I gave this a try and ran into the error of old_password. Looking in the main mysql database in the shell, I see all my users with the old 16 char hash.
So I deleted old_password from my.cnf file and when I edit a user or create a new database user it has the new 41 length hash.
So my plan was to just go into each account and edit the password, just setting it to the current password (by looking in the database connection file for each site wordpress or custom). Then once that’s done I can enable the new mysql plugin without issue.
BUT… I ran into an issue with phpMyAdmin and the main SiteWorx user (automatically created by InterWorx).
Example
SW account abcwidgetstore.com with account username of abcwidge with a created DB username of Bob.
In the mysql user database it would have:
abcwidge
abcwidge_bob
With old_passwords set to 0 or commented out when trying to access a SiteWorx account the main user (abcwidge in this example) that is created on the fly is created with a 41 char hash. Which is a good thing I thought, but then you get connection errors when trying to open phpMyAdmin.
What I don’t get is why is there an error there at all? I set a few accounts (manually created DB users) to the new 41 hash and am still able to connect to their databases via PHP scripts, so why won’t phpMyAdmin?
I’m sorry, it’s late here and I’m about to go to bed.
I think this is the difference between MySQL 4 and 5 in hashes.
IW requires MySQL 4, whilst the siteworx account could use MySQL 5.
I’ll post more tommorow with the forums post re this difference and there is a quirk to it, in that you can make all siteworx account use the new hash, as long as you don’t change the password for IW to use new hash.
I’m sorry if I’m wrong or not understood you sorry, but I have my granddaughter sleeping over as my grandson is undergoing an operation tommorow
Yeah, I’m strictly speaking on the actual websites, not the InterWorx core.
I had in my.cnf file (for the hosted websites) the old_passwords=1. I’m guessing that was enabled because I was on a newer 5.1 (I think) that had switched to the longer hashes and for backwards compatibility. So removing that old_passwords line allowed new and updated DB user passwords to be created with new hash. Which means eventually once all of them were updated, I could switch from php-mysql to php-mysqlnd on my server. Apparently since they are the same purpose you can’t have both (php-mysql and php-mysqlnd) of those installed at the same time.
The specific issue I’m having now is phpMyAdmin through SiteWorx will not work correctly, even while I am still on the old php-mysql, if the old_passwords is disabled. I don’t know why, but I did notice that SiteWorx seems to create, on the fly, a DB user with the main shell username for the account (without the _manuallyCreatedName) to access phpMyAdmin. So with old_password off, when it creates this user it creates it with the 41 char hash and it will not connect. So my guess is even if I had moved the server over to php-mysqlnd and all my sites were on 41 char hash, everything would work fine except phpMyAdmin.
Not sure if this is a SiteWorx issue or because SiteWorx uses an outdated version of phpMyAdmin. I guess I could just install a new version phpMyAdmin on all my sites outside of SiteWorx. I’m not a big web hoster, it’s 99% hosting for people I have developed websites for so I’m the one managing the more technically stuff anyway, but it would be great if “it just worked”.
I think I’ll let this thread stay open for a bit and see if we can get anywhere, if not, then I might open a support ticket to see what the team says.
Many thanks, he was rushed in yesterday and operated on this morning. It went very well thankfully and hopes to out of hospital on Monday.
You need to readd old password and set to zero, then for iWorx account, set the password to small hash value, restart MySQL and then edit my.cnf and set value back to 1, for new hash.
This allows IW to correctly connect to MySQL ver 4, and hosting sites to MySQL ver 5, and any new MySQL db, would use the new hash.
If the IW password is reset to new hash password again, repeat same. The only affect of the hash is non display of IW
The reason for this, is IW has it’s own MySQL ver 4, used only for IW, with no external access
I didn’t quite follow that. The first thing I need to make clear is that I’m not touching anything with the InterWorx database. This is only the end user mysql I’m dealing with here.
When I said the special IW database user, I meant that SiteWorx creates a DB user in the end user mysql user database, so that it can access the database via SiteWorx phpMyAdmin.
If old_passwords is removed or set to 0, when you click to open phpMyAdmin from SiteWorx, it creates a user with the sitework account name (e.g. abcwidge from my example above) and then uses that to connect to the database on phpMyAdmin. The issue is with that old_passwords set to 0, when it creates the user for abcwidge it does so with a 41 char hash (as it should), but then phpMyAdmin and/or SiteWorx doesn’t like it.
This abcwidge account seems like it’s created on the fly, meaning it’s removed after it’s used and then recreated by SiteWorx the next time someone goes into phpMyAdmin through SiteWorx. So basically I have to leave old_passwords=1 if I want phpMyAdmin to work and can’t move to the new php-mysqlnd driver, which I believe is now the default install for php 5.4 (or maybe they started that at php 5.5).
I’m hoping a developer can shed some light on if the issue is just phpMyAdmin needing an upgrade or if it’s something in SiteWorx that can be updated. Or if these problems will be resolved when IW 5.1 comes out?
Not sure if there is still a proper place to list bug reports in the forums or if I should just open a ticket?
Sorry, I think you have it correct as there is only my.cf and I may have got the on/off code wrong (sorry tired) ie old-password= 0 or 1.
This needs to set in my.cf and one turns on old password hash which IW password should be, but as long as password not changed, when old password turned off, everything should work as expected.
I’ll do a quick search for this now and post, but I’m sure you d read it.
I’d open a support ticket as bugs posting has been closed in favour of ideas page from main website.
I am currently also in the need of new password hashes to enable support for PHP 5.6 for our customers.
We are offering a remote DB Server wit MySQL 5.5 to our customers, so I assume if I change my.cnf on this server it shouldn’t make problems, or does interworx need old-passwords for “iworx” users on all DB servers?
This whole thing somehow makes me very confused.
When I change old_passwords to zero, this won’t change any currently saved hashes, so everything should still be working as before and only new created mysql-users and reset/changed passwords will get a new hash. Am I right?
Will the password for the “iworx” DB user ever be reset/changed?
And just for info: On my DB servers I have many db-users with the same names as the unix-users. So it doesn’t seem that they would only be created on-the-fly when connecting via PHPMyAdmin and deleted afterwards. But if it’s a problem if those users had a new password hash, as described by Justec, in my eyes, that would be the biggest problem.
I think I will have to try it out, but as we are on a production server with many customers I am a little bit afraid (and maybe still to confused ).
I think the confusion comes because do not consider IW uses it’s own MySQL, which is separate from the hosting accounts MySQL.
The difference been IW MySQL is ver 4, and the hosting accounts can be any version of MySQL.
This is why it is important to keep the old hash in my.cnf, purely for the internal IW MySQL.
If the IW password hash is upgraded to the higher hash value, your websites/MySQL db would still work fine, but you would have a fail on siteworx account, but is easily corrected by resetting the my.cnf to old password, and rehashing IW password, then change my.cnf back for new hash password.
I hope that helps and I have extensively tested this, also, IW allow you to have seperate MySQL servers if you wanted/needed.
I’m not sure this has to do with the InterWorx MySQL4 database or not. Everything from my test shows that the passwords and all are stored in the customer end MySQL, not Iworx.
I have confirmed through a support ticket that phpMyAdmin through SiteWorx will not work unless old_passwords is enabled. This is a known issue and is already resolved in InterWorx 5.1.
So as of now I’m sticking to php 5.4 and old_passwords enabled until 5.1 is released.
).