Planet Fedora-Fr http://planet.fedora-fr.org Sélection de blogs autour de Fedora fr-FR Sun, 01 Mar 2015 02:00:18 GMT eZ Systems eZ Publish (leZRSS) http://planet.fedora-fr.org/var/fedora/storage/images/media/images/logos/logo-rss/18149-2-fre-FR/logo-rss_rss.png Planet Fedora-Fr http://planet.fedora-fr.org Thu, 26 Feb 2015 15:35:43 GMT Premier Samedi : mars 2015 http://premier-samedi.org/premier-samedi/mars-2015/ https://premier-samedi.org/?p=1470 Date : samedi 7 mars 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 mars 2015 au Carrefour Numérique de la Cité des Sciences […]]]> premier samedi Thu, 26 Feb 2015 15:34:45 GMT Premier Samedi : février 2015 http://premier-samedi.org/premier-samedi/fevrier-2015-3/ https://premier-samedi.org/?p=1467 Date : samedi28 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 28 février 2015 au Carrefour Numérique de la Cité des Sciences et […]]]> premier samedi Sat, 21 Feb 2015 13:36:00 GMT Matthieu Saulnier : Raccordement de Seeks à Tor https://casperlefantom.net/index.php?post/2015/02/21/Raccordement-de-Seeks-%C3%A0-Tor urn:md5:269bba53b0147ada86e929e8a14ad542

J'ai commencé à connecter mes services au réseau de la fibre optiqueTor. Le méta-moteur de recherche Seeks qui tourne sur mon serveur est désormais joignable de bout-en-bout dans le réseau Tor. Pour y accèder il faut aller à l'adresse de mon serveur qui n'a pas changé depuis le précédent billet : d72vewh3wa4lwpaj.onion/seeks.html. Ce n'est pas la peine d'utiliser le protocole HTTPS puisque les traffics en clair ont lieu sur l'interface localhost (connexion du routeur Tor à Apache qui fait reverse proxy avec Seeks), du coup le certificat est bidon, c'est le localhost.crt auto-signé. Pour cette raison, je ne vais pas émettre de certificats pour les domaines .onion avec mon autorité de certification. Mes domaines accepteront les connexions HTTPS mais présenteront tous le même certificat (celui par défaut, le localhost.crt créé automatiquement à l'installation d'un serveur Fedora et auto-signé).

]]>
Seeks
Sat, 21 Feb 2015 09:26:39 GMT Premier Samedi : février 2015 http://premier-samedi.org/premier-samedi/fevrier-2015-2/ https://premier-samedi.org/?p=1464 Date : samedi21 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 21 février 2015 au Carrefour Numérique de la Cité des Sciences et […]]]> premier samedi Fri, 20 Feb 2015 06:31:00 GMT Remi Collet : PHP version 5.4.38, 5.5.22 et 5.6.6 http://blog.famillecollet.com/post/2015/02/20/PHP-version-5.4.38-5.5.22-et-5.6.6 urn:md5:d30e7d2cc38b0ef9e3ced82b5978546d

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)

]]>
RPM
Sat, 14 Feb 2015 08:31:00 GMT Remi Collet : PHPUnit 4.5 http://blog.famillecollet.com/post/2015/02/14/PHPUnit-4.5 urn:md5:d703bfa2dc1de2c18f8e48d4d634d13d

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.

]]>
RPM
Fri, 13 Feb 2015 16:03:00 GMT Patrice Kadionik : Linux Temps Réel sur ARM AT91RM9200. Séance 1 : présentation de la carte http://eddy33.eddy33.free.fr/weblog/index.php?post/2015/02/13/Linux-Temps-R%C3%A9el-sur-carte-ARM-AT91RM9200.-S%C3%A9ance-1-%3A-pr%C3%A9sentation-de-la-carte urn:md5:00f656ff9d389416d3dc8a7110b89b54

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...

++

]]>
Embedded
Wed, 11 Feb 2015 11:40:00 GMT Patrice Kadionik : Fedora 21 vs Fedora 20 : comparaison des performances pour les versions 32 bits http://eddy33.eddy33.free.fr/weblog/index.php?post/2015/02/11/Fedora-21-vs-Fedora-20-%3A-comparaison-des-performances-pour-les-versions-32-bits urn:md5:f6009e36ea9f9c3518c0b27a75c0b3cd

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
Sat, 07 Feb 2015 07:05:00 GMT Patrice Kadionik : Fedora 20 vs Fedora 19 : comparaison des performances pour les versions 32 bits http://eddy33.eddy33.free.fr/weblog/index.php?post/2015/02/06/Fedora-20-vs-Fedora-19-%3A-comparaison-des-performances-pour-les-versions-32-bits urn:md5:86183b02190b6e7e96a25d42132ccb69

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
Fri, 06 Feb 2015 07:31:00 GMT Patrice Kadionik : Fedora 19 vs Fedora 18 : comparaison des performances pour les versions 32 bits http://eddy33.eddy33.free.fr/weblog/index.php?post/2015/02/04/Fedora-19-vs-Fedora-18-%3A-comparaison-des-performances-pour-les-versions-32-bits urn:md5:a05a0ed3cb802830a86253080bbb6fd4

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.


++]]>
Fedora
Mon, 26 Jan 2015 09:49:00 GMT Matthieu Saulnier : Toggle proxy https://casperlefantom.net/index.php?post/2015/01/25/Toggle-proxy urn:md5:50e36aabba2bc1767729495c3fa580e2

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.

]]>
Extention
Sun, 25 Jan 2015 12:04:00 GMT Matthieu Saulnier : À Tor ou à raison https://casperlefantom.net/index.php?post/2015/01/21/%C3%80-Tor-ou-%C3%A0-raison urn:md5:d89c382771b68ba5d07e1a17d531a3bc

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.

]]>
réseaux
Fri, 23 Jan 2015 14:43:00 GMT Matthieu Saulnier : Upgrade du serveur https://casperlefantom.net/index.php?post/2015/01/22/Upgrade-du-serveur urn:md5:56cbda10c03d096b566ff4b8b86e46a5

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...

]]>
Bugzilla
Fri, 23 Jan 2015 06:20:00 GMT Remi Collet : PHP version 5.4.37, 5.5.21 et 5.6.5 http://blog.famillecollet.com/post/2015/01/23/PHP-version-5.4.37-5.5.21-et-5.6.5 urn:md5:cae0e1525d0457643fa6f504473d49dc

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)

]]>
RPM
Thu, 22 Jan 2015 10:43:00 GMT Matthieu Saulnier : Et si on enlève Javascript https://casperlefantom.net/index.php?post/2015/01/21/Et-si-on-enl%C3%A8ve-Javascript urn:md5:6cc8c19fa4b9a91c6239b09a01ef8959

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é.

]]>
Firefox
Thu, 22 Jan 2015 08:04:09 GMT Thomas Bouffon : find : exécuter des commandes complexes avec l'option -exec http://www.thomasbouffon.fr/fr/blog/57-find-executer-des-commandes-complexes-avec-l-option-exec http://www.thomasbouffon.fr/fr/blog/57-find-executer-des-commandes-complexes-avec-l-option-exec

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

]]>
Blog
Wed, 21 Jan 2015 11:22:00 GMT Matthieu Saulnier : linux_logo pour f21 https://casperlefantom.net/index.php?post/2015/01/21/linux_logo-pour-f21 urn:md5:e9202446343963d507c9c7b30785f32c 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 ?
]]>
ascii art
Fri, 09 Jan 2015 10:38:18 GMT Thomas Bouffon : Memo : rationaliser l'utilisation du wifi sous CyanogenMod http://www.thomasbouffon.fr/fr/blog/56-memo-rationaliser-l-utilisation-du-wifi-sous-cyanogenmod http://www.thomasbouffon.fr/fr/blog/56-memo-rationaliser-l-utilisation-du-wifi-sous-cyanogenmod

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é.

]]>
Blog
Fri, 09 Jan 2015 09:32:00 GMT Remi Collet : PHP version 5.5.21RC1 et 5.6.5RC1 http://blog.famillecollet.com/post/2015/01/09/PHP-version-5.5.21RC1-et-5.6.5RC1 urn:md5:90d44bf8e42778676b4a7ca94adc9e31

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)

]]>
RPM
Thu, 08 Jan 2015 14:07:00 GMT Edouard Bourguignon : Interdiction par défaut de se connecter en root via ssh pour Fedora 22 http://www.linuxed.net/post/2015/01/08/Interdiction-par-d%C3%A9faut-de-se-connecter-en-root-via-ssh-pour-Fedora-22 urn:md5:832c1eefbc3de937ddd272b8a636dd92

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.

]]>
Fedora