6 / 8
Dec 2021

Ralf, All,

I have nursed my trusty 1.8.007 install as far as I can. I need to move forward in time to the current release and don’t know if I will need to transition through incremental versions to move the database forward?

I toyed with 14 and 16.1, but always reverted due to pixelegg issues and loss of screen real estate.

From what I gather the egw update is fairly straight forward, install composer, grab clone the current repository, download and install the needed deprecated apps from 17.1, but what of the database backend? (MySQL - now MariaDB).

Will I need to do anything special or need to install incrementally to move my installation forward? Thanks for any help or suggestions you can give.

  • created

    Nov '21
  • last reply

    Sep '23
  • 7

    replies

  • 2.2k

    views

  • 3

    users

  • 9

    links

Hi David,

That is not the recommended and by far the most complicated way for an EGroupware installation!

You need eg. the npm stuff …

The recommended way on a Linux distribution is to use our packages, which install a set of docker Container:

The wiki also explains that you can and for an upgrade from before 14.1.004 you must install the deprecated API and other deprecated apps via their Linux packages (or clone them to /usr/share/egroupware on the host).

Give it a try with a clean new installation and test it. For the update you only need to do a DB backup inside EGroupware, rsync /var/lib/egroupware/default/{files,backup} to your new hosts /var/lib/egroupware/default/ and restore the backup via setup. (Remember you need the deprecated API to be able to update from before 14.1.003!)

The default installation comes with a MariaDB 10.4 running in a container, probably soon updated to 10.5.

Ralf

And of cause the push server and everything else coming as a container only: Collabora, Rocket.Chat, …

Even the developer install comes nowadays as a container.

Ralf

Oooohhh… Nuts…

Thank you Ralf for the reply. It warms the heart to see how well you have done and how far egroupware has come in the past 15 or so years.

Containers raise problems for the attorney requirement to safeguarding client information. Not for the information, but for the attorney’s responsibility to validate how the information is being handled and served. Containers composed by others are essentially black-boxes.

A server install allows for review and validation of what is run when keeping things under my control. To use a container approach I could validate and defend in the event of any problem, I would essentially have to use docker to compose the container from my site to begin with. (not the mention the additional overhead a contianerized apache and MySQL requires in addition to the native apache and MySQL already running)

Is there no way to continue to run current egw outside of a container? I’m not worried about it being a bit harder to do, or taking a bit longer to setup, I just need to be able to verify how the information is being handled.

If the current egroupware cannot be run outside a contianer, what would be the latest version that I can run from a self-hosted server similar to what I do now?

Not, if the Dockerfile is published, as for the containers we provide:

The Dockerfile also shows what you need to do to install EGroupware directly on the host.

Problem is not to run EGroupware outside a container, but the knowledge to do so.

Ralf

Hi David.

Not necessarily.
The EGroupware containers essentially contain only the EGroupware sources and PHP.
You can enter the running container, then find yourself on the shell and can inspect it just as you do on your current system.

From:

docker exec -it egroupware bash
Enter the container egroupware.
Changes in the container are discarded by an update or recreation of the container!


Overall, a Docker installation brings many advantages. Especially for security and speed.
Especially important: We develop on certain versions of PHP, MariaDB (…) and deliver the containers in exactly the same way. Everything fits together, is secure and fast.
Collabora Online, Guacamole, Rocket.Chat, Push… All this is only possible on the basis of containers.

Here is something else to read:





Yes, first of all right. You need more resources.

But let’s be honest. Even a full installation is still very small and requires little RAM/CPU compared to other systems (Microsoft…).
It simply doesn’t work to meet increased demands with resources from 15 years ago.


I recommend you: Just install EGroupware with docker (old PC, small vServer, …) and take a look.

Stefan

2 years later

Fresh Install of 23.1

Well, I tried to nuke this post because it has 21.1 in the title and start a new thread, but I can’t find a new thread button, so I’ll reppost here, but this is related to 23.1.

Hello Stefan, Ralf, all,

I’ve not had time to mess with migration in a while. So I am looking at it again. I did a composer install of 23.1, it’s quite happy, but moving my data forward is probably futile. I did a fresh install of egw from git and added the legacy apps back git clone app ... Then I moved my database from my old server to new test box and made sure MariaDB was happy (it was).

So I pulled my old header.inc.php and pointed my browser to egroupware/setup. Presto, the admin login box appeared, logged in and chose the Upgrade option. (it correctly showed my tables as 1.8.007. I pressed go, it worked for a while and then got an error:

AlterColumnSQL('egw_ea_accounts','acc_folder_archive',Array ( [type] => varchar [precision] => 128 [comment] => archive folder ) ) sql=Array ( [0] => ALTER TABLE `egw_ea_accounts` ADD `acc_folder_archive` VARCHAR(128) )

Duplicate column name 'acc_folder_archive'

AlterColumnSQL('egw_ea_accounts','acc_folder_ham',Array ( [type] => varchar [precision] => 128 [comment] => ham folder ) ) sql=Array ( [0] => ALTER TABLE `egw_ea_accounts` ADD `acc_folder_ham` VARCHAR(128) )

Duplicate column name 'acc_folder_ham'

AlterColumnSQL('egw_ea_accounts','acc_spam_api',Array ( [type] => varchar [precision] => 128 [comment] => SpamTitan API URL ) ) sql=Array ( [0] => ALTER TABLE `egw_ea_accounts` ADD `acc_spam_api` VARCHAR(128) )

Duplicate column name 'acc_spam_api'

AlterColumnSQL('egw_addressbook','contact_files',Array ( [type] => int [precision] => 1 [default] => 0 [comment] => &1: photo, &2: pgp, &4: smime ) ) sql=Array ( [0] => ALTER TABLE `egw_addressbook` ADD `contact_files` TINYINT DEFAULT 0 )

Duplicate column name 'contact_files'
api/setup/tables_update.inc.php (278)
An error happened!

So back to setup and run it again with debug enable, it now recognizes my tables as 14.3.907, but it still runs into duplicate column issues:

process->pass(): #1 for upgrade processing
process->upgrade(): Incoming : appname: api, version: 14.3.907, status: U
process->upgrade(): api(14.3.907 --> 23.1.004): running api_upgrade14_3_907() --> 16.1
process->upgrade(): api(16.1 --> 23.1.004): running api_upgrade16_1()

AlterColumnSQL('egw_ea_accounts','acc_folder_archive',Array ( [type] => varchar [precision] => 128 [comment] => archive folder ) ) sql=Array ( [0] => ALTER TABLE `egw_ea_accounts` ADD `acc_folder_archive` VARCHAR(128) )

Duplicate column name 'acc_folder_archive'
--> 16.1.001
process->upgrade(): api(16.1.001 --> 23.1.004): running api_upgrade16_1_001() --> 16.1.002
process->upgrade(): api(16.1.002 --> 23.1.004): running api_upgrade16_1_002() --> 16.1.003
process->upgrade(): api(16.1.003 --> 23.1.004): running api_upgrade16_1_003() --> 16.1.004
process->upgrade(): api(16.1.004 --> 23.1.004): running api_upgrade16_1_004() --> 16.1.005
process->upgrade(): api(16.1.005 --> 23.1.004): running api_upgrade16_1_005() --> 16.9
process->upgrade(): api(16.9 --> 23.1.004): running api_upgrade16_9() --> 16.9.001
process->upgrade(): api(16.9.001 --> 23.1.004): running api_upgrade16_9_001()

AlterColumnSQL('egw_ea_accounts','acc_folder_ham',Array ( [type] => varchar [precision] => 128 [comment] => ham folder ) ) sql=Array ( [0] => ALTER TABLE `egw_ea_accounts` ADD `acc_folder_ham` VARCHAR(128) )

Duplicate column name 'acc_folder_ham'

AlterColumnSQL('egw_ea_accounts','acc_spam_api',Array ( [type] => varchar [precision] => 128 [comment] => SpamTitan API URL ) ) sql=Array ( [0] => ALTER TABLE `egw_ea_accounts` ADD `acc_spam_api` VARCHAR(128) )

Duplicate column name 'acc_spam_api'
--> 16.9.002
process->upgrade(): api(16.9.002 --> 23.1.004): running api_upgrade16_9_002()

AlterColumnSQL('egw_addressbook','contact_files',Array ( [type] => int [precision] => 1 [default] => 0 [comment] => &1: photo, &2: pgp, &4: smime ) ) sql=Array ( [0] => ALTER TABLE `egw_addressbook` ADD `contact_files` TINYINT DEFAULT 0 )

Duplicate column name 'contact_files'
api/setup/tables_update.inc.php (278)
An error happened!

fclose(): supplied resource is not a valid stream resource (0)

That doesn’t look that bad or dire. If I can fix this, GREAT!, If not, I’ll just nuke it, drop the database on this machine and start with a new install.

Is there any hope of finishing this database migration?

Oh, I forgot, MariaDB is quite happy with the current state of the database, it passes all checks, e.g.

$ mariadb-check -c egroupware
egroupware.egw_access_log                          OK
egroupware.egw_accounts                            OK
egroupware.egw_acl                                 OK
egroupware.egw_addressbook                         OK
egroupware.egw_addressbook2list                    OK
egroupware.egw_addressbook_extra                   OK
egroupware.egw_addressbook_lists                   OK
egroupware.egw_admin_queue                         OK
egroupware.egw_admin_remote                        OK
egroupware.egw_applications                        OK
egroupware.egw_async                               OK
egroupware.egw_bookmarks                           OK
egroupware.egw_cal                                 OK
egroupware.egw_cal_dates                           OK
egroupware.egw_cal_extra                           OK
egroupware.egw_cal_holidays                        OK
egroupware.egw_cal_repeats                         OK
egroupware.egw_cal_timezones                       OK
egroupware.egw_cal_user                            OK
egroupware.egw_categories                          OK
egroupware.egw_config                              OK
egroupware.egw_contentmap                          OK
egroupware.egw_customfields                        OK
egroupware.egw_ea_accounts                         OK
egroupware.egw_ea_credentials                      OK
egroupware.egw_ea_identities                       OK
egroupware.egw_ea_notifications                    OK
egroupware.egw_ea_valid                            OK
egroupware.egw_etemplate                           OK
egroupware.egw_history_log                         OK
egroupware.egw_importexport_definitions            OK
egroupware.egw_infolog                             OK
egroupware.egw_infolog_extra                       OK
egroupware.egw_kb_articles                         OK
egroupware.egw_kb_comment                          OK
egroupware.egw_kb_questions                        OK
egroupware.egw_kb_ratings                          OK
egroupware.egw_kb_related_art                      OK
egroupware.egw_kb_search                           OK
egroupware.egw_kb_urls                             OK
egroupware.egw_lang                                OK
egroupware.egw_languages                           OK
egroupware.egw_links                               OK
egroupware.egw_locks                               OK
egroupware.egw_mailaccounts                        OK
egroupware.egw_news                                OK
egroupware.egw_news_export                         OK
egroupware.egw_notificationpopup                   OK
egroupware.egw_pm_constraints                      OK
egroupware.egw_pm_elements                         OK
egroupware.egw_pm_extra                            OK
egroupware.egw_pm_members                          OK
egroupware.egw_pm_milestones                       OK
egroupware.egw_pm_pricelist                        OK
egroupware.egw_pm_prices                           OK
egroupware.egw_pm_projects                         OK
egroupware.egw_pm_roles                            OK
egroupware.egw_polls                               OK
egroupware.egw_polls_answers                       OK
egroupware.egw_polls_votes                         OK
egroupware.egw_preferences                         OK
egroupware.egw_reg_accounts                        OK
egroupware.egw_reg_fields                          OK
egroupware.egw_resources                           OK
egroupware.egw_resources_extra                     OK
egroupware.egw_sharing                             OK
egroupware.egw_sitemgr_active_modules              OK
egroupware.egw_sitemgr_blocks                      OK
egroupware.egw_sitemgr_blocks_lang                 OK
egroupware.egw_sitemgr_categories_lang             OK
egroupware.egw_sitemgr_categories_state            OK
egroupware.egw_sitemgr_content                     OK
egroupware.egw_sitemgr_content_lang                OK
egroupware.egw_sitemgr_modules                     OK
egroupware.egw_sitemgr_notifications               OK
egroupware.egw_sitemgr_notify_messages             OK
egroupware.egw_sitemgr_pages                       OK
egroupware.egw_sitemgr_pages_lang                  OK
egroupware.egw_sitemgr_properties                  OK
egroupware.egw_sitemgr_sites                       OK
egroupware.egw_sqlfs                               OK
egroupware.egw_sqlfs_props                         OK
egroupware.egw_syncmldeviceowner                   OK
egroupware.egw_syncmldevinfo                       OK
egroupware.egw_syncmlsummary                       OK
egroupware.egw_timesheet                           OK
egroupware.egw_timesheet_extra                     OK
egroupware.egw_tracker                             OK
egroupware.egw_tracker_assignee                    OK
egroupware.egw_tracker_bounties                    OK
egroupware.egw_tracker_escalated                   OK
egroupware.egw_tracker_escalations                 OK
egroupware.egw_tracker_extra                       OK
egroupware.egw_tracker_replies                     OK
egroupware.egw_tracker_votes                       OK
egroupware.egw_wiki_interwiki                      OK
egroupware.egw_wiki_links                          OK
egroupware.egw_wiki_pages                          OK
egroupware.egw_wiki_rate                           OK
egroupware.egw_wiki_remote_pages                   OK
egroupware.egw_wiki_sisterwiki                     OK
egroupware.phpgw_mydms_ACLs                        OK
egroupware.phpgw_mydms_DocumentContent             OK
egroupware.phpgw_mydms_DocumentLinks               OK
egroupware.phpgw_mydms_Documents                   OK
egroupware.phpgw_mydms_Folders                     OK
egroupware.phpgw_mydms_GroupMembers                OK
egroupware.phpgw_mydms_Groups                      OK
egroupware.phpgw_mydms_KeywordCategories           OK
egroupware.phpgw_mydms_Keywords                    OK
egroupware.phpgw_mydms_Notify                      OK
egroupware.phpgw_mydms_Sessions                    OK
egroupware.phpgw_mydms_UserImages                  OK
egroupware.phpgw_mydms_Users                       OK

Let me know, and let me know if I can send anything else. If you can point me in the right direction, I don’t even mind trying to fix the code where this is occurring. If we get it working, then you have a good tool for 1.8 -> 23 migration.

Follow-up - all of the columns it complains are duplicates – are indeed added with the correct data type in the tables, e.g.

MariaDB [egroupware]> describe egw_ea_accounts;
...
| acc_folder_archive     | varchar(128) | YES  |     | NULL                |                               |
| acc_folder_ham         | varchar(128) | YES  |     | NULL                |                               |
| acc_spam_api           | varchar(128) | YES  |     | NULL                |                               |
| acc_further_identities | tinyint(4)   | NO   |     | 1                   |                               |

and

MariaDB [egroupware]> describe egw_addressbook;
...
| contact_files        | tinyint(4)     | YES  |     | 0       |                |

One thought I had was just dropping the columns it thinks are duplicates and trying again?? What do you think of that approach?

I tried it, and I think it worked, but the fclose() error seems to be a problem. After removing the duplicate columns and re-running the database update with debug output enable, the following was all I received:

Backup started, this might take a few minutes ...

Backup finished.

process->pass(): #1 for upgrade processing
process->upgrade(): Incoming : appname: api, version: 14.3.907, status: U
process->upgrade(): api(14.3.907 --> 23.1.004): running api_upgrade14_3_907() --> 16.1
process->upgrade(): api(16.1 --> 23.1.004): running api_upgrade16_1() --> 16.1.001
process->upgrade(): api(16.1.001 --> 23.1.004): running api_upgrade16_1_001() --> 16.1.002
process->upgrade(): api(16.1.002 --> 23.1.004): running api_upgrade16_1_002() --> 16.1.003
process->upgrade(): api(16.1.003 --> 23.1.004): running api_upgrade16_1_003() --> 16.1.004
process->upgrade(): api(16.1.004 --> 23.1.004): running api_upgrade16_1_004() --> 16.1.005
process->upgrade(): api(16.1.005 --> 23.1.004): running api_upgrade16_1_005() --> 16.9
process->upgrade(): api(16.9 --> 23.1.004): running api_upgrade16_9() --> 16.9.001
process->upgrade(): api(16.9.001 --> 23.1.004): running api_upgrade16_9_001() --> 16.9.002
process->upgrade(): api(16.9.002 --> 23.1.004): running api_upgrade16_9_002() api/setup/tables_update.inc.php (278)
An error happened!

fclose(): supplied resource is not a valid stream resource (0)

The fclose() seems to be throwing an error. Any idea how to fix that as well.

This does indeed look like a bug in the egw conversion routine. I dug into it further and the erroneous fclose() is triggered in api/setup/tables_update.inc.php on line 278 inside the following if (..) block in function api_upgrade16_9_002():

                        if ($row['contact_jpegphoto'] && ($fp = Api\Vfs::string_stream($row['contact_jpegphoto'])))

That if (..) should never be entered during the conversion of my data because there are no contact_jpegphoto entries that are not NULL, e.g. from the 1.8.007 box:

MariaDB [egroupware]> select contact_id, n_family from egw_addressbook where contact_jpegphoto != NULL;
Empty set (0.002 sec)

The first condition $row['contact_jpegphoto'] should never be true and that block should never be entered, but somewhere in the earlier conversion from 1.8.007 -> 16.9.002 something must be added in the contact_jpegphoto field that is causing it to evaluate true?? That causes the $fp = Api\Vfs::string_stream($row['contact_jpegphoto']) to execute and then fclose($fp); is called unconditionally – even though $fp would be invalid due to trying to string_stream(NULL) or similar. I’ll have to install the backup of the database saved in that state and see if there is anything add in the contact_jpegphoto in the upgrade process to that point. This seems like an easy fix. Hell, I could just comment out the if (..) block for my data and see what happens.

Saved backup and database in this state and then dropped all apps and completed /setup. Kudos, the interface looks good, though I really miss idots:slight_smile: The dark-mode background is a bit to glossy black and provides a harsh contrast with the text. In my old age, I’ve gotten to where I prefer a softer dark background like #18191d or similar (which is still really dark, but eliminate the harsh black/white contrast)

Data is king though. There is no way I can live without 20 years of egroupware data in my 1.8.007 install. Do you have any SQL map that I could manually use to map the 1.8.007 data into the new 23.1 schema?

Also, the composer install worked fine. It has a few quirks and left the vendor/npm-asset/... permissions a bit wonky and a few others needed manual intervention, but on balance, this works great (and reasonably fast on a dual-core Celeron box with 4G of RAM with egw and nextcloud both running! No containers! And egroupware is running circles around nextcloud. Rather than throwing the Composer install out, it is a great asset for egroupware and work keeping. Just needs a little TLC.

Worst case, I’ll just loop over the tables and dump both the 1.8.007 and 23.1 table descriptions from bash and then build a set of insert queries to go from one to the other. I’m really oping you have a map of some kind so I don’t end up reinventing the wheel (which I unfortunately do from time to time)

Let me know on the rest, and good work on 23.1!