Thank you for this explanation as I was (also) under the impression that a manifest file change was a necessary, even desireable, step. Is there, then, a "reconmmended" way to hold my customizations if not to edit the manifest directly? Would I be counting on svccfg/repository snapshots to revert to MY changes if altered?
Craig On Wed, March 15, 2006 6:48 am, lianep at eng.sun.com said: > > (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 > > > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org > Craig Cory Senior Instructor :: ExitCertified 8950 Cal Center Drive Bldg 1, Suite 110 Sacramento, California 95826 [e] craig.cory at exitcertified.com [p] 916.669.3970 [f] 916.669.3977 +---------------------------------------------------------------------+ ExitCertified :: Excellence in IT Certified Education Global provider of authorized technology training for Sun Microsystems, Veritas/Symantec, Oracle, Linux, Project Management, and IBM training USA: 1.800.803.EXIT (3948) | Canada: 1.866.328.EXIT (3948) OTTAWA | MONTREAL | SACRAMENTO | SAN FRANCISCO | QUEBEC CITY CALGARY | VANCOUVER | REGINA | WINNIPEG | LAS VEGAS +---------------------------------------------------------------------+ View additional course offerings and specials @ WWW.EXITCERTIFIED.COM
