CentOS

Here, this article will attempt to discuss how to initiate the process of running a netinstall over HTTP while in the process to install CentOS 6. 

The process of CentOS installation deals with the functioning of a small image file that is used to boot the computer that further will enable in downloading all the necessary files that stand necessary in downloading to complete the installation of the entire operating system. This process stands highly beneficial for computers that do not come with the access of DVD drive; here you are not required to download DVD based image files. 

To Start With: What Do You Need?

You must have a high-speed internet connection as this process will serve the beginning point of the graphical installation process. You must make sure that you are server consist of these following requirements,

​1. An Intel-based or AMD based CPU

2. More than 1GB RAM recommended. 

3. At least 10 GB hard disk space.

The Process: 

You are to insert the netinstall disc and further boot your computer from the optical drive. Then wait for the welcome screen to appear,

1. No soon does the welcome splash screen appear, you are to use the Up and Down arrow key for selecting and highlighting the referred space that says install or upgrade an existing system. Now, when you are ready directly press the Return Key to proceed. 
2. Now, after unpacking the files, you will see a disc found a screen that will ask you to test the integrity that of your installation disc. Integrity denotes to the quality of the data on the disc and if you are confident enough about installation media being error-free and you wish to proceed with the installation, make use of the LEFT and RIGHT arrow key and choose SKIP. Now, press the Return Key to proceed.
3. You can even test the integrity of your installation media by just clicking on OK and further following the provided instructions. This would take a few minutes, and when finished choose Continue and exit and you will automatically get back to the installation menu option
4. You will see a Language Selection screen and with the help of UP and DOWN arrow key, you click on your preferred language and then click on Return Key to proceed
5. Same for the Keyboard Selection Screen, that help of the UP and DOWN key to select your preferred keyboard setting and then click on the Return Key to proceed.
6. Now, you will have to confirm the installation method. As it will be installed over HTTP, you are supposed to choose the URL and again press the Return Key to proceed. 
7. You will see a Configure TCP/IP screen, where you will be asked to configure the network settings. With the help of UP and DOWN arrow key along with the Space Bar, you will have to place a * in the preferred value. In case, your local area supports dynamic IP, you are to choose DHCP and being ready highlight the OK and then click on Return Key to proceed. 
8. Now, your server will attempt to configure the Ethernet devices. This is before inviting you to complete the URL setup. So, whether you have chosen 32-bit or rather a 64-bit installation, use any one of the following values in the first dialogue box
   For 64-bit installation, use
   http://mirror.centos.org./centos/6/os/x86/_64
   For 32-bit installation, use
   http://mirror.centos.org/centos/6/os/i386  
   You can even obtain a list of local mirror sites
   http://ww.centos.org/mirrors

9. Now use the Tab Key and highlight OK and press the Return Key to proceed. 

10. Now, on success, the installer will gradually start retrieving the appropriate install.img file:

11. This might take a  few minutes to complete, however, once it gets resolved the progress bar is supposed to indicate the download activity. After completion, the installer will prepare an onscreen environment, and you will be presented with the installation welcome screen thereafter. 

How Does It Work?

This process does not only saves time by limiting your initial download to those files required for the installation process but at the same time, you underwent the whole of graphical installation method without any use of the complete DVD suite. 

Through this process, we came to know how to boot from the netinstall image, to initialize the main installer, check if the optical media is free of error, to provide relevant network, setting for the host computer along with providing URL to download the files. 

This is indeed the most flexible and easy process for a single server or multiple servers using a minimal install, you need not wait to download the entire set of installation files, rather the installer will only download the files required and chosen in location. This saves plenty of your time. 

The most significant security feature of any Linux system is providing access control— often called Discretionary Access Control (DAC)—which allows the owner of an object (such as a file) to set security attributes for it (for example, deciding who can read or write to a file using the chown and chmod commands). While this old and very simple security system was sufficient in ancient UNIX times, it does not meet all the modern requirements of security, where servers and services are constantly connected to the Internet.

Often, security breaches can be initiated by attackers exploiting buggy or misconfigured applications and the permissions to them. This is why the SELinux has been developed. Its main purpose is to enhance the security of the DAC system in Linux. It does so by adding an additional security layer on top of DAC, which is called Mandatory Access Control (MAC), and which can provide fine-grain access control to every single component of your system. SELinux has already been enabled on CentOS 7 and is absolutely recommended for any server connected directly to the Internet. Here in this process, we will install additional tools and configure them to better manage your SELinux system, and help in the troubleshooting and monitoring process.

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 connection to the Internet in order to download additional packages. For the best learning experience, it is also preferred that you work through this chapter segment process by process, in the order that they appear, because they build upon each other.

The Process

Throughout this book, we already applied programs such as semanage from the rpm policecoreutils-python package to manage our SELinux environment. If you missed installing it, we will begin this process by doing so (skip step 1 if you have already done this before):

1. Log in as root and install the following basic toolkit to work with SELinux:
   yum install policycoreutils-python
2. Now, we need some additional tools that will also be needed later in the course. 
   yum install setools setools-console setroubleshoot*
3. Next, install and configure the SELinux manual pages as they are not available by default on CentOS 7, but are important for getting detailed information about specific policies, security contexts, and SELinux Booleans later. First, we need to install another package:
   yum install policycoreutils-devel
4. Afterwards, let’s generate all the man pages for all SELinux security context policies currently available on the system, and then update the manual pages database afterwards:
   sepolicy manpage -a -p /usr/share/man/man8; mandb

How Does It Work?

By following this process, we installed all the tools needed for our daily work with SELinux. Also, we generated all available SELinux manual pages, which will be our primary source of information when working with SELinux, and also for troubleshooting SELinux services later.

SELinux has two primary and fundamental terms that we need to understand before diving into the remaining processes: labels (or more technically, security contexts) and policies. From SELinux’s perspective, a Linux system is divided into a number of different objects. Objects, for example, are all files, processes, users, sockets, and pipes in a system. In a SELinux context, every such object gets a special label. SELinux policies are the rules to control access to these objects using the labels defined on them: On every access attempt to such an object (for example, a file read), all SELinux policies available to the system will be searched if there is a rule for the specific label to make access control decisions (allow or deny the access).

So, what did we learn from this experience?

A lot of system administrators seem to avoid SELinux like the plague, and a trend in a lot of instruction manuals and tutorials leans towards disabling it altogether right after the installation of CentOS 7 because people seem to fear it and don’t want to mess with it, or are even frustrated if some networking service is not working correctly out-of-the-box. Often, they blame SELinux for any connection problems, so it often looks easier to disable it altogether rather than find out the true reasons by delving into the inner workings of SELinux. If you are disabling it, you are missing out one of the most critical security features of CentOS 7 that can prevent a lot of harm to your system in the event of an attack! In the last few years, the SELinux project has evolved very much and is easier to use than ever. A lot of convenient tools for working with it have emerged, and we get more of a complete set of policies to work with all the major applications and services available. By installing these tools, we are now ready to use SELinux and work with it in the most convenient way possible.

There's more…

There are three different modes when it comes to SELinux. While Enhanced is the only true mode that really protects us and enhances our server’s security, there are two other modes: Disabled and Permissive. Disabled means SELinux is turned off, which will never be an option for us in this book and is not discussed any further as it does not make sense to get rid of this fantastic CentOS feature. When disabled, our system is not enhanced by SELinux and the good old DAC system is the only source of protection we have at hand. Permissive mode means SELinux is turned on, the policy rules are loaded, and all objects are labeled with a specific security context, but the system is not enforcing these policies. This is like a dry-run parameter that a lot of Linux based command-line tools have: it simulates the system under SELinux enhanced security protection, and the system logs every SELinux policy violation as it would when running for real. This is a great way to debug the system, or to analyze the consequences that a normal, enforced run would have had on the system.

Often, it is used if you are unsure about the impact of using SELinux. As this mode does not really provide us with any additional security, we will eventually need to switch to Enforcing mode if we want enhanced security! Again, this is the only mode that protects us; SELinux is fully running with all the policies loaded and is enforcing these rules on the system. You should always aim for Enforcing mode on any system! To view the current mode, use the command sestatus. We can see the current SELinux mode in the Current mode line in the output. On CentOS 7, SELinux is in Enforcing mode by default, which again tells us that the system is fully protected by it. To change this mode to permissive mode, use the command setenforce permissive. Now, validate your setting using sestatus again. To revert your changes back to Enforcing mode, use setenforce enforcing. Setting the SELinux mode using setenforce is only setting it temporarily, and it will not survive a reboot (take a look at the Mode from config file in the sestatus output). To change this permanently, open the /etc/selinux/config file and change the SELINUX= configuration parameter.

Working with the MariaDB or Postgres command-line shell is sufficient for performing basic database administration tasks, such as user permission settings or creating simple databases as we have shown you in this chapter division. The more complex your schemas and relationships between tables get and the more your data grows, the more you should consider using some graphical database user interfaces for better control and work performance. This is also true for novice database administrators as such tools provide you with syntax highlighting and validation and some tools even have graphical representations of your databases (for example, showing Entity Relationship Models). In this process, we will show you how to install two of the most popular graphical open-source database management software for MariaDB and PostgreSQL on the market, namely phpMyadmin and phpPgAdmin, which are web-based browser applications written in PHP.

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 MariaDB or PostgreSQL server is already running using the processes found in this chapter division. Also, you will need a running Apache web server with PHP installed, which must be accessible from all the computers in your private network to deploy these applications. In addition, you need to have enabled the EPEL repositories for installing the correct software packages (refer to process Using a third-party repository, Managing Packages with YUM). Finally, you will need one computer in your network with a graphical window manager and a modern web browser to access these web applications

The Process

In this process, we will first show you how to install and configure phpMyAdmin for remote access and afterwards how to do the same for phpPgAdmin.

Installing and configuring phpMyAdmin in CentOS
To install and configure phpMyAdmin, perform the following steps:

1. Type in the following command to install the required package:
   yum install phpMyAdmin
2. Now create a copy of the main phpMyadmin configuration file:
   cp /etc/httpd/conf.d/phpMyAdmin.conf
/etc/httpd/conf.d/phpMyAdmin.conf.BAK
3. Next, open the main phpMyAdmin.conf configuration file and add the line Require ip XXX.XXX.XXX.XXX/XX with your defined subnet’s network address you want to grant access to the web application—for example, Require ip 192.168.1.0/24 below the line Require ip 127.0.0.1. You have to do this twice in the file or you can use sed to do this automatically, as shown here. On the command-line define the environment variable NET= accordingly to fit it to your own subnet’s network address.
   NET="192.168.1.0/24"
4. Then type the following line to apply your changes to the configuration file:
   sed -i "s,\(Require ip 127.0.0.1\),\1\nRequire ip $NET,g"
/etc/httpd/conf.d/phpMyAdmin.conf
5. Afterwards, reload your Apache server and now you should be able to browse to the phpMyAdmin website from any other computer in your subnet using the server’s IP running the web application, for example 192.168.1.12 (log in with your MariaDB administrator user called root or any other database user):
   http://192.168.1.12/phpMyAdmin

Installing and configuring phpPgAdmin in CentOS

Following are the steps to install and configure phpPgAdmin:

1. Type in the following command to install the required package:
   yum install phpPgAdmin
2. Before editing the phpPgAdmin main configuration, make a backup of it first:
   cp /etc/httpd/conf.d/phpPgAdmin.conf /etc/httpd/conf.d/phpPgAdmin.conf.BAK
3. Allowing remote access to phpPgAdmin is very similar to phpMyAdmin. Here you can also add a Require ip XXX.XXX.XXX.XXX/XX line with your defined subnet’s network address below the line Require local in the phpPgAdmin.conf file, or use the sed utility to do this automatically for you:
   NET="192.168.1.0/24"
sed -i "s,\(Require local\),\1\nRequire ip $NET,g"
/etc/httpd/conf.d/phpPgAdmin.conf
4. Restart Apache and browse to the phpPgAdmin main page:
   http://192.168.1.12/phpPgAdmin

How Does It Work?

In this fairly simple process, we have shown you how to install two of the most popular graphical administration tools for MariaDB and Postgres, running as web applications in your browser (and written in PHP) on the same server where your database service is running, and enabled remote access to them.

So what did we learn from this experience?

Installing phpMyAdmin for administering MariaDB databases and phpPgAdmin for Postgres databases was as easy as installing the corresponding rpm packages using the yum package manager. As both the tools are not to be found in the official CentOS 7 repositories, you need to enable the third-party repository EPEL before you can access and install these packages. By default, when installing both the web applications, access is denied to any connection not being made from the server itself (local only). Since we want to have access to it from different computers in our network, having installed a web browser you need to allow remote connections first. For both the web applications, this can be achieved using the Apache Require ip directive which is part of the Apache mod_authz_core module. In both the configuration files for phpMyAdmin and phpPgAdmin, we defined a whole subnet, such as 192.168.1.0/24, to allow connecting to the server, but you can also use a single IP address here which you want to allow access to. The sed commands inserted these important Require lines into the configuration file, but as said earlier you can also do this manually if you like by editing these files with your text editor of choice. After reloading the Apache configuration, you were then able to browse to the web pages using the two URLs shown in the process. On the start page of both the web sites, you can use any database user to log in without the need to enable remote privileges for them; any user with local permissions is sufficient.

In summary, we can say that we only showed you the basic configuration of both administration tools. There is always more to learn; for example, you should consider securing both PHP websites with SSL encryption or configuring your instances to connect to different database servers. Also, if you prefer desktop software for managing your databases, have a look at the open-source MySQL Workbench Community Edition, which can be downloaded from the official MySQL website for all major operating systems (Windows, OS X, Linux).

Before a client computer can use file system exports shared by an NFS server, it has to be configured to correctly access this system. Here in this process, we will show you how to set things up and work with NFS on the client machine.

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 you have already followed the Installing and configuring NFS process and have set up an NFS server, such as in this example. It is expected that all the clients can ping each other and are connected to the NFS server, and will be using a static IP address (see the process, Building a static network connection, in Configuring the System). In our example, the NFS server is running with the IP 192.168.1.10 and two clients with the IPs

192.168.1.11 and 192.168.1.12.

The Process

On our client systems, we also need the same NFS software package, and a similar configuration to the one on the server, in order to establish a communication between them:

1. To begin, log in on your client as root, and apply the exact same steps as in the Installing and configuring NFS process until the end of step 3. Skip step 4 because no firewalld service must be opened. Then, instead of step 5, use the following commands, which will not start and enable the nfs-server, but only the rpcbind service instead:
   systemctl start rpcbind
systemctl enable rpcbind
2. Stop there and do not apply anything else from the original process. To test the connection to our NFS server, use the following command:
    showmount -e myServer.example.com
3. Now, to test if attaching the NFS exports works you can do so manually using a new user, john. This needs to be added to the nfs-share group first in the following way so that we can write on our share:
   groupadd -g 50000 nfs-share;useradd john;passwd john;usermod -G nfs
share john
mount -t nfs4 myServer.example.com:/srv/nfs-data /mnt
su -john;touch /mnt/testfile.txt
4. If the creation of the file in the shared directory works, you can put the import in the fstab file so that it will be automatically mounted on system boot:
   vi /etc/fstab
5. Append the following line:
   myServer.example.com:/srv/nfs-data /mnt nfs defaults 0 0
6. Finally, to remount everything from fstab, type the following:
   mount -a

How Does It Work?

In this process, we showed you how easy it is to use some shared file system exports from an existing NFSv4 server.

So, what did we learn from this experience?

As you have seen, to set up an NFS client, you need a very similar setup to the one on the NFS server itself, with the exception of starting the rpcbind service instead of nfsserver (which, as the name implies, is only needed for the server side). The rpcbind service is a port mapper and is used for Remote Procedure Calls (RPC), which is a communication standard needed for NFS to work. Another very crucial step in the configuration that you should remember was setting up the domain name in the /etc/idmapd.conf file. We will have to use the same base domain name as on the server (example.com) in order to make the NFSv4 communication between server and client work. After having started and enabled the rpcbind service, we could then mount the NFS share to a local directory, either using the mount command (with -t type nfs4) directly or via the fstab file. Remember, that every system user who wants proper read/write/execute permissions to a share needs the same permissions on the NFS server; in our example, we manage correct permissions on an identical GID level. We used the default options to mount the share; if you need different or advanced options, please refer to man fstab. In order to apply changes to the fstab file, perform mount -a to remount everything from that file.

All software on a CentOS 7 system is distributed through RPM packages. Most of the time the YUM package manager is the first choice of any system administrator, performing software installation and maintenance, and is highly recommended whenever possible as it provides system integrity checks and has excellent package dependency resolution. In this process, we will show you an alternative way to manage your packages. We will be exploring the RPM package manager, which is a powerful tool used to build, install, query, verify, update, and erase individual RPM software packages. Though it is not as intelligent as YUM, as it cannot resolve package dependencies or work with repositories, it can be still relevant today since it provides very useful querying options that are not available in YUM, and it can be used to install single software packages manually.

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 RPM packages.

The Process

We start this process by downloading a rpm package from the Internet, which we will use to show you an example of how the rpm command works:

1. We will begin by logging in as root into the root’s home directory and downloading the pipe view program from the EPEL repository, which cannot be found in the official CentOS repository:
   Note
   cd ~;curl -O http://dl.fedoraproject.org/pub/epel/7/x86_64/p/pv-1.4.61.el7.x86_64.rpm
   Please note that while you are reading this, the package URL may have changed.
2. After the download has been completed, we will install this package using the following rpm command:
   rpm -Uvh ~/pv-1.4.6-1.el7.x86_64.rpm
3. If the installation has finished, let’s check if the installation of the package was successful by querying the RPM database:
   rpm -qa | grep "pv-"
4. You can also test the pv program directly (press Ctrl+C keys to quit):
   dd if=/dev/urandom | pv | dd of=/dev/null
5. We can now use the rpm command’s rich querying options to show useful information of the installed package:
   rpm -qi pv
rpm -ql pv
rpm -qd pv

6. Finally, let’s remove the package if you don’t like or need it anymore:
   rpm -e pv

How it works…

Here, in this process, we introduced you to the RPM package manager, which is the original program to manage RPM packages. The RPM package is a packaging standard for the distribution of software and contains useful metadata in the file to verify the authorship (for example, using signature verification with PGP) and integrity of the software included. The installation of packages containing binary programs instead of manually compiling and building them from scratch is much easier and more consistent, but RPM packages can also contain any type of file, such as source code or just documentation files. As said in the introduction, the rpm command has six different modes of operation: building, installing, uninstalling, updating, querying, and verifying rpm packages. Here, in this process, we showed you how to use the most important five operations (we don’t show building RPM’s).

So, what have we learned from this experience?

We started by logging in as root and downloading the pv (pipe viewer) rpm package example from the non-official EPEL CentOS repository (EPEL contains high-quality add-on packages, thoroughly checked and officially conformed; see the Using a third-party repository process to learn more about the EPEL repository) manually using curl, because it is not available in the official repository but can be a very useful tool.

Note

Although there are many RPM repositories and download sources on the Internet, for security and compatibility reasons, on productive systems you should consider installing only official CentOS 7 RPM packages from valid and reputable repositories and sources. In general, the packages contained are best tested and reviewed by many experts and users.

The downloaded package file’s name can be read the following way, which follows the following non-mandatory naming convention for RHEL/CentOS packages:
pv-1.4.6-1.x86_64.rpm = package name (pv)-version number (1.4.6)release(1)-CPU architecture (x86_64)

Next, we installed the downloaded pv package using the RPM package manager, which can be executed using the rpm command on the command line. We used it with the -Uvh command parameters together with the full name of the downloaded package rpm file.

Note

If using the rpm command for installing or upgrading rpm software packages, you should always use -Uvh with one exception; which are kernel packages. -U will remove old packages while updating, and this is not what you want if you install a new kernel. Use -i (for installing) here instead, as this will keep the old kernel files so that you can go back to an earlier version if you run into some problems.

-U is the parameter for installing or upgrading a package. If the package is not installed on the system, it will get installed; otherwise, rpm tries to upgrade it if it the RPM package version is newer than the one installed. The -v parameter prints a more verbose output, while -h displays a nice progress bar. Installing the pv package when you have not enabled the EPEL repository on your system will get the following warning message:
pv-1.6.0-1.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 3fc56f51: NOKEY

RPM will automatically check the validity of the package’s signature before installing to make sure that the package’s content has not been modified since it has been signed. Also, it checks that an RPM package is trustworthy, as it should be signed by an official third-party authority vendor using an encrypted key. You can ignore this message, as packages from the EPEL repository are from a secure source. To permanently trust EPEL sources, you can install its gpg public key on your system using the following command and getting rid of all future signature warning messages:
rpm --import https://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-7

Having successfully installed the package, we now have a nice command line tool called pv to show the progress of data going through a Unix pipe, which can be useful if you are transferring huge amounts of data through pipelines where you normally never know the current state of progress. Afterward, we queried the RPM database that stores information about all installed packages on a CentOS 7 system, using the rpm command with the -q flag. Working on the RPM database, we must use the true package name (pv) instead of the filename (pv-1.4.6-1.x86_64.rpm) that we used when we installed the packages in the first place. The same is true when removing an installed package; please specify the package name and not the version number or full filename.

To get detailed information about the installed package, pv, we used -qi (i for information), with the -ql parameter; we showed the full filename and path of all files in the package. -qd showed all the files in the package containing documentation. To read about more querying options, type man rpm and look under the PACKAGE QUERY OPTIONS section.

In summary, we can say that there are situations in a system administrator’s life where one needs to install a piece of software that is not distributed through an official repository (for example, non-open-source, cutting-edge program or beta versions, software that has a license disallowing the ability to put it into a repository such as Java, or software from independent developers), and where one will have to download individual RPM packages and install them manually. Under the hood, YUM also depends and uses the RPM package manager in the background, so you are also able to use the YUM program to install rpm files (yum install ). However, when it comes to querying your downloaded rpm files or installed packages on your system, there are situations where it’s better to use the older rpm command without having to install additional YUM-based software such as yum-utils.

The biggest weakness of RPM is that it does not support repositories and is missing a dependency management system. If you work with RPM alone to install all your software on a CentOS system, you will easily run into package dependency problems where you cannot install a specific package because it relies on some other packages. Often, when you try to install the dependent packages, you need other packages that they depend on and so on. This can be very tedious work and should always be avoided by using YUM instead.

There's more…

The rpm command can not only be used to query the rpm database for information about installed packages, you can also use it to query rpm files that you downloaded. For example, use the -qlp parameter to show all files in a local rpm package file:
rpm -qlp ~/pv-1.4.6-1.el7.x86_64.rpm

To get detailed information about the package from the rpm file, use the -qip parameter, as shown here:
rpm -qip ~/pv-1.4.6-1.el7.x86_64.rpm

If you want to install an RPM package that you have downloaded locally and that has dependencies, you can use the yum localinstall command. This will install the local package once supplied with its filename, and will try to resolve all the dependencies from remote sources, for example:

wget http://location/to/a/rpm/package_name.rpm
yum localinstall package_name.rpm

Often, a big part of every system administrator’s work is troubleshooting the server when something goes wrong. This is especially true for your system’s services, as they are constantly running and processing information all the time. Services can be dependent on other services and on the server’s system, and there will be situations in your administrator’s life where the system services will fail or refuse to start. Here, in this process, we will show you how to troubleshoot them if something goes wrong.

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.

The Process

In order to show you how to troubleshoot services, we will introduce a random error in the Apache service’s configuration file and then show you how to troubleshoot and fix it:

1. Log in as root and type the following command to append content to the httpd.conf:
   echo "THIS_IS_AN_ERRORLINE" >> /etc/httpd/conf/httpd.conf
2. Next, reload the httpd service and show its output:
   systemctl reload httpd.service
systemctl status httpd.service -l
3. Let’s revert this error line:
   sed -i 's/THIS_IS_AN_ERRORLINE//g' /etc/httpd/conf/httpd.conf
4. Now, restart the service again:
   systemctl reload httpd.service
systemctl status httpd.service

How it works…

In this fairly short process, we showed you how an example service will behave if it contains errors, and what you can do to fix it to get you started. There are a lot of different scenarios where something can go wrong when services malfunction, and it can be a big part of a system administrator’s job to solve those kinds of problem.

So, what have we learned from this experience?

We started this process by introducing a line of text in the main Apache configuration file, which does not contain any valid configuration syntax, and therefore the httpd service cannot interpret it. Then, we used the systemctl reload parameter to reload our server’s configuration file. As said before, not all services have the reload option, so if your service of interest does not support this, use the restart parameter instead. Since Apache will try to reload the configuration file with our current changes, it will refuse to accept the new configuration because of the wrong syntax that we introduced. Since we are just reloading the configuration, the running Apache process will not be affected by this problem and will stay online using its original configuration. The systemctl parameter will print out the following error message, giving us a hint of what to do next:

Job for httpd.service failed. Take a look at systemctl status httpd.service and journalctl -xe for details.

As suggested by the error output, the systemctl status parameter is a very powerful tool to see what’s going on behind the scenes with this service and to try and find out the reason for any failure (here you can also see that Apache is still running). If you start the systemctl status with the -l flag, it prints out an even longer version of the output, which can help you even more.

The output of this command shows us the exact reason for failing the configuration reload, so we can easily track down the cause of the problem (the output has been truncated):

AH00526: Syntax error on line 354 of /etc/httpd/conf/httpd.conf: Invalid command ERRORLINE, perhaps misspelled or defined by a module, is not included in the server configuration.

This output is part of the complete journald log information. If you want to read more about it, please refer to the Tracking system resources with journald process in this chapter. So, with this very useful information from the output, we can easily spot the problem and redo the introduction of ERRORLINE using the sed command and reload the service again; this time everything will work fine.

So, in summary, we can say that the systemctl status command is a very comfortable command that can be tremendously helpful in finding out problems with your service. Most services are very sensitive to syntax errors, and sometimes it can be just a misplaced space character that caused the service to refuse to work. Therefore, system administrators must work precisely all the time.

Here in this segment, we will learn how to perform a typical installation of CentOS using a new graphical installer interface introduced in CentOS.

In many respects, this is considered to be the recommended approach to installing your system, as it not only provides you with the ability to create the desired hard disk partitions but also to customize your installation in lots of ways (for example, keyboard layout, package selection, installation type, and so on). Your installation will then form the basis of a server on which you can build, develop, and run any type of service you may want to provide in the future.

To Start With: What Do You Need?

While we have learned in a former process how easy it is to upload our own images to the official Docker Hub, everything we put there will be exposed to the public. If you work on a private or closed-source project within a corporate environment or just want to test things out before publishing to everyone, chances are high that you would prefer your own, protected or cooperate-wide private Docker registry. Here in this process we will show you how you can set up and work with your own Docker registry that will be available in your own private network and which will be protected by TLS encryption and which will use user authentication so you can control exactly who can use it (push and pull images to and from it).

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. In our example, we will install the Docker Registry on a server with the IP address 192.168.1.100. Change the proces commands appropriately to fit your needs. You need to have set a FQDN for this server, otherwise, the registry will not work. For simplicity, we will use the /etc/hosts approach instead of setting up and configuring a DNS server (see processes in, Working with Domains if you would like to do this instead). Also, you need an Apache web server on your Docker server running which must be accessible from your whole private network.

The Process

Complete all the following steps in this process with user root on every computer in your network you want to connect to the Docker registry!

1. On each computer you want to access your Docker registry, as well as on our Docker registry server itself, with the IP address 192.168.1.100, define the domain name of the Docker registry, which in our example will be dockerserver.home (replace the dockerserver.home part appropriately if you use a different domain name):
   echo "export DCKREG=dockerserver.home" >> ~/.bash_profile source ~/.bash_profile
2. Now we will define the FQDN of our Docker server registry on each computer in our network we want to use the registry on (as well as on the Docker registry server itself). Log in as root on every machine and type the following command. Skip this step if you have already defined your Docker registry’s server’s domain name via a BIND DNS server (change the IP address of your Docker service 192.168.1.100 appropriately):
   echo "192.168.1.100 $DCKREG" >> /etc/hosts

Steps to be done on our Docker registry server (192.168.1.100)

1. First create a TLS certificate for our Docker registry certificate (use the FQDN you defined in DCKREG when asked for a Common name (for name; for example your name or your server’s hostname) []:dockerserver.home):
   cd; mkdir -p ~/certs; openssl req -newkey rsa:4096 -nodes -sha256
keyout certs/domain.key -x509 -days 365 -out certs/domain.crt
2. Next, we need to copy the new certificate to the Docker trusted certificate’s location as well as to the system’s default trusted certificate location and rebuild the certificate index:
   mkdir -p /etc/docker/certs.d/$DCKREG\:5000
cp ~/certs/domain.crt /etc/docker/certs.d/$DCKREG\:5000/ca.crt
cp ~/certs/domain.crt /etc/pki/ca-trust/source/anchors/docker
registry.crt
update-ca-trust
3. Also, copy the certificate to our Apache web server so we can easily access it from the Docker clients later:
   cp ~/certs/domain.crt /var/www/html/docker-registry.crt
4. Next, we will finally download, create, and run our Docker registry as a container:
   mkdir ~/auth; touch ~/auth/htpasswd docker run -d -p 5000:5000 - -
restart=always --name registry -v /
root/certs:/certs -v /root/auth:/auth -v /reg:/var/lib/registry -e
REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt -e
     REGISTRY_HTTP_TLS_KEY=/certs/domain.key -e
"REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" -e
REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd -e REGISTRY_AUTH=htpasswd
registry:2
5. Now check if the registry is running (in the output you should find it listening on [::]:5000, tls):
   docker logs registry
6. For setting up user authentication for our registry, use the following command (here we use johndoe as the username and mysecretpassword as the password for authentication. Change these two values to fit your needs. Repeat this command for every user account you want to have later for your users to login):
   cd; docker run -it --entrypoint htpasswd -v $PWD/auth:/auth -w /auth registry:2 -Bbc /auth/htpasswd johndoe mysecretpassword
7. Next restart the registry to apply your user account changes:
   docker restart registry
8.  Now create a new firewalld service and activate it in our firewall to make incoming connections to our new Docker registry port 5000 possible:
   sed 's/80/5000/g' /usr/lib/firewalld/services/http.xml | sed 's/WWW
(HTTP)/Docker registry/g' | sed 's/.*\/description>//g' >
/etc/firewalld/services/docker-reg.xml
firewall-cmd --reload
firewall-cmd --permanent --add-service=docker-reg; firewall-cmd - -
reload

Steps to be done on every client needing access to our registry

1. Finally, we can test connecting to our own new TLS-enhanced private Docker registry with user authentication by logging in on any computer in the same network as our Docker registry with root.
2. The first step is to install Docker on every client that wants to connect to the Docker registry:
   yum update && curl -sSL https://get.docker.com/ | sh
3. Next, on every client wanting to connect to our new Docker registry, set up the server’s certificate on the client first before we are able to connect to it (this step has been tested on CentOS 7 clients only):
   mkdir -p /etc/docker/certs.d/$DCKREG\:5000
curl http://$DCKREG/docker-registry.crt -o /tmp/cert.crt
cp /tmp/cert.crt /etc/docker/certs.d/$DCKREG\:5000/ca.crt
cp /tmp/cert.crt /etc/pki/ca-trust/source/anchors/docker-registry.crt
update-ca-trust
4. For testing, we start by pulling a new small test image from the official Docker Hub. Log in to the official Docker Hub by using your Docker Hub account (see a previous process):
   docker login
5. Now pull a small image called busybox:
   docker pull busybox
6. Afterwards, switch the Docker registry server to use our own that we set up in this process (enter the username and password, for example, johndoe / mysecretpassword. Leave the e-mail field blank):
   docker login $DCKREG:5000
7. Next, to push a Docker image from our client to our new private Docker registry, we need to tag it to be in our registry’s domain:
   docker tag busybox $DCKREG:5000/busybox
8. Finally, push the image to our own registry:
   docker push $DCKREG:5000/busybox
9. Congratulations! You have just pushed your first image to your private Docker repository. You can now pull this image $DCKREG:5000/busybox on any other client set up to communicate to our repository. To get a list of all the available images, use (change the account information accordingly):
   curl https://johndoe:mysecretpassword@$DCKREG:5000/v2/_catalog

How Does It Work?

In this process, we showed you how to set up your own Docker registry running in a Docker container on the server. It is very important to understand that you will need to configure a FQDN for your registry server because it is mandatory for the whole system to work.

So what did we learn from this experience?

We began by configuring the Docker registry’s FQDN on every computer using the /etc/hosts approach. Then we created a new certificate on the Docker registry server which will be used to communicate securely using TLS encryption between clients and registry. Next we installed the new generated certificate on the httpd server, so it is accessible to all the clients later; also in a specific Docker directory to make it accessible for Docker as well; and in the default trusted certificate location of the server where we also rebuilt the certificate cache for this server. Afterwards, we used the docker run command to download, install, and run our new Docker registry in a docker container itself on this server. We provided a list of parameters to configure TLS encryption and user authentication.

In the next step, we attached to the registry to create new htpasswd accounts. You can repeat this step whenever you need new accounts for your registry. Don’t forget to restart the registry container afterwards. Next, on every client we want to make communications to our new Docker registry, we need to install the server’s certificate also in the same places as on the server itself; thus we downloaded it from the HTTP source implemented previously and copied it to the various locations. To test things out on the client, next we connected to the official Docker Hub to download a random image we wanted to push to our own registry in the next step. We downloaded the busybox image to our own image cache and afterwards switched to connecting to our new private Docker registry. Before we could upload the image to the new location, we had to give it a proper tag that fitted the new server name and then we were able to push the image to our new Docker registry. The server is now available at port 5000 in the complete network. Remember that, if you don’t want to use your own registry any more on the clients, you can always switch back to the official docker repository using docker login.

There is so much more to learn about Docker. In the processes of this segment, we only scratched the surface of the Docker platform. If you want to learn more about it, consider going to https://www.Packtpub.com and check out one of the many titles available at this website about it.

In this process, we will learn how to configure remote access to a Postgres server which is disabled by default. Postgres employs a method called host-based authentication and it is the purpose of this process to introduce you to its concepts in order to provide the access rights you need to run a safe and secure database server.

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 text editor of your choice. It is expected that PostgreSQL is already installed and running.

The Process

In the previous process, we have already modified the host-based authentication configuration pg_hba.conf file using sed to manage our Postgres’s client authentication from peer to md5. Here we will make changes to it to manage remote access to our Postgres server.

1. To begin, log in as root and first open the firewall to allow any incoming PostgreSQL connections to the server:
   firewall-cmd --permanent --add-service=postgresql;firewall-cmd --reload
2. Now open the host-based authentication configuration file in your favorite text editor by typing:
   vi /var/lib/pgsql/data/pg_hba.conf
3. Scroll down to the end of the file and append the following line, to make these lines read as follows (substitute the XXX.XXX.XXX.XXX/XX value with a network address you want to grant access to. For example, if the IP address of your server was 192.168.1.12 then the network address would be 192.168.1.0/24):
   host        all          all           XXX.XXX.XXX.XXX/XX       md5
4. When you have finished, simply save and close the file in the usual way before opening the main Postgres configuration file by typing:
   vi /var/lib/pgsql/data/postgresql.conf
5. Add the following lines to the end of the file:
   listen_addresses = '*'
port = 5432
6. When you have finished, save the file in the usual way before restarting the database server by typing the following command:
   systemctl restart postgresql
7. On any other computer which is in the same network (defined by the XXX.XXX.XXX.XXX/XX value set previously), you can now test if the remote connection to your Postgres server is working using the psql shell (if your client computer is CentOS, you need to install it using yum install postgresql) by logging in on the server remotely and printing out some test data. In our example, the Postgres server is running with the IP address 192.168.1.12.
   psql -h 192.168.1.12 -U -d

How Does It Work?

PostgreSQL is a safe and secure database system but where we access it (either remotely or locally) can often become a cause of confusion. It was the purpose of this process to lift the lid on host-based authentication and provide an easy-to-use solution that will enable you to get your system up-and-running.

So what did we learn from this experience?

We began the process by opening the Postgres service’s standard ports in firewalld in order to make a connection from any remote computer possible in the first place. Then we opened Postgres’s host-based authentication configuration file called pg_hba.conf with our favorite text editor. Remember, we already changed from peer to md5 authentication for all local connections to provide user-based authentication in a former process. The inserted host record line specifies a connection type, database name, a user name, a client IP address range, and the authentication method. Many of the previous commands may already be understood but it is important to realize that there are several different methods of authentication:

• trust: Allows the connection unconditionally and enables anyone to connect with the database server without the need for a password.
• reject: Allows the database server to reject a connection unconditionally, a feature that remains useful when filtering certain IP addresses or certain hosts from a group.
• md5: Implies that the client needs to supply an MD5-encrypted password for authentication.
• peer and ident: Access is granted if the client’s logged in Linux user name from the operating system can be found as a database user in the system. ident is used for remote connections and peer for local connections.

Having completed this task, we then saved and closed the file before opening the main PostgreSQL configuration file located at /var/lib/pgsql/data/postgresql.conf. As you may or may not be aware, remote connections will not be possible unless the server is started with an appropriate value for listen_addresses, and where the default setting placed this on a local loopback address it was necessary to allow the database server to listen to all network interfaces (signified by the use of a star symbol or *) for incoming Postgres connections on the 5432 port. When finished, we simply saved the file and restarted the database server.

There is always much more to learn, but as a result of completing this process, you not only have a better understanding of host-based authentication but you have the ability to access your PostgreSQL database server both locally and remotely.

The Network File System (NFS) protocol enables remote access to filesystems over a network connection. It is based on a client-server architecture, allowing a centralized server to share files with other computers. A client can attach those exported shares in their own file system to access it conveniently, as they will be located on local storage. While Samba and AFP are more common distributed filesystems on Windows and OS X, NFS is now the de-facto standard and a key element of any Linux server system. Here in this process, we will show you how easy it is to set up an NFS server for file sharing over the network.

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 NFS server and all the clients will be able to ping each other and are connected to each other by a static IP address (see the process, Building a static network connection, in Configuring the System). In our example, the NFS server is running with IP 192.168.1.10 and two clients with the IPs 192.168.1.11 and 192.168.1.12 and the network’s domain name example.com.

The Process

In this particular section, we are going to learn how to install and configure the NFS server and create and export a share on a client.

Installing and configuring the NFS server

NFSv4 is not installed by default, and for this reason, we will begin by downloading and installing the required packages:

1. To do this, log in as root on the server that you want to run the NFS daemon on and type the following command in order to install the required packages:
   yum install nfs-utils
2. For NFSv4 to work, we need the same base domain for all clients and the NFS server. So, let’s define sub-domain names for our NFS server and the clients, if you haven’t set up a domain name using DNS, we will set up a new hostname for our computers in the /etc/hosts file:
   echo "192.168.1.10 myServer.example.com" >> /etc/hosts
echo "192.168.1.11 myClient1.example.com" >> /etc/hosts
echo "192.168.1.12 myClient2.example.com" >> /etc/hosts
3. Now, open the /etc/idmapd.conf file and put in the base domain name (not the full domain name) of your NFS server; search for the line that reads #Domain = local.domain.edu, and replace it with the following:
   Domain = example.com
4. Next, we need to open some firewall ports for the server to have proper NFS access:
   for s in {nfs,mountd,rpc-bind}; do firewall-cmd --permanent --addservice $s; done; firewall-cmd --reload
5. Finally, let’s start the NFS server service and enable it on reboot:
   systemctl start rpcbind nfs-server systemctl enable rpcbind nfs-server systemctl status nfs-server

Creating an export share

Now that our NFS server is configured and up-and-running, it’s time to create some file shares that we can export to our clients:

1. First, let’s create a folder for our shares and change its permissions:
   mkdir /srv/nfs-data
2. Create a new group with a specific GID and associate it with the export, and then change permissions:
   groupadd -g 50000 nfs-share;chown root:nfs-share /srv -R;chmod 775 /srv -R
3. Open the following file:
   vi /etc/exports
4. Now, enter the following text, but be very focussed while typing:
   /srv/nfs-data *(ro) 192.168.1.11(rw) 192.168.1.12(rw) /home *.example.com(rw)
5. Save and close the file, then re-export all entries from /etc/exports using the following:
   exportfs -ra

How Does It Work?

On CentOS 7, you can install version 4 of the NFS, which has some enhancements over former versions, such as more flexible authentication options and being fully backward compatible with older NFS versions. Here, we showed you how easy it is to install and configure the NFS server and create some shared exports for our clients to use.

So, what did we learn from this experience?

We started this process by installing the nfs-utils package, since the NFS server functionality is not available on CentOS 7 by default. Next, we configured our server’s domain name using the /etc/hosts file, as in our example, no DNS server of our own has been configured. If you have set up a DNS server, you should follow a similar domain name schema as shown here, because this is very important for NFSv4 to work, as all clients and the server should be in the same base domain. In our example, we specified that they are all sub-domains of example.com: myClient1.example.com, myClient2.example.com, and myServer.example.com. This is a means of securing the sharing of data, as the NFS server will only allow access to files from a client to a server if the domain names match (in our example, both server and client are part of the example.com domain). Next, we put this base domain in the idmapd.conf file, which takes care of mapping user names and group IDs to NFSv4 IDs. Afterwards, we enabled the nfs, mountd, and rpc-bind firewalld services in our firewalld instance, which are all needed for full support and communication between our clients and server. To finish our base configuration, we started the rpcbind and NFS servers and enabled them on boot.

After the NFS server was successfully set up, we added some export to it, to actually allow clients to access some shared folders from the server. Therefore, we created a special directory in the filesystem, which will keep all our shared files. We associated this sharing folder, /srv/nfs-data, with a new group, nfs-share, and gave it read/write/execute permissions. For practical reasons, we will control Linux file permissions for our export on a group level. The name is unimportant but its group identifier (GID) has to be set to a static value (for example, 50000). This new GID must be the same on the server as well as on every client for every user who wants to have write permissions because NFS transfers any access permissions between server and client on a user (UID) or GID level over the network. The whole sharing magic then happens in the /etc/exports file. It contains a table; in it you specify all the important information about your shared folders and their access securities for the clients. Every line in this file is equivalent to one shared folder in your system, and a whitespaced list of all the hosts allowed to access them together with their accessing options in brackets. As you can see, there are different possibilities to define your target clients using IP addresses or hostnames. For hostnames, you can use wildcards such as * and ? to keep the file more compact and allow for multiple machines at once, but you can also define export options for each single host name. Explaining all the options is outside the scope of this book; if you need more help, read the exports manual, which can be found using man exports.

For example, the line, /srv/nfs-data *(ro) 192.168.1.11(rw) 192.168.1.12(rw),

defines that we want to export the content of the folder /srv/nfs-data to all hostnames (because of the * symbol); read-only (ro) means that every client can read the content of the folder but not write in it. For clients with the IP address 192.168.1, ending with 11 and 12, we allow reading and writing (rw). The second line defines that we are exporting the /home directory to all clients in the subdomain of *.example.com with read/write capacity. Whenever you make a change to the /etc/exports file, run the exportfs -r command to apply your changes to the NFS server.

Finally, we can say that NFSv4 in CentOS 7 is very easy to set up and start. It’s the perfect solution for sharing files between Linux systems, or for centralized home directories.