Rainloop s'installe extrêmement facilement sur Nextcloud 11 pour transformer votre gestionnaire cloud favori en webmail fort pratique.
Activer l'application
La première étape consiste à activer l'application dans le magasin à application de Nextcloud. D'abord, cliquer sur le menu en haut à gauche puis sur le bouton "+ Apps" pour ouvrir le magasin à application.
Dans la catégorie "Social & communication", on trouve l'application Rainloop qu'il suffit alors d'activer :
Accéder à l'administration de Rainloop
Après activation, réfrénez cette envie irrépressible de cliquer sur l'icône "Email" apparue aux côtés de vos applications (ça ne servira à rien sans quelques paramétrages préalables) et rendez-vous dans la page d'administration de Nextcloud, section "Additionnal settings". Là, dans le paragraphe "RainLoop Webmail" fraîchement apparu, cliquez sur "Go to RainLoop Webmail admin panel". Alternativement, vous pouvez appeler cette URL http://cloud.url/index.php/apps/rainloop/app/?admin (en remplaçant http://cloud.url par une URL valide et conforme à votre cas).
Au premier usage, le nom d'utilisateur de l'administration est "admin" et le mot de passe "12345". Nul besoin de vous inviter à modifier cela !
Paramétrer Rainloop
Les paramétrages et optimisations de Rainloop abondent. Pour aller à l'essentiel, rendez-vous dans la section "Domains".
Le principe est simple : vous allez paramétrer (et de fait autoriser) les utilisateurs de Rainloop (dans Nextcloud) à se connecter à un IMAP/SMTP selon le domaine de leur adresse courriel. Par exemple, vos utilisateurs ont des adresses alice@mondomaine.fr et bob@mondomaine.fr. Nous allons donc ajouter le domaine "mondomaine.fr" et paramétrer l'IMAP et le SMTP pour ce domaine :
Désormais, sur leur compte Nextcloud, quand Alice et Bob ouvriront Rainloop, ils pourront saisir leur adresse (respectivement alice@mondomaine.fr et bob@mondomaine.fr) et Rainloop saura quels paramétrages IMAP/SMTP utiliser pour rapatrier le contenu de leur boîte courriel.
Et hop, grosse mise à jour du fail2ban pour OpenBSD : vilain.
Suite à une remarque de 22decembre concernant les Process lancés, j'ai retroussé mes manches pour essayer de maîtriser un minimum les async des dernières versions de python.
Le résultat est plus léger et facile à comprendre à mon sens.
Au passage, plusieurs expressions régulières pour protéger certains services ont été ajoutées (dovecot, erreur http 401...).
Comme toujours, les suggestions et contributions sont les bienvenues !
Au détour d’une news, je suis tombé sur l’annonce de la mise en place d’un moteur de recherche dédié aux images placées sous licences libres (https://creativecommons.org/2017/02/07/new-cc-search/). Cette initiative provient de la fondation Creative Commons et permet de rechercher des images réutilisables dans différents contextes (simple réutilisation, utilisation commerciale…).
Pour le moment le moteur est disponible en version beta (https://ccsearch.creativecommons.org/) et vous êtes bien entendu invité à faire vos retours à la fondation Creative Commons. Il devrait évoluer au fur à mesure des retours notamment en intégrant de nouveaux services.
Le périmètre couvert par cette version beta est pour le moment plutôt restreint. En effet, la fondation Creative Commons parle d’un pour cent des 10 millions d’images publiées sous licence « Creative Commons ». Les données indexées pour le moment proviennent de sources comme Flickr (près de 90% de la base) ou 500px. Ce périmètre devrait croître au fil du temps pour couvrir à terme l’ensemble du patrimoine disponible.
J'utilise Jenkins depuis quelques années. Un peu comme tout le monde je suis passé à la 2 au moment de sa sortie. Comme beaucoup, je n'ai pas vraiment vu de grosse différence avec les versions 1.6xx (si ce n'est que mes jobs ne fonctionnait plus mais ça, c'est une autre histoire). Au bout d'un moment je suis tombé sur une pépite : les pipeline/workflow de Jenkins.
Mais avant de parler de ça, je vais vous parler de ce que je faisais traditionnellement.
Création de job et parallélisation
Pour résumé, je gère énormément d'installations ou de compilation en tout genre et Jenkins me sert d'esclave personnel : il lance des playbooks Ansible, des shells Unix ou des compilations maven (beurk !). Je colle généralement ces scripts dans le repository Git des projets et je les appelle depuis Jenkins. Le petit problème est que j'ai quand même à créer ces jobs et que je dois gérer l'enchaînement de ces éléments.
Fonction de la difficulté de la tâche, je passe soit par des déclenchements de jobs (natif Jenkins) soit carrément des jobs permettant d'orchestrer plusieurs lancements (plugin Multijob).
Pour ceux qui ne le connaîtrait pas, le plugin Multijob est tout de même bien fait et permet de très facilement gérer des lancements d'opérations en parallèle assez complexe (cf capture d'écran).
Exemple de Multijob
Malgré tout, ça implique que pour chaque phase, vous aurez un job à définir (qui ne vont pas contenir grand chose si ce n'est un appel à un playbook Ansible) ainsi qu'un job supplémentaire permettant de piloter le lancement des autres jobs et ceci depuis l'interface graphique de Jenkins.
Vous l'aurez compris, ça fait beaucoup d'opérations manuelles à réaliser et vous n'avez pas vraiment de moyen de faire ça proprement (sauf à bricoler les fichiers XML de Jenkins). Autre problème, vous ne savez pas qui modifie quoi à quel moment. Vous n'avez aucun moyen de savoir si une modification a été réalisée par quelqu'un qui pourrait expliquer le gros plantage de compilation au moment de la release de votre projet.
C'est là qu'on va voir en quoi les pipelines/workflows Jenkins peuvent répondre à ce type de problème.
Les pipelines sous Jenkins
Première chose à savoir, vous n'avez plus à aller dans l'interface Jenkins pour mettre à jour vos jobs : vous créez votre Job dans l'interface Jenkins (vivement qu'on puisse scripter ça proprement ...), vous associez votre repository de code, vous rentrez le nom du fichier décrivant le pipeline et c'est à peu près tout. Et le reste me direz-vous ? On va voir que le pipeline remplace ça avantageusement :
Besoin de récupérer la dernière version du code ? Utilisez le mot clé checkout scm ;
Besoin de lancer une tâche ? Le mot clé sh est là pour ça ;
Lancement en parallèle ? La fonction parallel est là pour ça !
Vous l'aurez compris, ça permet de remplacer à la fois vos micro jobs ainsi que le job chapeau de pilotage des autres jobs.
Autre chose, c'est du groovy ce qui permet de faire des choses relativement propre par rapport à du shell Unix. Il est même possible de faire des librairies de fonction pour réutiliser du code. C'est magique je vous avais dit !
Exemple de pipeline
Avant d'aller plus loin, voici un petit exemple de pipeline :
node() { // Étape 1 stage('etapes-1') { parallel( 'etape-1.1': { echo "Job 1 de l'étape 1" }, 'etape-1.2': { echo "Job 2 de l'étape 1" }, ) } // Étape 2 stage('etapes-2') { echo "Job 1 de l'étape 2" } // Étape 3 stage('etapes-3') { parallel( 'etape-3.1': { // Cette opération doit prendre moins de 10 secondes timeout(time: 10, unit: 'SECONDS') { echo "Job 1 de l'étape 3" } }, 'etape-3.2': { echo "Job 2 de l'étape 3" }, 'etape-3.3': { echo "Job 3 de l'étape 3" }, ) } }
Les sections parallel vous permettent de lancer x jobs en même temps. Jenkins attendra gentiment que tous les jobs finissent leur lancement. Vous avez peur qu'un de ces petits coquins ne prenne trop de temps et ne vous rende jamais la main ? Ajoutez une section timeout et vous êtes sauvé !
Vous avez envie de gérer la reprise sur incident ? C'est du groovy ! Ajoutez une section try/catch !
Intégration dans Jenkins
On a vu à quoi ressemblait le code de notre pipeline. On va maintenant voir comment l'intégrer dans Jenkins :
On y voit plusieurs opérations :
Création du job pipeline dans Jenkins ;
Lancement du job et visualisation du résultat ;
Affichage dans la nouvelle interface Jenkins Blue Ocean.
Ici, le code a été intégré directement dans l'interface Jenkins. On peut utiliser ce mécanisme dans le cadre d'une mise au point ou de test mais si vous voulez travailler proprement, rien n'égale l'intégration dans un repository Git. Ça tombe bien, on va voir ça dans le chapitre suivant.
Stockage du pipeline dans Git
Première chose, nous allons créer un repository Git avec notre code pipeline :
Reste maintenant à intégrer notre code dans l'interface de Jenkins de la manière suivante :
NB : Si vous appelez votre fichier de pipeline autrement que Jenkinsfile, il faudra le préciser au moment de la création de votre job.
Pour finir
Voilà, ça sera tout pour l'instant. Ça donne déjà un bon aperçu de ce qu'il est possible de faire. Dans un prochain article, j'essaierai de vous présenter une autre fonction très sympathique des pipelines : l'écriture de librairie pipeline (avec le mot clé load). En attendant, bonne intégration continue !
C’est à dire qu’il ne devrait plus y avoir de changement de versions majeures dans les paquets. Seules les corrections de sécurité, de bugs ou de traductions sont maintenant acceptées (sauf dérogation)
On peut donc faire un petit tour des versions des logiciels qui seront dans la version finale:
Il en reste 275 aujourd’hui mais des bugs seront sûrement découverts pendant cette période de tests approfondis. Habituellement, la période de freeze dure environ 6 mois. (Freeze de Debian 8: nov2014 -> avril2015)
