Cacti 1.2.0 Remote collector IU login failing

[mini4mw2]

I've upgraded to 1.2.0 from 1.1.38. I have one main collector and 3 remote collectors, all running 1.2.0. Prior to the upgrade I could log into the remote poller UI and they would advise 'you're logging into a remote poller'. After the upgrade I can't log into any remote poller. I just get authentication failed. I've checked the DB and the password hash matches the main poller, but the user log table shows no login attempts. The upgrade didn't go smoothly. First time around all the graphs disappeared after the main controller upgrade (no errors during upgrade, thousands present before the upgrade, 0 after). I rolled back snapshots and re-ran the upgrade but remote pollers hosed in the process. As a quick fix I exported the main poller DB and imported to remote poller DB, most of the DB syncs with main site anyway. This fixed the problem after performing the necessary UI from main site/CLI reconfigurations, but I can't log into the remote pollers. I did a quick read through the include/auth.php but I haven't found anything. I'm guessing there's some table with a node ID, or reference to the poller that is different in each site's DB causing the failure but I haven't found it yet. I don't see any logs in httpd or cacti to point me in the right direction. Anyone advise how to find the culprit of the login failure?

[Osiris]

Perform a forced 'Full Sync' to each of the remote data collectors. That will essentially upgrade the database. Let us know how that goes.

[mini4mw2]

Full sync was done yesterday and its on a 30 min cycle. I've seen the successful replication in the main poller logs. Remote pollers are working fine, been collecting data since yesterday. Devices are assigned to remote pollers and graphs are all functioning/collecting data, updating the main poller rrd files, boost/hourly updated rrds (outside on the fly). The only thing I've found not working right is the remote poller web login. No logs in the remote poller mysql login table (rejected/failed attempts). Using spine and the DBs are configured (local and main poller/remote). Verified config.php has the right mysql info and i can log into the local DB on remote pollers using the same configuration from OS CLI. Strange that failed UI attempts are not logging into the local DB. No entries since the DB from the main poller DB was restored to the remote poller.

[Osiris]

Starting with 1.2, you should only have to, on rare occasions, perform a full sync. Once a day is often enough, unless you have some extended outage. Also, keep a watch out for 1.2.1. There will be some important updates there.

[mini4mw2]

the web UI accessibility is not a huge deal since everything can be managed from the main poller so I can wait for 1.2.1.

Is there anything else in the DB that may be referenced like a site code/poller ID that could be causing the logins to fail?

[Osiris]

Well, verify you database connection works both ways, and then perform a full sync to the remote system. If you are using ldap, that foreign system will be able to communicate to the ldap/ad.

[mini4mw2]

Just using local auth. Its not a big deal since the main collector can be logged in via GUI and everything else can be managed from the CLI on the remote pollers. Something I'll have to tackle when it is a problem. Worst case I have to move all the objects polling on the remote poller off, remove Cacti and reconfigure (hopefully).

I've also noticed I have to move devices to the main poller to perform a data query (IE SNMP Interfaces). If I leave the device on a remote poller and perform a query, 0 objects is always returned. Move to the main poller and it works fine, create graphs and then move back to remote poller. Polling works fine after the datasources are defined. I know the plugins don't work on remote pollers but I never saw anything on data queries not working. ACLs on the network and/or devices are not the issue. Not sure if that is 'normal' or not with remote pollers.

[mini4mw2]

We replaced the main poller today (changing from Fedora to CentOS) and then we couldn't log into the main poller UI after migration (scp cacti dir and dump/import sql). We fixed the UI issue as it appears with an import of the mariaDB. Somehow the MD5 hash on the password or perhaps it imports as clear text. The password hash looks same as it does on the old system, but the web UI fails login. Updated the password with the same password via SQL CLI and now we can log into the main poller and all the remote pollers.

So just a note that if you import the DB, you may need to re-update the admin user via mysql/maria CLI to fix some issue there. The values look the same, but something doesn't carry over.

[netniV]

The likelihood here is that the password fails due to a change in the OS/Hardware (Virtualware?) and so PHP does it's calculations for secured hashing in a different way. Fortunately, we haven't removed the old method of settings passwords via the MD5 hash, so when you update vai SQL using MD5, upon first login its converted over to the newer more secured format.

This is the first time that I've seen a password not survive a dump and reload though... something must have been customised on the old server I think...