Firewalld documentation website.

Since RHEL 7.0, Firewalld has been subject to controversies.

Newcomers find it easy to work with because it masks complexity: ports used by protocols are stored in configuration files, network masquerading is started through the simple –add-masquerade option, permanent and temporary configurations are clearly differentiated with the –permanent argument, etc. No need to remember the various iptables network chains or to be an expert in network packets to enable or disable a given protocol anymore.

However, some seasoned administrators don’t like it because it breaks iptables habits, add new concepts like zones, direct rules, rich rules and make some configurations almost impossible like ipset (to match entire sets of addresses at once) or MAC filtering, at least in the current RHEL 7.x versions.

In one word, Firewalld is generally easier to use than iptables but not always!

As Firewalld is part of the RHCSA & RHCE curriculums, even though iptables can still be used, it’s worth spending some of your time to learn it.

Thomas Woerner, Firewalld‘s author, has created a website to provide some documentation, explain the main concepts and offer some perspective about the future versions of his software: www.firewalld.org.

This is definitely a place to visit.

Posted in RHEL7

Systemd service debugging tips.

Troubleshooting a systemd service can be tricky.

Because the Restart=always directive is sometimes set in the unit file, you don’t know if a service is running fine or if it is stopping and restarting all the time.

The systemctl status command doesn’t help you much:

# systemctl status myservice
● myservice.service
Loaded: loaded (/etc/systemd/system/myservice.service; enabled; vendor preset: disabled)
Active: active (running) since Fri 2016-09-09 20:20:30 CEST; 44s ago
Main PID: 21366 (node)
CGroup: /system.slice/myservice.service
├─21366 /opt/nodejs/current/bin/node /opt/myapp/index.js -config=myconf.js
└─21376 /opt/nodejs/node-v4.5.0-linux-x64/bin/node index.js -config=myconf.js

Sep 09 20:20:30 myvm systemd[1]: Started myservice.service.
Sep 09 20:20:30 myvm systemd[1]: Starting myservice.service...
Sep 09 20:20:31 myvm nodejs[21366]: index.js: configurationFilename=myconf.js

First, you can add the -l/–full and -n 20/–lines 20 options to the systemctl status command. They respectively stop truncating the journal output and display 20 lines instead of 10 by default.

But if the service is regularly stopping and starting, these options won’t help you.

Hopefully, you can use the -u option and specify the service name in the journalctl command:

# journalctl -u myservice
Sep 09 16:52:47 myvm systemd[1]: Started myservice.service.
Sep 09 16:52:47 myvm systemd[1]: Starting myservice.service...
Sep 09 16:52:47 myvm nodejs[4076]: index.js: configurationFilename=myconf.js
Sep 09 16:53:47 myvm nodejs[4076]: can't access database
Sep 09 16:53:47 myvm nodejs[4076]: exited
Sep 09 16:53:48 myvm systemd[1]: myservice.service holdoff time over, scheduling restart.
Sep 09 16:53:48 myvm systemd[1]: Started myservice.service.
Sep 09 16:53:48 myvm systemd[1]: Starting myservice.service...
Sep 09 16:53:48 myvm nodejs[4261]: index.js: configurationFilename=myconf.js
Sep 09 16:54:48 myvm nodejs[4261]: can't access database
Sep 09 16:54:48 myvm nodejs[4261]: exited
Sep 09 16:54:48 myvm systemd[1]: myservice.service holdoff time over, scheduling restart.

Due to an error (“can’t access database”), it is now clear that the service is stopping and starting.
If it were not the case, adding Environment=SYSTEMD_LOG_LEVEL=debug in the service stanza of the unit file could provide some useful messages.

Posted in RHEL7

Third website anniversary.

As Redhat just announced the RHEL 7.3 Beta release (release notes are available here), this week marks the third anniversary of the website creation.

Tutorials are regularly updated even though writing of new ones has seriously slowed down due to lack of time.

I hope you still enjoy the website.

Posted in RHEL7

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 http://www.rsyslog.com/e/2307 ]
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 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!

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

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: 8 minutes.
Set up an iScsi target based on a block backstore of 100MB called lv_iscsi with basic authentication, ext4 filesystem and standard firewall configuration.

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