Red Hat recently released several high-quality articles about:

• the Benefits of Red Hat Enterprise Linux for Real Time explains what is an enterprise environment for real-time workloads,
• combining PTP with NTP to get the best of both worlds describes the differences between PTP and NTP, and how they can be used together.
• thinking through an identity management deployment discusses best practices when deploying an identity management.

Be sure to read them if the subject interests you, you will not waste your time!

With RHEL 7, it is pretty well known that performance configuration is made easy through the tuned tool. Specifying a profile in a list or creating one from some existing can be done quickly. A tutorial already explains how to Apply a tuning profile to a server.

However, what is less known is you can ask the tuned tool to operate in a dynamic way.
By assigning 1 to the dynamic_tuning parameter in the /etc/tuned/tuned-main.conf file, every 10 seconds by default the server configuration is updated.
After restarting the tuned service (# systemctl restart tuned), you can then check the dynamic adjustments in progress in the /var/log/tuned/tuned.log file.

This could be handy when you are searching for the best configuration.

One week ago, Raj left a comment on this website saying the current version used for the RHCSA/RHCE exams was now RHEL 7.1.
Although I had no reason not to believe him, I wanted a confirmation that I got a day after by training-uk@redhat.com.

In my recent post, I slightly blamed Jang/Orsaria‘s book for omitting to include any instruction changes coming with the new minor versions of RHEL 7. Now buyers of this book can start fixing tutorials (mainly NFS configuration, client and server sides, and LDAP client configuration). Bad luck for a pretty good book published at the end of April 2016 and already partially obsolete in June 2016!

Concerning Red Hat, it is already surprising that not a single feedback is provided in the exam results. But it is even more difficult to understand why Red Hat is not clearly announcing the RHEL minor version used in exam on its website: you have to ask to get the answer!

Because Red Hat is preparing its summit at the end of June, new presentations are available on several domains:

• Systemd: nothing new but a nice presentation,
• RHEL 7 Performance: a nice update about performances,
• Identity Management: a very detailed presentation about the state of the art,
• RHEV: a quick presentation and status on the KVM-based virtualization solution.

I hope you will find them interesting!

To read more than 900 pages takes time and motivation.

Mr Jang, Mr Orsaria and their proofreaders did a good job: there are very few typos and the quality is there.
Except the lack of coverage of the LDAP server configuration, very useful for testing the client side, all the topics are explained at considerable length and in a pretty expert manner.

Also, the awkward KVM presentation of the previous edition has been seriously improved.

Finally, I’ve got only one critic: all the configurations assume the RHEL 7.0 version. When the exams move to RHEL 7.1 or RHEL 7.2, you will have to buy a new edition (hopefully, this may never happen!).

Traditionally, to test the configuration of Postfix you had to install a full featured DNS server. This was due to the MX records mechanism. When you send a mail outside, the MTA (Mail Transfer Agent) sends a request to the DNS server responsible (the term normally used is authoritative) for the domain name specified in the recipient’s email address to get the MX records. These MX records give you the name of the servers handling the mails for the recipient’s domain. So, if you’ve got a domain called example.com, you need a way to define which servers in this domain are in charge of the mail delivery. The mail is sent to the mail server with the lowest value. If that failed, the mail is then sent to the one with the slightly higher value, etc.

For example, if you’ve got two servers managing mails for your domain, the DNS configuration is as follows:

example.com 86400 MX 10 mail.example.com
                     20 mail2.example.com

This DNS requirement makes Postfix configuration slightly more complicated because you need to be sure of your DNS configuration and it’s sometimes delicate in a lab environment.

However, there is a directive in Postfix called disable_dns_lookups that stops this behavior altogether. When set to yes, Postfix only relies on the local /etc/hosts file, which makes everything easier.

The RHEL 6.8 has just been released and brings the following main benefits:

• it enhances security by replacing openswan with libreswan as VPN endpoint solution,
• it makes integration with Active Directory easier through SSSD improvements (cached authentication lookup, authentication via smart cards) and support for adcli,
• it adds the new system archiving tool, Relax-and-Recover, enabling systems administrators to create local backups in an ISO format, simplifying disaster recovery operations,
• it now supports xfs filesystem sizes up to 300TB through the Scalable File System Add-on.

With the RHEL 6.8 release, this also marks the transition of Red Hat Enterprise Linux 6 into Production Phase 2. According to Red Hat Enterprise Linux lifecycle, this mainly means:

• no additions of new functionality beyond correcting defects,
• no implementation of previously existing features on a new hardware generation.

Rumors about Btrfs being deprecated are false and are only due to a poor wording in the technical notes.

Finally, you will find all the details in the RHEL 6.8 Releases Notes & RHEL 6.8 Technical Notes.

Since Systemd v213 and consequently with RHEL 7.2, a new resource control option called CPUQuota is now available.

Last year I wrote a post on the CPUShares option.

I decided to revisit it with this new CPUQuota option.

Caution: The following tutorial shouldn’t be run on a production server! The CPU will be used at 100%!

As in the previous post, I created a basic Systemd unit file called /etc/systemd/system/testSpeed.service:

[Unit]
Description=Test Speed
After=syslog.target

[Service]
ExecStart=/usr/bin/openssl speed 
ExecStop=/bin/kill -WINCH ${MAINPID}

[Install]
WantedBy=multi-user.target

Then, I created another copy of this file and updated the Systemd configuration:

# cd /etc/systemd/system; cp testSpeed.service testSpeed2.service
# systemctl daemon-reload

I started both new services on a fresh standard install of Centos 7.2 on a VM with 1 vCPU:

# systemctl start testSpeed testSpeed2

Each of the two new services were using almost 50% of the CPU time (excerpt of the top command execution):

  PID USER      PR  NI S %CPU %MEM     TIME+ COMMAND      
24598 root      20   0 R 49.8  0.3   0:08.42 openssl      
24601 root      20   0 R 49.8  0.3   0:08.40 openssl      

I checked the default CPUQuota property of the testSpeed service:

# systemctl show testSpeed | grep CPUQuota
CPUQuotaPerSecUSec=infinity

Note: Don’t ask me why the option is called CPUQuota and the property CPUQuotaPerSecUSec, I don’t know!

Because I wanted to learn how CGroups were working, I decided to apply a CPU constraint:

# systemctl set-property testSpeed CPUQuota=10%

Note: You don’t need to restart any service. The % character is not optional.

Now, the testSpeed service gets 10% of the CPU time and the testSpeed2 gets 90%:

  PID USER      PR  NI S %CPU %MEM     TIME+ COMMAND      
24601 root      20   0 R 90.0  0.3   1:23.58 openssl      
24598 root      20   0 R 10.0  0.3   1:22.20 openssl      

The CPUQuota property of the testSpeed & testSpeed2 services is now as follows:

# systemctl show testSpeed | grep CPUQuota
CPUQuotaPerSecUSec=100ms
DropInPaths=/etc/systemd/system/testSpeed.service.d/50-CPUQuota.conf
# systemctl show testSpeed2 | grep CPUQuota
CPUQuotaPerSecUSec=infinity

What exactly happened?

With the CPUShares option, you assigned a percentage of CPU time to a service. With the CPUQuota option, you now set a duration in millisecond. This duration is the maximum of CPU time allowed to a service per second. This service can get an amount of CPU time below but not above this limit.

The behaviour of the CPUQuota option is much easier to understand than the CPUShares‘.

Look at my CGroups page to get some other tips on this topic.

Some additional information is available in the systemd.resource-control man page.

One of the main changes that occurred in the RHCE 7 exam was the new objective regarding MariaDB. You can be a very experimented system administrator and never deals with databases. Not only you are asked to install the database system but you are also supposed to know how to create a database, create tables and manipulate SQL instructions.

SQL syntax is not so easy to learn. Even though nobody expects you to be a SQL master, correctly applying a create table statement requires some time.

Hopefully, MariaDB provides a nice solution to this problem through the help command. When you don’t remember a syntax detail, the help command should be a reflex.

MariaDB [db]> help update
Name: 'UPDATE'
Description:
Syntax:
Single-table syntax:

UPDATE [LOW_PRIORITY] [IGNORE] table_reference
SET col_name1={expr1|DEFAULT} [, col_name2={expr2|DEFAULT}] ...
[WHERE where_condition]
[ORDER BY ...]
[LIMIT row_count]

Multiple-table syntax:

UPDATE [LOW_PRIORITY] [IGNORE] table_references
SET col_name1={expr1|DEFAULT} [, col_name2={expr2|DEFAULT}] ...
[WHERE where_condition]

Sometimes like with the grant command, you even get some examples!

As usual, don’t rely too much on this feature, otherwise you will waste too much time and won’t be able to complete your exam in time.

Thanks to Sam and krz for sharing their knowledge.

Most system administrators know the tail command. By default, it displays the 10 last lines of a file.

The -f option is less known. Besides displaying the last 10 lines of a file, it mainly provides a way to watch what is written into a file in real-time:

# tail -f /var/log/messages
Apr  4 20:30:01 vm systemd: Stopping user-0.slice.
Apr  4 20:31:35 vm systemd: Created slice user-0.slice.
Apr  4 20:31:35 vm systemd: Starting user-0.slice.
Apr  4 20:31:35 vm systemd: Started Session 961 of user root.
Apr  4 20:31:35 vm systemd-logind: New session 961 of user root.
Apr  4 20:31:35 vm systemd: Starting Session 961 of user root.
Apr  4 20:31:35 vm dbus[590]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
Apr  4 20:31:35 vm dbus-daemon: dbus[590]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
Apr  4 20:31:35 vm dbus[590]: [system] Successfully activated service 'org.freedesktop.problems'
Apr  4 20:31:35 vm dbus-daemon: dbus[590]: [system] Successfully activated service 'org.freedesktop.problems'
Apr  4 20:33:53 vm systemd: Started Session 962 of user root.
Apr  4 20:33:53 vm systemd-logind: New session 962 of user root.
Apr  4 20:33:53 vm systemd: Starting Session 962 of user root.
...

When debugging complicated situations involving several files, the tail command proves to be a invaluable tool. In fact, you can specify several files after the -f option and a header will be displayed each time something is written into a different file:

# tail -f /var/log/messages /var/log/secure
==> /var/log/messages <== 
Apr 4 20:51:07 vm systemd-logind: Removed session 963. 

==> /var/log/secure <== 
Apr 4 20:51:11 vm sshd[21933]: Accepted password for root from 94.23.44.29 port 47411 ssh2 

==> /var/log/messages <== 
Apr 4 20:51:11 vm systemd: Started Session 966 of user root. 
Apr 4 20:51:11 vm systemd-logind: New session 966 of user root. 

==> /var/log/secure <== 
Apr 4 20:51:11 vm sshd[21933]: pam_unix(sshd:session): session opened for user root by (uid=0)

==> /var/log/messages <==
Apr 4 20:51:11 vm systemd: Starting Session 966 of user root.

...

For example, OpenStack engineers use this kind of command to debug their configuration on compute nodes:

# tail -f /var/log/{ceilometer,neutron,nova,openvswitch}/*.log /var/log/syslog

When troubleshooting, using the tail command should become a reflex!