On Fri, Jun 12, 2009 at 12:43 PM, Nicolas Williams<[email protected]> wrote: > 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. >
No-scripting is one IPS design choice that I fully agree with although I was a little skeptical long back. In fact many enterprises which do significant in-house software development enforce script-less packages whether on Linux or Solaris. A single script bug in a single package can bring a production server to it's knees. While this is good, thinking through the impact it will have on application and layered software packages and providing adequate hooks to take care of configuration issues should have been much higher priority in the IPS development action-items. For eg. there is currently no way to package the following HP driver with IPS and have it working properly: http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=us&prodTypeId=15351&prodSeriesId=3186080&prodNameId=3288103&swEnvOID=2023&swLang=8&mode=2&taskId=135&swItem=MTX-30012bd09e11426b9b289142e4 It modifies a bunch of configuration files. Regards, Moinak. -- ================================ http://www.belenix.org/ http://moinakg.wordpress.com/ _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
