> 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?
> 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?
> 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.
> The resulting properties would likely be the same,
> but we would do it by
> adding the appropriate elements to server.xml.
OK; I can certainly make the necessary changes in server.xml and deliver the
modified manifest to you.
> Sure. I'll contact you off-list.
Great! Thanks.
> 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?
> 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...
> > 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?
> 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).
> >From your next message, it looks like this ended up
> working?
I'm still not 100% convinced, because I remember that a few times it didn't
work. Even thogh I made a boo-boo last night and that caused aforementioned
problems, more testing is required.
> SVCCFG_REPOSITORY does the same thing as the
> "repository" command. It
> is private, so you shouldn't use it.
OK. If it's private, then I consider it off-limits, so I'll just forget I saw
it.
This message posted from opensolaris.org
