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.

Pidora

Fedora Tunisia

Pidora is a Linux software distribution for the Raspberry Pi computer. It contains software packages from the Fedora project compiled for the ARMv6 architecture used on the Raspberry Pi, packages which have been specifically written for or modified for the Raspberry Pi, and software provided by the Raspberry Pi Foundation for device access.

read more

Dotclear 2.6

Remi Collet

Ça y est ! La dernière version de Dotclear est installée.

Migration en douceur, aucun problème. Comme d'habitude, j'ai simplement appliqué le patch. Non, je n'utilise pas la fonction intégrée de MAJ qui nécessite des réglages à l'encontre des règles de sécurité.

Mon thème fonctionne parfaitement.

Au revoir free.fr

Thomas Bouffon
MacBook:~ thomas$ time nslookup mail.yahoo.com 
Server: 212.27.40.241
Address: 212.27.40.241#53

Non-authoritative answer:
mail.yahoo.com canonical name = login.yahoo.com.
login.yahoo.com canonical name = login-global.lgg1.b.yahoo.com.
login-global.lgg1.b.yahoo.com canonical name = eulogin.lga1.b.yahoo.com.
eulogin.lga1.b.yahoo.com canonical name = eu-eulogin.lga1.b.yahoo.com.
Name: eu-eulogin.lga1.b.yahoo.com
Address: 188.125.82.242
Name: eu-eulogin.lga1.b.yahoo.com
Address: 217.146.187.123


real 0m2.350s
user 0m0.005s
sys 0m0.005s

Plus de 2 socondes ? Ce n'est plus un DNS, c'est un annuaire papier !?
Pour comparaison :

MacBook:~ thomas$ time nslookup mail.yahoo.com  8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
mail.yahoo.com canonical name = login.yahoo.com.
login.yahoo.com canonical name = login-global.lgg1.b.yahoo.com.
login-global.lgg1.b.yahoo.com canonical name = login.lga1.b.yahoo.com.
Name: login.lga1.b.yahoo.com
Address: 98.139.237.162


real 0m0.048s
user 0m0.005s
sys 0m0.005s

décembre 2013

Premier Samedi Date : samedi 7 décembre 2013 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 décembre 2013 au Carrefour Numérique de la Cité des Sciences […]

Plusieurs versions de PHP sur un serveur Apache 2.4

Remi Collet

Pour illustrer ma conférence Introduction aux Software Collections, j'ai fait la démonstration sur l'utilisation d'un frontal Apache fonctionnant simultanément avec 3 versions de PHP (5.3, 5.4 et 5.5).

Gros plan sur cette mise en oeuvre très simple sur RHEL 6 ou CentOS 6.

J'ai évidement utiliser les paquets disponibles en SCL sur le site du projet SoftwareCollections, en particulier les collections httpd24, php54 et php55.

Installation du dépôt RHSCL 1.0 sur RHEL-6 (pour php54)

rhn-channel --add --channel=rhel-x86_64-server-6-rhscl-1

Installation du dépôt php54 sur CentOS-6

wget http://people.redhat.com/rcollet/php54/rhel-php54.repo -O /etc/yum.repos.d/php54.repo

Installation du dépôt httpd24 :

wget http://repos.fedorapeople.org/repos/jkaluza/httpd24/epel-httpd24.repo -O /etc/yum.repos.d/httpd24.repo

Installation du dépôt php55 :

wget http://people.redhat.com/rcollet/php55/rhel-php55.repo -O /etc/yum.repos.d/php55.repo

Installation des paquets Apache 2.4.6, PHP 5.3.3, 5.4.16 et 5.5.5 :

yum install httpd24 php54 php54-php-fpm php55 php55-fpm php-fpm

Comme les 3 versions de php-fpm sont configurées pour écouter sur le port 9000, modifions cela :

sed -e 's/9000/9002/' -i /opt/rh/php54/root/etc/php-fpm.d/www.conf
semanage port -a -t http_port_t -p tcp 9002

sed -e 's/9000/9003/' -i /opt/rh/php55/root/etc/php-fpm.d/www.conf
semanage port -a -t http_port_t -p tcp 9003

Configuration d'apache pour qu'il demande l'exécution des scripts PHP à FPM en fonction de la version, en créant le fichier /opt/rh/root/etc/httpd/conf.d/fpm.conf

#   PHP script executed by FPM backend
ProxyPassMatch ^/php53/(.*\.php)$ fcgi://127.0.0.1:9000/srv/website
# Other static stuff
Alias /php53 /srv/website

ProxyPassMatch ^/php54/(.*\.php)$ fcgi://127.0.0.1:9002/srv/website
Alias /php54 /srv/website

ProxyPassMatch ^/php55/(.*\.php)$ fcgi://127.0.0.1:9003/srv/website
Alias /php55 /srv/website

J'ai choisi de rediger les 3 URL vers le même dossier, car mon objectif est de tester la même application avec les différentes versions de PHP.

J'aurais aussi pu configurer 3 hôtes virtuels.

Installons notre application préférée:

mkdir /srv/website
echo '<?php phpinfo()' >/srv/website/info.php

Démarrage des services

service httpd24-httpd start
service php-fpm start
service php54-php-fpm start
service php55-php-fpm start

Il ne reste plus qu'à profiter : http://localhost/php53/info.php ou http://localhost/php54/info.php ou http://localhost/php55/info.php

A noter, il s'agit d'une configuration simpliste, destinée a un développeur désirant faire des tests. Elle nécessiterait d'être améliorée pour une utilisation en production, mais le principe reste le même.

Nouvelle machine pour 2014, 2015...

Remi Collet

Ma nouvelle machine est quasi opérationnelle :

Problème ennuyant, mon SSD ne fonctionne pas correctement (visible aléatoirement par le BIOS), je vais devoir en changer.

Première mise à l'épreuve, la compilation de Firefox 25 passe de 45' à 25'. Cool.

Je prévois donc rapidement de l'étendre avec

  • Un nouveau SSD
  • 16G de mémoire

Merci à tous ceux qui veulent participer, voir la page Merci/Thanks.

Mon ancienne machine sera utilisée par mes enfants.

La copie cachée, c'est mal ! Mais pas forcément pour ce qu'on croit

Thomas Bouffon
J'ai souvent entendu que la copie cachée n'était pas une bonne pratique, mais souvent pour des raisons qui ne m'ont pas convaincu.

Pour rappel, la copie cachée (en anglais BCC ou blind carbon copy) permet de mettre en copie des destinataires supplémentaires qui seront invisibles des destinataires originaux.
 
Ce que j'ai entendu le plus souvent me paraissaint loin de la logique : si le destinataire original d'un message avec destinataires supplémentaires en BCC répondait, il répondrait, sans le savoir, à tous les destinataires, incluant les destinataires cachés. Ce qui semble surprenant, car pour que les destinataires soient cachés, il ne peuvent pas apparaître dans les entêtes du mail reçu, et ainsi le client mail du destinataire n'a aucun moyen de mettre en copie les destinataires cachés.
 
J'ai donc entrepris quelques recherches sur le web pour démonter cet argument... Pour me rendre compte qu'il était valable !
Effectivement, certains serveurs ou clients de mails peuvent être mal fichus et ne pas enlever le champ BCC, exposant la liste des destinataires (voir la RFC-2821 ou ce papier sur stanford.edu). Le problème, c'est que ceci est valable pour l'utilisation "liste de diffusion" du BCC (uniquement des destinataires cachés, ce qui fait apparaître "undisclosed recipients") largement répandue. Heureusement, cela concerne des systèmes anciens.
 
Cependant, le risque principal est surtout pour une personne en BCC : si jamais elle clique malencontreusement sur "répondre à tous", le destinataire original découvrira qu'il y avait des personnes en BCC.
Ces 2 points indiquent que c'est surtout les destinataires en copie cachée qui peuvent pâtir de son utilisation.

Enfin, l'émetteur d'un email avec des destinataires en BCC apparaîtra aux yeux des destinataires cachés comme "le genre de personne qui écrit des mails avec copie cachée"
 
En revanche, sur le fond, utiliser la copie cachée ne diffère en rien du transfert d'un mail envoyé sans en avertir le destinataire orginal, pratique largement répandue.

En résumé,

  • il ne faut pas utiliser la copie cachée car c'est dangereux pour les personnes en copie cachée
  • il ne faut ni utiliser la copie cachée, ni transférer de mails sans en avertir les correspondants originaux parce que c'est mal. Mais ça n'a pas de rapport technique avec la copie cachée.
 

Thunderbird 24

Remi Collet

Le RPM de la nouvelle version du client de messagerie de la Fondation Mozilla est disponible dans le dépôt remi pour fedora 16, 17 et enterprise linux 6 (rétro-portage de la version F-20).

Commencez par lire :

Comme toujours :

yum --enablerepo=remi update thunderbird\*

L'extension enigmail (version 1.6) est aussi disponible.

Les RPM de la version 24.1.0 sont disponibles ici pour fedora 14 (x86_64), 16, 17, et pour enterprise linux 6 (et dans les dépôt officiels pour fedora ≥ 18)

Pour Enterprise Linux 6, la construction utilise python27 (Red Hat Software Collections 1) et devtoolset-2 pour gcc 4.8.1 (Red Hat Developer Toolset 2) (uniquement pour la construction, inutile par la suite). Cela corrige le problème qui bloquait la disponibilité de Thunderbird 24.

thunderbird-enigmail-1.6

Remi Collet

Le RPM de l'extension Enigmail version 1.6 pour Thunderbird ≥ 24 est disponible dans le dépôt remi pour fedora 16 et 17, pour Enterprise Linux 6 et dans les dépôts officiels pour fedora ≥ 18.

Installation

yum --enablerepo=remi  install  thunderbird-enigmail

Ou, dans les dépôts officiels : thunderbird-enigmail

Cette extension est, pour moi, un partenaire indispensable de Thunderbird, car elle intègre un système complet de gestion des clés OpenPGP ainsi que les outils pour signer, vérifier, crypter, décrypter les messages.

Quand vous envoyez aujourd'hui un courrier postal, vous utilisez une enveloppe, un recommandé, ou une carte postale en fonction de la nature du contenu. Considérez que OpenPGP est une forme d'enveloppe.

Avec la très forte pression actuelle sur notre vie privée, il me semble urgent de généraliser l'utilisation de ces outils.

Pour Enterprise Linux 6, la construction utilise python27 (Red Hat Software Collections 1) et devtoolset-2 pour gcc 4.8.1 (Red Hat Developer Toolset 2) (uniquement pour la construction, inutile par la suite).

Les RPM sont disponibles dans le dépôt remi pour Fedora 14 (x86_64), 16 et 17 et pour Enterprise Linux 6 ainsi que dans les dépôts officiels : thunderbird-enigmail


L'empreinte de ma clé OpenGPG personnelle est

 5A0E 6F54 D94D 5732 69EE  E3FF 614A 6905 29F1 6A18

En Iran, Red Hat et Pizza Hut fusionnent :)

Thomas Bouffon

Vu dans un article sur buzzfeed sur les copies de franchises en iran :

Trop fort !

Firefox 25

Remi Collet

Les RPM de la nouvelle version du navigateur de la Mozilla Foundation sont disponibles dans le dépôt remi pour Fedora 16, 17 et Enterprise Linux 6 (RHEL, CentOS, ...).

A lire : Mozilla Firefox Release Notes (notes de version, en anglais)

Installation :
yum --enablerepo=remi update firefox
Ce paquet utilise xulrunner-last, qui s'installe à côté de celui par défaut.

Remarque : ce RPM est très proche de celui de Firefox 25 qui sera présent dans Fedora 20.

Pour Enterprise Linux 6, la construction utilise python27 (Red Hat Software Collections 1) et devtoolset-2 pour gcc 4.8.1 (Red Hat Developer Toolset 2) (uniquement pour la construction, inutile par la suite).

Les RPM sont disponibles pour Fedora 14, 15 (x86_64), 16 et 17 et pour Enterprise Linux 6.

Migration sous Fedora 20 via FedUp

Guillaume Kulakowski

Après mon PC portable, c'est au tour de ma station de travail de passer sous Fedora 20 alpha. Et avec FedUp, c'est simple :

1. Lancement de la migration via FedUp :

fedora-upgrade --network 20

Attention : si vous n'avez pas assez d'espace, vous allez saturer votre /var/tmp ! Ma solution : je fais un lien symbolique de /var/tmp/fedora-upgrade sur mon bureau.

2. Reboot.

3. Nettoyage de FedUp :

fedora-upgrade --clean

4. Mise à jour :

yum clean all
yum update

5. Ensuite un peu de ménage, on force la mise à jour de ce qu'il pourrait subsister en f19 :

rpm -qa --qf "%{NAME}@%{release}\n" | grep fc19 | cut -d'@' -f1 | sort| tee list
yum reinstall $(cat list)

6. Et on contrôle :

package-cleanup --problems
package-cleanup --dupes

7. Pour finir on joue avec ll /etc/**.rpmnew (je suis en ZSH) et diff pour contrôler les nouvelles options des fichiers de configurations.

novembre 2013

Premier Samedi Date : samedi 2 novembre 2013 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 2 novembre 2013 au Carrefour Numérique de la Cité des Sciences […]

novembre 2013

Premier Samedi Date : samedi 2 novembre 2013 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 2 novembre 2013 au Carrefour Numérique de la Cité des Sciences […]

ETickets4Hikashop-1.0.5 : Correction de bug PayPal, régime sec et fin des debugs sauvages

Thomas Bouffon

Après que ETickets4Hikashop ait cessé de fonctionner avec PayPal, j'ai pas mal cherché et ai finalement corrigé le bug.

Voici donc ETickets4Hikashop-1.0.5, qui :

  • corrige le bug PayPal
  • ne pèse plus que 1.7 Mo contre 12 auparavant (au prix de la suppression de toutes le polices TCPDF sauf Helvetica et Courier
  • ne logge plus rien par défaut, et si on modifie $this->debug dans etickets.php, écrit proprement dans logs/plg_hikashop_etickets.errors.php

Au passage, j'ai remis sur pied et à jour le site de démo, sur lequel vous pouvez commander des billets gratuits pour voir le coté client, et même un billet  2 euros pour essayer le paiement PayPal. Mais attention, si vous allez au bout, vous m'offres une bière ;)

PHP 5.4.21 et 5.5.5

Remi Collet

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

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

Attention Attention : PHP 5.5 est désormais dans le nouveau dépôt remi-php55 au lieu de remi-test pour Enterprise Linux et a remplacé PHP 5.4 dans le dépôt remi pour Fedora ≤ 18.

Annonces des versions :

Installation de PHP 5.5

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

Installation de PHP 5.4

yum --enablerepo=remi update php\*

Et bientôt dans les mises à jour officielles:

À noter :

  • php-oci8 utilise désormais les clients Oracle version 12.1
  • pour php 5.5, l'extension Zip est désormais fournit dans le paquet php-pecl-zip.
  • beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

Informations, lire :

Les fonctionnalités attendues pour la Fedora 20

Edouard Bourguignon

Les fonctionnalités attendues pour la Fedora 20 Heisenbug, qui doit sortir en cette fin d'année, sont les suivantes:

Environnements graphiques

GNOME 3.10

La version alpha de la Fedora 20 propose une préversion de Gnome 3.10, la version 3.9.90. Gnome 3.10 proposera de nouvelles applications et fonctionnalités, comme gnome-music, gnome-map, une refonte du menu de status, et le support Zimbra dans Evolution.

Il y aura aussi un support préliminaire de Wayland, même si ce dernier ne sera pas dans les paquets par défaut. La couche Wayland étant un potentiel remplacant du serveur graphique ancestral X11.

KDE Plasma Workspaces 4.11

La Fedora 20 apportera KDE 4.11, qui inclut certaines évolutions, comme un indexage plus rapide avec Nepomuk, l'amélioration de Kontact, l'intégration de KScreen dans KWin, le support des metalinks/HTTP dans KGet et bien d'autres encore.

Architecture ARM

L'architecture ARM devient officiellement supportées. J'en ai déjà parlé ici. Voir aussi ce que ça apporte dans les sujets liés à la virtualisation.

Améliorations sur NetworkManager

Le CLI pour manipuler facilement ces connexions en ligne de commande s'améliore. Il sera possible via nmcli d'ajouter, éditer, supprimer, activer et desactiver des connexions réseaux. Pratique pour ceux qui ne veulent pas user leur souris.

NetworkManager supportera aussi les aggrégats de cartes réseaux (bonding) ainsi que les ponts ethernet (bridge). Des solutions déjà courament utilisées en entreprise, pour la haute disponibilité, ou encore la virtualisation. Vivement cette intégration dans RedHat Entreprise Linux (ou CentOS) du coup.

Plus de sendmail ou syslog par défaut

Certains services que certains pouvaient trouvés inutiles ne seront plus installés par défaut. Ils restent bien sûr possible de les installer à posteriori.

Cela concerne tout d'abord sendmail, car il n'est en effet plus nécessaire sur un poste de travail d'avoir un serveur de messagerie (MTA).

Syslog est aussi touché, vu que systemd peut prendre en charge la journalisation des évènements système (log).

Amélioration de la virtualisation

Fedora toujours à la pointe sur ce sujet:

  • Support du LVM Thin Provisionning dans l'installeur, améliorant aussi les fonctionnalités de snapshots.
  • virt-manager supporte les snapshots/checkpoints des machines virtuelles.
  • Contrôle d'accès basé sur des rôles pour la Libvirt.
  • ARM sur x86 avec la libvirt, virt-install et virt-manager.

Pour les développeurs

A noter:

  • Ruby on Rails 4.0
  • Perl 5.18

Réseaux GRE avec routage OSPF

Edouard Bourguignon

Objectifs

Etablir un réseau maillé (mesh) avec des liaisons GRE. Les tables de routage seront découvertes automatiquement via le protocole OSPF (Open Shortest Path First).

Donc dans un premier temps, configurer les liaisons GRE. Dans un second temps, configurer les démons ospfd pour la partie routage.

Topologie de la maquette

Il s'agit d'une version étendue de celle utilisée pour l'article sur la configuration d'un tunnel GRE simple. Au lieu d'avoir 2 réseaux distincts, nous en avons cette fois 4.

Les 4 réseaux A, B, C, D possède un identifiant qui leur a été attribué de manière arbitraire, pour simplifier les plans d'adressage:

  • Le réseau A => 16
  • Le réseau B => 22
  • Le réseau C => 227
  • Le réseau D => 13

Pour faire simple là aussi, ces différents réseaux sont reliés entre eux par un accès WAN sur une plage d'adresse unique en 192.168.122.X. X est remplacé par l'identifiant du réseau.

Chaque réseau possède des clients utilisant une plage d'adresse privée du style 192.168.X.0/24 où X est là aussi remplacé par l'idéntifiant du réseau.

Ce qui nous donne au final:

  • Réseau A Adresse WAN 192.168.122.16 avec réseau clients 192.168.16.0/24
  • Réseau B Adresse WAN 192.168.122.22 avec réseau clients 192.168.22.0/24
  • Réseau C Adresse WAN 192.168.122.227 avec réseau clients 192.168.227.0/24
  • Réseau D Adresse WAN 192.168.122.13 avec réseau clients 192.168.13.0/24

Toujours pour simplifier, l'adresse IP du serveur OpenBSD gérant le tunnel, et faisant office de passerelle, est sous la forme 192.168.X.254.

Bref voir le schéma suivant:

Gre 4 reseaux

En fonction de la fiabilité des liens entre les différents réseaux, il est possible de ne faire que seulement 2 liens entre chaque site, pour assurer la tolérance de panne. Pour que ce soit un vrai réseau maillé, pour N noeuds, chaque N doit avoir N-1 connexions. Donc dans notre cas, 3 connexions. Celles-ci seront numérotées arbitrairement pour faciliter encore une fois la configuration, voir le schéma suivant:

Gre 4 MESH

Il n'y a pas non plus de logique dans l'attribution des adresses IP des extrémités des tunnels, j'aurais pu opter pour un adressage du style 172.16.numero_tunnel.identifiant_réseau... Peut être la prochaine fois ;)

Ce numéro de tunnel est aussi repris dans la numérotation des interfaces GRE.

Pré-requis

Il s'agit des mêmes pré-requis que pour la configuration d'un tunnel GRE simple.

Pare-feu

Dans un premier temps, pour faciliter la mise en oeuvre, n'appliquons aucun filtrage sur les interfaces GRE.

Sur tun.a

Ajouter les lignes suivantes dans le début du fichier /etc/pf.conf:

set skip on gre0
set skip on gre1
set skip on gre2

OSPF

Sur tun.b

Ajouter les lignes suivantes dans le début du fichier /etc/pf.conf:

set skip on gre0
set skip on gre3
set skip on gre4
Sur tun.c

Ajouter les lignes suivantes dans le début du fichier /etc/pf.conf:

set skip on gre1
set skip on gre3
set skip on gre5
Sur tun.d

Ajouter les lignes suivantes dans le début du fichier /etc/pf.conf:

set skip on gre2
set skip on gre4
set skip on gre5

Autorisation des tunnels GRE

Pour autoriser au niveau du noyau les tunnels de type GRE, il faut ajouter sur l'ensemble des serveurs, la ligne suivante dans /etc/sysctl.conf:

net.inet.gre.allow=1

Et pour l'appliquer immédiatement, taper la commande suivante:

# sysctl -w net.inet.gre.allow=1

Autorisation du routage

Pour activer le routage IP, il faut ajouter sur l'ensemble des serveurs la ligne suivante dans /etc/sysctl.conf:

net.inet.ip.forwarding=1

Et pour l'appliquer immédiatement, taper la commande suivante:

# sysctl -w net.inet.ip.forwarding=1

Configuration des tunnels GRE

La configuration des 3 liaisons est effectuées sur chaque serveur. Il n'y a aucune information sur le routage à ce niveau.

Sur tun.a

Configuration de la liaison gre0

Contenu du fichier de configuration /etc/hostname.gre0:

172.16.0.2 172.16.0.1 netmask 0xffffffff link0 up
tunnel 192.168.122.16 192.168.122.22
Configuration de la liaison gre1

Contenu du fichier de configuration /etc/hostname.gre1:

172.16.1.2 172.16.1.1 netmask 0xffffffff link0 up
tunnel 192.168.122.16 192.168.122.227
Configuration de la liaison gre2

Contenu du fichier de configuration /etc/hostname.gre2:

172.16.2.2 172.16.2.1 netmask 0xffffffff link0 up
tunnel 192.168.122.16 192.168.122.13

Sur tun.b

Configuration de la liaison gre0

Contenu du fichier de configuration /etc/hostname.gre0:

172.16.0.1 172.16.0.2 netmask 0xffffffff link0 up
tunnel 192.168.122.22 192.168.122.16
Configuration de la liaison gre3

Contenu du fichier de configuration /etc/hostname.gre3:

172.16.3.1 172.16.3.2 netmask 0xffffffff link0 up
tunnel 192.168.122.22 192.168.122.227
Configuration de la liaison gre4

Contenu du fichier de configuration /etc/hostname.gre4:

172.16.4.1 172.16.4.2 netmask 0xffffffff link0 up
tunnel 192.168.122.22 192.168.122.13

Sur tun.c

Configuration de la liaison gre1

Contenu du fichier de configuration /etc/hostname.gre1:

172.16.1.1 172.16.1.2 netmask 0xffffffff link0 up
tunnel 192.168.122.227 192.168.122.16
Configuration de la liaison gre3

Contenu du fichier de configuration /etc/hostname.gre3:

172.16.3.2 172.16.3.1 netmask 0xffffffff link0 up
tunnel 192.168.122.227 192.168.122.22
Configuration de la liaison gre5

Contenu du fichier de configuration /etc/hostname.gre5:

172.16.5.1 172.16.5.2 netmask 0xffffffff link0 up
tunnel 192.168.122.227 192.168.122.13

Sur tun.d

Configuration de la liaison gre2

Contenu du fichier de configuration /etc/hostname.gre2:

172.16.2.1 172.16.2.2 netmask 0xffffffff link0 up
tunnel 192.168.122.13 192.168.122.16
Configuration de la liaison gre4

Contenu du fichier de configuration /etc/hostname.gre4:

172.16.4.2 172.16.4.1 netmask 0xffffffff link0 up
tunnel 192.168.122.13 192.168.122.22
Configuration de la liaison gre5

Contenu du fichier de configuration /etc/hostname.gre5:

172.16.5.2 172.16.5.1 netmask 0xffffffff link0 up
tunnel 192.168.122.13 192.168.122.227

Sur l'ensemble des serveurs

Pour activer les connexions GRE:

# sh /etc/netstart

Elles sont de toute façon activées par défaut au démarrage.

Configuration du démon OSPF

Il s'agit ici d'une configuration très simple permettant d'indiquer sur quelles interfaces le protocole OSPF doit opérer. L'interface indiquée comme passive permet à OSPFd de connaitre le reseau de cette dernière, sans faire d'annonce sur celle-ci. Les démons OSPFd dans notre cas ne peuvent en effet communiquer que via les tunnels GRE.

Sur notre maquette, l'interface reliée au réseau privé est em0.

Sur tun.a

Contenu du fichier /etc/ospfd.conf:

auth-md 1 "secret"
auth-type crypt
auth-md-keyid 1
area 0.0.0.0 {
       interface gre0 {}
       interface gre1 {}
       interface gre2 {}
       interface em0 { passive }
}

Sur tun.b

Contenu du fichier /etc/ospfd.conf:

auth-md 1 "secret"
auth-type crypt
auth-md-keyid 1
area 0.0.0.0 {
       interface gre0 {}
       interface gre3 {}
       interface gre4 {}
       interface em0 { passive }
}

Sur tun.c

Contenu du fichier /etc/ospfd.conf:

auth-md 1 "secret"
auth-type crypt
auth-md-keyid 1
area 0.0.0.0 {
       interface gre1 {}
       interface gre3 {}
       interface gre5 {}
       interface em0 { passive }
}

Sur tun.d

Contenu du fichier /etc/ospfd.conf:

auth-md 1 "secret"
auth-type crypt
auth-md-keyid 1
area 0.0.0.0 {
       interface gre2 {}
       interface gre4 {}
       interface gre5 {}
       interface em0 { passive }
}

Sur l'ensemble des serveurs

Pour activer le démon ospfd par défaut au démarrage, il faut modifer le fichier /etc/rc.conf pour modifier la ligne:

ospfd_flags=NO

en

ospfd_flags=""

Validation

Une fois tous les tunnels montés, et les services ospfd démarrés, ceux-ci devraient commencer à faire leurs découvertes sur les réseaux. Les routes seront échangées entre les différents démons via les annonces OSPF, constituant une base d'information de routage (ou RIB pour Routing Information Base). Pour consulter la RIB sur un serveur:

$ ospfctl show rib

Exemple sur la machine tun.a:

$ ospfctl show rib                                                                                                   
Destination          Nexthop           Path Type    Type      Cost    Uptime  
172.16.0.2/32        172.16.0.1        Intra-Area   Network   20      00:57:36
172.16.1.2/32        172.16.1.1        Intra-Area   Network   20      01:19:58
172.16.2.2/32        172.16.2.1        Intra-Area   Network   20      01:19:39
172.16.3.1/32        172.16.1.1        Intra-Area   Network   20      00:57:57
172.16.3.2/32        172.16.0.1        Intra-Area   Network   20      00:57:36
172.16.4.1/32        172.16.2.1        Intra-Area   Network   20      01:19:39
172.16.4.2/32        172.16.0.1        Intra-Area   Network   20      00:57:36 
172.16.5.1/32        172.16.2.1        Intra-Area   Network   20      01:19:27
172.16.5.2/32        172.16.1.1        Intra-Area   Network   20      01:19:33
192.168.13.0/24      172.16.2.1        Intra-Area   Network   20      01:19:39
192.168.22.0/24      172.16.0.1        Intra-Area   Network   20      00:57:36
192.168.227.0/24     172.16.1.1        Intra-Area   Network   20      01:19:58

A noté que le réseau 192.168.16.0/24 (réseau A) n'apparait pas vu qu'il s'agit du réseau local de la machine tun.a. Cette RIB nous informe que les démons ospfd a trouvé des routes pour les réseaux distants qui nous interessent, à savoir:

  • 192.168.13.0/24 (réseau D)
  • 192.168.22.0/24 (réseau B)
  • 192.168.227.0/24 (réseau C)

Un poids ou coût de 20 leur a été attribué.

Coupons maintenant la liaison GRE (numéro 0) entre tun.a et tun.b, en executant sur tun.b la commande suivante:

# ifconfig gre0 down

Regardons toujours sur tun.a, la RIB (les lignes inutiles sont masquées):

192.168.13.0/24      172.16.2.1        Intra-Area   Network   20      01:26:07
192.168.22.0/24      172.16.2.1        Intra-Area   Network   30      00:00:13
192.168.22.0/24      172.16.1.1        Intra-Area   Network   30      00:00:13
192.168.227.0/24     172.16.1.1        Intra-Area   Network   20      01:26:26

Le réseau B 192.168.22.0/24 n'est plus annoncé comme accessible via 172.16.0.1 (tun.a) mais par 2 nouvelles routes 172.16.2.1 (tun.d) et 172.16.1.1 (tun.c). Cela montre bien que la route défectueuse est contournée. Ce qui est confirmé par l'augmentation du coût de ces routes (30 au lieu de 20).

Coupons maintenant la liaison GRE (numero 2) entre tun.a et tun.d, voici la RIB:

192.168.13.0/24      172.16.1.1        Intra-Area   Network   30      00:00:09
192.168.22.0/24      172.16.1.1        Intra-Area   Network   30      00:04:56
192.168.227.0/24     172.16.1.1        Intra-Area   Network   20      01:31:09

Une route vers 192.168.22.0/24 a bien disparue.

Coupons maintenant la liaison GRE (numero 3) entre tun.c et tun.d, voici la RIB:

192.168.13.0/24      172.16.1.1        Intra-Area   Network   30      00:00:41
192.168.22.0/24      172.16.1.1        Intra-Area   Network   40      00:05:28
192.168.227.0/24     172.16.1.1        Intra-Area   Network   20      01:31:41

La route vers 192.168.22.0/24 est toujours disponible, mais a un coût elevée (40), vu que de tun.a, nous passons par tun.c puis tun.d pour joindre tun.b. Donc malgré 3 coupures notre réseau est toujours fonctionnel, du moment qu'un site possède toujours au moins 1 connexion GRE.

Introduction aux Software Collections

Remi Collet

Dans le cadre l'Open Source Developers' Conference 2013 (Open World Forum 2013), j'ai pu présenter une conférence Introduction aux Software Collections.

Je pense que le sujet a intéressé les personnes présentes et j'ai pu discuté et répondre à de nombreuses questions sur les SCL sur les stands Fedora et Red Hat.

La présentation (en anglais) est disponible : Software Collections Introduction

La démonstration d'un serveur RHEL-6 avec Apache 2.4 en avant et 3 services FPM (PHP 5.3, 5.4 et 5.5) en arrière m'a semble intéressante pour démontrer l'utilité et la simplicité des SCL.

La conférence a été filmée, je posterai dès que possible, le lien.

Tunnel GRE sous OpenBSD

Edouard Bourguignon

Objectifs

Permettre de relier 2 réseaux distincts via un tunnel GRE.

Le protocole GRE permet de relier des réseaux IP différents en masquant le ou les réseaux routés intermédiaires. Pour cela un paquet IP d'un reseau A, à destination du réseau B, à l'entrée du tunnel, est encapsulé dans un autre paquet IP pour être transmis via les réseaux intermédaires (ex: internet, réseau WAN etc). Arrivé sur le réseau B, à l'autre bout du tunnel, le paquet IP est désencapsulé et peut reprendre son trajet sur le réseau B. Ainsi sur le réseau B, ce paquet ne porte plus aucune trace d'un transport sur d'autres réseaux intermédiaires.

Attention, par contre, vu qu'il s'agit d'une encapsulation d'IP sur IP, sans autre traitement, les données sont donc transmises en claire. Pour chiffrer les données, et ainsi sécuriser leur transport sur les réseaux intermédiaires, il est possible par exemple d'utiliser IPSec par dessus le tunnel GRE. Cependant, s'il s'agit de faire transiter que des flux déjà chiffrés (ssh, https, etc), GRE garde tout son intérêt, grâce à sa simplicité de mise en oeuvre, et à sa légèreté.

Topologie de la maquette

Plages d'adresses des 2 reseaux à relier:

  • 192.168.16.x pour le réseau A
  • 192.168.22.x pour le réseau B

Le réseau WAN utilisé pour le tunnel possède une plage d'ip en 192.168.122.x.

Le serveur OpenBSD sur le réseau A, appellé tun.a, possède les adresses IP suivantes:

  • 192.168.122.16 sur le réseau WAN
  • 192.168.16.254 sur le réseau A

Le serveur OpenBSD sur le réseau B, appellé tun.b, possède les adresses IP suivantes:

  • 192.168.122.22 sur le réseau WAN
  • 192.168.22.254 sur le réseau B

Voir le schéma suivant:

Tunnel GRE

Pré-requis

Pare-feu

Dans un premier temps, pour faciliter la mise en oeuvre, n'appliquons aucun filtrage sur les interfaces GRE.

Ajouter la ligne suivante, sur les 2 serveurs, dans le début du fichier /etc/pf.conf:

set skip on gre0

Autorisation des tunnels GRE

Pour autoriser au niveau du noyau les tunnels de type GRE, il faut ajouter sur les 2 serveurs, la ligne suivante dans /etc/sysctl.conf:

net.inet.gre.allow=1

Et pour l'appliquer immédiatement, taper la commande suivante:

# sysctl -w net.inet.gre.allow=1

Autorisation du routage

Pour activer le routage IP, il faut ajouter la ligne suivante dans /etc/sysctl.conf:

net.inet.ip.forwarding=1

Et pour l'appliquer immédiatement, taper la commande suivante:

# sysctl -w net.inet.ip.forwarding=1

Configuration

Il s'agit de configurer un tunnel utilisant les adresses suivantes à ses extrémités:

  • 172.16.0.1 sur tun.a
  • 172.16.0.2 sur tun.b

L'interface utilisée pour le tunnel sera nommée gre0 en rapport avec le protocole utilisé GRE.

Sur le serveur tun.a

Contenu du fichier /etc/hostname.gre0

172.16.0.1 172.16.0.2 netmask 0xffffffff link0 up
tunnel 192.168.122.16 192.168.122.22
!route add -net 192.168.22 -netmask 255.255.255.0 172.16.0.2

Sur le serveur tun.b

Contenu du fichier /etc/hostname.gre0

172.16.0.2 172.16.0.1 netmask 0xffffffff link0 up
tunnel 192.168.122.22 192.168.122.16
!route add -net 192.168.16 -netmask 255.255.255.0 172.16.0.1

Validation

Il faut s'assurer que le traffic est bien routé vers l'entrée du tunnel, soit le serveur OpenBSD fait office de passerelle par défaut pour les clients de son réseau, soit il faut ajouter sur ces derniers, une route pour indiquer que les flux vers réseau distant doit passer par le serveur OpenBSD.

Exemple de route à ajouter sur un client Linux du réseau A en 192.168.16.0/24:

# ip route add 192.168.22.0/24 via 192.168.16.254

La même chose pour un client Linux du réseau B en 192.168.22.0/24:

# ip route add 192.168.16.0/24 via 192.168.22.254

Ensuite un simple ping d'un client A vers un client B devrait fonctionner:

[client01.a] $ ping 192.168.22.1
host 192.168.22.1 is alive!

voila!

Exemple de trames interceptées par un tcpdump sur un des serveurs OpenBSD:

12:20:43.026311 FF:FF:00:e8:e7:aa 52:54:00:3f:44:e6 0800 122: gre 192.168.122.16 > 192.168.122.22:  192.168.16.1 > 192.168.22.1: icmp: echo request (id:7e77 seq:243) (ttl 254, id 22932, len 84) (ttl 64, id 30293, len 108)
12:20:43.027113 FF:FF:00:3f:44:e6 52:54:00:e8:e7:aa 0800 122: gre 192.168.122.22 > 192.168.122.16:  192.168.22.1 > 192.168.16.1: icmp: echo reply (id:7e77 seq:243) (ttl 254, id 7409, len 84) (ttl 64, id 33582, len 108)

Ce qui confirme que le ping est bien transmis, et que les trames GRE passent bien en claires, car on voit des paquets GRE entre nos serveurs OpenBSD avec leurs adresses IP du réseau WAN, et à l'intérieur du paquet, les requetes ICMP sur les réseaux A et B.

Page générée le 13 avr 2014 à 22:32