Install Apache Web Server CentOS 7

 In this chapter, we will learn a little about the background of how Apache HTTP Server came into existence and then install the most current stable version on CentOS Linux 7.

Brief History on Apache WebServer

Apache is a web server that has been around for a long time. In fact, almost as long as the existence of http itself!

Apache started out as a rather small project at the National Center for Supercomputing Applications also known as NCSA. In the mid-90's "httpd", as it was called, was by far the most popular web-server platform on the Internet, having about 90% or more of the market share.

At this time, it was a simple project. Skilled I.T. staff known as webmaster were responsible for: maintaining web server platforms and web server software as well as both front-end and back-end site development. At the core of httpd was its ability to use custom modules known as plugins or extensions. A webmaster was also skilled enough to write patches to core server software.

Sometime in the late-mid-90's, the senior developer and project manager for httpd left NCSA to do other things. This left the most popular web-daemon in a state of stagnation.

Since the use of httpd was so widespread a group of seasoned httpd webmasters called for a summit reqarding the future of httpd. It was decided to coordinate and apply the best extensions and patches into a current stable release. Then, the current grand-daddy of http servers was born and christened Apache HTTP Server.

Little Known Historical Fact − Apache was not named after a Native American Tribe of warriors. It was in fact coined and named with a twist: being made from many fixes (or patches) from many talented Computer Scientists: a patchy or Apache.

Install Current Stable Version on CentOS Linux 7

Step 1 − Install httpd via yum.

yum -y install httpd

At this point Apache HTTP Server will install via yum.

Step 2 − Edit httpd.conf file specific to your httpd needs.

With a default Apache install, the configuration file for Apache is named httpd.conf and is located in /etc/httpd/. So, let's open it in vim.

The first few lines of httpd.conf opened in vim −

# 
# This is the main Apache HTTP server configuration file.  It contains the 
# configuration directives that give the server its instructions.
# See <URL:http://httpd.apache.org/docs/2.4/> for detailed information. 
# In particular, see  
# <URL:http://httpd.apache.org/docs/2.4/mod/directives.html> 
# for a discussion of each configuration directive.

We will make the following changes to allow our CentOS install to serve http requests from http port 80.

Listening host and port

# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, instead of the default. See also the <VirtualHost>
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses.
#
#Listen 12.34.56.78:80
Listen 80

From here, we change Apache to listen on a certain port or IP Address. For example, if we want to run httpd services on an alternative port such as 8080. Or if we have our web-server configured with multiple interfaces with separate IP addresses.

Listen

Keeps Apache from attaching to every listening daemon onto every IP Address. This is useful to stop specifying only IPv6 or IPv4 traffic. Or even binding to all network interfaces on a multi-homed host.

#
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, instead of the default. See also the <VirtualHost>
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses.
#
Listen 10.0.0.25:80
#Listen 80

DocumentRoot

The "document root" is the default directory where Apache will look for an index file to serve for requests upon visiting your sever: http://www.yoursite.com/ will retrieve and serve the index file from your document root.

#
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/var/www/html"

Step 3 − Start and Enable the httpd Service.

[root@centos rdc]# systemctl start httpd && systemctl reload httpd 
[root@centos rdc]#

Step 4 − Configure firewall to allow access to port 80 requests.

[root@centos]# firewall-cmd --add-service=http --permanent

Linux Admin - Create SSL Certificates

 

TLS and SSL Background

TLS is the new standard for socket layer security, proceeding SSL. TLS offers better encryption standards with other security and protocol wrapper features advancing SSL. Often, the terms TLS and SSL are used interchangeably. However, as a professional CentOS Administrator, it is important to note the differences and history separating each.

SSL goes up to version 3.0. SSL was developed and promoted as an industry standard under Netscape. After Netscape was purchased by AOL (an ISP popular in the 90's otherwise known as America Online) AOL never really promoted the change needed for security improvements to SSL.

At version 3.1, SSL technology moved into the open systems standards and was changed to TLS. Since copyrights on SSL were still owned by AOL a new term was coined: TLS - Transport Layer Security. So it is important to acknowledge that TLS is in fact different from SSL. Especially, as older SSL technologies have known security issues and some are considered obsolete today.

Note − This tutorial will use the term TLS when speaking of technologies 3.1 and higher. Then SSL when commenting specific to SSL technologies 3.0 and lower.

SSL vs TLS Versioning

The following table shows how TLS and SSL versioning would relate to one another. I have heard a few people speak in terms of SSL version 3.2. However, they probably got the terminology from reading a blog. As a professional administrator, we always want to use the standard terminology. Hence, while speaking SSL should be a reference to past technologies. Simple things can make a CentOS job seeker look like a seasoned CS Major.

TLS	SSL
-	3.0
1.0	3.1
1.1	3.2
1.2	3.3

TLS performs two main functions important to the users of the Internet today: One, it verifies who a party is, known as authentication. Two, it offers end-to-end encryption at the transport layer for upper level protocols that lack this native feature (ftp, http, email protocols, and more).

The first, verifies who a party is and is important to security as end-to-end encryption. If a consumer has an encrypted connection to a website that is not authorized to take payment, financial data is still at risk. This is what every phishing site will fail to have: a properly signed TLS certificate verifying website operators are who they claim to be from a trusted CA.

There are only two methods to get around not having a properly signed certificate: trick the user into allowing trust of a web-browser for a self-signed certificate or hope the user is not tech savvy and will not know the importance of a trusted Certificate Authority (or a CA).

In this tutorial, we will be using what is known as a self-signed certificate. This means, without explicitly giving this certificate the status of trusted in every web browser visiting the web-site, an error will be displayed discouraging the users from visiting the site. Then, it will make the user jump though a few actions before accessing a site with a self-signed certificate. Remember for the sake of security this is a good thing.

Install and Configure openssl

openssl is the standard for open-source implementations of TLS. openssl is used on systems such as Linux, BSD distributions, OS X, and even supports Windows.

openssl is important, as it provides transport layer security and abstracts the detailed programming of Authentication and end-to-end encryption for a developer. This is why openssl is used with almost every single open-source application using TLS. It is also installed by default on every modern version of Linux.

By default, openssl should be installed on CentOS from at least version 5 onwards. Just to assure, let's try installing openssl via YUM. Just run install, as YUM is intelligent enough to let us know if a package is already installed. If we are running an older version of CentOS for compatibility reasons, doing a yum -y install will ensure openssl is updated against the semi-recent heart-bleed vulnerability.

When running the installer, it was found there was actually an update to openssl.

[root@centos]# yum -y install openssl
Resolving Dependencies
--> Running transaction check
---> Package openssl.x86_64 1:1.0.1e-60.el7 will be updated
---> Package openssl.x86_64 1:1.0.1e-60.el7_3.1 will be an update
--> Processing Dependency: openssl-libs(x86-64) = 1:1.0.1e-60.el7_3.1 for 
package: 1:openssl-1.0.1e-60.el7_3.1.x86_64
--> Running transaction check
---> Package openssl-libs.x86_64 1:1.0.1e-60.el7 will be updated
---> Package openssl-libs.x86_64 1:1.0.1e-60.el7_3.1 will be an update
--> Finished Dependency Resolution 
Dependencies Resolved

===============================================================================
=============================================================================== 
 Package                               Arch
 Version                            Repository                        Size 
=============================================================================== 
=============================================================================== 
Updating: 
openssl                               x86_64                          
1:1.0.1e-60.el7_3.1                 updates                           713 k
Updating for dependencies:

Create Self-signed Certificate for OpenLDAP

This is a method to create a self-signed for our previous OpenLDAP installation.

To create an self-signed OpenLDAP Certificate.

openssl req -new -x509 -nodes -out /etc/openldap/certs/myldaplocal.pem -keyout
/etc/openldap/certs/myldaplocal.pem -days 365

[root@centos]# openssl req -new -x509 -nodes -out /etc/openldap/certs/vmnet.pem 
-keyout /etc/openldap/certs/vmnet.pem -days 365 
Generating a 2048 bit RSA private key
.............................................+++
................................................+++
writing new private key to '/etc/openldap/certs/vmnet.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:Califonia
Locality Name (eg, city) [Default City]:LA
Organization Name (eg, company) [Default Company Ltd]:vmnet
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:centos
Email Address []:bob@bobber.net
[root@centos]#

Now our OpenLDAP certificates should be placed in /etc/openldap/certs/

[root@centos]# ls /etc/openldap/certs/*.pem 
/etc/openldap/certs/vmnetcert.pem  /etc/openldap/certs/vmnetkey.pem
[root@centos]#

As you can see, we have both the certificate and key installed in the /etc/openldap/certs/ directories. Finally, we need to change the permissions to each, since they are currently owned by the root user.

[root@centos]# chown -R  ldap:ldap /etc/openldap/certs/*.pem
[root@centos]# ls -ld /etc/openldap/certs/*.pem
-rw-r--r--. 1 ldap ldap 1395 Feb 20 10:00 /etc/openldap/certs/vmnetcert.pem 
-rw-r--r--. 1 ldap ldap 1704 Feb 20 10:00 /etc/openldap/certs/vmnetkey.pem
[root@centos]#

Create Self-signed Certificate for Apache Web Server

In this tutorial, we will assume Apache is already installed. We did install Apache in another tutorial (configuring CentOS Firewall) and will go into advanced installation of Apache for a future tutorial. So, if you have not already installed Apache, please follow along.

Once Apache HTTPd can be installed using the following steps −

Step 1 − Install mod_ssl for Apache httpd server.

First we need to configure Apache with mod_ssl. Using the YUM package manager this is pretty simple −

[root@centos]# yum -y install mod_ssl

Then reload your Apache daemon to ensure Apache uses the new configuration.

[root@centos]# systemctl reload httpd

At this point, Apache is configured to support TLS connections on the local host.

Step 2 − Create the self-signed ssl certificate.

First, let's configure our private TLS key directory.

[root@centos]# mkdir /etc/ssl/private 
[root@centos]# chmod 700 /etc/ssl/private/

Note − Be sure only the root has read/write access to this directory. With world read/write access, your private key can be used to decrypt sniffed traffic.

Generating the certificate and key files.

[root@centos]# sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout 
/etc/ssl/private/self-gen-apache.key -out /etc/ssl/certs/self-sign-apache.crt 
Generating a 2048 bit RSA private key
..........+++
....+++
-----
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:xx
Locality Name (eg, city) [Default City]:xxxx
Organization Name (eg, company) [Default Company Ltd]:VMNET
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:centos.vmnet.local
Email Address []:

[root@centos]#

Note − You can use public IP Address of the server if you don't have a registered domain name.

Let's take a look at our certificate −

[root@centos]# openssl x509 -in self-sign-apache.crt -text -noout
Certificate:
   Data:
      Version: 3 (0x2)
      Serial Number: 17620849408802622302 (0xf489d52d94550b5e)
   Signature Algorithm: sha256WithRSAEncryption
   Issuer: C=US, ST=UT, L=xxxx, O=VMNET, CN=centos.vmnet.local
   Validity
      Not Before: Feb 24 07:07:55 2017 GMT
      Not After : Feb 24 07:07:55 2018 GMT
   Subject: C=US, ST=UT, L=xxxx, O=VMNET, CN=centos.vmnet.local
   Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
         Public-Key: (2048 bit)
            Modulus:
               00:c1:74:3e:fc:03:ca:06:95:8d:3a:0b:7e:1a:56:
               f3:8d:de:c4:7e:ee:f9:fa:79:82:bf:db:a9:6d:2a:
               57:e5:4c:31:83:cf:92:c4:e7:16:57:59:02:9e:38:
               47:00:cd:b8:31:b8:34:55:1c:a3:5d:cd:b4:8c:b0:
               66:0c:0c:81:8b:7e:65:26:50:9d:b7:ab:78:95:a5:
               31:5e:87:81:cd:43:fc:4d:00:47:5e:06:d0:cb:71:
               9b:2a:ab:f0:90:ce:81:45:0d:ae:a8:84:80:c5:0e:
               79:8a:c1:9b:f4:38:5d:9e:94:4e:3a:3f:bd:cc:89:
               e5:96:4a:44:f5:3d:13:20:3d:6a:c6:4d:91:be:aa:
               ef:2e:d5:81:ea:82:c6:09:4f:40:74:c1:b1:37:6c:
               ff:50:08:dc:c8:f0:67:75:12:ab:cd:8d:3e:7b:59:
               e0:83:64:5d:0c:ab:93:e2:1c:78:f0:f4:80:9e:42: 
               7d:49:57:71:a2:96:c6:b8:44:16:93:6c:62:87:0f:
               5c:fe:df:29:89:03:6e:e5:6d:db:0a:65:b2:5e:1d:
               c8:07:3d:8a:f0:6c:7f:f3:b9:32:b4:97:f6:71:81:
               6b:97:e3:08:bd:d6:f8:19:40:f1:15:7e:f2:fd:a5:
               12:24:08:39:fa:b6:cc:69:4e:53:1d:7e:9a:be:4b:

Here is an explanation for each option we used with the openssl command −

Command	Action
req -X509	Use X.509 CSR management PKI standard for key management.
-nodes	Do not secure our certificate with a passphrase. Apache must be able to use the certificate without interruption of a passphrase.
-days 2555	Tells the validity of the certificate to 7 years or 2555 days. Time period can be adjusted as needed.
-newkey rsa:2048	Specified to generate both key and certificate using RSA at 2048 bits in length.

Next, we want to create a Diffie-Heliman group for negotiating PFS with clients.

[centos#] openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

This will take from 5 to 15 minutes.

Perfect Forward Secrecy − Used to secure session data in case the private key has been compromised. This will generate a key used between the client and the server that is unique for each session.

Now, add the Perfect Forward Secrecy configuration to our certificate.

[root@centos]# cat /etc/ssl/certs/dhparam.pem | tee -a /etc/ssl/certs/self-sign-apache.crt

Configure Apache to Use Key and Certificate Files

We will be making changes to /etc/httpd/conf.d/ssl.conf −

We will make the following changes to ssl.conf. However, before we do that we should back the original file up. When making changes to a production server in an advanced text editor like vi or emcas, it is a best practice to always backup configuration files before making edits.

[root@centos]# cp /etc/httpd/conf.d/ssl.conf ~/

Now let's continue our edits after copying a known-working copy of ssl.conf to the root of our home folder.

• Locate
• Edit both DocumentRoot and ServerName as follows.

\\# General setup for the virtual host, inherited from global configuration
DocumentRoot "/var/www/html"
ServerName centos.vmnet.local:443

DocumentRoot this is the path to your default apache directory. In this folder should be a default page that will display a HTTP request asking for the default page of your web server or site.

ServerName is the server name that can be either an ip address or the host name of the server. For TLS, it is a best practice to create a certificate with a host name. From our OpenLdap tutorial, we created a hostname of centos on the local enterprise domain: vmnet.local

Now we want to comment the following lines out.

SSLProtocol

#   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
 ~~~~> #SSLProtocol all -SSLv2
 
#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
 ~~~~> #SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA

Then let Apache know where to find our certificate and private/public key pair.

Specify path to our self-signed certificate file

#   Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.  If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.  Note that a kill -HUP will prompt again.  A new
# certificate can be generated using the genkey(1) command.
~~~~> SSLCertificateFile /etc/ssl/certs/self-sign-apache.crt
specify path to our private key file
#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
~~~~> SSLCertificateKeyFile /etc/ssl/private/self-gen-apache.key

Finally, we need to allow inbound connections to https over port 443.

Install and Configure Open LDAP

 LDAP known as Light Weight Directory Access Protocol is a protocol used for accessing X.500 service containers within an enterprise known from a directory. Those who are familiar with Windows Server Administration can think of LDAP as being very similar in nature to Active Directory. It is even a widely used concept of intertwining Windows workstations into an OpenLDAP CentOS enterprise. On the other spectrum, a CentOS Linux workstation can share resources and participate with the basic functionality in a Windows Domain.

Deploying LDAP on CentOS as a Directory Server Agent, Directory System Agent, or DSA (these acronyms are all one and the same) is similar to older Novell Netware installations using the Directory Tree structure with NDS.

Brief History of LDAP

LDAP was basically created as an efficient way to access X.500 directories with enterprise resources. Both X.500 and LDAP share the same characteristics and are so similar that LDAP clients can access X.500 directories with some helpers. While LDAP also has its own directory server called slapd. The main difference between LDAP and DAP is, the lightweight version is designed to operate over TCP.

While DAP uses the full OSI Model. With the advent of the Internet, TCP/IP and Ethernet prominence in networks of today, it is rare to come across a Directory Services implantation using both DAP and native X.500 enterprise directories outside specific legacy computing models.

The main components used with openldap for CentOS Linux are −

openldap	LDAP support libraries
openldap-server	LDAP server
openldap-clients	LDAP client utlities
openldap-devel	Development libraries for OpenLDAP
compay-openldap	OpenLDAP shared libraries
slapd	Directory server daemon of OpenLDAP
slurpd	Used for LDAP replication across an enterprise domain

Note − When naming your enterprise, it is a best practice to use the .local TLD. Using a .net or .com can cause difficulties when segregating an online and internal domain infrastructure. Imagine the extra work for a company internally using acme.com for both external and internal operations. Hence, it can be wise to have Internet resources called acme.com or acme.net. Then, the local networking enterprise resources is depicted as acme.local. This will entail configuring DNS records, but will pay in simplicity, eloquence and security.

Install Open LDAP on CentOS

Install the openldap, openldap-servers, openldap-clients and migrationstools from YUM.

[root@localhost]# yum -y install openldap openldap-servers openldap-clients
migration tools
 Loaded plugins: fastestmirror, langpacks
 updates
 | 3.4 kB  00:00:00
 updates/7/x86_64/primary_db
 | 2.2 MB  00:00:05
 Determining fastest mirrors
 (1/2): extras/7/x86_64/primary_db
 | 121 kB  00:00:01
 (2/2): base/7/x86_64/primary_db
 | 5.6 MB  00:00:16
 Package openldap-2.4.40-13.el7.x86_64 already installed and latest version
 Resolving Dependencies
 --> Running transaction check
 ---> Package openldap-clients.x86_64 0:2.4.40-13.el7 will be installed
 ---> Package openldap-servers.x86_64 0:2.4.40-13.el7 will be installed
 --> Finished Dependency Resolution
 base/7/x86_64/group_gz
 | 155 kB  00:00:00
 
 Dependencies Resolved
 
=============================================================================== 
=============================================================================== 
Package                                Arch
Version                             Repository                        Size 
=============================================================================== 
=============================================================================== 
Installing: 
openldap-clients                    x86_64
2.4.40-13.el7                    base                                 188 k 
openldap-servers                    x86_64
2.4.40-13.el7                    base                                 2.1 M  

Transaction Summary 
=============================================================================== 
===============================================================================
Install  2 Packages

Total download size: 2.3 M 
Installed size: 5.3 M 
Downloading packages:

Installed: 
openldap-clients.x86_64 0:2.4.40-13.el7                                       
openldap-servers.x86_64 0:2.4.40-13.el7                                       
Complete! 
[root@localhost]#

Now, let's start and enable the slapd service −

[root@centos]# systemctl start slapd 
[root@centos]# systemctl enable  slapd

At this point, let's assure we have our openldap structure in /etc/openldap.

root@localhost]# ls /etc/openldap/ 
certs  check_password.conf  ldap.conf  schema  slapd.d
[root@localhost]#

Then make sure our slapd service is running.

root@centos]# netstat -antup | grep slapd
tcp        0      0 0.0.0.0:389            0.0.0.0:*              LISTEN      1641/slapd
tcp6       0      0 :::389                 :::*                   LISTEN      1641/slapd
 
[root@centos]#

Next, let's configure our Open LDAP installation.

Make sure our system ldap user has been created.

[root@localhost]# id ldap 
uid=55(ldap) gid=55(ldap) groups=55(ldap)
[root@localhost]#

Generate our LDAP credentials.

[root@localhost]# slappasswd  
New password:  
Re-enter new password:  
{SSHA}20RSyjVv6S6r43DFPeJgASDLlLoSU8g.a10

[root@localhost]#

We need to save the output from slappasswd.

Configure Open LDAP

Step 1 − Configure LDAP for domain and add administrative user.

First, we want to set up our openLDAP environment. Following is a template to use with the ldapmodify command.

dn: olcDatabase={2}hdb,cn=config 
changetype: modify 
replace: olcSuffix 
olcSuffix: dc=vmnet,dc=local 
dn: olcDatabase = {2}hdb,cn=config 
changetype: modify 
replace: olcRootDN 
olcRootDN: cn=ldapadm,dc=vmnet,dc=local 
dn: olcDatabase = {2}hdb,cn=config 
changetype: modify 
replace: olcRootPW 
olcRootPW: <output from slap

Make changes to: /etc/openldap/slapd.d/cn=config/olcDatabase = {1}monitor.ldif with the ldapmodify command.

[root@localhost]# ldapmodify -Y EXTERNAL -H ldapi:/// -f /home/rdc/Documents/db.ldif  
SASL/EXTERNAL authentication started 
SASL username: gidNumber = 0+uidNumber = 0,cn=peercred,cn=external,cn=auth 
SASL SSF: 0 
modifying entry "olcDatabase = {2}hdb,cn=config" 
modifying entry "olcDatabase = {2}hdb,cn=config" 
modifying entry "olcDatabase = {2}hdb,cn=config" 

[root@localhost cn=config]#

Let's check the modified LDAP configuration.

root@linux1 ~]# vi /etc/openldap/slapd.d/cn=config/olcDatabase={2}hdb.ldif

[root@centos]# cat /etc/openldap/slapd.d/cn\=config/olcDatabase\=\{2\}hdb.ldif
 # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. 
 # CRC32 a163f14c
dn: olcDatabase = {2}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap
olcDbIndex: objectClass eq,pres
olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub
structuralObjectClass: olcHdbConfig
entryUUID: 1bd9aa2a-8516-1036-934b-f7eac1189139
creatorsName: cn=config
createTimestamp: 20170212022422Z
olcSuffix: dc=vmnet,dc=local
olcRootDN: cn=ldapadm,dc=vmnet,dc=local
olcRootPW:: e1NTSEF1bUVyb1VzZTRjc2dkYVdGaDY0T0k = 
entryCSN: 20170215204423.726622Z#000000#000#000000 
modifiersName: gidNumber = 0+uidNumber = 0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20170215204423Z

[root@centos]#

As you can see, our LDAP enterprise modifications were successful.

Next, we want to create an self-signed ssl certificate for OpenLDAP. This will secure the communication between the enterprise server and clients.

Step 2 − Create a self-signed certificate for OpenLDAP.

We will use openssl to create a self-signed ssl certificate. Go to the next chapter, Create LDAP SSL Certificate with openssl for instructions to secure communications with OpenLDAP. Then when ssl certificates are configured, we will have completed our OpenLDAP enterprise configuration.

Step 3 − Configure OpenLDAP to use secure communications with certificate.

Create a certs.ldif file in vim with the following information −

dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/certs/yourGeneratedCertFile.pem

dn: cn=config
changetype: modify
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/openldap/certs/youGeneratedKeyFile.pem

Next, again, use the ldapmodify command to merge the changes into the OpenLDAP configuration.

[root@centos rdc]# ldapmodify -Y EXTERNAL  -H ldapi:/// -f certs.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber = 0+uidNumber = 0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

[root@centos]#

Finally, let's test our OpenLADP configuration.

[root@centos]# slaptest -u 
config file testing succeeded 
[root@centos]#

Step 4 − Set up slapd database.

cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG && 
chown ldap:ldap /var/lib/ldap/*

Updates the OpenLDAP Schema.

Add the cosine and nis LDAP schemas.

ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif

Finally, create the enterprise schema and add it to the current OpenLDAP configuration.

Following is for a domain called vmnet.local with an LDAP Admin called ldapadm.

dn: dc=vmnet,dc=local
dc: vmnet
objectClass: top
objectClass: domain

dn: cn=ldapadm ,dc=vmnet,dc=local
objectClass: organizationalRole
cn: ldapadm
description: LDAP Manager

dn: ou = People,dc=vmnet,dc=local
objectClass: organizationalUnit
ou: People

dn: ou = Group,dc=vmnet,dc=local 
objectClass: organizationalUnit 
ou: Group

Finally, import this into the current OpenLDAP schema.

[root@centos]# ldapadd -x -W -D "cn=ldapadm,dc=vmnet,dc=local" -f ./base.ldif
 Enter LDAP Password:
adding new entry "dc=vmnet,dc=local"

adding new entry "cn=ldapadm ,dc=vmnet,dc=local"

adding new entry "ou=People,dc=vmnet,dc=local"

adding new entry "ou=Group,dc=vmnet,dc=local"

[root@centos]#

Step 5 − Set up an OpenLDAP Enterprise Users.

Open vim or your favorite text editor and copy the following format. This is setup for a user named "entacct" on the "vmnet.local" LDAP domain.

dn: uid=entacct,ou=People,dc=vmnet,dc=local 
objectClass: top
objectClass: account 
objectClass: posixAccount 
objectClass: shadowAccount 
cn: entacct 
uid: entacct 
uidNumber: 9999 
gidNumber: 100 
homeDirectory: /home/enyacct 
loginShell: /bin/bash 
gecos: Enterprise User Account 001 
userPassword: {crypt}x 
shadowLastChange: 17058 
shadowMin: 0 
shadowMax: 99999 
shadowWarning: 7

Now import the above files, as saved, into the OpenLdap Schema.

[root@centos]# ldapadd -x -W -D "cn=ldapadm,dc=vmnet,dc=local" -f entuser.ldif 
 Enter LDAP Password:
adding new entry "uid=entacct,ou=People,dc=vmnet,dc=local" 

[root@centos]#

Before the users can access the LDAP Enterprise, we need to assign a password as follows −

ldappasswd -s password123 -W -D "cn=ldapadm,dc=entacct,dc=local" -x "uid=entacct 
,ou=People,dc=vmnet,dc=local"

-s specifies the password for the user

-x is the username to which password updated is applied

-D is the *distinguished name" to authenticate against LDAP schema.

Finally, before logging into the Enterprise account, let's check our OpenLDAP entry.

[root@centos rdc]# ldapsearch -x cn=entacct -b dc=vmnet,dc=local
 # extended LDIF
 #
 # LDAPv3
 # base <dc=vmnet,dc=local> with scope subtree
 # filter: cn=entacct
 # requesting: ALL 
 # 
 # entacct, People, vmnet.local 
dn: uid=entacct,ou=People,dc=vmnet,dc=local 
objectClass: top 
objectClass: account 
objectClass: posixAccount 
objectClass: shadowAccount 
cn: entacct 
uid: entacct 
uidNumber: 9999 
gidNumber: 100 
homeDirectory: /home/enyacct 
loginShell: /bin/bash 
gecos: Enterprise User Account 001 
userPassword:: e2NyeXB0fXg= 
shadowLastChange: 17058 
shadowMin: 0 
shadowMax: 99999 
shadowWarning: 7

Converting things like /etc/passwd and /etc/groups to OpenLDAP authentication requires the use of migration tools. These are included in the migrationtools package. Then, installed into /usr/share/migrationtools.

[root@centos openldap-servers]# ls -l /usr/share/migrationtools/
total 128
-rwxr-xr-x. 1 root root  2652 Jun  9  2014 migrate_aliases.pl
-rwxr-xr-x. 1 root root  2950 Jun  9  2014 migrate_all_netinfo_offline.sh
-rwxr-xr-x. 1 root root  2946 Jun  9  2014 migrate_all_netinfo_online.sh
-rwxr-xr-x. 1 root root  3011 Jun  9  2014 migrate_all_nis_offline.sh
-rwxr-xr-x. 1 root root  3006 Jun  9  2014 migrate_all_nis_online.sh
-rwxr-xr-x. 1 root root  3164 Jun  9  2014 migrate_all_nisplus_offline.sh
-rwxr-xr-x. 1 root root  3146 Jun  9  2014 migrate_all_nisplus_online.sh
-rwxr-xr-x. 1 root root  5267 Jun  9  2014 migrate_all_offline.sh
-rwxr-xr-x. 1 root root  7468 Jun  9  2014 migrate_all_online.sh
-rwxr-xr-x. 1 root root  3278 Jun  9  2014 migrate_automount.pl
-rwxr-xr-x. 1 root root  2608 Jun  9  2014 migrate_base.pl

Step 6 − Finally, we need to allow access to the slapd service so it can service requests.

firewall-cmd --permanent --add-service=ldap 
firewall-cmd --reload

Configure LDAP Client Access

Configuring LDAP client access requires the following packages on the client: openldap, open-ldap clients, and nss_ldap.

Configuring LDAP authentication for client systems is a bit easier.

Step 1 − Install dependent packeges −

# yum install -y openldap-clients nss-pam-ldapd

Step 2 − Configure LDAP authentication with authconfig.

authconfig --enableldap --enableldapauth --ldapserver=10.25.0.1 --
ldapbasedn="dc=vmnet,dc=local" --enablemkhomedir --update

Step 3 − Restart nslcd service.

systemctl restart  nslcd

Linux Admin - Set Up Perl for CentOS Linux

 Perl has been around for a long time. It was originally designed as a reporting language used for parsing text files. With increased popularity, Perl has added a module support or CPAN, sockets, threading, and other features needed in a powerful scripting language.

The biggest advantage of Perl over PHP, Python, or Ruby is: it gets things done with minimal fuss. This philosophy of Perl does not always mean it gets things done the right way. However, for administration tasks on Linux, Perl is considered as the go-to choice for a scripting language.

Some advantages of Perl over Python or Ruby are −

• Powerful text processing

• Perl makes writing scripts quick and dirty (usually a Perl script will be several dozen lines shorter than an equivalent in Python or Ruby)

• Perl can do anything (almost)

Some drawbacks of Perl are −

• Syntax can be confusing

• Coding style in Perl can be unique and bog down collaboration

• Perl is not really Object Oriented

• Typically, there isn't a lot of thought put into standardization and best-practice when Perl is used.

When deciding whether to use Perl, Python or PHP; the following questions should be asked −

• Will this application ever need versioning?
• Will other people ever need to modify the code?
• Will other people need to use this application?
• Will this application ever be used on another machine or CPU architecture?

If the answers to all the above are "no", Perl is a good choice and may speed things up in terms of end-results.

With this mentioned, let's configure our CentOS server to use the most recent version of Perl.

Before installing Perl, we need to understand the support for Perl. Officially, Perl is only supported far back as the last two stable versions. So, we want to be sure to keep our development environment isolated from the CentOS version.

The reason for isolation is: if someone releases a tool in Perl to the CentOS community, more than likely it will be modified to work on Perl as shipped with CentOS. However, we also want to have the latest version installed for development purposes. Like Python, CentOS ships Perl focused on the reliability and not cutting edge.

Let's check our current version of Perl on CentOS 7.

[root@CentOS]# perl -v 
This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi

We are currently running Perl 5.16.3. The most current version as of this writing is: perl-5.24.0

We definitely want to upgrade our version, being able to use up-to-date Perl modules in our code. Fortunately, there is a great tool for maintaining Perl environments and keeping our CentOS version of Perl isolated. It is called perlbrew.

Let's install Perl Brew.

[root@CentOS]# curl -L https://install.perlbrew.pl | bash 
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current 
                             Dload  Upload   Total   Spent    Left  Speed 
100   170  100   170    0     0    396      0 --:--:-- --:--:-- --:--:--   397 
100  1247  100  1247    0     0   1929      0 --:--:-- --:--:-- --:--:--  1929

Now that we have Perl Brew installed, let's make an environment for the latest version of Perl.

First, we will need the currently installed version of Perl to bootstrap the perlbrew install. Thus, let's get some needed Perl modules from the CentOS repository.

Note − When available we always want to use CentOS Perl modules versus CPAN with our CentOS Perl installation.

Step 1 − Install CentOS Perl Make::Maker module.

[root@CentOS]# yum -y install perl-ExtUtils-MakeMaker.noarch

Step 2 − Install the latest version of perl.

[root@CentOS build]# source ~/perl5/perlbrew/etc/bashrc
[root@CentOS build]# perlbrew install -n -j4 --threads perl-5.24.1

The options we chose for our Perl install are −

• n − No tests

• j4 − Execute 4 threads in parallel for the installation routines (we are using a quadcore CPU)

• threads − Enable threading support for Perl

After our installation has been performed successfully, let's switch to our newest Perl environment.

[root@CentOS]# ~/perl5/perlbrew/bin/perlbrew use perl-5.24.1

A sub-shell is launched with perl-5.24.1 as the activated perl. Run 'exit' to finish it.

[root@CentOS]# perl -v

This is perl 5, version 24, subversion 1 (v5.24.1) built for x86_64-linuxthread-multi

(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2017, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the GNU General
Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on this system 
using "man perl" or "perldoc perl".  If you have access to the Internet, point your 
browser at http://www.perl.org/, the Perl Home Page.

[root@CentOS]#

Simple perl script printing perl version running within the context of our perlbrew environment −

[root@CentOS]# cat ./ver.pl  
#!/usr/bin/perl
print $^V . "\n";

[root@CentOS]# perl ./ver.pl  
v5.24.1 
[root@CentOS]#

Once perl is installed, we can load cpan modules with perl brew's cpanm −

[root@CentOS]# perl-brew install-cpanm

Now let's use the cpanm installer to make the LWP module with our current Perl version of 5.24.1 in perl brew.

Step 1 − Switch to the context of our current Perl version.

[root@CentOS ~]# ~/perl5/perlbrew/bin/perlbrew use perl-5.24.1

A sub-shell is launched with perl-5.24.1 as the activated perl. Run 'exit' to finish it.

[root@CentOS ~]#

Step 2 − Install LWP User Agent Perl Module.

[root@CentOS ~]# ~/perl5/perlbrew/bin/cpanm -i LWP::UserAgent

Step 3 − Now let's test our Perl environment with the new CPAN module.

[root@CentOS ~]# cat ./get_header.pl  
#!/usr/bin/perl 
use LWP; 
my $browser = LWP::UserAgent->new(); 
my $response = $browser->get("http://www.slcc.edu/"); 
unless(!$response->is_success) { 
   print $response->header("Server"); 
}

[root@CentOS ~]# perl ./get_header.pl  
Microsoft-IIS/8.5 [root@CentOS ~]#

There you have it! Perl Brew makes isolating perl environments a snap and can be considered as a best practice as things get with Perl.

Configure Ruby on CentOS Linux

 Ruby is a great language for both web development and Linux Administration. Ruby provides many benefits found in all the previous languages discussed: PHP, Python, and Perl.

To install Ruby, it is best to bootstrap through the rbenv which allows the administrators to easily install and manage Ruby Environments.

The other method for installing Ruby is the standard CentOS packages for Ruby. It is advisable to use the rbenv method with all its benefits. CentOS packages will be easier for the non-Ruby savvy.

First, let's get some needed dependencies for rbenv installer.

• git-core
• zlib
• zlib-devel
• gcc-c++
• patch
• readline
• readline-devel
• libyaml-devel
• libffi-devel
• openssl-devel
• make
• bzzip2
• autoconf
• automake
• libtool
• bison
• curl
• sqlite-devel

Most of these packages may already be installed depending on the chosen options and roles when installing CentOS. It is good to install everything we are unsure about as this can lead to less headache when installing packages requiring dependencies.

[root@CentOS]# yum -y install git-core zlib zlib-devel gcc-c++ patch readline 
readline-devel libyaml-devel libffi-devel openssl-devel make bzip2 autoconf 
automake libtool bison curl sqlite-devel 

Method 1 − rbenv for Dynamic Ruby Development Environments

Now as the user who will be using Ruby −

[rdc@CentOS ~]$ git clone https://github.com/rbenv/rbenv.git
[rdc@CentOS ~]$  https://github.com/rbenv/ruby-build.git

ruby-build will provide installation features to rbenv −

Note − We need to switch to root or an administration user before running install.sh

[rdc@CentOS ruby-build]$ cd ~/ruby-build
[rdc@CentOS ruby-build]# ./install.sh

Let's set our shell for rbenv and assure we have installedthe correct options.

[rdc@CentOS ~]$ source ~/rbenv/rbenv.d/exec/gem-rehash.bash

[rdc@CentOS ruby-build]$ ~/rbenv/bin/rbenv  
rbenv 1.1.0-2-g4f8925a 
Usage: rbenv <command> [<args>]

Some useful rbenv commands are −

Commands	Action
local	Sets or shows the local application-specific Ruby version
global	Sets or shows the global Ruby version
shell	Sets or shows the shell-specific Ruby version
install	Installs a Ruby version using ruby-build
uninstall	Uninstalls a specific Ruby version
rehash	Rehashes rbenv shims (run this after installing executables)
version	Shows the current Ruby version and its origin
versions	Lists all Ruby versions available to rbenv
which	Displays the full path to an executable
whence	Lists all Ruby versions that contain the given executable

Let's now install Ruby −

[rdc@CentOS bin]$ ~/rbenv/bin/rbenv install -v 2.2.1

After compilation completes −

[rdc@CentOS ~]$ ./ruby -v 
ruby 2.2.1p85 (2015-02-26 revision 49769) [x86_64-linux] 
[rdc@CentOS ~]$

We now have a working Ruby environment with an updated and working version of Ruby 2.X branch.

Method 2 − Install Ruby from CentOS Packages

This is the most simple method. However, it can be limited by the version and gems packaged from CentOS. For serious development work, it is highly recommended to use the rbenv method to install Ruby.

Install Ruby, needed development packages, and some common gems.

[root@CentOS rdc]# yum install -y ruby.x86_64 ruby-devel.x86_64 ruby-
libs.x86_64 ruby-gem-json.x86_64 rubygem-rake.noarch

Unfortunately, we are left with somewhat outdated version of Ruby.

[root@CentOS rdc]# ruby -v 
ruby 2.0.0p648 (2015-12-16) [x86_64-linux]
[root@CentOS rdc]#