One last post before Christmas. Lately I’ve been seeing lots of Linux admins coming to Solaris boxes and getting confused – unable to find the right commands, unaware of the Solaris tools, generally just struggling to get to grips with an unfamiliar operating environment.
I rate Solaris very highly – it comes with some amazing tools, and is superbly tuned to the needs of the enterprise. This isn’t always aligned with the needs of developers and hackers, though – but once you get comfortable with the tools in Solaris, you’ll start to wonder how you managed without them.
I was going to type up a nice long document, but then I remembered that Ben Rockwood, over at Cuddletech, had already written An Accelerated Introduction to Solaris 10.
It’s a good read, and should help bring anyone up to speed who has a Linux background. One thing – please please take the time to read up on RBAC (linked from Ben’s post). RBAC is infinitely more powerful than sudo, and you will find RBAC+LDAP a totally invaluable skill to use within the datacentre.
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.
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.
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.
In 2005 I was having some issues with big F15k domains. They have a mix of 1gb/s and 100mb/s network cards, which all used the same Solaris driver family. Setting the port speeds meant editing the ce.conf file, and any typos or mistakes here either hung the kernel on boot (not good news in a big F15k domain) or just ignored the settings.
I ended up writing a script that would automatically work out what ce cards were present in the Solaris domain, and then automatically generate a ce.conf configuration file. The script grew in complexity when it became clear the F15ks and mid-frame machines (SF6500 etc.) had a radically different PCI addressing scheme.
I ended up writing and submitting a tech tip to Sun’s BigAdmin website. You can read the whole sordid story at http://www.sun.com/bigadmin/content/submitted/config_ce_cards.html
