I have been able to cajole my random-number-of-charges to help with installing Ubuntu on a stack of old machines prior to donation (5 so far!), taught some of them how to solder, and exterminated a horde of vermin from the call center, but no real traction. That will wait for summer camps to start!
After the last Stanford project I promised myself I would jump ahead from the 2.4 era of Sakai Stanford has been using. I took a peek at the K2 stuff - The white paper was sensible, Zach's notes useful... so I finally picked up Maven 2 and git. Too bad today was the same day the Sakai confluence was down for a brain trainsfer. I commenced to downloading the current binaries.
One goal floating around is to upgrade the kitchen Mac Mini to an Intel based Mini. The current Mini becomes a server in the call center. I wanted to run a CZWXLLC svn server outside of the graces of Stanford, and so went through the steps to get a svn server on the G4 mini. I did the simplest possible thing I could do. That is to get the server deployed running via the svn:// protocol and constantly accessible from within the imperial home network.
It wasn't that bad. Here is a rough outline:
- install the SVN package somewhere sensible. I used /usr/local/bin. that may not be sensible to you, but it was sensible to me.
- figure out which user is the 'login' user, if you have one. The Kitchen computer happens to have one - we want Skype up when Mitchell is on the road, so it's always ready to go.
- use svnadmin to create a repo directory somewhere where the login user has rights. I just used the user's home directory.
- update the user configuration files with your various users and assign passwords
- start svnserve
To get your svn server to start up after a restart is the real goal. To do that you're going to have to use the Mac OS launchctl tool.
launchctl is used to configure the launchd daemon. The idea is that you want the box to boot, scoot through a set of 'scripts' and fire up basic services. init.d stuff like stuff.
The 'scripts' are XML configuration files. They are stored in /Library/LaunchDaemons, and by convention are '.plist' files. These contain a namespace registration mechanism and a way of passing in command line arguments. Take a look at the files on your own machine - it's pretty straight forward, yet as with most of these abstractions rather opaque - what the heck are the options? the options for svnserve itself are fine, but what about the OS?
For svnserver I used one found here. Be sure to change the path to the repo, the user and the user's group as necessary for your machine.
More sophisticated schemes would have non-login users, separate groups, etc., etc., but I didn't think that was necessary for getting off the ground.
As this repo is behind the CZWX firewall this is as far as I've gotten. If I put it into the DMZ when I drop it into the call center I'll have to upgrade the connections to SSL and all that jazz.
Onward! Next steps are to get the most recent Sakai checked out as well as the K2 stuff and see about getting some edgeless administration stuff going on these phones.