When the container is started as root the default was to drop privileges to "unit:unit". This caused some problems with temporary files. Now the privileges are drop to "101:0".
When the container is started as a normal user unit prints a warning that changing the user and group is not possible. This warning is safe to ignore.
The migrations are only started if there are some that have not been
applied. Additionally the maintenace task needed after an update are
now run after the migrations
Before, the main_config (e.g. 'configuration.py' or 'ldap_config.py') were loaded twice.
The first load was hard-coded and correct.
The second load was during the discovery phase for dynamic configurations.
This has now been fixed. During the discovery for dynamic configurations,
the main_config file is now excluded.
Thanks @tobiasge for discovering this bug.
We now serve Netbox with an nginx-unit instance instead of Gunicorn.
This allows us to get rid of the extra Nginx container because Unit is
also serving the static files. The static files are now collected at container
buildtime instead of every startup.
The reason is that in the default configuration nginx is only serving 'http' traffic.
So if an upstream proxy sets the 'X-Forwarded-Proto' header, because it is terminating
TLS, then nginx will overwrite it to 'http'. This will cause django to think the page
is served via 'http' and it will not create 'https://...' URLs.
Related to #292
To optimize the application boot time the startup scripts can now be
disabled by an ENV variable. The default when the variable is not set,
is to run the startup scripts. This means that the default behaviour is
not changed from earlier releases.
One container should ideally have one responsibility [1]. Therefore I
implemented the netbox-worker to start in it's own container. This is
possible, because netbox and the worker communicate via redis anyway.
They still use the same image underneath, just the "command" they
execute while starting different.
Or in other words: I see no reason to introduce supervisord, when we
already have docker-compose which can take care of running multiple
processes.
Also, here's another benefit: Now it's possible to view the logs of the
webhook worker independently of the other netbox logs (and vice-versa).
Other changes in this commit:
* I don't see a reason to put a password for Redis in the docker-compose
setup, so I removed it.
* Slightly changed the nginx config, so that the nginx startup command
becomes simpler and any error should be visible in the docker log.
* Some housekeeping in the `Dockerfile`.
* Added some troubleshooting advice regarding webhooks to the README.
I'd like to thank Brady (@bdlamprecht [2]) here who did the harder
work of figuring out what's even required to have webhooks working. [3]
[1]
https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#decouple-applications
[2] https://github.com/bdlamprecht
[3] https://github.com/ninech/netbox-docker/pull/90
Make netbox-docker function with v2.4-beta1 again, fixes#84.
> The shell --plain option is deprecated in favor of -i python or --interface python.
> The shell --interface option now accepts python to force use of the “plain” Python interpreter.
https://docs.djangoproject.com/en/2.0/releases/1.10/#deprecated-features-1-10
With this the configuration is moved to /etc/netbox/config and the
default reports directory is set to /etc/netbox/reports. This enables
the user to mount reports from a config map or persistent volume in
OpenShift.
With these modifications the netbox containers can run on Openshift.
The configuration files can be imported from a config map to the
'/etc/netbox' directory and will be loaded from there.
