[Leaf-devel] Re: [Leaf-user] Dachstein-CD available
> I'm headed out of town for a long weekend (back Wedensday), so I may not be > able to answer questions immediately. Well, forget the part about me going out of town...my wife called just after I sent the e-mail and told me to cancel our trip to Washington (DC). No, we're not worried about terrorist attacks (although maybe we should be), but she's come down with something and doesn't want to travel while under the weather. On the plus side, I'll probably have IPSec working Real Soon Now (it's next on the list...right after I put a CD-Rom in *MY* firewall so I can use the new Dachstein-CD :) Unless something drastic happens, you'll need to run bash to get IPSec working properly. I've done limited testing with bash so if you're planning on using IPSec, grab dachstein-CD (or a HDD/Zip/other large storage media) and get a system up & running with bash (requires lncurses and lrdline2 in addition to bash.lrp). Any testing/debugging someone besides me can find time to do will make things go that much faster. I'd really like to figure out why ash isn't working properly, but the new IPSec startup scripts give even me a headache... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Dachstein-CD available
I have released a preliminary version of Dachstein-CD. Based on Dachstein, LRP-CD, and extensive modifications to the backup scripts, it's getting easier than ever to boot from a CD. The files, and some documentation are available from my website: http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/ But if you're grabbing the CD image, you'll probably have better luck with the faster mirrors: http://lrp1.steinkuehler.net/files/diskimages/dachstein-CD/ http://lrp2.steinkuehler.net/files/diskimages/dachstein-CD/ The mods are described in the README file, and the new backup system should be pretty easy to understand. The big change is you can now select the desired backup type and destination on a per-package basis, making it easy to control the generation of full or partial (config information only) backups, and to save them to floppy, hard-disk, or where-ever. I'm headed out of town for a long weekend (back Wedensday), so I may not be able to answer questions immediately. Don't let that worry you though...the new system is much easer to use than the previous LRP-CD release, and I think anyone reasonably familiar with LRP won't get too lost. The main thing to watch is getting your package path setting correct (remember, the kernel parameter is overridden by the pkgpath.cfg file on your floppy...see the README). I don't have time to update my website to reflect the changes, so keep the links above handy for now, and get a jump on the rest of the world for being a LEAF list member! Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: [Leaf-user] Dachstein release-candidate available
> > I have posted the first release candidate (rc1) of Dachstein on my
website:
> > http://lrp.steinkuehler.net/DiskImages/Dachstein.htm
> >
> > Just today, I made a large number of changes in the weblet pages,
finally
>
> I wish to raise a simple question. But first let me tell you that I did
> not even look at the new weblet.
>
> I use the weblet access to fetch files from the fw, not for visual
> display but for automatic manipulation.
>
> I always wanted a mode where the data comes down the wire with the
> absolute minimal added html.
>
> Can we add such a mode? Maybe a request flag that defines the level of
> visualization one wants? This flag can be stripped up front, then the
> request
> processed normally, and these scripts that want to use it can refer to
> it through, say, some environment variable that was set upfront.
Well, there are a couple of things you might be asking for, and both are
pretty easy.
If you would like access to files on the server, you can simply configure
weblet to serve up any file in the filesystem, and download anything you're
interested with a web browser or something like http-get.
If you want some of the status information made available via the cgi
scripts, you can pretty easily modify the scripts to return NO HTML
formatting. Simply change the mime-type returned by the cgi-script to
text/plain instead of text/html, and remove the HTML formatting from the cgi
script. You can either replace the existing cgi scripts with your new
versions, or give them a different name so you can access either version.
As an example, here is the original viewmasq cgi script:
#!/bin/sh
cat <<- /HTML-DATA
Content-type: text/html
${0##*/}
LRP Firewall
Masqueraded and Other Connections
$(date)
Masqueraded Connections:
$(/bin/netstat -Mn)
Other Connections:
$(/bin/netstat -n)
/HTML-DATA
To convert the entire thing to plain text, simply strip the HTML tags out,
and change the content-type header:
#!/bin/sh
cat <<- /HTML-DATA
Content-type: text/plain
$(date)
Masqueraded Connections:
$(/bin/netstat -Mn)
Other Connections:
$(/bin/netstat -n)
/HTML-DATA
Of course, you can provide text seperators, whitespace, and other formatting
as required if you need to easily parse the data on the far end.
Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Dachstein release-candidate available
I have posted the first release candidate (rc1) of Dachstein on my website: http://lrp.steinkuehler.net/DiskImages/Dachstein.htm Just today, I made a large number of changes in the weblet pages, finally converting to the much more attractive pages designed by Justin Ribeiro. I also migrated the cgi-scripts to use the new layout. If there are any new bugs, they are probably in changes I made to the web pages, so please a close look at the weblet pages by all new Dachstein users would be appreciated. Note that the web pages are a fair amount larger, but I think the better look makes up for the extra space. Also, I added the java bandwidth applet for convinence, which is huge. If you really want to save space and make weblet tiny again, remove the .jar file and put the java application code on your workstation instead of the LRP system. Other changes: -- Changes from pr4 to rc1: -- e3 default mode switched to Nedit readme file updated to reflect changes to editor and new packages kernel and modules switched to dachstein-small (I think I somehow had ewald's kernel and/or modules mixed in) removed pr4 tag from firewall script headers removed unused /etc/e3.conf added shell /etc/POSIXness.conf for setting mail variables added /etc/POSIXness to /var/lib/lrpkg/root.sys.conf changed root version from 4.0.0 to 4.0.1 weblet pages updated to modified versions of Justin Ribeiro's page design cgi scripts updated to use the new format as well The following features were not added to this release: modifications to backup scirpts (deferred to CD-ROM version) There will be an entirely new packaging system for the next major release easily allowing traffic to external private IP space This is still possible by editing ipfilter.conf Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: [Leaf-user] Dachstein-pr4 available
> I have a somewhat dumb question, ok. > > How do I get this image onto a floppy. > > when I use "dd of=/dev/fd0 if=dachstein-pr4-1680.bin" > > ]$ dd of=/dev/fd0u1680 if=dachstein-pr4-1680.bin > dd: /dev/fd0u1680: Input/output error > 19+0 records in > 18+0 records out > -- > > any ideas? Did you format the disk for 1680K first, or are you using a 1440K pre-formatted floppy? The 1440K format has 18 sectors/track, vs 21 sectors/track for 1680K, so your 18 records out indicates it's highly likely you don't have sectors 19-21 formatted... Charles Steinkuehler [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Testing...
Please ignore...testing my all-new proxy-arp DMZ setup. The list was the handiest available e-mail reflector :) Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Dachstein-pr4 available
Dachstein pr4 is now available in the usual location: http://lrp.steinkuehler.net/files/diskimages/dachstein/ WARNING: I'm going to be switching my firewall from a static-NAT DMZ to proxy-arp, which will likely create periodic interruptions in the availbility of my web server. You might want to check the SF mirror if my site is unresponsive: http://leaf.sourceforge.net/devel/cstein/files/diskimages/dachstein/ The main change is bugfixes in the new firewall scripts. I have now verified static-NAT DMZ functionality with the new scripts (no hand-editing of ipfilter.conf required for spoof protection!). Other notes from the changelog: -- Changes from pr3 to pr4: -- firewall scripts modified/enhanced: changed ALL imap references to imap2, and added imap alias in /etc to boot! fixed several bugs preventing proper operation of static NAT DMZs minor fixes for bash shell (firewall scripts now work with ash or bash) -- Next, I'm planning on switching my own DMZ to proxy-arp, testing that part of the firewall scripts, and I'll be making modifications to the backup and init scripts, allowing the floppy disk and CD distributions to share the same base code. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] lrpStat
> Try this ( just modify the inital size width & height ) Thanks...a slight variation of your code seems to do what I want. The updated version is online at: http://216.171.153.180/ > Could someone test it with netscape, I don't have it installed on my > machines If someone running netscape could go to the above link and see if the bandwidth monitor functions, I'd be grateful... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] lrpStat
> > Does anyone know how to get the applet to pop up in a scalable window when > > it's loaded from the web page? > I guess it is possible already, by using javascript to bring up a new window > (preferably without any navigation and URL toolbars), so it'll look just > like one of those annoying ads that are part of some sites. As Etienne > pointed out, in this case you'd have to use "WIDTH/HEIGHT="100%" in that > case). > > If that's not sufficient, I could extend the applet to (optionally) run in a > separate frame I've got the applet launching in it's own browser window, but it's still got the toolbars, menus, and such. If someone can point me towards some java-script to pop up a 'borderless' window, I'd appreciate it (I'm not much of a web design guru). > (but let me know quickly, since I'll be on my way to the States for two > weeks on sunday, so I won't be doing any work on that during that time). I > guess there's not much chance of meeting anyboy in the Andover/Boston area > over the next two weeks? ;-) Well, I don't know where everyone else is, but I'm in the middle of the country (Kansas), so you probably won't be bumping into me ;-) > Basically, my idea was that the applet was included in a whole page of infos > about the system (like, all the information that's displayed by the weblet > pages), and the application was for viewing _only_ the network stats. That's how I'm configuring things...see: http://216.171.153.180 Assuming the system stays online...I don't know how weblet will handle being hit by all the nimda probes now that I've opened it up to the world... > Let me know if there is something I should do - I would gladly do so. Heck, > I already feel honoured that it'll be included in your dachstein release. I always wanted to include the stats package...sadly, this is the first time I've re-rolled a release since you got it running . Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Dachstein-pr3 available
Dachstein pr3 is now available in the usual location: http://lrp.steinkuehler.net/files/diskimages/dachstein/ There are two main changes: A major bug with port-forwarded DMZ setups was fixed, and I have added the lrpStat application to weblet. There are several other changes as well...from the changelog: -- Changes from pr2 to pr3: -- firewall scripts modified/enhanced: fixed problem with port-forwarded DMZ added EXTERN_*_PORT and EXTERN_PROTO functionality changed imap references to imap2, to match /etc/services Weblet updated c0wz link fixed, mirror links added for c0wz & steinkuehler sites leaf homepage added title updated to dachstein automatic refresh disabled lrpStat added and configured e3 modified to not create backup files dhclient started in rcS instead of rc2, so it runs before network scripts required for proper port-forwarding if external address is dynamic -- As always, please report any problems and I'll try to get them fixed... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] lrpStat
I'm in the process of adding lrpStat to the weblet pages of Dachstein, and have a question. When I run the java applet in a web browser, it has a fixed size, specified as width and height in the applet tag. If, however, I run the application from the command line, I get a scalable window. Does anyone know how to get the applet to pop up in a scalable window when it's loaded from the web page? Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ipchains redirect
> > I haven't played with this much, but one of the things on the list of stuff > > to "play with one of these days" is using redirect to provide for an > > 'internal server' machine, similar to the way the low-end firewall boxes do. > > I *think* this would work properly for everything from game servers to VPN > > access, although security in such a situation isn't the greatest (although > > it's not too bad if combined with port-forwarded DMZ rules). > > Not sure I follow: would you use redir instead of > portfw rules? Or do you see it being used on the internal > interface's input chain? No, the redirects go on the external interface input rules. The basic idea is to mimic the functionality of the firewall 'bricks' available from Linksys, D-Link, Netgear, &c that provide for a single internal "server" IP. Basically, any inbound packets that are not either destined for local services or existing masqueraded connections, get forwarded (redirected) to an internal system. I *think* this can be used like a partial static-NAT, essentially splitting the single available IP between several systems. The fundamental difference between doing this with a redirect and using port-forwards, is the flexability of IPChains. I think the redirect rule could send anything not dealt with by previous rules to a remote system (even non-TCP/UDP traffic), providing a 'catch-all' port-forwarding I don't think it's possible to implement with portfw. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ipchains redirect
I haven't played with this much, but one of the things on the list of stuff to "play with one of these days" is using redirect to provide for an 'internal server' machine, similar to the way the low-end firewall boxes do. I *think* this would work properly for everything from game servers to VPN access, although security in such a situation isn't the greatest (although it's not too bad if combined with port-forwarded DMZ rules). Charles > Heyaz. Saw this on security-basics this AM. Never > saw it mentioned on LRP/LEAF before; anyone ever try it? > Alternatively, is "IP Transparent Proxy" enabled in any > LEAF kernels? Seems terribly powerful to me. > TIA! > > -Scott > > -- Forwarded message -- > > Date: Wed, 19 Sep 2001 20:19:19 +0200 (CEST) > From: Bosko Radivojevic <[EMAIL PROTECTED]> > To: Daniel Chojecki <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: ipchains, ipmasqadm > > On Tue, 18 Sep 2001, Daniel Chojecki wrote: > > > Is it posible to redirect all traffic comming for 0.0/0 80 to local > > squid proxy using ipchains and ipmasqadm. > > Using ipchains - yes. I'm not sure for ipmasqadm (I've never used it) > > I'm using those lines for that. Of course, you have to enable 'IP > Transparent Proxy' in your kernel. > > ipchains -A input -p TCP -d YOUR_IP/32 www -j ACCEPT (in case you have > your own web server) > ipchains -A input -p TCP -d 0/0 www -j REDIRECT 8080 > > > Conf: > > 2.2.19 > > ipchains > > It works for me: 2.2.18 & ipchains 1.3.9, 17-Mar-1999 > > Greetings ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] dachstein-pr2 available
I have just posted pre-release version 2 (pr2) of dachstein. The main change from pr1 is the merging of the several versions of firewall scripts I've got floating around. I've finally updated the (somewhat hacked) static-NAT DMZ support of the extended scripts V1.1, and merged this functionality with the Eiger based proxy-arp scritps from LRP-CD. I don't have an updated network.txt file documenting everything, but I did add and clarify the comments in network.conf, so if you're familiar with any of the existing scripts you shouldn't be too lost. I haven't done a lot of debugging on the DMZ aspect of the scripts yet, but the internal network portion is working OK. If anyone has the time or inclination to test firewall scripts, I'd be grateful. Disk image & readme available here (and the normal mirror locations): http://lrp.steinkuehler.net/files/diskimages/dachstein/ Other info from the changelog: -- Changes from pr1 to pr2: -- dnscache modified to use 0.0.0.0 for listen IP, allowing local name resolution to work using 127.0.0.1 as the dns server /etc/network.conf no longer sourced in dnscache config file, as local IPs are no longer required firewall scripts changed to LRP-CD (Eiger based proxy-arp) version with extended scripts 1.1 functionality folded in...full support for routed, proxy-arp, static-nat, and port-forwarded DMZ systems dhclient init script fixed to support multiple interfaces Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] lrp.steinkuehler.net back online
Well, I'm back in town, and my site and I are both back online. I have yet to get any of the queued leaf list e-mails, but it should be headed this way along with other delayed mail as smtp servers around the net process their mail queues and notice my new IP settings. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] lrp.steinkuehler.net
!! - WARNING - !! My DSL service provider (currently DSL.net) is discontinuing service in my area. Sometime next week, the wire pair carrying my SDSL connection will be cross-connected to the new provider (NewEdge networks), at which time my internet connectivity will go down until I swap routers and re-configure the IP addresses on my network. Since I'll probably be out of town when this happens, there will likely be a 2-3 day outage in my web services. The mirror sites, including the sourceforge mirror will still be online. On the positive side, I should shortly be able to bump my upstream bandwidth from 384K to a full 1.5 MBit. I may also have aquired 4 DEC Alpha personal workstation 500a systems to use as servers. If I get access to these machines, I'll probably try to make an LEAF build environment that supports cross-compiling, and test new distributions (post Dachstein) on x86 and Alpha hardware. While I don't think there's a big need for alpha based router/firewalls, having a good cross-compile development environment would go a long way towards making LEAF usable by folks making it easier to build stand-alone 'black-box' systems. Maybe I'll even get someone do donate a PPC NPe405H eval system I can use to port linux/LEAF to (hint, hint :) Look for things to return to normal (and a few web updates) the following week. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Kernel size
Some of the notes I took on kernel size when compiling the new 2.2.19 kernels. While the numbers won't directly apply to future kernels, I'm posting them in case someone else might find them useful. All sizes are relative, and based on the size of the zImage file created. I didn't test with UPX compression (which could make a significant difference), and I don't have detailed config files for the various options, but the numbers still give a general idea of what adds size to the kernel, and how much it adds. Also, the numbers are for the core kernel size only, and all options are compiled as modules if possible. As an example, when you add IPV6 support to the kernel, the core kernel size grows even if you compile IPV6 support as modules. The number below for IPV6 is the ammount the core kernel increases in size...if you actually wanted IPV6 support, you'd also need a lot more free storage for the IPV6 modules. Backward-compatible /proc/pci ~ 10,170 Parallel port support PC-style hardware ~ 0 IDE and netblock support ~ 23 IP: multicasting ~ 808 IP: multicast routing ~ 4807 The IPv6 protocol (EXPERIMENTAL) ~ 1164 Bridging (EXPERIMENTAL) ~ 8596 QoS ~ 6893 Telephoney ~ 0 SCSI ~ 3 I2O ~ 0 Arcnet & appletalk devices ~ 0 Fibre Channel driver support ~ 523 Mouse Support (not serial mice) ~ 2019 Reiserfs support ~ 1127 Native Language Support (additional languages compiled as modules) ~ 0 Sound ~ 0 Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Dachstein Pre-Release avaialble
> At 07:02 PM 8/21/01 -0500, Charles Steinkuehler wrote: > >I've uploaded a pre-release version of Dachstein, which can be found here: > >http://lrp.steinkuehler.net/files/diskimages/dachstein/dachstein-pr1-1680.i m > >g > > Charles -- > > You might want to repost this file with an extension that your Web server > recognizes as indicating a binary file (such as the .bin you use for > EigerStein). My Netscape-on-Windows system tries to download it at text, > with the familiar problems attendant to that. The above link has moved to: http://lrp.steinkuehler.net/files/diskimages/dachstein/dachstein-pr1-1680.bi n The previous URL is now a link to the .bin file. I have also found a bug in the pre-release image. The /etc/dhclient.conf file prepends 127.0.0.1 to the DNS servers provided by the ISP. This is incorrect. The correct IP to prepend is 192.168.1.254, which is the IP dnscache listens on. This will be fixed in the next release. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Dachstein Pre-Release avaialble
I've uploaded a pre-release version of Dachstein, which can be found here: http://lrp.steinkuehler.net/files/diskimages/dachstein/dachstein-pr1-1680.im g Pre-release means that I *know* there are things that will change before the release version. See the readme file below for details on what's changed from Ewald's latest ES2B update image, and what remains to be done. I have generally verified the image boots and functions, but I haven't pounded on it a lot...since several scripts have changed, there could be some hidden problems. Try it if you're daring (or can spend some time testing for bugs), but I wouldn't use it for production systems yet. Please post any problems, desired changes, &c to the list, for fixing/inclusion in the next image, which will hopefully be a release candidate. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) -- Changes from Ewald Wasscher's May 27 EigerStein2Beta update: http://leaf.sourceforge.net/devel/ewaldw/Eigerstein2BETA/20010527/Eigerstein 2BETA_test_20010527_1680.bin -- Release officially named Dachstein Syslinux splash screen replaced with version from Richard Lohman dnscache modified to use 0.0.0.0 for IPSEND dnscache still run from script (rather than daemontools) due to licensing issues with daemontools dhclient modified to no longer restart dnscache when getting a new IP log.lrp replaced by ramlog.lrp, which puts log files on their own ramdisk partition. /etc/fstab updated to reflect new mount point for /var/log dhcpd and dhclient modified to prevent storage of dhcp leases as part of root.lrp dhclient.conf modified to prepend 127.0.0.1 (local dnscache) to DNS servers provided by ISP's dhcp server Backup scripts reverted back to using ctar, to avoid file exclude problems when backing up root.lrp root.list changed from * to ./ to fix include problems backing up other packages (like etc) e3 replace with re-compiled version: Pico emulation set as the default mode, and the ":x" command was added to VI emulation -- TODO -- Update the readme to reflect changes to the editor (ae -> e3), and any other changes that affect end-user setup "walk-through" to verify the readme instructions Update network/firewall scripts, folding together LRP-CD and extended scripts V 1.1 functionality Add java bandwidth applet to weblet.lrp ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Tagline
I'm using one of the syslinux spash screens provided by Richard Lohman for Dachstein. Richard apparently replaced the old 'tagline' "Embedding the bird for the sake of all humanity" with "Don't fear the penguin...". I like the new version better than the old, but I though this would be a good topic for a survey (assuming the survey part of our PHP code is working). So post your favorite sound-bite for LEAF in general, and Dachstein in particular. A few 'quickies' (if no-one comes up with anything better, I'll use Richard's...I don't claim to have the marketing 'golden touch'). Guarded by the penguin Security penguin on duty >From Finland with love Waddle-waddle-waddle OK...I'll stop sniffing paint fumes (yes, I just painted my office) and go home now ;-) Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] SF Site Status
> Everyone, > SourceForge is implementing quotas on project directories. 150MB soft quota > and a 1GB hard quota. We are currently using 850MB. > > We need to start moving files into CVS and the Files area. Neither of these > areas have quotas. I'm open to suggestions for CVS tree structure. The > Files area should only contain tarballs and images. I'm currently responsible for about 250M of the data, which is the current size of my website. I can fairly easily remove some of the kernel directories for a savings of about 50M (remove 2.2.13 & 2.2.15) to 100M (remove 2.2.16 as well). Removing the kernel directories entirely and placing just the tarballs in the release area would save about 200 Meg, at the expense of not being able to download/browse individual modules/kernels from the SF mirror of my site. Most of the remaining 50 Meg is consumed by various disk images and lrp packages. Many of these could migrate to the file releases area (and perhaps should), but if they disappear from my web-directory to save space, the download links on my site will break. Let me know if you'd like me to clean up my kernels directory, and how 'thorough' I should be. Charles Steinkuehler [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Compressing kernel with UPX ??? (slitghly OT)
> From: "Charles Steinkuehler" <[EMAIL PROTECTED]> > > Make sure you've got the latest UPX. You'll need 1.11 or later to > compress > > kernel images. Both zImage and bzImage files can be compressed > successully > > by UPX. The command I use is: > > > > upx --best -o .upx > > > I compiled UPX 1.20 under my Slink machine and UCL 0.92. > Compilation went fine. No errors. I ran the suggested command. > I get an: > UnknownExecutableFormatException > error message :-( > Jacques Reports are you need the beta V1.11 to compress the kernel...apparently V1.2 "forgot" how to compress kernels. I'm using V1.11 and know it works. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] RAID kernels released
The RAID version of the new 2.2.19 Dachstein kernel is now online. The current kernels are untested (I hope to get around to testing next week), but *should* work, unless I goofed when migrating the RAID modifications of linuxrc-always from kernel 2.2.16 to 2.2.19. If anyone actually uses these kernels in a RAID environment, please let me know. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] 2.2.19 kernels
I've updated the 'normal' series kernels to include serial port console support. I've also slightly re-arranged the files. The kernel directories now only contain the kernels, config files, modules, and readme file. There is a new source directory that includes the config files, patches, additional device drivers, and scripts to build the kernel source. This was seperated out from the kernel directories to save space, and make downloads easier (most folks looking for a tar.gz of all the modules don't need the kernel source, & vice versa, and there's no need for several copies of identical source files in the seperate kernel trees). Finally, I'm compiling some RAID kernels right now. Hopefully I'll be able to get them online today, although I won't be able to test them until next week. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: 2.2.19 Kernels available
> > It still looks like you don't have the LRP kernel patches properly > > applied to your kernel. > > Well, you were were right. I didn't watch the output when I ran your > patching script originally. This time I notices all the 'file does not > exist' messages... > > And why did the original run fail... Well, it seems when I extracted > your 2.2.19-1.tar.gz, it ended up in /usr/src/2.2.19-1, not in > /usr/src/LEAF-kernel-2.2.19, which is coded in the scripts as the > SRC_DIR. So I edited the scripts and re-ran them. Building the new > kernel now. Yeah, this was a problem with me when I first started using Matthew Grant's scripts to build the kernel source, which my scripts are based on. I think I'll change the /usr/src/LEAF-kernel-2.2.19 to `pwd`, and add a comment to the readme that you must run the scripts from the current directory. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Compressing kernel with UPX ??? (slitghly OT)
> Hello everyone > I am trying to figure out hox to compress a linux kernel with UPX > I compiled with make bzImage and the tried upx -l9 bzImage. Did not > worked. Should I compile with make zImage instead ? > Jacques Make sure you've got the latest UPX. You'll need 1.11 or later to compress kernel images. Both zImage and bzImage files can be compressed successully by UPX. The command I use is: upx --best -o .upx where is the kernel image file. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Modifiyng Kernel messages which appears while booting
> I have a question about Kernel compiling options (sorry, i didn't found this > in the Kernel How-To) > > 1. How do I configure the message which appears just after loading the > kernel? i mean this message which shows the compiling date&time, > username@machine and so on. I want to adjust this message. The version string is defined in init/version.c, using environment settings created by the top-level Makefile. You can directly edit the string in version.c, or edit the pieces used to generate it in the Makefile (the latter is probably the safer option). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Static Compilation...
> ...that fails. The *ONLY* difference is adding "-static" to the gcc > command line. What's the difference? Well, the -static on the command line is what's different, you said so yourself. :-) I'm grasping at straws, but do you have the object modules for your c library somewhere the compiler/linker can find them? It kind of sounds like the linker might not be finding all your library object files... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] POSIXness -> CVS
> > As I'm mainly looking for a stable replacement to my Eiger series disks, and > > the overall size of the distribution has shrunk considerably already, I'm > > going to stick with ctar for package creation. I'm hoping this will be the > > last of the primarily LRP based releases, with new stuff using an updated > > packaging format, likely some version of your apkg application. > > What do you mean by "last of the primarily LRP based releases"? The last of the releases I plan that will include a substantial portion of code from LRP systems. Major LRP chunks and their planned replacements: Kernel Patches: I'd like for these to go away...the work you're doing with removing things from root.lrp helps here, as what I'd like to see is a fairly small conventional ramdisk image that rarely (if ever) needs to be altered. No more funky LRP kernel patches to mess with...use any kernel you've got space for on your boot disk. POSIXness: Mainly replaced by busybox, but there will probably be a few script based applets. Network init scripts: I think something more graceful can be done here. The 'mountain' images already share very little network.conf code with 2.9.x releases. Script based package system: Replaced with apkg, modified apkg, or possibly something completely different. Firewall scripts: Not a part of LRP 2.9.x at all, but will be replaced by something like SeaWall, rcf, &c. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: [Leaf-user] 2.2.19 Kernels available
> Do any of these include support for PCMCIA? I would like to build a 2.2.19 > that includes PCMCIA support.any help on this is appreciated. No...you'll need to compile the PCMCIA code. IIRC, there are some PCMCIA-enabled versions of LRP floating around somewhere... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] POSIXness -> CVS
> > Side Note: I plan on going back to using ctar to create LRP files, as there > > are still problems with proper file inclusion/exclusion using the BB tar > > command. > > Can you elaborate? I'd like very much to remove ctar... In the scripts Ewald modified to use busybox tar, root.lrp did not backup properly. IIRC, directories that were part of other packages (like etc) would be excluded even if they were not at the same level. In other words, I created the following directory structure: /boot /boot/etc /boot/etc/file1 /boot/otherdir but after backup & restore, I was left with: /boot /boot/otherdir As I'm mainly looking for a stable replacement to my Eiger series disks, and the overall size of the distribution has shrunk considerably already, I'm going to stick with ctar for package creation. I'm hoping this will be the last of the primarily LRP based releases, with new stuff using an updated packaging format, likely some version of your apkg application. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] POSIXness -> CVS
I'm finally getting around to working on Dachstein. The first order of business is to fix package creation (part of the POSIXness scripts). If there are no objections, I plan on making a CVS tree for these scripts, similar to the CVS tree for weblet, so changes can begin being archived. Ultimately, I'd like to have some sort of configuration utility, similar to how busybox works, allowing you to define functions POSIXness should include, but I currently plans are to simply check in the version Dave Cinege released with LRP 2.9.8, then check-in a few updates I've made since then, and finally make any mods required for Dachstein. Side Note: I plan on going back to using ctar to create LRP files, as there are still problems with proper file inclusion/exclusion using the BB tar command. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: [Leaf-user] 2.2.19 Kernels available
> Charles Steinkuehler wrote: > > I now have version 2.2.19 kernels (and associated modules) available for > > download from my website. Also available are all required patch files and a > > script to build a LEAF kernel tree from a raw 2.2.19 kernel source tarball. > > Which of these is applicable to LRP-CD ??? You can use any of the kernels for LRP-CD, although you'll obviously have to burn a new CD. Start by making a floppy disk of the boot-image on the CD-ROM. Replace the kernel on this disk with the new one. You'll also have to create a new root.lrp that contains the appropriate modules (remember to include the IDE modules if you don't use one of the IDE kernels). Once you get the system booting properly off the floppy, you can burn a CD using your new boot image. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Kernel 2.2.19 from Ewald Wasscher and Sources for CIPE
> I want to compile CIPE for 2.2.19 (Eigerstein2Beta from Ewald Wasscher). > http://leaf.sourceforge.net/devel/ewaldw/Eigerstein2BETA/20010527/kernel/ > But there are no sources. I ask because I want to compile CIPE for this > kernel (I hope I get my Debian ready, I guess it's not so easy to set up > Debian as setting up SuSE or RH). > > It's not a problem for me to use another kernel, but I want to try it with > my current one. I wasn't able to get the kernel source (or enough details to re-create) from Ewald, who seems to have disappeared. I have re-created a 2.2.19 source tree similar to Ewald's, and have several kernel config files ready for release (just a bit more work to do on the trimmed down floppy/firewall only kernel version). If you want, I can send you (or post online) the patches & scripts required to make the kernel source...what I'll be releaseing as the Dachstein kernel as soon as I get the extra-slim configuration finished. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Thinking and rambling: about using a non-sh shell for /linuxrc...
> Imagine a boot disk where ash, busybox, or libc could be upgraded with > very little effort just copy in a new one and run. I've been wanting to do this for ages (just not enough time), and is what I mean when I say I want to keep the core system flexible enough to run with various versions of libc. IMHO, root.lrp should be renamed to something like bootstrap.lrp (or similar...please excuse the 9.3 name), and contain only the absolute minimum required for unpacking the rest of the system. Exactly *what* the bootstrap system looks like is still up in the air. It could be lua code, busybox sh compiled against uLibc with a few helper apps, a small Forth program, or even custom written C code. Whatever it winds up looking like, there's a big premium on it being as small as possible. To still enable a single-disk system, which is obviously quite limited on space, there are two options: 1) The new bootstrap functions are kept small enough to be added to the existing LRP files. With things like UPX kernel compression, and some other space-saving measures, this isn't entirely out of the question. 2) Re-use the bootstrap code in the running LRP system. For instance, if the bootstrap package had a tar, gzip, and other standard utilities (or libraries), these could be re-used by a floppy version of root.lrp. Folks with more space available could still install a "full" system, using none of the files from the bootstrap package. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] NoCat Net
> My requirements are secure point to point connecting 2 wired networks. At this time I do not need roaming connectivity (though that may change, I don't have a laptop). What I plan to do to accomplish this is get it working first, then do a PPP over ssh2 (ya, 2 floppy disks ) so that it will be somewhat resistent to sniffers. Not that I am worried where I am yet, but, as I told a friend, we might as well do it right. I'm looking to do this as well, but I plan on using IPSec instead of PPP/ssh. Please be aware that a PPP/ssh link will not degrade well if you start loosing packets...the PPP layer and the TCP layer under ssh *both* try to account for dropped/mangled packets, and can wind up interfering with each other in bad ways. IPSec is designed to work with 'lossy' networks, and takes care of dropped/mangled packets cleanly. Note that as long as your link is clean, PPP/ssh should work fine... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] EigerStein3/Dachstein
> Charles, > What can we do to help you get the new release finished? Come to KS and help me unpack my office, pack my personal belonging, and move into my new house. ;-) Actually, there's quite a bit that can be done...from trolling the list archives: > - The distribution needs a name...again, I'd prefer Ewald to name it, since > he's been doing all the work The name is Dachstein. PROGRESS!!! > - The syslinux splash screen should be changed. It should probably refer to > the leaf sourceforge project. We may also want to pull the links to > linuxrouter.org, but I'm not sure about this... > - The readme file needs to be updated with (at minimum) new links and new > instructions for e3 rather than ae as the editor > - The readme instructions need to be verified (ie put on LUser hat & walk > through the readme like a newbie, making sure nothing unexpected happens). > > And on to 'real' changes required/desired: > > - I'd like to see the java bandwidth applet added to the weblet package > - I'd like dnscache to be run by the daemontools package, if it doesn't > require too much disk space...this should help keep things standardized, and > make tinydns package maintainence easier > - Use the ramlog package instead of the log package...this puts the logs on > a seperate ramdisk, avoiding the full ramdisk issues, which are the most > likely thing to kill a working LRP system. > - Remove old dhcpd and dhclient leases...that these are around is my fault, > as they are getting backed up with root. I need to add an exclude.list file > to each package. > - Modify the dhclient.conf file to properly generate an /etc/resolv.conf > that uses the local dnscache > - Update the network scripts...I need to fold my proxy-arp and Extended > scripts V1.1 together and create what will likely be the last of the > 'mountain' firewall script derivations. I'd like to see future images use > seawall, rcf, or similar. I've got work done on the dhcpd/dhclient pacakges, and using the ramlog package instead of log...as long as I can find my test disks (they're in a box somewhere), these are done. I'm likely the only one to modify the networking scripts, as I've got to fold together pieces of 3 different scripts into a unified whole. Stuff someone other than me can work on: Go back to using ctar to create the LRP files when backing up. I ran into problems archiving root.lrp when using the new scripts. Ctar is small enough, and package archiving is important enough, I'd like to leave it 'as-is' in this release. Verifying the dnscache configuration. While I was previously thinking using daemontools would be a good thing, recent threads on the licensing have made me change my mind... Updating the weblet package Updating the syslinux splash screen Updating the readme file There's probably more stuff, but this is what comes immediately to mind... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Going to glibc-2.1 (or glibc 2.2)
> Here are my questions (direct and to the point :-) > > 1. Is Eigerstein (or Dachstein) going to upgrade to a new version of > glibc? No. For clarity, if nothing else, Eigerstein, Dachstein, and any other direct decendants will stick with the 'old' glibc. > 2. Is LRP likely to upgrade to a new version of glibc? Who knows/cares ...I think it was Dave C's intention to go to 2.[12] and a 2.4 kernel with Butterfly... I think any new LEAF based projects should/will use a newer glibc. I have no real preference between 2.1 and 2.2, although I'd probably use the latest assuming there's no huge size penalty or other problems. > 3. What is your opinion: is compiling against glibc 2.0 worth the > trouble? Or should everyone migrate their packages to glibc 2.1 or 2.2? I think packages will begin to be compiled against whatever new glibc version is used in various distributions... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Using a new shell for linuxrc?
> All of this is part of an effort to shrink root.lrp; I've already > removed /var/spool/cron (to a new cron.lrp) and much of /sbin to > init.lrp > > What do you think of using lua for writing /linuxrc? Anyone here have > experience in lua? > > I'm about to dive in headlong :-) I still haven't looked at lua, so I don't know how it would work for /linuxrc. I've been figuring on working to build a busybox sh based /linuxrc, possibly statically linked against a stripped ulibc, and see how small a "boot-strap" lrp could be made. Root.lrp (and all other packages) would be loaded by the /linuxrc script. If you dive into lua, let us all know what it's like. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Licensing (specifically, djb)
> Has anyone contacted DJB? He may be willing to make an exception for the > LEAF project, or even create packages himself. E-mails I sent regarding his licensing for djbdns went unanswered. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Site update 2001-07-12
> Everyone, > I just finished updating our web site Guides, HOWTOs, and Man Pages pages. > Any feedback is appreciated. Also, please look at the new Download page, > and my update of the Packages page. Thanks. I took a look at your site updates earlier but forgot to reply. Once again, it looks like you're heading in the right direction, and doing the work no one else manages to get done. Kudos! Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] More packaging enhancements
> A couple of requests. > > 1. It would be useful to integrate one the extended scripts unto > DachStein. (You probably already thought of this :-) > So it would be nice for DachStein to be EigerStein2beta workalike > (e.g. with the network defaults as I mentioned above) with the > added functionality of the extended scripts already in there in case > the user decided he or she needed them. Yes, this is planned. The scripts released with Dachstein will likely be the last of the 'Mountain' firewall scripts, as future plans are to support several pre-packaged firewall scripts (seawall, rcf, &c). > 2. One irritation it would be nice to fix (though it may go beyond the > "quick upgrade to EigerStein2Beta philosophy) would be to > somehow extend the 256 character limit of the syslinux.cfg > APPEND= line. When I add a second drive to PKGPATH and add > serial support, I'm over the limit. I can't do both. (I recall that David > did something in Oxygen to get around this.) The 256 character limit is a kernel restriction, so is unlikely to change soon. It is possible to load non-critical LRP packages AFTER the kernel has booted, from a config file stored on disk, dramatically reducing the size of the LRP= part of the kernel command line. I believe this is what David is doing with O2. > Finally, a quick question. If all I want to do is add a simple DMZ to > my EigerStein2Beta network via a third ethernet board for a web > server at the public IP of the LRP box (which is using dhcp), which > is better: > > 1. upgrade to the extended scripts 1.0 > 2. upgrade to the extended scripts 1.1 > 3. upgrade to the CD scripts > > It looks to me like the extended scripts 1.0 have enough > functionality, but it also looks to me like the DHCP section in those > scripts doesn't have improvements you added to EigerStein2Beta. > If I recall correctly, bothe extended scripts 1.1 and the CD scripts > have the newer DHCP code. But I could easily just paste that > section into network.conf from scripts 1.0. As near as I can tell > that's the only issue. You're correct...the 1.0 scripts support what you want. I'd stick with the 1.0 scripts and paste in any dhcp mods you need. The 1.1 scripts require you manually edit ipfilter.conf, as a couple IP addresses are hard-coded (this will be fixed in the Dachstein scripts). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Modules and directories
> > > With a nice clean-up of modules, I can forsee a tree like this:
> > >
> > > /lib/modules/boot/* (in root.lrp)
> > > /lib/modules/2.2.16/* (in a modules.lrp)
> > > /lib/modules/2.2.19/* (in an alternate modules.lrp)
>
> > Thanks. I play so much with LRP, I forget about stuff like modprobe.
We
> > should probably migrate towards the more conventional directory
structure,
> > to avoid unnecessary confusion, if nothing else.
>
> Also, this kernel versioning means that you can load multiple kernel
> version modules, and not get them tangled. However, busybox insmod
> doesn't honor the traditional order; it does (last I checked) a form of
> this:
>
> MOD=${1%%.o}.o
> insmod $(eval find /lib/modules -name "$MOD")
>
> Rather than the more interesting and compatable:
>
> insmod $(eval find /lib/modules/`uname -r` /lib/modules/2.2 /lib/modules
> -name "$MOD")
>
> (did that make sense?)
Yup...looks like it could be time for a shell alias :)
> > I've seen this done before. I think a trick like this might be good for
an
> > install script (when creating a modules package), but I don't think we
need
> > to extend the module loading code to the running system. In addition to
the
> > extra script overhead, you've got to keep a modules.dep file around.
Also,
> > the modules.dep file is pretty human-readable...maybe we should just
create
> > this file and add a couple notes in a readme or howto (or comments in
> > /etc/modules) on interpereting it...
>
> I wonder if it would not do, to create a script to further read the
> modules.dep file, and create a file listing ONLY dependencies with no
> paths: this file would very likely be very short - and by its nature,
> very accurate. Then you could refuse to load module X if module Y is
> not yet loaded (via judicious use of lsmod and grep).
>
> Let me take a quickie stab at it:
>
> From a configuration file:
>
> modX: modY modZ
> modA: modB
>
> ...script:
>
>
> ...well?
Hmm...a POSIXness modprobe? :)
Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Modules and directories
> > > Only thing I'd possibly like to do in Oxygen is to move > > > /var/boot/modules to /lib/modules/boot (the standard location, I > > > understand). > > > > I settled on putting my boot-time modules in /boot/lib/modules, following > > the layout of my HDD machines, which create a /boot partition for stuff > > required to bootstrap the system. Where did /lib/modules/boot come from? > > In modules.conf(5), it says: > > [...snip...] > > DEFAULT CONFIGURATION > >If the configuration file '/etc/modules.conf' is missing, >or if any directive is not overridden, the following >defaults are assumed: > > depfile=/lib/modules/`uname -r`/modules.dep > > path[boot]=/lib/modules/boot > With a nice clean-up of modules, I can forsee a tree like this: > > /lib/modules/boot/* (in root.lrp) > /lib/modules/2.2.16/* (in a modules.lrp) > /lib/modules/2.2.19/* (in an alternate modules.lrp) > > ...and so forth. However, be wary of symbolic links; I don't think that > busybox insmod follows them, but in any case, busybox and GNU, symbolic > links are a problem. Thanks. I play so much with LRP, I forget about stuff like modprobe. We should probably migrate towards the more conventional directory structure, to avoid unnecessary confusion, if nothing else. > I also noted recently in the busybox list, someone said that he used > modprobe to generate modules.dep (in a build environment) then used a > shell script to analyze modules.dep and create the appropriate module > load in the appropriate order. Thoughts? I've seen this done before. I think a trick like this might be good for an install script (when creating a modules package), but I don't think we need to extend the module loading code to the running system. In addition to the extra script overhead, you've got to keep a modules.dep file around. Also, the modules.dep file is pretty human-readable...maybe we should just create this file and add a couple notes in a readme or howto (or comments in /etc/modules) on interpereting it... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] More packaging enhancements
> David, > Would it be a good idea for us to follow the LSB 1.0 specs? > > http://www.linuxbase.org/ > https://sourceforge.net/projects/lsb AFAIK, we can't follow LSB and still fit on a floppy, but we should probably try to not break any LSB rules. It may be possible to make a superset of some LEAF distribution LSB compliant, but I'll have to read through more of the spec... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] More packaging enhancements
> > I think the .req should be based on a functionality list, not a simple > > package name. There should also be some way to differentiate versions > > and/or functionality. For instance, it's probably important to be able to > > tell the difference between glibc versions, and between POSIXness, busybox, > > and full GNU versions of some commands. > > Yipes! Getting carried away a bit :-) > > For me, I almost hesitated to put that in - but the way I build packages > (main binary in bin.lrp, needed dynamic libraries in libX.lrp) adding > requirements is a big win. > > However, these are my goals: > 1. Simplicity > 2. Simplicity > 3. Simplicity :-) I like Simplicity, but that's pretty much what we've got already. I'm thinking more along the lines of "small but flexible". I'd like to see how much of a decent packaging system could be made with just shell scripts and possibly a few small programs (like md5sum and possibly a crypto signer/verifier). > Versions would be nice - probably doable - though, then you get things > like "versions earlier than X" or "version X or later" or "version Z > only"... And THEN you get versions like 0.91a05072001-1 ...uhoh... or > even (gasp) 01May2000 ...or worse... Maybe versions aren't such a good > idea... Yeah, versions can get real ugly real fast. I think there should be *some* form of versions, though, at least for stuff like shared libraries. > Secondly, this would be for installed packages; glibc is not an > installed package (at least, not currently); neither is busybox, nor > things like GNU sed. Also, Oxygen is likely to do away with POSIXness > altogether... I guess I'm thinking of broader variations in the base functionality. For instance, a minimal system might have a small busybox and some POSIXness scripts. There might be other [root|base|whatever] packages that include a larger busybox, or full GNU versions of the base commands. I think this stems from the fact that I'd like to make both floppy-disk based firewalls and single-purpose, very thin servers... > However, the idea of building in "functional" requirements is well-taken > - but not so easy to implement. For example, some things may require a Too much to think about right now, with my head wrapped up in kernel compiling. Lots of good thoughts, though. More comments later... > Another thing: what if you have 40 packages loaded with *.conf files? > The screen is only 22 or 23 or 24 lines long. > > Like I said: I should be able to do all sorts of mayhem, and lrpkg > handle it in stride. It can't. Yeah...there are several things of this sort that could be considered 'broken'. I'm not great fan of lrpkg, but would rather work on it's replacement than spiffy it up, and I'm unaware of any show-stoppers that prevent it from being usable (although it would be nice if it could verify it didn't run out of RAM when backing up). > Only thing I'd possibly like to do in Oxygen is to move > /var/boot/modules to /lib/modules/boot (the standard location, I > understand). I settled on putting my boot-time modules in /boot/lib/modules, following the layout of my HDD machines, which create a /boot partition for stuff required to bootstrap the system. Where did /lib/modules/boot come from? Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Kernel stuff
> Charles Steinkuehler, 2001-07-11 09:08 -0500 > >*DOH* Of course, I'm not using gcc on RH to compile the kernel...it's > >really: > >egcs-2.91.66 > > > >egcs-2.91.66 compiled zImage size: 473320 > >gcc 2.7.2.3 compiled zImage size: 464668 > > Charles, > Have you tried the new gcc 3.0? No, I don't have a system with gcc 3.0 yet. I think I'm going to stick with my Debian gcc 2.7 system for now, but I'd like to compare results with the new gcc 3.0 when testing compile environments for future distributions. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] More packaging enhancements
> I propose the following updates to packages, and would like to start > using them: > > .sh Shell script which takes a > parameter - one of: > preinst postinst prerem postrem > ...executed by apkg at times indicated > > .descConf file describing package: > Description: > Packager: Leonard U. Ser <[EMAIL PROTECTED]> > Group: Net/Diagnostics > > .req Package list: these must already be installed I think the .req should be based on a functionality list, not a simple package name. There should also be some way to differentiate versions and/or functionality. For instance, it's probably important to be able to tell the difference between glibc versions, and between POSIXness, busybox, and full GNU versions of some commands. Otherwise, adding the files sounds good to me. An existing lrpkg system should just ignore all this. One other thing that might be nice would be some sort of cryptographic signing of the package, but I don't know if we can find crypto code small enough to include with all floppy distributions. Also, we'd need to jump through some hoops to tack on a crypto signature to the end of a tar.gz file to keep it compatable with the existing package scripts (tricky, but do-able with dd & shell code). > These enhancements will allow: > > * Restarts of currently running daemons > * HTML pages with full descriptions, etc. > * Packager can specify package group (saves grouping problems) Please clarify the last item...I'm not sure what you mean. Features I consider a *MUST* in any new packaging scheme: The ability to upgrade an installed package Support for mixed-media bootup ie load data from a package repository (CD-ROM/network/&c) and config data from a local writable source (floppy/flash/&c) The ability to backup just config data The ability to backup user data, or just package changes (ie weblet web pages). This could possibly be done by storing anything with a changed MD5 sum. I think apkg has (or comes very close to having) several of these features already. > I've already begun using the following enhancement: > > .md5 MD5 sum of all files in package > > The beauty is, lrpkg SHOULD just ignore all these enhancements. > > Anybody do any work on lrpkg to make it not ralph if .help and/or > .version are missing? lrpkg should not fail for ANY reason; > otherwise it is buggy software. I should be able to throw most any > trash at it, and not see it fall over dead. apkg was designed with this > in mind. When does this happen? I've seen several packages w/o a help file, and I think I've seen some w/o a version. What breaks? > Anybody planning to use apkg with Dachstein? I'd like to see Dachstein be a fairly straight-forward update to the Materhorn/Eiger series disks. I hope to get this done in the near term, which should happen, as I've finally gotten a bit of time to work on LEAF stuff (in addition to being busy, I've been kind of hoping Ewald would turn up again). I'll be tackling Dachstein as soon as I finish IPSec, likely later this week. I'd like to see a 'ground-up' effort including the new c libraries, 2.2/2.4 kernel support, the new packaging system (likely apkg on steroids), and other enhancements. I don't see any reason to tie these changes to existing releases, and by starting with a clean slate, we don't have to keep any backwards compatibility we don't actually find useful. It might be very convinent, for example to switch to a VFAT format for floppies, and use long filenames for packages... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Kernel stuff
*DOH* Of course, I'm not using gcc on RH to compile the kernel...it's really: egcs-2.91.66 egcs-2.91.66 compiled zImage size: 473320 gcc 2.7.2.3 compiled zImage size: 464668 Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Kernel stuff
Well, I've been playing with 2.2.19 kernels, and noticed something interesting. When I compile on my RH 7.0 box (gcc 2.96) I get a kernel that's a fair amount larger than the same kernel compiled on my Debian Slink box (gcc 2.7.2.3). gcc 2.96 compiled zImage size: 473320 gcc 2.7.2.3 compiled zImage size: 464668 The above are compiled from EXACTLY the same source (rsynced prior to compile). Anyone know any gory details about how the newer gcc differs in terms of optimizations, loop unrolling, etc? I'm also getting close to a kernel source & config set I'm happy with. Currently, I've got the following patches to the standard 2.2.19 kernel source: linuxrc-always-2.2.19.diff initrd-archive-2.2.19.diff ip_masq_vpn-2.2.18.patch.gz ip_masq_h323-dplay-icq-mms.diff Several ip_masq modules rolled into a single patch: ip_masq_dplay-0.3.00 ip_masq_h323 Version 2.2.0 - 16 October 2000 ip_masq_icq-0.56 ip_masq_mms Version 0.91 linux-2.2.19-ow1.diff linux-2.2.19-reiserfs-3.5.33-patch.bz2 I've also applied the IPSec patches to the kernel, which don't add any size if IPSec is disabled (or compiled as a module). Once I get some kernels compiled and tested (hopefully today), I'll be working on the 1.91 release of IPSec. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Kernel stuff...
> Charles Steinkuehler, 2001-07-05 13:37 -0500 > >After searching a while, I found a link to David's Oxygen CD, which I > >think has the kernel source, patches & config files (please correct me > >if I'm mistaken), but I can't seem to download this file from the > >SourceForge site (I get a DNS error). > > Charles, > Try the http links below, they can also be accessed by ftp. > http://ftp1.sf.net/pub/sourceforge/leaf/ > http://ftp2.sf.net/pub/sourceforge/leaf/ > http://ftp3.sf.net/pub/sourceforge/leaf/ Thanks for the additional links. I'm not sure why, but the SF download links weren't working properly for me, then magically started working OK. I'm currently grabbing David's latest CD image... BTW: As I've been crawling through our site, another 'tweak' presents itself. Click on one of the links above, and you'll get an apache generated index page, which is good, but with the long filenames we use (since we can't create sub-directories), it's pretty much impossible to tell what the files are without looking at the link target (shows up in the bottom bar when the mouse is over the link in IE...don't know about Netscape). This is probably one of those things we can't do anything about, but if there is anything we can do, it would be a good thing. > >NOTE: It should probably be easier to find David's > >latest releases and his CD image on the 'main' leaf website... > > Noted. > > >Ewald has also apparently compiled some 2.2.19 kernels, but if he posted > >the patches he applied (and script or similar, indicating the patch > >order), I wasn't able to find them. > > http://leaf.sourceforge.net/devel/ewaldw/kernel/2.2.19-1-LRP/ Yeah, he lists the patches he applied, but no version numbers, patch sequence, &c, making it hard to re-create his kernel tree :< Anyone heard from Ewald lately? IIRC, I haven't heard from him since about a month ago... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] SourceForge
> > When I get the Oxygen CD burned, hopefully I'll have the kernel patches I've > > been looking for, although it's kind of a drag downloading 578 Meg just for > > some patches...missing that extra D/L bandwidth I got with my ADSL line > > right about now :< > > I'm not sure why you (of all people!) would have to hunt and search for > the standard LEAF patches; didn't you compile a bazillion versions of > 2.2.15? I'm not looking for the LEAF patches...I'm looking for the other patches applied (like openwall, VPNMasq, &c). I want to make sure I've got the same versions you're running with. > Anyway, I think the CDROM from Sourceforge only goes up to 2.2.17 or > 2.2.18, but the patches are there. The directories are thus: > > ./kernel/patches > ./kernel/2.4 > ./kernel/2.2/2.2.17 > ./kernel/2.2/2.2.18 > > etc. The linux kernel source code is the original code; however, some > versions I compiled a large variety of options and put the resulting > kernel tar.gz file into the appropriate Linux kernel directory (2.2.18, > 2.2.19, whatever). Hmm...if the 2.2.19 stuff isn't on the CD, can you give me a list of the patches you applied to whatever you consider the 'most standard' Oxygen kernel? Thanks, Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] SourceForge
Well, I can download files from the SF releases area now. I don't know what the problem was, but I'm assuming it was on the SF side. IIRC, I think their part of the 'net has been under some DDOS attacks recently... When I get the Oxygen CD burned, hopefully I'll have the kernel patches I've been looking for, although it's kind of a drag downloading 578 Meg just for some patches...missing that extra D/L bandwidth I got with my ADSL line right about now :< Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Kernel stuff...
> > Ewald has also apparently compiled some 2.2.19 kernels, but if he posted the > > patches he applied (and script or similar, indicating the patch order), I > > wasn't able to find them. > > The (LEAF) patches I've used were the same ones as before; the 2.2 > kernels don't vary enough to matter with the patches. I like to > recompute them though, as its nice for a user to "know" that the patches > are compatable. If you're talking about the offsets when applying the patches, these don't worry me...as long as no hunks fail :) If you've got the re-computed patches for 2.2.19, can you send them to me (or point me to them). I didn't see any patch files in the kernel tarballs you've got on the SF site... BTW: Am I right about the CD having a full kernel source directory? If so, is it pre-patched, or are the patches available seperately, or both? > > So...anyone know where I can get my hands on a source tree for an existing > > LRP 2.2.19 kernel? > > I've got 2.2.19 kernels on the Oxygen site, and I've got source et al > floating around here. You want patches and config files? Yeah, patches & configs, but mainly the patches (and if you've got it, the order you applied the patches). I need to be able to turn a 'virgin' 2.2.19 kernel source tarball into the source tree you used for the 2.2.19 Oxygen kernels. Along the same lines, should we try to standardize a set of patches for LRP, (other than the mandatory linuxrc-always and initrd-archive), or just continue to leave this up to whoever's making a particular kernel/distribution? Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Kernel stuff...
OK, I'm looking to compile the latest FreeS/WAN (V1.91), but to do so, I need to compile the kernel as well. This isn't really a problem for me, but the latest LRP based kernels I've got around are 2.2.16. I know that several other folks have built 2.2.19 kernels for LRP, and in the interest of trying to limit kernel version proliferation (isn't that part of why the LEAF site's here in the first place?), I'd like to start with someone else's baseline kernel, and like the direction folks have been taking lately (applying openwall & other security patches). After searching a while, I found a link to David's Oxygen CD, which I think has the kernel source, patches & config files (please correct me if I'm mistaken), but I can't seem to download this file from the SourceForge site (I get a DNS error). NOTE: It should probably be easier to find David's latest releases and his CD image on the 'main' leaf website...I had to go directly to the SourceForge released files page to find these, and then the links were broken (likely yet another problem with SF) :< Ewald has also apparently compiled some 2.2.19 kernels, but if he posted the patches he applied (and script or similar, indicating the patch order), I wasn't able to find them. So...anyone know where I can get my hands on a source tree for an existing LRP 2.2.19 kernel? Thanks, Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Going offline soon
I'll be going offline sometime soon (not sure yet exactly when) as I move into my new office. The SDSL connection at the new facility went online today, so I'll be migrating my existing services, including dns, e-mail, and web servers over to the new facility sometime tonight or tomorrow. Since I'm moving my primary dns, there will likely be a 'hiccup' of a day or two until everything settles down and gets back to normal (yes, this could be avoided, but I'm too busy to mess with configuring an alternate primary and moving my DNS twice). This outage will affect all steinkuehler.net domains, including my main e-mail account and lrp.steinkuehler.net. Since the main dns is going away temporarily, access to secondary domains such as lrp1.steinkuehler.net (the SF mirror of my site) will also be spotty due to name-server issues (access via leaf.sourceforge.net, however, will be unaffected). I hope to resume normal operations by Thursday at the latest. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Tel$tra Bigpuddle is imposing a 3GB TOTAL traffic limit
> Does anyone have any input on my ideas below? I'd really like my LEAF > box to be able to supply logs/statistics so I can measure throughput per > IP address. I understand that I can run MRTG on a Windows or Linux box, > but am unsure if it will display stats based on IPs so I can check > traffic quantities per IP on my LAN. I still need a way for the logs on > the LEAF box to be archived and exported daily so there's a more > permanent record of this traffic. One way I know of to do what you want: Create "accounting" rules with ipchains. This is a rule that matches any packets to and/or from a given IP address, but doesn't do anything (ie no -j parameter). You can then configure MRTG to track the packet/byte counts for these rules. I haven't set up MRTG to do this, but I remember seeing some scritps and/or descriptions of how to do this when I recently setup MRTG to do more conventional interface monitoring. There are probably other ways to do this, as well, and with the above method your usage info won't go to syslog (unless you make a cron script or something to 'harvest' the accounting rule packet/byte counts every so often and log it with logger or similar), but you might find the techinque useful anyway... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Site Updates
> >If there are no objections, > >I think a modified version of my existing support page (make more > >LEAFcentric, remove all the "I's" referring to me, etc) would work well: > >http://lrp1.steinkuehler.net/Support.htm > > If you have time, would you do this Charles? Or, do we have a volunteer? I can probably get to this sometime this afternoon. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Site Updates
I just got a private e-mail regarding LRP, and in trying to include the leaf-user list web page in my response, I noticed: 1) We don't have a mailing list link in the 'main menu' part of the leaf site 2) If you go to support, you get a link to the mailing list & the troubleshooting howto, but the page looks pretty sparse. I suggest we move the mailing lists tag from the development section to the main menu section, and expand the support page. If there are no objections, I think a modified version of my existing support page (make more LEAFcentric, remove all the "I's" referring to me, etc) would work well: http://lrp1.steinkuehler.net/Support.htm Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Hard-Hat
> I've also downloaded the CD's, but it seems that something is wrong with > CD1... > > It should boot, but I get nothing. Hmm...I just tried booting mine and I get a lilo prompt... > Opening the same CD and extracting the bootflop.img which is under the > bootimg directory, and put it on a floppy, still does not boot. > > Any pointers? To get my CD to boot into HH-Linux, I had to tell it which device my CD-Rom was attatched to (default is hdc). Otherwise, it seemd to boot fine. I can try to send you the bootimage from my CD, but it isn't the boot image used by the BIOS to boot. I'm not sure how to extract the floppy image the BIOS uses when booting from the CD... I was just planning on installing HH on one of my RedHat systems lying around, which is what MontaVista claims is supported for Journeyman...any particular reason you need to get it to boot native? Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Hard-Hat
> this works for mounting cdrom images w/o the cdrom. > > mount -t iso9660 /home/cdimage.iso /mnt -o loop Using the -o loop option with mount is the much preferred way to mount ISO (or floppy, or other raw filesystem) images, as you don't have to manually create the loopback mount point, and remember to remove it when done. When you use the -o loop option, a simple umount will remove the loopback device as well as unmount the filesystem... Another benifit of an embedded distribution is you can install from a file mounted using loopback on the full linux distribution of your choice. Doing an install of something like Debian or RH generally requires actual access to the CD (or a much more complex network based install). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Hard-Hat
> At 05:21 PM 6/18/01 -0500, Charles Steinkuehler wrote: > >I just got a call from the Monta-Vista folks (makers of Hard-Hat). > > > >I wanted to get their reaction to our possible use of the HardHat platform > >as a cross-compile environment, and what sort of comittment they have to > >keeping a free version available. > ... > >I have the Journeyman CD's, but have yet to install and evaluate the > >development environment. I'll try to get to this in the next week or so, > >and report back. > > May I ask how you managed to get them? I've tried for months to get a set of > disks from them, and Marketing always tells me "Real Soon Now". Last time I > asked was at their Embedded Systems Conference booth back in April. I just > now tried to go to their download page and it crashed my (Netscape on > Windows) browser. Twice. I downloaded them from their website (using IE on windows): ftp://ftp.mvista.com/pub/Journeyman/ It looks like their FTP server spits out malformed response headers, in an attempt to be graphical & GUI. I couldn't get IE to reload the link above, but I could get to it with a command line FTP client... > Monta Vista's Embedded Linux doesn't look to me like the best around > (Lineo's Embedix looks better, based on comparing literature, not samples) > ... but it sure looks like the best low-cost version. If we could refer > people to a version that was readily available to people who do not have > their own CD burners, I agree that it would address a lot of the issues we > wrestle with. Hmm...I forget not everyone has a CD rom burner yet. Perhaps a qualifer for any disto should be the ability to mirror the CD and/or sell copies at minimal cost... Of course, it's pretty hard to buy a Debian Slink (or RH 5.x) CD in today's world, so most w/o a CD burner would be stuck (or have to ask for help) as well... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Hard-Hat
I just got a call from the Monta-Vista folks (makers of Hard-Hat). I wanted to get their reaction to our possible use of the HardHat platform as a cross-compile environment, and what sort of comittment they have to keeping a free version available. They were encouraged by our potential use of their "Journeyman" functionality, and claimed to be comitted to keeping this level of functionality available for free (which makes sense, as the compile environment is entirely based on open-source tools to begin with). The big benifit to using a pre-packaged environment like this will be the ease with which a cross-compile environment can be created, and the fact that someone with a direct interest (as well as time and money) will be maintaining and upgrading the tools in this environment. I'd be real interested in the RedHat embedded tools as well, if they provided some sort of free version. I have the Journeyman CD's, but have yet to install and evaluate the development environment. I'll try to get to this in the next week or so, and report back. For those unfamilar with the benifits of using an embedded development environment, we *should* be able to gain the following advantages over simply compiling native on a generic x86 linux box: 1) Independence from the host systems glibc version, making it easier to compile/contribute 2) The ability to compile to an alternative CPU architecture. While I doubt anyone is going to do this immediately, a large number of commercial products are based on LRP, and we could get a lot of mileage, (support, hardware, money, ???) out of just one or two successful internet appliance designs based on or derrived from LEAF, so the ability to target typical embedded CPU's (ARM, PPC, 68K, MIPS, others) might be handy. 3) The ability to compile against arbitrary C libraries. I can see a system with the core BusyBox and firewall utilities compiled against a small glibc replacement, with the full glibc available if you've got the room and the need to run it for some high-end application. 4) We get an easy way to answer the "how do I compile for LEAF" mailing list questions. This is only partly in jest...if we don't have a standard environment that can weather changes to glibc and other compile environment options, in a year or two we'll be right back where we are now, with no-one wanting to install an ancient Debian Slink (or is that RH7) install just to compile LEAF binaries ;-) Look for the "product review" soon... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Suggestion for improvement
> For me personally, my aim is not to build "black box appliances that need > no maintenance", but rather to build "network appliances that don't carry > Unix baggage unless if there's no alternatives". With my consumer hat on, > if I install an appliance to take care of a specific task for me, I don't > want to have to hassle with source configuration and all those other > wonderful Unix traits: I get an appliance because I want the job done > quickly with a device that is tuned for that specific purpose. > > Think about it, a 500MB IDE harddrive to install FreeBSD, OpenBSD, Debian > Linux or whatever else on costs close to nothing. If I wanted a Unix > machine to do that task, I'd go and build one and wouldn't bother with > things like LRP. As a 'consumer', I go for LRP because I specifically > _don't_ want a "flexible, can do anything" solution, but a "stick it in, > configure it, stop worrying" one. This may be the core difference between David's Oxygen and what I'm trying to do, and is at least one reason why I think both flavors can flourish (and likely even build off of each other). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Suggestion for improvement
> > Still, a point well taken. It probably would be wise to institute an > > advisory list for package updates and security issues. > > A very good idea - and very possibly, a good place for LEAF: to > coordinate package updates, system updates, etc. Ah-ha! An overlooked requiremnet of the new packaging system...check for updated pacakges & possibly install from online package repsoitories. > I see! One of the things I keep in the back of my mind is I want > Oxygen to work just like Real UNIX(tm) - which is a second reason why > vi is the default editor - but being a vi nut helps too :-) Hey! What's with this VI stuff...it's emacs all the way! ;-) Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Apparent Directions
> > Also, I'm generally interested in 'really thin' servers. The first will > > probably be a BIND server, which I'd also like to see install straight from > > the CD. > > > > Charles Steinkuehler > Hi Charles ! > What are the reasons which make you choose Bind over tinydns if you are > looking for a "really thin" server ? Tinydns is really compact (package size= > 23K plus 45K for dnscache) and very efficient and secure. > Jacques Tinydns is an excellent option, and very suited to the LRP/LEAF environment. However, there are a LOT of systems out there running Bind, and a lot of sysadmins that are familiar with setting up and administering Bind, yet worried about potential security problems...this is the target 'market' for a very thin Bind platform. It would also be quite possible to build exactly the same sort of system using Tinydns, and I would expect this to happen as well, but Tinydns doesn't benifit as much from the restricted environment, being more secure and less complex to start with. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Suggestion for improvement
> Everyone, > Are our home page and releases page easier to navigate now? > > Note: I still need to work on our releases page, but I think our home page > is alright. Looking better! I still think we need a page that tells folks about the different versions. The current FAQ page you link to is a start, but I think it should be an actual web page (ie part of the PHP website, not SF's FAQ-o-matic), for looks if nothing else. I also think the descriptions should be beefed up, and probably written by the folks driving the distribution...as long as we can stay away from descriptions like: "this disto is way better than that other one, which really sucks". ;-) Finally, with each 'main' distribution having several permutations, I think there should be links to something that helps users decide which particular image(s) they need to do what they want. I've got an older version of this for my images at: http://lrp.steinkuehler.net/DiskImages/Which14Me.htm for an idea of what I'm thinking of. I'll try to get an updated version of this online soon, so it can be linked from the main LEAF selection page (you can link this page as-is if you want...the URL will be the same). I think David's got something like this for Oxygen, as well. In general, expect my site and content to become more integrated with the SF Leaf site as time goes on, but it will take a while... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Suggestion for improvement
> Scott C. Best, 2001-06-13 23:25 -0700 > > Heyaz. So, I went to the LEAF site today trying to > >imagine myself as a new LRP user who's going there for the > >first time. > > And it strikes me...where's the distro? IMO, front¢er > >links to both ES2B and Oxygen be a would be a great help. Sure, > >there's a little "releases" in the upper left, which leads to > >a page that has no clickable links on it -- gotta click again in > >the left banner, though, to actually get to the page. > > Doing it that way, with the left-banner, makes me feel > >like I had to mine for something, and may have no gotten the > >good stuff. So, I guess I'm suggesting a "here's the good stuff" > >link, right there on the homepage. Thoughts? > > Scott, > I could remove the "Releases" menu item. Then make "EigerStein" and > "Oxygen" root menu choices. My preference is to add links to the releases > page. Let me know which way you think is easier for the new user. I don't know that we need to change the menu items, just make it easier for a new user to find our distributions. Maybe add another 'tagline'...something like What is it? Project Goals: Distributions: Choosing a distribution <- Link to a page describing each disto in summary EigerStein <- Direct link to Releases/EigerStein Oxygen <- Direct link to Releases/Oxygen PPPoE and PPPd <- Direct link to Releases/PPPoE and PPPd Affiliates This would make it easy for new visitors to actually find the 'goodies' Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Hopefully last thread on LRP and leaving
> >P.P.S. what steps have been taken to store and or mirror sourceforge > >locally should VA Linux go away? > > I backup our web site, and the content in the DocManager here: > http://leaf.sourceforge.net/pub/archives/ > > SourceForge also backs up all projects regularly. If someone wishes to make > a backup that is independent of the SourceForge site, let me know. Note: it > will require approximately 1-2G of storage. I should soon be in a position to mirror the SF site, although I may need some help setting up PHP and the database stuff. Assuming DSL.net keeps their word, I'll be getting an SDSL line with a /26 of static IP's. Initial bandwidth will be 416 KBits/s, but I plan to upgrade to 1.5 MBits/s in a few months. Since I'm currently in the middle of moving my office (and my residence as soon as I'm done with the office), it may be late July or August before I get a new server built that can handle this type of site, but I will eventually get one up and would be more than willing to host a full mirror of the SF site & content. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Apparent Directions
> This is where I see the two LRP derivatives heading, based on the > mails from developers, and in other cases, my own view. These are > LONG views. > > Eigerstein: > > * Ease of use improvements and focus: boot it and use it > * Leaner, smaller > * Further specialized as a router and firewall > * Built against uClibc or similar > > Oxygen: > > * Mini-distribution > * Bootable CDROM with live CDROM fs > * Variety of non-router images: bridge for example > > Or to put it quite succinctly, Eigerstein => smaller, Oxygen => bigger > :-) Sounds about right to me, as long as I still get the option to boot off of a CD! I do expect Eigerstein (or actually LEAF named derivations) to be smaller and more focused than Oxygen. In addition to loading LRP files from the CD (which I can do now), I'd like to see a CD that could do a customized install (to floppy, HDD, flash, etc) straight off the CD. Also, I'm generally interested in 'really thin' servers. The first will probably be a BIND server, which I'd also like to see install straight from the CD. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] New Development Platform?
> > Also, I'd prefer to make a system flexible enough to handle: > > > > Base utilities...choice of: > > "Standard" binary > > BusyBox > > asmutils > > shell-script (POSIXness or similar) > > omitted entirely > > > > Libraries...choice of: > > ulibc > > glibc (various versions) > > newlib > > others? > > ...dietlibc... > > What is the goal in doing all this? Isn't this wide latitude of > variation what is causing all the grief in the glibc versions? Trying > to compile something written for glibc 2.2 against glibc 2.0 can be > downright annoying... I guess I'm thinking of a base system that uses one of the small c libraries, with the option of adding something like glibc 2.2 if you've got the space and are running something that requires it (maybe bind, a web server, or something similar). I'd mainly like to see enough checking in the install/packaging scripts so users would at least be prompted to install missing packages (like the glibc 2.2 library) rather than just getting a non-functional system. > > The other thing I'd like to see is an enhanced packaging system > > of some sort, that can handle a variety of boot and storage media...from the > > current floppy boot into a ramdisk, to CD or HDD boot into a hybrid system > > with volitle (ram-disk), non-volitle (flash/HDD), and read-only > > (CD-ROM/boot-ROM). > > You lost me there. A package system has no concept of "boot" or > "media", only of files and compiles and makes and things like > /bin/sh... To me, the package system for something like LRP has very different requirements than those RPM and DEB were created to meet. Both RPM and DEB package systems assume they are working with a system that has lots of non-volitle storage space (ie a large HDD), and AFAIK have little or no provision for backing up the packages (or at least the modified config files) so you can re-build the system exactly the same on the next boot, once your volitle memory has gone away. If you know of tools that can backup modified files from an RPM or DEB install, please point me to them. > There are several packaging formats that are interesting: > > * RPM - unrpm (busybox) > * Deb - undeb (busybox) > > ...and something else to consider: > > * Portage - this is used by Gentoo, and basically brings a form of the > FreeBSD ports tree to Linux. The concept is this: you change into a > directory, perform a "build", then the system fetches the source file > and compiles it for your environment. This has the benefit of > compiling the code for *YOUR* environment rather than relying on a > central packaging authority which may or may not run the same things > that you do. I took a look at the Gentoo site, and I like what they're doing. Portage might be useful as a big chunk of the compile environment, if it's flexible enough (likely) and easy enough to setup/install. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] New Development Platform?
> This talk recently of other development platforms (Hard Hat and > BlueCat) made me think about this. > > The original was Debian, as that was what was used, and it supported > glibc 2.0 in Slink. It later became clear (to me anyway) that any > glibc-2.0 based Linux should do, such as Red Hat 5.2 or Linux Mandrake > 5.3. > > I've taken a look at some of these, and wonder what every one else > thinks: > > * Hard Hat - seems like its made for true embedded applications, and > the Professional version isn't GPL and isn't available for download. > Embedded to me means: using some CPU no one's ever heard of, and > putting the CPU and software into a device no one will ever see. > > * BlueCat - this is like Hard Hat in that it is for True Embedded > Development... why develop for an i586 when you've get Joe's CPU > xx87AA0-series 7 available? > > Maybe I just don't "get it" with this embedded stuff - I thought we > were developing for mass produced Intel-compatible processors but > anyway - more: The part to 'get' about using an off-the-shelf distribution aimed at embedded development is the tool chain. The typical embedded distribution installs on top of some other system...most support a wide variety of linux, and even Windows NT/2000 using the GNU compilers. The big advantage to using something already setup with a cross compiling development environment is we don't have to worry about (and fix) the many little things that break when trying to build an environment like this...someone else did that work for us. Also, I guess I lean towards the embedded side of things, as I've done a lot of work with embedded processors. In addition, I guess it seems (at least to me) more likely to see a LEAF derivation in a stand-alone black-box router or VPN gateway (ie embedded system) than to see a LEAF derivation that is trying to be a full-blown desktop workstation with a self-hosted development environment. Note that even if we can self-host a development system, we're STILL in a cross-compile environment, as the target install machine is typically NOT the machine you're compiling on, even though they may share the same CPU architecture. > * Gentoo - this seems like a VERY appealing environment. I will > probably see if I can install it sooner or later. The idea of not > having GNOME support in binaries when you don't use GNOME is appealing > - similar things could be said about NIS and about IP v6. > > * Peewee Linux - this also seems appealing, though it seems more > geared towards making that bootable floppy disk distro than what I > thought it was originally (a bootable mini CDROM distro). > > * Peanut - this is another distro that I will probably install or try > out at some time. It IS a small CDROM-based distro. > > Thoughts? I'm only somewhat familiar with Peewee linux and Peanut...I haven't heard of Gentoo at all. I'll take a look at these... The more I think about it, the more I'm tempted to think we'll probably wind up with our own complete distribution, like it or not. At a minimum, we'll probably need to re-package anything pre-made, unless we can get full support for creation & extraction of RPMs or DEBs small enough to fit on a floppy. Also, I'd prefer to make a system flexible enough to handle: Base utilities...choice of: "Standard" binary BusyBox asmutils shell-script (POSIXness or similar) omitted entirely Libraries...choice of: ulibc glibc (various versions) newlib others? With BusyBox and perhaps ulibc making up the 'standard' floppy firewall. A full-blown glibc could be added as a package if something required it. In summary, I'd like to see a compile environment flexible enough to handle various library versions, and setup to compile for a target different than the host. The other thing I'd like to see is an enhanced packaging system of some sort, that can handle a variety of boot and storage media...from the current floppy boot into a ramdisk, to CD or HDD boot into a hybrid system with volitle (ram-disk), non-volitle (flash/HDD), and read-only (CD-ROM/boot-ROM). > PS: Maybe Charles wants to put Dachstein into a robot? :-) How about > a wireless router in a robot, doing network routing during competition > (hee, hee, hee, hee) "Hey the network went down." "Yeah, I know > - Charles' robot just got axed by that turtle thing from Monona, > Wisc." :-) :-) I do have plans on integrating some aspect of LRP/LEAF into a combat robot, however I have yet to meet Lisa and her robot Tentamushi (sp?) in the arena...blame any current network outages on the 'Wedge-of-doom". ;-) Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Monta-Vista Hard-Hat Linux
> > NOTE: I'm still very open to suggestions on what to use as the base of the > > next generation of LRP like functionality. I'm mainly looking at starting > > with an existing distribution because 'out of the box' you get a working > > cross-compile environment (no more dedicated Debian Slink boxes just to > > compile an application or two), and much of the software will be > > pre-packaged. > > I suppose it depends on what you want to do. However, this sounds > like you want to switch distributions entirely; isn't this the same as > starting from scratch? I guess in my view of the world, if a general purpose distribution can be found that is *close* to what we're currently doing with LRP (and various derrivations), it can be used as a base for new work: ??? distribution (possibly HardHat) is to New LEAF Disto as Debian Slink is to LRP In my mind, this is not really starting from scratch. Starting from scratch would be gathering the source for absolutely everything and compiling our own distribution, which I don't think is necessary. > > While the pre-packaged stuff will likely be in RPM format, it > > should be possible to easily convert the RPM's to a tar.gz file or something > > else shell-scripts can deal with. > > Busybox already has support for undoing RPMs (unrpm); use that. If it can still fit on a floppy, this would be an excellent solution. Otherwise, there will need to be a fair amount of work to address some of the packaging limitations of LRP. As previously mentioned, I'd at least like to see support for pre/post-install/remove scripts. On the other hand, I'm not sure RPM's will work well in a floppy environment where we need to backup the packages in order to save changes...this will take some investigating. > > A lot of the hard work (that requires > > maintainence and debugging) goes into making sure the packages all work well > > together...we should be able to leverage this work from a mainstream > > distribution and speed our "time to solution". I really don't want to try > > to create or maintain a complete, from the ground up distribution...it seems > > like too much duplication of existing work. > > This sounds like you are looking to go to "the next step" and leave > floppy distributions and LRP far behind. There are quite a few > CDROM-based routers out there. Peanut perhaps... > > I'd like to stay with the current base for several reasons: > > * Existing package support > * Knowledge base is built up already; otherwise Charles & Mike S. & > Mike N. & Jacques & Jeff & Ray & Rick & Ewald & Pi et al would > have to learn a new distro. > * Floppy-based operations is still important - to me, the floppy > should still be the base, and in fact should be a drop-in install for > a bootable CDROM floppy image. The biggest problem with the current base is the libraries, and (to at least some extent) 2.4 kernel support. I'm not looking to abandon the floppy distribution...otherwise there's not really any work to be done, as there are many micro-distributions of linux setup to run in tens or hundreds of meg instead of the gigabytes consumed by RedHat and similar disto's. I guess when I think of the 'perfect' next step, it involves: Latest libraries, and 2.4 kernel support Support for several 'standard' firewall scripts (ie shore-wall, rcf, etc.) Slightly extended package system with support for: pre/post-install/remove scripts dependancies "partial" backups (ie backup only config or user modified data) Since I don't want to compile all this from scratch (actually, the compiling I don't mind, it's the maintaining when things change that gets nasty), I'd like to see a way to convert packages from a mainstream distribution directly into pakages for . Kind of like if LRP packages were built as modifications to .debs, so when the new debian package came out, you could just 'import' or 'update' or whatever, and run the new stuff... > However, a shift towards RPMs would be nice. I'll try to look into what is possible using BB's RPM support...perhaps it will do all I'd like to see... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Monta-Vista Hard-Hat Linux
> > NOTE: I'm still very open to suggestions on what to use as the base of the > > next generation of LRP like functionality. I'm mainly looking at starting > > with an existing distribution because 'out of the box' you get a working > > cross-compile environment (no more dedicated Debian Slink boxes just to > > compile an application or two), and much of the software will be > > pre-packaged. > > I was recently contacted by the makers of BlueCat Linux (and its > RTOS sister LynxOS) at www.lynuxworks.com, who are actively looking for > partners for their distro. I cannot comment on the strengths of their > product, but if you'd like a name&email of the partners manager, that I > can provide. Please do. I've actually got a copy of BlueCat, which came with my ELJ contest kit. So far, I've been less than successful at getting it to boot (believe it or not, their network bootstrap loader won't work across a router), and there tech support has apparently been following the Dispair Inc. Apathy motto: If we ignore our customers, maybe they'll go away, but this could be related to the fact that I have a 'freebie' version... On the plus side, their distribution installed a cross-compile develompent environment on my RH 6.2 box successfully, and they look to have a fairly large list of pre-built packages. The boot problems are also at least partially due to the embedded PC card I've been trying to get BlueCat working with... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Monta-Vista Hard-Hat Linux
In light of my recent decision to abandon waiting for Butterfly, I am taking a long, hard look at working with Monta-Vista's Hard-Hat linux. I think this would make an excellent base distribution for the next generation of internet appliance releases. Of course, the proof is in the pudding (or so they say), so I'm downloading their (free) Journeyman release to play with. I've also e-mailed the HardHat linux folks, to see if they have any interest in a project like LEAF using their distribution. While I don't think we currently need sponsership from Monta-Vista, an alliance (or similar) might be nice. It would at least be good to know things like if they plan on keeping a free development platform available, be informed of major upcoming changes to the distribution ahead of time, and similar. Another benefit of using something like HardHat is multi-processor support. This will mean absolutely nothing to 99.999% of our users, but several folks are embedding LRP into 'black boxes' which may or may not run an Intel architecture CPU. I personally would LOVE to play with something like HardHat on the new IBM NPe405 CPU with 4 built-in 10/100 ethernet ports and multiple T1/E1 support. That would make a pretty cool LEAF platform... NOTE: I'm still very open to suggestions on what to use as the base of the next generation of LRP like functionality. I'm mainly looking at starting with an existing distribution because 'out of the box' you get a working cross-compile environment (no more dedicated Debian Slink boxes just to compile an application or two), and much of the software will be pre-packaged. While the pre-packaged stuff will likely be in RPM format, it should be possible to easily convert the RPM's to a tar.gz file or something else shell-scripts can deal with. A lot of the hard work (that requires maintainence and debugging) goes into making sure the packages all work well together...we should be able to leverage this work from a mainstream distribution and speed our "time to solution". I really don't want to try to create or maintain a complete, from the ground up distribution...it seems like too much duplication of existing work. Thoughts/commments welcome, as always Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: OT Re: [Leaf-devel] linuxrouter.org
> >I agree with Scott's wording. I recognized my mistake as soon as I read his > >message. I think we should give Morgan a chance to write a draft. He may > >come up with something we can all agree on. > ... > > We need to be careful here. Silence does not equal assent, and many of the > important participants in LEAF have been most notable for their silence on > this thread. Some of them may not share the sentiments of those of us who > have spoken up, but hesitate to start a confrontation here on this list. > Understandably. Others may share the general sentiment but feel that it is > not a proper topic of discussion here. Again, understandably. In other > contexts, I've been in both of these positions, and they are uncomfortable ones. Sorry to stir up this thread and disappear... Shortly after posting the suggestion to take a look at linuxrouter.org (which I can't actually take credit for...Michael Smith sent an e-mail to the webmaster account of my LRP site suggesting I take a look at linuxrouter.org or I never would have noticed), I went off bicycling. Two flat tires, and about 4 1/2 hours later on an extremely humid day, I got home, showered, and crashed, not getting a chance to read this thread until this morning. > Personally, I'm not too worried about trying to do something "effective". I > think Dave's efforts are trivial in any real political sense. Agreed. As for my response to Dave's day of mourning, for me there is now no question about the future direction of my efforts with LEAF. While I was working towards making some disk images with LRP 2.9.8, and would have been willing to consider using Butterfly as a base distribution if/when it ever saw the light of day, these plans are now scrapped. I am un-subscribing myself from the lists at linuxrouter.org, and will direct users of my disk images to use the LEAF site/lists, which I will remain subscribed to. Future development will be based either on custom work or perhaps a small distribution, like HardHat. In the short term, I'd like to see Dachstein actually get released, and I'll try to implement linuxrc script changes that enable us to boot LRP like systems using the standard kernel (I've never been too fond of Dave's initrd-archive patches anyway). Also, while I'll consider signing a letter to Dave C. from the LEAF group, I'm not sure this is appropriate or necessary. While I disagree with the statements posted on the linuxrouter.org site yesterday, I think the biggest transgression Dave made was combining his political views with the linuxrouter project. If the linuxrouter site had a history of being the "American terrorist firewall site: Keep the FBI out of your secret files", his site content yesterday would have been appropriate. Instead, it seems like he is attempting to force his views onto a user-base that has little or no advanced warning of what they're getting into. If we see enough questions from the user-base, we may need a FAQ or article stating something about how the LEAF group is not politically oriented, we just make firewalls and other useful things out of small linux systems, and intend for them to be used by anyone regardless of political or moral views. (At least, I hope this is what we're doing). Charles Steinkuehler [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] linuxrouter.org
For those of you who haven't been to www.linuxrouter.org lately, you might want to head over there today. Apparently the planned network outage today is not for routine maintence. Instead, the network seems to be 'in mourning'. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Problems with Dachstein backup scripts
I've been working with updating the Dachstein pre-release images, and ran into a problem with the backup scripts when making a new root package. I don't have time to crawl through the new scripts right now, but perhaps the symptoms will be easily recognized by someone more familiar with the new BB tar backup... I start with the following new /boot directory, which contains it's own etc and lib/modules directory and gets backed up as part of root. I have modified linuxrc to load modules from /boot prior to looking for LRP files, so you can use loadable kernel modules to boot of things like IDE or SCSI drives w/o requiring a kernel re-compile. Anyway, the directory structure is as follows (trailing / indicates a directory): /boot/ /boot/etc/ /boot/etc/modules /boot/lib/ /boot/lib/modules/ /boot/lib/modules/readme All well and good, but when I back up root, the boot directory winds up looking like this: /boot/ /boot/lib/ Everything in the /boot/etc directory is gone, as is the /boot/lib/modules directory. This seems a bit suspect, especially since the etc directory and lib/modules directory should be part of the exclude list (but at the root level...they shouldn't affect sub-directories). Any ideas for a quick fix, or do I need to crawl through the backup script and BB tar file handling code? I guess there's always ctar as a fallback, but I think we can get BB tar working... BTW: I noticed the -z switch seems to be working with BB tar, so you can: tar -xzvf .lrp Which is quite handy... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Site Update
> Last but not least, our phpWS has received 64732 visitors since 2001-03-19. What sort of a statistic is this? Is this unique IP's, individual webhits, or something in-between? Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ES3 suggestion
> 1. First, when it refreshes, I'm not sure that > it flushes the rules *and* the portfw's/autofw's. > I could be wrong here, but I think it only flushes > the ipchains rules and doesn't touch what was > previously setup with ipmasqadm. I'll check this. > 2. Given the increased popularity of ISPs giving out > RFC-1918 private addresses with DHCP and then static > NAT'ing them, I think part of the firewall setup which > blocks the RFC-1918 address specifically should be > dropped. While I still think the private IP's should be blocked by default, there should be an easy way to disable a particular range, and documentation on the fact that this might be required. I'll add a way to do this in the new firewall scripts. > 3. Many of the trojan's I've read about use blind-attacks > where a response from the target isn't needed. So the > attacker can spoof the return IP address, and they > often choose from the reserve-address range (and use > the "eleet" port of 31337). Anyhow. as per CIAC alert > K-032, I think the following reserved address traffic > should be blocked explicitly: > > $IPCHAINS -A input -i $IF_EXT -b -s 0.0.0.0/8 -j DENY > $IPCHAINS -A input -i $IF_EXT -b -s 224.0.0.0/4 -j DENY > $IPCHAINS -A input -i $IF_EXT -b -s 240.0.0.0/5 -j DENY The above IP's are already blocked... > $IPCHAINS -A input -i $IF_EXT -b -s 169.254.0.0/16 -j DENY > $IPCHAINS -A input -i $IF_EXT -b -s 192.0.2.0/24 -j DENY > $IPCHAINS -A input -i $IF_EXT -b -s 248.0.0.0/5 -j DENY I'll check into blocking these IP's as well... > 4. Lastly, at the end of the setup script, some "noise > blocker" rules should be stuck in. This helps eliminate > log file buildup (and the risk of resulting tooth > decay...). Since they're at the very end, they not > interfering with normal op's that would have been setup > earlier. > > $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 137 -p tcp -j DENY > $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 137 -p udp -j DENY > $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 138 -p tcp -j DENY > $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 138 -p udp -j DENY > $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 67 -p udp -j DENY The above are already blocked w/o logging (along with a few more netbios ports: 135 & 139)... > $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 68 -p udp -j DENY > $IPCHAINS -A input -i $IF_EXT -d 255.255.255.255 -j DENY Again, I'll look into blocking these IP's as well... > That's it. Please let me know what you think. Of > course, I'd be willing to do the dirty work of editing the > scripts and tar'ing them up for the inclusion in the new > release. Just wanted to be sure the above has enough perceived > value. I need to fold my extended V1.0 & V1.1 functionality together with my latest proxy-arp DMZ scripts, so I can make the mods, but pointers to any RFC's or other docs that refer to the new subnet ranges you think should be blocked would be helpful... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Ewald's Updated ES2B
> >- 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? Either name would be fine... > >- 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) I like the idea of just a link to leaf.sourceforge.net on the syslinux splash screen, with other links in the readme. > >- 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 :-) I usually do this with the self-extracting disk images just before I release them...I can do a pretty good job of 'playing dumb'. > >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'll try to dig these mods up... > >- 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? I missed loading kernel modules from linuxrc. I think this should be on the to-do list, as it won't add much (if any) to the size of root.lrp, and will make life easier for the handful of folks wanting to run off HDD, zip, or other non-floppy media. > >- 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. The scripts will be a clean extension of the existing Eiger firewall scripts, so any existing Eiger based network.conf would work properly. The extensions will allow alternate forms of DMZ support (port-forwarded, static-NAT, or proxy-arp based) in addition to the standard routed DMZ supported by the Eiger scripts currently. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Ewald's Updated ES2B
> > - Use the ramlog package instead of the log package...this puts the logs on > > a seperate ramdisk, avoiding the full ramdisk issues, which are the most > > likely thing to kill a working LRP system. > > Sorry, if I missed something, but can someone explain the advantage of > having extra packages for everything?? > > In the case of the ramdisk.lrp I started with Charles package, and it was > helpful to understand what's needed to have a second ramdisk for log files. > > Then I realized that most the package could be replaced by busybox commands, > at the end ramdisk.lrp has been obsolete - and again a few bytes saved. > So I ended up with multiple ramdisk support as an integrated function of > root.lrp. Is this worse than having an extra package? > > Not to mention the sideeffect, that I don't have to waste Charles time for > help and maintenance of the ramdisk.lrp - it's instead part of the active > busybox development. The ramdisk package was created because previous LRP systems were missing the minix format utility, and some init scripts are needed to acutally build the ramdisk. I have no problem with folding this functionality into root.lrp if the required functions are now in busybox (or can be added). The init scripts are very small, and can be backed up as part of root without causing any problems. The biggest benifit to using my ramlog.lrp package is the fact that it's already done...just replace log.lrp with ramlog.lrp, and that's it. Note that there is a bit of a chicken & egg problem with putting log files on the new ramdisk. The /var/log directory needs to be populated with some files for everything to work properly, and given the limitations of the LRP packaging format, the ramdisk init scripts need to create these files. This is currently handled by saving a log.tgz file as part of ramlog.lrp, but there may be a better way to do this. I'll take look at various ways to implement the extra ramdisk functionality cleanly... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Ewald's Updated ES2B
I've downloaded the 20010527 version of the updated ES2B image (I'm playing with the 1680K version). After a very brief examination (only about 30 minutes), I created the following list of things that still need to happen. This is probalby not everything, but I won't have time to really pound on things until later. Note several items are minor things that simply need to be addresses to make a clean distribution. - The distribution needs a name...again, I'd prefer Ewald to name it, since he's been doing all the work - The syslinux splash screen should be changed. It should probably refer to the leaf sourceforge project. We may also want to pull the links to linuxrouter.org, but I'm not sure about this... - The readme file needs to be updated with (at minimum) new links and new instructions for e3 rather than ae as the editor - The readme instructions need to be verified (ie put on LUser hat & walk through the readme like a newbie, making sure nothing unexpected happens). And on to 'real' changes required/desired: - I'd like to see the java bandwidth applet added to the weblet package - I'd like dnscache to be run by the daemontools package, if it doesn't require too much disk space...this should help keep things standardized, and make tinydns package maintainence easier - Use the ramlog package instead of the log package...this puts the logs on a seperate ramdisk, avoiding the full ramdisk issues, which are the most likely thing to kill a working LRP system. - Remove old dhcpd and dhclient leases...that these are around is my fault, as they are getting backed up with root. I need to add an exclude.list file to each package. - Modify the dhclient.conf file to properly generate an /etc/resolv.conf that uses the local dnscache - Update the network scripts...I need to fold my proxy-arp and Extended scripts V1.1 together and create what will likely be the last of the 'mountain' firewall script derivations. I'd like to see future images use seawall, rcf, or similar. I will take care of updating dhcpd.lrp & dhclient.lrp, and the network script mods, but probably not until Tuesday. The rest of the work is up for grabs by anyone who wants to tackle it... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] dnscache & dhclient - Oops ...
Just one extra question: there must be some dhclient option to avoid filling the resolv.conf file with the ISP DNS adresses: if one is running dnscache on his LRP box there is really no need to have ISP DNS ase secondary & tertiary DNS. You will always get a more up to date & secure information going through dnscache and there no reason for this program to fail unless some really serious problems going on (connection pb with your ISP, hardware pb) in which cases the ISP DNS's would be useless. CS> Yes, you can use 'supersede' instead of 'prepend', and dhclient will ignore anything sent from the ISP. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Pb with dhclient & Eigerstein BETA2_test_20010527
> Symptom: > When I boot the new package I get after: > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 > receive_packet failed on eth0: Network is down > > Then if I issue after login in > /etc/init.d/dhclient restart > it works ok > > I replaced the dhclient package with the one on Charle's site version > 2.0pl5 (not the one on Eigerstein Beta2 which is I think an earlier > version). I was able to login without any problem. Therefore the problem > is with the dhclient.lrp in the Beta2_test package. Yes, we need to verify the dhclient package is 2.0pl5. An older version is on the existing EigerStein disks. > Another problem is the dhclient-script file which must be hacked when > dhclient is running with dnscache. See FAQ section at > http://leaf.sourceforge.net/devel/jnilo/dnscache.html Hmm...kind of a sticky problem. Since I now know more about how dhclinet works, what about the following: 1) Return the dhclient scripts to their original form (ie knowing nothing about dnscache) 2) Add a prepend statement to dhclient.conf: prepend domain-name-servers 127.0.0.1; This *should* use the local dnscache to resolve names, falling back to the DNS server(s) provided by the ISP if local resolution fails, and keeps everything standard but the dhclient configuration file, which is where such things are supposed to be set. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Back online
Well, I'm back from my escapades fighting robots in California. A sincere appology goes out for missing the LEAF meeting in San Francisco Wedensday night. As Mike reported, I didn't get in until really early Thursday morning. Currently, it looks like the highest priority is verifying Ewald's latest pre-release version of the updated EigerStein. I should be able to spend some time on this in the next few days. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Eigerstein?BETA pre-release
> My $.02 on the subject is calling it EigerStein 2 Release, but > that's just me. ES2B has been around long enough that actually changing > the name to ES3 would help avoid confusion, and there's enough of an > update to warrant it. I agree. The new image should either be called something other than EigerStein2. EigerStein3 is OK, but I think enough material has changed to justify picking a new mountain for the release name. Ewald did the work, so he gets to pick the name. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Going walk-about
> If you meant Ewald, it's here: > > http://leaf.sourceforge.net/devel/ewaldw/Eigerstein2BETA/20010520/ > > Ewald Wasscher Sincere appologies. Somehow with my current lack of sleep, your name stuck in my head as Eric...I'm not sure how. I've now made the leap from being bad with names in the real world, to being bad with names in e-mail. :-/ Charles Steinkuehler [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Going walk-about
While I'm frantically working on finishing my new robot for BattleBots, and in preperation for my trip to California, I've disabled mail delivery from the LRP list (due to the high traffic). This is a tempory measure so I won't have thousands of e-mails to sift through when I get home...I'll re-subscribe when I'm back on-line. I'll still be getting mail from the LEAF lists, but it may be a week or two before I filter through old e-mail and reply to anyone, although I'll try to respond to anything urgent as soon as possible. Also, Eric's got a substantial update to EigerStein nearly complete. Saddly, I won't be able to do any testing with this until I get home, but perhaps some of you will want to play with the pre-release version Eric's currently got online. I'm looking forward to meeting those of you who will be at the meeting in San Francisco... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Website Problem
> Kenneth Hadley, 2001-05-15 07:27 -0700 > >opps, sorry, didn't even noticeshows you how well you read something > >after you've done it so many times ;-) > > Kenneth, > How are you modifying this document without a phpWS admin account? > > Charles, > I think for now I'll link to your text version instead of integrating it > into our phpWS. If there are no objections I'll make the change this afternoon. > > When the next version is released and we can verify this problem is solved > and integrate the document again. Sounds good to me... Of course if I'd ever gotten around to migrating my HOWTO's into docbook, this whole point would be moot, as we could just output an html or pdf version... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Website Problem
http://leaf.sourceforge.net/content.php?menu=110300&page_id=15 Kenneth Hadley just posted a link to my Hard-Disk HOWTO on the Leaf SF site. There is a problem, however, with the document when downloaded from this link. Apparently, the text is being interpreted as HTML, which is generally benign, but re-direction symbols (especially <) confuse things and cause large chunks of text to disappear (ie get interpreted as HTML tags). I think we need to run raw text through some sort of conversion before being included as part of an HTML page...is this possible to do with our fancy PHP site code? Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] seg faults in Eigersteinbeta solved- hopefully
> > >>strip --strip-unneeded -R.note -R.comment > > > > "strip -R" is equivalent to "strip --remove-section", so some extra > > information is removed from the binary. I have to admit that I don't > > really know what information these sections contain. > > Me neither, but there are visible results: > > wolfstar@ulrik:~ > ls -la libc.so.6* > -rwxr-xr-x1 wolfstar users 1382179 May 11 21:25 libc.so.6 > -rwxr-xr-x1 wolfstar users 1167916 May 11 21:27 libc.so.6-plain > -rwxr-xr-x1 wolfstar users 1108748 May 11 21:27 libc.so.6-extra > > That's the glibc that comes with SuSE 7.1 - I think glibc 2.2, but I'm not > sure off the top of my head. (Probably is, 2.1 was 4 megs unstripped.) > libc.so.6-plain was libc.so.6 just stripped as normal, while -extra was > done with the funky stuff above. 60k is appreciable. Compressed: > > -rwxr-xr-x1 wolfstar users 523935 May 11 21:25 libc.so.6.gz > -rwxr-xr-x1 wolfstar users 451864 May 11 21:27 libc.so.6-plain.gz > -rwxr-xr-x1 wolfstar users 451418 May 11 21:27 libc.so.6-extra.gz > > 450 bytes ain't much, but it's SOMETHING. (All compressed with gzip -9.) > > Worth investigating IMO. I don't know about the glibc libraries, but I'm pretty familiar with code sections (thanks to my background with embedded systems, where you have to deal with a lot of detail handled automatically in more complex environments). When writing code, you can tell the compiler/linker which "section" various pieces of code/data belong in, so the linker knows where to put everything. There are typically a number of pre-defined sections for things like executable code, constants, initialized variables, uninitialized variables, etc... On an embedded system, you tell the linker where to put each section, so your constants and code might go into ROM, while the variables get put into SRAM or DRAM...section information is stored in the executable files and the dynamic loader relocates sections 'on the fly' for complex systems like linux, as well as things like loading any other required libraries, initializing RAM, and other low-level details most folks never worry about. There are several code sections defined by convention on virtually all systems (even things like lowly single-chip micros deal with code sections so you put data in the right place...it's kind of imporant that your bootstrap code actually goes into [EP]ROM, and variables wind up in RAM somewhere), but you can also define your own code sections at will. Unless the linker (or some other tool) knows what to do with the new code sections, however, they won't be very useful. Without going through the glibc source code, and the dynamic loader/relocater (the tool that reads an elf file from your disk, puts it somewhere in memory, and gets everything ready to run), I can't say for sure, but if the names are at all descriptive, the .note and .comment sections don't exactly sound like critical information required to run the libraries. They are likely additional information that might be useful if you're running some sort of advanced debugger, but sound quite unnecessary for our typical floppy-disk based systems. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] BALDG meeting (was: SVLDG meeting)
> How to get to Treasure Island: > http://www.ci.sf.ca.us/treasureisland/public_info.htm An alternate location would be somewhere in downtown San Francisco, if the transportation to Treasure Island is poor (also, Treasure Island will be swarming with BattleBots builders and spectators...this could be good or bad, depending on your perspective :->). The hotel I'm staying at is the Holiday Inn Civic Center, which is downtown, right off I-80. Also, I'll have transportation, so I could get anywhere reasonably close to downtown (I'll defer to you locals on this...everything looks pretty close to someone from Kansas, but I'm used to cruising at 80 on the highways and little or no traffic...I hear it can take hours to go a few miles out there on the coasts!). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] SVLDG meeting (was: SVLUG meeting and Midori presentation)
> >I hoped would see & talk with you Mike. > > Larry, > Sorry I didn't make it. It might be a good idea to gather together on a > weekend sometime. We could call it a Silicon Valley LEAF Developers Group > (SVLDG) meeting. We need a place that is accessible by public > transportation to accommodate Ray and me. Any suggestions? Treasure Island sometime between May 22 & 28. It might be a bit crowded, however, as that's when/where BattleBots is being held. :-) Seriously, I'll be in the bay area then, and would love to meet up with anyone local to the area, if possible. I won't know my schedule until I actually get out there (brackets don't get posted until the day you actually fight), but I can probably break free for an afternoon/evening sometime. Also, I'm having a terrible time getting folks to commit to helping me out as part of my pit crew. If any of you in the Bay area are interested in hanging out at an amazingly cool demonstration of technology for a week, contact me off-list, and I can probably get you signed up on my pit-crew (you just need to sign & fax a waiver & get a passport photo to the BattleBots folks for a badge). Saddly, if you're not listed as a team member, I may not be able to get you a tour of the pit area if you just drop by...each event has been progressively more sticky about letting folks roam through the pits (insurance & everything), and with 650+ robots, it's going to be a zoo. I really need 2-3 reliable helpers, and I've currently got 0-1. Charles Steinkuehler [EMAIL PROTECTED] ___ 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....
> 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 David! Best wishes for your newest addition and the rest of your family. Charles Steinkuehler [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Vulnerabilities dot org
> Charles Steinkuehler, 2001-04-27 11:36 -0500 > >Either run disk quotas, or put /var/log on a seperate partition, so it > >doesn't run the whole filesystem out of space. Neither solution is > >perfect, but making a /var/log partition is already implemented (see my > >ramdisk.lrp), and wouldn't even require any extra room on the boot > >device, if we pull the mkminixfs functionality out of the kernel and put > >it in busybox (see earlier e-mails on booting LRP with a standard kernel). > > Charles, > Is this the design you want to implement in "Quercus"? Yes. I think the ability to use standard kernels is a big benifit, we get other benifits by moving the code to create & format ramdisks out of the kernel and into user space (not the least of which is more flexability). As soon as I get my head out of robotland, I plan to make some scripts that boot this way, to be followed by attempts to see how small I can get a system that can bootstrap a root filesystem to a new ramdisk. If it can be made small enough (minimal busybox linked with uClibc & a sub-set of the ash shell), the contents of the bootstrap initial-ramdisk can be entirely replaced by stuff loaded from standard tar.gz files, giving us the greatest flexability. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Vulnerabilities dot org
> > > >running, as "echo test > file" won't work if the disk is > > > >full. So...be cautious turning Nessus loose on your own > > > >LRP box. :) > > > > > > I think this is a problem. I believe the ramdisk shouldn't fill up > > > under any circumstances. Can we change log rotate to trigger on file > > > size in addition to periodically? > > > >It's got the ability in multicron, but commented out by default. I > >haven't formally tested it, but it seemed to worked on my old low-memory > >router. Still, a check every few minutes to start action seems like a > >kludgy way to handle it. > > Jack, > Is there an elegant solution to the problem? Either run disk quotas, or put /var/log on a seperate partition, so it doesn't run the whole filesystem out of space. Neither solution is perfect, but making a /var/log partition is already implemented (see my ramdisk.lrp), and wouldn't even require any extra room on the boot device, if we pull the mkminixfs functionality out of the kernel and put it in busybox (see earlier e-mails on booting LRP with a standard kernel). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Vulnerabilities dot org
> Makes me wonder though. At the start of the scan, > /var/log/syslog, messages and kern.log were 15k, 13k, and > 13k respectively. After the scan...all *three* of them were > over 980k before I ran out of disk space. > Sure, a brute-force DOS attack but...what am I doing > wrong where each packet log gets recorded in 3 places? This is just how it's setup. I've wondered about modifying this, but it was yet another issue that came down on the side of compatability (ie don't change if it's not necessary). I did actually think about it, though, and you can edit your /etc/syslog.conf file to change this behavior if you want, potentially even creating a log just for firewall stuff... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] EigerStein updates
> Charles Steinkuehler, 2001-04-25 12:45 -0500 > >I'm currently banging on the ELJ eval kit, trying to get it to do > >something useful...I'll report on BlueCat linux when I get a bit farther > >along. They do something like we were talking about for development. > >They build an entire directory structure (in this case with their own > >compiler, kernel source, and even RPM database). You cd into this > >directory, run a setup script, and PRESTO! you're all set to > >cross-compile. > > Charles, > I talked to LynuxWorks at the Embedded Systems Conference. The rep. said > they didn't support floppies as a target, or generic images. This means > that we would have to create an image for every hardware combination. Was > the rep. wrong? So far, the Blue-Cat stuff has a very embedded feel to it. No standard linux utilities required/provided at runtime (you have to custom build a disk image if you want things like a shell or the 'ls' command, etc). It even comes with it's own boot loader (like syslinux, except it does tftp/nfs over the network). It's mainly geared towards booting & running a custom program. We could probalby use it as a base, but using something like HardHat, which is actually packaging standard linux apps, would probably save a lot of work. While a lot of this becomes moot if we have our own packaging format, it's still nice to have a base distribution that provides major functional packages (like networking, apache, sendmail, etc), so folks have a reference for how to setup init-scripts, where to put config files, etc. More and more of this is becoming 'standard', but we're not to the point of universal compatibility between distributions, and likely never will be. > MontaVista said they do support floppies as a target, and generic images. > Ray and I should have the new HardHat Linux 2.0 CD shortly. From what the > rep. said it should be available for download too. On the down side, it > looks like they are only making a subset of packages available for free. :( > http://www.mvista.com/products/hhl.html This doesn't seem so bad. Folks can download and create their own free development environment, and I doubt any of the extra platforms supported in the $$$ edition would be required by anyone but a commercial developer, at which point paying for a full-blown development environment is an appropriate course of action. If we needed some of the professional stuff (I think we'd mainly be interested in the additional packages), we could probably get the HH guys to donate a few development systems. In general, I have yet to see anything more suited to being a development platform for us than HardHat. It targets embedded systems, and therefore supports cross-compiling and multiple CPU architetures out of the box. The embedded debian thing showed promise, but seems to be kind of dead at the moment (I get an "anyone out there" e-mail from the embeddian list every month or two). The embedded Red-Hat also looks kind of neat, but I think the RH folks are trying to force folks to pay for the whole development package...at least the HH guys have a free version (and really, how many folks in our user base are going to be using the GUI based remote GDB functionality anyway, which seems to be the main difference between the free and $$$ versions). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] EigerStein updates
For those working on updating EigerStein, there are a couple of things I recently remembered that should not be overlooked: Migrate the POSIXness script (/bin/grep) to the multi-file version I created for LRP 2.9.8 (easier to edit/maintain, and it runs faster) Grab the updated vi and new pico config files for the ae editor. Even if we switch to e3, these config files should be part of the ae.lrp package. I'm currently banging on the ELJ eval kit, trying to get it to do something useful...I'll report on BlueCat linux when I get a bit farther along. They do something like we were talking about for development. They build an entire directory structure (in this case with their own compiler, kernel source, and even RPM database). You cd into this directory, run a setup script, and PRESTO! you're all set to cross-compile. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
