Confusion about systemd

[thk686]

The docs say:

systemd-config — Comma-separated list of type:file, where type is one of login, network, resolve, system, timesync, or user. Copies the provided file to /etc/systemd/type.conf.d

I don't see /etc/systemd/type.conf.d on the installed system. Perhaps raspberry pi os does this differently now? What I see are .service files under /lib/systemd/ and symlinks to /etc/systemd/.

This fails:

system:"name=s1|systemd-config=<path omitted>/remove-ssh-success.service"

with

> Run Plugin 'system' (/mnt/sdm/usr/local/sdm/plugins/system) Phase 0 with arguments: 
  'name=s1|systemd-config=/home/agent/hostdir/biosense-config-files/remove-ssh-success.service'
* Plugin system: Start Phase 0
> Plugin system: Keys/values found:
   name: s1
   systemd-config: /home/agent/hostdir/biosense-config-files/remove-ssh-success.service
> Plugin system: Create directory /mnt/sdm/etc/sdm/assets/system-s1
? Plugin system: systemd-config item 
  '/home/agent/hostdir/biosense-config-files/remove-ssh-success.service' is unknown
? Plugin 'system' exited with failure status '1'

[gitbls]

The ".d" directories are not present by default in Debian or RasPiOS. However, they are documented. (see, for instance, man systemd-system.conf and man journald.conf, among others)

sdm creates the ".d" directory during the system plugin post-install phase.

The documentation is correct. For instance:

--plugin system:"systemd-config=timesync=/path/to/timesync.conf,journal=/path/to/journal.conf"

is a comma-separated list of type:file, where type is one of login, network, resolve, system, timesync, etc.

There is NO mention of a "type" called type. Why are you looking for one?

And, as I mentioned in https://github.com/gitbls/sdm/issues/223#issuecomment-2184213502, the file type must be ".conf", and sdm doesn't check that. Last time I looked, ".service" != ".conf".

I'm curious how you managed to equate them to be equal?

[thk686]

So a .conf file might look like:

[Unit]
Description=Generate WireGuard keys if not present
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/wg-keygen.sh
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

[gitbls]

So a .conf file might look like:

[Unit]
Description=Generate WireGuard keys if not present
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/wg-keygen.sh
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

That is a config file for a systemd SERVICE. There is no special support in the sdm system plugin for this.

Perhaps you could explain what you're trying to accomplish, and I can tell you the best way to accomplish it?

[thk686]

Ah, ok. I can do this in my custom plugin. I'm not familiar with systemd and don't know what a conf file is or accomplishes.

I am booting remote devices. They are programmed to repeatedly try to ssh to my server. Once they are successful in uploading their public wireguard key, they will remove a temporary ssh private key as all future communication will be initiated from the server.

[gitbls]

Yes, if you have a custom plugin you can create /etc/systemd/system/*.service files. Personally, I think that's the easiest way, but some people prefer to use sdm plugins (e.g., copyfile, etc) rather than writing their own plugin.

sdm lets you do it either way, of course.

The .conf files for systemd-config control the operation of the mentioned systemd services. For instance, I use a custom timesyncd.conf to set the time server on my local LAN.

[gitbls]

I am booting remote devices. They are programmed to repeatedly try to ssh to my server. Once they are successful in uploading their public wireguard key, they will remove a temporary ssh private key as all future communication will be initiated from the server.

You have probably figured this out, but just in case...another way to approach this would be to use sdm to load the public wg key into the disk for each client system, either at customize time or burn time, so that they are 100% configured when the initial system boot is done..

This would save the ssh-initiated communication and perhaps, if appropriate, simplify the initial startup of each client system.

[thk686]

Indeed, you are correct. I have not used wireguard before and was stuck in an ssh mindset. I think I will pregenerate all of the config files and use them one-by-one per client. Thanks for the insight!

On Tue, Jun 25, 2024 at 12:16 AM Benn @.***> wrote:

I am booting remote devices. They are programmed to repeatedly try to ssh to my server. Once they are successful in uploading their public wireguard key, they will remove a temporary ssh private key as all future communication will be initiated from the server.

You have probably figured this out, but just in case...another way to approach this would be to use sdm to load the public wg key into the disk for each client system, either at customize time or burn time, so that they are 100% configured when the initial system boot is done..

This would save the ssh-initiated communication and perhaps, if appropriate, simplify the initial startup of each client system.

— Reply to this email directly, view it on GitHub https://github.com/gitbls/sdm/issues/225#issuecomment-2187996268, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEQXSL57V4IL3GYFRYTDYDZJD4JTAVCNFSM6AAAAABJ2G6PCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBXHE4TMMRWHA . You are receiving this because you modified the open/close state.Message ID: @.***>

-- Timothy H. Keitt www keittlab org

[gitbls]

Indeed, you are correct. I have not used wireguard before and was stuck in an ssh mindset. I think I will pregenerate all of the config files and use them one-by-one per client. Thanks for the insight!

Now you're thinking sdm-style!

For my LAN i have a tree set up with a directory-per-host for server-type systems. There's a little wrapper script that picks up the correct files (host-specific stuff) when I burn, doing the per-host specific customization at burn-time. This is stuff like my VPN server, DNS/DHCP servers, etc.

The IMG that they use is my standard "workstation" config that is my workstation/test system/etc which is fully configured so that when it boots everything (everything installed, all software that I want to be running is running, etc).