"Peter Tribble" writes: > On 9/12/07, Liane Praza <lianep at eng.sun.com> wrote: > > Michel writes: > > > Hello, > > > > > > Is there a way to configure a service to start on the next system reboot > with > > > out having to execute "svcadm enable" nor putting a file in /var/svc/mani > fest > > > . > > > > We have an RFE open for a simpler way to do this, but for now you > > can use the workaround documented there: > > I was just about to ask about a very similar problem (functionally > the same, I guess, but a slightly different use case). > > What I need is the ability to install a service so that it starts out > permanently enabled but currently disabled. Without doing > an enable followed by a disable -t. > > The way this works is as follows: I install software, import the > services, and configure authorizations so that developers and > operators can temporarily disable/enable and restart the service. > However, at the start the services cannot be enabled - I don't > have the config files for apache or whatever, so if I try to enable > them they go straight into maintenance.What I want to avoid > is the loop where they have to come back to me to permanently > enable the service the first time - it would be easier if it was > initially in the temporarily disabled state so they could just > re-enable it when they're ready.
Interesting! I hadn't yet considered these use cases with respect to delegated administration. Certainly you could define the service as disabled in the manifest and use the procedure in 6198442, to permanently enable, but leave the service not running for now. I've been wondering if "unconfigured" is a useful tag to have on a service. That is, a way for a software developer/packager to say that a service isn't useful until some administrative action has been taken. Then the framework could make decisions like not to run the software even if it is enabled. Or, it could just use the information as an explanation for the maintenance state. I'm not sure it solves that many problems, though. A service author would still have to define it, and they can already use the configuration error code so that svcs -x diagnoses maintenance correctly. It isn't clear to me the operational model is any better than the one where you either explicitly disable the service, or leave it enabled and just know that some operational period of time the maintenance state (due to a configuration error) is expected. Thus: would a single command to explicitly leave the service in a temporarily disabled/permanently enabled mode solve your operational request, or is there more you think needs to be explored? liane
