Issue in upgrade from 17.1 to 19.1

vishakha 2020-07-06 21:55:04 UTC #1

I have started an upgrade from 17.1 to 19.1, however after logging in I get the following errors in log file and a message on the first page after logging in.

(mod_fastcgi.c.421) FastCGI-stderr: Database error (EGroupware\Api\Db\Exception\InvalidSql): Invalid SQL: UPDATE egw_access_log SET  WHERE
2020-07-06 15:53:30: (mod_fastcgi.c.421) FastCGI-stderr: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'WHERE>
2020-07-06 15:53:30: (mod_fastcgi.c.421) FastCGI-stderr: #0 /project/egroupware/api/src/Db/Deprecated.php(64): EGroupware\Api\Db->query('UPDATE egw_acce...', NULL, NULL, 0, >
2020-07-06 15:53:30: (mod_fastcgi.c.421) FastCGI-stderr: #1 /project/egroupware/api/src/Db.php(1980): EGroupware\Api\Db\Deprecated->query('UPDATE egw_acce...', 1830, '/home/>
2020-07-06 15:53:30: (mod_fastcgi.c.421) FastCGI-stderr: #2 /project/egroupware/api/src/Session.php(1830): EGroupware\Api\Db->update('egw_access_log', Array, Array, 1830, '/>
2020-07-06 15:53:30: (mod_fastcgi.c.421) FastCGI-stderr: #3 /project/egroupware/api/src/Session.php(1307): EGroupware\Api\Session->update_dla(true)
2020-07-06 15:53:30: (mod_fastcgi.c.421) FastCGI-stderr: #4 /project/egroupware/api/src/Egw.php(299): EGroupware\Api\Session->verify()
2020-07-06 15:53:30: (mod_fastcgi.c.421) FastCGI-stderr: #5 /project/egroupware/api/src/Egw.php(254): EGroupware\Api\Egw->verify_session()
2020-07-06 15:53:30: (mod_fastcgi.c.421) FastCGI-stderr: #6 /project/egroupware/api/src/loader.php(83): EGroupware\Api\Egw->wakeup2()
2020-07-06 15:53:30: (mod_fastcgi.c.421) FastCGI-stderr: #7 /project/egroupware/header.inc.php(81): require_once('/home/www.temps...')
2020-07-06 15:53:30: (mod_fastcgi.c.421) FastCGI-stderr: #8 /project/egroupware/json.php(110): include_once('/home/www.temps...')
2020-07-06 15:53:30: (mod_fastcgi.c.421) FastCGI-stderr: #9 {main}

Error message on screen

A request to the EGroupware server returned with an error: OK (200)

Please reload the EGroupware desktop (F5 / Cmd+r).
If the error persists, contact your administrator for help and ask to check the error-log of the webserver.

URL: project/egroupware/json.php?menuaction=status.jdots_framework.ajax_exec.template.status.EGroupware%5CStatus%5CUi.index
date: Mon, 06 Jul 2020 21:50:27 GMT

My installation is archive and the update is done via composer

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
					 php -r "if (hash_file('sha384', 'composer-setup.php') === 'e0012edf3e80b6978849f5eff0d4b4e4c79ff1609dd1e613307e16318854d24ae64f26d17af3ef0bf7cfb710ca74755a') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
					 vim /etc/php/php.ini:
											open_basedir =+ :/root/
					 php composer-setup.php					 
					 ln -s project/composer.phar /usr/local/bin/composer
					 pacman -S nodejs npm
					 npm install grunt
					 pacman -S php-xsl
					 vim /etc/php/php.ini:
											uncomment:
														extension=xsl.so
														extension=bcmath.so
					 composer create-project --prefer-source --keep-vcs egroupware/egroupware

Version
versions’ =>
array (size=5)
‘current_header’ => string ‘1.29’ (length=4)
‘maintenance_release’ => string ‘17.1.20180720’ (length=13)
‘api’ => string ‘17.1.003’ (length=8)
‘phpgwapi’ => string ‘17.1.003’ (length=8)
‘header’ => string ‘1.29’ (length=4

Maria db is ued
lighttpd server is used
PHP version is 7.2
installation type : archive installation

J_Roeleveld 2020-07-07 14:57:08 UTC #2

To avoid issues like this, I actually migrated to using the docker images myself.
I find the updates using those to be far more reliable and less error-prone than the composer method.

vishakha 2020-07-10 15:14:36 UTC #3

Thanks for the advice Roeleveld!
I’ll consider that, but it’s strange the error here is regarding the update of access log in db, I don’t understand how the arguments are not passing to the query in this version

vishakha 2020-07-10 16:18:07 UTC #4

Can someone help me if there was anything wrong with the composer update method for my archive installation. All other updates look okay, the db update was successful.

Why is the access log update query not having any arguments when the user is already existing and login is successful ?

Is this the case that version 19.1 (version 19.1.20200318) can only be upgraded via docker

StefanU 2020-07-10 17:34:30 UTC #5

Hi vishakha.

I don’t understand what you’re doing. What does an archive install have to do with Docker?

Stefan

RalfBecker 2020-07-10 17:42:50 UTC #6

Using composer is generally ok, our containers are also build with composer.

Question is, did you run the necessary database migrations?

If not, go to setup (https://your.domain/egroupware/setup/ upper login) and run them.

Ralf

vishakha 2020-07-10 17:43:00 UTC #7

Hi Stefan,

I’m under the process of upgrading my version to 19.1 from 17.1.
My current installation type is archive and the upgrade method was through composer.
I posted the errors I’m receiving in the first message in the post. I can’t seem to figure out the cause of the access log update query failure. I even removed my custom application to see if anything changes.

Could you guide me if you notice anything here. The exact version is 19.1.20200318.
This is something I had been trying since so long, any help would be appreciated

I was just curious about docker updates and had questions if that’s possible in my case.

vishakha 2020-07-10 17:52:47 UTC #8

Yeah I ran them, they seemed to have executed well
I can see in the setup that db updates were successful

StefanU 2020-07-10 17:54:08 UTC #9

Read this:

and then decide if the EGroupware standard docker installation is right for you.

Maybe you can install another system and try it out first. I once wrote something about my installation:

There is a reason why we install EGroupware as standard with Docker. Some things can only be realized if we separate EGroupware and the integrated systems (Collabora Online, Rocket.Chat, Guacamole and what ever…) as containers. Among a few other reasons…

Stefan

RalfBecker 2020-07-10 18:05:04 UTC #10

Docker installation allows you to run / integrate your own custom apps, just clone them into /usr/share/egroupware on the host and the starting container will copy them into the container.

There has been no schema change on egw_access_log table between 17.1 and 19.1.

Maybe the problem is caused by an “old” session, created under 17.1 now have trouble with the 19.1 sources.

Ralf

vishakha 2020-07-10 18:09:26 UTC #11

So should I remove the data from access log table to start a new session record ?
because the issue is the arguments only are not being passed in the query, usually the missing arguments came from missing schema structure, so I’m confused a bit

vishakha 2020-07-10 19:59:58 UTC #12

Okay I tried truncating the access log table, I still have the issue with update query as I check the logs and additionally see the following in my console.

Ajax request to https://project/egroupware/json.php?menuaction=rocketch…_exec.template.rocketchat.EGroupware%5CRocketchat%5CUi.index failed: parsererror 200 OK
Ajax request to https://project/egroupware/json.php?menuaction=status.j…ork.ajax_exec.template.status.EGroupware%5CStatus%5CUi.index failed: parsererror 200 OK
Ajax request to https://project/egroupware/json.php?menuaction=infolog.jdots_framework.ajax_exec.template.infolog.infolog_ui.index failed: parsererror 200 OK
Ajax request to https://project/egroupware/json.php?menuaction=filemana…ramework.ajax_exec.template.filemanager.filemanager_ui.index failed: parsererror 200 OK

vishakha 2020-07-13 14:14:29 UTC #13

Do you have any solution in mind that I can try in this case.

RalfBecker 2020-07-13 14:30:17 UTC #14

Check if the error still happens after manually calling https://example.org/egroupware/logout.php and login in again.

Ralf

vishakha 2020-07-13 14:36:30 UTC #15

Yes it still exists

2020-07-13 09:34:57: (mod_fastcgi.c.421) FastCGI-stderr: Database error (EGroupware\Api\Db\Exception\InvalidSql): Invalid SQL: UPDATE egw_access_log SET WHERE

J_Roeleveld 2020-07-13 18:50:57 UTC #16

I see a red X in step 4, did you manage to clear that?

vishakha 2020-07-13 19:04:07 UTC #17

This is because I removed my custom application folder from egroupware directory, thinking that this might be causing issues.
Even if I put the custom application directory back in, it still gives the error I’ve been facing. The setup config will be fixed thereafter.

RalfBecker 2020-07-14 07:02:27 UTC #18

Only explanation I have for that mangled SQL is that our main schema file (api/setup/tables_current.inc.php) is somehow broken. Are you sure not having any git conflicts?

I suggest the following:

get a EGroupware backup from your 17.1 installation
make a regular 19.1 or 20.1 installation on one of our supported Linux distros
restore your backup

Ralf

vishakha 2020-07-14 17:16:59 UTC #19

Okay thanks for your advice

I started the upgrade again from 17.1 and have 20.1 version now, working without the access log issues.

I have now the following errors

Call to undefined method EGroupware\Api\Session::appsession().

Please advice how to fix this

Also since phpgwapi has now been removed, I was using the following code in my custom application which now is deprecated. How do I fix this

$this->jscal = createObject('phpgwapi.jscalendar');

RalfBecker 2020-07-14 20:43:10 UTC #21

github.com

EGroupware/egroupware/blob/master/doc/fix_api.php

#!/usr/bin/env php
<?php
/**
 * EGroupware - check namespace usage in converted code
 *
 * @link http://www.egroupware.org
 * @license http://opensource.org/licenses/gpl-license.php GPL - GNU General Public License
 * @author Ralf Becker <rb@stylite.de>
 * @copyright 2016 by Ralf Becker <rb@stylite.de>
 * @version $Id$
 */

if (php_sapi_name() !== 'cli')	// security precaution: forbit calling as web-page
{
	die('<h1>fix_api.php must NOT be called as web-page --> exiting !!!</h1>');
}

// raw replacements
$add_use_api = array(
	"#use EGroupware\\\\Api;\n#" => '',	// remove evtl. use EGroupware\Api, as we add it again below

This file has been truncated. show original