Blog O' Matty

Solaris B_FAILFAST messages

This article was posted by Matty on 2005-04-14 22:22:00 -0400 EDT

After patching my box a few months back, I noticed the following messages on the console after I rebooted:

Apr 15 15:23:15 winnie md_mirror: [ID 437521] NOTICE: md: d1: B_FAILFAST I/O disabled
Apr 15 15:23:15 winnie md_mirror: [ID 437521] NOTICE: md: d2: B_FAILFAST I/O disabled
Apr 15 15:23:15 winnie md_mirror: [ID 437521] NOTICE: md: d1: B_FAILFAST I/O disabled
Apr 15 15:23:15 winnie md_mirror: [ID 437521] NOTICE: md: d2: B_FAILFAST I/O disabled

Due to the nature of the message, I grew somewhat frantic, and began feverishly scouring the Internet for answers. It didn’t take long to stumble across the following Sunsolve article. According to sunsolve, these are not errors, and the metadevices are not faulted:

“These are not errors. These are informational (NOTICE) messages telling you that the driver underlying your metadevices does not support the B_FAILFAST option and, as a result, that capability will not be active for speedier recovery. There is no way to disable these messages.”

C pre processor

This article was posted by Matty on 2005-04-13 22:18:00 -0400 EDT

I am knee deep in debugging another SEGFAULT issue, and was given a cool tip by my friend Clay this weekend. When you see lots of #ifdef, #ifndef, and #endif’s in a source file, you can see what the C pre-processor will produce by running the source through the C pre-processor command (cpp):

$ cat ack.c


typedef int blah;

typedef long foo

int main(void) {

int m = 5;


$ cpp -DSOMETHING ack.c

[ ... ]

typedef int blah;

int main(void) {

int m = 5;


I removed all the standard includes to simplify the example. This is super useful!

Solaris logfile rotation utilities

This article was posted by Matty on 2005-04-05 22:28:00 -0400 EDT

The logadm(1m) utility comes with the Solaris Operating System, and allows system and application logfiles to be rotated at configurable intervals. logadm(1m) is controlled through the logadm.conf configuration file, which contains the logfiles to rotate, and information to describe how to rotate the logfiles. When I need to add new entries to the logadm.conf configuration file, I usually invoke logadm(1m) with the following options:

-w ENTRY - Write an entry to logadm.conf
-a - Command to run after a logfile has been rotated
-b - Command to run before a logfile is rotated
-C COUNT - Number of logfiles to keep around
-e EMAIL - Send an email to EMAIL with the results
-o OWNER - Change the owner to OWNER after rotating the file
-g GROUP - Change the group to GROUP after rotate the file
-m PERMS - Set the permissions to PERMS after rotate the file

In addition to these flags, there are dozens of available options to control where logfiles are stored after they are rotated, the format logfiles will be stored in, and several directives to control when a file is rotated (e.g., when a file is bigger than size, or after X days/weeks/months). The following example can be used to rotate the IP filter logfiles daily:

$ logadm -w ipflog -C 30 -o sys -g sys -m 600 /var/log/ipflog -a 'kill -HUPcat /var/run/’`

This will keep thirty copies of ipflog, set the owner and group to sys, and restart syslogd after the logfiles are rotated. logadm(1m) will run each day at 3:10am, and provides the “-p” option to rotate logfiles at specific points in time. The following example will rotate the IP filter logfiles now:

$ ls -al /var/log/ipf | head -3

-rw------- 1 sys sys 65316 Apr 5 10:05 /var/log/ipflog
-rw------- 1 sys sys 0 Apr 5 09:47 /var/log/ipflog.0
-rw-r--r-- 1 root root 103495791 Apr 5 09:49 /var/log/ipflog.1

$ logadm -p now ipflog

$ ls -al /var/log/ipf | head -3

-rw------- 1 sys sys 149 Apr 5 10:05 /var/log/ipflog
-rw------- 1 sys sys 65316 Apr 5 10:05 /var/log/ipflog.0
-rw------- 1 sys sys 0 Apr 5 09:47 /var/log/ipflog.1

logadm(1m) also supports regular expressions, so entries similar to the following are possible (this item came from the logadm man page):


This is a nifty little utility.

Automating Solaris patch installations

This article was posted by Matty on 2005-04-01 22:26:00 -0400 -0400

Solaris 10 now ships with the patchpro suite of utilities, which assist with analyzing and applying Operating System patches. Patchpro makes patch installation super easy, since you are not required to download recommended bundles, or dig through patchdiag information to find the “required” patches. The patchpro smpatch(1m) utility can be run with the analyze option to compare the current set of patches from with what is installed on a server:

$ smpatch analyze

119145-01 SunOS 5.10: usr/snadm/lib Patch
119042-02 SunOS 5.10: patch usr/sbin/svccfg
117463-02 SunOS 5.10: passwdutil Patch
119143-02 SunOS 5.10: patch lib/
118822-01 SunOS 5.10: kernel Patch

If you want decided to download and install each patch listed by the analyze option, you can run smpatch(1m) with the update option:

$ smpatch update

119145-01 has been validated.
119042-02 has been validated.
117463-02 has been validated.
119143-02 has been validated.
118822-01 has been validated.
Installing patches from /var/sadm/spool...
119145-01 has been applied.
119042-02 has been applied.
117463-02 has been applied.
119143-02 has been applied.
118822-01 has been applied.
/var/sadm/spool/patchpro_dnld_2005.04.07@12:25:28:EDT.txt has been moved to /var/sadm/spool/patchproSequester/patchpro_dnld_2005.04.07@12:25:28:EDT.txt

Each smpatch run produces a logfile with notes on required reboots, and additional instructions:

$ cat /var/sadm/spool/patchproSequester/patchpro_dnld_2005.04.07@12:25:28:EDT.txt

This patch bundle was generated by PatchPro.

Please refer to the README file within each patch for installation instructions. To properly patch your system, the following patches should be installed in the listed order:

1) 119145-01
2) 119042-02
3) 117463-02 !!! REBOOT !!!
4) 119143-02 !!! REBOOT !!!
5) 118822-01 !!! REBOOT !!!

If you want to view the smpatch(1m) configuration options, you can run smpatch(1m) with the get option:

$ smpatch get - "" - /var/sadm/spool
patchpro.install.types - rebootafter:reconfigafter:standard
patchpro.patch.source -
patchpro.patchset - patchdb - ""
patchpro.proxy.passwd - ""
patchpro.proxy.port - 8080
patchpro.proxy.user - ""
patchpro.sun.passwd - ""
patchpro.sun.user - ""

smpatch(1m) contains a several options in addition to “analyze,” “update” and “get.” The “add” option allows individual patches to be installed, “remove” backs out patches from a system, “download” grabs a patch from “patchpro.patch.source,” and “set and “unset” are used to configure smpatch(1m).

Configuring OpenBSD to support cable modems

This article was posted by Matty on 2005-03-27 23:20:00 -0400 -0400

I recently switched from DSL to cable, and had to learn how to use the ISC DHCP software with OpenBSD and my cable provider (Comcast). This was relatively easy, and the dhclient(8) manpage has lots of useful information and examples. Once I read through the man page, I created a file called/etc/dhcpclient.conf with the following information:

interface "hme0" {
send host-name "OBSD1";
request subnet-mask, broadcast-address, time-offset, routers;

script "/etc/dhclient-end";

This configuration file tells dhclient(8)to request DHCP services on the hme0 interface. The services are defined between curly braces, and include default routers, DNS servers, and the time a lease is valid ( I personally only grab netmask, broadcast, lease time, IP addresses and default routers from the Comcast DHCP servers). I also created the following shell script to flush the PF stable table, and add a new Pf policy during lease negotiation:


# Startup PF
/sbin/pfctl -e -F all -f /etc/pf.conf

Once the configuration is in place, the dhclient(8) utility can be invoked to grab a lease on an interface defined in dhclient.conf:

$ dhclient hme0

When you are attempting to get DHCP working, you can run the dhclient(8) utility with the “-d” option. This will print tons of debugging information, and help you clear up issues in a timely manner. Now that the DHCP connection is working, I added the following to /etc/rc.conf to grab a lease when the server boots:

# Bringup hme0
echo -n "Bringing hme0 online..."
/sbin/ifconfig hme0 up
echo "Done"

# Startup the cable connection
echo -n "Startup Cable connection..."
/sbin/dhclient hme0
echo "Done"

If you want to review the leases and expiration times, you can view the contents of “/var/db/dhclient.leases”:

$ ls -al /var/db/dhclient.leases

---------- 1 root wheel 796 Mar 27 13:48 /var/db/dhclient.leases

You should enable pf in /etc/rc.conf, and ensure a default policy is in place prior to grabbing the initial lease. There is a period of time when you will be sitting on the Internet unprotected. It might be paranoia, but I like to have a DROP ALL but DHCP policy in place prior to dhclient starting.