ipcop-devel Mailing List for IPCop Firewall

On Wednesday 31 May 2006 18:57, Franck Bourdonnec wrote:
>
> http://franck78.ath.cx/drivers.cgi
>

Franck,

I get a Not Found
 The requested URL /drivers.cgi was not found on this server.

IvanK.

Le Mercredi 31 Mai 2006 23:44, vous avez =C3=A9crit=C2=A0:
>
> looks good. post it to the devel lists now for others to review and
> comment.
>
> Alan.

OK,

Hello developpers,

some time ago I suggested to write a dummy interface
to check faisability of 'brainstorming' solutions.
So, this 'interface' looks like what is in my minf...
but:
-nothing is behind it, just html
-absolutly not a definitive look

purpose is to answser questions, find what is missing
and where, redundant etc.

One main screen is missing: port translation (NAT). But
we more or less know it. He will add one soon.

Other missing is the glue. Things like
"Add a new XYZ", save, delete, ...

But the question is where to link the VPN.
Is describing it as a 'source object' sufficient?
I think no...

Remenber that the GUI is supposed do be=20
'helped' with a program reading all thoses choices.
We can think 'advanced' combinations and=20
let the 'compiler (ex-magic brain)' resolve case=20
or announces incompatibilities in setup.

This will represent the normal interface.
A beginner mode RED+GREEN (wizard?) is=20
also to be done.

So, take a look, try to imagine what is missing,
misplaced etc etc
and I will correct.

Note that GUI for service available on IPcop=20
won't really changed. They are on top of
routing layer.

start here:

http://franck78.ath.cx/drivers.cgi

and talk!

Franck

Feature Requests item #1495861, was opened at 2006-05-26 22:52
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=1495861&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: Brent Wolsey (bwolsey)
Assigned to: Nobody/Anonymous (nobody)
Summary: Data Transfered Traffic Graphs

Initial Comment:
Team,
A nice addition to the Status | Traffic Graphs would be
graphs that show you how much data has actually flowed
in and out (plus a total) of your network.  

The reason I would like this is because my ISP allows
me to transfer a maximum of 100 Gig a month (actually
25 Gig per week).  They call this "metered traffic" and
currently, all I can track in my IP-Cop is the data
transfer rate.  I'm sure that I could do the math and
figure it out, but why not let the brains between the
internet and my network handle it?

Thanks tons for the consideration and for the GREAT
firewall.

Brent


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

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

OK, I just found that if I set BLUE access by IP/MAC packets will jump
to DMZHOLES. The question is, wont be useful to allow user to define a
default rule like:
	"If there is no explicit allowed MAC, allow all"

I think that doing this the BLUE interface could be use as a second DMZ
or a GUESS network, and not just for wireless access.

Thanks again...

Federico Petronio wrote:
> Hello,
> 
> I write you to ask about a possible bug I found configuring IPCop. The
> installation is a GREEN + ORANGE + BLUE + RED type. I found that when I
> create holes that correspond to traffic from BLUE to GREEN, they do not
> affect the real traffic.
> 
> I searched in the code and I found that the only line referencing
> DMZHOLES is:
> 
> 	-A FORWARD -i eth2 -m state --state NEW -j DMZHOLES
> 
> where eth2 is the ORANGE device, so the packets coming from BLUE (eth1)
>  never "jump" to DMZHOLES.
> 
> I also found that adding theses lines to the rc.firewall file the
> problem gets solved:
> 
>   # BLUE pinhole chain
>   if [ "$BLUE_DEV" != "" ]; then
>     /sbin/iptables -A FORWARD -i $BLUE_DEV -m state --state NEW -j DMZHOLES
>   fi
> 
> nevertheless I would like to hear your opinion on this.
> 
> Thank you!


-- 
                                        Federico Petronio
                                        pe...@ac...

OK, I just found that if I set BLUE access by IP/MAC packets will jump
to DMZHOLES. The question is, wont be useful to allow user to define a
default rule like:
	"If there is no explicit allowed MAC, allow all"

I think that doing this the BLUE interface could be use as a second DMZ
or a GUESS network, and not just for wireless access.

Thanks again...

Federico Petronio wrote:
> Hello,
> 
> I write you to ask about a possible bug I found configuring IPCop. The
> installation is a GREEN + ORANGE + BLUE + RED type. I found that when I
> create holes that correspond to traffic from BLUE to GREEN, they do not
> affect the real traffic.
> 
> I searched in the code and I found that the only line referencing
> DMZHOLES is:
> 
> 	-A FORWARD -i eth2 -m state --state NEW -j DMZHOLES
> 
> where eth2 is the ORANGE device, so the packets coming from BLUE (eth1)
>  never "jump" to DMZHOLES.
> 
> I also found that adding theses lines to the rc.firewall file the
> problem gets solved:
> 
>   # BLUE pinhole chain
>   if [ "$BLUE_DEV" != "" ]; then
>     /sbin/iptables -A FORWARD -i $BLUE_DEV -m state --state NEW -j DMZHOLES
>   fi
> 
> nevertheless I would like to hear your opinion on this.
> 
> Thank you!


-- 
                                        Federico Petronio
                                        fpe...@ac...
                                        Linux User #129974

Hello,

I write you to ask about a possible bug I found configuring IPCop. The
installation is a GREEN + ORANGE + BLUE + RED type. I found that when I
create holes that correspond to traffic from BLUE to GREEN, they do not
affect the real traffic.

I searched in the code and I found that the only line referencing
DMZHOLES is:

	-A FORWARD -i eth2 -m state --state NEW -j DMZHOLES

where eth2 is the ORANGE device, so the packets coming from BLUE (eth1)
 never "jump" to DMZHOLES.

I also found that adding theses lines to the rc.firewall file the
problem gets solved:

  # BLUE pinhole chain
  if [ "$BLUE_DEV" != "" ]; then
    /sbin/iptables -A FORWARD -i $BLUE_DEV -m state --state NEW -j DMZHOLES
  fi

nevertheless I would like to hear your opinion on this.

Thank you!
-- 
                                        Federico Petronio
                                        pe...@ac...

Feature Requests item #1495341, was opened at 2006-05-26 18:24
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=1495341&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 (example)
Status: Open
Priority: 5
Submitted By: Like Magic (likemagic)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow google earth to be proxied

Initial Comment:
We use ipcop to protect 180 computers at a school. 
When you have 30 kids all use google earth at once 
our nz excuse for broadband dies
-note credit goes elsewhere I did not invent this

.
.
.
acl QUERY urlpath_regex cgi-bin \\?
#Maurice Google Tweek begin part 1
acl forcecache url_regex -i kh.google keyhole.com
no_cache allow forcecache
#Maurice Google Tweek end part 1
no_cache deny QUERY
.
.
.

cache_log /var/log/squid/cache.log
cache_store_log none
#Maurice Google Tweek begin part 2
refresh_pattern -i kh.google 1440 20% 10080 override-
expire override-lastmod reload-into-ims ignore-reload
refresh_pattern -i keyhole.com 1440 20% 10080 
override-expire override-lastmod reload-into-ims 
ignore-reload
#Maurice google earth tweek end part 2
.
.
.


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

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

Bugs item #1495337, was opened at 2006-05-26 18:05
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=1495337&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: Web Proxy
Group: 1.4.10
Status: Open
Resolution: None
Priority: 5
Submitted By: Like Magic (likemagic)
Assigned to: Nobody/Anonymous (nobody)
Summary: can not enable pass though authentication

Initial Comment:
There is no way of allowing pass though 
authentication to an upstream proxy - squid requires 
a user name of "PASS" with no password

Requires at a minimum the following code changes
.
.
.
        # Quick parent proxy error checking of 
username and password info. If username password 
don't both exist give an error.
        $proxy1 = 'YES';
        $proxy2 = 'YES';
        if (($proxysettings{'UPSTREAM_USER'} eq '')) 
{$proxy1 = '';}
        # reworked following line maurice
        if (($proxysettings{'UPSTREAM_USER'} 
ne 'PASS') && ($proxysettings{'UPSTREAM_PASSWORD'} 
eq '')) {$proxy2 = '';}
        if (($proxy1 ne $proxy2))
        {
                $errormessage = $Lang::tr{'advproxy 
errmsg invalid upstream proxy username or password 
setting'};
                goto ERROR;
        }
.
.
.
	# Write the parent proxy info, if needed.
	if ($remotehost ne '')
	{
		# Enter authentication for the parent 
cache (format is login=user:password)
              # reworked maurice
		if ($proxy1 eq 'YES') {
                   if ($proxysettings
{'UPSTREAM_USER'} eq 'PASS'){
                       print FILE "cache_peer 
$remotehost parent $remoteport 3130 
login=$proxysettings{'UPSTREAM_USER'} default no-
query";
                       print FILE "\n"
                   }else{ 
		          print FILE <<END
cache_peer $remotehost parent $remoteport 3130 
login=$proxysettings{'UPSTREAM_USER'}:$proxysettings
{'UPSTREAM_PASSWORD'} default no-query


END
		;
                   } 
		} else {
		# Not using authentication with the 
parent cache
		print FILE "cache_peer $remotehost 
parent $remoteport 3130 default no-query";
		if ($proxysettings
{'FORWARD_USERNAME'} eq 'on') { print FILE " 
login=*:password"; }
		print FILE "\n";
		}
		print FILE "never_direct allow 
all\n\n";
	}
	if ($urlfilter_addon) {
        	if ($proxysettings{'ENABLE_FILTER'} 
eq 'on')
	        {
        	        print FILE <<END


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

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

> ja...@gu... wrote:
> 
> > One of the original plans for IPCop was to support remote/off-line 
> > configurations.  
> 
> With offline configuration you mean, making a config with some 
> KDE/Gnome, Windows, MAC (etc.) utility which is then transfered to an 
> IPCop ?

A Java basic utility was the original thought.  But it could also be 
another IPCop that is being used as master setup if the web pages 
could do it.

ja...@gu... wrote:

> One of the original plans for IPCop was to support remote/off-line 
> configurations.  

With offline configuration you mean, making a config with some 
KDE/Gnome, Windows, MAC (etc.) utility which is then transfered to an 
IPCop ?


cheers Olaf


-- 

A weizen a day helps keep the doctor away.

ja...@gu... wrote:

> It is time for growth and we are talking about growth please think in 
> supporting each other any type to understand their points.  Remember 
> we are working to better IPCop and User experience.  If there is some 
> thing that could be explained better we should do it.
> 
> Now if you take the base ideas and add some of the past, some like 
> this is possible...
> 
> One of the original plans for IPCop was to support remote/off-line 
> configurations.  The idea of supporting a method to create 
> configuration and load it later makes a BIG step to this method.

OK, but these are two different points.

The first is, that some users may not see that rules are active
immediately. IMHO it's clearly explained in the legend (if a box is
checked the rule is active, if it's unchecked the rule isn't) and
there's an checkbox when you create a new rule you can uncheck so a rule
won't become active after pressing the 'add'-button if you don't want it.

I don't like PopUps, red-blinking warnings or anything else, here I
personally think it's enough if it's explained in the manual - less is more.


The second thing is that it's surely is a good thing if there would be
an option to create rules and then you can safe these rules.

But wouldn't it be better if you would be able to create rules for an
interface? Remember - if IPCop gets the ability to have ie two green
interfaces the current variables in the ruleset ($GREEN, $RED) can't be
used anymore, *and* if you want to have a kind of centralized
administration it would be nice if you can create a complete ruleset for
an interface and then load it up to different machines.

What about a new cgi-Script for creating a complete ruleset for only one
interface? We could use the old color-scheme but then you will be able
to customize this ruleset, and save or download and upload it.
So, there's a page which shows the whole rulesets with all interfaces,
if you want to change anything there's a new page for every interface
which could be one cgi-script for all interfaces and there you can
define all rules for this interface.

Then you'll be able to save this ruleset, or to download this ruleset
and upload this ruleset to another machine, and there it needn't to be
the same Interface (ie - your "blue" interface on machine A could be
eth2, and on machine B it could be eth3).

So there must be two cgi-scripts:
The first one shows all interfaces and the whole ruleset, there you
could also define which "basic color" an interface should have, and
there's another cgi-script which let you define the ruleset only for the
current interface.

The problem which I see:
If I want to allow packets to another interface this interface isn't the
same on all machines, so other interfaces must be marked if you upload a
ruleset.


So the whole rc.firewall-script consists of n+1 parts for n=number of
interfaces. You have an "starting part" where the default-policy is
defined, where a general LOG-, DROP- and REJECT-chain will be created, a
kind of simple DDoS-protection and so on, and then there're n parts for
every interface, and as long as the user will not change this ruleset
the attached "color-schema" defined in the setup will be used.


Sven

I made some progress and we should see the end of the changes next week.
I have no time now to commit my last changes and they are not fully tested.

To resume my changes :
for ipcopbackup, mostly go back to the code used in 1.4.10 (still with
floppy detection)
There is no need to change floppy backup for changes related to web or key
backup.

Shift changes related to key backup to ipcopbkcfg.
Replace the 'root' password check with a 'backup' password to crypt exported
key.
Make crypting the key mandatory on export (all is made inside ipcopbkcfg)
Make a standard usage() to describe the syntax used (no more "used from cgi
only")

Simplify backup.cgi accordingly (no more three password boxes, just once)

I still need :
- to modify setup to add 'backup' password,
- add some code to the update to add the 'backup' user,
- adapt the installer to this backup user,
- probably need to change the installer to ease backup set selection


Gilles

> Volker Kuhlmann wrote:
> 
> >> I know of only 1 position in IPCop where the behaviour is not immediate. 
> > 
> >> All other actions are immediate, straight-forward and quite clear.
> > 
> > And the GUI tells me this where?
> 
> I don't get the point here. You can see it in the gui that these rules
> are active after pushing the 'Add'-button.
> Do you want a warning-message like "Attention - packets to port 25TCP
> will be forwarded to 10.0.0.1:25 in 15...14...13... seconds!"?

It is time for growth and we are talking about growth please think in 
supporting each other any type to understand their points.  Remember 
we are working to better IPCop and User experience.  If there is some 
thing that could be explained better we should do it.

Now if you take the base ideas and add some of the past, some like 
this is possible...

One of the original plans for IPCop was to support remote/off-line 
configurations.  The idea of supporting a method to create 
configuration and load it later makes a BIG step to this method.

One idea is create the ability to name each configuration and 
attached the changes, then apply/install it.

So you could have three base/root configurations:

*DEFAULT - What is shipped in one the ISO.
*LAST - What was current was before.
*CURRENT - What is running at this time.

Then you could create a new configuration by first copying an 
existing configuration and applying changes to it.  Once done, you 
can then "apply" the configuration and make it *CURRENT (ie: copy 
over the *CURRENT configuration). 

If you change the *CURRENT configuration all changes would be 
immedate. You could save the *CURRENT configuration by making a copy 
of the configuration to a name.  You could then save and restore 
these named configurations.

The last function needed would be an autoroll back if when "applying" 
and no confirm occurred in X mintes. This would allow a remote admin 
to make a mistake and loss connectity and know it X mintes the box 
will be back and they try again.  If you are doning this *CURRENT 
this option will not exist.  

Now backup and saves would be nothing more than copying a named 
configuration... even if it is *CURRENT.

jackb 

Feature Requests item #1493834, was opened at 2006-05-23 22:52
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=1493834&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: Achim (achim_schaefer)
Assigned to: Nobody/Anonymous (nobody)
Summary: ndiswrapper

Initial Comment:
To be able to handle some of the growing WLAN networks,
it would be nice to have ndiswrapper supprt in IpCop.

In 2.6 kernel the support is getting better, but there
are still quite a few WLAN devices not supported by any
2.6 kernel

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

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

Volker Kuhlmann wrote:

>> I know of only 1 position in IPCop where the behaviour is not immediate. 
> 
>> All other actions are immediate, straight-forward and quite clear.
> 
> And the GUI tells me this where?

I don't get the point here. You can see it in the gui that these rules
are active after pushing the 'Add'-button.
Do you want a warning-message like "Attention - packets to port 25TCP
will be forwarded to 10.0.0.1:25 in 15...14...13... seconds!"?

> All other firewalls I've touched take some time to reload.

If you enter something like 'iptables -A FORWARD -i ppp0 -o eth1 -j
ACCEPT' then this rule is active immediately.
However - this is IPCop, and I personally like this. I don't want to
wait before my rules are getting active - and why?

> So I make a change and it doesn't work. Is it
> because my network cable is plugged in the wrong port, I made a mistake,
> or the rules aren't loaded yet?

Again - you see it in the gui if a rule is active - it's explained in
the legend.

> Pfsense takes almost 3 minutes to reload shaping rules. SuSEfirewall2
> always assembles all rules from scratch, then does a bulk commit (the
> latter speeding things up no end). Plus, as the next person points out,
> you're avoiding security problems. If you aren't careful in what order
> you apply rules, you can't be sure that you have everything tight at all
> times between loading the first rule and the last. Look at the comments
> in SuSEfirewall2. I don't get the impression that Ipcop is carefully
> avoiding insecure time windows.

I don't agree with you.

The first thing - if there's no rule allowing packets the default-policy
will get this, and the default-policy for FORWARD and INPUT is DROP.

Second:
If you want to allow only specific Traffic within a new chain (if there
is shorewall or another iptables-configurator), you will define these
rules recursive - ie (free hands):

iptables -N FTP
iptables -N FTP_REJECT

iptables -A FTP_REJECT -m limit --limit 3/second -j LOG \
 --log-prefix "To much FTP "
iptables -A FTP_REJECT -m limit --limit 3/second -j REJECT \
  -- reject-with tcp-reset
iptables -A FTP_REJECT -j DROP

iptables -A FTP -m connlimit --connlimit-above 10 -j FTP_REJECT
iptables -A FTP -j ACCEPT

iptables -A INPUT -p tcp --dport 20:21 -m state --state NEW -j FTP

so there is to no time a security-whole.

In IPCop you can't create new chains via GUI - there you can only
forward traffic or allow local input.

If you want to forward ports 10000-20000, but not 15500-16000 you'll
first have to block 15500-16000 and then forward 10000-20000 - again,
there's no security whole if you know what you're doing. If you don't
know what you're doing, there is no difference if rules are active
immediately or after 3 minutes.


Cheers,
Sven

Le Mardi 23 Mai 2006 10:01, Vittorio Manfredini a =C3=A9crit=C2=A0:
> I have the following problem :
>
> 2 different company with the same internal network (192.168.1.0) that
> are connected thru a fiber channel.
>
> The company "A" have to access two server on the network of the "B"
> company.
>
> At the moment we have 2 sonicwall with nat configured, but the network
> traffic is very slow. (an operation that need 1,5 minutes on the "B"
> network need 5 minutes when they pass thru the sonicwall ..)
>
> Will be possible to use ipcop on the both side to do this ?
>
> How I have to configure the 2 ipcop machine ?
>
> Thanks in advance
No strange config. You have two networks, with same IP network number,
linked with some kind of vpn I think.
It is definitily impossible for IP routing too understand that.

With IPcop, you may solve this if
you have a well defined and limited (server/ports) to give
access from other side. (port transfert, but no privacy here).


With NAT, the only public thing known is the public internet IP
of each network. Not what is behind IPCop/SonicWall.

Change one of 192.168.1.x/24 to 192.168.2.x/24

=46ranck

I have the following problem :

2 different company with the same internal network (192.168.1.0) that  
are connected thru a fiber channel.

The company "A" have to access two server on the network of the "B" company.

At the moment we have 2 sonicwall with nat configured, but the network  
traffic is very slow. (an operation that need 1,5 minutes on the "B"  
network need 5 minutes when they pass thru the sonicwall ..)

Will be possible to use ipcop on the both side to do this ?

How I have to configure the 2 ipcop machine ?

Thanks in advance

-- 
Vittorio Manfredini
Senior Technical Consultant






----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Feature Requests item #1493370, was opened at 2006-05-23 00:41
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=1493370&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: stony (stonygrunow)
Assigned to: Nobody/Anonymous (nobody)
Summary: PayPal Donate option

Initial Comment:
Thanks for the great work! I wanted to donate (albeit
only $10) but couldn't find a Paypal Donate button. Why
not put it on. It couldn't hurt (until intra-group
fighting breaks out about who gets to drive the ipcop
Bentley that night)

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

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

> I know of only 1 position in IPCop where the behaviour is not immediate. 

> All other actions are immediate, straight-forward and quite clear.

And the GUI tells me this where? All other firewalls I've touched take
some time to reload. So I make a change and it doesn't work. Is it
because my network cable is plugged in the wrong port, I made a mistake,
or the rules aren't loaded yet?

Pfsense takes almost 3 minutes to reload shaping rules. SuSEfirewall2
always assembles all rules from scratch, then does a bulk commit (the
latter speeding things up no end). Plus, as the next person points out,
you're avoiding security problems. If you aren't careful in what order
you apply rules, you can't be sure that you have everything tight at all
times between loading the first rule and the last. Look at the comments
in SuSEfirewall2. I don't get the impression that Ipcop is carefully
avoiding insecure time windows.

Greetings,

Volker

-- 
Volker Kuhlmann			is list0570 with the domain in header
http://volker.dnsalias.net/	Please do not CC list postings to me.

Feature Requests item #1493226, was opened at 2006-05-22 14:44
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=1493226&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: Harry Goldschmitt (goldharv)
Assigned to: Nobody/Anonymous (nobody)
Summary: DHCP, Dynamic DNS and VPN Coordinated Update

Initial Comment:
I have several net to net VPNs set up between sites.  Each site has a 
dynamic DNS and an address that changes via a RED DHCP.  When an 
IPCop's address changes, the dynamic DNS is updated, but its peers are 
not notified.  On the other IPCop's on the network, IPSec dead peer 
detection discovers the connection is broken, but does not re-resolve the 
DNS name of its peer.

I currently have to use external access to login to the other IPCops and 
enter /etc/rc.d/ipsec restart to get the VPN going again.

It seems that a cron script could be written to periodically check the IP 
addresses of VPN peers via the host command and see if they have 
changed.  If so, IPSec could be restarted.

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

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

I recently tried to upgrade 2 different IPCop machines.  One from 
1.4.6 and one from 1.4.7.  In both cases when I downloaded via the 
info link on the system update web page, I got what appear to be bad 
tarballs, (at least IPCop wouldn't perform the update with a bad 
update error message).  When I went to our Sourceforge file page and 
downloaded from there, the update worked.

Harry

Le Lundi 22 Mai 2006 21:50, Volker Kuhlmann a =E9crit=A0:
> > In case of a change saved but not yet applied, there should be a 'pendi=
ng
> > changes' information that 'Apply' button usage will clear.
> > Yes it will be more complicated to have two buttons than one.
>

In some situation, it is much more secure to setup everything then
apply the changes as a whole.

Like moving money from one place to another, when money is
subtracted from place1 you want it to be credited at second place.
All or nothing.

You can imagine things like giving squid cache access to only
a list of machine
=2Dopening port 8080
=2Dstart squid daemon
=2Dcreate machine list
It is bad to open 8080 for nothing (long before squid start)
It is bad to restart squid for every added machine (to much dynamic)
You setup, then you apply.

Or setting up a vpn with restricted port, restricted user etc...

Volker Kuhlmann wrote:

> The current situation is scruffy: it's unclear what the behaviour is,
> it's unknown when changes made are actually active. Useless for
> testing and setting up, so I resorted to running /etc/rc.d/rc.firewall
> restart, not the nice userfriendly GUI thing.

I beg your pardon ?

I know of only 1 position in IPCop where the behaviour is not immediate. 
And 1 where the behaviour is somewhat 'difficult'
Those are NTP time sync and DynDNS update.

All other actions are immediate, straight-forward and quite clear.

cheers Olaf

-- 

A weizen a day helps keep the doctor away.

Le Lundi 22 Mai 2006 10:28, Achim Weber a =E9crit=A0:
> Its not the only reason for them. If you want to restart one functionality
> (Port Forwarding / DHCP / NTP / etc.) you only have to call the
> corresponding helper and NOT the whole system.
>
> Here is another example:
> When you drive with your car and it begins to rain you start the wiper.
> Rain becomes stronger and you speed up the wiper. You don't have to stop
> the car, re-initalise all systems or even have to restart (reboot) the ca=
r!
> Only the helper for your wiper needs a restart ;-)

=2E..

> Spoken in other words:
> When you run all helpers/scripts and instead of run the commands the
> helpers/scripts would print the commands to one single (THE ONE) script
> with all commands, you would have your "magic brain" etc.
>
> - You will not have less or simple programms,
> - again you would need scripts/helpers which print the commands to THE ONE
>   script,
> - you still need the config (files) from which the helpers/scripts print
> the commands. You can't store the config in THE ONE script, otherwise you
> would have to parse THE ONE script and extract the config from the
> commands. So you can't copy THE ONE to another machine and think you would
> have transfered the config from one to another machine.
> - When one config changes (Port Forwarding / DHCP / NTP / etc.) you always
> have to re-compile THE ONE and restart the whole system (look at the car
> example above).
> I like the current design with single helpers for a small field of
> activity. I can't see the advantage of THE ONE single script, can someone
> enlighten me!?
=2E..> Counterquestion:
> When you buy a new car will it have 5 speed reverse and only one forward =
as
> it is a new car and needs a total re-design, only because the engineers of
> the manufacturer are no baby engineers?
> No, it mostly will have some improvements here and there but it will still
> be a car. Because you have a new version/release you don't need to do ALL
> things different.
>
All different no. Remove blocking concept yes.
Having things like 'enabled(_green)' 'enabled_red' 'enabled_blue'
etc is blocking. Removing this concept* implies redoing a lot of things.
*a known fixed number of one destination interface.


In the early 1900, Ford was manufactoring the FORD-T model.
When going to your car reseller, he presented you a catalog
with one option: the color I think. Take it as is or leave it.
Everything else were fixed.
Today you go to your dealer, answer a thousand of question
about your car. Then the build is launched at factory. At=20
every stage, the machines have all datas to decide on installing
an option or not. Result is a hightly customizable car, built
once, without mistakes like speakers installed but no
autoradio selected...

Ipcop 1.0 was certainly the ford-t, ipcop-1.4 a big evolution,
and 1.5 another step. The factory (the brain) makes
a high number of decision before delivering the car.
Then you drive it.
Some actions have to be immediate, yes. Some others need
refactoring the car (recalculating it).
wiper->dynamic change
using the 1000cc or 1200cc motorization->static*


=46ranck

*imagine a car where before using it you had to choose a motor
among ten types. Connecting each motor to the base car efficiently
will be painless for engineers, with many mechanicals tricks to suit
every case. All this mechanics is allways installed, subject to=20
problems (pirate), ready to side effect another mechanich...

> In case of a change saved but not yet applied, there should be a 'pending
> changes' information that 'Apply' button usage will clear.
> Yes it will be more complicated to have two buttons than one.

No it will be much less complicated, because it is immediately clear
what behaviour to expect: 'save' to save, 'apply' to activate changes
made; there ought to be an indication of when the changes have been
completely applied.

The current situation is scruffy: it's unclear what the behaviour is,
it's unknown when changes made are actually active. Useless for
testing and setting up, so I resorted to running /etc/rc.d/rc.firewall
restart, not the nice userfriendly GUI thing.

Volker

-- 
Volker Kuhlmann			is list0570 with the domain in header
http://volker.dnsalias.net/	Please do not CC list postings to me.