Menu
▾
▴
sqlgrey-users
|
From: Lionel B. <lio...@bo...> - 2005-06-08 17:25:53
|
Paolo Andretta wrote: > On Wed, 8 Jun 2005, Lionel Bouton wrote: > >>> Thanks for your work. >>> I am using SQLGrey in a Trustix box (attached rpm -qi report) >>> >>> Previous 1.4.x version have problems (in my box) when DB (SQL Lite in >>> /var/lib/sqlgrey), became about 16MB size. >>> After upgrade to 1.4.8 I have problems also with smallest DB. >>> I solve restarting the server and if still having problem, removing >>> the DB that was recreated on next start. >>> I have similar problem to 2 different box (but same linux >>> distro/conf); so I can't understand if it is a sqlgrey's problem or my >>> perl/conf problem. >>> >>> This is what I think is relevant in my log: >>> >>> Jun 8 10:56:14 mx7 sqlgrey: fatal: Modification of a read-only value >>> attempted at >>> /usr/lib/perl5/5.8.5/i586-linux-thread-multi/Sys/Syslog.pm line 312. >> > >> You may have several problems here. The fact that you get problems when >> the size of the database grows probably means there is a problem with >> SQLite or its Perl DBD driver. >> You didn't tell what problems you had exactly so I don't have any idea >> of what is happening. > > > Thanks for replay. > The daemon dead. So mail are refused and users ... ;-) > I assume the daemon dies at the time you get the Syslog.pm error. I'm betting on a pure Perl problem. Which version of Net::Server::Multiplex do you have ? > >> The Syslog.pm errors are puzzling. Did you have them with previous 1.4.x >> versions or only with 1.4.8? > > > Also with the previous 1.4.x. But very limited compared with current > problems. > >> What was sqlgrey doing at the time (you can use a higher log level >> and check the postfix logs of the same period)? > > > I have Verbose = 1. Can increase to 2/3/... or is a on/off parameter? > No more info from postfix. You can comment "verbose = 1" and uncomment "debug" in sqlgrey.conf. > > > 1.5.x transition can be an option for a production server? With SQLite, I'm not sure (the point I'm worrying about is the new asynchronous cleanup, I've made it run a few times on SQLite but not on an extended period). 1.5.x is well tested with MySQL and PostgreSQL. Unless a new function we are discussing on the mailing-list is proven useful to me shortly, I'm planning to release a 1.6.0 stable version based on 1.5.9. > I can consider using MySQL with 1.4.x or 1.5.x. > Then 1.5.9 with MySQL should be fine. If you have Syslog.pm errors and/or crashes in this configuration, then it's most probably a Perl problem as many users run MySQL with 1.5.x without trouble. Lionel. |
|
From: Michel B. <mi...@bo...> - 2005-06-08 21:52:02
|
Le Mercredi 08 Juin 2005 19:26, Lionel Bouton a =E9crit : > > Unless a new function we are discussing on the mailing-list is proven u= seful > to me shortly, I'm planning to release a 1.6.0 stable version based on > 1.5.9.=20 After some thoughts, I have a couple more things in favor of "throttling"= : 1/ The supplementary SELECT count(*) we perform against the connect table= =20 before deciding if we will accept or not to add a new entry, which is of = some=20 performance concern to you, is to some extent compensated by the fact tha= t we=20 save an INSERT each time we refuse an entry -- and that makes also a DELE= TE=20 that we save at some point in the future for cleanup. 2/ Throttling can to some extent be considered as "self-dynamic-blacklist= ing",=20 which looks nice : I see some patterns by looking at my logs, showing tha= t=20 the same spam sources (Zombie machines used as SMTP relays ? Viruses /=20 worms ?) tend to come back again and again randomly in time, with differe= nt=20 payloads (sender / recipient). If we use throttling, once they've filled = up=20 their not-retried "quota" in connect, when they come back again, their ne= w=20 connection is refused without generating any new entry in connect, which = in=20 turn reduces the chances that they could possibly defeat the greylisting=20 system by trying to resend (at random) a message with a sender/recipient=20 couple already known to the connect table. By limiting the number of connect entries we allow for a given (new) sour= ce,=20 we limit its possibility of passing greylisting by chance. This looks ver= y=20 interesting to me as it can make greylisting yet more efficient. So this throttling in connect gives a number of interesting things, besid= es=20 simply saving entries in connect -- and making impossible a connect-flood= =20 attack, even if the odds that this happens seem remote. The more I think about it, the more it seems to me that it can only make = the=20 system more secure, and certainly not less. And well, anyway, "it doesn't= =20 hurt" ;-) --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E |
|
From: Lionel B. <lio...@bo...> - 2005-06-09 11:30:38
|
Michel Bouissou wrote: >Le Mercredi 08 Juin 2005 19:26, Lionel Bouton a =E9crit : > =20 > >>Unless a new function we are discussing on the mailing-list is proven u= seful >>to me shortly, I'm planning to release a 1.6.0 stable version based on >>1.5.9.=20 >> =20 >> > >After some thoughts, I have a couple more things in favor of "throttling= " : > >1/ The supplementary SELECT count(*) we perform against the connect tabl= e=20 >before deciding if we will accept or not to add a new entry, which is of= some=20 >performance concern to you, is to some extent compensated by the fact th= at we=20 >save an INSERT each time we refuse an entry -- and that makes also a DEL= ETE=20 >that we save at some point in the future for cleanup. > >2/ Throttling can to some extent be considered as "self-dynamic-blacklis= ting",=20 >which looks nice : I see some patterns by looking at my logs, showing th= at=20 >the same spam sources (Zombie machines used as SMTP relays ? Viruses /=20 >worms ?) tend to come back again and again randomly in time, with differ= ent=20 >payloads (sender / recipient). If we use throttling, once they've filled= up=20 >their not-retried "quota" in connect, when they come back again, their n= ew=20 >connection is refused without generating any new entry in connect, which= in=20 >turn reduces the chances that they could possibly defeat the greylisting= =20 >system by trying to resend (at random) a message with a sender/recipient= =20 >couple already known to the connect table. > =20 > Ok. Now I'm convinced we should test it. But 1.4.8 is pretty old now and 1.5.x is quite stable since 1.5.7 so I would like to issue a stable 1.6.0 release shortly. Would it be OK if I release a 1.6.0 without the tarpitting and connect cleanup code and a 1.7.0 with it? Lionel. |
|
From: Michel B. <mi...@bo...> - 2005-06-09 11:38:27
|
Le Jeudi 09 Juin 2005 13:31, Lionel Bouton a =E9crit : > > Ok. Now I'm convinced we should test it. But 1.4.8 is pretty old now an= d > 1.5.x is quite stable since 1.5.7 so I would like to issue a stable > 1.6.0 release shortly. Would it be OK if I release a 1.6.0 without the > tarpitting and connect cleanup code and a 1.7.0 with it? You're the boss, so it's up to you ;-) I however believe that the tarpitting and connect cleanup code doesn't=20 introduce any stability or performance problem, and now sqlgrey-logstats.= pl=20 has its own patch for taking tarpitting into account as well. If you're in a real hurry of releasing 1.6.0 within 24 hours ;-) maybe yo= u'd=20 better leave all this code out although ; but if you can afford testing i= t=20 for a couple of days before deciding whether to include it in 1.6.0 or no= t,=20 it could be nice ;-)) Cheers. --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E |
|
From: Paolo A. <and...@ap...> - 2005-06-08 19:31:46
|
On Wed, 8 Jun 2005, Lionel Bouton wrote:
>> Thanks for replay.
>> The daemon dead. So mail are refused and users ... ;-)
>>
>
> I assume the daemon dies at the time you get the Syslog.pm error. I'm
Yes.
> betting on a pure Perl problem. Which version of Net::Server::Multiplex
> do you have ?
I think it is 0.87.
I have forced reinstall via CPAN.
Also reinstalled DBD::SQLite (1.08)
But for what I know none have updated it in last days (neither last weeks)
>> I have Verbose = 1. Can increase to 2/3/... or is a on/off parameter?
>> No more info from postfix.
>
> You can comment "verbose = 1" and uncomment "debug" in sqlgrey.conf.
TEsting in progress. At the moment no new useful data in logs (or I don't
see it because I don't know what serach ... ;-))) )
--
Regards,
Paolo
____________________________________________
|
Thanks for helping keep SourceForge clean.
X