Apr 2024
24 / 24
May 2024
May 2024
itwo
Apr '24
RalfBecker

Er möchte den Patch auf der aktuellen 23.1.2040304 nicht anwenden:

root@egw:~# curl https://github.com/EGroupware/egroupware/commit/54e5365e0b94bae00d22111c39c7113c65f0c661.patch | docker exec -i egroupware patch -p1 -d /usr/share/egroupware-sources
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2720 100 2720 0 0 9329 0 --:–:-- --:–:-- --:–:-- 9347
patching file notifications/inc/class.notifications_email.inc.php
Hunk #2 FAILED at 78.
1 out of 3 hunks FAILED – saving rejects to file notifications/inc/class.notifications_email.inc.php.rej

itwo
Apr '24

Irgendwie steckt da etwas der Wurm drin, ist der diff zu groß?

root@egw:~# curl https://github.com/EGroupware/egroupware/commit/018083dc0e8a68e53fcc0aa5b8fea7f79cad5296.patch | docker exec -i egroupware patch -p1 -d /usr/share/egroupware-sources
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2480 100 2480 0 0 9937 0 --:–:-- --:–:-- --:–:-- 9959
patching file api/src/Storage/Tracking.php
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored – saving rejects to file api/src/Storage/Tracking.php.rej
patching file notifications/inc/class.notifications_email.inc.php
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored – saving rejects to file notifications/inc/class.notifications_email.inc.php.rej
patching file notifications/inc/class.notifications_popup.inc.php
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored – saving rejects to file notifications/inc/class.notifications_popup.inc.php.rej

RalfBeckerEGroupware GmbH
Apr '24

Vermutlich ist es einfacher das ganze notifications/inc/class.notifications_email.inc.php File in den Container zu kopieren, statt zu patchen:

curl https://raw.githubusercontent.com/EGroupware/egroupware/23.1/notifications/inc/class.notifications_email.inc.php > /tmp/class.notifications_email.inc.php
docker cp /tmp/class.notifications.inc.php egroupware:/usr/share/egroupware/notifications/inc/
docker exec egroupware kill -s usr2 1

Nach restart des Containers oder Reboot der Kiste, ist das wie der Patch wieder draußen, damit es restart-fest wird musst Du bei dem docker cp /usr/share/egroupware mit /usr/share/egroupware-sources ersetzen.

Ralf

itwo
Apr '24

So zu sagen ein patch force :smile:

@StefanU kannst Du mir nochmal eine Einladung zum testen schicken?

RalfBeckerEGroupware GmbH
Apr '24

Noch mal ganz auf Anfang: Du hast doch in der App Config das “noreply@…” SMPT Konto für Benachrichtigungen ausgewählt.

Du solltest das auf “automatisch” lassen.

Falls Du “automatisch” nicht auswählen kannst, führe mal das folgende SQL aus:

DELETE FROM egw_config WHERE config_name='async_identity' and config_app='notifications'

Danach musst Du den Cache löschen, und die App Konfiguration der Benachrichtigungen nicht mehr speichern. Da ist ein Typo in dem XML File, das dafür sorgt, dass “automatisch” nicht auswählbar ist:

Ralf

itwo
Apr '24

“automatisch” konnte ich nicht auswählen, hab daher den Key in der DB gelöscht und den Cache geleert:

MariaDB [egroupware]> SELECT * FROM egw_config WHERE config_name='async_identity' and config_app='notifications';
Empty set (0.000 sec)

In der WebGUI steht noch das noreply@ Konto, deshalb nicht mehr speichern vermute ich.

Ursprünglich ist es so zu dem noreply@ Konto gekommen:

itwo
Apr '24

Genau das war das Problem, vielen Dank @RalfBecker.
Das ganze Problem ist damals mit dem “‘1’ist NICHT erlaubt (‘)!” entstanden.

Danke @StefanU für die vielen Testeinladungen!

itwo
Apr '24

Leider entsteht daraus ein neues Problem, EGw bringt eine rote Meldung sobald ein Alarm für den Kalendereintrag verschickt werden soll:

Fehler beim Benachrichtigen von user user@example.com
Alarm for TESTTERMIN at 19.04.2024, 11:20 in
notifications_popup failed: , notifications_email failed: Server is not accepting SMTP connections.

In der Mailserver Log sieht man das EGw nicht meinen SMTP Benutzer verwendet, sondern die EMail einfach so beim Mailserver abliefern möchte -> Client host rejected: Access denied

@RalfBecker könnte das mit dem Patch zusammen hängen?
Ist das ggf. ein Bug der daraus entsteht?

Edit: User und EMailadresse stimmen und wurden hier nur maskiert.

RalfBeckerEGroupware GmbH
Apr '24

Kannst Du doch einfach mal ausprobieren:

cd /etc/egroupware-docker
docker-compose up -d --force-recreate

Danach sind alle Patches weg, aber die in der DB gelöschte Zeile sorgt immer noch dafür, das due “automatisch” verwendest.

Ralf

itwo
Apr '24

Ich würde das gerne probieren, damit verliere ich auch einige Patches mit den PDFs Body only Mails und so langsam habe ich den Überblick verloren wann ich was gepatched habe.

Vielleicht ist es besser wenn ich als erstes das nächste Release abwarte und dann das ganze Thema noch einmal untersuche.

itwo
Apr '24
RalfBecker

Ich hab das heute probiert, hat nichts geändert, die Fehlermeldung kommt trotzdem.

Kann mich also nur zwischen richtigen Terminantworten ODER Terminbenachrichtigungen entscheiden. :confused:

19 days later
itwo
May '24

@RalfBecker
"automatic" kann ich inzwischen wieder auswählen 23.1.20240430, aber das versenden von Kalender Erinnerungen an sich selber scheitert nach wie vor.

EGw versucht sich nicht mit dem SMTP Benutzer zu authentifizieren sondern möchte die Mail einfach so abliefern, was der Mailserver ablehnt.

RalfBeckerEGroupware GmbH
May '24

Hmm, das kann ich so nicht nachvollziehen.

In der Auswahl, bzw durch die Automatic wird ein verfügbares Mail-Konto ausgewählt.

Wenn das Mail-Konto Authentifizierung eingetragen hat, wird die an den Mailserver geschickt.

Kann mir da nur vorstellen, das die Automatic ein Mail-Konto auswählt, das keine Authentifizierung hat.

Ralf

itwo
May '24

Du meinst das ein Rest in der DB hängt?
Meine Konten können alle nur via SMTP Auth verschicken, wenn mein Konto nicht gehen würde wäre das schon aufgefallen.

Könnte es ein Problem sein das mein Auth Benutzer ohne Domain ist:
Konto Postausgangs-Server Benutzername “user”?

Was mich aber wundert, darüber steht: “Authentifizierung Verwendet Benutzername+Passwort des angemeldeten Benutzers”.