NAT in IPv6 & Debian Backports, New Feature in iSMS & MySQL Query Cache, plus Application Developer Apprenticeship

4 – 8 July considered NAT in IPv6, demonstrated Debian backporting, shared a MySQL tip and announced a new feature in iSMS alongside an applications developer apprenticeship.
Starting the week, Thomas despaired at the continued use of NAT in IPv6. In light of the experimental RFC 6296 “IPv6-to-IPv6 Network Prefix Translation” he considered the reasons behind retaining NAT despite the abundance of addresses as we depart from IPv4: Simpler roaming, or fear of the side effects of renumbering, alongside the desire for dynamic and changing official IPs. He noted that NPTv6 is more like 1:1-NAT than the classic NAT from the xDSL line in IPv4. An internal address has its equivalent external address and passes all ports 1:1. A subnet’s complete prefix (/48, /68 etc.) is replaced with the last part remaining the same. Thomas feared that providers would find false comfort in NPTv6 and use it too broadly.
Marcus then showed how to backport packages from Debian. He began with a debootstrap to create a chroot to work in. With chroot chroot_squeeze/ /bin/bash should anything go wrong, the chroot file can be deleted and recreated. He then modified the /etc/apt/sources.list, recommending the use of the entire stable Debian branch to install build dependencies from the stable packages. Finally, the source entry in the /etc/apt/sources.list can is changed to testing, unstable or experimental depending on which source was required for the package. He carried out last run of the apt-get build-dep to ensure no errors in dependencies exist. Using Icinga as his example, Marcus then continued to retrieve icinga via apt-get, modifying the version with dch –v. Upon changing the name and email address, as well as the distribution in the changelog file, he then built the package with dpkg-buildpackage.
From the development team, Marius posted an opening for an applications developer apprenticeship. As of 1 September, NETWAYShopes to take in an IT student wishing to learn more about Linux, languages such as PHP, Python, Perl and C, modern technologies in web and systems development all in the open source spirit. Enthusiastic applicants with basic knowledge of Linux and programming are welcome to apply to jobs@netways.de. More information can be found on the jobs area of our website.
Building on a post he wrote a few years ago, Bernd shared his new tip for MySQL query cache. Alongside cache fragmentation and limitations in cached operations, internal cache maintenance can present problems. He saw the cause to be the deletion of all corresponding cache entries when the base tables are updated. In environments with frequent transactions, results can almost never be retrieved from the cache even though all results of a select query are in saved in the cache and managed there. To resolve this, Bernd recommended SQL_ CACHE and SQL_NO_CACHE. With these two, the query cache can be limited to individual statements and the storage of unnecessary results on the cache can be avoided.
Last but not least, Lennart noted a new smsfinder feature in iSMS. In the past, responding to an SMS required the same content to be used with a ACK or OK at the front. Now it is possible to send an SMS via –use-db, which automatically sends an id tag along with the status text. By simply sending the 4 digit id in a return message, an issue regarding a certain host or service can be acknowledged. This however only works with acknowledgements, and cannot as yet, set a service or host to OK. Download the addon at www.netways.org for free under GPL.

Backporting – Quick and a bit dirty

Oftmals steht man vor der Problematik, dass man auf seinem Produktivsystem eine aktuellere Version von einem Programm benötigt als sie bereits im Repository der stabilen Ausgabe von Debian vorhanden ist. Für solche Problemfälle gibt es das Backports-Projekt, indem aber natürlich auch nicht alle Pakete enthalten sind, da nur selektiv einzelne Pakete aus dem neuen “testing”-Zweig von Debian gegen ein Stable-Environment gebaut werden.
Häufig werden dann die benötigten Programme in aktueller Version selbst übersetzt und somit aus der Paketverwaltung ausgekoppelt, was das Einspielen von Updates erschwert.
Der direktere Weg ist selbst sich Pakete zu backporten. Dies hat folgende Vorteile:

  • Integration in die Paketverwaltung (Vereinfachung beim Einspielen von Updates oder einem Upgrade)
  • durch die Maintainer an das Debian-System angepasst
  • einfache Weitergabe und Verteilung auf mehreren Systemen

Grundlage bietet zunächst eine chroot-Umgebung, damit das System, auf dem Gearbeitet wird nicht “zugemüllt” wird durch diverse dev-Pakete. Das Anlegen eines chroots ist recht einfach und geschieht mit debootstrap (muss als root ausgeführt werden)

root@localhost:~# mkdir chroot_squeeze
root@localhost:~# debootstrap squeeze chroot_squeeze/ http://ftp.de.debian.org/debian
I: Retrieving Release
I: Retrieving Packages
....

Wenn debootstrap die Umgebung gebaut hat, kann mit chroot chroot_squeeze/ /bin/bash in das chroot gewechselt und ohne Gefahr gearbeitet werden. Weiterer großer Vorteil ist, dass wenn was schief geht und das System “zerschossen” wird, man den chroot-Ordner einfach löscht und neu anlegt.
In der chroot-Umgebung sollten zunächst die /etc/apt/sources.list angepasst und um die Source-Quellen erweitert werden. Empfehlenswert ist es zunächst ersteinmal komplett den stable-Zweig von Debian zu verwenden, um die Build-Dependencies von den Stable-Paketen zu installieren. Hintergrund ist, dass so schon einmal der Großteil der benötigten Pakete installiert wird und später schneller und gezielter die fehlenden Abhängigkeiten aufgelöst werden können.

root@localhost:~# chroot chroot_squeeze/ /bin/bash
root@localhost:/# cd ~
root@localhost:~# mkdir icinga ; cd icinga
root@localhost:~/icinga# apt-get build-dep icinga
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
....

Bei diesem Durchlauf sollten keine Fehler bzgl. Abhängigkeiten auftreten. Anschließend kann der Source-Eintrag in der /etc/apt/sources.list auf testing, unstable oder experimental geändert werden, je nachdem aus welcher Quelle man ein Paket benötigt. Anschließend erneut apt-get build-dep ausführen. Wenn hier Abhängigkeitsprobleme auftreten muss versucht werden diese Aufzulösen. In einigen Fällen kann es bedeuten, dass man zunächst andere Pakete backporten muss, damit die Abhängigkeiten der neuen Version stimmen. In unserem Beispiel von Icinga ist das jedoch nicht der Fall.
Es werden nun die Quellen mittels apt-get source icinga geholt und im Anschluss die Version mittels dch -v angepasst. Hierbei sollte man die Versionierung nehmen, wie sie auch beim Backports.org Projekt genutzt wird (paketname-1.0.2-2~xyz60+1 – genaueres ist aus backports.org zu entnehmen).

root@localhost:~/icinga# vi /etc/apt/sources.list
root@localhost:~/icinga# apt-get update
root@localhost:~/icinga# apt-get build-dep icinga
...
root@localhost:~/icinga# apt-get install devscripts #hier ist dch enthalten
root@localhost:~/icinga# cd icinga-1.4.1
root@localhost:~/icinga/icinga-1.4.1# dch --bpo

Nun öffnet sich ein Editor, der einem gleich die changelog Datei anbietet. Hier sollten noch Name und Email-Adresse angepasst werden und ggf. noch die Distribution (squeeze-backports, squeeze-backports-netways ..)
Nach dem Speichern kann das Paket mittels dpkg-buildpackage gebaut werden. Es kann sein, dass hier ebenfalls noch einmal Abhängigkeiten bemängelt werden, die man anschließend versuchen müsste aufzulösen, was jedoch aktuell und in unserem Beispiel nicht der Fall sein sollte.

root@localhost:~/icinga/icinga-1.4.1# dpkg-buildpackage
dpkg-buildpackage: setze CFLAGS auf Standardwert: -g -O2
dpkg-buildpackage: setze CPPFLAGS auf Standardwert:
dpkg-buildpackage: setze LDFLAGS auf Standardwert:
...

Ist der Build-Prozess erfolgreich durchgelaufen, liegen im übergeordneten Ordner die fertigen Debian-Pakete inklusive Quellpakete, welche dann in ein eigenes Repository hochgeladen werden können (bspw reprepro).
Ich möchte noch einmal darauf hinweisen, dass es unter unglücklichen Umständen (sehr große Versionssprünge und Abhängigkeitsprobleme) eine etwas umfangreicheres Unterfangen sein kann, ein Paket zurückzuportieren. Jedoch erntet man dafür die Vorteile und kann seine Ergebnisse mit anderen teilen.