The previous chapter covered active styling. This chapter covers the mechanism that makes a single route component serve multiple URLs: the path parameter. A path parameter is a dynamic segment in the route’s path, marked with a colon prefix (:id). The router matches any single URL segment to the parameter, and the component reads the…
The previous chapter covered navigation with the <Link> and <NavLink> components. This chapter focuses specifically on the active state: how the router determines that the current URL matches a link, how the <NavLink> exposes that state to the component, and the different patterns for styling the active link. The LFCS exam does not test React…
The previous chapters covered backup strategies and the tools that create the backups: tar and rsync. This chapter covers the reverse operation: the restore. A backup that has never been restored is a backup that might not work. The restore is not a single command; it is a sequence of decisions that determine whether the…
The previous chapter covered tar as the archiver for backups. This chapter covers rsync, which is the synchronization tool for backups. The distinction matters: tar produces a single archive file that must be extracted to be useful. rsync produces a mirror of the source directory that is immediately usable. The LFCS exam tests the rsync…
The previous chapter covered the conceptual backup strategies: the 3-2-1 rule, the RPO and RTO, and the distinction between full, incremental, and differential backups. This chapter covers the practical tool that implements those strategies on Linux: tar (Tape ARchive). Despite the name, tar is not just for tapes. It is the standard archiver for Linux,…
The previous chapters covered security and monitoring. This chapter shifts the focus to disaster recovery: the principles of backup that determine whether the data survives a disk failure, a ransomware attack, an accidental deletion, or a natural disaster. The LFCS exam tests the conceptual model: the 3-2-1 rule, the distinction between full, incremental, and differential…
The previous chapter covered AppArmor, which confines applications using path-based profiles. This chapter covers the system-wide audit framework: the kernel component that records security-relevant events and the auditd daemon that writes them to disk. Unlike AppArmor, which blocks actions, auditd observes and records. It does not prevent a file from being read; it records who…
The previous chapter introduced AppArmor’s conceptual model: path-based profiles attached to executables, with two enforcement modes. This chapter focuses on the practical mechanics of the profile files themselves and the operational workflow of switching between enforce and complain mode, reloading profiles after edits, and using the tooling to iterate on profile development. The LFCS exam…
The previous chapters covered SELinux, which is the default Mandatory Access Control (MAC) system on RHEL-family distributions. This chapter introduces AppArmor, which is the default MAC system on Ubuntu and SUSE. Both systems enforce a security policy that sits behind the traditional Unix permissions, but they use fundamentally different models. SELinux uses inode-based labels and…
The previous chapters covered the SELinux modes, contexts, and booleans. This chapter covers the workflow for diagnosing an access denial. An application fails, the logs show a denial, and the administrator must decide whether the cause is a mislabeled file, a boolean that needs to be toggled, a port that is not permitted, or a…