Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2019-10-10 17:44:01

gaekwad
Admin
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 2,633

Re: 4.7.3 - any changes required for MySQL 8.0 compatibility?

OK, I’m 99.9% there: PHP user bludgeoning works perfectly with 4.7.3 RC1 (aka beta-demo), and 4.7.3 (aka release-demo), but the same build script seems to flip out when I use it with 4.8.0-dev (aka dev-demo). Should I be using a different route with 4.8.0 user creation?

There are two kinds of user account I’m generating: accounts for anyone to use (Managing Editors through to No Access, a thousand of each), and a single Publisher account that owns the default article, but nobody can use this unless they guess the password…

So, here’s how I make the Publisher account:

<?php
define('txpinterface', 'css');

require '/absolute/path/to/root/index.php';

create_user("textpattern-robot", "textpattern-robot@example.com", "verycomplexpasswordinplaintexthere", "Textpattern Demo Site Robot", 1);
?>

…and here’s the rahMagic© for making the users:

<?php
define('txpinterface', 'css');

require '/absolute/path/to/root/index.php';

for ($i = 1; $i <= 1000; $i++) {
    $name = 'managing-editor' . $i;
    create_user($name, "{$name}@example.com", $name, "Managing Editor #{$i}", 2);
}
?>

I create the Publisher first, then chew through the other users in ascending order: Managing Editors are done after the Publisher since most people use that account to log in, then the other types of account get done in turn.

The release and beta sites use the 4.7.3 codebase, and the rebuild process takes ~25 seconds for each one, pegging the CPU (as expected) in the process. All fine, and I can streamline this to make it faster soon.

However, the dev site script, which uses the same routine as the release and beta sites, inserts the Publisher…and then seems to stall. The CPU is pegged, and a few minutes later nothing has happened.

Has the create_user function changed sufficiently between 4.7.3 and 4.8.0-dev that I need to rewrite it? I’m using the same PHP CLI version to run the scripts, so I’m not sure what’s going on.

Offline

#12 2019-10-10 18:29:50

etc
Developer
Registered: 2010-11-11
Posts: 3,427
Website

Re: 4.7.3 - any changes required for MySQL 8.0 compatibility?

gaekwad wrote #319622:

Has the create_user function changed sufficiently between 4.7.3 and 4.8.0-dev that I need to rewrite it? I’m using the same PHP CLI version to run the scripts, so I’m not sure what’s going on.

As suggested by @petecooper, 4.8 uses the native password_hash() function that should be available since PHP 5.5. Can you try whether echo password_hash('hello', PASSWORD_DEFAULT); is working?

Offline

#13 2019-10-10 18:40:37

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,841
Website

Re: 4.7.3 - any changes required for MySQL 8.0 compatibility?

gaekwad wrote #319622:

However, the dev site script, which uses the same routine as the release and beta sites, inserts the Publisher…and then seems to stall.

Uh oh, your suggested optimisations appear to have backfired, Pete :p

Seriously, I dunno why it would stall like that. I can understand that PASSWORD_DEFAULT (which uses BCRYPT) might take a bit more processing power to generate than what we were using before but I would have thought the PHP team would optimise it if they could.

In addition to what Oleg suggests, does it stall or redline if you generate just a handful, say change the loop to $i <= 10? Maybe the sheer quantity is making the CPU melt as it does the bcrypt calculations and we need to batch them up or something.

Very weird.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#14 2019-10-10 18:46:41

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,841
Website

Re: 4.7.3 - any changes required for MySQL 8.0 compatibility?

The only other thing I can think of is that we don’t have enough space in our pass field for the latest version of PHP’s implementation (although I’d expect it to truncate if so, not burn up).

One of the things the PHP docs do state is that 60 chars (as of PHP5.5) is enough, but the idea is that they’ll gradually increase the size of the computed hash with each version of PHP and suggest 255 chars as a suitable max. Maybe PHP 7.4 has already breached our 128 VARCHAR limit?

Can’t see that being the issue but I’m at a bit of a loss as to why it’s behaving like this in 4.8.0-dev.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#15 2019-10-10 18:58:30

gaekwad
Admin
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 2,633

Re: 4.7.3 - any changes required for MySQL 8.0 compatibility?

etc wrote #319625:

As suggested by @petecooper,

Ahem.

Can you try whether echo password_hash('hello', PASSWORD_DEFAULT); is working?

It works. Refreshing the page provides a different hash each time.

Offline

#16 2019-10-10 19:01:50

etc
Developer
Registered: 2010-11-11
Posts: 3,427
Website

Re: 4.7.3 - any changes required for MySQL 8.0 compatibility?

gaekwad wrote #319628:

It works. Refreshing the page provides a different hash each time.

Fast and less than 128 chars?

Offline

#17 2019-10-10 19:08:04

gaekwad
Admin
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 2,633

Re: 4.7.3 - any changes required for MySQL 8.0 compatibility?

Bloke wrote #319626:

In addition to what Oleg suggests, does it stall or redline if you generate just a handful, say change the loop to $i <= 10? Maybe the sheer quantity is making the CPU melt as it does the bcrypt calculations and we need to batch them up or something.

Bingo. Good spot. I ran time against a different number of accounts:

10 accounts

real	0m0.822s
user	0m0.767s
sys	0m0.004s

100 accounts

real	0m6.971s
user	0m6.519s
sys	0m0.020s

…so I assume that adding a thousand accounts a) takes roughly ten times as long and b) chews up enough CPU & RAM on a low-grade VPS that it effectively stalls.

Maybe the sheer quantity is making the CPU melt as it does the bcrypt calculations and we need to batch them up or something.

I’ve flipped back to the old squirt-the-SQL method for 4.8.0-dev on the new server, that works A-OK, and I’ll divvy up the workload to get the build duration sorted. I have one of those plans up my sleeve that might be needlessly complex but will mean things are wicked fast at restore time. To be continued!

Regardless of my complexity, thank you both very much for your advice and input – greatly appreciated.

Offline

#18 2019-10-10 19:13:12

gaekwad
Admin
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 2,633

Re: 4.7.3 - any changes required for MySQL 8.0 compatibility?

etc wrote #319629:

Fast and less than 128 chars?

Yes and yes.

dev-demo.textpattern.co/add_users_etc_test.php (live until 2100UTC),

Offline

#19 2019-10-10 19:17:02

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,841
Website

Re: 4.7.3 - any changes required for MySQL 8.0 compatibility?

gaekwad wrote #319630:

10 accounts real 0m0.822s... / 100 accounts real 0m6.971s...

Jeez, didn’t think it’d be that pronounced. Wow. I wonder if the opcode behind the scenes is doing some background stuff (which makes hardcore pipelining impossible) to try and improve the perceived speed of these intensive calculations, which works great for one, but trips over itself if you try and batch ‘em up.

Veeeery interesting.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#20 2019-10-10 19:19:03

gaekwad
Admin
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 2,633

Re: 4.7.3 - any changes required for MySQL 8.0 compatibility?

Bloke wrote #319632:

I wonder if the opcode behind the scenes is doing some background stuff (which makes hardcore pipelining impossible) to try and improve the perceived speed of these intensive calculations, which works great for one, but trips over itself if you try and batch ‘em up.

I can get you a login if you’re curious…everything on the server is disposable and rebuildable, so little to no risk.

Offline

Board footer

Powered by FluxBB