Git pull removed .png files now images in egroupware are gone?

Oh Wow!

That made a huge difference! All the icons are back and the QuickAdd drop-down no longer covers the headings on the next row. Man, oh man, was I ever scratching my head wondering how I managed to break the install. Changing branches and running ./install-cli.php 23.1 pulled in 42 updates and 3 new packages.

Logging in all looks really good. Thank you Ralf!

Yes, I’ve tried really hard to make the docker install work, but it just doesn’t want to play nice on Archlinux. I’ve made several full runs at the docker install and every time something goes awry.

One of these days I’ll make it work. I may have to load another OS that doesn’t live on the bleeding-edge of current upstream packages. You would think for a docker install it wouldn’t matter, but for some reason it does.

I’m just thrilled to have been able to migrate nearly 20 years of data forward from 1.8.009 and have it up and running. It has been a journey, but an enjoyable one.

Now to go check out all the new toys that were pulled in :)

Ralf,

I did run into a strange issue later after changing to the “23.1” branch. rocketchat and smallpart were listed as needing update. Running ./setup/setup-cli.php --update now gives an error Setup failure: excess looping in process->pass(): The output (with password removed) is:

./setup/setup-cli.php --update
PHP Deprecated:  explode(): Passing null to parameter #2 ($string) of type string is deprecated in /srv/http/htdocs/egroupware/setup/setup-cli.php on line 278
Admin password to header manager xxxxxxxxxxxxxx
EGroupware API version 23.1.009 found.
EGroupware configuration file (header.inc.php) version 1.29 exists and is up to date
PHP Deprecated:  Creation of dynamic property ADODB2_mysql::$upperName is deprecated in /srv/http/htdocs/egroupware/vendor/egroupware/adodb-php/adodb.inc.php on line 5098
PHP Deprecated:  Creation of dynamic property ADODB2_mysql::$quote is deprecated in /srv/http/htdocs/egroupware/vendor/egroupware/adodb-php/adodb.inc.php on line 5099
Backup started, this might take a few minutes ...
Backup finished.
PHP Deprecated:  Creation of dynamic property ADODB2_mysql::$upperName is deprecated in /srv/http/htdocs/egroupware/vendor/egroupware/adodb-php/adodb.inc.php on line 5098
PHP Deprecated:  Creation of dynamic property ADODB2_mysql::$quote is deprecated in /srv/http/htdocs/egroupware/vendor/egroupware/adodb-php/adodb.inc.php on line 5099
<br>Setup failure: excess looping in process->pass():
<br>Pass:<br>
<pre>Array
(
)
</pre>
<br>Passed:<br>
<pre>Array
(
)
</pre>

I don’t know if I did something wrong or if the deprecated warnings are expected.

Also not sure if looping error is related, but the Mail app is on the fritz and just freezes when I try and open it, (the Mail log error mentions the same Array as above) The egw_mailaccounts table is empty, but attempting to open Mail may be attempting setup on the mail-host with my login, and it keeps triggering a firewall ban on the mail server against the egroupware box IP

That’s not a big deal, I’m more concerned if I need to do anything to fix the setup-cli.php looping issue. I suspect they are related as I do get an error in the log related to Horde Mail and then a 19 entry traceback of the failure. The starting point for the error is in call_user_func_array(Array) which seems to match the setup-cli.php looping Array? The first three entries in the error_log are:

[Mon Oct 21 10:21:41.157258 2024] [php:notice] [pid 371077:tid 371077] [client 192.168.6.104:47586] EGroupware\\Api\\Mail\\Imap::hasCapability952 (examineServer for detection) SUPPORTS_KEYWORDS->NULL failed EGroupware\\Api\\Mail\\Imap->hasCapability:952 / mail_ui->get_actions:1429 / mail_ui->index:492 / EGroupware\\Api\\Framework\\Ajax::ajax_exec:1153 / call_user_func_array(Array) / EGroupware\\Api\\Json\\Request->handleRequest:205 / EGroupware\\Api\\Json\\Request->parseRequest:106, referer: https://2pi.3111skyline.com/egroupware/index.php?cd=yes
[Mon Oct 21 10:25:13.312907 2024] [php:notice] [pid 371077:tid 371077] [client 192.168.6.104:47586] An error happened! (Error): Attempt to assign property "client_debug" on null (0), referer: https://2pi.3111skyline.com/egroupware/index.php?cd=yes
[Mon Oct 21 10:25:13.312953 2024] [php:notice] [pid 371077:tid 371077] [client 192.168.6.104:47586] File: /vendor/egroupware/imap-client/lib/Horde/Imap/Client/Socket.php, Line: 4386, referer: https://2pi.3111skyline.com/egroupware/index.php?cd=yes

I have the next #0 - #18 traceback lines saved if you want them, but wasn’t sure it was a cause or result of the setup looping. If you want to see the those log lines, just let me know and I’m happy to post it.

The Mail issue is not a pressing issue for my use as I don’t use Mail in egroupware - but I do need to find and fix whatever is trying to access the mail server resulting in fail2ban banning the egroupware box IP. For now I can just avoid opening Mail and I think that will take care of it.

Your crystal ball is working mighty good. Not Completed smallpart-Version Mismatch - V needed updating. All apps updated in egroupware/setup web interface, but we still have the excess looping:

...
<br>Setup failure: excess looping in process->pass():
<br>Pass:<br>
<pre>Array
(
)
</pre>
<br>Passed:<br>
<pre>Array
(
)
</pre>

I also don’t have rocketchat installed in the egroupware/setup apps selection – if that could be an issue?

Now we may be getting somewhere. I’ve never used SmallPART/ViDoTeach, so I used setup to uninstall which said it “dropped tables”.

But… when I then used “go back” and chose [x] install, it threw warnings that the tables exist:

App install/remove/upgrade:

CreateTableSQL('egw_smallpart_livefeedback','lf_id I AUTOINCREMENT NOTNULL PRIMARY, course_id I4 NOTNULL, video_id I4 NOTNULL, session_created T, session_starttime T, session_endtime T, session_interval I4') sql=Array ( [0] => CREATE TABLE `egw_smallpart_livefeedback` ( `lf_id` INTEGER NOT NULL AUTO_INCREMENT, `course_id` INTEGER NOT NULL, `video_id` INTEGER NOT NULL, `session_created` DATETIME, `session_starttime` DATETIME, `session_endtime` DATETIME, `session_interval` INTEGER, PRIMARY KEY (`lf_id`) )CHARACTER SET utf8 )

Table 'egw_smallpart_livefeedback' already exists

CreateTableSQL('egw_smallpart_categories','cat_id I AUTOINCREMENT NOTNULL PRIMARY, course_id I4 NOTNULL, parent_id I4, cat_name C(256), cat_description C(256), cat_color C(7), cat_data C(16384)') sql=Array ( [0] => CREATE TABLE `egw_smallpart_categories` ( `cat_id` INTEGER NOT NULL AUTO_INCREMENT, `course_id` INTEGER NOT NULL, `parent_id` INTEGER, `cat_name` VARCHAR(256), `cat_description` VARCHAR(256), `cat_color` VARCHAR(7), `cat_data` VARCHAR(16384), PRIMARY KEY (`cat_id`) )CHARACTER SET utf8 )

Table 'egw_smallpart_categories' already exists

smallPART Tables installed, unless there are errors printed above..

This may be as expected, but I thought I would confirm.

The looping error is Gone!. Your crystal ball is still batting 1000!

Thank you Ralf!

Thanks Stefan,

That will likely be what I do. I’ve run Arch servers since 2009, and while you wouldn’t think a rolling-release makes a good server base – it solves one of the biggest issues with server management – your package versions are always current with upstream and you are never exposed to bugs in old versions. Over the 15 years I’ve run Arch servers, and up until 18 months ago, I would remote-admin the boxes from home, there were only two occasions where I had to scramble. One the Apache 2.2 - 2.4 update (that just took learning the new access framework) and around 2015 there was an openssh update that took ssh out with on-site configurations needed (not a great inconvenience with the office and home only 2 miles apart) Arch has been so stable during the past 9 years or so, there hasn’t ever been a repeat that required a physical trip to the office.

But here where outside systems are put together to run on top of the base server packages like docker, composer, npm, etcc… those systems are generally put together expecting files and directory location to be where they are on the systems they are built on. Arch using the webhost setup with packages hosted from /usr/share/webapps while also allowing user-sites in the traditional /srv/http does complicate configuration for PHP, etc… to securely handle the dual-zones of webapps.

I’ve run Debian on the Pi boxes since jesse and now have 4 boxes running bullseye, both 32-bit and 64-bit and they work fine. I’ve got openSUSE and Ubuntu boxes as well. Linux is just Linux, how the distros package it and where they choose to hide the internals is the only difference, Even VMware is just Linux under the hood.

But where Debian stands out is its reasonably long term support for a given release. The openSUSE release models running 18-24 month release cycles require far too frequent fresh-installs and always need them at the worse possible time during the calendar year. So I’m happy with Debian, so the next server I build I’ll use it and be able to use the containerized version of eGroupware (and as time permits, I’ll figure out hot to make it work on Arch too :)