Apparently I learned a hard lesson today. Don't update ISPConfig 3* on the day of release. Ispconfig 2 was stable and 3 might take another few months to be production ready (in my opinion). I wanted to push 3 as it utilized database users instead of system users. Years ago I had written some preliminary db design for virtual email users from within exim. Since then, I just haven't had the time to develop, so ISPConfig has been a help (version 2). Version 3.0.1.1 is beta quality (in my opinion), and should be labeled beta. Today, I get home from work and want to update 3.0.1.1 on a test server to 3.0.1.2.. Downloaded the tgz to /tmp and extract. cd into the install folder of the ispconfig root and run php -q update.php The install script complains about some dbispconfig.firewall_custom table not existing. Reconfigure services? [yes/no].. Either option I run wastes my database and cannot login.. If I leave the browser session open before the upgrade script is run, and refresh an email domain list after updating, the data is gone. Running an sql client and browsing the data verifies the data being gone.. So.. I don't see anyone else reporting any problems, so I'm pioneering this thread and see what comes about.. by the way, I am running Debian Lenny and followed the howto for perfect server etc for ver. 3.0.1.1 thanks
ISPConfig 3 is not beta and it is used in production enviroments for over a year. It is already in use on many thousand servers. Fine, sou you realised already thats a problem with your setup and not a general updating problem in ispconfig. So your post about beta quality is quite nonsense. You updated a svn version with a stable version. svn versions can not be updated with stable versions as they may contain more tables or a later development. Thats why you lost your database. You can update a svn version only with a svn version. To restore your database, use the database backup which is stored in the root folder. So as long as you install released versions from the ispconfig 3, then you have a stable enviroment. SVN versions are only for development and shall not be used in a production server. Thats the case for any open source project and not onyl ispconfig.
Ispconfig 3 Mr. Till. You are wonderful person for taking on the responsibility of these threads and helping those get things working. Also, I know I have offended you because much work is going into the project and your reply reflects it. However, installing the same thing to a server, server after server, does not prove it is stable. For instance, when installing a new OS, don't click on things that are off the path of install, or you're in a realm less tested. I don't download SVN versions... that is unless, by mistake, an SVN version was put in place of the release version on ispconfig.org site. No Till, I can assure you that I have read your other threads relating to the dropped database of mixing svn and releases, and it didn't apply to me. So to conclude, there appears to be nothing wrong with my setup. I had downloaded and reinstalled THE NON SVN VERSION several times without problem (ver 3.0.1.1). Something else is wrong.. So right now, I am working from an updated ispconfig 3.0.1.2, with data imported back into the db from 3.0.1.1. Till, I've always done ISPCONFIG to the book. If that's not good enough, then ISPCONFIG is beta. Stop getting offended that I think it's beta. It has problems! I'm obviously needing to do my own backup and go through this whole hoop de doo thing all over again... Till, thanks for your help.. I will figure this out.
There is no such table as firewall_custom in any released version. All released versions are available on sourfecorge, feel frr to download them and look into the sql dump if you dont believe me. Another possibility is that you created a table named firewall_custom manually.
ispconfig 3 yes, I was trying to make a custom firewall to manage independent src ip's in iptables. Since then, I was pretty sure I cleaned up from that and reinstalled. It's complaining it has no table, so somewhere there is still something pointing at this. thanks man Jordan
fixed The installer doesn't like having other tables in the database. Apparently, just removing the table made the upgrade work. Perhaps the tables are referenced by id, hence breaking the database on prior attempts? It is working fine now but I am a bit concerned about future upgrades on systems that aren't stock, as we do tweak things to get what we want. Is it possible that the update.php script could have not worried about extra tables? thanks Jordan ps: spam sucks.. it's a constant battle
