Difference between revisions of "Apache"
(→Apache) |
|||
Line 382: | Line 382: | ||
* http://www.yolinux.com/TUTORIALS/Subversion.html | * http://www.yolinux.com/TUTORIALS/Subversion.html | ||
− | [[Category:Module | + | [[Category:Module 2]] |
Revision as of 22:37, 24 February 2013
This page describes how to set up a web server on a Linux machine. If you are unfamiliar with using Linux from the command line, you should read the Linux guide first.
Contents
What is a web server?
A web server is software that listens for connections to your machine, and when a connection is receive, processes the request and responds with the appropriate information. Most web servers listen on port 80, which is reserved for the purpose, and use the HTTP protocol.
For example, when you visit this wiki, you are sending a request over the internet to some machine that is probably located somewhere in EIT (the user seldom knows exactly where the machine is located). The web server receives your request, and it processes the data you sent. Finally, the server prepares a response (the web page), and sends it back to you.
SSH
When connecting as an administrator to your machine over the internet or intranet, you will most likelly be using ssh (secure shell). SSH access requires that the sshd daemon is running in your machine.
By default, SSH is preinstalled on your EC2 instance. If you are not using an EC2 instance, simply install it from yum or apt.
SSH Keys
Normally, you can SSH into your machine with one of two ways: you can use traditional username/password authentication, or you can use a public/private key pair. A public/private key pair is generally considered to be more secure, but it requires that you always have access to your private key file when you want to log into your remote machine. By default, EC2 instances allow only public/private key pair authentication. You can enable password-based authentication by changing the PaswordAuthentication option in /etc/ssh/sshd_config to yes:
PasswordAuthentication yes
If possible, however, you should restrict yourself to using private and public keys.
SSH Server Configuration
The configuration files for SSH are in /etc/ssh. You can modify the files to affect SSH permissions, among other things. For example, it is always a good idea to disable root access over ssh. This could be done by editing /etc/ssh/sshd_config and setting
PermitRootLogin no
For more detail on editing files on the command line, see the Linux guide.
You will need to restart the server for changes to take effect:
$ sudo service ssh restart # if that doesn't work, try: sudo /etc/init.d/sshd restart
ssh stop/waiting
ssh start/running, process 1443
$
Caution: Disabling root access over SSH for your EC2 instance should only be done after setting up an additional user account and adding that account to the sudoers list.
Adding SSH Users
If you want to log into your EC2 instance using your own account rather than the default ec2-user or ubuntu account that Amazon made for you, you need to do some additional configurations.
If you are using keys, you need to associate your private key with the user on the server. To do this, run the following commands:
$ sudo su # you need to be root in order to access another user's directory
$ cd /home/myUserName/
$ sudo mkdir .ssh
$ sudo cp /home/originalUserName/.ssh/authorized_keys .ssh # originalUserName should be ec2-user in the Amazon Linux AMI or ubuntu in Ubuntu Server 12.04 LTS
$ sudo chmod 700 .ssh
$ sudo chmod 600 .ssh/authorized_keys
$ sudo chown -R myUserName:myUserGroup .ssh # myUserGroup is probably the same as myUserName; for example, if the username were alice, you could run: sudo chown -R alice:alice .ssh
$
You should now be able to log into your server using your custom username with SSH keys!
IMPORTANT: From here on out it is recommended that you always login as your user account instead of ec2-user or ubuntu. Previous versions of the Amazon EC2 cloud created an account named "root", instead of the default account ec2-user or ubuntu. If you really want to login as root, you can set the password for that account by typing: sudo passwd root. As explained below, it is not recommended to use the root account or allow ssh connections with that username. It is advisable to use the account you created instead of the root account (or ec2-user or ubuntu) for security reasons. Additionally, the act of requiring you to type "sudo" in order to run commands as root serves as a reminder that the command you are typing in should be examined carefully.
SSH Client Configuration
Unix-Based Systems (including Mac OS X)
Mac OS X is based on BSD, a flavor of Unix. As such, Mac OS X comes pre-built with all the tools you need to use SSH! Simply fire up Terminal and enter the command
ssh username@hostname
To use SSH with a key pair, use the command
ssh -i /path/to/key.pem username@hostname
Non-Unix-Based Systems (including Microsoft Windows)
Unfortunately, using SSH with Windows is more complicated. Amazon provides a great tutorial on how to connect to a virtual machine from Windows (follow this link if you are in the Urbauer Lab) [1]. It is necessary to install an SSH client to support the connections. A widely used SSH client for Windows is PuTTY. You can download PuTTY from http://www.chiark.greenend.org.uk/~sgtatham/putty/
PuTTY is fairly simple and straight forward with one caveat: Amazon's .pem key pair files are not compatible with PuTTY keys. In order to convert .pem keys to a PuTTY .ppk privte key file, you should use the puttygen.exe utility available from the same page [2] as PuTTY. Next select import under the conversions menu,load the amazon .pem key file and press the save private key button. Be sure to save the file in the directory where PuTTY looks for its keys.
Copy and paste works similarly to the X Window System in Unix. You use the left mouse button to select text in the PuTTY window. The act of selection automatically copies the text to the clipboard: there is no need to press Ctrl-Ins or Ctrl-C or anything else. In fact, pressing Ctrl-C will send a Ctrl-C character to the other end of your connection (just like it does the rest of the time), which may have unpleasant effects. The only thing you need to do, to copy text to the clipboard, is to select it.
To paste the clipboard contents into a PuTTY window, by default you click the right mouse button. If you have a three-button mouse and are used to X applications, you can configure pasting to be done by the middle button instead, but this is not the default because most Windows users don't have a middle button at all.
Also, here is a good PuTTY tutorial that you might find useful to get started: http://kb.mediatemple.net/questions/1595/Using+SSH+in+Putty+%28Windows%29
SSHFS
SSHFS is a filesystem client which allows secure mounting of remote file systems. While there are other ways to mount remote file systems, SSHFS has the advantage of being able to mount a file system located on any host that has an SSH daemon running without any host side installation or configuration. This means that you can easily access and edit your files using all of your local applications including IDEs.
As you may have inferred from the name, the underlying implementation utilizes SSH File Transfer Protocol in combination with FUSE, a package now included in the kernel that allows unprivileged users to easily create their own file systems in userspace (see the wikipedia entry for more information [3]).
To mount a share using password based authentication, the command is
sshfs user@domain:/path/to/remote/directory /path/to/local/mountpoint
e.g. To mount the directory /home/joe/myfiles in the user joe's home directory for a machine with the domain schmoesfiles.org using SSHFS you would enter the command
sshfs joe@www.schmoesfiles.org:myfiles
Note that if you are using public key authentication, the command to mount the remote share is slightly different
sshfs -o IdentityFile=/path/to/private/key user@domain:/path/to/remote/directory /path/to/local/mountpoint
To unmount the filesystem you can use the following command
fusermount -u /path/to/local/mountpoint
SFTP
Any server running an SSH server is also compatible with SFTP or Secure File Transfer Protocol. (Compare to FTP, or File Transfer Protocol.) SFTP is a convenient way to edit files on your computer and then upload them to your server in just a few clicks.
You can use SFTP from the command line, or you can use any GUI file transfer client. All FTP clients I have seen also support SFTP. One popular FTP client is Filezilla.
Using FileZilla
- Download and install FileZilla from http://filezilla-project.org/download.php?type=client
- If you are using a lab computer, you can save it to your H drive.
- When you launch FileZilla, go to Edit→Settings or FileZilla→Preferences, and go to the SFTP options (under Connection). Click "Add keyfile…", and choose the *.ppk file that you made earlier using Puttygen. (If you lost that file, you can choose your *.pem file, and FileZilla will convert it for you.)
- When finished, press OK (not the red ×) to save your changes.
- Back on the main FileZilla screen, there are four fields: Host, Username, Password, and Port. Fill them in as follows:
- Hostname: sftp://ec2-xxx-xx-xx-xxx.compute-1.amazonaws.com/
- Username: The username you created on your server.
- Password: Since you are using a key, you may leave this blank.
- If you changed your SSH settings to allow password-based authentication, then you could put your password in here.
- Port: 22
- Then click Quickconnect. If everything is configured correctly, FileZilla should log into your server.
On the left and right of the FileZilla window, you can drag files between your computer and your server. Thus, you can edit a file in a text editor like Notepad++ on your decktop, and then upload it to your server by simply dragging it from the left pane to the right pane in FileZilla.
Apache
Apache is the industry standard web server for Linux distributions. It is highly configurable and has a wide range of modules ready for different needs.
Installing Apache
In yum, Apache is distributed under the package name httpd (for hypertext transfer protocol daemon). In apt, it is distributed under the name apache2. Use the package manager associated with your distribution to install Apache. (For more information on how to use yum and apt, see the Linux guide.)
When Apache is installed through apt, the HTTP Daemon will be automatically to added as a startup item. If you are using the Amazon AMI, you need to run this command to add Apache as a startup item:
$ sudo /sbin/chkconfig --levels 235 httpd on # RHEL only
$
In RHEL, all Apache configurations are stored in /etc/httpd/conf/httpd.conf. Debian takes a more modular approach, having separate directories for each type of configuration, all located in /etc/apache2/. For more detail on Debian's approach, see http://www.control-escape.com/web/configuring-apache2-debian.html
Apache Directives
You define your settings for Apache using directives. Some of the directives you will likely encounter include:
- DocumentRoot: The path to the directory where the top level web files are going to be stored.
- IfModule: The following block would be included if specified module exists.
- User: Which user apache2 will run as.
- Group: Which group will have group access to default web files.
- AccessFileName: The name of the access file (that specifies user names/passwords and other limitations to files/directories).
- ErrorLog: Where any errors will be written.
- Include: Include some other files.
- LogFormat: How to write a log message.
- ErrorDocument: Files to display for some HTTP errors (500, 404, 402 etc.).
- Alias: Map a directory URL to some other location on your filesystem. Requires that the Alias module be loaded.
.htaccess Files
You can also specify some Apache configurations without delving into the master configuration file. To do this, put a file named .htaccess in any directory that Apache is serving. All directives in it will be interpreted as if they were in a Directory directive in the master configuration file.
VERY IMPORTANT: The directory containing .htaccess must not have the AllowOverride None directive in the master configuration file in order for .htaccess to be read. In Debian, AllowOverride None is enabled by default! The Apache configuration file you need to edit in Debian is /etc/apache2/sites-available/default (remove the AllowOverride None located on line 11).
Directory Directive
Use the Directory directive to assign other directives to a specific directory. For example:
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
allow from all
RedirectMatch ^/$ /apache2-default/
</Directory>
This sets options for the /var/www directory.
- The Options directive says that:
- If no index page is present in a directory, display a directory index page instead
- Apache will follow symbolic links in the directory
- AllowOverride None says that .htaccess files cannot alter the Apache options in this directory and all sub-directories
- Order allow,deny and Allow from all specifies that anybody is allowed to access this server via HTTP.
Note that this directory is actually the root directory of the web server.
Enabling the UserDir Module
The UserDir module lets you access files for any user on the server with a ~, e.g., http://ec2-xxx-xxx-xxx-xx.compute-1.amazonaws.com/~paul/
This module comes installed, but not activated by default.
Enabling UserDir in Debian
If you are using a Debian-based distribution for your server (like Ubuntu Server 12.04 LTS), simply run the following command to enable the module:
$ sudo a2enmod userdir
Enabling module userdir.
To activate the new configuration, you need to run:
service apache2 restart
$
Then restart Apache for the changes to take effect. Now, all users will be able to store their own personal web site in public_html inside their home directory.
To make sure everything is working, create a test file in your home directory under public_html, and then point your browser to it: http://ec2-xxx-xx-xx-xxx.compute-1.amazonaws.com/~yourUserName/hello.txt
Note: The UserDir configuration file, which already has all the correct settings, is located at /etc/apache2/mods-available/userdir.conf
Enabling UserDir in RHEL
If you are using an RHEL-based distribution for your server (like the Amazon AMI), you need to edit the master Apache configuration file.
Open /etc/httpd/conf/httpd.conf in your favorite text editor. For more information on command-line text editors, refer to the Linux guide.
Find the line that says
UserDir disabled
and change it to
UserDir disabled root
Additionally, find the line that says
#UserDir public_html
and uncomment it; that is, remove the # so that you have
UserDir public_html
This tells Apache that the directory containing each user's html files is a subdirectory of their home directory called public_html.
You may also need to change the permissions of your user directory and your public_html directory to allow Apache to read and execute inside them. To do this, run the following commands:
$ sudo chmod o+x /home/myUserName
$ sudo chmod o+rx /home/myUserName/public_html
$
Finally, restart Apache.
Remapping UserDir
If you want to change the name of the UserDir web server root from public_html to something else like .html, follow these instructions.
- Rename your public_html to .html
- The "." in front of the directory name means that the directory is a hidden one. You will not see it with the normal "ls" command. Use "ls -a" to see hidden files as well.
- Edit the UserDir configuration file.
- In RHEL, edit the master Apache configuration file at /etc/httpd/conf/httpd.conf
- In Debian, edit the UserDir configuration file at /etc/apache2/mods-available/userdir.conf
- Find the line that reads
UserDir public_html
and change it toUserDir .html/
- Restart Apache.
Apache Logs
Apache creates two log files: one for all access attempts to your server, and one for errors. The locations of these log files are:
- Debian:
- Access Log: /var/log/apache2/access.log
- Error Log: /var/log/apache2/error.log
- RHEL:
- Access Log: /var/log/httpd/access_log
- Error Log: /var/log/httpd/error_log
You might find it helpful to see access and errors appear "live" in your terminal window as they are created. To do this, you can use the tail -f command. Since the log files have strict permissions, you will need to also use sudo. Example on Debian:
$ sudo tail -f /var/log/apache2/error.log
Virtual Hosts
Virtual Hosts are used to run multiple Apache web servers from the same machine. Virtual hosts can listen for connections on different ports and/or different hostnames, serving completely different web sites to each. For example:
<VirtualHost cse330.dyndns.org>
ServerAdmin webmaster@localhost
ServerName cse330.dyndns.org
DocumentRoot /home/www/cse330/
ErrorLog /var/log/httpd/error_log
LogLevel warn
CustomLog /var/log/apache2/access_log combined
ServerSignature On
</VirtualHost>
This configuration enables any requests that use a host name of cse330.dyndns.org will use /home/www/cse330 as the root document directory. Make sure that the DocumentRoot directory exists and is readable by the httpd process. In RHEL, Apache runs as the apache user. In Debian, it runs as the www-data user.
It is good practice to put raw server configuration files in /etc/httpd/sites-available in RHEL or /etc/apache2/sites-available in Debian. To activate a site, create a symlink from the configuration in sites-available to a sibling directory called sites-enabled. In Debian, these directories are already set up for you, and Debian Apache even provides the a2ensite and a2dissite commands to create or destroy the symlinks! In RHEL, you have to do this by hand.
Restarting Apache and Testing
Whenever you make changes to the Apache configuration files, you will need to restart Apache for the changes to take effect. There are several different ways to restart Apache; they all functionally do (almost) the same thing, so choose your favorite:
$ sudo /usr/sbin/apachectl restart # works on both Debian and RHEL
$ sudo apachectl restart # if /usr/sbin is in your PATH (which it is by default in Debian, but not RHEL)
$ sudo /etc/init.d/httpd restart # on RHEL
$ sudo /etc/init.d/apache2 restart # on Debian
$ sudo /sbin/service httpd restart # on RHEL
$ sudo /usr/sbin/service apache2 restart # on Debian
$ sudo service httpd restart # on RHEL
$ sudo service apache2 restart # on Debian
If you're torn for which version is the "best" to use, the commands involving apachectl (think "Apache Control") are written by the Apache folks themselves. This has a couple advantages:
- They show you errors in the startup process (if there are any)
- They give you the option to perform a "soft" restart; that is, a restart that allows any pending connections to complete. To perform a soft restart, use graceful:
sudo apachectl graceful
In my anecdotal experience, the apachectl commands are also faster than the service or init.d commands.
To make sure everything is working, create a test file in your home directory under public_html, and then point your browser to it: http://ec2-xxx-xx-xx-xxx.compute-1.amazonaws.com/~yourUserName/hello.txt
Subversion
Subversion (svn) provides an easy way to store all of your files that you create in this course on a server backed up at WashU. It also allows you to easily create and edit text files on your local computer and then transfer them to the Amazon cloud machine using the svn "checkout" command.
Setting Up SVN on your Server
First, install the package using apt or yum, depending on whether you chose Debian or RHEL for your Linux distribution. For more information on installing packages, refer to the Linux guide. The package name is svn in yum and subversion in apt.
Next, navigate to your home directory and checkout your repository:
$ cd
$ svn co https://hostname.wustl.edu/path/to/repository
...
$
You will need to authenticate using your WUSTL key username and password (not your CEC or EC2 password). The path to this semester's repository is listed on Module 1.
After running the above commands, sn empty directory should be created. To make sure that SVN is working, cd into the directory, create a text file, and tell SVN to start version control on it. Finally, commit the file to the remote repository:
$ cd Lastname-studentid
$ touch helloFromTheCloud.txt
$ svn add helloFromTheCloud.txt
A helloFromTheCloud.txt
$ svn commit -m 'Added first file'
...
Committed revision 1.
$
Pointing Apache to your Repository
You may find it helpful to have Apache serve files from a certain directory inside your repository to which you can commit changes from your desktop. We can do so using a symbolic link (similar to a "Shortcut" in Windows or an "Alias" in Macintosh). Move public_html (or .html if you remapped UserDir) into your repository, and link to the new location from the old location:
$ cd # Make sure that we're in the right directory
$ mv public_html Lastname-studentid/htdocs # change public_html to .html if you remapped UserDir
$ ln -s Lastname-studentid/htdocs public_html # change public_html to .html if you remapped UserDir
$
Now, all files you save inside the htdocs directory in your repository will be served by Apache via the UserDir module.
Setting Up SVN on your Desktop
If you've taken CSE 131 or 132, you should already have SVN installed in Eclipse. If not, refer to the tutorial here: http://www.cs.wustl.edu/~cytron/cse131/HelpDocs/Subversive/subversive.htm
When you're ready, check out the repository into Eclipse. The path to this semester's repository is listed on Module 1.
Do you see the helloFromTheCloud.txt file that you made earlier? (You should.)
Create another text file, helloFromMyDesktop.txt. Commit that file to the remote repository
Back on your server, issue svn update
. The helloFromMyDesktop.txt should be downloaded:
$ svn update
A HelloFromDemo.txt
Updated to revision 89.
$