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.

PHP version 5.4.38, 5.5.22 et 5.6.6

Remi Collet

Les RPM de PHP version 5.6.6 sont disponibles dans le dépôt remi pour Fedora 21 et remi-php56 pour Fedora ≤ 20  et Enterprise Linux (RHEL, CentOS).

Les RPM de PHP version 5.5.22 sont disponibles dans le dépôt remi pour Fedora ≤ 20 et dans le dépôt remi-php55 pour Enterprise Linux.

Les RPM de PHP version 5.4.38 sont disponibles dans le dépôt remi pour Enterprise Linux (RHEL, CentOS...).

Ces versions sont aussi disponibles en Software Collections.

security-medium-2-24.pngCes versions corrigent quelques failles de sécurité, la mise à jour est vivement recommandée.

Annonces des versions :

emblem-important-2-24.pngLa version 5.4.33 était la dernière mise à jour corrigeant des bugs. La branche 5.4 est donc en maintenance de sécurité uniquement.

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir la version et le mode d'installation.

Remplacement du PHP par défaut du système par la version 5.6 (le plus simple) :

yum --enablerepo=remi-php56,remi update php\*

Installation en parallèle, en Software Collections de PHP 5.6 (x86_64 uniquement) :

yum --enablerepo=remi install php56

Remplacement du PHP par défaut du système par la version 5.5 (le plus simple) :

yum --enablerepo=remi-php55,remi update php\*

Installation en parallèle, en Software Collections de PHP 5.5 (x86_64 uniquement) :

yum --enablerepo=remi install php55

Remplacement du PHP par défaut du système par la version 5.4 (entreprise uniquement) :

yum --enablerepo=remi update php\*

Installation en parallèle, en Software Collections de PHP 5.4 (x86_64 uniquement) :

yum --enablerepo=remi install php54

Et bientôt dans les mises à jour officielles:

emblem-important-2-24.pngÀ noter :

  • la version EL7 est construite avec RHEL-7.0
  • la version EL6 est construite avec RHEL-6.6
  • beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php54/php55)

PHPUnit 4.5

Remi Collet

Les RPM de PHPUnit version 4.5 sont disponibles dans le dépôt remi pour Fedora et Enterprise Linux (CentOS, RHEL...)

Documentation : PHPUnit 4.5 manual  et Release Announcement for PHPUnit 4.5.0 (english)

Installation :

yum --enablerepo=remi install phpunit

Merci de tester cette nouvelle version, qui devrait bientôt être disponible dans Fedora 21, Rawhide et EPEL-7 (bloqué par les revues #1192493 et #1188530).

Remarque: cet outil est un epièce essentielle de la QA PHP dans Fedora.

PHPUnit 4.5

Remi Collet

Les RPM de PHPUnit version 4.5 sont disponibles dans le dépôt remi pour Fedora et Enterprise Linux (CentOS, RHEL...)

Documentation : PHPUnit 4.5 manual  et Release Announcement for PHPUnit 4.5.0 (english)

Installation :

yum --enablerepo=remi install phpunit

Merci de tester cette nouvelle version, qui devrait bientôt être disponible dans Fedora 21, Rawhide et EPEL-7 (bloqué par les revues #1192493 et #1188530).

Remarque: cet outil est un epièce essentielle de la QA PHP dans Fedora.

Linux Temps Réel sur ARM AT91RM9200. Séance 1 : présentation de la carte

Patrice Kadionik

Salut.

Comme je l'avais fait il y a quelques années avec la carte mini2440, je vais consacrer ce billet et les suivants à la mise en oeuvre de Linux Temps Réel Xenomai sur une ARM Eukréa AT91RM9200.

On verra les points suivants :

  • Mise en œuvre de Linux embarqué.
  • Mise en œuvre de lextension Temps Réel dur Xenomai pour Linux embarqué.
  • Mesures de temps de latence.

Xenomai est une solution Temps Réel dur sous Linux.

Je vais dans ce premier billet présenter la carte cible.

La carte cible AT91 est une carte de développement de la société bordelaise permettant de mettre en œuvre le processeur ARM9 AT91RM9200. Le processeur AT91RM9200 supporte Linux avec MMU.

Larchitecture du processeur AT91RM9200 est donnée sur les figures suivantes :

at91_processeur1.jpg

at91_processeur2.jpg
 
La carte cible possède les fonctionnalités suivantes :

  • ARM920T ARM Thumb Processor, v4T Architecture
  • 200 MIPS at 180 MHz
  • Memory Management Unit
  • 16-KByte Data Cache, 16-KByte Instruction Cache
  • In-circuit Emulator including Debug Communication Channel
  • 16K Bytes of SRAM and 128K Bytes of ROM
  • Ethernet MAC 10/100 Base-T
  • USB 2.0 Full Speed
  • Multimedia Card Interface
  • 4 Universal Synchronous/Asynchronous Receiver/Transmitters
  • Master/Slave Serial Peripheral Interface SPI
  • Two 3-channel, 16-bit Timer/Counters
  • IEEE 1149.1 JTAG Boundary Scan
  • Synchronous dynamic random access memory (SDRAM)
  • 32MB (MICRON - 128Mb x 2)
  • Flash memory
  • 8 MB (MICRON MT28F640J3)
  • Ethernet interface
  • 10-BaseT (10 Mb/s) and 100-BaseT (100 Mb/s) Ethernet Media Access Controller (MAC)
  • MICREL KS8721BL
  • 5 Universal asynchronous receiver/transmitter (UART)
  • USB host and USB device connectors
  • SD/MMC slot
  • 1 Push button : 1 reset

La carte cible possède donc :

  • 8 Mo de mémoire Flash : on y mettra le bootloader u-boot, le noyau Linux et le système de fichiers root.
  • 32 Mo de RAM SDRAM.


 at91_carte.jpg
 
Le mapping mémoire externe de la carte cible est le suivant :

at91_mapping.jpg
 
On notera que :

  • La mémoire RAM va de $2000 0000 à $21FF FFFF (Chip Select 1).
  • La mémoire Flash contenant u-boot (et éventuellement le noyau Linux et le système de fichiers root) va de $1000 0000 à $107F FFFF (Chip Select 0).


Le processeur AT91 possède une MMU (Memory Management Unit) qui protège les accès mémoire. On utilisera donc le noyau Linux standard pour processor ARM9 de type v4T.

Suite au prochain billet...

++

Fedora 21 vs Fedora 20 : comparaison des performances pour les versions 32 bits

Patrice Kadionik

Salut.

Voici les résultats comparatifs de Fedora 21 vs Fedora 20.

Pour rappel, ma machine est équipée d'un Quad Core Intel Q6600 à 2,4 GHz avec 4 Go de RAM.

Je me suis limité au benchmark UnixBench qui fournit un indice global, ce qui me simplifiera la comparaison. La version UnixBench utilisée est la version 4.1.0.

Mon protocole de tests est le suivant :
  • Installation de Fedora 21 version 32 bits avec le noyau Fedora 3.18.5-201.fc21.i686.
  • La machine est placée en niveau 3 (init 3).
  • 10 séries de tests avec UnixBench compilé sous Fedora 21 et exécuté sous Fedora 21 (3.18.5-201.fc21.i686).
  • 10 séries de tests avec UnixBench compilé sous Fedora 20 et exécuté sous Fedora 20 (noyau Fedora 3.17.8-200.fc20.i686).
Voici les résultats obtenus :

Fedora 21 version 32 bits :

Série 1 : 755.5
Série 2 : 779.5
Série 3 : 766.1
Série 4 : 803.1
Série 5 : 772.9
Série 6 : 760.2
Série 7 : 751.3
Série 8 : 753.3
Série 9 : 762.4
Série 10 : 758.5

Moyenne : 766,3

Fedora 20 version 32 bits :

Voici pour rappel les résultats obtenus avec Fedora 20 :
Série 1 : 765.0
Série 2 : 768.0
Série 3 : 759.4
Série 4 : 772.2
Série 5 : 770.7
Série 6 : 769.1
Série 7 : 764.5
Série 8 : 769.1
Série 9 : 767.3
Série 10 : 768.9

Moyenne : 767,4

Résultats :

Pour Fedora 21, on obtient un indice moyen de 766,3 pour UnixBench.
Pour Fedora 20, j'avais obtenu un indice moyen de 767,4 pour UnixBench.


On a donc une baisse non significative de 0.1 % de Fedora 21 32 bits par rapport à Fedora 20 32 bits...
On assiste cette fois-ci à une stabilisation des performances avec cette version de Fedora comme montré sur la figure suivante :

perfs_fedora_F21.png

Conclusion :


Au moment de ces tests, le noyau Fedora 21 (basé sur le noyau vanilla 3.18.5) reste stable par rapport au noyau Fedora 20 (basé sur le noyau vanilla 3.17.8).


++

Fedora 20 vs Fedora 19 : comparaison des performances pour les versions 32 bits

Patrice Kadionik

Salut.

Voici les résultats comparatifs de Fedora 20 vs Fedora 19.

Pour rappel, ma machine est équipée d'un Quad Core Intel Q6600 à 2,4 GHz avec 4 Go de RAM.

Je me suis limité au benchmark UnixBench qui fournit un indice global, ce qui me simplifiera la comparaison. La version UnixBench utilisée est la version 4.1.0.

Mon protocole de tests est le suivant :
  • Installation de Fedora 20 version 32 bits avec le noyau Fedora 3.17.8-200.fc20.i686+PAE.
  • La machine est placée en niveau 3 (init 3).
  • 10 séries de tests avec UnixBench compilé sous Fedora 20 et exécuté sous Fedora 20 (noyau Fedora 3.17.8-200.fc20.i686+PAE).
  • 10 séries de tests avec UnixBench compilé sous Fedora 19 et exécuté sous Fedora 19 (noyau 3.9.5-301.fc19.i686.PAE).
Voici les résultats obtenus :

Fedora 20 version 32 bits :

Série 1 : 765.0
Série 2 : 768.0
Série 3 : 759.4
Série 4 : 772.2
Série 5 : 770.7
Série 6 : 769.1
Série 7 : 764.5
Série 8 : 769.1
Série 9 : 767.3
Série 10 : 768.9

Moyenne : 767,4

Fedora 19 version 32 bits :

Voici pour rappel les résultats obtenus avec Fedora 19 :
Série 1 : 723.9
Série 2 : 724.7
Série 3 : 729.0
Série 4 : 730.4
Série 5 : 730.3
Série 6 : 726.3
Série 7 : 743.7
Série 8 : 732.0
Série 9 : 732.3
Série 10 : 740.4

Moyenne : 731,3

Résultats :

Pour Fedora 20, on obtient un indice moyen de 767,4 pour UnixBench.
Pour Fedora 19, j'avais obtenu un indice moyen de 731,3 pour UnixBench.


On a donc une augmentation moyenne de près de 4.9 % de Fedora 20 32 bits par rapport à Fedora 19 32 bits...
On assiste cette fois-ci à une augmentation des performances avec cette version de Fedora comme montré sur la figure suivante :

perfs_fedora_F20.png

Conclusion :


Au moment de ces tests, le noyau Fedora 20 (basé sur le noyau vanilla 3.17.8) propose une hausse de 4.9 % par rapport au noyau Fedora 19 (basé sur le noyau vanilla 3.9.5), ce qui le ramène au niveau de Fedora 7, premier noyau Fedora que j'avais testé.


++

Fedora 19 vs Fedora 18 : comparaison des performances pour les versions 32 bits

Patrice Kadionik

Salut.

C'est encore avec beaucoup de retard que je vous livre ces dernières mesures...

Voici les résultats comparatifs de Fedora 19 vs Fedora 18.

Pour rappel, ma machine est équipée d'un Quad Core Intel Q6600 à 2,4 GHz avec 4 Go de RAM.

Je me suis limité au benchmark UnixBench qui fournit un indice global, ce qui me simplifiera la comparaison. La version UnixBench utilisée est la version 4.1.0.

Mon protocole de tests est le suivant :
  • Installation de Fedora 19 version 32 bits avec le noyau Fedora 3.9.5-301.fc19.i686.PAE.
  • La machine est placée en niveau 3 (init 3).
  • 10 séries de tests avec UnixBench compilé sous Fedora 19 et exécuté sous Fedora 19 (noyau Fedora 3.9.5-301.fc19.i686.PAE).
  • 10 séries de tests avec UnixBench compilé sous Fedora 18 et exécuté sous Fedora 18 (noyau 3.6.10-4.fc18.i686.PAE).
Voici les résultats obtenus :

Fedora 19 version 32 bits :

Série 1 : 723.9
Série 2 : 724.7
Série 3 : 729.0
Série 4 : 730.4
Série 5 : 730.3
Série 6 : 726.3
Série 7 : 743.7
Série 8 : 732.0
Série 9 : 732.3
Série 10 : 740.4

Moyenne : 731,3

Fedora 18 version 32 bits :

Voici pour rappel les résultats obtenus avec Fedora 18 :
Série 1 : 755.2
Série 2 : 747.9
Série 3 : 757.8
Série 4 : 771.8
Série 5 : 764.7
Série 6 : 759.2
Série 7 : 764.8
Série 8 : 759.0
Série 9 : 766.7
Série 10 : 748.7

Moyenne : 759.6



Résultats :

Pour Fedora 19, on obtient un indice moyen de 731,3 pour UnixBench.
Pour Fedora 18, j'avais obtenu un indice moyen de 759.6 pour UnixBench.


On a donc une perte moyenne de près de 3.7 % de Fedora 19 32 bits par rapport à Fedora 18 32 bits...
On assiste cette fois-ci à une légère baisse des performances avec cette version de Fedora comme montré sur la figure suivante :

perfs_fedora_F19.png

Conclusion :


Au moment de ces tests, le noyau Fedora 19 (basé sur le noyau vanilla 3.9.5) propose une baisse de 3.7 % par rapport au noyau Fedora 18 (basé sur le noyau vanilla 3.6.10), ce qui le ramène au niveau de Fedora 8.


++

Toggle proxy

Matthieu Saulnier

Dans le dernier article j'ai oublié de mentionner l'extention Firefox qui permet de basculer en un clic entre deux configurations réseau, que l'on aura préalablement configuré dans les paramètres de Firefox.

Cette extention se nomme Toggle proxy. Dans ses paramètres on sélectionne "Pas de proxy" pour un état, et pour le second état on sélectionne "Configuration manuelle". Il faut que la configuration manuelle soit d'abord correctement configurée pour utiliser le proxy SOCKS de Tor avec DNS distant, à contrôler dans les paramètres de Firefox. L'extention agit comme un interrupteur, un bouton ON/OFF, en cliquant dessus dans la barre d'extentions on switche de connexion pour les prochaines requêtes. On peut également utiliser le racourci clavier [Alt-x]. Dans la description de l'extention il est indiqué qu'on peut modifier le raccourci clavier, je n'ai pas trouvé comment et celui-là me convient bien au final.

Pour vérifier que j'utilise bien le sous-réseau Tor, je me rends à l'adresse du serveur qui fait tourner ce blog où je suis sûr de tomber sur un Apache :

http://d72vewh3wa4lwpaj.onion/

Cette adresse de sous-réseau correspond à l'adresse lancaster.casperlefantom.net, elles pointent toutes les deux vers la même machine.

À Tor ou à raison

Matthieu Saulnier

Cela fait plusieurs mois déjà que j'étudie le sous-réseau Tor. L'idée m'a pris en novembre dernier d'explorer des réseaux dans le réseau, et le plus célèbre d'entre eux est bien sûr Tor. À peine je commence cet article que je dis déjà halte aux préjugés sur Tor, il est à l'image de l'utilisation que chacun de nous en fait, c'est la même chose avec le réseau (Internet). Du point de vue historique, il a été inventé par le laboratoire de recherche de l'U.S. Navy avec pour objectif de protéger les communications du gouvernement. Ce sous-réseau est très intéressant car il permet de s'affranchir d'un certain nombre de contraintes appliquées par le routage classique.

Routage en onion

Son architecture a la forme d'un onion, c'est à dire qu'une couche ne connait que la couche qui lui est supérieur et la couche qui lui est inférieur, elle ignore la présence des autres couche, et il en est de même pour chaque couche. Pour la conception d'un tel système de routage, chaque routeur ne doit connaitre la présence que de deux routeurs du circuit dont il fait parti, et ne peut pas connaitre les autres routeurs de son circuit. Il connait donc le routeur expéditeur d'un traffic et le routeur destinataire sans jamais connaitre le destinataire final placé à l'extrémité du circuit. Basé sur ce concept simple, le routage en onion est né.

Un routeur sur toutes ses Fedora

Les avantages d'avoir le service Tor installé et actif sur ses machines sont multiples. Ces routeurs couvrent tout l'éventail des applications réseau, du client au serveur. Pour la partie client, ne croyez pas qu'en passant par Tor vous devenez anonyme sur le Web. Avant d'atteindre ce statut il faut bloquer les cookies et désactiver Javascript. En revanche vous devenez effectivement anonyme sur le réseau, mais ce n'est pas cette particularité qui m'attire le plus chez Tor. C'est le concept de réseau dans le réseau qui m'inspire. Si une machine change d'emplacement sur le réseau (donc a changé de zone géographique), elle ne change pas d'adresse dans le sous-réseau. De plus, toutes les limitations du réseau (par exemple NAT et pare-feu de box) ont disparu, laissant la configuration du routeur gérer les accès à la machine. 

Application client

Il y a moyen d'avoir une utilisation très poussée du sous-réseau, mais tout n'est pas possible. En effet à cause des abus, les ports du protocole Bittorrent sont bloqués, les ports d'envoi de courriels le sont aussi. En revanche pour la partie technique, on a un port d'écoute sur l'interface localhost de type Proxy SOCKSv5 (avec DNS distant) dans lequel on peut envoyer diverses requêtes réseau. Pour envoyer les traffics réseau d'un logiciel quelconque qui ne dispose pas de configuration proxy SOCKS, on a le choix entre deux logiciels: torsocks qui est fourni avec le paquet Tor, et proxychains. Si les logiciels qu'on utilise tous les jours peuvent être configurés pour utiliser un proxy SOCKS comme Firefox par exemple, alors nul besoin de passer par torsocks ou proxychains. Au niveau du fichier de configuration /etc/tor/torrc, il n'y a rien à modifier.

Application serveur

Pour la partie serveur, les services réseau traditionnels peuvent être rendu accessible depuis le sous-réseau avec le minimum de configuration du routeur, et surtout permet de contourner la redirection de ports/NAT de la box (le routeur du réseau). Encore plus fort, si jamais la machine change d'emplacement physique sur le réseau, l'emplacement dans le sous-réseau ne change pas, tant que le routeur n'est pas réinstallé. Tous les services peuvent écouter et attendre les connexions clientes depuis le sous-réseau indépendemment de la zone géographique de la machine, mais les services eux-même ne peuvent pas établir de connexion cliente avec d'autres serveurs à travers le sous-réseau (à quelques exceptions près). Au niveau du fichier de configuration, il faudra ajouter les lignes suivantes :

HiddenServiceDir /var/lib/tor/hidden_service1/
HiddenServicePort 22 127.0.0.1:22
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 443 127.0.0.1:443

Pour chaque hidden_service2, 3, 4, etc, l'adresse en .onion sera différente. Par exemple pour joindre ma machine sur les ports HTTP avec une adresse différente de celle du port SSH :

HiddenServiceDir /var/lib/tor/hidden_service1/
HiddenServicePort 22 127.0.0.1:22
HiddenServiceDir /var/lib/tor/hidden_service2/
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 443 127.0.0.1:443

L'adresse de chaque hidden_service est stockée dans le fichier /var/lib/tor/hidden_service1/hostname.

Et les relais dans tout ça ?

Les applications évoquées précédemment n'impliquent pas que vous fassiez tourner un relai sur votre machine. Le routeur peut très bien être configuré en mode relai en plus de tout le reste. Le sous-réseau Tor n'existe que s'il y a suffisemment de relais dispersés à travers le monde, et à l'heure où j'écris ces lignes il y en a environ 8 000.

Avant de se lancer il faut savoir qu'il y a trois types de relai: Le relai de sortie, le relai au milieu et le relai gardien. Le relai de sortie est situé à l'extrèmité du circuit, c'est là où débouche tous les traffics entre le sous-réseau et Internet. C'est clairement pas une bonne idée d'avoir ce type de relai sur une ligne domestique, et il faut lire beaucoup de documentation pour réunir les conditions optimales au fonctionnement de ce type de relai. Le relai au milieu, comme son nom l'indique est placé au milieu du circuit, et ne communique qu'avec d'autres relais, c'est l'idéal pour une ligne domestique car il n'y a que du traffic chiffré. Enfin, les relais gardiens sont en fait des relais du milieu qui ont suffisament d'ancienneté pour être acrédité à recevoir les connexions des utilisateurs de Tor. Il sont situés à l'autre extrèmité du circuit, la plus sensible des deux.

Relai du milieu

La configuration par défaut du service Tor en mode relai est de type sortie (cumulée avec les autres types de relai car un routeur peut tout faire en même temps), il faut donc désactiver la sortie, et faire un peu de redirection de port/NAT avec sa box. Les ports OR (Onion Routing) et Dir (Directory Information) doivent être joignables depuis l'extérieur. On peut préciser le pseudo du relai ainsi que nos limites de bande passante. L'information de contact doit aussi être renseigné avec une clé GPG et une adresse email valide (mais obscurcie pour le spam) afin de pouvoir être averti en cas de problème. Enfin, il faut explicitement indiquer dans la conf que toutes les règles de sortie de traffic sont rejetées par le relai.

ORPort 9001
Nickname Casper02
RelayBandwidthRate 50 KB
RelayBandwidthBurst 60 KB
ContactInfo 0x83288189 Casper <fantom{ AT} fedoraproject{ dot} org>
DirPort 9030
ExitPolicy reject *:*

Rester dans le sous-réseau

C'est possible, et c'est la partie que je préfère de Tor. Jusqu'à maintenant nous avons vu les communications entre le sous-réseau et le réseau en passant par les relais de sortie, mais on peut tout aussi bien rester de bout en bout dans le sous-réseau pour joindre ses machines, à condition qu'elles aient toutes un routeur installé. Il y a une dualité entre les applications client et serveur vues précédemment. Si on peut utiliser l'application client pour joindre un serveur sur le réseau, on ne peut pas utiliser l'application serveur sans utiliser l'application client. Tout simplement car on ne peut pas joindre un serveur dans le sous-réseau en passant par le réseau, ce qui est plutôt logique en soit. L'application serveur nécessite l'application client, et utiliser les deux en même temps permet de réaliser ainsi une connexion de bout en bout dans le sous-réseau sans jamais transiter par le réseau. Fantastique non ?

Installation et préférences globales

C'est le moment où l'on peut agir en connaissance de cause. Cette partie est bien la plus facile, mais elle implique de grandes responsabilités, c'est pourquoi je ne la traite qu'à la toute fin.

# yum install tor tor-arm

Le minimum de configuration quel que soit le mode de votre routeur, qui n'est pas vital mais que je recommande :

Log notice file /var/log/tor/notices.log
Log warn file /var/log/tor/warnings.log
RunAsDaemon 1
DataDirectory /var/lib/tor
ControlPort 9051
HashedControlPassword my-hashed-password-here

Le port de contrôle (9051) n'est actif que sur l'interface localhost, il n'y a pas lieu de s'inquièter. Le hashage du mot de passe se fait avec la commande :

$ tor --hash-password mon-mot-passe-il-dechire

Le programme tor-arm, ou plutôt ARM de son vrai nom, est un programme de monitoring comme top, htop ou glances, sauf qu'il est spécialisé pour les routeurs Tor. Pour qu'il puisse se connecter au port 9051 il faudra taper le mot de passe précédent à son lancement dans le terminal. Si vous avez envie de faire tourner plus d'un relai, quel que soit son type vu précédemment, il faudra ajouter un paramètre supplémentaire dans le fichier de conf :

MyFamily $D8AE9C760B74AFE3CA0F48EEB21271E22CF25F7A, $etc, $etc...

Cette option sert à indiquer à vos routeurs à quels relais il ne doivent jamais se connecter pour garantir l'intégrité de leurs circuits de connexion, l'empreinte que l'on indique est lisible dans le fichier /var/lib/tor/fingerprint présent sur chaque routeur.

Ok, et toi dans tout ça ?

Personnellement je détiens trois connexions sur le réseau, la ligne ADSL de mon domicile, une machine virtuelle dans un datacenter à Billancourt, et une autre machine virtuelle dans un datacenter à Roubaix. J'y ai donc installé trois relais de type différent, dont un à basse vitesse, car ce n'est pas la bande passante qui compte, mais bien le nombre de relais accessibles.

Upgrade du serveur

Matthieu Saulnier

J'avais jusqu'à présent eu aucune occasion de parler des upgrades de mon serveur Fedora ici, puisque jusqu'à présent il n'y avait pas grand chose à dire, même rien du tout. Depuis l'apparition de FedUp, en Fedora 17 si ma mémoire est bonne, j'ai upgradé successivement le système du serveur, avec soin et minutie, sans jamais rencontrer un seul pépin. Il faut dire que je le chouchoute, tous les jours il m'envoie son rapport journalier m'informant de diverses avaries rencontrées durant les dernières 24 heures, les réactions qu'il a eu pour corriger ces anomalies, et même lancer une fois par semaine des tests matériels.

On a quoi sur la table ?

Un Linux Apache Mariadb PHP Bind Postfix Dovecot NTP NFS Bittorrent Tor Jabber KVM (Bitcoin daemon est dans une VM), fraichement upgradé en F21, basé sur une installation minimale sans Environnement de Bureau. Deux disques durs pour un grand LVM, 23 volumes logiques (si si, pas moins), SELinux en mode targeted, SSH en mode authentification par clé, rapports de contrôle des fichiers avec la rpmdb, rapports des anomalies SELinux, des HIDS, etc...

Il s'est passé quoi ?

Une upgrade à première vue comme toutes les autres, le journal de FedUp est lisible ici pour le prouver (FedUp remplit le même fichier depuis F18, la partie qui nous concerne est tout en bas), sauf que le reboot suivant a déraillé. Au premier coup d'oeil le serveur NFS ne démarrait pas, son journal n'explique pas pourquoi. Le méta-moteur de recherche Seeks est aussi hors-service, sauf que lui on sait pourquoi : les dépendances du paquets F20 ne sont plus satisfaites, normal nous sommes en F21. NetworkManager quant à lui indique dans sont journal qu'il n'a plus du tout de mémoire disponible pour traiter de nouveaux événements.

janv. 22 15:31:30 lancaster rpc.statd[5232]: Version 1.3.1 starting
janv. 22 15:31:30 lancaster rpc.statd[5232]: Flags: TI-RPC
janv. 22 15:31:30 lancaster rpc.statd[5232]: failed to create RPC listeners, exiting
janv. 22 15:31:31 lancaster systemd[1]: rpc-statd.service: control process exited, code=exited status=1
janv. 22 15:31:31 lancaster systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking..
janv. 22 15:31:31 lancaster systemd[1]: Unit rpc-statd.service entered failed state.
janv. 22 15:31:31 lancaster systemd[1]: rpc-statd.service failed.
janv. 22 15:31:31 lancaster rpc.mountd[5230]: Could not bind socket: (98) Address already in use
janv. 22 15:31:31 lancaster rpc.mountd[5230]: Could not bind socket: (98) Address already in use
janv. 22 15:31:31 lancaster rpc.mountd[5230]: Could not bind socket: (98) Address already in use
janv. 22 15:31:31 lancaster rpc.mountd[5230]: Could not bind socket: (98) Address already in use
janv. 22 15:31:31 lancaster rpc.mountd[5230]: mountd: No V2 or V3 listeners created!
janv. 22 15:31:31 lancaster rpc.mountd[5234]: Version 1.3.1 starting
janv. 22 15:31:31 lancaster rpc.nfsd[5237]: rpc.nfsd: writing fd to kernel failed: errno 111 (Connection refused)
janv. 22 15:31:31 lancaster kernel: svc: failed to register nfsdv3 RPC service (errno 111).
janv. 22 15:31:31 lancaster kernel: svc: failed to register nfsaclv3 RPC service (errno 111).
janv. 22 15:31:31 lancaster rpc.nfsd[5237]: rpc.nfsd: unable to set any sockets for nfsd
janv. 22 15:31:31 lancaster kernel: svc: failed to register nfsdv3 RPC service (errno 97).
janv. 22 15:31:31 lancaster kernel: svc: failed to register nfsaclv3 RPC service (errno 97).
janv. 22 15:31:31 lancaster systemd[1]: nfs-server.service: main process exited, code=exited, status=1/FAILURE
janv. 22 15:31:31 lancaster systemd[1]: Failed to start NFS server and services.
janv. 22 15:31:31 lancaster systemd[1]: Unit nfs-server.service entered failed state.
janv. 22 15:31:31 lancaster systemd[1]: nfs-server.service failed.

janv. 22 14:38:59 lancaster NetworkManager[958]: <error> [1421933939.450160] [platform/nm-linux-platform.c:3842] event_handler(): Failed to retrieve incoming events: Out of memory (-5)

Donc on fait quoi ?

Les pièces du puzzle sont en place, l'enquête va pouvoir commencer. Typiquement on commence par le plus petit pour aller vers le plus gros (problème), on dégrossi en quelques sortes. Seeks était pointé du doigt par la commande package-cleanup --problems, il apparait également dans le journal de FedUp. La meilleure solution pour lui en attendant la sortie du paquet F21 est bien de le retirer avec Yum. En lisant de près le journal du service nfs-server, on observe qu'en fait ce sont les services RPC dont NFS est dépendant, qui ne démarrent pas. J'ai remarqué aussi que NetworkManager a imprimé son erreur au même instant lorsque j'essayais de démarrer nfs-server, peut-être que les deux éléments sont liés.

J'ai donc fait plusieurs tests. J'ai commencé par supprimer le fichier /etc/sysctl.d/transmission.conf qui modifiait la mémoire maximum allouée à l'interface réseau. Ce hack (obsolète après test) résolvait une erreur dans le démon Transmission, puis j'ai stoppé le service Transmission pour voir s'il influençait NetworkManager, j'ai aussi essayé de démarrer plusieurs fois nfs-server pour voir si ça déclenchait l'erreur de NM. Aucun résultat à noter, nous avons bien à faire à un bug propre à NetworkManager. Si son bug n'est pas influencé par différents service réseau, est-ce que son bug affecte le démarrage des services RPC empèchant ainsi le démarrage de nfs-server ?

En regardant un peu sur le web, j'ai trouvé que le bug était connu sur EPEL7. Si le bug est connu quelque part, son fix est peut-être déjà arrivé dans le dépôt updates-testing. Erreur encore une fois, pas de mise à jour disponible pour le paquet NM. Le ticket du bug EPEL7 aidant, j'ai donc ouvert un ticket pour F21. Il ne reste plus que le cas des services RPC à traiter pour y voir plus clair dans l'affaire du serveur NFS.

Ironie du sort, en cherchant sur le Bugzilla je suis tombé par hasard sur ce ticket, dévoilant l'explication logique et rationnelle du pourquoi les services RPC ne démarraient pas. Les mots clés pour cette recherche furent : rpc.statd failed to create RPC listeners, exiting Qui eu crû que c'était parce que le service rpcbind.socket n'était ni activé ni démarré suite à l'upgrade ? Une fois ce socket activé, NFS ne démarra pas pour autant au boot de la machine. En effet, nfs.target est un reliquat du passé et n'existe plus sur F21. Il conviendra donc de désactiver puis réactiver ce service pour corriger les liens symboliques utilisés par systemd.

# systemctl disable nfs-server
Removed symlink /etc/systemd/system/nfs.target.wants/nfs-server.service.
# systemctl enable nfs-server
Created symlink from /etc/systemd/system/multi-user.target.wants/nfs-server.service to /usr/lib/systemd/system/nfs-server.service.

Le mystère est résolu

Élémentaire mon cher, lorsqu'on rencontre un problème avec NFS, c'est toute la pile RPC qu'il faut vérifier sur son système...

PHP version 5.4.37, 5.5.21 et 5.6.5

Remi Collet

Les RPM de PHP version 5.6.5 sont disponibles dans le dépôt remi pour Fedora 21 et remi-php56 pour Fedora ≤ 20  et Enterprise Linux (RHEL, CentOS).

Les RPM de PHP version 5.5.21 sont disponibles dans le dépôt remi pour Fedora ≤ 20 et dans le dépôt remi-php55 pour Enterprise Linux.

Les RPM de PHP version 5.4.37 sont disponibles dans le dépôt remi pour Enterprise Linux (RHEL, CentOS...).

Ces versions sont aussi disponibles en Software Collections.

security-medium-2-24.pngCes versions corrigent quelques failles de sécurité, la mise à jour est vivement recommandée.

Annonces des versions :

emblem-important-2-24.pngLa version 5.4.33 était la dernière mise à jour corrigeant des bugs. La branche 5.4 est donc en maintenance de sécurité uniquement.

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir la version et le mode d'installation.

Remplacement du PHP par défaut du système par la version 5.6 (le plus simple) :

yum --enablerepo=remi-php56,remi update php\*

Installation en parallèle, en Software Collections de PHP 5.6 (x86_64 uniquement) :

yum --enablerepo=remi install php56

Remplacement du PHP par défaut du système par la version 5.5 (le plus simple) :

yum --enablerepo=remi-php55,remi update php\*

Installation en parallèle, en Software Collections de PHP 5.5 (x86_64 uniquement) :

yum --enablerepo=remi install php55

Remplacement du PHP par défaut du système par la version 5.4 (entreprise uniquement) :

yum --enablerepo=remi update php\*

Installation en parallèle, en Software Collections de PHP 5.4 (x86_64 uniquement) :

yum --enablerepo=remi install php54

Et bientôt dans les mises à jour officielles:

emblem-important-2-24.pngÀ noter :

  • la version EL7 est construite avec RHEL-7.0
  • la version EL6 est construite avec RHEL-6.6
  • beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php54/php55)

PHP version 5.4.37, 5.5.21 et 5.6.5

Remi Collet

Les RPM de PHP version 5.6.5 sont disponibles dans le dépôt remi pour Fedora 21 et remi-php56 pour Fedora ≤ 20  et Enterprise Linux (RHEL, CentOS).

Les RPM de PHP version 5.5.21 sont disponibles dans le dépôt remi pour Fedora ≤ 20 et dans le dépôt remi-php55 pour Enterprise Linux.

Les RPM de PHP version 5.4.37 sont disponibles dans le dépôt remi pour Enterprise Linux (RHEL, CentOS...).

Ces versions sont aussi disponibles en Software Collections.

security-medium-2-24.pngCes versions corrigent quelques failles de sécurité, la mise à jour est vivement recommandée.

Annonces des versions :

emblem-important-2-24.pngLa version 5.4.33 était la dernière mise à jour corrigeant des bugs. La branche 5.4 est donc en maintenance de sécurité uniquement.

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir la version et le mode d'installation.

Remplacement du PHP par défaut du système par la version 5.6 (le plus simple) :

yum --enablerepo=remi-php56,remi update php\*

Installation en parallèle, en Software Collections de PHP 5.6 (x86_64 uniquement) :

yum --enablerepo=remi install php56

Remplacement du PHP par défaut du système par la version 5.5 (le plus simple) :

yum --enablerepo=remi-php55,remi update php\*

Installation en parallèle, en Software Collections de PHP 5.5 (x86_64 uniquement) :

yum --enablerepo=remi install php55

Remplacement du PHP par défaut du système par la version 5.4 (entreprise uniquement) :

yum --enablerepo=remi update php\*

Installation en parallèle, en Software Collections de PHP 5.4 (x86_64 uniquement) :

yum --enablerepo=remi install php54

Et bientôt dans les mises à jour officielles:

emblem-important-2-24.pngÀ noter :

  • la version EL7 est construite avec RHEL-7.0
  • la version EL6 est construite avec RHEL-6.6
  • beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php54/php55)

Et si on enlève Javascript

Matthieu Saulnier

En voilà une question amusante. À l'heure où tous les sites web sont gavés de Javascript, à quoi ressemblerait le Web 2.0 si ont désactivait Javascript dans sont navigateur. Pour cette expérience j'ai installé le plugin NoScript en mode "je laisse rien passer" dans Firefox. Aller, exceptionnellement je vais pas spoiler. Have fun... :-D

J'imagine déjà la bannière à la mode sur les plus grands sites web: « Ce site utilise Javascript, en l'activant dans votre navigateur vous consentez à notre politique d'utilisation de tout ce que nos scripts vont trouver chez vous. » Pitié, déjà qu'avec la bannière ridicule actuelle on apprend que le cookie n'est pas un biscuit mais un traceur, cette déclaration caricaturale est à prendre au second degré.

find : exécuter des commandes complexes avec l'option -exec

Thomas Bouffon

find est très utile pour trouver des fichiers, mais aussi pour y appliquer des actions groupées avec l'option-exec

linux_logo pour f21

Matthieu Saulnier Le paquet linux_logo contenant les bannières Fedora en ascii art est désormais disponible pour Fedora 21. J'ai repris mon vieux SRPM datant de f19, sachant que ce paquet n'a eu aucun changement depuis plusieurs années déjà. Les paquets finaux et journaux de construction sont disponibles directement dans le Fedora BuildSystem, j'ai d'ailleurs importé ces paquets dans mon petit Entrepôt. Pour celles et ceux qui l'utilisaient dans leurs bashrc ou zshrc, il faudra mettre à jour le numéro du logo à afficher donc ne soyez pas surpris que ce soit pas le bon logo qui s'affiche du premier coup.

-       linux_logo -L 12 -F "Bienvenue sur l'hôte #H\n#V, Compilé #C \n#P #X #T, #R, #U"
+       linux_logo -L 26 -F "Bienvenue sur l'hôte #H\n#V, Compilé #C \n#P #X #T, #R, #U"


Pour rappel, pour afficher la liste de tous les logos disponibles il y a toujours la commande :

casper@blackbird ~ % linux_logo -L list

Available Built-in Logos:
        Num     Type    Ascii   Name            Description
        1       Banner  Yes     banner-simp     Simplified Banner Logo
        2       Classic Yes     classic-simp    Classic No Dots Or Letters
        3       Classic Yes     classic-nodots  The Classic Logo, No Periods
        4       Classic Yes     irix            Irix Logo
        5       Banner  Yes     solaris         The Default Banner Logos
        6       Classic Yes     aix             AIX Logo
        7       Classic Yes     bsd             FreeBSD Logo
        8       Banner  Yes     bsd_banner      FreeBSD Logo
        9       Banner  Yes     banner          The Default Banner Logo
        10      Classic Yes     classic         The Default Classic Logo
        11      Banner  Yes     redhat          RedHat Banner (white)
        12      Banner  Yes     slackware       Slackware Logo
        13      Classic Yes     core            Core Linux Logo
        14      Banner  Yes     mandriva        Mandriva(TM) Linux Banner
        15      Banner  Yes     fedora          Fedora Banner (little)
        16      Banner  Yes     mandrake        Mandrakelinux(TM) Banner
        17      Classic Yes     debian_old      Debian Old Penguin Logos
        18      Banner  Yes     ubuntu          Ubuntu Logo
        19      Banner  Yes     sme             SME Server Banner Logo
        20      Banner  Yes     mandrake_banner Mandrake(TM) Linux Banner
        21      Classic Yes     debian          Debian Swirl Logos
        22      Classic Yes     gnu_linux       Classic GNU/Linux
        23      Banner  Yes     suse            SUSE Logo
        24      Banner  Yes     sourcemage_ban  Source Mage GNU/Linux banner
        25      Banner  Yes     sourcemage      Source Mage GNU/Linux large
        26      Banner  Yes     fedora          Fedora Banner
        27      Classic Yes     fedora          Fedora Logo
        28      Banner  Yes     debian_banner   Debian Banner (white)
        29      Banner  Yes     pld             PLD Linux banner

Do "linux_logo -L num" where num is from above to get the appropriate logo.
Remember to also use -a to get ascii version.



Par ailleurs, j'ai rencontré un petit soucis pour upgrader depuis la version f20. D'habitude je commente juste l'option exclude dans yum.conf, puis je réinstalle avec le nouveau paquet :

###exclude=linux_logo

lancaster ~ # yum reinstall https://fantom.fedorapeople.org/linux_logo-5.11-6.fc21.x86_64.rpm
Modules complémentaires chargés : fastestmirror, langpacks, verify
linux_logo-5.11-6.fc21.x86_64.rpm                                                                                                                                                                                       |  82 kB  00:00:00    
Examen de /var/tmp/yum-root-lxQKhU/linux_logo-5.11-6.fc21.x86_64.rpm : linux_logo-5.11-6.fc21.x86_64
Aucun paquet correspondant à désinstaller : linux_logo-0:5.11-6.fc21
Erreur : Problème dans la réinstallation : aucun paquet correspondant à supprimer


J'ai finalement supprimé le paquet avec yum, puis installé le nouveau aussi avec yum. Fin de l'histoire.

linuxlogo-fedora.png








Le fond d'écran est signé par le designer PapsOu de la communauté francophone de Fedora. Ça claque n'est-ce pas ?

Memo : rationaliser l'utilisation du wifi sous CyanogenMod

Thomas Bouffon

Depuis que que mon Xperia GO est sous CM10, j'ai déjà beaucoup gagné en autonomie en supprimant un paquet d'apps et services inutils. Mais j'ai perdu queluqes options d'économie d'énergie Sony fort utiles. Ici, quelques notes pour éviter d'avoir toujours le wifi allumé.

PHP version 5.5.21RC1 et 5.6.5RC1

Remi Collet

emblem-notice-24.pngNouveauté : les versions Release Candidate sont désormais disponibles dans le dépôt remi-test pour Fedora et Enterprise Linux (RHEL / CentOS) afin de permettre au plus grand nombre de les tester. Elles sont uniquement fournit en Software Collections, pour une installation en parallèle, solution idéale pour ce type de tests.

Les RPM de PHP version 5.6.5RC1 en SCL sont disponibles dans le dépôt remi-test pour Fedora 19-21 et Enterprise Linux.

Les RPM de PHP version 5.5.21RC1 en SCL sont disponibles dans le dépôt remi-test pour Fedora 21 et Enterprise Linux.

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir la version.

Installation en parallèle, en Software Collections de PHP 5.6 (x86_64 uniquement) :

yum --enablerepo=remi,remi-test install php56

Installation en parallèle, en Software Collections de PHP 5.5 (x86_64 uniquement) :

yum --enablerepo=remi,remi-test install php55

A noter, la version 5.6.4RC1 est aussi disponible dans Fedora rawhide.

emblem-notice-24.pngLa version RC est généralement identique à la version finale (à l'exception de correctifs de sécurité).

Software Collections (php55/php56)

PHP version 5.5.21RC1 et 5.6.5RC1

Remi Collet

emblem-notice-24.pngNouveauté : les versions Release Candidate sont désormais disponibles dans le dépôt remi-test pour Fedora et Enterprise Linux (RHEL / CentOS) afin de permettre au plus grand nombre de les tester. Elles sont uniquement fournit en Software Collections, pour une installation en parallèle, solution idéale pour ce type de tests.

Les RPM de PHP version 5.6.5RC1 en SCL sont disponibles dans le dépôt remi-test pour Fedora 19-21 et Enterprise Linux.

Les RPM de PHP version 5.5.21RC1 en SCL sont disponibles dans le dépôt remi-test pour Fedora 21 et Enterprise Linux.

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir la version.

Installation en parallèle, en Software Collections de PHP 5.6 (x86_64 uniquement) :

yum --enablerepo=remi,remi-test install php56

Installation en parallèle, en Software Collections de PHP 5.5 (x86_64 uniquement) :

yum --enablerepo=remi,remi-test install php55

A noter, la version 5.6.5RC1 est aussi disponible dans Fedora rawhide.

emblem-notice-24.pngLa version RC est généralement identique à la version finale (à l'exception de correctifs de sécurité).

Software Collections (php55/php56)

Interdiction par défaut de se connecter en root via ssh pour Fedora 22

Edouard Bourguignon

Si vous avez l'habitude de vous connecter en root à vos Fedora via SSH, vous devriez perdre cette mauvaise habitude dès la prochaine Fedora 22.

En effet, toujours dans l'idée de renforcer la sécurité, les connexions root à distance seront par défaut interdites dans la configuration du démon sshd.

Concrêtement les prochaines versions du paquet openssh-server fourniront une configuration avec :

PermitRootLogin=no

Les utilisateurs seront ainsi obligés de suivre les bonnes pratiques, à savoir d'utiliser un compte utilisateur normal, surtout à distance (ssh), et éventuellement, en cas de besoin, de passer par su ou sudo.

Il a même été prévu, pour ceux qui n'aurait qu'un compte root sur le Fedora (WTF?), sans autre compte utilisateur, que cette option ne soit pas touchée, histoire de pas les enfermer dehors...

Pour rappel, la Fedora 22 est prévue pour le mois de mai 2015.

février 2015

Premier Samedi Date : samedi 7 février 2015 Horaires : de 14h00 à 18h00 Lieu : Carrefour Numérique, Cité des Sciences et de lIndustrie, Paris Pour une nouvelle installation ou pour des ajustements de votre distribution GNU/Linux Fedora, Mageia ou Ubuntu, venez nous retrouver le samedi 7 février 2015 au Carrefour Numérique de la Cité des Sciences […]

Page générée le 27 juin 2015 à 12:36