Thanks, Thorsten. Thorsten Frueauf wrote: > Hi Ed et al, > > here are my comments: > > * usr/src/cmd/initpkg/svcmethod/svc_quorumserver_configure > > - general question - is this script idempotent? > I guess it comes down to ise i.rbac idempotent?
Yes. > I think it is, in which case I am fine. Otherwise you would need > a mechanism to ensure it is just run xactly once to prevent that > the modified files are getting filled up on mistake. > > - line 69, my usual please to substitute `...` calls with $(...) calls. Jonathan has noted that the magic line is /bin/sh, and that it maps to /sbin/sh which in turn is /usr/bin/i86/ksh93 so I have explicitly changed this script to /bin/ksh & updated the form of that command as you request. I cloned this from some other svc script, so there are probably lots of these legacy scripts invoking ksh93 under guise of /bin/sh. > > * you should also modify usr/src/ipsdefs/SUNWscqs/depend_static and > replace > the line > > depend fmri=SUNWcs type=require > > with > > depend fmri=SUNWcs at 0.5.11-%SOLBRANCHVER% type=require Done. > > Since the svc_quorumserver_configure script depends on SUNWcs for sure. > The entry without version string indicates it was carried over by the > SVR4->IPS conversion but was not verified if it is really true. > Since basename and i.rbac belong to SUNWcs, it is now verified. > > Otherwise I am fine with the webrev and your proposal. Thanks, --emk > > Greets > Thorsten > > Ed McKnight wrote: >> http://cr.opensolaris.org/~emk/CO-IPS-11/ >> >> The issue: postinstall and preremove do not exist under IPS. Quorum >> server uses both under SVR4. The prescribed solution is to migrate >> these tasks to an installer/configurator/smf service, all (well, >> most) of which (are supposed to) require a user gesture (reboot >> qualifies.) >> >> Under SVR4 the quorumserver packages make updates to /etc/services >> and rbac. It turns out that the /etc/services updates are >> unnecessary, and that rbac remove is a no-op, therefore the only >> install-related configuration need is to register rbac profiles at >> install time. >> >> I'm accomplishing this by introducing a new smf service, >> quorumserver_configure, with its method implementation, >> svc_quorumserver_configure which clones the rbac method from >> scinstall's ips install support. This new service is delivered >> enabled so it runs 'immediately' at package install time. It is >> disabled at package remove time. >> >> With the limited amount of hooks available (since it would be an EOU >> regression to introduce a configuration tool that the user must run, >> or require a reboot) the new service stays online until package >> removal when it becomes disabled. Thereafter the service remains >> (disabled) in the smf state tables, and even survives reboots. The >> cleanup work performed under SVR4's r.manifest cannot be invoked by a >> service on itself. There is a vague plan in IPS to fix this lack of >> proper cleanup on smf manifest removal "sometime in the future." >> >> For now I'm most inclined to just let it sit; if there is significant >> pushback I have a workaround in mind, but I'm not sure the benefit >> justifies the complexity and work. >> >> Comments? thx, --emk >
