Code source wiki de Guide de l’infrastructure

Version 106.1 par Clément AUBIN le 2021/03/22 11:59
Masquer les derniers auteurs
Aubincleme 105.1 1 Bonjour !
2
3 Ce guide a pour but, avec le moins de prétention possible, de faire état du fonctionnement général du système d’information d’ATILLA. //En théorie//, ce guide devrait suivre les évolutions de l’infrastructure et s’adapter en conséquence … mais bon, faire de la doc, ça n’a jamais été très intéressant ~^~^.
4
5 Nous espérons qu’avec ce guide et les ressources qui lui sont attachées, le SI d’ATILLA pourra continuer à évoluer au fil des ans et des bureaux.
6
7 //By the way//, comme l’exercice consistant à créer un guide totalement objectif semble pour nous quelque chose d’impossible, soyons bien d’accord : il y aura des endroits ou nous donnerons nos avis, aussi nuls soit-il ; //deal with it//.
8
9 Bisous,
10
11 Les admins <3
12
13 {{toc/}}
14
15 == Prérequis ==
16
17 Faire de l’administration système à ATILLA peut se résumer à trois points :
18
19 * Installer des machines (virtuelles ou non)
20 * Déployer et maintenir les services de l’association
21 * Résoudre des problèmes simples en matière d’architecture réseau
22
23 Il faut donc pour cela disposer d’une bonne connaissance du fonctionnement d’un système Linux ainsi que du fonctionnement des réseaux IPv4. Le principal défi est de pouvoir apprendre cela en parallèle des cours dispensés au sein de l’EISTI (à la date d’écriture de ce guide, nous ne disposons que d’un module sur le fonctionnement des réseaux au S2 d’ING2 qui touche de plus ou moins loin ce que nous traiterons ici).
24
25 === Se former ===
26
27 Du coup, comment apprendre ? Plusieurs moyens s’offrent à vous, choisissez celui qui vous va le mieux :) !
28
29 * Utiliser la littérature à votre disposition en CY106 : vous trouverez quelques livres décrivant le fonctionnement de Linux en général. Attention : il est possible que certaines commandes présentes dans ces ouvrages soient obsolètes.
30 * Demander aux personnes en place : vous pouvez joindre les administrateurs système d’ATILLA IRL ou bien par mail aux adresses suivantes : {{code}}admins[you know what]lists.atilla.org{{/code}}, {{code}}admin[you know what]atilla.org{{/code}} ou bien {{code}}root[you know what]atilla.org{{/code}}. Notons que les administrateurs système (et ingénieurs réseau) de l’EISTI ne rechignent généralement pas à répondre à vos questions (il suffit de dire que vous venez pour ATILLA ~^~^).
31 * Internet
32 * Apprendre sur le tas : en terme de pédagogie, ce n’est pas le top, mais ça s’applique parfaitement au sein d’ATILLA : il y a toujours des choses à changer et à améliorer. À vous d’amadouer un admin pour qu’il vous fournisse un accès sur un ou plusieurs serveurs :p.
33
34
35
36 === L’état d’esprit ===
37
38 Ce n’est pas quelque chose dont on parle souvent, mais je pense que cela compte beaucoup. Travailler au sein de l’administration système d’ATILLA, c’est évidemment pouvoir tester de nouvelles choses, mais aussi (et surtout) fournir un ensemble de services sur lesquels le reste de l’association peut se reposer (pour développer des projets, pour diffuser des talks et des conférences, …). Pour moi, avoir accès aux serveurs de l’association, c’est un énorme privilège mais aussi une énorme responsabilité. À partir du moment ou vous disposez d’un accès à un serveur, vous devenez automatiquement garant de son bon fonctionnement.
39
40 == Réseau ==
41
42 Parlons dans un premier temps du réseau. Comme ATILLA se trouve au sein de l’EISTI, nous ne disposons que de très peu de marge de maneuvre pour ce qui est de choisir nos plages IP. On peut distinguer deux réseaux au sein de l’association :
43
44 * Un réseau {{code}}ATILLA{{/code}} dédié aux serveurs et aux services de l’association. Il dispose de la plage IP {{code}}192.168.10.0/24{{/code}}.
45 * Un réseau {{code}}ATILLA-CY106{{/code}} pour gérer l’ensemble des équipements présents dans la salle CY106. Il dispose de la plage IP {{code}}192.168.253.0/24{{/code}}.
46
47 Chacun de ces deux réseaux dispose de son accès internet propre, en ce qui concerne le réseau {{code}}ATILLA{{/code}}, nous disposons de trois IP publiques que nous répartissons sur nos serveurs. A la date d’écriture de ce guide, notre passerelle est {{code}}Laïka{{/code}} avec l’IP publique {{code}}193.48.70.11{{/code}}. Il est à noter que ces trois adresses IP se trouvent sur le réseau EISTI {{code}}DMZ-RENATER{{/code}} : l’accès internet à ce réseau se fait donc par le biais du FAI … Renater !
48
49 D’un autre côté, le réseau {{code}}ATILLA-CY106{{/code}} se sert d’{{code}}Hydra{{/code}} comme passerelle. L’accès internet est fourni par un NAT sur le FAI Level3.
50
51 Par convention, nous définissons notre passerelle sur l’IP privée {{code}}192.168.XXX.1{{/code}}. Ainsi, {{code}}Laïka{{/code}} dispose de l’IP privée {{code}}192.168.10.1{{/code}} ; par ailleurs, {{code}}Hydra{{/code}} dispose de l’IP privée {{code}}192.168.253.1{{/code}}.
52
53 === Réseau {{code}}ATILLA-CY106{{/code}} ===
54
55 Comme dit précédemment, on trouve sur ce réseau à peu près tout ce qui se trouve en CY106. Le routage est assuré par {{code}}Hydra{{/code}} ({{code}}192.168.253.1{{/code}}). Notons qu’{{code}}Hydra{{/code}} assure également les services de DHCP et de DNS.
56
57 **ATTENTION : ** La configuration DHCP et DNS d’{{code}}Hydra{{/code}} est semi-automatique ; en effet, nous exportons une partie de ces configurations à partir de la plateforme [[members.atilla.org>>url:https://members.atilla.org]] (plus d’informations sont disponibles sur l’article [[Main.Members\.atilla\.org]]).
58
59 ==== Conservation des données de connexion ====
60
61 Depuis octobre 2016, nous avons obligation de logguer l’ensemble du trafic transitant sur le réseau {{code}}ATILLA-CY106{{/code}} … principalement pour savoir sur qui taper en cas de téléchargement illégal. Pour ce faire, nous utilisons deux ressources :
62
63 * Les fichiers de log du serveur DHCP : ils nous permettent de faire correspondre une adresse MAC à une adresse IP ; voici un exemple de logs :
64
65 {{code}}Jan 30 22:02:30 hydra dhcpd: DHCPREQUEST for 192.168.253.XXX from 00:00:00:00:00:00 via eth1{{/code}}
66
67 {{code}}Jan 30 22:02:30 hydra dhcpd: DHCPACK on 192.168.253.XXX to 00:00:00:00:00:00 via eth1{{/code}}
68
69 * Nous enregistrons également les en-têtes des paquets IP transitant par {{code}}Hydra{{/code}} à l’aide d’[[Ulogd2>>url:http://rlworkman.net/howtos/ulogd.html]]. Ce stocke ses informations dans une base de données Postgresql {{code}}logs{{/code}} directement sur {{code}}Hydra{{/code}}.
70
71 Notons qu’il nous est possible de faire correspondre une adresse MAC à un nom d’utilisateur en utilisant les mécanismes d’authentification RADIUS présents sur le réseau {{code}}ATILLA-CY106{{/code}}.
72
73 ==== Gestion des points d’accès au réseau ====
74
75 Pour pouvoir se connecter au réseau {{code}}ATILLA-CY106{{/code}}, il existe deux moyens principaux :
76
77 * Se brancher à une prise murale lié à un des deux switchs de la salle
78 * Passer par le réseau wifi {{code}}ATILLA{{/code}}
79
80 Les deux switchs {{code}}switch-b1{{/code}} ({{code}}192.168.253.4{{/code}}) et {{code}}switch-b2{{/code}} ({{code}}192.168.253.5{{/code}}) sont accessibles via telnet, via une interface web, ou bien via un port série au dos du switch.
81
82 Le réseau wifi est diffusé par un routeur situé à proximité de la baie réseau : {{code}}ap-wifi{{/code}} ({{code}}192.168.253.3{{/code}}) accessible via ssh ou bien via une interface web.
83
84 **ATTENTION : ** En ce qui concerne le routeur wifi, il est déconseillé d’utiliser l’interface web pour modifier les paramètres du routeur : en effet, nous utilisons une configuration wifi ne pouvant pas être affichée sur l’interface web ; vous risquez de casser des paramètres sans vous en rendre compte.
85
86 ==== Gestion de la connexion au réseau ====
87
88 Afin de pouvoir faire correspondre une adresse MAC à un nom d’utilisateur, nous avons mis en place un système d’authentification [[802.1x>>url:http://www.rfc-archive.org/getrfc.php?rfc=3580]] au sein du réseau {{code}}ATILLA-CY106{{/code}}. Le détail de ce système est expliqué dans l’article [[Main.Authentification_RADIUS]].
89
90 Évidemment, le serveur RADIUS loggue toutes les tentatives d’authentification, pour information, voici un exemple de logs pour une connexion :
91
92 {{code}}Sat Jan 28 19:47:42 2017 : Auth: (3636) Login OK: [aubincleme] (from client ap_wifi port 0 via TLS tunnel){{/code}}
93
94 {{code}}Sat Jan 28 19:47:42 2017 : Auth: (3636) Login OK: [aubincleme] (from client ap_wifi port 6 cli XX-XX-XX-XX-XX-XX){{/code}}
95
96 === Réseau {{code}}ATILLA{{/code}} ===
97
98 Sur le réseau {{code}}ATILLA{{/code}}, les choses fonctionnent un peu différemment : comme nous considérons que les personnes ayant accès aux serveurs de ce réseau sont des personnes de confiance, nous ne conservons pas de données de connexion ; il n’y a également pas d’authentification RADIUS sur ce réseau.
99
100 Il est à noter qu’ATILLA dispose à l’heure de la création de ce guide de 5 serveurs physiques :
101
102 * {{code}}bill.atilla.org{{/code}}
103 * {{code}}laika.atilla.org{{/code}}
104 * {{code}}idefix.infra.atilla.org{{/code}}
105 * {{code}}snoopy.infra.atilla.org{{/code}}
106 * {{code}}touffu.infra.atilla.org{{/code}}
107
108 Les serveurs {{code}}bill.atilla.org{{/code}} et {{code}}laika.atilla.org{{/code}} sont les deux seuls serveurs physiques à disposer d’une adresse IP (publique) sur le réseau {{code}}DMZ-RENATER{{/code}}.
109
110 Pour donner plus de flexibilité à la gestion de l’infrastructure, nous utilisons //massivement// les capacités de virtualisation de nos serveurs. Ainsi, la plupart de nos services fonctionnent sur des machines virtuelles (VMs) dédiées. Ces machines virtuelles sont stockées sur nos trois serveurs les plus récents : {{code}}Bill{{/code}}, {{code}}Laïka{{/code}} ou {{code}}Touffu{{/code}}.
111
112 ==== Découpage du réseau ====
113
114 Depuis février 2016, afin de rendre l’organisation de notre infrastructure plus cohérente, nous avons décidé de découper le réseau {{code}}ATILLA{{/code}} ({{code}}192.168.10.0/24{{/code}}) en 6 «sous-réseaux». Il est à noter que ces sous-réseaux n’ont de réseau que le nom : il s’agit simplement d’une convention entre les admins pour que nous sachions qu’un serveur dédié à la production se trouve forcément entre les adresses IP X et Y.
115
116 Voici le découpage IP actuellement en place :
117
118 * {{code}}192.168.10.0/27 - *.infra.atilla.org{{/code}} : Réseau dédié aux serveurs et équipements physiques (comme les EisTV) ;
119 * {{code}}192.168.10.32/27 - *.vps.infra.atilla.org{{/code}} : Réseau dédié aux serveurs privés virtuels (VPS) de l’association. Ce réseau n’est plus utilisé depuis septembre 2016 car nous n’acceptons plus l’hébergement de VPS ;
120 * {{code}}192.168.10.64/26 - *.prod.infra.atilla.org{{/code}} : Réseau dédié aux services utilisés en production ;
121 * {{code}}192.168.10.128/26 - *.test.infra.atilla.org{{/code}} : Réseau dédié aux services utilisés en test ;
122 * {{code}}192.168.10.192/27 - *.preprod.infra.atilla.org{{/code}} : Réseau dédié aux services utilisés en pré-production ;
123 * {{code}}192.168.10.224/27 - *.dev.infra.atilla.org{{/code}} : Réseau dédié aux services utilisés en développement.
124
125
126
127 ==== Serveur DHCP ====
128
129 Une grande majorité des serveurs du réseau {{code}}ATILLA{{/code}} prennent leur adresse IP //via// un serveur DHCP installé sur un de nos serveurs physiques (actuellement, il s’agit de {{code}}Bill{{/code}}). Toute la configuration DHCP de l’infrastructure est disponible aux membres de l’association via [[ce dépôt Git>>url:https://gitlab.atilla.org/adminsys/dhcp-config]] par souci de transparence. Nous découpons la configuration DHCP selon les 6 réseaux présentés précédemment ; on notera que ce serveur ne propose aucune //range// dynamique pour l’accueil de nouveaux équipements réseau, il faut donc modifier la configuration DHCP à l’ajout de toute nouvelle machine.
130
131 ==== Serveur DNS ====
132
133 Tout comme le serveur DHCP, le serveur DNS de notre infrastructure se trouve sur {{code}}Bill{{/code}}. De même, par souci de transparence, nous publions l’ensemble de notre configuration DNS sur [[ce dépôt Git>>url:https://gitlab.atilla.org/adminsys/dns-config]], accessible à tous les membres de l’association et de [[gitlab.atilla.org>>url:https://gitlab.atilla.org]].
134
135 On distingue deux configurations DNS distinctes :
136
137 * Une configuration {{code}}external{{/code}} pour toutes les adresses externes à l’EISTI ;
138 * Une configuration {{code}}internal{{/code}} pour toutes les requêtes provenant de l’intérieur de l’EISTI.
139
140
141
142 ===== Configuration {{code}}external{{/code}} =====
143
144 Dans cette configuration, on ne trouve que deux zones : {{code}}*.atilla.org{{/code}} et {{code}}*.eistiens.net{{/code}}. Il n’y a pas grand-chose à spécifier sur ces dernières, si ce n’est qu’elles ne servent qu’à rediriger un utilisateur vers notre frontal web, on trouvera donc souvent ce genre d’enregistrement : {{code}}random-vhost IN CNAME frontal-web{{/code}}
145
146 Comme il s’agit des zones DNS accessibles depuis l’extérieur de l’EISTI, ces dernières contiennent nos enregistrements {{code}}SPF{{/code}} pour les domaines {{code}}atilla.org{{/code}} et {{code}}eistiens.net{{/code}} et les enregistrements {{code}}DKIM{{/code}} et {{code}}DMARC{{/code}} pour le domaine {{code}}atilla.org{{/code}}.
147
148 ===== Configuration {{code}}internal{{/code}} =====
149
150 La configuration {{code}}internal{{/code}} est bien plus intéressante, en effet, c’est dans cette dernière que nous définissons les résolutions internes de toutes nos machines. Cette configuration est scindée en trois types de fichiers :
151
152 * Les fichiers de zone {{code}}*.eistiens.net{{/code}} et {{code}}*.atilla.org{{/code}} : ils ont peu ou prou le même objectif que ceux de la configuration {{code}}external{{/code}} : rediriger un utilisateur venant du réseau de l’EISTI et souhaitant se connecter à un service vers notre frontal web ;
153 * Le fichier de reverse-dns : {{code}}db.10.168.192.in-addr.arpa{{/code}} ; il nous permet (comme son nom l’indique) de publier les enregistrements reverse-dns des serveurs du réseau {{code}}192.168.10.0/24{{/code}} et ainsi de pouvoir faire correspondre à une adresse IP un FQDN ;
154 * Les 6 autres fichiers restants sont les suivants :
155 ** {{code}}db.infra.atilla.org{{/code}}
156 ** {{code}}db.vps.infra.atilla.org{{/code}}
157 ** {{code}}db.prod.infra.atilla.org{{/code}}
158 ** {{code}}db.test.infra.atilla.org{{/code}}
159 ** {{code}}db.preprod.infra.atilla.org{{/code}}
160 ** {{code}}db.test.infra.atilla.org{{/code}}
161
162 : Ces fichiers servent à publier les enregistrements DNS des serveurs se trouvant dans les «sous-réseaux» que nous avons définis auparavant. Dans chacun de ces fichiers, on retrouve le //subnet ID// du réseau correspondant, ainsi que deux enregistrements DNS {{code}}gateway{{/code}} et {{code}}broadcast{{/code}} correspondant tous les deux aux adresses IP de début et de fin du réseau.
163
164
165
166 ==== Politique de nommage des machines virtuelles ====
167
168 Nous avons tendance à en rire, mais au premier coup d’œil, la manière dont nous nommons nos machines virtuelles peut paraître invraisemblable.
169
170 Je m’explique. Prenons par exemple une machine virtuelle actant comme un serveur MySQL utilisé en environnement de test. Le nom (//hostname//) de la machine sera {{code}}mysql-test{{/code}} et cette dernière se trouvera dans le réseau {{code}}test.infra.atilla.org{{/code}}. Le [[FQDN>>url:https://fr.wikipedia.org/wiki/Fully_qualified_domain_name]] de cette machine sera donc : {{code}}mysql-test.test.infra.atilla.org{{/code}}
171
172 … mais, mais, mais … pourquoi diable suffixer le nom des machines virtuelles par leur environnement associé alors que ce dernier est également présent dans le nom du réseau auquel la machine appartient ?
173
174 À cette question, nous avons deux réponses :
175
176 1. Une machine peut se retrouver (par mégarde) sur le mauvais réseau ; il devient ainsi difficile de la différencier d’une machine virtuelle semblable appartenant à un environnement différent ;
177 1. La configuration actuelle des prompt Bash ({{code}}$PS1{{/code}}) de nos machines virtuelles n’affiche que le nom de la machine et non son FQDN. Sans suffixer le nom de la machine, il est impossible de distinguer du premier coup d’œil une machine virtuelle dans un environnement de production de son homologue dans un environnement de développement.
178
179
180
181 == Liens utiles ==
182
183 Vous trouverez ci-après un ensemble (plus ou moins structuré) de liens vers des documentations & tutoriels vous permettant d’en apprendre un peu plus sur l’admiminstration système.
184
185 === Réseau ===
186
187 ==== (Network) Bridges ====
188
189 * Qu’est-ce que c’est ? url:https://en.wikipedia.org/wiki/Bridging_(networking)
190 * Documentation Debian : url:https://wiki.debian.org/BridgeNetworkConnections
191 * Tutoriel simple pour mettre en place un bridge : url:https://www.cyberciti.biz/faq/debian-network-interfaces-bridge-eth0-eth1-eth2/
192
193 ==== Domain Name System (DNS) ====
194
195 * Qu’est-ce que c’est ? url:https://en.wikipedia.org/wiki/Domain_Name_System
196 * Monter un DNS avec Bind9 : url:https://www.it-connect.fr/dns-avec-bind-9%ef%bb%bf/
197
198 ==== Dynamic Host Configuration Protocol (DHCP) ====
199
200 * Qu’est-ce que c’est ? url:https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
201 * «Peut-on mettre en place plusieurs serveurs DHCP sur un même réseau ?» : url:https://serverfault.com/questions/368512/can-i-have-multiple-dhcp-servers-on-one-network
202
203 ==== Preboot Execution Environment (PXE) ====
204
205 * Qu’est-ce que c’est ? url:https://en.wikipedia.org/wiki/Preboot_Execution_Environment
206 * Le site d’IPXE : url:http://ipxe.org/
207 * La //specification// d’Intel : url:http://www.pix.net/software/pxeboot/archive/pxespec.pdf
208
209 ==== Théorie ====
210
211 Parfois, ça ne fait pas de mal de revenir aux fondamentaux ~^~^.
212
213 * Le modèle OSI : url:https://en.wikipedia.org/wiki/OSI_model
214 * //The TCP/IP Guide// : url:http://tcpipguide.com/free/index.htm
215 * Le NAT (Network Address Translation) : url:https://en.wikipedia.org/wiki/Network_address_translation
216
217 ==== Virtual LANs (VLANs) ====
218
219 * Qu’est-ce que c’est ? url:https://en.wikipedia.org/wiki/Virtual_LAN
220 * Norme IEEE 802.1Q (VLAN Tagging) : url:https://en.wikipedia.org/wiki/IEEE_802.1Q
221 * Le VLAN Tagging, en pratique : url:http://www.firewall.cx/networking-topics/vlan-networks/219-vlan-tagging.html
222 * Documentation Debian (attention, certaines commandes et configurations peuvent être obsolètes) : url:https://wiki.debian.org/NetworkConfiguration#Howto_use_vlan_.28dot1q.2C_802.1q.2C_trunk.29_.28Etch.2C_Lenny.29
223
224 === Serveurs ===
225
226 N’oubliez pas, le {{code}}man{{/code}} est votre ami : url:https://en.wikipedia.org/wiki/Man_page !
227
228 ==== Cheatsheets ====
229
230 * Sur différents outils Linux : url:https://www.nixtutor.com/linux/all-the-best-linux-cheat-sheets/
231 * Sur les commandes Linux usuelles : url:https://files.fosswire.com/2007/08/fwunixref.pdf
232 * Sur Vim : url:https://vim.rtorr.com/
233 * Sur Git
234 ** url:http://www.ndpsoftware.com/git-cheatsheet.html
235 ** url:http://www.cheat-sheets.org/saved-copy/git-cheat-sheet.pdf
236
237 ==== Logical Volume Manager (LVM) ====
238
239 * La doc d’Ubuntu : url:https://wiki.ubuntu.com/Lvm
240 * La doc de RedHat : url:https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/LVM_components.html#multiple_partitions
241 * Quelques notes sur les //Best practices// : url:https://unix.stackexchange.com/questions/76588/what-is-the-best-practice-for-adding-disks-in-lvm
242 * //Benefits of LVM on small systems// : url:http://tldp.org/HOWTO/LVM-HOWTO/benefitsoflvmsmall.html
243
244 ==== Virtualisation ====
245
246 * Wiki XEN Project : url:https://wiki.xenproject.org/wiki/Main_Page
247 * Tutoriel XEN pour Debian : url:https://wiki.debian.org/Xen
248
249 ==== Puppet ====
250
251 Puppet, c’est avant tout //beaucoup// de pages de documentation, sortez une nouvelle fenêtre de votre navigateur préféré, préparez un café et plongez : url:https://docs.puppet.com/puppet/ !
252 * Un article intéressant : url:https://puppet.com/blog/problem-separating-data-from-puppet-code