Re: [leaf-devel] Config system
Hi Guys At 10:01 06.02.2003 -0600, you wrote: On Wednesday 05 February 2003 03:36 pm, Charles Steinkuehler wrote: Duly noted. Where does the responsibility of the 'check' and 'restart' lie? This would seem to be the respnsibility of the back-end (save-script), on first glance. Would a "trigger" be a good method? Would a seperate db need to be made to keep track of "triggers" and the needed information? I'm assuming a dynamic db based on a list of used variables contained in the package itself. Thoughts? Wouldn't some kind of 'dirty' flag on a package be sufficient? Once you finish the configuration all packages with that flag could be restarted. . With some playing, I'm starting to agree with this to a point. A tree that contained '/path/variable/value' would be simple to set and change. However pairing the variable/value might not be too fun to use in the files that use this infomation. Considering this, if there was an added single db file that would concentrate the tree db information, there would be an option to easily find 'where' to change a value (by hand) and location to source for the run-time packages themselves. For a single key=value file there is one already in Bering and I believe in Dachstein too, lrp.conf , why not use it? It only contains parameters we need to use anyway. If a hierarchical setup is chosen the directory idea is simple and easy to parse, but more difficult for Joe Average to read and find things in. Just refer to the /proc directory structure. Another thought, maybe too late, I was wondering how a package like shorewall could take its parameters from a pure key=value db. The keys would have to be very elaborate then and such a set up might be more complicated to understand than the current one. Tom probably had good reasons to split his configuration files. 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 is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
AW: [leaf-devel] GRUB and LRP problem
> > One thing to note is that when I try the install GRUB from floppy, > > it fails to find (the optional?) fat_stage1_5 even though it's > located in > > /boot/grub/ on the FAT partition, because the file name is cut-off after > > the eigth character (is there a way around this BTW?). Has anybody used > > GRUB with a hard drive succesfully? Any help/info would be greatly > > appreciated. I'm booting with grub, but I'm using ext2 and reiserfs. I had quite some problems with smaller partitions (20MB) on a DoM with different filesystems. So far, ext2 was the only one I tried that worked. Though I might try FAT32, the Problem with FAT could indeed be the missing stage1_5 file. > There are people successfully booting LEAF with Grub and LiLO. > The DOS trunciation wouldn't happen if the /boot partition is compressed > in the initrd.lrp and/or root.lrp. I'm not aware of any of the > filesystem in > LEAF that isn't compressed in a *.lrp other than the kernel and syslinux. Grub doesn't see a compressed file system. It needs to read the /boot/grub/stage2, /boot/grub/menu.lst, /linux and /initrd.lrp files directly from a filesystem. It could, theoretically, read the stage1_5 files from somewhere else, as those are directly written to tracks on the HD/whatever. - Alex --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] module tarball for Bering-uClibc 1.1
Thank you Eric... On Fri, 07 Feb 2003 08:59:42 GMT Eric Spakman wrote: > > Does anyone have a module tarball available that is compatible > > with the stock Bering-uClibc 1.1 kernel? > Brad, > > I'm at work and using webmail, so I can't cc to the list. I am copying them back in to archive the URL. Hope that is okay. > The kernel and modules are uClibc independent, Right. > you can use the modules from Jacques for this. If you're using > the latest CVS 1.1 uClibc image I am. > you must use the new kernel modules, which can be found at: > http://leaf.sourceforge.net/devel/jnilo/bering/1.1/ Thank you! That was the link I was missing. --Brad > Eric --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Firewall builder
Hi all, Following the "Template system" -> "Config system" etc, has anybody seen this project (http://www.fwbuilder.org/index.html) for the GUI and config? Regards. -- Jaime Nebrera - [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Config system
On Thursday 06 February 2003 10:42 am, Charles Steinkuehler wrote: > Lynn Avants wrote: > > Let's say something like this: > > > > /db-tree/interfaces/eth1/ip_address (contains 192.168.1.254) > > > > /etc/db.cfg contains: > > PREFIX=/db-tree > > LAN_IP='cat /$PREFIX/interfaces/eth1/ip_address' > > > > Then the application uses: > > source /etc/db.cfg > > #Internal interface ip address to use > > $LAN_IP > > I'd like to see what Chad implemented, but off-hand, I think the above > would only be appropriate in an individual package's configuation script. I plan to go through that tomorrow morning (hopefully). I'm looking forward to it as well. ;-) > You're flattening the tree structure of the database (which IMHO exists > to contain important information). Whose to say you didn't really want: > LAN_IP=`cat /$PREFIX/interfaces/eth2/ip_address` > > I always figured the DB would contain some form of structure, and would > be accessed indirectly (ie via an API), something more like: > > LAN_IP=`getdbvalue interfaces.eth2.ip_address` > > Note that slashes, whitespace, colons, or pretty much whatever we decide > could seperate the "branches" of the db for quering. It probably also > wouldn't be terribly hard to setup some state information (maybe with > exported shell variables) so you could do something like: > > dbuse interfaces.eth2 > LAN_IP=`dbgetvalue ip_address` > LAN_MASK=`dbgetvalue netmask` > > Of course, this is all pretty speculative at this point. I personally > figured the package configuration scritps would be doing very little > actual talking to the db (mainly registering itself, and any templates > and package-specific db config variables used), and that the really > messy stuff would happen with the template files and a central > application that parsed them, filled in the dynamic information, and > wrote out the result (similar to how server-side-includes work for > webservers). I really don't think we're as far off in opinion as what it might appear. I also think I may have over simplified my snippet. From examining what Eric has posted, Eric and I are definately following the same path of thought. Eric and I are NOT proposing flattening the tree structure, but alloing for a inbetween layer that is actually interpretable by a human. Many humans have a need to fiddle w/o a API and want to find/fix possible bugs in a running configuration. The flat mid-layer allows for this to happen and also makes life simpler for packagers that may need the shared base information. You wouldn't want to make any changes in the flat file, you would want to take the literal path that the flat file contains to locate exactly _where_ a variable could be modified. This also saves on the dynamic nature and completeness of the documentation needed to grasp what is actually happening with the db. Possibly I am now rambling on about something that many feel is superficial, but with a strictly mandated API frontend, you might as well get rid of the editor on the disk. I would look far enough to figure out that everything is controlled by db-binary and look for something a little more adaptive to brute force changes if necessary. Per se, when Xdistro's propietary installer fsck's my setup for any reason (and I haven't met one that hasn't), I can manually fix the error. The suggested db doesn't leave much room for that. Someday XFree on Linux will figure out that a RIVA 128 won't work on a framebuffer correctly. When I can't fix that by hand, I'll likely be using FreeBSD on this desktop or something else a little more propietary. M$ protects the user from controlling much of their system. This is among one of many reasons many of us do not use their products. Please don't protect me from my own system. I regress. ;-) Thoughts? -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
AW: [leaf-devel] Firewall builder
> Following the "Template system" -> "Config system" etc, has > anybody seen > this project (http://www.fwbuilder.org/index.html) for the GUI and config? I have submitted an fwbuilder package (.lrp plus install script) For out firewalls, we ca change rules and have them installed via SSL with one click in the fwbuilder GUI Regards Alex --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Config system
On Fri, 2003-02-07 at 00:30, Erich Titl wrote: > Hi Guys > > At 10:01 06.02.2003 -0600, you wrote: > >On Wednesday 05 February 2003 03:36 pm, Charles Steinkuehler wrote: > > > > > >Duly noted. Where does the responsibility of the 'check' and 'restart' lie? > >This would seem to be the respnsibility of the back-end (save-script), on > >first glance. Would a "trigger" be a good method? Would a seperate db > >need to be made to keep track of "triggers" and the needed information? > >I'm assuming a dynamic db based on a list of used variables contained > >in the package itself. Thoughts? > > Wouldn't some kind of 'dirty' flag on a package be sufficient? Once you > finish the configuration all packages with that flag could be restarted. > > >. > >With some playing, I'm starting to agree with this to a point. A tree that > >contained '/path/variable/value' would be simple to set and change. > >However pairing the variable/value might not be too fun to use in > >the files that use this infomation. Considering this, if there was an > >added single db file that would concentrate the tree db information, > >there would be an option to easily find 'where' to change a value > >(by hand) and location to source for the run-time packages themselves. > > For a single key=value file there is one already in Bering and I believe in > Dachstein too, lrp.conf , why not use it? It only contains parameters we > need to use anyway. > If a hierarchical setup is chosen the directory idea is simple and easy to > parse, but more difficult for Joe Average to read and find things in. Just > refer to the /proc directory structure. The api makes the hierarchy "feel" like name=value pairs. The output from the api _is_ name value pairs; the input is sequential arguments that mimic name=value pairs. See the following transcript from my CVS code: [ccarr@ginger leaf-cdb]$ ./leaf-cdb get tree interfs default='eth0' eth0_ipaddr='172.24.8.24' eth0_netmask='255.255.252.0' eth0_gateway='172.24.8.1' eth1_ipaddr='192.168.2.10' eth1_netmask='255.255.255.0' eth1_gateway='192.168.2.1' [ccarr@ginger leaf-cdb]$ ./leaf-cdb get interfs/eth0/ipaddr interfs_eth0_ipaddr='172.24.8.24' [ccarr@ginger leaf-cdb]$ ./leaf-cdb get tree interfs/eth0 gateway='172.24.8.1' ipaddr='172.24.8.24' netmask='255.255.252.0' [ccarr@ginger leaf-cdb]$ ./leaf-cdb set tree interfs/eth0 broadcast 172.24.11.255 network 172.24.8.0 netbits 22 [ccarr@ginger leaf-cdb]$ ./leaf-cdb get tree interfs/eth0 broadcast='172.24.11.255' gateway='172.24.8.1' ipaddr='172.24.8.24' netbits='22' netmask='255.255.252.0' network='172.24.8.0' A properly designed api makes it easy to get and set "name=value pairs" without actually having them in the same file. The strength in this approach is that an individual package "owns" the data in the files that map to its name=value pairs, and can be responsible for backup them up, then putting the file back into place on the next boot. The file is "assembled" rather than edited. > Another thought, maybe too late, I was wondering how a package like > shorewall could take its parameters from a pure key=value db. The keys > would have to be very elaborate then and such a set up might be more > complicated to understand than the current one. Tom probably had good > reasons to split his configuration files. The interaction between the config-db and the trigger/templating system is a pure abstraction. The name=value pairs on the output of the api become the input (and symbol table) for the template. With a properly designed templating system _any_ type or number of files can be generated, data can be morphed or manipulated after it leaves the config-db (i.e. netmask could be transformed to netbits or vice-versa). The work flow is: - change the config-db using the api - fire a predefined (and documented) trigger saying you have done so Then the trigger "handlers" take over. Any package that is interested in the occurance of a certain trigger installs a handler (drops a script into the corresponding directory) to do what he needs to have done when that trigger is fired. The trigger mechanism is likely just debian run-parts or the like; very simple. The general workflow for a trigger handler: - read the config-db or portion of the config-db that he is interested in using the api - use that as a symbol table for any number of templating operations that he needs to execute to transform his operating files - atomically attempt to apply the changes, restart his service or daemon or otherwise put the new values into action - check to see if it worked - roll back to the old values if it didn't (this will take some additional work) Your example of shorewall is very apropos. Shorewall will need to know about nearly every networking change on the box, as well as changes to it's own configuration. If a new interface is added, it must regenerate its interfaces file and restart. If someone adds a rule, it must regenerate its rules or policy fi
Re: [leaf-devel] Config system
On Thu, 2003-02-06 at 22:01, Lynn Avants wrote: > Eric and I are NOT proposing flattening the tree structure, but alloing for > a inbetween layer that is actually interpretable by a human. Many humans > have a need to fiddle w/o a API and want to find/fix possible bugs in a > running configuration. The flat mid-layer allows for this to happen and also > makes life simpler for packagers that may need the shared base information. > You wouldn't want to make any changes in the flat file, you would want to > take the literal path that the flat file contains to locate exactly _where_ a > variable could be modified. This also saves on the dynamic nature and > completeness of the documentation needed to grasp what is actually happening > with the db. Documentation is important. It is important if we want things to be done right (not some nazi concept of "right," but right meaning "works all the time"). For a package maintainer to go into a shell fragment looking for a variable that has a current value that he thinks is associated with the operation he is executing is almost always the wrong move. Maybe it is the right variable; maybe not. Documentation tells. > Possibly I am now rambling on about something that many feel is superficial, > but with a strictly mandated API frontend, you might as well get rid of the > editor on the disk. I would look far enough to figure out that everything is > controlled by db-binary and look for something a little more adaptive to > brute force changes if necessary. Per se, when Xdistro's propietary installer > fsck's my setup for any reason (and I haven't met one that hasn't), I can > manually fix the error. The suggested db doesn't leave much room for that. > Someday XFree on Linux will figure out that a RIVA 128 won't work > on a framebuffer correctly. When I can't fix that by hand, I'll likely be > using FreeBSD on this desktop or something else a little more propietary. Actually, in this implementation, the config-db is quite easily manipulated by hand along the lines of qmail (my inspiration in form if not in license) # echo -n "172.24.8.24" > /leaf/cdb/interfs/eth0/ipaddr # /leaf/bin/leaf-trig ipchange eth0 Just as tweaker friendly. I wouldn't have it any other way. And frankly, using e3 in vi mode over even a 19200 serial console is not a dream. Especially on a 1000-line shell fragment. ;-) > M$ protects the user from controlling much of their system. This is among > one of many reasons many of us do not use their products. Please don't > protect me from my own system. I regress. ;-) I regret if I have done anything to imply that the config-db is off limits to users. I only meant to have it off limits to package maintainers, and even then only loosely off limits. During the backup and boot process packages are "allowed" (and even encouraged) to take control of their own config-db files. This fragmentation concept stems somewhat from my frustration in having to modify files in one package to affect the behavior of another. Of note is the addition of terminfo to etc.lrp to assist the installation of vim (to unhobble my serial boxes ;-)) Take a look at the code in cvs when you get a chance. I think that it will put your fears at bay. -- --- Chad Carr [EMAIL PROTECTED] --- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: AW: [leaf-devel] Firewall builder
On Fri, 2003-02-07 at 05:18, Alex Rhomberg wrote: > > Following the "Template system" -> "Config system" etc, has > > anybody seen > > this project (http://www.fwbuilder.org/index.html) for the GUI and config? > > I have submitted an fwbuilder package (.lrp plus install script) > > For out firewalls, we ca change rules and have them installed via SSL with > one click in the fwbuilder GUI Alex, Thanks for creating this package. What LEAF releases/branches did you test it with? https://sourceforge.net/tracker/?group_id=13751&atid=313751&func=detail&aid=657801 Did you also submit this package to the fwbuilder project? https://sourceforge.net/projects/fwbuilder/ -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Config system
On Friday 07 February 2003 07:23 am, Chad Carr wrote: > On Fri, 2003-02-07 at 00:30, Erich Titl wrote: > > For a single key=value file there is one already in Bering and I believe > > in Dachstein too, lrp.conf , why not use it? It only contains parameters > > we need to use anyway. > > If a hierarchical setup is chosen the directory idea is simple and easy > > to parse, but more difficult for Joe Average to read and find things in. > > Just refer to the /proc directory structure. This is my question as well with a different example, other than proc is quite well known and used among experienced users, where a leaf-db wouldn't be. > The api makes the hierarchy "feel" like name=value pairs. The output > from the api _is_ name value pairs; the input is sequential arguments > that mimic name=value pairs. See the following transcript from my CVS > code: > > [ccarr@ginger leaf-cdb]$ ./leaf-cdb get tree interfs > default='eth0' > eth0_ipaddr='172.24.8.24' > eth0_netmask='255.255.252.0' > eth0_gateway='172.24.8.1' > eth1_ipaddr='192.168.2.10' > eth1_netmask='255.255.255.0' > eth1_gateway='192.168.2.1' > [ccarr@ginger leaf-cdb]$ ./leaf-cdb get interfs/eth0/ipaddr > interfs_eth0_ipaddr='172.24.8.24' > [ccarr@ginger leaf-cdb]$ ./leaf-cdb get tree interfs/eth0 > gateway='172.24.8.1' > ipaddr='172.24.8.24' > netmask='255.255.252.0' > [ccarr@ginger leaf-cdb]$ ./leaf-cdb set tree interfs/eth0 broadcast > 172.24.11.255 network 172.24.8.0 netbits 22 > [ccarr@ginger leaf-cdb]$ ./leaf-cdb get tree interfs/eth0 > broadcast='172.24.11.255' > gateway='172.24.8.1' > ipaddr='172.24.8.24' > netbits='22' > netmask='255.255.252.0' > network='172.24.8.0' Now I'm going through this right now (as promised) and it is quite an intriguing proposal. It stills somewhat avoids the question I am asking though. When you first tried LEAF and possibly found you *wanted* or *needed* to manually change an option, you used tools you were familiar with or well documented via Google/whatever. Absoluely no one is going to have a clue to use './leaf-cdb set tree X' or './leaf-cdb get tree X' unless this is clearly explained before downloading an image/package and documented when logging on for the first-time. David D did an excellent job of doing exactly this on the later releases of Oxygen. I'm definately not attempting to say _not_ to use this style of db, but rather attempting to explain what short-comings that I see in the implementation. Two-line explanation: A flat-db is easily traceable and intuitive to somewhat experienced *NIX users, a tree db is not easily either. For concession, use of a tree db will _mandate_ clear, complete, and advertised documentation for all users, developers, and package maintainers. > A properly designed api makes it easy to get and set "name=value pairs" > without actually having them in the same file. The strength in this > approach is that an individual package "owns" the data in the files that > map to its name=value pairs, and can be responsible for backup them up, > then putting the file back into place on the next boot. The file is > "assembled" rather than edited. Who owns shared information between packages? There are several people that have already hacked single file and/or single package configuration. If the package 'owns' and 'stores' it's own db values, how is replacing something like a dhcp client going to 'drag-n-drop' w/o requiring it to set/ configure itself. With the information stored in an configuration file/package, you could reasonably assume that the same variables/values are universally used between the similar programs. > > Another thought, maybe too late, I was wondering how a package like > > shorewall could take its parameters from a pure key=value db. The keys > > would have to be very elaborate then and such a set up might be more > > complicated to understand than the current one. Tom probably had good > > reasons to split his configuration files. > > The interaction between the config-db and the trigger/templating system > is a pure abstraction. The name=value pairs on the output of the api > become the input (and symbol table) for the template. With a properly > designed templating system _any_ type or number of files can be > generated, data can be morphed or manipulated after it leaves the > config-db (i.e. netmask could be transformed to netbits or vice-versa). > The work flow is: > > - change the config-db using the api > - fire a predefined (and documented) trigger saying you have done so > > Then the trigger "handlers" take over. Any package that is interested > in the occurance of a certain trigger installs a handler (drops a script > into the corresponding directory) to do what he needs to have done when > that trigger is fired. The trigger mechanism is likely just debian > run-parts or the like; very simple. The general workflow for a trigger > handler: > > - read the config-db or portion of the config-db that he is interested > in using the api
AW: AW: [leaf-devel] Firewall builder
> Thanks for creating this package. What LEAF releases/branches did you > test it with? Good Question. I tested und used it only with Bering. In any case, a 2.4 kernel is required, as fwbuilder doesn't support ipchains >Did you also submit this package to the fwbuilder project? > https://sourceforge.net/projects/fwbuilder/ We will. Good idea Cheers Alex --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] [ leaf-Patches-682300 ] LEAF construction kit
Patches item #682300, was opened at 2003-02-07 14:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=313751&aid=682300&group_id=13751 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Rhomberg (alexrh) Assigned to: Nobody/Anonymous (nobody) Summary: LEAF construction kit Initial Comment: Helper scripts for pre-configuring LEAF firewalls - Unpack Floppy binaries and packages - Create configured or new packages - Handle multiple firewalls - Find differences between packages -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=313751&aid=682300&group_id=13751 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] [ leaf-Patches-682313 ] LEAF construction kit
Patches item #682313, was opened at 2003-02-07 14:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=313751&aid=682313&group_id=13751 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alex Rhomberg (alexrh) Assigned to: Nobody/Anonymous (nobody) Summary: LEAF construction kit Initial Comment: Helper scripts for pre-configuring LEAF firewalls - Unpack Floppy binaries and packages - Create configured or new packages - Handle multiple firewalls - Find differences between packages -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=313751&aid=682313&group_id=13751 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] GRUB and LRP problem
On Thu, Feb 06, 2003 at 10:37:48PM -0600, Spiro Philopoulos said: > BTW, thanks to Simon Blake for his GRUB mini-howto. You're most welcome. > Procedure used for GRUB (in case it's useful for solving the problem): > > - Partition the HD. 100MB FAT16 partition is first partition on the drive. > - Format the partitions. > - Install an MBR using 'fdisk /MBR' from DOS boot disk (GRUB wouldn't work > otherwise) Hmm. I've never had to do this - grub installs fine for me on compact flash drives, without needing to fdisk on an MBR first. > - Install GRUB stage binary images in /boot/grub/ on FAT partition, & edit > menu.lst. > - Install GRUB using the GRUB boot floppy: >root (hd0,0) >setup (hd0) This sounds to me like you might have LBA/CHS dive geometry problems. How big is the actual hard drive? A procedure I've found works pretty well for me is: Configure your target disk as primary master Configure another HD with the master LRP files as secondary master, booting into DOS. Have a Grub floppy available. Configure the BIOS of the machine to boot floppy->hdd0->hdd1 Leave the floppy out, assuming there's no boot sector on the new disk, it'll boot dos off your master disk, and it will become C: in DOS. if the new disk needs FDISKing, then do so (generally compact flash comes with a dos file system, so I don't bother), reboot, run format /s /u on the new D: drive. Copy LRP files across, copy menu.lst, stage1 and stage2 to D:\grub. You don't need stage1_5 (or at least, I've never used it). stick in the floppy, reboot off it, run the grub installer as above. This seems to work well for me because lots of bios's seem to setup the primary master differently from the secondary master - presumably because it expects to have to boot off the primary master. So muck around with your LBA settings in your BIOS, and see if that helps. YMMV, of course :-) Cheers Si --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] LEAF helper scripts: Please comment
I have written some scripts for creating pre-configured Bering packages and firewalls. I hope they are of use to other people as well. I would like to hear suggestions and bug reports, especially for LEAF Distributions other than Bering. I wrote and tested the scripts only with Bering. Find the tarball here: https://sourceforge.net/tracker/download.php?group_id=13751&atid=313751&file_id=41767&aid=682300 Cheers Alex PS: I apologise for the first two tries with non-text mails --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] SF CVS Site Docs
Everyone, The SF staff updated the CVS documentation. Please review it. Thanks. F1. Basic Introduction to CVS and SourceForge.net Project CVS Services https://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1 F2. Introduction to SourceForge.net Project CVS Services for Developers https://sourceforge.net/docman/display_doc.php?docid=768&group_id=1 F3. Project CVS: Using syncmail to Track CVS Commits https://sourceforge.net/docman/display_doc.php?docid=772&group_id=1 F4. CVS client installation: WinCvs with PuTTY on 32-bit Microsoft Windows platforms https://sourceforge.net/docman/display_doc.php?docid=766&group_id=1 Information on accessing SF cvs from behind a corporate firewall is in F1 section #firewall. In addition remember Charles is providing a copy of our repository that you can rsync from. [Leaf-devel] CVS Mirror resource http://www.mail-archive.com/leaf-devel@lists.sourceforge.net/msg05502.html -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SF CVS Site Docs
Everyone, I forgot to mention this. Please use the "doc feedback" links if you encounter a problem with the text. Thanks. On Fri, 2003-02-07 at 11:37, Mike Noyes wrote: > F1. Basic Introduction to CVS and SourceForge.net Project CVS Services > https://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1 > > F2. Introduction to SourceForge.net Project CVS Services for Developers > https://sourceforge.net/docman/display_doc.php?docid=768&group_id=1 > > F3. Project CVS: Using syncmail to Track CVS Commits > https://sourceforge.net/docman/display_doc.php?docid=772&group_id=1 > > F4. CVS client installation: WinCvs with PuTTY on 32-bit Microsoft > Windows platforms > https://sourceforge.net/docman/display_doc.php?docid=766&group_id=1 -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] The ideas presented so far...
On Sun, 2003-02-02 at 18:11, Matt Schalit wrote: > CONFIG-DB PROPOSALS > 1. flat-db > 2. api-flat-db > 3. api-xml-db > 4. api-binary-db > 5. template-api-xml-db Everyone, The proposals by Chad and Eric are now in CVS. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/ccarr/devel/leaf-cdb/ http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/ericw/configuration/leaf/test/ -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SF CVS Site Docs
On Fri, 2003-02-07 at 11:37, Mike Noyes wrote: > F1. Basic Introduction to CVS and SourceForge.net Project CVS Services > https://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1 > > F4. CVS client installation: WinCvs with PuTTY on 32-bit Microsoft > Windows platforms > https://sourceforge.net/docman/display_doc.php?docid=766&group_id=1 WinCVS users, Please take note of the link to the "WinCvs Daily Use Guide". http://cvsgui.sourceforge.net/howto/index.html -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Config system
Lynn Avants wrote: On Friday 07 February 2003 07:23 am, Chad Carr wrote: The api makes the hierarchy "feel" like name=value pairs. The output from the api _is_ name value pairs; the input is sequential arguments that mimic name=value pairs. See the following transcript from my CVS code: [ccarr@ginger leaf-cdb]$ ./leaf-cdb get tree interfs default='eth0' eth0_ipaddr='172.24.8.24' eth0_netmask='255.255.252.0' eth0_gateway='172.24.8.1' Very nice structure and output, Chad. Thanks for taking the time to work on this. A properly designed api makes it easy to get and set "name=value pairs" without actually having them in the same file. The strength in this approach is that an individual package "owns" the data in the files that map to its name=value pairs, and can be responsible for backup them up, then putting the file back into place on the next boot. The file is "assembled" rather than edited. Who owns shared information between packages? There are several people that have already hacked single file and/or single package configuration. If the package 'owns' and 'stores' it's own db values, how is replacing something like a dhcp client going to 'drag-n-drop' w/o requiring it to set/ configure itself. With the information stored in an configuration file/package, you could reasonably assume that the same variables/values are universally used between the similar programs. Another thought, maybe too late, I was wondering how a package like shorewall could take its parameters from a pure key=value db. The keys would have to be very elaborate then and such a set up might be more complicated to understand than the current one. Tom probably had good reasons to split his configuration files. The interaction between the config-db and the trigger/templating system is a pure abstraction. The name=value pairs on the output of the api become the input (and symbol table) for the template. With a properly designed templating system _any_ type or number of files can be generated, data can be morphed or manipulated after it leaves the config-db (i.e. netmask could be transformed to netbits or vice-versa). The work flow is: So all the complex coding is in the template that comes customized with a package? Is that system that has to know all the different brg commands for bridge.lrp for instance, so that it can make the correct bridge.conf type of files and issue the correct "ip route ..." commands and the like? You touched on the reason why this is so important to figure out in advance, down below Your example of shorewall is very apropos. Shorewall will need to know about nearly every networking change on the box, as well as changes to it's own configuration. If a new interface is added, it must regenerate its interfaces file and restart. If someone adds a rule, it must regenerate its rules or policy files. So it regenerates it's interface file, but what default rules or policies does it apply to that interface? Does it NAT it? How does it know you're not intending to bridge or traffic shape? The complexity of this is staggering. It is up to the package itself (or the folks who are trying to integrate it with the web interface, I suppose) to interpret the event and make the necessary changes to the configuration files. The reason this must be is that if a web interface knows the results of its actions, it must necessarily be bound to the implementation, _inextricably_. Then if someone comes along and creates a fancy new way to configure interfaces at boot time or a new, even tinier dhcp server, the web interface would have to know about it to get it configured. This is bad. I think. Bingo. I was thrashing around this problem myself. If I were making a GUI front-end configuration/admin program, I'd have to hard code in every variable that a package uses and make the drop-down list of possible choices and all that in advance. If a package changes, I have to change the front-end. Yikes. Not only that, but I'd have to know how to issue the necessary commands to configure every conceivable type of network hardware setup. That's impossible. So how can we make a front-end that reads a package and creates all the variable fields and choices dynamically? Does every package need a manifest of all possible variables and commands? Is that possible? If it's not possible, where do we draw the line and say that any more advanced config has to be done by hand? Ok, so now we're suggesting making the packages smarter. This follows the logic since only the package can assume its use. It's a big step moving responsibility from the front-end, back-end, and db-system to individual packages. Logical or not, is this what we want to propose I'm not sure we could put the responsibility anywhere *but* into the package, Lynn. When you sit down to ponder making the front-end GUI, you realize that it has to be future maintainable so that Joe Developer can drop
Re: [leaf-devel] Config system
On Fri, 2003-02-07 at 08:06, Lynn Avants wrote: > On Friday 07 February 2003 07:23 am, Chad Carr wrote: > > On Fri, 2003-02-07 at 00:30, Erich Titl wrote: > > > > For a single key=value file there is one already in Bering and I believe > > > in Dachstein too, lrp.conf , why not use it? It only contains parameters > > > we need to use anyway. > > > If a hierarchical setup is chosen the directory idea is simple and easy > > > to parse, but more difficult for Joe Average to read and find things in. > > > Just refer to the /proc directory structure. > > This is my question as well with a different example, other than proc > is quite well known and used among experienced users, where a > leaf-db wouldn't be. I see your point here. I am assuming that Joe Average's interface of choice is the web interface. If Joe wants to move beyond the capabilities granted by the web interface, we would have a first-tier document for him to read that explains the tight set of tools used and the layout of the hierarchy. > Now I'm going through this right now (as promised) and it is quite an > intriguing proposal. It stills somewhat avoids the question I am asking > though. When you first tried LEAF and possibly found you *wanted* or > *needed* to manually change an option, you used tools you were familiar > with or well documented via Google/whatever. Absoluely no one is going > to have a clue to use './leaf-cdb set tree X' or './leaf-cdb get tree X' > unless this is clearly explained before downloading an image/package and > documented when logging on for the first-time. David D did an excellent job > of doing exactly this on the later releases of Oxygen. I'm definately not > attempting to say _not_ to use this style of db, but rather attempting to > explain what short-comings that I see in the implementation. Again, I believe that the system should be designed so that Joe Average doesn't ever log in. If he chooses to go beyond, the doc picks up. > Two-line explanation: A flat-db is easily traceable and intuitive to somewhat > experienced *NIX users, a tree db is not easily either. For concession, use > of a tree db will _mandate_ clear, complete, and advertised documentation > for all users, developers, and package maintainers. Yes. I think that is a desire of this new sub-project. It does cut down on freedom and make the development of packages more difficult, but the development only needs to be done once (and whenever the configuration file format changes) and by the guy who knows best what should happen (the package maintainer). The benefit of getting a pluggable web configuration interface seems to me to outweigh the difficulty. > > A properly designed api makes it easy to get and set "name=value pairs" > > without actually having them in the same file. The strength in this > > approach is that an individual package "owns" the data in the files that > > map to its name=value pairs, and can be responsible for backup them up, > > then putting the file back into place on the next boot. The file is > > "assembled" rather than edited. > > Who owns shared information between packages? There are several people > that have already hacked single file and/or single package configuration. > If the package 'owns' and 'stores' it's own db values, how is replacing > something like a dhcp client going to 'drag-n-drop' w/o requiring it to set/ > configure itself. With the information stored in an configuration > file/package, you could reasonably assume that the same variables/values > are universally used between the similar programs. The system probably owns the core configuration data. Data that is shared (for example) between initrd.lrp, root.lrp, etc.lrp, modules.lrp could be owned by leaf.lrp (this is the core set of packages under Bering that it is basically impossible to run a system without). All other data may be owned by its respective package but can possibly be pushed into leaf.lrp if the package doesn't claim it. I suppose it doesn't matter technically who owns it as long as the package is not trying to be transported _after_ being backed up. > > > Another thought, maybe too late, I was wondering how a package like > > > shorewall could take its parameters from a pure key=value db. The keys > > > would have to be very elaborate then and such a set up might be more > > > complicated to understand than the current one. Tom probably had good > > > reasons to split his configuration files. > > > > The interaction between the config-db and the trigger/templating system > > is a pure abstraction. The name=value pairs on the output of the api > > become the input (and symbol table) for the template. With a properly > > designed templating system _any_ type or number of files can be > > generated, data can be morphed or manipulated after it leaves the > > config-db (i.e. netmask could be transformed to netbits or vice-versa). > > The work flow is: > > > > - change the config-db using the api > > - fir
Re: [leaf-devel] Config system
On Fri, 2003-02-07 at 14:15, Matt Schalit wrote: > > Lynn Avants wrote: > > On Friday 07 February 2003 07:23 am, Chad Carr wrote: > > >>The api makes the hierarchy "feel" like name=value pairs. The output > >>from the api _is_ name value pairs; the input is sequential arguments > >>that mimic name=value pairs. See the following transcript from my CVS > >>code: > >> > >>[ccarr@ginger leaf-cdb]$ ./leaf-cdb get tree interfs > >>default='eth0' > >>eth0_ipaddr='172.24.8.24' > >>eth0_netmask='255.255.252.0' > >>eth0_gateway='172.24.8.1' > > Very nice structure and output, Chad. Thanks for taking the > time to work on this. No problem. This is truly the next phase of leaf. I am glad to be a part. > >>The interaction between the config-db and the trigger/templating system > >>is a pure abstraction. The name=value pairs on the output of the api > >>become the input (and symbol table) for the template. With a properly > >>designed templating system _any_ type or number of files can be > >>generated, data can be morphed or manipulated after it leaves the > >>config-db (i.e. netmask could be transformed to netbits or vice-versa). > >>The work flow is: > > So all the complex coding is in the template that comes > customized with a package? Is that system that has to > know all the different brg commands for bridge.lrp for instance, > so that it can make the correct bridge.conf type of files and > issue the correct "ip route ..." commands and the like? > > > You touched on the reason why this is so important > to figure out in advance, down below Even the init script for a package may be templatized, if it relies heavily on command line parameters and conditional setup behavior. _Any_ file on the system that is required for functionality of the package may be customized. > >>Your example of shorewall is very apropos. Shorewall will need to know > >>about nearly every networking change on the box, as well as changes to > >>it's own configuration. If a new interface is added, it must regenerate > >>its interfaces file and restart. If someone adds a rule, it must > >>regenerate its rules or policy files. > > > So it regenerates it's interface file, but what default rules or > policies does it apply to that interface? Does it NAT it? How > does it know you're not intending to bridge or traffic shape? > The complexity of this is staggering. This is a different problem. It is up to the package maintainer to decide what people can and cannot configure via the web interface (and when I say web interface, I really mean non-editor interface, since other types of interfaces including SNMP may easily be built on top of this system). This is just like his decision to grant editor access to certain files through the lrcfg menu, just a little more advanced. > >>It is up to the package itself (or the folks who are trying to integrate > >>it with the web interface, I suppose) to interpret the event and make > >>the necessary changes to the configuration files. > >> > >>The reason this must be is that if a web interface knows the results of > >>its actions, it must necessarily be bound to the implementation, > >>_inextricably_. Then if someone comes along and creates a fancy new way > >>to configure interfaces at boot time or a new, even tinier dhcp server, > >>the web interface would have to know about it to get it configured. > >>This is bad. I think. > > Bingo. I was thrashing around this problem myself. > If I were making a GUI front-end configuration/admin program, > I'd have to hard code in every variable that a package uses > and make the drop-down list of possible choices and all that > in advance. If a package changes, I have to change the front-end. > Yikes. > > Not only that, but I'd have to know how to issue the necessary > commands to configure every conceivable type of network hardware > setup. That's impossible. Yes. Bingo. > So how can we make a front-end that reads a package and creates > all the variable fields and choices dynamically? Again, a different problem. It is possible to create a _very_ dynamic web interface using a drop-in methodology and templating similar to what I am proposing, but we really need the infrastructure first. The same tools could be used. > Does every package need a manifest of all possible variables > and commands? Is that possible? Yes. For _complete_ configuration yes. Is it possible: not for shorewall ;-). But not really required for a web interface. Our competition on this front is linksys, dlink, microsoft, netgear, toshiba?, cobalt? You don't have to expose all the beautiful workings to the world. Just the most common. Advanced configuration has been and always will be by hand. When competing against cisco you need cli and snmp; for the rest you need web. > If it's not possible, where do we draw the line and say > that any more advanced config has to be done by hand? The package maintainer does this. He is the only one who can
Re: [leaf-devel] GRUB and LRP problem
Thanks for the help. I'd just like to let anyone that's interested know that GRUB works fine off a hard drive FAT16 partition. It didn't work initially due to an embarrassing blunder of mine. I didn't set the RAMDISK size in menu.lst correctly :-) On Friday 07 February 2003 05:06, Simon Blake wrote: > On Thu, Feb 06, 2003 at 10:37:48PM -0600, Spiro Philopoulos said: > > BTW, thanks to Simon Blake for his GRUB mini-howto. > > You're most welcome. > > > Procedure used for GRUB (in case it's useful for solving the problem): > > > > - Partition the HD. 100MB FAT16 partition is first partition on the > > drive. - Format the partitions. > > - Install an MBR using 'fdisk /MBR' from DOS boot disk (GRUB wouldn't > > work otherwise) > > Hmm. I've never had to do this - grub installs fine for me on compact > flash drives, without needing to fdisk on an MBR first. > > > - Install GRUB stage binary images in /boot/grub/ on FAT partition, & > > edit menu.lst. > > - Install GRUB using the GRUB boot floppy: > >root (hd0,0) > >setup (hd0) > > This sounds to me like you might have LBA/CHS dive geometry problems. > How big is the actual hard drive? A procedure I've found works pretty > well for me is: > > Configure your target disk as primary master > > Configure another HD with the master LRP files as secondary master, > booting into DOS. > > Have a Grub floppy available. > > Configure the BIOS of the machine to boot floppy->hdd0->hdd1 > > Leave the floppy out, assuming there's no boot sector on the new disk, > it'll boot dos off your master disk, and it will become C: in DOS. > > if the new disk needs FDISKing, then do so (generally compact flash > comes with a dos file system, so I don't bother), reboot, run > > format /s /u > > on the new D: drive. Copy LRP files across, copy menu.lst, stage1 and > stage2 to D:\grub. You don't need stage1_5 (or at least, I've never > used it). > > stick in the floppy, reboot off it, run the grub installer as above. > > This seems to work well for me because lots of bios's seem to setup the > primary master differently from the secondary master - presumably > because it expects to have to boot off the primary master. So muck > around with your LBA settings in your BIOS, and see if that helps. > > YMMV, of course :-) > > Cheers > Si --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Will be out of town till Feb 14, 2003
--- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
