Re: [Leaf-devel] A new look on LEAF components
On 2/3/02 at 11:51 PM, Matt Schalit [EMAIL PROTECTED] wrote: Serge Caron wrote: I have experimented at length with both Dachstein and Shorewall to make sure that this implementation did not impact either project in any way. It has been my experience that lrp files are communicating vases and, in fact, each of these project ends up with exactly the same files packaged a different way. Dachstein is a distribution based on LRP and Eigerstein, etc. Shorewall is a firewall. It's a shame that you didn't try Oxygen 1.8.0. You would have found quite a few differences that were not in the packaging. Matt's quite right; Oxygen is probably the furthest away from its LRP base. Some quick examples of the most dramatic changes (as defined by current development): * POSIXness does not exist * Busybox is statically linked and is now at about 300k (170k dynamically linked?) and contains 77 apps or so * Kernel patches unique to LRP no longer needed * Use of /etc/rc.config.d (like HP-UX) for configuration of startup processes It will be interesting to see the impact of moving away from glibc 2.0.7 will have on the LEAF project. Oxygen has been using 2.1.3 for over half a year. Also, Oxygen uses libc.lrp - if you have the space on disk, just replace a 2.1.3 glibc with a 2.2 glibc in a libc.lrp and go. I'm not sure I understand how your project is supposed to work. -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] weblet the like
Lynn wrote regarding the Mosquito distribution: I have been busy looking at some CGI options myself lately. :) soapboxPersonally, I think there's something fundamentally wrong with managing a firewall/router through a web-based interface, but it seems that I'm the only one who feels this way.../soapbox I've been working on and off on integrating lua into a web server to provide an inline embedded scripting language, similar to PHP. For example: TITLEConfiguration page for ? readfrom(|/bin/hostname) x=read(*a) hostname=strsub(x,0,(strlen(x)-1)) x=nil write (hostname) ?/TITLE ... H1Configuration page for ? write(hostname) ?/H1 The above generates a web page that knows the local hostname... you get the idea (I hope.) I got micro_httpd working, but it only supports GET requests, so I switched to working with mini_httpd. GET requests work, but I'm still working on the correct approach for POSTS... Advantages I see to this approach are: Let the web server handle the access control, logging, etc. (better security) web pages should be more portable across the LEAF distributions mini_httpd can be built with SSL support, if desired inline-scripting is cool Disadvantages mainly involve size: The statically-linked lua library adds 50-70K to the web server code; lua-enabled mini_httpd is just under 100K in size. (UPX gets it to less than half of that, though). Does anyone out there see a need/use for this kind of thing? Or do you think the standard CGI scripting is fine? (I do realize you can fit alot of weblet pages in 100K) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] weblet the like
On Monday 04 February 2002 08:21, Angelacos, Nathan wrote: Lynn wrote regarding the Mosquito distribution: I have been busy looking at some CGI options myself lately. :) soapboxPersonally, I think there's something fundamentally wrong with managing a firewall/router through a web-based interface, but it seems that I'm the only one who feels this way.../soapbox Nope, your not alone. _Many_ of us feel exactly that way, but may don't and this limits the user base. If this config weblet is loaded as a package, you are only as unhappy as you make yourself :) I've been working on and off on integrating lua into a web server to provide an inline embedded scripting language, similar to PHP. For example: The above generates a web page that knows the local hostname... you get the idea (I hope.) I got micro_httpd working, but it only supports GET requests, so I switched to working with mini_httpd. GET requests work, but I'm still working on the correct approach for POSTS... Kewl, it would need to POST, but the size (on a floppy) is the problem as you mentioned. Advantages I see to this approach are: Let the web server handle the access control, logging, etc. (better security) web pages should be more portable across the LEAF distributions mini_httpd can be built with SSL support, if desired inline-scripting is cool Disadvantages mainly involve size: The statically-linked lua library adds 50-70K to the web server code; lua-enabled mini_httpd is just under 100K in size. (UPX gets it to less than half of that, though). Does anyone out there see a need/use for this kind of thing? Or do you think the standard CGI scripting is fine? (I do realize you can fit alot of weblet pages in 100K) I would agree with everything there, but I feel that the standard CGI is fine _on_ the distribution. SSL will be absolutely necessary for anything run externally, which brings us back to the chicken-n-egg question is sh-httpd configurable for SSL ? -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Where's Charles?
If anyone noticed, I've been offline since Thursday afternoon, when TransEdge decided to shut off my network connectivity (apparently the company I work for hasn't paid them for several months). Saddly, I was out of town and couldn't do anything about it, plus it was the weekend before I verified the outage wasn't due to the massive ice-storm we had here in the midwest last week. The outage caused my personal steinkuehler.net domain, including my LEAF web-site and e-mail services to completely disappear from the 'net, as well as wreking havoc on the corporate round-robin load-sharing web server setup (why I get a reasonably fast connection in the first place). Things are back online now, but I'm not sure for how long. There may be spot outages until everything gets straightened out (and my ISP acutally gets paid), so if you can't see lrp.steinkuehler.net, assume I'm offline :( I'll be filtering through back e-mails as they come in...I've got about 300 so far (only about 130 LEAF based)... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) OffTopic I have a variety of problems with the company I work for (not just the delay in paying bills, which is being driven by lackluster sales and too many expenses). In the very near future, I may be seeking other employment, probably consulting/contracting (hardware and/or software development). This could be a boon to my LEAF development, as one of the projects under consideration is an embedded linux based data-logger, likely with a PowerPC or ARM chip. If I wind up doing this, I'll probably be able to dedicate much more time to LEAF, as I hope to be able to use LEAF as a base. /OT ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Where's Charles?
On Monday 04 February 2002 12:18, Charles Steinkuehler wrote: Saddly, I was out of town and couldn't do anything about it, plus it was the weekend before I verified the outage wasn't due to the massive ice-storm we had here in the midwest last week. I figured that the ice had some fun with you ... the cable ISP a litlle further south survived the storm much nicer. I hope you can atleast keep your electricity on! OffTopic In the very near future, I may be seeking other employment, probably consulting/contracting (hardware and/or software development). This could be a boon to my LEAF development, as one of the projects under consideration is an embedded linux based data-logger, likely with a PowerPC or ARM chip. That would be nice :). There's a ton of HP-UX jobs in KC, of which I've never been priviledged enough to check out. Hope you find something you enjoy! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] weblet the like
I would agree with everything there, but I feel that the standard CGI is fine _on_ the distribution. SSL will be absolutely necessary for anything run externally, which brings us back to the chicken-n-egg question is sh-httpd configurable for SSL ? If you've got the space, sh-httpd (or pretty much *ANY* inted launched service, web-server or otherwise) should be able to run via SSL using the wrapper programs provided with OpenSSL. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] dachstein CD - backup dest
I studied why Charles coded this the way it is and decided that this simple rc script is probably the best way. Since the current mechanism bases the backup destination on whence the package last came -- this is a good thing -- I don't see an easy fix. Without some manual configuration, how will the system know -- at startup -- where you prefer to backup packages? Of course, it is possible that the post-startup backup process can test backup destinations for write-ability. Is this complication really warranted? snip I wonder what Charles has up his sleeve? You pegged why the existing system currently works the way it does. The best I've come up with for changing it is a slight modification of your recommendation, above. The initrd script would look at where the package was last loaded from (ie the existing default backup path). If that location was *NOT* writable, the package path would be traversed to find the first writable location, which would be used as the default backup path. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Backups to Floppy
I'm not sure how this relates to Dachstein, but I thought I'd propose it. Using /dev/backup and checking free space would be a GOOD addition to Dachstein, I think... Checking available freespace is definately a good thing! The only issue I have with using a /dev/backup link is the implicit assumption that there is only *one* backup location, when there may be several. Other than dual-disk floppy systems, and systems with both a HDD and a floppy, I've yet to actually create such an environment, but I've tried to keep the possibility open (it's always hard to imagine exactly how systems get used in the field). IIRC, there are various packaging and configuration differneces that may make a single backup location for Oxygen more appropriate than for Dachstein (or at least for the current Dachstein packaging scripts)... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] 2 useful comments from Matt and Dave
I find the following comments useful: Message: 9 Date: Sun, 03 Feb 2002 23:51:01 -0800 From: Matt Schalit [EMAIL PROTECTED] Subject: Re: [Leaf-devel] A new look on LEAF components To: [EMAIL PROTECTED] [snip] Are all LEAF's now and in the future packet filters? Message: 10 Date: Mon, 4 Feb 2002 06:32:53 -0600 From: David Douthitt [EMAIL PROTECTED] Subject: Re: [Leaf-devel] A new look on LEAF components To: LEAF Development [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] [snip] It's a shame that you didn't try Oxygen 1.8.0. You would have found quite a few differences that were not in the packaging. Matt's quite right; Oxygen is probably the furthest away from its LRP base. Some quick examples of the most dramatic changes (as defined by current development): [snip] I'm not sure I understand how your project is supposed to work. -- Without presuming on what I did (or did not) try, the concept of an enclosure does not favor any particular design, developer choice, or look and feel. What it does promote is a facility for moving from environment A to environment B, be it Oxygen or Dachstein or whatever. You are quick in making a distinction between Dachstein and Shorewall, the later being a commodity in the context of your sentence, if I understand correctly. There is no guarantee to Joe User that happens to like Shorewall enough to build on it for his own needs that he will be able to move his stuff to a cool new environment like Oxygen. On the other hand, the ordinary sysadmin that can write a script without feeling the urgency to rewrite the entire LEAF effort will find the concept of an enclosure usefull. After all, HER stuff is protected and she is one quick cp -a root.lrp ... away from moving to something else. Further, you can replace the ENTIRE set of files in the enclosure without loosing the base concept. Finally, it does promote some social responsibility. If LEAF provide a package repository, it creates a pull effect, that is a center of attention were everybody can go to find something. If it also provides reference kits (bootdisk, kernels, modules, whatever) it suddently has a broad offering as well as sharing the experience of working with these different environment, be it glibc 2.1.x or MacIntosh processors. If Charles, Jacques, or David create a distribution, it creates a push effort that lacks the LEAF project synergy. I believe there is room in this project for people who will take a base kit and come up with something that has nothing to do with the LEAF internals. Maybe Lynn has a redundant router project to share or somebody else has Dead Gateway Detection. There is no easy way for them to create this appliance unless they conquer the difficulty of providing their own boot disk, startup code and the like. In contrast, the person making a nmap.lrp package, for example, has a rather simple and well defined task. I do hope that somebody will provide alternate enclosures. That is the purpose of the effort. Better libraries, better menus, better support for typical embedded devices like flash disks, etc. Not only do I agree that POSIXness and silly kernel patches must go, I expect people creating enclosures to document each aspect of building of boot image in the comfort of their user's computer. This is Linux and people are also expected to work from source. PacketFilter is just a network setup script designed to drop IP traffic. Yet it is usefull enough to build a small workstation, an unforeseen benefit. As I plainy wrote in the documentation: I do not intend to maintain an LRP distribution just for the purpose of providing an environment in which to run PacketFilter. I believe this is clear enough. I am sure other people with something worthwhile to contribute will appreciate the support of the LEAF project. Let's make it easy for them to do so. Regards Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] dachstein CD - backup dest
Charles Steinkuehler wrote: I studied why Charles coded this the way it is and decided that this simple rc script is probably the best way. Since the current mechanism bases the backup destination on whence the package last came -- this is a good thing -- I don't see an easy fix. Without some manual configuration, how will the system know -- at startup -- where you prefer to backup packages? Of course, it is possible that the post-startup backup process can test backup destinations for write-ability. Is this complication really warranted? snip I wonder what Charles has up his sleeve? You pegged why the existing system currently works the way it does. The best I've come up with for changing it is a slight modification of your recommendation, above. The initrd script would look at where the package was last loaded from (ie the existing default backup path). If that location was *NOT* writable, the package path would be traversed to find the first writable location, which would be used as the default backup path. Since I have already written code to do this for the diskfree routine -- if only I can complete registration to leaf/sourceforge and publish it! -- I can certainly do this, as well. Actually, I thought of that; but, stopped short, not knowing where you thought to go and not daring assume that simple sort -- regardless of incoming order -- of writeable devices was sufficient . . . -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] dachstein CD - backup dest
Actually, I thought of that; but, stopped short, not knowing where you thought to go and not daring assume that simple sort -- regardless of incoming order -- of writeable devices was sufficient . . . A simple sort of writable devices is not sufficient. The search order should be the packagepath (ie $devlist in /linuxrc). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Magic recipe
Someone asked me for instructions on how to convert their existing installation to this enclosure concept. Here are instructions for 1680Kb floppy disks based on *stein, LRP, Bering, etc. It does not work for derivatives like Coyote Linux and others that changed the lrp extension into tgz. It does *not* apply to Oxygen releases. Please adjust the following instructions for your own boot medium. These are mechanical instructions that do not take into account potential differences in the actual binaries in use before and after the move. It does not alter you kernel, modules, or other packages on the disk. They simply give you your old disk back in the new packaging. Please exercise your best judgment before flaming me :-)) 1. Download the startup kit from http://leaf.sourceforge.net/devel/scaron/leaf.htm appropriate for your kernel. (2.2 or 2.4 depending on whether you have Cinege's kernel patches or not) The busybox in the 2.2 enclosure has a lot MORE applets than the one for 2.4 kernels. Such is life. 2. Boot this disk, log in as root, and take the disk out of the drive. Exit the menu system, edit /var/lib/lrpkg/backdisk and delete the line for the root package (it should be the second line). 3. If you don'thave a backup for your LEAF/LRP disk, now is the time to make one (use lrcfg to make one). 4. Type the following commands to install your old root and etc packages: mount -t msdos /dev/boot /mnt cd /mnt lrpkg -i root lrpkg -i etc cd /var/lib/lrpkg touch root.conf cat root.net.conf root.conf cat root.sys.conf root.conf cd /root umount /mnt 5. Use lrcfg to backup root and etc to your disk. root will probably shrink to less than 10% of its initial size. 6. Place the startup kit in the drive and type the following (notice the capitalization of the word LEAF :) mount -t msdos -r /dev/boot /mnt cp -a /mnt/LEAF.lrp ./ umount /mnt 7. Place the target disk in the drive and type mount -t msdos /dev/boot /mnt cp -a LEAF.lrp /mnt sync edit /mnt/syslinux.cfg 8. replace the initrd=root.lrp with initrd=LEAF.lrp and make sure the LRP parameter reads LRP=root,etc,... There may be more than one occurence of initrd and LEAF if your disk support multiple configurations. Save the file. 9. Type sync umount /mnt 10. Hit the reset button and watch the results. The old menu is now available under the Packages menu, option root. This is *not* perfect but it gives you a proper idea of the actual change. Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] LEAF Bering beta-3 available
The LEAF 2.4.16 - beta2 distribution has been updated and now becomes LEAF Bering - beta3. Main features: - 2.4.16 Kernel with support for IDE, DOC, SCSI, Parport, USB, PPP, PPPoE, PPPoA, PCMCIA, ISDN, Bridging, ext2/ext3/reiserfs, IPV6, Wireless LAN, ... - Provided with latest 1.2.5 Shorewall package - New packages available: pcmcia.lrp (3.1.31), wireless.lrp and ppp-filter.lrp in the Bering package area - Winimage disk image now available for Windows users - Updated documentation Stills fit on a 1680K floppy :-) The detailed changelog is available at: http://leaf.sourceforge.net/devel/jnilo/leaffw00.html#AEN68 For the full documentation refer to: http://leaf.sourceforge.net/devel/jnilo/leaffw.html Files are available for download at: http://leaf.sourceforge.net/devel/jnilo/bering/latest/ Extra packages available at: http://leaf.sourceforge.net/devel/jnilo/bering/packages/ Cheers Jacques ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] ISDN and Bering
Hello Jacques, List I am trying to fit the isdn on the Bering system, with the two floppy system this allready functions here. But to get the hisax file on the disk, it has to be compiled for each specific card. Now my problem If I use exactly the config file from Jacques. and apply the patches that are on the website, and after that do a make dep, make modules. without any change. My hisax.o is about 3K smaller, and in combination with the isdnutilities I get an error message with a dump of the kernel. Using the hisax file from Jacques with exactly the same setup functions. My questions. Could this be a compiler related problem ( gcc version , flags ? ) Allthough the kernel is built modular, it is obviously not possible to create a module on an other machine. Greetings Eric Wolzak http://leaf.sf.net/devel/ericw/ get the bering :))) http://leaf.sf.net/devel/jnilo/bering ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] 2 useful comments from Matt and Dave
On 2/4/02 at 2:24 PM, Serge Caron [EMAIL PROTECTED] wrote: What [an enclosure] does promote is a facility for moving from environment A to environment B, be it Oxygen or Dachstein or whatever. There is no guarantee to Joe User that happens to like Shorewall enough to build on it for his own needs that he will be able to move his stuff to a cool new environment like Oxygen. On the other hand, the ordinary sysadmin that can write a script without feeling the urgency to rewrite the entire LEAF effort will find the concept of an enclosure usefull. After all, HER stuff is protected and she is one quick cp -a root.lrp ... away from moving to something else. Further, you can replace the ENTIRE set of files in the enclosure without loosing the base concept. Note that Oxygen (now) uses root.gz - which is NOT a tar.gz file, but a gzipped filesystem image, just like the Linux kernel wants... Finally, it does promote some social responsibility. If LEAF provide a package repository, it creates a pull effect, that is a center of attention were everybody can go to find something. If it also provides reference kits (bootdisk, kernels, modules, whatever) it suddently has a broad offering as well as sharing the experience of working with these different environment, be it glibc 2.1.x or MacIntosh processors. If Charles, Jacques, or David create a distribution, it creates a push effort that lacks the LEAF project synergy. Forgive me - you lost me there. Pull? Push effort? Project synergy? Reference kits? What? Not only do I agree that POSIXness and silly kernel patches must go, I expect people creating enclosures to document each aspect of building of boot image in the comfort of their user's computer. This is Linux and people are also expected to work from source. Depending on the user's knowledge, you can do this: # fdformat /dev/fd0u1680 # dd if=my-leaf-disk.ima of=/dev/fd0u1680 Or you can look at the Linux From Scratch site (and HowTo) and read the Developer's Guide. PacketFilter is just a network setup script designed to drop IP traffic. Yet it is usefull enough to build a small workstation, an unforeseen benefit. How do you create a workstation from a network shell script? As I plainy wrote in the documentation: I do not intend to maintain an LRP distribution just for the purpose of providing an environment in which to run PacketFilter. I believe this is clear enough. True. But one doesn't need to create a distribution to utilize shell script and create your own firewall scripts. That is how Seawall, Shorewall, and rcf came to be. All work without a specific distribution. It almost sounds as if you are suggesting that a distribution have a standard set of applications included and a standard set of functions and scripts so that script writers can depend on certain programs being there and not worry these same programs will turn up missing. -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ISDN and Bering
On Monday 04 February 2002 17:23, Eric Wolzak wrote: My questions. Could this be a compiler related problem ( gcc version , flags ? ) Allthough the kernel is built modular, it is obviously not possible to create a module on an other machine. There is likely something support wise that you have built in your kernel that is missing from Jacques kernel. My experience, especially with the advanced routing, would probably be something in the advanced routing options or card support. The easiest way of fixing this is to have him send you his makefile, so they're the same. A gcc version is possible, but not likely if your module is smaller. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
