Re: @^\[@^#{[ de systemd !
Hugues Larrive a écrit :
> ------- Original Message ------- Le jeudi 30 juin 2022 à 08:55,
> BERTRAND Joël <joel.bertrand@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
Reply to: