rhel7 managing services with systemd

Tackling service management with Linux systemd

Systemd is a radical change from the old method of Linux service management. It provides a generic interface not just for services, but also for hardware management.

Until the launch of Linux Upstart a few years ago, Linux used an init-based startup procedure. Upstart was designed to make Linux startup more efficient, but it had a very short life. It was barely off the drawing board when systemd came along and replaced it on major Linux distributions as the method for service startup and management.

IT admins accustomed to finding service scripts in the /etc/[rc.d/]init.d directory of their favorite Linux distribution will notice they aren’t there anymore. All that remains are a limited number of services that don’t have a systemd startup script yet. On a Fedora system, the systemd services are in the /etc/system/system directory that contain symbolic links to the real location of the service scripts in usr/lib/system/system. In this directory, a subdirectory named multi-user.target.wants contains service scripts for the services that a system has installed.

In Linux systemd, the concept of runlevels was dropped. While booting, the computer goes through a series of phases, which are referred to as wants. The definition of a want is not as strict as the definition of a runlevel, so you will see differences here between the different Linux distributions. On a Fedora 17 system, for instance, you’ll find the following important wants:

  • sysinit.target.wants: contains scripts that have to be started at a very early stage
  • basic.target.wants: more scripts that have to be started at a very early stage
  • multi-user.target.wants: normal services that you typically need to have an operational system

In addition to these generic wants, there are some specific ones. You may find, for instance, the bluetooth.target.wants (to start Bluetooth) and the getty.target.wants used to initialize the ttys for users. In these wants you’ll find the service scripts themselves. But again, you’ll notice there are differences between the distributions, as every distribution can create its required wants.

The startup scripts themselves aren’t really startup scripts anymore. In the old startup procedure, bash shell scripts were used to launch services. Now you’ll find startup scripts that pass parameters required by systemd to start the services, which makes it very easy to understand how a service is started (see Example 1).

Example 1: A system-style init script for Linux systemd.

[root@IAD multi-user.target.wants]# cat sshd.service
[Unit]
Description=OpenSSH server daemon
After=syslog.target network.target auditd.service

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd-keygen
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

This very clean service script defines variables that systemd uses. All of the service scripts follow more or less the same syntax, which makes managing them a lot easier compared to the diverse init scripts.

Not only does systemd take care of items that were considered services in an init-based startup, it also handles part of hardware management. So when looking into the services system manages, administrators will see network devices, ttys and more.

Using systemctl to manage Linux services

The systemctl command, used for managing services, replaces old commands likeservice and chkconfig, which you’ll only have to use to manage old services that don’t have a systemd-compatible script. Start by typing systemctl by itself. This shows a list of all services Linux systemd manages as well as their current statuses (see Example 2).

Example 2: Use systemctl to show a list of services 

mdmonito…keover.service loaded active exited Software RAID Monitor Takeover
mysqld.service loaded active running MySQL database server
NetworkManager.service loaded active running Network Manager
nfs-idmap.service loaded active running NFSv4 ID-name mapping daemon
nfs-lock.service loaded active running NFS file locking service.
nfs-mountd.service loaded active running NFS Mount Daemon
nfs-rquotad.service loaded active running NFS Remote Quota Server
nfs-server.service loaded active exited NFS Server
ovirt-engine.service loaded active running oVirt Engine
postgresql.service loaded active running PostgreSQL database server
prefdm.service loaded active running Display Manager
rpcbind.service loaded active running RPC bind service
rsyslog.service loaded active running System Logging Service
rtkit-daemon.service loaded active running RealtimeKit Scheduling Policy Service
sendmail.service loaded active running Sendmail Mail Transport Agent
sm-client.service loaded active running Sendmail Mail Transport Client
smartd.service loaded active running Self Monitoring and Reporting Technology (SMART) Daemon
spice-vdagentd.service loaded active exited LSB: Agent daemon for Spice guests
sshd.service loaded active running OpenSSH server daemon
system-s…yboard.service loaded active running System Setup Keyboard
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running Login Service
systemd-…ollect.service loaded active exited Collect Read-Ahead Data

For status information about a specific service, use systemctl show followed by the name of the service. The service name typically includes the suffix .service, so use systemctl status sshd.service and not systemctl show sshd.

Systemctl has other useful display options as well, such as systemctl show servicename.service, which lists the current configuration of a particular service.

Example 3: Use systemctl status servicename.service to see the current status of a service

[root@IAD ~]# systemctl status sshd.service

sshd.service – OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: active (running) since Wed, 06 Mar 2013 07:44:53 +0100; 6h ago
Process: 1043 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
Main PID: 1085 (sshd)
CGroup: name=systemd:/system/sshd.service
â 1085 /usr/sbin/sshd -D

Mar 06 13:42:32 IAD.example.com sshd[4590]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:43:32 IAD.example.com sshd[4602]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:44:32 IAD.example.com sshd[4610]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:45:32 IAD.example.com sshd[4618]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:46:32 IAD.example.com sshd[4630]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:47:32 IAD.example.com sshd[4639]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:48:32 IAD.example.com sshd[4651]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:49:32 IAD.example.com sshd[4660]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:50:32 IAD.example.com sshd[4670]: Connection closed by 127.0.0.1 [preauth]
Mar 06 13:51:32 IAD.example.com sshd[4686]: Connection closed by 127.0.0.1 [preauth]

To start a service for the first time, use systemctl start servicename.service; to stop that service, use systemctl stop servicename.service. These allow you to start or stop a service once. If you want a service to start every time your computer boots, usesystemctl enable servicename.service. If you don’t want the service on your computer at all, use systemctl disable servicename.service.

Original page is here

Grub2 explained

Linux boot options in RHEL, SLES help ailing servers

GRUB2 and systemd present a major change for Linux boot options in Red Hat Enterprise Linux 7 and SUSE Linux Enterprise Server, including a change in how admins troubleshoot a server that doesn’t boot properly and requires essential recovery tasks.

When a Linux server boots, it first reads the GRUB2 configuration to discover which disk contains the root file system, as well as where to find the kernel and initramfs. If something is configured incorrectly, the system administrator must change the settings to allow the server to boot properly.

GRUB2 boot options

Figure 1. Editing GRUB2 boot options.

To do so, press the Escape key when GRUB2 loads to see available boot options. Select the option you want to modify and press e to enter the editor mode. This will show all the options that are loaded from the GRUB2 configuration files in /etc/default/grub and /etc/grub.d.

From the Linux boot options menu, select the line that you want to edit. Often, this is the line that loads the kernel. Some of the most important boot options have changed in RHEL 7 and SUSE LES. Systemd.units, or collections of systemd services that need to be started, replace runlevels, rescue mode and emergency mode.

Systemd.units provide many services for Linux boot options. And there are a few key systemd.unit services that all Linux administrators must know:

  • rescue.target: Rescue mode, which loads all the services needed for a fully operational system, but no network services or other non-essential services. It is comparable to runlevel 1 from the init boot procedure.
  • emergency.target: A minimal mode in which almost nothing is loaded. You’ll have a root file system, but very few services. This target can be compared to passing theinit=/bin/bash mode when starting on an init-based server.
  • multi-user.target: Replaces the runlevel 3. It is the basic mode a server starts in by default.
  • graphical.target: The new version of runlevel 5 that starts all services as well as the graphical interface.
  • poweroff.target: The old runlevel 0, which shuts down the server.
  • reboot.target: The old runlevel 6, which reboots a server.

To specify which targets to use during boot, pass them as an argument to the GRUB2 line that loads the kernel. To do this, you should either specify systemd.unit=emergency.target, or add the name of the target you want to start to the end of the line that loads the kernel.

Editing targets

Figure 2. Specifying the target you want to start at the end of the line that loads the kernel.

To enter any of these targets, use the systemctl command — as in systemctl isolate reboot.target. Distribution vendors keep the old commands operational to simplify the process. So if you cannot get accustomed to the new way of working, the telinit 6 command will work.

When you finish applying modifications to the line from the GRUB menu, use Ctrl-X to boot. Once in a specific mode, like emergency mode, type the systemctl command to find out which systemd services started. This provides an overview of all loaded services. In emergency.target mode, these will be minimal (see Figure 3).

Services in emergency.target mode

Figure 3. Getting an overview of currently loaded services.

After troubleshooting, use systemctl, followed by the name of the target you want to go, to restart the normal server state. For example, type systemctl isolate multi-user.target to start the equivalent of runlevel 3.

Changing GRUB2 default settings

If you entered the GRUB2 boot menu to modify the default GRUB2 startup, you should permanently apply them to GRUB2 configuration. Type the command grub2-mkconfig -o /boot/grub2/grub.cfg. This writes the settings you used to boot your server to the default GRUB2 configuration file /boot/grub2/grub.cfg. It only works if your grub configuration contained some real errors.

/etc/default/grub configuration file

Figure 4. The /etc/default/grub configuration file.

Change the grub configuration to change the default behavior of GRUB2. Start with the file /etc/default/grub, which contains most of the common GRUB2 settings you had to change. The GRUB_CMDLINE_LINUX line contains every option that your server’s kernel starts with by default. Modifying this line applies changes permanently.

Aside from the /etc/grub/default file, there are also files in the /etc/grub.ddirectory, which rarely require modification.

After applying changes to the GRUB2 configuration files, write them to your system with thegrub2-mkconfig -o /boot/grub2/grub.cfg command.

Original page here

RHEL 7 and firewalld

A few ways to configure Linux firewalld

Initially, firewalld looks difficult to use, but it really isn’t. Services and zones make it easy to put the pieces together and configure Linux firewalls.

Although it also works on the netfilter code in the Linux kernel, firewalld is totally incompatible with the old way to configure Linux firewalls. Red Hat Enterprise Linux 7 and other current distributions rely on this new method.

All examples of commands in this article are based on RHEL 7.

Firewalld works with zones

First, verify that firewalld is running. Use the command systemctl status firewalld(Listing 1).

Listing 1. This sequence shows that firewalld is active and running. Some lines were ellipsized; use -l when you try it to show them in full.

[root@rhelserver ~]# systemctl status firewalld

firewalld.service – firewalld – dynamic firewall daemon

   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)

   Active: active (running) since Thu 2014-05-22 07:48:08 EDT; 14min ago

 Main PID: 867 (firewalld)

   CGroup: /system.slice/firewalld.service

           └─867 /usr/bin/python -Es /usr/sbin/firewalld –nofork –nopid

May 22 07:48:08 rhelserver.example.com systemd[1]: Started firewalld – dynami…

Everything in firewalld relates to one or more zones.

After installation, a RHEL 7 server is normally in the public zone, but you may want to add it to another zone to easily configure firewall access. The command firewall-cmd --get-default-zone shows which zone you’re in, and firewall-cmd --get-zones shows the available zones. For detailed information about the configuration of a specific zone, you can use firewall-cmd --zone=zonename --list-all (Listing 2).

Listing 2. These commands show the zone or zones in which you’re setting up Linux firewalls.

root@rhelserver ~]# firewall-cmd –get-default-zone

public

 [root@rhelserver ~]# firewall-cmd –get-zones

block dmz drop external home internal public trusted work

[root@rhelserver ~]# firewall-cmd –zone=public –list-all

public (default, active)

  interfaces: ens33

  sources:

  services: dhcpv6-client sander ssh

  ports:

  masquerade: no

  forward-ports:

  icmp-blocks:

  rich rules:

Changing the current zone isn’t difficult: Use firewall-cmd --set-default-zone=home, for example, to change the default zone assignment from public to home.

Services and other building blocks

There are a few basic building blocks in the zones — services are the most important. Firewalld uses its own set of services that are configured using XML files in the directories /usr/lib/firewalld/services (for the system default services) and /etc/firewalld/services for services that you, the administrator, create. To configure services, create an XML file based on the example from Listing 3.

Listing 3. An example of a configuration of firewalld services.

[root@rhelserver services]# cat ftp.xml

<?xml version=”1.0″ encoding=”utf-8″?>

<service>

  <short>FTP</short>

  <description>FTP is a protocol used for remote file transfer. If you plan to make your FTP server publicly available, enable this option. You need the vsftpd package installed for this option to be useful.</description>

  <port protocol=”tcp” port=”21″/>

  <module name=”nf_conntrack_ftp”/>

</service>

Each service definition needs a short name, a description, a port section that specifies the protocol and port to be used, and a module name.

Listing 4. This example of a configuration file will create a firewalld service.

[root@rhelserver services]# cat sander.xml

<?xml version=”1.0″ encoding=”utf-8″?>

<service>

  <short>Sander</short>

  <description>Sander is a random service to show how service configuration works.</description>

  <port port=”666″ protocol=”tcp”/>

</service>

Once you have the right service file, use these commands to manipulate it.

The command firewall-cmd --list-services shows a list of all services that were found on your server. To add a service, use firewall-cmd --add-service yourservice to put it into the default zone, or add --zone=zonename to choose a specific zone.

Here’s how it works:

1. The command firewall-cmd --zone=public --list-all shows the current configuration of the public zone.

[root@rhelserver ~]# firewall-cmd –zone=public –list-all

public (default, active)

  interfaces: ens33

  sources:

  services: dhcpv6-client ssh

  ports:

  masquerade: no

  forward-ports:

  icmp-blocks:

  rich rules:

2. The command firewall-cmd --zone=public --add-service=ftp adds the FTP service to the public zone in the Linux firewall.

3. Verify that the FTP service was added successfully by repeating step 1. You will see it in the list of services.

4. Restart your server and repeat step 1. You will see that the FTP service has disappeared. In firewalld, nothing is permanent unless you use the option –permanent.

5. To add FTP to the public zone and make it a permanent setting, use firewall-cmd  --permanent --zone=public --add-service=ftp. It will now survive a reboot.

6. Type firewall-cmd --reload to apply all rules and reload the firewall.

It is extremely important when working with firewalld to use the --permanent option to make settings permanent.

Breaking the rules

Services are the preferred way of configuring firewalld, easily providing a global overview of what your firewall is doing. But if you don’t want to make your own service file in /etc/firewalld/service, you can add ports without them.

To assign a specific port to a specific zone, use a command like firewall-cmd --permanent --zone=dmz --add-port=22/tcp, then use firewall-cmd --zone=dmz --list-all to verify that the port was added successfully. While this is an uncomplicated way to add a port, going through services makes it easier to distribute similar rules across different hosts. Without services, files are hard to distribute, and rules in a configuration file are not that easy.

For even more control, you can — but shouldn’t — use a direct rule. Here’s why:

1. Type firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 80 -j ACCEPT.

2. Now type firewall-cdm --list-all to show the configuration for your default zone. Nothing was added that relates to port 80.

[root@rhelserver ~]# firewall-cmd –list-all

public (default, active)

  interfaces: ens33

  sources:

  services: dhcpv6-client ftp ssh

  ports:

  masquerade: no

  forward-ports:

  icmp-blocks:

  rich rules:

Nothing appears about the HTTP port you added because direct rules are writing to theiptables interface, not to firewalld.

3. To show direct rules, use firewall-cmd --direct --get-all-rules. Or use the deprecated command iptables -L instead.

Instead of direct rules, use rich rules, which are written to firewalld instead of iptables(Listing 5).

Listing 5. An example of a rich rule in Linux firewalld.

firewall-cmd –permanent –zone=public –add-rich-rule=”rule family=”ipv4″ source address=”192.168.4.0/24″ service name=”tftp” log prefix=”tftp” level=”info” limit value=”1/m” accept”

Firewalld rich rules offer a maximum amount of flexibility that is similar to what is possible on an iptables firewall.

Many things are accomplished and applied all in Listing 5’s one rule. The specification of IP family, source address and services name may be obvious, but note how the rule handles logging: A specific log prefix is defined, as well as a log level info and a limit value of one message per minute. max.

The Linux administrator can apply filters that look at more than just ports, so rich rules are particularly useful to filter on IP addresses (Listing 6).

Listing 6. This rich rule applies a filter on IP addresses for the Linux firewall.

firewall-cmd –permanent –zone=public –add-rich-rule=”rule family=”ipv4″ \

    source address=”192.168.0.4/24″ service name=”http” accept”

Analyzing zones

The firewall-cmd command is one of many methods to configure firewalld. Alternatively, you can edit the zone configuration file directly. This doesn’t give you any feedback on wrong syntax, but it’s a clean and straightforward configuration file that is easy to modify and distribute across multiple servers.

Listing 7. You can configure firewalld by editing the zone configuration file.

<?xml version=”1.0″ encoding=”utf-8″?>

<zone>

  <short>Public</short>

  <description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>

  <service name=”dhcpv6-client”/>

  <service name=”ssh”/>

  <rule family=”ipv4″>

    <source address=”192.168.4.0/24″/>

    <service name=”tftp”/>

    <log prefix=”tftp” level=”info”>

      <limit value=”1/m”/>

    </log>

    <accept/>

  </rule>

</zone>

The example in Listing 7 includes all that was added in the previous examples, written directly to the zone configuration file, with the exception of direct rules. Direct rules have their own configuration file:

[root@rhelserver firewalld]# cat direct.xml

<?xml version=”1.0″ encoding=”utf-8″?>

<direct>

  <rule priority=”0″ table=”filter” ipv=”ipv4″ chain=”INPUT”>-p tcp –dport 80 -j ACCEPT</rule>

</direct>

 

 

 

 

Came from here