2

I created a Drupal 7 site with Sqlite on my dev machine. When I go to localhost/install.php it says: Drupal is already installed.

After deploying the whole bunch to shared hosting (windows) the install.php is available again although the site works. It is even available to anonymous users and when the site is in maintenance mode. What should I do to disable that? Or should I deploy another way?

2

What the installer checks for, is whether or not the settings file has database information for the site.

While this sounds simple in theory, and shouldn't lead to install.php being executed, there are many components involved.

  1. There's DNS, which may or may not respond to various sub-domains.
  2. There's the webserver configuration, which may or may not serve sub-domains, and may or may not re-write them before they hit Drupal.
  3. Drupal, since 7, supports a sites.php file which can map domains to sites/ directories.
  4. Finally, there's the sites directory itself, where Drupal can find a settings.php file, check for a valid $db_url, and decide whether or not to allow installation.

Due to the many components, and the technical complexity of setting them all up right, it's very easy to end up in a situation where install.php decides to allow installation. This should generally not be a problem, as anonymous users should not be able to create new databases, but it looks quite wrong regardless.

While removing install.php is a solution, it's technically hacking core, and makes future deployments needlessly complicated.

I normally do two things to counteract this.

The first thing is to run the site from a directory named after the domain, such as sites/example.com/ and make sites/default a link to the main site. This way, any unexpected domains being requested by Drupal will be served by the main domain.

Second, I always just block access to install.php completely on any production systems with this vhost file:

# ssh -L 8080:127.0.0.1:80 example.com
<Location /install.php>
  Deny from all
  Allow from 127.0.0.1
</Location> 

<Location /update.php>
  Deny from all
  Allow from 127.0.0.1
</Location>

This ensures apache blocks access to both install and update. The comment at the top is a reminder for how I can open an ssh tunnel to the server so my traffic looks like it's coming from 127.0.0.1, thus allowing developers access to run update.php.

Something similar in IIS below. Note that I have not tested this. Someone with ISS experience, please update or comment so I can improve this part.

<location path="install.php">
    <system.webServer>
        <security>
            <authorization>
                <remove users="*" roles="" verbs="" />
                <add accessType="Allow" roles="Administrators" />
            </authorization>
        </security>
    </system.webServer>
</location>
  • Windows - IIS hosting... – Koen May 28 '12 at 10:04
  • Added IIS example. – Letharion May 28 '12 at 10:15
  • I'm sorry but this simply doesn't explain why install.php is even available and how to resolve the real cause. It is not supposed to serve the installation wizard when the site is already installed. – Koen May 29 '12 at 8:57
  • Significantly expanded the answer with more information. – Letharion May 29 '12 at 12:21
0

One way is just to delete the install.php file altogether. Another option is to set permissions on the file so that it is unusable by the user that providing content through apache (presumably)

  • Windows - IIS hosting... – Koen May 28 '12 at 10:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.