Evolvis – Make it into a Project!

git rebasing considered harmful

git rebase is problematic (from a version control system user point of view) because it rewrites history. We all knew that.

But did you know that git pull --rebase, commonly used before a git push, can also be harmful, destroy history, and surprise users in a negative way?

10:08⎜ Lo-lan-do, we must have committed at the same time :) First time I rebase and my commit disappear ;)
10:11⎜«Lo-lan-do:#fusionforge» So who won?
10:11⎜«Lo-lan-do:#fusionforge» Aha, I did :-)

This does fit git’s model of managing patches and tracking content, but is just irresponsible for a version control system. (Also, imagine incensed contributors whose commits just vanish.) So, danger, beware of using git rebasing when you use git as distributed version control system!

In a related way: merge commits are good. Especially when merging between, into or from feature branches. (A friend had his .gitconfig set up to default to rebasing… ugh.) So there should have been one place where you used rebase: to avoid merge commits when people work on the same repository at the same time (but, ideally, on different files). Those were mostly annoying. But, as you can see above, the alternatives are even worse…

iCalender and timezones

Okay. I just created three events at tomorrow 10:00 CEST (08:00 UTC), on three different accounts on the very same Debian Lenny machine. All three use nxclient to log into KDE 3, with Kontact/KDEPIM Version 1.2.9 (enterprise35 20131030.a834355).

Then, I looked at the event invitations (METHOD:REQUEST BEGIN:VEVENT) in a simple eMail program (alpine). What I got made me beg to differ:

$ fgrep -e DTSTAMP -e CREATED -e UID -e LAST-MODIFIED -e SUMMARY -e DTSTART -e DTEND s?

s2:DTSTAMP:20140812T114542Z
s2:CREATED:20140812T114541Z
s2:UID:libkcal-1345193151.365
s2:LAST-MODIFIED:20140812T114541Z
s2:SUMMARY:sk2
s2:DTSTART:20140813T080000Z
s2:DTEND:20140813T100000Z

s3:DTSTAMP:20140812T134551Z
s3:CREATED:20140812T134550Z
s3:UID:libkcal-579827798.725
s3:LAST-MODIFIED:20140812T134550Z
s3:SUMMARY:sk3
s3:DTSTART:20140813T100000Z
s3:DTEND:20140813T120000Z

s4:DTSTAMP:20140812T134559Z
s4:CREATED:20140812T134558Z
s4:UID:libkcal-743876151.470
s4:LAST-MODIFIED:20140812T134558Z
s4:SUMMARY:sk4
s4:DTSTART:20140813T100000Z
s4:DTEND:20140813T120000Z

I should mention that I created the events at roughly 13:45 CEST today (11:45 UTC), and the system timezone on the box as well as the “Time & Date” zone in the Kontact settings are all “Europe/Berlin”.

To add insult to injury: the calendar view on the accounts that created the event all do show it for tomorrow, 10:00 local time.

I cannot possibly imagine how this could go wrong, seeing as those are all on the same machine…

WTF is going on here?


Update: .kde/share/config/korganizerrc had TimeZoneId wrong. I had to change a different timezone (such as Europe/Bratislava), hit the OK button, confirm to “Keep Times”, then re-open the settings dialogue and change back to Europe/Berlin, for it to work.

Nicht Hardlink, sondern…?

TANSTA “softlink”. ITYM: symlink(7)

Actually, there’s “link” (also “hardlink”) and “symbolic link” (short “symlink”). (Oh, and reparse points, but let’s not get there, lest we mention *.lnk files…)

Inspired by a posting on the klibc mailing list.

SSD

Following the Wiki I put “discard” entries into my fstab(5) for swap (but not / as it’s suggested to use fstrim instead, and I had noatime for /boot and relatime for / already) and changed the scheduler. What wasn’t written there was to set vm.swappiness=0 in sysctl.d/local.conf *shrug* but it helps.

What they also didn’t mention:

mount -t tmpfs swap /var/cache/apt/archives

And in sid, which my dayjob-laptop is running, APT _finally_ creates the missing “partial/” subdirectory itself. Thanks!

I had the filesystems already created, so I changed the ext options with tune2fs:

tune2fs -E stride=1024,stripe_width=1024 /dev/sda2 # 1 KiB blocks: /boot
tune2fs -E stride=256,stripe_width=256 /dev/sda4 # 4 KiB blocks: /

I wonder how well that works. I also did _not_ manage to find out my device’s flash block size (search engine fodder: erase block size), so I assumed 1 MiB (also used for partition alignment already) as worst-case scenario. Input welcome on how to find *that* out.

Send Alt-SysRq-* to virt-manager guest using virsh

virsh send-key guestname KEY_LEFTALT KEY_SYSRQ KEY_H

This doesn’t work in virt-manager, but the virsh CLI tool is just fine.

PS: zerofree rocks! And can be installed in Grml 2011.05 just finely.

Fun with ssh pubkey auth

Okay, so imagine this: you just generated an SSH RSA key and threw its public part on system B into ~foo/.ssh/authorized_keys and its private part on system A into ~bar/.ssh/id_rsa but can’t login. Why?

Automated processes (Jenkins *cough*) often need you to ssh(1) manually once, to accept the remote host’s server key. Do that.

The id_rsa file on system A must be owned by the user bar and chmod 0600 or 0400 (similarily, the .ssh directory has strict permission checks, and everything in the path until there). Check those.

And, the most surprising one of the day: if there’s an id_rsa.pub it will be used for offering a key to the remote host (B) even if it does not match the secret key. Deleting A:~bar/.ssh/id_rsa.pub apparently makes OpenSSH generate the public part from the secret key each time (or just put the correct pubkey there), but if one’s there, it seems to like to use them. (That was the only part of this post that was news to even me, of course ☺)

And, as bottom line: hello to Planet Debian from “mirabilos at work”, too. I’ll occasionally tag posts so they show up here, if I think they’re of interest, since I’m doing Debian work at the dayjob, too.

How to find out when to a git repository was last committed?

git log -n 1 --all --full-history --pretty=format:'%cD'

This should™ scan all branches, take the chronologically last commit and output its committer date. Still doesn’t take into account git-receive-pack times, but we can just look at the mtime of the projectname-commits@lists.forgename mailing list for that.

PostgreSQL #FAIL – Handarbeit nötig!

PostgreSQL hatte vor kurzem ein Problem, und zwar in der Version 9.1.5, welches zu Datenkorruption führen kann. Ist in der Version 9.1.6 (und 9.2.1) gefixt. Dummerweise muß aber jede Datenbank, die auch nur einmal mit 9.1.5 gestartet wurde, gefixt werden, weil es sonst zu Datenkorruption kommen kann.

Schlimmer: die kaputte Version 9.1.5 wird aktuell mit precise-security in Ubuntu ausgeliefert und war für ca. ein Dutzend Tage in wheezy!

Nach dem Upgrade auf 9.1.6 gestaltet sich das Fixen wie folgt, als Superuser:

  • Die /etc/postgresql/9.1/main/postgresql.conf editieren: die Konfigurationseinstellungen (ggfs. erst hinzufügen) vacuum_freeze_table_age = 0 und vacuum_cost_delay = 50 setzen
  • Die Datenbank stoppen: /etc/init.d/postgresql stop
  • Prüfen, ob ps ax | fgrep postgres wirklich nix mehr zurückliefert
  • Die Datenbank starten: cleanenv - /etc/init.d/postgresql start
  • Ggfs. alle Anwendungen, die PostgreSQL (dauerhaft) benutzen, wie apache2 (Evolvis) und tomcat6 (Domisol) neu starten
  • Zum Systemuser wechseln – su - postgres – und vernünftige Sprache auswählen: Debian export LC_ALL=C.UTF-8 Ubuntu export LC_ALL=C
  • Alle Indicēs regenerieren: reindexdb -a
  • Staubsaugen: vacuumdb -F -z -a (optional noch mit -v zum mehr (zu viel) sehen)
  • Den PostgreSQL-User wieder verlassen: exit
  • Die beiden Konfigurationsänderungen von oben wieder rückgängig machen
  • Falls gewünscht, die Änderungen aktivieren: cleanenv - /etc/init.d/postgresql reload

Ich hab’ das mal für alle EvolvisForge- und tarent-activity-Maschinen gemacht, aber eure Desktops und so aktualisiert ihr bitte selber, wenn auch nur die Chance besteht, daß mal ein 9.1.5 oder 9.2.0 installiert war!

Jenkins und die APT-Repositories Ⅱ

As reported earlier we’ve got some kind of Jenkins/APT integration, with automatically generating as many repositories as a job desires.

News are that the builds host has moved, so the URIs to the repositories have changed. The new syntax is https://ci-something.lan.tarent.de/ for the Jenkins ⇒ “deb https://ci-something-debs.lan.tarent.de/jobname/ distribution suite …” and currently only usable in the company-internal network.

We’ve also got some more magic mksh code to automate the entire process – check the code out from SCM (required, as Jenkins’ svn checkouts are broken), build a Debian source package, NEW! ask cowbuilder to compile it in a clean chroot environment, and call mvndput.sh for APT repository publication. Sample projects are ci-evolvis/virtualscreen (git) and ci-dev/portal-setup (svn). Talk to me if you have any questions.

This allows for a one-line “run a shell command” build step!

Everybody else is, of course, invited to take and re-use our code, and maybe even improve upon it and submit that back. It’s all Open Source, after all.


tl;dr Jenkins Jobs now have integration with cowbuilder. There’s a new script to automate the whole build pipeline. The APT repositories have moved with the recent move.

Evolvis-Wikis und die Suchmaschine

(Dieses Posting wurde ursprünglich im internen Blog veröffentlicht, ist jetzt jedoch hierhin umgezogen. Firmeninterne Information wurde gekürzt, ist aber für Mitarbeiter im Mailinglistenarchiv ersichtlich.)

Neues aus der Adminstube (und vom Evolvis-Team) für unsere Projektmanager:

Im Rahmen der tarent-Suche werden die Wikis indiziert; dies ist natürlich nicht immer gewünscht, auch wenn die Suche nur Mitarbeitern zugänglich ist. Darum gibt es jetzt eine Möglichkeit, pro Projekt das Wiki öffentlich oder privat zu setzen. Im Moment werden nur die Wikis auf evolvis.org und dev.tarent.de indiziert, ab dem 20.06.2011 aber auch auf den Kundenevolvinēs – daher stellt eure Wikis bitte ein!

Wir werden jedes Wochenende den Suchindex leeren und neu aufbauen, das heißt, zukünftige Änderungen von öffentlich auf privat werden erst in der Folgewoche aktiv!

Die Einstellung betrifft den XML-Export, die tarent-Suche und die Sichtbarkeit für nicht eingeloggte Besucher. Wenn ihr die Einsicht eines Wiki vor Mitarbeitern, die keine Projektmitglieder sind, verstecken wollt, müssen wir weiterhin die Rechtefreigaben von Hand anpassen.

Die aktuelle Konfiguration ist wie folgt: [… gekürzt …]