Menu
▾
▴
sqlgrey-users
|
From: Dan F. <da...@ha...> - 2014-07-18 07:12:34
|
On 2014-07-18T00:30:38 CEST, Alex wrote: > Then, about seven minutes into my testing, sqlgrey quit and died on > all three systems: > > Jul 17 18:02:22 mail02 sqlgrey: fatal: setconfig error at > /usr/sbin/sqlgrey line 195. > Jul 17 18:02:36 mail03 sqlgrey: fatal: setconfig error at > /usr/sbin/sqlgrey line 195. > Jul 17 18:03:03 mail01 sqlgrey: fatal: setconfig error at > /usr/sbin/sqlgrey line 195. > So this is very interesting and useful log information. Thats a bug, right there.. I think i know what this is. Ill make a patch and get back to you. > > In this case 100s. > > I still have mine set for 1s, but I'd like an "indefinite" option for No you have your "sqlgrey -> mysql" timeout at 1s. This value is for "postfix -> sqlgrey". > I don't know if my 7m test hit some magic limit or something else I think its the db-cleanup that tries to run. It saves a timestamp to the db and apparently that action isn't fault tolerant. > So how do we explain it continuing beyond 100s when you've explicitly > defined the timeout period to be 100s? Because the defined timeout period is for Postfix. It tells postfix how long it will wait for a policy-daemon (like sqlgrey). "tester.pl" isnt using Postfix, it is connecting to sqlgrey directly and postfix timeout value is not in play at all. This just means, that if it was Postfix that had made the connection to sqlgrey (and not tester.pl), it would have given up after 100 seconds and displayed "Server configuration problem". |
|
From: Alex <mys...@gm...> - 2014-07-22 00:41:49
|
Hi, On Fri, Jul 18, 2014 at 3:12 AM, Dan Faerch <da...@ha...> wrote: > > On 2014-07-18T00:30:38 CEST, Alex wrote: > > Then, about seven minutes into my testing, sqlgrey quit and died on > > all three systems: > > > > Jul 17 18:02:22 mail02 sqlgrey: fatal: setconfig error at > > /usr/sbin/sqlgrey line 195. > > Jul 17 18:02:36 mail03 sqlgrey: fatal: setconfig error at > > /usr/sbin/sqlgrey line 195. > > Jul 17 18:03:03 mail01 sqlgrey: fatal: setconfig error at > > /usr/sbin/sqlgrey line 195. > > > > So this is very interesting and useful log information. Thats a bug, > right there.. I think i know what this is. Ill make a patch and get > back to you. Thanks very much. I've applied the patch. I'll be watching it over the next few days, and hope to be doing some more testing with the changes soon. > > > In this case 100s. > > > > I still have mine set for 1s, but I'd like an "indefinite" option for > No you have your "sqlgrey -> mysql" timeout at 1s. This value is for > "postfix -> sqlgrey". I must have been very tired and not thinking clearly. Appreciate your help. Thanks, Alex |
|
From: Alex <mys...@gm...> - 2014-07-22 22:16:59
|
Hi, On Mon, Jul 21, 2014 at 8:41 PM, Alex <mys...@gm...> wrote: > Hi, > > > On Fri, Jul 18, 2014 at 3:12 AM, Dan Faerch <da...@ha...> wrote: > > > > On 2014-07-18T00:30:38 CEST, Alex wrote: > > > Then, about seven minutes into my testing, sqlgrey quit and died on > > > all three systems: > > > > > > Jul 17 18:02:22 mail02 sqlgrey: fatal: setconfig error at > > > /usr/sbin/sqlgrey line 195. > > > Jul 17 18:02:36 mail03 sqlgrey: fatal: setconfig error at > > > /usr/sbin/sqlgrey line 195. > > > Jul 17 18:03:03 mail01 sqlgrey: fatal: setconfig error at > > > /usr/sbin/sqlgrey line 195. > > > > > > > So this is very interesting and useful log information. Thats a bug, > > right there.. I think i know what this is. Ill make a patch and get > > back to you. > > Thanks very much. I've applied the patch. I'll be watching it over the > next few days, and hope to be doing some more testing with the changes soon. > Found out today when the link between mail02 (the db server) and mail03 was broken that the patch is not fixing the problem. Did you test this locally before? Thanks, Alex |
|
From: Alex <mys...@gm...> - 2014-07-22 22:22:59
|
Hi, On Tue, Jul 22, 2014 at 6:16 PM, Alex <mys...@gm...> wrote: > Hi, > > On Mon, Jul 21, 2014 at 8:41 PM, Alex <mys...@gm...> wrote: > >> Hi, >> >> >> On Fri, Jul 18, 2014 at 3:12 AM, Dan Faerch <da...@ha...> wrote: >> > >> > On 2014-07-18T00:30:38 CEST, Alex wrote: >> > > Then, about seven minutes into my testing, sqlgrey quit and died on >> > > all three systems: >> > > >> > > Jul 17 18:02:22 mail02 sqlgrey: fatal: setconfig error at >> > > /usr/sbin/sqlgrey line 195. >> > > Jul 17 18:02:36 mail03 sqlgrey: fatal: setconfig error at >> > > /usr/sbin/sqlgrey line 195. >> > > Jul 17 18:03:03 mail01 sqlgrey: fatal: setconfig error at >> > > /usr/sbin/sqlgrey line 195. >> > > >> > >> > So this is very interesting and useful log information. Thats a bug, >> > right there.. I think i know what this is. Ill make a patch and get >> > back to you. >> >> Thanks very much. I've applied the patch. I'll be watching it over the >> next few days, and hope to be doing some more testing with the changes soon. >> > > Found out today when the link between mail02 (the db server) and mail03 > was broken that the patch is not fixing the problem. Did you test this > locally before? > I may have made a mistake. Would you confirm for me that this change is made in the setconfig() function? The version I have has a few patches from fedora, and this may have affected my patch. Thanks, Alex |
|
From: <da...@ha...> - 2014-07-23 10:16:25
|
On 2014-07-23 00:22, Alex wrote: > I may have made a mistake. Would you confirm for me that this change > is made in the setconfig() function? The version I have has a few > patches from fedora, and this may have affected my patch. All i did was add this line in the setconfig() function: return undef if $param ne 'version'; # Only die for 'version' It was added on the line, right above the line starting with "$self->mydie". |
|
From: Bruce B. <bb...@bo...> - 2014-08-07 01:01:58
|
Good day, I would like to temporarily disable sqlgrey. Would adding * and *.* to client_fqdn_whitelist.local achieve this goal? Is there a better way to TEMPORARILY disable greylisting? Thank you in advance. ~Bruce |
|
From: Karl O. P. <ko...@me...> - 2014-08-07 02:02:15
|
On 08/06/2014 07:42:20 PM, Bruce Bodger wrote:
> Good day,
>
> I would like to temporarily disable sqlgrey. Would adding * and *.*
> to client_fqdn_whitelist.local achieve this goal? Is there a better
> way to TEMPORARILY disable greylisting?
Turn off the stuff added to check_policy_filter in
/etc/postfix/main.cf. Comment it out and do
a "postfix reload".
Karl <ko...@me...>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
|
|
From: Bruce B. <bb...@bo...> - 2014-08-07 19:29:57
|
Thanks, Dan. I presume making changes to sqlgrey.conf would require a restart to take effect? Bruce On Aug 7, 2014, at 3:30 AM, da...@ha... wrote: > On 2014-08-07 04:02, Karl O. Pinc wrote: >> On 08/06/2014 07:42:20 PM, Bruce Bodger wrote: >>> Good day, >>> >>> I would like to temporarily disable sqlgrey. Would adding * and *.* >>> to client_fqdn_whitelist.local achieve this goal? Is there a better >>> way to TEMPORARILY disable greylisting? >> Turn off the stuff added to check_policy_filter in >> /etc/postfix/main.cf. Comment it out and do >> a "postfix reload". >> > I've usually set: > reject_code = dunno > > in sqlgrey.conf when testing code changes in sqlgrey. This is like > running in a "simulation mode", where everything works as normal, except > you just let all the mail through anyway. > I guess it depends on why you need to disable it. > > > > - Dan > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > Sqlgrey-users mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlgrey-users > |
|
From: <da...@ha...> - 2014-08-07 19:43:14
|
Yes, a restart of sqlgrey only though. Not postfix or anything else. You can do it like: $ sqlgrey -k; sqlgrey -d its very fast. - Dan On 2014-08-07 21:29, Bruce Bodger wrote: > Thanks, Dan. I presume making changes to sqlgrey.conf would require a restart to take effect? > > Bruce > > > On Aug 7, 2014, at 3:30 AM, da...@ha... wrote: > >> On 2014-08-07 04:02, Karl O. Pinc wrote: >>> On 08/06/2014 07:42:20 PM, Bruce Bodger wrote: >>>> Good day, >>>> >>>> I would like to temporarily disable sqlgrey. Would adding * and *.* >>>> to client_fqdn_whitelist.local achieve this goal? Is there a better >>>> way to TEMPORARILY disable greylisting? >>> Turn off the stuff added to check_policy_filter in >>> /etc/postfix/main.cf. Comment it out and do >>> a "postfix reload". >>> >> I've usually set: >> reject_code = dunno >> >> in sqlgrey.conf when testing code changes in sqlgrey. This is like >> running in a "simulation mode", where everything works as normal, except >> you just let all the mail through anyway. >> I guess it depends on why you need to disable it. >> >> >> >> - Dan >> >> ------------------------------------------------------------------------------ >> Infragistics Professional >> Build stunning WinForms apps today! >> Reboot your WinForms applications with our WinForms controls. >> Build a bridge from your legacy apps to the future. >> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >> _______________________________________________ >> Sqlgrey-users mailing list >> Sql...@li... >> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users >> > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > Sqlgrey-users mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlgrey-users |
|
From: Bruce B. <bb...@bo...> - 2014-08-08 18:13:49
|
Thanks again, Dan. I ended up taking Karl's recommendation by removing the call in postfix's main.cf and sending it a 'reload'. Starting and stopping sqlgrey on OS X is a bit more than just executing 'sqlgrey -k; sqlgrey -d' :-) Also, according to the comments in sqlgrey.conf, the reject code is "only used if reject_first_attempt/reject_early_reconnect = immed", the default being 'delay'. Again, thanks to you both. Regards, Bruce On Aug 7, 2014, at 2:43 PM, da...@ha... wrote: > Yes, a restart of sqlgrey only though. Not postfix or anything else. > You can do it like: > $ sqlgrey -k; sqlgrey -d > > its very fast. > > > - Dan > > On 2014-08-07 21:29, Bruce Bodger wrote: >> Thanks, Dan. I presume making changes to sqlgrey.conf would require a restart to take effect? >> >> Bruce >> >> >> On Aug 7, 2014, at 3:30 AM, da...@ha... wrote: >> >>> On 2014-08-07 04:02, Karl O. Pinc wrote: >>>> On 08/06/2014 07:42:20 PM, Bruce Bodger wrote: >>>>> Good day, >>>>> >>>>> I would like to temporarily disable sqlgrey. Would adding * and *.* >>>>> to client_fqdn_whitelist.local achieve this goal? Is there a better >>>>> way to TEMPORARILY disable greylisting? >>>> Turn off the stuff added to check_policy_filter in >>>> /etc/postfix/main.cf. Comment it out and do >>>> a "postfix reload". >>>> >>> I've usually set: >>> reject_code = dunno >>> >>> in sqlgrey.conf when testing code changes in sqlgrey. This is like >>> running in a "simulation mode", where everything works as normal, except >>> you just let all the mail through anyway. >>> I guess it depends on why you need to disable it. >>> >>> >>> >>> - Dan >>> >>> ------------------------------------------------------------------------------ >>> Infragistics Professional >>> Build stunning WinForms apps today! >>> Reboot your WinForms applications with our WinForms controls. >>> Build a bridge from your legacy apps to the future. >>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Sqlgrey-users mailing list >>> Sql...@li... >>> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users >>> >> >> >> ------------------------------------------------------------------------------ >> Infragistics Professional >> Build stunning WinForms apps today! >> Reboot your WinForms applications with our WinForms controls. >> Build a bridge from your legacy apps to the future. >> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >> _______________________________________________ >> Sqlgrey-users mailing list >> Sql...@li... >> https://lists.sourceforge.net/lists/listinfo/sqlgrey-users > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > Sqlgrey-users mailing list > Sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlgrey-users > |
|
From: <da...@ha...> - 2014-08-07 08:30:42
|
On 2014-08-07 04:02, Karl O. Pinc wrote: > On 08/06/2014 07:42:20 PM, Bruce Bodger wrote: >> Good day, >> >> I would like to temporarily disable sqlgrey. Would adding * and *.* >> to client_fqdn_whitelist.local achieve this goal? Is there a better >> way to TEMPORARILY disable greylisting? > Turn off the stuff added to check_policy_filter in > /etc/postfix/main.cf. Comment it out and do > a "postfix reload". > I've usually set: reject_code = dunno in sqlgrey.conf when testing code changes in sqlgrey. This is like running in a "simulation mode", where everything works as normal, except you just let all the mail through anyway. I guess it depends on why you need to disable it. - Dan |
|
From: Alex <mys...@gm...> - 2014-07-10 17:45:54
|
Hi, On Sun, Jul 6, 2014 at 7:07 AM, Dan Faerch <da...@ha...> wrote: > > > It's only based on the fact that there is no stalling or any delays here > > - it happens immediately when sqlgrey isn't running at all. > > You are now talking about how Postfix reacts to a missing policy-daemon > (sqlgrey is a postfix policy-daemon). > As this is not something I or sqlgrey can influence, this is not what im > talking about at all. > > I am ONLY talking about the issue you specified in your original mail, > which was (slightly summarized): > - You had "..configured using the DBCLUSTER.." > - and when "..one machine goes down, all three fail.." > - with error "..4.3.5 Server configuration problem.." > > And as such, i believe the issue was a mysql connection attempt that took > too long. This is now solved by setting timeout to 1 second. Okay, I didn't understand that the inability to reach mysql because the server was down would be considered a timeout. I was also thinking about the more general case and wasn't explaining myself very well. While I'm concerned about sqlgrey itself dying (and now understand it's a misplaced concern), I wanted to be sure a complete loss of the server itself was also solved with the mysql timeout parameter you've mentioned. I now only wish there was a way for postfix to fail silently and pass the mail on, instead of returning any error, temporary or not, to the user. I have a lot to read an re-read (especially about mysql replication). Very much appreciate your help. Thanks again for everything. Alex |
×
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