Matt Simerson wrote: > > <snipped from the Vpopmail FAQ> > > Then, every time someone pops in and authenticates, the follow happens: > > 1) vpopmail asks for an exclusive lock on the > ~vpopmail/etc/open-smtp.lock file > 2) it will wait for the lock, once it gets it, it will continue > 3) it adds the pop users IP into ~vpopmail/etc/open-smtp file with a > > time stamp. If the IP already exsists, it updates the timestamp. > 4) it runs tcprules to regenerate the /etc/tcp.smtp.cdb file > 5) releases lock and new IP becomes available to the next > smtp invocation. > > At this point, the smtp server configured above will allow that > IP to relay for 1 hour (default). > > You should setup cron to run the following: > 40 * * * * /home/vpopmail/bin/clearopensmtp > Change /home/vpopmail to be your vpopmails home dir. > > clearopenstmp will ask for a lock, clear out any roaming IP's > whos timestamps are over 1 hour old since last pop authentication. > merges the two files vpopmail does above and run tcprules. > Thus closing off relay for those aged IPs. > > I think it's pretty cool :) > > OK, based on this information I compiled Vpopmail with the > --enable-roaming-users=y. The /etc/tcp.smtp file does not exist but the > ~vpopmail/etc/tcp.smtp file does so the configuration script automatically > selects the ~vpopmail/etc default location for the tcp.smtp and open-smtp > files. Now, this is where it gets a little messy. The ~vpopmail directory is > /usr/home/vpopmail. I have one file server and four mail servers. Each mail > server mounts it's /usr/home off the file server so all four mail servers > share the same ~vpopmail/etc/open-smtp and ~vpopmail/etc/tcp.smtp files. > > The smtp invocation of tcpserver uses the -x ~vpopmail/etc/tcp.smtp > parameter to allow users who've pop or imap authenticated to send mail. It > works! In fact, it works pretty good and has been working, until recently > when a problem has surfaced and one that I believe is related to server > load. I think that the file locking code that checks for the file lock on > the open-smtp file is not actually honoring the lock file. If I sit and > watch the open-smtp file, it'll start growing away (as expected) and then > suddenly shrink back to nothing, and start growing again. I turned off the > clearopensmtp cron job and the behavior continued. > > So, my theory is that now that my server is finally getting a decent amount > of traffic, whenever two auth requests come in at the same time, one is > reading in the file while it's still being written. I can't think of any > other reason the file would shrink. The last clue is that the open-smtp.lock > file gets created but it's date timestamp never changes. In fact, it's mod > date hasn't been updated since October. If I delete the file, another will > appear but it's timestamp remains the same as it's creation date. > > Anyone encountered this? Anyone have a solution? > > Matt > > This has seemed to work quite well for me until lately. We'll get into why > here shortly. It is critical that the times on all the machines are synchronized for NFS to work correctly. Install and run ntp on all the machines. Ken Joens
