CentOS 7 Configuration

Basic CentOS 7 Configuration


This is a basic guide to setting up a CentOS 7 image from Linode. The CentOS 7 images they host may change from time to causing some portions of this document to no longer be 100% accurate, but that does not happen very often.

This guide assumes some familiarity with how to use a UNIX shell account, using SSH to connect to a server, and using a text editor from a command line interface to modify a text file.

  1. UNIX Shell Basics
  2. SSH Basics
  3. VIM Basics

Hostname and DNS

By default, your hostname will be something that is a sub-domain of your hosting provider (e.g. linode).

Generally speaking, you probably want a vanity fully qualified domain name of the form hostname.domain.tld where domain.tld is the domain you registered at a domain registry.

Please note that these do NOT need to match the fully qualified domain name you will use with a web server. They can and often do, but they do not need to.

If you do not have a domain, I recommend Namecheap. I have used them for almost a decade now, they are very good and they have excellent customer service.

Anyway, set the fully qualified domain name in your CentOS 7 VM:

[root@li219-112 ~]# hostnamectl set-hostname git.domblogger.net

Obviously replace git.domblogger.net with your own.

Next time you log in, instead of the Linode assigned meaningless host, you should see the hostname portion of your fully qualified domain name in your shell prompt.

DNS Records

You should set up DNS records to resolve your fully qualified domain name to the IP address of the VM. With Linode, you will have both an IPv4 address and an IPv6 address. The IPv4 address goes in an A record and the IPv6 address in an AAAA record. For example, in the domblogger.net zone file I have:

git		IN	A
git		IN	AAAA	2600:3c01::f03c:91ff:fed8:1c0a

If using Linode to host the VM, I recommend using their DNS services over those provided by your registrar.

Linode has  a decent write-up on DNS if you need it: https://www.linode.com/docs/networking/dns/dns-records-an-introduction/

Reverse DNS Records

These are set by your hosting provider, they can not be set in your own zone file.

Once the DNS is set up and resolving, set up the Reverse DNS to point to your hostname. If you just set up your DNS records, skip this step and come back to it in a day or so. If your A and AAAA records are already correctly resolving, you can do it now.

In your Linode console, go to your Remote Access panel and in the area for Public IPs, there will be a link for Reverse DNS.

When you click on it, there will be a simple form where you can enter the hostname. Enter the fully qualified domain name and press the “Look Up” button.

If Linode can resolve the A and AAAA records for your fully qualified domain name and they match the IP addresses Linode has assigned to you, it will give you buttons to set the Reverse DNS for the IPv4 and IPv6 addresses.

System Mail Setup

CentOS 7 ships with postfix as the default MTA (Mail Transport Agent) and that is an appropriate choice. To properly function, however, it needs to be configured.

These instructions are NOT intended to help you set up a SMTP server that receives mail from other servers. That is a more advanced topic and should not be done lightly.

Rather, these instructions are intended to help your system send mail. This is necessary for your system to send you alerts such as a list of available updates or alert you to an expired TLS certificate that is in use.

0. Pre-requisites

You need to have both reverse DNS set up and your hostname properly set up, or mail sent by your server may be rejected or flagged as spam. Make sure you have your firewall running and that Port 25 is blocked so that your server is not an open relay in the event of a postfix misconfiguration.

1. Install MailX

The /bin/mail command is a standard UNIX shell command that many scripts will assume is available on your system. It is also needed to test that things work.

[root@host ~]$ yum install mailx

2. Configure Postfix

If you properly set up your hostname, chances are you do not need to do any postfix configuration at all, but you should check it.

Run the command

[root@host ~]# postconf |grep "^myhostname"

That should correspond with your fully qualified domain name, e.g. git.domblogger.net for my git server. If it does not, edit the file /etc/postfix/main.conf

Where it read:

# The myhostname parameter specifies the internet hostname of this
# mail system. The default is to use the fully-qualified domain name
# from gethostname(). $myhostname is used as a default value for many
# other configuration parameters.
#myhostname = host.domain.tld
#myhostname = virtual.domain.tld

After the end of that comment block, add

myhostname = git.domblogger.net

replacing git.domblogger.net with your hostname.

Next, run the command:

[root@host ~]# postconf |grep "^mydomain"

That should correspond with your domain, e.g. domblogger.net for my git server. If it does not, edit the file /etc/postfix/main.conf

Where it read:

# The mydomain parameter specifies the local internet domain name.
# The default is to use $myhostname minus the first component.
# $mydomain is used as a default value for many other configuration
# parameters.
#mydomain = domain.tld

After the end of that comment block, add

mydomain = domblogger.net

replacing domblogger.net with your domain.

Finally run the command

[root@host ~]# postconf |grep "^inet_interfaces"

That should return

inet_interfaces = localhost

You do NOT want to be an open relay, so unless this is a destination SMTP server, you only want to have postfix listen on the localhost and not on an interface that can be connected to from another machine. If localhost is not the only result, edit /etc/postfix/main.conf and change the inet_interfaces definition so it looks like:

inet_interfaces = localhost

3. Enable and Start Postfix

This is very simple:

[root@host ~]# systemctl enable postfix.service
Created symlink from /etc/systemd/system/multi-user.target.wants/postfix.service to /usr/lib/systemd/system/postfix.service.
[root@host ~]# systemctl start postfix.service

Unless there is a bad error in your postfix configuration, postfix is now running and configured to run at system boot.

4. Test Postfix

Send a test e-mail to yourself:

[root@host ~]# echo "test" |mail -s "test e-mail" username@example.org

Where username@example.org is your actual e-mail address. Check your mail, it should have a message from root 🙂

If not, it may be caused by a spam filter. zen.spamhaus.org is particularly bad. Very often either the IP addresses you now have or IP addresses close to them were used for spamming and your server will be on a blacklist.

In such cases, white list your host by IP address, both the IPv4 and the IPv6 address. Talk to the mail administrator of the service you use for e-mail. Probably a good idea to do that even if you are not currently on the zen blacklist.

5. Configure Your /etc/aliases File

At the very bottom of your system /etc/aliases file, you will see the following:

# Person who should get root's mail
#root:          marc

Append an uncommented alias to that so it looks like

# Person who should get root's mail
#root:          marc
root:           awonder

Replace awonder with your administrative login name. Then run the /bin/newaliases command:

[root@host ~]$ /bin/newaliases

Mail sent on your system to the root user will now be redirected to that administrator.

6. Forward e-mail to your real e-mail

Now, log in as your administrative user (e.g. awonder) and run the following two commands:

[user@host ~]$ echo "username@example.org" > ~/.forward
[user@host ~]$ echo "test forward" |mail -s "test forward" root@localhost

The first sets up your ~/.forward file in your administrative account so that any mail it receives gets forwarded to username@example.org and the second command tests the system. You are sending a test e-mail to the root user. The /etc/aliases file should result in that being forwarded to your administrator account, and the ~/.forward file in your administrator account should result in it being sent through postfix to username@example.org.

Go check your e-mail. If you got it, things are set up correctly and username@example.org will now receive all important messages on your system.

System Updates

CentOS 7 can be configured to automatically download all available updates once a day and send an e-mail when they are ready, so that all you need to do is log in to the system and apply the updates.

It also can be configured to just apply them but I do not recommend that because you then are not there to deal with something gone wrong.

Install the YUM cron package:

[root@host ~]# yum install yum-cron

For most systems, the default configuration is exactly what you want. It actually installs two configuration files:


By default, the hourly configuration is set to not do anything and the daily configuration is set to download any updates and e-mail the root account when there are updates it has downloaded that are ready for install.

If you set up the system mail correctly, that e-mail will then get sent to your regular e-mail.

Enable and start the service:

[root@host ~]# systemctl enable yum-cron.service
[root@host ~]# systemctl start yum-cron.service

The notification e-mails will look something like the following:


The following updates will be downloaded on git.domblogger.net:
 Package                Arch        Version                  Repository    Size
 kernel                 x86_64      3.10.0-862.3.3.el7       updates       46 M
 caddy                  x86_64      0.11.0-1.el7             epel         3.8 M
 kernel-tools           x86_64      3.10.0-862.3.3.el7       updates      6.2 M
 kernel-tools-libs      x86_64      3.10.0-862.3.3.el7       updates      6.2 M
 python-perf            x86_64      3.10.0-862.3.3.el7       updates      6.2 M

Transaction Summary
Install  1 Package
Upgrade  4 Packages
Updates downloaded successfully.

When you get an e-mail letting you know there are updates, just log in to the system and run:

[root@host ~]# yum update

The updates will already have been downloaded resulting in a fast install.

WARNING: Personal experience has taught me to always always backup the MariaDB database and shut it down before applying updates that include MariaDB. Usually it goes smoothly, but having a backup from just before applying is critical, and turning it off prevents the update process from hanging if something goes wrong.

With backup followed by shutdown of the service, sometimes starting it again after MariaDB has been updated takes a few seconds, but so far that procedure has not resulted in a need to recover the database.

You do not need to worry about shutting MariaDB down when the updates do not include MariaDB packages.

Anonymity protected with AWM Pluggable Unplugged