PROJET AUTOBLOG


Planet-Libre

source: Planet-Libre

⇐ retour index

Renault : Journée de test de Fedora 24 sur liveusb-creator

mardi 19 avril 2016 à 00:01

Aujourd'hui, ce mardi 19 avril, est une journée dédiée à un test sur une "nouveauté de Fedora 24, liveusb-creator. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants afin de remonter un maximum de problèmes sur le sujet.

Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

Capture_du_2016-04-18_23-41-52.png

Qu'est-ce que le liveusb-creator ?

Liveusb-creator permet de créer des images USB de Fedora pour l'essayer puis l'installer. Ce programme n'est pas nouveau, mais cette fois il sera largement mis en avant par le projet pour effectuer l'installation de Fedora. En effet, la procédure actuelle est centrée autour des images ISOs pour ensuite graver le résultat sur un CD ou DVD. La procédure est complexe, en plusieurs étapes et pénible car il requiert un DVD gravable sous la main.

Ici Liveusb-creator s'occupera de tout, télécharger l'image et l'installer sur la clé USB dans une interface simple. En plus, Liveusb-creator sera également disponible sous Windows et Mac OS X.

Typiquement les tests du jour couvrent :

La version pour Mac OS X n'est aps encore prête pour le moment.

Comment y participer ?

Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.

En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

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

Articles similaires

Raphaël Hertzog : Debian 8 Jessie publié chez Eyrolles

lundi 18 avril 2016 à 20:47

Ca y est, une nouvelle édition de mon Cahier de l’Admin Debian vient de paraître aux éditions Eyrolles… couvrant cette fois-ci Debian 8 Jessie et quittant la collection « Cahier de l’Admin » pour intégrer la « Collection Blanche » des livres de référence.

Couverture Debian 8 Jessie

Le livre est disponible chez tous les bons libraires et sa version électronique est toujours disponible gratuitement sur le site officiel du livre. Rappelons que le livre est publié sous licence libre (au choix CC-BY-SA 3.0 ou GPL 2+) et qu’il est co-écrit par deux développeurs Debian (moi même et Roland Mas).

Aucun commentaire pour le moment | Vous avez aimé ? Cliquez ici. | Ce blog utilise Flattr.

Gravatar de Raphaël Hertzog
Original post of Raphaël Hertzog.Votez pour ce billet sur Planet Libre.

Articles similaires

Raphaël Hertzog : Mes activités libres en février et mars 2016

lundi 18 avril 2016 à 10:25

Mon rapport mensuel couvre une grande partie de mes contributions au logiciel libre. Je l’écris pour mes donateurs (merci à eux !) mais aussi pour la communauté Debian au sens large parce que cela peut donner des idées aux nouveaux venus et que c’est également un des moyens les plus effectifs de trouver des volontaires pour travailler sur les projets qui me tiennent à cœur.

J’ai fait l’impasse sur le rapport mensuel de mes activités du mois de février, celui-ci couvrira donc les mois de février et mars. Pour ne pas faire trop long, je vais tâcher de ne lister que les points les plus importants :-).

Cahiers de l’Admin Debian

J’ai travaillé avec Ryuunosuke Ayanokouzi à la préparation d’une version papier de la traduction japonaise de mon livre. Grâce aux efforts de chacun, il est maintenant disponible. Lulu a malheureusement décliné sa prise en charge dans le programme « distribution »; il ne sera donc pas disponible dans les librairies « habituelles » (telles qu’Amazon). La raison étant qu’ils ne supportent pas les ensembles de caractères non-latin dans les métadonnées.

J’ai essayé de feinter le système en entrant la description en anglais (tout en expliquant que le livre était écrit en japonais), mais ils l’ont quand même refusé, arguant que le titre en anglais pouvait induire les gens en erreur. lulu.com est donc la seule option pour se procurer le livre. Les frais de ports restent heureusement raisonnables, en choisissant l’option la plus économique.

A la suite de quoi j’ai enjoint les traducteurs espagnols, brésiliens, italiens et portugais à finir leurs traductions, afin que nous puissions publier des versions papier pour ces langues également. Ils étaient déjà proches du but, toutes les chaînes de caractères étant traduites. Manquaient principalement la localisation des captures d’écran et quelques contenus des première et quatrième de couverture. On y est presque maintenant, j’espère que cela sera fini le mois prochain.

Distro Tracker

Début févier j’ai modifié la configuration, de sorte que les exceptions générées par les emails entrants et les tâches de routine soient maintenant envoyées par email. Elles étaient auparavant simplement enregistrées, mais sans que je prenne le temps de les analyser. Cela a rapidement mis en lumière plusieurs problèmes, que j’ai corrigés au fur et à mesure de leurs apparitions. Par exemple, la gestion des rebonds était défaillante lorsque la casse n’était pas respectée, et il est apparu que certains emails nous revenaient après avoir été passés en minuscule. Le code de contrôle des emails entrants était également défaillant lorsque le champ « References » utilisait plus d’une ligne.

Cela a également fait apparaître tout un ensemble de problèmes liés à la base de données stockant deux fois le même email avec des casses différentes. J’ai du effectuer un nettoyage de la base pour rassembler toutes les entrées en doublon derrière un seul email.

Plus tard les fichiers Source expérimentaux ont changé, ce qui m’a amené à modifier le code pour gérer la suppression du champ « Files » (en me basant à la place sur Checksums-* pour trouver les divers fichiers liés à l’entrée concernée).

J’ai également corrigé le formulaire de connexion, afin qu’il ne génère pas d’exception lorsque l’utilisateur soumet un formulaire vide.

De plus, j’ai décidé de ne plus supporter Django 1.7 dans distro tracker, car Django 1.8 est la version long-terme supportée. J’ai demandé aux administrateurs système Debian de mettre à jour le paquet sur tracker.debian.org avec la version disponible dans jessie-backports. Cela m’a permis de me débarrasser des avertissements qui étaient déclenchés par le code Django 1.7.

Un de ces avertissements était généré par django-jsonfield, et je n’ai pas pu le corriger immédiatement. J’ai préparé à la place une demande de pull que j’ai soumise à l’auteur amont.

Dernière chose : j’ai modifié la feuille CSS pour densifier la mise en page de la page présentant le paquet. C’était l’une des évolutions les plus demandées par les personnes préférant encore packages.qa.debian.org à tracker.debian.org.

Kali et la nouvelle équipe pkg-security

Parmi les différentes tâches effectuées pour Kali, je corrige les bogues critiques pour la publication affectant les paquets Debian que nous utilisons dans Kali. Mais dans la plupart des cas, je suis confronté à des paquets dont les mainteneurs sont aux abonnés absents (MIA, missing in action). Jusqu’à présent, nous n’effectuions que des uploads en tant que non-mainteneur (NMU, non-maintainer upload), mais je souhaite pouvoir maintenir ces paquets de manière plus efficace. C’est pourquoi nous avons créé l’équipe pkg-security . Nous ne sommes que deux à l’heure actuelle, et n’avons aucune documentation disponible. Mais vous êtes les bienvenus si vous souhaitez participer, tout particulièrement si vous maintenez un paquet utilisé dans le domaine de la sécurité.

Travaux liés à l’architecture arm64 Les trois premiers paquets que nous avons pris en charge (ssldump, sucrack, xprobe) ne disposaient pas de binaires compilés pour arm64. Nous venons juste de lancer notre portage Kali sur arm64, et nous avons donc corrigé cela pour cette architecture. Dans la mesure où ces paquets n’étaient plus maintenus correctement, la correction s’est résumée à l’utilisation de dh_autoreconf afin d’obtenir des fichiers config.{sub,guess} à jour.

Quelques paquets sont encore manquants sur arm64 : vboot-utils (que nous récupèrerons très certainement bientôt, puisqu’il est proposé à l’adoption), ruby-libv8 et ruby-therubyracer, ntopng (nous devons attendre le nouveau luajit, qui n’est présent que dans experimental pour l’instant). Nous avons également constaté que dh-make-golang n’était pas disponible pour arm64 et, après quelques discussions sur #debian-buildd, j’ai créé deux rapports de bogue : le n°819472 concernant dh-make-golang et le n°819473 concernant dh-golang.

Corrections de bogues critiques pour la publication De multiples bogues critiques pour la publication affectaient hdparm, et les responsables de la publication ont essayé de le retirer de testing. Ce qui a provoqué le retrait de nombreux paquets utilisés par Kali et ses utilisateurs. J’ai donc analysé la situation dans laquelle se trouvait ce paquet, convaincu les mainteneurs actuels de le déclarer orphelin, ai lancé un appel à de nouveaux mainteneurs sur debian-devel, passé en revue des mises à jours préparées par les volontaires et parrainé leurs travaux. hdparm est maintenant de nouveau exempt de bogues critiques, et au niveau de la dernière version amont. Nous avons également mis à jour jsonpickle vers la version 0.9.3-1 pour corriger le bogue critique n°812114 (que j’avais en premier lieu rapporté à l’auteur).

Support de préréglages Systemd dans init-system-helpers J’ai essayé de trouver quelqu’un pour implémenter (moyennant rémunération) la fonctionnalité de préréglages système que j’avais demandée dans le n°772555, sans y parvenir. Andreas Henriksson a eu l’amabilité de s’y essayer et d’envoyer un premier patch. Je l’ai essayé et trouvé quelques erreurs. Je l’ai donc amélioré et continué à le simplifier… J’ai soumis une mise à jour du patch et fais signe à Martin Pitt. Il m’a renvoyé vers les erreurs que mon patch créait dans la suite de tests DEP-8, que j’ai rapidement corrigés après coup. Ce patch est utilisé dans Kali et nous permet de désactiver les services réseaux par défaut. Je souhaiterais le voir intégrer dans Debian, de sorte que tout-un-chacun puisse configurer de tels préréglages systemd, et qu’ils soient respectés au moment de l’installation.

Rapports de bogues divers J’ai créé le rapport n°813801 pour demander une nouvelle version amont de kismet. De même que pour masscan dans le n°816644 et wkhtmltopdf dans le n°816714. Nous avons empaqueté (avant Debian) une nouvelle version amont de ruby-msgpack, et nous sommes aperçus que la compilation échouait pour armel/armhf. En conséquence de quoi nous avons créé deux tickets amont (avec une proposition de correction). Dans le n°814805, nous avons demandé au mainteneur de pyscard de réintégrer python-pyscard. Seule la version Python3 avait été conservée, la version python2 ayant été abandonnée. C’est pourtant cette dernière que nous utilisons dans Kali.

Et ce n’est pas fini : j’ai créé les rapports n°816553 (erreur de segmentation) et n°816554 concernant cdebootstrap. J’ai demandé que dh-python voit son comportement amélioré, après avoir été induit en erreur par le résultat de « dh –with python3 », qui n’avait pas fait ce que j’attendais (cf. le n°818175). J’ai également rapporté le n°818907 concernant live-build, qui ne gère pas les paquets dont le nom comporte une majuscule (ce qui est effectivement contraire à la règle, mais que dpkg supporte toutefois).

Empaquetages divers

J’ai poussé Django 1.9.2 vers unstable et 1.8.9 vers jessie-backports. J’ai fourni les informations supplémentaires qui m’avaient été demandées par Julien Cristau dans le rapport de bogue n°807654 mais, malgré cela, cette version a été ignorée pour la deuxième mise à jour de Jessie consécutive. Elle est maintenant obsolète jusqu’à ce que j’incorpore les correctifs de sécurité qui ont été publiés entretemps, mais je ne suis pas sûr de le faire…le manque de coopération dont fait preuve l’équipe responsable de la publication pour ce type de requête est décourageant.

J’ai parrainé plusieurs uploads de dolibarr (concernant des mises à jour de sécurité notablement) et tcpdf (correction d’un bogue critique pour la publication).

Merci

Rendez-vous au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Free Software Activities in February and March 2016 contribuée par Weierstrass01.

Aucun commentaire pour le moment | Vous avez aimé ? Cliquez ici. | Ce blog utilise Flattr.

Gravatar de Raphaël Hertzog
Original post of Raphaël Hertzog.Votez pour ce billet sur Planet Libre.

Articles similaires

Monitoring-FR : Ne dites plus « ELK » mais « The Elastic Stack »

lundi 18 avril 2016 à 09:20

Il y a quelques temps déjà, nous vous avions présenté ce qu’on appelle « la pile ELK », dans un article dont le titre est « ELK : Trio de charme ElasticSearch, Logstash & Kibana ». Aujourd’hui, cette pile ELK n’existe plus! Elle a évolué pour devenir « Elastic Stack ». Analysons ce changement au travers des dernières nouveautés annoncées par les développeurs d’Elastic Stack.

Petits rappels

ELK signifie ElasticSearch, Logstash et Kibana. Il s’agit de coupler les 3 logiciels pour obtenir une solution d’analyse de log performante et complète. Les outils sont:

Ces outils libres sont développés par la même structure, la société Elastic, qui encadre le développement communautaire et propose des services complémentaires (support, formation, intégration et hébergement cloud).

« ELK », jusqu’à il y a peu, n’avait un sens qu’uniquement parce que ces outils s’associent parfaitement et l’on parlait de « pile ELK » par commodité : en réalité, il n’y avait pas de « produit ELK ».

Un(?) nouveau venu

Pour répondre à de nouveaux besoins, un (un seul?) nouvel outil développé par Elastic est apparu : Beats. Beats regroupe en fait plusieurs outils différents :

Les outils se marient parfaitement avec « la pile ELK » : les données collectées par Beats sont stockées dans ElasticSearch, peuvent être enrichies par LogStash et sont visualisées par Kibana. Ils méritent d’être liés à « la pile ELK ».

Un renommage d’abord pragmatique…

Un problème apparaît : ELK est déjà trop connoté et peu pensent à Beats lorsqu’ils parlent de « ELK » ou de « pile ELK ». Beats pourrait pâtir de ce point. Quelques questions se posent :

Non, il fallait trouver autre chose. Un nouveau nom pouvant intégrer tous les outils actuels et les prochains aussi. Et le nom de « The Elastic Stack » fut choisi.

… mais d’un véritable intérêt stratégique

« The Elastic Stack » sonne plutôt bien et à l’avantage de rappeler à la fois la base (ElasticSearch) mais aussi l’entreprise (Elastic) et indique qu’il s’agit d’une composition d’outils (le terme Stack). Le nom décrit parfaitement le produit tout en ouvrant la possibilité d’intégrer de futurs produits à cette stack.

Un autre intérêt stratégique est lié à ce changement de nom. Lorsqu’on compose des outils pour en faire une solution complète, un problème apparaît : la gestion des numéros de version et des incompatibilités entre les composants de cette sollution. Aujourd’hui, si l’on prend la « pile ELKB/BELK », nous avons :

Comment s’assurer que tous les produits sont compatibles entre-eux? D’un point de vue technique, c’est compliqué : il faut gérer une matrice de compatibilité qui doit être fournie par l’éditeur. L’éditeur doit faire des tests en faisant varier les versions de chaque composant. Les mises à jour doivent être bien documentées pour éviter qu’un utilisateur perde des données. La matrice de compatibilité doit être claire et compréhensible, sans erreur d’interprétation possible.

D’un point de vue marketing, c’est compliqué aussi! Toute la communication doit aussi être mise en œuvre pour que les utilisateurs et les clients suivent (correctement!) la matrice de compatibilité. Lorsqu’un client ou un utilisateur mettra à jour un composant qui sera incompatible avec tous les autres, c’est l’image des développeurs et de l’entreprise qui va en pâtir par les retours sur les forums utilisateurs, les articles de blog négatifs, les présentations lors des événements communautaires (salons, forums) et les bugs ouverts. Et ces retours négatifs risquent d’être très nombreux : les outils sont jeunes et évoluent très vite et le succès est grandissant.

D’où l’idée d’Elastic de coordonner les numéros de version : désormais il y aura un produit « The Elastic Stack » dans une version donnée et intégrant tous les outils, chaque outil ayant la même version majeure. La première version de « The Elastic Stack » sera la prochaine version, la version 5.0.0 et intégrera tous les produits dans la version 5.0.0. Ce qui sera plus simple pour tout le monde : clients, utilisateurs mais aussi développeurs et ingénieurs support d’Elastic!

Refonte graphique

Pour communiquer plus efficacement sur « The Elastic stack », la charte graphique des outils a été refondue lentement. Dorénavant, il y a une unicité graphique entre les outils concernant les logos :

nouveaux logos : the elastic stack

Auparavant, les logos pouvaient être très différents :

anciens logos : ELK

Première version disponible

La première version alpha de « The Elastic Stack » est disponible en version 5.0.0 alpha 1. Bienvenu à « The Elastic Stack » et merci à « la pile ELK » pour les services rendus.

Gravatar de Monitoring-FR
Original post of Monitoring-FR.Votez pour ce billet sur Planet Libre.

Thuban : Installer un nouveau logiciel sur OpenBSD

lundi 18 avril 2016 à 08:53
OpenBSD dispose de nombreux paquets, tous vérifiés et donc sécurisés.

Pour installer un paquet, on doit utiliser la commande "pkg_add". Par exemple, pour installer firefox :

# pkg_add ftp://ftp.fr.openbsd.org/pub/OpenBSD/5.9/packages/amd64/firefox


Avouez que ce n'est pas pratique de taper tout ça. On peut se simplifier la vie une bonne fois pour toute. Dans le fichier ~/.profile, ajoutez la ligne suivante :

export PKG_PATH=ftp://your.ftp.mirror/pub/OpenBSD/5.9/packages/`machine -a`/


Ou alors, on peut mettre la ligne suivante dans le fichier /etc/pkg.conf (merci fred):

installpath = http://ftp.fr.openbsd.org/pub/OpenBSD/%v/packages/%a


Maintenant, il suffit de lancer :

# pkg_add firefox


Et c'est tout, il saura trouver le paquet tout seul

Chercher et trouver un paquet
Vous pouvez consulter dans un navigateur la liste des paquets : http://ftp.fr.openbsd.org/pub/OpenBSD/5.9/packages/amd64/ .

Cependant, ce n'est pas très pratique. Je vous propose alors le script pkg_sch, qui va récupérer une fois pour toute la liste des paquets (mise à jour régulièrement). Il s'utilise ainsi :

pkg_sch paquet à  trouver


#!/bin/sh
#Search packages for openBSD

HOSTNAME="ftp.openbsd.org"
LOCATION="pub/OpenBSD/5.8/packages/amd64"
PKGLIST=~/.pkg_list

update_list() 
{
    echo "update package list"
ftp -n $HOSTNAME > $PKGLIST << EOF
user anonymous  " "
cd $LOCATION
nlist
bye
EOF
sed -i "s/.tgz//g" $PKGLIST
}

# update if necessary

if [ ! -e $PKGLIST ]; then
    update_list
elif [ $(($(date +%s) - $(stat --format=%Z ~/.pkg_list))) -gt 604800 ]; then
    update_list
fi

egrep "$@" $PKGLIST



Mon programme préféré n'est pas empaqueté
L'équipe d'OpenBSD n'a peut-être pas eu le temps d'empaqueter et vérifier la fiabilité de ce logiciel. Cela ne vous empêchera pas de l'installer, grâce aux système des ports. Il s'agit en réalité d'instructions simples qu'un programme va lire pour compiler et installer votre programme favori.

Si un port est en réalité déjà empaqueté, vous pouvez faire en sorte de le sélectionner directement en ajoutant la ligne suivante au fichier /etc/mk.conf :
FETCH_PACKAGES=yes


Pour récupérer la liste de ports, il faut lancer une fois pour toute les commande suivantes :

 $ cd /tmp
    $ ftp http://ftp.openbsd.org/pub/OpenBSD/$(uname -r)/ports.tar.gz
    $ ftp http://ftp.openbsd.org/pub/OpenBSD/$(uname -r)/SHA256.sig
    $ signify -Cp /etc/signify/openbsd-$(uname -r | cut -c 1,3)-base.pub -x SHA256.sig ports.tar.gz
    # cd /usr
    # tar xzf /tmp/ports.tar.gz


Pour chercher un port, on se déplace dans /usr/ports, puis on cherche le dossier du port souhaité. On peut utiliser "make search" ainsi :

$ cd /usr/ports
$ make search key=rsnapshot


Une fois le port trouvé, déplacez-vous dans son dossier puis lancez "make install".


Référence
— (permalink)

Gravatar de Thuban
Original post of Thuban.Votez pour ce billet sur Planet Libre.