Unix
LOSUG Presentation Slides Now Available
My presentation at LOSUG on tuesday went down like a house on fire – I think it would be safe to say that the phrase for the evening was ‘It’s a cache!’.
For that to make sense, you need to look at the slides, which are now available here.
Attendance was great, but it seems the last minute change of day meant that some people missed the session. We had 151 people register, and about 80 turned up on the night.
Mysterious crashes? – check your temporary directory settings
Just recently I seem to have noticed an increased number of mysterious crashes and terminations of applications. This is generally on brand new systems that I’m setting up, or on existing systems where I’m setting up a new or duplicate account.
Initially everything is fine, but then all of a sudden as I start syncing over my files, shell profile and so on applications will stop working. I’ve experienced it in MySQL, and more recently when starting up Gnome on Solaris 10 9/07.
Sometimes the problem is obvious, other times it takes me a while to realize what is happening and causing the problem. But in all cases it’s the same problem – my TMPDIR environment variable points to a directory that doesn't exist. That's because for historical reasons (mostly related to HP-UX, bad permissions and global tmp directories) I've always set TMPDIR to a directory within my home directory. It's just a one of those things I've had in my bash profile for as long as I can remember. Probably 12 years or more at least.
This can be counterproductive on some systems - on Solaris for example the main /tmp directory is actually mounted on the swap space, which means that RAM will be used if it’s available, which can make a big difference during compilation.
But any setting is counterproductive if you point to a directory that doesn’t exist and then have an application that tries to create a temporary file, fails, and then never prints out a useful trace of why it had a problem (yes, I mean you Gnome!).
I’ve just reset my TMPDIR in .bash_vars to read:
case $OSTYPE in
(solaris*) export set TMPDIR=/tmp/mc;mkdir -m 0700 -p $TMPDIR
;;
(*) export set TMPDIR=~/tmp;mkdir -m 0700 -p $TMPDIR
;;
esac
Now I explicitly create a directory in a suitable location during startup, so I shouldn’t experience those crashes anymore.
Setting a remote key through ssh
One of the steps I find myself doing a lot is distributing round an ssh key so that I can login and use different machines automatically. To help in that process I created a small function in my bash profile script (acutally for me it’s in .bash_aliases):
function setremotekey
{
OLDDIR=`pwd`
if [ -z "$1" ]
then
echo Need user@host info
fi
cd $HOME
if [ -e "./.ssh/id_rsa.pub" ]
then
cat ./.ssh/id_rsa.pub |ssh $1 'mkdir -p -m 0700 .ssh && cat >> .ssh/authorized_keys'
else
ssh-keygen -t rsa
cat ./.ssh/id_rsa.pub |ssh $1 'mkdir -p -m 0700 .ssh && cat >> .ssh/authorized_keys'
fi
cd $OLDDIR
}
To use, whenever I want to copy my public key to a remote machine I just have to specify the login and machine:
$ setremotekey mc@narcissus
Then type in my password once, and the the function does the rest.
How? Well it checks to make sure I’ve entered a user/host (or actually just a string of some kind). Then, if I haven’t created a public key before (which I might not have on a new machine), I run the ssh-keygen to create it. Once the key is in place, I output the key text and then use ssh to pipe append that to the remote authorized_keys file, creating the directory along the way if it doesn’t exist.
Short and sweet, but saves me a lot of time.
Extra bash improvements
If you’ve read my Getting the most out of bash article at IBM developerWorks then you be interested in some further bash goodness and improvements.
Juliet Kemp covers some additional tricks on Improving bash to make working with bash easier. Some of the stuff there I have already covered, but the completion extensions might be useful if you like to optimize your typing.
Even better, one of the comments provides the hooks to change your prompt to include your current CVS branch, another to include your current platform, and a really cool way of simplifying your history searching.
Making a single extractor
One of my new articles is on smplifying your command line (read more about System Administrators Toolkit: Standardizing your UNIX command-line tools, making your life easier as you move between different environments. The same principles can be applied just to make your life easier. Here’s a function I’ve had in my bash init script for years that gets round the issue of extracting a compressed archive file of various types, even if your tar isn’t aware of the compression type:
function uz ()
{
file=$1
case $file in
(*gz) gunzip -c $file|tar xf -;;
(*bz2) bunzip2 -c $file|tar xf -;;
(*Z) tar zxf $file;;
(*zip) unzip $file;;
esac
}
Now I can extract any file with:
$ uz file{gz|bz2|zip|Z)
And not worry that my Solaris tar isn’t bzip2 aware even though it is Gzip aware.
Copying multiple files with scp
I keep my .bash init scripts on one machine and copy them over to each machine on which I have a login. There’s various bits of logic in there to ensure that the right PATH and other values are set according to the host and/or platform.
I then have a simple line that updates the .ocal .bash scripts from the main box that holds the main copies, so that I can just run:
update-bash
To update everything. I use scp and, depending on the system, use a preset key or require a password.
For copying multiple files there are many solutions; I could just use .bash*, but I’d also get the history and backup files. The typical advice is separate entries:
scp mc@narcissus:.bashrc mc@narcissus:.bash_aliases
This is less than optimal for a number of reasons – the first is that each location is treated individually, and that requires multiple connections and multiple password requirements. You can, though, use normal shell like expansion, just make sure you use quotes to ensure that it isn’t parsed and expanded by the local shell instead of the remote one:
scp mc@narcissus:".bash{rc,_path,_aliases,_vars}" ~
Getting Solaris 10 working in Parallels
I’ve just been sent the latest version of Solaris 6/06 release) and wanted to get it working in a Parallels virtual machine.
Not everything is plain sailing, but with a combination of past experience and a few quick configuration changes you can get it working fine.
Basic installation
The key to getting the basic installation working fine is to ensure you choose and set the correct options when configuring the disk device. The Solaris Installer will see the virtual disk, but for some reason wont automatically perform the fdisk partition for you. Once you get to the option that shows the disk drives and default partition, make sure you go through the FDISK configuration and create a single partition. This will give Solaris the block device it needs to then create it’s own partition map.
Networking
Once booted up, you’ll need to get the networking driver that comes with the Parallels boot disk installed. Attach the vmtools.iso disk (on Mac OS X this is located in /Library/Parallels/Tools); it should automount in Solaris. Navigate through to the network/Solaris directory and run the network.sh script to install the driver and configure the IP address, netmask and gateway. You’ll need to reboot.
Once rebooted, copy /etc/nsswitch.dns to /etc/nsswitch.conf to enable DNS searches for hosts, and then edit /etc/resolv.conf with your domain name (optional) and nameserver information. For example, mine reads:
domain mcslp.pri
nameserver 192.168.0.22
nameserver 192.168.0.24
X11 configuration
The default X11 configuration will often work fine for the display and keyboard, but the mouse fails to be configured. You need to configure the mouse to use the /dev/kdmouse device and operate as a PS/2, not USB, mouse.
You can do this by hand by editing the /etc/X11/.xorg.conf file, or you can create your own, or you can download this file and copy it into /etc/X11/xorg.conf.
If you want to go through the process yourself, first run kdmconfig and set it to use X.org.
Then run /usr/X11/bin/xorgconfig – you’ll need to go through each step (which involves setting up the mouse, keyboard and display). Select the PS/2 mouse option and give the driver name. Choose an appropriate keyboard layout (I’m using the 102-key international layout and haven’t had any issues yet.
For the display driver, configure a multisync monitor (using huge manual horizontal and vertical refresh values) or using the largest of the options provided, and select VESA as the display adaptor type, setting an appropriate amount of video RAM etc. to get the display depth and size you want.
All set!
That should be everything – you can see a sample of Solaris 10 running in Parallels below.
.
Stepped execution with cron and at
I had a query from a reader today as a follow up to my System Administrators Toolkit: Time and event management article at developerWorks:
How do I execute a script at a specific interval, for example 28 days, rather than on a specific day or date?
It is the one limitation of cron that it doesn’t support such an interval, although there are some systems (including many Linux installations) that provide an alternative method. There are some solutions to the problem that will work on any platform that uses the cron/at system.
One way is to run the script every 7 days, and have it record how many times it’s been called in a file.
All you have to do is, in the script, load the current count, work out if this is the fourth time, and run the script accordingly.
For example:
count=`cat counter`
count=`expr $count + 1`
if [ $count -eq 4 ]
then
echo 0 >counter
echo 4th time called, going for it
# Do everything else
else
echo $count >counter
fi
I suggest you put the counter file into a usable location, but you get the idea.
The other alternative is to use at, rather than cron, and then add a line in the script to execute the script again in 28 days time. For example, using this line at the end of your script:
at 9pm + 28 days <myscript .sh
Because you are specifying the same time, but a different day, this will execute at the same time every 28 days.
If your script takes a long time to process and you run it, for example, at 23:59, put the ‘at’ line at the start of the script, rather than the end, so that the request gets registered on the same day.