Questions and notes installing on a DietPi

[bluemistP]

I use DietPi as my server and as expected some of the services are already duplicated from the things I install within DietPi.

I saw your warning about lighttpd possibly replacing existing HTTP server setups, but how does it apply for the other services? I'm almost afraid to try installing Samba because I already have it running the DietPi way, and I already configured CIFS share for the MiSTer, so those would seem to be redundant in my setup.

I would like however to take advantage of your concept about symbolic links and possibly supporting multiple kinds of structures for other retro systems, but for now I don't have a multiple-use case yet outside of MiSTer.

For now, I'm checking your Check Services menu to see if retronas detects the services that DietPi already configured. Seems to work out fine, except for Syncthing.

systemctl --no-pager --full status syncthing@dietpi
Unit syncthing@dietpi.service could not be found.

Not sure why @ is needed in this case, but I'm able to ping my Syncthing using this, so please consider changing your script if possible.

systemctl --no-pager --full status syncthing

As a status report, I have the following existing services in DietPi that were correctly detected:
Samba
lighttpd
OpenSSH

And the following I installed from retronas without conflicts/issues under DietPi:
Cockpit
Webone

Sorry for a lot of ramble, but hope this is useful in any way.

[sairuk]

I expect this would arguably be resolved once the project moves to targeting additional platforms other than Debian 11 see https://github.com/danmons/retronas/blob/main/IDEAS.md

The Debian package installs the syncthing unit as an instance signified by the @ symbol.

An instance is useful when you need data passed (in this case User is a var in the unit file) to a unit where you may be looking to run multiple instances of that unit. The instance inherits the name of the data passed to it to create a unique/dedicated name in this case syncthing@dietpi

From your post it appears dietpi runs from a static systemd service file i.e not an instance and as such when checking for the instance RetroNAS does not find the dietpi service since RetroNAS looks for the instance naming of syncthing@user.service

https://github.com/danmons/retronas/blob/8553ee22aa2567553f49d472510c067f60b4dd79/dialog/services.sh#L130

There may be a better way to do service detection so it is platform agnostic, need to have a think about that.

Also looking at the implementation I don't think the current syncthing implementation is functional as an instance anyway due to the hardcoded gui port in ansible, From the syncthing doco an alt listen port will be chosen if the default 8384 is taken at time of installation so coming through after the fact and forcing the gui port should mean its effectiveness as an instance is negated

https://github.com/danmons/retronas/blob/9325f5654185f9935379e8999cd8caa989a8d271/ansible/install_syncthing.yml#L38

somethings well worth looking into.

[sairuk]

This was related to a bug fixed in commit retronas/retronas@fe8f0a2

I have an sdcard with dietpi on it now and syncthing now installs as is run as the correct user and can be queried with the status menu.

@bluemistP can you please update your installation and confirm.

systemctl --no-pager --full status syncthing@dietpi

● syncthing@dietpi.service - Syncthing - Open Source Continuous File Synchronization for dietpi
     Loaded: loaded (/lib/systemd/system/syncthing@.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2022-02-08 07:44:16 GMT; 1min 29s ago
       Docs: man:syncthing(1)
   Main PID: 10183 (syncthing)
      Tasks: 18 (limit: 4532)
        CPU: 2.611s
     CGroup: /system.slice/system-syncthing.slice/syncthing@dietpi.service
             ├─10183 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0 --gui-address=0.0.0.0:8384
             └─10192 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0 --gui-address=0.0.0.0:8384

Feb 08 07:44:17 DietPi syncthing[10183]: [S6SY2] INFO: Creating new HTTPS certificate
Feb 08 07:44:17 DietPi syncthing[10183]: [S6SY2] INFO: QUIC listener ([::]:22000) starting
Feb 08 07:44:17 DietPi syncthing[10183]: [S6SY2] INFO: Ready to synchronize "Default Folder" (default) (sendreceive)
Feb 08 07:44:17 DietPi syncthing[10183]: [S6SY2] INFO: Completed initial scan of sendreceive folder "Default Folder" (default)
Feb 08 07:44:17 DietPi syncthing[10183]: [S6SY2] INFO: GUI and API listening on [::]:8384
Feb 08 07:44:17 DietPi syncthing[10183]: [S6SY2] INFO: Access the GUI via the following URL: http://127.0.0.1:8384/
Feb 08 07:44:17 DietPi syncthing[10183]: [S6SY2] INFO: My name is "DietPi"
Feb 08 07:44:31 DietPi syncthing[10183]: [S6SY2] INFO: Detected 1 NAT service
Feb 08 07:44:37 DietPi syncthing[10183]: [S6SY2] INFO: quic://0.0.0.0:22000 detected NAT type: Port restricted NAT
Feb 08 07:44:37 DietPi syncthing[10183]: [S6SY2] INFO: quic://0.0.0.0:22000 resolved external address quic://203.208.103.77:1024 (via stun.syncthing.net:3478)

Press [Enter] to continue...

[bluemistP]

Sorry @sairuk but it still does not detect.

Side question: Is this command enough to update retronas by itself? It looks like it's updating. Currently there's no indication in the wiki on how to update retronas, whether the command below is enough or if I need to run install_retronas.sh again.

sudo /opt/retronas/retronas.sh

Let me clarify my setup: I installed syncthing using the dietpi-software features, my syncthing is not installed using retronas.

Might be something related to how dietpi installs software? I'm more on end-user side so I'm not familiar about these things. In any case, this is how it looks in my dietpi machine:

dietpi@DietPi:~$ systemctl --no-pager --full status syncthing
● syncthing.service - Syncthing (DietPi)
     Loaded: loaded (/etc/systemd/system/syncthing.service; disabled; vendor preset: enabled)
     Active: active (running) since Tue 2022-02-08 20:13:15 JST; 9min ago
   Main PID: 190432 (syncthing)
      Tasks: 20 (limit: 9269)
        CPU: 32.147s
     CGroup: /system.slice/syncthing.service
             ├─190432 /opt/syncthing/syncthing -no-browser -no-restart -logflags=0 -home=/mnt/dietpi_userdata/syncthing
             └─190447 /opt/syncthing/syncthing -no-browser -no-restart -logflags=0 -home=/mnt/dietpi_userdata/syncthing

[sairuk]

I installed syncthing using the dietpi-software features

Ahh I see, yes OK that was clear the other day, sorry it must have slipped my mind, and yes our scripts will not currently handle that situation. I will leave this open and revisit the dietpi i deployed here to see if there is a simple solution.

[sairuk]

dietpi doesn't install from repo for syncthing, it pulls a tar from git which also includes the instance unit.

The dietpi project then creates a standalone systemd unit as syncthing.service which is hardcoded to the user dietpi in the file /etc/systemd/system/syncthing.service

root@DietPi:/tmp# cat /etc/systemd/system/syncthing.service 
[Unit]
Description=Syncthing (DietPi)
Wants=network-online.target
After=network-online.target
StartLimitIntervalSec=60
StartLimitBurst=4

[Service]
User=dietpi
ExecStart=/opt/syncthing/syncthing -no-browser -no-restart -logflags=0 -home=/mnt/dietpi_userdata/syncthing
Restart=on-failure
RestartSec=1
SuccessExitStatus=3 4
RestartForceExitStatus=3 4

# Hardening
ProtectSystem=full
PrivateTmp=true
SystemCallArchitectures=native
MemoryDenyWriteExecute=true
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

this is the wrong way to approach this, they should be using the packaged systemd instance as syncthing@dietpi.service and using an override file (if applicable) to handle any additional changes they want to make

The defaults are still available for review in /opt/syncthing/etc/linux-systemd/system/syncthing@.service

root@DietPi:/tmp# cat /opt/syncthing/etc/linux-systemd/system/syncthing@.service 
[Unit]
Description=Syncthing - Open Source Continuous File Synchronization for %I
Documentation=man:syncthing(1)
After=network.target
StartLimitIntervalSec=60
StartLimitBurst=4

[Service]
User=%i
ExecStart=/usr/bin/syncthing serve --no-browser --no-restart --logflags=0
Restart=on-failure
RestartSec=1
SuccessExitStatus=3 4
RestartForceExitStatus=3 4

# Hardening
ProtectSystem=full
PrivateTmp=true
SystemCallArchitectures=native
MemoryDenyWriteExecute=true
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Please speak with the upstream project and have dietpi revisit their approach, so they standardise with the syncthing project.

[sairuk]

A workaround has been added for this in the meantime, please confirm

[bluemistP]

Workaround is confirmed. Thank you.
systemctl --no-pager --full status syncthing*

[sairuk]

I'll leave this open to collect any other dietpi problems