ipcop-devel Mailing List for IPCop Firewall

> --- ipcop/trunk/src/misc-progs/settimenow.c	2007-11-29 12:55:11 UTC (rev
> 778) +++ ipcop/trunk/src/misc-progs/settimenow.c	2007-11-29 14:21:49 UTC
> (rev 779) @@ -40,7 +40,7 @@
>  	// What should we do?
>  	if (argc==1)
>  	{
> -		safe_system("/bin/touch /var/log/time/settimenow");
> +		safe_system("/usr/bin/touch /var/log/time/settimenow");
>  		safe_system("/usr/local/bin/timecheck");
>  		return 0;
>  	}
>
>
Hello,

using "flag files" to pilot execution of other programs is
a bad solution.

This particular example must be converted to a call
/usr/local/bin/timecheck --settimenow

Why? Simply because it causes a lot of interrogation after
a crash for example (persistance of a volatile indication???),
restore/save or not the flag-files, write acces while maybe
we run on read only system, who as ownership...

Thousand of reasons to kill this programmatic style.


Franck

Olaf Westrik wrote:
> Maikel Punie wrote:
> 
>>> With 4 developers (which are also working part time) we will never 
>>> finish such a project.
>> Well why do you guys want to write your own package manager?
> 
> The effort I was referring to is creating the packages, testing them in 
> various combinations and maintaining them.
> 
> 
> Olaf
> 

You may find that more people are willing to help out in this case.

Having package maintainers, like debian/ubuntu and so on..



Chris

On Wed, 2007-11-28 at 13:02 -0800, Darren Critchley wrote:

> Another interesting thing I have found is the memory limit, I can't 
> remember if the 4G highmem option has been enabled in the ipcop kernel 
> or not, so the rest of this may be totally irrelevant. But some of these 
> machines I am sending out with 8 Gigs of ram, which means the 64G 
> Highmem option needs enabling in the kernel, simple fix, no problem.

It doesn't strictly *require* it does it? Sure if you want more than 4G
to be addressable then you will need that option. However, if you're
happy to only utilise 4 of the available 8 you don't need to do anything
special?

What are you using all that extra RAM for? only thing I can imagine is
squid? Seems like vast overkill even in that case.

> However, when the 64G option is enabled, low end processors on longer 
> work. An example of this was the EPIA boards from VIA, the kernel will 
> not boot with 64G enabled. My solution to this was to leave the non SMP 
> kernels at 4G himem enabled and the SMP set to 64G.

I have an C7 based EPIA board and have no problem with the 64G highmem
option. However, 64G highmem requires the processor supports the PAE
extension, which rules out anything before a pentium pro and certain
third party x86 processors.

> Eventually this bridge will have to be crossed by the dev team, and you 
> will have to decide if you are going to make a separate ISO or deal with 
> these options in another way. Once the 64G Highmem is enabled, older low 
> end processors will not boot.
> So I thought I would bring it to your attention.

I don't really see the point in a 32 bit ISO with 64G highmem support,
I'd say we keep the 32 bit ISO as it is and produce a separate ISO for
64bit archs. Seeing as all the high end systems you talk about are
x86-64 that should solve the issue.

Equally though I consider throwing so much hardware at your firewalls
rather bizarre.

-- 
 Robert Kerr

On Friday 30 November 2007, Gilles Espinasse wrote:
> What do think of the changes I made on 1.4 lfs/Config?
>
> I understand this was the opposite way you change on svn.
> Because of mtools custom html error page, I think you now understand
> why I add a md5 check after loading a file.
> This duplicate md5 control but prevent a wrong file to be copied
> on cache. Once a file is on cache, LOAD target does nothing.
>
> MD5 check has to run on each build as it is the only way to control
> a file on cache still have the last _MD5.
>
> I don't pretend it is a nice looking code.
> This could be improved by using another time WGET macro on MD5
> (not yet tested)
>
> I just try to make it effective facing the real problem we encounter:
> - custom error page so wget return no error but no package code at all
> - wget return error on wrong URL
> - when a _MD5 is changed, reload the file during MD5 check.
>   This is effective when a package _MD5 change ( not a current case)
>   package _MD5 change had happen, not currently, for example when a
>   package license has been changed recently.
>   Not breaking on error allow a smooth nightly build.
> - when a file is loaded on /tmp but _MD5 is wrong, even if you fix _MD5,
>   next LOAD will fail because of wget (-c|--continue) can't load more
>   on /tmp
>
>
> Gilles


Gilles,

I only looked very absent mindedly at it.  Normally I ignore cvs :-)  I'll 
look into this now.

IvanK.

What do think of the changes I made on 1.4 lfs/Config?

I understand this was the opposite way you change on svn.
Because of mtools custom html error page, I think you now understand
why I add a md5 check after loading a file.
This duplicate md5 control but prevent a wrong file to be copied
on cache. Once a file is on cache, LOAD target does nothing.

MD5 check has to run on each build as it is the only way to control
a file on cache still have the last _MD5.

I don't pretend it is a nice looking code.
This could be improved by using another time WGET macro on MD5
(not yet tested)

I just try to make it effective facing the real problem we encounter:
- custom error page so wget return no error but no package code at all
- wget return error on wrong URL
- when a _MD5 is changed, reload the file during MD5 check.
  This is effective when a package _MD5 change ( not a current case)
  package _MD5 change had happen, not currently, for example when a
  package license has been changed recently.
  Not breaking on error allow a smooth nightly build.
- when a file is loaded on /tmp but _MD5 is wrong, even if you fix _MD5,
  next LOAD will fail because of wget (-c|--continue) can't load more
  on /tmp


Gilles

Achim Weber wrote:

> I'm no RRD expert, but shouldn't the RRD adjustment be done after potential time
> sync in case the time is (very) wrong!?

You are right.
If the time is in the past (which is usually the case if RTC is broken 
;-)), rrd update will just be ignored.


Olaf


PS this time sync just might prove very useful.

-- 

A weizen a day helps keep the doctor away.

> Revision: 784
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=784&view=rev
> Author:   owes
> Date:     2007-11-30 00:51:38 -0800 (Fri, 30 Nov 2007)
> 
> Log Message:
> -----------
> Adjust disk RRD after boot (forward from 1.4)
> 
> Modified Paths:
> --------------
>     ipcop/trunk/config/rc.d/rc.sysinit
> 
> Modified: ipcop/trunk/config/rc.d/rc.sysinit
> ===================================================================
> --- ipcop/trunk/config/rc.d/rc.sysinit	2007-11-30 02:16:57 UTC (rev 783)
> +++ ipcop/trunk/config/rc.d/rc.sysinit	2007-11-30 08:51:38 UTC (rev 784)
> @@ -277,6 +277,11 @@
>  echo "Dumping boot messages"
>  /bin/dmesg > /var/log/dmesg
>  
> +if [ -e /var/log/rrd/disk.rrd ]; then
> +	echo "Adjusting graphs to compensate for boot"
> +	/usr/bin/perl -e 'use RRDs;RRDs::update("/var/log/rrd/disk.rrd","-t","readsect:writesect","N:U:U");'
> +fi
> +
>  echo "Synchronizing time (if set)"
>  /usr/local/bin/settimenow boot
>  echo "Starting crond"
> @@ -308,4 +313,3 @@
>  /usr/bin/beep -l 75 -f 1000
>  /usr/bin/beep -l 75 -f 2000
>  /usr/bin/beep -l 75 -f 3000
> -


I'm no RRD expert, but shouldn't the RRD adjustment be done after potential time
sync in case the time is (very) wrong!?

Achim

Maikel Punie wrote:

>> With 4 developers (which are also working part time) we will never 
>> finish such a project.
> 
> Well why do you guys want to write your own package manager?

The effort I was referring to is creating the packages, testing them in 
various combinations and maintaining them.


Olaf

-- 

A weizen a day helps keep the doctor away.

Olaf Westrik wrote:
> With 4 developers (which are also working part time) we will never 
> finish such a project.

Well why do you guys want to write your own package manager?
There are a couple availeble that are build to be small and limit space
thats needed.

Ipkg (http://handhelds.org/moin/moin.cgi/Ipkg) is a very small package
manager that will forfill all the needs. Its special build for systems
that have storage limitations like ipcop.

regards,
Maikel

Gilles Espinasse wrote:

> We have already one installed in /etc/snort.
> I would not have introduce trouble with twice the same file but only the one
> that is not updated is used.
> 
> I think we should go that way :
> - remove etc/snort/rules/threshold.conf from installed files
> - include etc/snort/rules
> 
> That's the simpliest solution

A quick (and incomplete) test showed that this mod to lfs/snort and 
changing rootfiles, produces /etc/snort/rules with correct ownership and 
same rules files as before.


Index: ipcop/lfs/snort
===================================================================
RCS file: /cvsroot/ipcop/ipcop/lfs/snort,v
retrieving revision 1.6.2.26
diff -u -r1.6.2.26 snort
--- ipcop/lfs/snort     21 Aug 2007 20:19:03 -0000      1.6.2.26
+++ ipcop/lfs/snort     29 Nov 2007 16:32:38 -0000
@@ -101,6 +101,7 @@
         # Install rules from pr-2.4 tar.gz
         cd /etc/snort && tar zxf $(DIR_DL)/snortrules-pr-2.4.tar.gz 
--exclude='doc'
         install -g snort -o snort -m 0644 
/etc/snort/rules/threshold.conf /etc/snort
+       rm /etc/snort/rules/threshold.conf
         # disable standard pr-2.4 rules broken by 2.6.1.5 upgrade in 
web-misc.rules
         sed -i  -e '/sid:1143; rev:7/s/^/# /' \
                 -e '/sid:1144; rev:7/s/^/# /' \



-- 

A weizen a day helps keep the doctor away.

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBUaHUs
IDI5IE5vdiAyMDA3IDIxOjA2OjU2ICswMTAwDQpBY2hpbSBXZWJlciA8ZG90emJhbGxAZ214Lm5l
dD4gd3JvdGU6DQoNCj4gVGhlcmUgaXMgYSBuZXcgcmVsZWFzZSBvZiBTcXVpZDoNCj4gIGh0dHA6
Ly93d3cuc3F1aWQtY2FjaGUub3JnL1ZlcnNpb25zLw0KPiANCj4gU2hvdWxkbid0IHdlIGluY2x1
ZGUgaXQgaW4gMS40LjE3Ly4xOD8NCj4gDQpBIHBhY2thZ2UgbWFuYWdlbWVudCBzeXN0ZW0gd291
bGQgaGF2ZSBtYWRlIHRoaXMgZWFzeTotKQ0KU29ycnksIEkgY291bGRuJ3QgcmVzaXN0Oi0pDQoN
Ci0gLS0gDQpIaWxzZW4vUmVnYXJkcw0KTWljaGFlbCBSYXNtdXNzZW4NCg0KR2V0IG15IHB1Ymxp
YyBHbnVQRyBrZXlzOg0KbWljaGFlbCA8YXQ+IHJhc211c3NlbiA8ZG90PiBjYw0KaHR0cDovL2tl
eXNlcnZlci52ZXJpZGlzLmNvbToxMTM3MS9wa3MvbG9va3VwP29wPWdldCZzZWFyY2g9MHhEM0M5
QTAwRQ0KbWlyIDxhdD4gZGF0YW5vbSA8ZG90PiBuZXQNCmh0dHA6Ly9rZXlzZXJ2ZXIudmVyaWRp
cy5jb206MTEzNzEvcGtzL2xvb2t1cD9vcD1nZXQmc2VhcmNoPTB4RTUwMUY1MUMNCm1pciA8YXQ+
IG1pcmFzIDxkb3Q+IG9yZw0KaHR0cDovL2tleXNlcnZlci52ZXJpZGlzLmNvbToxMTM3MS9wa3Mv
bG9va3VwP29wPWdldCZzZWFyY2g9MHhFM0U4MDkxNw0KLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRGViaWFuIEhpbnQgIzMx
OiBEb2N1bWVudGF0aW9uIGNhbiBiZSBtYWRlIGF2YWlsYWJsZSBhdA0KaHR0cDovL2xvY2FsaG9z
dC8gYnkgaW5zdGFsbGluZyB0aGUgJ2RvYy1iYXNlJyBhbmQgJ2RvYy1jZW50cmFsJw0KcGFja2Fn
ZXMgYW5kIHRoZWlyIGRlcGVuZGVuY2llcy4NCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0t
DQpWZXJzaW9uOiBHbnVQRyB2MS40LjYgKEdOVS9MaW51eCkNCg0KaUQ4REJRRkhUeDIyVkVyWVZl
UG9DUmNSQXRtakFKd1BaUEp4WjdiSG5UUDBOTUhOUVpkNHR4bk1Fd0NlTGpsNQ0KRmN4ZU9MSVVS
QzljejJhd0ZSTkZXYk09DQo9NUxobA0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQo=

There is a new release of Squid:
 http://www.squid-cache.org/Versions/

Shouldn't we include it in 1.4.17/.18?

Achim

Gilles Espinasse wrote:

>> For example, if dhcp is a real package we should first remove all hooks
>> in rc scripts, remove from GUI, etc. etc.
>>
> I never intend to do that.
> 
>> However if it is still part of ipcop core and delivered when IPCop is
>> installed, things are much more easier. Since the interaction with other
>> core elements is installed.
>>
> Yes, that what I mean.

Ok.  Glad we sorted that out :-)


> The only one problem is to not have the package include twice, one by package
> rootfiles, one by the entire rootfile inclusion Maybe the SKIP trick could work
> there.

I think we would need to make the system intelligent to handle double 
installation of package and skip some files if (full) update includes 
something already changed by a package.


Olaf

-- 

A weizen a day helps keep the doctor away.

Le jeudi 29 novembre 2007 12:16, Olaf Westrik a écrit :
> Gilles Espinasse wrote:
> > IPCop should have a better way to deliver updates.
>
> That is true.
>
> But I see a difference between updating and a packaging system.  Maybe
> that is just because we have not set the primary goals yet.
>
> For example, if dhcp is a real package we should first remove all hooks
> in rc scripts, remove from GUI, etc. etc.
>
> However if it is still part of ipcop core and delivered when IPCop is
> installed, things are much more easier. Since the interaction with other
> core elements is installed.
>
>
> If the goal is updating (and we call that packaging system), I fully agree.
> If it is stripping from IPCop and then adding through a packaging
> system, I have to disagree, that is too much work IMHO.
>
>
> cheers Olaf


Inform the GUI about what products/hardware are available on the FW.
Have a GUI fully functionnal that produce a config-file-package that
suits the products/hardware .
Send that package to the FW. It has no big decisions to take. All is
done outside of it.
If it receives a config-file-package with dhcp server enabled and no dhcp 
package exists, it just rejects the config.
A contrario, have no dhcp configured with the package installed is 
not a problem.

Don't mix the package programs files and the management that can be
done for that package.


Franck

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

> Le jeudi 29 novembre 2007 08:37, Gilles Espinasse a écrit :
>
> >
> > If we do that, no reason to not create an apache package.
> > We probably should separate there apache code from our web interface,
> > allowing independante update of both parts.
> >
> > I don't know if that make sens to create a package with all web interface
> > pages or been able to update each page separatly.
> >
> > Gilles
> >
> >
> It make sense, yes, of course because a firewall doesn't need
> to run a GUI.
My question was, should we have :
- a meta package with all web GUI pages (package version will be
  a dummy +1 at each release)
- a separate package for each page
  (we would need to automate everything, possibily use svn version
  in package name)
- no package for the web GUI pages and continue with updates

I would prefer to avoid refreshing pages that have not officially
changed in case a local change has been made.

> The GUI can run completly outside of it and output the configuration files.
> Having them on the same machine is just another convinience that avoid
> to setup a secure communication path between the FW and GUI/management.
>
> Another IPCopv2+ enhancement to have in mind for future. Never never never
> touch/read config files directly from GUI.cgi but allways trougth a common
> interface...to invent! Same for reading logs.
First step is to separate saving registered configuration settings on disk from
writing configuration files before starting a service.
This way, we could rewrite apache configuration file when green IP is changed.
...

Gilles

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBUaHUs
IDI5IE5vdiAyMDA3IDEzOjE2OjExICswMTAwDQpHaWxsZXMgRXNwaW5hc3NlIDxnLmVzcEBmcmVl
LmZyPiB3cm90ZToNCg0KPiBUaGUgb25seSBvbmUgcHJvYmxlbSBpcyB0byBub3QgaGF2ZSB0aGUg
cGFja2FnZSBpbmNsdWRlIHR3aWNlLCBvbmUgYnkNCj4gcGFja2FnZSByb290ZmlsZXMsIG9uZSBi
eSB0aGUgZW50aXJlIHJvb3RmaWxlIGluY2x1c2lvbiBNYXliZSB0aGUNCj4gU0tJUCB0cmljayBj
b3VsZCB3b3JrIHRoZXJlLg0KU2luY2UgcGVybCBEQl9GaWxlIGlzIGEgcGxhaW4gZmlsZSB0aGlz
IGZpbGUgY291bGQgYmUgaW5zdGFsbGVkIGFzIHBhcnQNCm9mIHRoZSBiYXNlIHN5c3RlbSBwcmUt
cG9wdWxhdGVkIHdpdGggaW5mb3JtYXRpb24gYWJvdXQgdGhlIGJhc2UNCnN5c3RlbS4gQSB1c2Vy
IHRyeWluZyB0byBpbnN0YWxsIGEgcGFja2FnZSwgd2hpY2ggaXMgYWxyZWFkeSBwYXJ0IG9mDQp0
aGUgYmFzZSBzeXN0ZW0sIHdpbGwgYmUgbm90aWZpZWQgdGhhdCB0aGlzIHBhY2thZ2UgaXMgYWxy
ZWFkeQ0KaW5zdGFsbGVkLCBhbmQgdGhlIHBhY2thZ2UgbWFuYWdlciB3aWxsIHRoZSBzaWxlbnRs
eSBleGl0Lg0KDQotIC0tIA0KSGlsc2VuL1JlZ2FyZHMNCk1pY2hhZWwgUmFzbXVzc2VuDQoNCkdl
dCBteSBwdWJsaWMgR251UEcga2V5czoNCm1pY2hhZWwgPGF0PiByYXNtdXNzZW4gPGRvdD4gY2MN
Cmh0dHA6Ly9rZXlzZXJ2ZXIudmVyaWRpcy5jb206MTEzNzEvcGtzL2xvb2t1cD9vcD1nZXQmc2Vh
cmNoPTB4RDNDOUEwMEUNCm1pciA8YXQ+IGRhdGFub20gPGRvdD4gbmV0DQpodHRwOi8va2V5c2Vy
dmVyLnZlcmlkaXMuY29tOjExMzcxL3Brcy9sb29rdXA/b3A9Z2V0JnNlYXJjaD0weEU1MDFGNTFD
DQptaXIgPGF0PiBtaXJhcyA8ZG90PiBvcmcNCmh0dHA6Ly9rZXlzZXJ2ZXIudmVyaWRpcy5jb206
MTEzNzEvcGtzL2xvb2t1cD9vcD1nZXQmc2VhcmNoPTB4RTNFODA5MTcNCi0gLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoZSBu
YWtlZCB0cnV0aCBvZiBpdCBpcywgSSBoYXZlIG5vIHNoaXJ0Lg0KCQktLSBXaWxsaWFtIFNoYWtl
c3BlYXJlLCAiTG92ZSdzIExhYm91cidzIExvc3QiDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUt
LS0tLQ0KVmVyc2lvbjogR251UEcgdjEuNC42IChHTlUvTGludXgpDQoNCmlEOERCUUZIVHJlb1ZF
cllWZVBvQ1JjUkFzWWtBSjQxUHlsUFR1dTlYeHA2R1E5YmhEV0ZyYklQSFFDZ202eU8NCk91dG93
NUlFd1ltMTBMeGg3N3ZFS1drPQ0KPVB5SloNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBUaHUs
IDI5IE5vdiAyMDA3IDEzOjE2OjExICswMTAwDQpHaWxsZXMgRXNwaW5hc3NlIDxnLmVzcEBmcmVl
LmZyPiB3cm90ZToNCg0KPiBZZXMsIHRoYXQgd2hhdCBJIG1lYW4uDQo+IFBhY2thZ2UgY29udGFp
biBvbmx5IHdoYXQgaXMgaW5zdGFsbGVkIGJ5IGxmcyBzY3JpcHQuIFNvIHdlIGFscmVhZHkNCj4g
aGF2ZSB0aGUgbGlzdCBvZiBmaWxlcyB0byBiZSBwYWNrZWQuDQo+IFRoZSBvbmx5IG9uZSBwcm9i
bGVtIGlzIHRvIG5vdCBoYXZlIHRoZSBwYWNrYWdlIGluY2x1ZGUgdHdpY2UsIG9uZSBieQ0KPiBw
YWNrYWdlIHJvb3RmaWxlcywgb25lIGJ5IHRoZSBlbnRpcmUgcm9vdGZpbGUgaW5jbHVzaW9uIE1h
eWJlIHRoZQ0KPiBTS0lQIHRyaWNrIGNvdWxkIHdvcmsgdGhlcmUuDQoNClRoaXMgaXMgZXhhY3Rs
eSB3aGF0IEkgaGF2ZSBpbiBtaW5kLiBUaGUgaW50ZXJuYWwgc3RydWN0dXJlIG9mIGENCnBhY2th
Z2UgbWF5IGJlIHRoZSBmb2xsb3dpbmc6DQpwYWNrYWdlX3hfeV96DQogICAgfA0KICAgIHxfX2lw
bQ0KICAgIHwgICAgfA0KICAgIHwgICAgfF9fY29udHJvbHNjcmlwdA0KICAgIHwgICAgfA0KICAg
IHwgICAgfF9fcGFja2FnZV9pbmZvDQogICAgfA0KICAgIHxfX3BhY2thZ2VfeF95X3oudGFyLmd6
DQoNCnVudGFyLWluZyBwYWNrYWdlX3hfeV96LnRhci5neiB3aWxsIGNyZWF0ZSB0aGUgdGVtcG9y
YXJ5IGluc3RhbGwgdHJlZQ0KaW4sIGVnLiB0bXAuDQoNCkNvbnRyb2xzY3JpcHQgaXMgYSBzaW1w
bGUgc2hlbGwgc2NyaXB0IHJlcGxpY2F0aW5nIGluc3RhbGwgaW5zdHJ1Y3Rpb25zDQpmcm9tIGxm
cy4NCg0KIyEvYmluL3NoDQoNCk5BTUU9dGVzdDENCkZPUk1BVD10YXIuZ3oNCkNQPSIvYmluL2Nw
IC1yIg0KTUQ9Ii9iaW4vbWtkaXIgLXAiDQpSTT0iL2Jpbi9ybSAtcmYiDQpUQVI9Ii9iaW4vdGFy
IHh6ZiINCg0KdW50YXIoKSB7DQoJJHtUQVJ9ICR7TkFNRX0uJHtGT1JNQVR9ICYmIHJldHVybiAw
DQoJcmV0dXJuIDENCn0NCg0KaW5zdGFsbCgpIHsNCgkke0NQfSB1c3IvYmluLyR7TkFNRX0gL3Vz
ci9iaW4NCgkke01EfSAvdXNyL3NoYXJlL2RvYy8ke05BTUV9DQoJJHtDUH0gdXNyL3NoYXJlL2Rv
Yy8ke05BTUV9IC91c3Ivc2hhcmUvZG9jDQp9DQoNCnVuaW5zdGFsbCgpIHsNCgkke1JNfSAvdXNy
L2Jpbi8ke05BTUV9DQoJJHtSTX0gL3Vzci9zaGFyZS9kb2MvJHtOQU1FfQ0KfQ0KDQpjbGVhbigp
IHsNCgkke1JNfSB1c3INCn0NCg0KY2FzZSAiJDEiIGluDQoJaW5zdGFsbCkNCgkJdW50YXINCgkJ
aWYgWyAiJD8iIC1lcSAwIF07DQoJCXRoZW4NCgkJCWluc3RhbGwNCgkJCWNsZWFuDQoJCWZpDQoJ
CTs7DQoJdW5pbnN0YWxsKQ0KCQl1bmluc3RhbGwNCgkJOzsNCgkqKQ0KCQllY2hvICJVc2FnZTog
JDAge2luc3RhbGx8dW5pbnN0YWxsfSINCgkJOzsNCmVzYWMNCiANCi0gLS0gDQpIaWxzZW4vUmVn
YXJkcw0KTWljaGFlbCBSYXNtdXNzZW4NCg0KR2V0IG15IHB1YmxpYyBHbnVQRyBrZXlzOg0KbWlj
aGFlbCA8YXQ+IHJhc211c3NlbiA8ZG90PiBjYw0KaHR0cDovL2tleXNlcnZlci52ZXJpZGlzLmNv
bToxMTM3MS9wa3MvbG9va3VwP29wPWdldCZzZWFyY2g9MHhEM0M5QTAwRQ0KbWlyIDxhdD4gZGF0
YW5vbSA8ZG90PiBuZXQNCmh0dHA6Ly9rZXlzZXJ2ZXIudmVyaWRpcy5jb206MTEzNzEvcGtzL2xv
b2t1cD9vcD1nZXQmc2VhcmNoPTB4RTUwMUY1MUMNCm1pciA8YXQ+IG1pcmFzIDxkb3Q+IG9yZw0K
aHR0cDovL2tleXNlcnZlci52ZXJpZGlzLmNvbToxMTM3MS9wa3MvbG9va3VwP29wPWdldCZzZWFy
Y2g9MHhFM0U4MDkxNw0KLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRGFydGggVmFkZXI6DQoJVGhlIEZvcmNlIGlzIHN0cm9u
ZyB3aXRoIHRoaXMgb25lLg0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246
IEdudVBHIHYxLjQuNiAoR05VL0xpbnV4KQ0KDQppRDhEQlFGSFRyVHNWRXJZVmVQb0NSY1JBaFI3
QUowU1llL2lVek1NWEhIeGNqRlRtbDlIUEpvemxnQ2VPaTJqDQpRQkd4dVZDWXlic3JBV0V3Nkx6
QTBIND0NCj1UV29PDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg==

Le jeudi 29 novembre 2007 08:37, Gilles Espinasse a écrit :

>
> If we do that, no reason to not create an apache package.
> We probably should separate there apache code from our web interface,
> allowing independante update of both parts.
>
> I don't know if that make sens to create a package with all web interface
> pages or been able to update each page separatly.
>
> Gilles
>
>
It make sense, yes, of course because a firewall doesn't need
to run a GUI.
The GUI can run completly outside of it and output the configuration files.
Having them on the same machine is just another convinience that avoid
to setup a secure communication path between the FW and GUI/management.

Another IPCopv2+ enhancement to have in mind for future. Never never never
touch/read config files directly from GUI.cgi but allways trougth a common
interface...to invent! Same for reading logs.
Something very easy to deal with while developping on the GUI even if today 
the 'secure path' is limited to direct disk I/O (eg FW and GUI cohabit).

Franck

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

> Gilles Espinasse wrote:
>
> > IPCop should have a better way to deliver updates.
>
> That is true.
>
> But I see a difference between updating and a packaging system.  Maybe
> that is just because we have not set the primary goals yet.
>
> For example, if dhcp is a real package we should first remove all hooks
> in rc scripts, remove from GUI, etc. etc.
>
I never intend to do that.

> However if it is still part of ipcop core and delivered when IPCop is
> installed, things are much more easier. Since the interaction with other
> core elements is installed.
>
Yes, that what I mean.
Package contain only what is installed by lfs script. So we already have the
list of files to be packed.
The only one problem is to not have the package include twice, one by package
rootfiles, one by the entire rootfile inclusion Maybe the SKIP trick could work
there.
>
> If the goal is updating (and we call that packaging system), I fully agree.
> If it is stripping from IPCop and then adding through a packaging
> system, I have to disagree, that is too much work IMHO.
>
Totally ok

When a package is not installed, we may do two things :
- on the GUI, only add a simple test to know if a package is installed and warn
if it is not.
- maybe have a small script that replace the binary and state "Install xxx
package to use"


I think we should have a similar warning for gcc and make with a script that
display a "Read building how-to" warning and the URL.
Easier for gcc and make, we could install one script in /usr/local/bin and
symlink for the other. This would spare us from the newbee messages trying to
compile something inside IPCop.

For real packages, it could be more complex to install the replacement script in
the exact path.


Gilles

Gilles Espinasse wrote:

> IPCop should have a better way to deliver updates.

That is true.

But I see a difference between updating and a packaging system.  Maybe 
that is just because we have not set the primary goals yet.

For example, if dhcp is a real package we should first remove all hooks 
in rc scripts, remove from GUI, etc. etc.

However if it is still part of ipcop core and delivered when IPCop is 
installed, things are much more easier. Since the interaction with other 
core elements is installed.


If the goal is updating (and we call that packaging system), I fully agree.
If it is stripping from IPCop and then adding through a packaging 
system, I have to disagree, that is too much work IMHO.


cheers Olaf

-- 

A weizen a day helps keep the doctor away.

> On Thursday 29 November 2007 09:41:20 Achim Weber wrote:
..
> There is one file commented (#etc/snort/rules/threshold.conf)
> why is this?
> Should it not be on the installed system?
We have already one installed in /etc/snort.
I would not have introduce trouble with twice the same file but only the one
that is not updated is used.

I think we should go that way :
- remove etc/snort/rules/threshold.conf from installed files
- include etc/snort/rules

That's the simpliest solution

Other subjects
I have broken ./make.sh prefetch, will fix that tonight
A few packages does not properly load. I haven't yet look if it was temporary
web site troubles or files no more availables


Gilles

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

> Gilles Espinasse wrote:
>
> > Many features could be packaged:
> > - dhcp
> > - dnsmasq
> > - ntp
> > - squid
> > - tzdata, probably tzcode too (we should add separate lfs file for that)
> >
> > If we do that, no reason to not create an apache package.
> > We probably should separate there apache code from our web interface,
> > allowing independante update of both parts.
> >
> > I don't know if that make sens to create a package with all web interface
> > pages or been able to update each page separatly.
>
>
> I know that we can package almost every feature.
> But what is the advantage ?  Save a few KB of disk space ?

There is multiples advantages
- faster to release on package update for security issues
  We no more depend if everything is ready for a new release
  and could just update one package in the repository.
- better testing
  Need to have a testing repository intended to qualify new
  packages before a release and allow to go back to last
  official package release.
- update only what you want depending of your update policy
  Actual update is a big mix of everything.
  You can't actually update just one part but not another that
  you have have modified in an incompatible manner.

> And to what cost ?  If we modularize such core features like dhcp, dns,
> ntp we most likely have much work to get them to operate together again
> (or in any of the possible combinations).
>
We should start by the most frequenly updated packages.

> With 4 developers (which are also working part time) we will never
> finish such a project.
>
We don't need to package everything before to be ready.
We could start with a few packages ready and progressively
shift other packages from the global update system to the
packaging system.
I don't think it will be a really big job.
With 20 packages, we probably cover 90% of the need.
We should never have more than 100 packages (like a computer
never will need more than 640 kb)

We already have the script to restart every services.
In my installpackage oriented view, we just need :
- to create the 20 setup scripts to unpack and call the script
  to restart thoses services,
- to create an INFORMATION variable that will contain the
  information displayed during installation
- add a hook to a PACK macro in Config and add a call to PACK
  after POSTBUILD

When multiples packages are installed in the same time, just
tag that a service has to be restarted on installation and
when every new package is installed, a global script could
do all actions in the right order and just once.

I understand packaging add more task today.
But life should be really better when that will start to work.
I was reluctant when endian goes that way.
I have not look how they do (I think it was rpm based).
But more I think to the subject, more I know it is better than
our all in one updates.

To translate to a different OS world, would you accept to
install on Windows(TM) only service pack after service pack
and not separate packages when released.

That's my view of how update system work on IPCop actually.
We are somewhere between Windows service pack release
every two years and a monthly delivery update.

IPCop should have a better way to deliver updates.

Gilles

On Thursday 29 November 2007 09:41:20 Achim Weber wrote:
> Olaf Westrik wrote:
> > My proposal for fixing: lfs/snort should insert only the wanted files
> > below /etc/snort/rules
> > rootfiles can then use /etc/snort/rules
> >
> >
> > Olaf
>
> Another idea might be a post-install script which correct some directory
> owner/group/permissions at the end of the installation (after file
> unpacking or before reboot). Simple chown/chmod where it is needed.
>

> Another idea *g*
>
> Achim
>
Achim,
 That sounds like a better plan  certainly better than dropping SNORT !!!
-- 
TTFN
    Caparo

Olaf Westrik wrote:

> My proposal for fixing: lfs/snort should insert only the wanted files 
> below /etc/snort/rules
> rootfiles can then use /etc/snort/rules
> 
> 
> Olaf

Another idea might be a post-install script which correct some directory
owner/group/permissions at the end of the installation (after file unpacking or
before reboot). Simple chown/chmod where it is needed.

Snort and Cron are the first candidates but there might be some more to come.

No need to include the directory in rootfiles (no danger to include more than
wanted) and no need to have some mixture of rootfile list in rootfile-file(s)
and in lfs-script(s).

> PS: on second thought, the best fix would simply remove snort altogether 
> *evil grin*

Another idea *g*

Achim

> 
> I know that we can package almost every feature.
> But what is the advantage ?  Save a few KB of disk space ?
> And to what cost ?  If we modularize such core features like dhcp,
> dns, ntp we most likely have much work to get them to operate
> together again (or in any of the possible combinations).
> 
> With 4 developers (which are also working part time) we will never
> finish such a project.
> 
I suggest that any option not enabled by default could be a packaged.

-- 
Dave Taylor