On Thu, 2006-03-23 at 17:46, Dave Miner wrote: > Greetings, Installation community members! > > I've just posted for discussion a document that I've been working on for > the past couple of months: a draft strategy for Solaris installation. ... > I would appreciate review comments by April 14. I encourage posting > comments to this list, but private comments are of course equally > acceptable. > > http://www.opensolaris.org/os/community/install/files/install_strategy.pdf
First thoughts: Section 2 Audience - you're looking at the SMB/Developer segment, and the enterprise segment. This ignores another important class, specifically the lone user. (Some use the term "hobbyist", but I want to avoid that.) The lone user may have the opportunity to play with Solaris - either installing it themselves, or using a system installed by a friend or colleague. This class of user may well become a developer or customer later, and carries their experience with them. They have less experience and knowledge, less motivation, and much lower tolerance than developers. 2.1 You say that the scale of operations is not necessarily large enough to justify complex automation techniques, yet I would argue that (a) automation shouldn't be complex, and (b) automation is justifiable even for single-system setups (think recovery). In other words, while they would not initially have an environment in which automation were possible, we should ensure that they find it as easy as possible to automate procedures thereafter. 2.1.1 We should aim that *everyone* finds the software easy to use. Even "experts" could save time and make fewer mistakes. I've long argued that Solaris gives a very poor first impression - to administrators who have to fight past the first install, to users who get a limited (but improving) environment, to developers whose initial impression is always one of sloth. I like the damning indictment, but would make a minor change: Solaris *interactive* installation is ugly, slow, and difficult. (All Solaris installations are much slower than they ought to be, but the automated tools such as jumpstart do have some strengths.) To be honest, my own experience of the interactive install has been limited. I have done a couple in the last year, and while it's vastly inferior to jumpstart, I managed to get it right without problems - and it wasn't all that much worse than RedHat or FreeBSD. The two biggest problems *I* have with the install: 1. How abysmally painfully slow it is. More on that later... 2. The software selection system is useless. Software selection: the fundamental problem is that there are far too many packages. (Note that the notion of package here does not imply the SVR4 packaging system - I'm simply using a package as a related group of files, and a cluster as a related group of packages.) The way the product is split up into packages and clusters has no relevance to the end user whatsoever. For example, (talking about sparc - similar logic applies to x86) common network drivers such as bge, eri, ce; the fibre channel stack; fault management; basic graphics drivers; SVM itself; PCI drivers; picl; should be removed as separate packages and moved into the core solaris packages. Essentially, any machine up to (say) a V890 should be installable with the SUNWCcs cluster and run. This saves a lot of possible choices, makes it more likely that drivers will be already installed, and removes the urge for administrators to tinker. I'm sure you could go through the other packages and amalgamate extensively. I see no justification for my machine to have 1371 distinct packages installed - how can anyone make sense of that? Then the metaclusters don't make sense. I now start with SUNWCall and start hacking. What I *want* to do is start with SUNWCcs and start adding to it, in meaningful chunks. So there should be many more metaclusters. For example, there should be a JDS metacluster - which contains all the JDS packages and their dependencies. And an X11 metacluster. And a CDE metacluster. Metaclusters can include other clusters and metaclusters, and can overlap. I can imagine a developer metacluster. And a web server cluster. A file server cluster. A mail server cluster. A SAMP cluster - any number of application-specific clusters that would make sense in the SMB space (or for appliances). All metaclusters are complete and self contained - so you never need to do dependency checks. And you build up - the full install is simply all metaclusters. Removing a metacluster doesn't remove all its packages - those packages referenced by other metaclusters (because they're needed as dependencies) are still included. The cluster/metacluster definitions should exist throughout the packages management system, so that I can come along later and add the printing and fileserver clusters if I wish. 2.1.4 Upgrade. I recently upgraded several S10 FCS systems to S10U1 simply by sticking the DVD in the drive, and it was a relatively simple - if slow - process. My systems worked correctly afterwards, which wasn't the case many years ago. Live upgrade is an interesting problem. It's not helped by the fact that Sun sell many systems (even high-end ones) with small numbers of disk drives. While I've used it, it wasn't a pleasant experience. (Its habit of calling sync every few seconds was a killer on one production system I tried it on.) Still, Live Upgrade should be a compelling feature - and using zfs snapshots to manage BEs solves many problems (no need to copy, or allocate space up front). 2.1.7 I can't understand the lukewarm comparison of Solaris install performance with others. "It's the perception that we're slower." It's not a perception: -it's reality. And the gap is *huge*. Experience in the late S9/S10 beta timeframe was that Solaris is slower than (say) RedHat by a factor 5-10. I tested the "go-faster" package tools in S10 beta. Given that comparison with alternative systems indicates that there is a potential for a factor 5-10 improvement, and comparing many of the pkg* tools with emulations using shell tools indicates a similar deficiency, the fact that there was no significant improvement - and in many cases a significant regression - was a huge disappointment. Of course, if Solaris was better packaged into a smaller number of packages, this would also have benefits. There is another performance bottleneck, which is the SMF manifest import. This needs to be sped up or eliminated. 2.2.1 Saving jumpstart - not only from an interactive installation - ideally the install choices would be saved as a jumpstart profile (and sysidcfg file) to a standard location, but also from an installed system, so that you can go to a system, and generate a jumpstart profile and sysidcfg file that would reproduce that system. Section 3 - Requirements. 20. Or select an alternative nameservice. On the same screen as the account set up, have an extra entry with a check box "use a network nameservice for accounts" and a dropdown of NIS/NIS+/LDAP. It may even be possible to guess. I don't see any nameservice integration mentioned - it's a crucial component. 29. Absolutely. But this isn't an installation issue so much as ensuring that the appropriate subsets (metaclusters) are independent of the underlying OS version. Section 4 - Caiman (Let's hope that Caiman doesn't inherit Anacaonda's propensity for crashing.) Perhaps the Solaris best practices should be made availabele and pointed to - are they correct and still relevant? 4.1.1 I talked about metaclusters above. I'm unsure whether a choice of the entire Solaris release is sensible. What services are enabled or disabled? Is it advantageous to discriminate based on system type (if graphical install desktop...)? -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
