Red Hat Enterprise Linux 5.3

Posté par  (site web personnel, Mastodon) . Modéré par tuiu pol.
Étiquettes :
20
20
jan.
2009
Red Hat
Red Hat a annoncé ce 20 janvier la version 5.3 de Red Hat Enterprise Linux (RHEL), distribution commerciale destinée aux professionnels et aux entreprises. Il s'agit d'une version mineure, mais pas dénuée d'améliorations, comme par exemple en virtualisation (encore !), en prise en charge de matériel et en chiffrement de disque dur.

Quelques-unes des améliorations et correctifs apportés par cette nouvelle version sont détaillés dans la suite de la dépêche. Virtualisation
RHEL 5.3 gère encore plus de processeurs physiques, et monte la barre à 126 (contre 64 en 5.2), pour un téra-octet de mémoire vive totale. Du côté des machines virtuelles, celles-ci pourront posséder jusqu'à 32 processeurs et 80 giga-octets de mémoire vive. Le nombre de disques et d'interfaces réseaux virtuels a lui aussi été augmenté.

Support matériel
Les processeurs Intel nouvelle génération (plateforme Tylersberg/Nehalem pour ceux qui suivent l'actualité matérielle) sont annoncés comme supportés, en particulier pour leurs performances et leurs possibilités en virtualisation.

OpenJDK
Red Hat mise sur Java, on le sait depuis le rachat de JBoss (serveur d'application web). Après Fedora, RHEL 5.3 intègre OpenJDK 6, avec tous les avantages qui en découlent (voir la dépêche sur le sujet)

Diagnostic
Dans RHEL 5.2, le tracing en mode utilisateur avec SystemTap était présenté en avant-première technologique, cet attribut est maintenant retiré et on peut officiellement diagnostiquer et monitorer des applications.

Sécurité et chiffrement
Il est à présent possible de chiffrer entièrement un disque dur, que ce soit au niveau bloc ou au niveau du système de fichiers. On peut, entre autres, chiffrer le disque système et la swap, ce qui devrait plaire aux utilisateurs d'ordinateurs portables et à ceux qui se soucient du reconditionnement des disques durs (panne, revente de serveur ou de station de travail obsolète).

Gestion des paquets
Yum est mis à jour en version 3.2.18, apportant une meilleure rapidité d'exécution. RPM est lui aussi mis à jour, il s'agit de la version de Fedora 9, et ne devrait plus créer de fichier .rpmsave et .rpmnew (sauvegardes des fichiers de configuration des paquets) inutilement.

Cluster et stockage de données
Outre les correction dans cman, l'utilitaire de gestion de cluster Red Hat, des améliorations sont faites au niveau de la gestion iSCSI : il devient possible de démarrer sur un disque iSCSI grâce au support de l'iSCSI Boot Firmware Table (iBFT). GFS 2 (le système de fichier cluster de Red Hat) était inclus en tant que module noyau dans RHEL 5.2, il fait à présent partie du paquet du noyau.

Parmi les 150 mises à jour qui composent cette version mineure de RHEL, on trouvera aussi des correctifs de bugs, de sécurité, ainsi que des améliorations sur l'économie d'énergie.

Aller plus loin

  • # Y'en a que pour HREL et fedora ici

    Posté par  . Évalué à -10.

    linuxfr est infiltré?
    (et c'est très bien pour moi, fedoriste que je suis ;) )

  • # RHEL et les PME ?

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

    Il y a quelques années, j'ai administré le réseau d'une PME de 50 personnes. Le serveur NT4 était le serveur maître, et j'avais été je l'avoue assez bluffé par la simplicité de l'admin avec NT4. W2k était un peu plus (trop ?) compliqué. Linux à l'époque ne remplissait pas les critères.

    Dans ce genre de contexte, le serveur doit être administrable par des non informaticiens, la petite taille ne justifiant pas un informaticien à plein temps. Tout au plus pour les problèmes et les gros changements doit-on appeler un spécialiste (qui coute cher).

    Les besoins quotidiens que l'on avait étaient :

    - Ajouter/supprimer un compte utilisateur
    - Gérer les droits de ce compte, en particulier sur certains répertoires de données partagées
    - Gérer les différentes imprimantes, en pouvant gérer une sorte de matrice indiquant que tel compte s'il se connecte sur tels machines imprime sur l'imprimante 1, et l'imprimante 2 dans d'autres cas (quand certains se déplacent avec leur portable, ça peut être pratique)
    - Les données personnelles et la config logiciel de chaque utilisateurs, ou au moins une partie, ainsi que leur profil doivent pouvoir circuler, de sorte qu'un tel se log sur une machine une autre, il retrouve tous ses outils et settings installés.
    - De même que les comptes utilisateurs, la gestion des mails doivent être facilité par une interface permettant d'ajouter, supprimer, de permettre ou pas un accès externe via webmail
    - gestion de sauvegarde simple.
    - Gestion simple de VPN.


    Je sais pertinemment que tous les logiciels pour faire tout cela existent sous Linux. Ce n'est pas la question que je me pose.

    Ma question est plutôt de savoir s'il y a une interface simple, unifiée, accessible, administrable par un non informaticien (un cadre, un ingénieur) ?
    Windows permet pas mal de chose, mais devient difficile à manier (NT 4 était un bon compromis entre pauvreté des fonctions et simplicité d'administration) pour des non spécialistes.

    Webmin me semble un bon candidat, mais est trop riche, pas assez unifié, et un peu difficile à manier. Cela reste un outil pour informaticien.

    RHEL est-il en mesure d'offrir tous ces services de manière simple ?

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: RHEL et les PME ?

      Posté par  . Évalué à 10.

      Mon avis d'admin Windows, c'est que même un informaticien a besoin de formation dans les domaines qu'il ne maitrise pas totalement, alors un non-informaticien qui voudrait s'improviser administrateur sous Windows ou sous Linux, ça n'existe pas sans un investissement minimum : de la formation, du temps réservé, et une assistance externe (SSLL par ex.) pour réaliser le déploiement d'une solution adaptée (et surtout éviter d'installer n'importe quoi n'importe comment...)
      Après, que la personne soit cadre ou ingénieur, si c'est dans l'agroalimentaire je ne suis pas certain que ce soit la panacée. Si on parle de 50 employés, autant embaucher un technicien même débutant, et laisser les cadres mériter leur salaire... si on parle d'un PDG et 49 commerciaux, autant prendre des gmail consultables avec 49 abonnements iPhone et 1 BlackBerry, tout le monde sera ravi... :P

    • [^] # Re: RHEL et les PME ?

      Posté par  . Évalué à 4.

      > RHEL est-il en mesure d'offrir tous ces services de manière simple ?

      Oui et non.
      Le problème ici n'est pas seulement de fournir des interfaces graphiques. Il faut un tout cohérent et ça devient beaucoup plus compliqué. Même si Windows sucks, c'est un domaine où MS explose tout le monde.
      Pour les interfaces graphiques, RHEL a system-config-* (on y trouve de tout, lvm, cluster, samba, etc).

      Mais pour une PME, les system-config-* sont loin d'être suffisant.
      Un projet comme FreeIPA est particuliairement important : http://www.freeipa.org/ .
      Il est actuellement en développement intensif. J'imagine qu'il fera parti des fonctionnalités les plus soulignée par Red Hat de RHEL6.

      • [^] # Re: RHEL et les PME ?

        Posté par  . Évalué à 5.

        dans ma boite (90 personnes env.) le serveur ne nous sert que pour :
        - un serveur de fichier ( un bete partage de disque dur)
        - active directory pour la création de compte utilisateur
        - une base de donnée
        - et la sauvegarde sur bande

        Je connais pas RH mais je me dis que dans notre cas, une distrib comme mandriva avec son centre de controle tout graphique devrais pouvoir faire affaire pour un non informatitien

      • [^] # Re: RHEL et les PME ?

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

        Free IPA ne ferait-il pas la même chose que le Mandriva Directory Server ( http://www.mandriva.com/enterprise/fr/produits/mandriva-dire(...) ), lequel est bien avancé et disponible en paquets Debian en plus de Mandriva bien sûr ? C'est ce que nous avons dans notre entreprise depuis 2-3 ans et non seulement ça marche très bien, mais en plus c'est pratique !

        • [^] # Re: RHEL et les PME ?

          Posté par  . Évalué à 4.

          Je crois que ça va peut plus loin... FreeIPA ne fait pas "que" LDAP.
          Je te conseille de voir la doc de FreeIPA. Enfin FreeIPA utilise Fedora Directory Server (qui vient de Netscape Directory Server). Il y a support de réplication, Kerberos, etc.
          Afin, FreeIPA en est à ses débuts. L'un des buts est de remplacer un Active Directory de MS par FreeIPA (Policy group, etc).

          • [^] # Re: RHEL et les PME ?

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

            Il y a aussi kerberos dans le MDS mais c'est vrai qu'ils ne parlent pas de « policies ». Cela dit avec l'avènement de samba 4, ça m'étonnerait qu'à moyen terme leur but ne soit pas aussi de remplacer totalement AD, vu que ça le fait déjà en bonne partie (c'est d'ailleurs un AD qu'on a remplacé avec ;-) ). Quoiqu'il en soit, il n'y a pas de mal à ce que deux projets se penchent sur la question. Vu la complexité de la tâche, il est fort probable qu'ils auront des approches différentes et donc contenteront des besoins différents.

            NB: pour avoir posé la question, la synchro/réplication ils peuvent le faire mais c'est encore du sur-mesure.

    • [^] # Re: RHEL et les PME ?

      Posté par  . Évalué à 1.

      Sinon tu peux choisir Suse Linux Enterprise Server 10 SP2 de Novell qui est assez simple a administrer même pour un débutant.

      • [^] # Re: RHEL et les PME ?

        Posté par  . Évalué à 1.

        bonjour a tous,

        et quelqu'un saurait comment passer de la 5.2 a la 5.3 ?

        • [^] # Re: RHEL et les PME ?

          Posté par  . Évalué à 2.

          Si tu as une 5.2, il n'y a rien à faire, tu vas passer à la 5.3 lors de la mise à jour classique.

  • # Nombre de processeurs supportés

    Posté par  . Évalué à 6.

    Attention, vraie question :

    à quoi est due la limitation sur le nombre de processeurs supportés ?
    126, c'est déjà pas mal sur une seule machine, mais quelles sont les raisons logicielles (parce que ça à l'air logiciel tout ça) qui limitent d'en avoir bien plus ? (allez, disons plus de 1000)

    • [^] # Re: Nombre de processeurs supportés

      Posté par  . Évalué à 5.

      J'en vois 2 :

      a) Le systeme ne monte pas en charge convenablement au dela
      b) Ils n'ont pas le HW pour tester cette config

      Sinon, je dois avouer que je suis surpris par le chiffre de 126, 128 j'aurais compris, mais 126 est un peu "hors-norme"

      • [^] # Re: Nombre de processeurs supportés

        Posté par  (site web personnel, Mastodon) . Évalué à 6.

        Je viens de lire dans les release notes :
        The maximum CPUs must be restricted to less than 128 when on a 128 or greater CPU system. The maximum that is supported at this time is 126. Use the maxcpus=126 hypervisor argument to limit the Hypervisor to 126
        Cela semble être une limitation de l'hyperviseur

    • [^] # Re: Nombre de processeurs supportés

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

      à quoi est due la limitation sur le nombre de processeurs supportés ?

      Je pense que quelqu'un qui choisit d'acheter Red Hat est intéressé avant tout par le support. Je comprend que jusqu'à 126 processeurs, Red Hat prend en charge tous les problèmes. Au delà, le support peut répondre « on sait pas faire » (mais ils vont sûrement tenter d'aider au mieux).

      Côté noyau, la limitation est 4096 processeurs et 512 nœuds depuis Linux 2.6.27 (elle était de 255 processeurs et 32768 nœuds avant). Il y a de gros progrès dans le noyau quant aux performances avec beaucoup de cœurs/processeurs.

      • [^] # Re: Nombre de processeurs supportés

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

        /me travaille au support RHEL et a passé une partie de la journée à fermer de tickets, merci 5.3

        > Au delà, le support peut répondre « on sait pas faire » (mais ils vont sûrement tenter d'aider au mieux).

        Effectivement, à partir du moment où les limites sont dépassées, on sort du cadre du support normal et on "peut" faire du "best effort" sans aucune garantie mais ça dépend entièrement de la personne qui a le ticket sur le moment.

        En fait, si le problème a rien à voir, on va sans doute pas remarquer que la limite est dépassée. Après, si on suspecte que le dépassement de la limite est lié au problème, ben on va généralement demander de reproduire avec une configuration supportée.

        Personnellement j'ai eu au moins deux clients dans cette situation. Un dépassement de la taille maximum de filesystem et de la quantité de RAM. Dans le premier cas, fsck segfaultait et le noyal avait tendance à crasher en accèdant au dit filesystem et dans l'autre, le système paniquait sur un nmi_watchdog sous memory pressure (ben ouais, ça mettait trop longtemps pour libérer des pages). C'est typiquement des problèmes qu'on n'investigue pas vraiment mais pour lesquels on peut proposer des workarounds plus ou moins satisfaisants (upgrader vers RHEL 5 et désactiver nmi_watchdog respectivement). C'est dommage, il était joli ce coredump de fsck de 2Go :)

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

        • [^] # Re: Nombre de processeurs supportés

          Posté par  . Évalué à 2.

          > Effectivement, à partir du moment où les limites sont dépassées, on sort du cadre du support normal et on "peut" faire du "best effort" sans aucune garantie mais ça dépend entièrement de la personne qui a le ticket sur le moment.

          C'est le cas pour les limites "techniques". Red Hat ne serait pas contre de proposer du support pour 1000 ou plus de CPU, mais actuellement ce n'est globalement pas satisfaisant.

          Il y a aussi les limites "commerciales". Par exemple certaines variantes de RHEL sont limitées à 2 cpu. Cette limite n'est pas technique, elle est seulement commerciale (c'est le même noyau quelque soit la variante de RHEL). Notons que si on utilise une variante qui supporte que 2 cpu sur un système avec 16 cpu, ça marche toujours. Mais le client n'a plus de support. Le produit est libre (on a le droit de l'utiliser même si on dépasse les limites) mais le support ne l'est pas (ce qui se comprend bien).

        • [^] # Re: Nombre de processeurs supportés

          Posté par  . Évalué à 6.

          En passant, je trouve très bien que Red Hat disent ce qui est réellement supporté ou non.
          Par exemple GFS 2 est dans RHEL 5 depuis le début. Ce n'est que maintenant qu'il est supporté (donc tu vas avoir du boulot avec GFS 2 maintenant :-)).
          Beaucoup d'autres distributions disent tout supporter, mais derrière ça ne suit pas alors que t'as payé !

          Par exemple Canonical, pour Ubuntu 8.04 LTS, supporte GFS 2. Bien avant Red Hat alors que c'est Red Hat qui développe GFS. Ça laisse songeur...

          • [^] # Re: Nombre de processeurs supportés

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

            Ben ce qui est en « Technology Preview », c'est pas supporté. GFS2 était en tech preview jusqu'à la 5.3. Ce qui est tech preview est indiqué dans les release notes. La définition formelle et juridique de ce qu'on supporte est décrite là (annexe 1, section 2.2) : https://www.redhat.com/licenses/Enterprise_Agr_France.pdf

            Dans le doute, tu demandes au support avant de déployer.

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

            • [^] # Re: Nombre de processeurs supportés

              Posté par  . Évalué à 2.

              > Ben ce qui est en « Technology Preview », c'est pas supporté. GFS2 était en tech preview jusqu'à la 5.3.

              J'ai bien compris :-)
              J'apprécie beaucoup cette précision dans Red Hat qui dit clairement ce qui est ou non supporté.

              • [^] # Re: Nombre de processeurs supportés

                Posté par  . Évalué à 2.

                Moi j'apprécie beaucoup que tu apprécies beaucoup cette précision dans Red Hat qui dit clairement ce qui est ou non supporté, mais j'apprécie moins que ce soit la deuxième fois que tu nous le dis.

                Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

  • # Pfiou ça va trop viiiite!!

    Posté par  . Évalué à 4.

    Le projet sur lequel je travaille se faisait jusqu'ici sur RHEL3, on est train de migrer vers RHEL4... Certes, c'est le secteur de la défense mais bon.. Finalement, je pense que l'on aura toujours une version de retard : quand RHEL6 sortira, la DSI se décidera en mettre en place un serveur avec la version 5!

    • [^] # Re: Pfiou ça va trop viiiite!!

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

      engagez-vous, rengagez-vous qu'ils disaient ! :D

      sérieux, autant passer à RHEL 5 déjà disponible quand même ;-) (c'est l'occasion de se débarrasser du proprio qui ne suit pas, installer du PostgreSQL partout, du JBoss bien sûr si nécessaire et les applis standards du libre plutôt que des attardés à la traîne à chaque fois qui ralentissent les projets).

    • [^] # Re: Pfiou ça va trop viiiite!!

      Posté par  . Évalué à 7.

      à l'époque où je faisais encoe de l'admin., on employait Debian précisément à cause de son cycle de vie de longueur comparable à ceux des developpeurs des applis hébergées.

      Et encore, on a encore employé du SCO SVR3.2jusqu'en 2005

      Non pas que ce soit nécessaire, mais comme les developpeurs avaient toujours tendance à incriminier le système sous prétexte que les interfaces avaient évolué depuis leur passage à l'IUT...

  • # RHEL, une certaine vision de GNU/Linux.

    Posté par  . Évalué à 10.

    En général, il y en a que pour la dernière Ubunut/Mandriva/Fedora...
    On a même l'impression que les distributions se doivent de n'avoir que les dernières versions, qu'il n'y a que comme ça qu'on peut intéresser l'utilisateur lambda.

    RHEL 5 est sorti en mars 2007 si j'ai bonne mémoire. Près de 2 ans après, Red Hat sort encore une RHEL 5 (update 3) avec un lot significatif d'amélioration. Et le tout reste compatible binaire et source. Ce n'est pas un mince exploit, il n'y a que Red Hat et Novell à le faire.
    C'est du Red Hat, c'est du sérieux, et "donc" l'annonce oublie de dire qu'il y a Firefox 3, OOo 3 et le tout dernier NetworkManager. Ce sont des programmes qui comptent plus pour l'utilisateur que d'avoir Gnome 2.n ou 2.n+2 . Sûr qu'il doit y avoir des mises à jour de Thunderbird, Evolution et autre, je n'ai pas vérifié.
    Cette mise à jour de RHEL a aussi une belle pile de driver en plus pour contenter le matériel récent (wifi notamment).
    Il y aura-t-il une RHEL 5.4 ? Peut-être. En passant, le support de RHEL est passé de 7 à 10 ans !
    Imaginez la tranquilité d'esprit pour ceux qui déploient du RHEL. Pensons aussi aux intégrateurs (Dell, HP, etc).
    Bref, pour moi c'est clair, le GNU/Linux pour les PME (qui ont une équipe informatique réduite) passera par RHEL ou équivalent. Pas par un truc qui casse l'API et les habitutes tous les 12 mois ou même 36 mois ce qui n'est pas assez si on considère qu'il faut des mois à une entreprise pour adopter une nouvelle version d'un OS.

    > OpenJDK

    Mieux, c'est un OpenJDK certifié. Red Hat peut lui donner le nom de Java comme Sun le fait.

    Red Hat a toujours été beaucoup impliqué dans le libre. Mais depuis longtemps on pouvait trouver (un peu séparé du reste) un machine Java sans les sources (la machine d'IBM).
    Ce n'est maintenant plus le cas et le mérite en revient évidemment à Sun mais aussi à Red Hat qui est un gros contributeur Java.

    • [^] # Re: RHEL, une certaine vision de GNU/Linux.

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

      je suis resté sur ma faim pour le volet virtualisation dans cette dépêche : quelle solution ? VirtualBox soutenu par Sun, Kernel-based_Virtual_Machine ? :D libvirt apporte quoi concrètement ? (en terme de réponse à "oh bah moi VMware et ça roule" (en oubliant les contraintes sur les noyaux pris en charge).

      • [^] # Re: RHEL, une certaine vision de GNU/Linux.

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

        Alors pour la solution de virtualisation, c'est du XEN (en para-virtualisation ou en full-virtualisation).

        Pour ce qui est de libvirt, en gros c'est une API qui permet l'administration des machines virtuelles à distance notamment avec une IHM dans le genre de la console VMware (http://virt-manager.et.redhat.com)

      • [^] # Re: RHEL, une certaine vision de GNU/Linux.

        Posté par  . Évalué à 7.

        libvirt c'est avant-tout une couche d'abstraction, ça permet aux entreprises de gérer avec les mêmes outils (virt-manager, virsh etc ...)des solutions de virtualisations aussi diverses que Xen, KVM, OpenVZ, LXC etc ...
        libvirt c'est une API stable à long terme, c'est une intégration poussée avec avahi, policyKit, gestion à distance etc ... C'est également virtio qui offre un accès aux périphériques de stockage et réseaux aux systèmes invités équivalent en performance aux VMWare guest tools ou les pilotes paravirtualisés Xen. L'émulation des périphériques d'I/O était quand même le goulot d'étranglement des solutions de virtualisations libres comme Qemu et KVM.
        Pour RedHat, cela permet de garantir une certaine indépendance vis à vis de la solution de virtualisation proposé (Xen -> KVM).
        Pour l'administrateur, gérer plusieurs solutions de virtualisation avec un seul outil et non pas une dizaine qui ont des approches très différentes. Couplé avec avahi et func (pas encore dans RHEL il me semble), on arrive à faire des trucs assez sympa dans des parcs.

    • [^] # Re: RHEL, une certaine vision de GNU/Linux.

      Posté par  . Évalué à 6.

      Sans oublier CentOS qui devrait être mis à jour d'ici un mois.

      L'eco-système Fedora -> RHEL -> CentOS c'est vraiment une souplesse et un confort de l'esprit incroyable pour un admin système:

      La Fedora permet de tester les nouveautés upstream.
      La RHEL permet de voir quelles sont les technos les plus stables qui ont été adoptées
      La CentOS permet l'utilisation sans support payant de tout ça.

      Un admin heureux et tranquille.

  • # Chiffrement intégral du disque dur

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

    J'avais testé Ubuntu Gutsy avec chiffrement de toutes les partitions y compris le swap. Et bien, le portable était beaucoup plus lent qu'avant (installation sans aucun chiffrement). Surtout qu'il n'a que 512 Mo de mémoire, alors ça swappe rapidement... C'était les options par défaut dans l'installeur, je me souviens plus des algos utilisés et si c'était le disque ou le système de fichier qui était chiffré.

    • [^] # Re: Chiffrement intégral du disque dur

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

      Évidemment ça impacte pas mal les perf de chiffrer tout les FS, mais dans ce cas précis c'est pas vraiment destiné à faire tourner sur un portable avec 512Mo de RAM.

      C'est une distrib plus orientée serveur, l'impact au niveau perf est moindre sur un gros serveur ...

      De toutes façons, je ne pense pas que ce soit le mode d'installation par défaut ...

  • # CSS

    Posté par  . Évalué à 4.

    Elle est où la CSS pour RHEL ?? (je sens le DTC arriver... )

    • [^] # Re: CSS

      Posté par  . Évalué à -3.

      Puisqu'il le faut :
      DTC



      ~~~~~~~~~> [ ]

      • [^] # Re: CSS

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

        Raah c' est vrai que Linuxfr en rouge, ça aurait été chouette :)

        • [^] # Re: CSS

          Posté par  . Évalué à 0.

          linuxfr en rouge, ok, mais alors avec des caracteres verts.
          Ca rend tres bien en general: c'est absolument immonde, specialement sur un ecran cathodique.

          Allez, pour faire l'essai chez vous:
          xterm -bg red -fg green

          • [^] # Re: CSS

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

            ah c'est toi aussi qui a conçu les fenêtres root (ou plus souvent utilisateur applicatif plutôt) envoyées de la production vers les développeurs ? ;-)

Suivre le flux des commentaires

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