This guide is meant to serve as a comprehensive reference for setting up an Ubuntu slice. It was started by a fellow who started taking detailed notes after having hosed his slice multiple times. It won’t tell you how to do everything, but it should be enough to get most people started.
The guide is broken up into sections. Each is meant to be somewhat self-contained, although later sections may depend on the actions of previous sections.
This guide assumes you’re starting out with a brand new slice, loaded with Ubuntu (6.06 Dapper Drake edition). Hopefully you already know some command-line Linux and know how to operate an SSH client (like PuTTY). Your IP can be found in the SliceManager.
Finally, I pulled a lot of stuff from other guides in compiling this. Thanks to all the other developers out there for documenting your experiences! As a relative newcomer to VPS hosting, I can’t thank you enough.
Since your OS is running on a VPS with several other users, there is some competition for disk access. All users of a particular distro start out with the same times for the default cron jobs. Since approximately 80% of the VPSs at Slicehost run Debian or Ubuntu, the problem is compounded. Every day, 06:25 brings a detrimental impact to disk performance. You can help smooth this out by adjusting the times that your cron jobs run.
First, log in as root using the password you got in SliceManager. (If you’ve just rebuilt your slice, first you may need to delete the RSA key already on file for your IP address.)
Once you’re logged in as the root, change your root password with passwd. Don’t be too concerned about password ‘usability’, because you won’t be typing in this password much, if at all.
Now create your main user account. This is what you’ll be logging in with exclusively from now on. Give it a good strong password. You will be typing it in here and there.
adduser --ingroup users <username>
Next you need to give it permission to “sudo” (act as root). Run “visudo” and add the following line to the end (the editor is not vi but nano; press ctrl-o to save, ctrl-x to exit). It appears that users running Hardy (possibly other OSs too) may find the editor is vi, not nano. To use nano instead of vi, type :q to exit and “export EDITOR=nano” then type visudo again). Alternatively, to save and quit using the vi editor, hit Escape, then type “:wq” without the speech marks. This will write the changes to the file and will quit the editor. Using “:q” instead offers a prompt to confirm whether changes should be saved then quits the editor, while “:q!” quits without saving any changes. Further basic commands for the vi editor can be found here: http://www.cs.colostate.edu/helpdocs/vi.html
<username> ALL=(ALL) ALL
Now log out and log in as the other (non-root) user you just created. Make sure “sudo” works with the command sudo cat /etc/shadow. When prompted for a password, enter *your* password, not root’s! If you get about 20 lines of gobbly-gook, congratulations! You’re in business. If you get an error, don’t continue or you’ll lock yourself out of your account!
Now, let’s enhance our SSH security. For additional SSH security settings and discussion see the SSH article.
sudo nano /etc/ssh/sshd_config
Find the PermitRootLogin line and change it from “yes” to “no“. While you’re at it, find the Port line and change it from 22 to some four-digit number. Remember to mirror these changes in your SSH client! That oughta keep the bad guys off your tail... for a while. Reload the configuration with this command:
sudo /etc/init.d/ssh reload
Remember, if necessary, to add the new port rule to your firewall and to restart your server afterwards.
adduser --ingroup users <username> # you will be prompted for a password sudo echo "<username> ALL=(ALL) ALL" >> /etc/sudoers sudo perl -pi -e 's/(PermitRootLogin)\s+yes$/\1 no/g' /etc/ssh/sshd_config sudo perl -pi -e 's/(Port)\s+22$/\1 2288/g' /etc/ssh/sshd_config sudo /etc/init.d/ssh reload
Warning! Enabling SSH login without password authorization creates a significant hole in the security of your server. You should only authorize login without password from a secured computer, one that is either in your possession at all times, or that is protected from unauthorized users. You might also consider enabling login without password while setting up your server, and then removing it once it is up and running.
If you primarily use one computer to login and control your host, you may want to setup your server to accept SSH logins from that computer without having to enter a password each time. This method will create a key that is saved on both your home computer, and on your server. If the keys match, the server will allow you to login without using your account password.
On your home computer, generate an RSA key:
ssh-keygen -t rsa
Hit enter to accept the default options for all three questions that it asks.
Copy the key to your server. Use your new username and the Slice IP address where shown
scp ~/.ssh/id_rsa.pub USER@SLICEIP:~/
The catch – if you have changed your port number, you should be refused the connection. To solve this, issue the following command:
scp -P 2000 ~/.ssh/id_rsa.pub user@sliceip:~/
Enter your password when prompted.
Now login to your slice using a normal SSH login, including your password when prompted. Enter the following three commands on individual lines:
mkdir .ssh cat id_rsa.pub >> .ssh/authorized_keys rm id_rsa.pub
Change permissions to allow only the local server to see the shared key:
chmod go-w ~ chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
Now logout, and log back in to your slice. You should be able to do an SSH login without entering your password. This will also allow you to run programs that use the SSH protocol, such as rsync, to login without a password. If you would like to simplify the login process even more, add the following line to the ~/.bash_profile file on your local computer:
alias slice="ssh user@SLICEIP"
Now, simply typing “slice” in your terminal will automatically log you in to your slice server without having to enter any additional login or password data.
To remove the ability to login without a password, simply remove the file ~/.ssh/authorized_keys from your slice server.
rm ~/.ssh/authorized_keys
I’m assuming there are actually a few ways to get SSH going on Windows (PuTTY being one of them and using cygwin being another). The following instructions are only relevant for PuTTY (Release 0.60).
Download PuTTY and PuTTYGen here. Once you have it running, you will need to copy the .exe files to a known location.
Run puttygen. Select SSH-2 RSA and hit “Generate”. Move the mouse around in the “Key” area until the progress bar is complete.
PuTTYGen will generate a public key in the “Key” area. Select all the text (starts with “ssh-rsa”) and copy it to memory. Whilst you are at that dialog, select the “Save private key” button and type a name for the file. It might warn you about not having a passphrase, but that’s exactly the point, you want to use keys and not passwords - so ignore it.
Fire up PuTTY. Type in the following “login_name@host_ip” in the Host Name text box. Type in a name in the “Saved Sessions” text box and hit the save button. Expand the SSH node on the LHS and select “Auth”. Hit the “Browse” button and select the name of the file that you just saved as the private key file using PuTTYGen. Select “Session” on the LHS and hit the save button. Click the “Open” button. You will need to provide some credentials to log in. We are now about to setup the key at the server end.
mkdir .ssh echo "[right click mouse]" >> .ssh/authorized_keys
Note: right click pastes what is in the contents of the memory to the terminal in PuTTY, so make sure you have the key text selected from PuTTYGen. Change permissions to allow only the local server to see the shared key:
chmod go-w ~ chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
Logout and log back in using PuTTY. This time, you should see:
Authenticating with public key "rsa-key-XXXXXXX"
Incidentally, if you are using TortoiseSVN on Windows and you are getting sick of SVN asking for a password, you can use PuTTY to create the SSH connection settings (including SSH keys) and then in your connection string, use
svn+ssh://[name of session in PuTTY]/[path to repository]/
Tortoise will use the PuTTY settings (as named) to establish the connection, SSH keys and ports and all.
Ubuntu’s package management is done through apt-get. Alternatively, you can use the aptitude package manager in place of apt-get. Aptitude manages dependencies more effectively than apt-get when installing and removing packages. If you wish to use aptitude, simply use this term instead of apt-get.
In either case, the package manager has only the basic repositories and settings to begin with. You need to edit a config file to add some additional sources:
sudo nano /etc/apt/sources.list
Uncomment these lines (remove the “# “):
# deb http://us.archive.ubuntu.com/ubuntu/ dapper universe # deb-src http://us.archive.ubuntu.com/ubuntu/ dapper universe ... # deb http://security.ubuntu.com/ubuntu dapper-security universe # deb-src http://security.ubuntu.com/ubuntu dapper-security universe
Now update the repository index and upgrade your built-in software:
sudo apt-get update && sudo apt-get upgrade
sudo perl -pi -e 's/#\s?(.*dapper universe$)/\1/g' /etc/apt/sources.list sudo perl -pi -e 's/#\s?(.*dapper-security universe$)/\1/g' /etc/apt/sources.list sudo apt-get update && sudo apt-get upgrade
OK, this is a “taste” thing, but personally I like to have a color prompt that also has some space before it. So I changed my prompt by editing my ~/.bash_profile (”nano ~/.bash_profile“) and adding the following two lines at the end:
# Set prompt: " username@hostname/directory/tree $ " (with colors) export PS1=" \[\e[32;1m\]\u\[\e[0m\]\[\e[32m\]@\h\[\e[36m\]\w \[\e[33m\]\$ \[\e[0m\]"
Reload it with source ~/.bash_profile
Now, maybe it’s just me, but I love a good orthodox file manager. Let’s install one with apt-get: sudo apt-get install mc. Type mc and you’ve got a great two-pane file manager – if your ssh client doesn’t muck it up...
Some folks use screen; I personally never got into it but it’s very powerful. Google it. Then use sudo apt-get install screen.
Finally, if you find yourself typing something again and again, like sudo apt-get install, cut down on your typing with the command alias: alias sagi=”sudo apt-get install”. Alas, the effects will disappear upon your next login; if you like your alias, add the command to the end of your ~/.bash_profile (under the “export PS1” line) to load it every time you log on. You’ll especially appreciate this tip once you install apache and find yourself typing sudo /etc/init.d/apache2 reload all the time...
– Evan: you can reload apache2 using the shortcut command ‘apache2ctl restart’
You may need it, you may not, but it’s not obtrusive anyway. We need to create some symlinks too. If you’re doing any kind of serious Ruby work, you will probably want to install ruby with readline support instead.
sudo apt-get install ruby1.8-dev ruby1.8 ri1.8 rdoc1.8 irb1.8 libreadline-ruby1.8 libruby1.8 libopenssl-ruby sudo ln -s /usr/bin/ruby1.8 /usr/local/bin/ruby sudo ln -s /usr/bin/ri1.8 /usr/local/bin/ri sudo ln -s /usr/bin/rdoc1.8 /usr/local/bin/rdoc sudo ln -s /usr/bin/irb1.8 /usr/local/bin/irb
Now for gem, the Ruby package manager. I like to use gem over apt-get when I can...
To be able to compile gems, you will first need to install the essential compiler tools, Ubuntu makes this easy...
sudo apt-get install build-essential
mkdir sources; cd sources wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz tar zxvf rubygems-1.3.1.tgz cd rubygems-1.3.1 sudo ruby setup.rb cd ~ sudo ln -s /usr/bin/gem1.8 /usr/local/bin/gem sudo gem update --system
If you get the error: “Could not find rubygems-update (> 0) in any repository”, try tips posted on Derek Anderson's blog.
If you use rails, you probably know what to do...
sudo gem install rails --include-dependencies
If that throws an error “/usr/bin/gem:23: uninitialized constant”
sudo nano /usr/bin/gem
After the line
require 'rubygems'
add
require 'rubygems/gem_runner'
This is where things really start to differ, because everyone has different needs. Some people want a lightweight rails stack, some are using an exclusively php backend, some want to use a fancy-dandy control panel... some might not even want a web server! So, your needs may vary.
Simple as an apt-get, right? Think again. While Apache 2.0 is available through apt-get, version 2.2 includes some new features, notably mod_proxy_balancer which is crucial to a good Apache/Mongrel Rails stack.
OK, first the prerequisites; the first line installs some basic compiling tools you’ll need, like “make”. The second installs the “zlib” libraries; some tutorials have you build it from source, but with Ubuntu we can just grab the package. The third installs SSL support:
NOTE: The layout below makes the zlib line possibly confusing, as lowercase l and number 1 look similar in that font. It is zlib1g not zliblg in both cases.
sudo apt-get install build-essential sudo apt-get install zlib1g zlib1g-dev sudo apt-get install openssl ssl-cert libssl-dev
Now let’s download and install Apache 2.2. Note that we’ll need root permissions for a lot of this so we use sudo -i to get into a root shell. Be careful! I hosed a system more than once because of this.
sudo -i cd /usr/local/src wget http://apache.mirrors.tds.net/httpd/httpd-2.2.11.tar.gz tar -xvf httpd-2.2.11.tar.gz cd httpd-2.11.9 ./configure --enable-layout=Debian --enable-deflate --enable-proxy --enable-proxy-html --enable-proxy-http --enable-proxy-balancer --enable-rewrite --enable-cache --enable-mem-cache --enable-ssl --enable-headers --enable-mods-shared=most make make install exit
(The exit takes away your super-user powers.) No errors! Yay! If you do get errors about dependencies, you might try installing (with apt-get) a few libraries that are installed by apt-get install apache2, namely: libapr0 libexpat1 libpcre3.
Finally, let’s make some config changes. Open up httpd.conf with sudo nano /etc/apache2/httpd.conf. Tip: I prefer to download the file with FileZilla (an SFTP client), edit it locally with Notepad++, upload it to the home directory, and then replace the original file (backing up the original, of course).
ServerAdmin line and change it to your email address.User and Group lines and change them both to www-data (the way it’s done on Debian-based systems).ServerName 127.0.0.1 to keep Apache from complaining when you start it up./usr/share/apache2/default-site/htdocs to /var/www depending on the setup you want. This will, of course, be overridden when you access the site under a virtual host...ServerRoot line and change it to /etc/apache2At this point, you should be able to start apache using
sudo /usr/sbin/apachectl start
Looking at your site in a browser, it should say “It works!”. This is the default apache page.
Also, I like to add these lines to make my life easier:
# The following directives define some format nicknames for use with
# a CustomLog directive.
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
I like to do virtual hosts similar to the way the Ubuntu package is set up. So, because you do too...
First, add the following snippet to your httpd.conf file. What we’re doing is telling the server we’re going to use name-based virtual hosting (i.e., the domain name determines the web site served). The first configuration is not used. (Full disclosure: the original author of this wiki doesn’t quite understand how this works, but it works...)
# This enables name-based virtual hosting for all ports being listened to: NameVirtualHost * # The first configuration is the default one... <VirtualHost *> ServerName localhost <Directory /> Options FollowSymLinks AllowOverride None Order deny,allow Deny from all </Directory> CustomLog /var/log/apache2/access_log combined </VirtualHost>
Then we set up a file for each web site we’re hosting. I prefer to set up this directory under my home directory so I don’t have to edit it as root. Could this be a security issue? Honestly, I don’t know. I’m not an expert.
# Include vhost configs from home directory: Include /home/<username>/apache-configs/[^.#]*
You could also do the symlink-to-another-directory thing like the Debian package does (sites-enabled only contains symlinks to a sites-available directory).
As with many of the above installations Ubuntu makes this nice and easy for us so you can begin by using Apt to install the required packages:
sudo apt-get install mysql-server mysql-client
You’ll be asked to confirm the installation of some dependencies which you can go right ahead and select “y” to. If you’re wanting (as most likely will) to use this server with an Apache and PHP setup then you’ll need the PHP bindings to go with it so to do that you can.
Don’t do this if you’ve installed Apache 2.2 – installing the PHP 5 packages will install the Apache 2.0 packages as well.
For PHP 5
sudo apt-get install php5-mysql php5-mysqli
For PHP 4
sudo apt-get install php4-mysql
Now you have all of the required packages you can restart your Apache server with the following command:
sudo apache2ctl restart
Voila - you should now have a working MySQL backend which PHP can speak to. Now you can go ahead and begin the construction of the next killer search engine or Digg-crusher or you can give your MySQL “root” user account a password. You can do this using the “mysqladmin” utility that was installed as part of the packages earlier. Simply type at the command line:
mysqladmin -u root newpassword
To be completed...
To be completed... (note: since Django 0.96 it’s not straightforward to install on Ubuntu 6.06, since Ubuntu 6.06 includes Python 2.4 by default. Ubuntu 7 includes 2.5 by default.)