What happened then was that I tried to do an OTA upgrade and it failed because my system failed an `integrity check’ – manually edited files had been detected . I’m writing now to ask for some official
guidance about the extent to which and the ways in which we can modify our systems ourselves
without encountering such problems. The contexts for my request are these:
Forum posts over the years are full of advice about how volumio installations can be modified by
individual users. How can we know which of these suggestions are safe and which are not?
Closer to home: I installed the MiniDLNA plugin on one my volumio instances. It didn’t do what I hoped
it might and so I want to uninstall it. But the uninstall process fails with an error message
from systemd saying that the minidlna.service cannot be stopped. I suspect that I could solve this
problem via ssh, systemctl (and maybe apt --purge remove), but would doing that leave me
again with a system that can’t be upgraded?
These are for me really important issues so I hope you can supply some clarification. Thank you for all of your good work.
Volumio creates an md5 hash of /volumio and saves it to /etc/os-release. So only modifications of files in /volumio and a damaged /etc/os-release should cause the integrity check to fail.
The minidlna plugin does not modify files under /volumio so the integrity check should not be influenced by the plugin. Also connecting to Volumio via SSH should not touch the system integrity - doing it all the time here.
To find the cause of the uninstall issue with the plugin it could be helpful to get the log from the point where you attempted to uninstall the plugin. You could try sudo journalctl --no-tail and narrow the ouput down to the relevant time span.
Thank you very much indeed – this is very clear and is exactly the information I needed. And as a policy it all seems reasonable.
As to the problem with the miniDLNA plugin, journalctl --no-tail produced so much output that I tried instead: sudo journalctl | grep minidlna (following a reboot). That produced lines like:
error: Failed to start minidlna.service: Error: Command failed: /usr/bin/sudo /bin/systemctl start minidlna.service
Failed to start minidlna.service: Unit minidlna.service failed to load: No such file or directory.
although according to the web UI the plugin is on, active, and installed. There is a file minidlna.service in /data/plugins/miscellanea/minidlna/ ; but there is nothing under /etc/systemd. I think maybe there should either be a symlink in /etc/systemd/system/ to minidlna.service or else a full copy of that file. At present, the plugin seems to be in some zombie state – neither fully installed nor uninstalled. But this discussion may be more appropriate for a formal bug report than for this forum?
Thank you in any case for the crucial information I really wanted.
After the installation of the plugin there should be a minidlna.service file in /etc/systemd/system. The error message you posted indicates that this file is missing.
Either it has not been created during the installation of the plugin or it has been deleted on an attempt of uninstalling (or manually or by other software).
From your first post I assume the plugin was working after installation. If that is correct we can rule out an incomplete installation.
Did you try to uninstall the plugin and did you encounter error messages then?
Lastly, to solve your issues with the “zombie” state: You could try copying minidlna.service from /data/plugins/miscellanea/minidlna/ to /etc/systemd/system executing sudo cp /data/plugins/miscellanea/minidlna/minidlna.service /etc/systemd/system/minidlna.service. Then hit the “Uninstall” button in the UI.
The uninstalling of the plugin should now succeed. Maybe watch the log with sudo journalctl -f in parallel and report any error messages. If it works please give a feedback, too.
Thanks very much for your help. It turns out that the fundamental problem was that as soon as I had set the system up I had changed the password for the user volumio to something more secure (an old linux habit). Some parts of the uninstall process run as root so some of the crucial minidlna files had been removed , but later parts use sudo and they are written so as to expect the default password for the user volumio. Those parts of the process of course failed, because they were trying to use an `incorrect’ (i.e. the original) password. So the plugin was left in a half-installed, half-uninstalled state. When I changed the user password back to its original value, the process completed as it was supposed to.
I wouldn’t have set things up this way myself, since it has the consequence that if you want to use the plugin system you can’t make the minimal security enhancement of setting a password different from one that can easily be found on the web. But now at least I know how to work around this set-up. Or maybe it’s only the miniDLNA plugin for which this is an issue?
Yeah, I saw all those: echo "volumio" | sudo calls when I ran journalctl. That’s really gross. Worse, though, it would mean (if I hadn’t changed the password again and required key-based ssh access) that anyone who got access to my home network would instantly have root privileges on all of the volumio instances in the house. They could then turn every one of them into a spam-relay or worse. This isn’t exactly SELinux, is it?
