Hello.
I changed the mysql-database password for the pi user.The mysql.cnf and pi.cfg were changed.
But that doesn’t seem to work. privacyidea.log indicates, that the used password is not correct.
What needs to be done to get privacy to update the used password?
Thanks for help
Restart the web server process, so that pi.cfg is re-read.
The Webserver was down during change. (If there was no other Problem)
Is there anything special with the radius plugin? On first try I had the impression that the GUI worked but only Radius failed. On second try I only tried radius via command line.
After trying some more its clear that the old password remains cached somewhere even after a reboot. Unfortunatly I can’t figure out why and where.
Thanks for help
The question is actually
I think there might be a slight discrepancy.
This is not the way how chaning a mysql password works. You must change it via a mysql command like “grant privileges” and then change the password in pi.cfg.
THese is no user password in mysql.cnf.
Of course I only described what i did regarding privacyidea. The mysql change works fine. And as I wrote, after editing pi.cfg and rebooting he stills uses the old password and not the one from pi.cfg, since i let him log it to privacyidea.log.
where can pi get the old password from if it is not in the pi.cfg
Okay. Even if I cant try it now, I am quite sure that this is indeed really simple.
Its not the initial connection that fails, but the configured sql resolver for users which of course runs on the same database. That means pi connects to the database just to read out an outdated connection string from the resolver table and fails to connect to read out users.
It is really hard for me to make a good sense of what you are writing.
But if you change the password of the database user, then of course you need to change the SQL resolver. Of course you change the resolver as administrator in privacyIDEA.
Of course. If you remember, that there is an own setting for the same database which is rather uncommon for such products. If you use PI often that might be your first thought, but not if you set it up once a long time ago and now try to do some “simple” task.
But you stick to assume that people fail on restarting the webserver or fail to set a mysql database password.
I totally do not understand “an own setting for the same database”. If you care to explain this.
You might have your experience with common. But believe me, we have our very good reasons to design this thing as is. These are based on over 16 years of experience in strong authentication with many different vendors. But I am still curious to understand “own setting” (which you for days missed to explain in detail), so I can explain things to you.
I assume, that you have a user resolver with a local user table in the same database (token database). This is my assumption, because you never told this. You actually always told very little.
Now let me tell you something about common. It is totally your assumption, that you think it is common, that users are located in the same database. No. This is not common, this is crappy design. Yes, you can do this with privacyIDEA, but as this is crappy design, why should this be done automatically.
From looking at several hundrets privacyIDEA installation let me tell you this: My educated guess is that 1% of the installation actually have a local userresolver on the same database. Why?
Because this is crappy design.
…but I am repeatring myself…