UNIX Consulting and Expertise
Golden Apple Enterprises Ltd. » Posts for tag 'flar'

Solaris 9 branded zones Comments Off on Solaris 9 branded zones

Looking for UNIX and IT expertise? Why not get in touch and see how we can help?

Solaris zones are great for handling all those dev and test environments that seem to breed like cockroaches. The problem recently has been that lots of these environments have been on old sun4u architecture machines (which were cheap), whereas they should be on shiny new sun4v architecture machines (which are great for this sort of work).

Enter branded zones. Unlike a normal zone, which installs from the global zone, a branded zone uses a flar (Solaris flash archive) to install a different Solaris OE. In this case I’m going to go through setting up a Solaris 9 sun4u branded zone on a Solaris 10 sun4v T2000.

First of all, we need to apply a quick kernel patch to Solaris 10. Currently I’ve got:

bash-3.00# cat /etc/release 
                       Solaris 10 8/07 s10s_u4wos_12b SPARC
           Copyright 2007 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                            Assembled 16 August 2007

For branded zones for this OE, we need to apply kernel patch 127111-01 at a minimum. Once that’s in place, it’s over to Sun’s website to download the branded zones support files.

There are two different packages – one to support Solaris 8 branded zones, and one for Solaris 9. Head on over to http://www.sun.com/software/solaris/containers/ and download the one you need.

Once you uncompress the TAR file, there’ll be a README, which explains minimum patch levels, and which version of the branded zones package you need to install. For Solaris 9 on the 8/07 release of Solaris 10, I need to install version 1.0 of the Solaris 9 containers.

Installation is pretty simple:

bash-3.00# cd /var/tmp/s9containers-bundle/1.0/Product/
bash-3.00# pkgadd -d `pwd` SUNWs9brandr SUNWs9brandu SUNWs9brandk

pkgadd will go away and do it’s thing – answer ‘yes’ to all the questions, and in a couple of minutes the packages are in place. And that’s it – you’re done! Time to install those branded zones.

Zone configuration is pretty standard, except we need to tell Solaris we’re installing a specific branded zone:

bash-3.00# zonecfg -z test-zone
test-zone: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:test-zone> create -b
zonecfg:test-zone> set brand=solaris9
zonecfg:test-zone> set autoboot=false
zonecfg:test-zone> set zonepath=/export/zones/test-zone
zonecfg:test-zone> add net
zonecfg:test-zone:net> set physical=e1000g1
zonecfg:test-zone:net> set address=192.168.13.251
zonecfg:test-zone:net> end
zonecfg:test-zone> verify
zonecfg:test-zone> info
zonename: test-zone
zonepath: /export/zones/test-zone
brand: solaris9
autoboot: false
bootargs: 
pool: 
limitpriv: 
scheduling-class: 
ip-type: shared
net:
 address: 192.168.13.251
 physical: e1000g1
zonecfg:test-zone> verify
zonecfg:test-zone> commit
zonecfg:test-zone> exit

Note that the only real difference during zone configuration is branding the zone. Normally we wouldn’t specify the brand, and it would default to ‘native’.

Once the zone is configured, we need to install it. As we’re installing a branded zone, we can’t take the Solaris files from the global zone, so we need to use a flar as our boot image.

The process is very straightforward – we just supply the path to the flar as an argument to our zone install command:

bash-3.00# zoneadm -z test-zone install -u -a /mnt/flars/sun4u_sol_9_Generic_118558-11.flar 
      Log File: /var/tmp/test-zone.install.4436.log
        Source: /mnt/flars/sun4u_sol_9_Generic_118558-11.flar
    Installing: This may take several minutes...
Postprocessing: This may take several minutes...

        Result: Installation completed successfully.
      Log File: /export/zones/test-zone/root/var/log/test-zone.install.4436.log

And we’re done. Now just boot the zone and carry out the initial configuration as per normal.

Finally, a quick check to show off our sun4v architecture machine running a Solaris 9 sun4u branded zone:

bash-3.00# uname -m
sun4v
bash-3.00# cat /etc/release 
                       Solaris 10 8/07 s10s_u4wos_12b SPARC
           Copyright 2007 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                            Assembled 16 August 2007
bash-3.00# zoneadm list -cv
  ID NAME             STATUS     PATH                           BRAND    IP    
   0 global           running    /                              native   shared
   5 test-zone        running    /export/zones/test-zone        solaris9 shared
bash-3.00# uname -a
SunOS sunt2k-test 5.10 Generic_127111-01 sun4v sparc SUNW,Sun-Fire-T200

Extracting a file from a Solaris flar Comments Off on Extracting a file from a Solaris flar

Looking for UNIX and IT expertise? Why not get in touch and see how we can help?

So, as covered in a previous post, Solaris Flash Archives give us a nice way to image a Solaris installation, and then to use that to build a machine via Jumpstart.

The process isn’t all one way, however, and sometimes you’ll want to have the ability to pull apart a flar and see what’s inside. Case in point: trying to debug some Jumpstart issues for a client, where some odd configuration was being set. It wasn’t being set during Jumpstart, and it wasn’t being set during the application install.

This just left the flar as being a possible culprit – but how to pull out a single file to check?

A Solaris Flash Archive is just a cpio archive, which means we can use the cpio command to play around with it. However, flars have some padding and extra sections – if you directly try to use cpio on it, you’ll get a lot of errors about ‘skipped XXX bytes of junk’.

We first need to pull apart the flar into archive, header, etc. sections – and we can do this directly with the flar command:

grond # cd /var/tmp
grond # mkdir flar_hacking
grond # cd flar_hacking/
grond # flar split /export/install/flars/sol9_0905_sun4u.flar
grond # ls -l
total 3907142
-rw-r--r--   1 root     root     1999449088 Dec 15 17:14 archive
-rw-r--r--   1 root     root          18 Dec 15 17:12 cookie
-rw-r--r--   1 root     root         461 Dec 15 17:12 identification
-rw-r--r--   1 root     root        4334 Dec 15 17:12 postdeployment
-rw-r--r--   1 root     root        1339 Dec 15 17:12 predeployment
-rw-r--r--   1 root     root         898 Dec 15 17:12 reboot
-rw-r--r--   1 root     root          53 Dec 15 17:12 summary

We can see that the flar split command has given us our archive, which is where all the files actually are, as well as the other extra sections which make the flar more than just a cpio archive.

Now that it’s split up, we can use cpio directly. In this case, I want to check to see if /etc/default/init is in the flar:

grond # cpio -it < archive | grep etc/default/init
etc/default/init
3905174 blocks

And there it is - so now we can use cpio again to extract the file:

grond # cpio -ivdm etc/default/init < archive
etc/default/init

cpio will extract the file, but relatively to your working directory, and not the root, so we won't be in danger of overwriting anything important:

grond # ls -lR etc/
etc/:
total 2
drwxr-xr-x   2 root     root         512 Dec 15 17:15 default
etc/default:
total 2
-r-xr-xr-x   1 root     sys          490 Oct  5  2007 init

And there's the file we wanted, extracted from the relevant Solaris flar. In this particular instance, it was indeed responsible for the bogus configuration being pushed out.

Easy imaging of Solaris using flars – Solaris Flash Archives 3 comments

Looking for UNIX and IT expertise? Why not get in touch and see how we can help?

As previously posted about, the Solaris install is a bit of a slug due to the way the package manager processes the huge amount of files contained in a package.

Flash Archives (flar files) are one solution to this problem. Let’s say you’ve built a model install – everything is in place, all your custom packages, banners, OE tweaks – the works. Wouldn’t it be nice if you could take an image of that Solaris install, to slap down somewhere else?

Or maybe take point in time image snapshots of an environment, for use by developers to let them quickly roll back to a known previous version of their software?

Flash archives let you do all of this. At their most basic, they’re a way of taking an image of a Solaris install. You end up with a single (large) file, which can then be archived/transferred/restored/whatever.

flars are easy to use – the flarcreate command is all you need:

bash-3.00# flarcreate -n "T2k Sol10 8/07" -x /var/flars -R / /var/flars/sun4v_sol_10_Generic_120011-14.flar
Full Flash
Checking integrity...
Integrity OK.
Running precreation scripts...
Precreation scripts done.
Creating the archive...
2019951681 blocks
Archive creation complete.
Running postcreation scripts...
Postcreation scripts done.

Running pre-exit scripts...
Pre-exit scripts done.
bash-3.00#

The syntax is pretty straightforward:

  • -n specifies the name you’re giving to your flar
  • -x says what files and directories to exclude – in this case, we don’t want to include the directory where we’re creating and storing our flars
  • -R says where the root of the flar will be – in this case we’re imaging a full Solaris install, so we want to start from /
  • and the final part is the full path and filename of the flar we are creating

One thing that it’s important to remember, is that flarcreate will follow symlinks and mount points. If you have a 100gb /export/home, it will try and add that to your flar. This may not be what you want – especially if you’re creating a Solaris image for Jumpstart – so flars are best created from single user mode, when the system is idle and nothing unnecessary is mounted or running.

Another important point to note is that flars are hardware class dependant. If I create an image of a sun4v Solaris install (in this case, a trusty Sun T2000) then the flar will just contain the kernel and driver files for sun4v. If you try and boot a sun4u box (like a Sun V440) it’s going to go horribly wrong.

If you want to use flars to Jumpstart machines, you’ll need to have a master flar image for each machine hardware class you have in your estate – we can find this out with the uname command:

bash-3.00# uname -m
sun4u

We can use flar info to query a flar file to see what it contains:

bash-3.00# flar info sun4v_sol_10_Generic_120011-14.flar 
archive_id=afe30bf4ebb65085a54c5179a6f62a1c
files_archived_method=cpio
creation_date=20081118211329
creation_master=sunt2k-001
content_name=solaris_10_4v_Generic_120011-14
creation_node=sunt2k-001
creation_hardware_class=sun4v
creation_platform=SUNW,Sun-Fire-T200
creation_processor=sparc
creation_release=5.10
creation_os_name=SunOS
creation_os_version=Generic_120011-14
files_compressed_method=none
files_archived_size=4039903362
files_unarchived_size=4039903362
content_architectures=sun4v
type=FULL

And that’s it, basically. There’s not much to it, and it’s pretty simple to use. flars function in pretty much the same way as a normal archive file – we can use the flar command to list files inside the archive and find out more about the archive itself.

Why does Solaris take so long to install? Comments Off on Why does Solaris take so long to install?

Looking for UNIX and IT expertise? Why not get in touch and see how we can help?

It’s a common complaint, and it’s a very valid one. No one could ever accuse the Solaris installation process of being speedy. Even with all the CD swapping,the IRIX install is faster – and that’s saying something.

Each time the Solaris package installer, pkgadd, adds a new package, it rewrites the entire contents of /var/sadm/install/contents – in order. This is how the package manager keeps track of the package manifest, and this is a design flaw going way back to the days when AT&T and Sun came up with the idea of SVR4 UNIX. They just didn’t plan for over 10,000 files spread across over 1,000 packages, which is what a normal install of Solaris slaps down.

A potential solution that was floated for Solaris 10 was to use SQLite to handle the package database, but that uncovered another problem – performance tanked even further on small memory systems.

The real solution? Stop using flat files – but that’s an architecture decision that has lots of consequences for backwards compatibility. OpenSolaris is addressing this with an entirely new package management system. So far it’s looking pretty slick.

In the meantime – what to do? Install from flash archives – flars – and preferably via Wanboot. I’ll be blogging more about those two technologies shortly, but they can have a hugely beneficial impact on your Solaris estate.

Top of page / Subscribe to new Entries (RSS)