Code source wiki de Guide de l’infrastructure

Modifié par Clément AUBIN le 2021/04/03 21:31
Afficher les derniers auteurs
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 === L’état d’esprit ===
36
37 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.
38
39 == Réseau ==
40
41 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 :
42
43 * 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}}.
44 * 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}}.
45
46 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 !
47
48 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.
49
50 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}}.
51
52 === Réseau {{code}}ATILLA-CY106{{/code}} ===
53
54 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.
55
56 **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 [[Services.Members.WebHome]]).
57
58 ==== Conservation des données de connexion ====
59
60 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 :
61
62 * Les fichiers de log du serveur DHCP : ils nous permettent de faire correspondre une adresse MAC à une adresse IP ; voici un exemple de logs :
63
64 {{code}}
65 Jan 30 22:02:30 hydra dhcpd: DHCPREQUEST for 192.168.253.XXX from 00:00:00:00:00:00 via eth1
66 {{/code}}
67
68 {{code}}
69 Jan 30 22:02:30 hydra dhcpd: DHCPACK on 192.168.253.XXX to 00:00:00:00:00:00 via eth1
70 {{/code}}
71
72 * 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}}.
73
74 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}}.
75
76 ==== Gestion des points d’accès au réseau ====
77
78 Pour pouvoir se connecter au réseau {{code}}ATILLA-CY106{{/code}}, il existe deux moyens principaux :
79
80 * Se brancher à une prise murale lié à un des deux switchs de la salle
81 * Passer par le réseau wifi {{code}}ATILLA{{/code}}
82
83 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.
84
85 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.
86
87 **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.
88
89 ==== Gestion de la connexion au réseau ====
90
91 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]].
92
93 Évidemment, le serveur RADIUS loggue toutes les tentatives d’authentification, pour information, voici un exemple de logs pour une connexion :
94
95 {{code}}
96 Sat Jan 28 19:47:42 2017 : Auth: (3636) Login OK: [aubincleme] (from client ap_wifi port 0 via TLS tunnel)
97 {{/code}}
98
99 {{code}}
100 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)
101 {{/code}}
102
103 === Réseau {{code}}ATILLA{{/code}} ===
104
105 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.
106
107 Il est à noter qu’ATILLA dispose à l’heure de la création de ce guide de 5 serveurs physiques :
108
109 * {{code}}bill.atilla.org{{/code}}
110 * {{code}}laika.atilla.org{{/code}}
111 * {{code}}idefix.infra.atilla.org{{/code}}
112 * {{code}}snoopy.infra.atilla.org{{/code}}
113 * {{code}}touffu.infra.atilla.org{{/code}}
114
115 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}}.
116
117 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}}.
118
119 ==== Découpage du réseau ====
120
121 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.
122
123 Voici le découpage IP actuellement en place :
124
125 * {{code}}192.168.10.0/27 - *.infra.atilla.org{{/code}} : Réseau dédié aux serveurs et équipements physiques (comme les EisTV) ;
126 * {{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 ;
127 * {{code}}192.168.10.64/26 - *.prod.infra.atilla.org{{/code}} : Réseau dédié aux services utilisés en production ;
128 * {{code}}192.168.10.128/26 - *.test.infra.atilla.org{{/code}} : Réseau dédié aux services utilisés en test ;
129 * {{code}}192.168.10.192/27 - *.preprod.infra.atilla.org{{/code}} : Réseau dédié aux services utilisés en pré-production ;
130 * {{code}}192.168.10.224/27 - *.dev.infra.atilla.org{{/code}} : Réseau dédié aux services utilisés en développement.
131
132
133 ==== Serveur DHCP ====
134
135 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.
136
137 ==== Serveur DNS ====
138
139 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]].
140
141 On distingue deux configurations DNS distinctes :
142
143 * Une configuration {{code}}external{{/code}} pour toutes les adresses externes à l’EISTI ;
144 * Une configuration {{code}}internal{{/code}} pour toutes les requêtes provenant de l’intérieur de l’EISTI.
145
146
147 ===== Configuration {{code}}external{{/code}} =====
148
149 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}}
150
151 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}}.
152
153 ===== Configuration {{code}}internal{{/code}} =====
154
155 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 :
156
157 * 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 ;
158 * 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 ;
159 * Les 6 autres fichiers restants sont les suivants :
160 ** {{code}}db.infra.atilla.org{{/code}}
161 ** {{code}}db.vps.infra.atilla.org{{/code}}
162 ** {{code}}db.prod.infra.atilla.org{{/code}}
163 ** {{code}}db.test.infra.atilla.org{{/code}}
164 ** {{code}}db.preprod.infra.atilla.org{{/code}}
165 ** {{code}}db.test.infra.atilla.org{{/code}}
166
167 : 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.
168
169
170 ==== Politique de nommage des machines virtuelles ====
171
172 Nous avons tendance à en rire, mais au premier coup d’œil, la manière dont nous nommons nos machines virtuelles peut paraître invraisemblable.
173
174 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}}
175
176 … 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 ?
177
178 À cette question, nous avons deux réponses :
179
180 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 ;
181 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.
182
183
184 == Liens utiles ==
185
186 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.
187
188 === Réseau ===
189
190 ==== (Network) Bridges ====
191
192 * Qu’est-ce que c’est ? url:https://en.wikipedia.org/wiki/Bridging_(networking)
193 * Documentation Debian : url:https://wiki.debian.org/BridgeNetworkConnections
194 * Tutoriel simple pour mettre en place un bridge : url:https://www.cyberciti.biz/faq/debian-network-interfaces-bridge-eth0-eth1-eth2/
195
196 ==== Domain Name System (DNS) ====
197
198 * Qu’est-ce que c’est ? url:https://en.wikipedia.org/wiki/Domain_Name_System
199 * Monter un DNS avec Bind9 : url:https://www.it-connect.fr/dns-avec-bind-9%ef%bb%bf/
200
201 ==== Dynamic Host Configuration Protocol (DHCP) ====
202
203 * Qu’est-ce que c’est ? url:https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
204 * «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
205
206 ==== Preboot Execution Environment (PXE) ====
207
208 * Qu’est-ce que c’est ? url:https://en.wikipedia.org/wiki/Preboot_Execution_Environment
209 * Le site d’IPXE : url:http://ipxe.org/
210 * La //specification// d’Intel : url:http://www.pix.net/software/pxeboot/archive/pxespec.pdf
211
212 ==== Théorie ====
213
214 Parfois, ça ne fait pas de mal de revenir aux fondamentaux ~^~^.
215
216 * Le modèle OSI : url:https://en.wikipedia.org/wiki/OSI_model
217 * //The TCP/IP Guide// : url:http://tcpipguide.com/free/index.htm
218 * Le NAT (Network Address Translation) : url:https://en.wikipedia.org/wiki/Network_address_translation
219
220 ==== Virtual LANs (VLANs) ====
221
222 * Qu’est-ce que c’est ? url:https://en.wikipedia.org/wiki/Virtual_LAN
223 * Norme IEEE 802.1Q (VLAN Tagging) : url:https://en.wikipedia.org/wiki/IEEE_802.1Q
224 * Le VLAN Tagging, en pratique : url:http://www.firewall.cx/networking-topics/vlan-networks/219-vlan-tagging.html
225 * 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
226
227 === Serveurs ===
228
229 N’oubliez pas, le {{code}}man{{/code}} est votre ami : url:https://en.wikipedia.org/wiki/Man_page !
230
231 ==== Cheatsheets ====
232
233 * Sur différents outils Linux : url:https://www.nixtutor.com/linux/all-the-best-linux-cheat-sheets/
234 * Sur les commandes Linux usuelles : url:https://files.fosswire.com/2007/08/fwunixref.pdf
235 * Sur Vim : url:https://vim.rtorr.com/
236 * Sur Git
237 ** url:http://www.ndpsoftware.com/git-cheatsheet.html
238 ** url:http://www.cheat-sheets.org/saved-copy/git-cheat-sheet.pdf
239
240 ==== Logical Volume Manager (LVM) ====
241
242 * La doc d’Ubuntu : url:https://wiki.ubuntu.com/Lvm
243 * 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
244 * Quelques notes sur les //Best practices// : url:https://unix.stackexchange.com/questions/76588/what-is-the-best-practice-for-adding-disks-in-lvm
245 * //Benefits of LVM on small systems// : url:http://tldp.org/HOWTO/LVM-HOWTO/benefitsoflvmsmall.html
246
247 ==== Virtualisation ====
248
249 * Wiki XEN Project : url:https://wiki.xenproject.org/wiki/Main_Page
250 * Tutoriel XEN pour Debian : url:https://wiki.debian.org/Xen
251
252 ==== Puppet ====
253
254 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/ !
255
256 * Un article intéressant : url:https://puppet.com/blog/problem-separating-data-from-puppet-code