Hello Sarah!
> My apologies for the delay in responding. The email thread on this > discussion seems broken and I didn't get your response. My comments > inline... No prob; I can see that you're quite busy anyway. :-) [Sorry for the botched Umlauts in the last mail; emacs VM does that sometimes.] > > > 3rd party products for our enterprise customers are > > key, and unless they > > > follow the rules(which may be the answer) it is > > more than possible a > > > reboot will be required after installation of some > > of these products. > > > > I strongly disagree. One of the big wins of > > designing a local custom > > jumpstart infrastructure is to avoid extra reboots. > > The only reboots > > have encountered that were difficult to avoid were > > due to installation > > of Veritas VM and SDS/SVM (and the latter only > > because of the broken > > design of the profile extension). > > I think we are in agreement actually. I am not advocating making reboots the > norm, simply saying that we don't have control of 3rd party products and as > such reboots due to installation of these needs to be accounted for. OK. So you're just saying that while we don't like reboots we cannot completely avoid them. That's fine. > > > A2) If we enforce the rules that pkg(5) and smf(5) > > are using, perhaps > > > post install scripting isn't necessary. > > > > I really doubt that. You need to have a hook to exec > > arbitrary stuff. > > Whether you call that hook "finish script" or > > "transient SMF service" > > is secondary and only significant for the point in > > time of its invocation > > during the installation sequence. > > I think we are thinking of the same type of post install scripting. What I > mean by that is that we should utilize the existing OpenSolaris mechanisms > if at all possible to allow users to customize their environments. SMF helps > us do that. It also helps us manage dependencies in a more effective way. So > it is essentially a transient SMF service(which we use today by the way in > the Nevada installer) but allows us to hook in to this existing, fairly well > understood and stable environment. It seems you contrast postinstall scripting versus SMF. For me, these are just two of the many possible postinstall scripting implementations (ignoring the many other features of SMF for the moment). I can certainly live with an SMF install service that can do arbitrary things. > > > that Jumpstart has lived so long is that it is > > flexible and allows for > > > customization of environments. Perhaps this > > customization via scripting > > > should be obsoleted, and we should enforce the user > > of smf and pkg. What > > > about with regard to SVR4 packages that we will > > still allow for > > > installing? This seems like it could also introduce > > some complexity for > > > which we do not have control. > > > > A nice understatement. :-) > > It is an understatement. Certainly there is software out there that only > comes in SVR4 format that our enterprise customers will want to install. I > think we have to allow for this. And, we have to find a way to manage this > complexity. I admit that I do not know if IPS provides us any help in this > area, I only know I can install SVR4 packages on my Indiana system with no > issues. This will require more work. That is quite true. Ideally, one should not allow SVR4 packages on Indiana at all, but provide a good pkg format migration toolset instead. > > > 1. Gather data on how our enterprise customers use > > 3rd party software > > > and how often those products result in a required > > reboot. > > > > Interesting... how will you collect this data? > > I can speak with the JET folks as well to get their thoughts on this since > they work with customers specifically in this area. Also, I plan to use > resources within Sun to ask this specific question. Many of our service > engineers have experience with customers with regard to setting up > datacenters, 3rd party software, etc.. If you have any ideas on how to get > this data that would be welcome. I find this a quite daunting task. Taking samples from known customer sites certainly helps, but I don't really how much customer info Sun tracks (besides the proverbial explorer :-). Best regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Sun Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 45 Gesch?ftsf?hrer: Rainer J. H. Brandt und Volker A. Brandt
