Although Ansible provides support for managing firewall rules via module, I still find initial setup is best done with a tested batch of firewall rules instead of adding them one-by-one. Since I’m migrating CentOS 7 servers to CentOS 8 now, I decided to convert iptables into nftables.
Will probably post a Unix Tutorial Project about this, but today I’m just capturing notes.
What is nftables?
nftables is the next (current) generation of NetFilter based firewall solutions, replacing iptables and providing backward compatible tools with iptables syntax.
If all you used before is iptables, you can continue using familiar commands – but in CentOS 8 this means that on the firewall level there’s no longer iptables running, all the functionality is provided by NFT.
IMPORTANT: make sure you put this into some nft-rules.txt file outside of the /etc/sysconfig location – if things go wrong, you’ll just reboot server via hosting console and regain access.
Try/Check NFT Ruleset
Now comes the moment to disable iptables and try NFT tables in their place.
I did the following: flushed IPtables (removed any rules) and then applied NFT rules.
Flush iptables
# iptables -F
Apply NFT rules from nft-rules.txt file
# nft -f nft-rules.txt
We can now have a look at the list of active NFT rules:
# nft list ruleset
Configure nftables Rules to Apply upon Reboot
Assuming everything works as expected, we can now move the nfs-rules.txt file into default location that will be used by NFT upon reboot:
# mv nft-rules.txt /etc/sysconfig/nftables.conf
Make sure it belongs to root and has correct permissions (it’s not a script so needs no execution bits):
root@s1:~ # ls -lad /etc/sysconfig/nftables.conf -rw-------. 1 root root 5227 Mar 12 01:48 /etc/sysconfig/nftables.conf
I blogged about Generic Colouriser (grc) last week, cause I’m using it now to monitor syslog messages in my centralised RSyslog setup. I also mentioned that grc suppors many standard commands in addition to parsing common types of log files.
Colorized ls Output
Many Linux distros and even macOS support colorized file listing of the ls command, etc. Here’s how it usually looks:
Colorized ls Output with grc
Compare above example to how grc colorizes the same list of files:
Obviously, focus is on file permissions and ownership info.
I really like this, must be of great use for those of us just getting familiar with file/directory permissions in Unix/Linux.
I noticed that this server hasn’t been terribly available since upgrade to Ubuntu 19.04: more than once I went looking for the server and it was offline.
Now that I’m finally progressing with centralized RSyslog setup at home, I noticed that the UniFi controller server was reporting the following in logs recently:
So, it appears the power management has improved enough to start bringing this server to sleep every hour or so.
Since this is a recent enough version of Ubuntu, I figured there should be a way to disable power management using systemctl. Turns out, there is.
Confirm Sleep Status with systemd
IMPORTANT: I didn’t run this command on server, so this is example from another system: I’m running it on my XPS laptop with Ubuntu, just to show you expected output.
root@server:/ # sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
Created symlink /etc/systemd/system/sleep.target → /dev/null.
Created symlink /etc/systemd/system/suspend.target → /dev/null.
Created symlink /etc/systemd/system/hibernate.target → /dev/null.
Created symlink /etc/systemd/system/hybrid-sleep.target → /dev/null.
root@server:/etc/pm/sleep.d#
This is obviously a very simple way of disabling power management, but I like it because it’s standard and logical enough – there’s no need to edit config files or create cronjobs manually controlling sleep functionality.
The service is dead, no power management is happening and most importantly, my server has been up for 12 hours now.
greys@server:~$ systemctl status sleep.target
● sleep.target
Loaded: masked (Reason: Unit sleep.target is masked.)
Active: inactive (dead)
(re) Enabling Sleep in Ubuntu with systemctl
When the time comes and I would like to re-enable power management and sleep/hibernation, this will be the command I’ll run:
Pretty cool! Didn’t realise this, but Sublime Text 3 is available for Linux as well! Today I took a few minutes to download/install it and to even make it use some of the GUI themes for better coding experience.
All of these steps are taken from the Sublime Text 3 website.
Step 1: Activate Sublime Text 3 repo
First, we install the key to trust Sublime Text 3 repo:
greys@xps:~ $ wget -qO - https://download.sublimetext.com/sublimehq-pub.gpg | sudo apt-key add -
[sudo] password for greys:
OK
Now we ensure apt-get will support https protocol for working with repos:
greys@xps~ $ echo "deb https://download.sublimetext.com/ apt/stable/" | sudo tee /etc/apt/sources.list.d/sublime-text.list
Step 2: Install Sublime Text 3
We refresh apt package info:
$ sudo apt-get update
and install the packages:
greys@xps:~/proj/unixtutorial/examples $ sudo apt-get install sublime-text
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages were automatically installed and are no longer required:
dkms libgsoap-2.8.75 libvncserver1
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed
sublime-text
0 to upgrade, 1 to newly install, 0 to remove and 73 not to upgrade.
Need to get 9,835 kB of archives.
After this operation, 34.8 MB of additional disk space will be used.
Get:1 https://download.sublimetext.com apt/stable/ sublime-text 3211 [9,835 kB]
Fetched 9,835 kB in 8s (1,189 kB/s)
Selecting previously unselected package sublime-text.
(Reading database … 271734 files and directories currently installed.)
Preparing to unpack …/sublime-text_3211_amd64.deb …
Unpacking sublime-text (3211) …
Setting up sublime-text (3211) …
Processing triggers for desktop-file-utils (0.24-1ubuntu1) …
Processing triggers for mime-support (3.63ubuntu1) …
Processing triggers for hicolor-icon-theme (0.17-2) …
Processing triggers for gnome-menus (3.32.0-1ubuntu1) …
That’s it! Sublime Text 3 is now installed and can be started using the subl command:
My primary environment is macOS, but it’s comforting to know that I can fall back on Dell XPS laptop with Ubuntu to edit some Ansible playbooks in a similar way.
I started updating my Centralised RSyslog server on Raspberry Pi the other day, and one of the things I’ve been meaning to research was syntax highlighting for RSyslog logs. After a brief search online, I found grc: a great tool for seeing output of many common Unix commands and log files in a completely new, colorful and useful way.
Yesterday I have shown how to manage ext2/ext3/ext4 filesystem labels using e2label command. Continuing this topic, let’s update /etc/fstab file on my Ubuntu VM.
WARNING: don’t do this on a real server! try on a non-important virtual machine first, just to learn how to use commands, update fstab and so on. I’m using root filesystem (/) just because that’s the only filesystem I have on my Ubuntu VM.
Here’s how my /etc/fstab looks right now:
root@ubuntu:~ # cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# / was on /dev/sda1 during installation
UUID=ef0ca1f8-28cf-4baf-ada6-f2271aaece17 / ext4 errors=remount-ro 0 1
Check filesystem label for / filesystem
If we run df -h command, we can see what device the root (/) filesystem is using:
RHEL 8 has more software repositories available via various subscriptions than ever. Each subscription maps your operating system to a number of related repos, providing utmost granularity to installing and updating software.
I had to learn how to list repos because I wanted to install Ansible packages, turning one of my servers into an Ansible deployment server. Although Ansible is an open-source project, it’s not a core element of Red Hat Enterprise Linux, and that means it’s not available via core RHEL 8 repositories.
Instead, you need to find and enable Ansible repo in RHEL 8 (I’ll show how it’s done in the next few days).
How To List Software Repositories in RHEL 8
Simply run subscription-manager command with repos parameter, you’ll get quite a number of repositories reported back (I’m only showing you the first few):
root@rhel8:~ # subscription-manager repos
+----------------------------------------------------------+
Available Repositories in /etc/yum.repos.d/redhat.repo
+----------------------------------------------------------+
Repo ID: rhel-atomic-7-cdk-2.4-rpms
Repo Name: Red Hat Container Development Kit 2.4 /(RPMs)
Repo URL: https://cdn.redhat.com/content/dist/rhel/atomic/7/7Server/$basearch/cdk/2.4/os
Enabled: 0
Repo ID: satellite-tools-6.6-for-rhel-8-x86_64-eus-rpms
Repo Name: Red Hat Satellite Tools 6.6 for RHEL 8 x86_64 - Extended Update Support (RPMs)
Repo URL: https://cdn.redhat.com/content/eus/rhel8/$releasever/x86_64/sat-tools/6.6/os
Enabled: 0
Repo ID: codeready-builder-for-rhel-8-x86_64-rpms
Repo Name: Red Hat CodeReady Linux Builder for RHEL 8 x86_64 (RPMs)
Repo URL: https://cdn.redhat.com/content/dist/rhel8/$releasever/x86_64/codeready-builder/os
Enabled: 0
Repo ID: satellite-tools-6.7-for-rhel-8-x86_64-rpms
Repo Name: Red Hat Satellite Tools 6.7 for RHEL 8 x86_64 (RPMs)
Repo URL: https://cdn.redhat.com/content/dist/layered/rhel8/x86_64/sat-tools/6.7/os
When I say “quite a number“, I mean a lot of subscriptions are available:
I’m catching up on my systemd knowledge, this is almost a note to myself – a summary of the systemd unit types (yes, it’s a lot more than just startup scripts!).
How To Tell a systemd Unit Type
The quickest way to determine a systemd unit type is to just look at the last part of the unit file. For instance, if I list systemd units in /lib/systemd/system directory, I’ll find quite a mix. Here’s a fragment:
-rw-r--r-- 1 root 1196 Jan 29 18:07 systemd-time-wait-sync.service -rw-r--r-- 1 root 659 Jan 29 18:07 systemd-tmpfiles-clean.service -rw-r--r-- 1 root 490 Feb 14 2019 systemd-tmpfiles-clean.timer -rw-r--r-- 1 root 732 Jan 29 18:07 systemd-tmpfiles-setup-dev.service -rw-r--r-- 1 root 772 Jan 29 18:07 systemd-tmpfiles-setup.service -rw-r--r-- 1 root 635 Feb 14 2019 systemd-udevd-control.socket -rw-r--r-- 1 root 610 Feb 14 2019 systemd-udevd-kernel.socket
I have highlighted the last part of each filename, and it shows the type of a particular unit: service, timer or socket (there’s more types, see below).
Types of systemd Units
Here are the systemd unit types I’ve come across so far. They must be the most common ones:
service: thats the one you’ve probably heard about, it’s a unit type for configuring and managing a software service (startup/shutdown) just like init scripts used to do – but in a far more flexible way
device – anything and everything for managing device files – stuff like operating files in /dev filesystem, etc
mount – Systemd style of managing filesystem mounts – for now these are mostly internal OS use filesystems of special types. The more traditional filesystems like / or /var are still managed in /etc/fstab
timer – scheduling system for running low-level tasks like OS self-healing and maintenance – this is where mdcheck (software RAID arrays) runs and how apt/yum repos are updated.
target – similar to milestones in Solaris 10, this is a boot management mechanism where you create these targets with meaningful names which become logical points of alignment for system initialisation and startup. There are targets for printing, rebooting, system update or multi-user mode – so other Systemd units can be depedencies and dedepdants for such targets.