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.
* 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
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
