Date: Wed, 28 Oct 1998 17:17:12 -0800 (PST) From: Bryan Mann <bmann@whistle.com> To: Andrzej Bialecki <abial@nask.pl> Cc: Terry Lambert <terry@whistle.com>, small@FreeBSD.ORG Subject: Re: Unified Configuration Interface Message-ID: <Pine.BSI.3.95.981028160517.12500B-100000@chaco.whistle.com> In-Reply-To: <Pine.BSF.4.02A.9810282228390.10826-100000@korin.warman.org.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 Oct 1998, Andrzej Bialecki wrote:
> > Bryan Mann previiously wrote:
> > To pile on ... I agree that there should be a transactional model
> > and stress that there are as yet uninvented protocols that might be
> > light weight enough. The important piece of each of the
> > mentioned protocols that is missing from a management point of
> > view is "realtime" monitoring. Something we've been faced with
> > as time goes by here at Whistle is the need to have UI be capable
> > of monitoring processes in a 'light weight' way. We don't currently
> > have this solved and I consider it an area of research. I'd
> > offer that whatever management implementation freebsd-small use
> > should support this 'monitoring' capability.
>
> That's an interesting issue. The key thing here is the protocol, because
> we can already obtain this info without placing almost any load on the
> system - the problem is how to notify whoever is listening about the
> status changes. If I understand you correctly, you mean something similar
> to the part of "convenience MIB" of UCD-SNMP which allows to send traps
> when given set of processes behaves such and such, right?
>
I will look at UCD-SNMP. We've been experimenting with snmpd from
SNMP Research. So in answer ... possibly.
[deleted]
> >
> > Example:
> >
> > If your web-server daemon needs to know about hostname
> > changes it should register itself as wanting to receive
> > "Hostname changed" events. Rather than the other way
> > around, which is: if I'm managing the hostname let me
> > kill and restart any daemon that might need to make
> > configuration changes based on the new hostname.
>
> No, this is directly related - I wrote about it in the UCI document, in
> section on implementation of configuration agent.
Ok I missed it. Sorry.
>
> But there's one thing here which is still unclear: objects can have
> multiple dependencies, and in reality it matters which one of them is
> followed first.. We need some ordering mechanism here as well.
>
So perhaps this is faulty logic on my part but here goes...
Suppose that you don't order anything per se but rather define that
each sub-system is in some state similar to processes in the kernel.
Example states:
INIT - perform initialization tasks
START - to perform start-up tasks
STOP - perform stop related tasks
RUN - the primary work phase
IDLE - for objects that are waiting on some external event
CHECK - performs self consistency check
useful to test config changes prior to commit.
READY - ready to start but not yet started.
UPGRADE - perform upgrade tasks
DOWNGRADE- run downgrade tasks
MONITOR - to connect for monitoring
NOTIFY - out-of-band notification of state change
[out-of-band notification means that the client
opens a rendezvous point for the server to connect
to upon completion of the STATE/object in question]
ERROR - actions performed in error state, note that errors are
propagated up the object hierarchy until an error action
can be invoked on the object in question.
[includes success/fail messages to be emitted on
the success/fail of a particular state. Note that
for localized messages the response is simply an UUOID
for a message in a locale specific catalog]
SHARE - actions to be performed when replicating this entry.
EXT_{UserDefined}
- user defined extensions but how do you specify
where they go in the state machine ?
For this discussion then a sub-system is like
basic networking, routing etc. Then have a single proccess that
manages the bootstrap by going through the "services" sub-tree
and executes each subsystem's INIT method. Could be a script
or command line parameter to the daemon or whatever.
Then each daemon's INIT code registers the events that it wants
to monitor like "Notify me of 'routed started'" or whatever.
This means that the daemon must wait IDLE on it's dependencies
to be in place before it can complete it's INIT state and
move onto RUN.
And to some degree means that the system's startup is dependent
on what is installed or 'active'. Additionally, each daemon
would be capable of reporting it's state to the bootstrapper
so that it could be interegated or debugged in the case of
deadlock etc.
> > > Ugh.. Yeah.... This is pretty extensive list. But you make a good point...
> > >
> > > What worries me, though, is that the only one (free) implementation of
> > > snmp agent that I'm aware of is, well, more than bulky...
> > >
> >
> > Tracking MIBs raises issues of access control lists, security etc.
> > So far LDAP and SNMP v2, v3 seem to be lacking in these areas.
>
> AFAIK, SNMPv2 addresses this issue quite acceptably.
>
Ok, but there may be some reason to auth to a particular node
in the tree can SNMPv2 do this?
>
> Andrzej Bialecki
>
> -------------------- ++-------++ -------------------------------------
> <abial@nask.pl> ||PicoBSD|| FreeBSD in your pocket? Go and see:
> Research & Academic |+-------+| "Small & Embedded FreeBSD"
> Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/
> -------------------- ~-+==---+-+ -------------------------------------
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-small" in the body of the message
>
----------------------------------------------------------------------
"A University without students is like an ointment without a fly."
-- Ed Nather, professor of astronomy at UT Austin
(This signature brought to you courtesy of fortune(6) and cron(8).)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.981028160517.12500B-100000>