Configuring firewalld on Linux systems – zone creation

Firewalld is the default firewall module on newer Linux distributions that replaced its ancestor iptables.

One of its biggest advantage is firewall-cmd tool that makes easy to configure your own policies/zones through command line.

When installed, firewalld should be enabled and started.

systemctl enable firewalld; systemctl start firewalld

The default zone that is configured after installation is public on which the default network interface is added.

You can get a list of services allowed with the command:

firewall-cmd --zone=public --list-all

For the sake of the article we will create a new zone and allow some services on it.

Create a new zone with:

firewall-cmd --permanent --new-zone=custom

Make custom zone your default:

firewall-cmd --set-default-zone=custom

Reload firewalld module so that changes take place. Everytime you need to change a firewall setting a reload must take place.

systemctl reload firewalld

Add a custom ssh or application port on your created zone

firewall-cmd --permanent --add-port=11233/tcp --zone=custom

Add a build in service with a known port:

firewall-cmd --permanent --add-service=https --zone=custom

Add an IP address that could access your zone:

firewall-cmd --permanent --zone=custom --add-source=192.168.1.254

Mastering NTP configuration on Linux systems

The Network Time Protocol (NTP) is a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks and it is very important for various components and applications.

Many problems occur when time is not synchronized between systems even for time difference of milliseconds.

The latest case that I faced with a customer is composed of some power Linux systems that host SAP applications. Due to only some seconds time difference some flows could not be completed and messages could not be sent successfully between servers. This situation caused problems on client’s production and business departments and had to be resolved.

Although NTP was configured on the systems, the basic configuration was not enough to address correct time differences between systems and we had to alter the configuration.

Two of the most common used NTP daemons that one can use for Linux systems are ntpd and chronyd. In my case I had to alter configuration for ntpd, but same apply for chrony and the only change is where the configuration file is stored.

In order to modify ntpd settings one should edit /etc/ntp.conf file and for chronyd the conf file is located on /etc/chrony.conf

You can browse ntpd and chronyd manual pages with below commands:

man chrony.conf 
man ntpd.conf

Understanding NTPD and options:

The basic configuration of ntpd is the server keyword on the configuration file. However this could not be enough and you may encounter a big offset if your NTP provider is physically located on a long distance. (this was our case actually).

server IP on ntpd.conf

The premises on which NTP provider was located had a distance of some km and the connection was established through a dedicated network line. This however was not enough to keep time accurate.

As you can see below, the offset of the ntp with the one random system on client infrastructure was approximately 1,8 seconds (output is milliseconds) .

ntpq -pn
ntpd command will show you among others delay and offset statistics

The wikipedia article that is attached below, describes how NTP protocol works. In general a typical NTP client regularly polls one or more NTP servers. The client must compute its time offset and round-trip delay. Time offset θ, the difference in absolute time between the two clocks, is defined by below equation:

The important thing to understand is that NTP polling does not directly synchronize the local system  clock to the server clock; rather, a complex algorithm calculates an  adjustment value for each tick of the local system clock.

As a result, shorter  polling intervals cause NTP to make large but less accurate calculations that never stabilize, causing the local system clock to wander.

Longer  polling intervals allow NTP to calculate smaller tick adjustments that  stabilizes to a more accurate value, reducing wander in the local system  clock.

In many systems, administrators setup NTP only with the iburst option. This option only works for initial synchronization and will not be helpful on the normal system operation.

On the other hand, the burst option would be better, as on every synchronization attempt you will get more accurate calculations.

These options specify the minimum and maximum poll intervals for NTP
messages, in seconds as a power of two.

With burst option, chronyd/ntpd will shorten the interval between up to four requests to 2 seconds or less when it cannot get a good measurement from the server. The number of requests in the burst is limited by the current polling interval to keep the average interval at or above the minimum interval, i.e. the current interval needs to be at least two times longer than the minimum interval in order to allow a burst with two requests.

Adjust minpoll and maxpoll values:

These options specify the minimum and maximum poll intervals for NTP
messages, in seconds as a power of two.

The maximum poll interval defaults to 10 (1024 s), but can be increased by the maxpoll option to an upper limit of 17 (36 h).

The minimum poll interval defaults to 6 (64 s), but can be decreased by the minpoll option to a lower limit of 3 (8 s).

As described it would be better to increase maxpoll and minpoll so that you decrease traffic and improve accuracy.

In my case I altered the configuration to the below one and it seems that time differences between systems got better.

server IP burst minpoll 7 maxpoll 11

Check leap status:

ntpq -c rv
Leap_none = successful synchronization. Also offset is 76ms

Sources:

https://access.redhat.com/solutions/39194

https://en.wikipedia.org/wiki/Network_Time_Protocol

Rescan storage disk capacity physical RHEL – multipath storage device

Sometimes infrastructure servers are physical and directly connected to storage and not virtual ones. In virtualization cases, one has to assign a new virtual disk on the virtual server and proceed with the expand. In case of a physical server one should do the following in order to assign more space on a partition or a lvm.

Find storage adapters and rescan them:

ls /sys/class/scsi_host/
echo "- - -" > /sys/class/scsi_host/hostX/scan

where X is 0 to 10 in my system (some online and some offline)

After re scanning storage adapters a new multipath device will be visible and ready to be used.

multipath -ll
4 paths are available for this storage device ( disk 50G)

Initialize your disk and use it appropriately.

pvcreate /dev/mapper/mpathm

Configure Postfix to Send Mail Using an External SMTP Server

Sometimes due to network configuration you cannot use your SMTP server and you want to send emails through a proxy/relay. Below you can find how to configure a linux machine so that to act as an SMTP relay and forward emails to one SMTP server.

First if not installed you should install postfix package for your linux server depending on the distribution. For example on a RedHat server you should do:

sudo yum install postfix

Then you should edit the below postfix configuration lines. Postfix configuration is handled by /etc/postfix/main.cf

  • Change inet_interfaces from localhsot to all
inet_interfaces = all

Configure the source from which the emails will be sent. For example you can use a specific host or a subnet of hosts. In my case I chose a subnet so the second line should be uncommented.

#mynetworks_style = class
mynetworks_style = subnet
#mynetworks_style = host
  • Configure your subnet source Address and mask.
You can also specify the absolute pathname of a pattern file instead
of listing the patterns here. Specify type:table for table-based lookups
(the value on the table right-hand side is not used).

mynetworks = 192.168.0.0/16, 127.0.0.0/8
#mynetworks = $config_directory/mynetworks
#mynetworks = hash:/etc/postfix/network_table
  • Add your SMTP server address in the latest line
#relayhost = $mydomain
#relayhost = [gateway.my.domain]
#relayhost = [mailserver.isp.tld]
#relayhost = uucphost
relayhost = [IP_Address]

Finally test your configuration by a powershell command to verify the functionality.

Send-MailMessage -From "sender@mail.com" -To "recipient@mail.com" -Subject "test email" -Body "test subject" -SMTPServer IP_Address