What are the main tasks of a Linux administrator?

Core tasks include managing users and groups, controlling services, scheduling jobs, installing packages, monitoring logs and maintaining security. Administrators also document changes and troubleshoot operating system and application failures.

What is the difference between an active and enabled service?

An active service is running at the present time. An enabled service is configured to start automatically during boot, but it may still be stopped or failed at a particular moment.

What is the difference between a user crontab and /etc/cron.d?

A user crontab runs every entry as the user who owns that crontab and does not contain a username field. Files under `/etc/cron.d/` are system-managed and require a username between the schedule and command.

Should I use apt or dnf on Linux?

Use APT on Ubuntu and Debian-based distributions. Use DNF on current RHEL, Rocky Linux, AlmaLinux and Fedora systems.

Why does a command work manually but fail in cron?

Cron provides a limited environment and may use a different working directory and `PATH`. Use absolute command paths, verify file permissions, redirect output to a log and test the command as the account that cron uses.

Does locking a Linux password disable the whole account?

No. Password locking prevents password-based authentication but may not stop SSH key access, active sessions, running processes or scheduled jobs. Administrators should review every access method before considering an account fully disabled.

Linux Administration Basics: Core Daily Tasks

What are Linux administration basics?

Linux administration basics include controlling user access, managing services, scheduling recurring tasks and maintaining software packages. These responsibilities keep servers secure, available and consistent across development, cloud and production environments.

A useful diagram-in-words is:

Administrator
    |
    +-- Users and groups --> Who can access the server?
    +-- Services ---------> Which applications are running?
    +-- Cron jobs --------> Which tasks run automatically?
    +-- Packages ---------> Which software is installed and updated?

Most administrative commands require root privileges. On systems configured for sudo, place sudo before commands that modify users, services, system files or packages.

This guide uses commands suitable for Ubuntu, Debian, RHEL, Rocky Linux and AlmaLinux. Distribution-specific differences are identified where necessary.

How are Linux users and groups managed?

Linux users identify people or applications, while groups provide shared access to files and administrative functions. Administrators create accounts, assign group memberships, control login shells and remove access when it is no longer required.

Linux stores local account information in several important files:

File	Purpose
`/etc/passwd`	Usernames, user IDs, home directories and login shells
`/etc/shadow`	Password hashes and password ageing information
`/etc/group`	Group names and memberships
`/etc/gshadow`	Protected group administration data

Do not edit these files directly unless there is a specific recovery requirement. Commands such as useradd, usermod and passwd validate changes more safely.

Creating an interactive user account

The following example creates a user named devops1 with a home directory and Bash shell:

sudo useradd -m -s /bin/bash devops1
sudo passwd devops1

Confirm the account and its group memberships:

id devops1
getent passwd devops1

Example output:

uid=1001(devops1) gid=1001(devops1) groups=1001(devops1)
devops1:x:1001:1001::/home/devops1:/bin/bash

The UID and GID are numeric identities used by the kernel. The final two fields in the getent output show the user's home directory and login shell.

Granting administrative access

Ubuntu and Debian commonly use the sudo group:

sudo usermod -aG sudo devops1

RHEL-based distributions normally use the wheel group:

sudo usermod -aG wheel devops1

The -aG combination is important. -G sets supplementary groups, while -a appends the new group without removing existing memberships.

The user should sign out and sign back in before testing the new membership:

sudo -l

Creating a service account

Applications should not normally run under a person's account. Create a dedicated system account with a non-interactive shell:

sudo useradd --system \
  --create-home \
  --home-dir /var/lib/reportsvc \
  --shell "$(command -v nologin)" \
  reportsvc

A service account limits the effect of an application compromise and makes file ownership easier to audit.

Locking or removing an account

Lock password authentication without deleting the account:

sudo passwd -l devops1

Password locking does not necessarily block SSH key authentication, active sessions or scheduled jobs. Review the user's SSH keys, processes, cron entries and application access separately.

Remove an account and its home directory only after backing up required data:

sudo userdel -r devops1

File access also depends on ownership and mode bits. See Linux file permissions and ownership for a focused explanation of chmod, chown and permission calculations.

How are Linux services controlled with systemd?

Most current Linux distributions use systemd to start, stop and monitor background services. The systemctl command manages service state, while journalctl reads logs collected by the systemd journal.

A service has two separate concepts:

Active state  --> Is the service running now?
Enabled state --> Is it configured to start during boot?

A service can be active but disabled, or enabled but currently stopped.

Checking and controlling a service

Use these commands with a service such as Nginx:

sudo systemctl status nginx
sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx
sudo systemctl reload nginx

restart stops and starts the process. reload asks a supported service to reread its configuration without a full restart.

Enable the service at boot and start it immediately:

sudo systemctl enable --now nginx

Check both states without reading the full status page:

systemctl is-active nginx
systemctl is-enabled nginx

Example output:

active
enabled

Reading service logs

Display recent messages for one unit:

sudo journalctl -u nginx --since "30 minutes ago"

Show the latest messages and continue following new entries:

sudo journalctl -u nginx -n 50 -f

If a service fails, inspect its status and journal before repeatedly restarting it:

sudo systemctl status nginx --no-pager -l
sudo journalctl -u nginx -b --no-pager

The -b option restricts results to the current boot. Messages commonly identify invalid configuration, missing files, permission failures or occupied ports.

If you create or modify a unit file, tell systemd to reread unit definitions:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload is not required after changing an application's normal configuration file unless its documentation specifically says so.

How does cron schedule recurring Linux tasks?

Cron runs commands according to minute, hour, day, month and weekday fields. It is suitable for simple recurring tasks such as report generation, cleanup and health checks, but jobs must be designed for cron's limited environment.

The five scheduling fields are:

* * * * * command
| | | | |
| | | | +-- Day of week: 0-7, where 0 and 7 are Sunday
| | | +---- Month: 1-12
| | +------ Day of month: 1-31
| +-------- Hour: 0-23
+---------- Minute: 0-59

Edit the current user's personal crontab with:

crontab -e

Examples include:

# Run every day at 02:30
30 2 * * * /home/devops1/bin/backup.sh

# Run every Monday at 09:00
0 9 * * 1 /home/devops1/bin/report.sh

# Run every 15 minutes
*/15 * * * * /home/devops1/bin/health-check.sh

A personal crontab does not include a username field. By contrast, /etc/crontab and files under /etc/cron.d/ include the account that should run the command:

*/10 * * * * reportsvc /usr/local/bin/check-web.sh

Making cron jobs reliable

Cron normally has a smaller PATH than an interactive shell. Use absolute paths for scripts and important commands, send output to a known log, and test the command as the intended account.

*/10 * * * * /usr/local/bin/check-web.sh >> /var/log/report-health/cron.log 2>&1

The 2>&1 expression sends standard error to the same file as standard output. Also ensure that the crontab file ends with a newline.

Test a system cron command as its service account:

sudo -u reportsvc /usr/local/bin/check-web.sh

In crontab command fields, an unescaped % has special meaning and may split the command input. Place complex logic in a script rather than building a long inline command. For more automation practice, read Linux shell scripting basics.

How are packages installed and updated?

Package managers install software from configured repositories, resolve dependencies and track installed files. Ubuntu and Debian use APT with dpkg, while RHEL-based systems use DNF with the RPM package database.

Task	Ubuntu or Debian	RHEL, Rocky or AlmaLinux
Refresh metadata	`sudo apt update`	`sudo dnf makecache`
Install package	`sudo apt install nginx`	`sudo dnf install nginx`
Check installed package	`dpkg -l nginx`	`rpm -q nginx`
Show package details	`apt-cache policy nginx`	`dnf info nginx`
Remove package	`sudo apt remove nginx`	`sudo dnf remove nginx`
Find package owning a file	`dpkg -S /path/file`	`rpm -qf /path/file`

Using APT safely

Refresh repository metadata before installation:

sudo apt update
sudo apt install nginx curl

Review available upgrades:

apt list --upgradable

Apply normal available upgrades during an approved maintenance period:

sudo apt upgrade

apt remove normally retains package configuration files. Use apt purge when you intentionally want to remove those files as well:

sudo apt purge nginx

Review the proposed package list before confirming autoremove, especially on important servers:

sudo apt autoremove

Using DNF safely

Install and inspect packages with:

sudo dnf install nginx curl
sudo dnf list installed nginx
sudo dnf info nginx

Check for updates:

sudo dnf check-update

A return code of 100 from dnf check-update means updates are available; it does not necessarily indicate a command failure. Review previous package transactions with:

sudo dnf history
sudo dnf history info last

On production systems, package changes should be tested, documented and performed with a recovery plan. Kernel, runtime and database library updates may require service restarts or a system reboot.

How can these tasks be combined in a practical lab?

A useful lab is to install Nginx, create a restricted monitoring account and schedule a local HTTP check every five minutes. This combines users, packages, services, file ownership and cron in one small administration workflow.

Step 1: Install the required packages

On Ubuntu or Debian:

sudo apt update
sudo apt install nginx curl

On RHEL-based systems:

sudo dnf install nginx curl

Step 2: Create the service account and log directory

sudo useradd --system --shell "$(command -v nologin)" reportsvc
sudo install -d -o reportsvc -g reportsvc -m 0750 /var/log/report-health

Step 3: Start Nginx

sudo systemctl enable --now nginx
systemctl is-active nginx

Step 4: Create the health-check script

sudo tee /usr/local/bin/check-web.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
LOG=/var/log/report-health/status.log
TIME=$(/usr/bin/date --iso-8601=seconds)

if /usr/bin/curl -fsS http://127.0.0.1/ > /dev/null; then
    echo "$TIME nginx=healthy" >> "$LOG"
else
    echo "$TIME nginx=failed" >> "$LOG"
fi
EOF

sudo chown root:root /usr/local/bin/check-web.sh
sudo chmod 0755 /usr/local/bin/check-web.sh

Step 5: Test and schedule it

sudo -u reportsvc /usr/local/bin/check-web.sh
sudo cat /var/log/report-health/status.log

Create a system cron entry:

sudo tee /etc/cron.d/report-health > /dev/null <<'EOF'
*/5 * * * * reportsvc /usr/local/bin/check-web.sh
EOF

sudo chmod 0644 /etc/cron.d/report-health

After five minutes, verify that another timestamp has appeared:

sudo tail /var/log/report-health/status.log

This lab also demonstrates least privilege: Nginx runs under its packaged service identity, the check runs as reportsvc, and only administrators can modify the script.

How do you troubleshoot common administration failures?

Start by confirming the exact user, service state, command path and package status rather than changing multiple settings at once. Logs and direct tests usually reveal whether the failure is caused by permissions, configuration, environment or dependencies.

Problem	Checks and corrective action
User cannot use sudo	Run `id username`, verify `sudo` or `wheel` membership, then start a new login session
Service will not start	Use `systemctl status` and `journalctl -u`; validate the application's configuration
Cron job does not run	Test as the target user, use absolute paths, check permissions and inspect cron logs
Package cannot be found	Refresh metadata and verify enabled repositories and the package name
Package manager is locked	Check for another active package process; do not immediately delete lock files

For cron logs on Ubuntu, try:

grep CRON /var/log/syslog
journalctl -u cron --since today

On RHEL-based systems, use:

journalctl -u crond --since today
systemctl status crond

To reproduce a restricted environment, test with a minimal PATH:

sudo -u reportsvc env -i PATH=/usr/bin:/bin /usr/local/bin/check-web.sh

If the wider server issue is not limited to these four areas, follow the structured checks in the Linux troubleshooting guide.

What should administrators remember?

Linux administration basics are easier to manage when each change is verified immediately. Create purpose-specific accounts, distinguish active services from enabled services, use explicit cron paths and review package operations before confirming them.

A short operational checklist is:

Confirm the target distribution and version.
Use sudo only where elevated access is required.
Verify users with id and getent.
Verify services with systemctl and journalctl.
Test cron commands as the actual execution user.
Use supported repositories and review package changes.
Record changes and maintain a rollback method.

These tasks are also part of practical cloud and deployment work. To build Linux, automation, containers and CI/CD skills together, enquire about the AWS DevOps course and request current batch details.

*Reviewed by Network Rhinos Linux and DevOps trainers.*

Linux Administration Basics: Users, Services, Cron and Packages