Red Hat Software Collections 1.0 Beta

Posté par (page perso) . Édité par Xavier Claude et Xavier Teyssier. Modéré par Xavier Teyssier. Licence CC by-sa
20
20
juin
2013
Red Hat

Red Hat a annoncé, le 5 juin dernier, les « Software Collections » en version 1.0 Beta. Il s'agit d'un canal (terminologie de Red Hat pour désigner un dépôt logiciel) contenant des logiciels dont les versions sont plus récentes que dans les canaux habituels de la distribution RHEL.

Comme chaque canal logiciel de Red Hat, celui-ci est soumis à souscription auprès de la société.

La liste des logiciels inclus ainsi que leurs modalités d'installation et d'utilisation sont détaillés en seconde partie de cet article.

Sommaire

S'il est un reproche qu'on peut faire à RHEL, c'est de disposer de versions logicielles parfois anciennes, voire obsolètes par rapport à la dernière version disponible. Cela répond à des impératifs de stabilité et cela n'est pas gênant la plupart du temps : utiliser le dernier noyau Linux est-il nécessaire surtout si les correctifs de sécurité sont rétro-portés ?

Toutefois, certains cas de figure peuvent s'avérer plus problématiques : on se rappelle de PHP 5.1.6 déjà en fin de vie lors de la sortie de RHEL 5, mis à jour en 5.3.3 avec RHEL 5.6 (soit plus de 3 ans après).

Le cas de PHP est particulièrement marquant car la popularité de ce langage fait que de nombreux sites web et autres applications l'utilisent. Autant d'applications qui se retrouvaient de fait « incompatibles » avec RHEL, à moins de recompiler soi-même un PHP récent, ou qu'un gentil contributeur fournisse des paquets de versions à jour.

Cette collection de logiciels est donc très intéressante pour Red Hat qui peut, sans trop bousculer la stabilité du socle RHEL, augmenter sa compatibilité avec des applications tierces. Elle l'est aussi pour ses clients, qui n'auront pas à changer de distribution Linux (voire de fournisseur de support technique) ou à empaqueter (et maintenir) eux-même des versions plus récentes.

Les principaux logiciels inclus

Si l'introduction parle de PHP, c'est bien pour une raison : c'est que la version 5.4.14 s'y trouve ! PHP 5.3 est certes toujours maintenu par The PHP Group, mais avec la 5.5 déjà à l'état de RC (à l'écriture de cette dépêche), on peut supposer que la version 5.3 ne restera pas maintenue bien longtemps.

À noter aussi non pas une, mais deux versions plus récentes de Python : 2.7 et 3.3. Voilà qui devrait faciliter les tests de compatibilité de vos applications, surtout via les connecteurs pour base de données MySQL et PosgreSQL fournis.

Toujours dans les langages tendance, Red Hat nous propose Ruby 1.9.3 accompagné de son fidèle compagnon Rails, qui lui est en version 3.2.8. Il est d'ailleurs mentionné qu'une « large collection de gems » est de la partie.

Réjouissez-vous, mongueurs, car Perl est disponible en version 5.16.3. Comme pour Python, des connecteurs pour bases de données sont inclus.

Parlons des bases de données, justement : non seulement vous retrouverez MySQL 5.5, mais Red Hat a décidé de fournir MariaDB 5.5. PosgreSQL n'est pas en reste avec une version 9.2.

Enfin, et à titre d'avant-première technologique, Red Hat fourni aussi Node.js 0.10.

Distributions compatibles

Red Hat a choisi de limiter les distributions compatibles :

  • Red Hat Enterprise Linux 6.2 Extended Update Support
  • Red Hat Enterprise Linux 6.3 Extended Update Support
  • Red Hat Enterprise Linux 6.4

On remarquera l'absence de toute RHEL 5 des versions compatibles. Attention cependant si vous utilisez une version antérieure à RHEL 6.4 : il vous faudra utiliser RHN Classic et non le nouveau système de souscription. Une autre option est toutefois possible : mettre à jour vers RHEL 6.4 (oui, on sait, c'est un peu facile).

Utilisation

Commençons par les choses qui fâchent : les Software Collections ne sont accessibles qu'aux machine disposant d'une souscription « developer ». Si votre serveur la possède, alors il suffit de vérifier la liste des canaux disponibles, et d'activer le canal rhel-variant-rhscl-6-beta-rpms, où variant désigne votre version de RHEL.

L'installation des paquets se fait ensuite via yum, de manière tout à fait classique. Ce qui change, en revanche, c'est le nommage des paquets. De la même manière qu'avec RHEL 5.6, PHP 5.3 est disponible via le paquet php53, les logiciels fournis par Software Collections sont suffixés par leur numéro de version.

Par exemple, pour installer le CPAN et la prise en compte d'archives Tar pour Perl 5.16, il faudra taper la commande suivante : ~]# yum install perl516-perl-CPAN perl516-perl-Archive-Tar. Ces versions cohabitent donc avec les versions présentes dans RHEL.

L'utilisation d'un script Perl utilisant la version 5.16 devient donc :

~]$ scl enable perl516 'perl hello.pl'
Hello, World!

Il est toutefois possible d'utiliser les versions « Software Collections » par défaut dans son shell : ~]$ scl enable perl516 'bash (ici Bash, mais vous pouvez utiliser un autre shell).

De nombreux autres exemples d'utilisation sont disponibles dans la documentation au chapitre 2.

Dernières précautions

Les « Software Collections » ne sont pour le moment disponibles qu'en Beta. Soyez donc attentif lors de l'utilisation de ces logiciels. Un support est normalement disponible, mais rappelez-vous que Node.js n'en dispose pas, à cause de son statut d'avant-première technologique.

De plus, Red Hat nous a habitué lors des versions de RHEL, à faire disparaître les documentations Beta lorsque la version stable est disponible. Ceci n'est qu'une hypothèse, mais il est probable que certains liens présents dans cette dépêche soient invalides après l'apparition de la version stable. En cas d'erreur 404, n'hésitez donc pas à vous rendre sur la page d'accueil des documentations des produits Red Hat (dernier lien de la liste).

  • # RHEL se met donc à jour

    Posté par . Évalué à -10.

    Bonjour,

    Je ne savais pas que RHEL n'avait pas la possibilité d'obtenir les derniers paquets concernant la toute dernière version stable d'un logiciel donné via les dépôts officiels…
    Il est pourtant important d'offrir une telle possibilité.
    Le dernier PHP ou Python pourrait être nécessaire pour des applications exigeantes comme Symfony (PHP) ou django (python).

    Sous debian, il suffit de suivre les recommandations du site pour la mise en place d'une source.list cohérente et on a le dernier logiciel. Je l'ai fait avec Percona par exemple.

    Ce que je ne comprends pas c'est le fait qu'on doive payer une souscription pour pouvoir s'en servir.
    C'est dommage.

    Vu qu'à ce que j'ai compris, de plus en plus de linuxiens veulent le dernier logiciel en vogue, il m'a apparu normal que RHEL se mette au goût du jour pour inciter ceux qui seraient tentés de partir de rester…

    Merci pour cette dépêche qui mérite d'exister.

    PS: étant donné que je n'utilise aucun produit RH, je peux bien sûr me tromper sur ma première affirmation

    • [^] # Re: RHEL se met donc à jour

      Posté par (page perso) . Évalué à 7.

      Sous debian, il suffit de suivre les recommandations du site pour la mise en place d'une source.list cohérente > et on a le dernier logiciel. Je l'ai fait avec Percona par exemple.

      C'est pas vraiment vrai…

      Si tu es en stable, au bout d'un moment, si tu commence à mettre du SID, tu va devoir changer la libc, exemple classique. A partir de ce moment là, tu n'est plus en stable à mon sens. Ensuite, il y a les backports qui sont mieux mais il n'y a pas tout.

      Par ailleurs, cela modifie la version sur la machine. La technique RH ajoute une autre version en //. Cela permet d'avoir plusieurs versions de php, etc. Sur les machines de calcul ou on recompile tout à la main, on a un équivalent avec "module" (paquet environment-modules).

      • [^] # Re: RHEL se met donc à jour

        Posté par (page perso) . Évalué à 5.

        Ensuite, il y a les backports qui sont mieux mais il n'y a pas tout.

        Le gros inconvénient, c'est ce que n'est pas suivi par l'équipe de sécurité.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: RHEL se met donc à jour

        Posté par . Évalué à -9.

        --- " Si tu es en stable, au bout d'un moment, si tu commence à mettre du SID, tu va devoir changer la libc, exemple classique. A partir de ce moment là, tu n'est plus en stable à mon sens. Ensuite, il y a les backports qui sont mieux mais il n'y a pas tout " (…)

        Qui a parlé de SID ?
        Vous allez sur le site d'un éditeur compétent et ils vous indiquent les démarche à suivre:
        pour wheezy faites ceci, pour squeeze cela, etc.
        Ce n'est pas important que vous soyez en stable ou pas.
        Si votre site a besoin d'un user accounting, percona est un bon choix.
        (lire la news sur mariadb dans les commentaires)

        • [^] # Re: RHEL se met donc à jour

          Posté par (page perso) . Évalué à 6.

          On parle des versions dans les dépôts. Si c'est pour ajouter des paquets d'éditeur tiers, tu peux très bien le faire aussi avec RHEL.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: RHEL se met donc à jour

      Posté par (page perso) . Évalué à 4.

      Il est pourtant important d'offrir une telle possibilité.

      Pourquoi ? Avoir la toute dernière version des softs n'est pas tout le temps la bonne chose à faire. Et comme indiqué dans la news, parfois une version éprouvée avec correctifs de sécurité suffit amplement.

      • [^] # Re: RHEL se met donc à jour

        Posté par . Évalué à -9.

        --- " Pourquoi ? Avoir la toute dernière version des softs n'est pas tout le temps la bonne chose à faire. Et comme indiqué dans la news, parfois une version éprouvée avec correctifs de sécurité suffit amplement " (…)

        Offrir une possibilité ne veut pas dire qu'on va s'en servir…
        Mais une entreprise qui aura besoin du dernier PHP parce que son framework favori l'exige, ne va pas cracher sur la nouveauté si elle est estampillée stable par l'éditeur.
        Et je n'ai jamais dit qu'en production, il est préférable de prendre le dernier. Il vaut mieux prendre le plus éprouvé comme vous le dites vous-même…

  • # Comme quoi ...

    Posté par (page perso) . Évalué à 7.

    J'approuve grandement la façon propre de permettre la cohabitation de plusieurs version du même logiciel. Ne reste plus qu'a pouvoir démarrer proprement plusieurs fois le même service avec des contextes différents.

    Enfin je me permettrait de remarquer que la séparation entre le système de base et les portslogiciels tiers est finalement une idée qui fait son chemin.

    • [^] # Re: Comme quoi ...

      Posté par (page perso) . Évalué à 3.

      Ne reste plus qu'a pouvoir démarrer proprement plusieurs fois le même service avec des contextes différents.

      Y a déjà les containers, y a systemd ou tu peux modifier le path de ton service à grand coup de includes ( et donc copier le démarrage avec un path différent et ce genre de chose).

      Quel est le cas d'utilisation que tu voudrais avoir ?

      • [^] # Re: Comme quoi ...

        Posté par (page perso) . Évalué à 6.

        Y a déjà les containers, y a systemd ou tu peux modifier le path de ton service à grand coup de includes ( et donc copier le démarrage avec un path différent et ce genre de chose).

        Je sais que les mécanismes existent. C'est juste leur intégration qui pèche.

        Quel est le cas d'utilisation que tu voudrais avoir ?

        newinstance --service=tomcat --name=superappli --version=7
        chkconfig tomcat_superappli on
        vi /etc/sysconfig/tomcat_superappli
        service tomcat_superappli start
        
        
  • # RH et Fedora

    Posté par (page perso) . Évalué à 7.

    La sortie des software collections permet aussi de montrer que non, RH n'impose pas ce qu'elle veut sur Fedora, vu que ça a été proposé comme feature, et refusé:

    https://fedoraproject.org/wiki/SoftwareCollections

    Y a eu une grande discussions sur le sujet, couverte par lwn:

    https://lwn.net/Articles/529458/

  • # EPEL

    Posté par (page perso) . Évalué à 3.

    Puisqu'on parle de paquets pour RHEL, j'en profite pour recommander EPEL (Extra Packages for Enterprise Linux) [1] qui porte sur RHEL les paquets de Fedora qui ne sont pas proposés par Red Hat. Très pratique quand on a un serveur Red Hat (ou CentOS).

    [1] http://fedoraproject.org/wiki/EPEL

    • [^] # Re: EPEL

      Posté par (page perso) . Évalué à 3.

      Oui, mais on n'y trouve pas forcément des packages très à jours non plus… et quid du suivi de sécurité ?
      Idem pour rpmforge que je préfère globalement à EPEL (pas de troll, j'assume que c'est subjectif).

      • [^] # Re: EPEL

        Posté par (page perso) . Évalué à 3.

        EPEL est suivi comme Fedora, sur la même infra. Quand l'équipe sécurité trouve un CVE pour Fedora, un bug chez EPEL est ouvert si ça s'applique. Vu que les dépôts sont utilisés par l'équipe Fedora pour son infrastructure, c'est assez logique d'avoir un minimum de sécurité. Ensuite, y a pas d'ETA ni quoique ce soit, mais en général, les soucis sont suivis et corrigés.

        Les paquets passent par la même phase de validation communautaire via Bodhi dans les 2 cas ( ie, passage par updates-testing, puis si assez de karma ou assez longtemps, envoi dans le dépôt update ).

        Mais c'est pas explicite dans la FAQ :/

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.