ipcop-devel Mailing List for IPCop Firewall

----- Original Message ----- 
From: "evil" <ev...@gm...>
To: <ipc...@li...>
Sent: Wednesday, June 30, 2010 7:03 PM
Subject: Re: [IPCop-devel] IPCop-devel Digest, Vol 49, Issue 7


>   Hi Gilles,
>
> Maybe I have the right hint for you regarding the shared lib reduction
> problem with parted:
>
> I think you have to set the right flag in .configure:
>
> 1.5 Building GNU Parted
> =======================
>
> If you want to compile GNU Parted, this is generally done with:
>
>       $ ./configure
>       $ make
>
>
>
> `--disable-shared'
>       turns off shared libraries.  This may be necessary for use with old
>       versions of GNU libc, if you get a compile error about a "spilled
>       register".  Also useful for boot/rescue disks.
>
No that will disable shared lib build and parted will be statically linked
using libparted.a.
As we use parted and partprobe, that's slightly bigger than shared lib only
copied and stripped.
(I am not sure partprobe work at it should, that's another story)

The issue should be in the way mklibs work.

Gilles

  Hi Gilles,

Maybe I have the right hint for you regarding the shared lib reduction 
problem with parted:

I think you have to set the right flag in .configure:

1.5 Building GNU Parted
=======================

If you want to compile GNU Parted, this is generally done with:

      $ ./configure
      $ make



`--disable-shared'
      turns off shared libraries.  This may be necessary for use with old
      versions of GNU libc, if you get a compile error about a "spilled
      register".  Also useful for boot/rescue disks.




That means you have to edit your ./trunk/lfs/parted  :

# syntax has to be changed to be able to create part 1 as hfs and part 3 
as ext2
     # let fs compiled in for now (no --disable-fs) as it breaks several 
tests
     cd $(DIR_APP) && ./configure    --prefix=/usr \
                     --disable-device-mapper \
                     --disable-pc98 \
                     --without-readline \
                     --disable-nls \
                     --disable-debug \
                     --disable-shared 
<-------------------------------------Add this here!
     # to change compilation in a verbose mode --disable-silent-rules

Maybe I am wrong, but I could test it at coming weekend in my testbed.

Br,
Mike


>> I get the same fault. Removing mv -f libparted.a libparted_pic.a
>> from lfs/parted fixes it.
>>
>> Seems like libparted is unhappy after the size reduction. So we either
>> need to find/fix the cause or not shrink libparted.
>>
>>
>> Olaf
>>
> Ok
> Remove the "mv -f libparted.a libparted_pic.a" now or I will fix that tonight.
> I will try to understand what happen but shared lib reduction look a bit of
> vodoo. If that doesn't work, it may be hard to understand why.
>
>
> Gilles
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Filtered-With-Copfilter: Version 0.84beta4 (ProxSMTP 1.8)
Copfilter-Virus-Scanned: ClamAV 0.96.1/11293/Wed Jun 30 14:43:31 2010
by Markus Madlener @ http://www.copfilter.org

On Wednesday 30 June 2010 19:37, Guenter wrote:
<big snip>
> Furthermore many of us would of course also really like to see your
> WLAN-AP addon going into distro.
</snip>
  ++1  for that!  So Olaf, how about it, please.

Cheers,
Glen (your acting, unpaid, assistant list admin)

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

> Am 2010-06-26 20:30, schrieb Achim Weber:
>
> > With current rev. #4683 I get a Segmentation fault in partprobe. So
> currently
> > (at least my build) is broken at the moment, I can't install as the
> installer
> > is not able to partition my harddisk.
> > I did re-check with rev. #4678 (the one before the parted changes), this
> rev. is
> > installable at my testmachine.
> >
> > -------------------------------------
> > Running command: /usr/bin/disk-partition.sh x86 sda 574 1054 onedisk
> > error partitioning /dev/sda
> > Make partitions failed
> > -------------------------------------
> > [install-i686] :/ $ /usr/sbin/partprobe /dev/sda
> > Segmentation fault
> > [install-i686] :/ $
> > -------------------------------------
> >
> > Is this only my build?
> >
> > My toolchain is compiled with rev. #4674.
>
> I get the same fault. Removing mv -f libparted.a libparted_pic.a
> from lfs/parted fixes it.
>
> Seems like libparted is unhappy after the size reduction. So we either
> need to find/fix the cause or not shrink libparted.
>
>
> Olaf
>
Ok
Remove the "mv -f libparted.a libparted_pic.a" now or I will fix that tonight.
I will try to understand what happen but shared lib reduction look a bit of
vodoo. If that doesn't work, it may be hard to understand why.


Gilles

Hi Olaf,
Am 30.06.2010 09:14, schrieb Olaf Westrik:
>> Anyway I see that Ipcop tends more and more to only target very vew
>> mimimalistic enthusiasts rather than look for a broader user community
>> with their wishes and needs.
>
> I have to disagree there.
>
> Surely we do not and can not make everybody happy, take 100 users and
> you come up with 1000+ differing wishes.
that's ok, and understandable.

> But if we were to target only the minimalists, we would not care about
> PXE installation, serial console, Proxy, DDNS, IPsec, OpenVPN etc. etc.
> etc. and simply stick with iptables only.
ok, I agree. But then please lets talk a bit about some other small 
enhancements which would make a lot of users happy while they do not 
cost much bytes to add (where I ask here only for stuff which is 
kernel/system related, and therefore harder to maintain from addon side):

1. add the msr kernel module (needed for flashrom in order to do bios 
updates, ~2.6kb):
-rw-r--r-- 1 root root 2610 2010-06-12 06:53 
/lib/modules/2.6.32-1/kernel/arch/x86/kernel/msr.ko.gz

2. add parallel and usb printer drivers (~33kb). I know about your 
opinion that such things like a print server do not belong to a 
firewall, and in general I agree with that. Nevertheless I see the other 
point from home user side that they want to save energy costs, and many 
print servers suck more power than f.e. an Alix board. I dont want to 
add such big things like cups which I see as total overkill, but I have 
a very small lpd daemon (binary of ~20kb only) which works great, and 
some friends use this already for about two years on 1.4.x (when I first 
packed together this addon), and now on 1.9.x. It works fine with 
parallel and usb based printers, and I have it even running with a cheap 
usb2par adapter (China 2.20€) connected to an Alix board. The kernel 
modules needed for this are:
tar tvf lpdrivers-2.6.32-1.tar.gz
-rw-r--r-- root/root      9807 2010-05-30 23:40 
lib/modules/2.6.32-1/kernel/drivers/parport/parport.ko.gz
-rw-r--r-- root/root     10826 2010-05-30 23:40 
lib/modules/2.6.32-1/kernel/drivers/parport/parport_pc.ko.gz
-rw-r--r-- root/root      7075 2010-06-04 03:51 
lib/modules/2.6.32-1/kernel/drivers/usb/class/usblp.ko.gz
-rw-r--r-- root/root      5139 2010-06-10 04:01 
lib/modules/2.6.32-1/kernel/drivers/char/lp.ko.gz

3. add the missing Perl modules to get Archive::Zip working (~6kb 
compressed):
tar tvf lib.tgz
drwxr-xr-x root/root         0 2010-06-30 11:03 List/
drwxr-xr-x root/root         0 2010-06-30 11:03 List/Util/
-r--r--r-- root/root      1006 2010-06-30 11:03 List/Util/XS.pm
-r--r--r-- root/root      1319 2010-06-30 11:03 List/Util/PP.pm
-r--r--r-- root/root      6698 2010-06-30 11:03 List/Util.pm
drwxr-xr-x root/root         0 2010-06-30 11:03 Scalar/
drwxr-xr-x root/root         0 2010-06-30 11:03 Scalar/Util/
-r--r--r-- root/root      2228 2010-06-30 11:03 Scalar/Util/PP.pm
-r--r--r-- root/root      8059 2010-06-30 11:03 Scalar/Util.pm

Ok, these are the few kernel/system dependent things which I would find 
useful to have in main distro, and none of these is a security risk in 
any way, nor do they add any maintainance work.
Furthermore many of us would of course also really like to see your 
WLAN-AP addon going into distro.
Another little thingy which many ask for is WakeOnLan; I have already a 
basic version ready ported from your addon (~7kb compressed) which is 
only the cgi - pure Perl solution, no depency on external tools like 
etherwake (I posted this solution already some longer time ago to you 
privately). I have also added an import capability of the DHCP static 
leases to avoid double maintainance of machine MAC lists. I think this 
wakeonlan.cgi should really go into distro.

Finally I say a big thanks to all Ipcop developers for their constant 
hard work in order to make a good safe new version of the Ipcop firewall.

greets, Gün.

Am 30.06.2010 09:11, schrieb Olaf Westrik:
> For the IPCop ISO, it is easy to add and having sha1sum would give the
> addon creators to pick and use either md5 or sha1.
>
>
>> For sha1 inclusion (with perl code glue), I am not personally opposed.
>
> I'll add the sha1sum binary and the perl code.
thanks Olaf!

Gün.

Am 2010-06-26 20:30, schrieb Achim Weber:

> With current rev. #4683 I get a Segmentation fault in partprobe. So currently
> (at least my build) is broken at the moment, I can't install as the installer
> is not able to partition my harddisk.
> I did re-check with rev. #4678 (the one before the parted changes), this rev. is
> installable at my testmachine.
>
> -------------------------------------
> Running command: /usr/bin/disk-partition.sh x86 sda 574 1054 onedisk
> error partitioning /dev/sda
> Make partitions failed
> -------------------------------------
> [install-i686] :/ $ /usr/sbin/partprobe /dev/sda
> Segmentation fault
> [install-i686] :/ $
> -------------------------------------
>
> Is this only my build?
>
> My toolchain is compiled with rev. #4674.

I get the same fault. Removing mv -f libparted.a libparted_pic.a
from lfs/parted fixes it.

Seems like libparted is unhappy after the size reduction. So we either 
need to find/fix the cause or not shrink libparted.


Olaf

Am 2010-06-25 20:34, schrieb Guenter:

> Anyway I see that Ipcop tends more and more to only target very vew
> mimimalistic enthusiasts rather than look for a broader user community
> with their wishes and needs.

I have to disagree there.

Surely we do not and can not make everybody happy, take 100 users and 
you come up with 1000+ differing wishes.

But if we were to target only the minimalists, we would not care about 
PXE installation, serial console, Proxy, DDNS, IPsec, OpenVPN etc. etc. 
etc. and simply stick with iptables only.


Olaf

Am 2010-06-28 23:41, schrieb Gilles Espinasse:

> I agree we should more use sha<x>  on our building system in the futur, but
> probably more use gpg signatures to validate sources packages when
> available.

MD5 is fine for our purpose, testing the correct download/version of a 
archive.
But since several source archives have SHA1 instead of MD5 published, 
adding SHA (in addition to MD5) to our building system would safe us 
some time and effort when doing a package upgrade.

Something to put on the list for later.

For the IPCop ISO, it is easy to add and having sha1sum would give the 
addon creators to pick and use either md5 or sha1.


> For sha1 inclusion (with perl code glue), I am not personally opposed.

I'll add the sha1sum binary and the perl code.


Olaf

Am 2010-06-29 10:25, schrieb Mark Oswald:
> Hi,
> please update usb-modeswitch to 1.1.3
>
>
> file:
> trunk/lfs/usb-modeswitch
>
> line 35
> -VER        = 1.1.1
> +VER        = 1.1.3
>
> line 54
> -$(DL_FILE)_MD5 = 4c2642a25cc1667c39f955f0465f46d6
> +$(DL_FILE)_MD5 = 571e6b81873231246693d18a9912f55d

That modification does not build. More is required due to changes in 
archive contents.

We will also need to additionally fetch and include the modeswitch data 
file.


Olaf

Hi Gilles,
Am 28.06.2010 23:41, schrieb Gilles Espinasse:
> unzip is an uncommon usage on an unix box, unless for building drivers
> coming from manufacturer that mostly only know the windows world and package
> crappy drivers for linux.
> I haven't seen a strong need for unzip now, you are the first one to ask
> that.
>
> For sha1 inclusion (with perl code glue), I am not personally opposed.

I've finished a first version of my AddOn installer:
http://www.gknw.net/phpbb/viewtopic.php?t=586
please take a look, try it, and you will see why it comes handy for 
addons to have Archive::Zip as well as Digest::SHA added to the distro.
(BTW. I know that there exists a Digest::SHA::PurePerl, and I've tried 
that too - but found its *terrible* slow!)

Gün.

  Am 2010-06-15 11:54, schrieb Gilles Espinasse:
> Why not install in a more usual path like /usr/lib (and adjust path in
> openvpn.cgi)
>
> Ok to upgrade from v2.1_beta5 to v2.1_beta9?
>


OK on both.


Olaf

Hi,
Am 29.06.2010 15:51, schrieb Twanny Azzopardi:
> I just downloaded ipcop 1.9.11, what svn version do I need to compile
> additional software?
dont start now with 1.9.11 - there was a kernel update from .14 to .15;
here you can download a relatively recent svn version 4676 of 1.9.15:
http://svwe20.itex.at/ipcop-development/

depending on what you want to compile you might be fine on other Linux 
boxes with kernel 2.6.62; otherwise I might be able to help out with 
compiling stuff if you cant setup a complete build environment self to 
build from svn - just contact me directly.

Gün.

I just downloaded ipcop 1.9.11, what svn version do I need to compile 
additional software?

Twanny.

On Tuesday 29 June 2010 08:01:55 Twanny Azzopardi wrote:
> Is it possible to find / compile a 2.6 kernel for ipcop 1.4.21?
> 
> Regards.
> 
> ---------------------------------------------------------------------------
> --- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
> 
Does the addon server and copfilter work with version 2 ? 

Hi Gilles,
Am 28.06.2010 23:41, schrieb Gilles Espinasse:
> First, I will say again that I dislike the way many addons are
> build/packaged.
me too, but unless Ipcop lines up an accepted guideline how to pack 
addons + provides a framework like the now un-maintained addon-server 
this will not change.
> IPcop is build with a public source repository, open mailing lists.
> We make efforts that everyone that build the same sources produce the same
> binaries.
>
> Wich add-on provide  sources, wich provide a source repository, detailed
> changelog?
well, if that's your preference I'm willing to do so, but I see it as a 
bit overkill to make an own repo for one file like a cgi script, or even 
only an installer; the things I put together as addons are mostly based 
on other opensource projects, f.e. curl / libssh2, or flashrom - I 
modify nothing of the sources but only put the bits together so they can 
be easily installed by an average user in Ipcop.

> We have to evolve and have more flexibility on our building system _and_ at
> installation stage. We need for the futur a packaging system (one that
> already exist, with minimal overhead).
>
> As we are short in ressources, this may not come with 2.0 but to my point of
> view, this is a futur requirement. Until that happen, we have to be strict
> on what is include in standard installation.
>
> unzip is an uncommon usage on an unix box, unless for building drivers
> coming from manufacturer that mostly only know the windows world and package
> crappy drivers for linux.
> I haven't seen a strong need for unzip now, you are the first one to ask
> that.
well, I have two uses for it:
1. to unpack a bios update downloaded from mb manufacturer site.
2. to unpack additional software downloaded from manufacturer site which 
I do not want to repack and redistribute.

> I agree we should more use sha<x>  on our building system in the futur, but
> probably more use gpg signatures to validate sources packages when
> available.
well, my suggestions do not target the use of digests within Ipcop, but 
I only would like to see the Perl stuff beeing complete for use of 
Archive::Zip which is already part of the distro but unusable, and added 
Digest::SHA.

> For sha1 inclusion (with perl code glue), I am not personally opposed.
I did already post the necessary changes to the rootfiles.

I've collected the missing files in one folder:
24K     lib/Digest
12K     lib/List/Util
24K     lib/List
48K     lib/auto/Digest/SHA
52K     lib/auto/Digest
56K     lib/auto
8.0K    lib/Scalar/Util
20K     lib/Scalar
128K    lib/

these files are compressed ~32kb only:
-rw-r--r-- 1 root root   32697 2010-06-29 13:02 lib.tar.bz2

greets, Gün.

----- "Twanny Azzopardi" <twa...@gm...> a écrit :

> Is it possible to find / compile a 2.6 kernel for ipcop 1.4.21?
> 
> Regards.
> 
Compiling a 2.6 kernel with gcc-3.3.3 may require using a very old 2.6 kernel.
That would break ipsec, and require modutils upgrade to module-init-tools.
It may too be problematic in the installer for space reason in floppy images creation.

You would have better luck trying with last 1.9 test version.

Gilles

----- "Mark Oswald" <mar...@go...> a écrit :

> Hi,
> please update mklibs to 0.1.30
> 
> 
> file:
> trunk/lfs/mklibs
> 
> line 36
> -VER        = 0.1.29
> +VER        = 0.1.30
> 
> line 56
> -$(DL_FILE)_MD5                  = 7f35dfdbde249a090199829c1a1222d8
> +$(DL_FILE)_MD5                  = 15d20c45f786126e31aa3ac06fc08da5
> 
> 
> 
> greets,
> Mark
> 
Thank

I already have that change not yet commited to my tree.
I haven't seen a difference in behavior with 0.1.29.
mklibs still fail to reduce libpci and util-linux-ng libs with unresolved symbol message.

Did you know where that could matter?
I already look at the 0.1.29 vs 0.1.30 diff.


Gilles

Hi,
please update usb-modeswitch to 1.1.3


file:
trunk/lfs/usb-modeswitch

line 35
-VER        = 1.1.1
+VER        = 1.1.3

line 54
-$(DL_FILE)_MD5 = 4c2642a25cc1667c39f955f0465f46d6
+$(DL_FILE)_MD5 = 571e6b81873231246693d18a9912f55d


greets,
Mark

Hi,
please update mklibs to 0.1.30


file:
trunk/lfs/mklibs

line 36
-VER        = 0.1.29
+VER        = 0.1.30

line 56
-$(DL_FILE)_MD5                  = 7f35dfdbde249a090199829c1a1222d8
+$(DL_FILE)_MD5                  = 15d20c45f786126e31aa3ac06fc08da5



greets,
Mark

Is it possible to find / compile a 2.6 kernel for ipcop 1.4.21?

Regards.

----- Original Message ----- 
From: "Guenter" <li...@gk...>
To: <da...@kd...>; "IPCop devel" <ipc...@li...>
Sent: Friday, June 25, 2010 8:34 PM
Subject: Re: [IPCop-devel] 1.9.x no way to validate sha checksums


>> Unless it is part of something that is being permanently added to Ipcop.
> I do compile myself, and I need nobody to pay, nor to provide binaries
> to me. I want to provide an addon, and would find it nice if we could
> add things to make addon installations more hasslefree. I have no fun to
> maintain Perl modules and/or binaries self which depend on Perl and/or
> kernel versions which are already par of the build process but not
> included in the distro, so at the end if I provide my addon at all to
> the user community then I tell them to use my own builds which contain
> everything needed - its that simple for me.
> Anyway I see that Ipcop tends more and more to only target very vew
> mimimalistic enthusiasts rather than look for a broader user community
> with their wishes and needs.
>
> Gün.

First, I will say again that I dislike the way many addons are
build/packaged.
IPcop is build with a public source repository, open mailing lists.
We make efforts that everyone that build the same sources produce the same
binaries.

Wich add-on provide  sources, wich provide a source repository, detailed
changelog?

We have to evolve and have more flexibility on our building system _and_ at
installation stage. We need for the futur a packaging system (one that
already exist, with minimal overhead).

As we are short in ressources, this may not come with 2.0 but to my point of
view, this is a futur requirement. Until that happen, we have to be strict
on what is include in standard installation.

unzip is an uncommon usage on an unix box, unless for building drivers
coming from manufacturer that mostly only know the windows world and package
crappy drivers for linux.
I haven't seen a strong need for unzip now, you are the first one to ask
that.

I agree we should more use sha<x> on our building system in the futur, but
probably more use gpg signatures to validate sources packages when
available.

For sha1 inclusion (with perl code glue), I am not personally opposed.

Gilles





----------------------------------------------------------------------------
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
IPCop-devel mailing list
IPC...@li...
https://lists.sourceforge.net/lists/listinfo/ipcop-devel

Bugs item #3022467, was opened at 2010-06-28 18:26
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=3022467&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: Web Proxy
Group: V2 beta
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: DNS Proxy not forwarding requests inside firewall domain

Initial Comment:
1.4.x firewall forwards requests for hosts it doesn't know up to the DNS server.  1.9.14 doesn't appear to.  It properly serves requests to hosts it has configured, but not for others that end in the same domain that the firewall is configured to.  I plan to change the domain of the firewall to further confirm what is happening.

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

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

> Revision: 4679
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=4679&view=rev
> Author:   gespinasse
> Date:     2010-06-19 10:57:25 +0000 (Sat, 19 Jun 2010)
> 
> Log Message:
> -----------
> compile static lib again so mklibs could reduce the shared lib
> Disable pc98 format as it is possible and we don't use that format
> 
> Don't try to reduce libpci and util-linux-ng.
> Both reduction fail (unresolved symbol during lfs/initramfs)
> 
> With sysfsutils, e2fsprogs and parted reduced libs, gain is 70 kb compressed  
> 
> Modified Paths:
> --------------
>     ipcop/trunk/config/rootfiles/common/parted
>     ipcop/trunk/lfs/parted

With current rev. #4683 I get a Segmentation fault in partprobe. So currently
(at least my build) is broken at the moment, I can't install as the installer
is not able to partition my harddisk.
I did re-check with rev. #4678 (the one before the parted changes), this rev. is
installable at my testmachine.

-------------------------------------
Running command: /usr/bin/disk-partition.sh x86 sda 574 1054 onedisk
error partitioning /dev/sda
Make partitions failed
-------------------------------------
[install-i686] :/ $ /usr/sbin/partprobe /dev/sda
Segmentation fault
[install-i686] :/ $ 
-------------------------------------

Is this only my build?

My toolchain is compiled with rev. #4674.

Achim

Guenter wrote:
> Am 25.06.2010 19:38, schrieb Darren Critchley:
>> So you are asking that the Ipcop developers add a binary and a perl
>> module so that you alone can download a file to your Ipcop?
>>
>> You're going to have to compile that in your self or pay someone to do
>> it for you.
>>
>> Unless it is part of something that is being permanently added to Ipcop.
> I do compile myself, and I need nobody to pay, nor to provide binaries 
> to me. I want to provide an addon, and would find it nice if we could 
> add things to make addon installations more hasslefree. I have no fun to 
> maintain Perl modules and/or binaries self which depend on Perl and/or 
> kernel versions which are already par of the build process but not 
> included in the distro, so at the end if I provide my addon at all to 
> the user community then I tell them to use my own builds which contain 
> everything needed - its that simple for me.
> Anyway I see that Ipcop tends more and more to only target very vew 
> mimimalistic enthusiasts rather than look for a broader user community 
> with their wishes and needs.
> 
> Gün.
> 
> ------------------------------------------------------------------------------

I agree with Gün. As he already mentioned, it's already being built. 
It's only a matter of including it in the installation.

If one were to look objectively at the benefits vs the drawbacks, I 
think it's a no brainer.

-- 
-Eric 'shubes'