I’ve successfully configured and deployed several LibreNMS + Oxidized CentOS 7 (with nginx) without problem before, however on this new Ubuntu installation I am experiencing API issues when trying to test the API for Oxidized via curl.
curl -H ‘X-Auth-Token: c5b4314f1f2719f5c0f1bf4c248d7d767’ http://127.0.0.1/api/v0/oxidized
{
“status”: “error”,
“message”: “API Token is missing or invalid; please supply a valid token”
The token has been created in the Libre WebUI, and all appears fine with that… however, I can access no part of the API. I have tried with further tokens, however the same issue persists.
The curl API call generates the following access_log entry:
### Database config
$config['db_host'] = 'localhost';
$config['db_port'] = '3306';
$config['db_user'] = 'librenms';
$config['db_pass'] = 'REMOVED';
$config['db_name'] = 'librenms';
$config['db_socket'] = '';
$config['db']['extension'] = "mysqli";// mysql or mysqli
// This is the user LibreNMS will run as
//Please ensure this user is created and has the correct permissions to your install
$config['user'] = 'librenms';
### Memcached config - We use this to store realtime usage
$config['memcached']['enable'] = FALSE;
$config['memcached']['host'] = "localhost";
$config['memcached']['port'] = 11211;
### Locations - it is recommended to keep the default
$config['install_dir'] = "/opt/librenms";
### This should *only* be set if you want to *force* a particular hostname/port
### It will prevent the web interface being usable form any other hostname
#$config['base_url'] = "REMOVED";
### Enable this to use rrdcached. Be sure rrd_dir is within the rrdcached dir
### and that your web server has permission to talk to rrdcached.
#$config['rrdcached'] = "unix:/var/run/rrdcached.sock";
### Default community
$config['snmp']['community'] = array("REMOVED");
### Authentication Model
$config['auth_mechanism'] = "mysql"; # default, other options: ldap, http-auth
#$config['http_auth_guest'] = "guest"; # remember to configure this user if you use http-auth
### List of RFC1918 networks to allow scanning-based discovery
#$config['nets'][] = "10.0.0.0/8";
#$config['nets'][] = "172.16.0.0/12";
#$config['nets'][] = "192.168.0.0/16";
# Uncomment the next line to disable daily updates
#$config['update'] = 0;
# Enable billing module
$config['enable_billing'] = 1;
$config['billing_data_purge'] = 36;
My understanding is that should have echo’d back the actual libre username associated with the token? If that’s the case, it didn’t echo it back correctly (but instead appears to have echo’d back the token hash twice)??
That’s still the same token hash as the original one I posted? Or am I missing something? I have added (and subsequently deleted) several others for testing, however I’ve been sticking to this original one (c5b4314f1f2719f5c0f1bf4c248d7d767) for all tests.
MariaDB [librenms]> SELECT AT.user_id FROM api_tokens AS AT WHERE AT.token_hash= ‘c5b4314f1f2719f5c0f1bf4c248d7d767’;
Empty set (0.00 sec)
Ok upon closer examination I see that the token you just asked me to test has an additional ‘7’ character appended to it compared to my original token.
Token you asked me to test:
c5b4314f1f2719f5c0f1bf4c248d7d767
MariaDB [librenms]> SELECT AT.user_id FROM api_tokens AS AT WHERE AT.token_hash= ‘c5b4314f1f2719f5c0f1bf4c248d7d767’;
Empty set (0.00 sec)
Correct and configured token:
c5b4314f1f2719f5c0f1bf4c248d7d76
MariaDB [librenms]> SELECT AT.user_id FROM api_tokens AS AT WHERE AT.token_hash= ‘c5b4314f1f2719f5c0f1bf4c248d7d76’;
±--------+
| user_id |
±--------+
| 1 |
±--------+
1 row in set (0.00 sec)
