IT Development/Doc: Difference between revisions

From Wikimedia UK
Jump to navigation Jump to search
(→‎Nginx: add)
(→‎Nginx: also)
Line 31: Line 31:
==Nginx==
==Nginx==


Very easy to configure using files, but an automated tool is also installed. [http://wiki.nginx.org/Configuration Configuration guide for Nginx].
Very easy to configure using files, but an automated tool is also installed. [http://wiki.nginx.org/Configuration Configuration guide for Nginx]. If you change any Nginx configurations please commit them to the repository. In /etc/nginx, as root, run:
 
hg commit -m "<notes about what you have changed>"
hg push
 
''Before'' you make changes, ensure that no existing updates are available (again run as root in /etc/nginx):
 
hg pull && hg update


===Enable/Disable vhosts===
===Enable/Disable vhosts===

Revision as of 11:51, 8 April 2013

IT Development
Main pageInfrastructureDocumentation / ToolsPortfolioTechnology CommitteeProject requests


This page documents how to configure or otherwise manage the WMUK servers.

Overview

The servers run:

  • PHP 5.x
  • MySQL
  • Nginx (web server)

Paths

/etc/nginx

Nginx config path. Core vhosts are stored in /etc/nginx/sites-available. It is recommended not to touch these as they are in version control (SCM: config/nginx). Website vhosts can be configured with the tools detailed below.

/var/www

Root path for websites etc. Each virtual host will be given a sub-directory (with the name of the domain, see below).

Tools

Nginx/vhost management tools are stored on the SCM, using Mercurial, under config/Nginx-Config.

generate_vhost

Used to set up new virtual host domains based on skeleton files. See below.

nginx_ensite/nginx_dissite

Core tool for managing the master nginx configurations, should be rarely needed

htpasswd.py

Used to generate htpasswd files for HTTP basic auth (when the normal htpasswd tool is unavailable). Again, rarely needed.

Nginx

Very easy to configure using files, but an automated tool is also installed. Configuration guide for Nginx. If you change any Nginx configurations please commit them to the repository. In /etc/nginx, as root, run:

hg commit -m "<notes about what you have changed>"
hg push

Before you make changes, ensure that no existing updates are available (again run as root in /etc/nginx):

hg pull && hg update

Enable/Disable vhosts

Vhosts should be configured in /etc/nginx/sites-available, please name the file after the domain name (e.g. wikimedia.org.uk) for ease of reference. In general, all configurations for sub-domains should go into the top level domain vhost - but for more complex configurations it is often easier to split them up.

Always user nginx_ensite to then enable the domain (e.g. nginx_ensite <domain name>, then nginx reload) as this will check the config file syntax and correctly set up the symlink.

Using the generate_vhost tool

In a console run:

sudo generate_vhosts

It will ask you for the domain name you are hosting, and also to type in the public IP of the server (it will remind you). It will create a directory /var/www/<domain name> and copy a skeleton configuration into it. Then run:

sudo service nginx reload

This reloads the nginx config; if you see errors contact Tom.

Source code for the tool: Nginx-Config in the SCM

.htaccess??

.htaccess is a system of Apache web server most often used to do URL rewriting. Nginx does not support this method. If you have a .htaccess file then set up the vhost using the above tool then ping Tom who will convert the .htaccess to Nginx format.

Source Control

The Wikimedia UK source control server is located on Confidential at http://scm.wikimedia.org.uk. The management interface is Rhode Code. The server is capable of hosting repositories using either Git and Mercurial Distributed Version Control Software (DVCS).

SFTP access

Sometimes individuals may need access to the servers for updating files etc. No FTP server is installed, instead each individual should have a local user account placed in a chroot jail (to restrict their access) with SSH login disabled. The basics are; there is a user group called sftpusers which is configured in /etc/ssh/sshd_config to jail its users to /sftp/<username>. Add users to this group and and set their shell to /bin/login to enable SFTP only access.

useradd -g sftpusers -s /sbin/nologin <username>
mkdir /sftp/<username>

(the user will not have write permission to their jail root (/sftp/<username>) so you will have to create & chown their writable directories for them. e.g.

mkdir /sftp/<username>/<directory>
chown <username>:sftpusers /sftp/<username>/<directory>

Log in over SFTP to check access is jailed to the right directory.