Dear all, it seems I'm finally allowed to step in and summarize all your proposals. But first of all, thanks for sharing all your thoughts! I did my very best to include them all into this email so that we can decide the major changes and get into the details. If I've forgotten anything, please feel free to bring it up again.
>From what I've read, I think there are some conclusions we all agree upon: - Configuration automation is mandatory - We should make sure that the exam stays a Linux engineering exam so that our candidates fully understand what they automate - We should not add too many "Awareness of" topics to ensure we have enough meat on the bones for proper training - If we want to test the actual use of any of the configuration management tools, it would be Ansible - Candidates may encounter other automation tools, and might actually like some of them more than Ansible; although we can't go into the details of all of them. For me, this leads to a proposal similar to the architecture in the DevOps Tools Engineer objectives: One rather brief objective about the various approaches and existing tools (similar to 704.2, but with some more conceptual aspects like pull vs. push / agent-based vs. agent-less), as well as another objective about practical Ansible, similar to 704.1 (although probably with fewer weight). I would however go beyond just executing existing roles and playbooks and maybe cover package installation, SSH key distribution, copying files and simple line changes in a file. That would be enough to get the idea and follow up using the docs. Regarding the architecture, I would put these objectives into 201, because they are more focussed on administering a specific node instead of configuring network services. Beyond LPIC-2, I'd suggest removing Ansible from the DevOps Tools Engineer exam to shift its focus more towards containers. 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? Topic 200 is also worth a closer look. I think we should definitely reduce its weight (maybe to 4?) and add awareness of Prometheus. I am also unsure whether to propose merging 200.2 into 200.1... any comments? 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? Then there is a list of medium size considerations: What do you think about additional file systems in 203? 206.2, any more opinions on rclone? Shall we add certbot and Let's Encrypt to 208.2? Alternatively, we could consider having one Apache HTTPD and another NGINX objective and finally a HTTPS / TLS objective focussing on certificate procurement and enabling it in both servers. What's your ideal vision of Apache HTTPD/NGINX coexisting (assume, Squid disappears from the exam)? Shall we add some more NFSv4 features to 209.2? Or better keep them in LPIC-303? Shall we rename 210.1 to "Automated Network Configuration" and include full coverage of IPv6 SLAAC and DHCPv6? What do you think about Kea? Both SUSE and Red Had have replaced OpenLDAP with 389 DS. Shall we do the same in 210.4 ? Shall we add ssh-ca to 212.3 or keep it in LPIC-3? 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? 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. wireguard... uhm. In my opinion there are a lot of misconceptions about it. It may be great for certain use cases, but it lacks significant functionally compared to OpenVPN (which is certainly by design, but it is often considered a complete replacement). Maybe add awareness to 212.5? Same for IPsec? 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? I would refrain from adding contents in order to support their adoption. Imho, we should try to reflect what is currently used in the field (which doesn't mean we shouldn't lobby for good open source alternatives wherever we can). Then there are two topics which are (imho) due to be removed: 208.3 (Squid) 212.2 (FTP) I'm not sure about 202.3, though. Maybe move PXE as awareness closer to DHCP and drop the rest? And then there is the list of smaller change considerations we've collected in the wiki. A lot of them were also mentioned on the list. I've merged them into the following list of stuff I think we can just rubber stamp (again, feel free to object to any of these): 202.1: Remove SysV init aspects and increase systemd coverage (i.e. drop in and override units, as well as systemctl) 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 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 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 think this was it so far. Sorry if I've forgotten something, please feel free to add anything back. And please object to anything you consider questionable, this email is just a summary, nothing is set in stone yet. As you start commenting on this summary, I will start working the comments into a draft for the new objectives. Fabian On Wed, Feb 9, 2022 at 8:10 PM Fabian Thorns <[email protected]> wrote: > > Dear all, > > I hope the new year started off well for you. We do have quite a few > development projects to tackle this year, one of them is the > objectives review of LPIC-2. We will also review the DevOps Tools > Engineer this year, but we should get started with LPIC-2 first. > However, already considering potential changes to the DevOps Tools > Engineer while adjusting LPIC-2 is important to ensure our overall > program stays consistent. > > Let’s go! > > The current objectives are on the wiki: > > https://wiki.lpi.org/wiki/LPIC-2_Objectives_V4.5 > > The page already contains some future change considerations, including > some contents that will likely be removed from the exam. But please > feel free to bring up *any* aspect you’d like to discuss. This > explicitly includes weight changes if you feel some topics should be > tested at another level. > > However, there are two rather general concerns that I would like to > point out explicitly: One of them is configuration automation. Manual > administration is clearly often not the preferred way to administer > systems, so it might be a good idea to include some portions of it in > LPIC-2. We do already have a topic on this in the DevOps Tools > Engineer (topic 704, 10 weights in total!) which may serve as a > baseline for a similar topic in LPIC-2. > > Another trend is containerization. This is a thin line, since the LPIC > track is still closely aligned to system administration, while Podman, > Docker, et. al. include far more aspects, like application packaging, > building tools. Adding these topics in detail to LPIC would require a > lot of room and actually change the program’s characteristics. > > However, we still have the DevOps Tools Engineer exam, which is due > for review in 2022, too. If (!) we decide to add configuration > automation to LPIC-2, we would be able to turn the DevOps Tools > Engineer more towards a container focused exam. The focus would rather > lean towards cloud native technologies and the intersection of system > and software engineering, while LPIC-3 would focus on the lower level > aspects of the related technologies. > > I think this idea is worth a thought for various reasons: We would get > an up to date LPIC-2, addressing mastery of Linux, with the most > recent tools, as well as another certification addressing the now > commonly used ‘cloud native stack’ (for the lack of a better word), > with the latter being available without prerequisites to anyone doing > cloud native development. The new DevOps Tools Engineer would contain > less topics, be more focused and hence be more attractive than the > current version; LPIC-2 would be freed from some legacy/now less > important topics (I cannot imagine FTP and Squid surviving the review > (feel free to prove me wrong :)) and include configuration automation > while still covering what’s going on under the hood (again, feel free > to prove me wrong). > > Looking forward to your thoughts, > > Fabian > > -- > Fabian Thorns <[email protected]> GPG: F1426B12 > Director of Product Development, Linux Professional Institute -- Fabian Thorns <[email protected]> GPG: F1426B12 Director of Product Development, Linux Professional Institute
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
