Saltar al contenido principal
Versión: 13.x

Docker

Some of these steps may not apply to your installation. Understand what they do, and ignore, or customize as necessary.

Preparation​

For operating system support and service packages.

Debian Linux​

Install Docker (Engine): https://docs.docker.com/engine/install/debian/

Fedora Linux​

Install Docker (Engine): https://docs.docker.com/engine/install/fedora/

Extra instructions​

sudo usermod -a -G docker <username>;

Re-login or restart the machine.

sudo su -;
mkdir /srv/UMS;
chcon -t svirt_sandbox_file_t /srv/UMS;
chgrp docker /srv/UMS;
chmod -R g+w /srv/UMS;

Montar el Almacenamiento al Cliente y enlacelo a ese directorio, probablemente solo de lectura mount <Videos-Share> '/srv/UMS/Videos'

Texto de ejemplo: Enlace simbólico simple a otra ruta en el sistema anfitrión puede no funcionar, ya que no habrá acceso a él desde afuera de la ruta del volumen montado por el contenedor del docker. En su lugar, intente copiar los archivos dentro de esta ubicación.

Container Setup​

Mount the following volumes:

  • Media folder /media
  • Profile folder containing UMS.conf /profile

Expose/forward these ports from the host: 1044, 5001, 9001.

The following scripts accomplish that (using the fish shell):

sudo su -;
set rootDir "$HOME/.config/UMS";
mkdir -p "$rootDir/data";
​
docker pull universalmediaserver/ums;
​
docker create --name UMS \
  -p 1044:1044 -p 5001:5001 -p 9001:9001 \
  -v /srv/UMS:/root/media \
  -v "$HOME/.config/UMS":/root/.config/UMS \
  universalmediaserver/ums \
;
​
docker start UMS;

Investigating Problems/Issues​

General​

docker ps -a;
#docker attach [--no-stdin] UMS; # Still unintentionally stops container when done inspecting..
docker container logs [-f] UMS;
docker exec -it UMS /bin/sh;
docker diff UMS;

For detailed logs in the terminal: echo -e '\nlog_level=ALL' >> UMS.conf

docker cp <containerName>:/var/log/UMS/root/debug.log ./;

Mount trouble​

Using Fedora CoreOS, I had access/permission denied problems trying to use bind mounts.

It may be recommended to use the Docker-managed, named-volumes capability instead, but to avoid that complexity, I found that the additional :Z as a suffix to the bind mount's descriptor option value allowed container write access to host files. :z can also be used instead, but security advice may suggest keeping resources more isolated between application/service environments, rather than shared.

Matching error messages can be seen using journalctl, so it is an SELinux problem. The solution for that would be to run chcon -Rt svirt_sandbox_file_t host_dir, but that also seems discouraged.

Strangely this is not an issue on Fedora Workstation, but I guess installing it manually added a package to deal with this. Seems to be container-selinux.

References​