Bug 11713 - traffic graphs of deleted OpenVPN RW connections still show up in WebUI
Summary: traffic graphs of deleted OpenVPN RW connections still show up in WebUI
Status: ASSIGNED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all All
: Will affect an average number of users Aesthetic Issue
Assignee: Erik Kapfer
QA Contact: Peter Müller
URL:
Keywords:
: 11309 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-05-03 16:57 UTC by Peter Müller
Modified: 2021-11-05 13:16 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Müller 2018-05-03 16:57:44 UTC
The WebUI lists traffic graphs for OpenVPN road warrior and net-to-net (N2N) connections. However, if an roadwarrior connection is deleted, the concurring graph is not removed too. Problem persists after a reboot.
Comment 1 Michael Tremer 2018-06-18 15:05:33 UTC
*** Bug 11309 has been marked as a duplicate of this bug. ***
Comment 2 Peter Müller 2019-05-11 09:52:09 UTC
- ping -
Comment 3 Peter Müller 2020-04-10 11:16:29 UTC
For newly deleted connection, Erik fixed this in https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=fa4dbe2745d2f7b025c524003adeb9be6f039c78 .

RDD graphs of already deleted connections are currently not cleaned up, which we should to in the second step.
Comment 4 Peter Müller 2020-04-10 11:16:58 UTC
@Erik: Could you have a look at this?
Comment 5 Michael Tremer 2020-04-14 11:32:10 UTC
How are we deleting files of connections that have already been deleted?

They still show up in the Status page.
Comment 6 Erik Kapfer 2020-04-14 13:46:08 UTC
Hi all,
(In reply to Michael Tremer from comment #5)
> How are we deleting files of connections that have already been deleted?
> 
> They still show up in the Status page.

may with something like this -->

#!/bin/bash

OLD=$(find /var/log/rrd/collectd/localhost -name 'openvpn-*' | awk -F'/' '{ print $7 }')
EXISTING=$(awk -F',' '{ print "openvpn-"$4 }' /var/ipfire/ovpn/ovpnconfig)

RMLIST=$(diff -ia --suppress-common-lines <( printf "%s\n" "${OLD[@]}" ) <( printf "%s\n" "${EXISTING[@]}" ) | grep '<' | sed 's|^< |/var/log/rrd/collectd/localhost/|g')

echo "$RMLIST"

# EOF

to arm it, use rm -rf instead of echo in update.sh ? 

(In reply to Peter Müller from comment #3)
> For newly deleted connection, Erik fixed this in
> https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;
> h=fa4dbe2745d2f7b025c524003adeb9be6f039c78 .

This is patch do not really works. I fiddled around by deleting the RRD directories via openvpnctrl with no luck. By deleting the whole X509 the code mentioned here --> https://lists.ipfire.org/pipermail/development/2020-April/007438.html at least worked but that´s not pretty in my opinion even we have a solution mostly ready in openvpnctrl. My C++ foo is not that good, it might therefore be better if someone else can debug this there ?

Best,

Erik
Comment 7 Michael Tremer 2020-04-14 20:29:40 UTC
(In reply to Erik Kapfer from comment #6)
> may with something like this -->
> 
> #!/bin/bash
> 
> OLD=$(find /var/log/rrd/collectd/localhost -name 'openvpn-*' | awk -F'/' '{
> print $7 }')
> EXISTING=$(awk -F',' '{ print "openvpn-"$4 }' /var/ipfire/ovpn/ovpnconfig)
> 
> RMLIST=$(diff -ia --suppress-common-lines <( printf "%s\n" "${OLD[@]}" ) <(
> printf "%s\n" "${EXISTING[@]}" ) | grep '<' | sed 's|^<
> |/var/log/rrd/collectd/localhost/|g')
> 
> echo "$RMLIST"
> 
> # EOF

I have absolutely no idea what this code does. I suppose this should be a small script then so that we do not have to squeeze everything into one line.

> to arm it, use rm -rf instead of echo in update.sh ? 

No, we will already have valid data. We cannot just delete the existing ones.
Comment 8 Erik Kapfer 2020-07-07 12:40:44 UTC
Hi all,
according to Michaels request --> https://community.ipfire.org/t/openvpn-roadwarrior-statistics-graphs-from-removed-user/2640/5 to define the problem more specific, i will leave here a note.

Have tried to use the -drrd option from openvpnctrl via

/usr/local/bin/openvpnctrl --delete-rrd /var/log/rrd/collectd/localhost/{CONNECTION_NAME}/

which did not do anything (please give it also a try) but is called via ovpnmain.cgi.
So it appears to me that something is missing or does not work in this patch --> https://git.ipfire.org/?p=ipfire-2.x.git;a=blobdiff;f=src/misc-progs/openvpnctrl.c;h=5d3f8af73b43ba7b8c6f734ae74648c93bfae567;hp=d20cced7743b80bdfc91c1875b54c2e33d0ca337;hb=e1297cbb7659618c526fdc1ab07e97f57f55fd78;hpb=6b7cbc8f335106a0d8e8860f343a51bda8e14dbb .

It might be great if one with more C foo can take a look into this.

Best,

Erik
Comment 9 Michael Tremer 2020-07-07 13:12:50 UTC
Openvpnctrl should show an error if it cannot run this.

Could you run the command with strace and attach the output please?
Comment 10 Erik Kapfer 2020-07-14 11:47:46 UTC
Sure.

$ strace -e trace=open,read /usr/local/bin/openvpnctrl -drrd /var/log/rrd/collectd/localhost/openvpn-testsonderzeichen 
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\27\0\0\0\0\0\0"..., 832) = 832
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220Z\0\0\0\0\0\0"..., 832) = 832
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`<\2\0\0\0\0\0"..., 832) = 832
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\263\4\0\0\0\0\0"..., 832) = 832
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000\21\0\0\0\0\0\0"..., 832) = 832
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\321\0\0\0\0\0\0"..., 832) = 832
read(3, "DAUTH=BLAKE2b512\nREDIRECT_GW_DEF"..., 4096) = 578
read(3, "", 4096)                       = 0
read(3, "red0", 4096)                   = 4
read(3, "", 4096)                       = 0
read(3, "CONFIG_TYPE=3\nGREEN_DEV=green0\nG"..., 4096) = 1018
read(3, "", 4096)                       = 0
read(3, "1,on,testsoderzeichen,testsonder"..., 4096) = 96
read(3, "", 4096)                       = 0
+++ exited with 0 +++

After execution, the directory is still presant.

$ ls -la /var/log/rrd/collectd/localhost/openvpn-*
/var/log/rrd/collectd/localhost/openvpn-testsonderzeichen:
total 312
drwxr-xr-x  2 root root   4096 May  3 13:16 .
drwxr-xr-x 43 root root   4096 May  4 08:08 ..
-rw-r--r--  1 root root 307712 May  4 16:03 if_octets_derive.rrd
Comment 11 Michael Tremer 2020-07-14 12:43:15 UTC
Hi,

(In reply to Erik Kapfer from comment #10)
> Sure.
> 
> $ strace -e trace=open,read /usr/local/bin/openvpnctrl -drrd
> /var/log/rrd/collectd/localhost/openvpn-testsonderzeichen 
> read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\27\0\0\0\0\0\0"...,
> 832) = 832
> read(3,
> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220Z\0\0\0\0\0\0"..., 832) =
> 832
> read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`<\2\0\0\0\0\0"...,
> 832) = 832
> read(3,
> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\263\4\0\0\0\0\0"..., 832)
> = 832
> read(3,
> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000\21\0\0\0\0\0\0"..., 832)
> = 832
> read(3,
> "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\321\0\0\0\0\0\0"...,
> 832) = 832
> read(3, "DAUTH=BLAKE2b512\nREDIRECT_GW_DEF"..., 4096) = 578
> read(3, "", 4096)                       = 0
> read(3, "red0", 4096)                   = 4
> read(3, "", 4096)                       = 0
> read(3, "CONFIG_TYPE=3\nGREEN_DEV=green0\nG"..., 4096) = 1018
> read(3, "", 4096)                       = 0
> read(3, "1,on,testsoderzeichen,testsonder"..., 4096) = 96
> read(3, "", 4096)                       = 0
> +++ exited with 0 +++
> 
> After execution, the directory is still presant.

We are probably looking for rmdir and unlink sys calls.

Those just opened files and read from them.
Comment 12 Peter Müller 2021-10-23 11:45:00 UTC
- ping -
Comment 13 paul 2021-11-05 13:16:12 UTC
I may have a similar issue. I do not have a 10.0.0.6 device in my network but the Roadwarrior Statistics Graph shows that ip with no activity (-nan). 

The only thing I remember is that last year I connected a Linksys to my network and that linksys had 10.0.0.6 as an ip. Looked in /var/ipfire/ovpn/ dir to find any reference of 10.0.0.6 -- nothing. I don't know where that ip is stored.

Paul