While perusing the system logfiles on a server running X64 Solaris 10 6/06 this weekend, I noticed several errors similar to the following:
$ tail -10 /var/adm/messages
Jul 16 15:45:49 neutron genunix: [ID 935449 kern.info] ATA DMA off:
disabled. Control with "atapi-cd-dma-enabled" property
Jul 16 15:45:49 neutron genunix: [ID 882269 kern.info] PIO mode 4
selected
Jul 16 15:45:49 neutron genunix: [ID 935449 kern.info] ATA DMA off:
disabled. Control with "atapi-cd-dma-enabled" property
Jul 16 15:45:49 neutron genunix: [ID 882269 kern.info] PIO mode 4
selected
Jul 16 15:45:49 neutron genunix: [ID 935449 kern.info] ATA DMA off:
disabled. Control with "atapi-cd-dma-enabled" property
Jul 16 15:45:49 neutron genunix: [ID 882269 kern.info] PIO mode 4
selected
Jul 16 15:45:49 neutron genunix: [ID 935449 kern.info] ATA DMA off:
disabled. Control with "atapi-cd-dma-enabled" property
Jul 16 15:45:49 neutron genunix: [ID 882269 kern.info] PIO mode 4
selected
Jul 16 15:45:49 neutron genunix: [ID 773945 kern.info] UltraDMA mode 6
selected
The syslog entry mentioned that the “atapi-cd-dma-enabled” eeprom property can be used to enable DMA on the CD drive, so I ran the eeprom utility with the “atapi-cd-dma-enabled=1” option to enable DMA:
$ eeprom "atapi-cd-dma-enabled=1"
To verify that the setting took effect, I ran the eeprom utility:
$ eeprom
kbd-type=US-English
ata-dma-enabled=1
atapi-cd-dma-enabled=1
ttyb-rts-dtr-off=false
ttyb-ignore-cd=true
ttya-rts-dtr-off=false
ttya-ignore-cd=true
ttyb-mode=9600,8,n,1,-
ttya-mode=9600,8,n,1,-
lba-access-ok=1
prealloc-chunk-size=0x2000
bootpath=/pci@0,0/pci-ide@11,1/ide@0/cmdk@0,0:a
console=text
This stopped the errors from appearing in my system logfiles, and the CD drive is performing awesome.
I have mentioned several problems with Sun’s smpatch utility in the past few blog entries, and it looks like I hit another nasty bug. The sconadm utility allows me to register a server:
$ sconadm register -a -r RegistrationProfile
sconadm is running Authenticating user … finish registration!
But when I run the smpatch utility to check for updates, it says the system isn’t registered:
$ smpatch analyze
Failure: Cannot connect to retrieve Database/current.zip: This system is currently unregistered and is unable to retrieve patches from the Sun Update Connection. Please register your system using the Update Manager.
This is somewhat amusing, though it has caused me a good deal of consternation. I am extremely disappointed with the quality of Sun’s patch tools, and am posting this here in case other folks are encountering similar problems. Hopefully they will see that they are doing nothing wrong, and the tools they have been provided are broken.
Solaris has been shipping with a robust logfile management facility for a few years now, and I have found it super useful for managing system and application logs. The log management facility revolves around the logadm utility, which allows admins to set policies on when and how logfiles are rotated. Logadm stores it’s configuration in the file /etc/logadm.conf, and provides the “-w” and “-r” options to add and remove entries from the configuration file. The following example shows how to add an entry to rotate and compress the IP filter logfiles once per week:
$ logadm -w /var/log/ipflog -C 8 -P 'Fri Jul 14 23:05:38 2006 -a '/usr/sbin/svcadm refresh system-log' -g root -m 644 -o root -p 7d -z 0
This example has several interesting options. The first parameter contains the logfile to rotate, the “-C” option indicates how many copies to keep, the “-a” option lists a command to run after the file is rotated, the “-g,” “-o” and “-m” options indicate the user, group and permissions to apply to the logfiles, the “-p” option indicates how often to rotate the file, and the “-z” option can be used to compress logfiles after they are rotated. All of the options are covered in gory detail in the logadm(1m) manul page.
I run several CentOS 4.0 servers, and having to manually check each server for new updates is tedious. To simplify my life, I decided to write a shell script (yumnotifier) to E-mail me when new updates are available. The script (yumnotifier) analyzes the output from ‘yum check-update,’ and generates an E-mail similar to the following if updates are available:
From root@localhost.localdomain Sat Jul 15 19:24:59 2006
Date: Sat, 15 Jul 2006 19:24:59T-0400:00-04:00
From: root
To: matty@localhost.localdomain
Subject: Updates available for biscuit
==== The following updates are available for biscuit ===
comps.i386 2:4.3CENTOS-0.20060314 base
gtk2.i386 2.4.13-18 base
kernel.i686 2.6.9-34.0.2.EL update
libtiff.i386 3.6.1-10 update
mysql.i386 4.1.20-1.RHEL4.1 update
mysql-devel.i386 4.1.20-1.RHEL4.1 update
If you manage systems that use yum, you might be interested in this script.
If you’ve been following the Xen movement, you might be interested in Sun’s announcement that Solaris can now operate as Dom0 (the controlling domain). To celebrate the availability of Dom0 support, the Solaris Xen community has written several in-depth technical posts:
Migrating Xen domains to new servers
Detailed description of how Xen handles page faults
The current Solaris Xen implementation is definitely not production quality, and is missing some key features such as hardware supported virtualization and network checksum offload. Dom0 support is definitely exciting news, and will hopefully spark some additional interest in Solaris.