IT

As I'm keeping code for my diploma thesis in git and svn atm (various reasons, don't wonder) and I've got a few windows boxes, I've come to see that git+windows isn't always an easy task.

So that I shall forever remember what to do, here's it:

a) open up puttygen
b) import openssh private key
c) save as whatever (putty format)
d) open up putty
e) save a new session:
* gitosis@host.example.org
* port 22 or whatever
* Connection -> SSH -> Auth, select the converted putty key from c) or use pageant
* session name: gitosis_host or something
* important: save to registry, not to file
f) git clone gitosis_host:project.git

We had this server, you know, a really old server. It still ran openSUSE 10.2, which is baaad, mkay?
So there was a plan. A brilliant plan. Let's upgrade it to 11.1. No clean install, no DVD, just netinstall.

Then there was silence, because neither the openSUSE websites nor the oracle had any decent hints, all to be found was "OMG ITS DEAD, HALP!"

So the drama began. Disabling all services except sshd was the first step
The plan would be to be a bit conservative and go 10.2 -> 10.3 -> 11.0 -> 11.1, so the second step was to get a decently fresh version of zypper that supports the dup parameter (dist-upgrade).
So off to software.opensuse.org and grab the RPM.
Next came a mass of rpm -Uhv --test [whatever].rpm accompanied by an RPM search for the missing libs and a whiteboard drawing of dependencies as I didn't want to resolve em automatically to avoid completely destroying the system.
Lucky day, after 10 RPMs we had a fresh zypper. Just.. doh, it was a 10.3 zypper without dup. But luckily there was a backport of an 11.0 zypper version for 10.3 and with like 3 more dependencies and an enhanced whiteboard drawing it was done.
The rest went quite normal like described on openSUSE - Upgrade.
- zypper ref, zypper dup, fetch 320 MB
- check /boot/grub/menu.lst, whee, new kernel.
- reboot
- no ping, grab serial console
- doh, it's root(hd0,0) and not root(/dev/md0)
- woohoo, booting up
- uname -a shows a correct kernel, but yast won't start. whatever, next step

From then on it was just following the aforementioned upgrade procedure with additional attention to be paid to not forget zypper in zypper after each zypper ar and a few zypper ref inbetween and upgrading rpm as well. cpio: Bad magic is not something you like to read. (Reminds me of magic_quotes_gpc, what the hell. MAGIC. As in mushrooms, I swear. Ever heard of determinism?
relogin_suggested in yast/zypper is also something that's badly named, it means: "reboot your damn box" - and you should.
Total traffic: about 330MB per Upgrade, so not more than 1GB for 10.2 to 11.1

So, after a few hours everything looks fine, except for a postgrey that switched from tcp sockets to unix sockets without telling anyone and of course overwriting postfix config files. Positively surprised the SuSEfirewall2 rules were all still intact. yast was starting again and after adding the updates-repo and some more zypper up I called it a night.

Ever since I've played around with my sixxs.net ipv6 tunnel I - obviously - had IPv6 on my main workstation, which happens to run on Windows XP Pro.

So far nothing weird, but I just fixed a problem - which is related to this ipv6 stuff.

I've had problems with really slow loading times on two websites, one a blog and one is www.python.org/docs.python.org

Today I was fed up and tried to search for faster python doc mirrors, but I had no luck.
So a ping told me it had an ipv6 address because I wanted to exclude a slow DNS, so I planned to put [ip] [hostname] into my hosts file.
Wait... I just remembered that one blog also showed me a v6 IP on pinging, but I've never bothered as I mostly read it via feedreader anyway. So I removed the ipv6 driver from my primary NIC (it had been disabled already for months), had to reboot and... wow - docs.python.org is fast again and when I ping it I get the v4 IP.

Very weird. And again - Windows sucks for Networking stuff and I love my eeePC to troubleshoot. Don't wanna know how much cygwin-fu I'd need to get arping running. If at all...

Filezilla also always tried to update from a v6 IP that couldn't be reached (without the tunnel) - so probably that will now also work...

So, I've had this project that's been in svn for a while, but then a year ago I forked it and worked on it in git. Much smoother anyway :P.

But now I wanted to put it back to svn (into another repository) while preserving the history.

I found these hints, but neither worked out:
http://markpasc.livejournal.com/186297.html
http://its.arubything.com/2009/1/4/commit-a-linear-git-history-to-subversion
http://stackoverflow.com/questions/457694/how-to-commit-a-git-repo-to-an-empty-repo-svn-server
http://wiki.apache.org/general/GitAtApache

So with the help of our local git hero himself it came to a happy ending:

$ git svn clone https://svnrepo.example.org/repo/whatever [ -r XX]
$ git fetch ~/code/repo.git mybranch
$ git checkout FETCH_HEAD
$ git branch tomergeTEMP
$ git checkout master
$ git rev-list --reverse FETCH_HEAD  | head -n 1
-> de53700000000000000000000000000000000000
$ git rev-list --reverse HEAD  | head -n 1
-> 2a74500000000000000000000000000000000000
$ echo de53700000000000000000000000000000000000 2a74500000000000000000000000000000000000 > .git/info/grafts
$ git rebase tomergeTEMP
$ git svn dcommit --dry-run
$ git svn dcommit
 

To elaborate a bit:
a) clone the svn repository. empty one (with trunk/branches/tags created is perfect)
b) fetch the branch mybranch from a git repo
c) check out FETCH_HEAD
d) branch it to a temporary name
e) get back to master (master of the *new* repo that was cloned)

now the interesting part. with grafts you can merge history lines, it needs 2 commit sha-1 values.

f) get the first one
g) get the second one
h) put them into .git/info/grafts (format "X Y", value one, single space, value two)
i) do a rebase from the temporary branch
j) dry-run to check you have several diff-tree ... lines (one for each commit in the git repo)
k) really commit to svn if the last step looked reasonable. This will take a while, as it does one svn commit per git commit

update: just found a helpful thread on stackoverflow:

Create a file .git/info/grafts and put the two sha's on a single line there. The first is the first git commit, then a space, then the last svn commit. This tells git that the git commit is not parentless, but has in fact the last svn commit as parent.

Been mostly busy with my diploma thesis, moving, a bit of WoW and a bit of tinkering.

I've installed Munin yesterday to play around with it and I'm immensely impressed.
Muchinteresting information amd set up for master + 3 nodes in ~20min with no former experience. From reading the docs, the Debian/Ubuntu packaging maybe played a bigger part here than with some other packages.
Going to let it run for a few days now then I'm trying to make sense of it all.

I've also dug a bit deeper into Nagios, but the configuration format is much less attracting. Then again the tools are only slightly related and it would probably be best to let Munin report to Nagios, we'll see if that's to be done anytime soon.