At a guess, because he hasn’t updated in the last hour?
This is why we’re getting frustrated. People are thinking that three, twelve, seventy two, whatever, problems are the same thing.
The title of this thread is ‘Why does Apply Config take forever with no internet access’. That’s what we’re talking about. That’s what was fixed, an hour ago.
You’re the one who’s getting confused. Let’s try to keep one thread on one topic, please.
One of us is definitely confused.
You keep saying that the signature checking issue is unrelated to this issue. But, you’ve always told me that the signature checking was the reason why it was taking forever to apply config with no internet access. I’m not understanding how these two things are unrelated. They seem to me to be directly related.
I see that you previously posted a reference to framework v 12.0.67, but I don’t see how I would have known that this meant that you fixed the problem, or that the problem was fixed today.
In any case, if you’ve fixed the problem today, Kudos! Thanks!
How’d you fix it?
You may wish to go back to the OP, which was mine. This thread is about long delays caused by the module verification process. Why do you now claim that the two are unrelated? I don’t get it.
@AdHominem this is getting tiring. I documented three times how I fixed in. In the same post I keep linking to. I will link it a fourth time.
Because I said “Solution” (see above)
Signature Checking as a whole. File Tampering and Unsigned module warnings are what Signature Checking is about. You said you want to disable that.
This thread is about Retrieve_Conf delays which are caused, in part, by Signature checking but have since been fixed.
Indeed they are. But the concept of signatures is not what’s at fault. What was at fault was some testing code that checked for new and updated keys every time you clicked ‘Reload’. If the machine didn’t have internet access, it timed out.
That should only be happening daily, so we just removed the check. If you click on the github link there, you can actually see the commits. The third one down says exactly that.
Well, he did SAY it was fixed. And explained it.
I am not claiming that. I am saying there are two things here.
Signature Checking as a whole. Which does happen during retireve conf but takes less than a second. You stated you wanted it disabled completely. Is that what you truly want?
GPG key refreshing/checking, on the other hand, (different, but related to Signature Checking) happens during retrieve_conf. Err well it did. Unitl I moved it. But signature checking is still working. Signature checking is still happening. I just told it to not refresh the keys during retireve_conf, so you will no longer have timeouts from GPG there. Please note my first reply to this thread where I stated “GPG Key Checking” not “Signaure Checking”
Andrew,
The words:
“Solution: framework v12.0.67 Turned off online signature checking during reload. Modules are still checked during reload for tampering or unsigned. Moved it to the nightly cron check which will then “refreshKeys” (also “amportal a ma listonline”)”
Do not tell me that you fixed the problem today, or even that you fixed the problem I complained about, which was “Why does Apply Config take forever with no internet access?”
I wanted the ability to disable whatever it is that you changed that’s causing the delays, so that I could avoid the problem.
If you’re now telling me that the issue is resolved and that I can update modules to resolve it, then we’re done.
And, once again, thank you!
Well, ‘Solution’ DOES imply that it’s solved. Anyway, the important thing is that yes this was a bug, and yes this is now fixed.
There seems to be a lot of hot-headedness flying around about module signing, and it’s honestly quite difficult for us to separate the wheat from the chaff, with people going off on tangents and misunderstanding things.
For example:
That’s NOT what you wanted. What you wanted was for reloads not to take a long time when you didn’t have internet access. There’s a pretty significant difference there (well, there is to us, anyway - it might not be as obvious to you)
Yes, it is. And if it’s NOT, please open a bug about it. Otherwise we don’t know.
It’s always happened independently. The reason it was being done in Apply Config as well, was - back when heaps of keys were being signed - we needed an easy way to check that everything was updating properly, so we added it there, and promptly forgot about it.
We didn’t notice it because, well, all of our machines have internet access 
You’re welcome. I apologise for the confusion.
–Rob
No apologies necessary. The confusion stems from the fact that you guys seem to think that I know as much as you do, when I actually don’t.
I’ve done a lot of fiddling with FreePBX and so I know how the product operates and how to make it do stuff, but I know zero programming and so I have no idea how it actually works.
That’s why, for example, I didn’t know how to interpret Andrew’s “solution” message. 
Furthermore we did have a go at this a few months back where we changed the timeout per server from 15 seconds to 5 seconds (so from 45 total seconds to 15 seconds). After that I didn’t hear anything back on this thread until today so I assumed things were better. My fault for not actively saying we changed that. But we did. We do listen.
He does. I don’t. Shh.
My sincerest apologies if anything that I said made you think that I believed that you don’t listen. You’ve never done anything to warrant that belief, and I do NOT hold such a belief. You guys are awesome.
The reason you haven’t heard back from me is because I’ve been busy with other work. My 2.11/1.8 installation is running just fine, and I haven’t had any reason to try 12 again.
I’m planning to update one of my offices next month, and I’ll try 12 again at that time. You’ll probably see another flood of bug reports then as well. 
Please let us know if it still takes forever. It very well could. Then I will have to do more tweaking. But it would be in a different area.
I know that one part of the delay was related to iSymphonyServerV3, which wasn’t supposed to be running at all, but started after the first boot. Tony said you’ve resolved that issue.
Saw that. Let us know if thats an issue as well
@corkuck thanks for the detailed reply.
I understand your background, I can feel what a challenge to run this it must be…
Yet you’re writing this email from out of an Internet connected machine (yeah, so it’s a lab, but still).
I understand that in your ‘clean room’ conditions you don’t even have needs to run software update mirrors for any of the computers connected there? Like, how do you get bugfixes / feature requests applied to your systems then ? You do not run any sort of a sentry / IAD systems to ensure no ‘zombified’ workstation can take over the whole thing? (OK I acknowledge this information might be classified 
) (A lot of that is fixed or being fixed in software you get on the Internet, you know) Of course I do know a lot of /that/ is fixable, by security standards, checks and enforcement (and money, ultimately). But system of that size, is a lot more like The Internet than you or anybody will ever know…
So having this in mind, say you do run mirrors of your current Red Hat/whatever distribution you use most. Maybe you should run by Sangoma ask them how to set up your own internal mirror of the FreePBX distribution ? Have a process in place, that the updates be pulled by hand, cleansweeped, checked & all that and only then uploaded to the internal mirror(s). With automatic ‘electronic paper trail’. Sure that would be doable even with very security-aware committee?
also @tm1000 : I pulled the latest framework update as I type these words
I have 10-15 SIP ‘devices’, 5 (yes five) internal extensions (‘users’), 5 incoming SIP trunks, 1 queue and 2 time conditions.
Applying a trivial non-functional change (DID Description in an User’s configuration) now takes 5-6 seconds from click on Apply to the throbber bar disappearance. (and yes it feels much faster now, I can not compare to what it was before, unfortunately, but it used to be much longer)
(on a '2006 2.6GHz Celeron with 1GB RAM and 1Gbps intranet between PBX and the computer running the browser)
Wow, that’s is all we would like to say. But we have to say more…
For us that don’t have internet accessible machines we are back in business with a few seconds at most after “APPLY” has been pressed…
Just a side note: Personally I take care of an Asterisk v1.8 for security, 911 phone calls for 150 plus lots and cabins in the Rocky Mountains where we have little to no Internet at all. Using the HughesNet/WildBlue satellite network, but only when needed. So polling out on the internet how and then is not good for this install ether.
Thank you, thank you… for your good work. We are appreciative.
Here at work we installed FreePBX v12.0.67 and now it doesn’t seem to matter if you go to FreePBX, Advanced Settings, find Developer and Customization, then Enable Module Signature Checking and changing it to True or False. Both True or False seems to have no effect. Both seem to take no time at all after pressing “APPLY”. This is so Sweeeeeeet.
We are back at looking heavenly at Asterisk 13 as being our production machine someday, time will tell.
We are so sorry about any problems we may have caused between relationships we noticed throughout this heavily discussed topic at times. It felt so good to see the apologies towards the end of it all. Made us not wish to participate or give any input there for awhile.
But WOW did we learn allot from your guys. About Asterisk, FreeBPX and the people behind it.
Again thank you for being open minded, sharing and fixing this “APPLY” speed issue, when not having internet accessible machines.
We are all on the right path, lets move all together as one.
/corkuck
IIIUC, as tm1000 wrote
this is the case only when doing config changes/applying/reloading config.
If you happen to do module updates (i.e. download newer version from The Internet) the locally stored signatures WILL be checked with the servers’ versions (and the advanced settings ‘disable signature checking’ feature will reset to ON again). That is (probably) fine if you’re off the BWSN (Big Wild Scary Network) anyway for most of the time.
(also I still think, because you know, FreePBX is being worked on all the time, creating your own ‘off the BWSN’ dedicated mirror(s) of the update server(s) will/should let you stay more current with features/bugfixes in the future. Even if by the very nature of this development you have to carry data into the mirror server(s) on a memory stick… )
(DISCLAIMER: I am in no way affiliated professionally with Sangoma or FreePBX dev team or FreePBX otherwise than just by running one FreePBX Deployment on An Ancient Machine)
(But you know, this could give the project an insight into challenges you’re facing with it, and ultimately, make it do for others what it does for you… you call it Open Minded, some of us, by the words of one Late John ‘The Beautiful Mind’ Nash, call it ‘everybody wins’ )