Du réseau à l’Ubuntu Party

Ce billet décrit par les différentes étapes qui ont amenés à la

mise en place d’une machine à la cité des sciences et de

l’industrie pour faciliter les install parties régulières ayant

lieu dans leurs locaux. Si vous êtes juste intéressés par les

différents fichiers de configuration, vous pouvez vous rendre

immédiatement à la fin de l’article.

Un des intérêt de la cité des sciences et de l’industrie est que

celle-ci dispose d’un réseau existant et d’un lien de qualité vers

le reste d’Internet. Néanmoins, il ne s’agit que d’un lien de

quelques gigabits qui peut rapidement être saturé, en particulier en

cas d’utilisation intensive, ou si nous sommes basculés sur le lien

de secours. Cette situation est fort peu agréable en particulier

quand nous avons besoin d’accéder régulièrement au réseau

Internet.

Depuis déjà quelques éditions, nous sommes conscient de la

nécessité de disposer d’un réseau maîtrisé. Celle-ci passe par la

gestion de certains éléments, comme l’attribution des adresses IP,

le choix du serveur DNS et ce qui en découle l’utilisation de

miroirs locaux, servis de façon non-intrusive pour l’utilisateur

final.

Gardons en tête ce principe de ne pas impacter la façon

d’installer. Autrement dit, nous n’irons ni modifier les sources de

logiciel, ni modifier l’adresse des serveurs de noms utilisés par la

machine. Ces contraintes imposent donc successivement que les

entrées DNS correspondant aux archives Ubuntu doit pointer vers une

machine locale. Il est donc nécessaire de maîtriser le serveur de

nom. Pour que cela puisse se faire de façon transparente, il existe

une condition supplémentaire : assigner nous même des baux

d’adresses IP et en profiter pour annoncer nous même route et DNS

par défaut. Ceci peut se faire en disposant de notre propre serveur

DHCP. Ceci suppose également de ne pas rentrer en conflit avec

d’autres serveurs, en particulier ceux de la cité des sciences et de

l’industrie. Pour cela, nous disposons de notre propre plage d’IP

sur un vlan dédié.

Rentrons un peu plus dans les détails :

- les adresses IP sont attribuées via isc-dhcp-server ; le dns

</p>
annoncé est un dns interne à notre vlan ; la passerelle annoncée

<p>
permet de « sortir » sur internet ;
  • les noms de domaines sont résolus en adresses IP par bind,

    « mentant » sur la résolution de certains noms,

    comme fr.archive.ubuntu.com ;

  • les archives (et d’autres choses) sont servies par apache.

Lors de la mise en place de cette solution et lors des événements

précédents, nous avons rajouté un certain nombre de service. En

particulier, nous proposons un miroir de téléchargement pour les

images des cédéroms, un service de boot « PXE » ainsi qu’un cache

sur les sites web fortement consultés,

comme doc.ubuntu-fr.org

En guise de note finale, vous trouverez le fichier Makefile de

synchronisation des miroirs, ainsi que les différents fichiers

permettant de dupliquer cette installation pour votre install

party.

Si vous disposez de plusieurs interfaces réseaux, vous pouvez

également utiliser le script de NAT suivant qui nous sert à Parinux

sur notre machine portable, Idia, nommé d’après la précédente (Oups.)

Pour l’instant seuls les fichiers permettant de publier le miroir complet sur le réseau sont présent dans l’archive. Les fichiers feront certainement l’objet d’un billet spécifique.

Tagcloud
Ubuntu automontage kernel authentification orgcamp NetworkManager Internet identification PSL Science-Fiction JDLL postfix Opinions Gentoo Éducation Iptables OSM rubber sympa GNU-Linux Educ Libre PlanetUbuntuFr PlanetUbuntu nfs UbuntuFr Mathématiques auto hébergement Python compilation dovecot Mozilla Mandriva Emacs Perso eCryptfs April Drupal beamer automatisation shell DNS Voile Mutt orgmode Société LDAP Réflexions SNCF configuration Épinay redmine sqlite php CAPES Spam OpenVPN CPL dotclear ISN vélo mail installation OpenSSL GCC X.org sudo ArchLinux fail vserver IPv6 Debian Coups de gueule LaTeX Admin Sys Free Parinux RaspberryPi Vie numérique Essai sieve gpg vim fun Randonnée SPF OpenStack Informatique Coup de gueule Lectures Paris Web imap RATP Technique CLI code KDE roundcube Munin