The standard installation process doesn't agree with the INSTALL.txt instructions.

On a standard linux system, following the exact sequence of instructions always results in an X and the message "The settings file does not exist."

This is unfortunate. Since, as instructed, the directory is by this point writable, the system should be able to copy default.settings.php without user involvement.

Failing that, the instructions should tell one to create it before telling one to run the installation script. Getting everyone to inevitably view an error message doesn't reflect well on what is actually a remarkably good system.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pyrollo’s picture

I've just given a try on my Ubuntu laptop and it worked without problem.

Here what I did :

  • downloaded Drupal 7.0-rc2
  • uncompressed it under the apache document root directory
  • changed the permission to be sure apache can write (chown www-data and chmod u+rw recursively on all files and directories)
  • went to site front page
  • chose "standard" installation
  • chose "english" language
  • got on the mysql page (beyond possible message about settings.php)

At this point, settings.php has been created.

David_Rothstein’s picture

Title: Doesn't create settings.php file » Explain in INSTALL.txt that on some servers, the automated settings.php creation isn't expected to work
Version: 7.0-rc2 » 7.x-dev
Component: install system » documentation

...changed the permission to be sure apache can write (chown www-data and chmod u+rw recursively on all files and directories)...

Yes, but that is something people don't do if they want a secure server setup :)

I think we could probably improve the INSTALL.txt documentation a bit here, to point out that automated creation of settings.php is only really expected to work on some systems (typically shared hosting, where the webserver user owns the Drupal files).

The documentation already explains what to do if settings.php wasn't auto-created, but seems to imply that that will only happen if something went wrong, which isn't true. The main problematic sentence is this:

   During installation, several files and directories need to be created, which
   the installation script can do automatically if the web server has write
   permission on the sites/default directory. 

That's not really correct. Having write permissions is enough for the webserver to do some things, but not to auto-create settings.php.

There are plenty of technical details in the code comments as introduced in #418302: Copy default.settings.php to settings.php during install IFF webserver owns files (FTP on shared hosting) but we could probably use a one-sentence summary of this issue in INSTALL.txt.

jhodgdon’s picture

I don't understand. If the web server has write permission on sites/default, what would cause it to not have permission to create settings.php?

That issue you referenced has over 100 comments -- can you provide a summary?

droplet’s picture

won't get pass if you only have permission for sites/default dir. you should modify default.settings.php permission.

chown www-data sites/default/default.settings.php

jhodgdon’s picture

That is incorrect. The web server does not need write permission on the default.settings.php file in order to copy it and name the copy settings.php, which is what it does.

I have never had problems if I made the sites/default directory everyone-writeable before starting the install process, which is what the install.txt file says to do, and I still don't understand why the server would need anything but permission to write to that directory.

David_Rothstein’s picture

If sites/default is writable, the webserver is able to create settings.php, but Drupal still won't do it automatically.

That is for security reasons (a PHP file owned by the webserver means the webserver can later append code to it) and maintainability reasons (the person who owns the site needs to be able to log in to the server and edit settings.php later).

Drupal 6 stopped there. Drupal 7 will go ahead and write settings.php only on servers that already have webserver-owned files, where the security weakness is pre-existing and where the maintainability issue is not a concern.

I will write a patch to INSTALL.txt later today. The suggestion in #4 (chown www-data sites/default/default.settings.php) would "work" but makes the server more insecure. We just need to clarify that creating settings.php manually is sometimes a required/expected part of the installation.

jhodgdon’s picture

Thanks for the clarification. Sounds like we should probably try to get this patch done/in before release?

David_Rothstein’s picture

Status: Active » Needs review
FileSize
6.89 KB

How about something like this?

It's a bigger patch than I expected, because as far as I can tell, step 4 of the installation instructions is kind of pointless. It's written as if it's a required step, but it's actually not necessary for many people who install Drupal on shared hosting; meanwhile, for servers where it is necessary, it is never (or at least almost never) sufficient. So to make my other changes sensible, I removed that step and incorporated what was there into the section after it.

jhodgdon’s picture

I'm OK with the approach of this patch. A few little things I would like to see changed (which may have been in the original file and not things you introduced, but anyway):

a) create a files storage directory ==> create a file storage directory

b) The most common steps you may need to perform are described below:
==>
The most common steps you may need to perform are:

c) To run the install script point your browser to the base URL of your website ...
==> [add comma]
To run the install script, point your browser to the base URL of your website ...

d) If auto-creation fails, you can enable it to work by changing permissions ...
==>
If auto-creation fails, you can make it work by changing permissions ...

droplet’s picture

@David_Rothstein

I agreed with your points.
but install.txt still said "Drupal will try to automatically create a settings.php"

users assume that Drupal will do everything for them.... if FAILED.... they would ask why failed and how to get pass without create it manually.

can we suggest them a way to pass it and change permission back to make sure it is secure.

Is it always insecure to create settings.php like #4 ??

David_Rothstein’s picture

Attached patch fixes the issues from #9.

@droplet, once we're at the point where someone has to go onto their server anyway, it's more straightforward to have them just copy the settings file themselves. This also matches the instructions they will see in the UI. (And keep in mind that many people don't have root access and therefore couldn't change the ownership of default.settings.php even if they knew which user to change it to.)

Status: Needs review » Needs work

The last submitted patch, install-txt-1003968-11.patch, failed testing.

jhodgdon’s picture

Status: Needs work » Needs review

I have filed an issue about the failing test (which obviously had nothing to do with this patch).
#1010764: Exception in test - can't create table in list.module test
If we don't hit "retest" then the test results will stay there for purposes of that issue, so please don't re-test!

I think this patch is pretty much good to go... but David can you explain why you changed the order of the common problems? It was previously (a) settings file (b) files directory and you changed it to (a) files directory (b) settings file. It seems like we should put them in order of most likely encountered, or the order in which the install script will report them. I think the settings file problem is detected before the files directory problem, isn't it? Maybe not... my test server isn't running at the moment to verify.

David_Rothstein’s picture

During installation, the files directory problem is actual reported before the settings problem - so that's why I switched the order.

In terms of which is most common, I'm relatively convinced that they're equally common... Unless you've done some work to mess around with your file system beforehand, seeing one should mean you will always see the other also.

jhodgdon’s picture

Status: Needs review » Reviewed & tested by the community

Sounds good then. Thanks!

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Committed to HEAD. Thanks!

Status: Fixed » Closed (fixed)

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