Red Hat Enterprise Linux 6.5

Posté par (page perso) . Édité par Benoît Sibaud, palm123, Xavier Claude, MTux et Xavier Teyssier. Modéré par ZeroHeure. Licence CC by-sa
34
22
nov.
2013
Red Hat

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.

RHEL

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

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.

  • # Troll

    Posté par . Évalué à -3.

    Mais dans l'ensemble RedHat c'est mieux que Ubuntu Server ?

    • [^] # Re: Troll

      Posté par (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 2. Dernière modification le 22/11/13 à 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 (page perso) . É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 (page perso) . É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 (page perso) . É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 . Évalué à 10. Dernière modification le 22/11/13 à 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 . Évalué à 1.

            Vive Microsoft, sans eux beaucoup d'admins seraient au chômage!

            • [^] # Re: Troll

              Posté par . Évalué à 4.

              Voila ce que devrais faire le gouvernement :

              • obliger toutes les entreprise a utiliser windows
              • windows update quotidien OBLIGATOIRE ( sinon c'est trop facile )
              • Internet Explorer : obligatoire ( chrome et firefox c'est pour les gonzesses )
              • Surface pour tout le monde :)
              • Windows phone aussi :)

              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 . Évalué à 4.

                t'as oublier les asiles qui auront besoin de personnel pour prendre soin de tout ce monde :)

                • [^] # Re: Troll

                  Posté par . É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 (page perso) . É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 (page perso) . Évalué à 3. Dernière modification le 22/11/13 à 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 (page perso) . Évalué à 3.

                es plugins yum quant on les a essayé difficile de s'en passer ensuite en particulier 'priorities'.

                Ç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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 . É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 (page perso) . Évalué à 5.

              Bref, je refuse de faire l'administration de ce truc, pour moi, c'est une verrue sur mon réseau.

              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!

              que puppet n'est pas dispo dans les dépots…

              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 (page perso) . Évalué à -3.

                Bref, de l'anti sans vraiment connaitre et/ou se remettre en cause.

                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 (page perso) . É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 (page perso) . É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 :

              [xate@carbonatite ~]$ time yum search vim
              Loaded plugins: fastestmirror
              ============================================================================= Matched: vim =============================================================================
              vim-X11.x86_64 : Version VIM de l'éditeur vi pour le système X Window.
              vim-common.x86_64 : Fichiers communs indispensables pour toute version de l'éditeur VIM.
              vim-enhanced.x86_64 : Version de l'éditeur VIM comprenant des améliorations récentes.
              vim-minimal.x86_64 : Version minimale de l'éditeur VIM.
              
              real    0m0.964s
              user    0m0.676s
              sys     0m0.276s
              [xate@carbonatite ~]$
              

              Et je peux t'assurer que l'utilisateur Xate n'est pas l'utilisateur root…

              • [^] # Re: Troll

                Posté par (page perso) . Évalué à 1. Dernière modification le 22/11/13 à 16:01.

                Pour être honnête la tienne aussi est un peu customisée.
                Un vrai serveur ça ressemblerait plutôt à ça :

                [cedric@cedric-workstation ~]$ time yum search vim
                Loaded plugins: fastestmirror, priorities, refresh-packagekit, security
                Loading mirror speeds from cached hostfile
                 * base: mirrors.atosworldline.com
                 * elrepo: elrepo.reloumirrors.net
                 * epel: be.mirror.eurid.eu
                 * extras: mirrors.atosworldline.com
                 * updates: mirrors.atosworldline.com
                81 packages excluded due to repository priority protections
                =============================== N/S Matched: vim ===============================
                glusterfs-vim.x86_64 : Vim syntax file
                golang-vim.noarch : Vim plugins for Go
                protobuf-vim.x86_64 : Vim syntax highlighting for Google Protocol Buffers
                                    : descriptions
                vim-X11.x86_64 : The VIM version of the vi editor for the X Window System
                vim-clustershell.noarch : VIM files for ClusterShell
                vim-common.x86_64 : The common files needed by any version of the VIM editor
                vim-enhanced.x86_64 : A version of the VIM editor which includes recent
                                    : enhancements
                vim-minimal.x86_64 : A minimal version of the VIM editor
                nvi.x86_64 : 4.4BSD re-implementation of vi
                vile-common.x86_64 : The common files needed by any version of the VIM editor
                vim-halibut.noarch : Syntax file for the halibut manual tool
                youtube-dl.noarch : A small command-line program to download online videos
                
                  Name and summary matches only, use "search all" for everything.
                
                real    0m3.202s
                user    0m1.402s
                sys 0m0.160s
                
                • [^] # Re: Troll

                  Posté par (page perso) . É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 (page perso) . Évalué à 1. Dernière modification le 22/11/13 à 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

                  real    2m24.699s
                  user    0m19.347s
                  sys     0m15.801s
                  

                  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 . É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.

                    Je tiens à préciser que je ne comprends pas pourquoi une recherche entraîne la mise à jour de la liste des paquets.

                    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 (page perso) . É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 (page perso) . É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 . Évalué à 2.

                        Y'a régulièrement des màj de sécurité.

                        • [^] # Re: Troll

                          Posté par (page perso) . É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 (page perso) . Évalué à 3. Dernière modification le 22/11/13 à 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 (page perso) . É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 (page perso) . Évalué à 3.

                          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.

                          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 (page perso) . É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 (page perso) . Évalué à 0.

                      MEGA LOGIQUE

                      Oui, un outil pour chercher le paquet au loin, un autre pour fouiller dans le cache.

                      Pour avoir des informations à jour sur les paquets. "apt-get" est capable de te donner des infos pas à jour

                      Tu as visiblement des problèmes de logique brute.

                      il faut d'abord taper "apt-get update"

                      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 (page perso) . Évalué à 4.

                        Oui, un outil pour chercher le paquet au loin, un autre pour fouiller dans le cache.

                        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 (page perso) . É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 . Évalué à 4.

                        Il y a une quinzaine d'années, j'ai découvert cron, ça a changé ma vie. Tu devrais essayer.

                        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 (page perso) . Évalué à -1.

                          Tu veux dire qu'il faut que je configure moi-même un cron

                          $ time apt-cache search cron-apt
                          cron-apt - automatic update of packages using apt-get
                          
                          real    0m0.834s
                          user    0m0.796s
                          sys     0m0.024s
                          

                          Dois-je t'introduire au principe d'orthogonalité aussi ?

                          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

                          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 . É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 (page perso) . Évalué à 2.

                              comment est-on censé être informé que cron-apt existe ?

                              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 (page perso) . Évalué à 2. Dernière modification le 22/11/13 à 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…

                    Je tiens à préciser que je ne comprends pas pourquoi une recherche entraîne la mise à jour de la liste des paquets.

                    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 . Évalué à 4. Dernière modification le 22/11/13 à 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 . Évalué à 3. Dernière modification le 24/11/13 à 16:09.

              /* mode troll, topix troll :-)

              parce qu'il ne voit plus la librairie qu'a à le gérer

              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.

              installe en cochant tout ce qui était dispo dans anaconda

              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.

              je trouve yum lent

              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

              puppet n'est pas dispo dans les dépots

              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.

              je refuse de faire l'administration de ce truc, pour moi, c'est une verrue sur mon réseau.

              ç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 . É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 (page perso) . É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 . É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 . Évalué à 4.

      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é.

      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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.