You can use RHEL's task scheduling capabilities in scenarios like automating system maintenance (for example, log rotation or backup operations), managing routine administrative tasks (like user account cleanup or security updates), or orchestrating complex workflows in enterprise environments. These scheduling tools are essential for maintaining system health and ensuring that critical operations run without manual intervention.

For system administrators, think of task scheduling as the backbone of automated system management, enabling you to set up processes that run reliably in the background while you focus on more strategic initiatives. Its power lies in its flexibility and reliability, making it an indispensable skill for anyone managing Linux systems in production environments.

In this tutorial, you’ll learn how to schedule tasks in Red Hat Enterprise Linux using various built-in tools and techniques. This content is part of Schedule Future Tasks, which is Chapter 2 of the Red Hat System Administration (RH134) course. RH134 is a fundamental course for the Red Hat Certified System Administrator (RHCSA) certification, one of the most respected credentials in the Linux administration field.

This hands-on tutorial provides practical experience with the scheduling concepts covered in the RH134 curriculum, giving you the skills needed to automate tasks effectively in enterprise RHEL environments.

Here's what we'll cover:

• How to Schedule a One-time Job with 'at'

• How to Manage 'at' jobs

• How to Schedule Recurring User Jobs with 'crontab'

• How to Manage User 'crontab' Entries

• How to Schedule Recurring System Jobs with cron Directories

• How to Configure systemd Timers for Recurring Tasks

• How to Manage Temporary Files with systemd-tmpfiles

Prerequisites

This tutorial is designed to be beginner-friendly! You just need basic familiarity with using the Linux command line. If you can navigate directories and run simple commands, you're ready to start.

For those looking to deepen their RHEL knowledge, the RHEL Skill Tree offers comprehensive hands-on labs including RH124, RH134, RH294, and other courses for RHCSA and RHCE certifications.

Don't worry if you're new to Red Hat Enterprise Linux – I'll explain everything step by step, and these concepts work on most Linux distributions too.

How to Schedule a One-time Job with 'at'

First, let’s learn how to schedule a job to run once at a future time using the at command. The at command is useful for executing commands that don’t need to be run repeatedly. We will schedule a simple job, inspect its details, and then remove it.

In this tutorial, we will work directly on the local system to learn task scheduling. You’ll execute all commands in your current terminal environment.

Let's schedule a job to print the current date and time into a file named ~/myjob.txt in your home directory. We'll schedule it to run 3 minutes from now:

at now + 3 minutes << EOF
date > ~/myjob.txt
EOF

The warning: commands will be executed using /bin/sh message is normal. The job N at ... output indicates the job number and the scheduled execution time. Make a note of the job number, as you will need it later.

Next, let's schedule another job interactively. This method is useful for entering multiple commands or more complex scripts. We will schedule a job to append "Hello from at job!" to ~/at_output.txt 5 minutes from now:

at now + 5 minutes

After typing the command and pressing Enter, you will see an at> prompt. Type your command and then press Ctrl+d to finish:

at > echo "Hello from at job!" >> ~/at_output.txt
at > Ctrl+d

To view the jobs currently in the at queue, use the atq command. This command lists all pending at jobs for the current user.

atq

The output will show the job number, the scheduled time, the queue, and the user who scheduled it.

You can inspect the commands that a specific at job will run using the at -c command followed by the job number. Replace N with one of the job numbers you noted earlier.

at -c N

This command will display the shell script that at will execute for that job. You should see the date > ~/myjob.txt or echo "Hello from at job!" >> ~/at_output.txt command within the output.

Finally, to remove a scheduled at job, use the atrm command followed by the job number. Let's remove the first job we scheduled. Replace N with the job number of your first job.

atrm N

After removing the job, you can use atq again to verify that it is no longer in the queue.

atq

You should now only see the second job (if it hasn't executed yet) or an empty queue if both jobs have been removed or executed.

This completes the first step of scheduling one-time jobs with the at command.

How to Manage 'at' jobs

Now, let’s delve deeper into managing at jobs, including scheduling jobs with different queues and verifying their execution. Understanding at queues can be useful for prioritizing tasks or separating different types of one-time jobs.

We will continue working on the local system to explore more advanced at job management features.

The at command allows you to specify a queue using the -q option. Queues are single letters from a to z. Queue a is the default, and jobs in queues a through z are executed with decreasing niceness (priority). Queue a has the highest priority, and queue z has the lowest. Queue b is reserved for batch jobs.

Let's schedule a job in queue g (a lower priority queue) to run in 2 minutes. This job will create a file named ~/queue_g_job.txt with a timestamp:

at -q g now + 2 minutes << EOF
date > ~/queue_g_job.txt
EOF

You will see output similar to job N at .... Note down this job number.

Next, let's schedule another job, this time in queue b (batch queue), which is typically used for jobs that can run when system load is low. This job will append "Batch job executed!" to ~/batch_job.txt. We'll schedule it to run 4 minutes from now:

at -q b now + 4 minutes << EOF
echo "Batch job executed!" >> ~/batch_job.txt
EOF

Again, note down the job number.

To see all pending jobs, including those in different queues, use atq.

atq

You should now see both jobs listed, with their respective queue letters (g and b).

Now, wait for your scheduled jobs to execute. Wait for at least 5 minutes to allow all jobs to complete. You can check if the files created by your at jobs exist and contain the expected content.

Check ~/queue_g_job.txt:

cat ~/queue_g_job.txt

You should see a date and time string.

Check ~/batch_job.txt:

cat ~/batch_job.txt

You should see "Batch job executed!".

If the files are not present or empty, it might mean the jobs haven't executed yet, or there was an issue with the command. You can re-check atq to see if they are still pending.

How to Schedule Recurring User Jobs with 'crontab'

Next, you’ll learn how to schedule recurring tasks for a specific user using crontab. Unlike at jobs, which run once, cron jobs run repeatedly at specified intervals. This is ideal for routine maintenance, data backups, or generating reports.

We will continue working on the local system to learn about user crontab management.

The crontab command allows users to create, edit, and view their own cron jobs. Each user has their own crontab file.

To edit your crontab file, use the crontab -e command. This will open your crontab file in the default text editor (usually vim).

crontab -e

Vim editor instructions:

• Press i to enter insert mode (you'll see -- INSERT -- at the bottom)

• Use arrow keys to navigate

• To save and exit: Press Esc to exit insert mode, then type :wq and press Enter

• To exit without saving: Press Esc, then type :q! and press Enter

Inside the editor, you will add a new line to define your cron job. A cron entry has five time-and-date fields, followed by the command to be executed. The fields are:

• Minute (0-59)

• Hour (0-23)

• Day of Month (1-31)

• Month (1-12)

• Day of Week (0-7, where 0 or 7 is Sunday)

You can use * as a wildcard to mean "every" for a field, or / to specify step values (for example, */5 for every 5 minutes).

Let's schedule a job that appends the current date and time to a file named ~/my_cron_log.txt every minute. This will allow us to quickly observe the cron job in action.

Follow these steps in Vim:

1. Press i to enter insert mode

2. Add the following line to the crontab file:

* * * * * /usr/bin/date >> ~/my_cron_log.txt

3. Press Esc to exit insert mode

4. Type :wq and press Enter to save and exit

You should see a message indicating that a new crontab has been installed:

crontab: installing new crontab

To verify that your cron job has been successfully added, you can list your crontab entries using the crontab -l command:

crontab -l

You should see the line you just added:

* * * * * /usr/bin/date >> ~/my_cron_log.txt

Now, wait for a minute or two to allow the cron job to execute at least once. You can check the current time to see when the next minute mark will occur:

date

After waiting for at least two minutes to allow the cron job to execute a couple of times, check the content of the ~/my_cron_log.txt file.

cat ~/my_cron_log.txt

You should see one or more lines, each containing a date and time, indicating that your cron job has executed.

Mon Apr 8 10:30:01 AM EDT 2025
Mon Apr 8 10:31:01 AM EDT 2025

How to Manage User 'crontab' Entries

Now you will learn more advanced techniques for managing user crontab entries, including editing existing jobs, adding multiple jobs, and understanding special cron strings. Effective crontab management is crucial for automating routine tasks.

We will continue working on the local system to explore advanced crontab management techniques.

Let's start by adding a new cron job. This job will append "Hello from cron!" to ~/cron_messages.txt every two minutes.

Open your crontab for editing:

crontab -e

In Vim:

1. Press i to enter insert mode

2. Add the following line to the crontab file:

*/2 * * * * echo "Hello from cron!" >> ~/cron_messages.txt

3. Press Esc to exit insert mode

4. Type :wq and press Enter to save and exit

Verify that the entry is added:

crontab -l

You should see the newly added line.

Now, let's add another cron job that runs daily at 08:00 AM. This job will record the disk usage of your home directory to ~/disk_usage.log.

Open your crontab for editing again:

crontab -e

In Vim:

1. Press i to enter insert mode

2. Add the following line below the previous one:

0 8 * * * du -sh ~ >> ~/disk_usage.log

3. Press Esc to exit insert mode

4. Type :wq and press Enter to save and exit

Verify that both entries are present:

crontab -l

You should now see both cron jobs listed.

cron also supports special strings that can simplify common schedules. These include @reboot, @yearly, @annually, @monthly, @weekly, @daily, @midnight, and @hourly. For example, @hourly is equivalent to 0 * * * *.

Let's add a job that runs hourly and records the system uptime to ~/uptime_log.txt.

Open your crontab for editing:

crontab -e

In Vim:

1. Press i to enter insert mode

2. Add the following line:

@hourly uptime >> ~/uptime_log.txt

3. Press Esc to exit insert mode

4. Type :wq and press Enter to save and exit

Verify all three entries:

crontab -l

You should now see all three cron jobs.

To demonstrate the effect of these jobs, we will wait for a short period. Since the jobs are scheduled at different intervals, we won't see all of them execute immediately, but we can verify the setup.

Wait for at least 3 minutes to allow the */2 job to run at least once.

Check the ~/cron_messages.txt file:

cat ~/cron_messages.txt

You should see at least one "Hello from cron!" message.

Hello from cron!

The ~/disk_usage.log and ~/uptime_log.txt files might not be created yet, depending on the current time, as they are scheduled for daily and hourly execution, respectively. The important part is that their entries are correctly configured in your crontab.

How to Schedule Recurring System Jobs with cron Directories

In this step, you will learn how to schedule recurring system-wide tasks using cron directories. Unlike user crontab entries, which are specific to a user, system cron jobs are managed by the root user and affect the entire system. These are typically used for system maintenance, log rotation, and other administrative tasks.

We will continue working on the local system to explore system-wide cron job configuration.

System-wide cron jobs are defined in /etc/crontab or by placing scripts in specific directories:

• /etc/cron.hourly/: Scripts in this directory run once an hour.

• /etc/cron.daily/: Scripts in this directory run once a day.

• /etc/cron.weekly/: Scripts in this directory run once a week.

• /etc/cron.monthly/: Scripts in this directory run once a month.

These directories are processed by the run-parts utility, which executes all executable files within them.

To manage system cron jobs, you need root privileges. Since the labex user has sudo access, we can use sudo for the required commands.

Let's create a simple script that logs a message to the system log. We will place this script in /etc/cron.hourly/ to make it run hourly.

First, create the script file /etc/cron.hourly/my_hourly_script:

sudo nano /etc/cron.hourly/my_hourly_script

Add the following content to the file:

#!/bin/bash
logger "Hourly cron job executed at $(date)"

Save and exit the editor (Ctrl+o, Enter, Ctrl+x in nano).

Next, you need to make the script executable. Without execute permissions, run-parts will ignore it.

sudo chmod +x /etc/cron.hourly/my_hourly_script

Now, let's verify that the script is executable:

ls -l /etc/cron.hourly/my_hourly_script

You should see x in the permissions, for example: -rwxr-xr-x.

Since cron.hourly jobs run once an hour, we can't wait for a full hour to verify its execution in this tutorial. But we can manually trigger the run-parts command for the hourly directory to simulate its execution.

sudo run-parts /etc/cron.hourly/

This command will execute all executable scripts in /etc/cron.hourly/. The script we created uses the logger command to write messages to the system log.

In a real RHEL system, you would be able to check the system logs using journalctl or /var/log/messages to verify that the script executed successfully.

This completes the system cron job management step. The script will remain in place and would execute hourly in a real system environment.

How to Configure systemd Timers for Recurring Tasks

Next, you will learn about systemd timers, which are a modern alternative to cron for scheduling tasks on Linux systems. systemd timers offer more flexibility and better integration with the systemd ecosystem.

systemd timers work in conjunction with systemd service units. A timer unit (.timer file) defines when a task should run, and a service unit (.service file) defines what task should be executed.

We will continue working on the local system to explore systemd timer configuration.

You will need root privileges to create systemd unit files in system directories. Since the labex user has sudo access, we can use sudo for the required commands.

Let's create a simple service that logs a message to a file. We will place this service unit file in /etc/systemd/system/ which is where custom service units are typically stored.

Create the service unit file /etc/systemd/system/my-custom-task.service:

sudo nano /etc/systemd/system/my-custom-task.service

Add the following content to the file:

[Unit]
Description=My Custom Scheduled Task

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'echo "My custom task executed at $(date)" >> /var/log/my-custom-task.log'

Save and exit the editor (Ctrl+o, Enter, Ctrl+x in nano).

Next, create the timer unit file /etc/systemd/system/my-custom-task.timer. This timer will activate our service every 5 minutes.

sudo nano /etc/systemd/system/my-custom-task.timer

Add the following content to the file:

[Unit]
Description=Run My Custom Scheduled Task every 5 minutes

[Timer]
OnCalendar=*:0/5
Persistent=true

[Install]
WantedBy=timers.target

Save and exit the editor.

Explanation of OnCalendar:

• *:0/5 means "every 5 minutes".

  • * for year, month, day, hour (any value).

  • 0/5 for minute, meaning starting at minute 0, every 5 minutes (0, 5, 10, ..., 55).

In a typical systemd environment, you would now run systemctl daemon-reload to make systemd aware of the new unit files, and then systemctl enable --now my-custom-task.timer to start the timer.

Let's verify the existence of the created files:

ls -l /etc/systemd/system/my-custom-task.service
ls -l /etc/systemd/system/my-custom-task.timer

You should see output indicating that both files exist.

To simulate the execution of the service, you can manually run the command defined in ExecStart:

sudo /bin/bash -c 'echo "My custom task executed at $(date)" >> /var/log/my-custom-task.log'

Now, check the log file to see the output:

sudo cat /var/log/my-custom-task.log

You should see the message you just logged:

My custom task executed at Tue Jun 10 06:54:40 UTC 2025

This completes the systemd timer configuration step. The service and timer unit files will remain in place for reference.

How to Manage Temporary Files with systemd-tmpfiles

Now you’ll learn how to manage temporary files and directories using systemd-tmpfiles. This utility is part of systemd and is responsible for creating, deleting, and cleaning up volatile and temporary files and directories. It's commonly used to manage /tmp, /var/tmp, and other temporary storage locations, ensuring that old files are removed periodically.

We will continue working on the local system to explore systemd-tmpfiles configuration.

You will need root privileges to configure systemd-tmpfiles. Since the labex user has sudo access, we can use sudo for the required commands.

systemd-tmpfiles reads configuration files from /etc/tmpfiles.d/ and /usr/lib/tmpfiles.d/. These files define rules for creating, deleting, and managing files and directories.

Let's create a custom configuration file to manage a new temporary directory. We will create a directory /run/my_temp_dir and configure systemd-tmpfiles to clean files older than 1 minute from it.

Create the configuration file /etc/tmpfiles.d/my_temp_dir.conf:

sudo nano /etc/tmpfiles.d/my_temp_dir.conf

Add the following content to the file:

d /run/my_temp_dir 0755 labex labex 1m

Explanation of the line:

• d: Specifies that this entry defines a directory.

• /run/my_temp_dir: The path to the directory.

• 0755: The permissions for the directory.

• labex labex: The owner and group for the directory.

• 1m: The age after which files in this directory should be deleted (1 minute).

Save and exit the editor (Ctrl+o, Enter, Ctrl+x in nano).

Now, let's tell systemd-tmpfiles to apply this configuration. The --create option will create the directory if it doesn't exist.

sudo systemd-tmpfiles --create /etc/tmpfiles.d/my_temp_dir.conf

Verify that the directory has been created with the correct permissions and ownership:

ls -ld /run/my_temp_dir

You should see output similar to:

drwxr-xr-x 2 labex labex 6 Jun 10 06:55 /run/my_temp_dir

Next, let's create a test file inside this new temporary directory:

sudo touch /run/my_temp_dir/test_file.txt

Verify the file exists:

ls -l /run/my_temp_dir/test_file.txt

Now, we need to wait for more than 1 minute for the file to become "old" according to our configuration. Wait for at least 70 seconds (1 minute and 10 seconds).

After waiting for more than 1 minute, we will manually run systemd-tmpfiles with the --clean option to trigger the cleanup process based on our configuration.

sudo systemd-tmpfiles --clean /etc/tmpfiles.d/my_temp_dir.conf

Finally, check if the test_file.txt has been removed:

ls -l /run/my_temp_dir/test_file.txt

You should get a "No such file or directory" error, indicating that systemd-tmpfiles successfully cleaned up the old file.

This completes configuring the systemd-tmpfiles. The configuration file and temporary directory will remain in place for reference.

Summary

In this tutorial, you learned how to schedule and manage one-time tasks using the at command, including scheduling jobs interactively and non-interactively, viewing the at queue with atq, and deleting pending jobs with atrm. You also learned how to schedule recurring user-specific tasks using crontab, including how to edit, list, and remove cron jobs, and you learned the cron syntax for specifying execution times.

We also demonstrated how to schedule system-wide recurring tasks by placing scripts in standard cron directories (/etc/cron.hourly, /etc/cron.daily, etc.) and how to create custom cron jobs in /etc/cron.d.

Finally, you explored advanced task scheduling with systemd timers, learning to create and enable service and timer units for recurring tasks, and how to manage temporary files and directories using systemd-tmpfiles for automated cleanup.

This comprehensive tutorial provided practical experience in managing diverse task scheduling needs on RHEL systems, from simple one-off commands to complex recurring system processes.

To practice the operations from this tutorial, try the interactive hands-on lab: Schedule Tasks in Red Hat Enterprise Linux.

Managing users in RHEL is kind of like that. You decide who gets in, what they can do, and how much control they have. Without proper management, things can get messy fast—like that friend who somehow DJs when no one asks.

So, let’s dive into user management and ensure your Linux system stays organized, secure, and drama-free! 🚀

Table Of Contents

1. What is a User in Linux?

   • Understanding sudo in User Management

2. User Management Commands in Linux

   • How to Add a User

   • How to Check if a User is Created

   • How to Assign a Password

   • How to Switch Users

   • Understanding Groups in Linux

   • How to Modify Users

3. Final Words

What is a User in Linux?

A user in Linux is an account that allows someone (or a process) to interact with the system. Since Linux is a multi-user operating system, multiple users can exist on the same system, each with their own settings, files, and permissions. Users can have different levels of permissions, which determine what they can access or modify on the system.

Linux categorizes users into three main types based on their roles and privileges:

1. Privileged Users: These users have unrestricted access to the entire system. They have the highest level of permissions and can perform any operation on the system. They can install/remove software, modify system files, create/manage users, and even delete everything. These users are also called root users.

2. System Users: The system creates these users to run background processes or services. They can’t login like a normal user. Their sole purpose is to manage system operations like databases, web servers and scheduled tasks.

3. Normal Users: These are the everyday users created by administrators or during system installation. They have their home directory and can store personal files and settings. They can’t modify system files but can execute tasks within their permission scope.

Understanding sudo in User Management

The sudo (Superuser Do) command allows a regular user to execute administrative tasks with elevated privileges. Since user management tasks—such as adding, modifying, or deleting users—require root access, normal users must use sudo before these commands.

Note that the following commands are executed as the root user. If you are using a normal user account, you must prefix them with sudo to perform user management tasks.

Now let’s see how we manage users on RHEL.

User Management Commands in Linux

How to add a user

To create a new user account, use following command:

Syntax:

useradd [user_name]

Example:

useradd Tanishka # Root user
sudo useradd Tanishka # Normal user

Once you create a user, you can verify its existence in the /etc/passwd file. This file stores essential user account information (but not passwords, despite the name).

How to check if a user is created

To confirm the user entry in /etc/passwd, use one of the following methods:

1. View the file using cat or grep

cat /etc/passwd # Displays entire file content
grep Tanishka /etc/passwd # Displays information about Tanishka user only

2. Use id command:

The id command is used to display a user’s UID (User ID), GID (Group ID), and the groups they belong to. It helps in verifying user information and checking permissions.

id Tanishka
# Displays user id of Tanishka,
# hence verifying user has been created

Let’s understand what’s going on in the /etc/password fields. Each line in /etc/passwd represents a user account and contains seven fields separated by colons (:):

username:x:UID:GID:comment:home_directory:shell

How to Assign a Password

Once an account is created, it’s essential to assign a password to the account. Otherwise, that account can’t be logged in through a GUI login interface. To give a password to a user account, user this command:

Syntax:

passwd [user_name]

Example:

passwd Tanishka

You will be prompted to enter the password. Enter the password and you’re all set! Even though user information is stored in /etc/passwd file, actual information about the password is stored in the /etc/shadow file (weird, I know…).

To see the content of the /etc/shadow file, use this command:

cat /etc/shadow

Each line in /etc/shadow represents a user account password and contains nine fields separated by colons (:):

username:password:lastchg:min:max:warn:inactive:expire:reserved

To change password aging information, you use the chage (short for change age) command like this:

Syntax:

chage [OPTIONS] [user_name]

Example:

chage -l tanishka # Lists the current password aging information
chage -m 10 tanishka # Sets the minimum days to change password
chage -M 10 tanishka # Sets the maximum days password must be changed
chage -W 7 tanishka # Sets the number of days before the password expires that the user will be warned to change the password
chage -I 10 tanishka # Sets the number of days after password expiration that the account will be disabled if not logged in
chage -E 2025-12-31 tanishka # Sets the date when the user account will expire 
chage -d 2024-12-25 tanishka # Sets the last password change date

Now that you have learned to create users and assign passwords, you need to know how to switch between users. Let’s see that now.

How to Switch Users

The su (Substitute User) command allows you to switch from one user to another without logging out of the current session.

Syntax:

su - [user_name]

Example:

su - Tanishka # Switches to Tanishka user

• su stands for "substitute user" (or "switch user").

• The - (hyphen) loads the target user's full environment, including their shell, path, and profile settings (similar to logging in as that user).

• If no username is provided, it switches to the root user by default.

To return to original or root user, simply enter ‘exit’.

Understanding Groups in Linux

Just like a party where guests can belong to different social circles, Linux groups allow users to be part of different permission levels. Groups help manage file access, system privileges, and administrative controls efficiently.

Linux has two types of groups:

1. Primary Group:

• Every user has one primary group.

• When a user creates a new file, it belongs to their primary group.

• It is usually named the same as the username.

2. Secondary Groups:

• A user can belong to multiple secondary groups.

• These groups provide additional permissions beyond the primary group.

• Users can be assigned to various secondary groups to access shared resources.

To check a user’s group membership:

id [user_name]

This displays the user’s UID, primary group (GID), and any secondary groups they belong to.

To add a new group:

groupadd [group_name]

How to Modify a User

Sometimes, you might need to update user details, such as changing usernames, user IDs, group memberships, home directories, or login shells. You use the usermod command to modify existing user accounts while preserving their files and configurations.

Syntax:

usermod [OPTIONS] [user_name]

Let’s break down the different options available for modifying user accounts.

1. Change the username

If you want to rename an existing user, use the -l option:

Syntax:

usermod -l new_username old_username

Example:

usermod -l tanishkamakode tanishka

This renames tanishka to tanishkamakode. Just keep in mind that the home directory remains the same (/home/tanishka), so you might need to rename it manually.

To rename the home directory as well, use:

mv /home/tanishka /home/tanishkamakode

2. Change the user id:

Each user has a unique User ID (UID). If you need to change it, use -u.

Syntax:

usermod -u new_UID user_name

Example:

usermod -u 2001 tanishka

This changes tanishka's UID to 2001. Before you do this, you’ll want to make sure that no other user has the same UID. This is important.

If the user owns files under the old UID, you should update them after changing the UID.

3. Change the primary group

Every user belongs to a primary group. To change it, use -g.

Syntax:

usermod -g new_group user_name

Example:

usermod -g developers tanishka

This changes tanishka's primary group to developers. Just keep in mind that usermod -g developers tanishka removes the user from all secondary groups. To avoid that, just make sure you check and re-add secondary groups as needed.

Also, the group must exist beforehand. To create a group, run this command:

Syntax:

groupadd [group_name]

Example:

groupadd developers

Now, to check tanishka’s group, do the following:

id tanishka

4. Add to a secondary group

A user can belong to multiple secondary groups. Use -G to assign them.

Syntax:

usermod -G group1,group2 user_name

Example:

usermod -G linux,docker tanishka

This adds tanishka to the sudo and docker groups. Just keep in mind that this replaces any existing secondary groups that the user might already belong to. To add groups without removing the current ones, use -aG (append to groups) like this:

usermod -aG linux,docker tanishka

5. Change the home directory:

You can change a user’s default home directory using -d.

Syntax:

usermod -d /new/home_directory user_name

Example:

usermod -d /home/tani tanishka

This sets tanishka's home directory to /home/tani, but it does not move existing files. To move them, add the -m option:

usermod -d /home/tani -m tanishka

After moving the home directory, just make sure you’ve updated file ownership.

6. Change the login shell:

The default shell for a user can be changed using -s.

Syntax:

usermod -s /new/shell user_name

Example:

usermod -s /bin/zsh tanishka

This changes tanishka's default shell to zsh. Common shells include:

• /bin/bash (default)

• /bin/sh

• /bin/zsh

• /usr/sbin/nologin (to disable login)

With usermod, you can fine-tune user settings to match system requirements. Always check changes using:

id tanishka
grep tanishka /etc/passwd

Final Words

In this article, we explored the fundamentals of user management in RHEL, a crucial aspect of system administration. We started with creating and managing users, then moved on to handling groups.

If you're new to Linux and want to build a strong foundation, check out my first tutorial on Basic Linux Commands, where I cover essential commands every beginner should know. You can also read my second tutorial on Vim to learn how to navigate and edit text efficiently in this powerful editor. These articles will complement what you’ve learned about user management here.

Keep practicing these commands, and soon they’ll become second nature to you. Mastery comes with repetition, so continue experimenting and applying these fundamentals in real-world scenarios.

Stay tuned for more articles. Get ready to take your RHEL skills to the next level.

Let’s connect!