Re: [Leaf-devel] network.conf error?
guitarlynn wrote: I'm working on a script that generates Dachstein compliant /etc/modules and /etc/network.conf files and is used as an install option on the lrcfg menu. It is all working at this point _except_ the generated network.conf file. Using the dhcp and firewall options, I get this error on svi network reload: [: missing ] YES: not found YES: not found 1.1.1.2:not found /etc/network.conf: 526: Syntax error: unexpected I can't seem to locate which YES is not found and on 526 the is there on all network.conf's. I've gone through the generated file line by line and can find no difference between the generated one and the one on my present router (cd v1.0.2). Can anyone lend me a hand and find the error? I'm going nuts now! I'm guessing that a control character got in there or something odd. Did you really compare the files to see if they are exactly the same using various unix commands, or did you just read the lines? If you could do an md5sum on both files that was the same, then I'd be convinced, but some sort of cat -v or something would be intersting. Best, Matthew ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] network.conf error?
Matt Schalit wrote: guitarlynn wrote: I'm working on a script that generates Dachstein compliant /etc/modules and /etc/network.conf files and is used as an install option on the lrcfg menu. It is all working at this point _except_ the generated network.conf file. Using the dhcp and firewall options, I get this error on svi network reload: [: missing ] YES: not found YES: not found 1.1.1.2:not found /etc/network.conf: 526: Syntax error: unexpected I can't seem to locate which YES is not found and on 526 the is there on all network.conf's. I've gone through the generated file line by line and can find no difference between the generated one and the one on my present router (cd v1.0.2). Can anyone lend me a hand and find the error? I'm going nuts now! I'm guessing that a control character got in there or something odd. Did you really compare the files to see if they are exactly the same using various unix commands, or did you just read the lines? If you could do an md5sum on both files that was the same, then I'd be convinced, but some sort of cat -v or something would be intersting. Or try to create a network.conf that should be exactly the same as the original and do something like: diff -u network.conf.old network.conf.new Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] [ leaf-Feature Requests-506946 ] Wishlist for next Dachstein release.
Feature Requests item #506946, was opened at 2002-01-22 04:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=363751aid=506946group_id=13751 Category: Dachstein Group: None Status: Open Priority: 5 Submitted By: Ewald Wasscher (ewaldw) Assigned to: Charles Steinkuehler (cstein) Summary: Wishlist for next Dachstein release. Initial Comment: My wishes for Dachstein: Have a source tree in CVS from which one can build the core packages. (initrd?, root, etc, modules, log) Build support for multiple ramdisks into linuxrc. Modify linuxrc to work without sed. This will reduce size if we start using an initrd with statically linked binaries. Personally I think Oxygen linuxrc is cleaner and more readable, so perhaps we could make it a bit like that one and steal a few ideas from it. At least keep 2.2.x kernels as an option as 2.2 masquerading still seems to have better support for difficult protocols like ipsec, directplay, msn messenger to name a few. Also 2.2 kernels are considerably smaller than 2.4 kernels. Keep the possibility of a workable 1-floppy release. This may force us to use an alternative c-library for the core packages, and have glibc as an addon. (did I say uClibc) Create a pre-built 2.2.20 kernel. Skip glibc 2.1.x as it will be autodated quite soon. Generic update of all programs. Replace the usual system programs with smaller versions, or offer smaller ones as an alternative. This will make it easier to keep evertything on 1 floppy. (dcron, udhcp, busybox ash) When we switch to busybox ash: Remove the need for getopts and exp from POSIXness/linuxrc and replace them with busybox expr and getopt. Replace every possible program with their busybox equivalent. Rewrite all initscripts so that these will work with busybox start-stop-daemon once the busybox-unstable branch becomes stable. (In fact it is quite stable already I think) BB start-stop-daemon only accepts short-style arguments like -K not the long style ones like --pid-file=. Ship with some SSH version by default? Web-based configuration? (mini_httpd + ssl?) If possible builtin support for bandwidth managment like Jacques' and Eric's release. With uClibc this should fit on 1 floppy-disk. Ewald Wasscher -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=363751aid=506946group_id=13751 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] network.conf error?
I'm working on a script that generates Dachstein compliant /etc/modules and /etc/network.conf files and is used as an install option on the lrcfg menu. It is all working at this point _except_ the generated network.conf file. Using the dhcp and firewall options, I get this error on svi network reload: [: missing ] YES: not found YES: not found 1.1.1.2:not found /etc/network.conf: 526: Syntax error: unexpected I can't seem to locate which YES is not found and on 526 the is there on all network.conf's. I've gone through the generated file line by line and can find no difference between the generated one and the one on my present router (cd v1.0.2). Can anyone lend me a hand and find the error? I'm going nuts now! I've seen problems of this sort caused by unpaired quotes and improper end-of-lines (ie DOS CRLF instead of unix LF). Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] [dachstein] lrp.conf/multicron Spacecheck problem
KP Kirchdörfer wrote: snip Long Term: I'd also like to see the configuration directory approach taken to logrotate (similar to my RedHat distributions, which already do this), and even inetd (switch to xinetd?). Using files in a configuration directory makes the seperation of configuration information into packages much easier, ideally avoiding any pre/post package install/remove configuration required (or at least limiting it as much as possible). Good ideas; unfortunately xinetd seems to be tree times bigger than inetd and tcpd. Tcpserver from Dan Bernstein's ucspi-tcp package isn't too big, and has per-service configuration files iirc. Of course it only handles tcp streams. But for the bandwidth monitor and sh-httpd it should work. The micro_inetd from http://www.acme.com/ is smaller of course, and only handles one tcp service at a time. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2
Am Montag, 21. Januar 2002 16:54 schrieb Ewald Wasscher: Charles Steinkuehler wrote: Let's start with a wish list, then folks can start working on whatever pieces interest them. Good idea! - Boot-strap code modified to use features available in unpatched kernel (ie no more linuxrc-always or initrd-archive) - 2.1.x or 2.2.x glibc or perhaps uClibc for the core packages, and glibc as an additional one when it's needed. I vote for this one! As I wrote to some of you in private mails, I have a floppy based on the previous release from Jacques booting without any glibc and loading it as the first package. What bothered me, was that we need to use busybox sed instead of sed, which is somewhat different - and since I don't really understand sed, to have success I _played_ with linuxrc, until it seemed to work. Just plain trial-and-error... not very professional and reliable :) Anyway, I could think of a core that boots without glibc and loads glibc 2.0.7 for floppy releases and glibc whatever for CD, HD et al... - Use of new 2.4.x kernel ramdisk/temp filesystems - Updated packaging system Is there someone out who volunteers to make a proposal/summary of all the ideas we have seen about a new packaging in various threads? And to raise another old issue: Will we work with a cvs repository? kp ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2
KP Kirchdörfer wrote: snip Anyway, I could think of a core that boots without glibc and loads glibc 2.0.7 for floppy releases and glibc whatever for CD, HD et al... I think supporting 3 different c-libraries at a time will cause lots of problems for users, and for the developers supporting them. I'd prefer to drop support for the ancient glibc-2.0.7. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2
Anyway, I could think of a core that boots without glibc and loads glibc 2.0.7 for floppy releases and glibc whatever for CD, HD et al... I think supporting 3 different c-libraries at a time will cause lots of problems for users, and for the developers supporting them. I'd prefer to drop support for the ancient glibc-2.0.7. Question: If we drop support for the ancient glibc-2.0.7, will we still able to use the floppy versions? ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2
Luis.F.Correia wrote: Anyway, I could think of a core that boots without glibc and loads glibc 2.0.7 for floppy releases and glibc whatever for CD, HD et al... I think supporting 3 different c-libraries at a time will cause lots of problems for users, and for the developers supporting them. I'd prefer to drop support for the ancient glibc-2.0.7. Question: If we drop support for the ancient glibc-2.0.7, will we still able to use the floppy versions? That will become a bit more difficult. I don't have any exact numbers, but I estimate that glibc 2.2.x will take around 225-250 kb more diskspace than glibc 2.0.7. That why I've been mentioning uClibc for the last few months. Unfortunately not all programs will compile out-of-the-tarball with uClibc, but I think enough programs do to build a decent base system for leaf. For some extra programs glibc will still be needed, but much of that fancy stuff probably won't fit on a floppy anyway. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2
Anyway, I could think of a core that boots without glibc and loads glibc 2.0.7 for floppy releases and glibc whatever for CD, HD et al... I think supporting 3 different c-libraries at a time will cause lots of problems for users, and for the developers supporting them. I'd prefer to drop support for the ancient glibc-2.0.7. Can we provide glibc-2.0.7 as a compatability library, the way RedHat does, so if necessary, folks can run old code without worrying about re-compiles or crashes? I'd like to have a system that could potentially support more than one c library. 2.2.x for current work, 2.0.7 for older, existing LRP packages, and perhaps uClibc (or newlib, tinylibc, or similar) for core floppy or boot-strap features. Anyone know what details have to be dealt with to have multiple c libraries on the system at the same time? Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] [dachstein] lrp.conf/multicron Spacecheck problem
Charles Steinkuehler wrote: For instance, just because your /var/cache maybe full, do you want to arbitrarily purge /var/log files? Not for an instant do I suggest that such complexity is insurmountable; rather, it should be clear that this is far more involved and requires a new paradigm, other than: lrp_SC_DEL_L1=/var/log/*[4-9].gz lrp_SC_DEL_L2=/var/log/*[1-3].gz lrp_SC_DEL_L3=/var/log/*.gz lrp_SC_DEL_L4=/var/log/*.0 lrp_SC_DEL_L5=/var/log/wtmp Also, do not forget, I do not recommend my solution for its completeness; rather, I recommend it because it more accurately addresses the *default* DCD distribution, can be done by changing one (1) line in the current distribution and does *not* require considerable development and testing time. I will at least apply the one line fix in the next release. For the future, I'd like to see support for a configuration directory. There would be some default entries, while add-on packages could drop entries into the /etc/purge.d (or whatever) directory, with customizations for any large temporary files the particular package generates. Do you anticipate that the program (e.g., checkfreespace()) must decide on which filesystem purge-able files reside, or do you see this as a manual, pre-configuration issue for the system administrator? Long Term: I'd also like to see the configuration directory approach taken to logrotate (similar to my RedHat distributions, which already do this), and even inetd (switch to xinetd?). Using files in a configuration directory makes the seperation of configuration information into packages much easier, ideally avoiding any pre/post package install/remove configuration required (or at least limiting it as much as possible). Yes, this appears reasonable. I do not know these features of Redhat -- is there anything similar on Debian? Anyway this goes, as you know from my latest proposal, I have already done the work to get checkfreespace() to df *all* filesystems. That was very simple. Now, we need to decide on the the management system for purge-able files. Once the line is drawn in the sand, I can develop the infrastructure to make appropriate data available to checkfreespace(). What do you think? -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] should LEAF cut over to uClibc? (was: Re: [Leaf-devel]Announcement: LEAF 2.4.16 + Shorewall 1.2.2)
See below. At 07:11 PM 1/22/02 +0100, Ewald Wasscher wrote: Luis.F.Correia wrote: [...] If we drop support for the ancient glibc-2.0.7, will we still able to use the floppy versions? That will become a bit more difficult. I don't have any exact numbers, but I estimate that glibc 2.2.x will take around 225-250 kb more diskspace than glibc 2.0.7. That why I've been mentioning uClibc for the last few months. Unfortunately not all programs will compile out-of-the-tarball with uClibc, but I think enough programs do to build a decent base system for leaf. For some extra programs glibc will still be needed, but much of that fancy stuff probably won't fit on a floppy anyway. Good answer, and I think one that can begin to guide the eventual decision. At some point, LEAF-on-a-floppy should switch from glibc 2.0.7 to uClibc. When? When the stuff that usually is included on actual floppy versions of LEAF can run compiled against uClibc. Looking at what *Stein and Oxygen floppies have historically included is a good way to make concrete the terms enough programs ... to build a decent base system versus some extra programs. To judge from the actual 1680 images I have looked at in the past, enough needs to include the programs normally in about a half-dozen packages. From *memory*, this is, I think, the core list: root.lrp (of course; including ip) dhcp.lrp (the daemon) dhclient.lrp (for external dynamic connections pppoe.lrp (or however Ken packages it) ppp.lrp (for dialup connections and pppoe) sshd.lrp (for remote maintenance) dnscache.lrp (for DNS forwarding) weblet.lrp (for remote configuration/monitoring) (I think all the add-in firewall packages are entirely script based so do not depend on any particular version of the core library.) I may have the details wrong, and I would encourage others to suggest edditions to or deletions from this list. But I think discussing the cutover in terms of actual packages is better than trying to decide whether enough apps will work with uClibc or not. In considering this issue, please remember that David has done some nice work cutting glibc-2.2.x down to a size that can be used on Oxygen floppies. We should not dismiss the possibility of additional work in this area. I'm not getting a good sense form the uClibc list of how much the Lineo layoffs (last summer) have slowed work on it, but I think we need to remain open to all the plausible options. -- Never tell me the odds!--- Ray Olszewski-- Han Solo Palo Alto, CA[EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2
Comments below: Luis.F.Correia wrote: Anyway, I could think of a core that boots without glibc and loads glibc 2.0.7 for floppy releases and glibc whatever for CD, HD et al... I think supporting 3 different c-libraries at a time will cause lots of problems for users, and for the developers supporting them. I'd prefer to drop support for the ancient glibc-2.0.7. Question: If we drop support for the ancient glibc-2.0.7, will we still able to use the floppy versions? That will become a bit more difficult. I don't have any exact numbers, but I estimate that glibc 2.2.x will take around 225-250 kb more diskspace than glibc 2.0.7. That why I've been mentioning uClibc for the last few months. Unfortunately not all programs will compile out-of-the-tarball with uClibc, but I think enough programs do to build a decent base system for leaf. For some extra programs glibc will still be needed, but much of that fancy stuff probably won't fit on a floppy anyway. Ewald Wasscher Most everything you need for a floppy distro compiles under uClibc, including chat, cron, ctar, inetd, ip, iptables, pppd, run-parts, setserial, tc and tcpd, and presumably a bunch of others I haven't tried. Of course, busybox and tinylogin work under uClibc, and do most of the heavy lifting. -Richard ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2
And to raise another old issue: Will we work with a cvs repository? I think this is a must. If we're ever going to get out of the one man distribution era, we need an effective way to replicate build environments, and propogate updates. CVS was made to do exactly this. The big question is do we want to keep the full source-code tree in CVS, or just our mods? I vote for the whole source-code tree, and using CVS branching options to maintain our diffs. This allows us to import new major releases into the CVS tree, and merge any diffs we may have made to the code, which preserves development work we've done, allows fairly easy updates to new major versions, and allows anyone to download the entire build environment, without worring if they've got the exact code-base the developer started with. The model David worked out for building LRP packages (ie a sub-directory that would allow a make lrp) would be updated/extended to make LEAF packages. So, a brief example would perhaps be: Obtain source tree for fancyapp version 1.0.1 and import unmodified code into LEAF CVS archive. A LEAF branch is made from the mainline code. Any required code/configuration modifications are made, and files are added to allow a make LEAF-package functionality Changes are checked into CVS Normal CVS features are used (ie other developers can check-out the code, fix bugs and check-in their updates, etc). Fancyapp 1.1.0 is released...code is downloaded and checked into CVS as mainline code (ie not part of LEAF branch). LEAF branch modifications are merged back into mainline code, to provide an updated LEAF package. If nothing too major changed between the two fancyapp releases, updating to the new version could be virtually automatic (someone just has to run the proper CVS command). The only real problems with this approach: - It requires fairly sophisticated use of CVS to set everything up...this can be handled by simple howto documents. NOTE: Once everything is configured, checking-out and building the code is no more difficult than with a more conventional CVS setup. - We will be keeping all the source code in CVS, not just our mods. This could potentially get quite large, but I think the benifits are worth it. - Potentially, SourceForge could begin to limit CVS archive size...if this happens, we could setup our own CVS archive...either on someone's personal machines (I would volunteer), or perhaps with corperate sponsership. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] network.conf error?
I've seen problems of this sort caused by unpaired quotes and improper end-of-lines (ie DOS CRLF instead of unix LF). Ah so, got it! I eliminated some whitespace I added and found a missing semi-colon on ~line 737. Works now!!! Going to do some connection testing and add a prompt for portfw to an internal server... maybe DMZ. Should be available for testing in day of so. Thanks for the suggestions everyone, I was just venting more than anything. -- ~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] [dachstein] lrp.conf/multicron Spacecheck problem
I will at least apply the one line fix in the next release. For the future, I'd like to see support for a configuration directory. There would be some default entries, while add-on packages could drop entries into the /etc/purge.d (or whatever) directory, with customizations for any large temporary files the particular package generates. Do you anticipate that the program (e.g., checkfreespace()) must decide on which filesystem purge-able files reside, or do you see this as a manual, pre-configuration issue for the system administrator? Hmm... I think ideally, checkfreespace would have to determine which filesystem the purge-able files reside on. One of my major goals for a new distribution is to gracefully support flexible mount-points. While the purge-able files may not change, and so could be included as part of the package itself, there's no way for a package to know ahead of time exactly which file-system the files will reside on. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2
Hello all; due to reported mailing-list problems, please CC, as done, to me. And forgive, if I confuse private mail with list-mail... thanks. Am Dienstag, 22. Januar 2002 19:18 schrieb Charles Steinkuehler: Anyway, I could think of a core that boots without glibc and loads glibc 2.0.7 for floppy releases and glibc whatever for CD, HD et al... I think supporting 3 different c-libraries at a time will cause lots of problems for users, and for the developers supporting them. I'd prefer to drop support for the ancient glibc-2.0.7. IMHO we don't need to support 3 or more libraries. The core should boot (and that's what I've proofed to work) with ulibc and will then load glbic-whatever. I've did some work with dachstein 1.0.2 and glibc 2.1.3 and found, that only squid and ez-ipupdate needed a recompile with glibc 2.1.3 (and please note - I don't know what happended with ez-ipupdate, I suddendly had an very old lrp on my CD-image). All of the other apps are working as expected under 2.1.3, even if they are compiled with 2.0.7. And as you see, the apps above are not the one we consider for a floppy release (which is IMHO the user-space core in opposite to the technical boot core). As another sidenote - once leaf/dachstein allows diffrent glibc-versions, you won't see apps compiled with 2.0.7 anymore - developers will built packages, but they don't have to have an outdated system on the disk to maintain compatability. Being able to boot without glibc and to load libc207.lrp, libc213.lrp or even glibc225.lrp will force developers to use whatever is mainstream among leaf-users, and we will choose the most common determinator, but it is no techinal limitation. Can we provide glibc-2.0.7 as a compatability library, the way RedHat does, so if necessary, folks can run old code without worrying about re-compiles or crashes? I'd like to have a system that could potentially support more than one c library. 2.2.x for current work, 2.0.7 for older, existing LRP packages, and perhaps uClibc (or newlib, tinylibc, or similar) for core floppy or boot-strap features. Anyone know what details have to be dealt with to have multiple c libraries on the system at the same time? I don't understand. My proposal is to have busybox statically linked, since it's needed to boot and to load glibcxxx.lrp, from then on you have glibc.xxx.. It's up to the user to choose the apps and libraries on his own needs and responsability. Ok, on a second thought I understand - providing any glibc independently from any other would be straightforward, I have no idea, but if it works on Red Hat.? kp ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2
At 2002-01-22 12:36 -0600, Charles Steinkuehler wrote: And to raise another old issue: Will we work with a cvs repository? I think this is a must. If we're ever going to get out of the one man distribution era, we need an effective way to replicate build environments, and propogate updates. CVS was made to do exactly this. The big question is do we want to keep the full source-code tree in CVS, or just our mods? I vote for the whole source-code tree, and using CVS branching options to maintain our diffs. This allows us to import new major releases into the CVS tree, and merge any diffs we may have made to the code, which preserves development work we've done, allows fairly easy updates to new major versions, and allows anyone to download the entire build environment, without worring if they've got the exact code-base the developer started with. Charles, I like this idea. I created a src/ tree in our cvs repository in the hope that something like this would be implemented. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/ The model David worked out for building LRP packages (ie a sub-directory that would allow a make lrp) would be updated/extended to make LEAF packages. Auto builds from cvs exports would be great. - We will be keeping all the source code in CVS, not just our mods. This could potentially get quite large, but I think the benifits are worth it. - Potentially, SourceForge could begin to limit CVS archive size...if this happens, we could setup our own CVS archive...either on someone's personal machines (I would volunteer), or perhaps with corperate sponsership. Right now we have unlimited space in our SF CVS repository. If this changes I'll let everyone know in advance, so we can make appropriate arrangements. -- Mike Noyes [EMAIL PROTECTED] https://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] [dachstein] lrp.conf/multicron Spacecheck problem
Am Dienstag, 22. Januar 2002 19:39 schrieb Michael D. Schleif: KP Kirchdörfer wrote: Am Dienstag, 22. Januar 2002 19:21 schrieben Sie: KP Kirchdörfer wrote: Am Montag, 21. Januar 2002 15:54 schrieb Charles Steinkuehler: I will at least apply the one line fix in the next release. For I've done the one line fix, which is indeed a two-line fix in lrp.conf and multicron. [ snip ] What is the second line? What do you change in /etc/lrp.conf? My initial proposal requires only one (1) line modification and only in multicron . . . I've added lrp_CHK_PART=/ to lrp.conf and used this variable in multicron, for the reasons I've explained in the mail you're referring to. As you know, this does nothing to address the issues regarding *which* files to purge. Ok, you're right - due to private circumstances I'm not that concentrated I wish I am... Sorry for confusion and starting at the beginning of the discussion. What do you make of my most recent proposal that completely resolves both your mailspacelow() issue, as well as the file purge issues? I've saved it in my mailfolder and thought, it might be worth for testing. kp ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] [dachstein] lrp.conf/multicron Spacecheck problem
Charles Steinkuehler wrote: I will at least apply the one line fix in the next release. For the future, I'd like to see support for a configuration directory. There would be some default entries, while add-on packages could drop entries into the /etc/purge.d (or whatever) directory, with customizations for any large temporary files the particular package generates. Do you anticipate that the program (e.g., checkfreespace()) must decide on which filesystem purge-able files reside, or do you see this as a manual, pre-configuration issue for the system administrator? Hmm... I think ideally, checkfreespace would have to determine which filesystem the purge-able files reside on. One of my major goals for a new distribution is to gracefully support flexible mount-points. While the purge-able files may not change, and so could be included as part of the package itself, there's no way for a package to know ahead of time exactly which file-system the files will reside on. I didn't want to assume; but, that direction makes sense if packages are to contain purgeable file definitions. Is it fair to say that *all* applicable filesystems are ramdisks and, therefore, can be identified according to form: /dev/ramX ? The tools available are busybox grep and sort, and real sed? Once I define the requirements, then I can build it . . . -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Announcement: LEAF 2.4.16 + Shorewall 1.2.2
Luis.F.Correia wrote: That will become a bit more difficult. I don't have any exact numbers, but I estimate that glibc 2.2.x will take around 225-250 kb more diskspace than glibc 2.0.7. For Oxygen-1.8.0 (the current release): libc.lrp takes 522285 bytes on the floppy. libc-2.1.3.so takes up 1060136 bytes expanded. Matt ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Site Update 2002-01-22
Everyone, I created phpWS admin/author accounts for all of our developers. Send me email off list for login instructions. Note: our phpWebSite doesn't share authentication with SourceForge. I backed up our MySQL database, and performed the following modifications. mysql ALTER TABLE developer MODIFY short CHAR(30); mysql DELETE FROM users; *** Individual Developer Content Backup Responsibility *** Each developer is responsible for backing up their devel and home directories on the shell server, and their devel cvs tree. Backup commands: Replace all instances of yourname with your SF unix user name, and replace all instances of localdir with a local directory you wish store the backup in. $ rsync -e ssh -l yourname -av --partial --delete \ shell.sf.net:/home/user/y/yo/yourname localdir $ rsync -e ssh -l yourname -av --partial --delete \ shell.sf.net:/home/groups/l/le/leaf/devel/yourname localdir $ cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/leaf \ -q export -D `date +%Y-%m-%d` -d localdir devel/yourname *** LEAF Site Backup/Mirror Instructions (alpha) *** You will need approximately 3G of disk space to fully mirror our site, and must be a member of our project. Get files: $ rsync -e ssh -l yourname -av --partial --delete \ shell.sf.net:/home/groups/l/le/leaf localdir $ wget http://cvs.sourceforge.net:80/cvstarballs/leaf-cvsroot.tar.gz wget -m ftp://ftp.sourceforge.net:21/pub/sourceforge/leaf/ phpWebSite setup: Read the documentation in leaf/htdocs/docs, and here: http://res1.stddev.appstate.edu/horde/chora/cvs.php/phpwebsite/docs Then, modify the config.php file in leaf/mirror, and copy it into leaf/htdocs. Then import the mysqldump in leaf/mirror into your dbase with: $ mysql -u user_name -p database_name leaf_YY-MM-DD.sql -- Mike Noyes [EMAIL PROTECTED] https://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] [dachstein] lrp.conf/multicron Spacecheck problem
I think ideally, checkfreespace would have to determine which filesystem the purge-able files reside on. One of my major goals for a new distribution is to gracefully support flexible mount-points. While the purge-able files may not change, and so could be included as part of the package itself, there's no way for a package to know ahead of time exactly which file-system the files will reside on. I didn't want to assume; but, that direction makes sense if packages are to contain purgeable file definitions. Is it fair to say that *all* applicable filesystems are ramdisks and, therefore, can be identified according to form: /dev/ramX ? No. Even in existing systems, some folks have hard-disks, or will leave the floppy or CD-ROM drive mounted. The CD-ROM causes problems, as it's always 100% full. Systems may also be using flash disks (MTD), Disk-on-Chip (M-systems or MTD driver), and other devices for storage. The tools available are busybox grep and sort, and real sed? Plus ash (the built-in string handling is quite powerful, once you get the hang of it...see the sh-httpd script for some examples). In general, I'd say anything that's on Dachstein right now would be usable, but stick with the ash subset of available bash commands. Once I define the requirements, then I can build it . . . I'm envisioning something like: df indicates a partition is past is usage limit...mount points saved for use later /proc/mounts checked to verify partition is RW purgable file list built from /etc/purge.d directory or similar. Remember, sed can be very powerful for things like this... segway Assume a directory of files, with each file containing entries (one per line), consisting of two fields, a number (the purge-level), and a file-spec (wildcards OK). Check the list of mount-points for any with a leading portion that matches the over-full mount point (ie /var/log is full, but /var/log/httpd, a seperate mount point, isn't). Add any matching mount points to an exclude list. Build a single sed command to delete any un-desired file specs, and strip off the purge-level...start with /^1/!d (where one is the desired purge level), add delete commands for each sub-mount point (ie \:var/log/httpd:d), and end with a substute command to strip the leading field ( s/^[0-9 tab]*// ) and run it on all the purge-able file lists (for FILE in `sed $sedcmd /etc/purge.d/*` ; do rm $FILE ; done) /segway Verify enough space has been made available on file-system...if not, increase purge-level and repeat... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] [dachstein] lrp.conf/multicron Spacecheck problem
Build a single sed command to delete any un-desired file specs, and strip off the purge-level...start with /^1/!d (where one is the desired purge level), add delete commands for each sub-mount point (ie \:var/log/httpd:d), and end with a substute command to strip the leading field ( s/^[0-9 tab]*// ) and run it on all the purge-able file lists (for FILE in `sed $sedcmd /etc/purge.d/*` ; do rm $FILE ; done) Oops! You also need to delete any files that don't reside on the over-full partition before the final substitute command... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
