30 Oct 2010

SVN, Apache and Snow Leopard Server: A Battle

Looking for instructions for Lion Server?? Check out the new post

Oh wow. This one is covered out there on the internet but I had a hard time getting subversion and apache and snow leopard server to work together properly and in a way that stuck. Hopefully this article will save you a few hours of pain and give you a long lasting, robust solution for hosting a subversion repository on Mac OS X Snow Leopard Server.

Lets talk about the goal. I wanted to have a repository for each of my software projects. I have a group of users in Open Directory whom I want to be able to access the repository. I have them all in a "developers" group. I also want to be able to check in and out from outside my home network.

I thought the best way to achieve this would be to set up Apache and subversion and access the repo using webDAV. Snow Leopard server comes with all these tools built in and I thought it would be a cinch to get going. It turns out that most of the battle is with Server Admin. Apple have a capable but lacking module in Server Admin to configure Apache and its simply called "web"

All the tabs are pretty self explanatory. But the key to getting this configured is the "Sites" section.

Lets step back a bit and talk about Apache, the web server in Snow Leopard Server. Apache is configured using plain text configuration files stored in /etc/apache2. These files contain instructions on how to set up the webserver and these instructions are known as directives. Now If you have a directive at the beginning of the file and then specify that directive later on, the later directive takes precedence. In this way web servers are usually configured to deny all requests from everybody and have access to nothing, and then later on are configured to allow only certain access to certain places and only for certain domain names.

What does this all have to do with apache and Snow Leopard Server? Well quite a lot. The Sites tab sets up all the websites you want to host on your web server. (Vhosts in apache parlance). Different websites can be served up by apache depending on what address you type into your address bar of your browser.

Now, basically Sites at the bottom of the list in Server Admin are overridden by sites at the top of the list, just as Apache directives at the start of a config file are overridden by the ones at the end. This means that if you have a Site set up for yourdomain.com and in the Server Aliases Panel you have *.yourdomain.com like so…
Here we have a new site with our domain name entered.
And here is the alias for all subdomains.
To host a subversion repo at http://repo.yourdomain.com you need to make a new Site with that hostname and drag it above the more generic wildcard site in the list.

Ta da.

Now to the fun part. In various how tos around the internet it suggests creating a realm in Server Admin and then editing the apache conf file in Terminal to enable subversion. This method will drive you nuts as Server Admin sets DAV off over and over again no matter how lightly you tread. So lets not bother with server admin any more, lets do something that it can't change every 5 minutes!

At this point you should have a Site for your new repo, and you should get something when you visit it in a web browser. I have all the Options turned off, nothing in the realms section, nothing in the Web Server Aliases section, nothing in the proxy section and I disabled all the Wiki, Calendar and Blog stuff in the last tab (this is a subversion server after all).

Now fire up terminal and enter the following command (again I prefer to use vim, but you may like pico or something else)

sudo vim /etc/apache2/subversion.conf

now press the "a" key and paste this in (CMD + V):

        <Location "/svn/">
                AuthType Basic
                        Require group  developers
                AuthName "svn_auth"
                SVNParentPath /Groups/developers/repos
                DAV svn

Couple of things you may want to change…
  • Require group developers - this line only allows access to the developers group in Open Directory. Change this to what you want. You can also have Require user someUser to only allow access to someUser.
  • SVNParentPath …. - This means the following directory is a directory containing several subversion repos and saves you having to set up several individually.
  • /Groups/developers/repos - flying in the dour face of convention, as I am only allowing access to the group "developers" I am choosing to store the repos in their group folder. Nice and accessible in the finder and it means server permissions are easier!
Ok. Now those are all set up to your liking lets save the file. Press "Esc" and then type ":wq".

What we have done is the same as making a realm in Server Admin, but outside of where Server Admin looks.

Now we need to configure our site we made in Server Admin to reference this file. Open it up.
vim /etc/apache2/sites/0000_any_80_repo.yoursite.com  (or something like that)

Just before the end of this file we'll insert the vital line
Include "/etc/apache2/subversion.conf"

(in vim, scroll down using arrow keys, then press o to Open a new line and type it in. Press esc, then type :wq to save)

Wicked. Now all we need to do is create our subversion repository (might as well stick in terminal)

cd /Groups/developers/repos/
svnadmin create subversionRepository

So that our webserver can access the directory, lets make it owned by the web server user _www. Its ok to do this as access for the developers group is determined in an ACL, not using POSIX permissions.

chown _www subversionRepository

In the finder it looks like this

Now all thats left to do is test the repo. You can try it out in your web browser.

Any questions, post a comment.

29 Oct 2010

Snow Leopard Server as a Time Capsule Replacement

Who needs a time capsule when you have Snow Leopard Server?

Nobody! Snow Leopard Server comes with everything you need to turn your Mac into a wireless backup solution using Time Machine, in exactly the same way that a time capsule would.

At this point your server should be up and running OK on your network.

Lets start by enabling remote Time Machine backups. Open up server preferences and connect to your server.

Open up the preferences for Time Machine.

We can select the disk that we want the remote backups to use. You can pick from any hard drive connected to the server. My advice would be to buy a nice big drive and use that.

Now we need to check the permissions for each user. From the main screen of server preferences select "Users" and then select the "services" tab.
We want to check that Time Machine is checked for all the users we want to be able to use it.

Simples. Now on each machine you can select your server as a backup disk from Time Machine preferences in each systems System Preferences app. Each machine then creates a sparse bundle in the Time Machine backup share which it backs up to. Thats home users sorted.

Oh but I'm not going to leave it there…

This is the Mac OS X Server Admin blog for a reason. We don't want to have to go around configuring time machine for each computer and in the end we probably can't fit all those backups on even the largest storage solution, right?

Ok so now for the fun part.

Lets fire up Server Admin and take a look at the File Sharing section.

This screen allows us to share the Root of any drive by selecting a drive and clicking "Share".
We can also use browse mode to make a share point at any point in the folder hierarchy of a drive. This means you could make Time Machine backup in the directory /Volumes/Drive/office1/backups or whatever folder scheme you choose.
So now make your share point that you'll use for some Time Machine backups. Click the share button and then switch over to the share point screen and take a look at your new share point.

Make sure Enable as a Time Machine backup destination is selected and were good to go. The warning that you see here is shown when the backup destination is a removable disk. Its perfectly compatible as long as you don't remove it!

You can see if a share point is enabled for time machine backup in the share point list by looking for the time machine icon in one of the columns

Make a note of the name of the share point you intend to use for backups. Excellent. Now we have our share points set up lets make our networked computers back themselves up automatically! Fire up Workgroup Manager and log into your server

There are a few strategies we can use here:
  • We can make a "Guest Computer" account and set that to back up to the time machine destination. This means that all computers that join your domain and don't have computer accounts in Open Directory will automatically back up. Including any random Macs that decide to join the domain.
  • We can make accounts for all the computers we have and then set Time Machine backup preferences for them individually.
  • Or finally we can set up all out computers with computer accounts, and then make a computer group and set the Time Machine preferences for the whole computer group.
I'm going to show you how to make a Guest account and then how to make a computer account, then I'll show you how to set up time machine for them automatically using open directory.

So lets start by looking at our computer accounts

Now use the Server Menu in Workgroup Manager to make a Guest Computer account. 
Bear in mind a guest computer is any computer on your domain which doesn't match up to a computer account. Think about the ramifications that this may bring if you decide to go setting preferences for it. (If you're at home think about friends bringing computers over, or at a business think about client's computers using your network.)

Alternatively create a new computer account and fill in the name section. For good measure the short name should be the name of the machine. The real info that lets a computer find its account is the hardware UUID. This can be found on each of your client Macs from "About this Mac" in the Apple menu and clicking "More Info"

Tap this in to the UUID field for the computer account in Workgroup manager and your computer account is completed.
So now select either your guest computer account or your actual computer account and have a look at the managed preferences

Specifically we want to look at the Time Machine Preferences
This is where the magic happens. From here we can manage the Time Machine preferences for the computer. The only option is to Always manage the preferences or Never manage the preferences. For info on what these mean please see Apple's documentation. 

The afp URL we type in here is the URL to the share point we made earlier. Usually it looks like this:

afp = apple file-sharing protocol
your.server.com = domain name of your server. May not be a "proper" domain name e.g. server.local
backup_sharepoint_name = name of the sharepoint we made a backup destination earlier.

Pretty easy. The other options are all pretty self explanatory. Why would you want to back up all local volumes? In case there are other partitions with data on them. We also have a great option here that isn't available through the basic Time Machine interface which is to limit the amount of space that Time Machine uses on a per machine basis. A great way to plan storage space.

As soon as the settings are applied you can see if your computer has picked up the settings that apply to it by opening up a terminal and typing "mcxquery" to see all the preferences that are being managed.

You should see the above Time Machine preferences in the output.

Fantastic. All your computers are now automatically backing up using Time Machine to a remote share that you specified! They even have usage quotas. You'll never buy a time capsule again, especially as you can replace the drive attached to your server as needed!

Further Reading

Download Apple's Server Admin Tools for your admin machines

28 Oct 2010

Secure SSH with Snow Leopard Server

Ok so I thought I would do a post about SSH security. This is important for keeping your server secure from attacks, especially if you want to be able to SSH into your server from other computers on the internet.

Firstly some info. Why SSH? SSH is a great tool that enables you to log into your server at the command line level using the Mac OS X Utility app "Terminal". SSH provides a great way to issue remote commands to your server and make configuration changes with out being sat in front of the box. Especially useful if the server lives in a cupboard. SSH also has a network connection tunnelling feature. This means you can forward services on your server to the current computer you're working at or even use your server as an encrypted proxy server (facebook at work anyone?)

You can log in with SSH using one of several login methods, only one of which involves typing in a password. You really don't want to be able to log in by typing a password, as that means that someone else can log in if they know, guess, or brute force your password. Or more importantly if they guess another user's password which may be less secure than yours. While you might not worry if you don't open port 22 on your router I would never make an SSH server internet facing with password authentication on.

This tech tip will require typing commands at the command line in the "Terminal" app. You will need to know how to use a terminal editor like nano or vim (the authors favourite). However you should be able to do it easily by following the instructions so I've ranked this as "medium difficulty". I'm going to assume you have Open Directory setup and working, that you have an admin open directory account and that Kerberos is running on your domain.

First things first, lets sort out our server's accepted authentication systems. On the Mac OS X server open up a Terminal window. Terminal can be found in Applications>Utilities>Terminal

We're going to edit the server's SSH configuration file.

Type this into terminal "sudo vim /etc/sshd_config"
I like to use vim for editing, you may prefer pico. I'll walk through assuming you know what you need to press so if you get confused you might prefer to use pico "sudo pico /etc/sshd_config"

You'll need to type in your password
You'll have the configuration file open now. It should look a little like this.

You can now go through the file using the arrow keys to find the parts we need to change. I've put pictures of the settings we need to make below with explanations of what they do. Bear in mind each line you change should have any comment symbol (#) deleted from the start of the line to work.

These options are all about making it easy for you to log in via SSH when you are on the same network as your server. You will be able to log in using your Kerberos Ticket which should mean you wont need to type your password (as you supplied it when you logged into your computer). This authentication method is secure.

This option set to "no" disables logging in by typing your password at a prompt. I would always recommend having this set to off.

These options allow logins using private keys. This is a great way of logging in from outside your network and uses a file that you keep safe to log you in.

This option is the one that lets you tunnel your network connections through SSH. It means you can use local services outside your network.

Ok now you have made those changes its time to esc :wq
(in vim esc puts you back into command mode, we then type the command :wq which stands for Write the changes to the file, Quit the program)
You should be returned to the command prompt we saw at the beginning.

We don't need to restart the SSH server on mac OS X as services are started and stopped dynamically by launchd. Configuration changes are immediate.

Now lets try logging in on our local network. This shouldn't require a password as authentication will be done by kerberos. With Kerberos you authenticate when you log into your computer and the credentials are cached in a secure way to use for other services like SSH and AFP.

In a terminal window, on the computer you want to log in to your server from, type the following: 
"ssh -K your.server.com"

You should be instantly logged in without typing a password. Hooray! If not check your kerberos tickets. You can do this with the "Ticket Viewer" app System>Library>Core Services>Ticket Viewer

You should have a ticket like above. If you have no ticket it will say "No Ticket" under your server's DNS name. If nothing shows up in this list you have no Kerberos Identity which means you don't have kerberos and Open Directory set up properly. Setting that up is beyond the scope of this article.

So you logged in with SSH using Kerberos (no password on your local network). We used the command "ssh -K your.server.com". If you have an admin machine and you want to stop typing that K every time, then you can edit your admin computer's /etc/ssh_config file to have the following lines:

Just use the same method we used to edit the other file. The command (on your admin machine) would be "sudo vim /etc/ssh_config"

Now when you want to log in by SSH all you need to type is "ssh your.server.com" as we have specified that SSH should try the GSSAPI authentication by default.

Awesome. Now to set up logging in from outside your local network! This is done using "private keys". Similar idea to having keys to your car, now you have keys to your server. They are very secure and can even be secured with passwords to have 2 factor authentication. Keys have a public part and a private part. You need to keep the private part to yourself (like your actual car key) and the public part goes on whatever server you want to be able to log into with your key (kind of like the actual lock that the key fits into).

On the machine you want to be able to log in with from outside your network (or even a machine with a user that is not part of your directory) you'll want to fire up Terminal again (I'm assuming its a mac, windows users look up PuTTYGen) and type in the command "ssh-keygen"

You can just press enter for all the prompts to create a default key file without a password. This is ok. You'll then need to copy the public part of the key to your server. The best way to do this is to copy it to your desktop and then to a USB stick.
 "cp ~/.ssh/id_rsa.pub ~/Desktop/"

On your server you then need to copy the file into the right place for it to work. On your server log in as the user you want to use this key with. Put the file from the USB stick onto the server's desktop and rename it "authorized_keys". We then copy this into the right location using "Terminal".
"mkdir ~/.ssh"
"cp ~/Desktop/authorized_keys ~/.ssh/"
"chmod 400 ~/.ssh/authorized_keys"

All done. Go back to the original machine you created the key on. Fire up Terminal. If you are logged in as a network user destroy your kerberos tickets so that you can test it properly


Now try logging in.

"ssh your.server.com"

If it logs you into your server, hooray it worked! Now go have a cup of tea or something.

If not its troubleshooting time. Check the output of "ssh -vvv your.server.com" and see what comes out. Try repeating the process again or post a comment saying where you got stuck.

Further Reading:

18 Oct 2010

OS X Snow Leopard Server for the Home

With Apple’s introduction of the mac mini server some years ago they opened up a niche market. Perfect for the home or small office environment the server is a fantastic little machine that I believe should be a must have. But it sits there on the shelf and very little is said about it outside of the reviews on various sites around the internet. The reviews themselves go over the pros and cons of the machine; They talk about how much easier snow leopard server is to administer than previously and they herald the machines specs and features and give a balanced view of its shortcomings. Yet from my looking around there is very little reporting about what the server can do for the average family. This article will attempt to explain what the Mac Mini server can do for you in plain english and will link to individual tutorials when they become available.
The mac mini server at home
If your house has more than one computer then a mac mini server could be just what you are looking for without knowing it yet. This low powered machine can do much more than you ever imagined. If you know a little bit about computers and can follow some instructions then you should be able to get the server up and running in no time and be the lucky recipient of any or all of these benefits
Network user accounts: You want to use the computer to send some emails or work on a document but someone beat you to it and now you have to wait for them to finish. If you give all your family network user accounts then this is no longer a problem. Your documents and emails follow you around no matter which computer in the house you are using. You can simply sit down and log on at any computer you choose and everything is where you left it. Save games are always there, internet bookmarks, your dock is always the same. To top it off your kids can only use the computers at certain times on school nights and you can pick and choose what programs they can use. 
Time capsule replacement: I have a lot of laptops in my house and plugging them into portable hard drives to back up all the time was a pain. I could have bought a time capsule and had them all back up wirelessly with that but a mac mini server can do exactly the same thing. I have an external hard drive plugged into my mac mini server and set it to be a time machine backup share. Then all the computers in the house can back up over the air!
Mobile calendar and contacts for free: Thinking of getting mobile me so your phone and computer can stay in sync? The mac mini server can do this for you. Set up your mac and your iPhone and they all use the same calendar and contacts from the mac mini server. Each person in your family can have their own calendar and you can use it to book in visits to grandma or nights at a friends house and see when everyone has free time. You can even use the calendars to book time on the family computer or on the TV or Games Console and put and end to squabbling.
Host your own website for free: Want to host your own website but can’t find anything thats good and free? If you’re not expecting thousands of visitors an hour then you can easily host your website on your home internet connection. As your mac mini server will be on all the time anyway for all the other things it will be doing for you then this is a great opportunity to use it to keep your own blog and let everyone see how you’re getting on. It works well with iWeb too for easy site building.
Streaming internet TV: in the UK we have iPlayer, 4OD, Sky player and many other TV channels giving us their great content online. If you have ever wanted to watch these online TV channels on the actual TV then just plug you mac mini server in to your HDTV and you can use it to do just that! As well as being able to stream from the internet you can watch anything from iTunes and anything on Youtube. You can use the apple remote but I recommend getting a wireless keyboard and Magic Trackpad for the ultimate home entertainment system. Apple TV eat your heart out.