repackaging pg for debian - Page 2

		Phoenix Labs > Projects > PeerGuardian Linux
repackaging pg for debian

FAQ

Page 2 of 3

Thread Tools

Display Modes


03-05-2006, 03:51 PM	#11
lestlest Member Join Date: Mar 2006 Posts: 53	Re: repackaging pg for debian Here comes a new version. It's attached to the first post in this thread. Changes since 1.5b-3: Code: peerguardnf (1.5b-4) unstable; urgency=low * changed update script to check www.bluetack.co.uk:80 using nmap; * during postinstallation an update will only be tried if there are block lists older than two days in the spool directory (This needs some testing. I'll take care of this in a few days) * fixed logrotation error (wrong pid in /var/run) * package cleanup: removing unnecessary files... -- clessing <clessing@freenet.de> Sat, 4 Mar 2006 02:26:42 +0100 Your feedback ist welcome! Just a "this works" / "this works not" would make my day


03-06-2006, 02:54 AM	#12
lestlest Member Join Date: Mar 2006 Posts: 53	Re: repackaging pg for debian I noticed that my last upload had dependencies in debian experimental... I recompiled the package using pbuilder and reuploaded version 1.5b-4. It should install cleanly within current debian testing now. As a result of using pbuilder the package is not signed correctly. (Though the sources in the zip file are.)


03-11-2006, 07:00 AM	#13
lestlest Member Join Date: Mar 2006 Posts: 53	Re: repackaging pg for debian Code: peerguardnf (1.5-cvs20060228-5) unstable; urgency=low * modified peerguardnf not to install iptables rules automatically. Instead the init script takes care of this. -- clessing <clessing@freenet.de> Sat, 11 Mar 2006 12:41:01 +0100


03-16-2006, 08:48 AM	#14
jre Senior Member Join Date: Sep 2005 Posts: 588	Re: repackaging pg for debian I tried peerguardnf_1.5-cvs20060228-6_i386.deb. Great to have a debian-repository! Special thx for removing the automatic installation of the iptables rules. Two things: 1.) /etc/init.d/peerguardnf: I don't know if it matters but I think your #! /bin/sh should be #!/bin/sh 2.) Code: myhost:/home# /etc/cron.daily/peerguardnf peerguardnf: checking for new block lists... no connection to www.bluetack.co.uk, updating later. dig and ping support this result: Code: myhost:/home$ dig bluetack.co.uk ; <<>> DiG 9.3.2 <<>> bluetack.co.uk ;; global options: printcmd ;; connection timed out; no servers could be reached myhost:/home$ ping bluetack.co.uk PING bluetack.co.uk (67.18.178.4) 56(84) bytes of data. --- bluetack.co.uk ping statistics --- 209 packets transmitted, 0 received, 100% packet loss, time 208410ms But I can still update the blocklists from bluetack with my script. So your network-connectivity test doesn't yield a useful result for me. Greetings jre PS: Starting the daemon and blocking seems to work! Last edited by jre : 03-16-2006 at 08:49 AM. Reason: PS:

03-16-2006, 05:17 PM

#15

lestlest

Member

Join Date: Mar 2006

Posts: 53

Re: repackaging pg for debian

Quote:

Originally Posted by jre

I tried peerguardnf_1.5-cvs20060228-6_i386.deb. Great to have a debian-repository! Special thx for removing the automatic installation of the iptables rules.

Two things:
1.) /etc/init.d/peerguardnf:
I don't know if it matters but I think your
#! /bin/sh should be
#!/bin/sh

I corrected this but it should not be a problem.

Quote:

Originally Posted by jre

2.)

Code:

myhost:/home$ dig bluetack.co.uk

; <<>> DiG 9.3.2 <<>> bluetack.co.uk
;; global options:  printcmd
;; connection timed out; no servers could be reached

myhost:/home$ ping bluetack.co.uk
PING bluetack.co.uk (67.18.178.4) 56(84) bytes of data.

--- bluetack.co.uk ping statistics ---
209 packets transmitted, 0 received, 100% packet loss, time 208410ms

But I can still update the blocklists from bluetack with my script. So your network-connectivity test doesn't yield a useful result for me.

If no nameserver can be reached (dig) but you are able to ping (ping can resolve the name), I have no idea how your name resolution works...

Last edited by lestlest : 03-16-2006 at 05:20 PM.


03-18-2006, 12:14 PM	#16
jre Senior Member Join Date: Sep 2005 Posts: 588	Re: repackaging pg for debian I don't know why dig and ping don't work here with bluetack. But wget works, sometimes it has to wait some time while updating but in the end it always succeeds in getting the updated lists. Maybe you could replace your test by something more general that just looks if the machine is online? Sorry, I don't know how this could be done, but there must be a possibiltiy. Greetings jre


03-18-2006, 08:08 PM	#17
lestlest Member Join Date: Mar 2006 Posts: 53	Re: repackaging pg for debian That looks pretty much as if your network load is too high, causing dig and/or nmap to time out. Try editing the cron script /etc/cron.daily/peerguardnf right at the beginning: the +time switch is a timeout for dig in seconds. Just increase it until dig does not time out anymore. For nmap there is a --host-timeout switch. By default its in miliseconds but have a look at the manpage. (Append an s for seconds, etc.) If network load and timeouts are the problem, please let me know how many seconds you are waiting for the connection. I will include your settings in future releases. (I guess that there are more people out there with heavy traffic and not traffic management... )


03-19-2006, 08:25 PM	#18
jre Senior Member Join Date: Sep 2005 Posts: 588	Re: repackaging pg for debian I changed /etc/cron.daily/peerguardnf Code: dig $TESTHOST +time=120 >/dev/null error=$? if [ $error -eq 0 ]; then nmap --host-timeout 120000 -p80 $TESTHOST \|grep open >/dev/null error=$? fi if [ $error -ne 0 ]; then echo no connection to $TESTHOST, updating later.; exit 0; fi It idled some minutes and ended with no result: Code: peerguardnf: checking for new block lists... no connection to www.bluetack.co.uk, updating later. Then I just commented out the test and tried again, there were no pauses and after 16 secs all lists were downloaded. I admit that this is a strange behaviour of my machine which i should repair. But for now only commenting out the test is a solution for me. This line in /etc/init.d/peerguardnf is wrong PIDFILE=/var/run/pg.pid should be (or did I miss something?): PIDFILE=/var/run/peerguardnf.pid or PIDFILE=/var/run/$NAME.pid I wondered if these rules in PEERGUARD_IN/OUT/FW might be a security risk in case someone connects before peerguardian is started or while it's restarting: Code: ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED greetings jre Last edited by jre : 03-19-2006 at 09:00 PM. Reason: Added my 3rd point

03-20-2006, 06:20 AM

#19

lestlest

Member

Join Date: Mar 2006

Posts: 53

Re: repackaging pg for debian

Quote:

Originally Posted by jre

It idled some minutes and ended with no result:

Code:

peerguardnf: checking for new block lists...
no connection to www.bluetack.co.uk, updating later.

Then I just commented out the test and tried again, there were no pauses and after 16 secs all lists were downloaded. I admit that this is a strange behaviour of my machine which i should repair. But for now only commenting out the test is a solution for me.

That's odd indeed. By default dig uses nameservers from /etc/resolv.conf and if ping can resolve a hostname if have no idea why dig can't.

Quote:

Originally Posted by jre

This line in /etc/init.d/peerguardnf is wrong
PIDFILE=/var/run/pg.pid
should be (or did I miss something?):
PIDFILE=/var/run/peerguardnf.pid or
PIDFILE=/var/run/$NAME.pid

Oh! Yes. I missed this. (new package is online)

Quote:

Originally Posted by jre

I wondered if these rules in PEERGUARD_IN/OUT/FW might be a security risk in case someone connects before peerguardian is started or while it's restarting:

Code:

ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED

I don't think so. They say that connections that are already established and that traffic that is related to established connecions is ok.
I'm 99% sure that this is ok.

Last edited by lestlest : 03-20-2006 at 06:35 AM.

03-20-2006, 06:42 AM

#20

jre

Senior Member

Join Date: Sep 2005

Posts: 588

Re: repackaging pg for debian

Quote:

Originally Posted by lestlest

I don't think so. They say that connections that are already established and that traffic that is related to established connecions is ok.
I'm 99% sure that this is ok.

I see the security risk in those few seconds a day when PG is not running. If someone from outside or some bad program on your machine establishes a connections to a bad IP then PG will not be able to drop these packets when he's running again.
I just wonder what happens when in this time a connection is established to a fake-seeder (didi i use the right word? i'm talking about P2P). This would damage the "security" PG aims at.
jre

Page 2 of 3

« Previous Thread | Next Thread »

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Posting Rules
You may not post new threads You may not post replies You may not post attachments You may not edit your posts vB code is On Smilies are On [IMG] code is On HTML code is Off

Forum Jump

All times are GMT -5. The time now is 06:48 PM.