Re: [leaf-user] Update: Short term LEAF project goals
Lynn Avants wrote: I just didn't know how tunneling methods were integrated into Java other than possibly a call built-into the source. I think I'm back to my previous question, aren't these tunnel programs run as seperate apps from the GUI? What I mean is, there aren't any applications out there that need to know or be configured to use an encrypted tunnel, they just open a socket like they normally do. The tunnel is created in advance of the GUI ever running, isn't that the idea, and the GUI never knows about it. I may be wrong, but unless there's a decision to use the built-in java SSL or SSH calls as versus a seperate tunnel, java doesn't have a role in the security aspect. regards, matthew --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
I'm referring to only packaging meaning having within the same lrp. Additionally, the package installer should load all modules that are tarred within the package as they are deemed necessary for the utilities to work. I'm not suggesting that the module be compiled or integrated. Can we do away with manual steps when it is obviously needed. That is all. Sorry if my earlier posts have conveyed otherwise. It would probably be enough if a lrp package could have a init script on load that did whatever the module wanted setting on load - that way a module could insmod anything it wanted to. The only real danger here would be when modified packages were written away - does the .o get written twice (wasting space) or not at all (leaving you with a broken system). For that matter - does a .o need to be in /lib/modules once it is loaded? could we get away with copying it from module-specific space to /lib/modules, loading it then deleting it? --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
Lynn Avants wrote: Matt, Are lshd, Sounds new. what's the benefit of lshd? stunnel, http://tinyurl.com/63lh or zebedee also feasible options with Java??? Don't see why not, isn't this, like stunnel, completely seperate from the application? It's another thing to compile and make run though. Whatever works is cool, but I'd like to keep down the system reqs on both ends. Matt --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
On Wednesday 19 February 2003 04:18 pm, Matt Schalit wrote: Lynn Avants wrote: Matt, Are lshd, Sounds new. what's the benefit of lshd? It is somewhat compatible with SSH, but smaller. It is available for uClibc-bering and probably Bering as well. stunnel, Mosquito and other off-LEAF variants use it with their web- interfaces. Check David D's repository. or zebedee also feasible options with Java??? Don't see why not, isn't this, like stunnel, completely seperate from the application? Jacques has this one, it is a small replacement for SSH with *NIX and Win32 clients. It's another thing to compile and make run though. Whatever works is cool, but I'd like to keep down the system reqs on both ends. I just didn't know how tunneling methods were integrated into Java other than possibly a call built-into the source. -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
AW: [leaf-user] Update: Short term LEAF project goals
GUI Pre-rollout Config == We are thinking it'd be cool, if you wanted to, to download a fat CD of everything LEAF on it, burn the thing, and use it to build yourself a custom LEAF floppy. You'd do this before you rollout that floppy to the LEAF box. You could save your changes. You could upgrade to a new LEAF version seamlessly. We could make the pre-config program a Java GUI, a Python GUI, or a Web/Cgi thing. This is very dependant on new packages and a new central-db. This is a good place to advertise my work: I have written a bunch of scripts I use for pre-configuring Bering firewalls. They are useful for separating hardware dependent and configuration dependent stuff from the standard packages. I also find it much simpler to upgrade kernels or packages, because of that separation. The scripts provide no GUI but I think they could be useful for generating packages with the configuration created in the GUI. Regards Alex --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: AW: [leaf-user] Update: Short term LEAF project goals
Alex Rhomberg [EMAIL PROTECTED] writes: This is a good place to advertise my work: I have written a bunch of scripts Could you add a link please? Regards, Frank --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
You asked for comments: I long ago created my own database, wherein XT_DEVICE=eth0 XT_IF= 204.001.001.001 XT_MASK=24 IT_DEVICE=wlan0 ROUTERTYPE=tunnel IT_DHCPS=yes A1_DEVICE=eth1 SPOOFING=no etc,etc. (about 80 variables) And a single python function which can be called from a command line as in: /var/www/cgi-bin/xlfixconf.pyXT_GW=204.001.001.254 or from another python program. This is simple. If you import the above, it is all valid bash and variables can be used in all the networking and firewall scripts. It takes a little extra code to build something like ipsec.conf or dhcpd.conf. Anyway, the point is its simple to look at and simple to edit and Python or Perl builds a hash table in milliseconds. Any sort of real database technology would be a burdensome complication. Now. Given an organization like above, with creative use of underlines to create a hierarchy, It would be quite simple to write a 2 way parser bash-variables -- XML. I should also mention, there is a subject which rarely mentioned on LEAF, Group Permits. This is where you use netfilter to allow access to subnets and servers and services by groups of ip's and maybe domains. This deserves some db kind of thinking. I've kind of brute forced this stuff so far and haven't designed a decent database yet. But it is worth thinking about in any design. I think Cisco calls thisAccess Lists. Oh, can't speak for Perl, but after 1.5, Python gets BIG. 1.5 is fine for my purposes. Anyway, size matters. Matt Schalit [EMAIL PROTECTED] on 02/17/2003 12:39:36 PM To: [EMAIL PROTECTED] cc:(bcc: Phillip Watts/austin/Nlynx) Subject: [leaf-user] Update: Short term LEAF project goals This is an unofficial message to let folks know what the short term goals are for the LEAF project, the hot topics being developed, just in case you're not monitoring the leaf-devel list. I wasn't asked to write this, but I figured it'd might help a bit. Please toss in your comments if you'd like. More communication is welcome. LEAF is a loose collection of kind people who share a common interest in embedded Linux. There's no top-down organization here, per se, but rather the following ideas are what people are most excited about and working on. They are listed in an order that likely denotes their place in our unoffical roadmap. The point here being that it'd be tough to build a GUI admin system when you know there's a new package system coming out shortly: 1) Central configuration database 2) Central package repository 3) New package system 4) GUI preconfig 5) GUI admin Central Configuartion Database This is a way of storing the variables and values that make your LEAF box unique, like your IP addresses, in one single location and making a new command, perhaps leaf-cdb, that is used to access the db. Values like IP, netmask,and hostname that are common across packages will be listed once. No more entering the same data 5 times across 5 packages! The current idea is to use a stucture similar to the linux /proc set of subdirectories. Another idea is to burp that structure out of an xml database, perhaps stored remotely. Simplicity is a main goal of this project, a goal that contrasts with XML to some extent, but XML may be essential for GUI admin. Central Package Repository === No more looking all over our website for packages. All of them will now be stored in a single repository. Probably still fat16 with 8.3 filenames. Not sure. New Package System == A new package system would use the new central-db to get it's values from. We are interested in making the packages a LOT smarter and making it possible to load them from remote locations. A smart package contains a manifest of all it's variables and all possible values, offering that information to and incorporating those into the central-db. The run-time files that each package uses, the ones we customize nowadays like /etc/dnscache/env/IP, will be generated at boot time in the future, similarly to the way the /etc/rc?.d directories are generated on the fly now. This packaging system will require each package to provide a template of it's dynamic files. Templates are like mad-libs. You get the values out of the db, and once you fill them in, it's funny. GUI Pre-rollout Config == We are thinking it'd be cool, if you wanted to, to download a fat CD of everything LEAF on it, burn the thing, and use it to build yourself a custom LEAF floppy. You'd do this before you rollout that floppy to the LEAF box. You could save your changes. You could upgrade to a new LEAF version seamlessly. We could make the pre-config program a Java GUI, a Python GUI, or a Web/Cgi thing
Re: [leaf-user] Update: Short term LEAF project goals
S Mohan wrote: I'd also suggest a change in lrp packaging by which the modules required for a package to run is bundled with the lrp. Installing the lrp will also insmod the module automatically. A depmod kind of facility will make it easy to use/ configure LEAF. Give me an example please of a package that requires you to go out and find a .o module you need. Fwiw, dependancies are very much a fundamental part of the new package system. If you change, by hand or by script, your ip address for example, the built in dependancy checking triggers all packages that use the ip address to restart, in the correct order, and reread their configs. I just finished seeing monowall and the screenshots are great. It is just what I had in mind and Eric Wolzak has asked for ideas too. The monowall interface encapsulates most requirements. It may do good to invite Michael - the monowall author to participate here. Link to a screenshot? Apart from what has been listed below, the GUI must have a webmin like definition to allow authors to write new package screens easily and confirm to a standard. If this is done, then changing themes will change the look and feel across all packages. Thanks for the comments. One idea was that the package author completely describes all the variables and possible choices, then the new package screen is generated dynamically. Given a program written in Java or Python, which may be preferable because they can access drives and do other secure transactions much easier than a web script ever could, everyone would need to learn those if they wanted to code their own custom new package screens. Because that's not gonna happen, the idea for dynamic config pages seems more appealing. If the package author wants more latitude in design, a highly laudable goal, then I'm not adverse to adding whatever functionality is within reason. The joy here is that I can to tremendously powerful things with Java, in no time and very easily, simply because it is mature. We also need to look at SSL support if web based administration is contemplated. Mohan Java has ssh support built in. The LEAF system requirements are: sshd.lrp. That presents a space issue for any single floppy rollout, our classic format. cheers, matthew --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
S Mohan wrote: I'd also suggest a change in lrp packaging by which the modules required for a package to run is bundled with the lrp. Installing the lrp will also insmod the module automatically. A depmod kind of facility will make it easy to use/ configure LEAF. Give me an example please of a package that requires you to go out and find a .o module you need. pppoatm? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
On Tue, 18 Feb 2003, Matt Schalit wrote: S Mohan wrote: I'd also suggest a change in lrp packaging by which the modules required for a package to run is bundled with the lrp. Installing the lrp will also insmod the module automatically. A depmod kind of facility will make it easy to use/ configure LEAF. Give me an example please of a package that requires you to go out and find a .o module you need. ppp.lrp. The problem with incorporating module dependencies into packages is that modules are supposed to present a standard application programming interface that decouples the application from the hardware. PPP can in fact be run over ethernet, or over standard serial ports, or over special multi-port serial interfaces. Even if you put something in the packaging system that can recognize the absence of a minimum functionality (some type of point to point communication channel), you will still have confusion where the application calls for multiple channel types used in different ways (PPPoE into a serial control channel for an embedded device, for example). I think that in most cases coupling the base user-level package with an application-specific set of kernel modules makes more sense than integrating the two. If you really want idiot-level integration, then fall back on application-specific floppy image-style delivery. Bering's documentation is much more effective in the general case than trying to integrate into packages items that don't belong together in all cases. --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
[EMAIL PROTECTED] wrote: You asked for comments: I long ago created my own database, wherein Thanks for posting your information about the db you created. In our discussions, we've called this a flat databse, meaning that the entire database is a single bash sourceable text file containing name=value pairs and comments. We discussed the costs and benefits of this format at some length, and I encourage you to join the thread on leaf-devel to contribute your thoughts, or maybe just read it and see if you concur with the people who've been researching this for a few months. A single flat file was my initial choice. XT_DEVICE=eth0 XT_IF= 204.001.001.001 XT_MASK=24 IT_DEVICE=wlan0 ROUTERTYPE=tunnel IT_DHCPS=yes A1_DEVICE=eth1 SPOOFING=no etc,etc. (about 80 variables) And a single python function which can be called from a command line as in: /var/www/cgi-bin/xlfixconf.pyXT_GW=204.001.001.254 or from another python program. This is simple. If you import the above, it is all valid bash and variables can be used in all the networking and firewall scripts. It takes a little extra code to build something like ipsec.conf or dhcpd.conf. Yes we think sourcing a file like yours is beneficial. Anyway, the point is its simple to look at and simple to edit and Python or Perl builds a hash table in milliseconds. Any sort of real database technology would be a burdensome complication. A real database would be burdensome, that's true, when you take a first look, and we've agreed to some extent that a complex xml database on the LEAF box is bogus for this very reason. David and Charles are voicing their wish for this whole thing to increase simplicity. But we have not ruled this out, because XML makes it possible to easily maintain a GUI admin. Perhaps you agree with the point I made before that having to modify your front-end gui and back-end api every time a new package comes out with different config is not preferrable to doing all that dynamically. Now. Given an organization like above, with creative use of underlines to create a hierarchy, It would be quite simple to write a 2 way parser bash-variables -- XML. We agree on this, and I offered it as my request. If we use XML, it should also generate a flat file of bash sourcable var=values. I should also mention, there is a subject which rarely mentioned on LEAF, Group Permits. This is where you use netfilter to allow access to subnets and servers and services by groups of ip's and maybe domains. This deserves some db kind of thinking. I've kind of brute forced this stuff so far and haven't designed a decent database yet. But it is worth thinking about in any design. I think Cisco calls thisAccess Lists. Is netfilter a part of shorewall or a seperate .lrp or just part of the main distro? Any command can be described in the database I think. The database is _not_ my specialty ;-) Oh, can't speak for Perl, but after 1.5, Python gets BIG. 1.5 is fine for my purposes. Anyway, size matters. I think you're running python.lrp is that correct? Would you paste in console based python hello world? curious, matt --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Update: Short term LEAF project goals
While I'm not that aware of various options, I think a few modules are mandatory or have to go with some packages. E.g. ipsec.o with ipsec(509).lrp, bridge.o with bridge.lrp, netfilter with tc.lrp etc. I was looking at this. In addition, 90-95% of the users would use a common combination. Dial up connections use PPP over serial ports etc. Such popular combinations can also be packaged to gether. Mohan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeff Newmiller Sent: Wednesday, February 19, 2003 12:27 AM To: Matt Schalit Cc: [EMAIL PROTECTED] Subject: Re: [leaf-user] Update: Short term LEAF project goals On Tue, 18 Feb 2003, Matt Schalit wrote: S Mohan wrote: I'd also suggest a change in lrp packaging by which the modules required for a package to run is bundled with the lrp. Installing the lrp will also insmod the module automatically. A depmod kind of facility will make it easy to use/ configure LEAF. Give me an example please of a package that requires you to go out and find a .o module you need. ppp.lrp. The problem with incorporating module dependencies into packages is that modules are supposed to present a standard application programming interface that decouples the application from the hardware. PPP can in fact be run over ethernet, or over standard serial ports, or over special multi-port serial interfaces. Even if you put something in the packaging system that can recognize the absence of a minimum functionality (some type of point to point communication channel), you will still have confusion where the application calls for multiple channel types used in different ways (PPPoE into a serial control channel for an embedded device, for example). I think that in most cases coupling the base user-level package with an application-specific set of kernel modules makes more sense than integrating the two. If you really want idiot-level integration, then fall back on application-specific floppy image-style delivery. Bering's documentation is much more effective in the general case than trying to integrate into packages items that don't belong together in all cases. --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Update: Short term LEAF project goals
I'm referring to only packaging meaning having within the same lrp. Additionally, the package installer should load all modules that are tarred within the package as they are deemed necessary for the utilities to work. I'm not suggesting that the module be compiled or integrated. Can we do away with manual steps when it is obviously needed. That is all. Sorry if my earlier posts have conveyed otherwise. Mohan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeff Newmiller Sent: Wednesday, February 19, 2003 12:27 AM To: Matt Schalit Cc: [EMAIL PROTECTED] Subject: Re: [leaf-user] Update: Short term LEAF project goals I think that in most cases coupling the base user-level package with an application-specific set of kernel modules makes more sense than integrating the two. If you really want idiot-level integration, then fall back on application-specific floppy image-style delivery. Bering's documentation is much more effective in the general case than trying to integrate into packages items that don't belong together in all cases. --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
S Mohan wrote: While I'm not that aware of various options, I think a few modules are mandatory or have to go with some packages. E.g. ipsec.o with ipsec(509).lrp, bridge.o with bridge.lrp, netfilter with tc.lrp etc. I was looking at this. In addition, 90-95% of the users would use a common combination. Dial up connections use PPP over serial ports etc. Such popular combinations can also be packaged to gether. I rather favor a mechanism whereby package-module dependencies can be expressed in the package. Including kernel modules in .lrp's like ppp, pppoa or shorwall (just to name one) will yield nightmarish results when we try to introduce a new kernel version. -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
On Tuesday 18 February 2003 09:19 pm, Tom Eastep wrote: I rather favor a mechanism whereby package-module dependencies can be expressed in the package. Including kernel modules in .lrp's like ppp, pppoa or shorwall (just to name one) will yield nightmarish results when we try to introduce a new kernel version. -Tom I agree 100% with Tom. Some form of dependancy stating/checking is already on the board when the packaging format gets changed. The last thing you would _ever_ want to do is stick a kernel module within a package. Some packages change themselves to what form of modular dependancy/patching is needed from version to version, Allowing a 'dep check' would allow much easier updating on all fronts. -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
On Tuesday 18 February 2003 12:36 pm, Matt Schalit wrote: Java has ssh support built in. The LEAF system requirements are: sshd.lrp. That presents a space issue for any single floppy rollout, our classic format. Matt, Are lshd, stunnel, or zebedee also feasible options with Java??? -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Update: Short term LEAF project goals
Granted, accepted and think it is better. I did not think of this angle that modules may not keep pace. In some cases, due to sequence of loading, older modules might replace newer ones. Maybe be check while loading using lsmod to see if appropriate/ required module is loaded would be preferable. Mohan -Original Message- From: Tom Eastep [mailto:[EMAIL PROTECTED]] Sent: 19 February 2003 08:49 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [leaf-user] Update: Short term LEAF project goals S Mohan wrote: While I'm not that aware of various options, I think a few modules are mandatory or have to go with some packages. E.g. ipsec.o with ipsec(509).lrp, bridge.o with bridge.lrp, netfilter with tc.lrp etc. I was looking at this. In addition, 90-95% of the users would use a common combination. Dial up connections use PPP over serial ports etc. Such popular combinations can also be packaged to gether. I rather favor a mechanism whereby package-module dependencies can be expressed in the package. Including kernel modules in .lrp's like ppp, pppoa or shorwall (just to name one) will yield nightmarish results when we try to introduce a new kernel version. -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
[leaf-user] Update: Short term LEAF project goals
This is an unofficial message to let folks know what the short term goals are for the LEAF project, the hot topics being developed, just in case you're not monitoring the leaf-devel list. I wasn't asked to write this, but I figured it'd might help a bit. Please toss in your comments if you'd like. More communication is welcome. LEAF is a loose collection of kind people who share a common interest in embedded Linux. There's no top-down organization here, per se, but rather the following ideas are what people are most excited about and working on. They are listed in an order that likely denotes their place in our unoffical roadmap. The point here being that it'd be tough to build a GUI admin system when you know there's a new package system coming out shortly: 1) Central configuration database 2) Central package repository 3) New package system 4) GUI preconfig 5) GUI admin Central Configuartion Database This is a way of storing the variables and values that make your LEAF box unique, like your IP addresses, in one single location and making a new command, perhaps leaf-cdb, that is used to access the db. Values like IP, netmask,and hostname that are common across packages will be listed once. No more entering the same data 5 times across 5 packages! The current idea is to use a stucture similar to the linux /proc set of subdirectories. Another idea is to burp that structure out of an xml database, perhaps stored remotely. Simplicity is a main goal of this project, a goal that contrasts with XML to some extent, but XML may be essential for GUI admin. Central Package Repository === No more looking all over our website for packages. All of them will now be stored in a single repository. Probably still fat16 with 8.3 filenames. Not sure. New Package System == A new package system would use the new central-db to get it's values from. We are interested in making the packages a LOT smarter and making it possible to load them from remote locations. A smart package contains a manifest of all it's variables and all possible values, offering that information to and incorporating those into the central-db. The run-time files that each package uses, the ones we customize nowadays like /etc/dnscache/env/IP, will be generated at boot time in the future, similarly to the way the /etc/rc?.d directories are generated on the fly now. This packaging system will require each package to provide a template of it's dynamic files. Templates are like mad-libs. You get the values out of the db, and once you fill them in, it's funny. GUI Pre-rollout Config == We are thinking it'd be cool, if you wanted to, to download a fat CD of everything LEAF on it, burn the thing, and use it to build yourself a custom LEAF floppy. You'd do this before you rollout that floppy to the LEAF box. You could save your changes. You could upgrade to a new LEAF version seamlessly. We could make the pre-config program a Java GUI, a Python GUI, or a Web/Cgi thing. This is very dependant on new packages and a new central-db. GUI Admin === Everyone likes how weblet can show us information, but can we use it to administer our LEAF boxes? A lot of people would like to do something like that. But weblet/cgi requires a lot of shell scripts on the LEAF box. Plus there are security and space concerns. We are far away from settling anything on this or choosing the best app to use, but I have suggested a Java app rather than a weblet based approach. Python has also been suggested. Now the more capable one makes the GUI, the more it increases exponentially in complexity to build and use. We'll have to make sacrifices and assumptions about how easy this should be for users. Some tough decisions! But, if we used XML as the foundation of our central-db, then a Java or Python app could query that XML and generate the admin pages on the fly. No more changing the GUI because ntpdate added another variable. The GUI would just be written to create the fields and field-value options that the XML database told it to, on the fly. If the ntpdate package starts with a properly written manifest, everything else is automatic! That deserves a tiny w00t w00t. okey naw, matthew --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
Re: [leaf-user] Update: Short term LEAF project goals
On Mon, 2003-02-17 at 10:39, Matt Schalit wrote: This is an unofficial message to let folks know what the short term goals are for the LEAF project, the hot topics being developed, just in case you're not monitoring the leaf-devel list. I wasn't asked to write this, but I figured it'd might help a bit. Please toss in your comments if you'd like. More communication is welcome. Matt, Very nice summary. Very nice indeed. :-) -- Mike Noyes mhnoyes @ users.sourceforge.net http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
RE: [leaf-user] Update: Short term LEAF project goals
I'd also suggest a change in lrp packaging by which the modules required for a package to run is bundled with the lrp. Installing the lrp will also insmod the module automatically. A depmod kind of facility will make it easy to use/ configure LEAF. I just finished seeing monowall and the screenshots are great. It is just what I had in mind and Eric Wolzak has asked for ideas too. The monowall interface encapsulates most requirements. It may do good to invite Michael - the monowall author to participate here. Apart from what has been listed below, the GUI must have a webmin like definition to allow authors to write new package screens easily and confirm to a standard. If this is done, then changing themes will change the look and feel across all packages. We also need to look at SSL support if web based administration is contemplated. Mohan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matt Schalit Sent: Tuesday, February 18, 2003 12:10 AM To: [EMAIL PROTECTED] Subject: [leaf-user] Update: Short term LEAF project goals This is an unofficial message to let folks know what the short term goals are for the LEAF project, the hot topics being developed, just in case you're not monitoring the leaf-devel list. I wasn't asked to write this, but I figured it'd might help a bit. Please toss in your comments if you'd like. More communication is welcome. LEAF is a loose collection of kind people who share a common interest in embedded Linux. There's no top-down organization here, per se, but rather the following ideas are what people are most excited about and working on. They are listed in an order that likely denotes their place in our unoffical roadmap. The point here being that it'd be tough to build a GUI admin system when you know there's a new package system coming out shortly: 1) Central configuration database 2) Central package repository 3) New package system 4) GUI preconfig 5) GUI admin Central Configuartion Database This is a way of storing the variables and values that make your LEAF box unique, like your IP addresses, in one single location and making a new command, perhaps leaf-cdb, that is used to access the db. Values like IP, netmask,and hostname that are common across packages will be listed once. No more entering the same data 5 times across 5 packages! The current idea is to use a stucture similar to the linux /proc set of subdirectories. Another idea is to burp that structure out of an xml database, perhaps stored remotely. Simplicity is a main goal of this project, a goal that contrasts with XML to some extent, but XML may be essential for GUI admin. Central Package Repository === No more looking all over our website for packages. All of them will now be stored in a single repository. Probably still fat16 with 8.3 filenames. Not sure. New Package System == A new package system would use the new central-db to get it's values from. We are interested in making the packages a LOT smarter and making it possible to load them from remote locations. A smart package contains a manifest of all it's variables and all possible values, offering that information to and incorporating those into the central-db. The run-time files that each package uses, the ones we customize nowadays like /etc/dnscache/env/IP, will be generated at boot time in the future, similarly to the way the /etc/rc?.d directories are generated on the fly now. This packaging system will require each package to provide a template of it's dynamic files. Templates are like mad-libs. You get the values out of the db, and once you fill them in, it's funny. GUI Pre-rollout Config == We are thinking it'd be cool, if you wanted to, to download a fat CD of everything LEAF on it, burn the thing, and use it to build yourself a custom LEAF floppy. You'd do this before you rollout that floppy to the LEAF box. You could save your changes. You could upgrade to a new LEAF version seamlessly. We could make the pre-config program a Java GUI, a Python GUI, or a Web/Cgi thing. This is very dependant on new packages and a new central-db. GUI Admin === Everyone likes how weblet can show us information, but can we use it to administer our LEAF boxes? A lot of people would like to do something like that. But weblet/cgi requires a lot of shell scripts on the LEAF box. Plus there are security and space concerns. We are far away from settling anything on this or choosing the best app to use, but I have suggested a Java app rather than a weblet based approach. Python has also been suggested. Now the more capable one makes the GUI, the more it increases exponentially in complexity to build and use. We'll have to make sacrifices and assumptions about how easy this should be for users. Some tough decisions! But, if we used XML as the foundation
