When installing Aegir via the Hostmaster Installation profile, the install wizard requires writable permissions to settings.php in the usual spot that a default Drupal installation would.

After db credentials have been entered and the form submitted, the message states that all necessary changes have been made, and that the file has been set back to read-only for security.. all good. We are now at the 'Configure Site' form.

After submitting the Configure Site form, the *next* page unique to the Hostmaster profile, throws a Permission Denied exception regarding the settings.php, as though it expected it to be writable on the next step as well.

Leaving the settings.php writable for this one extra step in the chain of installation (in other words, making sure it's *still* writable when submitting the form on 'Configure Site'), and *then* re-protecting the settings.php afterward, avoids the error and keeps everyone happy for the rest of the installation.

Encountered myself and recently reproduced by others such as realityloop doing recent fresh installations.

CommentFileSizeAuthor
Following step after re-protecting settings.php - unexpected permission error68.01 KBmig5
settings.php supposedly done with - permissions set to readonly at normal step40.61 KBmig5

Comments

anarcat’s picture

anarcat commented
Title: 6.x-03-rc2 installation profile requires writable settings.php for one step further than expected/advised » installation profile requires writable settings.php for one step further than expected/advised

We need to rewrite the settings.php because of a bug in Drupal (#330297: Themes in profiles directory not discovered during install). This function makes sure the install profile is set properly in there... As long as that patch isn't committed (reviews and testing welcome!) we'll have to hack the settings.php after it's usually done. I'm not sure how best to workaround that issue for now, an better warning maybe?

Anonymous’s picture

Anonymous (not verified) commented

So this is a catch 22, per this code as you say above:

/**
 * modify the settings.php
 *
 * add the install_profile variable to the settings.php so that Drupal
 * picks up the theme in our install profile
 *
 * This is a bug in the Drupal core: http://drupal.org/node/330297
 */
function hostmaster_settings_php() {
  $settings_file = realpath(conf_path() . '/settings.php');
  drupal_verify_install_file($settings_file, FILE_READABLE|FILE_WRITABLE);
  $fp = fopen($settings_file, "a");
  fwrite($fp, "\n\n\$conf['install_profile'] = 'hostmaster';\n");
  fclose($fp);
  drupal_verify_install_file($settings_file, FILE_READABLE|FILE_NOT_WRITABLE);
}

If we keep this, then when the regular Drupal install advises to re-secure the settings.php, and one does so, the beginning of hostmaster_profile_tasks() calls the above function which will then fail to write to settings.php since we made it not-writable again.

If we remove the above code, the eldir theme doesn't get deployed properly in the install profile.

There are three possible solutions:

1) Provide a better warning / documentation in the INSTALL.txt saying something like 'the standard Drupal installer will advise you to re-secure your settings.php. Do not do this yet, as Hostmaster requires the ability to write to the file for one extra step beyond this section in the installer.' Or something.

2) Try and do something clever to stop Drupal advising the user to re-secure the settings.php at that standard place, and place the message on the other side of when that function above occurs. I have no suggestion how to do this and it feels ugly

3) Give up on the idea that the eldir theme should be installed in /profiles/hostmaster/themes/eldir and let it be downloaded to /sites/all/themes/eldir, which Drush will probably do by default anyway per the current docs instructions of 'drush dl eldir'. If the Eldir theme is in sites/all/themes, the theme will initiate as normal and in this scenario, we do not need to make any extra change to settings.php and can get rid of that function above.

As I understand, it's more 'correct' to put the 'eldir' theme inside /profiles/hostmaster/themes/. However we have a choice between what seems almost like 'tricking' the user into re-securing their settings.php, then immediately trying to write to it and throwing an error at them, or doing it in another way involving no hackery and which actually, well, works.

So until that issue 330297 is fixed (and the patch there is currently faulty itself), personally I vote for not screwing the user up majorly, ignoring the 'how it's meant to work' approach, and advising the user to drop eldir in /sites/all/themes/ (maybe /sites/aegir.example.com/themes/ will work too, haven't tried)

Anonymous’s picture

Anonymous (not verified) commented

I should add that if that php above gets removed, the patch for install_include(hostmaster_profile_modules()) in hostmaster.profile which got committed today correctly makes use of the install_profile_api, which makes the theme work as expected, as long as it's in sites/all/themes.

Even when the install_profile_api is correctly implemented in this way, if the theme is in profiles/hostmaster/themes/eldir, it'll still throw those array exceptions at the Finalise section of the install profile and present the user with a themeless drupal site. This themeless state is easily fixed by navigating to /admin and it rebuilds the theme registry or something I guess.

Example of those exceptions are pasted here

It's a tricky one. I guess the code above would avoid those array exceptions, but it in my opinion it's still a better result to put the theme in sites/all/themes, thus taking out 'nasty hack' code, correctly implementing the install profile api, theme gets detected and enabled as default, and everything 'just works'.

anarcat’s picture

anarcat commented

Regarding #2, 1) is good, a great workaround for the time being. 2) is a hack i don't think we should use. 3) i'm not formally against, but I don't actually remember why we're so adamant at putting all in profiles/hostmaster/*. Vertice could clarify this issue.

omega8cc’s picture

omega8cc commented

@anarcat

"why we're so adamant at putting all in profiles/hostmaster/*"

Good question! I was curious why it is there and not in a standard directories tree.

~Grace

Anonymous’s picture

Anonymous (not verified) commented

@ Grace, I've a feeling it's a 'recommended' or 'best practice' for installation profiles to put their dependencies in subdirectories of the profile but unsure why. If anything it feels like it 'scatters' the filesystem with modules and themes all over the place, and right now it causes more harm than good :)

Hopefully yes Vertice has the knowledge

jonhattan’s picture

jonhattan
Primary language Spanish
Location Plasencia
commented

@omega8cc, @mig5: I think the practice to put install profiles dependencies in subdirectories of the profile is done to ensure the profile compatibility with modules (and themes) version in a multisite environment. It is equivalent to have modules (and themes) at sites/onesite/modules instead of sites/all/modules.

That said, I think currently the better solution is to put eldir inside `sites/aegir.example.com/themes` because this theme is designed for use with Aegir frontend. This require some refactoring to #553230: INSTALL.txt documentation fixes / changes / improvements as `sites/aegir.example.com` is created several steps later than eldir is downloaded.

In addition to eldir, admin_menu is in the "Checking out the optional components" section.
Those can be moved below to "Install the Drupal" section. And admin_menu should be placed in sites/all/modules (it is not a dependency for hostmaster but a recomendation).

anarcat’s picture

anarcat commented

So this is what Vertice has to say about it:

17:31:22 <@Vertice> (which is why i dont like the modules / themes outside of the profile)
17:31:30 <@Vertice> it becomes much harder to package and maintain

The idea is that it's better to have all the modules/themes/profiles in one directory so it can be installed/moved around more easily. Now because of #330297: Themes in profiles directory not discovered during install, we are considering putting the theme in sites/all, but there's a workaround for that bug in the profile that triggers this very bug here.

In addition to eldir, admin_menu is in the "Checking out the optional components" section.
Those can be moved below to "Install the Drupal" section. And admin_menu should be placed in sites/all/modules (it is not a dependency for hostmaster but a recomendation).

Now, admin_menu needs to be available *before* the install profile is ran, because if it's available it will do something with it. I'm not sure it makes sense to keep admin_menu in profiles/ though, since it's so useful to everybody... And if it's really too much trouble (for now) i'm open to keeping eldir in sites/all too (we could even make it the default theme for created sites, although that could create a lot of confusion).

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Needs work

To update the ticket: anarcat's committed some documentation to INSTALL.txt to advise the user not to re-secure their settings.php at the advised step until the following step, and the reasons why, which I agree should get us through this for the time being.

omega8cc’s picture

omega8cc commented

Hmmm.. I am not convinced.

As far it seems that keeping dependencies in a profile sub-dirs doesn't solve any problems and even generates some new problems.
It starts to be extremely confusing (especially for new users) when they read about some dependencies located here and some there etc. I don't get it how it makes anything easier to anyone.

@jonhattan says it can be associated with "to ensure the profile compatibility with modules (and themes) version in a multisite environment".

Well, multisite inside an Aegir tree? Madness! :-)

Maybe I missed something, but I never use an Aegir tree to anything besides Aegir itself. All sites lives inside their Platforms and Aegir tree is not used as a Platform at omega8.cc.

I do understand people could be crazy enough to use Aegir tree as Platform for users space, but even in such a case what incompatibility is possible? Multiple copies of Aegir related modules?

Honestly, I believe it would be better to follow standard locations in sites/all/* and sites/aegir.example.com/* and not in a profile "hidden" subdirectories.

"Less is more" :-)

~Grace

jonhattan’s picture

jonhattan
Primary language Spanish
Location Plasencia
commented

"Less is more" and "explicit is better than implicit". So I should be more explicit to not be tagged as crazy.

@omega8cc: an "Aegir tree" is a multisite environment. Well, really a platform is a multisite environment. In a multisite environment you can have several versions of modules: some of them in sites/all/modules and other ones in sites/*/modules. To ensure a profile continue working whatever you do in sites/{all,*}/modules the profile modules in their profile-compatible version are put in profiles/*/modules. As you can guess you can have several profiles living with no conflict within the same multisite environment (or platform in Aegir's terminology). profiles/*/{modules,themes} is not a hidden place but a standard location as other drupal locations.
Here is a illustrative example: http://drupal.org/node/509398#comment-1854326

In my previous comment I was speaking --as a side note-- about profiles not about aegir's-usage-of-profiles, and it was not related to the bug this issue is about. About this issue --perhaps being contradictory-- my opinion (#7) was to put admin_menu and eldir in sites/all/modules and sites/aegir.example.com/modules respectively because those modules are suggestions and no requirements for the profile (as stated by the documentation) but I'm not an Aegir hacker to know what should happen behind the scenes (if the profile takes advantage of some admin_menu api or whatever).

"Special cases aren't special enough to break the rules." ;)

anarcat’s picture

anarcat commented

I agree with johnattan here: aegir must be able to run alongside other sites. I admit that I also reserver the platform for aegir and try not to use it for other things, but that's a precaution really, and if installing other sites on the aegir platform creates problems, that's a bug and a critical one at that.

So modules should be able to go in profiles/hostmaster/modules and same for themes. That the Drupal core can't handle it is a drupal core issue, and that issue should be fixed (I think it's even a regression in Drupal 6).

Please lobby to get #330297: Themes in profiles directory not discovered during install in D6 (although the patch needs to be fixed...). Once that hits core, we can remove our hack and close this damn ticket. :)

Anonymous’s picture

Anonymous (not verified) commented

See my latest comment on that thread #330297-9: Themes in profiles directory not discovered during install - the earlier patch fixes this issue, meaning we have a potential solution finally!

Basically I applied that earlier patch by stefan-agaric to a copy of Drupal-613, commented out the above function that I quoted and the call to it on line 89 of hostmaster.profile in HEAD (on a purely HEAD install of the aegir components), tested a fresh install and it worked perfectly. This means eldir can stay in profiles/hostmaster/themes/ etc with no problems thanks to this patch, and it eliminates the 'trickery' as I call it, of requiring writable access to the settings.php one step further than is normal.

Please test and confirm as above, and do push for this to make it into core, it solves this entire ticket!

jonhattan’s picture

jonhattan
Primary language Spanish
Location Plasencia
commented

Another option: current hostmaster.profile workaround works quite well if settings.php is owned by www-data so drupal is able to set it readonly. That is, it will not bring up

All necessary changes to %dir and %file have been made, so you should remove write permissions to them now in order to avoid security risks.

but

All necessary changes to %dir and %file have been made. They have been set to read-only for security.

... and then hostmaster will be able to set it readwrite again, do the change and revert back to readonly. The only issue is that the file is owned by www-data and not by aegir.

adrian’s picture

adrian commented
Status: Needs work » Needs review

i committed a fix to HEAD, i now write the value to setting.php in the form_alter on the install_configure form, before the message to change the perms is actually displayed.

Anonymous’s picture

Anonymous (not verified) commented

Tested and confirmed it works as expected. I chmod back to a protected state and no conflicts after the message is advised.

adrian’s picture

adrian commented
Status: Needs review » Fixed

closing

Status: Fixed » Closed (fixed)

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

  • Commit f3586b4 on 599758_edit_main_site, 640952_client_preview, dev-dns, dev-features, dev-headless_install, dev-log_directory, dev-migrate_aliases, dev-multiserver-install, dev-newsiteform, dev-nginx, dev-platform_management, dev-ports, dev-purgebackup, dev-relationships, dev-restore, dev-server_nodetype, dev-services, dev-site_rename, dev-ssl, dev_dns, prod-koumbit, ssl, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-588728-views-integration, dev-1403208-new_roles, dev-helmo-3.x authored by adrian: 
    #534302 - write install profile to settings.php before displaying the...

  • Commit f3586b4 on 599758_edit_main_site, 640952_client_preview, dev-dns, dev-features, dev-headless_install, dev-log_directory, dev-migrate_aliases, dev-multiserver-install, dev-newsiteform, dev-nginx, dev-platform_management, dev-ports, dev-purgebackup, dev-relationships, dev-restore, dev-server_nodetype, dev-services, dev-site_rename, dev-ssl, dev_dns, prod-koumbit, ssl, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-588728-views-integration, dev-1403208-new_roles, dev-helmo-3.x authored by adrian: 
    #534302 - write install profile to settings.php before displaying the...