Anyone who has jumpstarted a Sun box using Solaris anytime in the last 13 years has relied on the add_install_client script to do all the hard bits, like setting up the inetboot file in /tftpboot, and adding entries to the /etc/ethers and /etc/bootpararms. The add_install_script took a fair amount of the complexity that you might have to do by hand and did it for you, despite the fact that the parameters required to drive add_install_client can give the typing fingers a real workout.

Ever really looked at /etc/bootparams?

There's about a paragraph worth of stuff in there for each system that will get built describing to the client what things it needs to boot and install Solaris. I remember having to setup multiple servers and all the typing that entailed. I seem to recall building a table of systems and using a while; do loop to call add_install_client repeatedly. Not that I'm a bad typist, but why should I type all that crud out manually? I can't recall the number of times I couldn't get a system net-booting because I fat-fingered something like the ether address or path or something. And how would I really know, unless I had been using a command line shell with history features to see what I had really called add_install_client with?

However, bootp is not a great protocol for booting unless it's contained to a single subnet. The BOOTP requests don't pass through routers, and therefore, you needed to have a boot server on each subnet, so that a net-booting client could get it's initial boot load. Once the intial boot load happened, it could then talk to an install server on a different subnet. Not terrible, but it further complicates the issue by requiring a setup for the install server as well as the boot server.

As it turns out, since DHCP configurations can be passed through routers, you no longer need a boot server on each network to PXE or DHCP boot a Solaris system. This allows you to keep all your jumpstart configurations in one place, even if you have multiple jumpstart servers, as is done in large installations or like some of the factories in Sun.

Dawn of DHCP support for jumpstarting

I don't know exactly when this happened. It's only been in the last four or five years because an old Ultra-AXe box I have in the lab won't dhcp boot. (boot net:dhcp - install) The support for DHCP in add_install_client then fundamentally changed the behavior of add_install_client. Now, when you call add_install_client with the appropriate parameters to do a DHCP/PXE jumpstart, what you get is a list of DHCP macros that you have to plug into your local DHCP server, along with the requisite files in /tftpboot to get your client netbooting. If you thought /etc/bootparams was bad, configuring the DHCP macros is substantially worse, especially if you've never configured a DHCP server before. Not to mention, each different DHCP server has it's own syntax (SUN, ISC, Microsoft, etc et al). And it's not just a set of information that you have to configure, but there's also this concept of "supported architectures". Assuming you've been DHCP booting a bunch of V240's and the boss brings a new V440 up to the lab for you to jumpstart. You configure the add_install_client, punch boot net:dhcp - install and *nothing* happens. Well, not in the way you expect. You'll see things like timeouts and fallbacks to bootp perhaps, but it won't boot.

Whiskey-Tango-Foxtrot? Turns out that you have to inform the DHCP server, and all the SYMBOL macros that you now support the V240 and the V440, which requires approximately X lines of macro changes, based on the number of SYMBOL macros you have defined in your DHCP server which supports jumpstarting. A minimum number will be something like 8 and could be as high as 16. You go back and you fix your DHCP tables, and maybe you just go ahead a pre-populate any of the architectures for systems you might be DHCP jumpstarting, remembering to transform the "," to a "." so you dont' have to fool with the SYMBOL macros again. ( uname -i | sed 's/,/./' )

DHCP Macros for jumpstarting

/etc/bootparams looks really good right now, especially if you're fighting the DHCP server and trying to get things working. If you think the pain is not worth the effort, let me suggest the Jumpstart Enterprise Toolkit, aka JET which takes the complexity of jumpstart and put's all the typing and configuration into a single file. Make a typo? Review your template and remake the client. Need to tweak something, modify the template and remake the client. For some people, this is just *too* hard, but if you're like me and you want to figure out how you jumpstarted a system from 6 months ago, this is the tool to use. Do you have to care about DHCP servers when using JET? Nope. Well, unless you aren't running a Sun DHCP server. Do you have to worry about parsing the output of add_install_client? Nope. So where's the rub? Do you really want to become a DHCP/PXE macro guru? Do you think it's more important that you have really cool and complicated macros, or do you want a tool which sets up the client for you? If you fall into the first category, have at it. If all you really want is a framework to help you jumpstart your systems, then JET is the tool for you.

PXE Booting and how it relates to DHCP

When you call add_install_client (either manually or using a front end like JET) for a DHCP configuration, add_install_client sets up the information in /tftpboot, like you would expect to see. However, instead of populating /etc/bootparams, it nows gives you a list of DHCP macros, with values that you need to populate. JET does all the population of the DHCP macros for you (and if you run remove_client, will take them out of the DHCP tables).

The two DHCP macros that are required to PXE boot a system are the BootSrvA and BootFile. add_install_client tells you to put the BootSrvA macro in the PXE macro (PXEClient:Arch:00000:UNDI:002001). For the most part, we have figured out that this is kind of problem. If you happen to have a multihomed jumpstart server, having the BootSrvA macro in the PXE macro means that you can only have one network you boot from. Unless you then populate other macros with a BootSrvA macro, such as a network or client macro. So what's the point? Why bother with the PXE macro??? I think it just complicates the issue and by putting the BootSrvA in the client macro, you control that client. Some folks like to do anonymous jumpstarts where you can come in and plug your laptop and install it without having to do anything else than pinch a network port. From a security perspective, this is a bad idea. This means that at any time, a user could take one of your PC's and install an OS from the network and you don't have any control over it. The second macro required to PXE boot is BootFile, which is the Network Boot Program (nbp). It is currently a real mode binary which is responsible for collecting the rest of the client configuration information from the DHCP server, checking for a custom bootenv.rc file (usually named /tftpboot/01<MAC address>.bootenv.rc) on the tftpboot server and the inetboot file specified by the SbootURI macro. It starts the inetboot binary which then starts the kernel and you are on your way to PXE booting a Solaris X86/X64 system.

Per node bootenv.rc file

In Solaris 9, U6 (04/04), the concept of a per-node bootenv.rc was introduced. This file is created when you pass add_install_client a "-b variable=parameter" construct. If add_install_client sees that flag, it generates a custom bootenv.rc taken from the net-boot image, and applies the changes you specified with the -b flags. In this case, you can do things like disable acpi for the install, set the serial port to be the console, or set the boot-args to "- install nowin" like:

add_install_client [bunch of jumpstart variables] -b acpi-user-options=0x2

or

add_install_client [bunch of jumpstart variables] -b input-device=ttya -b output-device=ttya

or

add_install_client [bunch of jumpstart variables] -b boot-args=\"- install nowin\"

The last variable sets up the boot-args so that when the system boots, you no longer have to hit "2" to do a customized jumpstart, such that an Solaris X86/X64 jumpstart can be completely hands off (at in Solaris 10).

Somehow I just think I've made a bad decision. I just signed up to put my personal thoughts on the corporate sponsored blarg site, and I am not one to sit back idly and keep quiet. I'm sure a bunch of people who know me would agree. I don't know why I've not bothered up to this point. I've been posting on Usenet and other mailing lists for years, and with things like google, everything I might have ever written is kept someplace. Yeah, that makes me really happy. I think back to all the stupid posts when I thought *I* knew it all, had really bad days [the kind that makes people think you didn't take your medication], or was just being argumentative to the point of flames, and just shake my head. At least after all this time, I've realized the futility in arguing with folks who already have their minds made up, and just try to help those willing to ask for help or at least consider an alternative. For the most part that's worked. I've met a bunch of folks in person, both inside and outside of Sun, from my dealings with mailing lists such as the Yahoo Groups SolarisonX86 list and while it may just have been a lunch with a guy in Dallas in the West End, or a long phone call from someone in Canada whom I'd never talk to before who thought I was having a really bad day, I'm happy to call those folks friends. It makes me realize how very lucky I am, despite the fact that we don't have much interpersonal interaction without influences of a sequence of zeroes and ones.

But since I just did my first ever presentation, at CEC 2005 in San Francisco, I realized I'm now officially published with something more than a stream of consiousness response in a public forum. With a deck of slides I put together by myself with Star Office, and the requisite head-banging having to learn the ins and outs of Star Present, formatting help from some co-workers and a fair amount of reviews from peers, it's official now. Obviously, the CEC selection panel must have thought I had something important to talk about. So here I am, jumping into the deep end of the blarg. Great, now I have to think about what I say and how I say it. Thank goodness for "Save as Draft" At least if I'm not talking technical, I can write without having to go check the list of "do's" and "don'ts" to make sure I haven't violated rules of the blarg. (And wondering if my English professor from WVU would approve of my grammar. I have a tendency to run-on...) Unless I'm talking about something like how things work, what management is doing (which by the way, is one of the great reorg-ing mysteries of the world) or the big list of "do nots", I hope I can stay below the blarg police radar.

But, other engineers in the company are doing it, and it's a fairly innocuous way for other folks who don't troll mailing lists in the company to see what guys like me are dealing with from a corporate, technical or social perspective. Another way to get published. And as I sit and write this stuff, I realize I'm now going to have to learn HTML, something I've been avoiding for at least 10 years. What's a systems guy to do? I didn't get a degree in English, Creative Writing or Desktop Publishing. My degree is in Computer Science. The stuff in my head is all very technical and process driven, and up to this point, I've never really considered how to pretty it up on a web page. Heck, it's not like there's 10,000 other pieces of technology that I need to learn for my job. And this past weekend, even mangement has admitted they don't know what an "Engagement Architect" is supposed to do, which is now my official job title having originally been re-hired as a "Systems Engineer" after being RIF'd as a Cluster Services Methodology Developer. :-(

So will anyone really care what I have to say? Probably not. There's a bunch of stuff going on in my life that won't appear here because it's not really an appropriate forum for it. But folks will care about the technical content, which according to the blog stats, is what seems to tweak the public's interest.

CLB: may as well start early.

So what's the point of $7.6B in cash if the GAAP rules won't let you spend it because it comes off an asset? I'm really getting tired of that story, especially because I've come to realize all it is, is "spin". As far as I'm concerned, it's just a virtual carrot. It doesn't really exist other than to serve up as good press for the employees to hear at corporate meetings to believe that the company will stay afloat. The constant reorging, rifs, travel restrictions and expense reduction policies only serve as a warning sign. Yes, this is a technology business and the market changes very quickly. Hardware is more and more becoming commodity, and the JES software licensing at $100/head only validates the point. So where is Sun going? Services seem to be a very good way to bring in recurring revenue of substantial margin, but the mantra we hear is that "we don't want to become IBM GS". I look at their stock price and I have to wonder. The model of recurring revenue streams in services works really well if you get the long term contracts, even if the going rate is less. Having to do a couple of weeks at a time only incurs the overhead of creating, funding, staffing and implementing a project. The only thing the $7.6B in cash probably does is stave off someone buying Sun for $6B in cash and floating a $7.6B loan for the duration of procedures. In that context, I wonder what the future will really bring.

Enough rantings of another pony-tailed geek. Later!