Hades Blag

Free PDF Readers

2011-04-09T06:39:20Z

You may want this link next time you look for a PDF reader on a system where there is none: pdfreaders.org

This client is too old to work with working copy

2011-02-24T08:11:00Z

Did you know, that in subversion you get this error message if you create a working copy with a new client and then try to do something with it using an old client? Seems screwed up but pretty reasonable, doesn’t? But get this: subversion will update your working copy even if you do something like “svn diff” or “svn ls” there with a newer client. And then your older client will bail out.

That’s pretty damn fucked up. That’s one of the design decisions you should not be allowed to make. I mean, subversion is actually pretty dumb by itself. So what was so special needed to be changed in those crappy .svn directories, so that old clients cannot understand it?

By the way, if you accidentally came here googling the error message: sorry, you’ll have to deal with this shit until you move to a less crappy version control software.

Aeacus: Reloaded

2011-02-06T16:54:47Z

I’ve cleaned up my Gentoo repository “Aeacus” and published it again. Feel free to use it, comment upon it, edit it, or whatever. Just add this URL to your /etc/layman/layman.cfg under “overlays”:

http://dev.hades.name/file/Aeacus/layman-list.xml

Gentoo Install Checklist

2011-03-17T16:50:02Z

If you want to install Gentoo you should read the Gentoo Handbook. However, if you (like myself) have already installed Gentoo for a couple (thousand) times, you know more or less everything that has to be done, but just need a list of things not to forget. So here it is:

fdisk # create the partitions you want
mkfs # create the root filesystem
mount root /mnt/gentoo
cd /mnt/gentoo
wget -O- ftp://mirror.switch.ch/mirror/gentoo/releases/x86/current-stage3/stage3-i686-*.tar.bz2 | tar xj
cd usr
wget -O- ftp://mirror.switch.ch/mirror/gentoo/snapshots/portage-latest.tar.bz2 | tar xj
cd /mnt/gentoo
mount -t proc proc proc
mount --bind /dev dev
cp -L /etc/resolv.conf etc/
chroot . /bin/bash
env-update; source /etc/profile
emerge --sync
eselect profile set default/linux/x86
vim /etc/make.conf # setup USE, CFLAGS, CXXFLAGS, MAKEOPTS
vim /etc/locale.gen # setup locales
locale-gen
emerge gentoo-sources # configure, build and install the kernel
vim /etc/fstab # setup the partitions, don’t forget root, swap
vim /etc/conf.d/hostname # setup hostname
vim /etc/hosts # add the hostname to localhost line
passwd
vim /etc/conf.d/clock; emerge --config timezone-data # setup timezone
emerge syslog-ng vixie-cron mlocate
rc-update add syslog-ng default
rc-update add vixie-cron default
emerge reiserfsprogs xfsprogs jfsutils e2fsprogs # or whatever set of FS you have
emerge dhcpcd
emerge grub
vim /boot/grub/grub.conf # configure Grub
grep -v rootfs /proc/mounts > /etc/mtab
grub

Now reboot and smell the ashes!

Your Own Git Hosting: Gitolite

2010-12-02T17:53:52Z

So, let’s start with setting up gitolite to host your repositories and provide SSH access to them. There is also a tool called gitosis, but it is not as supported and featurefull as gitolite.

So what does it actually do? In essence, all the developers that will access your repositories will login to your server as user “git”, run server-side git daemon and sync data with it. Gitolite will determine if a user has access to perform operations he is going to. Ok, but why bother with all this crap, and not just create a bunch of users on the server and tell them where is the repository? There is a couple of reasons.

Firstly, you may not want to give your developers shell access to your server. Why wouldn’t you? Who knows, probably because they are stupid or malicious, or whatever. With gitolite they won’t get a shell access, because they will only be able to login with their SSH keys and that SSH keys will be restricted to invoking gitolite only. At this point you may want to read up SSH manual on keys and command restrictions, if you do not yet know about it.

Secondly, you may want to impose certain access restrictions on them. Gitolite allows to restrict read write and rewrite down to per-branch level.

Thirdly, with local multiuser git access you have to fiddle a little with umasks or write a hook that fixes the permissions, but that’s unimportant and uninteresting.

Fourthly, you may even not have a root access. That’s right, gitolite allows you to setup multi-user repositories on systems where you have only one non-root account.

So let’s go ahead with installation. The INSTALL doc is rather straightforward and you should in fact read it instead of this blog post. I am not offering the text below as a setup instructions, but merely as a log of how I installed it on my server.

First off, we require some git on our server. Please be careful to use as fresh git as possible, because it generally tends to gets even more super awesome with time. Also gitolite requires at least git 1.6.2 at the time of writing of this post. Unless you use especially sucky distribution (ahem debian ahem), you should be fine with git from your repository. I just told Portage to install me one:

    emerge -av git

Although gitolite has an ebuild in Gentoo, I set it up manually and will walk you along the procedure. First, lets obtain the sources:

    git clone git://github.com/sitaramc/gitolite.git

This will create a “gitolite” directory with gitolite sources. Let’s create a system directory for gitolite. I use /opt for all non-Portage packages, so let’s go ahead with:

    GITOLITE=/opt/gitolite
    sudo mkdir -p ${GITOLITE}/{bin,conf,hooks}
    sudo chown -R `whoami` ${GITOLITE}/{bin,conf,hooks}

You may of course use another set of directories if you want. Next, we let gitolite install itself wherever we want it:

    ./src/gl-system-install ${GITOLITE}/{bin,conf,hooks}

This takes three arguments: directory for binaries, directory for configs and directory for hooks. Also this is the same command you would use to update your gitolite installation after you git pull the new sources.

We would now require a user account for git. Let’s create them!

    sudo groupadd -r git
    sudo useradd -d /srv/git -g git -m -r -s `which bash` git

This creates a system (-r) group git and a system (-r) user git with home directory (-d) /srv/git and shell (-s) bash, in group (-g) git, and creates its home directory (-m). Now login into your new git account. Don’t forget to add your ${GITOLITE}/bin directory to the .bashrc if it is not in the PATH:

    sudo su — git
    echo PATH='${PATH}':/opt/gitolite/bin/ >> .bashrc
    source .bashrc
    which gl-setup

Now copy over your public key to a file called username.pub and finalize gitolite setup by running:

    gl-setup username.pub

After that, follow the instructions, they should be fairly straightforward. Congratulations, you’re done! The gitolite’s configuration is stored in a Git repository under gitolite, so you’d want to clone it from your computer (i.e. where you have the private key for username.pub):

    git clone git@yourservername:gitolite-admin
    cd gitolite-admin
    vim conf/gitolite.conf

The file gitolite.conf is in fact your gitolite config file. After you edit it, save it, commit it and push to the gitolite-admin repository on your server, gitolite checks the config and makes appropriate changes to the repositories. To add users, just place their keys into keydir directory. It’s that simple! You probably would want to read official admin doc just about now.