Bug#769325: mediatomb: Mediatomb does not work with systemd

Thu Dec 18 11:17:55 UTC 2014

Hola,

Find inlined comments below.

2014-12-09 14:35 GMT+01:00 Patrick Häcker <pat_h at web.de>:

>> > Even if it started, it wouldn't work, as it does not read the
>> > configuration file /etc/mediatomb/config.xml
>> >
>> > Additionally, it does not seem to make sense to have
>> > /etc/default/mediatomb, as nearly all options are duplicates of options in
>> > /etc/mediatomb/config.xml. It is completely unclear to a normal user which
>> > value is used, if the values of both files differ.
>> /etc/default/mediatomb is a file for daemon configuration (network card to
>> attach to, user/group to run under, location of config.xml, etc...)), while
>> /etc/mediatomb/config.xml is for mediatomb configuration (see upstream
>> documentation http://mediatomb.cc/pages/documentation#id2856319).
> Just for clarity for other readers, as I misunderstood this paragraph on first
> read: The documentation does not mention any separation of a "daemon
> configuration" from a "mediatomb documentation". But it states, that all
> relevant network related options are optional in config.xml.

Right.

>> You are right and some optional values can be set at config.xml, but Debian
>> mediatomb older releases have been configuring the daemon, even other
>> distros, as Fedora, configure the daemon. It is not our fault the upstream
>> provides two different ways to configure the daemon, via CLI or via
>> config.xml.
> It's absolutely standard for a Unix daemon to be configurable via
> configuration file, environment variables and CLI options (with increasing
> priority in case an option is set multiple times). Nevertheless, I can't
> remember a daemon where the configuration file is not the reference for
> default daemon startup. /etc/default is normally only used with parameters,
> which are not part of the daemon's configuration file.

Not sure I clearly understand you here. In older released mediatomb
has always shipped /etc/default/mediatomb file.
When adding systemd support, we updated variables to be more mediatomb
specific, similar to what Fedora uses.
  http://anonscm.debian.org/cgit/pkg-multimedia/mediatomb.git/commit/?id=5acd74434fbe71aa638529720fc5f11d14a857db
Some assumptions done by sysvinit script were moved into that same
default file for systemd compatibility.

>> > Mediatomb had working systemd support before these changes had been
>> > applied.
>> Sorry, there was no systemd unit file before, you might had been using the
>> old init script which also sets up the daemon.
> Thanks for clarification. That's what I meant, but my statement has indeed
> been ambiguous.

If you delete (or filter) systemd unit files it should fallback to use
sysvinit script as you were doing previously.

>> We picked to configure it via CLI with environment file, it has been that
>> way for several releases now.
> Yes, but in the init-script, config.xml is used (line 80), while in the new
> systemd unit file, config.xml is not used. Or that's what I thought. According
> to the documentation, /etc/mediatomb/config.xml should not be used with the
> configuration used in /lib/systemd/system/mediatomb.service, but I just found
> out, that this is incorrect. The above config.xml file is read even if no "-c"
> option is given in the service file. This makes one problem less.

Right, the config.xml file is still taken into account, if we look at unit file:
  http://anonscm.debian.org/cgit/pkg-multimedia/mediatomb.git/commit/?id=90f46857736afb6f49afe6c83dfc4d77fdb29613

>> > ExecStart=/usr/bin/mediatomb -d -c /etc/mediatomb/config.xml -P
>> > /run/mediatomb.pid

ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P
/run/mediatomb.pid -l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -p
$MT_PORT -e $MT_INTERFACE

where

## Location of the config file/database
MT_HOME="/etc"
MT_CFGDIR="mediatomb"

that way it still finds and parses config.xml.

Due to some other bug reports complaining that mediatomb exposed the
whole rootfs structure via web interface, I decided to hardcode
ethernet interface to loopback address and that needs to be changed by
admins if they want it to work on their network.

>> I do not think it's good idea to run the daemon as root, but instead
>> use the mediatomb user/group.
> Yes, that was a dumb idea from me, thanks for paying attention. This was the
> minimal working configuration for me and should not be used in Jessie.

Right, that's -u $MT_USER -g $MT_GROUP part

>> Sorry, I disagree to do those changes at this stage in the release, we are
>> frozen.
> Yes, we should aim for the least disruptive change which works for everyone.
> But please note, that the change in 0.12.1-7, uploaded directly before the
> freeze, was already a disruptive change, at least to me.

My most sincere apologies, I am still concerned about your issue and
trying to understand, was it disruptive because the $MT_ variable
update? I cant think on anything else.

>> Also you seem to drop network settings for UPnP to work properly on some
>> systems, why is that?
> I dropped them as I didn't need them (for a minimal working example). What do
> they do? Are there different UPNP standards and do some devices need them?

See
http://anonscm.debian.org/cgit/pkg-multimedia/mediatomb.git/tree/README#n842

>> I do not agree on the severity reported, as the package works for me with
>> that setup, and it might work for you, if you configure it properly.
>> Therefore I am downgrading severity to at most important as I do not think
>> it should be removed from jessie release, but I am further interested to
>> hear about your proposed changes and find a common area that works for all.
> It is not my intention to remove Mediatomb from Jessie. Instead I want to have
> a fix applied to Mediatomb before Jessie is released, as at least two users
> have problems with this version, although they had a working setup before and
> I fear that a lot of users might be affected when Jessie is released. Having
> it documented (with a release critical bug), that this package needs a fix
> before Jessie can be released seemed helpful to me.

Yes, let's please find the root cause, however I still do not think it
has RC severity (and that caused to be marked for autoremoval).

> Anyway, let's find the root cause, then we have better data and don't have to
> guess so much.

Great! :-)

> I tried several combination in /lib/systemd/system/mediatomb.service:
>
> # Does not work
> ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid
> -l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -e $MT_INTERFACE
>
> # Does not work
> ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid
> -l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -p $MT_PORT
>
> # Works
> ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid
> -l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR
>
> So setting the interface or the port makes mediatomb fail with systemd (using
> the init script works, but does not use the service file, of course).
>
> The variables MT_INTERFACE and MT_PORT are defined in /etc/default/mediatomb
> as following:
> MT_INTERFACE="eth1"
> MT_PORT="50500"
>
> The corresponding lines in /etc/mediatomb/config.xml read as following:
> <ip>192.168.1.10</ip>
> <port>49152</port>
>
> The port is definitely different, but the interface should be correct
> according to "ip route":
> 192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.10
>
> After changing MT_PORT to 49152 in /etc/default/mediatomb, Mediatomb works
> with systemd with the following line in /lib/systemd/system/mediatomb.service:
> ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid
> -l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -p $MT_PORT
>
> The reason this hasn't been a problem with the init-script is, that there is
> no port mentioned in the call:
> DAEMON_ARGS="-c /etc/mediatomb/config.xml -d -u $MT_USER -g $MT_GROUP -P
> $MT_PIDFILE -l $MT_LOGFILE $INTERFACE_ARG $OPTIONS"
>
> So this is definitely inconsistent (using the port number from
> /etc/default/mediatomb in systemd and using the port number from
> /etc/mediatomb/config.xml in the init script) and completely non-transparent
> to the user.
>
> Btw: The reason that Port 49152 works while 50500 does not is probably that
> 49152 has a special rule allowing it in my iptables rules, why there is no
> such rule for 50500. This could be changed, of course.

For reference, Fedora which did the systemd units ships with:
  http://pkgs.fedoraproject.org/cgit/mediatomb.git/tree/mediatomb.service

So, IIUC, you suggest to release mediatomb without a preconfigured
port because it causes conflicts when user has those settings
configured in config.xml file. I might need to do some testing on that
before pushing it forward.

> The remaining problem is the network interface option. Using
> ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid
> -l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -p $MT_PORT -i 192.168.1.10
> in the service file works with systemd, while
> ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid
> -l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -p $MT_PORT -e $MT_INTERFACE
> does not.
>
> The reason can be seen in
> /var/log/mediatomb:
> ERROR: You can not specify interface and IP at the same time!
> (Remember, that the ip has been set in /etc/mediatomb/config.xml)

Same conflict between config.xml and daemon configuration.  As
previously said, I decided to attach loopback interface as default as
some people was worried because mediatomb was exposing the whole
filesystem structure to outside world. Attaching to loopback device at
least forces admin to configure the package themselves.

> To summarize everything:
> The last mediatomb version broke working setups. These setups can be fixed by
> changing the configuration correctly and adapting the firewall rules. As
> Mediatomb behaves differently depending on being started by the init script or
> by systemd and as some options are available twice, it's very hard to find a
> working configuration. Nevertheless, it is possible.
>
> Overall, it's quite a mess. I would recommend to patch Mediatomb to exit with
> an error if the interface (and ip) or the port is configured in both
> /etc/mediatomb/config.xml and /etc/default/mediatomb with differing values.
> Additionally, I would recommend to change the init script to also use the port
> from /etc/default/mediatomb. A note on package upgrade would also be very
> helpful. Some additional documentation might also be in order.

I agree with your analysis, adding a NEWS note might be consistent.

Let's focus on Jessie release, we need to do minimal, less intrusive
changes to be able to pass release team acceptance.
My plan is to drop MT_PORT and MT_INTERFACE from systemd unit file, if
that works for all of us.

For next release, are you willing to work/propose a patch that exits
gratefully when there is a config mismatch between config.xml and
default config? I would be willing to support that idea.

Do you think that is good compromise?

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.