Waxing Cerebral

My notes to help remember the processes to get a secure svn server using Apache 2 on OS X Tiger. I know these are documented in lots of places, but it seemed that parts of various HowTos were required in order to do it with current Apache (2.2) and with Tiger. For anyone with Leopard onwards, you can skip the installation of Apache2 as this is now standard from Leopard on (Tiger and earlier used Apache 1.3 and earlier) and here is probably your best bet.

Edit: I drafted this a year ago and never finished (or published) it. Now the server has reverted back to apache1.3 after an update and my ssl cert had expired - time to revive the post! Unfortunately I didn't capture all the steps, especially the setting up of mods-enabled etc, but I'll just use my install as reference. Ask if you need those bits. Meantime, this link may be helpful. Brad.
Edit 2 (16/4/2009): It did it again. If svn access starts to fail, log in to a directory-displaying page or any page that gives the apache http server version - if it says 1.3 then it's reverted back from 2.0 (alternatively, if ls -l /usr/sbin/apachectl shows a single file rather than a symlink to /sw/sbin directory, that also is an indicator it's reverted). Easy fix is (after stopping 'Personal Web Sharing' in System Prefs): sudo ln -sf /sw/sbin/apache2ctl /usr/sbin/apachectl as below. Then start web sharing again; should now be 2.0 running.

Installing Apache httpd 2
1. Apache2 Installation

The bulk of this guide comes from Tim Fanelli's great howto (just the Fink, Apache2, Subversion, and WebDav steps for now). If you don't have XCode Tools installed prior to this, you can get them here (requires free registration). Extra notes to the sections in Tim's guide follow:

• Apache2: At the end of this section you can start up Apache2. Be sure to shut down the 1.3 WebServer first via the Sharing panel of SysPrefs, if it is running. You should then be able to view the Apache2 welcome screen by browsing to http://localhost. You probably won't be able to access this from another machine yet though (even within LAN) as the Mac's firewall won't be allowing it. We'll get to that later.
• Subversion: If you will be carrying this on to use svn, you might as well do this and the WebDAV steps now. You'll need svn-ssl, but may not require svn-client-ssl. I didn't install it.

That's all we need from that blog for setting up the Apache2 server

2. Apache2 Configuration
Next we'll configure Apache2 to be handled by the Sharing panel of SysPrefs, instead of old 1.3.

• cd /usr/sbin
• mv apachectl apachectl1.3 {–> This renames default apache1.3/apachectl command}
• ln -s /sw/sbin/apache2ctl apachectl {–> This creates symlink for Apache2/apachectl command}

Edit /sw/etc/apache2/apache2.conf:

1. Change the pidfile location to:
   
   
   /private/var/run/httpd.pid


2. In order to easily view logs from Console, and to get free log rotation, change the ErrorLog parameter to:
   
   
   /var/log/httpd/error_log


3. And add a new entry:
   
   
   CustomLog /var/log/httpd/access_log common

3. SSL Certificate
Go back to Tim's post and the SSL step. You'll want to follow the link and generate the certificate Important: Ensure you create a CommonName attribute in the certificate. If it is missing then many svn clients will fail to access the site. After doing that though, a couple of the commands given back in the main howto are wrong. Change sudo cp ~/server.key /sw/etc/apache2/ssl.key/ to sudo cp ~/sslcert/server.key /sw/etc/apache2/ssl.key/ and the same for .crt.



For better security, don't do the decryption suggested. However, for
pragmatism and to be able to control the server via the SysPrefs, just
do it :)

Using ssh we can create tunnels to route bi-directional traffic. Depending on our selection of destination and server computers to connect to, the complete tunnel is made of a fully secure ssh tunnel, and possibly an additional tunnel continuing on that is not secure. The examples below should help explain this.
Here's the command:

ssh -NL localport:targethost:hostport server [-p serverport]

Where

• -N means don't start a remote ssh session (useful if just port fowarding)
• -L indicates a tunnel is to be set up with the following params:
• localport: tunnel 'entry'. Port number to connect to locally (ie at localhost)
• targethost: tunnel 'destination'. Which computer (name or ip) to connect to
• hostport: tunnel 'exit'. Port number to appear as on the other side of the tunnel.
• server: computer to validate ssh connection on (needs to be running ssh server). This forms part of the tunnel and three variations of this are explained below. You can make this 'user@server' in order to specify a username for the authentication if required.
  
• serverport: this is optional, but if you want to create the ssh connection over a non-standard port (ie not 22) then use this. You'll need to get the sshd listening on the new port in this case.
  

Remember these funky things are 2-way so if whatever you're communicating with at the other end of the tunnel sends info back down the tunnel (via hostport) then you'll get it right back at your end (localport). It's cool.

Example 1, target computer is running ssh server:
ssh -NL 8081:192.168.1.4:8090 192.168.1.4
Create a tunnel from 8081 locally to 192.168.1.4, and appear there at port 8090. Validate at 192.168.1.4. This is a short tunnel, between just the client and host, but completely secure. All traffic in this case will be over port 22 (ssh default).

Example 2, host computer is running ssh server:
ssh -NL 8081:192.168.1.4:8090 localhost
Exactly as in example 1, only this time the local machine is both ssh server and client. There is effectively no secure tunnel here (ie it's only between ports on the local machine), so unsecure over port 8090 to 192.168.1.4.

Example 3, 3rd computer is running ssh server:
ssh -NL 8081:192.168.1.4:8090 192.168.1.5 -p 3389
In this case, locally we are the ssh client, connecting securely (over port 3389) to the ssh server, 192.168.1.5. From there traffic travels over port 8090 to the destination box, 192.168.1.4. This is very powerful as traffic can be securely routed into a limited-access network. For example in this case if Microsoft's Remote Desktop Protocol (RDP) was the only traffic allowed in and out (eg through VPN), then the client externally can run this command, connect through on the RDP port (3389), connecting to a box inside the network (192.168.1.5). From there the destination IP is resolved, so this needn't be visible from the client computer, and traffic flows freely inside the network over 8090.

Another option is remote tunnels (instead of local tunnels). These use essentially the same commands, but with -R in place of -L. With a remote tunnel it is possible to declare a port on a foreign machine as the tunnel entry.

A nice way to test your tunnel is to use netcat. For the above examples this test would be:

On 192.168.1.4:
nc -l -p 8090
listen (-l) on port (-p) 8090 - end of the tunnel

On localhost:
nc localhost 8081
connect to localhost on 8081 - start of the tunnel

The localhost connection should get tunneled to the remote box and you'll be able to type at either end and see it appear in the terminals.