Hello Jeremy, On Tuesday, May 24, 2005 at 10:11:21 PM Jeremy wrote:
>>> vpopmail's roaming-users support is poorly designed, slow, and >>> prone to failure. >> I'd like to see some evidence to back up this assertion. > the fact that it's based around one file (actually, 3) that can theoretically > be attempted to be updated many times simultaneously (requiring locking, etc) > the open-smtp file has to be locked, old entries purged, then the cdb file has > to be locked, and rebuilt. 'open-smtp' has to be locked, yes. But cdb file hasn't. It's rebuild in a temporary file and if build successfully the old one is removed and the new one renamed. In fact vpopmail makes use of 'tcprules' to create cdb file. > with relay-ctrl, it simply creates a file in a directory for each IP allowed, > and checks for old ones that should be removed. > This is NFS safe, requires no locking (who cares if two processes try to > create the same empty file at the same time), and is a lot more > fault-tolerant. And with 10k users adds a lot of "things to do" to find the correct file to the file system, especially if this special directory is located on an ext2 or ext3 partition, which as we all know, does not scale very well if there are a lot of directory entries. > Plus, since the relay-ctrl software is independent of any other qmail process, > no other qmail process needs to know the location of the relay-ctrl > directory, whereas vpopmail's roaming users either requires you to change > where your cdb file is, or tell it specifically where your cdb file is. *oooohhhh* Deleting whatever '-x' points existing tcpserver-processes and replacing it with a symlink really is hard to do ... If one does not want to adjust startup script and edit '-x' parameter directly. > Also.. some people use scripts to generate their tcp.smtp.cdb file, since > tcprules simply generates a cdb file based on stdin. vpopmail's roaming > users breaks this. Where? As far as I've understood vpopmail source it it simply opens 'tcprules' process, passes 'open-smtp' and 'tcp.smtp' contents to STDIN of this process, and that's it. Nothing that looks to me like 'breaking generating a cdb file based on stdin', especially nothing I'd call "prone to fail". Sure, for some 10k users cdb might become slow, when it comes to many necessary cdb file recreations (i.e. many altering IP addresses). But that does not necessarily mean it's slow, poorly designed or "prone to fail" for anybody else with much less users. It's a good, known to work reliable, solution that perfectly integrates into existing tcpserver usage ... -- Best regards Peter Palmreuther Rap is to music what Etch-A-Sketch is to art.