Red Hat lance RHEL 6

Posté par  (site web personnel, Mastodon) . Modéré par patrick_g.
30
12
nov.
2010
Red Hat
C'est après deux versions bêta et une RC que Red Hat a annoncé ce 10 novembre la disponibilité publique de Red Hat Enterprise Linux (RHEL) 6, distribution commerciale destinée aux professionnels et aux entreprises. Il s'agit d'une version majeure, apportant un lot conséquent de nouveautés. Red Hat Enterprise Linux 6 est disponible pour les architectures i386, AMD64/Intel64, System z et IBM Power (64-bit).

Red Hat continue d'assurer des mises à jour pour RHEL 5, une version bêta 5.6 ayant été annoncée.

Cette dépêche est sous licence CC BY-SA. NB : Une partie des nouveautés de RHEL 6 ont déjà été couvertes dans la dépêche sur la première version Bêta de RHEL 6, n'hésitez pas à la relire si vous souhaitez plus de détails.

Sommaire :

Installation
Stockage de données et grappe de serveurs
Virtualisation
Prise en charge du matériel
Environnement bureautique
Système et sécurité
Versions de logiciels
CentOS 6 ?
RHEL 3

Installation()

Fruit des avancées de Fedora, Anaconda a pu bénéficier d'améliorations, rien qu'au niveau de l'interface. Il est possible de lancer une installation graphique grâce à VNC, et de créer une phrase de passe lors de la création d'un volume de stockage chiffré (uniquement lors d'une installation via Kickstart). Le DVD d'installation est compatible avec les BIOS et les UEFI.

Stockage de données et grappe de serveurs()

La principale nouveauté de RHEL 6 au niveau des systèmes de fichiers est ext4 : sélectionné par défaut et recommandé, celui-ci succède à ext3 dans RHEL 5. Au niveau des partages réseau, NFS est maintenant par défaut en version 4. Le Device Mapper Multipath (DM-Multipath) crée un seul périphérique lorsque plusieurs chemins sont disponibles pour une unité de stockage, ce qui permet de centraliser la gestion des connexions à ce périphérique. Il est à présent possible de faire de la répartition de charge sur les différents chemins, et de manière dynamique. Côté LVM, l'outil system-config-lvm est actuellement en phase de transition vers gnome-disk-utility, jusqu'à ce que ce dernier atteigne les mêmes fonctionnalités. Il devient possible de créer un volume logique accompagné de quatre miroirs maximum, et de mirrorer les logs du miroir.

Pour la haute disponibilité, en plus d'un nouveau design de l'interface web luci, des améliorations ont été faites sur IPv6, et des machines virtuelles KVM peuvent être utilisées comme services.

Virtualisation()

Red Hat abandonne officiellement Xen en dom0 pour RHEL 6 ! Pour utiliser RHEL 6 comme hôte de virtualisation, le serveur devra avoir les instructions de virtualisation et RHEL utilise uniquement KVM. En système invité, il reste possible, grâce aux options de paravirtualisation (pv-ops), d'utiliser RHEL 6 en domU Xen. L'outil virt-v2v permet de migrer de Xen ou de VMware vers KVM, et sVirt permet d'utiliser SELinux avec de la virtualisation, afin d'empêcher qu'un système hôte soit victime d'une intrusion venant d'un système invité.

Autre amélioration dans la partie virtualisation, l'arrivée de SPICE : le but est de fournir une solution open source complète pour interagir avec des bureaux virtualisés. Celui-ci peut être comparé à VNC ou à RDP. l'implémentation se fait en trois composants : SPICE Driver est le pilote des bureaux virtualisés, SPICE Device est installé sur les hyperviseurs (RHEV) afin que le SPICE Client, installé sur le poste client, puisse s'y connecter pour accéder aux bureaux virtuels. A noter que le composant serveur des SPICE Devices ne peut être installé que sur un système 64 bits

Prise en charge du matériel()

Le noyau i386 de RHEL 6 possède maintenant par défaut les options PAE, ce qui permet d'utiliser plus de 4Go de mémoire vive sur un système 32 bits. Des améliorations ont aussi été faites au niveau de la consommation énergétique du CPU, en mettant plus souvent le CPU en mode idle. Ceci a été rendu possible grâce à l'utilisation massive de l'outil Powertop et de l'activation du mode « tickless » dans le noyau. Tuned est un démon qui surveille le système et permet de modifier dynamiquement certains paramètres du système, et ALPM (Aggressive Link Power Management) permet de passer un disque dur en mode économie d'énergie automatiquement lorsqu'il n'y a plus d'I/O sur celui-ci.

Environnement bureautique()

Tout comme Fedora il y a quelques versions, RHEL bénéficie maintenant d'un nouveau démarrage graphique grâce à Kernel-Modesetting (KMS). Les possibilités de mises en veille (suspend et resume) ont été de ce fait améliorées, les cartes graphiques utilisant KMS plutôt qu'un outil en espace utilisateur. Il est dorénavant plus simple de paramétrer un bureau avec plusieurs écrans : par défaut, un nouvel écran se place à gauche du principal. Bien que le pilote nv soit toujours présent pour les cartes vidéos Nvidia, c'est nouveau qui lui est préféré et utilisé par défaut.

Samba a été mis à jour : il est entre autres possible d'utiliser RHEL 6 avec des Windows 2008 (R2), de chiffrer le trafic entre un client et un serveur Samba, et une nouvelle interface graphique permet de rejoindre un domaine Windows. Grâce à Openchange, certains programmes comme le client mail Evolution peuvent discuter de manière native avec un serveur Microsoft Exchange.

Système et sécurité()

Quelques améliorations dans l'installation de paquets logiciels RPM : la somme de contrôle est maintenant en SHA-256, les paquets sont compressés avec XZ, la clé de signature RSA est maintenant d'une longueur de 4096 bits. PackageKit fait son entrée dans RHEL, permettant une installation graphique aisée des paquets logiciels. Les avancées de Fedora atteignent aussi Yum dans RHEL 6, dont delta RPM, via presto : seules les différences entre le paquet installé et sa version à jour sont téléchargées.

Le noyau Linux utilise à présent CFS comme gestionnaire des processus, et se voit activé kdump par défaut à partir de 4 Giga-octets de mémoire vive pour x86 et x86_64. Pour analyser les performances du noyau, deux outils font leur entrée : frtrace et perf; le premier permet de faire des graphes, et le deuxième surveille, journalise et analyse les évènements systèmes et matériels.

Côté sécurité, apparaissent SSSD (System Security Services Daemon), qui permet une gestion centralisée de l'identification et de l'authentification, et MAC (Mandatory Access Control) vient compléter SELinux. Un bac à sable (sandbox) est aussi disponible, via SELinux, en exécutant des applications dans un domaine SELinux confiné.

Versions de logiciels()

Voici, en vrac, quelques logiciels choisis et leur version (merci Distrowatch) :
Linux Kernel 2.6.32
Firefox 3.5
Thunderbird 3.1.3
OpenOffice.org 3.2.1
GNOME 2.28
KDE 4.3
Apache 2.2.15 avec le support de SNI (vhosts SSL sur le nom) et WSGI
PHP 5.3.2 avec APC
Perl 5.10.1
Bash 4.1
Bind 9.7.0-P2
DHCP 4.1.1
PostgreSQL 8.4.4
MySQL 5.1.47
SystemTap 1.1
GCC 4.4.4
Glibc 2.11
GDB 7.0
xorg-server 1.7.7
Postfix 2.6.6
Sendmail 8.14.4
Samba 3.5.4
Python 2.6.5
OpenSSH 5.3p1

CentOS 6 ?()

Si vous suivez le projet CentOS sur Twitter, alors vous savez que la construction de CentOS 6 a commencé ! Il n'y a bien entendu aucune date prévue, mais comme déjà annoncé dans les colonnes de DLFP, Karanbir Singh rappelle qu'il faut entre 4 et 6 semaines pour qu'une CentOS soit construite à partir d'une Red Hat Enterprise.

RHEL 3()

RHEL 6 est aussi l'occasion de vous débarrasser de vos vieux serveurs sous RHEL 3, puisque Red Hat n'assure plus de support sur cette dernière. CentOS 3 a aussi été annoncé en fin de vie.

Aller plus loin

  • # Commentaire supprimé

    Posté par  . Évalué à 2.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Découverte

    Posté par  . Évalué à 9.

    Je découvre cette distribution, elle a l'air pas mal pour l'entreprise, dommage qu'elle utilise un format de paquet inconnu (il y a d'autres distributions qui l'utilisent ?) au lieu d'un .deb beaucoup moins spécifique à une distribution en particulier.

    C'est dommage qu'il n'existe pas de version plus communautaire, ça leur permettrait de faire murir leur développement tout en ayant plus de testeurs.

    On voit aussi qu'ils utilisent un noyau 2.6.32, je suppose que c'est pour bénéficier du support de Debian qui l'a choisi pour sa prochaine stable.

    « 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: Découverte

      Posté par  . Évalué à -1.

      Hmmm... le format de paquets RPM n'a rien d'exotique, il existe depuis 15 ans et est utilisé dans pas mal de distros comme Fedora, Mandriva, Suse, et des dérivés de Red Hat. Même si Ubuntu a tendance à l'hégémonie sur le marché GNU/Linux, il ne faut pas être Debiano-centré.

      RedHat a une version communautaire, elle s'appelle Fedora, et elle est vraiment pas mal, quoi qu'orientée plutôt vers les développeurs que vers le grand public.

      J'avoue ne pas bien comprendre la dernière phrase, mais en tout cas, RedHat et Debian sont des systèmes très différents et peu apparentés. Regarde un peu Wikipédia.
      • [^] # Re: Découverte

        Posté par  (site web personnel) . Évalué à 5.

        J'avoue ne pas bien comprendre la dernière phrase

        indice : 'dredi ;-)
      • [^] # Re: Découverte

        Posté par  . Évalué à 2.

        J'avoue ne pas bien comprendre la dernière phrase

        Debian a été plusieurs fois accusée d'avoir choisi le 2.6.32 parce que Red Hat l'avait choisi, comme ça le support serait garanti.

        « 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: Découverte

      Posté par  . Évalué à 2.

      Moi je plusse car ça m'a bien fait marrer !
    • [^] # Re: Découverte

      Posté par  . Évalué à 5.

      Oué carrément d'accord,moi j'utilise CentOS, ça n'a rien à voir.
    • [^] # Re: Découverte

      Posté par  . Évalué à -4.

      C'est dommage qu'il n'existe pas de version plus communautaire, ça leur permettrait de faire murir leur développement tout en ayant plus de testeurs.

      Euh, et Fedora, c'est quoi ?

      :)
    • [^] # Re: Découverte

      Posté par  . Évalué à 2.

      Ce qui est marrant c'est qu'il y a 10 ans c'est le .deb que l'on accusait de pas être le standard ! En tout cas bravo, en trois phrases tu as fait très fort...
      Sinon, est-ce qu'Oracle va faire une nouvelle version de Unbreakable sur RHEL 6?
    • [^] # Re: Découverte

      Posté par  (site web personnel) . Évalué à -3.


      dommage qu'elle utilise un format de paquet inconnu (il y a d'autres distributions qui l'utilisent ?) au lieu d'un .deb beaucoup moins spécifique à une distribution en particulier.


      Alors celle-là, c'est la meilleure de l"année. Le .rpm est carrément plus utilisé que le .deb. Dans les distributions majeures, seules Debian et Ubuntu utilisent ce dernier. Le RPM est utilisé par Redhat, Centos, Mandriva/Mageia et OpenSuse. Et je parle pas des distributions plus petites. Ceci sans compter que le RPM est souvent utilisé comme système de paquet secondaire dans d'autres distributions (voire OS comme IBM AIX par exemple). Certaines distributions (comme debian (avec alien) et slackware (avec rpm2tgz)) proposent des outils de conversion du RPM, ce qui, à ma connaissance, n'existe pas avec le .deb.

      Faut se renseigner avant de sortir de pareils trolls.
      • [^] # Re: Découverte

        Posté par  . Évalué à 5.

        ce qui, à ma connaissance, n'existe pas avec le .deb.

        Je te propose de toi aussi te renseigner et de lire un passage de la page de manuel d'alien :

        alien is a program that converts between Red Hat rpm, Debian deb, Stampede slp, Slackware tgz, and Solaris pkg file formats. If you want to use a package from another linux distribution than the one you have installed on your system, you can use alien to convert it to your preferred package format and install it. It also supports LSB packages.

        Il est donc tout-à-fait possible de convertir un .deb en .rpm

        Faut se renseigner avant de sortir de pareils trolls.

        Il faut justement être bien renseigner pour sortir pareil troll :)

        « 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: Découverte

        Posté par  . Évalué à 1.

        C'est bizarre de troller .deb/.rpm/autre sans parler de la LSB. C'est justement la LSB qui fait que rpm est tant utilisé. Je n'ai pas de comparatif mais je crois qu'il y a des notions qui existent chez l'un et pas chez l'autre. Par exemple je crois que rpm ne gèrait pas de notion de paquet virtuel pendant longtemps.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Découverte

          Posté par  . Évalué à 2.

          La suprématie de RPM mesurée en nombre de distros l’utilisant date d’avant LSB.
          • [^] # Re: Découverte

            Posté par  . Évalué à 3.

            Autant affirmer que les autotools dépassent tout les autres ou les ncis (non ce n'est pas une série).

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Découverte

            Posté par  . Évalué à 2.

            C'est pas parce que beaucoup de monde l'utilise que c'est forcément mieux ...
            cf. les OS pour desktop, les navigateurs ouaibe, les dispositions de clavier, les cassettes vidéo, etc.
            • [^] # Re: Découverte

              Posté par  (site web personnel) . Évalué à 2.

              Le degré d'utilisation est aussi un critère (voire le plus gros critère) pour dire que c'est mieux. Si tu parles une super-méga-langue-géniale mais que toi seul la parle, elle a beau être "mieux" de certains point de vues, mais elle reste peu utile et "coûteux" à gérer (troll : non, je ne pense pas du tout à un truc qu'on appelle esperanto ;-) ), et c'est pareil pour les formats de packages. La petite guéguerre rpm vs deb vs les autres, c'est lourd (mais personne ne veut lacher son format, comme personne ne veut lâcher sa langue, donc ça ne va pas s’arranger)
        • [^] # Re: Découverte

          Posté par  . Évalué à 2.

          > C'est justement la LSB qui fait que rpm est tant utilisé

          euh, dans tes rêves. ce n'est PAS DU TOUT le cas.


          rpm est très utilisé parce que Red Hat puis SuSE et Mandrake (des forks à succès) l'ont utilisé. c'est tout. les forks décents de Debian sont rares à coté : aucun à part Ubuntu.

          le fait que la LSB ait préféré les paquets .rpm plutot que les .deb a eu une influence nulle IMNSHO
  • # Clair net précis

    Posté par  . Évalué à -5.

    Simple et complet

    Patrick_g a des mini-moi (Verne_Troyer) qui grouillent dans ce webzine.

    "Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"

  • # ext4 par défaut

    Posté par  . Évalué à 3.

    est-ce que ext4 permet la réduction à chaud des FS (lvm ou non) comme le font d'autres unix proprios ?
    • [^] # Re: ext4 par défaut

      Posté par  (site web personnel) . Évalué à 5.

      Non. C'est pour btrfs (non supporté dans RHEL pour le moment).

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # gloups

    Posté par  . Évalué à 3.

    arg une nouvelle version de RHEL est toujours une source d'angoisse...

    Bon j'exagère mais on a quand meme eut quelques frayeurs avec la dernière. Notemment un truc tout con : le passage de ksh88 à ksh93, bugguée à mort et parfois meme incompatible! Ca fait mal au fesse de voir tous ses scripts ksh se vautrer sans raison... Pourtant on peut pas dire que le ksh soit un langage très jeune, on s'attendrais quand même à un peu de maturité!

    Après quelques recherche, on découvre MirKSH et on peut souffler...

    Oui je sais que le KSH était proprio, mais on choisi pas toujours l'historique d'une entreprise (oui comme dans RHEL !). De toute fawon nous avons dans l'idée de passer à Perl pour nos script d'intégration. Ca devrait pouvoir nous faire tenir plus longtemps.

    (presque) rien à voir, mais Redhat devrait se rappeler qu'il ya encore des boites qui utilisent des macro Excel écrites il y a 20ans (si si). Donc la pérénité et la compatibilité ascendante ça compte!!


    Tout ce commentaire pour un petit package, c'est mesquin je sais!
    • [^] # Re: gloups

      Posté par  . Évalué à 9.

      Mouaif.
      RHEL 6 sort plus de 3 ans après RHEL 5 !
      RHEL 5 (et 4) reste supporté, donc ça ne sert à rien de passer à RHEL 6 si la version précédente marche.
      RHEL est supporté au minimum 7 ans, ça sera probablement 10 pour RHEL 5. C'est plus que correcte dans le monde Linux.
      • [^] # Re: gloups

        Posté par  (Mastodon) . Évalué à 7.

        Y a des gens comme ça, qui suppute pendant deux ans pour savoir s'ils sautent une version de redhat comme d'hab ou s'ils prennent la 5 direct, et sauteront la 6. Et ils font plein de réunions avec plein de powerpoint pour supputer sur un calendrier qu'en deux heures de lectures il était possible de connaitre.

        Plutot que Perl (assurance de pérénité ? sincèrement j'ai des doutes, vu les révolutions perl en ce moment, enfin bon faut simplement lire ou demander à un spécialiste pour savoir si l'ascendance ne risque pas d'en prendre un sérieux coup d'ici peu), pourquoi ne pas -enfin?- considérer ZSH comme remplaçant pour le bon vieux ksh troué buggué selon la version ? Faut faire croire que l'idée est interne, c'est le plus dur en fait.
        • [^] # Re: gloups

          Posté par  . Évalué à 2.


          Plutot que Perl (assurance de pérénité ? sincèrement j'ai des doutes, vu les révolutions perl en ce moment, enfin bon faut simplement lire ou demander à un spécialiste pour savoir si l'ascendance ne risque pas d'en prendre un sérieux coup d'ici peu)


          Je n'envisage pas du tout Perl6 comme un problème si c'est lui dont tu parles, vu qu'il s'agit d'un interpreteur totalement différent. A mon avis, si Perl6 sort un jour, il faudrait envisager de renommer en un autre langage....

          Sinon Perl5 est très stable et la politique actuelle est de garder strictement la compatibilité au fil des versions. C'est un énorme atout en entreprise et justement un gage de pérénité.

          Le seul problème à tout ça est que la compatibilité à tout prix oblige à garder des reliquats pas toujours heureux (au hasard, Perl5 supporte encore les appels de fonctions "&toto $x,$x" au lieu d'une syntaxe plus récente et logique "toto($x,$y)")

          L'autre gros atout est qu'il est porté sur Windows, ce qui permet aux intégrateur multi-OS de n'apprendre qu'un seul langage.
          Et là, ça enlève un point à ZSH...
          • [^] # Re: gloups

            Posté par  . Évalué à 1.

            ZSH tourne aussi sous Windows (via Cygwin)
      • [^] # Re: gloups

        Posté par  . Évalué à 2.

        en l'occurence, nous avions encore des RHEL 2 qu'il fallait migrer car fin du support. Nous avons donc décider de tout passer en 5 cette année. Donc oui je suis assez d'accord avec toi. D'ailleurs la mise à jour en 6 n'est pas pour tout de suite!
    • [^] # Re: gloups

      Posté par  . Évalué à 2.

      pour ton info, vu que tu sembles utiliser ksh, la dernière mouture d'aix (7) intègre ksh93 avec la complétion et tout (il était vraiment temps). Y en avait marre de devoir faire "esc + =" ou "esc + *", il restait possible d'installer bash mais bon c'était pas par défaut donc bon..
      • [^] # Re: gloups

        Posté par  . Évalué à 3.

        j'espere que je dis pas de betises, car ca fait longtemps, mais un bon vieux "set -o emacs" et tu as la completion par tab, même sur des antiques Aix 4... Mais à l'usage on revient vite aux raccourcis Vi, car on prend vite les reflexes à force de scripter avec!
        • [^] # Re: gloups

          Posté par  . Évalué à 3.

          Plus ou moins lié et pour ceux qui s'intéressent aux vieux trucs: un pdf de Eric Fischer, le type qui a ajouté les commandes emacs au terminaux.

          http://www.usenix.org/event/usenix99/full_papers/fischer/fis(...)
        • [^] # Re: gloups

          Posté par  . Évalué à 1.

          hélas non, la complétion par tab n'est pas accessible même en mode emacs, ce qui marche en revanche ce sont bien les flêches.

          Mais finalement, le mieux reste quand même le mode "vi", le top serait d'y adjoindre la complétion par tab mais je ne sais pas si c'est dispo en mode "vi"...
    • [^] # Re: gloups

      Posté par  . Évalué à 3.

      De toute fawon nous avons dans l'idée de passer à Perl pour nos script d'intégration. Ca devrait pouvoir nous faire tenir plus longtemps.

      Fais pas ça malhereux !!!! Tu risques de tomber sur un ayatollah de la sécurité qui décidera de désinstaller Perl des serveurs, et tu te retrouvera tout idiot avec tes scripts qui ne marchent plus.
      • [^] # Re: gloups

        Posté par  . Évalué à 1.

        ??
        C'est la première fois que j'entend dire que Perl n'est pas assez sécure pour des scripts?

        En cas les scripts Shell sont plus sécurisés que des scripts Perl?

        A moins que tu ne parles des installation de Perl sur Windows, où c'est effectivement arrivé... Il y a des admin windows qui ne connaissent pas trop ces notions de "script". Ou alors ils te sortent "powershell" et là je comprend que ça leur fasse peur !
        • [^] # Re: gloups

          Posté par  . Évalué à 10.


          C'est vrai ça, Perl c'est hyper-secure.

          Même avec le source il est impossible de trouver des failles tellement c'est illisible.
          • [^] # Re: gloups

            Posté par  . Évalué à 4.

            your comment is infected with linux32.perl-troll. Please choose an action :
            - delete your comment
            - apologise right now
            - do nothing (it's friday!)


            sans rire Perl est vraiment un excelent langage de script. Par contre il est évident qu'il faut utiliser un sous-ensemble de la syntaxe. En effet le seul vrai probleme de Perl vient surtout des multiples syntaxe possible d'une même instruction. Ce problème semble être d'ailleurs exacerbé dans Perl6, mais ce n'est pas le sujet!

            En formant les intégrateurs aux bonnes pratiques de codage et en standardisant l'écriture, les scripts d'admins peuvent être beaucoup plus clair qu'en sHell !

            A ce sujet l'excelent bouquin de Damian Conway "Perl Best Practices" qui est devenu mon livre de chevet de bureau et qui explique tout à fait cette problématique.
            • [^] # Re: gloups

              Posté par  (site web personnel) . Évalué à 2.

              "En effet le seul vrai probleme de Perl vient surtout des multiples syntaxe possible d'une même instruction [...] En formant les intégrateurs aux bonnes pratiques de codage et en standardisant l'écriture, les scripts d'admins peuvent être beaucoup plus clair qu'en sHell !"

              En gros, faire du python quoi.
              • [^] # Re: gloups

                Posté par  . Évalué à 3.

                On a effectivement longuement hésité avec Python... Mais il se trouve que passer de sHell à Perl se fait beaucoup naturellement. Et puis le python fait encore peur aux non-developpeurs, en particulier à cause du mot "objet".
                D'autre part, faire du python pour faire des scripts d'exploitation, c'est un peu tuer une mouche avec un laser. Nous avons surtout besoin de manipuler des fichiers textes (merci regexp) et de manipuler des structures simples. En perl, il n'y a que 2 structure possibles (hash et tableau), et qui sont de plus très simple à manipuler.

                Les architectures étant de plus en plus complexes, Python sera peut-être la prochaine évolution!
                • [^] # Re: gloups

                  Posté par  . Évalué à 3.

                  C'est clair que si tes scripts se basent essentiellement sur des commandes Unix,
                  Python n'est à mon avis pas adapté.
                  • [^] # Re: gloups

                    Posté par  . Évalué à 3.

                    Bien d'accord pour moi python n'est pas un langage "glue" alors que perl si.
                    Après quand il y a très peu de traitement et que le langage ne sert quasiment que de glue du shell POSIX (celui qui marche) c'est très bien.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: gloups

                      Posté par  (site web personnel) . Évalué à 3.

                      "Bien d'accord pour moi python n'est pas un langage "glue" alors que perl si."

                      Ha bon, perso je le voit comme un langage qui permet *aussi* de jouer la glue. Mais pas uniquement.

                      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

                • [^] # Re: gloups

                  Posté par  . Évalué à 2.

                  Et pourquoi pas du Tcl? Ca répond à tes critères de simplicité, ça tourne sous Windows sans passer par Cygwin.

                  C'est le langage de script qu'on utilise dans ma boîte, et ça marche nickel.

                  La syntaxe est très simple, ce qui facilite son apprentissage.
                  • [^] # Re: gloups

                    Posté par  . Évalué à 4.

                    Évidement, il y a aussi une question de mode. Quand on cherche un langage de script moderne, Tcl ne vient pas immédiatement à l'esprit.
                    Disons qu'il existe encore certains préjugés avec les vieux langage... Et sa syntaxe d'un autre age n'aide pas beaucoup!
    • [^] # Re: gloups

      Posté par  . Évalué à 2.

      Pour l'histoire ksh, il suffit juste que les scripts pointent sur /bin/pdksh ou /bin/ksh93 et surtout pas /bin/ksh et le tour est réglé.
      Nous avons eu le même problème au boulot, du au fait que /bin/ksh pointe vers /etc/alternatives/ksh qui pointe lui même vers /bin/pdksh ou /bin/ksh93... Donc si dans tes scripts tu pointais sur /bin/ksh, et que tu installes par exemple pdksh, ça tue tes liens et tes scripts au passage...
      Vraiment mal foutu...
      En pointant sur le lien direct du coup ça fonctionne mieux. C'est idiot de changer le lien symbolique sans prévenir les utilisateurs.
      • [^] # Re: gloups

        Posté par  (site web personnel) . Évalué à 1.

        Le système des alternatives est pas mal en fait pour gérer ça mais c'est vrai que je trouverais plus logique que l'installation du paquet pdksh ne modifie pas l'option par défaut et laisse l'admin choisir son ksh par défaut ...

        Sinon pour info pour ceux qui connaissent pas, ces fameux liens symboliques ces gèrent avec la commande update-alternatives :

        update-alternatives --config ksh

        Ce qui donne :

        Il existe 2 programmes qui fournissent « ksh ».

        Sélection Commande
        -----------------------------------------------
        + 1 /bin/pdksh
        * 2 /bin/ksh93

        Entrez pour garder la sélection courante [+] ou saisissez le numéro de type de sélection :
        • [^] # Re: gloups

          Posté par  . Évalué à 2.

          L'administrateur peut aussi modifier les priorités pour ne pas avoir de problème.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: gloups

            Posté par  (site web personnel) . Évalué à 1.

            Lapin compris ...

            De quelles priorités tu parle ?
            • [^] # Re: gloups

              Posté par  . Évalué à 3.

              Tu peut avoir plusieurs paquets installés en parallèles qui proposent une alternative pour ksh. Pour savoir le quel choisir, il y a un système de priorité (celui qui a la plus élevée est choisis). Je crois que c'est entre 0 et 100.

              Il est possible de modifier cette valeur pour que l'alternative que l'on choisi ne soit jamais mise à mal par l'installation d'un nouveau paquet.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: gloups

                Posté par  (site web personnel) . Évalué à 1.

                Merci pour la précision.

                Le système de priorité est expliqué dans la page de man en plus, honte sur moi, ça aurais quasiment mérité un RTFM ça ;)

                Après lecture de la doc, le système de priorité est appliqué uniquement si le groupe d'alternative est en mode auto.
                Dès qu'on change manuellement l'alternative avec update-alternative le groupe passe en mode manuel :

                mode manuel
                Quand un groupe de liens est en mode manuel, le système des «alternatives » ne modifie pas le paramétrage de l'administrateur système.


                Du coup, c'est même plus simple que de jouer avec les priorités. Une fois en mode manuel les liens ne bougerons pas quel que soit les paquets installés après.
  • # juridisme, maladie infantile

    Posté par  (site web personnel) . Évalué à -4.

    Nan, mais j’y crois pas, vous allez coller une licence à chaque fois que vous lâcherez un prout, ou quoi ???
    Les libristes commencent à sombrer dans un juridisme tatillon, pointilleux, vétilleux et omniprésent de plus en plus malsain et paralysant.
    • [^] # Re: juridisme, maladie infantile

      Posté par  . Évalué à 3.

      C'est une façon de dire « Vous pouvez reprendre la dépêche si vous voulez ». La licence est bien connue est donne clairement les conditions.

      La licence n'est pas là pour restreindre l'utilisation, au contraire elle est là pour donner des droits (puisque sans licence, aucun droit de copier / etc).
    • [^] # Re: juridisme, maladie infantile

      Posté par  (site web personnel) . Évalué à 5.

      Par défaut, on a le droit de lire la dépêche, et rien d'autre.
      Donc oui, c'est intéressant d'avoir une petite ligne précisant qu'on a le droit de modifier/modifier comme on souhaite.
      Ce n'est pas tatillon, c'est juste une information qu'on a des droits supplémentaires par rapport à d'habitude.

      Juridisme? Il faut faire comment de ton point de vue pour dire qu'on autorise la modification et diffusion libre? Car la, je ne vois pas plus petit qu'une phrase, à part modifier Templeet pour mettre une petite case dans un coin "licence" (un mot mieux qu'une phrase, ouais...).
      Bref, comment toi tu ferais pour qu'on sache quel droits on a sur le texte (c'est intéressant de savoir, oui, on n'est pas de vilains contrefacteurs)? On t'écoute, propose.
    • [^] # Re: juridisme, maladie infantile

      Posté par  . Évalué à 4.

      Moi ça fait longtemps que je lâche des prouts, mais je n'en faisais pas profiter les autres à ce point jusqu'ici :)

      Plus sérieusement, le "juridisme pointilleux", je pense qu'il se justifie facilement:
      1 une phrase ou une case, c'est pas très long
      2 ça peut toujours être utile à d'autres. Plus dans le cas de dépêches que de coms sans doute. C'est ce qui compte non ?

      Et puis, c'est aussi une manière de signifier qu'il serait plus mieux que le plus de prouts de la zone qu'est la toile soient libres de diffusion au moins. Ça serait utile.
  • # Licence ?

    Posté par  . Évalué à 5.

    Dites moi, je profite d'un post sur cette distribution, pour savoir si quelqu'un peux m'expliquer comment fonctionne la licence d'une distrib Red Hat ?

    Je m'explique : la distrib reprend du code GPL, elle est donc sous GPL en grande partie c'est incontestable.


    Cela veut dire : est-ce j'ai le droit de m'installer une copie d'une version qu'un copain qui l'aurait acheter m'aurait filé ?

    Ou bien suis - je obligé de me recompiler la distrib toute entière avec mes petites mains (comme font les gars de Cent OS) ?
    • [^] # Re: Licence ?

      Posté par  . Évalué à 3.

      Les sources de la distribution sont libres. les trademark RedHat ® et le logo du chapeau rouge sont copyrightés. Pour pouvoir utiliser la distribution binaire (les rpms) RHEL, il te faut une licence valide. La licence te procure un droit d'usage ainsi qu'un support, et ce pour chaque serveur sur lequel tu auras installé RHEL.

      Red Hat propose différentes solutions selon tes besoins : VM, physique, hyperviseur, et selon le nombre de CPU et cœur sur ta machine.

      Si tu désires installer et utiliser un serveur RHEL, il te faudra une licence. Sinon, tu dois recompiler les sources (disponibles car GPL) ou plus simplement prendre du CentOS.

      Je n'ai pas toutes les sources à dispo, ce n'est que de mémoire mais je ne pense pas trop me tromper...

      NB : en soit, je pense que Red Hat n'a pas obligation de fournir les sources de sa distribution directement à tout le monde, juste à leur clients qui ont acheté le licences, je pense. Menfin, ce n'est qu'une note :).

      J'en profite pour pointer sur la politique de la firme concernant les brevets logiciels : Si Red Hat se dit contre les brevets logiciel, elle en utilise/produit quand même. En contre partie Red Hat promet de ne pas attaquer tout utilisateur de ses brevets logiciels tant que ceux-ci sont dans un logiciel Open Source (licence reconnue par Red Hat)
      http://www.redhat.com/legal/patent_policy.html
      • [^] # Re: Licence ?

        Posté par  (site web personnel) . Évalué à 5.

        > Si tu désires installer et utiliser un serveur RHEL, il te faudra une licence.

        Non. Tu peux très bien utiliser RHEL sans licence autre que celles couvertes par le logiciel inclus dans la distribution (GPL, BSD,...). Par contre, si tu désires avoir accès aux mises à jour via Red Hat Network, à la base de connaissance et au support ou avoir une relation commerciale quelconque avec Red Hat, il te faut un « abonnement » (subscription) pour chacun des systèmes RHEL de ton organisation. Si tu as un système RHEL non couvert par la souscription, le contrat est rompu et Red Hat n'a plus d'obligation envers toi.

        Disclaimeur : Ne croyez pas tout ce que vous lisez sur internet. Je suis pas juriste. Je peux me tromper ou m'exprimer de manière ambigüe. Les circonstances de chacun peuvent changer. Mais je travaille au support Red Hat. Si vous voulez être sûr, faites lire https://www.redhat.com/licenses/ à vos avocats.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: Licence ?

          Posté par  . Évalué à 1.

          Hé bien merci pour ces infos ça réponds à des questions que je me posais depuis un petit moment.
  • # toute la page en italique

    Posté par  (site web personnel) . Évalué à 4.

    Il y a un balise "i" non fermée au début de cet article (« Cette dépêche est sous licence » ...).

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Suivre le flux des commentaires

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