Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 1.5.4, 1.6.6, 1.7.4
    • Fix Version/s: 1.6.7, 1.7.5
    • Component/s: Installation
    • Labels:
      None
    • Environment:
      Linux
    • Database:
      MySQL
    • Affected Branches:
      MOODLE_15_STABLE, MOODLE_16_STABLE, MOODLE_17_STABLE
    • Fixed Branches:
      MOODLE_16_STABLE, MOODLE_17_STABLE
    • Rank:
      27553

      Description

      The installation process relies on performing PHP fopen requests on several URLs. These tests assume that the relevent URLs can be read via the webserver.

      This is not a valid assumption in all working moodle installations. I have just installed moodle on a web hosting service that requires all executable scripts to be unreadable by the apache process. This arrangement appears to be a security measure implemented using the apache suexec module. The net effect is that install.php can be browsed correctly, but fopen on its url does not work.

      It is relatively easy to get around this installation problem by removing the relevent tests from the PHP, since this has no effect on the later operation of the site. However, it does call the logic of doing these tests into question.

      Checking that install.php can be read from the site URL is a poor test. For example, it would succeed if the installer specified the URL of the wrong moodle site (e.g. http://moodle.org/). Furthermore, it might fail incorrectly on carefully secured servers. Why not make it clear to the installer that the installation should be conducted via the URL intended for the live system and rely on the apache environment to get the URL right?

      The check on admin/site.html might fail for similar reasons, though it serves a different purpose. Here, I would inclined to avoid the whole problem by changing the default location of the moodle admin directory in the distribution. Given that the few installers who need to correct the problem have to change the directory structure of the distribution in any case, it might be better to leave them to edit the config.php file by hand. I would imagine that the attempt to automate this part of the installation process creates more confusion than it avoids.

      Felix

        Activity

        Hide
        Nicolas Connault added a comment -

        This was fixed in 1.8 and above, but still remains to be applied to 1.5, 1.6 and 1.7

        Show
        Nicolas Connault added a comment - This was fixed in 1.8 and above, but still remains to be applied to 1.5, 1.6 and 1.7
        Hide
        Nicolas Connault added a comment -

        Fixed in 1.6 and .1.7

        Show
        Nicolas Connault added a comment - Fixed in 1.6 and .1.7
        Hide
        Mathieu Petit-Clair added a comment -

        /lib/deprecatedlib.php doesn't exist in Moodle < 1.7 .. this is breaking the install process in 16. http://moodle.org/mod/forum/discuss.php?d=89237

        Show
        Mathieu Petit-Clair added a comment - /lib/deprecatedlib.php doesn't exist in Moodle < 1.7 .. this is breaking the install process in 16. http://moodle.org/mod/forum/discuss.php?d=89237
        Hide
        Mathieu Petit-Clair added a comment -

        I removed the requirement for deprecatedlib.php in 1.6.

        Show
        Mathieu Petit-Clair added a comment - I removed the requirement for deprecatedlib.php in 1.6.
        Hide
        Nicolas Connault added a comment -

        I assume that this can be closed now

        Show
        Nicolas Connault added a comment - I assume that this can be closed now

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: