Another Solaris item learned

After spending many hours, literally, in trying to figure out why a cron job wasn’t running, I finally stumbled upon the answer. Since this blog is more often than not used as my memory stick (the ram in my brain is beginning to fail), I thought I’d explain the issue and the solution I found.

We recently upgraded a server from Solaris 8 to Solaris 10 using LiveUpgrade. Not a bad way to do things, if you ask me. Once the server was brought up in Solaris 10, one of my users’ crontabs stopped working. In this case, it wasn’t critical, but it was a real pain to catch up what the cron missed (after being gone from the office for 2 weeks.) I tried all kinds of things (except the ones that put me on the path to recovery) including adding test entries to the crontab and seeing if they’d run. They didn’t.

Off to Google I ran. I discovered that our servers are logging cron runs (the log files reside at /var/cron/log), and I hadn’t thought of looking at them until about 15 minutes before the epiphany. I went to set up the servers to log cron runs, because most servers are installed without cron logging. I discovered it was turned on. So, I checked the logs, and found that I was getting the error

! bad user (username) Wed Jul 21 13:38:00 2010

The user is valid, so back to Google. The first answer I found said that you probably have a problem with the user in /etc/passwd or /etc/shadow. The user was in both files, but had been locked using “passwd -l username” – This did not cause any issues in Solaris 8, but once we turned up Solaris 10, the cron jobs ceased running.

The bottom line that I found with this problem is that in Solaris 10, the new security will not allow a user with a locked account to run cron jobs. I assigned a regular password to the user and life is grand once again.

SSH Requiring A Password

If you have gone through the process of sharing keys on various machines, but ssh is still asking for a password, I have the answer. After much pain, agony, wailing, and gnashing of teeth, I have found the elusive yet surprisingly simple answer. Change to your home directory, then issue the command

ls -ld . (that’d be ell ess space minus ell dee space dot for those who really shouldn’t be typing on a unix box)

If your directory does not come back as drwxr-xr-x (or 755 to those of us in the know), this is probably why your password is being requested. Change your home directory to 755 and try again. Happy?

This just in – your .ssh directory must be drwx- – – – – – (or 700) as well as the above info.  (My directory listing isn’t printing correctly – so I’ll write it out – drwx followed by 6 dashes.)