Hi Ed, Oh, this was the email about HACI stuff that I was looking for.
usr/src/cmd/initpkg/manifest/Makefile Warning: I am not an expert on packaging. So many of my comments will be more about me trying to learn what is going on. This file adds quorumserver_configure.xml to a long list of XML files that, except for quorumserver.xml, are going to be installed on cluster nodes. These two files should only be installed on the quorum server host. I would think that it would be better practice to have these files separated from the files for the cluster nodes. What do you think ? On 04/01/09 11:59, Jonathan Mellors wrote: > Hi Ed, > > Looks good to me and I agree we shouldn't cleanup the smf leftovers. > > Thanks > Jonathan > > 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, Are these updates unnecessary only on OpenSolaris or are these updates unnecessary on Solaris 10 as well ? >> 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." >> This is bad. It appears that if one removes the package, this smf stuff will remain forever. If the IPS team is going to fix this in the near future, it makes sense to wait. If not, then the proposed solution is not adequate. There must be some way for the administrator to completely remove the software. Regards, Ellard >> 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 >> _______________________________________________ >> ha-clusters-discuss mailing list >> ha-clusters-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss > _______________________________________________ > ha-clusters-discuss mailing list > ha-clusters-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss
