ipcop-devel Mailing List for IPCop Firewall

Feature Requests item #3481695, was opened at 2012-01-30 08:39
Message generated for change (Tracker Item Submitted) made by sjuncal
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=3481695&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface Improvements (example)
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Gabriel (sjuncal)
Assigned to: Nobody/Anonymous (nobody)
Summary: Proxy Log

Initial Comment:
Great program!! ;)

The proxy log is showing this information

12:48:31 	192.168.0.250 	http://www.symantec.com/favicon.ico
12:48:31 	192.168.0.250 	http://e52880.r.axf8.net/mr/e.gif?
12:48:31 	192.168.0.250 	http://www.symantec.com/favicon.ico

but some information is missing, like USER (when autenthicated) and if the request was rejected or not. 

Also i installed a syslog server, but cant see the proxy log. only i can see de firewall log and fcron log.

in addition, i can export 1 day of the proxy log, but not a range of days  (i backup the proxy log, so i have to export day by day)...

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

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

On 1/29/2012 6:21 AM, André L.R.Ferreira - Netdeep wrote:
> Hello guys! Congratulations!
>
> I would like to test, but where can I see the changelog?
>
> Thanks!
>
> André Luiz Rodrigues Ferreira
> Netdeep Tecnologia

You might see it on Friday Feb 3rd when RC1 is released. Please don't 
top post, thanks.

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

G.W. Haywood wrote:


>>> Please can someone explain to me in simple terms exactly why the lack
>>> of a built-in package management system is delaying the propagation of
>>> IPCop updates by periods of the order of months?
>>
>> What makes you think so?
> 
> The text quoted above my question.
> 
>> Is this a complaint about the frequency of updates?
> 
> No, this is a question about the quoted text (which appears to imply
> that the lack of a package management system  delays IPCop updates).
> 
> For the record, I still have IPCop 1.4.21 (plus a few manual tweaks)
> happily plugging away on about a dozen boxes; so it would indeed be
> churlish of me to complain about the frequency of IPCop updates and
> I am not doing any such thing.
> 
>> What delays are you speaking of?  ...
> 
> It was Mr. Espinasse who spoke of delays.  I'm just asking about that.
> 
> --
> 
> 73,
> Ged.
> 

OK, noted, now I understand what you meant. 

Yes, it is still safe to use 1.4.21 as you well know. Some seem to be 
holding out for urlfilter. I admit I was rather spoiled by urlfilter.
 
-- 
Dave Studeman
http://www.raqcop.com 

On 29 January 2012 13:27, Gilles Espinasse <g....@fr...> wrote:

>> Hi there,
>>
>> On 24-29 Jan 2012, Gilles Espinasse and Olaf Westrik wrote:
>>
>> > > > Yes package management is for me a priority on next version...
>> > >
>> > > What for?
>> >
>> > Faster update first.
>> >
>> > We have fix for 2.0.3 that could have been delivered one month ago.
>>
>> Please can someone explain to me in simple terms exactly why the lack
>> of a built-in package management system is delaying the propagation of
>> IPCop updates by periods of the order of months?
>>
>> --
>
> A package management allow to deliver exactly one part without touching
> anything else.
> We could mostly to the same with our update system except that there is
> still some manual operations needed. Release manager check :
> - if new files are really include using previously ./make.sh check_files
> (now made at each build),
> - probably too if old files are really suppressed as they should on
> installed machine.
> Update package signature too is manual.
>
> That would be very hard to scale to an update per day, maybe doable to an
> update per week. Plus when you have something not yet commited but that you
> build in your tree, you would not want to publish an update in those
> conditions.
> Concerning the period between updates, that's Olaf that cut the update.

I've often wondered about implementing a simpler 'patch' update, that
would only apply a simple, immediately required change, perhaps a one
line sed command to change a settings file, or a new set of tzdata
files, the day before the clocks change.

This would be along the lines of a 2.0.2-p1, 2.0.2-p2 naming scheme.

The same changes would also then be re-applied in the next main 2.0.3 update.

I'm not sure how easy or difficult that would be to integrate into the
current updating system, and who would decide what's urgent or not. I
think the current system has improved over time, and is still simple
enough for people like me to understand

Eric

Hi there,

On Sun, 29 Jan 2012, David W Studeman wrote:

> On 1/29/2012 4:47 AM, G.W. Haywood wrote:
>>
>> On 24-29 Jan 2012, Gilles Espinasse and Olaf Westrik wrote:
>>
>>>>> Yes package management is for me a priority on next version...
>>>>
>>>> What for?
>>>
>>> Faster update first.
>>>
>>> We have fix for 2.0.3 that could have been delivered one month ago.
>>
>> Please can someone explain to me in simple terms exactly why the lack
>> of a built-in package management system is delaying the propagation of
>> IPCop updates by periods of the order of months?
>
> What makes you think so?

The text quoted above my question.

> Is this a complaint about the frequency of updates?

No, this is a question about the quoted text (which appears to imply
that the lack of a package management system  delays IPCop updates).

For the record, I still have IPCop 1.4.21 (plus a few manual tweaks)
happily plugging away on about a dozen boxes; so it would indeed be
churlish of me to complain about the frequency of IPCop updates and
I am not doing any such thing.

> What delays are you speaking of?  ...

It was Mr. Espinasse who spoke of delays.  I'm just asking about that.

--

73,
Ged.

Hello guys! Congratulations!

I would like to test, but where can I see the changelog?

Thanks!

André Luiz Rodrigues Ferreira
Netdeep Tecnologia

-----Mensagem original-----
De: Olaf Westrik [mailto:wei...@ip...] 
Enviada em: domingo, 29 de janeiro de 2012 10:00
Para: Gilles Espinasse
Cc: IPCOP devel
Assunto: Re: [IPCop-devel] 2.0.3 release candidate 1

On 2012-01-29 12:50, Gilles Espinasse wrote:

> I would push lzo-2.06.

OK, do you want me to do that? Or do you have patch ready?


Olaf

----------------------------------------------------------------------------
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers is
just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro
Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
IPCop-devel mailing list
IPC...@li...
https://lists.sourceforge.net/lists/listinfo/ipcop-devel

----- Original Message ----- 
From: "G.W. Haywood" <ip...@ju...>
To: <ipc...@li...>
Sent: Sunday, January 29, 2012 1:47 PM
Subject: Re: [IPCop-devel] A proposal for a package management system


> Hi there,
>
> On 24-29 Jan 2012, Gilles Espinasse and Olaf Westrik wrote:
>
> > > > Yes package management is for me a priority on next version...
> > >
> > > What for?
> >
> > Faster update first.
> >
> > We have fix for 2.0.3 that could have been delivered one month ago.
>
> Please can someone explain to me in simple terms exactly why the lack
> of a built-in package management system is delaying the propagation of
> IPCop updates by periods of the order of months?
>
> --

A package management allow to deliver exactly one part without touching
anything else.
We could mostly to the same with our update system except that there is
still some manual operations needed. Release manager check :
- if new files are really include using previously ./make.sh check_files
(now made at each build),
- probably too if old files are really suppressed as they should on
installed machine.
Update package signature too is manual.

That would be very hard to scale to an update per day, maybe doable to an
update per week. Plus when you have something not yet commited but that you
build in your tree, you would not want to publish an update in those
conditions.
Concerning the period between updates, that's Olaf that cut the update.

Gilles

On 1/29/2012 4:47 AM, G.W. Haywood wrote:
> Hi there,
>
> On 24-29 Jan 2012, Gilles Espinasse and Olaf Westrik wrote:
>
>>>> Yes package management is for me a priority on next version...
>>>
>>> What for?
>>
>> Faster update first.
>>
>> We have fix for 2.0.3 that could have been delivered one month ago.
>
> Please can someone explain to me in simple terms exactly why the lack
> of a built-in package management system is delaying the propagation of
> IPCop updates by periods of the order of months?
>
> --
>
> 73,
> Ged.
>

What makes you think so? Is this a complaint about the frequency of 
updates? Patch Tuesday belongs to Microsoft, not IPCop. What delays are 
you speaking of? I wasn't aware of any scheduled frequency that updates 
are supposed to propagate and what you would expect from these updates.

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

Am 26.01.2012 19:43, schrieb Michael Rasmussen:
> On Thu, 26 Jan 2012 19:10:11 +0100
> Tom Eichstaedt<win...@to...>  wrote:
>
>> Am 24.01.2012 08:28, schrieb Gilles Espinasse:
>>
>>> Yes package management is for me a priority on next version (not 2.0.x,
>>> probably 2.1)
>>
>> We should not forget what IPCop is:
>>
>> A firewall.
>>
> And your point is?

There is simply no need for a package management system.
We should keep it simple, straightforward and well-known, as it is now.

Cheers Tom.

Hi there,

On 24-29 Jan 2012, Gilles Espinasse and Olaf Westrik wrote:

> > > Yes package management is for me a priority on next version...
> >
> > What for?
> 
> Faster update first.
> 
> We have fix for 2.0.3 that could have been delivered one month ago.

Please can someone explain to me in simple terms exactly why the lack
of a built-in package management system is delaying the propagation of
IPCop updates by periods of the order of months?

--

73,
Ged.

On 2012-01-29 12:50, Gilles Espinasse wrote:

> I would push lzo-2.06.

OK, do you want me to do that? Or do you have patch ready?


Olaf

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "IPCop devel" <ipc...@li...>
Sent: Sunday, January 29, 2012 10:03 AM
Subject: [IPCop-devel] 2.0.3 release candidate 1


> All,
>
>
> I intend to release 2.0.3-rc1 on Friday 3th February. Remaining SVN
> commits should be made before 2012-02-03 00:00:00 UTC.
> If all goes well, expect 2.0.3 to be released on Friday 10th February.
>
>
> Please note that release candidates are for testing purposes only. RCs
> can only be installed by uploading to IPCop manually or using IPCop
> console. There will be no updates from RCs to a final version.
>
>
> Olaf
>
I would push lzo-2.06.
Nothing hard but I noted that alloca configure test fail (same happen for
2.04).
There is other configure test wrong (clock_getcpuclockid, clock_getres,
clock_gettext) but they have no usage at all in source code or only if (0).

Gilles

On 2012-01-02 18:03, Olaf Westrik wrote:

>> However, I can move from April 30 to May 1 with the>>   button, but not
>> Feb 28 to March 1,
>> I don't know why yet. March 1<<   Feb 28 works OK.
>
> calculatedate() increased the date to 2012-02-29, after that
> validatedate() first decreases the year to 2011 and notices (correctly)
> that 2011-02-29 does not exist, thus descreasing the date to 2011-02-28.
>
> I'll add some tweaking in calculatedate(), so it returns the correct date.

This is still on the list to be fixed before release of 2.0.3.
I have not decided on what would be the best fix though.


Olaf

All,


I intend to release 2.0.3-rc1 on Friday 3th February. Remaining SVN 
commits should be made before 2012-02-03 00:00:00 UTC.
If all goes well, expect 2.0.3 to be released on Friday 10th February.


Please note that release candidates are for testing purposes only. RCs 
can only be installed by uploading to IPCop manually or using IPCop 
console. There will be no updates from RCs to a final version.


Olaf

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: <ipc...@li...>
Sent: Sunday, January 29, 2012 12:18 AM
Subject: Re: [IPCop-devel] A proposal for a package management system


> On 2012-01-24 08:28, Gilles Espinasse wrote:
>
> > Yes package management is for me a priority on next version (not 2.0.x,
> > probably 2.1)
>
> What for?
>
Faster update first.
We have fix for 2.0.3 that could have been delivered one month ago.

> Updating IPCop is extremely easy for users. Info is passed via
> ipcop-announce, after which 1 or 2 clicks are needed in the GUI.
>
> Having only one IPCop makes it easy to know what exactly someone is
> running in case help is asked.
>
I don't want to make everything optional. Just some packages could be user
selected.

> Preparing IPCop updates is work, but easier in v2 than it was in v1.4.
> Making a lot of small packages does not make the work any easier/faster.
>
Some package have very small dependencies and could be updated faster with a
package management than with the update system delivered when ready.

> I see no reason to make 'IPCop modules' that can be installed on demand.
> IPCop is small enough, and we try hard enough to keep it small, so that
> it can be installed on modest hardware.
>
> If someone believes a package management is helpful for addons, I
> suggest reviving the addon-server-project-thing.
> Probably better find out why it failed though, before investing time.
> If someone wants to install addons, that's fine, but it has to be clear
> that there is no such thing as an "IPCop-approved-addon".
>
>
> Olaf
>
Or you may consider I want to kill the addon-server and only have only
rightfully packaged code installed.
We need some flexibility.
Addon-server is an answer but does not always allow me to view the code
include in an addon, so I consider that not good enought.

With a minimal package management, I want good add-on be pushed in the
official tree (even not everything may enter).

I know IPCop is a firewall and it is not good to have everything installed.
I dream of a way to qualify the security of any package installed and to
qualify the security of the overall installation. I know that may be hard to
agree on a security note for some package. Is squid a risk or a solution in
a security point of view? Probably both, it depend of the point of view, of
the risk you want to protect.

The security note could be changed when a security issue is published. That
way, we would not care if a user stay with an old version, he would know his
machine may be vulnerable to some issues. That still remain his choice to
upgrade and when.
I am afraid this security note does not exist in package management, so we
may have to create one system to do that.

Gilles

On 2012-01-28 09:28, ges...@us... wrote:
> Revision: 6264
>            http://ipcop.svn.sourceforge.net/ipcop/?rev=6264&view=rev
> Author:   gespinasse
> Date:     2012-01-28 08:28:33 +0000 (Sat, 28 Jan 2012)
> Log Message:
> -----------
> iso .lib is cleaned from .so symlink
> /usr/lib need much work

We can do it step by step, everytime we touch some lfs file or rootfile.
Or we can do it with one big cleanup, probably better as we might forget 
to delete .so files during updates.


Olaf

On 2012-01-24 08:28, Gilles Espinasse wrote:

> Yes package management is for me a priority on next version (not 2.0.x,
> probably 2.1)

What for?

Updating IPCop is extremely easy for users. Info is passed via 
ipcop-announce, after which 1 or 2 clicks are needed in the GUI.

Having only one IPCop makes it easy to know what exactly someone is 
running in case help is asked.

Preparing IPCop updates is work, but easier in v2 than it was in v1.4.
Making a lot of small packages does not make the work any easier/faster.

I see no reason to make 'IPCop modules' that can be installed on demand. 
IPCop is small enough, and we try hard enough to keep it small, so that 
it can be installed on modest hardware.

If someone believes a package management is helpful for addons, I 
suggest reviving the addon-server-project-thing.
Probably better find out why it failed though, before investing time.
If someone wants to install addons, that's fine, but it has to be clear 
that there is no such thing as an "IPCop-approved-addon".


Olaf

On Thu, 26 Jan 2012 15:09:35 -0800
David W Studeman <dws...@ov...> wrote:

> 
>   As it is now, the entire distro is contained in a single tarball and 
> the installer only needs to format the drive and dump the tarball onto 
> the formatted drive and run setup. When you go to package management you 
> have a whole new game and it would be a lengthy install or would it not 
> be necessarily so?
> 
I don't see a contradiction between a package management system (PMS)
and having the initial distro contained in a single tarball.

Having a PMS gives the ability to:
1) Provide continues security patches.
2) Make selective upgrades .
3) Easier/faster get to current patch level from initial install

>   Depending how common of a packaging system is used, it could set up 
> IPCop to be abused easily by the folks wanting to run server software 
> and more on their firewall.
> 
This is a risk which is always present. Any system can be misused
whether a PMS is available or not. 

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------

On 01/26/2012 10:10 AM, Tom Eichstaedt wrote:
> Am 24.01.2012 08:28, schrieb Gilles Espinasse:
>
>> Yes package management is for me a priority on next version (not 2.0.x,
>> probably 2.1)
>
> We should not forget what IPCop is:
>
> A firewall.
>
> Cheers Tom.

  As it is now, the entire distro is contained in a single tarball and 
the installer only needs to format the drive and dump the tarball onto 
the formatted drive and run setup. When you go to package management you 
have a whole new game and it would be a lengthy install or would it not 
be necessarily so?

  Depending how common of a packaging system is used, it could set up 
IPCop to be abused easily by the folks wanting to run server software 
and more on their firewall.

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

On Thu, 26 Jan 2012 19:10:11 +0100
Tom Eichstaedt <win...@to...> wrote:

> Am 24.01.2012 08:28, schrieb Gilles Espinasse:
> 
> > Yes package management is for me a priority on next version (not 2.0.x,
> > probably 2.1)
> 
> We should not forget what IPCop is:
> 
> A firewall.
> 
And your point is?

AFAIK even firewalls need patching now and then. The easier patching is
the more likely this will be done more often.

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------

Am 24.01.2012 08:28, schrieb Gilles Espinasse:

> Yes package management is for me a priority on next version (not 2.0.x,
> probably 2.1)

We should not forget what IPCop is:

A firewall.

Cheers Tom.

On Tue, 24 Jan 2012 08:28:15 +0100
"Gilles Espinasse" <g....@fr...> wrote:

> 
> Yes package management is for me a priority on next version (not 2.0.x,
> probably 2.1)
> I would really prefer using a package management that exist and not create a
> new one.
> 
I agree since that normally means avoiding a lot of beginning errors.

> opkg is an option I considered last year. I just looked and compiled opkg
> and haven't been farest.
> OpenWRT use opkg, I don't know who else do.
> 
It is the package management system for OpenMoko and QNAP as well.

> 
> As we already have libgpg-error and libgcrypt, I don't know if we should not
> upgrade gpg for 2.1. That way, we could use opkg gpg option but need to
> add -libassuan libksba, pth, gpgme.
> Werner Koch is pushing for an upgrade from gnupg-1 to gnupg-2 for debian
> http://lists.gnupg.org/pipermail/gnupg-devel/2012-January/026432.html
> 
I agree that using gpg for signing would simplify things a lot. How
much, in size, does bringing in the requirements for gpg-2.1 add to the
core?

I would be willing to add some man hours for this project.

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------

On Sun, 22 Jan 2012 11:50:13 +0100
Michael Rasmussen <mi...@mi...> wrote:

>> Maybe it would be an option to port opkg to IPCop?
>>
>  is actually a doable solution. opkg needs these options to compile
> tested in trunk chroot):
> ./configure --disable-curl --disable-gpg --enable-openssl
>
> --disable-curl: Use wget to download instead of curl. wget is available
> in IPCop.
> --disable-gpg: Don't use gpgme. Disable package signing with gpg. gpgme
> not available in IPCop.
> --enable-openssl: Enable package signing using PKCS7 from openssl.
> openssl is available in IPCop.
>
> License: opkg is released under GPL2+.

Yes package management is for me a priority on next version (not 2.0.x,
probably 2.1)
I would really prefer using a package management that exist and not create a
new one.

opkg is an option I considered last year. I just looked and compiled opkg
and haven't been farest.
OpenWRT use opkg, I don't know who else do.


As we already have libgpg-error and libgcrypt, I don't know if we should not
upgrade gpg for 2.1. That way, we could use opkg gpg option but need to
add -libassuan libksba, pth, gpgme.
Werner Koch is pushing for an upgrade from gnupg-1 to gnupg-2 for debian
http://lists.gnupg.org/pipermail/gnupg-devel/2012-January/026432.html

Gilles

On Sun, 22 Jan 2012 11:50:13 +0100
Michael Rasmussen <mi...@mi...> wrote:

> Maybe it would be an option to port opkg to IPCop?
> 
It is actually a doable solution. opkg needs these options to compile
(tested in trunk chroot):
./configure --disable-curl --disable-gpg --enable-openssl

--disable-curl: Use wget to download instead of curl. wget is available
in IPCop.
--disable-gpg: Don't use gpgme. Disable package signing with gpg. gpgme
not available in IPCop.
--enable-openssl: Enable package signing using PKCS7 from openssl.
openssl is available in IPCop.

License: opkg is released under GPL2+.

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------

On Sat, 21 Jan 2012 20:34:28 -0800
Nick Austin <ni...@sm...> wrote:

> On Thu, Jan 19, 2012 at 11:11 PM, Michael Rasmussen <mi...@mi...> wrote:
> > Hi all,
> >
> > It think IPCop could gain a lot by having a package management system.
> > I have therefore attached (added since the list does not accept
> > attachments) a proposal for such a package management system to this
> > mail (I hope it is not removed by the list server).
> 
> Also consider the package management scheme used by OpenWRT:
> http://wiki.openwrt.org/doc/techref/opkg
> 
> !DSPAM:4f1b91f1222412758520239!
> 
> 
Maybe it would be an option to port opkg to IPCop?

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------