layer: Add Raspberry Pi Connect

[learmj]

Two new layers added to enable installation of Raspberry Pi Connect (with or without screen-sharing), plus auth token keyfile support. Whether or not the client starts at boot is controlled via a config variable which defaults to on (since embedded/industrial deployments will typically want Connect to start automatically at boot).

[learmj]

fyi @tdewey-rpi @mudge

[tdewey-rpi]

LGTM. I assume we'll add another example os-target that includes one of these layers at a later point?

[learmj]

LGTM. I assume we'll add another example os-target that includes one of these layers at a later point?

We are very light on example configs but it's intentional as we deliberately don't want to say 'here's one that everybody must use'. Connect can be included in the build like this:

layer:
  foo: rpi-connect
  ...

...or by adding rpi-connect (or rpi-connect-lite) as a dependency (via X-Env-Layer-Requires).

Supplying the auth token keyfile is a customisation step that should hopefully be self-explanatory, but I wondered if I should add something to each layer's X-Env-Var-authkey-Desc. What do you think? Maybe a short "Generated via Raspberry Pi Connect Account Settings"...?

[pelwell]

This works for me. The auth.key support is the only part I would question - is the idea that one would pass IGconf_connect_authkey on the rpi-image-gen command line?

[learmj]

This works for me. The auth.key support is the only part I would question - is the idea that one would pass IGconf_connect_authkey on the rpi-image-gen command line?

Either cmdline or via a config variable would work, eg

connect:
   authkey: /path/to/file

I would imagine it's better suited being driven via the environment when held in an env variable, eg

rpi-image-gen build <args> -- IGconf_connect_authkey=$KEYFILE

...or maybe in a variable referenced by the config file, eg:

connect:
  authkey: $KEYFILE

All of those schemes will work.

It's possible to define any variable via the config system (including auto-generating the file via custom means), so if a user had their own section (acme) they could have their static base.yaml, then include that from an auto-generated file which reads an env var holding the path to the token keyfile, eg:

include:
  file: base.yaml
connect:
   authkey: $PICONNECT_AUTHKEYFILE

...then run env PICPONNECT_KEYFILE=/path/to/auth.token rpi-image-gen build <args>

[mudge]

As the rpi-connect-signin.service is WantedBy rpi-connect.service, should this be in .config/systemd/user/rpi-connect.service.wants (which is where systemctl --user enable rpi-connect-signin.service puts it)?

Suggested change

	- uchroot "$1" 'ln -sf /usr/lib/systemd/user/rpi-connect-signin.service ${HOME}/.config/systemd/user/default.target.wants/rpi-connect-signin.service'
	- uchroot "$1" 'mkdir -p ${HOME}/.config/systemd/user/rpi-connect.service.wants'
	- uchroot "$1" 'ln -sf /usr/lib/systemd/user/rpi-connect-signin.service ${HOME}/.config/systemd/user/rpi-connect.service.wants/rpi-connect-signin.service'

[mudge]

As above re being in .config/systemd/user/rpi-connect.service.wants rather than .config/systemd/user/default.target.wants.

[mudge]

As above re being in .config/systemd/user/rpi-connect.service.wants rather than .config/systemd/user/default.target.wants.

[learmj]

Updated because:

• The enabling of systemd units wasn't quite right, so these have been corrected.
• It's probably helpful if IGconf_connect_authkey supported holding the key as a file path or as a value, so support has been added for that.
• Companion doc added to provide additional information.

fyi @clowder

[pelwell]

Think about this a bit more, the auth.key mechanism is not a great fit for AB images where the Pi Connect state lives in the system partitions. It works in the A partition, but when we switch to the B partition, either:
a. the auth key has already been used, in which case we are unable to translate it to an rpdev_ key, or
b. it's a brand new auth key, in which case I don't know what happens: does it look like a new device, or is the old key forgotten?

[tdewey-rpi]

Think about this a bit more, the auth.key mechanism is not a great fit for AB images where the Pi Connect state lives in the system partitions. It works in the A partition, but when we switch to the B partition, either: a. the auth key has already been used, in which case we are unable to translate it to an rpdev_ key, or b. it's a brand new auth key, in which case I don't know what happens: does it look like a new device, or is the old key forgotten?

Isn't the straightforward option to ensure we insert into /data, and don't package /data for an OTA?

[learmj]

Connect stores its assets in a location that keys off XDG_CONFIG_HOME or HOME. If, for example, we had the big persistent partition (retained across rotations) mounted on /var and we had /home bind mounted to /var/home, anything that stored assets in /home would have those assets retained across rotations. If we don't package /home for OTA, this would allow apps to have their configuration space preserved irrespective of what slot we're running from. I think that's what we want.

[pelwell]

Think about this a bit more, the auth.key mechanism is not a great fit for AB images where the Pi Connect state lives in the system partitions. It works in the A partition, but when we switch to the B partition, either: a. the auth key has already been used, in which case we are unable to translate it to an rpdev_ key, or b. it's a brand new auth key, in which case I don't know what happens: does it look like a new device, or is the old key forgotten?

Isn't the straightforward option to ensure we insert into /data, and don't package /data for an OTA?

Yes, hence "not a great fit for AB images where the Pi Connect state lives in the system partitions".

[clowder]

Really excited to get this integration merged! Tested this locally and worked well for remote shell.

Optional, it might be nice to make it clearer to folks following the quick start guide that they should use rpi-connect-lite; given there's no desktop on the minbase images.

[learmj]

Sorry for the churn on this. I updated it again because:

• Enabling Connect for auto start up should not be gated by user lingering, but rather by the presence of the Connect systemd unit symlinks. This makes it more in line with how rpi-connect on/off works if running interactively. User lingering is now always enabled regardless of the value of IGconf_connect_on.
• I wanted to add some more information to the companion doc (thanks Chris).

I don't anticipate any more changes. Functionally, things work exactly as they did before.

I'll merge this at the end of the day unless there are any objections.