Definition

Syslogs contain subsets of information on faults, events, audit & session data, all related the monitored objects. Not all logs depict errors. Syslog can include audit and event logs.

Syslog Facilities

Any program or process capable of generating syslogs.

Syslog Severities

aka syslog severity levels or syslog priorities. The describe different levels of importance. Example of syslog severities: emergency, alert, critical, informational, warnings.

How Linux implements logging

rsyslogd

Verify the version of rsyslogd deployed on a RHEL machine:

Finding the kernel packages

The Linux kernel is not a monolithic file but rather a set of RPM packages.

Find out the installed kernel packages:

user1@localhost:~$ rpm -qa *kernel*
kernel-modules-extra-matched-6.12.0-124.8.1.el10_1.x86_64
kernel-tools-libs-6.12.0-124.8.1.el10_1.x86_64
kernel-modules-core-6.12.0-124.8.1.el10_1.x86_64
kernel-core-6.12.0-124.8.1.el10_1.x86_64
kernel-modules-6.12.0-124.8.1.el10_1.x86_64
kernel-modules-extra-6.12.0-124.8.1.el10_1.x86_64
kernel-tools-6.12.0-124.8.1.el10_1.x86_64
kernel-6.12.0-124.8.1.el10_1.x86_64
user1@localhost:~$ 

Find out the kernel version and release:

user1@localhost:~$ uname --help
Usage: uname [OPTION]...
Print certain system information.  With no OPTION, same as -s.

  -a, --all                print all information, in the following order,
                             except omit -p and -i if unknown:
  -s, --kernel-name        print the kernel name
  -n, --nodename           print the network node hostname
  -r, --kernel-release     print the kernel release
  -v, --kernel-version     print the kernel version
  -m, --machine            print the machine hardware name
  -p, --processor          print the processor type (non-portable)
  -i, --hardware-platform  print the hardware platform (non-portable)
  -o, --operating-system   print the operating system
      --help        display this help and exit
      --version     output version information and exit

GNU coreutils online help: <https://www.gnu.org/software/coreutils/>
Full documentation <https://www.gnu.org/software/coreutils/uname>
or available locally via: info '(coreutils) uname invocation'
user1@localhost:~$ 
user1@localhost:~$ uname -v
#1 SMP PREEMPT_DYNAMIC Fri Oct 17 13:03:58 EDT 2025
user1@localhost:~$ uname -r
6.12.0-124.8.1.el10_1.x86_64
user1@localhost:~$ 

Kernel-related files

in the /boot directory

With the exception of the efi and grub2 directories, which deal with the bootloader for UEFI and BIOS systems respectively, the rest of the files and subdirectories under the /boot/ directory are related to the kernel.

Grub2 is a popular bootloader for BIOS and UEFI systems. It typically displays boot entries in a black background during system start. Each of these boot entries seem to be a reference to a set of configuration instructions that are defined in files. Such files are located under /boot/loader/entries/ according the the man page of grubby.

user1@rhel10-vm2:~$ ls /boot/loader/entries/
ls: cannot open directory '/boot/loader/entries/': Permission denied
user1@rhel10-vm2:~$ 
user1@rhel10-vm2:~$ sudo ls /boot/loader/entries/
995c0067e7c140f28c8539b917f55418-0-rescue.conf
995c0067e7c140f28c8539b917f55418-6.12.0-55.43.1.el10_0.x86_64.conf
user1@rhel10-vm2:~$ 

When my lab VM is booting, grub2 shows only two boot entries. And I found only two files under /boot/loader/entries/.

Installing and Removing Flatpak

Read this technote

Flatpak and Remotes

A Flatpak remote is a local representation of an online Flatpak repository. It can be a statically defined ‘.flatpakrepo’ file, manually placed under ‘/etc/flatpak/repos.d/’, or a dynamically defined section of the active configuration file, which is the ‘/var/lib/flatpak/repo/config’ file.

The addition of a description of a Flatpak remote in the active configuration file is performed by the Flatpak tool, when the command flatpak remote-add is executed.

Topology

graph LR
net1(LAN1_172.17.99.0/24) 
net1 <--> R1
R1 <--> |WAN1_10.10.10.8/30|R4

Configuration and Interpretations

Desired outcome: I want to configure a generated route on R1 for the prefix 172.17.99.0. Currently, the prefix 172.17.99.0/24 is directly attached to ge-0/0/6. I want to make R1 advertise the generated route 172.17.96.0/19 toward its BGP neighbor R4 only when R1 receives the BGP route 10.22.1.0/26 from R4 (which is configured as an aggregate route on R4) and successfully imports it from BGP into inet.0. On R1, at the moment there is only one contributing route for the generated route, which is 17.17.99.0/24.

Topology

graph LR
net1(LAN1_172.17.99.0/24) 
net1 <--> R1
R1 <--> |WAN1_10.10.10.8/30|R4

Configuration and Analysis

The default next hop of an aggregate route is reject:

root@R4> show configuration routing-options rib inet.0 aggregate 
defaults {
    preference 189;
}
route 10.22.1.0/26;

root@R4> 
root@R4> show route protocol aggregate 

inet.0: 15 destinations, 17 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.22.1.0/26       *[Aggregate/189] 00:00:58
                       Reject

inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

root@R4> 
root@R4> show route 10.22.1.0/26 exact detail 

inet.0: 15 destinations, 17 routes (15 active, 0 holddown, 0 hidden)
10.22.1.0/26 (1 entry, 1 announced)
        *Aggregate Preference: 189
                Next hop type: Reject, Next hop index: 0
                Address: 0x77c5434
                Next-hop reference count: 2
                Kernel Table Id: 0
                State: <Active Int Ext>
                Local AS:    22 
                Age: 7:22 
                Validation State: unverified 
                Task: Aggregate
                Announcement bits (2): 0-KRT 5-Resolve tree 3 
                AS path: I  (LocalAgg)
                Flags:                  Depth: 0        Active
                AS path list:
                AS path: I Refcount: 2
                Contributing Routes (2):
                        10.22.1.0/27 proto Direct
                        10.22.1.32/27 proto Static
                Thread: junos-main 

root@R4> 

#LessonLearned The contributing routes may be of different routing protocols or pseudoprotocols.

Linux units

Units are configuration files that describe the resources that are managed by systemd. They are stored in four file system paths. If I do a manual search I can approximately tell where they are:

Wassim@linux:~$ find / -mindepth 1 -name systemd 2>/dev/null
/home/Wassim/Documents/ddupdate/systemd
/home/Wassim/.config/systemd
/run/systemd
/run/udev/tags/systemd
/run/user/1000/systemd
/etc/xdg/systemd
/etc/systemd
/var/lib/systemd
/var/lib/flatpak/runtime/org.gnome.Platform/x86_64/49/e51263e53d04900556e2f97ac2b27201f632f604d68d67f50323f9a99389fdb0/files/lib/systemd
/var/lib/flatpak/runtime/org.gnome.Platform/x86_64/49/e51263e53d04900556e2f97ac2b27201f632f604d68d67f50323f9a99389fdb0/files/share/licenses/gnome/systemd
/var/lib/flatpak/runtime/org.gnome.Platform/x86_64/50/a8da766dd0273a67539d2b98358ed6809d8e729280baf63428108837135229d3/files/lib/systemd

<---- output omitted ---->

/var/lib/snapd/snap/gnome-3-38-2004/143/usr/lib/systemd
/usr/lib/systemd
/usr/lib/systemd/systemd
/usr/lib64/systemd
/usr/lib64/python3.12/site-packages/systemd
/usr/share/licenses/systemd
/usr/share/doc/systemd
/usr/share/systemd
/usr/share/cockpit/systemd
Wassim@linux:~$ 

/run/systemd seem to store runtime unit files, because /run/ typically contains runtime data, so it can not be a permanent location of systemd unit files. There is also /etc/systemd and /usr/lib/systemd/system/. The latter appears to store system units:

listing repos with DNF

List the enabled repos: either with dnf repolist or dnf repolist --enabled. I can add the verbose option -v.

user1@localhost:~$ dnf repolist -v
Loaded plugins: builddep, changelog, config-manager, copr, debuginfo-install, download, generate_completion_cache, groups-manager, kpatch, needs-restarting, notify-packagekit, playground, product-id, repoclosure, repodiff, repograph, repomanage, reposync, subscription-manager, system-upgrade, uploadprofile
Not root, Subscription Management repositories not updated
DNF version: 4.20.0
cachedir: /var/tmp/dnf-user1-w76vxc5s
OS software                                                   2.7 MB/s | 2.7 kB     00:00    
Application software                                          2.7 MB/s | 2.8 kB     00:00    
Repo-id            : AppStream
Repo-name          : Application software
Repo-revision      : 1761027148
Repo-updated       : Tue 21 Oct 2025 08:12:28 AM CEST
Repo-pkgs          : 4,514
Repo-available-pkgs: 4,514
Repo-size          : 6.5 G
Repo-baseurl       : file:///mnt/AppStream
Repo-expire        : 172,800 second(s) (last: Sat 04 Jul 2026 10:29:26 PM CEST)
Repo-filename      : /etc/yum.repos.d/local.repo

Repo-id            : baseOS
Repo-name          : OS software
Repo-revision      : 1761027164
Repo-updated       : Tue 21 Oct 2025 08:12:45 AM CEST
Repo-pkgs          : 946
Repo-available-pkgs: 946
Repo-size          : 1.3 G
Repo-baseurl       : file:///mnt/BaseOS
Repo-expire        : 172,800 second(s) (last: Sat 04 Jul 2026 10:29:26 PM CEST)
Repo-filename      : /etc/yum.repos.d/local.repo
Total packages: 5,460
user1@localhost:~$ 

user1@localhost:~$ dnf repolist --enabled -v
Loaded plugins: builddep, changelog, config-manager, copr, debuginfo-install, download, generate_completion_cache, groups-manager, kpatch, needs-restarting, notify-packagekit, playground, product-id, repoclosure, repodiff, repograph, repomanage, reposync, subscription-manager, system-upgrade, uploadprofile
Not root, Subscription Management repositories not updated
DNF version: 4.20.0
cachedir: /var/tmp/dnf-user1-w76vxc5s
Last metadata expiration check: 0:05:39 ago on Sat 11 Jul 2026 05:38:51 PM CEST.
Repo-id            : AppStream
Repo-name          : Application software
Repo-revision      : 1761027148
Repo-updated       : Tue 21 Oct 2025 08:12:28 AM CEST
Repo-pkgs          : 4,514
Repo-available-pkgs: 4,514
Repo-size          : 6.5 G
Repo-baseurl       : file:///mnt/AppStream
Repo-expire        : 172,800 second(s) (last: Sat 11 Jul 2026 05:38:51 PM CEST)
Repo-filename      : /etc/yum.repos.d/local.repo

Repo-id            : baseOS
Repo-name          : OS software
Repo-revision      : 1761027164
Repo-updated       : Tue 21 Oct 2025 08:12:45 AM CEST
Repo-pkgs          : 946
Repo-available-pkgs: 946
Repo-size          : 1.3 G
Repo-baseurl       : file:///mnt/BaseOS
Repo-expire        : 172,800 second(s) (last: Sat 11 Jul 2026 05:38:51 PM CEST)
Repo-filename      : /etc/yum.repos.d/local.repo
Total packages: 5,460
user1@localhost:~$ 

#LessonLearned There is no difference in output between dnf repolist -v and dnf repolist --enabled -v.

users

The useradd command with the -b option creates a base directory for the user account. The home directory is always the concatenation of the base directory and the user account name, according to Linux man pages.

user01@rhel10-vm4:~$ sudo useradd user02 -b /myBaseDir
Creating mailbox file: File exists
user01@rhel10-vm4:~$
user01@rhel10-vm4:~$ sudo su - user02
Last login: Fri Oct  2 01:27:39 EDT 2026 on pts/3
user02@rhel10-vm4:~$ pwd
/myBaseDir/user02
user02@rhel10-vm4:~$

I delete the user account, recreate it without the -b option and check its home directory again:

ddd