Enhanced Linux

Today I ran into a problem at work that I thought would be worth sharing. It is one of those odd only-happens-once-in-a-blue-moon errors, so writing it down and putting it out there on the internet may help those lucky few who run into it.

The Situation

I had a report from a user that the system account he and his team share was unable to run cron jobs. My initial checklist of things to verify were:

• Verify the syntax of the cronjob(s) by viewing the crontab: crontab -u <username> -l
• Verify user was listed in /etc/cron.allow, or *not* listed in /etc/cron.deny.
• Check the /var/log/cron for informational messages.

The cron syntax looked fine–I didn’t see any errors. I also verified that they were listed in the cron.allow file. (Our systems implement a cron.allow policy, for security.). From the crontab man page:

If the cron.allow file exists, then you must be listed therein in order to be allowed to use this command. If the cron.allow file exists, then you must be listed therein in order to be allowed to use this command.

It was the third entry, the system log, that alerted me to the problem.

Jan 5 10:26:01 hostname crond[21536]: User account has expired
Jan 5 10:26:01 hostname crond[21536]: CRON (username) ERROR: failed to open PAM security session: Success
Jan 5 10:26:01 hostname crond[21536]: CRON (username) ERROR: cannot set security context

The key piece of information here is “User account has expired.” While the shared system account was still usable–it doesn’t require a password–it had technically expired which meant cron would restrict its jobs. Remember, 99% of the time the system log tells you exactly what the problem is. The key is reading!

[ad#Google Adsense]

The Solution

The solution was to unexpire the system account. To do so you can use the chage command or the passwd command. In this situation, because this is a shared system account that does not need to expire, I set it to never expire:

passwd -x -1 username

From the passwd man page:

This will set the maximum password lifetime,  in  days,  if  the user’s  account  supports password lifetimes.  Available to root only. This will set the maximum password lifetime,  in  days,  if  the user’s  account  supports password lifetimes.  Available to root only.

As you might guess, -1 sets an infinite value meaning it will never expire.

This post will outline how to reset the root password on FreeBSD. These instructions require local access to the machine and are available on FreeBSD versions 5.4 and greater.

Resetting the root password

As I mentioned above, resetting the root password and gaining administrative access to the machine requires local access to the server. Following the steps below should put you at an administrative prompt where you will be able to run the ‘passwd’ command to reset the password to a known value.

1. Restart the server.
2. When the “Welcome to FreeBSD” menu appears, press the [SPACEBAR] to pause the boot countdown.
3. Select “4″ which should be: Boot FreeBSD in single user mode.

After the machine boots you should be presented with a prompt:

When prompted Enter full pathname of shell or RETURN for /bin/sh:

Press the enter key, or enter the full pathname of your preferred shell. At this point you should be at a shell prompt, as the root user. The remaining step is to reset the password to a known value.

In order to make this change you’ll need to remount the filesystem(s) in read-write. Use the following two commands to make this change:

mount -u /

mount -a

Finally, reset the root password using the passwd command:

passwd root

At this point you should be able to reboot the machine, or type ‘exit’ to continue the boot process into its normal multi-user environment.

Troubleshooting

If you have problems regarding the “passwd” command not being found, or other similar issues, you may need to ensure that you have properly mounted any additional file systems. I might suggest using:

mount /usr

To ensure that your /usr partition is mounted (assuming it is on a separate partition).