Having similar problems on a test system running on CentOS 8. It looks like the output of gnupg 2.2.9 (RHEL 8) is different from gnupg 2.0.22 (RHEL 7). The newer version, which I’d guess is what the problem Ubuntu/Debian users are using, outputs the info on the subkeys as well:
I have absolutely no knowledge of the gpg in FreePBX, so the whitelisting you, Bill, and Mike mentioned is meaningless to me. I’m simply doing whatever I can to alleviate a problem that I raised with you earlier this year (‘works for me’ was your immediate response) and that has been sitting on an open ticket for 3 months now (https://issues.freepbx.org/browse/FREEPBX-20559). If it’s so easy to fix , why the hell doesn’t someone at Sangoma attend to it? I’d rather not be patching anything.
10 seconds is a whole lot better than it hanging forever (see the above ticket).
I’ve never understood why GUI reloads go through all this gpg business but ‘fwconsole reload’ doesn’t.
The ticket you opened earlier this year was probably closed as “works for me” because as stated several times work is based off of how bugs work in the officially supported distro. Which this isn’t an issue there as stated why previously in this ticket.
Also the ticket you opened up three months ago. No idea why it hasnt been worked on. I haven’t worked for Sangoma since May.
@billsimon started this thread. I’m merely here to help. However your responses really make me feel unwelcome. I dunno. Maybe it’s just me.
No idea. Again I don’t work for Sangoma. However @miken32 took the ideas here and submitted a PR doing exactly what we stated.
The GUI reload actually just spawns fwconsole reload in 15. So I’m not sure why you’d be experiencing that either
To answer why hasn’t it been fixed yet? While FreePBX is ostensibly open source, you’re unlikely to get much traction on fixes for problems that occur off Sangoma’s distro. I run 80 hosted PBXs on various RHEL forks, and figured out a long time ago that if I don’t submit my own patches I’ll just get “WFM” as a response to problems or feature requests that don’t fit in with how Sangoma wants their product to be used. Not a complaint – I realize they’re a company trying to make money off this thing – just an observation.
On FreePBX 15 (up-to-date with EDGE modules enabled) with @miken32’s latest changes incorporated, an ‘fwconsole reload’ takes 3.25 seconds and a GUI reload takes 6.5 seconds (consistent over multiple runs).
[This is not a complaint – it’s simply an observation. This is infinitely better than it’s been since the early betas.]
As I’m no longer in the code daily I only remember the last things I did to fix transient issues on systems that aren’t the FreePBX Distro. Unfortuntately (or fortunately?) these changes only made it into 15.0
That’s what I was thought you were saying in your earlier post. However, a GUI reload takes twice as long as a CLI reload if module signature checking is enabled, but they’re equal if module signature checking is disabled. So I’m still confused as to why, if GUI reloads simply spawn fwconsole reloads, that signature checks being enabled doubles the time fwconsole takes to run when it’s spawned by the GUI vs run from the CLI. I understand that module signature checking takes considerable time, but if it’s being done by fwconsole in both cases, something doesn’t compute here. The symptom makes it appear that signature checking is done by the GUI (only) and is not performed by (CLI) fwconsole.
Look at the code yourself. I linked to it. You’ll see that the code just spawns fwconsole reload. Again that’s only the case for freepbx 15. Are you only testing this slow down on 15? Is 3.25 seconds really a slow down at this point?
At some point I do want to get another pi and see what the issue is but I think most of these issues seem to be resolved in 15
Everything I’ve discussed in this topic relates to FreePBX 15 only. That’s why I’m baffled that turning off signature checking reduces GUI reload time from 6.5 to 3.25 seconds, but CLI reload time is always 3.25 seconds. Obviously an extra 3.25 seconds is tolerable, but it’s certainly a mystery.