I was setting up a new root-server machine and went for the Debian 7 minimal set-up. Thankfully the root-server provider I am using (hetzner) is connected with IPv4 and IPv6 natively. Awesome stuff!
If you’re using an IPv6 native set-up these days you STILL have to be cautious about possible side-effects with software having bugs and not knowing how to deal with these ginormous ip adresses.
So there’s a well known Jabber / XMPP server that I am using for some years now without any issues. I was even using it on native IPv6 connected machines earlier.
But with the fresh and clean set-up of Debian 7 and IPv6 by the hoster several problems started bubbling up.
1: the ‘there can only be one ipv*’ problem
Turns out that the debian team decided to set a system setting by default that lets IPv6 aware applications bind to IPv6 only. Good thing, you can disable it by adding this to your sysctl.conf:
2: the ‘who resolves first is right’ problem
When you get a IPv6 native machine it might have a resolv.conf consisting of IPv4 and IPv6 name servers. And don’t worry: Everything is going to be all-right as long as the software you’re planning to use is perfectly capably dealing with the answers of both types of servers. The IPv4 ones will default to the A records, the IPv6 ones to the AAAA record.
Now there’s OpenFire. A stable and easy to use XMPP / Jabber server implementation. It’s based upon Java and I am running it with Java 7 on my Debian machine.
Unfortunately in the current 3.9.1 version of OpenFire there’s a bug that leads to Server-to-Server XMPP connections not working when they resolv to IPv6. So for example your Google-Talk contacts won’t work at all.
The bug itself is rather stupid: Seems that OpenFire expects an IPv4 adress from the DNS lookup and crashes on an IPv6 adress.
The solution is as easy as the bug is stupid: Remove the IPv6 defaulting nameservers from your resolv.conf.
# nameserver config
“The Data Visualisation Catalogue is currently an on-going project developed by Severino Ribecca.
Originally, this project was a way for me to develop my own knowledge of data visualisation and create a reference tool for me to use in the future for my own work. However, I thought it would also be useful tool to not only other designers, but also anyone in a field that requires the use of data visualisation regularly (economists, scientists, statisticians etc).
Although there have been a few attempts in the past to catalogue some of the established data visualisation methods, there is no website that is really comprehensive, detailed or helps you decide the right method for your needs.
I will be adding in new visualisation methods, bit-by-bit, as I research each method to find the best way to explain how it works and what it is best suited for.”
Source 1: http://datavizcatalogue.com/