Re: [vchkpw] tcp.smtp.cdb is updated only once, and only when open-smtp is missing
Ken, Thanks for your suggestions, but sadly, they didn't help. Your recap was dead-on...I verified the path to tcprules in config.h, and re-verified that I can run tcprules as user vpopmail and update the cdb without a problem. So, I'm still in the market for suggestions, as long as they don't involve learning C, which I'm just not going to have time for this week grin, though I'm going to try a couple of simple commenting out type of tests to see if I can pin down the problem a little bit. Tony Ken Jones [EMAIL PROTECTED] wrote on 9/21/2002 at 2:30 AM: So to recap: - open-smtp is correctly being updated with new pop auth IPs? - tcp.smtp.cdb is not being updated. A few things need to fall in line to make that all happen. And it sounds like you've got at least most of them. I would look at the config.h vpopmail file for: The #ifdef of where the tcprules program lives. make sure it is there :) then make sure the user that the vchkpw program runs as (when a user pops) has permission to run it and update the #ifdef location of where the tcp.smtp.cdb file lives. Run the tcprules program just like vchkpw would, on the command line and see what happens. Check if it updates the tcp.smtp.cdb file. If all this is right then i dunno... If all your email accounts are owned by vpopmail then you might as well run the pop3d tcpserver (and logs) as vpopmail.vchkpw. The alternative (worth trying) is have everything run as root. Ken Jones On Friday 20 September 2002 11:53 am, Tony A.T. Mendina wrote: This is a long story; but, I'd be happy if anyone with the patience to slog through it could offer further troubleshooting suggestions, pointers to docs that I missed, or any other advice they deem helpful grin. My problem is that tcp.smtp.cdb is not being updated when a pop3 user logs in, _unless_ I delete the open-smtp file just before the login. I'm not seeing errors in the logs or leftover temporary files on the disk, and users can log in and check mail successfully. The file open-smtp _is_ being updated each time a user checks mail. Clearopensmtp _does_ run without error from the system crontab, whether I've got the vpopmail system running as root or as vpopmail. I'm trying to use vpopmail with qmail 1.03 and redhat 7.2. My previous (working) qmail+vpopmail installs use vpopmail 5.2.1 just like I'm trying to do now, but this new one is a little different. Instead of running tcpserver directly from my init scripts and using Debian with a 2.2 kernel, I'm running it using supervise and using Redhat with a 2.4. Switching back to debian and cloning is not an option for work policy reasons. The qmail installs themselves are identical; both machines use the current ucspi-tcp, .88. At first, I was first letting the /supervise/qmail-pop3d/run script start tcpserver as root, and the open-smtp file, as well as the cdb file, were owned by root. Tcp.smtp.cdb was in /etc/, and clearopensmtp was run as root. I carefully compared the locations and permissions of executables and data files between a working debian+qmail+vpopmail system and this new redhat one, I and couldn't find any difference. After reading the tales of users with similar problems in the list archives, I saw that most of them had to do with the vpopmail user having access problems with needed files and with /etc. So as an experiment, I switched the whole setup to use the vpopmail user. The cron job for clearopensmtp was changed to run as vpopmail; vpopmail was recompiled to use /var/vchkpw/etc rather than /etc for the tcp rules file, the supervise scripts were changed accordingly, and so on. Users (well, test user accounts) can still log in and check mail without errors being returned to the client software, but just as before, the tcp.smtp.cdb file is _still_ not updated, except every 15 minutes when clearopensmtp runs. Then, as a further experiment, I tried replacing vpopmail 5.2.1 with 5.3.8. I used /var/vchkpw/etc and ran all components as the vpopmail user. No luck. The one exception to the lack of updates is if I delete the file /var/vchkpw/etc/open-smtp. If I do that, tcp.smtp.cdb is updated when the next pop3 user logs in. Open-smtp is recreated, and further pop3 logins don't result in updates to the cdb file, just open-smtp. This is the case whether the cdb file is in /etc and I'm running vpopmail as root or its in /var/vchkpw/etc and I'm running vpopmail as vpopmail. I've also tried running the tcpserver which runs qmail-popup, vchkpw, and qmail-pop3d from the command line as root and both with and without the -u 89 -g 89 parameters; I get the same problem as always, every time. In case this long and unhappy story wasn't long enough, I've included samples of scripts and the output of some of my debugging below. I've really run out of ideas for what to do next to try and identify the problem or to solve it, so ideas are very welcome! Vpopmail is *almost* working;
Re: [vchkpw] tcp.smtp.cdb is updated only once, and only when open-smtp is missing
So to recap: - open-smtp is correctly being updated with new pop auth IPs? - tcp.smtp.cdb is not being updated. A few things need to fall in line to make that all happen. And it sounds like you've got at least most of them. I would look at the config.h vpopmail file for: The #ifdef of where the tcprules program lives. make sure it is there :) then make sure the user that the vchkpw program runs as (when a user pops) has permission to run it and update the #ifdef location of where the tcp.smtp.cdb file lives. Run the tcprules program just like vchkpw would, on the command line and see what happens. Check if it updates the tcp.smtp.cdb file. If all this is right then i dunno... If all your email accounts are owned by vpopmail then you might as well run the pop3d tcpserver (and logs) as vpopmail.vchkpw. The alternative (worth trying) is have everything run as root. Ken Jones On Friday 20 September 2002 11:53 am, Tony A.T. Mendina wrote: This is a long story; but, I'd be happy if anyone with the patience to slog through it could offer further troubleshooting suggestions, pointers to docs that I missed, or any other advice they deem helpful grin. My problem is that tcp.smtp.cdb is not being updated when a pop3 user logs in, _unless_ I delete the open-smtp file just before the login. I'm not seeing errors in the logs or leftover temporary files on the disk, and users can log in and check mail successfully. The file open-smtp _is_ being updated each time a user checks mail. Clearopensmtp _does_ run without error from the system crontab, whether I've got the vpopmail system running as root or as vpopmail. I'm trying to use vpopmail with qmail 1.03 and redhat 7.2. My previous (working) qmail+vpopmail installs use vpopmail 5.2.1 just like I'm trying to do now, but this new one is a little different. Instead of running tcpserver directly from my init scripts and using Debian with a 2.2 kernel, I'm running it using supervise and using Redhat with a 2.4. Switching back to debian and cloning is not an option for work policy reasons. The qmail installs themselves are identical; both machines use the current ucspi-tcp, .88. At first, I was first letting the /supervise/qmail-pop3d/run script start tcpserver as root, and the open-smtp file, as well as the cdb file, were owned by root. Tcp.smtp.cdb was in /etc/, and clearopensmtp was run as root. I carefully compared the locations and permissions of executables and data files between a working debian+qmail+vpopmail system and this new redhat one, I and couldn't find any difference. After reading the tales of users with similar problems in the list archives, I saw that most of them had to do with the vpopmail user having access problems with needed files and with /etc. So as an experiment, I switched the whole setup to use the vpopmail user. The cron job for clearopensmtp was changed to run as vpopmail; vpopmail was recompiled to use /var/vchkpw/etc rather than /etc for the tcp rules file, the supervise scripts were changed accordingly, and so on. Users (well, test user accounts) can still log in and check mail without errors being returned to the client software, but just as before, the tcp.smtp.cdb file is _still_ not updated, except every 15 minutes when clearopensmtp runs. Then, as a further experiment, I tried replacing vpopmail 5.2.1 with 5.3.8. I used /var/vchkpw/etc and ran all components as the vpopmail user. No luck. The one exception to the lack of updates is if I delete the file /var/vchkpw/etc/open-smtp. If I do that, tcp.smtp.cdb is updated when the next pop3 user logs in. Open-smtp is recreated, and further pop3 logins don't result in updates to the cdb file, just open-smtp. This is the case whether the cdb file is in /etc and I'm running vpopmail as root or its in /var/vchkpw/etc and I'm running vpopmail as vpopmail. I've also tried running the tcpserver which runs qmail-popup, vchkpw, and qmail-pop3d from the command line as root and both with and without the -u 89 -g 89 parameters; I get the same problem as always, every time. In case this long and unhappy story wasn't long enough, I've included samples of scripts and the output of some of my debugging below. I've really run out of ideas for what to do next to try and identify the problem or to solve it, so ideas are very welcome! Vpopmail is *almost* working; if I could just get vchkpw to update the cdb file, I'd be set. Thanks for any help you can give, Tony First, the recordio output from when recordio was added to the startup script just ahead of qmail-popup. tcpserver: pid 2093 from 66.6.197.35 tcpserver: ok 2093 0:216.65.196.14:110 :66.6.197.35::1349 093 +OK [EMAIL PROTECTED] 093 USER [EMAIL PROTECTED] 093 +OK 093 PASS I've removed it 093 +OK 093 STAT 093 +OK 18 17029 093 LIST 093 +OK 093 1 1451 093 2 919 093 3 719 093 4 1037 093 5 1037 093 6 1640 093 7 717 093 8 921
[vchkpw] tcp.smtp.cdb is updated only once, and only when open-smtp is missing
This is a long story; but, I'd be happy if anyone with the patience to slog through it could offer further troubleshooting suggestions, pointers to docs that I missed, or any other advice they deem helpful grin. My problem is that tcp.smtp.cdb is not being updated when a pop3 user logs in, _unless_ I delete the open-smtp file just before the login. I'm not seeing errors in the logs or leftover temporary files on the disk, and users can log in and check mail successfully. The file open-smtp _is_ being updated each time a user checks mail. Clearopensmtp _does_ run without error from the system crontab, whether I've got the vpopmail system running as root or as vpopmail. I'm trying to use vpopmail with qmail 1.03 and redhat 7.2. My previous (working) qmail+vpopmail installs use vpopmail 5.2.1 just like I'm trying to do now, but this new one is a little different. Instead of running tcpserver directly from my init scripts and using Debian with a 2.2 kernel, I'm running it using supervise and using Redhat with a 2.4. Switching back to debian and cloning is not an option for work policy reasons. The qmail installs themselves are identical; both machines use the current ucspi-tcp, .88. At first, I was first letting the /supervise/qmail-pop3d/run script start tcpserver as root, and the open-smtp file, as well as the cdb file, were owned by root. Tcp.smtp.cdb was in /etc/, and clearopensmtp was run as root. I carefully compared the locations and permissions of executables and data files between a working debian+qmail+vpopmail system and this new redhat one, I and couldn't find any difference. After reading the tales of users with similar problems in the list archives, I saw that most of them had to do with the vpopmail user having access problems with needed files and with /etc. So as an experiment, I switched the whole setup to use the vpopmail user. The cron job for clearopensmtp was changed to run as vpopmail; vpopmail was recompiled to use /var/vchkpw/etc rather than /etc for the tcp rules file, the supervise scripts were changed accordingly, and so on. Users (well, test user accounts) can still log in and check mail without errors being returned to the client software, but just as before, the tcp.smtp.cdb file is _still_ not updated, except every 15 minutes when clearopensmtp runs. Then, as a further experiment, I tried replacing vpopmail 5.2.1 with 5.3.8. I used /var/vchkpw/etc and ran all components as the vpopmail user. No luck. The one exception to the lack of updates is if I delete the file /var/vchkpw/etc/open-smtp. If I do that, tcp.smtp.cdb is updated when the next pop3 user logs in. Open-smtp is recreated, and further pop3 logins don't result in updates to the cdb file, just open-smtp. This is the case whether the cdb file is in /etc and I'm running vpopmail as root or its in /var/vchkpw/etc and I'm running vpopmail as vpopmail. I've also tried running the tcpserver which runs qmail-popup, vchkpw, and qmail-pop3d from the command line as root and both with and without the -u 89 -g 89 parameters; I get the same problem as always, every time. In case this long and unhappy story wasn't long enough, I've included samples of scripts and the output of some of my debugging below. I've really run out of ideas for what to do next to try and identify the problem or to solve it, so ideas are very welcome! Vpopmail is *almost* working; if I could just get vchkpw to update the cdb file, I'd be set. Thanks for any help you can give, Tony First, the recordio output from when recordio was added to the startup script just ahead of qmail-popup. tcpserver: pid 2093 from 66.6.197.35 tcpserver: ok 2093 0:216.65.196.14:110 :66.6.197.35::1349 093 +OK [EMAIL PROTECTED] 093 USER [EMAIL PROTECTED] 093 +OK 093 PASS I've removed it 093 +OK 093 STAT 093 +OK 18 17029 093 LIST 093 +OK 093 1 1451 093 2 919 093 3 719 093 4 1037 093 5 1037 093 6 1640 093 7 717 093 8 921 093 9 734 093 10 735 093 11 735 093 12 733 093 13 735 093 14 735 093 15 1156 093 16 1656 093 17 685 093 18 684 093 . 093 UIDL 093 +OK 093 1 1032294648.21614.guilder.optimumreturn.com,S=1405 093 2 1032294707.21630.guilder.optimumreturn.com,S=858 093 3 1032294713.21634.guilder.optimumreturn.com,S=658 093 4 1032294893.21760.guilder.optimumreturn.com,S=976 2093 5 1032295236.21874.guilder.optimumreturn.com,S=+ 093 976 093 6 1032295950.21943.guilder.optimumreturn.com,S=1594 093 7 1032297065.23654.guilder.optimumreturn.com,S=656 093 8 1032297102.23663.guilder.optimumreturn.com,S=860 093 9 1032297216.24457.guilder.optimumreturn.com,S=673 2093 10 1032297245.24465.guilder.optimumreturn.+ 093 com,S=674 093 11 1032297303.24488.guilder.optimumreturn.com,S=674 093 12 1032297335.24497.guilder.optimumreturn.com,S=672 093 13 1032297357.24541.guilder.optimumreturn.com,S=674 093 14 1032297465.25301.guilder.optimumreturn.com,S=674 2093 15 1032297722.25325.guilder.optim+ 093
