While attempting to use the default Solaris patch command to apply the suhosin patch to the PHP source code, the patch command bombed out:
$ /bin/patch -p0 < suhosin-patch-5.1.6-0.9.5.patch
Looks like a unified context diff.
The next patch looks like a unified context diff.
The next patch looks like a unified context diff.
The next patch looks like a unified context diff.
The next patch looks like a unified context diff.
The next patch looks like a unified context diff.
The next patch looks like a unified context diff.
The next patch looks like a unified context diff.
The next patch looks like a unified context diff.
The next patch looks like a unified context diff.
The next patch looks like a unified context diff.
The next patch looks like a unified context diff.
The next patch looks like a unified context diff.
The next patch looks like a unified context diff.
The next patch looks like a unified context diff.
The next patch looks like a unified context diff.
File to patch:
The unified diff contained the name of each file to patch, so I decided to see if the GNU patch utility (which is installed in /bin on most Solaris hosts) worked:
$ /bin/gpatch -p0 < suhosin-patch-5.1.6-0.9.5.patch
patching file php-5.1.6/configure
patching file php-5.1.6/configure.in
patching file php-5.1.6/ext/standard/basic_functions.c
patching file php-5.1.6/ext/standard/dl.c
patching file php-5.1.6/ext/standard/file.c
patching file php-5.1.6/ext/standard/file.h
patching file php-5.1.6/ext/standard/info.c
patching file php-5.1.6/ext/standard/syslog.c
patching file php-5.1.6/main/fopen_wrappers.c
patching file php-5.1.6/main/main.c
patching file php-5.1.6/main/php_config.h.in
patching file php-5.1.6/main/php.h
patching file php-5.1.6/main/php_logos.c
patching file php-5.1.6/main/snprintf.c
patching file php-5.1.6/main/spprintf.c
patching file php-5.1.6/main/suhosin_globals.h
patching file php-5.1.6/main/suhosin_logo.h
patching file php-5.1.6/main/suhosin_patch.c
patching file php-5.1.6/main/suhosin_patch.h
patching file php-5.1.6/main/suhosin_patch.m4
patching file php-5.1.6/sapi/apache/mod_php5.c
patching file php-5.1.6/sapi/apache2filter/sapi_apache2.c
patching file php-5.1.6/sapi/apache2handler/sapi_apache2.c
patching file php-5.1.6/sapi/cgi/cgi_main.c
patching file php-5.1.6/sapi/cli/php_cli.c
patching file php-5.1.6/TSRM/TSRM.h
patching file php-5.1.6/TSRM/tsrm_virtual_cwd.c
patching file php-5.1.6/TSRM/tsrm_virtual_cwd.h
patching file php-5.1.6/win32/build/config.w32
patching file php-5.1.6/Zend/Makefile.am
patching file php-5.1.6/Zend/zend_alloc.c
patching file php-5.1.6/Zend/zend_alloc.h
patching file php-5.1.6/Zend/zend.c
patching file php-5.1.6/Zend/zend_canary.c
patching file php-5.1.6/Zend/zend_compile.c
patching file php-5.1.6/Zend/zend_compile.h
patching file php-5.1.6/Zend/zend_constants.c
patching file php-5.1.6/Zend/Zend.dsp
patching file php-5.1.6/Zend/zend_errors.h
patching file php-5.1.6/Zend/zend.h
patching file php-5.1.6/Zend/zend_hash.c
patching file php-5.1.6/Zend/zend_llist.c
patching file php-5.1.6/Zend/ZendTS.dsp
GNU patch worked flawlessly, which leads me to wonder if the Solaris patch command requires additional flags to process unified diffs similar to this. I have had a number of issues arise with the default Solaris patch utility over the years, and for some reason it doesn’t seem to process unified diffs as smoothly as the GNU patch utility. In the interm, I aliased patch to gpatch to avoid these types of issues. :)
While debugging a goofy GNOME / USB interoperability issue this week, I came across the dbus-monitor program. Dbus-monitor allows you to view messages as they are sent on the DBUS message bus, which can be amazingly useful for debugging hardware and software interoperability issues. To print the messages that are traveling on the system message bus (DBUS defines two types of buses, one is the system bus, the other is a per session bus), dbus-monitor can be run with the “-system” option:
$ dbus-monitor --system
signal sender=org.freedesktop.DBus -> dest=:1.4 interface=org.freedesktop.DBus; member=NameAcquired
0 string ":1.4"
signal sender=:1.0 -> dest=(null destination) interface=org.freedesktop.Hal.Manager; member=DeviceRemoved
0 string "/org/freedesktop/Hal/devices/volume_label_"
signal sender=:1.0 -> dest=(null destination) interface=org.freedesktop.Hal.Manager; member=DeviceAdded
0 string "/org/freedesktop/Hal/devices/volume_label_"
In this example, you can see that two message were sent when a hardware device was added and removed from the system. After reading through a slew of documentation, I am finally starting to understand how all of the GNOME packages tie in one another. Yikes!
While reviewing the list of zones on one of my Solaris hosts, I noticed that I accidentally assigned the name “cone3” to a zone:
$ zoneadm list -vc
ID NAME STATUS PATH BRAND
0 global running / native
11 zone1 running /zones/zone1 native
- centos installed /zones/centos lx
- template installed /zones/template native
- cone3 configured /zones/zone3 native
- centostest configured /zones/centostest lx
While the name cone3 sounds interesting (for some reason cone3 reminds me of the coneheads movie), I originally intended for the zone to be called “zone3.” To assign the correct name to the zone, I fired up the zone configuration utility (zonecfg), and set the ‘zonename’ variable to the correct value:
$ zonecfg -z cone3
zonecfg:cone3> set zonename=zone3
zonecfg:zone3> commit
zonecfg:zone3> exit
$ zoneadm list -vc
ID NAME STATUS PATH BRAND
0 global running / native
11 zone1 running /zones/zone1 native
- centos installed /zones/centos lx
- template installed /zones/template native
- zone3 configured /zones/zone3 native
- centostest configured /zones/centostest lx
Much better!
I gave a talk tonight on Solaris virtualization technologies, and posted my slides to prefetch.net. The presentation covered Solaris zones, Linux branded zones, project Crossbow, and shows how to configure each technology. The next two years will be exciting for members of the OpenSolaris community, since there are NUMEROUS awesome technologies currently in development (I am looking forward to seeeing Xen Dom0 and DomU support in an official Solaris 10 update!).
While reviewing the DNS logfiles on one of my name servers, I noticed that one of my Solaris hosts was querying getupdates.sun.com once per hour:
Sep 30 02:28:05 dns named[1097]: [ID 866145 local0.info] client 1.2.3.4#47644: view internal: query: getupdates.sun.com IN A +
Sep 30 03:27:35 dns named[1097]: [ID 866145 local0.info] client 1.2.3.4#47738: view internal: query: getupdates.sun.com IN A +
Sep 30 04:27:05 dns named[1097]: [ID 866145 local0.info] client 1.2.3.4#47841: view internal: query: getupdates.sun.com IN A +
[ ..... ]
Since I had recently applied the latest connection manager patches to the server, I started to wonder if Sun had installed a cron job (or started a daemon) to periodically poll the server that hosted getupdates.sun.com. To see what process was querying getupdates.sun.com, I first reviewed the cron jobs on the system, and then I perused the list of daemons that were running. Everything checked out fine, so I fired up DTrace to see which process was actually responsible for the DNS requests. It turns out these DNS queries were coming from the nscd daemon. After reading through the nscd.conf manual page, I came across a description of the “keep-hot-count” attribute:
“This attribute allows the administrator to set the number of entries nscd(1M) is to keep current in the specified cache. value is an integer number which should approximate the number of entries frequently used during the day.”
A quick peak at /etc/nscd.conf revealed that the value of keep-hot-count is set to 20 by default:
$ egrep "keep-hot.host" /etc/nscd.conf
keep-hot-count hosts 20
It turns out nscd was refreshing the name service information entry for this host once per hour. To disable this behavior, I set the value of keep-hot-count to 0, and the DNS queries for getupdates.sun.com ceased. Numerous admins kill nscd on systems that don’t handle lots of login sessions, and I reckon I will need to investigate this option.