ipcop-devel Mailing List for IPCop Firewall

On 2012-09-15 16:50, Eric Shubert wrote:
> If there's something in the
> documentation about needing to disable the Address Filter if you don't
> use it, I'm sorry that I missed it.

http://www.ipcop.org/2.0.0/en/admin/html/firewall-settings.html
2.6.3.2 and 2.6.3.3


Olaf

On 2012-09-26 15:27, g....@fr... wrote:

>> Hi,
>> To report a bug I've experienced and confirmed by other users
>> http://entraide.ixus.net/viewtopic.php?f=6&t=525
>> I installed IPCop 2.0.0 , I leave the default proxy stop , I
>> installed the update 2.0.1, 2.0.2, 2.0.3 , 2.0.4 and after Ipcop not
>> start the proxy, impossible.
>> I redo the same installation ( exactly the same), I activate the
>> proxy after installing IPCop 2.0.0 , then I install update 2.0.1,
>> 2.0.2, 2.0.3 , 2.0.4 and everything works fine. The proxy can start.
>>
>> Thank you to the developer of Ipcop which is really good.
>>
>> Eric.
>>
>>
> Thank for the report.
> I will test this suite of action.

The problem is the ownership of /var/ipcop/proxy. SVN #6808 should fix that.

Until then: chown nobody:nobody /var/ipcop/proxy


Olaf

On 10/28/2012 4:43 AM, Olaf Westrik wrote:
> IPCop 2.0.6 is released
>
> v2.0.6 is an UPDATE only, *NO* installation files.
> To install from scratch you will need to install v2.0.3 first,
> upgrade to v2.0.4, v2.0.5 and then upgrade to v2.0.6.
>
> v2.0.6 fixes the /var/log symlink for flash installations.
>
>
> Updates
> c4276df999d2c834fd214b7d6654ca28  ipcop-2.0.6-update.i486.tgz.gpg
>

Nice changes to rc.flash.up as well.

Looks like we're ready for next weekend's time change. I'm not sure how 
many are affected in any case. There seems to be quite a few still using 
1.4.21 including a few Raqcop users. That should change with 2.1.0. 
Holdouts for urlfilter they seem to be.

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

IPCop 2.0.6 is released

v2.0.6 is an UPDATE only, *NO* installation files.
To install from scratch you will need to install v2.0.3 first,
upgrade to v2.0.4, v2.0.5 and then upgrade to v2.0.6.

v2.0.6 fixes the /var/log symlink for flash installations.


Updates
c4276df999d2c834fd214b7d6654ca28  ipcop-2.0.6-update.i486.tgz.gpg

On 2012-10-28 06:15, David W Studeman wrote:

> The only issue with the patch is that it contains a /var/log folder. This
> matters on flash installs as it overwrites the link to /ram/var/log and you
> get a nice surprise with traffic accounting not finding the database as soon
> as you go to the homepage.

And some other surprises ...


I'll work on a small 2.0.6 patch that readds the symlink. Testing for 
FLASH installation first, and also testing if /var/log is a symlink or not.


Olaf

Eric Oberlander wrote:

> On 27 October 2012 18:28, Olaf Westrik
> <wei...@ip...> wrote:
>> IPCop 2.0.5 is released
>>
>> v2.0.5 is an UPDATE only, *NO* installation files.
>> To install from scratch you will need to install v2.0.3 first,
>> upgrade to v2.0.4 and then upgrade to v2.0.5
>>
>> v2.0.5 fixes the 'update is old' information message
>> and updates the timezone database.
>>
>>
>> Updates
>> 853b6d12793ea479440547c827e0c63a  ipcop-2.0.5-update.i486.tgz.gpg
> 
> Thanks Olaf

The only issue with the patch is that it contains a /var/log folder. This 
matters on flash installs as it overwrites the link to /ram/var/log and you 
get a nice surprise with traffic accounting not finding the database as soon 
as you go to the homepage. 

For the Raqcop version I removed /var/log/updates from the patch and added 
the following to the setup script before the section where it uncompresses 
the patch:
mkdir /var/log/updates
chown nobody:nobody /var/log/updates

This solved the issue. Should work whether /var/log is linked or an actual 
folder such as in the case of hard drive installs.

I had to re-link /ram/var/log and backversion my machine to 2.0.4 to try it 
again by doing the normal update via the updates page and it worked fine. I 
don't know how many of my users use flash, I know I swear by flash installs 
and prefer flash raid for some redundancy. 

This was definitely an interesting update during the 2.1.0 devel cycle. 
-- 
Dave Studeman
http://www.raqcop.com 

On 27 October 2012 18:28, Olaf Westrik <wei...@ip...> wrote:
> IPCop 2.0.5 is released
>
> v2.0.5 is an UPDATE only, *NO* installation files.
> To install from scratch you will need to install v2.0.3 first,
> upgrade to v2.0.4 and then upgrade to v2.0.5
>
> v2.0.5 fixes the 'update is old' information message
> and updates the timezone database.
>
>
> Updates
> 853b6d12793ea479440547c827e0c63a  ipcop-2.0.5-update.i486.tgz.gpg

Thanks Olaf

IPCop 2.0.5 is released

v2.0.5 is an UPDATE only, *NO* installation files.
To install from scratch you will need to install v2.0.3 first,
upgrade to v2.0.4 and then upgrade to v2.0.5

v2.0.5 fixes the 'update is old' information message
and updates the timezone database.


Updates
853b6d12793ea479440547c827e0c63a  ipcop-2.0.5-update.i486.tgz.gpg

On 2012-10-22 10:19, Eric Oberlander wrote:

> As the clocks go back this coming Sunday, how about putting out a
> smaller patch update, 2.0.5, which includes the latest tzdata files,
> new lang files, and maybe enough html to fix the update bug?

OK. Is going to be interesting SVN excercise though.
Seems there are quite a few American zonefiles that have been changed.


Olaf

Hi Olaf

As the clocks go back this coming Sunday, how about putting out a
smaller patch update, 2.0.5, which includes the latest tzdata files,
new lang files, and maybe enough html to fix the update bug?

Eric

----- Mail original -----
> De: "Eric Oberlander" <eri...@gm...>
> À: "Olaf Westrik" <wei...@ip...>
> Cc: "IPCop devel" <ipc...@li...>
> Envoyé: Vendredi 12 Octobre 2012 15:14:46
> Objet: Re: [IPCop-devel] linux-headers upgrade to 3.0.39
> 
> > looking into any remaining issues for 2.1.0.
> > Let us set a deadline of August 18th for 2.1.0-rc1 and (if all goes
> > well) a release of 2.1.0 on September 1st.
> 
> How are we doing on the release candidate?
> 
> It would be good to get the update out before the clocks go back, so
> the latest tzdata is available.
> 
Sorry, I make the planning shift a lot.

I make everyday some progress toward an upgrade to linux-3.4 kernel.
I am building with last 3.4.13 actually.
I will comment wanpipe build until the issues to build with 3.4 are fixed.

syslinux-4.05 doesn't compile with 3.4
syslinux-4.06 should be released at the weekend or early next week.
pre12 have been released a few days away and 4.06-pre13 yesterday.
The alternative is to copy the needed patch from fedora syslinux package tree with 4.05.

I encounter some issues with util-linux-2.22 that have been fixed with util-linux-2.22.1 just released a few days ago.
There was some corner cases badly handled by libmount, now the default on 2.22.
When the kernel running on the building machine is older than 2.6.37, a few issues appear with mount/umount.
I discovered that while building 2.22 and running coreutils tests on a machine that happen to run a 2.6.32 kernel.

While doing that, I learned how to play with loop module.
This case is special as it is possible to trigger loop module load from inside our building chroot (using losetup).

That let me fix one parted-3.1 test that was failing after I fixed /etc/mtab to look better.

I then experimented how to run mdadm and util-linux tests during the build.
The trick is to copy the required modules inside our build tree before the build, so they are available for modprobe during the build. That would work for mdadm actually but not for util-linux without other changes (as modprobe is build after util-linux).

I am unsure of the value of those tests using the machine kernel when the running kernel version is very different from the kernel we build against.
But that should be the right way if running the same kernel version as the one we build.
What I know is that one mdadm test fail : 01raid6integ (and test suite stop).

I will try to commit all my tree work this week-end. From memory, I have in my tree:
- les-451
- linux-3.4.13
- util-linux-2.22.1
- parted-3.1
- psmisc-22.20
- a few glibc-2.11 patches
- the /run change (not yet fully ready actually)
- touch /etc/fstab or fsck complain verbosely during mdadm tests

What I have not planned to upgrade is :
- replace module-init-tool by kmod (no time to work on this)
- replace libusb by libusbx (no time to work on this, no urgency too and I didn't know libusbx exist a few days ago)
- udev upgrade (all distro stay with 175 if I trust the linux-kernel 'udev breakage' topic)
  our udev-166 may not be worst than any recent for our need.

I don't know for :
- patch-2.7.1
- iproute2-3.6.0

Gilles

Hi Olaf

On 4 August 2012 18:03, Olaf Westrik <wei...@ip...> wrote:
> Hi Gilles,
>
>
>> I tried Olaf suggestion to upgrade the kernel headers and result look good.
>
> snip snip
>
>> So I would conclude upgrading the kernel headers to 3.0.39 is a good thing to do.
>
> Me too, somewhat suprised by the few changes required.
>
> Can you commit the change to lfs/linux-headers? After that I'll bump the
> toolchain version.
>
> Once the toolchain is sorted again, I would like to spend some time on
> looking into any remaining issues for 2.1.0.
> Let us set a deadline of August 18th for 2.1.0-rc1 and (if all goes
> well) a release of 2.1.0 on September 1st.

How are we doing on the release candidate?

It would be good to get the update out before the clocks go back, so
the latest tzdata is available.

Cheers

Eric