-
Notifications
You must be signed in to change notification settings - Fork 9
Error during first pass setup: InstallController #113
Comments
You may be the first person to try installing under SSL, but it should work and it is something we need to fix if it does not. I will investigate. |
I went back and turned off SSL and attempted to complete the web installation process with the same result as before - a search for a malformed file name. It's my impression the POST/GET or session information is not being passed along correctly. As a result, the php variables holding parts of the database file name and location are not being set. Here's the bit of code constructing the filename (line 114, InstallController.php):
And here's an example of the error message with my modification that prints the actual name of the file it's looking for:
So you can see that both the type (from the drop down list) and file name are not resolving. I thought perhaps my browser security settings might be interfering, so I tried with another clean browser with the same results. |
I started comparing this current installation of Midas with an older one I inherited, built last year. It was problems with that older installation that prompted me to build a new one from scratch. I'll submit another post about that older installation, but by comparing the directory trees, I noticed that the Zend libraries had moved locations. In the older installation from last year, they are in: midashome/library/Zend In the new installation, they are buried deep in midashome/vendor/zendframework/zendframework1/library/Zend Could it be that the latest Zend framework has changed the path structure from what Midas expects? Or that my installation was faulty? The errors I'm seeing (form fields not transmitted) hint at an encapsulation problem and that's what the Zend framework is used for, right? |
The Zend location is tested nightly with the latest stable build of Zend Framework 1.x and there have been no issues of which I am aware. |
If not the Zend wrapper, what might account for the missing form fields? Some php.ini setting? How php itself is being run? |
I just built another Ubuntu server from scratch using Vagrant, cutting and pasting from the instructions for building MIDAS on Ubuntu. I get the same error message - sql file not found with my modification to the php showing that the form fields are not arriving from the browser. I now have a Vagrantfile and provisioning script so you can build the same machine. Let me know if those would be helpful and how I can get them to you. |
Can you create a Gist with the contents of the Vagrantfile and provisioning script and then post a link here? |
Here you go. I've included a Readme for the build: |
I made some very slight progress by forcing the $type variable to have a value of "mysql" on /var/www/midas/html/core/controllers/InstallController.php, line: 117 The initialization process appears to finish - in that I am taken to my "home" page with my named user listed. If I exit the lynx browser and log back in, neither the "Log In" or "Register" options work. So I suspect my $type="mysql" hack didn't really help other than getting passed the first hurdle. |
If you log in to the database, is the user table populated with the details you specified at installation? |
Also, are you still using SSL? |
Regarding SSL, no, I haven't turned that on. I'm running Vagrant now to rebuild the system. I'll insert my hack (InstallController.php, line 117, hardcode type='mysql') and run the setup page, log out and check the back end sql file to see if anything was changed. By the way, since the updated documentation doesn't mention having to set the midas database password manually through a mysql prompt like the older documentation on kitware, is everything supposed to be initiated through the web interface? ---Update--- Not that it helps, but The system has encountered the following error: Uncaught exception 'PDOException' with message 'SQLSTATE[42S02]: Base table or |
If your database is unsecured you would not need a password. If your database is secured, then you would need to set a password and supply the password on the installation page. The MySQL or Ubuntu documentation will give more details on securing the installation. |
I can confirm that the current recipe does not result in a working pre-setup MIDAS home page. I do not see any particular errors occurring during the installation of all the dependencies. As near as I can tell, the Zend framework installation has changed. Running the "php composer.phar install" command results in: Loading composer repositories with package information In the past, I seem to remember a number of different Zend modules being installed by the "install" command. Whereas in the past, the same Vagrant built a working MIDAS (at least the home page was served up), now the same recipe does not build a working MIDAS home page. The errors I posted most recently are generated when accessing the home page. |
Regarding the database setup, there are instructions in the old kitware documentation to set up BOTH a master sql password AND one for midas itself (along with an initial table, I believe). I'm wondering if the current web initiated setup is supposed to do the second part for me. All I should do outside of MIDAS itself is to secure my database with a master password using the mysql standard method? See the last line in the buildmidas.sh file. This is where I'm creating a midas database outside of MIDAS itself per the old kitware instructions. I'm asking if this is a necessary step or if it's now handled by the web directed setup process. |
I can also confirm that the current 3.4.1 cannot be built into a working midas setup. Did you have nay luck getting the Database installed? My set up (Mint 17.2, PHP 5.6, Apache 2.4) gives me this error after inputting the DB credentials. class InstallController extends AppController
{
public $_models = array('User', 'Assetstore', 'Setting');
public $_daos = array('Assetstore');
public $_components = array('Random', 'Utility');
public $_forms = array('Install');
# then onto line 115 where the error occurs
if ($form->isValid($this->getRequest()->getPost())) {
require_once BASE_PATH.'/core/controllers/components/UpgradeComponent.php';
$upgradeComponent = new UpgradeComponent();
$upgradeComponent->dir = BASE_PATH.'/core/database/'.$type;
$upgradeComponent->init = true;
$sqlFile = $upgradeComponent->getNewestVersion(true);
$sqlFile = BASE_PATH.'/core/database/'.$type.'/'.$sqlFile.'.sql';
if (!isset($sqlFile) || !file_exists($sqlFile)) {
throw new Zend_Exception('Unable to find sql file');
}
# I can't find this function getFormAsArray in the Extended class
$this->view->databaseType[$database] = $this->getFormAsArray($form);
# the function getFormAsArray is not in the Parent Class either Is this why the install fails? |
When I pull up the MIDAS home page for the first time after a fresh install on a Ubuntu system, I start the install process by entering the sql database information.
Continuing from there, I encounter the following error:
Unable to find sql file
In /var/www/midas/html/core/controllers/InstallController.php, line: 117
At 18:47:46 2015-05-18
I modified the exception thrown to print the name of the sql file it was trying to locate:
/var/www/midas/html/core/database//0.sq
The path is correct down to the database directory, but not after. So, looking at the code,
$sqlFile = BASE_PATH.'/core/database/'.$type.'/'.$sqlFile.'.sql'
it appears that the $type and $sqlFile variables are not being set. The $type variable should be arriving from the html dropdown list on the install page. The $sqlFile variable is set by a call to the getNewVersion method of $upgradeComponent. In my case, I installed version 3.4.0.
The file core/database/mysql/3.4.0.sql does exist.
So the problem seems to be the construction of the filename by the InstallController.php file.
The only point of divergence from the installation instructions I've introduced is that I'm forcing MIDAS to run under SSL. Do you think I'm missing some php.ini setting that's preventing HTML form entries from transmitting over SSL?
Thanks,
John.
The text was updated successfully, but these errors were encountered: