[Leaf-devel] Re: [Leaf-user] Announcing official release of Dachstein-CD
Charles Steinkuehler wrote: The official release (v1.0.1) of Dachstein-CD is now available for download from the usual places: Time for me to get to work on Oxygen-CD; the competition's getting ahead :) Congratulations Charles! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: [Leaf-user] Announcing official release of Dachstein-CD
The official release (v1.0.1) of Dachstein-CD is now available for download from the usual places: Time for me to get to work on Oxygen-CD; the competition's getting ahead :) Congratulations Charles! Thanks, but Dachstein wouldn't be what it is without all your work. In addition to the many pieces Ewald got from Oxygen, I included several of your packages. IIRC, Lynx, bash, vim, tcpdump, rsync, many of the libraries, and probably lots of other stuff I'm not thinking of at the moment came directly from your Oxygen packages. Bash and vim (and the libraries to go with them) are especially beginning to spoil me...I go back to using ash/ae on some old systems I haven't upgraded yet, and I wonder how I ever managed. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] pfw.lrp v.0.94 - A Packet Firewall using ipchains
Matt: Heya. Some quick comments inline: Sounds good! I haven't checked echoWall on Oxygen yet, so good going. Thanks Scott, but they don't make it easy. There's no /etc/version or convenient uname switch so a script can determine what OS it's running on. Gah. I was wondering about that. The only thing preventing echoWall from running on Oxygen is that it needs a different gatping binary. Which we have, sure. Trick is to install the right one, either when the package is first installed via lrpkg -i or when it detects that it's being run for the first time. That I know I can detect. But now I need to consider how to detect the glibc version... Well I wasn't sure what you were going to release. I took a look at your website and it seems like you're making good progress at echogent.com from the looks of things. Heh. :) Our major release is on target for the end of the year. It's a personal VPN application called Kaboodle. It's designed to let average Internet users (ZDNet called them the clueless in a recent article; Dave Cinege's sobriquet for them was idiots) create a peer-to-peer VPN connection without needing to know anything about IP address, nevermind what their own is. The intent is to allow any TCP/IP app to tunnel across that connection, and so become point-to-point secure. Am starting with VNC, a personal favorite. It's a Windoze app, it's built in VC++, it's open source, and I'm working on the sourceforge website in my spare time (whatever that expression means, I cannot recall). It's a BSD license, and gawd knows I learned most of the basics from your rc.pf to begin with. :) Shucks. I don't know much from licenses, though. That's my brothers side of the family. Here's how I keep them straight: there are basically two things an open-source license speaks towards: can the code be combined with non-open code; can modifications be taken private into closed apps. The GPL says no to both. The LGPL says yes to the first, no to the second. The BSD license says yes to both. Playing fast and loose here, but AFAIK that's a good rule of thumb(s). Honestly I'm flattered that anyone's using it all besides me... I'm not. You made it very well. It's was cool of you to analyze all those inbound services and script them in the rules file. That's looks like a neat hobby. Have you announced if for any other os or just for LEAF users? If you haven't, that's an awful lot of succinct data on inbound services to hide at LEAF. Thanks! I should give it some more thought, perhaps release a more conventional tarball with a more conventional INSTALL script. Once I get the which-gatping-to-use issue settled, I should go for this. Quick question: when you start it up, does it blow away what was there by default, or will there be conflict? Yes it runs a global flush and clobbers any of the good work that Charles runs by default. Funny thing is, I always thought it was just called Dachstein, not Dachstein Firewall. Once I ran it, though, I realized that Charles had gone past a general router, hardened it, and added a lot of nice touches like dnscache, and load balancing. As I was near completion, I rolled it out for Dachstein, anyway. The ram-disk log partition is my favorite. I've had to reboot my ES2B router once a month because of the firewall log filling the ramdisk... Got to code some Java now for a break. Btw, do you have any idea why a Nessus scan of my firewall would say that port 0 is open to udp and tcp in the form a bonk attack? I have those ports blocked the usual way, so I'm thinking they're spurious report items. I didn't know there was a usual way to block those. That is, I didn't think the stock ES2B firewall rules addresses the non-standard port-0. I should check ipchains -ln the next time I boot sans echoWall... cheers, Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] pfw.lrp v.0.94 - A Packet Firewall using ipchains
Scott C. Best wrote:
But now I need to consider how to detect the glibc version...
This should do it...
GLIBC_VERSION=$(basename /lib/libc-*.so .so)
GLIBC_VERSION=${GLIBC_VERSION##*-}
...or better yet, follow that with:
GLIBC_MAJOR_VERSION=${GLIBC_VERSION%%.?}
Here's how I keep them straight: there are basically
two things an open-source license speaks towards: can the code
be combined with non-open code; can modifications be taken
private into closed apps. The GPL says no to both. The LGPL
says yes to the first, no to the second. The BSD license says
yes to both.
Playing fast and loose here, but AFAIK that's a good
rule of thumb(s).
Of course, there are MORE things than that. One of the most important:
GPL is viral in that any code that uses GPL-licensed code MUST be GPL
licensed; BSD licenses don't have that. The X Consortium caused quite a
stir when they tried to take X into the commercial realm as a
proprietary private product - which they could do under their license.
Under a GPL license, they couldn't do that.
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] pfw.lrp v.0.94 - A Packet Firewall using ipchains
Scott C. Best wrote: Matt: Heya. Some quick comments inline: Sounds good! I haven't checked echoWall on Oxygen yet, so good going. Thanks Scott, but they don't make it easy. There's no /etc/version or convenient uname switch so a script can determine what OS it's running on. Gah. I was wondering about that. The only thing preventing echoWall from running on Oxygen is that it needs a different gatping binary. Um, I thought I posted that, even with a working gatping, Echowall chokes on the lack of ipfwd. I don't know if it gathers the ip addresses or network addresses correctly, because I never could get anyone to compile ipfwd for me. Which we have, sure. Trick is to install the right one, either when the package is first installed via lrpkg -i or when it detects that it's being run for the first time. That I know I can detect. But now I need to consider how to detect the glibc version... I don't think you have to worry about glibc, just worry that the fixed gatping runs on Charles' os's. It should, being it has better c code. Well I wasn't sure what you were going to release. I took a look at your website and it seems like you're making good progress at echogent.com from the looks of things. Heh. :) Our major release is on target for the end of the year. It's a personal VPN application called Kaboodle. That's a good name. [snip] The BSD license says yes to both. That's very nice for simple shell scripts like ours. [snip] Thanks! I should give it some more thought, perhaps release a more conventional tarball with a more conventional INSTALL script. Once I get the which-gatping-to-use issue settled, I should go for this. I actually got 2/3 the way through a configure script that was going to generate a custom pfw (small, no comments). I got stuck when it got complicated with 3 or 4 nics. I don't have a network with enough real ip's to test everything thoroughly (proxy are, bridging). I decided my future was not trying to write the best firewall for linux with easy web based setup and monitoring. I have a killer app in mind, and I just wanted get pfw out so I could move on. Quick question: when you start it up, does it blow away what was there by default, or will there be conflict? Yes it runs a global flush and clobbers any of the good work that Charles runs by default. Funny thing is, I always thought it was just called Dachstein, not Dachstein Firewall. Once I ran it, though, I realized that Charles had gone past a general router, hardened it, and added a lot of nice touches like dnscache, and load balancing. As I was near completion, I rolled it out for Dachstein, anyway. The ram-disk log partition is my favorite. I've had to reboot my ES2B router once a month because of the firewall log filling the ramdisk... Got to code some Java now for a break. Btw, do you have any idea why a Nessus scan of my firewall would say that port 0 is open to udp and tcp in the form a bonk attack? I have those ports blocked the usual way, so I'm thinking they're spurious report items. I didn't know there was a usual way to block those. That is, I didn't think the stock ES2B firewall rules addresses the non-standard port-0. I should check ipchains -ln the next time I boot sans echoWall... I wasn't concerned about es2b rules, just a general question. Even rc.pf would have block any protocol to port 0, because it's not expressly allowed. So the default rules at the end catch it. That's how I noticed it in my pfw syslog entries. The www.vulnerabilities.com scan included port 0, and rule #56 or whatever caught it. So then I made an explicit rule to catch tcp and udp to port 0, and the scan still came back that it was susceptable to an attack using that traffic in the form of a bonk attack. My guess is that it's a bogus result. But I figure I need to analyze a bonk attack and get into some gory details if I want to be sure. Thanks, Matthew cheers, Scott ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Dachstein
Rocks. I just changed from Tel$tra cable to Optus@home cable, downloaded Dachstein RC2, and installed it fine. works a treat. I'll be making images for Tel$tra BigPond and Optus users, and replacing my earlier images on http://quarkau.cjb.net when I get back from camping next week. Regards, Hilton Travis ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] pfw.lrp v.0.94 - A Packet Firewall using ipchains
David:
Hey, thanks for the script idea. I'll try that:
GLIBC_VERSION=$(basename /lib/libc-*.so .so)
GLIBC_VERSION=${GLIBC_VERSION##*-}
...or better yet, follow that with:
GLIBC_MAJOR_VERSION=${GLIBC_VERSION%%.?}
Regarding the GPL, you make a good point. Not only can
GPL'd code not be combined (and then released) with non-open code,
it can only be combined (and then released) with *any* other code
if that code itself inherits the GPL license. Many other GPL
compatible open-source licenses, such as the Sleepycat license,
don't specify *which* license the new source code must be released
under, only that it must be open-source.
Again...I'm playing fast loose with the word combine
up there. The GPL FAQ (www.gnu.org/licenses/gpl-faq.html) dedicates
more than a few lines to what is the difference between mere
aggregation and combinining two modules into one program,
addressing details as low-level as the means one portion invokes
the other (fork, exec, pipes, rpc) and the semantics of the
communication.
Which, I don't believe, has hit the courts yet. It's
a question of legality that will eventually be presented to
judge. And that'll be an interesting event...
-Scott
Here's how I keep them straight: there are basically
two things an open-source license speaks towards: can the code
be combined with non-open code; can modifications be taken
private into closed apps. The GPL says no to both. The LGPL
says yes to the first, no to the second. The BSD license says
yes to both.
Playing fast and loose here, but AFAIK that's a good
rule of thumb(s).
Of course, there are MORE things than that. One of the most important:
GPL is viral in that any code that uses GPL-licensed code MUST be GPL
licensed; BSD licenses don't have that. The X Consortium caused quite a
stir when they tried to take X into the commercial realm as a
proprietary private product - which they could do under their license.
Under a GPL license, they couldn't do that.
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Announcing official release of Dachstein-CD
The official release (v1.0.1) of Dachstein-CD is now available for download from the usual places: slow: http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/ fast: http://lrp1.steinkuehler.net/files/diskimages/dachstein-CD/ http://lrp2.steinkuehler.net/files/diskimages/dachstein-CD/ There was a 'silent' release of v1.0.0 for internal use yesterday. Changes from the last release candidate include configuration tweaks (dnscache and ipsec), the inclusion of the ipsec binaries patched for x.509 certificate support, and fixes to a couple minor bugs (a problem with the POSIXness cut command, and setting custom backup destinations didn't work properly). With a couple minor updates to root.lrp, folks booting off floppy will need to copy the latest root.lrp to their floppy disk to get the updates. Otherwise, just pop in the new CD and re-boot... -- Changes from Dachstein-CD v1.0.0 to Dachstein-CD v1.0.1: -- Modified dnscache package configuration: listen IP changed to 0.0.0.0 127.0.0.1 added to allowed query IPs Fixed bug when setting custom backup destinations root version changed to 4.0.5 -- Changes from Dachstein-CD rc5 to Dachstein-CD v1.0.0: -- POSIXness cut fixed to handle regex and sed special characters as delimiters root version changed to 4.0.4 Updated README.txt Modified ipsec.lrp (now backs up all /etc/ipsec* files, allowing an /etc/ipsec/ directory or ipsec.*.conf for configuration include files) Added ipsec509.lrp (x.509 patched versions of pluto and auto) for folks using certificates -- Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] RE: [Leaf-user] Dachstein
I will, once one is available, but there was only an RC2 on the site a day ago... - Hilton -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael D. Schleif Sent: Saturday, 17 November 2001 11:34 To: Hilton Travis Cc: LEAF Users; LEAF Developers Subject: Re: [Leaf-user] Dachstein Hilton Travis wrote: Rocks. I just changed from Tel$tra cable to Optus@home cable, downloaded Dachstein RC2, and installed it fine. works a treat. I'll be making images for Tel$tra BigPond and Optus users, and replacing my earlier images on http://quarkau.cjb.net when I get back from camping next week. Please, consider a post-RC release . . . -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: [Leaf-user] Announcing official release of Dachstein-CD
Charles Steinkuehler wrote: The official release (v1.0.1) of Dachstein-CD is now available for download from the usual places: slow: http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/ fast: http://lrp1.steinkuehler.net/files/diskimages/dachstein-CD/ http://lrp2.steinkuehler.net/files/diskimages/dachstein-CD/ There was a 'silent' release of v1.0.0 for internal use yesterday. Changes from the last release candidate include configuration tweaks (dnscache and ipsec), the inclusion of the ipsec binaries patched for x.509 certificate support, and fixes to a couple minor bugs (a problem with the POSIXness cut command, and setting custom backup destinations didn't work properly). As always, this is truly superb stuff! Bravo, Charles !!! Couple questions, even though these items appeared in RC5: [1] What is the purpose of the ``leaf'' user? [2] Should /home/leaf exist -- provided that we agree that such an user ought to exist? -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: [Leaf-user] Announcing official release of Dachstein-CD
Michael D. Schleif wrote: Charles Steinkuehler wrote: The official release (v1.0.1) of Dachstein-CD is now available for download from the usual places: slow: http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/ fast: http://lrp1.steinkuehler.net/files/diskimages/dachstein-CD/ http://lrp2.steinkuehler.net/files/diskimages/dachstein-CD/ There was a 'silent' release of v1.0.0 for internal use yesterday. Changes from the last release candidate include configuration tweaks (dnscache and ipsec), the inclusion of the ipsec binaries patched for x.509 certificate support, and fixes to a couple minor bugs (a problem with the POSIXness cut command, and setting custom backup destinations didn't work properly). As always, this is truly superb stuff! Bravo, Charles !!! Couple questions, even though these items appeared in RC5: [1] What is the purpose of the ``leaf'' user? [2] Should /home/leaf exist -- provided that we agree that such an user ought to exist? Interestingly enough, logged in as leaf, I *cannot* su - root su: Incorrect password What gives? Trust me, I know the root password ; But, I cannot eliminate root login if I cannot su to root . . . -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
