ipcop-devel Mailing List for IPCop Firewall

Selon Franck Bourdonnec <fbo...@ch...>:

...
> >
> > Yes, you could load one package, read information and not install.
> > But to be able to load another package, you would need first to remove
> > previous uninstalled package. A 'Suppress' button need to be available for
> > that.
> > You should only be allowed to upload one package at a time.
> > When a .gpg package is present, package upload need to be disabled.
> >
> > I do not understand the purpose of a setup.inf files and what should be
> > written inside.
>
> > My idea is to study something with as less changes as possible to evaluate
> > if it could be made on v1.4. As we already have setup and information
> > files, I do not find requirement that need to change that.
>
> >
> > I do not feel a strong need on v1.4 to implement parsing the pubring to
> > test any available key to see if a package could be valid. This is too late
> > for v1.4 and we should think to the futur.
> >
> > Concerning v2, we need to be more advanced on the package management
> > subject.
> > That could be a solution to have our own system that check any key
> > available on root pubring.
> >
> > Gilles
>
> setup.inf= file read by readhash/keyvalues;
>
> readhash/kv is our standart method for that purpose.
> The actual 'information' is just another mindless variation of reading
> keyvalues.
>
> install=./setup
> uninstall=./del
> date=12.12.07
> desc=This is a standart IPCop patch
> desc-FR=Ceci est un patch standart
> text-0=Bug fixes:ipsec, blablah
> text-1=Other updates: blablah again
> text-0-FR=....
> depends=addon-manager,addon-xyz,ipcop1.4.17
> ....
>
> It is much more easy to edit this file and adding new keys
> than editing 'information';
> and of course will be similar in v2
> Don't try to extend this 'information'.
>
I agree that information is painfull to maintain but I do not want to change
that on v1.4.
You look to ignore how patches files are build with aggregation of information
files.
For example
http://www.ipcop.org/patches/1.4.10
http://www.ipcop.org/patches/1.4.15

We probably should change that for 2.0.
Have just one file to collect all updates would be simplier.
It would require an adjustement in the GUI to filter information from version
released before that version.

> YOU= one or more IPCop developper that is able to affirm
> "yes, this addon writer is producing good addon"
> It is only a label. IPCop approved ;-)
>
If it is out of my control and visibility, even it is has been estimated as
right at a time, I will not judge what could be the quality in the futur.
IPCop code is visible to everyone.
Not all add-on, even if they are GPL licenced are supplied with full sources and
a easy way to track changes. I do not think this is bad intention but this
require a bit more work.

> forking the helper to make it waits 3 minutes then delete
> it's unpacking dir should clean any installpackage dish?
> A 'Suppress' button cannot be used!
>
That's an obscure way to find a solution.
Why could we not suppress a file (that could be with a fixed name)?
As the file remain as loaded as a .gpg file, it remain protected by the
signature.
So we should be able to load all files under the same name. That's information
that would say us what is inside.
We could even not require to suppres a .gpg file not installed. The file would
only be replaced by a new loaded file.

Gilles

----- Original Message ----- 
From: "Franck Bourdonnec" <fbo...@ch...>
To: <ipc...@li...>
Sent: Tuesday, August 28, 2007 1:24 AM
Subject: Re: [IPCop-devel] [Ipcop-svn] installpackage


> >
> > (may be bad) :
> >
> > This design is broken. Including all key fingerprinting at compilation
will
> > not work.
> >
> > Think that you are the author of an add-on.
> > You install a new version of installpackage with your key fingerprint
> > include.
> > In that action, you erase a previous version of installpackage with
maybe
> > other key fingerprinting include, possibly from an other add-on writer.
> ???
> they don't have access to svn/cvs.
> Accepting their key here means that YOU or some else have decided
> that this developper writes good quality code. A kind of label.
> Just inserting a key in thekeyring doesn't prove that a package will
> do what an 'information' file says...
> The question is reject or accept or warn when the key is unknown.
>
No it is not me who decide.
I let the person who install an add-on free to decide what could be
installed on that machine.

If there is no information and setup, the package should be rejected as now.

...
> > I doubt we really need an option to differentiate an update like we know
> > today from an other package. We could create all package the same way
with
> > information and setup files include.
> > When we talk about installpackage, the needs I describe were not what
you
> > do
> >
> > - it will be better to be able to read only information of a package
before
> > to install.
> > We give instructions in information but you can't read them from the web
> > gui before the update is published on ipcop.org or before you install
that
> > update. That's a bit late.
> >
> > - we should be able to load one package at a time directly from
ipcop.org
> > and not locally uploaded. Remote loading should remain optional.
> >
> > Both need imply that a .gpg package could be loaded (from ipcop.org or
> > locally) inside ipcop and stay. It could then be treated (read the
> > information or install). After installation only, the gpg package is
> > removed.
> >
> > Gilles
>
> yes, yes, we can do. Just remember a user can begin viewing 'information'
> and jump elsewhere, leaving files not installed and not erased.
> Having a setup.inf style can solve problems instead of
> extending 'information'.
>
Yes, you could load one package, read information and not install.
But to be able to load another package, you would need first to remove
previous uninstalled package. A 'Suppress' button need to be available for
that.
You should only be allowed to upload one package at a time.
When a .gpg package is present, package upload need to be disabled.

I do not understand the purpose of a setup.inf files and what should be
written inside.
My idea is to study something with as less changes as possible to evaluate
if it could be made on v1.4. As we already have setup and information files,
I do not find requirement that need to change that.

I do not feel a strong need on v1.4 to implement parsing the pubring to test
any available key to see if a package could be valid. This is too late for
v1.4 and we should think to the futur.

Concerning v2, we need to be more advanced on the package management
subject.
That could be a solution to have our own system that check any key available
on root pubring.

Gilles

>
> (may be bad) :
>
> This design is broken. Including all key fingerprinting at compilation will
> not work.
>
> Think that you are the author of an add-on.
> You install a new version of installpackage with your key fingerprint
> include.
> In that action, you erase a previous version of installpackage with maybe
> other key fingerprinting include, possibly from an other add-on writer.
???
they don't have access to svn/cvs.
Accepting their key here means that YOU or some else have decided
that this developper writes good quality code. A kind of label.
Just inserting a key in thekeyring doesn't prove that a package will
do what an 'information' file says...
The question is reject or accept or warn when the key is unknown.

>
> > -an user must explicitly add gpg pub key from an addon author
> > -this program knows all gpg-keys from authors, and a key have some
>

> capabilities (to define)
>
> > based on this capabilities this prog do or avoid some actions.
>
> Checking key fingerprinting is useless.
> If a key is in the root pubring.gpg, that mean root have installed that
> key. You should not require extra check.
see previous

>
> You have implemented long and short options to the helper (and use only
> short version).
> I think short options should not be implemented.
> That mean something to you only for a few hours after you have written the
> code.
> We should use always long options.
ok


> I doubt we really need an option to differentiate an update like we know
> today from an other package. We could create all package the same way with
> information and setup files include.
> When we talk about installpackage, the needs I describe were not what you
> do
>
> - it will be better to be able to read only information of a package before
> to install.
> We give instructions in information but you can't read them from the web
> gui before the update is published on ipcop.org or before you install that
> update. That's a bit late.
>
> - we should be able to load one package at a time directly from ipcop.org
> and not locally uploaded. Remote loading should remain optional.
>
> Both need imply that a .gpg package could be loaded (from ipcop.org or
> locally) inside ipcop and stay. It could then be treated (read the
> information or install). After installation only, the gpg package is
> removed.
>
> Gilles

yes, yes, we can do. Just remember a user can begin viewing 'information'
and jump elsewhere, leaving files not installed and not erased.
Having a setup.inf style can solve problems instead of 
extending 'information'.

----- Original Message ----- 
From: <fra...@us...>
To: <ipc...@li...>
Sent: Friday, August 24, 2007 1:52 AM
Subject: [Ipcop-svn] SF.net SVN: ipcop: [486] ipcop/trunk


> Revision: 486
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=486&view=rev
> Author:   franck78
> Date:     2007-08-23 16:52:40 -0700 (Thu, 23 Aug 2007)
>
> Log Message:
> -----------
> Installpackage was unable to do a simple package installation, eg
something not necessarily
> a sequencial patche.
> This version is now able to do it.
> In addition this, I added a simple signature checking system. The idea is
(may be bad) :

This design is broken. Including all key fingerprinting at compilation will
not work.

Think that you are the author of an add-on.
You install a new version of installpackage with your key fingerprint
include.
In that action, you erase a previous version of installpackage with maybe
other key fingerprinting include, possibly from an other add-on writer.

> -an user must explicitly add gpg pub key from an addon author
> -this program knows all gpg-keys from authors, and a key have some
capabilities (to define)
> based on this capabilities this prog do or avoid some actions.
>
Checking key fingerprinting is useless.
If a key is in the root pubring.gpg, that mean root have installed that key.
You should not require extra check.

You have implemented long and short options to the helper (and use only
short version).
I think short options should not be implemented.
That mean something to you only for a few hours after you have written the
code.
We should use always long options.

I doubt we really need an option to differentiate an update like we know
today from an other package. We could create all package the same way with
information and setup files include.

When we talk about installpackage, the needs I describe were not what you do
:
- it will be better to be able to read only information of a package before
to install.
We give instructions in information but you can't read them from the web gui
before the update is published on ipcop.org or before you install that
update. That's a bit late.

- we should be able to load one package at a time directly from ipcop.org
and not locally uploaded. Remote loading should remain optional.

Both need imply that a .gpg package could be loaded (from ipcop.org or
locally) inside ipcop and stay. It could then be treated (read the
information or install). After installation only, the gpg package is
removed.

Gilles

----- Original Message ----- 
From: "Eric Oberlander" <eri...@gm...>
To: "IPCOP devel" <ipc...@li...>
Sent: Sunday, August 26, 2007 4:15 PM
Subject: [IPCop-devel] Testing 1.4.17 upgrade tgz


> Just to report the following error message when I manually apply the
> latest update file:
> 
> root@ipcop:# ./setup
> This is the 1.4.17 update patch for IPCop 1.4.16 installing.
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.34/kernel/drivers/net/wan/wanpipe.o.gz
> End of 1.4.17 update.
> 
> Not sure how important this is...
> 
> Eric
> 
thank, we may need to include the new system.map
I will test that.

Gilles

Just to report the following error message when I manually apply the
latest update file:

root@ipcop:# ./setup
This is the 1.4.17 update patch for IPCop 1.4.16 installing.
depmod: *** Unresolved symbols in
/lib/modules/2.4.34/kernel/drivers/net/wan/wanpipe.o.gz
End of 1.4.17 update.

Not sure how important this is...

Eric

Bugs item #1782017, was opened at 2007-08-26 13:49
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=1782017&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: bsht (bsht)
Assigned to: Nobody/Anonymous (nobody)
Summary: squid acls broken

Initial Comment:
i have been using some squid acls since 1.4.6 and have more then 50 ipcop boxes working with it.

yesterday i installed 1.4.15 and make it work as allways, then i upgraded to 1.4.16 and my acls simply stoped to work.

it did not recognise my acls and blocked everything.

no error, it just bypass my acls and did not work.

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

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

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBTYXQs
IDI1IEF1ZyAyMDA3IDExOjQ4OjM1ICswMjAwDQoiR2lsbGVzIEVzcGluYXNzZSIgPGcuZXNwQGZy
ZWUuZnI+IHdyb3RlOg0KDQo+IA0KPiBUaGUgcGFydCB3aGVyZSBJIHRvdGFsbHkgZG9uJ3Qga25v
dyBob3cgdG8gcHJvY2VkZSBpcyBob3cgdG8NCj4gcmVwcmVzZW50IHRoZSBwYWNrYWdlIHJlcG9z
aXRvcnkuDQo+IENvdWxkIHdlIGF2b2lkIHRvIGhhdmUgYSBkYiBmb3IgdGhhdCAoc2hvdWxkIHdl
IGF2b2lkKT8NCj4gDQpXaHkgbm90IHVzZSBhIGZsYXQgWE1MLWZpbGU/IEluIHRoaXMgZmlsZSB0
aGUgY3VycmVudCBhbmQgcHJldmlvdXMNCmNvbmZpZyBjb3VsZCBhbHNvIGJlIHNhdmVkIC0gYWxs
IGRhdGEgc2F2ZWQgaW4gb25lIGZpbGUgbWFrZXMNCmJhY2t1cC9yZWNvdmVyeSBhIGxvdCBlYXNp
ZXIuDQoNCi0gLS0gDQpIaWxzZW4vUmVnYXJkcw0KTWljaGFlbCBSYXNtdXNzZW4NCg0KR2V0IG15
IHB1YmxpYyBHbnVQRyBrZXlzOg0KbWljaGFlbCA8YXQ+IHJhc211c3NlbiA8ZG90PiBjYw0KaHR0
cDovL2tleXNlcnZlci52ZXJpZGlzLmNvbToxMTM3MS9wa3MvbG9va3VwP29wPWdldCZzZWFyY2g9
MHhEM0M5QTAwRQ0KbWlyIDxhdD4gZGF0YW5vbSA8ZG90PiBuZXQNCmh0dHA6Ly9rZXlzZXJ2ZXIu
dmVyaWRpcy5jb206MTEzNzEvcGtzL2xvb2t1cD9vcD1nZXQmc2VhcmNoPTB4RTUwMUY1MUMNCm1p
ciA8YXQ+IG1pcmFzIDxkb3Q+IG9yZw0KaHR0cDovL2tleXNlcnZlci52ZXJpZGlzLmNvbToxMTM3
MS9wa3MvbG9va3VwP29wPWdldCZzZWFyY2g9MHhFM0U4MDkxNw0KLSAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhlIHNtYWxs
ZXN0IHdvcm0gd2lsbCB0dXJuIGJlaW5nIHRyb2RkZW4gb24uDQoJCS0tIFdpbGxpYW0gU2hha2Vz
cGVhcmUsICJIZW5yeSBWSSINCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9u
OiBHbnVQRyB2MS40LjYgKEdOVS9MaW51eCkNCg0KaUQ4REJRRkcwQnBYVkVyWVZlUG9DUmNSQW5p
UkFKOURoamlWZzBYQWlQbmtTMDg2UlZORzhOc1diQUNncFpSeQ0KMXJ2WXdWZFhoSzhtbzhaa1ND
cWo3REE9DQo9UTBPVw0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQo=

----- Original Message ----- 
From: "Ivan Kabaivanov" <ch...@ya...>
To: <ipc...@li...>
Sent: Saturday, August 25, 2007 4:28 AM
Subject: Re: [IPCop-devel] [Ipcop-core] md5sum of all installed files aslast
step in theinstaller?


...
> > I think we should go to a packaging system, one that exist or our own.
> > This would allow better testing and qualification of changes, possibly
> > package uninstall to go back to a previous version.
>
>
> Gilles, I know you're following lfs-dev so you've seen this thread, but
I'll
> post it here anyway:
>
I was only on hlfs-dev
> http://linuxfromscratch.org/pipermail/lfs-dev/2007-August/060019.html
>
> It contains lots of new ideas, and the package management is only one of
them.
> Nothing concrete regarding that aspect came out of the discussion, but
some
> interesting suggestions were passed around.
>
> We can either wait for LFS to come up with something and hope it satisfies
our
> requirements or just try a few package managers and settle on the best one
> for our needs.
>
The main reason I think packaging would be a progress for us is for testing
new packages.
So my requirements would be :
- simply allow a package qualified as testing or qualified to install
- simply allow to restore from previous qualified package.

there is some parts that should be simple for us to create a package:
- we could do that in one line in POSTBUILD with
if [ -s $(TARGET) ]; then tar -T -F $(TARGET) -czf
/usr/src/packages/$(THISAPP).tar.gz; fi

I use hardcoded usr/src/packages just because it was simple for me to test.

But far more need to be done, include package name and version inside, sign
the packages

Some cleanup would be required in the build process like ping mv to insure
the right file is include.

The difficult part is with config file changes.
It could be that the most simple way is to save previous config files before
installation of the new package. That way, going back to old package restore
the previous config files.

The part where I totally don't know how to procede is how to represent the
package repository.
Could we avoid to have a db for that (should we avoid)?

Gilles

On Friday 24 August 2007, Gilles Espinasse wrote:
> ----- Original Message -----
> From: "Ivan Kabaivanov" <ch...@ya...>
> To: <ipc...@li...>
> Sent: Friday, August 24, 2007 8:28 PM
> Subject: [Ipcop-core] md5sum of all installed files as last step in
> theinstaller?
>
> > Just an idea -- what  do you think if the last thing the installer did
> > was
>
> to
>
> > find *all* installed files, md5sum them and write the sums to a floppy?
>
> This
>
> > would be an optional, but strongly recommended step of the installer to
>
> help
>
> > in the future in the event of a compromised system.
> >
> > This would go well together with a rescue mode initrd on the installation
>
> cd
>
> > that I'm planning to put together at some point in the near future.
> >
> > We can work out a system where updates will be taken into account when
>
> files
>
> > are changed.
>
> I think we should go to a packaging system, one that exist or our own.
> This would allow better testing and qualification of changes, possibly
> package uninstall to go back to a previous version.


Gilles, I know you're following lfs-dev so you've seen this thread, but I'll 
post it here anyway:

http://linuxfromscratch.org/pipermail/lfs-dev/2007-August/060019.html

It contains lots of new ideas, and the package management is only one of them.  
Nothing concrete regarding that aspect came out of the discussion, but some 
interesting suggestions were passed around.

We can either wait for LFS to come up with something and hope it satisfies our 
requirements or just try a few package managers and settle on the best one 
for our needs.


>
> > This will probably be quite time-consuming on old systems, but since it'd
>
> be
>
> > optional, people can choose not to do it.  But for those who do md5sum
>
> their
>
> > system, the benefit would be huge.
> >
> > I'd be interested in your feedback.
> >
> > Thanks,
> > IvanK.
>
> Could be in installer stage or ./make.sh rootfiles like I have done on
> v1.4. My idea was to concatenate md5 of published files after each update.
> I have not yet tested the number of files with a timestamp include on v1.5.
>
> Gilles

I think the installer would be the more appropriate place to do this kind of 
system fingerprinting -- just after installing all the files and after 
restoring configuration files.

Oh, and I'm moving this to ipcop-devel cause it'd be interesting to see what 
other people think.


IvanK.

Bugs item #1779818, was opened at 2007-08-22 17:10
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=1779818&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bill K (drotta)
Assigned to: Nobody/Anonymous (nobody)
Summary: _alloc_pages: order Allocation Failed kills Openvpn&snort

Initial Comment:

Hello,  IPCOP 1.4.16,  Running OPenvpn, Copfilter, IPSEC VPN, Snort on Red and Green.

What is am seeing is the following.

_alloc_page: 0-order allocation failed: gfp=01xd2/0
kernel: VM: killing process openvpn
_alloc_page: 0-order allocation failed: gfp=-x1d2/0
kernel: VM: killing process snort.


PS-ax will show that the Openvpn process is not running. 

I forgot to check snort. 
______________________________________________-
This is a box that has been upgraded from 1.4.7-16,
It is a P4 with 256mb

Via the webui, It will show that the OpenVpn is still running-- may be a problem with that and I can contact Ufuk on that and let him know tonight.

Via the webui. Snort will show that eth0 is checked and that eth1 is checked but the status for eth0 is stopped and eth1 is running. 

If you uncheck eth0 and then click save and then recheck eth0, it will never show that it is running.  

These problems appear to be new to the .16 revision. 

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

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

Bugs item #1779292, was opened at 2007-08-22 09:44
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=1779292&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: Security (Patches etc)
Group: 1.4.16
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nikesh (nikeshshah)
Assigned to: Nobody/Anonymous (nobody)
Summary: 255 Snort failure(s) to start

Initial Comment:
The last couple of times i.v updated IDS, i.v got this:

[Red Background]
Error messages:
255 Snort failure(s) to start

Just wondered if anyone knows why this could start to come up just recently, with no updates or changes to the system made?

Just wondered if anyone has any sugestions? that would be great.

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

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

Feature Requests item #1779029, was opened at 2007-08-21 23:39
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=1779029&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Merlin_von_Limbach (daniel_de_vil)
Assigned to: Nobody/Anonymous (nobody)
Summary: New feature request - boot from USB key

Initial Comment:
It would be nice and usefull implement usb key or usb hard disk boot possibility. Lates version 1.14 allows installation from USB key, but not on the USB hard disk. I would like to use Linutop to instal IP COP on it. Regards, Merlin_von_Limbach

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

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

Feature Requests item #1778444, was opened at 2007-08-21 10:00
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=1778444&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: J Goodwin (goodwinj)
Assigned to: Nobody/Anonymous (nobody)
Summary: Port Forwarding by Hostname

Initial Comment:
Would it please be possible to add a feature to allow port forwarding based on the host header.

e.g. www.xyz.com:443 --> 192.168.60.1:443
     www2.xyz.com:443 --> 192.168.60.2:443

Where www.xyz.com and www2.xyz.com both have the same external ip address

Thanks

James Goodwin

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

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

----- Original Message ----- 
From: "Franck Bourdonnec" <fbo...@ch...>
To: <ipc...@li...>
Sent: Monday, August 20, 2007 6:31 PM
Subject: Re: [IPCop-devel] Re ip-up, beeps, readhash, ...


>
> > No matter what the GUI does, the sound setting could exist in the form
of
> > the nobeep file.
> STOP! The GUI controls this, and states are stored in
/var/ipcop/*/settings.
> the GUI won't check the existence of the flagfile. The GUI create or erase
> the flagfile.... and there is no need for the flagfiles except adding
> confusion.
the new GUI will never see the nobeep flagfile as it will be removed by
update setup that call upgrade. That's you that add /bin/rm -f
/var/ipcop/ppp/nobeeps to upgrade script.

That's mean that a setting registred by a user vanish because you care about
stylistic change and not about user selection. Very inappropriate for a
stable release.

That's not a big problem because it is only a small sound.
But this is a real problem for us :
- that you allow you some incomplete changes,
- that you change too much parts of the stable code where there is no bugs.

Gilles

> No matter what the GUI does, the sound setting could exist in the form of
> the nobeep file.
STOP! The GUI controls this, and states are stored in /var/ipcop/*/settings.
the GUI won't check the existence of the flagfile. The GUI create or erase
the flagfile.... and there is no need for the flagfiles except adding 
confusion.
If something else wants to replace the GUI, it have to use the settings files.

> If I understand well, you erase nobeep file before to rewrite corresponding
> PPPUPDOWNBEEP on main/settings.
>
they were closely related together. When GUI checks PPPUPDOWNBEEP 
it creates the file. And when the GUI unckecks PPPUPDOWNBEEP it also
erase the file. At the same place.

This kind of doing comes from 1.3 when readhash or settings was not
the standart I think.
Some are easy to remove (be sure I would have done that since a
long time if I had seen this before)
Note also there is other flags of this kind, built with a suffix (_orange,...)
and I won't touch them. Especially when used in helpers.

lfs/configroot doesn't setup main/settings with a particular value
for PPPUPDOWNBEEP and no reference is made to the flagfile.

Selon Franck Bourdonnec <fbo...@ch...>:

> > > - 'be consistent' look not to me a valid reason to change the ip-up sound
>
> oh yes it is. Think to a blind person. He decides to replace 'beep'
> by another prog less agressive or what-ever you want.
> IPcop will inform him except for one function, function sited
> in the same directory same prog ( a daughter function).
>
I think a blind person would be happy not to have a sound changed on a stable
release.

> Any code 'reviewer' finding this code will think 'who wrote that code....'
>
Style changes are for the development version only.

> And it is the same for readhash usage. In the same code, mixed
> way for reading variables coming from the same source...
Idem
> If you don't trust perl to call a third time same function in same
> code, give up ;-)
>
>
>
> Le Monday 20 August 2007 11:56:35 Eric Oberlander, vous avez écrit :
> > Gilles
> >
> > I agree with you 100%. Please revert the changes.
>
>
> > them in 1.9/2.0
> > instead.
> I will
>
Thank

> > > - you broke something that work.
> as usual ;-)
> > > You forget to register beep/nobeep
> > > settings on main/settings PPPUPDOWNBEEP. So the result will no be
> > > equivalent after update
> ???
> The GUI manages this variable. What is register beep/nobeep????
No matter what the GUI does, the sound setting could exist in the form of the
nobeep file.
If I understand well, you erase nobeep file before to rewrite corresponding
PPPUPDOWNBEEP on main/settings.

I agree for the reason to remove isolate tag files and write content in files,
but not introduce all those changes on 1.4.
This could have hidden effect difficult to track, like change the time required
to start a perl script.

Gilles

Selon Andrew McGlashan <and...@af...>:

> Hi,
>
> I was wondering if anybody has ported IPCop for use on the Linksys NSLU2 or
> similar cheap / very low power consumption device? I've got a debian ssh
> server running on one now with a USB key for the 'hard disk'.
>
> If this can be done, then it might only be good for 1x normal Ethernet port
> and 1x Ethernet port via a USB device.  I wonder if a hub could be used to
> make more network ports available via USB.....
>
Ivan has designed the build tree with cross compilation in mind.

But we have too much work (or not enough work yet done, wich is the same) to
attempt to work on a cross-compilation toolchain (yes CLFS is designed for
that).

Concerning running on usb key, that should be a goal reachable for 2.0

Once a day after 2.0 will be out and the doc updated, we could see.
Same for MIPS.

Gilles

Hi,

I was wondering if anybody has ported IPCop for use on the Linksys NSLU2 or 
similar cheap / very low power consumption device? I've got a debian ssh 
server running on one now with a USB key for the 'hard disk'.

If this can be done, then it might only be good for 1x normal Ethernet port 
and 1x Ethernet port via a USB device.  I wonder if a hub could be used to 
make more network ports available via USB.....

Kind Regards

AndrewM

Andrew McGlashan
Broadband Solutions now including VoIP

Current Fixed Line No: 03 8705 0300
Mobile: 04 2574 1827 Fax: 03 8790 1224

National No: 1300 85 3804

Affinity Vision Australia Pty Ltd
http://www.affinityvision.com.au
http://adsl2choice.net

In Case of Emergency --  http://www.affinityvision.com.au/ice.html 

Le Monday 20 August 2007 13:43:01 Achim Weber, vous avez écrit :
> Franck Bourdonnec wrote:
> > i have seen the bug,
> > discovered why,
>
> ... and did not look into the cvs changes,
yes and the solution is bad.

> > use the correct func to get the correct IP
> > not relaying on ddns updater system.
>
> ... which is wrong as you used the ddns updater variable "BEHINDROUTER"
> (same as I did).

Just write the function that returns the Internet IP and everybody will be 
happy.

index.cgi has nothing to do on how to read this IP inside ddns internal files. 
Ok?

Franck

Franck Bourdonnec wrote:

> i have seen the bug,
> discovered why,

... and did not look into the cvs changes,

> use the correct func to get the correct IP
> not relaying on ddns updater system.

... which is wrong as you used the ddns updater variable "BEHINDROUTER" (same as
I did).

> Write GetInternetAddress() instead of my
> call to GetDyndnsREDIP

... which produce [much] more load (one call per index.cgi refresh) on
checkip.dyndns.com (than 1.15.2.22 code). Dyndns.com will thank you for that.

Can remember a time back in 1.3 days as DynDNS blocked IPCop due to heavy dyndns
updates of the used update programm which produced a high load on there servers.
I started the search on sf.net for you:
 ->
http://sourceforge.net/tracker/index.php?func=detail&aid=856556&group_id=40604&atid=428516


Achim

Le Monday 20 August 2007 13:10:28 Achim Weber, vous avez écrit :
> Franck Bourdonnec wrote:
> >>>> Previous code was working well, only issue was if you open index.cgi
> >>>> and
> >
> > not so well because someone reported an empty IP the displaying.
> >
> >
> > ......
>
> Did he use the latest CVS code? No, he uses 1.4.16 where this was a bug. In
> 1.15.2.22 this bug was already fixed.
>
> So you say, you overwrite latest CVS file without looking at the
> difference/log?
>
> Achim
>

i have seen the bug,
discovered why,
use the correct func to get the correct IP
not relaying on ddns updater system.
Write GetInternetAddress() instead of my
call to GetDyndnsREDIP
Storing the data is a private mechanisism
to setddns.

> > - 'be consistent' look not to me a valid reason to change the ip-up sound

oh yes it is. Think to a blind person. He decides to replace 'beep'
by another prog less agressive or what-ever you want.
IPcop will inform him except for one function, function sited
in the same directory same prog ( a daughter function).

Any code 'reviewer' finding this code will think 'who wrote that code....'

And it is the same for readhash usage. In the same code, mixed
way for reading variables coming from the same source...
If you don't trust perl to call a third time same function in same
code, give up ;-)



Le Monday 20 August 2007 11:56:35 Eric Oberlander, vous avez écrit :
> Gilles
>
> I agree with you 100%. Please revert the changes. 


> them in 1.9/2.0 
> instead.
I will

> > - you broke something that work. 
as usual ;-)
> > You forget to register beep/nobeep 
> > settings on main/settings PPPUPDOWNBEEP. So the result will no be
> > equivalent after update
???
The GUI manages this variable. What is register beep/nobeep????

Franck Bourdonnec wrote:

>>>> Previous code was working well, only issue was if you open index.cgi and
> not so well because someone reported an empty IP the displaying.
> 
> 
> ......

Did he use the latest CVS code? No, he uses 1.4.16 where this was a bug. In
1.15.2.22 this bug was already fixed.

So you say, you overwrite latest CVS file without looking at the difference/log?

Achim

Le Monday 20 August 2007 12:22:21 Achim Weber, vous avez écrit :
> Franck Bourdonnec wrote:
> > Le Monday 20 August 2007 07:54:30 Achim Weber, vous avez écrit :
> >> Franck Bourdonnec wrote:
> >>
> >> And inside the "existing function" you check for Dyndns settings!?! How
> >> does this match together?
> >
> > exact, it  checks one variable (behindrouter). But note that this
> > variable is totally unrelated to ddns service. It's more a global
> > information for the system, placed here for convinience.
>
> Hm, well the previous index.cgi only checks the same variable. So no
> "better" code, no improvements.
>
> > It just demonstrate that knowing the internet IP and the RED ip is used.
> > (dynddns, system status, vpn endpoint, more....)
>
> ???
>
> >> Too with the new code you may call gethostbyaddr with IP=='unavailable'.
> >> Not sure if this gives an error.
> >
> > pack returns a string a 4 char, gethostbyaddr receive something not an IP
> > and returns an empty string.
>
> Ok.
>
> >> Previous code was working well, only issue was if you open index.cgi and
not so well because someone reported an empty IP the displaying.


......

> >>
> >> Now it is called every time you load index.cgi.
> >
> > setddns.pl call it regurlarly too...
>
> Only every fourth call which is called by cron every 20 minutes. You coded
> it this way some time ago, including the fetch IP counter written to dyndns
> settings file.
>
> Now on startpage (index.cgi) it is everytime fetched from
> checkip.dyndns.com (additionally to setddns.pl) I open it.
>
>
> Achim

Then the correct solution is to write the function GetInternetAddress
hidding the internal mechanics.
The second things 'should do' is clearly say that there is no relation
between ddns updater system and finding the real IP internet.