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

anarcat’s picture

Status: Active » Needs work

install.sh now creates an apache.conf with relevant settings.

anarcat’s picture

Status: Needs work » Needs review

I 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.

anarcat’s picture

Status: Needs review » Fixed

the 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

adrian’s picture

how 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.

anarcat’s picture

Status: Fixed » Needs work

1. 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?

adrian’s picture

we wont have server verification in this alpha yet.

what does this mean for this and what needs to go in the release notes ?

adrian’s picture

Category: feature » bug
Priority: Normal » Critical

There 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

adrian’s picture

the help needs to change.

adrian’s picture

Status: Needs work » Fixed

I 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

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit 2cacb6a on debian, dev-dns, dev-envobject, dev-koumbit, dev-log_directory, dev-migrate_aliases, dev-multiserver-install, dev-newhooks, dev-nginx, dev-ports, dev-purgebackup, dev-restore, dev-services, dev-simplerinstaller, dev-site_rename, dev-ssl, dev_716166_apache_conf, dev_dns, dev_server_verify, prod-koumbit, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-subdir-multiserver, 6.x-2.x-backports, dev-helmo-3.x by anarcat:
    #716166 - start separating platform, server and vhost configs
    
    
  • Commit 27524c5 on debian, dev-dns, dev-envobject, dev-koumbit, dev-log_directory, dev-migrate_aliases, dev-multiserver-install, dev-newhooks, dev-nginx, dev-ports, dev-purgebackup, dev-restore, dev-services, dev-simplerinstaller, dev-site_rename, dev-ssl, dev_dns, dev_server_verify, prod-koumbit, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-subdir-multiserver, 6.x-2.x-backports, dev-helmo-3.x by adrian:
    fix for #716166 - remove old apache configs for platforms/servers before...