[leaf-devel] Network package loading
With all the consideration of network package loading and backup, I'll chip in my $0.02. This is a development method so I'm also sending this via the leaf-devel list, where it technically should be discussed. First of all, David D wrote apkg to approach many shortcomings in lrpkg. Network loading of packages is one of the additions, so I would highly suggest anyone seriously looking into adding this support check out the apkg SRC code. Second, the PXE bootloader is offered as an option to Syslinux for loading of images (and possibly packages) over a network. This method uses sftp, which is supported most OS's. I would imagine that David has used this method with apkg, though I can't confirm it. I can't see a reason that any other method would work cleaner w/o needing to re-write existing code and methods available for the same purpose. I would also imagine that you can find some links for documentation of this method from openbrick.org which offers Bering booted in this manner. Happy hunting! ;-) -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bering-uclibc source tree
On Wednesday 27 November 2002 19:41, Mike Noyes wrote: On Wed, 2002-11-27 at 14:31, Erich Titl wrote: What is done with the various branches of a tree is something which can be dealt with at release time (by of course the lead developers or someone charged with the release task) I'm not quite grasping your meaning here. Please elaborate. It is even less if someone just adds a little (hopefully not harmful) extension to a part of the software. Unless this extension makes its way to the base distribution it remains in its niche at the developers private tree. Correct. It is up to the release/branch lead developer and team members to incorporate these extensions/patches. I expect people that repeatedly provide useful additions would be asked to join the team. Well, if nobody minds too much, I'll add a few comments since I have a few spare moments. Right now, there exists CVS for certain packages, Oxygen, and Uclibc. The parts that pertain to *stein and Bering for the most part are unavailable in a CVS access. This has not been a problem in that most of the core packages for *stein and Bering are not updated and require versioning. To make the source available for many of these packages will require atleast one of three options: 1) Dig through the old LRP SRC tarball and update it to LEAF SRC CVS. 2) Have the individual developer who compiled the program copy the SRC directory on their personal box to LEAF SRC CVS. 3) Locate the proper version of the SRC code and duplicate/update the makefile and upload it to LEAF SRC CVS. Simply put, this NEEDS to be done. I am more than willing to do this myself, but I will definately not have the time until after the first of the year unless someone else wants to start work on it earlier. By having this done, this provides accordance of licensing, easy availability, and a good form of versioning as many of these programs are/should be updated. This also clearly differentiates between the different versions available for LEAF, which could easily become a problem with upcoming image releases/versions. The largest problem I see is getting all programs into CVS there are many little packages to get in there. It would also make things easier if developers want to update/change certain parts of these packages. a check of the PacketFilter changelog shows a huge amount of changes and rework of POXINESS scripts and similar programs. After this is done, then there can be branch updates of these programs via CVS by the lead developer(s). Those submitting changes to these programs outside of the release group should use the patch manager. Everyone simply cannot have access to the release CVS. Development can be done within the branch, but there should be a note stipulating which CVS version of each program is used within a release. I personally see this as the clearest method to work into the new releases that are now becoming available w/o watching the current problems snowball into a huge mess. I know this will require a lot of time to get up, but I don't see a better idea at this time. Any thoughts??? -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Larry Platzek
On Thursday 14 November 2002 22:52, Larry Platzek wrote: I will not be doing much with LEAF for a while, I have had some trouble. I now have a Broken leg, it was a clean fracture and now have a metal rod in my leg. It is difficult to even type on a keyboard. My sympathy's go out to you. Thanks for all the help that you provide, and I wish you a speedy recovery! ~Lynn -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering and PXELinux
On Thursday 31 October 2002 12:47, Michael Bonner wrote: Hi All, I'm running bering on a Soekris net 4501 for my firewall on my home network. I'm not really happy about having my CF card exposed for hacking if someone compromises my firewall (and yes I've been following the DOC write protection threads). I'd like to take advantage of the PXE Boot capabilities and run Bering using the PXELinux loader. Has anyone tried this before? Any suggestions or issues I should be aware of before I dive in? I believe the openbrick project is running on a custom LEAF image in this way. I would suggest looking over their site and/or dropping them an email based on their apparent experience with this. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] Different Size of Kernel Using Different Distro
On Friday 20 September 2002 22:54, H. D. Lee wrote: List, I have tested building Bering kernel from scratch, with the addition of ip_vs patch. During the process, I have noticed an interesting fact. When compiling on Mandrake Linux 8.2, the result of the kernel (bzImage) is slightly bigger than compiling on Debian 3.0. The gcc version shouldn't make too much of a size difference, by chance are you using the Mandrake source to compile with? Last I heard, Mandrake was still using RH's Alan Cox (AC) branch source which is different than the Linus branch source that Debian is using. Just a thought... :-) -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] RE: Bering - included libraries
On Sunday 22 September 2002 00:47, Eric B Kiser wrote: It seems that I am beginning to catch on. Zebra is looking for a newer version of libcrypto than what is being provided by libssl.lrp. So, that leaves me with two options; [1] build an updated libssl.lrp [2] compile my zebra package with libcrypto statically linked Michael suggested number [2], would anyone else care to voice an opinion on this? Does anyone else even see the need to have an updated libssl package? Just trying to gain a consensus and possibly some guidance before moving forward. Personally, I would like to eventually see ssh and zebra not using statically linked libraries. That is, of course, unless I can show that using the static libraries on zebra and ssl work out to take up less space than zebra+ssh+ssl packages. I would agree that option [2] would likely be the better of the two choices. You are about as far along with a Zebra/LEAF disk as I was when thinking about something similar several months ago. I know that Zebra isn't going to fit on a floppy, but SSL is a huge package that could present problems as well as benefits in the long run. Statically linking the library simply limits the drawbacks to including the entire library. It will work either way, but I would suggest drawing off of WISP-DIST architecture, since you are going to end up with a non-floppy image. This architecture adds several safety features not available with other current LEAF variants. The bright side is that your probably not going to have to worry about firewalling anything, just securing the router! ;-) -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] Re: Building Bering from source
experience is that standards are good, evolving standards are even better. Standardization seems like a uncomforting word to many developers. At what baseline are you considering standard. I'm sure you realize that 2.2 and 2.4 kernels demand different patches and init process. To further the standardization, Oxygen, Wist-dist, and Packetfilter have a different boot process altegether. I would highly suggest going over Serge's changelog with PacketFilter to get an idea of what I mean. My last consideration would be if Charles or someone does actually write a bootloader in Forth..where would the baseline be then when Syslinux is replaced??? I think I'm following your idea, but I don't think a central LEAF repository could be clear and easy to follow UNLESS things were seperated by variant. Or am I wrong??? -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Re: [off-list] GNU licensing
On Monday 16 September 2002 14:27, Mike Noyes wrote: Everyone, This is the first post I've seen from a kernel contributer on our devel list. Is this a gentle reminder that we may have some licensing problems with the files we provide? I would imagine so. I also missed a couple on the quiz...good learning experience! If this is a gentle prod, my interpretation of the quiz/GPL would indicate that we do NOT need source posted on the site, however it MANDATES that we have the source available on some physical media per request and that charging for the expense of shipping and media is allowed. With this in mind, each variant or any combination of variants should have something along the lines of David's developer CD that could be mailed if requesteda downloadable .iso would be nice, but beyond necessity of the GPL. I won't have guessed at this mandate myself, but after taking the quiz does anyone else have a different interpretation? -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Building Bering from source
So ... the key word in Erich's comment is primitive. If one's ends are simple, LEAF setup requirements probably are too demanding. But complex needs require complex solutions, and that is what all the LEAF and related-project (Shorewall, for example) developers seem interested in supporting. Yes, the existence of multiple LEAF branches does complicate things a bit, but blaming this diversity for the greater complexity of LEAF misses a lot of the point ... that LEAF configuration is more complicated than router-in-a-box solutions precisely because it can do more complicated things. Ok, with this line in thought being pointed out. In less than a week, I can presently turn out a set of custom images of several present LEAF variants that: 1) Provides a general firewall. 2) Provides a web-based interface linked to internal ip's w/ virtually no security (other than name/password). 3) Is simple to setup due to lack of configuration options. Is this what you desire to have available??? I feel that several others in the past have likely come this far in development, but feel the need not to release it due to the massive amount of specific request for more rarely needed options that don't necessarily keep everything simple (or on a floppy). Personally, I feel the upcoming development with the web-based configuration thread would be preferrable in the long run. Lots of people in the team have done little (or even big) extensions to the base threads. Some of these externsions may have found their way into the distribution. I would like to see a distribution tree with sources included, embracing as much additional stuff as is seen fit by the lead developers and I am prepared to help where I can with as much time as I can pry loose. I believe the community can profit from such a model and who knows, maybe we have success. I believe Ewald has expressed his dedication too and certainly others may want to get involved. If you think this is too big a bite for anyone's appetite let me know. Building a type of ports system such as David is working on interests me tremendously, however after several short precursive peeks at his tree leaves me with several inpending questions: Is the target system compiling the source itself? 1) If so, what compiler is available on the target system (floppy?)? 2) If the target system is not compiling the code, the user must use some form of *NIX system to compile on this pretty much eliminates M$ users. 3) if the compilation is done by the system remotely, is the SF compile farm (or some other system) going to work with any GPL restrictions (distributing binaries?). These are simply concerns due to my lack of understanding of port systems outside of LFS, which requires a Linux compiler on the host system. A simple description of the process being proposed would likely build more dialog on the topic. Any direction this is taken is going to have a baseline environment, which will affect the required licensing or end-user in some way. I'm still attempting to figure out what the required system can/will be. Thanks for the thoughts, the effort, and the development! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] (no subject)
On Sunday 15 September 2002 06:10, Erich Titl wrote: The currently available releases may still exist but it might be possible to get the best features out of everything. I was wondering if Eric's plans to base the configuraion on a common base would not automagically lead to a unified environment. Evolution will have it's way. This unified environment would not be mandatory. However it would require a compatibility layer for any LEAF variant since the packages that would depend on certain configuration data could not be assumed. This would be left optional for the user/variant to use at it's discretion. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] I need advice about some decision...
On Friday 06 September 2002 04:20, Choe charlie wrote: project team MOLE ,electronics engineering department Kang Won National University, KOREA Dear developers It was very helpful studying your website. Firstly, I appreciate that. We are designing Linux Router Project.I want to develop Linux Router with 1-floppy but we had a serious problem. so I would like to ask you to help us . My Linux router system must have following requirements. spec: 1 floppy Boot/root Linux system 2 support Ethernet(TCP/IP) * 3 Qos in Ethernet(not for ATM ) - Router must control band width by each User(IPs on Ethernet Network) when network is busy ,the system must guarantee Minimum Band for higher priority user. and when other case each IP could communicate Maximum for the extra. LRP is depreciated compared to the LEAF variants here at http://leaf.sourceforge.net/ . Dachstein has built in QoS capabilities and Bering can use bandwidth throttling with the tc package. You might also read over the QoS howto at: http://leaf.sourceforge.net/pub/doc/howto/LRP-QoS-HOWTO.html -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] SF shell file permission maintenance
On Friday 06 September 2002 15:02, Mike Noyes wrote: Everyone, Please make sure that all files you place on our SF shell server are of group leaf and are group readable. This is necessary for our mirrors to function properly. /home/groups/l/le/leaf/devel/guitarlynn/ipsec.txt Done! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] [config] Webbased configuration
On Monday 02 September 2002 09:15, Mike Noyes wrote: Everyone, If we're considering a change to our .lrp package structure, I strongly suggest an evaluation of udeb for the new format. This would allow us to piggyback off of Debian installer package development. They already have udpkg, netcfg, niccfg, busybox, ash, etc. They even have a stripped down apt-get called anna. modules.txt http://cvs.debian.org/debian-installer/doc/ http://ftp.debian.org/debian/dists/sid/main/debian-installer/binary-i 386/Packages This is a pretty good setup. I'm not sure if it's a perfect for this implementation, but it would be a great place to start discussion from in any case. - Can we build up a small subtree in the CVS structure for the configuration tool which can be accessed by everyone just for development purposes. A start could be the POST sh-httpd so we would not have to ask for copies explicitly. Suggestions for the structure please. This could help as a coordination point for our efforts. Erich, Agreed. Agreed here as well. I propose the creation of a config tree in our CVS src tree. All of the components necessary for this project can be placed there, and write access granted to team members. The structure of the config tree is left to the team members discretion. Example: leaf/src/config + | /core | /text | /ncurses | /web | /doc I think this is a good idea, however we had better get the architecture fairly well decided before creating the tree. Otherwise we'll likely end up with several nulled files. ### I would also suggest that we come up with a name for the config system before any trees are made and that the subject line start with [config] to make a clear seperataion from other devel topics. Thanks all! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] Dachstein v1.03 CD?
On Thursday 05 September 2002 11:46, K.-P. Kirchdörfer wrote: Am Mittwoch, 4. September 2002 18:54 schrieb Charles Steinkuehler: ~Fix for POSIXNESS mail script (kapeka?) What's broken in POSIXness mail? Should be buried somewhere in your mailfolder :) It's a one line fix to send mail during init process. I've found that no user is available in that special situation, and therefor mail refuses to send a mail with an invalid sender. The fix is to use root in that case. Especially useful with ipmail. Jacques accepted it for Bering-rc3, I'll send it again to whoever is responsible for Dachstein 1.0.4. Yeah, it's the missing one out of ~400 I've actually archivedabout time to clean house and actually make some notes. It's archived here: http://www.mail-archive.com/leaf-devel@lists.sourceforge.net/msg04581.html ~Lynn -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] DS 1.03 todo (Was: Dachstein v1.03 CD?)
On Wednesday 04 September 2002 12:06, Ewald Wasscher wrote: I'd like to add: update dhclient.lrp to fix problems for some ATT users create a udhcpc.lrp package based on Lynn Avants' udhcp.lrp My udhcp.lrp package is compiled with both the client and server in one binary. To seperate these daemons, a re-compile will be necessary. Personally there is redundant code between the two daemons, so I don't know whether seperating them would amount in saving much space. To use one daemon or the other, I would suggest commenting out/or removing the unwanted /etc/init.d script. This could be an added option in the .conf files if it would help anyone out. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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
[Leaf-devel] Dachstein v1.03 CD?
On Tuesday 03 September 2002 15:24, Charles Steinkuehler wrote:
Please migrate future replies to leaf-devel...this reply posted to
leaf-user in a blatent attempt to get more volunteer help :-)
Let me know if any of it looks like something you'd like to tackle...
I can take care of a few things and point you to some updated binaries.
mac addy command in /etc/modules
~ there was a posted addition to network.conf for this,
would this be plausible or are you looking for
something with the ! bang command?
Add 192.0.2.0/24 to stopMartians
Support unblocking of private IP ranges
~ I can do these, to start with anyway.
fix extra IP problem when using new net segment.
~ Where is this error coming from? Maybe I can do this,
I can't say that I've run into it.
Package updates:
libz
~ http://leaf.sourceforge.net/devel/jnilo/packages/libz.lrp
ssh* (add sftp)
~
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/helices/openssh/
New packages:
ntpclient - name too long!
~ http://leaf.sourceforge.net/devel/helices/ntpclient/
psentry
~ http://leaf.sourceforge.net/devel/ddouthitt/packages/psentry.lrp
Update binaries (or gnu instead of busybox version):
?new busybox
I think Bering is using an updated busybox, but IIRC he needed
to patch a couple of things to get it to work correctly.
This is where Sean Covel was at earlier:
#
body { font-family: helvetica } p { font-size: 12pt } a { color:
#547098; text-decoration: none; }Re: [leaf-user] Dachstein-CD update
Date: Sat, 15 Jun 2002 22:42:23 -0400
From: Sean [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
This is an update on my progress.
1. diskfree.sh - This may take awhile to incorporate, on the back
burner for
the moment.
2. MAC script change(modules/modutils) *DONE!
3. p9100.lrp if Bihn Do tests it and lets me know *DONE! Added p9100
and
modified root.lrp to create lp0 and par0
4. Unknown Weblet updates - Waiting for more info.
5. the .lrp.lrp change *DONE!
6. Burn and Test it. * I am probably going to do a personal test CD
tomorrow. My confidence in my Linux/LEAF development skills is low at
the
moment. Better test, test, test.
##
Let me know!
--
~Lynn Avants
aka Guitarlynn
guitarlynn at users.sourceforge.net
http://leaf.sourceforge.net
If linux isn't the answer, you've probably got the wrong question!
---
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] Re: Webbased configuration
On Sunday 01 September 2002 09:58, Nathan Angelacos wrote: Hey Lynn, thanks for your comments. I guess we are approaching this from slightly different starting assumptions. My assumption is that the webbased configuration engine is just a pretty face on lrcfg. The model I'm thinking of is you buy a linksys router, you plug it in to your LAN, look at the sticker on the router, and it says that if you point your web browser at 192.168.0.254, you'll get the configuration web page. No passwords - you're in as admininstrator, configuring the router for first use. All it is doing is editing the equivalent of /etc/interfaces; /etc/network.conf or whatever, and then bringing up the interface. Right? Similarly, we could say that the security of lrcfg is the strength of your root password for the internal interface, and whether you allow inbound telnet or ssh on your external interface. Once the someone gets in as root, I really don't care if he abuses lrcfg - he already owns the box. :-) I'm following you now that makes since and it would make it necessary to bring up the default (index?) page as a login only page (duh!). There may (or may not) be a defaut password to enter the configuration menu via www. It would also be advisable to run the server on something like port 81 so it would not be as likely to be accidentally accessed in the first place. snip I agree with the rest of what your saying... I was taking several steps further than you intended to in the application itself. Thx for clarifying! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] Webbased configuration
On Sunday 01 September 2002 15:08, Erich Titl wrote: Mike you seem to be knowledgeable about the copyright stuff. I am about to paint an entry page for the config stuff and would like to use the LEAF logo for it. Is there a problem? Erich, Would you mind getting with Richard Amerman and working on the the www page format. Richard has already done quite a bit of work stream lining the existing Weblet page code. Possibly the two of you can create the front-end of a menu system a little easier by bouncing ideas/code together. I think Charles' existing code, that uses Jscript for setting up the graphical end is an excellent idea that saves some space. Mosquito is using a Frame setup (shudder!) built from Jscript that works quite well (GPL'ed). There might be some ideas from examining that code as well. I would believe we will want to use xml (or xhtml 1.x) compliant code in the html...possibly CSS style-sheets with the POST form method (to avoid more code to interpret GET and the 255 character limit). I have sent Charles a copy of James Sturdevant's POST patched sh-httpd application that will be available via LEAF CVS when Charles commits it to CVS. If you need a copy of it to work with before then, mail me off-list and I'll send you a copy. Does anyone else have any ideas, thoughts, or comments on this since both Erich and Richard have been doing work for some time on the interface end of the project. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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
[Leaf-devel] Re: [leaf-user] Webbased configuration
On Wednesday 28 August 2002 12:56, Eric Wolzak wrote: (snip) I agree with your summary Eric. Advantage of webmin, there are all kinds of modules. Adaption is much easier than building from scratch. Disadvantage memory and CPU. I would be against using Perl personally. Porting Webmin would not necessarily be any better or faster than starting from scratch IMHO. Alternatively, use the same fields and write the engine in shell.script or php using sh-httpd. or a small server (boa, thttpd) It can be done with sh-httpd. Mosquito has used thttpd, but thttpd is considerably larger (and more versitile). My vote would be to use sh-httpd w/POST patch. Advantage probably, less memory and cpu consuming. ... I think any how, this should be a project for a group, who wants to contribute. I agree here as well. A group along these lines was discussed ~2 months ago. A couple of people were working on formatting Weblet and reworking it and I have developed a shell-atmosphere that will allow generating conf files from either GET or POST sh-httpd atmosphere. Modularization has always been in the plan, however nothing but test coding exists at this time being as I needed to jump through a few hoops to get the CGI environment working with sh-httpd. Anyone who would like to volunteer to work on any ideas, code re-work within the existing Weblet, or developing the new code-base for CLI/WWW configuration integration would be welcome to participate. In previous discussions with Mike N and Charles, the use of the leaf-devel mailing-list is encouraged for this project. This project would be beneficial to work under the LEAF umbrella and stay independant of releases. As everyone else was working with a Bering base, I am presently working with Bering as well (though I have worked on a Dachstein base as well). I am presently starting work on the framework. I believe that this is more of a devel topic, so I am moving the thread to leaf-devel. Is anyone ready to work on and/or discuss any sections of this??? Thx, ~Lynn -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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: [leaf-user] Webbased configuration
it. On Thursday 29 August 2002 16:47, Erich Titl wrote: Hi Eric, Lynn, Charles Asking for permission to come aboard. Welcome aboard!!! On Thursday 29 August 2002 18:11, Peter Robinson wrote: Hi there I have written a web based admin tool for LEAF based loosly on MOSQUITO. It is written in /bin/sh. I dont believe you need perl for this task That is interesting! I've gone through the Mosquito code and found that it covers many of the bases. However, there were several disadvantages to using any of itlike lack of CLI configuration options. The use of Jscript for a PHP-type atmosphere is interesting. It would be nice if you could elaborate on what you have done. Which LEAF version did you use? What modifications to the existing configuration files have you made to make it work? The thttpd and uncgi combination is great, however uncgi has not worked with sh-httpd in my testing due to CGI path restrictions. Uncgi uses /cgi-bin/uncgi/'cgi-script' to interpret a CGI file and sh-httpd does not support the /path/binary/option format. Exactly what kind of su wrapper are you using to overwrite existing configuration files or are you running thttpd as 'root'? * *New thoughts* Through my personal testing, though rather minimal, I've ideally got an environment that includes: *sh-httpd- can use GET or POST form methods. Either works fine, but GET has a 255 character line limit, POST doesn't and save a couple of lines of code to interpret the form information. James S.'s POST patch has worked in my testing. This is the smallest webserver that effectively works in my testing. *su-wrapper- to overwrite any file owned by 'root' and safely run sh-httpd as a non-priviledged user a suid binary must run. This small binary can be configured for many files and under set binaries and conditions...very easy to configure and I've compiled it w/o any glibc restrictions. *To ease compatibility of many packages needing specific duplicate information/variables, a break-up of certain conf files should be made and a check for depending packages should be made within the web module. The other option is building a new LEAF version that fits this format (successor to Dachstein???). Internal network and DMZ information would be excellent examples of possible problems. Modifying the existing package database would not be a good option, unless we are going through them anyway and following something along the lines of David D's Port system. *The CGI scripts should only setup the environment and call executables. If the actual executable is not integrated in CGI, a CLI configuration script could use the same code and minimize the total codebase that would need to be written. There are several of us that have already written configuration code for existing LEAF variants, possibly some of this code may be portable. *Variant Independence- How do we propose to write the code in a way that will not cater to a specific LEAf variant? This answer could possibly lead to variant developers porting their configuration files and packages to using our framework. The other option would be to start a new LEAF variant to accomadate this development and encourage other variants to use it if they choose. *Language for Executable code- Jscript, C, Forth and other languages could reduce the overall size of the operational configuration. Due to my proposed framework, the actual CGI size wouldn't benefit from using Jscript, but writing executables in compiled code could make a large difference. Who is available to write in any of these languages? I've written a little C/C++, but most of my experience has been modifying existing code to work for my environment rather than writing it from scratch. *Package framework- Should there be a base.lrp, a www.lrp and a cli.lrp to account for different installation preferences. How would we institute adding modules to the package porting lrpkg or apkg would be ideal and user-friendly. ** These questions pose the largest problems we're likely to run into with this project and *should* be answered before they become a problem. I believe the member resources are available to do this in a short period of time, but a solid framework and direction will make or break the project. All opinions, ideas, and suggestions are welcome and encouraged! Thx again, ~Lynn -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] cvs src tree
On Monday 26 August 2002 12:49, Mike Noyes wrote: Lynn, Thank you for opening this topic for discussion again. :-) Remember I'm not a programmer when reading my comments below. No problem, as discussed many times over the last yearthis needs to be done! +packages +glibc-2.0 +glibc-2.1 +glibc-none +binaries I believe the seperation of glibc within packages will avoid confusion between packages with the same package name that actually differ in end use. If we use David's build system for our packages tree, isn't the glibc separation unnecessary? Has anyone evaluated David's build system yet? I'm sure he would appreciate some feedback. Is it a usable system for our packages tree? The tree looks great, however there is no source that I could find located within the tree itself. It appeared able to pull the source from a remote location from the tree, however I thought that we found that doing that would be unacceptable under the GPL anyway (possibly fine within the MIT licensing, I dunno). The GPL does not support linking remote source as I believe we discovered and the reasoning for getting the LEAF source tree up in the first place. As I understand it, we simply need the source posted for compiled binaries and linked from where the compiled binary is available for download AND the source must be located locally. I may have missed another interpretration. David may have the source local on the SF site, but I was unable to locate the downloadable tarball. The addition of a binary tree will allow for compiled executables/utilities that are not part of any core image or package that are available for LEAF. Please explain the need for a binary tree in src. Its purpose is not clear to me from your explanation above. Is it for source tarballs from other projects? There are several binaries that various people offer that are not part of a LEAF package (su, telnet, etc). It would be strange to stick a non-packaged src in the package src, but another thought would be to simply offer the binary src and not the entire LEAF package since everything else in the packages are script and their own src code. Thoughts? This would be source code that may not belong to any project. I will need to include atleast one (that I have already compiled) within the webconfig package I am playing with. Any thoughts, as we need to have the src tree up and populated! Agreed. We have discussed this tree for over a year now, and little has come of it. We can't cooperate effectively on releases/branches or packages until we have a working src tree. Well, there can be many ramifications if the src tree is not up. These concerns may include ridicule and loss of hosting, which I would rather not see. SF has been exceptionally nice in the free hosting and services offered. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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
[Leaf-devel] dnsmasq
There is a new caching dns server program that is supposed to also automatically add LAN machines to itself. A friend reported success with it, but I haven't looked much at it as of yet. I'm sure some of you might be interested into checking it out. http://www.thekelleys.org.uk/dnsmasq/doc.html -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] Multiple upstream links
On Tuesday 13 August 2002 12:31, Charles Steinkuehler wrote: Not that I have time to mess with this, but what's the current state of the art regarding multiple upstream internet connections and possible bandwidth sharing? I believe Shorewall has this support built-in from some posts a while back. I cannot say that anyone has reported back with a success as of yet though. Has anyone tried anything similar with BGP (or similar routing protocols)? It seems reasonable to expect a router that's not too many hops away (ie the ISP, or the ISP's upstream provider) would be running BGP, and while it's hopefully not possible to alter the route list, it might be possible to import route information. If you could do this on both links, and run BGP on the LEAF box, you could do *REAL* load-balancing (or am I missing something major here? I don't do much backbone type setup/config, so I could be completely off-base). You would need to run Zebra to run BGP (or other WAN routing protocols) and there are several people doing this with some form of LEAF. The WAN routing protocols themselves do load-balancing, and I would assume that some form of clock syncing would also be necessary, so I think your up the right path. WISP is running OPSF and RIPv2 instead of Bridging. The big concern here is that you won't want to run the WAN routing protocols on the WAN side without implicit permission from your ISP(s), since your router will automatically update itself to internet WAN routers unless you limit the protocol to the LAN side. Eric Kiser is more of the Zebra-person among the present developers and has indicated that he is/will be working on an image along these lines. Hopefully this makes a little sense? -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] OpenSSH 3.4p1 Trojaned
On Saturday 10 August 2002 09:45, Jeff Newmiller wrote: On Fri, 9 Aug 2002, David Douthitt wrote: There was recently a break-in at the main site for the OpenSSH 3.4p1 sources, and a back-door was inserted. The modified sources were caught quickly, but some may have been downloaded. The originals were not back-doored, and should be okay. The interesting thing is that this was not caught by some sophisticated digital signature, but by a FreeBSD porter who saw a bad md5sum and sat up and took notice... Time for a security update, Jacques? You know: This distribution is not vulnerable. That would probably be a good idea, but... a) He is on vacation for another couple of weeks. b) As previously reported here, the trojan seems to only affect machines compiling the source, so the resulting LRP should be clean. I believe Micheal Schleif has updated ssh packages that are not affected by this. I'd check the list archives around 1~2 weeks ago for the packages. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] Re: leaf-announce ML
I apologize for my absence, I have some personal business that has been taking up most of my time at the present. :-( In light of not catching the entire thread, I will give my 0.02. Most users, especially in a commercial environment are subscribed to the leaf-user and/or leaf-devel mailing lists. The leaf-announce list is seldom used and has few subscribers. If there is a security announcement to be made, we reach substantially more users making the announcement on the user and devel lists. It has worked without compliants until you brought up this thread. We could make these announcements on the leaf-announce list, or another list that would be more proper. but why force you, me, and other people to subscribe to yet another list. You say that you do not plan on staying subscribed to the user/devel lists, well it sounds like you are making a personal choice in regards to the way we have been operating this site. We work mainly from other security announcement sites, so maybe the debian-security list will work more to your liking. I see no since in changing what is working for us because you do not want to delete a few extra emails everyday... you can always check the leaf mailing-list archives if the other options do not work to your liking. Simply put, the present system is working well for us. Thanks for the thoughts! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] Affiliates
On Sunday 14 July 2002 14:20, Mike Noyes wrote: On Sun, 2002-07-14 at 11:43, John Klar wrote: Just some observations about my interpretation of the GPL. Perhaps they won't be terribly popular, but hopefully it'll make a few people *think*. [2] Pointing requestors to the upstream source is NOT good enough. The distributor is required to provide the sources THEY use. John, Would this apply to our packages (.lrp) also? If so, nearly all of our packages are non-compliant. If I recall correctly, source of packages only compiled (not modified) by us (LEAF) or the Linux Router Project were always pointed upstream. I think Mathew Grant was the only one to include package source along with .lrp packages he produced. AFAIK, in my understanding the SRC should be availiable where the binary is downloaded (linked is acceptable). Script is it's own SRC code. We've avoided problems by readily making the code available when requested (via mailing-list), though this probably isn't legal per the license. I believe all of Charles' packages are availiable legally since he links the src from the package download area of his site. The SRC does _not_ have to be available within the package itself. IMHO, you cannot restrict anybody from taking your GPL'd package and codistributing it with a closed source binary. There is nothing in the GPL that prevents your scenario as long as they honor the rules of the GPL, ie. providing source for all the open source bits that make up the distribution. Worse, if it is not apparent how to get that source from you, they can cause a lot of trouble. Wording your license to prevent this case is itself a violation of the GPL. Very true, I was simply giving my opinion and personal feelings, not a legal interpretation to the license. I am free to give my blessing and encouragement to whomever I want. I did not make this clear, which I apologize for. A company could very easily do something like this legally, but I would not encourage it. One more point to ponder. What if the whizzy closed source application were a piece of hardware? Would you object to Fred's Router Appliances, Inc. shipping a free copy of LEAF, including source and development environment with every box? Not at all. I believe the company is giving due credit to the software in this instance. If they claimed the software was entirely theirs, I would feel otherwise. I believe that the GPL states that you cannot modify existing GPL code and license it as closed-source. Again, this is my interpretation of the license and my opinion not withstanding anyone else interpretation or opinion. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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: is Bering GNU?
code that might happen to be included in one of the nasty Linux distributions available! Okay, I just found the developer.rtf and scanned the whole thing. Formidable task, but I only see part of the forest and none of the trees. I already know linux and there seem to be some very specific LRP details in there, but will it be done before it's out of date? I'm not saying produce a `./configure make make image` but if the environment for building the release was published, or easier to find, I'm sure there would be a lot more community support. At one point I kicked myself for not looking in CVS before, but when I got in there, was in disbelief -- no source, only doc. Ummm you haven't downloaded David D's development CD then? This would seem pretty obvious if you had actually read the Development FAQ or examined the authors' website that is linked from the download area. Are you saying that you install a Linux system, install all the source-code, hack all of it to your personal preference, compile it, install all of your customized changes, then complain to the Distro mailing lists and well-read LUGS that the end-result is not working like you intended AND that it is their fault that it is not working as you intended it? Sounds pretty moronic to me. So now I have problems with my image to resolve, why do those Belkin cards detect as reltek under RH but, none of the Bering modules will work with them??? Ummm... RH is not GNU and I wouldn't touch it. What changes have they made to the modules and auto-detection from stock GNU utilities? Are the RH modules possibly closed-source manufacturer drivers? Shoot, maybe you can reduce RH down to a single-floppy OS with complete development tools and compilers, include propietary modules, and get it all to work for everyone as they expect w/o any knowledge of the changes you made to get the floppy to work (you also need to account for any custom binaries changes that they may make to the system). How will I ever get my tulips back from my boss so I can test an image at home? Call him at home or run down to Best Buy and spend $10 on a Linksys LNE110TX card. This doesn't sound like a LEAF problem here. What am I going to do about making an image and quickly changing a few parameters (ssh host keys, network, firewall and other site information) or major structure (LaBera, ppp, ipsec, dns) without spending a ton of time hand extracting and compressing components? Use the included lrcfg utility like everyone else or write a better one or simply copy the necessary files to a GNU desktop (doesn't need to have compilers or anything like that) and create a package SRC tree and make you changes there (the GNU tar utility works great with the .lrp extension, I use it). I'm going to make my own distribution. reBering. Complete with scripts to mount and extract all the subcomponents, global configure, mix'n'match packages, compress and unmount. Great! Don't learn how to use something existing, just get mad and make you own. I be sure to flame you when I bork a custom binary and it doesn't work, or I can't find SRC for shell-scripts, or your documentation doesn't meet my expetations when I haven't even read it. Sounds like the best solution to me. Only I don't think I can call it GNU because since I'm in a hurry, I won't have time to reverse engineer the compile time options and source. I'd rather work on putting it on an eprom anyway. Not GNU, you must be incrediably retarded to think that I will ever let you develop something non-GNU after getting this far through this thread. Good God, you must be the core-of-all-evil for even thinking such a idea. You better have a complete SRC tree on there too with excellent (and compete) documentation. I think you know where all the source is, being that it has all been linked in this thread. Someone has already gotten LEAF to work off of an EPROM, but you would probably need to find the documentation and read it. In all sincerity, Bering is very cool. It could just be a lot better if it was more in the spirit of _encouraging_ open source development rather than barley qualifying, actually I bet if it was audited, it wouldn't pass. If there are scripts to tar and gzip a lrp package, why aren't they part of a tools.tgz right beside package_src.tgz and compile_configs.tgz next to the Leaf_UML packages and extraction instructions for odd archives? I know asking for doc is a lot, but maintaining a file of command lines used to make the binaries from source would be an excellent first step. I will also expect this in the /usr/local/src and /doc directory of your image. It should meet my expectations without any reading being necessary. You might what to start from the Bering documentation, it is the most complete documentation of any OS/distribution that I have been exposed to. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net
Re: [Leaf-devel] Affiliates
On Friday 12 July 2002 12:31, Mike Noyes wrote: On Mon, 2002-07-08 at 15:45, guitarlynn wrote: Lynn, Thanks for the feedback. :-) I was hoping these proposals would generate more discussion than they have. I'd really appreciate additional feedback from our project members. I don't want to start affiliating with companies or create a consultants list, if it's going to upset our project members. Agreed, and my opinion certainly doesn't necessarily reflect anyone else's opinion. If they're gleaning LEAF GPL'ed code and charging for it, it would seem fair (fill in the blank). :-( Would you elaborate on this? How does it apply to the corporate affiliation idea above? Personally, I would be against something similar to a company taking a LEAF CD/IDE release, putting a closed-source web-configuration application on it, and selling it unless a large amount of the core distribution was also re-written. I am against adding one or two packages to a stock GPL'ed release and selling it as opposed to simply selling the package that they are offering. The current development of anti-virus/email-scanning for commercial use is an example of something that is fine with me they are selling their own code/package. IPNuts is quite fairly an entity of it's own right and the core is a highly modified LRP 2.9.8, which allows them the right to use it commercially (IMHO). My original concerns where over their use of LEAF VPN packages (IPSec, PPTP, CIPE, etc...) only on their for-sale releases and promoting these packages with web-configuration as the reason to buy it. If I interpreted the response correctly, they are not using LEAF VPN packages, but rather some other closed-source VPN program instead. My other concern(s), is their use of incorperating Bering and Dachstein IDE, CD-ROM, and wireless code into the sale-only products w/o making a similar product available for free (only the floppy is free and not in development anymore as I understand it). Any concerns over the use of Dachstein and Bering code in this way should be expressed by the respective authors. In closing, if your planning to sell code, then write it and sell what is yours (or largely yours) to sell. If your not planning to write much code, but need to make money, do it with consulting and the labor that you personally put in. I've sold a bit of consulting and LEAF installs, but never once have I thought of charging for the software. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Location for scripts during startup
On Thursday 11 July 2002 14:36, Charles Steinkuehler wrote: weblet runs script to gather all package conf files (/var/lib/lrpkg/*.conf files) to generate the configuration display component in weblet (to replace the hard coded one in the Dev Demo now) We can add an init.d script to do this w/o any problem. weblet runs script to gather weblet addon package conf files (/var/lib/lrpkg/w-xx.conf files) and to regenerate its /var/lib/lrpkg/weblet.conf file to these addon config files This is probably something for the init scripts to deal with (if required). Maybe an added button on the form to reload the init script via svi. The idea here is to simplify the weblet system so that there is a small base dashboard (much like it is now) with the ability to add new components and manage them as easily as adding additional lrp packages. Any startup-time config should be handled by the init scripts (/etc/init.d /etc/rc?.d/), but a lot of the site content should probably be generated on the fly...this shouldn't be too CPU intensive if a proper directory structure for weblet add-on packages is created. There is a project in progress to do this already...see the Richard's e-mail and weblet demo site. Add a directory in the cgi directory for placement of the seperate package modules. The module can be added to a package or manually this way w/o messing with lrpkg. A simple script that retrives a module list with ls would probably suffice. I am really against simply using the existing lrpkg system for this config unless we can text-to-html cat file and filter the file for option=value into a form decently. This option sounds more like a re-write of text-to-html and doesn't simplify the base configuration as much as I'm hoping. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Affiliates
On Wednesday 10 July 2002 00:27, kitakura wrote: Don't worry. I am following GPL . Thank-you :-) I'm looking forward to seeing IPNuts succeed, and I appreciate your time and effort with my concerns. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
On Wednesday 10 July 2002 19:41, Michael D. Schleif wrote: Yes, these are our (leaf) _cvs_ versions. However, how can a user select net-snmp v4.2.4 when my net-snmp version is 1.1? Well, the editor session that pops up during a commit can be avoided with the -m text switch added to the commit command... I use for notes based on the change(s) from earlier CVS versions of the same package. You can use this to differeniate between net-snmp v4.2.4, 4.2.5, and 5.0.1 (not to mention any other notables you would like to add). As I am working on doing, if you would like certain versions of the same CVS file(s) presented in a clear and special manner, simply link them from a web page that presents this information. What should I, joe-leaf-user, expect to find while perusing ViewCVS? Joe-User is usually looking for an exact package in CVS rather than aimlessly attempting to find something random. I think most major software groups use CVS from linked web pages as well. Right now, I'm only thinking about what goes under my devel/helices tree. How that gets tied into dcd, bering, or whatever, is another issue, which I've decided to ignore for the moment. Remember, this all started with your request to me to commit my net-snmp packages. I committed the LRP's only, and since I've begun to plan committing several other items. It's this planning that has me hung now; but, I'd really like to put that behind me ; I think you are doing the smartest thing by planning you tree. A good plan will save tons of time and effort at a later date by foreseeable circumstances. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] dcd: cleanup issues ???
On Wednesday 10 July 2002 20:06, Michael D. Schleif wrote: Also, in standard dcd v1.0.2, what program uses /etc/rpc? NFS and SUN login. I think a few people are using this style of access on LEAF boxes. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Affiliates
First of all, I would like to thank-you, kitakura, for updating us on your project and clarifying any assumptions that I made based on what little information I interpreted from various websites. TY :-) I offer my apologies for any false information/assumptions that I may have made! On Monday 08 July 2002 19:26, kitakura wrote: Packages in http://www.s-me.co.jp/mosquito/mos3_4/packages/ are GPL lisence.(and Other open source license decided by Auther.) WebAdmin is GPL. ( only japanese. a part is english) but, since we assert license, the user interface code of WebAdmin for [, such as VPN, ] a specific package is unacquirable in online. WebAdmin has the menu form which can be added. # And If not related to me, WebAdmin is used also for # firewall distribution of Japan in time. So, the only closed-source code is some form of VPN application that your distribution is using that is not easy to work around either! Good job! config.lrp is also my code. it is GPL.This can gather configuration file written .conf. I think that it is useful. Webadmin.lrp,config.lrp,rc.lrp ,etc.lrp and root.lrp can not use other leaf distribution ,since they are imcompatible. But other packages may be compatible with little modify,I think. A part of them includes code for Webadmin and rc.( but they are gpl.) Great! But when webadmin is upgraded, a license may change. I'm sad to hear that, but this is difficult to avoid when something goes commercially owned. # I'm developing kernel 2.4. It is going to use the linuxrc code of Bering. # I am thankful to many developers. This is where I was really concerned. Are you using Bering and/or Dachstein IDE code for sale-only products that do not have open code equivilents (ie... floppy-only free offerings) or planning to use Bering linuxrc code in something closed-source? I personally have reservations about these possibilities, when it is not 100% personal code in the particular application (not to reflect on any other developer with this opinion). I guess what I am getting at is this: How would you feel if I modified Webadmin.lrp and release it as a closed-source commercial offering? I not saying that this is what is being done... but rather looking at what _could_ happen at some point in the future. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Affiliates
On Monday 08 July 2002 08:55, Mike Noyes wrote: Mosquito From what I was able to glean from babelfish, it looks like Mosquito was purchased by a VPN company (SeSame), renamed to IPnuts, and was taken commercial. Does anyone have information on Mosquito development status? http://babelfish.altavista.com/urltrurl?lp=ja_enurl=http%3A%2F%2Fwww .s-me.co.jp%2Fnews%2F020516.html It appears that they now a cd-release for sale and have/working-on a 2.4.x kernel with VPN, SSL, and *SQL capabilities. I'd like to know what is going on since they are now commercially owned and we haven't heard from anyone since the buyout. Corporate Affiliates proposal: I'd like us to start affiliating with corporations. However, I'm unsure of the point where we should consider a company for affiliation. Do they need to provide code resources and a link back to us for consideration, or just a link back to us? Examples: * Echogent: fwlog.pl cgi-script, Echowall, ftp white paper, Scott Best is a project member. * SeSame: Mosquito image, various packages, Webadmin, and reciprocal link. * Bits Over Atoms: Reciprocal link to us. If they're gleaning LEAF GPL'ed code and charging for it, it would seem fair (fill in the blank). :-( Paying for Consulting and site setup is fine with me (I do a little of this), but sale of the software (and in particular closing of code) is quite another, IMHO. Consultant List proposal: I'd like us to create a web page with links or contact information of consultants willing to contract for LEAF installations. Should we use the linuxports.com site for listings, or something else? This sounds good to me. I really don't know how consultants could be qualified by the project though. It could be rather easy to get over your head in a short-term project. These proposals may not be good ideas, but I thought they should be discussed. Discussion is a good idea! :-) -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Hi, I'm new.
On Thursday 04 July 2002 10:21, Julian Church wrote: Hi everyone. I've been hanging around the leaf-user list for over a year now, and a couple of weeks ago Mike Noyes asked me if I was interested in joining the LEAF developers' group. Now I'm back from my holiday (Glastonbury music festival) I'm here to introduce myself. Welcome! As far as Linux experience goes, besides running LEAF at work, at home and at a few friends' homes, I've been doing a lot of reading over the past 6 months, to try to Learn Linux properly. Still, I feel very much like a beginner, especially compared with some of the people that seem to be involved with LEAF. Take a weekend and do a version of LFS (LInux from Scratch), you'll learn more from that than most people want to... quite a tool to learn about the Linux core and how it works together. ;-) I've been exploring the leaf sourceforge website to see how I might be able to help. Since my job has given me a fair bit of experience in writing, editing and converting technical documentation and I'm already quite familiar with DocBook XML, I was thinking that perhaps working on documentation for LEAF would be the best way I could help. Perhaps I should start by converting some existing docs, then take things from there. If you have suggestions which docs to start with, please let me know, otherwise I'll just dive in. Great, we can always use more help with the docs! I need to finish updating the FAQ's (sticky-note), but almost everything else needs to be updated to xhtml-strict (howto's, guides). Mike N can probably tell you where the updates are most needed. I really need to finish the FAQ's. Glad to have you aboard! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by:ThinkGeek Caffeinated soap. No kidding. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] sh-httpd weblet web-config
On Tuesday 02 July 2002 08:33, Charles Steinkuehler wrote: First, a point of order. In my view of the world, there are two major issues currently being discussed: snip I think it would probably help prevent confusion if mods to the web server itself refer to sh-httpd, while issues related to making html/cgi code to monitor or configure the system use the weblet moniker. Agreed, I attempted to clarify this earilier. I considered anything with configuration a seperate entity, but if Weblet is modularized the argument is moot. With that out of the way, I completely agree with the idea of forming a group to work on the weblet portion of the configuration problem. This can probably be done with very little effort completely within the bounds of the existing LEAF SF project. With a CVS directory somewhere in the existing LEAF tree, folks can share code and updates, and even developers w/o LEAF SF developer status can check-out code and posts diffs to the leaf-devel mailing list (much like the way the busybox list works...I've sent in several bug-fixes to busybox that got incorperated into the main code-base, but am not a registered busybox developer). I think the leaf-devel mailing list will work fine as a communications mechanism for now, and we can always make a new leaf mailing list if the traffic gets too high for the leaf-devel list (unlikely, at least for now). This is fine, I was making sure this was an approved method in accordance with the site admins. I can commit to help with the sh-httpd mods, and I think I can improve the performance of cgi scripts dramatically. I can probably help with a bit of the html/cgi scripting (ie general architecture and maybe solving any thorny scripting issues that crop up), but I don't have time to commit to a huge chunk of the project. I don't have a huge amount of time myself, but I can work on the core integration with the present Release(s) configuration to a script-based one. In honesty, I really haven't gone through much of the present CGI/Weblet scripts yet. If I can catch up with Richard's changes, I'll be happy to help in any manner there as well. It appears that I was working in a reverse order to everyone else... ;-) It looks like Richard's generally headed in the right direction with his mods to the existing html/cgi code, especially with the abstraction of the content. Has anyone else made much progress along these lines, or should work start on using Richard's framework to start building a web-config architecture? I think Richard is further along than anyone else with Weblet, I could contribute some form templates and some variable/conf file proposals as well. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] sh-httpd weblet web-config
On Tuesday 02 July 2002 10:29, Charles Steinkuehler wrote: 2) authentication may be an issue, but maybe this would bloat weblet, especially if we still want to support floppies I'd prefer to avoid the authentication entirely with sh-httpd, but basic authentication may be required. Note that even if implemented, I wouldn't really consider this amazingly secure...it would simply be a way to provide some sort of password so Junior couldn't edit the firewall rules on a whim, enabling the latest [mal|share]ware program to work. I think any form of secure authentication, as well as any encryption or tunneling should be handled by a seperate program (ie ssh, ssl, zeebee, or similar). After checking quite a few options available, I believe IDE releases should use ssh tunneling since it is likely already being used and floppy images should use zeebelee for space limitations. The Weblet would be limited to localhost and all configuration would be authenticated via the particular tunnel program used. I suppose zeebedee could be used for everything, but I'm not sure how two tunneling programs would react to each other if used at the same time. This would also limit the security risk due to any code we produce. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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
[Leaf-devel] Web-config devel
As stated before, there appears to be several people doing preliminary work on modifying Weblet to be used as a web-based configuration tool in the LEAF community, but not limited to the LEAF developers. It would be safe to assume that at some point redundant work will be done to achive the same end result. It would seem to be logical to form a consolidated group of developers to work together on this project, so that 1) development would be faster, 2) each developer could focus on a particular piece of the code, 3) the finished product would likely be better and more portable in respect to LEAF itself. How (and if) a group to develop a web-config package should be formed and run within the LEAF site is questionable and any idea's and advice is appreciated for a direction to take. At the moment, the work that has been done has been considered to be an extension of the weblet package and/or sh-httpd. Personally, I find a Web-configuration product to be something that is it's own entity, and be treated as such even though extensions will be made to the present sh-httpd code and integration with weblet will be a safe assumption. Shell/CLI environment configuration will need to be availible and the finished package should be optional as a package to the LEAF release(s) used on. I think a dedicated CVS branch, a means of communication, a schedule, and a roadmap would be general requirements to a clear and efficient development cycle for such a project. Is there an existing way to do and or all of this within the present LEAF infrastructure? Thoughts??? -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] Weblet Enhancements
* be tunneled, not just authenticated. I am proposing the use of 127.0.0.1 (localhost) for use of web-config within the scope of allowed host(s) for Weblet/web-config and the use of zebedee for remote access through any other machine... LAN or WAN. The authentication is built into zebedee and ALL information is encrypted. On Friday 28 June 2002 08:42, Joey Officer wrote: Last night at home I wasn't sure if the message was even going to go through. Glad it did! I'm not very familiar with CGI, or really anything html (I can write 'hello world', that's about it!), but from my experience w/ mrtg, I was under the impression that it was Perl based. If this is the case, how would you run a similar type program? Any interpreted executable can be CGI, be it shell, perl, C, whatever. On Friday 28 June 2002 00:44, Richard Amerman wrote: guitarlynn, Did you ever spend any more time playing with mosquito and its webadmin piece? I'm now more up to date with some of the weblet discussions in the past few months. Yes, but it doesn't allow for configuration on the router itself and is written mostly in Jscript. This is not the direction I would like to take. On Friday 28 June 2002 00:16, Richard Amerman wrote: What if we modified the architecture of Weblet so that you can add standard plugins (in the format of the standard LEAF pachage format, LRP for now). Actually, with the packaging system the only hard part would be links from index.html. I did a bit of checking into alternitives to Weblet (by no means exaustive) and it looks like sh-htppd (weblet) might still be the best answer. The only other option I've found likely is thttpd if we are using compiled CGI scripting. I really do not think this will be necessary either. OK, that does it for now any ideas or other other thoughts??? ~Lynn -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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-user] Re: [Leaf-devel] Re: Software write-protect (Was: Re: [leaf-user] Floppies)
How about if you modify tinylogin to email [EMAIL PROTECTED] everytime the box is logged into??? -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] Development Annoyances...
On Wednesday 26 June 2002 16:24, Michael D. Schleif wrote: This is pretty much where Serge Caron came in with `enclosures' . . . at least, part of his enclosure construct does exactly what you describe . . . I use it for early package development. It's nice to simply delete the update(d) package and have a clean system again. I'm using a PacketFilter box in production as well the connection auto-detection and hardened system is pretty much 'boot and forget' depending on your particular use(s). There are some very interesting things in there ;-) -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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
[Leaf-devel] Weblet-webconfig
## Moved from (leaf-user) # On Wednesday 26 June 2002 17:33, Richard Amerman wrote: I currently have a modification that has a new list of all the configuration files on the left side. I have included all the main networking files, modules file, ppp files, and all of shorewall. I did this with a combination of index.html modification (including some cleanup, primarily with an added style entry above that took out all the remaining style info bellow) and some changes in the showlogsx cgi scripts. Very nice, Bering is setup nicer in this way. DF's network.conf really needed to be chopped up to be cleaner in the end. I'm modularizing the configuration which can reduce the total space taken up and also allow for reduced (auto-)backup time/resources. I am planning to look at something along the lines of SSL for authentication or a SUID binary, but I haven't researched into how feasible this would be. In any regards, some form of authentication needs to be implemented. I plan on setting up a demo box outside our firewall that everyone can access to check out these changes. I will let the list know when I have this set up. Neat, let us know! ;-) -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] Weblet-webconfig
On Wednesday 26 June 2002 19:13, Richard Amerman wrote: Thanks for moving the thread Lynn! np I actualy did set up the config dump. I now have two new links, one that gives you a single page with all the major configuration files from /etc and another for all the Shorewall files. These two lists are hardcoded in the scripts so it is a temporary hack. I would like to directly link these to the packages so that they are dynamic. I would also like to make the initial page more dynamic, move it from a static page to a seperate script. I think that is along the lines of my thinking as well. Reguarless of any changes to the weblet content it would be best to secure it. If it was secure, this would open the door to web remote management. Web remote management could start with basic control panel items including: Bringing interfaces up and down Bring Shorewall up and down I won't release anything that is not secured via authentication. This would cause more problems for the project than what the ease of administration would be worth IMHO. In curiousity, being that you are a little further along with your project, would you mind checking out stunnel for authentication possibility. Someone is using it, but I haven't researched it (yet). A quick look would indicate that it could (should) be compiled statically. The dependancies look huge though. http://www.stunnel.org/ # Pre-compiled packages. http://www.s-me.co.jp/mosquito/mos3_2/packages/ From their you could eventualy edit the config files directly. I know this is facilitated fine with the config menus, but if there was a full web interface to LEAF this would open things up to a much wider audience. Well, my thought was to create and CLI config script or menu program instead of forcing direct edits with CLI. Something similar to the Install-scripts I was playing with: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/guitarlynn/scripts.tar.gz Have you had to make any concessions to get the conf files to write because of permissions? I've been expecting to have problems with the UID weblet runs with. If so, I imagine that you could still use the weblet's UID with 744 permissions. Any thoughts-experiences??? -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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] New VPN/firewall security solution
On Wednesday 05 June 2002 23:01, Steven Peck wrote: I believe this is it. snip In brief, it appears to be a way to establish secure end to end communications across NAT and the Internet specificcaly using the UPnP standard proposed by Intel. Though SSH doesn't come out and say this, they are basically the same idea. NAT causes problems with multiple clients doing the *same* thing at the same time. Say like multiple IPSec connections on port 500 leaving the NAT'ed Gateway. What is proposed here is a Nat-D type added to the approved header method (tunnel and transports are the current standard types). The Nat-D header would indicate the presence of a second added header that includes the port number used by the machine requesting the service (IPSec for instance). With this NAT'ed port information added to the packet payload, the gateway(s) will be able to indentify and decode the second header and send it to the exact machine that requested the information (identified by the port the connection was initialized on). Although this may not be the best method proposed to deal with NAT, this is a very easy method to implement and will work on all NAT and Proxy machines that will support identification and routing suggested in the docs. In special cases such as the iSCSI network storage devices, this can be built directly into the device driver eliminating the need for encryption by a processor because it is built into the device (driver) itself. What advantage it would give to us at this time would amount to faster thoroughput times and automatic resetting of dropped tunnels, assuming that FreeS/WAN supports the changes in any case. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] new lcd.lrp package
On Friday 19 April 2002 02:22, David Douthitt wrote: I've been working on an lcdproc.lrp which contains LCDproc in its latest version. I included support for SVGA, ncurses, and MatrixOrbital LCDs. Is this yet another case of multiple developers crossing paths? I imagine so, other than yours will have a lot more options than mine does. I simply packaged Charles' binaries for lcdd and lcdproc and wrote some scripts to take some options for the HD4470 chipset. I wasn't aware there was already a package for this, so I just released the one I was using. Yours sounds a lot more functional. Thanks! :-) -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] RC-1 image of IPSec-enabled Dachstein available
During the last several weeks of testing, my IPSec-enabled image of Dachstein has not received any reported bugs. I have now posted a new image (with a couple of minor non-functional changes and the updated udhcp.lrp). There shouldn't be any more functional changes unless the I use Chad Carr's ported ipsec scripts and eliminate the need for the ifconfig and mawk packages. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/guitarlynn/dachstein-v1.0.2-ipsec-1680.bin?rev=1.3content-type=text/vnd.viewcvs-markup Find me some bugs -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] new lcd.lrp package
I've taken Charles' binaries and created a package for use with lcd's using the hd44780 controller (and some clone) chipset's. Init script is included and the package includes /etc/lcd.conf which contains all needed configuration options. It is available at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/guitarlynn/lcd.lrp Enjoy -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Updated Udhcp package
I've updated the udhcp package with the server's default lease time that is more acceptable to Win2K/XP clients and modified the client init script to 'release' a lease and quit (rather than re-starting after releasing the lease). The general LEAF package is at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/guitarlynn/udhcp.lrp The Dachstein/mountain-series integrated package is at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/guitarlynn/udhcp.lrp.dachstein Enjoy -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Package description file proposal
Who determines what keywords and categories apply to each package? I believe these tags will cause confusion if there is no set categorization template. Maybe there should be one file templated out with certain information, like source version, package revision, packagename, glibc-required, maintainer, etc put a space/comma seperated line similar to the LRP= line in syslinux.cfg for the repository. This would be easily parsed by awk for administration of the list... but this would require strict adherance to the template format to work. Version: 1.20-1 upx is not version 1.20-1 but version 1.20 (at least in this example). In your example, why did you indicate a release level of 1? Is the release level different than the hyphen would indicate? It would indicate to me that it uses the same compliled source-code, but the package scripting (for .lrp) has been revised/patched. This will likely happen on occasion since the package maintainer does add scripting for use with LEAF. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Admin script help
On Sunday 14 April 2002 11:53, Mike Noyes wrote: Jeff Lynn, Thanks for the help. :-) Jeff, I modified your script, and added Lynn's awk line. I hope I didn't muck it up to bad. Looks OK to me if the output is correct. Everyone, Is there a reason that our packages don't contain the program name in the version file? The majority of packages seem to work that way I imagine that they were done this way since you should already know the 'basename' to check the version #. The package listing you're making would be the first time that we've had a good reason for implicitly putting the packagename in the version file. Adding: echo 'basename $1' should give the packagename if you want that in the output as well. I've been looking at the ldd output, and I'm having a hard time figuring out how to determine glibc versions from its output. The best I've come up with is to look for the presence of libm.so.6. Is that correct? libc.so.6 was used as far back as libc-2.0.x from what I could find. I couldn't locate if it was actually in libc-2.0.x or backported from later release of libc for compatibility. Anyone that has worked making any libc-2.1+ packages probably knows. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Admin script help
On Saturday 13 April 2002 13:14, Mike Noyes wrote:
Thanks. This works fairly well. I still get errors from tar, but I
don't see any way to force it to ignore them.
Try:
Examples:
$ ./package-date.sh test.txt 21
To something like:
#! /bin/bash
find leaf/ -iname *.lrp |
while read file ; do
echo `basename $file` $'\t' \
`tar tvzf $file 21| awk '{print $4}' | sort -n | tail -n 1`
$'\t' \
$file;
done |
sort
Now all I have to do is get the program name and version. Then
determine the libc version with ldd.
Jeff provided this snippet for checking the libc version with ldd.
I added a line to check for the version # to the script:
md ${package}
cd ${package}
gunzip ${packagelrppath}
ldd `ls bin/* sbin/* usr/bin usr/sbin usr/local/bin usr/local/sbin`
\
| grep -v ':$' | sort | uniq
awk '{print $1}' var/lib/lrpkg/${package}.version
cd ..
rm -R ${package}
I'll have to take a look at each package to determine program name
and version.
var/lib/lrpkg/package.help
var/lib/lrpkg/package.version
Any suggestions for accomplishing these tasks are appreciated.
Thanks again for the help. :-)
--
~Lynn Avants
aka Guitarlynn
guitarlynn at users.sourceforge.net
http://leaf.sourceforge.net
If linux isn't the answer, you've probably got the wrong question!
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Dachstein port forwarding FAQ
On Thursday 28 March 2002 01:42, Matt Schalit wrote: You probably caught this one already, but if not, you're missing a word in the second sentence of para 4. Thank-you, Matt, once again... it's fixed. Many thanks for all that you've done to help the cause. You've really done a lot since you joined up. ty ;-) I've learned so much from this project over the years, that it seems natural to give back so that others can do the same. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Basic IPSec HowTo
}. The connection names in the sample /etc/ipsec.conf used earlier would be roadwarrior and subnet-to-subnet. 12) TROUBLESHOOTING The output of a few commands can be the best source of information if your VPN connection does not work. The results of: Tell you: - ipsec barfVirtually everything about what is happening and what has happened with ipsec. cat /var/log/auth.log Authentication success and failure messages. ipsec look, route -n, and ifconfigShows a connected tunnel through interface ipsecX. ipsec auto --status Shows the status of the connection. Look for authentication failure or success with ipsec barf and/or the /var/log/auth.log file. A failure in these files usually indicate that port 500 and/or protocols 50 and 51 aren't making it through the firewall or your authentication key is not setup properly. If the authentication was successful, check ipsec look, ifconfig, and/or route -n. You should have an interface ipsec0 up with the external interface's ip address and a route showing the remote subnet/host via the local default gateway or your ISP. Failure at this point would indicate improper ipsec.conf configuration or port 500 not allowing traffic. The contents of /var/log/messages will show denied packets at the firewall check for any denied packets at port 500. If these commands do not help you locate the problem, monitoring the firewall activity will be the next source of information. Use the command ipchains --zero and note the output that refers to port 500 and protocols 50 and 51 or use a packet sniffer, while attempting to initiate a VPN connection. 13) LINKS LINKS TO BE ENTERED HERE ### # end of HowTo ### -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Dachstein port forwarding FAQ
If everyone is not bothered by anything contained in this FAQ,
I'll format it and submit it to the docmanager in the next day or two.
Thanks,
~Lynn
## start of FAQ
Q. How do I port forward a service through my Dachstein firewall to
the my internal network?
A. There are four steps to port forwarding in Dachstein. They are as
follows:
1) Edit /etc/modules and uncomment the IP_masq_portfw module.
Save the file and exit. You may need to download this module
and copy it to /lib/modules on your running LEAF system if you
are using the floppy version.
2) Edit /etc/network.conf to open the desired external port you would
like to to forward with one of the two available options:
# TCP services open to outside world
# Space separated list: srcip/mask_dstport
EXTERN_TCP_PORTS=0/0_www
# -or-
# Indexed list: SrcAddr/Mask port [ DestAddr[/DestMask] ]
#EXTERN_TCP_PORT0=5.6.7.8 domain 1.1.1.12
EXTERN_TCP_PORT0=0/0 www
Use only one of these two forms of entry. If you use both, only the
one you use first will have any effect. Whichever one appears second
in the file will be disregarded. Be sure that the one you are not
using is commented out with a # at the beginning of the line.
You can use either the actual port number itself (for example, 80),
or you can use the symbolic name for the port that appears in the
file /etc/services (in the same example, www).
3) While you're editing /etc/network.conf, you will also need to
specify the port forwarding itself. You do this with:
# Uncomment following for port-forwarded internal services.
# The following is an example of what should be put here.
# Tuples are as follows:
#
protocol_local-ip_local-port_remote-ip_remote-port
INTERN_SERVERS=tcp_${EXTERN_IP}_www_192.168.1.1_www
#-or-#
# These lines use the primary external IP address...if you
need to # port-forward
# an aliased IP address, use the INTERN_SERVERS setting
above #INTERN_FTP_SERVER=192.168.1.1 # Internal FTP server to make
available INTERN_WWW_SERVER=192.168.1.1 # Internal WWW server to
make available
As with Step 2, you can use one of the options or the other of
these options, but not both. I suggest using the first option, since
all ports and addresses are explicitly stated and you can use
different ports coming into and forwarded out of the firewall. It
also allows more
flexibility for using non-standard ports.
I personally use port 81
for my external web-services, but use port 80 on the internal
network. The first syntax allows for forwarding the external port 81
to the internal port 80 with a line like this:
INTERN_SERVERS=tcp_${EXTERN_IP}_81_192.168.1.1_80
After you are finished with the configuration here, save the file
and exit the editor.
4) You are now finished with all the configuration. You should now
the lrcfg menu system (if you are not using it already) and
choose the backup option. You will need to backup the etc and
modules packages. After both of the packages are backed up, exit
the menu system and reboot the Dachstein machine. Your new port
forwarding setup should now be operational.
# end of FAQ
--
~Lynn Avants
aka Guitarlynn
guitarlynn at users.sourceforge.net
http://leaf.sourceforge.net
If linux isn't the answer, you've probably got the wrong question!
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Upgrading Bering to libc 2.2.x?
On Wednesday 20 March 2002 15:40, Simon Blake wrote: I have a vague memory of somebody explaining to me that that the reason that 2.2.x is so much bigger is because it has a bunch of backwards compatibility stuff in it to allow binaries linked against 2.0.x to continue to work. So if one was to go through and rebuild all the binaries in bering against 2.2, then the 2.2 could be cut down to a size not too much bigger than the current 2.0 libc. But I could be on crack. I investigated libc 2.2 when it first came out and all pointers to the bloat was support for both 32-bit and 64-bit processors. If you could drop the 64-bit support out of the source you would likely reduce a huge amount of compiled code (this may be a config option). I could be on crack myself though, this information was skimmed from a similar discussion on a libc newsgroup post. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Upgrading Bering to libc 2.2.x?
On Wednesday 20 March 2002 17:23, Charles Steinkuehler wrote: Dang! There goes my alpha version of LEAF...I guess I'll just have to keep my resident Alpha systems running RedHat 7.1 busy crunching seti@home work-units (I've got 5 DEC Personal Workstation 500a's, three actually running). I can't say about the Alpha's inclusion to this statement, being that they have been supported for quite a long time. The 64-bit support bloat that was referred to seemed to be geared towards the upcoming Intel and AMD 64-bit processors. It was just something I found while perusing the net on the subject. I was just given a couple of old IBM RISC workstations. I'll have to figure out something to do with those. If I ever get back to LEAF development work, I'll look into the newer glibc. One of the first things I want to do is build a portable compile environment, and other than the compiler itself, the c library is about the biggest part of the puzzle, (as well as the biggest single chunk of code in most LEAF distributions)...I'd like to see what (if anything) can be done to squeeze the c library down to size, including various compiler options, as well as compile-time defines. Ah, you're a braver soul than I ! ;-) -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] net-snmp.lrp startup problem
On Tuesday 19 March 2002 21:52, Matt Schalit wrote: Matt Schalit wrote: Bino Oetomo wrote: Dear All. I just tried to use net-snmp.lrp. it's in Oxygen packages directory. I use it with DachStein image. Other people have had issues with this version with Dachstein. There is a new, tested version that works at: http://leaf.sourceforge.net/devel/helices/ -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Dachstein port forwarding FAQ
On Monday 18 March 2002 19:47, Ray Olszewski wrote:
Excellent idea, Lynn, and good first draft. I suggest a few edits.
(I've pulled them out, but left your doc at the end for reference.)
Thanks Ray, I am going to learn to re-read these things before I
post ... or atleast spell-check them. ;-)
Here is a new copy with Ray's suggestions
## start of FAQ
Q. How do I port forward a service through my Dachstein firewall to
the my internal network?
A. There are four steps to port forwarding in Dachstein. They are as
follows:
1) Edit /etc/modules and uncomment the IP_masq_portfw module.
Save the file and exit. You may need to download this module
and copy it to /lib/modules on your running LEAF system if you
are using the floppy version.
2) Edit /etc/network.conf to open the desired external port you would
like to to forward with one of the two available options:
# TCP services open to outside world
# Space separated list: srcip/mask_dstport
EXTERN_TCP_PORTS=0/0_www
# -or-
# Indexed list: SrcAddr/Mask port [ DestAddr[/DestMask] ]
#EXTERN_TCP_PORT0=5.6.7.8 domain 1.1.1.12
EXTERN_TCP_PORT0=0/0 www
Use only one of these two forms of entry. If you use both, only the one you
use first will have any effect. Whichever one appears second in the file
will be disregarded. Be sure that the one you are not using is commented
out with a # at the beginning of the line.
You can use either the actual port number itself (for example, 80), or you
can use the symbolic name for the port that appears in the file
/etc/services (in the same example, www).
3) While you're editing /etc/network.conf, you will also need to specify
the port forwarding itself. You do this with:
# Uncomment following for port-forwarded internal services.
# The following is an example of what should be put here.
# Tuples are as follows:
# protocol_local-ip_local-port_remote-ip_remote-port
INTERN_SERVERS=tcp_${EXTERN_IP}_www_192.168.1.1_www
#-or-#
# These lines use the primary external IP address...if you need to
# port-forward
# an aliased IP address, use the INTERN_SERVERS setting above
#INTERN_FTP_SERVER=192.168.1.1 # Internal FTP server to make available
INTERN_WWW_SERVER=192.168.1.1 # Internal WWW server to make available
As with Step 2, you can use one of the options or the other of these options, but not
both. I suggest using the first option, since all ports and addresses
are explicitly stated and you can use different ports coming into and
forwarded out of the firewall. It also allows more
flexibility for using non-standard ports.
I personally use port 81
for my external web-services, but use port 80 on the internal network.
The first syntax allows for forwarding the external port 81 to the
internal port 80 with a line like this:
INTERN_SERVERS=tcp_${EXTERN_IP}_81_192.168.1.1_80
After you are finished with the configuration here, save the file and
exit the editor.
4) You are now finished with all the configuration. You should now
the lrcfg menu system (if you are not using it already) and choose
the backup option. You will need to backup the etc and modules
packages. After both of the packages are backed up, exit the menu
system and reboot the Dachstein machine. Your new port forwarding
setup should now be operational.
# end of FAQ
--
~Lynn Avants
aka Guitarlynn
guitarlynn at users.sourceforge.net
http://leaf.sourceforge.net
If linux isn't the answer, you've probably got the wrong question!
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Oxygen Installation Guide
On Sunday 17 March 2002 09:26, Mike Noyes wrote: Everyone, I'm seeking a volunteer. :-) Would someone like to create an Oxygen Installation Guide? What kind of scope do you want with it? Just for future reference, on the top of my todo list, I plan on doing a IPSec Quick-Start FAQ, a PacketFilter Quick-Start Guide, and later on a Zebra FAQ (that would likely be used with Oxygen). I won't say that I am the best person to do a well-rounded Oxygen Guide, I think Matt and several others has much better experience than I do with Oxygen. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Embedded Systems Conference
On Saturday 16 March 2002 01:01, Matt Schalit wrote: Mike Noyes wrote: Everyone, This is a summary of yesterdays browsing of ESC. I had a good time, and I met Ray, Larry, and Matt. Well that's a meager summary :) Mike and Matt, Thanks for the summaries and links to products. I interested in finding some of this stuff, though my $$$ are pretty lacking right now. The Crusoe boards sound great if I can find some with 2+ ethernet under $500I'll check with the linked companies, they sound rather promising! There is always something nice about meeting someone you've never seen after years of communication, with I could have gone myself ;-) -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Embedded Systems Conference
On Saturday 16 March 2002 16:06, Mike Noyes wrote: Matt, We talked to him about ten minutes before your arrival. From what I understood of the conversation, he was suggesting the use of a free port/signal line (parallel and serial ports were discussed) on the motherboard to switch the state on the ADM. This is still hardware based, but is now switchable using a remote interface. His remote software authentication suggestion was snmp or pgp based. I think what we are hoping for is a jack for a mouted switch (either internal or external) to turn the WP on or off manually. It would be nice to be able to do it remotely, but in all cases that is no better than deleting the mount command during init. PGP is supposed to be dropped from development now (open source anyway). GPG would probably be better, but if going that route, maybe RSA/DSA would be the most secure route. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] How do I request help FAQ
On Monday 11 March 2002 03:46, Matt Schalit wrote: The section below needs a little more work. The syntax shown will overwrite forward.txt. It is fixed, thanks!!! And I request again that you add in ip route show /mnt/routes.txt and remove the netstat -rn, only because ip route show is on every distro (correct?) It is as of last week. Fixed as well. Mike, could you add the new revision I added to the website. Thx! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] How do I request help FAQ
Alright, the how do I ask for help FAQ is posted along with updates in all but 1 or 2 of the rest of the FAQ's up to Section 7. You can check out the new FAQ at: http://sourceforge.net/docman/display_doc.php?docid=1891group_id=13751 Thanks to everyone for helping put it together!!! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] TS-req-HowTo / How Do I Request Help?
On Friday 08 March 2002 11:21, Ray Olszewski wrote: I like Richard's changes too ... except that he forgot to add himself to the Acknowledgements list. Lynn, would you do that before committing? (And, Lynn, thanks once more for starting and keeping the ball rolling on these updates. As you can see, even I manage to do some work here with sufficient goading, and updates will be a real benefit to LEAF and its user base.) Definately, and I'll squeeze Matt in there too wonderful suggestions and work everyone! The feedback and opinions can really improve an already great submission. *Side note, I just picked up a 2 week job starting Monday. I'll be a little slower for the next couple of weeks. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Slashdot article
On Monday 04 March 2002 10:02, [EMAIL PROTECTED] wrote: For those keeping score, it seems that a firewall article made slashdot and leaf-project is suggested in a lot the replies, as are several others. http://slashdot.org/articles/02/03/04/0047215.shtml?tid=172 It appears that Brian Boonstra made the first LEAF plug, and maintains that LEAF is his preference. Haven't heard from him in some time. :-) -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Slashdot article
On Monday 04 March 2002 15:10, Matt Schalit wrote: I hope our Docs are in order so we can refer them rather than have to repeat things we've already hashed out. If I get motivated this week, and I intend to, I'm going to work on JN's sshd, tinydns, and dnscache docs which should take about an hour or two, then move onto the Docmanager stuff. I got around 14 more FAQ's updated, formatted, and submitted over the weekend. 3 more are almost ready and pending author approval of the changes. Mike is more than buried right at the moment, a couple of days would have helped matters considerably with the load he has right now. The current FAQ's I've updated contain virtually everything up to and including Section 6. The five remaining ones I haven't touched included in that group with virtually require rewrites. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Slashdot article
On Monday 04 March 2002 15:33, Matt Schalit wrote: guitarlynn wrote: I got around 14 more FAQ's updated, formatted, and submitted over the weekend. 3 more are almost ready and pending author approval of the changes. Way to go. It must have been pretty funny, reading some of the old stuff in there. I've used most of them, I just ghosted the mailing tists for a long time ;-) Let me know if you want some help on those last 5. I'm going to be tied up until around 10PM CST, so if you want to take a look at the following, it would probably help some people! http://sourceforge.net/docman/display_doc.php?docid=1420group_id=13751 http://sourceforge.net/docman/display_doc.php?docid=1431group_id=13751 http://sourceforge.net/docman/display_doc.php?docid=1432group_id=13751 These are the only ones that might need updating Section 7. The other two just need formatted to xhtml-strict ... no biggie. You can verify xhtml-strict @: http://validator.w3.org/file-upload.html I haven't looked at any in Section 7 and any later sections yet. Thanks Matt, and anyone else that wants to help! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] TS-req-HowTo / How Do I Request Help?
Any desired changes or is this acceptable to everyone to submit??? Thx, ~Lynn start of FAQ ## Q. If I want help troubleshooting a connectivity failure with my LEAF router, what information you you need from me? A. The exact information needed will vary by what trouble needs shooting. As a general matter, exact quoting of error messages, log entries, command output, and such, is better than your trying to paraphrase or summarize them. 1.0 Introduction As always in life, especially when you have just pulled your last hair out, there are several things to check and do before asking that might save you a post that is archived on the web for the rest of your life that hasn't jumped out at you yet. Or you simply are not familiar with the LEAF/Linux system yet and need some more information to help you realize exactly what to check and understand. I highly suggest following some, if not all, of the preliminary self-help steps before posting. Do a Google search on Guitarlynn some time, and within the first 5 hits of the search I can guarentee a very embarassing thread on a mailing list that happened many years ago. I would like to see everyone get a working system without any embarassing side-effects like that! In fact, it will most likely get you a correct answer to your problem in a much faster time frame by helping us help you in this manner. The instructions in this document apply to SourceForge support requests, and troubleshooting questions asked on the leaf-user mailing list. 1.1 Acknowledgements We thank the following people for their corrections and suggestions: Ray Olszewski, Charles Steinkuehler, Jeff Newmiller, Gary Shea, Michelle Konzack, Wayne Fool, Jonathan French, Michael Leone, Dave Emmons, Bill Pierce, Chris Hill, and Paul Batozech. 1.2 Distribution Policy A copy of the license is available at: http://sourceforge.net/docman/display_doc.php?docid=1812group_id=137 51 2. Things to do Before Posting Read all available documentation on the site where you obtained the LEAF disk image, or files you are using. Check the FAQs at: http://sourceforge.net/docman/?group_id=13751 Fix all known bugs - see FAQs Section 05: Fixes for Known Bugs Subscribe to the LEAF mailing list at: http://lists.sourceforge.net/mailman/listinfo/leaf-user This is not necessary, but it is the polite thing to do. Optional: Search the LEAF mailing list archives at: http://www.mail-archive.com/leaf-user@lists.sourceforge.net/ This may take some time and effort. If you're not familiar with search engines, you may find this difficult. However, in most cases it's faster than asking list members for help. 3.0 Preparing a Post When preparing a post, keep in mind that you're asking for free technical support from people. They have no vested interest in helping you. So, it is to your advantage to make it as easy as possible for them to help, by including all appropriate diagnostic information. Also, be aware that other people's machines are not the same as yours. If your post is formatted correctly, some of the most knowledgeable people (UNIX gurus) will be able to read it. The following is a list of things to keep in mind: Keep your lines under 80 characters, and under 72 if possible. Sometimes it is necessary to include lines longer than 80 characters. You can accomplish this by using \ to continue a line. Example: averylongcommandthatyouwanttosplit \ intomultiplelinesforpostingtothelist \ sothatotherpeoplecandiagnoseyourproblem Use plain ASCII text. Not all email clients can properly view styled or HTML text. Some will simply strip out the codes used for style/HTML text, while others will display the codes in the message and leave the recipient with a messy email message. In extreme cases (e.g. pine), the recipient will see nothing at all. - see http://www.expita.com/nomime.html for instructions The post should have an informative Subject line, with the important information near the beginning. Include all information in the body of the post. It is inappropriate to send attachments to the list. Please don't edit the diagnostic information in an attempt to conceal your IP address, netmask, nameserver address, domain name, etc... These things aren't secret. If someone wants to do something bad to you, they can get this information in no time. When you post files that include passwords, you should replace all password characters with the letter x. 3.1 How to Get Your Diagnostic Information Into a Post When asking for general help with routing or firewalling questions, you should ALWAYS include this information: the exact name of the LEAF distribution and version you
Re: [Leaf-devel] TS-req-HowTo / How Do I Request Help?
On Monday 04 March 2002 16:33, Mike Noyes wrote: At 2002-03-04 16:16 -0600, guitarlynn wrote: Any desired changes or is this acceptable to everyone to submit??? Lynn, Can I have another day to look at your proposed changes? Absolutely! Any comments, suggestions, or whatever are desired. It was sitting, so I thought I would ask. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Evolution as a project development model
Mike, Thank-you for the excellent reply and insight that explains much of the depth, experience, and respect that is rightfully deserved and displayed in this project :-) On Friday 01 March 2002 11:37, Mike Noyes wrote: At 2002-02-28 10:51 -0600, guitarlynn wrote: Gnome and KDE are single platforms that developers can write to. They use a monolithic development model for the base. Their base is then used as a resource to build things. Are different Gnome/KDE bases available to choose from? If not, they don't correlate well to our project. Yes, very observant, we all have our baseline to work from. I think all of our releases are showing that the baseline is not only being challenged now, but being lowered when compared to the limitations of the past. The only thing monolithic is the package repositories I can wait on seeing kde30.lrp for a while though :) snip of completely true statements that leave nothing to be said The acknowledgement and existance of LEAF affiliates assumes the position that you seem most concerned with, and the only seperation between release and affiliate here appears to be the opinion and process of the individual lead developer. Correct to some extent. However, most of our affiliates crate components (specifically firewalls) that our developers make use of when creating releases/branches. This means we don't have to create something from scratch, and allows for a faster development cycle. It also provides a synergy between the affiliated projects that is beneficial to both. It also benefits in vastness of scope that is unmatched in any other project or release/version/distro that I am aware of. Many others are very good products, but very limited in what you can do with them when compared. This is an extreme benefit to the project and releases. There are a couple of other levels of involvement. Pim van Riezen [1] decided not to join or affiliate with us, but he does participate on the mailing lists. Ken Frazier [2] decided he didn't want anything to do with us. That is disappointing to hear. I'm am in the process of attempting to use cish for some simulation in Cisco (hopefully). This shell could really add a compatibility layer to the project. I hope he wouldn't object to his shell being used with LEAF. David D has it packaged. If I remember right, Ken worked with Coyote for some time, his insight and different point of view would have also been nice! This sounds like healthy evolution to me. :-) You forgot one important thing that will prevent infinite release/branch creation. There are limited resources (developers/users) in our environment (LEAF). Mind share will prune the week eventually. Developer(s) will only work on a release/branch as long as they receive recognition of their effort. I see this every day on the SF support lists. Abandonment of unused projects is common. That is one reason I make an honest effort to try many different releases/products. Many of them fit a certain niche better than others. The sad part is that some of the more cutting-edge versions do not necessarily fit the most used niche, and end up not being used as often. This would be a good point to thank all the developers for their hard work and excellent products that I am happy to say are at the top of their niche's in respect to quality. snip of more sound reasoning 1. Use of evolution as a development model. 2. Tolerance for new ideas and differing opinions. 3. Full control by lead developers of release/branch direction and purpose. It appears to have promoted many excellent products and a very healthy, stable development community. As Charles admonished me earlier, I now do for you. Thank-you, Mike ;) All of our opinions/ideas matter. Whether you're a lead developer or project admin has nothing to do with the validity of your opinion/idea. Absolutely, however the effect of a project leader or lead developer having an issue would create far more effects to the community than myself. This does not mean that my opinion does not matter or should not be effective, but rather the people that primarily have made the larger contributions to the project should get the respect that they deserve for the time and effort that has made this possible. I intend this with exhaultion to these people, rather than any lack of self-esteem on my part or source of degrading demeanor towards anyone else. BTW, this reply took me almost two hours. Your post was very thought provoking. Thanks. :-) The reply was worth every minute you put into it, IMHO. Thank-you for extending your thoughts :-) -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] q regarding an ftp site for leaf-project.org
On Thursday 28 February 2002 21:26, David Douthitt wrote: On 2/28/02 at 1:52 AM, guitarlynn [EMAIL PROTECTED] wrote: PicoBSD might as well not even exist anymore. I HAD to reply to this :-) Hehe, I figured this might peek some interest ;-) PicoBSD is now an official part of the FreeBSD distribution, and is included in the source tree. The web pages haven't been updated in a LONG time. There also are very few, if any, floppy disk images to download. The expected thing to do is download the FreeBSD sources. However, there ARE the older PicoBSD images, plus at least two floppy images that I've found based on PicoBSD. One is a cluster director - that is, it handles the initial requests to a cluster and doles out the traffic to the appropriate web server or whatever. So they are still developing PicoBSD, but simply not posting any updates even in the way of information to the project page??? I knew it had been included in FreeBSD, but I haven't loaded a late version. I have used OpenBSD and been happy with it, so maybe I should take a go at a later version of FreeBSD. I just figured they would keep a current changelog or something to that effect on their homepage. :-(. Solaris sucks on an i86, but rules on a Sparc. I heard that 2.6 was alright, but 7 and 8 are slow because they expect SMP. I can verify that 7 and 8 run very slow on i86! At the time it came out, there was very limited NIC drivers too. It is a great version to learn Solaris on in any respect and definately worth the experience, but not for a production machine. On a different note, have anyone come across a open source RIP simulator??? -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] q regarding an ftp site for leaf-project.org
On Wednesday 27 February 2002 23:07, David Douthitt wrote: On 2/27/02 at 4:28 PM, Mike Noyes [EMAIL PROTECTED] wrote: The last consideration is licensing. David is using the MIT license, and everyone else is using GPL. From what I understand reading the iBiblio licensing page, only one license is allowed per repository. Sounds like I'm the odd man out, eh? :-) Naw, M$ will be using Oxygen ported to Win32 in the new WinRTR release though :O ...j/k I'd like to see each distro get a files area on ibiblio - that would solve the above problem as well. Each distribution needs some recognition; LEAF isn't one distro, it's a conglomeration. That is a good thought, and probably one reason many of the other similar projects are getting a lot of recognition w/o being nearly as versitile. I've seen some first time project browsers get rather confused with the conglomerate site, but I don't think breaking up LEAF would help any of us other than downloading and some documentation that is release specific. As you suggested, David, I think that might be to an advantage to everyone. When someone goes to a site that lists different single floppy embedded linux distro's, what is going to multiply the traffic to the LEAF site itself? possibly 4 out of 10 links back to LEAF! I'd like to think that many of the developers here truly deserve some recognition for the wonderful work they have done. btw, how's Solaris x86 working for ya??? It was a real dog here, but cheaper than a Sparc to learn on! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] q regarding an ftp site for leaf-project.org
On Thursday 28 February 2002 00:45, Mike Noyes wrote: This is where we disagree. I believe this is a single project with many releases/branches. ref. This I agree with, w/o necessarily heading in the same exact direction. D Douthitt wrote: I'd like to see each distro get: * Freshmeat entry * ibiblio directory * Linux.com entry in distribution listing... * Any other archives/collections... This sounds like a proposed split. It's exactly the opposite of what I've been trying to do. What happens when a release/branch is made obsolete by a new one (e.g. Eigerstein - Dachstein)? Do we create a bunch of new directories and records for each new release/branch? I belive this would lead to fragmentation. No new format to this site, rather each release taking the effort to update the proposed alternate _download_ mirrors such as Ibiblio, tucows, freshmeat, Dave Central, etc. Not a proposed split, but rather a defined release of the individual releases/branches that reside, are supported, and developed within the umbrella supersite that is LEAF. A split would occur when someone chooses to remove the support, development, sharing of ideas and methods, and ultimately the disk space of the individual part _from_ LEAF. I've seen David respond to a Dachstein question, I've seen Charles respond to a Oxygen question, and I know for a fact that almost everyone including myself has taken a stab at a LRP 2.9.4 or earlier question at some point in time. I don't think anyone has ever told someone that they couldn't use their package in someone else's branch if they wanted to. But I have seen someone create a killer branch to prove a theory. What I'm saying is, you can't download and use LEAF. You can download and use something (and many things) that were made possible directly from LEAF. LEAF is a conglomeration of seperate ideas, processes, and directions with a common ground and brotherhood and /or community. LEAF is a win-win project for the developers, by the developers. When I go to Walmart, I don't come home and say that I bought a Walmart; rather I say I bought something _at_Walmart_. The many things I buy at Walmart causes me to come back more often and explore what else I could get at Walmart and that I do. When someone finds _something_at_LEAF, they will know that it is not LEAF in the full meaning of the project, but rather one useful piece that makes up LEAF . They will also know that there is most likely more good things to try at LEAF. It amounts to name marketing through the sum of the individual, different pieces that the name contains. For the public growth of the project as a whole. I personally develop for LEAF, not just Dachstein, or Bering, or Oxygen, or branchX. I watch some other embedded distro's grow as well. Matthew Grant is doing a new WAN router thing according to his 'plains' website. You still can't write protect a FreeSCO disk and boot your machine. Coyote is pretty much a small harddisk distro now. BBImage has a real nice floppy disk generator using a 2.4.x kernel via CGI. PicoBSD might as well not even exist anymore. Solaris sucks on an i86, but rules on a Sparc. I develop for LEAF, and LEAF only. This is because I like the individual and sum of all the parts better than anything else available. The community is great too. Proposing a split? Rather, an idea to increase traffic and potential users back to the place we all call home. /soapbox and apologies to those of you who paid to download this -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] changes to FAQ docid_1400
I am submitting some changes/updates to the FAQ docid_1400 and feel that with the number of developers that it should affect, that approval via the list was the quickest and best way to make it available for changes and approval. Feel free to comment on the list or to me personally concerning this. ~Lynn start of FAQ # Dachstein It is easy to use, and will automatically configure machines on your internal network. Dachstein has built-in firewall/filtering and also provides a local DNS cache, which reduces your reliance on your ISP's server and can speed up internet access. The main drawback is the 1680K disk format, but the image is self-extracting, making it easy to work with. Oxygen This is a newer variation, and does not have as much of a following as the other variations. It was designed to be used not only as a firewall, but also as a network debugging tool or a system rescue disk. It incudes Data Disks which are really nothing more than disks with sets of packages on them, ready for loading into the Oxygen base system. Bering This is a new release, that unlike the other releases uses the newer 2.4.x kernel series and iptables for filtering and firewalling. Bering was based off of Dachstein, so much of the functionality is very similar between these two branches, though there is several notable differences between several of the packages and the network configuration (which was redone from scratch). The Shorewall firewall is built in for firewalling and filtering with iptables. Packet Filter This is another new release, that is not an actual release when considered on the bottom line. What Packet Filter really is boils down to more of an enclosure for other LEAF releases to run within. It offers a menu to select different networking and configuration options during the boot process that allows for loading different systems to be selected from on the fly. Network configuration test beds, a LEAF developer environment, and 5 to 10 minute rapid deployment network configuration are some of the primary uses of Packet Filter. All LEAF releases have been run on Packet Filter. It is probably noteable that Packet Filter is intended for more experienced LEAF users. ### end of FAQ -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] LRP 2.9.8
Alright everyone, I'm coming to the point in the FAQ's that haven't been updated since around the inception of the LEAF site. My concern is with updating considering LRP 2.9.8 is LRP now officially an old release, retired, or active as far as this site (LEAF) is concerned? I realize many of us still use 2.9.8 and are more than willing to support it, but put bluntly, Eigerstein is now considered a old release as are other releases that are more recent than 2.9.8 . I just don't want it to be considered as recent or up-to-date simply because it isn't compared to any current releases that LEAF is supporting. Thanks for the thoughts, -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Announcing leaf-project.org site name.
Steven, I would just like to thank-you! Not too many people would do something like that. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] dachstein floppy with glibc 2.1.3
On Saturday 16 February 2002 10:40, KP Kirchdörfer wrote: snip some cool stuff It seems to work pretty well, with about 40k free on the floppy, I#m sending this mail booted from the floppy. I should have a testing version of Udhcp (server client) as a mini- replacement to dhclient and dhcpd up tonight and tomarrow. I have a little tweaking to do, but it is coming in ~22.7Kb which is much smaller than the other two packages. I think I've got all the support working, except aliased interfacing I'm still deciding the cleanest way of doing this, so a later release will have this support. At this time, due to the scripts, this is a Dachstein release due to the script config options. I'll try to get a general LEAF release pretty quickly too. Thanks Charles! It should get you some room for some packages that don't fit now and be almost as functional as what it is replacing. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
I would just like to thank everyone for this discussion. Due to limited examples and precise wording designed to be clear (but somehow let most of the information vague), I am finally coming into a more complete understanding of what was originally proposed, and what direction some developers would like to go. In a very basic sense, what is proposed is that the developers fully document _how_ and _what_ something is loaded, not to mention _what_ exactly is being used. A repository or port system would be used for each developers system, so users should not be confused to what will and will not work will this particular system and a clear direction to take when they need something that is not necessarily provided or capable or being done with the said existing system. I don't think anyone would argue that something clearly along these lines would best be implemented at _this_ point in time. I am most likely the common denominator to the general public among the developers ... I am not a professional programmer by any means, I just know enough to generally get done _what_ I am aiming for within my limited skills. I look forward to seeing the process and result of the vast and broad knowledge that exists within this group. It should be interesting and educational for me! Meanwhile, I'll be off doing docs, packaging, maybe a custom image, and the list (I really should think a little more before responding ... I make some real un-intelligent posts on a regular basis). Thx all! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: SF changes TOS
On Thursday 14 February 2002 15:45, Serge Caron wrote: As a Canadian citizen, I do not know what you are taking about. We have NO restrictions on cryptography and our copyright laws are pretty much in sync with the international community. snip Here is some dope on the Canadian Export Control List (http://axion.physics.ubc.ca/ECL.html). However, if you have specifics, I will have a lawyer research this. OK, thanks for that info. Around six months ago I was looking into helping a couple of Canadian-based projects and they implictely stated that due to the US laws on cryt., they appreciated the offer but wished to decline due to the possible conflict. Things may not be true for any other projects and they may have changed their minds, but since some of these laws have passed within the US I have to respect their concerns :) Thanks once again for enlightening my concern! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] SF changes TOS
snip for slashdot Re:not such a big deal (Score:2) by wendy on Wednesday February 13, @04:34PM (#3002999) (User #42400 Info | http://cyber.law.harvard.edu/seltzer.html) They're choosing to take advantage of the safe harbor provision for ISPs (DMCA section 512, not the anticircumvention rules). 512(c) immunizes ISPs from liability for postings of their users, provide they follow notice and takedown procedures including the listing of a designated agent. Even if they list an agent, service providers still have the option of refusing to remove material if they get a notice of claimed copyright infringement, and of taking their chances in court. The subscriber receiving a claim of infringement can also file a counter-notification asserting that the material is legally posted. end of snip I think anything run in the US is going to have this problem. Canadian would be great, but legally you can't contribute from the US to their projects as I understand it. Bad year for Open Source! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Toys for the dreamers in all of us!
On Tuesday 12 February 2002 15:04, Serge Caron wrote: Hardware kits galore with a _real_time_ operating sustem: http://www.zworld.com/ Check out DeviceGate Development kits ! Pretty kewl, Other than the fact that Linux probably doesn't support the Rabbit2000? processor (that I know of) and the propietary C system they're using requires a Win32 OS. http://www.zworld.com/products/dc/index.html http://www.zworld.com/products/smart_star/index.html Sounds to me like QNX on a Win32 platform marketing through their own hardware. Maybe embedded SUN on Win32. I wonder why they don't offer something with a Transmeta chip? Neat, but not my cup of tea ;) thx -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Introduction: mds
Glad to have you aboard, welcome!!! :) -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: ADM Write Protect
On Saturday 09 February 2002 04:01, Jeff Newmiller wrote: The altered states to start to come into focus. :) hehe, kind of scary, eh? This is a cmos logic device.. not a power driver. It will not burn out any resistor. You often see resistors inline to limit current (say, for LEDs or transients from off-board inputs), but these are NEVER zero ohm resistors. I will have to agree with that, a real small diode would be more standard there, I've never seen a 0 ohm resistor? A zero ohm resistor is a piece of wire. It is not a fuse. I would recommend that you re-read Charles Steinkuehler's analysis for the most likely function of this (most likely not installed) piece of wire. Yep, I did and what you are saying makes sense. Why would you call a piece of wire (a jumper) a resistor? It seems that you would call it J8 or something or something along those lines. In any case, what R8 does, as Charles noted, takes the Wait# from the LD017_A0 to pin 30 (ground) on the controller. Mike said the tech told him that: They use a hardware solution shunting R8 to ground, which indicates to me that R8 was designed to be a component besides a piece of wire. A shunt is typically a resistor or an inductor coil. A piece of wire would work, but probably not what the design team had in mind. Now, what the design(ers) had in mind, I won't necessarily guess at. It seems to me that tying reset low would prevent the interface circuitry from working... that is, the device would be write protected, but it would also be read protected, so if it lost power you would have to physically be there to enable reboot. This would _not_ be ideal. No, I proved that by simply trying it. Logically, you make sense, but maybe that is why noone has gotten a typical ATA device to work this way in the years that it has been attempted. I proved that setting pin 1 to ground does _not_ disable read capabilities of the drive or the ability to communicate the Low-level hardware (BIOS). As one of my old high school math teachers kindly beat in my head, Sometimes 'PIAGO' is the only way to tell for sure! (PIAGO --- Plug it IN and Grind it Out) I'll try it with some other boards and ATA devices as soon as I get around to Syslinux'ing any of them, if noone else feels the desire to taking a chance on destroying some 7+ year old hardware. I find much of it by trash cans or at a DAV store for under $10, so I can afford to destroy one or two if it will benefit us. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ANN: LRP Developer's Guide
On Saturday 09 February 2002 12:25, David Douthitt wrote: There is a new version of the LEAF/LRP Developer's Guide. Minor revisions really - a new section on notes about compiling the Linux kernel. Thanks David!!! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CF (write protect) + IDE adapter
On Friday 08 February 2002 08:39, Charles Steinkuehler wrote: Um...you won't find any standard motherboards that support the usage of pin 30 for write-protect, and even if you could, it would probably be controlled by software, not a switch, which kind of defeats the whole purpose. That's the entire reason the WP jumper is on the device in the first place...you can use the pin 30 interface if you're designing a custom board...folks with standard hardware can just use the jumper (or optionally wire the jumper to a manual switch). OK, this is where I might be confused myself, and confusing others such as Matt. Let me explain it as I understand it, and everyone is welcome to thrash me into submission if wrong. As noted in the email and to a far lesser degree on the White paper, pin #30 _can_ be used with a special MB to control the WP, in particular with _partial_ software_named files/dirs to WP. The WP used with the pins #1-2 does not require the special MB or ATA instructions, simply a jumper or a jumper with switch, but you can't do partials. Now comes in my somewhat OT comments/thoughts of yesterday. Being that this jumper configuration does not require a special MB or ATA instructions beyond what is presently used, only a jumper that bypasses the disk itself (to ground) ... Is there any reason that this could not be implemented on any or all existing ATA run devices (CF, FlashDisk, IDE, etc), the jumper is bypassing the drive itself as far as the instructions on wire #1 is concerned The reason I bring this up at all is quite simple, I believe that the general population has old hardware that could be used for LEAF similar to mine roughly 30 old 486-P1 boxes that support IDE only (no SCSI support built in). The cost of a SCSI controller board is too expensive, or won't fit in the desired case restraints desired, so though it's a excellent option, it's not a desired option. I have flash and CF cards at present that I would like to use WP if possible through existing MB's ... a manual switch or even a $10-20 module would be more cost efficient and desired than simply trashing what I already have, hardware wise, to get WP, if possible. In other words, how many folks have said: Can I run LEAF on a harddrive (IDE). We say, you can, but it is a security risk compared to a floppy. What would it mean to be able to say: You can use a hd, but if you want it as secure as the floppy, a $10-20 add-in IDE module is available here (link). I think a lot of people would find this useful, IMHO, or maybe I'm thinking too hard and flogging a dead dog! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CF (write protect) + IDE adapter
On Friday 08 February 2002 10:52, Mike Noyes wrote: Lynn, If I understand you correctly, you believe Apacer was telling Stefaan that Host Selectable (Close 2,3) mode wasn't supported, not that Connect to Ground (Close 1,2) didn't work. Since there is no WP jumper on the ADM, we need to create an adapter that jumpers pin 30 to ground when WP is desired. Pins #2 30 are ground on a typical ATA cable. Did I get that right? Anyone willing to try this, and see if it works? I will see if I can try it today. If it's this easy, I can't understand why SST/Apacer didn't add a two pin WP jumper (Close 1,2) to the ADM. Me either, I'm probably wrong ... so I'll use a MB I won't care to lose just in case. If I'm guessing right, I'll manufacture the darn things. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CF (write protect) + IDE adapter
On Friday 08 February 2002 13:10, Mike Noyes wrote: Lynn, Do you already have one of the ATA-Disk Modules? If so, where did you get it, and what did you pay for it? No, Mike, I don't have one your not grasping the scope I see here. I just tried it, but it doesn't work as expected ... I'll have to engineer a module to work with it and a system patch ... but I can do this. THIS CAN BE MADE TO WORK WITH _ANY_ IDE DEVICE! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: ADM Write Protect
On Friday 08 February 2002 22:00, Matt Schalit wrote: ATA-Disk module (ADM) and it's write-protect features: Here is the 40pin 5V ADM schematic. This is using the LD017 controller. In the schematic R8 is used as an option for WP. I think this is the crux. It's being used. It's being tied to ground by the presense of ground on IDE cable pin 30, and the existence of a zero-ohm resistor, ie. a short to gnd. a zero-ohm resistor is for circuit protection and yes pin 30 is ground on regular IDE as is pin 2. Not a general feature if IDE I would agree. For a regular IDE drive, disconnecting or strapping an IDE pin low or high, such as DIOW or DIOR (23 or 25 I think) would interrupt the writing of command signals to the drive's onboard controller. At least that's how I understand it so far. Nope, pin 23 drops the acknowledgement of the drive itself out of the BIOS no drive found to boot. I tried this a couple of days ago thinking the same thing. - If R8 is vacent, the device behaves normally (ie no write-protect) I see the exact opposite. It's gnd now according to the docs with R8 present and it's write enabled. If you remove R8, then you are trying to do the opposite, ie protect it. But is floating it correct? If pin 30 is grounded (as normally done) and you add R8, R8 then grounds out pin 1 (reset) and _then_ the drive is write protected. story If you've now read this far, you get the cookie. Earlier today I hacked a jumper in an IDE cable between pin 1 (reset) and pin 2 (grnd) and started the P166. The BIOS acknowledged the flash drive (not a CF, but a regular IDE flash drive) and kept trying to reset the drive. It started to boot and failed. I thought, well that sucks and left it there. Just a couple of minutes ago, I was working by it and thought I might just boot it again, which I did, but this time it wasn't cycling the reset as it had before and booted. I logged in and tried to mount the drive . it gave me io errors and would not mount the drive. I rebooted 4 more times with the same exact results. I took the jumper out and booted again, I could mount and write to the drive. Apparently the BIOS updated itself after the first boot and decided to work for me. /story In a nutshell, jumpering pins 1 2 on a regular IDE setup from around 1996 will write-protect a regular IDE drive. I will try this with a harddrive as soon as I get around to Syslinux'ing one. Can anyone else try and verify this for me ??? I won't guarentee anything at this point other than it worked for me on the only box I've tried it on. I apologize for being off-topic for using IDE instead of a ADM that I do not have. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: ADM Write Protect
OK, a little back-ground on me, so maybe this makes a little more sense to follow. I have had 3 years of electronics schooling, a little over 2 years of Electrical engineering, and been a licensed electrician for around 4 years after a 5 year apprenticeship with specialties in digital control design and instrumentation. This doesn't mean a hill of beans other than I have a small notion how digital electronic devices are controlled on some level. My logic is somewhat different than a programmer when looking at devices such as data drives much of the time. I've been posting my thoughts without really going into an explanation of any depth ... maybe this will clarify what _is_ going on in _my_ head. a zero-ohm resistor is for circuit protection and yes pin 30 is ground on regular IDE as is pin 2. What does circuit protection mean? Ok, let's assume something internal in the ADM shorts out in a bad place We will also assume you are using the ADM as designed to use software via a special IDE controller to specify when and what is write-protected. This resistor has _no_ effect on the circuit _other_ than limiting the amount of current and voltage running across it. It technically should overload and burn out this resistor and protect the precious motherboard you just paid all this money for. In reality, this is almost never the case, but it is accepted good engineering practice from my experience. I said the writing of *commands* not data. The lack of commands is what yields the lockup, from my understanding. I was not claming that write protect is possible by blocking DIOW or DIOR. Rather it's the exact opposite as you found. Yes, I understood that, but I didn't state that I felt WP is possible w/o defining a software filter of _any_ kind, which is what I'm interpreting you saying on an extremely low-level here. You are defining what the manufacturer is intending to do and sell at a much higher price than a plug-in adapter to a toggle switch. If pin 30 is grounded (as normally done) and you add R8, R8 then grounds out pin 1 (reset) and _then_ the drive is write protected. The schematic show R8 exists. That's CS and my question at this point, Does R8 exist on an LD017 controller? Probably not, the drive wasn't shipped to write-protect .. especially with a non-compliant ATA controller. They probably save around a nickel by not putting it in at all. The only reason pin 30 is used at all is for software filtering as stated on the data sheet. I interpet the data sheet as saying a jumper between pins 1 2 can be used _or_ pin 30 for software controller depending on the high/low state. Apparently the BIOS updated itself after the first boot and decided to work for me. /story What BIOS are you referring to, and how does it update itself? The motherboard BiOS. I can't really explain this. When you put a 20 Gig harddrive in a Cyrix 333, why does it hang for ~30 seconds before booting. Checking the drive tables for a known drive type , then uses the best guess if not known, I guess. I really don't know anything about how BIOS hd detection really works. In a nutshell, jumpering pins 1 2 on a regular IDE setup from around 1996 will write-protect a regular IDE drive. I will try this with a harddrive as soon as I get around to Syslinux'ing one. I don't follow. Have you disconnect to wires to pins 1 and 2 on the drive, left them floating, and tied pins 1 and 2 of the cable side together? OK, you have two IDE connectors on the ribbon cable. Plug one into the drive. Now put a jumper, or wire in a switch, between wires 1 2 on the other drive plug. This simply grounds out pin 1 (reset) as the data sheet and the hardware tech alluded to. Is this going to work perfect on all drives/mb's/BIOS's ??? I don't know, it is now working on the one machine I tried with no problems. I can't say for anything else. Can anyone else try and verify this for me ??? I have a cable and an old IBM drive I can doink with. I'll let you know. Thanks, I think this could be of use to a couple of people besides myself anyway. Can I be a little lazy and ask you what the logic is that your trying to accomplish? What does grounding the reset line do? Something that will allow me to write-protect an IDE flash or CF drive in a 1U half-slot rack case. Write-protection will be pure hardware ideally. Maybe I'm just nuts, but it's lying there working as I wanted right now. I like to thank everyone for inspiring to make strange opinions and attempt weird tricks. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Ports
comments inline ;} In reply to DD CS ( others...): After the make install is done, the LEAF system now has /tmp/wget.lrp and an installed wget binary. Then you have come up with how Debian now installs . a set of one or more boot floppies, then 'wget' everything else. The unstable tree is finally about cleaned up from the mess it's been for some time :) Another possibility: using that full Linux system again, doing the same thing - except this time a make install uses scp and a private key to copy the file over to the LEAF system, then uses ssh and a private key to install the package on the LEAF system. Maybe rsync after the compile? While the gentoo stuff looks promising, I have yet to play with it...where's all the time go? Regardless, if you're wanting to play with a bsd style ports sytem on linux, Gentoo and portage are AFAIK, the way to go. I haven't played with Gentoo, but this sounds very similar to 'ALFS' which is an automated LFS. It compiles on the client box, but we could work around that via CGI/MySQL and everything is done via chroot. Source is available too. The problem I'm seeing is that SF is going to _kill_ us if we start mass compiling kernels on their systems (think of _server_overhead X100 users at a time then SCP'ing this traffic back over their connection). Anyone know someone who wants to give up the bandwidth _and_ the processor overhead (with atleast one T!) ? Maybe a thorough set of pre-compiled kernels to select from would be preferrable resource wise. Besides, it will take a while to compile everything including the modules (ie... IPSec [none | pass-through | support]. I love the idea, but this is going to take a _lot_ of server resources to implement. Probably a lot of disk space considering how much traffic this could create over what we have now! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Date/Time
On Thursday 07 February 2002 01:26, David Douthitt wrote: I've been looking into the date and time set in an Oxygen system, and comparing to a Mandrake system. That is a nightmare on Mandy 8+ I think your referring to a older relase (I hope!). LFS is probably clearer for what we're looking at, barring Busybox compatibility. The confusion comes this way: And it even appears that busybox date may be reporting the wrong time... sigh... Yep, it does! LFS still uses hwclock, so all the problems lie in the Busybox 'date' problem. Check this: http://lfs.planetmirror.com/view/3.1/chapter07/setclock.html http://lfs.planetmirror.com/view/3.1/chapter06/util-linux.html It appears that they have moved to ddate, which might be a good idea for busybox too, size in consideration. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CF (write protect) + IDE adapter
I just got word back from PQI, I should get a data sheet in a couple of weeks. It won't be availiable until May though :( ### snip ##3 Dear Lynn Yes, we are now ready to present the first model of our Secure Disk on Module product; it will be formally launch to the market in May, this product is perfectly for those applications, which just likes you mentioned. PQI now is the market leader in Taiwan and Europe for this type of product, Secure DOM is our latest DOM product; it also being asked by many of customers who just like you since one and half year ago. Because for the password type DOM can not satisfy with their needs anymore. I will send you the datasheets of this product in the end of this month, because PQI will close for the Chinese New Year from Feb. 9 to Feb. 17. After you go through those product descriptions, I ensure you will be very interested to this wonderful DOM/HDD solution. Regards Sam Lu Information Appliance Division. # end of snip # If the CS modification to the ATA cable will work, I'll be willing to manufacture some for the group (or a module as Arnie noted, this will require 12 ATA cables though ... 24 max length). -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Ports
On Thursday 07 February 2002 09:55, Charles Steinkuehler wrote: My intent was to suggest we co-opt the portage system to enable an easily installed, standard development environment. We would also be able to benifit from the work of others maintaining the portage tree (updating packages with bug fixes, newer versions, etc). Oh, ok .. Sorry, I missed the developer part. slinks away for a day in Ark., job hunting Thanks for the clarification. There should be source on the Debian wget/rsync method they use in any case... great idea guys! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CF (write protect) + IDE adapter
On Thursday 07 February 2002 10:59, [EMAIL PROTECTED] wrote: On Thu, Feb 07, 2002 at 10:41:33AM -0600, Charles Steinkuehler wrote: To install a write-protect device between the motherboard and an ATA device, you need something that understands ATA at the application level, and returns some sort of error for logical write commands. I understand this. But as i see this, this special device has one pin that it put to ground enables write protection. Not if it is expecting an ATA instruction back at the motherboard to work. If it was this simple, we would probably be using this as we speak and it wouldn't require a special controller (rather they could simply eliminate pin 30 at the disk and take it to ground there). -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CF (write protect) + IDE adapter
On Thursday 07 February 2002 11:24, Mike Noyes wrote: At 2002-02-07 10:47 -0600, guitarlynn wrote: I just got word back from PQI, I should get a data sheet in a couple of weeks. It won't be availiable until May though :( ### snip ##3 Secure DOM is our latest DOM product; it also being asked by many of customers who just like you since one and half year ago. Because for the password type DOM can not satisfy with their needs anymore. Lynn, Maybe their referring to me. ;) Probably so . ;) I've put in RFI's at several places... on several products. I've been asking for a DOM with a write protect tab/jumper/switch for approximately that long. I hope their new Secure DOM will work with standard motherboard/ide controller combinations. Me too. # Hey CS ### Is there any reason I can't make a module w/ a solid-state time-delay relay (set to boot time + x secs) to break pin #39 (Drive Active/Drive 1 present) and get the same effect? I would be willing to engineer one ... maybe I'll give it a shot tomarrow or over the weekend. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CF (write protect) + IDE adapter
On Wednesday 06 February 2002 02:04, Jeff Newmiller wrote: On Sun, 3 Feb 2002, guitarlynn wrote: Yes, a product to keep me from cutting tiny toggle switches into those blasted IDE cables would be a godsend! I can live with the CF cards nicely though for the time being (if I can get one anyway)! My curiosity gets the better of me... just how many of these toggle switches have you installed, and how well have they worked? hehe, I haven't to be honest I was in a strange mood @that time. I probably shouldn't have put it in there, sorry. I remember a long thread with some people trying this a couple of years ago though, did anybody ever have any success??? If my memory serves me right, there was a problem with disk-corruption errors if the system tried to write to the HD. It wouldn't be much trouble for me to try this if your really interested though. A less frustrating way of trying would be to wack a piece out of wire #23 and simply switch to another cable to write. I'll give it a try, I need to do some soldering today anyway! You bit, I will too. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] weblet the like
On Tuesday 05 February 2002 08:16, Charles Steinkuehler wrote: IMHO, there's nothing inherently wrong with GUI config tools (properly secured). I would like to see a consistent configuration system for the next generation LEAF that allows text-based menu configiguration via scripts on the default system, with the option of adding a web GUI if desired (sort of a light-weight linuxconf that actually works). It should also be possible to edit config files by hand without confusing the config menu front-end. hehe, Linuxconf more like Webmin :) OK, that pretty much eliminates any CGI except shell then. It's likely the best option, being the perl is not possible on a floppy. I imagine licensing would be a issue with vitually any other scripting language anyway. The ease of use this provides would help widen the user base, and I think the discipline of maintaining a consistent configuration scheme will add to both understandability and ease of administration. As long as the power to manually edit the config-files directly is still available (w/o completely confusing the GUI tools), I don't see where this has any big negatives (other than the obvious time/effort involved in building the configuration framework in the first place). In other words, it will require using sh, sourcing file(s), mandatory function style, dire commenting, and a good working knowledge of sed (that I'll likely become _much_ more familiar with). Can you use POST in sh-httpd or is this going to have to move to thttpd? Do you have an existing release config file form you would like to base off of, or do we do one from scatch? Every character in the McDonald's theme has a menu item associated with it except Ronald, what exactly does Ronald represent? hehe -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] weblet the like
On Tuesday 05 February 2002 14:52, Charles Steinkuehler wrote: sh-httpd could be modified to include POST, but it might be better to use something like mini-httpd, or perhaps a web-server written in an scripting alternate language (if we include something like java, ruby, c). If we stick with sh-httpd, it should be cleaned up a bit, given a serious security review, and also really needs support for connection-keep-alive... Well, from my digging the last couple of days, the best web-server option I've seen has been thttpd that supports POST natively. It appears to be secure and supports SSL and we already have a package (whether a re-compile is needed for this is another story. I dug through Mosquito last night for a bit. They use _no_ text editor and _all_ configuration must be done via the web-cgi applet. They are using thttpd w/uncgi which seems a great system other than Uncgi is copywritten freeware, which could cause us GPL problems if packaged in a release. Uncgi supports most scripting languages, Mosquito used shell and Jscript for theirs. I know this is a different direction than where we are looking, but thttpd and a generic GPL'ed script interpreter would work ideally. I'd especially like to see a clean, extensible, understandable method for setting up complex networking configurations static routes, since we're supposed to be targeting networking based applications...I have yet to see a method of configuring networking on a linux disto that I would consider intuitively obvious, but I've mainly worked with RH and Caldera. Anyone know if some other disto has already solved this cleanly? Not in an advanced server/routing setting. I could come up with a menu system similar to the kernel menuconfg/xconfig that I think could be a lot clearer considering simple/advanced options. I've tested darn everything but Caldera and Gentoo looking for something similar. I was also working on a similar-type project, before starting LEAF, for a Server-Linux upstart creating a similar menu-system for configuration of Apache, ProFTP, Samba, etc Unfortunately, my hard-drive died the week I was going to upload it and I never bothered to cvs or back it up :( . A good lesson was learned that day. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] weblet the like
On Monday 04 February 2002 08:21, Angelacos, Nathan wrote: Lynn wrote regarding the Mosquito distribution: I have been busy looking at some CGI options myself lately. :) soapboxPersonally, I think there's something fundamentally wrong with managing a firewall/router through a web-based interface, but it seems that I'm the only one who feels this way.../soapbox Nope, your not alone. _Many_ of us feel exactly that way, but may don't and this limits the user base. If this config weblet is loaded as a package, you are only as unhappy as you make yourself :) I've been working on and off on integrating lua into a web server to provide an inline embedded scripting language, similar to PHP. For example: The above generates a web page that knows the local hostname... you get the idea (I hope.) I got micro_httpd working, but it only supports GET requests, so I switched to working with mini_httpd. GET requests work, but I'm still working on the correct approach for POSTS... Kewl, it would need to POST, but the size (on a floppy) is the problem as you mentioned. Advantages I see to this approach are: Let the web server handle the access control, logging, etc. (better security) web pages should be more portable across the LEAF distributions mini_httpd can be built with SSL support, if desired inline-scripting is cool Disadvantages mainly involve size: The statically-linked lua library adds 50-70K to the web server code; lua-enabled mini_httpd is just under 100K in size. (UPX gets it to less than half of that, though). Does anyone out there see a need/use for this kind of thing? Or do you think the standard CGI scripting is fine? (I do realize you can fit alot of weblet pages in 100K) I would agree with everything there, but I feel that the standard CGI is fine _on_ the distribution. SSL will be absolutely necessary for anything run externally, which brings us back to the chicken-n-egg question is sh-httpd configurable for SSL ? -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Where's Charles?
On Monday 04 February 2002 12:18, Charles Steinkuehler wrote: Saddly, I was out of town and couldn't do anything about it, plus it was the weekend before I verified the outage wasn't due to the massive ice-storm we had here in the midwest last week. I figured that the ice had some fun with you ... the cable ISP a litlle further south survived the storm much nicer. I hope you can atleast keep your electricity on! OffTopic In the very near future, I may be seeking other employment, probably consulting/contracting (hardware and/or software development). This could be a boon to my LEAF development, as one of the projects under consideration is an embedded linux based data-logger, likely with a PowerPC or ARM chip. That would be nice :). There's a ton of HP-UX jobs in KC, of which I've never been priviledged enough to check out. Hope you find something you enjoy! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
