From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4ZHwDm40mcz32pC for ; Wed, 19 Mar 2025 17:09:44 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R10" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4ZHwDh6pwfz32p7 for ; Wed, 19 Mar 2025 17:09:40 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4ZHwDh0vLRz2s; Wed, 19 Mar 2025 17:09:40 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1742404180; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eq8UXeujnO+dKqmnPBEMTazMuPTu2gfarg7Q07u6R+Y=; b=5vXeHQrrKdS2xJ3QDRpNQ27wnSYGe6a5mtrh0emuCdDN4GayY7N55GUR5sufvHT5lhIxRN SBg79ZQQ5YnvnxBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1742404180; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eq8UXeujnO+dKqmnPBEMTazMuPTu2gfarg7Q07u6R+Y=; b=A+eb5ev7nE0OARjZDtWLBdt/MmUNohnx2/CnspP9LRQVNwoglvMiDxpZUbWFJC7xPdGD4z 9+oDFdsKLOHF6eDxeGtgLDivNUBYagGRKqZeCbvtMiAD6TqNYtT24ce8yVnDDiTv8aZ6Jm w9eydxEy2fS34GwzYRsJECnKeA7hLHvXU499aMEYW3wMP29lhYpjK6er9G35HjceP2e2cz LQYyiEbTuGwp6g+ySLsTSmsDFJW3cvgsV+bexzxM9b92F/r0LR6o2KSLV0nsJVCqThsQS6 OUHLxf34JSSTX0jzF/hpyONYaIlcqTNsIy/wS6C3UsJDf9zFS6dgHSePSbUwUA== Message-ID: <4f4ea978-6d49-4c6e-9870-6bdb61650c73@ipfire.org> Date: Wed, 19 Mar 2025 18:09:35 +0100 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: MIME-Version: 1.0 Subject: Re: [PATCH 1/3] collectd: Fixes bug13832 - uncomments include openvpn plugin only if openvpn is running To: Michael Tremer References: <20250317195123.2092-1-adolf.belka@ipfire.org> Content-Language: en-GB Cc: "IPFire: Development-List" From: Adolf Belka In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Michael, On 19/03/2025 16:56, Michael Tremer wrote: > Hello Adolf, > > In this patch you are checking whether OpenVPN is actually running. > > Should we not check whether it is enabled? That would avoid any kind of races that we might see when collectd is being started before OpenVPN. I did look at the enabled bit first but for a new OpenVPN installation, you could end up with OpenVPN enabled but the Server not started for the first time. In that case the /var/run/ovpnserver.log file would still be empty and so you would get the error messages that flagged up the problem in the first place. The ovpnserver.log gets its contents defined when the server is started and not when it is enabled but not started. Once the OpenVPN server has been started once then the ovpnserver.log file contents satisfy collectd and those contents stay there even if the OpenVPN server is stopped and disabled. So the other option could be to fill the required contents into ovpnserver.log, when red, or blue or orange are enabled and before the server is started. If that change was made then the include openvpn plugin line in collectd.conf could be uncommented based on at least one of the enable options being selected. Should I look at doing the approach of filling the ovpnserver.log with its contents when the openvpn server is enabled on at least one of the interfaces specified. What I don't know is when the openvpn server is running and the openvpn plugin is loaded, are there any issues or error messages when the user does not yet have any client connections defined. I didn't find any when I tested it out on a vm system with the root/host certificate set created, the openvpn server enabled on red, the openvpn server started and the openvpn plugin uncommented in the collectd.conf file but with no client configurations created yet so I don't believe there should be any problem. Regards, Adolf. > > -Michael > >> On 17 Mar 2025, at 19:51, Adolf Belka wrote: >> >> - Added code to check if openvpn.pid exists and only then uncomment the include openvpn >> plugin line in collectd.conf >> - Tested out on my vm testbed and the include openvpn plugin line in collectd.conf is >> only uncommented if the openvpn server is run ning and has a pid. >> >> Fixes: Bug13832 >> Tested-by: Adolf Belka >> Signed-off-by: Adolf Belka >> --- >> src/initscripts/system/collectd | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/src/initscripts/system/collectd b/src/initscripts/system/collectd >> index 263511fc7..f86b64e9d 100644 >> --- a/src/initscripts/system/collectd >> +++ b/src/initscripts/system/collectd >> @@ -143,6 +143,13 @@ case "$1" in >> sed -i -e "s|^#LoadPlugin swap|LoadPlugin swap|g" /etc/collectd.conf >> fi >> >> + # Enable openvpn plugin if openvpn.pid found >> + if [ ! -e /var/run/openvpn.pid ]; then >> + sed -i -e 's|^include "/etc/collectd.vpn"$|#include "/etc/collectd.vpn"|g' /etc/collectd.conf >> + else >> + sed -i -e 's|^#include "/etc/collectd.vpn"$|include "/etc/collectd.vpn"|g' /etc/collectd.conf >> + fi >> + >> if [ $(date +%Y) -gt 2011 ]; then >> boot_mesg "Starting Collection daemon..." >> /usr/sbin/collectd -C /etc/collectd.conf >> -- >> 2.49.0 >> >> > >