Unit 4: Command Productivity, Scheduling, Performance, and ACLs - Subjective Questions

Command-line productivity features reduce typing, prevent errors, and make previously executed commands easier to reuse.

• Command history: Bash stores previously executed commands. The history command displays them, the Up/Down Arrow keys navigate them, and !! repeats the previous command.
• History expansion: Expressions such as !25 execute command number 25, while !grep executes the most recent command beginning with grep.
• Reverse search: Ctrl+R searches interactively through command history.
• Command-line editing: Shortcuts such as Ctrl+A and Ctrl+E move the cursor to the beginning and end of a line. Ctrl+U removes text before the cursor, while Ctrl+K removes text after it.
• Tab completion: Pressing Tab completes command names, paths, filenames, variables, and other shell-supported items. Pressing it twice can display possible matches.

Together, these features make shell work faster and reduce mistakes caused by repeatedly entering long commands or paths.

These Bash features simplify commands and allow values to be reused dynamically.

• Shell variable: Stores data in the current shell, for example, project=/srv/project. Its value is accessed as $project.
• Environment variable: A variable exported to child processes, for example, export EDITOR=vim. Common environment variables include PATH, HOME, and LANG.
• Alias: Defines a short replacement for a longer command, such as alias ll='ls -alF'. The unalias command removes an alias.
• Command substitution: Captures the output of a command using $(command). For example, today=$(date +%F) stores the current date.
• Persistent configuration: Frequently used variables and aliases can be added to files such as ~/.bashrc.

Variables avoid repetition, aliases shorten common commands, and command substitution supplies values calculated at execution time.

A Bash script is a text file containing commands interpreted by the Bash shell.

• Shebang: The first line, normally #!/bin/bash, identifies the interpreter that should run the script.
• Comments: Lines beginning with # document the script and are ignored by the shell, except for the shebang.
• Variables: Values are assigned without spaces, such as name=admin, and referenced as $name or ${name}.
• Commands: Commands are normally executed from top to bottom.
• Exit status: exit 0 indicates success, while a nonzero value indicates an error. The status of the most recent command is available through $?.

To run a script, grant execute permission with chmod +x script.sh and execute it as ./script.sh. Alternatively, run it directly through the interpreter with bash script.sh, which does not require execute permission on the script file.

A suitable script is:

#!/bin/bash

if [[ $# -ne 1 ]]; then
    echo "Usage: $0 DIRECTORY" >&2
    exit 2
fi

dir=$1
if [[ ! -d $dir ]]; then
    echo "Error: $dir is not a directory" >&2
    exit 1
fi

count=$(find "$dir" -maxdepth 1 -type f -printf '.' | wc -c)
echo "Regular files: $count"
exit 0

Explanation:

• $# contains the number of positional arguments.
• $0 is the script name, while $1 is the first argument.
• [[ -d $dir ]] tests whether the supplied path is a directory.
• Quoting "$dir" prevents spaces and wildcard characters in the path from being interpreted incorrectly.
• find selects regular files at exactly the required directory level.
• Command substitution stores the count in count.
• Messages for invalid input are redirected to standard error with >&2.
• Distinct nonzero exit codes identify usage and path errors.

Bash loops repeat commands without requiring the administrator to enter each command separately.

• for loop: Iterates over a known list of values. It is suitable for processing multiple users or files.

for user in alice bob carol; do
    id "$user"
done

• while loop: Continues while a condition succeeds. It is useful when the number of iterations is not known in advance.

while read -r host; do
    ping -c 1 "$host"
done < hosts.txt

• until loop: Continues until a condition becomes successful. It is useful for waiting for a service or resource.

until systemctl is-active --quiet httpd; do
    sleep 5
done

A loop should include a changing condition or termination mechanism. Otherwise, it may run indefinitely and consume system resources.

One possible solution is:

#!/bin/bash

for mount_point in / /home /var; do
    usage=$(df -P "$mount_point" | awk 'NR == 2 {gsub(/%/, "", $5); print $5}')

    if (( usage >= 80 )); then
        printf 'WARNING: %s is %s%% full\n' "$mount_point" "$usage"
    else
        printf 'OK: %s is %s%% full\n' "$mount_point" "$usage"
    fi
done

Explanation:

• The for loop processes each mount point in the list.
• df -P produces predictable POSIX-style disk usage output.
• awk selects the second record, removes % from the usage field, and prints the numeric value.
• $(...) captures the command output.
• (( usage >= 80 )) performs an arithmetic comparison.
• Variables representing pathnames are quoted to prevent word splitting and pathname expansion.
• printf provides controlled output formatting, and %% prints a literal percent sign.

In a production script, the administrator could also validate that each mount point exists and send warnings to system logging or monitoring software.

A regular expression is a pattern used to locate or validate text. Commands such as grep, sed, and awk use regular expressions to filter or transform data.

Common pattern elements include:

• ^ matches the beginning of a line.
• $ matches the end of a line.
• . matches any single character.
• [abc] matches one listed character.
• [^abc] matches one character not in the list.
• * matches zero or more occurrences of the preceding expression.
• [0-9] matches one digit in a suitable locale.

Basic regular expressions (BRE) are used by standard grep. Operators such as grouping and alternation may require backslashes. Extended regular expressions (ERE) are enabled by grep -E and directly support operators such as +, ?, |, and parentheses.

For example, grep -E '^(error|warning):' file matches lines beginning with either error: or warning:.

The following commands illustrate suitable patterns:

• Failed SSH login messages:

grep -Ei 'failed (password|publickey)' /var/log/secure

-E enables alternation, and -i makes matching case-insensitive.

• Blank or whitespace-only lines:

grep -E '^[[:space:]]*$' file.txt

^ and $ anchor the entire line, while [[:space:]]* permits zero or more whitespace characters.

• Usernames beginning with a lowercase letter or underscore and followed by permitted characters:

grep -E '^[a-z_][a-z0-9_-]*$' usernames.txt

The first character is restricted separately, and the remaining class may repeat zero or more times.

These expressions should be chosen according to the actual format of the input. Anchors are important when the whole line must satisfy a rule rather than merely contain a matching substring.

The at facility schedules commands to run once at a specified future time. The atd service must be installed and running.

• Schedule interactively with a command such as at 22:30 or at now + 2 hours.
• Enter one or more commands at the at> prompt.
• Press Ctrl+D to submit the job.
• Use atq or at -l to list pending jobs.
• Use at -c JOB_ID to inspect the commands and environment stored for a job.
• Use atrm JOB_ID or at -r JOB_ID to remove a pending job.

Example:

echo '/usr/local/bin/report.sh' | at 23:00

An at job runs non-interactively with a saved environment and working-directory context. Commands should therefore use absolute paths where practical and redirect output explicitly. Access may be controlled by /etc/at.allow and /etc/at.deny.

at, cron, and systemd timers all schedule work, but they serve different needs.

• at: Runs a job once at a specified future time. It is appropriate for a one-time report, shutdown, or maintenance command.
• cron: Runs jobs repeatedly according to calendar fields in a crontab. It is widely available and simple for periodic tasks.
• Systemd timer: Activates a corresponding service unit. It supports calendar schedules, monotonic timers, dependency management, missed-run handling, logging through the journal, and randomized delays.

Important differences:

• at jobs disappear after execution; recurring definitions remain until removed.
• Cron uses compact time fields, while systemd timers can use directives such as OnCalendar= and OnUnitActiveSec=.
• Systemd timers separate the schedule from the command by placing work in a service unit.
• All three normally run without an interactive terminal, so scripts must not depend on prompts or a user's full login environment.

The choice depends on whether execution is one-time or recurring and whether advanced service-management features are required.

A user crontab line has five time fields followed by the command:

minute hour day-of-month month day-of-week command

For 15 2 * * 1-5 /usr/local/sbin/backup.sh:

• 15 means minute 15.
• 2 means 02:00 hours.
• * in the day-of-month field means every day of the month.
• * in the month field means every month.
• 1-5 means Monday through Friday.
• The script therefore runs at 02:15 every weekday.

A user creates or edits a crontab with crontab -e, lists it with crontab -l, and removes it with crontab -r.

Precautions:

• Use absolute paths for commands and files.
• Ensure the script is executable and readable by the job owner.
• Define required variables such as PATH explicitly.
• Redirect standard output and error to a log when needed.
• Avoid interactive commands.
• Prevent overlapping executions if a previous run may still be active, for example by using flock.
• Remember that system crontabs such as /etc/crontab include an additional username field.

Recurring system work can be configured through either cron facilities or systemd timers.

Cron-based jobs:

• /etc/crontab and files in /etc/cron.d/ use time fields followed by a username and command.
• Directories such as /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, and /etc/cron.monthly/ contain scripts run at predefined intervals, often through run-parts or anacron.
• anacron is useful for daily or longer-period jobs on systems that may not remain powered on continuously.

Systemd timer-based jobs:

• A .service unit defines the command to execute.
• A matching .timer unit defines when the service is activated.
• OnCalendar= specifies calendar times, while OnBootSec= and OnUnitActiveSec= specify monotonic intervals.
• Persistent=true can trigger a missed calendar event after the system starts again.
• systemctl enable --now name.timer enables and starts the timer.
• systemctl list-timers displays active timers and their next execution times.

Systemd timers provide stronger integration with service dependencies, status reporting, and journal logging.

Temporary files may contain sensitive data, consume storage, or introduce security vulnerabilities if their names and permissions are handled incorrectly.

Secure management practices include:

• Use mktemp to create an unpredictable file safely, for example, tmpfile=$(mktemp).
• Use mktemp -d when a private temporary directory is required.
• Quote the variable whenever the temporary path is referenced.
• Install a shell trap such as trap 'rm -f "$tmpfile"' EXIT so cleanup occurs when the script exits.
• Do not create predictable names such as /tmp/report.$$ when mktemp is available, because an attacker may pre-create links or files.
• Apply restrictive permissions and avoid storing secrets longer than necessary.
• Use /run for volatile runtime state when appropriate; it is generally cleared during boot.
• Use system facilities such as systemd-tmpfiles to create, clean, or remove temporary paths according to centrally managed policies.

The shared /tmp directory normally has the sticky bit, which limits deletion of files owned by other users, but it does not eliminate unsafe filename or permission practices.

systemd-tmpfiles applies declarative policies for creating, removing, and cleaning files and directories used during boot and normal operation.

Configuration is commonly read from:

• /usr/lib/tmpfiles.d/ for vendor-provided defaults.
• /usr/local/lib/tmpfiles.d/ for locally installed software.
• /run/tmpfiles.d/ for runtime configuration.
• /etc/tmpfiles.d/ for administrator-defined configuration and overrides.

A configuration entry can specify a path's type, permissions, owner, group, age, and related arguments.

Important operations include:

• systemd-tmpfiles --create creates configured paths and applies metadata.
• systemd-tmpfiles --clean removes content that exceeds configured age limits.
• systemd-tmpfiles --remove removes paths marked for removal.

Files with the same name in higher-priority directories override lower-priority definitions. Before applying a custom policy, the administrator should verify that paths, ownership, age rules, and removal behavior cannot affect persistent or actively used data.

Performance tuning should begin with a measurable workload and a clearly identified bottleneck.

A systematic approach is:

1. Establish a baseline for response time, throughput, utilization, and error rates.
2. Reproduce or observe the workload under realistic conditions.
3. Determine whether the constraint involves CPU, memory, storage, network, or application locking.
4. Change one relevant parameter or profile at a time.
5. Repeat the measurement and compare it with the baseline.
6. Retain the change only if it provides a reliable improvement without unacceptable side effects.

Useful commands include:

• uptime, top, and pidstat for load and process activity.
• vmstat and free for memory, paging, and CPU statistics.
• iostat for storage-device utilization and latency indicators.
• ss for socket and network-connection information.
• sar for current or historical system activity.

High utilization alone does not always indicate a fault. Measurement must precede tuning because changing unrelated kernel parameters can hide the real problem, reduce stability, or optimize one workload at the expense of another.

TuneD is a dynamic tuning service that applies coordinated settings for a particular workload or operating objective.

Common profiles may include:

• balanced for general-purpose systems.
• throughput-performance for sustained throughput.
• latency-performance for reduced response latency.
• powersave for lower energy consumption.
• virtual-guest or virtual-host for virtualization roles.

Typical administration commands are:

• tuned-adm list to display available profiles.
• tuned-adm active to show the active profile.
• tuned-adm recommend to obtain the recommended profile.
• tuned-adm profile PROFILE_NAME to activate a profile.
• tuned-adm verify to check whether the current system settings match the selected profile.
• tuned-adm off to disable profile-based tuning.

TuneD may adjust CPU governors, disk settings, kernel parameters, power-management options, and other subsystem controls. A profile should be selected according to measured workload needs, followed by benchmarking and verification rather than assuming that a profile's name guarantees better performance.

Linux scheduling behavior depends on the scheduling policy and its associated priority mechanism.

Nice values:

• Normal time-sharing processes commonly use policies such as SCHED_OTHER.
• Their nice value normally ranges from -20 to 19.
• A lower nice value gives the process a stronger preference for CPU time; a higher value makes it more willing to yield CPU time.
• nice -n 10 command starts a command with an adjusted nice value.
• renice 5 -p PID changes the nice value of an existing process.
• Ordinary users can generally increase their own processes' nice values but require privilege to set more favorable values.

Real-time policies:

• SCHED_FIFO and SCHED_RR use real-time priorities rather than nice values.
• chrt can inspect or change a process's real-time policy and priority.
• SCHED_FIFO runs a task until it blocks, yields, or is preempted by a higher-priority real-time task.
• SCHED_RR adds time slicing among tasks at the same real-time priority.

Incorrect real-time settings can starve ordinary processes and make a system unresponsive, so they require careful testing and appropriate privileges.

A POSIX Access Control List (ACL) extends the traditional permission model by allowing permissions to be assigned to additional named users and groups.

Traditional permissions provide only three classes:

• The file owner.
• One owning group.
• All other users.

ACLs add entries such as:

• user:alice:rw- for a named user.
• group:auditors:r-- for a named group.
• A mask that limits the effective permissions of named users, named groups, and the owning group.
• Default ACLs on directories, which provide inherited initial ACL entries for newly created children.

ACLs are useful when several users or groups need different levels of access but changing the owning group or creating many special-purpose groups would be inconvenient. The getfacl command displays ACLs, while setfacl creates, modifies, or removes them. ACLs supplement discretionary access control; they do not override read-only mounts, immutable attributes, or mandatory security controls such as SELinux.

The entries are interpreted as follows:

• Owner (user::rw-): Has effective rw-. The ACL mask does not restrict the file owner's entry.
• Named user alice (user:alice:rwx): The entry requests rwx, but the mask is r-x. Therefore, Alice's effective permissions are r-x; write permission is removed by the mask.
• Owning group (group::r--): The requested permission is r--. Intersecting it with the mask r-x leaves effective r--.
• Named group auditors (group:auditors:rw-): The entry requests rw-. Intersecting it with r-x leaves effective r--; write permission is masked out.
• Other users (other::---): Have no permissions. The mask does not apply to the other entry.

The mask represents the maximum effective permissions available to the owning group, named users other than the owner, and named groups. getfacl commonly displays an effective: annotation when an ACL entry is restricted by the mask.

Assuming /srv/shared already has suitable ownership and directory mode, access ACLs can be added with:

setfacl -m u:alice:rwX,g:auditors:r-X /srv/shared

Default ACLs for new child objects can be configured with:

setfacl -m d:u:alice:rwX,d:g:auditors:r-X /srv/shared

Key points:

• u:alice:rwX grants Alice read and write access and grants execute only where appropriate, such as on directories or already executable files.
• g:auditors:r-X grants the auditors group read access and directory traversal without making every regular file executable.
• The d: prefix creates default ACL entries. Default ACLs are valid only on directories.
• A directory's default ACL is used to calculate the initial ACL of newly created children, subject to the permissions requested by the creating program.
• Existing files do not automatically receive a newly added default ACL; they must be updated separately, potentially with a carefully reviewed recursive command.

Verification is performed with getfacl /srv/shared. A specific named entry can be removed with setfacl -x u:alice PATH, all default entries with setfacl -k DIRECTORY, and all extended ACL entries with setfacl -b PATH. The administrator must inspect the ACL mask because it can reduce the effective permissions of named users and groups.