Now that install.sh lives in provision and the server node refactoring is done, we should consider having hostmaster self-provisionned, that is make provision be able to install a hostmaster site (for that, see #711740: allow install of hostmaster sites in provision-install). But installing hostmaster is not enough, we also need to deploy the first platform.

Right now, install.sh does the following:

1. parse commandline
2. prompt for confirmation
3. creates a basic directory structure in $AEGIR_HOME
4. downloads drush in $AEGIR_HOME
5. downloads drush_make in $AEGIR_HOME/.drush
6. downloads provision in $AEGIR_HOME/.drush
7. deploys hostmaster in $AEGIR_HOME using drush
8. creates an apache config file in $AEGIR_HOME/config/vhost.d

This needs to be cleaned up so we have a simple script that can install the backend and a backend command to install the whole frontend in one shot.

That command would come after an install.sh that would just create the directory structure, and download drush, drush_make and provision in relevant places. The new installer (i suggest calling it provision-aegir) would then do:

7. deploy the hostmaster application using drush_invoke
8. provision-install the site (which creates the apache config file and other things)

The idea here is to separate the bootstrap of a "provision server" (the backend), which would be accomplished by install.sh or distro packages, from the task of bootstrapping a hostmaster site (the frontend), which would be accomplished by provision itself.

This looks a bit like how hostmaster-migrate works: it creates a platform if missing... So we should probably recycle some code from there. See for the original patches.

Comments

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Status: Active » Needs work

I added the -b flag to install.sh which allows installing only the backend. I think that's really all that can be done right now while we wait for #711740: allow install of hostmaster sites in provision-install to roll in.

I also made an apache.conf configuration file that has all the config settings we need (mod_env, mod_rewrite, NameVirtualHost, the Include, etc) instead of relying on provision to eventually do that.

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Issue tags: +multiserver

note that this touches multi-server support and #586000: make a "server verify" task.

adrian’s picture

adrian CreditAttribution: adrian commented

i am thinking now, we should abandon the wizard completely.
not make hostmaster installable from the "front end", ever.

This will also tremendously help with packaging, as we can have a clear path to make a .deb for the system.

Even though i have been hesitant to do this before, I think we should remove all the inline documentation in the system at the moment, since it's inherently tied to the old model and the wizard.

Once we have the server verify task, a lot of things are going to change .. and we can look at re-introducing inline help as per the original intention (ie: if a verify fails , it is keyed to the error code so it gives you contextual help how to fix it). The original help will remain in the git repository for future reference, and we will reduce our code base tremendously.

We could potentially reduce the code base by thousands of lines of code and actually remove several files altogether.

anarcat’s picture

anarcat CreditAttribution: anarcat commented

I agree we should ditch the wizard except for the usual "what's your site name" idiocies that can be automatically filled in. The server verification is going to do most of the magic, and I'm not even sure we need a frontend task for it: it's sysadmin level stuff that's taken care of during the install.

If we drop the wizard #711740: allow install of hostmaster sites in provision-install becomes trivial, and we can rewrite install.sh to be a simple drush command. We'd just need people to install drush, drush make, provision and then run a magic command (drush hostmaster-install) to which you pass all the relevant parameters (or they get prompted) then everything gets installed.

anarcat’s picture

anarcat CreditAttribution: anarcat commented

So a lot of this work has progressed since the dev-services merged the dev-server-verify branch in. In fact, now, the only thing blocking #711740: allow install of hostmaster sites in provision-install is #772824: rip most of the wizard out of hostmaster.profile.

Once the above is done, we can fix install.sh to call all those nice commands (including hostmaster-setup) in order. In fact, this should probably be done in PHP, through a hostmaster-install command in provision. install.sh then just becomes a stub that downloads drush, drush make and provision then fires up hostmaster-install.

So we're just missing that hostmaster-install command here, once the above issues are done.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Needs work » Fixed

we did exactly what comment #5 says. marking fixed

Status: Fixed » Closed (fixed)
Issue tags: -self-hosting, -multiserver

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

Issue tags: +self-hosting, +multiserver

Restoring issue tags, see #2125755: System messages removed all issue tags during D7 upgrade.

  • Commit 4568dc3 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: 
    #711760 - separate backend and frontend install process in two shell...