Les ordinateurs de l'HORREUR

[DarkSoul]

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 )… 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.

[DarkSoul]

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

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.

[spanner]

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

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)

[Corsaire]

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.

[s3phy]

Bon ben ça marche avec Hikari Next :D

Et ça va vite !

Merci à tous les deux :)

[DarkSoul]

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 !)
- Un RDP ouvert parce que on a un partenaire tiers qui administre le système

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.

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.

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. Encore une fois, SANS FIREWALL.

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 ? (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.

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.
- PAAAAAS BIEN : ...Ce compte était dans le groupe admin sur le serveur applicatif et le NAS, ET avait les privilèges RDP. Dieu merci la DB (MSSQL Server 2005) n'avait cet user que en user ordinaire.

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
-- 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"
- 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"
- "Ben j'ai voulu regarder la VM du Nagios secondaire mais le vmhost est aussi dans les choux"
- "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 ?"
- "Ah j'avais pas pensé merci... Ben non elle est up"
- "... ._O Bon attends je sors mon laptop et j'arrive sur IRC, on va continuer en direct"

Je remarque que absolument tout ce quadrant 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.

Presque tous.

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

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.

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...

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.

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.



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. IMPOSSIBURU.

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


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.

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é ?"
- "Go. On a que ça à faire."
- "Euh. Ping lost. SSH lost. SNMP lost. Aucune réaction. He's dead Jim."
- "On attend un peu des fois qu'il reboote."

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..."
- "...Merde."
-" Bon, on passe au reboot éléctrique."

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."

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"
- "Comment ça il revient pas ? O_o"
- "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"
- "T'es en train de me dire que l'accident a EN PLUS niqué un serveur physique ?"
- "Ben visiblement oui..."

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.
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 ?



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

Vendredi à 17H20.

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

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

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.

[DarkSoul]

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.

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

Sauf que souci ?
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é.

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

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).

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
- Il ne couvre pas les cas de pourrissement silencieux des données
- C'est que des emmerdes si il faut transvaser les disques sur un autre OS
- Il n'y a pas d'outil de monitoring digne de ce nom (contrairement à mdadm sous Linux, ou tout contrôleur RAID matériel)

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...

Enfin, quand le storage ne part pas en vacances sans prévenir.

[QCTX]

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.

[DarkSoul]

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.

[s3phy]

- "On attend un peu des fois qu'il reboote."

Je connais tellement ce moment

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é…

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

Putain j'avoue…

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.

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.

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… ) 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

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) [/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

[DarkSoul]

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.

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… ) 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

Idem~

- Il n'y a pas d'outil de monitoring digne de ce nom (contrairement à mdadm sous Linux, ou tout contrôleur RAID matériel)

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.

[DarkSoul]

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
- 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~)
- Du coup on a tente ce WE et on a decouvert que y'a d'autres disques qui battent de l'aile et apparemment un faux contact en plus avec les cables. Du coup grosse frayeur et deux disques endommages visiblement. Le souci c'est que c'est au point ou ZFS refuse de demarrer l'array meme avec trois disques branches sur les 4 (va savoir si les read errors y sont pour quelque chose, cela dit)
-> Moralite : un remplacement de disque, ca se fait *VITE*. On ne le repetera jamais assez.
- Du coup, conclusion, achat d'un disque de plus et d'un dock, et en attendant on met le bordel en stase cryogenique...
- A dix mille bornes la maintenance remote hands c'est chiant
- 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".

[s3phy]

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 :




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

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

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.


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

[DarkSoul]

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).

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.

Bam. No boot device.

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

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

"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.

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



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.

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)
Et je renverse l'ordre de priorites PRIMARY et SECONDARY.
ET CA FUCKING MARCHE.

"J'crois qu'c'est ca la difference", en effet >_>
Du coup petit mail bien senti au fournisseur pour demander quoi la baise.
Des nouvelles horreurs sous peu, ne changez pas de chaine.

[DarkSoul]

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

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.

[Shikaze]

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.

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.
SAUF QUE !
L'alerte concerne un baie, et le numéro de série correspondant, c'est de la sensi 9 : ALLLAAARRRMMMEEE !

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 ?

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.

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

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

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"

.....



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

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


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

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.

[QCTX]

Bon, j'ai eu ma dose, ce soir.

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.

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.

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.

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.

"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.

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."

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".

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.

Je vous laisse, il y a un second trou à hauteur de visage qui m'attend.

[spanner]

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

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?

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

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!

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

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

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

Bon, retour a l'intro de glassfish v3.x et... tiens "type de retour: json, xml, html"... html? etrange 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!
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

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
Y'a aussi des trucs qui semblent plus recent, a base de GET/POST/DELETE sur des enpoints unique, deja mieux!

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

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

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

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

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?
Ah, non, en fait, le separateur, c'est ":", pourquoi ":", aucune idee, mais visiblement c'est ca, soit.
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?!? 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
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

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.

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

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

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

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? " 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

(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

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

[DarkSoul]

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.

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".

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". Une ou deux fois par jour, sur cinq millions de mails. Avec plainte d'utilisateurs.

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

Sendmail utilisant une vieille API et un vieux design, il est TOUT SIMPLEMENT "incapable" de gerer plus de 1024 connexions en meme temps. 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 ! Donc du coup il devient impossible d'ouvrir meme /etc/hosts !!

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. 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.

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" 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, (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). 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.

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.

[s3phy]

T'es maudit avec les mails.

[DarkSoul]

T'es maudit avec les mails.

Gag, c'etait AUSSI un Sendmail l'autre fois :p

[DarkSoul]

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.

Le moment horrible ?
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 ),
et qui a demande des interventions pour cabler la console serie (oui car les serveurs Intel en question n'avaient pas de carte VGA ),
au moment d'eteindre, j'ai realise que...

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

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

Il y a de la moule de pendu qui se perd.

[Corsaire]

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.

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

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.

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...
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 ?

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

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

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

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...

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

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...

[Corsaire]

Le vCenter et les vieilles bouses (Edit)

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...
Et comme de bien sûr dans le tas une machine pète en pleine opération...

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

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

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.

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.
De plus, le driver réseau VMXNET est amené par les tools, donc un module third party... nope !

* 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.

En espérant que ça puisse servir à tous.

(Edit)

En fouillant plus profondément j'ai découvert un fait étrange, le package source des vmware tools a des fichiers adaptes a des kernels bien plus vieux... on doit donc pouvoir installer sur 2.4.xx

J'ai donc décider de tester et d'installer tout neuf sorti du CD une debian sarge 3.1.

Je lance dessus l'installation des vmware-tools et me bouffe une vilaine erreur

Code : Tout sélectionner

[...]
Creating a new initrd boot image for the kernel.

$Id: mkinitrd,v 1.201 2004/05/16 22:00:48 herbert Exp $

Usage: /usr/sbin/mkinitrd [OPTION]... <-o outfile> [version]

Options:
  -d confdir  Specify an alternative configuration directory.
  -k          Keep temporary directory used to make the image.
  -m command  Set the command to make an initrd image.
  -o outfile  Write to outfile.
  -r root     Override ROOT setting in mkinitrd.conf.

See mkinitrd(8) for further details.
ERROR: "/usr/sbin/mkinitrd" exited with non-zero status.

Your system currently may not have a functioning init image and may not boot 
properly.  DO NOT REBOOT!  Please ensure that you have enough free space 
available in your /boot directory and run this configuration script again.

Execution aborted.

De toute évidence il y a un problème avec mkinitrd MAIS PAS avec la préparation et la compilation des outils et modules... intéressant

Un peu de recherche et bingo

<tools>/bin/vmware-config-tools.pl

Code : Tout sélectionner

      $initmodfile = '/etc/sysconfig/kernel';
      if ($gSystem{'distribution'} eq 'suse') {
          $syscmd = join(' ', $binary, $kernelList, $initrdList);
      } else {
-          $syscmd = $binary;
+          $syscmd = join(' ', $binary, '-o', "/boot/initrd-$kernRel.img", $kernRel);
      }

Les bras cassés de vmware ont foire leurs scripts d'install, ils attendent dans tous les cas un mkinitrd récent qui ne réagit pas pareil.

Une fois cette modif faite on peut donc utiliser un 2.4.xx dans un vcenter.
Enjoy.

[QCTX]

Donc, ce jeudi, j'ai pu sortir un coffre de ma banque.

Précisons : ma banque, c'est celle où je travaille, pas celle où je met des sous (et je ne connais que très peu d'informaticiens qui mélangent les deux).

Depuis 2 mois au boulot, notre robot de sauvegarde envoie un avertissement comme quoi il n'a aps assez de bandes de sauvegardes libres pour faire son travail correctement. Bon, c'est pas une alerte trop grave, on peut se débrouiller, mais fallait faire quelque chose quand même. Et donc Chef est allé commander des bandes.
Sauf que Chef est un crevard et que les bandes sont arrivées il y a 2 semaines... sans étiquettes dessus.
En réunion, quand je remonte le soucis c'est : "Oui, mais t'inquiète pas, on va les imprimer nous-même, on n'a qu'une dizaines d'étiquettes à produire, ça va être facile. D'ailleurs, la police de caractère pour faire les codes-barres doit être sur le serveur 4, je te trouverai ça plus tard et je dois avoir des planches d'étiquettes auto-collantes dans mon garage, je chercherai ce soir."

Autant vous dire qu'on était bon pour patienter encore 2 mois avant que Chef ne fasse quoi que ce soit. Mercredi, dans un accès de ras-le bol, j'ai pris le temps de trouver sur le net un générateur d'étiquettes en ligne ( https://tapelabel.de/ ), de passer à l'économat récupérer des planches d'étiquettes auto-collantes et d'obtenir enfin mes étiquettes. Reste plus qu'a tester le résultat obtenu sur le robot de sauvegarde (qui gère les bandes). Robot qui est donc situé dans un autre bâtiment à environ 1 km de là. Bâtiment dans lequel Chef m'envoie, le jeudi matin, avec mes étiquettes et mes nouvelles bandes pour tester le travail de la veille. Le robot est installé dans une salle serveur, en sous-sol, avec la moitié de nos machines, ce qui nous permet d'avoir la prod d'un côté et un environnement de sauvegarde complètement répliqué dans le premier bâtiment.
Bref, je me déplace jusqu'à l'autre bâtiment, et je teste mes étiquettes. Au bout d'un moment, Chef m’appelle sur le portable : "Dis-moi, tu es au courant des crues de la Seine prévues pour ce week-end et toute la semaine ? Ce serait peut-être bien que l'on s'inquiète un peu plus de nos sauvegardes, que tu passes les prendre tous les matins et que tu récupères tout ce qui est dans le coffre, voire carrément le coffre en entier en fait. T'inquiète pas pour le trajet, ChefChef est à mes côtés, il vient te chercher en voiture."
Le coffre en question, c'est donc celui où on stocke nos sauvegardes, il doit faire dans les 80cm sur 60 de haut et pèse un âne mort tout en étant aussi équilibré qu'un micro-ondes. J'ai donc du sortir la bête de son armoire, sortir de la salle serveur sous haute surveillance, passer devant le poste de sécurité, poser plusieurs fois le coffre pour sortir le badge qui me permet de passer tous les contrôles, patienter dans la rue en plein après-midi avec un coffre dans les mains pour que la voiture de ChefChef s’arrête devant moi et qu'on transbahute le tout sur un pauvre petit kilomètre. Kilomètre au bout duquel j'ai du recommencer le jonglage entre le coffre et mon badge pour ramener le tout dans l'open-space.
Mais voilà, c'est officiel, je peux l'ajouter à mon CV, j'ai sorti un coffre de ma banque.

[Corsaire]

It hurts!

Parfois on pense bien connaître son hardware et celui-ci vous réserve quelques surprises...

Depuis des années j'utilise pour mon routeur une machine faite maison.
Étant au Japon, on n'a pas ici toutes ces box de FAI même si elles existent.
On a le plus souvent un ONU, sorte de modem fibre pour ne pas le résumer simplement a un transciver, une entrée pour la fibre, une sortie en port rj45.
Il y a un vrai marché pour les routeurs et le choix en boutique est très au delà de ce que l'on voit en France (Il n'y a pas un problème de position dominante des FAI par rapport aux constructeurs d'ailleurs ?).

La question se posait donc de confier son réseau a une solution toute faite (routeur Netgear par exemple) ou faire soi même.

Le choix se porta sur un fait soi même tournant sous OpenBSD.
Pourquoi ? Plein de raisons.

• découvrir le système

• gérer soi même comme on le souhaite son réseau

• OpenBSD est très résiliant aux failles (2 remote exploits découverts en 20 ans d'age)

• c'est un vrai unix pour pouvoir faire SSH, des tunnels OpenVPN,...

Le choix du matos va se porter sur des machines très compactes et intégrées, des Soekris Net6501.
Durant plusieurs années tout va tourner comme sur des roulettes avec satisfaction maximale, se payant même le luxe de me permettre de faire des expériences inédites en lien avec le boulot comme la double authentification PPPoE.

Et puis le drame...
En arrivant dans ma troisième résidence je prend la fibre gigabit.

Après un certain temps je commence a trouver que ma connexion se traîne...
Pas se traîne façon inutilisable loin de la, mais les valeurs obtenues ne sont pas normales.
Quelque soit le test effectué, le protocole utilisé, je ne dépasse pas 100megas (oui je vous vois bien tous ceux qui me font des gros yeux plein d'envie).
Je commence donc par méthodiquement faire des tests croisés avec tout mon matériel, allant jusqu'au cordons rj45.
Puis je finis par avoir un doute horrible... et si c’était mon routeur ?
Le plus insoupçonnable des éléments du réseau serait il fautif ?

Prenant mon macbook pro le fais le lien direct sur l'ONU et tombe dans les pommes.
Le mac débite a plus de 550megas.

D'autres tests vont finir de me prouver le problème, explication:
les Soekris net6501 existent en 3 modèles avec un CPU allant de 600 a 1600MHz et la RAM en option allant de 512 a 2048Mo.
J'ai choisi pour le routeur le modèle le plus léger n'ayant aucun besoin de déployer de la puissance pour une machine qui va se borner a passer des paquets IP.

Seulement voila, cette configuration se révèle insuffisante pour travailler un trafic réseau a pleine vitesse gigabit.
Vous allez me dire comment ne pas s'en être rendu compte avant ?
Je vous ai dit que c’était mon troisième domicile, mes contrats internet se sont ainsi enchaînes :

• fibre 100mega

• vdsl2 (100mega)

• fibre gigabit

La fibre gigabit est apparue alors que je résidais dans mon second logement qui ne pouvait accueillir que le vdsl2 (qui est très bon d'ailleurs).
Donc dans tous les cas de figure je ne pouvais aller qu'a 100mega.
Or le hasard fait que la Soekris avec ses limitations ne pouvait justement monter qu'a 100mega.
Le problème était donc totalement invisible jusqu'a présent.

La solution a été de changer de routeur et de passer a une APU2 2C4, un engin plus recent avec un CPU quad-core et 4Go de RAM.

Et la plus de problèmes.
L’expérience reste traumatisante car j’étais très loin de douter des capacités de la machine, qui il faut le reconnaître marche parfaitement si on ne dépasse pas un certain débit au delà duquel elle ne peut plus suivre.

[DarkSoul]

Pour référence, le matériel qu'on a utilisé comme routeurs jusque là :
* Soekris 5501 : http://beta.soekris.net/net5501.html (cartes 100Mbps)
* Soekris 6501 : http://beta.soekris.net/net6501.html (cartes 1Gbps en "théorie" ; mais arrêt de production)
** Il faut noter que OpenBSD est moins performant que Linux et FreeBSD, et que le firewall intégré, pf, plombe encore plus les perfs.
* APU2 C4 : http://www.pcengines.ch/apu2c4.htm
** J'en ai commandé deux pour remplacer ma Soekris et tester le montage avec routeurs redondants

Là, quand je vais rentrer au Japon je vais aussi expérimenter avec :
* SolidRun Clearfog Pro : https://www.solid-run.com/product/clear ... g-8g-ct-e/

[Corsaire]

** Il faut noter que OpenBSD est moins performant que Linux et FreeBSD, et que le firewall intégré, pf, plombe encore plus les perfs.

I beg to differ here.
Lors de ma tentative de passer a FreeBSD pour augmenter le débit j'ai pu constater en fait une chute des performances.

OpenBSD: 100mb
FreeBSD: 45mb