Re: [leaf-devel] Bering uClibc with Kernel 2.6
> But sooner or later, floppy support will have to go anyway - since there > won't be any new systems that are shipped with a floppy. For embedded Who dedicates a new box to running a LEAF firewall with all the free old boxes around? ;-) "But seriously folks", for those who DO use old hardware the old drivers should work just fine. So it's really just a matter of forking, but keeping the older software available (and making sure it doesn't get bit-rot) for those who can, want to, and perhaps must, use it. > Don't get me wrong - I didn't like having to admit that we had to drop > floppy support (and if we find a way to continue floppies, we will - > simply because it will give us the extra incentive to keep things small > and avoid any kind of bloat). Yes, avoiding code bloat is a very good thing. (Look at Windows.) Even if floppies go by the wayside, one might imagine small, discarded thumb- drives taking their place. One is hearing more and more of small flash- based systems, e.g. OLPC, et al., but they generally have modest storage capacities. The most common mistake I've seen younger programmers make is assumption that everybody else has what they have, wants what they want, etc. They suffer from lack of experience and/or imagination. In my experience, if there's one statement one should NEVER make, because it is too likely to have to be "eaten", it's: "We'll never need THAT again, good riddance." -- Paul Rogers [EMAIL PROTECTED] http://www.xprt.net/~pgrogers/ Rogers' Second Law: "Everything you do communicates." (I do not personally endorse any additions after this line. TANSTAAFL :-) -- http://www.fastmail.fm - A fast, anti-spam email service. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
oops - sorry > Hi Nicol, make that "Hi David" sorry about that Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
Hi Charles, > Besides driver issues, another reason to migrate to a 2.6 kernel is > support for IPV6, which will become vastly more important in the years > to come, particularly outside the US, where the IPV4 address pool is > already beginning to be exhausted. Good point. I haven't had to touch it yet, but I guess sooner or later, we all will have to tackle that beast. > I can likely assist with the IPSec stuff. I have migrated a few sites > from leaf-based firewalls to minimal debian installs, using the new > IPSec tools (racoon and racoon-tool, in my case). I have a few more > sites that still run leaf and will need to be upgraded soon. A 2.6 > kernel based release with modern IPSec would allow me to avoid migrating > to debian (and rotating HDDs). That would be great. If you could help with IPSEC on a 2.6 kernel, and you don't have to migrate your LEAF boxes to something else, I guess we all win :-) > I don't yet have any real-world experience with IPV6, other than the > dropped IPV6 packets seen by anyone running a firewall...the nasties > have taken to using IPV6 tunneling to try and circumvent firewall rules, > as many routers block IPV4 traffic but have separate (and frequently > non-existent or less maintained) rule sets for IPV6. That's a good point - and something we should focus on as we're moving towards IPV6 (and no matter how hard we try to ignore it - IPV6 will be something all of us will have to face at some point). I guess we already have 6Wall - but I'm afraid I have no idea how up to date it is, compared to shorewall. Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
Hi Nicol, thanks for your feedback, > I had no trouble running the 3.1 release candidate with a static 2.6 kernel; Well, but doesn't a static kernel (I assume you mean that everything you needed was compiled into the kernel statically, rather than as a module) pretty much stand against everything that LEAF seems to stand for (which as far as I'm concerned, is being modular, making sure that people can use it to suit their needs, without having to set up their own build environment)? > also I found the "tinygentoo" embedded stage 3 environment to be useful for > compiling things to run there. Well, what's wrong with the build environment we already have (see http://leaf.sourceforge.net/doc/buc-buildtool.html )? If "what's wrong" with it is that it requires a separate box, and one cannot compile things on the box the packages are to be deployed on - that's by design, I'm not going to build a toolchain on an ElanSC520, which still is a very good box for most home users). Maybe it simply comes down to me not being a gentoo user, and not subscribing to the ideas that seem to be important for people who use that distribution (which is fine with me, as long as I'm allowed to have a different point of view). > Size is an issue. But if you're booting isolinux instead of fd, you can cram > all you want (like, the whole root.lrp and etc.lrp packages) into an initrd > and > just keep it as the root isntead of all that pivoting and remounting. I must be missing something. Last time I checked, isolinux was for booting from El Torito (i.e CD-ROM) images. If one is booting from CD-ROM, what difference does the extra size for a 2.6 kernel make? I guess a 2.6 kernel plus initrd should fit nicely onto a 2.88MB image, so booting off a CD is not going to be an issue. But I fail to see how a big monolithic initrd will help in any way, if one is already booting off a media that has plenty of space available. And I'm rather unsure how one would boot off a compact flash, using isolinux (and all the boxes I have to support boot off CF, and they have neither a floppy, nor a CD-ROM - so unless I misunderstood what isolinux could do, I fail to see how isolinux could help with booting an "embedded box" with LEAF. So far (to me) "embedded" with LEAF means boxes like the Soekris or PC-Engines boxes, possibly even the Nexcom boxes - even though they're not exactly embedded, being 19 inch rack mounts...). Maybe we're just using completely different hardware, which might explain the different focus (or maybe, I'm just missing your point - it wouldn't be the first time that I totally misunderstand something). But if I didn't totally misunderstand the point you're trying to make, I'll have to disagree - to me (even though my opinion only counts for the stuff that I do, and everybody else is free to hold a different opinion, and work on things I wouldn't be working on) LEAF is about creating a platform. The platform should serve as a decent and secure home/home-office firewall out of the box, but it shouldn't require too much work to turn it into something else. To me, that means the distro should be modular. To some (or so it appears to me) modularity seems to be a bad compromise, and optimization for the box that will be running the code is very important. To me, optimization is good, after one has identified a bottleneck. But optimizing just for the sake of optimization seems to be a waste of time to me. I guess those two schools of thought are not easily combined, so it sounds like a "gentoo style" branch might be called for, to suit the needs of some. If there are people willing to put in the work required, and those people are willing to share their results, I'm sure that will happen, and I'm also sure there will be users who will happily use that branch. After all, it seems very well in line with Mike's idea of an evolutionary development model, where different ideas compete with each other, and hopefully, the one that suits the user's needs best will prevail. Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erich Titl wrote: | Actually playing with e1000 for 2.4 reset me a little lately. Definitely | I am convinced that if LEAF wants to go on strongly we need to be on par | with other project which do similar work, e.g. 2.6 is a must. | | And for all your effort which point into the future here it is _WELL DONE_ I agree! Besides driver issues, another reason to migrate to a 2.6 kernel is support for IPV6, which will become vastly more important in the years to come, particularly outside the US, where the IPV4 address pool is already beginning to be exhausted. | One of my concerns in the 2.6 branch will be IPSEC, as now we need to | use the native stack. It appears that with using the native stack IPSEC | will be an application like any other, so we may have now the benefit of | using Strongswan's IKEv2 implementation :-) I can likely assist with the IPSec stuff. I have migrated a few sites from leaf-based firewalls to minimal debian installs, using the new IPSec tools (racoon and racoon-tool, in my case). I have a few more sites that still run leaf and will need to be upgraded soon. A 2.6 kernel based release with modern IPSec would allow me to avoid migrating to debian (and rotating HDDs). I don't yet have any real-world experience with IPV6, other than the dropped IPV6 packets seen by anyone running a firewall...the nasties have taken to using IPV6 tunneling to try and circumvent firewall rules, as many routers block IPV4 traffic but have separate (and frequently non-existent or less maintained) rule sets for IPV6. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1VUXLywbqEHdNFwRAi/sAJ0d/ZHMKLXR+ryRRT9v4GhXUw5rDQCg/TsQ 0SuTICfWv3CevIn3uCF8qQQ= =jG9Q -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Project description
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 | Everyone, | We seem to have agreement on a name switch from Firewall to Framework. I | think we can make this change now, and continue work on a description | for later adoption. Is this acceptable? | | Mike Noyes +1 Charles Steinkuehler +1 - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1VKmLywbqEHdNFwRAsBaAJ9VKykfr3K5JAwOQdC72ow7hlzcKwCgqARL SuVdVQF1EANNnbon0oIAeWQ= =vqMP -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
On Fri, Mar 7, 2008 at 3:56 PM, Martin Hejl <[EMAIL PROTECTED]> wrote: > Hi all, > > this is a little depressing. After spending years (and tons of emails) > discussing the need for a kernel 2.6 version of LEAF, there has been no > response on this list on the topic. Is somebody actually interested in > continued work on that image (and has just not had an issue with it what > I've posted last Saturday), or did I scare off people with my too > verbose email, or is there just no interest, as long as somebody > provides the drivers for the hardware people need? I had no trouble running the 3.1 release candidate with a static 2.6 kernel; also I found the "tinygentoo" embedded stage 3 environment to be useful for compiling things to run there. Size is an issue. But if you're booting isolinux instead of fd, you can cram all you want (like, the whole root.lrp and etc.lrp packages) into an initrd and just keep it as the root isntead of all that pivoting and remounting. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Project description
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Mike Noyes > Sent: Friday, March 07, 2008 5:55 PM > To: leaf-devel@lists.sourceforge.net > Subject: Re: [leaf-devel] Project description > > On Thu, 2008-03-06 at 18:58 +0100, Martin Hejl wrote: > > > I agree with you, that the main usage scenario is to > build a network > > > appliance with LEAF and most of them also acting as firewall. > > > > > > Anyway I think it has grown from a "firewall" to a "framework". > > That's something I have no issues with - even though, that > seems to a > > change be the project name, rather than the description (the way I > > understand it, the current project name is > > > > "LEAF - Linux Embedded Appliance Firewall" > > "LEAF - Linux Embedded Appliance Framework" > > Everyone, > We seem to have agreement on a name switch from Firewall to > Framework. I think we can make this change now, and continue > work on a description for later adoption. Is this acceptable? > > Mike Noyes +1 Fine by me also Luis Correia - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel