Building a Secure Web Server with CentOS 5 - Part 1

12 Sep 2015 by rayheffer

This is the first of two Essential Linux Skills for CentOS blogs (See part 2). For many years I’ve become used to using service and chkconfig commands to manage services with RHEL (RedHat Enterprise Linux) and CentOS. In fact I first got my hands on a Unix system back in 1993, then got my first ever job as a Unix admin in 1996. I learned about SystemV runlevels, and then became used to using /etc/init.d/<service> to manage services. It takes a while to shake bad old habits, but CentOS 7 now uses systemd as the default init system.

Init (short for initialization) was the first process to start and the last to stop on a SysV (System V Unix) Linux system, and therefore we have the concept of runlevels. Each runlevel represents the state of the system, with runlevel 0 being shutdown (halt), 3 being multiuser mode (in other words it has now booted), and runlevel 5 is running the desktop environment if you use one (X Server starts and you have a desktop). Oh and runlevel 6 restarts the system.

Why is this important? Well, whether you like it or not, having core Linux skills is essential in the IT world we live in. In fact just a few weeks ago I was presenting at VMworld in San Francisco on VMware Horizon for Linux Virtual Desktops technical deep dive. I was approached after the session by a customer that has a project to deploy RHEL virtual desktops to hundreds of students in a college. He thanked me as he had to go home the following week to configure some of those virtual desktops with direct pass-through to NVIDIA GRID graphics cards. The process of doing that requires installation of the driver at runlevel 3, but he had no idea what it meant despite it being a simple command (init 3). It also meant that he learned about how to optimize RHEL by disabling unnecessary services that start at runlevel 3.

At VMware I see more and more customers deploying Linux desktops, but also server workloads are often running Linux (such as the server hosting this blog!), and virtual appliances.

SysV is still present on CentOS 7, but you’ll not find much there. If you run the following command, you can see which services are enabled at boot (runlevel 3).

# chkconfig --list | grep on

This will only show SysV services (for example, netconsole and network). You can also check the /etc/init.d/ directory.

systemd

Instead of /etc/init.d/ we now have /etc/systemd/system/. If you have a peek in there you’ll find our systemd targets and the symbolic link for default.target. These are what we know as runlevels, so just like we avoid watching old episodes of Friends, we’ll avoid using the term runlevel from now on!

drwxr-xr-x 2 root root 4096 Jul 7 2014 basic.target.wants
lrwxrwxrwx 1 root root 44 Jul 7 2014 dbus-org.freedesktop.Avahi.service -> /usr/lib/systemd/system/avahi-daemon.service
lrwxrwxrwx 1 root root 46 Jul 7 2014 dbus-org.freedesktop.NetworkManager.service -> /usr/lib/systemd/system/NetworkManager.service
lrwxrwxrwx 1 root root 57 Jul 7 2014 dbus-org.freedesktop.nm-dispatcher.service -> /usr/lib/systemd/system/NetworkManager-dispatcher.service
lrwxrwxrwx 1 root root 37 Jul 7 2014 default.target -> /lib/systemd/system/multi-user.target
drwxr-xr-x 2 root root 4096 Jul 7 2014 default.target.wants
drwxr-xr-x 2 root root 4096 Jul 7 2014 getty.target.wants
drwxr-xr-x 2 root root 4096 Sep 12 10:57 multi-user.target.wants
drwxr-xr-x 2 root root 4096 Jul 7 2014 sockets.target.wants
drwxr-xr-x 2 root root 4096 Jul 7 2014 system-update.target.wants

The two targets we’ll focus on are multi-user.target and graphical.target which are essentially runlevel 5 (oops I said it again, sorry). In our case we haven’t installed a desktop environment so we’re just concerned with multi-user.target (our default target).

You can list all the currently loaded targets using the following: # systemctl list-units -t target

Each service has 3 states; enabled, disabled or static. If a service is enabled it will start at boot. Static means it is typically dependent of other services and are controlled automatically.

To list enabled services use the following: # systemctl list-unit-files --type=service | grep enabled

auditd.service enabled
avahi-daemon.service enabled
chronyd.service enabled
crond.service enabled
dbus-org.freedesktop.Avahi.service enabled
dbus-org.freedesktop.NetworkManager.service enabled
dbus-org.freedesktop.nm-dispatcher.service enabled
getty@.service enabled
httpd.service enabled
irqbalance.service enabled
microcode.service enabled
NetworkManager-dispatcher.service enabled
NetworkManager.service enabled
rsyslog.service enabled
sshd.service enabled
sysstat.service enabled
systemd-readahead-collect.service enabled
systemd-readahead-drop.service enabled
systemd-readahead-replay.service enabled
tuned.service enabled

When a service is enabled it creates a symbolic link, usually at our multi-user target: /etc/systemd/system/multi-user.target.wants. Let’s take a look at this directory and we can see the symbolic links:

# cd /etc/systemd/system/multi-user.target.wants # ls -al

lrwxrwxrwx 1 root root 38 Jul 7 2014 auditd.service -> /usr/lib/systemd/system/auditd.service
lrwxrwxrwx 1 root root 44 Jul 7 2014 avahi-daemon.service -> /usr/lib/systemd/system/avahi-daemon.service
lrwxrwxrwx 1 root root 39 Jul 7 2014 chronyd.service -> /usr/lib/systemd/system/chronyd.service
lrwxrwxrwx 1 root root 37 Jul 7 2014 crond.service -> /usr/lib/systemd/system/crond.service
lrwxrwxrwx 1 root root 37 Sep 12 10:57 httpd.service -> /usr/lib/systemd/system/httpd.service
lrwxrwxrwx 1 root root 42 Jul 7 2014 irqbalance.service -> /usr/lib/systemd/system/irqbalance.service
lrwxrwxrwx 1 root root 46 Jul 7 2014 NetworkManager.service -> /usr/lib/systemd/system/NetworkManager.service
lrwxrwxrwx 1 root root 40 Jul 7 2014 remote-fs.target -> /usr/lib/systemd/system/remote-fs.target
lrwxrwxrwx 1 root root 39 Jul 7 2014 rsyslog.service -> /usr/lib/systemd/system/rsyslog.service
lrwxrwxrwx 1 root root 36 Jul 7 2014 sshd.service -> /usr/lib/systemd/system/sshd.service
lrwxrwxrwx 1 root root 39 Jul 8 2014 sysstat.service -> /usr/lib/systemd/system/sysstat.service
lrwxrwxrwx 1 root root 37 Jul 7 2014 tuned.service -> /usr/lib/systemd/system/tuned.service

To list all services, and the state and description of the service use: # systemctl list-units --type service (add --all to show services loaded but inactive)

To start/stop/restart services you can still use service, but the new command is:

# systemctl status <name> # systemctl stop <name> # systemctl start <name> # systemctl restart <name>

Practice

So let’s experiment with installing NTP with yum, checking the service status, starting it then enabling to start at boot (multi-user target).

# yum install ntp # systemctl list-units --type service --all | grep ntp

You’ll now see from the following that NTP is loaded but not active (I’ve added the headings in for clarity):

UNIT LOAD ACTIVE SUB DESCRIPTION
ntpd.service loaded inactive dead Network Time Service
ntpdate.service loaded inactive dead Set time via NTP
sntp.service not-found inactive dead sntp.service

# systemctl status ntpd # systemctl start ntp (if it’s not already running)

Let’s see if it’s running now: # systemctl list-units --type service --all | grep ntp

UNIT LOAD ACTIVE SUB DESCRIPTION
ntpd.service loaded active dead Network Time Service
ntpdate.service loaded inactive dead Set time via NTP
sntp.service not-found inactive dead sntp.service

We don’t need to include .service (ntpd.service) as systemctl will assume it’s a service you are specifying anyway.

Enable the service to start a boot:

# systemctl enable ntpd

Check again to see which services are enabled, and ntpd should now be listed:

# systemctl list-unit-files --type=service | grep enabled

You have now mastered systemd and can impress your friends with your elite systemctl command skills! :)

Comments are closed for this post.