Réunion du Collège Technique

• Date : Jeudi 1er septembre 2016
• Lieu : Pavillon des Jardins
• Début : 19h00
• Fin : 22H05

• Lien vers l'etherpad associé

Présents

• Hamza Dely
• Gabriel Detraz
• Charlie Jacomme
• Daniel Stan
• Myriam Bégel
• Mathilde Espinasse
• Renaud Taleroy
• Lucas Serrano
• Younesse Kaddar
• Emmanuel Arrighi
• Rémi Oudin
• Vincent Legallic (arrivé à 19h13)
• Michaël Paulon

Ordre du jour

État des lieux et stabilité

Le 0B est safe aux inondations de 15cm. Tout est surélevé. Les serveurs critiques sont sous Jessie, il n'y a plus de problème. Odlyd semble réparé, il n'y a plus eu de KP depuis plusieurs mois. La clim a été réparée une nouvelle fois, on espère qu'elle va bien et que c'est enfin fini. Dernière bonne nouvelle, sable est quasiment prêt en fallback master. La solution est qu'il spoofe toutes les ip (dns, dhcp, etc.) Il faut encore proprifier la conf éventuellement, mais ça semble en bonne voie.

Daniel propose de se pencher vers Keepalived. De cette manière, il se charge de vérifier si les services fonctionnent, et si ce n'est pas le cas, il prend le relais. C'est également l'ocassion de vérifier toutes les configurations de keepalived pour chaque service et s'assurer que le switch se fait bien également pour les serveurs de redondances.

NFS

Beaucoup de problème et de stabilité et de sécurité proviennent du nfs.

Le NFS est le système de fichier sur le réseau (https://en.wikipedia.org/wiki/Network_File_System). Certains dépôts comme /usr/scripts sont partagés par le nfs, et c'est potentiellement dangereux puisque si le nfs tombe, on perd tous nos scripts. Ce qui s'est passé le 28 : une commande foireuse suite à un énième remontage en ro d'un home a coupé nfs-kernel serveur, il nous a été impossible de le relancer. Cela a provoqué une panique en chaine sur zamok en premier, avec tous les users qui essayaient d'accéder à leur home ; le moindre ls tournait en boucle.

Seul un reboot de zbee, avec une mauvaise surprise habituelle (grub-rescue) a permis de relancer le nfs. Il a fallu entre autres rebooter zamok ; l'intranet également (qui accède aux home et a lui aussi paniqué). Les autres serveurs n'ont pas besoin des home, ils n'ont pas paniqué ; mais le dhcp et le radius ont planté du fait de l'absence de usr/scripts… Ce qui est très problématique, la coupure aurait pu être plus indolore sans cela. Seul odlyd a continué à router normalement, les règles du parefeu sont restées en place jusqu'à ce que usr/scripts revienne, bon point de ce coté là.

Il existe actuellement 3 exports nfs : les homes, la virtu et /usr/scripts.

/usr/scripts

L’intérêt du /usr/scripts over nfs est très limité ; l’expérience prouve qu'un git pull fait par monit avec alerte si cela foire fonctionne très bien, ironie du sort, sur zbee lui même ! Je propose donc d'abandonner /usr/scripts over nfs, et de mettre le dépot en dur sur les serveurs. Il ne pèse pas très lourd, 50 megas à tout casser.

On gagne énormément en stabilité ; à titre d'exemple, en cas de plantage de zbee le 28, le réseau aurait entièrement continué de fonctionner (dhcp, radius etc) ; seul les mails et zamok auraient été impactés à cause du plantage de l'export des home. On renforce également très fortement la sécurité.

La plupart des fichiers qui pèsent sont surement inutiles dans usr/scripts (fichiers de logs des bornes). Alors on autorise monit à git pull à chaque commit.

La décision est validée par le CT.

Ping propose une autre solution qui passerait par bcfg2 pour éviter d'avoir tous les scripts partout et de ne plus savoir qui doit être où. Cependant, ça demande beaucoup de travail, et on ne gagne pas forcément beaucoup en stabilité. La question pourra être réabordé dans le futur une fois que le /usr/scripts sera safe.

les Homes

C'est de loin le plus problématique sur le nfs. À moyen terme, il convient de réévaluer la pertinence des home sur la baie qui est plus que limité.

Chirac propose donc d'acquérir ou de constituer 2 nas, fonctionnant avec ceph, ce qui permettra au passage de tester cette technologie qui semble mature et robuste, et de migrer ensuite l'ensemble des home dans cette grappe de nas.

Charlie imagine un NAS logiciel. Dans ce cas, on peut prendre du SATA, et donc prendre des gros disques, avec du RAID logiciel. Chirac remarque que ceph + raid5 se fait facilement.

Charlie demandera un devis à Anne. Ping fait remarquer qu'au pire, elle peut Anne-uler.

La virtualisation

On peut la laisser à moyen terme dans la baie, et réévaluer la situation en temps voulu. Il est à noter que proxmox gère nativement ceph, si on souhaite fonctionner là aussi avec une grappe de nas. Auquel cas il sera pertinent de pas recommencer les mêmes erreurs, et de séparer le stockage des adhérents de la virtualisation…

Pour la virtualisation, on verra plus tard après avoir testé avec les Home.

Ram pour virtualiser

Il est apparu qu'on ne pouvait mettre toutes les vm sur un seul virtualiseur par manque de ram, ce qui est un peu bête. Chirac propose d'acheter 32 gigas de ram pour stitch, idem pour ft, vu le prix que cela coute, l'investissement vaut le coup. À ce moment là le réseau pourra tourner entièrement avec un seul virtualiseur up (stitch ou ft).

En mettre 32Gb sur les deux virtualiseurs est un peu overkill. L'objectif est de pouvoir faire tourner toutes les VMs sur le même serveur. Actuellement les VMs sont un peu maigres en RAM, ça permettrait de resizer pour éviter que les VMs se bloquent quand une upgrade prend plein de RAM.

Daniel propose de lister les VM vraiment vitales. On regarde les besoins en RAM, quitte à modifier, et on considère que c'est le minimum sur le virtualiseur principal. Les VMs de redondance iraient sur les autres virtualiseurs, quitte à les éteindre en cas d'urgence.

Hamza se charge de faire le calcul : Il faut 18Go de RAM pour faire tourner les VMs critiques. Charlie demandera un devis à Anne.

Ping remarque qu'il faudrait mettre 1Go minimal en RAM max (et 512 en mini) sur les VMs, en dessous on en a moins qu'une Raspberry Pi. Charlie se propose pour faire ça.

Redondance

Les VMs redondantes. Quand on a éteint des VMs quand le 0B chauffait (24/08/2016), y'a eu un certain nombre d'incompréhensions, au moins de ma part sur lesquelles étaient redondantes. Est-ce que 2 VMs censées l'être le son vraiment (ie y'en a pas une des 2 qui en fait, fait un truc en plus) ? Exemple typique : un des 2 serveurs radius fait en fait Federez-Wifi en plus.

• #roots, 24/08/2016
  16:54:42 &tudor | si vous voulez un protocole (en général), l'idée que je suggère c'est de garder les vm de redondance (pea, isc) ou inutiles sur le virtualiseur le moins puissant
  16:54:54 &tudor | et de l'éteindre au premier pépin

keepalived : je prétends que sa config pour les trucs qu'il est censé failover n'a pas été testée. Prove me wrong

Il faut mettre à jour la page wiki sur les VMs redondées, savoir qui fait quoi exactement. La mise en place de Keepalived sur sable permettra de faire une PoC sur tous les services.

Planification installation zamok

Si le CA est gentil, on aura un nouveau zamok à installer. Où, quand, qui et comment ? Warning : wild problems may appear everywhere…

Update : le CA est gentil

Il va falloir l'installer puisque le CA est gentil.

Un des problèmes est que le digicode est sur zamok. Charlie propose de tuer ce vieux service et de passer au nouveau digicode (à finir et à patcher). Le nouveau service coûte grand max 150€.

Charlie peut proposer un devis pour le CA. Un prototype marche avec des trucs sales, mais du coup on peut faire marcher avec un truc propre. Le système au 2B est quasiment fini.

Par contre, il faut vraiment s'y mettre pour le finir, et pas le laisser traîner.

Avoir le digicode prendra malgré tout 2-3 mois, on attendrait donc pour mettre zamok en prod. On prend donc le temps de le reconfigurer from scratch.

• http://git.crans.org/?p=rebootModule.git;a=commitdiff;h=36043453a6ac7f79dae42858b4642cdb761143fe

  • ↑ Ce commit prétend qu'on peut changer l'IP/MAC du serveur digicode avec le digicode actuel. (Le digicode n'est donc pas bloquant pour changer zamok). -- Daniel

Accessoirement, ce serait bien de faire un dump des paquets installés sur Zamok et de trier ceux qu'on garde et ceux qu'on jette. apt-mark showmanual ?

• https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.fr.html#package-status

Apt-dater

C'est en place, cela juste marche. Démo prévue (Chirac). On peut abaisser le niveau de vérification pour que ce soit encore plus pratique, mais attention danger.

Il faut les répartir en groupes (critique, autres, services…). La config est dans /root/.config/apt-dater/hosts.conf pour les groupes. Il faudrait que ça soit généré automatiquement par bcfg2 (voir pour la création de services.py pour un exemple)

Il faudrait aussi gérer le cas des serveurs/VMs marqués en unknown.

KVM

Pendant le stage de Hamza, on a reçu le module kvm usb, ça marche. On a pas d'alim qui fonctionne, il faut en racheter une, ainsi que la dizaine de modules kvm nécessaires.

policyd-rate-limit

Il y a eu des problèmes de spams par des vieux comptes inutilisés. Il n'y avait pas de limitations du nombre de mails si on changeait d'ip. Plein de serveurs nous ont blacklisté pendant un temps.

Nit a développé un script pour gérer ce problème. Si la limite est dépassée, postfix envoie une erreur smtp qui correspond à des limites dépassées.

Mailman ne semble pas impacté par policyd-rate-limit.

On peut fixer une limite par jour (genre 500 mails).

Hamza propose de s'en charger.

Il faut aussi créer une campagne de changement de mot de passe (projet apprentis).

Ethercalc

Suite au reboot du 2 août, il semble que ethercalc n'avait pas redémarré. Nit a fait un redémarrage par la suite, mais à la main.

Renaud avait fait un init script, il faut juste le retrouver. Il s'en charge pour la prochaine IN. Il écrira aussi la doc nécessaire pour comprendre son installation.

Autres problèmes

Idées en vrac :

• -- Wiki20-100 2016-08-26 14:58:34

• Contacts pour la maintenance :

• From: Gabriel Detraz <detraz@crans.org>
  Date: Tue, 2 Aug 2016 20:47:45 +0200
  Cc: nounou@lists.crans.org
  Pour information, j’ai envoyé le mail de la maintenance au adhérents, mais également aux clubs qui disposaient d’un contact valide.Par conséquent, FedeRez et l’ARES  pour ne citer qu’elles ont automatiquement reçu le mail prévenant de la coupure. Si ce n’est pas le cas de rezosup ou osm, il faut simplement mettre à jour les informations de contact dans la base de données.

Charlie va regarder pour aller voir. 20-100 va regarder dans la base de données si ils sont bien à jour.

Il faut créer un club rezosup, et le faire adhérer pour longtemps. Charlie s'en charge avec 20-100.

• Les autres trucs redondants. La dernière fois j'ai demandé ce qu'il en était du fameux quorum des virtualiseurs quand on reboote. C'est peut-être un problème réglé (ou WONTFIX) mais je ne sais honnêtement pas, et ça peut pas faire de mal de la rafraîchir dans la mémoire de tout le monde.

On avait déjà vu ce point. Le quorum est à 2, et en cas d'urgence, il faut aller le modifier à 1 dans /etc/pve/corosync.conf

• MailMan : j'ai pas encore eu droit au code que PEB a fait tourner pour fix l'encodage. Je voudrais réussir à tester mon script redisdead:/var/lib/mailman/bin/isthereencodingfail.py avec un Vrai Positif pour être sûr qu'il teste bien ce que je pense qu'il teste. Il reste quelques MLs qui ont des problèmes d'encodage sur l'inteface web : les MLs dont les adhésions sont générées automatiquement (ex respbats, roots).

Auth.py

Couac avec la période de sursis, les 2A se sont fait massivement envoyer bouler par auth.py et placer sur le vlan accueil, réglé par Chirac (involontairement) et PEB. Cela ne devrait plus se reproduire. Bug également avec le bloq dans auth.py, ce qui explique bien des bugs rencontrés ces derniers mois…

Détails : la période de sursis était évaluée au moment du lancement de auth.py à partir de config.py, or auth.py tourne depuis plusieurs semaines, parfois des mois sans être relancé. À partir de maintenant, la période de sursis est une méthode dans config.py qui est chargée à chaque check de has_access (methode lc_ldap qui évalue si un port/machine a accès ou non).

Fixed par PEB, qui a transformé les mesures de temps en méthode, et qui sont donc exécutées au moment du test, et non au moment ou on lance auth.py

Questions diverses

Virer SpamAssasin de MailMan

C'est un projet au long court, il faut pas se précipiter, mais ça pourrait être pas mal d'y réfléchir. Il pète config_list, il rend la modération relou (les spams n'atteignent pas le filtre discard_these_nonmembers), il considère que les mails des caméras sont du spam. Il faudrait d'abord sonder un peu les utilisateurs de ML pour savoir si il leur sert.

• => On regarde les datas et on en reparle plus tard

Services.py et bcfg2

"Quand on modifie services.py, il faut appliquer bcfg2 sur tous les serveurs pour mettre à jour services.py" Faux, c'est automatique.

Autre exemple : ssh_known_hosts.

Température 0B

Google préconise 23°C, il faudra passer pour remonter, et changer les réglages munin pour éviter de l'avoir en "Problem"

Un devis est passé pour une clim de secours, sans que cela soit une mauvaise idée, et étant données les prestations de la société actuelle, on peut troller sur la pertinence du truc. 3400 €, douche comprise.

On en reparle dans 2 semaines, après y avoir bien réfléchi.

Page d'accueil

Il faut trouver où mettre la page d'accueil créée par Myriam

Pour dans 2 semaines, il faut que Myriam vienne faire une démo avant la mise en prod. Et on met le point plus haut dans l'ODJ.

Mises à jour

Rappel : les mises à jour consistent à lancer dist-upgrade, puis à vérifier après que tout marche…

(la deuxième étape est aussi plus importante que la première, il ne suffit pas de cocher la mise à jour comme "faite"…)

Daniel est fâché à cause de ce qu'il s'est passé. Il rappelle la présence de systèmes de monitoring qui n'ont pas été vérifiés, voire des serveurs qui n'ont pas été rallumés.

20-100 rappelle qu'il faut regarder les changelogs (qui sont obligés d'être affichés en cas de DU). Il faut les lire et les appliquer.

Il faut vérifier que tout tourne à la fin aussi. Genre, utiliser le service qui a été mis à jour, ou qui a du être redémarré.

Vieilles nounous

Le droit existe, la suite ?

On finit le script, et on revoit ça après : On veut éviter que des bots puissent juste exécuter le script et obtenir les droits roots en cas de compte corrompu. Du coup, une solution est proposée qui serait de poser une question secrète avant de rendre les droits. Par exemple : Quelle était ta "maman" ? Quelle était ta nounou préférée ?.

---

• CatégoriePagePublique