RE: [Leaf-devel] weblet the like
Nothing nailed down so-far...the whole enchalida is up for grabs! I'd especially like to see a clean, extensible, understandable method for setting up complex networking configurations static routes, since we're Something like a meta-defninition that goes in the package (currently /var/lib/lrp/packagename.*) that defines what how to configure the package? That way someone could write a screen-based configuration manager (like Oxygen's acfg), or the web-gui, or a microwindows/nano-x configuration manager, or whatever, and they all talk to the common backend definition? Or am I going too far? ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] weblet the like
Lynn wrote regarding the Mosquito distribution: I have been busy looking at some CGI options myself lately. :) soapboxPersonally, I think there's something fundamentally wrong with managing a firewall/router through a web-based interface, but it seems that I'm the only one who feels this way.../soapbox I've been working on and off on integrating lua into a web server to provide an inline embedded scripting language, similar to PHP. For example: TITLEConfiguration page for ? readfrom(|/bin/hostname) x=read(*a) hostname=strsub(x,0,(strlen(x)-1)) x=nil write (hostname) ?/TITLE ... H1Configuration page for ? write(hostname) ?/H1 The above generates a web page that knows the local hostname... you get the idea (I hope.) I got micro_httpd working, but it only supports GET requests, so I switched to working with mini_httpd. GET requests work, but I'm still working on the correct approach for POSTS... Advantages I see to this approach are: Let the web server handle the access control, logging, etc. (better security) web pages should be more portable across the LEAF distributions mini_httpd can be built with SSL support, if desired inline-scripting is cool Disadvantages mainly involve size: The statically-linked lua library adds 50-70K to the web server code; lua-enabled mini_httpd is just under 100K in size. (UPX gets it to less than half of that, though). Does anyone out there see a need/use for this kind of thing? Or do you think the standard CGI scripting is fine? (I do realize you can fit alot of weblet pages in 100K) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Question on Oxygen 1.8.0 boot CD
Dave, I've noticed that the cdrom.cfg, smallnet.cfg, etc. configuration files on the bootable cd are not in the root directory of the cdboot.ima image on the CD. Instead, they are inside the root.lrp, in /var/boot/config. This is different from the standard floppy boot images, where the .cfg files are on the root of the boot floppy. Is there some specific reason that it has to be this way? Is it possible to create .cfg in the root of cdboot.ima and have them read? Thanks in advance. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] Oxygen Updates
You're seeing this error because the default configuration is linux - which is for a floppy-based boot. The most recent CDROM should use cdrom as the default config. Ah. Thanks. The default screen is the linux config screen. F1 will make the cdrom/largenet/firewall/etc. options appear, and F10 will make the Linux option the current screen again. When using CDROM, it still tries to mount /dev/fd0u1680, fails, and goes on. Not a big problem, but you will see the read failure messages on the console and in the syslog. I'm very pleased with the way things are shaping up with the Oxygen CDROMs. The main problems with the current image are: This is looking very nice, Dave. You should be proud. Thanks! Regarding the largenet SegFault, this is probably a stupid question, but could it have anything to do with trying to load 105 packages all at once? Has anyone else loaded that many before? ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] Oxygen Updates
Luis.F.Correia wrote: When booting from a CD, the only floppy formats supported are 1.44 and 2.88. Check which format Oxygen-CD is using and correct your config file. Luis, Thanks. Just as a clarification, the CD-image I'm using is (currently dated Dec 17) and at: http:leaf.sourceforge.net/pub/oxygen/development/oxygen.iso I think anyone who simply downloads that image and burns a CD from the iso will have the same problems I did. But your suggestion is helpful in looking for what to modify before burning another CD. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] Oxygen Updates
David, others, is there a reason for using syslinux instead of isolinux? I'd say it's easier to use isolinux and forget about floppy images on the CD. FWIW, ISOLinux worked great on the initial load, but there were some problems with LINUXRC. If I recall correctly, it seemed to want to mount the cd drive, which it couldn't do, and then got lost. I don't recall the specifics, as I tossed my CD in the hopes that people much smarter than me would figure it out. :-) But my impression was that the Oxygen init script is expecting to be run from a floppy or floppy-emulated device. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] Oxygen Updates
David Douthitt wrote: Also, the Oxygen Bootable CDROM has been updated, but the 'largenet' configuration is still SegFaulting at the end. Please help me find out why It's very puzzling, as there is plenty of RAMdisk space and other configurations work fine. In case it is any help to anyone else, when I booted with the CD and just hit enter (default is linux), linuxrc ran until the section *** ALMOST ALL OTHER PARAMETERS WILL BE IGNORED! *** LINUXRC: couldn't mount /dev/fd0u1680 with fs msdos! LINUXRC: error: not configuration LINUXRC: stopping system... and it stopped. From an older post of Dave's I tried this at the initial boot prompt: boot: linux conf=testcd.cfg and boot: linux conf=cdrom.cfg and LINUXRC goes through, complains about not finding /dev/fd0u1680 several times, then loads the packages and runs. I'm sure I'm abusing the boot prompt and should be entering other things as well, but this was the minimum I needed to get going. I'm sure I missed something along the line, but the Dec 17 .iso is the first one that's worked for me. Looking forward to testing further. Dave, is the linux conf=largenet.cfg the way I'm supposed to test the largenet.cfg? ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] Updated Oxygen Development Image - and lrp/ source directory
If people could bang away on the Oxygen development image, I'd appreciate it. I'd like to hear from some testers before I release... Finally got a chance to download (and test), so far looks good. The config.lrp handling works nicely now. Thanks! As an observation, /dev/boot seems to be a permanent symlink to /dev/fd0u1680, even when booting from /dev/hda1 (I had globally replaced fd0u1680 /w hda1 in oxygen.cnf) But I probably missed something somewhere on changing that (RTFM, right?) So far the new image looks good. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] cryptographically signed .LRPs
On Tue, 4 Dec 2001, Charles Steinkuehler wrote: snip Yeah, I think it's pretty big, plus I believe most of these packages require openssl and other huge add-ons to run. The basics of public-key cryptography, however, are pretty simple, so I think it'd be possible to make a small (a few K, perhaps) binary that would simply calculate and verify signatures, as long as there arn't too many various options to deal with (ie no cert chains, or fancy stuff, just plain-old crypto signing). And Jack Coats pointed out gpgv that might fit on a CD (283932 bytes), to which Jeff Newmiller reminded all that gpg will take that much ramdisk + RAM to run in... gpgv is the verification only part, and looking through the source code, most of it is gpg stubbed out (to be as small as possible.) From the looks of it, it is pretty close to what you were describing: gnupg 1.0.6 (gpgv), stripped and upx'ed down to 113522 bytes That's still pretty big. Or do you think that would be small enough? I don't see any way to get a pgp-like app smaller than that. Another idea might be to use OpenSSL, something like s/mime. (OpenSSL 0.9.6b stripped upx'ed is 400K or so, but it includes alot of other junk.) I saw no obvious way to strip it down without rewriting a small wrapper app that uses just a subset of the SSL libraries. (but, I make NO claims to being a coder.) With OpenSSL, you'd have to worry about maintining x509 certs, though. No solutions, just some ramblings on my thoughts. Comments or ideas welcome. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] packages and filesystems
Jack Coates [EMAIL PROTECTED] wrote: And for this reason I'm thinking that versioning in the filename is a convenient nice-to-have. If the version and author attributes are kept on the web server that should be enough to enable accurate downloads, though there are still troubleshooting issues. Determining what version an end-user is using will require looking at package sizes. Jack, I like your idea alot. Does anyone see any advantage to adding some packager/versioning information inside the /var/lib/lrpkg/pkgname.version file? I think the file is supposed to have the package version number. What if a second line had the packager's name/version/tag/vfat package name/whatever. Scripts that use the file to get the version number would have to grab just the first line, but putting the additional info in the file would allow the original package info to be saved even if the target system was a fat-only box. Just a thought. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] packages and filesystems
Charles Steinkuehler wrote: How do your fields compare against those stored by rpm deb? A quick cruise over to debian and rpm.org produced this for me (Sorry, Dave, if I'm speaking out of turn) rpm debianDave NamesourceName Version Version Version Release Release Summary Description Description Description follows descr Vendor Url URL Group Section Group packagerMaintainerPackager Priority Standards-version RequiresDepends ProvidesProvides Provides Recommends Suggests Pre-depends Conflicts Conflicts Packaged Keywords (provides?) License ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] packages and filesystems
David Douthitt wrote: I have a strong faith in the current format - even if we package up newfangledsoftware 2.2.2 as a *.lrp with glibc 2.0, it'll still work in that LRP 2.9.4 somebody's running. If we add a new file (*.desc) to the /var/lib/lrpkg directory, the package STILL works in that LRP 2.9.4 ... I like. :-) ( you are right .desc is a MUCH better place to put this stuff than .version.) One question, though - What about adding a Requires tag? snort.lrp and tcpdump.lrp may both require libpcap.lrp newfangledsoftware 2.2.2 with glibc 2.1 requires glibc 2.1, and might segfault under 2.0.7. Maybe there's no way to automate the requires bits of the desc file like rpm does, but at least the package maintainer could give hints as to anthing else the new lrp might need. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] packages and filesystems
David Douthitt wrote: About all that can be asked for is a comment-like tag that package creators use to detail dependencies. Agreed. That's what I was thinking of - comments for things the maintainer knows of, with no guarantee that its accurate or comprehensive. And I see what you mean about gets charles talking about new formats. :-) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] Re: How to keep config files separate from the packages
- Original Message - From: arne @ loopback . org [EMAIL PROTECTED] I would go a step further. make a minimal busybox only containing very few applets(tar,msh as shell,mount,ls,cat,...) And link it statically with uClibc. This will result in a quite small binary and you don't need to include a big libc... I do not the interest of doing that in an LRP distro. You will need libc and ld-linux libraries anyway so why not putting them in initrd.gz ? If you compile statically even with uClibc you would loose disk space at the end... That is why you really don't need to back-up this as you would need it for a standard package with config files and the like. And I also do not see the need to make modification to root.linuxrc in the LRP environnement: there is not reason to change this script outside of LRP development. My only concern with this is the initial module loading introduced by Charles in dachstein. But I think I have found a solution to take care of this. See previous post. The Problem with your previous post is, that you can not load the loadmod.lrp from the boot medium cause you need the modules from there to access your boot medium. I do not understand that. If you need to mount a special driver to read your boot medium, obviously you cannot have either the original root.lrp nor my boomod.lrp package on this boot medium. It has to be on a floppy. I would prefer to put it into the kernel, this would lead to a few customed kernels, but only a few. As i want to concentrate my work on LRP for Systems with CD,harddisk or flashdisk i have no Problem with a larger kernel. Obviously that is a safe solution. My main Problem is to have it the size to fit on a floppy. But if we do not use a embedded libc we will run into problems anyway, as fewer programs will support glibc-2.0.7 and we have to switch to another libc. This will break the floppy stuff (as using kernel 2.4 might). Well I guess we will have to move to glibc 2.1 or 2.2 at some point. But we all know that will lead to a somewhat bigger LRP distro... Jacques ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
