libselinux – undefined reference to pcre_version

Emerging the “sys-libs/libselinux-2.9-r1” failed with this link errors of undefined references

/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.lo: in function `regex_version':
regex.c:(.text+0x30): undefined reference to `pcre_version'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.lo: in function `regex_writef':
regex.c:(.text+0x95): undefined reference to `pcre_fullinfo'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.c:(.text+0xf6): undefined reference to `pcre_fullinfo'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.lo: in function `regex_data_free':
regex.c:(.text+0x1eb): undefined reference to `pcre_free'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.c:(.text+0x200): undefined reference to `pcre_free_study'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.lo: in function `regex_prepare_data':
regex.c:(.text+0x26d): undefined reference to `pcre_compile'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.c:(.text+0x28f): undefined reference to `pcre_study'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.lo: in function `regex_load_mmap':
regex.c:(.text+0x385): undefined reference to `pcre_fullinfo'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.c:(.text+0x3ed): undefined reference to `pcre_fullinfo'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.lo: in function `regex_match':
regex.c:(.text+0x494): undefined reference to `pcre_exec'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.lo: in function `regex_cmp':
regex.c:(.text+0x502): undefined reference to `pcre_fullinfo'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: regex.c:(.text+0x51a): undefined reference to `pcre_fullinfo'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:148: libselinux.so.1] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/var/tmp/portage/sys-libs/libselinux-2.9-r1/work/libselinux-2.9-abi_x86_32.x86/src'
make: *** [Makefile:44: all] Error 1
 * ERROR: sys-libs/libselinux-2.9-r1::gentoo failed (compile phase):
 *   emake failed
 *
 * If you need support, post the output of `emerge --info '=sys-libs/libselinux-2.9-r1::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-libs/libselinux-2.9-r1::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-libs/libselinux-2.9-r1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-libs/libselinux-2.9-r1/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-libs/libselinux-2.9-r1/work/libselinux-2.9-abi_x86_32.x86'
 * S: '/var/tmp/portage/sys-libs/libselinux-2.9-r1/work/libselinux-2.9'

>>> Failed to emerge sys-libs/libselinux-2.9-r1, Log file:

>>>  '/var/tmp/portage/sys-libs/libselinux-2.9-r1/temp/build.log'

 * Messages for package sys-libs/libselinux-2.9-r1:

 * ERROR: sys-libs/libselinux-2.9-r1::gentoo failed (compile phase):
 *   emake failed
 *
 * If you need support, post the output of `emerge --info '=sys-libs/libselinux-2.9-r1::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-libs/libselinux-2.9-r1::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-libs/libselinux-2.9-r1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-libs/libselinux-2.9-r1/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-libs/libselinux-2.9-r1/work/libselinux-2.9-abi_x86_32.x86'
 * S: '/var/tmp/portage/sys-libs/libselinux-2.9-r1/work/libselinux-2.9'

The solution was to rebuild the dev-libs/libpcre and dev-libs/libpcre2 libraries.

emerge -va dev-libs/libpcre dev-libs/libpcre2

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U  ] dev-libs/libpcre-8.43:3::gentoo [8.42:3::gentoo] USE="bzip2 cxx jit pcre16 readline recursion-limit (split-usr%*) (static-libs) (unicode) zlib -libedit -pcre32" ABI_X86="32 (64) (-x32)" 1540 KiB
[ebuild     U  ] dev-libs/libpcre2-10.34::gentoo [10.32::gentoo] USE="bzip2 jit pcre16 pcre32* readline recursion-limit (split-usr%*) unicode zlib -libedit -static-libs" ABI_X86="32 (64) (-x32)" 1676 KiB

Total: 2 packages (2 upgrades), Size of downloads: 3216 KiB

if you encounter the error above even you are not using Gentoo probably the problem is your libpcre/libpcre2 library and try to rebuild it or include the proper path to the library and its headers.

aplty – unable to find control.tar.gz part in package – change deb package compression from xz to gzip

We upgraded to a new version of Ubuntu and our CI (continuous integration) scripts began to throw errors when uploading packages to out aptly repository:

"Report":{"Warnings":["Unable to read file /srv/aptly/.aptly/upload/mysoft/mysoft-6.15-pk19.deb: unable to find control.tar.gz part in package /srv/aptly/.aptly/upload/mysoft/mysoft-6.15-pk19.deb"],"Added":[],"Removed":[]}}

But if the same command:

dpkg-deb --build $PKGNAME

is executed on our older Ubuntu 16 everyhting is perfect and no error when uploading the package in the repository.

It turns out the new version of dpkg 1.19.0 the dpkg-deb will compress the deb file with XZ by default. Before version 1.19 the default compression is gzip.

You may upgrade your aptly installation to 1.20 and above or just fix your script to use “-Zgzip” with dpkg-deb

dpkg-deb -Zgzip --build $PKGNAME

This command will force the dpkg-deb to use gzip to compress the debian package.

Change the compression of existing deb package

Thanks to the aptly bug report – https://github.com/aptly-dev/aptly/issues/655 (hopes this link stays forever) you may have a workarround to decompress and comrpess an existing package with antoher algorythm

dpkg-deb -R package.deb tmp
rm package.deb
fakeroot dpkg-deb -Zgzip -b tmp package.deb
rm -rf tmp

docker mysql – Fatal error: Please read “Security” section of the manual to find out how to run mysqld as root!

Pulling the official MySQL image from the docker registry https://hub.docker.com/r/mysql/mysql-server to start a MySQL instance with your configuration file (and MySQL binary files). Adding the “–volume” option for the configuration directory (or file) and MySQL binary files and you stumble on the error:

2019-12-03 01:13:38 0 [Note] mysqld (mysqld 5.6.46-log) starting as process 67 ...
2019-12-03 01:13:38 67 [ERROR] Fatal error: Please read "Security" section of the manual to find out how to run mysqld as root!

2019-12-03 01:13:38 67 [ERROR] Aborting

2019-12-03 01:13:38 67 [Note] Binlog end
2019-12-03 01:13:38 67 [Note] mysqld: Shutdown complete

Apparently, the server option is not configured to run properly as a root user and you do not want to run it, but why it keeps insisting to run it as root?

Because of the entry point script will execute only “mysqld” as a command, which expects to have a “user” option in the “[mysqld]” section of your my.cnf configuration file!

Do not miss the user option in my.cnf! This is how the MySQL server will be using the “mysql” username not the root!

user=mysql

Typical error, because it is not so common to include the username in my.cnf configuration file of the mysqld process to run as. If you use the official docker MySQL image to create your configuration file you would not encounter the above error, but if you use an existing (probably old and from non virtualized environment) my.cnf make sure to include the username, which should be used to run the mysqld process as.

Here is our command to execute the container:

docker run --privileged -d -v /mnt/storage/docker/mysql-slave/files:/var/lib/mysql -v /mnt/storage/docker/mysql-slave/etc/my.cnf:/etc/my.cnf mysql/mysql-server:5.6

Gentoo – UnicodeEncodeError: ‘ascii’ codec can’t encode character ‘\xc4’ in position 83: ordinal not in range(128)

Recently emerging package =dev-lang/go-1.13.4 under Gentoo failed on one of our virtual servers with:

--- /usr/lib/go/test/fixedbugs/issue27836.dir/
Traceback (most recent call last):
  File "/usr/lib64/python3.6/site-packages/portage/dbapi/_MergeProcess.py", line 234, in _spawn
    prev_mtimes=self.prev_mtimes, counter=counter)
  File "/usr/lib64/python3.6/site-packages/portage/dbapi/vartree.py", line 1788, in wrapper
    return f(self, *args, **kwargs)
  File "/usr/lib64/python3.6/site-packages/portage/dbapi/vartree.py", line 5385, in merge
    counter=counter)
  File "/usr/lib64/python3.6/site-packages/portage/dbapi/vartree.py", line 4548, in treewalk
    rval = self._merge_contents(srcroot, destroot, cfgfiledict)
  File "/usr/lib64/python3.6/site-packages/portage/dbapi/vartree.py", line 4828, in _merge_contents
    self.settings["EPREFIX"].lstrip(os.sep), cfgfiledict, mymtime):
  File "/usr/lib64/python3.6/site-packages/portage/dbapi/vartree.py", line 5225, in mergeme
    encoding=_encodings['merge'])
  File "/usr/lib64/python3.6/site-packages/portage/util/movefile.py", line 256, in movefile
    selinux.rename(src, dest)
  File "/usr/lib64/python3.6/site-packages/portage/__init__.py", line 246, in __call__
    rval = self._func(*wrapped_args, **wrapped_kwargs)
  File "/usr/lib64/python3.6/site-packages/portage/_selinux.py", line 71, in rename
    os.rename(src, dest)
UnicodeEncodeError: 'ascii' codec can't encode character '\xc4' in position 83: ordinal not in range(128)

>>> Failed to install dev-lang/go-1.13.4, Log file:

>>>  '/var/tmp/portage/dev-lang/go-1.13.4/temp/build.log'

The above log shows that the emerge fails in the installation phase when moving the files to the proper path in the system. The problem there is a non-ASCII character in the file name or path, but the environment is set to use ASCII as language.

The solution is to check if the environment LANG is set and what it contains. In this case, we should set the LANG environment to utf8.

export LANG=en_US.UTF-8

Most of the cases this kind of error could occur with virtual servers, docker (or the other kind of containers like lxc, podman and so on) containers and chroot jails or screens with changed user with su or sudo! In our case, the LANG just got missed because of a switch user procedure in a container and the emerge failed with the above error. When the LANG is missing probably the default value is “C”. In fact, check not only LANG but also the “LC_ALL” environment variable (it may have different value, which is wrong!), which also should be “en_US.UTF-8”:

export LC_ALL=en_US.UTF-8

Or try removing it at all with

unset LC_ALL

Keep on reading!

Build docker image with custom Dockerfile name – docker build requires exactly 1 argument

Docker uses the Dockerfile to build docker images, but what if you want to change the name and (or) the path of this file?
By default “docker build” command uses a file named Dockerfile on the same directory you execute the “docker build“. There is an option to change the path and name of this special file:

  -f, --file string             Name of the Dockerfile (Default is 'PATH/Dockerfile')

And the “-f” may include path and file name but it is mandatory to specify the path at the end “docker build” usually the current directory (context by the docker terminology) by adding “.” (the dot at the end of the command)

So if you want to build with a docker file mydockerfile in the current directory you must execute:

docker build -f mydockerfile .

If your file is in a sub-directory execute:

docker build -f subdirectory/mydockerfile .

The command will create a docker image in your local repository. Here is the output of the first command:

root@srv:~/docker# docker build -f mydockerfile .
Sending build context to Docker daemon  2.048kB
Step 1/3 : FROM ubuntu:bionic-20191029
bionic-20191029: Pulling from library/ubuntu
7ddbc47eeb70: Pull complete 
c1bbdc448b72: Pull complete 
8c3b70e39044: Pull complete 
45d437916d57: Pull complete 
Digest: sha256:6e9f67fa63b0323e9a1e587fd71c561ba48a034504fb804fd26fd8800039835d
Status: Downloaded newer image for ubuntu:bionic-20191029
 ---> 775349758637
Step 2/3 : MAINTAINER test@example.com
 ---> Running in 5fa42bca749c
Removing intermediate container 5fa42bca749c
 ---> 0a1ffa1728f4
Step 3/3 : RUN apt-get update && apt-get upgrade -y && apt-get install -y git wget
 ---> Running in 2e35040f247c
Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Get:2 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB]
Get:3 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Get:4 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
.....
.....
Processing triggers for ca-certificates (20180409) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Removing intermediate container 2e35040f247c
 ---> 2382809739a4
Successfully built 2382809739a4

Here is the image:

REPOSITORY                            TAG                 IMAGE ID            CREATED              SIZE
root@srv:~# docker images
<none>                                <none>              2382809739a4        About a minute ago   186MB

Build command with custom name and registry URL and TAG

root@srv:~# docker build -t gitlab.ahelpme.com:4567/root/ubuntu-project/ubuntu18-manual-base:v0.1 -f mydockerfile .
Sending build context to Docker daemon  2.048kB
Step 1/3 : FROM ubuntu:bionic-20191029
 ---> 775349758637
Step 2/3 : MAINTAINER test@example.com
 ---> Using cache
 ---> 0a1ffa1728f4
Step 3/3 : RUN apt-get update && apt-get upgrade -y && apt-get install -y git wget
 ---> Using cache
 ---> 2382809739a4
Successfully built 2382809739a4
Successfully tagged gitlab.ahelpme.com:4567/root/ubuntu-project/ubuntu18-manual-base:v0.1
root@srv:~# docker push gitlab.ahelpme.com:4567/root/ubuntu-project/ubuntu18-manual-base:v0.1
The push refers to repository [gitlab.ahelpme.com:4567/root/ubuntu-project/ubuntu18-manual-base]
7cebba4bf6c3: Pushed 
e0b3afb09dc3: Pushed 
6c01b5a53aac: Pushed 
2c6ac8e5063e: Pushed 
cc967c529ced: Pushed 
v0.1: digest: sha256:acf42078bf46e320c402f09c6417a3dae8992ab4f4f685265486063daf30cb13 size: 1364

the registry URL is “gitlab.ahelpme.com:4567” and the project path is “/root/ubuntu-project/” and the name of the image is “ubuntu18-manual-base” with tag “v0.1“. The build command uses the cache from our first build example here (because the docker file is the same).

Typical errors with “-f”

Two errors you may encounter when trying the “-f” to change the name of the default Dockerfile name:

$ docker build -t gitlab.ahelpme.com:4567/root/ubuntu-project/ubuntu18-manual-base:v0.1 -f mydockerfile subdirectory/
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /builds/dev/docker-containers/mydockerfile: no such file or directory

$ docker build -t gitlab.ahelpme.com:4567/root/ubuntu-project/ubuntu18-manual-base:v0.1 -f subdirectory/mydockerfile
"docker build" requires exactly 1 argument.
See 'docker build --help'.

Usage:  docker build [OPTIONS] PATH | URL | -

First, you might think the -f would take the path and file name and this should be enough, but the errors above appears!

Our example Dockerfile

This is our simple example docker file:

FROM ubuntu:bionic-20191029
MAINTAINER test@example.com

RUN apt-get update && apt-get upgrade -y && apt-get install -y git wget

We are using the official docker image from Ubuntu. Always use official docker images!

bonding – write error – device or resource busy – operation not permitted

Recently, there was a little bit of confusion when following the article about activating network bonding without ifenslave – How to enable Linux bonding without ifenslave. At first, there were couple of errors:

livecd ~ # echo balance-alb > /sys/class/net/bond0/bonding/mode
-bash: echo: write error: Device or resource busy
livecd ~ # echo "+enp129s0f0" > /sys/class/net/bond0/bonding/slaves
-bash: echo: write error: Operation not permitted

Or similar error when changing the bonding mode:

livecd ~ # echo 4 > /sys/class/net/bond0/bonding/mode
-bash: echo: write error: Directory not empty
livecd ~ # echo 802.3ad > /sys/class/net/bond0/bonding/mode
-bash: echo: write error: Directory not empty

The server just booted in rescue live cd and there is no active network configuration:

SCREENSHOT 1) Apparently, the /sys/class/net/bond0/bonding/mode and /sys/class/net/bond0/bonding/slaves are in read only state.

No writes means no new configuration could be installed and the bonding cannot be configured (reconfigured).

main menu
device or resource busy – operation not permitted

Bonding mode could be changed only when the bonding device is in DOWN state.

Network interfaces could be added to the boding device only if they were in DOWN state, too.

In addition, changing bonding mode could only happen if there were no network interfaces added to the bonding interface.

Keep on reading!

Cobbler web – AppRegistryNotReady – Apps aren’t loaded yet

If you happen to use Cobbler 2.6 (even the last release of 2.6 – 2.6.11) you may encounter the following error when you try loading the Cobbler web interface:

AppRegistryNotReady at /distro/list

Apps aren't loaded yet.

Request Method: 	GET
Request URL: 	https://192.168.0.25/cobbler_web/distro/list
Django Version: 	1.8.7
Exception Type: 	AppRegistryNotReady
Exception Value: 	

Apps aren't loaded yet.

Exception Location: 	/usr/lib/python2.7/dist-packages/django/apps/registry.py in check_apps_ready, line 124
Python Executable: 	/usr/bin/python
Python Version: 	2.7.12
Python Path: 	

['/usr/local/share/cobbler/web/cobbler_web',
 '/usr/local/share/cobbler/web',
 '/usr/lib/python2.7',
 '/usr/lib/python2.7/plat-x86_64-linux-gnu',
 '/usr/lib/python2.7/lib-tk',
 '/usr/lib/python2.7/lib-old',
 '/usr/lib/python2.7/lib-dynload',
 '/usr/local/lib/python2.7/dist-packages',
 '/usr/lib/python2.7/dist-packages']

Server time: 	Sun, 13 Oct 2019 21:24:30 -0400

The Cobbler web does not work properly. The Django application is not started properly.

main menu
Cobbler web – web error

It is a known error and it is easily fixable by editing the Cobbler web source file “/usr/local/share/cobbler/web/cobbler.wsgi” (or /usr/share/cobbler/web/cobbler.wsgi) and replacing the two lines:

    import django.core.handlers.wsgi
    _application = django.core.handlers.wsgi.WSGIHandler()

With the code:

    from django.core.wsgi import get_wsgi_application
    _application = get_wsgi_application()

Note the “_application” variable starts with underline.

In fact, Cobbler 2.4 has the same issue, but the variable is “application” without underline in the start and there is no return line at the end of the file (in 2.6 there is a return clause and you must leave it there!)

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

replace with

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

It is highly unlikely to use Cobbler 2.4, but still, if you need it and you come across this page this is the fix for the Cobbler web and be careful with the variable name _applicationapplication for the various Cobbler versions.

nano – Error opening terminal: unknown under chroot or (docker) container

A quick tip for GNU Nano – the text editor. Ever receiving the terminal error when using nano?

[root@srv ~]# nano                                                        
Error opening terminal: unknown.
[root@srv ~]#

Under chroot or container (like docker) environment try exporting the TERM environment:

export TERM=linux

And then execute nano the chances are you will enter nano normally and do your work (faster than vim 🙂 )?

You may use it without exporting to your shell, but just the for the nano:

TERM=linux nano

cobbler import – stderr file: No such file or directory

What a miss here in our docker Cobbler instance! When trying to import a new distro in Cobbler the import finished with failed task and multiple errors of:

running: /usr/bin/file /var/www/cobbler/ks_mirror/ubuntu-18.04.3-server-amd64-x86_64/dists/bionic/Release.gpg
received on stdout: 
received on stderr: /bin/sh: /usr/bin/file: No such file or directory

running: /usr/bin/file /var/www/cobbler/ks_mirror/ubuntu-18.04.3-server-amd64-x86_64/dists/bionic/main/binary-i386/Release
received on stdout: 
received on stderr: /bin/sh: /usr/bin/file: No such file or directory

The “file”? Apparently, the Linux file command is missing and it is just possible because it is a docker container with the minimum installation of packages and dependencies.

Without the “file” command import will fail with “No signature matched” even you have synced with the latest signature just before the execution of the import command.

Install the package “file” in your server.
CentOS 7/Fedora:

yum install -y file

Ubuntu

apt install -y file

Keep on reading!

cobbler – The SECRET_KEY setting must not be empty.

When installing cobbler (in our case 2.6.11, but it might happen with other versions) from source, because they do not offer binary packages anymore, the web showed this error:

[Tue Oct 08 07:41:00.680646 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] mod_wsgi (pid=8770): Exception occurred processing WSGI script '/usr/local/share/cobbler/web/cobbler.wsgi'.
.....
.....
[Tue Oct 08 07:41:00.687544 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] ImproperlyConfigured: The SECRET_KEY setting must not be empty.

The solution is simply to add value to the variable SECRET_KEY in file “/usr/local/share/cobbler/web/settings.py” (this file might be in /usr/share/cobbler/web/settings.py)

root@srv:~# grep -n SECRET_KEY /usr/local/share/cobbler/web/settings.py
39:SECRET_KEY = ''

The 39th line put a randomly generated text. You may use openssl to generate the random text like:

root@srv:~# openssl rand -base64 32
NVb09/5TWmCcqfDBLsvyCppza9lJ5Eyb0HWW4HTlSfo=

Edit the cobbler web setting file and put the string there:

root@srv:~# grep SECRET_KEY /usr/local/share/cobbler/web/settings.py
SECRET_KEY = 'NVb09/5TWmCcqfDBLsvyCppza9lJ5Eyb0HWW4HTlSfo='

The whole output error in the apache logs

The error could be seen in Cobbler web installed in Ubuntu 16 when installing cobbler 2.6.11.

[Tue Oct 08 07:41:00.680646 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] mod_wsgi (pid=8770): Exception occurred processing WSGI script '/usr/local/share/cobbler/web/cobbler.wsgi'.
[Tue Oct 08 07:41:00.680724 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] Traceback (most recent call last):
[Tue Oct 08 07:41:00.680764 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]   File "/usr/local/share/cobbler/web/cobbler.wsgi", line 27, in application
[Tue Oct 08 07:41:00.681890 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]     return _application(environ, start_response)
[Tue Oct 08 07:41:00.682025 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]   File "/usr/lib/python2.7/dist-packages/django/core/handlers/wsgi.py", line 170, in __call__
[Tue Oct 08 07:41:00.683222 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]     self.load_middleware()
[Tue Oct 08 07:41:00.683380 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]   File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 49, in load_middleware
[Tue Oct 08 07:41:00.685006 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]     for middleware_path in settings.MIDDLEWARE_CLASSES:
[Tue Oct 08 07:41:00.685168 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]   File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 48, in __getattr__
[Tue Oct 08 07:41:00.686783 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]     self._setup(name)
[Tue Oct 08 07:41:00.687047 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]   File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 44, in _setup
[Tue Oct 08 07:41:00.687111 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]     self._wrapped = Settings(settings_module)
[Tue Oct 08 07:41:00.687133 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]   File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 113, in __init__
[Tue Oct 08 07:41:00.687472 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793]     raise ImproperlyConfigured("The SECRET_KEY setting must not be empty.")
[Tue Oct 08 07:41:00.687544 2019] [wsgi:error] [pid 8770:tid 140654161590016] [remote 192.168.0.250:5793] ImproperlyConfigured: The SECRET_KEY setting must not be empty.