Quoth UNIX admin on Thu, Jan 04, 2007 at 03:40:41PM -0800:
> > You can either fail if the versions of Solaris don't
> > match or you can
> > postpone the commands until the root is booted.
>
> What exactly would you designate as a Solaris version mismatch?
> Solaris sparc versus Solaris i86pc?
> SunOS 5.10 versus 5.11, 5.12 or 5.23?
> Both of the above and some more?
>
> Please help me understand so that I might get a perspective. I'd like
> to make sure we're on the same page.
It appears that svc.configd can read opposite-endian databases. We
probably don't guarantee that, though. As for version, checking the
patch level of svc.configd would suffice. I don't know how to do that.
> Are you implying that SMF property groups and properties and/or
> mechanisms/interfaces might insufficiently change so as to be
> incompatible with previous syntax and structure of SMF?
Not at the libscf level (which is what svccfg exposes), but at the
database file level (i.e., what svc.configd consumes), yes.
> > The
> > only public ways to
> > do that is with an SMF service or an rc script.
>
> OKay. init.d scripts are out of the question, even though that is the
> path of the least resistance. I'm either going to be "jiggy" and
> "down" with that there SMF thingy, or I'm going to be limping along in
> "maintenance mode" with rc scripts.
>
> And I don't want to limp. Since I already know how to walk, now I want
> to sprint.
Well we should have better support for delivering new instances in
manifests soon, so I'd use an rc script in the meantime.
> This does bring up an interesting issue though: how would one go about
> delivering an SMF manifest that should only run once, then be removed
> from the system after it ran? What would be the *cleanest* way of
> doing that via SMF itself?
Well if you wanted to remove the manifest and such, you'd have to code
your service to delete its files and the service itself. Otherwise, you
could have your service know when to run and when not to run.
Formal support for one-time services has been talked about, but not
designed.
> > That said, we could make it easier for you to deliver
> > your service as
> > a manifest by moving our network/dns/server's
> > properties into the
> > dns/server:default instance. To that end I have
> > filed
> >
> > 6509773 network/dns/server:default should not
> > deliver any service-level properties
>
> Does that mean I will be able to deliver
> ${PKG_INSTALL_ROOT}/var/svc/manifest/network/dns/server:${STOCK-SYMBOL}.xml
> and won't clash with
> ${PKG_INSTALL_ROOT}/var/svc/manifest/network/dns/server.xml,
> but still have it show up under
> svc:/network/dns/server:${STOCK-SYMBOL}?
Yes. Apparently there isn't consensus on the team that it should be
done, though. The Enhanced SMF Profiles project should obviate the need
for it anyway.
> > Ok. I have filed
> >
> > 6509770 network/dns/server:default should have a
> > a refresh method
>
> Can you use my existing addpg and setprops for that, or will it
> require more work?
The resulting properties would likely be the same, but we would do it by
adding the appropriate elements to server.xml.
> Since I'm working on this right now anyways, if you tell me exactly
> how you want it done and what you want me to do, I'll do the rest of
> the work as well, so that the RFE can be closed?
Sure. I'll contact you off-list.
> > In this case, note that you could add your refresh
> > method to your
> > instance, rather than the service, unless you need
> > the default instance
> > to have the refresh method, too.
>
> Yes; initially, I implemented the refresh method just for my instance,
> but then I realized that /usr/sbin/named could benefit from a refresh
> method as well, so I implemented it at the service rather than the
> instance level. It seemed scalable to me that way.
>
> Although, when I think about it, svc:/network/dns/server:${INSTANCE}
> could have a non-BIND DNS server, which might or might not refresh his
> configuration by receiving a SIGHUP.
>
> Which means both Sun and I should implement refresh methods at
> instance levels, correct? If that's so, it's too bad we have to
> duplicate/double the work.
Right. It depends on whether we want to accommodate non-BIND servers as
network/dns/server. My intuition says "we do", but some on our team
think otherwise. Keep an eye on 6509773, I suppose.
...
> > SMF won't, but just as with any other failure, your
> > start method should
> > echo an explanation, like "configuration file X is
> > missing", before it
> > exits with a nonzero status. The message will end up
> > in the log file
> > and the administrator will be directed to it when he
> > runs svcs -x on
> > your service, which will be in maintenance.
>
> That's all well, but I don't use a start method to fire up `named`.
> Instead, I start, stop and refresh `named` directly via SMF, since SMF
> provides everything that I need:
>
> a) user to run as (method_context)
> b) group to run as (method_context)
> c) stop (:kill)
> d) binary to start (exec)
> e) a way to reread the configuration (refresh)
> f) a way to detect whether the named.conf file is present (dependency)
>
> Even the necessary environment variables that a method might normally
> need can be set. So the way I see it, a separate method is in this
> case redundant. I believe that a method would only be needed when some
> preprocessing must occur before a service instance is started.
Well "method" doesn't necessarily mean "script". If named fails and
prints an intelligent message when it can't find its configuration file,
then that would work fine.
> > By "live" I mean "pkgadd'ed onto the live system".
> > If you use the
> > repository command to modify /etc/svc/repository.db
> > then svccfg will
> > modify the file under the system's svc.configd's feet
> > and problems will
> > ensue. If we taught svccfg where the system
> > repository is, svccfg could
> > avoid this.
>
> By "teaching" you mean modifying the `svccfg` source code and
> hardcoding etc/svc/repository.db in it?
Yes.
> > If you're installing onto a dead root, using the
> > repository command is
> > ok, as long as the versions of Solaris match.
>
> Hmmm... I can check whether PKG_INSTALL_ROOT is either undefined/empty
> or set to "/"; if none of these holds, then I could execute the
> repository command, else I just proceed without the repository
> directive.
Right.
> Now, if I implement all of these, how close would you say that my
> implementation is to being clean and Sun-compliant?
About as close as possible. It would be cleaner to deliver your own
manifest, though, but that's got its own problems that we're working on.
...
> > Those are the symptoms of using svccfg repository or
> > $SVCCFG_REPOSITORY
> > to modify /etc/svc/repository.db under the system's
> > svc.configd's feet.
> > Therefore killing svc.configd would be necessary if
> > you had done one of
> > those things. Except it might result in data loss,
> > so you should avoid
> > doing those things.
>
> To test your theory, I created a special revision of the
...
>From your next message, it looks like this ended up working?
> > This comment in particular was made against the
> > preremove script, where
> > I didn't see SVCCFG_REPOSITORY being set. Without
> > it, svccfg should go
> > through the system's svc.configd, so killing
> > svc.configd should not be
> > necessary.
>
> Whatever the $SVCCFG_REPOSITORY environment variable is supposed to
> do, the (in)correct usage of this variable, or the variable itself for
> that matter, is not documented in either the `svc.configd` or the
> `svccfg` manual pages. In fact, those pages are pretty spartan on
> details.
>
> Please explain how $SVCCFG_REPOSITORY works, and how I should or
> should not be using it.
SVCCFG_REPOSITORY does the same thing as the "repository" command. It
is private, so you shouldn't use it.
David
