The `uwsgi-netbox` service now works, also the `netbox` wrapper service.
The PID file was removed from the Gunicorn service as it is not required
and a bit more efford to move it to `/run/` due to permissions.
Generally, all depend on `network.target` instead of
`network-online.target` now, and signals for reload, stop and kill were
added (especially required the uwsgi service).
To avoid aborts because of the python venv could not be updated by
killing all processes that uses the venv.
It will be done all times to prevent any error, because it could not be
reliably detected if the type installs or updates NetBox.
Enables multiple protocols like fastcgi or HTTP to bind to. This makes
it more flexible to use.
Also, a little fix for __netbox was done: correctly output a error msg.
Shellcheck warned about creating content for a python array. As the
string will be printed literally into the config, the warning does not
match to the current case.
The wrapper service will "control" the services added from the
__netbox_* types to provide a general interface. This is more dynamic
than the alias approach used previously. Through this, it is possible
to handle multiple wsgi services for netbox - if this works ..
See as a reference:
http://alesnosek.com/blog/2016/12/04/controlling-a-multi-service-application-with-systemd/
Because someone *want* to use something other than just gunicorn, it was
extracted to a own type. Because gunicorn is a bit deep in the netbox
installation process, it's a bit harder to isolate it.
`__netbox_uwsgi` will come, too.
The secret key is generated if it is not set via parameter and the
explorer does not return any. It will be saved in the netbox home
directory to easily read the key for the config generation.
Fixes error message `/opt/netbox/netbox/netbox/settings.py:141:
UserWarning: REMOTE_AUTH_DEFAULT_PERMISSIONS should be a dictionary.
Backward compatibility will be removed in v2.10.`
The working `ls | grep .` like solution was dropped based on the
shellcheck warning. Rather a solution with `find(1)` is used.
As alternative, it could be simply checked if the glob succeeds or not
by test all given arguments if there are existing files. It was dropped
in question if it's really better than the `find(1)` solution.
The ldap config file will be empty (only comments) if no parameter
name set matches `^ldap-*`.
It still generate a ldap config if one or more ldap parameters are set,
but not all basic parameters.
