Hi all
A new take on updating current zabbix_agentd 4.2.6 to latest LTS version. This set updates the agent version, fixes a few problems with the original addon and adds a few ipfire-specific metrics for the user to monitor out of the box (which I will document on the wiki when the patch-set is accepted).
The differences with the previous patch submission are: - patch 1: update to v5.0.20 - patch 2: - In the previous version the correct modules dir was commented out in the rootfile and was manually removed in the uninstall script if it was not empty. But since it is also included in the backup I figured it can be removed always by remove_files so I kept it in the rootfile now. - Checks before creating dirs are added in install script to see if dir is not already existing (like most other addons seem to do) - Function extract_backup_includes was not called in update.sh script causing possible scenarios where those includes are not present when backup needs to be taken or restored. - patch 3: Made sure to remove all configfiles upon uninstall as everything is in the backup. Also made sure that the ipfire supplied userparameter_pakfire.conf file is not added in addon-backup hence correctly updated on pak update. - patch 4: Is a small new patch to default the zabbix agent to listen only on GREEN as that is probably where the user's Zabbix server is and is a safer default than listening on all interfaces. - patch 5: was formerly patch4. - Grouped all ipfire (non-pakfire) related metrics in a single config file for simplicity. - Replaced the previous problematic iptables related metric and sudo rights with the renewed and safer getipstats binary. - Removed the services related metrics and perl script for now as we first need to have the new services metadata in the pak's and related pakfire functions so that I don't need to copy the bad code from services.cgi as I did before. - Added 2 new metrics: number of active dhcp leases and number of captive portal users. Those where contributed by StackKorora on my Zabbix template for IPFire on github.
As it was almost a year ago, previous patch submission and discussion can be found here: https://lists.ipfire.org/pipermail/development/2021-April/009872.html
I hope I addressed all concerns there where on the previous submission.
Regards Robin
- Update from 4.2.6 to latest LTS version 5.0.20 See release notes: https://www.zabbix.com/rn/rn5.0.20
Signed-off-by: Robin Roevens robin.roevens@disroot.org --- config/zabbix_agentd/zabbix_agentd.conf | 135 ++++++++++++++++++++++-- lfs/zabbix_agentd | 11 +- 2 files changed, 132 insertions(+), 14 deletions(-)
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=0 # Default: # SourceIP=
-### 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=system.run[*] is added by default. # # Mandatory: no # Default: -# EnableRemoteCommands=0 +# DenyKey=system.run[*] + +### Option: EnableRemoteCommands - Deprecated, use AllowKey=system.run[*] or DenyKey=system.run[*] instead +# Internal alias for AllowKey/DenyKey parameters depending on value: +# 0 - DenyKey=system.run[*] +# 1 - AllowKey=system.run[*] +# +# Mandatory: no
### Option: LogRemoteCommands # Enable logging of executed shell commands as warnings. @@ -177,6 +196,28 @@ ServerActive=127.0.0.1 # Default: # HostMetadataItem=
+### 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= + +### 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= + ### Option: RefreshActiveChecks # How often list of active checks is refreshed, in seconds. # @@ -265,7 +306,6 @@ ServerActive=127.0.0.1
Include=/etc/zabbix_agentd/zabbix_agentd.d/*.conf
- ####### USER-DEFINED MONITORED PARAMETERS #######
### Option: UnsafeUserParameters @@ -299,7 +339,7 @@ Include=/etc/zabbix_agentd/zabbix_agentd.d/*.conf # # Mandatory: no # Default: -# LoadModulePath=/usr/lib/modules +# LoadModulePath=${libdir}/modules
LoadModulePath=/usr/lib/zabbix
@@ -357,14 +397,14 @@ LoadModulePath=/usr/lib/zabbix # TLSCRLFile=
### Option: TLSServerCertIssuer -# Allowed server certificate issuer. +# Allowed server certificate issuer. # # Mandatory: no # Default: # TLSServerCertIssuer=
### Option: TLSServerCertSubject -# Allowed server certificate subject. +# Allowed server certificate subject. # # Mandatory: no # Default: @@ -397,3 +437,80 @@ LoadModulePath=/usr/lib/zabbix # Mandatory: no # Default: # TLSPSKFile= + +####### 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= + +### 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= + +### 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= + +### 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= + +### 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= + +### 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= + +####### 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= 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 @@ ############################################################################### # # # IPFire.org - A linux based firewall # -# Copyright (C) 2007-2019 IPFire Team info@ipfire.org # +# Copyright (C) 2007-2022 IPFire Team info@ipfire.org # # # # 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 @@
include Config
-VER = 4.2.6 +VER = 5.0.20
THISAPP = zabbix-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -32,7 +32,7 @@ DL_FROM = $(URL_IPFIRE) DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = zabbix_agentd -PAK_VER = 4 +PAK_VER = 5 DEPS =
############################################################################### @@ -43,7 +43,7 @@ objects = $(DL_FILE)
$(DL_FILE) = $(DL_FROM)/$(DL_FILE)
-$(DL_FILE)_MD5 = 6cd55cd743d416d9ffbf2e6fdee680ee +$(DL_FILE)_MD5 = 52df25394f9a4cf83ff55278b23e6295
install : $(TARGET)
@@ -80,7 +80,8 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) --prefix=/usr \ --enable-agent \ --sysconfdir=/etc/zabbix_agentd \ - --with-openssl + --with-openssl \ + --with-libcurl
cd $(DIR_APP) && make cd $(DIR_APP) && make install
Hello Robin,
Thank you for working on Zabbix and integrating it better into IPFire.
I am very happy with this, but I have my reservations about the mechanism with the “new” configuration file. I do not quite 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.
It would also create some unique feature around one package, but not for others which is probably more confusing than helpful.
What is your motivation for this?
-Michael
On 9 Feb 2022, at 23:26, Robin Roevens robin.roevens@disroot.org wrote:
- Update from 4.2.6 to latest LTS version 5.0.20
See release notes: https://www.zabbix.com/rn/rn5.0.20
Signed-off-by: Robin Roevens robin.roevens@disroot.org
config/zabbix_agentd/zabbix_agentd.conf | 135 ++++++++++++++++++++++-- lfs/zabbix_agentd | 11 +- 2 files changed, 132 insertions(+), 14 deletions(-)
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=0 # Default: # SourceIP=
-### 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=system.run[*] is added by default. # # Mandatory: no # Default: -# EnableRemoteCommands=0 +# DenyKey=system.run[*]
+### Option: EnableRemoteCommands - Deprecated, use AllowKey=system.run[*] or DenyKey=system.run[*] instead +# Internal alias for AllowKey/DenyKey parameters depending on value: +# 0 - DenyKey=system.run[*] +# 1 - AllowKey=system.run[*] +# +# Mandatory: no
### Option: LogRemoteCommands # Enable logging of executed shell commands as warnings. @@ -177,6 +196,28 @@ ServerActive=127.0.0.1 # Default: # HostMetadataItem=
+### 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=
+### 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=
### Option: RefreshActiveChecks # How often list of active checks is refreshed, in seconds. # @@ -265,7 +306,6 @@ ServerActive=127.0.0.1
Include=/etc/zabbix_agentd/zabbix_agentd.d/*.conf
####### USER-DEFINED MONITORED PARAMETERS #######
### Option: UnsafeUserParameters @@ -299,7 +339,7 @@ Include=/etc/zabbix_agentd/zabbix_agentd.d/*.conf # # Mandatory: no # Default: -# LoadModulePath=/usr/lib/modules +# LoadModulePath=${libdir}/modules
LoadModulePath=/usr/lib/zabbix
@@ -357,14 +397,14 @@ LoadModulePath=/usr/lib/zabbix # TLSCRLFile=
### Option: TLSServerCertIssuer -# Allowed server certificate issuer. +# Allowed server certificate issuer. # # Mandatory: no # Default: # TLSServerCertIssuer=
### Option: TLSServerCertSubject -# Allowed server certificate subject. +# Allowed server certificate subject. # # Mandatory: no # Default: @@ -397,3 +437,80 @@ LoadModulePath=/usr/lib/zabbix # Mandatory: no # Default: # TLSPSKFile=
+####### 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=
+### 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=
+### 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=
+### 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=
+### 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=
+### 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=
+####### 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= 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 @@ ############################################################################### # # # IPFire.org - A linux based firewall # -# Copyright (C) 2007-2019 IPFire Team info@ipfire.org # +# Copyright (C) 2007-2022 IPFire Team info@ipfire.org # # # # 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 @@
include Config
-VER = 4.2.6 +VER = 5.0.20
THISAPP = zabbix-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -32,7 +32,7 @@ DL_FROM = $(URL_IPFIRE) DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = zabbix_agentd -PAK_VER = 4 +PAK_VER = 5 DEPS =
############################################################################### @@ -43,7 +43,7 @@ objects = $(DL_FILE)
$(DL_FILE) = $(DL_FROM)/$(DL_FILE)
-$(DL_FILE)_MD5 = 6cd55cd743d416d9ffbf2e6fdee680ee +$(DL_FILE)_MD5 = 52df25394f9a4cf83ff55278b23e6295
install : $(TARGET)
@@ -80,7 +80,8 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) --prefix=/usr \ --enable-agent \ --sysconfdir=/etc/zabbix_agentd \
--with-openssl
--with-openssl \--with-libcurlcd $(DIR_APP) && make cd $(DIR_APP) && make install
-- 2.34.1
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.
Hi Michael
Michael Tremer schreef op di 15-02-2022 om 13:22 [+0000]:
Hello Robin,
Thank you for working on Zabbix and integrating it better into IPFire.
I am very happy with this, but I have my reservations about the mechanism with the “new” configuration file. I do not quite 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.
It would also create some unique feature around one package, but not for others which is probably more confusing than helpful.
What is your motivation for this?
I do understand your concerns and agree that handling the config of this pak differently than configs of other paks is bothersome.
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. Is this documented somewhere where I could have known this behaviour as a normal average user ?
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.
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.
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.
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.
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.
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 :-)
Regards
Robin
-Michael
On 9 Feb 2022, at 23:26, Robin Roevens robin.roevens@disroot.org wrote:
- Update from 4.2.6 to latest LTS version 5.0.20
See release notes: https://www.zabbix.com/rn/rn5.0.20
Signed-off-by: Robin Roevens robin.roevens@disroot.org
config/zabbix_agentd/zabbix_agentd.conf | 135 ++++++++++++++++++++++-- lfs/zabbix_agentd | 11 +- 2 files changed, 132 insertions(+), 14 deletions(-)
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=0 # Default: # SourceIP=
-### 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=system.run[*] is added by default. # # Mandatory: no # Default: -# EnableRemoteCommands=0 +# DenyKey=system.run[*]
+### Option: EnableRemoteCommands - Deprecated, use AllowKey=system.run[*] or DenyKey=system.run[*] instead +# Internal alias for AllowKey/DenyKey parameters depending on value: +# 0 - DenyKey=system.run[*] +# 1 - AllowKey=system.run[*] +# +# Mandatory: no
### Option: LogRemoteCommands # Enable logging of executed shell commands as warnings. @@ -177,6 +196,28 @@ ServerActive=127.0.0.1 # Default: # HostMetadataItem=
+### 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=
+### 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=
### Option: RefreshActiveChecks # How often list of active checks is refreshed, in seconds. # @@ -265,7 +306,6 @@ ServerActive=127.0.0.1
Include=/etc/zabbix_agentd/zabbix_agentd.d/*.conf
####### USER-DEFINED MONITORED PARAMETERS #######
### Option: UnsafeUserParameters @@ -299,7 +339,7 @@ Include=/etc/zabbix_agentd/zabbix_agentd.d/*.conf # # Mandatory: no # Default: -# LoadModulePath=/usr/lib/modules +# LoadModulePath=${libdir}/modules
LoadModulePath=/usr/lib/zabbix
@@ -357,14 +397,14 @@ LoadModulePath=/usr/lib/zabbix # TLSCRLFile=
### Option: TLSServerCertIssuer -# Allowed server certificate issuer. +# Allowed server certificate issuer. # # Mandatory: no # Default: # TLSServerCertIssuer=
### Option: TLSServerCertSubject -# Allowed server certificate subject. +# Allowed server certificate subject. # # Mandatory: no # Default: @@ -397,3 +437,80 @@ LoadModulePath=/usr/lib/zabbix # Mandatory: no # Default: # TLSPSKFile=
+####### 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=
+### 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=
+### 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=
+### 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=
+### 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=
+### 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=
+####### 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= 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 @@ ################################################################### ############ # # # IPFire.org - A linux based firewall # -# Copyright (C) 2007-2019 IPFire Team info@ipfire.org # +# Copyright (C) 2007-2022 IPFire Team info@ipfire.org # # # # 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 @@
include Config
-VER = 4.2.6 +VER = 5.0.20
THISAPP = zabbix-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -32,7 +32,7 @@ DL_FROM = $(URL_IPFIRE) DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = zabbix_agentd -PAK_VER = 4 +PAK_VER = 5 DEPS =
################################################################### ############ @@ -43,7 +43,7 @@ objects = $(DL_FILE)
$(DL_FILE) = $(DL_FROM)/$(DL_FILE)
-$(DL_FILE)_MD5 = 6cd55cd743d416d9ffbf2e6fdee680ee +$(DL_FILE)_MD5 = 52df25394f9a4cf83ff55278b23e6295
install : $(TARGET)
@@ -80,7 +80,8 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) --prefix=/usr \ --enable-agent \ --sysconfdir=/etc/zabbix_agentd \ - --with-openssl + --with-openssl \ + --with-libcurl
cd $(DIR_APP) && make cd $(DIR_APP) && make install -- 2.34.1
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.
Hello Robin,
On 16 Feb 2022, at 23:35, Robin Roevens robin.roevens@disroot.org wrote:
Hi Michael
Michael Tremer schreef op di 15-02-2022 om 13:22 [+0000]:
Hello Robin,
Thank you for working on Zabbix and integrating it better into IPFire.
I am very happy with this, but I have my reservations about the mechanism with the “new” configuration file. I do not quite 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.
It would also create some unique feature around one package, but not for others which is probably more confusing than helpful.
What is your motivation for this?
I do understand your concerns and agree that handling the config of this pak differently than configs of other paks is bothersome.
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. 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’t designed for this scale.
In order to avoid overwriting any existing configuration, we backup everything, extract the new package which will then overwrite the existing configuration 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 place which is what pakfire in IPFire 3 does.
Lots of other distributions work in a similar way where they rename the existing 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 that they don’t have to do this. The correct answer is probably somewhere in the middle.
What we do in practise is: We keep systems consistent with their previous behaviour. 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 the 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 “system configuration file”. It will 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 package 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.
Having some example configuration in a location the user would normally not look at is probably not helpful.
If you want them to configure things themselves, why not provide good documentation 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 “.user” or “.local” to make it clear that users should 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
Regards
Robin
-Michael
On 9 Feb 2022, at 23:26, Robin Roevens robin.roevens@disroot.org wrote:
- Update from 4.2.6 to latest LTS version 5.0.20
See release notes: https://www.zabbix.com/rn/rn5.0.20
Signed-off-by: Robin Roevens robin.roevens@disroot.org
config/zabbix_agentd/zabbix_agentd.conf | 135 ++++++++++++++++++++++-- lfs/zabbix_agentd | 11 +- 2 files changed, 132 insertions(+), 14 deletions(-)
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=0 # Default: # SourceIP=
-### 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=system.run[*] is added by default. # # Mandatory: no # Default: -# EnableRemoteCommands=0 +# DenyKey=system.run[*]
+### Option: EnableRemoteCommands - Deprecated, use AllowKey=system.run[*] or DenyKey=system.run[*] instead +# Internal alias for AllowKey/DenyKey parameters depending on value: +# 0 - DenyKey=system.run[*] +# 1 - AllowKey=system.run[*] +# +# Mandatory: no
### Option: LogRemoteCommands # Enable logging of executed shell commands as warnings. @@ -177,6 +196,28 @@ ServerActive=127.0.0.1 # Default: # HostMetadataItem=
+### 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=
+### 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=
### Option: RefreshActiveChecks # How often list of active checks is refreshed, in seconds. # @@ -265,7 +306,6 @@ ServerActive=127.0.0.1
Include=/etc/zabbix_agentd/zabbix_agentd.d/*.conf
####### USER-DEFINED MONITORED PARAMETERS #######
### Option: UnsafeUserParameters @@ -299,7 +339,7 @@ Include=/etc/zabbix_agentd/zabbix_agentd.d/*.conf # # Mandatory: no # Default: -# LoadModulePath=/usr/lib/modules +# LoadModulePath=${libdir}/modules
LoadModulePath=/usr/lib/zabbix
@@ -357,14 +397,14 @@ LoadModulePath=/usr/lib/zabbix # TLSCRLFile=
### Option: TLSServerCertIssuer -# Allowed server certificate issuer. +# Allowed server certificate issuer. # # Mandatory: no # Default: # TLSServerCertIssuer=
### Option: TLSServerCertSubject -# Allowed server certificate subject. +# Allowed server certificate subject. # # Mandatory: no # Default: @@ -397,3 +437,80 @@ LoadModulePath=/usr/lib/zabbix # Mandatory: no # Default: # TLSPSKFile=
+####### 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=
+### 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=
+### 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=
+### 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=
+### 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=
+### 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=
+####### 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= 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 @@ ################################################################### ############ # # # IPFire.org - A linux based firewall # -# Copyright (C) 2007-2019 IPFire Team info@ipfire.org # +# Copyright (C) 2007-2022 IPFire Team info@ipfire.org # # # # 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 @@
include Config
-VER = 4.2.6 +VER = 5.0.20
THISAPP = zabbix-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -32,7 +32,7 @@ DL_FROM = $(URL_IPFIRE) DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = zabbix_agentd -PAK_VER = 4 +PAK_VER = 5 DEPS =
################################################################### ############ @@ -43,7 +43,7 @@ objects = $(DL_FILE)
$(DL_FILE) = $(DL_FROM)/$(DL_FILE)
-$(DL_FILE)_MD5 = 6cd55cd743d416d9ffbf2e6fdee680ee +$(DL_FILE)_MD5 = 52df25394f9a4cf83ff55278b23e6295
install : $(TARGET)
@@ -80,7 +80,8 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) --prefix=/usr \ --enable-agent \ --sysconfdir=/etc/zabbix_agentd \
--with-openssl
--with-openssl \--with-libcurl cd $(DIR_APP) && make cd $(DIR_APP) && make install-- 2.34.1
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.
Hi Michael
Michael Tremer schreef op zo 20-02-2022 om 18:10 [+0000]:
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’t designed for this scale.
In order to avoid overwriting any existing configuration, we backup everything, extract the new package which will then overwrite the existing configuration 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 place which is what pakfire in IPFire 3 does.
The current method indeed is probably the best possible considering the way pakfire currently works when updating an addon. But for as far as I currently understand it, when you uninstall an addon, all config files are backed up and then are removed (due to being in the rootfile). For the user the addon is gone on the system. If the user opts to install the addon again, say about half a year or a year later, the install will restore the backup of the config it took during uninstall half a year ago. I think this will cause confusion in many cases? Is this implemented this way for a good reason? or just to accommodate the update procedure without much further thought?
I myself (if I didn't know how pakfire worked internally) would expect that if I uninstalled an addon, checked and removed potentially left- over config files, that a new install would give me a fresh install which I would have to configure manually again.
If pakfire worked that way, the user could make a copy of his config himself, uninstall and re-install an addon to have a fresh config which he then could merge himself with his old config-copy to make the addon work again.
So if there is no real reason to always backup on uninstall I would like to propose to perform the backup restore in the actual update- script instead of in the install and uninstall scripts? This way there is a quite logical way for the average user to start over with a fresh install of an addon. That would feel much more 'natural' to me.
Anyway this discussion about pakfire working is maybe worth its own thread as it is not really zabbix-agent specific.
Lots of other distributions work in a similar way where they rename the existing 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 that they don’t have to do this. The correct answer is probably somewhere in the middle.
What we do in practise is: We keep systems consistent with their previous behaviour. An update should never change that (there are of course exceptions to every rule). New features might only be activated on new systems.
The problem I see with this is that if software provided by an addon is for example deprecating one or more config-options. Keeping the systems constistent would mean - not providing any newer version for that addon anymore, which I don't think is what we want. Or - trying to 'convert' the possibly user-changed deprecated config- setting in the config file using sed, which I can see failing in may ways :-) Or - providing the user with a straight forward way to reinstall an addon completely afresh, and/or - what I'm trying to do here, provide the user with the new config in some easily accessible way (currently .ipfirenew, but could be a simpler .example, see below), keeping his old config active possibly making the new addon version fail to work, but giving him the possibility to manually merge his deprecated config to what the current version of the addon-software expects.
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 the things they want? Would that be overkill for the possible options?
As I said before, I would indeed prefer a web ui for the config of the addon. That way we are in complete control of the config file. And I plan to build such a page (I have already put some effort in it, but it is not even nearly ready for now). The page should give the user access to all possible configuration options. If not, we could handicap/limit the use of the agent or force the advanced user to still manually tinker with the config file.
But the zabbix agent has many options including defining certificates and encryption keys for communication and a web ui should do sanity checking on all options as well as provide methods to upload and/or generate those certs/keys so it is not a page that is easily designed overnight. But it is coming sooner or later.
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 “system configuration file”. It will 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 package 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.
Having some example configuration in a location the user would normally not look at is probably not helpful.
I agree with the "location the user would normally not look at". But as I currently see it, I would like to add the the config example next to the actual config. (I see this happen in many software packages in other linux distro's too. Granted, most of the time it is the vendor itself that provides that example config, not the distro. But since we don't have config merging or '.rpmnew' systems as those distro's do have, I see this as some kind of middle way)
So /etc/zabbix_agentd/ in a fresh install would contain - zabbix_agentd.conf.example - the config as shipped with the zabbix source, but renamed to '.example' during build. (with all options in it accompanied with option documentation as comments.) - zabbix_agentd.conf - the active config, provided by us, with only the bare minimum of options required for the agent to run (secure). - this config will not be altered by us after initial install due to the backup/restore.
This way the example config is automatically accurate for the current version of the addon. And the user stays in complete control of his own config in the same way it is in other addons.
Until the web ui is finished..
If you want them to configure things themselves, why not provide good documentation on the wiki?
I do not 'want' them to configure things themselves.. but if they want to actually use the agent they have to at least point the agent to their zabbix server. So minimal manual configuration is required, and that is also already documented on the wiki. But the agent has many options and possibilities and I don't think it is our job to provide extensive non-IPFire specific configuration documentation as that is the job of the vendor (and in case of Zabbix the docs are there and very clear).
But I do am convinced that we should provide a straight-forward way for the more advanced user to get a version of the default config as it is shipped with the current release of the software, especially when it is as verbose in documentation comments as provided by Zabbix.
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 “.user” or “.local” to make it clear that users should make their own changes here.
Ok, for the sudoers, I will go this route then.
Robin
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
Regards
Robin
-Michael
On 9 Feb 2022, at 23:26, Robin Roevens robin.roevens@disroot.org wrote:
- Update from 4.2.6 to latest LTS version 5.0.20
See release notes: https://www.zabbix.com/rn/rn5.0.20
Signed-off-by: Robin Roevens robin.roevens@disroot.org
config/zabbix_agentd/zabbix_agentd.conf | 135 ++++++++++++++++++++++-- lfs/zabbix_agentd | 11 +- 2 files changed, 132 insertions(+), 14 deletions(-)
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=0 # Default: # SourceIP=
-### 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=system.run[*] is added by default. # # Mandatory: no # Default: -# EnableRemoteCommands=0 +# DenyKey=system.run[*]
+### Option: EnableRemoteCommands - Deprecated, use AllowKey=system.run[*] or DenyKey=system.run[*] instead +# Internal alias for AllowKey/DenyKey parameters depending on value: +# 0 - DenyKey=system.run[*] +# 1 - AllowKey=system.run[*] +# +# Mandatory: no
### Option: LogRemoteCommands # Enable logging of executed shell commands as warnings. @@ -177,6 +196,28 @@ ServerActive=127.0.0.1 # Default: # HostMetadataItem=
+### 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=
+### 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=
### Option: RefreshActiveChecks # How often list of active checks is refreshed, in seconds. # @@ -265,7 +306,6 @@ ServerActive=127.0.0.1
Include=/etc/zabbix_agentd/zabbix_agentd.d/*.conf
####### USER-DEFINED MONITORED PARAMETERS #######
### Option: UnsafeUserParameters @@ -299,7 +339,7 @@ Include=/etc/zabbix_agentd/zabbix_agentd.d/*.conf # # Mandatory: no # Default: -# LoadModulePath=/usr/lib/modules +# LoadModulePath=${libdir}/modules
LoadModulePath=/usr/lib/zabbix
@@ -357,14 +397,14 @@ LoadModulePath=/usr/lib/zabbix # TLSCRLFile=
### Option: TLSServerCertIssuer -# Allowed server certificate issuer. +# Allowed server certificate issuer. # # Mandatory: no # Default: # TLSServerCertIssuer=
### Option: TLSServerCertSubject -# Allowed server certificate subject. +# Allowed server certificate subject. # # Mandatory: no # Default: @@ -397,3 +437,80 @@ LoadModulePath=/usr/lib/zabbix # Mandatory: no # Default: # TLSPSKFile=
+####### 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=
+### 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=
+### 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=
+### 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=
+### 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=
+### 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=
+####### 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= 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 @@ ############################################################### #### ############ # # # IPFire.org - A linux based firewall # -# Copyright (C) 2007-2019 IPFire Team info@ipfire.org # +# Copyright (C) 2007-2022 IPFire Team info@ipfire.org # # # # 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 @@
include Config
-VER = 4.2.6 +VER = 5.0.20
THISAPP = zabbix-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -32,7 +32,7 @@ DL_FROM = $(URL_IPFIRE) DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = zabbix_agentd -PAK_VER = 4 +PAK_VER = 5 DEPS =
############################################################### #### ############ @@ -43,7 +43,7 @@ objects = $(DL_FILE)
$(DL_FILE) = $(DL_FROM)/$(DL_FILE)
-$(DL_FILE)_MD5 = 6cd55cd743d416d9ffbf2e6fdee680ee +$(DL_FILE)_MD5 = 52df25394f9a4cf83ff55278b23e6295
install : $(TARGET)
@@ -80,7 +80,8 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) --prefix=/usr \ --enable-agent \ --sysconfdir=/etc/zabbix_agentd \ - --with-openssl + --with-openssl \ + --with-libcurl
cd $(DIR_APP) && make cd $(DIR_APP) && make install -- 2.34.1
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.
Hello,
On 20 Feb 2022, at 22:18, Robin Roevens robin.roevens@disroot.org wrote:
Hi Michael
Michael Tremer schreef op zo 20-02-2022 om 18:10 [+0000]:
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’t designed for this scale.
In order to avoid overwriting any existing configuration, we backup everything, extract the new package which will then overwrite the existing configuration 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 place which is what pakfire in IPFire 3 does.
The current method indeed is probably the best possible considering the way pakfire currently works when updating an addon. But for as far as I currently understand it, when you uninstall an addon, all config files are backed up and then are removed (due to being in the rootfile). For the user the addon is gone on the system. If the user opts to install the addon again, say about half a year or a year later, the install will restore the backup of the config it took during uninstall half a year ago. I think this will cause confusion in many cases? Is this implemented this way for a good reason? or just to accommodate the update procedure without much further thought?
I am not if this is for the best reason, but it prevents that people will lose their configuration for any reason and there is an easy option to drop configuration if you want to.
Although it might not be the best, it is a good solution.
I myself (if I didn't know how pakfire worked internally) would expect that if I uninstalled an addon, checked and removed potentially left- over config files, that a new install would give me a fresh install which I would have to configure manually again.
If pakfire worked that way, the user could make a copy of his config himself, uninstall and re-install an addon to have a fresh config which he then could merge himself with his old config-copy to make the addon work again.
So if there is no real reason to always backup on uninstall I would like to propose to perform the backup restore in the actual update- script instead of in the install and uninstall scripts? This way there is a quite logical way for the average user to start over with a fresh install of an addon. That would feel much more 'natural' to me.
There is the reason, that there is no other way at the moment than backing it up and restoring it. Otherwise the configuration will always be overwritten which is not what we want at all.
Additionally, I would want all packages to behave the same. If we change this for Zabbix, we will have to change this for everything else, too.
Anyway this discussion about pakfire working is maybe worth its own thread as it is not really zabbix-agent specific.
Lots of other distributions work in a similar way where they rename the existing 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 that they don’t have to do this. The correct answer is probably somewhere in the middle.
What we do in practise is: We keep systems consistent with their previous behaviour. An update should never change that (there are of course exceptions to every rule). New features might only be activated on new systems.
The problem I see with this is that if software provided by an addon is for example deprecating one or more config-options. Keeping the systems constistent would mean
- not providing any newer version for that addon anymore, which I don't
think is what we want. Or
- trying to 'convert' the possibly user-changed deprecated config-
setting in the config file using sed, which I can see failing in may ways :-) Or
This is what we do quite regularly and it has never failed.
Ultimately, if upstream decides to discontinue support for something, there isn’t much else that we can do.
- providing the user with a straight forward way to reinstall an addon
completely afresh, and/or
- what I'm trying to do here, provide the user with the new config in
some easily accessible way (currently .ipfirenew, but could be a simpler .example, see below), keeping his old config active possibly making the new addon version fail to work, but giving him the possibility to manually merge his deprecated config to what the current version of the addon-software expects.
I am not sure how they should know about those changes.
Showing a diff is probably hard to understand for many users and showing that diff on the UI is even more difficult.
I am not against *what* you are trying to achieve at all. I am just not sure if the *how* is the best.
How about just copying the configuration and put it next to the configuration file with a “.sample” suffix? Then people are still on their own, but I would consider a sample suffix more clear than a .ipfirenew because that doesn’t tell me much about what I should be doing with it.
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 the things they want? Would that be overkill for the possible options?
As I said before, I would indeed prefer a web ui for the config of the addon. That way we are in complete control of the config file. And I plan to build such a page (I have already put some effort in it, but it is not even nearly ready for now). The page should give the user access to all possible configuration options. If not, we could handicap/limit the use of the agent or force the advanced user to still manually tinker with the config file.
But the zabbix agent has many options including defining certificates and encryption keys for communication and a web ui should do sanity checking on all options as well as provide methods to upload and/or generate those certs/keys so it is not a page that is easily designed overnight. But it is coming sooner or later.
Wouldn’t the system automatically generate any keys for the agent?
Scrolling through the configuration, I do not see anything the user would want to change. Do you have an example for me to understand this better?
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 “system configuration file”. It will 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 package 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.
Having some example configuration in a location the user would normally not look at is probably not helpful.
I agree with the "location the user would normally not look at". But as I currently see it, I would like to add the the config example next to the actual config. (I see this happen in many software packages in other linux distro's too. Granted, most of the time it is the vendor itself that provides that example config, not the distro. But since we don't have config merging or '.rpmnew' systems as those distro's do have, I see this as some kind of middle way)
So /etc/zabbix_agentd/ in a fresh install would contain
- zabbix_agentd.conf.example - the config as shipped with the zabbix
source, but renamed to '.example' during build. (with all options in it accompanied with option documentation as comments.)
Okay. I can live with this.
- zabbix_agentd.conf - the active config, provided by us, with only the
bare minimum of options required for the agent to run (secure). - this config will not be altered by us after initial install due to the backup/restore.
Unless we need to remove any deprecated options, etc. Agreed.
This way the example config is automatically accurate for the current version of the addon. And the user stays in complete control of his own config in the same way it is in other addons.
Until the web ui is finished..
That sounds good to me.
If you want them to configure things themselves, why not provide good documentation on the wiki?
I do not 'want' them to configure things themselves.. but if they want to actually use the agent they have to at least point the agent to their zabbix server. So minimal manual configuration is required, and that is also already documented on the wiki. But the agent has many options and possibilities and I don't think it is our job to provide extensive non-IPFire specific configuration documentation as that is the job of the vendor (and in case of Zabbix the docs are there and very clear).
No, that would just be duplicating documentation.
-Michael
But I do am convinced that we should provide a straight-forward way for the more advanced user to get a version of the default config as it is shipped with the current release of the software, especially when it is as verbose in documentation comments as provided by Zabbix.
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 “.user” or “.local” to make it clear that users should make their own changes here.
Ok, for the sudoers, I will go this route then.
Robin
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
Regards
Robin
-Michael
On 9 Feb 2022, at 23:26, Robin Roevens robin.roevens@disroot.org wrote:
- Update from 4.2.6 to latest LTS version 5.0.20
See release notes: https://www.zabbix.com/rn/rn5.0.20
Signed-off-by: Robin Roevens robin.roevens@disroot.org
config/zabbix_agentd/zabbix_agentd.conf | 135 ++++++++++++++++++++++-- lfs/zabbix_agentd | 11 +- 2 files changed, 132 insertions(+), 14 deletions(-)
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=0 # Default: # SourceIP=
-### 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=system.run[*] is added by default. # # Mandatory: no # Default: -# EnableRemoteCommands=0 +# DenyKey=system.run[*]
+### Option: EnableRemoteCommands - Deprecated, use AllowKey=system.run[*] or DenyKey=system.run[*] instead +# Internal alias for AllowKey/DenyKey parameters depending on value: +# 0 - DenyKey=system.run[*] +# 1 - AllowKey=system.run[*] +# +# Mandatory: no
### Option: LogRemoteCommands # Enable logging of executed shell commands as warnings. @@ -177,6 +196,28 @@ ServerActive=127.0.0.1 # Default: # HostMetadataItem=
+### 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=
+### 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=
### Option: RefreshActiveChecks # How often list of active checks is refreshed, in seconds. # @@ -265,7 +306,6 @@ ServerActive=127.0.0.1
Include=/etc/zabbix_agentd/zabbix_agentd.d/*.conf
####### USER-DEFINED MONITORED PARAMETERS #######
### Option: UnsafeUserParameters @@ -299,7 +339,7 @@ Include=/etc/zabbix_agentd/zabbix_agentd.d/*.conf # # Mandatory: no # Default: -# LoadModulePath=/usr/lib/modules +# LoadModulePath=${libdir}/modules
LoadModulePath=/usr/lib/zabbix
@@ -357,14 +397,14 @@ LoadModulePath=/usr/lib/zabbix # TLSCRLFile=
### Option: TLSServerCertIssuer -# Allowed server certificate issuer. +# Allowed server certificate issuer. # # Mandatory: no # Default: # TLSServerCertIssuer=
### Option: TLSServerCertSubject -# Allowed server certificate subject. +# Allowed server certificate subject. # # Mandatory: no # Default: @@ -397,3 +437,80 @@ LoadModulePath=/usr/lib/zabbix # Mandatory: no # Default: # TLSPSKFile=
+####### 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=
+### 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=
+### 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=
+### 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=
+### 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=
+### 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=
+####### 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= 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 @@ ############################################################### #### ############ #
## IPFire.org - A linux based firewall # -# Copyright (C) 2007-2019 IPFire Team info@ipfire.org # +# Copyright (C) 2007-2022 IPFire Team info@ipfire.org # #
## 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 @@
include Config
-VER = 4.2.6 +VER = 5.0.20
THISAPP = zabbix-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -32,7 +32,7 @@ DL_FROM = $(URL_IPFIRE) DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = zabbix_agentd -PAK_VER = 4 +PAK_VER = 5 DEPS =
############################################################### #### ############ @@ -43,7 +43,7 @@ objects = $(DL_FILE)
$(DL_FILE) = $(DL_FROM)/$(DL_FILE)
-$(DL_FILE)_MD5 = 6cd55cd743d416d9ffbf2e6fdee680ee +$(DL_FILE)_MD5 = 52df25394f9a4cf83ff55278b23e6295
install : $(TARGET)
@@ -80,7 +80,8 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) --prefix=/usr \ --enable-agent \ --sysconfdir=/etc/zabbix_agentd \
--with-openssl
--with-openssl \--with-libcurl cd $(DIR_APP) && make cd $(DIR_APP) && make install-- 2.34.1
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.
Hi Michael
I was implementing the changes as we discussed here. But I came up with a few extra questions, where I'm not sure if you agree or on how to best handle them:
Currently the whole /etc/zabbix_agentd directory is included in the backup. But, as discussed, we will now add a .example config file and Alex has added the custom zabbix_agentd.d/userparameters_pakfire.conf file previously (which is currently already in the backup). And more userparameters files are added in this patchset. This makes this directory a hybrid with both user + ipfire managed files.
I was thinking to - only include - /etc/zabbix_agentd/zabbix_agentd.conf - /etc/zabbix_agentd/zabbix_agentd.d/* - /etc/zabbix_agentd/scripts/* in the backup instead of the whole /etc/zabbix_agentd/* That would remove the need to handle the new zabbix_agentd.conf.example file in the (un)install scripts preventing it from landing inside the backup.
- In the zabbix_agentd.conf file - which is managed by the user, I would add an Include= line to include a new location, specific for the IPFire added configfile(s). I was thinking '/var/ipfire/zabbix_agentd/userparameters' ?
This would ease the correct management of the backups and give the user the option to easily disable the IPFire provided customization by commenting out that include line in the config. I think this would be much cleaner now and in the future when possible more IPfire-specific customizations are added.
But if we decide to do that. How should I then handle old installs that will be upgraded? - The current zabbix_agentd.d/userparameters_pakfire.conf would then need to be removed. (as a new one will be installed somewhere else) But up until now it was included in the backup, and it is possible that a user has changed that file on his installation (I think chances are rather low.. but theoretically it is possible) Should I just remove the file ?
- How should I add the new Include= line now in an already existing config? I was thinking maybe, just add it during install, and also create (for example) a '/var/ipfire/zabbix_agentd/config_migrated' file so that I know the config was once changed and subsequent upgrades will no longer try to add that line again. (To prevent that if the user comments it out to disable our customizations, it would be added again on next upgrade)
A bit of the same story for the sudoers file. Up until now the file was included in the backup. And the user may have modified the file. I was thinking of performing a check on an existing sudoers.d/zabbix- file if it is still unmodified, and if so remove it. Otherwise rename it to sudoers.d/zabbix_agentd_user (and include that one in backup) and add a new sudoers.d/zabbix_agentd file that is not included in the backup and is not supposed to be modified by the user. Would that be a feasible solution ?
Regards Robin
Michael Tremer schreef op ma 21-02-2022 om 11:41 [+0000]:
Hello,
On 20 Feb 2022, at 22:18, Robin Roevens robin.roevens@disroot.org wrote:
Hi Michael
Michael Tremer schreef op zo 20-02-2022 om 18:10 [+0000]:
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’t designed for this scale.
In order to avoid overwriting any existing configuration, we backup everything, extract the new package which will then overwrite the existing configuration 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 place which is what pakfire in IPFire 3 does.
The current method indeed is probably the best possible considering the way pakfire currently works when updating an addon. But for as far as I currently understand it, when you uninstall an addon, all config files are backed up and then are removed (due to being in the rootfile). For the user the addon is gone on the system. If the user opts to install the addon again, say about half a year or a year later, the install will restore the backup of the config it took during uninstall half a year ago. I think this will cause confusion in many cases? Is this implemented this way for a good reason? or just to accommodate the update procedure without much further thought?
I am not if this is for the best reason, but it prevents that people will lose their configuration for any reason and there is an easy option to drop configuration if you want to.
Although it might not be the best, it is a good solution.
I myself (if I didn't know how pakfire worked internally) would expect that if I uninstalled an addon, checked and removed potentially left- over config files, that a new install would give me a fresh install which I would have to configure manually again.
If pakfire worked that way, the user could make a copy of his config himself, uninstall and re-install an addon to have a fresh config which he then could merge himself with his old config-copy to make the addon work again.
So if there is no real reason to always backup on uninstall I would like to propose to perform the backup restore in the actual update- script instead of in the install and uninstall scripts? This way there is a quite logical way for the average user to start over with a fresh install of an addon. That would feel much more 'natural' to me.
There is the reason, that there is no other way at the moment than backing it up and restoring it. Otherwise the configuration will always be overwritten which is not what we want at all.
Additionally, I would want all packages to behave the same. If we change this for Zabbix, we will have to change this for everything else, too.
Anyway this discussion about pakfire working is maybe worth its own thread as it is not really zabbix-agent specific.
Lots of other distributions work in a similar way where they rename the existing 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 that they don’t have to do this. The correct answer is probably somewhere in the middle.
What we do in practise is: We keep systems consistent with their previous behaviour. An update should never change that (there are of course exceptions to every rule). New features might only be activated on new systems.
The problem I see with this is that if software provided by an addon is for example deprecating one or more config-options. Keeping the systems constistent would mean
- not providing any newer version for that addon anymore, which I
don't think is what we want. Or
- trying to 'convert' the possibly user-changed deprecated config-
setting in the config file using sed, which I can see failing in may ways :-) Or
This is what we do quite regularly and it has never failed.
Ultimately, if upstream decides to discontinue support for something, there isn’t much else that we can do.
- providing the user with a straight forward way to reinstall an
addon completely afresh, and/or
- what I'm trying to do here, provide the user with the new config
in some easily accessible way (currently .ipfirenew, but could be a simpler .example, see below), keeping his old config active possibly making the new addon version fail to work, but giving him the possibility to manually merge his deprecated config to what the current version of the addon-software expects.
I am not sure how they should know about those changes.
Showing a diff is probably hard to understand for many users and showing that diff on the UI is even more difficult.
I am not against *what* you are trying to achieve at all. I am just not sure if the *how* is the best.
How about just copying the configuration and put it next to the configuration file with a “.sample” suffix? Then people are still on their own, but I would consider a sample suffix more clear than a .ipfirenew because that doesn’t tell me much about what I should be doing with it.
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 the things they want? Would that be overkill for the possible options?
As I said before, I would indeed prefer a web ui for the config of the addon. That way we are in complete control of the config file. And I plan to build such a page (I have already put some effort in it, but it is not even nearly ready for now). The page should give the user access to all possible configuration options. If not, we could handicap/limit the use of the agent or force the advanced user to still manually tinker with the config file.
But the zabbix agent has many options including defining certificates and encryption keys for communication and a web ui should do sanity checking on all options as well as provide methods to upload and/or generate those certs/keys so it is not a page that is easily designed overnight. But it is coming sooner or later.
Wouldn’t the system automatically generate any keys for the agent?
Scrolling through the configuration, I do not see anything the user would want to change. Do you have an example for me to understand this better?
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 “system configuration file”. It will 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 package 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.
Having some example configuration in a location the user would normally not look at is probably not helpful.
I agree with the "location the user would normally not look at". But as I currently see it, I would like to add the the config example next to the actual config. (I see this happen in many software packages in other linux distro's too. Granted, most of the time it is the vendor itself that provides that example config, not the distro. But since we don't have config merging or '.rpmnew' systems as those distro's do have, I see this as some kind of middle way)
So /etc/zabbix_agentd/ in a fresh install would contain
- zabbix_agentd.conf.example - the config as shipped with the
zabbix source, but renamed to '.example' during build. (with all options in it accompanied with option documentation as comments.)
Okay. I can live with this.
- zabbix_agentd.conf - the active config, provided by us, with only
the bare minimum of options required for the agent to run (secure). - this config will not be altered by us after initial install due to the backup/restore.
Unless we need to remove any deprecated options, etc. Agreed.
This way the example config is automatically accurate for the current version of the addon. And the user stays in complete control of his own config in the same way it is in other addons.
Until the web ui is finished..
That sounds good to me.
If you want them to configure things themselves, why not provide good documentation on the wiki?
I do not 'want' them to configure things themselves.. but if they want to actually use the agent they have to at least point the agent to their zabbix server. So minimal manual configuration is required, and that is also already documented on the wiki. But the agent has many options and possibilities and I don't think it is our job to provide extensive non-IPFire specific configuration documentation as that is the job of the vendor (and in case of Zabbix the docs are there and very clear).
No, that would just be duplicating documentation.
-Michael
But I do am convinced that we should provide a straight-forward way for the more advanced user to get a version of the default config as it is shipped with the current release of the software, especially when it is as verbose in documentation comments as provided by Zabbix.
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 “.user” or “.local” to make it clear that users should make their own changes here.
Ok, for the sudoers, I will go this route then.
Robin
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
Regards
Robin
-Michael
On 9 Feb 2022, at 23:26, Robin Roevens robin.roevens@disroot.org wrote:
- Update from 4.2.6 to latest LTS version 5.0.20
See release notes: https://www.zabbix.com/rn/rn5.0.20
Signed-off-by: Robin Roevens robin.roevens@disroot.org
config/zabbix_agentd/zabbix_agentd.conf | 135 ++++++++++++++++++++++-- lfs/zabbix_agentd | 11 +- 2 files changed, 132 insertions(+), 14 deletions(-)
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=0 # Default: # SourceIP=
-### 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=system.run[*] is added by default. # # Mandatory: no # Default: -# EnableRemoteCommands=0 +# DenyKey=system.run[*]
+### Option: EnableRemoteCommands - Deprecated, use AllowKey=system.run[*] or DenyKey=system.run[*] instead +# Internal alias for AllowKey/DenyKey parameters depending on value: +# 0 - DenyKey=system.run[*] +# 1 - AllowKey=system.run[*] +# +# Mandatory: no
### Option: LogRemoteCommands # Enable logging of executed shell commands as warnings. @@ -177,6 +196,28 @@ ServerActive=127.0.0.1 # Default: # HostMetadataItem=
+### 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=
+### 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=
### Option: RefreshActiveChecks # How often list of active checks is refreshed, in seconds. # @@ -265,7 +306,6 @@ ServerActive=127.0.0.1
Include=/etc/zabbix_agentd/zabbix_agentd.d/*.conf
####### USER-DEFINED MONITORED PARAMETERS #######
### Option: UnsafeUserParameters @@ -299,7 +339,7 @@ Include=/etc/zabbix_agentd/zabbix_agentd.d/*.conf # # Mandatory: no # Default: -# LoadModulePath=/usr/lib/modules +# LoadModulePath=${libdir}/modules
LoadModulePath=/usr/lib/zabbix
@@ -357,14 +397,14 @@ LoadModulePath=/usr/lib/zabbix # TLSCRLFile=
### Option: TLSServerCertIssuer -# Allowed server certificate issuer. +# Allowed server certificate issuer. # # Mandatory: no # Default: # TLSServerCertIssuer=
### Option: TLSServerCertSubject -# Allowed server certificate subject. +# Allowed server certificate subject. # # Mandatory: no # Default: @@ -397,3 +437,80 @@ LoadModulePath=/usr/lib/zabbix # Mandatory: no # Default: # TLSPSKFile=
+####### 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=
+### 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=
+### 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=
+### 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=
+### 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=
+### 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=
+####### 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= 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 @@ ########################################################### #### #### ############ # # # IPFire.org - A linux based firewall # -# Copyright (C) 2007-2019 IPFire Team info@ipfire.org # +# Copyright (C) 2007-2022 IPFire Team info@ipfire.org # # # # 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 @@
include Config
-VER = 4.2.6 +VER = 5.0.20
THISAPP = zabbix-$(VER) DL_FILE = $(THISAPP).tar.gz @@ -32,7 +32,7 @@ DL_FROM = $(URL_IPFIRE) DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = zabbix_agentd -PAK_VER = 4 +PAK_VER = 5 DEPS =
########################################################### #### #### ############ @@ -43,7 +43,7 @@ objects = $(DL_FILE)
$(DL_FILE) = $(DL_FROM)/$(DL_FILE)
-$(DL_FILE)_MD5 = 6cd55cd743d416d9ffbf2e6fdee680ee +$(DL_FILE)_MD5 = 52df25394f9a4cf83ff55278b23e6295
install : $(TARGET)
@@ -80,7 +80,8 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) --prefix=/usr \ --enable-agent \ --sysconfdir=/etc/zabbix_agentd \ - --with-openssl + --with-openssl \ + --with-libcurl
cd $(DIR_APP) && make cd $(DIR_APP) && make install -- 2.34.1
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.
Hello,
On 21 Feb 2022, at 23:48, Robin Roevens robin.roevens@disroot.org wrote:
Hi Michael
I was implementing the changes as we discussed here. But I came up with a few extra questions, where I'm not sure if you agree or on how to best handle them:
Currently the whole /etc/zabbix_agentd directory is included in the backup. But, as discussed, we will now add a .example config file and Alex has added the custom zabbix_agentd.d/userparameters_pakfire.conf file previously (which is currently already in the backup). And more userparameters files are added in this patchset. This makes this directory a hybrid with both user + ipfire managed files.
I was thinking to
- only include
- /etc/zabbix_agentd/zabbix_agentd.conf
- /etc/zabbix_agentd/zabbix_agentd.d/*
- /etc/zabbix_agentd/scripts/*
in the backup instead of the whole /etc/zabbix_agentd/* That would remove the need to handle the new zabbix_agentd.conf.example file in the (un)install scripts preventing it from landing inside the backup.
Yes, I would agree with this.
- In the zabbix_agentd.conf file - which is managed by the user, I
would add an Include= line to include a new location, specific for the IPFire added configfile(s). I was thinking '/var/ipfire/zabbix_agentd/userparameters' ?
This would ease the correct management of the backups and give the user the option to easily disable the IPFire provided customization by commenting out that include line in the config. I think this would be much cleaner now and in the future when possible more IPfire-specific customizations are added.
*IPFire. With a capital F :)
But if we decide to do that. How should I then handle old installs that will be upgraded?
- The current zabbix_agentd.d/userparameters_pakfire.conf would then
need to be removed. (as a new one will be installed somewhere else) But up until now it was included in the backup, and it is possible that a user has changed that file on his installation (I think chances are rather low.. but theoretically it is possible) Should I just remove the file ?
I wouldn’t just remove it, but rename it and make it clear that it just there as a backup. It can then be around for users to grab their custom changes if they want to.
We can add a line to the change log that manual action is required. Indeed I don’t expect anyone to run into this.
- How should I add the new Include= line now in an already existing
config? I was thinking maybe, just add it during install, and also create (for example) a '/var/ipfire/zabbix_agentd/config_migrated' file so that I know the config was once changed and subsequent upgrades will no longer try to add that line again. (To prevent that if the user comments it out to disable our customizations, it would be added again on next upgrade)
Yes, you could just add this in the install.sh script of the package.
That would work for me.
A bit of the same story for the sudoers file. Up until now the file was included in the backup. And the user may have modified the file. I was thinking of performing a check on an existing sudoers.d/zabbix- file if it is still unmodified, and if so remove it. Otherwise rename it to sudoers.d/zabbix_agentd_user (and include that one in backup) and add a new sudoers.d/zabbix_agentd file that is not included in the backup and is not supposed to be modified by the user. Would that be a feasible solution ?
I would do the save as above. Rename it to something that it is going to be inactive. sudo shouldn’t read it.
That way it is consistent, and users who have set up Zabbix like this, will have done things manually anyways and should know how to carry those changes over.
Hope this helps.
-Michael
Regards Robin
Michael Tremer schreef op ma 21-02-2022 om 11:41 [+0000]:
Hello,
On 20 Feb 2022, at 22:18, Robin Roevens robin.roevens@disroot.org wrote:
Hi Michael
Michael Tremer schreef op zo 20-02-2022 om 18:10 [+0000]:
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’t designed for this scale.
In order to avoid overwriting any existing configuration, we backup everything, extract the new package which will then overwrite the existing configuration 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 place which is what pakfire in IPFire 3 does.
The current method indeed is probably the best possible considering the way pakfire currently works when updating an addon. But for as far as I currently understand it, when you uninstall an addon, all config files are backed up and then are removed (due to being in the rootfile). For the user the addon is gone on the system. If the user opts to install the addon again, say about half a year or a year later, the install will restore the backup of the config it took during uninstall half a year ago. I think this will cause confusion in many cases? Is this implemented this way for a good reason? or just to accommodate the update procedure without much further thought?
I am not if this is for the best reason, but it prevents that people will lose their configuration for any reason and there is an easy option to drop configuration if you want to.
Although it might not be the best, it is a good solution.
I myself (if I didn't know how pakfire worked internally) would expect that if I uninstalled an addon, checked and removed potentially left- over config files, that a new install would give me a fresh install which I would have to configure manually again.
If pakfire worked that way, the user could make a copy of his config himself, uninstall and re-install an addon to have a fresh config which he then could merge himself with his old config-copy to make the addon work again.
So if there is no real reason to always backup on uninstall I would like to propose to perform the backup restore in the actual update- script instead of in the install and uninstall scripts? This way there is a quite logical way for the average user to start over with a fresh install of an addon. That would feel much more 'natural' to me.
There is the reason, that there is no other way at the moment than backing it up and restoring it. Otherwise the configuration will always be overwritten which is not what we want at all.
Additionally, I would want all packages to behave the same. If we change this for Zabbix, we will have to change this for everything else, too.
Anyway this discussion about pakfire working is maybe worth its own thread as it is not really zabbix-agent specific.
Lots of other distributions work in a similar way where they rename the existing 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 that they don’t have to do this. The correct answer is probably somewhere in the middle.
What we do in practise is: We keep systems consistent with their previous behaviour. An update should never change that (there are of course exceptions to every rule). New features might only be activated on new systems.
The problem I see with this is that if software provided by an addon is for example deprecating one or more config-options. Keeping the systems constistent would mean
- not providing any newer version for that addon anymore, which I
don't think is what we want. Or
- trying to 'convert' the possibly user-changed deprecated config-
setting in the config file using sed, which I can see failing in may ways :-) Or
This is what we do quite regularly and it has never failed.
Ultimately, if upstream decides to discontinue support for something, there isn’t much else that we can do.
- providing the user with a straight forward way to reinstall an
addon completely afresh, and/or
- what I'm trying to do here, provide the user with the new config
in some easily accessible way (currently .ipfirenew, but could be a simpler .example, see below), keeping his old config active possibly making the new addon version fail to work, but giving him the possibility to manually merge his deprecated config to what the current version of the addon-software expects.
I am not sure how they should know about those changes.
Showing a diff is probably hard to understand for many users and showing that diff on the UI is even more difficult.
I am not against *what* you are trying to achieve at all. I am just not sure if the *how* is the best.
How about just copying the configuration and put it next to the configuration file with a “.sample” suffix? Then people are still on their own, but I would consider a sample suffix more clear than a .ipfirenew because that doesn’t tell me much about what I should be doing with it.
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 the things they want? Would that be overkill for the possible options?
As I said before, I would indeed prefer a web ui for the config of the addon. That way we are in complete control of the config file. And I plan to build such a page (I have already put some effort in it, but it is not even nearly ready for now). The page should give the user access to all possible configuration options. If not, we could handicap/limit the use of the agent or force the advanced user to still manually tinker with the config file.
But the zabbix agent has many options including defining certificates and encryption keys for communication and a web ui should do sanity checking on all options as well as provide methods to upload and/or generate those certs/keys so it is not a page that is easily designed overnight. But it is coming sooner or later.
Wouldn’t the system automatically generate any keys for the agent?
Scrolling through the configuration, I do not see anything the user would want to change. Do you have an example for me to understand this better?
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 “system configuration file”. It will 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 package 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.
Having some example configuration in a location the user would normally not look at is probably not helpful.
I agree with the "location the user would normally not look at". But as I currently see it, I would like to add the the config example next to the actual config. (I see this happen in many software packages in other linux distro's too. Granted, most of the time it is the vendor itself that provides that example config, not the distro. But since we don't have config merging or '.rpmnew' systems as those distro's do have, I see this as some kind of middle way)
So /etc/zabbix_agentd/ in a fresh install would contain
- zabbix_agentd.conf.example - the config as shipped with the
zabbix source, but renamed to '.example' during build. (with all options in it accompanied with option documentation as comments.)
Okay. I can live with this.
- zabbix_agentd.conf - the active config, provided by us, with only
the bare minimum of options required for the agent to run (secure). - this config will not be altered by us after initial install due to the backup/restore.
Unless we need to remove any deprecated options, etc. Agreed.
This way the example config is automatically accurate for the current version of the addon. And the user stays in complete control of his own config in the same way it is in other addons.
Until the web ui is finished..
That sounds good to me.
If you want them to configure things themselves, why not provide good documentation on the wiki?
I do not 'want' them to configure things themselves.. but if they want to actually use the agent they have to at least point the agent to their zabbix server. So minimal manual configuration is required, and that is also already documented on the wiki. But the agent has many options and possibilities and I don't think it is our job to provide extensive non-IPFire specific configuration documentation as that is the job of the vendor (and in case of Zabbix the docs are there and very clear).
No, that would just be duplicating documentation.
-Michael
But I do am convinced that we should provide a straight-forward way for the more advanced user to get a version of the default config as it is shipped with the current release of the software, especially when it is as verbose in documentation comments as provided by Zabbix.
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 “.user” or “.local” to make it clear that users should make their own changes here.
Ok, for the sudoers, I will go this route then.
Robin
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
Regards
Robin
-Michael
> On 9 Feb 2022, at 23:26, Robin Roevens > robin.roevens@disroot.org > wrote: > > - Update from 4.2.6 to latest LTS version 5.0.20 > See release notes: https://www.zabbix.com/rn/rn5.0.20 > > Signed-off-by: Robin Roevens robin.roevens@disroot.org > --- > config/zabbix_agentd/zabbix_agentd.conf | 135 > ++++++++++++++++++++++-- > lfs/zabbix_agentd | 11 +- > 2 files changed, 132 insertions(+), 14 deletions(-) > > 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=0 > # Default: > # SourceIP= > > -### 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=system.run[*] is added by default. > # > # Mandatory: no > # Default: > -# EnableRemoteCommands=0 > +# DenyKey=system.run[*] > + > +### Option: EnableRemoteCommands - Deprecated, use > AllowKey=system.run[*] or DenyKey=system.run[*] instead > +# Internal alias for AllowKey/DenyKey parameters > depending on > value: > +# 0 - DenyKey=system.run[*] > +# 1 - AllowKey=system.run[*] > +# > +# Mandatory: no > > ### Option: LogRemoteCommands > # Enable logging of executed shell commands as > warnings. > @@ -177,6 +196,28 @@ ServerActive=127.0.0.1 > # Default: > # HostMetadataItem= > > +### 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= > + > +### 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= > + > ### Option: RefreshActiveChecks > # How often list of active checks is refreshed, in > seconds. > # > @@ -265,7 +306,6 @@ ServerActive=127.0.0.1 > > Include=/etc/zabbix_agentd/zabbix_agentd.d/*.conf > > - > ####### USER-DEFINED MONITORED PARAMETERS ####### > > ### Option: UnsafeUserParameters > @@ -299,7 +339,7 @@ > Include=/etc/zabbix_agentd/zabbix_agentd.d/*.conf > # > # Mandatory: no > # Default: > -# LoadModulePath=/usr/lib/modules > +# LoadModulePath=${libdir}/modules > > LoadModulePath=/usr/lib/zabbix > > @@ -357,14 +397,14 @@ LoadModulePath=/usr/lib/zabbix > # TLSCRLFile= > > ### Option: TLSServerCertIssuer > -# Allowed server certificate issuer. > +# Allowed server certificate issuer. > # > # Mandatory: no > # Default: > # TLSServerCertIssuer= > > ### Option: TLSServerCertSubject > -# Allowed server certificate subject. > +# Allowed server certificate subject. > # > # Mandatory: no > # Default: > @@ -397,3 +437,80 @@ LoadModulePath=/usr/lib/zabbix > # Mandatory: no > # Default: > # TLSPSKFile= > + > +####### 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= > + > +### 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= > + > +### 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= > + > +### 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= > + > +### 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= > + > +### 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= > + > +####### 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= > 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 @@ > ########################################################### > #### > #### > ############ > # > > > # > # IPFire.org - A linux based > firewall # > -# Copyright (C) 2007-2019 IPFire Team > info@ipfire.org # > +# Copyright (C) 2007-2022 IPFire Team > info@ipfire.org # > # > > > # > # 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 @@ > > include Config > > -VER = 4.2.6 > +VER = 5.0.20 > > THISAPP = zabbix-$(VER) > DL_FILE = $(THISAPP).tar.gz > @@ -32,7 +32,7 @@ DL_FROM = $(URL_IPFIRE) > DIR_APP = $(DIR_SRC)/$(THISAPP) > TARGET = $(DIR_INFO)/$(THISAPP) > PROG = zabbix_agentd > -PAK_VER = 4 > +PAK_VER = 5 > DEPS = > > ########################################################### > #### > #### > ############ > @@ -43,7 +43,7 @@ objects = $(DL_FILE) > > $(DL_FILE) = $(DL_FROM)/$(DL_FILE) > > -$(DL_FILE)_MD5 = 6cd55cd743d416d9ffbf2e6fdee680ee > +$(DL_FILE)_MD5 = 52df25394f9a4cf83ff55278b23e6295 > > install : $(TARGET) > > @@ -80,7 +80,8 @@ $(TARGET) : $(patsubst > %,$(DIR_DL)/%,$(objects)) > --prefix=/usr \ > --enable-agent \ > --sysconfdir=/etc/zabbix_agentd \ > - --with-openssl > + --with-openssl \ > + --with-libcurl > > cd $(DIR_APP) && make > cd $(DIR_APP) && make install > -- > 2.34.1 > > > -- > Dit bericht is gescanned op virussen en andere gevaarlijke > inhoud door MailScanner en lijkt schoon te zijn. >
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.
-- Dit bericht is gescanned op virussen en andere gevaarlijke inhoud door MailScanner en lijkt schoon te zijn.
- Add agent modules-dir to backup - Remove original, not used agent modules dir from rootfile - Create modules-dir during install if it not already exists - bugfix: Add existence check before creating log-dir, avoiding error messages if it already exists from a previous install - bugfix: add extract_backup_includes to update.sh script to make sure backup includes exist when backup is taken.
Signed-off-by: Robin Roevens robin.roevens@disroot.org --- config/backup/includes/zabbix_agentd | 3 ++- config/rootfiles/packages/zabbix_agentd | 2 +- src/paks/zabbix_agentd/install.sh | 4 ++-- src/paks/zabbix_agentd/update.sh | 1 + 4 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/config/backup/includes/zabbix_agentd b/config/backup/includes/zabbix_agentd index cba18d772..d3305cb96 100644 --- a/config/backup/includes/zabbix_agentd +++ b/config/backup/includes/zabbix_agentd @@ -1,2 +1,3 @@ /etc/sudoers.d/zabbix -/etc/zabbix_agentd/* +/etc/zabbix_agentd/ +/usr/lib/zabbix/ diff --git a/config/rootfiles/packages/zabbix_agentd b/config/rootfiles/packages/zabbix_agentd index 4420bda05..d9bbc3ccf 100644 --- a/config/rootfiles/packages/zabbix_agentd +++ b/config/rootfiles/packages/zabbix_agentd @@ -8,7 +8,7 @@ etc/zabbix_agentd/zabbix_agentd.d etc/zabbix_agentd/zabbix_agentd.d/userparameter_pakfire.conf usr/bin/zabbix_get usr/bin/zabbix_sender -usr/lib/modules +#usr/lib/modules usr/lib/zabbix usr/sbin/zabbix_agentd #usr/share/man/man1/zabbix_get.1 diff --git a/src/paks/zabbix_agentd/install.sh b/src/paks/zabbix_agentd/install.sh index e1450a1d8..cf435918d 100644 --- a/src/paks/zabbix_agentd/install.sh +++ b/src/paks/zabbix_agentd/install.sh @@ -39,8 +39,8 @@ ln -sf ../init.d/zabbix_agentd /etc/rc.d/rc0.d/K02zabbix_agentd ln -sf ../init.d/zabbix_agentd /etc/rc.d/rc6.d/K02zabbix_agentd
# Create additonal directories and set permissions -mkdir -pv /var/log/zabbix -chown zabbix.zabbix /var/log/zabbix +[ -d /var/log/zabbix ] || ( mkdir -pv /var/log/zabbix && chown zabbix.zabbix /var/log/zabbix ) +[ -d /usr/lib/zabbix ] || ( mkdir -pv /usr/lib/zabbix && chown zabbix.zabbix /usr/lib/zabbix )
restore_backup ${NAME} start_service --background ${NAME} diff --git a/src/paks/zabbix_agentd/update.sh b/src/paks/zabbix_agentd/update.sh index 7fc1c96fb..68bba4f80 100644 --- a/src/paks/zabbix_agentd/update.sh +++ b/src/paks/zabbix_agentd/update.sh @@ -22,6 +22,7 @@ ############################################################################ # . /opt/pakfire/lib/functions.sh +extract_backup_includes ./uninstall.sh ./install.sh
- Install user changeable configfiles as .ipfirenew-files to allow user to merge their config with the new version. (warnings will be displayed during update when manual review is required). If the configfiles are not yet present, the .ipfirenew-files will be renamed to the actual configfiles. And if an existing configfile does not differ from the new one, the .ipfirenew-file will be removed. - Make sure .ipfirenew files and userparameter_pakfire.conf are not included in backup during uninstall to prevent newer versions from being overwritten by backup restore during install. - Explicitly remove installed sudoers file as it is not removed by remove_files due to the renaming from .ipfirenew - Added comment in userparameter_pakfire.conf not to modify the file as it will be overwritten on update
Signed-off-by: Robin Roevens robin.roevens@disroot.org --- config/rootfiles/packages/zabbix_agentd | 4 +-- .../zabbix_agentd/userparameter_pakfire.conf | 7 +++++ lfs/zabbix_agentd | 7 +++-- src/paks/zabbix_agentd/install.sh | 29 +++++++++++++++++++ src/paks/zabbix_agentd/uninstall.sh | 8 +++++ 5 files changed, 51 insertions(+), 4 deletions(-)
diff --git a/config/rootfiles/packages/zabbix_agentd b/config/rootfiles/packages/zabbix_agentd index d9bbc3ccf..6f7090fe7 100644 --- a/config/rootfiles/packages/zabbix_agentd +++ b/config/rootfiles/packages/zabbix_agentd @@ -1,9 +1,9 @@ etc/logrotate.d/zabbix_agentd etc/rc.d/init.d/zabbix_agentd -etc/sudoers.d/zabbix +etc/sudoers.d/zabbix.ipfirenew etc/zabbix_agentd etc/zabbix_agentd/scripts -etc/zabbix_agentd/zabbix_agentd.conf +etc/zabbix_agentd/zabbix_agentd.conf.ipfirenew etc/zabbix_agentd/zabbix_agentd.d etc/zabbix_agentd/zabbix_agentd.d/userparameter_pakfire.conf usr/bin/zabbix_get diff --git a/config/zabbix_agentd/userparameter_pakfire.conf b/config/zabbix_agentd/userparameter_pakfire.conf index aa2e80f5c..09ddf61c9 100644 --- a/config/zabbix_agentd/userparameter_pakfire.conf +++ b/config/zabbix_agentd/userparameter_pakfire.conf @@ -1,2 +1,9 @@ +# +# IPFire specific configuration file +# +# +# DO NOT MODIFY - Changes will be overwritten when zabbix_agentd addon is +# updated. +# ### Parameter for monitoring pakfire status UserParameter=pakfire.status,sudo /opt/pakfire/pakfire status diff --git a/lfs/zabbix_agentd b/lfs/zabbix_agentd index 28fe97b4f..dae59fe48 100644 --- a/lfs/zabbix_agentd +++ b/lfs/zabbix_agentd @@ -90,8 +90,11 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) -rmdir /etc/zabbix_agentd/zabbix_agentd.conf.d -mkdir -pv /etc/zabbix_agentd/zabbix_agentd.d -mkdir -pv /etc/zabbix_agentd/scripts + # Remove original config + @rm -f /etc/zabbix_agentd/zabbix_agentd.conf + # And replace with our own config install -v -m 644 $(DIR_SRC)/config/zabbix_agentd/zabbix_agentd.conf \ - /etc/zabbix_agentd/zabbix_agentd.conf + /etc/zabbix_agentd/zabbix_agentd.conf.ipfirenew install -v -m 644 $(DIR_SRC)/config/zabbix_agentd/userparameter_pakfire.conf \ /etc/zabbix_agentd/zabbix_agentd.d/userparameter_pakfire.conf
@@ -111,7 +114,7 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects))
# Install sudoers include file install -v -m 644 $(DIR_SRC)/config/zabbix_agentd/sudoers \ - /etc/sudoers.d/zabbix + /etc/sudoers.d/zabbix.ipfirenew
# Install include file for backup install -v -m 644 $(DIR_SRC)/config/backup/includes/zabbix_agentd \ diff --git a/src/paks/zabbix_agentd/install.sh b/src/paks/zabbix_agentd/install.sh index cf435918d..4ef4b5be6 100644 --- a/src/paks/zabbix_agentd/install.sh +++ b/src/paks/zabbix_agentd/install.sh @@ -23,6 +23,23 @@ # . /opt/pakfire/lib/functions.sh
+review_required=false + +function setup_configfile() { + # Puts configfile in place if it does not already exist or + # remove the shipped version if it does not differ from existing file + configfile=$1 + + if [ ! -f $configfile ]; then + mv $configfile.ipfirenew $configfile + elif diff -q $configfile $configfile.ipfirenew >/dev/null; then + rm -f $configfile.ipfirenew + else + echo "WARNING: new $configfile saved as $configfile.ipfirenew for manual review" + review_required=true + fi +} + if ! getent group zabbix &>/dev/null; then groupadd -g 118 zabbix fi @@ -41,6 +58,18 @@ ln -sf ../init.d/zabbix_agentd /etc/rc.d/rc6.d/K02zabbix_agentd # Create additonal directories and set permissions [ -d /var/log/zabbix ] || ( mkdir -pv /var/log/zabbix && chown zabbix.zabbix /var/log/zabbix ) [ -d /usr/lib/zabbix ] || ( mkdir -pv /usr/lib/zabbix && chown zabbix.zabbix /usr/lib/zabbix ) +[ -d /etc/zabbix_agentd/scripts ] || ( mkdir -pv /etc/zabbix_agentd/scripts && chown zabbix.zabbix /etc/zabbix_agentd/scripts )
restore_backup ${NAME} + +# Put zabbix configfiles in place +setup_configfile /etc/zabbix_agentd/zabbix_agentd.conf +setup_configfile /etc/sudoers.d/zabbix + +if $review_required; then + echo "WARNING: New versions of some configfile(s) where provided as .ipfirenew-files." + echo " They may need manual review in order to take advantage of new features" + echo " or even to make this version of ${NAME} work." +fi + start_service --background ${NAME} diff --git a/src/paks/zabbix_agentd/uninstall.sh b/src/paks/zabbix_agentd/uninstall.sh index edff3b818..0770b40f1 100644 --- a/src/paks/zabbix_agentd/uninstall.sh +++ b/src/paks/zabbix_agentd/uninstall.sh @@ -23,8 +23,16 @@ # . /opt/pakfire/lib/functions.sh stop_service ${NAME} + +# Remove .ipfirenew files in advance so they won't be included in backup +rm -rfv /etc/zabbix_agentd/zabbix_agentd.conf.ipfirenew /etc/sudoers.d/zabbix.ipfirenew +# Remove IPFire provided userparameter config files in advance +rm -rfv /etc/zabbix_agentd/zabbix_agentd.d/userparameter_pakfire.conf + make_backup ${NAME} remove_files
+# Remove sudoers file +rm -rvf /etc/sudoers.d/zabbix # Remove init-scripts and symlinks rm -rfv /etc/rc.d/rc*.d/*zabbix_agentd
- Change zabbix_agentd.conf during install to only listen on the GREEN ip by default.
Signed-off-by: Robin Roevens robin.roevens@disroot.org --- config/zabbix_agentd/zabbix_agentd.conf | 2 ++ src/paks/zabbix_agentd/install.sh | 10 ++++++++++ 2 files changed, 12 insertions(+)
diff --git a/config/zabbix_agentd/zabbix_agentd.conf b/config/zabbix_agentd/zabbix_agentd.conf index aa8b899dc..5eea7d4b5 100644 --- a/config/zabbix_agentd/zabbix_agentd.conf +++ b/config/zabbix_agentd/zabbix_agentd.conf @@ -132,6 +132,8 @@ Server=127.0.0.1 # Default: # ListenIP=0.0.0.0
+ListenIP=GREEN_ADDRESS + ### Option: StartAgents # Number of pre-forked instances of zabbix_agentd that process passive checks. # If set to 0, disables passive checks and the agent will not listen on any TCP port. diff --git a/src/paks/zabbix_agentd/install.sh b/src/paks/zabbix_agentd/install.sh index 4ef4b5be6..f7218a603 100644 --- a/src/paks/zabbix_agentd/install.sh +++ b/src/paks/zabbix_agentd/install.sh @@ -62,6 +62,16 @@ ln -sf ../init.d/zabbix_agentd /etc/rc.d/rc6.d/K02zabbix_agentd
restore_backup ${NAME}
+# By default, only listen on GREEN +( + eval $(/usr/local/bin/readhash /var/ipfire/ethernet/settings) + if [ -n "${GREEN_ADDRESS}" ]; then + sed -i -e "s|ListenIP=GREEN_ADDRESS|ListenIP=${GREEN_ADDRESS}|g" /etc/zabbix_agentd/zabbix_agentd.conf.ipfirenew + else + sed -i -e "|ListenIP=GREEN_ADDRESS|d" /etc/zabbix_agentd/zabbix_agentd.conf.ipfirenew + fi +) || : + # Put zabbix configfiles in place setup_configfile /etc/zabbix_agentd/zabbix_agentd.conf setup_configfile /etc/sudoers.d/zabbix
Provide IPFire specific items for the Zabbix server to monitor: - ipfire.net.gateway.pingtime: Internet Line Quality - ipfire.net.gateway.ping: Internet connection - ipfire.net.fw.hits.raw: JSON formatted list of Firewall hits/chain - ipfire.dhcpd.clients: Number of active DHCP leases - ipfire.captive.clients: Number of Captive Portal clients
Signed-off-by: Robin Roevens robin.roevens@disroot.org --- config/rootfiles/packages/zabbix_agentd | 1 + config/zabbix_agentd/sudoers | 2 +- config/zabbix_agentd/userparameter_ipfire.conf | 18 ++++++++++++++++++ lfs/zabbix_agentd | 5 ++++- src/paks/zabbix_agentd/uninstall.sh | 2 +- 5 files changed, 25 insertions(+), 3 deletions(-) create mode 100644 config/zabbix_agentd/userparameter_ipfire.conf
diff --git a/config/rootfiles/packages/zabbix_agentd b/config/rootfiles/packages/zabbix_agentd index 6f7090fe7..fc62217f2 100644 --- a/config/rootfiles/packages/zabbix_agentd +++ b/config/rootfiles/packages/zabbix_agentd @@ -6,6 +6,7 @@ etc/zabbix_agentd/scripts etc/zabbix_agentd/zabbix_agentd.conf.ipfirenew etc/zabbix_agentd/zabbix_agentd.d etc/zabbix_agentd/zabbix_agentd.d/userparameter_pakfire.conf +etc/zabbix_agentd/zabbix_agentd.d/userparameter_ipfire.conf usr/bin/zabbix_get usr/bin/zabbix_sender #usr/lib/modules diff --git a/config/zabbix_agentd/sudoers b/config/zabbix_agentd/sudoers index 1b362a4fd..c73a95667 100644 --- a/config/zabbix_agentd/sudoers +++ b/config/zabbix_agentd/sudoers @@ -14,4 +14,4 @@ # Append / edit the following list of commands to fit your needs: # Defaults:zabbix !requiretty -zabbix ALL=(ALL) NOPASSWD: /opt/pakfire/pakfire status +zabbix ALL=(ALL) NOPASSWD: /opt/pakfire/pakfire status, /usr/sbin/fping, /usr/local/bin/getipstat diff --git a/config/zabbix_agentd/userparameter_ipfire.conf b/config/zabbix_agentd/userparameter_ipfire.conf new file mode 100644 index 000000000..88f5447e7 --- /dev/null +++ b/config/zabbix_agentd/userparameter_ipfire.conf @@ -0,0 +1,18 @@ +# IPFire specific configuration file +# +# +# DO NOT MODIFY - Changes will be overwritten when zabbix_agentd addon is +# updated. +# +# Parameters for monitoring IPFire specific metrics +# +# Internet Gateway ping timings, can be used to measure "Internet Line Quality" +UserParameter=ipfire.net.gateway.pingtime,sudo /usr/sbin/fping -c 3 gateway 2>&1 | tail -n 1 | awk '{print $NF}' | cut -d '/' -f2 +# Internet Gateway availability, can be used to check Internet connection +UserParameter=ipfire.net.gateway.ping,sudo /usr/sbin/fping -q -r 3 gateway; [ ! $? ]; echo $? +# Firewall Filter Forward chain drops in bytes/chain (JSON), can be used for discovery of firewall chains and monitoring of firewall hits on each chain +UserParameter=ipfire.net.fw.hits.raw,sudo /usr/local/bin/getipstat -xf | grep "/* DROP_.* */$" | awk 'BEGIN { ORS = ""; print "["} { printf "%s{"chain": "%s", "bytes": "%s"}", separator, substr($11, 6), $2; separator = ", "; } END { print"]" }' +# Number of currently Active DHCP leases +UserParameter=ipfire.dhcpd.clients,grep -s -E 'lease|bind' /var/state/dhcp/dhcpd.leases | sed ':a;/{$/{N;s/\n//;ba}' | grep "state active" | wc -l +# Number of Captive Portal clients +UserParameter=ipfire.captive.clients,awk -F ',' 'length($2) == 17 {sum += 1} END {if (length(sum) == 0) print 0; else print sum}' /var/ipfire/captive/clients \ No newline at end of file diff --git a/lfs/zabbix_agentd b/lfs/zabbix_agentd index dae59fe48..f909b8faa 100644 --- a/lfs/zabbix_agentd +++ b/lfs/zabbix_agentd @@ -33,7 +33,8 @@ DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = zabbix_agentd PAK_VER = 5 -DEPS = + +DEPS = fping
############################################################################### # Top-level Rules @@ -97,6 +98,8 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) /etc/zabbix_agentd/zabbix_agentd.conf.ipfirenew install -v -m 644 $(DIR_SRC)/config/zabbix_agentd/userparameter_pakfire.conf \ /etc/zabbix_agentd/zabbix_agentd.d/userparameter_pakfire.conf + install -v -m 644 $(DIR_SRC)/config/zabbix_agentd/userparameter_ipfire.conf \ + /etc/zabbix_agentd/zabbix_agentd.d/userparameter_ipfire.conf
# Create directory for additional agent modules -mkdir -pv /usr/lib/zabbix diff --git a/src/paks/zabbix_agentd/uninstall.sh b/src/paks/zabbix_agentd/uninstall.sh index 0770b40f1..f87ef8c17 100644 --- a/src/paks/zabbix_agentd/uninstall.sh +++ b/src/paks/zabbix_agentd/uninstall.sh @@ -27,7 +27,7 @@ stop_service ${NAME} # Remove .ipfirenew files in advance so they won't be included in backup rm -rfv /etc/zabbix_agentd/zabbix_agentd.conf.ipfirenew /etc/sudoers.d/zabbix.ipfirenew # Remove IPFire provided userparameter config files in advance -rm -rfv /etc/zabbix_agentd/zabbix_agentd.d/userparameter_pakfire.conf +rm -rfv /etc/zabbix_agentd/zabbix_agentd.d/userparameter_pakfire.conf /etc/zabbix_agentd/zabbix_agentd.d/userparameter_ipfire.conf
make_backup ${NAME} remove_files
-
Michael Tremer -
Robin Roevens