From: Michael Tremer <michael.tremer@ipfire.org>
To: Adolf Belka <adolf.belka@ipfire.org>
Cc: "IPFire: Development-List" <development@lists.ipfire.org>
Subject: Re: [PATCH 1/3] collectd: Fixes bug13832 - uncomments include openvpn plugin only if openvpn is running
Date: Fri, 21 Mar 2025 12:41:16 +0000 [thread overview]
Message-ID: <8F7DC93E-9E21-47E7-B9D2-F9772A1F68EE@ipfire.org> (raw)
In-Reply-To: <4f4ea978-6d49-4c6e-9870-6bdb61650c73@ipfire.org>
Hello,
> On 19 Mar 2025, at 17:09, Adolf Belka <adolf.belka@ipfire.org> wrote:
>
> 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.
Yes, I assume so, but I thought this was a better and more robust option than the other way around?
> 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.
Just write some dummy data into it? Possible, but again seems to be a workaround rather than a fix.
Should we not try to upstream the change that at least nothing is being logged whenever the file exists but is empty?
> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org>
>>> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
>>> ---
>>> 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
>>>
>>>
>
prev parent reply other threads:[~2025-03-21 12:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-17 19:51 Adolf Belka
2025-03-17 19:51 ` [PATCH 2/3] collectd.conf: Fixes bug13832 - include openvpn plugin line commented out by default Adolf Belka
2025-03-17 19:51 ` [PATCH 3/3] ovpnmain.cgi: Fixes bug13832 - restart collectd initscript on openvpn server status change Adolf Belka
2025-03-19 15:56 ` [PATCH 1/3] collectd: Fixes bug13832 - uncomments include openvpn plugin only if openvpn is running Michael Tremer
2025-03-19 17:09 ` Adolf Belka
2025-03-21 12:34 ` Michael Tremer
2025-03-21 12:41 ` Michael Tremer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8F7DC93E-9E21-47E7-B9D2-F9772A1F68EE@ipfire.org \
--to=michael.tremer@ipfire.org \
--cc=adolf.belka@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox