ipcop-devel Mailing List for IPCop Firewall

Good day.
I am trying to build ipcop 2 from svn as described in 
http://www.ipcop.org/index.php?module=pnWikka&tag=IPCop2BuildingHowto
on Ubuntu 8 kernel 2.6.24-17 with gcc version 4.2.3
and i get this error when i do ./make.sh build

gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -fno-common -Wno-error -fomit-frame-pointer -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.2.3/gcc -I../../gcc-4.2.3/gcc/build -I../../gcc-4.2.3/gcc/../include -I../../gcc-4.2.3/gcc/../libcpp/include  -I../../gcc-4.2.3/gcc/../libdecnumber -I../libdecnumber    -o build/gengtype-lex.o ../../gcc-4.2.3/gcc/gengtype-lex.c
gengtype-lex.c:3399: warning: no previous prototype for 'yyget_lineno'
gengtype-lex.c:3408: warning: no previous prototype for 'yyget_in'
gengtype-lex.c:3416: warning: no previous prototype for 'yyget_out'
gengtype-lex.c:3424: warning: no previous prototype for 'yyget_leng'
gengtype-lex.c:3433: warning: no previous prototype for 'yyget_text'
gengtype-lex.c:3442: warning: no previous prototype for 'yyset_lineno'
gengtype-lex.c:3454: warning: no previous prototype for 'yyset_in'
gengtype-lex.c:3459: warning: no previous prototype for 'yyset_out'
gengtype-lex.c:3464: warning: no previous prototype for 'yyget_debug'
gengtype-lex.c:3469: warning: no previous prototype for 'yyset_debug'
gengtype-lex.c:3475: warning: no previous prototype for 'yylex_destroy'
gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -fno-common -Wno-error -fomit-frame-pointer -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.2.3/gcc -I../../gcc-4.2.3/gcc/build -I../../gcc-4.2.3/gcc/../include -I../../gcc-4.2.3/gcc/../libcpp/include  -I../../gcc-4.2.3/gcc/../libdecnumber -I../libdecnumber    -o build/gengtype-yacc.o ../../gcc-4.2.3/gcc/gengtype-yacc.c
In file included from ./tm.h:15,
                 from /scratch/joseph/4.2.3/gcc-4.2.3/gcc-4.2.3/gcc/gengtype-yacc.y:26:
../../gcc-4.2.3/gcc/config/linux.h:1: error: expected identifier or '(' before '-' token
In file included from /scratch/joseph/4.2.3/gcc-4.2.3/gcc-4.2.3/gcc/gengtype-yacc.y:27:
../../gcc-4.2.3/gcc/gengtype.h:25: warning: ISO C does not allow extra ';' outside of a function
../../gcc-4.2.3/gcc/gengtype.h:62: error: field 'line' has incomplete type
../../gcc-4.2.3/gcc/gengtype.h:86: error: field 'line' has incomplete type
../../gcc-4.2.3/gcc/gengtype.h:100: error: field 'line' has incomplete type
make[4]: *** [build/gengtype-yacc.o] Error 1
make[4]: *** Waiting for unfinished jobs....
In file included from ./tm.h:15,
                 from ../../gcc-4.2.3/gcc/gengtype.c:24:
../../gcc-4.2.3/gcc/config/linux.h:1: error: expected identifier or '(' before '-' token
In file included from ../../gcc-4.2.3/gcc/gengtype.c:25:
../../gcc-4.2.3/gcc/gengtype.h:25: warning: ISO C does not allow extra ';' outside of a function
../../gcc-4.2.3/gcc/gengtype.h:62: error: field 'line' has incomplete type
../../gcc-4.2.3/gcc/gengtype.h:86: error: field 'line' has incomplete type
../../gcc-4.2.3/gcc/gengtype.h:100: error: field 'line' has incomplete type
../../gcc-4.2.3/gcc/gengtype.c: In function 'error_at_line':
../../gcc-4.2.3/gcc/gengtype.c:45: error: dereferencing pointer to incomplete type
../../gcc-4.2.3/gcc/gengtype.c:45: error: dereferencing pointer to incomplete type
../../gcc-4.2.3/gcc/gengtype.c: In function 'do_typedef':
../../gcc-4.2.3/gcc/gengtype.c:120: error: dereferencing pointer to incomplete type
../../gcc-4.2.3/gcc/gengtype.c: In function 'new_structure':
../../gcc-4.2.3/gcc/gengtype.c:154: error: dereferencing pointer to incomplete type
../../gcc-4.2.3/gcc/gengtype.c:210: error: dereferencing pointer to incomplete type
../../gcc-4.2.3/gcc/gengtype.c: In function 'note_variable':
../../gcc-4.2.3/gcc/gengtype.c:332: error: dereferencing pointer to incomplete type
../../gcc-4.2.3/gcc/gengtype.c: In function 'walk_type':
../../gcc-4.2.3/gcc/gengtype.c:1857: error: dereferencing pointer to incomplete type
../../gcc-4.2.3/gcc/gengtype.c:1857: error: dereferencing pointer to incomplete type
../../gcc-4.2.3/gcc/gengtype.c: In function 'main':
../../gcc-4.2.3/gcc/gengtype.c:3030: error: variable 'pos' has initializer but incomplete type
../../gcc-4.2.3/gcc/gengtype.c:3030: warning: excess elements in struct initializer
../../gcc-4.2.3/gcc/gengtype.c:3030: warning: (near initialization for 'pos')
../../gcc-4.2.3/gcc/gengtype.c:3030: warning: excess elements in struct initializer
../../gcc-4.2.3/gcc/gengtype.c:3030: warning: (near initialization for 'pos')
../../gcc-4.2.3/gcc/gengtype.c:3030: error: storage size of 'pos' isn't known
../../gcc-4.2.3/gcc/gengtype.c:3030: warning: unused variable 'pos'
make[4]: *** [build/gengtype.o] Error 1
make[4]: Leaving directory `/home/psycho/trunk/build_i486/ipcop/usr/src/gcc-build/gcc'
make[3]: *** [all-stage1-gcc] Error 2
make[3]: Leaving directory `/home/psycho/trunk/build_i486/ipcop/usr/src/gcc-build'
make[2]: *** [stage1-bubble] Error 2
make[2]: Leaving directory `/home/psycho/trunk/build_i486/ipcop/usr/src/gcc-build'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/psycho/trunk/build_i486/ipcop/usr/src/gcc-build'
make: *** [/home/psycho/trunk/log_i486/01_toolchain/gcc-4.2.3-pass2] Error 2


any luck with this 

Thanks



      

Feature Requests item #1976383, was opened at 2008-05-28 12:08
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=1976383&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: Christophe Migliorini (cmigliorini)
Assigned to: Nobody/Anonymous (nobody)
Summary: VPN Main screen improvement

Initial Comment:
I use my IPCop bow with 4 network interface to run a bunch of IPSec tunnels, and was missing some ergonomics...

I ended up patching the vpnmain.cgi file as follows.
- sorting the tunnels by name
- adding the LAN, remote GW, and remote LAN in the otherwise empty "Common Name" column.

Thought that might help.

--- vpnmain.cgi.orig	2008-05-27 21:28:24.000000000 +0200
+++ vpnmain.cgi	2008-05-28 11:37:33.000000000 +0200
@@ -2441,6 +2441,7 @@
     &General::readhash("${General::swroot}/vpn/settings", \%cgiparams);
     &General::readhasharray("${General::swroot}/vpn/caconfig", \%cahash);
     &General::readhasharray("${General::swroot}/vpn/config", \%confighash);
+    
     $cgiparams{'CA_NAME'} = '';
 
     my @status = `/usr/sbin/ipsec auto --status`;
@@ -2544,7 +2545,22 @@
     ;
     my $id = 0;
     my $gif;
-    foreach my $key (keys %confighash) {
+
+sub SortConfigHashByTunnelName
+{
+    if ($confighash{$a}[1] lt $confighash{$b}[1]) {
+	return -1;
+    }
+    elsif ($confighash{$a}[1] gt $confighash{$b}[1]) {
+	return 1;
+    }
+    else {
+	return 0;
+    }
+}
+
+
+    foreach my $key (sort SortConfigHashByTunnelName (keys(%confighash))) {
 	if ($confighash{$key}[0] eq 'on') { $gif = 'on.gif'; } else { $gif = 'off.gif'; }
 
 	if ($id % 2) {
@@ -2559,7 +2575,7 @@
 	} elsif ($confighash{$key}[4] eq 'cert') {
 	    print "<td align='left' nowrap='nowrap'>$confighash{$key}[2]</td>";
 	} else {
-	    print "<td align='left'>&nbsp;</td>";
+	    print "<td align='left' nowrap='nowrap'>$confighash{$key}[8] -[$confighash{$key}[10]]- $confighash{$key}[11]</td>";
 	}
 	print "<td align='center'>$confighash{$key}[25]</td>";
 	# get real state


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

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

> Gilles Espinasse wrote:

>> I think we should promote the date check windows earlier and before file
>> system creation.
>> You could test that once the file system is created, if you set the time in
>> the past and reboot (I have  tested with one hour on 1.40.9 ), on next
>> reboot, e2fschk will see the date in the futur on main partition, warn, fix
>> that and add another reboot. Next will other partitions be checked.

On second thought this is not that easy.
Best is to have everything in local time, now we have the TZ info only 
after file installation.

Need some more thinking how to handle this properly.


Olaf

-- 

A weizen a day helps keep the doctor away.

Eric Oberlander wrote:

>> Initial Comment:
>> regfish has changed its dynDNS update URL.
>> more infos may be found here
>> http://www.regfish.de/domains/dyndns/dokumentation

> I notice that Olaf has suggested a fix for this on the Bug Tracker.
> 
> Any feedback? Is it good to include in 1.4.20?

No feedback.

I see a 80% (or better) chance that the patch is good.
However without a test I do not think we should include.

OTOH I have seen no report in the IPCop communities that regfish is 
broken, this leads me to believe that there are very (very) few actually 
using it.


Olaf

-- 

A weizen a day helps keep the doctor away.

On Thu, Apr 24, 2008 at 9:08 AM, SourceForge.net
<no...@so...> wrote:
> Bugs item #1950435, was opened at 2008-04-24 10:08
> 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=1950435&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
> Resolution: None
> Priority: 5
> Private: No
> Submitted By: Hartmut Eilers (lnetwalker)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: change of DynDNS update URL by regfish
>
> Initial Comment:
> regfish has changed its dynDNS update URL.
> more infos may be found here
> http://www.regfish.de/domains/dyndns/dokumentation
>
> I tried to fix it by myself but had no luck.
> would be nice if these settings could be changed anywhere.
>
> Thanks
> Hartmut

I notice that Olaf has suggested a fix for this on the Bug Tracker.

Any feedback? Is it good to include in 1.4.20?

Eric

----- Original Message ----- 
From: "Gilles Espinasse" <g....@fr...>
To: <ipc...@li...>
Cc: <ow...@us...>
Sent: Sunday, May 25, 2008 6:34 PM
Subject: Re: [Ipcop-svn] SF.net SVN: ipcop:
[1410]ipcop/trunk/config/i486/install-message


>
> ----- Original Message ----- 
> From: <ow...@us...>
> To: <ipc...@li...>
> Sent: Saturday, May 24, 2008 8:29 PM
> Subject: [Ipcop-svn] SF.net SVN: ipcop:
> [1410]ipcop/trunk/config/i486/install-message
>
>
> > Revision: 1410
> >           http://ipcop.svn.sourceforge.net/ipcop/?rev=1410&view=rev
> > Author:   owes
> > Date:     2008-05-24 11:29:28 -0700 (Sat, 24 May 2008)
> >
> > Log Message:
> > -----------
> > Add i486 specific install-message, do not know if splash works with
aboot,
> yaboot and silo.
> >
...
> But we no more have the warning that everything previously on disk will be
> erased.
> We could add a new windows on newt interface.
> That would be better as it is simplier to translate there. And it no more
> depend on the arch and the boot system.
>
Concerning syslinux, there is now two menu system, one simple and one
advanced.
Details in doc/menu.txt
Simple menu could be in graphic mode or text mode.
Could be better than F1,F2,... pages
I have not yet played with that.

Gilles

Gilles Espinasse wrote:

>> Add i486 specific install-message, do not know if splash works with aboot,
> yaboot and silo.
> That will not work with aboot.
> For yaboot, there is a little penguin in config/ofboot-install.b text file.
> I don't know how change that.
> For silo, I don't know.

We can leave those as is then.


> But we no more have the warning that everything previously on disk will be
> erased.
> We could add a new windows on newt interface.

Already done that. As a matter of fact there are 2 warnings, first is 
just info: "Select the disk on which to install IPCop. The installation 
program will then partition the disk, put filesystems and files onto it. 
This means loosing ALL information on the disk!"

Second is an additional newt window, asking for confirmation: "Are you 
sure you want to continue and loose ALL information on the disk."

In this case a simple <enter> will abort, the user must move to the OK 
button before be able to continue.


> That would be better as it is simplier to translate there. And it no more
> depend on the arch and the boot system.

Exactly.


> I think we should promote the date check windows earlier and before file
> system creation.
> You could test that once the file system is created, if you set the time in
> the past and reboot (I have  tested with one hour on 1.40.9 ), on next
> reboot, e2fschk will see the date in the futur on main partition, warn, fix
> that and add another reboot. Next will other partitions be checked.

OK. I also noticed some problem with summertime (I'd really wish they 
drop that **(censored)** soon), the difference seems wrong.


Olaf

-- 

A weizen a day helps keep the doctor away.

----- Original Message ----- 
From: <ow...@us...>
To: <ipc...@li...>
Sent: Saturday, May 24, 2008 8:29 PM
Subject: [Ipcop-svn] SF.net SVN: ipcop:
[1410]ipcop/trunk/config/i486/install-message


> Revision: 1410
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=1410&view=rev
> Author:   owes
> Date:     2008-05-24 11:29:28 -0700 (Sat, 24 May 2008)
>
> Log Message:
> -----------
> Add i486 specific install-message, do not know if splash works with aboot,
yaboot and silo.
>
That will not work with aboot.
For yaboot, there is a little penguin in config/ofboot-install.b text file.
I don't know how change that.
For silo, I don't know.

splash is a problem with serial console.

Tested splah from pxe, it's look fine.
But we no more have the warning that everything previously on disk will be
erased.
We could add a new windows on newt interface.
That would be better as it is simplier to translate there. And it no more
depend on the arch and the boot system.

I think we should promote the date check windows earlier and before file
system creation.
You could test that once the file system is created, if you set the time in
the past and reboot (I have  tested with one hour on 1.40.9 ), on next
reboot, e2fschk will see the date in the futur on main partition, warn, fix
that and add another reboot. Next will other partitions be checked.

Gilles

----- Original Message ----- 
From: "Eric Oberlander" <eri...@gm...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCop devel" <ipc...@li...>
Sent: Saturday, May 24, 2008 8:15 PM
Subject: Re: [IPCop-devel] [1.4.19/1.4.20] update layout


> On Fri, May 23, 2008 at 3:14 PM, Gilles Espinasse <g....@fr...> wrote:
> > Selon Eric Oberlander <eri...@gm...>:
> >
> >> > You should have been able to reboot without trouble as grub.conf is
not yet
> >> > changed.
> >> >
> >> > I am curious what broke the new start. I may test that.
> >> > Anyway install could not properly work because old kernel files are
not
> >> actually
> >> > removed from /boot in 1.4.19 setup and space is too limited for 3
kernel
> >> > versions.
> >> >
> >> > Gilles
> >>
> >> I was not studying the start up messages closely, but I think there
> >> were a lot of error messages referring to "iptables not being
> >> compatible". The At the end of the boot process I had a running
> >> system, but no eth0 connectivity.
> >>
> > Could be very bad because iptables is not updated.
> > There  is only two lib updated in 1.4.19 (libpcre and libbzp2) but
ldconfig is
> > run so that should work.
> >
> > Maybe one updated lib could not have been written because there was no
space
> > left (as old kernel is actually not removed in 1.4.19 setup)
> > Old libbz2.so.1.0.3 is removed after new files installation but that
should
> > happen only when untarring updated files is a success.
> >
> >
> >> I can try and reproduce if required. I now have a usable backup ,dat
file :)
> >>
> > I am well trained to install old version and update.
> > With pxe boot and a small disk, I could install in 5mn old or new
version.
> > I will see if I can reproduce.
>
> Gilles
>
> Hold it, I just tried updating again, and my IPCop rebooted fine
> between 1.4.19 and 1.4.20
>
> I'm now contacting you via the running 1.4.20 system. Apologies for
> the false alarm.
>
> Eric
>
I have tested too and noted a few problems
My test has been to install 1.4.11 and apply all updates until 1.4.19 and
reboot (with intermediate reboot after 1.4.13)
With IDE 6.4GB disk size and IDE 273MB disk size, it's fine.
On small disk, I have selected UP kernel on 1.4.17.
I had no problems rebooting after 1.4.19 update but to my surprise 2.4.36
kernel was used.
Explanation for the 'no problems' is because I don't use the few 2.4.36 adsl
modules include in 1.4.20 (and not in 1.4.19).

The reason for the 2.4.36 kernel start even nothing has been changed in
grub.conf at that time is that grub.conf point to 'kernel /vmlinuz' at first
choice and during the update, vmlinuz (as a symlink to vmlinuz-2.4.36) is
installed.
We should not include the symlink in the update and create the symlink in
1.4.20 setup after grub.conf configuration.

With scsi disk, rebooting in 1.4.19 may (non smp) or may not (-smp) work.
It depend if you made enought manual cleanup before installing 1.4.12/1.4.13
to have a entire ipcoprd-smp.img. Anyway, that would be solved with full
1.4.19/1.4.20 setup

What is curious is that after 1.4.19 update actually ipcoprd.img include
2.4.34 modules and it boot with 2.4.36 vmlinuz. That look to work.

On Fri, May 23, 2008 at 3:14 PM, Gilles Espinasse <g....@fr...> wrote:
> Selon Eric Oberlander <eri...@gm...>:
>
>> > You should have been able to reboot without trouble as grub.conf is not yet
>> > changed.
>> >
>> > I am curious what broke the new start. I may test that.
>> > Anyway install could not properly work because old kernel files are not
>> actually
>> > removed from /boot in 1.4.19 setup and space is too limited for 3 kernel
>> > versions.
>> >
>> > Gilles
>>
>> I was not studying the start up messages closely, but I think there
>> were a lot of error messages referring to "iptables not being
>> compatible". The At the end of the boot process I had a running
>> system, but no eth0 connectivity.
>>
> Could be very bad because iptables is not updated.
> There  is only two lib updated in 1.4.19 (libpcre and libbzp2) but ldconfig is
> run so that should work.
>
> Maybe one updated lib could not have been written because there was no space
> left (as old kernel is actually not removed in 1.4.19 setup)
> Old libbz2.so.1.0.3 is removed after new files installation but that should
> happen only when untarring updated files is a success.
>
>
>> I can try and reproduce if required. I now have a usable backup ,dat file :)
>>
> I am well trained to install old version and update.
> With pxe boot and a small disk, I could install in 5mn old or new version.
> I will see if I can reproduce.

Gilles

Hold it, I just tried updating again, and my IPCop rebooted fine
between 1.4.19 and 1.4.20

I'm now contacting you via the running 1.4.20 system. Apologies for
the false alarm.

Eric

Selon Eric Oberlander <eri...@gm...>:

> > You should have been able to reboot without trouble as grub.conf is not yet
> > changed.
> >
> > I am curious what broke the new start. I may test that.
> > Anyway install could not properly work because old kernel files are not
> actually
> > removed from /boot in 1.4.19 setup and space is too limited for 3 kernel
> > versions.
> >
> > Gilles
>
> I was not studying the start up messages closely, but I think there
> were a lot of error messages referring to "iptables not being
> compatible". The At the end of the boot process I had a running
> system, but no eth0 connectivity.
>
Could be very bad because iptables is not updated.
There  is only two lib updated in 1.4.19 (libpcre and libbzp2) but ldconfig is
run so that should work.

Maybe one updated lib could not have been written because there was no space
left (as old kernel is actually not removed in 1.4.19 setup)
Old libbz2.so.1.0.3 is removed after new files installation but that should
happen only when untarring updated files is a success.


> I can try and reproduce if required. I now have a usable backup ,dat file :)
>
I am well trained to install old version and update.
With pxe boot and a small disk, I could install in 5mn old or new version.
I will see if I can reproduce.

Gilles

> You should have been able to reboot without trouble as grub.conf is not yet
> changed.
>
> I am curious what broke the new start. I may test that.
> Anyway install could not properly work because old kernel files are not actually
> removed from /boot in 1.4.19 setup and space is too limited for 3 kernel
> versions.
>
> Gilles

I was not studying the start up messages closely, but I think there
were a lot of error messages referring to "iptables not being
compatible". The At the end of the boot process I had a running
system, but no eth0 connectivity.

I can try and reproduce if required. I now have a usable backup ,dat file :)

Eric

Selon Eric Oberlander <eri...@gm...>:

> > Okay. My main reason for concern is a reboot after 1.4.19 and before
> > 1.4.20 update.
> > Since we remove 2.4.31 we must also remove from grub.conf but since we
> > do not have full 2.4.36 kernel we should not add to grub.conf.
> > Adding to grub.conf should be done if all kernel pieces are in place.
> >
> > Olaf
>
> I can confirm that rebooting after upgrading to 1.4.19 and before
> upgrading to 1.4.20 is a bad idea.
> I did it last weekend and completely hosed the box :)
>
> I had to reinstall from scratch, which was interesting.
>
You should have been able to reboot without trouble as grub.conf is not yet
changed.

I am curious what broke the new start. I may test that.
Anyway install could not properly work because old kernel files are not actually
removed from /boot in 1.4.19 setup and space is too limited for 3 kernel
versions.

Gilles

> Okay. My main reason for concern is a reboot after 1.4.19 and before
> 1.4.20 update.
> Since we remove 2.4.31 we must also remove from grub.conf but since we
> do not have full 2.4.36 kernel we should not add to grub.conf.
> Adding to grub.conf should be done if all kernel pieces are in place.
>
> Olaf

I can confirm that rebooting after upgrading to 1.4.19 and before
upgrading to 1.4.20 is a bad idea.
I did it last weekend and completely hosed the box :)

I had to reinstall from scratch, which was interesting.

Eric

Gilles Espinasse wrote:

>> Whilst adding a file for the next update, I noticed that we miss restart
>> of dhcp and squid (and now also snort) in setup.
>>
> thank for the snort fix
> As we supply a new kernel, a reboot is needed

Sure, but not everybody does that.
There are still enough that use 1.4.18 in combination with 2.4.31 
kernel. I anticipate similar will happen with 1.4.20 in combination with 
2.4.34 kernel.

To make sure we could simply add ipcopreboot boot at the end of 
1.4.20/setup (just kidding ;))


> vmlinuz* files are better in the first update for the same free space reason.
> vmlinuz* files does not use space on / partition.
> Any other files could be moved between first and second update without technical
> reasons.

Okay. My main reason for concern is a reboot after 1.4.19 and before 
1.4.20 update.
Since we remove 2.4.31 we must also remove from grub.conf but since we 
do not have full 2.4.36 kernel we should not add to grub.conf.
Adding to grub.conf should be done if all kernel pieces are in place.


Olaf

-- 

A weizen a day helps keep the doctor away.

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

>
> Whilst adding a file for the next update, I noticed that we miss restart
> of dhcp and squid (and now also snort) in setup.
>
thank for the snort fix
As we supply a new kernel, a reboot is needed

> I have not tried update scenarios, but to me it look better to swap to
> kernel parts: first add many modules in .19 then add essential parts in
> .20 (and juggle with grub.conf).
>
I have not yet tested too, should do this week-end after adding the bootloader
configuration.

There is place for tuning sizes actually.
Update is optimal when first update is smaller than the second and this is not
the case actually.

When first update is loaded and setup start, the first action is to remove the
old kernel. That mean before old kernel is removed, we have the update and two
full kernel versions.
When second update is loaded and setup start, we mostly have previous kernel
only and half of the two flavors (up,smp) of the new kernel plus the update
size.

vmlinuz* files are better in the first update for the same free space reason.
vmlinuz* files does not use space on / partition.
Any other files could be moved between first and second update without technical
reasons.

Gilles

Whilst adding a file for the next update, I noticed that we miss restart 
of dhcp and squid (and now also snort) in setup.

I have not tried update scenarios, but to me it look better to swap to 
kernel parts: first add many modules in .19 then add essential parts in 
.20 (and juggle with grub.conf).


Olaf

-- 

A weizen a day helps keep the doctor away.

Bugs item #1969949, was opened at 2008-05-22 16:52
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=1969949&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
Resolution: None
Priority: 5
Private: No
Submitted By: Jeff D. Hanson (jhansonxi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error when specifying a DHCP option value with a period

Initial Comment:
IPCop 1.4.18 
When adding a DHCP option/parameter for PXE boot file pxelinux.0 I get an error message.

If I specify the parameter "file name" I get:
/etc/dhcpd.conf line 16: expecting a parameter or declaration
	filename pxelinux.0;

If I specify the option "bootfile-name" I get:
/etc/dhcpd.conf line 17: semicolon expected.
	option bootfile-name pxelinux.
                                     ^
This doesn't occur with file name specified in a fixed lease.  The workaround is to use quotes: "pxelinux.0"

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

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

Gilles,

> As you know, the main problem is with openswan.

Yes.
There will be other (additional) problems in: eciadsl and wanpipe, both 
no longer build.
Smaller issue with libcap and perl, which I have found and prepared 
patches for.


> openswan-2.4.12 does not compile actually for kernels after 2.6.23, some work
> has been done for 2.6.24 but it is unfinished (there is not so much commits a
> month).

Yes, I am still hoping that it will be fixed soon. I tried strongswan, 
but that is too much change and work for me at the moment.
It does build and partial work, but it need change(s) in .cgi etc.
Also the method we use for key generation for backup does not seem 
possible with strongswan.


> Another goal is to be able to patch for security issues for some times.
> 2.4.24 is used in ubuntu 8.04 LTS and debian
> 2.4.25 is used by fedora, mandriva
> 
> That'easy to pick from a repository what we need, for example
> http://kernel.ubuntu.com/git or
> http://cvs.fedora.redhat.com/viewcvs/

For now I am happy with 2.6.24. Also it looks like there will be 
security patches (when necessary) from -stable team.

So for me there is no need to change and break even more parts.


> I haven't yet look how the already released distrib have addressed the ipsec
> issue. We could hope they are not all ipsec broken and pick the patches.
> The alternative is to fix openswan or revert the offending changes to a 2.6.23
> state.
> 
> Quickly looking, I find instruction with strongswan on ubuntu 8.04 when
> instructions for previous ubuntu versions use openswan.
> 
> I find too debian bug report with 2.6.24 and openswan-2.4.9. That mean our
> compilation issue has been solved bu one of the two ways ( kernel partial
> revertion or openswan fixes to 2.6.24).
> 
> Fedora in devel tree (and F9-split branch) use openswan-2.6.09 wich is a
> development version.

OK, I think I can find some time to do some searching.


For now I think we should stay with 2.6.24


Olaf

-- 

A weizen a day helps keep the doctor away.

Selon ow...@us...:

> Revision: 1373
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=1373&view=rev
> Author:   owes
> Date:     2008-05-20 23:43:07 -0700 (Tue, 20 May 2008)
>
> Log Message:
> -----------
> Be prepared should we decide to use kernel >= 2.6.25
>
Well
As you know, the main problem is with openswan.
openswan-2.4.12 does not compile actually for kernels after 2.6.23, some work
has been done for 2.6.24 but it is unfinished (there is not so much commits a
month).

Another goal is to be able to patch for security issues for some times.
2.4.24 is used in ubuntu 8.04 LTS and debian
2.4.25 is used by fedora, mandriva

That'easy to pick from a repository what we need, for example
http://kernel.ubuntu.com/git or
http://cvs.fedora.redhat.com/viewcvs/

I haven't yet look how the already released distrib have addressed the ipsec
issue. We could hope they are not all ipsec broken and pick the patches.
The alternative is to fix openswan or revert the offending changes to a 2.6.23
state.

Quickly looking, I find instruction with strongswan on ubuntu 8.04 when
instructions for previous ubuntu versions use openswan.

I find too debian bug report with 2.6.24 and openswan-2.4.9. That mean our
compilation issue has been solved bu one of the two ways ( kernel partial
revertion or openswan fixes to 2.6.24).

Fedora in devel tree (and F9-split branch) use openswan-2.6.09 wich is a
development version.


Gilles

On Mon, May 19, 2008 at 01:08:50AM -0700, David W Studeman wrote:
> On Monday 19 May 2008 12:27:26 am John Edwards wrote:
>> On Sun, May 18, 2008 at 09:08:15PM -0700, David W Studeman wrote:
>>>  I was wondering what the best alternative would be to set up the ramdisk
>>> on a machine that does NOT use grub? This is for the 1.4.x branch. To
>>> explain a bit the difference between Raq 3, 4, and Qube 3 from any other
>>> x86 is that instead of a bios, there is a linux based rom image in a
>>> flash chip on the board, this starts the boot process on it's own and can
>>> be accessed by serial console or use the lcd and panel buttons to set
>>> things like root partition so it can find /lib/modules, boot from disk,
>>> net boot, net kernel boot and so forth. When everything is set up, the
>>> Cobalt rom looks in either / or /boot for a gzipped and bzipped vmlinux
>>> image for disk boot, it bypasses any boot sector reading on the actual
>>> disk you run it from and just starts the kernel and hands off to it and
>>> gets out of the way. The rom menu using a serial console does allow
>>> kernel parameters to be set and as near as I can tell, it stores them in
>>> the rom settings but that is a messy thing to expect all Raq users
>>> wanting to run IPCop to bumble through. What I was wondering is where I
>>> can start the ramdisk other than grub. The reason why we are interested
>>> in CF flash installs is because small ide drives are getting harder to
>>> come by and a CF with a proper environment would be more than  enough
>>> space for a firewall plus I could post prebuilt CF images on our
>>> (racop.com) site. Any pointers on which direction to go would be greatly
>>> appreciated.
>>
>> Hi
>> Have you looked at how other Linux distributions have solved this
>> problem?
>>
>> For example:
>>  
>> http://www.google.co.uk/search?hl=en&q=linux++OR+debian+OR+gento+cobalt+RaQ
>>3+OR+RaQ4+OR+Qube3&btnG=Search&meta= (beware long line above)
>>
>> ps. Any chance of more line breaks and paragraphs in your emails to
>> that it is easier to read?
> 
> I think you misunderstand what I'm doing here, all the hits from your 
> suggested google search tell you how to install Linux on a Cobalt which I and 
> others have been doing for some time, in fact I know many of the people who 
> write these articles. My googling skills are not lacking in any way. This is 
> about setting up a ramdisk on IPCop without grub IF one is going to use a CF 
> card rather than a regular disk which I provide images for the latter on my 
> site. 

The GRUB + 2.4 kernel + ramdisk that IPCop uses is not that odd, just
outdated by a couple of years. There are other Linux systems that have
used it in the past and I thought that some of them would have been
installed on a Cobalt. One of the great advantages of open source is
that the knowledge is usually as openly distributed as the code.

I'm sorry if my email came across as "STFW", but it was not meant to
be that. It is often hard to know what another person has already done
to investigate a problem.

It sounds like a very worthy project. There must be quite a few old
Cobalt machines out there, and because they are becoming too old for
web servers they could make nice rack mountable firewalls. I wish you
luck and I hope you let the mailing list know of your progress.


>  I have to build a custom kernel since I have to patch it for Cobalt drivers 
> and also the e100 driver to ignore the hardware checksum thanks to yet 
> another goofy implementation of the Intel 82559er chips.  

That doesn't sound like a lot of fun. I'm glad you are doing the
porting and not me.
;)

> Simply setting the tmpfs option in the kernel config is also a non issue since 
> I use a modified config file. A stock IPCop distribution will not run on 
> these and I maintain a few build trees for IPCop on Cobalts including a devel 
> version that you can install on a spare Cobalt and compile things on.  
> 
>  I simply asked for an alternative to the current grub method of setting up a 
> ramdisk IF I choose to use a CF card rather than a spinning platter drive and 
> I got a good answer from Olaf. 

I agree that tmpfs is a good option, I like it and wrote some of the
patches for IPCop 2.0 SVN to use it for flash. And if the 2.4 kernel
in IPCop 1.4 supported it I would have recommended it as well. But as
you are going have to build your own kernel for the Cobalt oddities
you may as well include and use tmpfs instead of the older ramdisk.

If you are going to be using flash memory a lot then you may want to
have a look at some of the changes to the mkflash script that have
been committed to the IPCop 2.0 SVN. It already uses tmpfs and has
several bug fixes and extra features that I don't think have been
ported back to IPCop 1.4 (but I could be wrong).

One thing to be aware of is that the partition order is different to
IPCop 1.4, but that is an easy thing to fix.


> I'm sorry if my huge paragraphs are hard to read. I'll try to split it up 
> better.

Much nicer. :)


-- 
#---------------------------------------------------------#
|    John Edwards   Email: jo...@co...    |
#---------------------------------------------------------#

Gilles Espinasse wrote:

> my ISP was blacklisting host mail.sourceforge.net yesterday
> yuck!

They are currently also blacklisting ipcop-forum dot de


Here http://postmaster.free.fr/showipstate.pl it says:
The IP address a.b.c.d sent too many errors, your server is blacklisted 
for 2020 seconds. The IP address a.b.c.d sent too many errors, your 
server is temporaly blacklisted for 84820 seconds.


Very strange.


Olaf

-- 

A weizen a day helps keep the doctor away.

Gilles,


> I was intented to make a call at what could be changed on released kernel so we
> could stop the insane situation with :
> - official kernel
> - kernel lm sensor ready

Looking at http://khali.linux-fr.org/devel/i2c/ for the required changes 
  in i2c for lm-sensors to work, this looks more than just changing 1 or 
2 CONFIG_


> - kernel multicast ready

I have not made up my mind yet, whether this is good or bad ;)
Open to opinions.


> - kernel layer7 ready

I am opposed to using l7 for blocking, the l7-filter authors mention 
good and valid reasons here: http://l7-filter.sourceforge.net/HOWTO#Doing
IMHO a better solution is to enforce proxy usage and block all outgoing 
ports.

Also l7-filter seems to be moving away from in-kernel solution toward 
user-space and use iptables string match.


> As I think every kernel is under same /lib/modules name, every time the user
> apply an update related to a kernel module, it is very likely to break the
> running kernel. That's a very bad user experience!

To me the main problem here is that such modifications to IPCop are not 
marked (clearly enough) as something that can break things.


Olaf

-- 

A weizen a day helps keep the doctor away.

On Monday 19 May 2008 12:56:08 am Gilles Espinasse wrote:
> Selon John Edwards <jo...@co...>:
> > On Mon, May 19, 2008 at 06:54:22AM +0200, Olaf Westrik wrote:
> > > David W Studeman wrote:
> > >>  I was wondering what the best alternative would be to set up
> > >> the ramdisk on a machine that does NOT use grub?
> > >
> > > I'd try tmpfs (like we will do in 2.0).
> > >
> > > You will need to set CONFIG_TMPFS in the kernel config and create your
> > > 'ramdisk' with something like:
> > > mount -t tmpfs -o size=32M tmpfs /ram
> > >
> > > Not tried this on 1.4, but I see no reason why something like that
> > > would not work.
> >
> > Hi Olaf
> >
> > I like tmpfs, but think that the 2.4 kernel in IPCop 1.4.18 is
> > configured without it. On my build machine:
> >
> > $ grep -Hir tmpfs ipcop-1.4.18/config/kernel/kernel.config.i386
> > ipcop-1.4.18/config/kernel/kernel.config.i386:# CONFIG_TMPFS is not set
> >
> >
> > On my IPCop 1.4.18:
> >
> > # mount -t tmpfs -o size=32M tmpfs /ram
> > mount: wrong fs type, bad option, bad superblock on tmpfs,
> >        missing codepage or other error
> >        In some cases useful info is found in syslog - try
> >        dmesg | tail  or so
>
> We could change that setting.
>
> I was intented to make a call at what could be changed on released kernel
> so we could stop the insane situation with :
> - official kernel
> - kernel lm sensor ready
> - kernel multicast ready
> - kernel layer7 ready
> As I think every kernel is under same /lib/modules name, every time the
> user apply an update related to a kernel module, it is very likely to break
> the running kernel. That's a very bad user experience!
>
> I would prefer the situation where add-on developpers ask for needed
> configuration changes for the next released kernel.
> As we are near to release a new kernel, it is time now to ask for changes.
>
> I don't know remember enought of RAQ pecularities to know if it could share
> the exact same kernel as with other x86.
> If it was not possible to do that, there is no added value to set
> CONFIG_TMPFS on released kernel.
>
> Gilles
>
The /lib/modules are the same. The only actual kernel difference is that a 
Cobalt will not boot a vmlinuz image and uses no bootloader on the actual 
drive. The Cobalt rom looks in both / and /boot for a vmlinux.bz2 or 
vmlinux.gz image. I patch just the non smp kernel with the cobalt patch and 
e100 hardware checksum ignore patch, same for the 3.5.17 driver although that 
one does not like the 82559er chips in the Cobalt Raq 3 and 4. The Qube uses 
the natsemi driver so no problem there. 

 The Cobalt drivers end up being embedded in the bzipped kernel image and as 
such the system.map has a few more lines in it. I leave as much as possible 
in /lib/modules and certainly do not move or remove any existing IPCop driver 
modules. I'm not sure if a regular pc will boot a kernel image with the 
embedded Cobalt drivers in it. Moving the ramdisk setup out of grub and 
somewhere else would be great if it's not too much work. I'm not sure if the 
tmpfs can be a loadable module rather than embedded yet but i will find out 
shortly. Since 1.4.20 is supposed to be the last feature change of the 1.4 
series, the kernel changes you mentioned would be great. the Layer 7 and 
Multicast especially.

Thanks Gilles!



Dave

  

   

On Monday 19 May 2008 12:27:26 am John Edwards wrote:
> On Sun, May 18, 2008 at 09:08:15PM -0700, David W Studeman wrote:
> >  I was wondering what the best alternative would be to set up the ramdisk
> > on a machine that does NOT use grub? This is for the 1.4.x branch. To
> > explain a bit the difference between Raq 3, 4, and Qube 3 from any other
> > x86 is that instead of a bios, there is a linux based rom image in a
> > flash chip on the board, this starts the boot process on it's own and can
> > be accessed by serial console or use the lcd and panel buttons to set
> > things like root partition so it can find /lib/modules, boot from disk,
> > net boot, net kernel boot and so forth. When everything is set up, the
> > Cobalt rom looks in either / or /boot for a gzipped and bzipped vmlinux
> > image for disk boot, it bypasses any boot sector reading on the actual
> > disk you run it from and just starts the kernel and hands off to it and
> > gets out of the way. The rom menu using a serial console does allow
> > kernel parameters to be set and as near as I can tell, it stores them in
> > the rom settings but that is a messy thing to expect all Raq users
> > wanting to run IPCop to bumble through. What I was wondering is where I
> > can start the ramdisk other than grub. The reason why we are interested
> > in CF flash installs is because small ide drives are getting harder to
> > come by and a CF with a proper environment would be more than  enough
> > space for a firewall plus I could post prebuilt CF images on our
> > (racop.com) site. Any pointers on which direction to go would be greatly
> > appreciated.
>
> Hi
> Have you looked at how other Linux distributions have solved this
> problem?
>
> For example:
>  
> http://www.google.co.uk/search?hl=en&q=linux++OR+debian+OR+gento+cobalt+RaQ
>3+OR+RaQ4+OR+Qube3&btnG=Search&meta= (beware long line above)
>
> ps. Any chance of more line breaks and paragraphs in your emails to
> that it is easier to read?

I think you misunderstand what I'm doing here, all the hits from your 
suggested google search tell you how to install Linux on a Cobalt which I and 
others have been doing for some time, in fact I know many of the people who 
write these articles. My googling skills are not lacking in any way. This is 
about setting up a ramdisk on IPCop without grub IF one is going to use a CF 
card rather than a regular disk which I provide images for the latter on my 
site. 

 I have to build a custom kernel since I have to patch it for Cobalt drivers 
and also the e100 driver to ignore the hardware checksum thanks to yet 
another goofy implementation of the Intel 82559er chips.  

Simply setting the tmpfs option in the kernel config is also a non issue since 
I use a modified config file. A stock IPCop distribution will not run on 
these and I maintain a few build trees for IPCop on Cobalts including a devel 
version that you can install on a spare Cobalt and compile things on.  

 I simply asked for an alternative to the current grub method of setting up a 
ramdisk IF I choose to use a CF card rather than a spinning platter drive and 
I got a good answer from Olaf. 

I'm sorry if my huge paragraphs are hard to read. I'll try to split it up 
better.


Dave