Bonjour nal,
L'autre jour j'ai voulu ajouter un service de « cache » APT sur le réseau, et j'ai essayé de faire ça bien. J'ai une machine (sous Debian Stretch) déjà utilisée pour plusieurs choses, dont un serveur Web, et elle accueillerait bien ce service en plus, avec son honnête capacité de stockage disponible.
Je vais donc vous expliquer ma démarche, qui demande quand même quelques prérequis :
- Avoir un réseau IPv6 fonctionnel
- Maîtriser le serveur DNS de la zone où on veut mettre ce service
- Utiliser Debian, comme déjà évoqué
Et quand même, je souhaite globalement « faire simple » (vous allez voir, c'est subjectif).
Alors la première chose, c'était le choix du logiciel de « cache » : j'avais déjà essayé apt-cacher-ng et je n'en étais pas mécontent, mais j'ai quand même quelques réticences car j'ai déjà eu des problèmes de cache corrompu pour une raison inconnue (plusieurs fois), et il est même administrable en Web ce qui peut sembler bien, mais moi je trouve que ça fait une interface en trop à surveiller. J'ai alors regardé les alternatives, et approx 1 m'a bien tenté : utilise inetd, programmé en OCaml, configuration en une ligne. Bon, il ne fonctionne pas comme proxy HTTP comme apt-cacher-ng, mais doit être désigné dans le sources.list ; pourquoi pas, fonctionnement différent mais qui est dû je pense à la simplicité de faire ainsi (la complexité de apt-cacher-ng ne doit pas être étrangère au fait qu'il est capable « d'unifier » des paquets issus de mirroirs différents).
Allez hop (j'ajoute l'inetd à la mano, il n'est même pas en recommandation ; un bug à rapporter ?) :
apt-get install approx openbsd-inetd
Bon, une fois le logiciel choisi, vient le soit-disant problème qui m'a ammené à écrire ce journal en particulier : ce service est fourni en HTTP, et j'ai déjà un serveur sur ce port sur la machine. Que fais-je ? Je change de port et apprend à configurer chaque client pour ? Ou plutôt un reverse-proxy par mon serveur web ? Ou un autre en frontal ? Comment je gère le VirtualHost ? Etc.
STOP ! Je disais en introduction qu'on est en IPv6, et il faut arrêter de penser comme en IPv4 ! Sur Internet (sous-entendu IPv6) les services d'un même type (même port) sont différenciés par IP (v6, vous aurez compris). On ne devrait pas à avoir à tripatouiller du port, faire du mapping, etc (coucou Docker _o/), c'est un paliatif qui a été iventé dans un monde de rareté de l'IP. De plus, cela demande de la configuration d'équipement intermédiaire et client, alors que le but d'IP est de faire des logiciels qui communiquent de bout-en-bout et n'ont jamais besoin de configuration spécifique de la part du réseau (même « virtuel » au sein de votre VM/conteneur/whatever). Bien sûr, ça va à l'encontre de beaucoup de technologies modernes, qui sont bien souvent mal adaptées à IPv6 car pas pensé pour lui dès le départ (re-coucou Docker \o_).
Un autre aspect à prendre en compte : votre service va probablement être référencé dans le DNS (sinon comment souhaiteriez-vous le joindre depuis le réseau ?), et au lieu d'avoir dix-mille couche entre ce nom et votre IP, restez simple et pensez à faire la liaison directement. De plus, vous pourrez référencer la machine par nom dans toutes vos configurations, ce que permettent les API réseau POSIX depuis la nuit des temps. Le DNS est malheureusement un élément souvent oublié aujourd'hui, comme l'a par exemple rappelé Bortzmeyer il y a quelques jours encore lors d'une très bonne conférence, et il est d'autant plus nécessaire dans une configuration IPv6 (et même pour la transition).
Bon, et donc comment on fait ? Et bien on commence par choisir une IP pour ce service : ça sera 2001:db8:0:42::497, dans le sous-réseau de mes serveurs 2001:db8:0:42::/64. Pas besoin de port-mapping sur le NAT, de changer le firewall, etc : des règles simples sont déjà prévues pour laisser presque tout passer sur ce réseau puisqu'il est fait pour ça (les autres réseaux à usage différents sont sur des /64 différents). On met ça dans le classique /etc/network/interfaces, en utilisant un « alias » d'eth0, qui a déjà lui sa « propre adresse » si on peut dire :
auto eth0:apt
iface eth0:apt inet6 static
address 2001:db8:0:42::497
On l'active :
ifup eth0:apt
On vérifie que ça roule :
$ ip -6 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:db8:0:42::497/128 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 2001:db8:0:42::9/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::201:23ff:fe45:6789/64 scope link
valid_lft forever preferred_lft forever
Explications : la machine a déjà une IP précédemment définie 2001:db8:0:42::9, statique, pour laquelle je n'ai pas précisé de longueur de préfixe puisque c'est une propriété qui dépend du réseau. On arrive donc avec des prefixlen de 128 pour chacune (c'est à dire juste cette IP-là), plus l'adresse de liaison locale (link-local) « classique ». Seul petit truc étrange : la nouvelle adresse est « deprecated », qui est une propriété issue de la RFC sur l'autoconfiguration (RFC 4862) qui a une influence sur la sélection d'adresse par défaut (RFC 6274) mais n'est pas dérangeante ici si on dit qu'on veut explicitement cette adresse.
Pour vérifier l'histoire des longueurs de préfixe dont je vous parle :
$ ip -6 route
2001:db8:0:42::9 dev eth0 proto kernel metric 256 pref medium
2001:db8:0:42::497 dev eth0 proto kernel metric 256 pref medium
2001:db8:0:42::/64 dev eth0 proto kernel metric 256 expires 6703sec pref medium
2001:db8:0::/48 via fe80::298:76ff:fe54:3210 dev eth0 proto ra metric 1024 expires 6703sec pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
On a bien ici une route d'interface en /64 sur eth0 pour le préfixe, bien reçue d'un Router Advertisement (le compteur d'expiration est présent). Vous voyez un /48 via mon routeur pour mon « site » qui est annoncé par mon routeur afin de ne pas perdre la connectivité aux autres réseaux du site quand la connexion à Internet « tombe », à défaut de route par défaut, comme c'est le cas ici (mon routeur respecte bien l'obligation G-4 de la RFC 7084 et ne s'annonce pas comme routeur par défaut dans ce cas ; en l'occurence, c'est un bug de mon FAI signalé il y a deux ans qui me fait perdre Internet, coucou les adminsys de FDN \o/).
Bref, on peut pinger (en utilisant ping6) ça marche, cool. Maintenant passons au nom : il faut enregistrer cette IP dans le DNS. J'ai simplement utilisé le nom « apt » dans ma zone, et en syntaxe bind ça donne :
apt IN AAAA 2001:db8:0:42::497
Et pour le reverse (important, peut aider le debug) :
; l'ORIGIN vous devriez déjà l'avoir
$ORIGIN 2.4.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.apra.
7.9.4.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR apt.example.com.
Après le rechargement des zones, on ping le nom, pareil, ça marche toujours.
Passons maintenant à la configuration d'approx ! Alors c'est un logiciel spartiate, et seul un exemple de configuration est fourni dans /usr/share/doc/approx/examples/approx.xinetd, qu'il faut adapter à inetd (Edit : je me rends compte qu'il a une config systemd par défaut, mais mon serveur n'ayant pas ce logiciel, elle est ignorée). Ça donne :
apt.example.com:http stream tcp nowait approx /usr/sbin/approx
Vous tiquez peut-être sur la première colonne, de syntaxe inhabituelle pour ceux qui connaissent inetd : on ne met souvent que le port, ici on ajoute le nom d'hôte sur lequel écouter en plus (syntaxe classique "hôte:port"), car c'est bien sur une IP particulière qu'on veut présenter ce service ; et oui, un nom sur lequel se binder ! Et c'est très pratique : pas d'interface ou quoi que ce soit à se soucier, en précisant un nom (ou une IP, même), on sépare bien la question du routage de la localisation de service (choses souvent mélangées dans certaines technologies modernes). De plus, le fait d'utiliser le nom fait qu'on se rend tout de suite compte d'un décalage entre l'IP définie localement et le nom défini centralement dans le DNS qui sert en général d'autorité sur la localisation d'un service (c'est-à-dire que ça mettra une erreur au démarrage, indiquant que le démon ne peut pas se binder à l'IP indiquée).
On relance inetd :
service openbsd-inetd reload
Mais là, paf, pas de service :
# ss -lp sport = http
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 2001:db8:0:42::9:http :::* users:(("nginx",pid=27548,fd=8),("nginx",pid=27547,fd=8),("nginx",pid=27540,fd=8))
Il y a mon serveur Web, mais pas approx2. Regardons les logs :
# tail /var/log/syslog
[…]
Feb 3 22:05:47 machine inetd[7319]: http/tcp: apt.example.com: No address associated with hostname
Réfléchissons deux secondes : pas d'adresse avec ce nom, qui a pourtant bien marché tout à l'heure lors du ping ? Ah, mais bien sûr, il n'y a pas de nom en IPv4 ;-) (OK, un peu d'expérience avec le dual-stack sur différents logiciels aide un peu). Le man d'inetd indique qu'il faut préciser "tcp6" dans ce cas, et ajoute malicieusement :
"tcp" and "udp" will be recognized as "TCP or UDP over default IP version". This is currently IPv4, but in the future it will be IPv6.
Je pense qu'il a été écrit il y a quelques temps déjà (« IPv6 support was added by the KAME project in 1999. » !), et l'auteur ne devait pas penser que le futur serait si long à atteindre ! Et donc on adapte la configuration, on recharge inetd, et hop :
# ss -lp sport = http src apt.example.com
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 2001:db8:0:42::497:http :::* users:(("inetd",pid=7319,fd=8))
Ça roule. Pour finir de configurer approx, il faut lui indiquer quel sous-répertoire fait pointer vers quel mirroir. On prend les exemples fournis dans le fichier de configuration /etc/approx/approx.conf et on met par exemple :
debian http://ftp.nerim.net/debian
security http://security.debian.org/debian-security
Ce qui donnera côté client, pour qui voudra ajouter ce dépôt dans une configuration genre /etc/apt/sources.list.d/apt.example.com.list (ici pour une Stretch) :
deb http://apt.example.com/debian/ stretch main contrib
deb-src http://apt.example.com/debian/ stretch main contrib
deb http://apt.example.com/security/ stretch/updates main
deb-src http://apt.example.com/security/ stretch/updates main
Un petit coup de "apt-get update" et roule ma poule, ça fonctionne !
Bon, c'est plutôt bien, mais j'aimerais peut-être mettre un peu de contrôle d'accès dessus, car une des propriétés géniales d'IPv6, c'est que quand on est « sur le réseau », bah on est accesible de tout le réseau. Et je suis bien gentil mais je n'ai pour l'instant pas envie de faire cache pour la Terre entière. Alors je vais utiliser les bon vieux tcp-wrappers, normalement intégrés à inetd (selon le man) mais qu'en fait je n'ai réussi à faire fonctionner qu'après l'avoir invoqué explicitement (Edit : en fait c'est l'option -l à ajouter au lancement du démon…). Pour cela, il faut seulement ajouter "tcpd" avant notre commande dans inetd.conf, ce qui donne pour la ligne complète :
apt.example.com:http stream tcp6 nowait approx /usr/sbin/tcpd /usr/sbin/approx
On remplit ensuite les autorisations, dans le format "démon@hôte: client" (un peu plus spécifique que le standard "démon: client"), pour ce qui est autorisé dans /etc/hosts.allow :
approx@apt.example.com: [2001:db8::]/48
Et pour ce qui ne l'est pas dans /etc/hosts.deny :
approx@apt.example.com: *
Après un petit tour dans /var/log/daemon.log, on voit bien des connexion (réussies) loggées :
Feb 4 22:14:20 apu approx[14145]: connect from 2001:db8::0:7123:45ff:fe98:7654 (2001:db8::0:7123:45ff:fe98:7654)
Un test depuis une autre adresse renverra bien un « reset » (après une résolution inverse, ce qui retarde la réponse de quelques secondes si le client n'est pas dans la zone ip6.arpa, ce qui est souvent le cas des adresse SLAAC — c'est le cas ci-dessus).
Voilà donc, un bon petit service configuré de manière standard et « à l'ancienne » (IP, DNS, ports standard, outils Unix standards), qui tourne simplement sans trucs trop complexes. Forcément, étant IPv6 seulement, ça va en embêter certains, mais avec la complexification et la baisse de fiabilité des mises en place IPv4 qui arrive, j'espère que cette alternative sera de plus en plus considérée comme sérieuse et efficace. J'espère aussi que vous avez appris quelques trucs sur la manipulation des outils autour d'IPv6 (ip et ss de la suite iproute2, bind et IPv6) et de comment débugger des problèmes avec ce protocole, ainsi que quelques techniques spécifiques à lui.
Comme amélioration, on pourrait imaginer rendre le service plus résilient en ajoutant une autre instance d'approx sur un autre serveur : ça se fera facilement en ajoutant une deuxième IP derrière le nom qu'on a défini, c'est tout ! (c'est également car ce service de cache n'a pas d'état partagé nécessaire entre instance) On pourrait même utiliser les enregistrement SRV que apt gère (_http._tcp.apt.example.com dans notre cas) pour y ajouter une meilleure répartition et des serveurs de repli. Tout ça nous apporte de la disponibilité sans ajouter un quelconque intermédiaire (load-balancer ou autre), le travail étant fourni par les extrémités, et en tirant parti de cette merveilleuse base de données clé-valeur distribuée qu'est le DNS !
Bref, pensez Internet, pensez futur, pensez IPv6, et lancez plein de services « à l'ancienne » !
-
La homepage est normalement le git, mais tous les liens sont cassés depuis le malheureux passage à Gitlab, logiciel même pas présent dans l'archive ; une honte. ↩
-
On aurait pu filtrer sur l'IP en particulier en ajoutant "src apt.example.com" comme argument à ss, mais la syntaxe est assez infâme je trouve ; est-ce que ça a un rapport avec le fait que l'auteur russe travaille dans le nucléaire et a fait un soft au nom de nazi ?… ↩
# Merci !
Posté par barmic . Évalué à 9.
Merci pour ton explication claire et très didactique ! J'ai enfin compris pourquoi on reste en IPv4.
[^] # Re: Merci !
Posté par dani . Évalué à 1.
C'est clair ! C'est une bonne façon d'illustrer pourquoi on abandonnera pas IPv4 de si tôt. Et pourquoi IPv6 en est toujours là après plus de 20ans de déploiement…
[^] # Re: Merci !
Posté par mahikeulbody . Évalué à 7.
Je n'ai pas tout compris au journal (ceci explique peut-être cela) mais je n'ai pas vu en quoi la complexité apparente de ce qu'il décrit provient spécifiquement de IPv6.
[^] # Re: Merci !
Posté par barmic . Évalué à 4.
Il s'agit évidement d'un troll de ma part, mais néanmoins entre tout ce qui est décrit et ajouter un sous domaine à ton reverse proxy, il y a un monde. Le second est bien plus simple… et régulièrement plus souhaitable. Ton reverse proxy peut faire un tas de choses réellement intéressantes (WAF, TLS offloading, logging, load balancing,…). Tout ça pour un coup de latence généralement négligeable. Beaucoup de gros services internet utilisent ce genre de solutions, c'est que ça doit pas trop être coûteux.
Grosso modo il s'agit de gérer le routage au niveau Application (c'est l'url - soit le chemin soit le sous domaine - qui discrimine), au niveau Transport (c'est le port qui discrimine) ou au niveau Réseau (c'est l'IP qui discrimine). Plus tu fais ça tôt plus tu gagne en performance (après est-ce que c'est sensible je ne suis pas sûr), mais tu dois faire des manipulations « système » (avoir ton DNS, ajouter une interface à ta machine, t'assurer que ton routage fonctionne bien,…). Tester et reproduire tout ça n'est pas trivial.
Est-ce que le jeu en vaut la chandelle ? C'est à chacun de se faire une idée, mais contrairement à ce qui est dit dans le journal choisir de faire un peu plus tardivement le routage ne me paraît pas forcément choquant.
[^] # Re: Merci !
Posté par Pinaraf . Évalué à 5.
Et tu fais quoi pour un service qui ne soit pas en HTTP/HTTPS ? Je sais que c'est plus à la mode, mais y'a quand même des protocoles plus adaptés pour certaines taches que HTTP :)
[^] # Re: Merci !
Posté par barmic . Évalué à 2.
J'utilise un reverse proxy tcp par exemple ? (c'est précisément ce que je suis entrain de faire avec haproxy, mais nginx le fait aussi)
Pour udp je ne me suis jamais posé la question c'est un protocole que je n'ai pas eu l'occasion de manipuler.
[^] # Re: Merci !
Posté par Pinaraf . Évalué à 6.
Hum, je ne vois pas comment tu fais.
Prenons un cas simple : SSH.
Imaginons que tu doives avoir obligatoirement du SFTP sur le port 22 pour un logiciel ne supportant pas autre chose (j'ai déjà vu ça avec des banques), mais que le port 22 est déjà utilisé pour ton SSH normal et que tu ne peux pas le bouger. Comment tu veux faire la distinction sans avoir deux adresses IP ? Au niveau réseau, le nom d'hôte disparait, tu reçois des paquets TCP à destination de 1.2.3.4:22. Éventuellement, ils peuvent contenir une info sur la cible, comme le SNI de HTTPS… Mais donc il faut que ton reverse proxy gère spécifiquement chaque protocole ?
Ça me parait juste infaisable sans avoir des adresses IP en stock… et donc sans IPv6 pour la plupart des gens qui veulent faire de l'auto-hébergement, ou sur le long-terme.
[^] # Re: Merci !
Posté par barmic . Évalué à 3.
C'est pourtant ce que fais sslh ok c'est pas magnifique comme façon de faire, mais ça fonctionne très bien en 2 coups de cuillère à pot.
[^] # Re: Merci !
Posté par Prosper . Évalué à 2.
haproxy peut aussi faire du port multiplexing :
https://blog.visideas.com/2018/02/high-intensity-port-multiplexing-using.html
[^] # Re: Merci !
Posté par Pinaraf . Évalué à 5.
Ben justement, ce n'est pas ce que fait sslh, merci bien. J'ai déjà fait ce genre de chose avec de l'openvpn et du https, ça se distingue très bien sans regarder le contenu des paquets. Mais distinguer ssh toto@tutu1 et ssh toto@tutu2 quand tutu1 et tutu2 pointent sur la même IP, c'est pas la même histoire. Ou alors on a trouvé une énorme faille de sécurité dans SSH et personne ne m'a rien dit ?
[^] # Re: Merci !
Posté par benoar . Évalué à 8.
Quelle différence avec un firewall standard, quand tu utilise mon architecture ?
Je ne suis pas sûr de ce que tu proposes, mais la manière historique de faire c'est IPsec ; sinon, dans mon exemple tu pourrais rajouter du TLS avec un wrapper adapté (OK, c'est hypothétique).
Mmmhhh, je le fais aussi. Si ton service est Unix standard, il utilise syslog. Forcément, si tu parles de l'avantage du logging pour palier son manque dû à des applis Web codées par des dev modernes…
Le load-balancing est une invention inutile dans l'archi que je présente. Ou plutôt, il est « naturel » dans mon cas.
Note que dans ton cas, tu as externalisé toutes ces difficultés en prenant comme hypothèse que tu avais déjà une machine qui a un enregistrement DNS et un routage qui fonctionne. Ces choses ne sont pas arrivées magiquement, et un administrateur a bien dû les configurer.
Le principe du « bout-en-bout », c'est de ne pas rajouter une couche au-dessus de tout ça (HTTP et reverse-proxy) pour faire quelque-chose qui était à la base prévu dans l'architecture d'Internet : le réseau a été conçu pour être un « réseau de processus », pas forcément de « machines » sur lesquelles on va rajouter une couche. Donc on pousse le nommage et le routage jusqu'aux extrémités.
Bien sûr, tout n'est pas rose : la situation actuelle du « blocage » du nommage et du routage — qui amène à empêcher tout déploiement « correct » de service sur Internet — est due à un problème de répartition des responsabilités. On sait difficilement en entreprise ou à la maison déléguer une partie du DNS ou du routage à d'autres : il y a les « responsables du DNS » et les « responsables du routage » qui les gèrent de manière fermée, et qui sont parfois si obtus qu'on préfère passer par d'autres moyens pour étendre le réseau de processus que d'utiliser la manière « standard ».
Je n'ai pas dit choquant, je crois, jusque que c'est plus complexe et fragile. Si tu y trouves des avantages, tant mieux, mais j'ai souvent vu ses promoteurs sous-estimer ses désavantages.
[^] # Re: Merci !
Posté par barmic . Évalué à 1.
Euh ? Un WAF analyse le contenu du trafic HTTP, hein ? Donc tu fais une analyse couche applicative par conception. Si tu veux la faire via ton firewall c'est possible, mais c'est bizarre (ça veut dire que ton firewall (ou ce qui se plug à ton fw) va décoder la requête http, puis que tu va dans la suite continuer de vouloir être agnostique à la couche 7. Ça n'est pas particulièrement beau.
Terminaison TLS si tu préfère.
Non, la première RFC d'IPsec date de 1998 alors que SSL1.0 date de 1994, mais bon comment tu adresse un serveur IPsec+SMTP ?
Oui tu utilise un reverse proxy donc.
Je n'ai pas était très précis. Mais tu peux vouloir avoir des log qui inclus l'information métier et donc doit décoder la 7ème couche. Tu peux imaginer vouloir réagir à ces informations comme ne pas router le trafic s'il y a trop d'erreurs avant.
Prendre comme hypothèse que ça a était fais une fois est un peu plus simple que de considérer que ce sera fais pour chaque nouveaux services.
Je sais et je le comprends bien. Ça n'empêche pas de pouvoir le critiquer. Mais l'argument disant que les gens l'ont pensé comme ça il y a 30 ans donc on doit continuer à le faire n'est pas très convainquant.
Et des idéalistes voir des désavantages au microscopes. En fait quand je vois la facilité de mise en place et comme de très grosses infrastructures s'en servent, je me dis que pour mes besoins ça doit le faire sans trop se poser de question.
Je vois 3 points qui peuvent pose des problèmes sous fortes charges avec les reverses proxy :
[^] # Re: Merci !
Posté par benoar . Évalué à 2. Dernière modification le 06 février 2019 à 17:01.
OK, donc tu veux inclure un service intermédiaire, et ça n'est pas dans la philosophie d'IP : du coup oui, mets ton firewall applicatif. IP ne l'interdit pas, au contraire, mais ne peut pas remplacer effectivement une standardisation d'applicatif type request-response.
Je disais « historique » pour dire classiquement associée avec IP. Et si je chipotte, IPsec c'est 1995 https://tools.ietf.org/html/rfc1825.
Il n'y a effectivement pas de modèle de CA global associé à IPsec, donc « tu ne peux pas » pour le cas généraliste qu'on voit avec TLS.
Non, pas « proxy », juste parler TLS directement. Je précise car souvent le reverse-proxy implique d'avoir à différencier sur le hostname, avec SNI et consort, alors qu'ici on peut éviter ça.
Comme pour le premier cas, on ne va effectivement pas demander à IP de faire de l'applicatif. Ce que propose IP, par contre, c'est que le routage soit fait à la « bonne » couche.
Par contre je n'ai pas compris ton exemple de ne pas router « s'il y a trop d'erreurs avant ».
Pas d'accord : pour ton reverse, il va falloir que tu fasses l'adressage (et éventuellement le nommage) de toutes façons, mais tu le feras avec des couches d'IPv4 voire du NAT, et autre. Et dès qu'il faudra « bouger » tes backend, ça va être la merde parce que ton archi d'adressage est complètement sclérosée ; tu vas aller vers des solutions à la con genre VXLAN et consort (quoique ça doit être has-been aujourd'hui). Tout mettre au niveau d'IP avec de l'adressage globale découple complètement le routage de ton applicatif, et c'est ça qui simplifie énormément la vie. On ne voit pas les désavantages d'IPv4 parce que ses restrictions ont tellement été internalisées par tous que personne ne penserait à bouger un service : tu es « on-premise », ou dans le « Cloud », par exemple, mais jamais tu ne mélanges tout ça ; hérésie ! Alors que ça serait tellement évident en IPv6…
Et je ne parle même pas du setup de ton reverse-proxy : vu que c'est un SPOF, et qu'il doit être dimensionné « costaud », tu complexifies beaucoup plus que « juste un routeur ». Certes, trouver quelqu'un qui saura configurer correctement un routeur en IPv6 aujourd'hui est malheureusement pas si facile, mais j'espère que ça changera.
Oui, j'ai peut-être du mal à « faire rêver » avec mes trucs.
Je suis désolé mais de ce que j'ai vu (OK, subjectif), ça n'est vraiment pas si simple. Oui, les solutions sont mieux intégrées que le genre d'archi que je propose, mais ce ne sont « que » des problématique d'intégration qui pourraient être corrigées relativement facilement si on se bougeait un peu le cul. Derrière, quand il s'agit de gérer la scalabilité du bouzin, c'est une autre histoire.
Les gros y mettent de gros moyens, et forcément ça marche. Mais le genre de truc que je propose marche même à très petite échelle, avec des moyens matériels très réduits. Ça n'est pas forcément vendeur car ça ne pousse pas à la consommation, mais c'est la manière que je préfère.
Niveau perfs, je ne doute pas que vu comment c'est tuné aujourd'hui (d'autant plus si tu parles du très bon haproxy), ça ne doit pas avoir un impact énorme.
Là c'est clairement un des avantages d'IPv6 : tu n'as pas de limite de scalabilité. Donc ton infra marche bien tant que tu es en-dessous de la limite (et ça suffit à plein de monde, certes), mais tu sais que quand tu l'atteins t'es dans la merde.
Effectivement.
Mais ça ne sont pas les désavantages les plus flagrants que je voyais : je pense plutôt à la complexité de la machine (applicatif spécialisé complet versus kernel + userspace « basique »), les différentes possibilités de configuration (= très simple en IP), le SPOF que ça constitue, ou si tu utilises des front redondés la complexité du partage d'état fait (problématique non présente en IP), etc.
[^] # Re: Merci !
Posté par barmic . Évalué à 2.
On peut très bien déclarer plusieurs reverse proxy dans ton enregistrement dns. Par contre si je ne me trompe pas c'est bien plus compliqué avec IPv6. Là où les ip sont présenté en round robin avec IPv4, avec IPv6 l'ordre est défini et fixé. Donc les clients doivent consciemment implémenter le balancing.
Hum ? Je ne vois pas de quoi tu parle ?
[^] # Re: Merci !
Posté par benoar . Évalué à 1.
Oui, mais comme je disais après il faut réussir à les synchroniser pour tout ce qui est état partagé (pour l'authentification sûrement, voire plus).
Hmm, je ne vois pas d'où tu sors ça : le principe d'IP (v4 ou v6) « à l'ancienne » c'est de faire de la répartition sur un ensemble d'IP retournées en résolvant un nom. Sauf que comme il n'existe pas de standard sur comment faire ce round-robin, il a été standardisé les enregistrements SRV, sur le modèle des MX, qui précise l'algo à implémenter. D'autres ont préféré gérer ça côté serveur, et comme d'hab c'est moche : on pète le mécanisme de cache avec des TTL courts et du round-robin fait par le DNS. Aucune de ces solutions n'est spécifique à v4 ou v6, c'est juste que je suppose qu'en IPv6 on fera quelque-chose de mieux avec des SRV. Si tu veux implémenter du load-balancing côté serveur par contre, pas de problème, je pense que haproxy et consort savent faire de l'IPv6. C'est juste que ça n'est pas dans sa philosophie.
Si tu as de l'authentification fait par ton frontal, il faut que l'état soit répliqué sur tous tes fronts de la bonne manière. C'est complexe. Si il y a un peu de gestion de session sur les fronts, pareil.
[^] # Re: Merci !
Posté par barmic . Évalué à 3.
Si tu es distribué c'est complexe quelque soit ta version d'IP, c'est le fait d'avoir 2 logiciels qui tournent et qui doivent être synchronisés qui pose problème pas le routage, pas le reverse proxy.
D'un linuxmag d'il y a 2 ans je pense.
[^] # Re: Merci !
Posté par benoar . Évalué à 1.
Oui, sauf que si ton application ne nécessite pas d'état partagé, comme approx, tu n'as pas à t'embêter avec ; le frontal en reverse-proxy t'oblige à le faire, même si ton application ne le nécessite pas. Après, si tu gères majoritairement des applications distribuées qui nécessitent du partage d'état, avoir à le faire sur le proxy n'ajoute qu'une contrainte de plus, en effet.
[^] # Re: Merci !
Posté par barmic . Évalué à 3.
Haproxy ne gère aucun état partagé, à aucun moment. Même entre ces processus il ne fusionne pas ses statistiques. Je ne vois pas du tout de quoi tu parle.
[^] # Re: Merci !
Posté par benoar . Évalué à 1.
Si tu fais de l'authentification en frontal, il va bien falloir synchroniser tes tokens de session. C'est un exemple, il y en a peut-être d'autres.
[^] # Re: Merci !
Posté par barmic . Évalué à 3.
Le problème n'est pas de faire rêver, mais que ce n'est pas parce que l'IETF a imaginé un truc il y a 30 ans que c'est toujours d'actualité ou qu'il ne faut pas le remettre en question aujourd'hui.
[^] # Re: Merci !
Posté par benoar . Évalué à 3.
Ce que je ne comprends pas c'est que je ne reçois pas de critique claire de ce modèle : on me dit que c'est « has-been » alors que ça scale beaucoup mieux que les trucs actuels. Je sais bien que l'obstacle majeur n'est pas dans la technique mais dans la formation, le modèle de responsabilité, la mise en place de la transition, etc. Mais pourquoi dire que le modèle technique est dépassé ?!
[^] # Re: Merci !
Posté par barmic . Évalué à 3.
Je n'ai pas dit qu'il était dépassé, juste que cet un argument d'autorité. Ni plus ni moins.
[^] # Re: Merci !
Posté par barmic . Évalué à 3. Dernière modification le 07 février 2019 à 01:20.
Avant de regarder le routage, le coût réseau d'entrée/sortie des clouds tend ce genre de déploiements complètement infaisable. Tes latences explosent (tu n'est plus sur un réseau 10G), tu peux avoir une bande passante limité ou facturée, etc Tout ça fait que c'est de base une mauvaise idée sans même s'intéresser au routage.
[^] # Re: Merci !
Posté par benoar . Évalué à 1.
OK, c'est un cas extrême. Mais même en restant au « même endroit » (physiquement), souvent les réseaux en RFC 1918 sont gérés de manière anarchique, et le schéma de routage devient ossifié et on doit inventer des technos en-dessous pour refaire le routage à un niveau inférieur (à coup de technologies de VPN diverse et variées).
Je suis d'accord que le problème est plus complexe que dire juste « IPv6 », mais ça va avec : utiliser les API standard (socket), ne pas intégrer un schéma IP en dur dans le code, etc.
[^] # Re: Merci !
Posté par barmic . Évalué à 2.
Des reverse proxy qui font circuit breaker. C'est le cas de traefik notamment
[^] # Re: Merci !
Posté par benoar . Évalué à 1.
Donc pour de la protection de surcharge, ou de l'anti-DDoS, ou un truc du genre ? Ça se gère très bien niveau IP, selon moi.
[^] # Re: Merci !
Posté par barmic . Évalué à 2.
Ça dépend de ce que tu cherche à faire. traefik sait réagir à des erreurs 5xx (par exemple) retournées par ton serveur. Couche réseau je vois pas trop ce que tu va regarder comme erreur, couche transport tu peut regarder les connexions reset par le serveur. Ça n'est pas que de l'anti-DDOS, ton serveur destinataire peut juste se faire slashdoter par exemple (donc il ne s'agit pas de remplacer les solutions du genre limitation du trafic coté firewall qui vont vérifier qu'un client ne va pas générer trop de trafic par exemple.
[^] # Re: Merci !
Posté par benoar . Évalué à 1.
OK donc tu veux mettre de l'intelligence au milieu, et ça ne colle pas bien dans le modèle « classique » d'IP.
Par contre, la gestion de surcharge peut très bien s'effectuer côté client, avec des SRV et/ou l'utilisation correcte de getaddrinfo(3), qui permet de base d'itérer sur un nombre d'hôtes renvoyé par le DNS, et trouver un serveur fonctionnel dans le tas (avec des règles précises d'essai et de repli pour les SRV). Tu peux même mettre des règles en « fontal » également si tu le souhaites, sur critère X ou Y, pour renvoyer un ICMP unreachable quand tu veux.
Encore une fois, tu peux toujours utiliser des solutions « intelligentes » dans le réseau pour faire de l'analyse et du re-routage en cas de surcharge ou autre, comme l'exemple que tu as donné, mais tu peux également utiliser les méthodes plus « bout-en-bout ».
[^] # Re: Merci !
Posté par barmic . Évalué à 6.
On peut avoir une discussion sans partir dans ce genre d'idées reçues niaises, biaisées, malhonnêtes et totalement manichéenne ?
Les informations au niveau de ton service et au niveau de ton répartiteur de charge sont différentes et servent des besoins différents.
[^] # Re: Merci !
Posté par benoar . Évalué à 10.
Je vais le faire en plus court, pour montrer que ça n'est pas si difficile que ça. Il y a sûrement un manque d'intégration dans nos systèmes actuels, et c'est très triste vu l'ancienneté du protocole, mais ça se fait bien.
Donc on ajoute une IP (la manière de le faire persister dépend du système, je te laisse voir) :
Ajoute une entrée dans le DNS ; je n'ai jamais pratiqué, mais avec le standard "nsupdate" ça pourrait donner (non testé) :
Ajoute dans /etc/inetd.conf :
Et déjà tu as le service qui tourne (après un "service openbsd-inetd reload"), mais non configuré. La conf je ne la répète pas, et pour du contrôle d'accès, dans /etc/hosts.allow :
Et c'est tout. Tu as tout ce qu'il faut depuis la conf réseau, DNS jusqu'au service, en trois lignes, avec du contrôle d'accès en deux lignes de plus. Sans aucune hypothèse autre qu'un réseau « Internet » sur un OS « Unix ».
# L’avenir et le passé
Posté par Glandos . Évalué à 10.
Bon, contrairement à mes voisins du dessus, je suis parfaitement convaincu que l'IPv6 est une très bonne chose, surtout pour ce genre de choses en effet.
Par contre, c'est rigolo le mélange entre l'IPv6 et inetd. Je pensais que inetd était un vieux truc du temps où… euh… ah. Du temps où y avait pas systemd. Mais bon, c'est un autre débat :)
N'y a-t-il pas des softs qui remplissent la fonctionnalité de inetd tout en faisant un peu plus moderne, et moins invasif que le logiciel susmentionné ?
[^] # Re: L’avenir et le passé
Posté par Pinaraf . Évalué à 5.
Malheureusement, ce que fait systemd est nécessairement invasif. À partir du moment où tu veux gérer les services comme ça, tu te retrouves à intégrer beaucoup de choses… Bon, réimplémenter un client SNTP ou DHCP, faut pas déconner, c'est pas nécessaire.
Une excellente présentation sur ce sujet, sans à mes yeux de fanatisme pro-systemd:
https://www.youtube.com/watch?v=o_AIw9bGogo
[^] # Re: L’avenir et le passé
Posté par benoar . Évalué à 1.
L'article de LWN à propos de cette présentation vient d'être dispo au public aujourd'hui :
https://lwn.net/Articles/777595/
[^] # Re: L’avenir et le passé
Posté par freem . Évalué à 4. Dernière modification le 06 février 2019 à 12:39.
Dans mon cas, je me serais arrêté la, en gros, mais je n'y connais rien.
Si je ne me trompe pas (peu probable, mais les trucs que j'en ai lu jusqu'ici se résument à peu près à dire "superserveur", rien que ça), inetd est un outil pour économiser les ressources: il lance et éteins des daemons selon la demande.
Du coup, autant j'en vois l'intérêt dans un environnement ou il faut pouvoir redémarrer très vite le système (exposé à des milliers d'utilisateurs énervés d'attendre 10s de plus), mais est-ce maintenant vraiment le plus long de nos jours, de charger le daemon depuis le disque dur (voire le cache de l'OS)? Est-ce si coûteux de garder le processus en mémoire (en supposant qu'il soit capable de se nettoyer de lui-même lors de la fermeture d'une connexion, bien sûr) ou en swap?
Même en imaginant un environnement ou il y a un grand besoin de performances, je trouve que l'idée fait double emploi avec le cache de l'OS, au fond?
Du coup, il sert a quoi, inetd?
[^] # Re: L’avenir et le passé
Posté par benoar . Évalué à 3.
C'est une des raisons. L'autre est qu'il gère entièrement les aspects réseau, et que le démon final n'a qu'à se servir des entrées-sorties standard. Ça a l'avantage de la simplicité, mais si on veut un truc un peu mieux intégré dans le réseau, il faudra passer par autre chose.
Pour ton information, ce type de fonctionnement est présenté dans systemd comme une « révolution » pour ce qui est de son option de « démarrage par socket ». Donc ça doit être une considération encore d'actualité aujourd'hui.
Non effectivement, je ne pense pas que ça soit si énorme pour des « petits » démons (qui sont ironiquement la cible d'inetd, en général). Note que certains qui n'ont pas compris l'intérêt du swap le suppriment et peuvent donc être amenés à penser que « nettoyer » un processus ainsi est une bonne idée ; je pense qu'ils n'ont pas bien compris.
Pour moi c'est en priorité pour le simplicité de stdin/stdout, cf. plus haut, c'est tout.
[^] # Re: L’avenir et le passé
Posté par freem . Évalué à 3.
Quand tu dis mieux intégré, tu as des exemples?
Je sais que via un socket on peut récupérer pas mal d'informations, mais la plupart c'est via des sockets de type UNIX, me semble qu'on peut les transférer d'une machine à une autre via des tunnels mais… jamais essayé encore.
Je le sais, mais je pense que systemd est un projet qui vise à implémenter tout un environnement spécifique au noyau linux pour gérer la totalité du système.
inetd n'est pas le seul daemon qu'ils ont ré-implémenté en appelant ça une révolution: syslogd & consorts, crond, … je ne vois plus systemd comme un ensemble de logiciels mais comme une framework.
Avis personnel: les framework, c'est bien pour le jetable, dès qu'on veut maintenir un truc sur plus de 5 ans, utiliser des lib permets de n'avoir à remplacer qu'un seul composant le jour ou il y a un problème.
À la lumière d'une autre de tes réponses, cette phrase m'intrigue.
La réponse en question dit:
Si ma mémoire est bonne, syslogd nécessite une connexion sur un socket pour récupérer les logs, et non sur l'entrée standard.
Si le but est la simplicité, l'idée de logguer dans stdout plutôt que dans un socket avec le protocole syslog n'est-elle pas bonne? Après tout, un admin peut toujours utiliser des trucs comme svlogd pour ensuite récupérer ces logs?
D'ailleurs, est-ce vraiment une obligation d'utiliser syslog pour un outil UNIX standard? Si je me souviens bien, la philosophie d'UNIX, c'est de toujours balancer du texte sur les entrées et sorties standard, et pour le coup, je trouve que syslogd y déroge, mais bon, ce n'est pas mon domaine, je dois rater un truc (centraliser les logs dans un daemon permets peut-être un filtrage plus efficace, je ne sais pas).
[^] # Re: L’avenir et le passé
Posté par benoar . Évalué à 1. Dernière modification le 06 février 2019 à 14:26.
Quand tu veux une archi qui n'est pas simplement directement client-serveur, ou alors que tu veux pouvoir ouvrir des canaux de communication annexes (genre FTP passif ; oui, c'est considéré comme « has-been », mais il existerait tellement d'avantages à autoriser ce genre de chose pour des modèles d'interactions nouveaux), ou quand tu veux un contrôle plus fin des erreurs, voire même simplement quand ton protocole est un peu plus complexe que juste du question-réponse en une fois.
Oui.
Je dirais que les entrées-sorties standard sont faites pour l'interaction directe avec ton interlocuteur ; syslog a plutôt un but de log à destination d'autres programmes ou personnes. Donc je ne trouve pas ça illogique.
Si la personne qui peut mieux diagnostiquer le problème n'est pas l'interlocuteur du programme, je pense que ça vaut quand même le coup de passer par syslog. En fait, selon mon intuition, un log est vraiment un flux différent de l'applicatif, et doit pouvoir avoir plusieurs destinations, et va donc mieux dans un descripteur particulier. Mais c'est juste une impression, je ne suis pas un spécialiste des logs.
[^] # Re: L’avenir et le passé
Posté par freem . Évalué à 3.
Merci pour les réponses.
[^] # Re: L’avenir et le passé
Posté par barmic . Évalué à 4.
C'est surtout que ceux qui ont lu le code d'ip_conntrack_* qui font encore cauchemars…
[^] # Re: L’avenir et le passé
Posté par benoar . Évalué à 6.
Effectivement, et la conclusion c'est qu'il ne faut pas faire de conntrack. C'est pour moi le principal obstacle à la prolifération d'IPv6 : arrêter avec les politiques de soit-disant sécurité débiles, et ne pas faire de stateful! C'est ce qui a tué l'Internet v4 hors Web, et ce qui tuera IPv6 dans l'œuf si on fait la même connerie.
[^] # Re: L’avenir et le passé
Posté par barmic . Évalué à 4.
C'est les protocoles qui font n'importe quoi pour le coup. Lancer des connexions dans tous les sens sans pouvoir les tracker autrement c'est daubé de base. Rien que pour monitorer ce qu'il se passe sur ton réseau c'est affreux.
[^] # Re: L’avenir et le passé
Posté par benoar . Évalué à 2.
Bah tu dis ça, mais une fois que tu as monté ton ensemble de Docker dans tous les sens avec tes quarante applis containerisées qui font plein de trucs dynamique, cet ensemble va bien « lancer des connexions dans tous les sens ». Une application complexe aura ce comportement au bout d'un moment. Vouloir modéliser ça et le mettre dans le marbre d'une firewall (applicatif ou non) c'est scléroser ton modèle applicatif, qui va par la suite devoir truander tes flux pour se faufiler là où ça passe. C'est ça qui est vendu d'avance.
Et puis cette hypocrisie du « monitoring » quand aujourd'hui la moindre page web envoie des infos à droite à gauche dans tous les sens de manière dynamique… (OK, je change de contexte) personne ne le monitore, ça serait trop complexe ! Et pourtant je ne vois pas les sysadmin s'en plaindre : ils sont à la limite de leurs compétences et du coup ne font rien, alors que pour faire chier les applications standards ça ils y arrivent bien ! Bref, on ne voit et contrôle que ce qu'on veut voir et contrôler.
[^] # Re: L’avenir et le passé
Posté par barmic . Évalué à 3.
Docker va cacher ça dans un réseau spécifique. Ce qui entre et sors de ce réseau est tout à fais maîtrisable.
C'est pas mon taf, je ne connais pas du tout.
[^] # Re: L’avenir et le passé
Posté par benoar . Évalué à 1.
Gni ? Maîtrisable dans quel sens ? Si tu dis « bien décris », bah pareil pour mon application : je peux te décrire quel type de paquet/connexion elle va lancer dans quel sens. Je ne comprends pas la différence que tu fais.
[^] # Re: L’avenir et le passé
Posté par barmic . Évalué à 2.
C'est toi qui choisi quels ports sont utilisés (c'est un mapping que tu fais). Tu n'es pas obligé d'autoriser des plages de port parce que peut être que quelqu'un va les utiliser un jour
[^] # Re: L’avenir et le passé
Posté par benoar . Évalué à 4.
Alors là tu retombes complètement dans les contorsions inutiles d'IPv4 : en quoi « choisir » les ports de tes applications va t'aider à la maîtriser ? Faire du mapping de port, c'est comme faire du NAT, c'est des modalités locales « hors » de l'appli qui sclérosent le routage et le réseau ; c'est de « l'intelligence dans le réseau ». Les ports ne sont pas faits pour servir de variable d'ajustement du placement de service, à la base, même si c'est la « doctrine Docker » aujourd'hui (les mecs qui ont inventé Docker n'y connaissent rien en réseau).
Je ne comprends pas du tout ce que ça t'apporte de pouvoir bidouiller ça.
[^] # Re: L’avenir et le passé
Posté par benoar . Évalué à 0.
J'aurais bien aimé avoir ton explication sur ce choix… Alors j'enfonce un peu le clou : s'imaginer qu'on maîtrise une application parce qu'on peut « choisir » quels ports elle utilise, c'est un peu comme ceux qui croient maîtriser la consommation CPU ou mémoire d'une appli avec les cgroup. Tu te dis « Je vais interdire à l'application de faire ci ou ça », alors qu'en fait tu la casses parce que si un flux existe, c'est qu'il a une bonne raison d'exister, comme pour la conso CPU ou mémoire. J'ai l'impression que les gens font des analogies à deux francs sur « restreindre » une application comme un être vivant : ça va la « calmer » un peu de limiter son accès réseau / son CPU / sa mémoire… c'est débile !
[^] # Re: L’avenir et le passé
Posté par barmic . Évalué à 3.
Autant ton commentaire précédent pouvait être pertinent autant avec celui-ci…
La question n'est pas d'empêcher une application de faire une action, mais que la liste des actions don't elle a besoin soit suffisamment spécifié pour pouvoir s'assurer qu'elle n'est pas corrompu. Ton argument marcherait aussi bien avec les droit unix. Pourquoi interdire à tel ou tel programme d'accéder à tel ou tel répertoire ?
Si tu arrive à prendre le contrôle d'un programme/conteneur/machine virtuel, pouvoir ouvrir n'importe quel connexion vers l’extérieur représente un gros danger en terme de sécurité. Si tu le fait sur un serveur ssh par exemple, tu ne pourra pas le faire sans casser le comportement du serveur en question, ce qui augmente les chances de découvrir rapidement le problème.
Mais il est vrai (et c'est en ça que ton premier commentaire était juste), que tu peux le faire au niveau d'IP avec un firewall.
Le contrôle du comportement d'un programme, c'est la base de la sécurité (ce que tu as avec les droits unix, avec les lsm, avec les gr security, avec seccomp, etc).
[^] # Re: L’avenir et le passé
Posté par benoar . Évalué à 1.
Ah, OK, je pensais que tu parlais d'autre chose : d'interdire des flux déclarés parce que quelqu'un (l'admin, qui n'a pas codé l'appli) estime qu'ils ne sont « pas légitimes » (vu en vrai !).
Par contre, autoriser uniquement des flux spécifiés pour ton application, oui, et comme je disais c'est exactement pareil en IPv6 avec des connexions reçues/émises depuis/vers des IP diverses (que tu trouves « daubé »), et du Docker avec du mapping de port. Je persiste juste à dire que coder des prérequis applicatifs dans des éléments du réseau, c'est scléroser le réseau et perdre tous les avantages d'IPv6 (même si — encore une fois — c'est possible).
Malheureusement, cette pratique dans le réseau fait qu'on mélange l'adressage — qui concerne la topologie du réseau — avec des besoins applicatifs et de « sécurité » codés dans le réseau plus ou moins en dur, et que cela va forcément entraîner une sclérose du schéma d'adressage qui ne sera plus changeable, et qu'on devra palier « en dessous » en rajoutant une couche de routage sous-jacente, c'est à dire des tunnels ou autre technologie de VPN/overlay/etc. Et on aura perdu les propriétés de malléabilité du réseau que permet IP.
[^] # Re: L’avenir et le passé
Posté par Yth (Mastodon) . Évalué à 3. Dernière modification le 10 mars 2019 à 09:52.
Bah de mon point de vue inetd c'est pour permettre des services simples utilisés très rarement.
Par exemple tu veux avoir un accès FTP à une machine de ton réseau, mais tu utilises ça une fois tout les 36 du mois.
C'est un brin overkill de paramétrer et démarrer un serveur FTP qui va tourner en permanence, même s'il ne fait strictement rien.
Inetd est là pour regrouper plusieurs de ces services, genre authentification réseau, pop/imap basiques (pour réseau local), bootp, etc.
Ou n'importe quel service maison, qui permet d'avoir des données fabriquées via un script quelconque, sur le réseau, avec la sécurité qu'on saura bien y mettre…
Tout ça avec une configuration triviale et un démon qui ne fait que ça.
Maintenant pour tous ces cas d'utilisation, si tu as un objectif de montée en charge, de mise à disponibilité publique, de paramétrage spécifiques (typiquement pour le mail, on ne peut plus se permettre de faire des configurations triviales aujourd'hui), etc, il vaut mieux passer par un démon dédié, paramétré aux petits oignons, firewallé intelligemment etc.
Et si tu lances inetd pour un seul service derrière, c'est aussi une surcouche inutile, autant avoir l'unique service lancé.
En gros c'est facile, pratique et léger pour du bricolage.
Et je trouve qu'un cache local de mise à jour de paquets, local pour le réseau de la maison, ça rentre dans le bricolage.
Si c'est pour un réseau d'entreprise, vaut peut-être mieux construire quelque chose de plus solide.
Bizarrement un truc à base de systemd ne me paraît pas rentrer dans la catégorie « plus solide», mais ce troll est très différent, et n'entre pas dans le sujet je pense.
Yth.
[^] # Re: L’avenir et le passé
Posté par freem . Évalué à 2.
Donc, c'est bien pratique pour le dev qui teste son code et dont la machine a autre chose à faire, dans le cas d'un serveur ou tu veux être sûr que les ressources sont disponibles, c'est ridicule. Dans le cas de l'embarqué, avec de faibles perfs, ça peut cependant être utile.
En fait, les environnements contraints en perf, ou pour lesquels c'est anecdotique, c'est OK: le dev, l'embarqué. Par contre, pour un serveur, j'en doute: je préférerai que mon serveur soit stable, quitte à ce que les ressources soient parfois inutilisées. J'ai, en prod, eu assez de problèmes avec des alimentations électriques pas assez dimensionnées pour savoir le genre de bugs que peuvent causer des ressources insuffisantes. Merci, mais pour sous-dimensionner du hard, faut vraiment avoir envie de faire chier ses ingés!
[^] # Re: L’avenir et le passé
Posté par Glandos . Évalué à 2.
Plaisir à son directeur administratif et financier.
# Autre besoin: pacserve
Posté par jnanar (site web personnel) . Évalué à 4.
J'en profite pour faire la pub de pacserve sous Archlinux même s'il ne rempli pas tout à fait le même besoin.
Ayant 3 machines sous Arch à la maison, je voulais accélérer les mises à jour globales des systèmes et pacserve fait le boulot.
Il permet de partager facilement le cache de chaque machine facilement. Chaque machine partage son dossier
/var/cache/pacman/pkg(dossier des paquets téléchargés sur internet) et lors du téléchargement des paquets, la machine cherche l'archive sur le LAN avant de le télécharger sur le miroir classique.Il est possible de l'utiliser à la place de pacman avec les même options ou de modifier la configuration de pacman pour qu'il aille chercher les paquets sur le LAN automatiquement.
[^] # Re: Autre besoin: pacserve
Posté par gUI (Mastodon) . Évalué à 2.
Justement je découvre Archlinux depuis la semaine dernière et je me posais la question d'un équivalent à squid-deb-proxy (que j'utilise plutôt que apt-cache-ng). Merci !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Autre besoin: pacserve
Posté par benoar . Évalué à 1.
Et puis de ce que j'ai compris de la description de pacserve, c'est qu'il permet de découvrir le proxy « automagiquement » sur le LAN ; c'est faisable avec squid-deb-proxy-client en ce qui concerne ta suggestion de proxy APT, et il utilise la découverte de service locale par mDNS (DNS-SD), qui utilise les enregistrements SRV.
[^] # Re: Autre besoin: pacserve
Posté par gUI (Mastodon) . Évalué à 3.
Oui squid-deb-proxy est super pour ça : tu installes le serveur sur l'une des machines du réseau local, puis sur chaque client tu installes simplement le paquet squid-deb-prox-client et c'est tout. Pas de modification des sources à effectuer.
Et sur un portable par exemple où tu peux potentiellement quitter ton réseau local, rien de spécial à faire, tu perdras juste qques secondes de timeout puis tu téléchargeras sur les répos de référence normalement.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# apt-cacher-ng
Posté par freem . Évalué à 2.
Tiens, je n'avais jamais fait attention à son existence, merci, ça pourrait être utile. Et pour commencer, ça va se rendre utile par un
touch /etc/apt-cacher-ng/userinfo.htmlpour désactiver ça… en tout cas, ça à l'air de désactiver le frontal web de conf, je vais creuser un peu plus le sujet quand j'aurais le temps.Raison inconnue, ça veut bien dire que tu n'es pas sûr que le problème ne viens pas du système de fichiers ou d'un autre processus?
[^] # Re: apt-cacher-ng
Posté par gUI (Mastodon) . Évalué à 3.
J'ai eu le même soucis de désynchronisation entre mon cache et le vrai repo (remote). Du coup j'ai un peu cherché et trouvé pas mal de témoignages dans ce sens. Je suis ensuite passé à
squid-deb-proxyqui est bcp plus fiable (aucun soucis avec un serveur Debian, 1 client Debian et 5 clients Ubuntu en 2 ans je pense).En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: apt-cacher-ng
Posté par benoar . Évalué à 1.
Je suis à peu près sur que ça n'était pas de la corruption de FS (pas d'interruption brutale de processus ni de reboot), mais plutôt des histoires « classiques » de téléchargement interrompu ou de mirroir en cours de modification qui ont laissé le cache dans en état bâtard. Mais ça n'est qu'une supposition.
# My 2 cents
Posté par LaBienPensanceMaTuer . Évalué à 6.
Bon, je rejoins les autres sur la partie inetd: cette méthode de lancement de service est hérité de l'époque ou les serveurs n'était pas aussi puissant qu'aujourd'hui, les firewalls et services moins "flexibles" et servait uniquement à mettre en place un filtrage IP basique + du lancement de service à la demande.
Aujourd'hui, je pense que tu pourrais tout à fait lancer ton service via un bon vieux init.d (ou fichiers services, si tu manges de ce pain là :p) .
Sinon, tu écris:
Or j'ai cru comprendre que tu déployais tout ça sur un réseau local, n'est ce pas ?
Si c'est effectivement le cas, la rareté de l'IP ne te concerne pas et tout ce que tu décris aurais pu s'appliquer en IPv4 : rien ne t'empêche d'ajouter une adresse (v4 ou v6) à eth0 et de faire tourner ton cache de paquet sur cette nouvelle adresse.
Après, effectivement, si tu dois également rendre ce service dispo sur internet, alors oui, la rareté de l'IP est un problème :)
Je respecte cependant la démarche: il va bien falloir s'y mettre un jour ou l'autre, les jours de IPv4 sont comptés…
[^] # Re: My 2 cents
Posté par benoar . Évalué à 6.
Tout à fait, je présentais juste ce service qui avait ce type de fonctionnement, mais n'importe quel démon est le bienvenu !
Bzzz ! Tu fais l'erreur de penser « local vs. global » : tu as inscrits dans la définition de ton service le périmètre qu'il aura. C'est gravé dans le marbre, et dès que ton périmètre devra changer, tu seras dans la merde. En IPv6, tu mets ton service « sur le réseau » (d'où le titre de ce journal), et tu définis après (et de préférence aux extrémités, pas dans le réseau) sa portée.
Et tu devras te taper des problématiques de routage à la con au moindre changement topologique. C'est vu et revu.
[^] # Re: My 2 cents
Posté par freem . Évalué à 2.
Du coup, autre point qui m'intéresse: ton IPv6, tu la distribue comment? Codée en dur dans la machine ou distribuée par un DHCP?
Et le jour ou tu veux mettre ton service sur le réseau, tu vas bien passer par une machine (qui fasse à minima firewall, routeur, et peut-être d'autres choses) qui aura 2 IPs, une en local, une en global. Donc, il faudra bien que tu fasse une traduction d'adresse non? Comment ça marcherait tout ça?
[^] # Re: My 2 cents
Posté par Pinaraf . Évalué à 7.
Combien, 30 ans d'éducation réseau à casser ? Ça va être dur… :)
Prenons Marcel Toto, fier propriétaire du bloc 2000:2001:2002:2000::/56 attribué par son fournisseur d'accès internet RFC.com.
Marcel décide de répartir son réseau en 3 sous-réseaux:
- 2000:2001:2002:2001::/64 pour ses serveurs et services réseau principaux…
- 2000:2001:2002:2002::/64 pour ses ordinateurs de bureau, portables…
- 2000:2001:2002:2066::/64 pour le wifi invité.
Quand son serveur, 2000:2001:2002:2001::73, échange avec son ordinateur de bureau, 2000:2001:2002:2002::42, la communication va se faire sans traduction d'adresse, vu que les adresses sont uniques. L'équipement qui passera les paquets pourrait avoir, mettons, 2000:2001:2002:2001::1 et 2000:2001:2002:2002::1, il n'aura pas à traduire d'adresses pour autant. Il fera un travail de passe-plat, comme n'importe quel switch réseau sait le faire.
C'est justement là la différence avec le NAT.
En IPv4, on a le serveur de linuxfr.org qui parle à mon switch port TCP 12345, et le switch pour chaque paquet doit dire «ho, c'est pour moi, merc… et merde, non, c'est encore le gros lourd qui veut passer un message à l'autre con… bon, je colle une nouvelle étiquette, et c'est parti».
Bien sûr, juste sur mon réseau local, serveurs et clients peuvent se parler sans NAT, sans trop se prendre la tête… par contre quand tu commences à avoir des serveurs exposés sur l'extérieur, ça devient plus rigolo à router justement à cause du NAT. Alors qu'en IPv6, tu n'as pas à faire tout ça.
Tu noteras par contre que je n'ai pas parler du firewall pour ce qui vient de l'extérieur ou ce qui va entre chaque zones, ni de l'allocation des IPs, ce sont d'autres sujets (on répète tous ensemble : «le NAT n'est pas une sécurité» − https://blog.webernetz.net/why-nat-has-nothing-to-do-with-security/)
[^] # Re: My 2 cents
Posté par freem . Évalué à 3.
Nope, je dirais a peu près 17 seulement, ça pourrait être 2 fois plus simple que prévu, si l'administration était mon métier, mais ce n'est pas le cas (ce qui ne m'empêche pas de vouloir savoir comment ça marche).
Pour le reste, si je comprend bien, ton routeur dispose d'une plage d'IPs alors qu'en IPv4, sur les pauvres réseaux domestiques que j'ai eu à gérer, il n'en a qu'une seule. Du fait de l'abondance des IPs, donc, il suffit d'affecter les IPs que l'on souhaite utiliser à une machine spécifique et le tour est joué? Du coup, la différence contrairement à IPv4, c'est qu'il n'a pas besoin d'aller ouvrir le protocole suivant (TCP/UDP/ICMP/Que-sais-je/…) d'où un gain de simplicité dans la pile logicielle?
A mon grand regret, mais je comprend (que tu ne le fasse pas, je veux dire). De toute façon, je suppose qu'il doit y avoir un équivalent au DHCP qui fonctionne plus ou moins comme ceux que l'on utilise pour IPv4, à l'exception du fait de la quantité d'adresses dispo que l'on ne se prive pas pour assigner plusieurs IPs à une même interface, par exemple une IP publique et une IP locale, qui permette éventuellement de ne lancer les services sensibles que sur l'IP locale?
Autant le discours ne me surprend pas (je n'ai jamais vraiment considéré le NAT comme pour la sécurité… je ne me suis jamais vraiment posé la question non plus, à vrai dire) mais je pense que l'on peut faire la confusion du fait que les box internet font firewall en plus du NAT. Ainsi que DHCP et autres joyeusetés qui devraient à mon humble avis ne pas se situer sur l'équipement qui est directement exposé au réseau public… surtout quand on constate que bien souvent, pour modifier la conf DHCP, il faut rebooter le routeur, super…
En tout cas le lien est sympa, y'a plein de mots-clés à chercher pour qui veut apprendre un peu le réseau \o/
[^] # Re: My 2 cents
Posté par Pinaraf . Évalué à 3. Dernière modification le 07 février 2019 à 10:44.
Je parlais du cas général, je n'ai pas prétendu que tu avais 30 ans d'éducation en réseau (sinon je crois que tu m'écraserais allègrement) :)
Voilà. La quantité d'adresses IPs et de réseaux disponibles fait qu'il n'est plus nécessaire de jongler avec des adresses publiques/privées, et donc les routeurs ne font que router les IPs, sans regarder plus loin. Cela simplifie considérablement le travail. Sur un gros réseau, avec un fort trafic, la charge CPU pour le NAT n'est pas négligeable, et cela commence à consommer de la RAM. Et je ne dis pas ça comme un troll : dans des clouds professionnels à beaucoup de brouzouf$ par mois, j'ai déjà eu des connexions réseau qui se coupent entre deux systèmes parce qu'ils n'ont pas envoyé de paquet pendant X minutes et que le routeur a une règle pour supprimer périodiquement de la table de NAT les connexions «inactives» (et quand ça coupe, ça te prévient pas, du coup ton prochain paquet part dans un trou noir et ton appli peut faire la gueule)
Tu m'auras pas, je le ferai pas ! :)
Allez, on va faire ça en très court : il y a deux protocoles, SLAAC (StateLess Auto Adress Configuration) et DHCPv6. DHCPv6 a des fonctionnalités en plus par rapport à SLAAC (la RFC 6106 est rarement implémentée pour passer les serveurs DNS en SLAAC hélas, et elle est très peu connue), mais normalement tu peux n'utiliser que SLAAC sur la plupart des réseaux.
[^] # Re: My 2 cents
Posté par freem . Évalué à 3.
Tu veux dire qu'il n'existe plus de plages privées, du coup? La ou Internet IPv4 est un réseau de réseaux, avec des passerelles, avec IPv6 il n'y a plus qu'un seul réseau?
Vais aller lire ça, merci.
[^] # Re: My 2 cents
Posté par benoar . Évalué à 4.
« Réseau de réseaux » ne veut pas forcément dire « imbrication » avec NAT ! Internet v6 est autant un réseau de réseau qu'IPv4, c'est juste que l'interconnexion se fait de manière « plate » jusqu'aux extrémités.
[^] # Re: My 2 cents
Posté par benoar . Évalué à 4.
Comme tu veux. C'est la « complexité » d'IPv6 : vu que ta topologie n'est pas « gérée dynamiquement » par le NAT¹, il faut que tu aies un plan d'adressage « bien fait » au départ. Il existe plein de conseils là-dessus, et c'est une problématique routeur ; une fois que ton réseau est en place, c'est plus simple pour l'adressage des serveurs et services.
Non. Oublie « local » ou « global » ; enfin, dans un réseau simple². Tu ne dois pas penser « interface », mais « adressage » : comment adresses-tu ta machine ? Ton routeur, si tu veux une seule IP sur le loopback (façon Cisco), ça se fait très bien. Et le loopback ça n'est aucune des deux interfaces que tu viens de décrire ! Moi en général j'adresse globalement l'interface upstream (« nord » pour certains). Au sud, je laisse uniquement link-local, s'il n'y a pas de raison particulière de l'adresser en global. Tu vas me dire « ah ! mais t'as une locale d'une côté et globale de l'autre ! » mais ça n'est pas ça : j'ai de toutes façons des link-local sur mes deux interfaces, et je rajoute des globales où je veux. Question routage, je ferai passer les paquets tels-quels d'une interface à l'autre, après décision de routage sur la destination : c'est la base d'IP. Et dans IPv6 quand on ne fait pas de traduction, ça a l'avantage qu'un paquet sera identique quel que soit le point du réseau où il est observé : c'est une propriété absolument déterminante point de vue débugabilité du réseau, à un point que tu ne peux pas imaginer (je debug parfois des problèmes avec NAT des deux côté où les gens n'ont aucune idée de qui l'a envoyée ni qui la recevra).
1 : c'est dur à expliquer clairement, je peux préciser si tu veux.
2 : je sous-entend quand tu n'ajoutes pas un réseau « parallèle » en ULA
[^] # Re: My 2 cents
Posté par freem . Évalué à 2.
Je pense que je comprend, l'idée globale au moins.
Je suis pas admin réseau, mais je suis dev, j'imagine très bien à quel point savoir qu'un message proviens de A et veut aller à B facilite les choses plutôt que d'avoir un message qui proviens de A et va peut-être vers B, C, ou D. Surtout quand il y a plus d'un message…
[^] # Re: My 2 cents
Posté par Pinaraf . Évalué à 7.
Tiens, je croyais que le minitel n'existait plus :)
[^] # Re: My 2 cents
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
À l'époque c'était surtout la place en mémoire qui comptait pour ça.
Pas vraiment. Un logiciel lancé par
inetdn'a pas de spécificité réseau, puisqueinetdraccorde stdin/stdout du process qu'il lance sur une socket qu'il crée lui même, alors que depuisinit.d, il faut faire socket/bin/accept et tout ce qui tourne autour…[^] # Re: My 2 cents
Posté par freem . Évalué à 3.
Il existe des serveurs qui n'ouvrent pas de sockets et ne font que lire stdin? J'imagine que, sur le principe, c'est faisable, et ça pourrait même permettre de faire un serveur avec un simple script shell, mais, en pratique, je serais curieux de voir un exemple.
[^] # Re: My 2 cents
Posté par benoar . Évalué à 2.
Heu… c'est le principe d'approx que je viens de décrire dans le journal ! Sauf que je vois qu'en fait il l'utilise comme un socket en faisant un getsockname() pour commencer, et du coup je me rends compte que je connais mal inetd car à priori on peut faire bien plus que de simple entrées-sorties : c'est bien le socket tel qu'ouvert par inetd qui est passé sur stdin/stdout.
[^] # Re: My 2 cents
Posté par Yth (Mastodon) . Évalué à 2. Dernière modification le 10 mars 2019 à 10:57.
inetd permet d'utiliser des services avec stdin/stdout via un wrapper tcp appelé généralement tcpd, par exemple tu peux faire :
Et ensuite
telnet machine 2000va t'afficher la sortie denetstat -alancé en root.Comme on le voit c'est à la fois sécurisé, puissant et…
Ouais, bon, c'est du super bricolage :)
Mais c'est un des intérêts d'inetd.
Yth.
[^] # Re: My 2 cents
Posté par freem . Évalué à 2.
bah, à bien y réfléchir, c'est pas faux, inetd, ça peut juste gérer. Juste, c'est du cas par cas, et ça doit être supervisé par systemd/daemontools, ainsi qu'un sysadmin compétent pour que ça finisse pas en feuille excel sur laquelle repose une économie entière…
[^] # Re: My 2 cents
Posté par benoar . Évalué à 2. Dernière modification le 11 avril 2019 à 11:20.
Encore une fois, les tcpwrappers et tcpd sont évoqués dans le journal : c'est utile pour du contrôle d'accès, mais tu n'en as même pas besoin pour ton cas simple. Essaye avec /bin/cat directement : ça marche. Étrangement, ton cas netstat ne marche pas seul, pour une raison inconnue ; ça marche par contre bien avec ss (parce qu'il est meilleur ? :-P)
# Pour remplacer inetd
Posté par Glandos . Évalué à 2.
Il y a systemd : https://manpages.debian.org/unstable/systemd/systemd-socket-activate.1.en.html
Mais pour éviter les trolls, j'ai découvert cet utilitaire via cette tentative de remplacement : https://gitlab.com/dkg/socket-activate
Je ne suis pas sûr que le deuxième fournisse le mode
--inetdu premier. Mais bon, il a été écrit il n'y a pas très longtemps.[^] # Re: Pour remplacer inetd
Posté par benoar . Évalué à 3.
Oui, ce que tu pointes (qui est un utilitaire) est plutôt défini par les configurations de socket : https://manpages.debian.org/unstable/systemd/systemd.socket.5.en.html
Je précise dans le journal qu'une configuration pour approx est fournie par défaut dans ce format. Cependant, le manuel ne semble pas indiquer la possibilité de spécifier un nom d'hôte dans "ListenStream" (équivalent du premier champ pour inetd), ce qui est pour moi une régression inacceptable (les identifiants sous forme de noms changent en général moins que les IP, et dans mon exemple le nom d'hôte sera spécifié potentiellement pour d'autres services, et la modification serait laborieuse et prompte à erreur si elle se faisait par adresse ; sans parler de la lourdeur avec les IPv6). Encore une réinvention de la roue en moins bien.
Si quelqu'un qui utilise systemd pouvait me contredire, je n'en serais que plus heureux ; mais il faudrait au moins mettre à jour le man.
[^] # Re: Pour remplacer inetd
Posté par Glandos . Évalué à 3.
Effectivement, d'après le code, ça ne peut lire que des IPv4 ou v6 en notation numérique. Pas de résolution possible. Je n'ai pas essayé de faire un socket pour voir.
[^] # Re: Pour remplacer inetd
Posté par freem . Évalué à 3.
Je n'apprécie que peu l'idée d'utiliser systemd, mais honnêtement, je trouve l'idée de cet utilitaire ridicule. Pourquoi?
Parce que inetd & co, c'est des outils d'optimisation: il faut économiser la RAM (ou rebooter le serveur rapidement), donc on n'invoque un démon que quand il est nécessaire.
Donc, il faut que l'invocateur soit le plus léger et rapide possible.
Du coup, c'est quoi l'intérêt de coder ça en python? Je n'ai personnellement pas l'impression que python soit conçu pour être léger ou rapide au démarrage, après tout, on parle bien d'un langage dont un des arguments de vente est "battery included", non? et les piles, ça pèse lourd.
Python, c'est bien, pour la colle, le code non critique, le truc qui prend «pas de ressources». Donc, j'ai beaucoup de mal a en voir l'utilité pour économiser des ressources ou accélérer un boot: je ne serais pas surpris que cet outil bouffe plus de RAM que d'avoir un TFTPd, SSHd, DHCPd qui tournent h24… mais peut-être que je me trompe.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.