From c58680d2d42be0876225b3714a7e01ec164f5b73 Mon Sep 17 00:00:00 2001 From: Quentin Dufour Date: Thu, 12 May 2022 12:38:57 +0200 Subject: =?UTF-8?q?R=C3=A9organisation=20du=20manuel?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/operations/Jitsi.md | 105 -------------------------------- content/operations/_index.md | 10 ++- content/operations/app/Jitsi.md | 105 ++++++++++++++++++++++++++++++++ content/operations/app/_index.md | 8 +++ content/operations/app/email.md | 30 +++++++++ content/operations/email.md | 30 --------- content/operations/grappe/_index.md | 8 +++ content/operations/noeud/_index.md | 7 +++ content/operations/noeud/deploiement.md | 51 ++++++++++++++++ 9 files changed, 217 insertions(+), 137 deletions(-) delete mode 100644 content/operations/Jitsi.md create mode 100644 content/operations/app/Jitsi.md create mode 100644 content/operations/app/_index.md create mode 100644 content/operations/app/email.md delete mode 100644 content/operations/email.md create mode 100644 content/operations/grappe/_index.md create mode 100644 content/operations/noeud/_index.md create mode 100644 content/operations/noeud/deploiement.md (limited to 'content/operations') diff --git a/content/operations/Jitsi.md b/content/operations/Jitsi.md deleted file mode 100644 index 4563c73..0000000 --- a/content/operations/Jitsi.md +++ /dev/null @@ -1,105 +0,0 @@ ---- -title: Jitsi -description: -published: true -date: 2021-11-09T12:53:23.811Z -tags: -editor: markdown -dateCreated: 2021-11-09T12:46:50.731Z ---- - -## 2020-04-02 Campagne de debug Jitsi - -Contact: Quentin - -### Description du problème - -Les conversations à 3+ donc relayées par le serveur ne fonctionnent pas bien. -Louison m'a rapporté que ça avait marché pour lui (3 utilisateurs avec un Webkit). -Mais moi ça a échoué hier soir (01/04/2020) avec des participants sous Firefox. -Le bug est toujours le même : on entend 2 personnes sur 3 ou on voit 2 personnes sur 3, on recharge la page et c'est quelqu'un d'autre pour qui ça ne fonctionne plus. Souvent c'est que dans un sens. -À chaque fois en passant sur Facebook Messenger, le problème est résolu instantanément. -Par contre Facebook Messenger impose Google Chrome/Chromium pour les visio de groupe (et ne supporte donc pas Firefox). - -D'où mes 2 suspicions : - -- Firefox a un bug quelconque dans sa pile WebRTC déclenché par le mode conversation de groupe -- Jitsi a un problème avec les déconnexions/changement de connexion/petit hoquets du réseau et n'arrive pas à se reconnecter. Ça pourrait être rendu pire à certain moment de la journée comme le soir où le réseau est plus sollicité. Et ce serait provoqué lors du reload on repasse de 3 à 2, en P2P donc puis de nouveau de 2 à 3. - -### Approfondissement - -Avant d'aller plus loin, nous avons voulu prendre le temps d'identifier précisément les problèmes d'expérience utilisateurs et leur corrélation avec la plateforme de l'utilisateur (navigateur, OS). - -Pour celà, nous avons suivi deux approches : -1. Mener nos propres tests -2. Chercher d'autres retours - -#### Mener nos propres tests - -Nous avons effectué deux appels : un avec Firefox seulement et un avec Chrome/Chromium seulement. -Merci à Alex, Adrien et Maximilien pour leur participation. - -Voilà les conclusions que nous avons tirées de nos tests : - -- L'appel avec Firefox a déclenché le bug immédiatement, peu importe la version de Firefox ou de l'OS (firefox stable/nightly, fedora stable/beta, etc.) -- Le passage de tout le monde sous Chrome/Chromium a permis d'avoir une conversation stable. -- Adrien avait sa Livebox avec pare-feu configuré en mode "élevé" et a dû ajouter dans sa liste blanche les ports utilisés par Jitsi (`4443/tcp` et `10000/udp` au moment du test, seul un des deux a besoin d'être accessible) - -Nous avons donc demandé à Adrien quels étaient les ports ouverts par défaut dans le mode élevé de sa box : - -![Livebox Parefeu Personnalisé](/img/operations/livebox_parefeu_personnalise.png) - -Nous avons dans un premier temps retenu le port `995/tcp` pour Jitsi, le port UDP ne pouvant être changé (limitation de Jitsi). -Cependant, pour des raisons de sécurité, les navigateurs ne peuvent pas utiliser les ports en dessous de `1024/*`, à l'exception des ports `80/tcp` et `443/tcp` comme l'indique ;'issue [#3583](https://bugs.chromium.org/p/webrtc/issues/detail?id=3583) de Chromium. - -La capture n'indique pas de port TCP supérieur à 1024, nous ne pouvons donc pas résoudre ce problème de notre côté, car à l'heure actuelle, nos ports `80/tcp` et `443/tcp` sont utilisés et nous n'avons qu'une seule IP publique. -Les utilisateurs activant le parefeu en mode élevé devront ajouter une exception dans leur parefeu eux-mêmes. - -#### Chercher d'autres retours - -[Tedomum](https://tedomum.net/) a eu connaissance de problèmes similaires. -Ils ont également identifié Firefox et assurent qu'avec l'application Android ça marche bien. -Ils me confirment que le problème vient bien du logiciel et non pas de notre déploiement. -Ils m'ont pointé entre autres vers cette issue github [#4758](https://github.com/jitsi/jitsi-meet/issues/4758) -Apparemment une issue est dédiée en particulier au problème que nous rencontrons de déconnexion partielle d'un participant, mais nous ne l'avons pas encore retrouvée. - -### Correctifs - - 1. Notre instance Jitsi a été reconfigurée pour refuser Firefox. Suivre l'avancée du développement de Jitsi pour Firefox - * [#4758](https://github.com/jitsi/jitsi-meet/issues/4758) - * [#5439](https://github.com/jitsi/jitsi-meet/issues/5439) - * _À compléter_ - 2. Pour relayer la vidéo à travers la plupart des parefeux, notre `videobridge` Jitsi devait écouter sur le port `443/tcp`. Or ce port est déjà utilisé par notre frontal HTTPS. À défaut, Jitsi est maintenant configuré avec `8080/tcp` et `10000/udp` (contre `4443/tcp` et `10000/udp` avant). - * Un déploiement en IPv6 pourrait résoudre le problème pour une partie des utilisateurs - * Avoir un cluster géo-distribué avec plusieurs IPv4 pourrait également résoudre le problème - * Avoir un frontend layer 4 (niveau TCP) qui trouve une signature pour router du DTLS vers videobridge et du TLS vers traefik - -### À propos du control/data plane de Jitsi - -Notre videobridge écoute donc sur les ports `8080/tcp` et `10000/udp`. - -WebRTC fonctionne en deux étapes : -- Des offres doivent être échangées via un serveur de signaling quelconque -- Ensuite, ces offres servent à connecter des clients directement via un protocole TCP ou UDP avec un thin layer propre à WebRTC - -#### Le control plane de Jitsi : Prosody sur HTTPS via Bosh/XMPP - -Le serveur de signaling Jitsi n'est autre que le serveur de chat prosody. -Pour ça, prosody est exposé à travers HTTP grâce au protocole BOSH (XMPP overs HTTPS). -Une fois l'offre reçue ([exemple](/assets/operations/exemple_offre.txt)), elle est enregistrée dans le navigateur à l'aide de `setRemoteDescription` pour initialiser le data plane. -On peut débugger le signaling WebRTC sous Chromium avec [chrome://webrtc-internarls](chrome://webrtc-internals/). - - -Quand plus de deux participants sont connectés dans la conversation, Jitsi n'envoie pas les offres de chaque participant aux autres participants. À la place, elle envoie qu'une seule offre, celle de son VideoBridge. - -Ainsi, le VideoBridge est une sorte de client WebRTC particulier, qui récolte et redispatche à travers WebRTC tous les flux video/audio. - -#### Le data plane de Jitsi : videobridge sur DTLS/SCTP via WebRTC - -WebRTC utilise deux formats de paquets selon [Mozilla Developer Network|RTCDataChannel|DataFormat](https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel#Data_format) : -- `UDP/DTLS/SCTP` -- `TCP/DTLS/SCTP` - -On a donc un format de données arbitraire encapsulé dans du SCTP lui-même encapsulé dans du DTLS. -DTLS est prévu pour les datagrammes à l'origine, car WebRTC est prévu d'abord pour fonctionner sous UDP. -Le TCP est là en mode dégradé, en secours, il sert juste de tunnel pour relayer des datagrammes. \ No newline at end of file diff --git a/content/operations/_index.md b/content/operations/_index.md index 29ebdef..17843e4 100644 --- a/content/operations/_index.md +++ b/content/operations/_index.md @@ -2,8 +2,14 @@ title = "Opérations" description = "Opérations" weight = 100 +sorted_by = "weight" +++ -# Opérations +# Définitions + +* _Une grappe_, c'est **un ensemble d'ordinateurs, au moins trois** pour obtenir une grappe bien solide. + + Une grappe est **gérée de façon cohérente** (avec le même système logiciel), **plus ou moins autonome** (elle ne dépend pas du reste du monde pour fournir des services web), **par une entité définie** (une personne physique ou un groupe de personnes). + +* _Les opérateur·ices_ de la grappe ont **deux responsabilités** principales : **la maintenance** de la grappe, et **la protection des données hébergées**. -Ceci est un manuel diff --git a/content/operations/app/Jitsi.md b/content/operations/app/Jitsi.md new file mode 100644 index 0000000..4563c73 --- /dev/null +++ b/content/operations/app/Jitsi.md @@ -0,0 +1,105 @@ +--- +title: Jitsi +description: +published: true +date: 2021-11-09T12:53:23.811Z +tags: +editor: markdown +dateCreated: 2021-11-09T12:46:50.731Z +--- + +## 2020-04-02 Campagne de debug Jitsi + +Contact: Quentin + +### Description du problème + +Les conversations à 3+ donc relayées par le serveur ne fonctionnent pas bien. +Louison m'a rapporté que ça avait marché pour lui (3 utilisateurs avec un Webkit). +Mais moi ça a échoué hier soir (01/04/2020) avec des participants sous Firefox. +Le bug est toujours le même : on entend 2 personnes sur 3 ou on voit 2 personnes sur 3, on recharge la page et c'est quelqu'un d'autre pour qui ça ne fonctionne plus. Souvent c'est que dans un sens. +À chaque fois en passant sur Facebook Messenger, le problème est résolu instantanément. +Par contre Facebook Messenger impose Google Chrome/Chromium pour les visio de groupe (et ne supporte donc pas Firefox). + +D'où mes 2 suspicions : + +- Firefox a un bug quelconque dans sa pile WebRTC déclenché par le mode conversation de groupe +- Jitsi a un problème avec les déconnexions/changement de connexion/petit hoquets du réseau et n'arrive pas à se reconnecter. Ça pourrait être rendu pire à certain moment de la journée comme le soir où le réseau est plus sollicité. Et ce serait provoqué lors du reload on repasse de 3 à 2, en P2P donc puis de nouveau de 2 à 3. + +### Approfondissement + +Avant d'aller plus loin, nous avons voulu prendre le temps d'identifier précisément les problèmes d'expérience utilisateurs et leur corrélation avec la plateforme de l'utilisateur (navigateur, OS). + +Pour celà, nous avons suivi deux approches : +1. Mener nos propres tests +2. Chercher d'autres retours + +#### Mener nos propres tests + +Nous avons effectué deux appels : un avec Firefox seulement et un avec Chrome/Chromium seulement. +Merci à Alex, Adrien et Maximilien pour leur participation. + +Voilà les conclusions que nous avons tirées de nos tests : + +- L'appel avec Firefox a déclenché le bug immédiatement, peu importe la version de Firefox ou de l'OS (firefox stable/nightly, fedora stable/beta, etc.) +- Le passage de tout le monde sous Chrome/Chromium a permis d'avoir une conversation stable. +- Adrien avait sa Livebox avec pare-feu configuré en mode "élevé" et a dû ajouter dans sa liste blanche les ports utilisés par Jitsi (`4443/tcp` et `10000/udp` au moment du test, seul un des deux a besoin d'être accessible) + +Nous avons donc demandé à Adrien quels étaient les ports ouverts par défaut dans le mode élevé de sa box : + +![Livebox Parefeu Personnalisé](/img/operations/livebox_parefeu_personnalise.png) + +Nous avons dans un premier temps retenu le port `995/tcp` pour Jitsi, le port UDP ne pouvant être changé (limitation de Jitsi). +Cependant, pour des raisons de sécurité, les navigateurs ne peuvent pas utiliser les ports en dessous de `1024/*`, à l'exception des ports `80/tcp` et `443/tcp` comme l'indique ;'issue [#3583](https://bugs.chromium.org/p/webrtc/issues/detail?id=3583) de Chromium. + +La capture n'indique pas de port TCP supérieur à 1024, nous ne pouvons donc pas résoudre ce problème de notre côté, car à l'heure actuelle, nos ports `80/tcp` et `443/tcp` sont utilisés et nous n'avons qu'une seule IP publique. +Les utilisateurs activant le parefeu en mode élevé devront ajouter une exception dans leur parefeu eux-mêmes. + +#### Chercher d'autres retours + +[Tedomum](https://tedomum.net/) a eu connaissance de problèmes similaires. +Ils ont également identifié Firefox et assurent qu'avec l'application Android ça marche bien. +Ils me confirment que le problème vient bien du logiciel et non pas de notre déploiement. +Ils m'ont pointé entre autres vers cette issue github [#4758](https://github.com/jitsi/jitsi-meet/issues/4758) +Apparemment une issue est dédiée en particulier au problème que nous rencontrons de déconnexion partielle d'un participant, mais nous ne l'avons pas encore retrouvée. + +### Correctifs + + 1. Notre instance Jitsi a été reconfigurée pour refuser Firefox. Suivre l'avancée du développement de Jitsi pour Firefox + * [#4758](https://github.com/jitsi/jitsi-meet/issues/4758) + * [#5439](https://github.com/jitsi/jitsi-meet/issues/5439) + * _À compléter_ + 2. Pour relayer la vidéo à travers la plupart des parefeux, notre `videobridge` Jitsi devait écouter sur le port `443/tcp`. Or ce port est déjà utilisé par notre frontal HTTPS. À défaut, Jitsi est maintenant configuré avec `8080/tcp` et `10000/udp` (contre `4443/tcp` et `10000/udp` avant). + * Un déploiement en IPv6 pourrait résoudre le problème pour une partie des utilisateurs + * Avoir un cluster géo-distribué avec plusieurs IPv4 pourrait également résoudre le problème + * Avoir un frontend layer 4 (niveau TCP) qui trouve une signature pour router du DTLS vers videobridge et du TLS vers traefik + +### À propos du control/data plane de Jitsi + +Notre videobridge écoute donc sur les ports `8080/tcp` et `10000/udp`. + +WebRTC fonctionne en deux étapes : +- Des offres doivent être échangées via un serveur de signaling quelconque +- Ensuite, ces offres servent à connecter des clients directement via un protocole TCP ou UDP avec un thin layer propre à WebRTC + +#### Le control plane de Jitsi : Prosody sur HTTPS via Bosh/XMPP + +Le serveur de signaling Jitsi n'est autre que le serveur de chat prosody. +Pour ça, prosody est exposé à travers HTTP grâce au protocole BOSH (XMPP overs HTTPS). +Une fois l'offre reçue ([exemple](/assets/operations/exemple_offre.txt)), elle est enregistrée dans le navigateur à l'aide de `setRemoteDescription` pour initialiser le data plane. +On peut débugger le signaling WebRTC sous Chromium avec [chrome://webrtc-internarls](chrome://webrtc-internals/). + + +Quand plus de deux participants sont connectés dans la conversation, Jitsi n'envoie pas les offres de chaque participant aux autres participants. À la place, elle envoie qu'une seule offre, celle de son VideoBridge. + +Ainsi, le VideoBridge est une sorte de client WebRTC particulier, qui récolte et redispatche à travers WebRTC tous les flux video/audio. + +#### Le data plane de Jitsi : videobridge sur DTLS/SCTP via WebRTC + +WebRTC utilise deux formats de paquets selon [Mozilla Developer Network|RTCDataChannel|DataFormat](https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel#Data_format) : +- `UDP/DTLS/SCTP` +- `TCP/DTLS/SCTP` + +On a donc un format de données arbitraire encapsulé dans du SCTP lui-même encapsulé dans du DTLS. +DTLS est prévu pour les datagrammes à l'origine, car WebRTC est prévu d'abord pour fonctionner sous UDP. +Le TCP est là en mode dégradé, en secours, il sert juste de tunnel pour relayer des datagrammes. \ No newline at end of file diff --git a/content/operations/app/_index.md b/content/operations/app/_index.md new file mode 100644 index 0000000..8c93fad --- /dev/null +++ b/content/operations/app/_index.md @@ -0,0 +1,8 @@ ++++ +title = "Applications" +description = "Gestion des applicatifs" +sorted_by = "weight" +weight = 30 ++++ + + diff --git a/content/operations/app/email.md b/content/operations/app/email.md new file mode 100644 index 0000000..60a03f5 --- /dev/null +++ b/content/operations/app/email.md @@ -0,0 +1,30 @@ +--- +title: Emails +description: Emails +--- + +# Support d'un nom de domaine personnalisé + + 1. xxx + 1. Communiquez lui votre nom de domaine pour qu'il l'ajoute dans `ou=domains,ou=groups,dc=deuxfleurs,dc=fr` + 2. Communiquez lui l'adresse email que vous souhaitez pour qu'il change l'entrée `mail` dans votre profil utilisateur + 3. Si vous souhaitez avoir une boite mais plusieurs alias, demandez un champs `uid` dans votre profil utilisateur + + 2. Vous devez ensuite rajouter les entrées pour votre nom de domaine en éditant votre zone : + 1. L'entrée MX pour recevoir les emails +```bind +@ MX 10 email-in.deuxfleurs.fr +``` + 2. L'entrée SPF pour autoriser notre IP à délivrer des emails en votre nom : +```bind +@ TXT "v=spf1 mx:out.deuxfleurs.fr -all" +``` + 3. L'entrée DKIM pour autoriser notre postfix+opendkim à délivrer des emails en votre nom : +``` +smtp._domainkey TXT "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtdZp4qrgZR+6R7HeAkuLGJ/3L/6Ungvf5zwrMq6T8Tu931j2G4lYuPtsxyn9fZkT4y7DlX0waktLDBOCwf7X78nLEWjAFWiJTeWGRGhRdYRUFpscs9NUN0P+46jKlabibG3XTKd1DeAmywTu6o1oO03yiolrgKD1zgyDRFeUTfSwZIdPrdbcBSA1arda4WFtcBIrSygM9b4jtlqfQwGDrsMLbCBfVHDn4WfmDWyNg0gDAkuLrYClNETk6aqIyj9fC8srKri0Qp3cRagCn+fjBvuxP35qWWJH7Rnnh/tuEDr1ufuNYO2KgJZ7JdMidUotxXE8cfU+OrEWQf4mIYeJ4wIDAQAB" +``` + 4. L'entrée DMARC pour indiquer le comportement à adopter si les contraintes précédentes ne sont pas satisfaites : +``` +_dmarc TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:contact@deuxfleurs.fr!10m; ruf=mailto:contact@deuxfleurs.fr!10m; rf=afrf; pct=100; ri=86400" +``` + 3. C'est tout ! Vous devrez probablement attendre 24/48h que les changements se propagent. diff --git a/content/operations/email.md b/content/operations/email.md deleted file mode 100644 index 60a03f5..0000000 --- a/content/operations/email.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Emails -description: Emails ---- - -# Support d'un nom de domaine personnalisé - - 1. xxx - 1. Communiquez lui votre nom de domaine pour qu'il l'ajoute dans `ou=domains,ou=groups,dc=deuxfleurs,dc=fr` - 2. Communiquez lui l'adresse email que vous souhaitez pour qu'il change l'entrée `mail` dans votre profil utilisateur - 3. Si vous souhaitez avoir une boite mais plusieurs alias, demandez un champs `uid` dans votre profil utilisateur - - 2. Vous devez ensuite rajouter les entrées pour votre nom de domaine en éditant votre zone : - 1. L'entrée MX pour recevoir les emails -```bind -@ MX 10 email-in.deuxfleurs.fr -``` - 2. L'entrée SPF pour autoriser notre IP à délivrer des emails en votre nom : -```bind -@ TXT "v=spf1 mx:out.deuxfleurs.fr -all" -``` - 3. L'entrée DKIM pour autoriser notre postfix+opendkim à délivrer des emails en votre nom : -``` -smtp._domainkey TXT "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtdZp4qrgZR+6R7HeAkuLGJ/3L/6Ungvf5zwrMq6T8Tu931j2G4lYuPtsxyn9fZkT4y7DlX0waktLDBOCwf7X78nLEWjAFWiJTeWGRGhRdYRUFpscs9NUN0P+46jKlabibG3XTKd1DeAmywTu6o1oO03yiolrgKD1zgyDRFeUTfSwZIdPrdbcBSA1arda4WFtcBIrSygM9b4jtlqfQwGDrsMLbCBfVHDn4WfmDWyNg0gDAkuLrYClNETk6aqIyj9fC8srKri0Qp3cRagCn+fjBvuxP35qWWJH7Rnnh/tuEDr1ufuNYO2KgJZ7JdMidUotxXE8cfU+OrEWQf4mIYeJ4wIDAQAB" -``` - 4. L'entrée DMARC pour indiquer le comportement à adopter si les contraintes précédentes ne sont pas satisfaites : -``` -_dmarc TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:contact@deuxfleurs.fr!10m; ruf=mailto:contact@deuxfleurs.fr!10m; rf=afrf; pct=100; ri=86400" -``` - 3. C'est tout ! Vous devrez probablement attendre 24/48h que les changements se propagent. diff --git a/content/operations/grappe/_index.md b/content/operations/grappe/_index.md new file mode 100644 index 0000000..f904d8c --- /dev/null +++ b/content/operations/grappe/_index.md @@ -0,0 +1,8 @@ ++++ +title = "Grappe" +description = "Gestion d'une grappe" +sorted_by = "weight" +weight = 20 ++++ + + diff --git a/content/operations/noeud/_index.md b/content/operations/noeud/_index.md new file mode 100644 index 0000000..4e894fd --- /dev/null +++ b/content/operations/noeud/_index.md @@ -0,0 +1,7 @@ ++++ +title = "Noeuds" +description = "Gestion des noeuds" +sorted_by = "weight" ++++ + + diff --git a/content/operations/noeud/deploiement.md b/content/operations/noeud/deploiement.md new file mode 100644 index 0000000..dcc348f --- /dev/null +++ b/content/operations/noeud/deploiement.md @@ -0,0 +1,51 @@ +--- +title: Déploiement +description: Déploiement d'un noeud +published: true +date: 2022-01-09T13:29:29.710Z +tags: installation, serveur, infrastructure, réseau, sysadmin, site géographique, technique, administration +editor: markdown +dateCreated: 2021-12-28T14:33:59.088Z +--- + + +Dans ce guide, nous allons expliquer comment installer une grappe de serveurs, en vue d'un hébergement pour Deuxfleurs. + + + +# Choix des ordinateurs + +Héberger des services web est une tâche à la portée de la plupart des ordinateurs des 10 dernières années. Néanmoins, essayer de faire tourner correctement des applications lourdes sur une toute petite machine n'est pas une partie de plaisir. Alors, quitte à installer une nouvelle grappe, la vie sera plus agréable si ses machines disposent d'au moins : + +* 4 Go de RAM +* 1 To de disque (dur ou SSD) + +# Choix d'un site géographique + +Dans un *site géographique*, on installe une *grappe d'ordinateurs* au sein d'un *réseau local*, qu'on connecte au cluster de Deuxfleurs. + +On peut distinguer deux types de sites : + +* _Dans un centre de données_ : chaque ordinateur de la grappe appartient au même centre de données, dispose d'une adresse IP fixe qui le connecte directement à Internet. + + Dans ce cas-ci, **l'installation et l'administration sont assez simples** (on a moins de concepts à avaler que chez un particulier). + Par contre, **nous ne sommes pas chez nous** : le propriétaire du centre de données peut accéder aux disques, et voit ce qui passe sur le réseau. **Chiffrement du disque vivement conseillé.** + +* _Chez un particulier_ : la grappe est reliée à Internet par une *box*, qui filtre le trafic réseau selon des règles variables. La grappe se partage l'adresse IP de la box (qui peut changer régulièrement, être en IPv4 ou en IPv6). + + Dans ce cas de figure, **l'installation comme l'administration demandent plus de connaissances** : pour caricaturer, on doit installer et administrer la grappe **malgré le Fournisseur d'Accès Internet** (FAI), qui considère *a priori* que son abonnement ne sert pas à héberger des services web. + + On aura affaire à sa box (NAT, pare-feu...), au manque de garanties concernant notre adressabilité (IPv4 dynamique, IPv6 ? ...), ce qui va nous mener à devoir faire du routage. Le nœud du problème, c'est que chaque ordinateur de la grappe n'aura pas pignon sur rue (pas d'adresse IP publique et fixe par machine). + + Néanmoins, **on est chez nous !** Votre disque dur - qui contient les données personnelles de vos usagers chéris - est sous vos yeux, bien au chaud. Le seul curieux qui voit passer votre trafic réseau est votre FAI : *rien de nouveau sous le soleil*. + +Dans les deux cas - grâce à [la magie des VPN](/Technique/Infra/Wireguard) - on pourra communiquer sans souci avec le reste du cluster de Deuxfleurs. + +**À terme, chez Deuxfleurs, on compte héberger toute notre infrastructure chez des particuliers.** Mais [la route est encore longue](/Technique/Jalons/Interconnexion) avant que nous ayons assez de bonnes connexions et des ordinateurs suffisamment puissants, sans parler du système de gestion logiciel. +Ainsi, **pour le moment, il est tout à fait acceptable d'héberger des services Deuxfleurs en centre de données** : tant qu'on en informe nos usagers et qu'on fait attention à la sécurité. + +# Installation des ordinateurs + +Pour chaque ordinateur de notre future grappe, nous allons avoir besoin d'en configurer le ou les disques, de les chiffrer éventuellement, et d'installer son système d'exploitation. + + -- cgit v1.2.3