Update form Open SuSE 15.5 to 15.6

WalterH · 2025-03-16T08:53:32+00:00

Andy Wäre das vielleicht ein sicherer Weg?

Damit hast Du aber schon ca. 1/3 meiner Anleitung abgearbeitet.

Andy · 2025-03-16T10:23:33+00:00

Andy Bei dieser Art von Umstellung bin ich irgendwann aussen vor ....... Welche wichtigen Unterschiede in Schritt 19 erscheinen können, ist unklar, bei Schritt 20 breche ich ab, da der Vorgang für mich nicht prozeßsicher funktioniert. Mit Schritt 21 geht es im Prinzip so weiter

Es ist das, was ich auch in den vorigen Posts meinte, spätest ab diesen Schritten ist detaillierteres Know-How erforderlich, was mir jetzt zB. fehlt. Mir wäre es deshalb am liebsten, wenn es mit diesem "1/3" und vlt. noch ein paar eindeutigen Zusatzschritten auch reichen würde.

crpb · 2025-03-16T13:02:50+00:00

Ich wünsch mir auch manchmal sachen die einfach nicht wahr werden wollen *duck*

Andy · 2025-03-16T13:55:53+00:00

Mit wünschen hat das nichts zu tun.

Einfaches Bsp. Schritt 19 "....find missing packages but if you do, reinstall them as follow...", nach was soll ich suchen? Schritt 20 erfordert Detailwissen, Schritt 21 ebenso ... welche kann ich löschen und welche darf ich nicht löschen.

Usw. Ich warte eben besser, bis es wieder eine funktionierende Appliance gibt.

Cchats · 2025-03-16T18:13:52+00:00

Ich habe das Update nach der Anleitung hier manuell durchgeführt. Das hat auch funktioniert.
Hatte mich nur gewundert warum das Script nicht das macht wie beschrieben.
@Andy Eine funktionierende Appliance würde aber doch am Upgradeprozess nicht ändern, oder?
Denn wenn ich das richtig verstehe muss eine funktionierende Appliance komplett neu installiert werden.
Und wie sieht es denn da mit den Konfigurationen, Daten und vor allem Datenbankversionen aus?
Und des weiteren wie oft muss das Upgrade eigentlich überhaupt gemacht werden?

Andy · 2025-03-16T20:29:49+00:00

Ich unterstelle, dass in einer neuen Appliance alles korrekt hinterlegt ist. Da gibt es keine Schritte 19 und 20, wo beurteilt werden muss, was richtig oder falsch ist, ich für meinen Teil kann das jedenfalls nicht.

Dagegen, wenn Du eine Appliance neu installierst und überträgt nur Deine Nutzdaten und Datenbanken, ist das für mich sicherer, da es dafür einen klaren Weg gibt. Ich habe das bislang bei wesentlichen Veränderungen gemacht, zB. auch, als Leap 154 auf 155 angehoben wurde.

WalterH · 2025-03-17T06:52:39+00:00

Andy Schritte 19 und 20,

19 ist eine Sicherheitsprüfung ob alle Dienste, nach dem Update auch wieder vorhanden sind.
20 migriert die Konfigurationsdateien. Da sind normalerweise Anpassungen die der Admin gemacht hat und die nun möglicherweise nicht mehr zu den neuen Programm Versionen passen, Auch Neuerungen an den Konfig Dateien, die ins neue System übertragen werden sollen.

Andy · 2025-03-17T07:31:56+00:00

Einfach gesagt, könnte der Schritt 20 so gesehen dann übersprungen werden, wenn vorher im System keine Anpassungen erfolgten und das installierte System einer Defaultinstallation entsprechen würde.

Andy · 2025-03-18T06:34:13+00:00

Ich habe an einer Test-VM die Migration durchgeführt und die Configs, die ich für die Abholung und den Versand von Emails kenne, dazu zählen insbesondere

/etc/sysconfig/fetchmail
FETCHMAIL_POLLING_INTERVAL="180"
FETCHMAIL_FETCHALL="no"

/etc/postfix/main.cf
#relayhost
relayhost = 192.xxx.xxx.xxx:587 (Synology Mailserver Plus)

# SASL stuff
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = lmdb:/etc/postfix/sasl_passwd
smtp_use_tls = yes
# smtp_tls_security_level=yes # Verschlüsselung
#mynetworks
mynetworks = 192.xxx.xxx.0/24, 127.0.0.0/8 [::1]/128

/etc/postfix/sasl_passwd
# your smtp.com
# [smtp.yoursmt.server]:587 user:password

/etc/php8/cli/php.ini
memory_limit = 1024M

sind alle erhalten geblieben. Dennoch funktioniert jetzt im Gegensatz zu vorher der Versand nicht mehr, es erscheint die Meldung

<xxx.xxx@gmail.com>: host 192.xxx.xxx.xxx[192.xxx.xxx.xxx] said: 553 5.7.1
    <xxx.xxx@xxxxx.de>: Sender address rejected: not owned by user
    xxxxx (in reply to RCPT TO command)

Wo ist da ggf. noch anzupassen?

WalterH · 2025-03-18T18:32:21+00:00

Andy Sieht für mich nach einer andern Public IP des upgedateten Servers aus, die GMail nicht kennt.
Was sagt der Postfix beim Versenden für meldungen?

Cchats · 2025-03-18T18:45:05+00:00

Nur als Info: Ich kann derzeit keine einzige GMAIL Adresse anschreiben. Alle Tests kommen zurück.

Andy · 2025-03-18T19:56:11+00:00

Vielleicht muss ich dazusagen, dass Grommunio die Email über eine Synology DS und dessen MailPlus Server empfängt und auch versendet, daher die 192.xxx in der IP.

Aber weshalb geht das alles mit meiner aktuellen Grommunio-VM mit Leap 155, die ich vor fast 2 Jahren installiert habe und jetzt nach der Umstellung auf Leap 156 nicht mehr? Da muss ja irgendwo im System etwas verändert worden sein.

Betreffend Gmail habe ich ansonsten kein Thema, zumal das so oder so die DS erledigt.

WalterH · 2025-03-19T09:50:26+00:00

Andy Jammern hilft nicht, eine Antwort auf die oben gestellte Frage ist hilfreicher: Was sagt der Postfix beim Versenden für Meldungen? journalctl -f

Andy · 2025-03-21T23:50:05+00:00

Im Moment des Versandes erscheint folgendes, wobei das Resultat mit einer oder mehreren Emailadressen, wie nun hier, dasselbe ist:

Mär 22 00:40:35 localhost postfix/pickup[2531]: 485A06BE784: uid=479 from=<gro-user@domain.dl>
Mär 22 00:40:35 localhost postfix/cleanup[3845]: 485A06BE784: message-id=<gxZS._CLCmXjfWU-kiJEfLGO-QA@s7ayuBXFpUa1wMP35uwsFWBKcNOP7rBApS53dmhmKRw.xz>
Mär 22 00:40:35 localhost postfix/qmgr[2532]: 485A06BE784: from=<gro-user@domain.dl>, size=11617, nrcpt=7 (queue active)
Mär 22 00:40:35 localhost piler-smtp[1918]: connected from 127.0.0.1:44132 on fd=6 (active connections: 1)
Mär 22 00:40:35 localhost delivery-queue[2175]: remote=[::1] from=<gro-user@domain.dl> to={gro-user@domain.dl} return OK, queue-id:7
Mär 22 00:40:35 localhost postfix/smtp[3963]: 485A06BE784: to=<gro-user@domain.dl>, relay=::1[::1]:24, delay=0.02, delays=0.02/0/0/0, dsn=2.0.0, status=sent (250 Ok queue-id: 7)
Mär 22 00:40:35 localhost postfix/smtp[3846]: 485A06BE784: to=<email@gmail.com>, relay=relayserver[relayserver]:587, delay=0.05, delays=0.02/0/0.03/0.01, dsn=5.7.1, status=bounced (host relayserver[relayserver] said: 553 5.7.1 <gro-user@domain.dl>: Sender address rejected: not owned by user relayuser (in reply to RCPT TO command))
Mär 22 00:40:35 localhost postfix/smtp[3846]: 485A06BE784: to=<email@gmail.com>, relay=relayserver[relayserver]:587, delay=0.06, delays=0.02/0/0.03/0.01, dsn=5.7.1, status=bounced (host relayserver[relayserver] said: 553 5.7.1 <gro-user@domain.dl>: Sender address rejected: not owned by user relayuser (in reply to RCPT TO command))
Mär 22 00:40:35 localhost postfix/smtp[3846]: 485A06BE784: to=<email@outlook.de>, relay=relayserver[relayserver]:587, delay=0.06, delays=0.02/0/0.03/0.01, dsn=5.7.1, status=bounced (host relayserver[relayserver] said: 553 5.7.1 <gro-user@domain.dl>: Sender address rejected: not owned by user relayuser (in reply to RCPT TO command))
Mär 22 00:40:35 localhost postfix/smtp[3846]: 485A06BE784: to=<email@t-online.de>, relay=relayserver[relayserver]:587, delay=0.06, delays=0.02/0/0.03/0.02, dsn=5.7.1, status=bounced (host relayserver[relayserver] said: 553 5.7.1 <gro-user@domain.dl>: Sender address rejected: not owned by user relayuser (in reply to RCPT TO command))
Mär 22 00:40:35 localhost postfix/smtp[3846]: 485A06BE784: to=<email@t-online.de>, relay=relayserver[relayserver]:587, delay=0.07, delays=0.02/0/0.03/0.02, dsn=5.7.1, status=bounced (host relayserver[relayserver] said: 553 5.7.1 <gro-user@domain.dl>: Sender address rejected: not owned by user relayuser (in reply to RCPT TO command))
Mär 22 00:40:35 localhost piler-smtp[1918]: received: F9DWY90N8N6TDG4P, from=gro-user@domain.dl, size=11613, client=127.0.0.1, fd=6, fsync=10215
Mär 22 00:40:35 localhost piler-smtp[1918]: disconnected from 127.0.0.1 on fd=6, slot=0, reason=done (0 active connections)
Mär 22 00:40:35 localhost postfix/smtp[3847]: 485A06BE784: to=<archive@grommunio.subdomain.dl>, relay=127.0.0.1[127.0.0.1]:2693, delay=0.08, delays=0.02/0/0/0.06, dsn=2.0.0, status=sent (250 OK <F9DWY90N8N6TDG4P>)
Mär 22 00:40:35 localhost postfix/cleanup[3845]: 5A5086BE789: message-id=<20250321234035.5A5086BE789@grommunio.subdomain.dl>
Mär 22 00:40:35 localhost postfix/bounce[3964]: 485A06BE784: sender non-delivery notification: 5A5086BE789
Mär 22 00:40:35 localhost postfix/qmgr[2532]: 5A5086BE789: from=<>, size=15746, nrcpt=1 (queue active)
Mär 22 00:40:35 localhost postfix/qmgr[2532]: 485A06BE784: removed
Mär 22 00:40:35 localhost delivery-queue[2175]: remote=[::1] from=<no.envelope.from@invalid> to={gro-user@domain.dl} return OK, queue-id:8
Mär 22 00:40:35 localhost postfix/smtp[3963]: 5A5086BE789: to=<gro-user@domain.dl>, relay=::1[::1]:24, delay=0.01, delays=0/0/0/0, dsn=2.0.0, status=sent (250 Ok queue-id: 8)
Mär 22 00:40:35 localhost postfix/qmgr[2532]: 5A5086BE789: removed
Mär 22 00:40:35 localhost piler[1932]: 0/F9DWY90N8N6TDG4P: 5000000067ddf8fd2880c834004fcb9d4fea, size=11613/2768, attachments=0, reference=<1a03a609-5357-4af0-b026-185879b7fa51@domain.dl>, message-id=<gxZS._CLCmXjfWU-kiJEfLGO-QA@s7ayuBXFpUa1wMP35uwsFWBKcNOP7rBApS53dmhmKRw.xz>, retention=2557, folder=0, delay=0.0359, status=stored

WalterH · 2025-03-22T09:20:40+00:00

Andy 553 5.7.1 gro-user@domain.dl: Sender address rejected: not owned by user relayuser

Der Relayhost meint, das der relayuser nicht der Eigentümer des Users gro-user@domain.dl und daher nicht als dieser senden darf. Das hat aber mit grommunio nichts zu tun.

Andy · 2025-03-22T10:14:49+00:00

Das habe ich auch gesehen, jedoch kann ich mir das nicht erklären. Der Vorgang ist so eingerichtet, dass der Grommuniouser über den Relayserver Emails versendet mit zugehörigen Zugangsdaten, die in der sasl_passwd hinterlegt sind, also den Zugangsdaten des Relayusers.

Die Frage ist, weshalb das nach dieser obigen Umstellung nicht mehr geht, wenn das bislang und jahrelang iO. war.

Wo oder in welcher Datei kann der Relay noch stehen, ausser den Angaben in der main.cfg und sasl_passwd? Vielleicht ist da noch etwas verändert worden?

WalterH · 2025-03-22T10:45:03+00:00

Möglicherweise war ein SASL Login konfiguriert und das funktioniert möglicherweise nicht mehr. Das muss man aber suchen.

Andy · 2025-03-22T11:13:23+00:00

Das steht ja in der sasl_passwd, aber der Eintrag ist iO. und wie gehabt.

WalterH · 2025-03-22T11:14:20+00:00

SASL logging einschalten und klären ob die Gegenstelle das Login auch akzeptiert.

Andy · 2025-03-22T11:16:08+00:00

Dort, wo beim Setup die Domaindaten 1+2 abgelegt werden, könnte der Schritt 3 zum Relay vielleicht noch extra stehen. Wo sind diese Dateien abgelegt?