ipcop-devel Mailing List for IPCop Firewall

Gilles,
> Revision: 2393
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=2393&view=rev
> Author:   gespinasse
> Date:     2009-01-27 07:21:04 +0000 (Tue, 27 Jan 2009)
>
> Log Message:
> -----------
> Don't include any modules.*map files on ppc for now
> map files are not required but may help to understand what hardware id are supported.
>   

modules.pcimap is used by the installer/setup to be able to load proper 
module if there is no info in discover-data XML file.

I do not fully remember which network card, but there is a case where a 
PCI id is found and reported by libdiscover with no modulename in the 
XML file. In this case the hardware detection looks in modules.pcimap 
and tries to find the kernel module.


Olaf

-- 

A weizen a day helps keep the doctor away.

Hello Robert,

>> --> Orange will not have the half-open policy, the DMZ is completely
>> seperated from IPCop and green, blue.
> 
>> Yes it makes it somewhat different from green and blue and yes I know 
>> this is a trade off, but is the best approach for a DMZ if you ask me.
> 
> What access does orange have to IPCop services? none like at present?

Exactly. No dhcp, no dns, no ntp, no nothing.
The options would be open (udp/tcp access to internet) or closed (no 
access to internet without user firewall rules).
We should probably consider to add icmp (type 8, echo-request) as this 
is often missed for testing purposes.


>> Currently in 1.4 we have no restrictions for green -> blue+orange and 
>> for blue -> orange.
> 
>> We can either follow the same principle or (my personal favorite) have 
>> these restrictions between interfaces configurable on the same page 
>> where the policy is defined.
> 
> Seems silly not to have them configurable really. Though then you have
> to think about how far you take it I guess.
> 
> Some people have in the past wanted to have two 'green' interfaces that
> can both talk to ipcop/internet but not to each other. If the
> configuration was on a per-NIC basis rather than per-zone this could be
> possible. Might be making things too complex though, maybe an addon
> could be created to allow such functionality at a later date.

I think that is doable.
Also the user rule creation possibilities in the GUI are quite flexible 
and powerful. But I would prefer the basics to be only a single click 
away, to give an easy and good IPCop-feeling.


> The best approach seems to be to implement it as you have described then
> see how easy to use it is in various scenarios. It's sometimes hard to
> think up problems when reading about something that are relatively
> obvious when trying it.

Yes. We will work on this, gradually and SVN may be broken from time to 
time.
After the firewall changes are finished I want to do an alpha-1 release, 
to make it much easier to install, play around and watch the iptables 
rules that are created through the various options.


Olaf

-- 

A weizen a day helps keep the doctor away.

On Sat, 2009-01-24 at 16:44 +0100, Olaf Westrik wrote:

> --> Orange will not have the half-open policy, the DMZ is completely
> seperated from IPCop and green, blue.

> Yes it makes it somewhat different from green and blue and yes I know 
> this is a trade off, but is the best approach for a DMZ if you ask me.

What access does orange have to IPCop services? none like at present?

> Currently in 1.4 we have no restrictions for green -> blue+orange and 
> for blue -> orange.

> We can either follow the same principle or (my personal favorite) have 
> these restrictions between interfaces configurable on the same page 
> where the policy is defined.

Seems silly not to have them configurable really. Though then you have
to think about how far you take it I guess.

Some people have in the past wanted to have two 'green' interfaces that
can both talk to ipcop/internet but not to each other. If the
configuration was on a per-NIC basis rather than per-zone this could be
possible. Might be making things too complex though, maybe an addon
could be created to allow such functionality at a later date.

The best approach seems to be to implement it as you have described then
see how easy to use it is in various scenarios. It's sometimes hard to
think up problems when reading about something that are relatively
obvious when trying it.

-- 
 Robert Kerr

Robert Kerr wrote:

> In general the basics seem sound, but it doesn't seem to cover the
> restrictions between zones/interfaces? Also though it says orange will
> be separate I'm not clear what the restrictions will be there either. At
> the minute orange allows all to the internet but nothing to ipcops
> services which doesn't seem to fit neatly into the open/half-open/closed
> definition?


--> Orange will not have the half-open policy, the DMZ is completely
seperated from IPCop and green, blue.

Yes it makes it somewhat different from green and blue and yes I know 
this is a trade off, but is the best approach for a DMZ if you ask me.


Currently in 1.4 we have no restrictions for green -> blue+orange and 
for blue -> orange.

We can either follow the same principle or (my personal favorite) have 
these restrictions between interfaces configurable on the same page 
where the policy is defined.


> I guess there's also the question of how much a basic user has to think
> about? are there sane defaults similar to an existing IPCop install or
> are we forcing the user to choose a value for all these settings.

IMHO the defaults should be as close as possible to IPCop 1.4 behavior.

Which would be this:
  - green selected as maintenance network (https and ssh)
  - green is open (full access to internet, access to IPCop services)
  - green can access blue and orange
  - blue is open with "Blue access" activated (full access to internet, 
access to IPCop services)
  - blue can access orange
  - orange is open (full access to internet)



Olaf

-- 

A weizen a day helps keep the doctor away.

On Sat, 2009-01-24 at 13:50 +0100, Olaf Westrik wrote:
> This is an (incomplete) overview of the IPCop 2.0 firewalling.
> Please note that this is not a vision, but more a description of bits 
> and pieces already in place and things that are currently being worked 
> on by Achim and myself.
> I am sure that there is something I have forgotten to explain, or things 
> may not become fully clear (even after reading twice).  But here goes ...

In general the basics seem sound, but it doesn't seem to cover the
restrictions between zones/interfaces? Also though it says orange will
be separate I'm not clear what the restrictions will be there either. At
the minute orange allows all to the internet but nothing to ipcops
services which doesn't seem to fit neatly into the open/half-open/closed
definition?

I guess there's also the question of how much a basic user has to think
about? are there sane defaults similar to an existing IPCop install or
are we forcing the user to choose a value for all these settings.

-- 
 Robert Kerr

This is an (incomplete) overview of the IPCop 2.0 firewalling.
Please note that this is not a vision, but more a description of bits 
and pieces already in place and things that are currently being worked 
on by Achim and myself.
I am sure that there is something I have forgotten to explain, or things 
may not become fully clear (even after reading twice).  But here goes ...

Olaf


= Introduction =

The standard behaviour of the network interfaces will be modifiable. 
Target is not to have full flexibility which would lose ease of use, but 
to have the option to choose between different policies.
The policies are named open, half-open and closed and can be applied to 
green, blue and orange.


= User perspective =

The GUI has a page Firewall Settings, which offers following settings:
 - which networks are allowed access to IPCop maintenance (https and ssh)
 - several other global settings
 - policy choice for green, blue and orange interface.

Additional pages are available to define custom names for addresses (IP 
addresses and networks) and services (udp/tcp ports etc.), these names 
can also be grouped and later used (single or as a group) for user 
firewall rule creation.

The user firewall rules include all variations, from IPCop access for a 
specific service, internet access for a specific service, portforwards, 
pinholes. User rules can either be ACCEPT, DROP, REJECT, be used with or 
without logging and have an optional timeframe.


= IPCop services =

The firewall rulesset will be more restrictive for IPCop access (INPUT 
chain) and only allow packets for user enabled services. Services are 
for example DHCP, DNS, NTP, Proxy but also IPsec and OpenVPN.


= Interface policy =

Open means full access to internet and access to IPCop services.
Half-open is access to IPCop services only thus enforcing proxy usage.
Closed means exactly that: closed.
In all cases it is possible to create user firewall rules which can 
selectively enable or disable IPCop services, outgoing traffic, etc.

In the case of blue there will be an additional restriction based on MAC 
and/or IP address (Blue access), this restriction can easily be disabled 
through the firewall settings. So the IPCop admin will have an easy 
choice between 1.4 blue behaviour or using blue as a second green.

Orange will not have the half-open policy, the DMZ is completely 
seperated from IPCop and green, blue.


= Technical (developer) points =

The iptables chain order will be roughly ACCOUNTING, BADTCP, CUSTOM_* 
(addons and rc.firewall.local), FW_* (user firewall rules), IPCOP_* 
(access to IPCop services), LOG_DROP.

The global framework to be created by rc.firewall.
A perl script (puzzleFwRules.pl) to create or recreate the contents of 
FW_* and/or IPCOP_* in case of GUI changes.
puzzleFwRules.pl called through setfwrules, a SUID helper program.
The GUI helper programs (for example restartdhcp, restartsquid) will 
call setfwrules with parameter --ipcop to recreate the contents of IPCOP_*.


-- 

A weizen a day helps keep the doctor away.

Gilles Espinasse wrote:

>>> As I say in my commit message, I have seen that Mandriva use NO_HZ.
>>> We could try, that will probably work for the current in-tree drivers but I
>>> don't know what will happen on some out of tree drivers and maybe some
>>> rarely used in-tree drivers.
>>>
>>> For now, I will revert to 1000 and we will see later.

OK.


>> Is it worth setting up a NO_HZ branch for driver testing?
>>
> I don't think we should start having a different kernel branch actually until we
> have a packaging system.
> 
> We may set NO_HZ on svn and see what happen with more testers, particulary on
> the low end and with out of tree drivers.

OK.

I prefer to have only 1 kernel.
If we see a big problem to combine i486, good high speed traffic 
shaping, etc. than we can decide what to do:
- drop a feature (traffic shaping)
- drop support for a CPU (i486)
- have 2 branches or multiple target ISOs

FYI: in this particular situation I would choose for high speed traffic 
shaping and drop i486.  But let us first see if we have a real problem here.

To be able to do that (with more testers) I plan to release an alpha 
version in some weeks.
I am currently thinking and working together with Achim on sanitizing 
our firewall rules and firewall configuration possibilities.
This will take some time but the ideas are very good IMHO and look 
promising. I will write up a description in the next days.


> Is there too a reason why we have CONFIG_COMPAT_BRK=y set?
> It's set only on i486 and sparc arch but not on ppc.*
> CONFIG_COMPAT_BRK=y mean that heap randomization is disabled

Not really. Must have come from my change from .24 to .25, but there is 
no special reason for it AFAIK.


Olaf

-- 

A weizen a day helps keep the doctor away.

Selon David Raine <ra...@gm...>:

...
> > As I say in my commit message, I have seen that Mandriva use NO_HZ.
> > We could try, that will probably work for the current in-tree drivers but I
> > don't know what will happen on some out of tree drivers and maybe some
> > rarely used in-tree drivers.
> >
> > For now, I will revert to 1000 and we will see later.
> >
>
> Is it worth setting up a NO_HZ branch for driver testing?
>
> Regards
> David
>

I don't think we should start having a different kernel branch actually until we
have a packaging system.

We may set NO_HZ on svn and see what happen with more testers, particulary on
the low end and with out of tree drivers.

Is there too a reason why we have CONFIG_COMPAT_BRK=y set?
It's set only on i486 and sparc arch but not on ppc.*
CONFIG_COMPAT_BRK=y mean that heap randomization is disabled

There has been a typo in the help text that mismatch the recommended safe value
some time ago.
http://lkml.indiana.edu/hypermail/linux/kernel/0802.0/3413.html

Gilles

2009/1/23 Gilles Espinasse <g....@fr...>

>
> >> We have only 100,250,300 and 1000 values for CONFIG_HZ.
> >>
> > Not sure where you are getting the quantised values from
> > - I can build a 2.6 kernel with CONFIG_HZ=N where N is any integer.
> >
> not me
> ./make.sh shell
> cd /usr/src/linux*
> make menuconfig
>

Ah, yes menuconfig limits it, but we can set manually any value.



> > Sadly, CONFIG_HZ=250 will limit shaping of the upstream connection above
> > 1Mbit/sec on pppoe, so if you take that route, QoS is probably not useful
> over
> > ATM transports such as ADSL.
> >
> E in PPPoE mean ethernet, so you no more have atm cells on IPCop machine
> unless using a native atm driver plus br2684. On 2.6, this will be limited
> to pulsar and cnx pci driver plus usb adsl modems.
>

The real issue with QoS is there. Using pppoe with an ethernet-connected
ADSL modem, we actually need to time the upstream traffic to match the ATM
underlying transport - shaping for the tightest link, so we must still
consider that we are on ATM.


>  > My view would be that we should increase this to 1024 as a minimum, with
> an
> > option for 4096 for those with DSL 24Mbit/sec upstream. Of course, this
> needs
> > a fast CPU and memory subsystem.
>
> that's a problem when in the same time we try to set something workable on
> a
> real i486 or P-I / AMD K6
>

I agree -  it would be much better to use a different timer, one that is not
dependent on creating idle cycles. If we use NO_HZ, this is possible.

Specifically, we are targeting 2.6.27.y fro 2.0, not 2.6.28 and later for
> probably a not short time.
> 2.6.27 has been announced to be maintained as long as 2.6.16.
>

That will do.


> As I say in my commit message, I have seen that Mandriva use NO_HZ.
> We could try, that will probably work for the current in-tree drivers but I
> don't know what will happen on some out of tree drivers and maybe some
> rarely used in-tree drivers.
>
> For now, I will revert to 1000 and we will see later.
>

Is it worth setting up a NO_HZ branch for driver testing?

Regards
David

----- Original Message ----- 
From: David Raine
To: Gilles Espinasse
Cc: IPCop devel ; Olaf Westrik
Sent: Thursday, January 22, 2009 9:03 AM
Subject: Re: [Ipcop-svn] SF.net SVN: ipcop:[2363]
ipcop/trunk/config/kernel/kernel.config.i486


>> ...
>>> Totally agree. We need at the very least 512 to properly QoS an ADSL
upload stream of
>>> 2Mb/sec and up to 1024 to handle the faster 8Mb/sec plus schemes.
>>> HZ is not an issue with non-ADSL upstream traffic, as this does not need
the sub-frame
>>> ADSL alignment timing.
>>>
>>
>> We have only 100,250,300 and 1000 values for CONFIG_HZ.
>>
>>
>>
> Not sure where you are getting the quantised values from
> - I can build a 2.6 kernel with CONFIG_HZ=N where N is any integer.
>
not me
./make.sh shell
cd /usr/src/linux*
make menuconfig
    processor type and features
        time frequency
I can't there enter an integer value.

>> I didn't know for shaping.
>> I think there is now far less modem connected with native ADSL traffic,
>> most have switched to ethernet layer.
>>
>> I have too lowered CONFIG_HZ as a safety against lost interrupt that
>> will probably happen with some ethernet not napi drivers.
>>
>> I have look at Ubunbu server config and they have CONFIG_HZ=100
>> and a few users that complain for related side effect.
>>
>> So I am afraid we need a compromize.
>>
>> Do you agree for CONFIG_HZ=250?
>>
>> Gilles

>
> Sadly, CONFIG_HZ=250 will limit shaping of the upstream connection above
> 1Mbit/sec on pppoe, so if you take that route, QoS is probably not useful
over
> ATM transports such as ADSL.
>
E in PPPoE mean ethernet, so you no more have atm cells on IPCop machine
unless using a native atm driver plus br2684. On 2.6, this will be limited
to pulsar and cnx pci driver plus usb adsl modems.

New Traverse adsl2+ modem output directly ethernet traffic.

> My view would be that we should increase this to 1024 as a minimum, with
an
> option for 4096 for those with DSL 24Mbit/sec upstream. Of course, this
needs
> a fast CPU and memory subsystem.

that's a problem when in the same time we try to set something workable on a
real i486 or P-I / AMD K6

> If we are targetting 2.6.27+ then I will also look at options for
different timers,
> and we could possibly run tickless CONFIG_NO_HZ - which would really help
> power management and neatly sidesteps the issue. Forgive me, I'm not up to
speed
> on whick kernel is in the current builds, but if it is a recent 2.6, would
you consider
> going CONFIG_NO_HZ?
>
> David

Specifically, we are targeting 2.6.27.y fro 2.0, not 2.6.28 and later for
probably a not short time.
2.6.27 has been announced to be maintained as long as 2.6.16.

As I say in my commit message, I have seen that Mandriva use NO_HZ.
We could try, that will probably work for the current in-tree drivers but I
don't know what will happen on some out of tree drivers and maybe some
rarely used in-tree drivers.

For now, I will revert to 1000 and we will see later.

Gilles

2009/1/22 Gilles Espinasse <g....@fr...>

>
> ----- Original Message -----
> From: David Raine
> To: IPCop devel
> Cc: Gilles Espinasse ; Olaf Westrik
> Sent: Wednesday, January 21, 2009 10:02 PM
> Subject: Re: [Ipcop-svn] SF.net SVN: ipcop:[2363]
> ipcop/trunk/config/kernel/kernel.config.i486
>
>
> ...
> > Totally agree. We need at the very least 512 to properly QoS an ADSL
> upload stream of
> > 2Mb/sec and up to 1024 to handle the faster 8Mb/sec plus schemes.
> > HZ is not an issue with non-ADSL upstream traffic, as this does not need
> the sub-frame
> > ADSL alignment timing.
> >
>  We have only 100,250,300 and 1000 values for CONFIG_HZ.
>

Not sure where you are getting the quantised values from - I can build a 2.6
kernel with CONFIG_HZ=N where N is any integer.


>
> I didn't know for shaping.
> I think there is now far less modem connected with native ADSL traffic,
> most
> have switched to ethernet layer.
>
> I have too lowered CONFIG_HZ as a safety against lost interrupt that will
> probably happen with some ethernet not napi drivers.
>
> I have look at Ubunbu server config and they have CONFIG_HZ=100 and a few
> users that complain for related side effect.
>
> So I am afraid we need a compromize.
>
>
> Do you agree for CONFIG_HZ=250?
>
> Gilles
>
>
Sadly, CONFIG_HZ=250 will limit shaping of the upstream connection above
1Mbit/sec on pppoe, so if you take that route, QoS is probably not useful
over ATM transports such as ADSL.

My view would be that we should increase this to 1024 as a minimum, with an
option for 4096 for those with DSL 24Mbit/sec upstream. Of course, this
needs a fast CPU and memory subsystem.

If we are targetting 2.6.27+ then I will also look at options for different
timers, and we could possibly run tickless CONFIG_NO_HZ - which would really
help power management and neatly sidesteps the issue. Forgive me, I'm not up
to speed on whick kernel is in the current builds, but if it is a recent
2.6, would you consider going CONFIG_NO_HZ?

David

----- Original Message ----- 
From: David Raine
To: IPCop devel
Cc: Gilles Espinasse ; Olaf Westrik
Sent: Wednesday, January 21, 2009 10:02 PM
Subject: Re: [Ipcop-svn] SF.net SVN: ipcop:[2363]
ipcop/trunk/config/kernel/kernel.config.i486


...
> Totally agree. We need at the very least 512 to properly QoS an ADSL
upload stream of
> 2Mb/sec and up to 1024 to handle the faster 8Mb/sec plus schemes.
> HZ is not an issue with non-ADSL upstream traffic, as this does not need
the sub-frame
> ADSL alignment timing.
>
 We have only 100,250,300 and 1000 values for CONFIG_HZ.

I didn't know for shaping.
I think there is now far less modem connected with native ADSL traffic, most
have switched to ethernet layer.

I have too lowered CONFIG_HZ as a safety against lost interrupt that will
probably happen with some ethernet not napi drivers.

I have look at Ubunbu server config and they have CONFIG_HZ=100 and a few
users that complain for related side effect.

So I am afraid we need a compromize.


Do you agree for CONFIG_HZ=250?

Gilles

2009/1/21 Olaf Westrik <wei...@ip...>

> ges...@us... wrote:
>
>> Revision: 2363
>>          http://ipcop.svn.sourceforge.net/ipcop/?rev=2363&view=rev
>> Author:   gespinasse
>> Date:     2009-01-21 07:19:05 +0000 (Wed, 21 Jan 2009)
>>
>> Log Message:
>> -----------
>> Reduce HZ to 100, we are not a desktop.
>>
>>
>
> True.
>
> But it is my understanding that higher HZ is necessary for better traffic
> shaping.
>

Totally agree. We need at the very least 512 to properly QoS an ADSL upload
stream of 2Mb/sec and up to 1024 to handle the faster 8Mb/sec plus schemes.
HZ is not an issue with non-ADSL upstream traffic, as this does not need the
sub-frame ADSL alignment timing.

David

ges...@us... wrote:
> Revision: 2363
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=2363&view=rev
> Author:   gespinasse
> Date:     2009-01-21 07:19:05 +0000 (Wed, 21 Jan 2009)
>
> Log Message:
> -----------
> Reduce HZ to 100, we are not a desktop.
>   

True.

But it is my understanding that higher HZ is necessary for better 
traffic shaping.


Olaf

PS: IIRC David did some QoS investigating, maybe he knows a good HZ 
approach ?

-- 

A weizen a day helps keep the doctor away.

Feature Requests item #2524328, was opened at 2009-01-20 12:37
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=2524328&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: Next release
Status: Open
Priority: 5
Private: No
Submitted By: John H (jhallford)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add GRE Protocol to DMZ Pinhole Page

Initial Comment:
Please consider adding the GRE protocol to the DMZ Pinhole page. Currently, it is only available on the Port Forwarding page.

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

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

Gilles Espinasse wrote:
> Update of /cvsroot/ipcop/ipcop/config/cfgroot
> In directory 23jxhf1.ch3.sourceforge.com:/tmp/cvs-serv14107/config/cfgroot
>
> Modified Files:
>       Tag: IPCOP_v1_4_0
> 	general-functions.pl 
> Log Message:
> Escape the dot from the RE filtering .x and .y
> It was previously filtering any variables ending with x or y like verbosity
> Thank to Frank for the bug report and solution
>   

Would it not be better to simply discard any variable with a . ? Not 
just the onces followed by (lower-case) x or y ?

That would also better match the readhash sub and readhash script.


Olaf

-- 

A weizen a day helps keep the doctor away.

Bugs item #2515920, was opened at 2009-01-17 17:43
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=2515920&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: General
Group: 1.4.21
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Franck Bourdonnec (franck78)
Assigned to: Gilles Espinasse (gespinasse)
Summary: writehash bug

Initial Comment:
Hi,
In general-functions.pl the writehash() function is supposed to eliminate variables having names ending by'.x' or '.y'
Unfortunatly, points are not protected and replace any char, eliminating any variagle with names like 'verbosity'

               if (!($var =~ /(.x|.y)$/)) {

should be
1) removed if the mouse problem is gone away
2) or             if (!($var =~ /\.(x|y)$/)) {


Franck

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

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

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

>
> Just to make sure, are we agreed upon moving the lib .pl files from
> /var/ipcop and /var/ipcop/firewall into /usr/lib/ipcop ?
>
> For example header.pl, general-functions.pl, traffic-lib.pl and others
>
>
> At the same time I will move these files in SVN from config/cfgroot into
> (to be created) src/library.
> Also take them out of lfs/ipcop and put them in lfs/misc-progs
>
>
All is fine for me.

Gilles

On Wed, Jan 14, 2009 at 07:36:27AM +0100, Achim Weber (dot...@gm...) wrote:

> > Just to make sure, are we agreed upon moving the lib .pl files from
> > /var/ipcop and /var/ipcop/firewall into /usr/lib/ipcop ?
> 
> Hi Olaf
> 
> this is fine with me, go for it.

I'm happy with that as well (it's even quite consistent with FSH,
even if some other parts of ipcop aren't).

-- 
Tapani Tarvainen

> Just to make sure, are we agreed upon moving the lib .pl files from
> /var/ipcop and /var/ipcop/firewall into /usr/lib/ipcop ?

Hi Olaf

this is fine with me, go for it.

Achim

Just to make sure, are we agreed upon moving the lib .pl files from
/var/ipcop and /var/ipcop/firewall into /usr/lib/ipcop ?

For example header.pl, general-functions.pl, traffic-lib.pl and others


At the same time I will move these files in SVN from config/cfgroot into
(to be created) src/library.
Also take them out of lfs/ipcop and put them in lfs/misc-progs


Olaf


PS: remember to send to list instead to self next time :-(

-- 

A weizen a day helps keep the doctor away.

Gilles Espinasse wrote:

> Move lib .pl files to /usr/lib/ipcop?
> 
> That way, it is clearly separated from common linux stuff.

Fine with me.
I'll do that in the next days.


> For the files actually in /usr/local/bin, I haven't a clear better solution in
> my mind. FHS is not a goal for me, just a guideline.

We'll just leave everything else in place.


Olaf

-- 

A weizen a day helps keep the doctor away.

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

> Gilles Espinasse wrote:
>
> >> Log Message:
> >> -----------
> >> exclude var/ipcop/vpn-functions.pl from backup
> >>
> > Should we not move all that code somewhere out of /var/ipcop, probably in
> > /usr/local/bin, so probably moving the script to src/script in the tree?
>
> Not sure what the best place is for those files containing helper functions.
> Maybe we should put all of /var/ipcop/*.pl and /var/ipcop/firewall/*.pl
> in some directory specifically for these?
> Something like /usr/local/share/ipcop ?
>
>
> Olaf
>
Move lib .pl files to /usr/lib/ipcop?

That way, it is clearly separated from common linux stuff.

For the files actually in /usr/local/bin, I haven't a clear better solution in
my mind. FHS is not a goal for me, just a guideline.


Gilles

On Mon, Jan 12, 2009 at 02:09:31PM +0000, John Edwards (jo...@co...) wrote:

> /opt is for optional application software, which these programs
> are not (optional or applications).

That's somewhat debatable, or a matter of viewpoint:
if we want to keep ipcop stuff separate of "OS stuff",
it's logical to consider it an application which belongs in /opt,
otherwise it's part of the OS and belongs in the main hierarchy.
In neither case is /usr/local appropriate.

But I don't think too much weight should be given to
standards-adherence, certainly not enough to warrant
hair-splitting about optionality of stuff in /opt or the like.
Practical considerations are more important.

> Also /opt/bin is not part of the default $PATH and it would require
> work to rewrite a lot of scripts for the new hard-coded paths.

True. (Besides, /opt/bin would not be FSH-compatible either,
it'd have to be /opt/ipcop/bin or something like that.)


> There are a
> couple of advantages of moving everything into /usr:
>
> 1) It reduces the number of directories I have to look in to
> find a command.

Yes, although at the cost of burying them among the rest
of system stuff.

> 2) It frees up /usr/local for use by addons.

And by local admins.

I very much like keeping addons clearly distinct from
the base system.
(Actually I'd recommend /opt for add-ons in this
scenario, but as noted, that's somewhat uncontrollable.)


> Disadvantages are:
> 
> 1) Checking scripts for hard-coded paths.

Yes. I don't see this as a big thing at this point, where
all add-ons will have to be rewritten anyway - the main
source should not be too hard to check.

> 2) Possible confusion of old timers, though I'm sure v2.0 will
> include much larger changes.

No biggie, IMHO.

I'd add

3) Confusion and more potential conflicts with add-ons.


If you consider /opt:

1) hard-coded paths have to be checked
2) all ipcop -specific stuff easily separated from the rest
   (both from system and from add-ons);
   I consider this a big advantage, others may not.
3) oldtimers still confused. :-)


So, my prefererences are /opt, second /usr, third /usr/local.

But in any case, subdirectories bin/, lib/ &c should be used
consistently, and guidelines for add-ons thought out in
advance.

-- 
Tapani Tarvainen

On Mon, Jan 12, 2009 at 02:57:16PM +0200, Tapani Tarvainen wrote:
> On Mon, Jan 12, 2009 at 12:20:40PM +0000, John Edwards (jo...@co...) wrote:
> 
>> /usr/local/lib is the most common place to put local library
>> functions, and confirms to the FHS (Filesystem Hierarchy Standard).
> 
> Yes - but _local_ means local to one machine (or site), it is not
> meant for software packages, and it should be empty after system
> installation, and stay that way unless local sysadmin puts something
> in there.
> 
> In case of ipcop it would (IMHO) be within FHS guidelines to use
> /usr/bin, /usr/lib &c, but if you wish to keep ipcop stuff separate
> from regular system files, the appropriate place would be under /opt -
> e.g., /opt/ipcop/lib &c, also /var/opt/ipcop and /etc/opt/ipcop.

That is FHS correct.

As Olaf as said, IPCop stores the IPCop-specific programs in
/usr/local. This is a bit of a historical thing as IPCop and
Shorewall were original built on top of RedHat Linux, and so
you needed to separate out RPM packages from other binaries.

/opt is for optional application software, which these programs
are not (optional or applications). Also /opt/bin is not part
of the default $PATH and it would require work to rewrite a lot
of scripts for the new hard-coded paths.


I'm not too fussed between /usr and /usr/local, There are a
couple of advantages of moving everything into /usr:

1) It reduces the number of directories I have to look in to
find a command.

2) It frees up /usr/local for use by addons.

Disadvantages are:

1) Checking scripts for hard-coded paths.

2) Possible confusion of old timers, though I'm sure v2.0 will
include much larger changes.


But as I am only an occasional contributor it's not my decision
(thankfully).


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