I use Solaris Recommended patch bundles to patch my production servers, and like to use the following shell function to retrieve the latest bundle (it saves some typing):
getpatch () {
RB="10_Recommended.zip"
if [ "$1" != "" ]
then
SPWD=$PWD
cd $1
if [ -f ${RB} ]
then
rm -rf ${RB}
fi
echo "Grabbing the latest recommended bundle ..."
wget --passive-ftp ftp://sunsolve.sun.com/patchroot/clusters/${RB}
cd $SPWD
else
echo "Usage: getpatch DIRECTORY"
fi
}
getpatch will grab the patch bundle identifed by the $RB variable, and place it in the directory passed as an argument:
$ getpatch /tmp
Grabbing the latest recommended bundle ...
--21:58:11-- ftp://sunsolve.sun.com/patchroot/clusters/10_Recommended.zip
=> `10_Recommended.zip'
Resolving sunsolve.sun.com... 192.18.108.40
Connecting to sunsolve.sun.com[192.18.108.40]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /patchroot/clusters ... done.
==> PASV ... done. ==> RETR 10_Recommended.zip ... done.
Length: 88,546,001 (unauthoritative)
100%[======================================================================================>] 88,546,001 289.44K/s ETA 00:00
22:03:16 (284.60 KB/s) - `10_Recommended.zip' saved [88546001]
This should work for any bourne shell derivative.
I was reading through O’Reilley’s OnLamp today, and came across their interview with the OpenBSD developers. In the interview, Dave Miller discussed the new features in OpenSSH 4.X, and described the following awesome new feature:
“Added the ability to store hostnames added to ~/.ssh/known_hosts in a hashed format. This is a privacy feature that prevents a local attacker from learning other hosts that a user has accounts on from their known_hosts file.”
So instead of hostnames being stored in plain text like:
yourhost.example.com ssh-rsa AAAB3NzaC1yc2EAAAABIwAAAIEAp832eeMwYH…
They are hashed first, so they don’t reveal the hostname. E.g.:
|1|bRGYyrC+bfKZGGd5GZH4wo1AnsI=|xcQ+54QNVwQ+fBCldn0= ssh-rsa AAA…
We added at the request of some MIT researchers who found that a substantial number of user private keys on shared systems are not encrypted (a really dumb thing to do, BTW). This lack of user care, coupled with the information in the known_hosts files, allowed attackers to spread their attacks to multiple systems.
Right now this is disabled by default, but administrators of sites with lazy users can turn it on with the HashKnownHosts config flag.
If you do this, you should probably also hash your existing known_hosts file (ssh-keygen -H).”
I sometimes think I am the only person that uses ssh-agent to store private keys in memory, and strong complex passwords to protect keys on disk. While a competent attacker would use a packet analysis tool to find SSH destinations, this may protect admins in select situations.
While reading through comp.unix.solaris, I came across the following hung serial port post from Andrew Gabriel:
There is a bug (actually a POSIX bug) that can leave the port permanently wedged if there are characters buffered to be transmitted but they never will be (e.g. due to flow controlled off).
This is circumvented in Solaris 10, in that if this situation arises, the driver will discard the buffered characters after a timeout if the process that had the port open no longer exists, so the port can be opened again and reused. (However, you can’t run Solaris 10 on a SPARCstation 5.)
This issue has bit me several times over the years, and I am glad to see that it’s addressed in Solaris 10.
The Solaris kstat(1m) utility can be used to display a variety of counters and statistics that are maintained by the kernel. These values range from IP datagrams received to the number of interrupts handled to values related to random number generation. To display all statistics maintained by the kernel, the kstat(1m) utility can be executed with no option:
$ kstat |more
module: audiots instance: 0
name: audiots class: controller
crtime 67.00041102
hard 0
multiple_service 0
snaptime 7152574.24162951
soft 0
spurious 0
watchdog 0
module: chip instance: 0
name: chip0 class: misc
chip_id 0
chip_idleness 0
chip_rechoose_interval 3
crtime 49.090863407
logical_cpus 1
snaptime 7152574.2441863
[ ..... ]
To get kstat statistics for a specific kernel module and an instance of that module, kstat(1m) can be executed with the “-m” (module name) and “-i” (instance name) options:
$ kstat -m qfe -i 1
I constantly find myself using kstat(1m) to analyze and debug the Solaris systems I support.
I like to keep my Solaris systems up to date with the the latest Operating System and application patches, and try to patch my systems monthly if time permits. If I am patching a production system, I always use recommend patch bundles that have been tested in a non-production environment. If I am patching QE or development machines, I like to use the automated patch features built into the Solaris smpatch(1m) utility. This makes patching a breeze, and ensures that all relevant patches are applied to the server.
While performing a routine patch update with smpatch(1m) this weekend, I encountered the following error message:
$ smpatch update -L
This operation is not supported by this application for systems with
local zones.
I have used smpatch(1m) numerous times, and have never encountered this specific error. This led me to believe that new functionality was recently added, or a bug had been introduced during the last patch update. A quick check of Sunsolve verified that this error was due to a bug in smpatch(1m), and the bug report indicated that a patch was not available. As with any software fix, it could take a while to produce a patch for this issue, so I decided to create a work-around in the interm.
The first step in my work-around uses the ‘smpatch analyze’ output to get the list of patches to apply:
$ smpatch analyze | awk '{print 1}' |more
119828-03
118890-01
119580-01
120844-01
119573-01
118371-04
[ ..... ]
The analyze operation will check the current patch levels against a master database at getupdates.sun.com. If smpatch(1m) determines that a patch is out of date, it will be displayed in the output. Each patch identifer produced by the analyze option can be downloaded to the local disk drive with smpatch(1m)‘s download option. Smpatch(1m) will place the downloaded files in “/var/sadm/spoolâ€? by default, but allows you to change this default behavior with the “-dâ€? (directory location to store files) option:
$ smpatch download -d /var/tmp -i 119145-05
com.sun.patchpro.util.Percentage@8ddb93
119145-05 has been validated.
This example uses smpatch(1m)‘s “-i” (patch identifier) option to download one of the patches produced by the analyze operation. If you would prefer to download all of the patches that are produced during the analyze operation, you can pass a file with a list of patch identifiers to smpatch(1m)‘s “-x” (list of patches to download) option:
$ smpatch download -d /var/tmp -x idlist=/var/tmp/patch.list
Once the patch(es) finish downloading, the unzip(1) utility can be used to uncompress and extract the archive:
$ cd /var/tmp && unzip -q /var/tmp/119145-05.jar
Once unzip(1) finishes extracting the archive, the patchadd(1m) utility can be used to apply the patch:
$ patchadd 119145-05
Validating patches...
Loading patches installed on the system...
Done!
Loading patches requested to install.
Done!
Checking patches that you specified for installation.
Done!
Approved patches will be installed in this order:
119145-05
Preparing checklist for local zone check...
Checking local zones...
Booting local zone oracle for patch check...
## waiting for zone <oracle> to enter single user mode...
## waiting for zone <oracle> to enter single user mode...
## waiting for zone <oracle> to enter single user mode...
## waiting for zone <oracle> to enter single user mode...
Restoring state for local zone oracle...
Booting local zone build for patch check...
## waiting for zone <build> to enter single user mode...
## waiting for zone <build> to enter single user mode...
## waiting for zone <build> to enter single user mode...
## waiting for zone <build> to enter single user mode...
Restoring state for local zone build...
This patch passes the local zone check.
119145-05
Summary for zones:
Zone oracle
Rejected patches:
None.
Patches that passed the dependency check:
119145-05
Zone build
Rejected patches:
None.
Patches that passed the dependency check:
119145-05
Zone irc
Rejected patches:
None.
Patches that passed the dependency check:
119145-05
Patching global zone
Adding patches...
Checking installed patches...
Verifying sufficient filesystem capacity (dry run method)...
Installing patch packages...
Patch 119145-05 has been successfully installed.
See /var/sadm/patch/119145-05/log for details
Patch packages installed:
SUNWadmc
Done!
Patching local zones...
Patching zone oracle
Booting local zone oracle for patching...
## waiting for zone <oracle> to enter single user mode...
## waiting for zone <oracle> to enter single user mode...
## waiting for zone <oracle> to enter single user mode...
Adding patches...
Checking installed patches...
Verifying sufficient filesystem capacity (dry run method)...
Installing patch packages...
Patch 119145-05 has been successfully installed.
See /var/sadm/patch/119145-05/log for details
Patch packages installed:
SUNWadmc
Done!
Restoring state for local zone oracle...
Patching zone build
Booting local zone build for patching...
## waiting for zone <build> to enter single user mode...
## waiting for zone <build> to enter single user mode...
## waiting for zone <build> to enter single user mode...
Adding patches...
Checking installed patches...
Verifying sufficient filesystem capacity (dry run method)...
Installing patch packages...
Patch 119145-05 has been successfully installed.
See /var/sadm/patch/119145-05/log for details
Patch packages installed:
SUNWadmc
Done!
Restoring state for local zone build...
Once the patch installation process completes, you can remove the patch and META-INF files in the work directory:
$ rm -rf /var/tmp/119145-05.jar /var/tmp/119145-05 /var/tmp/META-INF
I am not real sure how long smpatch(1m) will be broken, so I created autopatch to ease the patch process in the interm. Please review the script and test it in a non-production environment prior to use. If you run into any issues with autopatch, post a comment to let me know what issues you encountered (I have used it on several systems, and have yet to encounter any issues).