Dietpi: Notice of myMPD behaviour change - primary group of mympd user

[jcorporation]

From issue #3110:

DietPi-Software | myMPD: Do not run service as "dietpi" group. Since it only reads but not writes media files, it is sufficient with "dietpi" as supplementary group.

The upcoming myMPD version 6.2.0 has the ability to publish the music and the playlist directory of MPD via webdav. This option is disabled in the standard configuration for security reasons.

It would be good if mympd had write permission for the mpd directories again, so webdav works after enabling it.

[MichaIng]

@jcorporation
Many thanks for the info.

This should be the case already, the commit description is a bid misleading:

• mympd user is added to dietpi group system-wide, hence as long as supplementary groups are not overwritten, myMPD still has write permissions to media dirs.
• ... ah but, if it writes files, and MPD + other media players want to access them, they mist be created as dietpi group... okay so action indeed required.

myMPD configs do not allow to set a group, right? Best solution for DietPi IMO is to simply switch the primary group for mympd user system-wide and remove the mympd group (which is unused):

usermod -g dietpi mympd
groupdel mympd

Overriding the primary group via systemd unit overrides other supplementary group memberships is some cases, still not sure in which exactly, but it happens.
What do you think?

---

Another question:

• myMPD never accesses to audio devices directly, right? We somehow currently add the user to "render" group, which at least enables permissions on Debian Buster for DRM and similar GPU rendering, but AFAIK has nothing to do with audio permissions, and in case MPD is added to this group.
• So I guess there is no point in using render group here, as well you installer does not use or mention it.

[MichaIng]

PR up: #3383
@jcorporation might you review it, based on above thoughts?

[jcorporation]

Looks good, thanks for your very fast response.

[MichaIng]

@jcorporation
Forgot to mention the switch to ./build.sh installdeps instead of installing dependency packages manually. I'll run some tests as well now.

[MichaIng]

@jcorporation
On Debian Stretch, myMPD connection to MPD server fails. Is there a minimum MPD version requirement? Or has the internal libmpdclient a minimal MPD version requirement?

Stretch APT repo would be MPD v0.19.21
Instead we pull v0.20.23 from dietpi.com
On Buster it's v0.21.5 already.

I compiled v0.21.19 and with this it worked fine. I needed to install meson from stretch-backports for this. Compiling for Raspbian Stretch will be hence more complicated since it does not have a backports repo and I am not sure if using Debian armv7hf meson to build for Raspbian armv6hf libs and packages will work without follow-up issues 🤔.

[jcorporation]

There should be no minimum MPD version requirement. Can you open an issue in the myMPD repo with debug logs from myMPD and MPD?

[jcorporation]

myMPD never accesses to audio devices directly, right?

right, rw access to the music and playlist directories are sufficient.

Btw:
Setting the right path to the mpd playlist directory in mympd.conf would be good, default is /var/lib/mpd/playlists.

[MichaIng]

@jcorporation
PR up: https://github.com/jcorporation/myMPD/issues/223

Setting the right path to the mpd playlist directory in mympd.conf would be good, default is /var/lib/mpd/playlists.

• https://github.com/jcorporation/myMPD/wiki/Configuration#section-mpd
• WARN Unkown config option: mpd - playlistdirectory 🤔

Btw regarding: https://github.com/jcorporation/myMPD/wiki/MPD-Configuration

• Must /var/lib/mpd/sticker.sql be the the path? I just removed the symlinks we left there since we set the correct final path for MPD frontends or they receive it from MPD directly for music and playlists. Didn't think about sticker.sql being accessed directly.
• Would be great if all those MPD paths could be received from MPD directly, if it's API allows.

[jcorporation]

• playlists: the playlistdirectory config option is new in v6.2.0, it can‘t be determined through the mpd protocol. This option is only used to publish this directory and not for the playlist functions in myMPD
• sticker: myMPD access stickers only through the mpd protocol not directly.
• musicdirectory: myMPD can detect this directory automatically only if the mpd connections is over a unixsocket, not over ip (mpd restriction)

I am planing a small cli tool that parses mpd.conf and configures myMPD accordingly. This tool should be non-interactive and could be called from your installer: https://github.com/jcorporation/myMPD/issues/224

[MichaIng]

Okay sounds all good then. I'll add the playlist dir ~commented for now and uncomment it once 6.2.0 is released~ EDIT: Ah no reason to comment it now since it only throws a warning that will disappear with v6.2.0. Will also retest all with the current 6.2.0 code state.

[MichaIng]

Alternative to self-compiled packages to provide current MPD on Debian+Raspbian Stretch: https://www.musicpd.org/download-unoff-debian/
Although I read inside about how to create simple deb packages, as long as this is maintained fine and has compile/setup options close to official Debian package, this should be preferred.

Since this is much newer than MPD even on Debian Bullseye, we could switch to this repo on all distro version 😎.

---

Setting up mpd (0.21.5-3~bpo9+2) ...
dpkg-statoverride: error: unknown option --force-all

Use --help for help about overriding file stat information.
dpkg: error processing package mpd (--configure):
 subprocess installed post-installation script returned error exit status 2
Processing triggers for libc-bin (2.24-11+deb9u4) ...
Processing triggers for systemd (232-25+deb9u12) ...
Errors were encountered while processing:
 mpd
E: Sub-process /usr/bin/dpkg returned an error code (1)

• Funny, I just saw on Buster about "--force is deprecated, use --force-all", but on Stretch this does not exist: https://manpages.debian.org/stretch/dpkg/dpkg-statoverride.1.en.html
• Since this package is clearly for Stretch, it must be seen as bug, strange only that this exists for SUCH a long time... EDIT: Mail sent, lets hope for repack of this package 🙂!
• Replacing --force-all with --force in postinst script fixes the issue... however not something we can workaround in a beautiful way 🤔.

🈯️ myMPD works fine with this.... no connection issue, but

🈴 Web UI only shows initial logo but does not continue to load, with current devel branch, debug log does not give a hint:

Feb 17 01:34:44 DietPi mympd[9149]: VERBOSE  /tmp/DietPi-Software/myMPD-devel/src/web_server.c:284: HTTP request (3): /
Feb 17 01:34:44 DietPi mympd[9149]: VERBOSE  /tmp/DietPi-Software/myMPD-devel/src/web_server.c:284: HTTP request (3): /assets/MaterialIcons-Regular.woff2
Feb 17 01:34:44 DietPi mympd[9149]: VERBOSE  /tmp/DietPi-Software/myMPD-devel/src/web_server.c:284: HTTP request (2): /css/combined.css
Feb 17 01:34:44 DietPi mympd[9149]: VERBOSE  /tmp/DietPi-Software/myMPD-devel/src/web_server.c:284: HTTP request (3): /js/combined.js
Feb 17 01:34:44 DietPi mympd[9149]: VERBOSE  /tmp/DietPi-Software/myMPD-devel/src/web_server.c:284: HTTP request (3): /assets/coverimage-loading.svg
Feb 17 01:34:44 DietPi mympd[9149]: VERBOSE  /tmp/DietPi-Software/myMPD-devel/src/web_server.c:284: HTTP request (3): /assets/appicon-192.png
Feb 17 01:34:44 DietPi mympd[9149]: VERBOSE  /tmp/DietPi-Software/myMPD-devel/src/web_server.c:284: HTTP request (3): /assets/favicon.ico

• Same on other Debian versions, hence this must be some issue with very latest devel code @jcorporation
• Revert to master branch fixes the issue on all distro versions.

[jcorporation]

Web UI only shows initial logo but does not continue to load, with current devel branch, debug log does not give a hint:

I am tested the latest devel code and I can't reproduce your issue. There should by a javascript error in your browsers console. Alternatively you can try a ./build.sh cleanupdist befor building myMPD, that forces a recreation of the delivered minified files, thats sometimes a problem in devel version.

[MichaIng]

@jcorporation
./build.sh cleanupdist indeed solves the issue. Does it make sense to add this to our installer or is it something that can only happen on devel branch?

[jcorporation]

It should happen only in the devel branch. In master I deliver always the actual minified files.

[jcorporation]

The mympd-config tool is now build and installed with v.6.2.0. The myMPD installer don't uses it for now. It should be more widely tested with custom mpd configurations.

https://github.com/jcorporation/myMPD/issues/224

[MichaIng]

@jcorporation
Looks great. Will do some testing when I find time.