I agree with Octave. I would also point out that AI as currently proposed in not an automatic installation it is a automatic provisioning, the two are not the same thing. Provisioning requires a pre-discovery phase, whether manual or not, and installation does not. Installation decisions are made *at* install time provisiong decisions are made *before* provisioning.
A concrete example. A server with > 2 disks which will have local disk used only as a mirrored root and the others are not required. With a begin script I can ensure that I have at least two working disks in the chassis and use them, I don't need to know a priori which disks to use, nor what manufacturer nor even what size the disks are because my begin script can make those decisions at install time. The second problem that I see is that there is currently one mechaism for media based or network customized installations (jumpstart ), it now appears that this will not be possible - really bad for OEMs with customized installations. -----Original Message----- From: [email protected] [mailto:desktop-discuss-bounces at opensolaris.org] On Behalf Of Octave Orgeron Sent: 26 March 2009 02:31 To: Bart Smaalders; Greg Jumper Cc: Eric J. Ray; Casper.Dik at Sun.COM; Jon.Aimone at Sun.COM; desktop-discuss at opensolaris.org; sysadmin-discuss at opernsolaris.org; nv-users at Sun.COM; Lubomir Sedlacik; nv_re at Sun.COM Subject: Re: [desktop-discuss] Does the AI opensolaris autoinstallation havethe post script just like the postscripts in the jumpstart This is an important discussion as AI is an extremely new framework and will take time for customers and 3rd party vendors to adapt to. I think custom jumpstart frameworks for most companies include the following: 1. Storage (disk mirroring, configuration of volume managers, formatting of disks, etc.) 2. Installation over the net of flash archives or pkg install 3. Installation of patches 4. Security hardening(usually before the first boot up off the disks) 5. Custom packages, scripts, etc. 6. Special configurations (IPMP, MPXIO, NFS shares, etc.) 7. Naming services (LDAP, Kerberos, RBAC, NIS, etc.) 8. Install applications, monitoring tools, backup software, etc (sun explorer, vts, jass, etc.). Some of these things have to happen either before the first boot off the disks for security reasons or afterwards. The concept of sticking everything in a package does place a greater dependency on SA's and developers to create proper IPS packages that can be installed and un-installed properly. Of course some things can be automated easily, while others require custom parameters in the profile to run correctly. I think the learning curve probably needs to be lessened by AI in some way. For example, in many jumpstart frame works, people will pass parameters through the profile that some begin/finish script uses to configure something (think IPMP, MPXIO, link aggregation, svm/zfs/etc on non boot disks, etc.). So this is a big area that many customers have spent time developing frameworks that build things out according to a standard of some kind to make things cookie cutter like and reduce SA intervention at provisioning time. Some of these things might make sense in an IPS pkg and others probably make more sense as post script. Or better yet.. perhaps the extra services/features need some AI integration for the profile, like IPMP, MPXIO, etc. ? That would prevent customers from having to do much other than learn the profile settings to pass on. Otherwise, they'll have to write scripts into an IPS pkg and figure out a way to get the parameters passed on. Probably the biggest issue is that many of the settings customers want configured are in configuration files that must be edited, appended, overwritten, etc. Some jumpstart frameworks, like JET are smart enough to do things like copy the original before making a change or to append things. Of course, most jumpstart environments only handle the original provisioning and that's it. So if you care about how things change over time or who did what, there's no integrated CMDB solution in Solaris to make his easy for managing hundreds or thousands of servers. This is something Sun has left to the likes of Opsware, Bladelogic, Tivoli, puppet, cfengine, etc. I think the challenge with IPS or any package management tool is that you only have a few choices when you want to pkg up a change to a configuration file: 1. Clobber the original 2. Copy the original to *.bak or something, then clobber 3. Append the configuration file (which can lead to things getting clobbered if mulitple pkgs touch it) 4. To uninstall, you either nuke the conf file, leave it as is, or replace it with the original with a script What would probably help administrators out is some way to have a method of flagging configuration files in IPS so that the original is archived and subsuquent changes from additional IPS pkg installs are tracked and archived as well.. perhaps a smart merge of some kind? That way if I make a IPS package that has configuration file changes to lets say sshd_conf and I remove it down the road, the original is restored without any scripting on my part.. it just does the right thing. Or lets say a third IPS package is installed that configures additional settings.. have IPS do an intelligent merge of the orignal, the second, and the third. If I remove the second pkg, only those settings that were merged into the configuration file are reverted back to the original if not already set by the 3rd. And I'm sure many SA's have dealt with Sun pushing out patches that clobber configuration files.. sendmail comes to mind. So this is an area where I think IPS could be extended or a cmdb added to help out. Anyways, just some ideas of things I'm sure other SAs are thinking about when reading up on AI. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- *-*-* Octave J. Orgeron Solaris Virtualization Architect and Consultant Web: http://unixconsole.blogspot.com E-Mail: unixconsole at yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- *-*-* ----- Original Message ---- From: Bart Smaalders <[email protected]> To: Greg Jumper <Greg.Jumper at Sun.COM> Cc: Eric J. Ray <Eric.Ray at Sun.COM>; Casper.Dik at Sun.COM; Jon.Aimone at Sun.COM; desktop-discuss at opensolaris.org; nv-users at Sun.COM; Lubomir Sedlacik <Lubomir.Sedlacik at Sun.COM>; nv_re at Sun.COM Sent: Wednesday, March 25, 2009 7:06:30 PM Subject: Re: [desktop-discuss] Does the AI opensolaris autoinstallation have the post script just like the postscripts in the jumpstart Greg Jumper wrote: > Hi Glenn, > > You write: > > So, what exactly are people not understanding when we (the install team > working on this stuff) say 'provide us with concrete *requirements* of > what you *need* and not what you want'? And saying 'we want jumpstart' > doesn't count. Technology changes and moves on (and hopefully evolves > and gets better). > > To maintain the functionality I have today, I require: > > - The ability to run Solaris commands to restore, create, edit, > rename, and otherwise customize the installed files. > > Probably everything I personally do from a Jumpstart finish script > could be done from a first-boot script (and I already do some things > that way, although not by choice). However, that approach has at > least three drawbacks: > > 1) The system is not available in its final-use configuration until > some indeterminate time after the installation "completes". > (I.e., installation and customization are distinct sequential > processes.) > 2) In general, restarting of multiple services (so the script must > capture the relationships between customized files and services) > or an additional reboot is required. > 3) When the system customizations include hardening, the system is > vulnerable during the first boot until the first-boot script > completes those customizations. > Direct manipulation of the as-laid down image prior to first boot generally presupposes an unsupportable level of knowledge of exactly how each Solaris subsystem configures itself, and the environment in which overall installation occurs. For example: What binaries do you expect to have available on the boot image to manipulate those files? Do you expect the same OS version to be running during installation as is being installed? Same patch level? > Beyond its existence, I know nothing about IPS, so I'm a newbie. > Is the implication that one Jumpstart finish script would have to be > replaced by multiple IPS scripts? For non-package-related > customizations, do I just randomly pick an IPS package to piggyback on? What subsystems are you trying to customize? Please give examples. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ desktop-discuss mailing list desktop-discuss at opensolaris.org _______________________________________________ desktop-discuss mailing list desktop-discuss at opensolaris.org
