Archive | October, 2012

Getting an SVN post-commit update hook to work

14 Oct

I’ve ALWAYS encountered some form of trouble while trying to set up a post-commit hook, and the list of prerequisites are seemingly endless when you’re trying one solution at a time off the google pages.

 

Therefore, here’s a list of things to check off!

  1. The post-commit file must be executable. ( chmod +x post-commit )
  2. The post-commit script should begin with the shell command. ( #!/bin/sh or #!/bin/bash )
  3. The path to the svn executable should be absolute. ( /usr/bin/svn update )
  4. If authentication is required, make sure username, password and non-interactive flags are set. ( –username USERNAME –password PASSWORD –non-interactive)
  5. Make sure the destination directory is writable by root.
Advertisements

Getting SFTP to work for a limited user in a Linode

7 Oct

First of all, if I wanted to have my own website, it wouldn’t make much sense for me to host my own server too. I’ve been living with cPanel on shared hosting and it does a pretty good job of automating various tasks such as creating subdomains, databases and such.

No, the reason I wanted to host my own server, besides having shell access which was crucial for source control as it was one of the first things I set up on my new server – was to host multiple sites. Not subdomains, but whole domains. In particular, deanishes.com, a site where it is planned that you can observe the inspired progress of Dean’s tasks. Now while it is possible for him to manage his site through the wordpress admin panel, in all fairness that is insufficient for editing code. You can edit the theme files through wordpress, and I’ve even thrown on a pretty code editor plugin but nothing beats the power of IDE software, with code-completion, auto-formatting and syntax highlighting.

Therefore, I needed a way to provide Dean with limited access to the server – just to access his wordpress installation files. Which brings me to the what this post is about – allowing SFTP access to the server but in a limited capability.

First of all, my original idea was a FTP server daemon which would handle a separate set of users and logins. My first step was to head to the Linode library, which is pretty good except for not fully documented parts. As it is, it turns out that SFTP is preferred over FTP because of security issues. I’m all for best practices and am pretty flexible, so I did what was right – I looked into SFTP access instead.

As per Linode’s reccomendations, I had shut down all ports except for allowed ones such as SVN, SSH and HTTP. So my next step was to open a port for FTP/SFTP access. As it turns out, because SFTP uses the same port as SSH (the two are the same, really), I didn’t need to configure my iptables firewall rules – though I did spend a great deal of time googling “iptables allow sftp” when my previous attempts didn’t work, but that was eventually chalked to a different problem (file permissions).

Now, SFTP uses unix accounts to connect, much like SSH. I was initially apprehensive of this, but then I thought about the ramifications – having ten users in my linux installation? Why not? I’m not going to be a general webhost, and one user per site seemed pretty reasonable to me. But the crux of the matter was that I needed to customise this user – it could not be allowed to access anything other than the directory I’ve specified for it.

Which led me to the concept of chroot SFTP, which basically is a SFTP jail that starts the user in a predefined directory without access to other things. All that is needed is that the directory be owned by root, but any subdirectories can be owned by the user. At first I was trying the Linode solution, but that did not pan out. For some reason, the

ChrootDirectory

directive in the Linode library specified %h, but the one in the other article reccomended /<some directory/%u.

The former did not work out, so I resorted to following the other article’s example to the letter.

And what I’ve discovered is this -%h defaulted to the root directory / regardless of the home directory I specified in /etc/passwd, and instead started from / and attempted to browse to the home directory specified – but of course failed because it didn’t have the permissions to traverse directories.

So when I specified the ChrootDirectory to /<some directory>/%u, AND the home directory to be /, It worked fine and started in / of /<some directory>/%u.

So what I can take away from this is that /etc/passwd specifies the home directory RELATIVE to whatever root directory was provided, and the ChrootDirectory provides the root directory for the jail. Now that I’ve got it all working, it’s time to celebrate this with Dean!

-EDIT- It is important that /<some directory> be owned by root, because the shell requires access to login. Funny, huh? the shell requiring access.

Setting up SVN using svn protocol on Linode/Debian

1 Oct

In my previous experience, trying to get source control to function minimally was an extremely daunting task. Need to set up a repository? Good luck getting it to be publicly accessible. Therefore, when I was trying to set it up for the first time, I went with the basic out-of-the-box solution: Apache + WebDAV protocol. After all, it listens on the HTTP port and hey, I DON’T have to go dewy-eyed at those port numbers, do I?

 

But WebDAV isn’t that secure. After all, it’s a publicly accessible URL link. Sure, you could try security through obscurity, but at this point we’re getting paranoid. Who’s going to hack my 5 hits a year site for which the majority of traffic comes from Googlebot crawling for my very specific niche text content?

 

The point I want to make here though, is that there is an smoother way to get your repository out for access. And that is through the SVN protocol, or svn://, which uses the port 3690 by default.

 

I was afraid that i’d have to google quite a bit for obscure and incredibly specific solutions to my specific problem, but turns out that replacing the more specific” Debian/Linode” for “Linux” makes it general enough to fit my needs.

 

So let’s get started. Using the one-click (or keypress) wonder that is the Linux package manager, I did

apt-get install subversion

Of course, depending on your flavor of Linux, you may have to resort to

yum install subversion

instead. The version you get is as old as what the package manger fancies, and manual installation for the latest version is out of scope here.

 

Next, create a parent directory for the repositories, I went with /subversion. In it, create another directory to contain your first project. Then do

svnadmin create /subversion/myfirstproject

replacing with your project/desired directory layout, of course.

 

The next step for svnserve daemon access, is to have usernames and passwords! For some reason they’re stored in plaintext – by default in 

/subversion/myfirstproject/conf/passwd

Which, when I first discovered to my horror, was like one giant plot hole in the story of security. I guess it’s not bad considering that anyone being able to see it means you have far bigger questions about how they got into your server in the first place, but at that time I assumed that plaintext was for baddies. Anyway, add in a user password combo, examples area already given in the pre-generated file.

 

Now, if you’re like me, there is already an existing project for which millions of LOC (lines of code) are held in the indeterminate state of who wrote what?. Which is why I’m installing subversion in the first place – to keep track of my changes and facepalm at the silly variable declarations I did a year ago when “var” was a fancy keyword in javascript. I kid. No one is THAT clueless. Or better not be.

 

Regardless, navigate to the directory where your project resides, and then do

svn co file:///subversion/myfirstproject

Which is a shortcut for accessing the repository via the local filesystem. Now that the directory is one big working copy, let’s add in the files!

svn add –force *

svn commit –username user –password pass

 

Now we’re all good to go! 

Hello world!

1 Oct

Welcome to WordPress.com! This is your very first post. Click the Edit link to modify or delete it, or start a new post. If you like, use this post to tell readers why you started this blog and what you plan to do with it.

Happy blogging!