ipcop-devel Mailing List for IPCop Firewall

On 23 Jun 2006, at 11:14, Achim Weber wrote:

> "IPCop SSH uses the non-standard Port 222!"
>
> No text regarding External Access, only a tip about the different ssh
> port.
>
> Achim

OK, no further comments received, I'll add this phrase to the  
Language Database.

Eric

On 25 Jun 2006, at 18:04, Marco van Beek wrote:

> Hi All,
>
> Adding a "First used in Version" field would be quite easy. We can  
> either do it as a ENUM field which would limit what choices one  
> had, but could increase day to day maintenance unless we limited it  
> to major releases only (eg v1.4, v1.5), or a simple text field,  
> which would be open to misspellings.
>
> I have a PHP script which will dump the MySQL ENUM values into a  
> HTML select, so that bit is self maintaining.
>
> What do you all think?
>
> Regards,
>
> Marco

Hi Marco

I'm getting out of my depth here :) I'm all for simplicity, to make  
maintenance easy. Achim's earlier suggestion of using a modified  
check_strings/fetchlangs sounded good. We would have to develop a  
script for v1.4, to add searching for strings in makegraphs and the  
logs.cgi sub-directory, but that would allow the Language Database to  
continue as is, with selection of phrases done automagically.

> You ask in another mail my modified check_strings.pl script, no
> problem. It is a mixture of check_strings and fetchlangs, it too would
> cover the issue with the language database for 1.4 and 1.5.
>
> The script searches the code for language entries and write only those
> language strings to the lang files which are really used in the code.
> In my "language DB" there are more language phrases than in the
> generated lang file in the release-package.
>
> If we use this in IPCop too there would be no need for a database
> change or a seperate database.
>
> Good idea?
>
> Achim

Eric

> On 2006-06-24 20:35:05, Michael Rasmussen wrote:
>>> 
>>> 2) I am not sure I understand what you mean by using gettext inside
>>> a print command. Could you be more specific?
>>> 

> But now I do:-) But it gets really ugly though!
> print "@{[$gt->get('legend')]}\n";

> The reason for your problems is that hashes are not interpolated inside
> double quotes like scalars and arrays so my solution above will make an
> anon-arrayref from the list of key-value pairs %hash in lists context
> returns, and deref it. The result will be the list joined by $".

Wow ok, that did the trick! It looks much better now:
 -> http://blockouttraffic.de/tmp/gettext_v2.png

Now I have the Locale::gettext Perl module for IPCop:
 -> http://blockouttraffic.de/tmp/gettext-module.tar.gz
Thanks Michael for your hints!

Test script:
 -> http://blockouttraffic.de/tmp/gettext_OO_2.pl


What do you other's think, is this to ugly or should I commit those
code (Lang.pl and convert script, I'm still afraid to convert all
cgi's etc.)?

Achim

Feature Requests item #1512653, was opened at 2006-06-26 08:18
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=1512653&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface Improvements (example)
Group: Next Release (example)
Status: Open
Priority: 5
Submitted By: Dragonator (dragonator)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow negative IP notation for port forward restrictions

Initial Comment:
When creating a port forward you can restrict access to
a particular IP or network.  You can even add multiple
entries if you need to allow them.  It would be really
nice to be able to enter negative entries like you can
in  iptables (!www.xxx.yyy.zzz/ab) to functionally
allow all except a particular block of IPs.  

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

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

Hi All,

Adding a "First used in Version" field would be quite easy. We can 
either do it as a ENUM field which would limit what choices one had, but 
could increase day to day maintenance unless we limited it to major 
releases only (eg v1.4, v1.5), or a simple text field, which would be 
open to misspellings.

I have a PHP script which will dump the MySQL ENUM values into a HTML 
select, so that bit is self maintaining.

What do you all think?

Regards,

Marco

Eric Oberlander wrote:
> On 25 Jun 2006, at 10:16, Gilles Espinasse wrote:
> 
>>> I think we could look at adding your new phrases to the Language
>>> Database after v1.4.11 is released, unless we want to modify the
>>> whole system?
>>>
>>> Eric
>>>
>> Should we not consider to have a separate database for 1.4 than for 1.5?
>>
>> Gilles
> 
> I have thought about separate databases before, and there are probably 
> advantages and disadvantages. I think the existing system works well, 
> and if possible should evolve, rather than be reinvented.
> 
> I wondered about asking the Database Masters if they could add a marker 
> (or markers) to indicate if a phrase is used in v1.4 series, or v1.5 
> series. We could then test for inclusion in v1.4 or v1.5 by modifying 
> the download scripts that generate the output files.
> 
> I would ask for something like a checkbox for admins to select against 
> each variable string:
>  Phrase used in v1.4 [x]
>  Phrase used in v1.5 [ ]
> 
> We could then select which phrases are relevant to each version. That 
> would avoid a problems if a phrase was dropped in v1.5, but was still 
> needed in v1.4.
> 
> I think we should ask Marco van Beek for his input.
> 
> Eric
> 
> 

-- 
Marco van Beek
==========================================
Supporting Role Ltd.
Grove Park Studios,
188-192 Sutton Court Rd,
London, W4 3HR
==========================================
T: 0870 757 2824
F: 0870 757 2826
M: 0788 770 3604
E: mva...@su...
==========================================

----- Original Message ----- 
From: "Michael Rasmussen" <mi...@mi...>
To: "IPCOP devel" <ipc...@li...>
Sent: Sunday, June 25, 2006 11:23 AM
Subject: Re: [IPCop-devel] Info: Building HEAD on Debian with gcc-4.1

> On 2006-06-25 10:10:33, Gilles Espinasse wrote:
> > Version is still 1.5.0a1 on cvs
> >
> My mistake. It is make.sh toolchain that is complaining of a missing
> package of toolchain. It looks for
> ipcop-1.5.0a1.2-toolchain-i486.tar.gz but
> ipcop-1.5.0a1.1-toolchain-i486.tar.gz is the one available.
>
> What is the difference between ipcop-1.5.0a1.1-toolchain-i486.tar.gz
> and ipcop-1.5.0a1-toolchain-i686.tar.gz and how to use it?
>
First was ipcop-1.5.0a1-toolchain-i686.tar.gz.
gcc parameters used to build the toolchain make this toolchain package only
usable on i686.
A different toolchain package need to be used for each cpu powering the
building machine.

A new toolchain was build with some changes and this time, gcc was build on
the toolchain for i486
 (same as target destination as we want it could be run on i486).
My build has run on a i686 but theorically, the package should run on any
i486 or better to build ipcop.
To be true, I have tested this toolchain-i486 on a K6-2-450 and it has
failed to build early.
I don't remember exactly in wich package the error was (I think it was on
glibc).
On this same K6-2 450, without using a toolchain package, I have been build
successfully using glibc (not tested uclibc way).

Due to new changes on building system (differentiate glibc/uclibc log and
build directories), I have incremented the necessary toolchain package to
1.5.0a1.2.
But I have not yet uploaded those new packages (one for glibc, one for
uclibc).

Gilles

Hi Eric,

Eric Oberlander wrote:

> On 25 Jun 2006, at 10:16, Gilles Espinasse wrote:

>>> I think we could look at adding your new phrases to the Language
>>> Database after v1.4.11 is released, unless we want to modify the
>>> whole system?
>>>
>>> Eric
>>>
>> Should we not consider to have a separate database for 1.4 than for
>> 1.5?
>>
>> Gilles

> I have thought about separate databases before, and there are  
> probably advantages and disadvantages. I think the existing system  
> works well, and if possible should evolve, rather than be reinvented.

> I wondered about asking the Database Masters if they could add a  
> marker (or markers) to indicate if a phrase is used in v1.4 series,
> or v1.5 series. We could then test for inclusion in v1.4 or v1.5 by
> modifying the download scripts that generate the output files.

> I would ask for something like a checkbox for admins to select  
> against each variable string:
>   Phrase used in v1.4 [x]
>   Phrase used in v1.5 [ ]

> We could then select which phrases are relevant to each version. That
> would avoid a problems if a phrase was dropped in v1.5, but was still
> needed in v1.4.

> I think we should ask Marco van Beek for his input.

> Eric


You ask in another mail my modified check_strings.pl script, no
problem. It is a mixture of check_strings and fetchlangs, it too would
cover the issue with the language database for 1.4 and 1.5.

The script searches the code for language entries and write only those
language strings to the lang files which are really used in the code.
In my "language DB" there are more language phrases than in the
generated lang file in the release-package.

If we use this in IPCop too there would be no need for a database
change or a seperate database.

Good idea?

Achim

On 25 Jun 2006, at 10:16, Gilles Espinasse wrote:

>> I think we could look at adding your new phrases to the Language
>> Database after v1.4.11 is released, unless we want to modify the
>> whole system?
>>
>> Eric
>>
> Should we not consider to have a separate database for 1.4 than for  
> 1.5?
>
> Gilles

I have thought about separate databases before, and there are  
probably advantages and disadvantages. I think the existing system  
works well, and if possible should evolve, rather than be reinvented.

I wondered about asking the Database Masters if they could add a  
marker (or markers) to indicate if a phrase is used in v1.4 series,  
or v1.5 series. We could then test for inclusion in v1.4 or v1.5 by  
modifying the download scripts that generate the output files.

I would ask for something like a checkbox for admins to select  
against each variable string:
  Phrase used in v1.4 [x]
  Phrase used in v1.5 [ ]

We could then select which phrases are relevant to each version. That  
would avoid a problems if a phrase was dropped in v1.5, but was still  
needed in v1.4.

I think we should ask Marco van Beek for his input.

Eric

On 2006-06-25 10:10:33, Gilles Espinasse wrote:
> Version is still 1.5.0a1 on cvs
>=20

My mistake. It is make.sh toolchain that is complaining of a missing =20
package of toolchain. It looks for =20
ipcop-1.5.0a1.2-toolchain-i486.tar.gz but =20
ipcop-1.5.0a1.1-toolchain-i486.tar.gz is the one available.

What is the difference between ipcop-1.5.0a1.1-toolchain-i486.tar.gz =20
and ipcop-1.5.0a1-toolchain-i686.tar.gz and how to use it?

--Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xD3C9A00E
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE3E80917
--------------------------------------------------------------
Use library functions.
             - The Elements of Programming Style (Kernighan & Plaugher)

On 2006-06-25 10:10:33, Gilles Espinasse wrote:
> Version is still 1.5.0a1 on cvs
>=20
My mistake. It is make.sh toolchain that is complaining of a missing =20
package of toolchain. It looks for =20
ipcop-1.5.0a1.2-toolchain-i486.tar.gz but =20
ipcop-1.5.0a1.1-toolchain-i486.tar.gz is the one available.

What is the difference between ipcop-1.5.0a1.1-toolchain-i486.tar.gz =20
and ipcop-1.5.0a1-toolchain-i686.tar.gz and how to use it?

--=20
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xD3C9A00E
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE3E80917
--------------------------------------------------------------
Use library functions.
             - The Elements of Programming Style (Kernighan & Plaugher)

----- Original Message ----- 
From: "Eric Oberlander" <er...@ob...>
To: "IPCop-Devel" <ipc...@li...>
Sent: Saturday, June 24, 2006 4:00 PM
Subject: Re: [IPCop-devel] Converting v1.5 cgis to use gettext


> On 24 Jun 2006, at 14:16, Achim Weber wrote:
> 
> snip...
> 
> > As for the generation of the message files, we already have a small
> > perl script which checks for translations:
> > http://ipcop.cvs.sourceforge.net/ipcop/ipcop/tools/check_strings.pl? 
> > revision=1.3&view=markup
> > I have modified this script for my BOT addon where it generates the
> > BOT language files. So we can go the OO-way with gettext and use this
> > script to generate the ascii-gettext files (IIRC these are the .po
> > files?).
> 
> The check_strings.pl script is used to see if there are any  
> untranslated, or unused, phrases in the cgi codebase. I'm not sure if  
> the current script will work on v1.5, as it was designed for v1.4.  
> The current v 1.4 version also fails to find translation strings in  
> the 'makegraphs' script, and the logs.cgi sub-directory IIRC, so it  
> has to be used bearing this points in mind. I have found it a very  
> useful tool over the years.
> 
> The script that downloads the language files from the IPCop Language  
> Database is called fetchlangs.pl
> http://ipcop.cvs.sourceforge.net/ipcop/ipcop/tools/fetchlangs.pl? 
> view=log
> Alan modified it to work for v1.5
> 
> I think we could look at adding your new phrases to the Language  
> Database after v1.4.11 is released, unless we want to modify the  
> whole system?
> 
> Eric
> 
Should we not consider to have a separate database for 1.4 than for 1.5?

Gilles

----- Original Message ----- 
From: "Michael Rasmussen" <mi...@mi...>
To: <ipc...@li...>
Sent: Sunday, June 25, 2006 8:23 AM
Subject: [IPCop-devel] Info: Building HEAD on Debian with gcc-4.1

> Hi all,
>
> I have just successfully build 1.5.0a2, the iso claims to be 1.5.0.a1
> though. The build system was Debian unstable.
>
Version is still 1.5.0a1 on cvs

> According to the build howto you are not able to build with gcc-4.0 but
> with gcc-4.1 there was no problem. I build all from scratch including
> tool-chain.
Good

> Three errors thoug: Because of newer versions the following tar-balls
> could not be downloaded automatically:
>
> man-pages-2.25
I upgrade to the newest available (2.34)

> popt-1.7
fixed ftp site is actually down, find on a http mirror

> shadow-4.0.15
not yet down
I could move url to old directory but I am unsure we need to stay with
4.0.15
There is some improvements in 4.0.16 wich may need lfs script cleanup.

Gilles

Hi all,

I have just successfully build 1.5.0a2, the iso claims to be 1.5.0.a1 =20
though. The build system was Debian unstable.

According to the build howto you are not able to build with gcc-4.0 but =20
with gcc-4.1 there was no problem. I build all from scratch including =20
tool-chain.

Three errors thoug: Because of newer versions the following tar-balls =20
could not be downloaded automatically:

man-pages-2.25
popt-1.7
shadow-4.0.15

--=20
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xD3C9A00E
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE3E80917
--------------------------------------------------------------
BOFH excuse #232:

Ionization from the air-conditioning

On 2006-06-24 20:35:05, Michael Rasmussen wrote:
>>=20
>> 2) I am not sure I understand what you mean by using gettext inside =20
>> a print command. Could you be more specific?
>>=20

But now I do:-) But it gets really ugly though!
print "@{[$gt->get('legend')]}\n";

The reason for your problems is that hashes are not interpolated inside =20
double quotes like scalars and arrays so my solution above will make an =20
anon-arrayref from the list of key-value pairs %hash in lists context =20
returns, and deref it. The result will be the list joined by $".

--=20
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xD3C9A00E
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE3E80917
--------------------------------------------------------------
Make the coupling between modules visible.
             - The Elements of Programming Style (Kernighan & Plaugher)

Hi again:-)

On 2006-06-24 19:56:59, Michael Rasmussen wrote:
>=20
> 2) I am not sure I understand what you mean by using gettext inside a =20
> print command. Could you be more specific?
>=20

Is it something like this your are looking for?
$s =3D $gt->get('legend');
print "$s\n";

--=20
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xD3C9A00E
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE3E80917
--------------------------------------------------------------
Your manuscript is both good and original, but the part that is good is =20
not original and the part that is original is not good.
		-- Samuel Johnson

Hi Achim,

On 2006-06-24 15:16:11, Achim Weber wrote:
> Michael, do you know a way around the Perl-Reference issue where the
> gettext can't be used inside a print-command:
> http://marc.theaimsgroup.com/?l=3Dipcop-devel&m=3D115097906018345&w=3D2
>=20
1) The example your link points to is using a mixture of OO and not OO. =20
The corrected script looks like this:

#!/usr/bin/env perl
#Above is the prered way since perl can be installed in different places

#use locale; not needed since implicitly included by using POSIX
use Locale::gettext; # this is the correct way of including gettext =20
support
use POSIX;     # Needed for setlocale()

setlocale(LC_MESSAGES, "en_GB"); #/* or which locale is really set! */
my $gt =3D Locale::gettext->domain('ipcop');
$gt->dir('/var/ipcop/locale');

print "Local variable:\n";
print "$gt->get('legend')\n";  # Here you print out the address of the =20
hash
print $gt->get('legend'),"\n"; # Here you print what the hash points to

require '/var/ipcop/general-functions.pl';
require "/var/ipcop/lang.pl";

print "Lang package:\n";
print "$Lang::gt->get('legend')\n";  # Error
print $Lang::gt->get('legend'),"\n"; # correct

exit 0;

2) I am not sure I understand what you mean by using gettext inside a =20
print command. Could you be more specific?

3) Your conversion script needs to be change too
sub convertLine
{
	my $line =3D shift;

	while($line =3D~ =20
/(.*)\$Lang::tr{'([A-Za-z0-9,:_\s\/\.-]+)'}(.*)$/)
	{
		$line =3D $1.$Lang::gt->get('$2').$3; #Why originally a =20
reference to $Lang::gt->get<text>('$2')? \$ creates a refence
	}
	return $line;
}


--=20
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xD3C9A00E
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE3E80917
--------------------------------------------------------------
BOFH excuse #323:

Your processor has processed too many instructions.  Turn it off =20
immediately, do not type any commands!!

On 24 Jun 2006, at 14:16, Achim Weber wrote:

snip...

> As for the generation of the message files, we already have a small
> perl script which checks for translations:
> http://ipcop.cvs.sourceforge.net/ipcop/ipcop/tools/check_strings.pl? 
> revision=1.3&view=markup
> I have modified this script for my BOT addon where it generates the
> BOT language files. So we can go the OO-way with gettext and use this
> script to generate the ascii-gettext files (IIRC these are the .po
> files?).

The check_strings.pl script is used to see if there are any  
untranslated, or unused, phrases in the cgi codebase. I'm not sure if  
the current script will work on v1.5, as it was designed for v1.4.  
The current v 1.4 version also fails to find translation strings in  
the 'makegraphs' script, and the logs.cgi sub-directory IIRC, so it  
has to be used bearing this points in mind. I have found it a very  
useful tool over the years.

The script that downloads the language files from the IPCop Language  
Database is called fetchlangs.pl
http://ipcop.cvs.sourceforge.net/ipcop/ipcop/tools/fetchlangs.pl? 
view=log
Alan modified it to work for v1.5

I think we could look at adding your new phrases to the Language  
Database after v1.4.11 is released, unless we want to modify the  
whole system?

Eric

Hi Michael, hi Ivan,

> On Friday 23 June 2006 17:32, Michael Rasmussen wrote:
>> Hi Achim, and the rest of you guys
>>
>> Do you need a hand converting all the cgi's to use gettext?
>> I have a great deal of experience using gettext in various projects -
>> it sort of is a requirement contributing to Gnome and/or Debian. I am
>> no perl hacker, but I no how to get around:-)


> Michael,

> I think Achim already committed a perl script to do the conversion.

> IvanK.

Yes I have committed a convert script to CVS - HEAD in tools/ dir:
http://ipcop.cvs.sourceforge.net/ipcop/ipcop/tools/convertLangsToGettext.pl?revision=1.1&view=markup

Michael, do you know a way around the Perl-Reference issue where the
gettext can't be used inside a print-command:
http://marc.theaimsgroup.com/?l=ipcop-devel&m=115097906018345&w=2

As for the generation of the message files, we already have a small
perl script which checks for translations:
http://ipcop.cvs.sourceforge.net/ipcop/ipcop/tools/check_strings.pl?revision=1.3&view=markup
I have modified this script for my BOT addon where it generates the
BOT language files. So we can go the OO-way with gettext and use this
script to generate the ascii-gettext files (IIRC these are the .po
files?). 

When we find a way to use gettext inside print or how we solve the
issue, we are done with gettext conversion :-)

Achim

Feature Requests item #1511758, was opened at 2006-06-24 13:25
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=1511758&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
Submitted By: Hanjo Viets (hanjov)
Assigned to: Nobody/Anonymous (nobody)
Summary: Kernel 2.6

Initial Comment:
Hi,

this might be a silly "feature request", but it would
be great to see the next IPCop (1.5 ?) running on
Kernel 2.6.

e.g. it would be easier to use more recent drivers oder
modules, for example mISDN/vISDN.

I'm really looking forward to see this great project
getting even greater :-) 

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

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

On Friday 23 June 2006 17:32, Michael Rasmussen wrote:
> Hi Achim, and the rest of you guys
>
> Do you need a hand converting all the cgi's to use gettext?
> I have a great deal of experience using gettext in various projects -
> it sort of is a requirement contributing to Gnome and/or Debian. I am
> no perl hacker, but I no how to get around:-)


Michael,

I think Achim already committed a perl script to do the conversion.

IvanK.

Hi Achim, and the rest of you guys

Do you need a hand converting all the cgi's to use gettext?
I have a great deal of experience using gettext in various projects - =20
it sort of is a requirement contributing to Gnome and/or Debian. I am =20
no perl hacker, but I no how to get around:-)

--=20
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xD3C9A00E
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=3Dget&search=3D0xE3E80917
--------------------------------------------------------------
panic("Attempted to kill the idle task!");
         linux-2.2.16/kernel/exit.c

Hi folks,

An error occurred when I try to build a ipcop

bucomm.o: In function `make_tempname':
bucomm.c:(.text+0x3f8): warning: the use of `mktemp' is dangerous,
better use `mkstemp'
bucomm.o: In function `make_tempname':
bucomm.c:(.text+0x3f8): warning: the use of `mktemp' is dangerous,
better use `mkstemp'
make[4]: Leaving directory
`/home/ipcop-1.4.10/build/usr/src/binutils-build/binutils'
make[3]: Leaving directory
`/home/ipcop-1.4.10/build/usr/src/binutils-build/binutils'
make[2]: Leaving directory
`/home/ipcop-1.4.10/build/usr/src/binutils-build/binutils'
make[1]: Leaving directory `/home/ipcop-1.4.10/build/usr/src/binutils-build'
make: *** [/home/ipcop-1.4.10/log/binutils-2.15.90.0.3-tools1] Error 2


I building ipcop1.4.10, and i try to build  in Debian sarge.

Tks
-- 
Serrano Neves - a.k.a eth0 / www.serrano.neves.eti.br
"Talk is cheap. Show me the code." - Linus Torvalds

ry...@zo...(Ryan)  12.06.06 06:31


>I noticed two (undocumented that I could find) features in IPCop
>1.4.10.

That are the "usual" sshd features.


>- TCP Wrappers
>IPCop comes with TCP wrappers installed. TCP wrappers are simple way
>to provide access control to SSH.

That's not really new for admins using ssh.

To prevent that stupid password crackers with chinese IPs
will litter the logfile, every "admin only sshd" should have

a hosts.deny 
ALL:PARANOID
or
ALL:ALL except xxx.xxx.xxx.

an a host.allow with 
sshd: xxx.xxx.xxx.
or for teh less parnoids:
sshd: xxx.xxx.xxx. .yourdamain.tld

>By putting ALL: 216.0.0.0/8 into the file /etc/hosts.deny, all IP
>addresses from that block will not be able to login via SSH, even if I
>open port 222 to the outside.

Yes. it'a a really good idea to have a second, independent protection!



>- SSH Tunneling
>SSH tunneling works well with Squid. Using putty, or the openSSH
>client, I can push http/https/ftp traffic 

ftp traffic? really?

>down an SSH tunnel from the 'net, and configure 
>my web browser to use squid. 
>I can browser the web, or local http/https servers (webcams, etc) 
>that aren't open to the net.

Yes.
I would recommand the team to get rid of the ugly 445-hack.
Port 445 is closed on many many networks, port 22 (or 222) is not.

Using "authorized_keys" one can restrict the tunnel account excatly 
to allow only that one tunnel from that machine to this server.



>I think these are great features. Do you guys need any help
>documenting them?

2 or three years ago i made several posting to the ipcop list
how to make secure tunnel. But sorry, there was no response.

>Integrating TCP Wrappers into the webgui should be simple, but the SSH
>tunneling example has a problem - it requires I ssh into IPCop with
>the root password. 

The paraanoid will first create a "tunnel user" with the shell "/bin/false".
Than you will generate authorized_keys which only allows port forwarding.
Those keys can be placed under "root" if you trust yourself in never doing
any error.

>If intergrated into the webgui, the user would need
>the ability to create regular accounts.

No.
Only several ssh-public-keys and rules are to be copied 
into "~tunneluser/.shh/authorized_keys"

Each remote tunnel will get his own key.
There is no need to generate a separate user account for each.
("root" would be secure enough too..)

besides security: The user can change his authorized_keys, 
but is that really advantage if every remote user can pin whole 
the firewall?
So a dummy user "tunneluser" which can only be changed using root
persmission is OK.
(His home and the files should be only writable by root,
not the tunnel user!)

A typical line (a single line without any unquoted " "!)
to forward the uucp port

command="/bin/sleep 1d",no-pty,no-X11-forwarding,no-agent-forwarding,
from="*.dyn-dialup.tld",permitopen="uucp.provider.tld:540",
permitopen="11.22.44.66:540" ssh-rsa AA...1000bytes..= rsa-key-2006 uucp

(That's one long single line)
The execution of the "command" "/bin/sleep 1d" is suppressed
by the parameter "-N" to putty.
A "/bin/false" does not work at that place, but don't
know why, when the command is not executed...?


To open the tunnel you only need (for windows)

----------------------------
set USER=username
set KEY=%KEYPATH%uucp.ppk
:: UUCP
set SERVER=uucp.toppoint.de
set SERVER=11.22.44.66
set LOCAL=540
set REMOT=540 
set FW=%FW% -L %LOCAL%:%SERVER%:%REMOT%
set SSHHOST=11.22.33.55
set SSHPORT=222

set PARAM=  -N -2 -T -x    -i %KEY%
plink %PARAM% %USER%@%SSHHOST% -P %SSHPORT% %FW%

---------------------
Rainer---<=====>                         Vertraulich
             //  
           //                              
         <=====>--------------ocholl, Kiel, Germany ------------

> Assuming we want to keep this help message in v1.4.11 (and my
> personal preference is to revert to the v1.4.10 version without it),
> how do we want to rephrase it?

Revert to 1.4.10 or at least move the blob behind the text like in all
other pages:
  [x] SSH Access <blob>

> 1. "To allow management of IPCop from the RED network, add a rule on
> the External Access page to open Port 222."

> Please add alternatives for discussion...

"IPCop SSH uses the non-standard Port 222!"

No text regarding External Access, only a tip about the different ssh
port.

> Eric

Achim

>> Hi All,
>>
>> I did a cvs checkout and installation of 1.4.11 the other day and
>> noticed the following 'help' in remote.cgi (SSH access):
>>
>> 'Add external access (port 222) to allow management from RED  
>> interface'
>>
>> I sure hope that this is a textual error, because opening 222 for  
>> RED in
>> *that* screen is a serious mistake IMHO.
>> If this is a textual error I suggest changing in something like
>> 'IPCop SSH access uses port 222'
>> The details of opening on Green / Blue can be left to the manual.
>>
>>
>> If this is not a textual error I suggest reverting back to the 1.4.10
>> mechanism. Opening 222 on RED should be from External Access.
>
> I agree it is not clear enough that it is an advice and not an  
> action made
> by checking the box.
> It is intended only to be a help message. Behavior has not changed  
> there.
> An action in external access is still necessary.
>
> Gilles

Assuming we want to keep this help message in v1.4.11 (and my  
personal preference is to revert to the v1.4.10 version without it),  
how do we want to rephrase it?

1. "To allow management of IPCop from the RED network, add a rule on  
the External Access page to open Port 222."

Please add alternatives for discussion...

Eric