Always put your root partition separate from the storage (aka data) partitions. root partition should be only for system files and nothing more! Keeping this simple rule you may easily change your operating system (or clean install or clean upgrade) without deleting the user’s data thus preserving the old storage partitions.
Our storage has 2 storage partitions, which means they hosts only data and no system files and there are separate partitions for Linux booting (grub2) and system files (root partition). Here is the partitions layout:
Of course, when there are partitions above 2T the GPT is mandatory.
You can skip the software RAID1 setup if you use only one controller or you have system partitions only in one disk (virtual drive and so on). Here we have two hardware controllers, which we want to use both for the system partitions.
4 RAID1 devices:
EFI partition (/boot/efi)
boot parition (/boot)
root partition (/)
The best practice is have total between 30G and 50G for the 4 partitions (in fact, boot partition could be skipped). Have in mind most modern Linux distributions cannot be installed on less than 10G~20G and for optimal results just separate between 30G and 50G for 4 partitions above (or 3 if you choose to skip the boot one).
Upgrade to CentOS 8 with clean install over our old CentOS 7 system partitions preserving the big data partitions.
Couple of things before start:
UEFI installation will be selected. So boot in UEFI mode.
IPMI KVM is used to install the new Linux distribution – CentOS 8
This article is a howto install of the official docker gitlab-ce (GitLab Community Edition). GitLab maintains a docker image in the Docker registry and this is the best way to install GitLab.
In this article you are going to learn how:
to install the GitLab CE in docker
to enable HTTPS (SSL) web support to your GitLab
to enable the docker registry functionality of GitLab
To install GitLab docker image in your Linux distribution all you need is a working docker environment and started docker daemon. As you know, installing software with docker will allow you to keep your main system clean and let you use a fined tuned installation from the official developer (creator). As mentioned already, the GitLab maintains an official GitLab image in the Docker Registry so you may expect everything to work smoothly and better than if you make an installation in a clean Linux distribution like CentOS, Ubuntu and so on. In this article, we will include the most important docker commands to control and configure the GitLab docker container and even if you are not familiar with the Docker software they are simple enough to use them and prefer this method over GitLab normal installation.
GitLab has integrated the Docker Container Registry in GitLab Container Registry and now with GitLab you can have a local Docker registry containing all project’s docker images!
Just to note, the Docker Registry is the place for the Docker (aka Linux) images.
Using GitLab Container Registry with CI/CD (continuous integration and continuous delivery) you can create automatically test, staging, development and production docker images. Keep on reading!
Preparing the preseed for unattended installation sometimes could be challenging. This article presents the right way to analyze an installation failure in one of the main steps – “select and install software”.
There is a ubuntu installation preseed file for our Bionic unattended installation, which uses the “pkgsel” to install first packages in the new system:
When an installation step in the preseed of a unattended installation fails the setup stops with a “Continue” confirmation.
Here is what you can do to check what exactly fails in step “select and install software”:
Start a shell in the current installation boot. Press “Ctrl+Alt+F2” to start the shell. You may use “Ctrl+Alt+F3” and “Ctrl+Alt+F4” for two more consoles and “Ctrl+Alt+F1” to return to the installation wizard.
Check the /var/log/syslog, in which file the debconf writes the logging information.
Find the lines where the step “select and install software” starts and look for errors after that. In this file, you can see all the step titles during, which the setup passes and they are named the same way the windows’ titles during the installation wizard.
Here is the real world output
Presing the “CTRL+ALT+F2” to start the BusyBox built-in shell, which is ash not bash!
Be careful there are some difference between ash and bash.
Last 20 lines shows the problem – pkgsel failed to install packages in step “select and install software”.
The installation wizard stops.
The problem is in the package “ntp”, the setup cannot install the “ntp” package because of unmet dependencies.
Because it is not so important to install ntp at this stage we added the package to the script executed in “preseed/late_command” and removed the package from the pkgsel line in the preseed file. In general, our problem was because we set local repositories for the bionic packages, but the setup cannot update list of available packages when the you set Bionic mirror to be unofficial local repository.
This article shows what files to add if you want to add a bonding interface under CentOS 8 without invoking the Network manager command utility.
Our goal is to use one boding group with the name bond0 in LACP (aka 802.3ad) mode (but it could be any of the other types) with two networks 10Gbps interfaces. The setup resented here uses NetworkManager, which handles the loading of bonding module properly.
In fact, the network-scripts are now deprecated and they are missing from the system (but they still exist in the additional package – “network-scripts”, how knows till when? do not rely on them!).
The configuration files are with the same syntax as under CentOS 7, but this time the network manager parses them. The ifup and ifdown still exist and they just call the Network manager when executed (unless the “network-scripts” package is installed). If you need to enable bonding without any configuration files (for emergency situations) you may still use – How to enable Linux bonding without ifenslave
What do you need:
Ensure you have installed: “iputils” and “NetworkManager” packages
This article is how to install aptly software, which offers easy Debian repository management.
First, few words for aptly and what tasks are really simple to do:
Mirror an existing (remote) repository. Make a local copy of Debian or Ubuntu repostories for all your internal infrastructure.
Create your own repositories
Create snapshots of repositories and mirrors.
Make diff between repositories (in fact snapshots of repositories, but you may make a mirror of an repository and then make a snapshot and then make a diff with some other snapshot to see the changes between the different repositories or the time the snapshots are made).
Remove or add individual packages from official mirrored repositories.
Use api calls to manage the repositories. HTTP REST API is still in development, but a big part of it works.
We are going to install the aptly and despite it could be used to serve the repository files we will use the Nginx web server for this work. Nginx is a more fast and reliable web server with easy installation of SSL certificates for our repositories.
The aptly is included in official Ubuntu repositories in the component universe, but at present, it is 2 to 3 versions behind the stable one from the aptly site, so we are going to use their repository to install aptly. Still, if you do not want to use Keep on reading!
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:
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
STEP 2) Download and install the Cobbler 2.6.11 source
tar xf v2.6.11.tar.gz
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.
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!
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!)
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 _application – application for the various Cobbler versions.