Re: [leaf-devel] Bering startup flaw
On Fri, 2004-04-02 at 11:28, Erich Titl wrote: Thanks, found it and got all puzzled by the thousands of ways people find to make their code difficult to use. I admit, the sheer mention of G. Knuth in the programming/documentation method used for ifup/down makes one shudder with respect, but still. I need now multiple additional packages (noweb, LaTeX) to just get the real source_and_documentation for a rather smallish program. Does anyone have the notangled source code for ifup/ifdown. There is an ifupdown applet in the busybox 1.0 pre-releases. It is used in Bering-uClibc. Ewald --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering on CD
On Sat, 2004-02-28 at 13:19, Charles Steinkuehler wrote:
The various forms of ${} substitution that exist in both ash and bash
are very powerful, and can do most string manipulations if used in the
right combination (see weblet for an example of lots of fancy tricks
with shell paramter expansion :).
IIRC Oxygen linuxrc is another such example, and doesn´t even need sed.
Ewald Wasscher
---
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id56alloc_id438op=click
___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Possible framework for build-from-source system.
Hello all, I am currently evaluating GAR, the build-system from http://www.lnx-bbc.org/ for use with leaf. So far it looks really good. It's flexible, quite well documented and there are lots of examples for building packages, a bootdisk or an iso image. I encourage anyone interested in the subject to take a look at the above site. Ewald Wasscher --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Possible framework for build-from-source system.
On Tue, 2002-09-17 at 20:57, Mike Noyes wrote: On Tue, 2002-09-17 at 11:37, Jacques Nilo wrote: One key question is the development environnement to be chosen. I understand that you consider slink as being outdated which is true but which is still the only way to have a single floppy based distro. I know that some users have switched to other media but I have the impression it is not the majority (Mike: what about a poll on this on the leaf site ?) Jacques, I'll attempt to get our phpWS poll code working. I'll keep you informed of my progress. Would it be a good idea to create a leaf-stats package that periodically sends an email with details about the system. Of course only after approval of the user. To get an idea of what I mean: http://gentoo.iq-computing.de/ Ewald Wasscher --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Possible framework for build-from-source system.
On Tue, 2002-09-17 at 20:37, Jacques Nilo wrote: Le Mardi 17 Septembre 2002 19:18, Ewald Wasscher a écrit : Ewald: Following on this and the previous thread on buiding Bering from source tree, please feel free to test that or any other approach to test your ideas on building Bering from source since apparently their an interest for it. Ah great to hear this! I will do so after (or paralell with) the next release of Dachstein. I am ready to help you on this project (I won't have much time to work on it myself and even if I feel that there will be many questions/obstacles along the way, I think it might be worth trying). Nice to hear this. I'll appreciate any help, also if it isn't much. One key question is the development environnement to be chosen. I understand that you consider slink as being outdated You understand that correctly. which is true but which is still the only way to have a single floppy based distro. I don't agree with you that it's the _only_ way. But maybe we can keep glibc-2.0.7 as an option. I know you have been wary of uClibc and other c-libraries targeted at embedded systems in the past, but I think it is possible to have a base system with uClibc (and AFAIK all of the programs on the Bering floppy can be built with it). If you want to discuss the use of uClibc maybe we can move that to another thread? Furthermore there is still some room left for space saving in Bering: - mkfs.minix from asmutils. - switch to ash from busybox - ? development branch of busybox is smaller - compile iptables with the extensions linked in statically. I know that some users have switched to other media but I have the impression it is not the majority (Mike: what about a poll on this on the leaf site ?) Yes! Polls! Polls! Polls! (What branch do you use? What hardware? What purpose? What do you want added/changed to leaf? Would you switch to a glibc 2.2 based leaf even if it would be bigger? etc) Some recent programs (e.g. freeswan userland stuff) have to be patched to compile cleanly with slink. That is one reason I don't like using glibc 2.0.x. The major other ones are the not exactly known but almost certainly present security holes. Would you be ready to do that on - say - a slink and woody based environnement ? If necessary. But I think I prefer a combined uClibc/glibc 2.x.y approach where x=2 or x=1. Suggestions /comments from the list ? Yes please, give them. Ewald --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Boot sequence hangs at starting cron.
On Thu, 2002-09-05 at 16:16, Eric B Kiser wrote: I have finally gotten the hardware together to set up my development station and have been working on getting UML set up as per Jacques' Developing and using LEAF in a virtual environment documentation. When I execute the command... ./linuxuml-2.4.XX-YY ubd0=root_fs_slink ...the boot sequence hangs at... Starting periodic command scheduler: cron. Any suggestions would be greatly appreciated. For me Jacques' kernel didn't work (gentoo 1.2 vanilla kernel 2.4.19) and I rolled my own. Ewald Wasscher --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] DS 1.03 todo (Was: Dachstein v1.03 CD?)
I'd like to add: update dhclient.lrp to fix problems for some ATT users create a udhcpc.lrp package based on Lynn Avants' udhcp.lrp Ewald Wasscher --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] inittar
Hello all, Perhaps this isn't news on the list, but I came across a replacement for the initrd_dyn kernel patches from lrp here: http://www.escape.de/users/outback/linux/ And for those who don't speak German: http://www.escape.de/users/outback/linux/index_en.html This will allow: - easily changing the size of the root filesystem without any initrd hassle. - removing support for minix filesystem from the kernel, remove mkfs.minix to save some diskspace. I think it can be a good solution until the initramfs that appears to be going into linux 2.6 arrives. Comments and flames are appreciated. Ewald Wasscher --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: [leaf-user] Webbased configuration
On Thu, 2002-08-29 at 21:59, Charles Steinkuehler wrote: using sh-httpd. or a small server (boa, thttpd) It looks as if almost noone knows about mini_httpd (http://www.acme.com/). It's from the same authors as thttpd. It's a little slower than thttpd, but smaller (40k vs. 71k) and it can be built with ssl support! It can be done with sh-httpd. Mosquito has used thttpd, but thttpd is considerably larger (and more versitile). My vote would be to use sh-httpd w/POST patch. IMHO, any web-administration utility should be fairly web-server neutral. Since sh-httpd is small, and presents what I believe is a standard CGI interface to back-end programs, it is a good candidate. It should be possible to use boa, thttpd, apache, or any other CGI-enabled web-server with little difficulty, however. Anyone who would like to volunteer to work on any ideas, code re-work within the existing Weblet, or developing the new code-base for CLI/WWW configuration integration would be welcome to participate. snip I am presently starting work on the framework. I believe that this is more of a devel topic, so I am moving the thread to leaf-devel. Is anyone ready to work on and/or discuss any sections of this??? I can commit to any updates/modifications to sh-httpd that may be required. I think it's possible to dramatically increase the CGI response of the existing sh-httpd when running CGI's, which would be a big help for a CGI driven admin interface. I haven't looked at sh-httpd recently, but some form of authentication may be a good idea if it's used for a configuration interface. I can also help with architure, debugging, and (hopefully) crafty solutions to difficult scripting problems, but I can't commit to writing a major chunk of code due to current time constraints (although this may change suddenly if the company I work for suddenly craters :-/ ). *WACKY THOUGHT* - If we use sh-httpd as the web-server, and shell-script CGI's, would there be any benifit to wrapping the whole thing into a unified structure? In other words, create a custom script-based CGI interface, rather than trying to match standard CGI...something like a shell-script version of PHP. It could probably be faster/smaller than sticking with a conventional web-server/CGI approach, but would be less portable to other web servers. Something to think about. *WACKY IDEA #2* I've been investigating forth, and will be working on a micro-controller based hygrometer project running forth on an Ateml AVR processor in the near future. I've been wanting access to a scripting language more powerful than shell-script on LEAF, and I think forth might fit the bill. It's possible to compile forth without *ANY* libc requirements, but with the ability to talk *DIRECTLY* to the kernel (so you could load libc and make calls to it, if you really wanted, and do pretty much anything you want...remember the irreplacable part of libc is essentially an interface between C programs and the kernel, the rest is just a bunch of standard routines to make programmer's lives a bit easier). That's a lot of power for an interpreter that would probably weigh in at 10K to 20K Bytes, with code that can potentially run at near optimized C speeds (ie *WAY* faster than shell-script)! I've wanted to code an initial bootstrap loader in forth for a while (something that would boot from CD/Floppy/whatever, and optionally swap out the kernel, allowing fancy boot-time configuration w/o having to re-burn a CD to set kernel options. The ability to make kernel calls from a script, w/o having any libc or /bin/sh dependencies is very cool for a boot-loader. I also think an available forth interpreter could potentially help the construction of a new packaging system as well as fancy CGI admin scripts. That sounds really cool. I can volunteer time to help craft a forth implementation for LEAF, if anyone else is interested... I'll have a look a forth first. I did come across a small forth interpreter here (eforth): http://www.lxhp.in-berlin.de/index-lx.shtml I just built it, and the static executable is 22k small. Compare that to ...oh, if you really want to get wacky, the web-server could be written in forth, too! There are more people with such ideas :-) http://www.jwdt.com/~paysan/httpd-en.html It seems to be included in the gforth distribution. Ewald Wasscher I'll be back --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: [leaf-user] Webbased configuration
On Fri, 2002-08-30 at 21:40, Charles Steinkuehler wrote: I'm well aware of mini_httpd, but it's 40K...sh-httpd is about 9K (including the conf file), and it's text so it compresses well in *.lrp packages! Agreed! There's also micro_httpd, but it won't do CGI... You can wrap most any inetd based webserver (including sh-httpd) to get ssl support, if you can afford the space. I can commit to any updates/modifications to sh-httpd that may be required. I think it's possible to dramatically increase the CGI response of the existing sh-httpd when running CGI's, which would be a big help for a CGI driven admin interface. I haven't looked at sh-httpd recently, but some form of authentication may be a good idea if it's used for a configuration interface. IMHO, this should probably happen outside the web-server. I could code basic authentication into sh-httpd, but that's never really going to be secure. I'd suggest either using an authenticating (and possibly encrypting) front-end like ssh, or off-loading authentication to the system (ie running su as part of the CGI scripts, and providing the root or an admin password) while encourgaing the use of encryption (ssh, zeebee, or similar) if accessing remotely to prevent clear-text passwords traversing the 'net. I'll have a look a forth first. I did come across a small forth interpreter here (eforth): http://www.lxhp.in-berlin.de/index-lx.shtml I just built it, and the static executable is 22k small. Compare that to Yep...apx 20K for a *POWERFUL* scripting language that allows you direct access to kernel system calls! The code isn't pretty to look at, and it's pretty cryptic if you're not passably familiar with the notation. I especially like the kernel level forth also at the site above...one of the current big Forth applications is Open Firmware, which is how Suns and several other systems (including most PPC systems, IIRC) boot...rather than native code, the firmware roms on various plug-in cards contain small forth routines, which both saves space, and allows CPU/OS independent boot-strap code (of course, native compiled optimized drivers are loaded once the system is boot-strapped). I can see something similar being useful for boot-strapping LEAF w/o having to have 100K shell and 500K of libc...not to write hardware drivers, but to build/extract the initial ramdisk, do the kernel-two-step switch-a-roo to allow booting a selectable kernel w/o custom CD imgaes, and other things that are difficult to do with plain shell-script. That sounds good too, but who is going to code such a thing for LEAF? Ewald Wasscher --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] my stuff (uClibc based root)
arne @ loopback . org wrote: On Mon, Jan 28, 2002 at 07:52:06AM +0100, Ewald Wasscher wrote: arne @ loopback . org wrote: Hi, sourceforge/leaf. Note that this is not complete, it does not build a real working root.lrp yet, Too bad, that was what I was hoping to see. Yes, me too ;-) I am working on it, but as my priority is finding a new job right now, i am not sure how much time i can spend on it in the next few weeks :( That's a pity, I wish you luck finding a job. stuff from src.tgz into your src dir (e.g. /usr/src) go into it, become root (needed for some install scripts) , Perhaps we should consider the use of fakeroot for the next-generation leaf, to avoid this. Anyone an opinion? Yes this might be a way, of course. But the main problem is that there is time when this will fail, especially creating the real root install dir ( the root.lrp) which has to be done as root to get the right permissions. expecially for tinylogin which needs to be suid root.. Or do i missunderstand fakeroot here ?? I haven't worked with fakeroot a lot, but AFAIK it was designed exactly for the purpose of building (.deb) packages completely as a non-root user. It isn't a big download, so you could pick it up from debian or rpmfind and have a look at the manpage. and make a ./makeit make and go out for lunch. If you do that its a good idea to redirect the output to a file... After that use ./makeit install to install the stuff into build/root you find the scripts for making/cleaning in src/scripts all binaries in src/build/ ... I will have a look at it, Thanks, all binaries should be installed correctly, Execpt that I didn't have kernel sources where iproute2 expected them. there are some scripts missing that are not copyied, though. Have you ever taken a look at an Erik-Andersen-ish buildroot like the tuxscreen-buildroot, the UML-uClibc buildroot? These are all makefiles, and download the missing source-tarballs needed. It looks quite elegant to me. Ewald Wasscher. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] my stuff (uClibc based root)
arne @ loopback . org wrote: Hi, as i write this, i am putting my sources up to devel/arneb on sourceforge/leaf. Note that this is not complete, it does not build a real working root.lrp yet, Too bad, that was what I was hoping to see. but as people might be interested... To have a look at it: install uClibc on youre machine (version 0.9.8 is in the orig-src archive), under /usr/i386-linux/uclibc (the default place). After that put in the stuff from src.tgz into your src dir (e.g. /usr/src) go into it, become root (needed for some install scripts) , Perhaps we should consider the use of fakeroot for the next-generation leaf, to avoid this. Anyone an opinion? and make a ./makeit make and go out for lunch. If you do that its a good idea to redirect the output to a file... After that use ./makeit install to install the stuff into build/root you find the scripts for making/cleaning in src/scripts all binaries in src/build/ ... I will have a look at it, Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] network.conf error?
Matt Schalit wrote: guitarlynn wrote: I'm working on a script that generates Dachstein compliant /etc/modules and /etc/network.conf files and is used as an install option on the lrcfg menu. It is all working at this point _except_ the generated network.conf file. Using the dhcp and firewall options, I get this error on svi network reload: [: missing ] YES: not found YES: not found 1.1.1.2:not found /etc/network.conf: 526: Syntax error: unexpected I can't seem to locate which YES is not found and on 526 the is there on all network.conf's. I've gone through the generated file line by line and can find no difference between the generated one and the one on my present router (cd v1.0.2). Can anyone lend me a hand and find the error? I'm going nuts now! I'm guessing that a control character got in there or something odd. Did you really compare the files to see if they are exactly the same using various unix commands, or did you just read the lines? If you could do an md5sum on both files that was the same, then I'd be convinced, but some sort of cat -v or something would be intersting. Or try to create a network.conf that should be exactly the same as the original and do something like: diff -u network.conf.old network.conf.new Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] [dachstein] lrp.conf/multicron Spacecheck problem
KP Kirchdörfer wrote: snip Long Term: I'd also like to see the configuration directory approach taken to logrotate (similar to my RedHat distributions, which already do this), and even inetd (switch to xinetd?). Using files in a configuration directory makes the seperation of configuration information into packages much easier, ideally avoiding any pre/post package install/remove configuration required (or at least limiting it as much as possible). Good ideas; unfortunately xinetd seems to be tree times bigger than inetd and tcpd. Tcpserver from Dan Bernstein's ucspi-tcp package isn't too big, and has per-service configuration files iirc. Of course it only handles tcp streams. But for the bandwidth monitor and sh-httpd it should work. The micro_inetd from http://www.acme.com/ is smaller of course, and only handles one tcp service at a time. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2
KP Kirchdörfer wrote: snip Anyway, I could think of a core that boots without glibc and loads glibc 2.0.7 for floppy releases and glibc whatever for CD, HD et al... I think supporting 3 different c-libraries at a time will cause lots of problems for users, and for the developers supporting them. I'd prefer to drop support for the ancient glibc-2.0.7. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2
Luis.F.Correia wrote: Anyway, I could think of a core that boots without glibc and loads glibc 2.0.7 for floppy releases and glibc whatever for CD, HD et al... I think supporting 3 different c-libraries at a time will cause lots of problems for users, and for the developers supporting them. I'd prefer to drop support for the ancient glibc-2.0.7. Question: If we drop support for the ancient glibc-2.0.7, will we still able to use the floppy versions? That will become a bit more difficult. I don't have any exact numbers, but I estimate that glibc 2.2.x will take around 225-250 kb more diskspace than glibc 2.0.7. That why I've been mentioning uClibc for the last few months. Unfortunately not all programs will compile out-of-the-tarball with uClibc, but I think enough programs do to build a decent base system for leaf. For some extra programs glibc will still be needed, but much of that fancy stuff probably won't fit on a floppy anyway. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2
Charles Steinkuehler wrote: snip My intentions for the next major release is to go to geographic names, reflecting locations near me (ie small towns in North-East Kansas: Auburn, Dover, Grantville, Perry, Lecompton...all places I bicycle to), but I'm open to other ideas. There may also be an intermediate set of experimental relesaes, as packaging issues, and issues with updating glibc, the kernel, and the boot process get hammered out. Do you intend to work on this in the near future? I would like to work on a new Dachstein release, so I would appreciate if you'd let me know where I can help. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2
Charles Steinkuehler wrote: Let's start with a wish list, then folks can start working on whatever pieces interest them. Good idea! Any nifty way we can use the PHP website to keep the wish-list dynamic and updatable by many people? Some kind of WikiWiki perhaps? If Mike doesn't come up with something I'll see if I can find an appropriate one. - 2.4.x kernel After playing with the 2.4.x kernels, I believe that 2.2.x still has better support for protocols that are difficult to masquerade, like directplay, msn messenger etc. That could be a reason to keep 2.2 as an option. - Boot-strap code modified to use features available in unpatched kernel (ie no more linuxrc-always or initrd-archive) - 2.1.x or 2.2.x glibc or perhaps uClibc for the core packages, and glibc as an additional one when it's needed. - Use of new 2.4.x kernel ramdisk/temp filesystems - Updated packaging system Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] [dachstein] feature add
Matt Schalit wrote: [EMAIL PROTECTED] wrote: Charles, For Dachenstein, not having set it up yet myself. Perhaps a specific menu item to back up the ssh keys... hThat just doesn't sound right. Well, I'll post it anyway to generate thought. -sp How about deciding to call leaf stuff leaf and not lrp anymore? .lrp files lrp all over sourceforge documents. Perhaps we could make use of a change of the suffix in the package names to make a distinction between the older lrp packages and a new new more featurefull leaf format :-) (OMG what topic did I bring up) Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Proposed change to shell devel tree
Mike Noyes wrote: Everyone, Here is a revised version of my previous post. We need to make some changes to our handling of individual developer content. We are running out of space on the shell server. SF only allocates a maximum of approximately 1G of space on the shell server. Our devel tree is currently using 772M. Proposed changes: Kernels shall only be provided in tarball format. This is a pain if someone only needs a module for e.g. a nic. This would require downloading 5M when you only need a 15k module. Perhaps obsolete kernels could be removed? Charles seems to have 186M of kernels/modules, and only the 2.2.19-3 kernel has all known security holes fixed, so the others shouldn't be used anyway. * space savings over individual files * tarballs only take a few minutes to download even at V.90 speeds Agreed, but IMHO it's still a waste of bandwidth. Archive developer directories on the shell server that haven't been updated within the last six months. A tarball of the developer's directory will be placed in our cvs repository. It shall reside in the developers personal devel tree in cvs. After the tarball is verified, the devel directory on the shell server will be removed. * reduce tech support questions about old files * developer directory can be restored from cvs * space savings on shell server Opinions, comments, and/or suggestions on this proposal are welcome. At your service! Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] New LEAF user Choose version FAQ
Scott C. Best wrote: Some old versions of LEAF can run on a 386SX, but for the more recent versions/branches a 486DX33 with 16Meg's of RAM is suggested for a floppy versions (24 Meg's for the cdrom versions) for cable modem users and an old Pentium 133 with suggested 24Meg's of RAM should saturate a T1 WAN connection unless you running an encrypted VPN gateway. That's a busy sentence. :) Content wise, the old versions of LEAF were actually called LRP: LEAF didn't start until Eigerstein really. Also, cable-modem users could fairly be called cable/dsl modem users. Lastly, the saturation capability is primarily a function of whether the NIC is an ISA card or a PCI card, not so much the processor speed. My 486 DX2/66 used to push 4,5 Mbit between DMZ and the internal net with _PCI_ nic's, so a 486 is capable of doing a bit more than one might think from the above. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS Structure Update
Mike Noyes wrote: Everyone, The last thing I did before disappearing for the last couple of months, was to restructure our CVS repository. All developers now have a personal tree in devel/yourname. There is a bin directory for released files. The oxygen and dachstein trees are controlled by David and Charles respectively. Please notify them before committing/adding anything to those trees. I will create a bin/packages directory for us too. The doc tree is self explanatory. The src tree structure is pending (consensus required). Is there ever going to be any consensus? The issue seems to have been forgotten lately. I might set up my personal cvs tree, but I'd rather not do so. If you need help with CVS commands please let me know. I'll update the Individual Developer Content FAQ in the next couple of weeks. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/ Any comments or suggestions are welcome. I'll see what I can come up with. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: [Leaf-user] Dachstein source tree?
David Douthitt wrote: snip Interested? Are there Dachstein patches to busybox? None that I know of. But POSIXness currently uses the ash getopts builtin, so using busybox ash would either require enabling it in ash.c, or some changes to POSIXness. Ewald Wasscher. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] LSH packages available for testing.
Hello all, I have put together some LEAF packages for LSH. I would appreciate it if some people could test them. In noone finds a problem I'll send an announcement to leaf-users this week. To quote myself: LSH* version 1.2.5 packages. LSH is a free (GPL license) implementation of the SSH version 2 protocol. The main reason I made lrp packages for this is that the daemon package is about 120kb smaller than Jacques Nilo's excellent OpenSSHd package. Because it also doesn't need zlib you will save 145kb to 150 kb of diskspace compared to the OpenSSH sshd.lrp. The drawback however is that the stable branch doesn't support sftp; and scp doesn't work with the Windows graphical scp clients I tried. If anyone succeeds let me know. OpenSSH scp works fine. OpenSSH for windows can be found here: http://www.networksimplicity.com/openssh/ OpenSSH under cygwin works fine too of course, and can be found here: http://sources.redhat.com/cygwin/ An excellent graphical SSH client for windows is Putty: http://www.chiark.greenend.org.uk/~sgtatham/putty/ Oh and before I forget: This software is provided as-is, without any warranty. Ewald Wasscher [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] LSH packages available for testing.
Hello again, The packages can of course be found here: http://leaf.sourceforge.net/devel/ewaldw/packages/ Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] [ leaf-Patches-500162 ] routerst - router status via browser
arne @ loopback . org wrote: just where to get this Routerst.lrp ?? Here: http://www.digitech.org/~tjunkie/ Ewald ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Console (newt based) Interface
arne @ loopback . org wrote: Hi, i spent my last two weeks in playing around with my gcc again, and made a first test version of a text/menu based version of a config frontend for lrp (it currently works for my version for kernel 2.4, based on lrp 2.9.8 and soon uClibc). I've been playing with uClibc too lately, and with a little help most binaries build with uClibc (or I chose an alternative). Perhaps we could share some experience through the list ? For now it just configures the stuff in the network.conf, but this will change in the future. I would make versions for other lrp based dists also (like dachstein, oxygen ??), but it should be clear that this will only work with configuration files NOT containing anything else than configuration keys-value pairs and comments (and no shell script functions like dachstein had in previous versions). This version now works (most of the time) and is intented to be a test, i know that i will have to rewrite a lot of things. It is not ready for production use, but i would people to have a look at it if they like (and help me find bugs, etc.). If anyone is interested, mail to me and i send you a copy of the program (bin only, the src will follow the next days). Yes please. Or just post it somewhere on the net. It is statically compiled against uClibc and minislang and is 125KB in Size (the tar gz is aroung 56kb). So that will be around 30-40kb for uClibc I guess. So it will get smaller. :-) It should be possible to get this even smaller, as size was not so importend for this test hack. I would just like to know, what people think. I do like the idea. But I wonder if it will be worth the extra space this takes when we switch to a decent libc finally (if ever). But of course you are using uClibc. BTW, while we are at it, Charles, how do you feel about a uClibc based version of Dachstein? I've been playing with this a bit lately and it seems doable. The worst problem was finding an ssh version that builds with uClibc (only lsh does). Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Console (newt based) Interface
Charles Steinkuehler wrote: I do like the idea. But I wonder if it will be worth the extra space this takes when we switch to a decent libc finally (if ever). But of course you are using uClibc. BTW, while we are at it, Charles, how do you feel about a uClibc based version of Dachstein? I've been playing with this a bit lately and it seems doable. The worst problem was finding an ssh version that builds with uClibc (only lsh does). I don't have a problem with a uClibc version of Dachstein, but I'm not sure I want to make uClibc the only available library. uClibc and glibc can be used together without a problem. Everyone who develops with uClibc does so and it's very convenient. I'd probably prefer a system where uClibc was used to make some specific pieces of code small (and probably statically linked, like a boot-loader), This may be usefull, but it does add to the _total_ system size. So for the proverbial one floppy system this would be worse than just a normal libc. I put together a bootloader which did nothing but load root.lrp for Dachstein, and it would use 69k of diskspace. Statically linking busybox with uClibc adds about 60k to busybox' size (for the Dachstein configuration, no NFS support for mount/umount). or perhaps something like using uClibc for the core firewalling functions (ie the packages on Dachstein-Floppy or their equivelant are all compiled against uClibc), while folks with more space can load a modern libc from CD or HDD. That sounds like a VERY good idea to me. I'd prefer to use a standard libc for most runtime applications, if the overall system size can be kept under control. For sure that would be easier. But to quote Arne: its more a hobby for me to get things small Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Console (newt based) Interface
Richard Doyle wrote: snip Eric Anderson is still maintaining it. I also don't know how to evaluate the security of uClibc, as opposed to glibc. I've seen others asking about this too, and I've been wondering about this myself. I wouldn't know how it compares to a recent glibc, but compared to glibc 2.0.7 which hasn't been maintained for quite some time it can hardly be worse. At least it is being maintained. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Linux 2.4.16
David Douthitt wrote: Second question: I STILL can't get 2.4.16 under 500k in size - I can't even get it under 600k - even compressed. Even though I strip practically everything out. Why is that? Do I really have to give up over 100k of floppy space to the Linux kernel? Do you care to share your kernel configuration file? I know 2.4 is bigger, but I'm surprised it's that big. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Finding CD-ROMs
Charles Steinkuehler wrote: Well, after the previous discussions on how to find CD-ROMs, cut Perhaps this has been mentioned before, but according to this article http://www-106.ibm.com/developerworks/library/l-fs4.html devfs finds cdroms automatically. All cdroms will be listed under /dev/cdroms. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] initrd confusion
David Douthitt wrote: 4. Does it matter whether a zImage or bzImage is made? I thought not - but then initrd.txt implies that it matters, as there is a bzImage+initrd p atch alluded to... Usually I just make bzImage, and have never run into any problems. 5. What is the status of /dev/initrd? Do we need it? What is it for? initrd.txt says it can be useful; devices.txt says that it will be obsoleted as of 2.6. I don't think we will need it. If I understand Documentation/initrd.txt correctly, it can only be used when the initrd is loaded, but _not_ mounted as the initial root fs I don't understand when it might be useful. One interesting thing I never thought of - but which was suggested by initrd: use init=/bin/sh or link /linuxrc to /bin/sh both VERY interesting ideas... Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] initrd confusion
David Douthitt wrote: I figured some things out... SOME I modified the kernel to answer the questions for me :) So now I have Oxygen booting with a standard Linux kernel - very nice. Too bad that the initrd_archive patch seems to be going away... But maybe we will have the initramfs someone posted about a while to replace that :-) This was the BIG trip up; ROOT= must NOT be /dev/ram or /dev/ram0, but anything else. initrd.txt never says this... in fact, initrd.txt never considers the fact that it might be used for a floppy-based Linux... At least for 2.4 kernels this isn't completely correct. I put together a small-as-possible bootloader package and it runs with root=/dev/ram0. But, I do specify init=/linuxrc, just like Jacques. 2. How does all of this interact with the kernel value returned by rdev? Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] initrd confusion
David Douthitt wrote: David, I found this url from the 2.4 initrd.txt quite interesting. You may find it interesting to at least skim through it: [1] Almesberger, Werner; Booting Linux: The History and the Future ftp://icaftp.epfl.ch/pub/people/almesber/booting/bootinglinux-current.ps.gz On 12/28/01 at 10:20 AM, Ewald Wasscher [EMAIL PROTECTED] wrote: David Douthitt wrote: This was the BIG trip up; ROOT= must NOT be /dev/ram or /dev/ram0, but anything else. initrd.txt never says this... in fact, initrd.txt never considers the fact that it might be used for a floppy-based Linux... At least for 2.4 kernels this isn't completely correct. I put together a small-as-possible bootloader package and it runs with root=/dev/ram0. But, I do specify init=/linuxrc, just like Jacques. From what I've been reading, what you and Jacques have done is cheating :) Maybe with respect to running init you are right, though I would call it making use of new features of the linix kernel.. Here is the two methods compared: EWALD/JACQUES 1. initrd.gz is loaded into /dev/ram0 (ROOT=/dev/ram0) 2. The kernel recognizes root is /dev/ram0, and does NOT run /linuxrc 3. The kernel then releases memory and exits the load process 4. The kernel runs init (INIT=/linuxrc) 5. Your linuxrc performs a pivot_root (if necessary) and runs init by hand. Agreed. IMHO the advantage of this approach is that it probably will be a bit more future-proof, according to initrd.txt and [1]. The obvious disadvantage is that it doesn't work with 2.2 kernels. OXYGEN 1. initrd.gz is loaded into /dev/ram0 (ROOT=/dev/ram1) 2. The kernel recognizes that root is NOT /dev/ram0, and then DOES run /linuxrc 3. The kernel then releases memory, performs a pivot_root, and runs /bin/init At least 3. is an older mechanism that may be removed in future releases as initrd.txt states. A disadvantage of this approach is that it doesn't work with tmpfs and nfs-root (the latter isn't much of a problem for us). The advantage is that it works with both 2.2 and 2.4 kernels (for the near future at least) No unusual kernel parameters required. I might suggest too, something that had occured to me: what about an entry in the inittab that runs /linuxrc? I agree with Charles here. But I digress: I think my way is the most standard way; what do you all think? I think that your way is the standard (and only) way with 2.2 kernels. It still works with 2.4 kernels, but may not do so with future releases of 2.4 and later kernels. From the little I have read about initramfs etc.I understand that more of the late booting process (like finding and mounting the root filesystem) will be moved to user space in the future. Considering this it makes sense to do things like pivot_rooting and finding and mounting the root filesystem yourself instead of relying on the kernel to do this. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Development on 1.9
David Douthitt wrote: I've begun working on the next generation... and have Oxygen booting with an initial RAM disk - in preparation for running without the linuxrc patch. Running without the initrd archive patch takes just a bit more, but shouldn't be too hard. Basically, what happens is linuxrc sets up a very basic root filesystem on /dev/ram1, copies itself over, then runs the bulk of the loading in a chroot'ed environment on the root filesystem. When it's all done, it dismounts everything it can and lets go - to let the kernel load init and swap root. Questions I'd have would be: 1. What parameters are from the patches and what should the non-patched kernel parms be? I suspect initrd_archive is an added parameter; I also suspect that root= should now read (in my case) root=/dev/ram1 - as this is what is used as root after everything is done. Isn't root= the device where the initrd will be put? For 2.2 kernels root= and initrd= will do I think. Initrd for 2.4 kernels is a little different, but can be used the old way for now. You could take a look at Jacques' kernel 2.4 based distro for how this can be done. See Documentation/initrd.txt in your kernel source tree. The linuxrc-always and the initrd-archive patches modify this documentation though, so keep that in mind. 2. What is the filesystem of the initial archive supposed to be? Can it be minix? It can be minix, but at least ext2 and romfs work. Romfs has the advantage that it's very small. A kernel with tmpfs+romfs is still 5k smaller than one with just minix. and mkfs.minix is bigger than genromfs (14k versus 10k), though busybox mkfs.minix may be smaller. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Oxygen Updates
Luis.F.Correia wrote: Nathan, When booting from a CD, the only floppy formats supported are 1.44 and 2.88. David, others, is there a reason for using syslinux instead of isolinux? I'd say it's easier to use isolinux and forget about floppy images on the CD. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Oxygen Updates
Charles Steinkuehler wrote: David, others, is there a reason for using syslinux instead of isolinux? I'd say it's easier to use isolinux and forget about floppy images on the CD. I don't know about David, but I've stuck with using a floppy disk image for a couple of reasons: 1) It's generally easier for me to maintain...the boot-disk is a very simple case of a standard distribution floppy. Easier? I diagree, but forget it. 2) It's easier (IMHO) for end-users to modify the floppy disk boot image if they need to burn a CD than it is to modify the isolinux configuration and make a bootable CD. I'm not even sure you could make a bootable CD on windows using isolinux and commonly available CD Burner software... Good point. It may be possible as cdrtools (mkisofs) compiles fine under cygwin. I haven't tried though. But I agree it will be harder for many end-users. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Back again.
Hello all, After a long time away from leaf I intend to become more active in leaf (dachstein) development again, if my time allows it. I feel a bit ashamed for abandoning dachstein so suddenly, but I hope the few contributions I will make are appreciated. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Ewald's Updated ES2B
7Charles Steinkuehler wrote: 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 I have 2 options in mind. The first one is Dachstein, which is a mountain in the Hohe Tauern (Austria iirc). This would make a more or less obvious connection to Eigerstein. The other one is Alpamayo (Cordillera Blanca, Peru) which is considered one of (if not the-) the most beautiful mountains on earth by many. I tend to favor Dachstein a little. Any opinions? - 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... That was more or less on my todo list. Perhaps pull the links to linuxrouter and put them in the readme.txt. And if we want to waste disk-space we can add a graphical splash-screen! (.e.g with the leaf-logo) - The readme file needs to be updated with (at minimum) new links and new instructions for e3 rather than ae as the editor This was on the todo-list too. - The readme instructions need to be verified (ie put on LUser hat walk through the readme like a newbie, making sure nothing unexpected happens). I'll ask a friend to do a beta test, or perhaps my parents :-) And on to 'real' changes required/desired: - I'd like to see the java bandwidth applet added to the weblet package OK, what about Justin Ribiero's modifications George Metz mentions on his pages? I haven't tried these though. - 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 Good, I agree. - 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. This was on my todo list for another release, as well as support for loading kernel modules from linuxrc. What do people think about that last point? - 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. If I understand the description of the 1.1 scripts on lrp.steinkuehler.net correctly these are an extension of the 1.0 scripts, and incoporate all of the 1.0 features? Before I was worried about 1.1 not supporting port-forwarded dmz servers. I'd like to see future images use seawall, rcf, or similar. I think it's a good thing to leave firewall scripts to the experts. I used to make my own until I realized that others did it very much better. 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... Like eh, me? I'll leave dnscache to Jacques of course. Does anyone think it makes sense to use the new FORWARDONLY option (since djbdns 1.03)? It seems to me that especially on a slow dialup line it will be slower to let the firewall do dns-resolution than to use the ISP nameservers. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Pb with dhclient Eigerstein BETA2_test_20010527
Hello all, Sorry for not reacting to the discussion, but I have baan AFK for 2 days and I won't be able to do more than this email for a day and a half probably. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Back online
Charles Steinkuehler wrote: 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. That would be nice. Jacques Nilo has reported some problems with the dhclient package. I wonder if you could have a look at it? Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Working with libraries....
David Douthitt wrote: Ewald Wasscher wrote: I thought libnsl was the Name Switch/Service Library. So I think anything that uses the system libraries to lookup users, hostnames, ips, protocols etc will need it. NSL appears to be the NIS Support Library; The Name Service Switch is supported by the libnssl (Name Service Switch Library) and all of the other libnss* files. The only functions in libnsl were yp_* functions... I see, I was mistaken. There are some binaries (packages) that need it, but I suspect all of them likely use it for NIS, and I suspect that a recompile without NIS support will get rid of that dependency. I also suspect that as long as the NIS support functions are never used, then there will be no missing library problems and errors. The only binary I can remember that had support was cpio, but there was about three or four. On Eigerstein2BETA (the updated one) there appears to be no binary linked with libnsl. Perhaps it's time to remove it :-) Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] New Eigerstein2BETA_test_20010527 snapshot available
Hello all, A new snapshot of the updated Eigerstein2BETA, together with a number of new LRP kernels is available here: http://leaf.sourceforge.net/devel/ewaldw/Eigerstein2BETA/20010527/ It contains a number of important fixes since the last snapshot. For more information about the changes since the last snapshot please take a look at the README and the Changelog at the above URL. If noone finds a major bug and Charles Steinkuehler agrees there will be a release by the end of the week. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] New Eigerstein2BETA_test_20010527 snapshot available
Jacques Nilo wrote: A new snapshot of the updated Eigerstein2BETA, together with a number of new LRP kernels is available here: Hi Ewald ! First of all congratulation for the great work. It looks like you are getting close to the new Eigerstein release. I installed the 20010527 release on my box. Follow my comments and suggestions 1/ dnscache There is to my opinion a bug in the dnscache.conf file. $IPSEND should be initialized with 0.0.0.0 and not with $EXTERN_IP. Otherwise you need to restart dnscache each time your external adress change (and therefore you loose your cache) when you have a dynamic IP. With $IPSEND set to 0.0.0.0 (this is what has to be done according to DJB install instructions). As far as I remember K. Haddley (I think) had problems of this sort which were solved by this suggestion. If this has no negative side effects I will do so. Hehe, so many Eigerstein installations are in use, all with a (slightly) wrongly configured dnscache ;-) 2/ dhclient By the same token there is an interraction problem between dnscache dhclient. When dnscache is running you have to make sure, if you are using dhclient, that your /etc/resolv.conf file is not periodically erased. You have to modify the dhclient script to take care of that. This is explained in the FAQ section of my dnscache.lrp user's guide (http://leaf.sourceforge.net/devel/jnilo/dnscache.html) Thank you for the suggestion. I have to go to a party soon, so I won't look at it before tomorrow evening. 3/ dnscache with or without daemontools ? I have made available a dnscache package which comes with daemontools utilities. The cost is 20K. It allow a very precise debugging also acces to my tinydns package (dns server) and more recently to qmail. It is also fully compliant with DJB approach. I think it would be a good think if we could have one and only one version of the package. I volunteer to be the maintener. Sounds like a good idea to me. You seem to be quite familiar with djbdns, so why should we reinvent the wheel? If you and Charles aggree I could suggest two options: 3.a - You provide my full dnscache package in Eigerstein2BETA - I would favor this option for the reasons mentionned above 3.b - I split my dnscache package in two pieces a daemontool.lrp piece and a dnscache.lrp piece with a dnscache script which would be able to handle both daemontool and non daemontool setup. I could do that if it can lead to a unique LRP dnscache package. I would vote for option b. This way people low on disk space can save some when they have to.Also it just seems sensible to make daemontools and dnscache seperate packages as these are different programs, and other programs need daemontools too. 4/ passwd and shadow files There are a lot of useless users coming from a standard debian distro. We all know it is a pain to add user in LRP... I would get rid of the useless ones and would add those you are used in LRP packages: dnscache, tinydns etc... - I can make up a proposal. It will speed up considerably the install process of those packages. Please make a proposal. If we can make LRP more user-friendly without adding too much bloat we should do so I think Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Follow-up - RE: [LRP] Eigerstein?BETA pre-release
Pim van Riezen wrote: On Mon, 28 May 2001, Peter Nosko wrote: pn] I was thinking it took a long time to create the root.lrp during the backup, but wasn't paying enough attention to say so for sure. I checked the boot partition, and the root.lrp file is 4,176,896 bytes. I tried to pkzip it so I could get it to my red hat box, but it only compressed by 3%. pn] Is this file worth anything to anybody? Are you sure it wasn't just disk-rot? Happens to me all the time, even if I use floppy disks for something else, and especially if I use older ones. The symptons you describe look the same. Like someone sneezed on your FAT. I did screw up a few things, so probably it isn't disk-rot this time. Ewald ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] About the libc threads
Arne Bernin wrote: What is missing right now is thread support. That's for sure ;-) I don't have anthing to add to Pim's post. but seems to go right into that direction, and if it supports enough functions/binaries i would vote for that. It is small and is good supported, although it may not be possible to compile every program, Anything using ipv6 comes to my mind, am I right? Well i'm not sure. But if this is the case i'm sure they are working on it... I was considering asking about that on the uClibc list. I think you're right we can expect ipv6. I'm pretty sure lineo has some clients that (will, in the future) want it. but as more people seem to use this for their embedded systems more programs that are really needed for routing/scripting/firewalling should work than. So maybe in half a year it gets really usable. So what do you think (or did you already discuss this and i missed it ???) I''d love to work on this. Actually I already planned to make a proof-of-concept version of some LRP distro based on uClibc. Well maybe we can talk about that ;-) OK, if you want to, contact me by private email. The Maintainer of busybox/tinylogin/uClibc seems to be willing to help get things running if you run into trouble. But as i said it might take some time, as they haven't even released one version yet (Only CVS).. I know. I have been keeping an eye on the shared library/libdl stuff lately (which afaik works now). Oh, and I did say proof-of-concept, didn't I? Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] About the linc threads
Arne Bernin wrote: Hi there, i didn't wrote when you where discussing it (Quite busy with other things), but my dream is to have a lrp/leaf system based on uClibc. I''ve been thinking of the same lately. It is not usable for this right now Then can you tell me what needed functionality is missing? but seems to go right into that direction, and if it supports enough functions/binaries i would vote for that. It is small and is good supported, although it may not be possible to compile every program, Anything using ipv6 comes to my mind, am I right? but as more people seem to use this for their embedded systems more programs that are really needed for routing/scripting/firewalling should work than. So maybe in half a year it gets really usable. So what do you think (or did you already discuss this and i missed it ???) I''d love to work on this. Actually I already planned to make a proof-of-concept version of some LRP distro based on uClibc. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Working with libraries....
David Douthitt wrote: I've been working on the glibc 2.1 version, and did the following to the libraries: * Removed libuuid; it didn't seem to be needed and it needed libcom_err anyway. * Removed libnss_db; it didn't seem to be needed and it needed libdb anyway. * Stripped libm - saved 68k compressed! Great! * Stripped libform - saved less than 1k compressed (oh well)... * Removed libnsl - nothing seemed to need it. Some addon packages do, though I don't know why: cpio, tcpd, and something else... perhaps I need to recompile these without NIS support? I thought libnsl was the Name Switch/Service Library. So I think anything that uses the system libraries to lookup users, hostnames, ips, protocols etc will need it. I also created some utilites that used nm and ldd to find out information: * missinglib: search the binary path and library path, looking for libraries that are needed but missing * whichlib: find out which binaries use a particular library * objlib: list library symbols without a lot of extra stuff * listlib: list all libraries used by system binaries and libraries. Since the *.lrp is so small, I might as well include it... I also added libNoVersion to the system, since it seemed to be required. I also tried to strip it, with DISASTROUS results. Anybody Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Going to San Francisco
Mike Noyes wrote: Everyone, I'm leaving tomorrow morning to help Charles with his bots. I'll be back early next week. Have fun. Have fun yourself with the bots! The same for Charles. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Eigerstein?BETA pre-release
S.C.Best wrote: Ewald: Hello! Great work, cool. This might be an old question, but I thought I'd ask: should we call your update, perhaps, Eigerstein3? I'll leave that up to Charles I think Ewald ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Eigerstein?BETA pre-release
Charles Steinkuehler wrote: 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. I'll consult a friend of mine who's a fanatic alpine climber on that! Personally I prefer rock climbing, so I'll have to think very hard to find an appropriate mountain :-) Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Going walk-about
Charles Steinkuehler wrote: 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. :-/ Does it have something to do with age? **evil grin** Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Eigerstein?BETA pre-release
Kenneth Hadley wrote: The kernel on this image dies on my Athlon 750 box with a kernel panic when it mounts root, original Eigerstein2BETA runs fine. Weird, what does the kernel say when panicking? This kernel is still the default Eigerstein2BETA kernel, although it's compressed with upx. Could you try with a fresh kernel from Charles' site and let me know if that works? Currently as I type this email ive got the updated image running on my pppoe DSL line (AMD586-133,64MB Ram) Now I just need to sit down and shrink the pppoe package ;-) I hope you will save as much disk-space as I did. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Talk of names....
David Douthitt wrote: The Oxygen glibc 2.1 distribution contains two dramatic changes from the original: glibc 2.1 and configuration files. The changes in the system are dramatic enough that I've been considering making this a new edition so to speak - still Oxygen, but a new Edition name to go with it. Ozone perhaps? I've been considering calling it Oxygen the Nitrous Oxide Edition, but I'm not sure. Lends itself to being called the Nitro Edition :-) What's the symbol for Nitrous Oxide anyway? From my two years of chemistry study I think I remember this: Nitrogen monoxide (the dangerous stuff from incomplete combustion) NO Nitrogen oxide NO2 N2O (Laughing gas, the stuff the dentist uses) Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Humor: [Fwd: [NL-PM] Final Version of Opera 5 for Linux]
On Fri, May 18, 2001 at 02:43:51PM +0200, Stefan Arentz wrote: On Wed, May 16, 2001 at 11:29:20AM +0200, H.Merijn Brand wrote: 15 May Opera Unleashes Final Version of Opera 5 for Linux -- Read the press release http://www.opera.com/pressreleases/20010515.html Wat is Linux? It's a communist OS, only used by unwashed `hackers' who don't want to pay for the quality Microsoft produces. All they can do is mimic commercial software, which they then put on the market. It's hard to install, there's no support and because it's free, it is ruining the market. Leaders of those `hackers' include Richard Stallman, a big bunch of hair who hasn't seen a working shower for over a decade. Big producer of political (communist) documents. Another `hacker' is Eric Raymond, who strongly believes everyone should be armed with fire arms. Writes many documents to glorify himself. Need I say more? Linux: just say no. Abigail
Re: [Leaf-devel] Going walk-about
Charles Steinkuehler wrote: Also, Eric's got a substantial update to EigerStein nearly complete. Do you mean Eric or Ewald? 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. If you meant Ewald, it's here: http://leaf.sourceforge.net/devel/ewaldw/Eigerstein2BETA/20010520/ Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Eigerstein?BETA pre-release
Hello all, With help and approval from Charles Steinkuehler I have made an updated version of Eigerstein2BETA. The goal was not to deviate too much from the original Eigerstein2BETA. All binaries have been upgraded to the last stable version. Other major changes are: - replaced ae with e3 as the default editor. - moved ae, ncurses and setserial to seperate packages - introduced a modified lrcfg.back.script that uses busybox tar A disk image (1743KB) and packages are available for testing here: http://leaf.sourceforge.net/devel/ewaldw/Eigerstein2BETA/20010520/ On the todo list for the final release are: - update sh-httpd in the weblet package - produce some updated kernels If some people could test this pre-release and provide me with merciless feedback I would be grateful. The changelog is attached. Greetings, Ewald Wasscher Changelog for Eigerstein2BETA_test_20010520 These binaries were updated, added or removed: - updated ash to version 0.3.7 - updated busybox to version 0.51 - updated tinylogin to version 0.80 - updated glibc libraries in /lib to the latest debian slink version, recompiled with linux 2.2.15 kernel headers. - updated syslogd klogd to the latest debian slink version - updated cron to debian 3.0pl1-66, recompiled without PAM - updated icmpinfo to version 1.11 - updated traceroute to version 1.4a12 - updated iproute to the latest debian version - updated netstat to net-tools version 1.60 - updated setserial to version 2.17 - upgraded hwclock,fdformat to util-linux-2.11b - updated init,start-stop-daemon,halt,killall5,runlevel, shutdown to sysvinit version 2.78 - upgraded POSIXness to the multi-file version from LRP 2.9.8 - upgraded lrcfg to the version from LRP 2.9.8 - upgraded ipchains to version 1.3.10 - upgraded ncurses to a full version 4.2 - upgraded dnscache to version 1.05 - upgraded dhcpd dhclient to version 2.0pl5 - the following binaries were removed: ctar, dnsdomainname (use hostname -d instead),/lib/libnss_db* (these were unused) - replaced the following commands with their busybox counterpart: hostname,ping,ps,stty,killall,logger,rdate,watchdog,insmod,rmmod - replaced /sbin/getty with tinylogin getty - the following binaries were moved to a seperate package: ae,ncurses,setserial - added e3.lrp as the default editor - introduced a modified version of Eric Wolzak's lrcfg.back.script that works with busybox tar instead of ctar The following changes were made to scripts: - some minor tweaks of linuxrc to make it work with the new busybox replace untar with busybox tar -x replace gunzip with zcat - modified /etc/init.d/network line 86: added \ as the new ash expects on the same line as the preceding command. - added the noauto option to the entry for / in /etc/fstab to get rid of the error when /etc/init.d/mountall.sh tries to mount / which is already mounted rw - renamed ln to busybox, and modified linuxrc accordingly - slightly modified /etc/init.d/network to change the format /etc/hostname is written in. busybox hostname does NOT ignore comments placed before the hostname, so we put the comment at the end. - adjusted root.list so that the initrd will be uncompressed properly after being backed up with the new lrcfg.back.script. the trick is to have no leading ./ in front of the filenames. - added an option to the lrcfg menu for backing up the boot floppy with backupdisk
Re: [Leaf-devel] Proposed CVS Structure
David Douthitt wrote: George Metz wrote: On Thu, 17 May 2001, Mike Noyes wrote: We have over 100 packages that I'm aware of. I'm sure that number will increase once we start importing packages into cvs. I think the packages tree might get cluttered without categories. Agreed. Go take a stroll through the packages directory for Oxygen and be a bit surprised, then realize that there's tons of others out there floating around. Not to mention variations on packages, etc. I just did. I found: *.gz 265 *.bz2 2 *.tgz 18 For a total of 285 - almost 300 archives. In the packages directory: *.lrp 187 So and I keep finding more :-) Okay, you all convinced me. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Linux 2.4 versus glibc 2.1/2.2
David Douthitt wrote: Pim van Riezen wrote: On Wed, 16 May 2001, David Douthitt wrote: I must say I've been surprised at all the excitement over Linux 2.4. I've noticed that all of you kernel wizards are scrambling to get Linux 2.4 installed on LRP, while glibc 2.1 gets ignored. For me, it's basically the fact that I'm silently still pissed off with the mess I, as a developer, get when dealing with different glibc versions. No matter what glibc I use on my development system, at the end if I want to produce binaries I'll have to use three different environments if I want to cater for all glibc variations. Now that RH7/glibc2.2 is gaining acceptance that'll be four: libc5 Is anyone still using this? glibc2.0 glibc2.1 glibc2.2 I may be wrong, but I think that anything using ipv6 won't compile with glibc 2.0. I'm not an expert on this matter but I thought that with symbol versioning applications compiled with glibc 2.0 should run on glibc 2.0 systems. Sounds like a good reason to shift from using glibc 2.0 to using glibc 2.1 or 2.2. I'd vote for 2.2. It may be bigger, but 2.1 will be unmaintained rather soon I'm afraid. So when we choose for glibc 2.1 we might end up with the same mess as we have for glibc 2.0 now in a year or so. Unless one of us is capable of backporting security fixes 2.2 is the way to go I think. I, too, have seen teh MESS that comes from trying to compile things for glibc 2.0. In particular, there are several applications which don't seem like they'll compile under glibc 2.0: * ax25-tools * zebra * brctl Of course, they all compile WITHOUT ERRORS OR WARNINGS under glibc 2.1. If you add to that the fact that a typical embedded application shouldn't be using much more than the stdio, string and socket functions and you see that I'm reluctant to change over to a newer glibc, which will probably take more space without offering much in exchange. That makes me wonder if anyone has seriously considered uClibc. It probably has some limitations. One is of course that binaries compiled with glibc won't run on a uClibc system. I've been playing with uClibc lately and there seems to be considerable progress in it's development. With the last snapshot I tried also the libdl seemed to work, which makes it usable for an LRP like distro. Also in this article: http://embedded.linuxjournal.com/magazine/issue00/4335/ Bruce Perens mentions a way of stripping down libraries. May be interesting for us. How about not having to compile for the old glibc versions? Sounds like a good reason to me. You gave lots of good reasons for why LRP (and variants) should move to glibc 2.1 or 2.2, instead of arguing against it. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Linux 2.4 versus glibc 2.1/2.2
David Douthitt wrote: I'd vote for 2.2. It may be bigger, but 2.1 will be unmaintained rather soon I'm afraid. So when we choose for glibc 2.1 we might end up with the same mess as we have for glibc 2.0 now in a year or so. Unless one of us is capable of backporting security fixes 2.2 is the way to go I think. I tend to agree, though I've already got 2.1.3 going. Upgrading libraries is a hassle - biggest of which is compiling the libraries from scratch - but I imagine I'll be doing it soon enough. Well, that should be doable I think. But compiling it takes ages. That makes me wonder if anyone has seriously considered uClibc. It probably has some limitations. One is of course that binaries compiled with glibc won't run on a uClibc system. That's one of the main reasons I went to glibc 2.1.3. No need to have to scrounge for old binaries; just load a current (now semi-current) distribution and use that. If you want to copy binaries this is obviously an advantage. If you want to compile your own stuff: with the recent gcc and binutils wrappers that come with uClibc compiling is a breeze. And installing a uClibc compile environtment is as easy, though some installation instructions wouldn't hurt. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Proposed CVS Structure
Mike Noyes wrote: Everyone, I'm going to create the following directories in CVS on Thursday, unless there are objections. /release + + /eigerstein + /ladybug + /oxygen + /quercus /script + + /weblet + (etc.) /package + + /base + /libs + /net + (etc.) The package tree will mimic the Debian source tree. Diff files should not be gziped. Other than that minor change, do what Debian does. http://ftp.us.debian.org/debian/dists/stable/main/source/ It's a little late perhaps, but I wonder about the usefulness of using cvs for storing tarballs and diff files. That would mean e.g that if you want a diff between 2 different versions of a package you'd request a diff of 2 diff files. This seems just odd to me. I also wonder if such a diff would be useful/understandable. I thought the strong side of CVS was keeping track of revisions of _text_ files. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Updating Eigerstein:progress
David Douthitt wrote: Ewald Wasscher wrote: It appears that busybox more segfaults when compiled with the slink egcc, which is egcs-2.91.60, _and_ only when the lines it is fed don't fit on the screen. Recompiling with gcc-2.7.2.3 solved this. Perhaps I should try again with gcc-2.95.3, and see what happens. Interesting! I've been compiling busybox these days under Red Hat 6.2 using egcs-2.90.29 (egcs release 1.0.3). Perhaps I should upgrade? That's up to you of course, but if your current compiler works properly (I thought your segfualt issues were solved), I'd say keep it. One more reason to do so is that newer versions of gcc seem to produce larger binaries. Compiling with -Os often helps against that, but not always. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] seg faults in Eigersteinbeta solved- hopefully
KP Kirchdörfer wrote: Some good news, I believe, for eigerstein developers. With extensive help from David I copied libraries (still glib 2.0.7) from the latest oxygen into my eigerstein environment - and the seg faults I've experienced since busybox 0.50 have gone away. What is the difference between the original glibc and David's if I may ask? What puzzles me is that the new root.lrp is about 40k smaller than the old one. Could it be that the new libs are more thoroughly stripped? The default Eigerstein2Beta glibc libraries (which I suspect to be debian's) get smaller when stripped with: strip --strip-unneeded -R.note -R.comment The disk booted without complaints - is currently up and running for about two days. Very well. Due to my workload in the last and coming days I've found no time to do some research how to use sourceforge for web mirroring, ftp et al. More worse, I'll have to start renovation at home and will be more offline than I like. If someone is interested, I'll send either my root.lrp as attachment or David's, revisited, how to build your own updated root.lrp. I almost have some heavily updated Eigerstein2beta packages ready. That is with glibc-2.0.7 recompiled with linux-2.2.15 headers. I'm very curious why and how David's glibc solves these segfault problems. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] LRP kernel. Which extra modules to add?
Hello all, I'd like to hear some opinions on which extra (not-coming-with-the-kernel) modules/patches should be added to a general LRP kernel. Currently I have these: ip_masq_icq ip_masq_mms (M$ messenger) ip_masq_dplay (for games that use M$ DirectPlay API) ip_masq_h323 vpn masquerading modules (pptp/ipsec) openwall patch netgear fa311 and fa312 nic drivers Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Makefile and Directory to create LRP packages fromsource
[EMAIL PROTECTED] wrote: I have visions of a cloud saying *and a miracle occurs* and then we proceed to make the lrp package. Hehe. me too :-) # cd lrp # make # ls -1 pkg.lrp pkg.lrp Until now I do things slightly different: # cd mypackage # chmod u+x lrp/rules # lrp/rules # ls lrp/package lrp/mypackage.lrp If I understand David correctly the main difference between his and my approach is that with my approach configuration of- and compiling the source is done by the lrp/rules makefile, instead of by the diff or by hand. It's that way now, but I've just a few things to tidy up. The last file I used this on was SING, and it worked well. I'm putting documentation into the Makefile, and more. I still have to do so. Automatic creation of a mypackage.version file comes to mind. Once I get this fixed up, I'll start cleaning the CDROM out, throwing out precompiled source in favor of the source files and a LRP diff. Would you mind sharing before you go into production? You didn't ask _me_ but I attached some diffs anyway. Initscripts and package.list files were shamelessly stolen from oxygen. The lrp/rules file in the sed diff doesn't create a package as sed will be in the root.lrp. Ewald Wasscher util-linux-2.11b-1lrp.diff.gz sed-3.02-1lrp.diff.gz
Re: [Leaf-devel] Proposed CVS Structure
Mike Noyes wrote: Everyone, I created the following trees in our CVS repository today. There are README files in each tree describing the proposed content. doc package release http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/ I didn't do anything else, because the discussion on package tree hasn't reached a consensus yet. Reaching such a consensus is imho on of the most important (if not the most) things right now. So whatever agreements we make, we should make them. And preferably the discussion shouldn't be a 3 man discussion as it has been until now. I'll post a few examples of my proposal for making packages this evening. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Proposed CVS Structure
Mike Noyes wrote: Ewald Wasscher, 2001-05-01 20:24 +0200 Mike Noyes wrote: David proposed something like this already. Take a look at this patch. Source code + diffs for CVS https://sourceforge.net/tracker/?func=detailaid=412704group_id=13751 \ atid=313751 I like the basic idea a lot. What I don't like is the way the package is configured. IMHO it will not always be obvious to others how a package was configured and built. Debian for example has a debian/rules file (which is in fact a makefile) that describes how to configure, build, install and package a certain application. So what I propose is the following directory structure: package/ + + lrp/ + + rules + install + package + files To build a package one should: cd package lrp/rules configure lrp/rules build lrp/rules install (or perhaps the following:) lrp/rules package Any comments? Ewald, You lost me. I'm not a programmer Neither am I. I just have a big mouth and pretend to know what I'm doing :-) so help me understand why this is necessary. If I understand correctly how David does this it's not necessarily obvious to someone other than David how a program is configured, and how it is built, what files to use in the .lrp package, and what lrp specific configs need to be added etc. So if someone decides to upgrade a package to a new version, or juist wants to play with it he/she has to find out again how to configure/build and package the program. There is however another problem. If you want to build ash, you cannot just simply do make, as you need the bsd pmake program instead of gnu make, and what's worse the version of pmake that comes with redhat and friends is too old, it just doesn't work. So it will require some tricks to be able to do a simple make to build ash. So IMHO it would be very nice to have a standardized way of doing such tricks.That way everyone should be able to understand what happens. My main reason for making this proposal is that that way it should be obvious to all of us what someone does to build and package a certain app. First of all I just like that idea. Second you can check if I screw up and I can admire all of the smart tricks someone else uses to build that super-cool ultra-small size optimized glibc (and learn from it). Third is that it has the potential of easier upgrading because the lrp specific logic is kept seperate from the actual source. Aply the diff to a new version of your program and if you're lucky you even won't have to make any other changes to build and package the app. The Debian source tree only contains three files for every package. Example: http://ftp.us.debian.org/debian/dists/stable/main/source/net/ snort_1.5.1-11.diff.gz 14-Feb-2000 03:5147k snort_1.5.1-11.dsc 14-Feb-2000 03:51 1k snort_1.5.1.orig.tar.gz 11-Jan-2000 15:15 134k That's right as far as i know. (though I'm not _very_ familiar with debian , so please correct me whem I'm wrong.) The dsc file isn't very interesting. It just describes what files are needed to build a package and their (md5-) checksums. The .orig.tar.gz is just a pristine source tarball as distributed by the creators of the program. It is just renamed to .orig.tar.gz The diff creates a subdirectory debian in the source directory which contains all of the trickery I wrote about as well as debian-specific config-files etc. Maybe the debian/rules files will shed some light on this problem. I suggest you download e.g. the ash source package from the debian testing distribution. Unpack the tarball, apply the diff and try to understand what happens in this debian/rules file in the patched source dir. Is this what you're referring to? http://people.debian.org/~srivasta/rules/cvs-buildpackage/ The files you find here are an example of the contents of such a debian subdirectory.We probably could keep things a bit simpler. http://packages.debian.org/stable/devel/cvs-buildpackage.html http://www.debian.org/devel/cvs_packages Wow, now I need a break. And some coffee too :-) I hope it's a little clearer now what I want and why. If not I'll have to do better. I'd _really_ like to know what people think about this, not just you. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Updating Eigerstein:progress
[EMAIL PROTECTED] wrote: On 30 Apr 2001, at 2:08, Ewald Wasscher wrote: [EMAIL PROTECTED] wrote: On 22 Apr 2001, at 14:34, Ewald Wasscher wrote: 22-4TODO: update all binaries to the _latest_ versions available? Is this a good idea? That will probably use some additional diskspace Yes, definitely. Fixes bugs and security problems. I've heard lack of updates classified as the number one security problem. Someone just had to give that as an answer. Like me, eh? :-) The only problem is that some newer releases don't compile very easily with older glibc/gcc/binutils. I've found that the problems are actually minor in most cases: usually it is a missing pcap.h - most programs seem to think it's in the main include directory instead of pcap/pcap.h (sigh)... Hmm, I guess that means I'll have to try again to compile all those bl%^$^% utilities. A few programs seem to use updated glibc networking headers, but most things I've used don't have that problem. So do you think it will be sufficient to track e.g. the latest debian security advisories or should all binaries in your opinion really be the _latest_ versions? I'd say they should be the *latest* versions - until you can't do it any longer with the older glibc. I solved the problem by switching to glibc 2.1 - the bridge utils won't compile under glibc 2.0 any longer... Ah well I've been working on my private glibc-2.1 based Eigerstein already. Ironic that Matthew (the fellow who did Materhorn) was the bridgeutils maintainer, and has now left it stagnate until someone else picked it up. AFAIK the 2.4 kernel needs other bridge utils than Matthew's so I suppose noone will ever pick it up. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] A little less mail,a little less Oxygen development....
[EMAIL PROTECTED] wrote: There is a new baby in the house so I'm not going to be doing a lot in the next week or so... Andrew James was born 22 April 2001 at 7:25 am, and was 9 lbs. 4 oz. (ask your wives if that's big :-) Congratulations! And I don't have to ask to know that's _big_ Current outstanding development concerns: * Both Oxygen versions (glibc 2.0.7 and 2.1.3) have problems with insmod: the kernel in both is a kernel with the bridge patches installed and compressed with UPX. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Updating Eigerstein:progress
[EMAIL PROTECTED] wrote: On 22 Apr 2001, at 14:34, Ewald Wasscher wrote: replace gunzip with zcat My understanding is that zcat is: #!/bin/sh gunzip -c $1 Of course, but it's also an alias for the gunzip applet in busybox. 22-4add e3 (the pre 1.5 from oxygen) as the default editor e3 is going to 1.5 very soon. Remember to change options in e3.asm... I just ripped the e3 from oxygen, but I will remember. 22-4TODO: update all binaries to the _latest_ versions available? Is this a good idea? That will probably use some additional diskspace Yes, definitely. Fixes bugs and security problems. I've heard lack of updates classified as the number one security problem. Someone just had to give that as an answer. The only problem is that some newer releases don't compile very easily with older glibc/gcc/binutils. So do you think it will be sufficient to track e.g. the latest debian security advisories or should all binaries in your opinion really be the _latest_ versions? Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Updating Eigerstein:progress
[EMAIL PROTECTED] wrote: On 23 Apr 2001, at 19:47, Ewald Wasscher wrote: KP Kirchdörfer wrote: 21-4updated busybox to version 0.51 I'm running eigerstein with busybox 0.51 (and replaced most of the POSIXness links and other progs with busybox and tinylogin), but as long as we see the seg fault in 'busybox more' it's not ready for prime time - even if it's a beta version. How should I reproduce that error? I have no problems with segfaults so far. This may be refering to a problem in Oxygen. The problems were solved with a recompile of glibc 2.0.7 from source. Unfortunately I do experience segfaults now with busybox more. It seems that when it gets an input line longer than approx. 78 (don't know the exact number) characters it segfaults Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: syslog.conf (was: Re: [Leaf-devel] Vulnerabilities dot org)
Ray Olszewski wrote: At 10:45 PM 4/26/01 -0700, Scott C. Best wrote: ... 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? I forget which version of LRP you use, but probably what you're doing wrong is accepting the default settings in /etc/syslog.conf . They provide for multiple logging of mesages that match more than one of the match criteria in the file. For example (looking at LRP 2.9.8), all kern.* messages go to kern.log, and some of them will also match the settings for syslog and messages. This is all very handy for systems with real mass storage, but the redundencies are probably unsuited to quasi-embedded setups like LRP, where storage is very limited. I wonder if we might do better to use a simple syslog.conf that just logs everything to messages -OR- syslog? In that case syslogd could perhaps be replaced with the busybox syslogd. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] EigerStein updates
Charles Steinkuehler wrote: 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) Aye aye sir! 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. Hmm, I already forgot about ae :-) I'll see what I can do. 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. I find this concept of building RPM's and then selecting the files you need from them ( I assume it is a bit like peeweelinux ) very attractive. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Updating Eigerstein:progress
Eric Wolzak wrote: Too bad. Probably I won't have much luck, but I'll try anyway :-) be carefull with root.lrp. I used tar and everything did backup fine. Only root caused a real trouble. I experimented with this for some time a summary of my post: The problem was that the exclude option overrides the include option. an example So with backup of ppp.lrp in the include list for ppp exists /etc/ppp now the files that are backed up with the other packages are excluded. in the exclude list it says /etc (from to package etc.lrp) at least with BB 0.49 now the /etc/ppp in the include list was ignored because /etc was in the exclude list. So all packets were smaller :)but less functionall ;) I observed the same :-( I used the following command tar -c -v `cat $INCLUDE` -X $EXCLUDE | gzip $DIR/$PACKAGE.lrp The problem can be probably be solved by changing the principal method of how to select what to backup but this would mean incompatibility with the original. As ctar is only very small i left this on my image. 22-4updated icmpinfo,rdate,traceroute to latest debian slink vers= ion why not replace rdate with the busybox version? It worked quite well until I started to use xntpd. I use it.also without problem this is my busybox list: basename, busybox, cat, chgrp, chmod, chown, clear, cp, cut, date,dd, df, dirname, dmesg, du, dutmp, echo, egrep, expr, false,fdflush,find, free, grep, gunzip, gzip, halt, head, hostname, id, init,insmod, kill, killall, klogd, linuxrc, ln, loadkmap, logger, ls,lsmod, makedevs, mkdir, mknod, more, mount, mv, nc, nslookup,poweroff, printf, ps, pwd, rdate, reboot, reset, rm, rmdir, rmmod,sleep, sort, swapoff, swapon, sync, syslogd, tail, tar, touch,tr, true, tty, umount, uname, uniq, update, uptime, wc, which,whoami, xargs, yes, zcat 158356 bytes, seems a lot but by removing insmod, and aa ffew others the root package is even smaller as before. I wonder why some people replace some POSIXness links with their busybox counterparts. On average the POSIXness version is smaller, so why replace it when it works? I bet that they don't care to remove the relevant code from POSIXness so the only result you'll get is a bigger root.lrp (and yes a little more speed probably). Ewald Wasscher ___ 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.
Scott C. Best wrote: George: Sorry for the late reply... Time to do some good old-fashioned market classification here. We have two base-level types of people using LRP: 1. People who want to have a firewall/router that will let them share IP addresses and don't want to spend the money on a commercially available one. 2. People who want to tinker, and as such have a fair bit of knowledge. I more or less agree with your generalization. I think Eigerstein proves your point substantially. Recall LRP without it, back when modmaker was alive? Every newcomer was pushed in the tinker category. From my pov, Eigerstein was the eighty percent solution, and has been a great success both on its own and for the project in general. The problem then becomes where we draw the line between the two. Perhaps a way to think about it is from the point of view of the newcomer. I think we really should. That is, we'd answer the question: why would a new user use this LEAF stuff. So, similar to what Eigerstein did, we could break it out by high level description: * Using a Cable-modem with a DHCP? Download MapleLEAF 1.0 * Using a DSL-modem with PPPoE? Download FigLEAF 1.3 * Using a dial-up modem? Start here with RedLEAF 1.1 * Experts only: want everything? MallornLEAF is for you. That sort of thing. Or if MapleLEAF was tied to a specific kernel/glibc version, we could post pre-rolled images like MapleLEAF for DSL, MapleLEAF for Developers, etc. Excellent idea! If we don't most windows users are IMHO more likely to buy another harddisk and put Win98SE on it and use it's Internet Connection Sharing. So we really should make it as easy as possible for them. 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. UPX probably will save very little space, if any, on the bootdisk if you use it for binaries as the lrp packages are already gzip compressed. At least then, it would be easier to transition from the basics to the fun stuff. Agreed. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Updating Eigerstein:progress
Ewald Wasscher wrote: I compile on a debian slink install with all of the updates. The compiler I used was egcc which is gcc-2.91.60 iirc. Duh, that means glibc-2.0.7 of course Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Web Site DOWN
Mike Noyes wrote: Mike Noyes, 2001-04-23 10:36 -0700 I believe at this time that the SF staff was trying to slipstream an update in. More than one project was affected. I also noticed German text on the rblock of the SF home page shortly after our site started working again. It's gone now. Apparently, the new SF code didn't work very well, and they backed out of the change. :( Everyone, Interesting. The German text is present on the SF home page again. At least I think it's German. No, it's Dutch! (which is very similar to German) SourceForge Statistieken Top projectendownloads Gebruikers met de hoogste rang Meest actief deze week Are they trying to implement i18n support? That's implemented (at least partially) already. When I login to sourceforge I see most text in Dutch. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Updating Eigerstein:progress
KP Kirchdörfer wrote: Am Sonntag, 22. April 2001 15:31 schrieb Ewald Wasscher: 21-4updated busybox to version 0.51 I'm running eigerstein with busybox 0.51 (and replaced most of the POSIXness links and other progs with busybox and tinylogin), but as long as we see the seg fault in 'busybox more' it's not ready for prime time - even if it's a beta version. How should I reproduce that error? I have no problems with segfaults so far. TODO: throw out ctar, we'll probably need to adjust some scripts. everyone agrees? I tried to replace ctar with tar --exclude-list - but it blew up the resulting lrp-packages, I guess --exclude-list didn't work as expected. Too bad. Probably I won't have much luck, but I'll try anyway :-) 22-4updated icmpinfo,rdate,traceroute to latest debian slink version why not replace rdate with the busybox version? It worked quite well until I started to use xntpd. That's on the todo list (see my post) 22-4add e3 (the pre 1.5 from oxygen) as the default editor Is this a version of e3, which don't make a backup of the original file? This feature of e3 is just wasting space, especially within lrcfg. I just checked and it doesn't seem to make a backup of an edited file. 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. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Updating Eigerstein:progress
Charles Steinkuehler wrote: Wow! Progress!!! Below you'll find a list of all the changes I have made so far in the process of producing an updated version of Eigerstein2BETA. Feedback is of course appreciated. I also wonder if it's possible to compile tinylogin with md5 passwords (good idea anyway) and without linking with libcrypt. That would make it possible to go without libcrypt. A diff is attached, but as I'm not a c programmer it would be nice if someone could verify it it should work. Hmm...If we loose libcrypt, will other stuff that authenticates (like ssh) still work? Probably not unless you set UseLogin yes in sshd_config Updated etc.lrp and root.lrp packages can be found here: http://leaf.sourceforge.net/devel/ewaldw/Eigerstein2BETA/20010422/ These are alpha quality. My test system boots with these with a few complaints from mount. I'll try to play with these some Monday... TODO: throw out ctar, we'll probably need to adjust some scripts. everyone agrees? I'm not sure I'd axe ctar...I'm not sure busybox tar creates the directory points required to properly backup LRP files (this was a discussion topic a while ago...I just don't remember the results). I'll have a look in the archives. Yes, several scripts will have to be modified if ctar goes away... That also needs to be done now as there are no star and untar applets in the new busybox Ewald Wasscher ___ 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.
Charles Steinkuehler wrote: 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... That would at least be a LOT easier for development than the current situation. (although I'd be happy with a 1.68 meg image). The same goes for me Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: Off-list Re: [Leaf-devel] Updating Eigerstein
Eric Wolzak wrote: Hello Ewald, Charles 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. yep, sort of. Argh, I have hardly touched a computer the last few days. I would have replied sooner if I had. I am implementing the eigerstein on the 2.4.3 kernel from george. It just seems to change quite a lot. I am using Busybox 0.50 for now. as I had problems compiling the 0.51 with insmod. (see previous posts) Updated the ash. ( oxygen) Am working on the weblet. But changing to 2.4 and updating to iptables means also changes in portforwarding and masquerading. I now have working ( not properly tested image with shorewall) Personally I think shorewall is great, but I would like to hear other's opinions. I am working on a basic ip-addres setup kind of the way lrp does it. The rest of the system will be setup with a webinterface (sort of prealpha stage ;) at the moment. Allthough this kind of changes would mean a rather radical change away from eigerstein. :( So perhaps it would be the best to stay with ipchains. and only update a few programms (busybox etc). I think that should be the first goal. It would of course be very interesting to create a truly linux 2.4 based distribution, but it will hardly be eigerstein I think (though rather cool) As said , i am still in a very pre-alpha stage, and don't know if I come further. Well I'm in the same stage, but intend to finish it rather soon. I think I'll post a log of the changes I have made so far on tuesday. 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 The busybox vi applet functions very well :) tried this. Good. But e3 is even smaller and quite functional. Greetings to all of you. Ook ewald de groeten :) Greetings to all, and to Eric: Gruesse aus Holland (hmm, where did you read that before :-) Ewald P.S. Eric; I live only 5 KM from the Dutch-German border. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: Off-list Re: [Leaf-devel] Updating Eigerstein
Eric Wolzak wrote: okay time for CVS :) Hmm, and hwo are we going te set this up? Currently there are lots of binaries in my eigerstein2beta tree for which I don't have (yet) the source code. Should there be seperate source and binaries trees? It would be really nice to do a "cvs co" and then a "make world". Greetings to all of you. Ook ewald de groeten :) Greetings to all, and to Eric: Gruesse aus Holland (hmm, where did you read that before :-) in my schoolbooks ;) ,I am dutch but live in Germany since 1984. I see. I thought you would have read it on a postcard from the Dutch coast! Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Updating Eigerstein
David Douthitt wrote: Ewald Wasscher wrote: David Douthitt wrote: 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 version of ash are you using if I may ask? I have been wondering about that before. I'm not sure; I think it must be 0.35 with patches from Erik Andresen. I tried to compile 0.37 (back then, and now) and it didn't work. With a few tricks due to different versions of dpkg on slink and woody I managed to compile the ash-medium-0.3.7 from debian-woody on slink with updated gcc, binutils and byacc. I commented out the lines for ash-small in debian/rules. dpkg-buildpackage fails, but when it does you have a working sh already. So far at least shorewall seems to work with this shell. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Updating Eigerstein
David Douthitt wrote: 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 version of ash are you using if I may ask? I have been wondering about that before. Ewald Wasscher. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] New shorewall .lrp
Tom Eastep wrote: I've corrected the problem that Ewald reported with Shorewall and busybox grep and have built a new .lrp. You can find it at: http://seattlefirewall.dyndns.org/pub/shorewall/shorwall-1.1.1b.lrp ftp://seattlefirewall.dyndns.org/pub/shorewall/shorwall-1.1.1b.lrp And it works! Hooray! Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] New shorewall .lrp
Tom Eastep wrote And it works! Hooray! However I forgot to mention that: /etc/shorewall/rules is missing in /var/lib/lrpkg/shorwall.conf I suppose it should be there. When trying to edit the policy file through lrcfg it passes "/etc/shorewall/policy " to ae. ae chokes on the extra space at the end, and can't find the policy file. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Shorewall on Eigerstein2Beta not working
Tom Eastep wrote: Thus spoke Tom Eastep: Hmmm -- This is probably because of how "grep" is defined on LRP. Please try it with the attached /etc/shorewall/functions file. Pardon me for following up my own post but the previously-posted functions file was brain-damaged. Here's one that works better... After using dos2unix on it it seems to work. Except for this strange output: Starting Shorewall... Loading Modules... Initializing... Determining Zones... Zones: net local dmz gw Determining Hosts in Zones... Deleting user chains... Configuring Proxy ARP and NAT Adding Common Rules Setting up ICMP Echo handling... Processing /etc/shorewall/tunnels... Processing /etc/shorewall/rules... Adding rules for DHCP Processing /etc/shorewall/policy... [: ==: unknown operand Policy DROP for net to net. [: ==: unknown operand Policy ACCEPT for local to net. [: ==: unknown operand Policy REJECT for local to local. [: ==: unknown operand Policy REJECT for dmz to dmz. [: ==: unknown operand Policy REJECT for gw to gw. Masqueraded Subnets and Hosts: Activating Rules... Shorewall Started Regarding the versions of /etc/shorewall/* files, if the file's format hasn't changed since version 1.0 then the version in the file's header likewise hasn't changed. I see. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: Shorewall works! Was:Re: [Leaf-devel] Shorewall on Eigerstein2Betanot working
Ewald Wasscher wrote: If you think that it's working now, I'll post a new .lrp in my download area that contains the fixes. Too bad it doesn't. I have sent the garbage output by private email. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Packaging
David Douthitt wrote: Ewald Wasscher wrote: David Douthitt wrote: BB has as one requirement that it only use glibc as I remember. debian:~/lrp-2.9.8/build/busybox-0.50# grep --context=3 uClib * README- README-Supported libcs: README- README: glibc-2.0.x, glibc-2.1.x, Linux-libc5, uClibc. People are looking at README- newlib and diet-libc, but consider them unsupported, untested, or worse. README- README-Supported kernels: Clear enhough, isn't it? Yes - it requires only glibc - but I wasn't clear. Ah, I was mistaken. I thought you meant it needed glibc specifically. I don't see libncurses in there - nor libwrap - nor libpcap - not even libm. My ldd confirms this :-) Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Shorewall on Eigerstein2Beta not working
Hello Tom and others, I've been testing the new shorewall-1.1.1.lrp package on Eigerstein2beta today and have run into a few problems: First there seems to be an extra space in the line for /etc/shorewall/policy in /var/lib/lrpkg/shorewal.conf. When I tried to edit /etc/shorewall/policy through the lrcfg menus ae would try to load "/etc/shorewall/policy ". Note there is an extra space after "policy". This is easily fixed. Second problem is that the /etc/shorewall/firewall script seems to enter an infinite loop. After displaying "Determining Zones" it doesn't show anymore progress. A trace (or how should I call it?) is attached. Ewald Wasscher sw-trace.gz
Re: [Leaf-devel] Kernel 2.4.x
George Metz wrote: Okay, I lied. Rants take time, and on an Athlon 1.1, compiles don't. http://leaf.sourceforge.net/devel/wolfstar/LRP-2.4.3-kernel.tar.bz2 When I put this kernel on a working Eigerstein2Beta floppy, linuxrc cannot mount the floppy so it won't load any lrp packages. With DEBUGGING and VERBOSE turned on in linuxrc it says for example: Mounted /dev/fd0u1680 as shm But when I put my own 2.4.3 or 2.2.19 kernels on the disk that is: Mounted /dev/fd0u1680 as msdos And packages are loaded just fine. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Kernel 2.4.x
George Metz wrote: On Sun, 8 Apr 2001, Ewald Wasscher wrote: When I put this kernel on a working Eigerstein2Beta floppy, linuxrc cannot mount the floppy so it won't load any lrp packages. With DEBUGGING and VERBOSE turned on in linuxrc it says for example: Mounted /dev/fd0u1680 as shm But when I put my own 2.4.3 or 2.2.19 kernels on the disk that is: Mounted /dev/fd0u1680 as msdos And packages are loaded just fine. Oh wow. That'll teach me to compile when I'm tired. Okay gang, skip the kernel, I need to do a recompile. Forgot to include support for MS-DOS filesystems. LOL. Perhaps you could compile iptables support as a kernel module. That way someone who wants an easy upgrade path can (temporarily) use the ipchains module. Perhaps you could also add a few patches from iptables' patch-o-matic too. There might be some people (like me) who absolutely need the ftp-multi-patch (damm ABNAMRO home banking),. or just want irc functionality. I have been running Tom Eastep's shorewall on a 2.4.3 kernel for a few days this week, and haven't experienced any problems with the pending-patches+ftp-multi+ftp-pasv+eggdrop patches applied Don't include those patches just for me as I will compile my own kernel anyway. Ewald Wasscher P.S. If I'm right the lrp package of shorewall is broken as "shorewall" is 9 characters long and doesn't fit the 8.3 msdos filenames on lrp boot floppies. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Introducing myself
George Metz wrote: Welcome. The lack of formal education on my part might surprise you; all my stuff is on the job training and hobby knowledge. =) Only hobby knowledge here. Some things I intend to contribute are: - an iptables.lrp for George's 2.4.3 kernel (very soon) Actually, the iptables binaries are already in the root.lrp that I'm using - you can find a link to it on my page. Right, but IIRC these are version 1.2 and do not work with iptables 1.2.1a which is current. - some kind of traffic accounting package, possibly based on rrdtool - a lot of nonsense on the mailinglists Traffic accounting good. Nonsense on mailing lists very good. Welcome! Thanks! Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Kernel 2.4.x
Ewald Wasscher wrote: Perhaps you could also add a few patches from iptables' patch-o-matic too. http://netfilter.kernelnotes.org/ has been unreachable for me and some others for some time now. The iptables userspace code can be found here: ftp://ftp.gnumonks.org/pub/netfilter/ Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Kernel 2.4.x
KP Kirchdrfer wrote: Am Sonntag, 8. April 2001 16:46 schrieb Ewald Wasscher: P.S. If I'm right the lrp package of shorewall is broken as "shorewall" is 9 characters long and doesn't fit the 8.3 msdos filenames on lrp boot floppies. Just a workaround until Tom find a new name: rename shorewall.lrp to shorewal.lrp after booting the disk move /var/lib/lrpkg/shorewall.* to /var/lib/lrpkg/shorewal.* edit shorewal.list to include shorewal.* instead of shorewall.* save shorewall and you are ready to test. Hmm, who posted about this on the shorewall-users list :-P Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] iptables.lrp released
Hello all, For those who want to experiment with LRP and 2.4 kernels I have made an iptables.lrp package. It is linked with glibc-2.0.7 and does not have ipv6 support. Please note that this is iptables 1.2.1a and because of that it needs a kernel patched for iptables 1.2.1a. Information on how to do so can be found in the documentation that comes with the iptables source found on: http://netfilter.kernelnotes.org/ The iptables.lrp can be found here: http://leaf.sourceforge.net/devel/ewaldw/ A matching kernel should be there soon too. Regards, Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Compiling iptables with glibc-2.0.7 (George Metz?)
Arne Bernin wrote Well i compiled this iptables with a libc-2.0.7. I have the source laying around somewhere, but i remember i had some problems with the ipv6 support, and had to comment some stuff in the Makefiles... My knowledge of c and makefiles is for certain a lot worse than David Douhtitt's. So I didn't even think about that. But it seems it does not really matter any more ;-) But the real fun should be compiling it against uClibc... No thanks. Perhaps when I get too bored one day. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Packaging
David Douthitt wrote: bzip2 is supposed to be pretty good; why not use root.tgz and all the rest are *.bgz or whatever the standard is but then, there probably isn't any. The zip code for root.tgz is contained within the kernel, so you could actually remove gzip and use bzip2. The only problem is you couldn't modify root.tgz ... And another problem is that any conventional root.lrp contains glibc and busybox and ash, which is probably the largest part of most lrp systems. I wonder if it will pay off in terms of diskspace to have a larger root.lrp (with bzip2 added) when you can only compress non-root packages with bzip2 Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Packaging
George Metz wrote: speech and boot.lrp requirements cut out This is based on the boot sequence in initrd archive, to the point of loading packages, as follows: 1. Creates links to busybox for ln, cat, and mkdir. 2. Creates the base directory structure with the above. 3. Creates busybox and POSIXness links. 4. Makes the dev files 5. chmod's /var/lock and /tmp, mounts proc, updates mtab 6. Checks for boot= and makes the mount dir, then mounts the boot device specified. 7. Begins to install packages. Please, someone who's monkeyed with the default 2.9.8 Linuxrc script, doublecheck me on that. I wouldn't swear on it, but I think this is accurate. Thought here is to get a bootstrap initrd archive up and running first, then use what it contains to load System packages, then addon packages, from a significantly larger medium than a floppy disk. In this case, if we're using bzip2, we can still load off the floppy disk, and just add in bzip2 and libbz2 to the boot.lrp package, and away we go. This could be a nice way of loading the bulk of leaf from a cdrom. I suppose the boot.lrp will have to remain on the floppy in order to remain compatible with 486's and older pentiums that don't support booting from cdrom. In that case it might be useful to link the binaries in boot.lrp to some kind of embedded libc (uClibc, newlib et al) in order to keep the boot.lrp as small as possible.Tweaking linuxrc so that it will work with busybox's sed applet instead of GNU sed could save a few bytes too. I THINK I can get a default boot.lrp together in the next few days, but I'm weak on scripting, and this may take a bit of scripting skill. If anyone can make a couple of modifications for me to Linuxrc, please offer. Overall, I'd prefer not, since this might be the kick I need to figure out shell scripts and the like, but if you like the idea and want it done in less than a week or two, then modify linuxrc to load a set list of System packages that are constant-named. I was thinking lib, modules, root, etc, and local could be static packages, whereas everything that ISN'T a system-required package such as dnscache, sshd, weblet, etc. could remain configured via the "LRP=" parameter - or whatever happens to be used by a given distro. Sshd might not be _absolutely_ necessary to run leaf, but I wouldn't want to have router without it Thoughts? Questions? Insults? =) You ^%**((* American (*(* :-) Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Compiling iptables with glibc-2.0.7 (George Metz?)
George Metz wrote: On Thu, 5 Apr 2001, Ewald Wasscher wrote: Could be a Red Hat problem, could not be. I didn't compile IPTables for 2.0.7 myself, someone else did; they're the ones to ask. I got the modified root.lrp from ftp.linux-router.com, and since I'm having "issues" getting stuff to work for my Slink install, Well these "issues" led me to the point that I decided to make a "woody-based" version of lrp-2.9.8. I already had that finished when I posted my question and read about the upcoming oxygen release. I haven't tried compiling it myself for 2.0.x glibc. I have tried,and again and again, and tried recompiling the damm glibc 2.0 etc. etc. :-((( That actually took a lot more time than producing my upgraded lrp-2.9.8. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
