Kernel 3 and Red Hat Enterprise Linux 7 new Systemd implementation

Intro:

Redhat and most major Linux distros such as Suse have adapted new Linux Kernel 3. Since release of Red Hat Enterprise Linux 7, Redhat replaces Linux Kernel 3 with the legacy kernel 2.6 in RHEL 6.7 and prior versions. Kernel 3 has improved handling of system services and runlevels. Kernel 2.6 System V "init" script for managing runlevels and "service", "chkconfig" commands for managing services have been replaced with "systemd" in Kernel 3.


Essential Commands:

I have collected a list of useful new commands to manage services, startup processes and runlevels for Linux Kernel 3.

Starting a service

Previously in RHEL 6 and prior:

# /etc/init.d/auditd start
Starting auditd:                                           [  OK  ]

Now in RHEL 7:

# systemctl start vsftpd.service


Stopping a service

Previously in RHEL 6 and prior:

# /etc/init.d/vsftpd stop
Stopping vsftpd:                                           [  OK  ]

Now in RHEL 7:

# systemctl stop vsftpd.service

Check the service status

Previously in RHEL 6 and prior:

# /etc/init.d/vsftpd status
vsftpd (pid 1309) is running...

Now in RHEL 7:

# systemctl status vsftpd.service      
vsftpd.service - Vsftpd ftp daemon
   Loaded: loaded (/usr/lib/systemd/system/vsftpd.service; disabled)
   Active: active (running) since Sat 2015-08-22 12:45:00 EDT; 12s ago
  Process: 8217 ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf (code=exited, status=0/SUCCESS)
 Main PID: 8218 (vsftpd)
   CGroup: /system.slice/vsftpd.service
           └─8218 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf

Aug 22 12:45:00 localhost.localdomain systemd[1]: Starting Vsftpd ftp daemon...
Aug 22 12:45:00 localhost.localdomain systemd[1]: Started Vsftpd ftp daemon.

Enabling a service at boot

Previously in RHEL 6 and prior:

# chkconfig vsftpd on

Now in RHEL 7:

# systemctl enable vsftpd.service
ln -s '/usr/lib/systemd/system/vsftpd.service' '/etc/systemd/system/multi-user.target.wants/vsftpd.service'

Disable a service at boot

Previously in RHEL 6 and prior:

# chkconfig vsftpd off

Now in RHEL 7:

# systemctl disable vsftpd.service
rm '/etc/systemd/system/multi-user.target.wants/vsftpd.service'

Show list of services starting during boot

Previously in RHEL 6 and prior:

# chkconfig --list
NetworkManager  0:off   1:off   2:on    3:on    4:on    5:on    6:off
abrt-ccpp       0:off   1:off   2:off   3:on    4:off   5:on    6:off
abrtd           0:off   1:off   2:off   3:on    4:off   5:on    6:off
acpid           0:off   1:off   2:on    3:on    4:on    5:on    6:off
atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
auditd          0:off   1:off   2:on    3:on    4:on    5:on    6:off
autofs          0:off   1:off   2:off   3:on    4:on    5:on    6:off
blk-availability        0:off   1:on    2:on    3:on    4:on    5:on    6:off
certmonger      0:off   1:off   2:off   3:on    4:on    5:on    6:off
cpuspeed        0:off   1:on    2:on    3:on    4:on    5:on    6:off
crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off

Now in RHEL 7:

# systemctl list-unit-files –type=service 
UNIT FILE                                   STATE   
abrt-ccpp.service                           enabled 
abrt-oops.service                           enabled 
abrt-pstoreoops.service                     disabled
abrt-vmcore.service                         enabled 
abrt-xorg.service                           enabled 
abrtd.service                               enabled 
accounts-daemon.service                     enabled 
alsa-restore.service                        static  
alsa-state.service                          static  
alsa-store.service                          static  
anaconda-direct.service                     static  
anaconda-nm-config.service                  static  
anaconda-noshell.service                    static  
anaconda-shell@.service                     static  
anaconda-sshd.service                       static  
anaconda-tmux@.service                      static  
anaconda.service                            static  
arp-ethers.service                          disabled
atd.service                                 enabled 
auditd.service                              enabled 
auth-rpcgss-module.service                  static  
autovt@.service                             disabled


Show the current runlevel(now "target")

systemd uses 'targets' instead of runlevels. By default, there are two main targets:
multi-user.target:  former runlevel 3
graphical.target: former runlevel 5

Previously in RHEL 6 and prior:

# cat /etc/inittab 
id:5:initdefault:

Now in RHEL 7:

# systemctl get-default
multi-user.target



Change the default runlevel(target)

To change from runlevel 3 to 5(target multi-user.target to graphical.target),

Previously in RHEL 6 and prior change the runlevel number in inittab file, e.g. from runlevel 5 to 3:

# cat /etc/inittab 
id:3:initdefault:

Now in RHEL 7 the location of default runlevel is in "/etc/systemd/system/default.target" and it can be set by following command:
# systemctl set-default graphical.target 
rm '/etc/systemd/system/default.target'
ln -s '/usr/lib/systemd/system/graphical.target' '/etc/systemd/system/default.target'

# systemctl get-default
graphical.target

Compatibility

Although legacy commands are still supported in RHEL 7 for time being for compatibility reasons but they may not have full power and will discounted in near future.
Legacy commands have been provided with a hint to new commands. e.g:

# chkconfig --list

Note: This output shows SysV services only and does not include native
      systemd services. SysV configuration data might be overridden by native
      systemd configuration.

      If you want to list systemd services use 'systemctl list-unit-files'.
      To see services enabled on particular target use
      'systemctl list-dependencies [target]'.

netconsole      0:off   1:off   2:off   3:off   4:off   5:off   6:off
network         0:off   1:off   2:on    3:on    4:on    5:on    6:off

which suggest to use "systemctl list-unit-files" instead of now legacy "chkconfig".

FreeIPA server client reinstallation failed

I've installed FreeIPA for central user management in Linux RHEL 6.5, other servers were connected to it as clients and doing user authentication and authorization correctly.

For some reasons, I decided to uninstall the server and reinstall it back.

However, this time after server reinstallation, I couldn't add other servers as client to FreeIPA and it fails with following error:

# ipa-client-install --domain=example.eu --server=vm1.example.eu --realm=EXAMPLE.EU -p admin  --password=123 --mkhomedir --hostname=vm1.example.eu

LDAP Error: Connect error: TLS error -8054:You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert.
LDAP Error: Connect error: TLS error -8054:You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert.
Failed to verify that ipaserver.example.eu is an IPA Server.
This may mean that the remote server is not up or is not reachable due to network or firewall settings.
Please make sure the following ports are opened in the firewall settings:
     TCP: 80, 88, 389
     UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working properly after enrollment:
     TCP: 464
     UDP: 464, 123 (if NTP enabled)
Installation failed. Rolling back changes.
IPA client is not configured on this system.

The reason is that the certificate from previous installation still exist and didn't purge with "ipa-client-install --uninstall" command.


Solution is to delete previous certificate manually and reinstallation of client will go smoothly afterward:

# rm /etc/ipa/ca.crt

Puppet multiple agents with same hostname issue

I have some servers in  my test environment which they have same hostanme.
It is kind of contradict to add them to puppet master as agents send certificate to be signed to master based on their hostnames. So if 2 servers have same hostname, they generate same certificate name and send to puppet master which obviously there is no way for master to differentiate them.

Solution:
We can define the certificate name for agent in its puppet config file, so we can give different certname than the hostname, and master can see those agents as though they have different hostnames.


1. Delete current agent certificates:

# rm -rf /var/lib/puppet/ssl/*


2. Define the certificate name in agent puppet config. If agent's hostname is client.example.com then:

# echo "certname=clientX.example.com" >> /etc/puppet/puppet.conf 


3. Restart puppet service in agent node:

# /etc/init.d/puppet restart


4. You should see new certificate ready to be signed in master with the "clientX" certificate name you have defined for "client" node:

# puppet cert list -all|grep clientX
  "clientX"                 (SHA256) D3:CA:74:4A:49:05:E6:8F:4C:64:A4:0E:D7:30:FD:EC:6A:24:C1:95:0C:58:2F:E0:8A:FE:93


5. So sign it and "client" node is ready to be managed by puppet master:

# puppet cert sign --all
Notice: Signed certificate request for clientX
Notice: Removing file Puppet::SSL::CertificateRequest clientX at '/var/lib/puppet/ssl/ca/requests/clientX.pem'