Re: [leaf-devel] [Shorewall-devel] Future of Shorewall
Tom Eastep wrote: Natanael Copa wrote: Have you thought of lua? should give you better performance than perl and would still be small enough for embedded. I can't say I have been looking at the shorewall code, but lua is very table oriented, which might be good for your table based config files. I suspect that the parser part of Shorewall might be difficult to write entirely in LUA (although I've only browsed the reference manual). Also, LUA appears to be a language that may only be embedded in C -- it does not stand on its own. So what you end up with is a C program that uses a smart library. Tom, Since I was mentioned in this thread already, I'll give my $0.02. Feel free to send to /dev/null A) The Lua manual is really bad. LuaForge is a mess. I really needed Programming in Lua to make sense of the language (Ver 1 is online http://www.lua.org/pil/ Version 2 is only available in dead-tree format and was worth the cost. B) The Lua parser is surprisingly good for regex type stuff. Its just /different/ from the other standard regexes. C) You are right about Lua wanting to be embedded in C (or some other language) - imagine however, a tiny C wrapper that forked iptables-restore[1] once and then used a lua parser to send all the data to that one process instead of forking iptables 1000's of times. The C code would be minimal, just enough to instantiate a Lua VM. D) Shorewall is YOUR fun project... so none of the above need apply. ;-) [1] - Believe it or not, http://www.netfilter.org/documentation/FAQ/netfilter-faq-4.html#ss4.5 says this is the official way to program iptables without using system() calls. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] webconf backup packages
Bering uClibc team, Eric alerted me to the broken backup packages webconf. (sorry) While looking at it, I have a quick question re the new backup system. Should it be possible to backup moddb/configdb to any of the destinations in /var/lib/lrpkg/pkgpath.disks, or does it now just use the first entry? The reason I ask is I can't find how to specify a package destination when saving config or backup modules in lrcfg. Thanks! - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] webconf backup packages
Hi Eric, I just posted the source and binary versions of webconf.lrp and webconf.lwp. Your changes to lrcfg.back.cgi were heroic. I decided to shortcut the whole thing and make webconf (backup, at least) work with Bering uClibc *only*. (Since Bering uClibc is the only one being updated at this point, the above statement should only affect Bering uClibc installations.) lrcfg.back.cgi makes a backup of the configdb and moddb; rather than go through the multiple layers of cruft in lrcfg.back.script, it uses apkg -o and apkg -d directly. It uses /var/lib/lrpkg/backup to find the names of the configdb and moddb, so you should be able to backup to the primary backup device with whatever name is set in the backup file. All of that simplifies the interface considerably... Now its just 2 checkboxes and a backup button. ;-) I did a cvs update this morning, so I *think* i got your change from earlier this morning...If I missed anything else, please let me know. I have a new webconf source tarball ready to go when you all think this is good enough for the buildconfig. Give the word and I'll upload it and make the buildconfig changes necessary to build webconf.lrp. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New LEAF branch?
Hi Eric, --- Eric Spakman [EMAIL PROTECTED] wrote: snip Yes you do lose, having the configs in separate files but you solve alot of other things. There is a very big problem with seperating the configs from the packages itself. You loose the consistency between the two. For example, if you update shorewall from version 2.x to 3.x (where the format of config files change), shorewall won't work anymore. Also with other programs config files, formats and items change between releases. While Tom posted a comment to your specific example, your point is well taken. Even if /shorewall/ doesn't have this problem, there are cases where other things do. From someone who's had to address this very issue with several hundred routers, the stupid-simple answer was to extend apkg to look for a /var/lib/lrpkg/pkg.upgrade shell script. Its kinda like a pre-install post-install script from other package managers. After upgrading a config file, it was tagged with the version of the current .lrp (e.g. #apkg updated this config file to version 2.1.3); the pkg.upgrade script then looks for the version x.x.x tag next reboot and updates or not as needed. At first it sounds scary, but In real-life, I've seen some cases where configs are 3 rev-levels back - they get upgraded on the fly and work, and the local tech never remembered to save changes to disk ;-) Your point is well taken, but a simple lrp [pre|post]-[upgrade|install|remove] extension might solve much of that problem. An other, maybe less important problem is that when you try a package the config file of that package will polute the local repository of config files (after you delete the package, the config files are still present) while with config inside a package this won't be the case. Agreed. sfic is a direct result from the comments received from the itsy configuration management system proposal. sfic allows for operations on a subset of the entire database, rather than the entire database as a whole. So it should be possible to maintain a lists of what should be installed, what is installed, and what changed from what would have been installed if I just exploded all my .lrps on a ramdisk. Then its just the problem of allowing the administrator to figure out what he wants to do with all the files on his system. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] lwp (webconf) packages
On Wednesday 15 March 2006 17:19, Mike Noyes wrote: On Wed, 2006-03-15 at 12:50, Nathan Angelacos wrote: On Wednesday 15 March 2006 15:03, Eric Spakman wrote: Who is going to put the available lwp packages in leaf/bin/config/webconf? Just a question. I can take care of the ones that are in my devel area. (That would be all of them, AFAIK) Eric Nathan, I just gave write access in our new bin directory to the webconf team. Please let me know if you require further changes. Thanks. avail|arneb, dorus, espakman, hejl, hun, lfcorreia, nangel|bin/config/webconf Thanks Mike. I committed the existing lwp's to the bin area. Eric, you should be able to change your build script at your convenience. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] lwp (webconf) packages
Mike, I fully recognize that nobody else is stepping up as Documentation/Website Admin, and we all appreciate the job you are doing. I hope you'll take these as comments of what one person sees could make things a little better. Its just my perspective - and you are more than welcome to send this to /dev/null. I won't be offended. :-) On Wednesday 15 March 2006 11:02, Mike Noyes wrote: To work on a project, then have it stored under someone else's name, buried in a cvs archive with no link to the homepage doesn't have the same reward as working on OpenWRT, posting your ipkg and letting the world see it. This seems directed at our cvs structure, website, and indirectly at me. I'll say this again,Our branch sites are under the control of their lead developer. The only two that are under my direct supervision are our hub and devel branch. Sorry if you read it that way, I wasn't trying to direct anything, just expressing the view as a lowly developer. I am not a member of the bering-uClibc team, the Bering team, or any other branch. I'm just a developer. Webconf is a web ui that works in the bering branch and the bering-uclibc branch, and with very little work would work in the oxygen branch. A lwp is just shell script that would work on a OpenWRT linksys router - not even LEAF. (really!) Since its just a component, it doesn't belong in any specific branch. So where does it go? Where it goes doesn't matter as much as where the end user has to look to find it. Right now the end-user has to play hunt-the-lwp through each developer's tree. I've got no issues with the CVS structure or you, but it would be nice to get some of the presentation hurdles out of the way to make it easier for the average non-affiliated developer to publicly contribute to the project. Please understand that I'm using webconf as an example, I'm *NOT* hoping to get webconf promoted to branch level or anything... The above statements could apply equally to a lrp - ipkg converter, or better lrp package system, or some other really cool idea some developer has. snip Mike, please don't take this as personal criticism against the leaf website - we all appreciate what you ARE able to do, I'm just making an honest observation, based on the early interest I had seen in the web interface, and what had happened to many of the developers. Understood. I make mistakes, and all I can do is try to learn from them. If I had it to do over again, I would have never implemented application/xhtml+xml on a working phpWebSite without tidylib available. I hope installing mediawiki will alleviate most of these issues. It'll give everyone a place for content. Greg Morgan is familiar with what mediawiki can do, and can answer questions better than I can. Mediawiki would be a good thing IMHO. Imagine: when some weirdo comes along with his web configuration ui that doesn't quite fit anywhere in the structure of things, park him somewhere in the wiki, let him document (or not) to his heart's content, and let Google figure out if its worth advertising to the world. This would also allow others to easily contribute to the web site content, and you can let the bering-uClibc folks figure out how they want to get their xml sources imported into mediawiki. Sounds like a win-win-win. Cheers --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] lwp (webconf) packages
On Wednesday 15 March 2006 12:48, Mike Noyes wrote: Also it would be nice if the contents of Nathan's CVS space could be moved to a more generic place (I think we need Kp for this). This requires opening a SR with the SF staff. Any one of our project admins can do this. Clarfication - webconf (the core) is already in leaf/src/config/webconf Mike already did that for us some time ago. (Thanks mike!!!) The docs weren't moved to the generic config part of the cvs tree because I had hoped the bering-uClibc would adopt them. They did recently, so I guess the only thing left is for someone to the web pages I referred to earlier to the buc guides instead of my devel tree. Then I'll be happy to kill my devel tree. If nobody does it, I'll also be happy to keep my devel tree. Doesn't matter either way. :-) What's NOT in leaf/src/config/webconf is all of the .lwp's (anything beyond webconf.lrp / webconf.lwp)Perhaps there's a place for them in the same spot. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] lwp (webconf) packages
On Wednesday 15 March 2006 13:40, Mike Noyes wrote: On Wed, 2006-03-15 at 10:09, Nathan Angelacos wrote: What's NOT in leaf/src/config/webconf is all of the .lwp's (anything beyond webconf.lrp / webconf.lwp)Perhaps there's a place for them in the same spot. Nathan, How about a new directory in src/config called lwp? We can open that directories write access to all of our project developers, or restrict it as desired. I'm ok with it; although it should probably be combined with Eric's suggestion of leaf/bin/config/webconf That way a developer could also upload a binary lwp (or lrp, yes, there are webconf lrps) If anyone has suggestions for what you are looking for in webconf developers, I'll be happy to collect the ideas and draft a request for assistance announcement. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Idea for configuration management system
I have posted a pdf containing an idea for a configuration management system, and would appreciate any extra peer review cycles you folks could spare: http://www.tetrasec.net/data/itsyconfigurationmanagementsystem.pdf The basic concept is to take configruation management of LEAF routers to the enterprise level, while at the same time preserving the SOHO style of operation for routers that aren't part of an enterprise. By making configuration management its own package (its own lrp), it might make it easier to migrate to another package manager, such as Ipkg. Or, then again, its possible I've just completely lost it. The doc mentions ipkg, mainly because of wishful thinking; but it should be entirely possible to implement this system with the current .lrp based packages. (Translation - I don't want to start a holy war over package managers! This is just about /configuration/ management smile) For the Bering-uClibc folks - a version control client will be heavy. The core system should be implemented as shell scripts, so the base system still fits on floppy; The svn/cvs client would still be an add on for enterprise routers. Think [ -e /bin/cvs ] use cvs Thanks! --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Webconf - differences in source for Bering-uClibc vs binary .lrp
This is just a post to document some differences in webconf.lrp, depending on where it comes from. The short version is: If you use Bering-uClibc, use the webconf.lrp included with Bering-uClibc. (e.g. you don't need to do anything, and can ignore the rest of this message.) In the cvs tree, leaf/devel/nangel/webconf/lrp/webconf.lrp is the version that one gets if someone follows the twisty maze of web links to download webconf.lrp on its own. This version contains var/lib/lrpkg/webconf.exclude.list; this file excludes: etc/webconf/* var/webconf/* The Bering-uClibc team has decided that those directories should be owned by the mhttp(s) package, due to other file ownership issues. This means a webconf.lrp built with buildtool.pl for a Bering-uClibc will (correctly) *not* contain webconf.exclude.list. However, removing the exclude.list from the binary .lrp file referenced above may break backups on classic bering. After a discussion with KP Kirchdoerfer, the binary webconf.lrp in leaf/devel/nangel/webconf/lrp/webconf.lrp will continue to have the webconf.exclude.list. The offical source code for all versions will continue to be leaf/src/config/webconf. In the past, whenever leaf/src/config/webconf changes, I committed a webconf-[date].tar.gz in the Bering-uClibc source tree, and updated buildtool.* to point to the new webconf source tarball. I will continue to do so, until told otherwise by the Bering-uClibc team. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Repository for webconf plugins
Mike, I would like write access (I just tried to commit something and just got an access denied message.) I think you could also add the core Bering-uClib core team as well. Thanks. On Friday 22 April 2005 10:55, Mike Noyes wrote: Nathan, I had the SF staff move webconfig source. Please let me know who you wish to have write access. mv /cvsroot/l/le/leaf/devel/nangel/webconf/src /cvsroot/l/le/leaf/src/config/webconf --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Repository for webconf plugins
On Thursday 12 May 2005 11:10, Mike Noyes wrote: On Thu, 2005-05-12 at 05:43, Nathan Angelacos wrote: I would like write access (I just tried to commit something and just got an access denied message.) I think you could also add the core Bering-uClib core team as well. Nathan, Done. Please let me know if you have any problems. Mike, Good morning! I can confirm it worked fine for me. Thanks. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Webconf logfiles.cgi can now sort shorewall report by column
(I'm including this only to the developer list since it is probably more a developer issue.) Eric House submitted a patch to logfiles.cgi that allows the pretty-formatted shorewall logs to be sorted by any column (nice!) I committed everything to CVS today, including a new webconf.lrp, so its available here: http://leaf-project.org/devel/index.php?module=pagemasterPAGE_user_op=view_pagePAGE_id=91 It will also automatically appear in the next Bering-uClibc beta. Here's his comment on some of the limitations: * Does numerical sorts correctly. For some reason, alphabetical sorts seem to be reversed sometimes. Anyway, I think this is good enough. What I still miss from weblet is a simple page showing *how many* attempts have been made per port and per host. In practice I usually only want to see the details after I know that a particular host or port is showing up a lot. Anyway, I hope this is useful. I still don't know if it exceeds the capacity of the typical 16M LEAF machine. I think the alpha reverse has to do with busybox sort. The idea for shorewall reporting is great, but its shorewall specific. It sounds like a great idea for a shorwall.lwp. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93alloc_id281op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Repository for webconf plugins
Mike, There are two different things in the present webconf cvs repository: Source code for the core; and I assume that it could go in config (or stay under devel/nangel) binary lrps lwps; and for the binary packaged versions, K.-P. makes a good point - the finished packaged stuff should go wherever other finished packaged stuff goes. Whatever the group thinks is best is fine with me, but it would be nice to have at least the binary packages in an area that others can update. What do you think of K.-P.'s suggestion? (nolibc) - at least for the lwp's On Wednesday 06 April 2005 17:08, K.-P. Kirchdörfer wrote: Hi Nathan, be careful with moving - that's a good place for beta's and new developements... I'd suggest a lwp reository in nolibc or something like that. kp Am Mittwoch, 6. April 2005 23:02 schrieb Nathan Angelacos: Mike, I'm all for anything that lets others share in development and removes me as the bottleneck. :-) Your suggestion sounds great. Thanks! The only thing is when it is moved, the webconf page will need to be updated to link to the moved repository. On Tuesday 05 April 2005 20:19, Mike Noyes wrote: On Tue, 2005-04-05 at 16:07, Nathan Angelacos wrote: I will be happy to post your webconf plugins in with the existing plugins for you. (Currently they are stored in my leaf devel cvs tree.) If you write a webconf plugin and would rather keep it somewhere else, thats fine too - if you drop me a note I'll put a pointer in the cvs tree giving the address where people can find your plugin. If there is enough activity, some other more permanent arrangement can be made, but at least this should help to get things started. Nathan, If you'd like, I can open a SR with the SF staff to move webconf. http://cvs.sourceforge.net/viewcvs.py/leaf/devel/nangel/webconf http://cvs.sourceforge.net/viewcvs.py/leaf/src/config/ --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel --- 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://ads.osdn.com/?ad_ide95alloc_id396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Repository for webconf plugins
Thanks Mike, Just to make things completely confusing... webconf.lrp is a bunch of shell scripts plus 2 programs compiled for bering-uclibc. So there /is/ a dependency there. However, there are plugins (lwp's) that contain /just/ the 2 binaries. (E.g. Erich Titl's wc207.lwp. It makes webconf.lrp work on his glibc 2.0.7 system.) The plugins overwrite the library specific binaries so that the same shell scripts (in webconf.lrp) can be used with any library. Soo... 1. Does webconf.lrp go in nolibc, and the library specific plugins (wc207.lwp) go in the appropriate directories? 2. Does webconf.lrp and all of the libary specific plugins (wc207.lwp) go in nolibc, since the major part of webconf.lrp is nolibc, and the plugins are expected to go with it?(I would lean toward this, personally, but it does violate nolibc by definition.) 3. REMOVE the uclibc binaries from webconf.lrp and make EVERYONE choose a library specific plugin? (Probably architecturally correct, but it will be a mess trying to support - I downloaded webconf.lrp and it doesn't work... You have to download your appropriate plugin. ... Which one? there are lots of files in the plugin directory... etc. 4. Leave webconf where it is and wait until the move to FRS Sandbox? 5. Other? This problem /could/ happen with other plugins - Typically a plugin will just be shell code (nolibc), but there's nothing to prevent someone from including a binary in the plugin. On Thursday 07 April 2005 10:31, Mike Noyes wrote: On Thu, 2005-04-07 at 04:55, Nathan Angelacos wrote: There are two different things in the present webconf cvs repository: Source code for the core; and I assume that it could go in config (or stay under devel/nangel) binary lrps lwps; and for the binary packaged versions, K.-P. makes a good point - the finished packaged stuff should go wherever other finished packaged stuff goes. Whatever the group thinks is best is fine with me, but it would be nice to have at least the binary packages in an area that others can update. What do you think of K.-P.'s suggestion? (nolibc) - at least for the lwp's Nathan The source code should go in src/config/, and HOWTO belongs in doc/howto/. The binary packages that aren't dependent on a library go in bin/nolibc/. Note: Our whole bin/ cvs module will probably move to the new SF FRS SandBox. Please let me know which directories/files you want moved. Thanks. --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Repository for webconf plugins
Mike, I'm all for anything that lets others share in development and removes me as the bottleneck. :-) Your suggestion sounds great. Thanks! The only thing is when it is moved, the webconf page will need to be updated to link to the moved repository. On Tuesday 05 April 2005 20:19, Mike Noyes wrote: On Tue, 2005-04-05 at 16:07, Nathan Angelacos wrote: I will be happy to post your webconf plugins in with the existing plugins for you. (Currently they are stored in my leaf devel cvs tree.) If you write a webconf plugin and would rather keep it somewhere else, thats fine too - if you drop me a note I'll put a pointer in the cvs tree giving the address where people can find your plugin. If there is enough activity, some other more permanent arrangement can be made, but at least this should help to get things started. Nathan, If you'd like, I can open a SR with the SF staff to move webconf. http://cvs.sourceforge.net/viewcvs.py/leaf/devel/nangel/webconf http://cvs.sourceforge.net/viewcvs.py/leaf/src/config/ --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Repository for webconf plugins
I will be happy to post your webconf plugins in with the existing plugins for you. (Currently they are stored in my leaf devel cvs tree.) If you write a webconf plugin and would rather keep it somewhere else, thats fine too - if you drop me a note I'll put a pointer in the cvs tree giving the address where people can find your plugin. If there is enough activity, some other more permanent arrangement can be made, but at least this should help to get things started. --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: Fw: [leaf-devel] (Fwd) Re: Bering Lead?
On Monday 04 April 2005 10:49, Andrea Galmacci - awd wrote: Just to give continuity to my previous announcement, this is to confirm my committment to port my scripts collection for Shorewall (already published as a tarball for 'standard' distros that could use apache + sudo) under webconf - that I consider very good indeed having solved one of the most difficult aspects for web management: form data/file upload handling. Woo hoo!!! Andrea, you got the point of webconf exactly. Or more precisely, haserl - it does the heavy-lifting of form data/file upload parsing, while trying to stay out of the way of the .cgi. Webconf is a framework to demonstrate that, but I don't claim it to be the end all - it can certainly be improved. As an example, long time ago Eric Spakman suggested a generic interface to allow pull-down menus, context-sensitive text-boxes that know how to parse and display a generic .conf file. It didn't seem possible at the time - but after looking at the caudium web-server config engine - I think just that thing /is/ possible, and without python. ;-) So as you work on the port, please feel free to suggest improvements to to either the haserl interpreter or the webconf framework. --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Newbie uClibc Buildtool question
Since malloc is a pretty common function... is there a standard trick to getting the ./configure script to work correctly? I'm a newbie at autoconf too - so if there's a test I should put there, that's fine... You could try removing AC_FUNC_MALLOC in the configure.ac script. -- Thanks Natanael, that seems to fix it. --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Newbie uClibc Buildtool question
Hi list, This is mainly for the uClibc folks, and its really a uClibc related question, but since I'm using buildtool.pl, I'll ask here first. I'm trying to compile haserl in the buildtool.pl environment. (K.-P. gave me working buildtool.mk cfg files, so that part works.) buildtool.pl build haserl fails with this error: /root/cvs/src/bering-uclibc/buildtool/staging/usr/bin/gcc -g -O2 -Wall -o haserl haserl.o haserl.o(.text+0x165): In function `myputenv': /root/cvs/src/bering-uclibc/buildtool/source/haserl/haserl-0.7.3/src/haserl.c:160: undefined reference to `rpl_malloc' haserl.o(.text+0x4a7): In function `ReadCGIPOSTValues': /root/cvs/src/bering-uclibc/buildtool/source/haserl/haserl-0.7.3/src/haserl.c:324: undefined reference to `rpl_malloc' haserl.o(.text+0x723): In function `ReadMimeEncodedInput': /root/cvs/src/bering-uclibc/buildtool/source/haserl/haserl-0.7.3/src/haserl.c:419: undefined reference to `rpl_malloc' haserl.o(.text+0xdbb): In function `PushTokenChain': /root/cvs/src/bering-uclibc/buildtool/source/haserl/haserl-0.7.3/src/haserl.c:692: undefined reference to `rpl_malloc' collect2: ld returned 1 exit status The reason is that the configure script thinks that it doesn't have a glibc compatible malloc, and so the src/Makefile contains: LIBOBJS = malloc$U.o LTLIBOBJS = malloc$U.lo (and the src/config.h contains #define malloc rpl_malloc ) If I uncomment all that junk out, then haserl compiles in the uClibc buildtool environment. My previous builds of haserl have been from a buildfs from Erik Anderson's toolkit, so I've never had this problem. Since malloc is a pretty common function... is there a standard trick to getting the ./configure script to work correctly? I'm a newbie at autoconf too - so if there's a test I should put there, that's fine... Thanks! --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] (no subject)
On Friday 17 December 2004 10:06, Erich Titl wrote: Nathan, Roger Do you believe there is a way to synchronize this work, so we won't do parallel stuff and avoid portability issues. cheers Erich Hi Erich, I guess we need to communicate clearly through this list, but do you have any other suggestions on how we do that? Thanks! --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Webconf Development
Hi Roger, On Thursday 16 December 2004 10:16, Roger E McClurg wrote: thought that I might be able to help in developing LWPs. I was wondering who was currently working on LWPs and which ones they are working on. If there is a particular LWP that needs attacking, I'd be glad to give it a shot. Please let me know what you think. I think that's great! I don't know of any particular packages that are being worked on. There are people working on packages, but it seems like they are doing them for specific niches. I have some work done on the interfaces file, but other than that, I don't know of any other packages that have any work done on them. If you wat to be a developer, Mike Noyes can set you up. If all you want is a place to put your creations, I'll be happy to host your work under the webconf cvs tree until things with the new website settle down again. --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] webconf
Erich, Thanks for your comments. On Wednesday 08 December 2004 14:56, Erich Titl wrote: Nathan I am trying to upgrade webconf to the latest beta and to my environment. A few questions arise. - The left menu bar in my case has a Networking and a System entry along with entries for root.net and root.sys. It appears that the menu entries are generated by looking into the /var/lib/lrpkg directory for *.conf files. Is there a way to restrict them to specific entries only? What you are looking at is the expert menu builder (more on why later on), and the menu is built in menubuilder.sh. Right now it is how you describe it - For the expert menu set, there's no way to do finer grain control. Long term, I'd like to have some way to have a field installed script to build the menu, but I'm not sure how to do that. So for now, the answer is you would have to write a new menubuilder.sh I'd be happy for help! :-) - I have set the GUI style to basic but it appears there is no link to the expert style, although there is a /etc/webconf/webconf-expert file. I answered a similar question on leaf-user and should have cross-posted. Sorry.. It sounds like you have webonf.lrp and webconf.lwp installed, but not any of the basic lwp's. Depending on which .lwp's you loaded, webconf is smart enough to only show the switch to link if you have a different menuset to switch to. The pages in the base webconf.lrp belong to the all menuset - they get absorbed into whatever menuset you are currently viewing. If you load only webconf.lrp, then you have neither Basic or Expert - but just the all set. There's no menuset to switch to, so the link isn't shown. The pages in the webconf.lwp belong to the expert menuset. So if you load webconf.lrp + webconf.lwp, then you will have the Expert menu set, but not the Basic menuset. In this case, only the Expert menuset (with the abosorbed all pages) is available. There is still nothing to switch to, and the link isn't shown. To get the Expert/Basic switch, you must load lwp's that include more than one menuset. Currently, the Basic menus are in dropbear.lwp and keyboard.lwp. So the minimum set to load to see the swich to item in the menu is: webconf.lrp + webconf.lwp + dropbear.lwp [or] keyboard.lwp In your case, even though the /var/webconf/webconf.conf says to load basic, expert is the only one you have available, so expert is what you see. Webconf's menu management tries to do the right thing, but it seems to be causing confusion... Cheers --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Suggestion to break up webconf.lrp into lrp and lwp parts
On Tuesday 30 November 2004 08:07, Erich Titl wrote: Nathan Would you consider to split off haserl and pwcrypt from webconf.lrp. IMHO this would make webconf extremely portable. Erich, My first reaction was but that's what makes it go! Its like removing pluto from ipsec.lrp or pppd from ppp.lrp! But I think I understand your concerns, - you'd like to use webconf.lrp on another platform without having to repackage webconf.lrp I wonder if the lwp mechanism would work: What if you create a wc-207.lwp with haserl and pwcrypt for glibc 2.0.7, and then add wc-207 to the LWP variable in /etc/webconf/webconf.conf? That means the webconf init script would pull in the correct haserl and pwcrypt binaries for your platform. Would that work? --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Suggestion to break up webconf.lrp into lrp and lwp parts
On Tuesday 16 November 2004 04:06, Luis.F.Correia wrote: To make webconf a full weblet replacement, there are some things to enhance: - add 'pretty shorewall logs' The version in CVS now has an attempt at parsing the shorewall logs. My initial reaction was pretty firewall formatting belongs in shorwall.lwp, not in basic webconf But... I'm not opposed to the idea /that/ much. In this version, parsing of the shorewall logs is done via a sed script. There's a new column called Formatted that shows the parsed version of the log. I guess if there's pretty formatting to be done for other logs, it could go in that column. (parsed ipsec logs, anyone?) Let me know what you think. If most think the original parsefw belongs in webconf.lrp, then I'll put it in. - simplify log file viewing by not opening a separate window Done. Enjoy! --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-user] Webconf.lrp Beta 3 available
Beta 3 of webconf.lrp for Bering-uClibc is now available. This version splits out the weblet functions from extra plugins. http://cvs.sourceforge.net/viewcvs.py/leaf/devel/nangel/webconf/lrp/webconf.lrp contains only weblet-like monitoring functions, plus tools to back up the modules. The pretty shorewall logs feature is now included in the logfiles.cgi. If its not good enough, or if there are other things that are missing, please let me know. For the expert menu set, you should also download the webconf plugin: http://cvs.sourceforge.net/viewcvs.py/leaf/devel/nangel/webconf/lrp/webconf.lwp The keyboard, dropbear plugins are now also separate plugins, available at the same location above. --- If you have installed a previous version of the beta, you can try this to use the new one without rebooting: #cd / #rm -rf /var/webconf #rm /etc/init.d/webconf #rm /var/lib/lrpkg/webconf* #rm /etc/webconf/* copy the new webconf.lrp to your boot device, and while it is still mounted, install the new one: #cd / #tar zxvf mountpoint of your boot media/webconf.lrp #umount mountpoint of your boot media To install the plugin, copy the webconf.lwp to your boot media and run: /etc/init.d/webconf restart Cheers --- 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-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-devel] Suggestion to break up webconf.lrp into lrp and lwp parts
On Tuesday 16 November 2004 04:06, Luis.F.Correia wrote: To make webconf a full weblet replacement, there are some things to enhance: - add 'pretty shorewall logs' You mean the table format (parsefw)? or is there more? - simplify log file viewing by not opening a separate window I was surprised this didn't get mentioned long before this. I'll fix it soon. Opinions may differ from mine ;) I think silence is agreement, right? Thanks for your comments! --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Suggestion to break up webconf.lrp into lrp and lwp parts
Thanks for all the positive feedback on webconf so far. There is a suggestion that webconf.lrp (core) be just a weblet replacement, and the current expert menu set be moved into webconf.lwp. The reason is situations where an admin wants to give a customer read-only rights to web pages for monitoring; but the customer shouldn't have access to fix [pronounced: break] the installed router. This makes sense to me; it means webconf.lrp is the replacement for weblet; webconf.lwp is the value-add for most do-it-yourself SOHO users; and extra .lwp's add further functionality. Here's a proposed breakup of the existing webconf.lrp (beta 2) keyboard.lwp - keyboard.cgi (basic menu set) dropbear.lwp - dropbear.cgi (basic menu set) webconf.lwp - lrcfg.cgi (expert configuration pages) - lrcfg.pkgdisks.cgi (Destinations) - leafcfg.cgi (Edit leaf.cfg ) webconf.lrp - (all the framework, lib, css, etc) - connection-info.cgi ( Active Connections) - general-info.cgi (General Health) - logfiles.cgi (Log Files) - lrcfg.back.cgi (Backup Packages) - wc-passwd.cgi (Webconf password) lrcfg.back.cgi is in the core so exra .lwp's will be able to save their changes: If the admin installs a nice interface to editing the dansguardian blacklists (danguard.lwp), he will want to let the customer save the changes to the boot media. In this example, the /etc/init.d/webconf LWP would be: LWP=danguard. The customer gets to look at general health, save the packages that are installed, and gets to play with dansguardian. Nothing else. [Disclaimer: danguard.lwp does not exist at this time... volunteers welcome] If anyone sees a reason NOT to do as described above, please let me know. Thanks! --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Webconf.lrp Beta 2 available
An updated webconf.lrp for Bering-uClibc is now available at: http://cvs.sourceforge.net/viewcvs.py/leaf/devel/nangel/webconf/lrp/webconf.lrp This version has the following new features: +The mini_httpd web server no longer needs to be root (you can now use the default sh-httpd user) +The problem with the shorewall configuration page taking 1-2 minutes to load has been fixed. +New links at the bottom of the page for top and home +webconf now comes with an /etc/init.d script that will look for packagename.lwp files on the boot media for all packages loaded; It will install these files if found. The init script can be further configured via the /etc/webconf/webconf.conf file. (This makes it possible for 3rd party plugins to be loaded automatically) +A number of typographical errors were fixed. --- Updated Installation instructions are here: http://cvs.sourceforge.net/viewcvs.py/leaf/devel/nangel/webconf/doc/webconf-configuration.html A Revised Developer's Guide is here: http://cvs.sourceforge.net/viewcvs.py/leaf/devel/nangel/webconf/doc/webconf-howto.html --- Note: It is expected that this will be the last version with dropbear and keyboard basic plugins built into the base webconf. Future versions of webconf.lrp will most likely have dropbear and keyboard as separate plugin packages. --- For developers, please review the new Developer's Guide. There are some significant changes to this release from a developer perspective. +The haserl cgi interpeter can now drop permissions - making it possible to run cgi's as a less-privledged user. (security enhancement) +The haser cgi interpeter now forks a single sub-shell, and environment variables now survive through the life of the .cgi (Thanks to Arne Bernin for providing suggestions and help for this enhancement.) +Leaf Webconf Plugins now have their own package type (.lwp) +The .webconf files were moved from /var/lib/lrpkg to /etc/webconf -- --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] web-based configuration beta available
On Monday 08 November 2004 18:05, Erich Titl wrote: I ported haserl to glibc 2.0.7, a few mods were needed to make it compile Thanks! I posted your fixes on sourceforge - the new release is 0.7.2 What is the reason for pwcrypt as opposed to htpasswd from mini-httpd? BTW... if you want to port this to glibc-2.0.7, just run unzip on pwcrypt. The c-source is appended to the binary as a (pk)zip file. --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Webconf package name
--- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Webconf package name
--- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Webconf package name
--- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Webconf package name
To allow third-party plugins for webconf, I would like to propose the following: webconf plugins have the name LWP (Leaf [Webconf | Web] [Plugin | Package]) The format is a gzipped tar archive with /var/webconf/www/*.cgi /var/webconf/conf/*.webconf For instance, the dropbear.lwp could contain /var/webconf/www/dropbear.cgi /var/webconf/conf/dropbear.webconf A /etc/init.d/webconf script could then scan the package disks for LWP files and install them at startup. For flexibility, I'd like to support selecting which webconf's one loads. For instance, if booting from a floppy/CD combination, it may not be desireable to load ALL the .lwp's from the CD. The proposal is to add an optional LWP= directive to leaf.cfg, just like LRP=; If LWP is defined in leaf.cfg, then that is the list of web plugins to install. If LWP is not defined, then the default LWP would be $LRP. (To set some sane defaults.) The packagename[:R|r|F|f] format would be supported. (Like the LRP= format) The LWP format is for plugins that don't need to save state or have configuration files. For plugins that need to save state, the LRP format can continue to be used. Since this extends the LEAF.CFG file format, and introduces a new extension (LWP), I'm interested in knowing if anyone has problems with this proposal. Thanks! --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] web-based configuration beta available
A web-based configuration package for Bering-uClibc is available at: http://cvs.sourceforge.net/viewcvs.py/leaf/devel/nangel/webconf/lrp/webconf.lrp This package provides the monitoring functions of weblet and adds web-based tools to perform all of the steps found in the various installation and user's guides. In other words, you can use a web interface to edit all the configuration files, back up packages, and edit the leaf.cfg boot configuration file. This should be considered beta-quality, and is targeted at experienced users. The webconf framework is designed to allow developers to seamlessly add their own plugins into the menu structure. Two plugin modules (one for dropbear ssh and one for keyboard selection) are included in the basic interface to demonstrate what can be done with the webconf framework. It is hoped that this work provides a starting point to develop a web interface to make it easier for users less experienced with Linux to be able configure a LEAF router. As with other SOHO router style web interfaces, the focus is on functionality rather than security - so it is not recommended that the web interface be accessible from the Internet side of your router. In default Bering-uClibc distributions, the Shorewall rules are pre-configured this way. Installation instructions are here: http://cvs.sourceforge.net/viewcvs.py/leaf/devel/nangel/webconf/doc/webconf-configuration.html A Developer's Guide is here: http://cvs.sourceforge.net/viewcvs.py/leaf/devel/nangel/webconf/doc/webconf-howto.html --- --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc vs. Oxygen
On Friday 01 October 2004 12:20 pm, Thorsten von Eicken wrote: development seems to have ceased in 2002. Is Bering-uClibc the way to go now? Thanks! Thorsten - Santa Barbara Hello! I made the switch from Oxygen for two reasons: A) Bering-uClibc appears to be the only product in active development right now, B) The Oxygen kernel is 2.2 based, Bering-uClibc is at 2.4.x. While I prefer the Oxygen boot model, I've also had success with building webcams, mp3 jukeboxes and the like with Bering and Bering-uClibc. Bering- uClibc has a new LEAF.CFG file that gives you much more flexibility in booting, so I'm not so sure that Oxygen is that much better anymore. YMMV. Hope this helps! --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Configuration
On Friday 24 September 2004 12:53 pm, Mike Noyes wrote: What is the status of webconf? The current version in cvs provides a web version of lrcfg and the backup script. It works for me, but hasn't been tested much. I've received a number of good suggestions from the uClibc-Bering crew, and as a result the current interface is somewhat different from what is documented in cvs. Updating the documentation is on the TODO list. I am currently working on providing logfile viewing and network connection status pages, since this is functionality in the current weblet. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] [OT] xml sources
I'm (attempting) to write some developer notes (guide) on the webconf framework. I'm trying to write something in the style of the bering-uc-developer's guide.The CVS sources for the other chapters don't list what generated the xml source. Obviously editing xml by hand with bare vi is the wrong way to go about this. Any pointers as to what you all use to write the developer's guide? thx. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Fwd: [OT] [Long] Source Config: Clarification / Apology
I posted a sample WebUI for review, and back in July 12 one of the uClibc development team wrote me. I didn't notice the message until yesterday. The message was a very polite query, and I think a response to the list is warranted. Basically, it was who are you, and why won't you release your source code, when what you are using is GPL'ed? By day I am part of the IT staff for a large organization that is not involved in providing IT services or products. All of my IT work is done for internal organizational consumption. (e.g. keep the file servers and email servers running.) We (Organization) have no interest in promoting open source other than for internal use. That having been said, we the IT guys definitely get OpenSource, and /want/ to contribute. The directive from our management is that we can release stuff we write GPL'ed or any other way, as long as it A) Isn't branded (e.g. internal logos, passwords, our business rules coded in, etc.) and B) We don't release it in the organization's name. I understand their position, and everyone's trying to play fair here. But the rules are: I can release code, but it has to be in my name, and I have to make sure that it isn't branded. So, when you see my email domain, that's me (the individual). When you see www.tetrasec.net, that me (the individual) too. We worked on a project that involves clusters of LEAF-like boxes that act as a set of perimieter networks for our branch offices. I say LEAF-like because its a pretty big fork of the old Bering code, with some of everyone else's ideas thrown in. These things boot from CD, and are coded to have our business rules built in (For example, I have to deal with this person can send email, that person can only send to certain domains, and that third person can't send email at all.) Back when J. Nilo was maintaining Bering, I talked with him briefly about merging some of our ideas (the sane ones - not the example of email usage!) into Bering. He was more interested in a single-diskette distro than a full-fleged CD. I respect his position, and think he was right. One of the things that the cluster includes is a web-based interface. Years and years ago we had discussions on this list about web interfaces. After actually seeing one in production, I'm now a passionate believer. According to my rules of conduct, I can release the web-configuration engine, but just have to make sure that the business rules (and lookfeel .e.g. css stylesheets) are changed. A few months ago I had a brief off-list conversation with Erik Spakman regarding suggestions for developing the webconf into a package. Our architecture is: pointers to the cgi's, for building the menu: /var/lib/lrpkg/pkgname.webconf the cgis: /var/www/.../blah.cgi /var/www/.../blah2.cgi This means when you load a lrp, the webinterface for /that package/ automatically shows up. Erik suggested that it might help adoption if I just left all of the cgi's and webconf's in my own .lrp. So I set off to create a web configuration engine for review by the LEAF folks, using stuff /based/ on the engine I wrote for our organization. Since I needed new lookfeel, and I was targeting uClibc, I ripped the css and images from the leaf.sourceforge.net site. I was working on this little demo when Mike Noyes mentioned to the list that we really needed a web interface. So I have: a running system that's branded, and is part of a cluster, but works ok - and this little demo box. The demo box wasn't ready for prime time, but I wanted to share what I had so I posted I'm not at liberty to give the whole web thing away, but if anyone is interested I could peel off a few cgi's as a demo. What I meant was, I *know* this approach works in production and works well enough, but all I have available is my little demo box, with just a few cgi's that I've completed. In hindsight, what I actually said was I've got this thing based on your hard work that you've released under the GPL. I can give you a peek, but you can't have it. That is not what I meant, and I'm sorry. Mike Noyes was still nice enough to ask if I could play nice and donate the code. My perspective - I was thrilled that I could participate, and immediately tried to package my little demo box up for review. I make things worse by my next post: I put out a sample of a web configuration out for review, its based on what we are currently using, although somewhat crippled - I just pulled a few pages out of a running system, and hacked them to work with UCBering... Crippled was a very poor choice of words. I meant crippled in the sense of I only got 2 web pages working ..., but it comes across as if I'm deliberatly witholding the code. Again, that's not what I meant. The guts of the system are *ALL* there: /var/webconf/validator.sh - validates input /var/webconf/svcstat.cgi- the thing that prints
[leaf-devel] Re: Source Config
I put out a sample of a web configuration out for review, its based on what we are currently using, although somewhat crippled - I just pulled a few pages out of a running system, and hacked them to work with UCBering... Screen snapshots and the code are at: http://www.tetrasec.net/index.cgi?page=WebUI Eric, in response to your question, I'll try to look at your web config stuff in the next few days. --- 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
--- Ray Olszewski [EMAIL PROTECTED] wrote: Actually no. I meant people other than Erich who are either upstream developers (e.g., Tom) or packagers (e.g., Charles). That is, the sorts of people who will actually have to use, or to ignore (as they have up to now, saving the occasional e-mail), whatever gets implemented. But any thoughts from the old development team would be great too. I don't know if you want to hear from someone who was hoping cdb would take off, but had to do a web-based configuration UI on bering anyway.. but here goes. I would have prefered to use cdb, /if that's what was mainstream/ but it was in early development when we started working on our UI, and then it got ignored. What we ended up doing was writing shell scripts that directly modify the configuration files themselves, and have the smarts to look for related packages to grap what the web-script needs. (e.g. dhcpd has to look at interfaces to figure out which interfaces it could serve dhcp addresses on) In a few cases, we source foo=bar ... files. (but from experience, I can count the number of variables that we need to store this way on one hand.) The biggest headache so far has been dealing with the case where the web-based script makes a change, and then a custom tweak is made afterward. Generally, our configuration files have comments in them that read: #vv managed by web interface do not edit below this line .. #^^^ managed by web interface do not edit above this line and then have the script just spit out everyhing above and below the markers, managing only what is inbetween. So far its worked as a fair compromise, but our userbase either only uses the web interface, only uses ssh, or wrote the web-script and knows how to tweak things. :-) It works as an advanced home router for the web case. I'm not at liberty to give the whole web thing away, but if anyone is interested I could peel off a few cgi's as a demo. But, as an integrator (sitting between user and developer) I would have preferred to use the cdb approach, but don't want to have to be the one to define the cdb database/heirarchy, etc. for all of the packages. If there was some consensus of what goes in the database and who puts it there, I'd be happy to use it. hope this helps. --- 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] Subject: Using .deb packages for custom Bering
--- Mike Noyes [EMAIL PROTECTED] wrote: Nathan, Would you mind making your diff of apkg available? Mike, I put the package as it exists and some description here http://www.tetrasec.net/index.cgi?page=ApkgLRP As always, comments, suggestions welcome. --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Subject: Using .deb packages for custom Bering
--- Mike Noyes [EMAIL PROTECTED] wrote: Nathan, Would you mind making your diff of apkg available? Sure. It doesn't do the http/ftp gets like the real apkg did, and the include/exclude logic is closer to serge's packetfilter than it is to standard lrp, so it's a little different from standard lrpkg. But I'll be happy to write up some docs and post it up for ya. --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Subject: Using .deb packages for custom Bering distro
Note: I am NOT wanting to start another which package system is best discussion, I'm just looking for comments, observations you all may have... Having used lrp (original), oxygen, Dachstein, bering, and uClib bering, I'm very familiar with the .lrp package structure. Currently we have many of these deployed in various roles (routers, vpn endpoints, traffic-shaping bridges, squid web cache, etc.) We need a better way to update packages than lrp currently provides. I need some way to have change management on thee boxes, as well as a way to update a package in place, without downtime. Yes, its possible to do with lrp, but I'd like some way to be able to have the leaf box pull an updated package from a central repository (via ssh or https), and then have an upgrade script run. The lrp way to do this is to add a /var/lib/lrpkg/pkgname.upgrade script, and then teach lrpkg to run the upgrade script. But at that point, I question whether or not its just better to make the switch and use busybox's dpkg applet - and use the .deb package format. debian already has the pre-install, install, deinstall (forget the name) and post-deinstall scripts. -- I know this is a severe departure from the leaf community, especially with respect to the uClib-bering team's goal of continuing to support a single diskette distro... So I'm not looking for support/design/coding help. (although it would be welcome :) ) What I am interested in is what you see as the pros/cons of such a plan. What I see are: Pro: debian's already figured out a good packaging system. leverage that. Pro: bering's already mostly debian, so it should be easier to strip a deb-source package and build a bering package for that than it would be to build one from scratch. Con: lrp is just a tarball - you can't get simpler than that Con: We'll need more RAM/disk space for metadata about which packages are installed. Con: Time/effort required to actually make the switch. Am I missing something really obvious? Thanks! --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Subject: Using .deb packages for custom Bering distro
--- Charles Steinkuehler [EMAIL PROTECTED] wrote: The big thing to consider is the fact that .deb packages were not made to re-build the full OS at each reboot, ie: they presume persistent storage. If you're running your systems off a HDD, that might not be a problem for you, at which point I'd suggest you take a look at any of the micro debian-based distributions that are avaialble. It would probably be a lot easier to start with something designed to work with .deb files than to coerce LEAF into that role. Thanks for your comments, Charles. Yes, that is a good point. The micro-debian distros are still a little heavy. Its a good feeling to strip a perimeter router down to 1 diskette, but scale to a cd+hdd for a web cache. I'll also throw out a few pointers, in case you decide you want to stay in the leaf domain: - You should not currently use lrpkg -i to install an upgraded package, Thanks. Actually I'm using a rewritten apkg (originally from Oxygen). - If you're using partial backups to save your configuration, you can fairly easily manually upgrade a package by: Extract the .lrp file into /root of the current filesystem Re-extract the configuration .lrp to restore the over-written config files - If you wanted to be a bit cleaner, you could do a 'psudo' partial backup (just stash the partial backup in /tmp or something) prior to installing the updated package. See the backup scripts (and the local file) for how to pull just the config data out of a package. - Obviously, you could create a script that automates the above processes...most of the code even exists already, spread throughout the backup scripts, linuxrc, and maybe a few other places... Nice ideas. Thanks for taking the time to respond. --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] possible cgi for weblet
After (years) of thinking about how to do a php-lite, I finally finished a cgi for use inside a small web server. I use thttpd on bering, but this should work wtih weblet (sh-httpd). The code compiles to about 11K with 2.2.5 glibc (yeah, non-standard bering). It compiles much smaller against uclibc. The basic idea is that it takes all form data and makes them environment variables. (nothing new there); the new parts are A) it handles binary file uploads (ssh keys, ipsec certs) and B) it handles conditionals - if / then / else - so that cgi programming is a bit easier (at least for me) than writing everything from shell script. Its kinda like a very minimalistic php. A short discussion and the code is avalable at http://www.tetrasec.net/webconf.html I'd be very grateful for suggestions / flames / whatever - I'm currently using it to power a web configuration engine, but would love to fold it in with what Eric Lynn are doing. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Command recall Oxygen(yes) Bering(no) DF(no)
It pains me to realize that I've been using command
recall in Ox, DF, and BF for a long time now. The
up arrow works great. My apologies for losing my mind.
Perhaps you aren't losing your mind...
Do you also have the experience that that ash seems
to have problems with the up-arrow command recall
when the command is greater than the screen width -
you can't edit the first part of a multiline
command? (where multiline is a long command line
without the use of '\' ?)
Thanks for the explanation. I guess what I'm really
missing in filename/directoryname completion.
After checking further, BusyBox ash (0.60.3) with
command auto completion seems to work here on bering
if you:
compile EXPR into busybox, and comment out line 204
in linuxrc:
# expr () { exp $@ ; }
Probably you could get away with not compiling in
expr and changing line 204 to read:
expr () { $(( $@ ; )) }
But the shell gurus should comment on that theory...
Also, at the top of linuxrc (line 30 something) there's
a call to [, which fails since busybox hasn't been
installed yet. Guess its a shell internal in ash, but
a program in BB.
The offending line is:
if [ $DEBUG ] ; then
A solution might be to change the line to read:
if /bin/busybox test $DEBUG ; then
or just define BB=/bin/busybox a little earlier in
the script and then call
if $BB test $DEBUG ; then
That seems to run through the linuxrc without any
errors, and gives a nice shell with auto completion
and correct behavior in using command recall.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Command recall Oxygen(yes) Bering(no) DF(no)
One reason I used to use Oxygen a lot is that it has command recall and filename/directoryname completion as part of it's shell, which I think is ash. But I don't get what's different on the other LEAFs. Don't people use the same shell? Also it has a a working $PWD. Well, command recall is my wish for Bering rc4. Not enabled by default of course :) Matt Me too! The reason is Oxygen uses BusyBox shell, and Bering uses real ash. Last time I tried to get bb shell to work with bering, there was a problem with initrc (can't remember specifically where in the script, but bering initrc seemed to want something that busybox couldn't understand, and it caused the startup to fail.) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: Webbased configuration
Better sense tells me I should probably keep quiet, but ... Back when this discussion came up previously (Dec 2001/Jan 2002?) I was able to get micro_httpd working with an embedded lua interpreter. It allows one to write html code with inline lua scripting, like php. To add some real numbers to this dicussion: micro_httpd - dynamically linked against libc9404 bytes lua_micro_httpd dynamic libc, static lualib 75972 bytes Compressing with upx gets it to 39K, which is still big for a diskette-based configuration engine. If FORTH can really get us an embedded language in 10K, that sounds great. I'll check the site Charles mentioned tomorrow; any other pointers anyone can give - please share! (I'm not a coder - but don't mind getting my fingers burned either...) --- FWIW, my wish-list is something like this: Must haves: +small size +URI (GET) or POST method variables exposed to the script language +rfc-2388 mulipart/form-data compliance (must be able to upload a ipsec cert/crl via the web browser) +inline scripting (like php) +enough of a framework (.css / examples / docs) to make it easy for someone else to use +master script (index.html?) that will take over the job of lrcfg Cool features, but not necessary +logging +http 1.1 compliance, especially keepalive +cookie support +std graphics building library (like fly or gd tools) Not desired +stand-alone server +high-performance +ssl +locked down security (need to be root to configure anyway!) -- I'm sure others have a different wish-list. Charles' wacky ideas got me to thinking If you check out nullwebmail, its an executable that runs as a cgi under a web server - but any will do: thttpd, boa, mini_httpd (I don't know about sh-httpd). Unlike most web-mail solutions, all you need is the single program - no complicated install process - just compile, put the program in the www directory and you have basic web-based mail. Do you think that's a better way to attack this problem? Rather than extend a web server, just build a really smart cgi? I don't know the answer - just wondering if anyone else does. --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] OpenSSH security
To sum up many posts and hopefully wrap up this thread... I've posted a new sshd.lrp at www.nothome.org:8000 The only change is a new /usr/sbin/add-sshd-user script, in response to Charles' comment that it would be nice to have a script to add the sshd user. The script isn't pretty, and it is fairly large (4K), but hopefully it covers 80% of the cases of creating the sshd user and group. Yes, it normally takes 4 lines of script to do that, but this script tries real hard (TM) to: * (by default) add sshd UID 22, GID 22 to the password and group files * If the GRP and GID variables at the top of the script are changed, it will use those (perhaps nogroup, as Michael D. Schleif suggested) * Use a different UID, if desired for some reason * Add the sshd user only if it does not already exist * Add the sshd user with a different UID if the requested UID is already in use * Add the defined group only if it does not exist * Add the defined group with a different GID if the requested GID is already in use * Insert the user and group into passwd group in numerical order, not at the end of the file * Reset the permissions ownership on the new passwd,group, and shadow files even if your group file is broken * Allow you to run all of this on a test directory first (see PTH variable, at top) --- The script is *not* listed in the package list, and is specifically listed in the exclude.list, so that it won't get backed up when sshd.lrp is backed up. The idea is to install sshd, run add-sshd-user as root, backup etc, backup sshd, and never think about this again. For those interested in the script only, I've placed it at the web site mentioned above as a text file (add-sshd-user.txt) Anyone is welcome to do anything they want with this script. - George Georgalis asked if it was possible to compile sshd without zlib (which makes sense, since compression must be turned off to use privilege separation). As far as I was able to tell, zlib is required to compile sshd. But the space requirements aren't that bad, since sshd and ssh are both dynamically linked against zlib. Finally, Greg Morgan pointed out that he hadn't seen many port 22 probes recently ... dshield.org doesn't list port 22 very high either. Such is life; at least we were prepared. :-) Thank you all for your comments and suggestions. --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Differences between gshadow and group
In both Oxygen and Bering the /etc/gshadow and /etc/group files appear to have very different entries. Generally, gshadow is a superset of what is in group. It looks like cruft from the old LRP (2.0.x kernel) days, but does anyone know of a good reason why the two should not be in sync? --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] OpenSSH security
I'm curious about /etc/group modification? I've upgraded two (2) potato's and two (2) woody's. Yes, there is a new user in passwd/shadow; but, I do not have any new group for sshd. Yes, I have seen the instructions for installing manually; but, I cannot find a reason for the special group. What do you think? Good question. I wondered the same thing, figured 'cause Theo said so.. and dismissed it. But after you asked, I checked the source... :-) sshd.c in privsep_preauth_child does a setgid() from the sshd's primary group (in passwd) when setting up the chroot jail. The manual instructions make sure that the uid:gid is sshd:sshd. So I guess 'cause Theo said so works. :-) I'm curious though, on your debian systems, what is the gid for the sshd user? The sshd.c source seems to indicate that sshd will fail if the group doesn't exist. --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] OpenSSH security
I've compiled new openSSH 3.4p1 lrps based on J. Nilo's packages. Since they are larger than the patch manager limit, they are available for download at http://www.nothome.org:8000/ I'll leave the page up until next Friday (5 Jul 2002.) The md5 sums for the packages are: 92395eae01a299a4c5412513482c90b0 sftp.lrp 0c9e5948681f5e20ef632e380d4928d1 sshd.lrp 0c5124438f4b9a0faca1d37b9f7b8846 sshkey.lrp 2087bea66f66ac5f2922551e26723b01 ssh.lrp Compilation notes are in sshd.lrp, in /var/lib/lrpkg/sshd.notes I would still be interested in knowing whether sshd should be a standard LEAF user, or if you all think not using priv separation is ok, or if a standard user (like nobody) should be used. --- --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: OpenSSH security
I got OpenSSH 3.3p1 working today with priv separation, but compression must be disabled (mmap error.) A couple of questions: - 3.3p1 with priv separation wants to have a sshd user and a sshd group. Those aren't in Bering or Oxygen's passwd/group/shadow files. I made the accounts UID 22 and GID 22 here; do you all have any suggestions for what UID/GID should be? Do you all see any problems with adding it into the standard LEAF distros (Dachstein/Oxygen/Bering/etc?) Or do you all favor changing the opensSHH code to use an existing user/group? - Eric Wolzak indicates Jacques won't be back till next week, but that's when the vulnerability details are supposed to be published. For management reasons I have a need to deploy the fix before Monday. :-) The package I have is based on Jacques' package, but compiled for libc 2.1.3 (Oxygen). If you want, I'll be happy to A) recompile for libc 2.0.7 and post or B) give you all my notes and you can build a package. Of course if no-one else has the same pressures to release before monday, its fine for us to run with non-standard lrp's. Thanks! --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] OpenSSH security
On Wed, 2002-06-26 at 08:08, Mike Noyes wrote: The vulnerability details are now public. Thanks for the heads-up, Mike. Unfortunately I only subscribe to the digest, so I got your notice after my post. Needless to say, I'll be putting together a brand-new *3.4* openSSH lrp tomorrow, if anyone is interested. Anyway, thanks again, Mike. I really appreciate your efforts. --- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Net Booting
Ángel Martín Alganza wrote: Of course, it is. Again... I was thinking about a LAN... actually, I think most of the time about two very similar scenarios: my class- room (I teach BioInformatics) and my brother's WebCafé... in both places I like to have thin diskless clients booting from floppy as straigth forward as possible. I mean... just drop in the floppy, turn on the system... wait for some seconds and start working... you know. Excuse me in advance if I'm butting in, but here was my experience: I taught a tcp/ip essentials class back in June, and used David's net booting method for the classroom. The server was running boa, with a directory for the packages the class needed, and another with ALL the packages. If memory serves me right, either the package list was supported then, or snarf pulled the whole directory down. The end result was that we were able to control the base base lrp package set for all classroom machines by modifying the directory on the web server. We didn't have to modify the boot disks. I think we were even able to push a larger root.lrp out to the class but I'd have to double- check that. :-) When it came time to use hunt ettercap the other fun stuff, we were able to have the class pull them down - but they didn't get those tools until we told them to. At least for us, the netboot worked well in a lan environment (20 machines or so, and appears to scale well. YMMV Again, apologies if I'm intruding. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
