pfsense 2.4.4 NTP PHP Error Bug (possible work around)
-
For those of you experiencing a php error with NTP API key mismatch issue.
I believe I may have a temp workaround until Netgate/pfsense can fix the API key error/ or credential mismatch. It looks like an API key mismatch maybe a credential key with PFsense NTP daemon 0.pfsense.pool.ntp.org
That during the update this API key was not updated.My Netgate 3100 FW and Snort are working fine, on 2.4.4 (balanced) IPS setting for now, no issues after I did the following:
RECOMENDATIONS: disclaimer (I am not a Netgate engineer or pfsense eng) but this is working for me until a more permanent fix for the API key.
I believe this to be a minor error but definitely needs to be fixed.
(2) possible workarounds:
(1) reinstalling NTP daemon and then maybe key might match-up again.
or
My fix:
(2) goto the General settings and delete 0.pfsense.pool.ntp.orgadd new pool: 0.us.pool.ntp.org .....or other NTP pool you trust.
click saveDon't forget to go to error page and click delete the bug report.
The error should NOT return as now your NTP daemon is point to a different NTP pool.I have logged out of pfsense and logged back in several times and no more error, so far this is working for me.
I hope this helps!
Thanks!
-
What is the exact error message you're trying to solve there? I have ~20 boxes all using 0.pfsense.pool.ntp.org (and
1.,2.and so on) and they all work. There is no "NTP API key".Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@jimp He must be referring to auth keys, not API keys.
-
There aren't any auth keys, either, though.
-
There are no "keys" when talking to a pool ntp server(s)
So have no idea what this poster is talking about..
-
I'm no NTP expert but ntp.org seems to talk about authentication keys here:
http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN3143
I have no idea what this gent's actual problem is.
-
Sure you can use auth keys - but that is not part of the pfsense configuration nor anything with using pool servers..
That is something you would do with YOUR clients talking to YOUR server... Not people talking to a server in the pool.. it would be impossible to manage..
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
2440 2.4.5p1 | 2x 3100 2.4.4p3 | 2x 3100 22.01 | 4860 22.01 -
@johnpoz Agreed. Just trying to figure out what this guy's actual problem was and how he really solved it.
-
It's possible there was some PHP error on the NTP settings page they misinterpreted and editing the NTP server list on System > General worked around it. But without the exact text of the error message and the context in which it was received, it's all guesswork. Only one that can answer anything here is the OP.
-
I think jimp hit it on the head there..
-
@johnpoz
Excerpt: from previous post, paraphrased & commented:For those of you experiencing a php error with NTP API key mismatch issue. I believe I may have a temp workaround (until Netgate/pfsense can fix the API key error)/ or (credential mismatch) <<<(ok maybe this is wrong and it mismatched compiler keys for PHP and NTP module or daemon) just going straight off the error message.
(my fix to the anoying pop up on my dashboard was a temp fix was to delete the error message and point the NTP daemon to different NTP pool. so it would stop showing the error. Does this fix the under lying Key mismatch noop and I said as much...prior
It looks like an API key mismatch (maybe a credential key) with PFsense NTP daemon 0.pfsense.pool.ntp.org
That during the update this API key was not updated.You are correct I wasnt talking about API as RESTful API
and mentioned the same in prior text that I thought the error is some sort of Key authentication mismatch. and used the same syntax as shown in the error message below....so maybe it isnt an auth key but compiler key mismatch...see error below...vs the rhetoric above.Module (compiled with module) API=20170718
PHP (compiled with module) API=20131226As it even shows different keys. Maybe NTP compiler Key mismatch hense the error, for all I know.
PHP Errors:
[29-Sep-2018 00:13:56 America/Chicago] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20170718/session.so' - /usr/local/lib/php/20170718/session.so: Undefined symbol "zend_empty_string" in Unknown on line 0
[29-Sep-2018 00:13:56 America/Chicago] PHP Warning: PHP Startup: bcmath: Unable to initialize module
Module compiled with module API=20170718
PHP compiled with module API=20131226
These options need to match
in Unknown on line 0
[29-Sep-2018 00:13:56 America/Chicago] PHP Warning: PHP Startup: bz2: Unable to initialize module
Module compiled with module API=20170718
PHP compiled with module API=20131226
These options need to match
in Unknown on line 0 -
(Thinking out loud) as in putting forth another idea...not that I am programmer or anything
Maybe it is simply that 2 different versions of a PHP compiler were used to compile the NTP daemon so there are different keys and hence a mismatch. (i.e. different keys were used to create the NTP daemon. One PHP compiler ver was used for 2.4.3 NTP daemon creation and new PHP compiler key ver was used for 2.4.4 and the new kernel is looking for the an old NTP compiler key or vis versa and getting a mismatch. don't know, just guessing, based on rudimentary programing experience.
Assuming the NTP daemon is actually PHP code running on Linux which appears to be the case here. (i.e. the ntpd is a PHP Daemon running on Linux).
Bottom line is there appears to be an Auth Key or a Compiler key mismatch or maybe it is a Security Key Mismatch, all the above. And I can't tell if it is a Auth/SEC Key, or a Compiler Key, but whichever it is...the NTP server daemon isn't syncing per the NTP log.
kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized <<<<<every day
again it might be something real inconsequential the time looks accurate per the Netgate appliance GUI dashboard and log stamps, so, you guys tell me.
Just here to learn....and have some fun!
really like the Netgate appliance and pfsense,
-
@rgc said in pfsense 2.4.4 NTP PHP Error Bug (possible work around):
Assuming the NTP daemon is actually PHP code running on Linux which appears to be the case here
What?? Looks like to me you have a php problem loading the extensions sessions.so.. The upgrade to 2.4.4 made big change to php version.. Seems like that didn't go clearn on the upgrade..
This doesn't seem to have anything to do with ntp at all.
Here!!!
https://forum.netgate.com/topic/135868/php-errors-after-upgrade-to-2-4-4 -
@rgc said in pfsense 2.4.4 NTP PHP Error Bug (possible work around):
(Thinking out loud) as in putting forth another idea...not that I am programmer or anything
Maybe it is simply that 2 different versions of a PHP compiler were used to compile the NTP daemon so there are different keys and hence a mismatch. (i.e. different keys were used to create the NTP daemon. One PHP compiler ver was used for 2.4.3 NTP daemon creation and new PHP compiler key ver was used for 2.4.4 and the new kernel is looking for the an old NTP compiler key or vis versa and getting a mismatch. don't know, just guessing, based on rudimentary programing experience.
No, there is no PHP used to compile NTP.
Assuming the NTP daemon is actually PHP code running on Linux which appears to be the case here. (i.e. the ntpd is a PHP Daemon running on Linux).
It is not using PHP. The web interface on pfSense is. Also, pfSense uses FreeBSD and not Linux.
Bottom line is there appears to be an Auth Key or a Compiler key mismatch or maybe it is a Security Key Mismatch, all the above. And I can't tell if it is a Auth/SEC Key, or a Compiler Key, but whichever it is...the NTP server daemon isn't syncing per the NTP log.
The errors you posted have nothing at all to do with NTP. They are only from PHP, and likely from pfBlockerNG. Uninstall and reinstall that package.
kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized <<<<<every day
That is a completely separate issue worthy of its own thread, but it has 0% to do with the PHP errors.
-
@rgc said in pfsense 2.4.4 NTP PHP Error Bug (possible work around):
Assuming the NTP daemon is actually PHP code running on Linux which appears to be the case here.
That is so hilariously wrong. PHP is a web scripting language and API for building dynamic web pages. Please don't be upset as I'm not trying to mock you, but that was pretty funny. I know that I appreciate users who take the time to report a problem and take even more time to try to logically think it through and then provide a lot of detail for people to help debug. As John & Jim already pointed out, you seem to be having a library problem that some others have also seen.
Welcome aboard.
-
@rgc said in pfsense 2.4.4 NTP PHP Error Bug (possible work around):
kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized <<<<<every day
Is this after you reboot the machine, or after a it has just been turned on? In that case it is possible that the battery supporting the hardware rtc on your machine has died, assuming the SG3100 has one. Anyways it simply means that the system time and the time received via NTP are different and the clock will be re-synced by the kernel. It shouldn't happen, but it's not that big of an issue either.
-
@johnpoz, Thanks. for not losing your cool with me. Just learning and Thanks for the feedback, seems PHP upgrade is an issue for some like me and mostly cosmetic apparently just get PHP error showing in GUI as upgrade process reports, this might happen. I have had 2 crashes since the 2.4.4 upgrade.
I don't run pfBlockerNG and not sure if it fixed anything thing for anyone, per prior posts. Maybe for those that were running it previously. Did they reload the package and it fixed the PHP error?. Hard to tell based on the responses, they seem mixed.
I still have the NTP clock sync issue. Not really sure what to do? about that but didn't have that issue before 2.4.4 upgrade. Unrelated to PHP ? dunno ? kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
i read clock sync issues were due to not having enough clock sources i have 4 pools based in US configured. but still get the sync error. Maybe too this is a PHP GUI thing for NTPD everything is OK but just not reporting to GUI correctly. ntpd.log shows still reportg the error.Back to PHP:
it seems what everyone is doing is just dealing with whatever issue they have GUI with PHP while things get tweaked a bit more. I didn't see any definitive fix in the posts GUI or otherwise but I am cool to wait for next updateMost Useful posts:
TheNarc:
I did read that, and in particular the following:
"These errors are primarily seen on the console as the upgrade is applied, but may appear in a crash report once the upgrade completes. In nearly all cases these errors are a harmless side effect of the changes between FreeBSD 11.1 and 11.2 and between PHP 5.6 and PHP 7.2."
It wasn't clear from that though whether recurring crash reports would be expected. Although I know that another section of that same post suggested that certain configurations may result in more PHP errors. In any case, I guess we should maybe give it some time and or reboot again before considering it a real issue?
Gertjan:
What happens is that during the upgrade, PHP Lib directory /usr/local/lib/php/20131226 is destroyed to make place for /usr/local/lib/php/20170718
Or, during the upgrade, some tasks (most GUI based maintenance tasks) still using PHP 5.2 (pfSense 2.4.3....) are still running. They die - they maybe should have been killed anyway, but hey, we want to see, among others, the upgrade progress in GUI, right ;)My apologies:
regarding my previous posts, I read that PHP is often used to create a PHP daemon in Linux. didnt know if that was done here in freeBSD build. I also wasnt aware that PHP is strictly just a webservices/server daemon. I thought that PHP could be used like any other language to build any daemon/Server or service. And that maybe since my PHP issue and NTPD issue appeared as the same time that PHP was partly impacting NTPD, that NTPD was essentially running like a PHP daemon service too, again not a programmer didnt know and as I mentioned thinking out loud. Sorry for bothering you all. Yea I guess I am an idiot, but trying to learn and understand . I am hopeful I will get better over time. I have only just started using my Netgate Appliance and Pfsense, 4months now. Again, sorry to bother you all. Please feel free to ignore me in future if I say something stupid or ask a dumb question. -
To your NTP not working - you sure your actually talking to the ntp servers? What does the ntp status show?
-
@rgc said in pfsense 2.4.4 NTP PHP Error Bug (possible work around):
Sorry for bothering you all. Yea I guess I am an idiot
No, not at all. It was an honest mistake that just so happened to be quite funny (at least to me). You might have been thinking of python, which can be used for scripting system services. We all live & learn. I've lost count of the times I've been corrected here after giving my best advice, usually by john or jim
