I'm delighted to announce that the Solaris 10 10/09 (Update 8) Patch Bundle is now available for download by customers with a Solaris support contract.

Each Solaris Update Patch Bundle contains the equivalent set of patches which are pre-applied into the corresponding Solaris Update release image.

It is provided to enable customers who cannot upgrade for whatever reason to be able to patch systems up to the same patch level as the Update release.

Each Solaris Update is intensely tested as a unit by myriad QA teams across Sun.  Therefore, Solaris Updates and their corresponding Solaris Update Patch Bundles provide good quality "baselines" on which customers can standardize their deployments.

Standardizing deployments on such "baselines" also provides customers with a "safety in numbers" effect, as any pervasive issues are likely to be found and fixed quickly, so each customer benefits from the experience of others.

The Solaris Update Patch Bundle brings all existing packages up to the same software level as the Update release.   Any features which are entirely contained in pre-existing packages, such as Zones and ZFS functionality, are entirely available in patches and hence applying the Solaris Update Patch Bundle brings them up to the same functional level as the Update release.

However, installing the Patch Bundle is not completely equivalent to upgrading to the corresponding Solaris Update as the Patch Bundles do not include any new packages introduced in the Solaris Update release image.  Therefore, any new features which are dependent upon new packages will not be available by applying the Solaris Update Patch Bundle.

Here's a summary of the new packages in Solaris 10 10/09 (Update 8) which are not available in the Solaris 10 10/09 Patch Bundle:

SUNWhxge: SUN 10Gb hxge Ethernet Network Adapter Driver
SUNWio-tools: Administrative tools to modify the pci/pcie fabric
SUNWmrsas: LSI MegaRAID SAS2.0 HBA driver
SUNWpixman: Pixman Library
SUNWntp4r: NTPv4 (root)
SUNWntp4u: NTPv4 (usr)
SUNWntp4S: NTPv4 (source)
SUNWmptsas: LSI MPT SAS2.0 HBA driver

Please remember to apply the latest Sun Alert Cluster on top of the Solaris Update Patch Bundle in order to get all Solaris OS security, data corruption, and system availability fixes released since the final build of the Update release.

Please see previous blog entries for further details on Solaris Update Patch Bundles.

Top Tip: If you are installing in a zones environment, make sure you have the latest patch utility patches installed and Zones Parallel Patching configured before you apply a Solaris Update Patch Bundle as Zones Parallel Patching will improve non-global zone patching performance by ~300%.   See this blog entry for details.

BTW: There is no need to take any action to enable "Turbo-Charging SVR4 Package Installation" as the necessary patches are installed early on when installing the Solaris 10 10/09 Patch Bundle and will be automatically enabled for subsequent patch application when the bundle is applied to the live boot environment.  While "Turbo-Charging" has little affect when installing most patches, it does significantly speed up the application of a small number of older patches with non-optimized deletes file processing install scripts and so does speed up the Solaris 10 10/09 Patch Bundle installation somewhat.

Best Wishes,

Gerry.

Part of the preparation for making CUPS as default on OpenSolaris, I have split out 2 packages SUNWgtk2-print-cupsand SUNWgtk2-print-papi in OpenSolaris 126 from SUNWgtk2.

Why did I do that?
The primary reason is that when LP ceases to the default print system on the LiveCD, having the PAPI print backend on the liveCD and not have /usr/lib/libpapi.so, all the applications that have print dialog will *CRASH*.

Splitting this out allows the PAPI print backend not to be installed on the liveCD when CUPS becomes default and allows applications to continue to work properly.

When will CUPS as default happen?
The basic code to switch CUPS as default is in b127, however, a lots of packages refactoring is being worked on so that CUPS will be slimmer than LP on the LiveCD. The credit for that belongs to Gowtham T (and as usual Norm as the adviser).

So when will CUPS as default becomes a reality from the LiveCD, that is all in the capable hands of Dave Miner and David Comay .

So in the meantimes, in b126/127, you may have to do:

$ pfexec pkg install SUNWgtk2-print-cups

if you are already using CUPS and noticed that all the printers you used to see is not visible in the print dialog.

Why can this be fixed automatically?
It seems until facets is implemented in IPS, I cannot easily specify some of the interdependencies easily. (see discussion thread here, here)

While I am goggling, it is really excited to see that Bart is implementing facets with this bug.

GREAT News!

Happy Z-Day everyone!

Breaking with tradition somewhat, I'm not sure there's going to be any fireworks photos here this year: we're down at my parents house, and are less likely to get the sort of sustained shelling that we normally experience in Raheny each year.

On the plus side, we had homemade pumpkin soup for lunch, so was at least able to get this shot. If there's any fireworks later on, I'll update this post - but otherwise, here's some Halloween cheer:

The day's been great so far - lovely birthday presents (a Merino base-layer and a copy of Neverwhere from the lovely missus, and DVDs of the first two Ice Age films from E (I think she had an ulterior motive there!) and a nice fleece from my folks)

I also popped out for a birthday run around Greystones this afternoon, only 10k but it was enough for me to realise I'm far from being back in running form: the recovery is going to last a few more weeks I think!

My folks are baby-sitting tonight, so myself and the missus get to go out for a grown-up dinner, which I'm really looking forward to. Happy Halloween!

Update: There were fireworks after all, here's a few shots: fantastic, the tradition continues!

I ran the Dublin City Marathon yesterday in approx. 3h 30m (more on that later) - that's my first marathon, but I suspect not my last: to anyone even half-thinking of running 26.2 miles, you have to try it.

My motivation for running started several months back on a low note. The background was that I was increasingly working from home, with work being busy and having a desire to eat dinner with the family and be around to put the kids to bed, I was noticing that there were days where I wasn't leaving the house at all. At the same time, the rumours started about Sun being in talks with various companies about a possible acquisition.

When the Oracle deal was announced it made things worse - what had previously just been rumours in the press became a lot more believable. Usually when something like this is going on, I'll write my thoughts about it here: but doing so would have been unprofessional. The furthest I ever went was the occasional emoticon on my twitter feed.

The solution for both problems, I decided, was to get out in the mornings and run: exercise, and a little time to think.

As the months went by, I was running further and further, logging my progress to @timfoster as I went ,and generally having a whale of a time. One weekend, we had a few friends over for lunch - Kev, Nic, Mike & Maria. A bit of the conversation went something like this:

"That's great running you're doing Tim, you should do the marathon"

Well, that was it, I'd had vague thoughts of doing it one day, but hearing someone else say it out loud was enough to make me register that night - with some trepidation, I might add. The registration form grouped entrants into three categories in order of expected finishing time: 3h or less, 3:30-4:15, 4:15+. I had no clue where I belonged, so popped myself in the middle and got on with it - that was July 28th this year.

I figured I ought to be following some sort of formal training plan. The athletics forum on boards.ie was a great resource, and were pointing newbies like me to Hal Higdon's running site . I chose the Intermediate II schedule, as I figured I was already reasonably fit with the daily commute on bike from time to time, and all the running I'd done so far. I'd missed a few weeks at the beginning of the formal program, so worked out where I should be (which turned out to be a good place to start given the running I'd already done) and stuck to it.

As I got closer to the race, I was dutifully doing my Long Slow Runs each weekend and was coming up to running the last of the three 20 milers when I became anxious about what sort of pace I'd manage in the race - could I go fast over a long distance? I didn't know. I didn't want to risk burning myself out in the early stages of the race, and end up not finishing. I decided to push it, and do a Long Fast Run instead - you're not supposed to do this during training, I found out why. Yes, I discovered that I actually could manage a 7:15 min/mile pace over 20 miles, but I also managed to injure my leg in the process. To make matters worse, I'd miscalculated where I was joining the schedule, and it left me with only 2 weeks to taper before the race rather than 3, and most of those 2 weeks were spent just resting my leg rather than doing the suggested mileage.

With that, race day was upon me. I was aiming for a 3h15m finish - but given the last few weeks, this was probably unrealistic.

The atmosphere around the start was tense, but an amazing experience - very very well organised I thought: a record turn-out of 12,500 people this year.

After a lot of limbering up, and shedding of bin-liners, the starting gun fired. We moved very slowly at first, eventually getting past the starting line. The race started gently: I was in the middle of the 3:30-4:15 pen and first few miles were depressingly slow, difficult to overtake slower runners and I was already well down on my target. They say one of the most common mistakes by new marathon runners is starting too fast, so I kept repeating that to myself, and tried to stay calm.

By mile 5, I'd escaped the crowds in Phoenix Park and picked up the pace, passing Kev & Nic at mile 10 who were out cheering for me (thanks!!) and managed to keep pretty much on target till about mile 16 where I started slowing down, only to slow down further on miles 20/21 (the dreaded Roebuck/Foster Avenue hill) The missus & the kids, and Mum & Dad were cheering for me there, and I spotted my friend Barry too, who was marshaling for the race: familiar faces making the run a lot easier.

In general, the support from the crowd on the day was phenomenal: I really hope the people who got up early on an October Bank Holiday Monday appreciate what a difference them cheering really makes to runners - and, to the lady watching the race who gave me a jelly baby around Kimmage to whom I forgot to say "thankyou" - many many thanks, it was yummy, and much needed!

Things took a turn for the worse though around mile 22 - going down Nutley Lane, I felt a twinge in my thighs that I'd felt once before during training: the onset of cramp. I had to stop stretch/shake out my legs periodically, eat more jelly babies and start again. My times were tumbling now, and I watched in dismay as the 3:30 pacer balloons passed me on Merrion Road. For the rest of the race, I kept going as fast as I could manage, but it wasn't enough.

Rounding the final corner onto Pearse St. I went for it, eating my remaining sweeties and telling myself it'd soon be over. I crossed the line, and stopped my watch, which told me 3:30:46. I was tired but happy - I'd missed the 3:15 target, but there's always the next marathon.

As for official timing, I'm still a wee bit confused - the timing service that was tied to the chip on my bib told me I'd finished in 3:32:04, yet when I visit the results page on the Dublin Marathon website and search for my number (4871), at the time of writing, it confirms that chip time of 3:34:04, but tells me my finish time is 3:30:34. I know there's a difference between chip time and gun-time, but I'd always thought gun-time should be longer than chip-time (as it doesn't account for the time it takes you to actually reach the starting line, whereas chip time is registered from the moment you cross the start-line) Perhaps they got the numbers mixed up - 3:30:34 is closer to what was on my stopwatch. Anyway - it doesn't really matter.

I had a ball on my first marathon - I finished 1516^th out of a field of 12,500, which I'm happy about. I've got memories I'll never forget and a belief in myself that I never had before. Sure, I'm walking around like Boris Karloff today (legs rather sore) and am wishing our house didn't have stairs, but I'm extremely proud of what I've achieved. I think I'll keep running and would strongly recommend everyone to have a go at completing a marathon: it's a truly unforgettable experience.

Here's the route map, and the splits from my watch - I missed a few mile markers here & there, so just rolled up those times into a single row. As you can see, I lack consistency here - so that's something to work on for next time.

The OpenOffice.org guys are doing some interesting analysis as part of their Project Renaissance UI improvement project. This click map caught my eye this week (click to see the whole thing):

More information on what they're doing can be found over on the GullFOSS Blog.

The OpenOffice.org guys are doing some interesting analysis as part of their Project Renaissance UI improvement project. This click map caught my eye this week (click to see the whole thing):

OpenOffice Impress toolbar click map

More information on what they’re doing can be found over on the GullFOSS Blog.

I'm delighted to announce the release of the 2nd phase of our PatchFinder tool enhancements, which include:

• The ability to see the "Entitlement Classes" of patches and get information on the support contracts necessary to access and use them.  

• A "Patch Basket", into which you can add selected patches from multiple search results.

• When you click on the "Go To Patch Basket" link, the patch dependencies for all the patches you have in your Patch Basket will be dynamically resolved, including filtering out redundant dependencies.   This saves you having to manually transfer patch dependency trees!   If you already have some of these installed, you can de-select them.
  

• You can then click the "Download Selected" button to download a 'wget' script and instructions which you can use to download all of the selected patches from SunSolve.   Once you make sure you install the latest version of the patch utilities patch first, you can then use "patchadd -M" to install all the patches in the correct order on your target system.
  

Sample Searches

Let's assume you applied the Solaris 10 SPARC Recommended Patch Cluster on August 15th 2009.  So what Solaris 10 SPARC Recommended Cluster patches have been released since then ?   To find out, for "OS Release" select "Solaris 10", for "Architecture" select SPARC", select "Recommended Only", and select August 15th 2009 from the calendar beside the "Released After" box.   (Select view 50, 100, or 200 to see the entire list in one page.)   You can then decide if you want to download some of all of these patches to add to your system.  Coupled with the dynamic dependency resolution and 'wget' download capability, this effectively enables you to create customized patch clusters for yourself with just the patches you need, rather than having to download the entire Recommended Cluster each time.

Or you could bookmark a search to show you all the patches released in the last day: Simply enter the number "1" into the "Released After" box and select any other selection criteria you are interested in and click "Search".  Depending on timezone differences with respect to California and your local time of day, you may need to enter the number "2" in the "Released After" box.

You can also use PatchFinder to see what Solaris 8 Vintage patches Sun has released since Solaris 8 entered End-Of-Service-Life (EOSL) Phase 2 on April 1, 2009.   Simply select "Solaris 8" for "OS Release", select "OS Patches Only" and click "Search".  Since the patches are listed in date order, most of the patches with a release date after April 1, 2009, including patches delivering security fixes, will have the "Solaris8VintageSoftwareUpdate" Entitlement Class associated with them if you mouse-over the red padlock symbol shown for them (assuming you don't have a Solaris 8 Vintage Patch Service Plan associated with your Sun Online Account).   You will see a couple of non-Vintage patches released after April 1, 2009.  This is a transition phase and these patches address issues escalated by customers prior to April 1, 2009.

Some other sample searches to satisfy your curiosity:

Ever wondered how many patches Sun has ever released ?   To find out, simply select "Show Obsolete" and then click "Search".

How many current "active" patches does Sun have ?   De-select "Show Obsolete" and then click "Search".

How many patches can be installed on Solaris 10, including application product patches ?   For "OS Release" select "Solaris 10" (and optionally "Show Obsolete" ) and then click "Search".

How many current "active" Solaris 10 OS patches there are for SPARC ?  For "OS Release" select "Solaris 10", for "Architecture" select "SPARC" and then select "OS Patches Only" and then click "Search".

Patch Access Entitlement Classes

When you look at the list of patches returned from a search, the letter-P-in-a-circle symbol shows which patches are "Public" and can be accessed and used without a support contract.  A green open padlock symbol shows the patches you have access to thanks to the support contracts which you currently have associated with your Sun Online Account (SOA).  A red closed padlock shows the patches which you are not currently entitled to access or use with the support contracts you currently have associated with your Sun Online Aaccout.  

You can mouse-over these symbols for any patch and it will show you the "Entitlement Classes" associated with the patch. 

Read the "What is it?" help link and the SunSolve "How Entitlement Works" wiki to find out about the support contracts which you need to buy in order to access and use these patches.

Feedback

I hope you'll find the new PatchFinder enhancements useful.

We are really interested in your feedback as to what further enhancements you would like to see, so feel free to post your comments here or else use the feedback link on the PatchFinder page.

Many thanks to Brian Kidney and Julien Colomb for all their work on this - nice work guys!

Emily Chen and I coauthored a chapter in an O'Reilly book entitled "Beautiful Testing" which was edited by Adam Goucher and Tim Riley.

Successful software depends as much on scrupulous testing as it does on solid architecture or elegant code. Beautiful Testing offers 23 essays from 27 leading testers and developers that illustrate the qualities and techniques that make testing an art. Through personal anecdotes, you'll learn how each of these professionals developed ideas of beauty in testing a wide range of products -- valuable knowledge that you can apply to your own projects.

The electronic version is already available here: http://oreilly.com/catalog/9780596159825

Didn’t blog about this at the time as I guessed anyone who was interested would be on the usability list anyway, but in retrospect that’s probably not true so I’ll summarise here as well.

Just prior to the Boston Summit, mostly in response to some prodding from Brian, a few of us started kicking around some ideas for dragging GNOME’s usability activities into the 21st century. General areas for discussion include:

• improving the HIG (e.g. turning it more into a visual pattern library with code samples, with a wordier secondary document for issues that still required it)
• novel ways to gather valid usability data for GNOME (e.g. instrumenting applications, online surveys, remote usability testing via webcam/voip)
• possibility of a Foundation-funded mobile usability lab, similar to the one Máirín demonstrated at the Boston Summit

.

Anyway, if you want to join in the discussion, it’s mostly happening over here.

I've updated the Solaris 10 Kernel PatchID sequence table in http://blogs.sun.com/patch/entry/solaris_10_kernel_patchid_progression with the latest Kernel PatchIDs for Solaris 10 10/09 (Update 8) and Solaris 10 Update 9.

What are you doing if the road is blocked? Probably trying to find a detour.

So what if the Skype is not working natively on OpenSolaris? Here is the recipe which will allow you to use your Skype account, send messages and do VoIP with video support.

First of all you will need to get the flash plugin for your Firefox. It's very easy, just follow the blog entry from John Rice.

Secondly simply use the IMO website and allow flash plugin to access your microphone and camera (you will be prompted when you will start some VoIP chat).

The only thing I had to do was to increase Recording volume using Volume Applet and the one from the flash plugin settings -right click on the VoIP window, when you are talking to someone and choose "Settings..." from the flash plugin menu.

OpenSolaris have 2 print systems, the default print system to date including 2009.06 release is LP. From the Live CD, the LP print system is installed. You may want to have CUPS because of better application integration or other reasons. You need to install additional packages from the repositories, such as http://pkg.opensolaris.org/dev.

To avail of the CUPS print system, one needs to do the following steps:

$ pfexec pkg install SUNWcups SUNWcups-libs SUNWcups-manager SUNWpycups SUNWhal-cups-utils

or simply

$ pfexec pkg install SUNWhal-cups-utils

Once these packages are installed, do

$ pfexec /usr/sbin/print-service -s cups

To revert back to LP, simply do

$ pfexec /usr/sbin/print-service -s lp

I presented An Introduction to OpenSolaris last Saturday at OSS BarCamp - my contribution to Software Freedom Day 2009.

You can download the odp presentation or the pdf, which I've exported with my notes for the talk that explain each of the slides a little more - I hope this is useful if you're planning on giving a similar talk.

A few things struck me while preparing for and giving the presentation. Firstly, it seemed odd to be giving an introduction to an operating system that's been around for quite a while now: clearly we haven't been doing enough of this sort of thing (and from personal experience, yes, ie-osug isn't as active as I'd like, I just sadly don't have the bandwidth)

Then secondly, it's really hard to cover all of the interesting features of OpenSolaris in sufficient detail over the course of an hour. My take, was to try to whet the appetite, rather than explain every feature fully - and in some cases, go for the features I thought the audience might be interested in (for example, mentioning NWAM as one of the major networking features - perhaps it's not as full of rocket science as other aspects of Solaris networking, but it makes a huge difference to the novice user)

Finally, and slightly embarrassingly, I had to spend about 5 minutes in front of an expectant audience futzing around with the display settings on my R500 laptop to get it to talk to the projector. It was doubly annoying that both xrandr (and indeed gnome-display-properties) were able to see the separate screen, but try as I might, I couldn't get any output to appear externally. Ultimately, a kind audience member offered me a USB key by which I transferred the pdf over to my EeePC (running nv_122) which was able to see the projector, but didn't have any of my demo material setup (some ZFS settings, some zones, crossbow, flows etc.) Oh well.

Here's hoping that at least some of the audience left with an impression that OpenSolaris was worth taking a second (or perhaps a first?) look at, despite the brevity of my talk and the initial teething problems I had. My new mantra:

Never work with children, animals, or weird exernal VGA projectors.

The new Patching Pre-flight Checks ('ppc') tool is now available to all customers who have a support contract.

The idea for this tool comes directly from customer feedback.  

The customer wanted to reduce the cost of patching Solaris systems by enabling more junior Sys Admins to successfully patch Solaris 10 zones systems.   Their concern was that potential zones patching issues in versions of Solaris prior to Solaris 10 8/07 (Update 4) meant that they needed to assign senior System Administrators to patch such systems to identify and resolve potential issues.  

Furthermore, the customer was concerned that such issues had the potential to derail planned maintenance windows - for example, if during the patching session an unexpected issue was encountered and the patching session couldn't be completed as planned.

To address these concerns, my colleague, Ronan O'Connor, has written the Patching Pre-flight Checks tool, 'ppc'.  It can be run prior to a planned patching session to check that the target system is in a clean state ready for patching.

It's important to understand the scope of the tool.  It checks a target system (and a patch set, if supplied) for a variety of inconsistencies which could cause problems.

It looks for left over lock files from previously aborted patching or packaging operations, inconsistencies in the contents database, IDRs installed on the target system, zones "mountability", space issues, etc.  Some of these issues can occur on early versions of Solaris 10, particularly in a Zones environment.  Many of the underlying causes of such issues are fixed in the latest versions of the patch utility patches (119254 SPARC / 119255 x86), which is why we always recommend you apply the latest patch utility patches before applying other patches.

If you have a directory of patches to be applied, 'ppc' checks the integrity of those patches, and cross-checks whether any of the patches patch pkgs which have been locked down by any IDRs on the system and warns if there is a conflict.

The 'ppc' Release Notes provide information to help interpret the messages produced.

The idea is that 'ppc' can be run by a junior Sys Admin prior to a planned patching session, and any potential issues uncovered can then be analyzed by a more experienced Sys Admin.  This helps avoid nasty surprises during patches sessions and also helps to reduce the level of expertise required to patch Solaris systems, leading to cost savings for customers.

It is outside the scope of the 'ppc' tool to do root cause analysis of why the inconsistency arose or what actions may be needed, if any, to correct the situation.

If 'ppc' returns without noting any problems, you can be pretty confident that the patching session will succeed.  If 'ppc' notes potential issues, they can be investigated prior to the planned maintenance window.

The next version of 'ppc' will include a Zones consistency check to check that all zones are at a consistent patch level.   It will also contain a more sophisticated space checking algorithm.  There's no planned release date yet for Version "2.0" yet as we're awaiting feedback on Version 1.0.x first.

Some of the ideas in 'ppc' may find their way back into 'patchadd', although it's probably appropriate to keep 'ppc' as a separate tool.

To download the Patching Pre-flight Checks tool, 'ppc', go to the 'ppc' thread on the Customer Patch Forum.  If you have not accessed the Customer Patch Forum before, please see my blog entry on the initial "secret-handshake" login. 

The Patching Pre-flight Checks tool, 'ppc', and the Customer Patch Forum are only available to customers with a support contract.

We're very interested in your feedback as to the usefulness of this tool and how you'd like to see 'ppc' develop going forward.

Many thanks to Ronan O'Connor for all his work on the tool!

Best Wishes,

I was getting some work done with virtualbox, vnics and
AI.

While VirtualBox does reboot rather fast since it virtualised, but why not faster ? Since the bug with VirtualBox and
OpenSolaris was fixed we should be able. And indeed we are.

By taking out VirtualBox from the blacklist of the boot-config SMF service we can then do Fastreboot within a VirtualBox guest with no issues :)

Let see what platforms are blacklisted.

$ svcprop -p fastreboot_blacklist/platforms boot-config
VirtualBox VMware\ Virtual\ Platform MCP55
$

Ok, lets take out VirtualBox.

$ svccfg -s boot-config:default setprop blacklist/platforms = astring: '("VMware Virtual Platform" "MCP55")'
$ svccfg -s boot-config:default refresh

Now VirtualBox can do fast reboot.

Thanks Darren for the trick with '(..)' for handling multiple strings in the property.

Nice to see Oracle starting to come out of the woodwork on a few issues in the interim. Good strong statement for Sun’s existing customer and userbase, and headsup to IBM -

Go digg it!

I am delighted to announce that Casper Dik's "Turbo-Charging SVR4 Package Install" feature enhancement is now available by downloading and installing the following patches:

119254-70 (SPARC) / 119255-70 (x86): Patch utilites patch
121428-13 (SPARC) / 121429-13 (x86): Live Upgrade Zones Support Patch
121430-40 (SPARC) / 121431-41 (x86): Live Upgrade Patch
124630-28 (SPARC) / 124631-29 (x86): System Administration Applications, Network, and Core Libraries Patch

It is important to apply 119254-70 (SPARC) / 119255-70 (x86) and 121428-13 (SPARC) / 121428-13 (x86) if the system is running non-global zones.  Otherwise booting newly installed zones will fail until the pkgserv daemon exits, about 5 minutes after zoneadm install finished.  Zones which were already installed can be booted as expected.

"Turbo Packaging" is designed to dramatically improve the performance of install, upgrade, Live Upgrade, and zone creation on Solaris 10.  It delivers only a small improvement for patching performance.   (See my Zones Parallel Patching blog entry for information on dramatic patching performance improvements.)

For background reading on the "Turbo Packaging" feature, please see
http://www.opensolaris.org/jive/thread.jspa?messageID=358081 and http://arc.opensolaris.org/caselog/PSARC/2009/173/. 

The "Turbo-charging SVR4 Package Install" feature will also be included in the forthcoming Solaris 10 Update 8 release and will be documented in the Release Notes for that release.

Great work, Casper - well done!

Discovered via Boing Boing this morning, I found this article particularly enlightening. Bruce Sterling talking about the future, picking five technologies from today, "The Cloud! Web Squared! The Internet of Screens! The Internet of Things! Augmented Reality!" and showing how they would seem completely normal to anyone in the future.

They're phantom far-out notions gobbled up by the real world. They packed in there so deep that nobody notices them. So, yes, I can write about it. It's just: it doesn't look futuristic. It looks way too real.

Why isn't it grand? Why isn't it as fantastically grand as the spectrum of all possibility? Well, why isn't today grand? Why didn’t we wake up this morning in direct confrontation with the entirety of past and future? The present day is the only day we’re ever given.

[ Bruce Sterling, writing for Webstock ]

Definitely worth reading the whole article.

This is a Quick 'n' Dirty guide to creating an LiveCD ISO image for OpenSolaris on OpenSolaris.

NOTE: these notes are written assuming you have access to Sun's internal servers. You may be able to populate your own local IPS repo from some other source, I don't know how off hand but if you find out let me know and I'll add that info here aswell.

1. Some Environment setup

Install ss-dev and SUNWonbld packages, this will ensure all required dev tools are installed such as SunStudioExpress and create SUNWspro symbolic link :

  $ pfexec pkg install ss-dev SUNWonbld
  $ pfexec ln -s /opt/SunStudioExpress /opt/SUNWspro

Some other dependencies that I also installed were :

  $ pfexec pkg install SUNWgnome-common-devel
  $ pfexec pkg install SUNWpython-setuptools
  $ pfexec pkg install SUNWpython-pycurl

If the build fails, see what the build was looking for and use pkg search filename to see what other package might be necessary.

Ensure your PATH has SunStudioExpress and onbld included, and also has /usr/bin before /usr/gnu/bin :

  $ export PATH=/usr/bin:/opt/SunStudioExpress/bin:/opt/onbld/bin:$PATH

2. Create local IPS Repository

First clone the gate (IPS) source and build/install it :

  $ cd
  $ hg clone ssh://anon@hg.opensolaris.org/hg/pkg/gate
  $ cd ~/gate/src
  $ pfexec dmake packages

All gate related packages are available under : ~/gate/packages/i386.

On OpenSolaris, just enure you have the most up to date versions of these package installed from your default authority :

  $ pfexec pkg install SUNWipkg SUNWipkg-brand SUNWipkg-gui SUNWipkg-gui-data  SUNWipkg-gui-l10n SUNWipkg-um SUNWpython-cherrypy SUNWpython-mako SUNWpython-ply SUNWpython-pycurl

On SXDE you should remove the old versions of these packages and install the newly built ones. Before installing these packages ensure the pkg/server SMF service is disabled.

  $ svcs -a | grep pkg/server
  online         Feb_18   svc:/application/pkg/server:default

If online then disable :

  $ pfexec svcadm disable pkg/server
  $ svcs -a | grep pkg/server:default
  disabled       11:26:58 svc:/application/pkg/server:default

Now as root :

    $ pkgrm SUNWipkg
    $ cd ~gate/packages/i386
    $ ls
    SUNWipkg               SUNWipkg-gui           SUNWipkg-gui-l10n        
    SUNWpython-cherrypy    SUNWpython-ply         pkg5-c700981b0af2.pkg
    SUNWipkg-brand         SUNWipkg-gui-data      SUNWipkg-um              
    SUNWpython-mako        SUNWpython-pycurl      pkg5.pkg
    $ pkgadd -d pkg5.pkg
    $ pkginfo SUNWipkg

3. Set up Local IPS Repository.

By default pkg/server uses /var/pkg/repo for it's package directory. If you choose to use the default the first time you import just ensure it's contents are clear out :

  $ svcadm disable pkg/server
  $ pfexec rm -rf /var/pkg/repo/*

Best practice though would be to create a new zfs location for local repo:

  $ pfexec zfs create rpool/ips
  $ pfexec zfs create rpool/ips/repo
  $ pfexec zfs set mountpoint=/export/ips/repo rpool/ips/repo

If you do create a new directory you need to set the pkg/inst_root property of the SMF service to point to this new location :

  $ pfexec svccfg -s pkg/server setprop pkg/inst_root = /export/ips/repo

You need to update the default port number from 80 to 10000, 10000 is the port used by distro-import :

  $ pfexec svccfg -s pkg/server setprop pkg/port = 10000

Refresh and enable pkg/server, and check your settings :

  $ pfexec scvadm refresh pkg/server
  $ pfexec svcadm enable pkg/server
  $ svcprop pkg/server | grep port
  pkg/port count 10000
  $ svcprop pkg/server | grep inst_root
  /export/ips/repo (or /var/pkg/repo)

You can browse the repo in browser with following URL :

     http://localhost:10000

4. Create your own slim install packages.

Get the sources:

  $ cd
  $ hg clone ssh://anon@hg.opensolaris.org/hg/caiman/slim_source

Read ~/slim_source/usr/src/README and follow the instructions on how to build.

You need three other packages not on the IPS servers but are available on http://dlc.sun.com/downloads. These are SUNWzoneint, SUNWwbint, and SUNWldskint. Just download and install them using pkgadd. The following shows a single line command that will download and install in one go :

  $ pfexec pkgadd -d http://dlc.sun.com/osol/install/downloads/current/SUNWldskint
  $ pfexec pkgadd -d http://dlc.sun.com/osol/install/downloads/current/SUNWwbint
  $ pfexec pkgadd -d http://dlc.sun.com/osol/install/downloads/current/SUNWzoneint

Before you build if you have pulled your slim source to a location other than the default "slim_source", you need modify developer.sh and change CODEMGR_WS to point to this location. To build your packages just :

  $ cd ~/slim_source/usr/src
  $ ./nightly developer.sh

This will build packages under : ~/slim_source/packages/i386/nightly-nd, and the nightly build log is located in ../../log/*/nightly.log.

5. Import packages to local Repo.

Now that we have some custom packages we want to generate a local repo which will contain latest nevada and your custom packages. To import latest nevada packages to your local IPS repo you need access to Sun internal servers. You can edit the Makefile located at :

    ~/gate/src/util/distro-import/Makefile

And set the following variables :

NOTE : If you don't have any custom packages leave TEST_PKGS blank.

Save and exit the Makefile. The following manifest file can be used to initialize your pkg/server service back to default values. Before importing you should edit the file and ensure the pkg/inst_root and pkg/port are assigned the correct values e.g. /export/ips/repo and 10000 :

  $ cd ~/gate/src/svc
  $ pfexec svcadm disable pkg/server
  $ pfexec svccfg import pkg-server.xml
  $ pfexec svcadm refresh pkg/server
  $ pfexec svcadm enable pkg/server

Change directory back into distro-import, and using a the specific build number use redist_import script to populate your local IPS repo. e.g. for build 121 :

  $ cd ~/gate/src/util/distro-import
  $ make 121/redist_import

NOTE:This will fail if you have the JDS CBE included on your PATH, e.g. ensure /opt/dtbld/bin is NOT included in your PATH.

This step can take quite a while. In your browser, keep an eye on http://localhost:10000 — it starts get new packages after a while.

After an initial import to your local IPS repo, if you created a new zfs filesystem for your local repo, it's best to create a snapshot at this time, this will allow you to return to a clean initial repo without haveing to re-import everything again :

  $ pfexec zfs snapshot rpool/ips/repo@virgin 

To roolback to this snapshot at a later time you can run the following :

  $ pfexec zfs rollback rpool/ips/repo@virgin 

There are some alternative imports which can be run but they have caveats:

6. Install or Push local test packages into your local repo.

There are a number of methods that can be used to push some custom packages into your local repo.

• 1. Use solaris.py to push into your local repo
  

  To push custom SUNWgui-install into http://localhost:10000 repo :
  

    $ cd ~/gate/src/util/distro-import/
    $ mkdir gui-install
    $ cat > gui-install/SUNWgui-install << EOF
    > package SUNWgui-install
    > import SUNWgui-install
    > end package
    > EOF
  

  The above script may also contain other commands if required such as adding users/groups which might be required by specific packages. See ~/gate/src/utils/distro-import/105/common/SUNWslim-utils as an example of how to create a user. Now create a metafile pointing to the gui-install stuff :
  

    $ cd ~/gate/src/util/distro-import/
    $ cat > gui-install.list << EOF
    > include gui-install/SUNWgui-install
    > EOF
  

  Finally run solaris.py to push the SUNWslim-utils package into the repo :
  

    $ ./solaris.py -b 6.6 -d -s http://localhost:10000 -w ~/slim_source/packages/i386/nightly-nd slim-utils.list
  

  Pay attention to the above. The "-b 6.6" specifies the revision. You just bump it up higher and higher to make sure that version is found. The ~/slim_source/packages/i386/nightly-nd is the directory containing the packages.
  

  You can verify that the right version was pushed with the following :
  

    $ pkg image-create -F -a test=http://localhost:10000 /tmp/test-image
  
    $ pkg -R /tmp/test-image install SUNWgui-install
    DOWNLOAD                                  PKGS       FILES    XFER (MB)
    Completed                                  1/1       30/30      0.0/0.0
  
    PHASE                                        ACTIONS
    Install Phase                                  58/58
    PHASE                                          ITEMS
    Reading Existing Index                           8/8
    Indexing Packages                                1/1
  
    $ pkg -R /tmp/test-image list -av SUNWgui-install
    FMRI                                                           STATE      UFIX
    pkg:/SUNWgui-install@0.5.11,5.11-6.6:20090219T082311Z           installed  ----
  

  Note the -6.6 at the end of the version shown in the list above.
  

  In order for distro_const to include the correct version of your custom package in the ISO, the package entire needs to be rebuilt so that it's manifest includes your package version.
  

  To achieve this firstly go back to your IPS gate source and edit Makefile :
  

    $ cd ~/gate/src/util/distro-import
    $ vi Makefile
  

  Edit the Makefile, and comment out the recreation of entire.incorporation, by changing line :
  

        From : entire: $(BUILDID)/entire.incorporation
        To   : entire: #$(BUILDID)/entire.incorporation
  

  Now edit the specific build entire.incorporation file :
  

    $ vi 121/entire.incorporation
  

  and change the version of the package listed here to your local version e.g. for SUNWgui-install :
  

        From : depend fmri=SUNWgui-install@0.5.11-0.121 type=incorporate
        To   : depend fmri=SUNWgui-install@0.5.11-6.6 type=incorporate
  

  Now re-build the entire package :
  

    $ make 121/entire
    PKG_REPO=http://localhost:10000 ./import_manifest_file \
        entire@0.5.11,5.11-0.`echo 121 | tr -d '[a-z]'` \
        121/entire.incorporation
    PUBLISHED
    pkg:/entire@0.5.11,5.11-0.121:20090903T143856Z
  

  Do a quick restart of the pkg/server, even though I'm not sure it's definitely required. Now check http://localhost:10000, search for package entire, once found click the "manifest" link and browse down to your custom package, the version listed here should be the one you published.

• 3. Import at initial local repo creation time
  

  When your first populate your local IPS repo you could set TEST_PKGS as stated in the section above to point to the location of your custom SVR4 packages, it will automatically grab all packages here and install them in your local repo.

• 4. Re-run redist_import to re-populate your local repo.
  

  Quite similar to previous method, except in this case you already have a populated local repo, you can re-run redist_repo to re-populate your local IPS repo. Before doing so you can set the environment variable TEST_PKGS to point to your custom packages :
  

    $ export TEST_PKGS=~/slim_source/packages/i386/nightly-nd
  

  Then re-run redist_import specifying -e make flag to override environment variables in the Makefile from current shell environment:
  

    $ cd ~/gate/src/util/distro_import
    $ /usr/bin/make -e 122/redist_import
  

NOTE:Options 2 & 3 above can take quite a bit of time depending on network connectivity and hardware specification.

7. Build Distribution ISO.

Ensure SUNWdistro-const is installed :

  $ pfexec pkg install SUNWdistro-const

Now make a copy of the distro XML manifest that you want to use to generate the ISO :

  $ mkdir ~/mydistro
  $ cp /usr/share/distro_const/slim_cd/all_lang_slim_cd_x86.xml ~/mydistro/mydistro.xml
  $ cd ~/mydistro

Now edit ~/mydistro/mydistro.xml :

• Change the distribution name to one of your choice :
  

       From : <distribution name="OpenSolaris">
       To   : <distribution name="MyDistro">
  

• Change url element of <pkg_repo_default_authority> section from :
  

        From : pkg.opensolaris.org/release
        To   : localhost:10000
  

• Change authname element of <pkg_repo_default_authority> section from :
  

        From : opensolaris.org
        To   : myrepo
  

• Optional to remove generation of usb image.
  If you don't want the distro.usb image to be generated then comment out or remove the usb finalizer script from within mydistro.xml. Go to section <finalizer> section and remove/comment out the following <finalizer> section :

     <script name="/usr/share/distro_const/create_usb">
        <checkpoint
           name="usb"
           message="USB image creation"/>
     </script>
  

• If you are using a custom finalizer script to pkgadd custom packages as detailed in the last section below, ensure the required changes are made to the <finalizer> section.

Now run distro_const on this mydistro.xml file to generate your ISO :

  $ pfexec distro_const build ~/mydistro/mydistro.xml

By default this will generate an installation under ZFS dataset :

    rpool/dc

If this filesystem does not exist it will be created. The media once generated will exist in :

    /rpool/dc/media

8. Test Your LiveCD ISO Using VirtualBox.

Boot from /rpool/dc/media/MyDistro.iso.
9. Use of Custom Finalizer script to install custom packages.

An alternative to pushing custom packages into your local repo, and regenerateing the entire package, you could simply use a finalizer script to add these packages to distro_const's default pkg_image area when it is creating the image.

When distro_const is run to create your distro, a number of finalizer scripts are run for the various steps to generate the distribution ISO image. These scripts are defined in the <'finalizer> section within the xml manifest used by distro_const. e.g. mydistro.xml mentioned above.

You can add your own finalizer script to pkgadd your custom packages to the image install area before the distro itself is constructed. The first script is "pre_bootroot_pkg_image_mod", add your custom finalizer install script just after this and just before the "slimcd_pre_bootroot_pkg_image_mod" script. It might look like the following :

   <script name="~/mydistro/add-custom-pkgs">
      <checkpoint 
         name="add-custom-pkgs" 
         message="Add Custom pkgs"/>
   </script>

The script add-custom-pkgs might contain the following :

  $ cat ~/mydistro/add-custom-pkgs
  #!/usr/bin/ksh93

  ADMIN_FILE=/tmp/admin.$$
  cat << \ADMIN_EOF > $ADMIN_FILE
  mail=
  instance=unique
  partial=nocheck
  runlevel=nocheck
  idepend=nocheck
  rdepend=nocheck
  space=nocheck
  setuid=nocheck
  conflict=nocheck
  action=nocheck
  networktimeout=60
  networkretries=3
  authentication=quit
  keystore=/var/sadm/security
  proxy=
  basedir=default
  ADMIN_EOF

  pkgadd  -a ${ADMIN_FILE}  -d ~/slim_source/packages/i386/nightly-nd -R /rpool/dc/build_data/pkg_image SUNWgui-install

This script simply takes a custom SVR4 package version of SUNWgui-install which I have built in ~/slim_source/packages/i386/nightly-nd and installs it to the default package image area /rpool/dc/build_data/pkg_image.

Once you've edited your manifest xml file and added your custom finalizer script entry, just re-run distro_const to generate your ISO as specified in the previous section.

10. Summary And Links

Well done you made it to the end of what turned out to be a lot longer that I had originally planned. If you find errors in the above, please let me know and I will update the blog.

Some resources that I used when putting this blog together :

• Do It Yourself Distro Constructor Notes (SXDE)

Ever wanted to run something past a patching expert ? 

Want to pick the brains of your peers in other companies ?

Lobby to get a patching enhancement implemented ?

Debate what is an appropriate patching strategy and associated best practices ?

Ask other customers if they are seeing the same issues you are ?

Your wait is over.  There are new Patch Forums available to customers with support contracts on http://forums.sun.com.

If you haven't accessed the private contract customer forums on forums.sun.com before, I'm told there's a bit of a "secret-handshake" procedure you must follow for your initial login:

• Go to https://identity.sun.com/amserver/UI/Login?org=self_registered_users&goto=http://sunsolve.sun.com/cwpGoto.do?target=home
• Log in with your Sun Online Account (SOA) username/password as normal.
• Click on "Edit Personal Information" in the menu on the top right of the screen and ensure that you have a "Screen Name" set.  If not, set one here.  This will be the name displayed when you post on forums.sun.com.
• If you are not an Member Support Center (MSC) registered user, click on "Change Contract" in the menu on the top right of the screen and ensure you have one or more support contracts associated with your Sun Online Account (SOA).  If not, associate your support contract number(s) to your SOA.  For MSC registered users, contracts are automatically associated to your SOA.
  
• Go back to http://sunsolve.sun.com/show.do?target=home and click on the "[ Access ]" link under the "Sun Community Forums" section.  This link is only visible if you have a support contract associated to your Sun Online Account.  Your initial access to the Patch Forum must be via this link.
  
• Scroll down the page you are redirected to, you will now see a Forum called "Patches" in the "Private" section.
• Click on "Patches" will bring you to the Patch Forum, http://forums.sun.com/category.jspa?categoryID=162
• If you do not see the "Patches" link, please try and logout of forums.sun.com and then log back in, as sometimes there are issues with single sign on preventing you from seeing the correct links in the "Private" section.  (Alternatively, clear your cookies and follow the above steps.)
  

Please note that the above process need only be followed once, in order to register your "Screen Name" for access to the private contract customer forums on forums.sun.com

For all future access, you may go directly to the Patch Forums and login via the "Login" link on the top right of the screen to see the Patch Forum content.

Patches Forum

http://forums.sun.com/category.jspa?categoryID=162

You can use the "Let's talk patching!" Community Forum to discuss Patching Strategy and Best Practices with peers and Sun folk, including potential enhancements to improve your patching experience.  It is important to note that this is not an official Support channel.  To ensure optimal support, you must continue to raise Service Requests for specific patching issues through the normal support channels, although you may use the Patch Issues sub-forum to see if others have experienced similar issues and know of workarounds or available fixes.  As with other forums of this nature, Sun does not guarantee to answer all questions posted. We'd like your feedback on how you would like to see this forum evolve and keep the questions coming so we can better serve your patching needs!

There are two sub-forums available:

Patching Strategy, Best Practices, and Enhancements

http://forums.sun.com/forum.jspa?forumID=1029

Discussions on patching strategies, best practices, news, and potential enhancements to improve your patching experience.

Patch Issues

http://forums.sun.com/forum.jspa?forumID=1028

Please note that this is not an official Support channel. To ensure optimal support, you must continue to raise Service Requests for specific patching issues through the normal support channels, although you may use the Patch Issues sub-forum to see if others have experienced similar issues and know of workarounds or available fixes.

I hope you find these forums useful!

They are designed to facilitate dialogue between you and other customers and with Sun subject matter experts to help improve your patching experience.

Best Wishes,

One of the fun events I’m involved in is Software Freedom Day Wellington, as part of the wider SFD effort. We’re planning a really fun day, with a whole bunch of things going on, as Brett’s excellent poster suggests -

Barcamp

At a barcamp attendees govern the agenda. We provide rooms and a flipchart and a schedule of times – the attendees decide on the discussions to be held around a variety of topics (from Education to Government, Communities to Business) that interest them at the start of the day. You can check the list of attendees on the registration page to see who else is attending with similar interests to you.

Tech Talks

This year there will be a separate room for tech talks. Rather than a discussion-based format like the barcamp sessions, the talks give attendees the opportunity to present a technical presentation about free and open source software. The tech talk schedule will be decided on the day, with each session broken into shorter timeslots, if needed.

Hackfest

A hackfest will be organised by SuperHappyDevHouse, One Laptop Per Child, and DigitalNZ – a chance to put the DigitalNZ APIs into action! Come hang out all day on our sofas, drink large amounts of coffee and work on your favourite piece of free and open source software. You can also learn about the work of the amazing team from One Laptop Per Child who will be showcasing their machines, and participate by helping to test them.

Installfest

The installfest is being organised by WellyLUG, the Wellington Linux User Group, for those wishing to install free and open source software on their laptops, or home computers. Bring your own machines/laptops along and get advice and support from a team of experts, while you install software. Copies of some popular free and open source software will be available to take away as well.

Makerspace

Wellington has a growing community of makers who share a lot of the same principles as FOSS, using open source technology to create craft, sharing tools and skills when working on solutions to technical projects. We will have a room set aside for makers, so come along and showcase your creations, whether they are gadgets or open source crafts, or work on something you’ve been dreaming up for months.

Kids Programme

A kids programme for primary school aged children will embrace all that’s going on at Software Freedom Day, giving them the opportunity to participate in a variety of activities – taking the first steps into programming at the installfest, testing OLPC laptops at the hackfest, a barcamp brainstorming session about where they think the future of computing is going, and more! Games, prizes and a treasure hunt included.

As part of the kids programme Nat Torkington will be running an hour long ‘Introduction to programming’ session for parents and kids as part of the installfest. Parents – it would be great if you can prepare for the session by downloading scratch from scratch.mit.edu onto your laptops/machines before you come along.

Students Programme

Students (secondary and tertiary) are encouraged to attend Software Freedom Day. Showcase technology you are interested in by registering to do a techtalk and bring your projects along to the makerspace. Hear from tech heros who will be there to address students about working in the industry and learn about how understanding open source solutions can enhance your job prospects. Bring along your laptop and get experts to help you to install open source software and operating systems on your laptop at the installfest, and learn about the work of One Laptop per Child and DigitalNZ how you could contribute to their projects at the hackfest.

So if you’re coming along, make sure you register for the event – we’ll have free wifi, free coffee and a bunch of great prizes to give away! Thanks heaps to our ever growing list of sponsors.

My colleague, Don O'Malley, asked me to post the following on resolving issues using 'wget' to automate patch downloads.  'wget' is a popular download method, and is used by patch automation tools such as 'pca'.

Summary: You can use versions 1.10.x and 1.11.x of 'wget' but not version 1.11.  Details of options to use are set out below.  See also Patch Download Automation using wget.

SunSolve recently migrated to using Akamai for patch and patch cluster downloads, to provide customers with a faster and more reliable experience.

Some customers have experienced issues accessing patches using 'wget'.  Here's information on the issues and how to resolve them:

1) You must use a version of 'wget' which supports 'https'.

Why?

SunSolve's new patch download service is accessed by redirecting requests to https://getupdates2.sun.com, which subsequently redirects to https://a248.e.akamai.net (Akamai).

Which versions of 'wget' support 'https'?

'wget' version 1.10.x or later has 'https' support.

How can I check which version of 'wget' I am using?

Run the command 'wget --version'

2) You must use the '-O' or '--output-document' switch in 'wget' to provide an output filename.

Why?

The Akamai URI identifying a patch is very long.  By default 'wget' will name the downloaded file the same as the URI.  As the filename is too long an error is thrown and the download will fail.

Example of the correct syntax:

# /usr/sfw/bin/wget ---http-user="xxxxxxxx" --http-passwd="xxxxxxx" --no-check-certificate "http://sunsolve.sun.com/pdownload.do?target=119255-01&method=h" -O /tmp/119255-01.zip

Example of some the output for a failing 'wget' request:

140778-01.zip?AuthParam=1251205908_479a27379ab5595128ae9170de4228c9&TUrl=L0QdUQV8Z4i0fdED3QTP3SJDWA8FMyaJsHfIWf4X29kTWQpKEzIbwqFuyRPZ&TicketId=3q3wk1CPNxhU&GroupName=SWUP&BHost=sdlc2h.sun.com&FilePath=%2Fpatches%2Fpatchroot%2Fall_unsigned%2F140778-01.zip&File=140778-01.zip: File name too long

Cannot write to `140778-01.zip? AuthParam=1251205908_479a27379ab5595128ae9170de4228c9&TUrl=L0QdUQV8Z4i0fdED3QTP3SJDWA8FMyaJsHfIWf4X29kTWQpKEzIbwqFuyRPZ&TicketId=3q3wk1CPNxhU&GroupName=SWUP&BHost=sdlc2h.sun.com&FilePath=%2Fpatches%2Fpatchroot%2Fall_unsigned%2F140778-01.zip&File=140778-01.zip' (Error 0).

3) If you are using 'wget' version 1.11.x you must use the '--auth-no-challenge' switch.

Why?

This is related to the manner in which 'wget' 1.11.x sends SunSolve a users Sun Online Account (SOA) information in this version of 'wget' (i.e. via '--http-user' & '--http-passwd'.)

Failure to include the '--auth-no-challenge' with 'wget' 1.11.x requests will result in the SunSolve Software License Agreement (SLA) being downloaded rather than the patch.

Example of the syntax for 'wget' 1.11.x users:

# /usr/sfw/bin/wget --auth-no-challenge --http-user="xxxxxxxx" --http-passwd="xxxxxxx" --no-check-certificate "http://sunsolve.sun.com/pdownload.do?target=119255-01&method=h" -O /tmp/119255-01.zip

Note, 'wget' version 1.11 does not have the '--auth-no-challenge' switch and so is not compatible with patch downloads from SunSolve.

4) You must provide 'wget' with direction on how to handle security certificate information.  Otherwise, patch downloads via 'wget' will fail.

Why?

Domains, getupdates2.sun.com & a248.e.akamai.net, are signed by trusted Certificate Authorities. (Verisign for Sun's and GTE Cybertrust for the case of Akamai.) Without a pointer to these certificates being provided to 'wget', download attempts will fail.

Which certs are required?

CN=GTE CyberTrust Global Root
CN=VeriSign Class 3 Secure Server CA - G2

What kind of error message can you expect to see from a failing 'wget' request?

ERROR: Certificate verification error for getupdates2.sun.com: self signed certificate in certificate chain
To connect to getupdates2.sun.com insecurely, use `--no-check-certificate'.
Unable to establish SSL connection.

Issue resolution:

If you wish to ignore this failure you can use the '--no-check-certificate' switch in 'wget'.  Example of the syntax:

# /usr/sfw/bin/wget --http-user="xxxxxxxx" --http-passwd="xxxxxxx" --no-check-certificate "http://sunsolve.sun.com/pdownload.do?target=119255-01&method=h" -O /tmp/119255-01.zip

If you wish to check against the certificates, you can use the '--ca-certificate' switch to point to a file containing the certificates.

http://sunsolve.sun.com/search/document.do?assetkey=1-9-240066-1 has an attachment called cacerts.pem, which is a concatenation of the two certificates.

If you save this file locally (eg to /tmp/cacerts.pem), you can use a syntax similar to:

# /usr/sfw/bin/wget --ca-certificate=/tmp/cacerts.pem --http-user="xxxxxxxx" --http-passwd="xxxxxxx" "http://sunsolve.sun.com/pdownload.pl?target=142284&method=h" -O /tmp/140778-01.zip

5) You may need to add firewall rules to enable 'wget' to work with SunSolve's new download service.

Why?

As the new download service is accessed by redirecting from http//:sunsolve.sun.com to https://getupdates2.sun.com initially and subsequently to https://a248.e.akamai.net, some customers may need to update their firewall rules to pass traffic from getupdates2.sun.com & a248.e.akamai.net in addition to sunsolve.sun.com.

How can I verify this?

Contact your System Administrator.

6) After associating a new contract to a SunSolve account there is a delay of up to 48 hours before 'wget' downloads will work for patches that the new contract should provide access to.

Additionally, customers registered in the Members Support Center must make an initial 'wget' call (which will fail) in order to trigger the synchronization process after associating a new contract to their party.

Why?

The delay is due to synchronization issues between SunSolve and the back-end access entitlement system.  Work is ongoing to reduce this delay.

What error message can you expect to see until this synchronization is complete ?

HTTP request sent, awaiting response... 403 You are not entitled to retrieve this content.

7) Attempts to download a patch README file by providing "method=r" in the URI is now failing.

Why?

Prior to the latest SunSolve release it was possible to download a patch's README file only via 'wget', using a syntax similar to :

# /usr/sfw/bin/wget --no-check-certificate --http-user="xxxxxxxx" --http-passwd="xxxxxxxx" "http://sunsolve.sun.com/pdownload.do?target=142284-01&method=r" -O /tmp/142284-01.README

There's a bug in the current SunSolve release this no longer works and attempts to download a patch README using this URI will result in a file of 0 Bytes being created.  This will be fixed at a later date.

Workaround:

Use "method=tr" to download a patch README file.  Example command syntax:

# /usr/sfw/bin/wget --no-check-certificate --http-user="xxxxxxxx" --http-passwd="xxxxxxxx" "http://sunsolve.sun.com/pdownload.do?target=142284-01&method=tr" -O /tmp/142284-01.README

This sort of thing always worries me. I really wish we had a more formal way of alerting users that functionality was going to go away, rather than just pulling the rug from under their feet when they install a new release.

At Sun, and I’m sure at most other companies that support software products, we have to tell our customers in advance when (certain) features are going away. We can’t just drop them from one release to the next because we’ve gone off the idea.

Personally, I’d like to see GNOME manage this a lot better, perhaps (from the end user’s perspective) via a section in the GNOME release notes that said which features we intended to remove from the next release. The impact of such changes would then have to be thought through well in advance, and there’d be plenty of time to remove the feature, fix any related issues, and properly update the documentation prior to its actual disappearance. And users would have time to prepare for the change, and have the opportunity to raise any sensible objections before the fact, rather than after it.

(This thought isn’t especially new, nor directly aimed at the proposed Windows capplet removal… although I do know that’s a decision that would generate support calls for Sun users and customers, who always scream when anything related to their sloppy focus settings breaks, changes or goes away. Many of them have been using sloppy focus on UNIX desktops since before GNOME or even Linux were first thought of, so it’s not a feature we like to mess with…)

In the wake of the cash for clunkers scam, the planned obsolescence of a few million televisions, and some misguided efforts to prevent electronic devices from being reused or recycled outside of the U.S., the obvious solution when my digital SLR began acting up should've been to pitch it and get another one. I'd already investigated and discovered that a newer model could be purchased for less than it would cost to send mine in for repair. But since I had nothing to lose, I decided to give it a try. I'm happy to report that this minor repair was a success! One less bit of e-waste.

I intend to put more of this kind of content on opensourcemechanic.com so this blog can grow more focused on Sun/OpenSolaris specific issues.

Quick follow-up on my last post about some ideas for a GNOME control center refresh.

Kristin and Jenya are running a usability study on three control center designs in the Sun labs this week (current GNOME control center as a baseline, plus two of their alternative designs). There will be 10 participants over three days, a mixture of “developers, technical end users, and technical students”.

We will of course share the results as soon as we have any to share

My colleague, Ed Clark, has made significant improvements to the Solaris 10 Recommended and Sun Alert patch clusters.  These improvements have just been released and are in the current clusters available to contract customers from the Patch Cluster & Patch Bundle Downloads on SunSolve.

Ed's improvements include:

• Filtering out "false negatives" from the patch utility return codes, so that if the cluster install script returns "1", you know you've got a real problem which needs investigating.   As you may know, the Solaris patch utility, 'patchadd', can return errors for some acceptable situations - for example, if the patch is already applied to the system, or a later revision of the patch or a patch which obsoletes it is already applied to the system, or none of the packages in the patch are on the target system (e.g. because a reduced Install Metacluster was used to install it or the system has been security hardened by package removal), etc.   Such conditions are acceptable "errors" which do not usually require further investigation by the user.  By filtering these conditions out, if the 'installcluster' script returns "1", you know it isn't because of one of these acceptable "errors", and therefore you need to look at the logfiles to find out what's gone wrong.  For further information, please see the cluster README and Analyzing a patchadd or patchrm Failure in the Solaris OS.

• The new 'installcluster' script will exit as soon as it encounters an unexpected failure - i.e. not one of the acceptable "errors" mentioned above.  This prevents potentially compounding issues by attempting to apply further patches.
  

• The new 'installcluster' script includes context intelligence for patching operations.   It informs the user when zones need to be halted, and it provides phased installation to handle patches which absolutely require an immediate reboot before further patches can be applied.  Such interim reboots are only needed when patching a live boot environment on a system below Kernel patch 118833-36 (SPARC) / 118855-36 (x86) and well as the earlier interim reboot required on x86 related to 'libc.so' patches and Kernel patch 118844-14.  On systems below these patch levels, the 'installcluster' will stop at the appropriate point when patching the live boot environment, and inform the user to reboot and re-invoke the 'installcluster' script.  (In the old cluster install script, it simply tried to carry on blindly past such interim reboots, spewing out error messages, although code in the relevant patches prevented any harm from being done).  These interim reboots, when required, are dealt with relatively early in the cluster install sequence so that once completed, the Sys Admin can leave the rest of the installation to finish unattended and move onto other systems.

• The new 'installcluster' script provides better integration with Solaris Live Upgrade as the user can now specify the Live Upgrade alternate boot environment to patch by name.

• The new 'installcluster' script performs space checking prior to installing each patch, and will halt if it believes there is insufficient space to complete the installation successfully.  For example, this helps avoid non-global zones getting out of sync regarding patch levels with respect to the global zone.  This is an important enhancement as running out of space during patching can potentially leave the system in an inconsistent state and is to be avoided.  Even removing a patch requires space, so immediate removal of a patch which has failed to apply correctly due to space issues should be avoided until sufficient space is freed up and potential issues caused by its partial installation investigated - for example, was the undo.Z file successfully created to enable backout ? (Tip: It may be better to retry the patch installation once space has been freed up rather than patch removal in such circumstances.  Contact Sun Support for instructions if you encounter such issues.).   The space checking enhancements in the 'installcluster' script are designed to prevent such problems occurring.
  

• The messages and log files produced by the 'installcluster' script are clear and well structured.  For example, a "failed" log is created if a patch fails to apply.  See the Cluster README for further information.
  

• The 'patch_order' places patches in an optimal order for installation to avoid known issues - for example, the patch utilities patches are installed as early in the sequence as possible to avoid hitting patch installation bugs which are fixed in the patch utility patches, and the Kernel patch procedural script override patch, 125555 (SPARC) / 125556 (x86), is ordered prior to 137137-09 (SPARC) / 137138-09 (x86) to resolve some known issues.  When patching an alternate boot environment (which is recommended), a small sub-set of pre-requisite patches, primarily the patch utility patches, need to be applied to the live boot environment to ensure correct patching operation.  The 'installcluster' script will check for these pre-requisite patches are halt installation if they are not present, advising the user of the 'installcluster' script option to use to install these pre-requisite patches.   Further patches may need to be installed on the live boot environment to support Live Upgrade.  See the cluster README for further information.
  

• The patches have been moved to a 'patches' sub-directory, to de-clutter the top level directory of the unzipped cluster.
  

• Please see the cluster README file for further information.  Customers should read the cluster README file and look at the Special Install Instructions in the patches within the cluster prior to installation.
  

I really want to thank Ed Clark for the enormous amount of thought and effort he has put into improving the cluster installation experience.   The work he's done on the Solaris 10 Recommended and Sun Alert patch cluster is a continuation of his previous work on the Solaris Update Patch Bundles and the Solaris 10 Live Upgrade Zones Starter Patch Bundle.  Nice work, Ed!

While the 'installcluster' script is copyrighted, I am happy for customers to use it, and the 'patch_order' file, as a starting point for their own customized patch bundles, so long as it is for their own use and is not to be given to a 3rd party or used for commercial gain (e.g. by a 3rd party maintainer or 3rd party commercial automation tool).

We have also made significant improvements to the back end processes to ensure higher and more consistent cluster quality. 

Originally, the clusters were created by the Patch Operations and Distribution (POD) team after patch release.  The POD Cluster QA process left a lot to be desired, resulting in inconsistent cluster quality.   To plug this gap, my Patch System Test team have been testing the clusters for several years, but the old process only allowed us to test them in parallel with their release, which meant that we found issues at the same time that early downloaders of the cluster encountered them.  Although we ensured such issues were fixed as quickly as possible, it still obviously compromised our customers' experience.

In the new process, the clusters are routed to Patch System Test (PST) prior to release.  PST run a transformation script on them to optimize the patch installation order, etc.  The clusters will only be released once they have passed PST testing.  This should ensure higher and more consistent quality for customers.  Work is continuing to move the entire patch cluster generation process to PST, although these future backend enhancements in this regard should be invisible to customers.

SunSolve 7.3.0 Release, Akamai, and Vintage Solaris 8 patch access entitlement

The SunSolve 7.3.0 release was deployed to production August 11th. 

It includes major changes to back-end processes designed to provide a more robust, reliable, and consistent customer experience.  All patch downloads are now serviced by Akamai, which is the same process used by Sun's patch automation tools smpatch, Update Manager, UCE, and xVM Ops Center.

Firewall rules may need to be changed to permit the access to the following systems:

• sunsolve.sun.com
• getupdates2.sun.com
• a248.e.akamai.net

This release also removes Member Support Center (MSC) from the critical path for Solaris 8 Vintage Patch access entitlement.   Prior to this release, Vintage Solaris 8 customers needed to register in MSC in order to access Vintage Solaris 8 patches (created after April 1, 2009).  This was difficult for some customers who needed to undergo a contract clean-up process prior to full registration in MSC.  Now, such customers can simply associate their Vintage Solaris 8 Patch Plan contract number with their Sun Online Account (SOA) using the "Change Contract" link at the top right hand corner of SunSolve pages once they have logged on.  This is now sufficient to grant patch download entitlement to patches covered by any support contract, including Solaris 8 Vintage patches.

Note, customers who are registered in Member Support Center (MSC) will not see the "Change Contact" link as their contract associations are automatically handled by MSC.

For non-MSC users, to ensure access to all patches to which you are entitled, please ensure your associate your Support Contracts with your Sun On-line Account.

Recognition of Support Contract Changes

Support contracts naturally get renewed, upgraded, extended, or expire.  

When a support contract changes - for example a new line item is added to provide support for additional products - then, for non-MSC registered users, to get this additional entitlement "recognized" quickly to enable manual download of access-entitled patches covered by this additional line item, either remove and re-add the Contract number to your Sun Online Account (SOA) using the "Change Contract" link on SunSolve while logged on or else simply log out and log back in again.  Both methods will grant the additional access entitlement as long as the back-end IBIS Contract database has been updated with the modified contract information.

For Member Support Center (MSC) registered users, the contract association will be handled automatically by MSC.    (BTW: A bug in the refresh of IBIS Materialized Views has now been fixed, so delays in automate updates of contract associations by MSC should no longer occur, once the contract amendments have been inputed to the backend database.)

Patch access entitlement information

We will be improving the ability for customers to clearly determine what they are / are not entitled to access in the next release of SunSolve and the new PatchFinder tool (due in October).

In the meantime, when logged into SunSolve, go to the "Change Contract" link at the top right hand corner of SunSolve pages.

This will display the "Entitlement Classes" provided by the support contracts which you have currently associated with your Sun Online Account (SOA).  Displaying the internal "Entitlement Class" names is not ideal and will be improved in the next release, but here's how to interpret them:

• "Public": You are entitled to access Public patches - i.e. patches which don't require a support contract to access them.
• "Solaris8VintageSoftwareUpdates": You have a Solaris 8 Vintage Patch Service plan and are entitled to access Solaris 8 Vintage patches produced after April 1, 2009.  (See previous blog posting on the Solaris 8 Vintage Patch Service plan.)
• "Solaris8SoftwareUpdates": You are entitled to access non-Vintage Solaris 8 patches.
  
• "Solaris9SoftwareUpdates": You are entitled to access Solaris 9 patches.
  
• "Solaris10SoftwareUpdates": You are entitled to access Solaris 10 patches.

There are a couple of additional entitlement classes, some of which are historical artifacts which overlap with the above.  These will be cleaned up in due course.

Did you know:

• You must have a Solaris 8 Vintage Patch support plan in order to access Vintage Solaris 8 patches created after April 1, 2009
• A SunSpectrum support plan or a Solaris 8 Software Subscription entitles you to access non-Vintage Solaris 8, 9, and 10 patches
• A Solaris 9 Software Subscription entitles you to access Solaris 9 and 10 patches
• A Solaris 10 Software Subscription entitles you to access Solaris 10 patches

Another "did you know":

Many documents on SunSolve have a "Document Audience:" of "PUBLIC".  However, in the case of patch README files, this does not necessarily mean that the patches they refer to have "public" access entitlement - i.e. that anyone can download the patch without a support contract.  The README is designed to make folk aware of the existence of a patch they may need.  However, they may still need to purchase a support contract in order to access the patch itself.

Using 'wget' to automate patch downloads

'wget' is a popular and efficient way to automate patch downloads.   Popular patch automation tools such as 'pca' and TLP utilize 'wget' for patch downloads.  Authentication is via the user's Sun Online Account (SOA), so customers should associate their support contracts to their SOA using the "Change Contract" link at the top right hand corner of SunSolve pages once they have logged on.

A version of 'wget' which support https transfers is now required in order to download patches.  For example, the 'wget' version in Solaris 10 supports https transfers.  To check whether the version of wget you are using is linked to SSL (to provide https support), you can use the following command:

# wget --help.

For example, the current development releases of wget (1.12-devel) shows:

   Options: +digest +ipv6 +nls +ntlm +opie +md5/openssl -gnutls
           +openssl +gettext

You also have to have your proxy configured to allow https connections through the proxy with the 'connect' command.

When contracts are added, renewed, or changed, MSC registered 'wget' users now need to attempt a download of a access-entitled patch (which will fail) in order to trigger a resynchronization of their contract data between the backend servers servicing the patch download request.  The modified contract entitlement will then be activated within 8 hours of this initial download attempt.

See Information on using wget for http download including example download script for further information.

Solaris 2.5.1 patch access entitlement removed

Solaris 2.5.1 is past its End Of Service Life (EOSL).   Access to Solaris 2.5.1 patches has therefore been removed.

Vintage Phone support, which includes access to existing patches (but no new patches will be created) is still available for Solaris 2.6 and Solaris 7 until the end of 2009, after which all access to Solaris 2.6. and Solaris 7 patches will also be removed.

I've changed the background "theme" used on this blog as the new theme provides Indexing and RSS feeds which was a requested enhancement.

Thanks to my colleague, Brian Kidney, for finding the theme. 

Otherwise, as Led Zep would say, the song remains the same.