DietPi-Software | syncplay server

[lukaszsobala]

Formal software information

• Software title | syncplay-server
• Short description | server for synchronizing playback of local video files and youtube over the Internet, with cross-platform clients and compatible with many video players
• Official URL (if available) | https://syncplay.pl
• GitHub URL (if available) | https://github.com/Syncplay/syncplay
• (Official) install documentation | https://syncplay.pl/guide/install/ this one is official, but here is an unofficial guide for Raspberry pi (works with the latest DietPi release 8.7) https://blog.cybrox.eu/posts/setup-a-proper-syncplay-server-on-ubuntu-debian/

Are there similar/alternative software titles available with DietPi-Software?

• I don't think so

How can DietPi make the installation easier or compatible, than following the install instructions or do APT installation, if available?

• the installation, update process and service creation can easily be automated!

Can you provide the installation steps that you would suggest DietPi-Software to do?

1. Make install the latest release from GitHub (or make install-server which should only install the server)
2. Set up a reserved port if the default 8999 clashes with any
3. Capture the first "salt" from stdout to later run the service with the same salt every time

Are you willing to help maintaining the software installation, e.g. in case of needed setup changes due to updates etc.? This is not needed, but could speed up our decision to implement it, as man power is always a topic 😉.

• GitHub alone seems to be good enough

[lukaszsobala]

Hello,

It's probably not going to get popular enough but I wanted to follow up with a simple way to run it as a service.

1. Install the latest server-only deb package from here: https://github.com/Syncplay/syncplay/releases
2. Create a syncplay user: useradd -r syncplay
3. Start the server once: syncplay-server. It will generate a "salt", which you might need later if you use room operator passwords. Copy it somewhere temporarily. Then kill it (Ctrl+C).
4. [optional] Create a MOTD (message of the day) file: touch /usr/lib/syncplay/motd.txt && chown syncplay:syncplay /usr/lib/syncplay/motd.txt, write what you want there.
5. Create a service file in /etc/systemd/system/syncplay.service:

[Unit]
Description=Syncplay server

[Service]
Type=simple
Restart=always
RestartSec=3
User=syncplay
ExecStart=syncplay-server --salt [paste salt here, no brackets] --motd-file /usr/lib/syncplay/motd.txt #put any other command line options you might need here

[Install]
WantedBy=multi-user.target

7. DO NOT Make it executable: chmod +x /etc/systemd/system/syncplay.service
8. Enable autostart and start the service: systemctl daemon-reload && systemctl enable syncplay && systemctl start syncplay
9. Now you can connect to it using a Syncplay client. The default port is 8999.

The other available guide is needlessly complicated, one doesn't need screen to make a simple service.

So in summary this can be easily scripted. I can help with it.

[MichaIng]

Thanks for the detailed instructions ❤️. Some hints:

2. The DEB package does neither create a user, nor a service? We have a function Create_User in dietpi-software which invokes useradd or usermod, depending on whether the user exists already, and applies some defaults (system user, /nonexistent home, /usr/sbin/nologin shell, same name group, ...), otherwise takes the same argument as the invoked commands.
3. As the package installs Syncplay as usual to /usr, /bin, etc, does it somehow use /opt/syncplay as config/data dir by default? Seems uncommon, in such cases, I'd expect /var/lib/syncplay and /etc/syncplay to be default data and config dirs. I guess /opt/syncplay is for non-packaged installs, and when compiling from source. However, if there is any chance to choose it, I'd suggest /mnt/dietpi_userdata/syncplay, to align it with other software options, to have variable data in this DietPi userdata dir which can be easily moved to an external drive.
4. As starting a process and stopping it at some point is difficult to script in a safe way (although we have a function for exactly this purpose, starting a service and stopping it once a specific file exists and optionally contains a certain string), is it possible to just manually pre-create a salt and store it to be used by Syncplay?
5. Basically if we pass the salt via command-line argument anyway, we don't need to let Syncplay create it but can manually create one from /dev/random (point 4). But actually I'd prefer to not pass such publicly visible via service file. Why is it actually possible to deal with this? Usually a salt is just automatically generated by the application and stored internally for hash generation, no need to users to know about.
6. A .service file never needs to be and should not be executable.
7. Does not need to be done in the dietpi-software code, but added to dietpi-services and passed as argument to the function which checks whether the software title shall be installed, like if To_Install 208 syncplay. It is then enabled and started automatically after all installs have finished.

screen in the guide is likely used since init.d services must be forked into background and syncplay-server seems to start a foreground process. systemd however works even best with foreground processes, so indeed no need to the screen hack there.

If someone wants to start implementing this, here further details, including some of what I mentioned above: https://github.com/MichaIng/DietPi/wiki/How-to-add-a-new-software-title

[lukaszsobala]

Hello,

Thanks for the tips!
In reality I installed syncplay by building and make installing, as I assumed the .deb wouldn't work on arm (it does). But now I installed it from the .deb file and the directories you mentioned don't exist, but the data seems to be in /usr/lib/syncplay. Most files in /usr/lib/syncplay/syncplay are owned by user 1001 from group docker (???). The deb doesn't seem to create a service right now. The executable /usr/bin/syncplay-server is a python script in which the data directory is defined.

In reality I did not end up making the service executable (indeed) but that was quite some time ago and now I was misled by the init.d script being made executable in the old tutorial. That was the first service I made so forgive the mistake.

I will probably get a dietpi VM and test how to do this on a fresh dietpi installation. As for the salt, yes it should be easily generated externally, I will check how they are doing this. Not sure how to store it internally. It can also be passed to syncplay as an environment variable SYNCPLAY_SALT, which I think would also be plain text (but not inside a .service file).

In the meantime I'll edit the previous comment to fix the more important things...

[MichaIng]

the data seems to be in /usr/lib/syncplay

This is usually used for static files only, not for variable data, configs and such.

Most files in /usr/lib/syncplay/syncplay are owned by user 1001 from group docker (???).

That is very strange indeed, especially when the package postinst script does not add a respective user. Files in this location should all be owned by root:root. A packaging bug. But can be easily fixed here: https://github.com/Syncplay/syncplay/blob/master/ci/deb-script.sh

the init.d script being made executable

Ah right, those need to be.

As for the salt

And if you do just not pass the salt at all, does anything not work? It's 10 uppercase letters: https://github.com/Syncplay/syncplay/blob/b62b038/syncplay/utils.py#L502-L511

tr -dc '[:upper:]' < /dev/random | head -c10

Depending on whether other characters are allowed as well, there may be a more efficient way of using the entropy pool via od, translating the input into e.g. hexadecimal characters instead of throwing away everything that is not an uppercase char.

[Ownsin]

Hello,

It's probably not going to get popular enough but I wanted to follow up with a simple way to run it as a service.

1. Install the latest server-only deb package from here: https://github.com/Syncplay/syncplay/releases
2. Create a syncplay user: useradd -r syncplay
3. Start the server once: syncplay-server. It will generate a "salt", which you might need later if you use room operator passwords. Copy it somewhere temporarily. Then kill it (Ctrl+C).
4. [optional] Create a MOTD (message of the day) file: touch /usr/lib/syncplay/motd.txt && chown syncplay:syncplay /usr/lib/syncplay/motd.txt, write what you want there.
5. Create a service file in /etc/systemd/system/syncplay.service:

[Unit]
Description=Syncplay server

[Service]
Type=simple
Restart=always
RestartSec=3
User=syncplay
ExecStart=syncplay-server --salt [paste salt here, no brackets] --motd-file /usr/lib/syncplay/motd.txt #put any other command line options you might need here

[Install]
WantedBy=multi-user.target

7. DO NOT Make it executable: chmod +x /etc/systemd/system/syncplay.service
8. Enable autostart and start the service: systemctl daemon-reload && systemctl enable syncplay && systemctl start syncplay
9. Now you can connect to it using a Syncplay client. The default port is 8999.

The other available guide is needlessly complicated, one doesn't need screen to make a simple service.

So in summary this can be easily scripted. I can help with it.

Hi, I followed your guide up until I added it as a service, but when I tried to run the service I couldn't, and I would get these errors:

Failed to start syncplay.service: Unit syncplay.service has a bad unit file setting.
See system logs and 'systemctl status syncplay.service' for details.

When I checked the status, I got this:

syncplay.service has more than one ExecStart setting, which is only allowed for Type=oneshot services. Refusing

Please advise on what to do?

[lukaszsobala]

How about modifying the [Service] part to:

[Service]
Type=simple
Restart=always
RestartSec=3
User=syncplay
ExecStart=
ExecStart=syncplay-server --salt [something] 

[MichaIng]

Yes, according to the error message there are two ExecStart entries, which cannot work. Try copy&pasting the service file from here.