Les ordinateurs de l'HORREUR

[Jaerdoster]

Inspiré de Tales from IT/Tales from tech support, je me disais que l'on pourrait raconter nos histoires d'horreur avec les ordinateurs et leurs utilisateurs maléfiques.
J'ai travaillé 1 an comme auto-entrepreneur, puis depuis plus de trois ans en banque dans l'informatique. Et j'ai un tas d'histoires atroces

Histoire 1: le docteur et la pile d'ordinateur

Quand j'habitais à Paris, au début que je m'étais lancé comme auto-entrepreneur, j'avais laissé des flyers partout, et en allant chez mon médecin je lui ai demandé si je pouvais en laisser dans sa salle d'attente, et il m'a dit qu'il avait besoin de mes services pour ses ordinateurs portables.

Oui, 'ses' ordinateurs.

Je lui ai dit ok, on a discuté prix, il était ok, et est parti a l'étage (il habitait au dessus du cabinet) avant de redescendre avec une véritable pile d'ordinateurs portables dans un sac Carrefour, vous savez, les grands pour les courses là. Il y en avait 7, toutes marques, et pas des légers, 15" minimum à chaque fois. Ça devait bien faire dans les 15/16 kgs avec les chargeurs.

Et là il m'explique le pourquoi.

Il s'avère que le docteur, que nous appellerons D., est une véritable buse en sécurité informatique, et qu'il a accessoirement trop d'argent visiblement. Du coup, quand il a un PC qui devient trop lent (comprendre vérolé de merdes) ou qui ne démarre plus, il en rachète un. Mais là ça lui fait une petite pile, et il aimerait bien au moins récupérer des données persos, des photos, des trucs comme ça, histoire de tout regrouper.

Je vous laisse imaginer.

Je rentre chez moi avec la pile de PC (et croyez moi, remonter la rue de Bagnolet avec 16kgs a bout de bras ça use), et je sens les emmerdes. Je prends mon vieux PC portable (qui s'appelait a l'époque Poubelle, parce qu'il passait son temps à en prendre plein la face et à se faire formater la tronche), je boot sous Linux et j'active un anti virus de qualité histoire de survivre a l’apocalypse a venir (ouais, ça existe sous Linux, ça sert à nettoyer des disques durs windows moisis ).

J'y vais yolo, j'allume le premier PC: un million d'icones de jeux de cartes à la noix, de solitaire, de mahjong et autre applications de quand on s'ennuie. Je me dis qu'heureusement que cette merde est pas connectée au réseau

Je lance le seul navigateur installé, Internet Explorer, et vais voir l'historique de navigation, histoire de savoir si je vais lutter avec des malwares de sites de cul, mais au delà de la légendaire barre d'outils Vosteran (un truc inventé par SATAN quand il s'ennuyait), rien d'anormal. Pas mal de sites de jeux en flash, surtout des Puzzle Bobble et des solitaires mahjong. Du coup ça explique le peu d’agressivité des merdes dessus.

Je colle un coup de malware bytes, un coup d'antivirus, je nettoie à fond, installe un Avast et colle par défaut firefox avec AdBlock. Espérons que ça suffise. Je fais la sauvegarde des photos de vacances au Cambodge et de l'anniversaire de sa fille de 4 ans.

Les 2nd et 3eme PC: pareil. Vidéo de son fils qui apprend à faire du vélo, mariage quelconque, rien de choquant.

Le 4eme est plus fun: Je le démarre, gros message me disant que je suis infecté par un virus et que je dois acheter un anivirus pour récupérer mes données. Aucun fichier de visible dans aucun disque, et les options pour afficher les fichiers cachés ont disparues "accès restreint par l'administrateur".
Je sors le disque dur, le branche sur un rack externe relié au pc portable et me prépare au pire. Ça ne manque pas: l'antivirus du PC portable devient dingue, genre "yo c'est la fin du monde". Le PC était infesté d'un de ces virus qui prend la main, colle tous les fichiers en cachés et te rackete pour te rendre les droits dessus.
Après un gros nettoyage, je sauve des paroles de chorale, mais considère le disque comme perdu et pars sur le combo formatage + réinstallation windows propre.

Le 5e est mort, grosse tache de café sur le clavier, carte mère qui boot plus, ça sent le court circuit. Paix à son âme.
Données sauvées: photos du chien, anniversaire de la fille, fils qui boude.

Le 6e a un putain d'impact sur la coque, et un disque qui fait crouic crouic pendant longtemps. Je sors le disque, sauve ce que je peux a une vitesse proche du néant (j'ai copié 350mo de photos en 4h30, chrono en main), et j'y installe un nouveau disque dur, facturé bien évidemment. Nouveau windows, roulez jeunesse.

Le 7e ne démarrait plus, il le croyait mort. Je le teste, pas de démarrage. Pas de lumière verte sur le chargeur non plus. Ah.
Je change le cable qui va entre le transfo et la prise de courant: it works !
Nettoyage du PC, sauvegarde des vacances au ski. C'est fait.

J'y retourne le lendemain avec 6 PC sur 7 de valide, le dernier étant KO (je ne change pas les cartes mères, il fera ce qu'il veut avec) et obtient mon paiement.

Moi: "Et donc, vous allez faire quoi de tous ces PC ?"
D: "Bonne question. Vous ne voulez pas m'en racheter un ?"

[Discorde]

Je valide à 200% ce topic. Vivement les suivantes !

[Jaerdoster]

Je suis actuellement "Gestionnaire d'applications". traduit en clair je suis un support transverse, et je me tape tout ce que les maitrises d’œuvre et d'ouvrage refusent de faire: reportings, gestion d'incidents, etc, et surtout on est support tantôt technique, tantôt fonctionnel, selon le domaine sur lequel on travaille.

Mes domaines sont la gestion électronique de documents, une application bancaire centrale de workflow qui y fait appel, diverses applications qui gravitent autour, et les applications de prêts immobiliers, qui sont dépendantes des précédents domaines.

Ma particularité est que je suis, contrairement a plusieurs collègues, aussi bien versé dans les domaines fonctionnels que techniques, du coup je me tape souvent les cas de merde.

Quand on numérise un document, on remonte pas mal de données sur le document dont sa date, son type (par exemple un relevé de compte) ou la personne a qui c'est lié.
Pour certains types de documents liés a une procédure et une application spécifique, on remonte également un numéro de compte qui se trouve sur les feuilles, et c'est là que notre histoire commence.

Histoire 2: "Mais ça n'a jamais fonctionné !"

Nous avons effectué une mise à jour de la chaine de numérisation de documents, et un bug s'est installé, nous empêchant de remonter le numéro de compte jusqu'à l'application destinataire, que nous appellerons l'application D. Je vous explique le workflow pour que ça soit compréhensible.

Création de dossier dans le logiciel de workflow > création automatique du dossier dans application D > Numérisation des documents nécessaires > remontée des documents dans logiciel workflow > remontée du numéro de compte dans appli D.

Du coup, les utilisateurs n'ayant plus la donnée de compte préremplie devait la taper à la main.
Comme je gère tout ce domaine, je dois voir quel est l'impact en attendant une correction technique, et je contacte donc un utilisateur de l'application D et lui demande a quel point ça les ralentis de ne plus avoir cette donnée préremplie.

User: "Mais ça n'a jamais fonctionné !"
Moi: "Comment ça ? On remontait bien la donnée avant."
User: "Sans doute, mais moi je dois taper à chaque fois à la main en reprenant le document numérisé, et mes collègues aussi."
Moi: "OK, je vais essayer de comprendre"

Du coup, je lance un mail avec comme destinataire mon Chef direct(Chef), le responsable technique chaine de numérisation (RespNum), le responsable du logiciel workflow (RespFlow) et le responsable de l'application D (RespD)

Code : Tout sélectionner

De: Moi
A: RespNum, RespFlow, RespD
CC: Chef
Bonjour,

<Explication du problème suscité>
@RespNum: Tu as moyen de nous sortir la forme exacte du compte bancaire qui est remonté, de préférence dans le flux XML de sortie ?
@RespFlow: Quand tu auras la réponse de RespNum, tu as moyen de vérifier que tu reçois bien les données venant de la CdN ? Et de voir comment tu les remonte ?
@RespD: Quand tu auras la réponse des 2 suscités, tu auras moyen de vérifier si la donnée reçue est exploitée chez toi et si ça fonctionne ?

Cordialement

S'en suit une suite de mail diverse, qui va durer pas loin de TROIS MOIS, ou tout le monde cherche de tous les côtés, ou RespNum bosse jusqu'à pas d'heures pour corriger le problème de remontée de la donnée, et alors qu'il l'a réparée....

Code : Tout sélectionner

De: RespD
A: RespNum, RespFlow, Moi 
CC: Chef

Bonjour,

En fait, j'ai vu avec les responsables fonctionnels de l'application, et la donnée n'est pas utilisée par l'application.

Cordialement

Code : Tout sélectionner

De: Moi
A: RespNum, RespFlow, RespD
CC: Chef
Bonjour,

Et du coup, on remonte cette donnée pour quoi ?

Cordialement

Code : Tout sélectionner

De: RespD
A: RespNum, RespFlow, Moi 
CC: Chef

Bonjour,

Pour rien, elle ne nous est pas utile

Cordialement

tl;dr: On a mis en place des règles spécifiques pour une application précise sur un type de document précis afin de faire remonter des données utiles, la règle tombe en panne, on fait tout pour la réparer au plus vite, pour au final se rendre compte que ça ne sert à rien.

[QCTX]

A l'époque, je bossais pour la première fois dans le milieu bancaire. Niveau support avancé, pas pour les cas désespéré et pour des utilisateurs de type développeurs/chefs de projets techniques dans le monde entier.
Évidemment, pour une grosse banque, côté "banque de marchés" (comprendre, La Bourse, pas les particuliers), ça nécessite un minimum de sécurité sur les machines. Et donc les ordinateurs portable sont protégés physiquement contre le vol de données par un cryptage du disque dur demandant un mot de passe à chaque reboot. Les mot de passe sont standardisés selon, entre autres, le nom du propriétaire de la machine.

Arrive donc un ticket d'un mec qui se plaint de ne pouvoir démarrer sa machine à cause du cryptage. Je l’appelle et vérifie que l'on parle bien de la bonne machine. Je lui explique comment est standardisé le mot de passe et lui annonce que donc son password doit être : "DURANT+blabla+identifiant" le propriétaire de la machine s'appelant DURANT. Et là mon interlocuteur m'interrompt.
- "Non, mais DURANT c'est mon chef, il est pas là, il m'a prêté la machine.
- Ah, mais si cette machine ne vous est pas attribué, vous êtes foutu, vous allez jamais pouvoir vous en servir. Et même si je vous aide là, vous allez être bloqué par Windows.
- Nos, non, c'est bon, j'ai le mot de passe.
- ...
- allo ?
- OK, je reprends, monsieur. Vous êtes en train de me dire que vous avez récupérer la machine de votre supérieur hiérarchique, que vous avez son mot de passe Windows et que vous souhaitez que je vous aide à décrypter le disque dur ?
- Ah oui, mais en fait, on l'a tous dans l'équipe le mot de passe, il nous prête tout le temps le portable, il s'en sert pas.
- <soupir>. Bon, écoutez, voilà ce qu'on va faire. Je vais faire comme si je n'avais pas entendu ce que vous venez de me dire. Je vais espérer pour vous que la Sécurité n'entende JAMAIS parler de votre cas parce que sinon, je ne donne pas cher de votre peau, ni de celle de votre chef. Et vous, de votre côté, vous allez m'apporter votre portable, et je vais le configurer pour que les 4 personnes de votre équipe puissent utiliser ce portable sans avoir à pirater le compte de votre chef. Pour information, ce mot de passe aurait pu vous permettre d'accéder à toute sa boite mail, à faire des demande d'accès à plein d'endroits et à répondre à sa place à n'importe quelle demande, j'espère que vous mesurez un peu pourquoi vous me faite froid dans le dos, là."


PS : bien entendu, la banque en question venait de se prendre quelque mois plus tôt un grosse flèche dans le genoux nommée Kerviel.

[Shikaze]

Pas vraiment de l'informatique pur (si ce n'est une erreur de saisie)... mais ça me rappelle mon boulot pour Wanadoo à l'époque.
Pour situer : je traitais les courriers de réclamation. Parfois technique, parfois financier, souvent hilarant.
Et le tout 1er dossier traité m'a mis de suite dans le bain. Je précise que je ne change rien à ce qui a été écris.
Ce courrier ?
Il commençait par....
"RENDEZ MOI MON NOM ET MON SEXE !!!"
Le plus drôle ? La demande était justifiée....
Le papy qui demandait ça avait une homonyme dans la même ville, et un couillon à la facturation avait réussi à intervertir leur nom, mais pas les adresses.... D'où l'erreur de saisie dont je parlais tantôt.
Dans le même style, faudra que je pense à en raconter certaines de l'époques où je faisais les réparations sur site pour Dell/NEC. J'en ai vu des très droles pendant 4 ans....

[s3phy]

Oh, chacun sors ses meilleures anecdotes (dont au moins une ou deux que j'avais déjà entendue )

À mon tour donc !

Alerte pavé. tl;dr en bas.

Je suis en stage chez un fournisseur de serveurs dédiés. Un OVH-like quoi. Mais avec un gros côté support utilisateur. On s'arrête pas à fournir la machine au client, on lui pré-installe ses softs, on les lui configure, on migre ses données de son ancien serveur... Et à peu près tout ce qu'il veut d'autre, on lui met en place, pour 75$ de l'heure. Et les gens payent, et payent. Je suis en stage avec les administrateurs systèmes au service à la clientèle. En gros, le support tech niveau 2. On m'a direct foutu niveau 2 parce qu'une fois les tests d'entrée passés, il s'est avéré que je poutrais sa mère en sysadmin Linux. En tout cas en comparaison avec les autres gens qui postulent pour ce taf.

Moi, jeune et naïf, je me disais que les gens qui prenaient un serveur dédié avaient les compétences pour l'utiliser. Quelle grossière erreur. Quand on fait du serveur dédié avec une bonne couche de support et surtout des bons vendeurs, on récupère tous les gens dont le site dépasse les capacités d'un hébergement mutualisé (en gros les mecs qui se sont fait foutre dehors des hébergements à 5$/mois vu que leur site consomme trop de ressources) et à qui on a vendu un serveur dédié comme la solution à leurs problèmes.

Un truc qui marche bien pour les bitos du dédié : les panneaux de contrôle. C'est un machin qui s'installe sur un serveur par dessus l'OS et permet depuis une interface web de faire toutes les opérations qu'un sysadmin ferait habituellement avec des fichiers de configuration ou des lignes de commande. Installer des paquets, les configurer, etc. On en propose deux différents au client, cP*nel et Pl*sk. Le premier est made in amuhrica. On est bien formés dessus. Le truc est d'une facilité impressionnante à prendre en main, autant pour le client que de notre côté pour le dépannage. Tout est plutôt logique quand on est habitué à Linux et qu'on connaît un minimum les scripts Shell ou Perl. Le truc est presque incassable : quand un client vous annonce dans un ticket qu'il a TOUT cassé, et qu'il a réellement tout cassé, il y a un script qui s'appelle littéralement "fixeverything" et qui fait exactement ce que son nom indique : il répare tout et remet le serveur dans un état utilisable. Y'as quand même un peu de magie dans ce truc. En face de ça on a Pl*sk. C'est vendu par un grand groupe américain... à travers une filiale basée à Vladivostok. Les principales caractéristiques du bousin c'est que son interface web imite le thème/la charte graphique de Windows Vista ; et qu'on peut le vendre au Liban, à Cuba, à l'Iran... bref à tous les pays sous embargo US (et on a réellement des clients là bas d'ailleurs). Avant la version 10 ou 11, chaque mise à jour, même mineure (9.a à 9.b) était une opération délicate, sans grande garantie de fonctionner. Chaque mise à jour majeure (8 à 9), sûre de foirer, et donc on préférait proposer un serveur neuf au client et qu'il migre lui-même ses données entre ses deux serveurs. Ou on lui faisait pour 75$ de l'heure, mais vraiment parce qu'on AVAIT à le faire, et ça débitait par créneaux de 4 heures vu la quantité d'emmerdes qu'on était sûr et certain de rencontrer.

Et donc, arrive ce jour, où j'arrive au bureau, et mon collègue/chef de service, me dit "tiens s3phy, on a une migration Pl*sk 7 Pl*sk 11 pour toi". Le fuuuuu--- est total. Si on a attendu que j'arrive, c'est parce que PERSONNE n'a voulu prendre cette merde depuis que les premiers collègues du créneau de jour sont arrivés quelques heures avant. Bon, un grand chocolat chaud, une grande inspiration, et on y va... Dernier ticket assigné... On ouvre... déjà ça prend du temps à charger. Ça sent pas bon. Le texte s'affiche... la scroll bar du navigateur devient petite... petite... putain mais y'as DES PAGES DE TEXTE SUR CE TICKET. Et il a été ouvert quand ? Y'as des mois et ça traîne depuis ? Non, juste une douzaine d'heures... wtf. Bon ben quand faut y aller... on reprend depuis le début.

Le client a été alerté vers minuit/une heure que son serveur était inaccessible. Un collègue de nuit a voulu se connecter au serveur, mais il était vraisemblablement freezé. Même avec un KVM, rien à faire, rien qui réagit. On redémarre physiquement le serveur. Et là il ne se rallume plus. On envoie un technicien dans le datacenter inspecter ce qui ne va pas. La machine ne s'allume pas du tout. Le technicien déracke la machine. Tests des composants, carte mère HS. On a plus ce modèle de carte mère en stock : c'est une carte mère pour Pentium 4, avec RAM en DDR 1, et disques dur en IDE Le client nous loue ce serveur depuis 8 ans Et il ne l'a jamais remplacé Mon collègue informe le client qu'on ne pourra pas redémarrer son serveur, que les pièces de son vieux vieux serveur ne sont plus en stock, plus disponibles du tout... Et après quelques échanges, il lui propose la solution la plus censée avec les cartes qu'on a en main : remplacer tout les composants de son serveur par ce qu'on a en stock, demander une installation d'urgence du dernier Pl*sk, et migration de ses données de ses anciens disques durs vers sa nouvelle installation. Le client accepte, et le technicien remplace bloc d'alim, carte mère, processeur, RAM, et disques durs maintenant en SATA (en fait il finit par remplacer la totalité contenu du serveur, sauf son boîtier).

Pour la migration des données, mon collègue de nuit fait brancher au technicien datacenter les anciens disques dur du client sur le nouveau serveur avec des adaptateurs IDE/USB (procédure classique chez cet hébergeur pour ce genre de cas). Dans le ticket qui fait 1km de long, je lis qu'il n'a pas réussi à accéder aux données. Il informe le client qu'il a des difficultés à restaurer ses données, puis le bout de la nuit est là, le ticket est refilé à mon chef de service, et finalement m'est transféré. Entre le moment où mon collègue de nuit s'est barré et le moment où je suis arrivé, personne n'a osé toucher à ce clusterfuck, le client a déjà répondu deux fois en demandant un avancement.

Bon... Au travail. Déjà, répondre au client. Je suis dessus, je m'en occupe, laissez la police faire son travail, dès que nous aurons de plus amples informations, croyez-bien que vous en serez le premier informé. Ensuite, du gros bon sens pour commencer : migrer un Pl*sk 7 à un Pl*sk 11, ça marchera JAMAIS. La meilleure solution serait d'arriver à booter la vielle installation du client (à base de ... Fedora Core 2 ) sur cette nouvelle machine. On croise les doigts. Ça ne boote évidemment pas. Pourquoi est-ce que ça boote pas... Hm. Le chipset de la carte mère neuve qu'on a mis au client, qui est la carte mère la plus vielle/ancienne qu'on a stock neuve, n'est supporté qu'à partir du kernel 2.6.9. C'est pas tout jeune... Mais Fedora Core 2 a un kernel 2.6.5.

Ça marchera jamais, plan B... rager et faire cette putain de migration. Les disques dur. Mon collègue de nuit a tenté d'accéder au premier disque, j'ai des logs d'un mount en ext4 (mais vu l'époque c'est du ext2 ) en read-write ( ) avec un fsck qui a delete des tonnes et des tonnes d'inodes. Screenshots de ça, pour montrer l'état dans lequel je trouve cette situation. Un fsck ça peut détruire des choses. Pour le second disque, message au technicien de datacenter, probablement plus jeune que moi. Disques durs IDE. Tu sais ce que c'est des jumpers ? Met moi ça en master pour voir ? C'est détecté. On monte les disques. Premier disque : Euh mais il est vide à 90 % ?! Pourquoi /etc est vide ? Pourquoi /home est vide ? Pourquoi /var est vide ? Que dis le /etc/fsta... ah oui y'as plus de /etc. Bon y'as définitivement rien sur ce disque. Sur le second ? Ah. Y'as un /etc. Et un /home. Avec des trucs dedans... Mais pas beaucoup ? C'est curieux... Et soudainement, au détour d'un ls -l : Mais y'as aucun fichier sur ce disque plus récent que 2006 Quelques mois après que le client ait pris ce serveur. Ça sent le sapin. C'était pas censé être un RAID mirroring ? Bon au moins y'as des logs... Et là, l'échec : la dernière entrée de log, de 2006, indique que le RAID s'est dégradé, et que ce disque était sorti du RAID. Ah. Mais le client, il a bien des mails de notification ? C'est bien configuré... Donc le mec ignore les mails de rappels lui disant que son RAID est dégradé depuis 7 ans ? Et le crash du serveur semble avoir emporté avec lui le système de fichiers où y'avait le seul exemplaire de ses données-super-importantes Ou alors mon collègue de nuit n'ayant pas été très fin a tué par mégarde toute possibilité d'une issue heureuse ?

Bon bon bon bon bon. Je tiens au courant le client. Qui répond qu'il n'a aucun backup de son côté, mais qu'on devrait regarder, il a une solution de backup chez nous. Y'en a pas de trace dans sa fiche client/dans ses facturations. En plus, vu l'époque où son serveur a été mis en place, il doit être sur l'ancien système de backup (des simples rsync vers des serveurs gérés par la boite), système qui était en train d'être supprimé lors de mon stage précédent, un an avant. Mes collègues commencent à me dire "oh la merde. oh le c*n. et il a pas de backup ? et il s'en fout ? envoie le chier, j'ai aucune pitié pour les gens qui ne font pas de sauvegarde de leurs données et qui se plaignent après. c'est dans son contrat, on ne s'occupe pas des données. envoie le chier sérieux, arrête de perdre ton temps, ça fait déjà combien d'heures qu'on passe sur ce ticket ?!"

Ouais mais je me met à la place du client... Bon, retrouvons l'ancien serveur où les données du client étaient backupées, l'ancienne solution de backup n'est toujours pas complètement arrêtée, y'as encore quelques clients dessus... y'as peut être toujours un backup... demande au responsable de cette solution de backup : non, ton client n'a aucun backup ici. Fouille des archives des tickets du client : c'est censé être sur le serveur xxx de notre côté... la dernière demande à ce sujet remonte à y'as 7 ans... peut être que c'était toujours en fonctionnement ? Il est passé où ce serveur xxx... Décomissionné y'as un mois. Ses disques sont passés au formatage y'as... deux jours.

Bon ben... "Cher client. Votre serveur a lâché la nuit dernière. Il était tellement vieux qu'on avait aucune pièce de rechange. Son RAID était cassé, et vous avez ignoré pendant 7 ans les mails de notification. Vous étiez certain d'avoir une solution de backup chez nous, pourtant au plus loin que je remonte, je n'en trouve aucune trace dans votre historique de facturation. Je retrouve bien une demande de mise en place il y a 7 ans, à laquelle vous n'aviez jamais répondu. Au point où on en est, on peut vous proposer d'envoyer vos disques durs chez une société spécialisée de récupération de données, mais c'est à vos frais et ça coûte méga reuch. Mais hey, vous avez un serveur tout neuf avec un Pl*sk 11 tout vide dessus !"

Il a pas répondu. Par contre après quelques minutes j'ai entendu le ton hausser du côté du support téléphonique. Et puis au service résiliation/fidélisation. J'ai remercié sincèrement ma collègue de ce service qui l'avait pris au téléphone (après l'avoir briefé sur la situation pendant que le client attendait). J'en ai plus entendu parler... Jusqu'à quelques heures avant de mon départ de la boite, où le ticket, qui m'était toujours assigné, a été ré-ouvert avec une/deux pages de legalspeek et de menaces de poursuites... Ticket transféré à mon chef de service, mon stage est fini.


tl;dr : le client a un serveur super vieux qui tombe en panne. Il a ignoré les mails d'alerte pendant des années, n'a aucune sauvegarde et vient se rend compte de la situation dans laquelle il est uniquement quand c'est trop tard. C'était à moi de tout faire pour régler la situation... Et lui annoncer le décès de sa grand mère.

[Jaerdoster]

Oh, ça m'est arrivé un truc du genre, c'était assez horrible.

[AxelTerizaki]

Me lancez pas où je sors mon gros COBOL.

J'aurais pas mal de trucs à raconter aussi tellement c'est le bordel dans les administrations, mais je contribue quand même à mettre en garde ceux qui me succéderont peut-être en déclarant par exemple dés le début d'un gros programme de batard usine à gaz :

Code : Tout sélectionner

* Vous qui entrez ici.
* Abandonnez tout espoir.

Ou autres :

Code : Tout sélectionner

*             A mon moi de 2020 : pense a changer ca a 2

Suivi d'une assignation de valeur à 1 actuellement parce qu'on est en 201x.

Mon quotidien.

[DarkSoul]

Moi, j'ai un medley de classiques des boîtes où j'ai bossé au Japon :

Résurrection du daemon

1) Un 31 décembre 2007, Shikaze se souviendra m'avoir entendu hurler sur Teamspeak après qu'il ait eu le malheur de dire "boum". Oui, à l'époque, il avait le pouvoir d'attirer les explosions. J'ai vu des alims de DELL PowerEdge 650 et 750 exploser, un condo propulsé comme une balle avec un bruit de revolver pour s'arrêter à la grille de l'alim, après avoir transpercé les pales fondues du ventilo.

Mais aujourd'hui, ce n'est pas d'une explosion d'alim dont je vais vous parler.

Sur Teamspeak :
<DarkSoul> Shik, je te jure, si mon téléphone sonne, je te t-*DRIIIIIIING* RHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA !
<Shikaze> Euh... ça a planté ?
<DarkSoul> OUI.
<Shikaze> o_o
<Shikaze> ... COMMENT tu as fait pour que j'ENTENDE le rouge dans ta voix ???

Je reçois un appel d'urgence car, bien sûr... LA PROD EST DOWN.
Sur un site où j'avais un terminal résident en root, DIEU MERCI.

Je vous la refais simplement pour l'état des lieux (approximatif) :

Code : Tout sélectionner

# ls
zsh: command not found: ls
# echo *
# pwd
.
# cd /
# echo *
home lib mnt tmp
# echo home/*
zsh: no match
# echo mnt/*
zsh: no match
# echo tmp/
gen_data.sh
# echo lib/*
zsh: no match

Oui. Le système se résume à quatre répertoires sous la racine : /mnt, /tmp, /lib, et /home.

UN WIPE TOTAL.

Plus de binaires, plus de libc, plus de RIEN.
"Accroche-toi au terminal, je retire le shell", eh ben tu croyais pas si bien dire !
La bécane était un FreeBSD 6.3. Bon. J'en ai un à la maison aussi.

J'ai exécuté :

Code : Tout sélectionner

# > /lib/libc.so.4
# > /tmp/gen_data.sh

... copié collé la libc de l'OS à sa place (avec une ruse pour que les séquences magiques ne soient pas interprétées, et n'en faire qu'un simple conduit à octets comme quand on uploade un firmware sur port série de switch par le canal de commande), et /usr/bin/tar dans le /tmp/gen_data.sh. En faisant le pari que ce dernier était exécutable.

Après de LONGUES minutes à me RONGER les sangs et prier pour que la copie se fasse sans accroc :

Code : Tout sélectionner

# /tmp/gen_data.sh
tar: Must specify one of -c, -r, -t, -u, -x

YES !!
Un moyen de transférer des fichiers, et de détarrer des archives.
Prochain binaire que je copie : fetch.
Prochain fichier que je reconstitue : /etc/resolv.conf.

YES !!
Accès au réseau et à http://ftp.freebsd.org/pub/FreeBSD/ pour downloader les .tar.gz de l'OS !
Après application de :

Code : Tout sélectionner

# fetch http://ftp.freebsd.org/pub/FreeBSD/i386/6.3-RELEASE/base/base.{aa,ab,ac,ad,ae,af,ag,ah,ai,aj,ak,al,am,an,ao,ap,aq,ar,as,at,au,av,aw,ax,ay,az,ba,bb,bc,bd,be} | tar -C / -zxpvf-
# fetch http://ftp.freebsd.org/pub/FreeBSD/i386/6.3-RELEASE/kernels/generic.{aa,ab,ac,ad,ae,af,ag,ah} | tar -C /boot/ -zxpvf-

J'avais un OS restauré et normalement bootable. Normalement. Mais l'heure n'était pas encore à vérifier.

Le plus dur était fait mais il restait à réinstaller les packages et tout le code, et les données (principalement statiques) du serveur web de contenu. QUI ETAIT TOUJOURS UP !
Donc, restauration des données statiques en priorité. Le reste, on verra après.

Je remets enfin les programmes, et je regarde le commit log.
Et je vois dans les derniers commits, l'ajout d'un commentaire dans le style suivant :

Code : Tout sélectionner

: To erase all temp data, do : rm -rf /tmp/data && rm -rf / usr/data/tmp/

S'ensuit un coup de fil rageux au responsable qui m'avait appelé plus tôt pour signaler l'apocalypse :
-"Ah tu as trouvé la cause ? Mais je comprends pas, mon rm -rf il était en commentaire !"
-"PARDON ? Pourquoi t'as utilisé cette syntaxe d'abord ?"
-"Ben tout le script avait été écrit par les anciens comme ça, donc ..."
-"... #°Д° ET POURQUOI TU AS LANCE CA EN *ROOT* SUR LA *PROD* SANS TESTER ?!"
-"Ben j'étais pressé ! Release de minuit tout ça"

Pour l'explication pour les non-UNIXiens émérites, ceci n'est pas un commentaire. La commande : est une commande dite NOOP, c'est-à-dire qui ne fait *RIEN*. Mais c'est une "commande", et non pas un "commentaire". Elle annule tous ses arguments, mais pas les opérateurs logiques. C'est le style de commentaire UNIX d'il y a trente ans à l'époque où sh ne gérait pas le caractère # pour des commentaires et où on faisait avec ça.

Ceci veut dire, que la commande a exécuté du rien, jusqu'à rm -rf / usr/data/tmp/. C'est à dire, tout effacer recursivement depuis /, puis ./usr/data/tmp/. "Un jour je ferai le génocide des cons, et je finirai par moi-même."

Vous connaissez la suite.

Trop énervé que j'étais sur le moment, je n'avais pas panné certains trucs. Notamment comment sur un FreeBSD il avait pu éradiquer la libc avec un rm -rf /, ce n'est normalement PAS possible. (FreeBSDistes en herbe, je vous invite à jouer avec la commande "ls -lo" dans /lib et autres pour voir si vous avez des ficihers flaggés "schg" (man chflags) => soit, system-immutable. Oui, fichiers protégés MÊME contre une modification par le root.)

Ce que script veut, Dieu le veut, mais sysadmin veut pas

2) Mais ça, c'est encore une autre histoire, je découvrirais qu'un sadomasochiste avait un script qui faisait des "rm -rf /$VAR" avec un $VAR souvent vide, et s'était plaint de voir que son script faisait :
unlink: Operation not permitted (Notez que ce n'est PAS "Permission denied", c'est encore différent)

Le mec a creusé ce message, découvert l'existence de chflags, et s'était mis en devoir... DE RETIRER LEDIT FLAG SUR *TOUS* LES SERVEURS °Д°. Parce que "vous les sysadmins vous pensez qu'à interdire, si mon script il veut faire un truc il le fait". Tralalalalalalalalalala.

SQL, autiste et CSV / Dérivé de la troisième Loi de Clarke

3) Quelques années plus tard dans une autre boîte, j'ai eu affaire à un gros méchant qui devait me filer un CSV de données à intégrer dans des applications, genre Redmine pour enregistrer des users pas dans Active Directory et pas synchronisables par moyens orthodoxes.

Feignant que j'étais j'avais codé un importateur CSV en shell vers postgres.
Mais j'avais pris mes précautions, et le truc était blindé contre les injections.
Après le découpage, j'encoderais en base64, avant de faire décoder par la DB comme suit :

Code : Tout sélectionner

function b64_encode()
{
  echo -n "$@" | openssl base64
}

cat fichier.csv | while read LINE ; do
  fname=`echo "$LINE" | cut -d , -f 1 `
  lname=`echo "$LINE" | cut -d , -f 2`
  mail=`echo "$LINE" | cut -d , -f 3`
  fname_b64=`b64_encode "$fname"`
  lname_b64=`b64_encode "$lname"`
  mail_b64=`b64_encode "$mail"`
  psql -c "INSERT INTO table ( first_name, last_name, mail ) VALUES (
convert_from(decode('${fname_b64}', 'base64'), 'UTF8')::text,
convert_from(decode('${lname_b64}', 'base64'), 'UTF8')::text,
convert_from(decode('${mail_b64}', 'base64'), 'UTF8')::text
);"

Cette méthode, à défaut d'être performante, a l'avantage d'être absolument blindée sur le plan théorique car les données passées en SQL à la DB sont neutres (base64), décompactées et retypées par le moteur DB lui-même. "YOU SHALL NOT PASS."
Bref, je vous montre directement le résultat, j'ai eu un user (nom non contractuel bien sûr) qui a fini avec :
* First name : Takatora'; DROP DATABASE redmine;
* Last name : Kureshima'; DROP TABLE users;

Je vais voir le responsable de cet immondice.
"Ah oui pardon lol mon copier coller a rippé, désolé".

Copier coller. Bien sûr.
Furieux, je me suis plaint aux chefs pour me faire rembarrer qu'un "grand ingénieur comme moi devait faire preuve de plus de mansuétude à l'égard de ses collègues pas spécialistes en info", "que je me prenais trop la tête sur des détails triviaux et que c'est pour ça que je ne m'intègrerais jamais".
OK, compris. Très bien. Zen. Je laisse couler.
Je laisse la merde se propager et être visible.
Je laisse le business user appeler le helpdesk et demander pourquoi son nom s'affiche bizarrement.
Je laisse un ticket se créer et garder une trace d'audit plus solide que n'importe quelle plainte.
Je laisse le mec s'exciter et se figurer que j'élimine ses merdes à la main.
Comme un taureau furieux qui charge le toréador, il s'énerve.
Il se met à pourrir de plus en plus de fichiers qu'il livre.

Jusqu'au jour... Où il pourrit la DB d'audit globale. En pleine audit financière.
Merci les backups de la veille, mais 12 heures de data qui ont disparu. Ca a pas rigolé pour lui. Mais alors, pas du tout.

[IlPa]

Suivi d'une assignation de valeur à 1 actuellement parce qu'on est en 201x.

Cette sécurité de l’emploi.


Je court-circuite pour replacer l’histoire connue :

C’est un développeur COBOL qui devient riche dans les années 90 en tant que consultant spécialisé dans la correction préventive du bogue de l’an 2000.
Il profite de sa fortune pour se faire cryogéniser, voulant découvrir à quoi le monde d’un futur lointain ressemblera.
En se réveillant de sa cryogénisation, il demande : « En quelle année sommes-nous ? »
On lui répond : « Nous sommes en 9999. Il parait que vous maitrisez le COBOL ? »

[Shikaze]

Plutôt que des kabooms, faut avouer que dans ma période Tech sur site, c'était plus "les fondus de l'informatique".

Je sais pas si j'ai encore les pics dans un coin, mais j'ai eu droit, entre autre :
- Des bobines se dessoudant de la PCB de l'alim parce qu'elles ont trop chauffé. Comment je le sais ? Parce que les dites bobines ont été retrouvées dans les pales du ventilo. Pas entre. DANS les pales. Elles avaient fondu le plastique de la pale.
Et j'ai remplacé plusieurs alims avec ce symptôme dans la même usine....
- Remplacement de carte mère chez un particulier. Je comprends mieux le pourquoi en ouvrant le boitier : le connecteur USB sur la carte mère avait fondu.
"Msieur, vous avez branché QUOI sur votre port USB ?"
Aucune réponse, et quelque chose me dit que je voulais pas savoir....

Mais j'ai aussi eu droit à quelques réels kabooms, dont au moins un par ma faute.
Protip : Dell fait dans l'international. TOUJOURS vérifier le voltage de l'alim avant de brancher le câble d'alim. Sinon ça pète direct. Selon le client, j'avais viré une très belle teinte de blanc après que le bloc m'ai littéralement explosé à la tronche, heureusement sans dégât ni projection, mais avec une belle fumée blanche.
Et je ne parle pas de l'état de composants diverses et variés après chaque orage dans les coins reculés de l'Auvergne, où le réseau électrique est pourri à la base. Je rigole encore de cette carte modem dont la puce avait gonflée jusqu'à explosion....

Et je préfère ne pas parler de mon taf actuel, où les tests en prod, sans prévenir les pilotes d'exploitation (aka bibi ici présent), sont relativement fréquents. A tel point que quand un serveur tombe, mon 1er réflexe avant d'ouvrir un ticket est d'aller voir les N+1/+2 pour savoir si y'a pas des opérations en cours. 8 fois sur 10, c'est un truc dont on était pas prévenu.

[ElKa]

Je comprends rien mais alors RIEN DU TOUT à ce que vous écrivez. Mais je peux pas m’empêcher de lire tout les pavés et de trouver ça drôle. Bon topic.
Au moins ça me fait dire que c'est sur et certain que ce n'était pas ma voie.

[Ley]

Moi je comprends à peu près et je kiff, et puis DarkSoul arrive avec ses gros sabots.

[Audrey Azura]

Je trouve que s3phy et DarkSoul sont tous deux aussi délicieux. C'est quand même de très belles anecdotes.

Par contre, je dois avouer que je me pose vraiment la question de comment ces injections SQL sont arrivés dans le nom. De la malveillance à ton égard, tu pense ?

[IlPa]

Par contre, je dois avouer que je me pose vraiment la question de comment ces injections SQL sont arrivés dans le nom.

Peut-être que c’est son vrai nom à l’état civil ?

[DarkSoul]

Je trouve que s3phy et DarkSoul sont tous deux aussi délicieux. C'est quand même de très belles anecdotes.

Par contre, je dois avouer que je me pose vraiment la question de comment ces injections SQL sont arrivés dans le nom. De la malveillance à ton égard, tu pense ?

Totalement. Tu fais pas des injections SQL dans tous les CSV que tu livres "sans le vouloir", ou alors tu t'exiles et tu renonces à toucher à un ordinateur pour le reste de tes jours.

On parle d'un fichier du genre :

Code : Tout sélectionner

Kureshima,Mitsuzane,k.kureshima@boite.jp
Kureshima';DROP DATABASE redmine;,Takatora'; DROP TABLE users;,t.kureshima@boite.jp
Kazuraba,Kota,k.kazuraba@boite.jp

Si tu me dis que le mec l'a pas fait exprès, de toute façon j'appliquerai la version modifiée de la loi de Clarke et son corollaire :
- Toute stupidité assez avancée est indistinguable de la malice.
- Et doit être traîtée comme telle, car il n'y a plus de différence. (Oui, il y A des gens dans notre métier, dont la stupidité compte comme arme de destruction massive)

[Nemo]

J'ai l'impression d'écouter les récits d'aventures d'Indiana Jones de l'informatique bien au chaud près du feu avec un chocolat chaud et des marshmallows. Je dois avouer que c'est un vrai plaisir. Merci beaucoup.

Excellent topic en tout cas. J'aurais bien quelques anecdotes mais elles vont paraître minable en comparaison.

[Little Yokai]

Je me sens comme Nemo pour le coup (Support/maintenance bureautique sur place auprès des utilisateurs donc conneries de base only quoi) mais ce topic est extra à lire.

Bordel s3phy ton histoire Le genre de truc que je déteste : Inextricable, tu te donnes à fond pour aider la personne, malgré tout tes efforts t'arrive à rien, et l'autre s'excite derrière oTL

Perso j'avais ouvert un ptit tumblr à gifsur le sujet mais ça fait un moment que j'y ait pas posté (et c'est fade en comparaison) mais si une anecdote particulièrement croustillante me revient à l'esprit, je viendrais vous la raconter

Genre par exemple, l'utilisateur que je dois rassurer longtemps que non, les icônes ne disparaitront pas du bureau quand je remplacerait l'écran. Oui oui.

[DarkSoul]

Pour en citer une bien plus abordable, dans une des boites ou je suis passe, on a du faire de la replication intercontinentale de DB.

La luxure est mère du génie ?

17GB de data. Un peu gros quand meme.
Et la je me dis "attends une seconde, il y a QUOI dans ces donnees ?"
Oui, parce que a repliquer en Europe et en Amerique, ben ca prend du temps. Donc tant qu'a faire, autant etre SUR que c'est necessaire.
Je regarde les tables et je vois que sur la trentaine de tables, il n'y en a qu'une qui est particulierement enorme, faisant 16.5GB.

Je regarde le contenu :

Code : Tout sélectionner

object_id | block_id | blob
1 | 1 | EVSS\x82\xb9\xcd\x00NIV YVFG...
1 | 2 | .........................................
[...]
1 | 1502 | .........................................
[...]
1362 | 2354 | .........................................

Et je me dis que le EVSS est un header de blob de data trop regulier pour etre honnete.
Je le passe dans la panoplie de toutes les cochonneries obfuscantes classiques... Je vous passe le processus, j'arrive a faire un test de ROT13 (decaler les lettres de l'alphabet de 13 lettres, c'est une transformation qui s'annule quand on l'applique deux fois), et... ca donne ? "RIFF". (Header de fichier AVI)
OH LE CON.
Quelqu'un a enchasse des fichiers AVI, 1362 fichiers AVI, dans une base de donnees.

Je regarde le contenu et ... du porn.
Je repete. DU PORN. DANS UNE DB MYSQL.
Il y a donc un genie, qui pour ne pas laisser trainer de fichier sur son poste, a mis tout son porn dans une DB redondee et bientot repliquee internationalement.

Le fichier est rassemblable de la facon suivante :

Code : Tout sélectionner

echo "SELECT blob FROM large_objects WHERE object_id = 5 ORDER BY block_id ASC" | mysql -h database | rot13 | mplayer -

Et voila, ton porn, directement en streaming. Depuis ton serveur de base de donnees.

Il va sans dire que la table a vole par la fenetre. J'ai decouvert que son auteur avait quitte la boite six mois plus tot. Sagouin.
Et gros degueulasse vu le contenu des fichiers. J'en ai regarde deux ou trois avant de tout bazarder sans garder de sauvegarde.

[DarkSoul]

Perso j'avais ouvert un ptit tumblr à gifsur le sujet mais ça fait un moment que j'y ait pas posté (et c'est fade en comparaison) mais si une anecdote particulièrement croustillante me revient à l'esprit, je viendrais vous la raconter

Who watches the watchers ? / Maintenant, oui.

http://fuckyeahtechinfo.tumblr.com/post ... gpo-fourbe <= Ah alors celle-la pour le coup, j'ai eu des exemples ou j'ai eu une prise de bec avec des Windowseux qui aimaient bien espionner les postes de certaines... ahem, "personnes d'interet" a mon precedent boulot.
-"T'as encore passe une GPO branlee comme de la merde pour espionner certains users."
-"Hein quoi mais non pas du tout qu'est-ce qui te fait dire ca ?"
-"Ecoute ducon t'as MEME PAS ECRIT LE NOM DU SERVEUR DE FICHIER COMME IL FAUT, j'ai un ecran '\\<DOMAN-CONTRLER>\audit\<AUDIT_CLIENT>.exe introuvable' qui poppe au login."
-"Euh c'est pas moi c'est un virus"
-"Et ca n'a vraiment rien a voir avec la circulaire pour approuver le budget pour <AUDIT_CLIENT> de ya deux semaines ?"
-"O_O COMMENT T'ES AU COURANT DE CA ??"
-"Maintenant, officiellement, oui. Merci."
-"..."

[DarkSoul]

http://fuckyeahtechinfo.tumblr.com/post ... e-je-dis-a <= encore un grand classique de quand on fait une modification en deux secondes et qu'on se banane comme une merde, et qu'on rollback en vitesse XD

[DarkSoul]

http://fuckyeahtechinfo.tumblr.com/post ... lot-et-que <= Sounds accurate a mon precedent boulot. XD

[Smog ShadowSeth]

En tant que dev, je n'ai pas autant d'histoires d'horreurs à raconter qu'un sysadmin ou un technos de maintenance, j'ai bien eu une période où j'ai tenté l'auto-entreuprenariat sans grand succès mais je n'ai rien vécu de trop "inhabituel" on va dire... Pourtant, il peut parfois arriver des absurdités sans nom dans le domaine, comme celle que je suis sur le point de vous raconter.

Le contexte, c'est mon moi de 2008-2009, a son premier emploi de dev web dans une PME marseillaise. La boite souhaitait se lancer dans l'aventure de la vente en ligne, et avait embauché à cet effet deux devs: un pas encore tout à fait ingénieur à l'époque, qui finissait ses études, et moi-même, modeste BTS qui sortait à peine des études. L'ingé était mon supérieur direct, qui en répondait directement au patron.

Après à peu près une année passée à développer le site, à le lancer et à recevoir les premières ventes, les commerciaux ont voulu étendre la clientèle potentielle en s’inscrivant comme vendeur auprès des grosses enseignes du web. Il a fallu développer des scripts pour pouvoir importer chaque jour les ventes effectuées en vue de les traiter. La tâche est répartie entre les deux devs, et je me retrouve à devoir traiter trois vendeurs, dont un très connu qui commence par "A", et deux autres, des français bien chez nous, pour le pire...

L'un d'entre eux utilise un système d'export vraiment... spécial. Les données des différentes ventes étaient transmises directement via une URL unique pour chaque vendeur partenaire (donc "en théorie" inaccessible à une tierce partie même si tout était transmit EN CLAIR. Bref.). On devait interroger l'url pour savoir s'il y avait une vente; si oui, elle nous redirigeait vers une autre url qui avait en paramètres les données de celle-ci. En retour, il fallait interroger cette url avec en paramètre une valeur confirmant que l'on avait bien récupéré les données de notre côté, après quoi on pouvait ré-interroger l'url de départ qui nous redirigerait vers la vente suivante, et ainsi de suite jusqu’à ce que l'url de transmission de données nous retourne des valeurs vides.

Rien de bien compliqué jusque là, sauf que... les données n'étaient pas transmises selon la structure de paramètres habituelle (?id=truc&nom=bidule&etc=etc), c'était une chaine de caractères concaténée directement à la suite de l'url avec un format propre au vendeur. Soit; il fallait juste faire des traitement sur la chaine de caractères récupérée de l'url pour en extraire les données, rien de grave, même si c'était quand même un peu relou de leur part de ne pas utiliser les standards intégrés.

Vient le moment du test du script sur le serveur de test de la boite. Après un peu de débug, le bousin tourne, et je pousse le script en prod tout en faisant une demande d'ajout à la cron table du serveur de prod, gérée par mon chef. Le lendemain de l'ajout du script à cette dernière, je fait un check rapide de la BDD de prod pour voir si des ventes venant de ce vendeur ont été ajoutées. Négatif. Il y en avait pourtant, et après vérification, le script n'avait renvoyé aucune erreur lors du traitement...
Je passe la journée sur ce problème avant de comprendre quelque chose d'absurde: le script tournait au poil sur le serveur de test, mais tournait dans le vide sur le serveur de prod. Les deux serveurs étaient pourtant sensés êtres identiques...

Sensés.

En creusant un peu, je découvre que le script fonctionne bien sur le serveur de prod jusqu'à un certain point: vous vous rappelez du formatage à la con du vendeur? J'étais obligé d'utiliser des fonctions très spécifiques pour pouvoir récupérer et décoder les données, et il s'avérait qu'une de ces fonctions renvoyait des champs vides sur le serveur de prod... mais pas sur le serveur de test. De plus, le noob que j'étais à l'époque n'avait pas pensé à vérifier si les champs traités n'étaient pas vides, et donc le script insérait ces champs vides en lieu et place des données des commandes, ce qui expliquait pourquoi le script ne bronchait pas sur le serveur de prod. Ah, et joie supplémentaire, comme ces commandes étaient marquées comme importées côté vendeur, il a fallu les insérer à la main dans la BDD pour pouvoir les traiter...

La question restait cependant: pourquoi cette fonction là foirait seulement sur le serveur de prod; en désespoir de cause, j'avais discrètement testé le script sur un serveur perso et là encore, pas de soucis...
Et puis j'ai eu l'idée d'aller voir les paramètres des deux serveurs via un bon vieux php_info()*. Et le premier truc qui me saute aux yeux? Déjà, aucun des deux serveurs PHP n'était à jour, ce qui craint quand même un peu dans le cas de celui de la prod, mais le meilleur, c'est que le serveur de prod avait plusieurs versions de retard par rapport au serveur de test.
Je regarde donc si par le plus grand des hasard, cette vielle version n'avait pas un bug sur la fonction critique de mon script, et bingo! Pile poil dans le cas de figure que j'avais!

La solution était donc simple: mettre à jour le serveur.

Sauf que... Le responsable marketing et le patron ne l'entendaient pas de cette oreille.

A savoir: comme nous étions des jeunes sur leur premier emploi, nous n'avions pas vraiment de droit d'initiative propre: nous devions soumettre chacune de nos actions à la hiérarchie qui approuvait ou refusait selon son bon vouloir; nous ne pouvions pas leur imposer une action même lorsqu'elle était nécessaire. Autre chose à savoir, à l'époque nous n'avions pas de sysadmin à proprement parler; le sysadmin en chef de la boite était un associé qui a décidé un jour que c'était mieux d'aller enseigner plutôt que de s'occuper de l'infra dont il avait la charge; la tâche est donc revenue à mon chef, qui était, je le rappelle, un dev, après que l'on ait épuisé plusieurs sysadmin "secondaires" dont le temps passé dans la boite se comptais au mieux en mois, au pire en jours.

Mon chef informe donc le responsable marketing que pour résoudre ce soucis, il va falloir mettre à jour le serveur, ce qui implique du downtime. Refus catégorique du marketing, qui craint de perdre des ventes même avec un délai de moins d'une heure. Et quand mon chef insiste un peu en soulignant que c'est quand même un risque de sécurité non-négligeable, le marketing court chercher le grand patron qui se range du côté du commercial: pas question de toucher au serveur, et tant pis pour la sécurité; après tout nous n'étions qu'une petite boite, donc pas une cible de choix pour des hackers, pas vrai? (*Screams internaly*)

Néanmoins, on nous a quand même imposé de trouver une solution alternative pour faire marcher le script d'import. Et à votre avis, qu'est-ce qu'on a fait?

Il ne marchait pas sur le serveur de prod. Mais par contre, sur le serveur de test...

Nous avons donc migré le script sur le serveur de test. L'entrée pour lui dans la cron table du serveur de prod a été pointée sur son emplacement sur le serveur de test. Et j'ai fait pointer la base de donnée du serveur de prod dans le script présent sur le serveur de test.
En des termes plus prosaïques: le script était lancé depuis le serveur de prod, exécuté sur le serveur de test et insérait les données récupérées sur le serveur de prod.

Bien entendu, ça a posé des soucis. Comme ce script était une exception, on l'oubliait souvent (et ne me parlez pas de doc... On ne pouvait pas en faire). Le serveur de test n'était par définition pas stable, ce qui fait qu'il était HS certaines nuits. Les scripts testés dessus étaient de temps en temps purgés, dont involontairement celui-ci, et il n'y avait pas de sauvegardes, pourquoi faire pour un serveur de test? (heureusement que j'avais l'habitude d'enregistrer tout mon travail en double sur ma session...) Et ça a été très rigolo quand, profitant d'un sysadmin qui ne savait pas encore où il avait mis les pieds, l'infrastructure informatique a été réorganisée (comment ça c'est plus le même nom sur le domaine pour le serveur de test? Meeeerde, le script!).

Bref. Un beau jour, la hiérarchie a fini par accepter qu'on mette le serveur de prod à jour, mais uniquement après avoir constaté que notre infra avait été piratée on ne sait trop pourquoi par des chinois, et qu'on a retrouvé des fichiers torrents managés depuis l'extérieur logés sur le serveur de prod... Mon départ de cette boite a été un peu houleux, mais en y repensant, non, je n'ai pas de regrets.

*: inb4 PHP c'est le mal.

Smog.

[Jaerdoster]

Oh god

Allez, j'ai moins flippant, mais flippant quand même une petite histoire que j'ai nommée:

Histoire 3: ERUPTION DU MONT VESUVE

Auto-entrepreneur, j'acceptais un peu tout pour faire des sous, y compris que l'on me dépose l'ordinateur a réparer chez moi, que je délivre un bon de réparation, et que le client revienne le chercher.

Un client m’appelle un jour pour ce type de service, en expliquant que son ordinateur s'étaient sans prévenir et fait beaucoup de bruit. Il me prévient de son passage, et m'amène sa tour bien rangée dans un carton, je signe le bon de réparation et je la sors du carton pour la coller sur mon bureau.

Et là, c'est le drame.

Je la sors du carton, la pose sur mon bureau, et BAM, ERUPTION DE MERDE GRISATRE

Vous le devinez parfaitement: de la CENDRE. le mec devait fumer à côté du PC.

Vous imaginez ça, partout dans le PC:


Une véritable horreur.

Du coup, dans une main l'aspirateur a une distance raisonnable, de l'autre la bombe a poussière, et on souffle en aspirant les cendres qui remontent. Après un démontage de l'alimentation pour nettoyer, nettoyage de tous les ventilos, un petit tour dans windows lui même pour virer les éevntuels malwares cachés et mettre à jour l'essentiel, il tournait du feu de dieu.

Le monsieur revient me voir le soir: "Ah, vous l'avez réparé ? Parfait. Si je peux me permettre, qu'est ce qu'il avait ?"
Et moi de lui répondre: "Vous devriez arrêter de fumer à côté de votre ordinateur, il avait un cancer du poumon."

[DarkSoul]

En tant que dev, je n'ai pas autant d'histoires d'horreurs à raconter qu'un sysadmin ou un technos de maintenance, j'ai bien eu une période où j'ai tenté l'auto-entreuprenariat sans grand succès mais je n'ai rien vécu de trop "inhabituel" on va dire... Pourtant, il peut parfois arriver des absurdités sans nom dans le domaine, comme celle que je suis sur le point de vous raconter.

Ah, joli, en effet. Le truc similaire que j'ai eu c'était à ma première boîte au Japon où les DB clients pour services mobiles étaient gérées avec... une chimère à base de CGI en perl sur un front-end Berkeley (l'équivalent "trois bouts de ficelle" pour une base de données, sans verrouillage ni protection anti corruption, mais argument du chef "mais, un serveur HTTP c'est plus rapide qu'un serveur SQL, enfin" -> *yirk* faut dire ils savaient pas écrire de requête SQL, un MongoDB leur aurait peut-être vraiment bien convenu), et qui exigeait une certaine version de perl (5.6), qui devenait de moins en moins compilable, et il fallait compter en plus une bibliothèque conçue par le chef-avant-qu'il-devienne-chef (à son crédit, utile pour son époque, mais dès 2006 c'était déjà foutrement dépassé), et que donc s'en débarasser c'était politiquement lui faire un bras d'honneur ce qui était impensable.

On a aussi du faire des trucs du genre pour traiter certaines données parce qu'il fallait que les datas soient process "par un perl version 5.6 patché custom avec la lib du chef un soir de pleine lune". Donc on a au final construit pas mal de trucs autour de ces serveurs "magiques" de conversion tournant sous FreeBSD 4.11, jusqu'à ce que je hurle à la mort et que je prenne son code C à la con pour le re-porter sous FreeBSD 6 et un compilo récent. C'était là le vrai début de ma carrière d'hybride sysadmin/dev.

[DarkSoul]

Oh god

Allez, j'ai moins flippant, mais flippant quand même une petite histoire que j'ai nommée:

Histoire 3: ERUPTION DU MONT VESUVE

Classe magnifique. Dans les alims, en PC perso, c'était il y a genre 15 ans, j'ai mon frère qui m'a fait voir ce que j'appelle...

Le bisou de Raiden/Zeus/Jupiter

Bon, je dis ça, mais ça se résume très simplement :
-"Euh, ya mon PC qui vient de s'éteindre sans prévenir, tu peux venir voir ?"
-"Hmm, ok. *clic*"
Je pose la main sur la carlingue, je tente de rallumer, et...
*BOOM*
L'alim m'explose au nez avec une décharge éléctrique, un éclair et de la fumée blanche, ce qui fait que par réflexe je m'éjecte après avoir eu une grosse frayeur comme si Raiden venait de me faire un combo XD

[s3phy]

http://fuckyeahtechinfo.tumblr.com/post ... e-je-dis-a <= encore un grand classique de quand on fait une modification en deux secondes et qu'on se banane comme une merde, et qu'on rollback en vitesse XD

Oh ça je replace quelques anecdotes comme ça :)

Du genre : Client demande qu'on lui installe la toute dernière version de PHP sur son serveur. La plus récente. La TOUTE dernière.
Ma réponse : Vous êtes sûr ? Vous êtes en 5.1.x, la dernière version est la 5.4.x, y'as eu de gros changements au niveau de PHP 5.3, êtes-vous sûr que votre site est compatible ?
Sa réponse : La dernière version je te dis !!! Et vite !!!

Bon... j'upgrade. Je teste le site du gars... Erreur 500. Direct sur la page d'accueil. Rollback discret et rapide...

Ma réponse : Je viens de faire des tests et je vous confirme que votre site n'est pas compatible avec PHP 5.4. Vous devriez demander à vos développeurs de vérifier la compatibilité. Dès qu'ils auront apporté les dernières modifications nécessaires, n'hésitez pas à nous recontacter pour effectuer cette mise à jour.
Sa réponse dans les minutes qui suivent : Tout est bon de notre côté, merci de faire la mise à jour IMMÉDIATEMENT vers la version de PHP LA PLUS RÉCENTE.

Bah OK. Je remet le PHP qui casse son site, l'informe de la mise à jour (screenshot d'un phpinfo(); à l'appui) et le remercie d'avoir choisi notre société.



Qui c'est qui a ouvert un ticket urgent quelques minutes plus tard parce que "oh mon dieu mon site est down faites quelque chose !!!!111" ?
(pas moi qui m'occupait des tickets urgents de toutes façons )


Un plus mignon de "je casse tout et je remet discrètement en place rapidement" : Une LAN party organisée dans mon école d'info, une centaine de joueurs présents, j'administre un pfSense pour manager les connexions internet des joueurs (ah oui c'est une LAN de nos jours, plus aucun jeu ne se joue en LAN, tout est online, les mecs pourraient jouer de chez eux ça changerait rien... fini le temps des parties de CS 1.3 sous Win 98 et du partage de fichiers jusqu'au remplissage des disques durs...). Bref l'école nous a imposé d'avoir un proxy pour logguer toutes les URLs que les joueurs on consulté. Avec pfSense 2.0.1, y'as une blague, le proxy Squid ne respecte pas les règles de traffic shaping qui lui sont appliquées. Dès que quelqu'un télécharge un fichier en HTTP, il arrive à saturer la connexion internet de la LAN, et ça fait ramer tout le monde. Du coup je suis en train de bricoler le paramétrage de Squid, et je clique, dans l'interface web de pfSense, sur "redémarrer Squid" histoire d'appliquer les changements. Le truc ne redémarre pas Clic sur démarrer le service. Rien ne se passe. Re-clic de l'angoisse. Toujours rien. Bon ça fait 30 secondes/1 minute là, ça va pas tarder les rageux "hey internet est down !"... Connexion en SSH, démarrage du service à la main... et ça se lance
Ce jour là j'ai appris que le bouton "redémarrer Squid" de l'interface web de pfSense ne fonctionne pas Il arrête mais il relance pas le service. Je crois que c'est toujours cassé sur la dernière version de pfSense


@ DarkSoul : purée l'injection SQL dans le CSV... magique ! Le FreeBSD mort-vivant ! Les 16 Go de porn dans une base SQL :D Génial.

[DarkSoul]

fini le temps des parties de CS 1.3 sous Win 98 et du partage de fichiers jusqu'au remplissage des disques durs...).

Nostalgie. ;_; Ceci me manque. Cruellement. AXEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEL T_T UNE AGC, VITE !

@DarkSoul : purée l'injection SQL dans le CSV... magique ! Le FreeBSD mort-vivant ! Les 16 Go de porn dans une base SQL :D Génial.

L'injection dans le CSV, c'est ce qui m'a fait comprendre que... Dans l'environnement où j'étais, à chaque tournant je faisais un spot check. Neuf fois sur dix, j'avais la preuve que j'avais raison de faire le spot check pour voir si j'allais me faire backstab ou non.

Pour le FreeBSD mort-vivant, j'en reviens pas de ma moule pour ça. Normalement, c'est "un aller au datacenter" (pas d'iLO/DRAC) et on réinstalle tout, un cas pareil.

Le porn dans la base SQL, ça m'a fait *cringe* mais c'est du génie pur. Je réutiliserai la manip pour obfusquer des échanges, clairement.

Je crois que c'est toujours cassé sur la dernière version de pfSense

Ah, je suis contributeur sur les packages de pfSense (j'ai surtout touché à Apache+mod_security dernièrement, vu que le package ne marchait juste pas, mais j'ai tableflip à cause du système de log (ou son absence, ce qui fait que ça remplit le disque) et j'ai tout migré à HAproxy), et j'ai vu passer plein de trucs sur Squid... En fait je pense surtout que ce sont les scripts de stop/start de pfSense qui sont merdiques. Pour Apache ce que j'ai déjà eu, c'est le cas où le restart ne marche pas parce que le port est toujours bindé => *PAF*.
Bon après squid l'autre gros souci c'est que la moindre modif exige un restart du bordel, et qu'il met une plombe à redémarrer -_-;