Basic CentOS 7 Configuration
DRAFT WORKING ON DRAFT WORKING ON NOT NEARLY READY
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.
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
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
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.
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 188.8.131.52 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
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
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.
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
/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
Where it read:
# INTERNET HOST AND DOMAIN NAMES # # 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
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
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
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" email@example.com
firstname.lastname@example.org is your actual e-mail address. Check your mail, it should have a message from
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
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
awonder with your administrative login name. Then run the
[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 "email@example.com" > ~/.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
firstname.lastname@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
Go check your e-mail. If you got it, things are set up correctly and
email@example.com will now receive all important messages on your system.
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:
/etc/cron.daily/0yum-daily.cron: The following updates will be downloaded on git.domblogger.net: ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: kernel x86_64 3.10.0-862.3.3.el7 updates 46 M Updating: 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.