Avoir des containers, c’est cool et c’est plus sécurisé qu’une installation tout en un, mais quand on a une mise à jour sur un des containers, on doit souvent la faire sur chacun. Et ça, ça peut prendre du temps si on n’a pas beaucoup de bande passante (chez soi par exemple).
Même si mon serveur est en datacenter, je ne vois pas bien l’intérêt de gaspiller des ressources pour faire la même chose une dizaine de fois.
C’est donc là qu’intervient apt-cacher-ng qui cachera les paquets pour l’ensemble des clients : une fois qu’un client a demandé un paquet Debian, celui-ci ne sera pas téléchargé de nouveau pour les autres clients, il sera servi directement par apt-cacher-ng.
Après l’avoir installé grâce à apt-get sur le container que vous voulez ou sur le dom0, ou une autre machine de votre appartement, il suffit d’écrire ceci dans le fichier /etc/apt/apt.conf.d/01proxy des machines qui doivent profiter d’apt-cacher-ng (dont celle où il est installé):
Bon, l’IP ou le nom de la machine, pourvu que la machine qui contient ça puisse s’y retrouver et contacter le serveur en question.
Sécurité
Comme ça, apt-cacher-ng est ouvert à tout vent. Si vous avez installé ça sur un serveur, c’est pas cool. Donc le firewall est de rigueur (port 3142, vous vous en doutez) ou, si vous avez utilisé ça dans un réseau de containers, vous pouvez forcer l’IP d’écoute d’apt-cacher pour que seul le réseau local soit à même de le contacter (l’IPv6 n’a pas que des avantages).
Pour ça, il faut modifier /etc/apt-cacher-ng/acng.conf et mettre un truc comme ça (à adapter à votre cas bien sûr):
BindAddress: 192.168.1.12
À noter qu’il existe aussi apt-cacher qui permet (au niveau sécurité) de définir des hôtes à servir et d’autres à refuser, mais celui-ci a plus de dépendances et apt-cacher-ng est une réécriture de celui-ci pour consommer le moins de ressources possibles. À vous de voir.
Et ouais, j’ai profité de la migration de serveur pour m’intéresser à IPv6, vu que c’est l’avenir et que ça permet quelques trucs bien cool (déjà dégager le NAT). Pis ça permet d’avoir la classe en s’inscrivant sur http://www.worldipv6launch.org/.
Et en fait, c’est pas si compliqué que ça à mettre en place (en tout cas, sur mon serveur qui, il est vrai, ne fait rien de bien compliqué).
Voyons voir comment mettre ça en place sur un serveur avec des containers lxc dedans.
un dom0 avec une interface eth0 qui donne sur internet et une interface bridge, br0 qui émule un réseau local.
des containers, qui possèdent tous une interface eth0. On ne traitera qu’un container, la copie des manipulations étant sans piège.
un champ d’ip publiques IPv6, mettons 2001:B0E:42:42::/64, fourni par mon hébergeur/FAI/la nasa…
la commande ip, fournie par le paquet iproute sous Debian
Choisir les ip
L’ip de la passerelle, chez Ovh (chez qui je loue mon serveur), se déduit de votre champ d’ip. Dans le cas fictif qui nous occupe, ce sera 2001:B0E:42:ff:ff:ff:ff:ff/128 => on prend l’ip de son sous-réseau et on s’arrange pour caler 5 « FF » à la fin. Voir ici pour plus de détails.
L’ip de l’interface eth0 du dom0 : 2001:B0E:42:42::1
L’ip de l’interface br0 du dom0 : 2001:B0E:42:42::2
L’ip de l’interface eth0 du container : 2001:B0E:42:42::3
J’ai pris 3 ip consécutives parce c’est plus simple à retenir mais vous faites comme vous voulez.
Quelques fichiers de conf
Dans le fichier /etc/sysctl.conf du dom0 (merci à Pierre-Philippe d’avoir remarqué cet oubli) :
Dans le fichier de config du lxc (/var/lib/lxc/lxchostname/config) :
lxc.network.ipv6 = 2001:41d0:2:9c::3/64
Mettre en place la passerelle
À cause du bug mentionné au-dessus, j’ai du placer la configuration de la passerelle dans le fichier /etc/rc.local.
C’est à ce moment que la commande ip devient utile. Faites des tests en ligne de commande avant d’écrire dans /etc/rc.local, c’est plus simple.
Quelques commande de bases :
ip -6 r(oute) l(ist)
=> affiche les routes ipv6 existantes
ip -6 r(oute) a(dd) 2001:B0E:42:ff:ff:ff:ff:ff dev eth0
=> ajoute une route ipv6 sur eth0
ip -6 r(oute) d(elete) 2001:B0E:42:ff:ff:ff:ff:ff dev eth0
=> supprime la route ipv6
ip -6 neigh add proxy 2001:B0E:42:42::3 dev eth0
=> indique que eth0 doit transmettre (forwarder) les requêtes adp à l’adresse suivante. On utilisera cette commande pour chacune des ip des containers.
Pour le dom0
ip -6 route add default via 2001:B0E:42:ff:ff:ff:ff:ff dev eth0
ip -6 neigh add proxy 2001:B0E:42:42::2 dev eth0
ip -6 neigh add proxy 2001:B0E:42:42::3 dev eth0
La première ligne est assez normale : par où faut-t’il passer pour aller vers le net.
La deuxième sert à assurer que la recherche de la machine ayant l’ip 2001:B0E:42:42::2 (br0 du dom0) sera bien transmise et que le container pourra bien répondre à cette sollicitation. Pareil pour la troisième ligne (eth0 du container).
On pourra voir avec ip –6 r l que les routes
2001:B0E:42:42::1 dev eth0 proto kernel metric 256
2001:B0E:42:42::/64 dev br0 proto kernel metric 256
ont été créées toutes seules comme des grandes (nécéssite peut-être un redémarrage et pas juste une activation des IPv6 sur les différentes interfaces).
Pour le container
ip -6 route add 2001:B0E:42:42::1 via 2001:B0E:42:42::2 dev eth0
ip -6 route add default via 2001:B0E:42:42::2 dev eth0
Voilà qui peut sembler étrange de spécifier la route de 2001:B0E:42:42::1 (eth0 du dom0) en passant par 2001:B0E:42:42::2 (br0 du dom0). En fait, pas du tout. Comme l’interface eth0 du container fait partie du réseau 2001:B0E:42:42/64, le serveur pense qu’il peut accéder à 2001:B0E:42:42::1 directement, or il lui faut passer par br0.
Ce problème est évitable en mettant les interfaces des containers, ainsi que br0 dans un /65 (ou un réseau encore plus petit) distinct de celui de l’interface eth0 du dom0. Je ne l’ai pas fait au début et ensuite ça m’embêtait de changer toute ma configuration.
Fini
Voilà, normalement, c’est tout bon. Vous pouvez tester votre configuration à grands coups de
ping6 ipv6.google.com
ou n’importe quel autre serveur dont vous savez qu’il répond aux pings IPv6 (fiat-tux.fr ne répondra pas : je bloque le ping des ip que je ne connais pas, désolé) . Pensez à le faire depuis tous les containers, on ne sait jamais.
Vous pouvez tester que le serveur choisit est bien censé répondre aux ping6 sur cette page.
Et si j’ai dit une bêtise ou que vous avez une question, je suis à votre disposition !