Ubuntu VPS Administration
From Freelock Knowledge Base
We have a growing number of clients who have a virtual private server (VPS), which we administer on their behalf. This page is meant to provide some hints to people less familiar with Linux, who have some simple, repeating tasks to do.
Where you see code snippets below, they should be typed into a shell (command line) on the server. So the first step is fire up Putty, OpenSSH, or a terminal shell and use SSH to connect to your server.
Things you type will be shown after a prompt. The prompt ends with either "$" if you're running as a normal user, or "#" if you're running as root. Here are some example prompts:
freelock@baker:~$ freelock@baker:/var/www$ root@baker:/var/www#
In this example, the prompt shows the user account you're logged into, the servername, and your current directory.
So the command you type appears after the $. The response will appear on following lines.
A key command to use is "sudo". Sudo allows you to run administrative commands as the root user (the superuser) without running as root constantly. It is possible to switch to the root account, if you're going to run a bunch of administrative commands in a row. But Freelock, Ubuntu, Apple, and many others all strongly recommend staying as a normal user and simply using sudo whenever necessary, because it protects you from doing significant damage if you make a mistake.
Contents |
[edit] Add a new user
These instructions are specifically for Ubuntu--the adduser command works differently on other distributions.
freelock@servername:~$ sudo adduser ken
Adding user `ken'...
Adding new group `ken' (1003).
Adding new user `ken' (1003) with group `ken'.
Creating home directory `/home/ken'.
Copying files from `/etc/skel'
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for ken
Enter the new value, or press ENTER for the default
Full Name []: Ken
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [y/N] y
That creates the user account, and the user should be able to log in now using SSH and SFTP.
Next, add the user to the Web group:
freelock@server:/var/www$ sudo adduser ken web Adding user `ken' to group `web'... Done.
That's it!
[edit] Add user to Subversion
Subversion uses Apache to authenticate users. You don't have to have a Unix user account to have a Subversion account--you can create accounts that allow users to check out your code from Subversion without giving them any access to the server. Likewise, creating a Unix user account does not automatically grant Subversion access.
So the first thing to do is find the htpasswd file that contains the user credentials for Subversion. We have several different places we might store this file:
- in /etc/subversion/passwd
- in /var/svn/repositoryname/htpasswd
- in /var/www/conf/something.htpasswd
These depend largely on whether we set up the authentication to be shared across all subversion repositories on the server, one single repository, or in some arbitrary password file we've created to password-protect other directories in Apache. The Apache configuration for Subversion will point to the one in use, or you can call and ask us.
Once you know which password file to manage, the Apache htpasswd command will add or change the password for the user:
$ sudo htpasswd /etc/subversion/passwd ken
[edit] Change password
Any user logged into a Unix system can change their password with the passwd command:
freelock@server:~$ passwd Changing password for freelock (current) UNIX password: Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully
- Note that the shell hides each password as you type it, it is never visible.
- Also note that this only affects logins for SSH and SFTP, not for Subversion or WebDAV. Those need to be changed by an administrator, or anyone with write access to the relevant htpasswd file.
To change another user's password, you can run this command as root:
freelock@server:~$ sudo passwd dave Enter new UNIX password: Retype new UNIX password:
- Note that in this case, I've used sudo in the past few minutes, so it's not asking for my password. Usually if this is the first time you've typed "sudo" in the last 5 minutes, it will first ask you for your password, for permission to use the root account. If it does this, the first line you see will be:
Password:
... not
Enter new UNIX password:
[edit] Create new Apache virtual host, for a developer copy
This can get tricky. Please call us if you need assistance for a server we're administering for you.
For our customers using Subversion to manage different developer copies, there are a number of quirks with Subversion that basically make it difficult for people to share a working copy. There are basically two approaches here:
1. Have one developer (or manager) with administrative access manage the working copy. In this case, before doing any subversion updates or commits, you need to change ownership of the entire directory and subdirectories to your account. You'll also want to make sure all files are group-writable, and owned by the web group. Here are steps to do this:
$ sudo chown -R freelock:web /var/www/siteroot $ chmod g+w -R /var/www/siteroot
With this arrangement, anyone you add to the "web" group should be able to edit/add files to that site. But new files they create won't necessarily have the correct group access. This can be corrected by them by running the "chmod g+w filename" command--but this only works for files they own. If they're working through a shell, editing directly on the server, running this command will make it so they create files with group write access by default:
$ umask 002
This only works for the current login. They can add it to their .bashrc or .bash_profile to make it more permanent, or we can change the login default for you.
... or, the other approach:
2. Have different working copies for each developer. This is the "real" way developers work, but there's a bit more administrative overhead. If your developers have a development environment on their own machines, this is definitely the most convenient way to work, because they can simply check out code to their server (or laptop) and work on it completely offline. If you want to give them a working copy on the server, you'll essentially need to set up a new "virtual host" in Apache for each developer who wants to work directly on the server.
This arrangement is very valuable if a developer needs to work on a "branch" of the code, for example to work on a feature that's going to take a while to create while other developers are working on the "trunk" or main site. Subversion is your arbitrator here, helping you manage and merge changes from multiple developers.
[edit] Configure Virtual Host
These steps are for Debian/Ubuntu installations, which have a set of tools for enabling/disabling virtual domains. Ubuntu virtual domain configurations are stored in /etc/apache2/sites-available, and are enabled/disabled using a couple special commands: a2ensite and a2dissite. You need to use an editor to edit configuration files to add a new virtual host. The popular Unix editors are vi and emacs, both of which are pretty ubiquitous, and both of which are particularly unfriendly to new users. They are both extremely powerful once you learn how to use them. If you don't plan to spend much time in a Unix shell, ask us to install nano for you, which shows you the available control commands on the screen and is quite a bit easier for new users. So to edit a file for Apache, you can use any of these commands:
$ sudo vi /etc/apache2/sites-available/sitename $ sudo nano /etc/apache2/sites-available/sitename $ sudo emacs /etc/apache2/sites-available/sitename
1. First, configure DNS for your new virtual host. If you're going to do many of these, ask us to set up a Wildcard Domain for you, so you don't need to add more domains. We typically run DNS for our clients, and do not provide client access to this.
2. Next, create the directory for the working copy:
$ sudo mkdir /var/www/ken $ sudo chown ken:web /var/www/ken $ sudo chmod 2775 /var/www/ken
3. Next, check out the code for the site from Subversion. We do this now because for most custom sites, we try to keep the core logic of the site out of the web root, so the actual web root we want to use is somewhere inside the code.
4. Create the Apache config, as a new file inside /etc/apache2/sites-available.
freelock@server:~$ sudo nano /etc/apache2/sites-available/ken
<VirtualHost *:80>
ServerName ken.domain.com
DocumentRoot /var/www/ken/public_html
</VirtualHost>
5. Enable the new site:
$ sudo a2ensite ken
6. Restart Apache:
$ sudo /etc/init.d/apache2 reload
