IT Development/Doc: Difference between revisions
(→Nginx: also) |
(→Enable/Disable vhosts: sp.) |
||
Line 44: | Line 44: | ||
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. | 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 | '''Always use 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=== | ===Using the generate_vhost tool=== |
Revision as of 11:51, 8 April 2013
IT Development |
Main page — Infrastructure — Documentation / Tools — Portfolio — Technology Committee — Project 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 use 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.