Resources

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.

If you maintain multiple CentOS servers in your local network and want to save Internet bandwidth or speed up the downloading of the same remote repository packages over and over again, or are within a very restrictive network environment where access to any remote CentOS repository is blocked for your clients, you might want to consider running your own YUM repository. Having your own repository is also an excellent solution if you want to roll out a few custom or unofficial RPM packages (for example in-house configuration files or programs) to your local crowd or if you just want to create an official CentOS 7 repository mirror site. Here in this process, we will show you how to set up your own first YUM CentOS 7 repository and how to serve it to your local 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 to facilitate the download of additional packages. For this process to work, you will also need to place the CentOS 7 Everything DVD iso file image in your server’s root home directory, if you haven’t downloaded it yet, refer to a detailed description in the first process, Installing CentOS (but download the latest CentOS-7-x86_64Everything-XXXX.iso file instead of the minimal iso file). Also, we need a running Apache web server to share our YUM repository to our local network; please read the process, Providing Web Services in order to learn how to set it up.

The Process

To create our own YUM repository, we need the createrepo program, which is not installed on CentOS 7 by default. Let’s begin our journey by installing it. In this example, we will use the IP address, 192.168.1.7, for our YUM repository server:

1. Log in as root on your server and install the following package:
   yum install createrepo
2. Next, for every repository you want to share, create a subfolder beneath the Apache web root folder under /var/www/html/repository/, which will be publicly available when Apache is running; for example, to share the complete CentOS 7 Everything repository packages, you could use:
   mkdir -p /var/www/html/repository/centos/7.1
3. Now, put all your RPM package files of choice into the repository folders created here. In our example, we will put all RPM packages from the Everything iso image file into our new local repository location after we have mounted the content of the iso file to the filesystem:
   mount ~/CentOS-7-x86_64-Everything-1503-01.iso /mnt/
cp -r /mnt/Packages/* /var/www/html/repository/centos/7.1/
4. Afterward, we need to update the SELinux security contexts for all the new files copied into the Apache web root directory:
   restorecon -v -R /var/www/html
5. Now, for every repository we want to set up, run the following command:
   createrepo --database /var/www/html/repository/centos/7.1
6. Congratulations, you now have successfully created your first YUM repository, which can be accessed from any computer in the same network through the running Apache web server. In order to test it, log in as root to any other CentOS 7-based system that can ping our repository server and add our new repository to its YUM repository configuration directory:
   vi /etc/yum.repos.d/myCentosMirror.repo
7. Add the following content to this empty file (change the baseurl appropriately to fit your own needs):
   [myCentosMirror]
name=my CentOS 7.1 mirror
baseurl=http://192.168.1.7/repository/centos/7.1
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-7
8. Save and close the file, then test if your new repository is available (it should appear on the list) on your client:
   yum repolist | grep myCentosMirror
9. Now, to test our new YUM repository, we can try the following command:
   yum --disablerepo="*" --enablerepo="myCentosMirror" list available

How Does It Work?

In this process, we have shown you how easy it is to install and set up a local YUM repository. However, we have only shown you how to create a mirror site of all the CentOS 7 Everything iso RPM packages, but you can repeat this process for creating YUM repositories of every kind of package that you want to share with your network.

So, what did we learn from this experience?

Setting up your own YUM repository was simply a matter of installing the createrepo package and copying all the RPM packages that you want to share into a subfolder of your choice beneath your Apache’s document root directory (In our example, we had to mount the CentOS 7 Everything iso file to the filesystem, in order to access its included RPM package files that we want to share). As the Apache’s document root directory is under the control of SELinux, afterward we needed to set the security context for all the new RPM files in this directory to the httpd_sys_content_t type label; otherwise, no access through the web server would be possible. Finally, we needed to run the createrepo command on our new repository folder, which will create our new repository’s metadata that is needed for any YUM client that wants to connect to the repository later to make queries to it.

Afterward, to test our new repository, we created a new repository definition file on another CentOS 7 system that wants to use this new service and that must be in the same network as our YUM repository server. In this custom .repo configuration file, we put the correct URL path to the repository, enabled gpg checks, and took the standard CentOS 7 gpgkey so that our YUM client can proof the validity of the RPM packages official repository packages. Finally, we used the yum command with the --disablerepo="*" and --enablerepo="myCentosMirror" parameters, which will make sure to only use our new custom repository as a source. You can use these two parameters in combination with any other yum command such as install, search, info, list, and so on. This was just for testing; if you want to combine your new repository with the existing ones, please use YUM priorities for it. 

There's more…

Now, before we announce our new centralized YUM repository to our network, we should first make an update of all the RPM packages that have changed since the release of the CentOS Everything iso. In order to do this, visit http://www.centos.org and choose a rsync:// mirror link that is geographically near your current location. For example, if you are located in Germany one option could be rsync://ftp.hosteurope.de/centos/ (for more detailed instructions on navigating the CentOS website, read the first process, Installing CentOS). Also, before we can use the rsync protocol, we need to install the rsync package (yum install rsync), if not done already. Now, open the following empty script file vi ~/update-myCentosMirror-repo.sh file and put in the following content (replacing the rsync:// location accordingly, if needed):

rsync -avz rsync://ftp.hosteurope.de/centos/7/os/x86_64/Packages/
/var/www/html/repository/centos/7.1
restorecon -v -R /var/www/html

Now, make the file executable using chmod +x ~/update-myCentosMirror-repo.sh, and run it with ~/update-myCentosMirror-repo.sh. This should update your repository to the latest version. Finally, to automate this process, let’s create a cron job that will update our repository packages with the other mirror site every night at 2:30 am (open crontab -e):

30 2 * * * /root/update-myCentosMirror-repo.sh