Apache, nginx, Scripting, SVN

My tasks for the weekend

This is my plan for the coming weekend. In hindsight, I should have done all this over Labor Day weekend, but what do you want me to say – I was busy watching Netflix and eating oreos. This is likely going to be an uber-rough post, so my apologies.

Format / Update

  • Backup computer
    • SQL databases should be backed up separately for easy retrieval…
  • Format
  • Install Lion, upgrade to Mountain Lion (I wish there was a ML thumb drive… Maybe I’ll format, upgrade to Lion, purchase Mountain Lion, roll my own and re-format to keep things super fresh/clean)

Restoration / Rebuilding

  • Restore the bare minimum:
    • Dev Frameworks
    • Standard Apps (ST2, CS6, iTunes, etc.)
  • Install new AMP stack if OS X-default isn’t sufficient
    • I use an NMP stack currently… I’d love to keep using it but all of our client sites run on Apache… Perhaps Apahce on 80 and nginx on 8080.
    • Reminder: Setup music proxy
  • Reinstall Parallels and recreate my VMs (Debian, Ubuntu, Trixbox, Windows via Bootcamp)

Setup Version Control

I’m still thinking about how I want to do this, but what I’ve got so far, and very likely to change…
  1. Most likely git
  2. If possible, mirrored in two locations:
    1. External HDD
    2. My webserver
  3. Again, if possible, it should keep the last 3-5 revisions locally in case I need to revert without access to remote repo.
    1. Somehow this should all sync and not delete older local revisions until synced with the remote repo.
  4. I also want to write a script that will package a site / project when I’m finished… Ideally, it would:
    1. Export all linked databases (I’m fine with providing credentials and db names)
    2. Grab the latest revision
    3. Create a text file with:
      1. the path of the git repo
      2. the command I ran to generate
      3. the date, time, and location (work/home… manual entry)
    4. Tar it all and open a finder window with the file highlighted
I’m not sure if all that is possible because I don’t know nearly enough about git, or applescript / shell scripts, so this will be a good learning experience.

Final Thoughts…

Wish me luck.

Debian, SVN

Setting up a chrooted SVN environment

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

  1. Install SVN
  2. Create Repo
  3. ???
  4. 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.

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.