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? > 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.
The script uses /bin/sh, so that suggestion would be OK for opensolaris since /bin/sh is a symlink to ksh93, but $(...) is not valid for the Bourne shell. Jonathan > > * 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 > > 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. > > 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 >
