The previous chapters covered the GitLab UI, the CI/CD pipeline, and the access control model. This chapter covers the mechanisms that allow external systems to interact with GitLab programmatically: webhooks, which push events to an external URL, and the REST/GraphQL API, which allows an external system to query and modify GitLab resources. The LFCS exam…
The previous chapters covered the CI/CD pipeline and its security scanners. This chapter covers the permission model that governs who can do what within a project. GitLab’s access control is built on roles: Guest, Reporter, Developer, Maintainer, and Owner. Each role is a bundle of permissions. The exam tests the distinction between the roles, the…
The previous chapters covered process monitoring with top and htop, and system-wide metrics with vmstat and iostat. This chapter covers two smaller, focused commands that answer two of the most common questions: free, which reports the memory usage, and uptime, which reports the system load average and uptime. Both commands are part of the procps…
The previous chapter covered process monitoring with top and htop, which show the CPU and memory usage of individual processes. This chapter covers the system-wide monitoring tools that reveal the aggregate state of memory, swap, I/O, and CPU: vmstat and iostat. These tools answer a different question. top answers “which process is using the CPU?”…
The previous chapters covered logs and their rotation. This chapter covers real-time process monitoring: the top command, which is available on every Unix-like system, and htop, which is the enhanced interactive alternative. Both tools show a snapshot of the running processes, updated at a configurable interval. The LFCS exam tests the interpretation of the top…
The previous chapter covered the rsyslog configuration: the rules that write messages to text files under /var/log/. This chapter covers the mechanism that prevents those files from growing indefinitely. The logrotate command is a scheduled utility that rotates, compresses, removes, and mails log files. It is not a daemon; it is a process invoked by…
The systemd journal is the default log store on modern Linux distributions, but it is not the only one. The rsyslog daemon runs alongside the journal and writes traditional text files to /var/log/. It is the mechanism that produces /var/log/syslog, /var/log/auth.log, /var/log/messages, and /var/log/kern.log. The LFCS exam tests the configuration syntax of /etc/rsyslog.conf, the rule…
Intro The React & Modern UI Stack path covers the essential frontend ecosystem and modern tooling roadmap, built directly on top of the Core Web Stack foundation. Tutorials
The previous chapter introduced the journalctl command and its basic filtering options. This chapter goes deeper into the filtering syntax and the persistence configuration. The LFCS exam tests the _FIELD matching, the –grep option, the -o output format, the boot-time filtering, and the journald.conf settings that control whether logs survive a reboot. The critical distinction…
The previous chapters covered shell scripting and its debugging mechanisms. This chapter returns to system administration: the journalctl command, which is the interface to the systemd journal. Unlike traditional text-based log files (/var/log/syslog, /var/log/messages), the journal is a binary store. It is not read with cat, grep, or less directly. The journalctl command is the…