I've recently started shooting a bit of film again so I 'scanned' and uploaded some of the results to Flickr. They're all in the linked album (along with some old ones I uploaded a good while ago). My scanning process isn't exactly typical - but that'll all be explained in a post that's coming soon...
GitLab is a great self-hosted alternative to GitHub. I'd set it up for other people before but it always seemed to be more hassle than should be to update and maintain (especially with it's monthly update cycle) so I'd never set it up for myself.
Thankfully GitLab now has omnibus packages available to make installation and maintenance much easier. Unfortunately these packages contain all of GitLab's dependencies including PostgreSQL, Nginx, Unicorn etc.. This is great for running on a server dedicated to GitLab but not terribly useful for my setup.
I already had a Postgres database I wanted to make use of along with an Nginx + Passenger setup for running Ruby application. The following describes the configuration changes I needed to make to fit GitLab omnibus into my setup.
The first steps are to create a PostgreSQL user and database for your GitLab instance and install your chosen omnibus package from www.gitlab.com/downloads. After performing the installation do not run
sudo gitlab-ctl reconfigure as per GitLab's own installation instructions, we need to add some config first.
The first bit of config goes in
/etc/gitlab/gitlab.rb, this sets up the external URL for your GitLab instance, configures the database and disables the built-in Postgres, Nginx and Unicorn servers:
Now you can run
sudo gitlab-ctl reconfigure, this should set up all of GitLab's configuration files correctly, with your settings, and migrate the database. You'll also need to run
sudo gitlab-rake gitlab:setup to seed the database (this is a destructive task, do not run it on an existing database)
Most of the above configuration comes directly from GitLab's omnibus configuration with a few customisations for Passenger. The main configuration options are correctly setting the user and group so there are no permission issues and ensuring that the correct directories exist in the
$PATH variable to prevent errors in GitLab's admin interface.
Currently, files uploaded into GitLab may not appear correctly using these instructions due to a permission issue, this should be corrected with a future omnibus release, more discussion can be found in this merge request.
And we're done.
That's about everything, hope it works for you too.
Considering that an internet connection is now deemed to be a human right you'd think that ISPs, that generally seem to rip us off anyway, would've managed to make their connections nice and reliable, especially when you take into account that the internet has been round for a good few years now and they've had plenty of time to get it right. Unfortunately this isn't the case & I decided that I wanted a way to make sure that I wasn't getting (too) ripped off by my ISP.
To this end I decided to make the use of the tools I already had available, a Raspberry Pi that I've been running as a home server, the Munin monitoring tool that I use to keep track of it & the always reliable Speedtest to test the connection.
(The following is entirely Debian & Munin 2 biased, you may need to tweak it for your particular setup.)
The first job was to find some way to run Speedtest from the command line, fortunately while I was stumbling around the internet I came across speedtest-cli which makes life much easier. So first we need to get a copy of the script and put it somewhere:
(You'll probably be needing to make sure you have a copy of Python installed too, for more info check out speedtest-cli's GitHub page.)
Then we need to get some useful numbers from the script, we do this as a cron job because the script can take a while to run, use a lot of bandwidth & tends to timeout when run in Munin directly.
Create the file
/etc/cron.d/speedtest containing the following (modifying the speedtest-cli path to suit your needs of course):
Finally we need a Munin script to create the graphs, the script below should go in
/etc/munin/plugins/speedtest, don't forget it make it executable too, or it might not run (
chmod +x /etc/munin/plugins/speedtest):
Finally, restart munin-node (probably something along the lines of
/etc/init.d/munin-node restart), give it an hour or so and enjoy your new statistics.
Check back soon.
As part of the project I'm working on at the moment I wanted a way to automatically update a targets build number in Xcode. My preferred setting for the build number is the current SCM revision, the script below automatically updates the build number in the Info.plist file each time the application is built.
Just add the script as a 'Run Script' build phase for your chosen target in Xcode. The script is only designed for Git, SVN & Git-SVN as they're all I use at the moment.
Check back soon.
And while I remember, you can also find out a little more out about.me at alexpardoe.co.uk.
Check back soon.