Fetching Github PullRequests easily

Github has got a nice and handy feature with pull-requests, you all know this.

But how do you fetch them fast and without any effort?

Lazyfrosch had a solution for this. Github uses a specific “namespace” to store the refs of pull-requests. Any normal git-client won’t fetch it, so the repo stays clean for a normal user. We have to modify the git-client.

Lazyfrosch does this for it:

git config --add remote.origin.fetch "+refs/pull/*:refs/pull/*"

This gives you refs like:

refs/pull/123/head  ->  the HEAD commit of the PR to merge
refs/pull/123/merge ->  the commit of the merged branch
                        (when merged to e.g. master)

Let’s modify this a bit. IMO this gives me too much information.

Do I need the merge commit? I don’t need it.

$ git config --add remote.origin.fetch "+refs/pull/*/head:refs/pull/*"
$ git checkout refs/pull/123

What do I do, if I’ve got multiple repositories, where PRs are happening?

This can be handy, if you commit into an organisation repository, but have your own fork, where others may create PRs, too.

Just add the remote-name to your local refs:

$ git config --add remote.<remote>.fetch "+refs/pull/*/head:refs/pull/<remote>/*"
$ git checkout refs/pull/<remote>/123

I don’t want to type ‘ref/..’ at first.

This is maybe a hack, but I’ve done it ūüėÄ

$ git config --add remote.<remote>.fetch "refs/pull/*/head:refs/remotes/<remote>/pull/*"
$ git checkout <remote>/pull/123

This is now, like you would reference any other branch from the remote-repository.

Make the configuration globally available.

You don’t have to add this manually anymore to the git repo. But it has got asmall drawback.

$ tail -n 4 ~/.gitconfig
[remote "origin"]
    fetch = +refs/pull/*/head:refs/remotes/origin/pull/*
[remote "upstream"]
    fetch = +refs/pull/*/head:refs/remotes/upstream/pull/*
$ git init
$ git remote show

Even with no added remotes, you’ll have instantly the upstream and origin remotes.


This is all together:

$ cd path/to/repo
$ git config --add remote.origin.fetch "+refs/pull/*/head:refs/remotes/origin/pull/*"
$ git fetch
$ git checkout origin/pull/123

Now you’re on the head commit of the PR with ID 123, you can test it now on your own.

Enabling a bridge on your ArchLinux-Setup with systemd

So today I set up my Hetzner-Host again with ArchLinux, but this time I wanted to use additional IP-Adresses for Virtualisation with libvirt. For this, I configured systemd-networkd as described on the Hetzner-Wiki (Heading: Routed (brouter)). But there had been a few problems, as it seems, that systemd does not support the full configuration-example in its state right now.

At the end of the day, I used these files in /etc/systemd/network on my dedicated host:

MACAddress=<the mac of your host goes here>
#Fill in here the Main IPs for your Hosts
Source=<Your Additional IPv4>/32
Destination=<Your Additional IPv4>/32

Before we can start the Virtual Machine, we have to get a new MAC-Adress from Hetzner, which is generated by the Robot. It may need some time to generate it.

curl -u login:password https://robot-ws.your-server.de/ip/<your additional ip>/mac -X PUT

If you need further information, you can get it at the Robot-Page in the Wiki.

We have to use this MAC-Address now for the Host, which is using the additional IP. Otherwise, Hetzner denies traffic from your additional IP.

After you have added the MAC to your VM, use the additional IP on your VM with the same subnet- and gateway-information as your host.

MACAddress=<the generated mac address>

# mind, that the IPv4-Subnet-Information is NOT 32 now
Address=<Additional IPv4>/Subnet
Gateway=<Gateway v4>
Gateway=<Gateway v6>
# these are the DNS-Servers from Hetzner today

If you have got any questions, drop me a line, and I may be able to help you.

Installing Archlinux on a Hetzner Dedicated Server with installimage

Update: This is not necessary anymore. You only have to boot into the Rescue-System and then execute installimage. After mailing fixes to Hetzner, ArchLinux is now integrated into the installimage-system. It is available and always a fresh install, but not yet officially supported!

I had to reinstall my dedicated server which is hosted at the Hetzer Datacentre. The first time I installed Arch on it, I used the method “Install from existing Linux” which is described in the wiki quite well.

Hetzner supports a system which is called “installimage”. Unlike others it has only a command-line-interface and no webinterface, but is highly configurable with textfiles and capable for mass-installations.

So you could be able to install your own images pretty easy with a few lines of code, but Hetzner claims that there is only support for Suse, Debian (Ubuntu) and CentOS.

But as I read the source-code of installimage I found out there are some arch-specific files there and the arch-install-tools package is also installed on top of the debian-based rescue-system.

But the only question is, how to activate the arch-specific config in installimage?

Ok, here I will show you how to generate an Image to mass-deploy arch-linux on your Hetzner dedicated hosts.

I will group the whole installation into 3 parts:

  1. Generate an Arch-Image
  2. Install Arch with installimage
  3. Configure your Arch-installation

Generate an Arch-image

The image you have to generate is very easy to do:

mount -t tmpfs -o size=2g none /mnt
#here you can add your own packages like vim, nano or sl
pacstrap /mnt base base-devel linux
cd /mnt
tar caf /tmp/Archimg.tar.gz .

You can do this on every Arch-based system, even on your Hetzner-box which has the arch-install-tools installed.

If Pacman hangs generating your PGP-Keys on it, it lacks of entropy on your Hetzner-Dedi. With the rng-tools package you can generate some entropy. After executing those commands execute pacstrap again.

apt-get install rng-tools -y
rngd -r /dev/urandom

If you did not create your image on your dedi-box, you have to copy it either to a download-server or directly with scp to the dedibox

scp  /path/to/Archimg.tar.gz root@archbox.example.com:/root

Install Arch with installimage

Now you have to copy the install-image configuration to your system. Use the following content and edit to your needs. The Hetzner-Wiki article installimage has a good documentation about the configuration-options.

DRIVE1 /dev/sda
DRIVE2 /dev/sdb
HOSTNAME archbox.example.com
PART /boot ext4 2G
PART swap swap 2G
PART /    ext4 all
#make sure, that your filename begins with Arch, otherwise the installation will fail!
#for example:
#Archinstall.tar.gz is ok
#Archlinux.tar.gz is ok
#archlinux.tar.gz is _NOT_ good
IMAGE /tmp/Archimg.tar.gz
#IMAGE https://example.com/path/to/your/Archbox.tar.bz2

We have to have another configure-script to fulfill the base-installation of Arch:

#postinstall.sh to configure your arch-installation

#configure timezone
ln -s /usr/share/zoneinfo/Europe/Athens /etc/localtime
#configure locales
cat &amp;gt; /etc/locale.gen &amp;lt;&amp;lt; EOF
en_US.UTF-8 UTF-8
de_DE.UTF-8 UTF-8

cat &amp;gt; /etc/locale.conf &amp;lt;&amp;lt; EOF

#add mdadm support
sed -i 's/^\(HOOKS.*block\) \(.*\)/\1 mdadm \2/g' etc/mkinitcpio.conf
mkinitcpio -p linux
grub-mkconfig -o /boot/grub/grub.cfg

#enable sshd
systemctl enable sshd
#enable the configuration generated by installimage
netctl enable ethernet

rm /usr/lib/udev/rules.d/80-net*
pacman-key --init
pacman-key --populate archlinux

Install the system now with installimage:

installimage -x postinstall.sh -c arch-installimage.conf

After that, your system should be bootable and you should be able to login with root and the given password from the rescue system.

If you want to make further modifications just mount your root to /mnt and boot to /mnt/boot and execute arch-chroot /mnt bash.

√úberarbeitung wirtemberg-gymnasium.de

Hier m√∂chte ich mein aktuelles Projekt vorstellen. Kurz bevor ich ehemaliges Gymnasium im Juni letzten Jahres verlassen habe (Yay, Abi ’13) wurde ich gefragt, ob ich die Website technisch betreuen k√∂nnte und das ein oder andere Feature hinzuf√ľge. Daraus wurde nun ein kompletter Wechsel von Design, CMS und Domain und in gro√üen Teilen eine √úberarbeitung sowie Neustrukturierung vom Inhalt.

Was habe ich da genau gemacht?

  • Wechsel des CMS von Contao zu WordPress
  • Kaufen einer neuen k√ľrzeren Domain (wiggy.de anstatt wirtemberg-gymnasium.de)
  • Konvertierung in ein Blogsystem
  • Sicherung √ľber HTTPs
  • Schulung von allen Lehrern und vor allem der Schulleitung
  • Einrichten eines SEO-Konzeptes
  • und vieles Weiteres, das die ganze Website erst zu einer Website machen (Sitemap, WebmasterTools von Google, Piwik, Lehrer/Schulleitung-Benutzerrollen, … u.v.m.)

Keine Vorstellung, was das alles sein könnte? Die Antwort darauf ist einfach: https://wiggy.de