Quoth UNIX admin on Fri, Jan 05, 2007 at 02:15:56AM -0800:
> > It appears that svc.configd can read opposite-endian
> > databases. We
> > probably don't guarantee that, though.
>
> Ahhh, so it could be a sparc versus i86pc issue?
No, it's an issue of us deciding that we would like a better
implementation, and changing it. See Jim Carlson's mail.
> > As for
> > version, checking the
> > patch level of svc.configd would suffice. I don't
> > know how to do that.
>
> `showrev -p` as a sanity check right before stuffing pgs and props is
> to commence?
> I can easily implement that as well as an additional sanity check.
>
> Should I post the revised version here once I'm done?
Sure, if you'd like.
> > Not at the libscf level (which is what svccfg
> > exposes), but at the
> > database file level (i.e., what svc.configd
> > consumes), yes.
>
> But the back end is a RDBMS, and right now it's SQL lite. Don't you
> guys actually issue SQL commands behind the scenes to the back end? If
> you don't, then I can very well see where the problems would arise.
>
> However if you do, then the endianess and even the DB structure would
> be abstracted from svc.configd and SMF in general. And carefully
> written/issued SQL statements should be DB independent.
We do use SQL, but by not publishing it as an interface we reserve the
right to use something else in the future. That's the problem.
...
> > 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.
>
> Well, isn't that exactly how SMF services and instances are supposed
> to work?
> By definition, a certain instance might be implemented by means of
> a different piece of software;
>
> for example, the Sendmail versus Postfix or Oracle versus PostgreSQL
> or even IPFilter versus CheckPoint come to mind.
>
> Although I wouldn't do it, technically speaking, someone else might
> have an idea to implement TinyDNS as the DNS server; and by the
> concept of SMF, they're *supposed to* implement that as an instance of
> svc:/network/dns/server.
>
> If it is known that svc:/network/smtp can't be exclusively "owned" by
> just Sendmail, then svc:/network/dns/server shouldn't diverge from
> that concept. We want to be consistent, right?
The service/instance split is for configuration sharing, but we haven't
established definite guidelines for what should be shared when. I agree
with you: since DNS is an open protocol, instances of
"network/dns/server" should available to any implementation. But some
members of our team feel that since we have already engineered
dns/server to accommodate multiple instances of named, other
implementations of DNS should use another service name, I guess. It's
wouldn't be so bad since DNS is a primarily network-facing service, but
for internally-used services, like syslog, there is also a dependency
argument to be made.
> > 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.
>
> Well it does, but in the syslogd logging facility.
> For example, in my postinstall phase, I parse syslog.conf to determine
> whether "local0.info" is already defined; if it is not, I add that to
> syslogd and SIGHUP syslogd. Before I even do that, I deliver a type
> "v" /var/log/local0.log as an empty file, so that all my bases are
> covered.
> But how to intelligently pick up an error message during named startup
> without a method script? Now I have to make a choice: either I keep it
> simple and keep everything inside SMF, or a write a method just for
> that one check, to see if named.conf is present...
I don't think it's that much more complicated. But you do understand
the situation.
> > > By "teaching" you mean modifying the `svccfg`
> > source code and
> > > hardcoding etc/svc/repository.db in it?
> >
> > Yes.
>
> How does svccfg know that it should read /etc/svc/repository.db now?
If you don't specify an alternative repository, it uses libscf
unmodified, which contacts the system svc.configd. If you specify an
alternative repository, svccfg starts its own svc.configd on that file
and uses private mechanisms to instruct libscf to communicate with it.
So if you use "repository /etc/svc/repository.db", you get your own
svc.configd modify repository.db, and the system svc.configd (which
svc.startd is listening to) doesn't see the changes. (I suppose it
could, but it assumes it's the only modifier, so it doesn't check for
external changes.)
> > 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.
>
> Yes, it would. I would certainly be a very elegant way to solve the
> `pkgadd -R /export/client1` problem.
>
> But when I experimented with a .xml file, I quickly determined that it
> overwrote Sun's dns/server.xml file in the DB itself.
>
> Is there a way for me to deliver a completely separate manifest which
> won't overwrite Sun's own, yet have it show up under
> svc:/network/dns/server:${STOCK-SYMBOL}? I really want that; as close
> to Sun as possible; no expense and no effort spared.
>
> That would be the ideal solution as far as I'm concerned (which kind
> of comes back to what Rich suggested at the very beginning, but not
> quite).
Unfortunately not. That's one of the things we want to address with the
Enhanced SMF Profiles project in the long term and 6509773 in the short
term.
David
