Re: [systemd-devel] Setting up a VPN daemon as a Portable Service

[David Anderson]

Yeah, so far we (tailscale) haven't found a good way to run on the Steam Deck 
at bootup, and also survive the A/B OS updates. Systemd system extensions _can_ 
be activated during bootup, if you place the extension in one of the well-known 
locations (/var/lib/extensions would be the one to use on Deck, as iirc it 
survives A/B upgrades), and the systemd-sysext service is enabled.

I would check if systemd-sysext.service is enabled on the deck, and if not, 
file a request with Valve to enable that service in a future update. You should 
present it as enabling further customization of their platform.

Another possible reason that sysexts aren't working for you, is that the Deck's 
/etc/os-release doesn't define a SYSEXT_LEVEL, and the VERSION_ID changes with 
every OS update. Because of this, the system extension will refuse to activate 
after every update (either SYSEXT_LEVEL or VERSION_ID must match exactly), 
until you rebuild a new image with the right OS metadata. Asking Valve to set 
SYSEXT_LEVEL to a stable value would make it even easier to provide Deck OS 
extensions reliably :)

- Dave

On Thu, Oct 6, 2022, at 12:08, Arian van Putten wrote:
> Afaik Portable services run in an isolated root and dont have access to the 
> hosts rootfs.  You'd have go include iptables and all its dependencies in the 
> portable services directory. If you don't want to do that you'd have to use 
> BindReadOnlyPaths= to give the service access to the required host paths or 
> you'd have to use a system extension.
> 
> That's probably why they advice running as a system extension. 
> 
> I think there are mechanisms for setting up system extensions on startup but 
> I'm not familiar enough with the details. Maybe someone else in the list 
> knows.
> 
> 
> 
> 
> On Thu, 6 Oct 2022, 20:21 Duncan Gibson,  wrote:
>> Hi, everyone.
>> 
>> The high-level overview: I'm trying to install Tailscale 
>>  as a portable service on my Steam Deck. 
>> 
>> Tailscale is a point-to-point VPN service, essentially a wrapper around 
>> Wireguard that helps with network setup and management. The Steam Deck is 
>> Valve's handheld PC running SteamOS 3, which is derived from Arch. It uses 
>> an A/B partition system for system files, meaning you can't install a 
>> service the normal way.
>> 
>> There *is* a guide to do this , 
>> posted on their own blog, but it uses system extensions which aren't good 
>> for services that you want to run on startup. Indeed, following that guide 
>> puts me in a state where I have to manually start the daemon every time I 
>> reboot my Deck, even with the service enabled.
>> 
>> Let's move on to how I've started to do this.
>> 
>> Tailscale is available through most package managers, but they also publish 
>> static binaries with systemd unit files 
>> . 
>> 
>> This script grabs that binary, extracts it, and moves it into a portable 
>> service directory structure.
>> 
>> # download and extract Tailscale
>> tarball="$(curl -s 'https://pkgs.tailscale.com/stable/?mode=json' | jq -r 
>> .Tarballs.amd64)"
>> version="$(echo ${tarball} | cut -d_ -f2)"
>> tar_dir="$(echo ${tarball} | cut -d. -f1-3)"
>> curl -s "https://pkgs.tailscale.com/stable/${tarball}; -o tailscale.tgz
>> tar xzf tailscale.tgz
>> test -d $tar_dir
>> 
>> # Set up our target directory structure
>> mkdir -p 
>> tailscaled/{usr/{bin,sbin,lib/systemd/system},etc,proc,sys,dev,run,/var/tmp}
>> 
>> # Copy tailscale-distributed files to the right place
>> cp -rf $tar_dir/tailscaled tailscaled/usr/sbin/tailscaled
>> cp -rf $tar_dir/systemd/tailscaled.service 
>> tailscaled/usr/lib/systemd/system/tailscaled.service
>> 
>> # Write service os-release file
>> source /etc/os-release
>> cp -rf /etc/os-release tailscaled/etc/os-release
>> 
>> Not automated yet is patching the provided unit file - you need to remove 
>> the EnvironmentFile line and "--port $PORT $FLAGS" options, and add 
>> [Exec]
>> Environment="PATH=/usr/bin"
>> 
>> Attach the portable service: sudo portablectl attach ./tailscaled 
>> --profile=trusted
>> and try starting it: sudo systemctl start tailscaled
>> 
>> It fails, leaving this in the logs:
>> 
>> `logtail started `
>> `Program starting: v1.30.2-t24c524c78-gc399ae6fa, Go 1.19.1-tsb13188dd36: 
>> []string{"/usr/sbin/tailscaled", 
>> "--state=/var/lib/tailscale/tailscaled.state", 
>> "--socket=/run/tailscale/tailscaled.sock"} `
>> `LogID: 0f59ed267a2b19cc28aac9ee7119914000ca478234af8d56893a025ae72cc647 `
>> `logpolicy: using $STATE_DIRECTORY, "/var/lib/tailscale" `
>> `wgengine.NewUserspaceEngine(tun "tailscale0") ... `
>> `wgengine.NewUserspaceEngine(tun "tailscale0") error: creating router: could 
>> not get iptables version: fork/exec /usr/bin/iptables: no such file or 
>> directory flushing log. `
>> `logger closing down `
>> `createEngine: creating router: could not get iptables version: fork/exec 
>> /usr/bin/iptables: no 

[systemd-devel] systemd prerelease 252-rc1

[systemd tag bot]

A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the 
tarball here:

https://github.com/systemd/systemd/archive/v252-rc1.tar.gz

NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:

https://github.com/systemd/systemd/issues/new?template=Bug_report.md

Changes since the previous release:

Announcement of Future Feature Removal:

* Please note that we intend to remove cgroupsv1 support from systemd
  release after EOY 2023. If you run services that make explicit use of
  cgroupsv1 features, please implement compatibility with cgroupsv2
  sooner rather than later, if you haven't done so yet. Most of Linux
  userspace has been ported over already.

* Please note that we intend to remove support for split-usr and
  unmerged-usr. This will happen in the second half of 2023, in the
  first release that falls into that time window. For more details, see:
  
https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html

Compatibility Breaks:

* ConditionKernelVersion= checks that use the = or != operator will now
  do simple string compares (as opposed to version compare – á la
  stverscmp() — as before, which is still done for the ordering
  operators <, >, <=, >=). Moreover, if no operator is specified a
  shell-style glob match is now done. This creates a minor
  incompatibility compared to older systemd versions, in case the *, ?,
  [, ], characters have been used in such condition expressions before,
  as these will now match per shell glob rules instead of
  literally. Given that kernel version strings typically do not include
  these characters we expect little breakage through this change.

New Features:

* systemd-measure is a new helper to precalculate PCR measurements
  to make it easier to set TPM2 policies.

Changes in systemd itself, i.e. the manager, and units

* The cpu controller is delegated to user manager units, and CPUWeight=
  settings are applied to the top-level user slice units (app.slice,
  background.slice, session.slice). This provides a degree of resource
  isolation between different user services competing for the CPU.

* Systemd can optionally do a full preset in the "first boot" condition
  (instead of just enable-only). This behaviour is controlled by the
  compile-time option -Dfirst-boot-full-preset=. Right now it defaults
  to 'false', but the plan is to switch it to 'true' for the subsequent
  release.

* Systemd will set the taint flag 'support-ended' if it detects that
  the os image is past its end-of-support date.

* Two new settings ConditionCredential= and AssertCredential= can
  be used to skip or fail units if a certain credential is not provided.

* ConditionMemory= accepts size suffixes.

* DefaultSmackProcessLabel= can be used in system.conf and user.conf
  to specify the smack label to use when not specified in a unit file.

* DefaultDeviceTimeoutSec= can be used system.conf and user.conf
  to specify the default timeout for devices.

* C.UTF-8 is used as the default locale if nothing else has been 
configured.

* Extend [Condition|Assert]Firmware= to conditionalize on certain SMBIOS
  fields. For example
  ConditionFirmware=smbios-field(board_name = "Custom Board") will
  conditionalize a unit so that it is only run when
  /sys/class/dmi/id/board_name contains "Custom Board" (without quotes).

* ConditionFirstBoot= now correctly evaluates as true only during the
  boot phase of the first boot. A unit re-ran later, after booting has
  completed, will no longer evaluate this condition as true.

* Socket units will now create sockets in the SELinuxContext= of the
  associated service unit, if any.

* Boot phase transitions (start initrd -> exit initrd -> boot complete
  -> shutdown) will be measured into PCR11, so that secrets can be bound
  to specific runtime phases, e.g.: a LUKS encryption key could be
  unsealed only in the initrd.

* Credentials will now also be provided to ExecStartPre= processes.

* Various units are now correctly ordered with initrd-switch-root.target
  where previously some were just (indirectly) ordered only with
  initrd-switch-root.service.

* In order to fully support the IPMI watchdog driver, which has not yet
  been ported to the new numbered device interface, /dev/watchdog0 will
  be tried first and systemd will silently fallback to /dev/watchdog if
  it is not found.

Re: [systemd-devel] Is it possible to let systemd create a listening socket and yet be able to have that socket activate nothing, at least temporarily?

[Klaus Ebbe Grue]

Hi Mantas,


Thanks for the suggestion. I will take a look at it.  When i do not want to do

  int flag=1;
  int rv=setsockopt(listen_fd,SOL_SOCKET,SO_REUSEADDR,,sizeof(flag));
the central problem will be to avoid the 1 minute delay

Cheers,
Klaus



Fra: Mantas Mikulėnas 
Sendt: 7. oktober 2022 09:51
Til: Klaus Ebbe Grue
Cc: systemd-devel@lists.freedesktop.org
Emne: Re: [systemd-devel] Is it possible to let systemd create a listening 
socket and yet be able to have that socket activate nothing, at least 
temporarily?


You don't often get email from graw...@gmail.com. Learn why this is 
important

On Fri, Oct 7, 2022 at 10:24 AM Klaus Ebbe Grue 
mailto:g...@di.ku.dk>> wrote:

Hi systemd-devel,

I have a user question which I take the liberty to send here since "about 
systemd-devel" says "... it's also OK to direct user questions to this mailing 
list ...".

I have a daemon, /usr/bin/mydaemon, which listens on one and only one TCP port, 
say , and which does no more than communicating over  and creating, 
reading, writing and deleting files in /home/me/mydaemon/.

Mydaemon leaves it to systemd to create a socket which listens at .

It is unimportant whether or not mydaemon is started at boot and it is also 
unimportant whether or not mydaemon is socket activated. As long as it is at 
least one of the two.

Now I want to upgrade mydaemon to a new version using a script, without race 
conditions and without closing the listening socket. I want the listening 
socket to stay open since otherwise there can be a one minute interval during 
which it is impossible to reopen .

If it is just a clean upgrade, the script could replace /usr/bin/mydaemon, then 
stop mydaemon. If the daemon is socket activated there is no more to do. If the 
daemon is activated only on boot then the script must end up restarting 
mydaemon.

But now I want to do some more while mydaemon is not running. It could be that 
my script should take a backup of /home/me/mydaemon/ in case things go wrong. 
It could be the script should translate some file in /home/me/mydaemon/ to some 
new format required by the new mydaemon or whatever.

So I need to stop mydaemon in such a way that mydaemon cannot wake up while my 
script fiddles with /home/me/mydaemon/.

Deploy the new version of your daemon to another location 
(/home/me/mydaemon.new/), perform all processing/conversions that are 
necessary, *then* stop the socket, `mv mydaemon mydaemon.old`, stop the 
service, `mv mydaemon.new mydaemon`, start the socket again. The interval for 
this will be more like half a second than a minute.

--
Mantas Mikulėnas

Re: [systemd-devel] Is it possible to let systemd create a listening socket and yet be able to have that socket activate nothing, at least temporarily?

[Klaus Ebbe Grue]

Hi Michael,


> Unfortunately not. You'd need some kind of "maintenance" mode ...

Thanks a lot. I will go with the maintenance mode without fearing to have 
missed some systemd feature.

Cheers,
Klaus

Re: [systemd-devel] Is it possible to let systemd create a listening socket and yet be able to have that socket activate nothing, at least temporarily?

[Mantas Mikulėnas]

On Fri, Oct 7, 2022 at 10:24 AM Klaus Ebbe Grue  wrote:

> Hi systemd-devel,
>
> I have a user question which I take the liberty to send here since "about
> systemd-devel" says "... it's also OK to direct user questions to this
> mailing list ...".
>
> I have a daemon, /usr/bin/mydaemon, which listens on one and only one TCP
> port, say , and which does no more than communicating over  and
> creating, reading, writing and deleting files in /home/me/mydaemon/.
>
> Mydaemon leaves it to systemd to create a socket which listens at .
>
> It is unimportant whether or not mydaemon is started at boot and it is
> also unimportant whether or not mydaemon is socket activated. As long as it
> is at least one of the two.
>
> Now I want to upgrade mydaemon to a new version using a script, without
> race conditions and without closing the listening socket. I want the
> listening socket to stay open since otherwise there can be a one minute
> interval during which it is impossible to reopen .
>
> If it is just a clean upgrade, the script could replace /usr/bin/mydaemon,
> then stop mydaemon. If the daemon is socket activated there is no more to
> do. If the daemon is activated only on boot then the script must end up
> restarting mydaemon.
>
> But now I want to do some more while mydaemon is not running. It could be
> that my script should take a backup of /home/me/mydaemon/ in case things go
> wrong. It could be the script should translate some file in
> /home/me/mydaemon/ to some new format required by the new mydaemon or
> whatever.
>
> So I need to stop mydaemon in such a way that mydaemon cannot wake up
> while my script fiddles with /home/me/mydaemon/.
>

Deploy the new version of your daemon to another location
(/home/me/mydaemon.new/), perform all processing/conversions that are
necessary, *then* stop the socket, `mv mydaemon mydaemon.old`, stop the
service, `mv mydaemon.new mydaemon`, start the socket again. The interval
for this will be more like half a second than a minute.

-- 
Mantas Mikulėnas

Re: [systemd-devel] Is it possible to let systemd create a listening socket and yet be able to have that socket activate nothing, at least temporarily?

[Michael Biebl]

Am Fr., 7. Okt. 2022 um 09:24 Uhr schrieb Klaus Ebbe Grue :
> QUESTION: Is it possible to let systemd create a listening socket and yet be 
> able to have that socket activate nothing, at least temporarily?

Unfortunately not. You'd need some kind of "maintenance" mode you
could put a service in, where systemd would keep the socket open but
just queues the requests until the service is put out of maintenance
mode again. There is no such feature atm although I would have found
that useful for Debian as well (during package upgrades).
The best you can currently do is probably to stop the .socket to avoid
accidental activation during the upgrade.

[systemd-devel] Is it possible to let systemd create a listening socket and yet be able to have that socket activate nothing, at least temporarily?

[Klaus Ebbe Grue]

Hi systemd-devel,

I have a user question which I take the liberty to send here since "about 
systemd-devel" says "... it's also OK to direct user questions to this mailing 
list ...".

I have a daemon, /usr/bin/mydaemon, which listens on one and only one TCP port, 
say , and which does no more than communicating over  and creating, 
reading, writing and deleting files in /home/me/mydaemon/.

Mydaemon leaves it to systemd to create a socket which listens at .

It is unimportant whether or not mydaemon is started at boot and it is also 
unimportant whether or not mydaemon is socket activated. As long as it is at 
least one of the two.

Now I want to upgrade mydaemon to a new version using a script, without race 
conditions and without closing the listening socket. I want the listening 
socket to stay open since otherwise there can be a one minute interval during 
which it is impossible to reopen .

If it is just a clean upgrade, the script could replace /usr/bin/mydaemon, then 
stop mydaemon. If the daemon is socket activated there is no more to do. If the 
daemon is activated only on boot then the script must end up restarting 
mydaemon.

But now I want to do some more while mydaemon is not running. It could be that 
my script should take a backup of /home/me/mydaemon/ in case things go wrong. 
It could be the script should translate some file in /home/me/mydaemon/ to some 
new format required by the new mydaemon or whatever.

So I need to stop mydaemon in such a way that mydaemon cannot wake up while my 
script fiddles with /home/me/mydaemon/.

According to https://0pointer.de/blog/projects/three-levels-of-off it seems 
that that was possible in 2011: just do "systemctl disable mydaemon.service". 
But when I try that, mydaemon still wakes up if I connect to  using eg 
netcat.

I have also tried to mask mydaemon. But if I then connect to  using netcat, 
then netcat gets kicked of. And if I try again then  is no longer listening.

QUESTION: Is it possible to let systemd create a listening socket and yet be 
able to have that socket activate nothing, at least temporarily?

Cheers,
Klaus