Using Screen in Scripts
Ed Schaefer and John Spurgeon
We expected reactions to our "Using Unknown Passwords" column, and we were
right. We'll cover reader feedback before continuing with this month's column.
Revisiting "Using Unknown Passwords"
Readers Andrew Barber, Rob Tanner, and Christopher Baker asked about situations
when you really need root's password. At OS boot-up, what happens when you are
queried for root's password to execute fsck or to enter a different maintenance
mode or run-level?
Depending on the situation, you might have to boot from external media to
solve this problem. In our environment, we support systems consisting of a primary,
a secondary, and a backup server. In the event of a boot problem, we promote
our backup server to be the production server and fix the problem at our leisure.
In Baker's situation, at times he requires the actual root password for maintenance
purposes, such as clearing screen locks and installing software. If a user has
root privileges through sudo, that user has the ability to temporarily change
root's password. Simply become root, execute "passwd root", and set a new password.
If necessary, the cron jobs that set passwords to random values can be temporarily
disabled as well. (Although the column suggested changing root's password every
minute, that's probably overkill in most situations.)
Carl Lowenstein suggests locking root's password instead of using our complicated
procedure to periodically change the password. Lowenstein raises another excellent
point -- one that we should have stressed in the article.
On Solaris, you can lock a user's password with the command:
passwd -l username
This inserts the string "*LK*" in the encrypted password column in /etc/shadow.
This might be just as good as setting the password to a random value, provided
you also turn off password aging with the command:
passwd -x -1 username
On Solaris, you have to be careful because if a user's password expires -- even
if it is locked -- that user's cron jobs stop running.
|
