Alan Hargreaves' Weblog

Interim fixes for Bind Vulnerability VU#725188/CVE-2009-0696 (Updated)

Yesterday I noticed an article titled New DoS Vulnerability in All versions of BIND 9 on slashdot. The article refers to BIND Dynamic Update DoS at the ISC site describing Vulnerability Note VU#725188 - ISC BIND 9 vulnerable to denial of service via dynamic update request.

This very rapidly caused a stir on a few internal mailing lists that I'm on and work on addressing this as

        6865903 Updated, P1 network/dns CVE-2009-0696 BIND dynamic update problem

The current status of this within Sun is that the Interim Security Reliefs (ISR) are available from http://sunsolve.sun.com/tpatches for the following releases:

SPARC Platform

• Solaris 10 IDR142522-01
• Solaris 9 IDR142524-01

x86 Platform:

• Solaris 10 IDR142523-01
• Solaris 9 IDR142525-01

Sun Alert 264828 is on its way to be published. When published it will be available from: http://sunsolve.sun.com/search/document.do?assetkey=1-66-264828-1

The fix is planned for build 121 for OpenSolaris/Nevada and we're attempting to get it into the next possible release Support Repository Update (SRU3).

Update 1

It turns out that the Solaris 9 ISR patches rely on an unreleased patch for Solaris 9. Work is underway to get this dependency out quickly,

Posted at 08:37AM Jul 30, 2009 by Alan Hargreaves in Solaris  |  Comments[4]

What's in the OpenSolaris Support repositories?

As you may or may not know, you can now buy support contracts for OpenSolaris.

Apart from the ability to make a support call, you also get access to the Support Repository. This is where we backport as subset of fixes from development system and do a lot more testing. Chris has blogged on how to point at the extras and support repositories, so I won't repeat him. What I will do is point you at a couple of sunsolve documents that may be useful in seeing what we are fixing in there.

The important one would be OpenSolaris Support Repository Updates (SRUs). In this page we list each of the updates as well as a browsable link (instructions provided on how to add the certificate to Firefox) and a README outlining the bugs that were addressed.

A link to SRU 6 hasn't made it into this page yet, but you can find it here.

Posted at 03:56PM Jun 16, 2009 by Alan Hargreaves in OpenSolaris  |  Comments[7]

Windows, OpenSolaris and VirtualBox

Over the weekend (as I knew we were going to have some network stuff going on) I installed Virtual Box on my notebook on the Windows disk (I have nevada on the other disk [yes I have a notebook with two 250gb discs]) and then installed a release candidate ISO of OpenSolaris 2009.06. I copied a backup of my punchin credentials and the two packages I needed onto the FAT32 partition of the windows disc from within nevada and then got to work setting things up.

Gotcha #1, don't try to do the install with only 512mb memory, it looks like it's working, but it just sits there doing precious little. I used up about an hour of battery on the train trying this. I got off the train at Tuggerah and went to McDonalds to both get dinner and finish the install, which then went along happily (I chose McDonalds mainly because they also have free wifi).

Installed the punchin packages and restored the credentials. It actually took a bit of research to find out how to use sharing. Doing it from the Windows side with Virtual Box was relatively straightforward, but doing it from the OpenSolaris side was not so obvious. I ended up finding it after hitting the User Guide. I'd called the directory I wanted "share", from OpenSolaris I had to do

$ pfexec mount -F vboxfs share /mnt

Once I'd done that it just worked fine. Everything looked great, except I'd now run out of battery with no power points easily in sight. Oh well headed home.

Once connected to the power everything seemed to work. I dropped the memory back to half a gig (as I run a few things in windows that are kinda memory hungry), and it worked fine for me all weekend just on the notebook.

Arrived at work today to find that for reasons that I won't go into today, the workstation that I normally run my Sun Ray IIFS from was off the internal network, making my Sun Ray useless to me.

I ran up Virtual Box on the notebook and then started the OpenSolaris that I had to start working. A little into the day it occurred to me that I have two 22" screens and a full sized keyboard and mouse sitting next to the notebook, currently doing very little. The keyboard and mouse are in their own unpowered usb hub plugged into the Sun Ray. OK they are now plugged into the notebook. That made a huge difference to productivity.

I then unplugged the digital connection from the screen and attached that to the notebook. Now I have a mirror of what's on the notebook and it is also easier to read. Productivity goes up again.

You know, I could go one step further by instead of mirroring the screens actually going dual screen, such that I have the windows session displayed on teh notebook and then I could go full screen (1600x1200) for OpenSolaris.

Once I arranged things that the mouse moved in the correct direction between the two, this is wonderful and surprisingly usable (well more so once i upped the memory for the OpenSolaris part to 768mb).

Gotcha #2, don't install the VDI files on a FAT32 filesystem, which is what I did because that's where I had the most free space. Everything worked wonderfully until the size of the dynamic disc that I had allocated hit 4gb. Then I started getting errors about full disks from Virtual Box. OK moving the VDI file to the NTFS wasn't that hard. I had to first physically copy it, then release and remove it from within Virtual box, then attach it again from the NTFS disc.

And that's how I ended up getting my job done today. I'm pretty happy with how it worked out.

Posted at 07:09PM May 25, 2009 by Alan Hargreaves in OpenSolaris  |  Comments[6]

Installing "extra" packages against OpenSolaris 2008.11 (with or without support repository updates)

It took me a bit to work out what was going on here (including a number of re-installs to make sure I hadn't screwed up), so I thought it worth sharing.

First, what a failure looks like:

After following Chris's instructions for adding the extra repository, I tried to install flash from it so the kids could play their browser based flash games.

$ pfexec pkg install pkg://extra/web/firefox/plugin/flash
Creating Plan |                        
pkg: the following package(s) violated constraints:
        Package pkg:/SUNWcsl@0.5.11,5.11-0.111 conflicts with constraint in installed pkg:/entire: 
                Pkg SUNWcsl: Optional min_version: 0.5.11,5.11-0.101 max version: 0.5.11,5.11-0.101 defined by: pkg:/entire

It turns out that what is at issue here is that the extra repository now has the "fat" packages that we will be using for 2009.06. The pkg command on 2008.11 (with any number of support repository updates - I was originally on SRU4 before re-install) can't handle these so it produces that cryptic message.

So, what can we do about it?

The first step is to have a look at all versions of the package we are interested in on extra.

$ pfexec pkg list -af 'pkg://extra/web/firefox/plugin/flash'
NAME (AUTHORITY)                              VERSION         STATE      UFIX
web/firefox/plugin/flash (extra)              10.0.22.87-0.111 known      ----
web/firefox/plugin/flash (extra)              10.0.22.87-0.101 known      u---
web/firefox/plugin/flash (extra)              9.0.151-0.101   known      u---
web/firefox/plugin/flash (extra)              9.0.125-0.101   known      u---
web/firefox/plugin/flash (extra)              9.0.125-0.101   known      u---

The version 9 packages will work ok, so we simply install one of those:

$ pfexec pkg install "pkg://extra/web/firefox/plugin/flash@9.0.151-0.101"
PHASE                                          ITEMS
Indexing Packages                            554/554 
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                    1/1         3/3     2.46/2.46 

PHASE                                        ACTIONS
Install Phase                                  19/19 
Reading Existing Index                           9/9 
Indexing Packages                                1/1 

And done. The note to myself for 2009.06 is that that 4gb root disc is just not going to cut it anymore :) Time for something more reasonable.

Posted at 03:41PM May 22, 2009 by Alan Hargreaves in OpenSolaris  |  Comments[3]

Daaaaaaaad, the computer isn't booting

These were the words that my 10 year old boy yelled to me on Sunday.

I'm documenting this as I tried to imagine facing this as an end user, rather than as a Solaris kernel support engineer, and shuddered

The machine he is talking about is the OpenSolaris box that I installed for them and recently upgraded to SRU4 on Friday (more on supported updates shortly).

The box (silver) had been sitting at the boot load screen (those of us old enough to remember the original Battlestar Galactica would refer to it as the cylon screen) with the disk light hard on and the disk rattling away threatening to send itself off into hyperspace. It had apparently been like this for a few hours (he lost interest and went to watch TV before thinking to tell me).

He'd tried resetting it and it didn't help.

"OK", I thought, "I've just upgraded the box, maybe there was a problem with SRU4, let's boot into the prior boot environment." Easy enough to do, just reset and select the prior environment in grub.

No dice. Same issue.

Failsafe boot? No it appears that we don't have one of those.

Right, a single user boot. I want to have a look at what is going on on the console, So we need to get rid of the graphics crud at the start.

This isn't too hard. Have a look at the options in the text boot to be sure, but all I did was hit 'e' (edit) in grub, d (delete) the splash and graphics lines, e (edit) the unix line to take out the ",Graphics... " stuff off the end of the command, hit Enter to go back a screen then hit b (boot) and watch what happens.

I didn't have to wait long.

Let me give you a little more background on this machine. It really is scrounged together. The root pool consists solely of a 4gb disc removed from an ultra 10.

The root zpool was 100% full. The disc full messages scrolled for a while.

OK, once we waited for a few minutes we got the prompt asking for a login name and password to drop us to a root single user. OK, let's go looking for where the space issue is.

A 'zfs list' showed me that rpool/export/home was a little larger than I expected. Unfortunately, as the pool was full, I couldn't mount those. No worries, let's poke around on / to try to find something to remove to make enough space so we can mount things.

A good place to look for such space on a workstation is in /var/log, specifically the Xorg logs.

Let's remove one of those, ....

Bzzzzzt wrong.

Copy on write, .... In order to unlink a file we need to write a new block for the directory entry. Oops no free blocks.

The trick is to lose the space without having to rewrite the directory entry. We need to truncate one of the logs.

# : > Xorg.0.log.old

Much better. For good measure I zapped Xorg.0.log as well.

OK, that looks much better.

Let's mount rpool/export/home and have a look.

# zfs mount rpool/export/home

Ahhh, the kids home directories each have a largish core in them. Remove those, unmount /export/home. Now, as I mounted rpool/export/home and not rpool/export, a directory got created in /export. We need to remove that or the filesystem/local service won't start correctly (it will complain about /export having stuff in it).

Logout of that shell and the system continues on to milestone=multiuser and we're good again and Jake is off to do his daily moves in Kingdom of Loathing and resume his Club Penguin.

Posted at 01:26AM Apr 07, 2009 by Alan Hargreaves in OpenSolaris  |  Comments[15]

OpenSolaris 2008.11 on the kids computer

OK, colour me impressed.

We got a hold of a "broken" computer today. After replacing the power supply and putting on an old 9gb disk (the previous owner wanted to keep the disk) I started wondering what I was going to put on it. So it occurred to me that I really should try to put OpenSolaris on it, as I think it should do most of what the kids want.

Downloaded the image from opensolaris.com and burned the cd image. Note to self, don't try to burn a cd image while running itunes, downloading a podcast and playing second life under XP. It's a good way to have a write underrun and burn a coaster.

Put it into the machine and booted it. Lovely, came straight up into the live cd. Hmmm, but no network. Dived into the device assistant and it noted I had a Via ethernet and needed the vfe driver, for which it kindly pointed me at homepage2.nifty.com/mrym3/taiyodo/eng/. A little bit of finger trouble later, I found the compiled version of the amd64 driver for it and installed it. Reading the README.txt is a good idea, as I left a step out and was wondering why I had no network. The trick was, ...

$ rm Makefile
$ ln -s Makefile.amd64_gcc Makefile
$ pfexec make install
$ pfexec ./adddrv.sh

That last step is vital.

Just to be safe I rebooted (it's late on the Monday of a long weekend and my brain is not working real great) and it came back with a network and everything looks honky dory.

Given this is for the kids and they spend a lot of time on You Tube and Club Penguin, I needed flash installed. I did a quick bit of googling and found something that I should have known from my day job (like I said, late n the Monday of a long weekend), in that if I went to pkg.sun.com/register and using my Sun Online credentials that I could register for the Extras repository and there was a package for flash in there.

Well I did this but stil had some trouble as it kept telling me that my certificate date was in the future. OK This one I could figure out. This did used to run windows, so the time on teh machine was an hour slow because of how windows set the clock for summer time. Easily fixed:

$ pfexec ntpdate 0.pool.ntp.org

And getting back through the screen saver that obviously came up :).

OK, now it liked the certificates and I could install flash, and successfully look at youtube after a firefox restart.

The final step was to make a new account for my 10 year old son.

Now the smoke test. I had him login. He immediately brought firefox up with no prompting from me. A few web sites later he is happily playing on Club Penguin.

We'll see how this runs for them over the next few weeks.

I'm pretty happy with how this has gone down so far.

Posted at 11:03PM Jan 26, 2009 by Alan Hargreaves in OpenSolaris  |  Comments[1]

Installing OpenSolaris 2008.05 under Virtual Box and Upgrading it

I'm in the process of preparing a Transfer of information (TOI) for Support Services in Asia Pacific on some of the basic differences and things to watch out for in providing Support for OpenSolaris (as against Support for Solaris 10 which they are already doing). One of the things that I am asking folks to do is to have already installed and upgraded from the 2008.05 distribution. I went hunting for documentation on this and the closest that I could find was an email trail, and there were corrections to that process further down the trail.

As a result I rewrote the instructions after doing a lot of running through them to make sure I got it right.

I noticed someone in #opensolaris today having trouble and they had missed out one of the listed steps which he didn't see in the release notes. As a result I was asked to blog this stuff, so here we go.

As we don't really have an easy way to do the equivalent of a jumpstart from this image in our labs, I'm recommending folks try it with Virtual Box.

There is excellent documentation on installing both Virtual Box and Open Solaris available at http://dlc.sun.com/osol/docs/content/IPS/virtualbox.html. This includes information on downloading the packages and the ISO image for OpenSolaris 2008.05. Unfortunately it does not discuss installing Virtual Box on Solaris. Fortunately, this is not too hard. Simply download the appropriate package and install it with pkgadd(1M).

Once you have the distribution installed, you will need to upgrade it to the currently available system. Doing this will step you through exactly what is required to do this using the live-upgrade replacement and taking advantage of the system using ZFS root.

General instructions on updating to the latest OpenSolaris development build from the 2008.05 ISO Image

1. Before using the "image-update" subcommand, it is recommended that the latest available version of the IPS software be installed for your current boot environment

   $ BUILD=`uname -v | sed s/snv_//`
   $ pfexec pkg refresh
   $ pfexec pkg install SUNWipkg@0.5.11-0.$BUILD
   $ pfexec pkg install entire@0.5.11-0.$BUILD
   

   One thing that I noticed when walking through these instructions was that NWAM had not modified /etc/nsswitch to include dns on the line for hosts. If you have this problem, you can edit the file with "pfexec vi /etc/nsswitch.conf" to fix this if you are unable to resolve pkg.opensolaris.com.

2. Before proceeding to the next step, verify your OpenSolaris build number

   $ echo $BUILD
   

3. If you are running build 93 or greater, you can use "pfexec pkg image-update" and skip the remainder of this page. In this case we are installing from the 2008.05 image which is based on build 86.

4. As you are using a build prior to 93, it is recommended one apply the update directly to an alternate boot environment. First, display the list of the existing BEs on the system

   $ beadm list
   BE         Active Active on Mountpoint Space
   Name       reboot      Used
   ----       ------ --------- ---------- -----
   opensolaris    no        no          - 33.92M
   opensolaris-1 yes       yes          - 17.06M
   

   Next, choose the name of a new BE - if the most recent created BE is of the form "opensolaris-N" where N is an integer, then a suitable choice for the new BE is "opensolaris-{N+1}". In the above example, the new BE would be "opensolaris-2".

   Then, execute the following sequence to create, mount, and update the new BE

   $ pfexec beadm create opensolaris-1
   $ pfexec beadm mount opensolaris-1 /mnt
   $ pfexec pkg -R /mnt image-update
   

5. If you are running build 86 (which you will be if you used the 2008.05 image), one additional work-around is required.

   ********** IMPORTANT **********

   Due to changes in the GRUB boot system, one must manually update the Master Boot Record (MBR) to include these latest changes. Failure to follow these instructions when updating from 2008.05 (build 86) to a later build will result in a system that does not boot by default and instead the original boot environment must be manually selected.

   Update the GRUB configuration on your ZFS boot device(s) using

   $ pfexec /mnt/boot/solaris/bin/update_grub -R /mnt
   

6. Unmount the boot environment you just updated and activate it.

   $ pfexec beadm unmount opensolaris-1
   $ pfexec beadm activate opensolaris-1
   

   When you're ready to boot into the updated boot environment, you can reboot(1M) or init(1M) as usual.

Technorati Tags: OpenSolaris

Posted at 12:27PM Sep 01, 2008 by Alan Hargreaves in OpenSolaris  |  Comments[3]

PSARC 2008/008 DTrace Provider for Bourne Shell

I finally got to submit the fast track for the shell provider. I've already had one comment (from Darren Reed) that I have incorporated as it made very good sense. He suggested that if we are tracking variable assignments, we should also track unset. At this point I realised that a better name for the probes would be variable-set and variable-unset. I have a working copy for SPARC with these changes now.

Below is the prefix text and the revised specification.

I am sponsoring the following fast track for myself. I am doing the
bourne shell first for two primary reasons.

1. It is the "simplest" of the shells and thus should provide the
   minimum set of probes to implement for future work in other shells,
2. Providing probes into /bin/sh gives us observability of
   approximately 60% of all of the scripts on ON.

Additionally, as it has been around for a very long time there are
quite a lot of user written scripts for it, many very badly written.

I would expect future fast tracks for other shells (eg ksh88, ksh93,
zsh, bash, ...) to reference this fast track for the minimum set of
probes.

Note the probes are currently listed as Uncommitted. As the probes
gain use I would hope to log a future fast track to increase this
stability.

A Minor release binding is initially requested. Again, once things
settle down and the interfaces stabilise it is expected that a future
case may request a patch binding.

The sh provider makes available probes that can be used to observe the
behaviour of bourne shell scripts.

Probes
------

The sh provider makes available the following probes as exports:

builtin-entry   Fires on entry to a shell builtin command.
builtin-return  Fires on return from a shell builtin command.
command-entry   Fires when the shell execs an external command.
command-return  Fires on return from an external command.
function-entry  Fires on entry into a shell function.
function-return Pires on return from a shell function.
line            Fires before commands on a particular line of code are
		executed.
subshell-entry  Fires when the shell forks a subshell.
subshell-return Fires on return from a forked subshell.
script-start    Fires before any commands in a script are executed.
script-done     Fires on script exit.
variable-set	Fires on assignment to a variable.
variable-unset	Fires when a variable is unset.

The use of non-empty module or function names in a sh* probe is
undefined at this time.

Arguments
---------

builtin-entry,
command-entry,
function-entry

	char *	args[0]	Script Name
	char *	args[1]	Builtin/Command/Function Name
	int	args[2]	Line Number
	int	args[3]	# Arguments
	char **	args[4]	Pointer to argument list

builtin-return,
command-return,
function-return

	char *	args[0]	Script Name
	char *	args[1]	Builtin/Command/Function Name
	int	args[2]	Return Value

subshell-entry

	char *	args[0]	Script Name
	pid_t	args[1]	Forked Process ID

subshell-return

	char *	args[0]	Script Name
	int	args[1]	Return Value

line

	char *	args[0]	Script Name
	int	args[1]	Line Number

script-start

	char *	args[0]	Script Name

script-done

	char *	args[0]	Script Name
	int	args[1]	Exit Value

variable-set

	char *	args[0]	Script Name
	char *	args[1]	Variable Name
	char *	args[2]	Value

variable-unset

	char *	args[0] Script Name
	char *	args[1]	Variable Name

Examples
--------

1. Catching a variable assignment

	Say we want to determine which line in the following script has
	an assignment to WatchedVar:

	#!/bin/sh

	# starting script
	WatchedVar=Value
	unset WatchedVar
	# ending script

	We could use the following script

	#!/usr/sbin/dtrace -s

	#pragma D option quiet

	sh$target:::line { self->line = arg1; }
	sh$target:::variable-set /copyinstr(arg1) == "WatchedVar"/ {
	        printf("%d: %s=%s\n", self->line, copyinstr(arg1),
		    copyinstr(arg2))
	}
	sh$target:::variable-unset /copyinstr(arg1) == "WatchedVar"/ {
	        printf("%d: unset %s\n", self->line, copyinstr(arg1)); }


	$ ./watch.d -c ./var.sh
	4: WatchedVar=Value
	5: unset WatchedVar

2. Watching the time spent in functions

	#!/usr/sbin/dtrace -s

	#pragma D option quiet

	sh$target:::function-entry { self->start = vtimestamp }
	sh$target:::function-return {
		@[copyinstr(arg1)] = quantize(vtimestamp - self->start)
	}

	Similar for the other entry/return probes, with the exception
	of subshell as the probe name is unavailable.

3. Wasted time using external functions instead of builtins

	This script is copied from the DTrace toolkit. It's function
	and how it works should be relatively self explanatory.

#!/usr/sbin/dtrace -Zs
/*
 * sh_wasted.d - measure Bourne shell elapsed times for "wasted" commands.
 *               Written for the sh DTrace provider.
 *
 * $Id: sh_wasted.d 25 2007-09-12 09:51:58Z brendan $
 *
 * USAGE: sh_wasted.d { -p PID | -c cmd }       # hit Ctrl-C to end
 *
 * This script measures "wasted" commands - those which are called externally
 * but are in fact builtins to the shell. Ever seen a script which calls
 * /usr/bin/echo needlessly? This script measures that cost.
 *
 * FIELDS:
 *              FILE            Filename of the shell or shellscript
 *              NAME            Name of call
 *              TIME            Total elapsed time for calls (us)
 *
 * IDEA: Mike Shapiro
 *
 * Filename and call names are printed if available.
 *
 * COPYRIGHT: Copyright (c) 2007 Brendan Gregg.
 *
 * CDDL HEADER START
 *
 *  The contents of this file are subject to the terms of the
 *  Common Development and Distribution License, Version 1.0 only
 *  (the "License").  You may not use this file except in compliance
 *  with the License.
 *
 *  You can obtain a copy of the license at Docs/cddl1.txt
 *  or http://www.opensolaris.org/os/licensing.
 *  See the License for the specific language governing permissions
 *  and limitations under the License.
 *
 * CDDL HEADER END
 *
 * 09-Sep-2007  Brendan Gregg   Created this.
 */

#pragma D option quiet

dtrace:::BEGIN
{
        isbuiltin["echo"] = 1;
        isbuiltin["test"] = 1;
        /* add builtins here */

        printf("Tracing... Hit Ctrl-C to end.\n");
        self->start = timestamp;
}

sh$target:::command-entry
{
        self->command = timestamp;
}

sh$target:::command-return
{
        this->elapsed = timestamp - self->command;
        this->path = copyinstr(arg1);
        this->cmd = basename(this->path);
}

sh$target:::command-return
/self->command && !isbuiltin[this->cmd]/
{
        @types_cmd[basename(copyinstr(arg0)), this->path] = sum(this->elapsed);
        self->command = 0;
}

sh$target:::command-return
/self->command/
{
        @types_wasted[basename(copyinstr(arg0)), this->path] =
            sum(this->elapsed);
        self->command = 0;
}

proc:::exit
/pid == $target/
{
        exit(0);
}

dtrace:::END
{
        this->elapsed = (timestamp - self->start) / 1000;
        printf("Script duration: %d us\n", this->elapsed);

        normalize(@types_cmd, 1000);
        printf("\nExternal command elapsed times,\n");
        printf("   %-30s %-22s %8s\n", "FILE", "NAME", "TIME(us)");
        printa("   %-30s %-22s %@8d\n", @types_cmd);

        normalize(@types_wasted, 1000);
        printf("\nWasted command elapsed times,\n");
        printf("   %-30s %-22s %8s\n", "FILE", "NAME", "TIME(us)");
        printa("   %-30s %-22s %@8d\n", @types_wasted);
}


Stability
---------

Element Name    Class           Data Class
------------------------------------------
Provider        Uncommited      Uncommited
Module          Private         Private
Function        Private         Private
Name            Uncommited      Uncommited
Arguments       Uncommited      Uncommited
------------------------------------------

Technorati Tags: Solaris, OpenSolaris, DTrace

Posted at 09:27AM Jan 09, 2008 by Alan Hargreaves in OpenSolaris  | 

Sun Developer Days

OK, I got back from CEC on Saturday a week back and walked into the house at about 9:30 absolutely knackered. About 2pm my pager went off and I discovered that I was on VOSJEC duty that weekend and ended up with a righht horror of a call that lasted the rest of the weekend (that I won't go into detail here with, save to say that I got an action plan out to these ghuys at about 00:30 on Monday morning.

Early Monday morning (ok I did get some sleep, this is real morning about 10-11), I got a call from Laurie Wong. Apparantly the DTrace speaker they had organised for the Developer Days couldn't make it and they really couldn't find anyone else. After some discussion with my boss, we agreed that I would go fly to Melbourne the next day to cover this and also cover Sydney on Wednesday.

Had an awful time actually using the system that we are supposed to use to book the flight, ended up taking me a bit over an hour and by that time the fare had risen 50% !!! Anyway got that all sorted and boy am I glad that I booked to get my self well ahead of when I spoke.

First off, I was using someone else's slides, so of course I had to work out what I was going to say to each one (I use flash cards to remind me of what I want to talk about so I'm not just reading the slides). Going through the slides I noticed that the information on the javascript provider was actually out of date. Indeed, you can actually download a firefox 3.0 alpha that has the new provider in there and looks pretty damned spiffy. So, I updated that stuff, then I discovered that there were actually two sections of the talk not present in the slides. This was the "tie it all together" bit and the summary. Well I didn't have the time to write a "tie it all together bit", so I removed that from the agenda slide and did up an "in conclusion" slide.

The other part of being glad I booked an earlier flight is that even though we boarded close to time, we were about an hour late getting off the runway! I got in to Melbourne at about midday. Fortunately we were able to put another speaker in front of me so I could finish writing the talk which I ended up giving at 4pm.

Anyway, the talk covered some background on DTrace (and the slide author provided some really nice graphics and animations), and discussion of various providers. In particular I talked about PHP, javascript, and postgresQL. I did demos for some of the basic DTrace, javascript and postgreSQL.

I Also touched on the shell provider I'm working on and encouraged folks to get involved with working on and testing new providers.

Amazingly, without having timed this or even thought about the length, I managed to finish exactly on time.

Laurie took me into the QANTAS lounge where we were able to relax a little before the flight home. With the flight and the train trip I got home about midnight.

The next day was in Sydney, so I only needed to take the train into the city.

After finding the venue (google maps on a treo 750 is really useful!), I sat in on a couple of the other talks and quite enjoyed those. In Sydney my talk was at 3:15 and again went pretty well.

Headed home after being treated to a really nice dinner at Doyle's on the Harbour.

Unfortunately I had a prior commitment on Friday so I couldn't give the talk in Canberra.

These were probably the largest audiences that I have ever presented to (combining both talks I spoke to about 580 people). I actually enjoyed it and I think my audience had a bit of fun as well. It's nice to do this kind of thing every so often.

Technorati Tags: Solaris, OpenSolaris, DTrace

Posted at 10:13AM Oct 23, 2007 by Alan Hargreaves in OpenSolaris  | 

sh provider update - command-entry fixed

I've just uploaded the latest diffs and binaries to www.opensolaris.org/os/community/dtrace/shells/.

So what changed?

There was a bug in that the command-entry probe fired in both parent and child shell. This was a simple oversight that I should not have missed. I originally had the probe before sh forked, then moved it such that it fired after we knew we were able to fork (basically I didn't want it firing if we were not able to actually fork and run the command). Unfortunately, I forgot to specify that it was only to fire in the parent shell. Simple fix. My bad.

Also note that the documentation on the Providers for various shells site supercedes what I previously wrote in my blog.

I haven't tested the diffs, but I did the same massaging to them that I did for the last lot, so they should be ok to use with gpatch.

Looks like things are starting to settle down now so I'll be able to think about progressing this one and starting to look at some others, using these probe names as some kind of standardisation.

There have been suggestions for extras in this provider, but the feeling that I'm getting is let's get a basic useful provider done as a v1.0 and look at things like stacks and other probes in a later update.

Technorati Tags: Solaris, OpenSolaris, DTrace

Posted at 07:08PM Aug 20, 2007 by Alan Hargreaves in OpenSolaris  | 

sh provider update (changes and sparc available)

After discussions with Brendan and Adam, I've made a couple of changes to the provider.

1. exec has been renamed to command, and

2. script-begin and script-end have become script-start and script-done respectively.

These changes are reflected in the documentation that is available at www.opensolaris.org/os/community/dtrace/shells/

In addition, I have rebuilt the x86 binary with this changes and provided a SPARC binary.

Technorati Tags: Solaris, OpenSolaris, DTrace

Posted at 11:59AM Aug 15, 2007 by Alan Hargreaves in OpenSolaris  | 

sh DTrace provider diffs and x86 binary available

The title says it all. I've uploaded the diffs and an x86 sh binary to the "Providers for various shells" page. I'll do up a SPARC binary if there is interest in it.

Note that the arguments for the entry probes for builtin, exec and function have changed. There is a link to the correct documentation on this page too.

Have fun playing folks and let me know if you find any bugs.

Technorati Tags: Solaris, OpenSolaris, DTrace

Posted at 12:19PM Aug 14, 2007 by Alan Hargreaves in OpenSolaris  |  Comments[4]

Why did I do a sh provider first?

Since I posted my initial blog on this, I've received a few comments and a surprising amount of mail asking why I did /bin/sh, which is an obviously obsolete shell, and not ksh93; some of it bordering on insulting.

Let me go through a few reasons why I did this one first.

1. It's the one I was asked to do.

2. The Bourne shell has been around for a very long time and there are, quite literally, millions of scripts that have been written in it, some of them very poorly so.

3. Much work in the open source environment is done to scratch an itch. In my day to day work doing performance calls I come across an amazing number of instances where being able to probe /bin/sh the way that this allows me to, would be an incredibly useful thing to have in order to explain to a customer why their thrown together script runs so slowly, most of these are /bin/sh scripts. Coding probes for ksh93 has no immediate impact on my day to day work as ksh93 is not yet integrated into OpenSolaris.

4. Just doing a quick poll of usr/src in the opensolaris tree gives me the following:

   Scripting Language	Actual scripts	Dynamically created scripts	Comments
   /bin/sh	463	538
   /usr/bin/sh	39	43	/bin symlinked to /usr/bin
   /sbin/sh	186	272	symlink to /bin/sh
   /bin/ksh	212	199
   /usr/bin/ksh	53	50	/bin symlinked to /usr/bin
   /bin/perl	13	9
   /usr/bin/perl	241	237	/bin symlinked to /usr/bin
   ksh93	0	0

5. sh is a logical first step from which other providers can follow.

6. ksh93 is currently on a track to get integrated. I really don't want to drop any roadblocks on it now.

7. Does it really matter which one comes first?

At no point did I say I would not consider doing ksh93 or even helping someone else do it, indeed I have had communication with Roland suggesting ways in which this could be done. Believe it or not, there is a plan to get all the shells done. Keep an eye on http://www.opensolaris.org/os/community/dtrace/shells/.

The last thing I expected when I started on this was to be the target of insults because I didn't do someone's favorite shell. I'm wondering how this kind of behavior encourages anyone to actually do anything that is of any benefit to the community. Come on folks, we can do better than that.

Technorati Tags: Solaris, OpenSolaris, DTrace

Posted at 11:07AM Aug 14, 2007 by Alan Hargreaves in OpenSolaris  |  Comments[9]

/bin/sh DTrace Provider

A couple of days ago Brendan was chatting with me on irc and we got to discussing such a beast. Mainly looking at something simple in the way of the python and perl providers that others have worked on.

Well, to make a long story short (ok it will be longer later), I've coded up something that appears to work against the nevada clone tree of a couple of days ago, and logged RFE 6591476 to track it.

I'll be putting the diffs up in the next day or so, but for a teaser, here is the documentation.

sh Provider

The sh provider makes available probes that can be used to observe the behaviour of bourne shell scripts.

Overview

The sh provider makes available the following probes:

builtin-entry	Probe that fires on entry to a shell builtin command.
builtin-return	Probe that fires on return from a shell builtin command.
exec-entry	Probe that fires when the shell execs an external command.
exec-return	Probe that fires on return from an external command.
function-entry	Probe that fires on entry into a shell function.
function-return	Probe that fires on return from a shell function.
line	Probe that fires before commands on a particular line of code are executed.
subshell-entry	Probe that fires when the shell forks a subshell.
subshell-return	Probe that fires on return from a forked subshell.
script-begin	Probe that fires before any commands in a script are executed.
script-end	Probe that fires on script exit.

Arguments

The argument types to the sh provider are listed in the below table.

Probe	args[0]	args[1]	args[2]	args[3]
builtin-entry, exec-entry, function-entry	char *	char *	int	char **
builtin-return, exec-return, function-return	char *	char *	int
line	char *	int
script-begin	char *
script-end	char *	int
subshell-entry	char *	pid_t
subshell-return	char *	int

arg0 in all probes is the script name.

In the builtin, exec, and function entry probes, and the builtin, exec, and function return probes, arg1 is the name of the function, builtin or program being called. arg2 and arg3 in these entry probes are the argument count and a pointer to the argument list. In these return probes, arg2 is the return code from the function, builtin or program.

In the subshell-entry, arg1 is the pid of the forked subshell and in subshell-return probes, arg1 is the return code from the subshell.

In the line probe, arg1 is the line number.

In the script-end probe, arg1 is the exit code of the script.

Stability

The sh provider uses DTrace's stability mechanism to describe its stabilities, as shown in the following table. For more information on the stability mechanism see Chapter 39 of the Solaris Dynamic Tracing guide.

Element	Name Class	Data Class	Dependancy Class
Provider	Unstable	Unstable	Common
Module	Private	Private	Unknown
Function	Private	Private	Unknown
Name	Unstable	Unstable	Common
Arguments	Unstable	Unstable	Common

The probes that gave me the most trouble were line and subshell-*.

line was tricky as sh only does line numbers when it parses input. It has no concept of line numbers on execution, which is what we need.

So, I needed to add another structure element (line) to trenod, and every other struct that is cast over the top of it. In the first failed attempt, I set this to standin->flin whenever we allocated a new one of these nodes, I set line to this value. The problem with this is that if the parser hits a newline, this number gets incremented before we actually set it, which means that the last command on every line has the line number of the following line. Not quite what I wanted.

What I ended up going with was the creation of another variable in the fileblk structure (comline) that I set just before standin->flin is incremented. This looks like it works.

The subshell-* probes were not initially going to be a part of this, but an assumption I made about com in execute() when coding the exec-* probes ended up causing the shell to coredump on me. It turns out that com is properly defined when we fall through the switch to the TFORK code, but if we go directly into the TFORK case, it's something completely different (would you believe "1"?). So, I made the probe conditional on the node type. If it was a TFORK, then we do a subshell probe, otherwise we do an exec probe. This also appears to work.

In the meanwhile, I've been sending Brendan sh binaries and he's already started coding more tools for the DTrace Toolkit based on this provider, and I have to say that some of his ideas look pretty cool.

Technorati Tags: Solaris, OpenSolaris, DTrace

Posted at 09:03PM Aug 10, 2007 by Alan Hargreaves in OpenSolaris  |  Comments[7]

Finding undocumented command options

I had a colleague this morning asking about undocumented (ie not listed in usage or man pages) options in a command. The actual command doesn't really matter, but I was feeling a little lazy and couldn't bothered looking up the source code to the command (which actually wasn't in ON). Almost immediately I thought of DTrace.

Let's have a look at ls as an example. I'll give it a dummy directory as I really don't care about the output.

$ dtrace -q -n 'pid$target::getopt:entry {trace(copyinstr(arg2));}' -c 'ls /nosuchfile'                     
/nosuchfile: No such file or directory
aAbcCdeEfFghHilLmnopqrRsStux1@vV

As you can see, the second line of output is printing out the third argument (arg2) to getopt(3c), which will list every option that getopt(3c) will recognise for the command.

Of course I could have prettied it up, but it's a one liner, I know what the output means.

The point being, that DTrace is just another sysadmin tool to be used in day to day operations.

Technorati Tags: Solaris, OpenSolaris, DTrace

Yes I know I have been lax in my blogging, I'm going to start doing something about that, starting with this one :-)

Posted at 11:47AM Aug 08, 2007 by Alan Hargreaves in OpenSolaris  |