[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-sysadmin-discuss
Subject:    Re: [sysadmin-discuss] SMF RANT (was Re: That's hard)
From:       David Bustos <David.Bustos () sun ! com>
Date:       2007-09-25 20:54:03
Message-ID: 20070925205403.GC17725 () bargle ! sfbay ! sun ! com
[Download RAW message or body]

Quoth Mike Gerdts on Sun, Sep 23, 2007 at 10:26:23AM -0500:
> On 9/23/07, Octave Orgeron <unixconsole@yahoo.com> wrote:
> > 4. Consistency. My big issue right now is that some things are in the
> > traditional configuration files and other things are in SMF. A good
> > example is that tcp_wrappers is an SMF setting, but TCP_STRONG_ISS is a
> > setting in /etc/default/inetinit. So there are inconsistencies in where
> > things are configured. You also have to consider that configuration
> > files for your server are no longer limited to the /etc directory, now
> > you have to consider you SMF dirs /lib/svc and /var/svc. While it may
> > be ideal to have all of the traditional configuration files in SMF as
> > XML params, it may not be practical from a usability standpoint.
> > Obviously, old rc services should be in SMF. But where do you fit in
> > configuration files like /etc/default/login?

Yeah, this is to be done.  The networking configuration is particularly
not well integrated.  I think we expect projects like NWAM to clean this
up, so you may inquire with them.  By /etc/default/login, I presume you
mean configuration which is (potentially) consumed by multiple services.
I agree that that's a generic problem, and I'm not sure of the solution.
My intuition tells me that we should have a separate namespace for
configuration stashes that don't represent active services.

> I really don't get why SMF service manifests are delivered to var.
> They are configuration files that belong in /etc.  The live
> configuration may not run from those files, but how is that different
> than /etc/mail/aliases vs. the db file that sendmail really uses?

I believe the designer was trying to anticipate deployers who write
manifests for services without the author's knowledge.  In that case the
amount of manifest data can become disconnected from the number of
packages, and /var is allowed to house such a variable amount of data.

That said, /var is problematic in terms of when it is available during
boot, and we would like to start importing manifests earlier, which
requires putting some of them in /etc.  So this will probably happen
eventually.

> > SMF is definitely a powerful tool. And while dependencies and settings
> > for services require some XML skill, in the end the methods for
> > start/stop of services is the same, shell scripts;) So the learning
> > curve is not quite as high as some people may think. The issue here
> > seems to be the need for tools to make the creation of services easier.
> > While it's nice to know XML and understand the syntax for a service, it
> > should be something behind the curtain:)
> 
> Writing (rather, copy then modify) XML is not a problem for me.
> Having to go read the DTD to understand what possible variables there
> is a PITA.

Agreed.  Some have asked for an "SMF bible".

> > 5. Making SMF work as the core method of clustering:) It basically does
> > what most clustering software accomplishes today. Application health
> > checks would be nice. Making it cluster aware and scalable for
> > fail-over, parallel, etc. would be kewl.
> 
> I have previously suggested that there needs to be a cluster.startd or
> similar that can use Solaris cluster agents directly.  Share the code
> base.  If you have dependencies or HA requirements that span machines
> (zones, LDOMs, etc.) bring in the rest of the cluster.  Hmm... now
> that I read on, I see that I mentioned that in this thread.  :)   I
> thought that I heard that there was a way for Solaris Cluster to use
> Veritas Cluster agents as well.  This could be especially nice for
> those that have an existing investment in home-grown VCS agents or
> are just more familiar with VCS (e.g. if they use VCS across many platforms).

People have talked about "distributed SMF", but the devil is in the
details, and we're working on fixing up the existing system first.


David
_______________________________________________
sysadmin-discuss mailing list
sysadmin-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
[prev in list] [next in list] [prev in thread] [next in thread]