We have been working on porting openATTIC to Ubuntu 16.04 LTS "Xenial Xerus" for
quite some time now, and we wanted to give you a quick update on the current
status as of openATTIC version 2.0.16.

It turns out that Xenial provides a number of challenges and differences that we
needed to take into account, for example a new version of Django and the Django
REST framework, as well as some additional underlying changes.

Making all the required changes in a backwards-compatible manner and testing
them is quite time-intensive.

In a nutshell, we're not quite there yet, but we're making progress.

Some of these issues can be worked around, but the overall "out of the box
experience" still needs to be further improved.

Following our mantra "release early, release often", we have published a release four weeks after the release of 2.0.15. One of the highlights in this version is the migration support for openATTIC instances still running on Django 1.6!

Moreover, the openATTIC REST API does now report all installed packages as well as the currently installed openATTIC version. Most other changes are bug fixes and improvements of openATTIC. We have also continued working on supporting Ubuntu 16.04 LTS "Xenial Xerus".

You may have seen today's announcement,
that the openATTIC development team has joined SUSE, and
with this SUSE has taken over the corporate sponsor role from openATTIC's parent
company, it-novum.

I'd like to share my view about what this means for openATTIC and the community
and ecosystem around the project.

First off, the license of the software or openness of the development process
won't change. Quite the contrary: SUSE is fully committed to keeping openATTIC
licensed under the GPL and growing the community around the project.

You will still be able to freely use it without arbitrary restrictions for your
Ceph and "traditional" storage management needs.

One key part of implementing Ceph management capabilities within openATTIC
revolves around the possibilities to install, deploy and manage Ceph cluster
nodes in an automatic fashion. This requires remote node management
capabilities, that openATTIC currently does not provide out of the box. For
"traditional" storage configurations, openATTIC needs to be installed on any
storage node that is managed, but you can use a single web interface for
managing all of the node's storage resources.

Naturally, installing openATTIC on all nodes belonging to a Ceph cluster is
not feasible.

As you're probably aware, we're putting a lot of effort into improving the Ceph
management and monitoring capabilities of openATTIC in collaboration with SUSE.

One of the challenges here is that Ceph is a distributed system, usually running
on a number of independent nodes/hosts. This can be somewhat of a challenge for
a developer who just wants to "talk" to a Ceph cluster without actually having
to fully set up and manage it.

Of course, you could be using tools like SUSE's Salt-based DeepSea project or ceph-ansible, which automate the deployment and
configuration of an entire Ceph cluster to a high degree. But that still
requires setting up multiple (virtual) machines, which could be a daunting or at
least resource-intensive task for a developer.

While we do have a number of internal Ceph clusters in our data center that we
can use for testing and development purposes, sometimes it's sufficient to have
something that behaves like a Ceph cluster from an API perspective, but must not
necessarily perform like a full-blown distributed system (and can be set up
locally).

Fortunately, Docker comes to the rescue here - the
nice folks at Ceph kindly provide a special Docker image labeled ceph/demo, which can be described as a "Ceph
cluster in a box".

If you ever plan to setup a clustered samba fileserver within a windows active directory infastructure you'll need the following things.

The problem in a clustered samba environment is, that the clients always wants to connect their network share with the same hostname/machine account.

It would be possible to just use the cluster ip instead of a new machine account, but then your users/clients will always get that popup within their office programs, that this isn't a trusted location.

To get rid of that annoying problem you have to create a new machine account and merge that keytab into your existing one on your samba servers.