With the change in daylight savings rapidly approaching and most administrators are very busy installing the latest timezone patch i thought it was a good a time as any to take a closer look at timezones.

First up here are the required patches:

Solaris 8: 109809-08
Solaris 9: 113225-10
Solaris 10: 125378-03

So, if you are unsure of your Solaris release you are definitely on the wrong site.

I have pre-patched the current timezone patch;

anouk:/ # showrev -p | grep 125378
Patch: 125378-02 Obsoletes: 122032-05 Requires: Incompatibles: Packages: SUNWcsu
Patch: 125378-03 Obsoletes: 122032-05 Requires: Incompatibles: Packages: SUNWcsu

Let’s just confirm the timezone;

anouk:/ # cat /etc/TIMEZONE
…<snip>
TZ=Australia/Victoria
…<snip>

Now, the files in /usr/share/lib/zoneinfo are unreadable without the zdump command. Using the -v for verbose option we can see all the timezone changes for your relevant region from 1901 to 2038. For now, let’s just see what is in store for 2008.

anouk:/ # zdump -v Australia/Victoria | grep 2008
Australia/Victoria Tue Feb 5 01:03:14 2008 UTC = Tue Feb 5 12:03:14 2008 EST isdst=1
Australia/Victoria Sat Apr 5 15:59:59 2008 UTC = Sun Apr 6 02:59:59 2008 EST isdst=1
Australia/Victoria Sat Apr 5 16:00:00 2008 UTC = Sun Apr 6 02:00:00 2008 EST isdst=0
Australia/Victoria Sat Oct 4 15:59:59 2008 UTC = Sun Oct 5 01:59:59 2008 EST isdst=0
Australia/Victoria Sat Oct 4 16:00:00 2008 UTC = Sun Oct 5 03:00:00 2008 EST isdst=1

The top line shows the current date and time. Lines 2 and 3 show the changes at the end of daylight savings and the bottom 2 lines the start again later in the year. If you do not install the patch the above output will look like this and who knows what it will break;

heineken:/export/home/mg133308/Desktop # zdump -v Australia/Victoria | grep 2008
Australia/Victoria Tue Feb 5 01:10:14 2008 UTC = Tue Feb 5 12:10:14 2008 EST isdst=1
Australia/Victoria Sat Mar 29 15:59:59 2008 UTC = Sun Mar 30 02:59:59 2008 EST isdst=1
Australia/Victoria Sat Mar 29 16:00:00 2008 UTC = Sun Mar 30 02:00:00 2008 EST isdst=0
Australia/Victoria Sat Oct 25 15:59:59 2008 UTC = Sun Oct 26 01:59:59 2008 EST isdst=0
Australia/Victoria Sat Oct 25 16:00:00 2008 UTC = Sun Oct 26 03:00:00 2008 EST isdst=1

So, if you haven’t already - get patching. You only have a few weeks left. Bear in mind this patch requires a reboot.

First up, it is not recommended to use bash as root shell. This is because root requires access to a valid shell when nothing but root partition is mounted. Bash is usually dynamically linked to /usr, which is not always mounted in the same partition as root. Dynamic libraries can become corrupted and are a common source for root exploits. /sbin/sh is statically linked so is a valid candidate for root shell.

A simple line can be added to /etc/profile to safely jump root straight to bash;

if [ -f /usr/bin/bash ] ; then /usr/bin/bash ; fi

Now, for your users there is no problem for them to use the bash shell. But what do you need to enable their profiles to be sourced when they login on a windowed system such as kde.

Well, in such a scenario the ~/.bashrc file is called. If you login remotely, for example via console then the ~/.bash_profile file is called. So, in the ~/.bashrc file put the following:

if [ -f .bash_profile ] ; then
source .bash_profile
fi

And then your path and aliases from .bash_profile will be sourced. If you have all this information in the .bashrc file you can add the above lines to your .bash_profile file, just substitute .bash_profile with .bashrc.

The same goes for root. Leave root as default shell (/sbin/sh). Just ensure the .bashrc and .bash_profile files are in the root folder so when you change the shell to root your environment is setup as required/desired.

I discovered one of my servers did not have a bootblock installed on the secondary bootdisk.

ok boot disk2
Boot device: /pci@1f,0/ide@d/disk@2,0 File and args:
The file just loaded does not appear to be executable.

This needs to be fixed.

ok boot net -s
Resetting …
… <snip>
SINGLE USER MODE

# format
Searching for disks…done

AVAILABLE DISK SELECTIONS:
0. c0t0d0 <ST320011A cyl 38790 alt 2 hd 16 sec 63>
/pci@1f,0/ide@d/dad@0,0
1. c0t2d0 <ST320011A cyl 38790 alt 2 hd 16 sec 63> newdisk
/pci@1f,0/ide@d/dad@2,0
Specify disk (enter its number): ^D

# installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t2d0s0

# halt
syncing file systems… done
Program terminated

ok reset-all
Resetting …

ok boot disk2
Boot device: /pci@1f,0/ide@d/disk@2,0 File and args:
SunOS Release 5.10 Version Generic_127111-02 64-bit
… <snip>
Hostname: amsterdam

Voila.

One of my systems has been crashing. It happened again overnite. I thought i would examine the coredump process. To view the current settings just type # dumpadm

amsterdam:/ # dumpadm
Dump content: kernel pages
Dump device: /dev/md/dsk/d10 (swap)
Savecore directory: /var/crash/amsterdam
Savecore enabled: yes

This means it is dumping the kernel pages only, as opposed to everything in memory. The dump device, in this case swap, is a temporary device where data gets stored as the system is crashing. The savecore directory is where the crashdump will be written upon reboot of the system.

I don’t really want to change anything here, except for to make the savecore directory on a remote server. Note that using a dump device under the control of a volume manager is not recommended for access and performance reasons. The recommendation is to have a dedicated dump device. I should change that but i don’t have the resources at this stage.

In order to allow crashdumps to be written over nfs to a remote directory i have to allow root to write to that mount. I can do this as for this particular server i don’t much care about security. So on the nfs server:

anouk:/ # cat /etc/dfs/dfstab
… snip
share -F nfs -o rw,root=amsterdam /work
share -F nfs /export/home

And remembering that by default an nfs mount is set to read and write.

amsterdam:/ # dumpadm -c kernel -d /dev/md/dsk/d10 -m 20% -s /mnt/crash/amsterdam
Dump content: kernel pages
Dump device: /dev/md/dsk/d10 (swap)
Savecore directory: /mnt/crash/amsterdam (minfree = 3580219KB)
Savecore enabled: yes

The flag -m 20% will ensure there will always be 20% free in the file system. Now i would like to simulate a crashdump to ensure it will work as required. The savecore -L command will allow me to do this. It will save a crash dump of the live system without rebooting. However, as i do not have a dedicated dump device available at this time i will have to set that up first.

amsterdam:/ # savecore -L
savecore: dedicated dump device required

I have now added a unipack and i will quickly change the dumpadm config.

amsterdam:/ # dumpadm -d /dev/dsk/c1t0d0s0
Dump content: kernel pages
Dump device: /dev/dsk/c1t0d0s0 (dedicated)
Savecore directory: /mnt/crash/amsterdam (minfree = 3580219KB)
Savecore enabled: yes

I can now force a crashdump.

amsterdam:/ # savecore -L
dumping to /dev/dsk/c1t0d0s0, offset 65536, content: kernel
100% done: 19315 pages dumped, compression ratio 3.52, dump succeeded
System dump time: Thu Dec 20 21:31:57 2007
Constructing namelist /mnt/crash/amsterdam/unix.0
Constructing corefile /mnt/crash/amsterdam/vmcore.0
100% done: 19315 of 19315 pages saved

And there it is, coredumps dumped on an nfs mount.

See: dumpadm, savecore, /etc/dumpadm.conv