Hi Kyle, > Bart Smaalders wrote: > >> Kyle McDonald wrote: >> >> >>> Why would I want to install the micro root onto the target host? >>> >>> Or are you assuming I'll have 'FLAR' type inmages precreated for all >>> my machine types? >>> >> Not for all of them... but certainly there's a significant list of >> packages that are the >> same. >> > As a percentage of the packages in Solaris it's a small list. >
I disagree. I think that the base OpenSolaris image would be similar in most respects. Except for an 'install only' image or some other minimal boot image that could be used for installation or recovery only. Regardless, the user still has the ability to create their own distros or utilize IPS repos to install from. >>> In my case at least I won't. There are too many combinations, and >>> it's too much work to make the same changes to all the images that >>> need them. >>> >> That's fine; you can take an image and add packages, or do it all with >> packages if you insist. The later _will_ take longer. >> >> > I understand that. Do you project it will take longer than it currently > does in JS? That would be unacceptable, but as long as it's no longer > than today (for the same set of pacakges, og course more pkgs takes > longer.) I'm ok with that. > Hard for us to know for sure how long this will take relative to JS today. Keep in mind that an IPS repo is likely remote(from some http server outside the clients network) from the client which will contribute to performance issues. Today with OpenSolaris the packages are served via NFS. Even if the IPS pkg install takes longer the fact that an image install is faster may offset the performance loss. I suppose this might be considered a best practice in terms of AI, that is using an image for installation if at all possible. Again, I am just speculating on performance possibilities. >>> I'm not sure it's all a 'time' issue. >>> >>> I can see some situations where you want to do customizations to a >>> machine before it's 'live'. >>> It maybe that net booting over a management net can install with the >>> public network down, but you want to make sure that all your security >>> hardening is done before you boot up 'live' on the internet. There >>> maybe other ways to work around this. But it seems simplest to be >>> able to do all your work before the first reboot. >>> >> Sure ... as long as that install environment never changes. >> >> > It's never changed in any way that bothered me in JS. I've never relied > on the install env for much more than /bin/sh and pfinstall. I nneded > perl for caspers fastpatch.pl script long before perl was in Solaris. I > just put the perl executable that I compiled into my jumpstart > directory, and it was fine. I imagine I can just keep doing that. > > I know I run some risk here, but I also think that theoretically at > least, the DC will let me make my own install environment if I had to. > Plus what's to say I won't want the changes the new environment brings. > >> So how you handle coreadm, dumpadm and other command-only >> configuration steps? >> >> > I append or replace the config files in finish scripts. It's not pretty. > But it works. The way my master finish script works it's very easy to > handle even complicated changes that may hvve come along, but if I had > to I could script it separately with sed or awk. > > Ideally I'd like to see AI have something like the 'actions' that > packages are going to have, but on a 'per install' case. I envision > keywords for the profile where I'd be able to set SMF properties and > enable/disable services. Just as the supplied actions, and SMF 'merge > services' I've see proposed for pks, eliminate the need for pkg post > install scripts, I imagine that seomthing similiar could reduce (but > probably not eliminate) the need for similiar things in the Finish > script by moving them to the profile. > Utilizing SMF in the same way as pkg makes sense. As I responded, earlier I think that utilizing existing OpenSolaris features is the best way to go for postinstall customization. sarah **** > -Kyle > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss > >
