Right now, we have a vhost.d that does everything: server-wide config, vhost configs and platforms configs. That's wrong, as we don't have a clear idea of which config file loads first (other than alphabetical order) and there's the potential of namespace conflicts between platforms and vhosts.
We should rather divide this up in topical directories:
/var/aegir/config/
vhost.d/ - apache virtual hosts, one per site (or so)
platform.d/ - apache Directory platforms, what replaces the .htaccess, one per platform
apache.conf - server-wide configuration, which includes the two above, and can be symlinked in /etc/apache2/conf.d or included in httpd.conf
This will require changing the platform verification code so it writes the platforms files there and add a new setting for that platform.d path (which could make upgrades tricky). apache.conf would be handled by the server verification task.
Special case: the aegir site
We currently have a special config file for the Aegir site. We would need to get rid of this special config for the above to make sense.
The special config is the file apache2.conf in hostmaster. It's basically a bastardized template mixing the three above categories: it's the vhost for the aegir site, the platform config for the aegir platform, and has server wide configuration.
Once we get #711740: allow install of hostmaster sites in provision-install working, we don't need the vhost part in this file. The installer should also take care of platform settings (through the use of provision-verify). Which leaves us only the server-wide settings, which include the NameVirtualHost *:80
directive and stuff like #497522: make the default Apache VirtualHost return a 404, which would be in the apache.conf.
The new apache.conf file would be part of server verification (#586000: make a "server verify" task), executed on install. It's currently handled through install.sh.txt, which be itself reshuffled to separate backend (provision) and frontend (drush make hostmaster, provision-verify, provision-install) installation (#711760: separate backend and frontend install process), so that the three parts are above are handled separately, in a "standard" way (using our regular provision tools).
Who's responsible for what
So basically:
vhost.d/ - handled by provision-install and other site commands
platform.d/ - handled by provision-verify and other platform specific commands
apache.conf - handled by the server verification task
Comments
Comment #1
anarcat CreditAttribution: anarcat commentedinstall.sh now creates an apache.conf with relevant settings.
Comment #2
anarcat CreditAttribution: anarcat commentedI started work for this on the dev_716166_apache_conf branch in git.
I think it basically does whatever is needed there, but we need testing.
Comment #3
anarcat CreditAttribution: anarcat commentedthe branch was merged on head after a little bit of testing, marking fixed.
the relnotes will need to mention this, some notes have been added to UPGRADE.txt for the migration
Comment #4
adrian CreditAttribution: adrian commentedhow will we generate the apache.conf for people who are upgrading ?
what happens to existing server.conf file ?
do the existing platform files get moved / deleted.
Comment #5
anarcat CreditAttribution: anarcat commented1. apache.conf is generatd through #586000: make a "server verify" task which needs to be ran on upgrades
2. the existing conf file needs to be removed manually
3. the existing platform files need to be moved manually
2 & 3 could possibly be done automatically by server verification until 0.4 is released and then that compatibility code removed in a subsequent release. How's that?
Comment #6
adrian CreditAttribution: adrian commentedwe wont have server verification in this alpha yet.
what does this mean for this and what needs to go in the release notes ?
Comment #7
adrian CreditAttribution: adrian commentedThere is no documentation on changing it to point to apache.conf, which is already generated.
The manual directory creation should not be necessary (similar to the _80 rename of vhosts, we can check the old location first).
The only thing the user should have to do is change the line in their httpd.conf.
I'm looking to see how to detect the httpd.conf is pointing to the right location.
Probably by adding the 404 vhost to it, and doing http -S
Comment #8
adrian CreditAttribution: adrian commentedthe help needs to change.
Comment #9
adrian CreditAttribution: adrian commentedI changed the help, in hostmaster. And modified the upgrade.txt to get the user to change the httpd.conf line.
I also added a default virtualhost in #497522: make the default Apache VirtualHost return a 404