Ça cause SAML, Keycloak et Nextcloud (genre https://stackoverflow.com/questions/48400812/sso-with-saml-keycloak-and-nextcloud )

Heure de fin prévue : 19h00

Définir qu'est-ce qui rentre dans le cadre de la structure qu'on met en place ? Est-ce que la structure se concentre sur la gestion du rack, le routage et l'infrastructure ?

Qui s'appellera pas chez mémé ni 42u mais qu'il faudra trouver.

Pour tierce le nom est important pour donner un peu le ton des choses et dans tout ce qu'on fais je trouve que l'aspect « détendu du slip » est important.

Pour les autres moins.

Soit.

Nombre d'accès au data center.

• all2all : pas de réponse
• verixi : des badges à 50€ et des boutons gratuits.

La gestion de la baie (c'est très vague et tout ce qui est sur ce pad tente à le définir mieux).

La prise en charge du routage (vois plus bas)

La gestion d'un stock de matériel de remplacement

• se met dans l'armoire 42u, soit en occupant des U soit dans les 10cm entre le sol et le premier U
• se met ailleurs ? → pas pratique pour la disponibilité

Il est a noter que les communications mobiles sont souvent inaccessibles dans un DC (un téléphone de secours peut être proposé par le DC)

Comment définir les « gardes » pour garantir l'opérationnel de la baie.

Définir qui sont les noms sur les contrats avec le DC et les signer.

Recevoir et payer les factures.

• privilégier les ordres permanents pour éviter le besoin d'intervention humaine dans le suivi des versements
• privilégier le trimestriel en lieu et place du mensuel
• concernant la consommation électrique (qui est facturée pour la baie) il faudrait prévoir la possibilité de mettre en place des « prises qui calculent la consommation » de chaque machine branchée.
• on ne peut pas se permettre de faire comme all2all et juste demander 75€ / U tout compris parce qu'on est plus petit et qu'une seule machine un peu pourrie pourrait nous plomber la facture d'électricité sans que nous ayons d'autre forme de revenus pour compenser les écarts.

Recevoir et traiter les demande de colocations de chaque membre

• convenir d'une charte pour définir les contours de « qui » la structure accepte dans la baie et ce qu'elle se réserve le droit de refuser
• peut-être proposer une décision collective des membres existant (occupant déjà la baie) pour ce qui est de l'acceptation ou l'exclusion de nouveaux serveurs (un peu comme pour les accès root dont nous parlons plus bas pour les accès au serveurs de ro(ou)tage
• essayer de sortir du « client (membre/serveur) - service (u, réseau, électricité) » et peut-être souligner qu'une participation au fonctionnement de la structure est incontournable à la mise en place d'un serveur.

Définir des contrats, tarifs, conditions et accès au DC pour chaque membre.

Chaque membre gère ses serveurs. Ce n'est pas la structure qui en est responsable.

Concernant les accès, il est peut-être possible de demander qu'un mail soit envoyé si un « bouton d'accès » est utilisé.

Envoyer le factures et suivre les paiements de chaque membre

Recevoir et traiter les requêtes judiciaires (sauf si c'est Neutrinet qui met ses IPs)

Définir le Service Level Agreement (SLA) des membres de la baie.

• un client de nubo ne sait pas se connecter mais nubo est accessible → problème technique chez nubo
• nubo n'est plus accessible → problème technique chez nubo ou la baie

  • tout le monde dans la baie n'est plus accessible → problème technique dans la baie, chez Neutrinet ou au datacenter ou sur le transitaire

  Pour pouvoir répondre à des questions du genre « lundi matin, 9h rien ne marche, qu'est-ce qui se passe ? »

Accès root.

Chez Neutrinet les clés sont là : https://gitlab.domainepublic.net/Neutrinet/infra/-/blob/master/group_vars/all

Comment donner et retirer un accès root. Proposition de HgO:

• venir trois fois à une réunion hub infra fixe pour créer de la confiance … et voir plus loin le paragraphe en gras.
• ne plus venir six fois d'affilée à une réunion fait que les clé sont retirées

Les pleins pouvoirs, chez Neutrinet en tout cas, s'accordent sur base d'une confiance humaine que nous n'avons jamais formalisé et … que nous ne souhaitons probablement pas le faire.

Par exemple, de vielles clés sont encore présentes, mais des clés de gens en qui nous avons confiance et rien n'est automatisé pour supprimer ces clés.

Les choses qui concerne l'infrastructure sont traitées dans le hub-infra.

Il est peut-être utile de définir des choses simples, claire et efficaces dans la droite ligne du Keep It Stupid and Simple.

La liste des root doit être clairement rendue publique et si quelqu'un doit être ajouté à cette liste TOUT les membres de la liste doivent donner leur accord puisque seul un root peut donner un droit root à une nouvelle personne.

Peut-être également publier les connexions à cette ou ces machines dans l'idée d'afficher une forme de monitoring publique de « qui se connecte à quoi ». C'est un peu l'automatisation du channel #ops sur chat.neutrinet.be.

Un constat … difficile de « protéger les membres » des problèmes techniques (accès root à un méchant, bug dans un protocole, mise à jours oubliée, porte dérobée dans un firmware,…) par une voie administrative (contrats, assurances,…).

Une forme de protection « technique », par exemple signer une config BGP et avertir si une config modifié est poussée.

Il faut peut-être se demander si se référer à des certifications du genre CISCO CCNA sont un prérequis.

Il est possible de faire du routage BGP dans les switchs de la baie.

Par exemple, un des problèmes auxquels « on » pourrait-être confrontés : une attaque DDOS

• il faut savoir sur quel canal s'exprimer (liste des ips attaquantes, …)
• il faut les compétences techniques pour mitiger l'attaque
• il faut les accès aux bonnes machines

La machine qui s'occupera du routage sera une machine essentielle tant pour des questions d'infrastructure que pour des questions de sécurité

Il est a noter que ce sera deux VMs pfsense sur un cluster proxmox de 2 serveurs et d'un ordinateur supplémentaire nécessaire au quorum. Cela amène la question de savoir si les non-neutrinetiens sont limité à ces VMs de routage ou si cela descend jusqu'au barebone.

Définir qui aurait accès à la machine qui gère le routage.

Si Neutrinet : actuellement 7 personnes sont sudoers MAIS seulement tharyrok et peut-être e-jim sont capable actuellement de gérer BGP ou le routage. Ceci dit … c'est le genre de choses qui ne changent pour ainsi dire jamais.

Définir les accès et procédures des différentes structures

Au même titre qu'un VPN reçoit son IPv4, son /64 IPv6 et ses gateways … ou il y a autre chose ?

Formation commune autour des sessions BGP

À planifier.

Vous allez dire que ça va de soit… mais c'est quelque chose qu'il faudra faire.

Chacun s'occupe de ses propres serveurs

À distance, ça va de soit … mais est-ce qu'il y a des « accès de secours » à prévoir ? Genre un VPN qui donnerait accès aux IPMI, Drac et autres ?

Physiquement celà dépendra un peu du genre d'accès au DC et soit il y a de l'autonomie soit il faut un chaperon à chaque passage.

Solidarité pour les procédures d'urgences à la demande de la structure. Travail défrayé par la structure ou 42U

Il y a une différence entre la structure et 42u ?

Éventuellement gestion d'un stock de secours utilisable par les structures (alimentation, disque dur, serveurs, …)

Où se trouverait ce stock ?

Il y aura des switchs (si possibles 2 pour la redondance) et il serait bon de pouvoir y faire des VLANs. Donc ce seront également des machines disposant d'accès « root ».

Avec les Gnuragistes nous avons mis en place GPG, Gopass et un répot gitea pour partager nos secrets.

Chez Neutrinet on a commencé aussi mais c'est pas fini.

tierce :

J'ai le sentiment de ne pas avoir été entendu sur le fait de commencer à 350€ / mois chez Verixi pour nous (thary, hgo, tierce) et vous (denis, kenny, ?) et profiter de la mise en place de nos serveurs (de prod pour nous) et de test / Nubo pour vous et « prendre des notes » pour définir petit à petit les questions / réponses / procédures et autre. N'ayant pas d'expérience en DC et encore moins en « gestion commune » il m'est difficile d'avancer sur la base seule de mon expérience et de mon imaginaire. J'en attendais beaucoup trop de « l'esprit bidouille » mais force est de constater que je me suis trompé. Ne me faites pas dire ce que je n'ai pas dis, « bidouille » ne veut pas dire manque de sérieux dans les objectifs à atteindre. C'est le chemin qui était à mes yeux la « bidouille » pas la destination.