Re: [lpi-examdev] LPIC-2 Objectives Review

[Justin Keller via lpi-examdev]

On Mon, Mar 7, 2022 at 11:18 AM Fabian Thorns via lpi-examdev
<lpi-examdev@list.lpi.org> wrote:
>
> 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?
I think SLAAC should be fully included. It is useful for IPv6, and
there are important points that should be known
>
> 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
Is arp covered in other LPIC exams?
>
> 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 <ftho...@lpi.org> 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 <ftho...@lpi.org> GPG: F1426B12
> > Director of Product Development, Linux Professional Institute
>
>
>
> --
> Fabian Thorns <ftho...@lpi.org> GPG: F1426B12
> Director of Product Development, Linux Professional Institute
> _______________________________________________
> lpi-examdev mailing list
> lpi-examdev@list.lpi.org
> https://list.lpi.org/mailman/listinfo/lpi-examdev
_______________________________________________
lpi-examdev mailing list
lpi-examdev@list.lpi.org
https://list.lpi.org/mailman/listinfo/lpi-examdev