Hi, I have got a seemingly odd problem with fresh installation of ISPConfig 3. We've got a brand new Intel Server platform with SuSE 11.4 installed today. I have used a tutorial for SuSE 11.4 to install ISPConfig. The only deviation from it was that I am using default SuSE firewall, instead of Bastille. Installation seems OK (there are some complaints on Dovecot, but it seems to be unrelated). ISPConfig is up and running. But when I enter admin:admin default credentials, nothing happens. The script just kicks me back to index.php. After playing around for some 4 hours, here are some facts: - when I enter login/password incorrectly, it complains on incorrect credentials - only when I enter login/password correctly, it kicks me back - MySQL contains ISPConfig DB, and I can access it by logging in with the credentials found in /etc/vlogger-dbi.conf - I have a PHPSESSIONID in my sys_session table, and the same PHPSESSIONID is transfered by browser - reinstalling ISPConfig with DB dropping is not helpful - disabling the firewall in SUSE altogether does not change anything - changing ports does not help - when I monitor data exchange between server and browser with network analyzer, following is seen: + client sends username and password with POST and XMLHttpRequest + server replies with LOGIN_REDIRECT:dashboard/dashboard.php + browser fetches /nav.php?nav=side, /js/scrigo.js.php, and /nav.php?nav=side. The js is a big javascript file. It seems that some javascript should take care of that LOGIN_REDIRECT:dashboard/dashboard.php. Since everything is gzipped, I have played the entire converation manually with netcat (without accept-encoding:gzip), but when fetching dashboard/dashboard.php, it only gives me 302 found with Location: /index.php. Here is where we end up. Too much javascript for an amateur to understand what should be here... Can someone help me, please? Thank you!
Which ISPConfig version did you install? The latest stable, or from SVN? Did you check if the ISPConfig database is ok? Are there any users in the sys_user table?
I have downloaded latest stable version from ispconfig.org (not sure where can i check the version on my server?). The database is present, in sys_user there is user admin with a password hash equal to MD5('admin'). I am pretty sure the authentication takes place (there is difference in behavior when correct or incorrect credentials are entered).
Do you use any ad or script blocker software in your browser? If yes, turn it off or try to use a different browser. Another possible reason for that problem might be if there is a alias for dashboard defined somewhere in your apache configuration, so that the request for the index.php in the dashboard directory gets redirected to a different location.
Have tried to login in four browsers on two different machines (FF6, Google Chrome, and IE7 on Win7, and FF on SuSE Linux desktop). The server is a clean install, nothing but ispconfig in Apache: /etc/apache2/sites-available # l total 20 drwxr-xr-x 2 root root 4096 Sep 23 22:45 ./ drwxr-xr-x 12 root root 4096 Sep 23 21:36 ../ -rw-r--r-- 1 root root 1022 Sep 23 22:44 apps.vhost -rw-r--r-- 1 root root 1248 Sep 23 22:44 ispconfig.conf -rw-r--r-- 1 root root 1691 Sep 23 22:45 ispconfig.vhost
I indeed have a redirect when trying to access my 192.168.0.100:8080/dashboard/dashboard.php: 192.168.0.101 - - [26/Sep/2011:09:59:36 +0400] "GET /dashboard/dashboard.php HTTP/1.1" 302 26 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0" but when I replace dashboard.php with my code (<?php print 'zzz'; ?>) it just works as expected (no redirect for this URL in config files). Any ideas?..
Iam not talking about the files written by ispconfig, as they dont contain such a alias or redirect. Please check the other apache config files, eg with the grep command.
Thats most likely because you are not logged in. The ajax pages cant be loaded without a prior successful login. Please check the tables in the ispconfig database wih phpmyadmin and ruN the mysql repair command on them.
I have figured out that my sys_session table contained a VARCHAR(32) for session_id. But I have checked cookie info in FF Web Developer addon to find out that my PHPSESSID is ue9mldprejr798ie9nvvbp57dcr19n1b060idmekmpv595d40t40 which is somewhat beyond 32 bits. I have changed VARCHAR(32) to VARCHAR(64) in mysql, and it finally works!!!! After taking a look at phpinfo(), i have found that session.hash_function sha256 This is a default value for my Apache, installed from OpenSuse repo for current SuSe beta version. I did not change any Apache settings to change hash function. Seems that ISPConfig users may have problems with it when release comes out - maybe this is worth project developers' attention. Thanks so much for your help.
Thanks for your findings. We havent tested with opensuse betas yet. We will change the length of the field in ispconfig.
Switch on the database! I was having troubles logging into to ISPConfig after a fresh install. Turns out I was having an idiot moment, the database daemon was not set to start at boot!! dur! The default credentials of "admin/admin" couldn't be checked. (would have been nice if ISPConfig prompted about no database connection but oh well) Check MySQL is running with: # service mysqld start Also turning off SELinux might help for debugging in /etc/selinux/config change SELINUX=permissive then reboot (...ok not the most elegant approach but it leaves nothing to chance) Hope this helps somebody!
