Re: [Leaf-user] Testing help needed
Charles Steinkuehler wrote: > > As part of getting a final floppy version released, I have created (yet > another) new kernel tree . > > http://lrp.steinkuehler.net/files/kernels/2.2.20-1-small/ > http://lrp1.steinkuehler.net/files/kernels/2.2.20-1-small/ > http://lrp2.steinkuehler.net/files/kernels/2.2.20-1-small/ > > The existing kernels have problems with reiserfs, which combined with the > openwall patches seems to cause most loadable filesystem modules to fail > with unresolved module dependencies. Since I have to re-compile all the > kernels anyway, I'm making the jump to 2.2.20 at the same time. [ snip ] We are un-clear as to your plans for 2.2.x kernels ;> Since we have just overcome 2.2.19 issues with Sangoma wanpipe, which are all kernel version/re-compile related, we want to release the new wanpipe.lrp for state-of-the-state Dachstein-CD. Please, share your thoughts and plans . . . -- 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
Re: [Leaf-user] Testing help needed
> [ snip ] > > We are un-clear as to your plans for 2.2.x kernels ;> I just want a recent 2.2.x kernel that works. > Since we have just overcome 2.2.19 issues with Sangoma wanpipe, which > are all kernel version/re-compile related, we want to release the new > wanpipe.lrp for state-of-the-state Dachstein-CD. If the wanpipe stuff breaks again with 2.2.20, let me know. > Please, share your thoughts and plans . . . The existing 2.2.19 kernel trees won't correctly load some of the filesystem modules, which appears to be an interaction between the openwall patches and the reiserfs patch. After a bit of testing, I determined the best way to fix this is to simply drop the reiserfs patch, since I don't really have time to re-compile all the kernels, and I REALLY don't have time to start crawling through kernel code. Anyway, since I was re-compiling everything anyway, I thought I'd try to use 2.2.20, but this is not mandatory. If there are problems with 2.2.20, I can easily drop back to 2.2.19. While I specifically mentioned the VPN_MASQ patches, I'd consider the Sangoma support important as well. Let me know if it's broken in .20, if you have time to test. Fundamentally, there's nothing I'm aware of in 2.2.20 that's mandatory vs 2.2.19, once the security patches have been applied to the 2.2.19 kernels (which the latest 2.2.19-2 kernels have included), so I could go either way... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-user] Testing help needed
Is it just me that's wondering, but why do you need a journaling filesystem for a firewall that runs in RAM? I can understand (I guess) if you are using it for a stripped down server application like smtp server, or whateverbut I was under the impression that a journaling filesystem's best attribute was crash recovery because of the way it writes to disk. For a database app server, or smtp server, I can see the benefits. But, again, as a router that loads a minimal filesystem, why go to the bother? Later Tony > The existing 2.2.19 kernel trees won't correctly load some of > the filesystem modules, which appears to be an interaction between the > openwall patches and the reiserfs patch. > ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] Testing help needed
Am Samstag, 1. Dezember 2001 19:22 schrieb Tony: > Is it just me that's wondering, but why do you need a journaling filesystem > for a firewall that runs in RAM? I can understand (I guess) if you are > using it for a stripped down server application like smtp server, or > whateverbut I was under the impression that a journaling filesystem's > best attribute was crash recovery because of the way it writes to disk. > For a database app server, or smtp server, I can see the benefits. But, > again, as a router that loads a minimal filesystem, why go to the bother? You're not alone - I've been astonished too. AFAIK the advantages of journaling fs are related to the HD size, especially in case of an unclean umount and the necessery fschk. (This is at least what I've learned from IBM regarding HPFS and JFS) kp ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-devel] Re: [Leaf-user] Testing help needed
> > Since we have just overcome 2.2.19 issues with Sangoma wanpipe, which > > are all kernel version/re-compile related, we want to release the new > > wanpipe.lrp for state-of-the-state Dachstein-CD. > Fundamentally, there's nothing I'm aware of in 2.2.20 that's mandatory vs > 2.2.19, once the security patches have been applied to the 2.2.19 kernels > (which the latest 2.2.19-2 kernels have included), so I could go either > way... OK, I've just decided to stick with the 2.2.19 kernel tree. Changes from the existing kernel tree will consist of removal of the reiserfs patch, and an upgrade of the openwall patch to ow4, neither of which should cause too much trouble (I hope). This is the easiest thing for me to do, and sounds like it will help you out, as well. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-devel] RE: [Leaf-user] Testing help needed
> Is it just me that's wondering, but why do you need a journaling filesystem for a firewall that runs in RAM? I can understand (I guess) if you are using it for a stripped down server application like smtp server, or whateverbut I was under the impression that a journaling filesystem's best attribute was crash recovery because of the way it writes to disk. For a database app server, or smtp server, I can see the benefits. But, again, as a router that loads a minimal filesystem, why go to the bother? The sort answer is because I wanted to play with it :) With the fact that reiserfs killed ext2 support as a module, and the user-space filesystem tools won't compile against the older glibc used, this is rapidly looking like the proverbial *bad idea*, so the whole experiment is being shelved until I start on a disto with a 2.2.4 kernel and modern libc... There *are* a bunch of valid reasons to run a journaling filesystem on a thin server, and I do use my disto's for more than just firewalls, but for a router, JFFS is probably more important than something like reiserfs or ext3. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
RE: [Leaf-devel] RE: [Leaf-user] Testing help needed
Ah, I see. I thought perhaps I was missing something. > > The sort answer is because I wanted to play with it :) > I experiment like that also. Now I understand. I thought perhaps I had my head somewhere and missed a whole shift in direction with the filesystems. > There *are* a bunch of valid reasons to run a journaling > filesystem on a thin server, and I do use my disto's for more than just > firewalls, but for a router, JFFS is probably more important than something like > reiserfs or ext3. > And I agree. Like I said in my first post, if your machines are doing other things, especially with HD's, I see why you would want to use a JFS. I guess I don't completely understand why you need a JFFS for something that under normal circumstances, isn't written to physically. If you have a crash/powerdown situation, with resumtion of service, you just reload your image and continue to firewall/route. Would the JFFS be in play to preserve the logs? If so, wouldn't it be easier/safer/more secure to forward them to an internal syslog server? Again, I am not trying to critique, more just trying to understand why. Hell, if you saw some of the crap I implement just to try it, you'd think I _like_ frustration and extra work :-) Later, Tony ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-devel] RE: [Leaf-user] Testing help needed
On Sat, 1 Dec 2001, Tony wrote: > Is it just me that's wondering, but why do you need a journaling > filesystem for a firewall that runs in RAM? I can understand (I > guess) if you are using it for a stripped down server application > like smtp server, or whateverbut I was under the impression that > a journaling filesystem's best attribute was crash recovery because > of the way it writes to disk. For a database app server, or smtp > server, I can see the benefits. But, again, as a router that loads a > minimal filesystem, why go to the bother? > > Later > > Tony > Two reasons -- the filesystem might not be on a RAM disk, or you might want the increased performance for certain applications. A mail relay built on LEAF would be the perfect example for the first, you'd put the mail spool on hard disk because using a RAM disk opens the possibility that you'll accept mail and lose power before forwarding it, which will cause the mail to be permanently lost, which is against the RFCs. An FTP repository full of small files would be a decent example for the second; ReiserFS is optimized for work with lots of tiny files, so you could increase performance by using it on the RAM disk. -- Jack Coates Monkeynoodle: A Scientific Venture... ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
