Hugues Larrive a écrit : > ------- Original Message ------- Le jeudi 30 juin 2022 à 08:55, > BERTRAND Joël <joel.bertr...@systella.fr> a écrit : > > >> > >> > >> Bonjour à tous, >> > > Bonjour,
Bonjour, >> J'utilise des rPI 3 comme point d'accès WiFi. Cela fonctionne >> bien, > > Moi aussi, il a une bonne portée. > >> mais depuis la dernière mise à jour de Debian, il y a comme un >> problème lors du démarrage et je suis contraint de démarrer les >> services à la main. Ça m'amuse cinq minutes, pas plus... :-( >> > > Pour en revenir à systemd, c'est bien pour les stations de > travail, beaucoup moins pour les serveurs ou l'embarqué. Mon pi3 > est en Debian Systemd/Linux (buster), mais maintenant je préfère > Devuan pour ce genre d'application. C'est un fork de Debian qui > offre le choix entre 3 systèmes d'init : - le traditionnel sysvinit > ; - openrc (Gentoo) ; - runit (void linux). Oui, moi aussi, je vire de plus en plus Debian pour autre chose (Devuan, mais pas uniquement). > Il est possible de migrer une debian vers devuan, la procédure est > sur le site. Il y a un moment ou apt "couine" un peu, mais ça passe > en insistant un chouya, je l'ai déjà fait trois fois, dont 2 > directement de debian 9 vers devuan chimaera (debian 11). > > Les avantages sont : - un démarrage séquentiel (clarté de la > console et des journaux) ; - une description claire du démarrage > dans /etc/rc* ; - pas de "merged /usr" ; - pas de renommage des > interfaces réseau. On est parfaitement d'accord, ce ne sont que des avantages, mais là n'est pas la question. > L’inconvénient c'est que l'absence de systemd pose des problèmes > pour les softs qui en dépendent plus ou moins comme lxc... NetBSD se démerde très bien avec un systemd-fake. Je n'ai jamais regardé plus que cela, mais j'ai vu passer quelques liens sur les listes officielles. >> Jusqu'ici, ces machines utilisaient un script rc.local qui n'est >> plus appelé. Ce script se terminait pas : >> > > Je crois que la commande magique pour qu'il soit de nouveau appelé > c'est : systemctl unmask rc.local.service Ne fonctionne pas. Ce n'est pas reproductible d'un démarrage à un autre, j'ai essayé. > C'est pas dit que ça fonctionne, il me semble que dans sysvinit, > rc.local est exécuté tout à la fin donc après networking mais > qu'avec systemd la cible multi utilisateur qui le déclenche est > atteinte avant la cible network... Voilà. Et comme le truc ne démarre pas les daemons dans un ordre établi... > De toute façon rc.local n'est pas fait pour ça, voir : > https://arkit.co.in/using-rc-local-file-execute-commands/ > > Il y a trois façons de configurer le réseau sous debian : - > /etc/network/interfaces (historique mais pas encore obsolète) ; - > systemd (moderne...) ; - network-manager (pour les ordinateurs de > bureau / portable). > > > Je pense que la méthode la mieux adaptée pour un point d'accès > sous debian est /etc/network/interfaces, surtout quand on ne s'en > sort pas avec systemd. C'est la plus éprouvée et la mieux > documentée sous debian. C'est exactement ce que j'utilise. Mais systemd passe par dessus avec des ifup@.service et autres joyeusetés. Jusqu'à Debian 10, ça passait, mais aujourd'hui, systemd est le plus fort et laisse les interfaces radio 'down' en raison de cette dépendance à rfkill. Si je retire rfkill de l'équation, les interfaces radio sont toujours bloquées par défaut (c'est un comportement nouveau). >> rfkill unblock 0 ifup wlan0 iptables-legacy -t nat -A POSTROUTING >> -s 192.168.11.0/24 -j MASQUERADE dhcpd exit 0 >> > > > Si rfkill est nuisible, autant le supprimer (apt remove rfkill). > Je n'en vois pas l'utilité sur un point d'accès. > Il faut néanmoins activer l'interface wlan0 qui est désactivée par défaut depuis la dernière mise à jour du système. > Pourquoi ne pas avoir utilisé /etc/network/interfaces ? Est-il > nécessaire de faire du routage ? Personnellement j'ai préféré > utiliser un pont : > > # /etc/network/interfaces auto lo br0 iface lo inet loopback > > iface br0 inet static address 192.168.1.253/24 gateway 192.168.1.1 > pre-up iw dev wlan0 set type __ap up /etc/nftables.conf # > > # dans /etc/hostapd/hostapd.conf : bridge=br0 Je ne veux pas un pont parce qu'il y a du filtrage et que je tiens absolument à isoler les réseaux pour des raisons de sécurité. Quant au réseau, il est géré par /etc/network/interfaces, exclusivement. JKB