Seite wählen

NETWAYS Blog

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.

Oops!… They did it again: IPv6 kann jetzt NAT

Während viele „Experten“ NAT noch immer als Sicherheitsfeature preisen, ist es für andere schlicht das Schlimmste, was dem Netz je passiert ist. Ich persönlich gehöre definitiv zu letzteren. Dank NAT und fehlender Netzwerktransparenz gibt es in vielen Firewalls viel größere „Löcher“, als eigentlich nötig wäre. Interne IPs auf IP-Ebene zu verstecken, während sie auf Anwendungsebene wieder sichtbar werden (Header in Mails, SIP – und vielen mehr) ist heutzutage ja meist auch eher witzlos. Der einzig wirkliche Grund für NAT war und ist die Adressknappheit bei IPv4 – und die wollten wir mit IPv6 ja hinter uns lassen. Warum also noch NAT?
Es scheint wohl Gründe dafür zu geben. Jedenfalls war es letzte Woche dann soweit: das experimentelle RFC 6296 „IPv6-to-IPv6 Network Prefix Translation“ wurde veröffentlicht. Was vorher unter dem verpönten Namen NAT66 lief nennt sich jetzt also NPTv6, ist noch kein „Internet Standard“ – aber wohl schon auf dem besten Weg dorthin. Das lange aufrecht erhaltene Credo „Mit IPv6 wird es kein NAT mehr geben“ wurde damit hinfällig. Vermeiden ließ sich eine solche Entwicklung leider ohnehin nicht, und es ist sicher besser wenn offizielle Standards Einzug halten, bevor der Wildwuchs im freien Markt allzu sehr ausartet.
Warum aber will man bei so vielen verfügbaren Adressen denn eigentlich noch ein NAT haben? Der Wunsch nach einfacherem Roaming könnte z.B. ein Grund sein. Oder schlicht die Angst vor Seiteneffekten beim Renumbering, also der Neuvergabe von Adressen für ein ganzes Netzwerk. Dies kombiniert mit dem Wunsch nach dynamischen und täglich wechselnden offiziellen IPs auch bei IPv6 führte nebst anderen Gründen so zum durchaus verständlichem Ruf nach NAT für IPv6.
NPTv6 ist nicht unbedingt mit dem klassischen NAT wie wir es von unserer xDSL-Leitung in der IPv4-Welt kennen vergleichbar. Es ähnelt eher dem 1:1-NAT (one-to-one), bei dem eine interne Adresse exakt einer externen entspricht, und sämtliche Ports 1:1 durchgereicht werden. SOHO-Router verwenden hierfür in der IPv4-Welt auch Ausdrücke wie „Exposed Host“ oder „DMZ-Host“. NPTv6 arbeitet ähnlich, allerdings nur auf Präfix-Ebene. Sprich: der komplette Präfix eines Subnetzes (/48, /64…) wird ersetzt – der Teil dahinter bleibt bestehen. Auch dynamische Port-Mappings sind glücklicherweise nicht vorgesehen.
Hier versucht die IETF, einen bei IPv4 gemachten Fehler nicht erneut zu begehen. Damals implementierte jeder NAT nach eigenem Gutdünken. Die IETF untersuchte später die am Markt verfügbaren Lösungen, um wenigstens zu dokumentieren, welche Spielarten von NAT denn im Umlauf seien. Mit IPv6 sollen wichtige Features wie „hairpinning“ kein Zufall mehr, sondern werden zwingend vorgeschrieben sein.
Nichtsdestotrotz bleibt ein schaler Beigeschmack: die Hemmschwelle, NAT auch in der IPv6-Welt einzusetzen wurde mit RFC 6296 erheblich heruntergesetzt. Und wir riskieren, dass Provider aus falsch verstandener Bequemlichkeit NPTv6 auf breiter Ebene einsetzen werden. Dabei wäre das Renumbering auch eines ganzen Netzwerks an sich nichts Böses. Und es hat einen entscheidenden Vorteil: Applikationen sind transparenten Adresswechseln nicht mehr blind ausgeliefert.

Thomas Gelf
Thomas Gelf
Principal Consultant

Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.

OSDC-Ticker: News in Apache 2.4 und IPv6

Auch wenn die Version in den gestrigen Vorträgen eine wichtige Rolle spielte, unterscheidete sich der Inhalt doch deutlich.

Rainer Jung berichtete in einem sehr interessantem Vortrag über die Neuerungen in der kommenden Apache Version 2.4. Dabei wurde auch ausführlich auf die seit Apache 2.0 verwendeten MPMs detailliert eingegangen. Hier sind ergänzend zu vielen erfolgten Codebereinigungen die größte Neuerung zu finden. Der neue „event“ MPM verspricht deutliche Performancesteigerungen gegenüber seiner Vorgänger. Ebenso halten neue Webtechnologien wie Websockets über kurz oder lang Einzug in den Code. Wir freuen uns mit Rainer Jung, ein Contributer des Apache Teams auf der Konferenz zu haben und über den tollen Vortrag.

Mit dem Vortrag „Einführung in IPv6“ brachte uns Jens Link die Vorzüge des aktuellen Internet Protokolls näher. Dabei ging er im Überflug auf sämtliche Grundlagen und neue Technologien im Vergleich zu IPv4 ein und teilte seine Praxiserfahrung über mögliche Probleme bei der Umstellung. Tenor seines Vortrages ist: IPv4 Adressen sind nur noch begrenzt verfügbar und jeder der mit Netzadministration beschäftigt ist, sollte sich lieber zeitig in ruhe mit der Thematik beschäftigen um gerüstet in die „neue Welt“ zu migrieren.
Bernd Erk
Bernd Erk
CEO

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 startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er 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 seinen beiden Söhnen und seiner Tochter.

Weekly Snap: From Open Rhein Ruhr to Web Monday with IPMI plugin and Ethernetbox in between

weekly snapNov 2-6 hopped from one event to another, leaving the OSMC for the Open Rhein Ruhr and Web Monday.
Christian F tipped off Bernd’s appearance in Bottrop at the Open Rhein Ruhr trade fair where he made a speech on current open source data centre solutions on Sunday. To follow, Julian will hop off to the Nuremberg Web Monday tonight, to push the bounds of the net with a casual bunch of web enthusiasts.
Behind events came hardware, with Christian’s introduction of the new IPMI plugin we developed in partnership with Thomas Krenn. The Nagios / Icinga plugin retrieves all IPMI sensor checks such as fan speeds, temperature, voltages, power supply status, etc. and is available under GPLv3 to download from Thomas Krenn.
Hardware man Martin added his monitoring tip, with a transducer device from MessPC known as the Ethernetbox 2. By transmitting SNMP data over the network to a Nagios or Icinga monitoring system via 0-10V connector cable or 4…20Ma adapter cable, a range of environment sensors can be integrated by this one box.
From the hosting and managed services side, Bernd L gave us an early reminder to switch to IPv6, counting down the 2 year end to IPv4 address availability. For the migration, he recommended a functioning monitoring system to avoid false reports of unreachable components, and testing to ensure all applications are IPv6 ready.
Finally, Bernd E shared his Open Rhein Ruhr experience with a quick peek into Charly Kuehnast’s presentation on spam filters of large calibre and his own presentation on current solutions for open source data centers. From DRBD and Xen to Puppet, Kontrollbase and MySQL Proxy, Bernd’s open source tool mosaic can be downloaded off our blog already.

IPv6 – die Zeit nutzen solange wir sie noch haben


Zwar ist schon seit Jahren bekannt, dass die IPv4-Addressen irgendwann zu neige gehen und die verbleibende Zeit wird immer kürzer, aber passiert ist eigentlich noch nicht viel. Schätzungen, wie der Counter dieser Counter gehen davon aus, dass die IPv4 Adressen noch etwa 2 Jahre ausreichen werden,  also eigentlich kein Grund zur Hektik werden sich viele denken. Allerdings sollte man so langsam doch in die Gänge kommen, da die Migration auf IPv6, bzw. die Einführung von IPv6 neben IPv4 nicht nach einigen Tagen durchgeführt ist.
Zwingende Vorraussetzung für die Einführung von IPv6 ist ein funktionierendes Monitoring, da nur so Falschmeldungen über nicht erreichbare Komponenten vermieden werden können. Auch sollte man sich von der gängigen Praxis abwenden nur eine IP pro Host zu prüfen. Mit IPv6 sind genügend Addressen verfügbar, so dass eine extra Addresse für das Monitoring und jede Applikation gewählt werden sollte. So lassen sich Applikationen bei Bedarf auch einfacher umziehen, da die IP-Addresse einfach mitgenommen werden kann, Abhängigkeiten zum DNS und dessen Aktualisierungsgeschwindigkeit entfallen somit größtenteils.
Vor einer anstehenden Migration sollte natürlich auch noch geprüft werden, ob alle eingesetzten Applikationen schon IPv6-Ready sind, hier bietet Deepspace6.net eine relativ umfangreiche Liste getesteter Software. Als vermutlich größte Fallstricke ist der fehlende IPv6-Support im Portmapper zu nennen, der für NFS-Exports benötigt wird und bei den meisten Linux-Distributionen Standard ist. Hier kann jedoch evtl. auf den RPCBind umgestellt werden wenn die Distribution entsprechende Pakete anbietet.
Einer Einführung von IPv6 steht daher nicht viel im Wege, so dass die noch verbleibende Zeit genutzt werden sollte um in Ruhe Erfahrungen im Umgang mit dem neuen Protokoll zu sammeln. Denn wie wir alle wissen ist nichts schlimmer als das Arbeiten unter Zeitdruck.