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 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 for free under GPL.

MySQL Query-Cache Hints

Vor einigen Jahren (ja das stimmt wirklich) habe ich mal einen kurzen Blog-Post zum Thema MySQL Query-Cache geschrieben. Leider ist die Verwendung des Query-Cache nicht wirklich unumstritten und auch nicht in jeder Umgebung ein problemlösendes Mittel. Neben Fragmentierung des Caches und einigen Limitierungen bezüglich gecachter Operationen kann gerade die interne Pflege des Caches ein Problem sein. Ursache hierfür ist das bei Aktualisierung der Basistabellen auch alle sich darauf beziehenden Cache-Einträge gelöscht werden. Dies ist Aufwändig und führt in Umgebungen mit hoher Transaktionsdichte oft dazu, dass nahezu nie ein Ergebnis aus dem Cache kommt aber trotzdem alle Ergebnisse einer Select-Abfrage in den Cache gelegt und dort verwaltet werden.
Die spannenden Hints dafür sind SQL_CACHE und SQL_NO_CACHE mit denen sich das Verhalten des Query-Caches auf Basis von Einzelstatements steuern lässt.
Ein Beispiel:

SELECT /*! SQL_NO_CACHE */ product_id, product_name, product_price from products;

Mit diesem Hint kann man die Ablage des Ergebnisses im Cache verhindern und ggf. wirkungslose Caching-Last vom System nehmen. In die andere Richtung funktioniert das natürlich auch 🙂

Bernd Erk
Bernd Erk

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.