Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
At 09:41 PM 7/5/2004 -0700, Chad Carr wrote: There is a lot here; let me begin. Comments inline. If I choose not to comment, that means I have nothing to add, not that I missed it. Thanks for a response that was both quick and to the point. I'm running out of things to say too, at least until I think a good bit more about the UI part (my main interest in this melange of related topics). So only a few minor responses this time around. 1) Unconfigured interfaces tend not to route packets to the proper destination (or accept them actually, even if you can figure out their address). A distinct problem for http-based configuration interfaces. Yes. But http-based configuration of home routers (think Linksys or Netgear) is naturally done on the internel interface, which can easily have workable values as the default settings (the best the external interface can do, I suppose, is default to DHCP). I'm pretty sure the current Bering variants assume eth1 is internal, has address 192.168.1.254, and is on 192.168.1.0/24. 2) There are several different types of interface configuration that potentially result in dynamic assignment of parameters such as ip address, mask and dns resolvers. DHCP of course is this way. PPPoE and dialup PPP set address stuff but not, as I recall, DNS. But that's quibbling. You are right, of course. I chose the example of setting up a static address in order to focus on UI complexity, not backend complexity ... static addresses involve the most explicit input from the user. Functionally, LEAF will not be able to bootstrap ethernet interfaces via anything other than a console-based interface until we are off floppy, which is not a goal of this project, from what I have seen. This is not quite true. Bering's kernel, like many small kernels, has limited NIC support built in. Right now I forget what NICs are supported out of the box, but tulip is a likely example. A LEAF system with 2 supported NICs could easily be brought up to the point where a Web-based interface was available on the LAN side, if the configuration chose sensible defaults. I believe the current defaults fit the need; if not, they would be easy to tweak, using the Linksys setup style as a mental model. Until we can throw a bunch of modules on the boot media and detect hardware, this is simply not a possibility. Not a limitation (or a responsibility) of the configuration database or any of the infrastructure components. Theoretically, a pre-configuration utility (as simple as a Makefile or as complex as a Java program) making use of the cdb structure will have a much easier time of building a bootstrapped floppy image for a newbie than without it (modules included!) Years ago, back in LRP days, there was a Web-based configuration system that would construct a modules.lrp file for you. It handled other things, like the various ip_masq_* modules, but its main purpose was to simplify NIC support. It failed for no fundamental reason, just the site's developer losing interest and nobody else picking it up when LRP changed kernels. It would be nice to think again about a configuration system that would build a floppy image that had a base kernel, suitable modules, an etc.lrp package with the right /etc/modules file, and the mix of packages suitable to a specific system ... maybe even including choices of firewall packages. But I Think that is not our immediate concern for using cdb. This entire passage depends on the interface and how it is laid out. Interface switching can easily be implemented as a wizard which allows you to select the interface on the first page, then configure the interface on subsequent pages, thus avoiding the hassle of re-reading data while accepting user input, then trying to figure out what to do. I have no particular objection to separating these two steps, but I have e general objection to fragmenting the UI in ways that do not seem natural to our target users. Which way this specific idea falls I don't really know. But I do know that the interaction with the user has to be the predominent consideration in all UI work, including how the configuration is compartmentalized.\ [...] 10) If any trigger fails, the cdb is rolled back to a sane state and the trigger is fired again, restoring the system to its previous state. Here I'm lost. Passive voice is the weakness here. Something has to do the roll back to a sane state part, and it's not clear from context what part of the system makes the decision to do so and initiates the action. We have at this point the individual scripts, the trig glue app, and the UI itself all running. What constitutes fails isn't as obvious as it might sound like. Nor is sane state. I see why you were vague; this is messy and needs serious thinking. You are reading very closely. It's what I do. Anyway, I asked you to write this up and you obliged. Reading it carefully seemed like the only polite thing to do. I used
{RESEND]: RE: [leaf-devel] New project members
Mike, Another ping - any estimate on when you might be done with the web site? I'm beginning to think it may be one of those on-going tasks, with no end date, though I assume your web site upgrade has some goals and at least an implicit project plan? Is there any neccessary linkage between your completion of your web site tasks and addition of new users, or is it just that you are incredibly busy, in which case one of the other project admins can probably perform the task of providing me access? Remember, the original basis for my request about 4 months ago was to be able to provide some user-contributed packages. Just curious. Thanks, -Venki --Original Message- -From: Venki S. Iyer [mailto:[EMAIL PROTECTED] -Sent: Monday, July 05, 2004 7:17 PM -To: Mike Noyes; [EMAIL PROTECTED] -Subject: RE: [leaf-devel] New project members - - - -Mike, - -Not a problem - any estimate on when you might be done w/ the web site? - -Thanks, - --V - - ---Original Message- --From: [EMAIL PROTECTED] --[mailto:[EMAIL PROTECTED] Behalf Of Mike Noyes --Sent: Monday, July 05, 2004 4:29 PM --To: [EMAIL PROTECTED] --Subject: [leaf-devel] New project members -- -- --Subject was Re: [leaf-devel] Re: CVS Access ... --On Sun, 2004-07-04 at 22:25, Venki S. Iyer wrote: -- Just saw a note from you talking about CVS access - I am -awaiting access -- myself. The SF id is 'venkisiyer'. -- --Venki, --I should be able to make you a project member shortly after our new --website is complete. I apologize for the delay. -- --Everyone, --Is anyone else awaiting addition to our project? -- --Mike Noyes mhnoyes at users.sourceforge.net --http://sourceforge.net/users/mhnoyes/ --SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs -- -- -- - --This SF.Net email sponsored by Black Hat Briefings Training. --Attend Black Hat Briefings Training, Las Vegas July 24-29 - --digital self defense, top technical experts, no vendor pitches, --unmatched networking opportunities. Visit www.blackhat.com -- --___ --leaf-devel mailing list --[EMAIL PROTECTED] --https://lists.sourceforge.net/lists/listinfo/leaf-devel -- --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [leaf-devel] Source: config
GoAhead, boa, thtpd etc are good alternative. GoAhead has ASP like scripting which is proprietary but pretty near Microsoft ASP. I remember m0n0wall uses PHP on a Soekris board. Maybe we can keep http interface for a dual floppy version or CF version. Single floppy system will be minimalistic. Warm regards Mohan -Original Message- From: Chad Carr [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 06, 2004 10:48 AM To: [EMAIL PROTECTED] Subject: Re: [leaf-devel] Source: config On Jul 5, 2004, at 9:14 PM, S Mohan wrote: 3. As part of this, can we also look at adopting a web server with scripting support for the configuration/monitoring using http/https. I took a look at acme mini_httpd a while back and it seemed just the ticket. Even packaged it for Bering, somewhere. Fairly large though with the crypto libs, but the Bering Uclibc guys have reclaimed some floppy space, right? --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
Ray, I have deleted some stuff below not because I ignored it, but because I wanted to focus some immediate discussion on some of your points: On Jul 5, 2004, at 11:07 PM, Ray Olszewski wrote: At 09:41 PM 7/5/2004 -0700, Chad Carr wrote: 1) Unconfigured interfaces tend not to route packets to the proper destination (or accept them actually, even if you can figure out their address). A distinct problem for http-based configuration interfaces. Yes. But http-based configuration of home routers (think Linksys or Netgear) is naturally done on the internel interface, which can easily have workable values as the default settings (the best the external interface can do, I suppose, is default to DHCP). I'm pretty sure the current Bering variants assume eth1 is internal, has address 192.168.1.254, and is on 192.168.1.0/24. Functionally, LEAF will not be able to bootstrap ethernet interfaces via anything other than a console-based interface until we are off floppy, which is not a goal of this project, from what I have seen. This is not quite true. Bering's kernel, like many small kernels, has limited NIC support built in. Right now I forget what NICs are supported out of the box, but tulip is a likely example. A LEAF system with 2 supported NICs could easily be brought up to the point where a Web-based interface was available on the LAN side, if the configuration chose sensible defaults. I believe the current defaults fit the need; if not, they would be easy to tweak, using the Linksys setup style as a mental model. Until we can throw a bunch of modules on the boot media and detect hardware, this is simply not a possibility. Not a limitation (or a responsibility) of the configuration database or any of the infrastructure components. Theoretically, a pre-configuration utility (as simple as a Makefile or as complex as a Java program) making use of the cdb structure will have a much easier time of building a bootstrapped floppy image for a newbie than without it (modules included!) Years ago, back in LRP days, there was a Web-based configuration system that would construct a modules.lrp file for you. It handled other things, like the various ip_masq_* modules, but its main purpose was to simplify NIC support. It failed for no fundamental reason, just the site's developer losing interest and nobody else picking it up when LRP changed kernels. It would be nice to think again about a configuration system that would build a floppy image that had a base kernel, suitable modules, an etc.lrp package with the right /etc/modules file, and the mix of packages suitable to a specific system ... maybe even including choices of firewall packages. But I Think that is not our immediate concern for using cdb. Let's start with the three sections above. I am all for making a preconfig part of the scope of this effort. I think it is well within the technical limits of the code we are talking about building, and it is an effort that will pay back with time saved on the newbie side (not that it will save _me_ time; I tend to ignore the buggers, but you and Tom have hearts of gold!). I also think that it factors into the decisions we are making with respect to the config-db and associated tools (package manager, for instance) I think the basic premise of a preconfig system would be to take some user input (this could start small like asking them to select their NICs from a list and what type of boot media they want), then generating a .bin or .iso for them with the modules built in and the initial config-db laid populated with default values. I have basically two questions I would like to put up to the group: 1) Should this tool be host-based (downloadable) or server-based (a web interface)? 2) What main functionality should it have? This is a list of possibilities to get the discussion going: configure console (serial, vga, or headless) configure NICs (possibly including initial IP addressing) configure dns/dhcpd configure time zone/ntp configure additional packages to install (not the package configs themselves) If we decide to create a host-based tool, we need to answer two additional questions: 1) Do we require linux as a host? 2) Do we require network access during preconfig? 11) The interface displays either an error or success message. On success, the user is presented with a page offering to back up the system to the boot media thus preserving the state of the system across reboots. My preference would be always to back up the system (or at least the cdb package) as part of a commit. Both approaches have their strengths and their defects ... probably ovbious to anyone interested in this thread ... so just listing the strengths of one and the defects of the other doesn't help much. On balance, I think prompt backup is more familiar to users, especially inexperienced ones, so that's why I favor it. I prefer to apply the changes and ask the user to commit
[leaf-devel] Web dynamic generation of image
Subject was Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl) On Mon, 2004-07-05 at 23:07, Ray Olszewski wrote: At 09:41 PM 7/5/2004 -0700, Chad Carr wrote: Until we can throw a bunch of modules on the boot media and detect hardware, this is simply not a possibility. Not a limitation (or a responsibility) of the configuration database or any of the infrastructure components. Theoretically, a pre-configuration utility (as simple as a Makefile or as complex as a Java program) making use of the cdb structure will have a much easier time of building a bootstrapped floppy image for a newbie than without it (modules included!) Years ago, back in LRP days, there was a Web-based configuration system that would construct a modules.lrp file for you. It handled other things, like the various ip_masq_* modules, but its main purpose was to simplify NIC support. It failed for no fundamental reason, just the site's developer losing interest and nobody else picking it up when LRP changed kernels. It would be nice to think again about a configuration system that would build a floppy image that had a base kernel, suitable modules, an etc.lrp package with the right /etc/modules file, and the mix of packages suitable to a specific system ... maybe even including choices of firewall packages. But I Think that is not our immediate concern for using cdb. Ray, ROM-o-matic provides similar functionality for Etherboot. If someone would like to work on this for LEAF branches, I'll try to figure out how to host it. ROM-o-matic.net http://rom-o-matic.net/5.2.4/ -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: {RESEND]: RE: [leaf-devel] New project members
On Tue, 2004-07-06 at 00:59, Venki S. Iyer wrote: Another ping - any estimate on when you might be done with the web site? I'm beginning to think it may be one of those on-going tasks, with no end date, though I assume your web site upgrade has some goals and at least an implicit project plan? Venki, The upgrade was partially complete when I had my accident (epidural hematoma). I've had some difficulties since then, but I'm close to completing the new website. Is there any neccessary linkage between your completion of your web site tasks and addition of new users, or is it just that you are incredibly busy, in which case one of the other project admins can probably perform the task of providing me access? Remember, the original basis for my request about 4 months ago was to be able to provide some user-contributed packages. Yes to some extent. Our website is a CMS (phpWebSite) that every project member has a login for and area for individual content. Project member content in work links to the SF FRS or CVS. I guess I could add you to the project and give you cvs access. What project resources are you looking to make use of? -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [leaf-devel] Source: config
I'd prefer the synchronicity to be coupled with a reasonable timeout period and default exit status being fail on timeout. Would this mean tinkering with process priorities so that the calling shell/process is always serviced? Discussions on cdb envisages dealing with name pairs. Can we not extend this to a relational DB form? Each application will have to register an attribute to the object. E.g. eth0 is an object. Its attributes are address, mask If we install shorewall, the eth0 related parameters like masq, norfc1918 etc are boolean fields/attributes. If we do so, in CLI if we query the interface, we will not only get IP related info but also application related info. I'm in agreement with Ray that we must follow the Linksys/netgear route for GUI. Our strength will be availability of CLI also. Warm regards Mohan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chad Carr Sent: Tuesday, July 06, 2004 10:41 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [leaf-devel] Source: config On Jul 5, 2004, at 9:58 PM, S Mohan wrote: Chad and list, The simple way is synchronous. Unfortunately synchronous is generally slow, and, as you mentioned, a way for an ill-behaved trigger script to make a mockery of the system. A decision that must be made, and soon. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
In my conception, I'm inclined to look at the CDB not for just config info but as a single repository for all data - config info, package info, user info, performance info etc. Is this way beyond what others look at it as? Warm regards Mohan -Original Message- From: Chad Carr [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 06, 2004 10:46 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl) I am not a fan. Space can be conserved with binary files, but editability is sacrificed. XML provides human(?) readibility/editability, but takes up lots of space. The filesystem as backing store has always seemed to me to be the best idea given the constraints. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Web dynamic generation of image
On Tue, 2004-07-06 at 07:17, Mike Noyes wrote: On Tue, 2004-07-06 at 06:28, Chad Carr wrote: If we decide to create a host-based tool, we need to answer two additional questions: 1) Do we require linux as a host? 2) Do we require network access during preconfig? Chad, A live cd approach may work to create the initial LEAF image (e.g. a striped down Knoppix). -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
On Monday 05 July 2004 07:44 pm, Mike Noyes wrote: On Mon, 2004-07-05 at 16:14, Chad Carr wrote: I say we all take a look at it, stamp it with approval or disapproval, and move on to more pressing questions, like when to back up changes and how the hell to write a full-featured templating system in the 92k stripped down /bin/sh from Oxygen! Chad, Dash may help in this area. http://gondor.apana.org.au/~herbert/dash/ DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible. DASH is not compilable for glibc-2.0.7. -- ~Lynn Avants Linux Embedded Appliance Firewall Developer http://leaf.sourceforge.net http://guitarlynn.homelinux.org:81 --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [--ot] [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
Erich Titl wrote: Hi At 21:55 06.07.2004, Lynn Avants wrote: On Monday 05 July 2004 07:44 pm, Mike Noyes wrote: On Mon, 2004-07-05 at 16:14, Chad Carr wrote: I say we all take a look at it, stamp it with approval or disapproval, and move on to more pressing questions, like when to back up changes and how the hell to write a full-featured templating system in the 92k stripped down /bin/sh from Oxygen! Chad, Dash may help in this area. http://gondor.apana.org.au/~herbert/dash/ DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible. DASH is not compilable for glibc-2.0.7. Some time ago I tried to use busybox ash instead of the installed one on Bering 1.2+. My goal was to get more space for possibly a more recent gclibc library and more modern package versions. I quickly found out that the ash syntax used in, for example, the backup routines did not work. I guess in order to be able to use different shells we should stick to an extreme low level of the possible tricks in the scripting _dialect_ so porting issues will pop up less frequently. This may sound like heresy in the ears of shell afficionados but will enhance the chance to use different interpreters. So which constructs do you propose that we do away with? -Tom -- Tom Eastep\ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [--ot] [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
Erich Titl wrote: Hi At 21:55 06.07.2004, Lynn Avants wrote: On Monday 05 July 2004 07:44 pm, Mike Noyes wrote: On Mon, 2004-07-05 at 16:14, Chad Carr wrote: I say we all take a look at it, stamp it with approval or disapproval, and move on to more pressing questions, like when to back up changes and how the hell to write a full-featured templating system in the 92k stripped down /bin/sh from Oxygen! Chad, Dash may help in this area. http://gondor.apana.org.au/~herbert/dash/ DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible. DASH is not compilable for glibc-2.0.7. Some time ago I tried to use busybox ash instead of the installed one on Bering 1.2+. My goal was to get more space for possibly a more recent gclibc library and more modern package versions. I quickly found out that the ash syntax used in, for example, the backup routines did not work. I guess in order to be able to use different shells we should stick to an extreme low level of the possible tricks in the scripting _dialect_ so porting issues will pop up less frequently. This may sound like heresy in the ears of shell afficionados but will enhance the chance to use different interpreters. No idea how much work it would take to get up to level alone with busybox ash, let alone with another interpreter. My understanding is the busybox ash comes from the same source the ash used in LRP came from (although I think there are a few differences, such as command line history, that are implemented differently), and should work fine with LEAF. IIRC, busybox ash has several compile-time options to allow for smaller size (by omitting lesser-used features that the complex scripts in LEAF tend to rely on). Are you sure you had everything enabled when you built the busybox ash and it still didn't work with Bering? -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [--ot] [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
Tom At 23:29 06.07.2004, Tom Eastep wrote: Erich Titl wrote: ... Some time ago I tried to use busybox ash instead of the installed one on Bering 1.2+. My goal was to get more space for possibly a more recent gclibc library and more modern package versions. I quickly found out that the ash syntax used in, for example, the backup routines did not work. I guess in order to be able to use different shells we should stick to an extreme low level of the possible tricks in the scripting _dialect_ so porting issues will pop up less frequently. This may sound like heresy in the ears of shell afficionados but will enhance the chance to use different interpreters. So which constructs do you propose that we do away with? I believe I cannot put my fingers on one simple statement, definitely the bracket test ( if [ -x /tmp/foo ] ) syntax clashes with busybox ash, at least with the version I tested. This syntax is elegant and widely used though, so you can imagine the impact such a thing would have. Maybe someone else has more experience with other issues in the busybox shell? cheers Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [--ot] [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
Charles At 23:43 06.07.2004, Charles Steinkuehler wrote: Erich Titl wrote: Hi At 21:55 06.07.2004, Lynn Avants wrote: On Monday 05 July 2004 07:44 pm, Mike Noyes wrote: On Mon, 2004-07-05 at 16:14, Chad Carr wrote: I say we all take a look at it, stamp it with approval or disapproval, and move on to more pressing questions, like when to back up changes and how the hell to write a full-featured templating system in the 92k stripped down /bin/sh from Oxygen! Chad, Dash may help in this area. http://gondor.apana.org.au/~herbert/dash/ DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible. DASH is not compilable for glibc-2.0.7. Some time ago I tried to use busybox ash instead of the installed one on Bering 1.2+. My goal was to get more space for possibly a more recent gclibc library and more modern package versions. I quickly found out that the ash syntax used in, for example, the backup routines did not work. I guess in order to be able to use different shells we should stick to an extreme low level of the possible tricks in the scripting _dialect_ so porting issues will pop up less frequently. This may sound like heresy in the ears of shell afficionados but will enhance the chance to use different interpreters. No idea how much work it would take to get up to level alone with busybox ash, let alone with another interpreter. My understanding is the busybox ash comes from the same source the ash used in LRP came from (although I think there are a few differences, such as command line history, that are implemented differently), and should work fine with LEAF. IIRC, busybox ash has several compile-time options to allow for smaller size (by omitting lesser-used features that the complex scripts in LEAF tend to rely on). Are you sure you had everything enabled when you built the busybox ash and it still didn't work with Bering? As sure as I can be, (which may not mean a lot.), but then why do we have a separate implementation of ash, sed, halt, klogd, reboot, syslogd, watchdog, wget. I believe busybox is part of initrd.lrp But then, this is busybox 0.60.5 /* vi: set sw=4 ts=4: */ // This file defines the feature set to be compiled into busybox. // When you turn things off here, they won't be compiled in at all. // This file is parsed by sed. You MUST use single line comments. // i.e., //#define BB_BLAH // // // BusyBox Applications //#define BB_ADJTIMEX //#define BB_AR #define BB_ASH #define BB_BASENAME #define BB_CAT #define BB_CHGRP #define BB_CHMOD #define BB_CHOWN #define BB_CHROOT //#define BB_CHVT #define BB_CLEAR //#define BB_CMP #define BB_CP //#define BB_CPIO #define BB_CUT #define BB_DATE //#define BB_DC #define BB_DD //#define BB_DEALLOCVT #define BB_DF #define BB_DIRNAME #define BB_DMESG //#define BB_DOS2UNIX //#define BB_DPKG //#define BB_DPKG_DEB #define BB_DUTMP #define BB_DU //#define BB_DUMPKMAP #define BB_ECHO //#define BB_ENV //#define BB_EXPR //#define BB_FBSET //#define BB_FDFLUSH #define BB_FIND #define BB_FREE #define BB_FREERAMDISK //#define BB_FSCK_MINIX //#define BB_GETOPT #define BB_GREP #define BB_GUNZIP #define BB_GZIP #define BB_HALT #define BB_HEAD #define BB_HOSTID #define BB_HOSTNAME //#define BB_HUSH #define BB_ID //#define BB_IFCONFIG #define BB_INIT #define BB_INSMOD #define BB_KILL #define BB_KILLALL #define BB_KLOGD //#define BB_LASH //#define BB_LENGTH #define BB_LN //#define BB_LOADACM //#define BB_LOADFONT #define BB_LOADKMAP #define BB_LOGGER //#define BB_LOGNAME //#define BB_LOSETUP #define BB_LS #define BB_LSMOD #define BB_MAKEDEVS //#define BB_MD5SUM #define BB_MKDIR //#define BB_MKFIFO #define BB_MKFS_MINIX #define BB_MKNOD //#define BB_MKSWAP //#define BB_MKTEMP //#define BB_MODPROBE #define BB_MORE #define BB_MOUNT //#define BB_MSH //#define BB_MT #define BB_MV #define BB_NC #define BB_NSLOOKUP #define BB_PIDOF #define BB_PING #define BB_PIVOT_ROOT //#define BB_POWEROFF #define BB_PRINTF #define BB_PS #define BB_PWD #define BB_RDATE //#define BB_READLINK #define BB_REBOOT //#define BB_RENICE //#define BB_RESET #define BB_RM #define BB_RMDIR #define BB_RMMOD //#define BB_ROUTE //#define BB_RPM2CPIO #define BB_SED //#define BB_SETKEYCODES #define BB_SLEEP #define BB_SORT #define BB_STTY //#define BB_SWAPONOFF #define BB_SYNC #define BB_SYSLOGD #define BB_TAIL #define BB_TAR //#define BB_TEE //#define BB_TEST //#define BB_TELNET //#define BB_TFTP //#define BB_TIME #define BB_TOP #define BB_TOUCH #define BB_TR #define BB_TRACEROUTE #define BB_TRUE_FALSE #define BB_TTY //#define BB_UNIX2DOS //#define BB_UUENCODE //#define BB_UUDECODE #define BB_UMOUNT #define BB_UNIQ #define BB_UNAME #define BB_UPDATE #define BB_UPTIME //#define BB_USLEEP //#define BB_VI #define BB_WATCHDOG #define BB_WC #define BB_WGET #define BB_WHICH #define BB_WHOAMI #define BB_XARGS #define BB_YES // End of Applications List THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED]
Re: [--ot] [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
Erich Titl wrote: Charles At 23:43 06.07.2004, Charles Steinkuehler wrote: snip IIRC, busybox ash has several compile-time options to allow for smaller size (by omitting lesser-used features that the complex scripts in LEAF tend to rely on). Are you sure you had everything enabled when you built the busybox ash and it still didn't work with Bering? As sure as I can be, (which may not mean a lot.), but then why do we have a separate implementation of ash, sed, halt, klogd, reboot, syslogd, watchdog, wget. I believe busybox is part of initrd.lrp Historical issues, in part (busybox didn't include ash, set, etc. when LRP was initially created). There are also compatability issues (for instance, sed is really 'put to the test' in several scripts that are part of LEAF, and I'm not sure the BB version of sed would work properly). But then, this is busybox 0.60.5 /* vi: set sw=4 ts=4: */ // This file defines the feature set to be compiled into busybox. // When you turn things off here, they won't be compiled in at all. // This file is parsed by sed. You MUST use single line comments. // i.e., //#define BB_BLAH // // // BusyBox Applications //#define BB_ADJTIMEX //#define BB_AR #define BB_ASH OK, you're compiling ash... snip //#define BB_TEST ...but you're *NOT* compiling test, which (as it's alter-ego '[' ) is what processes those conditional commands you were having problems with: definitely the bracket test ( if [ -x /tmp/foo ] ) syntax There should also be several ash options *OTHER* than the build switch you list above...I'm not sure where these would be in older busybox, but in the current CVS, it looks like they're in the shell directory as part of Config.in: http://www.busybox.net/cgi-bin/cvsweb/busybox/shell/Config.in?rev=1.16view=auto Note the recent addition of a 64-bit math support, which might be handy for LEAF... -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [--ot] [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
On Tuesday 06 July 2004 03:58 pm, Erich Titl wrote: [...] Some time ago I tried to use busybox ash instead of the installed one on Bering 1.2+. My goal was to get more space for possibly a more recent gclibc library and more modern package versions. I quickly found out that the ash syntax used in, for example, the backup routines did not work. I guess in order to be able to use different shells we should stick to an extreme low level of the possible tricks in the scripting _dialect_ so porting issues will pop up less frequently. This may sound like heresy in the ears of shell afficionados but will enhance the chance to use different interpreters. No idea how much work it would take to get up to level alone with busybox ash, let alone with another interpreter. David D rewrote Oxygen from the ground up in his last release to use BB-ash. The problem we basically face is the behavior of the glibc-2.0.7 Ash- (stripped) is not compatible with any other version of Ash known to mankind. This is the reason that David had to re-write init and other core files when he made the switch. That is likely another reason why we are still using the same binary that is so ancient. I don't know what the difference is, but everything else I've compiled has had syntax conflicts with one package or another (if it even boots correctly to begin with). IIRC, UClibc-team has made several corrections when they were first starting the project. I also seem to recall that they are using BB-Ash, so this is likely the best place to look at using a different (and compatible) shell. -- ~Lynn Avants Linux Embedded Appliance Firewall Developer http://leaf.sourceforge.net http://guitarlynn.homelinux.org:81 --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
