ipcop-devel Mailing List for IPCop Firewall

Nardus Geldenhuys wrote:
> Ok. I don't now if I should mention this. But /dev/ppp does not get created.

Since you asked the other day:
a way to contribute would be to figure out why and send a diff fixing it 
  ;-)


Olaf

-- 

A weizen a day helps keep the doctor away.

Ok. I don't now if I should mention this. But /dev/ppp does not get created.
This happens on the latest ipcop 1.9

Ivan, Gilles,

>> I see you disabled fcdsl in your latest commits.  Was that on purpose or
> is it
>> because it doesn't build with the latest changes to the kernel/toolchain?

because they currently do not build, because of API changes in the kernel.

>> I remember I did something to the fcdsl* scripts to make them build with
> CLFS's
>> toolchain which is the same as the LFS-dev toolchain.  Should I look into
>> that?

> There is some 2.4.24 changes.
> Some patches are available on gentoo repository
> http://piotrkosoft.net/pub/mirrors/gentoo-portage/net-dialup/fcdsl/files/


I also found this (by accident) http://opensuse.foehr-it.de/

But since I probably will not have time enough the coming days, I wanted 
to commit toolchain first, so we can all have a look at it.
If someone has fcdsl* modifications to make them build again: go for it ;-)


Olaf

-- 

A weizen a day helps keep the doctor away.

----- Original Message ----- 
From: "Ivan Kabaivanov" <ch...@ya...>
To: <ipc...@li...>
Sent: Wednesday, February 27, 2008 11:26 PM
Subject: [IPCop-devel] fcdsl


> Olaf,
>
> I see you disabled fcdsl in your latest commits.  Was that on purpose or
is it
> because it doesn't build with the latest changes to the kernel/toolchain?
If
> it's because of kernel/toolchain, I'll take a look at my (uncommitted and
> never to be committed) changes when I was considering a move towards CLFS.
I
> remember I did something to the fcdsl* scripts to make them build with
CLFS's
> toolchain which is the same as the LFS-dev toolchain.  Should I look into
> that?
>
> IvanK.
>
There is some 2.4.24 changes.
Some patches are available on gentoo repository
http://piotrkosoft.net/pub/mirrors/gentoo-portage/net-dialup/fcdsl/files/

Gilles

----- Original Message ----- 
From: Nardus Geldenhuys
To: ipc...@li...
Sent: Wednesday, February 27, 2008 1:32 PM
Subject: [IPCop-devel] How can I contribute.


> Howzit
>
> How can I contribute. Build the latest SVN version and it seems to work
nicely.
> Now the next step, what can I do to help ?
>
Thanks for the offer.

Where are you skilled or have a particular knoledge?

Gilles

Olaf,

I see you disabled fcdsl in your latest commits.  Was that on purpose or is it 
because it doesn't build with the latest changes to the kernel/toolchain?  If 
it's because of kernel/toolchain, I'll take a look at my (uncommitted and 
never to be committed) changes when I was considering a move towards CLFS.  I 
remember I did something to the fcdsl* scripts to make them build with CLFS's 
toolchain which is the same as the LFS-dev toolchain.  Should I look into 
that?

IvanK.

Howzit

How can I contribute. Build the latest SVN version and it seems to work
nicely. Now the next step, what can I do to help ?

Cheers

Nardus

On Friday 22 February 2008 15:07, Olaf Westrik wrote:
> Gilles Espinasse wrote:
> > Isn't that mostly already done?
> > It is no more compiled unless you ask for that.
>
> true, but I was thinking about removing completely.
> This week I've spend several hours looking through most of the lfs/*
> files for version updates :-S
> So I'm just happy with every file that goes ;-)
>
>
> Olaf


Olaf,

I did play with distcc some months ago -- I had three very fast machines 
sharing the load and there was absolutely no improvement.

However, I agree with Gilles -- distcc is useful, not for everybody, but for 
some.  Just because people with fast x86 boxes don't see any improvement 
doesn't mean that people with a farm of slow machines will not see a 
measurable decrease in compile time.  As a matter of fact I've been thinking 
of running a x86->sparc cross compiler on my fast quad-core machine to help 
with sparc compiles.

I think as things stand currently, distcc not being built and used by default, 
we are pretty flexible.

IvanK.

Gilles Espinasse wrote:

>> This week I've spend several hours looking through most of the lfs/*
>> files for version updates :-S
>> So I'm just happy with every file that goes ;-)
>>
> Fully understand, I know that.

the doc/Packages-monitoring-urls is a big help, but there is just a 
whole lot of file to monitor. I have yet to look into CPAN files.


> We could too remove as86 and mbr packages and use syslinux mbr/mbr.bin to
> make usb key bootable.

ok, I'll try and build usb (next week).


Olaf

-- 

A weizen a day helps keep the doctor away.

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "IPCop devel" <ipc...@li...>
Cc: "Gilles Espinasse" <g....@fr...>
Sent: Friday, February 22, 2008 9:07 PM
Subject: Re: [IPCop-devel] distcc


> Gilles Espinasse wrote:
>
> > Isn't that mostly already done?
> > It is no more compiled unless you ask for that.
>
> true, but I was thinking about removing completely.
> This week I've spend several hours looking through most of the lfs/*
> files for version updates :-S
> So I'm just happy with every file that goes ;-)
>
Fully understand, I know that.

We could too remove as86 and mbr packages and use syslinux mbr/mbr.bin to
make usb key bootable.

Gilles

Gilles Espinasse wrote:

> Isn't that mostly already done?
> It is no more compiled unless you ask for that.

true, but I was thinking about removing completely.
This week I've spend several hours looking through most of the lfs/* 
files for version updates :-S
So I'm just happy with every file that goes ;-)


Olaf

-- 

A weizen a day helps keep the doctor away.

Selon Olaf Westrik <wei...@ip...>:

> Ivan Kabaivanov wrote:
>
> > ccache already gives dramatic improvement -- on my build sparc, a reduction
> > from 8 hours with a clean ccache down to 3 hours with a populated ccache!
> > Beat that, distcc :-)
> >
> > I'm in favor of dropping distcc altogether.
>
>
> This was some (long) time ago, but still not to late ;-)
>
> To summarize:
>
> * little benefit, especially when ccache kicks in
> * defeats the idea of having a cleanly build toolchain
> * not that easy to get working (I've only got it working once)
>
>
> Anybody against dropping distcc ?
>
>
> Olaf
>
Isn't that mostly already done?
It is no more compiled unless you ask for that.
As experience has show the gain is very limited unless you have a set of slow
machines, I agree we could remove everything distcc related.

I have no planning building a farm of slow alpha servers and use distcc to speed
the build.

For any other arch than alpha, having a better hardware would have far more gain
than using distcc.

More gain could be reached with handling dependencies and reusing already build
package, previously saved and restored on a new compilation.

I find no time yet to work on packaging but this should come soon.
When a package is not changed, it would be great if we could not recompile that
part, particulary for the few ones that take the most time and are very
infrequently changed like gcc/glibc.

Gilles

Ivan Kabaivanov wrote:

> ccache already gives dramatic improvement -- on my build sparc, a reduction 
> from 8 hours with a clean ccache down to 3 hours with a populated ccache! 
> Beat that, distcc :-)
> 
> I'm in favor of dropping distcc altogether.


This was some (long) time ago, but still not to late ;-)

To summarize:

* little benefit, especially when ccache kicks in
* defeats the idea of having a cleanly build toolchain
* not that easy to get working (I've only got it working once)


Anybody against dropping distcc ?


Olaf

-- 

A weizen a day helps keep the doctor away.

For some time I experienced problems on a machine with lots of HW 
features. initramfs always missed something.
So instead of making a long (too long?) parms list, write all initramfs 
modules to a file and feed that to mkinitramfs.

Added parted option when installing, like the 1.4 fdisk option, this 
give the option to do your own parted thing.
Don't be fooled though, the partioning scheme must still match! Since I 
do not fully know yaboot, silo & co. I am hoping Ivan will take of 
parted option for those architectures.


Olaf

-- 

A weizen a day helps keep the doctor away.

FWIW if IPCop ever adds a failover-mode, where you can have multiple IPCop boxes on one LAN for redundancy (like CARP in 
OpenBSD), may I suggest upgrading the DHCP server to support primary and secondary DHCP servers:

    Failover with ISC DHCP
    http://www.madboa.com/geek/dhcp-failover/

TIA for listening ....

--
Angus Scott-Fleming
GeoApps, Tucson, Arizona
1-520-290-5038
+-----------------------------------+

Feature Requests item #1897488, was opened at 2008-02-19 21:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1897488&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface Improvements (example)
Group: Next major version
Status: Open
Priority: 5
Private: No
Submitted By: kurt romkey (no3fan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add ons

Initial Comment:
 I really  like your product and i use and recommend it to others. Just one thing i'd like to see.
  If your going to link to add on's, would it be possible to make sure that they interface with your product before listing them? I really like the idea of programs like banish, a program that i think you should incorporate into your next release, i just am  less than  pleased with the issues i have had trying to install it. i realize that its not YOUR issue, just would prefer to see approved addons that actually install listed instead of addons that do NOT install. 
JMHO, thanks  in advance.


K

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1897488&group_id=40604

Bugs item #1897472, was opened at 2008-02-19 18:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1897472&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Danno (danielbrown)
Assigned to: Nobody/Anonymous (nobody)
Summary: Prefetch svn 2 fails on snort and grub

Initial Comment:
I'm getting error 404's in the log when I try to build. 

Feb 20 01:08:45: Building grub 
-e grub	 Download: http://http.us.debian.org/debian/pool/main/g/grub/grub_0.97-29.diff.gz
http://http.us.debian.org/debian/pool/main/g/grub/grub_0.97-29.diff.gz:
17:08:45 ERROR 404: Not Found.

Build died here, but prefetch also failed on snort and md5 failed on the first entry on the list. I forget the name of it though. I am downloading through an IPCop 1.4.18 with Copplus installed and intrusion detection running. Is this problem on my end or is it an issue for you guys to look into?

Thank you!
-Dan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1897472&group_id=40604

ch...@us... wrote:
> Revision: 1109
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=1109&view=rev
> Author:   chepati
> Date:     2008-02-17 23:00:28 -0800 (Sun, 17 Feb 2008)
> 
> Log Message:
> -----------
> --disable-debugfs needed for yaboot and quik (ppc).  Not 100% sure if we can also use --disable-swapfs (disable old legacy PPC/68k byte swapping filesystems) as HFS might need it???  Better leave it in for now.
> 

I meant debugfs is needed for ppc.  So don't disable it.

IvanK.

Now I'm studying how to build the ipcop 1.4 without any modifications
first, and then, i'll put the addons in my box.

Thanks Again!




On Feb 16, 2008 11:27 AM, Gilles Espinasse <g....@fr...> wrote:
>
> ----- Original Message -----
> From: "Samuel Honorato" <sam...@gm...>
> To: "Gilles Espinasse" <g....@fr...>
> Cc: "IPCOP devel" <ipc...@li...>
> Sent: Saturday, February 16, 2008 2:03 PM
> Subject: Re: [IPCop-devel] remastering ipcop 1.4.18
>
>
> ...
> > For example, if i need to create a ipcop cd with Advanced Proxy and URL
> filter
> >
> Then you should copy the modified code inside a cvs tree and rebuild.
> Adjust src/ROOTFILES as explained in "how to compile additional code"
>
> I add some words about the interfaces that add-ons should use on the
> Building how-to.
>
> Gilles
>
>

----- Original Message ----- 
From: "Samuel Honorato" <sam...@gm...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Saturday, February 16, 2008 2:03 PM
Subject: Re: [IPCop-devel] remastering ipcop 1.4.18


...
> For example, if i need to create a ipcop cd with Advanced Proxy and URL
filter
>
Then you should copy the modified code inside a cvs tree and rebuild.
Adjust src/ROOTFILES as explained in "how to compile additional code"

I add some words about the interfaces that add-ons should use on the
Building how-to.

Gilles

I'll search more about that!


and...
Olaf and Gilles, Thanks !!


For example, if i need to create a ipcop cd with Advanced Proxy and URL filter


On Feb 16, 2008 10:23 AM, Gilles Espinasse <g....@fr...> wrote:
>
>
> ----- Original Message -----
> From: "Samuel Honorato" <sam...@gm...>
> To: <ipc...@li...>
> Sent: Saturday, February 16, 2008 12:56 PM
> Subject: [IPCop-devel] remastering ipcop 1.4.18
>
>
> > Hello everyone! Good day!
> >
> > I'm trying to remaster a new ipcop cd, with some extra addons that I
> > like, but I need to know. How can I do that?
> >
> > Readind the documentation, i found "Building IPCop 1.4.x", but i dont
> > see nothing about other ipcop addons, just the system rebuild is
> > covered by this doc.
> >
> > Can someone help me?
> >
> You could look at the add-ons installation scripts.
> I should say I haven't find the time to look at.
>
> There is basically two interfaces defined for add-ons:
> - add-on language files have to be placed on /var/ipcop/addon-lang and cache
> is updated with execution of
> /usr/bin/perl -e "require '/var/ipcop/lang.pl'; &Lang::BuildCacheLang"
>
> - backup
> Unfortunately floppy backup and web/usbkey backup behave differently
> With web/usbkey backup, each add-on could add his own include.<add-on> and
> exclude.<add-on> files in /var/ipcop/backup.
> With floppy backup, you should modify include.user to add new files (if they
> are not yet include by standard rules).All /var/ipcop (but a few files) are
> include in backup.
>
> With web/usbkey backup, using the --verbose option, you see the list of
> files include in backup.
> With floppy backup, the list is always displayed.
>
> With the GUI menu, this is all hacking, no interface.
> The only thing you know is that we never replace header.pl and always patch
> it when needed.
> You would better know looking at some add-ons.
>
>

----- Original Message ----- 
From: "Samuel Honorato" <sam...@gm...>
To: <ipc...@li...>
Sent: Saturday, February 16, 2008 12:56 PM
Subject: [IPCop-devel] remastering ipcop 1.4.18


> Hello everyone! Good day!
>
> I'm trying to remaster a new ipcop cd, with some extra addons that I
> like, but I need to know. How can I do that?
>
> Readind the documentation, i found "Building IPCop 1.4.x", but i dont
> see nothing about other ipcop addons, just the system rebuild is
> covered by this doc.
>
> Can someone help me?
>
You could look at the add-ons installation scripts.
I should say I haven't find the time to look at.

There is basically two interfaces defined for add-ons:
- add-on language files have to be placed on /var/ipcop/addon-lang and cache
is updated with execution of
/usr/bin/perl -e "require '/var/ipcop/lang.pl'; &Lang::BuildCacheLang"

- backup
Unfortunately floppy backup and web/usbkey backup behave differently
With web/usbkey backup, each add-on could add his own include.<add-on> and
exclude.<add-on> files in /var/ipcop/backup.
With floppy backup, you should modify include.user to add new files (if they
are not yet include by standard rules).All /var/ipcop (but a few files) are
include in backup.

With web/usbkey backup, using the --verbose option, you see the list of
files include in backup.
With floppy backup, the list is always displayed.

With the GUI menu, this is all hacking, no interface.
The only thing you know is that we never replace header.pl and always patch
it when needed.
You would better know looking at some add-ons.

Samuel Honorato wrote:

> Can someone help me?

Read the "compile additional code" part.


Olaf

-- 

A weizen a day helps keep the doctor away.

Hello everyone! Good day!

I'm trying to remaster a new ipcop cd, with some extra addons that I
like, but I need to know. How can I do that?

Readind the documentation, i found "Building IPCop 1.4.x", but i dont
see nothing about other ipcop addons, just the system rebuild is
covered by this doc.

Can someone help me?

Ivan Kabaivanov wrote:

> speaking from memory, it's the -I option (specify NIC interface) that someone 
> wanted.  Was it David Studeman or Harry Goldschmitt?

Probably Harry, he made a fairly good request/description way back in 
2004: http://marc.info/?l=ipcop-devel&m=108603556932267&w=2


> [chroot-i486] root:/$ /usr/bin/ping-iputils
> Usage: ping [-LRUbdfnqrvVaA] [-c count] [-i interval] [-w deadline]
>             [-p pattern] [-s packetsize] [-t ttl] [-I interface or address]
>             [-M mtu discovery hint] [-S sndbuf]
>             [ -T timestamp option ] [ -Q tos ] [hop1 ...] destination
> 
> I suppose we can drop inetutils' ping in favor of iputils' one.

Not that it is vital dropping 1 ping, saves ~ 30 KB.
It is the number of packages we are using / monitoring that worries me.
Looking at Packages-monitoring-urls I see some 200 packages, which is 
fine if we are 20+ developers, but since we are not it's worth getting 
rid of some.


Olaf

-- 

A weizen a day helps keep the doctor away.