totof2000 a écrit 1555 commentaires

  • # tuple

    Posté par  . En réponse au message Retourner deux valeurs. Évalué à 1.

  • [^] # Re: Et dans Pijul ?

    Posté par  . En réponse au journal Adieu vieille branche. Évalué à 4.

    Chut, tu vas offenser tous ceux qui ont perdu un membre de leur famile dans un incendie …

  • [^] # Re: Est-ce un problème?

    Posté par  . En réponse au journal Adieu vieille branche. Évalué à 4.

  • [^] # Re: N'allez pas chez OVH

    Posté par  . En réponse au journal OVH - Le nuage part en fumée ?. Évalué à 3. Dernière modification le 14 mars 2021 à 18:52.

    Cette phrase élimine tout discours critique sur OVH de la personne qui l'écrit.

    Encore des préjugés …. Tu ne connais pas le besoin et tu te permets de critiquer ? Il y a des cas ou l'auto-hébegement peut suffire (tout comme il y a des cas ou une offre bas de gamme comme OVH peut suffire également). A une certaine poque j'avais des besoins qui pouvaient être couverts par un auto-hébergement + sauvegarde sur autre site. Je ne gérais pas mes mails, et c'était plus des besoins perso (pas forcément besoin de dispo 24/7, et si coupure il y avait lorsque j'étais en vacances - ce qui est arrivé une fois sute à une coupure EDF - je pouvis appeler une persone de confiance qui avait les clés pour remettre en marche l'ensemble du bouzin).

    Maintenant pour un besoin pro, je reverrais certainement ma façon de faire. Mais tout le monde n'a pas des besoins "pro".

  • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

    Posté par  . En réponse au journal OVH - Le nuage part en fumée ?. Évalué à 3. Dernière modification le 11 mars 2021 à 23:46.

    Oui, je suis mauvaise langue (aussi mauvaise que sur ceux qui se plaignent d'avoir perdu leur site ou leurs données à cause de ça alors que la faute est plus proche d'eux qu'ils ne veulent l'imaginer :) ).

    C'est ce qui se passe quand on joue les têtes brûlées (oui, je suis chaud ce soir …).

  • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

    Posté par  . En réponse au journal OVH - Le nuage part en fumée ?. Évalué à 4.

    Je diraios qu'il brûle d'envie de le savoir …

  • [^] # Re: Froid dans le dos

    Posté par  . En réponse au journal OVH - Le nuage part en fumée ?. Évalué à 3.

    J'ai bossé pour une boite qui avait son propre nuage: le service juridique ne nous a jamais interdit de faire en sorte que ça marche mieux que strictement prévu par Loi et les contrats :-)

    Anéfé, souvent ce sont les services commerciaux et financiers qui t'en empêchent.

  • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

    Posté par  . En réponse au journal OVH - Le nuage part en fumée ?. Évalué à 5.

    Je suis expert de salon qui imagine qu'il doit bien avoir sa petite idée genre "je n'ai pas voulu signer l'achat du matos qu'on me disait que j'avais besoin en cas d'incendie; faut pas déconner, ça ralenti le déploiement et ça coûte une blinde la sécurité incendie pour si peu d'usage"…

    Je suis sûr que tu en mettrais ta main au feu …

  • [^] # Re: test grandeur nature :-/

    Posté par  . En réponse au journal OVH - Le nuage part en fumée ?. Évalué à 10. Dernière modification le 11 mars 2021 à 22:22.

    A une époque j'aurais parlé d' "humour noir" mais certains, tout feu tout flammes, y auraient vu une connotation raciste … Du coup j'ai préféré éviter les querelles fumeuses ou les discussions enflammées. La moindre étincelle pourrait mettre le feu au poudre et certain en profiteraient pour ajouter de l'huile sur le feu.

  • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

    Posté par  . En réponse au journal OVH - Le nuage part en fumée ?. Évalué à 10.

    Tu es mauvaise langue. Si ça se treouve, il a honte de dire que la sécurité a laissé entrer un employé avec son cable firewire.

  • [^] # Re: Octave Klaba explique et s'excuse dans une vidéo

    Posté par  . En réponse au journal OVH - Le nuage part en fumée ?. Évalué à 9.

    Pour ma part, à sa place je ne serais pas très fier de moi non plus …

    Ca explique la source, mais ça n'explique pas pourquoi le DC a brûlé en entier

    On ne le saura pas de suite. Je pense qu'à sa place je ne m'avancerais pas trop non plus sans avoir suffisamment d'éléments (surtout aujourd'hui avec les sur-réactions que l'on voit/entend de partout sur les réseaux sociaux). La transparence peut se retourner contre toi.

    "expert en carton", mais je sais que les départs de feu font partie de la vie d'un DC et que dans ce cas la on est sensé perdre au pire le DC pendant quelques jours le temps de remplacer ce qui a commencé à crame mais pas le DC entier à vie)…

    C'est normalement ce qui est fait lorsqu'on, travaille dans "les règles de l'art". La il semble que côté OVH, ils ont voulu se la jouer à la Elon Musk en tentant de révolutionner les datacenters en changeant un certain nombre de choses. Pas de bol, ils ont perdu, et tout un datacenter est cramé. Mais d'un autre côté, personne ne peut dire qu'il ne savait pas (cf le fil https://lafibre.info/ovh-datacenter/ovh-et-la-protection-incendie/ ). Et dans l'échange, j'invite celles et ceux qui se plaignent ici des experts "en carton" d'aller le lire en entier. On y apprend pas mal de choses sur les règles élémentaires de sécurité dans un datacenter. Ces choses sont expliquées par de vrais experts, qui travaillent dans ce domaine, et qui ont dès le début mis en doute la possibilité d'éteindre un feu avant qu'il ne se propage dans tout un DC (Ca se fait, et quand c'est bien fait au pire du pire, tu perds une salle, pas un DC complet). Et pas besoin d'être un expert pour comprendre que là il y a clairement eu une négligence de la part d'OVH sur la prévention des risques et éviter que l'incendie ne se propage. Il suffit d'avoir bossé un peu dans ceux-ci (ce qui est le cas de beaucoup de monde ici) ou d'en avoir visité un avec une personne dont c'est le métier de gérer un datacenter, pour vite comprendre qu'il y a un truc qui va pas dans les datacenters OVH. Pour ma part, je ne suis pas un expert (dans le sens ou ce n'est pas mon métier), mais j'ai assisté/participé à des constructions et déménagements de datacenter, et j'ai passé des nuits parfois à l'interieur de ceux-ci. Et bien souvent quand tu bosses dans ce genre de lieux, on t'explique bien ce qui se passe, les risques incendie, les risques électriques, on te dit surtout que si un incendie se déclare dans une salle il ne faut SURTOUT PAS essayer de l'éteindre, mais il faut sortir de la salle et appeler les pompiers. A l'époque ou je bossais en datacenter, rester dedans en cas d'incendie pouvait être mortel car il y avait du gaz qui se propageait pour tenter de limiter la propagation du feu …

    Après il semble que cette stratégie ait été assumée des le début (cf le tweet ou il dit "s'il y a incendie, tout est mort avant l'eau"). Par contre le fait que personne ne soit blessé montre que les plans d'évacuation étaient bien faits …

  • [^] # Re: test grandeur nature :-/

    Posté par  . En réponse au journal OVH - Le nuage part en fumée ?. Évalué à 3.

    Bon, je précise quand même que je plaisante … (il y a des gens qui pourraient me prendre au sérieux. Si c'est le cas, n'y allez pas, de toute façon vous vous ferez jeter par la sécurité).

  • [^] # Re: test grandeur nature :-/

    Posté par  . En réponse au journal OVH - Le nuage part en fumée ?. Évalué à 10.

    Je propose d'ailleurs aux clients d'OVH de se rendre à l'intérieurs des datacenters pour y allumer des cierges en priant pour qu'un ncendie ne se déclare pas sur les autres sites.

  • [^] # Re: Dans la langue de Jean-Baptiste Poquelin

    Posté par  . En réponse au lien Oh le beau bug (dans une rc1) (mais c'est un sacré bug). Évalué à 2.

    ça demande à être mis en place avant même l’installation du système

    Les distributions bien faites te le configurent à l'installation (ce n'est pas le cas d'Ubuntu d'ailleurs). Et honnetement, lvm ça reste assez simple, comparé à d'autres gestionnaires de volumes.

  • [^] # Re: Dans la langue de Jean-Baptiste Poquelin

    Posté par  . En réponse au lien Oh le beau bug (dans une rc1) (mais c'est un sacré bug). Évalué à 1.

    Je n’utilise que des fichiers de swap, système que je trouve bien plus simple et souple que les partitions dédiées.

    Ah bon ? Avec LVM, c'est pourtant très souple à gérer …

  • [^] # Re: Dans la langue de Jean-Baptiste Poquelin

    Posté par  . En réponse au lien Oh le beau bug (dans une rc1) (mais c'est un sacré bug). Évalué à -1.

    Moi je l'ai fait, mais j'ai du me battre avec systemd, qui a tout changé encore une fois pour rien …

  • [^] # Re: Dans la langue de Jean-Baptiste Poquelin

    Posté par  . En réponse au lien Oh le beau bug (dans une rc1) (mais c'est un sacré bug). Évalué à 3.

    On ne peut pas vraiment qualifier ubuntu de distro normal tant ils tendent à faire cavalier seuls sur certains choix techniques.

    Bof, pas plus que Fedora/Redhat ou Suse ou arch

  • [^] # Re: Monitoring

    Posté par  . En réponse au message Outil permettant de prévenir les utilisateurs d'un service . Évalué à 1. Dernière modification le 05 mars 2021 à 22:14.

    usine à gaz … En plus il me faudrait gérer au moins deux groupes distincts d'usagers. Puis au final, c'est détourner le monitoring de sa fonctionnalité principale : avertir les équipes techniques d'un dysfonctionnement, de préférence avant que le service ne soit perturbé. Après, au final, si l'outil le permet, on pourrait l'interfacer avec la supervision pour que certtaines alertes (les alertes critiques indiquant une perte de service) envoient un message pour prévenir les utilisateurs, mais de mon point de vue, ce sont bien deux fonctionnalités différentes (a moins que les outils de supervision intègrent cette fonctionnalité - je pensais à Prometheus Alert Manager par exemple, mais celui-ci ne gère pas l'abonnement-désabonnement à une liste de diffusion).

  • [^] # Re: Inclusif ?

    Posté par  . En réponse au journal Point médian sur clavier US international. Évalué à 0.

    Pourtant, ça doit poser le(s) même(s) problème(s).

    Pas exactement. Le point est u élément de "rupture", ce que n'est pas la parenthèse. Celà dit je t'accorde qu'un texte avec plein de parenthèses sera également difficile à lire à la longue.

  • [^] # Re: GLPI

    Posté par  . En réponse au message Outil permettant de prévenir les utilisateurs d'un service . Évalué à 1.

    J'ai du mal exprimer mon besoin alors …. :) Ou alors je n'ai pas vu la fonctionnalité qui m'intéresse sur le site de GLPI Mais en regardant ce que fait GLPI, je me demande s'il ne pourrait pas remplacer JIRA.

  • [^] # Re: Cachet

    Posté par  . En réponse au message Outil permettant de prévenir les utilisateurs d'un service . Évalué à 1.

    Ca ressemble effectivement à ce que je cherche.
    Merci.

  • [^] # Re: Monitoring

    Posté par  . En réponse au message Outil permettant de prévenir les utilisateurs d'un service . Évalué à 1.

    LA supoervision est déjà en place, et elle ne concerne que les gestionnaires du service. Ce que je cherche c'est un moyen de prévenir les utilisateurs du service que celui-ci a un dysfonctionnement, et qu'une intervention est en cours, sans pour autant qu'il soit au couyrant de toutes les alertes qui passent sur la supervision (des indicateurs oranges ou rouges ne signifient pas forcément que le service est down, exemple : un filesystem plein a 95% émettra une alerte préventive : le service ne sera pas impacté, et l'utilisateur du service n'a que faire de ce genre d'alerte).

  • [^] # Re: GLPI

    Posté par  . En réponse au message Outil permettant de prévenir les utilisateurs d'un service . Évalué à 1.

    En fait ce que je cherche c'est plutôt un truc qui ressemble à un gestionnaire de liste de diffusion … Après, qu'il puisse s'interfacer avec un outil de supervision, pourqui pas, mais à la base tout ce que je cherchen, c'est d'éviter à avoir à gérer moi-même les destinataires des messages : les personnes intéressées s'abonnent, ou se désabonnent si elles ne veulent pas être au courant. Dans un premier temps, l'envoi de notification se fera plus ou moins en mode semi-auto (pas de détection auto des pannes, juste sélectionner un message dans un template correspondant à un événement : incident, service rétabi, etc …).

    Ce n'est pas une mailing liste pour pévenir les admins, mais pour les utilisateurs du service leur indiquant que celui-ci est downn, dégradé, ou est de nouveau up.

  • [^] # Re: GLPI

    Posté par  . En réponse au message Outil permettant de prévenir les utilisateurs d'un service . Évalué à 1.

    A regarder vite ait, il a l'air surtout orienté "parc informatique" et non "service", a moins qu'un module permette de le faire.

    Cordialement.

  • [^] # Re: GLPI

    Posté par  . En réponse au message Outil permettant de prévenir les utilisateurs d'un service . Évalué à 1.

    Merci, c'est déjà un bon début.

    Je jette un oeil.