Hi, I noticed few days ago that our ISPConfig server was behaving a bit funky as it refused to let a Shell user login after a password change. After few tries we noticed that the password wasnt actually changed and the old one was still active. We dug around a bit and found that even though ISPConfig seemed work fine on the surface, nothing actually was happening on the underlying system. We can edit and create new customers, shell users, FTP users etc. but those are modified or created only in the ISPConfig database, not in our web folders or passwd/shadow files. We did a server migration few weeks back and the setup was working ok after that as we signed up couple of new users after the migration and their accounts are working. I tried to put the server on debug logging, but as that is done inside ISPConfig, nothing actually gets logged. We have a Debian 6.0.5 with ISPConfig 3.0.4.6. I have peeked and poked around without avail, so any pointers where to look for the problem are appreciated. Thank you. - J
Are there any errors in ISPConfig's Monitor module? What's the output of Code: ls -la /usr/local/ispconfig/server/temp/ ?
Nothing recent, only old ones from the time the server was migrated and the database password was wrong but that was fixed. root@foo:~# ls -la /usr/local/ispconfig/server/temp/ total 12 drwxr-s--- 2 ispconfig ispconfig 4096 Aug 19 12:27 . drwxr-s--- 13 ispconfig ispconfig 4096 Apr 19 13:17 .. -rw------- 1 ispconfig ispconfig 227 Jul 24 16:50 rescue_module_serverconfig.ser.txt
I presume you are referring to this: http://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/ The result for that one is root@foo:~# /usr/local/ispconfig/server/server.sh finished. - J
This indicates that debuggin is not enabled or the mysql server is unreachable. Please check again that you enebaled loglevel debug in the ispconfig interface for the server were you had run the command.
I double checked and the loglevel was at "Debug" when the command was executed. Also the database is reachable as the changes done inside ISPConfig are saved there, I checked by hand, but those settings are not applied in any underlying configs (apache, shell, ftp).
I did a manual update (php -q update.php) and reconfigured services. Now I get some error messages. And on userinterface So it seems to be ispconfig database user password mismatch. Any ways to correct this? - J
Ensure that the mysql passwords for the ispconfig user in the files /usr/local/ispconfig/server/lib/config.inc.php and /usr/local/ispconfig/interface/lib/config.inc.php are corret so that the ispconfig interface and server part can connect to the dbispconfig mysql database.
As far as I can see, they are the same on database and config files. I checked from our previous server and there seems to be difference in the way the password is stored. On the old server it looks like its MD5 or SHA1 hashed (*FB928...) and on the new its some long string with all lowercase letters and numbers. Still the string is same in configs and database. - J
If its the same password string, then the password in the config or mysql db must have been altered as the password is cleartext in the config file while the password in the mysql database is encrpyted with the mysql password function. So if they are the same, then you either have a encrypted password in the ispconfog password file or a unencrypted password in the mysql user database. The passwords can look differently in your servers as mysql changed the way they encoded their passwords.
For some reason it seems the password indeed was put as plaintext in the database. So that cleared the problem. Still the first occurence of problems was weird. If the database was not available, how did the user interface work at all? Anyhow, thank you very much for the help. - J (ps. is there some donation mechanism for ISPConfig?)
The interface is available but you will get a login failure when you try to login. Donations can be made by buying a ispconfig manual or a howtoforge subscription.
