[Leaf-devel] CVS export date?
Everyone, Which of these export date commands is recommended method for exporting the current tree. Is the quote nesting I used in the first example technically correct? Both examples below appear to function as expected. cvs -d:ext:mhnoyes@cvs1:/cvsroot/leaf -q export -D \ `date '+%Y-%m-%d %T %Z'` -d doc doc or cvs -d:ext:mhnoyes@cvs1:/cvsroot/leaf -q export -D \ `date -u` -d doc doc -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- 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: Standards and due process :-)
On 2/14/02 at 3:34 PM, Serge Caron [EMAIL PROTECTED] wrote:
Linux people are usually more intelligent than I am. Your
sed mask allows for stuff like ...etc and ../../../etc and
all kinds of ganes that I prefer not to play :). Following
your intervention, the original sed command now reads
...I just LOVE a good sed challenge :-)
sed -e /^etc[[:space:]]*$/d -e /^[/]etc[[:space:]]*$/d \
-e /^[.][/]etc[[:space:]]*$/d \
-e /^etc[/]/d -e /^[/]etc[/]/d -e /^[.][/]etc[/]/d \
${pkg} ${pkg}.light
First, with GNU sed:
sed -e '..' -e '..' -e '...'
can be written as:
sed '; .; .'
...also, it would appear that your matches are overlapping... why
not:
sed '/\.*\/*etc/{
/^etc[ ^I]*$/d
/^\.\/etc[ ^I]*$/d
/^\/etc[ ^I]*$/d
/^etc\//d
/^\.\/etc\//d
/^\/etc\//d
}' $pkg $pkg.light
The first line matches only those things that contain etc with any
number of periods and slashes (in that order) - which means you've
just ruled out a TON of things. Should be faster - only one match...
Using \. instead of [.] will save you one '.' - and it is probably
faster to use a single character instead of a set.
You don't need curly brackets ${} unless it is unclear where the name
starts and ends so ${pkg} is unnecessary, as is ${pkg}.light
(period stops the name) - but ${pkg}light and ${pkg}2 are necessary
if you want pkglight and pkg2 for names...
As a case in point, Bering does not have netstat, a
fixture in this environment since the early LRP days. In
the confined space of a floppy, Jacques Nilo decided
something that made sense for his project and he can
revisit his decision at any time. In the meanwhile, you
have Bering to play with.
netstat was also removed from Oxygen a while back; I think Linux in
general has made plain that netstat / route / ifconfig are to be
considered old and one is to use ip instead.
Oxygen dumped all three when space got tight; they are available as
packages.
--
David Douthitt
UNIX Systems Administrator
HP-UX, Unixware, Linux
[EMAIL PROTECTED]
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] More on dates
David Douthitt wrote: On 2/9/02 at 2:14 AM, Michael D. Schleif [EMAIL PROTECTED] wrote: However, since we are limited to shell scripting and my recent work on leaf has required me to compare dates and times, a working-as-advertised -d operation would simplify alot for me . . . What do you think? The date replacement I was considering does NOT have a -d option - only a -u option and the +%...format string... I hadn't seen the 'date -d STRING' format before, until I saw it as an option to busybox date. Is it common? I don't think so at this point, and we can do what we want with a working %format sequence, right? Matthew ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] DCD: ipfilter.conf patch
Here is a patch for /etc/ipfilter.conf [DCD, v1.0.2], the need for which
I discovered while researching my multiple external interface challenge:
# diff -bu ipfilter.conf ipfilter.conf.OLD
--- ipfilter.conf Mon May 6 16:30:20 2002
+++ ipfilter.conf.OLD Mon May 6 16:10:14 2002
@@ -171,11 +171,8 @@
local DST_PORT=${5:-$3}
# For internal connections
- for NET in $INTERN_NET; do
$IPCH -A forward -j MASQ -p $1 -s $DMZ_NET $DST_PORT \
- -d $NET -i $INTERN_IF
-### -d $INTERN_NET -i $INTERN_IF
- done; unset NET
+-d $INTERN_NET -i $INTERN_IF
if [ $OUTBOUND_ALL != YES ]; then
@@ -774,14 +771,7 @@
walk_list DMZ_SERVER $INIT_INDEX port_forward
# Masquerade internal network to DMZ network
- for NET in $INTERN_NET; do
-###$IPCH -A forward -j MASQ -p all -s $INTERN_NET -d
$DMZ_NET -i $DMZ_IF
- $IPCH -A forward -j MASQ -p all -s $NET -d $DMZ_NET -i
$DMZ_IF
- done; unset NET
- $IPCH -A forward -j MASQ -p all -s $net -d $DMZ_NET -i $DMZ_IF
-
- done
- unset net
+ $IPCH -A forward -j MASQ -p all -s $INTERN_NET -d $DMZ_NET -i
$DMZ_IF
if [ $DMZ_OUTBOUND_ALL = YES ]; then
@@ -800,7 +790,6 @@
-o $MASQ_SWITCH = yes ]; then
for NET in $INTERN_NET; do
$IPCH -A forward -j MASQ -p all -s $NET -d 0/0 -i
$EXTERN_IF
-
done; unset NET
fi
--
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 . . .
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Serge Caron wrote:
[ snip ]
By formulating the concept of a default store and that of an exclusion list,
here is _what_I_do_today_ : I boot from a CD which gives me all the storage
I need for the job at hand. I define my default store to be on the _floppy_.
So far, so good? Then I have this code snippet as part of the boot sequence:
for pkg in /var/lib/lrpkg/*.list; do
sed -e /^etc/d -e /^[/]etc/d -e /^[.][/]etc/d \
${pkg} ${pkg}.light
cmp -s ${pkg} ${pkg}.light
if [ $? = 0 ]; then
rm ${pkg}.light
else
echo ${pkg}
mv ${pkg}.light ${pkg}
fi
done
[ snip ]
I am confused ;
[1] Shouldn't your sed process:
sed -e /^etc/d -e /^[/]etc/d -e /^[.][/]etc/d \
${pkg} ${pkg}.light
actually be this?
sed -n /^[./]*etc/p ${pkg} ${pkg}.light
[2] How do you account for ${pkg}.exclude.list?
[3] How do you account for CONF files that do not reside under /etc?
[4] Where do you get `cmp'?
--
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] apkg -u, the deception?
Hi KP > I also _believe_ , that integration of apkg -u into the upgrade script will > be > easier to accomplish the then smaller changes and more helpful, than reinvent > apkg and configdb. I have been thinking hard about this and I believe you are wrong in this aspect. Let me state why I think this is so - we have a package A of version 1.0 which we just call A - we have a config file AC belonging to package A , call this AC - we have an installed package A with a modified config file AC, call this AC' - we can detect the difference between AC and AC', lets call this D - we have a package A of version 1.1, lets call this A1 - we have a config file AC belonging to package A1, lets call this AC1 - let us assume that AC <> AC1 - we want an installed package A1 with the adjusted config file AC1' therefore we need a transformation from AC' to AC1' - there is no direct transformation from AC' to AC1' - we can build AC1' by applying D to AC1 Right now we do not save D, but we save AC' If we replace AC by AC1 (by replacing the corresponding package A by A1) then we lose the capability to generate the difference D and as a consequence we loose the transformation from AC1 to AC1' This leads me to the conclussion that the transformation of AC' to AC1' cannot only work if either - D is saved, because then we can apply D to AC1 - AC, AC1 and AC1' are available, because then we can calculate D So a tool like apkg -u cannot work unless it is applied from a location different from the original boot location, because once the package A has been overwritten by A1 the reference to AC is lost. Is there a description how apkg -u is to be used? cheers ET -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] More on dates
On 2/9/02 at 2:14 AM, Michael D. Schleif [EMAIL PROTECTED] wrote: However, since we are limited to shell scripting and my recent work on leaf has required me to compare dates and times, a working-as-advertised -d operation would simplify alot for me . . . What do you think? The date replacement I was considering does NOT have a -d option - only a -u option and the +%...format string... -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] DCD /etc/init.d/netstd_misc ???
Likewise: /etc/init.d/netstd_init ??? Michael D. Schleif wrote: Why does this file exist? It does nothing and wastes space . . . 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
Re: [leaf-devel] [pedro.inacio@ptnix.com: PHP-Nuke x.x SQL Injection]
Hi Dave, On 2002.09.25_17:08:18_+, David Douthitt wrote: Saw this on bugtraq today. Does this affect our PHP site? The LEAF site is using phpWebSite, isn't it? CMIIW. I also saw a post on bugtraq regarding phpWebSite, two days ago. -- H. D. Lee --- 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] /linuxrc testing - round 2
K.-P. Kirchdörfer wrote:
Charles;
I may have found another small problem:
firewall# lrpkg -i squid-2.lrp
Installing squid-2 ... cat: /var/lib/lrpkg//boot.fstype: No such file or
directory
Done.
I was told:
It could be a bug (from the lrpkg script):
echo $fn=-t `cat $lrpkgpath/boot.fstype` $d$lrpkgpath/backdisk
but boot.fstype is obsoleted with new linuxrc.
Any idea how to solve?
This is a known bug. The error message is effectively harmless, and
only appears when manually installing packages.
The result of this bug is you must manually specify the backup disk when
first backing up a package you manually installed (which you'd probably
have to do anyway), rather than having it default to the (no longer
existing) /dev/boot device.
Assuming using the first entry in pkgpath.disks in place of the missing
boot device/fs info is acceptable, the following will fix the problem:
echo $fn=-t `cat $lrpkgpath/boot.fstype` $d$lrpkgpath/backdisk
Replace with (all one line):
echo $fn=-t `sed -n '\:'$d':{s/^.* //;p;}' $lrpkgpath/pkgpath.disks`
$lrpkgpath/backdisk
A bit above this, the handling of $d needs to be tweaked as well:
Was:
if [ -z $2 ]; then
local d=`sed 's/.*boot=/\1/; s/[: ].*//' /proc/cmdline`
else
Replace with:
if [ -z $2 ]; then
local d=`sed -n '1{s/ .*$//;p;}' $lrpkgpath/pkgpath.disks`
else
The (unused) mount.boot procedure should be removed.
...and finally, the mount.back procedure should be tweaked:
Was:
if [ $dev = ]; then
mount -t `cat /var/lib/lrpkg/boot.fstype` /dev/boot $2
else
Replace with (between if/else is one line):
if [ $dev = ]; then
mount -t `sed -n '1{s/\([^ ].*\) \(.*\)$/\2 \1/;p;}'
$lrpkgpath/pkgpath.disks` $2
else
Of course, it wouldn't hurt to s:/var/lib/lrpkg:$lrpkgpath: on the whole
file, to remove any remaining absolute references to the package directory.
NOTE: Mods above have been briefly tested for correct shell quoting and
functionality, but no guarantee is expressed or implied!
--
Charles Steinkuehler
[EMAIL PROTECTED]
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] dcd: cleanup issues ???
guitarlynn wrote: 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. O, now I see it: /etc/init.d/mountnfs.sh OK, /etc/rpc needs to stay . . . -- 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 . . . --- 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] ML volume
Michael D. Schleif wrote about Re: [leaf-devel] ML volume: Add to d) leaf-general, or some such. If this is divvied up to fine, then how will the generalists lend support? I have a feeling that nobody will subscribe to it. IMHO you need to make lists for branches which have big differences from each other. I see at least two: Bering and WISP-Dist. From what I understand Bering is mostly backwards compatible with Dachstein, so maybe same mailing list can be used for both Bering Dachstein. -- Best Regards, Vladimir Systems Engineer (RHCE) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] runtime keyboard controller detection for LEAF
KP, here's a change I'd like to see implemented in the kernel. It removes the old hard-coded keyboard controller check code for a much more simple runtime detection of the keyboard. With this patch, there will be no more reason to produce two different kernels for B-U afaik. Everything goes in the linux top level buildtool.mk directory buildtool.cfg has replaced the old patch with the new one buildtool.mk has been fixed to call the new patch and ALSO srcclean cleans openswan_dir kbc_runtime_detect_2_4.diff.gz is the new patch Please send me e-mail with any questions. Paul # buildtool make file for buildenv # $Id: buildtool.mk,v 1.15 2005/07/29 21:19:10 espakman Exp $ # # Note that this is some kind of a hack as you normally should do things # not the way they are handled here OPENSWAN_DIR:=openswan-1.0.9 include $(MASTERMAKEFILE) $(BT_LINUX_DIR)/.source: bzcat $(KERNEL_SOURCE) | tar -xvf - ln -s linux-2.4.31 linux zcat $(KERNEL_PATCH1) | patch -d linux -p1 zcat $(KERNEL_PATCH2) | patch -d linux -p1 zcat $(KERNEL_PATCH3) | patch -d linux -p1 zcat $(KERNEL_PATCH4) | patch -d linux -p1 zcat $(KERNEL_PATCH5) | patch -d linux -p1 zcat $(KERNEL_PATCH6) | patch -d linux -p1 zcat $(KERNEL_PATCH7) | patch -d linux -p1 zcat $(KERNEL_PATCH8) | patch -d linux -p1 zcat $(KERNEL_PATCH9) | patch -d linux -p1 zcat $(KERNEL_PATCH10) | patch -d linux -p1 zcat $(KERNEL_PATCH11) | patch -d linux -p1 # openswan stuff zcat $(OPENSWAN_SOURCE) | tar -xvf - # this patches the kernel - so we'll do it here $(MAKE) KERNELSRC=$(BT_LINUX_DIR) -C $(OPENSWAN_DIR) insert cp $(LINUX_CONFIG) linux/.config touch $(BT_LINUX_DIR)/.source $(BT_LINUX_DIR)/.configured: $(BT_LINUX_DIR)/.source perl -i -p -e 's,EXTRAVERSION\s*=.*,EXTRAVERSION =,g' $(BT_LINUX_DIR)/Makefile $(MAKE) -C linux oldconfig $(MAKE) -C linux include/linux/version.h touch $(BT_LINUX_DIR)/.configured source: $(BT_LINUX_DIR)/.source $(BT_LINUX_DIR)/.configured build: $(BT_LINUX_DIR)/.configured echo nothing done here right now, all done by buildenv and kernel package clean: -rm $(BT_LINUX_DIR)/.configured $(MAKE) -C linux clean srcclean: rm -rf linux rm -rf linux-2.4.31 rm -rf $(OPENSWAN_DIR) # things for kernel source Server kernel.org Type = http Name = www.de.kernel.org Serverpath = /pub/linux/kernel/v2.4 /Server File linux-2.4.31.tar.bz2 Server = kernel.org envname = KERNEL_SOURCE /File File buildtool.mk Server = cvs-sourceforge Directory = linux Revision = HEAD /File File helpers-2.4.29.patch.gz Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH1 Revision = HEAD /File File ebtables-brnf-9_vs_2.4.30.diff.gz Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH2 Revision = HEAD /File File linux-2.4.25-mppe-20040216.patch.gz Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH3 Revision = HEAD /File File grsecurity-2.1.6-2.4.31-200506141150.patch.gz Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH4 Revision = HEAD /File File wd1100_patch.gz Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH5 Revision = HEAD /File File netconfig.diff.gz Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH6 Revision = HEAD /File File kbc_runtime_detect_2_4.diff.gz Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH7 Revision = HEAD /File #connmark support File connmark.patch.gz Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH8 Revision = HEAD /File #wireless extensions v18 File iw249_we17-13.diff.gz Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH9 Revision = HEAD /File File iw240_we18-5.diff.gz Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH10 Revision = HEAD /File #fix ipv6 bug File ipv6-2.4.31.patch.gz Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH11 Revision = HEAD /File File Bering-2.4.31.config Server = cvs-sourceforge Directory = linux envname = LINUX_CONFIG Revision = HEAD /File File openswan-1.0.9.tar.gz Server = cvs-sourceforge envname = OPENSWAN_SOURCE directory = openswan revision
Re: [Leaf-devel] Re: Standards and due process :-)
Serge Caron wrote:
[ snip ]
mds said:
By-the-by, this is considerably faster:
sed -e /^[./]*etc/d ${pkg} ${pkg}.light
Linux people are usually more intelligent than I am. Your sed mask allows
for stuff like ...etc and ../../../etc and all kinds of ganes that I prefer
not to play :).
Nevertheless, since all backup operations are performed from root (/) --
a very sound *convention* and *standard*, yes? -- what is the actual
difference between our regex's, other than doing everything in one (1)
call to shell?
Following your intervention, the original sed command now
reads
sed -e /^etc[[:space:]]*$/d -e /^[/]etc[[:space:]]*$/d \
-e /^[.][/]etc[[:space:]]*$/d \
-e /^etc[/]/d -e /^[/]etc[/]/d -e /^[.][/]etc[/]/d \
${pkg} ${pkg}.light
If you must:
sed -e /^etc[[:space:]]*$/d
/^[/]etc[[:space:]]*$/d
/^[.][/]etc[[:space:]]*$/d
/^etc[/]/d
/^[/]etc[/]/d
/^[.][/]etc[/]/d ${pkg} ${pkg}.light
Or:
sed -e /^[.]\{0,1\}[/]\{0,1\}etc[[:space:]]*$/d
/^[.]\{0,1\}[/]\{0,1\}etc[/]/d ${pkg} \
${pkg}.light
Or:
sed -e /^[.]\{0,1\}[/]\{0,1\}etc[/[:space:]]*$/d ${pkg} \
${pkg}.light
I really don't like to see repeated calls to same executable in
production code -- just part of my process ;
[ snip ]
When I want a snapshot of my machines, I want _everything_ in etc. Life is
like that :-)
Didn't you just *exclude* these same files in your sed process? How do
you get everything that you just excluded _after_ explicitly excluding
it?
Clearly, I am missing something profound here . . .
[ snip ]
Now, to answer your question: you are looking for a baseline specification
:-). David Douthitt is *RIGHT* when he says that there should not be a
baseline specification, either explicitly specified for LEAF or indirectly
specified by refering to a distribution. We are dealing with unspecidied
hardware constraint, some of which are not obvious as in the case of the
write-protect switch. As a case in point, Bering does not have netstat, a
fixture in this environment since the early LRP days. In the confined space
of a floppy, Jacques Nilo decided something that made sense for his project
and he can revisit his decision at any time. In the meanwhile, you have
Bering to play with.
This is where I believe that we really part company. Since you insist
on this choice of words, I have no choice, but to take you literally:
``there should not be a baseline specification''
If this is the case and it is *explicitly* enforced, then it follows --
absolutely -- that nobody can build any package for leaf/lrp and expect
that it will perform according to any given specification! Period.
In fact, a system, such as leaf and lrp, is and always has been founded
on a -- confusing -- myriad of tacit specifications. It is this implied
set of conventions that I am addressing -- the fact that these
specifications are largely unwritten and, therefore, understood by a
very small minority. I maintain that, without any specification, there
would be no lrp and no leaf and no List Service on which to debate these
arcane issues.
It is another fact that I cannot, nor can anybody else, willy-nilly
construct any haphazard package, load it into a running leaf/lrp
environment and expect that that system will continue to run with its
baseline integrity; much less, that my package will perform as I
expect. We are dealing with systems predicated on baseline security and
integrity -- are we not?
Therefore, I insist that *NOW* is the time to publish an explicit set of
baseline conventions and standards for leaf -- prior to landing squarely
in the midst of 2.4.x land!
Let us take what has been learned from years of LRP, take what has
worked best, discard what has proven most costly -- however many or few
those specifications might be -- and make a clean break with the past.
Draw a line in the sand -- this side is the new land of LEAF and that
other side is the past and LRP. Again, these clear demarcations --
devised solely in the spirit of the lean and mean and embeddedness that
we admire most in LEAF -- can only contribute to the greater good.
NO, I am not advocating any system of commandments and laws,
transgression of which invokes the ire of the greater community; rather,
I believe that it is important -- no, critical -- that I, as LEAF user
and, especially, as LEAF developer -- know what I can expect from a
small set of system constructs.
For example, /var/log is the standard residence of logfiles. Looking
under that directory, I should never find executable files -- or, should
I?
For example, the root directory (/) should be residence to directories
*only* or, at least, *no* ordinary nor executable files -- or, should
it?
For example, /etc should house, among else, configuration files,
including a system of symbolic links facilitating
[Leaf-devel] LRP and Kernel 2.4
Hi, has anybody done this? -- arne --- Arne Bernin Netropol Digitale Systeme Lagerstrasse 30a Tel: +49 404325 D-20357 Hamburg/Germany Fax: +49 40 43189490[EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/mailman/listinfo/leaf-devel
[Leaf-devel] dachstein-cd 1.1 ipsec
Hello, I'm using dachstein-cd 1.1 and ipsec. I've used the old linux router 2.9.4 with ipsec, but i had to add a few lines in the ipchains to allow ipsec to work. what is the theory on getting it to work with the new dachstein cd? here's what i had in the old version, but i don't see the corresponding rules in the new dachstein version. # Forward anything from IPSEC tunnel and except all input from IPSEC tunnel ipchains -A forward -j ACCEPT -i ipsec0 -s 0/0 -d 0/0 ipchains -A input -j ACCEPT -i ipsec0 -s 0/0 -d 0/0 # ipsec incoming/outgoing for CURGW in $IPSECSG; do $IPCH -A input -j ACCEPT -i $EXTERN_IF -p udp -s $CURGW 500 $IPCH -A output -j ACCEPT -i $EXTERN_IF -p udp -d $CURGW 500 $IPCH -A input -j ACCEPT -i $EXTERN_IF -p 50 -s $CURGW $IPCH -A output -j ACCEPT -i $EXTERN_IF -p 50 -d $CURGW done I've changed the EXTERN_UDP_PORTS to allow the remote ipsec machine to use UDP port 500, and EXTERN_PROTO0 to allow proto 50 from the remote ipsec machine, but what about the rules to allow traffic through the ipsec0 interface? thanks, jim mcdonagh _ This Outbound message has been checked for all known viruses by the MessageLabs Virus Scanning Service. For further information visit http://www.messagelabs.com/stats.asp ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] DFE-570TX ?
Does anyone have any experience using a D-Link DFE-570TX 4-Port NIC under Linux? From what I've been able to piece together is that the standard tulip module should work for it since its using 4 x DEC DC21143 chips. -Kenneth Hadley ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ES3 suggestion
1. First, when it refreshes, I'm not sure that it flushes the rules *and* the portfw's/autofw's. I could be wrong here, but I think it only flushes the ipchains rules and doesn't touch what was previously setup with ipmasqadm. I'll check this. 2. Given the increased popularity of ISPs giving out RFC-1918 private addresses with DHCP and then static NAT'ing them, I think part of the firewall setup which blocks the RFC-1918 address specifically should be dropped. While I still think the private IP's should be blocked by default, there should be an easy way to disable a particular range, and documentation on the fact that this might be required. I'll add a way to do this in the new firewall scripts. 3. Many of the trojan's I've read about use blind-attacks where a response from the target isn't needed. So the attacker can spoof the return IP address, and they often choose from the reserve-address range (and use the eleet port of 31337). Anyhow. as per CIAC alert K-032, I think the following reserved address traffic should be blocked explicitly: $IPCHAINS -A input -i $IF_EXT -b -s 0.0.0.0/8 -j DENY $IPCHAINS -A input -i $IF_EXT -b -s 224.0.0.0/4 -j DENY $IPCHAINS -A input -i $IF_EXT -b -s 240.0.0.0/5 -j DENY The above IP's are already blocked... $IPCHAINS -A input -i $IF_EXT -b -s 169.254.0.0/16 -j DENY $IPCHAINS -A input -i $IF_EXT -b -s 192.0.2.0/24 -j DENY $IPCHAINS -A input -i $IF_EXT -b -s 248.0.0.0/5 -j DENY I'll check into blocking these IP's as well... 4. Lastly, at the end of the setup script, some noise blocker rules should be stuck in. This helps eliminate log file buildup (and the risk of resulting tooth decay...). Since they're at the very end, they not interfering with normal op's that would have been setup earlier. $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 137 -p tcp -j DENY $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 137 -p udp -j DENY $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 138 -p tcp -j DENY $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 138 -p udp -j DENY $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 67 -p udp -j DENY The above are already blocked w/o logging (along with a few more netbios ports: 135 139)... $IPCHAINS -A input -i $IF_EXT -d 0.0.0.0/0 68 -p udp -j DENY $IPCHAINS -A input -i $IF_EXT -d 255.255.255.255 -j DENY Again, I'll look into blocking these IP's as well... That's it. Please let me know what you think. Of course, I'd be willing to do the dirty work of editing the scripts and tar'ing them up for the inclusion in the new release. Just wanted to be sure the above has enough perceived value. I need to fold my extended V1.0 V1.1 functionality together with my latest proxy-arp DMZ scripts, so I can make the mods, but pointers to any RFC's or other docs that refer to the new subnet ranges you think should be blocked would be helpful... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] (Fwd) please help with webcfg bash script
Eric Wolzak wrote: snip # But now I found a bug :( # snip # change # # evaluate returnnames to local names # # As I use uncgi the fieldnames are returnde as $WWW_name # This is probably unneccessary. # The problem is however the name$nr # # - # Those are the troublesome lines # --- # eval name=\$WWW_name$nr eval ip=\$WWW_ip$nr # # - # this functions good unless name1 2 etc. contains a special char # for example * # the eval function will find a filename for it and not just write it to the # database # the same trouble could probably be caused by backticks in a name # any suggestion to improve this ? # # or in other words how can I evaluate a number of numbered fieldnames without # evaluating the contents. # #--- Are you sure you have a problem? This works for me in both bash and ash shells on Dachstein: Ash: tempest: -root- # name1=*.* ; x=1 tempest: -root- # eval z=\$name$x tempest: -root- # echo name1: $name1 ; echo z: $z name1: *.* z: *.* Bash: tempest: -root- # name1=*.* ; x=1 tempest: -root- # eval z=\$name$x tempest: -root- # echo name1: $name1 ; echo z: $z name1: *.* z: *.* # # test if the first or obligate field is empty # if [ -n $name ]; then # # # write the row # option that can be empty are set in their own line # $cdb set tree $tree/$ct name $name ip $ip I think this is your problem...using the above hand-entered test code, follow up with: tempest: -root- # echo $name1 *.* tempest: -root- # echo $name1 POSIXness.conf ae.rc checksecurity.conf cron.d cron.daily cron.monthly cron.weekly dhcpd.conf host.conf hosts.allow hosts.deny hosts.equiv inetd.conf init.d ioctl.save ipchains.forward ipfilter.conf ipsec.conf ipsec.secrets issue.net login.access lrp.conf minirc.dfl network.conf nsswitch.conf pcnfsd.conf ramdisk.conf rc.boot rc0.d rc1.d rc2.d rc3.d rc4.d rc5.d rc6.d rcS.d resolv.conf snmpd.agentinfo snmpd.conf syslog.conf What happens if you try: $cdb set tree $tree/$ct name $name ip $ip Thanks for any help No problem...getting quotes in the proper place can be tricky sometimes in shell script. You might want to checkout the ash man page (easier to comprehend than the much larger bash man page), starting with the Word Expansions topic, which covers expansion order and goes on to detail exactly how arguments are processed. You might also find the set -x command handy, which will dump the actual command the shell runs after various word expansions have occured) to err-out...a handy debugging tool for shell code. Handy ash man page link: http://www.leaf-project.org/devel/cstein/Documentation/ash.html -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] apkg -u, the deception?
Hi Erich; Am Donnerstag, 15. Oktober 2015, 08:27:56 schrieb Erich Titl: > Hi KP > > > I also _believe_ , that integration of apkg -u into the upgrade script > > will be easier to accomplish the then smaller changes and more helpful, > > than reinvent apkg and configdb. > > I have been thinking hard about this and I believe you are wrong in this > aspect. > Let me state why I think this is so > > - we have a package A of version 1.0 which we just call A > - we have a config file AC belonging to package A , call this AC > - we have an installed package A with a modified config file AC, call > this AC' > - we can detect the difference between AC and AC', lets call this D > - we have a package A of version 1.1, lets call this A1 > - we have a config file AC belonging to package A1, lets call this AC1 > - let us assume that AC <> AC1 > - we want an installed package A1 with the adjusted config file AC1' > > therefore we need a transformation from AC' to AC1' > > - there is no direct transformation from AC' to AC1' > - we can build AC1' by applying D to AC1 > > Right now we do not save D, but we save AC' > > If we replace AC by AC1 (by replacing the corresponding package A by A1) > then we lose the capability to generate the difference D and as a > consequence we loose the transformation from AC1 to AC1' > > This leads me to the conclussion that the transformation of AC' to AC1' > cannot only work if either > > - D is saved, because then we can apply D to AC1 > - AC, AC1 and AC1' are available, because then we can calculate D > > So a tool like apkg -u cannot work unless it is applied from a location > different from the original boot location, because once the package A > has been overwritten by A1 the reference to AC is lost. No; we only need the new package with the AC1 and the AC', which is in configdb.lrp. If you call apkg -u it will detect the changed file and it will offer you to either Keep your version, Show differences, Edit a merge file or to go with the new version. I've checked that it even works, if you replace the original package with the new version on /mnt. Pls test. So what upgrade can do is to copy the package to /mnt and run apkg -u afterwards from /mnt. If there are changes, the user can decide how to proceed. There has been introduced a safety feature, that every upgrade needs a response (y/n) , even it doesn't touch any config etc..., but if changes in the config are detected, you'll be offered with the menu to deal with the changes. > Is there a description how apkg -u is to be used? Only the source code... kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Serge Caron wrote:
Glad to be of service!
I am confused ;
[1] Shouldn't your sed process:
sed -e /^etc/d -e /^[/]etc/d -e /^[.][/]etc/d \
${pkg} ${pkg}.light
actually be this?
sed -n /^[./]*etc/p ${pkg} ${pkg}.light
I am only concerned with deleting lines that start with etc..., /etc..., and
./etc... (Note that this will match a directory like /etcold but I don't
care). So the first attempt is to produce a new file list that does not have
any of those lines.
This is where I get lost. When you said:
``When I want to backup, I simply remove the write protect tab on the
floppy. I can assure you that it takes a lot of config data to fill
1.6Mb of compressed space.''
I thought that you were backing up *only* config data. How does your
sed process facilitate this quoted intent of yours?
By-the-by, this is considerably faster:
sed -e /^[./]*etc/d ${pkg} ${pkg}.light
[2] How do you account for ${pkg}.exclude.list?
${pkg}.exclude.list is a proper substring of ${pkg}.list and therefore gets
included in the for loop.
Yes, I know; but, how does including excluded data facilitate your
needs?
[3] How do you account for CONF files that do not reside under /etc?
This particular code snippet treated /etc one way and /var a completely
different way. I could integrate both by producing a different exclusion
list for the default store. I'll think about it.
Yes, or similarly . . .
[4] Where do you get `cmp'?
cmp is a busybox applet. If don't have Andersen kit at hand, there is a
rather plump busybox on the discussion.img disk that I referred to earlier
this week. O'Reilly Linux in a nutshell has proper documentation for it.
I know that it is available; but, it is *not* included in DCD -- is it
included in Oxygen? I do not argue against its usage; rather, I am
often frustrated by lack of real awk, sed and sort -- not to mention cmp
and diff ;
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] Re: [Leaf-user] Dachstein-CD available
my bad -- i needed to change cmos ; it's ok now . . . Michael D. Schleif wrote: Charles == As a deployer of several instances of LRP-CD, I am clearly interested in Dachstein-CD. However, I'm having some difficulty getting this going ; ``Searching for Boot Record from Floppy..OK SYSLINUX 1.62 . . . . . . splash screen . . . Loading root.lrp Boot failed: please change disks and press a key to continue.'' Is this a kernel issue? I'm just trying to bring up your default distribution on a PPro box that otherwise runs woody just fine. CD-ROM drive is /dev/hdb and *not* bootable -- but, I already changed syslinux.cfg. The floppy clearly boots to a point; but, fails in root.lrp. 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
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
Re: [Leaf-devel] dcd: cleanup issues ???
Michael D. Schleif wrote: [ snip ] One thing that Charles and I want to do is remove all user configurable parameters from all init scripts. To that end, I have reviewed all /var/lib/lrpkg/*.conf, based on this list of packages that I use: [ snip ] My removal recommendations are based on functionality currently included dcd v1.0.2. Also, in standard dcd v1.0.2, what program uses /etc/rpc? -- 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 . . . --- 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] RE: Bering - included libraries
On 2002.09.22_01:09:25_+, guitarlynn wrote: [1] build an updated libssl.lrp [2] compile my zebra package with libcrypto statically linked 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. I second that. libssl.lrp itself is 398007 bytes, and about 1 megabyte uncompressed. Unless there are a lot of apps you intend to install use the library, I can only see a few points on installing the whole huge package. A few points I meant here, and may be what Lynn referred to as benefits, are availability of the library in the future and sharability. -- H. D. Lee --- 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] embedded hardware
On 2002.09.24_11:34:52_+, Joey Officer wrote: I found this interesting bit of hardware (http://mail.martinapparatus.com/Redirect/www.nagasaki.com.tw/1-products/emb edded.htm) for an embedded device. I'm awaiting pricing back from the vendor. Has anyone else worked with an embedded solution, as opposed to building routers from old hardware? Sure, please search the list archive (both leaf-devel and leaf-user). It should come up with a lot of hits. Additionally you can look at: http://www.leaf-project.org/links.php?menu=2 for some embedded device links. Joey Officer Sales Operations Martin Apparatus, Inc. 800-784-6806 x11 [EMAIL PROTECTED] -- H. D. Lee --- 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] RFC: Oxygen Network Boot HOWTO
David, List, I have written a howto on booting Oxygen from network. Only with NIC and boot ROM on the router, it should boot from tftp and dhcpd. The packages also loaded by tftp. The whole process made easy with David's Oxygen scripts that have been made network boot friendly. Thanks David. http://www.leaf-project.org/devel/hdlee/oxygen/doc/netboot/network-boot-howto http://www.leaf-project.org/devel/hdlee/oxygen/doc/netboot/oxygen.cfg http://www.leaf-project.org/devel/hdlee/oxygen/doc/netboot/std.conf I hope it would of use to someone. The document is still in a very alpha stage. Comments and suggestions are welcomed. Thank you in advance. Regards, -- H. D. Lee --- 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] ML volume
On Sun, 2003-02-09 at 10:27, Vladimir I. wrote: Michael D. Schleif wrote about Re: [leaf-devel] ML volume: Add to d) leaf-general, or some such. If this is divvied up to fine, then how will the generalists lend support? I have a feeling that nobody will subscribe to it. IMHO you need to make lists for branches which have big differences from each other. I see at least two: Bering and WISP-Dist. From what I understand Bering is mostly backwards compatible with Dachstein, so maybe same mailing list can be used for both Bering Dachstein. Vladimir, If we decide to create release/branch specific lists, I will create one for each of our releases/branches. It's the only fair thing to do. -- Mike Noyes mhnoyes @ users.sourceforge.net http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] New logos
x-flowedEveryone, I just uploaded two new logos based on the tuxnet image. tuxnet-leaflogo2.png - implements a suggestion from George tuxnet-leaflogo3.png - implements a suggestion from Charles Charles, I'm sorry about the hat, but I'm still unable to remember how to 3-D rotate it. ftp://leaf.sourceforge.net/pub/leaf/logo/mhnoyes/ -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/mailman/listinfo/leaf-devel /x-flowed
[Leaf-devel] Trouble-shooting information and HowTo
Michael D. Schleif wrote: Interestingly, it violates our company policy to publish our clients' public address schemes [...] I've always thought about a script to generate all the info necessary; that part would be easy. What about a script to sanitize information for posts such as these, and still provide most/all information? Would this be of use to all of you? ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] How to gzip *only* a new application's files ???
Matt Schalit wrote: And remember, mds, there's: make -n install to output the commands but not execute them. Cool! I didn't know that one . . . -- 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] Replacement mail command
BTW, do you have a replacement script for the POSIXness.mail mail command? And which smtp _output_only_ is preferred out there? IIRC, David D. has some tiny SMTP mailers as part of Oxygen. I think there are maybe some messages from him about this in the list archives, or maybe he'll chip in again with some info... 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] (forw) [ccarr@franzdoodle.com: porting scripts from ifconfig and awk to iproute and sed]
On 3/24/02 at 2:15 PM, Chad Carr [EMAIL PROTECTED] wrote: I am attempting to port freeswan scripts that use ifconfig and awk to use iproute and sed instead. I am posting these modifications to get input on better ways of doing things, since I do believe that there are probably at least 40-50 better ways to do it than I have come up with. So far: # get the physical device that leads to the default gateway # becomes this without netstat or awk ip route | sed -e '/^default/!d' -e 's/^.* ([^ ]*) $/\1/' ip route | sed -n '/^default/s/^.* ([^ ]*).*$/\1/p' and: # set up some vars pertaining to $phys # becomes (something like) this without ifconfig or awk eval `ip addr show dev $phys | sed -e '/^ *inet/!d' -e 's/^ *inet \(.*\)\/\(.*\) \(.*\) \(.*\) \(.*\) \(.*\) \(.*\)/addr=\1;mask=\2;type=\3;otheraddr=\4;/'` # of course, the type and mask are not the right format eval $(ip addr show dev $phys | sed -n ' /^ *inet/s/^ *inet \(.*\) \(.*\) \(.*\) \(.*\)/addr=\1 mask=\2 type=\3 other=\4/p') Please let me know if this way of doing things is completely braindead or not. Not brain dead at all. Some notes: 1. With the eval, you need to have no ; (semicolons) in the string or it will come out acting like a separator (with an error of mask=X: not found 2. sed doesn't generally need -e options today. 3. The sequence: sed '/foo/!d; s//z/' ...is equivalent to... sed -n '/foo/s//z/p' ...this might be faster; seems clearer to me (and possibly to other sed users). 4. GNU sed allows multiple commands: sed '/foo/!d; s/xxx/zzz/' ...works fine (note ;) -- returns work too. Coming from a perl background, I am not afraid of a regex or two, even complicated ones. I just am so unfamiliar with sed, I don't even have any frame of reference. Thanks in advance for your assistance. --- Chad Carr [EMAIL PROTECTED] --- -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ 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] df with post 2.4.18 kernels
Jacques Nilo wrote: Any fix/patch planned for df wich could work for all types of 2.4 kernels ? # rm /bin/df # cat /bin/df EOF #!/bin/sh /bin/busybox df | sed /^rootfs/d EOF # chmod 755 /bin/df ...or just patch the busybox source. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Dachstein-CD - Bering ???
I have noticed in recent months that Charles is migrating from DCD to Bering, and that migration has entailed some sleight-of-hand over straight Bering. Charles, have you published your DCD-Bering ``distribution''? What do you think? -- Best Regards, mds mds resource 877.596.8237 - 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 . . . -- signature.asc Description: Digital signature
[leaf-devel] Bering-uClibc: qmail ???
I am very surprised that I cannot find qmail for Bering-uClibc. What am I missing? Can somebody, please, make a Bering-uClibc qmail.lrp ??? TIA -- Best Regards, mds mds resource 877.596.8237 - 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 . . . -- signature.asc Description: Digital signature
[leaf-devel] SonicWALL
Everyone, This is interesting: Dell announces intent to acquire SonicWALL. http://content.dell.com/us/en/corp/d/secure/acq-sonicwall.aspx /SonicWALL/ http://www.sonicwall.com/ -- Mike Noyes http://sourceforge.net/users/mhnoyes https://profiles.google.com/mhnoyes -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] dachstein rc1 cd won't boot.
Hi, i am sending this only to the list, so you want get it twice... On Fri, Oct 12, 2001 at 10:13:04AM -0500, Charles Steinkuehler wrote: CS For some reason, the system is not automatically detecting your CD-Rom on /dev/hdd. I'll try to re-create this here and fix the init-scripts (if they're broken), but in the meantime, you can probably get going with the following procedure: Start with a blank floppy, or the bootdisk.bin image if your system won't boot from CD with a floppy disk in the drive. Create a file called pkgpath.cfg on the blank floppy. edit pkgpath.cfg, so it contains a single line with the text: /dev/hdd:iso9660 NOTE: This file may need a unix EOL...I'm not sure what will happen if the init script sees a carrige return as well as a line-feed...another thing to test :) well as i do not have any non UNIX System here around (except for testing ipsec clients), no Problem ;-) Yes and this works! (with the pkgpath.cfg). i just had a look and a i like the idea of putting this on CD (We are selling our systems with an IDE Flashdisk, though). But, i would like to see the config scripts be seperate from the configs itself, thats one difference to the release i made for myself. The other is of course Kernel 2.4... But i like the new lrcfg interface it looks nice. But please change the description there: b pgkg) Backup d pgkg) Set Backup Destination and so on, i tried multiple time to insert: d root ... pkgnum or something like that would be nicer... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ------ Arne Bernin Netropol Digitale Systeme Lagerstrasse 30a Tel: +49 404325 D-20357 Hamburg/Germany Fax: +49 4028416740 [EMAIL PROTECTED] --- ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Hello Michael,
Glad to be of service!
I am confused ;
[1] Shouldn't your sed process:
sed -e /^etc/d -e /^[/]etc/d -e /^[.][/]etc/d \
${pkg} ${pkg}.light
actually be this?
sed -n /^[./]*etc/p ${pkg} ${pkg}.light
I am only concerned with deleting lines that start with etc..., /etc..., and
./etc... (Note that this will match a directory like /etcold but I don't
care). So the first attempt is to produce a new file list that does not have
any of those lines.
[2] How do you account for ${pkg}.exclude.list?
${pkg}.exclude.list is a proper substring of ${pkg}.list and therefore gets
included in the for loop.
[3] How do you account for CONF files that do not reside under /etc?
This particular code snippet treated /etc one way and /var a completely
different way. I could integrate both by producing a different exclusion
list for the default store. I'll think about it.
[4] Where do you get `cmp'?
cmp is a busybox applet. If don't have Andersen kit at hand, there is a
rather plump busybox on the discussion.img disk that I referred to earlier
this week. O'Reilly Linux in a nutshell has proper documentation for it.
Regards,
Serge Caron
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Linux Virtual Server using LEAF Bering RFC
On 2002.09.17_19:27:06_+, Brad Fritz wrote: On Wed, 18 Sep 2002 06:55:56 +0700 H. D. Lee wrote: Great. May be this will be a good reason to incorporate IP_VS into Bering or Dachstein kernel. Even if it's not included, the build-from-source approach being discussed should make it easy for interested parties to roll their own kernel and modules. Yes, you are right. If it's not included, I will roll my own kernel and modules, and make it available. It means people who want LVS have to change the kernel and add the supported modules. IMHO, it would be convenient to have to add ip_vs related modules to turn the features on, just like other modules. Sure it would help. I would like to have such a script to automate the work. So far I have been doing it manually. The kernel should help me examine different result of patches version for testing. Thanks Brad. Posted to http://fritzfam.com/brad/leaftmp/make_bering_ivs_kernel temporarily. As time allows, I am going to re-write it using GAR or David's ports-like system (or both). Once I do, I will check it into cvs.sf.net under leaf/devel/bradfritz . Thank you. --Brad -- H. D. Lee --- 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: Bering - included libraries
On 2002.09.21_21:17:51_+, Eric B Kiser wrote: Hi Eric, Hi Eric, You must mean inside that really obvious directory named /lib. Urgh, it is now probably a moot point to mention that I am a newbie. Your patience is appreciated. Yes, the /lib directory contains libraries. Some libs are in /usr/lib. Here is where I am now. I execute the command #zebra -d to start the zebra process running as a daemon and I get the following message back. zebra: error in loading shared libraries libcrypto.so.2: cannot open shared object file: No such file or directory libcrypto and libcrypt are totally different things. libcrypt is from glibc, while libcrypto is installed from OpenSSL. libssl.lrp which includes libcrypto is available here: http://leaf-project.org/devel/ddouthitt/packages/libssl.lrp When installed, the files will be in /usr/lib. Here is specifically what I am running. Bering_1.0-rc3 UML kernel 2.4.18-21 zebra 0.92 packaged by David Douthitt also zebra 0.91a packaged by Andrew Hoying Is libcrypto.so.2 part of libcrypt-2.0.7.so or libcrypt.so.1 or is it something completely different? See my answer above. Thanks for any help that you can offer. You're welcome. Eric [Kiser] -- H. D. Lee --- 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] ML volume
Mike Noyes wrote: On Sun, 2003-02-09 at 09:45, Mike Noyes wrote: Everyone, It has come to my attention that our leaf-user list volume is discouraging some/many users from using it. We have a variety of options to address this issue. a) Keep things as they are. b) NNTP support (news.gmane.org and/or nntp.sourceforge.net) c) Web support (SF forums for each LEAF release/branch) (note: we already use SF support trackers) d) New LEAF release/branch specific MLs. leaf-bering leaf-dachstein leaf-lince leaf-oxygen leaf-packetfilter leaf-wisp-dist Add to d) leaf-general, or some such. If this is divvied up to fine, then how will the generalists lend support? e) Split leaf-user by adding leaf-user-new -- 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 . . . --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
On Sun, 2003-02-09 at 10:19, Michael D. Schleif wrote: Mike Noyes wrote: On Sun, 2003-02-09 at 09:45, Mike Noyes wrote: d) New LEAF release/branch specific MLs. leaf-bering leaf-dachstein leaf-lince leaf-oxygen leaf-packetfilter leaf-wisp-dist Add to d) leaf-general, or some such. Michael, Please explain how a general/discuss list would reduce traffic on leaf-user. If this is divvied up to fine, then how will the generalists lend support? Agreed. I have a couple of additional problems with the release/branch split above. It almost doubles my ML admin load. Second, once a list is created on SF it can't be removed or renamed. If we had used the release/branch solution from day one we would have two dead lists currently (leaf-eigerstein, leaf-wrp). e) Split leaf-user by adding leaf-user-new I'm not sure how much of a traffic reduction would be achieved by splitting new user questions to a new ML. -- Mike Noyes mhnoyes @ users.sourceforge.net http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ReiserFS (forward by port)
On Thu, 15 Nov 2001, Charles Steinkuehler wrote: In other news, I'm just about to give up with my year-long attempt to get forward-by-port with multiple Internet pipes working. It's turning out to be a serious PITA to handle when MASQ'ing is involved, and when I've gotten it to work (partially) it's been too complicated to document in a nice and easy HOWTO. ??? Can you explain a bit more about exactly what you're trying to do? Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) Situation: (1) Sprint broadband wireless w/fixed IP. (1) mom-n-pop ISP w/fixed IP, Tsoft. (2) ES2B systems, one for each circuit. (1) small NAT'd LAN. Tsoft lets me have a reverse DNS statement, so that's where I want mail to go, but Tsoft is also just a dedicated 56K modem until DSL is available next year -- so I don't want any web services going that way. I serve mail, DNS, web, and the occasional IRC from here, using two machines. Goal: One router handles both connections. Outbound mail and DNS use the Tsoft modem route, outbound web service and client activities use the Sprint wireless route. Problem 1: The servers are also workstations, so it would be a big pain to make one of them use the modem line as its default gateway. For the same reason, I can't route by source IP. Problem 2: Mail, DNS, and web are being served to the entire Internet, so I can't route based on destination IP. Problem 3: Mail really needs to go out of the tsoft line in order to take advantage of the RDNS assignment there. So I've gotten it to route _inbound_ from either pipe or both at the same time; but the return traffic of course always follows the default route. Setting up forward by port seems to work, but doesn't do anything. Here's what I've done: edit /etc/iproute2/rt_tables and add a table for each of your two external ISPs: 100 isp-a 101 isp-b now create the fwmark rules which will tag each matched packet with a number: ip rule add fwmark 100 table isp-a ip rule add fwmark 101 table isp-b now add the rules to do the tagging (look in /etc/ipfilter.conf for examples). Here are some rules I wrote: ipchains -A output -p tcp -d 0/0 6667 --mark 100 ipchains -A output -p tcp -d 0/0 25 --mark 100 ipchains -A output -p tcp -d 0/0 53 --mark 100 ipchains -A output -p udp -d 0/0 53 --mark 100 ipchains -A output -p tcp -d 0/0 80 --mark 101 finally, add the routes which will handle the tagged packets: ip route add default via 1.2.3.4 dev eth1 table isp-a ip route add default via 5.6.7.8 dev ppp0 table isp-b Now, I'm currently thinking that the output chain must be the wrong place to put things, because the weblet status page has an area named fwmark, which remains empty. I'm thinking such a thing exists because someone more knowledgeable thought it oughta be there. Any ideas? -- Jack Coates Monkeynoodle: A Scientific Venture... ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] 5.x0-alpha considerations- solved issue
Am 25.09.2012 19:18, schrieb KP Kirchdoerfer: But I tried to run buildall.sh with the toolchain set to Toolchain = armv5te-unknown-linux-uclibcgnueabi.mk There is an typo above, which caused the error below. It has to be: Toolchain = armv5te-unknown-linux-uclibcgnueabi to work as expected. kp as a test for the work to support other architectures. Unfortunately it fails while building the kernel sources with the error message: xzcat patch-3.2.29.xz | patch -p1 -s -d /opt/buildtool-master/source/armv5te-unknown-linux-uclibcgnueabi.mk/linux/linux-3.2 ln -s /opt/buildtool-master/source/armv5te-unknown-linux-uclibcgnueabi.mk/linux/linux-3.2 linux cat bitreverse.patch | patch -d /opt/buildtool-master/source/armv5te-unknown-linux-uclibcgnueabi.mk/linux/linux-3.2/lib -p0 patching file Kconfig Hunk #1 succeeded at 11 with fuzz 1 (offset 3 lines). cat kernel-mkmakefile.patch | patch -d /opt/buildtool-master/source/armv5te-unknown-linux-uclibcgnueabi.mk/linux/linux-3.2 -p1 patching file Makefile Hunk #1 succeeded at 423 with fuzz 1 (offset 23 lines). patching file scripts/mkmakefile cat 620-sched_esfq.patch | patch -d /opt/buildtool-master/source/armv5te-unknown-linux-uclibcgnueabi.mk/linux/linux-3.2 -p1 patching file include/linux/pkt_sched.h patching file net/sched/Kconfig patching file net/sched/Makefile patching file net/sched/sch_esfq.c cat 621-sched_act_connmark.patch | patch -d /opt/buildtool-master/source/armv5te-unknown-linux-uclibcgnueabi.mk/linux/linux-3.2 -p1 patching file net/sched/act_connmark.c patching file net/sched/Kconfig patching file net/sched/Makefile mkdir -p /opt/buildtool-master/toolchain/armv5te-unknown-linux-uclibcgnueabi.mk/usr touch .source (for i in ; do \ patch -i Bering-3.2.29.config-$i.patch -o Bering-3.2.29.config-$i Bering-3.2.29.config \ mkdir -p linux-$i cp Bering-3.2.29.config-$i linux-$i/.config \ ARCH= make -C /opt/buildtool-master/source/armv5te-unknown-linux-uclibcgnueabi.mk/linux/linux-3.2 O=../linux-$i oldconfig || \ exit 1; done ; \ ARCH= make -C linux-$i include/linux/version.h headers_install \ cp -r linux-$i/usr/include /opt/buildtool-master/toolchain/armv5te-unknown-linux-uclibcgnueabi.mk/usr) make: Entering an unknown directory make: *** linux-: No such file or directory. Stop. make: Leaving an unknown directory -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Hello again,
This is where I get lost. When you said:
``When I want to backup, I simply remove the write protect tab on the
floppy. I can assure you that it takes a lot of config data to fill
1.6Mb of compressed space.''
I thought that you were backing up *only* config data. How does your
sed process facilitate this quoted intent of yours?
Actually, the process is more like *I don't backup program binaries* :-).
Because of the subset of programs I work with, taking care of /etc and
/var - /var/log - /var/adm - /var/lib/lrpkg - /var/run - /var/lock -
/var/spool -/var/tmp } gives me what I want. YMMV :)
By-the-by, this is considerably faster:
sed -e /^[./]*etc/d ${pkg} ${pkg}.light
Linux people are usually more intelligent than I am. Your sed mask allows
for stuff like ...etc and ../../../etc and all kinds of ganes that I prefer
not to play :). Following your intervention, the original sed command now
reads
sed -e /^etc[[:space:]]*$/d -e /^[/]etc[[:space:]]*$/d \
-e /^[.][/]etc[[:space:]]*$/d \
-e /^etc[/]/d -e /^[/]etc[/]/d -e /^[.][/]etc[/]/d \
${pkg} ${pkg}.light
This is part of a startup script that runs a few times a year. I am more
concerned with exactness than speed of execution. Your method is
_definitely_ faster but does not gives me exactly what I want.
[2] How do you account for ${pkg}.exclude.list?
${pkg}.exclude.list is a proper substring of ${pkg}.list and therefore
gets
included in the for loop.
Yes, I know; but, how does including excluded data facilitate your
needs?
Sorry for taking your question litterally :). I will presume that you
understand that the set of files destined for the default store is the set
of all files on the machine minus the set of all the files enumerated in
each of all other packages and minus the set of files excluded for the
default store.
Suppose the default store is named gizmo and some other package exclude
/etc/thisthat. The backup code in LRP, Dachstein, Oxygen, etc concatenate
all the file lists for all packages other than gizmo in a single exclusion
list. Therefore, if something is excluded from one package, it is also
excluded from all other packages.
When I want a snapshot of my machines, I want _everything_ in etc. Life is
like that :-)
[3] How do you account for CONF files that do not reside under /etc?
This particular code snippet treated /etc one way and /var a completely
different way. I could integrate both by producing a different exclusion
list for the default store. I'll think about it.
Yes, or similarly . . .
Like I said above, I do not handle /var the same way as I handle etc. The
programs I use store their data in /etc or /var or both. It can be extended
to anything else. Eventually, the need to run write-protected will change.
However, this solution works today.
[4] Where do you get `cmp'?
[snip]
I know that it is available; but, it is *not* included in DCD -- is it
included in Oxygen? I do not argue against its usage; rather, I am
often frustrated by lack of real awk, sed and sort -- not to mention cmp
and diff ;
Gee, I really had a push-button mind when I answered you. Michael, bear with
me for a few more seconds.
For one of his shows, Ed Sullivan had invited a lion tamer who usually put
his entire head in the lion's mouth at the end of his act. It was explained
to him, in writing, that the act took 10 minutes. By showtime, due to
overbooking and delays, Sullivan tells the lion tamer that once the curtain
rises, he has two minutes for his act. OK, says the lion tamer, but YOU
explain it to the lion. :-)
Now, to answer your question: you are looking for a baseline specification
:-). David Douthitt is *RIGHT* when he says that there should not be a
baseline specification, either explicitly specified for LEAF or indirectly
specified by refering to a distribution. We are dealing with unspecidied
hardware constraint, some of which are not obvious as in the case of the
write-protect switch. As a case in point, Bering does not have netstat, a
fixture in this environment since the early LRP days. In the confined space
of a floppy, Jacques Nilo decided something that made sense for his project
and he can revisit his decision at any time. In the meanwhile, you have
Bering to play with.
The difficulty here is formalizing your ability to repackage your baseline
and go on with your life (or your LEAF :). I think we can overcome this
difficulty but I will wait for your comments on the process.
Regards,
Serge Caron
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Poll: Ladybug Architecture
Background, for those who haven't downloaded it yet: Ladybug is based loosely on Oxygen, and the conversion from Oxygen to Ladybug has proceeded with these tenets in mind: 1) The "idiot image" main system should be dirt simple. a) two .lrp's, root and etc. b) "the minimum" of system configuration files. In my dreams, that's two files: linuxrc and ladybug.conf. c) any package related configuration is going to go here, so the disk needs to have as much spare room as possible. d) Full support for packages isn't necessary. They need to be unpacked and backed up, and that's all. 2) Support for server hardware should be easy. a) RAID, SCSI, and so forth modules need to be available, along with all the config tools. b) a CD-ROM with all the support goodies and server packages needs to be available, or else you're looking at 30 floppies :-) c) a local harddisk is assumed, which the /var directory will be written to. c1) persistence of /var means lrpkg/ needs to move elsewhere. 3) Security should be as good as possible. a) only serial and ssh access are supported. b) out of the box bastion - it comes up safe. c) only local media supported for package load. d) packages updated and kernel patched. Some of these ideas are no brainers, but others are tougher and I'd like to ask for some help. 1-b) This is somewhat hard to do, given the progression from Debian through a few versions of LRP to Oxygen. However, the work is 90% done in the files that are up on my page. My question is, am I violating The Unix Way(TM) by going this direction? Would tons of little config files tied together with lrcfg menu be better? 2-b) If I'm assuming a CD-ROM and a box with lots of RAM, why not get away from the glibc issue and use a newer Linux as my base? Pros and cons? 3-d) Easier said than done. Any ideas or feedback? -- Jack Coates Monkeynoodle: It's what's for dinner! ___ Leaf-devel mailing list [EMAIL PROTECTED] http://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] RE: Bering - included libraries
Hi Michael, I am using David's zebra.lrp package and trying to get it to run on Bering_1.0-rc3. I wanted to check out what he did before I got started on mine. I will, however, be using UML_slink to do my compiling. You bring up an interesting question regarding ssh having the libraries statically linked. I expect to have both ssh and zebra running on the same system. Would it be better to use the libssl as suggested by H. D. Lee. That is, assuming that there is an ssh.lrp without libcrypto statically linked. Strictly for the purpose of conserving space. Along this same line of thought, does anyone know whether it would cause problems to use ssh.lrp with the statically linked libcrypto on the same system as using libssl.lrp. I am in unfamiliar terrain here so any help is appreciated. Many thanks to both of you, Eric [Kiser] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael D. Schleif Sent: Saturday, September 21, 2002 9:49 PM Cc: [EMAIL PROTECTED] Subject: Re: [leaf-devel] RE: Bering - included libraries Eric B Kiser wrote: You must mean inside that really obvious directory named /lib. Urgh, it is now probably a moot point to mention that I am a newbie. Your patience is appreciated. Here is where I am now. I execute the command #zebra -d to start the zebra process running as a daemon and I get the following message back. zebra: error in loading shared libraries libcrypto.so.2: cannot open shared object file: No such file or directory snip / There is a very real difference between these two (2) libraries: libcrypt libcrypto The latter is part and parcel of openssl; perhaps, also some other libraries. How are you compiling zebra? On what describe system? With what libraries? You probably need to do what we have done for openssh, which is to statically link libcrypto during openssh compile . . . -- 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 . . . --- 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 --- 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] apkg - lots of enhacements
Last week was hectic for me and I finally got around to not just making the
changes, but testing them too. I didn't know 'upgrade()' existed and now that
I've messed with it, I really like it. Instead of just being compatible with
the new package_changed_files(), any changes that are made are now committed at
the very end. So... you can modify files, one after another, and if you make a
mistake, just answer no at the end. I also updated expandpath() mainly because
of $PKGROOT always being///, or was it ? Boy I hated that. You still end up
with //some.file because that's just what happens when the top dir is a slash;
which could be changed (eg., $PKGROOT$afile, ${PKGROOT}literal.file), but,
that's being too pickyI would like to get this committed soon. If anyone
wants to test, please give it a try. Just make sure your busybox has 'readlink'.
--- apkg.orig2014-09-18 23:20:09.0 -0700
+++ apkg2014-10-24 13:38:52.851202831 -0700
@@ -6,20 +6,38 @@
# Upgrade code by Cedric Schieli
# Rundiff code and various improvements by Paul Traina
# Package dependency loading code by David M Brooke
-#
+# Package_changed_files() now backs up symbolic links and
+# empty directories; more detailed rundiff(); upgrade() now
+# prompts before committing changes and other enhancements;
+# changed expandpath by Jorge Contreras
+#
# Licensed under the terms of the GPL-2
# -
-# expandpath - given a path, expand it
-# code from apkg by David Douthitt
-expandpath () {
-local D=$(dirname $1)
-if `echo $D | grep -v ^/ /dev/null`; then
-[ `dirname $1` = . ] D=$PWD || D=$PWD/$(dirname $1)
+# expandpath - given a path, expand it; does not expect a valid path;
+# if available `readlink -m /some/path` is best, but that will canonicalize
+# symlinks, which is not always desired. Now get's rid of redundant slashes
+# (eg., ///dir1/dir2) and accepts null paths.
+# code from apkg by David Douthitt - Modified by Jorge Contreras
+expandpath() {
+
+if [ $1 = ] || [ $1 = . ]; then
+echo $PWD
+elif [ $1 = / ]; then
+echo /
+else
+local DN=$(dirname $1 | sed 's#//*#/#g')
+if $(echo $1 | grep -v ^/ /dev/null); then
+[ $DN = . ] \
+echo $PWD/$(basename $1) || \
+echo $PWD/$DN/$(basename $1)
+else
+echo $DN/$(basename $1)
fi
- echo $D/$(basename $1)
-}
+fi
+
+}
# -
@@ -200,24 +218,46 @@
# figure out which files have changed from this package
package_changed_files () {
-local tmp
+local tmp upgrade fullpkg NL tmpdir mktmpd s_syms s_dirs s_files
tmp=$TMP/$SESSIONID.sha1
+tmpdir=$TMP/$SESSIONID.tar
+# Hackish way of dealing with upgrades and symlinks
+if [ $1 = -u ]; then
+upgrade=1; fullpkg=$2; SHIFT 2
+fi
(
cd $PKGROOT
echo $tmp
-
+NL=
+
for pkg in $@ ; do
-if [ -f $PKGDIR/$pkg.local ]; then
-for a in $(find $(cat $PKGDIR/$pkg.local) -type f 2/dev/null); do
-! grep -h [ /]${a}\$ $PKGDIR/*.sha1 $tmp 2/dev/null \
-echo ${a} $tmp
-done
-fi
+if [ -f $PKGDIR/$pkg.local ] ; then
+for a in $(find $(cat $PKGDIR/$pkg.local) 2/dev/null); do
+if [ -L $a ] ; then
+[ $mktmpd != 1 ] mkdir $tmpdir mktmpd=1
+[ $upgrade != 1 ] fullpkg=$STORAGE_MEDIA/$pkg.lrp
+# if symlink doesn't exist or if it changed
+if ! tar xzf $fullpkg -C $tmpdir $a 2/dev/null || \
+[ $(readlink $a) != $(readlink $tmpdir/$a) ] ; then
+s_syms=$s_syms$a$NL
+fi
+elif [ -d $a ] ; then
+# Only add empty directories, non-empty dirs are always
backed up
+if ! [ $(ls -A $a) ] ; then
+s_dirs=$s_dirs$a$NL
+fi
+elif [ -f $a ] ; then
+! grep -h [ /]${a}\$ $PKGDIR/*.sha1 $tmp 2/dev/null
\
+echo ${a}
$tmp
+fi
+done
+[ $mktmpd = 1 ] rm -rf $tmpdir mktmpd=0
+fi
done
-
-sha1sum -c $tmp 2/dev/null | grep FAILED | sed -e s/: FAILED// | \
-sort | uniq
+
+s_files=$(sha1sum -c $tmp 2/dev/null | grep FAILED | sed -e s/:
FAILED//)
+echo $s_syms$s_dirs$s_files | sort | uniq
)
rm -f $tmp
@@ -225,13 +265,23 @@
}
# -
+# upg_cmdins - inserts a command into the upgrade script
+
+upg_cmdins() {
+
+if [ -n $1 ]; then
+echo $@ [ \$? -ne 0 ] upgexit
Re: [Leaf-devel] New logos
Hello Everyone, I just uploaded two new logos based on the tuxnet image. tuxnet-leaflogo2.png - implements a suggestion from George tuxnet-leaflogo3.png - implements a suggestion from Charles Charles, I'm sorry about the hat, but I'm still unable to remember how to 3-D rotate it. I played a little bit with the hat, i think i turned it in the right direction but the result is kind of funny ( hat too small, looks like a new years eve party :)) I don't promote it as logo but wanted to show it still :) ftp://leaf.sourceforge.net/pub/leaf/logo/ericw/tuxnet-leaf3b.png Eric Wolzak ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/mailman/listinfo/leaf-devel
Re: [Leaf-devel] grep options
"Scott C. Best" wrote: [...] what would be the equiv of, say: "grep -v -i FOO /etc/passwd" ? sed '/[Ff][Oo][Oo]/d' /etc/passwd Pi said: grep -v didn't even work in the old LRP2.9.8 release. Always had to hack around it by using sed -e "s/foo//" instead of grep -v "foo". Busybox 0.50 supports the following grep options: Hhinqvs So grep -iv works just fine... LRP may not have updated its busybox in some time; Oxygen uses the most current (now at 0.51pre) ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Where IS everybody?
Hello all, active on the list again :) On Tue, 6 Feb 2001, Arne Bernin wrote: I live in Hamburg,Germany, and we have 5ºC and its raining, the typical Weather for a winter in Hamburg (or the summer ...) --arne --- Arne Bernin Netropol Digitale Systeme Lagerstrasse 30a Tel: +49 404325 D-20357 Hamburg/Germany Fax: +49 4028416740 [EMAIL PROTECTED] I live in Korbach, a small city in the center of Germany, about 140 Miles north of Frankfurt. Eric Wolzak ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Shorewall 1.1.9 Released
a) The tunnels file is now in the RPM (really!) b) SNAT can now be applied to port-forwarded connections. c) A bug which would cause fireall start failures in some DHCP configurations has been fixed. d) The firewall script now issues a message if you have the name of an interface in the second column of an entry in /etc/shorewall/masq and the named interface is not up. e) You can now configure Shorewall so that it does not require kernel NAT and/or mangle netfilter support. f) Thanks to Alex Polishchuk, the hits command from seawall is now in shorewall. g) Support for IPIP tunnels has been added. -Tom -- Tom Eastep \ [EMAIL PROTECTED] ICQ #60745924\ http://seattlefirewall.dyndns.org Shoreline, Washington \__ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] [ leaf-Support Requests-435599 ] Help with mail command
David Douthitt, 2001-06-25 10:51 -0500 [EMAIL PROTECTED] wrote: Support Requests item #435599, was opened at 2001-06-22 15:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=213751aid=435599group_i d=13751 This URL doesn't seem to be responding. Anybody know anything of this? David, It looks like SF is trying to fix their dbase problem from Saturday. I'll update everyone when things stabilize. I apologize for any inconvenience this outage may cause you. -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: [Leaf-user] Openssh 2.9.9p2 available -- Dachstein-CD ???
Jacques Nilo wrote: I have updated openssh packages to their latest 2.9.9p2 version. They are compiled statically against openssl-0.9.6b and dynamically against zlib-1.1.3 See: http://leaf.sourceforge.net/devel/jnilo Excellent! Charles, is this that version that you are adding to Dachstein-CD ??? -- 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] Re: [Leaf-user] Announcing Dachstein CD RC5
Charles Steinkuehler wrote: [ snip ] Rebuilt log.tgz (part of ramlog.lrp) using busybox tar in hopes of eliminating broken pipe messages appering on some systems. Did I tell you that that fixes the problem? Of course, in my modified instance, it took me quite sometime to figure out how to un-archive, modify and re-archive in the same manner. Thank you . . . -- 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] [dachstein] lrp.conf/multicron Spacecheck problem
KP Kirchdörfer wrote: Am Sonntag, 20. Januar 2002 03:18 schrieb Michael D. Schleif: KP Kirchdörfer wrote: Am Donnerstag, 17. Januar 2002 04:15 schrieb Michael D. Schleif: I'll probably try to get the script to check *ALL* currently mounted, writable file-systems...maybe with an exclude variable in lrp.conf. If this doesn't work, I can fallback to the Enhanced solution, above. /etc/lrp.conf has a variable: lrp_SPACECHECK=YES/NO -- if YES, then -- and, only then -- /etc/cron.daily/multicron-d and its links can run checkfreespace(), which calls updatefree(), c. There is also mailadmin(), so if /var/something is on the list and checked, it will send a mail to mailadmin. Suppose, updatefree() returns a value for which ckfree() returns 0, then -- and, only then -- cleanlevel() runs and prunes applicable files that match the filter: $lrp_SC_DEL_L$cklevel But, *what* files can these be? In /etc/lrp.conf -- by default -- we see exclusively this: 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 Notice, *ALL* of these files -- by default -- reside in /var/log !!! Since *only* files under /var/log can be pruned -- by default -- then, why not modify updatefree() to say this: set -- $(df /var/log | sed -n 2p) lrp_SC_DEL_Lx could be enhanced to delete other /var/* as well. updatefree() isn't the place to determine the dir's, that's what I think. Agreed, this is not the ultimate solution. However, it does completely address DCD defaults! Nevertheless, `df /path/to/dir' *always* returns _only_ that information particular to that filesystem on which /path/to/dir resides; therefore, it would be a simple matter to test any variety of applicable dir/filesystem combinations. The truly hard part is, what to do with the information returned? Email somebody is straightforward; but, the complexities in deciding which files to purge becomes exceedingly complex !?!? Besides logfiles, what else on DCD can grow out-of-hand? On a common DCD I don't know. On my own /var/logs and /var/cache for squid. It's easy to decide that a cache can be flushed. Yes, of course, in and of itself, it is easy to decide whether or not to purge files in /var/cache. It is also easy enough to put several df's in a loop in order to analyze several filesystems. However, it is not as easy, once a filesystem is found that requires purging, for the dumb shell script to decide *which* files to purge ; 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. Enough said . . . -- 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] [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
Re: [Leaf-devel] DFE-570TX ?
Does anyone have any experience using a D-Link DFE-570TX 4-Port NIC under Linux? From what I've been able to piece together is that the standard tulip module should work for it since its using 4 x DEC DC21143 chips. These cards work great! I have several running and have had absolutely no problems with them. They run standard DEC 21143 chips, as you mention, behind a DEC PCI-PCI bridge. Simply load the tulip driver, and presto four ethernet ports! 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
[Leaf-devel] bering beta3 and typo in interfaces file
Hello Jacques, I just found out why my third network card didn't get set. It's a typo in the examples of the interfaces file. For Step 3 and step 4 the word adress is written with one d while it should be 2. # Step 3 (optionnal): configure DMZ # Default: eth2 / fixed IP = 192.168.1.100 #auto eth2 #iface eth2 inet static #adress 192.168.1.100 #network 192.168.1.0 #netmask 255.255.255.0 #broadcast 192.168.1.255 # Step 4 (optionnal): configure bridge #auto br0 #iface br0 inet static #adress 192.168.1.254 #network 192.168.1.0 #netmask 255.255.255.0 #broadcast 192.168.1.255 #gateway 192.168.1.1 #bridge_ports all ICQ# 37047796 [EMAIL PROTECTED] (Work) [EMAIL PROTECTED] (Home)
[Leaf-devel] Preferred package/filesystem location ???
Is there some kind of standard whereby, when building a new LEAF package, we know *where* particular files belong? From my brief experience, it appears that most LRP packages are built with non-default file locations. For example (not to pick on you, Andrew ;), netsnmpd.lrp puts configuration files under: /etc/snmp/ whereas the configure defaults are to put everything under: /usr/local/ If there isn't a standard, there *SHOULD BE* -- no? 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] How to gzip *only* a new application's files ???
Surely, all of you experienced LRP'ers have tackled this one! OK, I build a new application on a slink development box. Once I do `make install', how do I know an exhaustive list of *ALL* files to turn into the LRP file? 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] New dachstein 1.0.2 CD with glibc 2.1.3
Today I've put up a new build of dachstein 1.0.2 CD with glibc 2.1.3 onto sourceforge: leaf.sourceforge.net/devel/kapeka/lrp-packages I fixed one or two minor bugs, repackaged ipmail.lrp, updated to latest openssh version from Jacques Nilo, updated ez-ipupdate and replaced login, adduser etc. with tinylogin 1.0. Michael D. Schleif sent me a copy of his new net-snmp package, which he runs successfully on five routers. The previous net-snmp.lrp's has been replaced. AFAIK original dachstein 1.0.2 configurations should work without changes. regards kp ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/13/02 at 8:16 PM, Serge Caron [EMAIL PROTECTED] wrote:
By formulating the concept of a default store and that of
an exclusion list, here is _what_I_do_today_ : I boot from
a CD which gives me all the storage I need for the job at
hand. I define my default store to be on the _floppy_. So
far, so good? Then I have this code snippet as part of the
boot sequence:
Yeah! CODE! :)
for pkg in /var/lib/lrpkg/*.list; do
sed -e /^etc/d -e /^[/]etc/d -e /^[.][/]etc/d \
${pkg} ${pkg}.light
cmp -s ${pkg} ${pkg}.light
if [ $? = 0 ]; then
rm ${pkg}.light
else
echo ${pkg}
mv ${pkg}.light ${pkg}
fi
done
How about this:
for pkg in /var/lib/lrpkg/*.list ; do
if grep -q [./]*etc ; then
sed '/[^\/]*etc/d' $pkg $pkg.2
mv $pkg.2 $pkg
echo $pkg
fi
done
Yes! Every package list that claimed anything in /etc is
rewritten! When I want to backup, I simply remove the
write protect tab on the floppy. I can assure you that it
takes a lot of config data to fill 1.6Mb of compressed
space. Further, if the floppy is lost or if something BAD
happens, the machine still boots from the CD: removing the
floppy is akin to a master reset on the memory, not the
software. The entire experience is almost identical to
running from ROM. Sharing it will only improve the
process. For example, the enclosure can CREATE on the fly
an empty package if the default store is not specified.
See the discussion.img floppy that is idling somewhere.
How's this different from Oxygen and Dachstein and how they read their
configuration data from the floppy? I can create a package which
contains nothing but configuration files, put it onto a floppy disk,
and boot the Oxygen Bootable CDROM using that configuration
And I DON'T have to rewrite all of the packages...
I understand completely. The process of changing the way
something is stored is usually referred to as a
conversion and you will provide at a later date the
conversion procedure for your RAM disk. Will you still be
supporting the old LRP patches, eg, will Oxygen 1.9+
support both the old tar.gz RAM disk and the new gz only
RAM disk?
For booting purposes the use of root.lrp is dead; however, a script to
convert root.lrp to a root.gz is practically a neccessity. The LRP
patches can't be used on any kernel newer than 2.4.5 last I heard; so
this kills the use of a *.tar.gz file for booting.
I am not certain I understand everything you wrote there,
but I understand that you would be happy to include
additional packages in your repository. I am correct?
One of the ways I felt I could help LEAF (or LRP) was to package up
everything I wanted - or everything in sight, which was about the same
thing :-)
The repository is one of two things. I've tried to make a repository
in that I've been gathering a lot of packages together, too. However,
a real Repository would be with hyperlinks, descriptions, home pages,
etc and requires a new package extension. I've not done as much
as I ought, but it mainly uses a new file /var/lib/lrpkg/pkg.desc
which contains all of the information
This information is then read by the Lua script and converted to
HTML
--
David Douthitt
UNIX Systems Administrator
HP-UX, Unixware, Linux
[EMAIL PROTECTED]
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/14/02 at 8:05 AM, Michael D. Schleif [EMAIL PROTECTED] wrote: I know that it is available; but, it is *not* included in DCD -- is it included in Oxygen? I do not argue against its usage; rather, I am often frustrated by lack of real awk, sed and sort -- not to mention cmp and diff ; As far as I know, both Oxygen and Dachstein use GNU sed; Oxygen just happens to use sed 3.0 and Dachstein something older I think. mawk.lrp is available, as is diff.lrp. I think busybox comes with sort - 0.60.2 anyway, in Oxygen... But cmp? Who needs that? -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Past Articles repository ???
Recently, I have seen several posts regarding searches for items seen in LEAF articles quite in the past. I also have found myself looking for something that I'd swear I had seen on the main ttp://leaf.sourceforge.net/ page, or in the rightmost Past Articles column. Would it be valuable to archive *all* of these articles on some other page, perhaps linked to at the bottom of the current Past Articles column? 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] Re: [BusyBox] gzip broken in 0.60.3 ?
It is broken in CVS, at least, if I do: echo XXX | ./busybox gzip | ./busybox gzip -d XXX gzip: Invalid gzip magic gzip: Invalid gzip magic gzip: Invalid gzip magic gzip: Invalid gzip magic gzip: Invalid gzip magic gzip: Invalid gzip magic gzip: Invalid gzip magic gzip: Invalid gzip magic gzip: Invalid gzip magic gzip: Invalid gzip magic gzip: Invalid gzip magic gzip: Invalid gzip magic gzip: Invalid gzip magic gzip: Invalid gzip magic gzip: Invalid gzip magic ... ad infinitum... ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ???
On Wed, 2002-07-17 at 15:50, Michael D. Schleif wrote: [2] Since cvs does not retain group, mode nor ownership attributes, [1] is further complicated and requires another kludge to correct directory and files attributes. Michael, This should only be an issue when exporting for public distribution. The recommended solution is a script to export, configure, and package your release. # Exporting For Public Distribution http://cvsbook.red-bean.com/cvsbook.html#Exporting_For_Public_Distribution -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- 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] Muzik iste
JetMp3 Türkiye'de ilk kez uygulanan bir sistemi hayata geçirdi.
http://www.jetmp3.com
Bu sistemle artýk Ýstediðiniz MP3 leri ister tek tek isterseniz albümler halinde ve
birkaç dakika içinde sanki disketten bilgisayarýnýza yükler gibi süratle
indirebilirsiniz. Turk ve Yabancý albümler, klipler ve daha fazlasý...
11gb lik arþivimize göz atmak için týklayýn: http://www.jetmp3.com
áË ë^¨¥Ë)¢{(ç[ÈmêÓ
ì(®Wl}«-zË`®
Þj[bç(k§Æì¦V~æíë- ÀnWb¶)á¶Úÿ 0¦Ûz·(ú,vñbÞi÷^½éfj)b
b²ÒÞi÷^½éeËl²«qç讧zØm¶?þX¬¶Ë(º· ~àzwþX¬¶ÏåËbú?æuëÞ
Re: [leaf-devel] ML volume
Mike Noyes wrote: a) Keep things as they are. b) NNTP support (news.gmane.org and/or nntp.sourceforge.net) c) Web support (SF forums for each LEAF release/branch) (note: we already use SF support trackers) d) New LEAF release/branch specific MLs. leaf-bering leaf-dachstein leaf-lince leaf-oxygen leaf-packetfilter leaf-wisp-dist e) Split leaf-user by adding leaf-user-new f) phpBB 2.04, http://www.phpbb.com/ This is a web based forum system. A working example group that uses phpBB is http://forums.etree.org/ Regards, Matthew --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF Platform
Also sprach Erich Titl (Tue 22 Jul 02003 at 07:29:23PM +0200): Hi everybody I am just about to port Bering to a new embedded piece of hardware, except for a few keyboard errors quite successfully. I believe this platform could be very interesting for anyone contemplating a distribution of a standardized HW platform. Here is the link. http://www.pcengines.ch/wrap.htm This is interesting. What are you using for an enclosure? Perhaps, enclosure specifications are on the website, but I didn't see them . . . -- Best Regards, mds mds resource 877.596.8237 - 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 . . . -- pgp0.pgp Description: PGP signature
Re: [leaf-devel] /linuxrc testing - round 2
Charles; I may have found another small problem: firewall# lrpkg -i squid-2.lrp Installing squid-2 ... cat: /var/lib/lrpkg//boot.fstype: No such file or directory Done. I was told: It could be a bug (from the lrpkg script): echo $fn=-t `cat $lrpkgpath/boot.fstype` $d$lrpkgpath/backdisk but boot.fstype is obsoleted with new linuxrc. Any idea how to solve? kp --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] bootstrapping signed packages
On 21 Feb 2001, at 1:31, [EMAIL PROTECTED] wrote: On Tue, Feb 20, 2001 at 05:05:52PM -0600, [EMAIL PROTECTED] scribbled: Having said that, one of the things on my list of "ToDos" is to change apkg to generate *.md5 for every file in the package for checking purposes. This would mean: Every file? That's a hell of a lot of md5suming. Would not a single md5sum of all the files suffice? It's not that bad. Most packages don't have that many files. But, why would you want to md5sum a directory? I didn't say I wanted to. Why not md5sum the concatenation of all files in the dir, or even of all the md5sums of all the files in the dir? That's the idea: generate md5sums for all files in the directory. However If your challenge is to step through the list, using each line as an argument for md5sum, I can help, with a method Charles devised when I asked for help doing something similar for mp3s... :) Actually, I've gotten something working, but I think it's sort of kludgey. Here is a more concise description of the possible input to md5sum: directory wildcard-directory file wildcard-file ...so - which one is it? This has to be massaged for md5sum... also, a directory needs to be recursed into - I don't think my current checksumming does this. Another problem is that the ENTIRE path needs to be generated; this is also problematic... Let me think; this is what I need: directory: find $(fullpath $1) ! -type d wildcard-directory: find `echo $(fullpath $1)` ! -type d file: echo $(fullpath $1) wildcard-file: echo $(fullpath $1) hmmm or something like that. Does your busybox find support -exec? No. -- David Douthitt UNIX Systems Administrator HP-UX, Linux, Unixware [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] ipchains redirect
Leaf'rs: Heyaz. Saw this on security-basics this AM. Never saw it mentioned on LRP/LEAF before; anyone ever try it? Alternatively, is IP Transparent Proxy enabled in any LEAF kernels? Seems terribly powerful to me. TIA! -Scott -- Forwarded message -- Date: Wed, 19 Sep 2001 20:19:19 +0200 (CEST) From: Bosko Radivojevic [EMAIL PROTECTED] To: Daniel Chojecki [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: ipchains, ipmasqadm On Tue, 18 Sep 2001, Daniel Chojecki wrote: Is it posible to redirect all traffic comming for 0.0/0 80 to local squid proxy using ipchains and ipmasqadm. Using ipchains - yes. I'm not sure for ipmasqadm (I've never used it) I'm using those lines for that. Of course, you have to enable 'IP Transparent Proxy' in your kernel. ipchains -A input -p TCP -d YOUR_IP/32 www -j ACCEPT (in case you have your own web server) ipchains -A input -p TCP -d 0/0 www -j REDIRECT 8080 Conf: 2.2.19 ipchains It works for me: 2.2.18 ipchains 1.3.9, 17-Mar-1999 Greetings ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ipchains redirect
Scott C. Best wrote: Heyaz. Saw this on security-basics this AM. Never saw it mentioned on LRP/LEAF before; anyone ever try it? Alternatively, is IP Transparent Proxy enabled in any LEAF kernels? Seems terribly powerful to me. I've done this before, I think; it can be nice, especially for things such as web cache. However, for a router with no hard disk it isn't all that useful. The basic idea is that ALL web traffic going out is passed through the proxy itself; helps if you want to add a web cache but don't want any client reconfiguration to be needed. Its also good for proxies such as JunkBuster or filtering proxies. -- Forwarded message -- Date: Wed, 19 Sep 2001 20:19:19 +0200 (CEST) From: Bosko Radivojevic [EMAIL PROTECTED] To: Daniel Chojecki [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: ipchains, ipmasqadm On Tue, 18 Sep 2001, Daniel Chojecki wrote: Is it posible to redirect all traffic comming for 0.0/0 80 to local squid proxy using ipchains and ipmasqadm. Using ipchains - yes. I'm not sure for ipmasqadm (I've never used it) I'm using those lines for that. Of course, you have to enable 'IP Transparent Proxy' in your kernel. ipchains -A input -p TCP -d YOUR_IP/32 www -j ACCEPT (in case you have your own web server) ipchains -A input -p TCP -d 0/0 www -j REDIRECT 8080 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] ipchains redirect
I haven't played with this much, but one of the things on the list of stuff to play with one of these days is using redirect to provide for an 'internal server' machine, similar to the way the low-end firewall boxes do. I *think* this would work properly for everything from game servers to VPN access, although security in such a situation isn't the greatest (although it's not too bad if combined with port-forwarded DMZ rules). Charles Heyaz. Saw this on security-basics this AM. Never saw it mentioned on LRP/LEAF before; anyone ever try it? Alternatively, is IP Transparent Proxy enabled in any LEAF kernels? Seems terribly powerful to me. TIA! -Scott -- Forwarded message -- Date: Wed, 19 Sep 2001 20:19:19 +0200 (CEST) From: Bosko Radivojevic [EMAIL PROTECTED] To: Daniel Chojecki [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: ipchains, ipmasqadm On Tue, 18 Sep 2001, Daniel Chojecki wrote: Is it posible to redirect all traffic comming for 0.0/0 80 to local squid proxy using ipchains and ipmasqadm. Using ipchains - yes. I'm not sure for ipmasqadm (I've never used it) I'm using those lines for that. Of course, you have to enable 'IP Transparent Proxy' in your kernel. ipchains -A input -p TCP -d YOUR_IP/32 www -j ACCEPT (in case you have your own web server) ipchains -A input -p TCP -d 0/0 www -j REDIRECT 8080 Conf: 2.2.19 ipchains It works for me: 2.2.18 ipchains 1.3.9, 17-Mar-1999 Greetings ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: [Leaf-user] Dachstein-CD-rc3 available: bash.lrp error
Michael D. Schleif wrote: Charles Steinkuehler wrote: The third release-candidate version of Dachstein-CD is now available. This version feels like it's getting pretty close to done. Lots of minor chagnges, none of them show-stoppers, just getting everything working the way it should. This version is the first release that has actually gotten *SMALLER*, mainly due to the elimination of duplicate binaries in some of the packages, and the migration to busybox for some others. I haven't tried bash.lrp since pre-release. There used to be two (2) bash-related problems; now, I find one (1): Mounting local filesystems... ramdisk.pkg: Uncompressing archives - log.tgz/etc/rcS.d/S36ramdisk.pkg: line 33: 1001 Broken pipegunzip -c $pkgdir/$pkg 1002 Done | qt tar -x -Finished. I'm not sure what is wrong here -- I do not see wrong with the scripts. log.tgz *does* get un-archived and bash is working. Nevertheless, this is some kind of error -- hopefully *not* to manifest itself elsewhere . . . P.S. I am using ramlog.lrp -- *not* ramdisk.lrp . . . -- 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] Re: [Leaf-user] Announcing official release of Dachstein-CD
Michael D. Schleif wrote: Charles Steinkuehler wrote: The official release (v1.0.1) of Dachstein-CD is now available for download from the usual places: slow: http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/ fast: http://lrp1.steinkuehler.net/files/diskimages/dachstein-CD/ http://lrp2.steinkuehler.net/files/diskimages/dachstein-CD/ There was a 'silent' release of v1.0.0 for internal use yesterday. Changes from the last release candidate include configuration tweaks (dnscache and ipsec), the inclusion of the ipsec binaries patched for x.509 certificate support, and fixes to a couple minor bugs (a problem with the POSIXness cut command, and setting custom backup destinations didn't work properly). As always, this is truly superb stuff! Bravo, Charles !!! Couple questions, even though these items appeared in RC5: [1] What is the purpose of the ``leaf'' user? [2] Should /home/leaf exist -- provided that we agree that such an user ought to exist? Interestingly enough, logged in as leaf, I *cannot* su - root su: Incorrect password What gives? Trust me, I know the root password ; But, I cannot eliminate root login if I cannot su to root . . . -- 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] LEAF version FAQ rev.1
Looks good! Comments inline...
Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
snip
you can also use the net command
# net
Usage: net start|stop|reload
net ifup|ifdown|ifreset eth0|eth1|eth2|all
net ipfilter load|flush|reload
net ipfilter list [input|output|forward|autofw|mfw|portfw]
net ipfilter list masq|masquerade
IIRC, some of these commands are unique to the 'mountain'
series, especially
the net ipfilter ... commands. Any 2.9.x or Oxygen users
care to comment?
No net command in 2.9.8
snip
FIREWALL RUNNING RFC PRIVATE CLASS ADDRESS ON WAN CONNECTION
# edit /etc/ipfilter.conf and comment out the applied line of the
function:
# #A function to filter out martian source addesses
stop martians () {
#RFC 1918/1617/1597 blocks
$IPCH -A $LIST -j DENY -p all -s 10.0.0.0/8 -d 0/0 -l $*
$IPCH -A $LIST -j DENY -p all -s 192.168.0.0/24 -d 0/0 -l $*
#then have it take effect with svi network reload.
Maybe something that makes it a bit clearer the above (silent deny and
private IP mods) only applies to the 'mountain'
firewalls...not to Oxygen or
LRP 2.9.x
LRP 2.9.x don't use ipfilter.conf
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] More on dates
David Douthitt wrote: On 2/8/02 at 5:23 AM, Mike Noyes [EMAIL PROTECTED] wrote: At 2002-02-08 00:43 -0600, David Douthitt wrote: So how important is setting the time/date with date? Is rdate (or ntpclient) enough? I think it's important to have the correct date. My ISP NOC wont accept abuse reports without valid time stamps in syslog. That doesn't answer my questions I use rdate on my current floppy to set the time on boot. rdate connects a server on my lan, and my server connects to a timeserver on the Internet with xntpd. I use this setup for two reasons. One, I feel it's more secure than having the router/firewall accessing a time server on the Internet. Two, rdate connections are refused by most timeservers on the Internet. WIth rdate, I'd say that's the way to go for all the reasons you mentioned. So - can you do without date -s ? Frankly, managing nearly ten leaf/lrp systems, I do not have any problem with keeping time within one (1) second across all of them, using rdate. So, no -s is OK with me. However, since we are limited to shell scripting and my recent work on leaf has required me to compare dates and times, a working-as-advertised -d operation would simplify alot for me . . . 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
Re: [Leaf-devel] Re: Standards and due process :-)
David Douthitt wrote: On 2/14/02 at 8:05 AM, Michael D. Schleif [EMAIL PROTECTED] wrote: I know that it is available; but, it is *not* included in DCD -- is it included in Oxygen? I do not argue against its usage; rather, I am often frustrated by lack of real awk, sed and sort -- not to mention cmp and diff ; As far as I know, both Oxygen and Dachstein use GNU sed; Oxygen just happens to use sed 3.0 and Dachstein something older I think. Sorry, I was running off at the keyboard and forgot to check this: # /bin/sed -V GNU sed version 2.05 mawk.lrp is available, as is diff.lrp. I think busybox comes with sort - 0.60.2 anyway, in Oxygen... The point is, it is one thing to get a basic system to boot and initialize -- it is quite another to manage the running system. I agree that [mn]*awk is a luxury that may not be warranted in a base system. However, to manage the running system, it may be prudent to monitor changes to that running system, especially since one of the primary reasons for that system is to guard and protect the rest of the network on which it resides. In that spirit, I believe that real sort, cmp and possibly diff are warranted. But cmp? Who needs that? Besides the it's size? # uname -a Linux Loki 2.2.19 #1 Sat Oct 20 18:09:49 EST 2001 i686 unknown # ls -l /usr/bin/cmp /usr/bin/diff -rwxr-xr-x1 root root 9336 Aug 23 05:58 /usr/bin/cmp -rwxr-xr-x1 root root62076 Aug 23 05:58 /usr/bin/diff -- 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] 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] Location for scripts during startup
I am looking at implementing the following sequence of events in a redesign fo the weblet: (this is the weblet as we are now defining it, a web application that is seperate from the underlying sh-httpd server) - system starts boot Handled by syslinux... all packages finish loading ...and the filsystem is fully populated (/etc/rc?.d/* links created, busybox links created, /dev populated, etc). All this is handled by /linuxrc 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) 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). LEAF start up completes -- Where is the appropriate location to initiate the above scripts so that they are executed at the proper time, after all the packages have loaded? It looks like this might be easy to find, but as this is an important point, I would feel better getting an expert answer. 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. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) --- 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] cvs commit directory structure ???
Mike Noyes wrote: On Mon, 2002-07-15 at 22:39, Michael D. Schleif wrote: No matter how hard I try, I cannot commit a directory structure to cvs. [ snip ] I looked at your commit messages, and I think I understand what you were trying to accomplish. Here is a sequence that I believe would have worked. [ snip ] Is there some way to *transfer* a cvs module from my own cvs to sourceforge/leaf cvs? I have created a cvs environment for my own development. Since I already have [many of] my packages situated as local cvs modules, it would be most convenient if there is some way to move modules from cvs_A to cvs_B. Or, need I *export* a module from my own cvs prior to importing it into sourceforge/leaf cvs? -- 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 . . . --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] cvs commit directory structure ???
On Tue, 2002-07-16 at 06:52, Michael D. Schleif wrote: Mike Noyes wrote: On Mon, 2002-07-15 at 22:39, Michael D. Schleif wrote: No matter how hard I try, I cannot commit a directory structure to cvs. [ snip ] I looked at your commit messages, and I think I understand what you were trying to accomplish. Here is a sequence that I believe would have worked. [ snip ] Is there some way to *transfer* a cvs module from my own cvs to sourceforge/leaf cvs? Michael, Yes. A tarball of your current repository is needed for this. ref. # Introduction to SourceForge.net Project CVS Services Import of Existing CVS Repositories https://sourceforge.net/docman/display_doc.php?docid=768group_id=1 I have created a cvs environment for my own development. Since I already have [many of] my packages situated as local cvs modules, it would be most convenient if there is some way to move modules from cvs_A to cvs_B. CVS doesn't sync repositories. Either you use your local one or the one on SF. Or, need I *export* a module from my own cvs prior to importing it into sourceforge/leaf cvs? This is one method, but you'll lose your history doing it this way. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Perl help
Mike Noyes wrote:
On Wed, 2002-07-17 at 08:58, Michael D. Schleif wrote:
Mike Noyes wrote:
Anyone,
Will removing the following lines from enforce_naming leave the perl
script functional?
Yes, absolutely yes; provided that either all of the lines are
completely _removed_ or completely commented out.
Hmm, then what did I do wrong in rev 1.2? I used vi to dd out the lines
below, and you ended up with a broken pipe from the server last night.
Any enlightenment is appreciated.
Previously, you said that _cvs import_ somehow bypasses case checking,
or this script. Since all I did last night was _cvs import_, and
because there is nothing in enforce_naming (no version in cvs) that
would result in broken pipe errors, I believe the culprit is
elsewhere.
# Verify that all files are lowercase, except Makefiles
if ((substr($_, 0, 8) ne Makefile) and (lc($_) ne $_)) {
print All filenames must be completely lowercase except ;
print Makefiles. ($directory/$_)\n;
$exit_val = 1;
}
leaf/CVSROOT/enforce_naming rev 1.3
http://cvs.leaf-project.org/cgi-bin/viewcvs.cgi/leaf/CVSROOT/
Also, remove the lone `next;' at end of for loop, since the for loop
does that automatically, by design ;
Is this true for older versions of perl too? The SF cvs server may not
have the newest perl release on it.
I've been Perl'ing since v4.0x days. That is the design of a for loop.
That `next;' does not do anything bad except waste a couple cpu cycles .
. .
--
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 . . .
---
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] Perl help
On Wed, 2002-07-17 at 09:58, Michael D. Schleif wrote: Mike Noyes wrote: On Wed, 2002-07-17 at 08:58, Michael D. Schleif wrote: Mike Noyes wrote: Anyone, Will removing the following lines from enforce_naming leave the perl script functional? Yes, absolutely yes; provided that either all of the lines are completely _removed_ or completely commented out. Hmm, then what did I do wrong in rev 1.2? I used vi to dd out the lines below, and you ended up with a broken pipe from the server last night. Any enlightenment is appreciated. Previously, you said that _cvs import_ somehow bypasses case checking, or this script. Since all I did last night was _cvs import_, and because there is nothing in enforce_naming (no version in cvs) that would result in broken pipe errors, I believe the culprit is elsewhere. Michael, It seems to, but I don't think it should. Our commitinfo seems to process our cvs_acls script but not enforce_naming on imports. I need to find a reference to what commands activate commitinfo in which circumstances. Also, remove the lone `next;' at end of for loop, since the for loop does that automatically, by design ; Is this true for older versions of perl too? The SF cvs server may not have the newest perl release on it. I've been Perl'ing since v4.0x days. That is the design of a for loop. That `next;' does not do anything bad except waste a couple cpu cycles . Thanks for the info. I'll remove it also. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- 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] CVS structure ???
Jeff Newmiller wrote: On Wed, 10 Jul 2002, Michael D. Schleif wrote: [ snip ] I am starting to realize that, perhaps, I should take a directory based approach to helices' cvs tree. I have not settled on any particular structure. However, I am wondering about several things: [ snip ] CVS is designed to handle directories full of information... so a directory tree of html documents is a natural thing to enter. An idea... net-snmp/ README.txt package/ net-snmp.lrp target/ etc/ blahblah usr/ bin/ snmpbinary ... doc/ index.html images/ image1.jpg ... src/ sourcefiles... [ snip ] I took a liking to this structure, which you can see here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/helices/ I appreciate *ALL* feedback on this infrastructure, before I get carried away with further additions to cvs. 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 . . . --- 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] Linux Virtual Server using LEAF Bering RFC
On 2002.09.17_11:54:09_+, Brad Fritz wrote: I cannot answer your question about whether it will be included, but I can say that the linux-2.4.12-ipvs-0.8.2 patch applies cleanly over the stock Bering rc3 patched kernel[1]. Actually I have tested applying linux-2.4.19-ipvs-1.0.6.patch.gz to 2.4.18 with Bering patches. Also applies cleanly. The IPVS kernel, including IPVS debugging support, is only 44 bytes larger than the stock kernel after UPX compression. $ ls -l ../*.upx -rw-r--r--[..] 495299 Sep 17 11:42 ../Bering_1.0-rc3-ipvs.upx -rw-r--r--[..] 495235 Sep 17 11:26 ../Bering_1.0-rc3.upx Great. May be this will be a good reason to incorporate IP_VS into Bering or Dachstein kernel. make modules is running now. If it would be helpful, I could upload the (completely untested) kernel and modules, along with the build script I used to download patches and apply them to the stock 2.4.18 kernel, to my devel subdirectory in CVS. Let me know if that would be useful to you. Sure it would help. I would like to have such a script to automate the work. So far I have been doing it manually. The kernel should help me examine different result of patches version for testing. Thanks Brad. --Brad [1] with the exception of non-essential Documentation/Configure.help file -- H. D. Lee --- 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] Linux Virtual Server using LEAF Bering RFC
On Wed, 18 Sep 2002 06:55:56 +0700 H. D. Lee wrote: Great. May be this will be a good reason to incorporate IP_VS into Bering or Dachstein kernel. Even if it's not included, the build-from-source approach being discussed should make it easy for interested parties to roll their own kernel and modules. If it would be helpful, I could upload the (completely untested) kernel and modules, along with the build script I used to download patches and apply them to the stock 2.4.18 kernel, to my devel subdirectory in CVS. Let me know if that would be useful to you. Sure it would help. I would like to have such a script to automate the work. So far I have been doing it manually. The kernel should help me examine different result of patches version for testing. Thanks Brad. Posted to http://fritzfam.com/brad/leaftmp/make_bering_ivs_kernel temporarily. As time allows, I am going to re-write it using GAR or David's ports-like system (or both). Once I do, I will check it into cvs.sf.net under leaf/devel/bradfritz . --Brad -- H. D. Lee --- 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] Different Size of Kernel Using Different Distro
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. Mandrake Linux 8.2 -- $ gcc --version 2.96 $ cd /usr/src/linux/arch/i386/boot; ls bzImage -rw-r--r--1 root root 598779 Sep 18 09:53 bzImage Compressed using UPX 1.11, the result is: $ cd /usr/src/linux/arch/i386/boot; ls -l bering-ipvs.upx -rw-r--r--1 root root 521063 Sep 18 09:53 bering-ipvs.upx Debian 3.0 -- $ gcc --version 2.95.4 $ ls -l /usr/src/linux/arch/i386/boot/bzImage -rw-r--r--1 root root 571744 Sep 21 17:10 bzImage And the result compressed with UPX 1.11: $ cd /usr/src/linux/arch/i386/boot; ls -l bering-ipvs.upx -rw-r--r--1 root root 495547 Sep 21 17:10 bering.upx It is clear that one of the reason the size differs is the gcc version. The question is: what version of gcc that will compile the smallest bzImage? Under what distro? -- H. D. Lee --- 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
Eric B Kiser wrote: You must mean inside that really obvious directory named /lib. Urgh, it is now probably a moot point to mention that I am a newbie. Your patience is appreciated. Here is where I am now. I execute the command #zebra -d to start the zebra process running as a daemon and I get the following message back. zebra: error in loading shared libraries libcrypto.so.2: cannot open shared object file: No such file or directory snip / There is a very real difference between these two (2) libraries: libcrypt libcrypto The latter is part and parcel of openssl; perhaps, also some other libraries. How are you compiling zebra? On what describe system? With what libraries? You probably need to do what we have done for openssh, which is to statically link libcrypto during openssh compile . . . -- 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 . . . --- 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] RFC: Oxygen Network Boot HOWTO
On 2002.10.04_11:06:41_+, Matthew Schalit wrote: Neat. It'd be nice if you added a .txt extension to the file so that clicking on the link displayed the HOWTO in Mozilla rather than defaulting to downloading a binary/octet stream mime type. Good idea. Will be fixed on the next update. Just to prevent missing link if I fixed it right now. Sorry for inconvenience caused. Also I would like to convert this document to DocBook one day. Also, when you do look at it in Mozilla, you can see the first few paragraphs weren't formatted with any carriage returns so that the lines are about 400 characters wide and we have to scroll sideways. True, I wrote this using vim without applying any text formatting option. Thanks for the suggestion. Beyond asthetics, it'd be helpful if you said a few words about mknbi-linux which is where a lot of the meat an potatos happens. I'd not heard of it until seeing you use it. And if you could comment somewhere on the changes you made to oxygen.cfg that makes it load pacakges over the network. mknbi-linux was mentioned on the software requirement part, although nothing exist to explain it further. I'll add one. Also another nice idea to comment the changes to oxygen.cfg. And finally, as far as useability goes, how do you back stuff up? This is one thing that have not been finished. As previous message stated, this document is still in very alpha stage. I liked it, Thanks. matthew -- H. D. Lee --- 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] compact flash ???
Also sprach David Douthitt (Thu 20 Feb 02003 at 04:25:07PM -0600): On Wed, 19 Feb 2003 19:25:28 -0600 Michael D. Schleif [EMAIL PROTECTED] wrote: Are you booting off of this? How? Any special preparation to boot off of USB? You could say I am. It's a three-media startup: install CDROM, boot off of that. Put the floppy configuration disk in the floppy drive, and the USB device on the USB chain. Then tell the floppy to use the floppy configuration (in reality, a shell script sourced off of floppy). This floppy script then runs a script on the USB device which does all of the work. I want to eliminate both floppy and cdrom. So, we will need to boot directly from the flash . . . -- 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 . . . -- --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bridging/tc/shorewall
Richard Doyle wrote: On Fri, 2003-03-07 at 18:19, S Mohan wrote: I'm also not sure why you need ebtables. The bridge-nf patches already incorporated in the Bering kernel already allow one to filter, mangle and nat IPv4 packets with iptables. But not to the extent that one can make meaningful use of Shorewall. We have several choices: a) Just use iptables/ebtables directly in the bridging environment (the current state of affairs). b) Hack Shorewall to allow it to be used in a bridging environment. This may involve the use of ebtables to force packets to be routed rather than bridged (see Mohan's recent post). c) Clone Shorewall and hack out everything that doesn't apply to bridging, add whatever is necessary and call it Shorebridge or something. d) Create from scratch a frontend for iptables that is targeted at the bridging environment. I've volunteered to help determine the feasibility of b). I have neither the time nor the interest to get involved in c) or d). -Tom -- Tom Eastep\ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ [EMAIL PROTECTED] --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] glitch in webconf
Hi Folks
I have a LEAF box with multiple personalities, controlled through
multiple leaf.cfg files which define different configdb files.
Backing up the configdb works fine with lrcfg but fails miserably with
the webconf interface. The problem appears to be the parameter passing
in the file lrcfg.back.cgi.
The following patch fixes the problem for me
feed to patch
--- lrcfg.back.cgi.old 2006-11-17 18:49:44.0 +0100
+++ lrcfg.back.cgi 2007-08-24 14:22:14.872823587 +0200
@@ -11,6 +11,7 @@
fi
title=Commit Changes to Read/Write Media
/var/webconf/lib/preamble.sh ?
!-- $Id: lrcfg.back.cgi,v 1.3 2006/09/12 17:57:25 espakman Exp $ --
+!-- patched for variable CONFIGDB values by Erich Titl
[EMAIL PROTECTED] --
? # lrcfg.back settings
SESSIONID=${FORM_SESSIONID:-${SESSIONID}}
@@ -85,7 +86,7 @@
build_lrp () {
# use apkg $1 to build the package in /tmp
- apkg $1 /tmp 21 1/dev/null
+ apkg $1 $2 /tmp 21 1/dev/null
if ! [ -r /tmp/$2.lrp ]; then
log Red The package was not created
in /tmp!
return 1
@@ -206,7 +207,7 @@
echo
# The name comes from /var/lib/lrpkg/backup
echo td
- grep ^${x} /var/lib/lrpkg/backup 2/dev/null | cut -f2 -d= ||
echo ${x}
+ grep ^${x} /var/lib/lrpkg/backup 2/dev/null | cut -f1 -d= ||
echo ${x}
echo /tdtd align=left$( eval echo \$${x}_descr)/td
echo /tr
done
cheers
Erich
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] start with branch renaming/moving
Le 6 janv. 2014 à 19:09, KP Kirchdörfer kap...@users.sourceforge.net a écrit : Locally I do have maint-4.x, how to proceed? btw: how can we fix the wrong rename/move of maint to maint-4.x? Yes easy :D remove local and remote branches with the commands: git checkout master git branch -d maint-4.x git push origin :maint-4.x Really? master is at 5.0. What I'm looking for is to have move back maint-4.x to maint, then do it right to move maint to maint-4x and from then to create a new maint from master. Yes you need to delete maint-4.x locally and remotely then « create » a new maint and a new master. If you think it’s obscur for you i can do it. Regards, Yves -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] 5.x0-alpha considerations
Hi all; the x86 version of the upcoming 5.0 version runs quite well in production for a few months. The buildtool issues related to latest changes are solved and building for x86 shows green for every package. So I think the x86 is ready to prepare a release - anyone disagree about x86? But I tried to run buildall.sh with the toolchain set to Toolchain = armv5te-unknown-linux-uclibcgnueabi.mk as a test for the work to support other architectures. Unfortunately it fails while building the kernel sources with the error message: xzcat patch-3.2.29.xz | patch -p1 -s -d /opt/buildtool-master/source/armv5te-unknown-linux-uclibcgnueabi.mk/linux/linux-3.2 ln -s /opt/buildtool-master/source/armv5te-unknown-linux-uclibcgnueabi.mk/linux/linux-3.2 linux cat bitreverse.patch | patch -d /opt/buildtool-master/source/armv5te-unknown-linux-uclibcgnueabi.mk/linux/linux-3.2/lib -p0 patching file Kconfig Hunk #1 succeeded at 11 with fuzz 1 (offset 3 lines). cat kernel-mkmakefile.patch | patch -d /opt/buildtool-master/source/armv5te-unknown-linux-uclibcgnueabi.mk/linux/linux-3.2 -p1 patching file Makefile Hunk #1 succeeded at 423 with fuzz 1 (offset 23 lines). patching file scripts/mkmakefile cat 620-sched_esfq.patch | patch -d /opt/buildtool-master/source/armv5te-unknown-linux-uclibcgnueabi.mk/linux/linux-3.2 -p1 patching file include/linux/pkt_sched.h patching file net/sched/Kconfig patching file net/sched/Makefile patching file net/sched/sch_esfq.c cat 621-sched_act_connmark.patch | patch -d /opt/buildtool-master/source/armv5te-unknown-linux-uclibcgnueabi.mk/linux/linux-3.2 -p1 patching file net/sched/act_connmark.c patching file net/sched/Kconfig patching file net/sched/Makefile mkdir -p /opt/buildtool-master/toolchain/armv5te-unknown-linux-uclibcgnueabi.mk/usr touch .source (for i in ; do \ patch -i Bering-3.2.29.config-$i.patch -o Bering-3.2.29.config-$i Bering-3.2.29.config \ mkdir -p linux-$i cp Bering-3.2.29.config-$i linux-$i/.config \ ARCH= make -C /opt/buildtool-master/source/armv5te-unknown-linux-uclibcgnueabi.mk/linux/linux-3.2 O=../linux-$i oldconfig || \ exit 1; done ; \ ARCH= make -C linux-$i include/linux/version.h headers_install \ cp -r linux-$i/usr/include /opt/buildtool-master/toolchain/armv5te-unknown-linux-uclibcgnueabi.mk/usr) make: Entering an unknown directory make: *** linux-: No such file or directory. Stop. make: Leaving an unknown directory As cross-platform compilation is one of our main targets for the 5.x series IMHO this is a showstopper for the alpha version. Maybe someone has a quick solution/idea how to fix this - at least it worked some time ago :) As major tasks after the release of an alpha version I see: 1) providing (an) image(s) for other platforms 2) improvements to the build/release process to alleviate support for other platforms 3) Adjust/cleanup the wiki for the 5.x series - that means to keep the developer guide in sync with the changes since 4.x, to review and copy (and update, where necessary) the 4.x User Guide to 5.x User Guide 4) Work on the webpage (probably in sync with moving to a new CMS). Do I have missed something, other opinions, anything else...??? kp -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
