There is a lot here; let me begin. Comments inline. If I choose not to comment, that means I have nothing to add, not that I missed it.
Thanks for a response that was both quick and to the point. I'm running out of things to say too, at least until I think a good bit more about the UI part (my main interest in this melange of related topics). So only a few minor responses this time around.
1) Unconfigured interfaces tend not to route packets to the proper destination (or accept them actually, even if you can figure out their address). A distinct problem for http-based configuration interfaces.
Yes. But http-based configuration of home routers (think Linksys or Netgear) is naturally done on the internel interface, which can easily have workable values as the default settings (the best the external interface can do, I suppose, is default to DHCP). I'm pretty sure the current Bering variants assume eth1 is internal, has address 192.168.1.254, and is on 192.168.1.0/24.
2) There are several different types of interface configuration that potentially result in dynamic assignment of parameters such as ip address, mask and dns resolvers.
DHCP of course is this way. PPPoE and dialup PPP set address stuff but not, as I recall, DNS. But that's quibbling. You are right, of course. I chose the example of setting up a static address in order to focus on UI complexity, not backend complexity ... static addresses involve the most explicit input from the user.
Functionally, LEAF will not be able to bootstrap ethernet interfaces via anything other than a console-based interface until we are off floppy, which is not a goal of this project, from what I have seen.
This is not quite true. Bering's kernel, like many small kernels, has limited NIC support built in. Right now I forget what NICs are supported out of the box, but tulip is a likely example. A LEAF system with 2 supported NICs could easily be brought up to the point where a Web-based interface was available on the LAN side, if the configuration chose sensible defaults. I believe the current defaults fit the need; if not, they would be easy to tweak, using the Linksys setup style as a mental model.
Until we can throw a bunch of modules on the boot media and detect hardware, this is simply not a possibility. Not a limitation (or a responsibility) of the configuration database or any of the infrastructure components.
Theoretically, a pre-configuration utility (as simple as a Makefile or as complex as a Java program) making use of the cdb structure will have a much easier time of building a bootstrapped floppy image for a newbie than without it (modules included!)
Years ago, back in LRP days, there was a Web-based configuration system that would construct a modules.lrp file for you. It handled other things, like the various ip_masq_* modules, but its main purpose was to simplify NIC support. It failed for no fundamental reason, just the site's developer losing interest and nobody else picking it up when LRP changed kernels.
It would be nice to think again about a configuration system that would build a floppy image that had a base kernel, suitable modules, an etc.lrp package with the right /etc/modules file, and the mix of packages suitable to a specific system ... maybe even including choices of firewall packages. But I Think that is not our immediate concern for using cdb.
This entire passage depends on the interface and how it is laid out.
Interface switching can easily be implemented as a "wizard" which allows you to select the interface on the first page, then configure the interface on subsequent pages, thus avoiding the hassle of re-reading data while accepting user input, then trying to figure out what to do.
I have no particular objection to separating these two steps, but I have e general objection to fragmenting the UI in ways that do not seem natural to our target users. Which way this specific idea falls I don't really know. But I do know that the interaction with the user has to be the predominent consideration in all UI work, including how the configuration is compartmentalized.\
[...]
10) If any trigger fails, the cdb is rolled back to a sane state and the trigger is fired again, restoring the system to its previous state.
Here I'm lost. Passive voice is the weakness here. Something has to do the "roll back to a sane state" part, and it's not clear from context what part of the system makes the decision to do so and initiates the action. We have at this point the individual scripts, the trig glue app, and the UI itself all running.
What constitutes "fails" isn't as obvious as it might sound like. Nor is "sane state". I see why you were vague; this is messy and needs serious thinking.
You are reading very closely.
It's what I do. Anyway, I asked you to write this up and you obliged. Reading it carefully seemed like the only polite thing to do.
I used passive voice because this type of functionality is not contained within any current component. It might be pushed down into cdb, with a sort of checkpoint/commit/rollback capability, but we might decide to wrap cdb with a higher level interface that does more of a transaction-style interface, setting up a session that can be modified at will and doesn't push its changes until a commit is called.
It did not make sense to write anything on that front until we decided how we wanted to address updates. If we do, out of laziness or expediency, decide to apply all changes, try them out, then reboot without committing if something goes awry, then a full-featured transaction interface would go underappreciated.
Oh , I don't know about that. An immediate response that says "Oops ... you have no route to your default gateway" is likely to be more helpful than a later "Changes did not work ... reverted to old values".
My preference: we add checkpoint, commit and rollback functions to cdb. The UI calls "cdb checkpoint" prior to modifying anything. Changes are made to the real thing, triggers are fired in turn and checked for proper exit status, and if all goes well, the UI calls "cdb commit" and the user is prompted to backup the system. If things go poorly, the UI calls "cdb rollback" and fires the triggers again. Slower, but maintains absolute continuity of system state. We would have to test to see if the speed was acceptable.
Not bad, but it is a bit all or nothing. With a complex update like my example, parts of it may be just fine, while others may fail. In the example, suppose the only problem was with the ntp server addresses; I wouldn't want the configuration of the interface itself to be rolled back because of a typo here.
That said, your thoughts are probably good enough for now. I know I need to give this more thought before I can say anything really substantive.
11) The interface displays either an error or success message. On success, the user is presented with a page offering to back up the system to the boot media thus preserving the state of the system across reboots.
My preference would be always to back up the system (or at least the cdb package) as part of a commit. Both approaches have their strengths and their defects ... probably ovbious to anyone interested in this thread ... so just listing the strengths of one and the defects of the other doesn't help much. On balance, I think prompt backup is more familiar to users, especially inexperienced ones, so that's why I favor it.
I prefer to apply the changes and ask the user to commit them explicitly. It is always harder to recover from subtle errors after writing to non-volatile media. If we follow the procedure above, it is closer to the Cisco way of doing things: apply all the changes you want, try them out, and if you bork something really bad, just power cycle the darn thing and you are guaranteed to come up in a consistent state.
This may be a matter of what you are used to. When I'm not working with Linux-based routers, I'm working with small routers from Linksys, Netgear, D-Link, and the like. Their UIs are not perfect, but they are way ahead of what I saw Linux developers coming up with for years ... and they commit changes (to some sort of NVRAM) immediately, with no rollback option ... at least the several models I've actually tested.
I suspect they have a better feel for beginning users of routers than whoever designs Cisco gear (which, last time I checked, you took classes to learn how to operate ... not LEAF's user base). So I'm more inclined to steal from ... uh, make that learn from ... Netgear and its ilk than from Cisco on UI matters.
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
