General support for:

• Monitors
• OSDs
• MDSs
• RGW

More details:

• Authentication (cephx), this can be disabled.
• Supports cluster public and private network.
• Monitors deployment. You can easily start with one monitor and then progressively add new nodes.
  So can deploy one monitor for testing purpose. For production, I recommend to always use an odd
  number of monitors, 3 tends to be the standard.
• Object Storage Daemons. Like the monitors you can start with a certain amount of nodes and then
  grow this number. The playbook either supports a dedicated device for storing the journal or both
  journal and OSD data on the same device (using a tiny partition at the beginning of the device).
• Metadata daemons.
• Collocation. The playbook supports collocating Monitors, OSDs and MDSs on the same machine.
• The playbook was validated on Debian Wheezy, Ubuntu 12.04 LTS and CentOS 6.4.
• Tested on Ceph Dumpling and Emperor.
• A rolling upgrade playbook was written, an upgrade from Dumpling to Emperor was performed and worked.

One of our customers had a question related to the right value of Galera Cache size (gcache.size) in Galera Cluster for MySQL which I would like to share with you.

The question was: My maintenance window takes 4 hours for my 5TB DB. How can I avoid an SST ?!

Basically, having too small GCache size will lead to SST (Snapshot State Transfer) instead of IST (Incremental State Transfer), thus we can avoid the SST by setting the GCache to the appropriate value.

State Snapshot Transfer (SST) is a way for Galera to transfer a full data copy from an existing node (donor) to a new node (joiner). If you come from a MySQL replication background, it is similar to taking a backup of a master and restoring on a slave. In Galera Cluster, the process is automated and is triggered depending on the joiner state.

SST can be painful in some occasions, as it can block the donor node (with SST methods like mysqldump or rsync) and burden it when backing up the data and feeding it to the joiner. For a dataset of a few hundred gigabytes or more, the syncing process can take hours to complete - even if you have a fast network. It might be advisable to avoid e.g. when running in WAN environments with slower connects and limited bandwidth, or if you just want a very fast way of introducing a new node in your cluster.

s I plan to move from a proprietary calendaring to a more „ressource-aware” open source solution, I decided to give Radicale a try. It is open source, appears to be rather pragmatic in its approach to „standards” and has a small footprint in regards to system requirements.

With me running Debian 8 on my server, I decided to stick with the available package and not install „from source”. So a quick „apt-get install radicale” took care of installing the necessary software (do not forget to enable the Radicale daemon in /etc/default/radicale).

The configuration of Radicale is rather straightforward and simple. In regards to transport security, You can reuse an existing TLS certificate (or get a new one from Let’s encrypt). For authentication, you can choose between several options. As I don’t have an LDAP server (yet) and I didn’t want to create a .httpasswd entry for each user, I chose „IMAP”. So Radicale will validate all credentials against the local IMAP server (Dovecot in my case).

VXLAN is an overlay network to encapsulate Ethernet traffic over an existing (highly available and scalable, possibly the Internet) IP network while accomodating a very large number of tenants. It is defined in RFC 7348. For an uncut introduction on its use with Linux, have a look at my “VXLAN & Linux” post.

VXLAN is an overlay network to carry Ethernet traffic over an existing (highly available and scalable) IP network while accommodating a very large number of tenants. It is defined in RFC 7348.

Starting from Linux 3.12, the VXLAN implementation is quite complete as both multicast and unicast are supported as well as IPv6 and IPv4. Let’s explore the various methods to configure it.

I've published a new HOWTO on my website:

Enrico already wrote about the Why (and the What, Who and When), so I'll just quote his conclusion and move on to the How.

I now have an XMPP setup which has all the features of the recent fancy chat systems, and on top of that it runs, client and server, on Free Software, which can be audited, it is federated and I can self-host my own server in my own VPS if I want to, with packages supported in Debian.

You may have heard that the NSA can decrypt SSH at least some of the time. If you have not, then read the latest batch of Snowden documents now. All of it. This post will still be here when you finish. My goal with this post here is to make NSA analysts sad.

TL;DR: Scan this post for fixed width fonts, these will be the config file snippets and commands you have to use.