Moritz Willers wrote: > On 20 Nov 2007, at 12:46 am, Bart Smaalders wrote: > > >> Moritz Willers wrote: >> >>> Now I know this is unlikely to happen, but I would like to throw >>> this in for consideration on whatever is being worked on: >>> We have written a lot of packages that consist mainly of >>> postinstall scripts, i.e. not delivering any functionality, but >>> merely adding to the configuration of the system. Those packages >>> caused us much grief as we tried to adopt zones, cause us grief >>> during upgrades of our systems (where we tend to replace our in- >>> house developed packages, but need to skip those that do system >>> configuration work), cause us grief as we are looking at other >>> provisioning systems... >>> If here was a sysidcfg API we wouldn't have to do system >>> configuration through postinstall scripts in packages. >>> Whilst I title this and mention a "sysidcfg API", I doubt that will >>> ever come to fruition. It merely is a plea to consider other >>> system configuration, but those provided by the OS install >>> mechanism, and open any future technologies so we as a user can >>> hook into it. >>> - mo (kind of hoping that this mail can be answered with a RTFM >>> link to the Caiman documentation:)) >>> ------------------------------------------------------------------------ >>> _______________________________________________ >>> install-discuss mailing list >>> install-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/install-discuss >>> >> The IPS (Image Packaging System) project is working on a >> generic solution to the "run this at first restart" after >> service startup. This should be a much mor erobust solution >> to your problem, and provides a known context for execution. >> >> - Bart >> >> >> -- >> Bart Smaalders Solaris Kernel Performance >> barts at cyber.eng.sun.com http://blogs.sun.com/barts >> > > I've been following the various blog entries that Stephen posted on > the new packaging world, but have not quite seen how it should solve > the sysidcfg problem. > > For example: we want to set up the ntp.conf at install time. We have > somewhere around 30 locations around the globe with their local ntp > servers (which in turn sync back with the globally distributed GPS/DCF > receivers). We want to be able to define the ntp server on the > install server for every region (in our wrapper around > add_install_client) so the admin doesn't have to think about them when > installing a system, it's the same every time over again but different > from region to region. > > Right now we need to solve this with generating a response file pre > jumpstart and creating a package that creates the ntp.conf in the > postinstall based on the values in the response file and wrapping our > own package install into jumpstart (finish.sh) that allows packages to > be installed with response files. Yuck! > > Why Packages? Why response files?
Why not have the finish script key on domain name, or IP network, do a lookup based on hostname, and then have it create the ntp.conf (or any other config file) on the fly? Does it have to be a package? It sounds like this package would be empty except for a post script? That sounds like a lot of work when the finish script could do it. I have a finish script that looks up an input file for the host to see what to do to the machine, that config file can tell it to copy files, delete them, and run other scripts, and more. The other scripts are generic and install packages, create resolv.conf based on the network or domain, Add Patches, all sorts of things. The idea of putting all these things in postinstall scripts in side packages, and then installing packages never occurred to me. Why was it that you chose that route? -Kyle > Obviously we didn't solve the problem that way, we solved it by > shipping an ntp.conf with the servers defined as ntp1, ntp2, ntp3 & > ntp4 and appropriate CNAME records in DNS. But it is a good example > on how we would love to extend sysidcfg which already has a file > generated pre install to be used during install to automate certain > settings. > > I'm not sure I see how the new packaging alone does answer this > problem. There need to be hooks in the install system as well. > > - mo > > > _______________________________________________ > install-discuss mailing list > install-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/install-discuss >
