Today, I set up SVN on my server for a friend’s school project. While it’s not the first time I’ve set up SVN, it is the first time I’ve needed to restrict the users to a specific directory. Keeping in mind that I refuse to use Apache on this particular server, there would be no dav_svn.
Installing SVN
- Install SVN
- Create Repo
- ???
- Profit
apt-get install subversion
svnadmin create /path/to/svn/repo
…We’re done, right? Well, no. Not close. Remember, you wont find Apache on this server, so somehow, I needed to auth users. Now, I’m sure there’s a way to use SVN over FTP, but again, you’re lucky if you find an FTP server on this box… Cleartext passwords? No thanks.
Locking down an SSH User
I’ve never had the need to chroot a user before. Especially not a shell user. A quick google search brought me to a neat little script called make_chroot_jail. I installed the script in /usr/local/sbin/. Every time I tried to run the script, it would throw errors and never accomplished anything. I googled it and learned that the first line of the script, #!/bin/sh sometimes has to be changed to #!/bin/bash depending on the distro used. Once I did this, the errors stopped flowing. But I still wasn’t done. I originally thought I needed to use the full syntax:
make_chroot_jail.sh user /path/to/shell /path/to/home
but the script was including my absolute paths in a variable with paths already set. So /path/to/home became /home/jail/path/to/home. Additionally, it didn’t work properly, as I could still manage everything via ssh with that user. After some trial and error (and reviewing the script source again) I decided that simple is better. The new syntax,
make_chroot_jail.sh user
worked perfectly. It created a home directory based on the user inside of the jail. It also restricted the available applications to a select few standard apps. Unfortunately, this didn’t include the svn applications. This was easy enough to solve by adding the required apps to the APPS var, similar to:
APPS=”/bin/bash /bin/cp […] /usr/bin/svn /usr/bin/svnadmin”
I’m assuming that if you’re reading this and planning on doing what I did, you’ll notice that you need to change the line specific to your distro. If you don’t know what your distro is (or what “distro” means, for that matter), find someone familiar with Linux to do this for you.
I digress; At that point, I tried to connect to the SSH server but couldn’t. I learned that the supported jailed apps are actually copied into the jail. Nothing is updated realtime. I re-ran make_chroot_jail.sh user and it updated the jail, adding my svn apps. I still couldn’t connect to the repo, though. I wasted a lot of time on this part. SourceTree offered that it was, in fact, an SVN repo, and asked if I wanted to clone it to git. svnX claimed that it didn’t exist.
Beneficial vs. Detrimental
I like open source. I like free. Free + open source together are like ice cream to me. So I found svnX, a free, open-source SVN client for OS X. But if there’s one word I can use to sum up svnX: crap. Maybe it’s my lack of tolerance (bias) for applications that half-ass GUIs for CLI apps. Or maybe it’s the fact that svnX simply wouldn’t accept that I was using an authenticated user via ssh. I mean, in terms of GUIs, I’ve seen great… and I’ve seen worse than horrible. I could have gotten over the bad UI if the app had done what I wanted, but the fact that this app wouldn’t let me svn+ssh was a complete deal breaker.
What’s next? Versions. I’ve used it before. It’s got a great GUI. It makes sense. But since I primarily use GIT, forking out $60 on the app isn’t going to happen. Luckily, there’s a 30-day trial. Anyway, I downloaded it, plugged in my svn+ssh:// URL, and gave it a password. Boom. Instantly connected. And it worked. *Flawlessly.
Verdict
svnX: Detrimental to my workflow
Versions: Beneficial to my workflow
*Why wouldn’t there be a “But…”?
I said that Versions worked flawlessly. The app itself did. It even gave me a verbose and understandable error when I tried to commit rev 1 as a test. (Yep. There’s no way I’d be done with this project that easily.) The error was “attempt to write on a readonly database.” This one was actually easily enough to solve. I granted write perms to /path/to/repo/db/rep-cache.db and then it worked. No more hiccups on my end.
One more thing?
In the end, my friend, using Tortoise, told me that he has to enter the pass every time he performs an action. It looks like there’s no password caching in Tortoise. I generated a key, but we haven’t implemented it yet. I’m pretty sure that it will get fairly annoying during dev to have to stop to enter the pass all the time, and that’s where PuTTY / pageant will come in.
Closing Thoughts
All said and done, I definitely prefer GIT.
Leave a Reply