Bonjour un petit sujet pour partager un peu nos mésaventures quotidiennes…
Et se défouler quand les choses vont mal.
La vm du jour, tout va bien… (note la vm host le node d’un cluster flink qui bizarrement est hs.)
Note 1: En bon 
noir, ça arrive forcement juste le Vendredi avant les vacances.
Note 2: J’ai pas la main sur cette infra, mais je crois que qq chose va pas bien.
Y’a deux zombies qui trainent si tu avais pas remarqué
oui j’ai remarqué l’info gérant je sais pas trop… 
des zombies ! 
Hello,
Je saute sur ce sujet car j’ai depuis un moment une evie de faire une libre antene sur les histoires de problèmes qui nous on amener à amélioré les choses.
Parce que les REX de succès c’est bien mais les REX de problème c’est mieu pour aprendre je trouve.
J’aimerais bien faire une émission mensuell de 1h en Live Youtube avec des invités, comme une libre antène.
Bonne idée. Effectivement, les échecs et les erreurs c’est clairement plus formateur et réaliste.
qui nous on amener à améliorer les choses.
Alors dans le cas ci dessus, je suis pas certain que l’on va améliorer les choses. L’amélioration continue n’est pas forcement la norme partout… 
Mais c’est un autre sujet.
J’ai une formation pour ça si tu veux faire passer le mots 
Dans ce cas je me permet de partager mon REX sur un gros fail de ma part 
https://blog.karolak.fr/2020/05/03/ma-premiere-grosse-boulette-professionnelle/
Au passage, salut @amonthe, t’es partout toi ! 
Salut Nico,
Story de ouf, tu étais un admin immaculé avant!
@nka, j’étais déjà tombé sur ton article, mais merci de l’avoir partagé ici 
. C’est courageux de partager ce type d’expérience, bravo ! C’est un bon retour d’expérience qui montre que sous la “pression” d’un client et avec le stress, cela peut conduire à déroger à certains principes et faire une grosse boulette.
Ce matin manque d’un peu d’espace disque sur un fs. Un collègue (dev) me propose d’en récupérer sur /dev … 
Dans un radio DevOps, je disais “attention avec le cloud ça peut être assez rapide de se prendre une bonne pastille sur la facture”. Voici une illustration. (note: je détaille pas comment nous avons corrigé le pb car c’est pas le sujet, mais dites-le moi si ça vous intéresse)
Petit avertissement, rien n’était caché par le fournisseur de cloud et la faute est entièrement de notre faute. Une mise en place un peu trop hâtive sans être super attentif aux prix et 
…
Voici l’histoire, pour un de mes clients, nous avons dû mettre en place un service ftp. S’il vous plaît ne me juger pas ! Il se trouve que dans certain domaine, la norme pourtant récente impose du ftp. (La sécurité se fait sur le payload qui peut être signé et chiffré mais ce n’est pas imposé par la norme… Oui ça sux mais c’est comme ça).
On monte donc un service sur Azure, le service ftp (pas mal customisé) est redondant sur 3 serveurs, un dans chaque AZ. En frontal un LB qui dispatche la charge sur les 3 nodes et assure la HA si un serveur ne répond plus.
Pour que le service ftp fonctionne il faut faire des règles sur le LB, le port 21 pour les commandes et un certains nombres de port haut (mode ftp passif). Pour les ports hauts, on ouvre une centaine de ports car, le service devrait recevoir pas mal de connexions. Rien de vraiment fou et on ouvre les règles tranquillos sur le LB avec donc ~100 ports par environnements (dev, int, qualif, pprod, prod)… Cool après un peu de réglage de la configuration ça marche bien. La solution n’est pas en production, mais on va pouvoir le faire quand on en aura besoin.
Environ 6 semaines plus tard (la solution n’est pas tjr pas en prod) le client reçoit une alerte de seuil sur sa facture. Heureusement il a pris le temps de configurer cette alerte sinon ça allait faire très très mal. Il y en a quand même pour ~5k€ pour une solution qui n’a jamais réellement était utilisée !
On cherche la raison et là on regarde les règles de facturation du LB. (Tarification - Load Balancer | Microsoft Azure).
Le petit truc que l’on avait pas forcement imaginé ou vu c’est le prix des règles, 0,009 € pas cher, sauf que c’est par règle/heure.
Oui par heure ! Donc avec 100 règles ça fait quasiment 1€ par heure ! 100 règles * 0,009 * 5 envs * 24h = 108 € par jour * 45j = 4860€ juste pour les règles du LB. Aie ça pique… 
Pour d’avantage d’optimisation il serait aussi possible de déployer un vm scale sets de 2 machines sur 3 zones d’une région.
Alors oui, mais j’ai volontairement omis certains détails ici. Notamment le fait qu’il faut 3 nodes, car il y a du Hazelcast qui tourne avec ce service pour faire une “distributed shared hashmap”.
Je compatis même. J’en peu plus de ce protocole et des tickets de clients qui ne savent pas ce qu’est le mode passif
Une minute fail de début de carrière pour ma part.
J’étais dans un grand groupe où les équipes passaient un outil un peu dégueulasse en ksh pour “analyser la sécurité de la machine” (c’était n’importe quoi mais c’est un autre histoire). L’outil sortait un rapport en HTML.
C’était mon premier job après l’école et je devais donc résoudre les soucis détectés par l’outil.
Une alerte concernait un paquet en lien avec x11 (je me rappelle plus du nom exact mais il y avait x11 sur le nom), avec une alerte du type “houlala il y a un paquet x11 sur un environnement server, problème critique …”.
Je demande un peu de précisions aux équipes et on me confirme qu’il faut absolument désinstaller le paquet. OK, je fais un playbook ansible qui désinstalle le paquet. Je passe ça sur nos environnements, ça marche, super.
Sauf que ces playbooks étaient aussi joués sur les environnements d’autres équipes. L’équipe gérant hadoop l’a lancé sur plusieurs environnements (heureusement c’est jamais passé en prod, que des envs de test/qualif…) et par une chaine de dépendance la suppression du paquet a aussi supprimé toute la stack hadoop/hbase/hive… 
Morale de l’histoire: ne jamais forcer la désinstallation d’un paquet 
Je me fais un peu l’avocat des utilisateurs. 
de clients qui ne savent pas ce qu’est le mode passif
Parfois il faut se méfier, les clients évolués (genre filezilla) font des trucs pour pallier à certains défauts de configuration coté serveur et donc peuvent masquer des problèmes. J’ai pour habitude de toujours tester avec le client ftp le plus basique possible pour vérifier que ça fonctionne bien.
Après les clients(personnes), peuvent avoir du mal, ftp est un protocole super efficace pour faire ce pourquoi il a été conçu. Du transfert de fichiers. Par contre c’est “un peu 
” daté (FTP is 50 years old) les contraintes réseaux et sécurité n’était pas les même à l’époque et la mise en place de ces solutions est un peu inhabituelle. Ce qui peut expliquer les difficultés aujourd’hui…
Bon courage avec les tickets, résister au coté obscur qui te donne envie de répondre sauvagement avec un bon vieux RTFM tu dois ! 
Merci et je partage volontiers tes remarques.
Au final, je préfère un ticket pour un problème d’accès FTP que pour un problème d’accès CIFS
A une époque j’ai fais beaucoup de HPUX.
Un classique:
Sur Linux hostname -f → Display the FQDN (Fully Qualified Domain Name).
Sur HPUX l’option n’existait (n’existe ?) pas… hostname -f → Pas de réponse ($? == 0).
Et la souvent tu (ou l’admin) percutes pas, un peu vite, tu passes à un autre truc…
Mais 30mn plus tard il y a le feu ! C’est quoi le nom de la machine ? hostname → -f 
avec les conséquences que cela peut avoir coté applicatif.
Aujourd’hui un quiz minute fail. 
Problème qui m’est arrivé ce Lundi et qui est un grand classique sur Ansible.
Le “playbook” fait le déploiement de keepalived sur 3 nodes et configure celui ci de manière adéquate.
Enfin normalement, car suite au bug, les 3 nodes ont reçu la même configuration. (aie !)
En conséquence l’utilisation de la vip marchait très mal, performance vraiment mauvaise, probablement à cause des requêtes ARP que devaient envoyer chaque node à cause de la mauvaise configuration. Mettant le bronx sur le réseau et le switch.
Note: a noter que la difficulté a été de comprendre le soucis et trouver la mauvaise configuration, le bug et la correction sur Ansible par contre j’ai trouvé très vite.
Voila la conf (sans détails et possible choses confidentielles):
Inventory
...
[load-balancer-Group]
10.xxx.yyy.135
10.xxx.yyy.136
10.xxx.yyy.137
...
Partie du playbook
- name: "\\/\\/\\/ START: load-balancer deploy \\/\\/\\/"
hosts: load-balancer-Group
gather_facts: True
serial: 1
roles:
- load-balancer
...
Role (load-balancer)
- block:
# Install keepalived
- name: Install keepalived
yum:
name: keepalived
state: present
# Create keepalived configuration
- name: "Template keepalived configuration"
template:
src: keepalived.j2
dest: /etc/keepalived/keepalived.conf
owner: root
group: root
mode: '0640'
force: true
...
Template keepalived.j2
#jinja2: trim_blocks: False, lstrip_blocks: True
vrrp_script chk_myscript {
script "/usr/local/bin/decofer-load-balancer-check.sh"
interval 1 # check every 2 seconds
fall 2 # require 2 failures for KO
rise 2 # require 2 successes for OK
}
{%- set node_id=(ansible_play_hosts.index(inventory_hostname)) %}
vrrp_instance VI_1 {
{%- if node_id == 0 %}
state MASTER
{%- else %}
state BACKUP
{%- endif %}
interface {{ ansible_default_ipv4["interface"] }}
virtual_router_id 51
{%- if node_id == 0 %}
priority 255
{%- elif node_id == 2 %}
priority 254
{%- else %}
priority 253
{%- endif %}
advert_int 1
authentication {
auth_type PASS
auth_pass {{ keepalived_pass }}
}
virtual_ipaddress {
{{ lb_vip_list.0 }}
}
track_script {
chk_myscript
}
}
...
Alors est ce que vous l’avez le 
? 