Pour parler de Logiciels Libres en milieu professionnel... ou pas!

Aller au contenu | Aller au menu | Aller à la recherche

jeudi, avril 3 2014

Mise en oeuvre de logstash

Logstash est un excellent produit de tri, traitement et collecte des journaux (=>logs).

Lire la suite...

lundi, mars 3 2014

Un cadeau de Broadcom pour l'OpenSource

Ce n'est pas la première fois, et ce ne sera surement pas la dernière! Broadcom vient d'annoncer la mise à disposition de la documentation complète sur ses puces graphiques VideoCore IV, ainsi que les sources complètes de la pile logiciel en rapport. Cela, peut être pour remercier le Raspberry Pi, qui fête sa 2e année, et son succès planétaire.

Lire la suite...

jeudi, décembre 19 2013

Fin de vie de la Fedora 18

L'annonce de la date de fin de vie (EOL) pour la Fedora 18 vient de tomber.

Lire la suite...

mardi, décembre 17 2013

La Fedora 20 "Heisenbug" est sortie

Et voilà, la version finale de la Fedora 20 vient de sortir. Elle coïncide avec le 10e anniversaire du projet Fedora, et ce veut aussi un hommage à Seth Vidal, developpeur principale des projets YUM, et grand contributeur de projets libres, qui nous a quitté en juillet dernier. Cette version de Fedora lui est donc dédiée.

Pour voir la liste des changements: ici sur le site officiel, ou quand j'en avais parlé précédemment.

Les notes officielles de sortie sont ici. Pour télécharger la Fedora 20, il faut aller sur la page officielle du projet.

Gnome F20

dimanche, octobre 13 2013

Les fonctionnalités attendues pour la Fedora 20

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

samedi, octobre 5 2013

Réseaux GRE avec routage OSPF

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.local (le créer s'il n 'existe pas) pour avoir la ligne suivante:

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.

vendredi, octobre 4 2013

Tunnel GRE sous OpenBSD

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.

mardi, septembre 24 2013

Fedora 20 Alpha disponible

Pour vous les gens qui aimez être à la pointe de la technologie, qui aimez vivre dangereusement, que rien n'effraie, sachez que la Fedora 20 en version alpha vient tout juste de sortir.

Elle est disponible à l'adresse suivante: http://fedoraproject.org/get-prerelease

Elle était à l'origine prévue pour le 17 septembre dernier, mais elle a pris une semaine de retard.

Il est important, comme toujours, de tester, tester, et tester encore, dans des conditions les plus réelles possibles (genre en VM c'est bien, mais sur du vrai matos c'est mieux) les pré-versions, afin de remonter au plus tôt les éventuels problèmes. En espérant que ce ne soit pas des Heisenbug.

La prochaine étape après cette version alpha, sera, suspens... la version beta. Celle-ci reste pour l'instant prévue pour le 29 octobre 2013.

La version finale, si tout se passe bien, est prévue pour le 3 décembre 2013. Le calendrier est visible ici.

Fedora: 10 ans déjà!

Le 22 septembre dernier, le projet Fedora fêtait ses 10 ans. En effet, la distribution communautaire de chez RedHat avait vu le jour en 2003, avec la Fedora Core 1, abandonnant de fait les versions RedHat Linux pour passer aux RedHat Entreprise Linux. Ces dernières s'appuyent sur les avancés de Fedora et le travail de la communauté, mais avec un cycle beaucoup plus lent pour permettre plus de stabilité.

Entre temps, le nom Fedora Core a lui aussi évolué pour ne laisser que Fedora. C'est plus court.

Pour rappel, les RedHat Entreprise Linux 5 s'appuient sur la Fedora Core 6, et pour la branche 6, sur la Fedora 13. Les rumeurs vont bon train concernant la RHEL7, sur son arrivée assez imminente compte tenu de la "jeunesse" de la RHEL 6. Peut être cela permettra de combler un vide entre des versions très (voire trop pour certains) rapprochées chez Fedora, et des versions trop lente (et donc rapidement vieillissante) pour RedHat (qui tourne autour des 10 ans).

Finalement, avec le recul, une sortie prévue initialement tous les 6 mois, Fedora n'a pas pris tant de retard que ça en 10 ans. Nous en sommes à la Fedora 19. La Fedora 20 devrait sortir en décembre 2013.

Bon anniversaire au projet, et longue vie encore!

mercredi, septembre 4 2013

La Fedora 20 s'appellera...

Heisenbug. Voilà pour son petit nom. Comme il contient le mot bug, les trolls seront faciles, c'est toujours ça de pris. De toute façon, ça colle avec sa définition qui correspond à un type de bugs bien particuliers, ceux qui disparaissent quand on commencent à vouloir les éradiquer... pas si rares que ça...

Le résultat complet du vote, avec les autres propositions:

1549 :: Heisenbug
1291 :: Eigenstate
961 :: Félicette
879 :: Superego
826 :: herry Ice Cream
808 :: C hateaubriand
750 :: Santa Claus
653 :: Österreich
  1 :: 20

Au moins ça enterre complètement l'idée de ne plus donner de nom (1 vote pour le nom 20...). La Fedora 20 est pour l'instant prévue pour le 26 novembre 2013.

mardi, juillet 9 2013

Fedora pour ARM bientôt en support officiel

Le projet Fedora s'organise actuellement pour ajouter le support ARM, au même titre que les architectures historiques déjà supportées. Ce qui voudra dire qu'à terme, tous les paquets de Fedora devront compiler et supporter l'architecture ARM, en plus du i386 et du x86_64.

Il n'y a pas si longtemps encore, le projet ne voyait pas l'intérêt de supporter l'ARM. Fedora part donc aujourd'hui avec un certain retard, même si le support ARM existe déjà plus ou moins depuis certaines versions de Fedora. Là l'idée est bien d'améliorer ce support, en le rendant officiel.

La motivation vient du fait que l'ARM gagne de plus en plus de terrain dans l'informatique, y compris sur les serveurs. La monté en puissance des puces ARM (support 64bits, virtualisation, etc), leur polyvalence (voire omniprésence dans l'embarqué du moins), et surtout, tant que Intel ne se reveille pas, leur efficacité face à leur consommation electrique, y est surement pour quelque chose. En bref, une part de marché grandissante qui interesse RedHat et qui bénéficiera forcément du retour d'expérience d'avoir une Fedora ARM.

La cible est établie pour la Fedora 20 comme expliqué ici.

ps: Pour ceux qui veulent jouer avec une Fedora 18 ARM, et qui dispose d'un RaspberryPi => Pidora

mardi, juillet 2 2013

Fin de vie de la Fedora 17

Forcément, comme toujours, la Fedora 19 venant de sortir, l'annonce de la fin de vie pour la version N-2 arrive. La Fedora 17 n'aura donc plus de mise à jour à partir du 30 juillet 2013. Il n'y aura donc plus de support sur cette version, si vous ne mettez pas à jour, ce sera à vos risques et périls (danger de mort qui tue, etc)...

Peut être l'occasion de tester l'outil fedup pour mettre à jour.

La Fedora 19 est-elle à la fois sortie ET pas sortie?

En tout cas, chat de Schödinger ou pas, elle est bien disponible. Pour rappel les nouveautés apportées par cette nouvelle Fedora 19 (nom de code Schrödinger's Cat) sont:

  • Le remplacement de MySQL par MariaDB
  • Le support de OpenShift Origin et OpenStack Grizzly (supers outils de déploiement)
  • Des packages pour Node.js
  • De nouveaux outils autour de l'impression 3D (c'est à la mode)

Et son lot d'évolutions habituelles mais pas des moindres:

  • Systemd s'améliore encore (support des containeurs)
  • Gnome 3.8
  • KDE 4.10 et l'ensemble des bureaux alternatifs (MATE 1.6, Cinnamon, LXDE etc).

Quelques mises à jour un peu plus underground:

  • BIND10
  • checkpoint et restauration de processus, carrément. Intéressant il faudra tester ça!
  • PHP 5.5
  • Pilote KMS pour QXL/Spice (pour la virtualisation, vers de la 3D dans les VMs)
  • RPM 4.11
  • Le support de migration de VM sans stockage partagé (enfin)
  • yum qui supporte les snapshots LVM sur des lv thinp (dommage que Anaconda ne sache pas encore créer ça)

A vos mises à jour!

La liste des fonctionnalités de la F19 ici.

Pour télécharger la Fedora 19 (privilegiez le torrent): ici.

mardi, février 5 2013

Mais où est passé systemd-analyze?

Si vous venez de faire une installation toute fraîche de Fedora 18 vous serez peut être étonné que la commande systemd-analyze n'est plus disponible de base. Cette commande très utile est dans le paquet "systemd-analyze", qu'il suffit d'installer:

yum install systemd-analyze

Et voilà! Utile pour diagnostiquer un démarrage lent:

$ systemd-analyze blame
  2055ms postfix.service
   601ms systemd-udev-settle.service
   530ms firewalld.service
   476ms fedora-storage-init.service
   451ms iscsid.service
   335ms bluetooth.service
   229ms abrt-ccpp.service
   222ms systemd-binfmt.service
   204ms NetworkManager.service
   199ms fedora-storage-init-late.service
   195ms systemd-logind.service
   185ms avahi-daemon.service
   169ms ntpd.service
   162ms cpupower.service
   159ms acpid.service
   158ms fedora-loadmodules.service
   127ms systemd-udev-trigger.service
   105ms sshd.service
   103ms systemd-readahead-collect.service
   101ms abrt-vmcore.service
    98ms ksmtuned.service
    93ms gdm.service
    93ms lvm2-monitor.service
    92ms sys-kernel-debug.mount
    90ms systemd-readahead-replay.service
    85ms ksm.service
    80ms dev-mqueue.mount
    79ms udisks2.service
    78ms proc-sys-fs-binfmt_misc.mount
    68ms dev-hugepages.mount
    67ms systemd-vconsole-setup.service
    66ms systemd-remount-fs.service
    66ms systemd-tmpfiles-setup.service
    65ms home.mount
    62ms rpcbind.service
    60ms fedora-readonly.service
    59ms bacula-fd.service
    53ms colord.service
    52ms iscsi.service
    51ms tmp.mount
    51ms systemd-sysctl.service
    48ms polkit.service
    47ms systemd-modules-load.service
    45ms boot.mount
    45ms auditd.service
    42ms sys-kernel-config.mount
    29ms wpa_supplicant.service
    27ms accounts-daemon.service
    27ms systemd-udevd.service
    23ms upower.service
    12ms rtkit-daemon.service
     9ms systemd-user-sessions.service

Pas mal cette Fedora 18, assez propre sans rien faire (et encore j'ai perdu 2 secondes au boot en installant postfix). La transition vers systemd est de plus en plus complète, vu ce qu'il reste dans init.d:

$ ls /etc/init.d/
ebtables  functions  iscsi  iscsid  libvirt-guests  netcf-transaction  netconsole  network  README

A suivre!

lundi, février 4 2013

Automount via systemd

Quand il est nécessaire d'accèder à des systèmes de fichiers particuliers, à travers le réseau (NFS, CIFS, etc) ou sur une ressource pas toujours disponible (disque externe USB), voire même pour soulager les requêtes sur ce montage, il est utile de passer par la fonctionnalité "automount". Comme son nom l'indique, cela permet de monter automatiquement un point de montage, dès la première requête d'accès sur ce dernier. L'inverse est aussi de mise, démonter le point de montage quand celui-ci n'a pas été accédé depuis un certain temps (timeout).

Avant il fallait passer par autofs/automount, et configurer un ou plusieurs fichiers de configuration pour indiquer les points de montage à gérer. Rien de très complexe ceci dit. Mais aujourd'hui, le fameux remplaçant de SystemVinit, systemd, a de nombreux avantages dont celui de prendre en charge nativement les points de montage, particulièrement pratique pour remplacer autofs/automount.

Il y a deux possibilités pour configurer un point de montage automatique avec systemd:

  • via les fichiers unit de systemd, avec la création d'un fichier .automount et son associé en .mount
  • via directement le fichier /etc/fstab

Comme ici, le but est de faire plus simple qu'à l'époque de autofs, nous allons juste voir la méthode via fstab. Attention c'est simple, il suffit d'ajouter une ligne classique du montage souhaité, et dans les options d'ajouter la mention x-systemd.automount. Et voilà le tour est joué.

Exemple avec un montage nfs4:

srvnfs:/nfs/exports/home /mnt/nfs/home nfs4 x-systemd.automount 0 0

Exemple avec un disque externe usb (ex /dev/sdb1):

UUID=a2969b8d-c90a-432e-8198-f697c23f8c96 /mnt/externe		  ext4	  noauto,x-systemd.automount 0 0

(blkid /dev/sdb1 pour avoir l'UUID).

Au prochain reboot, au moindre accès dans le point de montage indiqué par x-systemd.automount, ce dernier sera automatiquement monté. C'est magique!

jeudi, janvier 17 2013

Fin de vie de la Fedora 16

La Fedora 18 étant disponible depuis le 15 janvier dernier, il va falloir penser à mettre à jour si vous êtes en retard. En effet, chez Fedora, la version n-2 devient obsolète et n'est plus maintenue.

Alors si vous utilisez encore une Fedora 16, notez bien dans vos agenda qu'elle sera considérée comme morte à partir du 12 février prochain (EOL: End Of Life). Donc plus de mises à jour pour cette version, plus de correctifs de bugs ou de sécurité (le plus gênant). Il est donc important de passer à une version plus récente (Fedora 18 par exemple, autant prendre la dernière).

Pour télécharger une Fedora récente: Le site officiel

Pour mettre à jour votre Fedora: Procédure de mise à jour

mercredi, janvier 9 2013

Un GO pour la Fedora 18

Enfin! Le GO vient d'être donné pour la sortie officielle de la Fedora 18 (Spherical Cow), la date sera donc le 15 janvier prochain.

Après plusieurs mois de retard, principalement lié à la refonte importante du programme d'installation Anaconda, cette prochaine version qui commençait à se faire attendre arrive enfin. Il aura fallu reporter sa sortie près de 7 fois, ce qui est surement une première chez Fedora, pour enfin corriger les derniers bugs bloquants. Vivement le 15!

Tout plein de nouveautés comme à chaque fois:

  • Gnome 3.6
  • Firewalld
  • toujours plus de systemd
  • DNF
  • oVirt 3.1
  • Samba 4
  • MATE, xfce etc

J'en oublie surement, la liste est longue: ici

Plus que quelques jour à attendre.

jeudi, novembre 29 2012

La Fedora 18 est disponible en beta

La Fedora 18 vient de passer une étape importante en vue de sa sortie finale avec la sortie de sa Beta. L'arrivée de cette Beta a été reporté plusieurs fois suite à quelques bugs importants, principalement dans l'installeur. Mais après quelques semaines de retard, la Beta est enfin là! Vous pouvez donc contribuer à son amélioration en testant cette version.

Pour télécharger la beta: http://fedoraproject.org/get-prerelease

Il peut bien entendu rester quelques problèmes, qui sont normalement référencés sur cette page: F18 Common Bugs (par exemple l'installation de MATE depuis le DVD d'installation est HS).

Plusieurs méthodes sont disponibles pour installer une Fedora 18:

  • soit directement depuis un média d'installation ou un liveCD (le DVD d'installation a souvent moins de problèmes)
  • soit avec preupgrade depuis une ancienne Fedora (depuis la 17 ce sera plus facile)
  • soit avec yum en suivant la procédure habituelle, décrite ici
  • soit avec le nouvel outil FedUp

Pour les fonctionnalités apportées par la Fedora 18, beaucoup de choix concernant l'environnement graphique:

  • Gnome 3.6
  • Nouvelles versions pour KDE, XFCE, Sugar
  • Arrivée de MATE (fork de Gnome2)
  • Cinnamon est toujours présent (fork de Gnome3)

Mais aussi un nouvel installeur, complètement repensé. Cf Anaconda 18

Pour avoir un aperçu plus détaillé des nouveautés: http://fedoraproject.org/wiki/Releases/18/FeatureList

Pour rappel la Fedora 18 "Spherical Cow" est prévue pour le 8 janvier 2013.

Bon test!

vendredi, novembre 9 2012

La Fedora 19 s'appellera...

Si vous êtes contributeurs Fedora, pensez à aller voter pour le nom de la prochaine Fedora, la version 19. Après le "Spherical Cow" de la Fedora 18, on commence enfin à s'éloigner de la bouffe américaine! Voici les noms proposés au vote:

  • Cubical Calf
  • Higgs Boson
  • Loch Ness Monster
  • Martian Blueberries
  • Newtonian Dynamics
  • Parabolic Potassium
  • Schrödinger's Cat
  • Tiddalik

Par contre, l'influence ubuntuesque reste encore un peu présente. Certains noms risquent en plus d'être difficile pour les graphistes (surtout pour le Schrödinger's Cat), mais on commence à avoir l'habitude de ne plus avoir de thèmes graphiques en rapport avec le nom de notre Fedora, ce qui est un peu dommage. Pour ma part j'ai une préférence pour Higgs Boson et Tiddalik, et vous?

source: ici (pour voter)

samedi, octobre 20 2012

Adieu yum, bonjour dnf!

Adieu yum, ce n'est peut être pas pour tout de suite quand même! Mais cela approche...

Le fabuleux gestionnaire de paquets yum (YellowDog Updater Modified), que nous utilisons depuis les débuts de Fedora, n'a jamais cessé de s'améliorer au fil du temps. Il a toujours été simple à utiliser, pas forcément rapide ni efficace dans la gestion des dépendances au tout début, mais il est maintenant un des meilleurs gestionnaires de paquets disponibles. Son succès l'amène d'ailleurs sur la plus part des distributions basées sur des RPMs.

Ses avantages aujourd'hui sont à mon avis les suivants:

  • Une seule commande comme point d'entrée (yum)
  • Une gestion automatique de son cache
  • Un affichage clair et efficace
  • Programmé en python
  • Fichiers de configuration simples et clairs
  • Facilité pour développer des plugins
  • Sa rapidité

Mais, bien souvent quand un produit arrive à une telle maturité, il peut être intéressant d'explorer de nouvelles pistes. Peut être pour contrer l'ennui de ses développeurs qui sait... Du coup, un fork a été crée, pas forcément avec délicatesse vis à vis des mainteneurs du yum originel, mais ça c'est fait. Le nouveau projet s'appelle DNF, ce qui ne veut rien dire car le nom est peut être temporaire. Il est censé améliorer certains points, déjà du point de vue des performances (ah?), de l'utilisation possible d'autres langages que python, et d'une mise à disposition d'une API claire et propre.

DNF est déjà disponible dans la Fedora 18, ce sera donc l'occasion de le tester. Mais il ne faudra pas s'attendre non plus à une révolution, l'ensemble du projet DNF étant un fork de yum il en utilise encore une très grande partie. D'ailleurs la commande dnf s'appellera peut être de nouveau yum quand elle pourra complètement le remplacer dans une future Fedora.

Le but premier de dnf est de fournir la bibliothèque hawkey qui s'appuie sur libsolv pour la résolution des dépendances. Pour information libsolv vient du monde openSuse. A terme toutes les résolutions de dépendances, pas forcément dans yum/dnf, s’appuieront sûrement sur libsolv.

Proposer une nouvelle API, plus propre/précise, permettra aussi une meilleure intégration dans l'environnement graphique. A voir ce que cela donnera dans Gnome par exemple.

Pour tester dnf, il suffit de l'installer:

yum install dnf

Les commandes dnf sont identiques (pour l'instant?) à yum, pas la peine d'en parler:

dnf help

Le fichier de conf se trouve logiquement dans /etc/dnf/dnf.conf. A voir sur le long terme ce que donnera dnf.

- page 1 de 5