Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Mot-clefs : Sysadmin

Certificat Let's Encrypt configuré au top

Guillaume Kulakowski

Dernièrement j'ai dû, pour le compte d'un client, faire une étude pour rendre un site compatible ATS au niveau de la sécurité. Il en est ressorti plusieurs problèmes :

  • La CVE-2016-2107 pour cause de lib-openssl pas à jour.
  • Des Ciphers et des protocoles pas top...
  • Pas de  PFS.

Le bilan : une note de "F".

Du coup, j'ai regardé un de mes domaines SSL et je me suis rendu compte que moi aussi je n'étais pas au top... Du coup une petite correction s'imposée.

Première étape : mettre à jour le container apache pour avoir les dernières versions de lib-openssl et d'apache.

Pour ça, rien de plus simple :

docker-compose build llaumgui_httpd24 ; docker-compose stop llaumgui_httpd24 ; docker-compose rm llaumgui_httpd24 ; docker-compose up -d llaumgui_httpd24

Seconde étapes : aller sur Mozilla SSL Configuration Generator pour trouver la configuration qui vous va bien. Pour moi je suis parti là dessus.

Troisième étape : faire le ménage dans la configuration de base de RHEL7.

Quatrième étape : aller sur Let'sEncrypt pour avoir un certificats SSL gratuit ! Alors là, faites gaffe, il existe plein de truc plus ou moins lourd pour générer des certificats SSL chez Let's Encrypt. Perso j'ai retenu acme-tiny car je n'ai rien trouvé de plus petit !

Il faut juste ouvrir votre port 80 et tout rediriger sur le 443 sauf bien sûr le chalenge Let's Encrypt :

<virtualhost>
    ServerName sub.domain.ltd
    ServerAdmin me@domain.ltd

    ### Let's encrypt
    Alias /.well-known/acme-challenge/ /var/www/challenges/
    <directory>
        # Allow open access:
        Require all granted
    </directory>

    ### Redirect to HTTPs
    RewriteEngine on
    RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/
    RewriteRule (.*) https://sub.domain.ltd$1 [R=301,L]
</virtualhost>

Et c'est tout ! Plus qu'à controller avec Qualys SSL Labs.

qualys_ssl_labs.jpg

Nouveau serveur et stack LAMP propulsée par Docker !

Guillaume Kulakowski

Afin de réduire les coûts d'hébergement de Scenario-PaintBall, site/forums qui partagent le même serveur que ce blog, nous avons étudié le remplacement de notre vieux Kimsufi 16G à 49€ TTC / mois. En effet, changer de serveur permet (presque) toujours d'avoir un serveur plus récent mais surtout tout aussi voir plus puissant que l'ancien et le tout pour moins cher. Après une rapide étude des solutions du marché, nous avons retenu une Dedibox XC 2016 à 19€20 TTC / mois.

Pour l'occasion j'en ai profité pour refondre complètement l'architecture d'hébergement :

  • Utilisation de CentOS 7 à la place de RHEL 6. Pourquoi passer de Red Hat vers CentOS ? Car, bien qu'en tant que contributeur, j'ai toujours des licences gratuites, je dois les faire renouveler tous les ans et ça me prend du temps et de l'énergie... et je suis fainéant.
  • Activation de SELinux ! Si j'ai déjà sauté le pas sur mes postes de travail (Fedora) depuis bien longtemps, l'ancien serveur était encore en mode désactivé ! Du coup je pourrais arborer fièrement le T-Shirt "setenforce 1" et ainsi faire plaisir à Dan.
  • Utilisation d'un cache HTTP : Varnish.
  • Mise en place d'une stack LAMP full Docker !

Et c'est ce dernier point dont je vais discuter.

docker.png  

Description de la stack LAMP dockérisée

Choix du moteur de stockage

Concernant le choix du moteur de stockage, je ne suis pas parti sur le natif CentOS, à savoir Device Mapper, mais j'ai retenu OverlayFS. J'ai fais ce choix sur les conseils de ce tutoriel et aussi de cette page de la documentation de Docker mais surtout à la lecture de cette phrase :

Many people consider OverlayFS as the future of the Docker storage drive

Gestion de l'envoi des mails et impact sur le réseau

Premier choix qui peut être discuté, j'ai fait le choix de ne pas mettre de container pour envoyer les mails mais d'envoyer les mails directement depuis l'host. En effet, j'ai pour habitude de considérer qu'un serveur doit posséder un MTA, c'est dailleurs une recommandation du Red Hat LSB.

Ceci implique donc que j'ai une communication des containers vers l'host. Comme j'ai un firewall (FirewallD) et que je veux sécuriser les choses au maximum, ceci implique une interface de communication avec un nom fixe. C'est à dire que j'exploite l'interface docker0 et non une interface créée par Compose qui serait créé avec un nom imprédictible (brd-hashquelconque). Du coup pour ouvrir les ports :

# On associe l'interface docker0 à une zone de confiance :
firewall-cmd --permanent --zone=trusted --change-interface=docker0

# On ouvre le service pour cette zone
firewall-cmd --permanent --zone=trusted --add-service=smtp

# On recharge :
firewall-cmd --reload

Pour que Compose utilise le réseau par défaut de docker, appelée "bridge" et utilisant l'interface docker0, il suffit de rajouter la ligne suivante dans Compose :

network_mode: "bridge"

Architecture et typologie de containers

Pour le moment Scénario PaintBall et ce blog partagent les mêmes versions de PHP (5.6) et Apache (2.4). J'utilise donc les mêmes images mais chaque infrastructure possède son propre container apache ainsi que son propre container PHP(-FPM). Bien entendu, un container Varnish mutualisé est présent en amont afin de dispatcher les requêtes sur la bonnes stack mais également pour assurer un rôle de cache HTTP. Concernant la base de données, j'ai fait le choix (discutable là encore) d'utiliser le même container pour les 2 stacks, c'est quand même plus simple à administrer, optimiser, backuper, etc....

De plus, j'ai également fait le choix de ne pas porter les applications Web (IPB, Dotrclear, WordPress) au sein des containers mais au sein de volumes. Ceci me permet de pouvoir mettre à jour les applications directement depuis l'host. Ceci me permet également de faire la migration de serveur plus rapidement.

Schéma d'architecture

Dans un mode 100% Dockerisé, j'aurais 1 groupe de container (Apache, PHP, Memcached, MariaDB, etc...) par application. Dans ce même mode, Dotclear (pour prendre cet exemple), serait présent directement dans les containers PHP et Apache et seul le répertoire public serait un volume partagé. Mais ça me prendrait carrément plus de temps (recréation des containers à chaque mise à jour de Dotclear ou d'un plugin) et le ROI serait négatif car je n'ai pas plusieurs environnements (prod, préprod, etc...), on parle ici d'applications personnelles. Bref, voici à quoi ça ressemble :

Architecture Docker Architecture Docker

Pour ce qui est des containers, j'ai fait un mix entre les containers officiels (MariaDB, Memcached) et des containers personnels (Apache 2.4, PHP 5.6).

Mon docker-compose.yml

Pour lancer mes containers, je suis fainéant, je passe par Compose. J'ai récupéré ma config perso, que j'ai un peu retravaillée :

version: '2'
services:

  ##################################################### Mutualized architecture
  famas_varnish:
    container_name: famas_varnish
    image: million12/varnish
    restart: always
    mem_limit: 1g
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/famas/varnish/conf/default.vcl:/etc/varnish/default.vcl:ro
    network_mode: "bridge"
    ports:
     - 80:80
    links:
     - llaumgui_httpd24:llaumgui
     - radinus_httpd24:radinus

  famas_mariadb10:
    container_name: famas_mariadb10
    image: mariadb:10
    restart: always
    mem_limit: 4g
    env_file:
     - .env
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/famas/mysql:/var/lib/mysql
    network_mode: "bridge"
    expose:
     - 3306

  ######################################################### spb's architecture
  spb_httpd24:
    container_name: spb_httpd24
    image: llaumgui/centos7-scl-httpd24
    build: 
      context: build/httpd/2.4/
    restart: always
    mem_limit: 512m
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/www/spb:/var/www/spb
     #- /docker/volumes/www/.htpasswd:/var/www/.htpasswd
     #- /docker/volumes/www/challenges:/var/www/challenges
     - /docker/volumes/spb/httpd24/conf/vhost.d:/etc/httpd/vhost.d:ro
     - /docker/volumes/spb/httpd24/conf/ssl:/etc/httpd/ssl/:ro
     - /docker/volumes/spb/httpd24/log/:/var/log/httpd24
    network_mode: "bridge"
    expose:
     - 80
    links:
     - spb_php56:php

  spb_php56:
    container_name: spb_php56
    image: llaumgui/centos7-scl-php56
    build:
      context: build/php-fpm/5.6/
    restart: always
    mem_limit: 2g
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/www/spb:/var/www/spb
     - /docker/volumes/spb/php56/log:/var/log/php-fpm
    network_mode: "bridge"
    expose:
     - 9000
    links:
     - famas_mariadb10:database
     - spb_memcached:memcached
    extra_hosts:
     - "mail:172.17.0.1"

  spb_memcached:
    container_name: spb_memcached
    image: memcached
    mem_limit: 512m
    volumes:
     - /etc/localtime:/etc/localtime:ro
    network_mode: "bridge"
    expose:
     - 1121

  ##################################################### llaumgui's architecture
  llaumgui_httpd24:
    container_name: llaumgui_httpd24
    image: llaumgui/centos7-scl-httpd24
    build: 
      context: build/httpd/2.4/
    restart: always
    mem_limit: 512m
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/www/llaumgui:/var/www/llaumgui
     - /docker/volumes/www/.htpasswd:/var/www/.htpasswd
     - /docker/volumes/www/challenges:/var/www/challenges
     - /docker/volumes/llaumgui/httpd24/conf/vhost.d:/etc/httpd/vhost.d:ro
     - /docker/volumes/llaumgui/httpd24/conf/ssl:/etc/httpd/ssl/:ro
     - /docker/volumes/llaumgui/httpd24/log/:/var/log/httpd24
    network_mode: "bridge"
    ports:
     #- 80:80
     - 443:443
    expose:
     - 80
    links:
     - llaumgui_php56:php
     - llaumgui_gitlab:gitlab

  llaumgui_php56:
    container_name: llaumgui_php56
    image: llaumgui/centos7-scl-php56
    build:
      context: build/php-fpm/5.6/
    restart: always
    mem_limit: 512m
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/www/llaumgui:/var/www/llaumgui
     - /docker/volumes/llaumgui/php56/log/:/var/log/php-fpm
    network_mode: "bridge"
    expose:
     - 9000
    links:
     - famas_mariadb10:database
    extra_hosts:
     - "mail:172.17.0.1"

Conclusion

La nouvelle architecture est en cours de test sur le blog et si c'est positif SPB devrait bientôt nous rejoindre. J'ai également quelques pistes pour améliorer les performances :

  • Réfléchir à l'utilisation d'1 container Postfix.
  • Migrer le blog en PHP 7.

Nouveau serveur et stack LAMP propulsée par Docker !

Guillaume Kulakowski

Afin de réduire les coûts d'hébergement de Scenario-PaintBall, site/forums qui partagent le même serveur que ce blog, nous avons étudié le remplacement de notre vieux Kimsufi 16G à 49€ TTC / mois. En effet, changer de serveur permet (presque) toujours d'avoir un serveur plus récent mais surtout tout aussi voir plus puissant que l'ancien et le tout pour moins cher. Après une rapide étude des solutions du marché, nous avons retenu une Dedibox XC 2016 à 19€20 TTC / mois.

Pour l'occasion j'en ai profité pour refondre complètement l'architecture d'hébergement :

  • Utilisation de CentOS 7 à la place de RHEL 6. Pourquoi passer de Red Hat vers CentOS ? Car, bien qu'en tant que contributeur, j'ai toujours des licences gratuites, je dois les faire renouveler tous les ans et ça me prend du temps et de l'énergie... et je suis fainéant.
  • Activation de SELinux ! Si j'ai déjà sauté le pas sur mes postes de travail (Fedora) depuis bien longtemps, l'ancien serveur était encore en mode désactivé ! Du coup je pourrais arborer fièrement le T-Shirt "setenforce 1" et ainsi faire plaisir à Dan.
  • Utilisation d'un cache HTTP : Varnish.
  • Mise en place d'une stack LAMP full Docker !

Et c'est ce dernier point dont je vais discuter.

docker.png  

Description de la stack LAMP dockérisée

Choix du moteur de stockage

Concernant le choix du moteur de stockage, je ne suis pas parti sur le natif CentOS, à savoir Device Mapper, mais j'ai retenu OverlayFS. J'ai fais ce choix sur les conseils de ce tutoriel et aussi de cette page de la documentation de Docker mais surtout à la lecture de cette phrase :

Many people consider OverlayFS as the future of the Docker storage drive

Gestion de l'envoi des mails et impact sur le réseau

Premier choix qui peut être discuté, j'ai fait le choix de ne pas mettre de container pour envoyer les mails mais d'envoyer les mails directement depuis l'host. En effet, j'ai pour habitude de considérer qu'un serveur doit posséder un MTA, c'est dailleurs une recommandation du Red Hat LSB.

Ceci implique donc que j'ai une communication des containers vers l'host. Comme j'ai un firewall (FirewallD) et que je veux sécuriser les choses au maximum, ceci implique une interface de communication avec un nom fixe. C'est à dire que j'exploite l'interface docker0 et non une interface créée par Compose qui serait créé avec un nom imprédictible (brd-hashquelconque). Du coup pour ouvrir les ports :

# On associe l'interface docker0 à une zone de confiance :
firewall-cmd --permanent --zone=trusted --change-interface=docker0

# On ouvre le service pour cette zone
firewall-cmd --permanent --zone=trusted --add-service=smtp

# On recharge :
firewall-cmd --reload

Pour que Compose utilise le réseau par défaut de docker, appelée "bridge" et utilisant l'interface docker0, il suffit de rajouter la ligne suivante dans Compose :

network_mode: "bridge"

Architecture et typologie de containers

Pour le moment Scénario PaintBall et ce blog partagent les mêmes versions de PHP (5.6) et Apache (2.4). J'utilise donc les mêmes images mais chaque infrastructure possède son propre container apache ainsi que son propre container PHP(-FPM). Bien entendu, un container Varnish mutualisé est présent en amont afin de dispatcher les requêtes sur la bonnes stack mais également pour assurer un rôle de cache HTTP. Concernant la base de données, j'ai fait le choix (discutable là encore) d'utiliser le même container pour les 2 stacks, c'est quand même plus simple à administrer, optimiser, backuper, etc....

De plus, j'ai également fait le choix de ne pas porter les applications Web (IPB, Dotrclear, WordPress) au sein des containers mais au sein de volumes. Ceci me permet de pouvoir mettre à jour les applications directement depuis l'host. Ceci me permet également de faire la migration de serveur plus rapidement.

Schéma d'architecture

Dans un mode 100% Dockerisé, j'aurais 1 groupe de container (Apache, PHP, Memcached, MariaDB, etc...) par application. Dans ce même mode, Dotclear (pour prendre cet exemple), serait présent directement dans les containers PHP et Apache et seul le répertoire public serait un volume partagé. Mais ça me prendrait carrément plus de temps (recréation des containers à chaque mise à jour de Dotclear ou d'un plugin) et le ROI serait négatif car je n'ai pas plusieurs environnements (prod, préprod, etc...), on parle ici d'applications personnelles. Bref, voici à quoi ça ressemble :

Architecture Docker Architecture Docker

Pour ce qui est des containers, j'ai fait un mix entre les containers officiels (MariaDB, Memcached) et des containers personnels (Apache 2.4, PHP 5.6).

Mon docker-compose.yml

Pour lancer mes containers, je suis fainéant, je passe par Compose. J'ai récupéré ma config perso, que j'ai un peu retravaillée :

version: '2'
services:

  ##################################################### Mutualized architecture
  famas_varnish:
    container_name: famas_varnish
    image: million12/varnish
    restart: always
    mem_limit: 1g
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/famas/varnish/conf/default.vcl:/etc/varnish/default.vcl:ro
    network_mode: "bridge"
    ports:
     - 80:80
    links:
     - llaumgui_httpd24:llaumgui
     - spb_httpd24:spb

  famas_mariadb10:
    container_name: famas_mariadb10
    image: mariadb:10
    restart: always
    mem_limit: 4g
    env_file:
     - .env
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/famas/mysql:/var/lib/mysql
    network_mode: "bridge"
    expose:
     - 3306

  ######################################################### spb's architecture
  spb_httpd24:
    container_name: spb_httpd24
    image: llaumgui/centos7-scl-httpd24
    build: 
      context: build/httpd/2.4/
    restart: always
    mem_limit: 512m
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/www/spb:/var/www/spb
     #- /docker/volumes/www/.htpasswd:/var/www/.htpasswd
     #- /docker/volumes/www/challenges:/var/www/challenges
     - /docker/volumes/spb/httpd24/conf/vhost.d:/etc/httpd/vhost.d:ro
     - /docker/volumes/spb/httpd24/conf/ssl:/etc/httpd/ssl/:ro
     - /docker/volumes/spb/httpd24/log/:/var/log/httpd24
    network_mode: "bridge"
    expose:
     - 80
    links:
     - spb_php56:php

  spb_php56:
    container_name: spb_php56
    image: llaumgui/centos7-scl-php56
    build:
      context: build/php-fpm/5.6/
    restart: always
    mem_limit: 2g
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/www/spb:/var/www/spb
     - /docker/volumes/spb/php56/log:/var/log/php-fpm
    network_mode: "bridge"
    expose:
     - 9000
    links:
     - famas_mariadb10:database
     - spb_memcached:memcached
    extra_hosts:
     - "mail:172.17.0.1"

  spb_memcached:
    container_name: spb_memcached
    image: memcached
    mem_limit: 512m
    volumes:
     - /etc/localtime:/etc/localtime:ro
    network_mode: "bridge"
    expose:
     - 1121

  ##################################################### llaumgui's architecture
  llaumgui_httpd24:
    container_name: llaumgui_httpd24
    image: llaumgui/centos7-scl-httpd24
    build: 
      context: build/httpd/2.4/
    restart: always
    mem_limit: 512m
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/www/llaumgui:/var/www/llaumgui
     - /docker/volumes/www/.htpasswd:/var/www/.htpasswd
     - /docker/volumes/www/challenges:/var/www/challenges
     - /docker/volumes/llaumgui/httpd24/conf/vhost.d:/etc/httpd/vhost.d:ro
     - /docker/volumes/llaumgui/httpd24/conf/ssl:/etc/httpd/ssl/:ro
     - /docker/volumes/llaumgui/httpd24/log/:/var/log/httpd24
    network_mode: "bridge"
    ports:
     #- 80:80
     - 443:443
    expose:
     - 80
    links:
     - llaumgui_php56:php
     - llaumgui_gitlab:gitlab

  llaumgui_php56:
    container_name: llaumgui_php56
    image: llaumgui/centos7-scl-php56
    build:
      context: build/php-fpm/5.6/
    restart: always
    mem_limit: 512m
    volumes:
     - /etc/localtime:/etc/localtime:ro
     - /docker/volumes/www/llaumgui:/var/www/llaumgui
     - /docker/volumes/llaumgui/php56/log/:/var/log/php-fpm
    network_mode: "bridge"
    expose:
     - 9000
    links:
     - famas_mariadb10:database
    extra_hosts:
     - "mail:172.17.0.1"

Conclusion

La nouvelle architecture est en cours de test sur le blog et si c'est positif SPB devrait bientôt nous rejoindre. J'ai également quelques pistes pour améliorer les performances :

  • Réfléchir à l'utilisation d'1 container Postfix.
  • Migrer le blog en PHP 7.

Surveillance d'une carte contrôleur RAID LSI MegaSAS 9260 sous Debian / Proxmox

Guillaume Kulakowski

Au travail, nous utilisons un serveur Dell Power Edge R710 pour gérer plusieurs VMs de développements. Pour l'hyperviseur et connaissant mes obédiences, nous sommes partis sur une solution Open source à savoir ProxMox VE. Dell fourni pas mal d'outils pour monitorer leurs machines mais rien pour Proxmox basée sur une Debian et ne disposant pas d'interface graphique.

Bref, suite à une visite de la salle blanche, je me suis rendu compte que l'un des disques durs RAID 5 était en erreur sans qu'aucune de mes sondes ne me remonte la moindre information. J'ai donc dû rechercher des informations sur la carte contrôleur RAID (une LSI MegaSAS 9260) pour voir comment sous Linux et plus particulièrement sous Debian, je pouvais lui faire cracher des informations.

Après un peu de recherche, je suis tombé sur un dépôt apt qui propose un outil appelé megacli supportant cette carte et qui permet de retourner les informations en ligne de commande. De là, j'ai fais un petit cron qui va lancer une analyse et rechercher les mots tels que "Degraded" ou "Failed" et me voila avec une solution de surveillance rapide.

Surveillance d'une carte contrôleur RAID LSI MegaSAS 9260 sous Debian / Proxmox

Guillaume Kulakowski

Au travail, nous utilisons un serveur Dell Power Edge R710 pour gérer plusieurs VMs de développements. Pour l'hyperviseur et connaissant mes obédiences, nous sommes partis sur une solution Open source à savoir ProxMox VE. Dell fourni pas mal d'outils pour monitorer leurs machines mais rien pour Proxmox basée sur une Debian et ne disposant pas d'interface graphique.

Bref, suite à une visite de la salle blanche, je me suis rendu compte que l'un des disques durs RAID 5 était en erreur sans qu'aucune de mes sondes ne me remonte la moindre information. J'ai donc dû rechercher des informations sur la carte contrôleur RAID (une LSI MegaSAS 9260) pour voir comment sous Linux et plus particulièrement sous Debian, je pouvais lui faire cracher des informations.

Après un peu de recherche, je suis tombé sur un dépôt apt qui propose un outil appelé megacli supportant cette carte et qui permet de retourner les informations en ligne de commande. De là, j'ai fais un petit cron qui va lancer une analyse et rechercher les mots tels que "Degraded" ou "Failed" et me voila avec une solution de surveillance rapide.

Poezio, c'est magique. Vraiment.

Matthieu Saulnier

poezio-room-fedora.pngÀ la recherche d'un client XMPP en console afin de pouvoir l'utiliser dans un multiplexeur de terminal (Tmux), j'ai découvert grâce au bouche à oreille ce très méconnu logiciel, qui comme la plupart des artistes peu connus, est l'un des meilleurs que j'ai jamais eu l'occasion de tester. Son design très raffiné lui procure une certaine prestance sur le bureau, confectionné avec un thème de couleurs lui donnant une présence marquée, ce programme ne passera pas inaperçu devant les regards amateurs. Le faire évoluer dans un Tmux ajoute certes une petite touche esthétique, mais surtout permet de laisser tourner le client connecté en arrière-plan. Les cas de figure où la session Tmux est détachée sont indénombrables, cela va du simple changement d'environnement de bureau au crash du serveur graphique en passant par des connexions VTY via SSH.logo-poezio.png

Ce qui m'a en premier choqué chez ce programme, c'est la simplicité de mise en route, plus besoin d'avoir un diplôme d'ingénieur aéronautique pour configurer un logiciel, d'autant plus qu'il fonctionne à la perfection sous l'utilisateur SELinux « user_u » (ce qui n'est pas le cas de certains clients dont je tairais le nom).

Après avoir démarré Poezio, taper la commande pour indiquer le compte jabber sur lequel se connecter :

/set jid <mon_compte_jabber@jabber.fr>

Une ligne confirmant l'opération devrait apparaitre :

19:12:40 Info> jid=<mon_compte_jabber@jabber.fr>

Puis taper la commande indiquant le mot de passe du compte :

/set password <phrase_de_passe>

19:17:31 Info> password=<phrase_de_passe>

(Si la phrase-passe contient un backslash, il faut l'échapper en mettant devant un backslash, les autres caractères spéciaux ne posent pas de soucis)

Taper la commande indiquant quel pseudo utiliser dans les salons de discusion :

/set default_nick Casper

19:24:58 Info> default_nick=Casper

Et si le pseudo est déjà utilisé dans le salon, ajouter au pseudo un underscore ou le caractère qui vous plaira :

/set alternative_nickname _

19:28:00 Info> alternative_nickname=_

Enfin on indique sur quel serveur se connecter :

/set server jabber.fr

19:33:25 Info> server=jabber.fr


Et on relance Poezio ! Le serveur et son certificat ayant changé depuis la dernière connexion établie, un message d'alerte est affiché :

WARNING! Server certificate has changed, accept? (y/n) y

Une fois connecté, on retrouve la liste de contacts affichée, les salons présents en marque-page sont rejoints, bref, tout ce qui est dépendant du compte Jabber reste identique avec Poezio. Ce qui m'a choqué en second chez ce programme, c'est son ergonomie. La fenêtre principale découpée par la moitié avec le roster et la fenêtre de status elle-même ciselée avec la fenêtre d'informations du contact sélectionné (avec les flèches) respire la clarté. Une barre inférieur listant toutes les fenêtres ouvertes donne une petite note classique à l'ensemble, la navigation entre les buffers se fera d'ailleurs avec Ctrl+n et Ctrl+p comme le veut la tradition. Les fenêtres de salons de discussion quant à elles, possèdent une approche plutôt révolutionnaire du problème puisqu'en plus de lister les participants du salon dans une petite fenêtre à droite, affiche les dernières ligne de la fenêtre de status en bas, très utile pour être averti lorsqu'un de nos contacts se connecte ou autres événements réseau du protocole XMPP. Pour rejoindre un nouveau salon, taper :

/join fedora@chat.jabberfr.org

Une nouvelle fenêtre est alors créée et nous sommes automatiquement basculé dessus. Toutes les fonctionnalités standards comme la console XML sont présentes ( /xml_tab ), l'ajout de divers plugins est facilité avec la commande /load, et les utilisateurs Fedora sont une fois encore privilégiés avec un paquet Poezio mis à jour à l'extrême dans le dépôt.

Chrooter avec systemd

Matthieu Saulnier

Ces temps-ci je n'arrète pas d'installer et de faire fonctionner des programmes dans des chroots, que ce soit des services ou de simples logiciels de développement. Sauf que voilà, la commande chroot est devenue obsolète, et puis systemd refuse catégoriquement de coopérer si l'on a chrooté son shell avec cette commande. D'autre part, lancer un service dans un chroot au démarrage de la machine est rendu possible avec le classique fichier Unit, mais on verra ça en seconde partie.

Quel système linux choisir pour son chroot ? De préférence un système incorporant systemd, le reste n'a pas d'importance. Je choisis donc Fedora 18. Si ce chroot a pour vocation de faire tourner un service, je recommande vivement de l'installer sur un Volume Logique à part entière qui servira à stocker la multitude de chroots qui seront créés ultérieurement. Les paquets requis pour l'installation minimale de Fedora sont listés dans le groupe Core.

# yum install --nogpgcheck --releasever=18 --installroot=/contener/fedora-18-x86_64/ @core

Une fois que yum a fini, pas la peine de commencer à monter /proc et /sys en bind dans l'arborescence du chroot. Oui ce temps et révolu, et c'est systemd qui virtualise complètement l'arborescence vitale tel que /sys et /proc ainsi que /dev (seuls les fichiers hors-périphérique matériel seront présent dans /dev). En réalité il le fera juste au moment de l'invocation de la commande pour chrooter son shell:

# systemd-nspawn -D /contener/fedora-18-x86_64/

À partir de là, vous pouvez faire *tout* ce que vous voulez jusqu'à la destruction totale et irréversible du système. On s'en fiche on peut en refaire un autre :-D Bon ça c'est surtout pour les nouveaux, les habitués en revanche installeront un programme dont les dépendances ne sont pas compatibles avec notre système principal (Fedora 19).

Point important: Tant que vous n'aurez pas manipulé yum dans le chroot (install/remove/update), la clé GPG du dépôt fedora ne sera pas importée dans la base RPM du chroot, ce qui aura pour effet de rendre obligatoire l'option --nogpgcheck dans les commandes yum lancées depuis l'extérieur du chroot, comme :

# yum update --nogpgcheck --releasever=18 --installroot=/contener/fedora-18-x86_64/

Enfin, pour administrer depuis notre système principal un service systemd préalablement installé dans notre chroot, il suffit de créer dans /etc/systemd/system/ un fichier Unit contenant deux options supplémentaires :

[Service]

RootDirectory=/contener/fedora-18-x86_64/

RootDirectoryStartOnly=yes

Le reste de la configuration du fichier est sur la base de n'importe quel service systemd. À noter que si le service installé dans le chroot fournit lui aussi un fichier Unit, celà ne servira strictement de le manipuler ou bien de l'activer (systemctl enable).

Importer une Autorité de Certification

Matthieu Saulnier Récemment j'ai eu à ajouter plusieurs autorités de certification sur mes différentes machines, celui de CAcert et le miens. Voici la technique pour ajouter une autorité de certification sur Fedora 19 et ultérieur à la base de confiance du système.

C'est une exclusivité de Fedora 19 si la technique est aussi simple. Elle consiste à placer le fichier du CA au format PEM dans le répertoire /etc/pki/ca-trust/source/anchors/ puis lancer la commande « update-ca-trust ». J'aimerais toutefois apporter une note sur la sécurité : qu'est-ce qui nous prouve que l'on a pas téléchargé un CA corrompu ? Gardons à l'esprit qu'à cause de ce CA, notre système acceptera tous les certificats TLS/SSL dont il est le signataire.

On commence par le récupérer, et on vérifie les droits de ce fichier, personne ne doit pouvoir le modifier sur le disque dur :
blackbird:~# curl http://www.cacert.org/certs/root.crt > /etc/pki/ca-trust/source/anchors/cacert.pem
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2569  100  2569    0     0  24307      0 --:--:-- --:--:-- --:--:-- 24466
blackbird:~# ll /etc/pki/ca-trust/source/anchors/cacert.pem
-rw-r--r--. 1 root root 2569  1 sept. 23:05 /etc/pki/ca-trust/source/anchors/cacert.pem


Puis on vérifie que l'on dispose bien du véritable CA émis par CAcert en comparant l'empreinte numérique établie selon l'algorithme SHA1, l'algo MD5 étant obsolète:
blackbird:~# openssl x509 -in /etc/pki/ca-trust/source/anchors/cacert.pem -noout -fingerprint
SHA1 Fingerprint=13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33


Cette empreinte numérique est publiée sur le site de CAcert afin que l'on puisse comparer. Il semblerait que l'empreinte corresponde, donc j'ai récupéré le bon fichier. Ce contrôle est le minimum vital pour ne pas accepter de certificats frauduleux. Ensuite on peut lancer la mise à jour des CA de confiance :
blackbird:~# update-ca-trust

Désormais les certificats émis par CAcert ne feront plus de warnings dans l'ensemble des logiciels manipulant des certificats comme les clients imap/smtp/xmpp/http.

Comme vous venez de l'apprendre, j'ai mis en place ma propre autorité de certification, j'aimerais juste expliquer "pourquoi". Tout d'abord parce que je veux pouvoir fournir une couche d'encryption SSL à quiconque le désire, sauf que cela entraine pour moi les problèmes suivants: Primo il est hors de question de payer 50€ un fichier (si vous voyez de quoi je parle). Secondo, ça ne fait que déplacer le problème, c'est à dire que si le CA signataire de mon certificat n'est pas fiable c'est sur le nez de mes visiteurs que ça va retomber. Tercio les certificats auto-signés c'est juste naze. Enfin quand on a plusieurs domaines, les CA comme CAcert ne délivrent qu'un seul certificat par personne morale, dans l'eau. Vu que je fournis déjà un certain nombre de services, autant faire les choses bien en faisant tout simplement une véritable Certificate Autority. Ah j'oubliais, mon root.pem est ici, et l'empreinte numérique est :
09:75:86:4A:20:36:0F:94:A1:39:11:4A:D3:2E:8E:BE:30:F2:24:29
(l'empreinte numérique est également présente sur la page "À Propos" au cas où)

Installation de seeks

Matthieu Saulnier

Voici la procèdure d'installation du méta-moteur de recherche Seeks en mode serveur web (pour avoir une jolie interface comme sur seeks.fr) sur serveur Fedora 18 hébergeant d'autres services web en parallèle.

Tout d'abord récupérer la dernière version du SRPM de WilQu, ce RPM Source est actuellement en revue pour être intègré au dépôt fedora.

Puis le compiler (si vous ne savez pas compiler un SRPM, suivez la doc).

Une fois le RPM construit, nous pouvons l'installer simplement avec YUM:

# yum install seeks-0.4.2-0.4.20130121git9f17d4a.fc18.x86_64.rpm

Seeks est un service géré par systemd qu'il faut tout d'abord configurer. Ses fichiers de configuration se situent dans le répertoire /etc/seeks/. J'ai dû en modifier 3 pour répondre à mes objectifs:

  • Activer le serveur web en chargeant le plugin correspondant
  • Désactiver le mode proxy automatiquement lorsque le serveur web est activé
  • Changer le port d'écoute du serveur web seeks
  • Ajouter le nœud seeks de gnunux.info en tant que pair

Ajouter à celà le minimum de configuration obligatoire comme il est très bien expliqué dans les commentaires des fichiers de conf, on obtient les changements suivants:

--- cf-config.bak       2013-07-16 04:54:56.717574124 +0200
+++ cf-config   2013-07-16 04:56:00.981903552 +0200
@@ -18,6 +18,7 @@ record-cache-timeout 600
 cf-peer http://www.seeks.fr bsn
 cf-peer http://seeks-project.info/search_exp.php bsn
 cf-peer http://seeks-project.info/search.php bsn
+cf-peer https://seeks.gnunux.info/ bsn
 
 # Time interval in seconds between two check on dead peers.
 # default: 300
--- config.bak  2013-07-16 04:58:19.703464280 +0200
+++ config      2013-07-16 06:00:45.648877805 +0200
@@ -85,7 +85,7 @@
 #      No email address is displayed on error pages and the CGI user
 #      interface.
 #
-# admin-address seeks-admin@example.com
+admin-address hostmaster@casperlefantom.net
 #
 #
 #  1.3. proxy-info-url
@@ -239,7 +239,7 @@ logdir /var/log/seeks
 #      Any log files must be writable by whatever user Seeks is
 #      being run as.
 #
-logfile logfile
+logfile seeks.log
 #
 #
 # 2.5. plugindir
@@ -269,7 +269,7 @@ logfile logfile
 #
 #      Use --plugin-repository your_repository to override the value at startup.
 #
-# plugindir /usr/local/lib/seeks
+plugindir /lib64/seeks/plugins
 #
 # 2.6. activated-plugin
 # ======================
@@ -311,7 +311,7 @@ activated-plugin uri-capture
 activated-plugin query-capture
 activated-plugin cf
 activated-plugin udb-service
-#activated-plugin httpserv
+activated-plugin httpserv
 #activated-plugin xsl-serializer
 activated-plugin readable

 #
@@ -341,7 +341,7 @@ activated-plugin readable
 #
 #      Use --data-repository your_repository to override the value at startup.
 #
-# datadir /usr/local/share/seeks
+datadir /usr/share/seeks/
 #
 #
 #  2.8. automatic-proxy-disable
@@ -361,7 +361,7 @@ activated-plugin readable
 #     1, the proxy is automatically disabled when the HTTP server plugin is
 #        running.
 #
-# automatic-proxy-disable 1
+automatic-proxy-disable 1
 #
 #
 #  2.9. user-db-file
@@ -646,7 +646,7 @@ debug 8192 # Non-fatal errors
 #
 #      Note that Seeks does not validate the specified hostname value.
 #
-#hostname hostname.example.org
+hostname search.casperlefantom.net
 #
 #
 #  4. ACCESS CONTROL AND SECURITY
--- httpserv-config.bak 2013-07-16 05:29:25.593094537 +0200
+++ httpserv-config     2013-07-16 05:29:40.896935556 +0200
@@ -1,6 +1,6 @@
 # HTTP server listening port.
 # default: 8080
-server-port 8080
+server-port 8081
 
 # HTTP server host
 # default: localhost

Le changement du port est facultatif, moi j'ai juste Apache qui occupe déjà ce port, tout est relié au port 80 grace au reverse proxy Squid, mais à vous d'adapter selon votre serveur bien entendu. Petite mise en garde sur les chemins des répertoires dans le fichier config, des fois le / de fin n'est pas nécessaire et c'est indiqué en commentaire, des fois rien n'est indiqué mais il est vital au bon fonctionnement du service. Sinon ça donne dans /var/log/messages une erreur du genre:

Error: Cannot open template file /usr/share/seeksplugins/websearch/templates/themes/compact/seeks_ws_hp.html: No such file or directory

Le service est correctement configuré, nous pouvons donc le démarrer comme n'importe quel service systemd. Si Apache occupe déjà le port 80 de votre machine, vous pouvez configurer Apache en ajoutant dans un hôte virtuel la fonction ProxyPass afin de réacheminer les requêtes du port 80 vers le port 8080.

Voilà, j'espère vous avoir mis sur de bonnes pistes, les fichiers de confs sont très bien commentés et leur lecture est indispensable. Vous aurez sans doute remarqué dans la barre des menus de mon blog une nouvelle entrée, n'hésitez pas à en user et en abuser.

Le méta-moteur de recherche

Matthieu Saulnier

Tout le monde a déjà essayé au moins une fois de changer de moteur de recherche, sauf que voilà, celui que l'on cherche à fuir est vraiment partout, jusque dans la barre d'url de votre navigateur. Je parle de la barre d'url et non de la barre de recherche car désormais lorsque l'on a une recherche à faire on tape les mots clés directement dans cette barre, la barre de recherche étant souvent absente pour des raisons ergonomiques.

Quel moteur de recherche choisir, a-t-on le choix seulement entre la peste et le choléra ? Je serais tenté de répondre oui, c'est pourquoi je me suis penché vers le méta-moteur de recherche. Son rôle est de tout simplement lancer une recherche sur plein (une dizaine environ) de moteurs de recherche, et de trier les résultats par ordre de pertinence. Ainsi, les moteurs de recherche enregistrent une recherche venant du serveur hébergeant le méta-moteur, et les utilisateurs retrouvent tout naturellement leur anonymat et des résultats non-biaisés par un profil quelconque. Pour n'en citer qu'un, que nous prendrons comme exemple pour la suite de l'article: seeks.fr (prononcez « siiiix »).

Pour en revenir à notre barre d'url, voici comment en changer le moteur de recherche, sur le navigateur Firefox (les navigateur non-libres et backdooré du genre Chrome et I.E. sont volontairement ignorés).

  • Taper "about:config" dans la barre d'URL
  • Taper "keyword" dans la sous-barre « Rechercher: »
  • Double-cliquer sur la case contenant l'ancien moteur de recherche et y taper « http://seeks.fr/search?q= »

firefox-keyword.png

Et votre expérience utilisateur se voit métamorphosée...

Coté sysadmin, que des bonnes nouvelles, Seeks est un logiciel libre facilement installable sur serveur ou desktop Fedora grâce au RPM de WilQu, disponible ici. (Note: C'est un SRPM qu'il faut compiler en premier lieu). J'envisage sérieusement de monter un nœud seeks sur mon petit serveur... Les tests sont déjà en cours en machine virtuelle.

Git, GitHub et le social codding

Guillaume Kulakowski

A mon boulot, on fait depuis quelque temps des BarCamp de type first jeudi, à la différence que nous, on fait ça entre midi et deux.

J'ai donc eu le plaisir danimer un "Déjeuner autour de Git, GitHub et le social codding". Mes slides sous reveal.js sont disponibles ici.

Le but de cette présentation était de :

  • Présenter Git aux équipes qui n'utilisent pas Git. En effet, comme on utilise Indefero à l'agence, on a la possibilité d'avoir Git ou SVN.
  • Permettre aux équipes qui utilisent Git avec une approche SVN de s'ouvrir vers de nouveaux horizons.
  • Permettre aux équipes déjà évangélisées d'avancer dans leur utilisation de GIT.

Pour les illustrations ainsi que pour certain propos, je me suis inspiré de lexcellent eBook Pro Git sous licence Creative Commons Attribution Non Commercial Share Alike 3.0.

Git, GitHub et le social codding

Guillaume Kulakowski

A mon boulot, on fait depuis quelque temps des BarCamp de type first jeudi, à la différence que nous, on fait ça entre midi et deux.

J'ai donc eu le plaisir danimer un "Déjeuner autour de Git, GitHub et le social codding". Mes slides sous reveal.js sont disponibles ici.

Le but de cette présentation était de :

  • Présenter Git aux équipes qui n'utilisent pas Git. En effet, comme on utilise Indefero à l'agence, on a la possibilité d'avoir Git ou SVN.
  • Permettre aux équipes qui utilisent Git avec une approche SVN de s'ouvrir vers de nouveaux horizons.
  • Permettre aux équipes déjà évangélisées d'avancer dans leur utilisation de GIT.

Pour les illustrations ainsi que pour certain propos, je me suis inspiré de lexcellent eBook Pro Git sous licence Creative Commons Attribution Non Commercial Share Alike 3.0.

Encryption d'un volume physique LVM

Matthieu Saulnier

Applicable sur un périphérique de stockage de masse vide (sans partition) ou neuf, par exemple une clef USB emtec de 8Go ou un disque dur:

[root@blackbird ~]# fdisk -l /dev/sdb

Disque /dev/sdb : 8094 Mo, 8094744576 octets, 15810048 secteurs
Unités = secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Disk label type: dos
Identifiant de disque : 0x000b2458

Périphérique Amorce  Début        Fin      Blocs     Id  Système

La taille maximale du volume physique LVM sera donc de 8094Mo. Je crée donc une partition primaire qui va occuper toute la place et servir de support à la couche d'encryption.

[root@blackbird ~]# parted /dev/sdb mkpart primaire 1 8094
Information: Ne pas oublier de mettre à jour /etc/fstab si nécessaire.

[root@blackbird ~]# fdisk -l /dev/sdb                

Disque /dev/sdb : 8094 Mo, 8094744576 octets, 15810048 secteurs
Unités = secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Disk label type: dos
Identifiant de disque : 0x000b2458

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sdb1            2048    15808511     7903232   83  Linux

On voit que la partition non-formatée occupe 15808511-2048=15806463 secteurs sur les 15810048 secteurs disponibles, ce qui est correct. Puis initialisation d'un volume LUKS sur la partition, le contenu est chiffré avec la phrase-passe.

[root@blackbird ~]# cryptsetup luksFormat /dev/sdb1

WARNING!
========
Cette action écrasera définitivement les données sur /dev/sdb1.

Are you sure? (Type uppercase yes): YES
Saisissez la phrase secrète :
Verify passphrase:

À partir d'ici la première couche (l'encryption) vient d'être appliquée. C'est aussi à partir d'ici que l'on peut choisir entre créer un système de fichier sur le volume LUKS, et dans ce cas se retrouver avec le système obsolète des partitions primaires, ou bien ajouter la couche LVM, qui offre une multitude d'avantages.

[root@blackbird ~]# cryptsetup luksOpen /dev/sdb1 luks-sdb1
Saisissez la phrase secrète pour /dev/sdb1 :
[root@blackbird ~]# pvcreate /dev/mapper/luks-sdb1
  Physical volume "/dev/mapper/luks-sdb1" successfully created

Et c'est tout. Le volume physique LVM est vide et bien chiffré avec LUKS, en 10 minutes chrono.

Après, il suffit de créer sur le volume physique (PV) un groupe de volumes (VG) et d'y ajouter autant de volumes logiques (LV) que l'on souhaite.

[root@blackbird ~]# vgcreate emtec8 /dev/mapper/luks-sdb1
  Volume group "emtec8" successfully created
[root@blackbird ~]# lvcreate -L 1G -n metro emtec8                                                                                                                       
  Logical volume "metro" created
[root@blackbird ~]# lvcreate -L 1G -n boulot emtec8                                                                                                                      
  Logical volume "boulot" created
[root@blackbird ~]# lvcreate -L 2G -n dodo emtec8                                                                                                                        
  Logical volume "dodo" created
[root@blackbird ~]# lvcreate -L 1G -n lvbackup emtec8                                                                                                                    
  Logical volume "lvbackup" created
[root@blackbird ~]# lvcreate -L 2G -n lv01 emtec8                                                                                                                        
  Logical volume "lv01" created

Il faut savoir que lorsque que l'on sélectionne l'option "Chiffrer mon système" lors de l'installation de Fedora, c'est cette même procèdure qui est appliquée avec à la fin l'écriture du fstab pour le montage des LV au démarrage.

Pour contrôler le remplissage du VG:
[root@blackbird ~]# vgs emtec8
  VG     #PV #LV #SN Attr   VSize VFree 
  emtec8   1   5   0 wz--n- 7,53g 544,00m

Il reste encore 544Mo de libre... Ne pas oublier de formater chaque LV avec:

# mkfs.ext4 /dev/mapper/emtec8-boulot

Et il ne reste plus qu'à monter les LV pour pouvoir les remplir, tout en gardant à l'esprit que leur contenu ne sera lisible uniquement d'une seule personne: Vous.

Utilisation de yum shell pour migrer de php-mysql vers php-mysqlnd

Guillaume Kulakowski

Avec l'arrivée imminante de php 5.5, version qui verra disparaitre la librairie php-mysql, il est grand temps d'entamer une migration vers mysqlnd. Voici donc le mode opératoire pour effectuer ce changement en utilisant yum shell & le dépôt remi sur ma RHEL6.

Pourquoi yum shell ? Car il n'est pas possible de passer par un simple yum install :

root@kalach ~> yum install php-mysqlnd
Loaded plugins: changelog, downloadonly, presto, product-id, rhnplugin
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package php-mysqlnd.x86_64 0:5.4.14-1.el6.remi will be installed
--> Processing Conflict: php-mysql-5.4.14-1.el6.remi.x86_64 conflicts php-mysqlnd
--> Finished Dependency Resolution
Error: php-mysql conflicts with php-mysqlnd-5.4.14-1.el6.remi.x86_64
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

En effet php-mysqlnd et php-mysql rentrent en conflit...

Alors essayons de désinstaller php-mysql :

root@kalach ~> yum remove php-mysql
Loaded plugins: changelog, downloadonly, presto, product-id, rhnplugin
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package php-mysql.x86_64 0:5.4.14-1.el6.remi will be erased
--> Processing Dependency: php-mysql for package: php-pluf-1.0-3.gitb1fed2e.el6.remi.noarch
--> Processing Dependency: php-mysql for package: phpMyAdmin-3.5.8.1-1.el6.remi.noarch
--> Processing Dependency: php-mysql for package: cacti-0.8.8a-2.el6.noarch
--> Running transaction check
---> Package cacti.noarch 0:0.8.8a-2.el6 will be erased
---> Package php-pluf.noarch 0:1.0-3.gitb1fed2e.el6.remi will be erased
--> Processing Dependency: php-pluf >= 1.0-3 for package: indefero-1.3.3-1.el6.noarch
---> Package phpMyAdmin.noarch 0:3.5.8.1-1.el6.remi will be erased
--> Running transaction check
---> Package indefero.noarch 0:1.3.3-1.el6 will be erased
--> Finished Dependency Resolution
 
Dependencies Resolved
 
=======================================================================================================
 Package         Arch        Version                          Repository                          Size
=======================================================================================================
Removing:
 php-mysql       x86_64      5.4.14-1.el6.remi                @remi                              449 k
Removing for dependencies:
 cacti           noarch      0.8.8a-2.el6                     @epel                              5.4 M
 indefero        noarch      1.3.3-1.el6                      @/indefero-1.3.3-1.el6.noarch      3.4 M
 php-pluf        noarch      1.0-3.gitb1fed2e.el6.remi        @remi                              1.2 M
 phpMyAdmin      noarch      3.5.8.1-1.el6.remi               @remi                               22 M
 
Transaction Summary
=======================================================================================================
Remove        5 Package(s)
 
Installed size: 33 M
Is this ok [y/N]:

Trop de dépendances !

La solution : yum shell :

root@kalach ~> yum shell                                     13:37
Loaded plugins: changelog, downloadonly, presto, product-id, rhnplugin
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Yum Shell
> install php-mysqlnd
Setting up Install Process
> remove php-mysql
Setting up Remove Process
> run
--> Running transaction check
---> Package php-mysql.x86_64 0:5.4.14-1.el6.remi will be erased
---> Package php-mysqlnd.x86_64 0:5.4.14-1.el6.remi will be installed
--> Finished Dependency Resolution

================================================================================
 Package            Arch          Version                    Repository    Size
================================================================================
Installing:
 php-mysqlnd        x86_64        5.4.14-1.el6.remi          remi         260 k
Removing:
 php-mysql          x86_64        5.4.14-1.el6.remi          @remi        449 k

Transaction Summary
================================================================================
Install       1 Package(s)
Remove        1 Package(s)

Total download size: 260 k
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 260 k
php-mysqlnd-5.4.14-1.el6.remi.x86_64.rpm                 | 260 kB     00:00     
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : php-mysqlnd-5.4.14-1.el6.remi.x86_64                         1/2 
  Erasing    : php-mysql-5.4.14-1.el6.remi.x86_64                           2/2 
  Verifying  : php-mysqlnd-5.4.14-1.el6.remi.x86_64                                                                                                                                                         1/2 
  Verifying  : php-mysql-5.4.14-1.el6.remi.x86_64                                                                                                                                                           2/2 

Removed:
  php-mysql.x86_64 0:5.4.14-1.el6.remi                                                                                                                                                                          

Installed:
  php-mysqlnd.x86_64 0:5.4.14-1.el6.remi                                                                                                                                                                        

Finished Transaction
> exit
Leaving Shell

Et voila, bien sûr on peut utiliser yum shell pour d'autres opérations.

Transformer irssi en service systemd

Matthieu Saulnier Qui n'a jamais songé à lancer automatiquement au démarrage son client IRC ? Qui n'a jamais rêvé de lancer son client IRC en nCurses automatiquement au démarrage comme un simple service ? Il y a cependant une problèmatique de taille : Contrairement à un démon normal, les clients en nCurses produisent un output que l'on doit pouvoir récupérer plus tard. Donc de ce fait, il faut lancer le client dans une session détachée, avec l'aide de Tmux par exemple. Il y a aussi un autre problème, si ce n'est pas explicitement paramètré, le démon sera lancé sous l'utisateur root, mais il est hors de question de lancer notre client IRC sous root. Heureusement, systemd a déjà tout prévu pour changer l'utilisateur qui lancera le client. Mais ce n'est pas tout, il suffit d'écrire un fichier à peine plus long qu'un .desktop pour réaliser ce qui est décrit plus haut, une fois encore grace à la simplicité de systemd.

$ cat /lib/systemd/system/irssi.service
[Unit]
Description=Run IRSSI in a Tmux session for user 'casper'
After=NetworkManager.service syslog.target auditd.service
[Service]
Type=forking
User=casper
Group=casper
ExecStart=/usr/bin/tmux new-session -d irssi
[Install]
WantedBy=multi-user.target

Quelques adaptations seront nécéssaires de votre part, comme le nom d'utilisateur et son groupe, pour le reste je vous recommande d'essayer irssi dans un Tmux...
Avec les outils systemd, on retrouve dans le service IRSSI un comportement absolument identique à celui d'un démon tout à fait banal, voir ci-après.

# systemctl status irssi
irssi.service - Run IRSSI in a Tmux session for user 'casper'
 Loaded: loaded (/usr/lib/systemd/system/irssi.service; enabled)
 Active: inactive (dead) since Sun, 23 Dec 2012 22:51:33 +0100; 25s ago
Process: 23027 ExecStart=/usr/bin/tmux new-session -d irssi (code=exited, status=0/SUCCESS)
Main PID: 23029 (code=exited, status=0/SUCCESS)
 CGroup: name=systemd:/system/irssi.service

# systemctl start irssi
[ne renvoie pas d'output]

# systemctl status irssi
irssi.service - Run IRSSI in a Tmux session for user 'casper'
 Loaded: loaded (/usr/lib/systemd/system/irssi.service; enabled)
 Active: active (running) since Sun, 23 Dec 2012 22:53:32 +0100; 2min 37s ago
Process: 23939 ExecStart=/usr/bin/tmux new-session -d irssi (code=exited, status=0/SUCCESS)
Main PID: 23941 (tmux)
 CGroup: name=systemd:/system/irssi.service
 ├ 23941 /usr/bin/tmux new-session -d irssi
 └ 23942 irssi

$ tmux list-session
0: 1 windows (created Sun Dec 23 22:53:32 2012) [80x23]
Et enfin pour récupérer la session :
$ tmux attach -t 0

Voilà une combine indspensable pour ceux qui font tourner leur client IRC sur leur serveur. Bon hack et Joyeuses Fêtes à vous.

Powertop sur serveur

Matthieu Saulnier Amusante découverte du jour, Powertop peut écrire son rapport dans un fichier au format html. La page html statique apporte des informations complémentaires à Cacti mais sont plus d'ordre général, du coup je pense que le faire travailler dans un Cron hebdomadaire pourrait être intéressant. Attention il fournit toutefois des informations sensibles pour un serveur, il convient donc d'en restreindre l'accès. avec un htaccess dans le cas présent.

Dans la racine de votre site web, créer le répertoire /powertop/ 
cat /etc/cron.weekly/powertop.sh
#!/bin/bash
powertop --html=/var/www/dotclear1/powertop/index.html --time=600
La commande demande à powertop de générer son rapport sur 10 minutes d'enregistrement.
chmod +x /etc/cron.weekly/powertop.sh
Pas de nom d'utilisateur, pas de mot de passe, juste un libre accès pour mon IP Locale et un 403 pour tous les autres :
cat /var/www/dotclear1/powertop/.htaccess
AuthName "Powertop"
AuthType Basic
order deny,allow
deny from all
allow from 192.168.1.20
Notez que le "allow from xxx" n'est valide que sur Apache 2.2 et antérieur, et qu'il faudra utiliser dorénavant "require ip xxx" sur Apache 2.4 fournit avec Fedora 18.
Et voilà, j'ai accès à mon rapport Powertop à l'adresse http://casperlefantom.net/powertop

ownCloud : mon cloud à moi (Dropbox like & killer !)

Guillaume Kulakowski

Cela fait maintenant un certain temps que je me sers de Dropbox pour synchroniser les données de mes différents postes mais également pour pouvoir accéder à ces informations de partout. Bref pour mettre mes données dans les nuages.

Le problème de Dropbox c'est qu'une fois mes 10Go passés, la solution devient payante (normale me direz-vous c'est un service qu'on consomme il est normal de la payer). L'autre problème, plus grave, est que les données ne sont pas cryptées et c'est plutôt dérangeant lorsqu'un problème survient.

Donc j'ai un peu regardé ce qui s'offrait à moi comme Dropbox like et DropBox killer.

Les concurrents : Box, Drive, SkyDrive et Hubic

Box, Drive et SkyDrive ont des prix équivalents à DropBox. hubiC quant à lui offre plusieurs avantages :

J'ai un peu testé hubiC mais le client mal intégré à l'OS et les performances d'un montage WebDAV m'ont vite découragé.

Mon cloud à moi : ownCloud

Comme je possède un serveur, je me suis donc dit que je pouvais héberger mon cloud à moi :

  • SparkleShare : très prometteur, mais GIT est-il un moteur de stockage adéquate pour des fichiers binaires (MP3, photos, etc.) ? AMHA, la réponse est non !
  • Syncany : prometteur sur le papier, mais je ne bosse pas sur le papier ;-).

Bref, je me suis alors tourné vers OwnCloud qui est une sorte de DropBox mais hébergé chez soit :

  • Client Linux / Mac / Windows,
  • Interface web,
  • WebDAV,
  • Cryptage,
  • Versioning,
  • Partage,
  • etc.

Cependant, l'outil n'est pas encore exempte de problèmes. Par exemple, l'interface web est très lente, des améliorations devraient arriver avec la version 4.5 et un système de cron.

Loutil possède une feuille de route claire, la version 4.5 est actuellement en beta, les fonctionnalités à venir sont alléchantes :

Sortie d'Indefero 1.3.2 et disponibilité des RPMs

Guillaume Kulakowski

La forge Indefero, utilisée sur projects.llaumgui.com (entre autre, car on s'en sert également sur Fedora-Fr et à mon travail) est sortie hier en version 1.3.2.

L'occasion pour moi de mettre à jour les RPMs disponibles sur mon dépôts et également de rappeler la review Request au bon souvenir des approbateurs potentiels.

Pour mettre à jour votre forge, rien de plus simple :

  • Mise à jour du RPM :
yum --enablerepo=llaumgui update indefero
  • Mise à jour de la configuration (/etc/indefero/idf.php).
  • Mise à jour de la base :
root@stetson /usr/share/indefero> php /usr/share/php/pluf/migrate.php --conf=/etc/indefero/idf.php -a -d -u
PHP include path: .:/usr/share/pear:/usr/share/php:/usr/share/php/pluf
Migrate  to version latest
18 18DownloadMD5 up
19 19WikiPageAssocs up
20 20AddWikiResources up
21 21WikiPageRevisionName up
22 22ProjectTagRelationTable up
23 23ProjectActivity up
24 24CurrentProjectActivity up
  • Effacement du cache :
rm -f /tmp/Pluf_*

Voila.

Ma forge (projects.llaumgui.com) sous Indefero 1.3

Guillaume Kulakowski

Cela va faire bientôt une semaine que ma forge tourne sans problème sous Indefero 1.3. J'en ai également profité pour mettre à jour la forge au boulot, car nous avions atteint un nombre de projets critique et la nouvelle page d'accueil introduite avec la version 1.3 nous permet maintenant de retrouver rapidement nos projets en fonction des technologies, des clients, etc.

Malheureusement la 1.3 comportant quelques bugs (notamment pour les utilisateurs de PostgreSQL, et une dépendance à Pluf) j'ai bien mis à jour le SPEC, mais je n'ai pas encore releasé les RPMs sur mon dépôt et pense pour cela attendre la 1.3.1 qui ne devrait tarder.

CSSLint et Sniffer Zeta Components dans le dépôt llaumgui

Guillaume Kulakowski

En ce moment, professionnellement je travaille beaucoup avec Jenkins, qui nous permet de monter en qualité dans le code mais également en maintenabilité. J'en suis tellement fan que je suis entrain de me monter une plateforme d'intégration continue personnelle sur mon serveur (sujet d'un prochain billet à venir).

Comme il manque encore quelques outils en RPM, j'ai packagé CSSLint pour Fedora 14/15/16 et RHEL 5/6. Vous pouvez donc trouver cet utilitaire au sein du dépôt llaumgui, package pour lequel j'ai également ouvert une review request.

Au niveau des eZ Components que je package pour Fedora et EPEL, il manquait le standard pour php Code Sniffer. C'est chose faite avec l'arrivée de PHP_CodeSniffer_Standards_Zeta dans le dépôt llaumgui.