Hi Gary, [ moving this discussion to smf-discuss, and including more than average quotage for reference ]
PAUL> Is it acceptable to put other non-SMF related commands into this PAUL> script, which need to be run at the next boot? Or should PAUL> expanding the use of this file be avoided all together? JAMES> It would have to be in the ARC contract for your use of this JAMES> interface, but my assumption would be "not a good idea." LIANE> Correct. It is extremely unlikely the SMF team would sign a LIANE> contract for use of /var/svc/profile/upgrade that wasn't LIANE> SMF-specific. I'd like to remove this file entirely, but only LIANE> have plans for how to attack (most of) the SMF-specific parts. LIANE> Making it a catch-all for run-on -boot scripts won't allow us LIANE> to replace it with a more sensible interface. GARY> Hummm, I wonder what Paul's trying to fix that's beyond the GARY> suggested fixes that I gave for GARY> 6384568 SUNWcsr postinstall may be too aggressive with the audit GARY> service in zones GARY> 6381337 bsmconv(1M) may not completely work for an alternate GARY> root The main problem that was observed in bug 6381337 is that the auditd service is not started when an alternative root is used, because the bsmconv script attempts to enable the service on the host that the script is running on, rather than the host that is represented by the mounted filesystem that is being changed. The suggested fix of adding the SMF command to enable this service to the upgrade profile seems like a resonable solution to this problem (assuming we can continue using the interface). However, comments added to the bug by Ric Aleshire and also an inspection of the code that was done by me suggest that there are a number of other things in this script which do not work as expected when an alternate root is used. For example, the existing code uses the upgrade profile to disable the volfs service at boot time, but stores the current state of that service first, so that it can be returned to that state when auditing is disabled. Because the 'svcs -o state' command that is run to store the current state is run on the host on which bsmconv is executing, it will store the state of the service for _that_ host, rather than the one represented by the alternate filesystem. Further examples are the running of '/usr/sbin/devfsadm -e' when TX is installed (as pointed out by Ric) and the use of 'mkdevalloc' and 'mkdevmaps' to initialise device allocation (which, as I understand it, in the current incarnation probes for devices on the host running bsmconv, not the host that will boot from the alternate filesystem, which could be of entirely different hardware), all of which need to be done on the host that will boot from the alternate root, rather than the host running the bsmconv script. Any ideas on the right way to ensure that these commands are run on the correct host are most welcome. My current guess is that perhaps I could modify the startup method for the auditd service so that if a special script exists, that file will get executed and then deleted, meaning that bsmconv can put commands in this file to be run the first time the audit service is activated. However, this issue is further complicated by the fact that the same problem exists with bsmunconv (which as the name suggests attempts to undo many of the things done with bsmconv and also supports alternate roots). For example, this script currently runs 'devfsadm -d' on the host running the script, when it should get run on the target host instead. Many thanks for your help. Kind regards, - Paul
