[Leaf-devel] Re: [Leaf-user] Openssh 3.0p1 available
I hope those guys at http://www.openssh.org are not going to update their version every other day :-) But well this time, you got the latest one pretty quickly... As usual check: http://leaf.sourceforge.net/devel/jnilo Very cool... What mods (if any) were made when compiling these? When I compiled 2.9.9p2 it didn't link to libz dynamically...is this something you changed, or something on my system that's different than yours? 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] Anybody succes with initrd_dyn
Another point is that it will not get into the standard kernel as it seems, initrd_archive + linuxrc_always does not work either for kernel 2.4.9 so maybe its time to try something new like mounting a minimal real initrd first and creating a ramfs from that and putting the packages ... Using a 'real' initrd is my plan for the next major release...to save space, I'm thinking the floppy version could 'inherit' the contents of the initrd, while if you're running of a CD-Rom, HDD, or something else big you could ditch the whole initrd, and built a new root fs from scratch. Regardless, I think you'd build the root fs on /dev/ram1 or something, allowing you to dynamically configure the ramdisk size w/o having to change the kernel command line... 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-CD-rc3 available: bash.lrp error
I haven't tried bash.lrp since pre-release. There used to be two (2) bash-related problems; now, I find one (1): Mounting local filesystems... ramdisk.pkg: Uncompressing archives - log.tgz/etc/rcS.d/S36ramdisk.pkg: line 33: 1001 Broken pipegunzip -c $pkgdir/$pkg 1002 Done | qt tar -x -Finished. I'm not sure what is wrong here -- I do not see wrong with the scripts. log.tgz *does* get un-archived and bash is working. Nevertheless, this is some kind of error -- hopefully *not* to manifest itself elsewhere . . . P.S. I am using ramlog.lrp -- *not* ramdisk.lrp . . . I still don't know why this is happening...what happens if you run the script manually? (ie svi ramdisk.pkg start). There *was* a problem like this early on, reflecting differences between different busybox versions of gzip, if memory serves, but I haven't seen a problem like that for a while... 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-CD-rc3 available: bash.lrp error
I haven't tried bash.lrp since pre-release. There used to be two (2) bash-related problems; now, I find one (1): Mounting local filesystems... ramdisk.pkg: Uncompressing archives - log.tgz/etc/rcS.d/S36ramdisk.pkg: line 33: 1001 Broken pipegunzip -c $pkgdir/$pkg 1002 Done | qt tar -x -Finished. I'm not sure what is wrong here -- I do not see wrong with the scripts. log.tgz *does* get un-archived and bash is working. Nevertheless, this is some kind of error -- hopefully *not* to manifest itself elsewhere . . . P.S. I am using ramlog.lrp -- *not* ramdisk.lrp . . . I'm running bash (and vim) on my development systems here, and I have not seen this problem. Can you provide more details about your system: Hardware details (cpu, memory, NIC's, etc) Configuration (packages modules loaded from CD) Which packages you have local configuration information for on your floppy. I'm not sure what the problem could be... 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] Dachstein-CD-rc3 available
The third release-candidate version of Dachstein-CD is now available. This version feels like it's getting pretty close to done. Lots of minor chagnges, none of them show-stoppers, just getting everything working the way it should. This version is the first release that has actually gotten *SMALLER*, mainly due to the elimination of duplicate binaries in some of the packages, and the migration to busybox for some others. The iso image can be found in the usual places: http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/ http://lrp1.steinkuehler.net/files/diskimages/dachstein-CD/ http://lrp2.steinkuehler.net/files/diskimages/dachstein-CD/ HELP NEEDED! - I have tested the pppoe package on systems here, but I do not have access to a 'real' PPPoE account. I have created a test network using the roaring-penguin pppoe-server program, but I'd feel better if someone running PPPoE could test it as well. To run pppoe, make sure you're loading all required modules (typically slhc,ppp,ppp_deflate,bsd_comp, and slip), run adsl-setup to set your username password, and edit network.conf to use ppp0 for your external interface...that *should* do it (crossing my fingers :) UPGRADING: Manual changes are only required if you are using either ipsec or pppoe. Since I have stripped duplicate binaries into their own packages, you simply need to add the following packages to your pakcage list (typically /lrpkg.cfg on /dev/fd0) to satisfy dependencies: ipsec: add ifconfig and mawk pppoe: add ifconfig For those of you booting off the CD, just burn a new CD from the current image and reboot. If you're booting off a floppy, you need to copy the new root.lrp from the CD image to your boot floppy, as well as switch to the new CD. -- Changes from Dachstein-CD rc2 to Dachstein-CD rc3: -- Added init script to pppoe package Added RCDLINKS variable to ppp init script Added /etc/vimrc to vim package Enhanced POSIXness version of basename optional suffix parameter now recognized (required for PPPoE scritps to work properly) Removed several binaries from pppoe package: tty - migrated to busybox wc - migrated to busybox egrep- migrated to busybox echo - unnecessary...shell built-in used instead ifconfig - migrated to ifconfig.lrp route- migrated to ifconfig.lrp Removed several binaries from ipsec package: tr - migrated to busybox awk/mawk - migrated to mawk.lrp ifconfig - migrated to ifconfig.lrp route- migrated to ifconfig.lrp Replaced existing mawk.lrp (from David Douthitt's Oxygen) with mawk from my ipsec package. While my mawk is about 10K larger than David's, it does not require libm, which is huge... Added/fixed busybox functions: egrep - Now properly uses extended regular expression matching tr- added tty - added wc- added Fix syslinux.cfg on bootdisk image (. instead of , between dhclient dhcpd) -- 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] Dachstein-CD-rc2 available
The second release-candidate version of Dachstein-CD is now available. A couple minor but annoying bugs have been fixed, and I have added Kenneth Hadley's PPP and PPPoE packages, with hopes of getting PPPoE connections working (currently untested). The iso image can be found in the usual places: http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/ http://lrp1.steinkuehler.net/files/diskimages/dachstein-CD/ http://lrp2.steinkuehler.net/files/diskimages/dachstein-CD/ -- Changes from Dachstein-CD rc1 to Dachstein-CD rc2: -- Ramdisk package restored to initial version...ramlog retains the ability to extract tar.gz files from /etc/ramdisk/ Updated kernel to 2.2.19-2 with openwall patch ow3 fixes: Local DoS via deep symlinks Root compromise by ptrace(3) added pppoe.lrp (2.6) and ppp.lrp (2.3.11) from Kenneth Hadley EXPERIMENTAL ONLY AT THIS POINT! dnscache init script switched to use ash instead of sh, so UID can be set /bin/edit bug using bash shell fixed -- 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] Updated kernels available
The 'normal' and 'RAID' versions of the Dachstein kernel are now available with the updated openwall ow3 patch, which fixes the symlink DoS and the pthread exploit. As with the small kernel previously, the prefix has changed from 2.2.19-1- to 2.2.19-2-, and the Dachstein symlinks now point to the new version. The new kernels are currently available from: http://lrp.steinkuehler.net/files/kernels/ And the high speed mirrors: http://lrp1.steinkuehler.net/files/kernels/ http://lrp2.steinkuehler.net/files/kernels/ With the other mirror sites updating in the next day or two. 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-CD-rc2 available
The second release-candidate version of Dachstein-CD is now available. I forgot to mention...anyone wanting to upgrade from the previous (rc1) version of Dachstein-CD can simply switch to the new CD and reboot (keeping your existing config floppy)...no manual tweaking of anything required. To me this is one of the coolest things about running the CD release (that and it boots a lot faster than floppies :-) 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] New Kernels available
I have new kernels available, which include patches for a couple recent kernel bugs: http://www.securityfocus.com/cgi-bin/archive.pl?id=1mid=221337start=2001-1 0-15end=2001-10-21 The 'small' kernel tree, and the source for building your own kernel is currently available at my site, and should also be available from the higher speed mirrors. The new kernel trees are prefixed by 2.2.19-2-, as opposed to 2.2.19-1-. The Dachstein- symlinks now point to the new kernels instead of the older directories. NOTE: At this point, only the small and source trees are available. The RAID and normal trees will be available later today or tomorrow, as my sluggish P90 development system earns it's keep compiling non-stop for hours on end... The new kernels differ from the previous release only in the version of the Openwall patch applied. The previous version used the ow1 version of the patch, while the newer version uses ow3. In addition to a few minor changes to the openwall code, the new ow3 patch includes fixes for the two reported kernel bugs: Local DoS via deep symlinks Root compromise by ptrace(3) I also took the opportunity to enable compilation of the Racal ethernet drivers (as modules), so the three ni*.o ethernet drivers (ni5010, ni52, and ni65) are now available for anyone needing them You should be able to simply replace your running kernel with the new version...I doubt any modules will need to be replaced, but I haven't actually tested this... NOTE: To save room on my web-server, the old (2.2.19-1-*) uncompressed kernel directories have been deleted. The contents are still available as tar.gz files if you need them for any reason. 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] New Kernels available
I have new kernels available, which include patches for a couple recent kernel bugs: [ snip ] I notice that your site http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/CD-Contents/ indicates file change dates more recent than your original issue of Dachstein-CD, rc1: -r-- 1 1474560 Oct 19 11:11 bootdisk.bin -r-- 1 43858 Oct 18 17:11 dhcpd.lrp -r-- 1334739 Oct 19 11:31 ipsec.lrp dr-x 2 4096 Oct 17 19:16 lib/ -r-- 1754089 Oct 19 11:06 root.lrp Other than kernel updates, what has changed in these files from RC1 ??? Nothing has changed in these files from rc1: -r-- 1 18409472 Oct 19 11:32 dachstein-cd-rc1.iso Note the CD image is slightly newer than any of the included packages... I am compiling the new CD kernels now...I'll burn a new CD image when I get the new kernels compiled and fix the couple of known bugs, probably tomorrow. 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] Compiling busybox
I need to upgrade to the 0.60.1 version of busybox to fix a problem with the logger application, but I'm having some problems getting the insmod utility to compile properly. I get the following errors: gcc -s -Wl,-warn-common -o busybox cat.o chgrp.o chmod.o chown.o chroot.o clear.o cp.o date.o dd.o df.o dmesg.o dutmp.o fdflush.o find.o freeramdisk.o grep.o gunzip.o gzip.o head.o hostname.o id.o insmod.o kill.o ln.o loadkmap.o logger.o ls.o makedevs.o mkdir.o mknod.o more.o mount.o mv.o nc.o ping.o printf.o ps.o pwd.o rdate.o rm.o rmdir.o rmmod.o sleep.o sort.o stty.o swaponoff.o sync.o tail.o tar.o touch.o true_false.o umount.o update.o which.o busybox.o usage.o applets.o libbb.a insmod.o: In function `new_get_kernel_symbols': insmod.o(.text+0x1687): undefined reference to `query_module' insmod.o(.text+0x1748): undefined reference to `query_module' insmod.o(.text+0x179f): undefined reference to `query_module' insmod.o(.text+0x185a): undefined reference to `query_module' insmod.o: In function `insmod_main': insmod.o(.text+0x2dc4): undefined reference to `query_module' make: *** [busybox] Error 1 If I link with libutil.a from modutils, the error goes away (and busybox insmod works properly), but there's no mention of having to link against external code in any of the busybox documentation... Does anyone know why this is happening? I'm developing on a Debian Slink system with a 2.2.19 kernel. Busybox Config: // Support insmod/lsmod/rmmod for post 2.1 kernels #define BB_FEATURE_NEW_MODULE_INTERFACE // // Support insmod/lsmod/rmmod for pre 2.1 kernels //#define BB_FEATURE_OLD_MODULE_INTERFACE // // Support module version checking //#define BB_FEATURE_INSMOD_VERSION_CHECKING 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: [BusyBox] Problem compiling 0.60.1...external code required!?!
If I link with libutil.a from modutils (simply adding it to the end of the above gcc command), the error goes away (and busybox insmod works properly), but there's no mention of having to link against external code in any of the busybox documentation... Update: After a bit more digging, I found I can get everything to compile properly using only busybox code if I comment out the test for __GNU_LIBRARY__ 5 in libbb/module_syscalls.c I'm still not sure *why* I need to do this, but it works (and makes the binary about 5K smaller than linking with the library from modutils). Details on my C library: __GNU_LIBRARY__ 6 __GLIBC__ 2 __GLIBC_MINOR__ 0 Again, this is a Debian 2.1 (slink) environment... 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] Dachstein-CD-rc1 available
The initial release candidate of Dachstein-CD is now available in the usual places: slow: http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/ fast: http://lrp1.steinkuehler.net/files/diskimages/dachstein-CD/ fast: http://lrp2.steinkuehler.net/files/diskimages/dachstein-CD/ dachstein-cd-rc1.iso file There have been many changes from the latest release, primarily bug fixes, the addition of IPSec, and a newer busybox. While there are still a few things on the todo list, they are minor and mainly represent testing or features added for convenience. I am now using this distribution on my own router, and will be upgrading several other production routers to this version in the next few days. I even burned a CD-R instead of my usual CD-RW, so it's working pretty well :-) Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) -- Changes from Dachstein-CD pr2 to Dachstein-CD rc1: -- Added volume label and Joliet extensions to CD Modified /bin/edit script to allow override of default editor To change editors, simply: export EDITOR=your editor Replace busybox with version 0.60.1 fixes problem with logger uncovered in IPSec tests Added several busybox functions: chroot egrep freeramdisk grep head id sort tail which Removed POSIXness functions that transfered to busybox: grep id head sort tail IPSec 1.91 added and functional using ash or bash shell Removed extranious files from root.lrp: many extra busybox symlinks in /bin strange file in /var/lib/lrpkg (ctrl chars in name) Updated dhcpd to latest version added dhcpd.local file ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: [Leaf-user] New Dachstein-CD: strange file in root.lrp ???
All attempts to extract root.lrp to my nt4,sp6a box, via winzip8, *abort* _prior_ to completion with this error: ``Can't create output file: _PATH_\.\root\var\lib\lrpkg\root etc local modules ramlog'' *WHAT* is this file? Some wacky thing that probably got accidentally created when one of my modified scripts crashed, when I was re-writing/testing some of the backup scripts. Is it necessary? Nope. Is it necessary to be named thusly? Nope. What do you think? It should go away...it will be gone in the next CD release (coming RSN...I'm burning a test image now). 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] Dachstein-CD available
I had created my lrcfg file from the readme.txt file that I modified. At some point it became an MSDOS file. The symptom was that the last module in the list closest to the ^M, in this case vim, did not load. The ^M looked like a . in the edit editor. I am using etc:R,local,modules,ramlog,dhclient,dnscache,dhcpd,weblet,lncurses,vim in my lrcfg file simulating EB2. I'll fix this in the next release... There is a subtle difference between the 2.2.16 and the 2.2.19 module I was using for my ethernet adapter. In 2.2.16, I was able to just load eepro100. In 2.2.19, I also needed to uncomment pci-scan in the /etc/modules before the interfaces were brought up. This is due to the newer drivers in the 2.2.19 kernel. Newer drivers are generally (but not always) a good thing :) A difference between EB2 and Dachstein-CD is that a person also has to uncomment both ip_masq_portfw and ip_masq_autofw for NAT. Should all the ip_masq_ modules be uncommented by default like EB2 had them? This is an undocumented difference between the floppy and CD versions...see recent post to leaf-user...I'll fix this in the next CD release, and make it behave like the floppy version. Another difference between EB2 and Dachstein-CD, dCD is in the ip address used for the internal network. I am puzzled here. Both EB2 and dCD allow a person to have their /etc/hosts file created from a list of variables. In EB2 the router takes the internal subnet address when the /etc/hosts file is created. In dCD the router is assigned the address of 1.1.1.2. The only real difference I can see is that the EB2 /etc/network.conf uses 0.0.0.0 for eth0_IPADDR variable while dCD uses 1.1.1.2. I tried changing these eth0_IPADDR to 0.0.0.0 thinking the NAT rules were using this number, but /etc/hosts file has 0.0.0.0 for the router ip. Hmm...are you using dhcp? If so, the hosts file should get created with your public IP, not the 'placeholder' IP of 0.0.0.0 or 1.1.1.2. If it doesn't, this is a bug... weblet is not working. I tried a telnet myrouter 80 with a GET / HTTP/1.0enterenter operation. Before I could finish typing GET / the connection was dropped. The log file says sh-http refushed connection. My weblet configuration files are the same from EB2. The default Dachstein CD image is not setup to run weblet...I'll fix that in the next release... To fix it yourself, I think all you need to do is ad sh-httpd to /etc/inetd.conf 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] Dachstein-CD available
WOW! Too many great suggestions for me to comment on them all... Thanks for releasing the Dachstein-CD. I have had fun playing with it. I have not created a LEAF CD before so I may be able to provide some newbie impressions: Often the best kind...I like to know what people find confusing (or easy to use)... Since it is a CD and the current ISO is only 17M, it would be nice to include say a dosutils directory with rawrite.exe. Attached is a file called mkfloppy. It calls rawrite using all the correct command line arguments along with the bootdisk.bin file. Great suggestion! You describe three configuration options depending on if your BIOS allows you to boot from a CD. I believe bootdisk.bin will work for both one and two. I realize it would be overkill, but you could provide an image file for people transitioning from eigersteinbeta2. LOL I realize it would just have the lrpkg.cfg file with etc:R,local,modules,ramlog,dhclient,dnscache,dhcpd,weblet,lncurses,vim in it but it might make it easier for new people using the CD. Besides its nice going into lrcfg and seeing a list of packages to configure when you first boot the CD. Noted will be fixed... I thought it would be clearer to describe just one of the CD-ROM boot configurations at a time from start to finish. That way a user would not have to remember which variation he was trying to configure as he read--worked for me. ;-) Attached is a proposed README.TXT file with most of it this section rewritten. I don't believe the second configuration is complete. Thanks for the contribution...I'll fold in a lot of your mods... Moreover, I had fun playing with the image. I have documented many other tasks in the readme.txt file. I started a FAQ with one of the questions on the devel mailing list. One section is a quick how to on configuring a cd burner under Redhat. I even describe how to customize the image, but I appear to be boot challenged. LOL...my modified disk image did not boot after I added a dosutils directory, etc. I realize there are many ways and tools to create a boot able ISO image, but I would be happy, if there was a complete example under Linux. Would someone please look at the readme.txt and show me what is missing to make the iso boot? Did you use the mkisofs command I provided? If so, it *should* boot... I realize that the random number seed is not saved on existing LEAF systems. I am thinking this might be a security weakness (it might make it easier to guess sequence numbers, etc). Is there a way to save this seed on the config floppy as the system is halted or rebooted? Possibly...I'll think about how to do this... 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] Minor trouble with Dachstein release-candidate
Thanks for all your work with LEAF Charles. I tried your Dachstein RC and had a bit of trouble. I followed your instructions and entered my static ip info. On bringing up the network I got: Starting interface: RTNETLINK answers: Invalid argument. A quick search on deja pointed to a possible problem with QOS. I switched to the dachstein normal kernel and modules that includes the QOS code and all is fine now. I'm fairly certain I had the configuration correct because changing the kernel and modules fixed the problem. I didn't even change the net card module as I use a tulip based card. I'm not well versed enough in Linux or Eigherstein to troubleshoot any further than this. Sorry. Hmm...the Invalid argument error can happen for any of a number of reasons. It's quite odd that changing your kernel fixed the problem...nothing related to QoS is enabled unless you specifically set several network.conf varilables, and install the user-space QoS configuration tools. Can you possibly e-mail me a copy of your network.conf file so I can see if I can reproduce the problem here on a test system? 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] dachstein rc1 cd won't boot.
i have problems with the dachstein rc1 cd. The machine boots from cd, identifies the cdrom at hdd as ATAPI 2xCDROM and then cannot load the other packages (etc.lrp ...). it just says: could not mount the boot device can't install packages. I have not floppy inserted and no harddisk (now) in this machine... CS For some reason, the system is not automatically detecting your CD-Rom on /dev/hdd. I'll try to re-create this here and fix the init-scripts (if they're broken), but in the meantime, you can probably get going with the following procedure: Start with a blank floppy, or the bootdisk.bin image if your system won't boot from CD with a floppy disk in the drive. Create a file called pkgpath.cfg on the blank floppy. edit pkgpath.cfg, so it contains a single line with the text: /dev/hdd:iso9660 NOTE: This file may need a unix EOL...I'm not sure what will happen if the init script sees a carrige return as well as a line-feed...another thing to test :) 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-CD available
Just a note: If you are going to use bootdisk.bin instead of bootdisk.ima, please, replace all references to bootdisk.ima in README.TXT };Þ Doh!! I'll get it fixed in the next release... 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-CD available
Regarding /etc/network.conf, what are the differences between LRP-CD and Dachstein-CD? Or, are all of the differences in the other scripts that call variables instantiated in network.conf? I ask this, because I am interested in quickly converting several instances of LRP-CD to Dachstein-CD -- of course, *after* extensive testing -- and I need to gauge the amount of effort required to convert network.conf . . . In general, the Dachstein scripts are a superset of LRP-CD, which was based on Eiger. For upgrading, you have a few options: 1) Keep all of your existing configuration files. You *should* be able to simply replace the LRP-CD with a Dachstein-CD, and reboot, although you'll probably have to modify etc in the lrpkg.cfg file on your floppy to be etc:R, due to the new packaging scheme. The big drawback to this is you won't have the new network scripts, but there's nothing wrong with the eiger-based LRP-CD scripts, if you don't need the extra functionality. You may also need to be careful about packages with init scripts. If the init scripts changed (I think this only applies to IPSec) you may have to merge the changes manually. I will typically boot w/o loading my local config in this case, and manually unpack the config files to /tmp, then move them to the appropriate location. Of course many packages (like ssh) haven't changed at all, so you can use your old configuration w/o worry. 2) Migrate the configuration information to the new CD. This is mainly merging the contents of /etc/network.conf to the new network.conf file. There should be little or no change required to the variables in your existing network.conf...the settings should just copy over. 3) Re-configure the system from scratch. This really isn't too hard, but you'll loose things like your ssh host ID, and IPSec private keys (assuming you're using RSA keys for authentication). What I would probably do, on a per-package basis: bwidth22.lrp - No configuration needed dhcpd.lrp - Identical...keep existing config etc.lrp - create from scratch using Dachstein base old config files ipsec.lrp - manually copy old /etc/ipsec.* files to new package (when it comes out :) local.lrp - keep old config log.lrp - no config necessary modules.lrp - create from scratch using Dachstein base nmbd-207.lrp - Identical...keep existing config ramdisk.lrp - edit from Dachstein base, if required root.lrp - no config required...use the new one :) snmp.lrp - Identical...keep old config socks5-c.lrp - Identical...keep old config socks5.lrp - Identical...keep old config ssh-1.lrp - Identical...keep old config ssh1-key.lrp - Identical...keep old config sshd-1.lrp - Identical...keep old config update.lrp - Not required anymore...do not load So...take a look at etc, modules, and ipsec from a configuration standpoint, and edit your lrpkg.cfg file, removing update, changing etc to etc:R, and adding any new packages you want. I think that will do it... 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] Dachstein-CD available
I have released a preliminary version of Dachstein-CD. Based on Dachstein, LRP-CD, and extensive modifications to the backup scripts, it's getting easier than ever to boot from a CD. The files, and some documentation are available from my website: http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/ But if you're grabbing the CD image, you'll probably have better luck with the faster mirrors: http://lrp1.steinkuehler.net/files/diskimages/dachstein-CD/ http://lrp2.steinkuehler.net/files/diskimages/dachstein-CD/ The mods are described in the README file, and the new backup system should be pretty easy to understand. The big change is you can now select the desired backup type and destination on a per-package basis, making it easy to control the generation of full or partial (config information only) backups, and to save them to floppy, hard-disk, or where-ever. I'm headed out of town for a long weekend (back Wedensday), so I may not be able to answer questions immediately. Don't let that worry you though...the new system is much easer to use than the previous LRP-CD release, and I think anyone reasonably familiar with LRP won't get too lost. The main thing to watch is getting your package path setting correct (remember, the kernel parameter is overridden by the pkgpath.cfg file on your floppy...see the README). I don't have time to update my website to reflect the changes, so keep the links above handy for now, and get a jump on the rest of the world for being a LEAF list member! 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] Re: [Leaf-user] Dachstein release-candidate available
I have posted the first release candidate (rc1) of Dachstein on my
website:
http://lrp.steinkuehler.net/DiskImages/Dachstein.htm
Just today, I made a large number of changes in the weblet pages,
finally
I wish to raise a simple question. But first let me tell you that I did
not even look at the new weblet.
I use the weblet access to fetch files from the fw, not for visual
display but for automatic manipulation.
I always wanted a mode where the data comes down the wire with the
absolute minimal added html.
Can we add such a mode? Maybe a request flag that defines the level of
visualization one wants? This flag can be stripped up front, then the
request
processed normally, and these scripts that want to use it can refer to
it through, say, some environment variable that was set upfront.
Well, there are a couple of things you might be asking for, and both are
pretty easy.
If you would like access to files on the server, you can simply configure
weblet to serve up any file in the filesystem, and download anything you're
interested with a web browser or something like http-get.
If you want some of the status information made available via the cgi
scripts, you can pretty easily modify the scripts to return NO HTML
formatting. Simply change the mime-type returned by the cgi-script to
text/plain instead of text/html, and remove the HTML formatting from the cgi
script. You can either replace the existing cgi scripts with your new
versions, or give them a different name so you can access either version.
As an example, here is the original viewmasq cgi script:
#!/bin/sh
cat - /HTML-DATA
Content-type: text/html
HTMLHEADTITLE${0##*/}/TITLE/HEAD
BODY background=/images/lrpbkg.gif
H1LRP Firewall/H1
H2Masqueraded and Other Connections/H2
H3$(date)/H3
H3Masqueraded Connections:/H3
PRE
$(/bin/netstat -Mn)
/PRE
H3Other Connections:/H3
PRE
$(/bin/netstat -n)
/PRE
/BODY/HTML
/HTML-DATA
To convert the entire thing to plain text, simply strip the HTML tags out,
and change the content-type header:
#!/bin/sh
cat - /HTML-DATA
Content-type: text/plain
$(date)
Masqueraded Connections:
$(/bin/netstat -Mn)
Other Connections:
$(/bin/netstat -n)
/HTML-DATA
Of course, you can provide text seperators, whitespace, and other formatting
as required if you need to easily parse the data on the far end.
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] Dachstein release-candidate available
I have posted the first release candidate (rc1) of Dachstein on my website: http://lrp.steinkuehler.net/DiskImages/Dachstein.htm Just today, I made a large number of changes in the weblet pages, finally converting to the much more attractive pages designed by Justin Ribeiro. I also migrated the cgi-scripts to use the new layout. If there are any new bugs, they are probably in changes I made to the web pages, so please a close look at the weblet pages by all new Dachstein users would be appreciated. Note that the web pages are a fair amount larger, but I think the better look makes up for the extra space. Also, I added the java bandwidth applet for convinence, which is huge. If you really want to save space and make weblet tiny again, remove the .jar file and put the java application code on your workstation instead of the LRP system. Other changes: -- Changes from pr4 to rc1: -- e3 default mode switched to Nedit readme file updated to reflect changes to editor and new packages kernel and modules switched to dachstein-small (I think I somehow had ewald's kernel and/or modules mixed in) removed pr4 tag from firewall script headers removed unused /etc/e3.conf added shell /etc/POSIXness.conf for setting mail variables added /etc/POSIXness to /var/lib/lrpkg/root.sys.conf changed root version from 4.0.0 to 4.0.1 weblet pages updated to modified versions of Justin Ribeiro's page design cgi scripts updated to use the new format as well The following features were not added to this release: modifications to backup scirpts (deferred to CD-ROM version) There will be an entirely new packaging system for the next major release easily allowing traffic to external private IP space This is still possible by editing ipfilter.conf 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] Re: [Leaf-user] Dachstein-pr4 available
I have a somewhat dumb question, ok. How do I get this image onto a floppy. when I use dd of=/dev/fd0 if=dachstein-pr4-1680.bin ]$ dd of=/dev/fd0u1680 if=dachstein-pr4-1680.bin dd: /dev/fd0u1680: Input/output error 19+0 records in 18+0 records out -- any ideas? Did you format the disk for 1680K first, or are you using a 1440K pre-formatted floppy? The 1440K format has 18 sectors/track, vs 21 sectors/track for 1680K, so your 18 records out indicates it's highly likely you don't have sectors 19-21 formatted... Charles Steinkuehler [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Testing...
Please ignore...testing my all-new proxy-arp DMZ setup. The list was the handiest available e-mail reflector :) 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] lrpStat
I'm in the process of adding lrpStat to the weblet pages of Dachstein, and have a question. When I run the java applet in a web browser, it has a fixed size, specified as width and height in the applet tag. If, however, I run the application from the command line, I get a scalable window. Does anyone know how to get the applet to pop up in a scalable window when it's loaded from the web page? 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] lrpStat
Does anyone know how to get the applet to pop up in a scalable window when it's loaded from the web page? I guess it is possible already, by using javascript to bring up a new window (preferably without any navigation and URL toolbars), so it'll look just like one of those annoying ads that are part of some sites. As Etienne pointed out, in this case you'd have to use WIDTH/HEIGHT=100% in that case). If that's not sufficient, I could extend the applet to (optionally) run in a separate frame I've got the applet launching in it's own browser window, but it's still got the toolbars, menus, and such. If someone can point me towards some java-script to pop up a 'borderless' window, I'd appreciate it (I'm not much of a web design guru). (but let me know quickly, since I'll be on my way to the States for two weeks on sunday, so I won't be doing any work on that during that time). I guess there's not much chance of meeting anyboy in the Andover/Boston area over the next two weeks? ;-) Well, I don't know where everyone else is, but I'm in the middle of the country (Kansas), so you probably won't be bumping into me ;-) Basically, my idea was that the applet was included in a whole page of infos about the system (like, all the information that's displayed by the weblet pages), and the application was for viewing _only_ the network stats. That's how I'm configuring things...see: http://216.171.153.180 Assuming the system stays online...I don't know how weblet will handle being hit by all the nimda probes now that I've opened it up to the world... Let me know if there is something I should do - I would gladly do so. Heck, I already feel honoured that it'll be included in your dachstein release. I always wanted to include the stats package...sadly, this is the first time I've re-rolled a release since you got it running sigh. 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] lrpStat
Try this ( just modify the inital size width height ) Thanks...a slight variation of your code seems to do what I want. The updated version is online at: http://216.171.153.180/ Could someone test it with netscape, I don't have it installed on my machines If someone running netscape could go to the above link and see if the bandwidth monitor functions, I'd be grateful... 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] ipchains redirect
I haven't played with this much, but one of the things on the list of stuff to play with one of these days is using redirect to provide for an 'internal server' machine, similar to the way the low-end firewall boxes do. I *think* this would work properly for everything from game servers to VPN access, although security in such a situation isn't the greatest (although it's not too bad if combined with port-forwarded DMZ rules). Charles Heyaz. Saw this on security-basics this AM. Never saw it mentioned on LRP/LEAF before; anyone ever try it? Alternatively, is IP Transparent Proxy enabled in any LEAF kernels? Seems terribly powerful to me. TIA! -Scott -- Forwarded message -- Date: Wed, 19 Sep 2001 20:19:19 +0200 (CEST) From: Bosko Radivojevic [EMAIL PROTECTED] To: Daniel Chojecki [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: ipchains, ipmasqadm On Tue, 18 Sep 2001, Daniel Chojecki wrote: Is it posible to redirect all traffic comming for 0.0/0 80 to local squid proxy using ipchains and ipmasqadm. Using ipchains - yes. I'm not sure for ipmasqadm (I've never used it) I'm using those lines for that. Of course, you have to enable 'IP Transparent Proxy' in your kernel. ipchains -A input -p TCP -d YOUR_IP/32 www -j ACCEPT (in case you have your own web server) ipchains -A input -p TCP -d 0/0 www -j REDIRECT 8080 Conf: 2.2.19 ipchains It works for me: 2.2.18 ipchains 1.3.9, 17-Mar-1999 Greetings ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] dachstein-pr2 available
I have just posted pre-release version 2 (pr2) of dachstein. The main change from pr1 is the merging of the several versions of firewall scripts I've got floating around. I've finally updated the (somewhat hacked) static-NAT DMZ support of the extended scripts V1.1, and merged this functionality with the Eiger based proxy-arp scritps from LRP-CD. I don't have an updated network.txt file documenting everything, but I did add and clarify the comments in network.conf, so if you're familiar with any of the existing scripts you shouldn't be too lost. I haven't done a lot of debugging on the DMZ aspect of the scripts yet, but the internal network portion is working OK. If anyone has the time or inclination to test firewall scripts, I'd be grateful. Disk image readme available here (and the normal mirror locations): http://lrp.steinkuehler.net/files/diskimages/dachstein/ Other info from the changelog: -- Changes from pr1 to pr2: -- dnscache modified to use 0.0.0.0 for listen IP, allowing local name resolution to work using 127.0.0.1 as the dns server /etc/network.conf no longer sourced in dnscache config file, as local IPs are no longer required firewall scripts changed to LRP-CD (Eiger based proxy-arp) version with extended scripts 1.1 functionality folded in...full support for routed, proxy-arp, static-nat, and port-forwarded DMZ systems dhclient init script fixed to support multiple interfaces 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] lrp.steinkuehler.net back online
Well, I'm back in town, and my site and I are both back online. I have yet to get any of the queued leaf list e-mails, but it should be headed this way along with other delayed mail as smtp servers around the net process their mail queues and notice my new IP settings. 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] lrp.steinkuehler.net
!! - WARNING - !! My DSL service provider (currently DSL.net) is discontinuing service in my area. Sometime next week, the wire pair carrying my SDSL connection will be cross-connected to the new provider (NewEdge networks), at which time my internet connectivity will go down until I swap routers and re-configure the IP addresses on my network. Since I'll probably be out of town when this happens, there will likely be a 2-3 day outage in my web services. The mirror sites, including the sourceforge mirror will still be online. digression On the positive side, I should shortly be able to bump my upstream bandwidth from 384K to a full 1.5 MBit. I may also have aquired 4 DEC Alpha personal workstation 500a systems to use as servers. If I get access to these machines, I'll probably try to make an LEAF build environment that supports cross-compiling, and test new distributions (post Dachstein) on x86 and Alpha hardware. While I don't think there's a big need for alpha based router/firewalls, having a good cross-compile development environment would go a long way towards making LEAF usable by folks making it easier to build stand-alone 'black-box' systems. Maybe I'll even get someone do donate a PPC NPe405H eval system I can use to port linux/LEAF to (hint, hint :) /digression Look for things to return to normal (and a few web updates) the following week. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Tagline
I'm using one of the syslinux spash screens provided by Richard Lohman for Dachstein. Richard apparently replaced the old 'tagline' Embedding the bird for the sake of all humanity with Don't fear the penguin I like the new version better than the old, but I though this would be a good topic for a survey (assuming the survey part of our PHP code is working). So post your favorite sound-bite for LEAF in general, and Dachstein in particular. A few 'quickies' (if no-one comes up with anything better, I'll use Richard's...I don't claim to have the marketing 'golden touch'). Guarded by the penguin Security penguin on duty From Finland with love Waddle-waddle-waddle OK...I'll stop sniffing paint fumes (yes, I just painted my office) and go home now ;-) Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Dachstein Pre-Release avaialble
I've uploaded a pre-release version of Dachstein, which can be found here: http://lrp.steinkuehler.net/files/diskimages/dachstein/dachstein-pr1-1680.im g Pre-release means that I *know* there are things that will change before the release version. See the readme file below for details on what's changed from Ewald's latest ES2B update image, and what remains to be done. I have generally verified the image boots and functions, but I haven't pounded on it a lot...since several scripts have changed, there could be some hidden problems. Try it if you're daring (or can spend some time testing for bugs), but I wouldn't use it for production systems yet. Please post any problems, desired changes, c to the list, for fixing/inclusion in the next image, which will hopefully be a release candidate. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) -- Changes from Ewald Wasscher's May 27 EigerStein2Beta update: http://leaf.sourceforge.net/devel/ewaldw/Eigerstein2BETA/20010527/Eigerstein 2BETA_test_20010527_1680.bin -- Release officially named Dachstein Syslinux splash screen replaced with version from Richard Lohman dnscache modified to use 0.0.0.0 for IPSEND dnscache still run from script (rather than daemontools) due to licensing issues with daemontools dhclient modified to no longer restart dnscache when getting a new IP log.lrp replaced by ramlog.lrp, which puts log files on their own ramdisk partition. /etc/fstab updated to reflect new mount point for /var/log dhcpd and dhclient modified to prevent storage of dhcp leases as part of root.lrp dhclient.conf modified to prepend 127.0.0.1 (local dnscache) to DNS servers provided by ISP's dhcp server Backup scripts reverted back to using ctar, to avoid file exclude problems when backing up root.lrp root.list changed from * to ./ to fix include problems backing up other packages (like etc) e3 replace with re-compiled version: Pico emulation set as the default mode, and the :x command was added to VI emulation -- TODO -- Update the readme to reflect changes to the editor (ae - e3), and any other changes that affect end-user setup walk-through to verify the readme instructions Update network/firewall scripts, folding together LRP-CD and extended scripts V 1.1 functionality Add java bandwidth applet to weblet.lrp ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: 2.2.19 Kernels available
It still looks like you don't have the LRP kernel patches properly applied to your kernel. Well, you were were right. I didn't watch the output when I ran your patching script originally. This time I notices all the 'file does not exist' messages... And why did the original run fail... Well, it seems when I extracted your 2.2.19-1.tar.gz, it ended up in /usr/src/2.2.19-1, not in /usr/src/LEAF-kernel-2.2.19, which is coded in the scripts as the SRC_DIR. So I edited the scripts and re-ran them. Building the new kernel now. Yeah, this was a problem with me when I first started using Matthew Grant's scripts to build the kernel source, which my scripts are based on. I think I'll change the /usr/src/LEAF-kernel-2.2.19 to `pwd`, and add a comment to the readme that you must run the scripts from the current directory. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Compressing kernel with UPX ??? (slitghly OT)
Hello everyone I am trying to figure out hox to compress a linux kernel with UPX I compiled with make bzImage and the tried upx -l9 bzImage. Did not worked. Should I compile with make zImage instead ? Jacques Make sure you've got the latest UPX. You'll need 1.11 or later to compress kernel images. Both zImage and bzImage files can be compressed successully by UPX. The command I use is: upx --best -o kernel.upx kernel where kernel is the kernel image file. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] POSIXness - CVS
Side Note: I plan on going back to using ctar to create LRP files, as there are still problems with proper file inclusion/exclusion using the BB tar command. Can you elaborate? I'd like very much to remove ctar... In the scripts Ewald modified to use busybox tar, root.lrp did not backup properly. IIRC, directories that were part of other packages (like etc) would be excluded even if they were not at the same level. In other words, I created the following directory structure: /boot /boot/etc /boot/etc/file1 /boot/otherdir but after backup restore, I was left with: /boot /boot/otherdir As I'm mainly looking for a stable replacement to my Eiger series disks, and the overall size of the distribution has shrunk considerably already, I'm going to stick with ctar for package creation. I'm hoping this will be the last of the primarily LRP based releases, with new stuff using an updated packaging format, likely some version of your apkg application. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: [Leaf-user] 2.2.19 Kernels available
Do any of these include support for PCMCIA? I would like to build a 2.2.19 that includes PCMCIA support.any help on this is appreciated. No...you'll need to compile the PCMCIA code. IIRC, there are some PCMCIA-enabled versions of LRP floating around somewhere... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Static Compilation...
...that fails. The *ONLY* difference is adding -static to the gcc command line. What's the difference? Well, the -static on the command line is what's different, you said so yourself. :-) I'm grasping at straws, but do you have the object modules for your c library somewhere the compiler/linker can find them? It kind of sounds like the linker might not be finding all your library object files... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: [Leaf-user] 2.2.19 Kernels available
Charles Steinkuehler wrote: I now have version 2.2.19 kernels (and associated modules) available for download from my website. Also available are all required patch files and a script to build a LEAF kernel tree from a raw 2.2.19 kernel source tarball. Which of these is applicable to LRP-CD ??? You can use any of the kernels for LRP-CD, although you'll obviously have to burn a new CD. Start by making a floppy disk of the boot-image on the CD-ROM. Replace the kernel on this disk with the new one. You'll also have to create a new root.lrp that contains the appropriate modules (remember to include the IDE modules if you don't use one of the IDE kernels). Once you get the system booting properly off the floppy, you can burn a CD using your new boot image. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Thinking and rambling: about using a non-sh shell for /linuxrc...
Imagine a boot disk where ash, busybox, or libc could be upgraded with very little effort just copy in a new one and run. I've been wanting to do this for ages (just not enough time), and is what I mean when I say I want to keep the core system flexible enough to run with various versions of libc. IMHO, root.lrp should be renamed to something like bootstrap.lrp (or similar...please excuse the 9.3 name), and contain only the absolute minimum required for unpacking the rest of the system. Exactly *what* the bootstrap system looks like is still up in the air. It could be lua code, busybox sh compiled against uLibc with a few helper apps, a small Forth program, or even custom written C code. Whatever it winds up looking like, there's a big premium on it being as small as possible. grin To still enable a single-disk system, which is obviously quite limited on space, there are two options: 1) The new bootstrap functions are kept small enough to be added to the existing LRP files. With things like UPX kernel compression, and some other space-saving measures, this isn't entirely out of the question. 2) Re-use the bootstrap code in the running LRP system. For instance, if the bootstrap package had a tar, gzip, and other standard utilities (or libraries), these could be re-used by a floppy version of root.lrp. Folks with more space available could still install a full system, using none of the files from the bootstrap package. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] NoCat Net
My requirements are secure point to point connecting 2 wired networks. At this time I do not need roaming connectivity (though that may change, I don't have a laptop). What I plan to do to accomplish this is get it working first, then do a PPP over ssh2 (ya, 2 floppy disks shrug) so that it will be somewhat resistent to sniffers. Not that I am worried where I am yet, but, as I told a friend, we might as well do it right. I'm looking to do this as well, but I plan on using IPSec instead of PPP/ssh. Please be aware that a PPP/ssh link will not degrade well if you start loosing packets...the PPP layer and the TCP layer under ssh *both* try to account for dropped/mangled packets, and can wind up interfering with each other in bad ways. IPSec is designed to work with 'lossy' networks, and takes care of dropped/mangled packets cleanly. Note that as long as your link is clean, PPP/ssh should work fine... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] EigerStein3/Dachstein
Charles, What can we do to help you get the new release finished? Come to KS and help me unpack my office, pack my personal belonging, and move into my new house. ;-) Actually, there's quite a bit that can be done...from trolling the list archives: - The distribution needs a name...again, I'd prefer Ewald to name it, since he's been doing all the work The name is Dachstein. PROGRESS!!! - The syslinux splash screen should be changed. It should probably refer to the leaf sourceforge project. We may also want to pull the links to linuxrouter.org, but I'm not sure about this... - The readme file needs to be updated with (at minimum) new links and new instructions for e3 rather than ae as the editor - The readme instructions need to be verified (ie put on LUser hat walk through the readme like a newbie, making sure nothing unexpected happens). And on to 'real' changes required/desired: - I'd like to see the java bandwidth applet added to the weblet package - I'd like dnscache to be run by the daemontools package, if it doesn't require too much disk space...this should help keep things standardized, and make tinydns package maintainence easier - Use the ramlog package instead of the log package...this puts the logs on a seperate ramdisk, avoiding the full ramdisk issues, which are the most likely thing to kill a working LRP system. - Remove old dhcpd and dhclient leases...that these are around is my fault, as they are getting backed up with root. I need to add an exclude.list file to each package. - Modify the dhclient.conf file to properly generate an /etc/resolv.conf that uses the local dnscache - Update the network scripts...I need to fold my proxy-arp and Extended scripts V1.1 together and create what will likely be the last of the 'mountain' firewall script derivations. I'd like to see future images use seawall, rcf, or similar. I've got work done on the dhcpd/dhclient pacakges, and using the ramlog package instead of log...as long as I can find my test disks (they're in a box somewhere), these are done. I'm likely the only one to modify the networking scripts, as I've got to fold together pieces of 3 different scripts into a unified whole. Stuff someone other than me can work on: Go back to using ctar to create the LRP files when backing up. I ran into problems archiving root.lrp when using the new scripts. Ctar is small enough, and package archiving is important enough, I'd like to leave it 'as-is' in this release. Verifying the dnscache configuration. While I was previously thinking using daemontools would be a good thing, recent threads on the licensing have made me change my mind... Updating the weblet package Updating the syslinux splash screen Updating the readme file There's probably more stuff, but this is what comes immediately to mind... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Using a new shell for linuxrc?
snip All of this is part of an effort to shrink root.lrp; I've already removed /var/spool/cron (to a new cron.lrp) and much of /sbin to init.lrp What do you think of using lua for writing /linuxrc? Anyone here have experience in lua? I'm about to dive in headlong :-) I still haven't looked at lua, so I don't know how it would work for /linuxrc. I've been figuring on working to build a busybox sh based /linuxrc, possibly statically linked against a stripped ulibc, and see how small a boot-strap lrp could be made. Root.lrp (and all other packages) would be loaded by the /linuxrc script. If you dive into lua, let us all know what it's like. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Licensing (specifically, djb)
Has anyone contacted DJB? He may be willing to make an exception for the LEAF project, or even create packages himself. E-mails I sent regarding his licensing for djbdns went unanswered. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] More packaging enhancements
A couple of requests. 1. It would be useful to integrate one the extended scripts unto DachStein. (You probably already thought of this :-) snip So it would be nice for DachStein to be EigerStein2beta workalike (e.g. with the network defaults as I mentioned above) with the added functionality of the extended scripts already in there in case the user decided he or she needed them. Yes, this is planned. The scripts released with Dachstein will likely be the last of the 'Mountain' firewall scripts, as future plans are to support several pre-packaged firewall scripts (seawall, rcf, c). 2. One irritation it would be nice to fix (though it may go beyond the quick upgrade to EigerStein2Beta philosophy) would be to somehow extend the 256 character limit of the syslinux.cfg APPEND= line. When I add a second drive to PKGPATH and add serial support, I'm over the limit. I can't do both. (I recall that David did something in Oxygen to get around this.) The 256 character limit is a kernel restriction, so is unlikely to change soon. It is possible to load non-critical LRP packages AFTER the kernel has booted, from a config file stored on disk, dramatically reducing the size of the LRP= part of the kernel command line. I believe this is what David is doing with O2. Finally, a quick question. If all I want to do is add a simple DMZ to my EigerStein2Beta network via a third ethernet board for a web server at the public IP of the LRP box (which is using dhcp), which is better: 1. upgrade to the extended scripts 1.0 2. upgrade to the extended scripts 1.1 3. upgrade to the CD scripts It looks to me like the extended scripts 1.0 have enough functionality, but it also looks to me like the DHCP section in those scripts doesn't have improvements you added to EigerStein2Beta. If I recall correctly, bothe extended scripts 1.1 and the CD scripts have the newer DHCP code. But I could easily just paste that section into network.conf from scripts 1.0. As near as I can tell that's the only issue. You're correct...the 1.0 scripts support what you want. I'd stick with the 1.0 scripts and paste in any dhcp mods you need. The 1.1 scripts require you manually edit ipfilter.conf, as a couple IP addresses are hard-coded (this will be fixed in the Dachstein scripts). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Site update 2001-07-12
Everyone, I just finished updating our web site Guides, HOWTOs, and Man Pages pages. Any feedback is appreciated. Also, please look at the new Download page, and my update of the Packages page. Thanks. I took a look at your site updates earlier but forgot to reply. Once again, it looks like you're heading in the right direction, and doing the work no one else manages to get done. Kudos! Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Kernel stuff
Well, I've been playing with 2.2.19 kernels, and noticed something interesting. When I compile on my RH 7.0 box (gcc 2.96) I get a kernel that's a fair amount larger than the same kernel compiled on my Debian Slink box (gcc 2.7.2.3). gcc 2.96 compiled zImage size: 473320 gcc 2.7.2.3 compiled zImage size: 464668 The above are compiled from EXACTLY the same source (rsynced prior to compile). Anyone know any gory details about how the newer gcc differs in terms of optimizations, loop unrolling, etc? I'm also getting close to a kernel source config set I'm happy with. Currently, I've got the following patches to the standard 2.2.19 kernel source: linuxrc-always-2.2.19.diff initrd-archive-2.2.19.diff ip_masq_vpn-2.2.18.patch.gz ip_masq_h323-dplay-icq-mms.diff Several ip_masq modules rolled into a single patch: ip_masq_dplay-0.3.00 ip_masq_h323 Version 2.2.0 - 16 October 2000 ip_masq_icq-0.56 ip_masq_mms Version 0.91 linux-2.2.19-ow1.diff linux-2.2.19-reiserfs-3.5.33-patch.bz2 I've also applied the IPSec patches to the kernel, which don't add any size if IPSec is disabled (or compiled as a module). Once I get some kernels compiled and tested (hopefully today), I'll be working on the 1.91 release of IPSec. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Kernel stuff
*DOH* Of course, I'm not using gcc on RH to compile the kernel...it's really: egcs-2.91.66 egcs-2.91.66 compiled zImage size: 473320 gcc 2.7.2.3 compiled zImage size: 464668 Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] More packaging enhancements
I propose the following updates to packages, and would like to start using them: pkg.sh Shell script which takes a parameter - one of: preinst postinst prerem postrem ...executed by apkg at times indicated pkg.descConf file describing package: Description: blah Packager: Leonard U. Ser [EMAIL PROTECTED] Group: Net/Diagnostics pkg.req Package list: these must already be installed I think the pkg.req should be based on a functionality list, not a simple package name. There should also be some way to differentiate versions and/or functionality. For instance, it's probably important to be able to tell the difference between glibc versions, and between POSIXness, busybox, and full GNU versions of some commands. Otherwise, adding the files sounds good to me. An existing lrpkg system should just ignore all this. One other thing that might be nice would be some sort of cryptographic signing of the package, but I don't know if we can find crypto code small enough to include with all floppy distributions. Also, we'd need to jump through some hoops to tack on a crypto signature to the end of a tar.gz file to keep it compatable with the existing package scripts (tricky, but do-able with dd shell code). These enhancements will allow: * Restarts of currently running daemons * HTML pages with full descriptions, etc. * Packager can specify package group (saves grouping problems) Please clarify the last item...I'm not sure what you mean. Features I consider a *MUST* in any new packaging scheme: The ability to upgrade an installed package Support for mixed-media bootup ie load data from a package repository (CD-ROM/network/c) and config data from a local writable source (floppy/flash/c) The ability to backup just config data The ability to backup user data, or just package changes (ie weblet web pages). This could possibly be done by storing anything with a changed MD5 sum. I think apkg has (or comes very close to having) several of these features already. I've already begun using the following enhancement: pkg.md5 MD5 sum of all files in package The beauty is, lrpkg SHOULD just ignore all these enhancements. Anybody do any work on lrpkg to make it not ralph if pkg.help and/or pkg.version are missing? lrpkg should not fail for ANY reason; otherwise it is buggy software. I should be able to throw most any trash at it, and not see it fall over dead. apkg was designed with this in mind. When does this happen? I've seen several packages w/o a help file, and I think I've seen some w/o a version. What breaks? Anybody planning to use apkg with Dachstein? I'd like to see Dachstein be a fairly straight-forward update to the Materhorn/Eiger series disks. I hope to get this done in the near term, which should happen, as I've finally gotten a bit of time to work on LEAF stuff (in addition to being busy, I've been kind of hoping Ewald would turn up again). I'll be tackling Dachstein as soon as I finish IPSec, likely later this week. I'd like to see a 'ground-up' effort including the new c libraries, 2.2/2.4 kernel support, the new packaging system (likely apkg on steroids), and other enhancements. I don't see any reason to tie these changes to existing releases, and by starting with a clean slate, we don't have to keep any backwards compatibility we don't actually find useful. It might be very convinent, for example to switch to a VFAT format for floppies, and use long filenames for packages... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] More packaging enhancements
I think the pkg.req should be based on a functionality list, not a simple package name. There should also be some way to differentiate versions and/or functionality. For instance, it's probably important to be able to tell the difference between glibc versions, and between POSIXness, busybox, and full GNU versions of some commands. Yipes! Getting carried away a bit :-) For me, I almost hesitated to put that in - but the way I build packages (main binary in bin.lrp, needed dynamic libraries in libX.lrp) adding requirements is a big win. However, these are my goals: 1. Simplicity 2. Simplicity 3. Simplicity :-) I like Simplicity, but that's pretty much what we've got already. I'm thinking more along the lines of small but flexible. I'd like to see how much of a decent packaging system could be made with just shell scripts and possibly a few small programs (like md5sum and possibly a crypto signer/verifier). Versions would be nice - probably doable - though, then you get things like versions earlier than X or version X or later or version Z only... And THEN you get versions like 0.91a05072001-1 ...uhoh... or even (gasp) 01May2000 ...or worse... Maybe versions aren't such a good idea... Yeah, versions can get real ugly real fast. I think there should be *some* form of versions, though, at least for stuff like shared libraries. Secondly, this would be for installed packages; glibc is not an installed package (at least, not currently); neither is busybox, nor things like GNU sed. Also, Oxygen is likely to do away with POSIXness altogether... I guess I'm thinking of broader variations in the base functionality. For instance, a minimal system might have a small busybox and some POSIXness scripts. There might be other [root|base|whatever] packages that include a larger busybox, or full GNU versions of the base commands. I think this stems from the fact that I'd like to make both floppy-disk based firewalls and single-purpose, very thin servers... However, the idea of building in functional requirements is well-taken - but not so easy to implement. For example, some things may require a snip Too much to think about right now, with my head wrapped up in kernel compiling. Lots of good thoughts, though. More comments later... Another thing: what if you have 40 packages loaded with *.conf files? The screen is only 22 or 23 or 24 lines long. Like I said: I should be able to do all sorts of mayhem, and lrpkg handle it in stride. It can't. Yeah...there are several things of this sort that could be considered 'broken'. I'm not great fan of lrpkg, but would rather work on it's replacement than spiffy it up, and I'm unaware of any show-stoppers that prevent it from being usable (although it would be nice if it could verify it didn't run out of RAM when backing up). Only thing I'd possibly like to do in Oxygen is to move /var/boot/modules to /lib/modules/boot (the standard location, I understand). I settled on putting my boot-time modules in /boot/lib/modules, following the layout of my HDD machines, which create a /boot partition for stuff required to bootstrap the system. Where did /lib/modules/boot come from? Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] More packaging enhancements
David, Would it be a good idea for us to follow the LSB 1.0 specs? http://www.linuxbase.org/ https://sourceforge.net/projects/lsb AFAIK, we can't follow LSB and still fit on a floppy, but we should probably try to not break any LSB rules. It may be possible to make a superset of some LEAF distribution LSB compliant, but I'll have to read through more of the spec... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Modules and directories
Only thing I'd possibly like to do in Oxygen is to move /var/boot/modules to /lib/modules/boot (the standard location, I understand). I settled on putting my boot-time modules in /boot/lib/modules, following the layout of my HDD machines, which create a /boot partition for stuff required to bootstrap the system. Where did /lib/modules/boot come from? In modules.conf(5), it says: [...snip...] DEFAULT CONFIGURATION If the configuration file '/etc/modules.conf' is missing, or if any directive is not overridden, the following defaults are assumed: depfile=/lib/modules/`uname -r`/modules.dep path[boot]=/lib/modules/boot snip With a nice clean-up of modules, I can forsee a tree like this: /lib/modules/boot/* (in root.lrp) /lib/modules/2.2.16/* (in a modules.lrp) /lib/modules/2.2.19/* (in an alternate modules.lrp) ...and so forth. However, be wary of symbolic links; I don't think that busybox insmod follows them, but in any case, busybox and GNU, symbolic links are a problem. Thanks. I play so much with LRP, I forget about stuff like modprobe. We should probably migrate towards the more conventional directory structure, to avoid unnecessary confusion, if nothing else. I also noted recently in the busybox list, someone said that he used modprobe to generate modules.dep (in a build environment) then used a shell script to analyze modules.dep and create the appropriate module load in the appropriate order. Thoughts? I've seen this done before. I think a trick like this might be good for an install script (when creating a modules package), but I don't think we need to extend the module loading code to the running system. In addition to the extra script overhead, you've got to keep a modules.dep file around. Also, the modules.dep file is pretty human-readable...maybe we should just create this file and add a couple notes in a readme or howto (or comments in /etc/modules) on interpereting it... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Modules and directories
With a nice clean-up of modules, I can forsee a tree like this:
/lib/modules/boot/* (in root.lrp)
/lib/modules/2.2.16/* (in a modules.lrp)
/lib/modules/2.2.19/* (in an alternate modules.lrp)
Thanks. I play so much with LRP, I forget about stuff like modprobe.
We
should probably migrate towards the more conventional directory
structure,
to avoid unnecessary confusion, if nothing else.
Also, this kernel versioning means that you can load multiple kernel
version modules, and not get them tangled. However, busybox insmod
doesn't honor the traditional order; it does (last I checked) a form of
this:
MOD=${1%%.o}.o
insmod $(eval find /lib/modules -name $MOD)
Rather than the more interesting and compatable:
insmod $(eval find /lib/modules/`uname -r` /lib/modules/2.2 /lib/modules
-name $MOD)
(did that make sense?)
Yup...looks like it could be time for a shell alias :)
I've seen this done before. I think a trick like this might be good for
an
install script (when creating a modules package), but I don't think we
need
to extend the module loading code to the running system. In addition to
the
extra script overhead, you've got to keep a modules.dep file around.
Also,
the modules.dep file is pretty human-readable...maybe we should just
create
this file and add a couple notes in a readme or howto (or comments in
/etc/modules) on interpereting it...
I wonder if it would not do, to create a script to further read the
modules.dep file, and create a file listing ONLY dependencies with no
paths: this file would very likely be very short - and by its nature,
very accurate. Then you could refuse to load module X if module Y is
not yet loaded (via judicious use of lsmod and grep).
Let me take a quickie stab at it:
From a configuration file:
modX: modY modZ
modA: modB
...script:
snip
...well?
Hmm...a POSIXness modprobe? :)
Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Kernel stuff...
OK, I'm looking to compile the latest FreeS/WAN (V1.91), but to do so, I need to compile the kernel as well. This isn't really a problem for me, but the latest LRP based kernels I've got around are 2.2.16. I know that several other folks have built 2.2.19 kernels for LRP, and in the interest of trying to limit kernel version proliferation (isn't that part of why the LEAF site's here in the first place?), I'd like to start with someone else's baseline kernel, and like the direction folks have been taking lately (applying openwall other security patches). After searching a while, I found a link to David's Oxygen CD, which I think has the kernel source, patches config files (please correct me if I'm mistaken), but I can't seem to download this file from the SourceForge site (I get a DNS error). NOTE: It should probably be easier to find David's latest releases and his CD image on the 'main' leaf website...I had to go directly to the SourceForge released files page to find these, and then the links were broken (likely yet another problem with SF) : Ewald has also apparently compiled some 2.2.19 kernels, but if he posted the patches he applied (and script or similar, indicating the patch order), I wasn't able to find them. So...anyone know where I can get my hands on a source tree for an existing LRP 2.2.19 kernel? Thanks, Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Kernel stuff...
Ewald has also apparently compiled some 2.2.19 kernels, but if he posted the patches he applied (and script or similar, indicating the patch order), I wasn't able to find them. The (LEAF) patches I've used were the same ones as before; the 2.2 kernels don't vary enough to matter with the patches. I like to recompute them though, as its nice for a user to know that the patches are compatable. If you're talking about the offsets when applying the patches, these don't worry me...as long as no hunks fail :) If you've got the re-computed patches for 2.2.19, can you send them to me (or point me to them). I didn't see any patch files in the kernel tarballs you've got on the SF site... BTW: Am I right about the CD having a full kernel source directory? If so, is it pre-patched, or are the patches available seperately, or both? So...anyone know where I can get my hands on a source tree for an existing LRP 2.2.19 kernel? I've got 2.2.19 kernels on the Oxygen site, and I've got source et al floating around here. You want patches and config files? Yeah, patches configs, but mainly the patches (and if you've got it, the order you applied the patches). I need to be able to turn a 'virgin' 2.2.19 kernel source tarball into the source tree you used for the 2.2.19 Oxygen kernels. Along the same lines, should we try to standardize a set of patches for LRP, (other than the mandatory linuxrc-always and initrd-archive), or just continue to leave this up to whoever's making a particular kernel/distribution? Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Going offline soon
I'll be going offline sometime soon (not sure yet exactly when) as I move into my new office. The SDSL connection at the new facility went online today, so I'll be migrating my existing services, including dns, e-mail, and web servers over to the new facility sometime tonight or tomorrow. Since I'm moving my primary dns, there will likely be a 'hiccup' of a day or two until everything settles down and gets back to normal (yes, this could be avoided, but I'm too busy to mess with configuring an alternate primary and moving my DNS twice). This outage will affect all steinkuehler.net domains, including my main e-mail account and lrp.steinkuehler.net. Since the main dns is going away temporarily, access to secondary domains such as lrp1.steinkuehler.net (the SF mirror of my site) will also be spotty due to name-server issues (access via leaf.sourceforge.net, however, will be unaffected). I hope to resume normal operations by Thursday at the latest. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Tel$tra Bigpuddle is imposing a 3GB TOTAL traffic limit
Does anyone have any input on my ideas below? I'd really like my LEAF box to be able to supply logs/statistics so I can measure throughput per IP address. I understand that I can run MRTG on a Windows or Linux box, but am unsure if it will display stats based on IPs so I can check traffic quantities per IP on my LAN. I still need a way for the logs on the LEAF box to be archived and exported daily so there's a more permanent record of this traffic. One way I know of to do what you want: Create accounting rules with ipchains. This is a rule that matches any packets to and/or from a given IP address, but doesn't do anything (ie no -j target parameter). You can then configure MRTG to track the packet/byte counts for these rules. I haven't set up MRTG to do this, but I remember seeing some scritps and/or descriptions of how to do this when I recently setup MRTG to do more conventional interface monitoring. There are probably other ways to do this, as well, and with the above method your usage info won't go to syslog (unless you make a cron script or something to 'harvest' the accounting rule packet/byte counts every so often and log it with logger or similar), but you might find the techinque useful anyway... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Site Updates
I just got a private e-mail regarding LRP, and in trying to include the leaf-user list web page in my response, I noticed: 1) We don't have a mailing list link in the 'main menu' part of the leaf site 2) If you go to support, you get a link to the mailing list the troubleshooting howto, but the page looks pretty sparse. I suggest we move the mailing lists tag from the development section to the main menu section, and expand the support page. If there are no objections, I think a modified version of my existing support page (make more LEAFcentric, remove all the I's referring to me, etc) would work well: http://lrp1.steinkuehler.net/Support.htm Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Hard-Hat
At 05:21 PM 6/18/01 -0500, Charles Steinkuehler wrote: I just got a call from the Monta-Vista folks (makers of Hard-Hat). I wanted to get their reaction to our possible use of the HardHat platform as a cross-compile environment, and what sort of comittment they have to keeping a free version available. ... I have the Journeyman CD's, but have yet to install and evaluate the development environment. I'll try to get to this in the next week or so, and report back. May I ask how you managed to get them? I've tried for months to get a set of disks from them, and Marketing always tells me Real Soon Now. Last time I asked was at their Embedded Systems Conference booth back in April. I just now tried to go to their download page and it crashed my (Netscape on Windows) browser. Twice. I downloaded them from their website (using IE on windows): ftp://ftp.mvista.com/pub/Journeyman/ It looks like their FTP server spits out malformed response headers, in an attempt to be graphical GUI. I couldn't get IE to reload the link above, but I could get to it with a command line FTP client... Monta Vista's Embedded Linux doesn't look to me like the best around (Lineo's Embedix looks better, based on comparing literature, not samples) ... but it sure looks like the best low-cost version. If we could refer people to a version that was readily available to people who do not have their own CD burners, I agree that it would address a lot of the issues we wrestle with. Hmm...I forget not everyone has a CD rom burner yet. Perhaps a qualifer for any disto should be the ability to mirror the CD and/or sell copies at minimal cost... Of course, it's pretty hard to buy a Debian Slink (or RH 5.x) CD in today's world, so most w/o a CD burner would be stuck (or have to ask for help) as well... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Apparent Directions
Also, I'm generally interested in 'really thin' servers. The first will probably be a BIND server, which I'd also like to see install straight from the CD. Charles Steinkuehler Hi Charles ! What are the reasons which make you choose Bind over tinydns if you are looking for a really thin server ? Tinydns is really compact (package size= 23K plus 45K for dnscache) and very efficient and secure. Jacques Tinydns is an excellent option, and very suited to the LRP/LEAF environment. However, there are a LOT of systems out there running Bind, and a lot of sysadmins that are familiar with setting up and administering Bind, yet worried about potential security problems...this is the target 'market' for a very thin Bind platform. It would also be quite possible to build exactly the same sort of system using Tinydns, and I would expect this to happen as well, but Tinydns doesn't benifit as much from the restricted environment, being more secure and less complex to start with. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Apparent Directions
This is where I see the two LRP derivatives heading, based on the mails from developers, and in other cases, my own view. These are LONG views. Eigerstein: * Ease of use improvements and focus: boot it and use it * Leaner, smaller * Further specialized as a router and firewall * Built against uClibc or similar Oxygen: * Mini-distribution * Bootable CDROM with live CDROM fs * Variety of non-router images: bridge for example Or to put it quite succinctly, Eigerstein = smaller, Oxygen = bigger :-) Sounds about right to me, as long as I still get the option to boot off of a CD! I do expect Eigerstein (or actually LEAF named derivations) to be smaller and more focused than Oxygen. In addition to loading LRP files from the CD (which I can do now), I'd like to see a CD that could do a customized install (to floppy, HDD, flash, etc) straight off the CD. Also, I'm generally interested in 'really thin' servers. The first will probably be a BIND server, which I'd also like to see install straight from the CD. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Hopefully last thread on LRP and leaving
P.P.S. what steps have been taken to store and or mirror sourceforge locally should VA Linux go away? I backup our web site, and the content in the DocManager here: http://leaf.sourceforge.net/pub/archives/ SourceForge also backs up all projects regularly. If someone wishes to make a backup that is independent of the SourceForge site, let me know. Note: it will require approximately 1-2G of storage. I should soon be in a position to mirror the SF site, although I may need some help setting up PHP and the database stuff. Assuming DSL.net keeps their word, I'll be getting an SDSL line with a /26 of static IP's. Initial bandwidth will be 416 KBits/s, but I plan to upgrade to 1.5 MBits/s in a few months. Since I'm currently in the middle of moving my office (and my residence as soon as I'm done with the office), it may be late July or August before I get a new server built that can handle this type of site, but I will eventually get one up and would be more than willing to host a full mirror of the SF site content. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Suggestion for improvement
Scott C. Best, 2001-06-13 23:25 -0700 Heyaz. So, I went to the LEAF site today trying to imagine myself as a new LRP user who's going there for the first time. And it strikes me...where's the distro? IMO, frontcenter links to both ES2B and Oxygen be a would be a great help. Sure, there's a little releases in the upper left, which leads to a page that has no clickable links on it -- gotta click again in the left banner, though, to actually get to the page. Doing it that way, with the left-banner, makes me feel like I had to mine for something, and may have no gotten the good stuff. So, I guess I'm suggesting a here's the good stuff link, right there on the homepage. Thoughts? Scott, I could remove the Releases menu item. Then make EigerStein and Oxygen root menu choices. My preference is to add links to the releases page. Let me know which way you think is easier for the new user. I don't know that we need to change the menu items, just make it easier for a new user to find our distributions. Maybe add another 'tagline'...something like What is it? Project Goals: Distributions: Choosing a distribution - Link to a page describing each disto in summary EigerStein - Direct link to Releases/EigerStein Oxygen - Direct link to Releases/Oxygen PPPoE and PPPd - Direct link to Releases/PPPoE and PPPd Affiliates This would make it easy for new visitors to actually find the 'goodies' Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] New Development Platform?
This talk recently of other development platforms (Hard Hat and BlueCat) made me think about this. The original was Debian, as that was what was used, and it supported glibc 2.0 in Slink. It later became clear (to me anyway) that any glibc-2.0 based Linux should do, such as Red Hat 5.2 or Linux Mandrake 5.3. I've taken a look at some of these, and wonder what every one else thinks: * Hard Hat - seems like its made for true embedded applications, and the Professional version isn't GPL and isn't available for download. Embedded to me means: using some CPU no one's ever heard of, and putting the CPU and software into a device no one will ever see. * BlueCat - this is like Hard Hat in that it is for True Embedded Development... why develop for an i586 when you've get Joe's CPU xx87AA0-series 7 available? Maybe I just don't get it with this embedded stuff - I thought we were developing for mass produced Intel-compatible processors but anyway - more: The part to 'get' about using an off-the-shelf distribution aimed at embedded development is the tool chain. The typical embedded distribution installs on top of some other system...most support a wide variety of linux, and even Windows NT/2000 using the GNU compilers. The big advantage to using something already setup with a cross compiling development environment is we don't have to worry about (and fix) the many little things that break when trying to build an environment like this...someone else did that work for us. Also, I guess I lean towards the embedded side of things, as I've done a lot of work with embedded processors. In addition, I guess it seems (at least to me) more likely to see a LEAF derivation in a stand-alone black-box router or VPN gateway (ie embedded system) than to see a LEAF derivation that is trying to be a full-blown desktop workstation with a self-hosted development environment. Note that even if we can self-host a development system, we're STILL in a cross-compile environment, as the target install machine is typically NOT the machine you're compiling on, even though they may share the same CPU architecture. * Gentoo - this seems like a VERY appealing environment. I will probably see if I can install it sooner or later. The idea of not having GNOME support in binaries when you don't use GNOME is appealing - similar things could be said about NIS and about IP v6. * Peewee Linux - this also seems appealing, though it seems more geared towards making that bootable floppy disk distro than what I thought it was originally (a bootable mini CDROM distro). * Peanut - this is another distro that I will probably install or try out at some time. It IS a small CDROM-based distro. Thoughts? I'm only somewhat familiar with Peewee linux and Peanut...I haven't heard of Gentoo at all. I'll take a look at these... The more I think about it, the more I'm tempted to think we'll probably wind up with our own complete distribution, like it or not. At a minimum, we'll probably need to re-package anything pre-made, unless we can get full support for creation extraction of RPMs or DEBs small enough to fit on a floppy. Also, I'd prefer to make a system flexible enough to handle: Base utilities...choice of: Standard binary BusyBox asmutils shell-script (POSIXness or similar) omitted entirely Libraries...choice of: ulibc glibc (various versions) newlib others? With BusyBox and perhaps ulibc making up the 'standard' floppy firewall. A full-blown glibc could be added as a package if something required it. In summary, I'd like to see a compile environment flexible enough to handle various library versions, and setup to compile for a target different than the host. The other thing I'd like to see is an enhanced packaging system of some sort, that can handle a variety of boot and storage media...from the current floppy boot into a ramdisk, to CD or HDD boot into a hybrid system with volitle (ram-disk), non-volitle (flash/HDD), and read-only (CD-ROM/boot-ROM). PS: Maybe Charles wants to put Dachstein into a robot? :-) How about a wireless router in a robot, doing network routing during competition (hee, hee, hee, hee) Hey the network went down. Yeah, I know - Charles' robot just got axed by that turtle thing from Monona, Wisc. :-) :-) I do have plans on integrating some aspect of LRP/LEAF into a combat robot, however I have yet to meet Lisa and her robot Tentamushi (sp?) in the arena...blame any current network outages on the 'Wedge-of-doom. ;-) Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: OT Re: [Leaf-devel] linuxrouter.org
I agree with Scott's wording. I recognized my mistake as soon as I read his message. I think we should give Morgan a chance to write a draft. He may come up with something we can all agree on. ... We need to be careful here. Silence does not equal assent, and many of the important participants in LEAF have been most notable for their silence on this thread. Some of them may not share the sentiments of those of us who have spoken up, but hesitate to start a confrontation here on this list. Understandably. Others may share the general sentiment but feel that it is not a proper topic of discussion here. Again, understandably. In other contexts, I've been in both of these positions, and they are uncomfortable ones. Sorry to stir up this thread and disappear... Shortly after posting the suggestion to take a look at linuxrouter.org (which I can't actually take credit for...Michael Smith sent an e-mail to the webmaster account of my LRP site suggesting I take a look at linuxrouter.org or I never would have noticed), I went off bicycling. Two flat tires, and about 4 1/2 hours later on an extremely humid day, I got home, showered, and crashed, not getting a chance to read this thread until this morning. Personally, I'm not too worried about trying to do something effective. I think Dave's efforts are trivial in any real political sense. Agreed. As for my response to Dave's day of mourning, for me there is now no question about the future direction of my efforts with LEAF. While I was working towards making some disk images with LRP 2.9.8, and would have been willing to consider using Butterfly as a base distribution if/when it ever saw the light of day, these plans are now scrapped. I am un-subscribing myself from the lists at linuxrouter.org, and will direct users of my disk images to use the LEAF site/lists, which I will remain subscribed to. Future development will be based either on custom work or perhaps a small distribution, like HardHat. In the short term, I'd like to see Dachstein actually get released, and I'll try to implement linuxrc script changes that enable us to boot LRP like systems using the standard kernel (I've never been too fond of Dave's initrd-archive patches anyway). Also, while I'll consider signing a letter to Dave C. from the LEAF group, I'm not sure this is appropriate or necessary. While I disagree with the statements posted on the linuxrouter.org site yesterday, I think the biggest transgression Dave made was combining his political views with the linuxrouter project. If the linuxrouter site had a history of being the American terrorist firewall site: Keep the FBI out of your secret files, his site content yesterday would have been appropriate. Instead, it seems like he is attempting to force his views onto a user-base that has little or no advanced warning of what they're getting into. If we see enough questions from the user-base, we may need a FAQ or article stating something about how the LEAF group is not politically oriented, we just make firewalls and other useful things out of small linux systems, and intend for them to be used by anyone regardless of political or moral views. (At least, I hope this is what we're doing). Charles Steinkuehler [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Monta-Vista Hard-Hat Linux
In light of my recent decision to abandon waiting for Butterfly, I am taking a long, hard look at working with Monta-Vista's Hard-Hat linux. I think this would make an excellent base distribution for the next generation of internet appliance releases. Of course, the proof is in the pudding (or so they say), so I'm downloading their (free) Journeyman release to play with. I've also e-mailed the HardHat linux folks, to see if they have any interest in a project like LEAF using their distribution. While I don't think we currently need sponsership from Monta-Vista, an alliance (or similar) might be nice. It would at least be good to know things like if they plan on keeping a free development platform available, be informed of major upcoming changes to the distribution ahead of time, and similar. Another benefit of using something like HardHat is multi-processor support. This will mean absolutely nothing to 99.999% of our users, but several folks are embedding LRP into 'black boxes' which may or may not run an Intel architecture CPU. I personally would LOVE to play with something like HardHat on the new IBM NPe405 CPU with 4 built-in 10/100 ethernet ports and multiple T1/E1 support. That would make a pretty cool LEAF platform... NOTE: I'm still very open to suggestions on what to use as the base of the next generation of LRP like functionality. I'm mainly looking at starting with an existing distribution because 'out of the box' you get a working cross-compile environment (no more dedicated Debian Slink boxes just to compile an application or two), and much of the software will be pre-packaged. While the pre-packaged stuff will likely be in RPM format, it should be possible to easily convert the RPM's to a tar.gz file or something else shell-scripts can deal with. A lot of the hard work (that requires maintainence and debugging) goes into making sure the packages all work well together...we should be able to leverage this work from a mainstream distribution and speed our time to solution. I really don't want to try to create or maintain a complete, from the ground up distribution...it seems like too much duplication of existing work. Thoughts/commments welcome, as always Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Monta-Vista Hard-Hat Linux
NOTE: I'm still very open to suggestions on what to use as the base of the next generation of LRP like functionality. I'm mainly looking at starting with an existing distribution because 'out of the box' you get a working cross-compile environment (no more dedicated Debian Slink boxes just to compile an application or two), and much of the software will be pre-packaged. I was recently contacted by the makers of BlueCat Linux (and its RTOS sister LynxOS) at www.lynuxworks.com, who are actively looking for partners for their distro. I cannot comment on the strengths of their product, but if you'd like a nameemail of the partners manager, that I can provide. Please do. I've actually got a copy of BlueCat, which came with my ELJ contest kit. So far, I've been less than successful at getting it to boot (believe it or not, their network bootstrap loader won't work across a router), and there tech support has apparently been following the Dispair Inc. Apathy motto: If we ignore our customers, maybe they'll go away, but this could be related to the fact that I have a 'freebie' version... On the plus side, their distribution installed a cross-compile develompent environment on my RH 6.2 box successfully, and they look to have a fairly large list of pre-built packages. The boot problems are also at least partially due to the embedded PC card I've been trying to get BlueCat working with... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Site Update
Last but not least, our phpWS has received 64732 visitors since 2001-03-19. What sort of a statistic is this? Is this unique IP's, individual webhits, or something in-between? Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Ewald's Updated ES2B
- Use the ramlog package instead of the log package...this puts the logs on a seperate ramdisk, avoiding the full ramdisk issues, which are the most likely thing to kill a working LRP system. Sorry, if I missed something, but can someone explain the advantage of having extra packages for everything?? In the case of the ramdisk.lrp I started with Charles package, and it was helpful to understand what's needed to have a second ramdisk for log files. Then I realized that most the package could be replaced by busybox commands, at the end ramdisk.lrp has been obsolete - and again a few bytes saved. So I ended up with multiple ramdisk support as an integrated function of root.lrp. Is this worse than having an extra package? Not to mention the sideeffect, that I don't have to waste Charles time for help and maintenance of the ramdisk.lrp - it's instead part of the active busybox development. The ramdisk package was created because previous LRP systems were missing the minix format utility, and some init scripts are needed to acutally build the ramdisk. I have no problem with folding this functionality into root.lrp if the required functions are now in busybox (or can be added). The init scripts are very small, and can be backed up as part of root without causing any problems. The biggest benifit to using my ramlog.lrp package is the fact that it's already done...just replace log.lrp with ramlog.lrp, and that's it. Note that there is a bit of a chicken egg problem with putting log files on the new ramdisk. The /var/log directory needs to be populated with some files for everything to work properly, and given the limitations of the LRP packaging format, the ramdisk init scripts need to create these files. This is currently handled by saving a log.tgz file as part of ramlog.lrp, but there may be a better way to do this. I'll take look at various ways to implement the extra ramdisk functionality cleanly... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ES3 suggestion
1. First, when it refreshes, I'm not sure that it flushes the rules *and* the portfw's/autofw's. I could be wrong here, but I think it only flushes the ipchains rules and doesn't touch what was previously setup with ipmasqadm. I'll check this. 2. Given the increased popularity of ISPs giving out RFC-1918 private addresses with DHCP and then static NAT'ing them, I think part of the firewall setup which blocks the RFC-1918 address specifically should be dropped. While I still think the private IP's should be blocked by default, there should be an easy way to disable a particular range, and documentation on the fact that this might be required. I'll add a way to do this in the new firewall scripts. 3. Many of the trojan's I've read about use blind-attacks where a response from the target isn't needed. So the attacker can spoof the return IP address, and they often choose from the reserve-address range (and use the eleet port of 31337). Anyhow. as per CIAC alert K-032, I think the following reserved address traffic should be blocked explicitly: $IPCHAINS -A input -i $IF_EXT -b -s 0.0.0.0/8 -j DENY $IPCHAINS -A input -i $IF_EXT -b -s 224.0.0.0/4 -j DENY $IPCHAINS -A input -i $IF_EXT -b -s 240.0.0.0/5 -j DENY The above IP's are already blocked... $IPCHAINS -A input -i $IF_EXT -b -s 169.254.0.0/16 -j DENY $IPCHAINS -A input -i $IF_EXT -b -s 192.0.2.0/24 -j DENY $IPCHAINS -A input -i $IF_EXT -b -s 248.0.0.0/5 -j DENY I'll check into blocking these IP's as well... 4. Lastly, at the end of the setup script, some noise blocker rules should be stuck in. This helps eliminate log file buildup (and the risk of resulting tooth decay...). Since they're at the very end, they not interfering with normal op's that would have been setup earlier. $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 137 -p tcp -j DENY $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 137 -p udp -j DENY $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 138 -p tcp -j DENY $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 138 -p udp -j DENY $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 67 -p udp -j DENY The above are already blocked w/o logging (along with a few more netbios ports: 135 139)... $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 68 -p udp -j DENY $IPCHAINS -A input -i $IF_EXT -d 255.255.255.255 -j DENY Again, I'll look into blocking these IP's as well... That's it. Please let me know what you think. Of course, I'd be willing to do the dirty work of editing the scripts and tar'ing them up for the inclusion in the new release. Just wanted to be sure the above has enough perceived value. I need to fold my extended V1.0 V1.1 functionality together with my latest proxy-arp DMZ scripts, so I can make the mods, but pointers to any RFC's or other docs that refer to the new subnet ranges you think should be blocked would be helpful... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Ewald's Updated ES2B
I've downloaded the 20010527 version of the updated ES2B image (I'm playing with the 1680K version). After a very brief examination (only about 30 minutes), I created the following list of things that still need to happen. This is probalby not everything, but I won't have time to really pound on things until later. Note several items are minor things that simply need to be addresses to make a clean distribution. - The distribution needs a name...again, I'd prefer Ewald to name it, since he's been doing all the work - The syslinux splash screen should be changed. It should probably refer to the leaf sourceforge project. We may also want to pull the links to linuxrouter.org, but I'm not sure about this... - The readme file needs to be updated with (at minimum) new links and new instructions for e3 rather than ae as the editor - The readme instructions need to be verified (ie put on LUser hat walk through the readme like a newbie, making sure nothing unexpected happens). And on to 'real' changes required/desired: - I'd like to see the java bandwidth applet added to the weblet package - I'd like dnscache to be run by the daemontools package, if it doesn't require too much disk space...this should help keep things standardized, and make tinydns package maintainence easier - Use the ramlog package instead of the log package...this puts the logs on a seperate ramdisk, avoiding the full ramdisk issues, which are the most likely thing to kill a working LRP system. - Remove old dhcpd and dhclient leases...that these are around is my fault, as they are getting backed up with root. I need to add an exclude.list file to each package. - Modify the dhclient.conf file to properly generate an /etc/resolv.conf that uses the local dnscache - Update the network scripts...I need to fold my proxy-arp and Extended scripts V1.1 together and create what will likely be the last of the 'mountain' firewall script derivations. I'd like to see future images use seawall, rcf, or similar. I will take care of updating dhcpd.lrp dhclient.lrp, and the network script mods, but probably not until Tuesday. The rest of the work is up for grabs by anyone who wants to tackle it... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Back online
Well, I'm back from my escapades fighting robots in California. A sincere appology goes out for missing the LEAF meeting in San Francisco Wedensday night. As Mike reported, I didn't get in until really early Thursday morning. Currently, it looks like the highest priority is verifying Ewald's latest pre-release version of the updated EigerStein. I should be able to spend some time on this in the next few days. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Pb with dhclient Eigerstein BETA2_test_20010527
Symptom: When I boot the new package I get after: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 receive_packet failed on eth0: Network is down Then if I issue after login in /etc/init.d/dhclient restart it works ok I replaced the dhclient package with the one on Charle's site version 2.0pl5 (not the one on Eigerstein Beta2 which is I think an earlier version). I was able to login without any problem. Therefore the problem is with the dhclient.lrp in the Beta2_test package. Yes, we need to verify the dhclient package is 2.0pl5. An older version is on the existing EigerStein disks. Another problem is the dhclient-script file which must be hacked when dhclient is running with dnscache. See FAQ section at http://leaf.sourceforge.net/devel/jnilo/dnscache.html Hmm...kind of a sticky problem. Since I now know more about how dhclinet works, what about the following: 1) Return the dhclient scripts to their original form (ie knowing nothing about dnscache) 2) Add a prepend statement to dhclient.conf: prepend domain-name-servers 127.0.0.1; This *should* use the local dnscache to resolve names, falling back to the DNS server(s) provided by the ISP if local resolution fails, and keeps everything standard but the dhclient configuration file, which is where such things are supposed to be set. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Going walk-about
If you meant Ewald, it's here: http://leaf.sourceforge.net/devel/ewaldw/Eigerstein2BETA/20010520/ Ewald Wasscher Sincere appologies. Somehow with my current lack of sleep, your name stuck in my head as Eric...I'm not sure how. I've now made the leap from being bad with names in the real world, to being bad with names in e-mail. :-/ Charles Steinkuehler [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Eigerstein?BETA pre-release
My $.02 on the subject is calling it EigerStein 2 Release, but that's just me. ES2B has been around long enough that actually changing the name to ES3 would help avoid confusion, and there's enough of an update to warrant it. I agree. The new image should either be called something other than EigerStein2something. EigerStein3 is OK, but I think enough material has changed to justify picking a new mountain for the release name. Ewald did the work, so he gets to pick the name. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Going walk-about
While I'm frantically working on finishing my new robot for BattleBots, and in preperation for my trip to California, I've disabled mail delivery from the LRP list (due to the high traffic). This is a tempory measure so I won't have thousands of e-mails to sift through when I get home...I'll re-subscribe when I'm back on-line. I'll still be getting mail from the LEAF lists, but it may be a week or two before I filter through old e-mail and reply to anyone, although I'll try to respond to anything urgent as soon as possible. Also, Eric's got a substantial update to EigerStein nearly complete. Saddly, I won't be able to do any testing with this until I get home, but perhaps some of you will want to play with the pre-release version Eric's currently got online. I'm looking forward to meeting those of you who will be at the meeting in San Francisco... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Website Problem
http://leaf.sourceforge.net/content.php?menu=110300page_id=15 Kenneth Hadley just posted a link to my Hard-Disk HOWTO on the Leaf SF site. There is a problem, however, with the document when downloaded from this link. Apparently, the text is being interpreted as HTML, which is generally benign, but re-direction symbols (especially ) confuse things and cause large chunks of text to disappear (ie get interpreted as HTML tags). I think we need to run raw text through some sort of conversion before being included as part of an HTML page...is this possible to do with our fancy PHP site code? Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] seg faults in Eigersteinbeta solved- hopefully
strip --strip-unneeded -R.note -R.comment strip -R is equivalent to strip --remove-section, so some extra information is removed from the binary. I have to admit that I don't really know what information these sections contain. Me neither, but there are visible results: wolfstar@ulrik:~ ls -la libc.so.6* -rwxr-xr-x1 wolfstar users 1382179 May 11 21:25 libc.so.6 -rwxr-xr-x1 wolfstar users 1167916 May 11 21:27 libc.so.6-plain -rwxr-xr-x1 wolfstar users 1108748 May 11 21:27 libc.so.6-extra That's the glibc that comes with SuSE 7.1 - I think glibc 2.2, but I'm not sure off the top of my head. (Probably is, 2.1 was 4 megs unstripped.) libc.so.6-plain was libc.so.6 just stripped as normal, while -extra was done with the funky stuff above. 60k is appreciable. Compressed: -rwxr-xr-x1 wolfstar users 523935 May 11 21:25 libc.so.6.gz -rwxr-xr-x1 wolfstar users 451864 May 11 21:27 libc.so.6-plain.gz -rwxr-xr-x1 wolfstar users 451418 May 11 21:27 libc.so.6-extra.gz 450 bytes ain't much, but it's SOMETHING. (All compressed with gzip -9.) Worth investigating IMO. I don't know about the glibc libraries, but I'm pretty familiar with code sections (thanks to my background with embedded systems, where you have to deal with a lot of detail handled automatically in more complex environments). When writing code, you can tell the compiler/linker which section various pieces of code/data belong in, so the linker knows where to put everything. There are typically a number of pre-defined sections for things like executable code, constants, initialized variables, uninitialized variables, etc... On an embedded system, you tell the linker where to put each section, so your constants and code might go into ROM, while the variables get put into SRAM or DRAM...section information is stored in the executable files and the dynamic loader relocates sections 'on the fly' for complex systems like linux, as well as things like loading any other required libraries, initializing RAM, and other low-level details most folks never worry about. There are several code sections defined by convention on virtually all systems (even things like lowly single-chip micros deal with code sections so you put data in the right place...it's kind of imporant that your bootstrap code actually goes into [EP]ROM, and variables wind up in RAM somewhere), but you can also define your own code sections at will. Unless the linker (or some other tool) knows what to do with the new code sections, however, they won't be very useful. Without going through the glibc source code, and the dynamic loader/relocater (the tool that reads an elf file from your disk, puts it somewhere in memory, and gets everything ready to run), I can't say for sure, but if the names are at all descriptive, the .note and .comment sections don't exactly sound like critical information required to run the libraries. They are likely additional information that might be useful if you're running some sort of advanced debugger, but sound quite unnecessary for our typical floppy-disk based systems. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] BALDG meeting (was: SVLDG meeting)
How to get to Treasure Island: http://www.ci.sf.ca.us/treasureisland/public_info.htm An alternate location would be somewhere in downtown San Francisco, if the transportation to Treasure Island is poor (also, Treasure Island will be swarming with BattleBots builders and spectators...this could be good or bad, depending on your perspective :-). The hotel I'm staying at is the Holiday Inn Civic Center, which is downtown, right off I-80. Also, I'll have transportation, so I could get anywhere reasonably close to downtown (I'll defer to you locals on this...everything looks pretty close to someone from Kansas, but I'm used to cruising at 80 on the highways and little or no traffic...I hear it can take hours to go a few miles out there on the coasts!). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Vulnerabilities dot org
Makes me wonder though. At the start of the scan, /var/log/syslog, messages and kern.log were 15k, 13k, and 13k respectively. After the scan...all *three* of them were over 980k before I ran out of disk space. Sure, a brute-force DOS attack but...what am I doing wrong where each packet log gets recorded in 3 places? This is just how it's setup. I've wondered about modifying this, but it was yet another issue that came down on the side of compatability (ie don't change if it's not necessary). I did actually think about it, though, and you can edit your /etc/syslog.conf file to change this behavior if you want, potentially even creating a log just for firewall stuff... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Vulnerabilities dot org
running, as echo test file won't work if the disk is full. So...be cautious turning Nessus loose on your own LRP box. :) I think this is a problem. I believe the ramdisk shouldn't fill up under any circumstances. Can we change log rotate to trigger on file size in addition to periodically? It's got the ability in multicron, but commented out by default. I haven't formally tested it, but it seemed to worked on my old low-memory router. Still, a check every few minutes to start action seems like a kludgy way to handle it. Jack, Is there an elegant solution to the problem? Either run disk quotas, or put /var/log on a seperate partition, so it doesn't run the whole filesystem out of space. Neither solution is perfect, but making a /var/log partition is already implemented (see my ramdisk.lrp), and wouldn't even require any extra room on the boot device, if we pull the mkminixfs functionality out of the kernel and put it in busybox (see earlier e-mails on booting LRP with a standard kernel). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Vulnerabilities dot org
Charles Steinkuehler, 2001-04-27 11:36 -0500 Either run disk quotas, or put /var/log on a seperate partition, so it doesn't run the whole filesystem out of space. Neither solution is perfect, but making a /var/log partition is already implemented (see my ramdisk.lrp), and wouldn't even require any extra room on the boot device, if we pull the mkminixfs functionality out of the kernel and put it in busybox (see earlier e-mails on booting LRP with a standard kernel). Charles, Is this the design you want to implement in Quercus? Yes. I think the ability to use standard kernels is a big benifit, we get other benifits by moving the code to create format ramdisks out of the kernel and into user space (not the least of which is more flexability). As soon as I get my head out of robotland, I plan to make some scripts that boot this way, to be followed by attempts to see how small I can get a system that can bootstrap a root filesystem to a new ramdisk. If it can be made small enough (minimal busybox linked with uClibc a sub-set of the ash shell), the contents of the bootstrap initial-ramdisk can be entirely replaced by stuff loaded from standard tar.gz files, giving us the greatest flexability. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] EigerStein updates
For those working on updating EigerStein, there are a couple of things I recently remembered that should not be overlooked: Migrate the POSIXness script (/bin/grep) to the multi-file version I created for LRP 2.9.8 (easier to edit/maintain, and it runs faster) Grab the updated vi and new pico config files for the ae editor. Even if we switch to e3, these config files should be part of the ae.lrp package. I'm currently banging on the ELJ eval kit, trying to get it to do something useful...I'll report on BlueCat linux when I get a bit farther along. They do something like we were talking about for development. They build an entire directory structure (in this case with their own compiler, kernel source, and even RPM database). You cd into this directory, run a setup script, and PRESTO! you're all set to cross-compile. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] EigerStein updates
Charles Steinkuehler, 2001-04-25 12:45 -0500 I'm currently banging on the ELJ eval kit, trying to get it to do something useful...I'll report on BlueCat linux when I get a bit farther along. They do something like we were talking about for development. They build an entire directory structure (in this case with their own compiler, kernel source, and even RPM database). You cd into this directory, run a setup script, and PRESTO! you're all set to cross-compile. Charles, I talked to LynuxWorks at the Embedded Systems Conference. The rep. said they didn't support floppies as a target, or generic images. This means that we would have to create an image for every hardware combination. Was the rep. wrong? So far, the Blue-Cat stuff has a very embedded feel to it. No standard linux utilities required/provided at runtime (you have to custom build a disk image if you want things like a shell or the 'ls' command, etc). It even comes with it's own boot loader (like syslinux, except it does tftp/nfs over the network). It's mainly geared towards booting running a custom program. We could probalby use it as a base, but using something like HardHat, which is actually packaging standard linux apps, would probably save a lot of work. While a lot of this becomes moot if we have our own packaging format, it's still nice to have a base distribution that provides major functional packages (like networking, apache, sendmail, etc), so folks have a reference for how to setup init-scripts, where to put config files, etc. More and more of this is becoming 'standard', but we're not to the point of universal compatibility between distributions, and likely never will be. MontaVista said they do support floppies as a target, and generic images. Ray and I should have the new HardHat Linux 2.0 CD shortly. From what the rep. said it should be available for download too. On the down side, it looks like they are only making a subset of packages available for free. :( http://www.mvista.com/products/hhl.html This doesn't seem so bad. Folks can download and create their own free development environment, and I doubt any of the extra platforms supported in the $$$ edition would be required by anyone but a commercial developer, at which point paying for a full-blown development environment is an appropriate course of action. If we needed some of the professional stuff (I think we'd mainly be interested in the additional packages), we could probably get the HH guys to donate a few development systems. In general, I have yet to see anything more suited to being a development platform for us than HardHat. It targets embedded systems, and therefore supports cross-compiling and multiple CPU architetures out of the box. The embedded debian thing showed promise, but seems to be kind of dead at the moment (I get an anyone out there e-mail from the embeddian list every month or two). The embedded Red-Hat also looks kind of neat, but I think the RH folks are trying to force folks to pay for the whole development package...at least the HH guys have a free version (and really, how many folks in our user base are going to be using the GUI based remote GDB functionality anyway, which seems to be the main difference between the free and $$$ versions). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Off-Topic - NAB
Got too much time on your hands? Too much bandwidth to the 'net? Check out NewTek's live feed feed from the NAB trade show floor. Watch demos of Light-wave (3D package), Aura (2D compositing package), and the Video Toaster (live video production switcher). Go to: http://www.newtek.com/nab2001/ebooth.html And pick the 100K or 300K stream... NewTek is the company I work for, and I designed a big chunk of the hardware for the Video Toaster that lets a computer system play/record live, uncompressed D1 Video (digital video at 27 MBytes/s). What's amazing is that modern computers can manipulate multiple streams of D1 video in real-time, mixing, fading, color-correcting, and running DVE effects in the process, with enough CPU cycles left over to turn the whole thing into a windows meda stream (MPEG compressed) and spit it out over the 'net. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Updating Eigerstein:progress
Might I add to the TODO-list, to include Seawall? What does Charles think about that? For most home-users the default Eigerstein firewall rules will be sufficient I suppose. For an updated EigerStein image, the current firewall scripts should remain, or migrate to something like my extended-scripts, which use a superset of the network.conf variables. While I have no objection to using SeaWall, doing so would not create an updated EigerStein, but a new image. This wouldn't necessarliy be bad, and actually, everything but the firewall scripts could be identical. If anyone wants to work on this, I have no objections, but I'd also like to see a version using the current scripts (or an extension of them), so existing Eiger/EigerStein users would have an easy upgrade path. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Patched kernel 2.4.3 (about to be) available.
Any thoughts or ideas? I'm thinking that trimming the fat off of this stuff, combined with UPX, might be enough for us to go glibc 2.1.x or even 2.2.x for base router images. At least then, it would be easier to transition from the basics to the fun stuff. I think glibc 2.1.x or 2.2.x on a floppy with a 2.4 kernel should be the target, until we find some practical reason why this just can't be done... With the numbers I've seen for 2.4 kernel and glibc (especially once glibc gets stripped of debug info) seem to indicate there's no reason we can't make this work, maybe even on a 1.4Meg floppy (although I'd be happy with a 1.68 meg image). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Patched kernel 2.4.3 (about to be) available.
It'd be interesting to see how much each option affected size, but overall a 411K 2.4 kernel is VERY COOL, and should be quite usable for floppy firewalls. While I'd like to see a 'one size fits all' kernel, perhaps there could be a floppy only, minimal kernel, and a larger kernel with all the 'goodies' like RAID, loopback, etc (compiled as modules, where possible) for folks running from CD, HDD, Flash, or what have you. Right. There's none of the MTD stuff compiled into this kernel, and I even went modular on the IDE support. The bitch of it all is that, for some of the ideas I've had, IDE support is Sorta-Kinda-Necessary. I think I'll play around a bit over the next few days and see what I come up with. Well, I generall think almost EVERYTHING should be modules. You can regain IDE support for booting by adding the modules to the initial ramdisk (the linuxrc mods I posted a while ago for my SCSI-RAID support do this). I'm envisioning a single kernel (or perhaps 2, if we don't want the module hooks for RAID, IPSec, and various other higher-end functions taking up space on a single floppy firewall), along with a small number of pre-rolled initial ram-disks (floppy-only, IDE HDD, IDE HDD+CD-ROM, Flash/DOC support, etc). Anyone wanting a really funky or custom boot system can roll their own initrd (or make a custom root.lrp if we stick with the initrd-archive patch use a tar.gz file). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Patched kernel 2.4.3 (about to be) available.
Okay gang, got the FTP security patch from the Netfilter boys and applied it. Kernel is compiled and I'm about to tar and gzip it. I also took the opportunity to go weeding. The final result is as follows: 1. Kernel is no longer able to mount filesystem images on the loopback device. This seems like a bad thing, but it is probably tolerable. Why not make the loopback device a module? Note that a loopback device or a spare ramdisk will be required to backup the initial ramdisk image if we migrate away from the initrd-archive patch and use a plain-vanilla kernel... 2. There is no longer a PCI Device Database, so PCI devices are listed in /proc/pci by card ID. Absolutely no problem here... 3. The Network Block Device was removed, as I couldn't really see a need for it on a secure system. Does it save a lot of space being removed over being a module? 4. Modularized serial support. OK, but this prevents headless boxes controled with a serial cable... Some of these are a little questionable in my own mind, to be honest, so I'd like some feedback from people on whether or not the tradeoff is acceptable. However, the final results are impressive. Here's the previous Standard and UPX-Compressed 2.4.3 kernels: -rw-r--r-- 1 wolfstar root 552k Apr 11 03:45 kernel.standard -rw-r--r-- 1 wolfstar root 481k Apr 11 03:46 kernel.upx Here's the current one: -rw-r--r-- 1 wolfstar root 474k Apr 20 02:38 kernel.standard -rw-r--r-- 1 wolfstar root 411k Apr 20 02:39 kernel.upx So we're looking at about 70-75k of space savings, and that's TRULY spectacular. I might go back in and try putting back the Serial support and see how that affects kernel size, but this is a LOT of space saving. It'd be interesting to see how much each option affected size, but overall a 411K 2.4 kernel is VERY COOL, and should be quite usable for floppy firewalls. While I'd like to see a 'one size fits all' kernel, perhaps there could be a floppy only, minimal kernel, and a larger kernel with all the 'goodies' like RAID, loopback, etc (compiled as modules, where possible) for folks running from CD, HDD, Flash, or what have you. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: Off-list Re: [Leaf-devel] Updating Eigerstein
Is anyone working on this already? If not I will have a start this weekend, or perhaps when I return from work tonight. If you prefer someone else's work please tell me so; it will save me some superfluous work. I haven't seen any progress reports, or been asked any questions...the best I can tell you for sure is that I'm not working on this (just too busy). Feel free to do whatever work you have time for, and just ask if you have any questions or need anything from me. Allright! I'll see what I can do this weekend. As I have a part-time job, no wife and no children I'm not as busy as both of you. Of course I will keep a full log of the changes that I make for you to comment on. One of the bigger changes I propose is replacing ae with e3 or the busybox vi applet. That will make it a lot easier to throw out ncurses a "whopping" 119 kb). If you have the time it would be nice if you could make sh-httpd compatible with the newer ash from oxygen. I can view webpages but cgi is broken. The weblet cgi-scripts do work when executed from the commandline. I added updating sh-httpd to work under Oxygen as a task (assigned to me). I'll try to get this done in the near term, before I go out of town again. I guess this means I'm going to finally have to get an Oxygen system up running...should be fun. Any particular version(s) of Oxygen I need to be working with, or should I just grab the latest? Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] sh-httpd in CVS
Well, I've checked the shell-script web-sever, sh-httpd into CVS. Looks like I'm the first to put something into CVS other than the website...I'm almost giddy over how cool it is to use CVS, and how easy it is to create new directories. I suggest we begin checking in other shell-scripts, like linuxrc, POSIXness, the backup-scripts/apkg, etc. into CVS as well. Has anyone given any thought to how the CVS archive should be structured? Should we have seperate directories for different functions (ie linuxrc vs. POSIXness), and should different distributions (LRP, Oxygen, EigerStein) be seperate CVS trees, or just seperate branches? I think we should try to keep the various distributions in the same tree (though likely as seperate branches...this should help with propogating updates from one branch to another), and possibly have seperate trees for the major functions (ie sh-httpd, and POSIXness are clearly their own trees...how to handle the lrcfg scripts, linuxrc, etc... is a bit trickier). NOTE TO WEB GURU's: I think SF changed the web-based CVS front-end. When I click on the Leaf CVS link from our home-page: http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/?cvsroot=leaf I get a message to go to this link instead: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/ BTW: The new web-based CVS viewer is WAY FAST, and instantly registered the changes I made (ie the 'age' field listed 31 seconds, which is how long it took me to pull up 'click-through' from the LEAF home-page). Way cool! Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) To pre-empt any CVS related questions, here's what I did (warning, some lines wrapped): First, tell CVS to use ssh: export CVS_RSH=ssh Then, create the directory tree you want in CVS. I used my archived sh-httpd.tgz files Untar-gzip sh-httpd V0.3 cd to the directory Import all files (and sub-directories, if there had been any) into CVS: NOTE: Use your sourceforge login instead of cstein, which is my user-id! cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/leaf import -m "Initial CVS check-in V0.3" sh-httpd cstein Release-2822 NOTE: The last two parameters are 'vendortag' and 'releasetag', and don't really matter unless we get into complex CVS trees...(we may with some of the 'core' LRP scripts) That's all there is to creating a new CVS directory. Once I did the above, I wiped the existing directory (which is not under active CVS control), and checked-out the newly created archive (REQUIRED): cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/leaf/ co sh-httpd This creates a new sh-httpd directory, all setup for future CVS use. You could do this with anonymous CVS access, but then you won't be able to check-in any changes you make. I cd'd into the new directory and 'tagged' the files just to be safe: cd sh-httpd cvs -q tag Release-0_4 And that's it! Checkout the SF Docs for more details: http://sourceforge.net/docman/display_doc.php?docid=763group_id=1 ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Oxygen ready sh-httpd
An updated sh-httpd that works with Oxygen is checked-in to the sh-httpd CVS archive. This is the previous change from using `jobs` to /proc/$CGI_PID, and represents sh-httpd version 0.4.1 I currently have this running on Oxygen 032901 at: http://lrptest.steinkuehler.net/ NOTE: Web pages have not been updated to reflect Oxygen file/log layout, so some things are probably broken, but the basic web-server/CGI interface seems to work OK. If anyone has any other problems with the sh-httpd web server, please let me know... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Weblet problem under 2.4 and new ash
Now and then I feel really dumb with some questions, but it took me several hours to find the location of the problem. Analyzing the code, i always assume that the command does what it says, but that just doesn't :( Don't feel at all bad. Actually, spending several hours on this sort of problem is doing pretty good. I've debugged lots of stuff, including a lot of hardware, which can be very painful (no stepping through in a debugger with your entire local context available). The problems with a 'correct' command simply not doing the right thing are VERY hard to track down, and require you to have previously chased down all the 'obvious' solutions, and begin questioning absolutely everything. It's not at all uncommon so spend several DAYS on one of these... Also, as very well explained in The Cathedral The Bazaar, finding the bugs is usually the hardest part, and getting lots of eyes looking for bugs is one of the big benifits of open source...actually fixing a well defined bug is usually pretty trivial (or at least tends to be straight-forward...even if you have to re-architect the whole program, at least you know WHY). A small step further onto the updated eigerstein ;) Hooray!!! Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Updating Eigerstein
I've had my interest renewed in updating Eigerstein, with the realization that Eigerstein ash is broken. I seem to remember having problems with ash in LRP too, but with some patches I received from Erik Andersen (seems to me) I managed to recompile ash and now it works. What I propose is to update every binary (and/or library) possible with a newer version. This does not include major shifts (like glibc 2.0 to 2.1 or 2.2) but would include updating everything else like ip, tracedump, ash, etc. I would staunchly refuse to change the scripts. Would such an upgrade be respectable enough for EigersteinBeta3 ? This would at least extend the life of the current Eigerstein images for a little while, and make more things work... I would LOVE to see this happen. I just haven't had time to go digging through all the new stuff you've compiled and replace the existing versions. If anyone else has time to make this happen, you'll get my full support, and what help I have time to provide (I can at least make the self-extracting images, since I blew the $$ for a licensed copy of WinImage). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Weblet problem under 2.4 and new ash
The next problem I have now, that I don't understand is: After starting the weblet The index page is visible ( not completely as some off the cgi-scripts are broken (no more ipchains etc). But as soon as I take one of the scripts from the cgi-bin it means intermittent trouble. f.e calling viewmasq creates a sh-httpd.xxx in tmp with the content of the page it should display. This temporary file should be "catted" to the page but this is done only once in a few times. (it is no cache problem). The page is created every time as file. The problem seems to be in a construct case $FILE in .. . [ "$COMMAND" != HEAD ] cat (this isnt done every time) esac $OUTPUT( where $OUTPUT is the temp.file sh-httpd.xxx) Anybody a suggestion ? Hmm...the CGI programs are tricky. sh-httpd sits around and waits for the CGI to finish (the cgi script is run as a seperate process), then examins the output before sending it to the client. There are lots of places for things to go wrong, especially if there are some bugs in the shell interpreter (or perhaps just different bugs than in the ash that comes with most LRP's). There's not much I can do without replicating the environment here (which I doubt I have time for unless you can send me a disk image), or a lot more debugging info... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Packaging
else needs/wants). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Nifty CD Idea
The key to making this happen is getting a linuxrc that's smart (or flexible) enough to deal with whatever is required. The other missing piece is a way to communicate with the CD-ROM boot scripts. That would be syslinux.cfg; what is needed (sounds like) is a way to shift the entire "append=" line to another file... You can't change what's on the CD, so you either make some assumptions (like always load config info off a floppy, or a fixed set of devices) or you find a way to save some settings across a reboot (like the unused part of the CMOS ram) that all systems support. CMOS? Uhoh sounds both fascinating and reckless and dangerous - what a mix! I remember seeing something once about a program to stash user data in the unused 1/2 of CMOS RAM that is available on almost all PC systems (at least those made after about 1988). I agree with the above...exciting and scary! I've been leaning towards a CDROM/floppy combination: you can configure the floppy all you want, then load packages from the CDROM. This is what I'm talking about... Um... not quite. You are talking about bootable CDROMs with a configuration disk; I am talking about booting from floppy disk and using the CDROM as a data disk. Your ideas are much more revolutionary than mine. Actually, I want both to work. My CD-ROM currently uses a floppy image to boot. If your system doesn't support booting from a CD, you just make a floppy image and boot off that. The trick is to be able to modify your configuration without changing any of the boot files (syslinux.cfg or root.lrp), which may be hardcoded on the CD. I've also been considering (for a long time) using a CDROM to create a TFTP and/or FTP and/or HTTP server with packages available; thus you can put the CDROM in, boot, then go to another system, boot Oxygen on it, and download all packages via the CDROM system on the network. Hmm...haven't thought about this sort of thing much. I guess I don't generally like the idea of my router or servers booting off the network. Having a resource to load packages from would be a good thing, but why not just have that out on the internet somewhere? Then everyone can use it... You could do that too. The problem with that is: * Security - packages could be compromised - source system could be compromised - router (bridge?) would become visible to outside world, and would be immediately known as a LRP-style router * Availability: if the source goes down or changes IP, the router is dead when it reboots. I was thinking about something more along the lines of the Debian apt-get functionality. All packages are stored locally, but if you want the latest widget package, you go out to an archive and grab it. IMHO, nothing in my running configuration should be loaded across the network at boot time (at least I don't ever plan to setup any routers this way). Beowolf clusters and the like are another matter entirely, however, so it makes sense to have the flexability to do some (or all) booting from the network...are the growing popularity of Beowolf clusters and the appearance of a dhcp client in the kernel coincidence? You be the judge... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Mailing list archive
David, does Oxygen have any reason it would be different from other LRPs, or should somebody give this guy the standard answer? I'm not sure what the standard answer would be. However, the use of the ram disks is hardcoded in linuxrc, and /etc/fstab; the kernel is probably the biggest item since it loads to RAM disk does it not? Perhaps it would be best to load the system normally (with a minimal root) then use root to shift to running from the hard drive and umount and destroy the RAM disk. When you umount a /dev/ram* device, is the memory essentially free and returned to the standard free pool? Or are some resources still used by it? I've seen reports you have to run freeramdisk, but I have yet to verify this. NOTE: Busybox has a freeramdisk function... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Nifty CD Idea
Well, I'm working on documenting how to run LRP 2.9.8 with root on a HDD, and it got me thinking about my CD booting images. One of the main things I can't change on the CD is the size of the ramdisk, since that's a kernel parameter, and I can't change kernel paramaters on a bootable CD without re-burning a custom CD (a bad thing, especially for end-users). The technique I'm using to run LRP off a HDD root partition is to acutally run the LRP startup scripts in a chrooted environment, creating a root environment that is then simply mounted at the next boot (linuxrc is modified to just exit after loading bootstrap modules if root is set to something other than the ramdisk). This got me thinking A slight extension (and automation) of the process to build the root image would make a nice installer to put LRP on your hard-disk for use as a thin server. A few more tweaks, and you could build root on the fly into /dev/ram1 (or any other ramdisk besides /dev/ram0). This would allow on-the-fly configuration of ramdisk parameters (including size and potentially filesystem...a 1/2 Gig ext2 ramdisk LRP system anyone?). Throw in a bit of work to allow an install script to build a boot floppy on the fly (shouldn't really be a problem, with a whole CD to fill with kernel trees, modules, and full blown binaries of tar, perl/python interpreters, etc), and you could make a pretty nifty distribution. While the thin firewall folks would need a CD along with their floppy, if they didn't have to burn a custom CD to get things to work (but could just download an ISO image or by one pre-burned), I don't think that would be too bad. It would also be possible to automatically build 1 or 2 disk stand-alone images directly from the CD... Sound like a good idea to anyone else? This could be what enables Butterfly to work for a large number of existing LRP users, especially if more complicated 2 disk configurations could be created automatically... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
