This week, I focused on connecting those pieces.

In this post, I will cover a few foundational terms, explain how Linux services are managed with systemd, set up a simple Apache web server, and finally look at how Flatpak installs desktop applications differently from DNF.

Note: I practised these commands on Red Hat Enterprise Linux (RHEL) while logged in as the root user, as we do during system-administration practice. Therefore, the administrative commands below do not use sudo. On a regular user account, equivalent commands require appropriate privileges.

1. A Few Terms That Made Everything Easier

Before working with services and software, it helps to understand a few terms that appear everywhere in Linux.

Configuration file

A configuration file is a file that stores settings used by a program or service.

Instead of changing the program's source code, we edit its configuration to control how it behaves. For example, a web server's configuration can define which port it listens on, where website files are stored, and which modules are enabled.

Configuration files are commonly found inside /etc.

Plug-in

A plug-in is an additional component that adds a feature to an existing program without replacing the entire program.

For example, a plug-in may add authentication support, a new command, or integration with another tool.

Bare metal

Bare metal means a physical computer running an operating system directly on its hardware, without a virtualization layer between them.

Virtual machine and hypervisor

A virtual machine (VM) is a software-created computer with its own virtual CPU, memory, storage, and operating system.

A hypervisor creates and manages virtual machines by allocating physical resources to them.

I use VMware Workstation on my laptop to run a RHEL virtual machine, so that is a Type 2 hypervisor setup.

2. What Does SSH Actually Do?

SSH (Secure Shell) lets us securely access and control another machine over a network.

Suppose my laptop needs to manage a remote Linux server:

• My laptop is the SSH client because it initiates the connection.

• The remote machine is the SSH server because it accepts the connection.

• The sshd daemon on the server listens for SSH connections.

• SSH normally uses TCP port 22.

To connect, I can run:

ssh username@server-ip

For example:

ssh zia@192.168.1.50

Once the connection is established, commands typed in my terminal are executed on the remote machine, not on my laptop. SSH encrypts the communication between the client and server.

SSH authentication

Two common ways to authenticate are:

1. Password authentication — enter the remote user's password.

2. SSH key authentication — the client keeps a private key, while the matching public key is placed on the server.

The private key must remain secret. The public key can safely be copied to the server.

Checking the SSH service

The remote server needs its SSH service running:

systemctl status sshd
systemctl enable --now sshd

The second command both starts sshd now and enables it to start automatically during future boots.

If firewalld is running on the server, SSH must also be allowed through the appropriate firewall zone:

firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload

Opening SSH on my laptop is not required merely to connect out to another machine. The firewall rule matters on the machine accepting incoming SSH connections.

3. Services and Daemons in Linux

A service is a program or process that provides a function, usually in the background.

Examples include:

A daemon is a background process that waits for work or continuously provides a service. Many daemon names end in d, such as sshd and httpd, although this is a convention rather than a strict rule.

What is systemd?

systemd is the system and service manager used by RHEL and many other Linux distributions.

During boot, the Linux kernel starts systemd as the first user-space process, normally with Process ID (PID) 1. systemd then starts the services and other units required by the system.

What is systemctl?

systemctl is the command-line tool used to communicate with systemd.

The basic pattern is:

systemctl action unit

For example:

systemctl restart httpd

Here:

• systemctl is the management command.

• restart is the requested action.

• httpd is the service being managed.

Common systemctl commands

systemctl start httpd
systemctl stop httpd
systemctl restart httpd
systemctl status httpd
systemctl enable httpd
systemctl disable httpd

These actions are not interchangeable:

To start a service now and enable it for future boots in one command:

systemctl enable --now httpd

To verify both conditions separately:

systemctl is-active httpd
systemctl is-enabled httpd

What is a unit file?

systemd manages resources as units. A service unit file, such as httpd.service, contains instructions that tell systemd how the service should be started, stopped, and supervised, along with dependencies and boot-related settings.

Common unit-file locations include:

• /usr/lib/systemd/system/ for files supplied by installed packages

• /etc/systemd/system/ for administrator-created units and overrides

• /run/systemd/system/ for temporary runtime units

To see the unit file used for a service:

systemctl cat httpd

If a unit file is manually added or changed, tell systemd to reread its unit definitions:

systemctl daemon-reload

This reloads systemd's unit-file configuration. It does not automatically restart the service itself.

4. Practical Example: Running an Apache Web Server

Apache HTTP Server provides web pages to clients. On RHEL, its package and service are called httpd.

Step 1: Install Apache

dnf install -y httpd

dnf installs the httpd package and its required dependencies from configured RPM repositories.

Step 2: Start it now and at boot

systemctl enable --now httpd

Step 3: Check its status

systemctl status httpd

Step 4: Create a simple web page

Apache's default document root on RHEL is /var/www/html.

echo "Hello from The Logbook" > /var/www/html/index.html

Step 5: Test it locally

curl http://localhost

If Apache is working, the terminal should return:

Hello from The Logbook

Step 6: Allow HTTP through the firewall

If other machines need to open the page and firewalld is active, allow the predefined HTTP service:

firewall-cmd --permanent --add-service=http
firewall-cmd --reload

HTTP normally uses TCP port 80, while HTTPS normally uses TCP port 443.

The --permanent option saves the rule so it remains after reboot. --reload applies the permanent configuration to the running firewall.

Check the active firewall configuration with:

firewall-cmd --list-all

The complete request path now looks like this:

Browser -> server firewall -> httpd -> /var/www/html/index.html

The service may be running correctly while the website is still unreachable from another machine if the firewall blocks HTTP. That is why checking only systemctl status httpd is not always enough.

A simple troubleshooting order

When a service does not work, I now check it layer by layer:

1. Is the package installed?

   rpm -q httpd
   

2. Is the service running?

   systemctl status httpd
   

3. What do its logs say?

   journalctl -u httpd --since today
   

4. Is it listening on the expected port?

   ss -ltnp | grep ':80'
   

5. Does it work locally?

   curl http://localhost
   

6. Does the firewall allow the traffic?

   firewall-cmd --list-services
   

This order helps separate a service problem from a network or firewall problem.

5. Flatpak: A Different Way to Install Applications

Normally, RHEL installs software as RPM packages using DNF. These packages are built for the distribution and use libraries available on the operating system.

For example:

dnf install package-name

This approach integrates applications closely with the operating system, but desktop application developers may need to package their software differently for multiple Linux distributions. A distribution's repositories may also intentionally provide an older, well-tested version instead of the newest release.

Flatpak provides another way to distribute and run applications across Linux distributions.

A Flatpak application uses:

• The application itself

• A runtime containing shared libraries needed by multiple applications

• Any additional dependencies that are not already supplied by that runtime

• A sandbox that limits the application's access to the rest of the system

This reduces dependency and compatibility problems, although Flatpak applications can use more disk space because runtimes and additional components must also be installed.

Repository vs remote

Flatpak downloads applications and runtimes from repositories. A configured source pointing to one of these repositories is called a remote.

One well-known remote is Flathub, which hosts Flatpak applications from many publishers. A remote is the source; Flatpak is the tool that communicates with it.

A sandbox improves isolation, but it does not automatically make every application trustworthy. The publisher and requested permissions still matter.

DNF and Flatpak are not replacements for each other

Flatpak does not replace DNF. I would use DNF for components such as httpd, system utilities, libraries, and administrative tools. Flatpak is useful for desktop applications.

On RHEL 10, Flatpak is especially relevant because Flatpaks are the default delivery method for Firefox and Thunderbird.

6. Essential Flatpak Commands

Install Flatpak itself

Flatpak is first installed as a normal RPM package:

dnf install -y flatpak

See configured remotes

flatpak remotes

Add Flathub for the current user

flatpak remote-add --user --if-not-exists flathub \
https://dl.flathub.org/repo/flathub.flatpakrepo

Here:

• --user configures the remote only for the current user.

• --if-not-exists avoids an error if it has already been added.

• flathub is the local name assigned to the remote.

Search for an application

flatpak search firefox

Understand the application ID

Flatpak applications have unique IDs, usually written in reverse-domain style:

org.mozilla.firefox

Using the application ID avoids confusion when applications have similar names.

Install an application

flatpak install --user flathub org.mozilla.firefox

This means: use Flatpak, install for the current user, get the application from the flathub remote, and select the application with the ID org.mozilla.firefox.

List installed Flatpaks

flatpak list

To show only applications and hide runtimes:

flatpak list --app

Run an application

flatpak run org.mozilla.firefox

Desktop environments normally add installed applications to the graphical application menu as well.

Update applications and runtimes

flatpak update

Uninstall an application

flatpak uninstall --user org.mozilla.firefox

User installation vs system installation

A Flatpak can be installed for one user or for the entire system:

# Current user only
flatpak install --user flathub application-id

# System-wide
flatpak install --system flathub application-id

Using --user is often convenient for a personal desktop because it does not affect other users.

What Finally Clicked for Me

The biggest lesson this week was that Linux problems are often made of multiple layers.

Installing httpd gives the system the required program. Starting it creates the running service. Enabling it controls what happens after reboot. The firewall decides whether remote traffic can reach it. Its configuration and content files decide how it behaves and what it serves.

Flatpak follows a different model: it focuses mainly on portable desktop applications, shared runtimes, remotes, and sandboxing. It complements the system package manager instead of replacing it.

Understanding what each layer is responsible for makes the commands much easier to remember—and makes troubleshooting feel far less random.

Quick Command Recap

# Manage services
systemctl enable --now httpd
systemctl status httpd
systemctl restart httpd
systemctl is-active httpd
systemctl is-enabled httpd

# Check logs
journalctl -u httpd --since today

# Allow HTTP through firewalld
firewall-cmd --permanent --add-service=http
firewall-cmd --reload

# Manage Flatpak applications
flatpak remotes
flatpak search application-name
flatpak install --user remote-name application-id
flatpak list --app
flatpak run application-id
flatpak update
flatpak uninstall --user application-id

Detailed Notes on GitHub

• Cloud and DevOps Notes

References

• Red Hat Enterprise Linux 10 — Setting up the Apache HTTP web server

• Red Hat Enterprise Linux 10 — Installing applications by using Flatpak

• Flatpak documentation — Using Flatpak

This post is part of The Logbook, where I document what I learn while building practical Linux, cloud, and DevOps skills.

A two-tier VPC architecture - (Public tier (ALB, internet-facing) + Private tier (EC2, application logic)) across two availability zones:

• Public subnets with NAT Gateways and an Application Load Balancer

• Private subnets with EC2 instances managed by an Auto Scaling Group

• The whole thing isolated inside a custom VPC with layered security

If that sounds like a lot of buzzwords, here's the simple version: I built a network where the servers running the application are hidden from the internet, but users can still reach them through a load balancer. And if one server dies, another one spins up automatically.

The Build: Component by Component

1. VPC and Subnets

I created a custom VPC with a /16 CIDR block. Then I carved it into:

• 2 public subnets (one per AZ)

• 2 private subnets (one per AZ)

What I learned: CIDR block planning matters. If you make your subnets too small, you can't scale later. If you make them too big, you're wasting IP space. I kept it balanced — /24 for each subnet, giving me 251 usable IPs per subnet. More than enough for a learning project, but the exercise of calculating it was valuable.

2. Internet Gateway and NAT Gateways

Attached an Internet Gateway (IGW) to the VPC so the public subnets could reach the internet. Then I created two NAT Gateways — one in each public subnet.

What I learned: Private instances need internet too. They need to download updates, fetch packages, call external APIs. But you don't give them public IPs — that's a security risk. Instead, you route their outbound traffic through a NAT Gateway sitting in the public subnet. The private instances can reach out, but nothing from the internet can reach in.

3. Application Load Balancer (ALB)

Deployed an ALB across both public subnets. This is the single entry point for users. The ALB receives HTTP/HTTPS traffic and forwards it to healthy EC2 instances sitting in the private subnets.

What I learned: The EC2 instances in private subnets have no public IP addresses. You can't SSH into them directly from your laptop. You can't reach them via their IP from a browser. The only way traffic gets in is through the ALB, which is configured to talk to a Target Group containing those instances.

This is the DMZ pattern — the load balancer lives in the danger zone (public internet), while the application servers live in the safe zone (private network).

4. Auto Scaling Group (ASG)

Created a Launch Template defining what each instance should look like (AMI, instance type, security group, key pair). Then attached it to an ASG that maintains a minimum number of instances across both AZs.

What I learned: High availability isn't just having a backup. It's having automated recovery. If an instance fails its health check, the ASG terminates it and launches a replacement. If traffic spikes, the ASG can add more instances. If traffic drops, it removes them.

5. Security Groups (Layered Defense)

• ALB Security Group: Allows ports 80 and 443 from anywhere (0.0.0.0/0)

• EC2 Security Group: Allows traffic only from the ALB's security group. Not from the internet. Not from my IP. Only from the load balancer.

• Bastion Security Group: Allowed SSH (port 22) only from my IP address

What I learned: This is defense in depth. Even if someone somehow discovers the private IP of an EC2 instance, they can't reach it. The security group blocks everything except traffic from the ALB. And the ALB only forwards HTTP/HTTPS traffic. An attacker would need to compromise the ALB first, then the instance.

Validating from My RHEL 10 VM

Here's where my Linux background came in handy. I didn't use PuTTY or some Windows SSH client. I did everything from my Red Hat Enterprise Linux 10 virtual machine running on VMware Workstation — the same environment I use for RHCSA practice.

The workflow:

1. Downloaded the .pem key from AWS

2. Transferred it to my RHEL VM via VMware shared folder (/mnt/hgfs/)

3. Copied it to /root/.ssh/ and set chmod 400 (because shared folders don't preserve Linux permissions)

4. SSH'd into the public bastion instance first

5. From the bastion, SSH'd into the private instances

6. Ran curl http://<alb-dns-name> to verify traffic flow

7. Tested outbound internet from private instances using ping and yum update

The Mistakes (Because That's Where Learning Happens)

Mistake 1: SSH Permission Denied (The .pem File)

I kept getting WARNING: UNPROTECTED PRIVATE KEY FILE! because I was trying to use the .pem directly from /mnt/hgfs/Downloads/ (the VMware shared folder). Shared folders are mounted with Windows permissions, so chmod 400 doesn't actually stick.

Fix: Copy the key to a native Linux directory first (/root/.ssh/), then chmod 400 it there.

Lesson: VMware shared folders are for file transfer, not for running Linux operations that depend on file permissions.

Resources

• GitHub Repo: [Production-Grade AWS VPC Architecture] — Full screenshots, setup notes, and the architecture breakdown

• Local environment: RHEL 10 VM on VMware Workstation

What I'd Do Differently Next Time

1. Use Terraform or CloudFormation. Clicking through the console is fine for learning, but real teams use Infrastructure as Code. I want to be able to terraform apply and recreate this entire architecture in minutes.

2. Add CloudWatch alarms. Right now I have no visibility into CPU, memory, or request latency. I'd add alarms so I know when ASG is actually scaling.

3. Replace the bastion host with AWS Systems Manager Session Manager. SSH through a jump box works, but Session Manager is more secure (no open port 22) and doesn't require managing key pairs.

4. Add a database tier. This is currently two-tier (web + app). A real application needs a database in a private subnet, possibly with RDS Multi-AZ for redundancy.

About This Journey

I'm documenting my learning path here — Linux, AWS, Python, and whatever breaks in between. Not polished tutorials. Just honest notes from someone figuring things out.

Currently studying: RHCSA, AWS core services, Python automation.

The learning itself is actually on fast track — almost done with the full RHCSA course. The past two weeks were all Linux, no AWS. And honestly some of the most interesting concepts so far. Special permissions, access control lists, repository setup — things that look intimidating at first but click really fast once you understand the problem they're solving.

SUID — Set User ID

The Problem It Solves

Normal Linux permissions work like this: when you run a program, it runs with YOUR permissions. If you don't have access to a file, the program you're running doesn't either.

But there's a classic problem with this. Every user needs to be able to change their own password. Passwords are stored in /etc/shadow — a file readable only by root. So how does a regular user run passwd and update their own password if they can't read /etc/shadow?

The answer is SUID.

What SUID Does

When SUID is set on an executable file, that program runs with the permissions of the file's owner — not the person who ran it.

The passwd command is owned by root and has SUID set. So when you run it, it temporarily runs as root, which can access /etc/shadow. Once it finishes, those root privileges go away.

ls -la /usr/bin/passwd
# -rwsr-xr-x. 1 root root ... /usr/bin/passwd
#    ^
#    's' here instead of 'x' = SUID is set

The lowercase s in the owner's execute position means SUID is set AND the file is executable. An uppercase S means SUID is set but the file is NOT executable (which is unusual and usually a mistake).

Setting SUID

chmod u+s filename        # symbolic
chmod 4755 filename       # octal — the 4 at the front = SUID

When You'd Use It

SUID is for executables that need elevated access to do their job but should be available to regular users. Examples already on your system:

ls -la /usr/bin/passwd
ls -la /usr/bin/su
ls -la /usr/bin/ping

All of these need root-level access internally but are meant for regular users to run.

Security note: SUID is powerful and potentially dangerous. Setting it on the wrong binary could let users escalate their privileges. Never set SUID on scripts — only compiled binaries. On the RHCSA exam, finding files with SUID set is a common task:

find / -perm /4000 -type f 2>/dev/null     # find all SUID files

SGID — Set Group ID

SGID works similarly to SUID but for groups, and it behaves differently depending on whether it's set on a file or a directory.

SGID on Files

When SGID is set on an executable, it runs with the permissions of the file's group, regardless of who runs it.

ls -la /usr/bin/write
# -rwxr-sr-x ... tty /usr/bin/write
#        ^
#        's' in group execute position = SGID set

SGID on Directories — More Commonly Used

This is where SGID gets really useful. When SGID is set on a directory, any file created inside that directory automatically inherits the group of the directory, not the primary group of the person who created the file.

Why this matters: In a team environment where multiple people work in the same directory, without SGID, every person's files get assigned to their own personal primary group. Other team members can't access them properly. With SGID on the shared directory, everything created inside belongs to the team's shared group.

mkdir /shared/project
chown :devteam /shared/project       # set group to devteam
chmod g+s /shared/project            # set SGID
# Now any file anyone creates in /shared/project belongs to devteam group

Setting SGID

chmod g+s filename_or_directory       # symbolic
chmod 2755 filename_or_directory      # octal — the 2 at the front = SGID

find / -perm /2000 -type f 2>/dev/null    # find SGID files
find / -perm /2000 -type d 2>/dev/null    # find SGID directories

Sticky Bit

The Problem It Solves

/tmp is a directory everyone can write to. Everyone needs it to create temporary files. But if anyone can write to it, can anyone also delete files in it?

Without sticky bit: yes. Any user could delete any other user's files in /tmp — a serious problem.

Sticky bit fixes this.

What Sticky Bit Does

When sticky bit is set on a directory, only these people can delete files inside it:

• The file's owner

• The directory's owner

• Root

Other users can still read and write files in the directory (if permissions allow), but they cannot delete files they don't own.

ls -la /tmp
# drwxrwxrwt ... tmp
#          ^
#          't' in others execute position = sticky bit set

Lowercase t = sticky bit set AND others have execute permission. Uppercase T = sticky bit set but others don't have execute permission.

Setting Sticky Bit

chmod +t /shared/directory            # symbolic
chmod 1777 /shared/directory          # octal — the 1 at the front = sticky bit

Quick Summary — Special Permissions

# Finding all special permissions at once:
find / -perm /7000 -type f 2>/dev/null

UMASK — Default Permission Mask

What UMASK Is

Every time you create a file or directory, Linux assigns it default permissions. UMASK controls what those defaults are by specifying which permissions to remove from the maximum.

Maximum permissions:

• Files: 666 (rw-rw-rw-) — execute is never given by default for security

• Directories: 777 (rwxrwxrwx) — execute is needed to enter a directory

UMASK subtracts from these. With a umask of 022:

• Files: 666 - 022 = 644 (rw-r--r--)

• Directories: 777 - 022 = 755 (rwxr-xr-x)

Checking and Setting UMASK

umask                    # show current umask value
umask 022                # set umask for current session
umask -S                 # show umask in symbolic form (u=rwx,g=rx,o=rx)

Common UMASK Values

Making UMASK Permanent

Setting umask in the terminal only affects the current session. To make it permanent:

# For a specific user — edit their shell config:
vim ~/.bashrc
# Add at the bottom:
umask 027

# For all users system-wide:
vim /etc/profile
# or
vim /etc/bashrc

UMASK on the RHCSA Exam

Common exam task: "Set the default umask for user john so that new files are created with permissions 640."

# 640 means: rw-r-----
# File max = 666
# 666 - 640 = 026 → umask should be 026

vim /home/john/.bashrc
# Add: umask 026

ACL — Access Control Lists

Why Standard Permissions Aren't Enough

Standard Linux permissions give you three sets: owner, group, others. That's it. You can't say "user alice gets read access, user bob gets read+write, user charlie gets nothing, and the rest of the world gets read only" — there aren't enough slots.

ACLs solve this. They let you attach fine-grained permission rules to any file or directory, giving specific users or specific groups their own permission sets, beyond the standard three.

Checking if ACL is Supported

ACLs work on most modern Linux filesystems (ext4, xfs — which RHEL uses by default). If you see a + at the end of the permissions in ls -l, that file has an ACL set.

ls -la file.txt
# -rw-r--r--+ 1 anousheh devops ... file.txt
#            ^
#            '+' = ACL is set on this file

Viewing ACLs

getfacl filename           # show all ACL entries for a file
getfacl /shared/project    # works on directories too

Output looks like:

# file: filename
# owner: anousheh
# group: devops
user::rw-              # owner permissions (standard)
user:alice:r--         # alice specifically gets read only
user:bob:rw-           # bob specifically gets read+write
group::r--             # group permissions (standard)
mask::rw-              # effective permission ceiling for named entries
other::r--             # others permissions (standard)

Setting ACLs

# Give a specific user permissions:
setfacl -m u:alice:r-- file.txt          # alice gets read only
setfacl -m u:bob:rw- file.txt            # bob gets read+write
setfacl -m u:charlie:--- file.txt        # charlie gets nothing

# Give a specific group permissions:
setfacl -m g:developers:rwx /project     # developers group gets full access

# Set default ACL on a directory (inherited by new files/dirs created inside):
setfacl -m d:u:alice:rw- /shared/        # alice gets rw on everything created in /shared

# Apply ACL recursively to existing files:
setfacl -R -m u:alice:r-- /shared/       # -R = recursive

Removing ACLs

setfacl -x u:alice file.txt      # remove alice's entry specifically
setfacl -x g:developers file.txt # remove developers group entry
setfacl -b file.txt              # remove ALL ACL entries from file

The Mask

The mask in ACL output defines the maximum effective permissions for all named users and groups (not the owner or others). Even if you give alice rwx, if the mask is r--, alice effectively only gets r--.

setfacl -m m:rw- file.txt        # set the mask to rw-

ACL on Directories — Default ACLs

When you set a default ACL on a directory, any new files or subdirectories created inside automatically inherit those ACLs.

setfacl -m d:u:alice:rw- /project     # d: prefix = default ACL
# Now any file created in /project automatically gives alice rw

Without default ACLs, you'd have to setfacl on every new file manually.

The su Command — Switch User

What su Does

su (switch user) lets you switch to another user account from the terminal without logging out. You authenticate as that user and get a shell running as them.

su username              # switch to username
su                       # switch to root (same as su root)
su -                     # switch to root with full login environment
su - username            # switch to username with full login environment

★ The Critical Difference: su vs su -

This is one of the most important things to understand about su and it's tested in interviews.

su username (without dash):

• Switches to that user

• Keeps your current environment — your current directory, your PATH, your environment variables

• You're running as them but in your shell environment, not theirs

su - username (with dash):

• Switches to that user

• Loads their full login environment — their home directory, their PATH, their .bashrc, their variables

• It's as if that user just logged in fresh

Practical difference:

su - root
# You're now in /root, root's PATH includes /sbin, /usr/sbin etc.

su root
# You're still in your previous directory, root's PATH may not be fully loaded
# Commands like fdisk, useradd might not be found because /sbin isn't in PATH

Rule of thumb: Almost always use su - with the dash. You want the full environment of the user you're switching to. Using su without the dash leads to subtle bugs where commands aren't found or configs don't load properly.

su -c — Run a Single Command as Another User

su -c "command" username          # run one command as username, then return
su -c "cat /etc/shadow" root      # run as root, then drop back to current user

Useful when you just need to run one privileged command without fully switching sessions.

Authentication

When switching to another user with su, you need to know that user's password.

Exception: root can su to any user without a password — because root already has unlimited access.

# As regular user: need to know target user's password
su - alice        # prompts for alice's password

# As root: no password needed
su - alice        # switches immediately, no prompt

su vs sudo

su gives you a full shell as another user — you stay in that shell until you exit. sudo runs a single command with elevated permissions and returns immediately. Most modern systems prefer sudo because:

• No need to share root password — each user has their own password

• Logs every command run with sudo

• Can be configured to allow specific commands only

But understanding su is still required for RHCSA.

Exiting

exit               # return to your original user
# or Ctrl+D

Repository Configuration

What Repositories Are

A repository is a structured storage location for packages — either online or local. When you run dnf install httpd, DNF connects to configured repos, finds the package and its dependencies, downloads them, and installs everything.

RHEL has two main repos:

• BaseOS — core OS packages: kernel, glibc, systemd, core utilities

• AppStream — applications, runtimes, databases, web servers

Both need to be configured. Without repos, dnf install has nowhere to look.

★ Configuring a Local ISO Repository

This is a standard RHCSA exam task — the exam machine has no internet access, so you configure the RHEL ISO itself as the package source.

Step 1 — Mount the ISO

In VM settings: attach the RHEL ISO to the CD drive. The system auto-mounts it.

lsblk                          # find where it's mounted — look for sr0
ls /run/media/root/            # confirm ISO contents visible (AppStream and BaseOS)

Step 2 — Create the repo file

cd /etc/yum.repos.d            # all repo files live here
vim rhel-local.repo            # create new file

Step 3 — Write the repo file

[BaseOS]
name=BaseOS
baseurl=file:///run/media/root/RHEL-10-0-BaseOS-x86_64/BaseOS
gpgcheck=0
enabled=1

[AppStream]
name=AppStream
baseurl=file:///run/media/root/RHEL-10-0-BaseOS-x86_64/AppStream
gpgcheck=0
enabled=1

The path after file:/// must match exactly where the ISO is mounted. Use lsblk and ls to find the correct path before writing the file.

Step 4 — Verify

dnf repolist
# BaseOS and AppStream should appear as enabled

dnf install httpd -y
# Should install without errors

Repo File Structure

[repo-id]          # unique ID — what you see in dnf repolist
name=Any Name      # human-readable label
baseurl=...        # where packages are — URL or file path
gpgcheck=0         # 0 = skip signature check, 1 = verify (needs gpgkey)
enabled=1          # 1 = active, 0 = configured but ignored

What's next

LVM, disk partitioning, cron jobs

Full notes on GitHub: https://github.com/anousheh-hussain/cloud-devops-notes

Networking

Overview of Networks

A network is simply a collection of devices connected together to share resources and communicate. Every time you open a browser, send a file, or SSH into a server — that's a network doing its job.

Key terms that come up everywhere:

• Node — any device on a network (PC, server, router, switch)

• Link — the connection between nodes (wired or wireless)

• Bandwidth — how much data can be transferred per second

• Latency — delay between sending and receiving data

• Protocol — agreed-upon rules for how devices communicate

Circuit Switching vs Packet Switching

Circuit Switching — a dedicated path is established before communication begins and held for the entire duration. Traditional telephone networks. The path is reserved even when no data is being sent — consistent but wasteful.

Packet Switching — data is broken into packets, each routed independently, reassembled at the destination. The internet uses this. Efficient because bandwidth is only used when data is actually sent, but packets can arrive out of order.

Reference Models — OSI vs TCP/IP

OSI Model (7 layers):

TCP/IP Model (4 layers):

OSI is theoretical and used for understanding. TCP/IP is what the internet actually runs on.

Network Topology

• Bus — all nodes share one cable. Simple but one failure affects everyone

• Star — all nodes connect to a central switch. Most common in LANs, single point of failure is the center

• Ring — nodes in a circle, data travels in one direction. One break breaks the network

• Mesh — every node connects to every other. Highly reliable, very expensive

• Hybrid — combination, most real networks

Physical Layer

Transmission Media

Guided (wired):

• Twisted Pair — two copper wires twisted together. Cheapest, used in most ethernet

• Coaxial Cable — inner conductor with metal shield. Better noise resistance. Used in cable TV

• Fiber Optic — transmits light pulses. Immune to electromagnetic interference, fastest, longest distances. Expensive

Unguided (wireless):

• Microwave — line-of-sight transmission between towers

• Satellite — high latency due to distance

• Radio Waves — omnidirectional, used in WiFi and mobile networks

• Infrared — very short range, TV remotes

Transmission Modes

• Simplex — one direction only. TV broadcast

• Half Duplex — both directions but not simultaneously. Walkie-talkie

• Full Duplex — both directions simultaneously. Phone call, most network communication

Data Link Layer

Flow Control

Stop and Wait — send one frame, wait for ACK, repeat. Simple but slow.

Sliding Window — send multiple frames before needing an ACK. The window is how many unacknowledged frames can be in flight at once. Much more efficient.

Error Control — ARQ Protocols

Stop and Wait ARQ — send one, wait for ACK. If ACK doesn't arrive, resend.

Go-Back-N ARQ — if one frame is lost, retransmit that frame AND all frames sent after it, even correctly received ones. Simple receiver, wasteful retransmission.

Selective Reject ARQ — only the specific damaged frame is retransmitted. More efficient, but receiver must buffer out-of-order frames.

Error Detection

Parity Check — adds one bit so total 1s are always even or odd. Detects single-bit errors only.

CRC (Cyclic Redundancy Check) — divides data by a polynomial, appends the remainder. Much stronger than parity. Used in Ethernet.

Checksum — sum of all data segments. Simple, used in UDP and IP headers.

Encoding Schemes

• NRZ — high voltage = 1, low voltage = 0. Simple but synchronization problems with long runs

• Manchester — transition in the middle of each bit period. Self-synchronizing, used in Ethernet

• 4B/5B — maps 4-bit data to 5-bit codes to ensure synchronization transitions

Network Layer

IPv4 and IPv6

IPv4 — 32-bit addresses (192.168.1.1). About 4.3 billion unique addresses. We've run out.

IPv6 — 128-bit addresses in hexadecimal. 340 undecillion addresses. Built-in security, no broadcast.

Ethernet and CSMA/CD

CSMA/CD is how early shared Ethernet handled collisions:

1. Listen before transmitting — if busy, wait

2. If free, transmit

3. If collision detected, stop, send jam signal, wait random backoff, retry

Modern switched Ethernet is full duplex — switches eliminate collisions entirely.

Routing

Distance Vector — routers tell neighbors what destinations they know and the cost. Simple, slow to converge. Used by RIP.

Link State — each router broadcasts its link states to the whole network. Everyone builds a complete map, runs Dijkstra's shortest path. Faster convergence. Used by OSPF.

Transport and Application Layers

TCP vs UDP

TCP:

• Connection-oriented — three-way handshake (SYN, SYN-ACK, ACK)

• Reliable, ordered delivery

• Flow and congestion control

• Use for: HTTP, email, file transfer

UDP:

• Connectionless — just sends packets

• No reliability or ordering guarantees

• Much faster, lower overhead

• Use for: DNS, video streaming, gaming

Application Layer Protocols

DNS, Firewalls, Gateways

DNS — translates domain names to IPs through a hierarchy: root servers, TLD servers, authoritative servers.

Firewall — filters traffic based on rules. Stateless checks each packet independently, stateful tracks connection state.

Gateway — connects networks using different protocols. Your home router is a gateway between your LAN and the internet.

Linux Side

Group Management

Groups let you apply permissions to multiple users at once.

groupadd groupname              # create group
groupmod -n newname oldname     # rename group
groupdel groupname              # delete group
gpasswd -a username groupname   # add user to group
gpasswd -d username groupname   # remove user from group
groups username                 # see all groups a user belongs to
cat /etc/group                  # all group info stored here

Every user has one primary group (set at creation) and can have many supplementary groups. Files created by a user get assigned to their primary group by default.

id username    # shows UID, primary GID, all supplementary groups

File Permissions

Every file has three permission sets — owner, group, others.

ls -l filename
# -rwxr-xr-- 1 anousheh devops 1024 Jul 10 script.sh

Breaking down -rwxr-xr--:

• First character: file type (- = file, d = directory, l = symlink)

• Next 3: owner permissions (rwx)

• Next 3: group permissions (r-x)

• Last 3: others permissions (r--)

chmod

Symbolic mode:

chmod u+x file       # add execute for owner
chmod g-w file       # remove write for group
chmod o=r file       # set others to read only
chmod a+r file       # add read for everyone

Octal mode: read = 4, write = 2, execute = 1

chmod 755 file    # rwxr-xr-x  (standard for scripts)
chmod 644 file    # rw-r--r--  (standard for files)
chmod 700 file    # rwx------  (owner only, nothing for anyone else)
chmod 777 file    # rwxrwxrwx  (everyone full access — avoid this)

chown

chown username file              # change owner
chown username:groupname file    # change owner and group
chown :groupname file            # change group only
chown -R username directory/     # change recursively

Only root can change file ownership. A regular user can change a file's group but only to a group they already belong to.

What's next?

Next week will mostly focus on revision alongside a few new AWS topics. After a month of uni exams, I have a lot of ground to cover to get back up to speed.

Full notes on GitHub: https://github.com/anousheh-hussain/cloud-devops-notes
(Will updates the notes soon. Sorry for the delay as I got really busy with exams.)

AWS Side

S3 — Simple Storage Service

S3 is AWS's object storage service. Unlike a file system where you have folders and files, S3 stores objects — any file, any size — inside containers called buckets. A bucket is globally unique, meaning no two AWS accounts anywhere in the world can have a bucket with the same name.

Key things to understand about how S3 works:

• You don't SSH into S3, you don't mount it like a drive — you access it through the AWS console, CLI, or API

• Every object stored in S3 gets a unique URL

• S3 is a regional service — you create a bucket in a specific region, but the bucket name itself has to be unique globally

• Objects can be anywhere from 0 bytes to 5TB. For files larger than 5GB, S3 requires multipart upload

S3 is used for almost everything in AWS — static website hosting, storing application logs, backup and archiving, sharing files between services, storing EC2 AMIs, and more.

S3 Storage Classes

This is where S3 gets interesting. Not all data needs to be accessed the same way — some files you need instantly, others you haven't touched in years. S3 lets you choose different storage classes based on how often you actually need your data, with different pricing accordingly.

S3 Standard Default class. High availability, instant access, replicated across at least 3 AZs. Use this for data you access regularly. Most expensive storage cost but no retrieval fee.

S3 Intelligent-Tiering AWS monitors access patterns and automatically moves objects between frequent and infrequent access tiers. Small monthly monitoring fee per object. Good for data with unpredictable access patterns where you don't want to manually manage tiers.

S3 Standard-IA (Infrequent Access) Cheaper storage than Standard, but you pay a retrieval fee every time you access the data. Minimum storage duration of 30 days. Use for data you need to keep but don't access often — backups, disaster recovery files.

S3 One Zone-IA Same as Standard-IA but stored in only one Availability Zone instead of three. Cheaper, but if that AZ goes down you lose the data. Only use for easily reproducible data.

S3 Glacier Instant Retrieval Archival storage with millisecond retrieval. 90 day minimum storage duration. Much cheaper than Standard, but higher retrieval cost. Good for compliance archives where you might need to pull something quickly but rarely do.

S3 Glacier Flexible Retrieval Slower retrieval — minutes to hours depending on the tier you choose (Expedited, Standard, or Bulk). Even cheaper storage. Used for long-term archiving where waiting a few hours to retrieve is acceptable.

S3 Glacier Deep Archive Cheapest S3 storage class. Retrieval takes 12–48 hours. 180 day minimum storage duration. For data you're legally required to keep but will almost certainly never look at — 7-year compliance archives, that kind of thing.

S3 Bucket Policies

By default, S3 buckets and everything in them are private. Nothing is publicly accessible unless you explicitly allow it. Bucket policies are JSON documents attached to the bucket that define who can do what with the bucket and its contents.

A simple example — making all objects in a bucket publicly readable:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*"
    }
  ]
}

Breaking down the key parts of any bucket policy:

• Effect — Allow or Deny

• Principal — who this applies to. "*" means everyone, or you can specify an IAM user/role ARN

• Action — what operation is being controlled. s3:GetObject is read, s3:PutObject is write, s3:DeleteObject is delete

• Resource — which bucket or objects this policy applies to

Bucket policies apply at the bucket level and affect anyone accessing it, including other AWS accounts. This is different from IAM policies, which are attached to users/roles and apply to whatever AWS resources they interact with. Both can be used together — an IAM policy can allow S3 access AND the bucket policy can allow it, and both need to agree for access to be granted (unless there's an explicit deny, which always wins regardless).

Linux Side

User Management

Linux is a multi-user system — multiple people or services can have accounts on the same machine, each with their own permissions. Managing these accounts properly is a core part of Linux administration and a heavy RHCSA exam topic.

Creating a user:

useradd username                    # create user
useradd -m username                 # create user with home directory
useradd -m -s /bin/bash username    # specify shell
useradd -m -G groupname username    # add to a group at creation time

Modifying an existing user:

usermod -aG groupname username    # add user to additional group
usermod -s /bin/bash username     # change login shell
usermod -l newname oldname        # rename user
usermod -L username               # lock user account
usermod -U username               # unlock user account

The -aG flag is important — the a means append. Without it, usermod -G replaces the user's groups entirely instead of adding to them.

Deleting a user:

userdel username        # delete user, keep home directory
userdel -r username     # delete user and their home directory

Checking user info:

id username             # shows UID, GID, and all groups
cat /etc/passwd         # user account info stored here
whoami                  # current logged-in user

/etc/passwd stores user info — username, UID, GID, home directory, shell. Despite the name, it doesn't store passwords. That's a common misconception. Passwords are in /etc/shadow, which is root-readable only.

Password Management

Setting and changing passwords:

passwd username            # set or change a user's password
passwd                     # change your own password
passwd -l username         # lock account (disable password login)
passwd -u username         # unlock account
passwd -d username         # delete password (passwordless login — dangerous)

Password aging with chage:

Password aging controls when a password expires, when the user gets warned, and how long they have to change it. This is tested in RHCSA.

chage -l username              # list current aging settings for user
chage -M 90 username           # max password age = 90 days
chage -m 7 username            # min days before password can be changed = 7
chage -W 14 username           # warn user 14 days before expiry
chage -E 2025-12-31 username   # account expires on a specific date
chage -d 0 username            # force password change on next login

Where passwords actually live:

cat /etc/shadow    # hashed passwords, root-only readable

Each line in /etc/shadow has 9 fields — username, hashed password, last changed date, minimum age, maximum age, warning period, inactivity period, expiry date, reserved field. The RHCSA exam tests whether you can read and interpret this file.

Important files to know:

/etc/passwd    # user account info (readable by all)
/etc/shadow    # hashed passwords (root only)
/etc/group     # group info
/etc/gshadow   # group passwords (rare but exists)

What's next?

Networking Basics
Linux: Group Management, File Permissions, chmod, chown

Full notes on GitHub: https://github.com/anousheh-hussain/cloud-devops-notes

This week was networking and high availability on the AWS side, and text processing on the Linux side.

AWS Side

Route 53 — DNS

Route 53 is AWS's DNS service. Before getting into Route 53 specifically, had to actually understand DNS properly first — it's the system that translates domain names like amazon.com into IP addresses computers can use. Without it, you'd have to memorize IP addresses for every website you visit.

When you type a domain into your browser, the request goes through several layers — browser cache, OS cache, then out to a Recursive Resolver, which asks a Root server, which points to a TLD nameserver, which finally points to the Authoritative nameserver holding the actual record. That whole chain happens in milliseconds.

The part that actually confused me at first: Route 53 doesn't store your Load Balancer's IP address directly, because that IP can change anytime AWS scales it. Instead, Route 53 uses something called an ALIAS record, which points to the Load Balancer's DNS name instead of a fixed IP, and stays in sync automatically even as the underlying IP changes. A regular CNAME record can't even be used for a root domain like amazon.com — only ALIAS records can, which is one of the reasons Route 53 uses its own record type instead of just relying on standard CNAME.

Also learned about TTL — how long a DNS answer gets cached before being looked up again. Low TTL means changes propagate fast but costs more queries, high TTL means faster lookups but slower propagation if something changes.

Auto Scaling Groups (ASG)

ASG automatically manages how many EC2 instances are running based on traffic. Instead of manually deciding instance count, you define three numbers — minimum, maximum, and desired. ASG keeps the count at desired, scales up toward maximum when load increases, and never drops below minimum.

It uses a Launch Template as the blueprint for every new instance it creates — same AMI, same instance type, same security groups, same startup script, every time. Scaling itself is driven by policies, the most common being Target Tracking — for example "keep average CPU at 50%," and ASG handles the rest.

The part I found genuinely clever: ASG also handles its own healing. If an instance fails a health check, ASG kills it and replaces it automatically, no manual intervention needed.

Target Groups

A Target Group is what an Application Load Balancer actually routes traffic to — it doesn't send traffic to instances directly. The Target Group holds the list of instances and runs health checks against each one. Only instances that pass the health check get traffic. When ASG creates a new instance, it automatically registers it with the Target Group, and deregisters it before terminating, so in-flight requests aren't dropped mid-way.

Bastion Host

A Bastion Host is a small EC2 instance sitting in a public subnet, acting as the single controlled entry point into private infrastructure. Instances in private subnets have no public IP, so they can't be SSH'd into directly from the internet. You SSH into the Bastion first, then from the Bastion into the private instance. The private instance's security group only allows SSH traffic coming from the Bastion's security group — nothing else gets in.

SSH

Spent more time actually understanding SSH itself this week instead of just using it as a black box. It's the protocol used to securely connect to and control a remote machine over an encrypted channel, using a key pair instead of a password.

ssh -i keyfile.pem username@ip-address

Also looked into SSH Agent Forwarding, which keeps your private key only on your local machine even when hopping through a Bastion — the key never actually sits on the Bastion server, which matters a lot if that server is ever compromised.

Linux Side

This week was all about working with file content and text processing — pipes, redirection, filters, search/compress utilities, regex, and the VI editor.

I/O Redirection

Redirection controls where command input comes from and where output goes.

command > file      # redirect output to file, overwrite
command >> file     # redirect output, append instead
command < file      # use file as input
command 2> errors.log   # redirect only error output

Filters in Linux

Filters are commands that take input, transform it in some way, and produce output. Used constantly when combined with pipes.

sort file            # sort lines
uniq file             # remove duplicate lines
wc -l file            # count lines
cut -d',' -f1 file    # extract a column from delimited data

Pipes

A pipe (|) sends the output of one command directly into the input of another, without needing a temporary file in between.

cat access.log | grep "error" | sort | uniq -c

This single line filters a log file down to just error lines, sorts them, and counts unique occurrences — chaining filters together is the actual point of the Linux command line.

Bundle, Find, and Compress Data

tar -cvf archive.tar folder/      # bundle files into one archive
tar -xvf archive.tar              # extract
gzip file                         # compress
gunzip file.gz                    # decompress
find / -name "*.log"              # search for files by name
find / -size +100M                # search by size

Regular Expressions (Regex)

Regex lets you search for patterns in text rather than exact strings. Used heavily with grep.

grep "^error" file        # lines starting with "error"
grep "fail$" file          # lines ending with "fail"
grep "[0-9]\{3\}" file     # three consecutive digits
grep -E "warn|error" file  # match either word

The biggest mental shift here was understanding that regex is a separate pattern language from the file globbing covered in week 2 — * means something completely different in each context, and mixing them up is an easy mistake.

VI Editor

VI (or VIM) is the default text editor on most Linux systems, including RHEL. No mouse, fully keyboard driven, and has two main modes.

i        # enter insert mode (start typing)
Esc      # exit insert mode back to command mode
:wq      # save and quit
:q!      # quit without saving
dd       # delete current line
/word    # search for "word" in the file

It feels unnatural for the first while, but it's unavoidable for RHCSA since GUI editors usually aren't available on the exam environment.

What's next?

In my week 4, I will be covering:

AWS: S3, storage classes, bucket policies
Linux: User Management and Password Management

Full notes on GitHub: https://github.com/anousheh-hussain/cloud-devops-notes

AWS Side

VPC — Virtual Private Cloud

VPC is your own private, isolated network inside AWS. Everything you launch — EC2 instances, databases, anything — lives inside a VPC. Think of it as your own data center, but in the cloud.

When you create an AWS account, a default VPC already exists in every region. You can use it, but for real projects you always create a custom one.

Key components:

• Subnets — divide your VPC into smaller networks. Public subnet = internet accessible, private subnet = internal only

• Internet Gateway — connects your VPC to the internet. Without this, nothing inside your VPC can reach the outside world, no matter how the rest is configured

• Route Tables — rules that decide where network traffic goes. Every subnet is associated with a route table, and this is usually the missing piece when something "should be reachable" but isn't

Security Groups

Security groups are stateful firewalls attached at the instance level. Stateful means if inbound traffic is allowed, the response automatically goes out — no separate outbound rule needed.

Key things:

• Only allow rules exist, no deny rules

• Attached to instances (or other resources), not subnets

• Changes take effect immediately

• Default security group allows all outbound, blocks all inbound

Inbound rule example:

Type: SSH | Protocol: TCP | Port: 22 | Source: My IP

NACLs — Network Access Control Lists

NACLs operate at the subnet level, not the instance level. Unlike security groups, they're stateless — both inbound AND outbound rules need to be explicitly defined.

They also support deny rules, which security groups don't have.

Rule number order matters in NACLs — lower number gets evaluated first, and once a match is found, evaluation stops there.

IP Addressing in AWS

• Private IP — assigned automatically, stays fixed within the VPC even after stop/start

• Public IP — assigned on launch if enabled, but changes every time the instance is stopped and started

• Elastic IP — a static public IP reserved separately and attached to an instance. Doesn't change. Free while attached to a running instance, costs money when idle — so release it when not in use

CIDR notation controls how many IPs are in a subnet. /24 gives 256 addresses, /16 gives 65,536.

Linux Side

Shell Expansion

Shell expansion is what happens before a command actually runs — the shell processes and transforms parts of the command first. Understanding this makes the terminal feel a lot less mysterious.

Control Operators

These control how multiple commands run together:

command1 ; command2      # run both, regardless of outcome
command1 && command2     # run command2 only if command1 succeeds
command1 || command2     # run command2 only if command1 fails
command &                # run command in background

&& shows up constantly in real scripts — install something, then only configure it if the install actually succeeded.

Shell Variables

NAME="Ziya"               # define variable
echo $NAME                # use variable
export NAME               # make it available to child processes
env                       # see all environment variables
unset NAME                # delete variable

Important built-in ones:

• $HOME — your home directory

• $PATH — where the shell looks for commands

• $USER — current username

• $PWD — current directory

Shell Embedding (Command Substitution)

Run a command inside another command — the output gets used inline:

echo "Today is $(date)"
echo "You are logged in as $(whoami)"
FILES=$(ls /etc)       # store command output in a variable

The $() syntax is preferred over the older backtick style — cleaner and nestable.

For Loops

for i in 1 2 3 4 5; 
do
    echo "Number $i"
done

Loop through files:

for file in /etc/*.conf; 
do
    echo "$file"
done

C-style loop:

for ((i=1; i<=5; i++)); 
do
    echo $i
done

Loops matter for automation — creating multiple users, processing files in bulk, anything repetitive.

File Globbing

Globbing is pattern matching for filenames, expanded by the shell before the command runs:

*          matches anything
?          matches exactly one character
[abc]      matches a, b, or c
[a-z]      matches any lowercase letter
[!abc]     matches anything except a, b, or c

Examples:

ls *.txt           # all .txt files
ls file?.log       # file1.log, file2.log etc
ls [Rr]eadme*      # Readme or readme, anything after
rm temp[0-9].log   # temp1.log through temp9.log

What's next?

On my third week, I will be diving deep into:
AWS: Route53, Auto Scaling Group, Target Group, Bastion Host, SSH
Linux: I/O Redirection, Filters in Linux, bundle/find/compress data, Regex, VI Editor

Full notes on GitHub: https://github.com/anousheh-hussain/cloud-devops-notes

AWS Side

IAM — Identity and Access Management

IAM is how AWS controls who can do what inside your account. Every action — launching an EC2, reading S3, creating a user — goes through IAM first.

Things that actually clicked this week:

• Never use the root account for daily work. Create an IAM admin user and use that instead. Root is only for billing and account-level stuff

• Attach policies to groups, not individual users. Much easier to manage when you scale

• Least privilege — give only the permissions actually needed, nothing extra

• Explicit deny always wins. If one policy allows S3 access and another explicitly denies it, the deny wins every time. No exceptions

EC2 — Elastic Compute Cloud

EC2 is basically a virtual machine running in AWS. You pick the OS, instance type, storage, and networking — it's running in minutes.

What I focused on:

• Instance types — t2.micro is free tier, but there are different families optimized for compute, memory, or storage depending on the workload

• Key pairs — SSH access to your instance. You get one chance to download the private key when creating it. Lose it and you're locked out

• Security groups — act as a virtual firewall. Control what traffic can come in and go out of your instance

• Stopping vs terminating — stopping is like shutting down a PC, terminating deletes the instance completely

Linux Side

What even is Linux

Linux is an open source operating system kernel. The distributions (Ubuntu, RHEL, CentOS, Fedora) are built on top of it. For RHCSA specifically, everything is RHEL-based.

Firmware and Low-Level Software

Before the OS even loads, firmware (BIOS or UEFI) runs first. It initializes hardware and hands control to the bootloader, which then loads Linux. Not something you touch daily but important to understand the boot chain.

Run-levels and Targets

Older Linux used run-levels. Modern Linux uses systemd targets:

• multi-user.target — command line, no GUI (what servers use)

• graphical.target — desktop environment

• rescue.target — minimal mode for recovery

bash

systemctl get-default    # check current target

Linux File System Structure

Everything in Linux starts from / (root). Key directories worth knowing:

• /etc — configuration files

• /var — logs and variable data

• /home — user home directories

• /bin and /usr/bin — essential commands

• /tmp — temporary files, cleared on reboot

• /root — home directory for the root user specifically

SSH Setup

SSH lets you securely connect to a remote Linux machine:

bash

ssh -i keyfile.pem username@ip-address

For RHCSA, /etc/ssh/sshd_config controls server behavior — changing default port, disabling root login, key-based vs password auth are all exam-relevant.

DOS vs Linux Terminal

Working with Directories

bash

pwd             # where am I
ls -la          # list all including hidden files
mkdir name      # create directory
mkdir -p a/b/c  # create nested directories in one go
rm -rf name     # remove directory and everything in it

File Creation and Manipulation

bash

touch filename    # create empty file
cp file1 file2    # copy
mv file1 file2    # move or rename
rm filename       # delete

File Content Manipulation

bash

cat file          # print file content
head -n 5 file    # first 5 lines
tail -n 5 file    # last 5 lines
grep "word" file  # search for word inside file

grep is something you'll use constantly. Worth spending extra time on it.

Getting Help and Man Pages

bash

man ls       # full manual
ls --help    # quick summary
whatis ls    # one line description

Man pages are allowed in the RHCSA exam. Get comfortable using them now.

Inodes, Hard Links and Soft Links

An inode stores file metadata — permissions, owner, size, timestamps. Every file has one.

A hard link points to the same inode. Delete the original — the hard link still works.

A soft link (symlink) points to the filename. Delete the original — the symlink breaks.

bash

ln file hardlink       # hard link
ln -s file softlink    # soft link
ls -li                 # see inode numbers

What's next?
That’s a wrap on Week 1!
Next week, I’ll be diving into:
AWS: VPC, Security Groups, NACLs, IP Addressing
Linux: Shell Expansion(Shell Embedding, File Globbing, etc)

Full notes on GitHub: https://github.com/anousheh-hussain/cloud-devops-notes