Hi Guys For my admin login, ISP Config just keeps reloading the login page, and won't get me in to the control panel. At times it half loads the top menu, and then goes back to the login page again. Other times it will show 'logout' in the top right corner of the page, even though it's asking me to log in. It used to work after a few tries (up to 10 or so) but now just doesn't want to play ball. Running the perfect server on ubuntu 14.04 here. ISPConfig 3.0.5.4 p9. Weirdly, if I don't log in as an admin user then it seems to work fine. Any suggestions?
Predictably, it's a(nother) browser issue with Chrome. Loading the page in incognito mode fixes the problem, as does using another browser.
This problem is now also occurring in incognito mode (can't be cookies), and also in Firefox. Any help appreciated.
I have tried it on a different computer (behind the same IP) and still nothing. /var/log/ispconfig/cron.log doesn't show any MySQL errors (which I wouldn't expect as I am not having password issues). Could it be something with the custom main.tpl.htm that I have used? I changed the footer link, and the logo. Stranger things have happened. This is doing my head in. When I login, I get the pop-up box with the spinning wheel. The news feed loads on the left, but the tabs at the top don't load. Then, it gets to the bottom of the page (which is empty because the content there doesn't load either) and it immediately reloads the login page. Almost as if some code in that page is kicking me back to the login page. Any help appreciated!!
Check that the session table is not corrupted and there can be a problem with the template as well, if your template was quite old.
Thanks, till. I did some more digging, and found the following error in apache error log: mod_fcgid: stderr: PHP Warning: session_start(): Failed to decode session object. Session has been destroyed in /usr/local/ispconfig/interface/lib/app.inc.php on line 104, referer: xxxxxx I found this thread: https://www.howtoforge.com/communit...-to-log-into-ispconfig-admin-interface.73001/ but unfortunately don't know enough php to butcher the file. I attempted something (as one does) which threw up an error 500, and once I reset it back to normal it's letting me log in. I guess this could this be related to the session table, as you mentioned, and it has somehow reset the data?
Did you run a mysql check and repair on all tables of the dbispconfig database, especially the session table?
Thanks, till, I ran the check and repair on all tables in the dbispconfig database. It worked for a bit, but has now broken again. Where can I find an online copy of the current main.tpl.htm file? I'll over-write the one I've got, and re-edit for the branding requirements and see how that goes. Again, it's odd that this is only an issue for the admin user. Clients seem to be able to use the system fine. For clarity, what functionality to custom session callbacks provide? Speaking with a colleague, it seems to us that it would be preferable to not save information between sessions as with each load of the cpanel you want the latest information from the server. Possibly removing this would work as in the other thread, although I'm not sure which sections in app.inc.php to comment out.
In the ISPConfig tar.gz file which can be downloaded from ispconfig.org. You can rest assured, the session handler works fine on a few hundred thousand installations, so there is no issue with the code and removing it will open a security hole in your server, so I highly recommend to not do that if your system is connected to the internet.
Apologies, I don't really know enough about the technical details to make an educated guess here. Thanks, I'll reinstall the theme files and post back here.
Okay, so I overwrote the main.tpl.htm file with a new one (delete and paste the contents) and it didn't work. Unfortunately, when I renamed this file to main.tpl.htm.old and brought back in the old file, it broke something else and now there's no control panel and just a white page - this is very very bad, at least before clients were able to log in. What on earth is going on!? apache error log reports the following: mod_fcgid: stderr: PHP Warning: fopen(/usr/local/ispconfig/interface/web/themes/default/templates/main.tpl.htm): failed to open stream: Permission denied in /usr/local/ispconfig/interface/lib/classes/tpl.inc.php on line 862, I have checked the permissions of the file, and they seem to be fine. I have not looked at the tpl.inc.php file. I brought back in the original main.tpl.htm from the start of this box, and that didn't fix the problem. So now I have 3 versions that don't allow me to log in, and currently just a white page instead of the login prompt. How could something else have changed when I have only been looking at this one file?
I performed these steps: cd /tmp wget http://www.ispconfig.org/downloads/ISPConfig-3-stable.tar.gz tar xvfz ISPConfig-3-stable.tar.gz cd ispconfig3_install/install php -q update.php from this thread and at least the login page is back online. It's scary to think about the amount of data that may have been reset, but I will just have to go through it all manually. Now I am back to the original issue of not being able to log in with my admin user, and the trusty error message: PHP Warning: session_start(): Failed to decode session object. Session has been destroyed in /usr/local/ispconfig/interface/lib/app.inc.php on line 104, I am forced to attempt to remove the session handler as described in this thread, and try again, as I have orders waiting that can't be put off any longer. I think I can say with some confidence that it is nothing to do with the theme files. Any help appreciated.
I have commented out the following lines in app.inc.php: // session_set_save_handler( array($this->session, 'open'), // array($this->session, 'close'), // array($this->session, 'read'), // array($this->session, 'write'), // array($this->session, 'destroy'), // array($this->session, 'gc')); in the hopes that this will solve it. please let me know if this is opening the security hole you mentioned. it seems at this point that I have no other choice. it seems to have worked, so I will post back if that changes.
@edooze, I think the security concerns are pretty minimal, that will simply save the session data in individual files, eg. under /var/lib/php5/, rather than in a database table. The biggest implication I can think of is you wouldn't be able to share that session across multiple ispconfig servers, though there may be more to it than that which I'm not aware of. As to your problem, I wonder if there's a database collation/charset issue at play?
The problem is still ongoing. I've taken to commenting out the session handler whenever I need to log in, and then re-applying it when I don't. It's a real pain in the neck. Unfortunately, I'm not sure how to check the database issue. Do you have any suggestions? Thanks.