Re: [leaf-devel] ipt_CONNMARK.o
You two are right, I'm so sorry, if I had used my own damn tools instead of doing it by hand it would have showed up. I keep doing crap like this, sorry for being unobservant. On Dec 19, 2006, at 11:49 PM, KP Kirchdoerfer wrote: > Am Mittwoch, 20. Dezember 2006 00:06 schrieb Paul Traina: >> It looks like ipt_CONNMARK.o is not in the Bering*_modules.tgz file >> in the iso image. >> >> Can we please get this in as part of the standard build before >> shipping 3.0? It's needed for TCP connection tracking when using >> shorewall to do intelligent rate limiting of flows. > > tar -tvzf Bering-uClibc_modules_2.4.33.tar.gz | grep ipt_CONNMARK > -rw-r--r-- root/root 2184 2006-11-27 21:29:59 > 2.4.33/kernel/net/ipv4/netfilter/ipt_CONNMARK.o > > At least in the tarball I'll upload in a few minutes. > > kp > > -- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > > ___ > leaf-devel mailing list > leaf-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/leaf-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] ipt_CONNMARK.o
It looks like ipt_CONNMARK.o is not in the Bering*_modules.tgz file in the iso image. Can we please get this in as part of the standard build before shipping 3.0? It's needed for TCP connection tracking when using shorewall to do intelligent rate limiting of flows. Much thanks, Paul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] QBox - Back under active development
Ron Senykoff wrote: > Sorry for the duplicate emails Eric... > >>> Instead of branching out, you could create a custom QOS, configdb and >>> moddb package and a lwp plugin. The packages can be merged in an automatic >>> way with the standard package to an image. This way you can just keep pace >>> with Bering-uClibc development without putting effort in creating images >>> on your own. > > This sounds great. I'll read up on all the docs for 3.0 over the next > few days and of course, ask questions. ;) > >>> Btw, what's wrong with shorewall's QOS implementation? > > 1 - requires shorewall (the goal here is QoS, not firewalling or > trying to solve every problem in one package) right, you don't have to turn on the firewalling part of shorewall > 2 - the last I checked shorewall still required that you define your > own QoS parameters, edit config files etc. In QBox, the default > installation allows you to simply plug in your bandwidth specs and > ports / IPs that you'd like to manage. no, that was completely rewritten a while back, and later even made operable :-) I use it now and it works quite well. > 3 - QBox uses well tested queueing schemes. For example, would you > want to apply SFQ (Stochastic Fairness Queueing) to video traffic? > Short answer: no. Long answer: I've tried this, and found that every > time the SFQ algorithm rehashes (default is 30 secs I believe) you > will get 'pops' in audio and video. interesting for the cases where you're doing video over udp/rtp I'd like to see that fixed in shorewall's framework > The goal of QBox is to allow someone who knows absolutely nothing > about linux, queuing schemes, or text editors to implement QoS at home > or a small to mid office environment. A friend of mine is running one > on a 10Mb internet link no problem. I picked the PC Engines WRAP board > as something I will maintain an image for, so people don't have to > deal with any hardware / driver issues. My install directions include > Windows step by step to use syslinux to install. If you use the WRAP > board, it just works out of the box like a Linksys router or the like. > Also, by sticking with some defined hardwaree platform(s), I hope to > provide accurate measurements of throughput capability. This becomes > more important as I add Layer 7 filtering capability. One of the things I always bitch about here (and unfortunately don't help enough with) is improving on exactly this thing -- the packaging and installation of B-U along with the dev environment. If you feel the same way, it would be totally cool if you would be willing to take some time and look at the updates to B-U and shorewall since the last time you looked, and consider adding your effort to the existing distribution. I don't think the goals of the projects are dissimilar, I just think that the priorities are not. With someone actually spending real time working on adapting B-U to your target audience (e.g. yourself and any others who jump on your bandwagon as soon as they see how cool the work is that you're doing), you'll be able to focus on QoS and UI issues rather than that plus all the other stuff of building your own special distribution as a fork. Best of luck either way, Paul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ez-ipupdate?
Doh, I'm an ass. I found it just after I sent the note out... I was thinking, "I know it was in 2.x..." - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Documentation in Shorewall Configuration Files
Eric Spakman wrote: > Hi Paul, > >>> What troubles me more is that Tom updates the documentation on his site >>> to represent the state of the art in shorewall v5, and the currently >>> shipping versions of LEAF or BU are using shorewall v3, our >>> documentation will not match the code we're shipping. >> >> > There is no shorewall version 5, the current Stable Release version is > 3.2.6 which is what we use. The development release is version 3.3.5, > which will become 3.4.x when stable. When this version is stable, that one > is going to be used in BU. > > Eric > > Sorry, that was a "hypothetical." - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] ez-ipupdate?
Is there a reason the ez-ipupdate package for 3.x isn't in the packages 3.x list? Does it not build or? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Documentation in Shorewall Configuration Files
Mike Noyes wrote: > I believe, an even better solution is using DocBook XInclude from LEAF > to the Shorewall site. This is only possible if you're using DocBook XML > to generate man pages, and the docbook xml source is > available via uri. > The only problem with that idea that I can think of, is that it vulnerable to Tom changing URLs or updating the documentation for Shorewall while we have not updated or changed ours. Up to you. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] bristuff02 on cvs repository
Andrea Fino wrote: > > Hi to all, > > I have put the ast*.lrp packages on the cvs repository on sourceforge. > > here they are: devel/faino/asterisk/packages/bri2/ > > Moreover, I have put all the things needed to build them. If someone is > interested I can write down some doc about building them. > > Best regards, > Andrea Fino > Better yet, how about integrating them into the buildtool.pl system so we don't need to know how to build them, we can just run buildtool.pl. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] new stuff is running great
Eric, The new .lrp files are running on the home router as well as the development systems. I can't begin to tell you how happy I am that this will be the last 3 hours of manual diffing and patching I had to do for LEAF configurations when doing a forklift upgrade. Paul p.s. I've got a new rules file for you for shorewall that cleans up some formatting bugs and adds support for traceroute. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] yet another functionality request for 3.0 - ancillary file storage .lrp
Eric Spakman wrote: > Please take a look at the local.lrp package of 3.x, it has a new > functionality. You can list the added files that you want to save. Before > use check the help file of local.lrp. That's good enough, thanks Eric! - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] yet another functionality request for 3.0 - ancillary file storage .lrp
The 2.x distribution had one particularly nice feature that I'd like to see reimplemented in 3.x. From the looks of it, saving the config currently only checks the collection of config files enumerated in /var/lib/lrpkg/*.config. There are times when I need ancillary scripts and crap on the router and don't have them in a package format (and don't want them in their own separate package), but there's no way to save them between reboots. For example, when I'm working on tools like the modules building script, or if I'm doing some lightweight firewalling and don't want to use shorewall, I might just have a simple script in /usr/bin or /etc/init.d respectively. It would be cool if we could have a local.lrp similar to configdb and moddb that contained any extra files not explicitly enumerated in the loaded packages package lists (obviously excluding /dev and /var and any other random generated crap). We used to have a local.lrp that covered everthing in /usr/local, but honestly that was a bit limiting anyway (my local stuff inevitably got saved in the 2.x etc.lrp). If there's no official behavior for this currently (I could be blind, I'm cutting over to 3.x at high speed and not reading docs all that well), would you mind if I created something? Do you have opinions about how it should behave? - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] how is the CD actually made?
Cédric Schieli wrote: > The best doc (or starting point) should be the script > tools/createimage.sh in buildtool Awesome, much thanks! - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] how is the CD actually made?
OK, what I'd like to do is reproduce the build sequence that you guys use, exactly, to create the CD. What I'd like to do is have a unified build from scratch and build from source environment (perhaps modulo lrpstat). Is there any documentation on that? - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] apkg wishlist functionality...
I'm going to try to pound out something to do this, unless someone tells me that there's already a better way of doing it. I don't quite understand apkg.merge yet so I'm still scratching my head on how to do it most efficiently. I would like some functionality that would generate a diff -u file of: 1) The current running configuration vs. the current saved configuration in configdb. "What changes am I about to make before I save the configuration?" 2) The current saved configuration vs. the distribution .lrp configuration. "What makes this router special?" I realize that configdb carries all changed files, but I want to know what config changed, not just which files changed. That way I can keep archives of config changes of all of my machines on a central host and quickly see if someone did something stupid to the network. Is anyone (hopefully) already working on adding that functionality to apkg? - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] patch: enable traceroute in busybox
On Fri, Sep 08, 2006 at 06:18:01PM +0200, Eric Spakman wrote:
> I'd be interested to know how much adding traceroute to busybox does
> with the size of the initrds.
With traceroute:
-rwxr-xr-x 1 root root 272952 2006-09-08 00:52 busybox
Without:
-rwsr-xr-x 1 root root 266136 Sep 4 2006 /bin/busybox
Speaking of busybox, I noticed that you're linking busybox to its linked
commands with symbolic links instead of hardlinks. Using hardlinks
should be more memory and space efficient *if* using a symbolic link
takes up an inode in the filesystem in memory/on disk. Unfortunately,
my memory is too foggy to remember exactly which filesystems symbolic
links take inodes in vs directory entries.
> Having argument processing is indeed nice, but automatically finding
> boot media is not really necessary in my opinion. It doesn't need to
> be a fully automatic process. If you just mount the device and
> something like 'loadmod /mnt/Bering-uClibc-2.4.33.tar.gz' it should
> be enough for a start.
OK, then you're welcome to add this to the distribution. :-)
Feel free to bang on it.
#!/bin/sh
#
# Build /lib/modules based upon the contents of /etc/modules and a
# defined modules repository.
#
# Copyright (c) Paul Traina 2006, GPL v2
#
MODLIST=/etc/modules
MODREPO=/mnt/modules.tgz
LIBMOD=/lib/modules
##
progname=`basename $0`
usage() {
cat >&2 <<-EOF
Usage: $progname [ -m modules ] [ -f modules.tar.gz ] [ -l module-dir ]
Defaults:
-m $MODLIST
-f $MODREPO
-l $LIBMOD
Extract kernel modules from $MODREPO into $LIBMOD
based upon the contents of $MODLIST.
EOF
}
args=`getopt -a -o hm:f:l: -n "$progname" -- "$@"`
if [ $? != 0 ] ; then
usage
exit 1
fi
eval set -- "$args"
while true ; do
case "$1" in
-h) usage; exit 0 ;;
-m) MODLIST="$2"; shift 2 ;;
-f) MODREPO="$2"; shift 2 ;;
-l) LIBMOD="$2";shift 2 ;;
--) shift; break ;;
*) echo >&2 "Internal error"; exit 1 ;;
esac
done
if [ ! -f $MODLIST ] ; then
echo >&2 "$progname: module list $MODLIST not found"
exit 1
fi
if [ ! -f $MODREPO ] ; then
echo >&2 "$progname: module repository $MODREPO not found"
exit 1
fi
if [ ! -d $LIBMOD ] ; then
echo >&2 "$progname: module directory $LIBMOD not found"
exit 1
fi
##
MODLIST=/tmp/build-modules-list.$$
MODTEMP=/tmp/build-modules-extract.$$
for mod in $modules ; do
if [ ! -f $LIBMOD/${mod}.o ] ; then
missing="${mod}.o ${missing}"
fi
done
# Nothing missing...
if [ -z "$missing" ] ; then
exit 0
fi
echo "Missing kernel modules: ${missing}"
#
# get absolute path of all modules in tarfile first (sigh)
#
trap "rm -f $MODLIST" 0 1 2
tar tzf $MODREPO > $MODLIST
for mod in $missing ; do
findmod="`grep -F ${mod} $MODLIST` ${findmod}"
done
rm -f $MODLIST
trap '' 0 1 2
#
# Now do the actual module extraction to a temporary area and then
# move the modules to /lib/modules
#
trap "rm -rf $MODTEMP" 0 1 2
mkdir $MODTEMP
tar xzf $MODREPO -C $MODTEMP $findmod
echo
echo -n "Installing modules:"
for mod in $findmod ; do
echo -n " `basename $mod .o`"
mv $MODTEMP/$mod $LIBMOD/`basename $mod`
done
echo
rm -rf $MODTEMP
trap '' 0 1 2
exit 0
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] example "build modules" engine...
Here's what I was talking about... this is the core engine, obviously
it should take some command arguments, and make some intelligent guesses
about where .lrp files exist (stealing from apkg/lrcfg), but I wanted
to show actual working code to make this a non-academic pitch.
Even if folks don't like the idea of dynamic modules extraction at start,
this is a useful tool in its current condition for building up your
modules on demand and saving them with lrcfg.
Regards,
Paul
#!/bin/sh
#
# Build /lib/modules based upon the contents of /etc/modules and a
# defined modules repository
#
MODLIST=/etc/modules
MODREPO=/mnt/mod2433.tgz
LIBMOD=/lib/modules
MODLIST=/tmp/build-modules-list.$$
MODTEMP=/tmp/build-modules-extract.$$
modules=`sed -e 's/#.*//' -e 's/ .*//' -e '/^ *$/d' /etc/modules | sort`
missing=""
for mod in $modules ; do
if [ ! -f $LIBMOD/${mod}.o ] ; then
if [ -z "$missing" ] ; then
echo -n "Missing kernel modules:"
fi
echo -n " ${mod}"
missing="${mod}.o ${missing}"
fi
done
# Nothing missing...
if [ -z "$missing" ] ; then
exit 0
fi
echo "."
echo "Extracting modules..."
#
# Ugly -- get absolute path of all modules since we don't have tar -X
#
trap "rm -f $MODLIST" 0 1 2
tar tzf $MODREPO > $MODLIST
for mod in $missing ; do
findmod="`grep -F ${mod} $MODLIST` ${findmod}"
done
rm -f $MODLIST
trap '' 0 1 2
#
# Now do the actual module extraction to a temporary area and then
# move the modules to /lib/modules
#
trap "rm -rf $MODTEMP" 0 1 2
mkdir $MODTEMP
tar -xzf $MODREPO -C $MODTEMP $findmod
echo
echo "Installing modules:"
for mod in $findmod ; do
echo -n " `basename $mod .o`"
mv $mod $LIBMOD/`basename $mod`
done
echo
rm -rf $MODTEMP
trap '' 0 1 2
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] patch: enable traceroute in busybox
? busybox-1.2.1 Index: .config === RCS file: /cvsroot/leaf/src/bering-uclibc/apps/busybox/.config,v retrieving revision 1.10 diff -u -r1.10 .config --- .config 13 Aug 2006 20:22:05 - 1.10 +++ .config 8 Sep 2006 05:08:09 - @@ -547,10 +547,10 @@ # CONFIG_FEATURE_TFTP_PUT is not set # CONFIG_FEATURE_TFTP_BLOCKSIZE is not set # CONFIG_DEBUG_TFTP is not set -# CONFIG_TRACEROUTE is not set -# CONFIG_FEATURE_TRACEROUTE_VERBOSE is not set -# CONFIG_FEATURE_TRACEROUTE_SOURCE_ROUTE is not set -# CONFIG_FEATURE_TRACEROUTE_USE_ICMP is not set +CONFIG_TRACEROUTE=y +CONFIG_FEATURE_TRACEROUTE_VERBOSE=y +CONFIG_FEATURE_TRACEROUTE_SOURCE_ROUTE=y +CONFIG_FEATURE_TRACEROUTE_USE_ICMP=y # # udhcp Server/Client - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] dynamic generation of dropbear keys if not present
Please consider applying this patch to dropbear. It will dynamically create the dropbear host key files if they don't exist. This is EXTREMELY useful for bringup from scratch. If you don't have access to the serial port, at least you can ssh into the box. I wish I had had it today. With this change, there is no need for gendropbearkeys anymore. rm gendropbearkeys cvs rm gendropbearkeys Index: buildtool.cfg === RCS file: /cvsroot/leaf/src/bering-uclibc/apps/dropbear/buildtool.cfg,v retrieving revision 1.9 diff -u -r1.9 buildtool.cfg --- buildtool.cfg 26 Jun 2006 17:56:31 - 1.9 +++ buildtool.cfg 8 Sep 2006 04:54:58 - @@ -17,12 +17,6 @@ Directory = dropbear - - Server = cvs-sourceforge - Revision = HEAD - Directory = dropbear - - Server = cvs-sourceforge Revision = HEAD @@ -99,12 +93,6 @@ Type= link - Source = usr/bin/gendropbearkeys - Filename= usr/bin/gendropbearkeys - Type= binary - Permissions = 755 - - Filename= etc/dropbear Type= directory Type= local Index: dropbear.init === RCS file: /cvsroot/leaf/src/bering-uclibc/apps/dropbear/dropbear.init,v retrieving revision 1.1 diff -u -r1.1 dropbear.init --- dropbear.init 1 Jul 2004 14:40:54 - 1.1 +++ dropbear.init 8 Sep 2006 04:54:58 - @@ -20,10 +20,12 @@ if [ -n "$DB_RSAFILE" ]; then DB_OPTIONS="$DB_OPTIONS -r $DB_RSAFILE" + test -f $DB_RSAFILE || dropbearkey -t rsa $DB_RSAFILE fi if [ -n "$DB_DSSFILE" ]; then DB_OPTIONS="$DB_OPTIONS -d $DB_DSSFILE" + test -f $DB_DSSFILE || dropbearkey -t dss $DB_DSSFILE fi if [ -n "$DB_BANNER" ]; then - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] dynamic modules building idea
I don't know how popular this is going to be, but I'll toss it out anyway.
For 99% of leaf users, storage is no longer ultra critical. This idea
is not meant to eliminate the current way of doing things (for those
folks who really are tight on secondary storage, things stay the same),
but I'd like to make a modest proposal.
If a file on the boot media called modules.tgz (or
Bering-uClibC-modules-2.4.33.tar.gz for the ISO image) is present,
extract the required modules from that file in realtime, on boot. That
way we're not saving & storing custom moddb.lrps if all the modules that
would normally be in that file are already in the default distribution.
It's fairly trivial, I wrote some shell code in realtime to do it
because I needed to populate /lib/modules for my box. I like this idea
better (or as an alternate to the web based stuff Arne did) because I
know the source of my modules and keep them in exact sync with the kernel.
The code I kinda cobbled together in realtime did something like this.
This is just for an example, it is not productized or tested...
# generate a list of module names
modules=`sed -e 's/#.*//' -e 's/[^ ].*//' -e '/^[ ]*$/d'
/etc/modules`
mkdir /tmp/mods.$$
cd /tmp/mods.$$
zcat /mnt/Bering-uClibc-2.4.33.tar.gz | tar xf -
for file in $modules ; do
fn=`find /tmp/mods.$$ -name ${file}.o`
if [ ! -f /lib/modules/`basename $fn` ] ; then
echo -n "Extracting $fn"
cp $fn /lib/modules
echo "."
fi
done
cd /tmp
rm -rf /tmp/mods.$$
Obviously, it should be done with tar -X so we don't fill up /tmp with a
bunch of memory resident crap that is just going away, but that's tbd
only if this sounds interesting to the B-U community.
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] initial 3.0 beta feedback
Just my random notes. I built a leaf flash from scratch using pxeboot on a spare box using the CVS .lrp packages diff.lrp is not being built? a port of traceroute would be a good thing (feedback from burning man) ditto iperf not having a WRAP configdb kinda sucked... (the whole serial console thing was a pain in the ass again). Could we uncomment the /dev/ttyS0 line in the default /etc/inittab until this stuff gets hammered out? It's much better to have to turn off a tty that you don't want than be unable to access an unconfigured machine. lrpstat & friends aren't in the packages directory webwlan was not either should we be saving /var/lib/random-seed in configdb? - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] runtime fixup of /etc/inittab for serial consoles
Sorry for the delay getting back to you, just got back from a week on the playa lighting up dust storms with 2.4 and 5.8ghz wifi... :-) > The reason I'm not really enthusiastic about this idea is that it adds a > new dependency between sylinux, initrd and the etc package and also adds > extra complexity to the linuxrc script. Something that I like to avoid as > much as possible, because, for example, makes a change to a different > kernel more difficult. Not really, or not as I understand it. It's looking at /proc/cmdline, which is going to have the console port specified on it if a serial console is chosen, unless someone makes source code changes to the kernel or is running a non x86 kernel, neither of which are B-U worries until the cross compilation environment works. :-) As far as I can tell, there is no dependency on initrd, or syslinux at all. I would do the same thing running grub or any other kind of boot loader. If you're going to actually publish and maintain hardware specific configdb's, then what I'm proposing is not necessary. However, I've become a big fan of having code just "do the right thing" when the right thing is fairly obvious and considered this in the same vein as my runtime patch to figure out that the keyboard controller wasn't present. Just a year ago you were compiling (or not, as the case was) special kernels for the WRAP unit when all we needed was a one line test in the kernel to support a runtime fix. The serial console stuff is currently the one thing getting in the way of just copying the .lrp files over and having them run. > An advantage of using some hardware specific configdb packages is that you > can also set some other standard options, like selecting the right modules > in /etc/modules, some network options and comment out the normal ttys. I was going to ask you what configdb things you would do for hardware specific changes besides fixing inittab. Frankly, a HW specific distribution with pre-populated moddb's wouldn't be awful. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] runtime fixup of /etc/inittab for serial consoles
Eric Spakman wrote: > Hi Paul, > >> Not if it's not. You're the software developer, you make the >> distribution etc.lrp. The whole point of this thing is to get people >> running with a working console. Once they're on their feet, i.e. if >> they edit the /etc/inittab or do a backup after the real inittab is >> working, things behave just as before. >> >> What it saves them from having to do is hand mess with etc.lrp on a >> second system the very first time they load the flash. >> > There is absolutly no need for that. We will release some specific > configdb packages for certain types of hardware, so it's just a > matter of copying the right configdb package to the storage media and > of you go. > > Eric > OK, fair enough, if the console speed and everything else is the same. I'm not sure I understand the reluctance to using this idea, but since I'm not the one stuck doing maintenance, it's wrong of me to continue to try to argue with you. Sorry for being a pain in the ass--I re-read my last message and the tone is not what I intended. Best and thanks, Paul - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] bug in showtraf/cron integration
Currently, /etc/init.d/showtraf adds a line to /etc/crontab. This is seriously bogus. Instead, showtraf.lrp should own a file called /etc/cron.d/showtraf and any showtraf cron commands should be in that file. Otherwise, if you back up etc.lrp while showtraf is running, you'll get showtraf's crontab lines. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] new config/backup system
Cool. I'm heading out to the desert for 2 weeks, I'll check back in once I have come home and washed all the dust off and regained my sanity. Paul - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] new config/backup system
Your call, but the stuff in the help file isn't formalized and it isn't validated in any way since it was always human input. When are you guys shooting for a 3.0 alpha test release? I just whacked together stuff for burning man based on 2.4.2 even though that's a bit creaky because I wasn't sure of the current snapshot state of cvs. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] new config/backup system
Eric & KP, Looks nice, been trying to catch up on things... Couple of questions, while we're doing the 3.0 flag day, would it be OK if we made the package dependancies explicit, not part of the help file? /var/lib/apkg/.depend which would contain a list of packages that the current package depends upon one per line: e.g. $ cat /var/lib/apkg/tcpdump.depend libpcap $ cat /var/lib/apkg/easyrsa.depend openssl The dependencies should theoretically be recursive (there are pros and cons). easyrsa would depend upon openssl (but not directly on libssl) openssl should depend upon libssl The pro is that indirect dependencies really shouldn't exist. The con is that this could lead a naive user to have to do more lrpkg's or reboots, however he does his test installs. $ lrpkg -i /mnt/easyrsa lrpkg: not installing easyrsa, openssl required $ lrpkg --fulfill-dependencies -i /mnt/easyrsa lrpkg: installing openssl lrpkg: installing libssl lrpkg: installing libcrpto If a dependency wasn't there... $ lrpkg --fulfil-dependancies -i /mnt/easyrsa lrpkg: installing openssl lrpkg: installing libssl lrpkg: not installing easyrsa, openssl, libssl: libcrpto not found In any case, the magic needed to be done to apkg/lrpkg can come later, but we need to get the new hooks into the package control files sooner rather than later. I propose modifying the XML to formalize the dependancies instead of putting them in the help file, and creating .depend control files. What do you guys think? - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] hostapd + wpa2 + madwifi_ng = broken
Hi Eric and friends, I stumbled across a couple of problems today while playing with hostapd. It looks like WPA2 (psk) is not working properly with my Atheros CM9 card. I did a cursory visual inspection of the source and it looks like the problem might be fixed by compiling with MADWIFI_NG. Unfortunately, I no longer have a linux development system (it got replaced with a Mac this week) so I can't verify it. The problem I was seeing is that clients attempting to negotiate WPA2 were generating the following message: "No WPA/RSN element for station!?" in the debug output. I noticed that there is some conditional code ifdef'ed on MADWIFI_NG. Since leaf currently ships with madwifi_ng, not the old madwifi code, it would be good to make sure that little bit of code gets compiled in. Again, I'm sorry, this is just by inspection. (oops, update, if the dev environment was correct, we should have set it based upon IEEE_80211_IOCTL_SETWMMPARAMS up at the top of the file... so I am confused). Are we compiling against the right headers? If I have a free afternoon (was hoping to do it this weekend), I'll try to get parallels desktop up and running to creat a virtual linux machine under macos running so I can do occasional leaf development. - The second problem is probably a madwifi driver bug or an inability of the CM9 card. I was trying to run WPA with CCMP (AES in CBC mode) as one of the available cyphers. (hostapd was configured to allow ccmp as well as tkip). My Mac was working fine, but my wife's PC was crapping out. When hostapd attempts to configure the atheros card to do CCMP, we get a bad ioctl error. The CM9 should support this: wlan: 0.8.4.2 (0.9.0) wlan: mac acl policy registered ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath_rate_sample: 1.2 (0.9.0) ath_pci: 0.9.4.5 (0.9.0) wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: H/W encryption support: WEP AES AES_CCM TKIP wifi0: mac 5.9 phy 4.3 radio 3.6 wifi0: Use hw queue 1 for WME_AC_BE traffic wifi0: Use hw queue 0 for WME_AC_BK traffic wifi0: Use hw queue 2 for WME_AC_VI traffic wifi0: Use hw queue 3 for WME_AC_VO traffic wifi0: Use hw queue 8 for CAB traffic wifi0: Use hw queue 9 for beacons wifi0: Atheros 5212: mem=0x8000, irq=12 FWIW, does anyone know if the openwrt development environment works in a cross compilation scenario? I never thought I'd actually get caught by all of my whining about cross compilation for leaf over the years, but now I find myself actually able to consolodate all of my computer crud into one mac laptop and, honestly, so far I'm pretty damn happy. I would be willing and able to test hostapd.lrp's if someone else can build them. Paul ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New LEAF branch?
I would love to remove the documentation from the configuration files since it is a PITA to maintain but when I've suggested that idea in the past, the moans and cries have been absolutely pitiful to hear :-) -Tom I agree and stand corrected. :-) --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New LEAF branch?
Eric, This isn't magic. Debian solved this quite nicely years ago. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New LEAF branch?
I'm glad to hear that someone with energy and good ideas is looking at this. "In a perfect world" what I'd like to see is binaries come with default sensible configurations, and the user is simply responsible for specifying and maintaining divergences from that configuration. There are a whole lot of ways to skin this cat, some are difficult and work well, some are simple and work poorly. In the most simplistic solution, we could make the binary .lrp packages read-only. They always carry the "default" /etc configuration files. When a LRP package is installed, we look up the package config files, check our own local config patches (from a config area possibly stored in a config.lrp?), and apply them. In theory, tools like ucf(1) make this fairly painless. In reality, most of the binaries that we ship have configuration files with tons of needless text and comments and examples in them, these inactive sections of the configuration files are often changed since they are the defacto documentation for a given config file, so 3 way diffs and merges almost never work without manual intervention. That's wrong. For example, a typical dnsmasq.conf has 9 lines of active commands in it and some of those may even mirror compiled in defaults, but with comments, my dnsmasq.conf is 380+ lines. Shorewall is another example, the documentation is in the configuration files. The average shorewall configuration file has 0 lines of active commands in it (grin) but has at least 150 lines of comments. A junos or IOS configuration is just the minimal changes off of the default to turn on the bits you need. There's a little semantic or syntactic structure to make it easy to migrate back and forward between binary versions. We could auto-generate config /etc files from a database. This is what we did in the JUNOS UI (my baby). Later on, we decided that XML constructs work very nicely for this kind of thing, but the overhead and bloat are high, and I think that the re-engineering effort alone for any database driven project would make such a project a non-starter, no matter how appealing it is. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Re: floppy vs flash drive
I think the question is, should the PRIMARY b-u distribution be geared towards a floppy release, or something more modern. If people with floppy only hardware want to maintain a stripped down floppy only version, that's great, but do we really want the fate of B-U tied to such limitations? Frankly, I have a love hate relationship with B-U, and I think it's destined to fail for more than a lack of a snazzy web interface. I'm not trying to blame anyone, I'm just stating issues getting in the way of B-U's usefullness for the general DIY router crowd. I've put up with them because I've been a unix hacker and router hacker for over 15 years, but I still find them painful: 1) I was a core developer for FreeBSD for over six years. I've been a Debian follower for about eight years as well. Both projects lost major mindshare because their software was too difficult for folks to install. As dedicated hackers, we looked at ourselves and said: "WTF?" Then Mandrake and later Fedora came along and we saw how installs should work. Even eye candy can be important. :-( Installing B-U on modern hardware is still a pain requiring multiple tools and sometimes multiple operating systems. Installing mono0wall is as simple as running dd or pfwrite with a single binary. Until you can make BU easy to install on something other than a box with a floppy, you're cutting off most of your "try it and see" crowd. 2) It's insanely tedious to upgrade the software because the configs are still stored with the binaries, and there are no tools for merging diffs between the configs (e.g. ucf). 3) There's no easy way to figure out what modules should be updated. Other developer rants: 4) The development environment is a mess. It needs to be portable and self contained. People should be able to build a development environment on any POSIX based system, even a cygwin environment. (wishlist much much lower priority): 5) The way we use CVS is a mess. Because diffs are stored out of tree in .tar.gz files and applied at build time, it's a pain in the ass to see what work other people have done. Debian has this problem, FreeBSD does not. CVS and SVN have branches, sources should be tracked and imported. These are all common problems in open software projects like this. Once you climb over the hurdle of getting the damn thing working, you no longer care about the install experience, but to gain additional workers and reduce your support load, this needs to be done. In any commercial endeavor (e.g. even Ubuntu and RedHat like commercializations of Linux), initial user experience is the FIRST priority, not the last priority. Am I volunteering to fix any of this? Nope, not anymore. I bought a bunch of wrt54gl's and am using openwrt which provides similar capabilities on less expensive hardware and there's a much larger active developer base. That doesn't mean I don't like B-U and the team, I think you guys are awesome. Paul --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Re: [leaf-user] pptpd current b-u problems
I got my dev environment working (limping) again.
I built a pptpd with symbols and statically linked.
It was crashing in libwrap.
I added the line "pptpd: ALL" to /etc/hosts.allow and now it works.
My libwrap hosts.deny is the default, libwrap should obviously not
be crashing. Unfortunately I didn't compile uClibc and libwrap with
symbols so I don't know what libwrap screwed up (or uClibc):
Core was generated by `./pptpd --fg'.
Program terminated with signal 11, Segmentation fault.
#0 0x0805207d in inet_pton ()
(gdb) where
#0 0x0805207d in inet_pton ()
#1 0x08052452 in getaddrinfo ()
#2 0x0804bb70 in sock_hostname (host=0xb880) at socket.c:265
#3 0x0804b560 in eval_hostname (host=0xb880) at eval.c:77
#4 0x0804a402 in host_match (tok=0xbfffee85 "PARANOID", host=0xb880)
at hosts_access.c:316
#5 0x0804a108 in list_match (list=0xbfffee84 " PARANOID", request=0xb770,
match_fn=0x804a1e5 ) at hosts_access.c:217
#6 0x0804a005 in table_match (table=0xbfffee84 " PARANOID",
request=0xb770) at hosts_access.c:173
#7 0x08049f0a in hosts_access (request=0xb770) at hosts_access.c:133
#8 0x0804968d in pptp_manager (argc=2, argv=0xbdf4) at pptpmanager.c:219
#9 0x08048745 in main (argc=2, argv=0xbdf4) at pptpd.c:420
(gdb) up
#1 0x08052452 in getaddrinfo ()
(gdb) up
#2 0x0804bb70 in sock_hostname (host=0xb880) at socket.c:265
265 if (getaddrinfo(host->name, NULL, &hints, &res0) != 0) {
(gdb) print host->name
$1 = "protempore.shockwave.org", '\0'
(gdb) print hints
$1 = {ai_flags = 3, ai_family = 2, ai_socktype = 1, ai_protocol = 0,
ai_addrlen = 0, ai_addr = 0x0, ai_canonname = 0x0, ai_next = 0x0}
(gdb) print res0
$2 = (struct addrinfo *) 0x0
(gdb) quit
The arguments being passed into getaddrinfo look, at first glance, to
be reasonable. I looked over the hints getting passed in, they look good.
There may be a generic problem dealing with ALL: PARANOID, this is the
first time I've ever actually violated a libwrap directive since my
firewall usually protects everything.
Worst case, I'll need to rebuild uclibc with symbols, but I'm not looking
forward to that, my dev environment is quite shakey thanks to compiler
mismatches. I was hoping to not do any more leaf development until the
upgrade to gcc-4.0 and a recent uclibc.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ipp2p
I thought, at one point, the ipp2p matching code was part of the build kernel, but it doesn't appear as if it's in the 2.4.32 kernel you compiled. No, the ipp2p code isn't in yet. I know Arne created some setups for it, but we still need to discuss a bit about what's the best way to implement it in buildtool. How can I help? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] ipp2p
Eric, I thought, at one point, the ipp2p matching code was part of the build kernel, but it doesn't appear as if it's in the 2.4.32 kernel you compiled. If not, this would be a nice capability for BU to carry forward. I find that the p2p traffic on my network is bogging stuff down a bit (especially the voip stuff) and rather than trying to enumerate all the voip connections, it would be easier to kick the p2p traffic back to a max of 80% of my b/w. Much thanks, Paul --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] 7 problems building B-U from scratch (entire distribution)
No clear differentiation between programs that run in the host environment and programs that need to be compiled in the target environment. Good exercise would be to build LEAF on a non x86 linux box and find all of this crap (for example, linux/scripts/mkdep (a binary) is compiled against uclibc by the target compiler, but run on the host). (Of course, I've mentioned this before... but it really needs to get fixed as our host and target environments diverge) Good luck on that one. I'd really like to see that too, but the last time I tried, I failed miserably. There are _many_ configure scripts out there that simply cannot cope with a true cross-compile - many assume that the build host will also be the target host. If you specify the appropriate options (--build and --host, if I recall correctly), they fail. So, even if we fix all the "crap" that's compiled against uclibc but runs on the build-host, it wouldn't really help much, unless somebody takes the time and cleans up those troublesome configure scripts too, and then takes the changes upstream, so the changes to the configure scripts wouldn't have to be re-applied with the next version. True, but the only way to solve this is to start, one package at a time. Some better documentation on the build environment would help (no, I'm not volunteering at the moment), perhaps what we need is a "hello world" package that works in a completely cross-compiled environment as a start? Sorry, I can't volunteer for this this year, my head is exploding with other work (in fact, apologies for the delay in replying). --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] 7 problems building B-U from scratch (entire distribution)
Eric Spakman wrote: Hi Paul, Something needs to be done so that the pthread include files are used instead of the system include files. The pthread library is part of uClibc and compiled with the initial build of buildenv. The pthread.h file is also part of uClibc and placed in the .../staging/include directory. I rebuilded the upnpd sources and looked through the source and buildtoollog, but I didn't saw a reference to my host pthread.h file. This would also be very strange, because the include path is set in the target gcc compiler which will look for headers in the .../staging/include directory. Can you point where you found the reference to the host include files? Eric You're absolutely right, I must have gotten a bad batch of crack that night, this bug report seems off. Sorry. upnpd shouldn't need lpthread at all. I think I noticed it by inspection. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] 7 problems building B-U from scratch (entire distribution)
Eric Spakman wrote: Hi Paul, (6) upnpd package needs to depend upon lpthread in sources.conf That's not needed, the pthread library is build as part of uClibc and already build in the buildenv setup. The pthread setup is only to create the package, it's no dependency of upnpd. Eric Something needs to be done so that the pthread include files are used instead of the system include files. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] 7 problems building B-U from scratch (entire distribution)
(1)
gpio fails to package
tries to package staging/lib/modules/gpio.o
file is really staging/lib/modules/2.4.32/gpio/gpio.o
--
(2)
initrd needs to be built as real root, not fakeroot because it tries to
mount loopback filesystems in order to make the packages
--
(3)
lrpstat requires java_home & java sdk to be built but is not documented
and not depended upon...
--
(4)
shorewall fails to package, cp is failing on /etc/shorewall/*, looks like
this cp happens *AFTER* "Cleaning up dir /tmp/BUILDTOOL_STAGING_"
Creating dir /tmp/BUILDTOOL_STAGING_iYSA/etc/default/
Creating dir /tmp/BUILDTOOL_STAGING_iYSA/etc/default
executing cp /home/pst/leaf/buildtool/staging/etc/default/shorewall
/tmp/BUILDTOOL_STAGING_iYSA/etc/default/shorewall
executing cp /home/pst/leaf/buildtool/staging/etc/shorewall/*
/tmp/BUILDTOOL_STAGING_iYSA/etc/shorewall
cp: omitting directory
`/home/pst/leaf/buildtool/staging/etc/shorewall/start.d'
cp: omitting directory
`/home/pst/leaf/buildtool/staging/etc/shorewall/stop.d'
Cleaning up dir /tmp/BUILDTOOL_STAGING_iYSA
Copying file /home/pst/leaf/buildtool/staging/etc/shorewall/* failed. No
such file or directory at ./buildpacket.pl line 416
main::system_exec('cp
/home/pst/leaf/buildtool/staging/etc/shorewall/* /tmp/BUIL...', 'Copying file
/home/pst/leaf/buildtool/staging/etc/shorewall/*...') called at
./buildpacket.pl line 517
main::copyBinariesToPackageStaging('HASH(0x8487bcc)',
'/home/pst/leaf/buildtool/staging') called at ./buildpacket.pl line 1150
--
(5)
pptpd is attempting to execute aclocal1.9 as part of the build
it should be depending upon the version of autotools inside the leaf
buildtool environment, not trying to use a hardcoded explicit version
in the host environment.
--
(6)
upnpd package needs to depend upon lpthread in sources.conf
--
(7)
No clear differentiation between programs that run in the host environment
and programs that need to be compiled in the target environment.
Good exercise would be to build LEAF on a non x86 linux box and find all
of this crap (for example, linux/scripts/mkdep (a binary) is compiled
against uclibc by the target compiler, but run on the host).
(Of course, I've mentioned this before... but it really needs to get fixed
as our host and target environments diverge)
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] openssl
Guys, I see folks are starting to work on the new kernel, at this point, it would be a good thing update openssl to 0.97i (or 0.98a if you're going to refresh binaries as well). More security holes. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net 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 Type = http Name = www.de.kernel.org Serverpath = /pub/linux/kernel/v2.4 Server = kernel.org envname = KERNEL_SOURCE Server = cvs-sourceforge Directory = linux Revision = HEAD Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH1 Revision = HEAD Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH2 Revision = HEAD Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH3 Revision = HEAD Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH4 Revision = HEAD Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH5 Revision = HEAD Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH6 Revision = HEAD Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH7 Revision = HEAD #connmark support Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH8 Revision = HEAD #wireless extensions v18 Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH9 Revision = HEAD Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH10 Revision = HEAD #fix ipv6 bug Server = cvs-sourceforge Directory = linux/patches envname = KERNEL_PATCH11 Revision = HEAD Server = cvs-sourceforge Directory = linux envname = LINUX_CONFIG Revision = HEAD Server = cvs-sourceforge envname = OPENSWAN_SOURCE directory = openswan revision = HEAD kbc_runtime_detect_2_4.diff.gz Description: Binary data
[leaf-devel] B-U wrap gpio patched into the kernel
Would someone with kernel privs add the wrap gpio driver that Luis did into the kernel module build process? It doesn't have to go in the default modules file, but it should be built by the leaf team instead of people having to manually do it. Paul --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] shorewall uploaded
A port of 2.2.3 to B-U's buildtool has been uploaded to devel/pstraina/shorewall. Please code review and send opinions/hate-mail, etc. Thanks, Paul --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] how is shorwall.lrp produced for Bering uClibc?
Agreed. On Mon, Apr 11, 2005 at 01:54:10PM -0700, Tom Eastep wrote: > Tom Eastep wrote: > > > > > Thanks -- I note that KP had added another change to the rules file in > > LrpN which I hadn't included in my patch. Something to do with dnsmasq... > > > > Ok -- I took a look at that and it has to do with DHCP -- I personally > think that a better approach is to set the 'dhcp' option on the local > interface in the interfaces file. > > -Tom > -- > Tom Eastep\ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ [EMAIL PROTECTED] > PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key > --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] how is shorwall.lrp produced for Bering uClibc?
Hmm, OK, there are a couple patches in here I assume you didn't want anymore... based upon your changelog saying you weren't going to set up default stuff anymore in /etc? Specifically: Tom Eastep wrote: --- /home/teastep/Shorewall/Shorewall2/interfaces 2005-04-08 10:19:05.0 -0700 +++ ./interfaces2005-04-11 13:03:40.0 -0700 @@ -204,4 +204,6 @@ ## #ZONE INTERFACE BROADCAST OPTIONS # +net eth0detect dhcp,routefilter,norfc1918 +loc eth1detect dhcp #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE and diff -au /home/teastep/Shorewall/Shorewall2/masq ./masq --- /home/teastep/Shorewall/Shorewall2/masq 2004-12-31 09:41:44.0 -0800 +++ ./masq 2005-02-02 13:10:52.0 -0800 @@ -197,4 +197,5 @@ # ### #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC +eth0 eth1 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE and diff -au /home/teastep/Shorewall/Shorewall2/policy ./policy --- /home/teastep/Shorewall/Shorewall2/policy 2005-03-30 07:03:32.0 -0800 +++ ./policy 2005-04-06 10:11:20.0 -0700 @@ -68,24 +68,24 @@ # and the size of an acceptable burst. If not specified, # TCP connections are not limited. # -# Example: +# As shipped, the default policies are: # # a) All connections from the local network to the internet are allowed # b) All connections from the internet are ignored but logged at syslog # level KERNEL.INFO. # d) All other connection requests are rejected and logged at level # KERNEL.INFO. -# -# #SOURCE DEST POLICY LOG -# # LEVEL -# loc net ACCEPT -# net all DROP info -# # -# # THE FOLLOWING POLICY MUST BE LAST -# # -# all all REJECT info -# ### #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL +loc net ACCEPT +net all DROP ULOG +# If you want open access to the Internet from your Firewall +# remove the comment from the following line. +#fw net ACCEPT + +# +# THE FOLLOWING POLICY MUST BE LAST +# +all all REJECT ULOG #LAST LINE -- DO NOT REMOVE and diff -au /home/teastep/Shorewall/Shorewall2/rules ./rules --- /home/teastep/Shorewall/Shorewall2/rules2005-03-01 10:29:15.0 -0800 +++ ./rules 2005-04-11 13:05:09.0 -0700 @@ -330,4 +330,26 @@ #ACTION SOURCEDESTPROTO DESTSOURCE ORIGINAL RATEUSER/ # PORTPORT(S)DEST LIMIT GROUP +# Accept DNS connections from the firewall to the network +# +ACCEPT fw net tcp 53 +ACCEPT fw net udp 53 +# Accept SSH connections from the local network for administration +# +ACCEPT loc fw tcp 22 +# Allow Ping To Firewall +# +ACCEPT loc fw icmp8 +ACCEPT net fw icmp8 +# +# Allow all ICMP types (including ping) From Firewall +# +ACCEPT fw loc icmp +ACCEPT fw net icmp +# +# Bering specific rules: +# allow loc to fw udp/53 for local/caching DNS servers to work +# allow loc to fw tcp/80 for weblet to work +ACCEPT loc fwudp 53 +ACCEPT loc fwtcp 80 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE and --- /home/teastep/Shorewall/Shorewall2/zones2005-02-02 07:39:59.0 -0800 +++ ./zones 2005-02-02 13:10:52.0 -0800 @@ -11,15 +11,9 @@ # OVERLAPPING ZONES DEFINED THROUGH /etc/shorewall/hosts. # # See http://www.shorewall.net/Documentation.htm#Nested -# -# Example zones: # -#You have a three interface firewall with internet, local and DMZ interfaces. -# -# #ZONE DISPLAY COMMENTS -# net InternetThe big bad Internet -# loc Local Local Network -# dmz DMZ Demilitarized zone. -# -#ZONE DISPLAY COMMENTS +#ZONE DISPLAY COMMENTS +netNet Internet +locLocal Local networks +#dmz DMZ Demilitarized zone #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE The stuff in shorewall.conf and to start and stop I assumed were ok to keep. Which way do you want me to go? Blank, or KP-style defaults? ---
Re: [leaf-devel] how is shorwall.lrp produced for Bering uClibc?
Tom Eastep wrote: Paul Traina wrote: Actually, that's exactly what I was suggesting we do as well, although there's not consensus about it. Let me take a whack at it this afternoon and see how cleanly I can do it. If people like the results, great, if not, no worries. The biggest problem with the way I was /intending/ to do it was that I was going to do it inside the Bering uClibc buildtool environment, and B-U is not the only lrp based distribution out there. I'll see if I can make it generic-LEAF friendly. You can certainly use the 'install.sh' script as a basis for building and populating the directory tree. That's what is done when I build the .rpm. Note the PREFIX environmental variable -- allows installing in a directory other than /. -Tom Tom, Would you be willing to refresh the lrp version /etc files to match what you believe they should be? I know you changed your policy on template stuff to reduce your support load, but the lrp versions don't represent that change. I've made some guesses, but... are you the maintainer of the lrp versions of these files, or is KP? Your install script assumes it runs as root, which may not be correct if we're using PREFIX. Currently I'm using fakeroot as a wrapper to avoid dealing with the -o owner -g group arguments in install. I was thinking of patching your install.sh script to something like: if using prefix and `id -u` != 0 OWNERSHIP="" else OWNERSHIP="-o $OWNER -g $GROUP" fi and then replacing the explicit stuff with $OWNAGE, but I didn't want to have to manage that patch outside of your environment. I'll send you a patch along shortly showing you the differences between your LRP and what I am currently generating. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] how is shorwall.lrp produced for Bering uClibc?
Actually, that's exactly what I was suggesting we do as well, although there's not consensus about it. Let me take a whack at it this afternoon and see how cleanly I can do it. If people like the results, great, if not, no worries. The biggest problem with the way I was /intending/ to do it was that I was going to do it inside the Bering uClibc buildtool environment, and B-U is not the only lrp based distribution out there. I'll see if I can make it generic-LEAF friendly. Paul --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] how is shorwall.lrp produced for Bering uClibc?
I don't see it in buildtool? Tom's got some changes in CVS I want to play with to test UPnP integration, and I wanted to see about making some local changes. I realize shorewall isn't compiled per-se, but shouldn't it be under buildtool anyway so we can patch in local changes? Confused... Paul --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] buildtool not clean enough yet...?
Warning:The symlink from /lib/ld-uClibc.so.0 --> /home/pst/LEAF/buildtool/staging/lib/ld-uClibc.so.0 does not exist, this may cause problems with some configure scripts that try to run a compiled program Do we still need this link? If this is the case, then how can buildtool do cross-arch targeting? We shouldn't be running any target-compiled executables on the host environment. If someone can point me at the program/issue that was causing the problem, I'll take a peek at fixing it. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] ANN: UPnP support for Bering-uClibc (repost)
Mike asked me to repost this to leaf-devel as well. I'll also introduce myself a bit more. I'm an ex-router software developer (if you're desperately interested, google me) who really doesn't want to spend his retirement working on software routers, but hates the state of the art in consumer grade routers you can buy off the shelf (if they just hand dnsmasq and support for multiple-ip-addresses when NATing, I wouldn't be here at all). I feel like a crack whore (no offense to crack whores, since this is even lower than that...) for even considering turning on UPnP, much less porting it over to uClibc, but I hate than static configurations for hosts. We shouldn't ever have to think about IP address allocation in this day and age, and the thought of putting in static DNAT rules so that I can download stuff with bittorrent was making me unhappy. Other than that, well, here's a port of UPnP IGD services for Bering-uClibc. I've tried to make integration with Shorewall as simple as possible, if you have any questions, I'll try to answer them. Original Message Subject: [leaf-user] ANN: UPnP support for Bering-uClibc Date: Wed, 6 Apr 2005 09:24:21 -0700 From: Paul Traina <[EMAIL PROTECTED]> To: leaf-user@lists.sourceforge.net Hi folks, I just wanted to introduce myself and let people know that I've uploaded Universal Plug-N-Play Internet Gateway Device support for Bering uClibc. This is a port of the project at linux-igd.sourceforge.net with some help for integrating with Shorewall. UPnP IGD services provide firewall and NAT traversal support for applications that need bidirectional connection establishment (e.g. peer-to-peer applications like audio & video chatting with most IM programs, or bittorrent/gnutella type programs). Documentation on how to install and use should be available in the Bering uClibc users guide. Two warnings: 1) This implementation supports one upstream/external interface and one "local" interface. You can have more interfaces on your router but only one will listen to UPnP control points (clients) and only one gets firewall/NAT traversal rules. 2) Any time you allow hosts to automatically add rules to your firewall configuration, you're potentially asking for a security issue. Please take care to trust all the hosts on your internal interface, or create some policy in front of the UPnP auto-generated rules to disallow any unacceptable behavior. See the documentation in the Bering uClibc users guide for more detail. Installation support, bug reports, et al should come to me and please cc the leaf-user mailing list. Paul --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] why do we install non-build binaries in bt_staging_dir?
Sigh, I forgot, I already asked this question in Feburary, I just didn't like the answer then so I forgot it... K.-P. Kirchdörfer wrote: > The long term idea by Arne or Martin has been to chroot into staging > and run our own distro from there. > I've asked myself, but then with all the problems with some packages > leaking on some machines, I understood it may help in the long run. I happen to disagree on this one, but I'll follow their lead... I think that it's more important to keep staging dir clean, and if you want to test-run a distro (assuming you have the same CPU), you could/should just have a small script that untar's all the LRPs into a chroot jail. That way you also test to make sure the .lrp's were packaged correctly (you remembered to include all the files the router needs). I feel that the staging directory really should be reserved for the toolchain and supporting libraries (i.e. include files and shared libraries) required by other packages. I've been building both debugging and non-debugging versions of upnpd, and I live in fear that I didn't sanitize staging_dir and clean out the old libraries. It's much easier to just rm -rf target_dir/upnpd and not worry. It also means I can have separate versions of upnpd in the tree and not have them install crap over each other. Minor point, but just wanted to share my two cents. I'll follow the current consensus of the group. Paul p.s. has anyone tested how "clean" our build environment really is? I've got some worries about include file and library file cross-polination from the host build environment...but I haven't dug into the gcc spec file for the cross compiler to make sure it never includes anything from /usr/include and LD never looks at /usr/lib. can buildtool run under freebsd to produce a LEAF binary? can buildtool run on a powerpc to produce an i386 binary? --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] best way to keep "new" files that are part of an lrp?
In the upnpd package, I create several new files that are part of the package and are LEAF environment specific. At first, I was keeping them in a patch file, but that seems like I'm mis-using cvs. I think it would be best to actually keep them as individual source files right in CVS so people can easily use CVS to see diffs, merge, update, etc... upnpd/ buildtool.cfg buildtool.mk libupnp-1.2.1a.tar.gz -upstream libupnp-1.2.1a-1.diff.gz-leaf patch upnpd_cvs20050215.tar.gz-upstream upnpd_cvs20050215-1.diff.gz -leaf patch etc/-new files init.d/ upnpd default/ upnpd shorewall/ action.allowinUPnP action.allowoutUPnP action.forwardUPnP start.d/ upnpd_start First off, would it be bad form to do it this way? Secondly, if I do, am I stuck creating a line in buildtool.cfg for every single file, or could I just specify a directory? Server = cvs-sourceforge Revision = HEAD Directory = upnpd Thanks, and sorry for flooding everyone with all of these newbie developer questions, I just want to make things as clean as possible and not crap all over the project. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] why do we install non-build binaries in bt_staging_dir?
I certainly understand why we copy the toolchain, libraries, and include files into bt_staging_dir, but it seems somewhat bogus that we're doing so for end-binaries (i.e. things that nothing else is ever going to depend upon)... Is there a reason for this? It seems that there was a change in the charter for bt_staging_dir at some point (the documentation discusses that it's just for the toolchain elements, but all the example buildtool.mk files I've seen copy binaries and configuration files in there that are not part of the toolchain). I realize I'm just talking about one line in a buildtool.mk file, but it just seems curious that we're polluting what would otherwise be a clean and hopefully idempotent toolchain directory. Thanks, Paul --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] adding files to /etc/shorewall from a different package?
Hi, I'm packaging upnpd.lrp. I'd like to add a few user defined actions to shorewall to make integrating leaf and shorewall a bit easier. I'm wondering what the best way to do this is... currently I'm having the user add: /etc/shorewall/action.allowinUPnP /etc/shorewall/action.allowoutUPnP /etc/shorewall/action.forwardUPnP /etc/shorewall/start.d/upnpd_start modify /etc/shorewall/modules (add ipt_owner) modify /etc/shorewall/actions (register the actions) I'd like to just include these files right in the upnpd.lrp file. 1) Since I'm a .lrp file, should the new files be added to /usr/share/shorewall? The new files aren't really meant for user consumption or manipulation 2) What's the best way to insure that upnpd.lrp "owns" these files when the user does a backup of either shorewall or upnpd? It would be evil for me to modify any of shorewalls files or package config excludes? Paul --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
