Warning message

Documentation is currently being migrated into the new system. Some pages might be temporarily missing, and some guides might appear empty. Thank you for your patience while we are improving Drupal.org documentation.

OS specific download notes

Last updated on
September 16, 2016 - 13:06

Follow the links below to download and install Drupal 7 on specific operating systems:

OS X download notes

If you are installing on a Mac server, or are creating a test site on your Mac, you may also want review these handbook pages during installation:

Windows download notes

Note: By default, Windows cannot uncompress files saved in the .tar.gz format. This page assumes that you've downloaded and installed the freely available 7-Zip utility to extract .tar.gz files. A number of other file compression utilities are also available.

To download Drupal on your Windows computer:

  1. On the Drupal project download page find the version that you want to download. In this case, select the first Drupal 7 version under the section 'Official Releases.' Click Download and save the file without opening it.
  2. Right-click the .tar.gz Drupal installation file, and then select 7-Zip >> Extract here.

    The utility extracts a .tar file.

  3. Right-click the .tar file, and then select 7-Zip >> Extract here.

    You will now see the final Drupal folder. Drag the folder to where you need it to be in the file hierarchy.

    Notes:

    • If you extract the files into a folder other than your web site's folder, copy the contents of the Drupal folder into the appropriate web folder, rather than cutting/pasting them. (This will ensure the files will inherit the appropriate permissions for the web server.)
    • If you're using Apache instead of IIS, skip the remaining steps on this page.
  4. In the sites/default folder, create a folder called files and grant modify permissions for it to IIS_WPG (IIS6) or IIS_IUSRS (IIS7).
  5. Drupal distributions come with .htaccess files for *nix use. IIS7 users should convert this file to a web.config file for their site. If you have used the IIS Manager to create a new site, a basic web.config file will exist in your site's root directory. Edit the file to look like this example:

<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <!-- Don't show directory listings for URLs which map to a directory. --> <directoryBrowse enabled="false" /> <!-- Caching configuration was not delegated by default. Some hosters may not delegate the caching configuration to site owners by default and that may cause errors when users install. Uncomment this if you want to and are allowed to enable caching --> <!-- <caching> <profiles> <add extension=".php" policy="DisableCache" kernelCachePolicy="DisableCache" /> <add extension=".html" policy="CacheForTimePeriod" kernelCachePolicy="CacheForTimePeriod" duration="14:00:00" /> </profiles> </caching> --> <rewrite> <rules> <!-- rule name="postinst-redirect" stopProcessing="true"> <match url=".*" /> <action type="Rewrite" url="postinst.php"/> </rule --> <rule name="Protect files and directories from prying eyes" stopProcessing="true"> <match url="\.(engine|inc|info|install|module|profile|test|po|sh|.*sql|postinst.1|theme|tpl(\.php)?|xtmpl|svn-base)$|^(code-style\.pl|Entries.*|Repository|Root|Tag|Template|all-wcprops|entries|format)$" /> <action type="CustomResponse" statusCode="403" subStatusCode="0" statusReason="Forbidden" statusDescription="Access is forbidden." /> </rule> <rule name="Force simple error message for requests for non-existent favicon.ico" stopProcessing="true"> <match url="favicon\.ico" /> <action type="CustomResponse" statusCode="404" subStatusCode="1" statusReason="File Not Found" statusDescription="The requested file favicon.ico was not found" /> </rule> <!-- To redirect all users to access the site WITH the 'www.' prefix, http://example.com/... will be redirected to http://www.example.com/...) adapt and uncomment the following: --> <!-- <rule name="Redirect to add www" stopProcessing="true"> <match url="^(.*)$" ignoreCase="false" /> <conditions> <add input="{HTTP_HOST}" pattern="^example\.com$" /> </conditions> <action type="Redirect" redirectType="Permanent" url="http://www.example.com/{R:1}" /> </rule> --> <!-- To redirect all users to access the site WITHOUT the 'www.' prefix, http://www.example.com/... will be redirected to http://example.com/...) adapt and uncomment the following: --> <!-- <rule name="Redirect to remove www" stopProcessing="true"> <match url="^(.*)$" ignoreCase="false" /> <conditions> <add input="{HTTP_HOST}" pattern="^www\.example\.com$" /> </conditions> <action type="Redirect" redirectType="Permanent" url="http://example.com/{R:1}" /> </rule> --> <!-- Rewrite URLs of the form 'x' to the form 'index.php?q=x'. --> <rule name="Short URLS" stopProcessing="true"> <match url="^(.*)$" ignoreCase="false" /> <conditions> <add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" /> <add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" /> <add input="{URL}" pattern="^/favicon.ico$" ignoreCase="false" negate="true" /> </conditions> <action type="Rewrite" url="index.php?q={R:1}" appendQueryString="true" /> </rule> </rules> </rewrite> <!-- httpErrors> <remove statusCode="404" subStatusCode="-1" /> <error statusCode="404" prefixLanguageFilePath="" path="/index.php" responseMode="ExecuteURL" /> </httpErrors --> <defaultDocument> <!-- Set the default document --> <files> <remove value="index.php" /> <add value="index.php" /> </files> </defaultDocument> </system.webServer> </configuration> 

Further reading available at: http://chrislarson.me/blog/installing-drupal-iis-microsoft-sql.html & http://www.drupalonwindows.com/en/blog/installing-drupal-windows-and-sql-server

SELinux download notes

To install on a Fedora-based distro (RHEL, CentOS, etc.) there are two main options:

  • Install from the repository through a yum install drupal command. (In Fedora 23, it is dnf install drupal7)
  • Install it yourself.

The installation instructions will vary a bit depending on your choice, as will the version you wind up with in some cases.

To be compliant with FHS guidelines on architecture independent system components (http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY) vs transient data placement (http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY) and to enforce Fedora-ish system segregation Fedora and its derivatives place the code part of systems like Drupal and WikiMedia in /usr/share and the data elements (like files/ and images/) in /var/www. These parts are bound together through a series of symlinks, as the original development concept behind Drupal and other such systems did not take the FHS into account (there is a pretty big generation/culture gap between core Unix developers and web developers -- and embedding code to this extent inside of what used to be public data files (.html files becoming .php files and totally bypassing cgi-bin) was never thought of when the FHS was originally conceived). This can be confusing for newcomers.

In either case, the placement of the Drupal code (all those .php files) in the filesystem is irrelevant to the function of SELinux. Apache's daemon, httpd, has a context group within the Fedora SELinux policy structure. Any files or directories that Apache needs to interact with must be placed in an httpd_* type context. Yum will handle this for you if you do a yum install drupal install and the stickiness of the /var/www filesystem hierarchy will do it for you if you unpack it directly into a sub-directory there. However, installation cases outside of this where SELinux is set to enforce but the default SELinux policies are either grossly underdeveloped (Ubuntu, for example) or nonexistant (Slackware / LFS + SELinux -- yes, some people do this) will have to make the change on their own:


chcon -R -t httpd_sys_content_t /path/to/drupal/files 

The other area where SELinux can trip one up is basic policy permissions for allowing Apache to do things like send email (to prevent compromised systems from becoming proxy spam-generators -- a problem far more common than most Ubuntu new administrators seem to be aware), make calls across network sockets to database servers (a wonderful way to bypass password protections and steal user data from a site), or directly alter files on behalf of scripts (an entry to the first two). To enable this small list of abilities but keep your system otherwise locked down with an SELinux policy set to "enforce" run the following three commands:


# setsebool -P httpd_can_network_connect_db=1 # setsebool -P httpd_can_sendmail=1 # setsebool -P httpd_unified=1

Unfortunately, in an excited rush to get things up quickly most people who opt for the increased security that SELinux provides by choosing a Fedora-based distro usually toss all their gains at the first sign of SELinux conflicts by turning SELinux off instead of digging further (because learning 4 more file security attributes is hard -- and admittedly, SELinux is rarely explained so simply in currently available resources).

Outside of granting Apache permission to do things Drupal needs to work correctly (those three setsebool commands) and then telling SELinux where these permissions should apply (the chcon command above), the installation process is no different from any other system. It is useful to remember if you run into an FHS-compliant installation where /var/www/html/drupalxx is largely empty but for a few symlinks and data folders (like config/) that all of the code is over in /usr/share and conceptually nothing has really changed.

Also, if you use LDAP, you may be interested:
# setsebool httpd_can_connect_ldap on

tl;dr reference on rpm-based Systems: http://zxq9.com/archives/442