* Tom Whitten <thomas.whitten at SUN.COM> [2009-12-02 21:11]: > Tom Whitten writes: > > We've heard your input, and the new manifest location will be > > /lib/svc/manifest. The new ARC case document will be sent out shortly. > > I've attached the new document. > > tom
Comments, suggested corrections, and questions inline. > <case number> > Sean Wilcox > 11/17/2009 > > 1. Summary > smf(5)/Greenline (PSARC 2002/547) provides the manifest-import > process, that imports manifest files from supported directories > under /var/svc/manifest and /var/svc/manifest/site. The > manifest-import process runs late in the boot process due to > a dependency on the system/filesystem/minimal service. It is > desirable to have this process run much earlier in the boot process, > specifically before any services are started. Let's not call it Greenline anymore, at least in ARC documentation. And probably better to call manifest-import a service. Finally, the last sentence should give background on the desirability. How about "As some services need their updated configuration prior to this stage of startup, it is ...". > 2. Details > > In the current environment, there is a problem when the manifest for an > existing service is upgraded. Since the manifest-import service runs relatively > late in the boot process, it is possible that the service with the > upgraded manifest can start before the manifest-import service runs. If > this happens, the SMF repository will contain old information -- not the > configuration from the upgraded manifest. > > The Early Manifest Import project solves this problem by importing > manifests before any services are started. This ensures that the > repository will contain information from the latest manifests when the > services are started. Thus, the services will not read stale > configuration information from the repository. > > Early Manifest Import will be a pseudo service. Meaning that while it > has the appearance of a service, by having a repository entry that > describes it and gives state, the service will be solely executed by the > svc.startd process. The Early Manifest Import service will be executed > by svc.startd before any other services are initiated. I'm a bit confused by the term, "pseudo-service", and discourage its introduction without more explanation. All services delegated to svc.startd(1M) are "solely executed" by that process. If I changed the start method of this service instance, would that method be run? What properties are in play? Which are ignored? > Manifest files will be imported from a new location that is available > at the time Early Manifest Import is executed. Root (/) will be > available, and as part of that /lib will be available. Therefore > manifest files located under /lib/svc/manifest and /lib/svc/manifest/site > will be imported during the execution of Early Manifest Import. > As part of this project, the ON manifest files that are currently > delivered under /var/svc/manifest will be moved to /lib/svc/manifest. After this change, the > recommended best practice that manifest files > be delivered under /lib/svc/manifest subtrees to take advantage of > Early Manifest Import. > Services delivered under the /var/svc/manifest > directory tree will still be supported. Although, they will be > imported during Late Manifest Import, specifically by the current > manifest-import service. > > /lib/svc/method/manifest-import will take a new option, -e, that > will indicate that manifest-import run under the concept of Early > Manifest Import. Why an option letter? The method knows from SMF_FMRI which service it is; moreover, I would expect it to be driven by properties in the service instance. Do the directories not move out of the script at this point? > Manifest files under the /lib/svc/manifest subtree > will be imported during this phase. Those under the /var/svc/manifest > will be imported during the Late Manifest Import which will > run as the current manifest-import today with the dependency > on filesystem/minimal ensuring that /var/svc/manifest subtree > is available. > > The Late Manifest Import service will import manifests from > /lib/svc as well. This allows administrators and IPS to invoke > "svcadm restart manifest-import" to install new/upgraded > manifest files. > > /lib/svc/method/manifest-import will use a new feature of the svccfg > import sub-command option to import all the manifests in a set of > directories. Each manifest file in the directory subtree will be found > and imported. The code will preserve the use of the Project Private > SVCCFG_CHECKHASH > environment variable as it is used in today's code during manifest > import. If the SVCCFG_CHECKHASH environment variable is set, then > manifest files will be imported only if there are changes present that > cause the hash values in the smf/manifest table to be different. > > Since profiles are considered to be machine specific configuration and > since they are designed to be modified by the system administrator, the > location for profiles will be /etc/svc/profile and /var/svc/profile. > Much like manifest import, only the profiles in /etc/svc/profile will be > applied during early manifest import. The profiles in both directories > will be applied during late manifest import. Neither Early Manifest > Import nor Late Manifest Import will look for profiles under /lib/svc. > > 3. Interface Table > svccfg import <directory or file> Committed > /lib/svc/manifest Committed > /etc/svc/profile Committed > manifest-import -e Project Private Need your service/service instance FMRIs here. > This case requests patch binding. > > 4. Additional Materials > smf_bootstrap > svccfg > > man page updates > > > --- smf_bootstrap(5) > > --- smf_bootstrap.orig Wed Nov 18 15:53:53 2009 > +++ smf_bootstrap.emi Tue Dec 1 15:17:18 2009 > @@ -14,19 +14,52 @@ > files. > > Manifest Loading at Boot > - The svc:/system/manifest-import:default service uses > - svccfg(1M) to import certain manifest files from the > - /var/svc/manifest directory tree into the service configura- > - tion repository. The service imports files that it has not > - imported previously and those files which have changed since > - the last time they were imported by the service. When a man- > - ifest is imported by the service, a hash of the file that > - includes its contents is recorded in a property group of the > - svc:/smf/manifest service. The manifest-import service uses > - the hash to determine whether the file has changed. See > - svccfg(1M) for information on the svccfg import behavior for > - services that already exist in the repository. > + Manifests are processed in two different phases during boot. > + In each phase, manifests are processed using svccfg(1M) to > + import manifest files from well-known locations into the > + service configuration repository. Imported manifest files are > + those that have not been imported previously or have changed > + since the last time they were imported. When a manifest is > + imported, a hash of the file that includes its contents is > + recorded in a property group of the svc:/smf/manifest service. > + The hash is used to determine whether the file has changed. > + See svccfg(1M) for information on the svccfg import behavior > + for services that already exist in the repository. For manifests > + installed under supported directory trees, /lib/svc/manifest and > + /var/svc/manifest, the manifest-import process will remove > + services and instances from the repository if manifest(s) > + delivering those services were deleted form the system. > + Instances will be removed from the repository if support for > + those instances are removed from the supporting manifest files. > > + The svc:/system/early-manifest-import:default, a pseudo > + service is responsible for the first manifest processing. Drop "pseudo". Why isn't this an instance of manifest-import, like svc:/system/manifest-import:early or svc:/system/manifest-import:initial? > + This service processes only manifests from the /lib/svc/manifest > + directory tree before svc.startd(1M) initializes any services > + thus enabling services delivered in /lib/svc/manifest to > + always start with their most updated definition. Since this > + is a pseudo service, svcadm(1M) commands are ignored though > + svcs(1) can be used to observe status and get log file > + information. Why is this special aspect necessary? Isn't the real special attribute the fact that this service instance is executed prior to any other instance? It should be possible to disable this instance, with known impact. > + The svc:/system/manifest-import:default service handles the > + second manifest processing and imports manifest files from > + both /lib/svc/manifest and /var/svc/manifest directory trees, > + in that respective order. > + Move the following to the NOTES section of the page, deleting the first sentence. > + NOTE: Support for /var/svc/manifest is compatibility support > + for manifests delivered in that directory tree prior to the > + introduction of system/early-manifest-import:default. > + Services delivered in /var/svc/manifest may run into upgrade > + related issues where a service may be started with old > + repository configuration since its updated manifest is not > + yet imported. Similarly, a newly added service may not be > + available or a deleted service is still started during boot > + because its manifest file has not been processed. Developers > + are strongly encouraged to move manifest to /lib/svc/manifest > + to avoid these issues. > + > + > Manifest Handling During Packaging Operations > Service manifests within packages should be identified with > the class manifest. Class action scripts that install and > @@ -108,21 +141,23 @@ > across any release boundary. > > Profile Application > - The first time the existence of each of the three service > - profiles listed below is detected, svc.startd(1M) automati- > - cally applies the profile. > + The first time the existence of each of the service > + profiles listed below is detected, the profile is automati- > + cally applied. > > - /var/svc/profile/generic.xml > - /var/svc/profile/platform.xml > + /etc/svc/profile/generic.xml > + /etc/svc/profile/platform.xml > + /etc/svc/profile/site.xml > /var/svc/profile/site.xml > > + The svc:/system/early-manifest-import:default service applies > + the system profiles in /etc/svc/profile while the > + svc:/system/manifest-import:default service handles the > + site.xml profile in /var/svc/profile. (Implementation.) How do the Xincluded profiles get handled? Isn't there cross-consolidation coordination required here? (Or, couldn't you just have generic and platform profiles in both locations?) > - The svc:/smf/manifest service is used in a similar fashion. > > > - > - > SunOS 5.11 Last change: 25 Sep 2008 2 > > > @@ -134,11 +169,12 @@ > > > > - Additional service profiles that characterize the activation > - of various groups of service instances might be present in > - /var/svc/profile. None of the /var/svc/profile profiles are > - automatically applied to the repository. A profile can be > - manually applied or re-applied using svccfg(1M). > + Additional service profiles that characterize various groups > + of service instances might be present in /etc/svc/profile > + and /var/svc/profile. None of the additional profiles in the > + mentioned directories are automatically applied to the > + repository. A profile can be manually applied or re-applied > + using svccfg(1M). > > SEE ALSO > pkgadd(1M), pkgrm(1M), svcadm(1M), svccfg(1M), > > > --- svccfg(1M) > > --- svccfg.orig Wed Nov 18 15:53:53 2009 > +++ svccfg.emi Wed Nov 18 15:53:53 2009 > @@ -235,8 +235,13 @@ > fails. > > > - import [-V] file > + import [-V] [file | directory] > > + If a directory is supplied, for each manifest file found > + in the directory tree, the service manifest file is imported > + as stated below. Only files with a .xml extension are > + considered for import when a directory is searched. > + > If file is a service manifest, then the services and > instances it specifies are imported into the repository. > According to the file, dependencies may be created in Everything else seems sensible to me. This will be nice. Thanks Stephen -- sch at sun.com http://blogs.sun.com/sch/
