Update form Open SuSE 15.5 to 15.6

Andy · 15 Mar

WalterH mehr Informationen liefert und Möglichkeiten zum Eingreifen bietet.

Das ist aus dieser Sicht richtig, ich unterstelle aber, ich gehe da auch von mir aus, dass nicht jeder damit nichts anfangen kann, weil Kenntnisse fehlen. Ich bevorzuge daher die Neuinstallation und Datenübertragung.

WalterH · 15 Mar

Andy Ich bevorzuge daher die Neuinstallation und Datenübertragung.

Mann kann es auch kompliziert und aufwändig machen.

Andy · 15 Mar

Innerhalb von max. 30 Minuten ist das erledigt. Wenn ein Vorgang aber Interpretationen zulässt, die nicht jeder durchdringen kann, wird es für nicht so kundige schwierig.

crpb · 15 Mar

WalterH Das Script kann das: https://docs.grommunio.com/admin/operations.html#updating-grommunio

Wüsste ich nichts von und im git repo ist noch der alte kram drin sowie auf den installierten systemen..

grom-test-4:~ # rpm -q grommunio-admin-common
grommunio-admin-common-42.e17ec55-lp156.36.1.noarch
grom-test-4:~ # grep -Po '15.?([0-9])?.*' /etc/zypp/repos.d/* /usr/sbin/grommunio-repo /usr/sbin/grommunio-update
/etc/zypp/repos.d/base.repo:15.6/repo/oss
/etc/zypp/repos.d/base.repo:15.6/oss
/etc/zypp/repos.d/base.repo:15.6/repo/oss
/etc/zypp/repos.d/base.repo:15.6/oss
/etc/zypp/repos.d/base.repo:15.6/repo/oss/
/etc/zypp/repos.d/grommunio-base.repo:15.6/repo/oss
/etc/zypp/repos.d/grommunio-base.repo:15.6/oss
/etc/zypp/repos.d/grommunio-base.repo:15.6/sle/
/etc/zypp/repos.d/grommunio-base.repo:15.6/backports/
/etc/zypp/repos.d/grommunio-base.repo:15.6/repo/oss
/etc/zypp/repos.d/grommunio-base.repo:15.6/oss
/etc/zypp/repos.d/grommunio-base.repo:15.6/sle/
/etc/zypp/repos.d/grommunio-base.repo:15.6/backports_debug/
/etc/zypp/repos.d/grommunio-base.repo:15.6/repo/oss/
/etc/zypp/repos.d/grommunio.repo:15.6/?ssl_verify=no
/usr/sbin/grommunio-repo:15.[34]#${VERSION_ID}#g" /etc/zypp/repos.d/*.repo > /dev/null 2>&1
/usr/sbin/grommunio-update:15 Minutes: "$5 }')

Da ist keine mechanik drin die von 15.5 auf 15.6 aktualisiert weil die ziffer 5 nach der 34 fehlt was es dann jedoch einfach ohne nachfrage machen würde durch ein klicken auf update im admin-web...

Also sofern man in die datei /etc/os-release einfach mal 15.6 eintragen würde jetzt wo das auch genutzt wird \o/

Andy · 16 Mar

Ich habe da mal an einem Klone meiner Produktiv-VM mit Leap 155 getestet: Ersetzen der Einträge 15.5 -> 15.6 in

/etc/zypp/repos.d/base.repo
/etc/zypp/repos.d/grommunio.repo
/etc/zypp/repos.d/grommunio-base.repo
/etc/os-release

und zypper --verbose ref -f && zypper --verbose dup ausgeführt:

Die folgenden 478 Pakete werden aktualisiert:
  adwaita-icon-theme                  41.0-150400.1.10 -> 45.0-150600.1.2
  alsa                                1.2.8-150500.1.1 -> 1.2.10-150600.2.3
  alsa-ucm-conf                       1.2.8-150500.1.1 -> 1.2.10-150600.1.2
  alsa-utils                          1.2.8-150500.1.2 -> 1.2.10-150600.3.3.6
.
.
.
Das folgende Schema wird aktualisiert:
  grommunio  1-lp155.9.1 -> 1-lp156.9.1

Die folgenden 10 Pakete werden durch eine ältere Version ausgetauscht:
  libprotobuf-lite20   3.9.2-150200.4.24.1 -> 3.9.2-150200.4.21.1
  libtiff5             4.0.9-150000.45.47.1 -> 4.0.9-150000.45.41.1
  php8-redis           5.3.7-lp155.1.9 -> 5.3.7-bp156.2.5
  python3-argcomplete  1.9.2-150000.3.8.1 -> 1.9.2-150000.3.5.1
  python3-dnspython    1.15.0-150000.3.10.2 -> 1.15.0-150000.3.2.1
  python3-Jinja2       2.10.1-150000.3.18.1 -> 2.10.1-3.10.2
  python3-PyYAML       5.4.1-150300.3.3.1 -> 5.4.1-1.1
  python3-requests     2.25.1-150300.3.12.2 -> 2.25.1-150300.3.6.1
  python3-urllib3      1.25.10-150300.4.12.1 -> 1.25.10-150300.4.9.1
  python3-Werkzeug     1.0.1-150300.3.8.1 -> 1.0.1-150300.3.3.1

Die folgenden 48 NEUEN Pakete werden installiert:
  kernel-default                  6.4.0-150600.23.42.2
  libavc1394-0                    0.5.4-1.27
  libb2-1                         0.98.1-150400.1.4
  libbpf1                         1.2.2-150600.3.3.1
  libc++1                         19.1.7-bp156.4.2
  libc++abi1        
.
.
.
Die folgenden 4 Pakete werden GELÖSCHT:
  libsemanage1       3.1-150400.3.4.2
  llvm17-libc++1     17.0.6-bp155.5.1
  llvm17-libc++abi1  17.0.6-bp155.5.1
  systemd-sysvinit   249.17-150400.8.46.1

Das folgende Paket erfordert einen Systemneustart:
  kernel-default  6.4.0-150600.23.42.2

478 Pakete werden aktualisiert, 10 werden zurückgestuft, 48 neue, 4 zu entfernen.

Größe des Pakets zum Herunterladen:    1,18 GiB

Änderung der Installationsgröße des Pakets:
              |      4,30 GiB  erforderlich für Pakete, die installiert werden sollen
   445,7 MiB  |  -   3,86 GiB  freigegeben von Paketen, die entfernt werden sollen

    Hinweis: Systemneustart erforderlich.

Backend:  classic_rpmtrans
Fortfahren? [j/n/v/...? zeigt alle Optionen] (j):

Insgesamt wurden 539 Pakete heruntergeladen und installiert, wobei auffällig war eigentlich nur das

Nach einem Reboot am Ende scheint die VM ohne ein Problem mit Leap 156 zu laufen. Wäre das vielleicht ein sicherer Weg?

WalterH · 16 Mar

Andy Wäre das vielleicht ein sicherer Weg?

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

Andy · 16 Mar

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 · 16 Mar

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

Andy · 16 Mar

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 · 16 Mar

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 · 16 Mar

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 · 17 Mar

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 · 17 Mar

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 · 18 Mar

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 · 18 Mar

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 · 18 Mar

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

Andy · 18 Mar

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 · 19 Mar

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 · 21 Mar

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 · 22 Mar

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.