Agree completely
On 10/25/23 01:48, Alessandro Selli via lpi-examdev wrote:
On 24/10/23 18:29, BHL via lpi-examdev wrote:
I have a question about Zabbix. Zabbix is used for Linux, not Splunk
or Kibana?
As far as I know (I never used it), Splunk is a cloud-based,
web-managed platform for generic, machine-generated big-data analysis
and searching, reporting tool.
On https://www.splunk.com/en_us/download/splunk-cloud.html I can read
they offer a 14 days free cloud trial.
The software download page only offers Free Trial packages, except for
a "Universal Forwarder" package that "collects data securely from
remote sources, including other forwarders, and sends it into Splunk
software".
It is not just a platform monitoring tool.
I think LPI should not cover Cloud-based services that are not
available as free software, that do not have native packages in any
distribution that I know of, that are only accessible through a web
interface - which makes it not Linux-specific - that requires people
to send their data to a private, for-profit public company and that
requires that users have a paid account to be able to access it past
the two weeks of the free trial offering.
Kibana i read on the Wikipedia is proprietary, source-available
software that it too has no related packages in the repositories of
the Debian and Rocky Linux distributions.
It is a frontend for Elasticsearch, which is a "full-text search
engine with an HTTP web interface" (Wikipedia).
Which means that it is not just a platform monitoring tool, even
though of course it can also do that, that it is not Linux specific
and that is it is not free software. For these reasons i feel it
should not be mentioned in any LPI exam objective.
I feel we could at most add Zabbix to the the list of the universally
available free monitoring tools in Linux:
200.2 Predict Future Resource Needs (weight: 2)
Awareness of monitoring solutions such as Icinga2, Nagios, collectd,
MRTG and Cacti
but nothing more, as the list is already pretty beefy (even though
Nagios and Icinga2 are very similar).
Alessandro Selli
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
_______________________________________________
lpi-examdev mailing list
[email protected]
https://list.lpi.org/mailman/listinfo/lpi-examdev
--
Jeroen Baten | EMAIL :[email protected]
____ _ __ | web :www.i2rs.nl
| )|_)(_ | tel : +31 (0)648519096
_|_/_| \__) | Frisolaan 16, 4101 JK, Culemborg, the Netherlands
_______________________________________________
lpi-examdev mailing list
[email protected]
https://list.lpi.org/mailman/listinfo/lpi-examdev
