S3FS on CentOS

So, we’re using CentOS 5 for some of our servers; the ones we need cPanel for.  These are our shared setups with people running blogs, Joomla, Drupal, and such.

I’ve never liked FTP for anything due to its insecurity, slowness, and its inability to recover from even the simplest  of errors.

So I finally got our server provider to build a kernel with FUSE support built in so that I could use s3fs to mount an Amazon S3 bucket as a normal mount.

It was a little annoying to set up the first time but, when I had do it a second time, and had to go all the way back to the beginning, I figured I’d better write it down this time.

Install Subversion

First step is to get s3fs from its site at: http://code.google.com/p/s3fs/wiki/FuseOverAmazon.

I prefer to check out from Subversion but Subversion was not installed on my server.

A simple:

	# yum install subversion


gave me an error about a missing dependency:

Error: Missing Dependency: perl(URI) >= 1.17 is needed by package subversion-1.4.2-4.el5_3.1.x86_64 (base)


To make a long story short, I ended up downloading and installing the RPM directly with:

# wget http://mirror.centos.org/centos/5/os/i386/CentOS/perl-URI-1.35-3.noarch.rpm
# rpm install perl-URI*


Download and Install s3fs

Once I had subversion installed, I checked out and built s3fs:

# svn checkout http://s3fs.googlecode.com/svn/trunk/ s3fs-read-only
# cd s3fs-read-only/s3fs
# make install


There are a handful of warnings from the compiler, but I ignored them since I wasn’t particularly interested in working on the code.

Setting up Keys

You can invoke s3fs with your Amazon credentials on the command line, in the environment, or in a configuration file. Since command lines and environments are too easy for bad guys to find, I opted for the configuration file approach.

Create a file /etc/passwd-s3fs with a line containing a accessKeyId:secretAccessKey pair.

You can have more than one set of credentials (i.e., credentials for more than one amazon s3 account) in /etc/passwd-s3fs in which case you’ll have to specify -o accessKeyId=aaa on the command line.

Once that’s all set up, you can mount the S3 bucket mybucket at the mountpoint /mnt/mybucket, the command line is:

	# /usr/bin/s3fs mybucket /mnt/mybucket

Now, you can treat /mnt/mybucket as a regular copy destination including using it for rsync!

If you ever want to get rid of the mount, the normal unix umount command does the trick:

	# umount /mnt/mybucket


mercurial-server on CentOS or RedHat 5.x

So, as per my previous blog post, I got mercurial-server set up on one of our Ubuntu servers just fine.

Then I tried on one of our cPanel based CentOS servers.

What a pain in the ass!

There has been an effort to get this working, somewhat, by adding a new target to the Makefile: `setup-useradd`.

This uses the RedHat/CentOS `useradd` command in place of Ubuntu’s `adduser`.

Unfortunately, because of the way the Makefile is set up, if you don’t have all the prerequisites for building the docs, the product only gets half-setup.

Rather than get all the prerequisites, I found it simpler to just whack the Makefile around to remove the documentation build from the Makefile.

Find the line that says:

`installfiles: installetc installdoc pythoninstall`

and replace it with:

`installfiles: installetc pythoninstall`

You’ll also have to remove the –system parameter to the `useradd` call on line 62 of the Makefile since it’s not supported and is not necessary.

Do those things, then use:

	# make sudo setup-useradd

and everything else will go just fine. If you need to build the docs, you’re on your own, I have no interest in getting CentOS all set up for this unnecessary step.

Serving Mercurial over SSH


I’ve been deploying our big Django application to all of our servers using a pretty slick setup with Fabric and rsync.

This worked fine when I was the only developer, working on my local machine and pushing to a Mercurial repository on one of our internal Ubuntu boxes. Since it was all local, I just used the server’s Apache setup and mod_wsgi and didn’t worry about security too much. The Linux box is completely firewalled off from the Intertubes.

However, as we get more people working on the code, and as we deploy to more servers, having the ability to update to and from our Mercurial repository is becoming more important. Just ask Jeff(rey), whose template changes I clobbered this afternoon.

Since the shared hosting on which I wanted to set up my Mercurial repositories doesn’t have mod_wsgi, nor is it really safe to put a ‘foreign’ module like that into a cPanel setup, I had to find another way to serve mercurial securely.

Also, since we’re finding that Apache and its threading model are consuming waaaaaaaayyyy too much memory under load, we’re moving toward lighter weight, single purpose servers for everything anyway.

So…I found mercurial-server.

It gives secure, tightly controlled Mercurial access over a simple SSH connection.

After I found the `.deb` file and was able to use `dpkg` to actually install it, things went pretty smoothly.

Setup instructions are pretty straightforward with the only part that confused me a little was extracting the key from SSH Agent with `ssh-add -L`. I wasn’t using SSH Agent so the directions didn’t work but once I figured out that al I needed in-hand was the public key, I was on my way.

The repositories are kept squirreled away in kind of an odd location that’s not mentioned anywhere, but that doesn’t seem to be much of an issue as long as that directory tree (`/var/lib/mercurial-server/repos/`) is getting backed up, I’m fine with wherever it wants to put it. The reason for that location, far as I can figure, is that the /var/ tree is supposed to be for things:

/var/ Variable files—files whose content is expected to continually change during normal operation of the system—such as logs, spool files, and temporary e-mail files. Sometimes a separate partition.

At any rate, it took a couple of hours to get set up right and, while speeds don’t seem to be quite as good as they were running under Apigche, it’ll work just fine for my automated setup.

Now, to figure out how to get hooks to do all the necessary pushing and pulling for me…

To see how to get this running on CentOS, see my next blog post. What a PITA!

Stupid Subversion on Stupid CentOS

After using Ubuntu for my day to day server for a while, I’m really realizing how much CentOS and yum suck.

oot@tequila [~]# yum -y install subversion
Loading “fastestmirror” plugin
Loading mirror speeds from cached hostfile
* base: pubmirrors.reflected.net
* updates: mirrors.gigenet.com
* addons: yum.singlehop.com
* extras: mirror.steadfast.net
Excluding Packages in global exclude list
Setting up Install Process
Parsing package install arguments
Resolving Dependencies


–> Finished Dependency Resolution
Error: Missing Dependency: perl(URI) >= 1.17 is needed by package subversion

Stupid miserable POS!

Quick Solution:

wget http://rpm.evopanel.net/rpms/perl-URI-1.35-3.noarch.rpm

rpm -ihv perl-URI-1.35-3.noarch.rpm

yum -y install subversion