Solaris 10 bulk password setting via sed

We have a client that likes to generate their own /etc/shadow password hashes and have us assign them to a bulk list of their userids. This enables them to not have to pass along a plain-text password to us, their hosting provider. We’re in the process of transitioning this client to our LDAP configuration, but until we get them converted it’s each individual machine and I wasn’t thrilled about having to spend an entire day to vi the shadow file on more than 50 servers for 17 userids on each server.

Prior to Solaris 10 this was easy enough to do via a script given the limited characters for password generation. I needed to figure out a way to script it out for Solaris 10 with the inclusion of $ and / into the password hashes. I finally got it working via command line and then had to slightly modify the way it was done via script. The only funkiness I noticed was the literal interpretation of $ when read in from a variable, so please note that the line in the script containing the password must include “\” prior to every occurance of $.

For example, if your password salt is “$1$aQmSf/ZM$CBSTF10TXrvpOe..OaCtH/” then you’ll need to set your salt into the script’s variable thusly:

PASSWD=”\$1\$aQmSf/ZM\$CBSTF10TXrvpOe..OaCtH/”

I added a few idiot checks around the script since wiping out your /etc/shadow file is never a fun thing to explain to the boss. Feel free to tweak this if you can think of any other ways to streamline it or any additional idiot checks. Please also note that while this script does clean up after itself in the /root/scripts working directory, it will leave a time-stamped copy of /etc/shadow in /etc in case you run into any need to rollback your changes.

#!/usr/bin/bash

# Check for userid

if [[ $1 = “” ]]
then
echo ” Usage: pwchange.sh <userid>”
exit
else
sleep 0
fi

DATE=`date +%m%d%y%H%M%S`
USER=$1
OLDPW=`grep $USER /etc/shadow | cut -f 2 -d “:”`
USERCK=`grep $USER /etc/shadow | cut -f 2 -d “:” | wc -l`

# Check if userid exists in /etc/shadow.

if [[ $USERCK -lt 1 ]]
then
echo “No users matching $USER”
exit
else
sleep 0
fi

# Check if multiple userids exist. If there are, fail out.

if [[ $USERCK -gt 1 ]]
then
echo “Multiple users matching $USER”
exit
else
sleep 0
fi

PASSWD=”\$1\$aQmSf/ZM\$CBSTF10TXrvpOe..OaCtH/”

# Check if password has already been set to salt.

if [[ $OLDPW = $PASSWD ]]
then
echo “Password already matches for $USER”
exit
else
sleep 1
fi

echo “Setting password for $1”

/usr/bin/cp -rp /etc/shadow /etc/shadow.$DATE
/usr/bin/cp -rp /etc/shadow /root/scripts/shadow
/usr/bin/sed -e “/$USER/s|$OLDPW|$PASSWD|g” /root/scripts/shadow > /etc/shadow
/usr/bin/rm /root/scripts/shadow

Setup ALOM networking with jumpstart begin script

When jumpstarting a server you want to see the console output to make sure nothing bad happens,
this can be accomplished by logging into the ALOM over the network so you can follow your installation
from your desk in stead of the noisy datacenter.

First when the server is powered up we want to go into the ALOM/SC
when you are in the ok prompt type:

{1} ok #.
sc>

The first thing to do is to set the admin password

sc> password
password: Changing password for admin
Enter new password: *****
Re-enter new password: *****
sc>

Read the rest of this entry »

Removing a driver that panics the kernel during boot

I had the unfortunate experience dealing with a system that panics on boot. I added the Emulex lpfc package which loads the driver during the installation. Then the V490 panics, dumps the system core, and reboots. At which point it panics again since it is trying to load the lpfc driver. In order to figure out what is wrong I need the dump, but the machine won’t boot. To fix the problem I perform a network boot into single use mode, I mounted up the OS, chroot and removed the driver with the rem_drv(1M).

# mount /dev/dsk/c1t0d0s0 /mnt
# chroot /mnt /bin/bash
# rem_drv -b / lpfc
# init 6

More Authors Needed

In last month since I started this blog, I have had over 1000 views.  Which is great considering I only have about five posts.  But it is hard for me to keep the content flowing and fresh.  I am seriously looking for a lot of authors to join the ranks and contribute their own articles.  Even if you think you aren’t a great writer I will work with you.  Send me an email and considering adding some of your own content.  The more people we have the better this blog will be.

boot net:speed=100,duplex=full – install

This is a gem for jumpstarting, usually people have a begin script that sets the interface to 100M Full. But this sets the interface immediately at boot time. It speeds this up a bit, and makes it easier to configure your jumpstart server. For more information see EXAMPLES in boot(1m).

Setting ce driver parameters with ce.conf

I am starting to run into a situation where I need both a 100M Full Duplex set on one ce interface, but 1000M Auto Negotiate on another. To put it bluntly this is a chore. I have done it a few times over the last year, but never remember the steps. I am sure there are some descent docs out there but I have pieced this together from looking at the documentation, which was wrong at one point. What you need to do is unambiguously identify the exact PCI device to supply different parameters. Otherwise it is easy you just add the following to /platform/sun4u/kernel/drv/ce.conf:

adv_autoneg_cap=0 \
adv_1000fdx_cap=0 \
adv_1000hdx_cap=0 \
adv_100fdx_cap=1 \
adv_100hdx_cap=0 \
adv_10fdx_cap=0 \
adv_10hdx_cap=0;

Of course you can use ndd in an rcX.d script to set these parameters, but SUN is quick to point out in the documentation that it is not supported. Plus I always viewed the conf files as the best practice.

NOTE: The following should work exactly the same for bge devices

Read the rest of this entry »

SC Alert: DHCP negotiation failed

I started getting these annoying errors on the console from the the V445 I am building, they log about once every couple of minutes:

SC Alert: DHCP negotiation failed, perhaps misconfigured or no DHCP server available

Searching for an answer you don’t get very much. But reading up on the ALOM that ships with the Sun Fire V445, I found the following:

All initial configuration must [be] done through the serial management port on the Sun Fire V210, V240, V250, and V440 servers and Netra 210, 240, 440 servers. Some servers (Sun Fire V215, V245, and V445) support DHCP by default on the network management port. These servers can be configured from the serial management port or network management port, if the attached subnet has a DHCP server. The default network configuration allows a Secure Shell session to be started.

So starting with the Sun Fire V215, V245, and V445 servers, it tries to associate with a DHCP server. If you are not currently using this feature you probably want to turn it off. So here is what you do.

Read the rest of this entry »