Accident du meilleur administrateur système
Je cherche des histoires amusantes d'accidents d'administrateur système que vous avez eus. Suppression du courrier électronique du PDG, formatage du mauvais disque dur, etc.
Je vais ajouter ma propre histoire comme réponse.
Je me suis amusé à découvrir la différence entre la commande linux "killall" (tue tous les processus correspondant au nom spécifié, utile pour arrêter les zombies) et la commande solaris "killall" (tue tous les processus et arrête le système, utile pour arrêter le serveur de production dans au milieu des heures de pointe et faire rire tous vos collègues pendant une semaine).
J'étais en charge de notre proxy web d'entreprise qui était à l'époque le produit de Netscape. En jouant dans les formulaires d'administration (c'était une interface Web), il y avait un gros bouton (et je jure que c'était rouge) qui disait Supprimer la base de données utilisateur. Pas de problème, je pensais. Voyons quelles sont les options que cela me donne quand je touche ça. Il y aura sûrement une invite de confirmation s'il n'y a pas d'options.
Ouais, pas de confirmation. Aucune option. Plus d'utilisateurs.
Alors, je suis allé voir M. Solaris Sysadmin et j'ai dit que j'avais désespérément besoin d'une restauration à partir d'une bande à laquelle il a répondu: "Je ne sauvegarde pas cette boîte."
"Euh, reviens," rétorquai-je.
"Je ne soutiens pas cette boîte. Elle est sur ma liste de choses à ajouter à la rotation de sauvegarde mais je n'y suis pas encore parvenue."
"Ce serveur est en production depuis près de 8 mois!" J'ai crié.
haussement d'épaules , répondit-il. "Désolé."
Il y a plusieurs années, la société pour laquelle je travaillais avait un client qui exécutait une sauvegarde nocturne de leur serveur NT 4.0 sur un lecteur Jaz (comme un disque Zip haute capacité).
Nous avons créé un fichier de commandes, qui s'est déroulé comme un travail planifié pendant la nuit. Chaque matin, ils récupéraient le disque des dernières nuits dans le lecteur, et avant de partir le soir, ils inséraient le disque suivant dans la séquence.
Quoi qu'il en soit, le fichier de commandes ressemblait à ceci (le lecteur Jaz était le lecteur F:) ...
@echo off
F:
deltree /y *.*
xcopy <important files> F:
Quoi qu'il en soit, une nuit, ils ont oublié de mettre le disque. Le changement sur le lecteur F: a échoué (pas de disque dans le lecteur) et le fichier de commandes a continué à s'exécuter. Le répertoire de travail par défaut du fichier de commandes? C :. La première fois que j'ai vu une routine de sauvegarde détruire le serveur qu'elle sauvegardait.
J'ai appris un peu quelque chose sur l'administration système (et la gestion des exceptions) ce jour-là.
Jim.
PS: le correctif? "deltree/y F:\*. *".
root @ dbhost # find/-name core -exec rm -f {} \;
Moi: "Vous ne pouvez pas entrer? OK. Quel est le nom de la base de données?"
Cu: "Core".
Moi: "Oh."
J'adore la façon dont tout le monde qualifie son histoire avec "quand j'étais jeune/vert" comme s'ils ne recommenceraient jamais. Les accidents peuvent arriver même aux pros les plus aguerris.
Mon pire moment est si mauvais que je ressens encore des palpitations ...
Nous avions un SAN avec les données de production à ce sujet. Critique pour la société. Mon "mentor" a décidé d'étendre une partition pour libérer de l'espace disque. Pouvez-vous voir où cela se dirige? Il a dit que le logiciel SAN pourrait le faire en direct, en heures de production et personne ne le remarquerait. Les alarmes auraient dû commencer à sonner, mais étaient visiblement silencieuses. Il a dit qu'il l'avait fait "des tonnes de fois avant "sans problème. Mais voici le problème - il m'a fait cliquer sur le bouton qui dit" êtes-vous sûr? "! Comme j'étais nouveau dans l'entreprise, je supposais que ce type savait de quoi il parlait. Grosse erreur. Le la bonne nouvelle est que le LUN a été étendu.
Je suis content de porter un pantalon marron.
Nous avons dû expliquer pourquoi 1 To de données avait disparu à l'heure du déjeuner. Ce fut une très, très mauvaise journée.
C'est un bon principe en fait - avant de faire quelque chose dont vous avez des doutes, imaginez devoir expliquer à la direction si quelque chose ne va pas. Si vous ne trouvez pas de bonne réponse pour expliquer vos actions, ne le faites pas.
Nagios nous a cinglé un matin lorsque les heures d'ouverture ont commencé à dire qu'il ne pouvait pas se connecter à un serveur non critique. Ok, marchez jusqu'à la salle des serveurs. Il s'agit d'un ancien serveur, un Dell 1650 acheté en 2002, et nous savions que les 1650 avaient des problèmes matériels. Le PFY poignarde le bouton d'alimentation. Rien. Frappez-le à nouveau et maintenez-le pendant cinq secondes pour `` forcer la mise sous tension '' ... ce qui annule la protection contre les erreurs du BMC, car sans DRAC, il n'y a aucun moyen d'examiner les journaux du BMC sans mettre le châssis sous tension.
La machine démarre POST, puis meurt à nouveau. Je me tiens au-dessus et je dis "Je sens la fumée". Nous retirons le serveur sur ses rails, et l'un des blocs d'alimentation est chaud, donc le PFY le tire et est sur le point de refermer la boîte. Je dis: "Non, ce n'est pas de la fumée d'alimentation, c'est de la fumée de la carte mère."
Nous rouvrons le boîtier et recherchons la source de l'odeur de brûlé. Il s'avère qu'une bobine d'inductance et un condensateur ont fait exploser le régulateur de tension sur la carte mère, et ont pulvérisé du cuivre fondu et du gobelet de condensateur sur tout, court-circuitant un tas de choses et faisant essentiellement un gros gâchis.
Le pire pour moi était de reconnaître que j'avais fumé suffisamment de matériel pour reconnaître la différence entre l'odeur d'une carte mère brûlée et une alimentation électrique brûlée.
Il y a trois jours (sérieusement), j'étais connecté à distance à un serveur scolaire, installant le Service Pack 2 sur un serveur de fichiers Windows Server 2008.
J'ai décidé de planifier le redémarrage nécessaire tard dans la nuit, lorsque les enseignants ne seraient pas connectés pour terminer leurs bulletins de fin d'année. J'ai tapé quelque chose comme:
à 23:59 "shutdown -r -t 0"
... qui aurait bien fonctionné.
Mais je me suis ensuite deviné. Ma syntaxe "d'arrêt" était-elle correcte? J'ai essayé d'afficher l'aide à l'utilisation en tapant
arrêt/h
... et a instantanément perdu ma connexion RDP. Paniqué, j'ai frappé Google pour la syntaxe. Une recherche rapide a révélé que la version d'arrêt de Server 2008 comprend un commutateur/h, qui (comme vous l'avez peut-être deviné) met la machine en veille prolongée.
Les enseignants ont commencé à m'appeler en quelques minutes pour me signaler qu'ils ne pouvaient plus ouvrir ou enregistrer les bulletins sur lesquels ils avaient travaillé. Comme j'étais hors site et que la salle des serveurs était verrouillée, j'ai dû appeler directement le directeur de l'école et lui expliquer comment rallumer la machine.
Aujourd'hui, j'ai apporté des biscuits maison à tout le monde comme une excuse.
Dans un emploi précédent, nous avions un excellent système local qui enregistrait et archivait chaque courrier entrant, entrant ou restant dans l'entreprise.
Vous avez fait sauter toute votre boîte aux lettres? Aucun problème! Vous cherchez un morceau de courrier que quelqu'un vous a envoyé il y a une semaine/mois/an mais vous ne vous souvenez pas qui l'a envoyé ou quel était le sujet? Aucun problème! Nous vous livrerons tout à partir de février dans un dossier spécial.
À un moment donné, le PDG de l'entreprise a eu besoin de surveiller le courrier entre un concurrent et un vendeur interne soupçonné. Nous avons donc configuré un script qui a été exécuté tous les soirs et livré le courrier pertinent de la veille au PDG. Aucun problème!
Environ un mois plus tard, la rumeur d'un double problème urgent est venue d'en haut. Il semble que lorsque le PDG lisait la liste des courriers envoyés à $ OTHERCOMPANY, il est tombé sur celui-ci:
To: somebody@$OTHERCOMPANY
From: CEO
Subject: CEO has read your message (subject line here)
Naturellement, le PDG étant une personne importante et tout, il était trop occupé pour cliquer sur toutes ces boîtes de dialogue "Envoyer un accusé de lecture" dans Outlook et avait configuré son client pour tout simplement les envoyer. Un des messages capturés par le filtre de surveillance avait un ensemble de demande de confirmation de lecture. Devinez ce qu'Outlook a fait? Certainement foutu en l'air la surveillance "clandestine".
Notre prochaine tâche: ajouter des règles au filtre de messagerie pour bloquer les reçus de lecture sortants du PDG à cette entreprise. Oui, c'était le moyen le plus simple. :)
Ahhh, le mien était il y a environ 10 ans, quand je me mouillais encore les pieds. J'ai eu la joie d'installer des sauvegardes de batterie sur tous les ordinateurs des programmeurs. Ils voulaient également que le logiciel chargé avertisse d'une panne de courant et s'arrête correctement.
Je l'ai donc installé sur mon ordinateur pour tester tout d'abord bien sûr et m'assurer que tout fonctionnait. Je déconnecte donc le cordon d'alimentation et le message s'affiche sur mon écran. msgstr "alimentation externe perdue, début de l 'arrêt du système".
Alors j'ai pensé: Hé cool, ça a marché. Mais pour une raison étrange, je ne me souviens même pas, il a envoyé ce message sous forme de message réseau afin que les 200+ ordinateurs de l'entreprise reçoivent ce message, où plus de 100 utilisateurs étaient programmeurs.
Ouais, parle de panique de masse !!
J'ai gardé la tête basse à cet endroit pendant un certain temps!
J'utiliserais souvent la commande "sys-unconfig" sur les machines Solaris pour réinitialiser le service de nom de machine, I.P. adresse et mot de passe root. J'étais sur un système d'utilisateurs et je me suis connecté au serveur d'installation du bâtiment et j'ai recherché quelque chose (en tant que root), puis en oubliant que je m'étais connecté à une autre machine (invite "#" non descriptive), j'ai exécuté la commande "sys-unconfig".
# sys-unconfig
WARNING
This program will unconfigure your system. It will cause it
to revert to a "blank" system - it will not have a name or know
about other systems or networks.
This program will also halt the system.
Do you want to continue (y/n) ? y
Connection closed
#
Ce message "connexion fermée" s'est lentement transformé en panique ... à quelle machine étais-je connecté lorsque j'ai exécuté cette commande.
Le pire, ce n'était pas les moments difficiles que mes collègues m'ont donnés, c'est que j'ai fait la même chose un mois plus tard.
J'en ai une assez bonne. Certes, c'était avant mon temps en tant qu'administrateur système, mais toujours lié à la technologie, j'ai donc pensé l'ajouter.
À l'époque, je travaillais en tant que technologie satcom/large bande pour l'USAF. Ayant récemment terminé mes études techniques, je me suis retrouvé en poste en Corée du Sud. Peu de temps après son arrivée en station, une opportunité s'est présentée de voyager dans le sud avec les "gros gars" qui étaient là depuis un certain temps et de travailler sur des équipements du monde réel (c'est-à-dire de la "production").
Je suis descendu avec l'équipage et en tant que jeune technicien passionné, je rongeais le nez, très excité à la perspective de mettre la main sur un véritable équipement qui passait le trafic voix et données militaire LIVE.
Pour me démarrer lentement, ils m'ont remis un manuel, se sont tournés vers la section de maintenance préventive et m'ont pointé en direction de quatre racks remplis de plusieurs grands multiplexeurs numériques. L'équipement était assez facile, nous avions couvert le même équipement dans une école de technologie.
Première page du manuel lue; "Mettez le multiplexeur ditig sous tension. Mettez les deux interrupteurs arrière en position ON et attendez que l'équipement se mette sous tension, puis commencez les tests." J'ai levé les yeux, et il y avait déjà du courant APPLIQUÉ!
J'étais certainement dans un dilemme. Ne sachant pas comment procéder, j'ai tiré de mon mieux, "Ummmm .. Un peu perdu ici", regarde le senior.
Il m'a regardé et a ri, "Non, non, ça va. Vous pouvez ignorer cette partie de la liste de contrôle." Puis, comme il a remarqué l'expression sur mon visage, (puisque nous n'avons jamais appris à l'école, JAMAIS ignorer une partie de la liste de contrôle, et il était certain que la mort et la destruction étaient le cas), il a jeté un regard sérieux sur son visage et dit: "Ignorez SEULEMENT cette partie! Suivez le reste, à la lettre!"
Heureusement, j'ai parcouru les instructions en plusieurs étapes PM, heureux comme une palourde et fier de laisser une technologie aussi basse (quoique intelligente) faire ce travail important.
Quelque part entre la cinquième et la sixième liste de contrôle de maintenance préventive sur ces énormes multiplexeurs, j'ai commencé à remarquer une augmentation du niveau d'activité autour de moi. Les téléphones sonnaient, les gens se déplaçaient rapidement. Des regards bizarres étaient échangés.
Enfin, un groupe de personnes s'est précipité vers moi, dirigé par l'un des techniciens supérieurs qui m'avait fait tomber.
"Hé! Nous voyons d'énormes pannes dans le trafic de données, et nous avons isolé/tracé le chemin du retour vers les racks sur lesquels vous travaillez! Voyez-vous quelque chose de bizarre ..."
(À ce moment-là, il a été interrompu par un autre dépanneur qui avait fait son chemin vers le premier groupe de multiplexeurs sur lequel j'avais effectué les PM.)
"SAINT NOIX! ILS SONT DÉSACTIVÉS! IL LES A ÉTEINT !!!!"
En peu de temps, j'ai regardé pendant qu'ils parcouraient à la hâte la première étape du manuel, "Tournez les deux interrupteurs arrière en position ON ..." Une fois le technicien senior terminé, il est venu vers moi et m'a demandé incrédule à quoi je pensais. de, en éteignant les équipements critiques.
Effrayé par mes esprits, je lui ai remis la liste de contrôle que j'avais suivie, jurant que je n'avais pas du tout dévié. Que je l'avais suivi, "à la lettre" comme il l'avait indiqué.
Au bout d'un moment, il a ri et a indiqué où était le problème.
Dans le manuel, l'étape FINALE de la liste de contrôle de maintenance préventive était:
"Enregistrez la lecture finale de la sonde, essuyez le panneau avant, retirez toute la poussière et les particules, puis tournez les deux interrupteurs d'alimentation arrière en position OFF."
:)
Je rechargeais un système pour quelqu'un, et pendant le processus de sauvegarde manuelle, je lui ai posé la question "Avez-vous d'autres programmes que vous utilisez?" et "Y a-t-il autre chose d'important que vous faites sur l'ordinateur?"
Il a dit "non" PLUSIEURS fois.
J'étais convaincu et formaté le disque.
Environ 30 minutes plus tard, il a dit "oh mon dieu" et a mis les deux mains sur sa tête.
Il s'avère qu'il travaillait sur un scénario de livre depuis plus de 10 ans dans un programme spécialisé. C'était à l'époque où les programmes utilisaient pour enregistrer les données utilisateur dans son répertoire de fichiers de programme et je l'ai raté.
Whhhhooooops.
Il n'était pas en colère contre moi, mais c'était un sentiment de dégrisement.
C'est une sorte d'accident administrateur système ... dans la mesure où les administrateurs système doivent parfois transporter physiquement un grand nombre de machines du point A au point B (où A et B sont apparemment toujours séparés par plusieurs volées d'escaliers dans un bâtiment sans ascenseur). Lors du nième voyage de la journée, je me suis arrêté pour une pause à trois vols du niveau du chargement du sous-sol pour discuter avec quelqu'un qui descendait, calé la tour pleine grandeur avec la station que j'étais en train d'accrocher sur la main courante intérieure de la cage d'escalier ouverte et ... eh bien, vous avez deviné ... légèrement perdu mon emprise sur elle. Il a plongé infailliblement tout droit dans le puits et quand il a atteint le fond, euh ... pas tellement avec la fonctionnalité de celui-là! Total des pièces récupérables: deux bâtons de RAM, un lecteur de disquette et une carte RNIS (que Dieu bénisse les ingénieurs Hermstedt!). Tout le reste craquait, cliquetait ou se brisait en petits morceaux.
Par la grâce de Dieu, personne ne marchait en dessous, ce qui, heureusement pour moi, était le premier de mon patron, alors j'ai dû garder mon travail. Je me suis senti très malade pendant environ une heure.
Morale: la gravité gagne toujours!
Mon préféré n'est pas le mien et j'en suis TRÈS content. Jetez un œil ici.
Cela ne m'est pas arrivé, mais…
Je travaillais dans une entreprise qui fabriquait des logiciels fonctionnant sur des machines Linux fournies par le client. Nous "reprendrions" essentiellement les machines, les configurerions entièrement selon nos spécifications et ferions toute la gestion et la surveillance. Essentiellement, nous étions une équipe de 10 à 15 administrateurs système, gérant des milliers de serveurs pour des centaines de clients. Des erreurs devaient se produire.
Une de nos équipes a trouvé des problèmes sur un serveur (une sauvegarde, je crois) et a décidé qu'il devait exécuter fsck dessus. Il a arrêté tous les services concernés, s'est assuré que des sauvegardes avaient été effectuées récemment sur le système, puis a exécuté le fsck, mais il s'est plaint que le système de fichiers était monté. Étant donné que nous étions à distance et que nous n'avions pas d'accès à distance (DRAC, BIT, etc.), il ne pouvait pas faire le fsck, mais il était presque sûr que c'était sûr de le faire avec le système de fichiers monté, si vous faisiez attention.
Il a décidé de l'essayer lui-même en exécutant fsck sur sa partition racine, avec des résultats prévisibles - il a corrompu sa partition racine et ne pouvait plus démarrer.
Confus, il est allé voir notre chef d'équipe. Le lead a dit qu'il était à peu près sûr que vous ne pouviez pas faire cela, et le membre de l'équipe a dit `` Bien sûr que vous pouvez! '', A pris le clavier du lead et lui a montré que vous pouviez - en exécutant fsck sur la partition racine du lead. Quelle partition racine HIS complètement corrompue.
Résultat final? Aucune donnée client perdue, grâce aux tests des membres de l'équipe. Deux jours de productivité des employés ont été perdus, mais cela valait beaucoup, beaucoup moins que les données sur la machine du client. Et pour mémoire? Vous pouvez exécuter fsck sur un lecteur monté, mais uniquement pour vérifier les données. Pas pour le réparer. C'était l'erreur du membre de l'équipe.
-
Pour ajouter ma propre histoire, je travaillais dans la même entreprise et essayais de réinitialiser un mot de passe utilisateur. Notre système a refusé de me laisser le définir sur le mot de passe dont il avait besoin, car il suivait les anciens hachages de mot de passe et refusait de vous laisser dupliquer le mot de passe. Le mécanisme était simple: il a validé votre mot de passe par rapport au hachage le plus récent de la base de données.
(Et pour mémoire, il devait s'agir de l'ancien mot de passe car il s'agissait d'un compte partagé, et s'assurer que tout le monde savait que le nouveau mot de passe n'était pas pratique)
J'ai décidé de simplement aller dans la base de données des utilisateurs et de supprimer les nouveaux enregistrements afin qu'ils utilisent l'ancien. C'est tout simplement SQL (exécutant une ancienne version de Sybase), donc c'est facile. J'ai d'abord dû trouver les enregistrements:
SELECT * FROM users_passwords WHERE username='someuser';
J'ai trouvé l'ancien dossier qu'il voulait garder; il y en avait deux autres devant. J'ai décidé d'être intelligent et de supprimer tout ce qui est plus récent que l'ancien disque. En regardant l'ensemble de résultats, j'ai vu que l'ancien mot de passe était l'ID # 28 dans la base de données, et les nouveaux étaient l'ID # plusieurs milliers (système très occupé). C'est simple, toutes les anciennes lignes étaient> 28, donc:
DELETE FROM users_passwords WHERE id > 28;
Il n'y a rien de pire que de faire un simple élagage de ligne et de voir "212 500 lignes affectées". Heureusement, nous avions deux serveurs de base de données principaux (avec l'ID utilisateur), mais Sybase (au moins, notre version) ne prenait pas en charge la réplication automatique, donc il n'effaçait pas automatiquement les anciens enregistrements. C'était une question banale d'obtenir un vidage de la table users_passwords et de la réimporter. Pourtant, un assez gros "oh f ** k!" moment.
Tapé kill 1 en tant que root. init et tous ses enfants sont morts. Et tous leurs enfants. etc, etc. Oups.
Ce que je voulais taper était kill %1
Après avoir réalisé ce que j'ai fait, j'ai couru vers le panneau de commande d'une machine de tri de balles de laine GRANDE et j'ai appuyé sur le bouton d'arrêt d'urgence. Cela a empêché la machine de se déchirer, car je venais de tuer le logiciel qui la contrôlait.
Instruction DELETE sans clause WHERE, dans la base de données des clients en direct des clients.
Un autre de mes favoris:
Lors de la configuration d'un ordinateur et d'une imprimante laser locale sur un système, j'ai eu la brillante idée de les connecter tous les deux à l'onduleur de l'ordinateur. Avez-vous déjà essayé d'imprimer sur une imprimante laser locale lorsqu'elle est connectée à un onduleur de bureau? Eh bien, si vous ne savez pas, cela a tendance à tirer tous les amplis ... Ce qui redémarre l'ordinateur ... Et le travail d'impression ne se termine jamais ...!
Obtenez jamais l'appel: 'Chaque fois que j'imprime, il redémarre mon ordinateur et n'imprime pas !!!'?
Oups!
JFV
Nous étions au milieu d'une panne de courant et avons vu que l'onduleur fonctionnait à 112% de sa charge configurée. Ce n'était pas vraiment un problème car nous fonctionnions sur le générateur à l'époque.
Nous avons donc utilisé des câbles d'alimentation de secours pour réduire la consommation d'énergie de cet onduleur (nous en avions deux, un beaucoup plus grand que l'autre). Nous sommes arrivés au commutateur réseau qui dirigeait la salle des serveurs (c'était la salle des serveurs avec tous les serveurs internes de l'entreprise, avec les clients face aux serveurs dans une autre salle des serveurs). Le commutateur était un grand commutateur de classe entreprise avec trois blocs d'alimentation. Les fournitures étaient N + 1, nous n'en avions donc besoin que de deux pour faire fonctionner le commutateur.
Nous avons choisi un câble et l'avons retiré. Malheureusement pour nous, les deux autres ont été branchés sur une seule barrette d'alimentation, qui a rapidement explosé lorsque la charge a augmenté sur les deux alimentations qui y étaient branchées. L'administrateur système a alors paniqué et a branché le troisième câble. L'interrupteur a tenté de se déclencher, mettant toute la charge de l'interrupteur sur l'alimentation unique. Au lieu de couper l'alimentation, il a explosé dans une pluie d'étincelles à 12 pouces de mon visage, me renvoyant dans le rack de serveurs.
Par instinct, j'ai essayé de sauter sur le côté, mais malheureusement, à ma gauche, il y avait un mur et deux à ma droite, un très grand gars des installations de 6 pi 4 po. des racks Compaq (ceux avec les fronts à mailles fines) sans mettre un tout dans le rack, et sans toucher le gars des installations.
À un moment donné de ma carrière, une enquête judiciaire dans l'entreprise pour laquelle je travaillais nous a imposé que tous les e-mails soient conservés "à partir de ce jour", jusqu'à ce que le contraire soit dit. Après environ un an de stockage de sauvegardes complètes quotidiennes de notre environnement d'échange (1 To par nuit), nous avons commencé à manquer d'espace.
Les administrateurs d'échange ont suggéré que nous ne conservions qu'une copie de l'e-mail sur 8. Pour ce faire, nous leur avons demandé de restaurer pendant une journée les bases de données d'échange, d'extraire le courrier électronique dont elles avaient besoin (personnes spécifiques signalées pour enquête) et de le ré-archiver. Ils l'ont fait pour chaque 8ème jour d'email pour toutes nos sauvegardes. Le 8ème jour a été choisi car Exchange avait un ensemble de paramètres où les "éléments supprimés" sont conservés dans la base de données pendant 8 jours.
Après avoir terminé chaque archive, je revenais et supprimais toutes les sauvegardes plus anciennes que celles qu'elles avaient archivées.
TSM ne dispose pas d'un moyen simple pour ce faire, vous devez donc supprimer manuellement les objets de la base de données de sauvegarde.
J'ai écrit un script qui supprimerait toutes les sauvegardes antérieures à une date, au moyen d'un calcul de date utilisant la différence entre aujourd'hui et la date en question. Un jour, j'ai dû supprimer environ un mois de sauvegardes, sauf lorsque j'ai fait le calcul de la date, j'ai fait une faute de frappe et entré la date le 7/10/2007 au lieu du 6/10/2007, et j'ai exécuté le script. J'ai supprimé un mois supplémentaire de données, accidentellement, ce qui faisait partie d'un procès très important.
Après cela, j'ai ajouté quelques étapes au script pour confirmer que vous vouliez supprimer les données et vous montrer ce qu'il allait supprimer ...
Heureusement, ils n'ont même jamais utilisé aucune des données que nous avons travaillé si dur pour préserver, et j'ai toujours mon travail.
Après une longue journée ou le traçage des performances et le réglage d'un gros ordinateur central (vous savez, les bêtes qui prennent quelques heures avant que tous les sites de sauvegarde de secours aient convenu qu'il est en effet redémarré et entièrement synchronisé), j'ai tendu les doigts, tapé un arrêt satisfait -p maintenant dans mon invite portable, fermé le couvercle, tiré le câble série hors du châssis, avec l'anticipation d'un joli verre froid de bière blonde.
Soudain, j'entends le son assourdissant de la rotation de l'unité centrale alors que mon ordinateur portable affichait toujours X avec bonheur.
En attendant que la machine soit à nouveau entièrement en ligne, j'ai décidé que j'avais le temps de faire fonctionner mon ACPI sur mon ordinateur portable, donc je ne serais jamais tenté d'arrêter mon ordinateur portable.
J'ai supprimé le compte de quelqu'un par erreur, j'ai mélangé les noms avec celui que je soupçonnais de supprimer. Opps
Ce qui est cool, c'est qu'ils n'ont jamais su ce qui s'est passé. J'ai reçu l'appel qu'ils n'ont pas pu se connecter, le sou a chuté à propos du compte que j'ai supprimé.
Pendant que je téléphonais avec eux, j'ai rapidement recréé leur compte, y ai attaché leur ancienne boîte aux lettres (heureusement, Exchange ne supprime pas les boîtes aux lettres immédiatement) et l'ai renvoyé à leurs anciens fichiers utilisateur.
Ensuite, je leur ai reproché d'avoir oublié leur mot de passe que je venais de réinitialiser pour eux :)
J'ai accidentellement installé un fichier tar.gz sur ma boîte Gentoo Linux au mauvais endroit et il a laissé des fichiers partout. Cela devait être vers 1999, 19 à l'époque (merci pour les commentaires ci-dessous)
Étant le geek que je suis, j'ai décidé d'essayer de me scénariser hors du travail de parcourir manuellement chaque fichier.
J'ai donc essayé:
tar --list evilevilpackage.tar.gz | xargs rm -rf
Il ne m'a pas fallu longtemps pour remarquer que tar listait également tous les répertoires que le programme utilisait, ceux-ci étaient ''/usr,/var,/etc '' et quelques autres que je ne voulais pas vraiment disparaître.
CTRL-C! CTRL-C! CTRL-C! Trop tard! Tout est parti, réinstallez le temps. Heureusement, la boîte ne contenait rien d'important.
Cet accident ne s'est pas produit ... mais il convient de mentionner:
J'ai été envoyé dans un centre de données très utilisé pour effectuer des tests de bande passante sur un nouveau circuit. Je suis arrivé à la salle de démarcation/IDF, j'ai trouvé une place sur l'un des racks pour mon routeur de test, j'ai établi mes connexions et commencé les tests. Malheureusement, je n'ai absolument pas remarqué que le routeur frontière en production était non seulement exactement sur le rack suivant (presque au même niveau), mais qu'il était également de la même marque et du même modèle que mon routeur de test.
Une fois le test terminé, j'ai commencé à mettre l'interrupteur en position d'arrêt (... imaginez-le au ralenti ...) et, je le jure, juste au moment où j'appliquais une pression, j'ai compris que la toupie que j'étais sur le point éteindre était celui en production. Mon cœur s'est arrêté et j'ai presque ... eh bien, utilisez votre imagination.
J'ai quitté le MDF air pâle et effrayé du centre de données, mais en même temps heureux d'avoir encore un travail!
Dans une petite partie de mon ancienne vie, j'ai administré le serveur de fichiers de l'entreprise, une boîte netware 4:11. Il n'a presque JAMAIS eu besoin d'entrée, mais si c'était le cas, vous avez ouvert une fenêtre de console distante.
Habitué à utiliser DOS tout le temps, quand j'avais fini, je tapais naturellement "Quitter". Pour Netware, "exit" est la commande pour arrêter le système d'exploitation. Heureusement, il ne vous laissera pas éteindre à moins que vous n'ayez d'abord "arrêté" le serveur. Vers le bas "avant de pouvoir quitter"
Me demander combien de fois j'ai 1: tapé "exit" dans la session console et 2: tapé docilement "Down" puis "Exit" pour pouvoir "terminer ce que j'essayais de faire"
Et puis le téléphone commence à sonner .....
LOL
Le dernier endroit où j'ai travaillé, mon collègue avait ses enfants avec lui dans la salle des serveurs (pourquoi? Je n'ai aucune idée!).
Il s'est assuré qu'ils étaient loin des serveurs et a expliqué à son enfant de 5 ans qu'il ne devait toucher AUCUN des serveurs et SURTOUT aucun des interrupteurs d'alimentation.
En fait, il les avait juste à côté de la porte ... (pouvez-vous voir où cela va ...?)
Le garçon ne toucha aucun des boutons d'alimentation du serveur ... Non, ce serait bien trop facile à expliquer. Au lieu de cela, il a frappé le GRAND BOUTON ROUGE qui était près de la porte ... Le bouton qui coupe l'alimentation de la SALLE DE SERVEUR ENTIER !!!
Les lignes téléphoniques ont immédiatement commencé à s'allumer en se demandant pourquoi Exchange, les serveurs de fichiers, etc. n'étaient pas disponibles ... Imaginez-vous essayer d'expliquer CELA au PDG!
-JFV
Une autre histoire qui ne s'est pas produite (ouf):
Nous effectuions quotidiennement des sauvegardes incrémentielles sur un lecteur de bande.
Il nous est arrivé d'écrire une bande contenant des données à expédier à quelqu'un d'autre. Ils ont dit "nous ne pouvons pas lire votre cassette". En fait, nous non plus. Ou n'importe quelle bande en fait.
Nous avons acheté un autre lecteur de bande et avons retenu notre souffle jusqu'à son installation.
Morale de l'histoire. Assurez-vous toujours de tester vos sauvegardes.
J'ai eu une fois un combat avec le logiciel de surveillance APC UPS. Étant une petite entreprise, nous avions quelques onduleurs de petite taille et divers serveurs étaient configurés pour les surveiller. La plupart des serveurs étaient Linux, mais quelques-uns fonctionnaient sous Windows et ils étaient donc ceux utilisés car le logiciel APC est uniquement Windows.
Cependant, le logiciel APC à l'époque était codé en dur pour supposer que l'onduleur avec lequel il parle alimente également le PC! Ce n'était pas le cas pour ce serveur, mais je l'ai découvert trop tard pour lui dire d'arrêter. Malheureusement, le programmeur principal faisait la démonstration du produit de la société à un partenaire - c'était une application Web, fonctionnant sur le même serveur, je ne voulais pas que le logiciel APC s'arrête ...
Je travaille pour un fournisseur de services sans fil en Amérique du Nord et j'avais suivi une formation pour qu'une personne de mon groupe exécute les bons de travail. J'étais resté éveillé les deux premières nuits (nous faisons tout pendant la fenêtre de maintenance), mais il allait bien et a dit qu'il devait l'apprendre par lui-même, alors je l'ai laissé et j'ai laissé mon téléphone portable et mon téléavertisseur. Je me suis connecté et j'ai vérifié la configuration lorsque je me suis levé à 8 heures du matin le lendemain matin.
Le changement était que nous ajoutions un nouveau pool d'adresses IP pour BlackBerrys , le pool que nous ajoutions était d'environ 10000 adresses. Pour ce faire, nous ajoutons des routes sur le routeur qui pointent vers l'adresse du processeur sur une lame qui effectue tout le traitement des appels (essentiellement, cela fonctionne comme un proxy). De plus, nous nous connectons au processeur et configurons le pool IP, et lions le pool IP à utiliser pour nos utilisateurs sans fil. Cependant, pour les tests, nous configurons normalement cela sur un processeur (en fait, démarrez un téléphone et testez toutes les fonctionnalités), puis déplacez simplement la configuration vers le processeur réel sur lequel nous le voulons.
Avance rapide de deux semaines, et je reçois un appel de notre centre de contrôle disant qu'il y a eu beaucoup d'appels concernant des problèmes intermittents de BlackBerry, et les quelques BlackBerry qu'ils ont examinés semblent passer par un pool commun, mais n'étaient pas vraiment sûr de ce qui se passait. Il ne m'a fallu que 5 minutes environ pour réaliser que c'était la nouvelle piscine que mon collègue venait d'ajouter deux semaines auparavant. Il n'a pas non plus fallu longtemps pour voir que le routeur avait deux routes, l'une allant vers le processeur de test et l'autre vers le processeur d'appel approprié. Cela étant, il a oublié de supprimer la route vers le processeur de test et il a remplacé la route appropriée.
Essentiellement, un BlackBerry se connecte au réseau, se connecte au proxy pour obtenir son adresse IP, le proxy lui donne une adresse du pool avec le chemin incorrect, et le BlackBerry essaie de parler au RIM relay, et la réponse serait acheminée vers le proxy de test et ne reviendrait jamais à l'utilisateur, ce qui signifie essentiellement aucune connectivité.
Nous avons eu de la chance, car les BlackBerry ont un comportement qui, s'ils ne peuvent pas contacter le relais, se déconnecte/se reconnecte au réseau, mais certains appareils RIM sont restés sans service pendant plusieurs heures jusqu'à ce qu'ils soient en mesure de passer à un ordinateur qui fonctionne. bassin. J'ai repensé, et quand j'ai revérifié le travail, je n'avais qu'à vérifier la configuration du proxy qui était nouvelle pour ce type, je n'ai jamais vérifié la configuration de routage car ce gars était auparavant avec l'équipe de base et le routage était son truc. Oops!
Je l'ai réparé et l'ai appelé cet après-midi, sa journée se passait bien, mais j'ai commencé par Je suis désolé, mais je suis sur le point de ruiner votre semaine entière. Un an plus tard, l'histoire revient toujours autour des bières.
Trébucher sur un serveur tour coincé derrière un rack et me frapper la tête à l'arrière du routeur Cisco principal en descendant. Révélant ainsi à quel point les cordons d'alimentation étaient lâchement installés dans les blocs d'alimentation à l'avant du Catalyst 65 .
Ouais. Nous avons un casque accroché dans la salle des serveurs maintenant. Avec mon nom dessus.
Je faisais une visite à un nouveau administrateur système d'une application Service Manager. J'ai dit "si jamais vous deviez arrêter ce service, vous cliqueriez sur ce bouton, mais vous ne devriez jamais le faire pendant la journée." Vous ne croiriez jamais à quel point son bouton de souris était sensible!
Deux minutes plus tard, le service avait redémarré et personne ne semblait le remarquer.
Ma tante m'a demandé de réparer leur ordinateur. Ils ont dit qu'il ne démarrerait pas et que c'était comme ça depuis 2 semaines. Je soupçonnais que c'était le BIOS ou le système d'exploitation.
Je me suis assis devant leur ordinateur. Je m'accroupis pour appuyer sur le bouton d'alimentation. Je regarde.
Le BIOS est passé. C'est bon.
Le système d'exploitation a démarré. C'est bon.
J'ai déplacé la souris en pensant qu'il y avait peut-être un problème avec les périphériques d'entrée. Il n'y a eu aucun problème avec les périphériques d'entrée.
J'ai ouvert son traitement de texte. Il courut.
J'imprime teste l'imprimante. Il a imprimé.
À ce stade, je me suis levé et j'ai dit à ma tante (qui me regardait) qu'il n'y avait rien de mal avec l'ordinateur. Elle a affirmé que ce n'était pas comme ça avant de m'asseoir.
Je peux maintenant affirmer à ma famille que je suis tellement bon, que je peux réparer n'importe quel ordinateur simplement en m'asseyant devant lui.
Quand j'ai été embauché comme administrateur système par l'administrateur principal ... dans la première semaine, nous avons reçu un tout nouveau serveur Dell ... Windows Server 2003 ... c'était son petit bébé jusqu'à ce que je sois secrètement appelé dans la salle des serveurs à minuit un samedi soir pour en nettoyer de nombreuses instances de malware car il SURFIT SUR LE WEB avant de se déployer SANS ANTIVIRUS !!!
Le nettoyage des logiciels malveillants est une chose avec laquelle j'ai beaucoup d'expérience, mais comme il s'agit d'un serveur, j'ai fait un formatage et je l'ai réinstallé pour plus de sécurité.
Je ne lui en ai jamais dit un mot. Il savait qu'il avait gâché royalement.
Plus une chose de script personnel qu'une chose d'administration système, mais ...
J'écrivais un script Perl pour agir comme une macro qui récupérerait maintenant les informations de lecture de Banshee et les saisirait caractère par caractère comme événements clavier en utilisant le programme "xte". De cette façon, je pourrais le faire fonctionner dans des programmes sans aucune interaction particulière, ce serait comme je l'ai tapé.
Eh bien, j'ai codé la chose presque parfaitement. J'ai décidé de le tester dans un jeu aléatoire. La touche pour faire apparaître le chat était shift + enter. Maintenant, pour ce faire, je devais le maintenir enfoncé shift, presse enterpuis relâchez shift. Malheureusement, dans ma hâte, j'ai oublié "release shift". J'ai exécuté le script et cela a conduit à l'effet secondaire quelque peu hilarant de ma touche Maj verrouillée. Je me suis dit "pas de problème, je vais juste aller au terminal et taper manuellement la ligne pour libérer shift". Malheureusement, comme tout le monde le sait, Linux est sensible à la casse. Il n'accepterait pas la commande en toutes lettres car je devais la saisir. Je ne pouvais pas "contre-déplacer" ou quelque chose comme ça.
Cela m'a conduit à une chasse au trésor de cinq minutes pour visiter des sites Web et utiliser la souris pour copier + coller des lettres minuscules individuelles dans le terminal pour former la commande dont j'avais besoin pour l'éteindre.
Ce n'est pas un gros problème, mais certainement un matin "Oeuf sur mon visage" il y a environ 10 ans. J'étais en train de parcourir l'ancien inventaire matériel et de réimaginer les disques prêts à être déchargés. En essayant de trouver le moyen le plus efficace de le faire, j'avais construit un CDRom avec une copie de Norton Ghost et l'image à appliquer. Vous avez allumé la machine, et pendant qu'elle POSTait, mettez le CD dans le lecteur. La machine démarrerait à partir du CD et se réinventerait automatiquement. A bien fonctionné.
Le problème est survenu lorsque j'avais fait des copies du CD afin que je puisse faire fonctionner plus de machines en parallèle. J'ai fini de graver le dernier CD, éteint mon ordinateur de bureau et suis rentré chez moi pour la journée. Eh bien, vous pouvez deviner ce qui s'est passé le lendemain matin. Je suis entré, j'ai allumé mon PC et je suis allé faire un café ...
Quand je suis revenu pour une raison quelconque, ma machine était hors du domaine et n'acceptait pas mon mot de passe ...
Je venais de comprendre ce qui s'était passé et j'ai commencé à jurer quand les autres gars sont arrivés pour la journée. Oui, ils ne m'ont pas laissé vivre ça pendant un moment.
À l'époque, quand j'étais très vert, j'avais besoin d'installer un logiciel AV sur les PC de mes utilisateurs, car personne ne semblait l'avoir. J'ai donc passé un peu de temps à comprendre comment faire une installation à distance, plutôt que de fouiller environ 40 ou 50 postes de travail. L'installation à distance a parfaitement fonctionné et tout semblait aller bien, jusqu'à ce que divers responsables soient passés par mon bureau pour se plaindre qu'ils ne pouvaient pas se connecter.
Il s'est avéré que quelques personnes avaient Symantec AV installé sur leurs machines, et cela ne coexistait pas du tout avec le logiciel McAfee que j'utilisais et verrouillerait les machines après une tentative de connexion.
Heureusement, il était possible de désactiver le service à distance si vous arriviez à la machine avant qu'ils ne tentent de se connecter, j'ai donc réussi à obtenir des points pour le réparer au lieu d'avoir à reconstruire tous les PC de gestion supérieurs ...
Fait par l'un de mes employés ... Exemple parfait de la raison pour laquelle vous étiquetez clairement vos serveurs:
Envoyé mon employé au colo pour reconstruire le serveur de base de données MSSQL secondaire (qui ne contenait aucune donnée actuelle). Le primaire était activement utilisé. Vous pouvez probablement prédire le reste de cette histoire ... Une fois sur place, il a redémarré le serveur, a commencé l'installation et reformaté les disques, seulement pour que je l'appelle et lui demande pourquoi le serveur de base de données principal ne répond plus. (doh)
La mienne est arrivée il y a seulement 6 mois. Nous venions de passer à un nouveau serveur pour une application web PHP/MySQL. Depuis que j'ai pu choisir le système d'exploitation, j'ai choisi celui que je connais le mieux/à l'aise: Ubuntu.
Nous avions un certain nombre de scripts de sauvegarde qui seraient exécutés par cron toutes les heures, tous les jours, etc. La transition s'est parfaitement déroulée. Il n'y a eu que 2 minutes environ de temps d'arrêt pendant que j'ai transféré la base de données MySQL de l'ancien serveur vers le nouveau et changé d'adresse IP.
Quelques semaines plus tard cependant, je travaillais dans MySQL sur la ligne de commande et supprimais certains anciens enregistrements de test qui n'étaient plus nécessaires. Depuis que je suis programmeur d'abord, sysadmin ensuite, j'ai pris l'habitude de taper d'abord mon point-virgule (;) puis de taper la commande. Eh bien, alors que j'allais ajouter la clause WHERE à ma requête DELETE, j'ai accidentellement appuyé sur la touche Entrée. ...Oops.
Query OK, 649 rows affected (0.00 sec)
"Ce n'est pas grave," pensai-je. "La sauvegarde horaire vient de se terminer il y a 4 minutes. Il y a peut-être 3 enregistrements perdus en tout. Je suis rapidement allé dans le répertoire de sauvegarde et j'ai restauré. Problème résolu.
... Ensuite, j'ai remarqué l'horodatage de la sauvegarde. Il était âgé de 17 jours. Il n'y avait aucune autre sauvegarde. Je venais de tout effacer dans le système entré moins de 17 jours auparavant.
Il s'avère qu'il y a un bogue dans le démon cron d'Ubuntu qui l'empêche d'exécuter un fichier de script avec un point (.) N'importe où dans le nom. Cela ne soulève pas d'erreur, il n'y a donc aucune preuve d'un problème. Il refuse simplement de l'exécuter. Tous nos scripts de sauvegarde avaient des points dans leurs noms. Ils fonctionnaient parfaitement avant, mais pas maintenant.
Leçons que j'ai apprises:
- Ne placez pas le point-virgule sur la ligne de commande de MySQL tant que vous ne voulez pas réellement exécuter la requête.
- Vérifiez l'horodatage de vos fichiers de sauvegarde avant de les restaurer.
- Testez vos scripts de sauvegarde et assurez-vous qu'ils fonctionnent vraiment .
Il y a plus longtemps que je ne le pensais, j'étais le technicien de l'entreprise et j'ai travaillé avec des consultants pour installer leur application. Le matériel était un DEC VAX et utilisait un serveur de stockage HSC50. Les consultants ont pris une grande partie de la journée avec leur installation, et après leur départ, j'ai décidé de sauvegarder le disque système sur un disque vide à l'aide de l'utilitaire de copie bit à bit du HSC50. Une fois la copie terminée et j'ai essayé de redémarrer, j'ai découvert que j'avais inversé les noms des disques source et cible et que j'avais donc sauvegardé le disque vierge bit à bit sur le disque système.
J'ai pu reconstruire VMS sur le disque système et réinstaller une grande partie de l'application, mais je pense que cela n'a jamais fonctionné aussi bien. Depuis lors, si je faisais une copie/sauvegarde/etc., Je protégerais en écriture le disque source avant de continuer. (Maintenant que les commutateurs de protection en écriture ne sont plus, je regarde la commande avant je frappe Retour.)
J'ai été appelé pour enquêter sur une alerte provenant d'une machine Windows qui indiquait que le système de surveillance n'avait pas de fichier de licence. J'ai ouvert l'invite de commande et j'ai commencé à enquêter sur le problème et j'ai constaté que les commandes de base de Windows n'étaient même pas là.
Un administrateur système qui avait exécuté un script à distance avait écrit un script qui utilisait la commande del pour supprimer un dossier spécifié par une racine et un sous-dossier avec les dossiers spécifiés dans Variables d'environnement. Si les variables d'environnement n'étaient pas définies, il supprimait silencieusement toute la partition.
Lorsqu'on lui a dit, l'administrateur système était tellement surpris qu'il a confirmé l'action en exécutant ledit script sur son propre ordinateur portable, le jetant ainsi également.
La chose étonnante était que Windows fonctionnait bien, jusqu'à ce que nous redémarrions le serveur. Seul le logiciel de surveillance avare s'est plaint.
Il s'agissait du serveur Active Directory secondaire d'un parti politique. Oops.
Ajout d'une règle de contournement à un pare-feu afin d'accélérer certains téléchargements BitTorrent. Il s'avère que le système utilisé par la règle de contournement n'était pas trop stable et il a supprimé le pare-feu. Il s'agissait d'un pare-feu frontalier pour la connexion Internet de chaque école de la ville. Pour aggraver les choses, le redémarrage était juste suffisant pour faire mourir le disque dur du pare-feu. Amusant? Pas tellement. Échec spectaculaire? Absolument.
Le mien était un effort d'équipe.
La direction m'a demandé de connecter l'un de nos DBA à un serveur afin qu'il puisse faire une sorte de nettoyage. Il a lancé sa requête et immédiatement nos deux téléavertisseurs se sont déclenchés, ce qui a provoqué des explications de nous deux.
En fin de compte, le nettoyage était en fait une goutte de la base de données et devait être effectué sur l'un des serveurs de développement. Cependant, les instructions que j'ai reçues m'ont amené à croire qu'il s'agissait d'une tâche de nettoyage mineure qui devait se produire en production.
Heureusement, nous avons pu restaurer à partir d'une sauvegarde avec une perte de données minimale.
Leçon apprise: assurez-vous TOUJOURS de savoir exactement ce que vous êtes censé faire lorsque vous jouez avec des serveurs de production. S'il y a de l'incertitude, il vaut mieux que vous obteniez la clairification.
D'accord. Obtenir & sur un clavier américain, appuyez sur Maj-7. Pour l'obtenir sur un clavier suédois, appuyez sur Maj-6. Alors, qu'obtenez-vous lorsque vous appuyez sur Shift-7 sur un clavier suédois? Vous obtenez /.
Il y a des années, les dispositions suédoises n'étaient pas si courantes. Ma préférence personnelle était d'utiliser la disposition américaine. Un jour, j'ai voulu supprimer un tas de fichiers et de sous-répertoires dans un répertoire.
Je frappe:
rm -fr *
Mais c'était trop lent, alors j'ai rapidement frappé:
Ctrl-C rm -fr * &
Ou bien? Et bien non. Il m'a fallu quelques secondes pour réaliser que j'étais sur un clavier suédois. Voir ci-dessus pour décoder ce qui s'est passé. Et ce désastre était un fait.
Ce fut le jour où j'ai appris la commande:
dd
J'ai finalement réussi à passer du disque à la bande, mais cela a pris toute la nuit. Le lendemain, j'ai appris que le système était sur le point d'être réinstallé de toute façon.
J'ai eu de la chance, mais j'ai appris quelques choses.
Lorsque la majeure partie du parc de serveurs était encore Windows NT, la principale méthode distante utilisée était pcAnywhere. Nous avions un bug "bien connu", qui parfois les serveurs redémarraient soudainement lors de l'utilisation de pcAnywhere, et les utilisateurs finaux étaient informés de ce bug bien connu.
Le bug était que pcAnywhere (au moins quelle que soit la version que nous utilisions) avait un bouton "redémarrer l'hôte" à côté du bouton "déconnecter de l'hôte". Donc de temps en temps ...: D
VNC dans un serveur Win 2k à 200 miles de là, est allé ajouter une adresse IP, alors ... faites un clic droit sur l'icône réseau dans la barre d'état système, cliquez sur "Désactiver" et non sur "Propriétés" - DOH! .... Solution .... Montez en voiture. Pas heureux! Si seulement ils avaient un 'êtes-vous sûr' sur cette option de menu!
Mike
Été 2002.
J'ai déployé par inadvertance IE 6.0 avec un redémarrage forcé à 16 000 utilisateurs en milieu de journée.
En vérité j'ai rattrapé mon erreur et j'ai tapé le plus rapide de tous les temps arrêt odadmin tout (Commande Tivoli pour arrêter tous les serveurs de déploiement).
Sous Linux et FreeBSD hostname -s affichera le nom d'hôte court. Il s'agit du nom d'hôte coupé au premier point.
Sous Solaris 9, hostname -s définira le nom d'hôte sur "-s".
Mon collègue a donc exécuté un script pour auditer l'ensemble de nos 120 systèmes, y compris 10 serveurs de base de données Oracle Mission Critical fonctionnant sur Solaris 9.
for Host in `cat all-hosts`; do
ssh $Host "hostname -s"
done
Tous nos serveurs Oracle ont échoué instantanément. La vitesse de cet échec était vraiment assez incroyable, il nous a fallu environ 20 secondes pour nous remettre de cette erreur, mais il était déjà trop tard. Tout était en panne.
L'ironie est que notre centre de données a souffert d'une panne de courant majeure quelques jours plus tôt, et nous avons mis à jour notre feuille de calcul "power down/power up" pour assurer une récupération plus rapide en cas de panne de courant future.
Pas moi, mais quelqu'un avec qui je travaille. Ils ont créé une stratégie sur le serveur AV qui contenait un * dans le champ de processus. En termes simples: n'autorisez pas la lecture, l'écriture et l'exécution à tout processus contenant le nom *.
Cette stratégie a ensuite été répliquée sur 1 500 serveurs, qui à leur tour ont arrêté RDP et tout autre processus. Le réparer signifiait monter chaque disque dur du serveur un par un et supprimer la politique. 48 heures avec une équipe de 15 personnes.
Je suis programmeur, donc toutes mes erreurs appartiennent à Stack Overflow. Cependant, voici quelques-unes des erreurs d'administrateur système dont j'ai été témoin.
Révoquer les autorisations d'ouverture de session de TOUS les utilisateurs d'un domaine Windows NT. (À part l'administrateur intégré sur le PDC, malheureusement, seul l'entrepreneur qui a configuré le domaine connaissait le mot de passe, et ils étaient partis depuis longtemps) Je ne sais pas vraiment comment cela a été réalisé. Je sais que j'ai pu m'asseoir et discuter avec mes collègues développeurs pendant quelques heures.
Supprimez accidentellement les serveurs membres OU . C'était encore quelques heures à bavarder pendant une restauration à partir de la bande.
Notre administrateur avait l'intention de donner à tous les administrateurs de domaine l'autorisation d'utiliser l'accès au lecteur de CD et de disquette. (À l'époque, nous utilisions SecureNT pour contrôler l'accès aux supports amovibles.) Malheureusement, il a récupéré l'appartenance au groupe et a accordé à tous les utilisateurs de supports amovibles des droits d'administrateur de domaine complets. J'ai trouvé cela parce que certaines tables étaient apparues dans une base de données SQL de production qui avait été créée par un utilisateur qui n'aurait pas dû pouvoir. Quand j'ai dit à l'administrateur en question que j'aimais voir son visage changer de, non, c'est le bon chemin, jusqu'à, oh ****. Heureusement, aucun dommage grave n'a été causé.
Ha, mon premier très gros accident a été quand j'écrivais un petit panneau d'administration SVN sur notre serveur de développement, un logiciel complètement non sécurisé qui ne devait être utilisé que pour la mise à jour du site Web interne "Développement".
Parfois, le dépôt SVN était corrompu, j'avais donc écrit un bouton qui appellerait un fichier PHP, qui nettoierait tout le répertoire SVN demandé et ressemblait à quelque chose comme ça ..
<?php
$directory=$_GET['dir'];
$result = Shell_exec("Sudo rm -Rvf /".$direcory);
echo $result;
?>
Pour ceux qui ne le voient pas - le "répertoire $" que j'ai mal orthographié dans Shell_exec, provoquant l'exécution du système "Sudo rm -Rvf /" .... Au début, je pensais que la page Web prenait juste son temps à supprimer tous les fichiers du référentiel. Après environ 10-15 minutes, j'avais découvert que j'avais détruit plus de la moitié du système de fichiers.
Oops.
L'histoire d'un ancien employeur, c'est super. Certains détails ont été modifiés pour protéger les innocents. J'avais un problème d'employé, appelez-le Fred, qui avait eu beaucoup de problèmes de productivité, mais semblait s'être racheté et avait récupéré quelques privilèges. Le seul problème était que, lorsque ses privilèges ont été restaurés, un bogue dans un script d'approvisionnement lui a donné des privilèges supplémentaires.
J'étais au milieu d'un grand projet, j'ai donc demandé à Fred de créer un correctif Windows nécessaire pour une application. (C'était à l'époque pré-blaster lorsque les gens ne patchaient pas aussi religieusement qu'aujourd'hui). Fred effectue donc un test dans notre laboratoire et tout fonctionne bien.
Fred pose ensuite quelques questions:
"Who should I Push it to?" (Mind you, this is a patch for some custom VB app)
"Everyone", I respond
"Ok, what time should it start?"
"How about 2AM?", I answer. (Figuring I'd have time to look over everything before I left for the day!)
Que se passe-t-il ensuite? Il configure un travail avec notre application de distribution de logiciels pour pousser tout le monde et est même assez aimable pour cocher les cases de chaque plate-forme prise en charge par le produit. Ensuite, définit l'heure de début pour 2 heures du matin, comme dans le 2 heures du matin qui a eu lieu environ 12 heures dans le passé.
Le résultat? Tout redémarre et essaie d'installer un correctif d'exécution VB5. Vers 14h45 PM un vendredi après-midi. Tout.
Tout? Comme 40 000 PC? Oui. 3000 serveurs Windows? Oui. Boîtes 300 HP, Sun et IBM Unix? Oui. Un cluster AS/400? Oui.
La seule chose qui n'a pas redémarré était les contrôleurs de domaine Windows, parce que les gars AD ont désactivé notre application pour une raison quelconque. Saint cauchemar. Après une semaine de ratissage, je ne pouvais pas croire que j'étais toujours employée.
La punchline? Fred a obtenu une énorme promotion dans un emploi où il ne pouvait plus rien faire de mal.
Peut-être plus d'un pet cérébral tard le soir qu'autre chose.
L'un des développeurs rencontrait des problèmes pour exécuter un profileur Java sur une boîte Solaris. Le profileur se plaignait de l'existence de deux copies de Libc; une dans /lib et un sur /usr/lib. Donc, après quelques lds, nous avons déplacé celui de /lib car tout indiquait /usr/lib, ou alors ils ont dit.
Mais soudain, rien n'a fonctionné. Non ls, pas cd, pas cp ou mv. Après environ 20 minutes de "oh merde, oh merde", nous avons compris que l'un des développeurs avait une copie en cours d'exécution d'Emacs sur cette boîte et nous avons pu ouvrir la sauvegarde /lib copie de Libc et réécrire avec le nom d'origine. Et le tour est joué! Tout fonctionnait. Leçon apprise; laissez Libc où il veut être et ne modifiez pas les demandes des développeurs à 2 heures du matin!
J'en avais un il n'y a pas si longtemps. Au cours de certains déploiements de ponts Oracle ODBC bridge, j'ai dû modifier le chemin d'accès sur environ 500 messages d'utilisateurs.
C'est une opération assez simple, vraiment. Dommage que j'aie oublié ces citations. Les gens ont commencé à sonner après avoir reçu des messages étranges (le ODBC)) et ont semblé penser que le redémarrage de la machine serait juste ce qu'il fallait.
Bien sûr, une autre installation précédente A PRÉPENDU (!!!) un chemin de fichiers programme dans la variable système (avec des espaces et tout, sans guillemets), donc le nouveau chemin s'est arrêté juste là, à c:\Program (bien sûr, l'existence de% ProgramFiles% est resté complètement ignoré). Pas de système, pas de system32, pas de Shell. Donc pas de scripts de connexion non plus.
Les personnes qui avaient redémarré n'avaient plus accès au réseau et aucun script automatisé ne pouvait réparer les dégâts. Bien sûr, dès que je suis allé voir un utilisateur qui se plaignait, que j'ai regardé autour de moi et vérifié le chemin, j'ai eu ce sentiment.
En environ 30 minutes, j'avais un autre script, avec les valeurs de chemin les plus standard, prêt à être envoyé à tout le monde (le courrier électronique fonctionnait toujours). Les utilisateurs ont même rappelé pour être sûr que le correctif était réel, car ils ne sont pas utilisés pour envoyer des fichiers cryptés avec d'étranges raisons de les appliquer, et la plupart d'entre eux n'étaient même pas au courant de ce qui se passait.
La première version était désordonnée (un nouveau point-virgule à chaque exécution), mais elle enregistrait toutes les valeurs de chemin possibles disponibles, donc j'avais rapidement des données avec des chemins possibles, donc je devais juste créer quelque chose d'intelligent pour les vérifier toutes, et obtenir le chemin bien en place.
Dans l'ensemble, cela n'a duré que 45 minutes environ, et c'est moi qui, par chance, avons tout remis en ordre. Mais quand même, quand un chemin corrompu apparaît maintenant, je suis toujours prêt à prendre le blâme;)
Mon meilleur est venu à un moment où notre serveur de sauvegarde était dans les limbes administratives - mon patron "discutait" s'il devait rester au bureau, hors site depuis notre salle de serveurs (et ne pas faire de sauvegarde pour une raison quelconque) ou si il doit être installé dans la salle des serveurs pour économiser des quantités massives de bande passante. Il me semble que cet état de limbes existe depuis plusieurs mois.
Notre serveur Web avait une matrice RAID 5 pour le stockage des sites Web. Il semble qu'il fonctionnait en mode dégradé (sans m'en informer pour des raisons inconnues ou dont je ne me souviens pas) depuis un certain temps avant que le deuxième des trois disques ne tombe en panne. Je dois tirer une nuit blanche pour remonter le serveur. Nos clients n'étaient pas satisfaits de la disparition de leurs sites Web et devaient restaurer à partir de leurs propres sauvegardes. Surtout ceux qui n'avaient pas leurs propres sauvegardes.
Les questions que mon patron m'a posées étaient: "Comment une matrice RAID pourrait-elle échouer comme ça? Je pensais qu'ils n'étaient pas censés le faire!" et "Pourquoi n'avons-nous pas eu de sauvegardes de notre serveur Web?"
Cependant, la leçon n'est pas restée lettre morte. Mon patron a coopéré lorsque j'ai suggéré que les mises à niveau de notre serveur de messagerie incluent une matrice RAID 1 avec un disque de secours (au lieu de discuter avec moi du coût supplémentaire, ce qu'il aurait normalement dû faire). Et bien sûr, le serveur de sauvegarde faisait son travail correctement en peu de temps.
Que diriez-vous d'apprendre la différence entre Exchange Server 2007 "Supprimer la boîte aux lettres" et "Désactiver la boîte aux lettres"? Surtout quand je supprime l'ancienne boîte aux lettres de tout le monde pour traiter une base de données corrompue?
...
Restaurer sur un serveur d'échange ... pas amusant ... Avoir à restaurer un serveur d'échange ET Active Directory ... double pas amusant.
Le faire à 11h00 vendredi matin ... Inestimable.
J'essayais de libérer de l'espace sur la partition principale du serveur Web RedHat 5 du site. J'étais relativement nouveau sur Linux mais j'utilisais DOS depuis des lustres.
J'ai réussi à déplacer l'intégralité du dossier/bin vers une autre partition, en supprimant le site Web de production et en me laissant sans aucune commande système accessible. J'ai paniqué, je ne pouvais pas renommer, copier, déplacer, rien parce que j'avais déplacé tous ces exécutables utiles.
Heureusement, j'ai pu utiliser un disque de démarrage et annuler mon travail.
J'étais nouveau sur RAID 5 et j'apprenais toujours comment cela fonctionnait. À l'époque, j'étais le seul informaticien dans une très petite entreprise. Tous les fichiers auxquels tout le monde a accédé ont été stockés sur un seul serveur. Le serveur commençait à manquer d'espace et n'avait que 3 disques dans la matrice RAID, j'ai donc pensé que l'ajout d'un 4ème augmenterait l'espace et la réactivité. Je l'ai fait pendant les heures d'ouverture. Je n'avais pas appris le concept de la maintenance après les heures normales.
La baie de disques a commencé à se reconstruire, et elle a dit que cela serait fait dans 36 heures. Je pensais que c'était beaucoup trop long. J'ai trouvé un curseur qui contrôlait la priorité de reconstruction, et il était réglé sur le paramètre le plus bas. Je l'ai réglé sur moyen. Le temps est passé à 8 heures. Les voyants du disque dur clignotaient un peu plus rapidement, mais je pensais toujours que c'était encore trop long pour seulement 80 Go de données. J'ai donc défini la priorité sur élevé. Les voyants du disque dur se sont allumés et je me suis dit "c'est plus comme ça!" L'interface graphique que j'utilisais a alors cessé de répondre. Il s'est connecté à distance à la boîte. J'ai essayé de le récupérer, mais il n'a pas pu trouver le serveur.
J'ai commencé à entendre des gens dans le couloir se plaindre qu'ils ne pouvaient pas monter sur le serveur. Je suis allé sur le serveur pour me connecter pour voir ce qui se passait. Il a fallu 5 minutes pour que l'écran vide passe à l'arrière-plan. Il a fallu encore 5 minutes avant que l'invite de connexion s'affiche. Chaque pression sur une touche a pris 5 minutes pour s'enregistrer. J'avais fixé la priorité si haut que le serveur ne répondrait à rien. Il a fallu 2 heures pour que la baie se reconstruise. Heureusement, c'était une heure avant le déjeuner, donc personne ne s'en souciait vraiment. Mon manager à l'époque était une femme vraiment cool et a dit que ce n'était pas grave. L'ingénieur en chef de la conception m'a cependant donné un regard méchant. Je transpirais des balles pendant 2 heures. Leçon apprise.
Un employé s'est plaint que son ordinateur portable était lent, j'ai donc vérifié la fragmentation du disque dur et c'était (et c'est à ce jour) le pire que j'aie jamais vu. Les tentatives de défragmentation du disque ont été infructueuses car il n'y avait pas assez d'espace libre. J'ai essayé de nettoyer les fichiers temporaires (je ne sais pas pourquoi je n'ai pas simplement déplacé des choses vers le serveur temporairement) et j'ai stupidement supprimé son Outlook.pst en pensant que c'était une sauvegarde de son e-mail et non de son e-mail réel. Il m'a pardonné, mais ne m'a jamais laissé l'oublier.
(Cela s'est produit il y a de nombreuses années peu de temps après avoir obtenu mon diplôme universitaire. Je suis beaucoup plus compétent maintenant.)
Erreur très stupide. J'écrivais un script sur mon poste de travail Linux qui traitait un certain nombre de fichiers, mais peu importait le type de fichiers qu'il s'agissait, tant qu'il y avait beaucoup de fichiers. J'ai donc décidé que c'était une bonne idée de copier /etc dans un répertoire dans lequel je faisais mes tests. Lorsque les choses tournaient mal, j'ai supprimé la copie et copié /etc à nouveau dans mon répertoire de test. Cela s'est bien passé pendant un certain temps, puis j'ai tapé
rm -rf /etc
au lieu de
rm -rf etc/
OK, rien à craindre, je pouvais encore faire des choses sur mon poste de travail et pensais que je pouvais le faire revivre en le copiant à partir d'un autre poste de travail, ou quelque chose. Ou réinstallez à la fin de la journée. Tout d'abord, prenez quelque chose à boire et, en raison de la politique de l'entreprise, j'ai verrouillé mon écran. Merde, j'ai besoin de mon mot de passe pour déverrouiller et c'est dans/etc/.....
Erreurs stupides:
- faire trop de racine (j'avais une bonne raison pour ça O :)).
- taper
/etcau lieu deetc/ - en utilisant
/etcà des fins de test
Il y avait le temps où j'ai accidentellement supprimé l'utilisateur "bin" sur une boîte Unix. Bien sûr, la suppression d'un utilisateur entraîne également la suppression de son répertoire personnel.
Pouvez-vous deviner quel est le répertoire personnel de bin?
/poubelle
Il y a quelques sociétés, nous avions une boîte Windows NT 4 comme serveur principal exécutant tout, en tant que sauvegarde, elle avait un disque dur en miroir.
J'ai accidentellement supprimé quelques fichiers importants, pas de problème, redémarrez la boîte, sélectionnez le disque 2 dans le menu SCSI et nous sauvegardons et exécutons la copie en moins d'une minute.
Ensuite, j'ai lancé la commande pour reconstruire le lecteur miroir. Il s'avère que bien que Windows ait maintenant de nouveaux lecteurs C: et D: le logiciel de mise en miroir intelligent n'allait pas être dupe de cela. Il a utilisé les numéros d'identification SCSI pour la source et la cible, et a copieusement copié 1-> 2.
Merci Adaptec!
Fin de semaine, tout le monde presque sorti du bâtiment, je vais dans la salle des serveurs pour charger de nouvelles bandes dans la librairie, pour la sauvegarde complète du week-end. L'AC est trop froid je pense, et éteignez-le (la salle des serveurs était juste une pièce avec un AC mural - pas de fonds pour quoi que ce soit de grave). Je charge donc les bandes, m'assure que le TBU lit les codes-barres OK et je sors.
Le lendemain, je me réveille le matin, avec une gueule de bois (hé, c'est le week-end!), Regarde mon téléphone et vois un tas de SMS messages "$ server down down". Puis un autre "UPS principal en panne".
J'attrape les clés, me dirige vers les bureaux et ouvre la salle des serveurs, pour trouver qu'il fait environ 60 degrés là-dedans, et que tout l'équipement est éteint.
J'ai fini par faire glisser quelques ventilateurs pour chasser l'air chaud, avant même que je puisse commencer le fonctionnement de la climatisation, sans parler de l'onduleur et des 40 serveurs et équipements de communication. Et passer le week-end au bureau bien sûr. Et remercier toutes les divinités pour les unités UPS intelligentes qui peuvent tout tirer vers le bas si la température ambiante est trop élevée. Je garde toujours un sweat à capuche depuis et je ne coupe jamais le courant alternatif
Il y a dix ans et plus, je travaillais sur un projet qui nécessitait un proxy SOCKS. J'utilisais un programme appelé WinGate qui, en plus du proxy SOCKS, offrait une jolie fonctionnalité de passerelle Internet avec NAT, DHCP et quelques autres subtilités. C'était avant que Windows ne partage la connexion Internet. WinGate vous a donc permis de partager votre modem d'accès à distance avec votre réseau Ethernet.
J'ai installé le logiciel et commencé à travailler sur la fonctionnalité client SOCKS. Plus tard dans la journée, nous avons perdu la connectivité Internet. Tout d'un coup, elle s'est arrêtée et personne n'a pu accéder à l'extérieur de l'entreprise. Nous avons appelé notre FAI et tout allait bien sur la connexion. Le routeur fonctionnait bien. Nous ne pouvions tout simplement pas comprendre ce qui n'allait pas. Je suis intervenu à un moment donné car j'avais une certaine connaissance de TCP/IP, mais je n'ai fait aucun progrès.
Le lendemain, notre informaticien a découvert que le serveur DHCP avait donné l'adresse du routeur à la machine de quelqu'un, et que tout le monde l'utilisait pour la passerelle par défaut qui n'allait nulle part. Plus tard dans la journée, notre informaticien est venu dans mon bureau et j'ai demandé: "Alors, avez-vous déterminé qui a donné la mauvaise adresse IP?" Il a dit: "Ouais, c'est toi!"
WinGate avait par défaut exécuté un serveur DHCP et avait donné l'adresse du routeur au premier client dont l'adresse précédente avait expiré. J'étais plutôt roux pendant un moment.
Au début, quand j'étais jeune, j'essayais d'être "utile" et j'ai essayé de copier 250 Mo de données sur une ligne à 128 kbit/s sur 86 sites différents en même temps ... pendant les heures d'ouverture. Pendant que je faisais cela, j'ai entendu des gens demander pourquoi tout prenait autant de temps.
Inutile de dire que j'ai tué les transferts et (heureusement) personne ne savait que c'était moi!
Nous avons construit des systèmes IVR clé en main pour les clients sur des boîtiers Unix. Une fois, les développeurs avaient tout leur code dans/devel. Ils m'ont demandé de retirer les répertoires de développement et la boîte et de ramener les serveurs à l'aéroport un dimanche après-midi (mon jour de congé!). Dans ma hâte, j'ai supprimé/dev/*. Immédiatement vu mon erreur, s'est assis et a réfléchi pendant une minute. Je ne sais pas si le système mourrait si le noyau n'avait pas de hook sur les périphériques système, j'ai donc regardé le répertoire/dev sur une machine identique et pour que mknod [c | b] majeur mineur restaure le clavier, tty, lecteurs scsi, fd0 et null ont ensuite créé une disquette sur l'autre machine/dev et l'ont montée et copiée localement pour obtenir le reste.
Je ne sais toujours pas ce qui se serait passé si j'avais laissé les choses tranquilles, mais je suis sûr que cela aurait été malheureux au redémarrage :)
Leçon apprise - le répertoire de développement ne doit pas être appelé/devel.
Cela s'est produit lorsque je venais de commencer mon premier travail de support hors de uni, j'ai été connecté au serveur 2003 d'un client essayant d'accéder à l'une des machines de l'utilisateur après qu'il se soit plaint de problèmes de connectivité.
Je lui ai parlé d'un dépannage de base et j'ai remarqué qu'elle avait une adresse IP statique, alors j'ai commencé à lui parler en définissant cela sur DHCP. J'ai ouvert les propriétés de la connexion LAN sur le serveur à utiliser pendant que je lui expliquais quoi faire. Après l'avoir fait essayer de le remettre à DHCP, il avait toujours une adresse IP statique, lui a donc demandé de désactiver la connexion et de la réactiver.
Maintenant, à ce stade, je faisais tout ce que je lui disais sur le serveur sans modifier réellement les paramètres, jusqu'au moment où je lui ai demandé de cliquer avec le bouton droit sur la connexion LAN et de désactiver, ce que j'ai ensuite fait.
Ça m'a pris peut-être une demi-seconde pour réaliser ce que je venais de faire.
Il a fallu peut-être 10 minutes pour que les autres ingénieurs cessent de se moquer de moi avant que l'un d'eux n'ait à conduire pendant une heure pour réactiver le NIC sur le site du client).
J'avais l'habitude de m'occuper d'un tas de serveurs de bases de données, chacun avec un cycle de développement et de test bien défini. Notre rôle était de transposer les modifications fournies par les développeurs, en utilisant leur documentation de leur environnement de test dans l'environnement de test du client pour les tests client avant de les mettre en ligne. Dans ce cadre, l'environnement de test client a été créé à partir de la sauvegarde la plus récente de l'environnement en direct.
Tout cela a été soigneusement documenté, ainsi que le processus de déploiement de la modification dans l'environnement réel après que le client a approuvé la modification.
Nous avons pris un nouveau départ dans notre équipe et après qu'il était avec nous depuis quelques mois, nous l'avons laissé s'asseoir sur un certain nombre de cycles de changement jusqu'à ce qu'une nuit fatidique nous le laissions le faire lui-même. Les tests clients se sont bien déroulés et le client a accepté le changement avec plaisir.
Le nouveau départ a ensuite fait exactement ce qu'il avait fait chaque fois qu'il avait introduit la modification dans l'environnement de test, confiant qu'il n'avait pas besoin de suivre la documentation que le reste d'entre nous faisait. Étape (1), reconstruire à partir de la sauvegarde précédente ...
Le lendemain matin, le client a remarqué que le travail de la veille manquait et il ne nous a pas fallu longtemps pour découvrir ce qui s'était passé. Heureusement, les bases de données avaient activé la journalisation des modifications, nous avons donc pu récupérer toute l'activité. Le nouveau départ a au moins appris à valoriser la documentation et à la suivre à l'avenir.
J'en ai eu une bonne nouvelle la semaine dernière.
J'ai demandé à un de mes gars de créer un serveur DNS temporaire pour une plate-forme de test que nous construisons, j'ai demandé à nos gars DNS de mettre à jour un domaine de test particulier pour pointer vers ce nouveau serveur DNS temporaire, mais le gars a mis à jour l'enregistrement en direct et non celui de test .
Soudain, ce seul serveur (heureusement une nouvelle boîte, donc une spécification raisonnable) servant à peu près toutes les demandes DNS pour près de 5 millions d'utilisateurs - 400 millions de demandes le premier jour! - heureusement, le TTL n'était que de 24 heures, il est donc principalement vidé maintenant.
Dimension totalement différente, mais il s'agit toujours d'un accident de l'administrateur système.
Désolé: vous devez comprendre l'argot italien pour l'obtenir. Il ne peut pas être traduit. Vous devez le savoir par cœur
On m'a demandé de réparer quelque chose sur un serveur Solaris à Napoli, en Italie. J'avais besoin du mot de passe root et je ne parlais pas beaucoup italien à l'époque. Les gars semblaient réticents à me dire ce que c'était. Enfin, l'un d'eux chuchota à moitié:
J'ai dit: Aha, 'sticazzi'. Comment épelez-vous cela?, et lui a donné un morceau de papier + un stylo.
Un an plus tard, j'ai rencontré M.*o B.* encore (Salut! - si vous lisez ceci). À l'époque, mon italien était bien meilleur. Je lui ai dit que je connaissais maintenant un peu plus l'italien.
Ce fut un rire dur.
La morale de l'histoire: Si besoin de demander le mot de passe root dans une langue que vous ne connaissez pas, une fois qu'on vous l'a donné mieux rire, rougir et avoir l'air insulté en même temps.
Tout le monde est rm -rf/à un moment donné accidentellement. Le mien essayait de supprimer certains des fichiers supplémentaires dans mon répertoire personnel 2 jours avant l'échéance de ma dernière affectation de structures de données.
Professionnellement, j'ai été suffisamment capable pour ne pas avoir de problèmes de merde catastrophiques jusqu'à présent.
Cela ne m'est pas arrivé, mais je suppose que c'est une très belle histoire.
Ces gars-là travaillaient avec l'un de ces anciens serveurs à tour complète Solaris qui, comme je le sais, détenaient des bases de données pour plusieurs bases de données Informix de cette société. Il s'agissait d'une entreprise de services publics de base, vous pouvez donc imaginer la quantité de données que cela signifie.
À un moment donné, plusieurs configurations via des serveurs ont été copiées sur une disquette, puis transmises de serveur à serveur. Après avoir travaillé avec un serveur, ils éjectaient simplement la disquette et passaient au suivant.
Accompagné d'une autre personne du groupe sysadmin, ce type travaillait sur ces configurations alors qu'ils parlaient de choses aléatoires. Il a terminé son pas alors il a poussé le bouton pour éjecter la disquette.
- "ATTENDEZ! Ne relâchez pas le bouton!"
Quand il regarde à nouveau, il a appuyé sur le bouton de réinitialisation en cas d'erreur et non sur le bouton d'éjection. Au moment où il a relâché ce bouton, l'ensemble du système de base de données de l'entreprise était immédiatement mis hors tension. (Je pensais que ces boutons étaient instantanés ... mais c'est ainsi que l'histoire se déroule.)
Ainsi, chaque administrateur système arrête ce qu'il fait pour appeler les chefs de service et "dire à tout le monde de se déconnecter du système. Maintenant". tandis que ce gars regarde tout ce qui se passe attaché à un serveur par son doigt.
Lors de la configuration d'une adresse IP statique dans /etc/network/interfaces sur une boîte Debian, quelqu'un a accidentellement changé les adresses IP sur la ligne d'adresse IP et la ligne de passerelle.
Devinez ce qui se passe lorsque vous "volez" l'IP du commutateur principal?
Oh, un jour, j'ai supprimé une base de données PostgreSQL par inadvertance et je l'ai récupérée à partir des fichiers journaux;)
Heureusement, j'ai pu récupérer facilement de ce que je vais partager avec vous. Vous avez donc entendu parler de l'infâme
rm -rf /
deltree/y/s/b \
Mon problème est que j'ai tapé ceci et je savais que c'était faux, alors je suis allé appuyer sur la touche de retour arrière, mais je l'ai touché du doigt et j'ai plutôt appuyé sur la touche Entrée! Il m'a fallu littéralement seulement 2 secondes pour réaliser ce que j'avais fait, alors j'ai furieusement commencé à appuyer plusieurs fois sur ctrl-c pour abandonner l'opération. Au moment où je l'avais arrêté, la moitié du système de fichiers avait disparu.
Des sauvegardes à la rescousse, mes amis! À part un redémarrage, il n'y avait pas d'autre temps d'arrêt. Dans un sens, j'ai été vraiment chanceux ce jour-là car j'avais de bonnes sauvegardes en place.
Au début de l'administration du système, j'ai inventé une nouvelle méthode de gestion des stocks (inventaire) pour nos magasins de détail. J'ai pris beaucoup d'ordinateurs portables et de lecteurs de codes-barres connectés et j'ai rendu le processus dix fois plus rapide que d'habitude comme lorsque nous l'avons fait en écrivant tous les articles avec un stylo sur pappier. J'ai également acheté des terminaux portables Symbol PDT DOS. Pour prolonger la durée de vie des batteries des bornes Symbol, j'ai fabriqué mes propres batteries et les fils connectés manuellement. Cette nuit-là et le lendemain matin, j'étais si fier de moi et j'étais fier comme un paon se promenant dans le bureau en disant à quel point j'étais intelligent.
Le cauchemar a commencé lorsque j'envoyais des données vers le serveur pour faire un calcul et une comparaison des stocks et des listes. L'un des appareils Symbol avec une batterie supplémentaire avait été flashé car l'un des fils était tombé en panne et l'appareil était resté sans énergie pendant longtemps.
Aujourd'hui, tout le travail d'une centaine d'employeurs est tombé à l'eau. À quoi servent 13 ou 15 appareils et leur liste si je ne les avais pas tous? Comment pourrais-je savoir ce qui manquait dans l'inventaire.
Pour mieux décrire ma catastrophe, nous n'avons eu que quelques jours de congé dans l'année. C'est lorsque nous fermons nos magasins et faisons l'inventaire, et cet événement coûte beaucoup d'argent et d'efforts à notre entreprise.
Heureusement pour moi, notre directeur et chef de ce nouveau procès a été des listes d'inventaire raisonnables et acceptées car ils étaient à l'ordinateur pour cette année.
Après cela, je fais toujours deux copies de données pendant que le travail est en cours et juste après la fin du processus d'inventaire et bien sûr je ne me vante plus.
Je suis un peu un administrateur système novice/hobbiest avec seulement 30 à 40 sites hébergés sur mon serveur, donc ce n'était pas trop mal. Je supprimais les autorisations d'exécution sur tous les fichiers du répertoire/bin/xxx et ils ont tous commencé par.
Donc, prenant l'action évidente, j'ai couru
chmod -R a-x .*
Sensationnel. Lorsque vous supprimez les autorisations d'exécution sur votre répertoire bin, le nettoyage est assez compliqué. Les techniciens du centre de données ont dû démarrer sur un CD live pour y remédier. La meilleure partie était que je devais leur expliquer comment y remédier. Le pire, c'est qu'ils en savaient encore assez pour rire de moi: P
Au tout début d'Internet, j'ai tout exécuté sur les serveurs SGI Challenge S. À un moment donné, à mon insu, le "département artistique" a commandé un serveur d'impression de rendu de démonstration à IKON. Entré dans une matinée, défi agissant drôle, appels d'administrateur dans la salle des serveurs, nous passons par des diagnostics de routine, etc. enfin je dis qu'il DOIT ÊTRE l'alimentation. Bien sûr, nous n'avons pas de rechange. Je rentre dans le bureau principal - je vois la machine du prêteur et je me rends compte - c'est aussi un SGI - l'ouvre, dévisse l'alimentation électrique, redémarre le serveur - bingo! Nous commandons une pièce de rechange pendant la nuit, un représentant se présente le matin pour demander comment nous aimons la démonstration, nous devons hummada hummada pendant 30 minutes jusqu'à ce que FedEx se présente et nous échangeons de nouveau les blocs d'alimentation et roulons la boîte de démonstration à l'extérieur. Tout en un jour de travail.
Il y a longtemps, j'ai décidé de changer le point de montage de ma partition de données. J'ai donc créé un nouveau répertoire, changé le point de montage dans/etc/fstab et supprimé le répertoire sur lequel il était précédemment monté.
Le fait est que j'ai réalisé que les partitions étaient toujours montées sur l'ancien répertoire lorsque nautilus m'a montré une barre de progression (pour ce qui devrait être une suppression de 4 Ko). Heureusement, j'ai pu l'annuler avant qu'un gros dommage ne soit fait, mais j'ai perdu quelques fichiers.
Lors de la maintenance dans un même emplacement, j'ai tiré notre câble d'alimentation DNS principal. Je remplaçais le secondaire à l'époque et j'ai dû tirer le câble avant de fermer le rack. Tous nos sites ont commencé à chuter rapidement et j'ai dû retourner au co-emplacement pour rebrancher la chose stupide.
Lors de ma première tâche d'installation (il y a de nombreuses années, à l'âge du DOS), j'ai accidentellement supprimé presque tous les fichiers système et les demi-fichiers d'application sur l'ordinateur qui appartient au directeur de l'institution publique. Mais ce n'était pas ma faute. J'essaie de supprimer des fichiers non importants dans le dossier C:/TEMP pour libérer de l'espace. La suppression commence ... après quelques instants, je vois quelques noms familiers de la racine et du dossier DOS défiler à l'écran ... Frapper fort Ctrl + Break ... mais trop tard ...
C'était le moyen le plus difficile d'apprendre ce qu'est le problème des fichiers croisés sur le système de fichiers FAT.
Nous avons une installation d'essai à froid pour nos ingénieurs dans le nord du Minnesota. Il y a environ 10 ans, le T1 que nous avions là-haut est mort. Nous avions déplacé les serveurs de cette installation vers notre centre de données principal parce que nous avions installé la ligne plus rapide, donc presque tout était inutile là-haut. Venez découvrir qu'un agriculteur du centre du Minnesota avait parcouru la fibre avec un équipement agricole. Nous n'étions pas trop heureux que la fibre soit même accessible à cet équipement et pas enterrée beaucoup plus profondément ...
Imaginez une tasse de café. C'est une tasse pleine, avec du sucre. Imaginez-le sérieusement mal placé sur le plateau de clavier rétractable d'un rack. Un rack plein de serveurs. Le plateau est en quelque sorte poussé dans le rack. La tasse pénètre dans le panier, puis bascule.
C'était ma faute, et j'étais alors un administrateur chevronné, donc je n'ai aucune excuse. Il y avait une salle de bain à proximité et j'ai pu nettoyer la plupart des dégâts avec des serviettes en papier. Heureusement, il n'y a pas assez de café dans les serveurs, alors je les ai fermés et bien nettoyés. Seulement 400 utilisateurs concernés. Phew!
Puis il y a eu un autre accident, appelons-le ainsi, qui est arrivé à un de mes amis. Il a consacré les 10 dernières années à construire sa propre entreprise. Il compte environ 15 employés et toutes les données de l'entreprise se trouvaient sur ce seul serveur. Cela comprenait tous les projets passés et présents, de nombreuses données sur les clients, les informations qu'il avait contractées pour assurer la sécurité, toutes les informations de contact, etc. Tout était bien crypté avec LUKS. Je le harcelais depuis longtemps pour le faire commencer à faire des sauvegardes, mais il ne l'a jamais fait. Trop occupé, à court de fonds, vous avez l'idée. Il était convaincu que son RAID1 le sauverait. Sa dernière sauvegarde avait 8 mois. C'était aussi la disponibilité de son serveur. Il avait changé son mot de passe LUKS juste avant le dernier redémarrage, 8 mois avant cela. Maintenant, il a redémarré son serveur et s'est rendu compte qu'il n'avait pas écrit le nouveau mot de passe, et il ne s'en souvenait pas. Tout ce dont il se souvenait, c'était qu'il était très long, et qu'il y avait plusieurs mots approximativement arrangés d'une manière ou d'une autre avec une sorte de majuscule et éventuellement des symboles.
Vous pouvez imaginer le degré de démoralisation de ses employés et la rage des clients qui ont dû renvoyer leurs informations pour traitement, apprenant ainsi que leurs données étaient "temporairement" indisponibles. Pour faire court, il m'a fallu environ 40 heures de travail, 14 jours d'exécution et un programme spécialisé pour générer et tester plus d'un million de mots de passe pour enfin trouver son mot de passe LUKS.
Il y a plusieurs années, notre administrateur iSeries de l'époque effectuait un nettoyage dans la zone où nos serveurs IBM iSeries étaient assis dans la salle informatique. Il était environ 8h30 du matin. Tout comme j'ai commencé à travailler avec tout ce sur quoi je travaillais à l'époque. L'écran s'est éteint quelques secondes plus tard, les appels téléphoniques ont commencé à arriver.
Venez découvrir, quand il a déplacé une table, le cordon d'alimentation était enroulé autour de la jambe juste assez pour qu'il sorte quand il a déplacé la table.
Environ deux heures plus tard, après que le système se soit remis de la mise hors tension, les gens ont pu de nouveau travailler.
Nous avons eu un peu de gâchis il y a quelques années. En milieu de matinée, les utilisateurs ont commencé à signaler de nombreuses erreurs sur le verrouillage lors de l'accès à notre application hébergée par SQL Server. L'application s'arrête complètement - personne ne peut rien faire. Plutôt que de prendre le temps de découvrir la cause, nous effectuons un redémarrage d'urgence et tout recommence à fonctionner. Ensuite, je commence à parcourir les différents journaux pour voir ce qui aurait pu le déclencher, et juste avant que tout ne se complique, je trouve une transaction nommée ouverte contre la table principale sans COMMIT correspondant.
Il s'est avéré que mon collègue avait écrit du SQL dans l'Analyseur de requêtes pour corriger certaines données erronées dans la table principale, et il les avait placées dans une transaction. Mais, au lieu de simplement appuyer sur F5 pour l'exécuter, il avait mis le tout en surbrillance, puis avait frappé F5. Sauf qu'il n'avait pas tout à fait tout mis en évidence ... il avait raté la fin où il avait en fait ENGAGÉ la transaction ... laissant la table verrouillée.