Desktop Summit which is made up of GUADEC and AKademy will be held this year in the Gran Canaria from 3rd-11th July. This is by far the biggest events on its nature, FOSS and totally Desktop oriented.

I will be arriving on the 2nd July evening with the whole bunch from the Desktop group in Sun. Now that some of the people, Alberto, Luis are native Canarians. I am looking forwards to their local hospitality Also we meet up hackers old and new.

Many of the exciting talks including GNOME Shell, GNOME 3.0, Mobile Development are so exciting topics that I look forward to hear and see! I will be there until 9th July.

I had the privilege to be a guest on FLOSS Weekly with Leo Laporte and Jono Bacon this week, thanks guys! Of course Aaron and David had done awesome groundwork with an interview on ZFS a few weeks earlier. It was a fun hour, and I enjoyed it though can think of many thing I’d answer differently now! Looking forward to catching up with Jono and others at the Community Leadership Summit next month in San Jose, the weekend before OSCON.

And yes, OpenSolaris is officially ‘not bollocks’. Check it out!

Sun Learning Services are in the process of creating a number of patch related training lessons.

They've launched a blog, which contains the initial introductory videos.

Future lessons will be much more detailed, concentrating for example on Live Upgrade.   These lessons will be available on the Sun Open Learning Center (SOLC) website: https://learning.sun.com/solc/smartstart.

I'd like to give you a heads-up on a couple of Kernel patch installation issues which we're currently investigating.

1. There looks like there's a bug in the Deferred Activation Patching functionality in a ZFS Root environment.   An error message to the effect that a Class Action Script has failed to complete and failure to set up environment for Deferred Activation Patching may be seen.   The relevant CR is 6850329: "KU 139556-08 fails to apply on x86 systems that have ZFS root filesystems and corrupts the OS".    It's possible that SPARC systems are similarly affected.  The following error message is returned:

mv: cannot rename /var/run/.patchSafeMode/root/lib/libc.so.1.20102 to /lib/libc.so.1: Device busy
ERROR: Move of /var/run/.patchSafeMode/root/lib/libc.so.1.20102 to dstActual failed
usage: puttext [-r rmarg] [-l lmarg] string
pkgadd: ERROR: class action script did not complete successfully

Installation of <SUNWcslr> failed.

There are several workarounds to avoid the issue:

1. Apply KU 139556-08 to an inactive boot environment, either using LiveUpgrade or via boot net/cdrom
2. Manually umount /lib/libc.so.1 BEFORE applying KU 139556-08
3. One more way to apply to inactive boot environment is to boot into failsafe mode, mount root pool on /a and apply KU to /a

The principal reason ZFS Root support was implemented in LiveUpgrade is so that patch application like this to the live boot environment would not be necessary. With ZFS Root, creating a clone BE is so easy that there's no good reason not to. 

2. There are reproducible issues using jumpstart finish scripts and other scenarios to install Kernel patch 137137-09 followed by Kernel patch 139555-08.   Here's the gist of the issue which I've pulled from an engineering email thread on the subject:

Issue 1: I have a customer whose system is not booting after applying the patch cluster with Live Upgrade (LU).

Solution 1: If using 'luupgrade -t', then you must ensure that latest version of LU patch is installed first, currently 121430-36 is currently the latest revision on SPARC, 121431-37 on x86. Once thse patches are installed, LU will automatically handle the build of the bootarchive when 'luactivate' is called, thus avoiding the problem.

Issue 2: There are other ways to get oneself into situations where a boot-archive is out of sync: e.g. If using jumsptart finish scripts to apply patches that include 137137-09.  Basically any operation that invovles patching to an ABE outside of 'luupgrade' will invovle a manual build of boot-archive.

Solution 2: One must manually rebuild the boot-archive on the /a partiton after applying the patches.  Otherwise once the system boots, the boot-archive will be out of sync.

Here's some more detail on the jumpstart finish script version of this: 

We've seen the same panic a few times when the latest patch cluster is applied via a finish script to a boot environment prior to  s10u6 via a jumpstart installation. It appears that the boot archive is out of sync with the kernel on the system. The boot archive was created from the 137137-09 patch and not updated after the 139555-08 kernel was applied, therefore the mismatch between the kernel and the boot archive.

In these instances updating the boot archive allows the system to boot successfully. Boot failsafe (ok boot -F failsafe) will detect an out of sync boot archive.  Execute the automated update then reboot. This will now boot from the later kernel (139555-08) which successfully installed from the finish script.

I reproduced the problem in a jumpstart installation environment applying the latest 10_Recommended patch cluster from a finish script. The initial installation was s10u5 which is deployed from a miniroot that has no knowledge of a boot archive (my theory anyway).  This is similar to a live upgrade environment if the boot environment doing the patching is also boot archive unaware (meaning the kernel is pre 137137-09).

In the jumpstart scenario the immediate problem was solved by updating the boot archive by booting failsafe as previously described.  The Solution was to update the boot archive from the finish script after the patch cluster installation completed.  BTW, all patches in the patch cluster installed successfully per the /var/sadm/system/logs.finish.log.

In a standard jumpstart the boot device (install target) is mounted to /a, therefore adding the following entry to the finish script solved the problem:

/a/boot/solaris/bin/create_ramdisk -R /a

Depending on the finish script configuration, and variables the following would also work:

$ROOTDIR/boot/solaris/bin/create_ramdisk -R $ROOTDIR

Issue 3: This above issues are sometimes misdiagnozed as CR 6850202: "bootadm fails to build bootarchive in certain configurations leading to unbootable system".

But CR 6850202 will only be encountered in very specific circumstances, all of which must occur in order to hit this specific bug, namely:

1. Install u6 SUNWCreq - there's  no mkisofs so we build ufs boot archive

2. Limit /tmp to 512M - thus forcing the ufs build to happen in /var/run

3. Have a separate /var - bootadm.c only lofs nosub mounts "/" when creating the alt root for DAP patching build of boot archive

4. Install 139555-08

You must have all 4 of above in order to hit this, i.e. step 4 must be installing a DAP patch such as a Kernel patch associated with a Solaris 10 Update such as 139555-08. 

Solution 3: Removing the 512MB limit (or whatever limit has been imposed) to /tmp in /etc/vfstab and/or adding SUNWmkcd (and probably SUNWmkcdS) so that mkisofs is available on the system is sufficient to avoid the code path that fails this way.

Booting failsafe and recreating the boot archive will successfully recreate the boot archive.

Best Wishes,

Gerry.

I think I'm about done with the next release. Here's the Changelog entry:

0.12

• Add event-based snapshots
• Add support to change the separator character in snapshot names
• set the default value of "zfs/sep" to "_"
• useful for CIFs clients that previously choked on colons in snapshot names
• Improved shutdown speed via http://blogs.sun.com/dp/entry/speeding_to_a_halt
• Add support to allow the user disable auto-snapshots of new pools
• Bugfix to allow snapshots of datasets with spaces in their names
• Bugfix to properly deal with namespace clashes in dataset names
• Exported $LAST_SNAP and $PREV_SNAP variables when performing backups
• useful to things like the "zfs-backup-to-s3" project on kenai.com

The main new thing here is the "event-based-snapshot" instance, as described in the README and Defect 9595. It's nothing earth shattering, but a useful feature I think.

I've found that in my day to day use of OpenSolaris, I tend to take the lazy option of running "zfs snapshot -r rpool@snap" whenever I'm about to do something to the system that I might regret later, and don't want to wait for the 15 minute ":frequent" instance to fire. Later, I go to run the same thing again, and find I've already got a snapshot called rpool@snap, so I take a new one, rpool@snap2 - can you tell where this is going?

Eventually, I find myself out of disk-space and with no real clue what was interesting about rpool@snapn in the first place. I torch the snapshots and get on with life. So far, this has worked just fine, but it's a bit manual and results in us snapshotting rpool/swap and rpool/dump, and I don't really want that.

Some of the stuff Erwann added for 2009.06 helps a bit - with the "snapshot this directory" button in Nautilus, we could take a snapshot of a single dataset, but it doesn't group them, and still leaves the name of the snapshot as the only place to describe the snapshot contents.

So, my solution was to add the svc:/system/filesystem/zfs/auto-snapshot:event instance. Most of the code for this was in 0.11, but I'm now including a manifest that uses it. This service isn't managed using cron, instead you get to manually run run the method script each time you want to take a snapshot. You also have to option of supplying a description that gets stored into a user property on the snapshot, com.sun:auto-snapshot-desc (feel free to go all "Web 2.0" here, and add #hashtags if you want!)

Where this wins over a simple "zfs snapshot -r rpool@snap" is that it uses the com.sun:auto-snapshot properties used by the other instances to determine which datasets we want to take snapshots of (and can be overridden by com.sun:auto-snapshot:event).

I've hacked together a (flawed) GUI that I've added as a launcher on my GNOME panel which shows a Zenity dialog box asking for a description of the snapshot, runs the method script, then pops up a notification once the snapshots have been taken. I've not included this in the package, since I'm sure someone will do a better job of it, but download from here if you want it. Obviously this is but one use for event-based snapshots: if you set the zfs/backup-save-cmd SMF property on that instance, you'd have a 1-click "backup my stuff" button! :-)

More of my awesome GUI skills...

The snapshot event notification popup

As ever, the README also documents these changes, and you can get the sources and build yourself a package via:

$ hg clone ssh://anon@hg.opensolaris.org/hg/jds/zfs-snapshot

I'm not sure when these changes will land in OpenSolaris - there'll be a 0.12.1 release as soon as I get to write support for the 'zfs list -d' command that Chris added for the bug I filed 6762432, so perhaps we'll wait for that (I thought it polite to wait till everyone was able to run a version of OpenSolaris that included that fix before making the changes).

Comments welcome here, or on the zfs-auto-snapshot mailing list

This is a neat idea (if not technically all that novel)... log in to Sun Learning Services portal, and you can play with a virtual instance of OpenSolaris for up to an hour.

It does require Java, there are only 8 slots available at any one time, and right now they're still provisioning OpenSolaris 2008.11 rather than the newer and shinier 2009.06. But if you want to give OpenSolaris a quick whirl, you might find it more convenient than downloading the LiveCD.

More info in Brian Leonard's blog entry.

This is a neat idea (if not technically all that novel)… log in to Sun Learning Services portal, and you can play with a virtual instance of OpenSolaris for up to an hour.

It does require Java, there are only 8 slots available at any one time, and right now they’re still provisioning OpenSolaris 2008.11 rather than the newer and shinier 2009.06. But if you want to give OpenSolaris a quick whirl, you might find it more convenient than downloading the LiveCD.

More info in Brian Leonard’s blog entry.

The Zones Parallel Patching enhancement for the Solaris 10 patch utilities was released this week giving customers a choice of how to improve zones patching performance.

In the Zones "Update On Attach" section of a previous blog posting, I mentioned that the Zones "Update On Attach" feature could also be used to improve Zones patching perfomance.

Zones Parallel Patching is a true patching solution utilizing the 'patchadd' utility.  

Whereas Zones "Update On Attach" uses zones functionality similar to that used during zones creation to provide a pseudo-patching solution that does not utilize 'patchadd'. 

So which one to choose ?

Let's look at the two options in more detail:

Zones Parallel Patching

Zones Parallel Patching is an enhancement to the standard Solaris 10 patch utilities and is delivered in the patch utilities patch, 119254-66 (SPARC) and 119255-66 (x86).

Simply install this patch, set the maximum number of non-global zones to be patched in parallel in the config file /etc/patch/pdo.conf, and away you go.

It works for all Solaris 10 systems. 

It also works well in conjunction with higher level patch automation tools such as xVM Ops Center. 

It can dramatically improve zones patching performance by patching non-global zones in parallel.  The global zone is still patched first.

While the performance gain is dependent on a number of factors, including the number of non-global zones, the number of on-line CPUs, the speed of the system, the I/O configuration of the system, etc., a performance gain of ca. 300% can typically be expected for patching the non-global zones - e.g. On a T2000 with 5 sparse root non-global zones.

See my previous Zones Parallel Patching blog entry for further information.

Since it's a pure enhancement to 'patchadd', it's normal 'patchadd' functionality.  You can subsequently remove patches using 'patchrm', etc.  Nothing has changed except that it's now much faster to patch non global Zones with Zones Parallel Patching invoked.

Zones "Update On Attach"

The primary purpose of Zones "Update on Attach" is Zones migration from one server to another.  

For example, a database instance in a non-global zone hosted on a server has grown to the extent that the Sys Admin wants to transfer it to a better spec'd server which can better handle the workload.   The Sys Admin can detach it from the old server (e.g. a Sun4u) and reattach it to the new server (e.g. a Sun4v) using Zones "Update On Attach".   This will bring the OS Software level on the non-global zone up to the same level as the new server's global zone.

Zones "Update On Attach" can certainly be used for patching but there are limitations you need to be aware of as outlined below.

For example, detach the non-global zones from a system, apply a bunch of patches to the global zone, reattach the non-global zones using "Update On Attach" and viola, the non-global zones will be brought up to the same software level as the global zone (for OS type packages), effectively patching the non-global zones without using 'patchadd' at all.   This is typically even faster than using Zones Parallel Patching.  But there are limitations to this approach which users must be aware of (see below).

My senior engineer, Enda O'Connor, has just published an interesting article on The Zones Update on Attach Feature and Patching in the Solaris 10 OS. 

Zones "Update On Attach" limitations as a patching aid

Zones "Update On Attach" only works for packages which are SUNW_PKG_ALLZONES=true - i.e. typically OS level packages, and not application packages.

So when to use Zones Parallel Patching in 'patchadd' and when to use Zones "Update On Attach" ?

Here's what my senior engineer, Enda O'Connor, says:

"The Zones Update on Attach Feature and Patching in the Solaris 10 OS document may help customers understand how the technology works, applying a cluster via patching and via zones Update On Attach is not quite the same really.

It really depends on the patches being applied, i.e. applying a firefox patch via Update On Attach would not work if you wanted it to apply to the global zone and all non-global zones as well.

One has to understand how Update On Attach works and then apply that to the list of patches to see if it gets them to a desirable state.

There is no black or white answer here.

I'd recommend Zones Parallel Patching using 'patchadd' as it has a known outcome all the time, whereas Update On Attach makes it's own internal determination based on a number of things, that can vary from system to system ( e.g. inherited directories ).

But if time to patch is critical then if the customer does proper testing to validate things, and are happy with the results, then by all means use Update On Attach.

But using Update On Attach without:

1. Understanding how it determines what packages to update

2. Not inspecting the patches being applied.

...will most likely lead to grief at some point."

And my other senior engineer, Ed Clark, says:

"In terms of giving guidance on which technology to use, there are a number of considerations -- two of these considerations are:

1. Using Update On Attach to update sparse zones can require significantly more disk storage space than would be needed by applying patches with 'patchadd' (3-4 times as much space would not be uncommon i think), due to Update On Attach copying fully populated global zone 'undo' files into the non-global zones, as opposed to having patchadd build sparsely populated 'undo' files in the non-global zones.

2. If a customer is really concerned about the ability to back out patches reliably, then 'patchadd' is a lower risk option than Update On Attach -- 'patchrm' of a patch from a non-global zone that has a copy of the global zones 'undo' pkg data (as is the case after Update On Attach) may potentially have unexpected side effects." [although we have yet to see any actual cases of negative results from this.]

Conclusion

In general, we recommend using the Zones Parallel Patching enhancement in the patch utilities rather than the Zones "Update On Attach" feature as Zones Parallel Patching is standard patching functionality, only faster, whereas Zones "Update On Attach" is really designed for migrating zones from one server as another and was not primarily designed to speed up patching.  

Because Zones "Update On Attach" uses Zones functionality similar to the zone creation functionality, rather than 'patchadd' functionality, limitations exist on what will be patched (typically the OS but not applications) and there's the potential for anomalies around things like the "undo" files which would be used by 'patchrm' if patches applied using Zones "Update On Attach" were subsequently removed from the non-global zones using 'patchrm' (although we have yet to see any actual cases of serious issues resulting from this).

So in patching situations where time is absolutely critical, Zones "Update On Attach" may provide a good option, as long as it's well tested in the customer environment prior to deployment on production systems.

Remember too, Live Upgrade is also your friend in such situations, enabling you to patch an inactive boot environment while the system is still in production.   So a combination of Live Upgrade and Zones Parallel Patching would be ideal.

I hope you find this helpful!

Best Wishes,

Gerry.

The Solaris 10 5/09 (Update 7) patch bundle is now available for download from the SunSolve Patch Cluster & Patch Bundle Download Page.  Click on the "Solaris Update Patch Bundles" link.

As with previous patch bundles, it contains the patches which are included in the corresponding Solaris Update, in this case Solaris 10 5/09 (Update 7).

This is useful for Sys Admins who wish to bring all their systems up to the same patch level as the Solaris Update without wanting to upgrade to the release - for example, due to change control policy restrictions in their organizations.

See previous blog entries for previous Solaris Update patch bundles for further information.

The Zones Parallel Patching feature is now available in the latest Solaris 10 patch utilities patch, 119254-66 (SPARC) and 119255-66 (x86).

This is available for use on all Solaris 10 systems. 

Simply install this patch, set the maximum number of non-global zones to be patched in parallel in the config file /etc/patch/pdo.conf, and away you go.

Prior to this feature, each non-global zone was patched sequentially, leading to unnecessarily long patching times for zones systems.  (Sequential patching remains the default behavior unless the config file is edited to enable Zones Parallel Patching.)

With this feature invoked, the global zone continues to be patched first, but then the non-global zones can be patched in parallel, leading to significant performance gains in patching operations on Zones systems.

While the performance gain is dependent on a number of factors, including the number of non-global zones, the number of on-line CPUs, the speed of the system, the I/O configuration of the system, etc., a performance gain of ca. 300% can typically be expected for patching the non-global zones - e.g. On a T2000 with 5 sparse root non-global zones.

Here's the relevant note from the patch README file:

NOTE 10: 119255-66 is the first revision of the patch utilities to deliver "zones parallel patching".
          This new functionality allows multiple non-global zones to be patched in parallel by patchadd.
          Prior to revision 66, patchadd would patch all applicable non-global zones sequentially,
          that is one after another. With zones parallel patching, a sysadmin can now set the number
          of zones to patch in parallel in a new configuration file for patchadd called /etc/patch/pdo.conf.

         The two factors that affect the number of non-global zones that can be patched in parallel are
         1. Number of on-line CPUs
         2. The value of num_proc in /etc/patch/pdo.conf

          If the value of num_proc is less than or equal to 1.5 times the number of on line CPUs,
          then patchadd limits the maximum number of non-global zones that will be patched in
          parallel to num_proc. If the value of num_proc is greater than 1.5 times the number of on line CPUs,
          then patchadd limits the maximum number of non-global zones that will be patched in parallel
          to 1.5 times the number of on line CPUs. Note that patchadd will patch all applicable non-global
          zones on a system, the above description outlines only how patchaadd determines the
          maximum number of job slots to be used during parallel patching of non-global zones.

          An example of this in operation would be where:
          num_proc=8
          and number of on line CPU's is 4

          In this case the maximum setting for num_proc would be 6, that is the maximum number
          of zones that could be patched in parallel is 6.  If there are more than this number of non-global zones on the
          system, the first 6 will be patched in parallel, then the remaining non-global zones will be patched
          as processes finish patching the first 6 non-global zones.   Only one patch process will be used for each
          non-global zone, so if there are less than 6 non-global zones on the system, then only the number of processes
          equal to the number of non-global zones will be initiated.

          Please see comments in /etc/patch/pdo.conf for more details on setting num_proc.

I would like to thank Ed Clark and Enda O'Connor from my own team for all their work in developing and testing Zones Parallel Patching.

I would also like to thank Jon Bowman, Arindam Sarkar, and the rest of the RPE (Sustaining) Install team for all their work in getting this feature integrated into the patch utilities and delivered to production.

I would also like to thank our selected key customers who kindly Beta tested the feature for us.

I believe this feature is an important milestone in improving our customers' patching experience in a Zones environment as it addresses a long standing customer complaint on Zones patching performance.

Enjoy!

Over at The Observatory, Brian Leonard posted more information on how to use the compare feature I implemented in the file version explorer of Time-slider.

Thanks Brian :) 

In the next version the compare feature will get even more interesting, if time permits ! Watch this space...

Some of the work I've done recently involved some changes to virt-install(1) to teach it how to install xVM guests from OpenSolaris AI servers - work that you'll see going back soon as a patch to virt-install as part of our xVM 3.3 changes.

This ended up shaking a few bugs out of AI and OpenSolaris, two of which became stoppers for the 2009.06 release (which made for a rather exciting weekend) one was fixed, the other was documented in the release notes.

Along the way though, and the point of this blog post, I got to learn a bit more about OpenSolaris and the boot process when we're using AI and what to do when things go wrong.

For x86 (the only thing I really cared about in my case, sparc differs slightly) AI works by downloading the kernel and a very small boot archive via pxe and tftp. The client then boots with this image and the svc:/system/filesystem/root:live-media SMF service arranges to download solaris.zlib and solarismisc.zlib files, and mounts them on the client.

However, should that service fail for some reason - we're left with a pretty unfriendly OpenSolaris environment. There's a tradeoff between fast/low memory installs and easy-to-debug environments so it's a tough one to call.

However, if you do need to debug stuff early in boot with an AI image, I added a comment to Defect 6851 that explains how you do it. This came from an email I was writing to a colleague today who was running into the same problem - I figured posting those comments to the bug report and writing this short blog post would be a good thing to do. Hope this helps someone out there?

We just announced the Call for Miniconfs for LCA 2010 in Wellington, New Zealand next year! Miniconfs are an excellent way of having a full day of great sessions for a specific topic - examples of previous miniconfs are Debian, MythTV and of course near and dear to my own heart, GNOME.

For LCA 2010, we will have twelve Miniconfs over the course of 2 days, 6 per day. While you wait for the call for papers to open later this month, start your braincells and Submit a Miniconf Proposal! Read the announcement for more details.

This is a big day for technophiles as well as technologically nostalgic. An analog TV broadcast standard which has maintained compatibility for 68 years will end today. A B&W TV designed around the 1941 NTSC standard would have been able to display some broadcasts on channels 2-13 yesterday. A color TV designed around the 1953 standard would have displayed some broadcasts in color yesterday. For anyone who appreciates the engineering required to progress technology while maintaining backwards compatibility, the story of the NTSC compatible color standard is interesting. I'm surprised that modern technology and ingenuity couldn't have kept ATSC (DTV) compatible with NTSC for another decade. This would have been more than long enough for internet video to make DTV obsolete. But despite the 'generous' (taxpayer funded) converter box subsidy, planned obsolescence and DRM trumps consumer convenience and compatibility.

As the earliest color TV standard, NTSC was getting a bit long in the tooth. It earned a reputation for failing to be as good as the newer PAL or SECAM standards. It was said that NTSC stood for "Never The Same Color" or "Never Twice Same Color". It's unlikely that accurate color's reliance on phase stability over a scan line would have made it possible to do this PAL trick of restoring a color video from a B&W film of a TV screen.

As with any technological change, there are advantages and unexpected disadvantages. ATSC's advantages are obvious:

• Higher resolution, more stable, accurate color.
• It frees bandwidth for other services.
• Resolution is high enough to be used as a computer text display.
• More people will receive a perfect picture.

Some of the disadvantages are unknown, but here are a few problems I forsee:

• Fewer people will have an acceptable picture. (while the coverage will allow some in suburbs to receive a better picture, rural viewers who had an acceptable analog picture might not receive anything at all.)
• Portable ATSC TVs will be more expensive and will consume batteries faster.
• Since battery powered ATSC digital TVs haven't been perfected, they won't work well in weather or other emergencies. This is important because weather radar and other emergency maps provide information specific to a viewer's locale, this is very difficult if not impossible to provide via NOAA or commercial radio. Internet/cell phone services are often the first to go in an emergency and so they cannot be relied upon either.
• Given the amount of time there was to plan this transition, it was poorly managed.
• The billions of dollars and years of engineering that went into a slightly higher resolution TV standard could've been been put to a better use. Discounting the money spent by consumers on HDTVs, this project has cost taxpayers approximately $5 Billion. While the recent bailouts make $5 Billion sound like pocket change, this is actually 1/4th the cost of the entire Apollo moon lander program, which was completed in less time!
• Many devices will go into landfills before the end of their serviceable life. (e.g. almost all battery powered TVs such as the Casio in this photo are impractical to use with any of the Federally subsidized converter boxes.)
• Newscasters must shave and apply makeup more often.
• ATSC is heavily encumbered with expensive patents and royalties which, all else being equal, would nearly double the cost of the pocket Casio TV in the above photo. This also means that it may be impossible to create an opensource television or other free (as in freedom) ATSC compatible device (e.g. PVR.)

The photo above is of a portable NTSC TV receiving a PAL signal. The black-level is wrong, as are the horizontal and vertical sync intervals. There is no color and the sound modulation and frequency spacing are wrong. The fact that it works at all demonstrates just how robust analog technology is. If E.T. were looking for a an easily decipherable video signal from the U.S., she should focus on TV signals from 1941-2009. So long analog NTSC, it has been fun.

After many months of procrastination on my part, it’s time to launch the New Zealand OpenSolaris User Group. Organizing an active user group that meets on a regular basis is hard, regardless of technology interest, so I’ve decided firstly that NZOSUG will be just a virtual group for now with a mailing list to join - we’ll see how interest grows over time, and might have an occasional meet up with a presentation or several pints of beer.

Of course folks outside the country are most welcome to join. First up, we need to get cracking on a fun logo for the group - If you’re an artist and keen to draw something up, please do! I’ll make sure you get something from the OpenSolaris swag bag in MPK for your troubles.

A few weeks ago, we had a Saturday that was everything a Saturday should be - not too early a start, a nice breakfast, an energetic, if slightly damp, walk with Calum and the four of us visiting the Botanic Gardens for a picnic.

We're sort of in a weird state at home at the moment, trying to go around appreciating everything that Dublin has to offer (hence the visit to the Botanic gardens), unsure of what the future holds.

Ever since our first trip to New Zealand we've always thought it'd be an interesting place to live, but before my most recent trip there for Glynn & Jayne's wedding, we'd talked about my using the time over there to consider more carefully whether it's somewhere we'd want to emigrate to.

Over the course of the two and a bit weeks there, I was gradually leaning towards a "yes" answer to the question above, but it's funny - as soon as I heard the rumours about a supposed deal with IBM to buy Sun, I'd decided that if the deal went through, that'd be it, we'd really seriously look into moving. In some ways, that the deal fell through was a bit of a relief, not only because I think it'd have been the wrong thing for Sun, but also because I was off the hook in terms of facing that big decision to move. Now that there's another deal pending with Oracle, I need to face that question again.

On the other side of the argument, we've got a pretty cushy number in Ireland at the moment: our house is a 25 minute cycle from the office (the missus has a shorter commute to her office) and the creche we use for Ella, and possibly Calum too, is right next door -- but that, in a way makes us feel even more trapped: should we give up what appears to be a perfect setup and fling ourselves into the unknown? Looking further out, there's good primary schools in the local area for the kids, but getting them to a secondary schools would mean quite a commute for them I think, so we'd end up having to move somewhere in a few years anyway.

There's some things that could make moving easier. Already, I'm the only person in Ireland working in the Solaris xVM kernel group, so I'm working remotely wherever I am: working from the other side of the world probably wouldn't be that much different for me, assuming I'm allowed that opportunity with the pending acquisition. And of course, I'm not just moving me - we're a family, so anything we do has to work for everyone, otherwise it's not going to happen.

So is the decision to move made yet? No, not at all - it is a realization though, that we need to make that decision soon, rather than leave it hanging over us. Perhaps the best way, is to try to get out there for a year, and see how we settle - a sort of "Try and Buy" approach I suppose.

But, between then and now, there's plenty to enjoy about Ireland, and it seems like considering the question on whether to emigrate or not has made us think a lot about life in general and what we want to get out of it. I think we all should be enjoying it a lot more, dancing in the bluebells as much as we can.

To make life simpler for folks who wants to contribute OSS code to OpenSolaris, SourceJuicer is a web based through where spec files (format derived from RPM) can be submitted and automatically build and and publish on the web. The built package which is pkg(5) format can then be installed through the browser with a single click into the OpenSolaris 2009.06.

Since the Beta day, SourceJuicer has came a long way. Came across this webcast from Markus Weber, well worth a look at this introductory webcast.

OpenSolaris 2009.06 is now available for download!

I’m thrilled that we’ve gotten through another 6 months and produced another milestone, with some absolutely stunning new features like Crossbow’s network virtualization and IPS one click installs coupled with the automatic build and packaging service, Source Juicer . Check out what’s new with this release, along with Dan and Stephen talk through some of the new features.

We’re going to be celebrating the launch at CommunityOne with a whole bunch of OpenSolaris sessions. If you happen to be in the area, join us and help celebrate! Those outside the US should of course organize their own release parties!

I’ve set up a new mailing list for those mirroring the OpenSolaris ISO images. If you’re interested in hosting a mirror, or a current mirror maintainer, please join us! OpenSolaris 2009.06 coming soon!

The initial version of the new PatchFinder tool is now available on http://sunsolve.sun.com/patchfinder/. 

It's linked off the main SunSolve Patch page, http://sunsolve.sun.com/show.do?target=patchpage.  Look for the following link immediately under the old PatchFinder search box:

Preview The New PatchFinder

Why a new PatchFinder tool ?

The old PatchFinder tool was a pet peeve of mine.  You needed to know at least the 6 digit base PatchID of the patch you were trying to find in order to find it.   Rather self defeating IMHO.

The new PatchFinder tool directly leverages Sun's internal Patch Metadata Web Services to provide a much richer search experience.

Features of the new PatchFinder tool

You can still search by PatchID if you want.  This will override all other search options.

But you can also search for all Recommended or Security patches, and restrict that search, for example, to Solaris 10 SPARC.

By the way, "Recommended" means it's part of the Solaris Recommended Patch Cluster, which contains the latest revision of all Solaris OS patches which fix Security, Data Corruption, or System Availability issues.  See the cluster inclusion criteria definitions by clicking the appropriate heading on the Patch Clusters & Patch Bundles download page, http://sunsolve.sun.com/show.do?target=patch-access.

"Security" includes all patches which address Security issues, including Solaris OS patches and application and middleware patches for other products.

If you click the "OS Patches Only" box, the search results can be restricted to patches for the Solaris OS only, which will exclude application and middleware patches which are not bundled as part of the Solaris OS.  

Caveat: Note, the interpretation of what is a Solaris OS patch used by the tool is currently about 97% accurate.  This is due to difficulties interpreting patches for applications and middleware which may be bundled with the Solaris OS.  (The old PatchFinder tool and SunSolve patch reports have the same issue.) Hence you can see anomalies between search results returned for "Recommended" and "Recommended & OS Patches Only" which should be identical.  A subsequent version will have a 100% accurate interpretation of what is a Solaris OS patch.

Advanced Search Capabilities

Click on "Show Advanced Search" for more options.

This gives you options such as searching by CR (Change Request, a.k.a. BugID) number, so if you suspect you've hit a particular bug, you can check whether a patch for that CR is available yet.

Or you can search for patches with particular words in the patch synopsis or keywords fields - e.g. ldap, "patch util", "package util", "pkg util", etc.  These options have limited value as it's difficult to guess the values.

The "Released Before" option is handy if your company has a policy of waiting for patches to "age" a specified number of days after release before you consider applying them.

The "Released After" option is useful to restrict the search to patches released since the last time you checked for patches.

The "README Modified After" option is subtly different to the "Released After" field and is a superset of the "Released After" results in that is also shows patches whose README or patchinfo metadata files have been updated since the patch was initially released - for example, Special Install Instructions may have been added to the README to specify workarounds for issues found post-release which do not warrant the patch being withdrawn from SunSolve (i.e. the patch still does more good than harm for the majority of customers).

You can filter the search further to see only those patches whose README file was modified since you last downloaded patches by using the following search filter combination: For example, if you downloaded patches 30 days ago, you can see which patches which were release 30 or more days ago have had their READMEs modified since then by using the combination: "Released Before" == 30 && "README Modified After" == 30

In all of these time related fields, you can specify actual dates instead of a specified number of days.

If you don't have a support contract, click on the "Public Patches Only" box to restrict the search to patches which are available for download without a support contract.

The "Patch Property" field enables you to search for things like "Interactive" patches which require manual intervention during installation, "NonStandard" which means they aren't applied using the standard 'patchadd' utility (e.g. firmware patches), or patches which require downtime (Single User Mode, Reboot*) if applied to the live boot environment.  (Remember, Live Upgrade can be used to minimize the downtime and risk associated with applying patches by applying the patches to an inactive boot environment, thereby avoiding such downtime requirements during or immediately after patch installation.  You can reboot to set the inactive boot environment live at a time that suits you.)

By default, only patches which are currently available for download (i.e. patches which haven't been withdrawn due to issues) are returned in the search results.    You can select "Withdrawn" patches instead to get a list of patches which have been withdrawn from SunSolve due to serious issues.   This is useful to ensure you don't have any withdrawn patches installed on your systems.  I recommend you also select "Show Obsoletes" along with "Withdrawn" so withdrawn patches which have been superseded by replacement good patches aren't masked.  (Note, a Sun Alert is issued whenever a patch is withdrawn, so if you keep abreast of Sun Alert notifications as is advisable, this step is simply a check and balance.)

Fields such as "OS Release", "State", etc., allow multiple options to be selected concurrently from the drop down menu.

Patch Metrics Gathering 

The new PatchFinder tool is also useful for helping you to calculate patch metrics - e.g. the number of Solaris 10 SPARC OS patches released in the last year.

Or, if you feel so inclined, you can use the new PatchFinder tool to calculate the percentage of Solaris OS patches which are publicly available.   Select an OS Version, select "OS Patches only", and search with and without the "Public Patches Only" box selected to get the number of publicly available patches and the total number of available patches respectively.   To save you the trouble, the percentage of Solaris OS patches which are publicly available without a support contract today (May 27th 2009) are 25% for Solaris 10 OS patches, 28% for Solaris 9 OS patches, and 31% for Solaris 8 OS patches.

Display and Bookmarking Options

You can also select the number of patches to display in each page of search results returned (default 20), hide the search form so that only the results are displayed (the option is in the top right hand corner of the tool), and order the results by PatchID, Released date, or Synopsis, in either ascending or descending order (by clicking on the appropriate column heading of the results returned).

You can click on a PatchID in the search results returned to display the Patch README.

You can also bookmark the search results returned for future reference.  This is handy if you wish to run the same query regularly. 

Help! 

There's a "Help" summary in the top right hand corner and each search field has it's own help summary marked "?".

What's next ? 

I hope you find this initial version of the new PatchFinder tool useful.

This is a start, not the finished article.   In future versions we plan to provide options to resolve patch dependencies and patch installation order, enable patch download, etc.  

Feedback - what else would you like to see ?

Feel free to provide feedback on features which you'd like to see to the software-update-finder-feedback@sun.com alias or directly to me, Gerry.Haskins@sun.com .  

Our goal is to improve your patching experience.

It's with regret, that I won't be able to head over to CommunityOne West next week - the OpenSolaris tracks look pretty interesting, but as ever with this sort of thing, it's as much about the people you'll meet as the actual content of the sessions - in fact, I'd almost argue, it's more about the people you'll meet, than the sessions.

It's been ages since I've chatted to OpenSolaris-folk in person (other than my immediate colleagues in the xVM team and Glynn of course) and while email and IRC are good, they're no really match for having a beer and a natter with like-minded people - the OpenSolaris Party on Monday night looks like a pretty good opportunity for that. I would also quite like to be over there for the launch of 2009.06 having played a bit of a part in this release too (note to self: filing bugs that end up on a stopper list makes for somewhat exciting weekend), oh well.

My travel plans this year have been put on hold for a while - having been away from the wife + kids for a few weeks while I was down in New Zealand, closely followed by another week in MPK, I've promised to stay put in Ireland for a bit, although more about that in a future blog post I think.

Still, I'll be doing my best to keep up with what's going on at C1, and hope that I can at least read some blog reports on how the event goes next week. Wish I was there! If you wish you were there too, but live a bit closer, and feel like learning more about OpenSolaris, then do fill in the box below :-)

If you had been following OpenSolaris development during the lead up to 2008.05 and 2008.11, you might have heard the developers talking about Mexican Coke getting them through (the tip may be thanks to the guys at Joyent). Now rather than believe the engineers are a bunch of crack heads, their addiction is only to a sugary drink made from sugar cane and not sweetener used in the US.

So, on the lead up to OpenSolaris 2009.06 with fond memories of our first release coinciding with Cinco de Mayo, I give you Mexican chocolate perfect for those early morning conference calls.

My colleague, Enda O'Connor, has published 3 more patching articles on Big Admin which I hope you will find useful:

• Analyzing a patchadd or patchrm Failure in the Solaris OS

  How to gather and analyze the necessary information to determine why a 'patchadd' or 'patchrm' session failed.
  

• How to Split a Root Mirrored With Solaris Volume Manager Prior to Updating Software

  How to split a Solaris Volume Manager mirror prior to updating the software through upgrades or patches.

• How to Remove a Solaris Patch While Booted From a Network or CD-ROM

  How to run 'patchrm' from a network or CD-ROM against a non-live system that is mounted from such media, and how to mount file systems under the mount point after the system is booted from the media.

I think the first article is particularly useful to help customers and support engineers understand what data to gather to enable analysis of a patching issue.  Even if you are not able to analysis the issue yourself, providing this data to Sun Support when you log a call will help speed up the issue analysis by Sun.

Solaris 10 5/09 (Update 7) and subsequent Kernel PatchIDs 

The Kernel patch included in Solaris 10 5/09 (Update 7) has now been released to SunSolve.  The PatchIDs are 139555-08 (SPARC) and 139556-08 (x86).  The rest of the patches included in Solaris 10 5/09 are either released or in the process of being released over the next week or so. 

I've updated the Solaris Kernel PatchID sequence listed in http://blogs.sun.com/patch/date/20080416 to reflect this, including the PatchIDs of the post Solaris 10 5/09 (Update 7) sustaining Kernel PatchID and the Solaris 10 Update 8 Kernel PatchID.

We will be releasing a patch bundle containing the set of patches included in Solaris 10 5/09 in the next couple of weeks.  This will be available from the "Solaris Updates Patch Bundle" section on the new look SunSolve Patch Cluster and Patch Bundle page, http://sunsolve.sun.com/show.do?target=patches/patch-access, which now includes a description of the purpose, contents, and update frequency of each patch cluster and bundle.

As always, customers need to have a valid support contract in order to download Solaris patch clusters and bundles.

New PatchFinder tool coming

We plan to release a new PatchFinder tool on SunSolve at the end of May.   This leverages the patch metadata in our release database to provide a much richer customer experience to search for patches.  Further enhancements are planned after the initial deployment.  The old PatchFinder tool will remain available for a transition period.

Zones Parallel Patching Performance Enhancement

The Zones Parallel Patching performance enhancement continues on schedule.  It has been successfully beta tested by a number of key customers who confirm a 3x performance improvement patching zones.   It is on schedule to be released in a revision of the patch utilities patch (119254 SPARC / 119255 x86) in June.

Solaris 10 "Recommended" and Sun Alert Patch Clusters

Improvements to the Solaris 10 "Recommended" and Sun Alert Patch Clusters are on schedule to be deployed before the end of June.  The improvements include an improved install_cluster script (currently available in the Solaris 10 Live Upgrade Zones Starter Patch Bundle and the Solaris 10 Updates Patch Bundles) and other process improvements designed to improve quality.

Solaris 8 Vintage Patch Support Program

The Solaris 8 Vintage Patch Support Program is now up and running.  The first Vintage Solaris 8 patches have been released.

Patches which fix SunAlerts which were issued prior to the April 1 start date of the Solaris 8 Vintage Patch Support program will be released as "normal" (i.e. non-vintage) Solaris 8 patches. 

But all other Solaris 8 patches created after April 1, including patches which fix security issues, require customers to have a Solaris 8 Vintage Patch Support contract to use them.

See http://www.sun.com/bigadmin/topics/vintagepatch/  for further information.

A software glitch caused a number of empty patches to be accidentally released last week.   The PatchIDs are:

• 139555, revisions -01 to -07: Solaris 10: Kernel Patch
• 139556, revisions -01 to -07: Solaris 10_x86: Kernel Patch
• 139981-01: Solaris 10_x86: md patch

The above patches have been removed from SunSolve.   All of these patches were empty (i.e. they contained no payload packages), so they are incapable of being installed or causing any problems on a customer system.   This notice is simply to clear up any confusion.

The correct Kernel patch revisions are now available.  These are:

• 139555-08, which is the Solaris 10 Kernel patch included in Solaris 10 5/09 (Update 7)
• 139556-08, which is the Solaris 10 Kernel patch included in Solaris 10_x86 5/09 (Update 7)

The correct "md" patch revision will be released shortly.  This is:

• 139981-03: Solaris 10_x86: md patch

On behalf of Sun, I apologize most sincerely for any confusion or inconvenience caused. 

The first travel of the year for me with Sun, with a trip over to CommunityOne and JavaOne. Of course OpenSolaris will be there, with a great line up of activities, and lots of fun parties to help celebrate the release of OpenSolaris 2009.06. Come join us and hang out!

Testing OpenSolaris in a heterogeneous world using Virtual Box

Solaris and OpenSolaris have very good reputations for being stable, well tested platforms while also being full of innovation like dtrace, power aware dispatcher, ZFS, Cross Bow etc.. In this environment test coverage is a moving target, new features, new uses, new platforms all make it necessary for teams involved in testing to adapt and innovate to cope with the ever increasing workload. Running to stand still.

The PerfQE team provides Performance QE coverage for most of Sun's software and hardware assets, producing 40,000+ performance metric a month, automated regression isolation to the putback ( or to put it another way when we log a bug in a Solaris biweekly build which could have hundreds of separate changes/putbacks we have automation that will automatically the engineer that caused the regression and reassign it to him/her )

We have 1400+ system across the globe all run at 100% 24*7 and no dedicated lab staff in Dublin where most of our systems are located you can get the idea that we don't have the luxury of putting up with mis behaving tests that require us to kick start. One pain point for us has been a 60 Desktop Windows PC configuration placing stress on a Solaris server via in kernel CIFS and Samba. Between test run we reboot the entire configuration but 1 in 8 to 10 reboots one of those Wintel PCs would hang requiring, requiring a manual reboot. In the past we've added IP power switches to reboot offending systems hard after timeouts. But frankly they cost and I have enough cables.

So we just finished replacing the 60 Windows 2000 with a v40z ( Quad Core Opteron ) running OpenSolaris and 60 Virtual Box Windows instances. We've gone through a detailed review to ensure we are producing the same ( actually it is a higher load ) on the Solaris CIFS server and we're seeing the same load pattern on the system under test but no hangs so far.

So what have we gained from this ? What are the advantages ?

1. Space savings of over 95% ( they were desktop PC connected to a KVM )

2. Power savings of 80%

3. Capital saving on hardware 60 desktops vs one server are pretty large. ( I will not put a % on it as it varies too widely )

4. Test hangs reduced by 100% ( making the team happier ), and getting more from our capital.

5. We'll now be testing more versions of Windows as the overhead in managing the virtual images is so low.

6. We can use dtrace to profile the load Windows sends to our server more easily.

7. The v40z is easier to manage remotely and hardware problems are handled by FMA making life easier

There nothing here to stop anyone test/QA/QE group implement something similar and with saving as significant as we are seeing it really is worth the time.

Some of the strongest criticisms of Django come from users of PHP or other frameworks which allow you to do almost anything in the templates. This can encourage developers to put business logic into the presentation layer which eventually results in an unmaintainable mess. It's the web2.0 equivalent of a GOTO statement.

But on several occasions while working on SourceJuicer it really would've been handy to be able to store or increment variables or directly access a slightly complicated query in the template. For example, I was attempting to pass a list indexed by an existing column (JobID) into a template when I noticed that there was no way to convert the JobID string to a numeric within the template. Then Luis reminded me that if it seems like you're trying to do too much in the template, you're probably trying to do too much in the template. So I went back to the model and saw that I could add the 'slightly complicated' query to an access method in my model. Django does allow you to access methods from the template but it doesn't allow you to pass parameters to these methods. This seems a reasonable balance between strictness and ease of use. It simplified the code while maintaining good separation between business logic and presentation.

I did my first git push yesterday (30/04/2009() since GNOME has moved from svn(1)to git(1). First of all, I really do appreciate those who worked on getting git(1) into OpenSolaris; save me having to build them from Spec Files Extra.

Looking at the my bash shell history, I issued the following commands:

git config --global user.name "user name"
git config --global user.email "email-address"

# That set up my basic identification.

git status
git clone git://git.gnome.org/gnome-session

# First mistake, I checked out with read-only permission.

git clone ssh://"username"@git.gnome.org/git/gnome-session

# Checked out properly. Make code changes

git diff

# Look at code diff

git commit gnome-session/gsm-manager.c

# Commit code to local git clone

git push --dry-run

# Tried to push in dry run mode

git push origin HEAD

# finally pushed to master repository.

All the commands use are essentially nicely documented here

After making the commit, received a link from maintainer in how to make commit message more meaningful and conformance.

Just for future commits: http://live.gnome.org/Git/CommitMessages

Lots of useful information can be found here
But I find this one is all that I need for doing my first git push!

If you had seen Campbell Live last night, or followed the NZ beer and brewing forums you know about DB Brewery’s bulling tactics against Green Man Brewery, a small organic brewery in Dunedin.

Unfortunately a while ago DB successfully claimed ‘Radler’ as a Trademark with the Intellectual Property Office, IPONZ. As many will know, the term ‘radler’ (defined in Wikipedia) is actually a beer style, much like lager, pilsner, or IPA. However, having wrongly claimed the trademark (and IPONZ are to blame here), they also wrongly defended use of their trademark against Green Man’s Radler beer and forced the company, after a short fight due to the costs involved to Green Man, to re-label their product to ‘Cyclist’. DB also have tried to register other beer styles as trademarks to mixed successes.

Fortunately a renowned law firm are getting involved on a pro-bono basis to fight the case, James and Wells, as announced recently, helping the cause of both Green Man Brewery and SOBA (Society of Beer Advocates). Other local businesses likes Rumbles are getting on board.

Now you can too! Here’s how - Simply boycott all DB products - Tiger, Heineken, Amstel, Tui, Export Gold, Monteiths and Budvar. It’s that simple. Help support the NZ craft beer industry by buying NZ craft beer, a set of great brewerys brewing for the love of beer, the availability of great beer, and the choice and freedom of all recognized beer styles.