Closed rmens closed 1 week ago
Hi, Stereo Tool developer here. This is most likely a rights issue. We try to save in $HOME/.st_plugin.presets (with st_plugin the name of the plugin without the .so at the end). Depending on where and under which user account you're running things, it could be that that location isn't writable.
To test if this is indeed the issue (and as a temporary workaround): Make your home directory writable for anything (chmod 777), then check if such a directory is created. (You may need to restart Stereo Tool for that). Don't forget to restore the original rights after this.
root@liqtest:~# getent passwd liquidsoap
liquidsoap:x:102:109::/usr/share/liquidsoap:/usr/sbin/nologin
So the Liquidsoap user that's created by the .deb package gets /usr/share/liquidsoap/
as home directory. It's owned by root and not by the user liquidsoap. So StereoTool, which runs as the user liquidsoap can't write to it. Chmod 777 works but isn't a secure option.
This is interesting because according to:
https://github.com/savonet/liquidsoap/blob/4dc4d24800fbe4612e0ce3be9df0482004ec5aec/.github/debian/postinst#L25
the homedir is /var/cache/liquidsoap
but that never gets created.
Creating the .liquidsoap.presets
directory by hand in the homedir looks like the best hotfix and makes it work. I would still consider this a bug in Liquidsoap tho.
root@liqtest:/usr/share/liquidsoap# ls -la
total 20
drwxr-xr-x 5 root root 4096 Oct 10 23:29 .
drwxr-xr-x 99 root root 4096 Oct 10 23:29 ..
drwxr-xr-x 6 root root 4096 Oct 10 23:29 camomile
drwxr-xr-x 3 root root 4096 Oct 10 23:29 libs
drwxr-sr-x 2 liquidsoap liquidsoap 4096 Oct 10 23:31 .liquidsoap.presets
For the record: the directory always seems to be .liquidsoap.presets
not the name of the .so file @hansvanzutphen.
Oh. I guess our Linux code has a bug due to which it gets the name of the host application instead of its own name... I'll put that on our todo list. But that doesn't affect the issue itself.
My hotfix keeps expanding. Due to the non-writeable homedir of Liquidsoap it was necessary to create and chown the following directories:
/usr/share/liquidsoap/.liquidsoap.presets/
/usr/share/liquidsoap/.liquidsoap.log/
And the following file to get ST to save it's settings.
/usr/share/liquidsoap/.liquidsoap.rc
I defined preset="/etc/liquidsoap/st.ini"
in my original .liq file, since settings should be stored in /etc/
in Linux and /usr/share
is for read-only files.
I expected StereoTool to save its settings in the settings file that is specified in the preset=
argument in Liquidsoap. It seems to ignore that and write to $HOME/$HOSTNAMEAPP.rc anyway.
This all is a bit of a mess. There's no point in defining a preset in the .liq configuration if ST has a hardcoded path for it. The preset=
argument could be removed from Liquidsoap in that case since it's not very useful. Or the other way around: ST could respect the preset=
argument and save it's settings to the defined file.
Description
I'm not sure if this is a Liquidsoap or StereoTool problem. But since StereoTool doesn't have a public bug tracker, I'll start here.
When loading StereoTool in Liquidsoap, there's an option to save the preset via the web interface. Which is great, since it's a pain in the ass manually editing the preset file.
Steps to reproduce
Load StereoTool via
You have to define a pre-built preset with at least the web interface enabled and your ip whitelisted, otherwise it's impossible to configure StereoTool via it's web interface.
Configure the settings. Go to 'Select preset' and push 'Save current settings as preset'. This error will show up.
Expected behavior
Being able to save the preset.
Liquidsoap version
Liquidsoap build config
Installation method
From official packages in the release artifacts
Additional Info
Tested with StereoTool 10.41