documentation/compte_rendus/2016_09_01.md

# Réunion du Collège Technique

* Date : Jeudi 1er septembre 2016
* Lieu : Pavillon des Jardins
* Début : 19h00
* Fin : 22H05
* <<Pad>>

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

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 :

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