Bonjour,
Ce matin je suis tombé sur cet article décrivant comment le groupe Manutan s'est sortis de la cyberattaque qu'il a vécu en 2021.
Article source : https://www.lemagit.fr/etude/Recit-comment-Manutan-sest-sorti-de-la-cyberattaque-du-21-fevrier
Je trouve l'article intéressant et donc je vous invite à le lire mais je vous relève quelques points :
- Microsoft qui veut se placer en leader les a laissé tombé
- Faite des sauvegardes et avec des outils plus poussés que rsync
- Utilisez Linux à la place de Windows :D , plus sérieusement suite à l'attaque Manutan a décidé de mieux équilibrer sont utilisation de Linux et de Windows, ne pas mettre tous ses oeufs dans le même panier.
- Avoir un anti virus n'est pas suffisant
# Oui et non...
Posté par ptit_poulet . Évalué à 10.
Alors oui et non. Microsoft ne les a pas vraiment lâché. Ils se sont juste rétractés pour une intervention immédiate car au final le contrat côté utilisateur n'était pas respecté, puisque la plus part des SI n'étaient pas à jour. Du coup le travail n'étant plus le même à leurs niveaux ils ont proposé un devis et une date d'intervention.
Ça me parait pas illogique. Imagine je te préviens que tes lacets risquent de casser, ce qui pourrait provoquer une chute grave dans les escaliers. Mais je t'en fournis des tous neufs, il faut juste que tu les installes toi même. Mais tu refuses de le faire parce que tu as pas le temps car tu portes tes chaussures tout le temps et 15j après tu tombes dans les escaliers car les lacets se sont cassés… Forcément quand tu vas te tourner vers moi pour prendre en charge les frais d'hospitalisation, je vais dire non.
Je pense que le problème aurait été le même que ce soit du Linux ou du Windows. A partir du moment où tu ne respectes pas le contrat.
[^] # Re: Oui et non...
Posté par Watchwolf . Évalué à 10.
Quand tu dis à ton client qui a son SI bloqué : "ok si vous payez on regarde dans 2 semaines" tu le lâche. C'est limite de la moquerie.
Microsoft aurait pu dire : "ok mais c'est hors support support donc vous allez payer" ou alors "on ne regarde pas, hors support, pas le temps …, allez voir ailleurs, tenez on a des pistes …" tu ne le lâche pas.
[^] # Re: Oui et non...
Posté par saltimbanque (site web personnel) . Évalué à 10.
L'article ne rentre pas assez dans le détail pour trancher.
Tout dépend s'ils ont juste manqué la dernière maj d'il y a 2 jours et que MS utilise cela pour se dédouaner, ou s'ils ont encore des serveurs sur Windows 95.
Avec SAP j'ai le problème, où au moindre bug applicatif il te demandent de passer sur la dernière version (alors que la précédente est encore supportée…). Impossible - c'est simplement un moyen de ne pas assurer le support, fort qu'ils sont de leur position de leader
D'autres commentaires sur la pratique de MS? et j'imagine que ça puisse dépendre du client
[^] # Re: Oui et non...
Posté par eingousef . Évalué à 7.
Y'a pas un truc jore
unattended-upgradessous windoze ?ça craint
*splash!*
[^] # Re: Oui et non...
Posté par abriotde . Évalué à 2.
Je dirais même plus, si tu prends un support, c est pour qu ils interviennent quoi qu il en soit. A partir du moment ou ce n est pas abusif et trop régulier.
Microsoft aurait dû intervenir, après le fait que ce ne soit pas à jour empêche juste l entreprise de demander des indemnités a Microsoft ou même Microsoft peut limiter son intervention à un minimum. Mais s ils n ont rien fait c est parce qu ils ont abusé en ce disant que l entreprise n en valait pas la peine (elle ne lui fera pas de procès, et elle n est pas assez grosse pour lui porter préjudice…)
Côté Microsoft, ce n est qu un calcul mercantile.
[^] # Re: Oui et non...
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2. Dernière modification le 10 décembre 2021 à 17:50.
Si si bien sûr.
WSUS + GPO permettent d'automatiser le déploiement des patches de sécurité et certaines mises à jours.
Par contre effectivement si on parle d'un SI a base de Windows Server 2008 ça ne le mettra pas magiquement à jour en server 2019
[^] # Re: Oui et non...
Posté par ptit_poulet . Évalué à 1.
[^] # Re: Oui et non...
Posté par ptit_poulet . Évalué à 6.
Ok mais du coup ils vont affecter des équipes sur un dossier hors contrat et les dites équipes ne pourront donc pas intervenir dans les temps sur des dossiers couverts par le contrats.
Tu ne peux pas avoir le beurre, l'argent du beurre, la crémière et le…
Je pense qu'il manque une grosse partie de l'histoire. On a seulement la version de l'entreprise, donc c'est un peu facile quand même. Si on creuse on va peut-être même trouver qu'en fait ils n'avaient même pas de contrat premium… Moi je préfère me méfier quand on a qu'une moitié de scénario.
[^] # Re: Oui et non...
Posté par abriotde . Évalué à 0.
La version Microsoft n est pas trop difficile a deviner. Ils l ont dis.
[^] # Re: Oui et non...
Posté par ptit_poulet . Évalué à 3.
Non l'entreprise a dit la version de Microsoft, nuance.
Il faudrait la version de Microsoft expliquée par Microsoft.
[^] # Re: Oui et non...
Posté par feth . Évalué à 5.
Comme l'histoire est écrite par les vainqueurs, j'en déduis que Microsoft est enfin vaincu, c'est un grand jour !
[^] # Re: Oui et non...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Oui et non. Le problème, c'est qu'ils ne mettaient pas à jour les centaines de serveurs une fois par semaine. Donc techniquement, on en arrive à la difficulté de mettre à jour un système Windows, ce qui revient à un détail technique qui est un véritable boulet que Microsoft traîne depuis des décennies, si je ne m'abuse : le verrouillage implicite en écriture des fichiers ouverts et l'absence de fichier sans nom.
Vous voyez, quand vous ouvrez un fichiers, sous GNU/Linux, notamment lorsque vous lancez un logiciel ? Sans plus de précision, le fichier correspondant n'est absolument pas verrouillé, un autre logiciel peut l'ouvrir en écriture et le modifier sous vos pieds. C'est moche, mais pas dramatique. D'une part, lorsque vous ouvrez un fichier, vous pouvez le verrouiller explicitement. D'autre part, pour mettre à jour des logiciels ou des bibliothèques, les gestionnaires de paquets écrivent les nouveaux fichiers avec un nom temporaire, puis suppriment l'ancien et renomment le nouveau avec le même nom que l'ancien.
Par exemple, pour installer une mise à jour de
/bin/ls, le gestionnaire de paquets va écrire la nouvelle version dans/bin/ls.new, supprimer/bin/lset renommer/bin/ls.newen/bin/ls.Pour un logiciel en cours d'exécution, qu'est-ce que ça change ? Rien du tout, l'ancienne version, toujours ouverte, n'a plus aucun nom dans le système de fichiers, mais est toujours présente dessus : elle sera supprimée lorsque la son compteur de liens (déjà à zéro donc) et son compteur d'ouvertures arrivera à zéro.
Du coup, vous pouvez mettre à jour tout ce que vous voulez, puis relancer plus tard, quand vous voulez les processus concernés par ces mises à jour. Il faut tout de même penser à le faire, sinon vous gardez des processus obsolètes et potentiellement troués. Si la mise à jour concerne le noyau, là, rien à faire, il faut redémarrer.
Ça, c'était sous GNU/Linux. Sous Windows, rien de tel. Pour mettre à jour un logiciel en cours d'exécution, donc ouvert, impossible d'écrire sur son fichier, qui est verrouillé. On peut l'installer avec un nouveau nom, mais impossible de supprimer l'ancienne version pour ensuite renommer la nouvelle. Du coup, que fait-on ? On écrit une note pour le prochain redémarrage, qui demande au système de faire cette opération pour vous, très tôt dans le processus de démarrage. Donc… redémarrage à tous les coups, même pour des mises à jour qui ne concernent pas le noyau.
[^] # Re: Oui et non...
Posté par Watchwolf . Évalué à 3.
Il existe quand même une astuce concernant Windows :
- déplacer le fichier en cours d'utilisation
- renommer le nouveau
Le fichier déplacé restera là, ne sera pas supprimé mais au prochain redémarrage l'application utilisera bien le nouveau
[^] # Re: Oui et non...
Posté par paulez (site web personnel) . Évalué à 2.
Sous Linux le processus continue à utiliser l'ancienne version du fichier, potentiellement vulnérable pour une mise à jour de sécurité. Donc au final il faut au moins redémarrer l'applicatif, ce qui revient vite au même.
[^] # Re: Oui et non...
Posté par Renault (site web personnel) . Évalué à 8.
Puis même sous Linux il est recommandé de faire les mises à jour à froid, c'est-à-dire avec le système en mode minimal pour mettre à jour comme Windows.
Déjà car comme tu le mentionnes, la mise à jour d'une application n'est vraiment effective que si on relance les applications. Les composants systèmes (noyau, systemd / autres systèmes d'init, X11, les environnements de bureaux) ne sont pas relancés à chaud en général en dehors du redémarrage du système donc le redémarrage reste requis.
Ensuite car une mise à jour est un processus malgré tout fragile, qui consomme des ressources, des services sont relancés et ça peut foirer car en conflit avec ce qui est fait sur le machine. On a eu un tel exemple chez Fedora qui était d'ailleurs générique : https://forums.fedora-fr.org/viewtopic.php?id=65807 mais parfois c'est plus subtile.
Enfin, admettons que tu mettes à jour Firefox et sa dépendance NSS lors de la même procédure de mise à jour. Exemple fictif, tu lances Firefox quand NSS a été mis à jour mais pas Firefox, tu as potentiellement une dépendance dans une version incompatible avec ta version de Firefox qui est chargée ce qui peut donner des bogues étranges difficiles à reproduire.
La mise à jour par paquet n'étant pas une opération atomique, l'état du système est mouvant pendant une longue période de temps où pas mal de scénarios peuvent se produire.
[^] # Re: Oui et non...
Posté par paulez (site web personnel) . Évalué à 4.
Oui car simplement savoir ce qui doit être redémarré ou pas n'est pas simple, il faut généralement utiliser un outil comme "needs-restarting" sous Fedora ou "needrestart" sous Debian. Donc si on veut automatiser ça la manière la plus sûre est de toujours redémarrer.
Il y a même des cas où une mise à jour peut avoir des effets très étranges sur tout le système avec dbus ou systemd, car le processus a déjà été lancé, mais il charge une librairie dynamique, et il peut y avoir une incompatibilité entre les deux après une mise à jour.
Du coup ce que fait Fedora Workstation qui demande systématiquement de redémarrer pour installer les mise à jours est en fait la méthode la plus fiable, même si c'est parfois un peu frustrant.
[^] # Re: Oui et non...
Posté par Quinane . Évalué à 2.
En effet mais entre redémarrer un service et une machine, il y a quand même une différence. En temps et en impact si plusieurs services partagés tournent sur cette machine.
[^] # Re: Oui et non...
Posté par Zenitram (site web personnel) . Évalué à 3.
Sous Linux j'aime bien l'idée de Kpatch pour ne pas redémarrer le noyau. Mais je n'ai jamais essayé la chose (bonjour les tests pour être sûr que tout est bien corrigé partout…), j'imagine que ça se réserve à des pros de chez pros avec les tests à chaud à faire…
[^] # Re: Oui et non...
Posté par Renault (site web personnel) . Évalué à 10.
Cette méthode ne fonctionne que pour certains correctifs du noyau (pas tout) et l'objectif n'est pas d'atteindre l'uptime de 100% sur l'année.
Un exemple de cas d'utilisation, tu gères l'infra du NASDAQ, tu as besoin d'un uptime de 100% sur la journée le temps des opérations. La moindre coupure du serveur coûte cher et prend du temps (plusieurs dizaines de minutes au moins), les maintenances sont planifiées quand c'est fermé. Mais tu as besoin d'une sécurité à toute épreuve quand c'est ouvert, car tu es une cible privilégiée. Tu utilises kpatch pour corriger une faille critique pour tenir le temps de la prochaine maintenance où tu pourras te permettre de mettre à jour le système en entier proprement avec les redémarrages et tests nécessaires.
Utiliser kpatch pour se dispenser de redémarrer me semble être une mauvaise idée car c'est pas mal de boulot en plus pour suivre les correctifs (il est plus simple de mettre à jour le noyau) et tous les patchs du noyau ne sont pas compatibles à cause de la méthode employée. Donc à la fin tu es obligé de mettre à jour le noyau en entier quand même.
Notons qu'en plus du noyau, si tu mets à jour la glibc par exemple, tu es bon pour relancer tous les logiciels ou presque qui tournent sur ta machine, redémarrer est finalement nécessaire si tu veux que cela soit vraiment appliqué partout.
[^] # Re: Oui et non...
Posté par Quinane . Évalué à 2.
Merci Renault pour ces réponses.
[^] # Re: Oui et non...
Posté par pasBill pasGates . Évalué à 9. Dernière modification le 07 décembre 2021 à 20:29.
Toi tu vis encore dans les années 90
Quand tu as un service en ligne, que ce soit Windows ou Linux, tu le construis de manière à ce qu'il :
Et le deuxième point là, cela te permet de :
- mettre à jour ton service toutes les heures si cela te chante
- enlever des machines quand tu veux si ils ne répondent plus ou … si tu veux les patcher
C'est un concept basique de nos jours, et avec celui là, on se fout que la machine doive rebooter ou pas.
Non, le problème de cette boite c'est qu'ils ne savent pas gérer leur infrastructure.
Oh et sinon, pour ce qui est du patching : https://docs.microsoft.com/en-us/azure/automanage/automanage-hotpatch
# ha...
Posté par Zenitram (site web personnel) . Évalué à 10.
heu, non, ce n'est pas incohérent, on appelle ça l'automatisation. On fait pareil sous Linux d'ailleurs. Et plein de monde fait les MAJ à temps (quelque soit l'OS).
Au final, classique balance entre effort de maintenance et merdes à gérer quand ça merde.
[^] # Re: ha...
Posté par ptit_poulet . Évalué à 5.
Surtout quand on voit ce qu'on peut faire avec SCCM entre autre et une petite couche de PowerShell.
[^] # Re: ha...
Posté par Quinane . Évalué à 6.
Je suis d'accord qu'avec 800 serveurs, s'ils n'automatisent pas, ce sont des branques.
Sauf qu'avec Windows, les MAJ mettent une plombe et il y a redémarrage quasi-systématique (parfois plusieurs).
Avec GNU/Linux, déjà c'est bien plus rapide, et seules les MAJ noyaux réclament un redémarrage. Et encore il y a Live Patch.
Dans des petits boîtes qui n'ont pas de redondance, c'est une interruption de service, c'est vraiment chiant surtout quand on sait comment ça marche avec GNU/Linux.
Bien sûr il y a la balance coût d'exploitation / coût redondance. Mais justement avec Windows, pour une PME, on doit faire ce choix, sous GNU/Linux, pas besoin.
[^] # Re: ha...
Posté par Zenitram (site web personnel) . Évalué à 3.
Si tu n'es pas prêt à accepter cette interruption de service planifiée (genre 2 heures du matin) pour le service rendu, tu n'utilises pas de Windows non redondé à cet endroit, point barre, pas d'excuse pour ne pas mettre à jour (combien de temps? une fois par an?) car la mise à jour de sécurité fait partie du package.
PS : grâce au commentaire précédent je constate que la discussion avait déjà eu lieu :).
[^] # Re: ha...
Posté par Quinane . Évalué à 4.
On met à jour justement. Les MAJ de sécurité c'est quasi-hebdomadaire. C'est bien c'est suivi sauf que c'est une interruption de service. Et les choix logiciels faits imposent Windows. MAJ planifiée à 2h du mat' dans une PME avec peu de ressources info ? Si cela se passe mal ? Avec le nombre de serveurs et les MAJ décalées justement pour vérifier un jour ou deux que cela ne pose pas de problème ? Guère gérable.
Ta réponse est juste mais je disais juste qu'on a pas ce problème avec GNU/Linux.
[^] # Re: ha...
Posté par ptit_poulet . Évalué à 3.
Si ça se passe mal ? Hé bien tu restaures la VM dans l'état d'avant maj.
Ah ok ils ont 800 serveurs non virtualisés ?! Ouai mais là on ne peut plus rien faire alors…
[^] # Re: ha...
Posté par Quinane . Évalué à 3.
Là je ne parlais pas de Manutan, j'ai dit qu'avec 800 serveurs se plaindre en laissant entendre qu'il n'y a pas d'automatisation…
Là je parlais d'une PME, donc la VM, on oublie, au moins pour le moment. Il y a une resto système, avec une durée d'intervention de presque 1h… en heures ouvrées.
Vous allez me dire, c'est que ce n'est pas critique. J'ai déjà dit ok. Mais avec GNU/Linux, ces MAJ seraient sans interruption de service sauf pépin. Point barre aussi.
[^] # Re: ha...
Posté par groumly . Évalué à 10.
Je veux pas dire, mais 25 filiales, 2500 employés et 800 serveurs, j'appelle pas ça une pme, et s’ils ont pas des équipes (pluriel) en astreinte pour gérer ça, ils vont avoir d’autres problèmes que les mise à jour.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ha...
Posté par ptit_poulet . Évalué à 6.
Oui mais si tu n'as pas de redondance c'est que tu considères le service comme non critique, ou alors c'est que tu veux jouer avec la survie de ta boite en voulant économiser des bouts de chandelle.
Au boulot j'ai un serveur sous Windows (entre autres) que je considère non critique et pour les maj le reboot se fait la nuit vers 2h du mat car les 3min d'interruption n'impacteront personne.
[^] # Re: ha...
Posté par xulops (site web personnel) . Évalué à 10.
Ne jamais planifier un truc entre 2h et 3h du matin dans les pays qui ont un changement heure d'hiver/ heure d'été, c'est un coup à se demander pourquoi ça ne s'est pas fait, ou pourquoi ça s'est fait deux fois.
[^] # Re: ha...
Posté par ptit_poulet . Évalué à 1.
Je n'ai jamais eu ce problème pour un reboot planifier sous Windows.
Je ne vois d'ailleurs pas trop comment il pourrait l'exécuter 2 fois… Une fois qu'il a fait sa maj il n'y a plus de maj justement donc pourquoi voudrait-il demander à redémarrer pour une maj qui n'est plus ?
[^] # Re: ha...
Posté par xulops (site web personnel) . Évalué à 8. Dernière modification le 06 décembre 2021 à 13:59.
Dans le cas d'un reboot d'un serveur windows (ou d'une mise à jour), j'en sais rien, je ne touche pas à ces machins là (oui, je suis un homme chanceux).
Ma remarque se voulait plus générale : c'est une bonne pratique de bannir la tranche 2h-3h du mat pour les déclenchements planifiés, c'est une bonne habitude de choisir de lancer un truc avant 2h ou après 3h.
[^] # Re: ha...
Posté par Zenitram (site web personnel) . Évalué à 4.
J'ai écrit trop vite et comprend complètement ta phrase, oui, viser plutôt 3:01 :-p.
[^] # Re: ha...
Posté par ptit_poulet . Évalué à 2.
Oui si pas de contrôle d'exécution je comprends ton raisonnement.
[^] # Re: ha...
Posté par groumly . Évalué à 3.
UTC, c’est pas fait pour les chiens :)
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ha...
Posté par Moonz . Évalué à 6.
J’aurais plutôt dit ne jamais mettre un serveur en autre chose qu’UTC.
[^] # Re: ha...
Posté par claudex . Évalué à 3.
Vu qu'ils galèrent pour faire des mises à jour, je doutes qu'ils aient une idée du fuseau horaire configuré sur toutes les machines du parc. Donc le conseil ne me semble pas mauvais.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ha...
Posté par Strash . Évalué à 4.
Mais du coup si tu fais la màj à 2h du matin en UTC, ça tombe au milieu de la journée en Asie…
Tu fais comment pour mettre à jour "la nuit là où le serveur est" si tout tes serveurs sont en UTC ?
[^] # Re: ha...
Posté par Moonz . Évalué à 3. Dernière modification le 07 décembre 2021 à 13:21.
Ben tu fais la conversion à la main.
Si la période de downtime pour maintenance acceptable est 2h du matin à Tokyo, tu configures ta MAJ auto à 17h sur ton serveur qui est en UTC.
[^] # Re: ha...
Posté par claudex . Évalué à 3.
Et du coup, tu changes l'heure de mise à jour deux fois par an (pour les pays qui pratiquent le changement d'heure) ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ha...
Posté par Moonz . Évalué à 2. Dernière modification le 07 décembre 2021 à 14:25.
Soit ça, soit tu acceptes que ce sera parfois à 2h et parfois à 3h (locale, toujours 17h UTC) selon la période de l’année. La seconde solution me parait plus adaptée pour des jobs "système" (comme les MAJ auto, les backups, les renouvellement de certificats letsencrypt, les rotations de logs…).
Si ton heure locale est significative (par exemple : envoyer quotidiennement un rapport au département comptabilité), tu peux utiliser systemd pour spécifier explicitement dans quelle timezone s’applique tes services planifiés (
OnCalendar=08:00:00 Asia/Tokyo) tout en gardant ton serveur en UTC. Mais maintenant faut à nouveau faire gaffe au piège "0 ou 2 envois pendant le changement d’heure".[^] # Re: ha...
Posté par ptit_poulet . Évalué à 1.
Du coup on en revient au même qu'au début. Peu importe l'heure utilisée il est important de vérifier qu'une tâche a été exécutée ou non…
[^] # Re: ha...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
En dehors des tâches programmées, il est utile pour d'autres raisons d'avoir la même heure sur tous les serveurs qui peuvent se trouver un peu partout dans le monde…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: ha...
Posté par claudex . Évalué à 5.
Rien qu'avoir des logs coordonnés est une grande aide.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ha...
Posté par Kaane . Évalué à 10.
Je ne connais personne qui arrive à mettre à jour des parcs de plusieurs centaines de serveurs d'une semaine sur l'autre systématiquement. Et ce quelque que soit le niveau d'automatisation que l'on mette en place, les OS concernés ou le niveau de support chez les meilleurs techniciens du marché.
Il y a pas mal d'infrastructure ou en une semaine tu ne peux même pas vraiment valider que les mises à jour ne cassent rien. Et je ne parle même pas des environnements ou il faut re-certifier les machines quand il y a des modifications.
Généralement tu vas tester les mises à jour sur un environnement dédié, valider que tout se passe bien, demander aux utilisateurs/clients/services de vérifier que tout va bien, passer les mises à jour sur les autres serveurs, re-valider que tout s'est bien passé. Rester sur le qui-vive jusqu'à ce que la clôture mensuelle/annuelle et le processus important qui n'est lancé que lorsque que strictement nécessaire se passent bien.
Même si tout est automatisé ET que tout se passe bien faire tout ça en une semaine et être prêt à recommencer la semaine suivante est extrêmement complexe.
Mais tout ne va pas bien se passer. Certaines mises à jour vont arriver avec leur lot de bugs, certains comportement de l'OS ou de la base de données ou des libs sur lesquelles tu t'appuyais vont changer (même subtilement). Un programme que tu compiles pour tes tests d'intégrité va avoir un hash différent. Un calcul va avoir une différence de résultat sur la cinquième décimale. Et du coup la question de "est-ce qu'on passe les mises à jour en prod ?" va se poser très sérieusement.
Et des fois ça va même franchement mal se passer. Tu vas tomber dans le cas à la con que ni MS ni IBM n'ont jamais testé de leur vie et qui va littéralement casser ton système ou effacer/rendre inaccessible une partie de tes données.
Et pendant que tu répares, que tu fais le tri entre les mises à jour que tu peux prendre et celles que tu veux éviter. Que tu escalades ton cas chez MS ou chez Red Hat - d'autres mises à jour hebdomadaires continuent de tomber. Avec bien sur des alertes CVE qui continuent d'arriver pour tes logiciels et de nouvelles menaces/problèmes à prendre en compte sur tes appliances et ton réseau.
Automatiser la mise à jour d'un parc de 800 serveurs, des applis qui tournent dessus et de l'infra qui va autour - ça n'est pas juste une ligne dans le chron que tu dupliques sur toutes tes machines et qui tourne le jeudi entre 2h et 3h du mat après les backups et avant les tests d'intégrité.
[^] # Re: ha...
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 06 décembre 2021 à 13:35.
qui peut dire honnêtement qu'il fait ça sur des MAJ de sécurité (y compris sur les failles majeures sous Linux, pour troller sur le sujet du site; et on parle de MAJ de sécurité, pas d'update de version de distro), quelque soit l'OS?
[^] # Re: ha...
Posté par Kaane . Évalué à 10.
Pour ne parler que de ce que je connais :
- Les gens qui font des logiciels et des machines pour l'assistance lors de chirurgies hépatiques ou cardiaques
- Les gens qui fabriquent des avions et des hélicoptères
- Une partie des gens qui travaillent avec des gens qui fabriquent des avions et des hélicoptères
- Les personnes qui ont foutu 2000 clients dans le noir pendant 48h suite à un crash d'un routeur telecom suite à une mise à jour de sécurité qui a juste pété le multicast IPv6
Mais ceci étant la procédure que je décris n'est pas la procédure exceptionnelle à appliquer sur les systèmes critiques de centrales nucléaires ukrainienne dont le bouclier se fissure, c'est la bonne pratique recommandée, entre autre, par Microsoft.
De la même façon quand on fait des sauvegardes il faut s'assurer qu'elle soit intègres, cohérentes, reproductibles et restaurables. Ce qui demande de faire des tests, d'avoir des serveurs dispo pour faire des restauration ex-nihilo et de pouvoir monter une infra complète juste pour tester.
Ou encore de valider qu'il n'y a pas de point de défaut commun entre les différents serveurs critiques qui sont redondés. Ce qui veut dire pas le même datacenter, pas la même alimentation électrique, pas le même fournisseur pour les liens inter/intranet
Et une fois de plus tout ce que j'évoque ce ne sont pas des procédures extraordinaires pour sociétés en mal de travail à donner à ses admins sys, ce sont les procédures minimales pour garantir que le travail de prévention effectué sert à quelque chose.
Il n'y a rien de plus frustrant que d'avoir des sauvegarde fonctionnelles mais non cohérentes les unes avec les autres - en d'autres termes on peut restaurer la base et le filer, mais les deux ne sont pas au même moment dans le temps et du coup il y a soit des manques soit des erreurs.
Mais je te l'accorde, personne ne fait tout comme il faut, du moins pas avant d'avoir perdu plusieurs millions suite à un problème ou une attaque et d'avoir les moyens de pouvoir survivre à cette perte de plusieurs millions.
En avionique ou en médical c'est différent, il y a des organismes de contrôle qui vérifient en permanence que tu fais tout comme il faut - du coup tout le monde est obligé d'investir des dizaines de milliers d'Euros pour protéger et sécuriser l'environnement. Mais dans les domaines ou ce n'est pas strictement obligatoire, les gens font un peu n'importe quoi, parce que ça coute quand même nettement moins cher (tant qu'il n'y a pas de soucis) et que c'est tout ce qui permet de rester concurrentiel.
Pour finir je dirais que c'est quand même un peu bizarre de reprocher à une société de ne pas avoir fait ce qu'il fallait en ce qui concerne l'application des mises à jour tout en déclarant le post d'après "qui peut se prévaloir de faire ce qu'il faut ce qui concerne l'application des mises à jour ?"
[^] # Re: ha...
Posté par orfenor . Évalué à 3.
Complétion : je sais par l'un des sysadmins que Motorola testait tout dans les années 90.
[^] # Re: ha...
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 5.
Et ce d'autant plus qu'on a l'impression que l'infrastructure s'est construite au fil de l'eau par ajouts successifs.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: ha...
Posté par ptit_poulet . Évalué à 5.
Oui car on parle de 800 serveurs. On a l'impression que c'est la NASA alors qu'ils vendent juste du mobilier de bureau… Je simplifie un peu beaucoup ok, mais quand même !
[^] # Re: ha...
Posté par xulops (site web personnel) . Évalué à 4.
J'ai pertinenté car en effet je trouve bizarre que personne ne trouve ça choquant. Une entreprise de la taille de Manutan qui a besoin de 800 serveurs pour son activité, c'est qu'il y a un gros soucis décisionnel au niveau IT, qu'il y a eu du laissez-aller, qu'on a laissé s'empiler des trucs pour faire plaisir à un service ou à un autre sans vision globale du SI.
Une refonte complète de leur système est à prévoir. Qu'ils embauchent donc un vrai responsable informatique et achètent de l'huile de coude … et au boulot ! Remettre tout à plat est une bonne occasion pour migrer ce qui peut l'être sous Linux.
[^] # Re: ha...
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 9.
Je crois que c'est un peu le problème de beaucoup de boîtes surtout avec les deux idées dominantes "payer des gens pour faire le boulot ça coûte de l'argent" et "faire plus avec moins". Ce n'est probablement pas tant du fait du secteur informatique de la boite, mais décisions de gestionnaires.
Il y a un moment où ça casse…
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: ha...
Posté par xulops (site web personnel) . Évalué à 10. Dernière modification le 06 décembre 2021 à 14:26.
Il y a de ça, et d'autres raisons.
On peut citer la valse des directeurs IT, parce que dans la profession il faut bien avouer qu'il y a beaucoup d'incompétents (je ne parle pas de Manutan que je ne connais pas) qui ne tiennent pas la route et dégagent dès que la pression monte un peu. La succession de "directeurs" qui n'ont aucune vision à long terme de l'IT de l'entreprise débouche souvent sur cet empilement de serveurs car faute de connaissance du SI en place, c'est le fameux "on ne touche pas à l'existant, on ne prend pas le risque de casser le truc, on ajoute un autre serveur à côté".
Il y a également les pros de l'externalisation, ce qui va un peu à l'encontre de ton "payer des gens pour faire le boulot ça coûte de l'argent". En fait ça ne dérange pas forcément les entreprises de cracher au bassinet, tant que c'est pour payer des prestataires, surtout si tu ajoutes à ça la mode des gestions purement comptables des entreprises.
Petit retour d'expérience explicite : j'étais responsable informatique dans une PME (plutôt M que P), et en 5 ans j'ai réinternalisé énormément de services en formant la petit équipe en interne. Au niveau SI, ça s'est traduit par une efficacité spectaculaire qui faisait mieux tourner l'ensemble de l'activité de l'entreprise, tout en divisant le budget annuel par 4. Résultat : quand j'ai demandé que les salaires des gars de l'IT prennent 10% (une portion ridicule du gain sur le budget global IT), refusé: Et les gestionnaires pas contents du tout ! Faut pas faire varier comme ça un budget. Leurs prévisions ne doivent absolument pas être faussées, ni dans un sens ni dans l'autre, donc faut dépenser autant de budget que prévu, et impossible de transférer un pouième de gain d'un budget sur un autre (IT -> remunération). Avec des gestionnaires pareils, pas étonnant que les SI de certaines entreprises soient des usines à gaz, ils ont le SI qu'ils méritent.
[^] # Re: ha...
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 10.
Ah mais, payer des prestataires, dans la logique pourrie actuel, c'est pas comme payer des salariés (qui coûtent cher, parce que les prestataires c'est pas pareil). Il y a le même problème en France avec la fonction publique où l'idée est de payer moins de fonctionnaires ("qui coûtent cher pour rien") mais de payer plus cher pour externaliser (et ne pas forcément avoir un service à la hauteur d'ailleurs), mais passons. Donc oui c'est la même logique.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ha...
Posté par ptit_poulet . Évalué à 3.
Ouai enfin ça sent surtout 1 serveur physique = 1 service.
Pour l'avoir déjà vécu c'est juste horrible et ingérable.
[^] # Re: ha...
Posté par groumly . Évalué à 3.
Ça me parait pas choquant.
Ils font pas loin d’un milliard d’euros de chiffre d’affaire, et ils ont 2500 employés.
A cette échelle, ils ont pas juste un apache/php/mysql. Entre tous les systèmes de productions, les systèmes de support, les outils interne d’analytique, ab test et que sais je encore, Kafka, kibana, graphite, les serveurs de builds, l’intégration continue, toute l’infrastructure it pour gerer 2500 personnes, si en plus tu rajoutes les environnements de dev et de preprod, ça monte vite.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ha...
Posté par claudex . Évalué à 2.
Vu ce qu'ils décrivent, ils n'ont pas trop l'air d'avoir de l'ab test, sinon ils galèreraient moins pour les mises à jours.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ha...
Posté par groumly . Évalué à 0.
Il dit qu’il a plus de genoux.
C’est quoi le rapport?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ha...
Posté par claudex . Évalué à 3.
S'ils avaient une infrasctruture pour faire des tests, ils verraient vite si les mises à jour ont un impact ou pas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ha...
Posté par groumly . Évalué à 1.
Ab test, pas test test.
C’est censé tester l’impact de nouvelles (ou changement de) fonctionnalités sur le business, pas valider l’infrastructure sous jacente.
Y’a des moyens beaucoup plus simple de valider qu’une mise à jour de Windows pete pas le service. Tu déploies un canary, et tu gardes un œil sur tes métriques techniques et tes logs.
Quand il s’agit de mises à jour systèmes, t’as pas toujours l’option de faire ça non plus. Si t’as updaté ton sqlserver, c’est pas garantit que tu puisses le downgrader derrière et que ça continue à marcher.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ha...
Posté par claudex . Évalué à 3.
Ben, s'il n'y a pas d'impact sur le business, c'est que l'infrastructure sous-jacente fonctionne relativement bien.
Oui, mais je doute qu'ils aient 800 sqlserver sur 1200 serveurs (ou autre serveur impossible à downgrader (et encore, le schéma de la db ne devrait pas changer avec des updates de sécurité).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ha...
Posté par groumly . Évalué à 1.
C’est une façon de voir les choses. Tu peux aussi zapper l’analyse statistique, et conclure via tes métriques techniques (success/failure et response times), bien plus vite, sans avoir à te demander si t’as choisi la bonne p-value, si t’as pas un biais de sélection qui influence les résultats et autres joyeusetés qui viennent avec l’analyse d’un ab test.
Dit autrement, tu peux enfoncer un clou avec un tournevis, mais c’est pas forcément le plus adapté.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ha...
Posté par claudex . Évalué à 4.
Ce que je dis depuis le début ce n'est pas qu'il faut utiliser l'AB testing pour qualifier les mises à jour mais que s'ils n'arrivent pas à automatiser les mises à jour sur ces serveurs, il y a peu de chance qu'ils aient l'infrastructure en place pour faire de l'AB testing.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ha...
Posté par groumly . Évalué à 1.
Pourquoi les deux seraient liés? C’est des compétences et champs complètement différents.
Et surtout, y’en a qui sert à mesurer directement l’augmentation de ca, et l’autre qui apparaît surtout comme un coup sans aucun intérêt direct.
C’est comme si je te disait “puisqu’il habite en appartement, il doit pas aimer la glace à la vanille”.
Et d’autre part, non, c’est pas ce que tu dit depuis le début.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ha...
Posté par xulops (site web personnel) . Évalué à 2.
2500 employés, 1200 serveurs, soit quasiment la moitié d'un serveur par personne… moi je trouve ça un peu beaucoup quand même. Mais je sais que c'est une situation assez répandue, hélas.
[^] # Re: ha...
Posté par groumly . Évalué à 2.
La question c’est surtout combien de clients ils ont. La majorité de ces serveurs sont là pour eux, pas les employés. ‘Fin c’est très bizarre comme métrique, surtout qu’on sait pas si ces 800 machines Windows sont des VM ou des serveurs physiques.
C’est dur d’estimer quel genre de traffic ils prennent, mais une autre façon de voir les choses c’est que chaque serveur génère plus de 650k euros de chiffre d’affaire par an.
C’est assez incongru comme métrique aussi, mais vu sous cet angle, ça devient moins stupide.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: ha...
Posté par ff9097 . Évalué à -1.
Ça fait moins de 1800 balles / jour / serveur c'est très faible je trouve
[^] # Re: ha...
Posté par Quinane . Évalué à 10.
En plus de plussoyer.
Nous sommes d'ailleurs dans l'attente d'un correctif d'une faille 0-day de la part de MS (CVE-2021-41379).
MS avait corrigé récemment une faille 0-day. Sauf qu'un chercheur a trouvé que le correctif représentait une autre faille 0-day, plus large.
Donc après avoir passé les MAJ sur les serveurs, il va falloir s'y remettre. Mais ça va, on attend toujours le correctif, depuis près de 15 jours.
Le chercheur en question a publié direct pour protester contre les baisses drastiques du programme bug bounty de MS.
Après PrintNightmare, Solarwinds, Exchange, l'ardoise s'allonge. D'ailleurs quatre associations représentant des grandes entreprises belges, françaises et allemandes ont fait une lettre ouverte réclamant que MS participe aux frais engendrés par leur politique de sécurité calamiteuses. ( NextInpact)
[^] # Re: ha...
Posté par pasBill pasGates . Évalué à 5.
Bonjour,
Ici on update des [je peux pas donner le chiffre mais il y a bcp de zero] de milliers de serveurs, chaque jour.
Il y a tout un concept de pipeline, A/B testing, deploiement par étapes, … et tout est automatisé.
Faut penser à passer au 21ème siècle, la méthode manuelle avec 3 semaines de test pour un serveur c'est has been
[^] # Re: ha...
Posté par Psychofox (Mastodon) . Évalué à 5.
Il faut de toute façon partir du principe qu'un serveur peut tomber à n'importe quel moment, raison pour laquelle le chaos engineering a été inventé.
Il me semble que la durée de vie moyenne d'un container dans l'infra netflix n'excède pas 3h. Dans ces conditions, les noeufs hôtes et hyperviseurs sous-jacents peuvent être drainés et redémarrés à intervalles régulières.
[^] # Re: ha...
Posté par Kaane . Évalué à 6.
La méthode automatique ou il faut 6 jours de calculs pour valider la simulation par éléments finis sur un cluster de 200 serveurs - pour peu qu'un truc se passe mal une fois, elle prend 3 semaines.
Et ça sert pas à grand chose de mettre plus de serveurs pour gagner du temps, le logiciel scale pas vraiment bien au delà de 800/900 cœurs CPU. On est plutôt limité par les I/O à ce niveau.
Après tu peux toujours améliorer le système, rajouter des serveurs, des environnements, des tests, des automates. Mais ça a un coût. Bloquer 1000 serveurs et appliances pour faire tous les tests possibles et imaginables tous les trois jours c'est facile quand on a 100 000 serveurs à disposition. Quand on en a 800 (ou même 1200), c'est nettement plus dur.
Et puis quand tu as un environnement dans lequel tous les process sont utilisés tous les jours plusieurs fois par jour c'est vachement facile de tester. Quand tu es dans un cas ou certains process ne sont même pas utilisé tous les ans (certification finale d'un avion ou accréditation d'un moniteur chirurgical ça se fait pas tous les jours)
Bref l'administration système d'un grand groupe - par exemple Facebook - c'est facile. Même si tu pêtes le BGP et que tu fous tout le réseau dans le noir pendant 12h : ben tu perds 0.1% de ton chiffre d'affaire annuel et après quelques quolibets tu repars sans problèmes autre que quelques ado en mal d'endorphine. Et puis tu as des moyens quasi illimités pour les tests et les achats.
Pour les autres boîtes, des fois c'est plus compliqué.
[^] # Re: ha...
Posté par pasBill pasGates . Évalué à 2.
Mais quand tu as une infrastructure élastique (hum…cloud) ben tu te fous de savoir combien de serveurs tu as, si tu en veux un cela prend 10 secondes plutôt que devoir attendre 3 semaines, et si tu en veux 100 cela prend 10 secondes aussi !
Ensuite il y a le côut, mais quand tu prend en compte le côut pour les équipes de devoir commander des serveurs, attendre qu'ils arrivent et qu'ils soient installés, etc… ben tu commences à comprendre pourquoi plein de bôites s'y mettent.
Alors oui, il y a certains trucs très particuliers qui s'y prettent potentiellement moins, mais pour tout ce qui est infra d'entreprise c'est évident que cela marche, et je suis sûr que tu serveur de calcul, pour vérifier qu'il fonctionne il n'y a pas besoin d'un calcul de 6 semaines, tu peux le tester en bcp moins de temps avec une batterie de tests correcte.
Avec ce modèle, tu te fiches de penser à bloquer des serveurs, tu en as un nombre infini, tu peux les rendre quand tu veux, et tu ne les paies quand quand tu les utilises.
Non vraiment, quand je t'entends, j'ai l'impression d'être de retour dans les années 90 - début 2000.
# Lien
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 10.
On pourra consulter ce lien pour d'autres commentaires sur ce sujet, dont plusieurs jugés plutôt pertinent par le lectorat de Linuxfr.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Merci à Manutan
Posté par tisaac (Mastodon) . Évalué à 10.
Je pense qu'en dehors de critiquer (à juste titre ou pas) leur gestion informatique on peut remercier Manutan de ce partage d'expérience (même partiel). En faisant cela, ils risquent bien plus d'attirer des critiques sur leur gestion que de créer un courant de sympathie. Et pourtant, je suis assez convaincu que c'est en partageant ce qui a merdé (et ils reconnaissent ne pas avoir fait tout parfaitement) qu'on diminue la connerie collective.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Merci à Manutan
Posté par Adrien . Évalué à 5.
Autre partage d'expérience : la ville d'Angers s'est fait plomber par un ransomware, la directrice de communication a fait un retour d'expérience assez intéressant, pas technique mais organisationnel :
https://www.youtube.com/watch?v=B2i-0RyqIYw
[^] # Re: Merci à Manutan
Posté par bobo38 . Évalué à 4.
as-tu un résumé? c'est 1 heure de vidéo ce lien…
[^] # Re: Merci à Manutan
Posté par ptit_poulet . Évalué à 4.
Y a quand même une grosse partie sur "Rubrik" où on te dit que c'est top, ça te sauve la vie…
Je ne connais pas le produit, donc c'est peut-être le cas.
Mais d'un côté je lis Microsoft c'est des pas gentils car de toute façon ils n'arriveront pas à avoir de ristourne à l'année car ils sont trop petits.
Et de l'autre on nous fait une pub d'enfer sur Rubrik, ça sent un peu le placement de produit. Je t'ai sauvé la vie maintenant fais moi de la pub. Ou pire fais moi de la pub et je te sauve la vie.
[^] # Re: Merci à Manutan
Posté par Watchwolf . Évalué à 6.
A voir mais moi je pense aussi que Microsoft les a un peu laissé tombé alors que Rubrik les a soutenu et aidé (ils ont été sauvé par le produit et les équipes).
Alors evidemment ça oriente un peu mais si c'est bien le cas alors ils ont raison de le dire je pense.
[^] # Re: Merci à Manutan
Posté par Psychofox (Mastodon) . Évalué à 7. Dernière modification le 08 décembre 2021 à 17:16.
Je crois que c'est plutôt Manutan qui était naif et qui n'avait aucune idée de ce que couvre le support qu'ils paient.
Ils avaient un contrat de support et ils espéraient avoir le service d'un contrat d'infrastructure sous gestion externalisée. C'est pas vraiment la même chose, et encore moins le même coût.
RedHat ou Cannonical ne les aurait pas plus aidé.
Rubrik fait du logiciel de backup et récupération de données. Ça tombe bien c'est ce qu'ils avaient besoin à ce moment là.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.