I'm going to limit to what I have not already given my (often biased, but disclaimed) opinions on ...
On Mon, Mar 7, 2022 at 11:18 AM Fabian Thorns via lpi-examdev < [email protected]> wrote: > Another huge change may regard the Linux kernel. I agree that it is > becoming less common to compile own kernels. With the exception of DKMS and > makeinitramfs, I would propose dropping objective 201.2 (Compiling a Linux > kernel) entirely. We could include initramfs and DKMS in 201.3 (Kernel > runtime management and troubleshooting). If we want to bring it one step > further, we could merge 201.1 (Kernel components) in there too and make the > result a new objective within topic 202 (System Startup). What do you think? > First off, kernel compression I've already covered, far more than I should have for LPI (but just wanted to point out some 'influences'). Secondly, 64-bit uEFI SecureBoot is here to stay, even on 'open system' ** Linux/aarch64 (ARMv8 and beyond) platforms, I'd rather focus on just the kernel aspects for boot-update. I really don't see any need for building one's own kernel and, at most, prepping the kernel for modules, except for embedded. But that's just me. I'm extremely biased, so my opinion should be ignored, and others considered of more value. **RANT: If Microsoft would stop screwing with the ODMs/OEMs to make them Windows-only, we'd have a viable, low-power, Linux/aarch64 'open system' ecosystem. In fact, with the sheer number of new NAND SSD, non-PCIe GPU and other interconnects/solutions that are Linux-only (native Windows support will always be impossible, and driver hacks for NT/Win64 are non-performant), there's no reason we shouldn't have Apple M1 Pro competitors in Linux/aarch64 notebooks. I really need to write an article on how Microsoft is killing 64-bit uEFI 'open system' ARMv8 platforms. > This one is probably the most controversial one... Docker. It is > important. It is a big topic. But is it LPIC-2? If we would include it, we > would have to add aspects of packaging (Dockerfiles), orchestration > (compose, k8s), security (rootless containers, the slirp4netns nightmare). > I find it hard to shape this in a way that it doesn't grow giant but still > is useful. I would rather recommend leaving Docker in the DevOps Tools > Engineer exam (for the user's perspective) and LPIC-305 (for the details). > But I agree, being able to check if a system runs containers is something > that is relevant for any admin. I would suggest adding launching a single > container and querying a list of running containers to LPIC-1 later. In > LPIC-2, however, I see the focus on administering full Linux systems and > the major network services. What do you think? > That's really all we can do in such a broad scope ... at least not without increasing LPIC-3 to yet three (3) exams. ;) I'm fine with Docker, but if I could make one suggestion ... we should limit ourselves to things in Docker that also run under Podman**. Yeah, I know, big Red Fedora bias. But, for the most part, nearly all common, basic Docker commands are the same in Podman. **LOGIC: As always, Red Hat likes to use existing solutions, until they are non-compliant or lacking features, and the Upstream (often with a new, 'commercial overlord' not-so-interested in open source, like after an acquisition) is unwilling to budge, hence Podman. ;) Shall we add some more NFSv4 features to 209.2? Or better keep them in > LPIC-303? > I'd really avoid opening up that can-o-worms. From the client-only aspect ... knowing the IDmap RPC service, possibly sec=sys v. sec=krb5[ip] and the GSSAPI RPC service is required, is the limit of what I'd do ... and that's still asking a lot. Network configuration... we have a lot of NetworkManager in LPIC-1, and it > seems people seldom use the command line to manage NetworkMananger. > Right now we see NetworkMananger, systemd-networkd and netplan. Is this > something we should keep on LPIC-1 level or address in LPIC-2, too? > RHEL8+ requires nmcli now, but that's not a valid reason for LPI. I'm mixed on this for LPIC-2, but I'd defer to 'skip,' for now. NetworkManager, or its CLI (nmcli), it isn't the only game in town. I defer to others. > firewalld seems to become more important. Should we include it as a > general tool? If we do, should we have a dedicated packet filtering > objective in topic 212 and bundle its aspects from 212.1 and 212.4 there? > What about testing actual use of nft? I am not seeing people use it > manually, the iptables wrappers still seem to be more popular. > RHEL8+ now uses nft-based firewalld, no longer iptables-based firewalld. The change is transparent. But just like NetworkManager, firewalld isn't the only game in town. I defer to others. To make matters worse, Google has been way, way behind on dynamic firewalls ... and is only now addressing some of them. Some topics were mentioned that are important for sure, but are currently > covered on LPIC-3 level: Namespaces, cgroups, SELinux / AppArmor, VLANs, > Bonding, cloud-init. Any votes to reconsider them for LPIC-2? > Namespaces, CGroups, et al. are really Containers, even before Docker, let alone LXC, even existed. Ergo, OpenShift was originally just Namespaces, CGroups and SELinux a dozen-plus years ago, and adopted Docker (later CGroupv2/Podman) and Kubernetes as they appeared. I think these are all advanced, low-level concepts that should remain in LPIC-3. SELinux/AppArmor can be limited to restoring contexts. 202.1: Remove SysV init aspects and increase systemd coverage (i.e. drop in > and override units, as well as systemctl) > Absolutely. On-the-job for the past 5 years, I've taught people how to do this. systemd timers is something I've been using far more now as well ... especially since it avoids the need for a 'run file,' unlike cron, that will glad fire of new instances, while the priors were already running. 202.2: Remove NVMe booting > 202.2/.3: Remove any GRUB Legacy aspects > 203.3: Remove mkisofs and CD-ROM aspects > 206.2: Add "Understanding of consistency in backups, i.e. for databases" > 206.2: Remove Amanda and Bacula > 207.1: Remove djbdns and add unbound on awareness level > All agreed. We could use the room, and most of these are not used much in the field ... other than NVMe becoming common-place, but little different. 207.1: /var/named/ is distro-specific, remove it > 207.2: Remove creation of root.hints > 207.2: Remove nslookup > 207.1: /var/named/ is distro-specific, remove it > 207.3: Remove chroot for BIND > A couple of these are Red Hat'isms, and I'm fine with removing Red Hat'isms. > 208.1: Remove mod_perl and PHP configuration > 208.1: Add HTTP2 > 208.2: Remove CA.pl > 208.2: Remove SNI specialties > 208.2: Remove client certificate options > 209.1: Remove Samba Share-Level security > 209.1: Remove nmblookup > 209.1: Add samba (the process) and wbinfo > 210.1: Remove arp > 210.4: Remove Whitepages > 211.1: "Understand the concepts of email spoofing protection, i.e. SPF, > DKIM and DMARC" > 212.3: Remove 'Protocol' > 212.4: Remove 'Locations and organisations that report security alerts as > Bugtraq, CERT or other sources' > In general: > - Remove paths to commands and configuration files wherever possible > - Remove net-tools in the favor of iproute2 > I agree with all these. All legacy net-tools (like arp) probably should be removed. Most vendors now link to CERT et al. too. -- Bryan J Smith - http://www.linkedin.com/in/bjsmith E-mail: b.j.smith at ieee.org or me at bjsmith.me
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
