Hello As watching the opinion on ML, my idea is:
- Ansible is in the category of DevOps. If included, it must be ansible. I haven’t see puppet and chef more than 6 years. - bzip2 is still needed but mainly xz is popular. One of useful command is pxz. It supports multi-core/ parallel compress execution. - How about including ‘cloud-init’? It has already been the objectives at DevOps. But the knowledge of Cloud-init will be useful if the user uses on-premis Linux or Cloud-based like EC2 linux. - Docker/Container knowledge is required. Just for the beginner’s knowledge. Professional knowledge is in DevOps Tools Engineer. Regards, Kenji Okada > 2022/02/12 3:06、Ricardo Prudenciato via lpi-examdev > <[email protected]>のメール: > > > Hey guys, > > Here are my thoughts that I believe should be considered: > > To be included: > - Some level of coverage, at least awareness, for open source monitoring > tools that are most used today, like Prometeus and Zabbix. > - Netplan, due your common use on Ubuntu servers. > - Ansible, as already mentioned. > - Docker basics, but I believe that should be more at LPIC-1 than LPIC-2 > > To be increased: > - Network Manager > - NGINX > > To be removed: > - GRUB Legacy references that can be seen on 201.2 and 201.3. Keep the focus > on GRUB 2. > - CD-ROM filesystems and extensions > - ARP commands > - Remove 206.3 (keep it only on LPIC-1) > > To be reduced: > - Modules coverage, specially on 201.2 and 201.3 > - Kernel compilation and installation procedures, specially about applying > patches and versioning details > - SysInit coverage > - Apache (modules, mod_*). Less Apache, More NGINX > - SAMBA - Cover the essentials but keep the details on LPC-3 > > > That is it. > Regards, > Ricardo Prudenciato > > > > On Fri, Feb 11, 2022 at 1:11 PM Bryan Smith via lpi-examdev > <[email protected] <mailto:[email protected]>> wrote: > Being of blatantly clear Red Fedora bias, I'm hardly against such. ;) > > I just wanted to seem neutral and included Chef and Pupet. But if we pick > only one (1) tool, then I'd agree, Ansible ... and possibly tucked under SSH > instead of a new Sub-Objective for Configuration Management. > > I leave it to others to decide, but I'd limit the scope to running existing > Playbooks, and how to identify/use existing Inventory files with existing > Defaults/Variables, Tasks and Handlers. > > As always, my very opinionated $0.02 / €0.018. ;) > > - bjs > > On Fri, Feb 11, 2022 at 6:49 AM Éric Deschamps via lpi-examdev > <[email protected] <mailto:[email protected]>> wrote: > Hello, > > Le 11/02/2022 à 11:51, Eden Caldas via lpi-examdev a écrit : > > Hi > > > > Hi. I don't think LPIC-2 should dive too deep into this. As you said, > > There's the devtools exam. Linux exam should be about Linux. > > > > If you really want to add some automation, don't add all 3 of the main > > ones, again we have the DevOps exam for that. Add Ansible only. It's the > > best choice because it uses other mechanisms common to the Linux > > environment (SSH). > > > I agree with that. > > You might also keep in mind that it would be hard to add ansible + chef > + pupett in an exam training. Or it would be training without practice, > which does not make sense. > > Have a nice day, > > Eric > > > > > My 2 cents. > > > > On Thu, 10 Feb 2022, 01:47 Bryan Smith via lpi-examdev > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > On Wed, Feb 9, 2022 at 2:11 PM Fabian Thorns via lpi-examdev > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > The current objectives are on the wiki: > > https://wiki.lpi.org/wiki/LPIC-2_Objectives_V4.5 > > <https://wiki.lpi.org/wiki/LPIC-2_Objectives_V4.5> > > <https://wiki.lpi.org/wiki/LPIC-2_Objectives_V4.5 > > <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 > > <http://www.linkedin.com/in/bjsmith> > > <http://www.linkedin.com/in/bjsmith > > <http://www.linkedin.com/in/bjsmith>> > > E-mail: b.j.smith at ieee.org <http://ieee.org/> <http://ieee.org > > <http://ieee.org/>> or me at > > bjsmith.me <http://bjsmith.me/> <http://bjsmith.me <http://bjsmith.me/>> > > > > _______________________________________________ > > lpi-examdev mailing list > > [email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > https://list.lpi.org/mailman/listinfo/lpi-examdev > > <https://list.lpi.org/mailman/listinfo/lpi-examdev> > > <https://list.lpi.org/mailman/listinfo/lpi-examdev > > <https://list.lpi.org/mailman/listinfo/lpi-examdev>> > > > > > > _______________________________________________ > > lpi-examdev mailing list > > [email protected] <mailto:[email protected]> > > https://list.lpi.org/mailman/listinfo/lpi-examdev > > <https://list.lpi.org/mailman/listinfo/lpi-examdev> > > > _______________________________________________ > lpi-examdev mailing list > [email protected] <mailto:[email protected]> > https://list.lpi.org/mailman/listinfo/lpi-examdev > <https://list.lpi.org/mailman/listinfo/lpi-examdev> > > -- > > -- > Bryan J Smith - http://www.linkedin.com/in/bjsmith > <http://www.linkedin.com/in/bjsmith> > E-mail: b.j.smith at ieee.org <http://ieee.org/> or me at bjsmith.me > <http://bjsmith.me/> > > _______________________________________________ > lpi-examdev mailing list > [email protected] <mailto:[email protected]> > https://list.lpi.org/mailman/listinfo/lpi-examdev > <https://list.lpi.org/mailman/listinfo/lpi-examdev>_______________________________________________ > lpi-examdev mailing list > [email protected] > https://list.lpi.org/mailman/listinfo/lpi-examdev
_______________________________________________ lpi-examdev mailing list [email protected] https://list.lpi.org/mailman/listinfo/lpi-examdev
