Cacti 1.2.1 Installation - Can't login

[Hotratz]

I've just installed 1.2.1 from 1.2.0. I am no longer able to login and am stuck at Installation In Progress" in the browser window. I have cleared the cache.

After having gone through the upgrade process numerous times (since prior to v1.0) this is the first time experiencing such a problem.

On CentOS 7.6, kernel 3.10.0-957.1.3.el7.x86_64, Apache/2.4.6

***
Installation In Progress

There is an Installation or Upgrade in progress.

Only Cacti Administrators with Install/Upgrade privilege may login at this time

Return | Login Again

***

I do not get a login window regardless of clicking on "Return" or "Login Again" - The page only reloads.

Any ideas?

Thanks.

[netniV]

If you do not believe another administrator is performing an upgrade, try running

Code: Select all

DELETE FROM settings WHERE name LIKE 'install_%';

in MySQL/MariaDB

[Hotratz]

I am the administrator which is why I'm perplexed about this issue.

Any idea what might be causing the server get stuck on this page and not present a login for an admin?

I'll give that a try. Thanks.

[Hotratz]

Unfortunately that did not work. Also, it appears to only address the symptom, not the cause of the problem.

I reverted back to 1.2.0, the last working version.

[netniV]

There is no change between either version to the installation system for the lockout. Check that you have the Install/Upgrade permission against your user.

[paulbeard206]

Check that you have the Install/Upgrade permission against your user.

what does this even mean? I also upgraded thru FreeBSD ports and am now locked out with no login screen.

[netniV]

You can check which user does have the rights by running the following in MySQL/MariaDB:

Code: Select all

mysql> select id, realm_id, username from user_auth_realm uar inner join user_auth ua on ua.id = uar.user_id where realm_id = 26;
+----+----------+----------+
| id | realm_id | username |
+----+----------+----------+
|  1 |       26 | admin    |
|  7 |       26 | mark     |
+----+----------+----------+

[Hotratz]

What doesn't make sense is the fact that after having gone through the upgrade process a number of times before with no change in process (automated via upgrade script) or users/permissions, why would this become an issue now?

[netniV]

Because as part of the enhancements to security, a new realm was added to specify which users are actually allowed to upgrade the system. After all, not all admins are equal yet previously ANY user with console access would be able to run through the upgrade process.

From 1.2.0, the system should have assigned the first admin to login the rights to realm 26 which is the install/upgrade rights. Hence I asked you to run the above MySQL statements to see who was given those rights. You will see it if you examine the lib/auth.php script and search for 'Install/Upgrade realm 26'.

Normally, the first user to login is the user performing the upgrade so those rights should have been assigned immediately. Hopefully, that explanation has informed you on the change and why I was asking for the above query to show which user had been given those rights.

[paulbeard206]

OK. Seems like a fairly significant change to make.

Code: Select all

select id, realm_id, username from user_auth_realm uar inner join user_auth ua on ua.id = uar.user_id where realm_id = 26;

Empty set (0.00 sec)

So now what? How does fix this? What GRANT statement needs to be used (optimally as part of the upgrade process?) so that we can access an existing install?

I have no realm 26. Perhaps creating and populating that should be part of the upgrade process?

[netniV]

Creating and populating that is part of the login process when you upgrade from 1.1.x to 1.2.x. Something somewhere has gone wrong if that hasn't been populated. To correct it, do the following

Code: Select all

select id from user_auth where username = '<name of login>'

Then do the following:

Code: Select all

insert into user_auth_realm VALUES (26, <id>)

where <id> is the id from the first statement.

[paulbeard206]

Permissions seem fine. Spine is writing to the log happily. Why is this failing?

I changed /var/log/cacti to be owned by www:www and it worked. Changed it back and it still works.

[netniV]

So the process is now working?

[Hotratz]

Because as part of the enhancements to security, a new realm was added to specify which users are actually allowed to upgrade the system. After all, not all admins are equal yet previously ANY user with console access would be able to run through the upgrade process.

From 1.2.0, the system should have assigned the first admin to login the rights to realm 26 which is the install/upgrade rights. Hence I asked you to run the above MySQL statements to see who was given those rights. You will see it if you examine the lib/auth.php script and search for 'Install/Upgrade realm 26'.

Normally, the first user to login is the user performing the upgrade so those rights should have been assigned immediately. Hopefully, that explanation has informed you on the change and why I was asking for the above query to show which user had been given those rights.

Ok now it all makes sense. Thank you for shedding additional light on the issue. I ran your suggested command and found that admin does not have access to realm 26. I'll change that and try again.

I suppose the next question is why would Cacti not have made the assignment? I'll take a look in lib/auth.php.

****

Looked in auth.php - found nothing indicating assigning realm 26 access to admin. I do see a $new_realm = 0 in function user_copy - that's the closest thing I've found to making a new realm assignment.

****

The problem has now been resolved and now have 1.2.1 up and running. Thanks again for the solution.

[netniV]

That is because the actual code in 1.2.1 occurs in include/auth.php beginning at line 107 (feel free to review and let me know if you think there's an issue).

It basically tries to find any user or group that has realm 26 associated to it. If it fails to find one then it then adds everyone who has realm 15 (Settings/Utilities access) as an Installer/upgrader. The idea there being that a user who has that access would likely be an installer/upgrader. But once set, an admin can remove those privileges should they feel it necessary.