Files config.docker.php, config.php and directory config.d have wrong UID and GID after install.

[ehoitinga]

I am busy installing your librenms image on a Synology RS815+ NAS server. After I have created the database and issued my Docker run command the UID and GID of the files config.docker.php, config.php and directory config.d have the UID and GID from root in stead of librenms after install. I used the following docker run command to install the cointainer:

docker run \ -d \ -p 8000:80 \ -p 8443:443 \ -e DB_HOST=192.168.1.248 \ -e DB_NAME=librenms \ -e DB_PORT=3307 \ -e DB_USER=librenms \ -e DB_PASS=librenms \ -e TZ=Europe/Brussels \ -e BASE_URL=https://192.168.1.248:8443 \ -e POLLERS=16 \ -v /volume1/docker/librenms/logs:/opt/librenms/logs \ -v /volume1/docker/librenms/rrd:/opt/librenms/rrd \ -v /volume1/docker/librenms/ssl:/etc/nginx/ssl:ro \ -v /volume1/docker/librenms/config.custom.php:/opt/librenms/config.custom.php:ro \ --name librenms \ jarischaefer/docker-librenms

The validate.php scripts complains about this and I can not login to to librenms. After a restart of the docker image and 'cd /opt && chown -R librenms.librenms /opt/librenms' I can login and the validate.php script no longer gives error messages. There are some warnings left but it seemed to be working.

Am I doing something wrong or can this be a bug.

Erik

[jarischaefer]

I am aware of validate.php's complaints about permissions. However, I did not detect any functional issues on my setup (using v1.33).

Most of the warnings about permissions seem to be false positives. Since LibreNMS does not originally ship with config.docker.php/config.custom.php (these files are implementation details of this particular container), their permissions should be irrelevant.

In my opinion, the only valid complaint concerns the config.php file, which is part of LibreNMS. Since config.php is readable by the librenms user, there should be no problem with root owning the file (unless LibreNMS writes to config.php, I am not sure about that).

I will have to analyze the issue more thoroughly and get back to you.

[E-t-z]

I'm running this container on Synology DS916+ myself, so I can comment on this:

These issues can be ignored as they are purely cosmetic. As @jarischaefer already explained, config.docker.php/config.custom.php, both are this container specific files.

config.php has indeed root permissions, but it is due to the fact, how it is being assembled from multiple files when this container is started (without this "complex" process, you would not have any permanent custom config possibility) and it won't cause any problems as librenms user can still read it. LibreNMS itself does not need any write permissions to that file and does not write into it, so everything will work just fine.

In short, you should call it a feature instead :)

http://starecat.com/content/wp-content/uploads/bug-feature-by-design.jpg

[ehoitinga]

OK. Thank you all for your swift response. For your convienance I added the actual output of validate:

root@1259d41e1f38:/opt/librenms# cd /opt/librenms && ./validate.php

Component	Version
LibreNMS	1.33
DB Schema	213
PHP	7.1.11-1+ubuntu16.04.1+deb.sury.org+1
MySQL	10.0.31-MariaDB
RRDTool	1.5.5
SNMP	NET-SNMP 5.7.3

====================================

[OK] Database connection successful [OK] Database schema correct [WARN] Your install is over 24 hours out of date, last update: Sun, 29 Oct 2017 21:39:24 +0000 [FIX] Make sure your daily.sh cron is running and run ./daily.sh by hand to see if there are any errors. [WARN] Your local git branch is not master, this will prevent automatic updates. [FIX] You can switch back to master with git checkout master [WARN] Your local git contains modified files, this could prevent automatic updates. [FIX] You can fix this with ./scripts/github-remove Modified Files: logs/.gitignore rrd/.gitignore root@1259d41e1f38:/opt/librenms#

Erik

[E-t-z]

Your validate output looks just fine, nothing to be worried about. It is "out of date", because it is using monthly release schedule not daily one.

Benefit is, while you would miss latest "bells and whistles" it should be generally more stable and tested. Also, building and maintaining new docker image daily, would be probably too time consuming for @jarischaefer You can always update it by yourself, if you really wish to do it more frequently. But be cautious I don't think, this functionality is really tested much on this image. And AFAIK your container will grow significantly in size, when you do this often.

[ehoitinga]

@E-t-z But still, if I do not change the owner and group id of config.php I am not able to connect to librenms with my browser nor the cronjobs are executed. And this has to be repeated by every container restart.

UPDATE: A restart of the container leaves the permissions intact. Only when I reinstall the container the UID and GID of the files config.docker.php, config.php and directory config.d are set to root.

[E-t-z]

By any chance, do you have changed your Docker share /volume1/docker/ permissions?

Still it should not affect ability to log in, as user is stored in DB.

[ehoitinga]

I changed nothing on the docker shared folder. I left it as created when I installed docker on my NAS. If you mean the access rights of the librenms folder in /volume1/docker/ the access right are as follows:

root@nas-server:/volume1/docker# ll
total 0
drwxr-xr-x+ 1 root root  28 Oct 31 15:47 .
drwxr-xr-x  1 root root 320 Oct 31 14:50 ..
drwxrwxrwx+ 1 root root   8 Oct 31 13:18 @eaDir
drwxr-xr-x+ 1  999  999  54 Oct 31 15:49 librenms
root@nas-server:/volume1/docker# cd librenms
root@nas-server:/volume1/docker/librenms# ll
total 4
drwxr-xr-x+ 1  999  999   54 Oct 31 15:49 .
drwxr-xr-x+ 1 root root   28 Oct 31 15:47 ..
-rw-r--r--  1  999  999 1085 Oct 31 15:49 config.custom.php
drwxrwxr-x  1  999  999   42 Nov  1 00:15 logs
drwxrwxr-x  1  999  999  198 Oct 31 17:00 rrd
drwxr-xr-x+ 1 root root   28 Oct 31 15:56 ssl
root@nas-server:/volume1/docker/librenms# ls -l ssl
total 8
-rw-r--r-- 1 root root 1428 Oct 31 15:55 ssl.crt
-rw------- 1 root root 1708 Oct 31 15:55 ssl.key
root@nas-server:/volume1/docker/librenms# 

If you want I can PM (if possible in GitHub) my 'install guide' that I made during my install.

Erik

[ehoitinga]

Your validate output looks just fine, nothing to be worried about. It is "out of date", because it is using monthly release schedule not daily one.

Benefit is, while you would miss latest "bells and whistles" it should be generally more stable and tested. Also, building and maintaining new docker image daily, would be probably too time consuming for @jarischaefer

Is this done by the daily.php script?

You can always update it by yourself, if you really wish to do it more frequently. But be cautious I don't think, this functionality is really tested much on this image. And AFAIK your container will grow significantly in size, when you do this often.

I am a bit puzzled by the update process. It is only for a couple of weeks that I dove into Docker. I thought the daily.sh script took care of the update of git branch of librenms while the linux operating system in the container stays unchanged. When I want to update do I have to delete the container and the image and start installation all over?

Still have lots of reading to do when it comes to Docker :-)

[E-t-z]

Well, first of all...dont't treat Docker container as VM, it is not. You should think Docker container as an virtualized application.

About the container, you should not worry about configuring anything from scratch, just delete container and recreate it, all your data is stored outside of container. Synology has marvellous GUI for Docker, which lets you import/export container config as json, so it would take only couple of minutes to download updated image and recreate it.

BTW, My Docker share permissions look like this:

Etz@Syno:/volume1/docker$` ll
total 0
drwxrwxrwx+ 1 root root   36 Aug  4 14:40 .
drwxr-xr-x  1 root root  760 Oct 30 12:00 ..
drwxrwxrwx+ 1 root root    8 Oct 18 19:39 @eaDir
drwxrwxrwx+ 1 Etz  users  54 Jul  1 16:05 LibreNMS
drwxrwxrwx+ 1 root root    0 Aug  2 13:46 @tmp

Why your LibreNMS directory is owned by LibreNMS user? This may cause a slight problem, as Synology DSM does not know anything about this user.

Everything else is fairly similar to yours:

Etz@Syno:/volume1/docker/LibreNMS$ ll
total 4
drwxrwxrwx+ 1 Etz  users   54 Jul  1 16:05 .
drwxrwxrwx+ 1 root root    36 Aug  4 14:40 ..
-rwxrwxrwx+ 1 Etz  users 1554 Oct 27 23:03 config.custom.php
drwxrwxr-x  1  999   999   42 Dec 11  2016 logs
drwxrwxr-x  1  999   999   36 Oct 30 21:15 rrd
drwxrwxrwx+ 1 Etz  users    0 Dec  8  2016 ssl

I have not changed any permissions from inside the container, as image handles these themselves.

[ehoitinga]

You were right, understanding docker has to be approached with another way of thinking when you are use working with VM's. OK. I have it running right now following this procedure. Yeah I like documenting while I am testing ;-)

However there are a few things:

When I do an update I download the new image and create the container using the same command. But what about the database schema? How to update that, running daily.sh refuses to update the database schema.

I noticed that the host name of the container changes every time a new container is created. Is this by design? My syslog server fills up with different host names for the same 'server'.

Also I noticed that when i point my browser to https://nas-server:8443 I have to login twice before I have access to librenms. After logging in my server address has changed to https://192.168.1.248:8443/. When I point my browser directly to https://192.168.1.248:8443/ the first login is successful. Name resolution comes before connecting to the librenms website on the nas server. Something to do with referrer interpretation?

Erik

[E-t-z]

Not sure what are you thinking by: hostname changing all the time.

Change your BASEURL to / and this "login twice" should go away. Problem is that first you log in via DNS name and after that you get redirected to IP, so you would have to log in again.

I personally never used IP or URL:PORT to access containers.

I use Synology built-in ngnix reverse-proxy, so I have unique URL for every container without any port in it, and they are totally different from my NAS hostname (Yeah I have specified them in DNS as well, in my router)

See this: https://s1.postimg.org/2yc2intnj3/Capture.png

If Synology provides us such tools, why not use them :) Additional benefit is, that we can use https on containers, which do not actually support it or fiddle with additional certificates for containers.

[ehoitinga]

Not sure what are you thinking by: hostname changing all the time.

root@nas-server:~# docker exec -it librenms bash root@15fc2105df16:/# hostname 15fc2105df16 root@15fc2105df16:/#

Also for some reason the validate script gives me errors now about poller jobs under an old host name that have not completed. Host name is now af62ddd9c123.

[FAIL] The poller (15fc2105df16) has not completed within the last 5 minutes, check the cron job [FAIL] The poller (a4b5b6ea4393) has not completed within the last 5 minutes, check the cron job

I run a central syslog server on my nas and I configured LNMS to send its log messages to it.

Change your BASEURL to / and this "login twice" should go away.

Setting the BASE_URL to / did the trick. Will try the solution with reverse proxy on the Synology. Seems to be a more proper way to address the containers. I suppose the source part in your reverse proxy is a FQDN for external access of your librenms?

Erik

[jarischaefer]

The hostname may be specified explicitly using: docker run -h foobarbaz ...

I am currently testing some internal changes that will fix the warnings about permissions.

[jarischaefer]

Could you try again with the latest image? It includes a7e96688f1e6bfb6d7af7ef40c237ee0fc02e21c.

[ehoitinga]

@jarischaefer Thank you very much. So just to be clear. To update I delete the container and the image and I reissue the command:

sudo docker run \
    -d \
    -h librenms \
    -p 8000:80 \
    -p 8443:443 \
    -e DB_HOST=192.168.1.248 \
    -e DB_NAME=librenms \
    -e DB_PORT=3307 \
    -e DB_USER=librenms \
    -e DB_PASS=librenms \
    -e TZ=Europe/Brussels \
    -e BASE_URL=/ \
    -e POLLERS=16 \
    -v /volume1/docker/librenms/logs:/opt/librenms/logs \
    -v /volume1/docker/librenms/rrd:/opt/librenms/rrd \
    -v /volume1/docker/librenms/ssl:/etc/nginx/ssl:ro \
    -v /volume1/docker/librenms/config.custom.php:/opt/librenms/config.custom.php:ro \
    --name librenms \
    jarischaefer/docker-librenms

When I do it in this way will it take your latest image or do I have to specify jarischaefer/docker-librenms:latest?

I suppose that in my sudo docker run command I have change the line:

-v /volume1/docker/librenms/config.interfaces.php:/opt/librenms/config.custom.php:ro \

to:

-v /volume1/docker/librenms/config.custom.php:/opt/librenms/conf.d/config.interfaces.php \

and copy the contents of the old config.custom.php to this file. I have some extra config lines in this file. The contents of my old config.custom.php is:

<?php
//
// config.interfaces.php
//
// Interfaces to ignore
$config['bad_if_regexp'][] = '/^docker[\w]+$/';
$config['bad_if_regexp'][] = '/^lxcbr[0-9]+$/';
$config['bad_if_regexp'][] = '/^veth.*$/';
$config['bad_if_regexp'][] = '/^virbr.*$/';
$config['bad_if_regexp'][] = '/^lo$/';
$config['bad_if_regexp'][] = '/^macvtap.*$/';
$config['bad_if_regexp'][] = '/tun[0-9]+$/';
//
// SNMP v1 or v2c
$config['snmp']['community'] = array("G11DFresErRS");
//
// When using HTTPS, it is recommended that you use secure, encrypted cookies
// to prevent session hijacking attacks.
$config['secure_cookies'] = true;
//
// Auto discovery settings
$config['autodiscovery']['xdp'] = true;
$config['autodiscovery']['ospf'] = true;
$config['autodiscovery']['bgp'] = true;
//
// Perform discovery on the subnets below
$config['nets'][] = '192.168.1.0/24';
$config['nets'][] = '192.168.10.0/24';
$config['nets'][] = '10.16.100.0/24';
$config['nets'][] = '172.17.0.0/16';
//
// Enable two factor authentication.
$config['twofactor'] = true;
$config['twofactor_lock'] = 300;

Think I will have some time tonight (Belgium time) to test. Keep you posted.

Erik

[jarischaefer]

To update I delete the container and the image and I reissue the command

Yes, that works. You may also use docker pull jarischaefer/docker-librenms to fetch images explicitly (docker run only fetches the image if it is not stored locally) and then docker stop librenms && docker rm -v librenms followed by docker run ...

When I do it in this way will it take your latest image or do I have to specify jarischaefer/docker-librenms:latest?

If you do not specify the tag, docker implicitly uses latest. Therefore, jarischaefer/docker-librenms and jarischaefer/docker-librenms:latest are the same. Keep in mind that you must either docker pull jarischaefer/docker-librenms or remove the image and have docker run pull it automatically to get the latest build.

I suppose that in my sudo docker run command I have change the line:

-v /volume1/docker/librenms/config.interfaces.php:/opt/librenms/config.custom.php:ro \

to:

-v /volume1/docker/librenms/config.custom.php:/opt/librenms/conf.d/config.interfaces.php \

The legacy config.custom.php file (mounted on /opt/librenms/config.custom.php) still works, but it is deprecated.

and copy the contents of the old config.custom.php to this file. I have some extra config lines in this file. The contents of my old config.custom.php is:

Yes, copying the contents and making sure the file starts with <?php is sufficient.

[ehoitinga]

@jarischaefer Thank you for your reply. Looks like it its working.

root@librenms:/opt/librenms# ./validate.php
====================================
Component | Version
--------- | -------
LibreNMS  | 1.33.01
DB Schema | 214
PHP       | 7.1.11-1+ubuntu16.04.1+deb.sury.org+1
MySQL     | 10.0.31-MariaDB
RRDTool   | 1.5.5
SNMP      | NET-SNMP 5.7.3
====================================

[OK]    Database connection successful
[OK]    Database schema correct
[WARN]  Your install is over 24 hours out of date, last update: Wed, 01 Nov 2017 17:55:06 +0000
    [FIX] Make sure your daily.sh cron is running and run ./daily.sh by hand to see if there are any errors.
[WARN]  Your local git branch is not master, this will prevent automatic updates.
    [FIX] You can switch back to master with git checkout master
[WARN]  Your local git contains modified files, this could prevent automatic updates.
    [FIX] You can fix this with ./scripts/github-remove
    Modified Files:
     logs/.gitignore
     rrd/.gitignore
root@librenms:/opt/librenms#

I am writing a little shell script to automate the update procedure. If interested I can publish it here when it is finished.

When I use the commands sudo docker pull jarischaefer/docker-librenms, sudo docker stop librenms, sudo docker rm -v librenms and sudo docker run ... to update to a new LibreNMS version will the the database schema be updated also?

The script daily.sh gives me errors. I run an external MariaDB 10 database listening on port 3307 on the same nas-server as Docker. Looks like the daily.sh scripts has trouble finding the proper hostname and or port of my database server.

root@librenms:/opt/librenms# ./daily.sh
Re-running /opt/librenms/daily.sh as librenms user
Checking PHP version                               FAIL
MySQL Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
MySQL Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
Updating SQL-Schema                                FAIL
MySQL Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
Updating submodules                                OK
Cleaning up DB                                     FAIL
MySQL Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
MySQL Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
MySQL Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
MySQL Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
MySQL Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
MySQL Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
MySQL Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
MySQL Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
MySQL Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
MySQL Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
MySQL Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
MySQL Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
Fetching notifications                             FAIL
MySQL Error: php_network_getaddresses: getaddrinfo failed: Name or service not known
Caching PeeringDB data                             OK
root@librenms:/opt/librenms#

Many thanks,

Erik

[jarischaefer]

I am writing a little shell script to automate the update procedure. If interested I can publish it here when it is finished.

Sure, but keep in mind that nowadays a lot of people favor management tools over custom scripts (these tools did not exist in the past, so many people wrote their own scripts back in the day).

When I use the commands sudo docker pull jarischaefer/docker-librenms, sudo docker stop librenms, sudo docker rm -v librenms and sudo docker run ... to update to a new LibreNMS version will the the database schema be updated also?

Yes, updates should be applied automatically. If you navigate to Settings -> About LibreNMS, there should be a DB Schema column. When I upgrade my own instance, the schema always updates itself.

In the past, some of LibreNMS's SQL scripts were broken and updates were not applied correctly (but the schema version counter was incremented anyway). I think this should be investigated in a separate issue (analyzing the update procedure, making sure there are no partial updates, ...). Perhaps this is something the LibreNMS developers have to fix themselves, if the problem cannot be solved externally.

The script daily.sh gives me errors. I run an external MariaDB 10 database listening on port 3307 on the same nas-server as Docker. Looks like the daily.sh scripts has trouble finding the proper hostname and or port of my database server.

The underlying PHP scripts use getenv to retrieve the configuration. Your shell probably lacks the proper environment variables (DB_HOST, DB_USER, ...).

I usually run the following inside the container:

su - librenms
source /etc/librenms_environment <- loads the env vars
cd /opt/librenms
php validate.php

[ehoitinga]

Sure, but keep in mind that nowaways a lot of people favor management tools over custom scripts (these tools did not exist in the past, so many people wrote their own scripts back in the day).

You're right. I am a bit old school. Started in IT when the first PC's came out. I feel old :-)

The underlying PHP scripts use getenv to retrieve the configuration. Your shell probably lacks the proper environment variables (DB_HOST, DB_USER, ...).

Learning every day... I can confirm that the the daily.sh script runs without errors with this method.

Thanks

Erik

[jarischaefer]

You're right. I am a bit old school. Started in IT when the first PC's came out. I feel old :-)

Well, I am still using a bunch of old bash scripts for my deployments, so maybe I am growing older too ;)

Learning every day... I can confirm that the the daily.sh script runs without errors with this method.

Great, so no more issues with permissions?

[ehoitinga]

Great, so no more issues with permissions?

No more issues with permissions. Thank you very much for your help.

Quick question though, does your image supports the applying of patches with the script github-apply. I recently tried to apply a patch but I encountered some problems.

This is the script I use to mange the librenms container. Still in development but must mqke the update process more easy.

[jarischaefer]

Quick question though, does your image supports the applying of patches with the script github-apply. I recently tried to apply a patch but I encountered some problems.

No, the images are intended to be immutable and your changes will disappear after docker rm. I suggest you build a custom image and pass build args: docker build --build-arg LIBRENMS_VERSION=hash.

[ehoitinga]

No, the images are intended to be immutable and your changes will disappear after docker rm. I suggest you build a custom image and pass build args: docker build --build-arg LIBRENMS_VERSION=hash.

Excuse my ignorance, but what will the LIBRENMS_VERSION=hash option do? I suppose it has nothing to to with the perl module 'hash'.

I presume I have to use your dockerfile and files tree to build a custom image?

[jarischaefer]

The hash is used to determine the LibreNMS version. The latest release is based on commit https://github.com/librenms/librenms/commit/b7a06045b01aa86e7eabef9e1018c3d34c190a2a. You may find the hash (b7a06045b01aa86e7eabef9e1018c3d34c190a2a) inside the URL.

Pick a hash from https://github.com/librenms/librenms/commits/master, clone the repository from GitHub and build the image:

git clone --depth 1 https://github.com/jarischaefer/docker-librenms`
docker build -t librenms --build-arg LIBRENMS_VERSION=3dcadcccce26d3bd1d29dfd77952721ae1872b84 docker-librenms

[jarischaefer]

Closing this issue. See https://github.com/jarischaefer/docker-librenms/issues/55

[saterunholy]

I have an issue trying to run it on a Raspberry Pi 4 (Raspbian GNU/Linux 10 (buster), once i try to generate the key i get this error: "standard_init_linux.go:211: exec user process caused "exec format error"