[leaf-devel] Re: CVS Access ...
Mike, Just saw a note from you talking about CVS access - I am awaiting access myself. The SF id is 'venkisiyer'. Thanks, -Venki --- 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
Re: [leaf-devel] Source: config
Mike At 10:17 04.07.2004 -0700, Mike Noyes wrote: Everyone, I'd like us to complete the work Chad Carr started on the leaf config system. This is one of the main deficiencies I feel we have presently. lrcfg isn't viable as a sole option anymore. Chad's system allows for multiple front-end support from command line to http using templates. I have contemplated some time to write a new front end to our configuration system. I am not sure just a new standardized database and API (that's what I understood Chad's system is) will be sufficient to reach this goal. IMHO what we are missing are parser and converter routines _to_and_from the existing Debian configuration files. In order to achieve this, each and every package maintainer would also have to maintain the interface routines to the respective package, else modifications to the _original_ format will go unnoticed. thoughts Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- 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
Re: [leaf-devel] Source: config
Erich -- I'll be a bit happier when this discussion starts to attract comments from someone other than the two of us (and Mike). Until then, a couple of small responses to what you wrote. (After I wrote this, I got Mike's mail forwarding Chad's messages. At this point, they don't change my thinking ... but I haven't had the time to look at the attachment he provided, to see how it amplifies what is in CVS.) At 05:47 PM 7/5/2004 +0200, Erich Titl wrote: [...] (This part is, I believe, Erich's observation, just fleshed out with examples. But I think we need conversion routines only to each package's own config files, not to *and* from them as Erich writes. M... I believe in the end the _true_ files, the ones that are actually used by the LEAF box (for example /etc/network/interfaces) should have precedence over the _config_ files, because those are the files that actually get loaded. IMHO the contents of these files should be parsed and the converted to the _config_ values which could then be used in a standardized way. The idea is to force everything to use this config database, not just to make it another option. This is achieved easily by letting the _config_ package just manipulate the config database. The above mentioned method just makes sure that all manual modifications get passed back to the database, e.g. If I modify the network configuration manually (bad habit) and then save etc.lrp and go home, the next poor luser that uses the configuration UI will get wrong information k... I disagree, especially with the easily, but in general with this philosophy. If we take this approach, then any changes made by hand to a non-database config file will propagate back to the database (or probably will, which is even worse than certainly will). This invites packagers to adopt procedures that break the UI. I would recommend that the system instead be set up so that every package is expected to create its separate config files during boot/init, drawing on the common database ... so we can be confident that changes made to the database always get propagated to the apps by a save-and-reboot procedure (the easiest thing to tell beginners to do). I'm not dead set on this ... I'm happy to listen to an argument for doing it the other way ... but I don't see the case for doing it the way you propose to be so obvious that it doesn't require an explanation. What motivates me to propose my approach is: 1. If we don't force packagers to use the config system, some of them won't, and that breaks the UI and makes things hard for naive users. (This is a perpetual battle between upstream developers and distro packagers, not something peculiar to LEAF.) 2. Having information propagate back from the app files to the database creates the risk that the configuration for one package might corrupt settings for another. Consider any of the old-days situations where users were required to enter their IP address in 2 or more places as an illustration of how this might happen. For a more current example (though one I am less certain of), what would happen to the config database if the true config files /etc/resolv.conf and wehatever dnscache uses contained inconsistent information? I'd bet that Shorewall could provide additional examples, simply because it has the most complex configuration system of anything that is a stock LEAF package. 3. Creating that part of the API, and getting it right, is more work, and projects ... especially ones that have languished for 18 months due to lack of developer interest ... should not require more work than they absolutely must. (At this point, you and I, and Mike, are the only people exhibiting even a passing interest in this topic ... and I haven't noticed any of us yet voluntering to complete this API.) I'll be interested to read what you see as the strengths of doing it the other way. I believe for the sake of a more modern UI we need a standardized API to store and retrieve config parameters. I believe also that we need the agreement of the developers involved to move towards such an API, just because they will have to maintain interface code for it. Just to be clear ... I agree 100% with this. What I was questioning in the long discussion I deleted here is whether this *particular* API was suitable for the task, or whether it combined too much complexity with too little flexibility. After all, a file that sets a bunch of shell variables, in PARAMETER=value format, is also a standardized API, albeit a very simple one. I would find it helpful if someone could illustrate how the proposed API offers more genuine flexibility than a simple system of that sort, one that would be a fairly basic extension of the approach used by the old lrcfg system. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings
[leaf-devel] cvs ssh keys?
Is it possible to use a key and ssh-agent to access the sourceforge cvs repository? Thanks, Chad --- 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
Re: [leaf-devel] cvs ssh keys?
On Mon, 2004-07-05 at 10:46, Chad Carr wrote: Is it possible to use a key and ssh-agent to access the sourceforge cvs repository? Chad, Yes, as far as I know. Please let me know if these documents fail to answer your question(s). SF Site Docs E5. Guide to generating, posting and using SSH keys https://sourceforge.net/docman/display_doc.php?docid=761group_id=1 I1. SSH Host Key Fingerprints for SSH-Accessible Hosts https://sourceforge.net/docman/display_doc.php?docid=3088group_id=1 -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Re: [leaf-devel] Source: config
At 10:30 AM 7/5/2004 -0700, Chad Carr wrote: On Jul 5, 2004, at 9:47 AM, Ray Olszewski wrote: Erich -- I'll be a bit happier when this discussion starts to attract comments from someone other than the two of us (and Mike). Until then, a couple of small responses to what you wrote. I guess you probably meant myself, Lynn or Eric, hmm? Actually no. I meant people other than Erich who are either upstream developers (e.g., Tom) or packagers (e.g., Charles). That is, the sorts of people who will actually have to use, or to ignore (as they have up to now, saving the occasional e-mail), whatever gets implemented. But any thoughts from the old development team would be great too. I don't want to go into detail regarding what you wrote. For the most part, I pretty much agree with it, especially now that I've taken the time to review some of the early discussion -- from around Feb 2003 -- on this topic. I think your closing comment is to the point: [...] I am a simple type of guy, but I truly believe that we need to start up the discussion not at cdb, which has been discussed to death (and is, frankly, complete), but at a (believe it or not) much more difficult and contentious problem, which is what to do with the stuff once we have it in there! Seriously, think about this: what if you did have the most perfect unified configuration and database interface in the universe? What would you do then? Well, I almost agree with this. Especially the difficult and contentious part. While I agree that the structure of config-db probably doesn't deserve much more disussion ... except at the nitpicky level of loose ends in the implementation ... a discussion fo the stuff one puts in it is worth having. A lot of my concern about the overall approach stemmed from reading through the draft Bering DB structure document (hier-help). It left me very confused about how the system would actually hold data. Here are some of the concerns is raises in my mind. The really really hard parts -- e.g., the structure of the Shorewall subsection -- are not yet done. Or at least I hope not ... this area lacks very basic details, such as a way to specify port forwarding/DNAT. Some of the simpler parts are described a bit too vaguely for me to get a handle on them. dns is a good example of this. Is it intended that the design force the router's own DNS resolution (in /etc/resolv.conf) to match the DNS resolution provided to dnscache? How does it handle DNS server info provided as part of a DHCP lease? Some parts seem either incorrect or incomplete. For example, where in this hierarchy does one describe the internal network? I'd guess it is in an /interface specification ... but the illustrations for this spec use the sorts of variables I associate with external networks (dhcp, pppoe, gateway), not internal networks (NAT, proxy arp, locally authoritative DNS server). Another thing that would help my thinking is a few examples of how you'd expect init or install scripts to use the database. How, for example, would a package that needs to know the IP address of the external interface (if static) or how it is provided (if ppp or pppoe) get this info from the database? How would an ntp server or client get the address(es) of the timeserver(s) it is to use? More generally, how would dynamic address assignment on the external interface be handled? Would every update of the address cause an update to the database, with anything that needs the address (e.g., Shorewall) getting the info from the updated database? Or would the daabase just store the fact that the address is dynamic, with changes handled as they are today? (I think you intend the second.) How would the system handle a package change? For example, if the user were to replace dnscache with a different resolver, or Shorewall with a different firewall, how would that get reflected in the database? Or even more basically, just adding a package not on the list (an SMTP forwarder, or a proxy server)? Is the system intended to handle hardware issues at all? I wonder especially about what always seems to be the #1 hardware issue for LEAF -- NIC detection and module support. My guess here is NO -- that the process of configuring LEAF to match the hardware ... and generally, adding kernel modules of any sort ... will remain outside the config system. We might ask ourselves if we are happy with that limitation. Finally, what would a setup User Interface -- console based or Web based -- to this system look like? Yes, I know this is a big question, but I'd hope you and your co-developers had something in mind when you designed the database. The database contents seem very messy in some ways, and I'd be unhappy with a UI that simply exported that messiness for a naive user to confront directly. Probably some of this was discussed a year ago, though I didn't find that discussion today when I looked. BTW, I'd still like to read Erich's
Re: [leaf-devel] Source: config
On Mon, 2004-07-05 at 11:36, Etienne Charlier wrote: I'm really glad that this thread started up! I can help modifying package to take care of the reading config values from the repository !! Etienne, Would you like write access to src/config in cvs? -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Re: [leaf-devel] Source: config
On Mon, 2004-07-05 at 12:17, Ray Olszewski wrote: Probably some of this was discussed a year ago, though I didn't find that discussion today when I looked. Ray, Unfortunately, much of the discussion was held in off list messages and irc, so the content isn't available. :-( BTW, I'd still like to read Erich's explanation of why he thinks package config files should have priority over the central db. Though I obviously agree with Chad's comments (deleted here, they basically said they agreed with my prior comments), I really would like to read the othe side of this argument, and a packager or developer is the likely person to make in in its best form. I worry that I am (and you are) missing something important. I'd like to here Erich's reasoning also. -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Re: [leaf-devel] Source: config
On Jul 5, 2004, at 12:17 PM, Ray Olszewski wrote: At 10:30 AM 7/5/2004 -0700, Chad Carr wrote: On Jul 5, 2004, at 9:47 AM, Ray Olszewski wrote: Erich -- I'll be a bit happier when this discussion starts to attract comments from someone other than the two of us (and Mike). Until then, a couple of small responses to what you wrote. I guess you probably meant myself, Lynn or Eric, hmm? Actually no. I meant people other than Erich who are either upstream developers (e.g., Tom) or packagers (e.g., Charles). That is, the sorts of people who will actually have to use, or to ignore (as they have up to now, saving the occasional e-mail), whatever gets implemented. But any thoughts from the old development team would be great too. Sorry. I guess my assumption was a bit egocentric. I didn't intend it that way. I do hope however that your ignore comment is not a value judgment on either the code or design; it is extraordinarily easy to ignore code that is not complete! Comments inline. While I agree that the structure of config-db probably doesn't deserve much more disussion ... except at the nitpicky level of loose ends in the implementation We will likely be discovering these for some time to come... ... a discussion fo the stuff one puts in it is worth having. A lot of my concern about the overall approach stemmed from reading through the draft Bering DB structure document (hier-help). It left me very confused about how the system would actually hold data. Here are some of the concerns is raises in my mind. Please do not be distressed by hier.help. I have spent a sum total of a couple of hours thinking about and writing text into that file. I spent the majority of my time creating and thinking about a nice generic storage mechanism, which I believe is what we now have in cdb. Seriously, the package maintainers and developers are the one's who are much more competent at laying out the hierarchy. I am just a humble(?) tool creator... The really really hard parts -- e.g., the structure of the Shorewall subsection -- are not yet done. Or at least I hope not ... this area lacks very basic details, such as a way to specify port forwarding/DNAT. Correct, not done. The problem(?) with generic storage of ip firewalling/tunneling/etc. parameters is that Tom has done such an outstanding job of breaking down the model in his own config file set. Frankly, the cdb model will likely look a lot like Tom's model, with the files as directory keys and the lines and their column headers as the individual name-value pairs. Again, package maintainers and developers are much stronger at this than I am, so please don't take it's absence as an indication of cdb's inadequecy. Some of the simpler parts are described a bit too vaguely for me to get a handle on them. dns is a good example of this. Is it intended that the design force the router's own DNS resolution (in /etc/resolv.conf) to match the DNS resolution provided to dnscache? How does it handle DNS server info provided as part of a DHCP lease? Again, package maintainers could speak better to this, but being a programmer, I would likely say something vague like not necessarily. There might be global name resolution parameters to be used in /etc/resolv.conf, which might then be overridden by a forwarders key under the dns tree. On the dynamic stuff, that is exactly what I would like to discuss with people. Obviously, the easiest thing to do is put an indicator in the cdb that the configuration of a given element (in this case an interface) is dynamic, then the specifics of obtaining the interface-specific information are outside the purview of the cdb. But that breaks our nice encapsulation, doesn't it? Not to mention that there are (at least in the case of dhcp client) several different (package specific) ways of going about finding the information you desire...a conundrum, but definitely needs to be part of the upcoming discussion. Some parts seem either incorrect or incomplete. For example, where in this hierarchy does one describe the internal network? I'd guess it is in an /interface specification ... but the illustrations for this spec use the sorts of variables I associate with external networks (dhcp, pppoe, gateway), not internal networks (NAT, proxy arp, locally authoritative DNS server). Likely incomplete. There is no reason to define an interface as internal or external until you start giving it a job (acquiring an address, filtering packets, etc.) so these terms need to be logical terms laid on top of interfaces, not part of the definition of the hierarchy itself, right? Another thing that would help my thinking is a few examples of how you'd expect init or install scripts to use the database. How, for example, would a package that needs to know the IP address of the external interface (if static) or how it is provided (if ppp or pppoe) get this info from the database? How would an ntp
Re: [leaf-devel] Source: config
On Jul 5, 2004, at 1:24 PM, Erich Titl wrote: Your analysis is convincing, especially as it covers the most important part of getting the system configured the way the user wants it. My suggestion to allow the inverse way was wrong in the way it was formulated. I would actually love if the UI showed the _actual_ state of the system. regardless of the config files, because the end user will typically also use such tools to check the actual system status. If this is consistent with the system status at load of the UI we'd have a good starting point. Whenever a change is confirmed in the UI this state should be written to the config database _and_ the system which would keep us in a consistent state. This would, of course, require quite a sophisticated control mechanism, e.g. when the user changes an IP address, subsystems like shorewall and ipsec would probably have to be reconfigured and restarted. The purpose of having trig is to handle system-wide notifications of cdb changes for just this purpose. The idea is that the user makes a configuration change in the cdb, then the UI calls a predefined trigger method for that change. Any package that needs to know about that change registers for the event by dropping a shell script in the proper directory on the system, which is called when the trigger fires. The package can do whatever it wants in that script, up to and including rewriting its configuration files, setting other cdb variables, restarting dependent services, etc. Hope this makes sense. It does to me. --- 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
Re: [leaf-devel] Source: config
Hello List, sorry for being so quiet for so long, my new job is takeing lots of energy and time. ( but positiv stress :) ) I just uploaded the work in progress on the cdb.lrp and weblet.lrp on my server at http://www.leafinfo.com/webconfig/ I played a lot with the webbased configuration, and changed the database even more times. the system is based on chads cdb ( only very small correction) my own tmpl (details on the page) every template carries its own destination, its postinstall routine and the informationpath in the database. In contrast to chads tmpl it is rather primitive with temporary files and use of sed. But it achieves just what I wanted to do with it. It also can be used to drop in for.example the webpages used ot configure the package. I will try to keep up to date with the list. regards Eric Wolzak --- 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
Re: [leaf-devel] Source: config
On Mon, 5 Jul 2004, Ray Olszewski wrote: The really really hard parts -- e.g., the structure of the Shorewall subsection -- are not yet done. Or at least I hope not ... this area lacks very basic details, such as a way to specify port forwarding/DNAT. Here are some random thoughts. I don't understand what requirements the solution that you are designing is supposed to meet. If it is to make things simple for newbies then you may end up with two very different ways to configure a Bering box -- using the config files directly and using the configDB/UI. My experience with Shorewall was that this approach works badly because when people outgrow the 'newbie solution' then they have a big learning curve to be able to configure 'the real way'. Through the UI, you will have established an unrealistic level of expectation. If you intend the configDB/UI to be *the* way to configure the box then the database and UI should reflect a similar abstraction and I have a difficult time understanding why it would be desirable for the Shorewall UI to present a different firewall model from the text-file database that Shorewall currently uses. If the UI does not mirror the Shorewall configuration files (in a manner similar to the Webmin Shorewall Interface) then users can't make use of the Shorewall documentation to configure Shorewall through the UI. Furthermore, if the interface is significantly different from the Shorewall documentation then people who use Shorewall on a platform other than LEAF can't help those who only know how to use the LEAF UI (and if some folks participating in this discussion have their way, there would be no way to reload the database from the Shorewall config files). 10 years ago or so, I worked on a project to create a centralized configuration database and UI for Tandem NonStop (tm) systems; that project was eventually abandoned. Some of the issues were: a) what are the product/database synchronization rules? b) Who is responsible for updating the DB/UI when the product changes? c) How does product upgrade/downgrade interact with the database/UI? d) How are Database-UI/product version differences accommodated? e) How do I install/uninstall a product. In our case, the intractable problems were more organizational than technical. I would like to participate further in these discussions but my schedule is very full these days; nevertheless, I'll try to follow the discussion. -Tom -- Tom Eastep\ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] --- 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
Re: [leaf-devel] Source: config
At 10:24 PM 7/5/2004 +0200, Erich Titl wrote: [...] I'm not dead set on this ... I'm happy to listen to an argument for doing it the other way ... but I don't see the case for doing it the way you propose to be so obvious that it doesn't require an explanation. What motivates me to propose my approach is: 1. If we don't force packagers to use the config system, some of them won't, and that breaks the UI and makes things hard for naive users. (This is a perpetual battle between upstream developers and distro packagers, not something peculiar to LEAF.) Force such a strong word. It will be hard to force anyone to change his API when his product is distributed a zillion times, successful and he's moved on to other chores. Of course you are right, but this is not the ideal world. I would prefer the _invite_ method :-) I was not sufficiently clear here, I'm afraid. There is no way to force actual developers of applications to do anything. But we can insist that anything packaged for LEAF conform to LEAF packaging standards, just as other, larger distros do. Debian, for example, limits official .deb packages (there are unofficial Debian repositories, too) to ones that conform to Debian packaging guidelines and that are maintained by a registered Debian maintainer. An example of this, one familiar to LEAF developers, is Shorewall. Tom himself distrbutes a .tgz, a .rpm. and a .lrp version of Shorewall. A Debian maintainer other than Tom repackages Shorewall as a .deb (Tom links to it on the Shorewall page). I don't know the mechanism, but the various .rpm-based distros must do something similar, at least for the packages they make part of the distros. That is why I spoke of forcing *packagers* (not developers) to use the system. Sorry if my prior lack of precision her eclouded things up. 2. Having information propagate back from the app files to the database creates the risk that the configuration for one package might corrupt settings for another. Consider any of the old-days situations where users were required to enter their IP address in 2 or more places as an illustration of how this might happen. For a more current example (though one I am less certain of), what would happen to the config database if the true config files /etc/resolv.conf and wehatever dnscache uses contained inconsistent information? I'd bet that Shorewall could provide additional examples, simply because it has the most complex configuration system of anything that is a stock LEAF package. Good point, something that bothered me a long time. Actually, a couple of comments Chad made today are relevant here. I don't understand how the leaf-tools config system can enforce either entry locking or uniqueness of variable names. If any script can write to the database, then (potentially) any package script can change global settings. And there might also be race conditions and deadlocks. All of this is not actually awful in an embedded-systems setting like LEAF ... it's not even unusual ... but embedded systems don't usually support drop-in packages either. Probably Chad and the others implemented some mechanisms to handle this stuff, but I've missed what they are. 3. Creating that part of the API, and getting it right, is more work, and projects ... especially ones that have languished for 18 months due to lack of developer interest ... should not require more work than they absolutely must. (At this point, you and I, and Mike, are the only people exhibiting even a passing interest in this topic ... and I haven't noticed any of us yet voluntering to complete this API.) I'll be interested to read what you see as the strengths of doing it the other way. Your analysis is convincing, especially as it covers the most important part of getting the system configured the way the user wants it. My suggestion to allow the inverse way was wrong in the way it was formulated. I would actually love if the UI showed the _actual_ state of the system. regardless of the config files, because the end user will typically also use such tools to check the actual system status. If this is consistent with the system status at load of the UI we'd have a good starting point. Yes, this is a tough one. For any UI to work, LEAF has to insist on *some* sort of cooperation from packagers. Using the config database exclusively is my current candidate something. Another is that a package always include a script that will, on demand, read all its config variables and report them in some standard form (hey, how about the database format?), and another one that will accept back that same list of variables in a standard form and update the config files. This is close to what you were suggesting. There are probably other ways to do it too. But if we don't require *something* of packagers (not of upstream developers; remember the distinction), then no config system will ever be able to handle a
Re: [leaf-devel] Source: config
Hello Tom, Ray- that is exactly the problem I found by working on this system. To create a UI for a limited set is good possible, and by giving people the change to only select limited possibilities reduces errors ( masks , Broadcast and so on) It is also possible to simply forward certain ports for servers ( like gaming and peer2peer networks) . If you want to use your UI for the more complex system you are complicating the settings for the average user. The overall complexity is enormeous. So what I would like is to use the database for those settings that are common to all kind of packages (local IP, Hostname and so on), This will limit the number of things people has to do to start. So you could use a webconfig for the level of a advanced home router. If you want to go beyond that, you will have to have knowledge of routing and so on anyway, and then it would be better to keep to the more universal solutions.( which means a much larger base of possible literature and helping hands regards Eric wolzak From: Tom Eastep [EMAIL PROTECTED] To: Ray Olszewski [EMAIL PROTECTED] Copies to: [EMAIL PROTECTED] Subject:Re: [leaf-devel] Source: config Date sent: Mon, 5 Jul 2004 14:15:39 -0700 (Pacific Daylight Time) On Mon, 5 Jul 2004, Ray Olszewski wrote: The really really hard parts -- e.g., the structure of the Shorewall subsection -- are not yet done. Or at least I hope not ... this area lacks very basic details, such as a way to specify port forwarding/DNAT. Here are some random thoughts. I don't understand what requirements the solution that you are designing is supposed to meet. If it is to make things simple for newbies then you may end up with two very different ways to configure a Bering box -- using the config files directly and using the configDB/UI. My experience with Shorewall was that this approach works badly because when people outgrow the 'newbie solution' then they have a big learning curve to be able to configure 'the real way'. Through the UI, you will have established an unrealistic level of expectation. If you intend the configDB/UI to be *the* way to configure the box then the database and UI should reflect a similar abstraction and I have a difficult time understanding why it would be desirable for the Shorewall UI to present a different firewall model from the text-file database that Shorewall currently uses. If the UI does not mirror the Shorewall configuration files (in a manner similar to the Webmin Shorewall Interface) then users can't make use of the Shorewall documentation to configure Shorewall through the UI. Furthermore, if the interface is significantly different from the Shorewall documentation then people who use Shorewall on a platform other than LEAF can't help those who only know how to use the LEAF UI (and if some folks participating in this discussion have their way, there would be no way to reload the database from the Shorewall config files). 10 years ago or so, I worked on a project to create a centralized configuration database and UI for Tandem NonStop (tm) systems; that project was eventually abandoned. Some of the issues were: a) what are the product/database synchronization rules? b) Who is responsible for updating the DB/UI when the product changes? c) How does product upgrade/downgrade interact with the database/UI? d) How are Database-UI/product version differences accommodated? e) How do I install/uninstall a product. In our case, the intractable problems were more organizational than technical. I would like to participate further in these discussions but my schedule is very full these days; nevertheless, I'll try to follow the discussion. -Tom -- Tom Eastep\ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] --- 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 --- 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
Re: [leaf-devel] Source: config
--- Ray Olszewski [EMAIL PROTECTED] wrote: Actually no. I meant people other than Erich who are either upstream developers (e.g., Tom) or packagers (e.g., Charles). That is, the sorts of people who will actually have to use, or to ignore (as they have up to now, saving the occasional e-mail), whatever gets implemented. But any thoughts from the old development team would be great too. I don't know if you want to hear from someone who was hoping cdb would take off, but had to do a web-based configuration UI on bering anyway.. but here goes. I would have prefered to use cdb, /if that's what was mainstream/ but it was in early development when we started working on our UI, and then it got ignored. What we ended up doing was writing shell scripts that directly modify the configuration files themselves, and have the smarts to look for related packages to grap what the web-script needs. (e.g. dhcpd has to look at interfaces to figure out which interfaces it could serve dhcp addresses on) In a few cases, we source foo=bar ... files. (but from experience, I can count the number of variables that we need to store this way on one hand.) The biggest headache so far has been dealing with the case where the web-based script makes a change, and then a custom tweak is made afterward. Generally, our configuration files have comments in them that read: #vv managed by web interface do not edit below this line .. #^^^ managed by web interface do not edit above this line and then have the script just spit out everyhing above and below the markers, managing only what is inbetween. So far its worked as a fair compromise, but our userbase either only uses the web interface, only uses ssh, or wrote the web-script and knows how to tweak things. :-) It works as an advanced home router for the web case. I'm not at liberty to give the whole web thing away, but if anyone is interested I could peel off a few cgi's as a demo. But, as an integrator (sitting between user and developer) I would have preferred to use the cdb approach, but don't want to have to be the one to define the cdb database/heirarchy, etc. for all of the packages. If there was some consensus of what goes in the database and who puts it there, I'd be happy to use it. hope this helps. --- 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
Re: [leaf-devel] Source: config
On Jul 5, 2004, at 2:19 PM, Ray Olszewski wrote: Some discussion of this might be profitable. I think so, too. Shall we start? I really do think we can work through this, I do. We just need to talk it through. We should probably start up a task force of some kind consisting at least one each of coder, networking specialist, system engineer, packager, and communicator (to encapsulate things and document better than any of us has done, then communicate it back to the list and take feedback, possibly drawing pictures along the way). I don't know if Eric or Lynn has the time to rejoin the team, but I am game now (new job transition is nearly over so I should be freeing up quite a bit any day now). If anyone sees their job title in the above list, please ask Mike for write access to the repository and let me know so we can start right away. Until then, we should keep throwing ideas out to the list and gathering them up to make sense of them. Ray, I will attempt to draw out a better view of my concepts for the leaf-tools. Possibly with pictures, if I can muster it. It all fits inside my head quite neatly, but splashes out all over the place when it hits the list. If I can just get it on paper in a way that folks can understand it, I am sure everyone will think what we have is a pretty good start. Thanks, Chad --- 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
[leaf-devel] leaf-tools overview (cdb, trig, tmpl)
All, I started to draw this out, but I just simply do not have skills in that area. Some would question my verbal skills as well, but here goes: Each of the tools (cdb, trig and tmpl) represents a data store. cdb - abstract configuration variables trig - abstract actions tied to those variables, with package-specific handlers tmpl - package-specific data allowing the creation of operational configuration files from abstract configuration data. The idea is that an interface (of arbitrary complexity) needs only to know the abstract values (configuration parameters and trigger actions), and the packages can make themselves work. It would go something like this: 1) The user chooses to configure his or her LEAF router via an interface (web, ncurses, etc.) backed by leaf-tools. 2) The interface makes one or more calls to cdb to obtain the current canonical values for a handful of (hopefully related) configuration parameters. 3) Cdb returns these values to the interface as name=value pairs that may be sourced via the usual shell script methods. 4) The interface draws some sort of user-friendly input device (probably a form of some kind) to display those values and allow the user to alter them. 5) The interface accepts the user input, then makes one or more calls to cdb to update the configuration data. 6) This data is inserted into cdb's backing store (whatever that happens to be!) 7) The interface triggers one or more system events by calling trig with the name of the event and optional parameters. 8) Trig runs the scripts that have registered for that event (by dropping themselves into the proper directory). The sequencing of this execution is controlled via leading index numbers (think SysV init scripts). 9) Each script decides for itself what needs to be done on each system event. Generally, this will involve reading the new values from cdb, rewriting its configuration files using the new values, then restarting or otherwise re-initializing itself 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. 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. Now, that is what is in my head, but as you can see, there are several points of contention that need to be discussed thoroughly. But, none of the points of contention have anything to do with the design of the backing store model. Frankly, it is a very small part of the overall design and, while cdb may not be perfect, it does work, quite well in fact, and it is done. I say we all take a look at it, stamp it with approval or disapproval, and move on to more pressing questions, like when to back up changes and how the hell to write a full-featured templating system in the 92k stripped down /bin/sh from Oxygen! --- 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
Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
On Mon, 2004-07-05 at 16:14, Chad Carr wrote: I started to draw this out, but I just simply do not have skills in that area. Some would question my verbal skills as well, but here goes: Chad, Dia will help with diagramming, even UML. I hope this information is useful. Dia's homepage http://www.gnome.org/projects/dia/ A UML tutorial http://www.gnome.org/projects/dia/umltut/index.html Tools that generate Dia diagrams http://www.gnome.org/projects/dia/links.html -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
On Mon, 2004-07-05 at 16:14, Chad Carr wrote: 6) This data is inserted into cdb's backing store (whatever that happens to be!) Chad, Would SQLite work as cdb's backing store, or am I misunderstanding what a backing store is? SQLite http://www.sqlite.org/ -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
sqlite would certainly work, but the cdb utility would need to be rewritten in C or C++ and would no longer be hand editable. That is why the current version is written to use the filesystem as the backing store. In my mind, advanced users would be able to hand-tune the cdb repository, then hand-run the trigger scripts, thus saving them from the peril of using a graphical user interface. That is, of course, in my mind. On Jul 5, 2004, at 5:20 PM, Mike Noyes wrote: On Mon, 2004-07-05 at 16:14, Chad Carr wrote: 6) This data is inserted into cdb's backing store (whatever that happens to be!) Chad, Would SQLite work as cdb's backing store, or am I misunderstanding what a backing store is? SQLite http://www.sqlite.org/ -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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 --- 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
[leaf-devel] inverting exit status
Shell gurus, Is there a reliable cross-platform way to write an inverted if statement? Something like bash's: if ! /usr/bin/false # with some other command, obviously then # do something true else # do something false fi Your assistance is greatly appreciated. Chad --- 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
Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
Mike Noyes wrote: On Mon, 2004-07-05 at 16:14, Chad Carr wrote: I say we all take a look at it, stamp it with approval or disapproval, and move on to more pressing questions, like when to back up changes and how the hell to write a full-featured templating system in the 92k stripped down /bin/sh from Oxygen! Chad, Dash may help in this area. http://gondor.apana.org.au/~herbert/dash/ DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible. Mike -- Dash and Ash are very similar. I've worked with the Dash developer to ensure that Shorewall works with it. -Tom -- Tom Eastep\ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] --- 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
Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
On Mon, 2004-07-05 at 17:33, Chad Carr wrote: sqlite would certainly work, but the cdb utility would need to be rewritten in C or C++ and would no longer be hand editable. That is why the current version is written to use the filesystem as the backing store. In my mind, advanced users would be able to hand-tune the cdb repository, then hand-run the trigger scripts, thus saving them from the peril of using a graphical user interface. That is, of course, in my mind. Chad, Ah. I now remember this from a previous conversation. I had a feeling I was beyond my depth making the SQLite suggestion. On Jul 5, 2004, at 5:20 PM, Mike Noyes wrote: On Mon, 2004-07-05 at 16:14, Chad Carr wrote: 6) This data is inserted into cdb's backing store (whatever that happens to be!) Chad, Would SQLite work as cdb's backing store, or am I misunderstanding what a backing store is? SQLite http://www.sqlite.org/ -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Re: [leaf-devel] inverting exit status
On Mon, 2004-07-05 at 17:39, Chad Carr wrote: Shell gurus, Chad, I'm by no means a shell guru, but this Google string may help. Google string: inverted if posix ash Is there a reliable cross-platform way to write an inverted if statement? Something like bash's: if ! /usr/bin/false # with some other command, obviously then # do something true else # do something false fi Your assistance is greatly appreciated. I hope this is helpful. -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
On Jul 5, 2004, at 5:43 PM, Tom Eastep wrote: Mike Noyes wrote: On Mon, 2004-07-05 at 16:14, Chad Carr wrote: I say we all take a look at it, stamp it with approval or disapproval, and move on to more pressing questions, like when to back up changes and how the hell to write a full-featured templating system in the 92k stripped down /bin/sh from Oxygen! Chad, Dash may help in this area. http://gondor.apana.org.au/~herbert/dash/ DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible. Mike -- Dash and Ash are very similar. I've worked with the Dash developer to ensure that Shorewall works with it. Nice shell, by the way. 76k stripped, runs cdb test harness without errors. Nice. Which (if any) current LEAF distros run this shell by default? Is it nicely packaged for any of the others? --- 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
Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
On Mon, 2004-07-05 at 18:08, Chad Carr wrote: On Jul 5, 2004, at 5:43 PM, Tom Eastep wrote: Mike Noyes wrote: Dash may help in this area. http://gondor.apana.org.au/~herbert/dash/ DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible. Mike -- Dash and Ash are very similar. I've worked with the Dash developer to ensure that Shorewall works with it. Nice shell, by the way. 76k stripped, runs cdb test harness without errors. Nice. Which (if any) current LEAF distros run this shell by default? Is it nicely packaged for any of the others? Chad, This is the status of Dash as I know it. Bering-uClibc: evaluating Lince WISP-Dist: unknown Bering Oxygen: no -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
On Mon, 2004-07-05 at 17:43, Tom Eastep wrote: Mike Noyes wrote: Dash may help in this area. http://gondor.apana.org.au/~herbert/dash/ DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible. Mike -- Dash and Ash are very similar. I've worked with the Dash developer to ensure that Shorewall works with it. Tom, That's good news. :-) Do you know if the Bering-uClibc team has done any regression testing yet? -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Re: [leaf-devel] Source: config
On Mon, 2004-07-05 at 14:41, Nathan Angelacos wrote: It works as an advanced home router for the web case. I'm not at liberty to give the whole web thing away, but if anyone is interested I could peel off a few cgi's as a demo. Nathan, Are you willing to donate your snippet(s) of code to the project? But, as an integrator (sitting between user and developer) I would have preferred to use the cdb approach, but don't want to have to be the one to define the cdb database/heirarchy, etc. for all of the packages. If there was some consensus of what goes in the database and who puts it there, I'd be happy to use it. Understood. I hope we can accommodate your wish by developing something all of us can make use of. -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
At 04:14 PM 7/5/2004 -0700, Chad Carr wrote: All, I started to draw this out, but I just simply do not have skills in that area. Some would question my verbal skills as well, \ Not me. At least, not based on this message ... it is exactly what I was asking for youi to clarify. I'm going to walk through the steps below, choosing to focus on a concrete example: using a Web interface to enter a static IP address, and related information, for the external interface. It's a fairly common need, one that users will often have to do as a first thing. If this exercise works ... I'm actually doing it as I write this reply ... you'll see the point by the end. but here goes: Each of the tools (cdb, trig and tmpl) represents a data store. cdb - abstract configuration variables trig- abstract actions tied to those variables, with package-specific handlers tmpl- package-specific data allowing the creation of operational configuration files from abstract configuration data. The idea is that an interface (of arbitrary complexity) needs only to know the abstract values (configuration parameters and trigger actions), and the packages can make themselves work. It would go something like this: 1) The user chooses to configure his or her LEAF router via an interface (web, ncurses, etc.) backed by leaf-tools. OK. He or she connects via a browser to a Weblet-like server. It displays some sort of top-level menu. One choice is something like Configure Connection to ISP. User chooses that. 2) The interface makes one or more calls to cdb to obtain the current canonical values for a handful of (hopefully related) configuration parameters. OK. In practice, this sort of setup would have to get the following variables. (Actually, since this is a first configuration, it doesn't really have to get anything, except perhaps the identity of the external interface.) The choice in [] is the default/current setting. identity of external interface: [eth0]/eth1 MAC address of interface: [aa:bb:cc:dd:ee:ff] (might use this for cases where the system needs to do MAC-address spoofing to deal with ISP authentication baloney) address assignment method: [static]/dhcp/pppoe IP address: [0.0.0.0] Netmask: [0.0.0.0] (or maybe /0) Broadcast: [255.255.255.255] Gateway: [0.0.0.0] DNS Server 1: [0.0.0.0] DNS Server 2: [0.0.0.0] (could be more DNS servers, but ISPs typically provide 2) Userid: [] Password: [] (rarely needed with static connections; often needed with PPPoE) (these next few might not be part of this page) SMTP server: [] (this would be an FQN, not an IP address) NTP Server 1:[] (should take an FQN or an IP address) NTP Server 2:[] (should take an FQN or an IP address) How does the list of available interfaces (the first item above) get generated? My guess is that for hardware-level issues, LEAF, and any UI for it, should NOT rely on the database. So in this instance, it actually checks for the physical interfaces (eth*) present, makes them available for selection, and in the absence of a prior configuration, queries cdb for a default choice (eth0 for external, eth1 for internal, eth2 if a DMZ option is available). For PPPoE, the system still wants to know the physical interface to use; the ppp0 interface can be invisible to the UI. Only if the system supports dial-up should a ppp0 be an explicit choice for users. 3) Cdb returns these values to the interface as name=value pairs that may be sourced via the usual shell script methods. This part would look roughly like this (from my memory of how LRP did it in the old days): $IF_EXT=eth0 $MAC_EXT=aa:bb:cc:dd:ee:ff $IP_EXT_STATIC=true $IP_EXT_PPPOE=false $IP_EXT_DHCP=false $IP_EXT_ADDRESS=0.0.0.0 $IP_EXT_NETMASK=0.0.0.0 $IP_EXT_BROADCAST=255.255.255.255 $IP_EXT_GW=0.0.0.0 $IP_EXT_DNS1=0.0.0.0 $IP_EXT_DNS2=0.0.0.0 $IP_EXT_USERID= $IP_EXT_PASSWD= $IP_EXT_SMTP= $IP_EXT_NTP1= $IP_EXT_NTP2= 4) The interface draws some sort of user-friendly input device (probably a form of some kind) to display those values and allow the user to alter them. Right. I assume the Web system would at a minimum support CGI scripts. Javascript is nice for this sort of stuff, but probably beyond LEAF's limited Web-server capacity. Remember that altering the values might require additional calls to cdb. In the example, the obvious candidate is identity of external interface -- if the user changes it from eth0 to eth1, the rest of the $IF_* values might need to be replaced with the cdb values for eth1. (Or maybe not - swapping interfaces is kind of tricky from a UI perspective.) 5) The interface accepts the user input, then makes one or more calls to cdb to update the configuration data. Where
Re: [leaf-devel] inverting exit status
Chad Carr wrote:
Shell gurus,
Is there a reliable cross-platform way to write an inverted if
statement? Something like bash's:
if ! /usr/bin/false # with some other command, obviously
then
# do something true
else
# do something false
fi
Your assistance is greatly appreciated.
Just shuffle the then and else code around as appropriate for the
sense of the exit condition you're checking for.
If that's not an option (ie: you're only checking one case, and don't
want an empty then), you can do something like
if /usr/bin/false ; [ $? -ne 0 ] ; then
...
or more typically:
/usr/bin/false
if [ $? -ne 0 ] ; then
...
or even:
/usr/bin/false
retcode=$?
...
if [ $retcode -ne 0 ] ; then
...
If you're just trying to test for error codes or something, the
following might be handy:
abort() { ... }
# Call an abort procedure if command1 fails
/usr/bin/command1 || abort
# Run several commands if command2 fails
/usr/bin/command2 || { echo ERROR!!! ; exit ; }
HTH
--
Charles Steinkuehler
[EMAIL PROTECTED]
---
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
Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
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. On Jul 5, 2004, at 7:15 PM, Ray Olszewski wrote: At 04:14 PM 7/5/2004 -0700, Chad Carr wrote: All, I started to draw this out, but I just simply do not have skills in that area. Some would question my verbal skills as well, \ Not me. At least, not based on this message ... it is exactly what I was asking for youi to clarify. I'm going to walk through the steps below, choosing to focus on a concrete example: using a Web interface to enter a static IP address, and related information, for the external interface. It's a fairly common need, one that users will often have to do as a first thing. If this exercise works ... I'm actually doing it as I write this reply ... you'll see the point by the end. but here goes: Each of the tools (cdb, trig and tmpl) represents a data store. cdb - abstract configuration variables trig- abstract actions tied to those variables, with package-specific handlers tmpl- package-specific data allowing the creation of operational configuration files from abstract configuration data. The idea is that an interface (of arbitrary complexity) needs only to know the abstract values (configuration parameters and trigger actions), and the packages can make themselves work. It would go something like this: 1) The user chooses to configure his or her LEAF router via an interface (web, ncurses, etc.) backed by leaf-tools. OK. He or she connects via a browser to a Weblet-like server. It displays some sort of top-level menu. One choice is something like Configure Connection to ISP. User chooses that. 2) The interface makes one or more calls to cdb to obtain the current canonical values for a handful of (hopefully related) configuration parameters. OK. In practice, this sort of setup would have to get the following variables. (Actually, since this is a first configuration, it doesn't really have to get anything, except perhaps the identity of the external interface.) The choice in [] is the default/current setting. identity of external interface: [eth0]/eth1 MAC address of interface: [aa:bb:cc:dd:ee:ff] (might use this for cases where the system needs to do MAC-address spoofing to deal with ISP authentication baloney) address assignment method: [static]/dhcp/pppoe IP address: [0.0.0.0] Netmask: [0.0.0.0] (or maybe /0) Broadcast: [255.255.255.255] Gateway: [0.0.0.0] DNS Server 1: [0.0.0.0] DNS Server 2: [0.0.0.0] (could be more DNS servers, but ISPs typically provide 2) Userid: [] Password: [] (rarely needed with static connections; often needed with PPPoE) (these next few might not be part of this page) SMTP server: [] (this would be an FQN, not an IP address) NTP Server 1:[] (should take an FQN or an IP address) NTP Server 2:[] (should take an FQN or an IP address) How does the list of available interfaces (the first item above) get generated? My guess is that for hardware-level issues, LEAF, and any UI for it, should NOT rely on the database. So in this instance, it actually checks for the physical interfaces (eth*) present, makes them available for selection, and in the absence of a prior configuration, queries cdb for a default choice (eth0 for external, eth1 for internal, eth2 if a DMZ option is available). For PPPoE, the system still wants to know the physical interface to use; the ppp0 interface can be invisible to the UI. Only if the system supports dial-up should a ppp0 be an explicit choice for users. This is a real rat's nest. There are a couple of main problems with interface configuration itself: 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. 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. 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. 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!) We do have a discussion waiting for us on the best way for the system to handle dynamically
RE: [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
Why not look at sleepycat DB? It has an XML DB option which will give us extensibility and also make it easy to interface to external systems. Config file can be in readable XML format also. IMHO a very attractive option. Warm regards Mohan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chad Carr Sent: Tuesday, July 06, 2004 6:04 AM To: [EMAIL PROTECTED] Subject: Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl) sqlite would certainly work, but the cdb utility would need to be rewritten in C or C++ and would no longer be hand editable. That is why the current version is written to use the filesystem as the backing store. In my mind, advanced users would be able to hand-tune the cdb repository, then hand-run the trigger scripts, thus saving them from the peril of using a graphical user interface. That is, of course, in my mind. On Jul 5, 2004, at 5:20 PM, Mike Noyes wrote: On Mon, 2004-07-05 at 16:14, Chad Carr wrote: 6) This data is inserted into cdb's backing store (whatever that happens to be!) Chad, Would SQLite work as cdb's backing store, or am I misunderstanding what a backing store is? SQLite http://www.sqlite.org/ -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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 --- 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 --- 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
RE: [leaf-devel] Source: config
Count me in - system engineer, network designer, documentation, UI designer . I can write the manuals as I've done before (QoS and Bridging). I can contribute in the form of drawing up requirements and validating them from an end user's perspective. Warm regards Mohan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chad Carr Sent: Tuesday, July 06, 2004 3:13 AM To: Ray Olszewski Cc: [EMAIL PROTECTED] Subject: Re: [leaf-devel] Source: config On Jul 5, 2004, at 2:19 PM, Ray Olszewski wrote: Some discussion of this might be profitable. I think so, too. Shall we start? I really do think we can work through this, I do. We just need to talk it through. We should probably start up a task force of some kind consisting at least one each of coder, networking specialist, system engineer, packager, and communicator (to encapsulate things and document better than any of us has done, then communicate it back to the list and take feedback, possibly drawing pictures along the way). I don't know if Eric or Lynn has the time to rejoin the team, but I am game now (new job transition is nearly over so I should be freeing up quite a bit any day now). If anyone sees their job title in the above list, please ask Mike for write access to the repository and let me know so we can start right away. Until then, we should keep throwing ideas out to the list and gathering them up to make sense of them. Thanks, Chad --- 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
Re: [leaf-devel] Source: config
On Jul 5, 2004, at 9:58 PM, S Mohan wrote: Chad and list, Are the triggers asynchronous or synchronous? I imagine triggers can be used for semantic validation across packages and take appropriate decisions. If it does come to an irresolvable state, then errors have to be directed back to the initiator. From my limited knowledge, this would mean the triggers should be synchronous. The other problem with synchronicity is that we run the danger of hanging in case the trigger misbehaves. The simple way is synchronous. Unfortunately synchronous is generally slow, and, as you mentioned, a way for an ill-behaved trigger script to make a mockery of the system. A decision that must be made, and soon. The key is to have errors trapped neatly inline and fed back to the initiator without passing control back till a exit status is passed back. This will be particularly so for CLI where errors need to be reported immediately. It is possible to use cdb as a message board for asynchronous programs. Each trigger could be called with the name of a key array to write errors to. This array could be checked after completion for errors prior to committing changes. This allows progress of triggers to be timed out, but still have good communication back to the caller. IMHO, we need to support both. Actions like notification can be asynchronous while some others that need to be synchronous can be so. The program that registers the trigger would create it as a synchronous or asynchronous trigger. Some features that I think will be useful in this infrastructure layer (IMHO for a good UI/config system): 1. Commit and rollback of configuration commands. 2. Syntax verification and command completion. We can also conceive of the CLI being constructed and compiled into this DB. Syntax validation happens using this infrastructure. AFAIK, Zebra does the routing code CLI validation this way. In the Zebra code, we can load plug-ins for any module we want and only those commands are usable. This way, we can remove the need for bash shell for users and make the CLI shell as his UI. AFAIK, Zebra, suing this mechanism, filters options as the CLI is being entered apart from providing completion (hitting tab) and options (on hitting ?). 3. Use this DB infrastructure to maintain some key counters from the /proc interface to get a historical view. 4. Create a notification engine with API as part of the infrastructure that can be configured to use different notification mechanisms. Maybe syslog itself can be modified to handle this. Applications can use this API for notifications. 5. A well defined error reporting mechanism/ codification also part of the DB to make sense of error codes passed by called programs via triggers. 1. Much needed discussion 2. Very fancy and nice. Have thought of this often. Beyond my time constraints right now. 3. Great idea. See, folks already coming up with novel uses! 4. Trig should be able to be used for this, but perhaps you were thinking of something lighter. We should discuss in more depth what you want from this facility. 5. See above (cdb as message board) Hope I have been lucid enough. Crystal clear. --- 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
Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
I am not a fan. Space can be conserved with binary files, but editability is sacrificed. XML provides human(?) readibility/editability, but takes up lots of space. The filesystem as backing store has always seemed to me to be the best idea given the constraints. On Jul 5, 2004, at 9:51 PM, S Mohan wrote: Why not look at sleepycat DB? It has an XML DB option which will give us extensibility and also make it easy to interface to external systems. Config file can be in readable XML format also. IMHO a very attractive option. Warm regards Mohan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chad Carr Sent: Tuesday, July 06, 2004 6:04 AM To: [EMAIL PROTECTED] Subject: Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl) sqlite would certainly work, but the cdb utility would need to be rewritten in C or C++ and would no longer be hand editable. That is why the current version is written to use the filesystem as the backing store. In my mind, advanced users would be able to hand-tune the cdb repository, then hand-run the trigger scripts, thus saving them from the peril of using a graphical user interface. That is, of course, in my mind. On Jul 5, 2004, at 5:20 PM, Mike Noyes wrote: On Mon, 2004-07-05 at 16:14, Chad Carr wrote: 6) This data is inserted into cdb's backing store (whatever that happens to be!) Chad, Would SQLite work as cdb's backing store, or am I misunderstanding what a backing store is? SQLite http://www.sqlite.org/ -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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 --- 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 --- 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
