[leaf-devel] Webconf Development
Don't know if this made to the list of not. Seems I slipped up and left the privacy crap that work email system puts on messages. I registered my home email on the list so that doesn't happen again. Sorry. I couldn't sleep last night, so I spent the time productively; thinking about Webconf and automating Bering in general. Some of the things I thought we will need to EVENTUALLY get working is the detection and installation of network interfaces. That seems to be the first big hurdle for new LEAF users. They don't know what kind of NICs they have, or don't know what module to use. Automatically detecting and installing the network interfaces would get these people over the first big hurdle. This shouldn't be too huge an effort, because distributions such as Damn Small Linux do it now. No need to reinvent the wheel. Just work from the shoulders of those who have done this already. Another, and I should think easier task, would be to automate a very basic setup of Shorewall. Detect the number of interfaces and setup eth0 as the untrusted side, eth1 as trusted, and eth2 if it exists as a DMZ (although anyone with a DMZ should know enough to do this amount of setup). Such a setup could provide multiple levels of user selected restriction, dare I say it, like Windows. Of course this is just to get the user started. A more detailed Shorewall page would help provide more granular control. The last idea was to provide a first page that let the user select the packages needed by a description of the function not by package name. The user would select the functions needed and the packages would be added to Webconf to setup. These are just thoughts I,m tossing out there. I'm not trying to get the cart before the horse. I realize that we need to get Webconf working as currently designed before, we go and try to do so much automation. If others think any of these ideas worth pursuing, I will be glad to work on them. For now I thought I'd start small and start work on dhcpd and dnsmasq, unless someone is already working on them. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Branches: Bering & Oxygen
Everyone, In my next revision of our branch derivation image map, I'm going to label Bering and Oxygen in yellow. Oxygen last update -- 2002 (red ? David ?) Bering last update -- June 2003 http://leaf-project.org/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=2 PacketFilter and Dachstein will move to red. Comments and suggestions are welcome. -- Mike Noyes http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Leaf.cfg
Erich Titl wrote: Hi Charles another little problem showed up using the bash package, apparently bash is included in initdr.lrp (or at least in initrd.list) this prevents bash being backed up using lrcfg. Problem summary: - initrd.lrp includes /bin/bash (symlink to ash) - installing 'real' bash.lrp means multiple packages list /bin/bash in their package.list files, so bash never gets backed up. There's not a perfect solution to this problem, as it is impossible in the current packaging system to include the same file in more than one package. Options for work-arounds include: 1) Remove /bin/bash from initrd.lrp, creating the symlink 'on the fly' as part of the init scripts. This moves the problem to root.lrp (which will try to backup the /bin/bash symlink...if /bin/bash is added to root.exclude.list, we're back to where we started, and bash will never get backed up). 2) Move the 'real' bash to someplace like /usr/bin/bash. This keeps files from steping on each other when backing up, but /bin/bash will still be a symlink to /bin/ash, unless modified (at which point you can no longer make a 'clean' backup of initrd.lrp). 3) Use indirection, similar to the debian 'alternatives', ie: /bin/bash -> /etc/alternatives/bash ..and one of .. /etc/alternatives/bash -> /bin/ash ..or.. /etc/alternatives/bash -> /usr/bin/bash With this method, you can make a 'clean' backup of both initrd.lrp *AND* bash.lrp, with the change required to select whether to use ash or bash as /bin/bash saved in a third package (either etc or a seperate alternates pacakge). ...or you can just ignore the whole mess, and don't backup initrd or bash (or manually remove /bin/bash from one package list file if you need to backup the other). Realistically, it shouldn't generally be required to backup the bash package (for anyone other than the maintainer), and it's only rarely necessary to backup initrd.lrp, so this is the option -- Charles Steinkuehler [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Leaf.cfg
Erich Titl wrote: Charles after moving from lrpkg.cfg to leaf.cfg and the new linuxrc, which I hopefully did right... I found something weird in my backdisk file after manually loading bash using lrpkg -i /disk/bash (/disk being the mount point of my CF) mhttpd=-t msdos /dev/hda1 webconf=-t msdos /dev/hda1 bash=-t console=ttyS0,38400 It looks like lrpkg did not handle the file system and the device correctly. The reason I believe lies in the lrpkg command which scans for the boot parameter in the command line and tries to find the boot.fstype file too. Is there a more recent version available? This is a known bug, resulting from the elimination of the boot.fstype file. It's considered 'cosmetic' (and hasn't been fixed by me) for a few reasons: - If you actually want to backup a manually installed package, you'll have to specify a backup target. It's not possible for lrpkg to know which of the available targets you'll want to use to backup the pacakge. You could default to the first entry in /var/lib/lrpkg/pkgpath.disks, which should be right most of the time, but might not be the right thing to do all the time. - Currently, if you try to backup a manually installed package, you get an error (due to the malformed backdisk entry), 'prompting' the user to select an appropriate backup path. - As soon as you manually specify a backup path in lrcfg, the backdisk file is corrected. - I haven't had time to re-work lrpkg to extract the backup information from pkgpath.disks if boot.fstype doesn't exist. There's no newer version available that I'm aware of. If manually setting a backup destination is enough of a problem, feel free to hack on lrpkg. I'll help as time allows. -- Charles Steinkuehler [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
