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! 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
