Hello all,
let me first say that I have just uploaded six
packages for Webconf in the cvs-path
/cvsroot/leaf/devel/meand/webconf/alpha/
These implement a separation of informational
content from configuration duties, for 'basic'
as well as 'expert', each with its own help text.
An 'apkg-listing' is provided as general info.
A validation change for fully qualified host names,
as needed by OpenBSD clients, is also included.
Feel free to comment on the optics, in order that
I may judge whether to commit these alterations
for the present beta cycle.
Now for the main matter. I have indulged in a
short conversation with Erich Titl on the notion
of 'running service' and its recognition as such.
This is a vital point indeed. As I see the situation
there are four kinds of services on a Bering-box:
1) Single daemon services tied in a unique manner
to a single daemon process. A typical example
is 'openntpd'.
2) 'Boot script services' that possess a fully fledged
init-script, offering at least stop/start/restart
as distinct and meaningful commands, but services
stillnot tied to a single running process. The typical
example is "shorewall".
3) Then there are the compound services and the crippled
services. The lrcfg item "System" is clearly compound,
and "keyboard" is definitely crippled.
4) Finally, there is "Networking" in lrcfg-speak. Here the
diversity of network constellations poses a major obstacle.
I would like to cite two sentences of Erich Titl in order
to stress the difficulty of pinpointing a "live network":
E. Titl: "I also pointed out the meaninglessness of [a] network
being up or down, what exactly does it mean?"
E. Titl: "I further believe, as long as the web interface can be
accessed, networking is _not_ down."
Until two days ago, Bering considered the network to be "up"
only if
$ /sbin/ip li sh dev eth0 | grep UP
would succeed. I have now changed it to determine whether the
adapter carying a default route is marked "UP". This is still
a bad compromise, since the internal web interface is not taken
into account, but ought to capture at least wireless connections.
I feel the developers now ought to join in discussing these matters,
in particular the issue on "networking". Although Erich Titl is
aiming further than I am on the abilities of a Web GUI, a project
goal of producing a competetive/amicable product from LEAF-Bering
does need clear specifications of notions such as "up", "down"
for sevices, possibly also a precise plugin interface description
This latter part, in order that the users may incorporate all
functionality for configuring and maintaining any service in a Web GUI.
Just consider the diverse functionality that already is present on
a Bering iso-image today, or think of any useful privately developed
subsystem that must have seen daylight.
I am only slowly beginning to see what unexpectedly large undertaking
this Webconf subsystem really will be, before it can function smoothly.
But then again, I am mainly a command line administrator!
So, please join into the discussion, but delete the above text in
your replies, or better still, start a completely new sub-thread.
Best regards for now
Mats Erik Andersson
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
