Six deployment steps for Linux services and their related tools
![6 deployment steps and their tools](/sysadmin/sites/default/files/styles/full/public/2020-06/123456-wall-decor-1329293%20Cropped.jpg?itok=AoFLTAfg)
Photo by Magda Ehlers from Pexels
Some years ago, I overheard another Linux instructor rattle off several steps to deploy a service in Linux. I jotted down the steps, and over time I have added some more information to them. The steps have been a part of my own Linux instructional deliveries ever since.
This topic is pretty fundamental for all you users out there who have been with Linux since the beginning. Of course, a review of the fundamentals is never a bad thing. For the newer Linux sysadmins, this checklist might serve as a way of organizing your deployment steps and reminding yourself about how Linux manages the services you maintain. I’m also going to note the tools you utilize for each step.
Perhaps you are deploying a basic website using Apache, or you’re standing up a new file server that relies on NFS. Whatever the case may be, you want to ensure that your deployment is successful.
Let’s get started!
Step 1: Is the service installed?
Service installation is obviously the most fundamental step. Many Linux distributions include only a minimal installation of services for security and performance reasons. For example, about the only network service you can count on to be installed by default is SSH. So, if you’re deploying an Apache webserver or an NFS file server, you probably have to install the software yourself.
Note: Remember that by having to install most applications yourself, you are subtly encouraged to use the most recent version. However, you are also given the freedom to use older software versions if those are necessary for compatibility reasons.
On RHEL-based distributions, ensure the service is installed by using the rpm
, yum
, or dnf
commands.
For example, run the following yum
command to ensure the Apache software is installed:
# yum list httpd
Step 2: Is the service configured?
As you are aware, Linux uses text files to manage service configuration. These files are usually stored in the /etc
directory. Once the service is installed, configure it by editing the associated configuration files.
For example, the primary Apache configuration file is /etc/httpd/conf/httpd.conf
. Use this file to define the initial settings for the web service.
Most sysadmins use vim
to edit configuration files. Nano
, gedit
, and even emacs
are also possible tools.
Here is an example of opening a configuration file by using my text editor of choice, vim
:
# vim /etc/httpd/conf/httpd.conf
Step 3: Is the service started?
Newly-installed and configured services must be started. Manually starting a service causes it to read the configuration file you edited in the previous step. The start procedure also launches the appropriate process (or processes) and makes the service functionality available to the user.
Most modern distributions rely on systemd
, so use the systemctl
command to start, stop, and restart services. Here is an example of starting Apache by using systemctl
:
# systemctl start httpd
Older systems may rely on the SysV
init environment. In those cases, use the following command to start the service:
# service httpd start
The problem with manually starting a service is that it is only active for the current runtime. If you reboot the server, the process does not automatically start. That fact leads us to step four below.
Step 4: Is the service persistent?
To cause the service to start each time the system boots up, you need to enable it. Remember, starting a service causes it to run in the current runtime while enabling the service causes it to start when the system starts. The two concepts are not interchangeable (in other words, enabling a service does not cause it to start).
On systemd-based distributions, manage the startup status of the service by using systemctl
. The actions are enable or disable. Here is an example:
# systemctl enable httpd
On SysV-based systems, use the chkconfig
command to control the startup status of the service. For example, to ensure the service starts in runlevels 3 and 5, enter the following command:
# chkconfig --level 35 httpd on
Step 5: Did you test the service?
Now that you have installed, configured, started, and enabled the service, it’s time to ensure the service functions as intended. Can you display the Apache test web page? Can you access the directories you exported with NFS? Don’t forget that for network services, you almost certainly have to configure the firewall, as well. That task is outside the scope of this discussion, but the information is readily available online.
During the test phase, you may want to confirm that the appropriate log files are generated, and that log entries match the required severity. Begin by reviewing the /etc/rsyslog.conf
file, as well as the service’s man page.
Step 6: Did you change the service?
Did you make any changes to the service’s configuration file while testing? If so, you need to restart the service so that it rereads the file. You also need to consider any future configuration file edits that you make during the service’s lifecycle. Here are examples of restarting a service on both systemd and SysV-based systems:
# systemctl restart httpd
# service httpd restart
Wrap up
I hope that this fundamental summary of service deployment steps and tools has been helpful. By establishing a mental checklist that verifies each of these steps, you help to ensure that your service deployments are successful.
Remember - start and enable are not interchangeable terms, and they are separate actions. The same applies to stop and disable. Be aware of whether you are working with a systemd-based distribution or a distribution that uses SysV.
Here is a summary of the steps and tools:
- Installed? rpm, yum, dnf
- Configured? vim, nano
- Started? systemctl or service
- Persistent? systemctl or chkconfig
- Tested? ping or standard client software
- Reconfigured? systemctl or service
[ Want to try out Red Hat Enterprise Linux? Download it now for free. ]
![Author’s photo](/sysadmin/sites/default/files/styles/user_picture_square/public/pictures/2020-06/DMG_Pic.jpg?itok=0DVbrcG4)
Damon Garn
Damon Garn owns Cogspinner Coaction, LLC, a technical writing, editing, and IT project company based in Colorado Springs, CO. Damon authored many CompTIA Official Instructor and Student Guides (Linux+, Cloud+, Cloud Essentials+, Server+) and developed a broad library of interactive, scored labs. He regularly contributes to Enable Sysadmin, SearchNetworking, and CompTIA article repositories. Damon has 20 years of experience as a technical trainer covering Linux, Windows Server, and security content. He is a former sysadmin for US Figure Skating. He lives in Colorado Springs with his family and is a writer, musician, and amateur genealogist. More about me