Forums

MySQL Error on Fresh 5.6.0.2 Install

Permalink
Hello, I'm trying to evaluate Concrete 5 as a replacement for our current CMS but I can't get the current version to work either through migrations from an earlier version or a fresh install. In theory I'm excited about this CMS, but in practice I'm a little scared to use it in production.

My configuration:

- OpenSUSE 12.1, all current upgrades as of this post
- MySQL v5.5.25 installed through yast2
- PHP v5.3.8 installed through yast2
- Apache2 v2.2.21 installed through yast2

When installing I get this error:
mysql error: [1048: Column 'uID' cannot be null] in EXECUTE("INSERT INTO Config (cfKey,cfValue,uID) VALUES ('NEWSFLOW_LAST_VIEWED','FIRSTRUN',NULL)")

Looking at the appropriate db.xml file, that field does not have the <NOTNULL /> tag, so I don't know why it doesn't match the schema generated. I'm not a PHP guy though so I didn't debug much further.

With this same setup I can install 5.4.2.2 and upgrade to 5.5.2.1 with no apparent errors. When I upgrade to 5.6.0.2 though my edit bar doesn't show (the javascript to render it isn't written) and I can't adjust permissions for anything with simple or advanced permissions in the dashboard (I can get to the dashboard if I type the url in manually).
 
nazweb replied on at Permalink Reply
I figured I would post my solution to getting 5.5.2.1 to install all the way through. I added this to the ./concrete/models/package/starting_point.php file at line 208:

$u->ID = 0;


The context of this then becomes:

Config::save('SITE', SITE);
Config::save('SITE_APP_VERSION', APP_VERSION);
$u = new User();
$u->ID = 0;
$u->saveConfig('NEWSFLOW_LAST_VIEWED', 'FIRSTRUN');


If I do the same thing in 5.6.2.2 I get a little bit further, but then I get a class not found error, which is fixed by adding an include. After that the site is still broken in the same way, but it reports having installed successfully.
nazweb replied on at Permalink Best Answer Reply
The underlying problem is actually Concrete 5 nuking the user session. In concrete/startup/session.php, the length of the session key is checked, presumably as a security measure. Since I'm not a PHP developer I don't know why that's important. The two php.ini settings that control key length are:

session.hash_bits_per_character : Higher numbers make shorter keys
session.hash_function : Different hash functions have different lengths

My default OpenSUSE install set hash_bits_per_character at 5 and the hash_function at SHA256, which is more secure than 1 (SHA-1), so I'm going to guess this is a bug. To make all my problems go away I modified the concrete/startup/session.php file to comment out the following three lines.

if (isset($_COOKIE[SESSION]) && strlen($_COOKIE[SESSION]) > 32) {
   unset($_COOKIE[SESSION]);
}
ceaus replied on at Permalink Reply
Brilliant! You've nailed it. I stopped trying after messing with this back in October. Many thanks!
andrew replied on at Permalink Reply
andrew
I am upping this max value to 128 instead of 32.
nazweb replied on at Permalink Reply
Thanks, I just logged on to post a follow-up saying this was fixed on 5.6.1.1 and noticed your comment (https://github.com/concrete5/concrete5/blob/5.6.1.1/web/concrete/startup/session.php) :)