GRUB 2 (GRand Unified Bootloader version 2) is the standard bootloader for Oracle

Linux and many other Linux distributions,

including Red Hat Enterprise Linux. It manages the boot process, allowing you to
choose between multiple kernels, operating systems,
and configurations at startup.

GRUB 2 Configuration Files:

The main configuration file is located at /BOOT/GRUB2/GRUB.CFG on BIOS systems

or /boot/efi/EFI/redhat/grub.cfg on UEFI systems.
Unlike GRUB Legacy, YOU SHOULD NOT EDIT GRUB.CFG DIRECTLY. Instead, make changes in
the configuration files that GRUB 2 generates grub.cfg from.
Key configuration files and directories include:
/ETC/DEFAULT/GRUB: CONTAINS DEFAULT SETTINGS FOR GRUB, like the default timeout,
boot entry, and kernel parameters.
/etc/grub.d/: A directory with scripts used to create grub.cfg. Each script defines
specific boot entries or settings.
10_linux: Detects Linux installations and adds them to the GRUB menu.
20_linux_xen: Used for Xen-based virtual machines.
30_os-prober: Searches for other OS installations (e.g., Windows) and adds them to
the GRUB menu.
40_custom: Used for custom entries.

After making any changes to /ETC/DEFAULT/GRUB or any script in /etc/grub.d/, you

need to regenerate the main configuration file grub.cfg with:

SUDO GRUB2-MKCONFIG -O /BOOT/GRUB2/GRUB.CFG

GRUB 2 displays a boot menu during startup. You can use this menu to select the
kernel version or operating system to boot.

The default boot entry is configured in /etc/default/grub using:

GRUB_DEFAULT=0: Sets the default menu entry. 0 indicates the first entry.
GRUB_TIMEOUT=5: Sets how long the menu will wait (in seconds) before automatically
booting the default entry.

GRUB Command Line: If GRUB fails, you might be dropped into the GRUB command line.
From here, you can manually specify the kernel and
boot parameters to start the OS.
Rescue Mode: On Oracle Linux, boot into rescue mode from the installation media to
reinstall or repair GRUB if it becomes corrupted.

GRUB 2 automatically detects other operating systems like Windows or additional

Linux installations.

To re-scan for additional OS installations (if added after Oracle Linux), ensure
os-prober is installed, then run:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Kernel parameters can be modified temporarily during boot from the GRUB menu or
permanently by editing GRUB_CMDLINE_LINUX in /etc/default/grub.

Common parameters include quiet (for minimal boot messages) and rhgb (for Red Hat
graphical boot).

Example of /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=0
GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet"
GRUB_DISABLE_RECOVERY="true"

If GRUB 2 does not automatically detect the other OS, you can manually add an entry
by editing the /etc/grub.d/40_custom file.

sudo mdadm --manage /dev/md0 --fail /dev/sdb --remove /dev/sdb --add /dev/sdb

sudo mdadm --manage /dev/md0: This part specifies that the mdadm command will
manage the RAID array device /dev/md0.

--fail /dev/sdb: Marks /dev/sdb as "failed" within the RAID array. This tells the
RAID array to stop using /dev/sdb as an active disk.
RAID will begin using other disks to manage redundancy and data integrity if it's
configured to do so.

--remove /dev/sdb: Removes /dev/sdb from the RAID array. After marking the disk as
failed, this step fully detaches /dev/sdb from the array configuration,
making it eligible to be replaced or added back in.

--add /dev/sdb: Re-adds /dev/sdb back to the RAID array as a fresh, active disk.
Once re-added, RAID will begin syncing and rebuilding data onto
/dev/sdb as part of the array, as if it were a new or repaired disk.

This sequence is typically used when you want to force a resync of a disk within a
RAID array. This might be helpful if you suspect data corruption
or want to reinitialize the disk's data without physically replacing the disk.

Check the firewall status:

sudo firewall-cmd --state

List the active zones (shows which zones are in use):

sudo firewall-cmd --get-active-zones

List all active rules:

sudo firewall-cmd --list-all

Reload the firewall after changes:

sudo firewall-cmd --reload

Configure Firewall Zones

firewalld uses zones to manage traffic. Each zone represents a level of trust for
network connections. Some common zones include:

public: Default zone, used for untrusted networks.

dmz: Used for public services, such as web servers.
internal: Trusted network, such as an internal LAN.
trusted: For networks where all incoming traffic is allowed.

You can view the default zone by using:

sudo firewall-cmd --get-default-zone

Set Default Zone

To set the default zone, use the following command:

sudo firewall-cmd --set-default-zone=public

Add Services to a Zone

For example, if you want to allow HTTP (port 80) and HTTPS (port 443) in the public
zone:

sudo firewall-cmd --zone=public --add-service=http --permanent

sudo firewall-cmd --zone=public --add-service=https --permanent
After adding services, reload the firewall to apply the changes:

sudo firewall-cmd --reload

Remove a Service from a Zone
To remove a service from a zone, use:

sudo firewall-cmd --zone=public --remove-service=http --permanent

sudo firewall-cmd --zone=public --remove-service=https --permanent

chronyd replaces ntpd in Oracle Linux 8, offering improved accuracy, especially in

virtualized environments and for systems with intermittent connectivity

The main configuration file is /etc/chrony.conf.

nmcli connection add type vlan ifname vlan100 dev eth0 id 100
nmcli connection modify vlan100 ipv4.addresses 192.168.100.10/24
nmcli connection modify vlan100 ipv4.gateway 192.168.100.1
nmcli connection modify vlan100 ipv4.dns "8.8.8.8 8.8.4.4"
nmcli connection modify vlan100 ipv4.method manual
nmcli connection modify vlan100 vlan.priority 1
nmcli connection modify vlan100 connection.autoconnect yes
nmcli connection modify vlan100 802-3-ethernet.mtu 1500

Then activate it
nmcli connection up vlan100

ifname: The VLAN interface name.

dev: The parent interface for the VLAN (e.g., eth0).
id: VLAN ID.
ipv4.addresses: Static IP address.
ipv4.gateway: Gateway IP address.
ipv4.dns: DNS server(s).
ipv4.method: Address assignment method (manual for static, auto for DHCP).
vlan.priority: VLAN priority level (for QoS).
connection.autoconnect: Whether the VLAN autostarts on boot.
802-3-ethernet.mtu: MTU size for the VLAN interface.
802-3-ethernet.cloned-mac-address: Custom MAC address.

Autofs is a system that automatically mounts filesystems only when a user or

application tries to access them.
Autofs helps reduce the need for manual mounts, lowers system resource usage by
unmounting unused filesystems, and provides easier access to remote filesystems,
such as NFS.
Key Components:
Master Map File: Specifies where and how to mount filesystems.
Map Files: Define specific mount points and their options

Example Full Configuration

/etc/auto.master:

/mnt/nfs /etc/auto.nfs --timeout=300

/etc/auto.nfs:

data -fstype=nfs4,rw 192.168.1.100:/exported/data

logs -fstype=nfs4,rw 192.168.1.100:/exported/logs
backup -fstype=nfs4,ro 192.168.1.100:/exported/backup
This setup:

Manages the /mnt/nfs directory, automatically creating mount points for data, logs,
and backup.
The backup mount point is read-only (ro), while data and logs are read-write (rw).

cgroups are the core mechanism for resource management in the kernel, allowing
direct control of CPU, memory, and I/O usage for processes.
eg: echo "100M" > /sys/fs/cgroup/memory/mygroup/memory.limit_in_bytes
Slices in systemd are logical groupings of units built on top of cgroups, allowing
administrators to enforce resource policies across large sections of the system
without managing individual processes directly.
eg: [Slice]
MemoryMax=1G
CPUQuota=50%

In Linux 8, cgroups v2 is enabled by default, but some systems may still require
cgroups v1
In cgroups v2, resources are managed in a hierarchical structure where each cgroup
can have multiple sub-cgroups, allowing fine-grained resource control.

Controllers in cgroups v2

cgroups v2 provides several controllers to manage different resources:

cpu: Limits CPU usage.
memory: Controls memory limits, with support for hard and soft limits.
io: Manages disk I/O.
pids: Controls the maximum number of processes in a cgroup.
devices: Allows or denies access to device nodes.

The cgroup filesystem is mounted at /sys/fs/cgroup and contains files and

directories for each cgroup. These files expose settings for resource limits,
usage statistics, and other controls.
Resource configuration is done by writing values to specific files within these
directories (e.g., memory.max for memory limits).
Cgroup settings can be viewed and modified using standard Linux commands, such as
cat, echo, and ls.

In Linux 8, systemd is tightly integrated with cgroups, and each systemd unit
(service, scope, or slice) automatically creates its own cgroup.
Resource limits can be set for systemd units using unit files by adding directives
under the [Service] or [Slice] sections, such as CPUQuota, MemoryMax, and IOWeight.
Example of a unit file configuration:

[Service]
CPUQuota=50%
MemoryMax=1G

These settings can be dynamically modified using the systemctl command with set-
property:

sudo systemctl set-property myservice.service CPUQuota=50%

Viewing cgroup Statistics and Limits

You can check resource usage and limits within the cgroup filesystem. For
example:

cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/cpu.max

Example Use Case in Linux 8

To limit a process to 512MB of memory and 25% CPU usage in a cgroup using systemd:

Create a custom service unit file (e.g., /etc/systemd/system/myapp.service).

Add resource limits:

[Service]
ExecStart=/path/to/your/application
MemoryMax=512M
CPUQuota=25%

Start and enable the service:

sudo systemctl start myapp.service

sudo systemctl enable myapp.service

This configuration will create a systemd-managed cgroup with specified memory and
CPU limits, providing controlled resource allocation for myapp.

dmesg options:
Option Description
-C, --clear Clears the kernel ring buffer without displaying any messages.
-c Prints the kernel ring buffer contents and then clears it.
-T, --ctime Shows timestamps in a human-readable date and time format.
-H, --human Displays output in a human-readable format with interactive scrolling.
-k, --kernel Shows only kernel-related messages, hiding user-space messages.
-l, --level Filters messages by log level (e.g., err, warn, info).
-n, --console-level Sets log level for messages displayed on the console.
-r, --raw Shows raw format without additional formatting.
-f, --facility Filters messages by facility, such as kern, user, mail.
-s, --buffer-size Limits output to a specified number of bytes (e.g., -s 1000).
-x, --decode Decodes facility and priority for debugging purposes.
-w, --follow Continuously monitors new messages in real-time (like tail -f).

Cron Job Precedence

 User Crontabs (/var/spool/cron/): Highest precedence; runs based on the user's
own scheduled jobs.
/etc/cron.d/: System-wide jobs defined here run next.
/etc/crontab: System-wide cron jobs in this file are executed.
/etc/cron.hourly, .daily, .weekly, .monthly: Finally, any scripts in these
interval directories are executed according to their defined schedule.

Anacron Job Precedence

/etc/anacrontab: Specifies which scripts in the daily, weekly, or monthly

directories should run if missed.
Cron.daily, Cron.weekly, Cron.monthly: The anacron service will refer to these
directories based on the /etc/anacrontab configuration.
Only Root Can Modify Anacron Jobs: By default, only the root user or users
with elevated privileges (via sudo) can add, modify, or remove anacron jobs.

Precedence between cron and anacron

Anacron only runs daily, weekly, and monthly jobs, and it will run missed jobs
upon the next system startup.
Cron can run at any frequency (including minutely and hourly), so if both cron
and anacron are configured for the same task, cron might run the job multiple times
a day, while anacron would run it only once if missed.

Behavior of cron.allow and cron.deny

If both files exist (cron.allow and cron.deny):

Users in the cron.allow file are allowed to use cron.
Users in the cron.deny file are denied access, even if they are not listed
in the cron.allow file.
If a user is in neither file, cron access is typically allowed unless
configured differently elsewhere.

If only cron.allow exists:

Only users listed in cron.allow can schedule cron jobs.
All other users, even those not in cron.deny, are denied access.

If only cron.deny exists:

Users listed in cron.deny cannot schedule cron jobs.
All other users (not listed in cron.deny) are allowed to use cron.

If neither file exists:

The system will allow all users to use cron.

NTP (via Chrony) is the default method for time synchronization in Oracle Linux
8, and it is easy to configure for general-purpose time synchronization.
PTP is used for higher-precision synchronization and is implemented through the
linuxptp package, supporting nanosecond-level accuracy.
Both services can run simultaneously on a system, allowing for general time
synchronization (NTP) alongside highly accurate synchronization (PTP) as needed.

Protocol: NTP uses a client-server model where clients request time from NTP
servers. PTP uses a master-slave model where one clock (master) distributes time to
other clocks (slaves) in the network.

QN:17 - C
QN:26 - A,C
precedence for SSH client configuration is:

Command line (C)

User-specific configuration (~/.ssh/config, B)
System-wide configuration (/etc/ssh/ssh_config, A)

chage - change user password expiry information

. Password Lifetime

Definition: Password lifetime specifies the maximum duration (in days) that a
password can be used before it must be changed.
Purpose: It enforces regular password changes, enhancing security by limiting
how long a password can remain the same.
Configuration: This is controlled by setting the maximum password age in
/etc/login.defs or by using the chage command.
Example: If PASS_MAX_DAYS is set to 90, users must change their password every
90 days.

2. Password Expiry

Definition: Password expiry sets a specific date when a password will expire,
regardless of when it was last changed.
Purpose: It enforces a hard expiration date for passwords, which may be useful
in scenarios where access needs to end on a specific date (e.g., temporary
accounts).
Configuration: This can be set per user using the chage command with the -E
option to specify an expiration date.
Example: Running chage -E 2024-12-31 username sets the user’s password to
expire on December 31, 2

/etc/login.defs

# Password aging controls

PASS_MAX_DAYS 90
PASS_MIN_DAYS 1
PASS_WARN_AGE 7

# UID and GID ranges for regular users

UID_MIN 1000
UID_MAX 60000
GID_MIN 1000
GID_MAX 60000

# Password encryption method

ENCRYPT_METHOD SHA512

# Home directory and mail settings

CREATE_HOME yes
MAIL_DIR /var/mail
UMASK 077

Login controls -> LOGIN_TIMEOUT, LOGIN_RETRIES(number of allowed failed login

attempts before the system blocks), USERGROUPS_ENAB: Enables or disables the
creation of a private group for each new user
In the vsftpd configuration file (/etc/vsftpd/vsftpd.conf), the setting
userlist_enable controls whether a user list is used to allow or deny FTP
access for specified users.

Here's how it works:

userlist_enable=YES: This setting enables the use of the user list file,
typically located at /etc/vsftpd.user_list.
Whether users in this list are allowed or denied access depends on another
setting, userlist_deny.
userlist_deny=YES (default): If userlist_deny is set to YES, users listed in
vsftpd.user_list are denied FTP access.
userlist_deny=NO: If userlist_deny is set to NO, only users listed in
vsftpd.user_list are allowed FTP access.

To summarize:

If both userlist_enable=YES and userlist_deny=YES, any user in vsftpd.user_list

will be denied access.
If userlist_enable=YES and userlist_deny=NO, only users in vsftpd.user_list can
access FTP; all others are denied.

Main Configuration File: /etc/vsftpd/vsftpd.conf

This is the primary configuration file for VSFTPD.

Controls various aspects of the FTP server, including security, user access,
permissions, logging, and passive/active FTP modes.

Some commonly used settings include:

anonymous_enable: Enables or disables anonymous FTP access (YES or NO).
local_enable: Allows local (non-anonymous) users to log in.
write_enable: Enables write permissions for FTP users.
chroot_local_user: Restricts users to their home directories, enhancing
security.
pasv_min_port and pasv_max_port: Define the range of ports for passive FTP
connections.

/etc/vsftpd/user_list:

A list of usernames that can either be allowed or denied access to the FTP
server based on userlist_deny setting in vsftpd.conf.
If userlist_deny=YES, users in this list are denied access. If
userlist_deny=NO, only users in this list are allowed access.

/etc/vsftpd/ftpusers:

A file that specifies a list of users who are always denied FTP access,
regardless of other settings.
Typically, system users like root, bin, daemon, etc., are listed here to
prevent them from FTP login for security reasons.

/etc/pam.d/vsftpd

This file configures the Pluggable Authentication Modules (PAM) for VSFTPD.
Controls how authentication is handled for users trying to log in via FTP.
This file allows VSFTPD to integrate with the system’s authentication
mechanisms, including password checks and user restrictions.
Log Files: /var/log/vsftpd.log

sudo ip link add link <parent_interface> name <parent_interface>.<vlan_id> type

vlan id <vlan_id>

ip link add link eth0 name eth0.10 type vlan id 10

nmcli connection add type vlan ifname vlan100 dev eth0 id 100

Interaction between Podman, Buildah, and Skopeo

Podman & Buildah:

Podman and Buildah share a lot of common functionality, and both are part
of the containers ecosystem.
Podman is primarily used for running containers, while Buildah is focused
on building container images.
You can use Buildah to create a container image and then use Podman to run
that image.

Podman & Skopeo:

Skopeo can be used alongside Podman to inspect or copy container images
between registries.
You can use Skopeo to push/pull images between registries and use Podman to
run containers locally.

Buildah & Skopeo:

After building an image with Buildah, you can use Skopeo to copy that image
to a registry or inspect it without pulling it.

Podman doesn’t rely on a central daemon. Each container runs independently,

enhancing security and flexibility.

Skopeo allows inspecting images directly from registries without needing to pull
them, providing metadata and other image details.

podman inspect

Scope: Local Images and Containers

Purpose: Primarily used to inspect images and containers that are stored
locally or actively running on the host machine.

Command Syntax:

podman inspect <image_name_or_container_id>

Use Case: When you want to retrieve metadata or configuration details about a
container or image stored on your local system, such as environment variables,
ports, labels, mount points, and network settings.

Output Details:

Includes information specific to the local container or image, such as image

layers, container configuration, environment settings, and networking.
This output is JSON-formatted and provides exhaustive details relevant to
Podman-managed images and containers.

skopeo inspect
 Scope: Remote and Local Images

Purpose: Used to inspect images remotely on a registry (without pulling them)

or locally if needed. skopeo inspect can access images in various locations,
including container registries, local directories, and tar archives.

Command Syntax:

skopeo inspect docker://<registry>/<image_name>:<tag>

Use Case: When you want to view metadata about an image stored in a remote registry
(such as Docker Hub or a private registry) without downloading it.
This is useful for quickly checking image details (like layers and size) directly
from the source registry.

Output Details:

Provides image metadata such as size, digest, creation date, and supported
architectures.
It does not include extensive local container configuration details because
it’s intended for retrieving basic image information across multiple locations.

UPG: In shared directories or projects, administrators can assign users to specific

groups to allow controlled collaboration.
Since each user has a unique primary group, it’s easier to add them to additional
groups as needed without affecting their primary private group.

sudo usermod -aG project_team alice adds alice to the project_team group in
addition to her private group

umask: In the UPG model, the default umask value is typically set to 002 for user-
created files. This setting determines the default permissions for new files and
directories:
Files are created with 664 permissions (rw-rw-r--), making them readable and
writable by the user and their private group, but read-only for others.
Directories are created with 775 permissions (rwxrwxr-x), allowing full access for
the user and their group but read-only for others.
This model avoids excessive restriction while maintaining control, as only users
within the same group have write access to shared files.

Create a User with UPG: sudo useradd username

View User’s Private Group: id username (displays all groups the user belongs to)
Add User to an Additional Group: sudo usermod -aG groupname username
Modify Permissions in Shared Directories: To set group permissions on shared
directories, use chmod and chown as needed.

The KERNEL=="hdb", DRIVER=="ide-disk", SYMLINK+="sparedisk" rule is a udev rule,

not part of the kernel Makefile.
You should place it in a file inside /etc/udev/rules.d/ and reload the udev rules.
File extention should be .rule
Optionally, you can automate copying the udev rule file as part of the Makefile by
using install commands to copy the rules to the appropriate location.

Command Description
auditctl -l List current audit rules
auditctl -a always,exit -F arch=b64 -S execve Log every execve system call on a
64-bit system
auditctl -w /etc/passwd -p rwxa Monitor access (read, write, execute, and
attribute change) to /etc/passwd
auditctl -d Delete a specific rule
sudo ausearch -m execve Search audit logs for execve system calls

sudo dnf install audit

-a always,exit: This specifies that the rule should apply to all processes (whether
successful or not) for a specific system call or action.
-F arch=b64: This option is used to specify the architecture. For a 64-bit system,
arch=b64 should be used.
-S <syscall>: The system call (e.g., execve, open, read, write) to be audited.
-w <path>: Watch a specific file or directory.
-p <permissions>: Define the permissions to monitor on the file (e.g., r for read,
w for write, x for execute, a for attribute changes).

To monitor file open events for all files, you can use the following rule:

sudo auditctl -a always,exit -S open

To audit the execution of a particular command (e.g., /usr/bin/ls):

sudo auditctl -a always,exit -F path=/usr/bin/ls -S execve

By default, the rules set with auditctl are not persistent across reboots. To make
them persistent, you need to add them to the
/etc/audit/rules.d/ directory in a rules file.

To create persistent rules, you can either directly edit the file
/etc/audit/rules.d/audit.rules, or you can create a custom rules file:

Audit logs are typically stored in /var/log/audit/audit.log. You can view the logs
with ausearch, which is a utility to query and search through the audit logs.

systemd is the core system and service manager, handling the startup, management,
and shutdown of system services. It replaces the older init system and introduces a
unified way to manage services, processes, and other system components.
The Service Manager is a systemd component that manages these services, making it
easy to start, stop, restart, enable, and disable services.

sudo nmcli connection add type bond ifname bond0 mode active-backup
sudo nmcli connection add type bond-slave ifname eth0 master bond0
sudo nmcli connection add type bond-slave ifname eth1 master bond0
sudo nmcli connection modify bond0 ipv4.addresses 192.168.1.100/24
sudo nmcli connection modify bond0 ipv4.method manual
sudo nmcli connection up bond0

nmcli connection show bond0

cat /proc/net/bonding/bond0

Summary Table of Bonding Modes

Mode Name Load Balancing Fault
Tolerance Switch Requirements
0 Round Robin (balance-rr) Yes Yes
Yes, specific configuration may be needed
1 Active Backup (active-backup) No Yes
None, works with most switches
2 XOR (balance-xor) Yes Yes
Requires switch support for link aggregation
3 Broadcast (broadcast) No Yes
None, works with most switches
4 802.3ad (Dynamic Link Aggregation) Yes Yes
Requires switch support for LACP
5 Adaptive Transmit Load Balancing (balance-tlb) Yes,transmit only Yes
None
6 Adaptive Load Balancing (balance-alb) Yes Yes
None

sudo pvcreate /dev/sdX /dev/sdY

sudo vgcreate myvg /dev/sdX /dev/sdY
sudo lvcreate -n mylv -L 10G myvg or sudo lvcreate -n mylv -l 100%FREE myvg
sudo mkfs.ext4 /dev/myvg/mylv
sudo mkdir /mnt/mydata
sudo mount /dev/myvg/mylv /mnt/mydata

/etc/lvm/lvm.conf

atq -> running/pending jobs

This command will list all pending at jobs for the current user.
The output will show job IDs, the date and time they are scheduled to run, and the
queue.
at -c <job id> - contents of at job
atrm <job id> - remove job

In Oracle Enterprise Linux 8, systemd is the system and service manager responsible
for controlling services, processes, and system states.
Units: systemd organizes everything as units
(e.g., .service, .socket, .target, .timer, and .mount).
Service Units: Manage services or daemons (e.g., httpd.service for Apache).
Target Units: Represent system states or goals (e.g., multi-user.target,
graphical.target).

/etc/systemd/system/: Directory for custom or overridden unit files.

/usr/lib/systemd/system/: System unit files (default location).
/etc/systemd/system.conf: Global configuration file for systemd settings.
/etc/systemd/journald.conf: Configuration for the systemd journal logging.

firewalld - Dynamic Firewall Manager

SYNOPSIS
firewalld [OPTIONS...]

DESCRIPTION
firewalld provides a dynamically managed firewall with support for
network/firewall zones to define the trust level of network connections or
interfaces. It
has support for IPv4, IPv6 firewall settings and for ethernet bridges and
has a separation of runtime and permanent configuration options. It also supports
an interface for services or applications to add firewall rules directly.

firewall-cmd - firewalld command line client

zones in firewalld on OEL 8 are not treated as "private" in the sense of being
user-specific, but rather they allow for segmentation of network traffic based on
trust levels and network sources.

sudo useradd -c "John Doe, Web Developer" johndoe

getent passwd johndoe ---Check userinfo

In nftables, rules are organized into tables, and tables contain chains. Each chain
holds a set of rules that determine the actions on network packets
at various stages of the packet processing pipeline. The persistent configuration
is typically saved in /etc/sysconfig/nftables.conf.
There are three types of chains:

Input Chain (input): Handles incoming packets destined for the local system.
Output Chain (output): Handles outgoing packets originating from the local system.
Forward Chain (forward): Handles packets that are being forwarded between different
network interfaces (e.g., a router).
Each chain can have rules that determine what actions should be taken on packets
(e.g., accept, drop, log, etc.).

/proc files system and the properties of files within the /proc file system
difference between cgroup1 and 2
chroot jail
disable selinux temporarily

# Check current status

sestatus

# Temporarily disable SELinux (set to permissive mode)

sudo setenforce 0

# Verify that it's in permissive mode

sestatus

# Re-enable SELinux enforcing mode

sudo setenforce 1

ls /sys/fs/cgroup/
If you see subdirectories like cpu, memory, blkio, and others, it's using cgroup
v1.
If you see a directory called unified, it's using cgroup v2.

Feature cgroup v1
cgroup v2
Hierarchy Multiple hierarchies for different controllers
Single unified hierarchy for all controllers
Controller Management Independent controllers in separate hierarchies
Unified set of controllers for all resources
Resource Control Less advanced, fragmented support More
advanced, unified resource control
Delegation Not supported
Supports delegation and granular control
Process Management Per-hierarchy assignment of tasks
Single hierarchy for all process management
Security and Permissions Fragmented, different models per controller
Unified permission model for all controllers
Compatibility Widely used in older systems and applications
Not backward compatible with cgroup v1
Default in OEL 8 Supported but not the default
Default for most services (systemd, containers)

Virtual and Dynamic: Files in /proc do not exist on the disk; they are created in
memory by the kernel at runtime.
Kernel Interface: Provides access to kernel-related parameters, system statistics,
and process information.
Process-Specific Information: Directories and files in /proc contain information
about running processes, resource usage, and kernel settings.
System Monitoring: It's a valuable tool for system administrators and developers
for real-time system monitoring, debugging, and performance tuning

Text-based: Most files in /proc are text files, making it easy for administrators
and scripts to read and extract information.
Dynamic: The contents of the files are updated in real-time as the system changes.
For example, if the system's memory usage changes, the contents
of /proc/meminfo will automatically reflect those changes.
Read/Write: Some files in /proc are readable only, while others are writable,
allowing you to change kernel parameters. For instance, you can change
settings in /proc/sys/ by writing to certain files, which affect kernel behavior
immediately without requiring a reboot.

/proc/[pid] - Process Information:

Each running process has its own directory named after its Process ID (PID). Inside
this directory, you can find various files that contain information about the
process.
For example:
/proc/1234/ – The directory for the process with PID 1234.
Files within each process directory:
/proc/[pid]/status: Information about the process, including memory usage, process
state, etc.
/proc/[pid]/cmdline: The command line that started the process.
/proc/[pid]/fd/: A directory that contains symbolic links to the file descriptors
opened by the process.
/proc/[pid]/stat: Detailed information about the process, including state, memory
usage, CPU usage, etc.
/proc/[pid]/mem: This represents the memory of the process.

/proc/cpuinfo - CPU Information:

Contains information about the CPU architecture and available processors.

Example:

cat /proc/cpuinfo
Outputs details such as the number of CPUs, model name, cache size, and other CPU
features.

/proc/meminfo - Memory Information:

Displays detailed memory statistics.

Example:

cat /proc/meminfo
Displays information such as total memory, free memory, buffers, swap usage, etc.
/proc/uptime - System Uptime:

Contains two values: the system's total uptime (in seconds) and the amount of time
the system has been idle.
Example:

cat /proc/uptime

/proc/version - Kernel Version:

Displays information about the Linux kernel version and the GCC version used to
compile it.
Example:

cat /proc/version
Output might look like: Linux version 4.18.0-240.el8.x86_64 (gcc version 8.3.1
20190507 (Red Hat 8.3.1-5)) #1 SMP Thu Dec 12 12:30:01 EST 2019

/proc/filesystems - Supported Filesystems:

Lists all file systems supported by the kernel, including mounted and available
file systems.
Example:

cat /proc/filesystems
/proc/mounts - Mounted Filesystems:

Displays the list of currently mounted filesystems.

Example:

cat /proc/mounts
Output will include details like device, mount point, file system type, and mount
options.

/proc/sys/ - Kernel Parameters:

Contains files that control kernel parameters. These can be modified to configure
various kernel settings in real-time (e.g., network settings, security settings,
and more).
For example, to change the maximum number of open files:
bash
Copy code
echo 1024 > /proc/sys/fs/file-max
Examples:
/proc/sys/net/ipv4/ip_forward: Controls IP forwarding.
/proc/sys/vm/swappiness: Controls the kernel's preference for swapping.
/proc/partitions - Disk Partition Information:

Displays information about disk partitions and block devices.

Example:
bash
Copy code
cat /proc/partitions
/proc/net/ - Network Information:

Contains files related to networking, such as statistics on network interfaces,

connections, and protocol usage.
For example:
/proc/net/dev: Displays network device statistics (e.g., bytes received/sent).
/proc/net/tcp: Shows TCP connection information.
/proc/loadavg - Load Average:

Displays the system's load average over the last 1, 5, and 15 minutes.
Example:
bash
Copy code
cat /proc/loadavg
Output example:
Copy code
0.01 0.05 0.08 1/1949 12456
/proc/self - Self Information:

The /proc/self/ directory is a symbolic link to the current process’s directory

in /proc. For example, /proc/self/status would provide information about the
process that is executing the command.

augenrules

augenrules is a utility that helps to load and manage audit rules. Specifically, it
scans files in the /etc/audit/rules.d/ directory for individual rule files and then
combines these rules into a single, optimized rule set for the Audit Daemon. It is
commonly used to build persistent rules that survive reboots.

Location of Rules: Rules are placed in individual files in /etc/audit/rules.d/,

with .rules as the extension (e.g., audit.rules).
Output: After reading the rules, augenrules compiles them into a single file
located at /etc/audit/audit.rules, which is used by the Audit Daemon on startup.

Load Rules: To generate and load rules from the files in /etc/audit/rules.d/:

augenrules --load

This command reads the rule files, compiles them, and loads the resulting rules
into the active audit system.

Check Rules: To check for any syntax errors in the rule files before applying:

augenrules --check

This will identify errors in rule definitions that could prevent them from being
loaded.

/etc/audit/rules.d/example.rules)

Here is a simple example rule file to audit login events and modifications to
/etc/passwd:

# Audit all logins and logouts

-w /var/log/wtmp -p wa -k logins

# Audit changes to /etc/passwd

-w /etc/passwd -p wa -k passwd_changes

After creating this file, you can load it using augenrules --load

auditctl: Primarily used for adding, removing, or modifying audit rules in real-
time. Rules set with auditctl do not persist across reboots.
augenrules: Used for setting persistent audit rules that apply every time the Audit
Daemon starts. It reads and consolidates rule files from /etc/audit/rules.d/ to
make configuration management easier.

cryptsetup - supporting LV,VG,RAID, swap

journal log file

cfroup_no_v1

/etc/default/grub - changes persistant across reboots

Editing /etc/default/grub alone does not apply changes immediately. You must run
the grub2-mkconfig command to regenerate the GRUB configuration file.
If you do not update GRUB using grub2-mkconfig, the changes you made to
/etc/default/grub will not take effect, and the previous GRUB configuration will
still be used.
sudo grub2-mkconfig -o /boot/grub2/grub.cfg # for BIOS systems
This change will persist across reboots, as long as the GRUB configuration is
updated properly.

fireall rules for the zones are managed seperatly

selinux - nginx change default location. How to updated

SELinux uses contexts to enforce security policies on files and processes. If you
change the default location of an application like Nginx,
you need to ensure that SELinux recognizes the new path and applies the correct
security contexts to it.
Otherwise, SELinux may block access to the new location.

To update SELinux for Nginx when changing its default location:

Modify Nginx’s configuration to use the new directory.

Use semanage fcontext to add the new path with the appropriate SELinux context.

sudo semanage fcontext -a -t httpd_sys_content_t "/new/location(/.*)?"

This command updates SELinux to allow Nginx (which runs under the httpd type) to
access files in /new/location.

Explanation:
-a: Adds the new file context.
-t httpd_sys_content_t: Assigns the httpd_sys_content_t context (which is used for
web content files).
"/new/location(/.*)?": Specifies the path (with a wildcard to include
subdirectories).

Apply the SELinux context with restorecon.

sudo restorecon -R -v /new/location

Restart Nginx and check for any SELinux denials, applying additional SELinux rules
if needed.
sudo systemctl restart nginx
sudo ausearch -m avc -ts recent

This ensures that SELinux allows Nginx to read and serve content from the new
location while maintaining security policies.
nglix remove

Stop Nginx service:

sudo systemctl stop nginx

Disable Nginx from booting:

sudo systemctl disable nginx

Remove Nginx package:

sudo dnf remove nginx

Optionally remove residual files:

sudo rm -rf /etc/nginx /var/www/html /var/log/nginx

Optionally remove unused dependencies:

sudo dnf autoremove

dnf remove/dnf history run

ip link - modprob - ip address

root_squash

setfacl -m m::rw
m::rw: Specifies the mask (permissions limit) to rw (read and write) for all ACL
entries. The mask limits the permissions that other ACL entries can have.
In ACL, the mask (m) defines the maximum permissions for users (other than the
owner) and groups. Setting it to rw means that no user or group can have more than
read and write permissions on OEL8.

read and navigate to the directory

networkmanager - /etc/sysconfig/network - files

/etc/systemd/system(by running process) /usr/lib/systemd/system/(by system

administrator) multiuser target units

cron preference - correct

active-backup - B hash protocol

chrony - depends on high global/radio/multicast source - Radio Clocks: Configured

with refclock for hardware time sources like GPS.

The main configuration file for chronyd is /etc/chrony.conf, where you can specify
NTP servers, configure time sources, define access rules, and more.

ssh port config file

oracle user password expiration details - /etc/shado, bash_rc, /etc/profile.d,
/home/bash...

anonymous_enable: Enables or disables anonymous FTP access (YES or NO). - FTP write
access

unit no longer required - which logfile

If persistent journaling is enabled, logs are stored in:

/var/log/journal/ – Persistent storage for journald logs if configured.

Otherwise, journald logs are kept in memory (volatile storage) and are not saved
across reboots.
/run/log/journal/

PAM - satisfied, required, option etc....

podman pull docker - registry tag, repository location

podman pull docker.io/library/ubuntu:latest

This command pulls the ubuntu image from Docker Hub (the default registry) with the
latest tag.

auditctl -S --systemcall or number, -F when to start auditing

The -F option in auditctl is a filtering option for creating detailed audit rules
based on specific conditions.
It does not specify when to start auditing but rather defines criteria that must be
met for the rule to trigger.

Common Usage of auditctl -F

Here's a breakdown of some common filters that can be used with auditctl -F:

Filter by UID (User ID)

To capture events only for a specific user ID:

auditctl -a always,exit -S open -F uid=1000

This rule captures all open system calls by the user with UID 1000.

Filter by GID (Group ID)

To capture events only for a specific group ID:

auditctl -a always,exit -S open -F gid=1001

This captures all open system calls made by users in the group with GID 1001.

Filter by Path (File Path)

To capture access to a specific file:

auditctl -a always,exit -F path=/etc/passwd -F perm=wa

This rule logs write and attribute changes (wa) to /etc/passwd.

Filter by Key (for Easier Search)

The key option can be used with -F to label events, making them easier to
search for later:

auditctl -a always,exit -S open -F path=/etc/shadow -k shadow_access

This tags any access to /etc/shadow with shadow_access for easy searching in
audit logs.

Filter by PID (Process ID)

To capture actions by a specific process:

auditctl -a always,exit -S execve -F pid=1234

This captures all execve calls made by the process with PID 1234.

Filter by Capability

To monitor for specific capabilities used by processes:

auditctl -a always,exit -S capset -F auid>=1000

This rule captures capset calls made by users with an AUID (Audit User ID) greater
than or equal to 1000.

IOSTAT - REPEATED STATS - COUNT, INTERVAL

kubctl run ----port

ksplice can update which user patches -> openssh, openssl, glib, kernal ....

ss command

changing system parameters using echo is persistant across reboot

changes in the sysctl.com are affected on boot

rsyslog - include/exclude

LVM is visible to users

Accessing LVM Information (Admin Privileges Required)

To view and manage LVM volumes in detail, users need root or sudo privileges. With
elevated permissions, users can use the following commands:

lvdisplay: Shows details about logical volumes.

vgdisplay: Shows details about volume groups.
pvdisplay: Shows details about physical volumes.
lvs, vgs, pvs: Provides summaries of logical volumes, volume groups, and
physical volumes.

ip link command - vlan

permissive, enforcing -> audit

UPG -> umask, setgid,

partition tables

wireshark/tshark - On Oracle Enterprise Linux 8 (OEL8), you can install and use
Wireshark and TShark (the command-line version of Wireshark) to
capture and analyze network packets.

XFSGROWFS

default log location in OEL

auditctl load/list/control/

What xfs_growfs Expands

File System: xfs_growfs only expands the XFS file system itself, allowing it to
utilize additional free space on its partition or logical volume.
It does not modify or extend the partition or logical volume.
When run, xfs_growfs adjusts the file system’s internal structures to make use of
the extra space now available on the disk, but only within the
limits of the existing partition or logical volume.

Key dnf history Options

dnf history list

Lists recent transactions, similar to running dnf history without
additional options.
Example: dnf history list

dnf history info <transaction_id>

Displays detailed information about a specific transaction.
Example: dnf history info 3

dnf history undo <transaction_id>

Reverts the effects of a specific transaction. For example, if a package
was installed, it will be removed, or if it was removed, it will be reinstalled.
Example: dnf history undo 5

dnf history redo <transaction_id>

Re-executes a previous transaction, applying the same actions again.
Example: dnf history redo 4

dnf history rollback <transaction_id>

Rolls back all transactions up to and including the specified transaction
ID. Useful if you want to revert the system to a previous state.
Example: dnf history rollback 2

dnf history userinstalled

Lists packages that were manually installed by the user, filtering out
those that were installed as dependencies.
Example: dnf history userinstalled

dnf history reset

Clears the transaction history, resetting the dnf history log.
 Example: dnf history reset

Key Options for podman pull

--all-tags, -a
Pulls all tags of an image instead of just the specified tag.
Example: podman pull -a docker.io/library/ubuntu

--authfile
Specifies the path to the authentication file for logging into a private
registry.
Example: podman pull --authfile /path/to/auth.json docker.io/library/ubuntu

--cert-dir
Sets the directory where certificate files are stored for accessing a
registry securely (e.g., .crt, .cert, .key).
Example: podman pull --cert-dir /path/to/certs docker.io/library/ubuntu

--creds
Allows you to specify username and password for authenticating to a
registry. The format is username:password.
Example: podman pull --creds myuser:mypassword registry.example.com/myimage

--quiet, -q
Reduces the output, showing minimal details during the pull operation.
Example: podman pull -q docker.io/library/ubuntu

--tls-verify
Toggles TLS verification for the registry. Use --tls-verify=false to pull
from a registry without verifying its certificate (useful for self-signed
certificates).
Example: podman pull --tls-verify=false registry.example.com/myimage

--no-store
Disables saving the image in local storage. This option is typically used
in specific use cases, like one-off analysis.
Example: podman pull --no-store docker.io/library/ubuntu

--override-arch
Forces podman to pull an image for a specified architecture, such as arm64
or amd64.
Example: podman pull --override-arch=arm64 docker.io/library/ubuntu

--override-os
Similar to --override-arch, this option forces pulling an image for a
specified operating system, like linux or windows.
Example: podman pull --override-os=linux docker.io/library/ubuntu

--override-variant
Specifies the variant of the architecture, useful in cases where an
architecture has multiple variants (e.g., ARM's v7 or v8).
Example: podman pull --override-variant=v7 docker.io/library/ubuntu

skopeo inspect docker://docker.io/library/nginx:latest

the registry is docker.io. This is the domain of Docker Hub, which is where the
nginx:latest image is hosted.
Here’s a breakdown of the command:

docker:// – Protocol that specifies the type of container registry.

docker.io – The registry, which in this case is Docker Hub.
library/nginx:latest – The image path, where:
library is the namespace (used as a default for popular images on Docker Hub).
nginx is the repository name.
latest is the tag specifying the version of the image.
So, in this example, docker.io is the registry where Skopeo is inspecting the image
nginx under the library namespace with the latest tag.

cgroup_no_v1 allows administrators to selectively or entirely disable cgroups v1

controllers to take full advantage of the newer cgroups v2 system.

Edit the GRUB configuration file, typically /etc/default/grub.

Add cgroup_no_v1 with your desired value to the GRUB_CMDLINE_LINUX line, for
example:

GRUB_CMDLINE_LINUX="cgroup_no_v1=all"

Update the GRUB configuration:

sudo update-grub # or `grub2-mkconfig -o /boot/grub2/grub.cfg

'
cgroup_no_v1=all

This disables cgroups v1 entirely, making the system use only cgroups v2.

cgroup_no_v1=memory,blkio

This disables the memory and blkio (block I/O) controllers for cgroups v1, while
leaving other controllers in v1 mode if needed.
The cgroup_no_v1 parameter allows you to disable specific or all controllers from
using cgroups v1 in favor of using the unified cgroups v2 hierarchy.

The cgroup_no_v1 parameter allows you to disable specific or all controllers from
using cgroups v1 in favor of using the unified cgroups v2 hierarchy.

/etc/passwd: Contains basic user account information.

/etc/shadow: Stores password expiration and aging information.
/etc/login.defs: Contains global password expiration settings.
/etc/pam.d/: Contains PAM configuration files, including settings for password
management.
chage command: Provides a way to view and modify user password expiration details.

Log Type Log File/Location Description

System Logs /var/log/messages General system messages and various
service logs.
/var/log/secure Security-related logs
(authentication, sudo usage).
/var/log/dmesg Kernel boot messages (kernel
ring buffer logs).
Systemd Journal Logs /run/log/journal/ Volatile system logs (cleared on
reboot).
/var/log/journal/ Persistent system logs (if
configured).
systemd-journald is a logging service that collects and manages log data from
various sources, such as the kernel, SERVICES, and applications.
This service is part of systemd and stores logs in a structured, binary format,
allowing for efficient log management, filtering, and searching.

Binary Log Storage: Logs are stored in binary format, which enables quick querying
and reduced disk usage. Unlike traditional text logs in /var/log,
this format allows structured and organized data retrieval.
Centralized Logging: systemd-journald aggregates logs from different sources,
including the kernel, boot messages, and individual service logs,
into a single system.
Log Persistence: Logs are stored either temporarily in /run/log/journal/ (volatile
storage cleared on reboot) or persistently in /var/log/journal/
(if configured for permanent storage).
Data Integrity: Journald verifies log integrity to help detect tampering or
corruption.

The configuration file for systemd-journald on Oracle Enterprise Linux 8 (OEL8) is:

/etc/systemd/journald.conf

Persistent Logging: To ensure logs are saved across reboots, set

Storage=persistent.
Space Management: Use SystemMaxUse, SystemKeepFree, and RuntimeMaxUse to control
disk usage.
Rate Limiting: Adjust RateLimitInterval and RateLimitBurst to prevent log flooding.

Compress= Enables compression of log files to save space (yes or no). ---Default
yes

Editing the Configuration File

Open the file with a text editor (e.g., nano or vim):

sudo nano /etc/systemd/journald.conf

Modify the options as needed. For example, to enable persistent logging, set:

Storage=persistent

Save the changes and restart systemd-journald for the changes to take effect:

sudo systemctl restart systemd-journald

journalctl command options:

Option Description Example

-u <unit> Show logs for a specific systemd service unit. journalctl -u
httpd.service
-f Display logs in real-time (similar to tail -f). journalctl -f
-k Show only kernel logs. journalctl -k
-p <priority> Filter logs by priority level (e.g., err, warning). journalctl -
p err
--since <time> Show logs since a specific date or time. journalctl --since
"2024-11-01"
--until <time> Show logs up to a specific date or time. journalctl --until
"2024-11-01 18:00"
-b Show logs from the current boot. journalctl -b
-b -1 Show logs from the previous boot. journalctl -b -1
-o <output-format> Specify the output format (e.g., short, json, verbose).
journalctl -o json
-n <number> Show the last n log entries. journalctl -n 50
-x Show explanatory messages for logs, when available. journalctl -xe
--no-pager Show logs without paging, useful for scripts. journalctl --no-pager
--disk-usage Show the total disk space used by the journal. journalctl --disk-
usage
--list-boots List available boot entries, showing boot times and IDs.
journalctl --list-boots
-r Reverse the order to show the newest entries first. journalctl -r
--grep <pattern> Filter logs by a specific pattern or keyword. journalctl --grep
"error"
-S <cursor> Show logs starting from a specific cursor (useful for automation).
journalctl -S "<cursor>"

If cron.allow exists - only users listed into it can use crontab

If cron.allow does not exist - all users except the users listed into cron.deny can
use crontab
If neither of the file exists - only the root can use crontab
If a user is listed in both cron.allow and cron.deny - that user can use crontab

The iproute2 package in Linux provides a suite of networking tools that replace
many of the older networking utilities.
It is used for advanced network management tasks, such as configuring network
interfaces, managing routes, setting up network namespaces, and more
iproute2 Commands:
Command Description
ip link Manage network interfaces.
ip addr Manage IP addresses.
ip route Manage routes and routing tables.
ip addr add Add an IP address to an interface.
ip link set Enable or disable network interfaces.
ss Display socket statistics and network connections.
tc Configure and manage network traffic control (QoS,
bandwidth shaping).
rtmon Monitor routing table changes.
bridge Manage Ethernet bridges and bridge-related
configurations.
ip netns Manage network namespaces.

Create the VLAN interface:

sudo ip link add link eth0 name eth0.100 type vlan id 100

Bring the interface up:

sudo ip link set dev eth0.100 up

Assign a static IP address:

sudo ip addr add 192.168.1.10/24 dev eth0.100

(Optional) Use DHCP:

sudo dhclient eth0.100

Configure the VLAN for persistence by editing /etc/sysconfig/network-scripts/ifcfg-

eth0.100.

Restart the network service:

sudo systemctl restart network

Normally, no need for modprobe: The 8021q module is often loaded by default on most
modern Linux distributions, so you should not need to manually load it.
If needed, use modprobe 8021q to load the VLAN kernel module, and you can ensure it
is loaded on boot with the /etc/modules-load.d/ configuration.

Key Differences Between iproute2 and NetworkManager

Feature iproute2
NetworkManager
Purpose Low-level network configuration and management
High-level network management and automation
Scope Focused on advanced network settings (IP addresses, routes,
interfaces, tunnels) Designed to manage all types of network connections
(Ethernet, Wi-Fi, VPN, mobile)
Primary Users Network administrators and advanced users
End users, desktop users, and systems with dynamic network configurations
Key Tools ip, ss, tc, bridge, route, tunnel
nmcli, nmtui, graphical tools (e.g., GNOME or KDE network settings)
Configuration Type Manual and detailed configuration
Automated, with profiles and dynamic management
Network Interface Management Detailed control over interfaces (e.g., bring
up/down interfaces, assign IPs) Manages interfaces automatically with user-
defined profiles
Routing and Traffic Control Provides full control over routing and QoS via ip
route and tc Automatically manages routing, though less granular control than
iproute2
Network Services Does not manage network services or connections Provides dynamic
management of network services (e.g., automatically connects to known Wi-Fi
networks)
Flexibility Very flexible and powerful, but requires more expertise Simple to
use but less flexible for advanced configurations

cryptsetup is a utility for managing LUKS (Linux Unified Key Setup) and plain dm-
crypt encrypted devices. It is used to set up, configure, and manage encrypted
volumes to secure data.

cryptsetup can encrypt most block devices, including:

PHYSICAL VOLUMES (PVS):

Entire disks like /dev/sda, /dev/nvme0n1.

PARTITIONS:
Specific partitions like /dev/sda1.

LVM DEVICES:
Logical Volumes (LVs) created within LVM.
Volume Groups (VGs) indirectly, by encrypting the PV or LV.

RAID DEVICES:
Devices managed by RAID (e.g., /dev/md0) can be encrypted like any block
device.
 SWAP DEVICES:
Swap partitions or files (use cryptsetup with --TYPE=PLAIN for ephemeral
swap encryption).

FILE-BASED LOOP DEVICES:

Files used as block devices via losetup.

Configuration Files

/etc/crypttab:
Used to automatically open encrypted volumes during boot. Example:

my_encrypted_device UUID=1234-5678-90abcdef none luks

/etc/fstab:

To mount unlocked devices:

/dev/mapper/my_encrypted_device /mnt ext4 defaults 0 0

Check Device Status:

cryptsetup status my_encrypted_device

Check LUKS Device Information

cryptsetup luksDump /dev/sdX

dm-crypt is the kernel-level device mapper encryption module used to encrypt block
devices on Linux. It provides encryption functionality to tools like cryptsetup,
enabling you to secure physical disks, logical volumes, RAID arrays, and swap
devices.

sudo dnf install cryptsetup

Format the Device with LUKS:

sudo cryptsetup luksFormat /dev/sdX

Options:
--type luks1: Use LUKS1 format (default on OEL8 is LUKS2).
--cipher aes-xts-plain64: Specify the encryption cipher.
--key-size 256: Set encryption key size.
--hash sha256: Define the hash function for key derivation.

Open (Unlock) the Encrypted Device: Create a mapped device for the encrypted block
device:

sudo cryptsetup open /dev/sdX mycrypt

Create a File System: Format the mapped device with a file system:

sudo mkfs.ext4 /dev/mapper/mycrypt

Mount the Encrypted Device: Mount it to a directory:

sudo mkdir /mnt/secure

sudo mount /dev/mapper/mycrypt /mnt/secure
Encrypting swap ensures that sensitive data written to swap space is secure:

Set Up Encrypted Swap:

sudo cryptsetup open --type=plain /dev/sdX cryptswap

sudo mkswap /dev/mapper/cryptswap
sudo swapon /dev/mapper/cryptswap

Configure Persistent Swap: Add to /etc/crypttab:

cryptswap /dev/sdX /dev/urandom swap,cipher=aes-xts-plain64,size=256

swapon: /.swapfile: insecure permissions 0644, 0600 suggested.

swapon: /.swapfile: read swap header failed

Adjust the file permissions:

sudo chmod 600 /.swapfile

The error swapon: /.swapfile: read swap header failed indicates that the swap file
is not properly initialized as swap space.

Re-create the swap file:

Turn off swap (if active):

sudo swapoff /.swapfile

Create the swap file (replace <size> with the desired size, e.g., 1G):

sudo dd if=/dev/zero of=/.swapfile bs=1M count=<size>

Set proper permissions:

sudo chmod 600 /.swapfile

Initialize the file as swap space:

sudo mkswap /.swapfile

Enable the swap file:

sudo swapon /.swapfile

Verify the swap file:

sudo swapon --show

Check /etc/fstab for a correct entry:

/.swapfile none swap sw 0 0

/.swapfile: The path to the swap file.

none: No mount point, as swap does not need one.
swap: The swap file system type.
sw: The swap file system option (enables swap).
0: The dump option (does not need to be backed up).
0: The fsck option (no need to check the swap file).

cat /proc/swaps

Sample Output:

Filename Type Size Used Priority

/dev/sda2 partition 2097148 0 -2

cat /proc/meminfo | grep -i swap

Sample Output:

SwapTotal: 2097148 kB
SwapFree: 2097148 kB
SwapCached: 0 kB

root_squash: When enabled, this option maps the root user (UID 0) on the client
machine to a non-privileged user (typically nobody) on the NFS server. This
prevents the client’s root user from having root privileges on the server,
enhancing security.

no_root_squash: This option disables the mapping of the root user to nobody. This
allows the root user on the client machine to have root privileges on the NFS
server as well, which may be required in some specific use cases but introduces
potential security risks.

With root_squash:

The root user on the client machine (UID 0) is mapped to a non-privileged user
on the NFS server (usually nfsnobody or nobody, with UID 65534).
This ensures that the root user does not have unrestricted access to the NFS
share, preventing possible unauthorized changes or damage.

With no_root_squash:

The root user on the client machine is allowed to have root privileges on the
NFS server.
This might be necessary in certain configurations but is generally considered
risky because it exposes the server to potential abuse or mistakes by the root user
on the client.

Example in /etc/exports on the NFS Server

The root_squash and no_root_squash options are configured in the /etc/exports file
on the NFS server.
Using root_squash (default)

/shared_directory <client_ip_or_network>(rw,sync,root_squash)

all_squash: This option maps all clients’ requests (including root) to the
nfsnobody user. It’s typically used for shared data where no client should have
elevated privileges.

Install NFS utilities using dnf install nfs-utils.

Enable and start the NFS server with systemctl enable --now nfs-server.
Configure shared directories in /etc/exports.
Apply changes using exportfs -ra.
Adjust firewall settings to allow NFS traffic.
Test the NFS server by mounting the share on a client machine.

Relevance in OEL8 and NetworkManager

Deprecated for NetworkManager:

When NetworkManager is used, /etc/sysconfig/network is largely ignored.
NetworkManager uses its own configuration files located in /etc/NetworkManager/
or /etc/NetworkManager/system-connections/.

Compatibility with Legacy Systems:

If the legacy network service is used instead of NetworkManager,
/etc/sysconfig/network may still play a role in system-wide network configuration.

Hostname Management:
Modern systems prefer managing hostnames using the hostnamectl command or
by editing /etc/hostname, rather than relying on /etc/sysconfig/network.

Contents of /etc/sysconfig/network

A typical /etc/sysconfig/network file might look like this:

NETWORKING=yes
HOSTNAME=myserver.example.com
GATEWAY=192.168.1.1

NetworkManager supports /etc/sysconfig/network-scripts for backward compatibility

with ifcfg files.
The NM_CONTROLLED directive in ifcfg files determines whether NetworkManager
manages an interface.
Modern setups often use NetworkManager's native configuration profiles stored in
/etc/NetworkManager/system-connections/.
The relationship can be controlled through NetworkManager.conf and ifcfg file
directives.

In OEL8, NetworkManager is the default tool for managing networks.

It is configured to read ifcfg files by default, but modern configurations prefer
using profiles stored in /etc/NetworkManager/system-connections/.

If you are transitioning from legacy network scripts to NetworkManager:

Convert existing ifcfg configurations into NetworkManager profiles using nmcli

or nmtui.
Optionally remove or disable the ifcfg files to avoid conflicts.

NM_CONTROLLED Directive in ifcfg Files

In the ifcfg-<interface> files, the NM_CONTROLLED directive determines whether

NetworkManager should manage the interface:

Syntax:

NM_CONTROLLED=yes

yes: NetworkManager manages this interface.

no: NetworkManager does not manage this interface, and it is left to other
tools (like network service).
Control in NetworkManager.conf

You can globally configure NetworkManager to manage or ignore ifcfg files by

editing /etc/NetworkManager/NetworkManager.conf:

To use ifcfg files:

[main]
plugins=ifcfg-rh

To ignore ifcfg files: Omit or change the plugins setting.

How NetworkManager Uses /etc/sysconfig/network-scripts:

Reads Existing Configurations:

If ifcfg-<interface> files exist, NetworkManager can read and apply their
settings.
Creates New Configurations:
When you create or modify a connection using nmcli or nmtui, NetworkManager
can save the configuration back into ifcfg files (if configured to do so).
Ignores ifcfg Files if Disabled:
If explicitly configured, NetworkManager can ignore ifcfg files and use its
own connection profiles stored in /etc/NetworkManager/system-connections/.

Use systemctl status NetworkManager to confirm if NetworkManager is running and

enabled.
Use nmcli device status to list interfaces and their management state.

Global Configuration File:

Check /etc/NetworkManager/NetworkManager.conf for unmanaged interfaces:

cat /etc/NetworkManager/NetworkManager.conf

Look for the [keyfile] section:

[keyfile]
unmanaged-devices=interface-name:eth0

If any interfaces are listed under unmanaged-devices, they are not managed by
NetworkManager.

nmcli device status

Example Output:

DEVICE TYPE STATE CONNECTION

eth0 ethernet connected Wired Connection 1
wlan0 wifi disconnected --
lo loopback unmanaged --

connected: The interface is managed by NetworkManager and active.

disconnected: Managed but not connected.
unmanaged: Not managed by NetworkManager.

NetworkManager does not manage all interfaces by default but manages those defined
in its profiles unless explicitly excluded.
To control which interfaces NetworkManager handles, use
/etc/NetworkManager/NetworkManager.conf or the NM_CONTROLLED directive in
traditional ifcfg files.

NetworkManager Management Defaults

Managed by Default:
NetworkManager manages interfaces defined in its connection profiles
located in /etc/NetworkManager/system-connections/.
It dynamically manages interfaces unless explicitly instructed not to.

Unmanaged Interfaces:
Interfaces are not managed by NetworkManager if:
They are configured manually using traditional configuration files
(e.g., /etc/sysconfig/network-scripts/).
The unmanaged directive is set in
/etc/NetworkManager/NetworkManager.conf.

If a network interface has an ONBOOT=no in its configuration file, NetworkManager

will not manage it.

vi /etc/sysconfig/network-scripts/ifcfg-eth0

Example:

DEVICE=eth0
BOOTPROTO=none
ONBOOT=no

Alternatively, you can specify:

NM_CONTROLLED=no

Managing All Interfaces

Force NetworkManager to Manage All Interfaces

To ensure that all interfaces are managed by NetworkManager, remove any unmanaged
directives from /etc/NetworkManager/NetworkManager.conf and legacy configuration
files:

Edit /etc/NetworkManager/NetworkManager.conf:

[keyfile]
unmanaged-devices=

Restart NetworkManager:

sudo systemctl restart NetworkManager

Enable NetworkManager to Control Legacy Configurations

If the legacy network service is used, disable it and allow NetworkManager to take
over:

sudo systemctl stop network

sudo systemctl disable network
sudo systemctl enable --now NetworkManager

NetworkManager is the primary network configuration tool in Oracle Linux 8 (OEL8).

It manages network connections dynamically and provides a uniform way to configure
network interfaces through command-line tools, configuration files, or graphical
utilities.

Dynamic Network Management:

Automatically handles connections for wired, wireless, and VPN interfaces.

Supports automatic switching between network connections (e.g., Wi-Fi to
Ethernet).

Support for Advanced Networking:

VLANs, bonds, bridges, and other complex network setups.

VPN integration with support for common protocols (e.g., OpenVPN, IPsec).

Easy Configuration:

Command-line interface (nmcli) and a graphical tool (nmtui) for easy network
management.
Configuration via standard files in /etc/NetworkManager/.

Connectivity Checks:

Monitors internet connectivity and handles auto-reconnect.

Network Profiles:

Allows saving and managing multiple configurations for different network

interfaces or environments.

NetworkManager Components

Command-Line Tools:
nmcli: A powerful command-line interface for managing NetworkManager.
nmtui: A text-based user interface for NetworkManager.

System Services:
NetworkManager service: Manages network interfaces.
network service: Legacy service, usually disabled on modern setups.

Configuration Files:
Located in /etc/NetworkManager/system-connections/.
Each file represents a saved network connection.

Key Configuration Files

Global Configuration:

/etc/NetworkManager/NetworkManager.conf - Configures global settings for

NetworkManager.
/usr/lib/NetworkManager/conf.d/: Default configuration files.
/etc/NetworkManager/conf.d/: Custom configuration files (overrides default
settings).

Connection Profiles:

/etc/NetworkManager/system-connections/
Contains one file per saved network connection.

Log Files:
 /var/log/messages: General log file for NetworkManager activities.
Use journalctl for detailed logs:

journalctl -u NetworkManager

Command-Line Interface: nmcli

Check Network Status:

nmcli general status

List Available Connections:

nmcli connection show

Activate/Deactivate a Connection:

nmcli connection up <connection_name>

nmcli connection down <connection_name>

Create a New Connection:

nmcli connection add type ethernet ifname eth0 con-name my-connection

ipv4.addresses 192.168.1.10/24 ipv4.gateway 192.168.1.1 ipv4.dns 8.8.8.8
ipv4.method manual

Modify an Existing Connection:

nmcli connection modify my-connection ipv4.addresses 192.168.1.20/24

Delete a Connection:

nmcli connection delete my-connection

Text-Based Interface: nmtui

Start nmtui:

nmtui

Choose from options like:

Edit a connection.
Activate a connection.
Set system hostname.

Create a DHCP Connection:

nmcli connection add type ethernet ifname eth0 con-name dhcp-connection ipv4.method
auto

Activate It:

nmcli connection up dhcp-connection

Set a Hostname

Change Hostname Temporarily:

nmcli general hostname new-hostname

Set Hostname Permanently:

hostnamectl set-hostname new-hostname

/usr/lib/systemd/system:

Contains default unit files provided by the OS or installed packages.

Do not edit files directly; changes are overwritten during updates.

/etc/systemd/system:

Contains custom unit files or overrides.

Use this directory to create persistent custom configurations.

Precedence:

/etc/systemd/system overrides /usr/lib/systemd/system.

Always use /etc/systemd/system for customizations.

/usr/lib/systemd/system

This directory contains the default unit files provided by installed packages. It
is the primary location where unit files are placed by the operating system or
software packages during installation.
Key Features:

Package-Managed:
Unit files in this directory are managed by the package manager (e.g.,
dnf).
Updates or reinstalls of the package can overwrite these files.
Default Unit Files:
These are the unmodified, original configurations provided by software
vendors.

When to Use:

Do not edit files directly in this directory. Changes can be overwritten during
software updates.

Examples:

Service unit files such as:

/usr/lib/systemd/system/sshd.service
/usr/lib/systemd/system/httpd.service

2. /etc/systemd/system

This directory contains customized unit files or overrides. It is where

administrators can modify or create their own unit files without risking overwrites
by package updates.
Key Features:

Administrator-Managed:
Files in this directory take precedence over those in
/usr/lib/systemd/system.
 Custom Overrides:
If you need to customize a service, create or edit the unit file here.
Overrides specific to a unit can be placed in a .d directory (e.g.,
/etc/systemd/system/ssh.service.d/).

Persistent Changes:
Unit files in this directory are not affected by package updates.

When to Use:

Use this directory for:

Custom unit files.
Overriding default unit files with a modified configuration.

Examples:

Custom unit file:

/etc/systemd/system/my-custom.service

Override directory for a service:

/etc/systemd/system/sshd.service.d/custom.conf

Precedence Order

When systemd looks for a unit file, it uses the following precedence (highest to
lowest):

/etc/systemd/system/
/run/systemd/system/ (runtime-only overrides; lost on reboot)
/usr/lib/systemd/system/

If a unit file exists in multiple locations, the one with the highest precedence is
used.

How to Work with These Directories

Override a Unit File:

To customize a unit file:

Create an override directory for the service:

sudo mkdir -p /etc/systemd/system/<service>.service.d

Create a drop-in override file:

sudo vi /etc/systemd/system/<service>.service.d/custom.conf

Add custom configurations:

[Service]
Environment="CUSTOM_VAR=value"

Reload systemd to apply changes:

sudo systemctl daemon-reload

Create a New Unit File:

 Create a unit file in /etc/systemd/system/:

sudo vi /etc/systemd/system/my-custom.service

Define the unit file content:

[Unit]
Description=My Custom Service
After=network.target

[Service]
ExecStart=/path/to/command
Restart=always

[Install]
WantedBy=multi-user.target

Reload systemd and enable the service:

sudo systemctl daemon-reload

sudo systemctl enable my-custom.service

4. Commands to Explore and Manage Unit Files

List All Unit Files:

systemctl list-unit-files

Show Active Units:

systemctl list-units

Inspect a Unit File:

systemctl cat <unit-name>

Edit a Unit File:

sudo systemctl edit <unit-name>

This opens a safe editor for creating overrides in /etc/systemd/system.