Darren Beale

My background task over the Christmas holidays was to ensure that I had the ability to give read/write access to a subversion repository situated on a machine within our corporate network so that staff or external contractors can access it via the interweb but without me needing to open up additional ports on our firewall.

The server running Debian ‘etch’ is sitting within our DMZ and is only open to the outside world via port 80 for apache and also for ssh listening on a non-standard port. Internally we can access the repositories using the svn:// method between the internal network and the DMZ using the standard svn password-db authentication (and the handy password caching that this provides).

To give external access it seemed a no-brainer that I’d tunnel over ssh especially when I found out that I could set it up so that authentication would be dealt with by maintaining system (i.e. ssh) users for remote access (which all relevant staff have anyway) and could then administrate separately my local-only svn users that access via the plain-text svn://method. On balance I figured this would work for me as I’d rarely need to give access to an ‘outsider’ and when I did then them having a non-privileged user account on the machine wouldn’t be a big deal.

In the end it turned out to not be too difficult to get working though there was a bit of hoop jumping; I was expecting as much after reading this in the svn book:

Once you’ve jumped through these hoops, your repository should be accessible by all the necessary processes. It may seem a bit messy and complicated, but the problems of having multiple users sharing write-access to common files are classic ones that are not often elegantly solved.

Permissions were the biggest issue and the first thing that I did was to add all external users to the svn group. I already have everything chmoded 2770 with owner/group being ’svn’ but when accessing over ssh the lock files (amongst others) are read-only for everyone except the svn user. To fix this I had to create two wrapper scripts for the svn and svnserve binaries respectively that set the correct umask:

#!/bin/sh
umask 002
/usr/bin/svn-real "$@"

…where svn-real is the renamed svn binary and this script is /usr/bin/svn, repeat for /usr/bin/svnserve.

That was pretty much it except that for external access the way to connect was slightly different. Firstly the connection ‘URL’ was of the form svn+ssh:// for example:
svn co svn+ssh://hostname/path/to/remote/project/trunk

Also, because we’re connecting over ssh via a non-standard port I needed to set an environment variable for the user on the client machine. To do so I simply added the following to their ~/.profile:
export SVN_SSH="ssh -p PORT_NUMBER".

That was it.

So, in summary to give external access all I now need do is:

• Create a system account on the svn server
• Add that account to the svn group
• Tell that user to create a local SVN_SSH environment variable so they connect via ssh over the right non-standard port

Complicated to set-up? Not really. Easy to administer? Yes. Secure? As good as I could make it.

The following is a no-frills install guide for getting Trac up and running on a Debian ‘etch’ Linux system.

The assumption is that you’ve already got mysql and subversion working and have created a subversion repository (tip: apt-get install mysql-server subversion).

The first thing that we need to do is install Python, easy_install and the mysql & python bindings:
apt-get install python python-setuptools python-mysqldb python-subversion

To install trac via the easy_install command I suggest that you see what is the newest version of trac:
svn list http://svn.edgewall.com/repos/trac/tags

I then picked the newest tag and then installed:
easy_install http://svn.edgewall.com/repos/trac/tags/trac-0.11b1

I want to use the - note: experimental - MySQL support so I create a mysql db and create a trac user:

mysql> create database trac;
mysql> grant all on trac.* to trac@localhost identified by 'password';

To test it is all working I create our first project:

trac-admin /export/trac/MY_PROJECT initenv

A number of self explanitory questions are asked, here are selected answers:

Database connection string [sqlite:db/trac.db]> mysql://trac:password@localhost:3306/trac
Path to repository [/path/to/repos]> /export/svn/MY_SVN_REPOSITORY

Finally, test it is working:
tracd --port 8000 /export/trac/MY_PROJECT

Visiting http://server:8000/MY_PROJECT gives me the standard trac web interface and I can browse the SVN repository. There, that wasn’t too bad was it? We do still need to get it all sensibly configured so once I’ve done that I’ll post another article.

Related:
http://trac.edgewall.org/wiki/TracInstall

More brain dumping, this time after setting up MySQL on my test server to replicate offsite as the data on there is becoming important.

To start with both machines are running fully updated and upgraded Debian Etch and MySQL 5 as a Debian package with identical copies of the MySQL databases in /var/lib/mysql/.

On the master I:

I ensured that bind-address was set to the machine’s IP address as by default it is bound to localhost (therefore not allowing external connections) in /etc/mysql/my.conf

Checked that the server-id and log_bin were set in /etc/mysql/my.conf

Issued the MySQL command GRANT REPLICATION SLAVE ON *.* TO 'USERNAME'@'SLAVE_IP' IDENTIFIED BY 'PASSWORD';

Issued the MySQL command FLUSH TABLES WITH READ LOCK; and then SHOW MASTER STATUS;, noting down the values of File and Position.

On the slave I:

Checked that the server-id and log_bin were set in /etc/mysql/my.conf (server-id being different to that of the master)

Issued the mysql command:

CHANGE MASTER TO MASTER_HOST='MASTER_IP',
MASTER_USER='USERNAME',
MASTER_PASSWORD='PASSWORD',
MASTER_LOG_FILE='FILE_NOTED_EARLIER',
MASTER_LOG_POS=POSITION_NOTED_EARLIER;

To check it was all working I used a combination of the MySQL command SHOW SLAVE STATUS; ensuring that all looked OK and simply made changes on the master and saw them appear on the slave.

If the slave is constantly showing “trying to connect” to the master when you show status then to debug make sure that it can telnet to 3306 on the master. If not then you have to ensure that there is network access between the machines and re-check the bind-address on the master.

Ok, if you ‘do’ linux then you’ll probably already know this one. I did, kinda, but had to Google to remind myself of the exact chain of commands. So here I am writing it down so it’s easier to find next time.

In my case I had a load of apache conf files where I needed to replace each occurence of an IP address with an asterisk. A combo of find and sed worked well:

find /etc/apache2/sites-available -type f -exec sed -i 's/192\.168\.255\.2/\*/g' {} \;

Need to move multiple subversion repositories?

Well I just finished putting a simple how-to together which details the steps I took when moving our 30+ svn projects from one server to another.

It went really smoothly and took about a quarter of the time I was expecting it to.

Anyway, here it is.

Related:

• Creating a subversion repository
• Automating subversion repository creation

I’ve just uploaded a blank Wordpress theme called Naked that I built to assist those (like myself in the past) who have a need to quickly roll-out a Wordpress theme with a custom look and feel but may not necessarily have the time to start from scratch.
It is purposely very simple and basic, but I’ve put some effort into making it self explanatory and for anyone with experience of PHP/XHTML/CSS it should be an absolute doddle to use.

Here’s the default look, woo!

You can download it here, enjoy.

This morning I’m debugging an issue on a script that gets cronned every minute. I’ve a shell open on the server and the file in question open using Vim and I notice each line has a trailing ^M…. Aargh the dreaded DOS linebreak.

Dusting off my rusty vim-foo I simply do a search and replace using Vim without having to exit the file.

The command is:

:%s/^M//g

Job done, well actually no, there is still an issue with the script but now I at least know that ^M is not the culprit.

Note: To get the ^M I did NOT type a caret and M, I typed Ctrl-V then Ctrl-M

My old man has been getting into finding out more about our family history. Most of his research so far has been by talking to one of my second cousins in Lowestoft who as already done a fair bit of digging. Through her he’s found out that his Mum originated from Cheltenham (I always thought she was born and bred Welsh) and her family name, Pritchard.

Anyway, not being one who can tell the front from the back of a computer he genuinely impressed me the other day when he told me to Google for Cheltenham fire brigade which I then did coming up with this page.

This is the first picture taken from that page and amongst others it shows a C and a W Andrews. Apparently C Andrews is my great great uncle and W Andrews is my great great grandfather (my Nan’s grandfather).

Fascinating (if you’re me).

Today we stepped off the property ladder with the sale of our house in London completing for the asking price and with the money that we’ve gained over the last 10 years of house price inflation being placed in a high interest savings account.

Our feeling is that the worst that’ll happen is that we’ll lose out on a further gain but that most likely our savings at today’s rates (if you shop around) of around 6.2% AER will likely beat the median estimations of HPI at around 5% for the next 2 years or lower. There are also many camps that are screaming about a crash but there are so many factors to consider that our heads begin to spin so we’re simply going to sit it out for a while and see what happens. My gut feeling is that a price correction downwards is most likely.

Of course there’s much, much more to owning a home than simply making some cash. Renting for the past 12 months has shown us the negative aspects of being a tenant including the general insecurity that you may get kicked out next month and simple things like not being able to replace - say - the crap cooker or boiler. It’s also very important to have a stable environment for the little ones to grow up in and not have to deal with things like changing schools every 12 months; we can see that this sort of thing is certainly worth a premium.

Hence we may still buy, indeed over the past few months we’ve looked at over 20 houses, but with another baby coming and general uncertainty over the stability of the economy - what with being self employed and all the US shenanigans too - we’re very definitely going to hold off now until the new year at an absolute minimum.

Morris wanted a ’scary’ pumpkin and Eden wanted a ‘pretty’ one, here’s the best that Daddy could muster.