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).
Aller plus loin
- Red Hat (69 clics)
- DLFP : Sortie de Red Hat Enterprise Linux 6.4 (65 clics)
- Annonce de Red Hat Software Collections 1.0 Beta (107 clics)
- Notes de version 1.0 Beta (39 clics)
- Documentation produit Red Hat (34 clics)
# RHEL se met donc à jour
Posté par kadalka . É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 Sytoka Modon (site web personnel) . Évalué à 7.
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 claudex . Évalué à 5.
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 Sytoka Modon (site web personnel) . Évalué à 2.
En fait, sous debian, il y a aussi l'option "schroot" qui dépanne dans certain cas et évite de tout polluer…
[^] # Re: RHEL se met donc à jour
Posté par kadalka . Évalué à -9.
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 claudex . É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 CrEv (site web personnel) . Évalué à 4.
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 kadalka . Évalué à -9.
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 Joris Dedieu (site web personnel) . É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 Misc (site web personnel) . Évalué à 3.
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 Joris Dedieu (site web personnel) . Évalué à 6.
Je sais que les mécanismes existent. C'est juste leur intégration qui pèche.
# RH et Fedora
Posté par Misc (site web personnel) . É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 Almacha (site web personnel) . É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 rictus (site web personnel) . É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 Misc (site web personnel) . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.