first of all - i don't want to blame anybody - it was my own fault and i am the only responsible person for this problem - but i want to tell about, maybe the installer could help me by doing backup of the configuration files. i changed the file /root/ispconfig/isp/conf/vhost.conf.master. i added the line Code: suPHP_ConfigPath {HTTPD_ROOT}/{WEB}/etc/php because with this trick every virtual host has it's own php.ini and so i can set the tmp-dir and the open-basedir individually for each virtual host. after doing the update to the newest version i realized that the update copies its "new" file over my "old" file and so my changes where gone. this means the openbasedir and the tmp-dir was meaningless and this opens a security hole. one again - my fault! i changed something and forgot to re change it after the update. But maybe the installer can reate a "backup-dir" and copies the "old" files there, so that i can recopy the "old" files over then "new" ones. the same was with the apache default-files. i changed them all to my company and after doing the update all changes where gone. - just want to say ;-)
I support this. I mentioned something alike, when I suggested to use a 'custom' subdirectory where customizations could be stored. If a config files exists, ISPC should use the custom file and not the standard. Upgrading would be much easier. All defaults can be changed. If a custom ISPC config files exists, only a warning should be given during the upgrade phase. It's then the responsibility of the server admin to check for inconsistencies. This trick is also used by DirectAdmin. We should make this a RFE.
The setup script is doing this already, its not a directory, its a tar.gz file. Have a look at your /tmp directory, there are 2 tar.gz files and a SQL dump. These backups should be removed from /tmp/ when you verified that the update worked as expected. Yes, I think this makes sense but the installer will have to be rewritten for this. A Drawback of this method is, that it will often result in a non working system while the curent installer ensures that your system works.
I agree it involves an extra question when problems are reported: "Do you have any file in the <where-ever>/custom directory? If yes, remove it (or check the differences)". But it will bring much more customization options to the skilled sysadmins.
