On a fresh ISPConfig 2.2.9 install on Opensuse 10.2 I have the following problem: After adding emailusers to a site it doesn't seem to update the virtusertable.db file and gives errors in the log. When I do it manual, all is fine: 28.12.2006 - 14:21:02 => WARN - /root/ispconfig/scripts/lib/classes/ispconfig_postfix.lib.php, Line 289: WARNING: could not postmap hash:/etc/postfix/virtusertable 28.12.2006 - 14:34:09 => WARN - /root/ispconfig/scripts/lib/classes/ispconfig_postfix.lib.php, Line 289: WARNING: could not postmap hash:/etc/postfix/virtusertable 28.12.2006 - 14:34:35 => WARN - /root/ispconfig/scripts/lib/classes/ispconfig_postfix.lib.php, Line 289: WARNING: could not postmap hash:/etc/postfix/virtusertable digistam:/etc/postfix # postmap hash:/etc/postfix/virtusertable digistam:/etc/postfix # /etc/init.d/postfix restart Shutting down mail service (Postfix) done Starting mail service (Postfix) done digistam:/etc/postfix # Any idea what could be causing this?
Please run Code: postmap /etc/postfix/virtusertable /etc/init.d/postfix restart If that doesn't work, please reboot the server.
That only works once. The next time, he does update the virtusertable again, but not that database. So it means you always have to do an ssh session and you cant have users change theire settings in the mailuser login, because the .db file is not updated and postfix isn't accepting any mail any longer.
I remember having the same issue on a SuSE 10.2 system (SuSE... sigh ). But on another SuSE 10.2 it was working. Please restart ISPConfig: Code: /etc/init.d/ispconfig_server restart Are there any errors in /home/admispconfig/ispconfig/ispconfig.log?
This is how it works for us We have the same problem on one of our servers running suse 10.2. This is how we solved it: - there was a warning in ispconfig.log - but the command given in the log works perfectly when entered in a shell so this seems to be a problem with php exec() I did not want to patch the code, because the patch would be lost in case of updates, so I decided to cd /usr/bin ln -s /usr/sbin/postmap as a quick fix. ISPconfig now works as expected.
virtusertable.db beeing destroyed I have the same problem. After ISPconfig updates the virtusertabel.db postfix rejects all incoming mail. I've spent well over 10 hours figuring it out... Here is my progress: 1: Mail beeing rejected and returned with the message: "reason: 550 5.1.1 <[email protected]>: Recipient address rejected: User unknown in local recipient table" 2: I check /etc/postfix/virtusertable and find the email address 3: run Code: postmap /etc/postfix/virtusertable to update the virtusertable.db file, and noticing that the file becomes much larger Code: -rw-r--r-- 1 root root 70K Aug 15 17:41 virtusertable -rw-r--r-- 1 root root 164K Aug 15 17:32 virtusertable.db -rw-r--r-- 1 root root 164K Aug 15 16:25 virtusertable.db.correct -rw-r--r-- 1 root root 12K Aug 15 16:16 virtusertable.db.destroyed 4: Add a new email alias to get ISPconfig to update the virtusertable and virtusertable.db 5: checkeing the log /home/admispconfig/ispconfig/ispconfig.log and finding the warning: "WARN - /root/ispconfig/scripts/lib/classes/ispconfig_postfix.lib.php, Line 289: WARNING: could not postmap hash:/etc/postfix/virtusertable" 6: Locating the php-code which runs the update in /root/ispconfig/scripts/lib/classes/ispconfig_postfix.lib.php line 289 Code: // virtusertable.db anlegen $mod->log->caselog("postmap hash:".$mod->system->server_conf["server_sendmail_virtuser_datei"], $this->FILE, __LINE__); 7: Assuming that the function $mod->log->caselog() runs an php exec() I make a simple php-file (postmap.php) to test if there is an error with exec() Code: <?php exec("postmap hash:/etc/postfix/virtusertable"); ?> and run it (as root) Code: php5 postmap.php and noticing that the virtusertable.db size seems ok. 8: Replacing the code in ispconfig_postfix.lib.php line 289 with Code: exec("postmap hash:/etc/postfix/virtusertable"); and get ISPconfig to run a new update. The virtusertable.db is again destroyed... 9: I assume it is something wrong with the user that runs the phpscript. For now i just comment out line 289 in ispconfig_postfix.lib.php... Any suggestions to fix this??? Edit: BTW: the softlink method did not work for me
The user that runs the script is the root user, so it has definately all needed permissions. Please add the line: copy '/etc/postfix/virtusertable','/etc/postfix/virtusertable_bak'); right before the postmap command is executed in the script and then check if /etc/postfix/virtusertable_bak contains any errors.
no error... here is an output of the diff command Code: hkweb4:/etc/postfix # diff virtusertable_bak virtusertable 7d6 < 1401c1400 < #### MAKE MANUAL ENTRIES BELOW THIS LINE! #### --- > #### MAKE MANUAL ENTRIES BELOW THIS LINE! #### \ No newline at end of file
Do you get any errors when you run Code: postmap hash:/etc/postfix/virtusertable manually on the shell? Which distribution do you use?
no errors No errors when i run the postmap manually. When I do it manually the .db file is totaly fine, and postmap reciebves email normally. I use OpenSuSE 10.2
Any errors in /home/admispconfig/ispconfig/ispconfig.log? What's the output when you run Code: /root/ispconfig/php/php /root/ispconfig/scripts/writeconf.php on the shell? Is AppArmor disabled?
Code: # /root/ispconfig/php/php /root/ispconfig/scripts/writeconf.php ls: cannot access /etc/apache2/vhosts.d/*.conf: No such file or directory start ende AppArmor is disabled The only error I get is the "could not postmap" warning above
Here's my story (after about 4 hours), perhaps you can find out what happened: 1. I ran into the same problem on one of our servers. Drove me crazy as on the second (test/less important sites) server everything is just fine and our production server shows exactly this problem. We also use OpenSUSE 10.2 and this all happened after upgrading ISPConfig from 2.2.9 to 2.2.18. The configurations of the two servers are the same almost to the letter (both perfect setup and vanilla ISPConfig, the only two extra services we use is mailman and Zend Optimizer which is not on the second server). I tried to switch off Zend Optimizer but it seems not to matter. 2. Just like the gentleman before, symlinking did not help and everything was fine when ran by hand. The only extraordinary thing was that after update, I had an error message for one of the anon FTP users (actually, this might be the only anon FTP user we have): 28.11.2007 - 01:57:15 => WARN - /root/ispconfig/scripts/lib/config.lib.php, Line 1957: WARNING: could not useradd -d /srv/www/web102/ftp -g web102_anonftp -m -s /bin/false -u 12102 web102_anonftp &> /dev/null plus the other WARN, the postmap hash:.... For a while it seemed that if I erase the anon FTP user for that site, then things get better. At least it seemed. But after some more experimenting, everything failed. 3. I am not much of a guru, so after everything failed (the symlink, the Zend Optimizer, updating SUSE, etc.), I tried to reinstall ISPConfig. The error appeared at once (it was like 15 minutes ago) and I almost cried. 4. In my final desperation, I tried to modify by hand the script, probably did something stupid because then ISPConfig would not log any more... so I restored the original script and restarted ispconfig_server. 5. Now postmap virtusertable suddenly seems to work. Like it always has. Can anybody explain what the hell happened? Anyway, if you ran into this, please try to reinstall ISPConfig and to restart it manually. By the way, what might be wrong with that FTP user? Clearing and rechecking the Anon FTP checkbox does not help... grep web102 shadow shows this: singuuriq:/etc # grep web102 shadow web102_anonftp:!:13845:0:99999:7::: Thank you very much in advance. Best, Szabolcs
These problems seem to happen on OpenSuSE 10.2 only. I don't know why because on my test system everything was working as expected.
That was the bummer: on our test system everything was working as expected, too... :-( Anyway, now it seems to be fine. And ISPConfig still rules. Helps us so much...