Red Hat a annoncé ce 21 novembre la version 6.5 de Red Hat Enterprise Linux (RHEL), distribution commerciale destinée aux professionnels et aux entreprises.
Même si RHEL 6 est disponible depuis novembre 2010, cette version 6.5 apporte de nombreuses améliorations, non seulement au niveau des pilotes matériels mais aussi au niveau des logiciels de plus haut niveau. Red Hat avait annoncé la version bêta près de deux mois auparavant, soit le 8 octobre dernier.
Une sélection des améliorations se trouve en deuxième partie de dépêche.
Sommaire
- Matériel
- Gestion des abonnements RHN
- Réseau
- Stockage
- Sécurité
- Virtualisation
- Environnement de bureau
- Du côté des clones
Matériel
Le futur est déjà présent dans RHEL 6.5 ! En tous cas au moins celui d'Intel, car des futurs produits de la marque sont déjà ajoutés. Cela comporte entre autres des processeurs SoC, dont des bi-processeurs Atom, des contrôleurs mémoire, des puces SATA, USB, ILB, ou SMBUS et aussi des puces 2D et 3D.
AMD n'est pas en reste avec l'activation de l'ECC pour une future génération de processeurs. Toujours dans le domaine de la mémoire, vous pourrez utiliser plus d'un téra-octet de mémoire vive sur une machine AMD (via une mise à jour noyau).
Le pilote mpt3sas est mis à jour pour être utilisé avec les contrôleurs disques SAS LSI 12Gbps.
RHEL dispose d'un moniteur de fréquence processeur. Celui-ci a été mis à jour : il fournit maintenant de meilleures informations, ce qui lui fait prendre de meilleures décisions sur le changement de fréquence. Le but ce système est de pouvoir baisser la fréquence processeur afin d'économiser de l'énergie.
On remarquera l'apparition de fonctionnalités de partitionnement de matériel dynamique et de reconnaissance d'emplacement de carte système, qui alertent les logiciels intermédiaires ou applications de haut niveau pour la reconfiguration. Il devient du coup possible d'agrandir le système et de lui faire assumer une charge de travail plus importante sans avoir à le redémarrer.
Gestion des abonnements RHN
Les kernel dump peuvent être très volumineux sur certains sytèmes, il est maintenant possible de les diviser en plusieurs fichiers et d'utiliser une compression LZO pour faciliter leur envoi au support Red Hat.
Nous l'avions vu dans RHEL 5.10, Red Hat introduit un paquet nommé redhat-support-tool. Pour plus de détails, vous pouvez consulter l'article de la base de connaissance.
Réseau
NTP, c'est bien. Mais PTP, c'est mieux ! C'est ce qu'on pourrait penser en lisant les notes de versions, qui annoncent la prise en charge officielle de ce protocole de synchronisation d'horloge. Déjà présent en 6.4 en avant-première technologique, celui-ci est maintenant officiellement pris en charge. Celui-ci dispose d'une implémentation aussi bien en espace noyau qu'en espace utilisateur, et certains pilotes de carte réseau sont indiqués comme compatibles : bnx2x, tg3, e1000e, igb, ixgbe, et sfc.
Quelques améliorations aussi du côté de NetworkManager : il permet maintenant la création et la gestion de connexions PPPoE, utilisées entre autres pour l'ADSL, ISDN et certains VPN.
Dans le cadre du développement d'OpenStack, les Network namespaces ont été implémentés dans RHEL 6.5 : il s'agit d'un système de conteneurs légérs permettant à des processus d'avoir leur propre espace réseau plus ou moins isolé.
La vie (au sens réseau du terme, hein) ne se limite pas à TCP et UDP. Le protocole SCTP est à l'honneur dans cette RHEL, puisqu'il se voit apporté deux améliorations : la première est la possibilité d'utiliser SHA1 en plus de MD5 comme fonction de hachage cryptographique, et l'ajout d'un protocole nommé M3AU pour envoyer des messages de signalisation.
Stockage
Comme pour RHEL 5.10, l'outil fsfreeze est maintenant officiellement pris en charge. Des corrections de bug ont aussi été ajoutées dans pNFS, sans donner beaucoup de détail.
On remarquera que suite à l'acquisition de GlusterFS, son intégration avance dans les produits Red Hat : celui-ci est maintenant pris en charge par FUSE.
Côté LVM, la grosse nouveauté est le thin provisionning : le principe est de créer des volumes depuis une réserve de stockage partagé. Les blocs de cette réserve ne sont alloués que lorsque des données sont écrites dessus, et reviennent dedans une fois les données effacées. De plus, une nouvelle implémentation des instantanés est mise en place, uniquement pour les systèmes qui ne sont pas en cluster. Ces deux possibilités sont des avant-premières technologiques.
Utilisateurs de multipath, réjouissez-vous : RHEL 6.5 promet une meilleure réactivité des outils, un nommage automatique de vos périphériques et une détection des cibles plus robuste !
Abordons maintenant GFS2, le système de fichiers partagé. Celui-ci devrait être plus performant, grâce à l'introduction du Orlov block allocator. En plus, lorsqu'un groupe de ressources fait l'objet d'un trafic soutenu, un groupe différent est utilisé pour augmenter les performances.
Pour finir cette section sur le stockage, penchons-nous sur mdadm, qui va vous permettre d'utiliser TRIM sur vos ensembles RAID0, RAID1, RAID10 et RAID5 de disques SSD.
Sécurité
Attention, nous avons du lourd, car il y a une mise à jour d'envergure : ce n'est ni plus ni moins qu'OpenSSL, qui passe de la version 1.0.0 à la version 1.0.1 ! Cela peut sembler ironique de prime abord, mais Red Hat effectue habituellement un rétro-portage des correctifs et des améliorations nécessaires à RHEL (et surtout ses clients). Cette mise à jour permet avant tout d'ajouter des chiffrements nécessaires pour GlusterFS (racheté par Red Hat il y a quelques temps).
Toutefois, d'autres ajouts intéressant sont disponibles, comme ECDSA, une variante de l'algorithme DSA utilisant la cryptographie sur les courbes elliptiques. Toujours dans les courbes elliptiques, c'est aussi une variante de Diffie-Hellman qui fait sont apparition : ECDHE.
Bien entendu, TLS 1.1 et 1.2 sont pris en charge, non seulement dans OpenSSL mais aussi dans NSS (qui lui aussi, au passage, tire parti des courbes elliptiques). Moins marquant mais ouvrant la porte à d'autres possibilités, la manière dont est empaqueté OpenSSL a été modifiée, faisant appel au préfixe macro : le but est de pouvoir reconstruire OpenSSL et de l'installer à un autre endroit sur le système.
OpenSSH n'est pas en reste, puisque sa mise à jour permet d'utiliser une Smartcard comme moyen d'authentification. Il devient aussi possible d'utiliser SHA-2 pour les MAC (Message Authentifcation Code), ce qui améliore l'intégrité des données.
Vous voulez encore plus de courbes elliptiques ? Alors regardez du côté de Suite B : il s'agit d'une liste d'algorithmes tenue par la NSA dans le cadre de son programme de modernisation cryptographique. Les algorithmes abordés dans cette rubrique en font partie, ainsi que d'autres déjà implémentés dans RHEL, comme AES-128, ou AES-256.
Virtualisation
Nous avions déjà eu des améliorations concernant KVM avec Windows en RHEL 6.4, il y en a encore en 6.5 : citons notamment le guest agent, pris en charge et dont l'installeur est fourni par le paquet virtio-win, disponible dans le canal "Supplementary". On pourra aussi entendre la différence sur les machines virtuelles Windows XP grâce à un contrôle du volume fonctionnel. Toujours dans le domaine de la compatibilité avec le monde Microsoft, KVM peut maintenant utiliser (en lecture seule) les fichier VHDX en provenance d'Hyper-V.
Il est aussi possible pour KVM d'utiliser (en lecture seule ici aussi) des fichiers VMDK provenant des solutions VMware, et l'outil virt-v2v est capable de convertir (vers KVM, bien sûr) des machines virtuelles provenant d'export OVF de VMware ou des invités Citrix Xen.
Depuis les versions 5.9 et 6.4, RHEL dispose des pilotes invités pour Hyper-V. Une amélioration dans cette version 6.5 est l'ajout du pilote "Synthetic Video Frame Buffer". En plus, le protocole de signalisation entre l'hôte et l'invité a été mis à jour.
Si vous utilisez RHEL en invité sur VMware, peu de changement pour vous : seul le pilote réseau paravirtualisé a été mis à jour dans la dernière version upstream.
Environnement de bureau
Si vous utilisez RHEL sur un ordinateur de bureau ou portable, la version 6.5 vous apportera quelques mises à jour appréciables : gdm, Evolution, LibreOffice, et NetworkManager sont de la partie, ainsi que des pilotes pour cartes graphiques AMD.
La mise à jour de gdm comporte un correctif sur les message d'expiration de mot de passe, la possibilité de faire du "multi-seat" et un correctif d'interopérabilité.
Evolution a été mis à jour en dernière version afin de mieux fonctionner avec Microsoft Exchange. Cela permet d'utiliser EWS (Exchange Web Service), et améliore les réunions ainsi que les dossiers.
Pour LibreOffice, il s'agit d'une mise à jour en version 4.0.4. Quant à NetworkManager, sa mise à jour comporte le support des alias sur les interfaces réseau. Toutefois, il est recommandé aux utilisateurs d'utiliser la fonctionnalité d'adresses IP secondaires.
Du côté des clones
Peu avant son annonce, Red Hat a commencé à fournir les paquets sources de cette version. Du coup, les contributeurs du projet CentOS ont d'ores et déjà commencé à construire les paquets pour la version 6.5. Ce sujet de forum est l'occasion de découvrir une partie du processus de construction de l'un des clones de RHEL les plus utilisés.
Aller plus loin
- Red Hat (712 clics)
- DLFP : Red Hat Enterprise Linux 6.4 (454 clics)
- DLFP : Red Hat Enterprise Linux 5.10 (102 clics)
- Annonce de RHEL 6.5 (189 clics)
- Notes de version (295 clics)
- Notes techniques (131 clics)
# Troll
Posté par MTux . Évalué à -3.
Mais dans l'ensemble RedHat c'est mieux que Ubuntu Server ?
[^] # Re: Troll
Posté par Zenitram (site web personnel) . Évalué à 6.
Déjà, rien que dans sa durée de vie (10 ans pour RHEL/CentOS contre 5 ans pour Ubuntu).
Mais sinon, oui c'est un gros troll, chaque distro ayant ses avantages et inconvénients, on ne peux pas dire "c'est mieux" sans connaitre l'utilisation, bref il n'y a que toi qui peut savoir ce qui est mieux pour toi, en fonction de ce que tu comptes en faire (exemple : si tu fais des upgrades tous les 2-3 ans ou si ton projet a une courte durée de vie, l'avantage que j'ai cité ne te concerne pas et ne vaut rien du tout, si tu veux pas gérer des upgrades ou en faire le moins possible pendant la vie de ton long projet, Ubuntu est éliminé direct).
[^] # Re: Troll
Posté par Atem18 (site web personnel) . Évalué à 0.
Joue un peu avec et tu verras à quel point Ubuntu est foireux dans son ensemble. Il serait par contre plus intéressant de comparer Debian à Red Hat.
[^] # Re: Troll
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 22 novembre 2013 à 12:24.
Ca c'est du lancer de troll!
Pour l'alimenter : clair qu'avoir 1 an pour upgrader (si tu installes une machine au 1/1/2011, fallait faire un upgrade dans l'année 2011 tout début 2012 sinon plus de sécu), sinon crève, ça donne envie comme distro, après si tu as le temps de t'amuser à refaire les validations…
[^] # Re: Troll
Posté par gnumdk (site web personnel) . Évalué à 1.
Ah, moi j'ai un serveur RedHat, un serveur Ubuntu et que des serveurs Debian…
Le serveur foireux je le connais bien, il s'appelle RedHat…
[^] # Re: Troll
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 5.
Et je peux en dire tout autant dans l'autre sens. Encore une fois, c'est une question de préférence, et d'habitude.
[^] # Re: Troll
Posté par Misc (site web personnel) . Évalué à 10.
j'aurais tendance à dire qu'un serveur foireux sur une debian ou une rh, ça dit beaucoup plus sur l'admin que sur la distribution. Globalement, aucune n'a 0 bug, je peux citer des cas chiants sur chacune ( genre par exemple, l'intégration selinux de debian a des bugs, j'ai soumis 4 patchs et du coté RHEL, j'ai trouvé des bugs dans augeas et postfix qui sont corrigé en 6.5 avec l'upgrade en 1.0, par exemple ).
Des serveurs qui ont sans arrêt des emmerdes, j'ai jamais croisé, ou quand j'ai croisé, c'était rarement la faute de la distribution.
[^] # Re: Troll
Posté par Christophe B. (site web personnel) . Évalué à 10. Dernière modification le 22 novembre 2013 à 13:04.
foireux dans quel sens ?
De notre coté seul Redhat est certifié par l'éditeur qui nous fait vivre donc si on veut de l'assistance on est obligé.
Je ne sais plus combien de serveur RH on a chez nos clients (dont beaucoup n'ont pas d'informaticien à demeure) mais ça "juste tourne"
Alors c'est vrai que notre utilisation est basique : BDD Oracle + ERP Propriétaire, nos serveurs sont souvent sur dimensionné par rapport aux besoins.
Au tarif ou sont la RAM les disques pourquoi se priver.
Mais le résultat est la, des clients content qui ne connaissent même pas la version de l'os, ils savent que c'est du Linux RedHat car ils payent l'assistance mais c'est tout.
Pour illustrer :
Je viens de trouver comment voir sous Zabbix certaines choses, je supervise en douce quelques serveurs clients et voici quelques uptimes :
Client 1 : 100 users environ, 2 serveurs Oracle RH5 en STANDBY => uptime 385 jours
Client 2 : 25 users environ, 1 serveur => 189 jours
Client 3 : 8 users => 114 jours
Client 4 : 15 users => 78 jours
Il s'agit de serveur en exploitation quotidienne, avec de la bonne grosse informatique de gestion Commande, Bon de livraison Facture Stock etc …
Sincèrement on est proche de l'ennui avec Linux, coté administration, surtout qu'on ne fais pas de mise à jour.
Heureusement on a encore quelques serveurs sous Windows pour nous tenir en éveil :)
C'est pour cela que j'aimerais savoir ce que tu trouves de foireux chez RedHat par rapport à une debian ou autre
Et aussi l'utilisation courante que tu en fais.
Note : c'est pas pour critiquer, hein même si c'est dredi, c'est juste pour ma culture personnelle
[^] # Re: Troll
Posté par etenil . Évalué à 1.
Vive Microsoft, sans eux beaucoup d'admins seraient au chômage!
[^] # Re: Troll
Posté par Christophe B. (site web personnel) . Évalué à 4.
Voila ce que devrais faire le gouvernement :
Et la tu peu tripler voir quintupler le nombre d'admin et la courbe du chomage s'inverse
Et puisque c'est dredi
Linux c'est comme les freins sur les voitures … c'est pour les LACHES
sur ce messieurs bon week end …
[^] # Re: Troll
Posté par Albert_ . Évalué à 4.
t'as oublier les asiles qui auront besoin de personnel pour prendre soin de tout ce monde :)
[^] # Re: Troll
Posté par Christophe B. (site web personnel) . Évalué à 3.
de plus en plus d'admin, voire même plus d'admin que d'utilisateurs …
Nous pourrons alors prendre le pouvoir, par la force s'il le faut
ADMIN POWEEEEEEERRRRRRRR !!!!
on me souffle à l'oreille que c'est l'heure d'aller se coucher et que c'est plus trolldi
et n'oublie pas de prendre tes gouttes …
[^] # Re: Troll
Posté par gnumdk (site web personnel) . Évalué à 0.
Je ne faisais que faire une réponse pourrie à un commentaire pourri…
Moi aussi, la RedHat c'est pour faire tourner Time Navigator, on ne m'a pas laissé le choix et la personne qui a installé ce dernier passe plus de temps à me dire de le rebooter parce qu'il ne voit plus la librairie qu'a à le gérer…
et moi quand je l'ai vu faire l'installe en cochant tout ce qui était dispo dans anaconda, j'ai quand même eu un peu peur…
Tu rajoutes à cela que je trouve yum lent, que la recherche dans ce dernier ne fonctionne pas sans être root, que puppet n'est pas dispo dans les dépots… Bref, je refuse de faire l'administration de ce truc, pour moi, c'est une verrue sur mon réseau.
[^] # Re: Troll
Posté par Ermaion (site web personnel) . Évalué à 3. Dernière modification le 22 novembre 2013 à 15:09.
Puppet est dans les dépots EPEL, tout les admins qui maîtrise RHEL le savent.
Quant à yum il est plus lent à démarrer mais globalement plus pratique : les plugins yum quant on les a essayé difficile de s'en passer ensuite en particulier 'priorities'.
Je pense que tu as beaucoup de préjugés parce-que visiblement tu as plus l'habitude de Debian ; le fait, qui plus est, que ta RHEL à l'air d'être bien pourrie par son admin ne doit pas arranger les choses.
[^] # Re: Troll
Posté par claudex . Évalué à 3.
Ça correspond à apt-pinning ou c'est autre chose ?
« 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: Troll
Posté par Ermaion (site web personnel) . Évalué à 4.
Je connais pas trop apt-pinning mais yum-priorities permet d'attribuer une valeur de 1 à 99 à chaque dépôt afin d'empêcher que des dépôts non fiables n'altèrent le système en mettant à jour des paquets issus de dépôts fiables (les officiels de la distribution surtout).
Par exemple dans mon cas avec trois dépôts externes à la distribution 81 mises à jour sont bloquées.
[^] # Re: Troll
Posté par Misc (site web personnel) . Évalué à 3.
Apt_pinning, c'est simple.
Tu mets un poids à chaque dépot, et en fonction du poids dans un range arbitraire ( http://linux.die.net/man/5/apt_preferences ), ça prends ou pas la priorité sur les autres dépots lors de la résolution de dépendances.
Donc de 0 à 100, y a un range, de 500 à 990, de 990 à 1000, et au delà aussi. Genre si je donne un note de 1200, alors le dépôt prends le pas sur tout les autres, même si ça fait revenir en arrière, sauf si le paquet vient du même dépot, auquel cas il va le mettre à jour.
Si le dépôt a par exemple 50, alors tu installes, mais il mets pas à jour si ç'est déjà sur place.
Etc, etc.
Alors tu peux faire ça par distribution, mais aussi par paquet.
Et à la fin, quand tu as compris ce que tu veux faire et comment le faire sur tes 15 dépôts, tu peux faire un cul de chouette, car si tu piges le pinning, tu piges le jeu aussi.
[^] # Re: Troll
Posté par Zenitram (site web personnel) . Évalué à 3.
Vous êtes conscients que vous parlez de la même chose à l'implémentation près juste que la "langue" (le logiciel sous-jacent) est différente?
Sinon, entre "apt-cache" pour la recherche et "pinning" pour les dépots prioritaires, chez apt ils ont de la suite dans les idées pour t'inciter à oublier les commandes… (bon, apt a l'air d'utiliser le mot "preferences" plus logique, mais je vois "pinning" pas mal sur le net, encore un truc apt-get vs aptitude dans le discours?)
[^] # Re: Troll
Posté par rictus (site web personnel) . Évalué à 2.
Grosso modo le plugin priorities de yum correspond au pinning de apt…
yum a bien rattrappé son retard par rapport à apt, ça me semblerait être du troll ou du vrai subjectif de dire que l'un est supérieur à l'autre… même si je suis sûr qu'on peut trouver des exemples de choses que fait l'un mais pas l'autre.
Subjectivement, je préfère apt, mais dans mon usage quotidien yum se comporte aussi bien.
[^] # Re: Troll
Posté par Ermaion (site web personnel) . Évalué à 1.
Je n'ai jamais sous entendu que apt était moins bon, je réagissais surtout à la réaction de gnumdk qui était du genre «yum et RHEL c'est de la merde et puis c'est tout»
[^] # Re: Troll
Posté par jolitorax . Évalué à 3.
Puppet est surtout dans les dépôts puppetlabs qui permettent d'installer la même version sur tout ton parc (de serveurs Centos, scientific et Debian chez nous). Ça évite des bugs étranges quand le master n'a pas la même version que les agents.
[^] # Re: Troll
Posté par Zenitram (site web personnel) . Évalué à 5.
Clair que RHEL c'est pas le truc que les admins à travers le monde utilisent tous sur les grosses machines, gnumdk est trop un dieu et c'est certainement de la faute de la distro si il y a un problème, c'est évident…
RHEL est juste le truc par défaut de toute boite qui rationalise (bon, concurrencé par SuSE certes maintenant), mais c'est de la merde, évident!
Il est pourtant la :
https://dl.fedoraproject.org/pub/epel/6/x86_64/
(non, pas le dépot de chez RedHat direct, mais ce dépot est la référence, le truc à ajouter à une RHEL/CentOS si on ne te l'interdit pas pour les certifications, l'équivlaent de universe d'Ubuntu)
Bref, de l'anti sans vraiment connaitre et/ou se remettre en cause.
[^] # Re: Troll
Posté par Renault (site web personnel) . Évalué à -3.
Le ou est inclusif en français par défaut (donc un ou exprime un ET/OU) ce qui rend non nécessaire cette expression affreuse. ;)
Un ou non inclusif se dit : ou exclusivement.
[^] # OU logique vs pratique
Posté par Zenitram (site web personnel) . Évalué à 10.
Dans la théorie (et un OU logique) tu as raison, mais si un jour on te demande de répondre par oui ou par non et que tu réponds "oui et non", je crois qu'on va pas apprécier. Je préfère donc expliciter…
[^] # Re: Troll
Posté par Xavier Teyssier (site web personnel) . Évalué à 4.
Tu rajoutes à cela que je trouve yum lent, que la recherche dans ce dernier ne fonctionne pas sans être root
Ta Red-Hat m'a l'air d'avoir été drôlement customisée :
Et je peux t'assurer que l'utilisateur Xate n'est pas l'utilisateur root…
[^] # Re: Troll
Posté par Ermaion (site web personnel) . Évalué à 1. Dernière modification le 22 novembre 2013 à 16:01.
Pour être honnête la tienne aussi est un peu customisée.
Un vrai serveur ça ressemblerait plutôt à ça :
[^] # Re: Troll
Posté par Xavier Teyssier (site web personnel) . Évalué à 2.
Ah non, je proteste, dans l'histoire, c'est la tienne qui est customisée. C'est quoi tous ces dépôts ? :-)
Pour ma part, je n'ai que les dépôts base, addons et extras d'activés. Et je ne sais pas pourquoi ils n'apparaissent pas dans la liste. Je suppose que c'est parce qu'ils pointent vers un serveur en local.
Les seules customisations que j'ai apportées sur ces machines, c'est justement cela : faire pointer les dépôts vers des mirroirs présents sur notre réseau interne (et sur cette machine spécifiquement, désactiver le dépôt updates, mais ça, c'est une autre histoire).
Effectivement, pour le temps d'exécution de la commande, le fait que les mirroirs soit en local doit jouer. Perso, le temps d'exécution de yum ne m'a jamais gêné. Mais pour ceux qui en sont à la seconde près, j'ai déjà lu qu'on peut le configurer pour que l'équivalent du "aptitude update" ne soit pas réalisé à chaque exécution de YUM, mais uniquement sur appel manuel. Perso, je n'en suis pas à la seconde près, et j'aime les trucs automatiques :-)
[^] # Re: Troll
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 22 novembre 2013 à 16:28.
Sur la machine que j'utilise professionnellement, qui a été configurée par je ne sais qui, j'ai largement le temps d'écrire ce message, et d'y ajouter que la simple recherche de vim a pris
Ouais, il doit y avoir pas mal de merde dans la liste de dépôts. Sans compter que c'est une machine virtuelle sur laquelle sont connectés 5 personnes, au moins, de manière permanente.
Je tiens à préciser que je ne comprends pas pourquoi une recherche entraîne la mise à jour de la liste des paquets.
[^] # Re: Troll
Posté par WhiteCat . Évalué à 3.
Moi je haie "apt-get".
Déjà la commande est chiante à taper.
Ensuite, la commande pour chercher un paquet s'appelle… "apt-cache" => MEGA LOGIQUE inside.
Pour avoir des informations à jour sur les paquets. "apt-get" est capable de te donner des infos pas à jour (très utile donc…) et si je veux avoir des infos correctes, il faut d'abord taper "apt-get update". Devoir taper 2 commandes au lieu d'une, vive l'ergonomie.
[^] # Re: Troll
Posté par claudex . Évalué à 4.
Moi, je hais yum/zypper/… qui rafraichit la liste des paquets d'une distribution stable avant une recherche alors que la liste n'a pas changé depuis hier (forcément, c'est une version stable la liste ne change pas).
« 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: Troll
Posté par Zenitram (site web personnel) . Évalué à 4.
je sais pas pour vous, mais pour moi taper "yum -C search" est quif quif (en vitesse pour taper et en vitesse pour mémoriser la commande à la con) que taper "apt-cache search"
C'est quoi votre problème avec ces commandes qui font la même chose (et même rapidité)? Pourquoi cette haine de choses qui font la même chose avec la même rapidité?
[^] # Re: Troll
Posté par WhiteCat . Évalué à 2.
Y'a régulièrement des màj de sécurité.
[^] # Re: Troll
Posté par claudex . Évalué à 4.
Ça ne change pas la liste des paquets. Ça ne change donc que les versions des paquets, ce qui n'est pas la propriété le plus souvent recherchée (en tout cas pour moi).
« 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: Troll
Posté par Renault (site web personnel) . Évalué à 3. Dernière modification le 22 novembre 2013 à 21:19.
Il arrive qu'en pleine version stable de nouveaux paquets soient disponibles car le mainteneur a travaillé dessus. Tu en as plusieurs dizaines ainsi après la sortie de la version stable.
Puis quitte à chercher des paquets, autant avoir la dernière version d'affiché (c'est parfois important de savoir si le programme du dépôt est à jour par rapport à la version officielle du dit programme).
ÉDIT : ma remarque sur les paquets concernaient Fedora et comme Yum est utilisé par plusieurs distributions, il ne faut pas que son comportement soit induit par un choix de conception qui n'est pas du ressort de Yum.
[^] # Re: Troll
Posté par Misc (site web personnel) . Évalué à 4.
Tu peux dire à yum de ne jamais expirer les métadonnées, et de le faire à la main avec yum makecache.
L'idée de faire ça automatiquement, c'est que ça évite les erreurs cons du style "j'ai fait ça mais ça me dit "package not found" car l'index n'est pas bon". Et au final, ça améliore la perception de ta distribution ( vu que tu élimines une classe d'erreur ) et ça réduit les appels au support ( que ça soit pro comme communautaire, la problématique est la même ).
Ensuite, je comprends que c'est pas un choix qui plait à tout le monde, que ça reste plus chiant en terme de ressources, mais faut bien faire un choix par défaut.
[^] # Re: Troll
Posté par claudex . Évalué à 3.
Je suis entièrement d'accord avec ça, je réagissais juste au fait que le comportement par défaut n'était pas forcément apprécié de tout le monde et que certains préférait le comportement d'apt-get.
« 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: Troll
Posté par rictus (site web personnel) . Évalué à 4.
la commande aptitude est un bon frontal à apt-get et apt-cache :
aptitude update (~ yum check-update)
aptitude upgrade (~ yum upgrade)
aptitude install (etc…)
aptitude search…
aptitude était d'ailleurs préconisée au moins à partir de debian squeeze…
[^] # Re: Troll
Posté par WhiteCat . Évalué à 1.
Bien vu.
[^] # Re: Troll
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 22 novembre 2013 à 18:11.
A chaque que je cherche (genre quand j'oublie la commande qui a un nom bizarre), je tombe que "apt-cache search". C'est historique?
Aucune différence, apt-get et apt-cache sont donc à bannir de toute utilisation "non super méga avancée" et de tout tuto?
Parce qu'en mise à jour 2013:
http://fr.openclassrooms.com/informatique/cours/reprenez-le-controle-a-l-aide-de-linux/apt-cache-search-rechercher-un-paquet
http://www.tecmint.com/useful-basic-commands-of-apt-get-and-apt-cache-for-package-management/
http://askubuntu.com/questions/298506/using-apt-cache-search
https://help.ubuntu.com/community/AptGet/Howto (octobre 203… Et une seule personne pour dire "non, c'est aptitude")
que du apt-get / apt-cache…
[^] # Re: Troll
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
La dernière version stable (wheezy) dit : « Pour une mise à niveau des versions précédentes de Debian, il est recommandé d'utiliser le gestionnaire de paquets apt-get. Lors des versions précédentes, aptitude était recommandé, mais les dernières versions d'apt-get fournissent des fonctions équivalentes et se sont montrées plus robustes pour fournir le résultat attendu pour la mise à niveau. »
L'avant-dernière stable (squeeze) dit pareil.
Et celle d'encore avant (lenny) : « Pour une mise à niveau des versions précédentes de Debian GNU/Linux, il est recommandé d'utiliser le gestionnaire de paquets aptitude. Ce programme prend des décisions plus sûres qu'apt-get pour l'installation des paquets. »
[^] # Re: Troll
Posté par Zenitram (site web personnel) . Évalué à 4.
"Pour une mise à niveau des versions précédentes", ça ne me parle pas pour une recherche de paquet ou une installation de nouveau paquet… :(
Sans compter que c'est pas très stable comme conseil (apt-get avant, puis aptitude, pui apt-get de nouveau, ça va dans quelle direction ce truc?)
[^] # Re: Troll
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Debian Handbook version Squeeze
http://debian-handbook.info/browse/stable/sect.apt-get.html
« The most recommended interface, aptitude, is the one used during the installation of Debian. »
[^] # Re: Troll
Posté par Antoine . Évalué à 3.
Je crois que tu devines aisément la suite.
[^] # Re: Troll
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 0.
Oui, un outil pour chercher le paquet au loin, un autre pour fouiller dans le cache.
Tu as visiblement des problèmes de logique brute.
Il y a une quinzaine d'années, j'ai découvert cron, ça a changé ma vie. Tu devrais essayer.
[^] # Re: Troll
Posté par Zenitram (site web personnel) . Évalué à 4.
Tu penses sérieusement que les interfaces homme-machine doivent être à base de trucs techniques et non pas d'étude sur la communication?
Ouch…
[^] # Re: Troll
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
On voit bien où mènent les études sur la communication : GNOME 3. Je ne veux pas d'un système qui range les choses là où l'imbécile moyen croit qu'il les trouvera ; je veux un système prédictible. Et en l'occurrence, faire appel au réseau rend la tâche imprévisible.
[^] # Re: Troll
Posté par WhiteCat . Évalué à 4.
Tu veux dire qu'il faut que je configure moi-même un cron, qui donc va tourner régulièrement, même quand j'en ai pas besoin, pour avoir des informations à jour dans un autre logiciel.
L'ergonomie des outils d'administration Debian me laisse pantois. Heureusement que ce même procédé n'est pas généralisé ailleurs, par exemple sur le Web où pour aller consulter les articles sur linuxfr.org, il faudrait lancer d'abord un cron pour mettre à jour les pages web en local, pour ensuite les consulter dans Firefox.
[^] # Re: Troll
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -1.
Dois-je t'introduire au principe d'orthogonalité aussi ?
Pour peu qu'un couillon appelle ça RSS, on serait bien dans l'embarras d'un logiciel qui met automatiquement à jour une liste d'articles d'un site web, avec son contenu. Tiens, et pourquoi pas en plus un logiciel qui trie ce qui est susceptible de t'intéresser, on appellerait ça la curation.
[^] # Re: Troll
Posté par Antoine . Évalué à 1.
Question sérieuse : comment est-on censé être informé que cron-apt existe ? Personnellement, je ne connaissais pas (et j'utilise régulièrement Debian / Ubuntu).
[^] # Re: Troll
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
C'est la même question pour tous les logiciels. Comment est-on censé être informé de l'existence de Liferea, de Firefox ou de mutt ?
Je crois que j'avais découvert l'existence de cron-apt dans les colonnes de GLHMF, dans la section de découvert des outils. Mais je suis bien d'accord que ce devrait être un paquet par défaut.
[^] # Re: Troll
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 22 novembre 2013 à 17:13.
Ta machine fume.
Ma VM (une VM, hein… Bref, un truc ralenti, bon OK comme toi) derrière une ligne VDSL2 (donc comme l'ADSL le ping est pas terrible, c'est pas un serveur correctement connecté au net) chez un FAI "pour particuliers" :
real 0m6.729s
user 0m0.370s
sys 0m0.070s
Et j'ai les repos par défaut + EPEL…
Pour que la liste soit à jour, de manière automatique, et pas que tu te dises ensuite "zut, la liste est peut-être obsolète". Pour un search c'est peut-être bourrin, ok, mais c'est du défaut, c'est tout.
Et puis, bon, c'est pas comme si on parlait d'admins système, qui sont sensés savoir lire un manpage de yum pour changer les options par défaut (c'est un choix par défaut, qui plait ou pas ça reste du défaut)
-C
Tells yum to run entirely from cache - does not download or update any headers unless it has to to perform the requested action.
hop:
real 0m0.435s
user 0m0.366s
sys 0m0.028s
Pas contre toi spécialement, mais l'argument de la lenteur simplement parce que le choix par défaut n'est pas le même entre apt et yum est risible, et montre plus une envie de taper sur yum qu'on a décidé de détester sans savoir pourquoi qu'une comparaison objective.
Perso, la seule différence que je vois entre les deux avec ma maigre utilisation certes est une petite différence de config par défaut et des commandes différentes (et les gars, vous êtes sérieux quand apt vous plait alors qu'ils faut taper des commandes super chiantes pour une simple recherche à jour? faut taper "-C" pour yum, ok, mais "apt-cache" pour une recherche, c'est d'un évident…) pour le plaisir de faire chier ceux qui travaillent avec plusieurs distros, bref, le plaisir de coder 2x la même chose.
[^] # Re: Troll
Posté par Christophe B. (site web personnel) . Évalué à 4. Dernière modification le 22 novembre 2013 à 17:18.
Je connais un peu Time Navigator (Tina pour les intimes:) ) je connais RedHat.
le reboot est un gros mot sous linux. le problème vient plutôt du portage du driver de la librairie
en plus si je me souviens bien insmod ls mod c'est pas fait pour ca ? rafraichir les modules ?
mouais … et c'est des sauvegardes importantes ?
tu y tiens a ton prestataire ?
[^] # Re: Troll
Posté par bubar🦥 (site web personnel) . Évalué à 3. Dernière modification le 24 novembre 2013 à 16:09.
/* mode troll, topix troll :-)
Je ne suis pas sûr d'avoir bien compris cette phrase, et la "perte de librairies" (non, pas de bibliothèques) je n'ai 'jamais vu/entendu parler' de ça. Par contre lors de (re)boot sur des Redhat 6, TiNa perd ses librairies lorsqu'elles sont distantes sur des baies, parceque le noyau refait dynamiquement l'attribution des devices alors que TiNa veut des wwn. Refaire à la main ces attributions lors des reboot, pour avoir un tina fonctionnel, c'est pas terrible. Mais les prochaines versions auront intégrés un patch (sic, juste une conf udev) pour permettre de faire du persistant binding quelque soit la techno sous-jacente. Sinon, refaire à la main les wwn pour que TiNa retrouve ses petits, à chaque boot, c'est pas terrible.
Il faut le pendre haut et court.
Même si l'impact est nul, avec des mises à jour aux petits oignions, c'est crade. Là c'est probablement une amélioration si tu proposes un kickstart « voilà ce qu'est "redhat pour serveur autonome" ici, et tu t'y tiens » à ton intégrateur/installeur.
On parle de machines de guerre qui hébergent souvent les informations du coeur de métier, et vous parlez de savoir si toto prend une seconde de moins que titi pour réaliser une proposition de mises à jour ? Non mais … LOL Et puis, celui gérant les mises à jour avec yum, faut le pendre aussi, hein :p
Et OpenShift & OpenStack, ça n'existe pas ? Sérieux, là, dire "n'existe pas chez redhat" c'est faux. Puppet n'existe pas pour les versions serveurs de base, et il y a des raisons à cela. Et si tu en as besoin parceque tu a choisi Puppet pour une partie de l'administration de ton parc, ben c'est ton choix pas celui de l'éditeur.
ça a du sens, l'homogénéité facilite tout.
[EDIT : fai indique ne pas supporter officiellement redhat] Pour Puppet, je ne rejoins pas le commentaire plus bas disant d'utiliser le dépôt fourni par le projet. Ton approche est la même que celle décrite plus haut : prudents, on prends la version de l'éditeur, pour toi, Debian. Heureusement l'intérêt de Puppet sur des serveurs de sauvegardes tina est très faible …
[^] # Re: Troll
Posté par datz . Évalué à 2.
+1
Combien de fois ne suis-je pas tombé sur des paquets cassés sous Ubuntu.
Sous CentOS, c'est rare. Sous Fedora, ça fait des années que j'ai pas vu ça.
[^] # Re: Troll
Posté par Misc (site web personnel) . Évalué à 5.
Je pense que comme toutes les distributions, Ubuntu a des outils de verification, et le souci, c'est plus que les mainteneurs de la communauté s'en foutent ( alors que je pense que Canonical fait gaffe à ça pour main ).
Donc la solution, c'est de s'impliquer pour les aider. Pour mageia, il y a une règle, si le paquet est pas installable au moment de la release, il est viré. Ça motive beaucoup plus les gens à les corriger :)
# Debian et stabilité
Posté par maxmasou . Évalué à -2.
Il me semble un peu farfelue d'attaquer la stabilité de Debian quand son système(Ubuntu) est basé sur une Debian. Une Debian Testing faut-il le précisé. Ce gars me fait pensé à moi, il y a 5 ans. J'avais fait un commentaire presque identique, sur QuebecOS.com, au sujet de ces deux même distribution. Un modérateur m'avait expliqué pourquoi j'étais dans l'erreur. J'ai donc décidé de donner une vrai chance à Debian dans les jours qui ont suivit. Je n'ai plus jamais changé de distro!
[^] # Re: Debian et stabilité
Posté par xcomcmdr . Évalué à 4.
Faux et archi-faux. Ubuntu utilise des paquets provenant de Sid pour une (bonne) partie de ce que Canonical ne prend pas directement en charge, ce qui est assez différent.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Debian et stabilité
Posté par maxmasou . Évalué à 1.
Vraiment désolé pour la désinformation sur Ubuntu. Oui il existe des différences entre Sid et Testing. Par contre, sa dépend a quel moment dans le cycle de Debian, Ubuntu prend ces paquets. Quelques mois avant le "Freeze", les paquets sont pratiquement identiques dans Sid et Testing. De plus, à 95%, j'ai toujours eu les même bug dans Testing et dans Sid. Mais ça, sa dépend de ce que l'on fait avec son système….
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.