ipcop-devel Mailing List for IPCop Firewall

Bugs item #3612265, was opened at 2013-04-30 04:18
Message generated for change (Tracker Item Submitted) made by fxmaier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=3612265&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: Installation
Group: 2.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: fxmaier (fxmaier)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't create backup

Initial Comment:
I always used floppy for creating backups of my settings. Since ipcop 2.1.1 SVN 6980 and 7016 this no longer works. I get an error message, that there is not enogh space on disk - but I want to save the settings to floppy! Also I tried creating a backup on SD-Card - not possible!

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

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

Eric Shubert wrote:


>> The best way for consideration is to submit what you have as a feature
>> request ON THE SITE (yes, that ipcop.org one you should be familiar with
>> by now) with any working patches you have. Then you will get a yes or no
>> answer from the developers. Endian, a fork from IPCop that is now mature
>> in it's own right, supports Virtualization out of the box but they too
>> warn you against it.
>>
> 
> Thanks for the pointers, David.
> 
> Looks to me as though Endian is embracing Virtualization in a big way:
> http://www.endian.com/index.php?id=416
> I'm not seeing any warnings against it. Would you care to cite specific
> references?
> 

I can no longer find the disclaimer. I can also never see the same page 
twice at Endian it seems, the site is HUGE. 

As far as submitting, it looks as if Gilles has you covered. 

-- 
Dave Studeman
http://www.raqcop.com 

On 04/18/2013 07:39 PM, David W Studeman wrote:
> On 4/18/2013 1:29 PM, Eric Shubert wrote:
>
>>
>> So my question is, what are the chances of getting these patches applied
>> to the mainstream IPCop? Let me know what I might do to facilitate the
>> process.
>>
>> Thanks to everyone for all of their great work on IPCop!
>>
>
> The best way for consideration is to submit what you have as a feature
> request ON THE SITE (yes, that ipcop.org one you should be familiar with
> by now) with any working patches you have. Then you will get a yes or no
> answer from the developers. Endian, a fork from IPCop that is now mature
> in it's own right, supports Virtualization out of the box but they too
> warn you against it.
>

Thanks for the pointers, David.

Looks to me as though Endian is embracing Virtualization in a big way:
http://www.endian.com/index.php?id=416
I'm not seeing any warnings against it. Would you care to cite specific 
references?

-- 
-Eric 'shubes'

On 04/18/2013 11:42 PM, g....@fr... wrote:
>
>
> ----- Mail original -----
>> De: "Eric Shubert" <ej...@sh...>
>> À: ipc...@li...
>> Envoyé: Jeudi 18 Avril 2013 22:29:03
>> Objet: [IPCop-devel] Virtio Devices Patch
>>
>> A fellow developer (Justin H) and I have successfully built the
>> latest
>> (7001) IPCop with support for Virtio (paravirtualized KVM) disk and
>> network devices. These drivers are part of the kernel, and provide
>> significant performance improvements for IPCop virtual hosts running
>> under Linux KVM.
>>
>> The svn diff patch file is attached. It's fairly simple. The code is
>> replicated and tailored from existing IPCop code, and existing code
>> is pretty much untouched.
>>
> Thank for the patch.
> I will care to integrate.
>
> Index: src/installer/partition.c
> ===================================================================
> --- src/installer/partition.c	(revision 7001)
> +++ src/installer/partition.c	(working copy)
> @@ -622,6 +622,8 @@
>       /* TODO be more specific which modules to include */
>       fprintf(handle, "ext3\njbd\n");
>       fprintf(handle, "ehci-hcd\nohci-hcd\nuhci-hcd\nhid\nusbhid\n");
> +    // include virtio so se can boot from a virtio disk.
> +    fprintf(handle, "virtio\nvirtio_pci\nvirtio_blk\n");
>
> Appart of the typo, maybe we could detect boot from KVM?
>
> http://www.dmo.ca/blog/detecting-virtualization-on-linux/
> say 'dmesg | grep -i virtual' detect for all virtualized cases.
>
> To be specific for KVM, I suppose this should do the trick.
> dmesg | grep -i 'paravirtualized kernel on KVM'
>
> Could you confirm?
>
> Gilles
>
> ------------------------------------------------------------------------------

Gilles,

That particular string doesn't work for me, but I found one ('virtual 
kernel memory layout') which tests out ok. I also included a similar 
test ('virtio-pci') when checking for the virtio_net device.

FWIW, I'm still seeing cpu utilization that I think is a little higher 
than it needs to be (8% or so when idling). I'll look into this when I 
get a chance to see if that can be reduced. It might take a newer kernel 
though.

Many thanks for including this in the stock IPCop, Gilles. I'm hoping it 
will make it in the 2.1 release.

(this time with patch attached)

-- 
-Eric 'shubes'

-- 
-Eric 'shubes'

On 04/18/2013 11:42 PM, g....@fr... wrote:
>
>
> ----- Mail original -----
>> De: "Eric Shubert" <ej...@sh...>
>> À: ipc...@li...
>> Envoyé: Jeudi 18 Avril 2013 22:29:03
>> Objet: [IPCop-devel] Virtio Devices Patch
>>
>> A fellow developer (Justin H) and I have successfully built the
>> latest
>> (7001) IPCop with support for Virtio (paravirtualized KVM) disk and
>> network devices. These drivers are part of the kernel, and provide
>> significant performance improvements for IPCop virtual hosts running
>> under Linux KVM.
>>
>> The svn diff patch file is attached. It's fairly simple. The code is
>> replicated and tailored from existing IPCop code, and existing code
>> is pretty much untouched.
>>
> Thank for the patch.
> I will care to integrate.
>
> Index: src/installer/partition.c
> ===================================================================
> --- src/installer/partition.c	(revision 7001)
> +++ src/installer/partition.c	(working copy)
> @@ -622,6 +622,8 @@
>       /* TODO be more specific which modules to include */
>       fprintf(handle, "ext3\njbd\n");
>       fprintf(handle, "ehci-hcd\nohci-hcd\nuhci-hcd\nhid\nusbhid\n");
> +    // include virtio so se can boot from a virtio disk.
> +    fprintf(handle, "virtio\nvirtio_pci\nvirtio_blk\n");
>
> Appart of the typo, maybe we could detect boot from KVM?
>
> http://www.dmo.ca/blog/detecting-virtualization-on-linux/
> say 'dmesg | grep -i virtual' detect for all virtualized cases.
>
> To be specific for KVM, I suppose this should do the trick.
> dmesg | grep -i 'paravirtualized kernel on KVM'
>
> Could you confirm?
>
> Gilles
>
> ------------------------------------------------------------------------------

Gilles,

That particular string doesn't work for me, but I found one ('virtual 
kernel memory layout') which tests out ok. I also included a similar 
test ('virtio-pci') when checking for the virtio_net device.

FWIW, I'm still seeing cpu utilization that I think is a little higher 
than it needs to be (8% or so when idling). I'll look into this when I 
get a chance to see if that can be reduced. It might take a newer kernel 
though.

Many thanks for including this in the stock IPCop, Gilles. I'm hoping it 
will make it in the 2.1 release.


-- 
-Eric 'shubes'

Bugs item #3611806, was opened at 2013-04-25 01:49
Message generated for change (Tracker Item Submitted) made by yanncam
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=3611806&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: Security (Patches etc)
Group: 2.0.0
Status: Open
Resolution: None
Priority: 5
Private: Yes
Submitted By: Yann CAM (yanncam)
Assigned to: Nobody/Anonymous (nobody)
Summary: IPCop <= 2.0.6 multiple vulnerabilities

Initial Comment:
Hello IPCop development team,

I'm contacting you to inform you of some vulnerabilities in the latest version of IPCop <= 2.0.6.

A non-persistent XSS is present and can be exploited by attackers on IE browsers.
This allows you to bypass the CSRF protection implemented (referer checking).
A Remote command execution is exploitable on all browsers (if the referer is valid).
The non-persistent XSS can be used to gain a full interactive reverse-shell with CSRF protection bypass.

You will find all details in attached PoC and a private demonstration video can be viewed here : www.youtube.com/watch?v=ovhogZGHyMg

Do not hesitate to contact me for more information.

Thanking you in advance for your work on IPCop and future potential corrections.

Sincerely,

Yann CAM - Security consultant @ Synetis - ASafety

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

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

On 04/18/2013 11:42 PM, g....@fr... wrote:
>
>
> ----- Mail original -----
>> De: "Eric Shubert" <ej...@sh...>
>> À: ipc...@li...
>> Envoyé: Jeudi 18 Avril 2013 22:29:03
>> Objet: [IPCop-devel] Virtio Devices Patch
>>
>> A fellow developer (Justin H) and I have successfully built the
>> latest
>> (7001) IPCop with support for Virtio (paravirtualized KVM) disk and
>> network devices. These drivers are part of the kernel, and provide
>> significant performance improvements for IPCop virtual hosts running
>> under Linux KVM.
>>
>> The svn diff patch file is attached. It's fairly simple. The code is
>> replicated and tailored from existing IPCop code, and existing code
>> is pretty much untouched.
>>
> Thank for the patch.
> I will care to integrate.
>
> Index: src/installer/partition.c
> ===================================================================
> --- src/installer/partition.c	(revision 7001)
> +++ src/installer/partition.c	(working copy)
> @@ -622,6 +622,8 @@
>       /* TODO be more specific which modules to include */
>       fprintf(handle, "ext3\njbd\n");
>       fprintf(handle, "ehci-hcd\nohci-hcd\nuhci-hcd\nhid\nusbhid\n");
> +    // include virtio so se can boot from a virtio disk.
> +    fprintf(handle, "virtio\nvirtio_pci\nvirtio_blk\n");
>
> Appart of the typo, maybe we could detect boot from KVM?
>
> http://www.dmo.ca/blog/detecting-virtualization-on-linux/
> say 'dmesg | grep -i virtual' detect for all virtualized cases.
>
> To be specific for KVM, I suppose this should do the trick.
> dmesg | grep -i 'paravirtualized kernel on KVM'
>
> Could you confirm?
>
> Gilles
>
> ------------------------------------------------------------------------------

Thanks Gilles.

I'll incorporate said change, and see about doing the same when 
detecting the nic so the subsystem_deviceid can be stored so that the 
routine in networking.c will find it. I'll post another patch when I get 
it done. Hopefully this weekend.

Thanks again.


-- 
-Eric 'shubes'

----- Mail original -----
> De: "Eric Shubert" <ej...@sh...>
> À: ipc...@li...
> Envoyé: Jeudi 18 Avril 2013 22:29:03
> Objet: [IPCop-devel] Virtio Devices Patch
> 
> A fellow developer (Justin H) and I have successfully built the
> latest
> (7001) IPCop with support for Virtio (paravirtualized KVM) disk and
> network devices. These drivers are part of the kernel, and provide
> significant performance improvements for IPCop virtual hosts running
> under Linux KVM.
> 
> The svn diff patch file is attached. It's fairly simple. The code is
> replicated and tailored from existing IPCop code, and existing code
> is pretty much untouched.
> 
Thank for the patch.
I will care to integrate.

Index: src/installer/partition.c
===================================================================
--- src/installer/partition.c	(revision 7001)
+++ src/installer/partition.c	(working copy)
@@ -622,6 +622,8 @@
     /* TODO be more specific which modules to include */
     fprintf(handle, "ext3\njbd\n");
     fprintf(handle, "ehci-hcd\nohci-hcd\nuhci-hcd\nhid\nusbhid\n");
+    // include virtio so se can boot from a virtio disk.
+    fprintf(handle, "virtio\nvirtio_pci\nvirtio_blk\n");

Appart of the typo, maybe we could detect boot from KVM?

http://www.dmo.ca/blog/detecting-virtualization-on-linux/
say 'dmesg | grep -i virtual' detect for all virtualized cases.

To be specific for KVM, I suppose this should do the trick.
dmesg | grep -i 'paravirtualized kernel on KVM'

Could you confirm?

Gilles

On 4/18/2013 1:29 PM, Eric Shubert wrote:

>
> So my question is, what are the chances of getting these patches applied
> to the mainstream IPCop? Let me know what I might do to facilitate the
> process.
>
> Thanks to everyone for all of their great work on IPCop!
>

The best way for consideration is to submit what you have as a feature 
request ON THE SITE (yes, that ipcop.org one you should be familiar with 
by now) with any working patches you have. Then you will get a yes or no 
answer from the developers. Endian, a fork from IPCop that is now mature 
in it's own right, supports Virtualization out of the box but they too 
warn you against it.

-- 
Dave Studeman
http://www.raqcop.com

A fellow developer (Justin H) and I have successfully built the latest 
(7001) IPCop with support for Virtio (paravirtualized KVM) disk and 
network devices. These drivers are part of the kernel, and provide 
significant performance improvements for IPCop virtual hosts running 
under Linux KVM.

The svn diff patch file is attached. It's fairly simple. The code is 
replicated and tailored from existing IPCop code, and existing code is 
pretty much untouched.

I've tested the installation process, and it's working well. Unit 
testing has also been completed with promising results. I'll be 
installing and testing in a live environment in the next week or so.

I realize that some people aren't keen on running IPCop as a VM, but I 
think that's a personal judgment. For those of us choosing to do so, 
having the option to use virtio devices with IPCop is very desirable. 
While IPCop developers should rightly take pride in providing support 
for a wide array of devices, I think that virtual devices should not 
necessarily be excluded.

I might add that, while PFSense provides the ability to use virtio 
devices, the installation and configuration of them in PFSense is a 
little convoluted. With the attached patches, IPCop can be installed 
directly with virtio disk and network devices, all of which are 
automatically recognized by the installer. This gives IPCop somewhat of 
a leg up on the competition regarding installation as a VM. ;)

So my question is, what are the chances of getting these patches applied 
to the mainstream IPCop? Let me know what I might do to facilitate the 
process.

Thanks to everyone for all of their great work on IPCop!

-- 
-Eric 'shubes'

Feature Requests item #3611206, was opened at 2013-04-17 07:50
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=3611206&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: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Edolon ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for kerberos authentication to proxy server

Initial Comment:
Adding support for squid to use kerberos authentication would help increase security when wanting to use Windows integrated (transparent) authentication.
Currently only LM/NTLM authentication is supported for Windows integrated (transparent) authentication.
The problem with the above is on windows vista/2008 and higher only NTLMv2 responses are supported by default
(Microsoft has disabled LM & NTLM responses to increase domain security)

currently the squid auth helper squid_kerb_auth and negotiate_kerb_auth are installed but the libraries libkrb5support.so.0 is missing, so they can not be used.
At minimum can the libraries to be able to run squid_kerb_auth and negotiate_kerb_auth be included, so it can be configured manually though ssh?
and work on adding web GUI  support in the future after that.

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

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

> I forgot what code use ulogd-1. ulogd-1 is end-of-life.
> 
> Gilles

ulogd-1 is(/was) used for "detailed" traffic accounting, but currently
"detailed" is disabled. So ulogd-1 is not used at the moment.

I looked at ulogd-2, as there is libnetfilter_acct "for flexible traffic
accounting via nfnetlink_acct and iptables nfacct match" which requires kernel
>= 3.3.x, I won't start with the switch to new ulogd until our kernel is upgraded.

Achim

Hi

A few days ago I created this patch to integrate the service "URL Filter"
in IPCop 2.0.6!!
I have run many tests, and editing is stable!
I hope it will be useful!!


Link Download: http://sourceforge.net/projects/ipcop2urlfilter/

Link README file: http://sourceforge.net/projects/ipcop2urlfilter/files/


The Patch is in Italian, but also works on other languages.


Thanks!

Bye Bye!

-- 
Antonello Rotolo
moderator of the community IPCop Italia - http://forum.ipcop.pd.it
WEB: http://antonellorotolo.altervista.org
E-MAIL: ant...@gm...

On Tue, 09 Apr 2013 19:02:08 -0700
Eric Shubert <ej...@sh...> wrote:

> 
> While the virtio-blk disk driver won't provide nearly the overall 
> performance gain as virtio-net, I'd also like the installer to recognize 
> and use the virtio-blk device for the hdd. Any pointers for that would 
> be appreciated as well.
> 
Running virtualized block devices will be pretended to the kernel
as /dev/vda /dev/vdb etc. Maybe this can help you making a script
testing for block device names.

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
PENGUINICITY!!

On 04/05/2013 11:33 AM, Eric Shubert wrote:
> I'm attempting to build v6177 (should be 2.0.6 if I'm not mistaken) on a
> COS6 host. I've gotten over several hurdles, but I'm stuck on perl now.
> I ran ./make.sh gettoolchain, so perl wasn't built in that phase.
>
> The make.sh is choking at "chroot_make perl", with the following error:
>
> + cd /usr/src/lfs
> + make -f perl LFS_BASEDIR=/usr/src install
> ====================================== Installing perl-5.10.1 ...
> Install started; saving file list to /usr/src/lsalr ...
> cd /usr/src/perl-5.10.1 && tar zxf /usr/src/cache/
> tar (child): /usr/src/cache/: Cannot read: Is a directory
> tar (child): At beginning of tape, quitting now
> tar (child): Error is not recoverable: exiting now
>
> gzip: stdin: unexpected end of file
> tar: Child returned status 2
> tar: Error is not recoverable: exiting now
> make: *** [/usr/src/files_i486/02_base/perl-5.10.1] Error 2
>
> Any help would be greatly appreciated.
> I'll continue to learn what that script's doing in the meantime.
> Thanks.
>

Thanks to Gilles and David for the pointers.

I've since adjusted my tact. I've changed to debian to do the build, and 
have fetched the entire ipcop svn tree, and am using the 
tag/release-2.0.3 branch for building.

I've adjusted locations and a couple versions and successfully obtained 
the other sources. Using the current trunk was helpful with this, 
especially the kernel related packages. I've thus been able to build 
current 2.1.1 and older 2.0.3 isos. So far so good.

My purpose of doing this is to include the kernel paravirtualized 
drivers virtio-net and virtio-blk for use with IPCops running as a KVM. 
I realize that some folks here are leery about running IPCop as a VM, 
but I'm not so inclined. While the merits of such a setup can be 
debated, I think that having the option is none the less a benefit.

I changed the config/kernel/kernel-config.i486 file using menuconfig to 
include virtualization modules, and built an iso. An associate of mine 
who's working with me on this installed the iso using the e1000 network 
drivers, then changed the nic types from the e1000 to virtio. IPCop 
handles it fine with the modified kernel which includes the virtio 
modules. Network performance went from 80MB/s using e1000 to 269MB/s 
using virtio. That's a sizable improvement.

We're in need of a little guidance regarding how to get setup to detect 
the virtio device type. I haven't been able to hack that bit yet, and 
would appreciate a little help getting that going.

While the virtio-blk disk driver won't provide nearly the overall 
performance gain as virtio-net, I'd also like the installer to recognize 
and use the virtio-blk device for the hdd. Any pointers for that would 
be appreciated as well.

Once I get all this working, I'd be happy to provide a patch file for 
all of the changes required for this, or do whatever might be needed to 
help get these drivers into the stock IPCop distro.

Thanks for all your work with IPCop. I hope I can make a little 
contribution in this area too.

-- 
-Eric 'shubes'

On 4/6/2013 2:35 AM, g....@fr... wrote:
>
  "$?:$i" >>failure.log; done
>
> 2.0.6 is not easy to build.
> You need to checkout the full tree and build from the last tag (release-2.0.3), not from the trunk
> svn checkout https://ipcop.svn.sourceforge.net/svnroot/ipcop/ipcop

I know that when I tried to do a Raqcop 2.0.5 and 6 build it was more 
trouble than it was worth (I failed) and the IPCop patches already were 
out so simply edited them to match the cobalt arch that my update 
mechanism looks for, re-signed them with the raqcop key and put them on 
my update server. It was mainly timezone data and another minor fix so 
there was no need for everyone to build 2.0.6 for every IPCop adaptation 
out there. I remember owes doing some svn exercising to pull that one off.

-- 
Dave Studeman
http://www.raqcop.com

I'm attempting to build v6177 (should be 2.0.6 if I'm not mistaken) on a 
COS6 host. I've gotten over several hurdles, but I'm stuck on perl now. 
I ran ./make.sh gettoolchain, so perl wasn't built in that phase.

The make.sh is choking at "chroot_make perl", with the following error:

+ cd /usr/src/lfs
+ make -f perl LFS_BASEDIR=/usr/src install
====================================== Installing perl-5.10.1 ...
Install started; saving file list to /usr/src/lsalr ...
cd /usr/src/perl-5.10.1 && tar zxf /usr/src/cache/
tar (child): /usr/src/cache/: Cannot read: Is a directory
tar (child): At beginning of tape, quitting now
tar (child): Error is not recoverable: exiting now

gzip: stdin: unexpected end of file
tar: Child returned status 2
tar: Error is not recoverable: exiting now
make: *** [/usr/src/files_i486/02_base/perl-5.10.1] Error 2

Any help would be greatly appreciated.
I'll continue to learn what that script's doing in the meantime.
Thanks.

-- 
-Eric 'shubes'

----- Mail original -----
> De: "Eric Shubert" <ej...@sh...>
> À: ipc...@li...
> Envoyé: Vendredi 5 Avril 2013 20:33:21
> Objet: [IPCop-devel] Trying to build 6177, perl failing
> 
> I'm attempting to build v6177 (should be 2.0.6 if I'm not mistaken) on a
> COS6 host. I've gotten over several hurdles, but I'm stuck on perl now.
> I ran ./make.sh gettoolchain, so perl wasn't built in that phase.
> 
> The make.sh is choking at "chroot_make perl", with the following
> error:
> 
> + cd /usr/src/lfs
> + make -f perl LFS_BASEDIR=/usr/src install
> ====================================== Installing perl-5.10.1 ...
> Install started; saving file list to /usr/src/lsalr ...
> cd /usr/src/perl-5.10.1 && tar zxf /usr/src/cache/
> tar (child): /usr/src/cache/: Cannot read: Is a directory
> tar (child): At beginning of tape, quitting now
> tar (child): Error is not recoverable: exiting now
> 
> gzip: stdin: unexpected end of file
> tar: Child returned status 2
> tar: Error is not recoverable: exiting now
> make: *** [/usr/src/files_i486/02_base/perl-5.10.1] Error 2
> 
> Any help would be greatly appreciated.
> I'll continue to learn what that script's doing in the meantime.
> Thanks.
> 
> --
> -Eric 'shubes'
> 
It is very strange that the build fail so late.
Why the missing perl_5.10.1-17squeeze2.debian.tar.gz was not picked by lfsmakecommoncheck?
make md5 should have failed for lfs/perl.
Don't you hack the build, trying to hide(fix) the missing file?

If I build tags/release-2.0.3 without perl_5.10.1-17squeeze2.debian.tar.gz in cache, I have this error
perl                                      [     5.10.1 ]
ERROR: Download error in perl                                          [ FAIL ]
Check <mypath>/tags/release-2.0.3/log_i486/_build_00_preparation.log for errors if applicable

and _build_00_preparation.log show

perl	 Download: http://http.us.debian.org/debian/pool/main/p/perl/perl_5.10.1-17squeeze2.debian.tar.gz
http://http.us.debian.org/debian/pool/main/p/perl/perl_5.10.1-17squeeze2.debian.tar.gz:
2013-04-06 11:04:30 ERROR 404: Not Found.

If you didn't hack the build, that may be the hard to trigger bash bug we suffer since some time.
debian bash-4.1.5(1)-release (32bits) suffer from this issue. Randomly, make.sh may fail, sometime on impossible issue like
grep -q '^download' ${1}) not matching on the lfs script that is build.

I wan't able to trigger that bug on opensus-1.12.3 (64bits), I don't know yet if this is the bash version change or 32/64 bits that solve the issue.
I was able to reliabily trigger that issue on the debian machine (v6) after a full build using:
for i in $(seq 1 20); do sudo rm files_i486/03*/squid-3.1.2*; ./make.sh build; echo "$?:$i" >>failure.log; done

2.0.6 is not easy to build.
You need to checkout the full tree and build from the last tag (release-2.0.3), not from the trunk
svn checkout https://ipcop.svn.sourceforge.net/svnroot/ipcop/ipcop
cd ipcop/tags/release-2.0.3
You should be able to build from that place. Here, you should try ./make.sh prefetch
I should say I have a link for cache and ccache to the usual tree to avoid loading each time every package for each new tag.

Some package will miss like the debian diff that have been updated and perl is in that case.
lsof has to be loaded from OLD directory and from tar.gz
I have this diff under my tags/release-2.0.3 tree
Index: lfs/lsof
===================================================================
--- lfs/lsof    (révision 6951)
+++ lfs/lsof    (copie de travail)
@@ -38,8 +38,8 @@
 OTHER_SRC  = yes

 THISAPP    = $(PKG_NAME)_$(VER)
-DL_FILE    = $(THISAPP).tar.bz2
-DL_FROM    = ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof
+DL_FILE    = $(THISAPP).tar.gz
+DL_FROM    = ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/OLD
 DIR_APP    = $(DIR_SRC)/$(THISAPP)
 TARGET     = $(DIR_INFO)/$(STAGE_ORDER)_$(STAGE)/$(THISAPP)

@@ -55,7 +55,7 @@

 $(DL_FILE)     = $(DL_FROM)/$(DL_FILE)

-$(DL_FILE)_MD5 = a09326df500ef7e4550af546868338d6
+$(DL_FILE)_MD5 = 6dae655988c810a7042c06a4e2fa3c5f

Gilles

Eric Shubert wrote:
> I'm attempting to build v6177 (should be 2.0.6 if I'm not mistaken) on a
> COS6 host. I've gotten over several hurdles, but I'm stuck on perl now.
> I ran ./make.sh gettoolchain, so perl wasn't built in that phase.
>
> The make.sh is choking at "chroot_make perl", with the following error:
>
> + cd /usr/src/lfs
> + make -f perl LFS_BASEDIR=/usr/src install
> ====================================== Installing perl-5.10.1 ...
> Install started; saving file list to /usr/src/lsalr ...
> cd /usr/src/perl-5.10.1 && tar zxf /usr/src/cache/
> tar (child): /usr/src/cache/: Cannot read: Is a directory
> tar (child): At beginning of tape, quitting now
> tar (child): Error is not recoverable: exiting now
>
> gzip: stdin: unexpected end of file
> tar: Child returned status 2
> tar: Error is not recoverable: exiting now
> make: *** [/usr/src/files_i486/02_base/perl-5.10.1] Error 2
>
> Any help would be greatly appreciated.
> I'll continue to learn what that script's doing in the meantime.
> Thanks.
>
  You make no mention of why you are trying to build it but you couldn't 
have picked a worse build to try. When it became necessary to come out 
with 2.0.5 and 2.0.6, the svn tree was miles ahead of where 2.0.4 left 
off namely it was pre2.1.0 with urlfilter actually being well underway 
amongst thousands of other changes that would not have worked for a 
2.0.x progression since we only needed tzdata and 2.1.x was not ready 
nor close enough to be pushed out the door in haste.

In order to build the 2.0.5 and 6 updates required quite an svn maneuver 
on the developers part outside of the main tree. It was not a natural 
progression in the same tree as we have now and those who tried to build 
their own version of 2.0.6 likely failed.

If you have to build something, try 2.0.3 or 2.0.4 from a full fresh svn 
-r for that exact revision or build the latest and greatest if you are 
just testing anyway.


Dave Studeman
http://www.raqcop.com

I'm attempting to build v6177 (should be 2.0.6 if I'm not mistaken) on a 
COS6 host. I've gotten over several hurdles, but I'm stuck on perl now. 
I ran ./make.sh gettoolchain, so perl wasn't built in that phase.

The make.sh is choking at "chroot_make perl", with the following error:

+ cd /usr/src/lfs
+ make -f perl LFS_BASEDIR=/usr/src install
====================================== Installing perl-5.10.1 ...
Install started; saving file list to /usr/src/lsalr ...
cd /usr/src/perl-5.10.1 && tar zxf /usr/src/cache/
tar (child): /usr/src/cache/: Cannot read: Is a directory
tar (child): At beginning of tape, quitting now
tar (child): Error is not recoverable: exiting now

gzip: stdin: unexpected end of file
tar: Child returned status 2
tar: Error is not recoverable: exiting now
make: *** [/usr/src/files_i486/02_base/perl-5.10.1] Error 2

Any help would be greatly appreciated.
I'll continue to learn what that script's doing in the meantime.
Thanks.

-- 
-Eric 'shubes'

-- 
-Eric 'shubes'

Hi Eric

yes, I think capitalize words would be the best. 

Those text phrases are all copied/used from the urlfilter addon from Marco. 

Achim


> Hi Achim
> 
> I've looked at the actual webpage now, and can see that it is your
> 'Blacklist Editor' feature. Perhaps he simplest thing would be to
> capitalize both words, where the appear?
> 
> Eric
> 
> 
> 
> On 5 April 2013 12:07, Eric Oberlander <eri...@gm...> wrote:
> 
> > Hi Achim
> >
> > I'm forwarding a query about these two phrase variables:
> > blacklist import text
> > errmsg invalid import file
> >
> > The text for the first is:
> > To import a previously saved blacklist editor file upload the .tar.gz file
> > below
> >
> > Do you mean 'edited file' rather than 'editor file'? i.e. has the
> > blacklist file previously been edited, so it could be 'To import a
> > previously saved edited blacklist file upload the .tar.gz file below'
> > or is it more like 'To import a previously saved blacklist filtering file
> > upload the .tar.gz file below'
> >
> > And for the second:
> > File is not a valid URL filter blacklist editor file
> >
> > Similar query...
> >
> > Regards
> >
> > Eric
> >

Hi Achim

I've looked at the actual webpage now, and can see that it is your
'Blacklist Editor' feature. Perhaps he simplest thing would be to
capitalize both words, where the appear?

Eric



On 5 April 2013 12:07, Eric Oberlander <eri...@gm...> wrote:

> Hi Achim
>
> I'm forwarding a query about these two phrase variables:
> blacklist import text
> errmsg invalid import file
>
> The text for the first is:
> To import a previously saved blacklist editor file upload the .tar.gz file
> below
>
> Do you mean 'edited file' rather than 'editor file'? i.e. has the
> blacklist file previously been edited, so it could be 'To import a
> previously saved edited blacklist file upload the .tar.gz file below'
> or is it more like 'To import a previously saved blacklist filtering file
> upload the .tar.gz file below'
>
> And for the second:
> File is not a valid URL filter blacklist editor file
>
> Similar query...
>
> Regards
>
> Eric
>

Hi Achim

I'm forwarding a query about these two phrase variables:
blacklist import text
errmsg invalid import file

The text for the first is:
To import a previously saved blacklist editor file upload the .tar.gz file
below

Do you mean 'edited file' rather than 'editor file'? i.e. has the blacklist
file previously been edited, so it could be 'To import a previously saved
edited blacklist file upload the .tar.gz file below'
or is it more like 'To import a previously saved blacklist filtering file
upload the .tar.gz file below'

And for the second:
File is not a valid URL filter blacklist editor file

Similar query...

Regards

Eric

Hi translators!

>> I have added some new texts from urlfilter to the lang db which need
>> translations now.
> 
> Thanks to the Italian translator for almost finishing the new texts added
> by Achim.
> 
> If any translator has difficulty understanding a particular phrase or text,
> please post a question to this list, so we can help, and perhaps add an
> explanation to the Database, to help the next translators.


For some languages (bz, es, fr, it, nl, ru) there are already all translations
available from the URLFilter addon (for IPCop 1.4). Those translations can
easily copied, I only have changed some translation keys but below is a mapping
between (OLD) addon key and (NEW) IPcop 2.x key.

Achim


Mapping between old and new translation keys:
'OLD KEY' -> 'NEW KEY'
'urlfilter backup' -> 'create backup file'
'urlfilter backup error' -> 'err create backup file'
'urlfilter blacklist category name' -> 'blacklist category name'
'urlfilter blacklist name' -> 'blacklist name'
'urlfilter category data error' -> 'errmsg blacklist empty'
'urlfilter category name error' -> 'errmsg category name error'
'urlfilter domains' -> 'domains'
'urlfilter dont restart urlfilter' -> 'dont restart urlfilter'
'urlfilter dst error' -> 'errmsg at least one category must be selected'
'urlfilter edit domains urls expressions' -> 'edit domains urls expressions'
'urlfilter enable automatic blacklist update' -> 'enable automatic update'
'urlfilter export blacklist' -> 'export blacklist'
'urlfilter export error' -> 'err create export file'
'urlfilter expressions' -> 'expressions'
'urlfilter import blacklist' -> 'import blacklist'
'urlfilter import text' -> 'blacklist import text'
'urlfilter install blacklist' -> 'install blacklist'
'urlfilter install information' -> 'install blacklist information'
'urlfilter invalid content' -> 'errmsg invalid blacklist content'
'urlfilter invalid import file' -> 'errmsg invalid import file'
'urlfilter invalid restore file' -> 'errmsg invalid restore file'
'urlfilter load blacklist' -> 'load blacklist'
'urlfilter quota restart message' -> 'quota restart message'
'urlfilter quota time error' -> 'errmsg quota time'
'urlfilter quota user error' -> 'errmsg quota user'
'urlfilter restart' -> 'restart urlfilter'
'urlfilter restore' -> 'import backup file'
'urlfilter restore results' -> 'restore results'
'urlfilter select blacklist' -> 'select blacklist'
'urlfilter src error' -> 'errmsg src empty'
'urlfilter tar error' -> 'errmsg extract tar'
'urlfilter update results' -> 'blacklist update results'
'urlfilter upload success' -> 'blacklist upload success'
'urlfilter urls' -> 'urls'
'urlfilter web proxy service required' -> 'errmsg web proxy service required'
'urlfilter weekday error' -> 'errmsg weekday'
'urlfilter wrong filetype' -> 'errmsg wrong filetype'

On 28 March 2013 10:52, Achim Weber <dot...@gm...> wrote:

> > What's left to do before v2.1.1 can be released? It's getting close to
> > another clock shift, when an updated tzdata might be useful to some.
>
> I have added some new texts from urlfilter to the lang db which need
> translations now.
>

Thanks to the Italian translator for almost finishing the new texts added
by Achim.

If any translator has difficulty understanding a particular phrase or text,
please post a question to this list, so we can help, and perhaps add an
explanation to the Database, to help the next translators.

Thanks

--
Eric