Build a Multi-User Development Environment

Every account on a Linux system is really three records that must agree. /etc/passwd holds the username, UID, primary GID, home, and shell. /etc/shadow holds the hashed password and aging fields. /etc/group maps group names to GIDs and lists supplementary members. The kernel only ever deals in numbers, the UID and GID, and the names are a convenience layered on top.

A user has exactly one primary group (set with -g, written into the passwd line and applied to every file the user creates) and any number of supplementary groups (set with -G, listed in /etc/group). That is why contractor1 uses -g contractors -G developers: its identity is contractor, but it also belongs to developers so it can reach the shared storage.

By default RHEL gives each new user a private group of the same name (User Private Groups). Here you override that by naming an existing group with -g, which is exactly what shared-project setups need so that files land in a common group. UIDs below 1000 are reserved for the system; regular users start at 1000, which is why the report script in Task 6 filters on that boundary.

chage edits the aging fields in /etc/shadow. The flags are easy to mix up: -M is the maximum days a password is valid, -m the minimum days between changes, -W the warning window before expiry, and -I the inactive grace period. Inactive is the subtle one: after the password expires, the account stays usable for that many days, then locks. So -M 90 -I 5 means the password dies at day 90 and the account locks at day 95.

System-wide complexity is enforced by pam_pwquality, configured in /etc/security/pwquality.conf and wired into the password stack in /etc/pam.d/system-auth. The credit values are counted in a confusing direction. A negative number is a hard requirement: ucredit = -1 means at least one uppercase letter is required. A positive number instead grants length credit for that class, which is not what you want for an exam policy. One caveat: root can override these rules when setting another user’s password, so always test enforcement as an unprivileged user.

The storage stack here is the standard LVM chain, physical volume, volume group, logical volume, filesystem, but the interesting part is the permission model. In a shared directory the usual problem is that each user creates files owned by their own primary group, so collaborators cannot edit each other’s work. The fix is the setGID bit on the directory.

chmod 2770 sets three things at once. The 7 gives the owning user full access, the second 7 gives the owning group full access, the 0 denies everyone else, and the leading 2 sets setGID. On a directory, setGID means every file and subdirectory created inside inherits the directory’s group rather than the creator’s primary group. It also propagates: a new subdirectory inherits both the group and the setGID bit, which is why /projects/shared and /projects/private pick up the developers group automatically.

Order matters. Set the group ownership with chown root:developers first, then chmod 2770, otherwise the setGID bit attaches to whatever group the directory happened to have.

Standard Unix permissions give you exactly three sets of rights: owner, one group, and everyone else. The moment two different groups need different access to the same directory, that model runs out of room. POSIX ACLs add named entries on top, so you can say developers get rwx and ops get r-x on the same folder.

A getfacl listing has a fixed grammar. user:: and group:: are the owning user and owning group (the same bits you see in ls -l). user:name: and group:name: are named entries. other:: is everyone else. The mask:: entry is a ceiling: it caps the effective permission of every named entry and the owning group, so if the mask is r-x a named rwx entry is effectively only r-x.

The key insight for this task is that developers is the owning group, so it is represented by the group:: entry that comes from the 2770 bits. You do not need a named group:developers ACL at all; you only add a named entry for ops. Finally, ACLs apply only to files that exist now. To make new files inherit the rules you set a default ACL with setfacl -d, which acts as a template for anything created later inside the directory.

A sudoers rule reads as four parts: who where = (run-as) what. So %developers ALL=(ALL) NOPASSWD: ALL means members of the developers group, on any host, may run any command as any user, without a password. The leading % is what makes it a group rule rather than a single user. The ops line lists explicit absolute command paths instead of ALL, which limits that group to exactly those binaries, and because it omits NOPASSWD it still prompts for the user’s own password.

Never edit /etc/sudoers by hand. The bottom of that file contains #includedir /etc/sudoers.d, so dropping a file there is the supported, modular way to add rules. Two hard requirements: the file must be mode 0440 or sudo refuses to read it, and the syntax must be valid or you can lock everyone out of sudo. visudo -f edits a drop-in with a syntax check on save, and visudo -c validates without opening an editor.

One RHEL 9 trap: use /usr/bin/systemctl, not /bin/systemctl. /bin is a symlink to /usr/bin, but sudo matches the command against the path it actually resolves, which is the /usr/bin form, so the /bin spelling can silently fail to match.

The reliable way to walk a colon-delimited file in bash is while IFS=: read -r f1 f2 f3 …. Setting IFS=: for the duration of read splits each line on colons, and -r stops backslashes from being interpreted. This is more robust than piping through cut or awk per field, and reading from /etc/passwd directly means the script always reflects the current user list instead of a hardcoded one.

Exit codes are the contract a script has with whatever runs it. 0 means success, anything else means failure. This script tests that it can write its report up front and exits 1 if not, so a cron job or systemd unit can detect the failure rather than silently producing nothing.

The last-login field is where the naive version breaks. The last command reads wtmp and, for a user who has never logged in, can return its footer line or empty fields, which a simple emptiness test does not catch and which prints a blank. lastlog is purpose-built for this: it prints the literal text Never logged in for such users, so the script can detect that case and print never cleanly.

This task deliberately uses both schedulers because they answer different questions. cron answers at what clock times. Its five fields are minute, hour, day-of-month, month, and day-of-week. The day-of-week field is a common slip: 0 and 7 both mean Sunday, 1 is Monday, so 0 6 * * 1 is six in the morning every Monday. A root crontab entry is per-user; system-wide jobs can instead live in /etc/cron.d.

systemd answers at what point in the boot and lifecycle. A Type=oneshot service runs a command to completion and then is considered done, which is right for a report generator. WantedBy=multi-user.target in the install section is what systemctl enable hooks into so the unit runs on every boot.

The ordering directive is worth understanding. network.target only means the network stack has been configured, not that it is actually reachable. To wait for real connectivity you order After=network-online.target and also pull it in with Wants=network-online.target, since the online target is not reached unless something asks for it.

RHEL runs two logging systems side by side. systemd-journald collects structured logs from every unit, and rsyslog reads from the journal and writes the traditional text files under /var/log. You configure them separately.

rsyslog routes messages using selectors of the form facility.priority. The facility names the source category and the priority names the severity. authpriv is the facility for authentication and privilege events, which is exactly where login and sudo activity lands, so authpriv.* captures all of it regardless of severity. Putting the rule in a drop-in under /etc/rsyslog.d keeps the main config clean, and rsyslog must be restarted to load it.

journald storage is the other half. By default the journal is volatile, kept in /run and wiped on reboot. Setting Storage=persistent moves it to /var/log/journal, but that directory must exist for persistence to take effect, which is why you create it explicitly. SystemMaxUse=400M caps how much disk the journal may consume so it cannot fill the partition.

A DNF repository is just a directory of packages plus metadata, described to the system by a small .repo file in /etc/yum.repos.d. The fields that matter are the section id in brackets (the short name DNF uses internally), name (a human label), baseurl (where the packages live), gpgcheck (whether to verify package signatures), and enabled. RHEL itself ships two main repos, BaseOS for the core operating system and AppStream for applications and development tools.

Disabling gpgcheck tells DNF to install without verifying signatures. That is acceptable for a trusted internal mirror in a lab, but on production you leave it on so a tampered package is rejected.

A package group is a named bundle, not a single package. Development Tools pulls in gcc, make, and the rest of the build chain in one step. Use dnf group list to see the exact names, since a misspelled group name simply reports nothing found. Always confirm with dnf repolist that your repo is visible before you try to install from it.

You could mount every developer home with a permanent /etc/fstab entry, but that mounts everything at boot whether or not anyone uses it, and it does not scale to dozens of nearly identical mounts. autofs mounts on demand and unmounts again after a period of inactivity, which is lighter and self-healing.

autofs is configured in two layers. The master map (here a drop-in under /etc/auto.master.d) says this mount point is managed by this map file. The map file then describes what to mount. An indirect map manages a set of subdirectories under one parent, which is what you want for per-user homes.

The wildcard is the elegant part. A key of * matches any subdirectory name someone tries to access, and & in the location is replaced by that same name. So one line, * -rw,sync fileserver:/devhomes/&, handles every user: touching /mnt/devhomes/dev1 mounts fileserver:/devhomes/dev1. Because the mount is created on access, listing the parent /mnt/devhomes shows nothing; you must reference a specific subdirectory to trigger it.

hostnamectl set-hostname writes the name to /etc/hostname, so it is the persistent way to rename a host. The older hostname command only changes the running value and is lost on reboot. systemd actually tracks three hostnames, static (the configured one), transient (a DHCP or runtime value), and pretty (a free-form label), but for the exam the static one set by hostnamectl is what counts. Adding the name to /etc/hosts lets the machine resolve its own fully-qualified name without depending on DNS, which some services expect.

Time on RHEL 9 is handled by chrony. You point it at a source with a server line in /etc/chrony.conf; the iburst option makes the first sync happen quickly by sending a short burst of probes. Comment out the default pool and server lines before adding your own so chrony is not also averaging in the shipped sources. chronyc sources shows the candidates, where a ^* marks the currently selected source, and chronyc tracking shows how closely the clock is disciplined. Timezone is separate from sync: timedatectl set-timezone repoints /etc/localtime at the right zone file.

The reboot is not a formality, it is the actual test. Almost every way to fail this kind of exam comes down to the same mistake: a setting that is correct in memory right now but was never written somewhere that survives a restart.

It helps to sort each task into one of two buckets. On-disk state persists by nature: an /etc/fstab line, ACLs stored in the filesystem, a sudoers drop-in, a script on disk, the contents of /etc/chrony.conf. Runtime state does not: a service you started but never enabled, a hostname set with the wrong command, an fstab you edited but never tested with mount -a.

The two verbs that catch most of it are enable (start at every boot) versus start (start right now), and daemon-reload so systemd actually reads a new unit file before you enable it. Reboot, then walk the checklist one line at a time. If something is missing, you know it was runtime-only, and you go back and make it persistent.