Search Results

Search found 2 results on 1 pages for 'hijinx'.

Page 1/1 | 1 

• USER_LOGIN audit log with incorrect auid value?

  - by hijinx

  We have a CentOS 6.2 x86_64 system that's logging what looks to be erroneous audit information. We were receiving alerts for failed logins by a user who wasn't actually trying to log in. After some diagnosis, we figured out that the source of the events is our tool that periodically checks to see if SSH is answering. When that happens, we see this log this entry: type=USER_LOGIN msg=audit(1340312224.011:489216): user pid=28787 uid=0 auid=501 ses=8395 subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct=28756E6B6E6F776E207A01234567 exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1 terminal=ssh res=failed' This is the entry we get whenever there is an incomplete ssh connection, but usually the auid is the same as the ses= value. For some reason, on this system, it's using a particular user's auid, regardless of the login user. For example, ssh'ng to this system as [email protected] and cancelling before providing a password generates this error. Attempting to log to an unrelated account with a bogus password will also create an entry with the incorrect auid value.

  Read the article

• Cron Job on Ubuntu Hardy Executing But Not Deleting Files As Expected

  - by Patrick McKenzie

  I have a bit of a pickle here and wonder if anyone can give me some pointers: I have a cron job which executes for a particular user daily and is supposed to sweep files in a particular directory. Technically, it is two jobs. I've turned on cron.log to verify they're actually executing, and they are: May 24 11:03:01 AppNameGoesHere /USR/SBIN/CRON[11257]: (mongrel_AppNameGoesHere) CMD (rm -rf /var/www/apps/AppNameGoesHere/current/public/ {popular,index,purchasing,purchasing-alternate,support,about-us,guarantee,screenshots}.htm{,l}) May 24 11:04:01 AppNameGoesHere /USR/SBIN/CRON[11260]: (mongrel_AppNameGoesHere) CMD (rm -rf /var/www/apps/AppNameGoesHere/current/public/ {stats,popular,bcf,articles,expenses}) I have removed the actual usernames and formatted it so that it is less ugly on StackOverflow. Now, my question: Despite the fact that I can see these deletions executing and apparently succeeding in the log, if I go to the specified directory, the files are still there. I initially suspected permission hijinx were going on, but I've verified that I can delete the files manually by su-ing into the mongrel_AppNameGoesHere user and issuing individual rm commands or by copy/pasting the cron job to the command line. Anything that I don't manually zap stays unzapped despite days of that cron job executing successfully. Any suggestions on to what might be happening? I was previously using Dapper Drake with these cron jobs in the /etc/crontab file directly, and when I upgraded to Hardy I moved them to user-specific crontabs (via sudo crontab -e - u mongrel_AppNameGoesHere), which was the point where they appear to have stopped working.)

  Read the article

1