Hi there,
I am trying to setup mopidy inside a docker based on debian buster, however running in some issues.
Is there a way to install mopidy not as a system user (I get an error when changing the uid beforehand)?
As with docker you (may) have shared files on the host you want to set the uid and gid to a self selected value as otherwise host users might get access to data that they shouldn’t have. In my case debian-exim.
Switching the uid would then enable me to use mopidy as a service.
OR
Is there a way to configure the binding of mopidy when running it with “mopidy” from the terminal? Whatever I put in the config (which is read by mopidy, as checked with mopidy config), is ignored and 127.0.0.1 is used.
Ok, something seems to be off with the config usage. At least it does not work like described in the documentation:
I start mopidy via /usr/bin/mopidy, hence it should use the config in /root/.config/mopidy/mopidy.conf
When calling /usr/bin/mopidy config that is true and it lists my config. However the running process is using /etc/mopidy/mopidy.conf. Only when I copy my config over there, it is picked up.
The only way /etc/mopidy/mopidy.conf gets used is when that file is explicitly specified in a command line argument passed to Mopidy. The systemd unit specifies that argument. The mopidyctl helper also does. Nothing else does and hence no other way of running Mopidy will normally use /etc/mopidy/mopidy.conf. Unless you explicitly tell it to.
Otherwise, normally, the config file is read from the home directory of the user running Mopidy.
So, how exactly did you start Mopidy? And why do you think it’s using /etc/mopidy/mopidy.conf ?
The interface that Mopidy-http listens on is controlled with its hostname config. Likewise for Mopidy-MPD. How that interface maps to something outside of a Docker container sounds like a Docker question.
As written in my post “I start mopidy via /usr/bin/mopidy”. Just /usr/bin/mopidy, no arguments given.
As written in my post it only picks up the config changes, if I apply them to /etc/mopidy/mopidy.conf
and if it is of help, because it says so in the logs:
Feb 15 00:46:47 mopidy-server[24625]: INFO 2020-02-15 00:46:47,053 [1:MainThread] mopidy.config
Feb 15 00:46:47 mopidy-server[24625]: Loading config from file:///etc/mopidy/mopidy.conf
So I understood that this apparently should not happen, as it should only use /etc/mopidy when run as a service (see Mopidy documentation). However it seems to not adhere to that when run with “mopidy” (but strangely with “mopidy config”). That is why I am confused and that is why question 2 in the original post came up.
Apologies for asking you to repeat yourself but I wanted confirmation as I can’t explain the behaviour you say you are seeing.
nick@xps:~$ /usr/bin/mopidy
MainThread INFO 2020-02-15 12:40:46,069 Starting Mopidy 3.0.1
MainThread INFO 2020-02-15 12:40:46,091 Loading config from builtin defaults
MainThread INFO 2020-02-15 12:40:46,092 Loading config from file:///home/nick/.config/mopidy/mopidy.conf
nick@xps:~$ sudo -u root /usr/bin/mopidy
INFO 2020-02-15 13:10:25,747 [17026:MainThread] mopidy.__main__
Starting Mopidy 3.0.1
INFO 2020-02-15 13:10:25,775 [17026:MainThread] mopidy.config
Loading config from builtin defaults
INFO 2020-02-15 13:10:25,777 [17026:MainThread] mopidy.config
Loading config from file:///root/.config/mopidy/mopidy.conf
That’s how I’d expect Mopidy to behave when not run as a service. There is nothing special about /usr/bin/mopidy and absolutely nothing within Mopidy knows absolutely anything about the existence of /etc/mopidy/mopidy.conf. You won’t find that string anywhere in the code base.
Did you create this Docker image yourself or find one?
No, worries, I was not sure if I made it clear in the original post.
It is a self build Dockerfile, but of course I used existing ones as a base. In them I found, that most of them rewrite the default config in var/lib.
You can find the Dockerfile below. Here some explanations:
I normally rewrite the uid, gid before install to get them in the correct values to prevent erratic file access on the host. However the package of mopidy checks if mopidy is a system user and will not install without one. Not sure why that is necessary, but it prevents to change the uid/gid in an easy way, hence I am not using it and keep it as root (not optimal, but better than having a random user on the host access to the data).
The entrypoint.sh is pretty much empty, as normally I would reset file permissions here, if the package changes them in updates.
I call this image with a bind of the mopidy.conf out of the host file system. I started with /root/.config/mopidy/mopidy.conf, as that was what the documentation said and got the above behavior. When now mounting it to /etc/mopidy/mopidy.conf it works, however this is just a workaround.
FROM debian:buster-slim
# Allow to set external uid, gid
ARG uid
ARG gid
# Add user and group before install, for correct file permission
#RUN groupadd -g $gid mopidy \
# && useradd -u $uid -g mopidy -b /dev/null -r -s /sbin/nologin mopidy
RUN export DEBIAN_FRONTEND=noninteractive
RUN apt-get -o Acquire::ForceIPv4=true update
RUN apt-get -o Acquire::ForceIPv4=true upgrade -y
RUN apt-get -o Acquire::ForceIPv4=true install -y \
curl \
gcc \
gnupg \
gstreamer1.0-alsa \
gstreamer1.0-plugins-bad \
nano \
python3-crypto \
python3-pip \
tzdata \
wget
# Get mopidy repository and install mopidy
RUN wget -q -O - https://apt.mopidy.com/mopidy.gpg | apt-key add -
RUN wget -q -O /etc/apt/sources.list.d/mopidy.list https://apt.mopidy.com/buster.list
RUN apt-get -o Acquire::ForceIPv4=true update
RUN apt-get -o Acquire::ForceIPv4=true install -y \
mopidy \
mopidy-local \
mopidy-podcast \
mopidy-spotify \
mopidy-tunein
# Install mopidy extensions
RUN pip3 install Mopidy-MusicBox-Webclient
# Cleanup
RUN apt-get purge --auto-remove -y \
curl \
gcc \
wget
RUN apt-get clean
RUN rm -rf /var/lib/apt/lists/*
# Set timezone
RUN cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime \
&& echo "Europe/Berlin" > /etc/timezone
ADD ./entrypoint.sh /usr/local/sbin/entrypoint.sh
RUN chmod u+x /usr/local/sbin/entrypoint.sh
EXPOSE 6680
ENV __FLUSH_LOG yes
ENTRYPOINT ["/usr/local/sbin/entrypoint.sh"]
CMD ["/usr/bin/mopidy"]