I have a question about Zabbix. Zabbix is used for Linux, not Splunk or Kibana?
Sent with [Proton Mail](https://proton.me/) secure email.
------- Original Message -------
On Tuesday, October 24th, 2023 at 8:26 AM, Ricardo Prudenciato via lpi-examdev
<[email protected]> wrote:
> Hi all
>
> An update to LPIC-2 is really long awaited, especially to bring it closer to
> the current activities of professionals in the area.
>
> The coverage of Ansible will be very well received, we can discuss the
> weights, but I'm happy having it.
>
> Something that I would like to bring attention to is the fact that some items
> are also covered on LPIC-1, and sometimes it is hard to understand what is
> covered on LPIC-1 and what is on LPIC-2. Making this clear will help a lot
> the training partners and the professionals in their self-study.
>
> Here are some small items that I noted for 201:
>
> 201.1
> I think this topic has grouped too many areas and most of them are already
> somehow covered on 101 Topic 101, being difficult to understand what goes
> where and if we really need to cover this again on LPIC-2.
>
> 201.3
> GRUB Legacy is still mentioned and I don't see the need.
>
> 201.4
> I also don't see the need for this sub-topic. Maybe we should just move the
> most important things (like uefi secure boot) to 201.3
>
> 202.1
> Also many items already covered on LPIC-1 Topic 104, like identifying UUID,
> etc.
>
> 203.3
> I see that the coverage for BTRFS was removed, and now we only have the
> "basic feature knowledge" on LPIC-1
>
> Are you planning to increase the coverage for BTRFS on LPIC-1? Or should we
> have 203.3 covering BTRFS and ZFS.
>
> 204.
> Have you considered including some coverage of netplan? What do you think
> about it?
>
> 205.1
> I understand it's ok to keep basic compilation procedures with a weight 2
>
> 205.3
> It will be nice to include some of the most used monitoring tools like Zabbix.
>
> That's it for now.
>
> Thanks Fabian for putting this under discussion.
>
> Regards,
> Ricardo Prudenciato
>
> On Mon, Oct 23, 2023 at 11:28 PM Justin Keller via lpi-examdev
> <[email protected]> wrote:
>
>> On Mon, Oct 23, 2023 at 6:58 PM Alessandro Selli via lpi-examdev
>> <[email protected]> wrote:
>>>
>>> Hello.
>>>
>>> On 23/10/23 22:46, Dimitrios Bogiatzoules via lpi-examdev wrote:
>>>
>>> Hi!
>>>
>>> Am 23.10.23 um 20:25 schrieb Marc Baudoin via lpi-examdev:
>>>
>>> A weight of 2 for installations from source code is way too low
>>> because this is the heart and soul of free software (or open
>>> source).
>>>
>>> Remembering the days before Linux, system administrators*had* to
>>> build software from source code, having to modify it along the
>>> way because the author used a different kind of UNIX. System
>>> administrators also had to know C and the POSIX API for that.
>>> Since Linux has binary packages, the level of knowledge system
>>> administrators have about their system has dramatically dwindled
>>> and most of them don't understand correctly the basic tools
>>> provided by the system (I often see that about things as simple
>>> as redirects and pipes).
>>>
>>>
>>> Just being curious: if nowadays software is installed using packages, as
>>> you describe, why would an objetive about installing from the source
>>> deserve a bigger weight? As much as I understand the nostalgia, in
>>> contemporary environments, installing from the source is the absolute
>>> exception and in many cases organisations do not even allow other than
>>> specific repositories to be used.
>>>
>> So many scripts, packages, apps, etc do not have packages available.
>> Maybe the packages version has a config flag that turns off a feature
>> you need that is available if it's a source build or maybe you need to
>> compile it with specific flags for it to work--either at all or most
>> optimized. Also, security critical updates would be pushed first to
>> the source before going through the whole life cycle of package
>> management. Instead, installing from source can make it much easier...
>> though many times I find myself using cmskecfor it or a simple
>> ./configure with a flag or two, make && make install
>>> If anyone would ask my opinion, I'd drop objective 205.1 completely and
>>> give its weighting to backup, which deserves more.
>>>
>>>
>>> I agree.
>>> I would also put "201.4 Alternate Bootloaders (weight: 2)" on the cutting
>>> block.
>>> They are way too niche, dated and irrelevant to the 2020s professional use
>>> of Linux.
>>> Event the hardware is gone, except for network booting which can anyway be
>>> performed directly from the system firmware without any additional boot
>>> device.
>> I can't remember the last time I touched anything besides grub for
>> Linux specific
>>>
>>>
>>> Alessandro
>>>
>>> _______________________________________________
>>> 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
_______________________________________________
lpi-examdev mailing list
[email protected]
https://list.lpi.org/mailman/listinfo/lpi-examdev
