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

Installing OpenSolaris with the Automated Installer Comments Off on Installing OpenSolaris with the Automated Installer

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

One of the new features of OpenSolaris is AI – the Automated Installer. If you were hoping to use your existing Jumpstart setup to install OpenSolaris over the network, get ready for some disappointment – it won’t work.

AI replaces Jumpstart for network installs. If you’re deploying OpenSolaris from scratch, this is fine – build one machine manually, set it up as an AI server, and roll out the rest. If you’ve got an existing Solaris infrastructure, however, this becomes a pain of a pain. An additional issue to take into account is that AI can only deploy OpenSolaris to SPARC machines which support WANBoot – so you’ll need to check your OBP versions.

This is the current matrix of what can be installed and how:

OS Install methods OS that can be installed
Solaris Jumpstart
Jumpstart + JET
Solaris SPARC
Solaris x86
OpenSolaris AI
Jumpstart
Jumpstart + JET (4.7)
Solaris SPARC
Solars x86
OpenSolaris SPARC
OpenSolaris x86

I’m sure lots of people are in no hurry to migrate their Jumpstart server to OpenSolaris – especially as it’s probably a SPARC box.

The big advantage of AI is that it’s very easy to get going. I’m going to work through deploying AI to demonstrate how simple it is. In this environment, the OpenSolaris machine that will be used as an AI server is also my workstation. I’ve got a Netra T1 running a complex Jumpstart + JET setup with lots of customisations – I don’t want to replace that, but I do want to use it’s DHCP server.

AI is managed via the installadm tool. It’s probably not installed on your OpenSolaris machine by default, so you’ll need to add it:

pfexec pkg install SUNWinstalladm-tools

Once you’ve got the tools in place, you need to setup the install server. Download an OpenSolaris image – but be careful! The Live CD ISO cannot be used to setup an AI server, you have to download the AI version of the ISO.

Head on over to http://hub.opensolaris.org/bin/view/Main/downloads to grab the relevant ISO.

Once you’ve got the ISO, you can setup the install server. It works based on services – each OS release for each platform is treated as a different service. The you add clients, and tell the client which service it will use to boot from.

I’m going to be sticking AI under /export – the traditional place in Solaris for shared filesystems. I just want to create one install service for OpenSolaris 06/09 x86, which I’ll call 0609×86.

The full command line is:

installadm create-service -n (service_name) \
	-s (source_AI_ISO) (AI_service_data_directory)

Here’s the full command line along with the output:

[email protected]:/export# /usr/sbin/installadm create-service -n 0609x86 \
	-s /export/torrents/osol-0906-ai-x86.iso \ 
	/export/aiserver/osol-0906-ai-x86
Setting up the target image at /export/aiserver/osol-0906-ai-x86 ...
Registering the service 0609x86._OSInstall._tcp.local

Detected that DHCP is not set up on this server.
If not already configured, please create a DHCP macro
named dhcp_macro_0609x86 with:
   Boot server IP (BootSrvA) : 192.168.13.100
   Boot file      (BootFile) : 0609x86
   GRUB Menu      (GrubMenu) : menu.lst.0609x86
If you are running Sun's DHCP server, use the following
command to add the DHCP macro, dhcp_macro_0609x86:
   /usr/sbin/dhtadm -g -A -m dhcp_macro_0609x86 -d :BootSrvA=192.168.13.100: \
	BootFile=0609x86:GrubMenu=menu.lst.0609x86:

Additionally, if the site specific symbol GrubMenu
is not present, please add it as follows:
   /usr/sbin/dhtadm -g -A -s GrubMenu -d Site,150,ASCII,1,0

Note: Be sure to assign client IP address(es) if needed
(e.g., if running Sun's DHCP server, run pntadm(1M)).
Service discovery fallback mechanism set up

Helpfully, installadm tells us what commands to run on our DHCP server. First we’ll need to add the GrubMenu symbol (it won’t exist by default) and then we can add in the DHCP macro for the service. Just copy and paste the two commands on your Jumpstart server.

With that out of the way, we can now setup a client. In this case, I have a Sun v20z with a MAC address of 00:09:3d:12:ff:80 on bge0.

We need to run installadm to create the client, giving it the MAC address and telling it which install service to use. The command line is:

installadm create-client -e (MAC_address) -n (AI_service_name_to_use) \
	-t (AI_service_data_directory)

Here’s the full command line with the output:

[email protected]:/export# /usr/sbin/installadm create-client \
	-e 00:09:3d:12:ff:80 -n 0609x86 \
	-t /export/aiserver/osol-0906-ai-x86
Setting up X86 client...
Service discovery fallback mechanism set up

Detected that DHCP is not set up on this server.
If not already configured, please create a DHCP macro
named 0100093D12FF80 with:
   Boot server IP (BootSrvA) : 192.168.13.100
   Boot file      (BootFile) : 0100093D12FF80
If you are running Sun's DHCP server, use the following
command to add the DHCP macro, 0100093D12FF80:
   /usr/sbin/dhtadm -g -A -m 0100093D12FF80 -d :BootSrvA=192.168.13.100: \
	BootFile=0100093D12FF80:GrubMenu=menu.lst.0100093D12FF80:

Note: Be sure to assign client IP address(es) if needed
(e.g., if running Sun's DHCP server, run pntadm(1M)).

Once again installadm will helpfully tell us what commands we need to run on our DHCP server to add the macros for this client.

Over on the Jumpstart server, here’s the output of dhtadm showing us the configured macros on the Sun DHCP server (with some line breaks to make it a bit more readable):

bash-3.00# dhtadm -P
Name                    Type            Value
==================================================
dhcp_macro_0609x86      Macro           :BootSrvA=192.168.13.100: \
	BootFile=0609x86:GrubMenu=menu.lst.0609x86:
0100093D12FF80          Macro           :BootSrvA=192.168.13.100: \
	BootFile=0100093D12FF80:GrubMenu=menu.lst.0100093D12FF80:
v20z                    Macro           :BootFile=0100093D12FF80: \
	BootSrvA=192.168.13.101:
192.168.13.0            
GrubMenu                Symbol          Site,150,ASCII,1,0

I’ve removed all of the other stuff that Jumpstart puts in there to clearly show the AI macros that have been added.

At this stage, we can just SSH into the V20z’s ILOM, power on the chassis, and go into the BIOS to change the boot order. PXEboot will then send out a DHCP request, and we’ll then see the OpenSolaris grub menu.

From that point onwards it’s a hands-off install. For more details on the entire process, have a read through the OpenSolaris Automated Installer Guide.

Having played around with AI for a bit now, I’m not that impressed to be honest. I can see that it could be easier for new users who’ve never touched Solaris before – as you can see, it doesn’t take much to setup an install server and configure clients.

However, there’s a big installed base of Solaris users out there, and they’ve all got Jumpstart. AI lacks the features, flexibility and power of Jumpstart – it’s not ready as a replacement just yet. So being forced to use it to be able to deploy OpenSolaris just means many existing Solaris shops won’t bother – integration with Jumpstart for OpenSolaris could well speed up it’s acceptance and adoption.

With so many Solaris users out there I think that OpenSolaris needs a lot of work to become a credible upgrade or migration path. Both AI and the new IPS packaging system show promise, but they’re a long way from being usable replacements to existing Solaris technologies.

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.

Top of page / Subscribe to new Entries (RSS)