'Terminal unknown' in systemd unit met network namespace

[Borromini]

Ik heb een network namespace opgezet, die wordt bij opstart automatisch aangemaakt via een aparte systemd unit. Dat werkt netjes. De bedoeling is dat de programma's die in die namespace dienen te draaien
via aparte units worden opgestart. Als ik het commando zelf rechtstreeks in mijn terminal uitvoer werkt het perfect, maar als ik de aparte systemd unit datzelfde commando laat uitvoeren klaagt systemd over een ongedefinieerde terminal. En ik kom er maar niet uit

Systemd unit:

code:

After=namespace@%i.service
BindsTo=namespace@%i.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=ip netns exec namespace sudo -E -u #1000 -g #1000 rtorrent -o import=/home/anon/.rtorrent.rc
WorkingDirectory=/home/anon

[Install]
WantedBy=multi-user.target
WantedBy=network-online.target

Log:

jul 24 23:39:19 amalthea sudo[2092460]:     root : PWD=/home/anon ; USER=anon ; GROUP=anon ; COMMAND=/usr/bin/rtorrent -o import=/home/anon/.rtorrent.rc
jul 24 23:39:19 amalthea sudo[2092460]: pam_unix(sudo:session): session opened for user anon(uid=1000) by (uid=0)
jul 24 23:39:19 amalthea ip[2092461]: Error opening terminal: unknown.
jul 24 23:39:19 amalthea sudo[2092460]: pam_unix(sudo:session): session closed for user anon
jul 24 23:39:19 amalthea systemd[1]: [e-mail]: Main process exited, code=exited, status=1/FAILURE

Relevante software en hardware die ik gebruik: Debian Bullseye pre-release.

Wat ik al gevonden of geprobeerd heb: TERM-variabele definiëren, maar dan klaagt systemd weer:

code:

ExecStart=TERM\=xterm ip netns exec namespace sudo -E -u #1000 -g #1000 rtorrent -o import=/home/anon/.rtorrent.rc

Foutmelding:

jul 24 23:29:55 amalthea systemd[1]: /etc/systemd/user/[e-mail]:13: Ignoring unknown escape sequences: "TERM\=xterm"
jul 24 23:29:55 amalthea systemd[1]: /etc/systemd/user/[e-mail]:13: Executable name contains special characters: TERM\=xterm

[Thralas]

Heb je al gekeken naar JoinsNetworkNamespaceOf en friends (zie systemd.unit)? Users en groups kun je dan zetten met User/Group.

Dat is een stuk eleganter dan sudo/ip. Environment variables kun je ook zetten met een aparte directive.

[Borromini]

Daar had ik nog niet naar gekeken, bedankt. Ik heb de unit file aangepast. Systemd manual heeft het ook over PrivateNetwork=, maar als ik dat in de namespace unit activeer, dan is de namespace nutteloos - dan werkt de VPN-tunnel daarin niet meer. De documentatie heeft het ook over alleen de loopback interface die in zo'n namespace wordt geactiveerd, maar ik zie online wel andere mensen blijkbaar met succes beide combineren... (JoinsNetworkNameSpaceOf vind ik zelf trouwens niet, wel JoinsNameSpaceOf.)

Ik heb in de manual ook NetworkNamespacePath= gevonden als alternatief, maar dat doet niks hier, dan klaagt systemd dat ie 't niet herkent:

jul 25 11:17:15 amalthea systemd[1]: /etc/systemd/user/[e-mail]:13: Unknown key name 'NetworkNamespacePath' in section 'Unit', ignoring.

Unit ziet er dan zo uit:

code:

[Unit]
After=namespace@%i.service
BindsTo=namespace@%i.service
JoinsNamespaceOf=namespace@%i.service
NetworkNamespacePath=/var/run/netns/%i

[Service]
Type=oneshot
RemainAfterExit=yes
User=anon
ExecStart=/usr/bin/tmux -L rtorrent new-session -d -s %u -n 'rtorrent' 'rtorrent'
WorkingDirectory=/home/anon

[Install]
WantedBy=multi-user.target
WantedBy=network-online.target

De unit start wel nog rtorrent op, maar die is gewoon te zien in de standaard namespace en luistert op het LAN-IP, niet op het adres van de VPN-tunnel. Als ik in de namespace pgrep rtorrent uitvoer dan krijg ik daar vreemd genoeg *ook* een PID terug. Maar netstat (in de standaard namespace) toont duidelijk dat rtorrent op het LAN-IP luistert, dus in de standaard namespace.

Namespace unit:

code:

[Service]
Type=oneshot
RemainAfterExit=yes

ExecStartPre=-/bin/ip netns delete %I

ExecStart=/bin/ip netns add %I
ExecStart=/bin/ip link add wg0 type wireguard
ExecStart=/usr/bin/wg setconf wg0 /etc/wireguard/wg0.conf
ExecStart=/bin/ip link set wg0 netns %I
ExecStart=/bin/ip -n %I addr add $IPv4/32 dev wg0
ExecStart=/bin/ip -n %I addr add $IPv6/128 dev wg0
ExecStart=/bin/ip -n %I link set wg0 up
ExecStart=/bin/ip -n %I route add default dev wg0

# Kill namespace when stopped
ExecStop=/bin/ip netns delete %I

[Install]
WantedBy=multi-user.target
WantedBy=network-online.target

[ Voor 21% gewijzigd door Borromini op 25-07-2021 11:38 ]

[Thralas]

Borromini schreef op zondag 25 juli 2021 @ 11:28:
Daar had ik nog niet naar gekeken, bedankt. Ik heb de unit file aangepast. Systemd manual heeft het ook over PrivateNetwork=, maar als ik dat in de namespace unit activeer, dan is de namespace nutteloos

Volgens mij is de truuk om de namespace unit file aan te maken met PrivateNetwork=. Zoals dit voorbeeld.

Dan heb je namelijk iets bruikbaars voor JoinsNamespaceOf - voor alles dat direct in de namespace kan, zoals je torrent client.

Je VPN client kan dat inderdaad niet gebruiken omdat die ook buiten de namespace moet communiceren, maar die kan zelf de namespace joinen (bijvoorbeeld met een up-script in OpenVPN).

(JoinsNetworkNameSpaceOf vind ik zelf trouwens niet, wel JoinsNameSpaceOf.)

Mea culpa, de naming is soms wat verwarrend.

Ik heb in de manual ook NetworkNamespacePath= gevonden als alternatief, maar dat doet niks hier, dan klaagt systemd dat ie 't niet herkent:

Zal dan te nieuw zijn.

Als ik in de namespace pgrep rtorrent uitvoer dan krijg ik daar vreemd genoeg *ook* een PID terug.

Processen zijn ook niet gescheiden als je enkel een network namespace aanmaakt. Daarvoor is de pid namespace.

[Borromini]

Thralas schreef op zondag 25 juli 2021 @ 11:48:
[...]

Volgens mij is de truuk om de namespace unit file aan te maken met PrivateNetwork=. Zoals dit voorbeeld.

Dan heb je namelijk iets bruikbaars voor JoinsNamespaceOf - voor alles dat direct in de namespace kan, zoals je torrent client.

Je VPN client kan dat inderdaad niet gebruiken omdat die ook buiten de namespace moet communiceren, maar die kan zelf de namespace joinen (bijvoorbeeld met een up-script in OpenVPN).

OK, dus als ik het goed begrijp: aparte unit voor de namespace dan, en dan nog één voor de VPN-tunnel die daarop voortbouwt? En dan pas de rtorrent unit? Want dan ga ik de namespace & VPN uitsplitsen (en PrivateNetwork=yes opnieuw proberen, dat breekt nu alles).

Processen zijn ook niet gescheiden als je enkel een network namespace aanmaakt. Daarvoor is de pid namespace.

OK, dat het hier alleen een network namespace betreft, dat snap ik. Alleen leek ik eerder bv. geen PID netwerkverbindingen van rtorrent te kunnen oproepen in de default (network) namespace en moest ik dat ook via ip netns exec namespace doen. Dus da's wel wat vreemd dan.

Ik ga es zien wat het uitsplitsen geeft . Bedankt alvast!

[Thralas]

Borromini schreef op zondag 25 juli 2021 @ 11:58:
OK, dus als ik het goed begrijp: aparte unit voor de namespace dan, en dan nog één voor de VPN-tunnel die daarop voortbouwt? En dan pas de rtorrent unit? Want dan ga ik de namespace & VPN uitsplitsen (en PrivateNetwork=yes opnieuw proberen, dat breekt nu alles).

Ik zie nu dat je WireGuard gebruikt en dat al in je namespace unit had zitten.

Je zei ook dat NetworkNamespacePath niet werkt, maar zo te zien is het probleem dat deze onder Service thuishoort (ipv. Unit).

Als die directive werkt, kun je PrivateNetwork achterwege laten in de namespace unit - omdat je hem daar met ip netns aanmaakt kun je er vervolgens naar refereren met NetworkNamespacePath=/var/run/netns/NAMESPACE in je rtorrent unit file.

Volgens mij ben je er dan, met 1 unit voor je namespace/wireguard en 1 unit zonder sudo/ip hacks voor iedere service in die namespace.

OK, dat het hier alleen een network namespace betreft, dat snap ik. Alleen leek ik eerder bv. geen PID netwerkverbindingen van rtorrent te kunnen oproepen in de default (network) namespace en moest ik dat ook via ip netns exec namespace doen. Dus da's wel wat vreemd dan.

Dat is toch exact het idee van een network namespace..?

[Borromini]

Thralas schreef op zondag 25 juli 2021 @ 13:54:
[...]


Ik zie nu dat je WireGuard gebruikt en dat al in je namespace unit had zitten.

Je zei ook dat NetworkNamespacePath niet werkt, maar zo te zien is het probleem dat deze onder Service thuishoort (ipv. Unit).

Daar heb je gelijk in, ik had die directive hier gehaald en helemaal op het einde van dat topic werd dan gezegd dat die onder Service moet .

Als die directive werkt, kun je PrivateNetwork achterwege laten in de namespace unit - omdat je hem daar met ip netns aanmaakt kun je er vervolgens naar refereren met NetworkNamespacePath=/var/run/netns/NAMESPACE in je rtorrent unit file.

Volgens mij ben je er dan, met 1 unit voor je namespace/wireguard en 1 unit zonder sudo/ip hacks voor iedere service in die namespace.

Dat klopt, dat werkt netjes. Bedankt!

Dat is toch exact het idee van een network namespace..?

Klopt, maar het vage was dat, als de rtorrent unit opstartte de netwerkverbindingen ook in de default namespace zichtbaar waren, en niet alleen in de VPN namespace, dus daar ging nog steeds iets mis. Maar dat is nu dus niet meer het geval .