Drupal and Configuration Mgmt, we're getting there ...

Kris Buytaert — Sun, 17 Jul 2011 20:39:27 +0000

For those who haven't noticed yet .. I`m into devops .. I`m also a little bit into Drupal, (blame my last name..) , so one of the frustrations I've been having with Drupal (an much other software) is the automation of deployment and upgrades of Drupal sites ...

So for the past couple of days I've been trying to catch up to the ongoing discussion regarding the results of the configuration mgmt sprint , I've been looking at it mainly from a systems point of view , being with the use of Puppet/ Chef or similar tools in mind .. I know I`m late to the discussion but hey , some people take holidays in this season :) So below you can read a bunch of my comments ... and thoughts on the topic ..

First of all , to me JSON looks like a valid option.
Initially there was the plan to wrap the JSON in a PHP header for "security" reasons, but that seems to be gone even while nobody mentioned the problems that would have been caused for external configuration management tools.
When thinking about external tools that should be capable of mangling the file plenty of them support JSON but won't be able to recognize a JSON file with a weird header ( thinking e.g about Augeas (augeas.net) , I`m not talking about IDE's , GUI's etc here, I`m talking about system level tools and libraries that are designed to mangle standard files. For Augeas we could create a separate lens to manage these files , but other tools might have bigger problems with the concept.

As catch suggest a clean .htaccess should be capable of preventing people to access the .json files There's other methods to figure out if files have been tampered with , not sure if this even fits within Drupal (I`m thinking about reusing existing CA setups rather than having yet another security setup to manage) ,

In general to me tools such as puppet should be capable of modifying config files , and then activating that config with no human interaction required , obviously drush is a good candidate here to trigger the system after the config files have been change, but unlike some people think having to browse to a web page to confirm the changes is not an acceptable solution. Just think about having to do this on multiple environments ... manual actions are error prone..

Apart from that I also think the storing of the certificates should not be part of the file. What about a meta file with the appropriate checksums ? (Also if I`m using Puppet or any other tool to manage my config files then the security , preventing to tamper these files, is already covered by the configuration management tools, I do understand that people want to build Drupal in the most secure way possible, but I don't think this belongs in any web application.

When I look at other similar discussions that wanted to provide a similar secure setup they ran into a lot of end user problems with these kind of setups, an alternative approach is to make this configurable and or plugable. The default approach should be to have it enable, but the more experienced users should have the opportunity to disable this, or replace it with another framework. Making it plugable upfront solves a lot of hassle later.

Someone in the discussion noted :
"One simple suggestion for enhancing security might be to make it possible to omit the secret key file and require the user to enter the key into the UI or drush in order to load configuration from disk."

Requiring the user to enter a key in the UI or drush would be counterproductive in the goal one wants to achieve, the last thing you want as a requirement is manual/human interaction when automating setups. therefore a feature like this should never be implemented

Luckily there seems to be new idea around that doesn't plan on using a raped json file
instead of storing the config files in a standard place, we store them in a directory that is named using a hash of your site's private key, like sites/default/config_723fd490de3fb7203c3a408abee8c0bf3c2d302392. The files in this directory would still be protected via .htaccess/web.config, but if that protection failed then the files would still be essentially impossible to find. This means we could store pure, native .json files everywhere instead, to still bring the benefits of JSON (human editable, syntax checkable, interoperability with external configuration management tools, native + speedy encoding/decoding functions), without the confusing and controversial PHP wrapper.

Figuring out the directory name for the configs from a configuration mgmt tool then could be done by something similar to

cd sites/default/conf/$(ls sites/default/conf|head -1)

In general I think the proposed setup looks acceptable , it definitely goes in the right direction of providing systems people with a way to automate the deployment of Drupal sites and applications at scale.

I`ll be keeping a eye on both the direction they are heading into and the evolution of the code !

Juliux End of Life Announcement

Kris Buytaert — Sun, 02 Sep 2007 17:11:24 +0000

Raf posted the Juliux End Of Life announcement a couple of days ago, http://www.x-tend.be/pipermail/juliux-dev/2007-August.txt
We started Juliux about 2 years ago with as idea to create an open source alternative for the back then proprietary RedHat Satelite and the back then totally broken ZLM from Novell. We set out to build a webbased platform from where you could do package management for a hybrid set of servers, with as a second version target to also integrate some form of configuration management. We even presented our proof of Concept at the 2006 UKUUG Lisa Conference

RedHat in the meanwhile announced open sourceing Satellite, but more importantly Puppet became more popular and more feature rich.
One of the features that came in puppet that made me rethink Juliux was the fact that you could do package management including installation etc within Juliux, so I started thinking about making Juliux a webfrontend that used Puppet as a back end.

The ideas were good, but we really didn't have time to focus on developing the things we wanted to write. So when I ran into PuppetShow the time was right to refocus the little efforts we were spending and as Raf announced he now will be working on PuppetShow when he has time.

Funny . there was a time when I was thinking about rebranding Julux to PuppetMaster, or Master of Puppets, but I actually like PuppetShow better .. So we had similar ideas , only Luke had more time to implement his ideas .

Time often is an issue in opensource development. There's lots of stuff that I have in my head that could easily be written .. but I don't always have time to do it myselve or other people available that can write it for me .. :( Well.. maybe one day :)

Everything is a Freaking DNS problem - configuration management

Drupal and Configuration Mgmt, we're getting there ...

Juliux End of Life Announcement