[leaf-devel] SF site layout, addendum
I looked at the page's source code, figured out I wanted to append "/stable" ti the URL, but that page has the same unusable layout issues. -- Paul Rogers paulgrog...@fastmail.fm 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. -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] SF site layout
Apologies, but I'm not sure who to send this to. The Files area layout on SourceForge is all messed up. Way to the right there seems to be lists of versions, but a couple large buttons for IBM and WoW adverts are covering them up. The files are unreachable. I do hope somebody can contact the right person(s) to see to the proper layout! TIA! -- Paul Rogers paulgrog...@fastmail.fm 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 - The professional email service -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] The UnNamed One
I agree with Andrew's reasons for using LEAF. It has been my perimeter firewall for many years. However, by far, my preferred network architecture involves a perimeter firewall as a "standalone" box that does only that "first line of defense" job. I put some value on being able to Power-Cycle my perimeter firewall without overly disturbing the internal network. IMHO, that simplicity makes for more robust security. If I can't do the job that way, it makes me re-analyze my plan and see what I want to do "wrong". "Fancy" things, like poking holes through a perimeter firewall, may not always be wrong, but they certainly suggest a different architecture should be examined. Putting any sort of "development tools" on a perimeter firewall is always wrong, IMNSHO. So far, so good, but, yes, I concede there are more complex architectures that might be relevant in advanced cases. I know many places regularly junk old hardware, and being forced to use newer stuff can lead to the sort of hardware support problems Andrew has had. Personally, I put a value on the sort of simplicity to be found in the old hardware. "Uncomplicated" is a good thing. The requirement I have for saving an old box that can be "repurposed" to, say, a LEAF perimeter firewall is reliability, "it just works". At this point in time, a suitable old box can still be found if one looks for it. And in at least one case, I've donated an old classic Pentium box to the cause. It is behind my perimeter firewall where I accept a bit more complexity. For example, this workstation's iptables has something like 140 rules, more or less--it's very strict. One day my position may become untenable, but not yet I think. Until then I'll prefer the tried and true. IMHO, if my LEAF perimeter firewall still presents a strong, "impenetrable" first line of defense sitting there alone, it's just fine as it is. -- Paul Rogers paulgrog...@fastmail.fm 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 - Choose from over 50 domains or use your own -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] The UnNamed One
> The 2.6 kernel is that large, that a runnable _and_ useful floppy > version in the way we provided it with the kernel 2.4- based versions I'm not sure I understand why someone wants a 2.6 kernel to run a standalone LEAF/Bering firewall. Can't find an old box and needs the hardware support for a box that's entirely too powerful? ;-) -- Paul Rogers paulgrog...@fastmail.fm 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 - IMAP accessible web-mail -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] The UnNamed One
> > I'm still running Bering-1.2. > > Wow, that's a pretty old version. I suggest you better update due to > security reasons. I may give it some consideration after I get a chance to see 3.01 in action. I'm running a fairly restrictive internal firewall also. > The 2.6 kernel is that large, that a runnable _and_ useful floppy > version in the way we provided it with the kernel 2.4- based versions Oh, I understand that. I'm not suggesting a retrofit, just that a usable copy of one of the floppy-capable versions be kept online for downloading by someone who might need it. Just keep it around. > Maybe we create a basic bootable floppy version, where packages can be > added... But you've already got that in the existing/previous versions. Just leave them available is all I'm suggesting. -- Paul Rogers paulgrog...@fastmail.fm 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 - Access all of your messages and folders wherever you are -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] The UnNamed One
> That said I hope that both efforts will end up in a joint project, > which may (or should?) get a new name. Not only that it is based on a > 2.6 kernel and it marks the end of floppy-runnable versions, it shall I'm still running Bering-1.2. I would only wish that the floppy versions should be given the little amount of space they require to remain available on-line for someone who has reason to run that configuration in the future. > version we can reach. So it's a more open approach than we had with > Bering and Bering-uClibc. As may be, but that was very good work done. I always thought setup could have been easier in that old version and contributed some, I hope, helpful criticism from a new user's perspective, but I can't complain about it keeping me safe all these years--albeit I still find the need for an internal firewall as well. Based on my experience I've recommended it to a buddy, and I've almost got a v3.01 box ready to go for him--once I get a replacement for a presumably flakey NIC. > However, your suggestions are appreciated, they are easy to spell > and write, not to mention, that I'm living near the Kattegat and > Skagerag area :) They may be commonplace names to you, and may have sent chills down the spines of my long-ago ancestors, but I think they're fun to say. -- Paul Rogers paulgrog...@fastmail.fm 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 - Faster than the air-speed velocity of an unladen european swallow -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] The UnNamed One
> How about one of these straits: > Darwin Straits in Tierra del Fuego? I've always thought the Skagerrak & Kattegat were neat names. Maybe a bit wide, depending on how narrow one thinks a "strait" should be. -- Paul Rogers paulgrog...@fastmail.fm 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 - Access your email from home and the web -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Docs for the 2 NIC config
On Mon, 12 Oct 2009 10:10:24 +0200, "Erich Titl" said: > What exactly are you referring to? The 2 NIC setup is probably the > standard and the only thing I can think of is the assignment of ethXX > to a specific NIC. This is not a Bering issue but just the way Linux > addresses its hardware (it can be overridden later afaik). With NICs > this is typically determined by the sequence of driver loading, e.g. > if you have the e1000 driver before the e100 driver in you > /etc/modules file and you have both nic types in your platform, then > the e1000 will have a lower ethnn number. AFAIK within the same driver > the sequence is determined by the mac address of the NIC. Quite so. That's esentially what I found out from a message reply by Charles re Dachstein in searching the message base. Thing is, I've been running Linux for over 5 years. In the versions of modutils I use, derived from LFS, such things can be assigned by "alias eth1 3c59x" for example. I never ran across the "default case" before and didn't know it. If one HASN'T run across this before, then one needs to know it, since Bering doesn't seem to use aliases in its /etc/modules file. (MY firewall uses a modem, and Bering-1.2, because dialup is all I can afford.) I'm just suggesting that a few sentences like you wrote in the documentation would have been a big help, because I was stuck! -- Paul Rogers paulgrog...@fastmail.fm 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 - Or how I learned to stop worrying and love email again -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Docs for the 2 NIC config
Just setting up a Bering-3.1 for a friend, with 2 NICs (3C900, & eepro100). Had to figure out assignment to eth[01]. Looked in doc pack. Thought it strange that's the default config, but there's nothing in the docs about that. Aggressive searching turned up a MESSAGE from Charles in reference to Dachstein that explained most of it. Can I suggest the issue be covered in the canonical docs? TIA -- Paul Rogers paulgrog...@fastmail.fm 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 - The professional email service -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ 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
> 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
> 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'm just a Bering user, and not a kernel hacker, but I began programming
in 1966, so I've been around the block a few times. With that
experience,
my question would be, what significant benefits does the 2.6 kernel
provide to a minimalist system? I'm still interested in a firewall I
can
run from a write-protected floppy, always have been. It seems the 2.6
kernel is larger, which is a disadvantage. I wouldn't argue that, for
instance, the new locking & dispatching aren't improvements, but do they
remedy real problems for a LEAF implementation? It seems one branch of
hardware development is making small, motorless systems that would make
nice LEAF applicances, so we might need support for them in new kernels.
The 2.4 kernel brought us stateful packet inspection, and that was a
very
GOOD thing. I'm just unaware of a NEED for the 2.6 kernel at present.
> Maybe LEAF is a victim of the fact that it works so well, and as long as
> somebody helps getting the latest network drivers to work, all is well
That's a strong reason.
> Ceder - infection resistant
Cedar, actually.
I might suggest Saguaro or Ocotillo for the "barebones" tree. ;-)
Ginko - the ancient one
Araucaria - the impenetrable one ("Monkey Puzzle" tree)
Sequoia - the big one
Oak - the steadfast one
--
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 - Does exactly what it says on the tin
-
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
I am, have been, using Bering-1.2 to allow me to use the internet with some safety for (obviously) several years. It doesn't seem to be broke, and I've got other things to do besides update it. One of these days, perhaps... I also agree Bering is more useful than just as a firewall, and "framework" is an apt substitute. I'm not sure I agree with inclusion of the word "network" in the description, it should be more general than just a networking appliance. Bering uClibc can be "just the thing" for very small Linux systems. One of the thing I'm spending time on is building LFS systems. I needed a bootable small system on which to base its reinstallation on new systems. I did some work with Trinux, but in the end used a somewhat stripped-down Bering uClibc. I thought lrp packaging and package management was unnecessary for my needs, so retreated to plain old tarballs, for example. If this redirection proceeds, I'd suggest: 1) that LEAF installation have some useful intermediate points before the "full-up" system, e.g. without lrp packaging, etc., and 2) it would need an easy to setup and use generalized development environment so additional packages for some particular use can be easily recompiled for uClibc. -- 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 - Access your email from home and the web - 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
