Announcement

Collapse
No announcement yet.

Urgent: Update to 7.0: Error 500: No database driver specified

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Urgent: Update to 7.0: Error 500: No database driver specified

    I did the standard terminal update to 7.0. I got the following:

    php command.php upgrade
    Current version is 6.1.10.
    EspoCRM will be upgraded to version 7.0.0 now. Enter [Y] to continue.
    Y
    Downloading...
    Upgrading... This may take a while..............PHP Warning: array_keys() expects parameter 1 to be array, int given in /var/www/html/xxxxxxxpublic_html/espocrm/application/Espo/Core/Utils/Config.php on line 303



    When trying to start the system I get: Error 500: No database driver specified

    Please, how do I recover from this. It is urgent.

    Al

  • #2
    Here are the log entries:

    [2021-10-02 17:45:08] WARNING: E_WARNING: The use statement with non-compound name 'Throwable' has no effect {"code":2,"message":"The use statement with non-compound name 'Throwable' has no effect","file":"/var/www/html/mailanc2.net/public_html/espocrm/data/upload/upgrades/61589a8e8bc9309a4/scripts/AfterUpgrade.php","line":40} []
    [2021-10-02 17:45:09] ERROR: Uncaught Exception RuntimeException: "No database driver specified." at /var/www/html/xxxxxxxx/public_html/espocrm/application/Espo/Core/ORM/EntityManagerFactory.php line 141 {"exception":"[object] (RuntimeException(code: 0): No database driver specified. at /var/www/html/xxxxxxx.net/public_html/espocrm/application/Espo/Core/ORM/EntityManagerFactory.php:141)"} []
    [2021-10-02 17:45:09] ERROR: Upgrade Error:

    Comment


    • #3
      At the end of upgrade some config params should have been moved to config-internal.php file. Could be that the file was not created for some reason, or some access issue.

      Recover the following config parameters from your backup and put it to config.php (or config-internal.php).

      'cryptKey',
      'hashSecretKey',
      'apiSecretKeys',
      'database',
      'internalSmtpPassword',
      'passwordSalt',
      'webSocketSslCertificateLocalPrivateKey',


      Or restore the backup.

      Comment


      • #4
        What is "config-internal.php"? Is that a new file for 7.x? I do't see it in 6.1.9. Perhaps it is a temp. file during an upgrade?

        In all the years I've used EspoCRM I've NEVER had a bad update. With any other system (SugarCRM) I would have waited from going to 6.x.x to 7.0 but this time I didn't and paid the price.

        I had a backup 'dump' of the database but not of the code directory. I never thought I'd need one... and I thought wrong!

        I could not find instructions on how to revert back to the previous version so I spent the afternoon creating a new directory and installing 6.1.9 from the copy on GitHub https://github.com/espocrm/espocrm/releases

        I created a new MySQL database and then did the 6.1.9 install script. I tried to find out if I could have done a new install and used the current database but I never found the answer do I did the creation of the new database and then imported the dump file. Maybe I should have done the import of the database before I did the install.

        Anyway, after I fixed a few ownership issues, the system ran just fine.

        I'll try updating to 6.1.10 which I expect will be fine (and yeah, I have a full espocrm directory zipped up now!) But I'll wait a month or so before I move to 7.x.
        Last edited by dev77; 10-03-2021, 04:07 PM.

        Comment


        • #5
          I v7.0 we have data/config-internal.php where sensitive config params should be stored. Upgrade script should have moved some params to internal config. For some reason if failed to do on your env. Not sure why.

          Comment


          • #6
            Originally posted by yuri View Post
            I v7.0 we have data/config-internal.php where sensitive config params should be stored. Upgrade script should have moved some params to internal config. For some reason if failed to do on your env. Not sure why.
            In terms of security will will be the difference between the config.php and the config-interman.php file? On the failed install, it created the new file but it was empty.

            Did the error message that came back from the install make any sense to you? It looks like the install wants to strip out some items from config.php and put them somewhere else (maybe config-internal) and it looks like it did that and left the config.php without the database section so of course the script fails.

            Could it be a permissions or ownership issue? After the broken install the config.php file has permissions of 644 with the owner and group being me. But on the new 6.1.9 install I did to recover the config.php file has 664 permissions and owner:group both as www-data.

            I don't know why some files are me:me and some are me:www-data and some are www-data:www-data on my 'new' install. But 6.1.9 is working just fine... just as every other version of EspoCRM has ALWAYS worked from day-1... until this 7.0 upgrade.

            If I can be of help, let me know.

            Al

            Comment


            • #7
              Any param in config-internal supposed never make its way to the frontend regardless metadata defining whether a specific param is allowed or not. So having sensitive params in config-internal is an extra security measure for cases when access control based on metadata is failed or a developer forgot to forbid a custom param.

              The errors from your log just indicated me that the file could not be written. I suppose it was caused by permissions by I'm not yet sure.

              Comment


              • #8
                The fact that you have files owned by your user (rather than www-data) means that Espo could not change ownership of files when you run upgrade under your user.

                You can avoid it by:

                1. running upgrade script under www-data user;
                2. or running under root user;
                3. or adding your user to www-data group and change all file permissions to 664.
                Last edited by yuri; 10-04-2021, 08:02 AM.

                Comment


                • #9
                  Originally posted by yuri View Post
                  The fact that you have files owned by your user (rather than www-data) means that Espo could not change ownership of files when you run upgrade under your user.

                  You can avoid it by:

                  1. running upgrade script under www-data user;
                  2. or running under root user;
                  3. or adding your user to www-data group and change all file permissions to 664.


                  1. How would I run under a different user? I've never done that... ever.

                  2. To run as root, would running: "sudo php command.php upgrade" run the entire script under root? What ownership would EspoCRM write to new files? me, root, or www-data?

                  3. The user (me... xxx below)) is a member of www-data group.
                  xxx@saturn:/var/www/html$ groups xxx
                  xxxx : xxx sudo www-data

                  Do you have the chmod command(s) to change all of the files to the permissions you want us to use?

                  I'm going to update to 6.1.10 but it will be a while before I try the new 7.0.1 that came out today.

                  Comment


                  • #10
                    sudo -u www-data php command.php upgrade

                    I don't recommend to tweak with file permissions, it may require additional configuration in espo so that all new files will be created with 664. Resort to it only if you don't have www-data or root access.
                    Last edited by yuri; 10-04-2021, 03:34 PM.

                    Comment


                    • #11
                      Originally posted by yuri View Post
                      sudo -u www-data php command.php upgrade
                      Thanks. I'll run the update that way from now on. I'll wait for 7.1

                      Comment


                      • #12
                        Originally posted by yuri View Post

                        The errors from your log just indicated me that the file could not be written. I suppose it was caused by permissions by I'm not yet sure.
                        The system wrote part of the new /data/config.php file but left out several sections, the main one being the data section. The implies some kind of issue with the update code and not permissions or ownership.

                        Comment


                        • #13
                          What is "data section*?

                          It wrote config.php w/o items that supposed to be moved to config-internal.php. But failed to write config-internal.php (due permissions I guess). I've already fixed that config.php will be written only after config-internal.php is written, this should prevent losing data. The system will be reverted if config-internal could not be written.

                          All code for storing config is not in upgrade but here: https://github.com/espocrm/espocrm/b...riter.php#L108
                          Last edited by yuri; 10-05-2021, 06:00 AM.

                          Comment


                          • #14
                            Originally posted by yuri View Post
                            What is "data section*?
                            I meant "database" section:

                            'database' => [
                            'driver' => 'pdo_mysql',
                            'host' => 'localhost',
                            'port' => '',
                            'charset' => 'utf8mb4',
                            'dbname' => 'espocrm2_db',
                            'user' => 'xxxxx',
                            'password' => 'yyyyyy'
                            ],

                            All code for storing config is not in upgrade....
                            I assume this code will be in the 7.0.2 update? I can wait for that.

                            Thanks.

                            Comment


                            • #15
                              It's already in 7.0.1.

                              Comment

                              Working...
                              X