As Swisslinux.org member, I again had the opportunity to take part to the Rencontres Hivernales du Libre (roughly translated as ‘Winter Libre meetup'), up in the jura, in St-Cergue. This week-end-long meetup, organized for the second time this year, aims at gathering all libre-related actors. This article, originally written in french, tells you the story of what happened there, who attended and did what.

Les Rencontres Hivernales du Libre, deuxième édition

Dans le cadre de l'association Swisslinux.org dont je suis membre, j'ai à nouveau eu le plaisir de participer aux Rencontres Hivernales du Libre, du 8 au 10 janvier passés. Ces rencontres, organisées pour la deuxième fois en 2016, ont pour but de rassembler les acteurs romands du Libre, dans sa définition la plus large.

30 geeks à St-Cergue

Dès la première édition, l'idée a été de profiter d'une période et d'un cadre moins usuel, en allant chercher la neige là où elle est. Viser une expérience de “conférence” plus large; entre informatique et loisirs extérieurs. Lors de l'édition 2015, le beau temps avait permis à plusieurs participants de profiter de chacun de ces deux aspects, entre ski et surf.

Le lieu choisi cette année a de nouveau été le Centre du Vallon, à St-Cergue, pour son bon compromis entre proximité aux transports publics, enneigement et coûts.

Malheureusement, les conditions météorologiques de l'édition 2016 ont été moins profitables, avec un faible manteau neigeux, arrosé de pluie durant tout le week-end. Bonne surprise cependant, avec l'incinération des sapins de Noël de la commune, organisée devant le local par les pompiers, qui a amené une grande bouffée de chaleur à ce week-end maussade.

Il s'y est passé quoi ?

Répondant à l'appel de Swisslinux.org, plusieurs associations et organismes étaient présents, favorisant ainsi les échanges inter-disciplinaires et les discussions animées. Petit tour de présentations.

Les bricoleurs du Post Tenebras Lab(le hackerspace genevois) ont profité d'une salle d'atelier pour travailler sur un système de paiement sans fil entièrement libre (matériel et logicel). ATICOM, association orientée vers l'enseignement et la pédagogie, a présenté ses activités lors d'une conférence. Doxel.org a présenté ses dernières avancées en photo-grammétrie avec des senseurs optiques non-calibrés: impressionnante combinaison de technologies pour la reconstitution de scènes tri-dimensionnelles à l'aide de photos prises par des téléphones portables. L' IAPC a amené et mis en place tout le matériel nécessaire pour l'implantation d'une station radio-amateur: entre l'antenne d'un mètre cinquante et les équipements électroniques, l'ensemble en a impressioné plus d'un. Axel & Frank, venus de loin, ont présenté leur projet collaboratif de livre sur les techniques d'empaquetage pour  Debian (en allemand). La présentation a abordé les défis éditoriaux (trouver, puis convaincre un éditeur de la viabilité et de l'intérêt d'un livre libre) et les défis techniques (collaboration à deux personnes géographiquement distantes sur un même ouvrage, ouverture de la rédaction aux contributeurs externes, assurer la construction et la distribution du livre dans différents formats, etc.).

Défis et Organisation

20 personnes étaient déjà présentes vendredi soir, pour un souper en commun “ à la bonne franquette“. Le lendemain soir, 8 caquelons de fondue ont été servis aux 35 participants. Ensuite, si d'aucuns restaient sur leurs laptops, d'autres ont laissé leurs claviers de côté pour des discussions ou des jeux de société. Autant dire que la soirée ne s'est pas terminée tôt!

L'organisation d'une telle conférence, bien que modeste en nombre de participants, est tout de même une suite de défis à relever. Au niveau des repas, la décision a été prise de prendre une équipe professionnelle pour la cuisine: ce fut une bénédiction culinaire! Si mettre en place et maintenir une infrastructure sans fil pour 30 participants n'est pas si compliqué en théorie, en pratique, ce n'est pas le WiFi qui a failli, mais l' uplink Swisscom. La conférence s'est donc terminée en accédant à l'Internet par la 4G.

Swisslinux.org remercie les différents parrains qui ont permis la tenue de cet événement: le GULL et  ATICOM pour les soutiens financiers et Liip pour avoir assuré la logistique et le financement du café pour tout le monde.

À l'année prochaine, pour une nouvelle édition, qu'on espère enneigée!

That's a situation every Drupal developer came accross at least once in his life: deployment nightmare. How can we maintain and deploy a website that has almost everything stored in its database? Some people use the “click-click in the admin until everything is fixed” method, while others directly fetch the source with an SCM software installed on the target server and apply database patches by hand. But let's think again about what “deploying” implies… A typical Drupal website:

• is a set of files to be deployed
• has some dependencies (Apache and PHP are some of them, or you might be using curl in your code so you'll need the php-curl extension)
• uses a database that needs to be updated along with the code
• uses some configuration depending on the instance (like database credentials)

All of these points can be automated using a well-known method: Debian packaging. Debian packages allow us to pack a set of files thus creating a package that will have other packages as dependencies and custom install scripts (like postinst). Also debconf allows us to easily configure a package. That's perfectly suited to our needs and gives us the following advantages:

• we can automatically backup the database before updating the site (also database management is done by dbconfig-common)
• we don't need to install software dependencies (eg. php modules) by hand
• we clearly know if the update went well or not (package in a broken state)
• we can easily reconfigure our package using dpkg-reconfigure (eg. if the IP address of our database server changed)
• we always know which version of the site is deployed

How do we package

A basic Debian package is quite easy to make: you create some files giving information about which files should go in the package, where they should be put, what packages your package depends on and what additional commands should be executed during the install process. You can also create a config file which will define the questions that should be asked when installing the package (in our case that will be the DB credentials, the install profile to use, the site name, etc).

Once your package is created you can scp it to your target server and install it using dpkg. Done!

I know you're wondering “there's no difference with a tar file, so why losing time creating a deb file? And you talked about database updates?”.

Features to the rescue

Drupal Features is a great module that allows you to do some click-click stuff on your dev machine and then export it as a module. That way, you'll be able to deploy your modifications without having to do any click-click stuff again and without having to worry about your database changes. You can export blocks, views, content types and even variables. Also it has a drush interface that allows you to revert a feature back into your database, which is just what we need for our deployment stuff.

Of course there are some things you won't be able to write with features, but you can still fall back to hook_update_N functions.

We now have nice modules that will update everything we need. We just need to call them in our deployment postinst file so they will be automatically applied after the deployment: “drush fra” will revert all our features back to the database and “drush updb” will take care of hook_update_N functions.

Conclusion

Packaging your Drupal site using Debian packages takes some time at the beginning because you have to write some scripts and understand how Debian packaging works. But once you've done that, you'll be able to deploy your website in a fully-automated way, without having to worry whether the update went well or not, because if your staging deployment worked, you know your prod deployment will too. Don't forget we have some nice scripts you can use to ease your deployment a little more.

Happy packaging!

You sent me now approx. 3 mails from 3 different people that I should change the License of various packages to either BSD or LGPL. Geeez, to put it in Helgi's words: Don't you guys ever talk internally between you guys to keep this from happening ?

Anyway, the PHP community is aware of some of the problems of the PHP license itself and AFAIK some people are trying to find a decent solution to this. Until that is solved, please stop bickering and if you can't sleep anymore due to that, please do not hesitate to remove my packages from your distribution .)

PS: I'm fine with the BSD or Apache2 License for all my packages, it's just not my top priority to change the license currently. Contacting the other authors, making a new release and all that is not a task done in 2 minutes…