Re: @^\[@^#{[ de systemd !
Hugues Larrive a écrit : > --- Original Message --- Le jeudi 30 juin 2022 à 08:55, > BERTRAND Joël 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
Re: @^\[@^#{[ de systemd !
--- Original Message ---
Le jeudi 30 juin 2022 à 08:55, BERTRAND Joël a
écrit :
>
>
> Bonjour à tous,
>
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).
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.
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...
> 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
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...
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.
> 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.
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
Avec cette configuration on obtient un point d'accès "transparent"
au niveau IP : les périphériques wifi sont sur le même sous-réseau
que l'ethernet, il peuvent recevoir une adresse du DHCP de la
passerelle ou d'un serveur, le point d'accès n'a qu'une seul IP
sur br0. Il n'est pas nécessaire d'activer l'IP forwarding ou de
faire du masquerading avec nftables, il faut juste installer
bridge-utils.
Si on préfère isoler le wifi :
# /etc/network/interfaces
auto lo eth0 wlan0
iface lo inet loopback
iface eth0 inet dhcp
iface wlan0 inet static
address 192.168.11.254/24
pre-up iw dev wlan0 set type __ap
bridge_ports eth0 wlan0
#
Le script (mode 755) /etc/nftables.conf que j'utiliserais :
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0;
}
chain forward {
type filter hook forward priority 0;
}
chain output {
type filter hook output priority 0;
}
chain postrouting {
type nat hook postrouting priority 100; policy accept;
ip saddr 192.168.11.0/24 oifname eth0 masquerade
}
}
#
J'aime bien les scripts nft probablement à cause des accolades
et de l'indentation. Je les trouves plus lisibles que les
scripts iptables qui m'avaient toujours rebuté.
Avec du filtrage et du NAT/PAT (soyez indulgent, je débute en
nft) ça donnerait ce genre de chose :
#!/usr/sbin/nft -f
#
# nettoyage des règles existantes
flush ruleset
define LAN_IF = eth0
define WLAN_IF = wlan0
define WLAN_NET = 192.168.11.0/24
# un serveur en wifi
define WSRV_IP = 192.168.11.1
# table de filtrage ipv4
table inet filter {
chain output {
# le trafic sortant est autorisé par défaut
type filter hook output priority 0; policy accept;
}
chain inbound {
# le trafic entrant est rejeté par défaut
type filter hook input priority 0; policy drop;
# accepter les
Nettoyage du spam : juin 2022
Bonjour, Comme nous sommes en juillet, il est désormais possible de traiter les archives du mois de juin 2022 des listes francophones. N'oubliez bien sûr pas d'ajouter votre nom à la liste des relecteurs pour que nous sachions où nous en sommes. Détails du processus de nettoyage du spam sur : https://wiki.debian.org/I18n/FrenchSpamClean OpenPGP_signature Description: OpenPGP digital signature
Re: @^\[@^#{[ de systemd !
didier gaumet a écrit :
>
>
> Bonjour,
Bonjour,
> Si je ne comprends pas de travers (c'est toujous possible, hein...), je
> pense qu'il s'agit potentiellement d'une caractéristique de Systemd qui
> requiert des instructions assez explicites:
> - tu spécifies que ton service rfkill doit tourner après ("After=") le
> service systemd-rfkill.
> - Mais ce faisant, littéralement, tu ne spécifies pas que pour toi
> systemd-rfkill *doit* être lancé, donc il ne l'est pas car la clause
> "After=" ne l'implique pas.
> - En plus de la clause "After=" pour le séquencement, il faudrait
> spécifier une clause "Requires=" pour indiquer que tu veux que le
> service ssytemd-rfkill soit lancé
>
> cf https://wiki.archlinux.org/title/Systemd#Handling_dependencies
Exact. J'ai fait simple parce que systemd-rfkill est lancé sur le
système (et est lancé avant rfkill, je le vois sur la console). Je vais
rajouter cette clause, mais ce n'est pas la bonne réponse ;-)
Bien cordialement,
JKB
Re: @^\[@^#{[ de systemd !
Bonjour,
Si je ne comprends pas de travers (c'est toujous possible, hein...), je
pense qu'il s'agit potentiellement d'une caractéristique de Systemd qui
requiert des instructions assez explicites:
- tu spécifies que ton service rfkill doit tourner après ("After=") le
service systemd-rfkill.
- Mais ce faisant, littéralement, tu ne spécifies pas que pour toi
systemd-rfkill *doit* être lancé, donc il ne l'est pas car la clause
"After=" ne l'implique pas.
- En plus de la clause "After=" pour le séquencement, il faudrait
spécifier une clause "Requires=" pour indiquer que tu veux que le
service ssytemd-rfkill soit lancé
cf https://wiki.archlinux.org/title/Systemd#Handling_dependencies
Re: @^\[@^#{[ de systemd !
Bonjour, pas de réponse, j'ai abandonné depuis longtemps. Je fais dans crontab root @reboot /usr/local/bin/aafterReboot.sh et le script #!/bin/bash debug=false second=0 max_time=10 while [ "$second" -lt "$max_time" ]; do sleep 1 second=$((second+1)) [ $debug = true ] && echo $second case $second in 1) ;; 2) ;; 3) ;; 4) ;; 5) ;; 6) ;; 7) ;; 8) ;; 9) ;; 10) ;; *) ;; esac done exit 0 et je suis heureux :) Le 30/06/2022 à 08:55, BERTRAND Joël a écrit : Bonjour à tous, J'utilise des rPI 3 comme point d'accès WiFi. Cela fonctionne bien, 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... :-( Jusqu'ici, ces machines utilisaient un script rc.local qui n'est plus appelé. Ce script se terminait pas : rfkill unblock 0 ifup wlan0 iptables-legacy -t nat -A POSTROUTING -s 192.168.11.0/24 -j MASQUERADE dhcpd exit 0 Aujourd'hui, lorsque je démarre un rPI, je me retrouve avec une interface wlan0 qui est bloquée par défaut (soft) : root@abel:~# rfkill ID TYPE DEVICESOFT HARD 0 wlan phy0 blocked unblocked 1 bluetooth hci0 blocked unblocked root@abel:~# Là, je ne comprends pas. L'interface est _toujours_ active lors de l'extinction et systemd.restore_state vaut par défaut 1. Si je lance successivement : rfkill unblock 0 ifup wlan0 hostapd -B -P /run/hostapd.pid /etc/hostapd/hostapd.conf dhcpd je récupère une borne WiFi fonctionnelle. J'ai donc écrit dans /etc/systemd/system les choses suivantes : root@abel:/etc/systemd/system# cat rfkill.service [Unit] Description=rfkill Before=ifup@wlan0.service After=systemd-rfkill [Service] Type=oneshot ExecStart=/usr/sbin/rfkill unblock 0 [Install] WantedBy=network.target root@abel:/etc/systemd/system# cat route.service [Unit] Description=Wlan route After=networking.service [Service] Type=oneshot ExecStart=/usr/sbin/iptables-legacy -t nat -A POSTROUTING -s 192.168.11.0/24 -j MASQUERADE [Install] WantedBy=network.target root@abel:/etc/systemd/system# cat dhcpd.service [Unit] Description=dhcpd After=route.service [Service] Type=forking ExecStart=/usr/sbin/dhcpd [Install] WantedBy=network.target Si route.service et dhcpd.service sont appelés, pas moyen que rfkill.service soit appelé au bon moment. Il faut pourtant qu'il soit appelé _après_ systemd-rfkill (qui merdoie) et avant que l'interface wlan0 soit montée par ifup.service. Lors du démarrage, systemd provoque un timeout sur rfkill.service et merdoie sur hostapd.service (là, ce n'est pas un timeout, mais des lancements de hostapd en boucle parce que wlan0 n'existe pas). Une idée pour corriger la chose, parce que je ne comprends pas trop. Bien cordialement, JKB
@^\[@^#{[ de systemd !
Bonjour à tous, J'utilise des rPI 3 comme point d'accès WiFi. Cela fonctionne bien, 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... :-( Jusqu'ici, ces machines utilisaient un script rc.local qui n'est plus appelé. Ce script se terminait pas : rfkill unblock 0 ifup wlan0 iptables-legacy -t nat -A POSTROUTING -s 192.168.11.0/24 -j MASQUERADE dhcpd exit 0 Aujourd'hui, lorsque je démarre un rPI, je me retrouve avec une interface wlan0 qui est bloquée par défaut (soft) : root@abel:~# rfkill ID TYPE DEVICESOFT HARD 0 wlan phy0 blocked unblocked 1 bluetooth hci0 blocked unblocked root@abel:~# Là, je ne comprends pas. L'interface est _toujours_ active lors de l'extinction et systemd.restore_state vaut par défaut 1. Si je lance successivement : rfkill unblock 0 ifup wlan0 hostapd -B -P /run/hostapd.pid /etc/hostapd/hostapd.conf dhcpd je récupère une borne WiFi fonctionnelle. J'ai donc écrit dans /etc/systemd/system les choses suivantes : root@abel:/etc/systemd/system# cat rfkill.service [Unit] Description=rfkill Before=ifup@wlan0.service After=systemd-rfkill [Service] Type=oneshot ExecStart=/usr/sbin/rfkill unblock 0 [Install] WantedBy=network.target root@abel:/etc/systemd/system# cat route.service [Unit] Description=Wlan route After=networking.service [Service] Type=oneshot ExecStart=/usr/sbin/iptables-legacy -t nat -A POSTROUTING -s 192.168.11.0/24 -j MASQUERADE [Install] WantedBy=network.target root@abel:/etc/systemd/system# cat dhcpd.service [Unit] Description=dhcpd After=route.service [Service] Type=forking ExecStart=/usr/sbin/dhcpd [Install] WantedBy=network.target Si route.service et dhcpd.service sont appelés, pas moyen que rfkill.service soit appelé au bon moment. Il faut pourtant qu'il soit appelé _après_ systemd-rfkill (qui merdoie) et avant que l'interface wlan0 soit montée par ifup.service. Lors du démarrage, systemd provoque un timeout sur rfkill.service et merdoie sur hostapd.service (là, ce n'est pas un timeout, mais des lancements de hostapd en boucle parce que wlan0 n'existe pas). Une idée pour corriger la chose, parce que je ne comprends pas trop. Bien cordialement, JKB
