No valid auth_mechanism defined, config:get null after upgrade

[fbs]

I had been upgrading LibreNMS from time to time. When updating to the current release 23.7.0, validation failed (auth_mechanism not found). Since I am using LibreNMS from FreeBSD ports and there had been some compatibility work for this release (SHEBANG), I tried to go back to the previous release (available from FreeBSD ports) and see if this error was introduced there. Turned out to be not the case.

% ./validate.php 
===========================================
Component | Version
--------- | -------
LibreNMS  | 23.5.0 (2023-05-19T15:32:19+00:00)
DB Schema | 2023_05_12_071412_devices_expand_timetaken_doubles (252)
PHP       | 8.1.22
Python    | 3.9.17
Database  | MariaDB 10.11.4-MariaDB
RRDTool   | 1.8.0
SNMP      | 5.9.1
===========================================

[OK]    Installed from package; no Composer required
ERROR: no valid auth_mechanism defined!
 not found as auth_mechanism

% ./scripts/auth_test.php -l
ERROR: no valid auth_mechanism defined!
 not found as auth_mechanism

% ./lnms config:get --dump
null

As you can see, the validate.php outputs that no valid auth_mechanism is defined, the same error is displayed when running ./scripts/auth_test.php -l.

When calling validate.php or ./scripts/auth_test.php, the error message is printed from includes/init.php, after the config got sourced.

I think the real problem seems to be that the config is not sourced at all, because ./lnms config:get --dump outputs null and the above mentioned tests regarding the auth_mechanism are just the first ones being tested.

Having a look at the database shows that the config table is existent and populated:

[librenms]> select * from config;
+-----------+-------------------------+------------------------------+
| config_id | config_name             | config_value                 |
+-----------+-------------------------+------------------------------+
|         1 | fping                   | "/usr/local/sbin/fping"      |
|         2 | fping6                  | "/usr/local/sbin/fping6"     |
|         3 | snmpgetnext             | "/usr/local/bin/snmpgetnext" |
|         4 | rrdtool                 | "/usr/local/bin/rrdtool"     |
|         5 | traceroute              | "/usr/sbin/traceroute"       |
|         6 | traceroute6             | "/usr/sbin/traceroute6"      |
|         7 | allow_duplicate_sysName | true                         |
|         8 | auth_mechanism          | "mysql"                      |
+-----------+-------------------------+------------------------------+
8 rows in set (0.000 sec)

Could that have to do something with how the Laravel framework caches configs? Any idea on how to fix this would be very appreciated.

[fbs]

What helped to get ./validate.php running further is indeed clearing Laravel’s config cache by executing:

% php artisan config:clear

   INFO  Configuration cache cleared successfully.  

Now I just need to roll forward to the release I was using before (23.5.0 to 23.7.0) to silence the waring about extra migrations.

[fbs]

validate.sh is happy with the current release (23.7.0):

% ./validate.php
===========================================
Component | Version
--------- | -------
LibreNMS  | 23.7.0 (2023-07-17T04:42:41+00:00)
DB Schema | 2023_05_12_071412_devices_expand_timetaken_doubles (252)
PHP       | 8.1.22
Python    | 3.9.17
Database  | MariaDB 10.11.4-MariaDB
RRDTool   | 1.8.0
SNMP      | 5.9.1
===========================================

[OK]    Installed from package; no Composer required
[OK]    Database connection successful
[OK]    Database Schema is current
[OK]    SQL Server meets minimum requirements
[OK]    lower_case_table_names is enabled
[OK]    MySQL engine is optimal
[OK]    Database and column collations are correct
[OK]    Database schema correct
[OK]    MySQl and PHP time match
[OK]    Active pollers found
[OK]    Dispatcher Service is enabled
[OK]    Locks are functional
[OK]    Python wrapper cron entry is not present
[OK]    Redis is unavailable
[OK]    rrd_dir is writable
[OK]    rrdtool version ok

There are some threads discussing the above mentioned issue (config:get returns null) in Laravel oriented discussion forums. I am not sure where in the LibreNMS landscape this is mentioned, but from my understanding so far, it seems to be a good idea to proactively clear the config cache after an upgrade.

Could somebody please confirm this?