Journal RHEL 5.2/Ubuntu 8.04

Posté par (page perso) .
Tags : aucun
1
11
août
2008
Bonjour,
Pour une mission de courte durée chez un client, je dois installer un serveur linux pour héberger une application utilisant Apache/PHP/Mysql.
J'arrive donc le premier jour, le client a un support Redhat... Très bien, donc, je demande le DVD d'install, je le mets, ah ! Install Number. Bon, je demande, on me donne un truc (le product ID number, je l'ai appris après) ca marche pas.
Donc, appel à la hotline, on dit à mon client qu'on va le rapeller. Bon, et moi ? Je fais quoi ?
Après quelques heures, je demande à mon client si je peux pas faire le truc avec une Debian ou même avec une Ubuntu. Il me dit OK avec une Ubuntu.
En 3 journées, tout est installé, (serveur + Backup) pas de problème, je retourne chez moi.
Une semaine après, coup de fil du client, qui demande à installer une Redhat pour avoir la même chose sur tout ses serveurs. Il reconnait son tort et donc demande une nouvelle prestation. Le support a expliqué comment il fallait faire...
Je comprends qu'il veuille la même chose partout et je me dis que ca devrait quand même pas être compliqué.
Donc, ok, on me donne un nouveau numéro, ca passe, je configure le serveur.
Les dépots sont affreusement lents, mais ca fini par se faire.
Je veux installer phpMyAdmin, aie, pas dans les dépots ! Obligé de le faire à la main.
Je veux faire les mises à jour : Ah non, pas possible, il y a un paquet Zen qui correspond pas.
Je veux me connecter en sftp sur mon serveur : je trouve pas, direction forums etc, je cherche encore la solution.
Et puis ce matin, c'est le ponpon, je veux installer mon serveur de backup avec mon zoli install number et là, le service https://rhn.redhat.com ne répond pas, je ne peux pas configurer mon dépot.

Technical Problem (503)

You've reached this page because of a technical problem that occurred while executing your last request. Our web engineers automatically receive an email alerting them of your difficulty and will address the issue promptly. We apologize for any inconvenience!

Please enter this problem in Bugzilla if you continue to experience problems.

Résultat des courses : j'ai passé 3 jours (et c pas fini) à faire la même chose avec ma RHEL contre à peine une journée avec mon Ubuntu (ca aurait été juste un peu plus long avec une debian.)
Franchement, j'ai pas de chance ou je suis nul ?
  • # Mandriva

    Posté par (page perso) . Évalué à -6.

    Tu aurais dû installer Mandriva. Tu aurais moins galèré
    • [^] # Re: Mandriva

      Posté par (page perso) . Évalué à -3.

      Pas sûr...
      bon, je suis pas expert en configuration de serveur... j'ai donc besoin de suivre la documentation en ligne, les forums, tout ça....
      alors, la semaine dernière, installation de Mandriva pour à peu près les mêmes objectifs que l'auteur de ce journal...
      bah, en cherchant les informations pour configurer pure-ftp... je les trouves sur le site de ubuntu-fr... (plus clair que sur le wiki de mandriva) ensuite, j'ai du mal avec l'organisation des menus de Mandriva, pas l'habitude quoi, donc au final, parce que je suis plus habitué à Ubuntu, ce WE j'ai réinstallé une 7.10 et roulez jeunesse...
  • # même expérience

    Posté par (page perso) . Évalué à 4.

    j'ai eu la même expérience il y a 3 ans avec des serveur RHEL. Jamais compris comment on pouvait rendre ça utilisable. Je suppose que c'est pour pas dépayser les windowsiens.
    • [^] # Re: même expérience

      Posté par . Évalué à 7.

      ça permet aussi de trouver un responsable (RedHat) au problème plutôt que de tout se prendre dans la gueule parce que la Debian qu'on a choisit il y a des problèmes après.
      • [^] # Re: même expérience

        Posté par (page perso) . Évalué à 8.

        Alors là je ne suis pas d'accord.
        Avec une RHEL, tu paies pour avoir un responsable (RedHat) quand il y a un problème.
        Avec une Debian, c'est inutile de payer : il n'y a pas de problèmes.

        Désolé, j'ai pas eu le courage d'attendre vendredi.
        • [^] # Re: même expérience

          Posté par . Évalué à 5.

          Ouai, va expliquer à ton client que ses données sensibles ont été interceptés à cause de https://linuxfr.org//2008/05/15/24092.html et que le responsable est une association même pas enregistrée en France qui déclare n'être responsable de rien.
          • [^] # Re: même expérience

            Posté par (page perso) . Évalué à 7.

            Ah ça ! Saleté d'Ubuntu ! Pas question que je mette cette distro d'amateurs sur un serveur.

            (Comme pour mon commentaire précédent, merci de ne pas me prendre à la lettre.)
          • [^] # Re: même expérience

            Posté par . Évalué à 10.

            ah non, le responsable c'est toi qui a choisi et installé tout ce bazar chez ton client, pas la petite souris et encore moins Debian qui ne sait même pas que tu existes.
    • [^] # Re: même expérience

      Posté par (page perso) . Évalué à 5.

      Exactement, comment se faire chier alors que tout marche à coté...
      Je dois avouer, qu'entrer des numéros de licence pour installer un linux, j'avais jamais fait... et que ca bloque parce que le service répond pas, là, je trouve ca terrible.
      Je pense que je vais mettre une Centos
      • [^] # Re: même expérience

        Posté par (page perso) . Évalué à 10.

        Euh, je ne veux pas être méchant, mais tu as quand même une part de responsabilité.
        Visiblement, tu n'as jamais touché une red hat de ta vie, et tu vas proposer tes services autour de cette distrib. Si le client demandait une Red hat, il fallait lui dire que tu n'avais simplement pas les compétences pour cet OS, et éventuellement le rediriger vers quelqu'un les possédant. Et si un grand nombre de tes clients te réclament du Red hat, bin dans ce cas tu peux te former dessus.

        Après je ne dis pas que tu es responsable de ces mésaventures, sans doute que le premier responsable est Red hat. Mais au moins, si tu avais déjà quelques expériences sur le système, tu aurais su à quoi t'attendre, et ton client aurait peut-être été moins embêté.
  • # Idem

    Posté par (page perso) . Évalué à 7.

    J'ai eu le meme genre d'experience chez plusieurs clients. Les admin pas formés a Unix/Linux a qui ont dit d'utiliser Redhat "car on paie le support". Resultat personne ne connait le mot de passe d'acces a RHN et du coup impossible d'installer des paquets officiels sur les serveurs ni de faire les mises a jour de securité.

    Au final ca fait plein d'applis compilées pendant des heures a la main dans /usr/local depuis les sources (sans parler des galeres pour geres les dependances runtime + compile time) et aucunes mises a jours ...

    Et apres ca on me sort toujours oui mais debian ou ubuntu on a pas le support ... Je doute que les ingénieurs de support de chez redhat puissent intervenir efficacement sur des serveurs dont la moitié du systeme est compilé a la main et sans aucune mise a jour.
    • [^] # Re: Idem

      Posté par . Évalué à 3.

      Redhat/Novell c'est également interessant pour la certification des applications d'Oracle / SAP. Cependant je n'ai encore vu aucun client français qui utilise des systèmes de production faisant fonctionner des applications SAP (ECC, SRM, CRM, Portail, EAI), sous Linux, en revanche depuis 3 ans il y a une explosion du nombre de serveur sous Windows / SQL Server à la place d'AIX / Oracle ou DB2, mais pas de Linux.
    • [^] # Re: Idem

      Posté par . Évalué à 10.

      oui enfin si "personne ne connait le mot de passe d'acces a RHN" c'est qu'il y a une grosse carence et pas exactement d'ordre technique.
      • [^] # Re: Idem

        Posté par (page perso) . Évalué à 2.

        Tout a fait. Je ne critique pas la qualité du service de RedHat ni l'utilité d'un service de support professionnel. Je cherche juste a mettre en exergue l'attitude du DSI lambda qui se dit "on prend du Redhat car c'est plus pro" (et qui n'hesitera pas le cas echeant a parler de Debian ou Ubuntu comme de systeme d'amateurs hobbyistes) en negligeant tout le reste (formation des admins, mise en place de mirroires de repositories, formalisation du processus de mises a jours). Au final on se retouve très souvent avec une infrastructure dans un état lamentable.

        Cette attitude est vraiment omniprésente chez la plupart de clients qui decouvrent le systeme open source, et pas seulement dans les petites structures.
    • [^] # Re: Idem

      Posté par (page perso) . Évalué à -3.

      Ouais enfin tu pouvais toujours booter un LiveCD quelconque, monter la partition / du RedHat, faire un "chroot", "passwd root" et voilà...

      Tu t'es pas un peu compliqué la vie à tout recompiler pour rien ?

      D'autant que si vraiment tu voulais pas changer le mot de passe root tu pouvais toujours dire : "vous me donnez pas les ressources et accès nécessaire, rappelez moi quand vous les aurez".
      • [^] # Re: Idem

        Posté par . Évalué à 2.

        toi tu n'as lu qu'à moitié. Où as-tu entendu parler de password du user root ?
      • [^] # Re: Idem

        Posté par (page perso) . Évalué à 2.

        non non :)
        RHN, c'est RedHat Network... Donc, il lui manquait pas le pass root mais bien le mot de passe pour installer le dépot principal d'une RHEL
        • [^] # Re: Idem

          Posté par (page perso) . Évalué à -1.

          Rah..ça marche comme ça ??
          Pff pas super pratique, surtout si - comme je l'espère j'ai ce coup-ci bien compris - il n'y a pas de miroir.
        • [^] # Re: Idem

          Posté par (page perso) . Évalué à 1.

          D'autant plus que c'est facile pour le mot de passe root en général chez ce type de client c'est toujours ... "root".
          • [^] # Re: Idem

            Posté par . Évalué à 2.

            Ah non, tu as aussi "123456", "azerty" et "654321" (chez les plus malins).
            • [^] # Re: Idem

              Posté par . Évalué à 2.

              Et "password" et "abcd1234".

              Il me semble aussi me souvenir d'une info qui disait que le mot de passe préféré de la famille Michu était "soleil".
  • # c'est reparti !

    Posté par (page perso) . Évalué à 3.

    Voilà, j'ai enfin réussi à configurer mes dépots ;)
    donc, c'était bien un problème coté Redhat... 2h30 de coupure du service !!!
    Dans les commentaires, il y en a pas un qui défend le service et ca fait un peu peur.
    • [^] # Re: c'est reparti !

      Posté par (page perso) . Évalué à 3.

      Dans les commentaires, il y en a pas un qui défend le service et ca fait un peu peur.

      Le raisonnement de certains est: je prends du service car en cas de pépin, je saurais à qui m'adresser. C'est tout à fait défendable.

      Le raisonnement d'autres personnes est: je suis un peu compétent. Jusqu'à présent la qualité du service m'a toujours démontré que c'est inutile de souscrire à ces offres car je me dépanne mieux moi-même qu'avec leur aide.

      En gros, si on utilise quelque chose d'important pour l'entreprise, alors on le maîtrise au moins un peu. En général le service n'a aucune utilité. Si c'est quelque chose de non important, alors pas besoin de le maîtriser, mais du coup pas besoin de service non plus.

      Cela dit, beaucoup d'informaticiens n'ont pas les compétences intelectuelles pour maîtriser quoi que ce soit. Donc le service est bienvenu dans ce cas. 90% des cas ?

      Chez nous, nous avons deux exceptions:
      Un VPN Equant (une merde sans nom) qui est en cours de résiliation. C'était avant mon arrivée :-)
      La suite CEGID (une merde sans nom encore pire) car sans leur "service" (notez les guillemets) c'est en panne chaque semaine. Et leur personnel est le seul à avoir une vague idée de comment ça fonctionne. Pour donner une idée de la grosse bouse que sont les produits CEGID: ils sont basés sur un SGDBR (SQL server chez nous) MAIS il faut que l'application ait accès aux fichiers de données en direct. Pour quoi faire ? Mystère.
      • [^] # Re: c'est reparti !

        Posté par . Évalué à 1.

        C'est quoi des compétences intellectuelles ?
        • [^] # Re: c'est reparti !

          Posté par . Évalué à 7.

          Reflexion, analyse, synthèse, curiosité, recul, calme, initiative, confiance, ambition, remise en question, humilité, persévérance, etc.
          • [^] # Re: c'est reparti !

            Posté par . Évalué à 4.

            Mouais, tu m'éclaire pas beaucoup. L'ambition ou l'humilité ce ne sont pas vraiment des competences, à la rigueur des qualités et encore pas forcément, ou des traits de caractères, et leur rapport avec l'intellect (ou "ce qui se rapporte à l'intelligence" est pas tout à fait immédiat.

            En fait si je posais la question c'est que je déteste ce genre de façon méprisante et supérieure de parler des informaticiens en général en sous-entendant qu'ils sont stupides à 90%. Genre tu n'as besoin de support que si tu es stupide ou incompétent et pas parce que c'est potentiellement plus rapide de passer un coup de fil et poser une question à des gens qui sont là pour ça et qui pourront (peut être régler ton problème en trois coups de cuillère à pot là ou tu auras besoin de te taper des pages de docs en quantité et que ça peut te bouffer du temps que tu n'auras pas forcément.
        • [^] # Re: c'est reparti !

          Posté par (page perso) . Évalué à 2.

          C'est quoi des compétences intellectuelles ?

          Dans le domaine relatif à "pas besoin de service de support", c'est ce qui permet par exemple de se rendre compte que ta machine ne peut pas se mettre à jour à cause d'un modem/routeur qui gère mal les requêtes dns AAAA (c'est le cas avec Debian + DLINK).

          C'est ce qui permet par exemple de mettre en place un moteur de configuration de tout tes serveurs (cfengine ou puppet) au lieu de te taper des tonnes de sessions ssh.

          En bref, c'est ce qui permet de résoudre des problèmes qu'on n'a pas encore eu.
          • [^] # Re: c'est reparti !

            Posté par . Évalué à 2.

            En gros c'est des compétences techniques, du temps et un certain potentiel à se documenter. Je vois pas ce qu'il y a de mal à se reposer sur un support compétent pour ce genre de ce que je considère comme des "problèmes à la con" éventuellement connus au moins pour ton premier exemple et à se concentrer sur autre chose.

            Pour le deuxième exemple, pareil, j'irai presque dans ton sens, genre si on peut simplifier au maximum l'administration c'est plutôt cool. Mais là encore il n'y a pas de mal à se faire bien conseiller par un service de support compétent et de gagner du temps plutôt que de faire des recherches fastidieuses et longues si c'est pas ton domaine de compétence. Genre les éventuels outils dédiés de la distrib, par exemple.

            Après on est d'accord, c'est surement mieux si tu sais régler le problème toi même, mais le support c'est un peu une manière de capitaliser les expériences de ce côté et d'accélérer la résolution, surtout si c'est des problèmes connus qui pourront limite servir de "bugreport+fix" un peu costaux.
            • [^] # Re: c'est reparti !

              Posté par (page perso) . Évalué à 3.

              le support c'est un peu une manière de capitaliser les expériences de ce côté et d'accélérer la résolution

              Nous sommes bien d'accord là dessus. Et puis une entreprise préfère payer un service 15000 € annuel (plus un petit morceau du salaire de l'administrateur) plutôt que 5000 € mensuel.
              Là où nous ne sommes visiblement pas d'accord, c'est que mon expérience personnelle ne m'a JAMAIS mis sur la route d'un support compétent. A part pour les 2 ou 3 problèmes basiques, c'est toujours moi qui dépatouille l'affaire.
              Dernier exemple en date: je suis en train de valider un nouveau type de modem/routeur ADSL pour déployer dans nos sites. Je teste un DLINK (je n'aime pas du tout la marque, mais il n'y a pas moins cher). Je tombe sur un bug mineur et un bug majeur au bout d'un quart d'heure. Leur "support" est incapable de corriger cela car google m'a montré que le problème existe depuis plusieurs mois. Je corrige le script à la mimine, et zou, ça fonctionne.
              pseudo support = 0
              Ma pomme = 1

              Mon avant dernier exemple était avec un des logiciels CEGID. Il ne prenait pas en compte une modification de l'adresse d'une entreprise. Le support indique qu'il faut rebouter (c'est comme ça que l'écrit notre cheffe comptable, j'aime bien). Ma pomme indique que net stop net start a amplement suffir. Je fais, ça fonctionne.
              pseudo support = 0
              Ma pomme = 2


              Un jour peut-être, je tomberais sur un support compétent :-)
              • [^] # Re: c'est reparti !

                Posté par (page perso) . Évalué à 2.

                Il faut comprendre que le support (logiciel comme matériel mais surtout logiciel) n'est pas qu'une assurance technique mais surtout une assurance financière. En clair, on établit un contrat avec l'entreprise qui fera le support d'un logiciel donné.
                En cas de problèmes majeurs en production avec le dit logiciel, on ne fera pas forcément appel à toi car le temps vient généralement à manquer (en production) et que le contrat de support est justement là pour cela. On n'aura pas nécessairement le temps d'attendre que tu te documentes à coups de Google, en espérant que quelqu'un ait déjà eu le même problème (et l'ai publié après avoir trouvé une solution).
                Tout cela fait beaucoup de si. Si le logiciel cause des pertes significatives de revenus à l'entreprise, les contrats prévoient généralement des pénalités en cas de non-résolutions. Ceci entraîne souvent une gestion intempestive des tickets (avec clôture très rapide).
                Cependant, ce n'est pas le support professionnel le problème, c'est plutôt la rationnalisation des coûts des centres de support, qui entraînent ces dérives, en compétences et en gestion.

                Je vais prêcher pour ma paroisse mais pour trouver un support plutôt compétent : http://www.08000linux.com/
                J'admets le caractère publicitaire que cela peut avoir mais pour les avoir eu quelques fois en deux ans parce le client pour lequel je travaille a souscris une offre de support chez nous, je peux dire qu'ils sont compétents. Pour l'instant, il faut avouer que le centre de support est encore à visage humain et que les recrutements ne négligent pas les compétences. Simplement : un expert, ça coûte très cher à une entreprise spécialisée dans le support et je te laisse deviner ce que ça pèse dans la balance d'un gestionnaire financier.
      • [^] # Re: c'est reparti !

        Posté par . Évalué à 5.

        Il est également intéressant de noter que beaucoup d'admins de systèmes Microsoft mettent en avant comme argument de leur choix le support dès qu'on leur parle d'autres solutions...
        • [^] # Re: c'est reparti !

          Posté par (page perso) . Évalué à 2.

          Et même des dirigeant qui mettent en avant le fait d'obtenir des dommages et intérêts en cas de pépin :-)
          Ce sont d'aimables plaisantins.
      • [^] # Re: c'est reparti !

        Posté par . Évalué à 2.

        Je ne te contredirais pas sur le fait que CEGID soit une merde sans nom...
        Par contre un informaticien qui a des "compétences intellectuelles" et un tout petit peu de bonne volonté peut apprendre à le faire marcher sans avoir besoin de leur SAV. D'ailleurs le sevrage est normalement rapide vu le temps de réponse du sav si tu as la dernière version et pas un vieux crincrin.

        Après personnellement je pense que dans le cas de CEGID, si il n'y avait que les problèmes des informaticiens ce ne serait vraiment pas grave, ce qui me fait plus de soucis ce sont les problèmes utilisateurs... on est quand même censé pouvoir faire de la compta avec et ça c'est pas gagné d'avance ^^
        • [^] # Re: c'est reparti !

          Posté par (page perso) . Évalué à 2.

          le sevrage est normalement rapide vu le temps de réponse du sav
          Ah, il répondent maintenant ? :-)
          Le seul moyen que je connaisse pour qu'ils répondent, c'est de contacter la responsable du service juridique. Sinon "on va vous rappeler", tu peux être tranquille, le téléphone ne sonnera pas.


          dans le cas de CEGID, si il n'y avait que les problèmes des informaticiens ce ne serait vraiment pas grave
          Heu, une balance déséquilibrée car il n'y a pas de vérification de date lors de la saisie, bon, ça ne le fait pas je trouve :-) Il n'y a pas non plus de contraintes dans la base de données. Nous avons visiblement des expériences différentes à propos de leurs merveilleux logiciels et des utilisateurs. Chez nous ça va, les comptables sont vraiment bien de ce côté.

          Par contre, le faire fonctionner de nous-mêmes, je ne suis malheureusement pas partant. Rien que pour changer de version c'est tellement aléatoire que nous bloquons 2 jours pour que ça se fasse. Et maintenant que ça fonctionne sur des machines que NOUS avons installées (au départ c'étaient leurs machines, et leurs installations, du grand n'importe quoi), les problèmes sont uniquement liés à leurs produits.

          Mais bon, à la place de CEGID, on prends quoi ? Sage ? C'est la même chose :-(
          • [^] # Re: c'est reparti !

            Posté par . Évalué à 1.

            CEGID réagit très bien aux contraintes commerciales. Tu appelles le commercial, tu fournis une facture d'interruption de service, et miracle pendant un an ou deux ils rappellent "assez" rapidement. Après faut remontrer les dents de temps à autres.

            Après CEGID faut en avoir besoin... nous on a fini par lourder. C'est un outil qui fait en général beaucoup plus de choses que nécessaire. Les commerciaux doivent s'éclatent à vendre un truc qui fait tout et les techs rament pour réaliser derrière (jamais vu deux fois le même gars d'ailleurs).
            J'ai effectivement de très mauvais souvenirs de leurs installations mais par chance pour nous ça a planté dès le premier jour (en fait le serveur n'a jamais redémarré le lendemain de l'install car l'ingé CEGID avait bidouillé les permissions ntfs de la partition C) et nous avons refait l'installation en interne direct en piétinant amoureusement la plupart de leurs préconisations pour mieux coller à notre architecture. Quand l'ingé est arrivé pour tout refaire, on lui a offert le café et on l'a renvoyé direct, sans payer sa première prestation.

            Ca a peut-être changé mais dans le temps il fallait un accès direct aux fichiers de base de données parce que tout n'était pas en sql serveur (officiellement sensé tourner sur Mysql mais bon.. j'imagine pas le truc). Il y avait quelques .mdb indispensables perdus dans les répertoires...

            Par contre ils fournissent (ou fournissaient ?) toutes les infos requises pour interroger leurs bases de données depuis des outils tiers et valident même des outils de modifications. Et ça c'était plus sympa que certaines boites où tu dois pleurer pour faire un SELECT de la liste des clients...
            • [^] # Re: c'est reparti !

              Posté par (page perso) . Évalué à 2.

              dans le temps il fallait un accès direct aux fichiers de base de données parce que tout n'était pas en sql serveur
              C'est toujours le cas :-) Il faut SQL Server ET l'accès aux fichiers. Si si madame, les deux. Et bien entendu, l'accès est en lecture et écriture, c'est tout de même plus fun.

              Pour les interrogations directes, je suis en train de faire un outils d'extraction et c'est vrai qu'on peut lire ce qu'on veut. Je pense que c'est le cas chez tout le monde ou presque.
  • # Bienvenu au club des déçus par RHL / Fedora...

    Posté par . Évalué à -2.

    Red Hat ça a été mon premier contact avec Linux...

    ...5 installations décevantes plus tard, je passe à suze, qui me décoit terriblement aussi, je revenais à Windows pour 3 ans...

    ...Puis j'ai essayé Debian, qui me sembla tout de suite plus sympa (merci apt, merci la communauté), mais tellement difficile à installer son matériel non / mal supporté (NVidia & compagnie il y a 5 ans) ; j'ai laissé tomber après les tentatives infructueuses pour installer correctement ma carte graphique...

    ...Et enfin, Ubuntu (il y a 3 ans). Et là, tout (presque) marche rapidement, c'est convivial, ça permet de faire le premier pas sans t'empêcher de faire les pas suivants.

    Je reviendrais peut-être à Debian un jour, pour voir et pour une utilisation serveur. En attendant, vive Ubuntu.

    En plus, si vous êtes dans une entreprise qui aime payer pour avoir quelqu'un à qui se plaindre quand ça ne fait pas exactement ce qu'elle veut, il y a Canonical... Ubuntu pour l'entreprise, c'est sans doute la meilleur solution pas prise de tête en Linux, n'en déplaise aux masochistes...
    • [^] # Re: Bienvenu au club des déçus par RHL / Fedora...

      Posté par (page perso) . Évalué à 6.

      Enfin, vu ton parcours, tu compares ubuntu à une redhat ou suse d'il y a 8 ans, et ca a pas mal changé depuis aussi.
    • [^] # Re: Bienvenu au club des déçus par RHL / Fedora...

      Posté par . Évalué à 6.

      J'ai envie de te dire que RedHat et FedoraProject c'est deux choses différentes. J'ai également envie de te dire que les principales distributions se valent toutes plus ou moins, que tu retrouves les mêmes outils mais ça serait comme prêcher dans le désert.

      > il y a Canonical... Ubuntu pour l'entreprise, c'est sans doute la meilleur solution pas prise de tête en Linux, n'en déplaise aux masochistes...

      Je n'ai rien contre Ubuntu en entreprise, après tout si l'admin connait bien, ou que tu fais appel à un prestataire compétent, pourquoi pas.
      Un bon admin qui maitrise bien Ubuntu fera mieux qu'un mauvais admin qui ne maitrise pas RedHat.

      Mais, Canonical == meilleure solution, c'est une blague ?
      Non seulement, ce sont les plus chers à prestation égale (plus cher que RedHat même) mais la qualité du service est très loin derrière ce que peut t'offrir RedHat, Novell, Mandriva ou une SSLL compétente.
      Même au niveau de la documentation et des formations, Canonical ne joue pas dans la même ligue.
      • [^] # Re: Bienvenu au club des déçus par RHL / Fedora...

        Posté par (page perso) . Évalué à 2.

        Je comprends ta position de dire que Canonical est pas super par rapport à Redhat (même si je n'ai aucune expérience à ce sujet) pour une grosse entreprise.
        Pour moi, Ubuntu n'est pas autre chose qu'une Debian facile à installer/utiliser pour un gars aux modestes moyens ;). Franchement, je rêvais de cela quelques années avant qu'elle sorte et je n'étais pas le seul.
        Ce que je peux dire aujourd'hui, c'est que, lorsque j'ai un serveur à installer je mets un debian, quand c'est pour un utilisateur qui veut linux, pour mon desktop ou pour essayer quelque chose, je n'hésite pas, c'est une Ubuntu.
        Ceci étant dit, on ne doit pas avoir les mêmes besoins.
      • [^] # Re: Bienvenu au club des déçus par RHL / Fedora...

        Posté par (page perso) . Évalué à -1.

        Je comprends ta position de dire que Canonical est pas super par rapport à Redhat (même si je n'ai aucune expérience à ce sujet) pour une grosse entreprise.
        Pour moi, Ubuntu n'est pas autre chose qu'une Debian facile à installer/utiliser pour un gars aux modestes moyens ;). Franchement, je rêvais de cela quelques années avant qu'elle sorte et je n'étais pas le seul.
        Ce que je peux dire aujourd'hui, c'est que, lorsque j'ai un serveur à installer je mets un debian, quand c'est pour un utilisateur qui veut linux, pour mon desktop ou pour essayer quelque chose, je n'hésite pas, c'est une Ubuntu.
        Ceci étant dit, on ne doit pas avoir les mêmes besoins.
    • [^] # Re: Bienvenu au club des déçus par RHL / Fedora...

      Posté par . Évalué à 7.

      en même temps si tu avais fait le chemin inverse (disons debian puis fedora/red hat) tu aurais eu les mêmes réactions : "rah ça pue" puis "vache, ça c'est bien amélioré"
  • # RHEL ~ CentOS

    Posté par . Évalué à 2.

    Les fournisseurs d'applications tournant sous Linux qui ne "valident" que RHEL pourraient au moins prendre la peine de valider aussi leurs applications en utilisant les "distributions clones" telles que CentOS. Vu que l'environnement est censé être le même, ça ne leur prendrait pas des plombes et ça éviterait au client final de débourser en plus pour la licence RHEL. Oui, je sais, c'est commercialement pas sympa pour Redhat tout ça... mais bon.
    • [^] # Re: RHEL ~ CentOS

      Posté par . Évalué à 3.

      je vois pas trop leur intérêt, surtout si à coté de te fournir des applis ils sont aussi revendeurs/formateurs/etc Red Hat...
  • # Zorro...

    Posté par . Évalué à 7.

    Hello,

    Je ne sais pas combien de serveurs a ton client, mais de faire un dépôt local ne serait pas du luxe et la licence RHEL le permet sans problème.

    Il m'est déjà arrivé le même problème que ce soit avec Ubnutu, SuSE ou encore sous windows avec le site web d'une application que je devais télécharger qui ne répondait pas pile au moment ou j'en avais besoin.

    Il est inutile de tirer à boulet rouge sur RedHat. Certaines boîtes sont obligées de prendre cette distribution, car des outils métiers ne sont supportés que sur certaines plateforme. Dans mon cas, nous utilisons CentOS, car nous n'avons pas besoins du support de ce côté-ci. En revanche nos outils critiques (et très chers ) ne sont supportés que sous RHEL donc nous n'avons pas trop le choix.


    My 2 escudos...
    • [^] # Re: Zorro...

      Posté par (page perso) . Évalué à 1.

      Mon client a 3 serveurs : le mien et les 2 autres sous RHEL 4.0... Donc pas la peine.
      Pour Ubuntu ou Debian, si le dépot ne fonctionne pas, un petit tour dans synaptic et changement de mirroir.
      Mais c'est vrai que je pensais bien ne pas avoir le choix et devoir utiliser la RHEL pour ce client. Je voulais juste dire que ca m'avait fait perdre - beaucoup - de temps.
  • # Quel administrateur aime bien rhel ?

    Posté par . Évalué à 3.

    Existe-t-il un club des administrateurs système n'aimant pas ( et subissant ) les rhel ?

    Y a-t-il quelqu'un ici qui est content de cette distribution ?

    A quoi ça sert d'avoir une distribution certifiée si c'est pour de toute façon installer des paquets non officiels voir compilés à la main ?

    Et enfin, pourquoi, oui, pourquoi Red Hat n'a pas développé une meilleure gestion des paquets ? ( je parle au passé, car je ne sais pas comment cela est géré maintenant et je crois qu'il y a eu des évolutions sur ce point ).
    • [^] # Re: Quel administrateur aime bien rhel ?

      Posté par . Évalué à 8.

      > A quoi ça sert d'avoir une distribution certifiée si c'est pour de toute façon installer des paquets non officiels voir compilés à la main ?

      C'est facile de chier des paquets, mais assurer le support de qualité professionnel qui va avec ça l'est nettement moins. Reste deux possibilités, faire prendre conscience à RedHat que le support de xyz est vital (si vous êtes assez nombreux à râler, ça devrait être facile), soit raquer.
      Je préfère ça aux escrocs qui prétendent supporter tout et n'importe quoi et qui mette leur tête sous le sable au premier souci.

      > si c'est pour de toute façon installer des paquets non officiels
      Dans le cas de RHEL, les paquets provenant de CentOS et de EPEL ont une qualité proche de ce qu'offre RedHat (si ce n'est supérieur), et qui vaut largement un support commercial.
      Si tu n'as pas besoin de l'expertise de RedHat, tu peux te tourner vers CentOS.
    • [^] # Re: Quel administrateur aime bien rhel ?

      Posté par . Évalué à 4.

      Salut,

      Je dois être la minorité à aimer cette distrib.
      Bientôt 6 ans que je l'utilise dans la boite ou je suis et pas grand chose à redire :
      Le support est réactif, le site bugzilla bouge bien et pour une utilisation à grande échelle, kickstart est ton amis.
      La gestion des paquets est correcte (yum/yam).
      Le code source du proxy RHN est libéré (j'en atttends beaucoup).
      Le support de la distrib est passée à 7 ans (plus besoin de faire une montée majeure de kernel + libc tous les 2/3 ans).
      ..
      bref, que du positif pour moi.

      Et pour ceux qui râlent contre RH, qu'ont ils à proposer à la place (je parle ici d'une distrib Linux avec support et supportée par Oracle, NBU, SAN...) ?

      Bonne journée
    • [^] # Re: Quel administrateur aime bien rhel ?

      Posté par . Évalué à 1.

      > Et enfin, pourquoi, oui, pourquoi Red Hat n'a pas développé une meilleure gestion des paquets ?

      Parle technique (et non troll) et dit ce qu'il manque à rpm (vs deb).
      En passant, il y a aussi apt-get pour rpm...
      • [^] # Re: Quel administrateur aime bien rhel ?

        Posté par . Évalué à 3.

        Sans le "autoremove", ce n'est plus vraiment apt-get ; bon, tu me diras, les gestionnaires de paquets des machins de chez RedHat ne gèrent déjà pas ça, alors, le gérer pour les deb...

        ... et puis bon, c'est aptitude, la tendance actuelle...
        • [^] # Re: Quel administrateur aime bien rhel ?

          Posté par . Évalué à 2.

          Ce n'est pas une limitation de RPM -d'ailleurs, je ne vois pas même pas pourquoi une telle limitation-, je ne sais pas pour apt4rpm mais c'est en cours de développement dans Yum (via un plugin) et c'est faisable avec les yum-utils.
          https://lists.dulug.duke.edu/pipermail/yum/2007-June/009933.(...)
          • [^] # Re: Quel administrateur aime bien rhel ?

            Posté par . Évalué à 2.

            > Ce n'est pas une limitation de RPM

            Tout à fait... sauf qu'aucune des distros à base de RPM que j'ai essayées n'implémente la désinstallation automatique des dépendances inutiles ; il me semble que Mandriva va s'y mettre, pour sa prochaine version, à la rentrée - d'autres sont sûrement en train de le faire...

            ... mais quand on l'habitude que le bloat soit automatiquement désinstallé, c'est une vraie plaie que d'utiliser yum & cie...

            Alors, certes, a priori, aucun rapport avec RPM (c'est plutôt au niveau du gestionnaire de paquets, de gérer ce qu'il fait à ce niveau)... mais c'est quand même une habitude tenace dans le "clan RPM"...



            Sinon, non, ce n'est pas faisable avec yum-utils... ce machin ne fait que te lister les paquets qui ne dépendent d'aucun autre : pour les librairies, il est simple de trouver l'intrus (d'autant qu'il me semble qu'on peut filtrer pour n'afficher qu'elles, avec package-cleanup)...

            ... sauf que les dépendances ne sont pas forcément des librairies... et là, c'est le bordel pour savoir quels paquets tu as installé manuellement, lesquels sont venus en tant que dépendances, et lesquels étaient là avant que tu ne commences à installer quoi que ce soit...

            Ce que fait package-cleanup, c'est du niveau du vieux deborphan... mais c'est à peine un ersatz de ce qu'on peut attendre d'une gestion des dépendances à la désinstallation.
            • [^] # Re: Quel administrateur aime bien rhel ?

              Posté par . Évalué à 2.

              > Tout à fait... sauf qu'aucune des distros à base de RPM que j'ai essayées n'implémente la désinstallation automatique des dépendances inutiles

              Quel est l'intérêt ?
              Gagner un peu de place sur le disque dur et c'est tout.

              Enfin comment tu fais pour savoir si un paquet est inutile ou non avec le chargement dynamique des libraries ?
              Prend le plugin flash, c'est une librairie, personne en dépend (en tout cas tu ne peux pas le détecter automatiquement). Tu fais quoi, tu le vires automatiquement ?
              Certes, tu peux faire une "usine à gaz" qui regarde ce que l'utilisateur a explicitement demandé d'installé. Mais pour l'installation par défaut, tu fais quoi ? Tu considères qu'il n'a explicitement rien demandé ou qu'il a demandé explicitement tout ce qui est dans l'installation par défaut ?
              RHEL/Fedora utilisé les groupes (abstraction hors de rpm). Lorsqu'un utilisateur demande l'installation d'un groupe, tu considères que l'utilisateur a explicitement demandé tous les paquets du groupe ?

              Prenons le problème avec plus de distance. Si un paquet est installé et n'est pas utilisé, il ne dérange personne (à quelques excèptions comme les programmes avec suid).
              Regardes du côté de Windows, 99 % des postes ont l'installation par défaut...
              Contrairement à Windows, sous Linux il n'y a pas de programme qui s'exécute et qu'on ne peut virer. Si c'est un service, on peut le désactiver, si c'est un applet Gnome, on peut la virée, etc.
              Donc les paquets en trop ne dérange pas sauf pour la place disque, voire la durée de mise de jour.
              Cette "finesse" de désinstallation n'a pas de sens en entreprise. Un poste peut être utilisé par plusieures personnes et dans ce cas le poste ne va pas être aux petits oignons pour une seule personne. Si une personne a besoin d'un programme qui n'est pas installé, l'admin installe le programme. Et si la personne part, ben l'admin laisse l'application car il a autre chose à foutre que d'économiser quelques Mo et car l'application sera peut-être utilisée par un autre.

              > mais c'est quand même une habitude tenace dans le "clan RPM"...

              Il y a des raisons/explications légitimes.
              • [^] # Re: Quel administrateur aime bien rhel ?

                Posté par (page perso) . Évalué à 6.

                Dîtes nous de quoi vous avez besoin, on vous expliquera comment vous en passer ...

                Il y a des utilisations de l'ordinateur qui nécessitent par exemple d'installer plein de logiciels "concurents" pour une même tâche dans le but de choisir le meilleur pour une utilisation donnée. Sur debian, le plus souvent ces logiciels sont dans les paquets et ensuite je pourrai ne conserver que le logiciel que je préfère sans avoir trop de cochonneries sur le disque. Sur redhat/fedora, les paquets risquent être plus durs à trouver mais à chaque expérimentation on perd de la place car on n'enlève pas les dépendances... Et si l'on fait souvent l'opération, l'espace disque gâché va vite devenir non négligeable.

                Donc, non la désinstallation propre n'est pas indispensable, mais elle est quand même loin d'être un luxe inutile.

                PS : puis à la place de l'argument 'regardez il y a pire ailleurs et ça ne dérange personne', citer les raisons/explications légitimes aurait pu être une bonne idée (oui je sais tout cela avait déjà été détaillé plusieurs fois sur ce site).
        • [^] # Re: Quel administrateur aime bien rhel ?

          Posté par . Évalué à -1.

          N'importe quoi.
          Et regarde pour d'autres fonctionnalités, rpm les a depuis bien avant deb (triggers, signatures, etc).

          Du côté de deb on a des fanatiques aveugles, du côté de rpm des pragmatiques ennuyeux. J'ai choisi mon camp...
          • [^] # Re: Quel administrateur aime bien rhel ?

            Posté par (page perso) . Évalué à 2.

            Et regarde pour d'autres fonctionnalités, rpm les a depuis bien avant deb (triggers, signatures, etc).
            Donc deb les a aussi maintenant, non ? ;)

            PS : je ne suis pas encore aveugle, seulement myope ...
          • [^] # Re: Quel administrateur aime bien rhel ?

            Posté par (page perso) . Évalué à 6.

            Comme fanatique, tu es pourtant bien placé...
            Le problème n'est pas tant de savoir quel format a eu le support XYZ en premier, mais pourquoi certaines fonctionnalités sont toujours manquantes chez l'un et pas chez l'autre.
            À chaque fois, tu nous a sortis une tirade sur le thème de « ça ne sert à rien » (genre Debconf...). Si ça ne servait vraiment à rien, pourquoi est-ce que certains développeurs les auraient implémenter ? Par souci de l'utilisateur ?

            La gestion de désinstallation d'aptitude ou synaptic (et maintenant apt-get si je ne m'abuse) n'a rien d'une « usine à gaz » et pourtant, ça marche. J'aurais préféré que tu nous sortes les raisons des développeurs Fedora/RH pour ne pas vouloir implémenter cela plutôt qu'essayer de prétendre à l'inutilité d'une telle fonctionnalité.
          • [^] # Re: Quel administrateur aime bien rhel ?

            Posté par . Évalué à 6.

            Mais ce que je m'en fous du débat rpm vs deb...

            ... très sincèrement, je fais de temps en temps des deb, et je n'ai pas eu le temps de me mettre aux rpm avant d'être saoulé par Fedora (pas que pour la gestion de paquets, même si packagekit, entre moults autres, a explosé au bout de quelques jours ; mais là n'est pas la question).

            ... reste que ce qui m'a ennuyé sur la gestion des paquets, c'est que yum ne gère pas les dépendances à la désinstallation. Tu peux dire ce que tu veux, c'est quelque chose qui manque, alors qu'il est chez d'autres (BSDs, Debian, ...)...

            ... et quand on vient de chez les autres et qu'on s'est habitué à ce "confort" (autant pour certaines utilisations, oui, limite, je m'en fous, autant, vu que j'utilise aussi des distros très instables, même si très fiables, comme Sid, qui ont des mises à jour énormes à faire pour peu que je les délaisse un poil, ce n'est vraiment pas du luxe que de ne pas vouloir d'inutilités sur ma machine... ça marche aussi si elle sert de conteneur à des dizaines d'autres, qu'il va falloir gérer aussi), il y a un manque. Et ce n'est pas à toi de me dire si c'en est un ou pas : c'est à moi que ça manque. Ce que je fais de mes machines, c'est quand même avant tout moi, que ça regarde... Voir à ne pas confondre les fanatiques.

            C'est quand même dingue d'être de mauvaise foi au point de vouloir faire passer des pratiques à bloat pour une feature... Si j'utilise quelque chose qui a un gestionnaire de paquets qui prétend gérer les dépendances, je m'attends à ce qu'il fasse le boulot en entier, pas à moitié - d'autant que ça existe et que c'est répandu.

            Admettre que c'est un manque n'est pas la mort, tout au contraire... la preuve, Mandriva va s'y mettre.



            > Du côté de deb on a des fanatiques aveugles, du côté de rpm des pragmatiques ennuyeux. J'ai choisi mon camp.

            Celui des fanatiques ennuyeux ?
      • [^] # Re: Quel administrateur aime bien rhel ?

        Posté par (page perso) . Évalué à 2.

        Oui mais apt-rpm est-il supporté par RedHat ?
  • # T'es juste nul.

    Posté par . Évalué à 0.

    1. Comparer une offre serveur avec support professionnel à un machin sans support ça n'a pas de sens.
    La plupart du temps, tu t'en foutras royalement du support pro jusqu'au jour où tu seras dans la grosse caca et là tu seras bien content de trouver Chapeau Rouge.
    2. RedHat te vend du *vrai* support, ça ne sert à rien de supporter tout les paquets de l'univers si derrière tu n'assures pas.
    C'est pourquoi, RHEL comporte peu de paquets, mais tu as toujours la possibilité de demander à RedHat de supporter de nouveaux paquets.
    3. Dépôts tiers ? Tu as CentOS un clone de RHEL, Tu as FedoraProject qui maintient le dépôt EPEL fournissant des paquets pour RHEL/CentOS, tu as RPMForge/Dag etc ...
    Ce n'est pas ça qui manque ...
    4. Autre possibilité, recompiler des paquets de chez Fedora.
    5. Même moi qui ne suis pas un professionnel, je l'aurais fait en 1/2 journée.
    • [^] # Re: T'es juste nul.

      Posté par (page perso) . Évalué à 3.

      1/2 journée, c'est le temps que j'ai attendu :
      - pour avoir une réponse du support pro
      - pour attendre que le serveur https://rhn.redhat.com réponde
      Donc, déjà ca fait une journée à attendre chez le client...
      Ceci étant dit, merci pour les dépots !!! Je vais les utiliser pour phpmyadmin !
      Aussi, à la vue des commentaires ci-dessus, pourrais-tu me dire un cas ou tu as utilisé le support pro et le résultat que tu as eu ???
      Merci
      • [^] # Re: T'es juste nul.

        Posté par . Évalué à 2.

        1. au taff, je passe pas une demi-journée à attendre la réponse du support pro. Dans le pire des cas, je conte fleurette mais personne ne se plaindra de badiner avec une jeune demoiselle au frais de la princesse.
        2. Je ne suis pas admin et donc je n'ai pas directement affaire à eux.
        Comme je l'ai dit quelque part, si tu n'as pas besoin de l'expertise de RedHat, passe à autre chose. Mais quand tu tombes sur un bug bien retors dans la GLibc, le noyau, un pilote (ce qui n'est pas rare), tu es bien content d'avoir derrière des gens compétents.
        D'après les echos sur IRC, pour certains *gros* clients, le support de RedHat au niveau de la virtualisation a été capital dans le succès du service.
        3. C'est mon style brut de fonderie, il n'y a aucune once de méchanceté ou d'hostilité.
        • [^] # Re: T'es juste nul.

          Posté par (page perso) . Évalué à 3.

          Pas de problème pour le ton, je me suis pas vexé... Et puis, je peux que te remercier puisque tu m'as fais gagner du temps pour l'install de phpMyAdmin !!!
          Comme je l'ai dit quelque part, si tu n'as pas besoin de l'expertise de RedHat, passe à autre chose.
          J'aimerais bien !!! Mais c pas moi qui décide ;)
        • [^] # Re: T'es juste nul.

          Posté par (page perso) . Évalué à 3.

          J'ai eu une fois un bug noyau, problème dans un module important, j'ai contacté le mainteneur du paquet directement sans passer par le support et sans passer par bugzilla tellement c'était urgent (pour les prochains qui allaient mettre à jour). 2 heures plus tard, un nouveau noyau était disponible. Je n'aurais pas pu avoir cette réactivité en faisant autrement.
          Sinon, on a eu une fois un support redhat pour une installation d'un cluster, le niveau de l'ingénieur était bon. Ce sont les niveaux des supports constructeurs qui sont mauvais : les rôles ont tendance à s'inverser, le support c'est nous, on pourrait téléphoner pour commander des pizzas, ça serait bien plus utile.

          Christophe

      • [^] # Re: T'es juste nul.

        Posté par (page perso) . Évalué à 2.

        Mais pourquoi attendre ?
        Face à un problème qu'un support devrait résoudre, tu ouvres un ticket !
        Ensuite, si tu as du temps à consacrer à ce problème, par rapport à ta liste des tâches, au lieu d'attendre bêtement la réponse (avec une solution parce que l'AR ne compte pas, hein), tu peux commencer tes propres investigations.
        Ainsi, si le support a manqué à ses obligations, tu seras couverts car tu auras fait appel à eux (et n'hésite pas à en faire part à tes supérieurs lors de tes CR sinon, ils n'en sauront jamais rien) et si ta solution de contournement fonctionne, tu en seras d'autant crédité.
    • [^] # Re: T'es juste nul.

      Posté par (page perso) . Évalué à 3.

      Je voudrais juste revenir sur une chose : RedHat en France (pour le reste du monde je ne sais pas) ne fait pas de vrais support, RH c'est le support le plus merdique que je n'ai jamais vue, combien de fois j'ai vue débarqué des ingénieurs support qui n'y connaissent pas grand chose en RH et encore moins en linux alors qu'ils sont de chez redhat (pas des presta des offciels RH), combien de fois je me suis fait envoyer paitre par le support RedHat parce que pour corriger le bug (simple avec patch officiel upstream existant ) il fallait attendre la prochaine release majeure RedHat, je précise qu'il s'agissait du support chez des très gros compte, pas forcément des comptes majeurs pour RH mais des très gros compte quand même, qui potentiellement auraient pu devenir des comptes importants chez RH.

      Donc je suis désolé, mais RedHat question support c'est à la rue...
      • [^] # Re: T'es juste nul.

        Posté par . Évalué à 2.

        > RedHat en France (pour le reste du monde je ne sais pas) ne fait pas de vrais support

        Voilà un point qui mérite d'être soulevé: est-ce une insuffisance de RedHat ou simplement de RedHat France ? Je ne saurais pas te répondre, je sais juste que leurs homologues US et britanniques du moins les techos font assez bien leur boulot.
        • [^] # Re: T'es juste nul.

          Posté par . Évalué à 5.

          De toute manière, ils devraient remonter le problème quand ils ne savent pas. C'est ce que font toutes les boites sérieuses. Si un ingénieur "support" ne sais pas, il va demander directement à l'équipe qui développe/maintien le code en question et ceux-ci te distribuent un patch spécifique à ton problème si celui-ci est important pour toi et qu'il ne sera corrigé que dans une release supérieure.
          • [^] # Re: T'es juste nul.

            Posté par . Évalué à 2.

            oui et les utilisateurs de RH france devraient remonter le manque de sérieux de "l'antenne locale" à la maison mère... perso je l'ai fait et j'ai pas eu de retour... peut être qu'en gueulant un coup en groupe... car, en effet, il y a un monde entre le suport fr et us ou GB...
    • [^] # Re: T'es juste nul.

      Posté par . Évalué à -3.

      Oui, il faut être nul pour installer phpMyAdmin.
      Un bon admin n'installe pas ce genre de truc.
      Un bon admin RHEL n'installe pas phpMyAdmin.
      Un bon admin RHEL sait qu'il existe plein de dépôt RHEL/Fedora et sait adapter un paquet Fedora à RHEL.
      Un bon admin RHEL sait que RHEL est pour le support ET l'assurance qualité. Ce bon admin préférera peut-être une Fedora, mais il sait, bien que les similitudes soient nombreuses entre RHEL et Fedora, que ses deux distributions n'ont pas la même cible.

      Plus globalement, on a ici un mec qui connait mieux Ubuntu que RHEL...
      C'est tout.

      Puis les gus qui disent que le support de RHEL est mauvais, ben il y a quoi à côté alors qu'on compare RHEL à Ubuntu ?
      Du support à la Ubuntu pour RHEL, ça existe. C'est Centos et autres clônes.
      • [^] # Re: T'es juste nul.

        Posté par . Évalué à 6.

        Le bon admin qui veut rester dans le redhat préfèrera CentOS et non Fedora qui est plutôt une distribution pour poste client.
      • [^] # Re: T'es juste nul.

        Posté par (page perso) . Évalué à 7.

        Le gus je le prends pour moi, puisque je suis le premier à en avoir parler, alors :
        1/ je n'ai pas comparer a Ubuntu, je ne connais pas le support d'Ubuntu et ne veux même pas le connaître.
        2/ j'attends d'un support que le gus connaissent mieux que moi le système
        3/ j'attends d'un support qu'il puisse me fournir des patchs testé et validés par eux pour des packages clefs du système (ces patchs existent upstream il suffit de les backportés, ce qui est simple, j'ai réussit à le faire mais voulant conserver le support RH, j'ai demandé au support de le faire en indiquant la marche que je suivit pour y arriver)
        4/ j'attends du support autre chose comme réponse que faut tester avec la release n+1 si elle existe ou celle qui viendra quand mon problème je l'ai sur une release officiellement supportée.

        Le support de SUN sur du Solaris est nettement meilleur par exemple. Je ne connais pas le support de Novell ou celui des autres distributions, mais RH France (je ne sais pas pour le reste du monde) c'est de la merde, donc valorisé le support pourri en disant bah tu payes le support ailleurs non alors que le support est proche de /dev/null chez eux non, peut être qu'il faut remonter ça à la maison mère aux US ou quoi que ce soit, mais ça je ne veux pas le savoir, si je paye du support je veux du vrais support.

        Mes excuses d'avances aux quelques employés RH France qui sont bon il doit (j'espère) quand même y en avoir, mais le support global est nul.
        • [^] # Re: T'es juste nul.

          Posté par . Évalué à 6.

          Le role d'un support n'est pas de faire de la formation a quelqu'un qui n'y connait pas grand chose (au moins dans l'environnement concerne).
          Dire que le support Redhat (France) est "nul" ne sert a rien car il n'y en a pas. Le support RH France se trouve en Angleterre, en revanche il y a un Service Professionel pour les prestations et un Centre de Formation.
          La cle d'activation, qui visiblement est a l'origine de ce post, est disponible sur RHN via le compte du client. Il faut pour cela, il est vrai, que RHN soit operationnel et disposer du code client (2h30 de down time ne representent pas 3 jours de travail)
          En plus si on connait son environnement (Rhel en l'occurence) on telecharge l' iso avant sa prestation et utilise des outils comme kickstart ce qui peux reduire les 3 jours d'install a quelques heures (encore faut il savoir que ca existe ;) ).
          Accepter une prestation chez un client c'est accepter de faire ce que le client demande et dans l'environnement qu'il souhaite, avec l'obigation de conseil a laquelle on est tenu. Si on est pas capable de realiser ce que le client demande on se forme ou on ne repond pas (un coup de gueule est toujours plus facile qu'une remise en question). Si Redhat France ne fait pas (localement) son support la societe dispose d'un centre de formation ouvert a tous.
          Le fait de preconiser la seule distribution que l'on connaisse ne fait pas de soi un specialiste linux, c'est un peu comme savoir installer windows et se declarer specialiste systeme (ATTENTION: il y a des specialistes systemes qui ne connaissent que windows ;) ). L'important c'est d'avoir un peu d'ouverture d'esprit et de savoir s'adapter.
          Pour finir, Redhat qui gagne de l'argent avec linux le reverse en partie en salariant des developpeurs qui ne se consacrent qu'a ce cher systeme d'exploitation qui est le meme sur toutes les distributions (packaging, et autres differences mineures s'entend)....
          • [^] # Re: T'es juste nul.

            Posté par (page perso) . Évalué à 2.

            J'avoue avoir un peu de mal à supporter tes critiques :
            Tu ne connais pas les tenants et les aboutissants de la prestation et pourtant, tu me dis que j'avais qu'à pas répondre à celle-ci.
            Si je n'avais accepté que des missions ou je connaissais tout de A à Z, je ne sais pas ce que je boufferais aujourd'hui (et ma famille avec).

            Je tiens à te dire que ca y est, tout fonctionne, et que j'y suis arrivé, avec un RHEL et que maintenant je connais mieux cette distrib.
            Je continue à penser, suite à tout ces commentaires, que j'aurais mieux fait de faire cela avec une Debian :
            - Parce que cela aurait été plus vite
            - Parce que le support n'est pas indispensable (voir inacessible) pour mon client

            En bref, j'aurais plus à en dire la prochaine fois qu'un client me parlera du support Redhat, et ce, grâce à toute ces discussions.
            • [^] # Re: T'es juste nul.

              Posté par . Évalué à 2.

              > Si je n'avais accepté que des missions ou je connaissais tout de A à Z, je ne sais pas ce que je boufferais aujourd'hui (et ma famille avec).

              C'est ta démarche, risquer mais nécessaire. Il faut l'assumer (oui, c'est dur, bon courage).

              > j'aurais mieux fait de faire cela avec une Debian

              Ce qui est désagréable avec toi, c'est que tu dis "Debian c'est mieux", seulement car tu ne connais pas RHEL.
              Il y a plein d'admin RHEL/Fedora qui n'ont pas envis de se prendre une Debian "dans la gueule" car ils ne connaissent pas Debian. Il y a plein d'admin RHEL qui ont dû s'aventurer sur Debian temporairement et ils n'en sont pas sorti très fière. Mais ils ne vont pas vomir Debian pour autant.

              En passant, une RHEL est supporté 7 ans minimum (ce que ne fait pas Debian). Et avec compatibilité source et binaire (sauf quelques gros paquet comme Firefox, OOo). Rares sont ceux qui le font.
              Beaucoup de bug noyau/libc/etc sont corrigés par Red Hat. Certes, tu vois ces corrections dans Debian rapidement, mais Debian n'est souvent pas en mesure de les faire. Et ce boulot c'est bien du support (même si tu peux l'avoir gratuitement dans une CentOS, c'est du boulot de support de RHEL).
              Parce que le support de RHEL est fort, Ubuntu veut la synchronisation avec RHEL (car Ubuntu n'arrive pas à fournir le même support que RHEL, Ubuntu veut récupérer le boulot de RHEL).

              Tu as eu une mauvaise expérience avec RHEL. OK, ça t'as refroidi et tu fuis RHEL. Je te comprend.
              Mais de la à vomir sur RHEL et son support, puis conclure "Debian c'est mieux", c'est fort de café.
            • [^] # Re: T'es juste nul.

              Posté par (page perso) . Évalué à 3.

              Oui mais le client, il s'en fout.
              Il te demande un contexte technique précis, à toi de t'y tenir.
              Il en a rien à faire que ta famille dépend de toi pour manger.
              Il ne t'a pas forcé la main à signer le contrat ? Et si c'est trop dur en indépendant, pourquoi ne pas (re-)venir à la société de services ou autre poste de salarié ?
              La prochaine fois que tu proposeras une modification du contexte initialement demandé, assure-toi de le faire cofnirmer PAR ÉCRIT. Les paroles s'envolent, etc.. Mais si dans le cahier des charges ou CCTP, il y avait explicitement mentionné RHEL, tu étais en porte-à-faux vis-à-vis de ton client. Que certains prestataires mentent sur les compétences techniques réelles, qu'ils assument mais que cela ne porte pas le discrédit sur leurs confrères.
            • [^] # Re: T'es juste nul.

              Posté par . Évalué à 2.

              Tu te permet de critiquer toute la structure Redhat France et donc les gens qui la compose sans pour autant avoir eu affaire a eux et tu ne supporte pas mes critiques :-).
              Je ne connais de ton affaire que ce que tu as bien voulu dire c'est a dire ton incompetence sur Redhat et ta volonte de mettre de l'Ubuntu pour que tu puisses comprendre ce que tu fais.
              Il ne s'agit pas de savoir si tu dois accepter des missions ou tu connais tout de A a Z mais simplement que quand tu ne sais pas ne critique pas (ou soit constructif).
              Tu dis avoir croiser "de visu" des gens du support de Redhat France (et pas des sous traitants) alors que ce n'est pas possible ou alors c'en etait un qui etait ivre et en vacances loin de son port d'attache....et encore j'y crois pas :), en plus il serait nul c'est pas de pot ....
              Si tu veux denigrer Redhat fait le honnetement. La critique permet d'avancer si elle est constructive et si tu ne la supportes pas dans ce cas la abstient toi.
              Je pense que malgre tout ca tu n'auras rien de plus a dire, d'ojectif et d'honnete en tout cas, sur le support Redhat a tes clients.
              Ce qui est sur c'est que ces querelles de clocher d'une distrib a une autre ne servent pas la cause Linux dans son ensemble.
              Unix a perdu pied face a Microsoft a cause de ce genre de stupidite et il serait bon que l'histoire ne se repete pas...
              Bon ca c'est fait maintenant je retourne jouer avec ma Slack..... tu connais ?


          • [^] # Re: T'es juste nul.

            Posté par . Évalué à 2.

            > Pour finir, Redhat qui gagne de l'argent avec linux le reverse en partie en salariant des developpeurs qui ne se consacrent qu'a ce cher systeme d'exploitation qui est le meme sur toutes les distributions (packaging, et autres differences mineures s'entend)....

            c'est pas faux mais hors-sujet ici. de la même façon que les oeuvres philanthropiques de Bill Gates ou Microsoft n'excusent en rien la piètre qualité de certains produits.
            • [^] # Re: T'es juste nul.

              Posté par . Évalué à 2.

              > c'est pas faux mais hors-sujet ici

              Pas vraiment.
              Par exemple l'excellent Alan Cox bosse upstream mais répond aussi au support de Red Hat.
              Une grande partie des développeurs Red Hat fait aussi du support.
              Certe Alan Cox ne va pas répondre pour ton problème de compte RHN ou de configuration de carte réseau. Mais pour des grands comptes qui ont des problèmes pointus ou des besoins de conseils, ou pour IBM qui n'arrive pas à faire marcher correctement une bécane avec RHEL, il peut intervenir. Le patch sera dans RHEL et biensûr en upstream.

              Le support ce n'est pas qu'avoir des bimbos qui répondent au téléphone. C'est l'expertise, la compétence. Avoir des développeurs upstream est très important.
        • [^] # Re: T'es juste nul.

          Posté par (page perso) . Évalué à 4.

          Amusant que tu compares cela au support SUN, parce que de la langue même de certains employés de SUN France, ce n'est pas franchement le cas. Ou alors, tu parles très bien l'anglais international avec les accents indiens, etc.
          Une fois, j'ai fait appel à eux et il m'a fallu é-p-e-l-e-r « /usr/lib/... » et mon interlocuteur n'avait aucune base en système Unix. Au final, j'ai trouvé entretemps une solution de contournement via Google, sur un site de SUN et j'ai demandé l'avis du support qui l'a approuvé. Mais ils n'ont pas été capable de me fournir l'information en question avant.
          En fait, le support de niveau 1 est mutualisé et, si tu ne connais pas les bons mot-clés à utiliser, tu risques d'avoir un ticket mal routé.
          Et ce genre de centres de support mutualisés est, àmha, à la base même de dédain qu'ont les professionnels vis-à-vis des supports techniques. Et, au risque de me répéter, il s'agit d'une conséquence de la rationalisation financière de ces centres qui ont néanmoins un coût.
          Un « vrai » support dispose donc de personnels qualifiés, ayant des connaissances techniques et donc, qui coûtent très chers, en tout cas, certainement plus chers que la plupart des personnels employés.
  • # Debian / Ubuntu

    Posté par (page perso) . Évalué à 1.

    Tu dis, je cite : "à peine une journée avec mon Ubuntu (ca aurait été juste un peu plus long avec une debian.)"

    Alors là c'est probablement un troll mais je ne vois pas en quoi une ubuntu aurait pu te faire gagner du temps, j'ai presque envie de dire, au contraire.

    Je suis utilisateur quotidien sur desktop d'ubuntu et debian et franchement, les différences entre les 2 sont quand même faibles pour une utilisation serveur... (bon en même temps, j'ai jamais eu l'idée de foutre une ubuntu en serveur alors que je peux mettre une etch)



    (et sinon, ouais moi non plus j'aime pas redhat... le seul avantage pour moi c'est qu'il y a une boite pour faire du support... dans le cas de debian c'est à ta boite de faire le support ou de passer par une autre boite qui va assurer le support...)

Suivre le flux des commentaires

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