Initial Setup Error

[MarkTheDaemon]

Hi all,

 

Really looking forward to trying v3, been around since early on v2. Have installed and got to the initial setup screen, filled out the relevant details however it is just throwing a blank page after submitting the form. Have attached the error_log that was in the root directory.

 

Cheers,

 

Mark

error_log.txt

[Michael]

Do you have PDO functions installed?

You may wish to list the PHP version, MySQL version and OS to assist the dev team quicker.

[MarkTheDaemon]

Have listed the install screen below

 

 

Minimum Requirements: PASS

PHP version 5.1.3 or greater is required. Your version: 5.3.27. PASS

The PDO extension is required. PASS

The pdo_mysql extension is required. PASS

The curl extension with a minimum version of 7.10.5 is required. Your version: 7.24.0 PASS

The openssl extension with a minimum version of 0.9.6 is required. Your version: 1.0.0 PASS

The ionCube Loader extension is required. PASS

The config file (/home/forumdoc/my/public_html/config/blesta-new.php) and directory (/home/forumdoc/my/public_html/config/) must be writable by the webserver (you can change these back after installation is complete). PASS

Recommended Requirements: PASS

For best results, PHP 5.2 or greater is recommended. PASS

The mcrypt extension is recommended for better performance. PASS

The gmp extension is highly recommended for better performance. PASS

The json extension is recommended for better performance. PASS

For better performance ensure that /home/forumdoc/my/public_html/cache/ is writable by the webserver. PASS

For best results a memory limit of at least 32M is recommended. Your setting: 128M PASS

For added security, 'register_globals' should be disabled. PASS

The imap extension is required to send and receive mail via SMTP and IMAP. PASS

The simplexml and libxml extensions are highly recommended as they may be required to interface with some systems. PASS

The zlib extension is highly recommend for better performance. PASS

 

Have run the install again and getting the message that the configuration file has been written. blesta-new.php has been moved to blesta.php however the database details have not been entered.

 

 

Configure::set("Blesta.database_info", array(
	'driver' => "mysql",
	'host'	=> "{database_host}",
	//'port' => "8889",
	'database' => "{database_name}",
	'user' => "{database_user}",
	'pass' => "{database_password}",
	'persistent' => false,
	'charset_query' => "SET NAMES 'utf8'",
	'options' => array()
	)
);

 

[MarkTheDaemon]

Just to add, the database appears to have been fully populated, from accounts_ach to user_otps, 94 tables in all.

[Michael]

Oh ok, you'll need Paul, Cody or Tyson to look into this.

[MarkTheDaemon]

Also happy to allow access to the system/install if required to debug the issue by the developers.

[Tyson]

Can you compare the content in blesta-new.php with blesta.php? What are the differences, if any?

 

What OS and version of PHP are you running?

[MarkTheDaemon]

Hi Tyson,

 

Can you compare the content in blesta-new.php with blesta.php? What are the differences, if any?

 

What OS and version of PHP are you running?

 

Both files are identical, only change is the installer has renamed the file but done nothing after that.

 

OS is CentOS 6.4, PHP version is 5.3.27.

[Michael]

Hi Tyson,

 

 

Both files are identical, only change is the installer has renamed the file but done nothing after that.

 

OS is CentOS 6.4, PHP version is 5.3.27.

 

Erm I would try removing blesta.php, remove database, remove user, remake them both, connect them both and try again, http://yourdomain.com/install/

If that fails I'm confused.

[MarkTheDaemon]

Erm I would try removing blesta.php, remove database, remove user, remake them both, connect them both and try again, http://yourdomain.com/install/

If that fails I'm confused.

 

Same result unfortunately. This install is being attempted on a bog standard cPanel server that fits the requirements, nothing custom or special. It seems like the installer is falling down at the config writing step, and there doesn't appear to be a failback in place to allow the user to download and upload the config file and then carry on with the install.

 

Disappointing, sure the developers will get it improved though.

[Ken]

The error message in the screenshot you uploaded says that blesta-new.php isn't writable.  Make sure it's writable by the webserver.  If it's a cPanel account then usually the owner:group would be the username of that account.

[MarkTheDaemon]

The error message in the screenshot you uploaded says that blesta-new.php isn't writable.  Make sure it's writable by the webserver.  If it's a cPanel account then usually the owner:group would be the username of that account.

 

With respect, I'm an advanced user who has been using Blesta since 2009 so I do know what I'm doing. The config/ directory is set at 777 and blesta-new.php is set at 666.

 

Also, if the directory and file wasn't writeable why allow the installer to say that it is a pass in the minimum requirements section of the installer as I posted earlier?

[Paul]

I'm guessing this was not compiled with suPHP?

 

Just to be clear..

 

1. Before install, you set the config directory to 777, and blesta-new.php to 666.

2. After you attempt to install it renames blesta-new.php to blesta.php but doesn't do tag replacement on database variables

 

Question: What are the permissions of blesta.php after it is renamed? Is it still 666 or something else?

 

If it's not writable by the web server at that point, my guess is that it may rename the file first and then attempt to do the variable replacements but it can't because it's no longer writable.

 

If this is what's happening, we should be able to look into a fix. Can you confirm?

[Michael]

I'm guessing this was not compiled with suPHP?

 

Just to be clear..

 

1. Before install, you set the config directory to 777, and blesta-new.php to 666.

2. After you attempt to install it renames blesta-new.php to blesta.php but doesn't do tag replacement on database variables

 

Question: What are the permissions of blesta.php after it is renamed? Is it still 666 or something else?

 

If it's not writable by the web server at that point, my guess is that it may rename the file first and then attempt to do the variable replacements but it can't because it's no longer writable.

 

If this is what's happening, we should be able to look into a fix. Can you confirm?

Paul I wonder if you could check if suPHP is installed on installation? to ensure people don't miss that

[Paul]

Paul I wonder if you could check if suPHP is installed on installation? to ensure people don't miss that

 

suPHP is not a requirement, but it does eliminate many permissions issues. Still, I'd like determine the cause for what he is experiencing so we can debug it and implement a fix.

[Michael]

suPHP is not a requirement, but it does eliminate many permissions issues. Still, I'd like determine the cause for what he is experiencing so we can debug it and implement a fix.

Ah I see mate

[MarkTheDaemon]

I'm guessing this was not compiled with suPHP?

 

Just to be clear..

 

1. Before install, you set the config directory to 777, and blesta-new.php to 666.

2. After you attempt to install it renames blesta-new.php to blesta.php but doesn't do tag replacement on database variables

 

Question: What are the permissions of blesta.php after it is renamed? Is it still 666 or something else?

 

If it's not writable by the web server at that point, my guess is that it may rename the file first and then attempt to do the variable replacements but it can't because it's no longer writable.

 

If this is what's happening, we should be able to look into a fix. Can you confirm?

 

Hi Paul,

 

SuPHP is actually active on this server and working normally for all other PHP applications.

 

The config directory is set to 777 and blesta-new.php to 666 before the install is attempted. The installer gives a pass to this requirement as well.

 

After the installation attempt blesta-new.php is renamed blesta.php, the permissions stay at 666 but no tag replacement is done at any level; this includes the database details but also the system key.

[Michael]

Hi Paul,

 

SuPHP is actually active on this server and working normally for all other PHP applications.

 

The config directory is set to 777 and blesta-new.php to 666 before the install is attempted. The installer gives a pass to this requirement as well.

 

After the installation attempt blesta-new.php is renamed blesta.php, the permissions stay at 666 but no tag replacement is done at any level; this includes the database details but also the system key.

I thought blesta-new.php stayed there.

 

I have both blesta-new.php and blesta.php. But I suppose I just copy the files over when upgrading so that's probably why.

[MarkTheDaemon]

I thought blesta-new.php stayed there.

 

I have both blesta-new.php and blesta.php. But I suppose I just copy the files over when upgrading so that's probably why.

 

Looks like the file is just renamed, line 258 of app/controller/install.php

 

/**
	 * Write the config file details
	 *
	 * @return false If the file could not be renamed (e.g. written to)
	 */
	private function writeConfig() {
		
		// Attempt to rename the config from blesta-new.php to blesta.php
		if (!rename(CONFIGDIR . "blesta-new.php", CONFIGDIR . "blesta.php"))
			return false;
		
		// Generate a sufficiently large random value
		Loader::load(VENDORDIR . "phpseclib" . DS . "Crypt" . DS . "Random.php");
		$system_key = md5(crypt_random() . uniqid(php_uname('n'), true)) . md5(uniqid(php_uname('n'), true) . crypt_random());
		
		$config = file_get_contents(CONFIGDIR . "blesta.php");
		$replacements = array(
			'{database_host}' => $this->db_info['host'],
			'{database_name}' => $this->db_info['database'],
			'{database_user}' => $this->db_info['user'],
			'{database_password}' => $this->db_info['pass'],
			'{system_key}' => $system_key
		);
		foreach ($replacements as &$value) {
			$value = str_replace(array('\\', '$', '"'), array('\\\\', '\$', '\"'), $value);
		}
		
		file_put_contents(CONFIGDIR . "blesta.php", str_replace(array_keys($replacements), array_values($replacements), $config));
		
		return true;
	}

Looks like the installer could possibly be falling down while trying to set up the system key, even if it couldn't do the variable replacement it would still return true, perhaps need another error check in there; being able to rename the file doesn't automatically mean that it was written successfully.

[Michael]

Ah learn something new every day haha, not sure why it worked for me then :s. 

 

http://screencast.com/t/ugMjFYL4

 

so weird.

[MarkTheDaemon]

As an aside, I think the installer needs a bit more work generally, after setting blesta-new.php permissions to 444 the installer still says that the file is writeable!

[Paul]

As an aside, I think the installer needs a bit more work generally, after setting blesta-new.php permissions to 444 the installer still says that the file is writeable!

 

If you are using suPHP then it would be writable so long as owner is writable.

 

In app/controller/install.php I wonder what would happen if you bypass the key generation. Would you mind giving this a try?

 

Comment out lines 270 and 271 and statically set $system_key to something.

 

		// Generate a sufficiently large random value
		// Loader::load(VENDORDIR . "phpseclib" . DS . "Crypt" . DS . "Random.php");
		// $system_key = md5(crypt_random() . uniqid(php_uname('n'), true)) . md5(uniqid(php_uname('n'), true) . crypt_random());
		$system_key = "somethingrandomtotestwith";

 

Then run the installer, does it populate config/blesta.php's database details?

[MarkTheDaemon]

If you are using suPHP then it would be writable so long as owner is writable.

 

Setting the file to 444 means that it is read only for everyone, including the owner, and the install still reports it as writeable so I'm not convinced that the check is working correctly on that front.

 

I will take out the system key code and let you know what happens.

[MarkTheDaemon]

Removed the system key generation code and the file was written successfully with database details and the dummy details I used for $system_key.

 

However, once on the initial setup page after filling in my details it just returns a blank screen. No errors in the apache log.

[MarkTheDaemon]

Have now set Blesta up on another VM successfully.

[domaingood]

The openssl extension with a minimum version of 0.9.6 is required. Your version: FAIL to me

 

I m use XAMPP Latest ver with php5.5 SSL Version OpenSSL/1.0.1g

 

OpenSSL to 1.0.1g

Apache to 2.4.9

PHP to 5.5.11

phpMyAdmin 4.1.12