Gentoo – updating perl and problems like perl-core/ is blocking virtual/perl-

When upgrading Perl under Gentoo it’s almost typical to have blocks of the kind:

[blocks B      ] <perl-core/File-Path-2.160.0 ("<perl-core/File-Path-2.160.0" is blocking virtual/perl-File-Path-2.160.0)
[blocks B      ] <perl-core/Module-CoreList-5.201.905.220 ("<perl-core/Module-CoreList-5.201.905.220" is blocking virtual/perl-Module-CoreList-5.201.905.220)
[blocks B      ] <perl-core/Archive-Tar-2.320.0 ("<perl-core/Archive-Tar-2.320.0" is blocking virtual/perl-Archive-Tar-2.320.0)

These blocks appeared when we tried updaring the Perl 5.26 to 5.30 (dev-lang/perl-5.30.0:0/5.30::gentoo from dev-lang/perl-5.26.2:0). This update is a major update.
So what does it mean?
The virtual package and the perl-core package should be the same version, but it appears there are no corresponding same versions to the virtual package versions (). The problem is that the update depends on a newer version of File-Path, Module-CoreList, and Archive-Tar but there are only virtual packages with the required versions. Virtual packages are just meta-packages and they do not install any module. First, what are the virtual/[perl-module] and perl-core/[perl-module]:

  • perl-core/[perl-module] – perl independent modules. In fact, the same module may be independent and it may be part of the build-in packages from the Perl main package – dev-lang/perl. Sometimes you may choose the independent package, because of a newer version than the version included in the dev-lang/perl package.
  • virtual/[perl-module] – perl meta-package, which ensures the installation of the module. The module could be an independent package from above or module, which is included in the main Perl package (in dev-lang/perl)

To solve the blocks of this kind “perl-core/ is blocking virtual/perl-” you must check for a newer version of perl-core/* if there is no newer version, just to remove the package and let the setup (emerge) use the module included in dev-lang/perl.

In our case, there are no newer versions of the three packages and we remove them with:

emerge -Cv perl-core/File-Path perl-core/Module-CoreList perl-core/Archive-Tar

And then emerge with no problems the new version of Perl with:

emerge --verbose --verbose-conflicts --backtrack=200000 $(qlist -IC|grep perl|sort|uniq) media-gfx/inkscape media-gfx/imagemagick dev-php/pecl-imagick

For detail explaination of why we use verbose-conflicts, backtrack, qlist and three excplicitly added packages you may read our article on similar subject – Gentoo updating perl with many masked and blocked packages
You may read the offcial documentation for more information – https://wiki.gentoo.org/wiki/Perl#Introduction

Updating our Perl from dev-lang/perl-5.26.2:0 to dev-lang/perl-5.30.0:0/5.30

Keep on reading!

Install Cobbler 2.6 under Ubuntu 16.04 LTS from Cobbler source – manual intallation

This article will show how to install Cobbler 2.6.11 (the last from the 2.6 branches) under Ubuntu 16.04 LTS. There is Cobbler package version 2.4.x in the Ubuntu 16 LTS, but Cobbler 2.4 is really old and some options and features are not available anymore, so installing from the Ubuntu package system Cobbler 2.4 would probably just waste your time and you will move to 2.6 or even later. In fact, Ubuntu 18 LTS removed the Cobbler packages at all and only manual install (aka installation from sources is only available or from an anonymous repository like PPA).
Here are the steps to install a working Cobbler 2.6 under Ubuntu 16.04 (Xenial Xerus).

Note: All commands are executed as root user, so it is much easier to just execute ones “sudo su” before you begin following the steps below.

STEP 1) Update your system to the latest state and install the Cobbler 2.6.11 dependencies

Update the system:

apt update
apt upgrade -y

Install the Cobbler 2.6 dependencies:

apt install -y make git python-yaml python-cheetah python-netaddr python-simplejson libapache2-mod-wsgi python-django atftpd debmirror apache2 python-urlgrabber fence-agents isc-dhcp-server

STEP 2) Download and install the Cobbler 2.6.11 source

cd /root
wget https://github.com/cobbler/cobbler/archive/v2.6.11.tar.gz
tar xf v2.6.11.tar.gz
cd cobbler-2.6.11
make install

This will install Cobbler and Cobbler web by replacing all configurations of old Cobbler install! The python files will be installed under “/usr/local”, so a big part of Cobbler will be installed in /usr/local/lib/python2.7/dist-packages/cobbler.

STEP 3) Enable Cobbler in apache2

a2enconf cobbler cobbler_web
a2enmod proxy proxy_http rewrite ssl
a2ensite default-ssl
systemctl enable apache2

Enable apache2 configuration file for cobbler web, enable the apache2 modules and the default HTTPS apache2 virtual host, because the web interface won’t work with HTTP. Opening the Cobbler web interface using HTTP will result in forbidden error (HTTP error 403). The Cobbler web interface is limited to use HTTPS.
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.

Technical details of a default CentOS 8.0.1950 minimal installation

This article is for those of you who do not want to install a whole new operating system only to discover some technical details about the default installation like disk layout, packages included, software versions and so on. Here we are going to review in several sections what is like to have a default installation of CentOS 8.0.
Despite the kernel is 4.18 it detects successfully the new RYZEN/Threadripper AMD and the system is stable (we booted in UEFI mode).

Software

The CentOS 8.0 (8.0.1950) you can have

  • linux kernel – 4.18.0 (4.18.0-80.7.1.el8_0.x86_64)
  • Graphical User Interface
    • Xorg X server – 1.20.3
    • GNOME (the GUI) – 3.28.2
    • K Desktop Environment – NO, it’s depricated and not included in the release.
  • System
    • linux-firmware – version: 20190111, release: 92.gitd9fb2ee6.el8.
    • QT – 5.11.1
    • libc – 2.28
    • GNU GCC – 8.2.1
    • OpenSSL – 1.1.1
    • coreutils – 8.30
    • yum – Depricated and replaced with dnf
    • dnf – 4.0.9.2
    • cups – 2.2.6
    • rsyslog – 8.37.0
  • Servers
    • Apache – 2.4.37
    • Nginx – 1.14.1
    • MySQL server – 8.0.13
    • MariaDB server – 10.3.11
    • PostgreSQL – 10.6
  • Programming
    • PHP – 7.2.11
    • python – 2.7.15 and also includes 3.6.8
    • perl – 5.26.3
    • ruby – 2.5.3
    • OpenJDK – 11.0.4.11 and also includes 1.8.0.222.b10
    • Go – 1.11.5
    • Rust – 1.31.0
    • Subversion – 1.10.2
    • Git – 2.18.1

Note: Not all of the above software comes installed by default.
The installation procedure you can find here – How to do a network installation of CentOS 8 (8.0.1950) – minimal server installation Minimal install with “Standard” Addons selected.
Installed packages are 547 occupying 1.8G space:.

[root@srv ~]# dnf list installed|wc -l
547
[root@srv ~]# df -h /
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/cl_srv-root   50G  1.8G   49G   4% /

Note: if you do not select “Standard Addon” the installation occupies less space – 1.6Gbytes and installs only 397 packages.
Keep on reading!

emerge – ERROR: 17.1 migration has not been performed – upgrade from 13 to 17.1

When upgrading to 17.1 profile you need to perform additional steps to get to a healthy Gentoo portage system using profile 17.1.
Here what we stumbled when we tried to upgrade from 13 to 17.1:

>>> Emerging (1 of 3) dev-libs/elfutils-0.177::gentoo
 * Fetching files in the background.
 * To view fetch progress, run in another terminal:
 * tail -f /var/log/emerge-fetch.log
 * elfutils-0.177.tar.bz2 BLAKE2B SHA512 size ;-) ...                                                                                                                [ ok ]
 * Please follow the instructions in the news item:
 * 2019-06-05-amd64-17-1-profiles-are-now-stable
 * or choose the 17.0 profile.
 * ERROR: dev-libs/elfutils-0.177::gentoo failed (setup phase):
 *   ERROR: 17.1 migration has not been performed!!
 * 
 * Call stack:
 *        ebuild.sh, line 591:  Called __source_all_bashrcs
 *        ebuild.sh, line 410:  Called __try_source '/usr/portage/profiles/default/linux/amd64/17.1/profile.bashrc'
 *        ebuild.sh, line 467:  Called __qa_source '/usr/portage/profiles/default/linux/amd64/17.1/profile.bashrc'
 *        ebuild.sh, line 112:  Called source '/usr/portage/profiles/default/linux/amd64/17.1/profile.bashrc'
 *   profile.bashrc, line   6:  Called die
 * The specific snippet of code:
 *              die "ERROR: 17.1 migration has not been performed!!"
 * 
 * If you need support, post the output of `emerge --info '=dev-libs/elfutils-0.177::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-libs/elfutils-0.177::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/dev-libs/elfutils-0.177/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-libs/elfutils-0.177/temp/die.env'.
 * Working directory: '/var/tmp/portage/dev-libs/elfutils-0.177/homedir'
 * S: '/var/tmp/portage/dev-libs/elfutils-0.177/work/elfutils-0.177'

As you can see there is news, which consists of 12 steps to perform a successful upgrade to profile 17.1.
You can read the news with (the news output is included at the end of this article, just for completeness):

eselect news read 28

Specific note for our upgrade – in fact, our Gentoo installation was a chroot and it had not been updated for three years. The profile was 13.0 and portage supported only EAPI 5, which is a real problem. The new portage tree (we installed the latest) has no profile 13.0 and our emerge was half broken. We have preliminary steps described in Failed to install sys-apps/portage – Called pkg_preinst – portage._compat_upgrade.default_locations

Because we upgrade from 13.0 to 17.1, first, we need to perform the 17.0 upgrade (check the original steps here – https://gentoo.org/support/news-items/2017-11-30-new-17-profiles.html)

STEP 1) Select the previous profile 17.0 temporarily.

srv ~ # eselect profile set default/linux/amd64/17.0

You won’t be able to build any GNU GCC and you cannot continue with the next step.

STEP 2) Upgrade to GNU GCC 6.4.0 or later.

Our current GNU GCC is really old – 4.9.3. The latest version is gcc-9.2.0-r1 and we are going to use it.
Keep on reading!

cobbler – DisallowedHost: Invalid HTTP_HOST header: ”. You may need to add u” to ALLOWED_HOSTS.

Cobbler web (probably not the latest) uses Django and since version 1.5 (IIUC) if your IP is not in an allowed host directive – ALLOWED_HOSTS you will get 400 and the following apache errors:

[Mon Jan 14 13:44:27.805290 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] mod_wsgi (pid=5897): Exception occurred processing WSGI script '/usr/share/cobbler/web/cobbler.wsgi'.
.....
.....
[Mon Jan 14 13:44:27.805743 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] DisallowedHost: Invalid HTTP_HOST header: '192.168.0.25'. You may need to add u'192.168.0.25' to ALLOWED_HOSTS.

The solution is simple enough – add your host in the ALLOWED_HOSTS.

But where? In which cobbler configuration file?

Find the cobbler web setting file and add a line for ALLOWED_HOSTS.

In Ubuntu the file is “/usr/share/cobbler/web/settings.py” and add the following:

DEBUG = True
TEMPLATE_DEBUG = DEBUG

ALLOWED_HOSTS = '*'

ADMINS = (
    # ('Your Name', 'your_email@domain.com'),
)

This will instruct Django to accept requests from all IPs. Now Cobbler web will work.

The whole output error in the apache logs

The error could be seen in Cobbler web installed in Ubuntu 16 with the latest package cobbler-web 2.4.1-0ubuntu2.

[Mon Jan 14 13:44:27.805290 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] mod_wsgi (pid=5897): Exception occurred processing WSGI script '/usr/share/cobbler/web/cobbler.wsgi'.
[Mon Jan 14 13:44:27.805360 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] Traceback (most recent call last):
[Mon Jan 14 13:44:27.805381 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/core/handlers/wsgi.py", line 189, in __call__
[Mon Jan 14 13:44:27.805420 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     response = self.get_response(request)
[Mon Jan 14 13:44:27.805429 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 207, in get_response
[Mon Jan 14 13:44:27.805442 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     return debug.technical_500_response(request, *sys.exc_info(), status_code=400)
[Mon Jan 14 13:44:27.805449 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/views/debug.py", line 97, in technical_500_response
[Mon Jan 14 13:44:27.805463 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     html = reporter.get_traceback_html()
[Mon Jan 14 13:44:27.805470 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/views/debug.py", line 384, in get_traceback_html
[Mon Jan 14 13:44:27.805480 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     return t.render(c)
[Mon Jan 14 13:44:27.805487 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 210, in render
[Mon Jan 14 13:44:27.805499 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     return self._render(context)
[Mon Jan 14 13:44:27.805505 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 202, in _render
[Mon Jan 14 13:44:27.805516 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     return self.nodelist.render(context)
[Mon Jan 14 13:44:27.805523 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 905, in render
[Mon Jan 14 13:44:27.805533 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     bit = self.render_node(node, context)
[Mon Jan 14 13:44:27.805551 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/debug.py", line 79, in render_node
[Mon Jan 14 13:44:27.805563 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     return node.render(context)
[Mon Jan 14 13:44:27.805569 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/defaulttags.py", line 329, in render
[Mon Jan 14 13:44:27.805582 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     return nodelist.render(context)
[Mon Jan 14 13:44:27.805589 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 905, in render
[Mon Jan 14 13:44:27.805602 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     bit = self.render_node(node, context)
[Mon Jan 14 13:44:27.805609 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/debug.py", line 79, in render_node
[Mon Jan 14 13:44:27.805621 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     return node.render(context)
[Mon Jan 14 13:44:27.805627 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/debug.py", line 89, in render
[Mon Jan 14 13:44:27.805639 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     output = self.filter_expression.resolve(context)
[Mon Jan 14 13:44:27.805647 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 648, in resolve
[Mon Jan 14 13:44:27.805657 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     obj = self.var.resolve(context)
[Mon Jan 14 13:44:27.805663 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 789, in resolve
[Mon Jan 14 13:44:27.805673 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     value = self._resolve_lookup(context)
[Mon Jan 14 13:44:27.805679 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/template/base.py", line 849, in _resolve_lookup
[Mon Jan 14 13:44:27.805689 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     current = current()
[Mon Jan 14 13:44:27.805696 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/http/request.py", line 152, in build_absolute_uri
[Mon Jan 14 13:44:27.805708 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     host=self.get_host(),
[Mon Jan 14 13:44:27.805714 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]   File "/usr/lib/python2.7/dist-packages/django/http/request.py", line 102, in get_host
[Mon Jan 14 13:44:27.805725 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685]     raise DisallowedHost(msg)
[Mon Jan 14 13:44:27.805743 2019] [wsgi:error] [pid 5897:tid 139760386561792] [remote 192.168.0.250:44685] DisallowedHost: Invalid HTTP_HOST header: '192.168.0.25'. You may need to add u'192.168.0.25' to ALLOWED_HOSTS.

How to do a network installation of CentOS 8 (8.0.1950) – minimal server installation

Minimal net install is useful when a dedicated server is installed from a IPMI KVM or Dell iDRAC, HP iLO, IBM IMM or where the initial client side download of files need to be minimal.
For amd64 CentOS 8 BaseOS the net install bootable media is located here (now the current latest release is 8.0.1950, but you can check the last directory with 8. for the time you follow this howto):

http://mirror.leaseweb.com/centos/8/isos/x86_64/CentOS-8-x86_64-1905-boot.iso

Note there is no minimal CD for offline installation anymore. Boot CD is to just boot and make “netinstall” installation and a big fat DVD of 6.6Gbytes to install offline.
Software details of CentOS 8 minimal install could be found here – Technical details of a default CentOS 8.0.1950 minimal installation

Download it and put it on a cd or usb, the boot from it and follow the steps bellow:

STEP 1) Enter the BIOS of your machine (desktop or server) to change the boot order.

You can try F11 on most servers to have the boot menu. Here we use DEL to enter the UEFI BIOS.

main menu
Enter BIOS – change boot order

Keep on reading!