ipcop-devel Mailing List for IPCop Firewall

Olaf Westrik wrote:

> David W Studeman wrote:
>>  Since tmpfs allows itself to be mounted as a percentage of available ram
>>  as
>> well as the traditional fixed size of the old school rd filesystem (had
>> to be formatted as a fixed size block device before mounting), Wouldn't
>> 50% be a better default?
> 
> Yes.  I'd still prefer to use a fixed size though (call me old school if
> you want ;-)).
> I will change the installer to calculate 50% and have that memory size
> as the default value when the window comes up in the installer.

 For some reason /var/ipcop/main/flashsettings does not get written to on 
install. I have also tried hand editing it to add the line 
TMPFS_MAX_SIZE=50% and it is totally ignored.
 
> 
>  > I couldn't imagine anyone trying to run IPCop 2 on flash
>> with less than 128MB of ram which would yield 64MB anyway.
> 
> Yes, I guess we need to make a note somewhere that to run IPCop (and be
> a happy camper) with the flash optimizations one would need at least 128
> MB.
> 
> 
> Olaf
> 

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

Bugs item #2799161, was opened at 2009-05-31 20:10
Message generated for change (Tracker Item Submitted) made by scorp888
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=2799161&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: User Interface
Group: 1.4.21
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By:  Ian (scorp888)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi-bin/logs.cgi/ids.dat gives in-correct squid urls.

Initial Comment:
Links from this page

http://www.snort.org/pub-bin/sigs.cgi?sid=485
http://www.snort.org/pub-bin/sigs.cgi?sid=2050
http://www.snort.org/pub-bin/sigs.cgi?sid=2003

Give 404's on the squid web sie.

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

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

Bugs item #2798583, was opened at 2009-05-29 22:25
Message generated for change (Tracker Item Submitted) made by dg7raj
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=2798583&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: 5
Private: No
Submitted By: Clemens (dg7raj)
Assigned to: Nobody/Anonymous (nobody)
Summary: DDNS adds a dot for opendns.com 

Initial Comment:
My hostname is umts for DynamicDNS opendns.com:

cat /var/ipcop/ddns/config 
opendns.com,umts,,,,username,password,on

/cat/var/log/messages
ipcop: Dynamic DNS ip-update for opendns umts. : failure (nohost)

Ipcop 1.4.21 sends: umts.  - not umts

Workaround - I replaced my label/hostname on OpenDNS ending with a dot and it works :-)



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

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

Gilles Espinasse wrote:

> 
> ----- Original Message -----
> From: "Olaf Westrik" <wei...@ip...>
> To: "Gilles Espinasse" <g....@fr...>
> Cc: "David W Studeman" <avi...@ai...>; "IPCOP
> devel" <ipc...@li...>
> Sent: Wednesday, May 27, 2009 10:09 AM
> Subject: Re: [IPCop-devel] Usb Storage on 1.9.5
> 
> 
>> Gilles Espinasse wrote:
>>
>> > ub is a simple driver needed for some cheap mp3 player, not really our
>> > target and should be less complete than usb-storage driver.
>> > That's possible to have both ub and usb-storage and switch from one to
>> > another but I don't think there is added value for us (but I have not
>> > selected that option by ignorance).
>> > I would prefer remove ub driver and continue with usb-storage.
>>
>> Yes.
>> Do you want me to remove ub, or do you already have it in your local
>> tree?  Combine with some missing usb serial drivers?
>>
>>
>> Olaf
>>
> I will change that before a nightly build.
> I am delayed huntinf a different issue (expect segfault and gcc test
> failure on debian lenny).
> 
>     Gilles
 
I can confirm that all is well compiling minus the ub driver and plugging 
usb devices in. There is one called sg that is still present and autoloads 
in addition to sd_mod and usb-storage. As long as we get the /dev/sd* nodes 
we're golden.  


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

Weizen,

I can continue to beta test as fixes come out.

When will multiple interfaces become available for testing?


Doug


--- On Wed, 5/27/09, Olaf Westrik <wei...@ip...> wrote:

> From: Olaf Westrik <wei...@ip...>
> Subject: Re: [IPCop-devel] [2.0] release of v1.9.5, SVN #2876 - Bugs Report
> To: "Doug S" <r20...@ya...>
> Cc: ipc...@li...
> Date: Wednesday, May 27, 2009, 12:19 AM
> Hello Doug,
> 
> 
> > After testing the latest test version, found the
> following bugs:
> 
> Thanks for testing and reporting in.
> 
> 
> > 1)  OpenVPN interface does not work.  Gives
> an error message:
> 
> Yes, that is an unfortunate error in 1.9.5 :-(
> Please try this 'hot-fix' http://marc.info/?l=ipcop-devel&m=124334789406372&w=2
> 
> 
> > 2)  Interface to assign interfaces does not allow
> assignment of unassigned NICs (no documentation on how to
> add a custom interface).
> 
> For now we are still limited to a Green+Red+Blue+Orange
> setup.
> Adding interfaces can only be done manually
> 
> 
> > 3)  IPSec status does not change after
> enabling/disabling service and selecting save.  Only
> changed after reboot.  Possible service not change
> until reboot.
> 
> Yes.  I have been working on that in the last few
> days, but not completely happy yet.
> 
> I have added the running/stopped indicator as found on the
> OpenVPN page.
> I have revived the 'Enable on Red/Blue/Orange' checkmarks,
> but need to look at this a bit more.
> Enabling or adding a tunnel will start the IPsec daemon if
> needed.
> Disabling or removing a tunnel should stop the IPsec
> daemon, not fully tested yet.
> 
> The bigger issue I currently see is that IPsec
> nat-traversal is not working. I have yet to find out
> why  :-(
> 
> 
> 
> Olaf
> 
> -- 
> A weizen a day helps keep the doctor away.
> 


      

----- Original Message ----- 
From: "Achim Weber" <dot...@gm...>
To: "Olaf Westrik" <wei...@ip...>
Cc: "Gilles Espinasse" <g....@fr...>; "IPCOP devel"
<ipc...@li...>
Sent: Tuesday, May 26, 2009 9:31 PM
Subject: Re: [IPCop-devel] [2.0] Remove SHOW_PROGRESS feature from make.sh?


> Hi Gilles
>
> feel free to remove the progress feature. I never ever used it...
>
> Achim
>
I have played today with jhalf building LFS because I wanted to look at some
tests log related to an expect/gcc problem on debian lenny.
That's always interesting to see a different implementation that has
advantages and drawback.
jhalf has something very very similar to SHOW_PROGRESS but their system stop
everything when doing ctrl/C. I haven't look in details how that's made.

Basically jhalf produce the reverse of our building system.
The result of parsing LFS book produce a big Makefile that call small bash
scripts when our system is a big make.sh that call small Makefile scripts.
There is some missing features :
- you have to manually create the sudo configuration,
- it does not use ccache
- it does not create something like our toolchain package, saving a lot of
time on chap 6 rebuild.

The advantage is that in a few minutes, you could start building LFS, CLFS
from svn version or from a specific book version without coding anything.

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "David W Studeman" <avi...@ai...>; "IPCOP devel"
<ipc...@li...>
Sent: Wednesday, May 27, 2009 10:09 AM
Subject: Re: [IPCop-devel] Usb Storage on 1.9.5


> Gilles Espinasse wrote:
>
> > ub is a simple driver needed for some cheap mp3 player, not really our
> > target and should be less complete than usb-storage driver.
> > That's possible to have both ub and usb-storage and switch from one to
> > another but I don't think there is added value for us (but I have not
> > selected that option by ignorance).
> > I would prefer remove ub driver and continue with usb-storage.
>
> Yes.
> Do you want me to remove ub, or do you already have it in your local
> tree?  Combine with some missing usb serial drivers?
>
>
> Olaf
>
I will change that before a nightly build.
I am delayed huntinf a different issue (expect segfault and gcc test failure
on debian lenny).

    Gilles

David W Studeman wrote:
>  Since tmpfs allows itself to be mounted as a percentage of available ram as 
> well as the traditional fixed size of the old school rd filesystem (had to 
> be formatted as a fixed size block device before mounting), Wouldn't 50% be 
> a better default?

Yes.  I'd still prefer to use a fixed size though (call me old school if 
you want ;-)).
I will change the installer to calculate 50% and have that memory size 
as the default value when the window comes up in the installer.


 > I couldn't imagine anyone trying to run IPCop 2 on flash
> with less than 128MB of ram which would yield 64MB anyway.

Yes, I guess we need to make a note somewhere that to run IPCop (and be 
a happy camper) with the flash optimizations one would need at least 128 MB.


Olaf

-- 

A weizen a day helps keep the doctor away.

Gilles Espinasse wrote:

> 
> ----- Original Message -----
> From: "David W Studeman" <avi...@ai...>
> To: <ipc...@li...>
> Sent: Wednesday, May 27, 2009 3:10 AM
> Subject: [IPCop-devel] Usb Storage on 1.9.5
> 
> 
>> Hello all! As was discussed in a previous thread a while back, the backup
>> cgi looks for sd* devices which in turn require sd_mod to be loaded.
> Looking
>> at the module dependencies of usb-storage, sd_mod is not one of them and
>> I too have device nodes uba and uba1 pop up automatically as others have
> seen
>> here. I was able to mount and write to /dev/uba1 with vfat. Should the
>> sd_mod and sd* requirement be dropped from the backup cgi and look for
>> ub* device nodes instead? Since sd_mod is not a requirement of
>> usb-storage, is there any reason to rely on it these days? The ub* device
>> nodes pop up
> with
>> usb storage as soon as it loads when a usb storage device is detected.
>>
> ub is a simple driver needed for some cheap mp3 player, not really our
> target and should be less complete than usb-storage driver.
> That's possible to have both ub and usb-storage and switch from one to
> another but I don't think there is added value for us (but I have not
> selected that option by ignorance).
> I would prefer remove ub driver and continue with usb-storage.
> 
>     Gilles
> 
I read up on ub and it is indeed classified as a low performance driver.  
Probably might not sit well with some people. Since ub is also not a 
dependency of usb-storage as it is a separate driver that seemingly came 
from nowhere yet looks to be from 2004 so it must have been there, I see 
your point and you can't go wrong with the sd_mod usb-storage pair imho. I 
never knew about ub until Olaf ran into it popping up a short while back. 
-- 
Dave
http://www.raqcop.com

Gilles Espinasse wrote:

> ub is a simple driver needed for some cheap mp3 player, not really our
> target and should be less complete than usb-storage driver.
> That's possible to have both ub and usb-storage and switch from one to
> another but I don't think there is added value for us (but I have not
> selected that option by ignorance).
> I would prefer remove ub driver and continue with usb-storage.

Yes.
Do you want me to remove ub, or do you already have it in your local 
tree?  Combine with some missing usb serial drivers?


Olaf

-- 

A weizen a day helps keep the doctor away.

----- Original Message ----- 
From: "David W Studeman" <avi...@ai...>
To: <ipc...@li...>
Sent: Wednesday, May 27, 2009 3:10 AM
Subject: [IPCop-devel] Usb Storage on 1.9.5


> Hello all! As was discussed in a previous thread a while back, the backup
> cgi looks for sd* devices which in turn require sd_mod to be loaded.
Looking
> at the module dependencies of usb-storage, sd_mod is not one of them and I
> too have device nodes uba and uba1 pop up automatically as others have
seen
> here. I was able to mount and write to /dev/uba1 with vfat. Should the
> sd_mod and sd* requirement be dropped from the backup cgi and look for ub*
> device nodes instead? Since sd_mod is not a requirement of usb-storage, is
> there any reason to rely on it these days? The ub* device nodes pop up
with
> usb storage as soon as it loads when a usb storage device is detected.
>
ub is a simple driver needed for some cheap mp3 player, not really our
target and should be less complete than usb-storage driver.
That's possible to have both ub and usb-storage and switch from one to
another but I don't think there is added value for us (but I have not
selected that option by ignorance).
I would prefer remove ub driver and continue with usb-storage.

    Gilles

Hello Doug,


> After testing the latest test version, found the following bugs:

Thanks for testing and reporting in.


> 1)  OpenVPN interface does not work.  Gives an error message:

Yes, that is an unfortunate error in 1.9.5 :-(
Please try this 'hot-fix' 
http://marc.info/?l=ipcop-devel&m=124334789406372&w=2


> 2)  Interface to assign interfaces does not allow assignment of unassigned NICs (no documentation on how to add a custom interface).

For now we are still limited to a Green+Red+Blue+Orange setup.
Adding interfaces can only be done manually


> 3)  IPSec status does not change after enabling/disabling service and selecting save.  Only changed after reboot.  Possible service not change until reboot.

Yes.  I have been working on that in the last few days, but not 
completely happy yet.

I have added the running/stopped indicator as found on the OpenVPN page.
I have revived the 'Enable on Red/Blue/Orange' checkmarks, but need to 
look at this a bit more.
Enabling or adding a tunnel will start the IPsec daemon if needed.
Disabling or removing a tunnel should stop the IPsec daemon, not fully 
tested yet.

The bigger issue I currently see is that IPsec nat-traversal is not 
working. I have yet to find out why  :-(



Olaf

-- 

A weizen a day helps keep the doctor away.

David W Studeman wrote:

> Hello all! As was discussed in a previous thread a while back, the backup
> cgi looks for sd* devices which in turn require sd_mod to be loaded.
> Looking at the module dependencies of usb-storage, sd_mod is not one of
> them and I too have device nodes uba and uba1 pop up automatically as
> others have seen here. I was able to mount and write to /dev/uba1 with
> vfat. Should the sd_mod and sd* requirement be dropped from the backup cgi
> and look for ub* device nodes instead? Since sd_mod is not a requirement
> of usb-storage, is there any reason to rely on it these days? The ub*
> device nodes pop up with usb storage as soon as it loads when a usb
> storage device is detected.
> 
> Since some sysinit changes were made to compensate for systems such as
> Cobalt which cannot rely on the initrd a short while back, everything
> including the usb host driver loads on boot with no adding to /etc/modules
> required anymore. As soon as I plug in a usb stick, usb-storage autoloads
> and the ub device nodes appear and are mountable immediately.

Following up, for some reason, build 2921 loads sd_mod automatically as well 
and sda device nodes appear now as soon as a usb stick is plugged in. As of 
now I am using the unedited modules.conf and modules files. Module ub does 
still load automatically as well as usb-storage and sd_mod. Interesting 
indeed.
-- 
Dave
http://www.raqcop.com

Hello all! As was discussed in a previous thread a while back, the backup 
cgi looks for sd* devices which in turn require sd_mod to be loaded. Looking 
at the module dependencies of usb-storage, sd_mod is not one of them and I 
too have device nodes uba and uba1 pop up automatically as others have seen 
here. I was able to mount and write to /dev/uba1 with vfat. Should the 
sd_mod and sd* requirement be dropped from the backup cgi and look for ub* 
device nodes instead? Since sd_mod is not a requirement of usb-storage, is 
there any reason to rely on it these days? The ub* device nodes pop up with 
usb storage as soon as it loads when a usb storage device is detected. 

Since some sysinit changes were made to compensate for systems such as 
Cobalt which cannot rely on the initrd a short while back, everything 
including the usb host driver loads on boot with no adding to /etc/modules 
required anymore. As soon as I plug in a usb stick, usb-storage autoloads 
and the ub device nodes appear and are mountable immediately. 
-- 
Dave
http://www.raqcop.com

After testing the latest test version, found the following bugs:

1)  OpenVPN interface does not work.  Gives an error message:
----------Begin Error Message----------

Software error:

Unable to read file /var/ipcop/ovpn/settings at /usr/lib/ipcop/general-functions.pl line 95.

For help, please send mail to the webmaster (root@localhost), giving this error message and the time and date of the error. 

----------End Error Message----------

2)  Interface to assign interfaces does not allow assignment of unassigned NICs (no documentation on how to add a custom interface).


3)  IPSec status does not change after enabling/disabling service and selecting save.  Only changed after reboot.  Possible service not change until reboot.


Doug


      

Hi Gilles

feel free to remove the progress feature. I never ever used it...

Achim

Gilles Espinasse wrote:

> Since SHOW_PROGRESS feature addition, all lfs scripts are run in background.
> The /feature/ allow first to display an twirling baton and was upgraded to
> display the second since lfs script start. That's a fine display and was
> missing the gap since we display build duration and no more the date where
> previous package build has finished, so it is possible to simply know how
> long compilation take and if it may have hang somewhere (because of a
> missing kernel .config parameter for example in make oldconfig)
> 
> But major drawback is that ctrl/c no more stop the lfs script (as started in
> background).
> So we have to kill schild scripts that may run far longer than we are ready
> to wait before releasing our moutpoints. Killing the child work for root
> since some time, building a list of child scripts of make.sh and killing
> them.
> But as I am far from a big fan to add kill in sudoer list when not compiling
> as root, that is not supported in non-root build. I don't think it is
> possible to do that in a secure way (not allowing the build user to kill
> anything on the machine).
> 
> Should we remove SHOW_PROGRESS?
> That simply would allow us to have ctrl/c working again to stop the build
> even in the non-root case.

Yes, feel free to remove SHOW_PROGRESS and move building of the 
lfs/scripts into foreground.

For me being able to kill a build, outweighs the progess indicator.


> One alternative is start only lfs script in the background when
> SHOW_PROGRESS is in use (maybe only in root case), but as SHOW_PROGRESS is
> more a gadget than something important, I would prefer to work on features
> for the installed machine, not on the building system.

I think that only complicates things too much.

If some day I miss the progress indicator too much, I could try to make 
it the other way around: start a counter in the background 
(tools/progress.pl or something). That would be easier to kill in case 
of CTRL-C.



Olaf

-- 

A weizen a day helps keep the doctor away.

Since SHOW_PROGRESS feature addition, all lfs scripts are run in background.
The /feature/ allow first to display an twirling baton and was upgraded to
display the second since lfs script start. That's a fine display and was
missing the gap since we display build duration and no more the date where
previous package build has finished, so it is possible to simply know how
long compilation take and if it may have hang somewhere (because of a
missing kernel .config parameter for example in make oldconfig)

But major drawback is that ctrl/c no more stop the lfs script (as started in
background).
So we have to kill schild scripts that may run far longer than we are ready
to wait before releasing our moutpoints. Killing the child work for root
since some time, building a list of child scripts of make.sh and killing
them.
But as I am far from a big fan to add kill in sudoer list when not compiling
as root, that is not supported in non-root build. I don't think it is
possible to do that in a secure way (not allowing the build user to kill
anything on the machine).

Should we remove SHOW_PROGRESS?
That simply would allow us to have ctrl/c working again to stop the build
even in the non-root case.

One alternative is start only lfs script in the background when
SHOW_PROGRESS is in use (maybe only in root case), but as SHOW_PROGRESS is
more a gadget than something important, I would prefer to work on features
for the installed machine, not on the building system.

    Gilles

Mark Wormgoor wrote:
> Olaf Westrik wrote:
>> If there are no strong and valid objections within a few days, I will 
>> change both 222 to 8022 (ssh) and 800 to 8080 (proxy).
>>
>> That will give us these special ports:
>> 8022 - SSH access
>> 8080 - proxy
>> 8443 - web GUI
>>
>> The proxy port is, same as in 1.4, easily modifiable through the GUI.
>> SSH and GUI are also modifiable, but not via the GUI and it is also not 
>> recommended to do so.
> 
> I fully agree with ssh and web gui. I do have some doubts about proxy 
> though. What happens to those users who run a significant amount of pc's 
> behind their IPCop? They'll not be able to access the internet, unless 
> they reconfigure their clients or the proxy. Not sure if that's the 
> first place they'll look. Changing the access ports will raise a number 
> of questions on the list already, but will only affect administrators. 
> Changing the proxy port has the potential to affect end-users as well.

The proxy port will automagically transfer when doing backup/restore.
I'd also expect people running large networks to first do trials in a 
test environment, especially since 2.0 will not be an upgrade.


Olaf

-- 

A weizen a day helps keep the doctor away.

Olaf Westrik wrote:

> v1.9.5 is *TESTING* material only, *DO NOT* use in a productive environment.
> 
> Some things will work, for example cleaning your harddisk on installation.
> Some things may work.
> Some things will not work.
> 
> There will be no updates to later versions.
> There will be no support.

As is OpenVPN is not configurable through the GUI.

The fix is fairly trivial, create /var/ipcop/ovpn/settings with 
following contents:
DCIPHER=BF-CBC
DPROTOCOL=udp
DDEST_PORT=1194
KEEPALIVE_1=10
KEEPALIVE_2=60

Followed by a:
chown nobody.nobody /var/ipcop/ovpn/settings


And all should be OK.


Olaf

-- 

A weizen a day helps keep the doctor away.

 Since tmpfs allows itself to be mounted as a percentage of available ram as 
well as the traditional fixed size of the old school rd filesystem (had to 
be formatted as a fixed size block device before mounting), Wouldn't 50% be 
a better default? I couldn't imagine anyone trying to run IPCop 2 on flash 
with less than 128MB of ram which would yield 64MB anyway. If one is running 
a gig of ram and half of it is available for the tmpfs mounted as /ram, any 
unoccupied ram is still available for the system to use as it is needed. If 
I'm not mistaken, tmpfs mounts at 50% if no size is specified but the 
parameter might still be good to keep in rc.flash.up so one can easily 
change it to another value if desired.

I would also like to repeat what I have said in older threads, some of my 
findings in that a running tmpfs mount can be remounted at a different size 
on the fly with no data loss in /ram, yet another nicety of having a non 
block device filesystem that does not need formatting. I have done it many 
times. Saves a reboot. Probably not as important as it would have been had 
Snort been kept, 64MB /ram would never have been enough for the rules 
download but that hog is gone now. The remount is invoked by the same 
command as original mounting but with -o remount added to the argument.

The ability to make a flash install initially is heaven sent. For 1.4 I made 
a variation of the mkflash script that saves the keys. If you're like me, 
you like to use the same ssh and http keys as you saved in your backup. For 
public distribution of course, better to let each machine generate it's own 
set. None of this is an issue with 2.0 thanks to the installer flash option. 
Thanks!
-- 
Dave
http://www.raqcop.com

Eric Oberlander wrote:

> So when we get round to it, here's my design suggestion, for consideration
> :)
> 
> 00-000_system
> 00-100_home
> 00-200_scheduler
> 00-300_updates
> ...
> 00-900_credits
> 01-000_status
> 01-100_system_status
> 01-200_system_info
> 01-300_network_status
> ...
> 01-800_connections
> 02-000_network
> 02-100_dialup
> 02-200_upload
> 02-300_modem
> 02-400_aliases
> 03-000_services
> 03-100_proxy
> 03-200_dhcp_server
> ...
> 
> Where first 2 digits represents Mainmenu position, reserved by IPCop.
> And second 3 digits represents position in Submenu.
> 000 indicates it's a Main Menu.
> Text after first underscore would be a 'translation string'
> 
> Embed the string within each cgi, for example, within dhcp.cgi have:
> # MENUCODE 03-300_dhcp_server
> 
> Or, for wireless.cgi, include a flag to indicate 'only display if a Blue NIC
> is installed'
> # MENUCODE 04-200_blue_access ifBlue
> 
> So by grepping the cgis you could generate the menus, from a script that
> could run at startup, update, or on request.


I first thought it easier to have a directory say /var/ipcop/menu where 
one drops the wanted entries as a file.

On second thought putting the info into the CGI could prove to be easier.
Examples:
# MENUENTRY 010-000 "alt system" ""
# MENUENTRY 010-000 "alt home" "alt home"
# MENUENTRY 020-040 "system graphs" "system graphs"
# MENUENTRY 020-050 "sstraffic graphs" "network traffic graphs" 
"?graph=network"
# MENUENTRY 070-030 "proxy logs" "proxy log viewer" ifProxy


I don't think we really need to bother with "IPCop " in the statustext, 
as we do some cut & paste magic already to insert the '-' character.
We'd need an optional parameter to be given to the CGI, as required by 
graphs.cgi
A second optional parameter to include things like ifGreen, ifBlue, ifProxy.

Special case of course the top-level menus, which do not have a CGI (and 
also no statustext). But there is no problem to put all of them in for 
example index.cgi, and treat this differently because of the 000 as 
second number.


A Perl script to grep through all CGIs, build a menu.pl which could then 
be easily pulled by header.pl.
As modifications are done either after updates or addon installation, I 
see no need for suid tricks, trigger files, etc.


Olaf

-- 

A weizen a day helps keep the doctor away.

Olaf Westrik wrote:
> Tom Eichstaedt wrote:
> 
>> Another request is to switch ssh access to port 8022 (like https
>> which already is changed to port 8443) so it's plain sailing for 
>> everyone. Olaf recommended that some time ago but there were no
>> replies as far as I remember.
> 
> If there are no strong and valid objections within a few days, I will 
> change both 222 to 8022 (ssh) and 800 to 8080 (proxy).
> 
> That will give us these special ports:
> 8022 - SSH access
> 8080 - proxy
> 8443 - web GUI
> 
> The proxy port is, same as in 1.4, easily modifiable through the GUI.
> SSH and GUI are also modifiable, but not via the GUI and it is also not 
> recommended to do so.

I fully agree with ssh and web gui. I do have some doubts about proxy 
though. What happens to those users who run a significant amount of pc's 
behind their IPCop? They'll not be able to access the internet, unless 
they reconfigure their clients or the proxy. Not sure if that's the 
first place they'll look. Changing the access ports will raise a number 
of questions on the list already, but will only affect administrators. 
Changing the proxy port has the potential to affect end-users as well.

Changing it might be a good idea to match standards, but we need to be 
careful to consistently mention these port changes in announcements.

Kind regards,

Mark

Tom Eichstaedt wrote:

> Another request is to switch ssh access to port 8022 (like https
> which already is changed to port 8443) so it's plain sailing for 
> everyone. Olaf recommended that some time ago but there were no
> replies as far as I remember.

If there are no strong and valid objections within a few days, I will 
change both 222 to 8022 (ssh) and 800 to 8080 (proxy).

That will give us these special ports:
8022 - SSH access
8080 - proxy
8443 - web GUI


The proxy port is, same as in 1.4, easily modifiable through the GUI.
SSH and GUI are also modifiable, but not via the GUI and it is also not 
recommended to do so.


Olaf


PS: of course there are other special ports for dns and dhcp, but these 
are non-configurable.

-- 

A weizen a day helps keep the doctor away.

Peter Bassel @ GWPco wrote:

> Sorry don't know how to reply through list.

There is a section about mailing list usage here: 
http://ipcop.org/index.php?module=pnWikka&tag=IPCopSupport


Olaf

-- 

A weizen a day helps keep the doctor away.