From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH v3 1/5] zabbix_agentd: Update to v5.0.20 (LTS)
Date: Sun, 20 Feb 2022 18:10:17 +0000
Message-ID: <145C4468-1A65-4132-8831-BA33F674287F@ipfire.org>
In-Reply-To: <7690c72ee6cc9f3ddc2a2b45258b94bd3ed0bc83.camel@sicho.home>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4437195825686341852=="
List-Id: <development.lists.ipfire.org>

--===============4437195825686341852==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hello Robin,

> On 16 Feb 2022, at 23:35, Robin Roevens <robin.roevens(a)disroot.org> wrote:
>=20
> Hi Michael
>=20
> Michael Tremer schreef op di 15-02-2022 om 13:22 [+0000]:
>> Hello Robin,
>>=20
>> Thank you for working on Zabbix and integrating it better into
>> IPFire.
>>=20
>> I am very happy with this, but I have my reservations about the
>> mechanism with the =E2=80=9Cnew=E2=80=9D configuration file. I do not quit=
e see the
>> necessity for this since we have a package management system which
>> will allow you to start again from scratch if you want by
>> uninstalling the package, throwing away the backup and then
>> installing the package again.
>>=20
>> It would also create some unique feature around one package, but not
>> for others which is probably more confusing than helpful.
>>=20
>> What is your motivation for this?
>=20
> I do understand your concerns and agree that handling the config of
> this pak differently than configs of other paks is bothersome.
>=20
> However, I understand now that you can start over by removing the
> package and the backup but up until I started contributing, I never
> knew the config of an addon was backed up automatically on uninstall
> and restored on re-install. I would have expected that if I didn't find
> the config anymore after an uninstall it would be gone and a re-install
> would give me a fresh config. So I would probably be utterly confused
> if I found my old config back after a re-install.=20
> Is this documented somewhere where I could have known this behaviour as
> a normal average user ?

The reason why pakfire is doing this is because it is simply a wrapper around=
 tar. It is not that sophisticated of a package management system because it =
wasn=E2=80=99t designed for this scale.

In order to avoid overwriting any existing configuration, we backup everythin=
g, extract the new package which will then overwrite the existing configurati=
on files and then restore the backup to have the old configuration again. We =
could have built something that avoids overwriting the files in the first pla=
ce which is what pakfire in IPFire 3 does.

Lots of other distributions work in a similar way where they rename the exist=
ing configuration files and might rename them back again.

> The problem I'm having with the current way is that when an addon is
> updated, a new version of the config is just discarded due to the
> restore of the previous config during install (even if that config was
> never changed by the user).
> So if settings in the config are added, deprecated or even no longer
> valid, the user will never know until a version would no longer start
> up or no longer behave as expected due to the old config.
> And even if a user would think about checking config changes on an
> update he would have to go search the internet for a config example for
> this version of the addon.

Yes, this is a huge problem for us all. The question there is to answer is:

  Do we know better than the user?

Answering that with a yes means that we would make decisions on their behalf =
and that might potentially go wrong. Answering that with a no means that the =
user needs to invest a lot of time into the configuration of each part of the=
 distribution and the reason why we have a nice shiny web user interface is t=
hat they don=E2=80=99t have to do this. The correct answer is probably somewh=
ere in the middle.

What we do in practise is: We keep systems consistent with their previous beh=
aviour. An update should never change that (there are of course exceptions to=
 every rule). New features might only be activated on new systems.

> In this specific case, as we update from a rather old version of zabbix
> agent, there are quite a few interesting config changes that can harden
> the security of the agent, which I would not want the user to miss out
> on. Also one option is deprecated, is currently still supported, but in
> the next version it probably will no longer work, possibly breaking
> some users' monitoring or causing the agent to fail starting.

Is this an add-on that generally requires configuration on the console?

We do we not build a page on the web UI for this so that people can enable th=
e things they want? Would that be overkill for the possible options?

> For the sudoers file it is even more problematic; the user can of
> course modify that file to add additional commands he requires the
> agent to execute as root, but possible future additions to the ipfire
> specific monitoring that I or other contributors in the future may add,
> may also need extra commands in that file to work. (for example the
> upcoming services monitoring that would require some form of addonctrl
> status)
> But I can't update that file with the current behaviour.. or I would
> have to try to implement some sed magic after the restore in install.sh
> hoping not to damage the file if it has user customizations in it.

This is not a configuration file in my eyes. It technically is one of course,=
 but we call these files a =E2=80=9Csystem configuration file=E2=80=9D. It wi=
ll be overwritten because what is in it is necessary for the system to work. =
It does not contain any choices by the user at all.

For that reason, this file should not be backed up and overwritten by every p=
ackage update.

> So I'm not sure on how to handle this differently at the moment.
> I was thinking for the main config maybe just installing a ".example"
> version of the latest config so that a user would not have to go search
> for it on internet ? And in that case even remove all comments and
> defaults from the actual config (on a fresh install) as that is then
> provided in the ".example" version as documentation.=20

Having some example configuration in a location the user would normally not l=
ook at is probably not helpful.

If you want them to configure things themselves, why not provide good documen=
tation on the wiki?

> But that still leaves the sudoers file. The only other possibility I
> see there is that we don't add this file to the backup and add a
> comment in it that a user should not modify it as it will get
> overwritten on update. He can then always still create his own sudoers-
> file with his own custom rights for the agent.

This is the way to go. In many cases, we have extra files that end on =E2=80=
=9C.user=E2=80=9D or =E2=80=9C.local=E2=80=9D to make it clear that users sho=
uld make their own changes here.

> Of course all this can be solved by managing the config using the
> webgui.. and I'm still planning to create a webgui config page for the
> agent someday. But we are not there yet :-)

-Michael

>=20
> Regards
>=20
> Robin
>=20
>>=20
>> -Michael
>>=20
>>> On 9 Feb 2022, at 23:26, Robin Roevens <robin.roevens(a)disroot.org>
>>> wrote:
>>>=20
>>> - Update from 4.2.6 to latest LTS version 5.0.20
>>>  See release notes: https://www.zabbix.com/rn/rn5.0.20
>>>=20
>>> Signed-off-by: Robin Roevens <robin.roevens(a)disroot.org>
>>> ---
>>> config/zabbix_agentd/zabbix_agentd.conf | 135
>>> ++++++++++++++++++++++--
>>> lfs/zabbix_agentd                       |  11 +-
>>> 2 files changed, 132 insertions(+), 14 deletions(-)
>>>=20
>>> diff --git a/config/zabbix_agentd/zabbix_agentd.conf
>>> b/config/zabbix_agentd/zabbix_agentd.conf
>>> index 21b8e0122..aa8b899dc 100644
>>> --- a/config/zabbix_agentd/zabbix_agentd.conf
>>> +++ b/config/zabbix_agentd/zabbix_agentd.conf
>>> @@ -63,14 +63,33 @@ LogFileSize=3D0
>>> # Default:
>>> # SourceIP=3D
>>>=20
>>> -### Option: EnableRemoteCommands
>>> -#      Whether remote commands from Zabbix server are allowed.
>>> -#      0 - not allowed
>>> -#      1 - allowed
>>> +### Option: AllowKey
>>> +#      Allow execution of item keys matching pattern.
>>> +#      Multiple keys matching rules may be defined in combination
>>> with DenyKey.
>>> +#      Key pattern is wildcard expression, which support "*"
>>> character to match any number of any characters in certain
>>> position. It might be used in both key name and key arguments.
>>> +#      Parameters are processed one by one according their
>>> appearance order.
>>> +#      If no AllowKey or DenyKey rules defined, all keys are
>>> allowed.
>>> +#
>>> +# Mandatory: no
>>> +
>>> +### Option: DenyKey
>>> +#      Deny execution of items keys matching pattern.
>>> +#      Multiple keys matching rules may be defined in combination
>>> with AllowKey.
>>> +#      Key pattern is wildcard expression, which support "*"
>>> character to match any number of any characters in certain
>>> position. It might be used in both key name and key arguments.
>>> +#      Parameters are processed one by one according their
>>> appearance order.
>>> +#      If no AllowKey or DenyKey rules defined, all keys are
>>> allowed.
>>> +#       Unless another system.run[*] rule is specified
>>> DenyKey=3Dsystem.run[*] is added by default.
>>> #
>>> # Mandatory: no
>>> # Default:
>>> -# EnableRemoteCommands=3D0
>>> +# DenyKey=3Dsystem.run[*]
>>> +
>>> +### Option: EnableRemoteCommands - Deprecated, use
>>> AllowKey=3Dsystem.run[*] or DenyKey=3Dsystem.run[*] instead
>>> +#      Internal alias for AllowKey/DenyKey parameters depending on
>>> value:
>>> +#      0 - DenyKey=3Dsystem.run[*]
>>> +#      1 - AllowKey=3Dsystem.run[*]
>>> +#
>>> +# Mandatory: no
>>>=20
>>> ### Option: LogRemoteCommands
>>> #       Enable logging of executed shell commands as warnings.
>>> @@ -177,6 +196,28 @@ ServerActive=3D127.0.0.1
>>> # Default:
>>> # HostMetadataItem=3D
>>>=20
>>> +### Option: HostInterface
>>> +#      Optional parameter that defines host interface.
>>> +#      Host interface is used at host auto-registration process.
>>> +#      An agent will issue an error and not start if the value is
>>> over limit of 255 characters.
>>> +#      If not defined, value will be acquired from
>>> HostInterfaceItem.
>>> +#
>>> +# Mandatory: no
>>> +# Range: 0-255 characters
>>> +# Default:
>>> +# HostInterface=3D
>>> +
>>> +### Option: HostInterfaceItem
>>> +#      Optional parameter that defines an item used for getting
>>> host interface.
>>> +#      Host interface is used at host auto-registration process.
>>> +#      During an auto-registration request an agent will log a
>>> warning message if
>>> +#      the value returned by specified item is over limit of 255
>>> characters.
>>> +#      This option is only used when HostInterface is not defined.
>>> +#
>>> +# Mandatory: no
>>> +# Default:
>>> +# HostInterfaceItem=3D
>>> +
>>> ### Option: RefreshActiveChecks
>>> #       How often list of active checks is refreshed, in seconds.
>>> #
>>> @@ -265,7 +306,6 @@ ServerActive=3D127.0.0.1
>>>=20
>>> Include=3D/etc/zabbix_agentd/zabbix_agentd.d/*.conf
>>>=20
>>> -
>>> ####### USER-DEFINED MONITORED PARAMETERS #######
>>>=20
>>> ### Option: UnsafeUserParameters
>>> @@ -299,7 +339,7 @@
>>> Include=3D/etc/zabbix_agentd/zabbix_agentd.d/*.conf
>>> #
>>> # Mandatory: no
>>> # Default:
>>> -# LoadModulePath=3D/usr/lib/modules
>>> +# LoadModulePath=3D${libdir}/modules
>>>=20
>>> LoadModulePath=3D/usr/lib/zabbix
>>>=20
>>> @@ -357,14 +397,14 @@ LoadModulePath=3D/usr/lib/zabbix
>>> # TLSCRLFile=3D
>>>=20
>>> ### Option: TLSServerCertIssuer
>>> -#      Allowed server certificate issuer.
>>> +#              Allowed server certificate issuer.
>>> #
>>> # Mandatory: no
>>> # Default:
>>> # TLSServerCertIssuer=3D
>>>=20
>>> ### Option: TLSServerCertSubject
>>> -#      Allowed server certificate subject.
>>> +#              Allowed server certificate subject.
>>> #
>>> # Mandatory: no
>>> # Default:
>>> @@ -397,3 +437,80 @@ LoadModulePath=3D/usr/lib/zabbix
>>> # Mandatory: no
>>> # Default:
>>> # TLSPSKFile=3D
>>> +
>>> +####### For advanced users - TLS ciphersuite selection criteria
>>> #######
>>> +
>>> +### Option: TLSCipherCert13
>>> +#      Cipher string for OpenSSL 1.1.1 or newer in TLS 1.3.
>>> +#      Override the default ciphersuite selection criteria for
>>> certificate-based encryption.
>>> +#
>>> +# Mandatory: no
>>> +# Default:
>>> +# TLSCipherCert13=3D
>>> +
>>> +### Option: TLSCipherCert
>>> +#      GnuTLS priority string or OpenSSL (TLS 1.2) cipher string.
>>> +#      Override the default ciphersuite selection criteria for
>>> certificate-based encryption.
>>> +#      Example for GnuTLS:
>>> +#              NONE:+VERS-TLS1.2:+ECDHE-RSA:+RSA:+AES-128-
>>> GCM:+AES-128-CBC:+AEAD:+SHA256:+SHA1:+CURVE-ALL:+COMP-NULL:+SIGN-
>>> ALL:+CTYPE-X.509
>>> +#      Example for OpenSSL:
>>> +#              EECDH+aRSA+AES128:RSA+aRSA+AES128
>>> +#
>>> +# Mandatory: no
>>> +# Default:
>>> +# TLSCipherCert=3D
>>> +
>>> +### Option: TLSCipherPSK13
>>> +#      Cipher string for OpenSSL 1.1.1 or newer in TLS 1.3.
>>> +#      Override the default ciphersuite selection criteria for
>>> PSK-based encryption.
>>> +#      Example:
>>> +#              TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
>>> +#
>>> +# Mandatory: no
>>> +# Default:
>>> +# TLSCipherPSK13=3D
>>> +
>>> +### Option: TLSCipherPSK
>>> +#      GnuTLS priority string or OpenSSL (TLS 1.2) cipher string.
>>> +#      Override the default ciphersuite selection criteria for
>>> PSK-based encryption.
>>> +#      Example for GnuTLS:
>>> +#              NONE:+VERS-TLS1.2:+ECDHE-PSK:+PSK:+AES-128-
>>> GCM:+AES-128-CBC:+AEAD:+SHA256:+SHA1:+CURVE-ALL:+COMP-NULL:+SIGN-
>>> ALL
>>> +#      Example for OpenSSL:
>>> +#              kECDHEPSK+AES128:kPSK+AES128
>>> +#
>>> +# Mandatory: no
>>> +# Default:
>>> +# TLSCipherPSK=3D
>>> +
>>> +### Option: TLSCipherAll13
>>> +#      Cipher string for OpenSSL 1.1.1 or newer in TLS 1.3.
>>> +#      Override the default ciphersuite selection criteria for
>>> certificate- and PSK-based encryption.
>>> +#      Example:
>>> +#              TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
>>> :TLS_AES_128_GCM_SHA256
>>> +#
>>> +# Mandatory: no
>>> +# Default:
>>> +# TLSCipherAll13=3D
>>> +
>>> +### Option: TLSCipherAll
>>> +#      GnuTLS priority string or OpenSSL (TLS 1.2) cipher string.
>>> +#      Override the default ciphersuite selection criteria for
>>> certificate- and PSK-based encryption.
>>> +#      Example for GnuTLS:
>>> +#              NONE:+VERS-TLS1.2:+ECDHE-RSA:+RSA:+ECDHE-
>>> PSK:+PSK:+AES-128-GCM:+AES-128-CBC:+AEAD:+SHA256:+SHA1:+CURVE-
>>> ALL:+COMP-NULL:+SIGN-ALL:+CTYPE-X.509
>>> +#      Example for OpenSSL:
>>> +#              EECDH+aRSA+AES128:RSA+aRSA+AES128:kECDHEPSK+AES128:
>>> kPSK+AES128
>>> +#
>>> +# Mandatory: no
>>> +# Default:
>>> +# TLSCipherAll=3D
>>> +
>>> +####### For advanced users - TCP-related fine-tuning parameters
>>> #######
>>> +
>>> +## Option: ListenBacklog
>>> +#       The maximum number of pending connections in the queue.
>>> This parameter is passed to
>>> +#       listen() function as argument 'backlog' (see "man
>>> listen").
>>> +#
>>> +# Mandatory: no
>>> +# Range: 0 - INT_MAX (depends on system, too large values may be
>>> silently truncated to implementation-specified maximum)
>>> +# Default: SOMAXCONN (hard-coded constant, depends on system)
>>> +# ListenBacklog=3D
>>> diff --git a/lfs/zabbix_agentd b/lfs/zabbix_agentd
>>> index c69643a54..28fe97b4f 100644
>>> --- a/lfs/zabbix_agentd
>>> +++ b/lfs/zabbix_agentd
>>> @@ -1,7 +1,7 @@
>>> ###################################################################
>>> ############
>>> #                                                                 =20
>>>            #
>>> # IPFire.org - A linux based
>>> firewall                                         #
>>> -# Copyright (C) 2007-2019  IPFire Team=20
>>> <info(a)ipfire.org>                     #
>>> +# Copyright (C) 2007-2022  IPFire Team=20
>>> <info(a)ipfire.org>                     #
>>> #                                                                 =20
>>>            #
>>> # This program is free software: you can redistribute it and/or
>>> modify        #
>>> # it under the terms of the GNU General Public License as published
>>> by        #
>>> @@ -24,7 +24,7 @@
>>>=20
>>> include Config
>>>=20
>>> -VER        =3D 4.2.6
>>> +VER        =3D 5.0.20
>>>=20
>>> THISAPP    =3D zabbix-$(VER)
>>> DL_FILE    =3D $(THISAPP).tar.gz
>>> @@ -32,7 +32,7 @@ DL_FROM    =3D $(URL_IPFIRE)
>>> DIR_APP    =3D $(DIR_SRC)/$(THISAPP)
>>> TARGET     =3D $(DIR_INFO)/$(THISAPP)
>>> PROG       =3D zabbix_agentd
>>> -PAK_VER    =3D 4
>>> +PAK_VER    =3D 5
>>> DEPS       =3D
>>>=20
>>> ###################################################################
>>> ############
>>> @@ -43,7 +43,7 @@ objects =3D $(DL_FILE)
>>>=20
>>> $(DL_FILE) =3D $(DL_FROM)/$(DL_FILE)
>>>=20
>>> -$(DL_FILE)_MD5 =3D 6cd55cd743d416d9ffbf2e6fdee680ee
>>> +$(DL_FILE)_MD5 =3D 52df25394f9a4cf83ff55278b23e6295
>>>=20
>>> install : $(TARGET)
>>>=20
>>> @@ -80,7 +80,8 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects))
>>>                 --prefix=3D/usr \
>>>                 --enable-agent \
>>>                 --sysconfdir=3D/etc/zabbix_agentd \
>>> -               --with-openssl
>>> +               --with-openssl \
>>> +               --with-libcurl
>>>=20
>>>         cd $(DIR_APP) && make
>>>         cd $(DIR_APP) && make install
>>> --=20
>>> 2.34.1
>>>=20
>>>=20
>>> --=20
>>> Dit bericht is gescanned op virussen en andere gevaarlijke
>>> inhoud door MailScanner en lijkt schoon te zijn.
>>>=20
>>=20
>>=20
>=20
> --=20
> Dit bericht is gescanned op virussen en andere gevaarlijke
> inhoud door MailScanner en lijkt schoon te zijn.


--===============4437195825686341852==--