Notes New
Notes New
GRUB 2 displays a boot menu during startup. You can use this menu to select the
kernel version or operating system to boot.
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.
To re-scan for additional OS installations (if added after Oracle Linux), ensure
os-prober is installed, then run:
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.
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
/etc/auto.nfs:
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
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:
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
To limit a process to 512MB of memory and 25% CPU usage in a cgroup using systemd:
[Service]
ExecStart=/path/to/your/application
MemoryMax=512M
CPUQuota=25%
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).
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.
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:
. 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
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:
Controls various aspects of the FTP server, including security, user access,
permissions, logging, and passive/active FTP modes.
/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
Skopeo allows inspecting images directly from registries without needing to pull
them, providing metadata and other image details.
podman inspect
Purpose: Primarily used to inspect images and containers that are stored
locally or actively running on the host machine.
Command Syntax:
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:
skopeo inspect
Scope: Remote and Local Images
Command Syntax:
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.
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.
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
-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:
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
/etc/lvm/lvm.conf
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).
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.
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
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.
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.
cat /proc/cpuinfo
Outputs details such as the number of CPUs, model name, cache size, and other CPU
features.
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
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
Lists all file systems supported by the kernel, including mounted and available
file systems.
Example:
cat /proc/filesystems
/proc/mounts - Mounted Filesystems:
cat /proc/mounts
Output will include details like device, mount point, file system type, and mount
options.
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 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:
augenrules
cfroup_no_v1
nglix remove
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.
anonymous_enable: Enables or disables anonymous FTP access (YES or NO). - FTP write
access
This command pulls the ubuntu image from Docker Hub (the default registry) with the
latest tag.
ksplice can update which user patches -> openssh, openssl, glib, kernal ....
ss command
rsyslog - include/exclude
partition tables
wireshark/tshark -
XFSGROWFS
--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
GRUB_CMDLINE_LINUX="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.