DEV Community: Yvonne

How to Change Directory Permissions in Linux (and Why It Matters)

Yvonne — Tue, 17 Feb 2026 01:33:00 +0000

One of the most common tasks in Linux administration is changing directory permissions. You may need to secure sensitive data or set up a shared workspace for your team. Understanding Linux permissions is crucial to managing files and directories.

Here’s a walkthrough showing how to share a folder with your team by assigning it to the devteam group and applying the correct permissions. This example assumes the devteam group already exists.

(I’ll cover how to create a group and add members in an upcoming post.)

Index

Check the current permissions
Assign the directory to the team group
Give the owner and group full access
Confirm the setup
Summary

1. Check the current permissions

Before changing anything, check the directory permissions:
ls -ld sharedfiles - Where the directory name is "sharedfiles"

You'll see:

This tells you:

Owner: read, write, execute (rwx)
Group: read, execute (r-x)
Others: read, execute (r-x)

2. Assign the directory to the team group

chgrp devteam sharedfiles

3. Give the owner and group full access

chmod 770 sharedfiles

770 is a permission setting that gives full access to the owner and the group, and no access to anyone else.

7 (owner) → read, write, execute

7 (group) → read, write, execute

0 (others) → no permissions at all

4. Confirm the changes

ls -ld sharedfiles

Now:

You (the owner) can read/write/execute
Your team (devteam) can read/write/execute
No one else can access the folder

5. Summary

This is how shared project directories, departmental folders, and collaboration workspaces are secured in production environments. There are other ways to do this on a more granular level using ACL permissions, and I'll leave that for another post.

Use Case: Imagine you’re supporting a development team that needs a shared directory where everyone can collaborate, but you don’t want other users on the system to access or modify the files.

Connect with me on LinkedIn to comment or share your experiences with Linux.

#RedHatEnterpriseLinux
#CloudWhistler #CloudEngineer #Linux
#DevOps #RedHat #OpenSource
#CloudComputing #WomenInTech

Tighten Security on EC2 Instances: Fast and Simple

Yvonne — Tue, 15 Apr 2025 07:08:23 +0000

When you're managing EC2 instances across your infrastructure, it's easy to get caught up in launching, tagging, and tweaking, but security should always be on your mind. A single open port or misconfigured rule can be all it takes for trouble to find you.

The good news is that you don’t need to be a security expert to take a few quick steps that make your EC2 environment safer. Today, I’ll show you three simple AWS CLI commands you can run to help lock things down fast.

Index

List All Open Security Group Ports
Restrict SSH Access to a Specific IP
Enable Detailed Monitoring for EC2 Instances
Business Use Case
Summary

1. List All Open Security Group Ports

Command:

aws ec2 describe-security-groups \ --query "SecurityGroups[*].{Name:GroupName,ID:GroupId,Inbound:IpPermissions}" \ --output table

Note: the --output options for this command are text, table or yaml. For scripting or automation, you can use json or text

Running this command gives you an output of tables of the security groups that helps you spot overly open rules (like 0.0.0.0/0 on port 22).

Why this matters: You can quickly review inbound rule across all groups without accessing the AWS Management Console.

2. Restrict SSH Access to a Specific IP

Change the SSH (port 22) rule to allow access only from your IP, not the whole world.

When you run the two commands, you change the IP address from "any IP address" to "your IP address". That means that incoming traffic comes from your IP address only, and not all outside traffic.

Command:

aws ec2 revoke-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp --port 22 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp --port 22 --cidr YOUR.IP.ADDRESS.0/32

Note:

0.0.0.0/0 means allow access from anywhere on the internet. This tells AWS that any IP address in the world can reach this port on this server.
It's okay to use 0.0.0.0/0 for public-facing services like: Web servers (port 80/443) or APIs meant to be public.

Why this matters: This locks down SSH access to our machine only.

3. Enable Detailed Monitoring for EC2 Instances

Enable CloudWatch detailed monitoring on an instance so you can detect unusual spikes in activity.
Command:
aws ec2 monitor-instances --instance-ids i-0123456789abcdef0

After running the command monitoring confirmed enabled.

Why this matters: Helps detect brute-force login attempts, CPU spikes, or suspicious behavior faster.

4. Business Use Case

Security is a critical part of running stable, reliable cloud infrastructure. For teams running production workloads, even one exposed instance can lead to service disruptions, compliance issues, or worse.

Using CLI commands to audit and lock down EC2 instances gives you a fast and scalable way to apply security best practices across environments without relying entirely on the management console.

5. Summary

Security doesn’t have to be complicated, and even a few small changes can make a big impact. Using the AWS CLI to manage security on EC2 instances lets you work faster, especially when you need to apply changes across multiple instances or environments.

These three commands are a great starting point, but there is a long security checklist your company has to manage security over the entire infrastructure. You should be in the habit of reviewing your EC2 settings, secure what you can, always keep and eye on your cloud.

Connect with me on LinkedIn to comment or share your experiences with using the AWS CLI.

#30DaysLinuxChallenge #RedHatEnterpriseLinux
#CloudWhistler #CloudEngineer #Linux
#DevOps #RedHat #OpenSource
#CloudComputing #WomenInTech

Bash Script to Back Up and EC2 Instance

Yvonne — Mon, 14 Apr 2025 19:31:46 +0000

When you're managing EC2 instances in AWS, backups aren't optional, but a critical part of managing your cloud infrastructure. If you’re updating a server, applying patches, or making big configuration changes, having a fresh backup could save you from hours of troubleshooting if something goes wrong.

Today, I’m going to walk you through a simple Bash script that uses the AWS CLI to create a backup of your EC2 instance without logging into the AWS Management Console. Whether you're managing one server or scaling up to dozens, this simple script can save you a lot of time and headaches down the road.

Index

What This Script Does
How to Run the EC2 Backup Script

Open Your Terminal
Create a New Script File
Copy and Paste the Script into the File
Save and Exit the File
Make the Script Executable
Run the Script
Business Use Case
Summary

What This Script Does:

Sets variables - Defines your instance ID and region
Generates a backup name - Creates a timestamped name like Backup-2025-04-14-10-45-30
Creates an AMI - Calls aws ec2 create-image command using the AWS CLI
Set --no-reboot flag - Creates an AMI without rebooting the instance
Creates a Success message - Prints confirmation message at the end

Important Notes:
This is a very simple script to demonstrate the possibilities of using bash scripting for backups, so it doesn't do everything:

✅ --no-reboot: Skips rebooting the instance for faster backup.
If you want a more consistent backup, remove --no-reboot.

✅ This only backs up the instance and its root volume.
If you have additional EBS volumes attached, you’ll want to create snapshots for those too and that's a separate script.

✅ The script doesn't automatically clean up old backups. You can later write another script to delete old AMIs if you want.

How to Run the EC2 Backup Script

Checklist Before Running the Script:

Make sure AWS CLI is installed - Check the version by running aws --version
Configure AWS CLI - Configure it by running aws configure (set the access key, secret access key, and region)
Make sure your AWS CLI region matches your EC2 instance region

1. Open Your Terminal

If you're on Linux or Mac ➔ open Terminal.

If you're on Windows ➔ open PowerShell, Command Prompt, or Git Bash (recommended).

2. Create a New Script File

Create a .sh Bash script file where you want it.
Command: nano backup-ec2.sh

✅ This opens a new empty file for editing.

3. Copy and Paste the Script Into the File

Paste this content:

#!/bin/bash

# Check if an instance ID was provided
if [ -z "$1" ]; then
  echo "Usage: $0 <instance-id>"
  exit 1
fi

# Set your variables
INSTANCE_ID="$1"                  # Get the instance ID from the first argument
REGION="us-east-1"                 # <-- Replace with your AWS Region
BACKUP_NAME="Backup-$(date +%F-%H-%M-%S)"   # Backup name with timestamp

# Create the AMI
aws ec2 create-image \
  --instance-id $INSTANCE_ID \
  --name "$BACKUP_NAME" \
  --no-reboot \
  --region $REGION

# Output success message
echo "Backup started for Instance ID $INSTANCE_ID with AMI name $BACKUP_NAME"

✅ Make sure you replace: REGION with your correct AWS region (like us-west-2, us-east-1)

4. Save and Exit the File

If using vim: Press Esc, type :wq, and press Enter.

5. Make the Script Executable

You need to give permission to run the script

Command:
chmod +x backup-ec2.sh

Linux Note:

When the script file, backup-ec2.sh was created, it was not an executable file shown listed as -rw-rw-r--.
After running the command, chmod +x backup-ec2.sh, the script is now executable indicated by -rwxrwxr-x and the script file is highlighted in green to show that it has execute permissions (x) set for the owner, group and others.

✅ Now the script can be executed.

6. Run the Script and Pass the Instance ID

Now just run it!
Command:
./backup-ec2.sh i-00cb2dd8e85b84fe7

Two things about this script:

The $1 on the line INSTANCE_ID="$1" allows you to pass the EC2 instance ID as an argument when you run the script so you don't have to add the instance ID to the script
Will generate an Imageid number
If you don't give an instance ID when running script, it will display a helpful message reminding you the instance ID is missing.

✅ The script will:

Call AWS CLI to run the Linux command aws ec2 create-image.
Create an AMI backup of your EC2 instance.
Print a success message:

Backup started **for **Instance ID **i-00cb2dd8e85b84fe7** **with **AMI name **Backup**-2025-04-14-19-23-57

if you want to find out which AMI image ID an EC2 instance is using the AWS CLI, here's the command.

aws ec2 describe-instances \
--instance-ids i-0123456789abcdef0 \
--query "Reservations[*].Instances[*].ImageId" \
--output text

✅ Replace the instance-ids with your actual EC2 Instance ID.

Explanation:
describe-instances - Get all information about the EC2 instance
--instance-ids - Specify which instance you are checking
--query- Pull only the ImageId field
--output text Display it in text

Finally, you can also verify the AMI was created by signing on to the AWS Management Console and verify the AMI image was created.
In the Management console, go to EC2 **and under **Images, select AMIs.

7. Business Use Case

If you have an EC2 instance with Amazon Linux, Apache, custom applications and configurations when you create an Amazon Machine Image (AMI) all of that is captured. Later, you can launch new servers identical to that setup anywhere in the AWS cloud infrastructure. Most importantly, having an up-to-date Amazon Machine Images (AMIs) ensures you can quickly recover if something goes wrong.

8. Summary

There are more complex scripts you can write for backing up resources, but I just wanted to illustrate the power of scripting using Linux commands. Automation is the name of the game, and cloud engineers are always looking for clean, fast and efficient ways automate to maintain consistency, minimize downtime risks, and streamline their disaster recovery processes.

Connect with me on LinkedIn to comment or share your experiences with using the AWS CLI.

#30DaysLinuxChallenge #RedHatEnterpriseLinux
#CloudWhistler #CloudEngineer #Linux
#DevOps #RedHat #OpenSource
#CloudComputing #WomenInTech

Add or Update a Tag on an EC2 Instance Using AWS CLI

Yvonne — Mon, 14 Apr 2025 03:13:15 +0000

When you're managing AWS resources like EC2 instances, keeping things organized is key especially as your environment grows. One of the easiest and most effective ways to stay organized is by using tags. Tags let you add key-value pairs to your resources, making it easier to track, sort, and manage everything.

Today, I’ll show you how to quickly add or update a tag on an EC2 instance using a simple AWS CLI command. It's quick and a habit that will make your cloud life a lot easier down the road.

1. Add or Update a Tag on an EC2 Instance
2. Business Use Case
3. Summary

1. Add or Update a Tag on an EC2 Instance

This command adds or updates a tag on an EC2 instance using AWS CLI.

Command:
aws ec2 create-tags\
--resources i-0123456789abcdef0 \
--tags Key=Environment,Value=Production \
--region us-east-1

Just replace the instance ID and region with your own.

Explanation:
aws ec2 create-tags - Main AWS CLI command to add or update tags
--resources - Specifies the EC2 instance (or multiple instances) you want to tag
--tags - Defines the key and value for the tag
--region - sets which AWS region you're working in

✅ If the tag already exists, this command updates it to the new value.
✅ If the tag doesn't exist, it creates it.

2. Business Use Case

By tagging EC2 instances with keys like Environment=Production or Owner=DevTeam, companies can easily generate cost reports, enforce automation scripts, or quickly identify critical systems during incidents. Without proper tagging, cloud environments can quickly become chaotic and expensive.

3. Summary

In real-world cloud environments, tagging resources isn’t just a nice-to-have; it's a best practice. Tags help teams track costs, manage environments, enforce security policies, and even automate processes across hundreds or thousands of resources. Tagging may seem like a small detail, but it really adds up once you're managing dozens or hundreds of AWS resources.

Connect with me on LinkedIn to comment or share your experiences with Linux.

#30DaysLinuxChallenge #RedHatEnterpriseLinux
#CloudWhistler #CloudEngineer #Linux
#DevOps #RedHat #OpenSource
#CloudComputing #WomenInTech

Automate Your EC2 Setup Using AWS CLI and User Data

Yvonne — Mon, 14 Apr 2025 00:49:03 +0000

When I first dove into AWS services, spinning up an EC2 instance server felt like an accomplishment in itself. But the real thrill? Watching that server configure itself automatically with no manual tinkering required. That’s when working with EC2 instances truly starts to feel like magic.

In this article, we’ll build a basic Apache web server on an EC2 instance using AWS CLI and a simple Bash script. We’ll even verify that the webpage is live!

Index

1. What You Will Build
2. Tools You will Need
3. User Data Script
4. Launching the Instance with User Data
5. Quick Steps to Follow
6. A Few Pro Tips
7. Business Use Case
8. Summary

1. What You Will Build

We’ll launch an EC2 instance that:
Automatically installs an Apache webserver (httpd).
Starts the Apache service.
Creates a basic webpage (index.html).

This leaves the server ready for you to visit the public IP address and see the site live!

2. Tools You Will Need

AWS CLI installed and configured (sudo yum install aws-cli -y and aws configure)
An existing AWS Key Pair (for SSH, if needed)
A Security Group that allows port 22 (SSH) and port 80 (HTTP) inbound

3. User Data Script

Here's the basic script we'll use:

#!/bin/bash

yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Welcome to the World of Cloud Engineers!</h1>" > /var/www/html/index.html

This Bash script:

Updates packages
Installs the Apache web server
Starts and enables the web server
Creates a basic HTML homepage

4. Launching the Instance with User Data

Here's the AWS CLI Command:
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--count 1 \
--instance-type t2.micro \
--key-name MyKeyPair \
--security-group-ids sg-0123456789abcdef0 \
--subnet-id subnet-0123456789abcdef0 \
--associate-public-ip-address \
--user-data file://setup-apache.sh

✅ Notice the important part:

--user-data file://setup-apache.sh

setup-apache.sh is a local file containing the script above.
The file:// prefix tells AWS CLI to read the file and send it as base65-encoded user data.
You use the --associate-public-ip-address to request that AWS automatically assigns a public IP address to your new EC2 instance when you launch it into a subnet that does not automatically assign public IPs by default.

Note: You don't "get" the --associate-public-ip-address option from AWS; it's a flag you add manually into your CLI command when needed.

5. Quick Steps to Follow

5.1 - Create your script file:
Command:
nano setup-apache.sh

Paste the bash script above into the file and save it.

5.2 - Make sure the file is saved in the same directory where you run your AWS CLI command.
5.3 Run the aws ec2 run-instances command with --user-data.

5.4 Wait for the instance to launch and initialize.

5.5 Get the public IP:
Command:
aws ec2 describe-instances --query 'Reservations[*].Instances[*].PublicIpAddress' --output text

5.6 Open your browser and visit:
http://<your-instance-public-ip>

✅ You should see: "Welcome to the World of Cloud Engineers!"

6. A Few Pro Tips

Keep your user data scripts simple especially if you’re just starting out.
User data script only runs once the very first time the instance boots.
If testing fails, check the instance's /var/log/cloud-init-output.log to debug.
Make sure your security group allows HTTP traffic (port 80) or you won't see the webpage!

7. Business Use Case

Instead of logging into the server every time to set things up manually, you can preload a script that runs the moment the instance boots for the first time. This saves time, reduces mistakes, and it falls in line with automation in the cloud.

8. Summary

Using the AWS CLI and User Data field lets you automate an EC2 instance server setup without even logging into the instance.
It’s a key feature to use for cloud engineers, DevOps, and anyone looking to build real-world cloud deployments.

The Next time you launch an instance, give it a little brainpower using the User Data field, and save yourself a ton of setup time!

Connect with me on LinkedIn to comment or share your experiences with using the AWS CLI.

#30DaysLinuxChallenge #RedHatEnterpriseLinux
#CloudWhistler #CloudEngineer #Linux
#DevOps #RedHat #OpenSource
#CloudComputing #WomenInTech

AWS Documentation: Your Essential Reference for Linux Command Lines

Yvonne — Sun, 13 Apr 2025 07:10:26 +0000

If you've ever tried to track down the exact syntax for an AWS CLI command and felt stuck, you're definitely not alone. The AWS Documentation website is an invaluable resource for navigating the complexity of AWS. In this article, I'll demonstrate how to use it effectively with a real-life example: starting an EC2 instance using the AWS CLI.

1. A Goldmine of Resources
2. How to Quickly Find What You Need
3. Why AWS Documentation Matters
4. Summary

1. A Goldmine of Resources

Not only will you find a full command library for working with AWS services, but you’ll also discover step-by-step instructions for building real-world projects. Want to host a WordPress blog on Amazon EC2? No problem, you'll find full instructions, sample commands, and best practices are right there.

The AWS Documentation site has so much more:

AWS service guides
Whitepapers
Best practice playbooks
Sample code
User guides
CLI references

It’s seriously a wealth of knowledge that many people overlook.

2. How to Quickly Find What You Need

Here's a quick tip I use all the time: Let’s say you need to start an EC2 instance but can’t recall the command syntax.

a. Just jump to your browser and type aws cli reference. The first hit in your browser you see is AWS CLI Command Reference.

b. On that page, scroll down to the Available Services section.
You'll see a huge list of all of the AWS Services.

c. Pick your service:
Since there are so many services on a page like this, no need to scroll endlessly. Just press CTRL + F and search for what you need. For example, in the search box at the top of the page, type ec2 to jump right to the EC2 Instance service.

d. Click on the EC2 and then scroll to the Available Commands section.

e. Press CTRL + F and search for what you need. For example, type start or stop to jump right to the instance management commands.

f. Click on the command link start-instances and on that page, scroll down to the Examples section to a sample command.
Here you will find the syntax for starting an instance:
Command:

Terminal Output:

Explanation and Use Case:

The command aws ec2 start-instances initiates a stopped EC2 instance using its unique instance-id. The output confirms the transition of the instance's state from stopped to pending. This ability is crucial for managing resources efficiently, especially in scenarios where cost-saving measures demand stopping instances during off-peak hours and restarting them as needed.

3. Why AWS Documentation Matters

AWS Documentation is more than just a reference; it’s a lifesaver. For commands to manage your AWS Service, the website provides:

Command Syntax: Clear examples like the one above.
Detailed Descriptions: Understand not just the "how" but also the "why."
Use Cases: Learn practical applications to solve real-world problems.

By leveraging this resource, you can simplify workflows, minimize errors, and enhance your productivity.

4. Summary

While today I’m focusing on Linux commands, this is only a small piece of what’s available on the AWS Documentation website. There’s a massive library of content for just about anything you want to do in AWS.

Here’s the link: 👉 AWS Documentation

I visit it all the time. Bookmark it, add it to your resources list, and start using it. It’s one of the best ways to level up your AWS and Linux skills without getting overwhelmed.

Connect with me on LinkedIn to comment or share your experiences with Linux.

#30DaysLinuxChallenge #RedHatEnterpriseLinux
#CloudWhistler #CloudEngineer #Linux
#DevOps #RedHat #OpenSource
#CloudComputing #WomenInTech

Managing EC2 Instances with the AWS CLI

Yvonne — Sat, 12 Apr 2025 01:57:31 +0000

As a Cloud or DevOps engineer, proficiency and automation are key to managing a cloud infrastructure. While the AWS Management Console is visually appealing and user-friendly, if there is a high workload it may get cumbersome managing dozens or more of instances. The AWS CLI is a great tool for managing AWS Services directly from the command line.

In this article, I’ll walk you through how to manage EC2 instances using the AWS CLI. We’ll cover commands to launch, list, and terminate instances, explain their syntax, and discuss why CLI management is a valuable for your workflow.

Index

Why use the AWS CLI Instead of the Management Console?

1. Set Up AWS CLI on Amazon Linux
2. Launch and EC2 Instance
3. List All EC2 Instances
4. Delete or Terminate an EC2 Instance
5. Business Use Case: CLI Over Console
6. Summary

Why use the AWS CLI Instead of the Management Console?

While the AWS Management Console is great for small workloads, as the cloud environment scales, using AWS CLI has significant advantages:

Efficiency: Perform complex actions in seconds, without navigating through multiple console screens.
Automation: Easily integrate CLI commands into scripts for tasks that need to be repeated.
Scalability: Manage multiple resources at once, like starting or stopping dozens of instances with a single command.
Flexibility: Access AWS from anywhere with a terminal, and there is no need to rely on a web interface.

1. Set Up AWS CLI on Amazon Linux

Before diving into the EC2 commands, ensure that AWS CLI is installed and configured on your Amazon Linux machine.

Install AWS CLI
Amazon Linux generally comes with AWS CLI pre-installed. If not, you can install it:

Configure AWS CLI
After installation, configure your AWS credentials:

You'll need to provide:

AWS Access Key ID
AWS Secret Access Key
Default region (e.g., use-east-1)
Output format (none)

2. Launch an EC2 Instance

Start off by launching a new EC2 instance
Command:
aws ec2 run-instances --image-id ami-00c1e19c6845d02f0 --count 1 --instance-type t2.micro --key-name us-east-kp6 --security-group-ids sg-00df97ec3b4d8bc5f --subnet-id subnet-0386d618164fbad2f --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=WebServer1}]'

For this command, you will need the AMI image id, key pair, security group id and the subnet id. You can get these from an existing EC2 instance or you can run these commands in the AWS CLI:

aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm-*" --query "Images[*].[ImageId,Name]" --output table
aws ec2 describe-security-groups --query "SecurityGroups[*].[GroupId,GroupName]" --output table
aws ec2 describe-subnets --query "Subnets[*][SubnetId,AvailabilityZone]" --output table

Explanation:
--image-id: The AMI ID to use for the instance. Replace AMI ID with your desired AMI.
--count: The number of instances to launch (set to 1 for a single instance).
--instance-type: The instance type (e.g., t2.micro for general-purpose usage).
--key-name: The name of your key pair for SSH access.
--security-group-ids: The security group(s) to associate with the instance.
--subnet-id: The subnet where the instance will be launched.
--tag-specifications: Assign tags to the instance (e.g., Name=MyInstance).

Assigning tags to instances is important because if you are working with multiple servers, tagging makes it easy to search for an instance.

Use Case:
You’re provisioning a new web server or application instance and need it up and running quickly. This command handles everything from specifying the AMI to tagging the instance for easy identification.

3. List All EC2 Instances

After launching instances, you can review what's running on your account using the command below:
Command:
aws ec2 describe-instances --query "Reservations[*].Instances[*].[InstanceId,State.Name,Tags[?Key=='Name'].Value|[0]]" --output table

Explanation:
--describe-instances: Retrieves details of all EC2 instances.
--query: Filters and formats the output to show Instance ID, state, and name tag.
--output: Specifies the format for output (table is used here for readability)

Use Case:
This command gives you a summary of all your instances, and also to check their status.

4. Delete or Terminate an EC2 Instance

When an instance is no longer needed, terminate it to save costs.

Command:
aws ec2 terminate-instances --instance-ids i-0123456789abcdef0

Explanation:
--terminate-instances: Permanently deletes the specified instance(s).
--instance-ids: The ID of the instance you want to terminate. Replace instance ID in the command with the actual instance ID.

Use Case:
You’ve created a temporary testing environment and now need to clean it up. Terminating instances ensures you’re not billed unnecessarily.

5. Business Use Case: CLI Over Console

Here's why DevOps engineers love the AWS CLI for managing EC2 instances:

Faster Provisioning: Scripts can be used to launch multiple instances at once, saving hours compared to the manual console process.
Automation: Integrate CLI commands into CI/CD pipelines for automated deployments.
Cost Optimization: Quickly identify and terminate idle or underutilized instances, helping businesses save on AWS costs.
Consistency: Scripts ensure repeatable, error-free infrastructure deployment.

Imagine a scenario where your team needs to deploy a testing environment with 10 instances. A script can be written that launches them in seconds. Another script terminates them when done, saving time, reducing errors, and simplifying the workflow of the DevOps engineer.

6. Summary

Managing EC2 instances via the AWS CLI is a must-have skill for DevOps engineers. Not only does it streamline repetitive tasks, but it also opens the door to powerful automation. With commands like run-instances, describe-instances, and terminate-instances, you can manage your infrastructure more effectively while minimizing costs and errors.

Connect with me on LinkedIn to comment or share your experiences with using the AWS CLI.

#30DaysLinuxChallenge #RedHatEnterpriseLinux
#CloudWhistler #CloudEngineer #Linux
#DevOps #RedHat #OpenSource
#CloudComputing #WomenInTech

Systemctl Basics: Managing Your Linux Services

Yvonne — Thu, 10 Apr 2025 22:46:45 +0000

Ever found yourself staring at your Linux terminal, wondering how to restart a service and make sense of those systemctl commands? Whether it’s fixing a monitoring a system, troubleshooting, or just poking around your system, getting the hang of systemctl is puts you in control of managing Linux services with ease.

Systemctl is a command-line tool used in Linux to control and manage the systemd service manager. Think of systemctl as a way to start, stop, restart, enable/disable, and check the status of services like, web servers, databases, networking, etc on a Linux machine. Go to the Linux man pages, man systemctl to see all of the commands and options available.

Index

Common Systemctl Commands to Know

Check the Status of a Service
Start or Stop a Service
Enable or Disable a Service at Boot
Restart a Service
Advance Systemctl Tips
Summary

Common Systemctl Commands to Know

The most commonly used systemctl commands by network engineers are to start, stop, restart and monitor Linux services. Run go to the Linux man pages, by running man systemctl to see all of the options.

Check the Status of a Service

This command checks the status of a service.

Command: - systemctl status httpd

Use Case: - When a service is not running or you are troubleshooting, the status command is the first command you run to check a service.

Start or Stop a Service

This command starts a service.

Command: - systemctl start httpd

Use Case: - If a service abruptly starts, you can quickly start the service.

Enable or Disable a Service at Boot

This command enables a service. When a service is enabled, it automatically starts when a server is rebooted.

Command: - systemctl enable sshd

Use Case: - By enabling the sshd service, it allows you to remotely connect to your server over a network or remote terminal access.

Restart a Service

This command restarts a service that is already running.

Command: - systemctl restart httpd

Use Case: - Restarting a service is different that starting a service. When you make configuration changes to a service such as NGNIX or Apache, it has to be restarted for the changes to take effect.

Advance Systemctl Tips

View a specific service that is running.

Command: - `systemctl --type=service --state=running | grep "httpd"

Use Case: There are many services running and you want to quickly search for a specific service. This saves you time when troubleshooting.

Check for only service unit files and exclude other unit files. This command shows you which services will start at boot and you can spot disabled services you may want to enable.

Command: - systemctl list-unit-files --type=services

Use Case: A fast way to check for only "service unit files" as oppose to all unit files when you are only interested in the Linux services. Quick filtering speeds up troubleshooting.

Checked for failed services. This is a good command for troubleshooting to check if services are not running.

Command: - systemctl --type-service --state--failed

Summary

For network engineers, the systemctlcommand and important command for monitoring and keeping critical services up and running. You can start, stop or restart these services in seconds, making troubleshooting and maintenance less stressful. Plus, it lets you automate service startups after a reboot, saving you the problem of downtime. For anyone managing a network infrastructure, mastering this command is all about having control and staying ahead of the game.

Connect with me on LinkedIn to comment or share your experiences with Linux.

#30DaysLinuxChallenge #RedHatEnterpriseLinux
#CloudWhistler #CloudEngineer #Linux
#DevOps #RedHat #OpenSource
#CloudComputing #WomenInTech

Linux Search Commands: Essential Tools for Incidence Response

Yvonne — Thu, 10 Apr 2025 09:40:40 +0000

Imagine this: a server in your production environment has been breached, and the security team suspects malware or rogue files have been installed. Speed is crucial. As an engineer, your ability to run detailed and precise Linux searches can make a world of difference in identifying, isolating, and removing the threat.

Incident response involves a lot of steps, but in this article, I’ll focus on the critical role Linux searches play. I’ll walk you through some essential search commands that can help uncover suspicious files like newly created executables, recently modified files, and those with unusual extensions. Plus, I’ll share a bonus tip for generating a CSV report of your search results.

Index

Why Mastering Linux Searches Matters
Key Searches to Run During a Breach

Finding Recently Modified Files
Locating Newly Created Executables
Identifying Files with Unusual Extensions
Bonus Tip: Generate a CSV Report
Summary

Why Mastering Linux Searches Matters

In a large-scale production environment, hundreds, if not thousands, of files are created or modified daily. Running imprecise searches can return overwhelming results, wasting valuable time. By mastering advanced Linux search commands, you can pinpoint the exact information you need during an incident response, saving time and mitigating risks effectively.

Key Searches to Run During a Breach

1. Finding Recently Modified Files

When dealing with a breach, one of the first steps is identifying files modified recently. This can help you detect suspicious activity.

Command: - find / -type f -mtime -1

What It Does:

find /: Starts searching from the root directory.

-type f: Limits the search to files only.

-mtime -1: Finds files modified in the last 24 hours.

This search will return a lot of results because a lot if legitimate files can be generated in 24 hours, and it may be too broad of a search, but it's a place to start.
If you wanted to search the log files modified in the last 24 hours, run the command find /var/log/ -type f -mtime -1. This will return files in the log directory.

Use Case: If rogue files were added during the breach, this command helps identify them quickly. Be precise with your searches to avoid sifting through unrelated results.

2. Locating Newly Created Executables

Newly created executables can be a major red flag. These might be scripts or binaries added by attackers.

Command: - find / -type f -perm /111 -ctime -1

What It Does:

-perm /111: Finds files with execute permissions (for user, group, or others).

-ctime -1: Filters files created in the last 24 hours.

Use Case: Helps you focus on executable files that could potentially be malicious programs.

3. Identifying Files with Unusual Extensions

Attackers often hide malicious files using uncommon or suspicious extensions.

Command: - find / -type f $ -name "*.sh" -o -name "*.pyc" -o -name ".tmp" $

What It Does:

-type f: Limits the search to files.

$ ... $: Groups multiple conditions.

-o: Acts as “OR” to search for multiple extensions like .sh, .pyc, and .tmp.

Use Case: Quickly locate files with extensions that don’t usually appear in your system but may indicate malicious intent.

4. Bonus Tip: Generate a CSV Report

If you need to document your findings, you can export search results into a CSV file for easier analysis.

Command: - `find /var/log -type f -mtime -1 -name "*.log" -exec ls -l {} \; | awk '{print $NF","$5","$6", "$7" "$8}' > incident_results.csv

This command finds log files accessed in the last 24 hours and puts the output in a CSV file.

Run the command cat incident_results.csv to view the contents of the CSV file.

What It Does:

-exec ls -l {}: Lists details about each file found.

awk: Extracts the file name, size, and timestamp.

> incident_results.csv: Redirects the output into a CSV file.

Use Case: Perfect for creating a structured report to share with your security team or to document the incident.

5. Summary

When responding to a server breach, time is critical. The ability to perform precise, detailed searches on Linux servers is an invaluable skill for any engineer. By identifying suspicious files, you can help your team resolve incidents faster and more effectively. Having strong Linux search skills isn’t just about being technically proficient; it’s about being prepared when it matters most.

Connect with me on LinkedIn to comment or share your experiences with Linux.

#30DaysLinuxChallenge #RedHatEnterpriseLinux
#CloudWhistler #CloudEngineer #Linux
#DevOps #RedHat #OpenSource
#CloudComputing #WomenInTech

The Linux (rm) Command: Simple, Powerful, and Dangerous

Yvonne — Wed, 09 Apr 2025 05:54:17 +0000

There’s a reason that Linux professionals emphasize caution when using the rm command. It’s a very simple command, only two letters, but extremely powerful. If you’re not careful, a misplaced command could wipe out critical files or even an entire system. I want to share what I’ve learned about the rm command, from the basics to best practices, because understanding this command well can save you a lot of trouble down the road.

Index

1. What is the rm Command?
2. Common rm Options
3. The Dangers of the rm command
4. Best Practices for Using rm
5. Recommendations for Safe Use
6. Business Use Cases
7. Summary

1. What is the rm Command?

The rm command stands for "remove." It’s used to delete files and directories in Linux. It’s a pretty straightforward command, but its power lies in the options you can use to make it more flexible.

Basic Syntax
rm filename.txt - This removes a specified file from your system. For example, rm filetest2.txt will delete filetest2.txt.

2. Common rm Options

Here are some of the most commonly used (and most important!) options for rm:

-r: Recursively delete directories and their contents.
-f: Force removal without prompting for confirmation.
-i: Interactive mode, asking for confirmation before every deletion (highly recommended).

Example:
rm -ri foldername - This will prompt you for confirmation before removing the folder and its contents. For example, rm finance will delete the finance directory.

rm -rvf foldername - Recursive + Force: removes everything without asking. For example, rm -rvf inventory deletes the directory with contents without asking.

Why it Matters
The -r option is necessary when you need to delete directories, but combining it with -f can be risky. Always double-check your command when using these flags to avoid accidental deletions.

3. The Dangers of the rm Command

Here’s where things can go wrong:

Running rm * in the wrong folder can wipe out everything in that directory.
Using rm -rf / can (and will!) delete your entire root filesystem. That means that the server will become inoperable, and if no backup, could be down for hours or even days. The thing to understand about the rm command is that there is no undo. Once the files are removed, they’re gone.

4. Best Practices for Using rm

Always double-check your commands. Pay close attention to the paths and options you’re using.
Use the -i option. This interactive flag makes rm a lot safer by prompting you before each deletion.
Run a search first before deleting. If you’re using rm with search commands (like find), run the search alone first to verify what will be deleted.

Example Workflow:
Say you want to delete all files modified on a specific date (April 29, 2025), excluding hidden files and folders. Here’s the process:

Step 1 - Search:
find . -not -path '/.' -newermt "2025-04-29" ! -newermt "2025-04-30"

What It Does:

Searches the current directory (.).
Excludes hidden files and directories (-not -path '*/.*').
Finds files modified on April 29, 2025 (-newermt flags).

Step 2 - Delete (only after verifying the search):
find . -not -path '/.' -newermt "2025-04-29" ! -newermt "2025-04-30" -exec rm -rf {} +
What It Does:

Adds -exec rm -rf to delete the matched files and directories.

5. Recommendations for Safe Use

Using rm responsibly requires a little extra effort, but it’s worth it:

Never combine search and delete in one step without testing. Run the search first, and only add the delete command once you’re confident.
Communicate with your team. Before deleting anything in a shared environment, confirm with your team or a senior engineer.
Backup first. Whether it’s a snapshot, copy, or full backup, always have a fallback in case something goes wrong.
Document your actions. Log the commands you run and why, especially in production environments. Accountability is key.

6. Business Use Cases

Log rotation - Remove old logs from servers to free disk space.
Data retention compliance - Securely remove expired customer data after retention.
Security - Delete sensitive files from servers during incident response.

7. Summary

The rm command is one of the most useful tools in Linux, but it’s also one of the most dangerous. By taking the time to understand how it works and following best practices, you can avoid costly mistakes and handle deletions with confidence. Remember: double-check, backup, and think twice before you delete especially in a production environment.

Using the rm command responsibly is what makes a great cloud engineer stand out. It’s all about being careful and understanding the command.

Connect with me on LinkedIn to comment or share your experiences with Linux.

#30DaysLinuxChallenge #RedHatEnterpriseLinux
#CloudWhistler #CloudEngineer #Linux
#DevOps #RedHat #OpenSource
#CloudComputing #WomenInTech

Attention to Detail in Linux Commands

Yvonne — Tue, 08 Apr 2025 06:18:31 +0000

During those early days when I was getting the hang of Linux, I frequently encountered two of many messages: "No such file or directory" and "Command not found." The cause of these errors was for two reasons: typos and not knowing where I was in the directory structure. Through trial and error, I discovered how attention to detail is crucial in Linux.

Index

1. Introduction
2. No such file for directory
3. Command not found
4. Permission denied
5. Summary

1. Introduction

Paying attention to the little details in Linux makes a world of difference. As a cloud engineer, nailing the basics is absolutely essential as it’s the foundation for everything more advanced you’ll learn later on. It’s easy to overlook something small, but those tiny mistakes can have a big impact, especially in a live production environment. Being thorough and detail-oriented is what sets you apart and makes your job easier.

2. No such file or directory

Cause: Spacing issue, incorrect directory path, or missing directory.
Solution:
- Ensure there are no unnecessary spaces in your command. Linux is case-sensitive, so even a small mismatch trips it up.
- When creating multiple directories, use the -p option with the mkdir command to prevent this error. For example; mkdir -p jenkins/vs/v1/v2

Business Use Case: Being able to create multiple directories speeds up directory setup for complex projects; it's a time saver.

3. Command not found

Cause: The package required for the command is not installed.
Solution:

Check if the command is installed. For example, to find out if apropos is installed, run the command "which apropos" or "command -v apropos" If installed, you'll see an output like /usr/bin/apropos. If not, install the package associated with the command. Business Use Case: Imagine troubleshooting missing tools during a production environment setup. You can quickly identify and install essential commands saving hours of downtime.

4. Permission denied

Cause: User is trying to access a file or execute a script and does not have the required permissions.
Solution:

Check that the user is in the Linux "Wheel" group
Run the command with "sudo". For example to do an update, run "sudo yum install httpd".

In the example below, the user tried to create a script file and was denied.

The user was also not in the "sudoers" file
Add the user to the "Wheel" group. Run the command, "sudo usermod -aG wheel username". The "Wheel" group in Linux controls who has sudo access.
Check that user is added to the "Wheel" group. Run the command Business Use Case: In collaborative environments, ensuring the right people have the correct permissions streamlines workflows without compromising security.

5. Summary

I’m highlighting these common errors to show the importance of double-checking your commands and directory paths. Attention to detail can save time and prevent frustration in high-pressure environments.
Linux can be unforgiving with errors, but it rewards you when you master the OS and become efficient in doing those critical tasks. By developing an eye for detail and employing simple troubleshooting techniques, you can tackle common errors with confidence.

Connect with me on LinkedIn to comment or share your experiences with Linux.

#30DaysLinuxChallenge #RedHatEnterpriseLinux
#CloudWhistler #CloudEngineer #Linux
#DevOps #RedHat #OpenSource
#CloudComputing #WomenInTech