Menu
▾
▴
sqlgrey-users
|
From: Steve H. <st...@th...> - 2005-09-27 11:51:23
|
We have successfully setup sqlgrey on one of our incoming mail servers. We now need to do the same for our other server. We accept mail for ~250 domains. For most of these the two servers are equal MX priority, so they load share and provide backup for each other. When setting up sqlgrey on the second server should we create a new Postgres database or have them share the existing one? We thought that sharing would be the best option, but dont know if this will work. Thanks Steve -- thorNET Internet Services, Consultancy & Training www.thornet.co.uk |
|
From: Lionel B. <lio...@bo...> - 2005-09-27 12:06:52
|
Steve Heaven wrote the following on 27.09.2005 13:51 : > > We have successfully setup sqlgrey on one of our incoming mail servers. Yes, saw you on postfix-users :-) > We now need to do the same for our other server. > We accept mail for ~250 domains. For most of these the two servers are > equal MX priority, so they load share and provide backup for each other. > > When setting up sqlgrey on the second server should we create a new > Postgres database or have them share the existing one? > > We thought that sharing would be the best option, but dont know if > this will work. > Sharing the database is the way to go. It was designed to work this way (using several databases would only make the greylisting process slower: the messages could be greylisted more than once). Be sure to use SQLgrey 1.6.6 (there was a rare race condition in the earliest 1.6.x releases in multiple SQLgrey instances cases). Lionel. |
|
From: Steve H. <st...@th...> - 2005-09-27 12:19:17
|
On Tue, 2005-09-27 at 13:06, Lionel Bouton wrote: > Sharing the database is the way to go. We thought that was best. We have already seen connections greylisted on smtp1 and then being retried on smtp2 (which currently isnt running sqlgrey), so without shared access to the db this would start another 5 mins wait. > Be sure to use SQLgrey 1.6.6 Were running 1.7.1 -- thorNET Internet Services, Consultancy & Training www.thornet.co.uk |
|
From: Lionel B. <lio...@bo...> - 2005-09-27 12:30:00
|
Steve Heaven wrote the following on 27.09.2005 14:19 : > On Tue, 2005-09-27 at 13:06, Lionel Bouton wrote: > >>/Sharing the database is the way to go. / >> > We thought that was best. > We have already seen connections greylisted on smtp1 and then being > retried on smtp2 (which currently isnt running sqlgrey), so without > shared access to the db this would start another 5 mins wait. > >>/ Be sure to use SQLgrey 1.6.6/ >> > Were running 1.7.1 Less tested development branch. There's at least a cosmetic bug in it. Lionel |
|
From: Who K. <qui...@me...> - 2005-09-27 13:04:24
|
Steve Heaven wrote: > > We have successfully setup sqlgrey on one of our incoming mail > servers. We now need to do the same for our other server. > We accept mail for ~250 domains. For most of these the two servers are > equal MX priority, so they load share and provide backup for each other. > > When setting up sqlgrey on the second server should we create a new > Postgres database or have them share the existing one? > > We thought that sharing would be the best option, but dont know if > this will work. > > Thanks > > Steve > > >-- >thorNET >Internet Services, Consultancy & Training >www.thornet.co.uk > This is not a recommendation, but rather a comment based on my experience. While I beleive that it would be best to have both servers access the same sqlgrey, as I initially configured my 3 mail servers, I have subsequently reconfigured them to use their own due to a production issue. Recently my main mail server had a problem which in turn caused the sqlgrey database it served to also become unavailable, and allthough the two other mailservers should have picked up the mail handling duties they failed to accept any inbound mail returning soft error 450 due to their inability to access the sqlgrey database. Regards, Jim |
|
From: Lionel B. <lio...@bo...> - 2005-09-27 13:23:21
|
Who Knows wrote the following on 27.09.2005 15:03 : > Steve Heaven wrote: > >> >> We have successfully setup sqlgrey on one of our incoming mail >> servers. We now need to do the same for our other server. >> We accept mail for ~250 domains. For most of these the two servers >> are equal MX priority, so they load share and provide backup for each >> other. >> >> When setting up sqlgrey on the second server should we create a new >> Postgres database or have them share the existing one? >> >> We thought that sharing would be the best option, but dont know if >> this will work. >> >> Thanks >> >> Steve >> >> >> -- >> thorNET >> Internet Services, Consultancy & Training >> www.thornet.co.uk >> > This is not a recommendation, but rather a comment based on my > experience. While I beleive that it would be best to have both servers > access the same sqlgrey, as I initially configured my 3 mail servers, > I have subsequently reconfigured them to use their own due to a > production issue. > > Recently my main mail server had a problem which in turn caused the > sqlgrey database it served to also become unavailable, and allthough > the two other mailservers should have picked up the mail handling > duties they failed to accept any inbound mail returning soft error 450 > due to their inability to access the sqlgrey database. > Just to clarify: If you have one SQLgrey sitting on each server running a MX server and all of them configured to use the same database you don't have any single point of failure. If one MX fails, the other(s) handle the trafic. If the database server fails, all SQLgrey processes switch to passthrough automatically (and warn the email address configured in sqlgrey.conf) -> your MX are unaffected but the greylisting stops. If you have one single SQLgrey process and the server it is sitting on fails, all "incoming" mail trafic stops (Postfix answers requests with "service temporary unavailable" errors). Lionel. |
|
From: Who K. <qui...@me...> - 2005-09-27 15:34:11
|
Lionel Bouton wrote: > > Just to clarify: > > If you have one SQLgrey sitting on each server running a MX server and > all of them configured to use the same database you don't have any > single point of failure. > If one MX fails, the other(s) handle the trafic. If the database > server fails, all SQLgrey processes switch to passthrough > automatically (and warn the email address configured in sqlgrey.conf) > -> your MX are unaffected but the greylisting stops. > If you have one single SQLgrey process and the server it is sitting on > fails, all "incoming" mail trafic stops (Postfix answers requests with > "service temporary unavailable" errors). > > Lionel. Okay, I was aware that was what was supposed to happen. Is the switch to passthru in the abscense of a database ( or database error ) a config setting because according to my logs my MTAs returned config error when the database was inacessable. |
|
From: Lionel B. <lio...@bo...> - 2005-09-27 15:58:55
|
Who Knows wrote the following on 27.09.2005 17:33 : > Lionel Bouton wrote: > >> >> Just to clarify: >> >> If you have one SQLgrey sitting on each server running a MX server >> and all of them configured to use the same database you don't have >> any single point of failure. >> If one MX fails, the other(s) handle the trafic. If the database >> server fails, all SQLgrey processes switch to passthrough >> automatically (and warn the email address configured in sqlgrey.conf) >> -> your MX are unaffected but the greylisting stops. >> If you have one single SQLgrey process and the server it is sitting >> on fails, all "incoming" mail trafic stops (Postfix answers requests >> with "service temporary unavailable" errors). >> >> Lionel. > > > Okay, I was aware that was what was supposed to happen. Is the switch > to passthru in the abscense of a database ( or database error ) a > config setting because according to my logs my MTAs returned config > error when the database was inacessable. No it is automatic. It is designed to recover from both an unreachable database and simple query errors (no answer or clearly invalid answers). Do you rely on the database for anything else than SQLgrey? Was SQLgrey running on the same systems the MTAs were on (ie policy_service declared as localhost:<something> on each MTA)? Lionel. |
|
From: Who K. <qui...@me...> - 2005-09-28 01:18:15
|
Lionel Bouton wrote: > No it is automatic. It is designed to recover from both an unreachable > database and simple query errors (no answer or clearly invalid answers). > Do you rely on the database for anything else than SQLgrey? Was > SQLgrey running on the same systems the MTAs were on (ie > policy_service declared as localhost:<something> on each MTA)? > My old configuration was sqlgrey v1.6.6-1 serverX local MTA - postfix local sqlgrey localhost sqlgraydb serverY local MTA - postfix local sqlgrey remote DB serverX sqlgraydb serverZ local MTA - postfix local sqlgrey serverX sqlgraydb Here is an exerpt of what was happened for all messages arriving at serverY after serverX swooned: NOTE: the ****** are to protect the guilty(or innocent) Sep 21 07:51:00 serverY postfix/smtpd[3184]: connect from ablist.about.com[207.241.145.4] Sep 21 07:51:03 serverY sqlgrey: dbaccess: can't connect to DB: Can't connect to MySQL server on 'serverX.*******'' (110) Sep 21 07:51:03 serverY sqlgrey: dbaccess: warning: couldn't do query: DELETE FROM from_awl WHERE last_seen < timestamp '2005-09-20 21:35:36' - INTERVAL 60 DAY: Can't connect to MySQL server on 'serverX.*******'' (110), reconnecting to DB Sep 21 07:51:03 serverY sqlgrey: warning: Use of uninitialized value in string eq at /usr/sbin/sqlgrey line 1191. Sep 21 07:51:11 serverY postfix/smtpd[3240]: timeout after RSET from unknown[80.232.117.10] Sep 21 07:51:11 serverY postfix/smtpd[3240]: disconnect from unknown[80.232.117.10] Sep 21 07:51:11 serverY postfix/smtpd[3130]: timeout after RSET from unknown[80.232.117.10] Sep 21 07:51:11 serverY postfix/smtpd[3130]: disconnect from unknown[80.232.117.10] Sep 21 07:51:17 serverY postfix/smtpd[3265]: connect from mail3.inbox360.com[207.106.213.11] Sep 21 07:51:24 serverY postfix/smtpd[3270]: warning: timeout on 127.0.0.1:2501 while reading input attribute name Sep 21 07:51:24 serverY postfix/smtpd[3270]: warning: problem talking to server 127.0.0.1:2501: Connection timed out Sep 21 07:51:24 serverY postfix/smtpd[3270]: NOQUEUE: reject: RCPT from smtp02.infoave.net[165.166.0.27]: 450 Server configuration problem; from=<mdf...@lo...> to=<webmaster@**********> proto=ESMTP helo=<SMTP02.INFOAVE.NET> |
|
From: Lionel B. <lio...@bo...> - 2005-09-28 18:36:23
|
Who Knows wrote the following on 28.09.2005 03:18 : > Lionel Bouton wrote: > >> No it is automatic. It is designed to recover from both an >> unreachable database and simple query errors (no answer or clearly >> invalid answers). >> Do you rely on the database for anything else than SQLgrey? Was >> SQLgrey running on the same systems the MTAs were on (ie >> policy_service declared as localhost:<something> on each MTA)? >> > My old configuration was sqlgrey v1.6.6-1 > > serverX > local MTA - postfix > local sqlgrey localhost sqlgraydb > > serverY > local MTA - postfix > local sqlgrey remote DB serverX sqlgraydb > > serverZ > local MTA - postfix > local sqlgrey serverX sqlgraydb > > Here is an exerpt of what was happened for all messages arriving at > serverY after serverX swooned: > NOTE: the ****** are to protect the guilty(or innocent) > > Sep 21 07:51:00 serverY postfix/smtpd[3184]: connect from > ablist.about.com[207.241.145.4] > Sep 21 07:51:03 serverY sqlgrey: dbaccess: can't connect to DB: Can't > connect to MySQL server on 'serverX.*******'' (110) > Sep 21 07:51:03 serverY sqlgrey: dbaccess: warning: couldn't do query: > DELETE FROM from_awl WHERE last_seen < timestamp '2005-09-20 21:35:36' > - INTERVAL 60 DAY: Can't connect to MySQL server on 'serverX.*******'' > (110), reconnecting to DB > Sep 21 07:51:03 serverY sqlgrey: warning: Use of uninitialized value > in string eq at /usr/sbin/sqlgrey line 1191. This odd-looking warning, I can deal with. It may be why some messages were rejected but unless SQLgrey died I believe it shouldn't have rejected every message but only a few ones (I'll have to check the flow of SQL queries to be sure that there's no loophole introduced by a recent change, but last time I did it was OK). > > Sep 21 07:51:11 serverY postfix/smtpd[3240]: timeout after RSET from > unknown[80.232.117.10] > Sep 21 07:51:11 serverY postfix/smtpd[3240]: disconnect from > unknown[80.232.117.10] > Sep 21 07:51:11 serverY postfix/smtpd[3130]: timeout after RSET from > unknown[80.232.117.10] > Sep 21 07:51:11 serverY postfix/smtpd[3130]: disconnect from > unknown[80.232.117.10] > Sep 21 07:51:17 serverY postfix/smtpd[3265]: connect from > mail3.inbox360.com[207.106.213.11] > Sep 21 07:51:24 serverY postfix/smtpd[3270]: warning: timeout on > 127.0.0.1:2501 while reading input attribute name > Sep 21 07:51:24 serverY postfix/smtpd[3270]: warning: problem talking > to server 127.0.0.1:2501: Connection timed out > Sep 21 07:51:24 serverY postfix/smtpd[3270]: NOQUEUE: reject: RCPT > from smtp02.infoave.net[165.166.0.27]: 450 Server configuration > problem; from=<mdf...@lo...> to=<webmaster@**********> > proto=ESMTP helo=<SMTP02.INFOAVE.NET> > > So several messages like this were rejected. If I understand correctly SQLgrey recovered when the database came back. Did some messages get through while the database was down or each and every message were tempfailed ? Lionel |
|
From: Who K. <qui...@me...> - 2005-09-29 05:32:37
|
Lionel Bouton wrote: > So several messages like this were rejected. If I understand correctly > SQLgrey recovered when the database came back. Did some messages get > through while the database was down or each and every message were > tempfailed ? > > Lionel to the best of my knowledge all inbound messages were rejected with 450 until the sql server was restored to service. |
|
From: Lionel B. <lio...@bo...> - 2005-10-23 23:47:24
|
Who Knows wrote the following on 29.09.2005 04:46 : > Lionel Bouton wrote: > >> So several messages like this were rejected. If I understand >> correctly SQLgrey recovered when the database came back. Did some >> messages get through while the database was down or each and every >> message were tempfailed ? >> >> Lionel > > > to the best of my knowledge all inbound messages were rejected with > 450 until the sql server was restored to service. > I reviewed the whole 1.6.x code looking for a case where it could reject the message when the DB is not reachable and found none obvious. I just uploaded 1.6.7 which fixes the odd log errors you witnessed. There is a remote possibility that they were linked to the rejects you witnessed (I'm not sure how Perl handles the undefined variables, the calling methods could abort at mid-processing which *could* explain messages being rejected). Lionel. |
|
From: Steve H. <st...@th...> - 2005-09-27 13:22:14
|
Trying to setup the second server like the first but we get this: Sep 27 14:18:43 balder1 sqlgrey: Process Backgrounded Sep 27 14:18:43 balder1 sqlgrey: 2005/09/27-14:18:43 sqlgrey (type Net::Server::Multiplex) starting! pid(18324) Sep 27 14:18:43 balder1 sqlgrey: Binding to TCP port 2501 on host localhost Sep 27 14:18:43 balder1 sqlgrey: Setting gid to "522 522" Sep 27 14:18:43 balder1 sqlgrey: 2005/09/27-14:18:43 Couldn't become gid "522": at line 486 in file /usr/lib/perl5/site_perl/5.8.0/Net/Server.pm Sep 27 14:18:43 balder1 sqlgrey: 2005/09/27-14:18:43 Server closing! # grep sqlgrey /etc/group /etc/passwd /etc/group:sqlgrey:x:522: /etc/passwd:sqlgrey:x:522:522::/home/sqlgrey:/bin/false |
|
From: Michael S. <Mic...@lr...> - 2005-09-27 15:03:25
|
On Tue, 27 Sep 2005, Steve Heaven wrote: > Trying to setup the second server like the first but we get this: > > Sep 27 14:18:43 balder1 sqlgrey: Process Backgrounded > Sep 27 14:18:43 balder1 sqlgrey: 2005/09/27-14:18:43 sqlgrey (type > Net::Server::Multiplex) starting! pid(18324) > Sep 27 14:18:43 balder1 sqlgrey: Binding to TCP port 2501 on host > localhost > Sep 27 14:18:43 balder1 sqlgrey: Setting gid to "522 522" > Sep 27 14:18:43 balder1 sqlgrey: 2005/09/27-14:18:43 Couldn't become gid > "522": at line 486 in file > /usr/lib/perl5/site_perl/5.8.0/Net/Server.pm > Sep 27 14:18:43 balder1 sqlgrey: 2005/09/27-14:18:43 Server closing! If you have Net::Server 0.88 then this seems to be the problem. 0.88 in some cases does not work together with perl 5.8.0, as they said on the amavisd-new list. In this case either downgrade to 0.87, see http://marc.theaimsgroup.com/?l=amavis-user&m=111999829830183&w=2 or upgrade to a new perl version (which may create an entirely new can of worms). Michael Storz ------------------------------------------------- Leibniz-Rechenzentrum ! <mailto:St...@lr...> Barer Str. 21 ! Fax: +49 89 2809460 80333 Muenchen, Germany ! Tel: +49 89 289-28840 |
|
From: Lionel B. <lio...@bo...> - 2005-09-27 13:30:23
|
Steve Heaven wrote the following on 27.09.2005 15:22 : > Trying to setup the second server like the first but we get this: > > Sep 27 14:18:43 balder1 sqlgrey: Process Backgrounded > Sep 27 14:18:43 balder1 sqlgrey: 2005/09/27-14:18:43 sqlgrey (type > Net::Server::Multiplex) starting! pid(18324) > Sep 27 14:18:43 balder1 sqlgrey: Binding to TCP port 2501 on host > localhost > Sep 27 14:18:43 balder1 sqlgrey: Setting gid to "522 522" > Sep 27 14:18:43 balder1 sqlgrey: 2005/09/27-14:18:43 Couldn't become > gid "522": at line 486 in file > /usr/lib/perl5/site_perl/5.8.0/Net/Server.pm > Sep 27 14:18:43 balder1 sqlgrey: 2005/09/27-14:18:43 Server closing! > > > # grep sqlgrey /etc/group /etc/passwd > /etc/group:sqlgrey:x:522: > /etc/passwd:sqlgrey:x:522:522::/home/sqlgrey:/bin/false Which user do you use to start SQLgrey? init scripts usually suppose you are root. |
|
From: Steve H. <st...@th...> - 2005-09-27 13:36:05
|
On Tue, 2005-09-27 at 14:30, Lionel Bouton wrote: > > Which user do you use to start SQLgrey? init scripts usually suppose you > are root. > > Yes, we're running the init script by hand as root -- thorNET Internet Services, Consultancy & Training www.thornet.co.uk |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X