Brian Smith wrote: > I have read filesystem(5). It says that /var/svc/manifest is the place for > "SMF service manifests. An approved installation location for bundled, > add-on system software and applications." What is the advantage of storing > the service manifests in /var/svc/manifest? What happens if I don't store a > manifest there? If the user deletes everything in /var/svc/manifest then > will anything bad happen? > > If you put a file into /var/svc/manifest/network/<service>.xml then it won't > be picked up until reboot. That means I need to have a class script that > does "svccfg import -f /var/svc/manifest/network/<service>.xml". If I do > "svccfg import", then do I still need to still store the manifest in > /var/svc/manifest? If so, why?
One reason is to support pkgadd -R -- if you deliver in /var/svc/manifest, your the class i. script doesn't have to do anything in that case. If you use the "manifest" class that's delivered with S10u2 and above, you don't have to import your own CASs. I pretty strongly recommend you use the system's delivered "manifest" class. Next, IPS is implementing its manifest action by just 'svcadm refresh manifest-import' which does require the manifest is delivered in /var/svc/manifest to work. Putting it there will future-proof your package in case you ever want to move to IPS. Another reason is that SMF is capable of re-building the system from "seed" if the repository is corrupted and *all* the backups we take are somehow gone (very unlikely). Some people also restore to the seed repository in order to undo all of their SMF customizations on the entire system, and I use it as a way to test essentially what install does. (Also rare, but happens.) The reason I mention this is that the way SMF restores the system from seed is it grabs the original minimal repository that was delivered with the system, and then searches /var/svc/manifest for manifests to import. If your manifest isn't there, it won't get imported automatically on restore from seed. liane
