I had updated the password on one email account on one domain out of 15 domains. All of a sudden, i began getting errors with sudo and root - saying uid 0 , and uid 1000 did not exist. I looked in /etc/passwd and only accounts for web2_ (the domain i updated) were visible!! .. root, the main accounts , logger accounts were all gone - only web2_ accounts remained. I had to login to another system and copy the first section of /etc/passwd to get the system running at half-capacity again. I'm stil getting this error. sudo: pam_authenticate: Authentication service cannot retrieve authentication info. And, I need to find out how to get ispconfig to rewrite the passwd file from the other 15 domains besides web2, i don't know all those uid's!
Any errors in /home/admispconfig/ispconfig/ispconfig.log? What's the output of Code: ls -la /root/ispconfig ?
output os ls -la /root root@www:/var/www# ls -la /root/ispconfig total 100 drwxr-xr-x 9 root root 4096 2007-06-29 10:50 . drwxr-xr-x 5 root root 4096 2006-08-31 13:00 .. -rwxr-xr-x 1 root root 33494 2006-08-23 14:33 cronolog -rwxr-xr-x 1 root root 9673 2006-08-23 14:33 cronosplit drwxr-xr-x 12 root root 4096 2006-08-23 14:14 httpd drwxr-xr-x 12 root root 4096 2006-08-23 14:33 isp -rw-r--r-- 1 root root 8 2007-06-29 10:50 .old_path_httpd_root drwxr-xr-x 6 root root 4096 2006-08-23 14:11 openssl drwxr-xr-x 6 root root 4096 2007-03-15 12:30 php drwxr-xr-x 4 root root 4096 2007-01-04 23:59 scripts drwxr-xr-x 4 root root 4096 2006-08-23 14:33 standard_cgis drwxr-xr-x 2 root root 4096 2006-08-23 14:33 sv -rwx------ 1 root root 9389 2006-08-23 14:33 uninstall
All Issues Resolved ISPConfig is great, its never presented any issues whatsoever until now. Overwriting /etc/passwd file instead of appending changes for a given domain Optional Apache Directives are added to the beginning of the virtual host configuration section, rather than the end - this causes some configuration directives to fail needlessly I had to reconstruct my /etc/passwd file. Knowing that ISPConfig had never done this before , I assumed the issue was transient in nature and updated one account out of every domain on the server. I saw that the /etc/passwd file had been built back up - but crucial system accounts were still absent. I went to another system which was similar in configuration and copied many of the system accounts (root, logger, ftp, etc...). This stopped most of the errors, I was still not able to sudo from a non-root account and I had only been lucky enough to have left a root terminal open from before the /etc/passwd corruption. After several several hours of verifying the integrity of the authentication system I realized suddenly that there were two accounts under the same uid in /etc/passwd and I had inadvertently copied one account over with the same uid as the one i was having trouble using sudo from. Removing the extra account fixed the pam_authentication issue. I will also note that the passwords for all accounts on all domains had been corrupted to a degree - such that I had to go in and reset the password for most of them to continue operations. On a separate note , for some reason ISPConfig is writing [email protected] on some entries in /etc/postfix/virtusertable and [email protected] on others - I've had to manually add entries for certain domains and run postmap /etc/postfix/virtusertable Finally, on the optional apache directives issue. It is possible to run RubyOnRails applications on ISPConfig by using the ProxyPass and ProxyPassReverse directives to internally forward requests to an instance of mongrel, or webbrick server. However, abruptly - ISPConfig somehow kept commenting out this configuration so whenever anyone would go to a site that was to be running a ruby server - they would see the default index.html for any domain. This became a serious problem - I found out that if you add the "ProxyPass / http://localhost:3000/" and "ProxyPassReverse / http://localhost:3000/" to the beginning of the vhost configuration (as ISPConfig does it but immediately comments it out - i had to try this manually and run httpd -t") httpd -t fails when those directives are prepended to the configuration - but does not fail when appended to the end of the vhost section specific to the domain. To resolve this issue, I had been forced to copy out the vhost configurations out to a text-editor. Delete the sites from ISPConfig. Add the directives, and stick them in at the end of apache2.conf after ISPConfig's vhost configuration had already been included. Best of Luck, These are the only issues i've ever encountered with ISPConfig.
