On Wed, Jun 10, 2009 at 12:00:35AM -0700, UNIX admin wrote: > To the best of my knowledge and belief, as of right now, SMF provides > no capability for a one time run, so getting post-installation code to > run via SMF is tricky, with one svcadm refresh, and one svccfg delete.
This thread's been beat to death, but what the heck :) It is definitely possible to build one-shot SMF services, as well as transient services that do nothing when there's nothing for them to do. I've done it as a proof of concept. A service can disable itself. And a service can even remove itself. Because SMF out of the box doesn't provide a way to do the latter it took some cleverness, namely: use ctrun(1) with an argument command that is, effectively, a shell script that waits for the service's state to change to offline then removes the service, all the while the parent disables the service. > Is it really practical to take the "no scripting zone" design so far > as to force people to resort to "backdoors" and hacks via SMF, which > SMF doesn't even rightly support yet? I mean, if I have to use SMF to > do postinstall, I clearly have the need to execute code upon software > installation and removal. Why refuse to give me capability to do that > in the packaging system? The IPS team's arguments for no pkg install/remove time scripting are, IMO, rock-solid. I would prefer that there were more examples and better conventions and tools around self-assembly, but that's nothing compared to what IPS solves just by not allowing install-time scripting. Any engineer who's had to fix SVR4 package class action scripts knows this deep down. Nico -- _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
