|
From: John H. <joh...@pl...> - 2006-06-27 12:05:54
|
On Tue, 2006-06-27 at 02:17 -0400, pyz...@nr... wrote: > Hi. No, I'm not Frank. Didn't mean to give that impression at all. > Okay, thanks for that. I really couldn't tell so I thought it best to ask :-) > It appears that Frank last posted to this list in september. I just don't > expect Frank to reply right away with "its not dead" every time someone > asks. > Ah, but people will only ask if it is dead because it 'appears' to be dead. I asked because of our timeout problem, and checking the list archives, the bugs etc, it 'appears' that nothing has really happened for some time despite others having problems as well (as reported on the list). The overall impression is of it not being worked on - i.e. dead. > There's simply no code to manage distributed servers. Someone would have to > write it. I suppose that if Frank thought it was a big problem he might have > done it already. I can only speculate based on his posts to the mailing > list. > But there is a feature request on SF for multiple servers dating from 2003/2004, so this idea has been around for 2 years. Using one server to support all of the pyzor requests is surely risky. What if the server fails for good or the owners decide to withdraw their support? Pyzor then would be dead. Using multiple servers surely must be a good thing. (In terms of coding it, it seems that 'pyzor ping' already supports multiple servers, so what is required is for each server to synchronise the local DB from the main server. I wouldn't have thought that actually requires any coding, but just using something like rsync or whatever run regularly via cron. How big is the DB though? Catering for DB updates would require that these are sent to the main server. Perhaps the 'servers' file could simply list each server as either master or slave. DB updates then go to the listed 'master'. Rotating the slave server used each time would be nice too.) > People reporting server problems doesn't necessarily mean there is a server > problem. > Agreed, especially when UDP is used. > I see those posts pop up now and then, but I still see plenty of > spam going into my pyzor folder. I'm not impressed when people report server > problems and don't know or even try to do a traceroute, use other computers, > or internet connections. I don't have handy stats but it seems that I have > less than 2% timeouts or other errors. Probably pretty good for UDP over the > net. > Again I tend to agree. In our case, continuous timeouts, I suspect is a local firewall issue and was my first assumption. However, then going on to check the mailing list archive to see if others have the same problem (and what port to open up), I see they do. Checking the patches to see if there may have already have been some code fix (if it was the code), shows that there have been no patches for a very long time. Overall an impression of not much happening, hence why I initially asked if the project was in fact dead. > That's right there hasn't really been any changes in the software since > 2002, IMO because it is simple and it works. > Yes, but relying on just one server is risky. Multiple servers would help. > There are a few patches that you can get all rolled into one: > Ah, thanks for that I'll take a look at them. > > My recent manual attempts to check pyzor spams seemed to time out but I > checked my spamassassin logs and pyzor doesn't seem to be timing out that > often at all. Maybe it retries. > No it doesn't. Tcpdump shows that just one UDP packet is sent out to each server. > Anywhoo, the major point was that its not dead, it is working, and it's just > really low maintenance. Until we see a deluge of posts about server timeouts > I don't expect to hear from Frank about it. > I don't expect a deluge. How would someone know if the pyzor server was timing out or not? Their spam would probably be filtered by other methods (SARE rules, DCC etc). Only if the sysadmin actually looked, or monitored, the log file would they see that no spam mail is being flagged as hitting a pyzor check (in SA). They would then need to investigate further if there was a problem with pyzor. For these reasons I suspect others may be experiencing a timeout problem but perhaps don't know it. > Even then all it might take is someone to step up and provide another > server, or hack the client code to failover to multiple servers. > True, but why not do it now before using a single server does become a problem, and pyzor stops for everyone? John. -- --------------------------------------------------------------- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: Joh...@pl... Fax: +44 (0)1752 233839 |