I've read through this thread:
http://opensolaris.org/jive/thread.jspa?threadID=47134&tstart=15
and I'm still quite confused about this issue. If there's some
consensus about which direction SMF is going, I'd like to know about
it.
I'm currently working on an Ethernet bridging daemon for Solaris.
It's not part of NWAM, but it looks like the problems I'm facing are
somewhat similar. I'd like to try to make it conform to SMF as much
as possible. This means storing the configuration data in SMF, and
representing the instances using SMF instances.
For symmetry with other networking tools and other administrative
interfaces, I'd like to be able to allow for "temporary" changes --
ones that intentionally do not survive reboot. This means being able
to create bridge instances temporarily, add or remove links
temporarily, and so on. It seems like just good system administration
to be able to address the running configuration or the saved
configuration at will.
This runs me directly into a problem: SMF doesn't allow for the
creation of temporary instances, so addressing only the running
configuration isn't possible. It looks like the acceptable solutions
are:
- "mws mode"
When the user specifies "-t", have the command line tool invoke
the daemon directly rather than creating a new instance and
enabling it (as we would ordinarily do). This causes a host of
design problems:
. The user must have sufficient privilege to actually run the
daemon, where all he needed in the normal case was privilege
enough to create the instance and enable the service. We
lose the benefits of the privilege tie-in for regular SMF
services (svc.started?).
. The code in the utility that handles "-t" will need to be at
least twice as complex. Instead of just knowing how to
manipulate the SMF bits, it'll also need to know how to
launch the daemon and feed it data that the daemon would
ordinarily get directly from libscf on its own.
. The code in the daemon also needs to be more complex and
ad-hoc. Instead of reaching out to get the data from libscf
when needed, it has to "listen" (doors?) for someone else to
supply the data through some other channel or needs to fetch
it from stdin or command line arguments.
I don't think I can solve those problems in any clean way. I
realize that it follows the "ifconfig versus /etc/hostname.*"
model, but it looks like a mess to me.
- "max-workaround mode"
When the user specifies "-t", the command line tool still creates
the SMF instance in the repository (even though the user didn't
want that to be done). It's marked as disabled, so that it won't
come to life on the next reboot. We then do the equivalent of
"svcadm enable -t" on it.
If the user reboots the system, the ghosts of the "-t" instances
will remain in disabled state. They don't really go away, so it's
not a true "temporary" flag, but maybe it's "good enough" and
nobody cares about the warts. Or maybe we have a transient
service that scrubs them away at boot time.
- "temporary mode"
We redesign SMF (or wait for someone else to do so) such that
libscf and svccfg can deal with temporary instances, perhaps based
on layered views of the data.
- "no temporary mode"
Just give up on the idea of symmetry with the rest of system
administration. If people want bridges, they'll have to settle
for non-temporary instances or wait until the underlying subsystem
supports temporary configuration.
I'm leaning towards the second solution (the work-around) or perhaps
the fourth (sorry, no temporaries), but I don't like either of them
much.
Which way is the SMF community going?
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
