(I'm bcc'ing an internal alias, again after mistyping smf-discuss, where this question has been asked multiple times recently: it's a relatively common question and the answer deserved to be on a public alias.)
An internal person writes: > What would be the best way to change a system-provided manifest ? > Background: If one want to change the behavor of a system service. This servi > ce is started from a start method, which is used from a sun-deliverred manife > st. First, file a bug against the service where you're looking to change the manifest. If you or a customer of yours is finding a need to change a system-provided manifest, that means there's a change in behaviour that isn't supported by the manifest. It shouldn't be necessary to change system manifests, all behaviour changes *should* be customizable with supported configuration variables/properties -- but there are some lingering bugs/rfes in a few services. It should be a high priority to get these filed and fixed, which we can't do without data about what changes people are making! Once you've done that, here's the procedure: - File a bug documenting the lack of supported way to change the config you want to change. (Hey, can I stress this enough? :) ) - Copy the existing method to a new location. If you want to make the customization in a single local zone rather than in the global zone and all local zones, you'll need to put the new method into a zone-modifyable location. (e.g. somewhere in /opt) - Modify the method with your changes. - Configure the REPOSITORY to point at your new method: # svccfg -s <fmri> setprop start/exec = "<method invocation>" - When you're ready to commit the changes you made and start the service with the new method: # svcadm refresh <fmri> (commit the changes) # svcadm restart <fmri> (restart the service) What's absolutely critical here is that you customize the service using the repository directly, not by changing manifests and re-uploading them. SMF tries very very hard to preserve administrator customizations. The way it knows what's an adminstrator customization is that it can tell the difference between config imported from a manifest and config made using svccfg (or libscf calls). We ship manifests as uneditable (packaging type f), so it isn't supported to change them. There's even a comment in all our manifests which say this! So, what's the benefit of SMF knowing that this was an explicit administrator customization? When the system is upgraded, the customization will be preserved. If you stick the customization in the manifest, it won't be, as we believe that the manifest is the only one that ever delivered that change and it should be updated by the patch. After a patch which changes the method, you'll need to re-apply your changes to the method, of course, as your method might have diverged from changes that we delivered in the patch/upgrade. That's why filing a bug is really important -- properties which influence behaviour rather than setting the method directly will not need to be modified across a patch/upgrade. (It's clearly a bit early for me to be trying to explain the subtleties of this, so feel free to nudge about clarifications of particularly opaque sentences.) liane -- Liane Praza, Solaris Kernel Development liane.praza at sun.com - http://blogs.sun.com/lianep
