On Wed, Feb 9, 2022 at 2:11 PM Fabian Thorns via lpi-examdev <
[email protected]> wrote:

> 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.
>

Yeah, to take a first, simple crack at it, I'd probably have something like
(needs major refinement) ...


Topic 206:  System Maintenance
 ...
206.4: Configuration Management (weight: 2 ~ 4?)

Description: Candidates should be able to identify and execute pre-existing
Ansible, Chef and Puppet components and solutions to ensure a target server
is in a specific state regarding its configuration and installed software.

Key Knowledge Areas:

 - Basic feature and architecture knowledge of Ansible
 - Basic feature and architecture knowledge of Chef
 - Basic feature and architecture knowledge of Puppet

The following is a partial list of the used files, terms and utilities:

 - Inventory, Default/Variable, Task, Handler, Builtin
 - Recipe, Cookbook, Manifest, Class
 - ansible-playbook
 - chef-solo
 - puppet



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.
>

Like Configuration Management, probably should be limited to starting and
destroying premade instances, or things will quickly get out of hand.


-- 
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

Reply via email to