[Leaf-devel] Introduce Myself
I'd just like to introduce myself to the devel group. My name is Lynn Avants, I have done admin. work w/Linux for a couple of years now, some consulting with systems integration, and support for sites/groups like Brainbuzz/Cramsession, Corel Linux, linuxjunior.org, linuxnewbie.org, and astcomm.net. I was working on bringing LFS (LinuxFromScratch) into the 2.4.x kernel w/reiserfs as the stock method decided to branch out into my own distribution last Spring. A couple of weeks ago in preparation to upload the base into my SF project, I lost the harddrive the whole distro. I've decided to abandon that project now an start with something a little less frustrating :), so I would like to dedicate some time to making LEAF accessible to a wider user base. Documentation, packages, and some (light) scripting is some of the things I plan to work on, besides support of course. I think LEAF can expand into a lot more new users and some enterprise uses. I am looking forward to helping LEAF move forward, -- ~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] New LEAF user Choose version FAQ
I wrote a FAQ concerning new users looking at which LEAF version best fits their needs. This is submitted for comments, questions, and corrections/improvements to the list. Also, should Seattle Firewall, ShoreWall, and OpenWall be covered in this FAQ? It wouldn't be a problem. Is the command help also relevent to being included in this doc? FAQ is below post. -- ~Lynn Avants aka Guitarlynn **Start of FAQ *** ** Choosing LEAF Version FAQ ** *** By Lynn Avants aka Guitarlynn The LEAF (Linux Embedded Appliance Firewall) project are one of my favorite IT tools. Do you need a small Linux distribution that will scale down to a single floppy disk or is expandable to span several floppies, a flash disk, or a CD? Do you want a STRONG home firewall that you can make from old spare parts or find laying out in the trash or a friends garage? Do you need a cheap VPN gateway solution without the thousands of dollars in licensing fees? Need something to use as a thin-client or a terminal client? Then this is probably just what you've been looking for. Some old versions of LEAF can run on a 386SX, but for the more recent versions/branches a 486DX33 with 16Meg's of RAM is suggested for a floppy versions (24 Meg's for the cdrom versions) for cable modem users and an old Pentium 133 with suggested 24Meg's of RAM should saturate a T1 WAN connection unless you running an encrypted VPN gateway. Dachstein and Oxygen are configurable to run not only on a floppy, cdrom, or harddrive, but also flashdrives. Some people have built half-rack 2U router/bridge/firewalls and servers out of LRP. The coolest part is run on a write-protected floppy or a cdrom, if the machine is compromised, you can just restart it and it is back to the original setup...not even Cisco can guarantee that. All parts are common PC hardware typically, so you can always find and buy hardware for it if something goes bad. Another major difference between LEAF distributions and your regular Linux distributions is that LEAF is embedded Linux. This means that the system runs in a virtual disk in RAM, which is the fastest once booted, and safe from system crashes if they may occur because there is no data loss of the boot/configuration disk(s). Dachstein -The brand new release of Charles Steinkuehler's, who with his last release (EigerStein), is probably the most used branch of all LRP-based distro's in the last year or two. He picked up Matthew Grant's mountain branch and started extending scripts to make Mr. Grant's release easier to use and add more functions. Dachstein is used the most often as a firewall, which with his scripts, are likely to be the strongest stock firewalls I know of without any prompted configuration. It's fairly easy to setup if you know anything about networking and actually read the README.txt file before trying to set the disk up. When run as a router, Dachstein is equally as functional. SSL, IPSec, a web-based monitor, a dhcp server, and web-proxy server are stock on this version. A cdrom version of Dachstein is in full development and is available for testing. Charles is one of the primary developers at LEAF. This is what I use for my firewall at home. Oxygen -David Douthitt is another of LEAF's primary developers with his incredible new Oxygen branch. Although Oxygen can do all the firewall, routing, and bridging that almost all LRP derivatives do, he has taken a different direction in having Oxygen work best as a miniature scale jack-of-all-trades distro. Scalable from a single floppy to a full 7 in the present release, he is also in testing with an Oxygen cdrom that will do more than I could think of explaining here. Shoot, the floppy(s) release does more than I would think of listing here! At a 2.2.19 kernel now, a 2.4 series kernel is in testing with iptables and an available choice on the development cdrom. Advanced features such as network booting, thin client setup, machine rescue, and network monitoring are built-in. The cdrom version also has a LEAF developer's kit on it if you feel the need to make something for LEAF that isn't already available. I always have Oxygen available for use when I need an outstanding tool or something more specialized than what normally comes on Dachstein. LRP-the Original -Dave Cinege's original LRP release. This is not part of the LEAF project, but mentioned out of respect of being the base that the LEAF versions came from. Development has been rather slow, but the upcoming Butterfly release (LRPv4.0) should be out soon. The most recent has been 2.9.8 which uses the 2.2.x kernel. This distro is the best as a regular router and tool-kit distro. LRP is not supported on LEAF, but rather on the distro's own domain at http://www.linuxrouter.org
[Leaf-devel] LEAF version FAQ rev.1
Based on feedback and a few personal edits, I submit rev.2 of a LEAF Version FAQ for more feedback, opinions, etc... It has been modified quite a bit. -- ~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! **Start of FAQ *** ** Choosing LEAF Version FAQ ** *** By Lynn Avants aka Guitarlynn The LEAF (Linux Embedded Appliance Firewall) project are one of my favorite IT tools. Do you need a small Linux distribution that will scale down to a single floppy disk or is expandable to span several floppies or a flash disk and doesn't require a hard-drive? Do you want a firewall that you can make from old spare parts or find laying out in the trash or a friends garage that will offer you more protection than a low priced commercial firewall without too much effort? Do you desire the flexibility of adding VPN, ssh2, and other services to such a device? Do you desire something to use as a thin-client or a terminal client operating system? Then one of the LEAF versions is probably just what you've been looking for. The suggested minimum requirements for LEAF are as follows. A 486DX33 with 16 Meg's of RAM for floppy versions and 24 Meg's of RAM for the cdrom versions. Either two network cards for cable/DSL users or A network card and modem for dial-up/IDSN users will be required to make the necessary network connections. These minimums should provide you with a sound and stable piece of equipment that won't require a monitor or keyboard. A few people have reported having running LEAF boxes that haven't been touched in close to a year or more (in fact I had one myself, though a recent upgrade required me to restart it). For idea on how LEAF should perform on your hardware, an old Pentium 1 with suggested 24Meg's of RAM can saturate a T1 WAN connection running PCI network cards. It should be noted that PPPoE users have noticed sizable bandwidth gains running a Pentium1 166-233 Mhz boxes, but as a cable user myself running straight DHCP, a 486DX2 has provided me with maximum possible bandwidth for my connection. The major difference between LEAF distributions and your regular Linux distributions is that LEAF is embedded Linux. This means that the system runs on a virtual disk in RAM, which is fast and safe from data loss on the boot/configuration disk(s) if the system crashes. Dachstein and Oxygen are configurable to run on virtually any type of disk you can throw at it. Some people have built half-rack 2U router/bridge/firewalls and servers out of LRP. An interesting point of LEAF is part is run on a write-protected floppy or a stand-alone cdrom setup, if the machine is compromised, you can just restart it and it is back to the original setup. All parts are common PC hardware typically, so you can always find and buy hardware for it if something goes bad. Dachstein -The brand new release of Charles Steinkuehler's, who with his last release (EigerStein), is probably the most used branch of all LRP-based distro's in the last year or two. He picked up Matthew Grant's mountain branch and started extending scripts to make Mr. Grant's release easier to use and add more function. This is generally the choice version for those new to LEAF, being that 90% of the configuration is in one file (network.conf) and includes a dhcp server, a DNS cache-proxy, a web-based system monitor, and SSH (server and client) on the default disk. VPN passthrough is also configurable and working with IPSec and PPtP protocols. Dachstein can be used as a masquerading firewall, a non-masquerading firewall, or a non-firewalling router. A cdrom version of Dachstein has just been released (cd-v1.0.2). Charles is one of the primary developers at LEAF. This is what I use for my firewall at home. Oxygen -David Douthitt is another of LEAF's primary developers with his incredible Oxygen branch. Although Oxygen can do all the firewall, routing, and bridging that almost all LRP derivatives do, he has taken a different direction in having Oxygen work best as a miniature scale jack-of-all-trades distro. Scalable from a single floppy to a full 7 in the floppy release, he has just released the Oxygen-cdrom that works more like a full-fledged distro running on a LEAF system that includes development tools for LEAF and documentation that other LEAF version do not. Oxygen is using a 2.2.19 kernel now and a 2.4 series kernel is in testing with iptables on the development cdrom. Advanced features such as network booting, thin client setup, machine rescue, and network monitoring are built-in. The cdrom version also has a LEAF developer's kit on it if you feel the need to make something
Re: [Leaf-devel] LEAF version FAQ rev.1
*** Should I bypass the explanations and link to Why should I use it? http://sourceforge.net/docman/display_doc.php?docid=1739group_id=13751 *** Should I bypass the hardware and link here (maybe update for Cdrom versions).: http://sourceforge.net/docman/display_doc.php?docid=1398group_id=13751 *NOTE*- I know that a 386SX w/8M RAM is still possible being that I've done it, but this is really not practical for anything but a minimum of services (ie... bridging, minimal router w/o services). Update the hardware FAQ? * Fork 2 (related) I know there is a ip command HowTo on c0wz, but the inclusion of a FAQ for basic LEAF commands might prove useful. I agree that it should be stripped from the Choosing... FAQ. Seperation of the different versions would be necessary (ie... Charles note to Oxygen's use of apkg other notable differences). Would a seperate FAQ along this line be useful to have created ??? ***Fork 3 (future thoughts--OT)*** I've really never spent much time with the LEAF FAQ's, assuming they were rather shallow like many other FAQ's. After a couple of hours of reading I've found them to be very informative, clear, and in an excellent format (book-style). A link to the FAQ section from any LEAF download and mailing list page would likely clear a lot of mailing list questions. They are a little out of date with the releases of the last couple of months, but that wouldn't take much work to update. Possibly a downloadable FAQ-Book tarball would prove useful if the FAQ was fully converted to cvs/book form. Thoughts? -- ~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] LEAF version FAQ rev.1
Barring anymore suggestions/changes, this FAQ is ready to submit. Feedback? START OF FAQ * *** ** Choosing LEAF Version FAQ ** *** By Lynn Avants aka Guitarlynn with plenty of help from other developers The LEAF (Linux Embedded Appliance Firewall) project is one of my favorite IT tools. Do you need a small Linux distribution that will scale down to a single floppy disk? That is expandable to span several floppies or a flash disk? One that doesn't require a hard-drive? Do you want a firewall that you can make from old spare parts or find laying out in the trash or a friends garage that will offer you more protection than a low priced commercial firewall without too much effort? Do you desire the flexibility of adding VPN, ssh2, and other services to such a device? Do you desire something to use as a thin-client or a terminal client operating system? Then one of the LEAF versions is probably just what you've been looking for. The suggested minimum requirements for LEAF are as follows: A 486DX33 with 16 Meg's of RAM for floppy versions and 24 Meg's of RAM for the cdrom versions. Either two network cards for cable/DSL users or A network card and modem for dial-up/IDSN users will be required to make the necessary network connections. These minimums should provide you with a sound and stable piece of equipment that won't require a monitor or keyboard. A few people have reported having running LEAF boxes that haven't been touched in close to a year or more (in fact I had one myself, though a recent upgrade required me to restart it). For idea on how LEAF should perform on your hardware, 486 systems can typically route 3-6 MBits/s, more than enough for the average cable-modem/xDSL connection. Users with a PPPoE connection or a VPN gateway (both CPU intensive) will likely see speed increases using a Pentium-1 class system. Another big advantage to most Pentium systems is the availability of PCI slots, allowing the use of modern, inexpensive (and easy to configure!) PCI network cards. As a cable user myself running straight DHCP, a 486DX2 has provided me with maximum possible bandwidth for my connection. The major difference between LEAF distributions and your regular Linux distributions is that LEAF is embedded Linux. This means that the system runs on a virtual disk in RAM, which is fast and safe from data loss on the boot/configuration disk(s) if the system crashes. Dachstein and Oxygen are configurable to run on virtually any type of disk you can throw at it. Some people have built half-rack 2U router/bridge/firewalls and servers out of LRP. An interesting point of LEAF is part is run on a write-protected floppy or a stand-alone cdrom setup, if the machine is compromised, you can just restart it and it is back to the original setup. All parts are common PC hardware typically, so you can always find and buy hardware for it if something goes bad. Dachstein -The brand new release of Charles Steinkuehler's, who with his last release (EigerStein), is probably the most used branch of all LRP-based distro's in the last year or two. He picked up Matthew Grant's mountain branch and started extending scripts to make Mr. Grant's release easier to use and add more function. This is generally the choice version for those new to LEAF, being that 90% of the configuration is in one file (network.conf) and includes a dhcp server, a DNS cache-proxy, a web-based system monitor, and SSH (on the cdrom version) on the default disk. VPN passthrough is also configurable and working with IPSec and PPTP protocols. Dachstein can be used as a masquerading firewall, a non-masquerading firewall, or a non-firewalling router. The cdrom version of Dachstein has just been released (cd-v1.0.2). Charles is one of the primary developers at LEAF. This is what I use for my firewall at home. Oxygen -David Douthitt is another of LEAF's primary developers with his incredible Oxygen branch. Although Oxygen can do all the firewall, routing, and bridging that almost all LRP derivatives do, he has taken a different direction in having Oxygen work best as a miniature scale jack-of-all-trades distro. Scalable from a single floppy to a full 7 in the floppy release, he has just released the Oxygen-cdrom that works more like a full-fledged distro running on a LEAF system that includes development tools for LEAF and documentation that other LEAF version do not. Oxygen is using a 2.2.19 kernel now and a 2.4 series kernel is in testing with iptables on the development cdrom. Advanced features such as network booting, thin client setup, machine rescue, and network monitoring are built-in. The cdrom version also has a LEAF developer's kit on it if you feel the need
Re: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2
On Sunday 20 January 2002 11:13, Jacques Nilo wrote: Was not it CERBERE (I am not sure of the English spelling) the dog who was keeping the entry of Hell ? Jacques hehe, maybe the Dante series.. -- ~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! --- -- ~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] Site Update 2002-01-16
On Sunday 20 January 2002 10:41, Mike Noyes wrote: Matt Lynn, Take a look at the link above now, and let me know if this is what you had in mind. http://leaf.sourceforge.net/content.php?menu=1000page_id=4 Looks great to me, ty! -- ~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! --- -- ~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] network.conf error?
$BNDWIDTH \ allot $PXMTU avpkt 1000 bounded weight 1 prio 1 tc qdisc add dev $1 parent $HNDL:3 pfifo # Add filters tc filter add dev $1 parent $HNDL:0 protocol ip \ priority 50 handle $MRK_CRIT fw classid $HNDL:3 tc filter add dev $1 parent $HNDL:0 protocol ip \ priority 60 handle $MRK_IA fw classid $HNDL:2 \ return 0 } ### # End ### end of gereated network.conf ### -- ~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] network.conf error?
I've seen problems of this sort caused by unpaired quotes and improper end-of-lines (ie DOS CRLF instead of unix LF). Ah so, got it! I eliminated some whitespace I added and found a missing semi-colon on ~line 737. Works now!!! Going to do some connection testing and add a prompt for portfw to an internal server... maybe DMZ. Should be available for testing in day of so. Thanks for the suggestions everyone, I was just venting more than anything. -- ~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! --- -- ~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] should LEAF cut over to uClibc? (was Tooo long :)
On Wednesday 23 January 2002 14:21, Ray Olszewski wrote: Now if we could only come up with an aol.lrp package ... sigh. hehe, RH is working on that as we speak! -- ~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] Make files, CVS, and distributions
On Wednesday 23 January 2002 14:42, [EMAIL PROTECTED] wrote: In thinking about this, what if we confined a distribution CVS to the following: 1. Configuration file: URL of source, and perhaps more 2. Makefile 3. Patch or patches ..then the Makefile would grab the source from the URL, unpack it, set up patches, compile it, and create the *.lrp package. So space required for CVS would be minimal, and all files are text... Easy to updatevia CVS. Some of the drawbacks are: * URLs must be validated Others? Server overhead if a _lot_ of compiling is done. I am thinking about trying some CGI scripting to generate custom floppy images via a route similar to this. I haven't investigated enough to see any big problems sounds plausible, but a bit of work to me. Sounds like the way to go with where Oxygen is at now (and where everything else is headed). - ~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] Re: Ticker script
On Wednesday 23 January 2002 21:42, Mike Sensney wrote: Yes, I had noticed that little annoyance. But I just did some more testing and discovered you can double escape the \ and that apparently works in both bash and ash. That is very true good examples in the install scripts coming out. Not necessarily a example of great scripting, but completely functional. Network.conf was pure joy! -- ~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] Announce Dachstein install scripts
I have written a set of install scripts for Dachstein v1.0.2 targeted at _new_ users. There is a set for the floppy release and an extended set for the cdrom release. An install item is added to the main menu in lrcfg, there is an auto-backup option builtin for stock Dachstein images. The scripts generate compliant /etc/modules and /etc/network.conf files for troubleshooting and advanced configuration options. They only support ethernet at this point and time (ppp and pppoe should be done as a seperate set IMHO). Check the README.txt for more info. They weigh in at 76.4 kB uncompressed (cd set) and 69kB uncompressed (floppy set). Both sets of scripts combined come in at 29kB gzipped together. They're pretty big, but staying compliant and my skills were starting to conflict :( You can check them out at: http://leaf.sourceforge.net/devel/guitarlynn/ Hopefully they will be useful to someone! Any feedback/testing/suggestions are appreciated! -- ~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] A name for LEAF 2.4.16
On Thursday 24 January 2002 15:28, Jacques Nilo wrote: It's time for us to get a name for the LEAF 2.4.16 distro. Mike wants one :-) :) : I have finally opted (suggestion from Jack Coates, thank Jacks) for the Strait concept. Very nice concept! Few suggestions: Bering Hormuz Malacca Gibraltar Dover Don't use Gibralter, that is the name of a stand-alone linux cd version somewhat similar to the LEAF cd-versions. -- ~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! --- -- ~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] Site Notoriety
On Saturday 26 January 2002 08:37, Mike Noyes wrote: Everyone, We got a lot of referrals from lwn.net and root.cz this week. LWN added us to their Linux distributions list, and there was a blurb about us on root.cz that I can't read. http://lwn.net/2002/0124/dists.php3 http://www.root.cz/clanek.phtml?id=1013 Also, we broke our previous monthly record for unique web hits recorded by SF. Take a look at our stats page using a monthly view. http://sourceforge.net/project/stats/?group_id=13751 That's great! It still amazes me that FreeSCO stays that well-regarded, it hasn't been upgraded much since around the LRP 2.9.3 days and you still can't write-protect the floppy. The config script was really the only advantage to a stripped version of old LRP (I'm working on that though). -- ~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! --- -- ~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] LEAF command FAQ
# editor e3 in vi-mode # Network configuration file /etc/network.conf # Firewall/Filtering is not on the stock (default) image. ### BERING/LEAF-2.4.16 SPECIFIC COMMANDS ### # Start the configuration menu lrcfg # lrpkg -i packagename *NOTE* Also add to syslinux.cfg or lrpkg.cfg on your boot device to load at boot. # ifconfig is on disk in addition to iproute2 commands. # Setting status of interfaces (network cards, modems, etc...) ifup [options] [interface(s) ifdown [options] [interface(s)] [options] (start|restart|stop|reload|force-reload) # Network commands (functions) svi networking (start|stop|reload|restart) # DHCP client pump # editor e3 in ae-mode (vi, pico, and other modes available) # Network configuration file /etc/interfaces # Firewall/Filtering done by Shorewall (shorwall) * END OF FAQ *** -- ~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] LEAF command FAQ
If everyone is happy with it, I will submit it to cvs tomarrow! Thanks, Lynn ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] LEAF command FAQ
On Friday 01 February 2002 07:16, Mike Noyes wrote: Lynn, Please submit new FAQs to the DocManager. I need the docid it assigns to the document before it is placed in cvs. Thanks. https://sourceforge.net/docman/new.php?group_id=13751 Yes, of course! Ty! -- ~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: AW: [Leaf-devel] DFE-570TX ?
On Thursday 31 January 2002 11:36, Sandro Minola wrote: Could you expand on this and allow us to use it as a Customer Testimonial or something like that? It would be quite an example - a sort of Look at What You Can Do with LEAF! How about diagrams, and so on Yeah, and some pictures (photo) would be nice! That would be a very nice addition to the site! As I have stated before, I make my own 1U/2U half/full slot rack cases for LEAF routers and planning to possibly expand into an embedded web/ftp/mail server. I'll take some pictures for a testimonial too if this would be another practical example. I should be making another one within a month. -- ~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: AW: AW: [Leaf-devel] DFE-570TX ?
On Thursday 31 January 2002 12:26, Sandro Minola wrote: Hi Lynn, hi all For all those who understand german, there is a good site about converting a normal pc into a 19 rack case: http://www-public.tu-bs.de:8080/~y0011440/ This one is more along what I based my routers/servers from: http://www.ant-computing.com/index.html?oldurl=/ This page is made by a fli4l user. fli4l is a competitor to LEAF and unfortunately it's much more popular in germany than LEAF. (http://www.fli4l.de) Fli4l has some advantages and some disadvantages comparing to LEAF. Perhaps you're interested in what they did better than we. Interesting, I do try to keep up with the changes of *other* similar products, FMI. I haven't tried fli4l though, I may do that if I don't need to learn German :) I don't know of anything that I can't get to work with LEAF that anything else will do in anyway. -- ~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] LEAF command FAQ
It is submitted and XHTML 1.0 compliant. -- ~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] dachstein CD - backup dest
On Friday 01 February 2002 17:52, Michael D. Schleif wrote: KP Kirchdörfer wrote: the backup destination of packages points by default to cdrom, which is write-protected by technology... Could this be changed easily to default to /dev/fd0? Cosmetic change, I know, for leaf-die-hards, but something new user might be disattracted. One problem with this thought, if the cd packages are pointed to backup to a floppy by default, what happens when the Newbie decides to backup the entire disk to a floppy??? It's the chicken/egg question! Once you backup a package to a floppy and load it during boot once, it will backup to the last place loaded (ie... the floppy) and life will be great. Other side of the coin, they keep trying to backup ~20Meg to a floppy and can't figure out why it doesn't work! Maybe the default way isn't any worse, it could be conceivably better depending on you POV. -- ~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] LEAF command FAQ
On Saturday 02 February 2002 01:27, Malcolm Miles wrote: That works from the prompt but when I run lrcfg it defaults to the ae-mode. K, I don't know where it calls the binary from, but e3 is the default and a symlink to e3ne. There is no reason you couldn't delete the e3 symlink in /bin and ln -s /bin/e3ws /bin/e3. It should get what you want anyway! -- ~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] Mosquito distribution?
On Saturday 02 February 2002 08:30, Mike Noyes wrote: Does anyone know anything about a Mosquito distribution from Japan? We consistently get significant http referrals from: LEAF and LRP are linked right at the top of their homepage. They appear to be duplicating (in some form) the ssh, ssl, weblet, and ppp/pppoe packages at a minimum. The Webadmin package they have appears to be a tiny, custom version of weblet. It didn't appear to have any ability to change settings over the web (as I first assumed). I downloaded their image, but it's a Win32 exe, so I'll put it on a disk the next time I boot a M$ box here to confirm this. I really don't think it is too much of a deviation from what LEAF has been doing for some time, other than native Japanese support/docs. It would appear that they're watching our site for parallel upgrades. -- ~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! --- -- ~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
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
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] 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
Re: [Leaf-devel] weblet the like
On Tuesday 05 February 2002 08:16, Charles Steinkuehler wrote: IMHO, there's nothing inherently wrong with GUI config tools (properly secured). I would like to see a consistent configuration system for the next generation LEAF that allows text-based menu configiguration via scripts on the default system, with the option of adding a web GUI if desired (sort of a light-weight linuxconf that actually works). It should also be possible to edit config files by hand without confusing the config menu front-end. hehe, Linuxconf more like Webmin :) OK, that pretty much eliminates any CGI except shell then. It's likely the best option, being the perl is not possible on a floppy. I imagine licensing would be a issue with vitually any other scripting language anyway. The ease of use this provides would help widen the user base, and I think the discipline of maintaining a consistent configuration scheme will add to both understandability and ease of administration. As long as the power to manually edit the config-files directly is still available (w/o completely confusing the GUI tools), I don't see where this has any big negatives (other than the obvious time/effort involved in building the configuration framework in the first place). In other words, it will require using sh, sourcing file(s), mandatory function style, dire commenting, and a good working knowledge of sed (that I'll likely become _much_ more familiar with). Can you use POST in sh-httpd or is this going to have to move to thttpd? Do you have an existing release config file form you would like to base off of, or do we do one from scatch? Every character in the McDonald's theme has a menu item associated with it except Ronald, what exactly does Ronald represent? hehe -- ~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
On Tuesday 05 February 2002 14:52, Charles Steinkuehler wrote: sh-httpd could be modified to include POST, but it might be better to use something like mini-httpd, or perhaps a web-server written in an scripting alternate language (if we include something like java, ruby, c). If we stick with sh-httpd, it should be cleaned up a bit, given a serious security review, and also really needs support for connection-keep-alive... Well, from my digging the last couple of days, the best web-server option I've seen has been thttpd that supports POST natively. It appears to be secure and supports SSL and we already have a package (whether a re-compile is needed for this is another story. I dug through Mosquito last night for a bit. They use _no_ text editor and _all_ configuration must be done via the web-cgi applet. They are using thttpd w/uncgi which seems a great system other than Uncgi is copywritten freeware, which could cause us GPL problems if packaged in a release. Uncgi supports most scripting languages, Mosquito used shell and Jscript for theirs. I know this is a different direction than where we are looking, but thttpd and a generic GPL'ed script interpreter would work ideally. I'd especially like to see a clean, extensible, understandable method for setting up complex networking configurations static routes, since we're supposed to be targeting networking based applications...I have yet to see a method of configuring networking on a linux disto that I would consider intuitively obvious, but I've mainly worked with RH and Caldera. Anyone know if some other disto has already solved this cleanly? Not in an advanced server/routing setting. I could come up with a menu system similar to the kernel menuconfg/xconfig that I think could be a lot clearer considering simple/advanced options. I've tested darn everything but Caldera and Gentoo looking for something similar. I was also working on a similar-type project, before starting LEAF, for a Server-Linux upstart creating a similar menu-system for configuration of Apache, ProFTP, Samba, etc Unfortunately, my hard-drive died the week I was going to upload it and I never bothered to cvs or back it up :( . A good lesson was learned that day. -- ~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] CF (write protect) + IDE adapter
On Wednesday 06 February 2002 02:04, Jeff Newmiller wrote: On Sun, 3 Feb 2002, guitarlynn wrote: Yes, a product to keep me from cutting tiny toggle switches into those blasted IDE cables would be a godsend! I can live with the CF cards nicely though for the time being (if I can get one anyway)! My curiosity gets the better of me... just how many of these toggle switches have you installed, and how well have they worked? hehe, I haven't to be honest I was in a strange mood @that time. I probably shouldn't have put it in there, sorry. I remember a long thread with some people trying this a couple of years ago though, did anybody ever have any success??? If my memory serves me right, there was a problem with disk-corruption errors if the system tried to write to the HD. It wouldn't be much trouble for me to try this if your really interested though. A less frustrating way of trying would be to wack a piece out of wire #23 and simply switch to another cable to write. I'll give it a try, I need to do some soldering today anyway! You bit, I will too. -- ~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] Ports
comments inline ;} In reply to DD CS ( others...): After the make install is done, the LEAF system now has /tmp/wget.lrp and an installed wget binary. Then you have come up with how Debian now installs . a set of one or more boot floppies, then 'wget' everything else. The unstable tree is finally about cleaned up from the mess it's been for some time :) Another possibility: using that full Linux system again, doing the same thing - except this time a make install uses scp and a private key to copy the file over to the LEAF system, then uses ssh and a private key to install the package on the LEAF system. Maybe rsync after the compile? While the gentoo stuff looks promising, I have yet to play with it...where's all the time go? Regardless, if you're wanting to play with a bsd style ports sytem on linux, Gentoo and portage are AFAIK, the way to go. I haven't played with Gentoo, but this sounds very similar to 'ALFS' which is an automated LFS. It compiles on the client box, but we could work around that via CGI/MySQL and everything is done via chroot. Source is available too. The problem I'm seeing is that SF is going to _kill_ us if we start mass compiling kernels on their systems (think of _server_overhead X100 users at a time then SCP'ing this traffic back over their connection). Anyone know someone who wants to give up the bandwidth _and_ the processor overhead (with atleast one T!) ? Maybe a thorough set of pre-compiled kernels to select from would be preferrable resource wise. Besides, it will take a while to compile everything including the modules (ie... IPSec [none | pass-through | support]. I love the idea, but this is going to take a _lot_ of server resources to implement. Probably a lot of disk space considering how much traffic this could create over what we have now! -- ~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] Date/Time
On Thursday 07 February 2002 01:26, David Douthitt wrote: I've been looking into the date and time set in an Oxygen system, and comparing to a Mandrake system. That is a nightmare on Mandy 8+ I think your referring to a older relase (I hope!). LFS is probably clearer for what we're looking at, barring Busybox compatibility. The confusion comes this way: And it even appears that busybox date may be reporting the wrong time... sigh... Yep, it does! LFS still uses hwclock, so all the problems lie in the Busybox 'date' problem. Check this: http://lfs.planetmirror.com/view/3.1/chapter07/setclock.html http://lfs.planetmirror.com/view/3.1/chapter06/util-linux.html It appears that they have moved to ddate, which might be a good idea for busybox too, size in consideration. -- ~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] CF (write protect) + IDE adapter
I just got word back from PQI, I should get a data sheet in a couple of weeks. It won't be availiable until May though :( ### snip ##3 Dear Lynn Yes, we are now ready to present the first model of our Secure Disk on Module product; it will be formally launch to the market in May, this product is perfectly for those applications, which just likes you mentioned. PQI now is the market leader in Taiwan and Europe for this type of product, Secure DOM is our latest DOM product; it also being asked by many of customers who just like you since one and half year ago. Because for the password type DOM can not satisfy with their needs anymore. I will send you the datasheets of this product in the end of this month, because PQI will close for the Chinese New Year from Feb. 9 to Feb. 17. After you go through those product descriptions, I ensure you will be very interested to this wonderful DOM/HDD solution. Regards Sam Lu Information Appliance Division. # end of snip # If the CS modification to the ATA cable will work, I'll be willing to manufacture some for the group (or a module as Arnie noted, this will require 12 ATA cables though ... 24 max length). -- ~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] Ports
On Thursday 07 February 2002 09:55, Charles Steinkuehler wrote: My intent was to suggest we co-opt the portage system to enable an easily installed, standard development environment. We would also be able to benifit from the work of others maintaining the portage tree (updating packages with bug fixes, newer versions, etc). Oh, ok .. Sorry, I missed the developer part. slinks away for a day in Ark., job hunting Thanks for the clarification. There should be source on the Debian wget/rsync method they use in any case... great idea guys! -- ~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] CF (write protect) + IDE adapter
On Thursday 07 February 2002 10:59, [EMAIL PROTECTED] wrote: On Thu, Feb 07, 2002 at 10:41:33AM -0600, Charles Steinkuehler wrote: To install a write-protect device between the motherboard and an ATA device, you need something that understands ATA at the application level, and returns some sort of error for logical write commands. I understand this. But as i see this, this special device has one pin that it put to ground enables write protection. Not if it is expecting an ATA instruction back at the motherboard to work. If it was this simple, we would probably be using this as we speak and it wouldn't require a special controller (rather they could simply eliminate pin 30 at the disk and take it to ground there). -- ~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] CF (write protect) + IDE adapter
On Thursday 07 February 2002 11:24, Mike Noyes wrote: At 2002-02-07 10:47 -0600, guitarlynn wrote: I just got word back from PQI, I should get a data sheet in a couple of weeks. It won't be availiable until May though :( ### snip ##3 Secure DOM is our latest DOM product; it also being asked by many of customers who just like you since one and half year ago. Because for the password type DOM can not satisfy with their needs anymore. Lynn, Maybe their referring to me. ;) Probably so . ;) I've put in RFI's at several places... on several products. I've been asking for a DOM with a write protect tab/jumper/switch for approximately that long. I hope their new Secure DOM will work with standard motherboard/ide controller combinations. Me too. # Hey CS ### Is there any reason I can't make a module w/ a solid-state time-delay relay (set to boot time + x secs) to break pin #39 (Drive Active/Drive 1 present) and get the same effect? I would be willing to engineer one ... maybe I'll give it a shot tomarrow or over the weekend. -- ~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] CF (write protect) + IDE adapter
On Friday 08 February 2002 08:39, Charles Steinkuehler wrote: Um...you won't find any standard motherboards that support the usage of pin 30 for write-protect, and even if you could, it would probably be controlled by software, not a switch, which kind of defeats the whole purpose. That's the entire reason the WP jumper is on the device in the first place...you can use the pin 30 interface if you're designing a custom board...folks with standard hardware can just use the jumper (or optionally wire the jumper to a manual switch). OK, this is where I might be confused myself, and confusing others such as Matt. Let me explain it as I understand it, and everyone is welcome to thrash me into submission if wrong. As noted in the email and to a far lesser degree on the White paper, pin #30 _can_ be used with a special MB to control the WP, in particular with _partial_ software_named files/dirs to WP. The WP used with the pins #1-2 does not require the special MB or ATA instructions, simply a jumper or a jumper with switch, but you can't do partials. Now comes in my somewhat OT comments/thoughts of yesterday. Being that this jumper configuration does not require a special MB or ATA instructions beyond what is presently used, only a jumper that bypasses the disk itself (to ground) ... Is there any reason that this could not be implemented on any or all existing ATA run devices (CF, FlashDisk, IDE, etc), the jumper is bypassing the drive itself as far as the instructions on wire #1 is concerned The reason I bring this up at all is quite simple, I believe that the general population has old hardware that could be used for LEAF similar to mine roughly 30 old 486-P1 boxes that support IDE only (no SCSI support built in). The cost of a SCSI controller board is too expensive, or won't fit in the desired case restraints desired, so though it's a excellent option, it's not a desired option. I have flash and CF cards at present that I would like to use WP if possible through existing MB's ... a manual switch or even a $10-20 module would be more cost efficient and desired than simply trashing what I already have, hardware wise, to get WP, if possible. In other words, how many folks have said: Can I run LEAF on a harddrive (IDE). We say, you can, but it is a security risk compared to a floppy. What would it mean to be able to say: You can use a hd, but if you want it as secure as the floppy, a $10-20 add-in IDE module is available here (link). I think a lot of people would find this useful, IMHO, or maybe I'm thinking too hard and flogging a dead dog! -- ~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] CF (write protect) + IDE adapter
On Friday 08 February 2002 10:52, Mike Noyes wrote: Lynn, If I understand you correctly, you believe Apacer was telling Stefaan that Host Selectable (Close 2,3) mode wasn't supported, not that Connect to Ground (Close 1,2) didn't work. Since there is no WP jumper on the ADM, we need to create an adapter that jumpers pin 30 to ground when WP is desired. Pins #2 30 are ground on a typical ATA cable. Did I get that right? Anyone willing to try this, and see if it works? I will see if I can try it today. If it's this easy, I can't understand why SST/Apacer didn't add a two pin WP jumper (Close 1,2) to the ADM. Me either, I'm probably wrong ... so I'll use a MB I won't care to lose just in case. If I'm guessing right, I'll manufacture the darn things. -- ~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] CF (write protect) + IDE adapter
On Friday 08 February 2002 13:10, Mike Noyes wrote: Lynn, Do you already have one of the ATA-Disk Modules? If so, where did you get it, and what did you pay for it? No, Mike, I don't have one your not grasping the scope I see here. I just tried it, but it doesn't work as expected ... I'll have to engineer a module to work with it and a system patch ... but I can do this. THIS CAN BE MADE TO WORK WITH _ANY_ IDE DEVICE! -- ~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] Re: ADM Write Protect
On Friday 08 February 2002 22:00, Matt Schalit wrote: ATA-Disk module (ADM) and it's write-protect features: Here is the 40pin 5V ADM schematic. This is using the LD017 controller. In the schematic R8 is used as an option for WP. I think this is the crux. It's being used. It's being tied to ground by the presense of ground on IDE cable pin 30, and the existence of a zero-ohm resistor, ie. a short to gnd. a zero-ohm resistor is for circuit protection and yes pin 30 is ground on regular IDE as is pin 2. Not a general feature if IDE I would agree. For a regular IDE drive, disconnecting or strapping an IDE pin low or high, such as DIOW or DIOR (23 or 25 I think) would interrupt the writing of command signals to the drive's onboard controller. At least that's how I understand it so far. Nope, pin 23 drops the acknowledgement of the drive itself out of the BIOS no drive found to boot. I tried this a couple of days ago thinking the same thing. - If R8 is vacent, the device behaves normally (ie no write-protect) I see the exact opposite. It's gnd now according to the docs with R8 present and it's write enabled. If you remove R8, then you are trying to do the opposite, ie protect it. But is floating it correct? If pin 30 is grounded (as normally done) and you add R8, R8 then grounds out pin 1 (reset) and _then_ the drive is write protected. story If you've now read this far, you get the cookie. Earlier today I hacked a jumper in an IDE cable between pin 1 (reset) and pin 2 (grnd) and started the P166. The BIOS acknowledged the flash drive (not a CF, but a regular IDE flash drive) and kept trying to reset the drive. It started to boot and failed. I thought, well that sucks and left it there. Just a couple of minutes ago, I was working by it and thought I might just boot it again, which I did, but this time it wasn't cycling the reset as it had before and booted. I logged in and tried to mount the drive . it gave me io errors and would not mount the drive. I rebooted 4 more times with the same exact results. I took the jumper out and booted again, I could mount and write to the drive. Apparently the BIOS updated itself after the first boot and decided to work for me. /story In a nutshell, jumpering pins 1 2 on a regular IDE setup from around 1996 will write-protect a regular IDE drive. I will try this with a harddrive as soon as I get around to Syslinux'ing one. Can anyone else try and verify this for me ??? I won't guarentee anything at this point other than it worked for me on the only box I've tried it on. I apologize for being off-topic for using IDE instead of a ADM that I do not have. -- ~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] Re: ADM Write Protect
OK, a little back-ground on me, so maybe this makes a little more sense to follow. I have had 3 years of electronics schooling, a little over 2 years of Electrical engineering, and been a licensed electrician for around 4 years after a 5 year apprenticeship with specialties in digital control design and instrumentation. This doesn't mean a hill of beans other than I have a small notion how digital electronic devices are controlled on some level. My logic is somewhat different than a programmer when looking at devices such as data drives much of the time. I've been posting my thoughts without really going into an explanation of any depth ... maybe this will clarify what _is_ going on in _my_ head. a zero-ohm resistor is for circuit protection and yes pin 30 is ground on regular IDE as is pin 2. What does circuit protection mean? Ok, let's assume something internal in the ADM shorts out in a bad place We will also assume you are using the ADM as designed to use software via a special IDE controller to specify when and what is write-protected. This resistor has _no_ effect on the circuit _other_ than limiting the amount of current and voltage running across it. It technically should overload and burn out this resistor and protect the precious motherboard you just paid all this money for. In reality, this is almost never the case, but it is accepted good engineering practice from my experience. I said the writing of *commands* not data. The lack of commands is what yields the lockup, from my understanding. I was not claming that write protect is possible by blocking DIOW or DIOR. Rather it's the exact opposite as you found. Yes, I understood that, but I didn't state that I felt WP is possible w/o defining a software filter of _any_ kind, which is what I'm interpreting you saying on an extremely low-level here. You are defining what the manufacturer is intending to do and sell at a much higher price than a plug-in adapter to a toggle switch. If pin 30 is grounded (as normally done) and you add R8, R8 then grounds out pin 1 (reset) and _then_ the drive is write protected. The schematic show R8 exists. That's CS and my question at this point, Does R8 exist on an LD017 controller? Probably not, the drive wasn't shipped to write-protect .. especially with a non-compliant ATA controller. They probably save around a nickel by not putting it in at all. The only reason pin 30 is used at all is for software filtering as stated on the data sheet. I interpet the data sheet as saying a jumper between pins 1 2 can be used _or_ pin 30 for software controller depending on the high/low state. Apparently the BIOS updated itself after the first boot and decided to work for me. /story What BIOS are you referring to, and how does it update itself? The motherboard BiOS. I can't really explain this. When you put a 20 Gig harddrive in a Cyrix 333, why does it hang for ~30 seconds before booting. Checking the drive tables for a known drive type , then uses the best guess if not known, I guess. I really don't know anything about how BIOS hd detection really works. In a nutshell, jumpering pins 1 2 on a regular IDE setup from around 1996 will write-protect a regular IDE drive. I will try this with a harddrive as soon as I get around to Syslinux'ing one. I don't follow. Have you disconnect to wires to pins 1 and 2 on the drive, left them floating, and tied pins 1 and 2 of the cable side together? OK, you have two IDE connectors on the ribbon cable. Plug one into the drive. Now put a jumper, or wire in a switch, between wires 1 2 on the other drive plug. This simply grounds out pin 1 (reset) as the data sheet and the hardware tech alluded to. Is this going to work perfect on all drives/mb's/BIOS's ??? I don't know, it is now working on the one machine I tried with no problems. I can't say for anything else. Can anyone else try and verify this for me ??? I have a cable and an old IBM drive I can doink with. I'll let you know. Thanks, I think this could be of use to a couple of people besides myself anyway. Can I be a little lazy and ask you what the logic is that your trying to accomplish? What does grounding the reset line do? Something that will allow me to write-protect an IDE flash or CF drive in a 1U half-slot rack case. Write-protection will be pure hardware ideally. Maybe I'm just nuts, but it's lying there working as I wanted right now. I like to thank everyone for inspiring to make strange opinions and attempt weird tricks. -- ~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] Re: ADM Write Protect
On Saturday 09 February 2002 04:01, Jeff Newmiller wrote: The altered states to start to come into focus. :) hehe, kind of scary, eh? This is a cmos logic device.. not a power driver. It will not burn out any resistor. You often see resistors inline to limit current (say, for LEDs or transients from off-board inputs), but these are NEVER zero ohm resistors. I will have to agree with that, a real small diode would be more standard there, I've never seen a 0 ohm resistor? A zero ohm resistor is a piece of wire. It is not a fuse. I would recommend that you re-read Charles Steinkuehler's analysis for the most likely function of this (most likely not installed) piece of wire. Yep, I did and what you are saying makes sense. Why would you call a piece of wire (a jumper) a resistor? It seems that you would call it J8 or something or something along those lines. In any case, what R8 does, as Charles noted, takes the Wait# from the LD017_A0 to pin 30 (ground) on the controller. Mike said the tech told him that: They use a hardware solution shunting R8 to ground, which indicates to me that R8 was designed to be a component besides a piece of wire. A shunt is typically a resistor or an inductor coil. A piece of wire would work, but probably not what the design team had in mind. Now, what the design(ers) had in mind, I won't necessarily guess at. It seems to me that tying reset low would prevent the interface circuitry from working... that is, the device would be write protected, but it would also be read protected, so if it lost power you would have to physically be there to enable reboot. This would _not_ be ideal. No, I proved that by simply trying it. Logically, you make sense, but maybe that is why noone has gotten a typical ATA device to work this way in the years that it has been attempted. I proved that setting pin 1 to ground does _not_ disable read capabilities of the drive or the ability to communicate the Low-level hardware (BIOS). As one of my old high school math teachers kindly beat in my head, Sometimes 'PIAGO' is the only way to tell for sure! (PIAGO --- Plug it IN and Grind it Out) I'll try it with some other boards and ATA devices as soon as I get around to Syslinux'ing any of them, if noone else feels the desire to taking a chance on destroying some 7+ year old hardware. I find much of it by trash cans or at a DAV store for under $10, so I can afford to destroy one or two if it will benefit us. -- ~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] ANN: LRP Developer's Guide
On Saturday 09 February 2002 12:25, David Douthitt wrote: There is a new version of the LEAF/LRP Developer's Guide. Minor revisions really - a new section on notes about compiling the Linux kernel. Thanks David!!! -- ~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] Toys for the dreamers in all of us!
On Tuesday 12 February 2002 15:04, Serge Caron wrote: Hardware kits galore with a _real_time_ operating sustem: http://www.zworld.com/ Check out DeviceGate Development kits ! Pretty kewl, Other than the fact that Linux probably doesn't support the Rabbit2000? processor (that I know of) and the propietary C system they're using requires a Win32 OS. http://www.zworld.com/products/dc/index.html http://www.zworld.com/products/smart_star/index.html Sounds to me like QNX on a Win32 platform marketing through their own hardware. Maybe embedded SUN on Win32. I wonder why they don't offer something with a Transmeta chip? Neat, but not my cup of tea ;) thx -- ~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] Introduction: mds
Glad to have you aboard, welcome!!! :) -- ~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] SF changes TOS
snip for slashdot Re:not such a big deal (Score:2) by wendy on Wednesday February 13, @04:34PM (#3002999) (User #42400 Info | http://cyber.law.harvard.edu/seltzer.html) They're choosing to take advantage of the safe harbor provision for ISPs (DMCA section 512, not the anticircumvention rules). 512(c) immunizes ISPs from liability for postings of their users, provide they follow notice and takedown procedures including the listing of a designated agent. Even if they list an agent, service providers still have the option of refusing to remove material if they get a notice of claimed copyright infringement, and of taking their chances in court. The subscriber receiving a claim of infringement can also file a counter-notification asserting that the material is legally posted. end of snip I think anything run in the US is going to have this problem. Canadian would be great, but legally you can't contribute from the US to their projects as I understand it. Bad year for Open Source! -- ~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] Re: SF changes TOS
On Thursday 14 February 2002 15:45, Serge Caron wrote: As a Canadian citizen, I do not know what you are taking about. We have NO restrictions on cryptography and our copyright laws are pretty much in sync with the international community. snip Here is some dope on the Canadian Export Control List (http://axion.physics.ubc.ca/ECL.html). However, if you have specifics, I will have a lawyer research this. OK, thanks for that info. Around six months ago I was looking into helping a couple of Canadian-based projects and they implictely stated that due to the US laws on cryt., they appreciated the offer but wished to decline due to the possible conflict. Things may not be true for any other projects and they may have changed their minds, but since some of these laws have passed within the US I have to respect their concerns :) Thanks once again for enlightening my concern! -- ~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] Re: Standards and due process :-)
I would just like to thank everyone for this discussion. Due to limited examples and precise wording designed to be clear (but somehow let most of the information vague), I am finally coming into a more complete understanding of what was originally proposed, and what direction some developers would like to go. In a very basic sense, what is proposed is that the developers fully document _how_ and _what_ something is loaded, not to mention _what_ exactly is being used. A repository or port system would be used for each developers system, so users should not be confused to what will and will not work will this particular system and a clear direction to take when they need something that is not necessarily provided or capable or being done with the said existing system. I don't think anyone would argue that something clearly along these lines would best be implemented at _this_ point in time. I am most likely the common denominator to the general public among the developers ... I am not a professional programmer by any means, I just know enough to generally get done _what_ I am aiming for within my limited skills. I look forward to seeing the process and result of the vast and broad knowledge that exists within this group. It should be interesting and educational for me! Meanwhile, I'll be off doing docs, packaging, maybe a custom image, and the list (I really should think a little more before responding ... I make some real un-intelligent posts on a regular basis). Thx all! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] dachstein floppy with glibc 2.1.3
On Saturday 16 February 2002 10:40, KP Kirchdörfer wrote: snip some cool stuff It seems to work pretty well, with about 40k free on the floppy, I#m sending this mail booted from the floppy. I should have a testing version of Udhcp (server client) as a mini- replacement to dhclient and dhcpd up tonight and tomarrow. I have a little tweaking to do, but it is coming in ~22.7Kb which is much smaller than the other two packages. I think I've got all the support working, except aliased interfacing I'm still deciding the cleanest way of doing this, so a later release will have this support. At this time, due to the scripts, this is a Dachstein release due to the script config options. I'll try to get a general LEAF release pretty quickly too. Thanks Charles! It should get you some room for some packages that don't fit now and be almost as functional as what it is replacing. -- ~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] Announcing leaf-project.org site name.
Steven, I would just like to thank-you! Not too many people would do something like that. -- ~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] changes to FAQ docid_1400
I am submitting some changes/updates to the FAQ docid_1400 and feel that with the number of developers that it should affect, that approval via the list was the quickest and best way to make it available for changes and approval. Feel free to comment on the list or to me personally concerning this. ~Lynn start of FAQ # Dachstein It is easy to use, and will automatically configure machines on your internal network. Dachstein has built-in firewall/filtering and also provides a local DNS cache, which reduces your reliance on your ISP's server and can speed up internet access. The main drawback is the 1680K disk format, but the image is self-extracting, making it easy to work with. Oxygen This is a newer variation, and does not have as much of a following as the other variations. It was designed to be used not only as a firewall, but also as a network debugging tool or a system rescue disk. It incudes Data Disks which are really nothing more than disks with sets of packages on them, ready for loading into the Oxygen base system. Bering This is a new release, that unlike the other releases uses the newer 2.4.x kernel series and iptables for filtering and firewalling. Bering was based off of Dachstein, so much of the functionality is very similar between these two branches, though there is several notable differences between several of the packages and the network configuration (which was redone from scratch). The Shorewall firewall is built in for firewalling and filtering with iptables. Packet Filter This is another new release, that is not an actual release when considered on the bottom line. What Packet Filter really is boils down to more of an enclosure for other LEAF releases to run within. It offers a menu to select different networking and configuration options during the boot process that allows for loading different systems to be selected from on the fly. Network configuration test beds, a LEAF developer environment, and 5 to 10 minute rapid deployment network configuration are some of the primary uses of Packet Filter. All LEAF releases have been run on Packet Filter. It is probably noteable that Packet Filter is intended for more experienced LEAF users. ### end of FAQ -- ~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] LRP 2.9.8
Alright everyone, I'm coming to the point in the FAQ's that haven't been updated since around the inception of the LEAF site. My concern is with updating considering LRP 2.9.8 is LRP now officially an old release, retired, or active as far as this site (LEAF) is concerned? I realize many of us still use 2.9.8 and are more than willing to support it, but put bluntly, Eigerstein is now considered a old release as are other releases that are more recent than 2.9.8 . I just don't want it to be considered as recent or up-to-date simply because it isn't compared to any current releases that LEAF is supporting. Thanks for the thoughts, -- ~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] q regarding an ftp site for leaf-project.org
On Wednesday 27 February 2002 23:07, David Douthitt wrote: On 2/27/02 at 4:28 PM, Mike Noyes [EMAIL PROTECTED] wrote: The last consideration is licensing. David is using the MIT license, and everyone else is using GPL. From what I understand reading the iBiblio licensing page, only one license is allowed per repository. Sounds like I'm the odd man out, eh? :-) Naw, M$ will be using Oxygen ported to Win32 in the new WinRTR release though :O ...j/k I'd like to see each distro get a files area on ibiblio - that would solve the above problem as well. Each distribution needs some recognition; LEAF isn't one distro, it's a conglomeration. That is a good thought, and probably one reason many of the other similar projects are getting a lot of recognition w/o being nearly as versitile. I've seen some first time project browsers get rather confused with the conglomerate site, but I don't think breaking up LEAF would help any of us other than downloading and some documentation that is release specific. As you suggested, David, I think that might be to an advantage to everyone. When someone goes to a site that lists different single floppy embedded linux distro's, what is going to multiply the traffic to the LEAF site itself? possibly 4 out of 10 links back to LEAF! I'd like to think that many of the developers here truly deserve some recognition for the wonderful work they have done. btw, how's Solaris x86 working for ya??? It was a real dog here, but cheaper than a Sparc to learn on! -- ~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] q regarding an ftp site for leaf-project.org
On Thursday 28 February 2002 00:45, Mike Noyes wrote: This is where we disagree. I believe this is a single project with many releases/branches. ref. This I agree with, w/o necessarily heading in the same exact direction. D Douthitt wrote: I'd like to see each distro get: * Freshmeat entry * ibiblio directory * Linux.com entry in distribution listing... * Any other archives/collections... This sounds like a proposed split. It's exactly the opposite of what I've been trying to do. What happens when a release/branch is made obsolete by a new one (e.g. Eigerstein - Dachstein)? Do we create a bunch of new directories and records for each new release/branch? I belive this would lead to fragmentation. No new format to this site, rather each release taking the effort to update the proposed alternate _download_ mirrors such as Ibiblio, tucows, freshmeat, Dave Central, etc. Not a proposed split, but rather a defined release of the individual releases/branches that reside, are supported, and developed within the umbrella supersite that is LEAF. A split would occur when someone chooses to remove the support, development, sharing of ideas and methods, and ultimately the disk space of the individual part _from_ LEAF. I've seen David respond to a Dachstein question, I've seen Charles respond to a Oxygen question, and I know for a fact that almost everyone including myself has taken a stab at a LRP 2.9.4 or earlier question at some point in time. I don't think anyone has ever told someone that they couldn't use their package in someone else's branch if they wanted to. But I have seen someone create a killer branch to prove a theory. What I'm saying is, you can't download and use LEAF. You can download and use something (and many things) that were made possible directly from LEAF. LEAF is a conglomeration of seperate ideas, processes, and directions with a common ground and brotherhood and /or community. LEAF is a win-win project for the developers, by the developers. When I go to Walmart, I don't come home and say that I bought a Walmart; rather I say I bought something _at_Walmart_. The many things I buy at Walmart causes me to come back more often and explore what else I could get at Walmart and that I do. When someone finds _something_at_LEAF, they will know that it is not LEAF in the full meaning of the project, but rather one useful piece that makes up LEAF . They will also know that there is most likely more good things to try at LEAF. It amounts to name marketing through the sum of the individual, different pieces that the name contains. For the public growth of the project as a whole. I personally develop for LEAF, not just Dachstein, or Bering, or Oxygen, or branchX. I watch some other embedded distro's grow as well. Matthew Grant is doing a new WAN router thing according to his 'plains' website. You still can't write protect a FreeSCO disk and boot your machine. Coyote is pretty much a small harddisk distro now. BBImage has a real nice floppy disk generator using a 2.4.x kernel via CGI. PicoBSD might as well not even exist anymore. Solaris sucks on an i86, but rules on a Sparc. I develop for LEAF, and LEAF only. This is because I like the individual and sum of all the parts better than anything else available. The community is great too. Proposing a split? Rather, an idea to increase traffic and potential users back to the place we all call home. /soapbox and apologies to those of you who paid to download this -- ~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] Evolution as a project development model
Mike, Thank-you for the excellent reply and insight that explains much of the depth, experience, and respect that is rightfully deserved and displayed in this project :-) On Friday 01 March 2002 11:37, Mike Noyes wrote: At 2002-02-28 10:51 -0600, guitarlynn wrote: Gnome and KDE are single platforms that developers can write to. They use a monolithic development model for the base. Their base is then used as a resource to build things. Are different Gnome/KDE bases available to choose from? If not, they don't correlate well to our project. Yes, very observant, we all have our baseline to work from. I think all of our releases are showing that the baseline is not only being challenged now, but being lowered when compared to the limitations of the past. The only thing monolithic is the package repositories I can wait on seeing kde30.lrp for a while though :) snip of completely true statements that leave nothing to be said The acknowledgement and existance of LEAF affiliates assumes the position that you seem most concerned with, and the only seperation between release and affiliate here appears to be the opinion and process of the individual lead developer. Correct to some extent. However, most of our affiliates crate components (specifically firewalls) that our developers make use of when creating releases/branches. This means we don't have to create something from scratch, and allows for a faster development cycle. It also provides a synergy between the affiliated projects that is beneficial to both. It also benefits in vastness of scope that is unmatched in any other project or release/version/distro that I am aware of. Many others are very good products, but very limited in what you can do with them when compared. This is an extreme benefit to the project and releases. There are a couple of other levels of involvement. Pim van Riezen [1] decided not to join or affiliate with us, but he does participate on the mailing lists. Ken Frazier [2] decided he didn't want anything to do with us. That is disappointing to hear. I'm am in the process of attempting to use cish for some simulation in Cisco (hopefully). This shell could really add a compatibility layer to the project. I hope he wouldn't object to his shell being used with LEAF. David D has it packaged. If I remember right, Ken worked with Coyote for some time, his insight and different point of view would have also been nice! This sounds like healthy evolution to me. :-) You forgot one important thing that will prevent infinite release/branch creation. There are limited resources (developers/users) in our environment (LEAF). Mind share will prune the week eventually. Developer(s) will only work on a release/branch as long as they receive recognition of their effort. I see this every day on the SF support lists. Abandonment of unused projects is common. That is one reason I make an honest effort to try many different releases/products. Many of them fit a certain niche better than others. The sad part is that some of the more cutting-edge versions do not necessarily fit the most used niche, and end up not being used as often. This would be a good point to thank all the developers for their hard work and excellent products that I am happy to say are at the top of their niche's in respect to quality. snip of more sound reasoning 1. Use of evolution as a development model. 2. Tolerance for new ideas and differing opinions. 3. Full control by lead developers of release/branch direction and purpose. It appears to have promoted many excellent products and a very healthy, stable development community. As Charles admonished me earlier, I now do for you. Thank-you, Mike ;) All of our opinions/ideas matter. Whether you're a lead developer or project admin has nothing to do with the validity of your opinion/idea. Absolutely, however the effect of a project leader or lead developer having an issue would create far more effects to the community than myself. This does not mean that my opinion does not matter or should not be effective, but rather the people that primarily have made the larger contributions to the project should get the respect that they deserve for the time and effort that has made this possible. I intend this with exhaultion to these people, rather than any lack of self-esteem on my part or source of degrading demeanor towards anyone else. BTW, this reply took me almost two hours. Your post was very thought provoking. Thanks. :-) The reply was worth every minute you put into it, IMHO. Thank-you for extending your thoughts :-) -- ~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] q regarding an ftp site for leaf-project.org
On Thursday 28 February 2002 21:26, David Douthitt wrote: On 2/28/02 at 1:52 AM, guitarlynn [EMAIL PROTECTED] wrote: PicoBSD might as well not even exist anymore. I HAD to reply to this :-) Hehe, I figured this might peek some interest ;-) PicoBSD is now an official part of the FreeBSD distribution, and is included in the source tree. The web pages haven't been updated in a LONG time. There also are very few, if any, floppy disk images to download. The expected thing to do is download the FreeBSD sources. However, there ARE the older PicoBSD images, plus at least two floppy images that I've found based on PicoBSD. One is a cluster director - that is, it handles the initial requests to a cluster and doles out the traffic to the appropriate web server or whatever. So they are still developing PicoBSD, but simply not posting any updates even in the way of information to the project page??? I knew it had been included in FreeBSD, but I haven't loaded a late version. I have used OpenBSD and been happy with it, so maybe I should take a go at a later version of FreeBSD. I just figured they would keep a current changelog or something to that effect on their homepage. :-(. Solaris sucks on an i86, but rules on a Sparc. I heard that 2.6 was alright, but 7 and 8 are slow because they expect SMP. I can verify that 7 and 8 run very slow on i86! At the time it came out, there was very limited NIC drivers too. It is a great version to learn Solaris on in any respect and definately worth the experience, but not for a production machine. On a different note, have anyone come across a open source RIP simulator??? -- ~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] Slashdot article
On Monday 04 March 2002 10:02, [EMAIL PROTECTED] wrote: For those keeping score, it seems that a firewall article made slashdot and leaf-project is suggested in a lot the replies, as are several others. http://slashdot.org/articles/02/03/04/0047215.shtml?tid=172 It appears that Brian Boonstra made the first LEAF plug, and maintains that LEAF is his preference. Haven't heard from him in some time. :-) -- ~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] Slashdot article
On Monday 04 March 2002 15:10, Matt Schalit wrote: I hope our Docs are in order so we can refer them rather than have to repeat things we've already hashed out. If I get motivated this week, and I intend to, I'm going to work on JN's sshd, tinydns, and dnscache docs which should take about an hour or two, then move onto the Docmanager stuff. I got around 14 more FAQ's updated, formatted, and submitted over the weekend. 3 more are almost ready and pending author approval of the changes. Mike is more than buried right at the moment, a couple of days would have helped matters considerably with the load he has right now. The current FAQ's I've updated contain virtually everything up to and including Section 6. The five remaining ones I haven't touched included in that group with virtually require rewrites. -- ~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] Slashdot article
On Monday 04 March 2002 15:33, Matt Schalit wrote: guitarlynn wrote: I got around 14 more FAQ's updated, formatted, and submitted over the weekend. 3 more are almost ready and pending author approval of the changes. Way to go. It must have been pretty funny, reading some of the old stuff in there. I've used most of them, I just ghosted the mailing tists for a long time ;-) Let me know if you want some help on those last 5. I'm going to be tied up until around 10PM CST, so if you want to take a look at the following, it would probably help some people! http://sourceforge.net/docman/display_doc.php?docid=1420group_id=13751 http://sourceforge.net/docman/display_doc.php?docid=1431group_id=13751 http://sourceforge.net/docman/display_doc.php?docid=1432group_id=13751 These are the only ones that might need updating Section 7. The other two just need formatted to xhtml-strict ... no biggie. You can verify xhtml-strict @: http://validator.w3.org/file-upload.html I haven't looked at any in Section 7 and any later sections yet. Thanks Matt, and anyone else that wants to help! -- ~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] TS-req-HowTo / How Do I Request Help?
Any desired changes or is this acceptable to everyone to submit??? Thx, ~Lynn start of FAQ ## Q. If I want help troubleshooting a connectivity failure with my LEAF router, what information you you need from me? A. The exact information needed will vary by what trouble needs shooting. As a general matter, exact quoting of error messages, log entries, command output, and such, is better than your trying to paraphrase or summarize them. 1.0 Introduction As always in life, especially when you have just pulled your last hair out, there are several things to check and do before asking that might save you a post that is archived on the web for the rest of your life that hasn't jumped out at you yet. Or you simply are not familiar with the LEAF/Linux system yet and need some more information to help you realize exactly what to check and understand. I highly suggest following some, if not all, of the preliminary self-help steps before posting. Do a Google search on Guitarlynn some time, and within the first 5 hits of the search I can guarentee a very embarassing thread on a mailing list that happened many years ago. I would like to see everyone get a working system without any embarassing side-effects like that! In fact, it will most likely get you a correct answer to your problem in a much faster time frame by helping us help you in this manner. The instructions in this document apply to SourceForge support requests, and troubleshooting questions asked on the leaf-user mailing list. 1.1 Acknowledgements We thank the following people for their corrections and suggestions: Ray Olszewski, Charles Steinkuehler, Jeff Newmiller, Gary Shea, Michelle Konzack, Wayne Fool, Jonathan French, Michael Leone, Dave Emmons, Bill Pierce, Chris Hill, and Paul Batozech. 1.2 Distribution Policy A copy of the license is available at: http://sourceforge.net/docman/display_doc.php?docid=1812group_id=137 51 2. Things to do Before Posting Read all available documentation on the site where you obtained the LEAF disk image, or files you are using. Check the FAQs at: http://sourceforge.net/docman/?group_id=13751 Fix all known bugs - see FAQs Section 05: Fixes for Known Bugs Subscribe to the LEAF mailing list at: http://lists.sourceforge.net/mailman/listinfo/leaf-user This is not necessary, but it is the polite thing to do. Optional: Search the LEAF mailing list archives at: http://www.mail-archive.com/leaf-user@lists.sourceforge.net/ This may take some time and effort. If you're not familiar with search engines, you may find this difficult. However, in most cases it's faster than asking list members for help. 3.0 Preparing a Post When preparing a post, keep in mind that you're asking for free technical support from people. They have no vested interest in helping you. So, it is to your advantage to make it as easy as possible for them to help, by including all appropriate diagnostic information. Also, be aware that other people's machines are not the same as yours. If your post is formatted correctly, some of the most knowledgeable people (UNIX gurus) will be able to read it. The following is a list of things to keep in mind: Keep your lines under 80 characters, and under 72 if possible. Sometimes it is necessary to include lines longer than 80 characters. You can accomplish this by using \ to continue a line. Example: averylongcommandthatyouwanttosplit \ intomultiplelinesforpostingtothelist \ sothatotherpeoplecandiagnoseyourproblem Use plain ASCII text. Not all email clients can properly view styled or HTML text. Some will simply strip out the codes used for style/HTML text, while others will display the codes in the message and leave the recipient with a messy email message. In extreme cases (e.g. pine), the recipient will see nothing at all. - see http://www.expita.com/nomime.html for instructions The post should have an informative Subject line, with the important information near the beginning. Include all information in the body of the post. It is inappropriate to send attachments to the list. Please don't edit the diagnostic information in an attempt to conceal your IP address, netmask, nameserver address, domain name, etc... These things aren't secret. If someone wants to do something bad to you, they can get this information in no time. When you post files that include passwords, you should replace all password characters with the letter x. 3.1 How to Get Your Diagnostic Information Into a Post When asking for general help with routing or firewalling questions, you should ALWAYS include this information: the exact name of the LEAF distribution and version you
Re: [Leaf-devel] TS-req-HowTo / How Do I Request Help?
On Monday 04 March 2002 16:33, Mike Noyes wrote: At 2002-03-04 16:16 -0600, guitarlynn wrote: Any desired changes or is this acceptable to everyone to submit??? Lynn, Can I have another day to look at your proposed changes? Absolutely! Any comments, suggestions, or whatever are desired. It was sitting, so I thought I would ask. -- ~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] TS-req-HowTo / How Do I Request Help?
On Friday 08 March 2002 11:21, Ray Olszewski wrote: I like Richard's changes too ... except that he forgot to add himself to the Acknowledgements list. Lynn, would you do that before committing? (And, Lynn, thanks once more for starting and keeping the ball rolling on these updates. As you can see, even I manage to do some work here with sufficient goading, and updates will be a real benefit to LEAF and its user base.) Definately, and I'll squeeze Matt in there too wonderful suggestions and work everyone! The feedback and opinions can really improve an already great submission. *Side note, I just picked up a 2 week job starting Monday. I'll be a little slower for the next couple of weeks. -- ~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] How do I request help FAQ
Alright, the how do I ask for help FAQ is posted along with updates in all but 1 or 2 of the rest of the FAQ's up to Section 7. You can check out the new FAQ at: http://sourceforge.net/docman/display_doc.php?docid=1891group_id=13751 Thanks to everyone for helping put it together!!! -- ~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] How do I request help FAQ
On Monday 11 March 2002 03:46, Matt Schalit wrote: The section below needs a little more work. The syntax shown will overwrite forward.txt. It is fixed, thanks!!! And I request again that you add in ip route show /mnt/routes.txt and remove the netstat -rn, only because ip route show is on every distro (correct?) It is as of last week. Fixed as well. Mike, could you add the new revision I added to the website. Thx! -- ~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] Embedded Systems Conference
On Saturday 16 March 2002 01:01, Matt Schalit wrote: Mike Noyes wrote: Everyone, This is a summary of yesterdays browsing of ESC. I had a good time, and I met Ray, Larry, and Matt. Well that's a meager summary :) Mike and Matt, Thanks for the summaries and links to products. I interested in finding some of this stuff, though my $$$ are pretty lacking right now. The Crusoe boards sound great if I can find some with 2+ ethernet under $500I'll check with the linked companies, they sound rather promising! There is always something nice about meeting someone you've never seen after years of communication, with I could have gone myself ;-) -- ~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] Embedded Systems Conference
On Saturday 16 March 2002 16:06, Mike Noyes wrote: Matt, We talked to him about ten minutes before your arrival. From what I understood of the conversation, he was suggesting the use of a free port/signal line (parallel and serial ports were discussed) on the motherboard to switch the state on the ADM. This is still hardware based, but is now switchable using a remote interface. His remote software authentication suggestion was snmp or pgp based. I think what we are hoping for is a jack for a mouted switch (either internal or external) to turn the WP on or off manually. It would be nice to be able to do it remotely, but in all cases that is no better than deleting the mount command during init. PGP is supposed to be dropped from development now (open source anyway). GPG would probably be better, but if going that route, maybe RSA/DSA would be the most secure route. -- ~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] Oxygen Installation Guide
On Sunday 17 March 2002 09:26, Mike Noyes wrote: Everyone, I'm seeking a volunteer. :-) Would someone like to create an Oxygen Installation Guide? What kind of scope do you want with it? Just for future reference, on the top of my todo list, I plan on doing a IPSec Quick-Start FAQ, a PacketFilter Quick-Start Guide, and later on a Zebra FAQ (that would likely be used with Oxygen). I won't say that I am the best person to do a well-rounded Oxygen Guide, I think Matt and several others has much better experience than I do with Oxygen. -- ~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] Dachstein port forwarding FAQ
On Monday 18 March 2002 19:47, Ray Olszewski wrote:
Excellent idea, Lynn, and good first draft. I suggest a few edits.
(I've pulled them out, but left your doc at the end for reference.)
Thanks Ray, I am going to learn to re-read these things before I
post ... or atleast spell-check them. ;-)
Here is a new copy with Ray's suggestions
## start of FAQ
Q. How do I port forward a service through my Dachstein firewall to
the my internal network?
A. There are four steps to port forwarding in Dachstein. They are as
follows:
1) Edit /etc/modules and uncomment the IP_masq_portfw module.
Save the file and exit. You may need to download this module
and copy it to /lib/modules on your running LEAF system if you
are using the floppy version.
2) Edit /etc/network.conf to open the desired external port you would
like to to forward with one of the two available options:
# TCP services open to outside world
# Space separated list: srcip/mask_dstport
EXTERN_TCP_PORTS=0/0_www
# -or-
# Indexed list: SrcAddr/Mask port [ DestAddr[/DestMask] ]
#EXTERN_TCP_PORT0=5.6.7.8 domain 1.1.1.12
EXTERN_TCP_PORT0=0/0 www
Use only one of these two forms of entry. If you use both, only the one you
use first will have any effect. Whichever one appears second in the file
will be disregarded. Be sure that the one you are not using is commented
out with a # at the beginning of the line.
You can use either the actual port number itself (for example, 80), or you
can use the symbolic name for the port that appears in the file
/etc/services (in the same example, www).
3) While you're editing /etc/network.conf, you will also need to specify
the port forwarding itself. You do this with:
# Uncomment following for port-forwarded internal services.
# The following is an example of what should be put here.
# Tuples are as follows:
# protocol_local-ip_local-port_remote-ip_remote-port
INTERN_SERVERS=tcp_${EXTERN_IP}_www_192.168.1.1_www
#-or-#
# These lines use the primary external IP address...if you need to
# port-forward
# an aliased IP address, use the INTERN_SERVERS setting above
#INTERN_FTP_SERVER=192.168.1.1 # Internal FTP server to make available
INTERN_WWW_SERVER=192.168.1.1 # Internal WWW server to make available
As with Step 2, you can use one of the options or the other of these options, but not
both. I suggest using the first option, since all ports and addresses
are explicitly stated and you can use different ports coming into and
forwarded out of the firewall. It also allows more
flexibility for using non-standard ports.
I personally use port 81
for my external web-services, but use port 80 on the internal network.
The first syntax allows for forwarding the external port 81 to the
internal port 80 with a line like this:
INTERN_SERVERS=tcp_${EXTERN_IP}_81_192.168.1.1_80
After you are finished with the configuration here, save the file and
exit the editor.
4) You are now finished with all the configuration. You should now
the lrcfg menu system (if you are not using it already) and choose
the backup option. You will need to backup the etc and modules
packages. After both of the packages are backed up, exit the menu
system and reboot the Dachstein machine. Your new port forwarding
setup should now be operational.
# end of FAQ
--
~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] net-snmp.lrp startup problem
On Tuesday 19 March 2002 21:52, Matt Schalit wrote: Matt Schalit wrote: Bino Oetomo wrote: Dear All. I just tried to use net-snmp.lrp. it's in Oxygen packages directory. I use it with DachStein image. Other people have had issues with this version with Dachstein. There is a new, tested version that works at: http://leaf.sourceforge.net/devel/helices/ -- ~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] Upgrading Bering to libc 2.2.x?
On Wednesday 20 March 2002 15:40, Simon Blake wrote: I have a vague memory of somebody explaining to me that that the reason that 2.2.x is so much bigger is because it has a bunch of backwards compatibility stuff in it to allow binaries linked against 2.0.x to continue to work. So if one was to go through and rebuild all the binaries in bering against 2.2, then the 2.2 could be cut down to a size not too much bigger than the current 2.0 libc. But I could be on crack. I investigated libc 2.2 when it first came out and all pointers to the bloat was support for both 32-bit and 64-bit processors. If you could drop the 64-bit support out of the source you would likely reduce a huge amount of compiled code (this may be a config option). I could be on crack myself though, this information was skimmed from a similar discussion on a libc newsgroup post. -- ~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] Upgrading Bering to libc 2.2.x?
On Wednesday 20 March 2002 17:23, Charles Steinkuehler wrote: Dang! There goes my alpha version of LEAF...I guess I'll just have to keep my resident Alpha systems running RedHat 7.1 busy crunching seti@home work-units (I've got 5 DEC Personal Workstation 500a's, three actually running). I can't say about the Alpha's inclusion to this statement, being that they have been supported for quite a long time. The 64-bit support bloat that was referred to seemed to be geared towards the upcoming Intel and AMD 64-bit processors. It was just something I found while perusing the net on the subject. I was just given a couple of old IBM RISC workstations. I'll have to figure out something to do with those. If I ever get back to LEAF development work, I'll look into the newer glibc. One of the first things I want to do is build a portable compile environment, and other than the compiler itself, the c library is about the biggest part of the puzzle, (as well as the biggest single chunk of code in most LEAF distributions)...I'd like to see what (if anything) can be done to squeeze the c library down to size, including various compiler options, as well as compile-time defines. Ah, you're a braver soul than I ! ;-) -- ~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] Basic IPSec HowTo
}. The connection names in the sample /etc/ipsec.conf used earlier would be roadwarrior and subnet-to-subnet. 12) TROUBLESHOOTING The output of a few commands can be the best source of information if your VPN connection does not work. The results of: Tell you: - ipsec barfVirtually everything about what is happening and what has happened with ipsec. cat /var/log/auth.log Authentication success and failure messages. ipsec look, route -n, and ifconfigShows a connected tunnel through interface ipsecX. ipsec auto --status Shows the status of the connection. Look for authentication failure or success with ipsec barf and/or the /var/log/auth.log file. A failure in these files usually indicate that port 500 and/or protocols 50 and 51 aren't making it through the firewall or your authentication key is not setup properly. If the authentication was successful, check ipsec look, ifconfig, and/or route -n. You should have an interface ipsec0 up with the external interface's ip address and a route showing the remote subnet/host via the local default gateway or your ISP. Failure at this point would indicate improper ipsec.conf configuration or port 500 not allowing traffic. The contents of /var/log/messages will show denied packets at the firewall check for any denied packets at port 500. If these commands do not help you locate the problem, monitoring the firewall activity will be the next source of information. Use the command ipchains --zero and note the output that refers to port 500 and protocols 50 and 51 or use a packet sniffer, while attempting to initiate a VPN connection. 13) LINKS LINKS TO BE ENTERED HERE ### # end of HowTo ### -- ~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] Dachstein port forwarding FAQ
If everyone is not bothered by anything contained in this FAQ,
I'll format it and submit it to the docmanager in the next day or two.
Thanks,
~Lynn
## start of FAQ
Q. How do I port forward a service through my Dachstein firewall to
the my internal network?
A. There are four steps to port forwarding in Dachstein. They are as
follows:
1) Edit /etc/modules and uncomment the IP_masq_portfw module.
Save the file and exit. You may need to download this module
and copy it to /lib/modules on your running LEAF system if you
are using the floppy version.
2) Edit /etc/network.conf to open the desired external port you would
like to to forward with one of the two available options:
# TCP services open to outside world
# Space separated list: srcip/mask_dstport
EXTERN_TCP_PORTS=0/0_www
# -or-
# Indexed list: SrcAddr/Mask port [ DestAddr[/DestMask] ]
#EXTERN_TCP_PORT0=5.6.7.8 domain 1.1.1.12
EXTERN_TCP_PORT0=0/0 www
Use only one of these two forms of entry. If you use both, only the
one you use first will have any effect. Whichever one appears second
in the file will be disregarded. Be sure that the one you are not
using is commented out with a # at the beginning of the line.
You can use either the actual port number itself (for example, 80),
or you can use the symbolic name for the port that appears in the
file /etc/services (in the same example, www).
3) While you're editing /etc/network.conf, you will also need to
specify the port forwarding itself. You do this with:
# Uncomment following for port-forwarded internal services.
# The following is an example of what should be put here.
# Tuples are as follows:
#
protocol_local-ip_local-port_remote-ip_remote-port
INTERN_SERVERS=tcp_${EXTERN_IP}_www_192.168.1.1_www
#-or-#
# These lines use the primary external IP address...if you
need to # port-forward
# an aliased IP address, use the INTERN_SERVERS setting
above #INTERN_FTP_SERVER=192.168.1.1 # Internal FTP server to make
available INTERN_WWW_SERVER=192.168.1.1 # Internal WWW server to
make available
As with Step 2, you can use one of the options or the other of
these options, but not both. I suggest using the first option, since
all ports and addresses are explicitly stated and you can use
different ports coming into and forwarded out of the firewall. It
also allows more
flexibility for using non-standard ports.
I personally use port 81
for my external web-services, but use port 80 on the internal
network. The first syntax allows for forwarding the external port 81
to the internal port 80 with a line like this:
INTERN_SERVERS=tcp_${EXTERN_IP}_81_192.168.1.1_80
After you are finished with the configuration here, save the file
and exit the editor.
4) You are now finished with all the configuration. You should now
the lrcfg menu system (if you are not using it already) and
choose the backup option. You will need to backup the etc and
modules packages. After both of the packages are backed up, exit
the menu system and reboot the Dachstein machine. Your new port
forwarding setup should now be operational.
# end of FAQ
--
~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] Dachstein port forwarding FAQ
On Thursday 28 March 2002 01:42, Matt Schalit wrote: You probably caught this one already, but if not, you're missing a word in the second sentence of para 4. Thank-you, Matt, once again... it's fixed. Many thanks for all that you've done to help the cause. You've really done a lot since you joined up. ty ;-) I've learned so much from this project over the years, that it seems natural to give back so that others can do the same. -- ~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] Admin script help
On Saturday 13 April 2002 13:14, Mike Noyes wrote:
Thanks. This works fairly well. I still get errors from tar, but I
don't see any way to force it to ignore them.
Try:
Examples:
$ ./package-date.sh test.txt 21
To something like:
#! /bin/bash
find leaf/ -iname *.lrp |
while read file ; do
echo `basename $file` $'\t' \
`tar tvzf $file 21| awk '{print $4}' | sort -n | tail -n 1`
$'\t' \
$file;
done |
sort
Now all I have to do is get the program name and version. Then
determine the libc version with ldd.
Jeff provided this snippet for checking the libc version with ldd.
I added a line to check for the version # to the script:
md ${package}
cd ${package}
gunzip ${packagelrppath}
ldd `ls bin/* sbin/* usr/bin usr/sbin usr/local/bin usr/local/sbin`
\
| grep -v ':$' | sort | uniq
awk '{print $1}' var/lib/lrpkg/${package}.version
cd ..
rm -R ${package}
I'll have to take a look at each package to determine program name
and version.
var/lib/lrpkg/package.help
var/lib/lrpkg/package.version
Any suggestions for accomplishing these tasks are appreciated.
Thanks again for the help. :-)
--
~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] Admin script help
On Sunday 14 April 2002 11:53, Mike Noyes wrote: Jeff Lynn, Thanks for the help. :-) Jeff, I modified your script, and added Lynn's awk line. I hope I didn't muck it up to bad. Looks OK to me if the output is correct. Everyone, Is there a reason that our packages don't contain the program name in the version file? The majority of packages seem to work that way I imagine that they were done this way since you should already know the 'basename' to check the version #. The package listing you're making would be the first time that we've had a good reason for implicitly putting the packagename in the version file. Adding: echo 'basename $1' should give the packagename if you want that in the output as well. I've been looking at the ldd output, and I'm having a hard time figuring out how to determine glibc versions from its output. The best I've come up with is to look for the presence of libm.so.6. Is that correct? libc.so.6 was used as far back as libc-2.0.x from what I could find. I couldn't locate if it was actually in libc-2.0.x or backported from later release of libc for compatibility. Anyone that has worked making any libc-2.1+ packages probably knows. -- ~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] Package description file proposal
Who determines what keywords and categories apply to each package? I believe these tags will cause confusion if there is no set categorization template. Maybe there should be one file templated out with certain information, like source version, package revision, packagename, glibc-required, maintainer, etc put a space/comma seperated line similar to the LRP= line in syslinux.cfg for the repository. This would be easily parsed by awk for administration of the list... but this would require strict adherance to the template format to work. Version: 1.20-1 upx is not version 1.20-1 but version 1.20 (at least in this example). In your example, why did you indicate a release level of 1? Is the release level different than the hyphen would indicate? It would indicate to me that it uses the same compliled source-code, but the package scripting (for .lrp) has been revised/patched. This will likely happen on occasion since the package maintainer does add scripting for use with LEAF. -- ~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! --- -- ~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] RC-1 image of IPSec-enabled Dachstein available
During the last several weeks of testing, my IPSec-enabled image of Dachstein has not received any reported bugs. I have now posted a new image (with a couple of minor non-functional changes and the updated udhcp.lrp). There shouldn't be any more functional changes unless the I use Chad Carr's ported ipsec scripts and eliminate the need for the ifconfig and mawk packages. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/guitarlynn/dachstein-v1.0.2-ipsec-1680.bin?rev=1.3content-type=text/vnd.viewcvs-markup Find me some bugs -- ~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] new lcd.lrp package
I've taken Charles' binaries and created a package for use with lcd's using the hd44780 controller (and some clone) chipset's. Init script is included and the package includes /etc/lcd.conf which contains all needed configuration options. It is available at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/guitarlynn/lcd.lrp 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
[Leaf-devel] Updated Udhcp package
I've updated the udhcp package with the server's default lease time that is more acceptable to Win2K/XP clients and modified the client init script to 'release' a lease and quit (rather than re-starting after releasing the lease). The general LEAF package is at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/guitarlynn/udhcp.lrp The Dachstein/mountain-series integrated package is at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/guitarlynn/udhcp.lrp.dachstein 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] new lcd.lrp package
On Friday 19 April 2002 02:22, David Douthitt wrote: I've been working on an lcdproc.lrp which contains LCDproc in its latest version. I included support for SVGA, ncurses, and MatrixOrbital LCDs. Is this yet another case of multiple developers crossing paths? I imagine so, other than yours will have a lot more options than mine does. I simply packaged Charles' binaries for lcdd and lcdproc and wrote some scripts to take some options for the HD4470 chipset. I wasn't aware there was already a package for this, so I just released the one I was using. Yours sounds a lot more functional. Thanks! :-) -- ~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] New VPN/firewall security solution
On Wednesday 05 June 2002 23:01, Steven Peck wrote: I believe this is it. snip In brief, it appears to be a way to establish secure end to end communications across NAT and the Internet specificcaly using the UPnP standard proposed by Intel. Though SSH doesn't come out and say this, they are basically the same idea. NAT causes problems with multiple clients doing the *same* thing at the same time. Say like multiple IPSec connections on port 500 leaving the NAT'ed Gateway. What is proposed here is a Nat-D type added to the approved header method (tunnel and transports are the current standard types). The Nat-D header would indicate the presence of a second added header that includes the port number used by the machine requesting the service (IPSec for instance). With this NAT'ed port information added to the packet payload, the gateway(s) will be able to indentify and decode the second header and send it to the exact machine that requested the information (identified by the port the connection was initialized on). Although this may not be the best method proposed to deal with NAT, this is a very easy method to implement and will work on all NAT and Proxy machines that will support identification and routing suggested in the docs. In special cases such as the iSCSI network storage devices, this can be built directly into the device driver eliminating the need for encryption by a processor because it is built into the device (driver) itself. What advantage it would give to us at this time would amount to faster thoroughput times and automatic resetting of dropped tunnels, assuming that FreeS/WAN supports the changes in any case. -- ~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! ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Development Annoyances...
On Wednesday 26 June 2002 16:24, Michael D. Schleif wrote: This is pretty much where Serge Caron came in with `enclosures' . . . at least, part of his enclosure construct does exactly what you describe . . . I use it for early package development. It's nice to simply delete the update(d) package and have a clean system again. I'm using a PacketFilter box in production as well the connection auto-detection and hardened system is pretty much 'boot and forget' depending on your particular use(s). There are some very interesting things in there ;-) -- ~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! --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Weblet-webconfig
## Moved from (leaf-user) # On Wednesday 26 June 2002 17:33, Richard Amerman wrote: I currently have a modification that has a new list of all the configuration files on the left side. I have included all the main networking files, modules file, ppp files, and all of shorewall. I did this with a combination of index.html modification (including some cleanup, primarily with an added style entry above that took out all the remaining style info bellow) and some changes in the showlogsx cgi scripts. Very nice, Bering is setup nicer in this way. DF's network.conf really needed to be chopped up to be cleaner in the end. I'm modularizing the configuration which can reduce the total space taken up and also allow for reduced (auto-)backup time/resources. I am planning to look at something along the lines of SSL for authentication or a SUID binary, but I haven't researched into how feasible this would be. In any regards, some form of authentication needs to be implemented. I plan on setting up a demo box outside our firewall that everyone can access to check out these changes. I will let the list know when I have this set up. Neat, let us know! ;-) -- ~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! --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Weblet-webconfig
On Wednesday 26 June 2002 19:13, Richard Amerman wrote: Thanks for moving the thread Lynn! np I actualy did set up the config dump. I now have two new links, one that gives you a single page with all the major configuration files from /etc and another for all the Shorewall files. These two lists are hardcoded in the scripts so it is a temporary hack. I would like to directly link these to the packages so that they are dynamic. I would also like to make the initial page more dynamic, move it from a static page to a seperate script. I think that is along the lines of my thinking as well. Reguarless of any changes to the weblet content it would be best to secure it. If it was secure, this would open the door to web remote management. Web remote management could start with basic control panel items including: Bringing interfaces up and down Bring Shorewall up and down I won't release anything that is not secured via authentication. This would cause more problems for the project than what the ease of administration would be worth IMHO. In curiousity, being that you are a little further along with your project, would you mind checking out stunnel for authentication possibility. Someone is using it, but I haven't researched it (yet). A quick look would indicate that it could (should) be compiled statically. The dependancies look huge though. http://www.stunnel.org/ # Pre-compiled packages. http://www.s-me.co.jp/mosquito/mos3_2/packages/ From their you could eventualy edit the config files directly. I know this is facilitated fine with the config menus, but if there was a full web interface to LEAF this would open things up to a much wider audience. Well, my thought was to create and CLI config script or menu program instead of forcing direct edits with CLI. Something similar to the Install-scripts I was playing with: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/guitarlynn/scripts.tar.gz Have you had to make any concessions to get the conf files to write because of permissions? I've been expecting to have problems with the UID weblet runs with. If so, I imagine that you could still use the weblet's UID with 744 permissions. Any thoughts-experiences??? -- ~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! --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Weblet Enhancements
* be tunneled, not just authenticated. I am proposing the use of 127.0.0.1 (localhost) for use of web-config within the scope of allowed host(s) for Weblet/web-config and the use of zebedee for remote access through any other machine... LAN or WAN. The authentication is built into zebedee and ALL information is encrypted. On Friday 28 June 2002 08:42, Joey Officer wrote: Last night at home I wasn't sure if the message was even going to go through. Glad it did! I'm not very familiar with CGI, or really anything html (I can write 'hello world', that's about it!), but from my experience w/ mrtg, I was under the impression that it was Perl based. If this is the case, how would you run a similar type program? Any interpreted executable can be CGI, be it shell, perl, C, whatever. On Friday 28 June 2002 00:44, Richard Amerman wrote: guitarlynn, Did you ever spend any more time playing with mosquito and its webadmin piece? I'm now more up to date with some of the weblet discussions in the past few months. Yes, but it doesn't allow for configuration on the router itself and is written mostly in Jscript. This is not the direction I would like to take. On Friday 28 June 2002 00:16, Richard Amerman wrote: What if we modified the architecture of Weblet so that you can add standard plugins (in the format of the standard LEAF pachage format, LRP for now). Actually, with the packaging system the only hard part would be links from index.html. I did a bit of checking into alternitives to Weblet (by no means exaustive) and it looks like sh-htppd (weblet) might still be the best answer. The only other option I've found likely is thttpd if we are using compiled CGI scripting. I really do not think this will be necessary either. OK, that does it for now any ideas or other other thoughts??? ~Lynn -- ~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! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-user] Re: [Leaf-devel] Re: Software write-protect (Was: Re: [leaf-user] Floppies)
How about if you modify tinylogin to email [EMAIL PROTECTED] everytime the box is logged into??? -- ~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! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Web-config devel
As stated before, there appears to be several people doing preliminary work on modifying Weblet to be used as a web-based configuration tool in the LEAF community, but not limited to the LEAF developers. It would be safe to assume that at some point redundant work will be done to achive the same end result. It would seem to be logical to form a consolidated group of developers to work together on this project, so that 1) development would be faster, 2) each developer could focus on a particular piece of the code, 3) the finished product would likely be better and more portable in respect to LEAF itself. How (and if) a group to develop a web-config package should be formed and run within the LEAF site is questionable and any idea's and advice is appreciated for a direction to take. At the moment, the work that has been done has been considered to be an extension of the weblet package and/or sh-httpd. Personally, I find a Web-configuration product to be something that is it's own entity, and be treated as such even though extensions will be made to the present sh-httpd code and integration with weblet will be a safe assumption. Shell/CLI environment configuration will need to be availible and the finished package should be optional as a package to the LEAF release(s) used on. I think a dedicated CVS branch, a means of communication, a schedule, and a roadmap would be general requirements to a clear and efficient development cycle for such a project. Is there an existing way to do and or all of this within the present LEAF infrastructure? Thoughts??? -- ~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! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] sh-httpd weblet web-config
On Tuesday 02 July 2002 08:33, Charles Steinkuehler wrote: First, a point of order. In my view of the world, there are two major issues currently being discussed: snip I think it would probably help prevent confusion if mods to the web server itself refer to sh-httpd, while issues related to making html/cgi code to monitor or configure the system use the weblet moniker. Agreed, I attempted to clarify this earilier. I considered anything with configuration a seperate entity, but if Weblet is modularized the argument is moot. With that out of the way, I completely agree with the idea of forming a group to work on the weblet portion of the configuration problem. This can probably be done with very little effort completely within the bounds of the existing LEAF SF project. With a CVS directory somewhere in the existing LEAF tree, folks can share code and updates, and even developers w/o LEAF SF developer status can check-out code and posts diffs to the leaf-devel mailing list (much like the way the busybox list works...I've sent in several bug-fixes to busybox that got incorperated into the main code-base, but am not a registered busybox developer). I think the leaf-devel mailing list will work fine as a communications mechanism for now, and we can always make a new leaf mailing list if the traffic gets too high for the leaf-devel list (unlikely, at least for now). This is fine, I was making sure this was an approved method in accordance with the site admins. I can commit to help with the sh-httpd mods, and I think I can improve the performance of cgi scripts dramatically. I can probably help with a bit of the html/cgi scripting (ie general architecture and maybe solving any thorny scripting issues that crop up), but I don't have time to commit to a huge chunk of the project. I don't have a huge amount of time myself, but I can work on the core integration with the present Release(s) configuration to a script-based one. In honesty, I really haven't gone through much of the present CGI/Weblet scripts yet. If I can catch up with Richard's changes, I'll be happy to help in any manner there as well. It appears that I was working in a reverse order to everyone else... ;-) It looks like Richard's generally headed in the right direction with his mods to the existing html/cgi code, especially with the abstraction of the content. Has anyone else made much progress along these lines, or should work start on using Richard's framework to start building a web-config architecture? I think Richard is further along than anyone else with Weblet, I could contribute some form templates and some variable/conf file proposals as well. -- ~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! --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] sh-httpd weblet web-config
On Tuesday 02 July 2002 10:29, Charles Steinkuehler wrote: 2) authentication may be an issue, but maybe this would bloat weblet, especially if we still want to support floppies I'd prefer to avoid the authentication entirely with sh-httpd, but basic authentication may be required. Note that even if implemented, I wouldn't really consider this amazingly secure...it would simply be a way to provide some sort of password so Junior couldn't edit the firewall rules on a whim, enabling the latest [mal|share]ware program to work. I think any form of secure authentication, as well as any encryption or tunneling should be handled by a seperate program (ie ssh, ssl, zeebee, or similar). After checking quite a few options available, I believe IDE releases should use ssh tunneling since it is likely already being used and floppy images should use zeebelee for space limitations. The Weblet would be limited to localhost and all configuration would be authenticated via the particular tunnel program used. I suppose zeebedee could be used for everything, but I'm not sure how two tunneling programs would react to each other if used at the same time. This would also limit the security risk due to any code we produce. -- ~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! --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Hi, I'm new.
On Thursday 04 July 2002 10:21, Julian Church wrote: Hi everyone. I've been hanging around the leaf-user list for over a year now, and a couple of weeks ago Mike Noyes asked me if I was interested in joining the LEAF developers' group. Now I'm back from my holiday (Glastonbury music festival) I'm here to introduce myself. Welcome! As far as Linux experience goes, besides running LEAF at work, at home and at a few friends' homes, I've been doing a lot of reading over the past 6 months, to try to Learn Linux properly. Still, I feel very much like a beginner, especially compared with some of the people that seem to be involved with LEAF. Take a weekend and do a version of LFS (LInux from Scratch), you'll learn more from that than most people want to... quite a tool to learn about the Linux core and how it works together. ;-) I've been exploring the leaf sourceforge website to see how I might be able to help. Since my job has given me a fair bit of experience in writing, editing and converting technical documentation and I'm already quite familiar with DocBook XML, I was thinking that perhaps working on documentation for LEAF would be the best way I could help. Perhaps I should start by converting some existing docs, then take things from there. If you have suggestions which docs to start with, please let me know, otherwise I'll just dive in. Great, we can always use more help with the docs! I need to finish updating the FAQ's (sticky-note), but almost everything else needs to be updated to xhtml-strict (howto's, guides). Mike N can probably tell you where the updates are most needed. I really need to finish the FAQ's. Glad to have you aboard! -- ~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! --- This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Affiliates
On Monday 08 July 2002 08:55, Mike Noyes wrote: Mosquito From what I was able to glean from babelfish, it looks like Mosquito was purchased by a VPN company (SeSame), renamed to IPnuts, and was taken commercial. Does anyone have information on Mosquito development status? http://babelfish.altavista.com/urltrurl?lp=ja_enurl=http%3A%2F%2Fwww .s-me.co.jp%2Fnews%2F020516.html It appears that they now a cd-release for sale and have/working-on a 2.4.x kernel with VPN, SSL, and *SQL capabilities. I'd like to know what is going on since they are now commercially owned and we haven't heard from anyone since the buyout. Corporate Affiliates proposal: I'd like us to start affiliating with corporations. However, I'm unsure of the point where we should consider a company for affiliation. Do they need to provide code resources and a link back to us for consideration, or just a link back to us? Examples: * Echogent: fwlog.pl cgi-script, Echowall, ftp white paper, Scott Best is a project member. * SeSame: Mosquito image, various packages, Webadmin, and reciprocal link. * Bits Over Atoms: Reciprocal link to us. If they're gleaning LEAF GPL'ed code and charging for it, it would seem fair (fill in the blank). :-( Paying for Consulting and site setup is fine with me (I do a little of this), but sale of the software (and in particular closing of code) is quite another, IMHO. Consultant List proposal: I'd like us to create a web page with links or contact information of consultants willing to contract for LEAF installations. Should we use the linuxports.com site for listings, or something else? This sounds good to me. I really don't know how consultants could be qualified by the project though. It could be rather easy to get over your head in a short-term project. These proposals may not be good ideas, but I thought they should be discussed. Discussion is a good idea! :-) -- ~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! --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Affiliates
First of all, I would like to thank-you, kitakura, for updating us on your project and clarifying any assumptions that I made based on what little information I interpreted from various websites. TY :-) I offer my apologies for any false information/assumptions that I may have made! On Monday 08 July 2002 19:26, kitakura wrote: Packages in http://www.s-me.co.jp/mosquito/mos3_4/packages/ are GPL lisence.(and Other open source license decided by Auther.) WebAdmin is GPL. ( only japanese. a part is english) but, since we assert license, the user interface code of WebAdmin for [, such as VPN, ] a specific package is unacquirable in online. WebAdmin has the menu form which can be added. # And If not related to me, WebAdmin is used also for # firewall distribution of Japan in time. So, the only closed-source code is some form of VPN application that your distribution is using that is not easy to work around either! Good job! config.lrp is also my code. it is GPL.This can gather configuration file written .conf. I think that it is useful. Webadmin.lrp,config.lrp,rc.lrp ,etc.lrp and root.lrp can not use other leaf distribution ,since they are imcompatible. But other packages may be compatible with little modify,I think. A part of them includes code for Webadmin and rc.( but they are gpl.) Great! But when webadmin is upgraded, a license may change. I'm sad to hear that, but this is difficult to avoid when something goes commercially owned. # I'm developing kernel 2.4. It is going to use the linuxrc code of Bering. # I am thankful to many developers. This is where I was really concerned. Are you using Bering and/or Dachstein IDE code for sale-only products that do not have open code equivilents (ie... floppy-only free offerings) or planning to use Bering linuxrc code in something closed-source? I personally have reservations about these possibilities, when it is not 100% personal code in the particular application (not to reflect on any other developer with this opinion). I guess what I am getting at is this: How would you feel if I modified Webadmin.lrp and release it as a closed-source commercial offering? I not saying that this is what is being done... but rather looking at what _could_ happen at some point in the future. -- ~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! --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Affiliates
On Wednesday 10 July 2002 00:27, kitakura wrote: Don't worry. I am following GPL . Thank-you :-) I'm looking forward to seeing IPNuts succeed, and I appreciate your time and effort with my concerns. -- ~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! --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
On Wednesday 10 July 2002 19:41, Michael D. Schleif wrote: Yes, these are our (leaf) _cvs_ versions. However, how can a user select net-snmp v4.2.4 when my net-snmp version is 1.1? Well, the editor session that pops up during a commit can be avoided with the -m text switch added to the commit command... I use for notes based on the change(s) from earlier CVS versions of the same package. You can use this to differeniate between net-snmp v4.2.4, 4.2.5, and 5.0.1 (not to mention any other notables you would like to add). As I am working on doing, if you would like certain versions of the same CVS file(s) presented in a clear and special manner, simply link them from a web page that presents this information. What should I, joe-leaf-user, expect to find while perusing ViewCVS? Joe-User is usually looking for an exact package in CVS rather than aimlessly attempting to find something random. I think most major software groups use CVS from linked web pages as well. Right now, I'm only thinking about what goes under my devel/helices tree. How that gets tied into dcd, bering, or whatever, is another issue, which I've decided to ignore for the moment. Remember, this all started with your request to me to commit my net-snmp packages. I committed the LRP's only, and since I've begun to plan committing several other items. It's this planning that has me hung now; but, I'd really like to put that behind me ; I think you are doing the smartest thing by planning you tree. A good plan will save tons of time and effort at a later date by foreseeable circumstances. -- ~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! --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] dcd: cleanup issues ???
On Wednesday 10 July 2002 20:06, Michael D. Schleif wrote: Also, in standard dcd v1.0.2, what program uses /etc/rpc? NFS and SUN login. I think a few people are using this style of access on LEAF boxes. -- ~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! --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Location for scripts during startup
On Thursday 11 July 2002 14:36, Charles Steinkuehler wrote: weblet runs script to gather all package conf files (/var/lib/lrpkg/*.conf files) to generate the configuration display component in weblet (to replace the hard coded one in the Dev Demo now) We can add an init.d script to do this w/o any problem. weblet runs script to gather weblet addon package conf files (/var/lib/lrpkg/w-xx.conf files) and to regenerate its /var/lib/lrpkg/weblet.conf file to these addon config files This is probably something for the init scripts to deal with (if required). Maybe an added button on the form to reload the init script via svi. The idea here is to simplify the weblet system so that there is a small base dashboard (much like it is now) with the ability to add new components and manage them as easily as adding additional lrp packages. Any startup-time config should be handled by the init scripts (/etc/init.d /etc/rc?.d/), but a lot of the site content should probably be generated on the fly...this shouldn't be too CPU intensive if a proper directory structure for weblet add-on packages is created. There is a project in progress to do this already...see the Richard's e-mail and weblet demo site. Add a directory in the cgi directory for placement of the seperate package modules. The module can be added to a package or manually this way w/o messing with lrpkg. A simple script that retrives a module list with ls would probably suffice. I am really against simply using the existing lrpkg system for this config unless we can text-to-html cat file and filter the file for option=value into a form decently. This option sounds more like a re-write of text-to-html and doesn't simplify the base configuration as much as I'm hoping. -- ~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! --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Affiliates
On Friday 12 July 2002 12:31, Mike Noyes wrote: On Mon, 2002-07-08 at 15:45, guitarlynn wrote: Lynn, Thanks for the feedback. :-) I was hoping these proposals would generate more discussion than they have. I'd really appreciate additional feedback from our project members. I don't want to start affiliating with companies or create a consultants list, if it's going to upset our project members. Agreed, and my opinion certainly doesn't necessarily reflect anyone else's opinion. If they're gleaning LEAF GPL'ed code and charging for it, it would seem fair (fill in the blank). :-( Would you elaborate on this? How does it apply to the corporate affiliation idea above? Personally, I would be against something similar to a company taking a LEAF CD/IDE release, putting a closed-source web-configuration application on it, and selling it unless a large amount of the core distribution was also re-written. I am against adding one or two packages to a stock GPL'ed release and selling it as opposed to simply selling the package that they are offering. The current development of anti-virus/email-scanning for commercial use is an example of something that is fine with me they are selling their own code/package. IPNuts is quite fairly an entity of it's own right and the core is a highly modified LRP 2.9.8, which allows them the right to use it commercially (IMHO). My original concerns where over their use of LEAF VPN packages (IPSec, PPTP, CIPE, etc...) only on their for-sale releases and promoting these packages with web-configuration as the reason to buy it. If I interpreted the response correctly, they are not using LEAF VPN packages, but rather some other closed-source VPN program instead. My other concern(s), is their use of incorperating Bering and Dachstein IDE, CD-ROM, and wireless code into the sale-only products w/o making a similar product available for free (only the floppy is free and not in development anymore as I understand it). Any concerns over the use of Dachstein and Bering code in this way should be expressed by the respective authors. In closing, if your planning to sell code, then write it and sell what is yours (or largely yours) to sell. If your not planning to write much code, but need to make money, do it with consulting and the labor that you personally put in. I've sold a bit of consulting and LEAF installs, but never once have I thought of charging for the software. -- ~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! --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: is Bering GNU?
code that might happen to be included in one of the nasty Linux distributions available! Okay, I just found the developer.rtf and scanned the whole thing. Formidable task, but I only see part of the forest and none of the trees. I already know linux and there seem to be some very specific LRP details in there, but will it be done before it's out of date? I'm not saying produce a `./configure make make image` but if the environment for building the release was published, or easier to find, I'm sure there would be a lot more community support. At one point I kicked myself for not looking in CVS before, but when I got in there, was in disbelief -- no source, only doc. Ummm you haven't downloaded David D's development CD then? This would seem pretty obvious if you had actually read the Development FAQ or examined the authors' website that is linked from the download area. Are you saying that you install a Linux system, install all the source-code, hack all of it to your personal preference, compile it, install all of your customized changes, then complain to the Distro mailing lists and well-read LUGS that the end-result is not working like you intended AND that it is their fault that it is not working as you intended it? Sounds pretty moronic to me. So now I have problems with my image to resolve, why do those Belkin cards detect as reltek under RH but, none of the Bering modules will work with them??? Ummm... RH is not GNU and I wouldn't touch it. What changes have they made to the modules and auto-detection from stock GNU utilities? Are the RH modules possibly closed-source manufacturer drivers? Shoot, maybe you can reduce RH down to a single-floppy OS with complete development tools and compilers, include propietary modules, and get it all to work for everyone as they expect w/o any knowledge of the changes you made to get the floppy to work (you also need to account for any custom binaries changes that they may make to the system). How will I ever get my tulips back from my boss so I can test an image at home? Call him at home or run down to Best Buy and spend $10 on a Linksys LNE110TX card. This doesn't sound like a LEAF problem here. What am I going to do about making an image and quickly changing a few parameters (ssh host keys, network, firewall and other site information) or major structure (LaBera, ppp, ipsec, dns) without spending a ton of time hand extracting and compressing components? Use the included lrcfg utility like everyone else or write a better one or simply copy the necessary files to a GNU desktop (doesn't need to have compilers or anything like that) and create a package SRC tree and make you changes there (the GNU tar utility works great with the .lrp extension, I use it). I'm going to make my own distribution. reBering. Complete with scripts to mount and extract all the subcomponents, global configure, mix'n'match packages, compress and unmount. Great! Don't learn how to use something existing, just get mad and make you own. I be sure to flame you when I bork a custom binary and it doesn't work, or I can't find SRC for shell-scripts, or your documentation doesn't meet my expetations when I haven't even read it. Sounds like the best solution to me. Only I don't think I can call it GNU because since I'm in a hurry, I won't have time to reverse engineer the compile time options and source. I'd rather work on putting it on an eprom anyway. Not GNU, you must be incrediably retarded to think that I will ever let you develop something non-GNU after getting this far through this thread. Good God, you must be the core-of-all-evil for even thinking such a idea. You better have a complete SRC tree on there too with excellent (and compete) documentation. I think you know where all the source is, being that it has all been linked in this thread. Someone has already gotten LEAF to work off of an EPROM, but you would probably need to find the documentation and read it. In all sincerity, Bering is very cool. It could just be a lot better if it was more in the spirit of _encouraging_ open source development rather than barley qualifying, actually I bet if it was audited, it wouldn't pass. If there are scripts to tar and gzip a lrp package, why aren't they part of a tools.tgz right beside package_src.tgz and compile_configs.tgz next to the Leaf_UML packages and extraction instructions for odd archives? I know asking for doc is a lot, but maintaining a file of command lines used to make the binaries from source would be an excellent first step. I will also expect this in the /usr/local/src and /doc directory of your image. It should meet my expectations without any reading being necessary. You might what to start from the Bering documentation, it is the most complete documentation of any OS/distribution that I have been exposed to. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net
Re: [Leaf-devel] Affiliates
On Sunday 14 July 2002 14:20, Mike Noyes wrote: On Sun, 2002-07-14 at 11:43, John Klar wrote: Just some observations about my interpretation of the GPL. Perhaps they won't be terribly popular, but hopefully it'll make a few people *think*. [2] Pointing requestors to the upstream source is NOT good enough. The distributor is required to provide the sources THEY use. John, Would this apply to our packages (.lrp) also? If so, nearly all of our packages are non-compliant. If I recall correctly, source of packages only compiled (not modified) by us (LEAF) or the Linux Router Project were always pointed upstream. I think Mathew Grant was the only one to include package source along with .lrp packages he produced. AFAIK, in my understanding the SRC should be availiable where the binary is downloaded (linked is acceptable). Script is it's own SRC code. We've avoided problems by readily making the code available when requested (via mailing-list), though this probably isn't legal per the license. I believe all of Charles' packages are availiable legally since he links the src from the package download area of his site. The SRC does _not_ have to be available within the package itself. IMHO, you cannot restrict anybody from taking your GPL'd package and codistributing it with a closed source binary. There is nothing in the GPL that prevents your scenario as long as they honor the rules of the GPL, ie. providing source for all the open source bits that make up the distribution. Worse, if it is not apparent how to get that source from you, they can cause a lot of trouble. Wording your license to prevent this case is itself a violation of the GPL. Very true, I was simply giving my opinion and personal feelings, not a legal interpretation to the license. I am free to give my blessing and encouragement to whomever I want. I did not make this clear, which I apologize for. A company could very easily do something like this legally, but I would not encourage it. One more point to ponder. What if the whizzy closed source application were a piece of hardware? Would you object to Fred's Router Appliances, Inc. shipping a free copy of LEAF, including source and development environment with every box? Not at all. I believe the company is giving due credit to the software in this instance. If they claimed the software was entirely theirs, I would feel otherwise. I believe that the GPL states that you cannot modify existing GPL code and license it as closed-source. Again, this is my interpretation of the license and my opinion not withstanding anyone else interpretation or opinion. -- ~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! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
