Am I right to be somewhat concerned? The error stack dumped to the screen _could_ be quite helpful for a potential attacker - while it is perfectly ok to log errors to a location where the sys admin can access them, details like the above should never make it to the end user (which could as well be a bot trying to break the application) Just my €.02
I think what Till is saying is you need to actually repair the existing database - a reinstall might fail if the tables are already present but marked as crashed or anything. And since there's no PHP error shown, I'm not sure the stack dump can even be controlled via php.ini...
looks like something wrong with my dbispconfig i have only 5 tables on it .. is that the latest version ??? or what
Looks _very_ wrong then - mine has 75 tables and I'm still on 3.0.5 - if you haven't actually set up any accounts, dropping the DB and reinstalling could be the better option indeed. Log in as the root DB user and check again to be sure you're not just accidentally checking with limited privileges.
Are you looking for _latest_ or _stable_? wget http://www.ispconfig.org/downloads/ISPConfig-3-stable.tar.gz has never failed me
Can't figure why Ubuntu 16.04 should be a problem - if you are generally following the "Perfect Server" approach, that is. If you're flying casual from a generic Ubuntu install, all kinds of funny things could happen - but you should always see some warnings/errors pop up during ISPconfig install then. Maybe watch the shell output carefully on your next attempt.
i have a system that runs on Ubuntu 12.04 and 14 with no problem .... but this is the first time i try to install on 16.04 with no luck yet
my issue is only 5 tables is created during the installation. i think this is hte line that cause the issue ERROR 1067 (42000) at line 139: Invalid default value for 'added_date' on my ispconfig3.sql file .. any idea ???
Ubuntu 16.04 requires ISPConfig 3.1beta 2, you can not use The stable ISPConfig 3.0.5 on that Ubuntu version.
This seemed interesting so I dug into it some. The above error "only" gives away the session id, nothing else that I see is sensitive. However, in ispconfig a valid admin sessionid is indeed the "keys to the kingdom". With only the session id set/copied, you get full admin access to the control panel, you can change the admin password (without knowing the old one), add your own admin user, etc. Even if you logout and/or set sessions to expire, when the admin logs in again next time, the same session id is sent (by the admin's browser), and reused by ispconfig, and at this point it becomes alive for anyone else who has copied/uses it. A quick way to invalidate the session is to logout, then clear cookies in your browser for the ispconfig hostname (and might hit the IP address if you've logged in there, though that should be a different session id). Note that if an attacker had added another admin account, or changed your password or anything, you'll have to recover from that (eg. password reset and check cp users), but we'll assume it's not an ongoing fight for the control panel, just typical cleanup/sanitization. In this particular case/post, the error message would have the session id for a broken ispconfig installation, possibly set on a temp/disposable domain, and there's no indication from this post what server name that cookie would be good for, so possibly a non-issue overall. If @Maile Halatuituia will eventually use the same server name in production, it would be a good idea to clear cookies in all browsers where that was set. So there's definitely an opportunity/need to improve this here. In fact, it looks like ispconfig used to regenerate the session id upon login, but that was commented out, probably creating this bug/issue: https://git.ispconfig.org/ispconfig/ispconfig3/blob/stable-3.1/interface/web/login/index.php#L213 Probably related to https://git.ispconfig.org/ispconfig/ispconfig3/issues/3827 EDIT: I was testing ispconfig 3.1 from I think July 6, where the session id does not change, hence session hijacking is a much greater possibility. I have not tested stable 3.0.5, it's certainly possible that isn't an issue there.
is the beta version ok for production, if so where can i get it otherwise i have to downgrade to ubuntu 14
thanks for the reply but i think the mysql version 5.7 does not support the disbuted field i guess .... i am looking for the beta version now of ispconfig or downgrade to ubuntu 14
Manage to install the beta version ok but cannot login with the admin user and passwword set during install