Hi, if I got it right I can copy the templates located in server/conf to server/conf-custom (or from install/tpl to server/conf-custom/install) to adjust the corresponding conf file. If I would place a file named apache_apps.vhost.master there, it would be parsed everytime a vhost gets changed or created I guess. And maybe also on resync in multi-server-setup? Now in my case I would like to edit apache_ispconfig.conf.master for general settings not related to any vhost just like the ones already in there. What triggers the file /etc/apache2/sites-available/ispconfig.conf to be rewritten from the template? And one more question: In a multi-server-setup is it correct that I have to place my template files on every client-ispconfig server myself? (meaning: they will not be copied in any way from ispconfig master server) Thanks for clarification - could not find any information about it (if there is a source I would like to know where. We also bought a manual, but could not find this info there). Regards
Yep, that's exactly how it works. Some templates are used repeatedly by the system (generally (always?) in server plugins), others are only used by the installer, and that's how you override/change them. Implied in doing so, you also then have to be careful to manually check every template you use each time you upgrade ISPConfig versions (or from dev if you update to git-stable) to see if the upstream templates have changed since you made your copy upon which you based your changes. This can become a pain and can be easy to forget; I hope this can improve in the future. At a minimum you might add a comment to your own template with the timestamp of the original template you used or something so you can quickly look and know that it has or hasn't changed. (I wish I had done that initially .. nowadays I work to get all my customisations into proper feature support upstream, working towards 0 conf-custom files.) No, from a quick look at the source, that template is used to create the 000-apps.vhost file in the installer (so runs when you initially install ISPConfig, and each time you update ISPConfig choosing to reconfigure services) as well as in the apps_vhost_plugin.inc.php server plugin, triggered from the server_update event - I believe that event is fired when you edit a server's config (System > Server Config > {server}), not when a vhost is changed/created. Again, no, not from doing Tools > Resync, but just when editing the Server Config for a server. Note that if you don't need to change those exact settings, but just add some more global apache settings, you can do so by creating your own conf file (in /etc/apache2/conf-available, with a symlink under conf-enabled), and you won't have another template to maintain. As above, that is both in the installer as well as a server plugin. You can see that in the server plugin it is called inside the server_ip() function, which is hooked from the server_ip_{insert,update,delete} and server_{insert,update} events. Ie. change a server ip, or edit server config, and it'll fire. Correct, all template files only affect the server on which they reside, and are not automatically distributed.
Thank you very much for this detailed answer! It helps a lot. We will keep the modified templates in VCS to be able to track the changes and keep them in place for ISPConfig Updates.
After the v3.2.2 update I found several config files messed up. I posted tickets and most of them were closed with admonishment to use conf-custom. OK, this is the first time I've had to understand this in-depth, with no mention of conf-custom in the PDF documentation, and no resource other than random forum posts. Of the hundreds of forum posts I've read, I missed this one, which is really helpful. Yes, a better update mechanism would be desirable. Yes, it's a pain to have to manually diff update with the prior version, diff that with our customizations, and then manually determine how we should process each change - without the benefit of some link between the data change and the related issue/commit. Yes, master/slave conf-custom automatic transfers would be desirable. Yes, it's FOSS, and if we want it bad enough we should do it ourselves and publish it for others. I don't have a problem with the model. What constantly bothers me is the deep pain we need to go through to learn what this great software does .... and what it does not do.
