Les ordinateurs de l'HORREUR

Topic général, un peu bordélique, parfait pour accueillir toutes choses légères et sans prétention.

Modérateur : La Force Poissons

Avatar de l’utilisateur
DarkSoul
Membre En Mutation
Messages : 89
Enregistré le : Jeu Oct 13, 2011 2:50 am
Localisation : Japon, Tokyo

Re: Les ordinateurs de l'HORREUR

Messagepar DarkSoul » Mar Oct 11, 2016 2:58 am

Corsaire a écrit :
s3phy a écrit :De tous les choix y'en a que 2 qui sont cohérents avec ce que j'ai (y'en a que 2 avec Mansion dans le nom :redface:)… mais comment je sais si j'ai un Hikari Next ou un B FLETS ?

Au doigt mouillé tu peux tabler sur du Flets Next, le Bflets est en voie de disparition, on dégage des flopées de plages Ip régulièrement


Bah justement ca depend de a quel point la ligne est vieille...

Sinon, en cas de doute, tu peux toujours faire tester un type de ligne, puis faire verifier via le RADIUS quelle ligne c'etait reellement, et faire basculer si besoin via le customer support. Ca se fait en 5 minutes, et normalement ca n'influe pas sur le prix de l'abo AsahiNet.
0 x
Membre d'Epitanime depuis 2000 (EPITA Promo 2005 SRS)
Informaticien expatrié, traducteur à ses heures perdues

Avatar de l’utilisateur
DarkSoul
Membre En Mutation
Messages : 89
Enregistré le : Jeu Oct 13, 2011 2:50 am
Localisation : Japon, Tokyo

Re: Les ordinateurs de l'HORREUR

Messagepar DarkSoul » Mar Oct 11, 2016 3:00 am

spanner a écrit :Donc apple enchasse du binaire dans un format obscure, encode en base64, dans leur xml de configuration, tout ca pour stocker une simple couleur RGB :kanie:


La seule raison que je vois de faire ca, c'est que derriere tu as une API qui prefere manger directement le format binaire opaque, qui doit etre un format serialise d'objet. Et que du coup c'est plus rapide pour eux.
0 x
Membre d'Epitanime depuis 2000 (EPITA Promo 2005 SRS)
Informaticien expatrié, traducteur à ses heures perdues

spanner
Apprenti Thaliste
Messages : 7
Enregistré le : Mer Juin 15, 2016 7:47 pm

Re: Les ordinateurs de l'HORREUR

Messagepar spanner » Mar Oct 11, 2016 8:03 am

DarkSoul a écrit :
spanner a écrit :Donc apple enchasse du binaire dans un format obscure, encode en base64, dans leur xml de configuration, tout ca pour stocker une simple couleur RGB :kanie:


La seule raison que je vois de faire ca, c'est que derriere tu as une API qui prefere manger directement le format binaire opaque, qui doit etre un format serialise d'objet. Et que du coup c'est plus rapide pour eux.


A priori c'est bien ca (on retrouve NSKeyedArchiver aussi, qui " provides a way to encode objects" selon la doc apple), le truc con, c'est que iterm2 fait le truc plus proprement (avec le meme format de % r/g/b entre 0 et 1), et que terminal.app doit anyway parser le xml pour recuperer l'objet serialise, pas sur que ca fasse une grande difference au final, cote code...

Code : Tout sélectionner

   <key>Ansi 1 Color</key>
   <dict>
      <key>Color Space</key>
      <string>sRGB</string>
      <key>Blue Component</key>
      <real>0.011764705882352941</real>
      <key>Green Component</key>
      <real>0.01568627450980392</real>
      <key>Red Component</key>
      <real>0.8</real>
   </dict>


Je penche pour un truc legacy des premieres versions d'OSX qui a jamais ete change (type "a l'epoque t'avais pas <real>to</real>")... c'est quand meme pas mal con parceque du coup c'est une horreur de mettre un color scheme sur terminal.app, ce qui explique probablement pourquoi on retrouve beaucoup moins de configs dispo pour terminal.app que pour iterm2 ou autres... (pour pas taper que sur apple, c'est pas les seuls, gnome terminal, c'est un script shell de 120 lignes pour utiliser gconf/dconf)
0 x

Avatar de l’utilisateur
Corsaire
Début de la gloire
Messages : 21
Enregistré le : Ven Fév 06, 2015 7:16 am

Re: Les ordinateurs de l'HORREUR

Messagepar Corsaire » Mar Oct 11, 2016 11:15 am

DarkSoul a écrit :Bah justement ca depend de a quel point la ligne est vieille...

Sinon, en cas de doute, tu peux toujours faire tester un type de ligne, puis faire verifier via le RADIUS quelle ligne c'etait reellement, et faire basculer si besoin via le customer support. Ca se fait en 5 minutes, et normalement ca n'influe pas sur le prix de l'abo AsahiNet.

A bien y réfléchir il me semble d'ailleurs que la transition sur higashi nihon est terminée car on a plus de double enregistrement à faire comme avant.
Donc tu peux tabler sur Next assez tranquille je pense.
0 x
Un poing vaut mieux que deux "j'te préviens..."

Avatar de l’utilisateur
s3phy
Tenace
Messages : 68
Enregistré le : Mar Déc 30, 2014 4:54 pm
Localisation : Shinjuku

Re: Les ordinateurs de l'HORREUR

Messagepar s3phy » Mer Oct 12, 2016 1:21 pm

Bon ben ça marche avec Hikari Next :D

Et ça va vite !

Merci à tous les deux :)
0 x

Avatar de l’utilisateur
DarkSoul
Membre En Mutation
Messages : 89
Enregistré le : Jeu Oct 13, 2011 2:50 am
Localisation : Japon, Tokyo

Re: Les ordinateurs de l'HORREUR

Messagepar DarkSoul » Sam Jan 14, 2017 2:52 pm

Nouveau post avec la nouvelle année.

Windows en frontal, prepare for anal

D'abord, commençons par un petit poème :

Code : Tout sélectionner

Malware du matin, chagrin
Snapshot du soir, espoir
User crétin, chagrin
Password dictionnaire, moi vénèr


On s'est pris un ransomware because... On s'est fait faire le cul d'un serveur applicatif (un vieux service qu'on fournit depuis l'aube du 21e siècle) qui avait :
- Des IPs publiques en façades sur un VLAN spécial (sans firewall matériel !) :yoshitake2:
- Un RDP ouvert parce que on a un partenaire tiers qui administre le système :mio2:

Et on finit avec un serveur qui affiche une page web de rançon et il faut contacter par email et si on prend trop de temps le prix va monter blablabla. :sue:

On a donc eu la frayeur du siècle parce que deux machines sur ce réseau se sont faites ransomwariser, et que c'était une espèce d'intranet / calendrier pour plus d'une centaine de clients. DIEU MERCI on avait virtualisé et le stockage c'était du NetApp avec des snapshots du coup on a pu rollback proprement et sans casse. Sérieusement, snapshots et backups, vous sauvez des vies tous les jours et énormément de pognon. :mion:

Et là je réalise qu'un des postes touchés a une patte sur ... LE FUCKING RESEAU DE MANAGEMENT @#%! pour faciliter justement sa gestion. :shouko: Encore une fois, SANS FIREWALL. :mio2:

Ou plutôt non, attendez, c'est plus drôle : il y avait un firewall. Le firewall Windows. Le gag ? On avait supposément mis une règle pour dire "RDP accessible uniquement depuis telle IP" mais la vérification pour cette rule et son application avaient été oubliées. Ceci pose une autre question horrible : COMMENT ON A FAIT POUR TENIR AUSSI LONGTEMPS ? :pokerface: (apparemment quelques années)

Et là je me mets à baliser sur le vecteur d'infection et l'intelligence du gars. Dieu merci encore, c'était un système assez vieux pour dater d'avant la mise en place d'AD au sein de la boîte et ce service n'avait rien à faire dessus donc il n'avait jamais été mis sur un domaine, il tournait en workgroup. :moffle2:

Ceci fut bien et à la fois pas bien :
- Bien : même infecté, va te faire foutre pour te logger sur un serveur linké à AD. Au moins c'est pas openbar.
- Pas bien : On a découvert que le vecteur d'infection était un user "cifs" utilisé sur le serveur applicatif ET sur un autre serveur qui servait de NAS (partage réseau), et avec un mot de passe vulnérable. :fu:
- PAAAAAS BIEN : ...Ce compte était dans le groupe admin sur le serveur applicatif et le NAS, ET avait les privilèges RDP. :tamako: Dieu merci la DB (MSSQL Server 2005) n'avait cet user que en user ordinaire. :hiyoko:

Mesures prises :
- Analyse forensic comparant le snapshot "une heure avant" avec "l'image infectée", on a découvert un truc sur l'infectée et pas sur le "une heure avant" donc on peut raisonnablement espérer qu'on a évité le pire :coach:
-- J'ai QUAND MÊME suggéré "dans le doute, on désintègre tout et on reconstruit au passage en Win2012 tant qu'on y est" :feu:
- On va étudier la construction d'un domaine spécifiquement pour ce service. Je refuse de me taper la gestion manuelle d'un user sur 4~5 serveurs comme ça. On est dans un cas à la con où un workgroup ferait bien l'affaire, mais où on a besoin d'une feature du domaine. Aussi si on fait un domaine, relation de trust à sens unique bien sûr.

À votre SAN-té, nous ne tenons pas nos Promesses pour la nouvelle année !

Et le lendemain de l'affaire ci-dessus ? Il y a un autre service au boulot qui tombe complètement en rade.
Symptomes : le monitoring Nagios secondaire de ce système ne remonte plus aucune alerte au Nagios principal, et c'est ainsi fait que au bout de 10 minutes sans updates, le Nagios principal fait tout passer en UNKNOWN "Stale information".

Je me fais réveiller par un appel paniqué de l'admin d'astreinte, et je pense d'abord à un souci de réseau :
- "OK, rapport de situation s'il te plaît" :coach:
- "Ben j'ai voulu regarder la VM du Nagios secondaire mais le vmhost est aussi dans les choux" :medusa:
- "OK... Et si le Nagios primaire réagit comme ça, c'est que le secondaire est mort ; ce serait pas un souci réseau des fois ? Tu as check la gateway pour le datacenter pour ce projet ?" :rin3:
- "Ah j'avais pas pensé merci... Ben non elle est up" :saki2:
- "... ._O Bon attends je sors mon laptop et j'arrive sur IRC, on va continuer en direct" :yuyushiki:

Je remarque que absolument tout ce quadran du réseau est apparemment down, mais pas certains équipements d'admin (KVM, PDU, firewall) ou autres. Par contre tout ce qui est VMs et serveurs physiques, presque tous down. :misaka2:

Presque tous. :mion:

Certains (physiques comme virtuels) me laissent me connecter en RDP, et j'ai un écran noir. :pokerface:
Et là je réalise avec horreur. :keuwa:
Le serveur est up, l'OS aussi mais a perdu presque toutes ses fonctions. :yuno:

Certains serveurs étaient conçus pour tourner indépendamment, et eux fonctionnaient pépère sans interruption. Bon c'est déjà ça. Le plus gros du service est toujours fonctionnel. :fuckyea:

Je chope le fichier zone du réseau en question pour choper l'IP du KVM et j'ignore l'avertissement SSL de "gros porc tu m'as accédé avec l'IP et pas le nom", et je vois que la majorité des serveurs physiques a effectivement rebooté. Vu qu'ils bootent en iSCSI, je vois l'écran de négociation avec le SAN... Et je vois que ça devrait booter, et l'écran avec le petit curseur qui clignote... Qui clignote... Qui clignote... :azusa2:

Et qui devrait virer au logo bleu de Windows 2012 qui boote, mais qui n'y vire jamais, et au bout de 5 minutes, je vois le serveur tenter de booter en PXE. :yuno:

Et là je vais regarder nos graphes de monitoring, notamment le storage, qui semble pourtant up selon les critères classiques. Et je vois CECI. :death: :homer:

Image

Notez que l'unité est en OCTETS. Et que le réseau est ainsi fait que le storage peut prendre 20Gbits/s.
Le truc tente donc de me dire qu'il a transféré sur un volume logique 12GB/s, soit 100Gbits/s. :misaka2: IMPOSSIBURU. :non:

Mais j'ai vu un symptome bien plus choquant en regardant les graphes (voici un extrait que je viens de choper pour expliquer) :
Image

En gros à un moment le storage cesse de débiter la moindre donnée. Confirmé aussi sur les switches (et bien sûr aucune trace du mystérieux pic de soi-disant transfert).

Bref, le storage répond, permet de se logger en iSCSI, mais ne répond aucune donnée. :homer:

Avec mon chef, on tente de rebooter un contrôleur, et ça freeze absolument tout. Il cesse de répondre, au ping, au SNMP, à tout (alors que jusque là on avait encore le SNMP pour surveiller la température, l'état du matos etc...)

- "Reboot contrôleur 1, paré ?" :coach:
- "Go. On a que ça à faire." :coach:
- "Euh. Ping lost. SSH lost. SNMP lost. Aucune réaction. He's dead Jim." :loose:
- "On attend un peu des fois qu'il reboote." :yukino4:

Dix minutes plus tard...

- "Non c'est pas normal, lors de l'update de firmware, le management avait eu zéro downtime et en tout ça avait pris cinq minutes..." :yukino4:
- "...Merde." :tokiomi:
-" Bon, on passe au reboot éléctrique." :akiho:

Un reboot éléctrique plus tard, et...

- "Ping, up ; SSH, up ; SNMP, up ; Les serveurs arrivent à booter dedans ; VMware a repris la main aussi."
- "Bon maintenant damage assessment... Toutes les VM sont bonnes pour un reboot, les Linux ont du basculer en read-only. Les Windows..."
- "Ok les Linux c'est facile, on les reboote avec les VMtools en masse. Reset pour les récalcitrants qui ont perdu leurs VMtools. Les Windows..."
- "Ouais, va falloir se logger et chkdsk tout." :non:

Avec le staging et la prod, ça fait trente bécanes où il faut se logger, chkdsk c:, plus tous les disques de cluster et autres, et faire basculer le cluster pour réparer le node actif. Dieu merci il y a juste eu quelques pets genre fichiers temporaires écrasés, et espace libre mal déclaré.

Et là je chope un des serveurs (dieu merci un de ceux qui sont en pool et interchangeables), je note qu'il est bloqué et ne répond pas au reboot via le KVM. Je coupe le courant via la PDU, je relance... Et je remarque que là où les autres bouffent 40W, lui ne bouffe que 7W. Il est en alimentation minimale, mais il n'arrive pas à se rallumer.

- "PUTAIN le serv web #1 est down et ne revient pas" :fu:
- "Comment ça il revient pas ? O_o" :tokiomi:
- "Alimentation éléctrique minimale, négocie sur le switch avec 100Mbps, on dirait que le chipset n'arrive même pas à s'initialiser, je n'ai même pas le signal VGA" :kiddingme:
- "T'es en train de me dire que l'accident a EN PLUS niqué un serveur physique ?" :serious:
- "Ben visiblement oui..." :kiddingme:

Après quelques heures de chkdsk acharné et de jonglage de cluster (deux clusters MSFC, un pour le core d'appli et un pour sa DB), on est revenus dans l'ordre.

On notifie le fabriquant, un minimum colère quand même mais bon on va être poli. :ringo3:
Et là on a pour réponse "J'ai vu le product leader il a mis ça dans sa file d'attente." Wait are you fucking SERIOUS ? :serious:



D'ailleurs gag le matos a remis ça hier.

Vendredi à 17H20. :tamako:

Je regarde Nagios et je vois que plein de trucs virent UNKNOWN "Stale information" concernant ce service. :keuwa:
Oh non. :tokiomi:
OH NON. :creeper:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH :shinji:

- "CHEF ! Regardez vite le Nagios je crois qu'il nous a remis ça" :fu:
- "Hein quoi ?" :shiori:
- "Storage toujours up, mais traffic data tombé à zéro..." :yuno:
- "Et c'est arrivé quand ?" :mio2:
- "Ben y'a quinze minutes..." :yuno:
- "Merde..." :non:
- "Reboot éléctrique ? (après avoir get le service report)" :coach:
- "Reboot éléctrique." :coach:

Rinse, wash, repeat. On a réalisé bien plus vite ce qui se passait et réagit, alors certaines machines ont quand même survécu à ça (Apparemment si on reboote le storage Windows tient cinq bonnes minutes sans même faire un I/O error o_o), mais le recovery a quand même bien pris trois-quatre heures parce qu'on ne peut juste pas se permettre de se rater et se dire "bah tout va bien" après ça. Après, un mail bien senti au fournisseur avec "NON, on ne peut pas attendre, OUI c'est critique et si ils peuvent rien faire on casse le contrat et on met un NetApp à la place"

On a eu une réponse pour le moment. Le fabriquant, PROMISE, ne sait pas encore à l'heure qu'il est d'où vient le bug et n'arrive pas à le reproduire, et il nous conseille si ça se reproduit, pour le log de debug "de débrancher les cables du réseau iSCSI, et de mettre une clé USB sur le port de l'appareil" ... Oui sauf que l'appareil est en datacenter à 30 minutes :/ Enfin on peut s'en sortir en coupant immédiatement le traffic via le switch pour ne pas noyer les logs avec des erreurs iSCSI, puis foncer au datacenter mettre la clé USB pour récupérer le log complet -_-;

On soupçonne une mise à jour de firmware d'être responsable, donc à la prochaine merde on tente de récupérer le log et on downgrade.
Modifié en dernier par DarkSoul le Sam Fév 18, 2017 2:07 am, modifié 2 fois.
0 x
Membre d'Epitanime depuis 2000 (EPITA Promo 2005 SRS)
Informaticien expatrié, traducteur à ses heures perdues

Avatar de l’utilisateur
DarkSoul
Membre En Mutation
Messages : 89
Enregistré le : Jeu Oct 13, 2011 2:50 am
Localisation : Japon, Tokyo

Re: Les ordinateurs de l'HORREUR

Messagepar DarkSoul » Sam Jan 14, 2017 3:58 pm

Ah et je réalise que j'avais oublié un très joli morceau.

Pour mon malheur, ces serveurs physiques sont des machines avec des specs plutôt grosses (2 CPU, 8 cores en tout et 32GB de RAM), mais cheap et donc en contrepartie pas d'iLO donc de console à distance ou contrôle de l'éléctricité. Pas grave, on avait acheté un PDU et un KVM pour ça. :coach:

(Au final avec le prix du KVM et des PDU Raritan... on se demande où est l'économie. :mio2: )

Sauf que souci ? :shiori:
Le BIOS est réglé par défaut pour "conserver le dernier état" en cas de perte du courant. Ce que ça veut dire ? Prenez un serveur qui a foiré son boot en iSCSI et qui a pris un boot recovery Windows. Si vous avez eu le malheur de vouloir en sortir en appuyant sur la seule option à portée, à savoir "Shut down", eh bien vous êtes proprement niqué. :non:

Votre serveur ne repartira jamais par lui-même. :hirano:

Le boot iSCSI est aussi toute une horreur à lui seul, normalement on se dirait qu'on peut configurer le DHCP pour passer les paramètres (en mettant ça dans une DB ou un LDAP) et vogue la galère. Que nenni. Si vous faites ça, vous risquez de n'avoir le boot iSCSI qui ne marche qu'une fois sur trois (de mon expérience). :fu:

La raison pour laquelle on fait du iSCSI avec ces serveurs ? Parce que dedans c'est un bête contrôleur Intel SATA avec du faux RAID. Et si vous n'avez jamais eu à gérer ça, alors soyez bénis et faites tout pour le fuir comme la peste. Ce pseudo-RAID est en réalité géré par le BIOS pour donner un coup de pouce pour accéder au boot record, mais :
- Il ne couvre que très mal les cas de dégradation et de boot pendant une dégradation :pokerface:
- Il ne couvre pas les cas de pourrissement silencieux des données :lied:
- C'est que des emmerdes si il faut transvaser les disques sur un autre OS :fuckthat:
- Il n'y a pas d'outil de monitoring digne de ce nom (contrairement à mdadm sous Linux, ou tout contrôleur RAID matériel) :serious:

Bref, les serveurs ont des disques locaux mais j'ai désactivé le contrôleur dans le BIOS, et j'ai configuré l'iSCSI à la main (deux NICs, une NIC sur le portail 1, une NIC sur le portail 2, chaque NIC sur un switch différent stacké, et pouf on a du iSCSI redondant). Et là ça marche parfaitement... :akiho:

Enfin, quand le storage ne part pas en vacances sans prévenir. :araragi:
0 x
Membre d'Epitanime depuis 2000 (EPITA Promo 2005 SRS)
Informaticien expatrié, traducteur à ses heures perdues

Avatar de l’utilisateur
QCTX
Fait partie du paysage
Messages : 126
Enregistré le : Lun Mar 30, 2009 12:44 am
Localisation : RP

Re: Les ordinateurs de l'HORREUR

Messagepar QCTX » Dim Jan 15, 2017 2:49 pm

Et la direction, elle comprend que faut plus lésiner sur les tarifs des licences ILO quand tu lui remonte les frais du KVM + PDU + heures supp sur la restauration ? Non parce que au bout d'un moment faut pas déconner non plus.
0 x
Image

Avatar de l’utilisateur
DarkSoul
Membre En Mutation
Messages : 89
Enregistré le : Jeu Oct 13, 2011 2:50 am
Localisation : Japon, Tokyo

Re: Les ordinateurs de l'HORREUR

Messagepar DarkSoul » Dim Jan 15, 2017 3:37 pm

QCTX a écrit :Et la direction, elle comprend que faut plus lésiner sur les tarifs des licences ILO quand tu lui remonte les frais du KVM + PDU + heures supp sur la restauration ? Non parce que au bout d'un moment faut pas déconner non plus.


Alors en fait, c'est quand même plus compliqué que ça. Il faut savoir que tout le département technique, moi le premier, avons dit "euh on est VRAIMENT obligés d'utiliser ces serveurs ?" après avoir regardé la tête du matos, les specs et tenté de l'utiliser/configurer (D'ailleurs ils ont PAS de carte iLO _du tout_, c'est même pas une question de licence ; OUI, ça existe encore, des serveurs sans iLO)

Et ça a fini comme suit : "Ben, ils ont supposément de l'expérience dans ce domaine, avec un design qualifié et éprouvé, donc pour commencer on va utiliser ce design. Si y'a une merde dans les débuts, on pourra leur taper dessus vu qu'on a une garantie, et puis quand on y arrivera par nos propres moyens, on prendra autre chose. Mais faut dire que leur truc est vraiment pas cher"

En fait, on voulait monter notre solution et ce fournisseur s'est ramené et accroché à l'affaire et a vendu son design, ses serveurs et son matos, et ils ont même tenté de fourguer une solution API chaperonnant le tout sauf que on a dit "NOPE" quand on a compris qu'ils avaient reverse engineer pas mal de trucs et que 1) ça nous mettrait mauvais avec le fournisseur du logiciel 2) c'était beaucoup plus clean de faire faire une API avec le fournisseur pour ce qu'on voulait.

Du coup on les a gardés comme fusible si toute cette affaire merdait, c'est une décision politique faite en connaissance de cause. (Perso, avoir cette garantie fait que j'ai pu faire pas mal de trucs avec moins de pression, donc je comprends parfaitement le caractère politique ; et la merde majeure là c'est la première en un an et demi)

Si tu veux le détail de leur matos :
- Leurs serveurs 1U, je me demande si on se porterait limite pas mieux avec des VM, franchement, vu les emmerdes de monitoring physique (pas "chiant" mais voilà on devrait pas avoir à y penser) et de contrôle (évidemment "très chiant" quand il y a une merde). Même si ils ont des specs assez overkill genre 8 cores et 32GB de RAM, et que quelque part je suis pas mal de l'école de pensée que "le plus critique (lire : qui doit genre planter en DERNIER) on virtualise pas", je trouve que l'absence de RAID1 hardware sur ce matos est rédhibitoire (surtout sous Windows ; sous Linux avec un mdadm on peut commencer à discuter).
- Leurs serveurs 2U qu'on utilise pour du recording, il y a genre 8TB de stockage dedans, et c'est "pas trop mal foutu" (genre ils ont optimisé les perfs du contrôleur pour l'enregistrement continu et le rebuild blablabla) mais avec les mêmes défauts pour le monitoring et le contrôle. La plus grosse différence c'est qu'il y a du RAID hardware dans le bordel donc c'est bien plus bitable à utiliser, ça fait que l'OS et l'enregistrement peuvent continuer même si tout le reste se banane (prouvé ces deux dernières fois) ; Mais ça force à set un KVM et une PDU pour les raisons plus haut, donc on se demande si y'a quand même pas mieux comme serveur, mais ce sera forcément plus cher.
- Leur storage, y'aurait pas eu l'incident qu'on a là... Il se fait pas trop entendre, ça va. Un petit peu poussif à mon goût mais ils l'ont qualifié au départ que pour servir de shared storage pour le serveur SQL clusterisé, et pour le cluster de l'appli elle-même (qui a du coup besoin d'un quorum drive); et on s'en sert pour booter les 1U en iSCSI... (Bon tu me diras je raisonne que : si le storage tombe, tout tombe, donc de toute façon ça rend pas la dépendance fondamentalement plus critique) Et aussi comme datastore pour nos VM (ça, c'est plus problématique je pense, mais vu qu'ils nous ont refourgué un array de 16TB on s'est dit "on va l'utiliser")

Bref, les 1U vont finir virtualisés, les 2U, on va sans doute remplacer pour la génération suivante par autre chose, et le storage si ça merde trop on va foutre du NetApp mais bobo la facture. On va peut-être passer à deux tiers de storage pour le critique et le pas critique.
0 x
Membre d'Epitanime depuis 2000 (EPITA Promo 2005 SRS)
Informaticien expatrié, traducteur à ses heures perdues

Avatar de l’utilisateur
s3phy
Tenace
Messages : 68
Enregistré le : Mar Déc 30, 2014 4:54 pm
Localisation : Shinjuku

Re: Les ordinateurs de l'HORREUR

Messagepar s3phy » Mar Jan 17, 2017 7:16 am

DarkSoul a écrit :- "On attend un peu des fois qu'il reboote." :yukino4:
Je connais tellement ce moment :yoshitake2:

DarkSoul a écrit :On a eu une réponse pour le moment. Le fabriquant, PROMISE, ne sait pas encore à l'heure qu'il est d'où vient le bug et n'arrive pas à le reproduire, et il nous conseille si ça se reproduit, pour le log de debug "de débrancher les cables du réseau iSCSI, et de mettre une clé USB sur le port de l'appareil" ... Oui sauf que l'appareil est en datacenter à 30 minutes :/
Vous avez pas une presta Hands & Eyes du datacenter pour ça ? Même si je suppose que ça coûte une burne, pour ce genre de situation ça serait justifié…

DarkSoul a écrit :(Au final avec le prix du KVM et des PDU Raritan... on se demande où est l'économie. :mio2: )
Putain j'avoue…

DarkSoul a écrit :La raison pour laquelle on fait du iSCSI avec ces serveurs ? Parce que dedans c'est un bête contrôleur Intel SATA avec du faux RAID.
Image
J'ai touché à cette merde une fois y'as déjà pas mal d'années, chez un pote avec un serveur @ home, où on avait foutu 6 disques 1 TB (ou 500 GB, je sais plus, ça remonte, 2008 par là ?) en RAID 5, en se disant que ça serait une bonne idée (plus jamais je met autant de disques dans un RAID 5), et que ça serait aussi une bonne idée d'utiliser le contrôleur RAID de carte mère, après tout, si y'as un RAID " " " matériel " " " autant l'utiliser ?

Ha.

Haha.

Au premier disque qui a lâché on a découvert que le bouzin pour faire marcher le fakeraid/hostraid sous Linux à l'époque était incapable de rebuild du RAID 5. Sérieusement. Le truc (c'était comment déjà… ha dmraid !) pouvait lire, écrire sur un RAID 5 existant, mais pas le rebuild. :tiramie:

On a passé quelques mois misérables à avoir tous les disques qui lâchent les uns à la suite des autres (des Seagate 7200.10 ou .11, quelle bonne série… :tiramie: ) et à devoir booter sous un Windows pour rebuild, rebuild qui merdait aussi la plupart du temps. Puis on est passé au soft raid avec md, et on a plus jamais eu de problèmes :kyou:

quote="DarkSoul"]- Il n'y a pas d'outil de monitoring digne de ce nom (contrairement à mdadm sous Linux, ou tout contrôleur RAID matériel) :serious: [/quote]Alors j'ai pas testé MAIS à c'que j'ai lu… les versions récentes de mdadm savent maintenant gérer les opérations de base avec un Intel Matrix Storage, à priori de manière suffisamment fiable pour que des gens utilisent ça. Je suis pas vraiment sûr de vouloir essayer :|
0 x

Avatar de l’utilisateur
DarkSoul
Membre En Mutation
Messages : 89
Enregistré le : Jeu Oct 13, 2011 2:50 am
Localisation : Japon, Tokyo

Re: Les ordinateurs de l'HORREUR

Messagepar DarkSoul » Mar Jan 17, 2017 8:13 am

s3phy a écrit :Au premier disque qui a lâché on a découvert que le bouzin pour faire marcher le fakeraid/hostraid sous Linux à l'époque était incapable de rebuild du RAID 5. Sérieusement. Le truc (c'était comment déjà… ha dmraid !) pouvait lire, écrire sur un RAID 5 existant, mais pas le rebuild. :tiramie:


Oui, j'ai eu exactement la meme surprise en 2009 avec le RAID qui contenait ... mon stock de rapports financiers. Et rien de valeur ne fut perdu~

On a passé quelques mois misérables à avoir tous les disques qui lâchent les uns à la suite des autres (des Seagate 7200.10 ou .11, quelle bonne série… :tiramie: ) et à devoir booter sous un Windows pour rebuild, rebuild qui merdait aussi la plupart du temps. Puis on est passé au soft raid avec md, et on a plus jamais eu de problèmes :kyou:


Idem~

DarkSoul a écrit :- Il n'y a pas d'outil de monitoring digne de ce nom (contrairement à mdadm sous Linux, ou tout contrôleur RAID matériel) :serious:
Alors j'ai pas testé MAIS à c'que j'ai lu… les versions récentes de mdadm savent maintenant gérer les opérations de base avec un Intel Matrix Storage, à priori de manière suffisamment fiable pour que des gens utilisent ça. Je suis pas vraiment sûr de vouloir essayer :|


Oui, mais la je parle du FakeRAID sous Windows :( Meme les volumes dynamiques/miroir n'ont pas de fonction de monitoring facilement accessible... Du coup c'est juste pas une option.
0 x
Membre d'Epitanime depuis 2000 (EPITA Promo 2005 SRS)
Informaticien expatrié, traducteur à ses heures perdues

Avatar de l’utilisateur
DarkSoul
Membre En Mutation
Messages : 89
Enregistré le : Jeu Oct 13, 2011 2:50 am
Localisation : Japon, Tokyo

Re: Les ordinateurs de l'HORREUR

Messagepar DarkSoul » Mar Jan 17, 2017 8:25 am

Autre petite horreur recente avec mon ZFS a la maison en France :
- Fin d'annee, il y avait un disque qui battait de l'aile -> Bon bah je vais commander un disque pour faire livrer en France, et le faire remplacer par le paternel, business as usual :coach:
- On a manque de temps du coup avec les fetes on a repousse le remplacement, apres tout c'est que le NAS qui contient certaines photos (pas la seule copie) et une des repliques de mes data critiques (marrant comme ca sonne un peu comme Horcrux~) :kira:
- Du coup on a tente ce WE et on a decouvert que y'a d'autres disques qui battent de l'aile :keuwa: et apparemment un faux contact en plus avec les cables. :fu: Du coup grosse frayeur et deux disques endommages visiblement. :bioshocked: Le souci c'est que c'est au point ou ZFS refuse de demarrer l'array meme avec trois disques branches sur les 4 :non: (va savoir si les read errors y sont pour quelque chose, cela dit) :tokiomi:
-> Moralite : un remplacement de disque, ca se fait *VITE*. On ne le repetera jamais assez. :yuno:
- Du coup, conclusion, achat d'un disque de plus et d'un dock, et en attendant on met le bordel en stase cryogenique... :sad:
- A dix mille bornes la maintenance remote hands c'est chiant :mio2:
- Des que le matos arrive, ca va finir avec un ddrescue sur les deux disques abimes, on transfere les donnees, on bazarde les vieux disques et on fait croire a l'ensemble que "rien n'a change tout va bien". :rin2:
0 x
Membre d'Epitanime depuis 2000 (EPITA Promo 2005 SRS)
Informaticien expatrié, traducteur à ses heures perdues

Avatar de l’utilisateur
s3phy
Tenace
Messages : 68
Enregistré le : Mar Déc 30, 2014 4:54 pm
Localisation : Shinjuku

Re: Les ordinateurs de l'HORREUR

Messagepar s3phy » Mar Jan 17, 2017 8:35 am

Tiens quitte à parler HostRaid/FakeRaid j'ai une autre anecdote à ce sujet… je pensais que cette merde avait disparu y'as des années, mais ça m'est retombé dessus y'as tout juste deux ans, quand je me suis acheté pour faire serveur @ home un HP Proliant MicroServer Gen8

Le MicroServer Gen8 c'est ceci :

Image
Image

Et cette petite machine c'est de l'or en barre pour les geeks qui veulent se bricoler un petit serveur à la maison. HP l'a conçu à la base pour les TPE/PME, ça a pas vraiment marché, par contre les enthousiastes du serveur à tout faire à la maison l'ont découvert et s'en sont emparés. Faut dire que voyant que ça se vendait pas à la cible initiale, y'as des gens chez HP qui ont oublié d'êtres cons et qui ont permis à certains revendeurs de le brader, résultat on le trouve depuis environ 2 ans dans les 200€ sur Amazon https://www.amazon.fr/Computer-HP-Micro ... B00DDIC1DA (j'ai payé le mien 218) https://www.amazon.fr/Hewlett-Packard-E ... B013UBCHVU , sans les disques durs, mais avec CPU et RAM (aujourd'hui 4GB, 2GB quand je l'ai acheté). Y'as toute une communauté d'utilisateurs sur certains forums (Hfr ou HomeServerShow notamment), le machin supporte le VT-d (mais pas le CPU fourni avec, mais tous les forums on la liste des CPUs compatibles (HP proposait un certain Xeon d'origine pour beaucoup plus cher) si on veut s'amuser à foutre genre un ESXi sur ce truc), etc.

À ce prix là on a un serveur avec un tout petit format, avec 4 emplacements 3,5", deux interfaces réseau gigabit… et l'iLO !

Tout semble parfait pour mon usage… mais après avoir lu quelques pages de topic sur les forums… je découvre que… le chipset RAID HP, sur la carte mère de ce serveur… un HP B120i… est un contrôleur FakeRaid :kanako2:

Quel est le con qui est allé foutre du HostRaid dans un contrôleur RAID d'une gamme serveur ?!!! :ringo3:

Bon, pas grave, suffit dans le BIOS de foutre le contrôleur en mode AHCI/SATA, et si on veut du RAID, le gérer logiciellement avec md ?

C'est le tout premier réglage que j'ai bien entendu changé dans le BIOS…

… et au redémarrage, le ventilateur du serveur accélère, accélère, et y'as vraiment pas moyen de ne pas l'entendre. Wat. Jusque là la machine était incroyablement silencieuse, c'était même surprenant pour du matos serveur ?!

En fait, le BIOS ne sait lire la température des disques durs qu'à travers le contrôleur RAID. Et du coup, avec le contrôleur RAID désactivé, vu que le BIOS n'a pas de visibilité sur la température des disques, il empêche le ventilateur de descendre en dessous d'un certain %age de vitesse. :kobato:


Bon, une mise à jour du BIOS fin 2014 a permis de réduire cette vitesse mini à beaucoup plus faible, du coup avec les dernières mises à jour, le machin est presque parfaitement inaudible dans un usage domestique. J'voulais juste raconter comment je me suis retrouvé face à du FakeRaid là où je ne m'y attendais pas :minorin3:
Modifié en dernier par s3phy le Mar Jan 17, 2017 10:13 am, modifié 1 fois.
0 x

Avatar de l’utilisateur
DarkSoul
Membre En Mutation
Messages : 89
Enregistré le : Jeu Oct 13, 2011 2:50 am
Localisation : Japon, Tokyo

Re: Les ordinateurs de l'HORREUR

Messagepar DarkSoul » Mar Jan 17, 2017 8:40 am

DarkSoul a écrit :Le boot iSCSI est aussi toute une horreur à lui seul, normalement on se dirait qu'on peut configurer le DHCP pour passer les paramètres (en mettant ça dans une DB ou un LDAP) et vogue la galère. Que nenni. Si vous faites ça, vous risquez de n'avoir le boot iSCSI qui ne marche qu'une fois sur trois (de mon expérience). :fu:


Followup sur ce point precis.

J'ai remplace hier le serveur mort de l'autre jour et j'ai refait sa conf avec ma procedure toute propre. :mion:

Bam. No boot device. :tokiomi:

Booon... Pourtant il detecte bien le disque iSCSI... :yukino4: Mais il passe cinq minutes a tenter de booter avant de se planter. :ringo3: Pourtant WinPE en PXE boote bien et le voit, donc c'est bon, mais... :yukino4:

Bon, on va rebooter un des autres serveurs et comparer sa conf BIOS ecran par ecran :rin2:

"Aucune difference", disait le Barde au Barbare dans un certain Donjon, avant de se prendre une mandale.
"J'crois qu'c'est ca la difference", mais ca n'avance pas davantage mon affaire.

Et la d'un coup j'ai un eclair d'inspiration : ce boot qui ne marche pas, ca ressemble au storage quand il PLANTE et qu'il ne repond pas de donnees apres un login pourtant reussi. :saki2:

Je code vite fait un template Cacti pour monitor les controleurs, et je remarque CECI :
Image
Image

On dirait qu'il y a un controleur qui gere les lectures et l'autre les ecritures, la ou on s'attendrait a ce que ce soit UN PEU MIEUX reparti. :otome:

Du coup je me dis, il se passe quoi si je me connecte sur le mauvais ? (Sur le serveur, redondance a tous les etages, j'ai config la carte 1 branchee sur le switch 1 pour se connecter sur le portail 1, la carte 2 sur le switch 2 pour le portail 2) :rin3:
Et je renverse l'ordre de priorites PRIMARY et SECONDARY. :yukino4:
ET CA FUCKING MARCHE. :keuwa: :tamako: :serious:

"J'crois qu'c'est ca la difference", en effet >_>
Du coup petit mail bien senti au fournisseur pour demander quoi la baise. :sue:
Des nouvelles horreurs sous peu, ne changez pas de chaine. :musume:
Modifié en dernier par DarkSoul le Mar Jan 17, 2017 6:18 pm, modifié 1 fois.
0 x
Membre d'Epitanime depuis 2000 (EPITA Promo 2005 SRS)
Informaticien expatrié, traducteur à ses heures perdues

Avatar de l’utilisateur
DarkSoul
Membre En Mutation
Messages : 89
Enregistré le : Jeu Oct 13, 2011 2:50 am
Localisation : Japon, Tokyo

Re: Les ordinateurs de l'HORREUR

Messagepar DarkSoul » Mar Jan 17, 2017 8:42 am

s3phy a écrit :Quel est le con qui est allé foutre du HostRaid dans un contrôleur RAID d'une gamme serveur ?!!! :ringo3:


Facile : ca coute la peau du fion d'ajouter un controleur RAID hardware (surtout pour plus de deux disques, parce que il faut la batterie etc...). Economie de couts. Le matos serveur vendu aux PME, souvent c'est du desktop glorifie/retoole avec deux alims et un controleur RAID-1 pour faire joli, alors bon...

Les serveurs Promise qu'on a la c'est exactement la meme race.
0 x
Membre d'Epitanime depuis 2000 (EPITA Promo 2005 SRS)
Informaticien expatrié, traducteur à ses heures perdues

Avatar de l’utilisateur
Shikaze
Début de la gloire
Messages : 20
Enregistré le : Mer Sep 22, 2010 7:15 pm

Re: Les ordinateurs de l'HORREUR

Messagepar Shikaze » Mar Jan 17, 2017 8:15 pm

Haaa, les joies du travail en horaire décalés, où on est totalement livré à soi même.... et où on doit lire dans les pensées des gens absents pour savoir quoi faire. :death:

En l'occurence, alerte sur un de nos ... 3 (4? voire 5) outils de supervisions...
Je regarde dans l'outil de ticket : sensi 0, on s'en tape, ticket et basta. ::D
SAUF QUE ! :espion:
L'alerte concerne un baie, et le numéro de série correspondant, c'est de la sensi 9 : ALLLAAARRRMMMEEE ! :vuvuzela:

Donc, dans un cas comme ça, on fait QUOI ? :?:

On prend en compte la sensi de la baie, dont on n'a aucune indication si c'est un truc de secours ou redondé ? Ou on prend en compte la sensi 9, sachant qu'on se fait taper sur les doigts quand on appelle à tord ? :-o

Je précise aussi qu'en regardant dans les logs de tickets, on voit que y'a déjà eu un truc comme ça pendant le week-end, et que ça avait été cloturé le matin sans plus d'explication. :gohda2:

Sachant que j'étais avec le ptit nouveau, arrivé là depuis 3 mois, je prends la décision. :rider2:

On appelle, parce que si c'est vraiment critique, on peut pas laisser ça comme ça ! :coach:

Braifeu, appel à l'astreinte vers 00h45 : je lui donne le nom de la baie, et là : "Ouais, je sais, y'a une inter planifiée demain matin"

.....

:fu:

ET VOUS POUVEZ PAS LAISSER LES INFOS COMME ÇA DANS LES TICKETS, BERDEL DE MORDE ?!? :pourquoi:

Addendum : et bien entendu, quand je vérifie les mails du tafs ce soir, le chef d'équipe : "Bon, pourquoi t'as appelé à tort ?"
:ringo3:

La blague ?

Le MAIL auquel il répond en demandant ça, t'as l'astreinte ET le chef d'équipe de l'astreinte qui disait "on a repassé la sensi 9 en sensi 0, y'avait erreur à ce niveau".

Donc traduction, on doit prendre en compte la sensi des éléments dans l'outil de ticket... sauf quand y faut pas parce que c'est une erreur.... et apparemment c'est à nous de le savoir sans aucune info supplémentaire :touko:

Donc, comme dit au début, apparemment, faut que je lise dans les pensées des gens en astreinte sans les réveiller pour savoir si je dois les réveiller ou pas maitenant. :jospin:
0 x

Avatar de l’utilisateur
QCTX
Fait partie du paysage
Messages : 126
Enregistré le : Lun Mar 30, 2009 12:44 am
Localisation : RP

Re: Les ordinateurs de l'HORREUR

Messagepar QCTX » Mar Jan 17, 2017 9:57 pm

Bon, j'ai eu ma dose, ce soir.
:rider2:
Tu es sur ton annuaire tranquilou à jongler avec tes comptes utilisateurs. Et puis y'en a un qui semble sortir du lot en te disant qu'il à pas le même nom chez toi et dans l'annuaire de destination. Ha bon ? Mais alors comment on va le déplacer de l'un vers l'autre ? Et surtout, quelle est la bonne orthographe ?
Pas de soucis, la bonne orthographe, elle est listée dans une belle base de données des RH, avec une jolie interface web. Bon, ok, on prend l'identifiant de l'utilisateur, on regarde et on trouve bien notre utilisateur correctement orthographié... comme dans les annuaires. Pas de classique du type, nom ou prénom composé, avec un tiret ou un accent quelque part. Parfois on a même des surprises à base de "ç" qui viennent s’incruster, mais là non. Rien, que dalle, les nom sont exactement aux trois emplacements.
:oguie:
Bon, va falloir chercher un peu mieux. On prend l'annuaire de destination, on tape le nom de l'utilisateur dans le champs de recherche et on regarde les options.
On reprend l'annuaire de départ, on tape le nom de l'utilisateur et... Oh, c'est quoi ça, deux résultats ? Avec le même nom et le même prénom ?
Oh, collègue, rappelle-moi la procédure pour le cas ou on à des homonyme, l'un des deux se voit attribuer un chiffre dans le nom, c'est bien ça ? Bon alors pourquoi je vois pas de chiffre et deux fois la même valeur ?
Bah, il doit y avoir une différence, c'est pas possible, Microsoft gère pas deux entrées avec la même valeur dans le champs Display Name.
OK, on ressort la loupe.
:akiho:
Et on constate :
la seule différence dans le champ Display Name entre les deux comptes, c'est ça : " ".
Voilà, vous avez bien lu, l'un des admins s'était gentiment amusé à insérer 1 fucking espace supplémentaire entre le nom et le prénom dans le champ les affichant.
:sayako:
Après avoir creusé un nouveau trou à hauteur de visage, j'ai voulu corriger le champ et remettre un seul espace. Impossible, il ne peut y avoir deux élément avec le même champs Display Name. Pas grave, vous connaissez les tours de Hanoï ? Je prend l'autre compte, je remplace le 1 espace par 3 espaces, et sur le bon compte je remplace 2 espaces par 1 espace.
Enfin, ça, c'est que je voulais faire, mais le collègue m'a fait alors remarqué un truc encore plus bizarre :
- 2 comptes.
- 2 identifiants différents.
- 1 seule adresse mail, la même, reliée aux deux comptes.
:yukino4:
"Alors, ça, tu vois, au vu des identifiants, c'est un mec qui est passé d'agent statutaire à intérimaire. Il y a trois ans environ, vu l'activité du second compte."
Et on a donc débusqué un admin flemmard, obligé de créer un second compte, pour le même utilisateur, et qui, plutôt que de laisser une note dans le champs "commentaire" prévu à cet effet, à simplement différencié le nouveau compte avec un double espace.
:tiramie:
Le même admin qui vient nous trouver plus tard dans la soirée pour nous dire qu'il en a marre de gérer des tickets et plus particulièrement celui-ci : un utilisateur qui se plaint de ne pas pouvoir supprimer un dossier sur son partage réseau.
Le message d'erreur indique que le dossier ne peut pas être supprimer parce qu'il reste un fichier dans le dossier. Le fichier qui refuse de s'effacer proprement, vous le connaissez tous, il s'appelle thumbs.db
Et l'admin peut pas le supprimer, il est sur un serveur auquel il n'a pas accès. L'utilisateur ne peut pas le supprimer car il n'a pas d'élévation de privilège. La hotline à encore moins de droits sur le répertoire. Et ça reviens chez nous parce que "c'est un utilisateur que vous avez changé d'annuaire, le problème date de ce moment là, c'est forcément votre faute."
:kanako2:
En regardant mieux, la responsabilité est notre, effectivement : le projet est en cours, la reprise d'activité par les admins de l'autre bord n'a pas encore eu lieux parce que PERSONNNE ne veut se coltiner les procédures, surtout que les admin par ici ont rien branlé niveau ménage et qu'on va forcément tomber sur des piles de cadavres, des montagnes de cadavres bien cachés. Et que même si on transfère les procédure existantes, elles feraient se dresser des cheveux sur la tête au moindre technicien capable, qui refusera tout net de reprendre sous sa responsabilité ce... "truc".
:jospin:
Donc, on cherche. Pas longtemps, parce que la solution, on la connaît. On a même prévu un moyen pour que tout soit résolu par d'autres que nous. Les données incriminées sont sur un NAS. NAS qui a deux pattes réseaux. Sur chaque patte, on mis une instance CIFS rattaché à un domaine différent. Quand les utilisateurs changent de domaine, ils continuent d'accéder au données en passant par une route différente (les CIFS), mais ce sont les mêmes données. Et les deux CIFS sont physiquement au même endroit : dans le même bâtiment que les admins. Admins qui ont tout à fait les droits d'accès aux deux instances, mais qui refusent de toucher à tout ce qui n'est pas LEUR domaine. Dès fois que. Et qui n'ont donc toujours pas compris cette histoire d'instances CIFS leur permettant d'accéder aux même données.
:rin2:
Je vous laisse, il y a un second trou à hauteur de visage qui m'attend.
:tamako:
0 x
Image

spanner
Apprenti Thaliste
Messages : 7
Enregistré le : Mer Juin 15, 2016 7:47 pm

Re: Les ordinateurs de l'HORREUR

Messagepar spanner » Lun Avr 10, 2017 6:51 pm

Une petite histoire de dev/sysadmin, toujours en cours

Poisson de verre, parceque quand t'y touches, ca casse

Pour le contexte, je suis arrive dans ma nouvelle boite avec comme mission d'automatiser/industrialiser au plus possible l'infra actuelle, donc config management, CI/CD, remontee des metriques, ce genre de trucs, c'est super cool, l'equipe est super ouverte d'esprit sur les changements (majeurs!) que je propose, et ca se passe plutot bien :mion:

Jusqu'a ce que j'arrive a mon projet actuel, on doit changer de serveur d'application java, d'un vieux jboss a glassfish, et du coup, vu qu'on a SaltStack pour le config management, ma mission, si je l'accepte, c'est de faire des statefiles pour installer et configurer glassfish et y deployer nos applicatifs metier, why not? :lisbeth:

Sauf que, SaltStack a pas de modules pour configurer glassfish, et que en fait, comme c'est un serveur java EE, tout se configure avec un utilitaire en ligne de commande, "asadmin", qui a l'air de principalement modifier un fichier de conf "domain.xml", mais comme visiblement directement gerer le domain.xml c'est casse-gueule, faut trouver un autre moyen :pierre:

Coup de chance, j'apprends l'existence d'une API RESTful pour gerer glassfish, et c'est meme a priori ce qu'utilisent l'interface web et le asadmin, c'est parti pour coder un module SaltStack pour gerer ca! :akiho:

Bon, premiere etape, la doc, ou se trouve la doc... bon, y'a bien une page d'intro pour glassfish 3.x sur le site d'oracle, mais je suis sur la derniere version, en 4.x, donc bon, je met ca de cote, et je continue de chercher, y'a pas l'air d'avoir sur le site de glassfish (visiblement, c'est passe de oracle a communautaire java entre la 3.x et la 4.x)... y'a pas l'air d'avoir sur le github de glassfish... mais elle est ou cette doc? pourtant c'est bien indique comme etant une API pour permettre aux devs tiers de gerer glassfish :yukino4:

La reponse est simple, y'a pas de documentation!, bon, bon, bon... y'a l'intro pour l'API de glassfish 3 qui indique que sur un GET, il va cracher la liste des parametres a donner en GET/POST, et je peut toujours sniffer les requetes HTTP de asadmin, on va tester la seconde solution rapidement, voir si je peut avoir des morceaux d'infos sur quoi envoyer ou :delrio5:

Je vous la fait courte, asadmin n'utilise pas l'API normale, ca utilise bien une API, mais elle est completement non-documente et elle demande un parametre etrange, un hash sha1 en base 64 (!) qui semble (selon le code source) etre une concatenation des noms des parametres + des tags selon si c'est obligatoire, etc... j'ai aucune foutre idee de pourquoi ca demande ca :inaba:

Bon, retour a l'intro de glassfish v3.x et... tiens "type de retour: json, xml, html"... html? etrange :yukino4: ah tiens, c'est une interface "web" tres moche mais on s'en fout, qui liste les endpoints, les donnees, et surtout, qui a des formulaires avec les parametres pour faire les POSTs et les DELETES, yes! :musume:
Sauf que cette interface visiblement, les devs eux aussi ont pas compris ce qu'il fallait faire, aucun des formulaires marche (ils envoient pas un header "X-Requested-By: Glassfish REST Interface" obligatoire), et quand on veut afficher les properties d'un element (/endpoint/$name/property), ca renvoit... une page blanche, visiblement, meme les collegues de ceux qui ont dev l'API ont pas compris le bordel que c'est :sayako:

Bon, deja, une chose etrange, pour chaque element, a priori y'a deux moyens de faire, le premier, c'est une serie de endpoints create-truc, delete-truc, edit-truc, list-trucs... c'est pas tres RESTful ca, par contre, ca ressemble fortement a du SOAP porte a l'arrache :tiramie:
Y'a aussi des trucs qui semblent plus recent, a base de GET/POST/DELETE sur des enpoints unique, deja mieux! :rin2:

Le probleme? L'API en fait, c'est jumanji, a chaque fois que tu as un endpoint different, les regles du jeu changent, meme si c'est les memes variables, c'est un festival :kanako2:

Selon que ce soit un POST vers /endpoint pour creer un element ou sur /endpoint/$element pour le mettre a jour, les noms des variables sont pas forcement les memes, parfois c'est pareil, les deux en camelCase, parfois c'est lowercase a la creation et camelCase a l'update, parfois c'est... un melange des deux, camelCase a l'update et... ben ca depend de la variable a la creation, restype cotoie resAdapter, mais par contre, c'es bien resType et resAdapter a l'update, ils ont juste oublier les majuscules a certains noms, comme ca :yui3:

Si tu te foires, t'as un gentil json avec l'erreur 500 avec un status "FAILED" et un message d'erreur, c'est bien, ca permet de savoir ce qui va pas pour corriger... sauf quand ca renvoit un erreur 500 vide, ca depend, ou un 400 vide. et rien dans les logs, bonne chance pour debug :sue:

Sur tous les elements, y'a un champ "target", a quoi il sert? j'en sais foutre rien, les variables ont aucune description et le plus drole? selon l'endpoint, tu peut avoir null... ou pas, a priori, le default c'est "server" et sur certains endpoints, t'es oblige de le mettre, sur d'autres, ca le fait tout seul, comme par magie :kanie:

Pour set les properties de l'element, a la creation, t'as un champ "property", comment tu set plusieurs properties avec un seul champ? en faisant une liste de var=value evidemment! mais euh, var1=value1&var2=value2, ca fonctionne pas? :shiori:
Ah, non, en fait, le separateur, c'est ":", pourquoi ":", aucune idee, mais visiblement c'est ca, soit. :mio2:
Le probleme? value est parfois une URL, donc un truc qui commence par protocole://machin. QUI C'EST LE CON QUI CHOISI LE MEME SYMBOLE QUE TU TROUVES DANS LES VALUES EN TANT QUE SEPARATEUR?!? :ringo3: donc c'est protocole\://, faut le deviner.

Les regles changent aussi pour /endpoint/$element/property, la, le POST classique, ca fonctionne plus, visiblement, y'a plus qu'avec Content-type: application/json et les donnes en json que ca fonctionne :marii3:
Et aussi, la, plus de var=value comme au dessus, non, la c'est [ {name: 'var1', value: 'value1'}, {name: 'var2', value: 'value2'} ], c'est concept :homura:

Pour delete un element, tu fais un DELETE sur /endpoint/$element, pour delete une property? tu... met a jour les properties (avec un POST sur /endpoint/$element/property) en ne mettant pas cette property, si tu met a jour juste la property que tu veux update, en fait, tu vire les autres. :coach:

Parfois, un element n'aura pas la meme valeur a la creation et a l'update, si tu essaies de copier/coller un truc d'un element existant pour en creer un nouveau... ca va planter, aucune idee pourquoi, c'est un bug que j'ai decouvert cet apres-midi :tamako:

UPDATE: en fait, ca a bien la meme valeur, c'est juste que cette valeur depend de la valeur d'un autre element, lui indique comme etant optionnel dans la liste des parametres, sans valeur par defaut ni meme de liste de valeurs possible... alors qu'en fait t'as le choix entre 2, et que si tu met pas cette valeur optionelle correctement, ca fait planter une valeur elle obligatoire. pour faciliter le tout, ces informations se trouvent sur la page de creation d'un element sur le panneau d'admin web... page qui plante avec un nullpointer sur glassfish depuis 5ans :fu:

Ce parametre etant visiblement une string, mais seulement "un choix parmis une liste possible", cette liste possible, contrairement a d'autres parametres, elle est pas documentee, faut les deviner :kyou:

Sur un post de blog d'un des devs de cet immondice, tu apprends que "l'API REST dispose d'un fichier WADL, apres tout, que serait une API REST sans fichier WADL? :cm: " un fichier WADL? c'est un "equivalent" au WSDL du SOAP pour les apis REST, c'est donc un enorme fichier XML qui normalement defini de fond en comble l'API, la blague? il donne ni la liste, ni la description des variables a mettre, ca liste juste les endpoints, et le type de format :jospin:

(je precise, rien de tout ca n'etant documente, ca a ete "trouve" par chance ou en lisant le code source... des tests unitaires de l'API)

Ca fait une semaine et demie que je suis dessus, alors que normalement c'est juste implementer une API RESTful pour get/set des variables en python, j'en ai marre :kanako2:

Tu m'etonnes que Oracle a abandonne le support commercial de ce truc pour se concentrer sur WebLogic :yoshitake2:
0 x

Avatar de l’utilisateur
DarkSoul
Membre En Mutation
Messages : 89
Enregistré le : Jeu Oct 13, 2011 2:50 am
Localisation : Japon, Tokyo

Re: Les ordinateurs de l'HORREUR

Messagepar DarkSoul » Mar Avr 25, 2017 3:36 am

Sendmail, le serveur qui porte mal son nom

Grosse connerie de la semaine, et moment de honte pour moi : cette semaine, j'ai commis un des peches capitaux du sysadmin, a savoir que j'ai pousse une modification en prod sous le coup de la fatigue et de la panique, et fait une enorme connerie en me disant "ca devrait pas avoir d'impact", et en etant trop pete pour penser a verifier proprement derriere. :kanie:

Ceci est donc aussi une "cautionary tale" a la "si vous voyez passer les signes d'une situation similaire, arretez TOUT" et "si vous utilisez sendmail, voila dans quelles limites c'est acceptable, et si vous sortez de ces limites, alors oubliez parce que c'est juste suicidaire". :yukino4:

La panique et la fatigue viennent d'une chasse a l'erreur "qui arrive une fois par jour en haute charge", qui avait dure plusieurs jours, sur... pourquoi un serveur defini dans /etc/hosts renvoyait "host name lookup failure". :misaka2: Une ou deux fois par jour, sur cinq millions de mails. :marii7: Avec plainte d'utilisateurs. :haruka:

Je vous passe tout le raisonnement : Ce n'etait pas nsswitch.conf. :shinji: Ce n'etait pas un souci du disque. :saki: C'etait un souci de famine de descripteurs de fichiers. :kuroko2: En gros, sous UNIX un processus a une limite pour ses resources (man ulimit, man setrlimit), et il est "normalement" possible de la programmer. :coach: La blague ? Sendmail se reprogramme lui-meme a 1024. :yukino6: Ce n'est pas configurable. Pire : ce ne DOIT PAS etre configurable. :shardis:

Sendmail utilisant une vieille API et un vieux design, il est TOUT SIMPLEMENT "incapable" de gerer plus de 1024 connexions en meme temps. :pokerface: Ce qui se passe quand ce nombre atteint sa limite ? Bah vous ne pouvez plus ouvrir de connexions, vous ne pouvez plus ouvrir de FICHIERS ! :misaka2: Donc du coup il devient impossible d'ouvrir meme /etc/hosts !! :mio2:

Seconde blague : Quand un serveur mail ne peut pas livrer un mail ? Il defer ou il bounce (sur un mail qu'il n'a pas encore accepte, ca veut dire "refuser" ; sur un mail deja accepte ca veut dire "renvoyer"). Quand il ne peut MEME PAS renvoyer le mail ? Bah Il l'efface. :araragi: La decision d'un serveur mail de dire "renvoie ca plus tard" ou "je refuse" varie selon les implementations et le cloisonnement entre les fonctions du serveur. :coach:

Ceci a son importance. Au bout de quatre heures a creuser, tester, et lire le code de sendmail, et a lutter avec un environnement de test qui etait pas tout a fait au point et qu'il fallait remonter (et que je devais faire en meme temps mais qui etait pas encore utilisable ; premiere erreur, d'abord retaper l'environnement de test, on verra ensuite), on s'est retrouves a 20h et j'etais un peu en mode "oh MERDE, oh MERDE, oh MERDE" :homer: parce que je realisais qu'on perdait donc un mail ou deux par jour en random, et j'ai voulu faire quelque chose en attendant pour regler le probleme alors qu'il n'y avait plus personne ou presque sur le plateau, :homer: (CE RAISONNEMENT EST UNE ERREUR ; CA AURAIT PU ATTENDRE) et donc j'ai voulu configurer le serveur mail de relai dans sendmail pour ne plus passer par le DNS. J'ai mis l'IP directement en me disant "bon c'est idempotent et ca marche sous postfix, ca doit passer..." (CE RAISONNEMENT EST UNE ERREUR ; TOUJOURS VERIFIER, SURTOUT SUR UN SERVEUR MAIL)

Le chef de la prod a vite fait vu la modif (ou son concept du moins) et a dit "OK" mais... Truc que j'ai decouvert deux heures plus tard apres un coup de fil en panique ? Que l'element de configuration "smart host" dans sendmail est en realite un element de transport mail, et doit etre configure avec une syntaxe de domaine pour l'envoi d'emails (c'est-a-dire domaine.com ou [111.222.33.44] pour une IP). Que fait sendmail sinon ? Il va garder les mails en queue et les renvoyer une fois la conf fixee, vous vous direz ? Bah non. Il droppe. Il accepte les mails, et il les droppe. :-?

Sur deux heures de 20h a 22h ca a fait 500 000 emails, pour 80 000 IDs impactes (mais par bonheur 90% de spam). :bioshocked: Moralite : il n'y a pas que la fatigue qui est traitre et a laquelle il faut faire attention, il y a aussi la panique et l'impression factice que "c'est la merde", parce qu'elle vous fait oublier la premiere et vous pourrit vos reflexes. :-? :homer:

TL;DR : Je suis tombe sur du code horrible dans sendmail, j'ai commis un epic fail, et j'ai applique une modif en prod sans la valider prealablement parce que j'avais pas pense que sendmail aurait un comportement broken a ce point. :non:
1 x
Membre d'Epitanime depuis 2000 (EPITA Promo 2005 SRS)
Informaticien expatrié, traducteur à ses heures perdues

Avatar de l’utilisateur
s3phy
Tenace
Messages : 68
Enregistré le : Mar Déc 30, 2014 4:54 pm
Localisation : Shinjuku

Re: Les ordinateurs de l'HORREUR

Messagepar s3phy » Dim Mai 28, 2017 8:47 pm

T'es maudit avec les mails.
0 x

Avatar de l’utilisateur
DarkSoul
Membre En Mutation
Messages : 89
Enregistré le : Jeu Oct 13, 2011 2:50 am
Localisation : Japon, Tokyo

Re: Les ordinateurs de l'HORREUR

Messagepar DarkSoul » Lun Mai 29, 2017 2:41 am

s3phy a écrit :T'es maudit avec les mails.


Gag, c'etait AUSSI un Sendmail l'autre fois :p
0 x
Membre d'Epitanime depuis 2000 (EPITA Promo 2005 SRS)
Informaticien expatrié, traducteur à ses heures perdues

Avatar de l’utilisateur
DarkSoul
Membre En Mutation
Messages : 89
Enregistré le : Jeu Oct 13, 2011 2:50 am
Localisation : Japon, Tokyo

Re: Les ordinateurs de l'HORREUR

Messagepar DarkSoul » Mar Aoû 29, 2017 12:10 pm

Pas trop une horreur au premier abord, mais j'ai aujourd'hui porte le coup de grace a deux serveurs FreeBSD 4.2 qui etaient up depuis 15~16 ans. :fuckyea:

Le moment horrible ? :pokerface: :char2:
Quand apres une longue migration qui m'a pris tout le mois d'aout (car operable uniquement les jours de maintenance contractuelle sur une timeframe de 30 minutes :wait: ),
et qui a demande des interventions pour cabler la console serie (oui car les serveurs Intel en question n'avaient pas de carte VGA :fuckthat: ),
au moment d'eteindre, j'ai realise que... :keuwa: :shinji:

LA CONF RESEAU N'ETAIT PAS CONSIGNEE DANS /etc/rc.conf. :tokiomi:

Ces deux machines au demeurant assez critiques ont donc tourne, je repete, au moins QUINZE ANS, sans jamais rebooter, ni perdre leur conf reseau. :tsubaki: :misaka2:

Il y a de la moule de pendu qui se perd. :lied:
1 x
Membre d'Epitanime depuis 2000 (EPITA Promo 2005 SRS)
Informaticien expatrié, traducteur à ses heures perdues

Avatar de l’utilisateur
Corsaire
Début de la gloire
Messages : 21
Enregistré le : Ven Fév 06, 2015 7:16 am

Re: Les ordinateurs de l'HORREUR

Messagepar Corsaire » Mer Oct 25, 2017 4:08 pm

Le DNS qui ne voulait pas mourir

Lorsque je suis entré dans ma boite j'ai eu bien entendu à me familiariser avec nos procédures et documentations.
Ceci pour en constater l'état parfois lamentable.

Si les anciens connaissent par cœur l'infra pour l'avoir en partie créé, ils ont parfois consigné sous forme de wiki ce qui s’apparenterait plus à un pense-bête qu'une vraie doc. :tamako:

J'ai donc énormément réécrit ou reformaté. :yukino5:

Dans le tas, les docs pour manipuler le, ou plutôt les DNS.
Et tout en faisant le process et réécrire proprement point par point ce qu'il faut faire, je tombe sur un truc étrange lors d'une étape.
En synchronisant les zones DNS nouvellement créés sur les serveurs DNS des différents segments, il y a un serveur qui n'aime pas ça, son rsync est juste trop vieux !
Il s'agit d'un Solaris 5.6 de 1997 donc. :yukino4:

En en discutant avec les gens autour, ce DNS ne sert que pour une section du réseau du genre le totem qu'on ne déplace pas, façon s'il y a un changement par an c'est un miracle.
La décision est prise de carrément le retirer de la procédure standard, on laisse bien un chapitre dédié dans le Wiki mais qui va encore le lire... :yoshitake2:
En bref on laisse le truc crever mais en ligne au cas où, après tout il y a des DNS bien plus récents et maintenus alors si d'aventure on oubliait d'avoir changé une conf sur un serveur d'infra ça serait un filet de sécurité temporaire.

What could go wrong ? :sue:

Fast forward plus de 3 ans après...

Afin de nettoyer le réseau infra pour le mettre à neuf je fais une petite pérégrination dans notre infra, je repense a cette vieille machine et m'interroge sur son usage.

Me logguant dessus je constate bien qu'elle n'a guère qu'un Bind qui tourne et ses zones DNS n'ont plus été mises à jour depuis 2008.
Mais là où ça devient drôle c'est lorsque je jette un œil a ses logs, le daemon est pas mal sollicité en fait !!

En regardant qui lance des query je vois plein de nos serveurs d'infra vénérables ! Le genre que si ils disparaissent d'un coup le Nagios devient un sapin de noël :char2:

En bref, nos serveurs "pilliers" de la boite sont incapables de voir les changements dans la boite depuis près de 10 ans !
On est vernis qu'il s'agit majoritairement de vieux AIX et Solaris qui se basent majoritairement sur des fichiers hosts pushés en même temps que les modifs de DNS (générés par le meme script), mais quand même !

En vérifiant leurs resolv.conf ils sont écrit comme çà :

Code : Tout sélectionner

nameserver vieux_serveur
nameserver nouveau_serveur 1
nameserver nouveau_serveur 2
:kanako2:

Je fais donc un rapport de tout ça et le chef saute au plafond. :bioshocked:

Le résultat, on va analyser à fond pour trouver qui fait encore des appels, modifier les confs et flinguer la machine.

Gag 1 :
contrairement à ce que vous pouvez lire de ci de là sur le net, quand on change un resolv.conf il est nécessaire de relancer les process (postfix, snmpd, ...) voire de rebooter complètement.
Et comme je l'ai dit les serveurs concernés sont des vénérables, le genre si ça plante c'est la merde, on ne les reboote pratiquement jamais et on est pas sur que le hardware non plus résiste au redémarrage.
Qui n'a pas déjà entendu le cri d'agonie du bip de démarrage d'un vieil AIX ne peut comprendre... :yuno:

Gag 2 :
Ce serveur DNS peut se vanter d'un Uptime à ce jour de 17,3 ans ! :figurantes:

Gag3 :
En discutant de cela avec le chef en réunion lui même n'est même pas sur de comment on peut rebooter un a un les vénérables sans tout exploser, ou plutôt sans devoir mettre au tapis TOUT le groupware pour faire l’opération puis tout relancer... :kuroko2:
0 x
Un poing vaut mieux que deux "j'te préviens..."

Avatar de l’utilisateur
Corsaire
Début de la gloire
Messages : 21
Enregistré le : Ven Fév 06, 2015 7:16 am

Re: Les ordinateurs de l'HORREUR

Messagepar Corsaire » Dim Oct 29, 2017 12:19 pm

Le vCenter les vieilles bouses

En faisant un tour dans notre vCenter j'ai trouvé pas mal de machines installées sans les vmware-tools ou avec des versions antédiluviennes.

Pour rappel ces tools installés permettent ceci :

* Synchronisation NTP : VMware Tools donne la possibilité a votre machine virtuelle de synchroniser l’heure avec son serveur hôte.
* Amélioration des performances réseaux : installe les drivers VMXNET
* Amélioration des performances graphiques : si vous avez installé un OS avec un environnement graphique le driver SVGA installé par VMware Tools augmentera le taux de rafraîchissement et vous donnera accès à des résolutions plus élevées
* Amélioration des performances de la RAM : un driver vous permettra de profiter d’une meilleure gestion de l’allocation de RAM
* Amélioration des performances de la souris : installation d’un driver d’accélération
* Optimisation des drivers SCSI : un driver BusLogic SCSI avec de meilleures perforances I/O pour certains types d’OS virtualisés
* Partage des dossiers : vous pouvez mettre en place facilement un partage de dossiers entre votre hôte et votre VM
*Réduire la taille des disques virtuels : si vous aviez défini une taille de disque s’avérant trop grande vous pouvez désormais la diminuer
* Éteindre et redémarrer vos VMs : vous avez la possibilité d’éteindre ou redémarrer vos VMs proprement sans avoir a vous logger

Je me lance donc dans des installations ou mises a jour... :mion:
Et comme de bien sûr dans le tas une machine pète en pleine opération... :hirano:

Coup de pot c'est une machine qui ne sert que pour l'IRC interne à la boite. :marii3:

Mais un incident reste un incident, je me dois d’enquêter et faire un rapport. :keima:

La conclusion est que le process de MAJ a pete en cours de route sur cette machine car pas assez de disque libre au mauvais moment... on pourra rediscuter du fait d'avoir un serveur rempli a plus de 90% en fonctionnement courant. :kanie:

Mais surtout mon enquête m'aura fait soulever les points suivants :

* Debian 3 et en dessous
oubliez la virtualisation !
Le jeu n'en vaut pas la chandelle, le kernel 2.4 est très mal a l'aise sur un environnement virtualisé et du décalage d'horloge va se produire. :tsubaki:
De plus, le driver réseau VMXNET est amené par les tools, donc un module third party... nope ! :clooney:

* Debian 4
On passe au kernel 2.6.* mais encore un peu trop vieux.
Le driver réseau VMXNET est amené par les tools là aussi, passez en réseau intel1000 plutôt.
Virez le open-vm-tools de la distro, trop vieux il ne fonctionne pas ! Mettez les tools depuis votre vcenter.

* Debian 5
Mettez le kernel 2.6.32-bpo et vous aurez le module VMXNET intégré au kernel pas une pièce rapportée
Comme pour la debian 4 virez le open-vm-tools de la distro et mettez les tools depuis votre vcenter.

* Debian 6 et plus
Sans Pb, utilisez toutefois cette fois le paquet open-vm-tools de la distro.

Et surtout pour virer les tools des vieux packages de distro passez a l'artillerie lourde:

Code : Tout sélectionner

dpkg -l | grep vmware
dpkg -P paquets

Oui, l'option PURGE, et même les SOURCE doivent disparaitre. :shardis:

En espérant que ça puisse servir à tous.
1 x
Un poing vaut mieux que deux "j'te préviens..."


Retourner vers « Fourre-Tout des discussions légères »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 14 invités