CentOS

Knowing and managing CentOS background services

Linux system services are one of the most fundamental concepts of every Linux server. They are programs which run continuously in your system, waiting for external events to process something or do it all the time. Normally, when working with your server, a system user will not notice the existence of such a running service because it is running as a background process and is therefore not visible. There are many services running all the time on any Linux server. These can be a web server, database, FTP, SSH or printing, DHCP, or LDAP server to name a few. In this, we will show you how to manage and work with them.

To Start With: What Do You Need?

The Process

systemctl is a program that we will use to manage all our background service tasks in a CentOS 7 system. Here, we will show you how to use it, taking the Apache web server serves as an example in order to get familiar with it.

First, we log in as root and install the Apache web server package:
yum install httpd
Next we will check Apache’s service status:
systemctl status httpd.service
Start the web server service in the background and print out its status again:
systemctl start httpd.service systemctl status httpd.service
Next, let’s print out a list of all services currently running in the background of your system; in this list, you should identify the httpd service you just started:
systemctl -t service -a --state running
Now, let’s make a backup of the Apache configuration file:
cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.BAK
Now, we will make some changes to the main Apache configuration file using sed:
sed -i 's/Options Indexes FollowSymLinks/Options -Indexes +FollowSymLinks/g' /etc/httpd/conf/httpd.conf
Now, type the following command to stop and start the service and apply our changes:
systemctl stop httpd.service systemctl start httpd.service systemctl status httpd.service
Next, let’s enable the httpd service to start automatically at boot time:
systemctl enable httpd.service
The last command will show how to restart a service:
systemctl restart httpd.service

How it works…

As we have seen, the systemctl utility can be used to take full control of your system’s services. The systemctl is the control program for systemd, which is the system and service manager in CentOS 7 Linux. The systemctl command can be used for a variety of other tasks as well, but here we concentrate on managing services.

So, what have we learned from this experience?

We started this process by logging in as root and installed the Apache web server package as we want to use it for showing how to manage services in general using the systemctl program. Apache or the httpd.service, as it is called by systemd, is just an example we will use; other important services that might be running in a basic server environment could be sshd.service, mariadb.service, crond.service, and so on. Afterward, we checked httpd’s current status with the systemctl status command parameter. The output showed us two fields: Loaded and Active. The Loaded field tells us if it is currently loaded and if it will automatically be started at boot time; the Active field denotes whether the service is currently running or not. Next, we showed how to start a service using systemctl. The command’s exact starting syntax for services is the systemctl start .service.

Note

By starting a service, the program gets detached from the terminal by forking off a new process that gets moved into the background where it runs as a non-interactive background process. This is sometimes called daemon.

Next, after we started the Apache webserver daemon, we then used systemctl’s status parameter again to show how the status changes if we run it. The output shows us that it is currently loaded but disabled on reboot. We also see that it is running, along with the latest logging output from this service and other detailed information about the process. To get an overview of all status information for all services on the system, use systemctl -type service --all.A systemctl service must not be running all the time. Its state can also be stopped, degraded, maintained, and so on. Next, we used the following command to get a list of all currently running services on your system:

systemctl -t service -a --state running

As you can see here, we used the -t flag in order to filter only for type service units. As you may guess, systemctl can not only deal with service units but also with a lot of other unit types. systemd units are resources systemd can manage using configuration files, and which encapsulate information about services, listening sockets, saved system state snapshots, mounting devices, and other objects that are relevant to the system. To get a list of all possible unit types, type systemctl -t help. These configuration unit files reside in special folders in the system, and the type they belong to can be read from the extension; all the service unit files have the file extension, .service (for example, device unit files have the extension, .device). There are two places where the system stores them. All the systemd unit files installed by the basic system during installation are in /usr/lib/systemd/system, all other services that come from installing packages such as Apache or for your own configurations should go to /etc/systemd/system. We can find our Apache service configuration file exactly at /usr/lib/systemd/system/httpd.service. Next, we showed the user how to stop a service, which is the opposite of starting it, using the syntax, systemctl stop . Finally, as a last step, we used systemctl’s restart parameter, which just handles the stopping and starting of service in one step with less typing. This is often useful if a service hangs and is unresponsive, and you quickly need to reset it to get it working. Before showing how to stop and restart a service, we did another important thing. While the Apache service was running, we changed its main service configuration file with the sed command, adding an -Indexes option that disables the directory web site file listings, and which is a common measure to increase the security of your web server. Since the Apache web server was already running and loading its configuration into memory during service startup, any changes to this file will never be recognized by the running service.

Note
Normally, to apply any configuration file change, running services need a full-service restart, because configuration files will normally only be loaded during startup initialization.

Now, imagine that your web server is reachable from the Internet and at the moment there are a lot of people accessing your web pages or applications in parallel. If you restart the Apache normally, the web server will be inaccessible for a while (as long as it takes to restart the server) as the process will actually end and afterward start all over again. All the current users would get HTML 404 error pages if they were to request something at that moment. Also, all the current session information would have gone; imagine you have an online webshop where people use shopping carts or logging in. All this information would also be gone. To avoid the disruption of important services such as the Apache web server, some of these services have a reload option (but not every service has this feature!) that we can apply instead of the restart parameter. This option just reloads and applies the service’s configuration file, while the service itself stays online and does not get interrupted during execution. For Apache, you can use the following command-line: systemctl reload httpd.service. To get a list of all the services that have the reload functionality, use the following lines:
grep -l "ExecReload" /usr/lib/systemd/system/*.service /etc/systemd/system/*.service

So, having completed this recipe, we can say that we now know how to work with the basic systemctl parameters to manage services. It can be a very powerful program and can be used for much more than only starting and stopping services. Also, in this recipe, we have used different names that all mean the same: system service, background process, or daemon.

There's more…

There is another important unit type called target. Targets are also unit files and there are quite a number of them already available in your system. To show them, use the following:
ls -a /usr/lib/systemd/system/*.target /etc/systemd/system/*.target

Simply said, targets are collections of unit files such as services or other targets. They can be used to create runlevel-like environments, which you may know from earlier CentOS versions. Runlevels define which services should be loaded at which system state. For example, there is a graphical state or a rescue mode state, and so on. To see how the common runlevels correspond to our targets, run the following command, which shows us all the symbolic links between them:
ls -al /lib/systemd/system | grep runlevel

Targets can be dependent on other targets; to get a nice overview of target dependencies, we can run the following command to show all dependencies from the multi-user target to all the other targets (green means active and red means inactive):
systemctl list-dependencies multi-user.target

You can show the current target that we are in at the moment with:
systemctl get-default

You can also switch to another target:
systemctl set-default multi-user.target

Creating CentOS USB installation media on Windows or OS X

Here in this process, we will learn how to create a USB installation media on Windows or OS X. Nowadays, more and more server systems, desktop PCs, and laptops get shipped without an optical drive. Installing a new operating system, such as CentOS Linux using USB devices gets essential for them as no other installation option is available, as there is no other way to boot the installation media. Also, installing CentOS using USB media can be considerably faster than using the CD/DVD approach.

To Start With: What Do You Need?

Before we begin, it is assumed that you have followed the previous process in which you were shown how to download a minimal CentOS image and confirm the checksum of the relevant image files. It is also assumed that all the downloads (including the downloaded ISO file) are stored on Windows in your C:\Users\\Downloads folder or if using an OS X system, in the /Users//Downloads folder. Next, you will need a free USB device which can be discovered by your operating system, with enough total space, and which is empty or with data on it that can be discarded. The total space of the USB device needed for preparing as an installation media for CentOS 7 for the minimal version must be roughly 700 megabytes. If you are working on a Windows computer, you will need a working Internet connection to download additional software. On OS X, you need an administrator user account.

The Process

To initiate this process, start up your Windows or OS X operating system, then connect a free USB device with enough capacity, and wait until it gets discovered by File Manager under Windows or Finder under OS X.

On a Windows-based system, we need to download an additional software called dd. Visit http://www.chrysocome.net/dd in your favorite browser. Now download the latest dd-XX.zip file you can find there, with XX being the latest stable version number. For example, dd-0.5.zip.
On Windows, navigate to your Downloads folder using File Manager. Here you will find the dd-05.zip file. Right-click on it and click on Extract All, and extract the dd.exe file without creating any subdirectory.
On Windows, open the command prompt (typically found at Start | All Programs | Accessories | Command Prompt) and type the following commands:
cd downloads dd.exe --list
On OS X, open the program Finder | Applications | Utilities | Terminal, and then type the following commands:
cd ~/Downloads diskutil list
On Windows, to spot the name of the right USB device you want to use as installation media, look into the output of the command under the removable media section. Below that, you should find a line starting with Mounting on and then a drive letter, for example, \.\e:. This cryptic written drive letter is the most important part we need in the next step, so please write it down.
On OS X, the device path can be found in the output of the former command and has the format of /dev/disk, where number is a unique identifier of the disk. The disks are numbered, starting with zero (0). Disk 0 is likely to be the OS X recovery disk, and disk 1 is likely to be your main OS X installation. To identify your USB device, try to compare the NAME, TYPE, and SIZE columns to the specifications of your USB stick. If you have identified the device name, write it down, for example, /dev/disk3.
On Windows, type the following command, assuming your USB device selected as an installation media has the Windows device name \\.\e: (change this as required and be careful what you type – this can create tremendous data loss). Also, substitute XXXX with the correct iso file version number in the next command
dd.exe if=CentOS-7-x86_64-Minimal-XXXX.iso of=\\.\e: bs=1M
On OS X, you need two commands which will ask for the administrator password (replace XXXX and disk3 with the correct version number and the correct USB device path):
sudo diskutil unmountDisk /dev/disk3 sudo dd if=./CentOS-7-x86_64-Minimal-XXXX.iso of=/dev/disk3 bs=1m
After the dd program finishes, there will be some output statistics on how long it took and how much data has been transferred during the copy process. On OS X, ignore any warning messages about the disk not being readable.
Congratulations! You now have created your first CentOS 7 USB installation media. You now can safely remove the USB drive in Windows or OS X, and physically unplug the device and use it as a boot device for installing CentOS 7 on your target machine.

How it works...

So what have we learned from this experience?

The purpose of this process was to introduce you to the concept of creating an exact copy of a CentOS installation ISO file on a USB device, using the dd command-line program. The dd program is a Unix based tool which can be used to copy bits from a source to a destination file. This means that the source gets read bit by bit and written to a destination without considering the content or file allocation; it just involves reading and writing pure raw data. It expects two file name based arguments: input file (if) and output file (of). We will use the CentOS image file as our input filename to clone it exactly 1:1 to the USB device, which is accessible through its device file as our output file parameter. The bs parameter defines the block size, which is the amount of data to be copied at once. Be careful, it is an absolute expert tool and overwrites any existing data on your target while copying data on it without further confirmation or any safety checks. So at least double-check the device drive letters of your target USB device and never confuse them! For example, if you have a second hard disk installed at D: and your USB device at E: (on OS X, at /dev/disk2 and /dev/disk3 respectively) and you confuse the drive letter E: with

D: (or /dev/disk3 with /dev/disk2), your second hard disk would be erased with little to no chances of recovering any lost data. So handle with care! If you’re in doubt of the correct output file device, never start the dd program!

In conclusion, it is fair to say that there are other far more convenient solutions available for creating a USB installation media for CentOS 7 than the dd command, such as the Fedora Live USB Creator. But this process was not only to create a ready-to-use CentOS USB installer but also to get you used to the dd command. It’s a common Linux command that every CentOS system administrator should know how to use. It can be used for a broad variety of daily tasks. For example, for securely erasing hard disks, benchmarking network speed, or creating random binary files.

Creating your own images from Dockerfiles and uploading to Docker Hub on CentOS

Besides images and containers, Docker has a third very important term called a Dockerfile. A Dockerfile is like a process on how to create an environment for a specific application, which means that it contains the blueprint and exact description of how to build a specific image file. For example, if we would like to containerize a webserver-based application, we would define all the dependencies for it, such as the base Linux system that provides the system dependencies such as Ubuntu, Debian, CentOS, and so on (this does not mean we virtualize the complete operating system but just use the system dependencies), as well as all applications, dynamic libraries, and services such as PHP, Apache, and MySQL in the Dockerfile and also all special configuration options or environment variables. There are two ways to build your own custom images. One, you could download an existing base image as we did in the previous Wordpress process and then attach to the container using BASH, install your additional software, make the changes to your configuration files, and then commit the container as a new image to the registry. Alternatively, here in this process, we will teach you how to build your own Docker image from a new Dockerfile for an Express.js web application server and upload it to your own Docker Hub account.

To Start With: What Do You Need?

To complete this process, you will require a working installation of the CentOS 7 operating system with root privileges, a console-based text editor of your choice, and a connection to the Internet in order to communicate with the Docker Hub. It is expected that Docker is already installed and is running. Also, for uploading your new image to the Docker Hub, you need to create a new Docker Hub user account there. Just go to https://hub.docker.com/ and register there for free. In our example, we will use a fictitious new Docker Hub user ID called johndoe.

The Process

To begin, log in as root and create a new directory structure using your Docker Hub user ID (substitute the johndoe directory name appropriately with your own ID), and open an empty Dockerfile where you put in your image’s building blueprint:
mkdir -p ~/johndoe/centos7-expressjs cd $_; vi Dockerfile
Put in the following content into that file:
FROM centos:centos7 RUN yum install -y epel-release;yum install -y npm; RUN npm install express --save COPY . ./src EXPOSE 8080 CMD ["node", "/src/index.js"]
Save and close the file. Now create your first Express.js web application, which we will deploy on the new container. Open the following file in the current directory:
vi index.js
Now put in the following JavaScript content:
var express = require('express'), app = express(); app.get('/', function (req, res) {res.send('Hello CentOS 7 cookbook!\n');}); app.listen(8080);
Now to build an image from this Dockerfile, stay in the current directory and use the following command (don’t forget the dot at the end of this line and replace johndoe with your own Docker Hub ID):
docker build -t johndoe/centos7-expressjs .
After successfully building the image, let’s run it as a container:
docker run -p 8081:8080 -d johndoe/centos7-expressjs
Finally, test if we can make an HTTP request to our new Express.js web application server running in our new container:
curl -i localhost:8081
If the Docker image is successfully running on the Express.js server, the following HTTP response should occur (truncated to the last line):
Hello CentOS 7 cookbook!

Uploading your image to the Docker Hub

After creating a new Docker Hub account ID called johndoe, we will start to login to the site using the following command—stay in the directory where you put your Dockerfile from the last step–for example ~/johndoe/centos7-expressjs (provide the username, the password, and the registration e-mail when asked):
docker login
Now, to push your new image created in this process to the Docker Hub (again replace johndoe with your own user ID), use:
docker push johndoe/centos7-expressjs
After uploading, you will be able to find your image on the Docker Hub web page search. Alternatively, you can use the command line:
docker search expressjs

How Does It Work?

Here in this short process, we showed you how to create your first Dockerfile which will create a CentOS 7 container to serve Express.js applications, which is a modern alternative to LAMP stacks where you program JavaScript on the client-and server-side.

So what did we learn from this experience?

As you can see, a Dockerfile is an elegant way to describe all the instructions on how to create an image. The commands are straight-forward to understand and you use special keywords to instruct Docker what to do in order to produce an image out of it. The FROM command tells Docker which base image we should use. Fortunately, someone has already created a base image from the CentOS 7 system dependencies (this will be downloaded from Docker Hub). Next, we used the RUN command, which just executes commands as on a BASH command-line. We use this command to install dependencies on our system in order to run Express.js applications (it’s based on the Node.js rpm package which we access by installing the EPEL repository first). The COPY command copies files from our host machine to a specific location on the container. We need this to copy our index.js file which will create all our Express.js web server code in a later step on to the container. EXPOSE, as the name implies, exposes an internal container port to the outside host system. Since by default Express.js is listening on 8080, we need to do this here. While all these commands shown up to this point will only be executed once when creating the image, the next command CMD will be run every time we start the container. The command node /src/index.js will be executed and instructs the system to start the Express.js web server with the index.js file (which we already provided in this directory by copying it from the host machine). We don’t want to go into any details about the JavaScript part of the program—it just handles HTTP GET requests and returns the Hello World string. In the second part of this process, we showed you how to push our new created image to the Docker Hub. In order to do so, login with your Docker user account. Then we can push our image to the repository.

As this is a very simple Dockerfile, there is much more to learn about this subject. To see a list of all the commands available in the Dockerfile, use man Dockerfile. Also, you should visit the Docker Hub and browse the Dockerfiles (under the section Source Repository hosted on GitHub) of some interesting projects to learn how to create some highly sophisticated image files with just a handful of commands on your own.

Installing a PostgreSQL server and managing a database in CentOS

In this process, we will not only learn how to install the PostgreSQL DBMS on our server, but we will also discover how to add a new user and create our first database. PostgreSQL is considered to be the most advanced open source database system in the world. It is known for being a solid, reliable, and well-engineered system that is fully capable of supporting high-transaction and mission-critical applications. PostgreSQL is a descendant of the Ingres database. It is community-driven and maintained by a large collection of contributors from all over the world. It may not be as flexible or as pervasive as MariaDB, but because PostgreSQL is a very secure database system that excels in data integrity, it is the purpose of this process to show you how to begin exploring this forgotten friend.

To Start With: What Do You Need?

To complete this process, you will require a working installation of the CentOS 7 operating system with root privileges, a console-based text editor of your choice, and a connection to the Internet in order to facilitate the download of additional packages. It is expected that your server will be using a static IP address.

The Process

PostgreSQL (also known as Postgres) is an object-relational database management system. It supports a large part of the SQL standard and it can be extended by the server administrator in many ways. However, in order to begin, we must start by installing the necessary packages:

Start by logging in your server as root and type:
yum install postgresql postgresql-server
Having installed the database system, we must now enable the database server at boot by typing:
systemctl enable postgresql
When you have finished, initialize the database system as follows:
postgresql-setup initdb
Now complete this process by starting the database server:
systemctl start postgresql
Now set a new initial password for our postgres administrator of your choice. As the default postgres user is currently using peer authentication, we need to execute any Postgres-related command with user postgres:
su -postgres -c "psql --command '\password postgres'"
To get rid of the requirement, that the postgres user has to be logged in on a system user basis before he can execute Postgres-related commands such as psql, and to allow login with database user accounts in general, we need to change the authentication method for localhost from peer to md5 in the Postgres client authentication configuration file. You can do this manually or use the sed tool as shown next, after you have made a backup of the file first:
cp /var/lib/pgsql/data/pg_hba.conf /var/lib/pgsql/data/pg_hba.conf.BAK sed -i 's/^$local.*$peer$/\1md5/g' /var/lib/pgsql/data/pg_hba.conf
Next, we have to restart the postgresql service in order to apply our changes:
systemctl restart postgresql
Now you will be able to login to your Postgres server with user postgres without the need to log in the postgres Linux system user first:
psql -U postgres
To exit the shell (postgres=#), type the following command (followed by the Return key):
\q
We will now issue a shell command to create a new database user, by substituting with a relevant user name to fit your own needs (type in a new password for the user when prompted, repeat it, and afterwards enter the password for the administrator user postgres to apply these settings):
createuser -U postgres -P
Now, also on the shell create your first database and assign it to our new user by replacing the and values with something more appropriate to your needs (enter the password for the postgres user):
createdb -U postgres -O
Finally, test if you can access the Postgres server with your new user by printing all the database names:
psql -U -l

How Does It Work?

PostgreSQL is an Object-Relational Database Management System and it is available to all CentOS servers. Postgres may not be as common as MariaDB, but its architecture and a large array of features to make it an attractive solution for many companies concerned with data integrity.

So what did we learn from this experience?

We began this process by installing the necessary server and client rpm packages using yum. Having done this, we then proceeded to make the Postgres system available at boot before initializing the database system using the postgresql-setup initdb command. We completed this process by starting the database service. In the next stage, we were then required to set the password for the Postgres administrator user to harden the system. By default, the postgresql package creates a new Linux system user called postgres (which is also used as an administrative Postgres user account to access our Postgres DBMS), and by using su -postgres -c we were able to execute the psql commands as the postgres user, which is mandatory upon installation (this is called peer authentication).

Having set the admin password, to have more like a MariaDB shell-type of login procedure where every database user (including the administrator postgres user) can log in using the database psql client’s user -U parameter, we changed this peer authentication to md5 database password-based authentication for the localhost in the pg_hba.conf file (see the next process). After restarting the service, we then used Postgres’s createuser and createdb command line tools to create a new Postgres user and connect it to a new database (we needed to provide the postgres user with the -U parameter because only he has the privileges for it). Finally, we showed you how to make a test connection to the database with your new user using the -l flag (which lists all the available databases). Also, you can use the -d parameter to connect to a specific database using the syntax: psql -d -U .

There's more…

Instead of using the createuser or createdb Postgres command-line tools, as we have been showing you in this process, to create your databases and users, you can also do the same using the Postgres shell. In fact, those command-line tools are actually just wrappers around the Postgres shell commands, and there is no effective difference between the two. psql is the primary command-line client tool for entering SQL queries or other commands on a Postgres server, similar to the MariaDB shell shown to you in another process in this chapter division. Here, we will launch psql with a template called template1, the boilerplate (or default template) that is used to start building databases. After login (psql -U postgres template1), and typing in the administrator password you should be presented with the interactive Postgres prompt (template1=#). Now to create a new user in the psql shell, type:
CREATE USER WITH PASSWORD ' ';

To create a database, type:
CREATE DATABASE ;

The option to grant all privileges on the recently created database to the new user is:
GRANT ALL ON DATABASE to ;

To exit the interactive shell, use: \q followed by pressing the Return key.

Having completed this process you could say that you not only know how to install PostgreSQL, but this process has served to highlight some simple architectural differences between this database system and MariaDB.

Using WebDAV for file sharing in CentOS

The Web-based Distributed Authoring and Versioning (WebDAV) open standard can be used for sharing files over the network. It is a popular protocol to conveniently access remote data as an online hard disk. There are a lot of online storage and e-mail providers who offer online space through WebDAV accounts. Most graphical Linux or Windows systems can access WebDAV servers in their file managers out-of-the-box. For other operating systems, there are also free options available. Another big advantage is that WebDAV is running over normal HTTP or HTTPS ports, so you can be sure that it will work in almost any environment, even behind restricted firewalls.

Here, we will show you how to install and configure WebDAV as an alternative for the FTP protocol for your file sharing needs. We will use HTTPS as our communication protocol for secure connections.

To Start With: What Do You Need?

To complete this process, you will require a working installation of the CentOS 7 operating system with root privileges and a console-based text editor of your choice. You will need a working Apache web server with SSL encryption enabled and reachable in your network; see Providing Mail Services for how to install the HTTP daemon, and especially the process of Setting up HTTPS with SSL. Also, some experience working with the Apache config file format is advantageous.

The Process

Create a location for sharing your data and for a WebDAV lock file:
mkdir -p /srv/webdav /etc/httpd/var/davlock
Since WebDAV is running as an Apache module over HTTPS, we have to set proper permissions to the standard httpd user:
chown apache:apache /srv/webdav /etc/httpd/var/davlock chmod 770 /srv/webdav
Now, create and open the following Apache WebDAV configuration file:
vi /etc/httpd/conf.d/webdav.conf
Put in the following content:
DavLockDB "/etc/httpd/var/davlock" Alias /webdav /srv/webdav DAV On SSLRequireSSL Options None AuthType Basic AuthName webdav AuthUserFile /etc/httpd/conf/dav_passwords Require valid-user
Save and close the file. Now, to add a new WebDAV user named john (enter a new password for the user as prompted):
htpasswd -c /etc/httpd/conf/dav_passwords john
Finally, restart the Apache2 web server:
systemctl restart httpd
To test if we can connect to our WebDAV server, you can use a graphical user interface (most Linux file managers support WebDAV browsing) from any client in your network, or we can mount the drive using the command line.
Log in on any client machine as root in the same network as our WebDAV server (on CentOS, you need the davfs2 filesystem driver package to be installed from the EPEL repository, and the usage of file locks must be disabled as the current version is not capable of working with file locks), enter the password for our DAV user account named john, and confirm the self-signed certificate when asked:
yum install davfs2 echo "use_locks 0" >> /etc/davfs2/davfs2.conf mkdir /mnt/webdav mount -t davfs https:///webdav /mnt/webdav
Now, to see if we can write to the new network storage type:
touch /mnt/webdav/testfile.txt
If you’ve got connection problems, check the firewall settings on your WebDAV server for the services http and https, as well as on your client.

How Does It Work?

Here in this process, we showed you how easy it is to set up a WebDAV server for easy file sharing.

So, what did we learn from this experience?

We started our journey by creating two directories: one, where all the shared files of our WebDAV server will live, and one for creating a lock file database for the WebDAV server process. The latter is needed so that users can block access to documents to avoid collisions with others if files are currently modified by them. As WebDAV runs as a native Apache module (mod_dav) that is already enabled by default in CentOS 7, all we need to do is create a new Apache virtual host configuration file, where we can set up all our WebDAV settings. First, we have to link our WebDAV host to the full path of the lock database that is used to track user locks. Next, we defined an alias for our WebDAV sharing folder, which we then configured using a Location directive. This will be activated if someone is using specific HTTP methods on the /webdav path URL. Within this area, we specified that this URL will be a DAV-enabled share, enabled SSL encryption for it, and specified basic user-based password authentication. The user account’s passwords will be stored in a user account database called /etc/httpd/conf/dav_passwords. To create valid accounts in this database file, we then used the Apache2 htpasswd utility on the command line. Finally, we restarted the service to apply our changes.

For testing, we used the davfs filesystem driver, which you need to install on CentOS 7 using the davfs2 package from the EPEL repository. There are many other options available, such as the cadaver WebDAV command-line client (also from the EPEL repository); alternatively, you can access it directly using integrated WebDAV support in a graphical user interface such as GNOME, KDE, or Xfce.

Using a CentOS third-party repository

In this process, we will investigate the desire to take full advantage of the packages that are available to CentOS by installing both the EPEL and Remi repositories. CentOS is an enterprise-based operating system that prides itself on stability, and during the lifetime of your server, it is possible that not every piece of software you need can be found in the default repositories. It is also possible that you may require updated packages of current software, and for these reasons, many server administrators choose to install both the EPEL and Remi repositories. These are not the only repositories available, but because they represent one of the most popular combinations, it is the purpose of this process to show you how both the EPEL and Remi repositories can be added to your system.

To Start With: What Do You Need?

The Process

Before we start, it is assumed that you have followed the previous process that showed you how to install and activate YUM priorities.

To begin, log in as root and install the EPEL release repository using YUM:
yum install epel-release
Next, from your home directory, type the following commands to download the remi release rpm package:
curl -O http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
Note
Please note that, while you are reading this, this URL may have changed; if so, please do some Internet research to find out if there is a new URL available.
The preceding file should now be located in your home folder. To proceed, type the following command:
rpm -Uvh remi-release-7.rpm
After the installation is done, open the Remi repository file with your favorite text editor:
vi /etc/yum.repos.d/remi.repo
Change enabled=0 to enabled=1 and add the line priority=10 to the end of the [remi] section.
Now, open the EPEL repository file with your favorite text editor:
vi /etc/yum.repos.d/epel.repo
Again, change enabled=0 to enabled=1 if not set automatically and add the line priority=10 in the [epel] section.
To finish, update YUM as shown here:
yum update
If updates are available, choose Y to proceed. Having completed the update process, you will now be able to download and install packages from both the Remi and EPEL repositories as an addition to those that are used by default.

How it works...

In order to use and enjoy the benefits of a third-party repository, you are required to install and enable it first using the YUM and RPM package manager.

So, what did we learn from this experience?

Having started the process, the task of installing both the Remi and EPEL repositories is a remarkably smooth process. While the installation of the EPEL repository using YUM is very safe to changes, the preceding URL for Remi is maintained at the discretion of the repository owners, so you should always ensure that they are the most current. However, having obtained the necessary repository setup file, it was then a matter of applying an RPM-based command in order to install all necessary repository files on your system. Having done this, we were then required to open the relevant configuration files of each of the installed repositories and enable them (by changing enabled=0 to enabled=1) and setting a priority value (priority=10). While the former value will merely switch the repository on, the latter one will be used by YUM to correctly identify which repositories were the most appropriate when we called the update command. As it was discussed in the previous process regarding YUM priorities, the simple rule of thumb is based on remembering the phrase “the lower the number, the higher the priority.” This, in itself (depending on your reasons), may not be a bad thing to do, but for the purpose of this process, it is shown that the default CentOS repositories should take priority over all others. Of course, you may disagree with this, and yes, there is nothing stopping you from applying the same priority rule to a third-party supplier, but I do caution you before diving in, and this is particularly the case if this is for a mission-critical production server. Remember, if all the priority values are the same, then YUM will attempt to download the latest version by default.

The reason for setting both Remi and EPEL to a higher value than the existing CentOSbased repositories is based on the need to consider security updates. Unless you have determined otherwise, it is always advised that the base files should come from CentOS first. This includes, but it is not limited to, Kernel updates, SELinux, and related packages. Third-party repositories should be used for additional packages that cannot be obtained from the original sources, or for access to particular updates that may not be available to the base release of CentOS. This may include packages such as Apache, MariaDB, or PHP. As a final footnote, you will have noticed that both Remi and EPEL repositories shared the same priority value. This is by design as these repositories are often viewed as partners. However, if you decide to begin mixing repositories, or use this process as a gateway to installing other repositories not mentioned here, then you should always do your research and evaluate every third-party on a case-by-case basis. The Remi and EPEL repositories are very popular, so if you do intend to add more third-party resources, read around the subject, choose your repositories carefully, and stay loyal.

There's more…

There are many other interesting repositories available for CentOS 7, such as ELRepo, which focuses on hardware-related packages such as filesystem drivers, graphics drivers, network drivers, sound drivers, and webcam or video drivers. Go to http://elrepo.org to learn how to install and access it.

Priming the kernel on CentOS

The Linux kernel is a program that constitutes the central core of the operating system. It can directly access the underlying hardware and make it available to the user to work with it using the shell.

In this process, we will learn how to prime the kernel by working with dynamically loaded kernel modules. Kernel modules are device driver files (or filesystem driver files) that add support for specific pieces of hardware so that we can access them.

You will not work very often with kernel modules as a system administrator, but having a basic understanding of them can be beneficial if you have a device driver problem or an unsupported piece of hardware.

To Start With: What Do You Need?

To complete this process, you will require a minimal installation of the CentOS 7 operating system with root privileges.

The Process

To begin, log in to your system using your root user account, and type the following command in order to show the status of all Linux kernel modules currently loaded:
lsmod
In the output, you will see all loaded device drivers (module); let’s see if a cdrom and floppy module have been loaded:
lsmod | grep "cdrom\|floppy"
On most servers, there will be the following output:
cdrom 42556 1 sr_mod floppy 69417 0
Now, we want to show detailed information about the sr_mod cdrom module:
modinfo sr_mod
Next, unload these two modules from the kernel (you can only do this if the module and hardware have been found and loaded on your system; otherwise skip this step):
modprobe -r -v sr_mod floppy
Check if the modules have been unloaded (output should be empty now):
lsmod | grep "cdrom\|floppy"
Now, to show a list of all kernel modules available on your system, use the following directory where you can look around:
ls /lib/modules/$(uname -r)/kernel
Let’s pick a module from the subfolder /lib/modules/$(uname r)/kernel/drivers/ called bluetooth and verify that it is not loaded yet (output should be empty):
lsmod | grep btusb
Get more information about the module:
modinfo btusb
Finally, load this Bluetooth USB module:
modprobe btusb
Verify again that it is loaded now:
lsmod | grep "btusb"

How it works…

Kernel modules are the drivers that your system’s hardware needs to communicate with the kernel and operating system (also, they are needed to load and enable filesystems). They are loaded dynamically, which means that only the drivers or modules are loaded at runtime, which reflects your own custom specific hardware.

So, what did we learn from this experience?

We started using the lsmod command to view all the currently loaded kernel modules in our system. The output shows three columns: the module name, the amount of RAM the module occupies while loaded, and the number of processes this module is used by and a list of dependencies of other modules using it. Next, we checked if the cdrom and floppy modules have been loaded by the kernel yet. In the output, we saw that the cdrom module is dependent on the sr_mod module. So, next we used the modinfo command to get detailed information about it. Here, we learned that sr_mod is the SCSI cdrom driver.

Since we only need the floppy and cdrom drivers while we first installed the base system we can now disable those kernel modules and save us some memory. We unloaded the modules and their dependencies with the modprobe -r command and rechecked whether this was successful by using lsmod again.

Next, we browsed the standard kernel module directory (for example, /lib/modules/$(uname -r)/kernel/drivers). The uname substring command prints out the current kernel version so that it makes sure that we are always listing the current kernel modules after having installed more than one version of the kernel on our system.

This kernel module directory keeps all the available modules on your system structured and categorized using subdirectories. We navigated to drivers/bluetooth and picked the btusb module. Doing modinfo on the btusb module, we found out that it is the generic Bluetooth USB driver. Finally, we decided that we needed this module, so we loaded it using the modprobe command again.

There's more…

It’s important to say that loading and unloading kernel modules using the modprobe command is not persistent; this means that if you restart the system, all your changes to kernel modules will be gone. To load a kernel module at boot time create a new executable script file, /etc/sysconfig/modules/.modules, where is the name of your choice. There you put in modprobe execution commands just as you would on the normal command line. Here is an example of additionally loading the Bluetooth driver on startup, for example /etc/sysconfig/modules/btusb.modules:

#!/bin/sh if [ ! -c /dev/input/uinput ] ; then exec /sbin/modprobe btusb >/dev/null 2>&1 fi

Finally, you need to make your new module file executable via the following line:
chmod +x /etc/sysconfig/modules/btusb.modules

Recheck your new module settings with lsmod after reboot.

To remove a kernel module at boot time for example sr_mod, we need to blacklist the module’s name using the rdblacklist kernel boot option. We can set this option by appending it to the end of the GRUB_CMDLINE_LINUX directive in the GRUB2 configuration file /etc/default/grub so it will look like:

GRUB_CMDLINE_LINUX="rd.lvm.lv=centos/root rd.lvm.lv=centos/swap
crashkernel=auto rhgb quiet rdblacklist=sr_mod"

If you need to blacklist multiple modules, the rdblacklist option can be specified multiple times like rdblacklist=sr_mod rdblacklist=nouveau.

Next, recreate the GRUB2 configuration using the grub2-mkconfig command:
grub2-mkconfig -o /boot/grub2/grub.cfg

Finally, we also need to blacklist the module name using the blacklist directive in a new.conf file of your choice in the /etc/modprobe.d/ directory for example:
echo "blacklist sr_mod" >> /etc/modprobe.d/blacklist.conf

Downloading CentOS and confirming the checksum on Windows or OS X

In this segment, we will learn how to download and confirm the checksum of one or more CentOS 7 disk images using a typical Windows or OS X desktop computer. CentOS is made available in various formats by HTTP, FTP, or the rsync protocol from a series of mirror sites located across the world or via the BitTorrent network. For downloading very important files from the Internet, such as operating system images, it is considered best practices to validate those files’ checksum, in order to ensure that any resulting media would function and perform as expected when installing. This also makes certain that the files are genuine and come from the original source.

To Start With: What Do You Need?

It is assumed that you are using a typical Windows-based (Windows 7, Windows Vista, or similar) or OS X computer with full administration rights. You will need an Internet connection to download the required installation files and also need access to a standard DVD/CD disk burner with the appropriate software, in order to create the relevant installation disks from the image files. Here, it is assumed that all the downloads will be stored on Windows in your personal C:\Users\ \Downloads folder, or if using an OS X system, in the /Users//Downloads folder.

The Process

Regardless of the type of installation files you download, the following techniques can be applied to all the image files supplied by the CentOS project:

Let’s begin by visiting http://www.centos.org in a web browser and navigate to the button link Get CentOS Now. Then click the link list of the current mirrors in the text.
The mirror sites are categorized, so from the resulting list of links, choose a mirror that is geographically near your current location. For example, if you are in London (UK), you can choose a mirror from the EU and the United Kingdom. Now choose a mirror site by selecting either the HTTP or the FTP link.
Having made your selection, you will now see a list of directories of all the available CentOS versions. To proceed, simply click the appropriate folder that reads 7. Next, you will see an additional list of directories, such as atomic, centosplus, cloud, and so on. We proceed by choosing the isos directory.
CentOS 7 currently only supports the 64-bit architecture, so browse to the only directory available labeled x86_64, which is a container for the 64-bit version.
You will now be presented with a series of files available for download. Begin by downloading a copy of the valid checksum result identified as md5sum.txt.
If you are new to CentOS or are intending to follow this process, then the minimal installation is ideal. This contains the least amount of packages to have a functional system, so choose the following (XXXX is the month stamp of this release):
On a Windows-based system only (on Mac, this tool is already available in the system), visit http://mirror.centos.org/centos/dostools/ in your browser and download the program md5sum.exe.
Now on Windows, open the command prompt (typically found at Start | All Programs | Accessories | Command Prompt) and type the following commands into the window that will open (press the Enter key at the end of all the lines):
cd downloads dir
On OS X, open the program Finder | Applications | Utilities | Terminal, then type the following commands (press the Enter key at the end of all the lines):
cd ~/Downloads ls
You should now see all the files in your download folder (including all the downloaded CentOS installation image files, the md5sum.txt file and on Windows, the md5sum.exe program)
Based on the file names shown, modify the following command in order to check the checksum of your downloaded ISO image file. On Windows, type the following} command (change the XXXX month stamp accordingly
md5sum.exe CentOS-7-x86_64-Minimal-XXXX.iso
On OS X, use instead
md5 CentOS-7-x86_64-Minimal-XXXX.iso
Press the Return key to proceed and then wait for the command prompt to respond. The response is known as the MD5 sum and the result could look like the following:
d07ab3e615c66a8b2e9a50f4852e6a77 CentOS-7-x86_64-Minimal-1503-01.iso
Now look at the sum and compare against the relevant listing for your particular image file in md5sum.txt (open in a text editor). If both the numbers match, then you can be confident that you have indeed downloaded a valid CentOS image file. If not, your downloaded file is probably corrupted, so please restart this procedure by downloading the image file again.
When you have finished, simply burn your image file(s) to a blank CD-ROM or DVD-ROM using your preferred desktop software, or create a USB installation media from it, as we will show you in the next recipe in this chapter.

How it works...

So what have we learned from this experience?

The act of downloading a CentOS installation image is just the first step towards building the perfect server. Although this process is very simple, many do forget the need to confirm the checksum. In this segment, we will work with the minimal installation image, but you should be aware that there are other installation options available to you, such as NetInstall, DVD, Everything, and various LiveCDs.

Downloading an image and running a container on CentOS

A common misconception is that Docker is a system for running containers. Docker is only a build-tool to wrap up any piece of Linux based software with all its dependencies in a complete filesystem that contains everything it needs to run: code, runtime, system tools, and system libraries. The technology to run Linux containers is called operating-systemlevel virtualization and provides multiple isolated environments built in every modern Linux kernel by default. This guarantees that it will always run the same, regardless of the environment it is deployed in; thus making your application portable. Therefore, when it comes to distributing your Docker applications into Linux containers, two major conceptional terms must be introduced: Docker images and containers. If you ever wanted to set up and run your own WordPress installation, in this process we will show you how to do so the fastest way possible by downloading a pre-made WordPress image from the official Docker hub; we will then run a container from.

To Start With: What Do You Need?

To complete this process, you will require a working installation of the CentOS 7 operating system with root privileges, a console-based text editor of your choice, and a connection to the Internet in order to facilitate the download of additional Docker images. It is expected that Docker has already been installed and is running.

The Process

The official WordPress image from Docker Hub does not contain its own MySQL server. Instead, it relies on it externally, so we will start this process by installing and running a MySQL docker container from Docker Hub.

To begin, log in as root and type the following command by replacing in the following command with a strong MySQL database password of your own choice (at the time of writing, the latest WordPress needs MySQL v.5.7; this can change in the future, so check out the official WordPress Docker Hub page):
docker run --restart=always --name wordpressdb -e MYSQL_ROOT_PASSWORD= -e MYSQL_DATABASE=wordpress -d mysql:5.7
Next, install and run the official WordPress image and run an instance of it as a Docker container, connecting it to the MySQL container (providing the same string from the previous step):
docker run --restart=always -e WORDPRESS_DB_PASSWORD= -d -name wordpress --link wordpressdb:mysql -p 8080:80 wordpress
Now the MySQL and WordPress container should already be running. To check the currently running containers, type:
docker ps
To get all the Docker WordPress container settings, use:
docker inspect wordpress
To check the container’s log file for our WordPress container, run the following command:
docker logs -f wordpress
Open a browser on a computer in the same network as the server running the Docker daemon and type in the following command to access your Wordpress installation (replace IP address with the one from your Docker server):
http://:8080/

How Does It Work?

A Docker image is a collection of all the files that make up a software application and its functional dependencies, as well as information about any changes as you modify or improve on its content (in the form of a change log). It is a non-runnable, read-only version of your application and can be compared to an ISO file. If you want to run such an image, a Linux container will be created out of it automatically by cloning the image. This is what then actually executes. It’s a real scalable system because you can run multiple containers from the same image. As we have seen, Docker is really not only the tools you need to work with images and containers but a complete platform as it also provides tools to access already pre-made images of all kinds of Linux server software. This is really the beauty of the whole Docker system because most of the time you don’t have to reinvent the wheel twice trying to create your own docker image from scratch. Just go to the Docker Hub ( https://hub.docker.com ), search for a software you want to run as a container, and when you find it then just use the docker run command, providing the Docker Hub name of the image, and you are done. Docker really can be a life-saver when thinking about all the endless hours trying to get the latest trendy programs to work with all the dependencies you need to compile and trying to get it to install.

So what did we learn from this experience?

We started our journey by using the docker run command which downloaded two images from the remote Docker Hub repos and put them into a local image store (called mysql:5.7 and wordpress) and then run them (create containers out of them). To get a list of all the images downloaded on our machine, type docker images. As we have seen, both run command lines provided the -e command line parameter, which we need to set some essential environment variables that will then be visible within the container. These include the MySQL database we want to run and the MySQL root password to set and access them. Here we see a very important feature of Docker: containers that can communicate which each other! Often you can just stack your application together from different Docker container pieces and make the whole system very easy to use. Another important parameter was -p which is used to create a port mapping from our host port 8080 to the internal HTTP port 80 and opens the firewall to allow incoming traffic on this port as well. --restart=always is useful to make the image container restartable, so the containers automatically get restarted on reboot of the host machine. Afterwards, we introduced you to Docker’s ps command line parameter which prints out all running Docker containers. Here the command should print out two running containers called wordpressdb and wordpress, together with their CONTAINER_ID. This ID is a unique MD5 hash we will use all the time in most of the Docker command line inputs whenever we need to reference a specific container (in this process we referenced by container name which is also possible). Afterwards, we showed you how to print out a container’s configuration by using the inspect parameter. Then, to get the Wordpress container’s log file in an open stream, we used the log -f parameter. Finally, since the -p 8080:80 mapping allows incoming access to our server at port 8080, we could then access our Wordpress installation from any computer in the same network using a browser. This will open the Wordpress installation screen.

Note
Note that if you have any connection problems while downloading any containers from Docker at any time, such as dial tcp: lookup index.docker.io: no such host, restart the Docker service before trying again.

There's more…

In this section, we will show you how to start and stop a container and how to attach to your container.

Stopping and starting a container

In the main process, we used Docker’s run command which is actually a wrapper for two other Docker commands: create and start. As the names of these commands suggest, the create command creates (clones) a container from an existing image and if it does not exist in the local image cache then it downloads it from a given Docker registry (such as the predefined Docker hub), while the start command actually starts it. To get a list of all the containers (running or stopped) on your computer, type: docker ps -a. Now identify a stopped or a started container, and find out its specific CONTAINER_ID. Then we can start a stopped container or stop a running one by providing the correct CONTAINER_ID such as docker start CONTAINER_ID. Examples are: docker start 03b53947d812 or docker stop a2fe12e61545 (the CONTAINER_ID hashes will vary on your computer).

Sometimes you need to remove a container; for example, if you want to completely change its command line parameters when creating from an image. For removing a container, use the rm command (but remember that it has to be stopped before): docker
stop b7f720fbfd23; docker rm b7f720fbfd23

Attaching and interacting with your container

Linux containers are completely isolated processes running in a separated environment on your server and there is no way to log in to it like logging into a normal server using ssh. If you need to access your containers BASH shell then you can run the docker exec command, which is particularly useful for debugging problems or modifying your container (for example, installing new packages or updating programs or files in it). Note that this only works on running containers and you need to know your container’s ID before (type docker ps to find out) you run the following command: docker exec -it CONTAINER_ID /bin/bash, for example docker exec -it d22ddf594f0d /bin/bash. Once successfully attached to the container, you will see a slightly changed command-line prompt with the CONTAINER_ID as hostname; for example, root@d22ddf594f0d:/var/www/html#. If you need to exit your container, type exit.

Allowing remote access to a MariaDB server on CentOS

Unless you are running your MariaDB database server to drive some local web applications on the same server hardware, most working environments would be pretty useless if remote access to a database server were forbidden. In many IT surroundings, you will find high-available, centralized dedicated database servers optimized in hardware (for example, huge amounts of RAM) and hosting multiple databases allowing hundreds of parallel connections from the outside to the server. Here in this process, we will show you how to make remote connections to the server possible.

To Start With: What Do You Need?

To complete this process, you will require a working installation of the CentOS 7 operating system with root privileges. It is expected that a MariaDB server is already installed and running and you have read and applied the Managing a MariaDB database process for an understanding of permissions and how to test (local) database connections.

The Process

In our example, we want to access a MariaDB database server with the IP address 192.168.1.12 from a client computer in the same network, with the IP address 192.168.1.33. Please change appropriately to fit your needs:

To begin, log in as root on your MariaDB database server and open the firewall for the incoming MariaDB connections:
firewall-cmd --permanent --add-service=mysql && firewall-cmd --reload
Afterwards, we need to create a user account which can connect to our MariaDB server remotely (as we have prevented root from doing this in a further step for security reasons), login your database server using the MariaDB command line interface mysql as user root and type the following MariaDB statement (replacing the XXXX with a password of your choice, also feel free to adjust the username and remote IP of the client who wants to connect to the server—in our case the client has the IP 192.168.1.33—accordingly):
GRANT SELECT ON mysql.user TO 'johndoe'@'192.168.1.33' IDENTIFIED BY 'XXXX'; FLUSH PRIVILEGES;EXIT;
Now we can test the connection from our client computer with the IP address of 192.168.1.33 in our network. This computer needs the MariaDB shell installed (on a CentOS 7 client, install the package mariadb) and needs to be able to ping the server running the MariaDB service (in our example, the IP 192.168.1.12). You can test connecting to the server by using the following command (on success, this will print out the content of the mysql user table):
echo "select user from mysql.user" | mysql -u johndoe -p mysql -h 192.168.1.12

How Does It Work?

We started our journey by opening the standard MariaDB firewall port 3306 using the firewalld predefined MariaDB service, which is disabled by default on CentOS 7. After this, we configured which IP addresses were allowed to access our database server, which is done on a database level using the MariaDB shell. In our example, we used the GRANT SELECT command to allow the user johndoe at the client IP address 192.168.1.33 and with the password in quotes 'XXXX' to access the database with the name mysql and the table user to make SELECT queries only. Remember, here you can also apply wildcards in the field using the % sign (which means any characters). For example, for defining any possible hostname combination in a Class C network, you can use the % sign like so 192.168.1.%. Granting access to the mysql.user database and table was just for testing purposes only and you should remove the user johndoe from this access permission whenever you have finished your tests, using: REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'johndoe'@'192.168.1.33';. If you want you can also delete the user DROP USER 'johndoe'@'192.168.1.33'; because we don’t need it anymore.

Subscribe to CentOS