En ce mardi 3 novembre 2015, le projet Fedora est fier d’annoncer la sortie de la distribution GNU/Linux Fedora 23.

Comme à son habitude, le projet Fedora propose le dernier cru des environnements GNOME 3.18 mais aussi Sugar 0.106 à destination des enfants. Tout comme la sortie de Libreoffice 5, ces programmes améliorent la gestion des écrans à haute-densité de pixels (même en cas de multi-écran avec des densités différentes). L'intégration dans Wayland est également poursuivie.

Les fans de l'environnement de bureau Cinnamon pourront profiter d'un LiveCD officiel pour le tester et l'installer directement.

Cette version de Fedora s'est surtout concentrée sur quatre axes : gestion des paquets, sécurité, Python 3 et cloud computing.

Gestion des paquets

Tout d'abord d'un point de vue graphique, GNOME Logiciels gère mieux la bande passante disponible et peut effectuer les mises à niveau complètes de Fedora. GNOME Logiciels a même la capacité nouvelle de mettre à jour les firmwares UEFI des machine le permettant !

Du côté de la console, les précédentes solutions de mise à niveau comme fedup ou encore preupgrade sont abandonnées. À la place, le gestionnaire de paquets officiel dnf hérite de ce rôle via un plugin. Cela apporte une meilleure fiabilité du processus et une meilleure intégration au système (comme dans GNOME Logiciels par exemple). Utilisateur de Fedora 22 ? Vous pouvez d’or et déjà effectuer la procédure en suivant les instructions suivantes :

# dnf install dnf-plugin-system-upgrade
# dnf system-upgrade download --releasever=23
# dnf system-upgrade reboot

Sécurité

Fedora souhaite être une distribution à la pointe de la sécurité. Après les derniers scandales entourant l'usage des vieillissants algorithmes de sécurité RC4 et SSL3, le projet a retiré leur usage dans les programmes les y autorisant encore à l'exception notable des programmes issus de Mozilla, qui ont un calendrier de retrait différent.

Notons encore que les programmes de base ayant des critères d'acceptation de mots de passe voient leurs règles unifiées. Il est possible ainsi d'avoir un mot de passe unique pour anaconda (le programme d'installation), passwd ou encore gnome-control-center ! Changer la politique à l'un d'entre eux se répercute sur les autres, évitant de reproduire la procédure.

Cloud

Une version Cloud de Fedora, à savoir Fedora Atomic, suivra un calendrier de publication différent du reste du projet de Fedora. Plutôt que de sortir tous les 6 mois en moyenne, cela se fera toutes les deux semaines ! L'objectif est de faire avancer le projet rapidement pour satisfaire les besoins des développeurs et des utilisateurs. Un tel changement implique une profonde refonte de la l'assurance qualité mais aussi du site web pour respecter ce rythme effréné. Ce nouveau cycle sera en place très prochainement.

Python 3

Python a effectué il y a 7 ans un changement majeur de son langage de programmation, un changement tel que la compatibilité a été rompue avec la branche précédente. Afin d'accélérer la transition, qui doit être faite avant 2020 d'après les développeurs de Python, Fedora 23 incorpore les aspects suivants :

• Python 3 est installé par défaut et est la seule version disponible dans les fichiers permettant l'installation de Fedora (à savoir les LiveCD notamment mais aussi les images Atomic ou DVD) ;
• Python 2 reste disponible dans les dépôts ;
• Pour les paquets fonctionnels avec les deux versions, Python 3 est désignée comme la version de référence ;
• /usr/bin/python pour les utilisateurs et développeurs restera Python 2, afin de respecter les recommandations du projet Python.

Et bien entendu d'autres nouveautés sont à découvrir. Vous pourrez profiter d'un article en français plus complet. N'hésitez pas à profiter de cette dernière monture et à en effectuer des retours.

Liens

• Site de la communauté francophone de Fedora
• Site officiel du Projet Fedora
• Notes de version officielles de Fedora 23
• Liste de torrents officiels pour télécharger Fedora 23 et dérivées

Original post of Renault.Votez pour ce billet sur Planet Libre.

Il y a quelques jours, j’ai eu la bonne surprise de voir ma demande a la beta de Let’s Encrypt être acceptée. A moi l’argent, la gloire et la crypto !

Pour rappel, letsencrypt est une autorité de certification (CA) qui ne demande aucune validation humaine de leur part. Pas d’envoie de papiers d’identité ou autre preuves. Pour prouver que vous etes bien possesseur du domaine, il suffit que, lors de la génération du certificat, vous placiez un fichier json accessible a une url « mondomaine.com/.well-known/… ».

La procédure de génération est donnée (et risque d’évoluer d’ici la fin de la beta) mais en résumé:

Make sure your web server displays the following content at                                                                                           
http://mart-e.be/.well-known/acme-challenge/abcdef... before continuing:

{"header": ...}

Content-Type header MUST be set to application/jose+json.

If you don't have HTTP server configured, you can run the following
command on the target server (as root):

mkdir -p /tmp/letsencrypt/public_html/.well-known/acme-challenge
cd /tmp/letsencrypt/public_html
echo -n '{"header": ...}' > .well-known/acme-challenge/abcdef...
# run only once per server:
$(command -v python2 || command -v python2.7 || command -v python2.6) -c \\
"import BaseHTTPServer, SimpleHTTPServer; \\
SimpleHTTPServer.SimpleHTTPRequestHandler.extensions_map = {'': 'application/jose+json'}; \\
s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \\
s.serve_forever()"
Press ENTER to continue

Super, seulement wordpress ne me laisse pas créer des dossiers arbitraires dans mon dossier contenant le code (et c’est une bonne nouvelle en soit). Pour résoudre cela, un petit bricolage nginx s’imposait.

HTTPS sur un blog, c’est comme un éléphant-mitrailleuse. Ça ne sert pas a grand chose mais c’est cool!

Mise à jour: Michel propose une solution plus simple sans s’ennuyer avec un serveur local en python!

server {
       listen 80;
       server_name mart-e.be;
       location ~ /.well-known {
            proxy_pass  http://127.0.0.1:7890;
       }
       
       # reste de la config pour wordpress
}

Où 7890 est un numero de port totalement arbitraire.
Ensuite, suivant +/- les conseils du wizard de letsencrypt

$ mkdir -p /tmp/letsencrypt/public_html/.well-known/acme-challenge
$ cd /tmp/letsencrypt/public_html
$ echo -n '{"header":...}  > .well-known/acme-challenge/abcdef...
$ python -c "import BaseHTTPServer, SimpleHTTPServer; SimpleHTTPServer.SimpleHTTPRequestHandler.extensions_map = {'': 'application/jose+json'}; s = BaseHTTPServer.HTTPServer(('', 7890), SimpleHTTPServer.SimpleHTTPRequestHandler); s.serve_forever()"

Notez que j’ai changé le numéro de port de 80 a 7890 dans les paramètres de HTTPServer.

On relance NGINX (nginx -s reload), continue l’exécution du wizard (press ENTER) et victoire !

Press ENTER to continue

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/mart-e.be/fullchain.pem. Your cert will
   expire on 2016-01-26. To obtain a new version of the certificate in
   the future, simply run Let's Encrypt again.

Vous pouvez tuer la commande python une fois validé et retirer la config nginx (ou commentez, le certificat beta ne vaut que 90 jours).

En bonus, la config nginx qui va bien:

ssl_certificate /etc/letsencrypt/live/mart-e.be/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mart-e.be/privkey.pem;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
ssl_protocols TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparams.pem;

Avec le fichier dhparams.pem servant à la génération d’une clef diffie-helman, via la commande openssl dhparam -out dhparam.pem 2048

Mozilla a un super générateur de config. J’ai prit la config moderne, désolé utilisateurs de vieux soft, je décroche ainsi un beau A sur le CryptCheck un peu nazi de Aeris !

Vous pouvez maintenant accéder a mart-e.be en https !

Original post of Martin T..Votez pour ce billet sur Planet Libre.

Il y a quelques jours, j’ai eu la bonne surprise de voir ma demande a la beta de Let’s Encrypt être acceptée. A moi l’argent, la gloire et la crypto !

Pour rappel, letsencrypt est une autorité de certification (CA) qui ne demande aucune validation humaine de leur part. Pas d’envoie de papiers d’identité ou autre preuves. Pour prouver que vous etes bien possesseur du domaine, il suffit que, lors de la génération du certificat, vous placiez un fichier json accessible a une url « mondomaine.com/.well-known/… ».

La procédure de génération est donnée (et risque d’évoluer d’ici la fin de la beta) mais en résumé:

Make sure your web server displays the following content at                                                                                           
http://mart-e.be/.well-known/acme-challenge/abcdef... before continuing:

{"header": ...}

Content-Type header MUST be set to application/jose+json.

If you don't have HTTP server configured, you can run the following
command on the target server (as root):

mkdir -p /tmp/letsencrypt/public_html/.well-known/acme-challenge
cd /tmp/letsencrypt/public_html
echo -n '{"header": ...}' > .well-known/acme-challenge/abcdef...
# run only once per server:
$(command -v python2 || command -v python2.7 || command -v python2.6) -c \\
"import BaseHTTPServer, SimpleHTTPServer; \\
SimpleHTTPServer.SimpleHTTPRequestHandler.extensions_map = {'': 'application/jose+json'}; \\
s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \\
s.serve_forever()"
Press ENTER to continue

Super, seulement wordpress ne me laisse pas créer des dossiers arbitraires dans mon dossier contenant le code (et c’est une bonne nouvelle en soit). Pour résoudre cela, un petit bricolage nginx s’imposait.

HTTPS sur un blog, c’est comme un éléphant-mitrailleuse. Ça ne sert pas a grand chose mais c’est cool!

server {
       listen 80;
       server_name mart-e.be;
       location ~ /.well-known {
            proxy_pass  http://127.0.0.1:7890;
       }
       
       # reste de la config pour wordpress
}

Où 7890 est un numero de port totalement arbitraire.
Ensuite, suivant +/- les conseils du wizard de letsencrypt

$ mkdir -p /tmp/letsencrypt/public_html/.well-known/acme-challenge
$ cd /tmp/letsencrypt/public_html
$ echo -n '{"header":...}  > .well-known/acme-challenge/abcdef...
$ python -c "import BaseHTTPServer, SimpleHTTPServer; SimpleHTTPServer.SimpleHTTPRequestHandler.extensions_map = {'': 'application/jose+json'}; s = BaseHTTPServer.HTTPServer(('', 7890), SimpleHTTPServer.SimpleHTTPRequestHandler); s.serve_forever()"

Notez que j’ai changé le numéro de port de 80 a 7890 dans les paramètres de HTTPServer.

On relance NGINX (nginx -s reload), continue l’exécution du wizard (press ENTER) et victoire !

Press ENTER to continue

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/mart-e.be/fullchain.pem. Your cert will
   expire on 2016-01-26. To obtain a new version of the certificate in
   the future, simply run Let's Encrypt again.

Vous pouvez tuer la commande python une fois validé et retirer la config nginx (ou commentez, le certificat beta ne vaut que 90 jours).

En bonus, la config nginx qui va bien:

ssl_certificate /etc/letsencrypt/live/mart-e.be/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mart-e.be/privkey.pem;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
ssl_protocols TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparams.pem;

Avec le fichier dhparams.pem servant à la génération d’une clef diffie-helman, via la commande openssl dhparam -out dhparam.pem 2048

Mozilla a un super générateur de config. J’ai prit la config moderne, désolé utilisateurs de vieux soft, je décroche ainsi un beau A sur le CryptCheck un peu nazi de Aeris !

Vous pouvez maintenant accéder a mart-e.be en https !

Original post of Martin T..Votez pour ce billet sur Planet Libre.

Créer un environnement de construction de paquets Debian

Dans ce billet nous verrons comment créer un environnement sécurisé pour gérer ou construire des paquets Debian sans interférer sur le système installé car les paquets en dépendances nécessaires pour le développement du programme ne seront pas installés sur notre os mais dans un système de chroot afin d'isoler les procédures.

Dans un autre billet nous verrons comment obtenir un paquet Debian de A à Z depuis les sources originales en amont. Ces deux billets ne prétendent pas traiter le problème de la construction de paquets dans sa totalité, pour cela se référer au handbook Debian in extenso, mais plutôt à des débutants motivés susceptibles de créer des paquets pour leur usage personnel ou pour pour une distribution en petit comité, dans un groupe de confiance. Ne sera pas abordée non plus la signature des paquets.

Pour créer notre environnement de gestion nous allons utiliser pbuilder qui, comme dit plus haut, va créer un chroot dans lequel sera installée une autre distribution Debian, indépendante de celle utilisée, qui peut être d'une autre version, Stable, Testing, Sid, totalement indépendante de la version hôte, voire une Ubuntu sur un hôte Debian ou l'inverse. Bénéfice donc, le paquet créé sera indépendant de l'os utilisé et pourra ainsi aussi être installé sur une autre machine.

Installation de l'environnement :

:~# aptitude install pbuilder dh-make debootstrap devscripts unp

Dans cet exemple j'utilise une Debian GNU/Linux 8.2 (jessie) et je veux fabriquer un paquet pour fonctionner sur une Sid amd64. Je vais donc fabriquer un chroot que je pourrai utiliser à nouveau dans les mêmes circonstances.

:~# pbuilder --create   \\
    --distribution sid  \\
    --architecture amd64 \\
    --basetgz /var/cache/pbuilder/sid-amd64-base.tgz

Explications des options de construction :
--distribution Ici je demande la version Sid mais j'aurais pu construire une Jessie, une Stretch, une Ubuntu Quantal, vivid, etc. Comme pbuilder utilise debootstrap on peut voir la liste des constructions possibles dans /usr/share/debootstrap/scripts en sachant tout de même que suivant le choix il faudra ajouter d'autres options comme les adresses des miroirs et autres variantes. À noter qu'avec pbuilder on peut aussi utiliser experimental.

--architecture Il est demandé amd64 mais ce pourrait être aussi i386

--basetgz On peut créer plusieurs chroots indépendants les uns des autres, il est donc bon de leur donner un nom explicite. Dans le cas contraire le chroot compressé sera placé dans /var/cache/pbuilder/base.tgz

Le fichier de configurations principal de pbuilder est dans /usr/share/pbuilder/pbuilderrc. Il existe un autre fichier de configuration dans /etc/pbuilderrc qu'il est préférable d'utiliser pour modifier la configuration principale, ou bien créer un pbuilderrc dans son /home. Il ne sera pas modifié lors des mises à jour.
En ce qui me concerne comme modifications génériques j'y ai ajouté l'adresse des miroirs dans la ligne MIRRORSITE et "main contrib non-free" dans COMPONENTS.

Après lancement de la procédure elle se termine par :
I: creating base tarball [/var/cache/pbuilder/sid-amd64-base.tgz]
I: cleaning the build env

Voilà, nous avons uns Debian Sid contenant le minimum nécessaire de 257 Mo compressé.

Nous verrons plus tard comment créer un nouveau paquet Debian mais là, pour tester pbuilder nous allons utiliser les sources Debian pour avoir le deb du programme axe, un simple éditeur. Comme on peut le vérifier par aptitude -s build-dep axe si nous devions créer ce paquet sur notre système principal il faudra ajouter plus de 20 paquets afin de satisfaire les dépendances de création. D'où l'intérêt de le faire dans le chroot car pbuilder appellera les dépendances nécessaires puis, une fois le paquet créé, nettoiera le chroot en supprimant ces paquets pour le conserver dans son état d'origine.

Après avoir récupéré l'adresse du fichier dsc sur https://packages.debian.org/sid/axe on le télécharge car c'est ce fichier qui donnera à pbuilder tous les renseignements nécessaires pour construire le deb :

$ dget -d http://http.debian.net/debian/pool/non-free/a/axe/axe_6.1.2-16.2.dsc

et j'aurai ensuite mon fichier et les signatures vérifiées automatiquement :

axe_6.1.2-16.2.dsc:
      Good signature found
   validating axe_6.1.2.orig.tar.gz
   validating axe_6.1.2-16.2.diff.gz
All files validated successfully.

$ ls -1
axe_6.1.2-16.2.diff.gz
axe_6.1.2-16.2.dsc
axe_6.1.2.orig.tar.gz

On peut maintenant construire (build) le paquet en précisant - mais ce n'est pas toujours nécessaire - la distribution et l'architecture, l'adresse de la base.tgz puisqu'elle est spécifique ainsi que l'adresse où trouver le fichier .dsc.

sudo pbuilder --build  \\
--distribution sid     \\
--architecture amd64   \\
--basetgz  /var/cache/pbuilder/sid-amd64-base.tgz \\
~/axe/axe_6.1.2-16.2.dsc

Voilà, dans le dossier result on trouve ensuite le deb construit ainsi que les diverses parties propres à un paquet Debian, les sources donc, le changes, le diff, le dsc, fichiers que nous aurons l'occasion d'étudier lors de la création de notre premier paquet.

$ ls -1 /var/cache/pbuilder/result/
axe_6.1.2-16.2_amd64.changes
axe_6.1.2-16.2_amd64.deb
axe_6.1.2-16.2.diff.gz
axe_6.1.2-16.2.dsc
axe_6.1.2.orig.tar.gz

On peut maintenant vérifier la qualité de construction de notre deb avec lintian :

$ lintian /var/cache/pbuilder/result/axe_6.1.2-16.2_amd64.deb

E: axe: info-document-missing-dir-section usr/share/info/axe.info.gz

Il y a une Erreur. En effet sur aXe le mainteneur a omis de renseigner le dir, ce qui d'ailleurs a fait l'objet d'une déclaration de bug, mais le paquet est opérationnel :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528866

Pour faire la mise à jour d'un chroot avec pbuilder on utilise la commande pbuilder --update mais dans notre cas puisqu'on a précisé le nom de la base.tgz il faudra la renseigner par la commande :

:~$ sudo pbuilder --update --basetgz /var/cache/pbuilder/sid-amd64-base.tgz

À suivre.

Original post of Cyrille BORNE.Votez pour ce billet sur Planet Libre.

Original post of genma.Votez pour ce billet sur Planet Libre.