Rsyslog tip.

When you are about to deploy an application, you’ve got a lot of problems to solve.
How are you going to deal with backups, monitoring, filtering admin connections?

One of these problems concerns the management of system and application messages.
There are many available options. One of them is to use rsyslog.

With rsyslog, you can store system and application messages into local files or/and send them to a remote server according to the configuration located in the /etc/rsyslog.conf file or the /etc/rsyslog.d directory.

However, what happens if your central rsyslog server is not available because of maintenance or failure? You loose all your platform messages during this time! This is not good.

But, there is a solution: you can perfectly configure two or several remote rsyslog servers in your client configuration (still in /etc/rsyslog.conf) as follows:

# ### begin forwarding rule ###
$ActionQueueFileName fwdRule1 # unique name prefix for spool files
$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible)
$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
*.* @@remote-host1:514
$ActionExecOnlyWhenPreviousIsSuspended on
& @@remote-host2:514
& @@remote-host3:514
$ActionExecOnlyWhenPreviousIsSuspended off
# ### end of the forwarding rule ###

Then, check the syntax:

# rsyslogd -N 1
rsyslogd: version 7.4.7, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: warning: ~ action is deprecated, consider using the 'stop' statement instead [try ]
rsyslogd: End of config validation run. Bye.

This way, all the messages go to the remote-host1 server by default. If the remote-host1 server doesn’t answer, messages are sent to the remote-host2 server, then to the remote-host3 server if the previous server doesn’t reply.

You can find all the details in the tutorial about Configuring a system to log to a remote system.

There are certainly other options but this one is pretty simple and works fine.

Note: Rsyslog was an RHCE 6 objective but doesn’t appear in the RHCE 7 objectives anymore.

Posted in RHEL7

RHEL 7.2 new goodies.

The RHEL 7.2 release doesn’t only bring an important Systemd update (v219). It also contains several goodies, some still to discover.

Among these, two come to my mind.

Firstly, several Firewalld configuration files have been added making administrator’s life easier:

  • iscsi-target allows TCP-UDP/3260,
  • rsyncd allows TCP-UDP/873,
  • freeipa-ldap allows TCP/80, TCP/443, TCP-UDP/88, TCP-UDP/464, UDP/123, TCP/389,
  • freeipa-ldaps allows TCP/80, TCP/443, TCP-UDP/88, TCP-UDP/464, UDP/123, TCP/636,
  • freeipa-replication allows TCP/7389.

As an exercise for RHCE candidates, you can guess which protocols are specified in the freeipa-ldap* lists.

Secondly, a nice shortcut has been introduced. Instead of typing:

# systemctl enable httpd ntpd
# systemctl start httpd ntpd

You can now type:

# systemctl enable --now httpd ntpd

This also works with the –disable and –mask options.

Remember, this is only coming with the RHEL 7.2 release. As the exams still don’t use this version (they use RHEL 7.0 or RHEL 7.1), you can’t use these goodies now.

Posted in RHEL7

Recent high-quality Red Hat articles.

Red Hat recently released several high-quality articles about:

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

Posted in RHEL7

Tuned dynamic configuration.

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.

Posted in RHEL7

RHCSA/RHCE move to RHEL 7.1.

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

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!

Posted in RHEL7

New Red Hat Presentations.

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!

Posted in RHEL7

RHCSA/RHCE Jang/Orsaria’s book review.

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!).

Posted in RHEL7

Postfix testing made easy.

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, 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: 86400 MX 10

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.

Posted in RHEL7

RHEL 6.8 just released.

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.

Posted in RHEL6

RHEL 7.2 CPUQuota resource control option.

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:

Description=Test Speed

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


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

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
# systemctl show testSpeed2 | grep CPUQuota

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.

Posted in RHEL7

RHCSA7: Task of the day

Allowed time: 5 minutes.
Set up time services pointing to default time servers.

RHCE7: Task of the day

Allowed time: 10 minutes.
Configure a httpd server that executes a Perl script in the /var/www/cgi-bin directory displaying "Hello!".

Poll for favorite RHEL 7 book

What is your favorite RHEL 7 book to prepare RHCSA & RHCE exams?

View Results

Loading ... Loading ...

Poll for most difficult RHCSA 7 topic

What do you think is the most difficult RHCSA 7 topic?

View Results

Loading ... Loading ...

Poll for most difficult RHCE 7 topic

What do you think is the most difficult RHCE 7 topic?

View Results

Loading ... Loading ...