Windows-compatible Memberserver nicht unter UCS 5.2 verfügbar

Hallöchen,

 ucr get version/version
5.1

ucr get version/erratalevel
0

beim Upgrade meiner UCS Umgebung von 5.0 auf 5.2 möchte die “Manged Node” nicht auf 5.2 updaten. Lediglich 5.1 ist möglch. Warum?

blocking_apps:
The update to 5.2 is currently not possible,
because the following Apps are not available for UCS 5.2:
 * Windows-compatible Memberserver

Die Version 4.18 des Windows-compatible Memberserver ist installiert. Laut Appcenter direkt von Univention ist der Version 4.21 für UCS 5.2 verfügbar. Aber diese Version lässt sich am lokalen System nicht finden:

univention-app upgrade samba-memberserver
A newer version of samba-memberserver than the one installed must be present and chosen

Ich hab dann alles zurückgerollt und nochmal von vorne versucht zu aktualisieren. Gleicher Fehler. Also habe ich zum Test eine komplett neue UCS Umgebung mit einer zusätzlichen managed node installiert.

Fakt ist, auch dort ist die App “Windows-compatible Memberserver” nicht so einfach installierbar. Denn über das Appcenter wird sie nicht gefunden. Nur über die CMD direkt auf der Managed Node ließ sich die App installieren:

univention-app install samba-memberserver

Aber ein Join des Services ist leider dann doch nicht möglich:

RUNNING 26univention-samba.inst
2025-05-25 11:20:26.718969013+02:00 (in joinscript_init)
Not updating samba/role
Setting samba/domain/security
Multifile: /etc/samba/smb.conf
Setting samba/autostart
Multifile: /etc/samba/smb.conf
Module: autostart
Not updating samba/autostart
Stopping winbind (via systemctl): winbind.service.
Setting samba/user
Not updating samba/user/pwdfile
Multifile: /etc/samba/smb.conf
Setting stored password for "cn=ucs-member,cn=memberserver,cn=computers,dc=tux,dc=lan" in secrets.tdb
New SMB password:
Retype new SMB password:Failed to read new password!
setting idmap secret for '*' from /etc/machine.secret
Secret stored
Stopping smbd (via systemctl): smbd.service.
Stopping nmbd (via systemctl): nmbd.service.
Starting nmbd (via systemctl): nmbd.service.
Starting smbd (via systemctl): smbd.service.
Object modified: cn=ucs-member,cn=memberserver,cn=computers,dc=tux,dc=lan
Failed to join domain: failed to find DC for domain TUX - The object was not found.
Failed to join domain: failed to find DC for domain TUX - A domain controller for this domain was not found.
Failed to join domain: failed to find DC for domain TUX - A domain controller for this domain was not found.
ERROR: Failed to join via net rpc join. Please check your Samba DCs and your DNS and WINS configuration.
EXITCODE=1
0fda5e26-675c-46b3-aef5-7af40c1953da
univention-join-hooks: looking for hook type "join/post-joinscripts" on ucs.tux.lan

Somit gehe ich mal von einem Bug irgendwo in der Upgrade Logik von UCS 5.1 auf 5.2 aus? Und natürlich wohl auch ein kleinere Bug im Appcenter selbst?

Die Frage ist jetzt, wie kann ich das lösen damit ich mit meiner Managed Node auch auf die Version 5.2 komme?

Ich möchte auch noch erwähnen, dass der Selbsttest auf allen Nodes sauber durchläuft. Auch am Memberserver mit UCS5.1.

Hi,

das beobachtete Verhalten ist natürlich sehr unerfreulich. Aber technisch gesehen spannend. Ich lege meine Hand dafür ins Feuer, dass die App unter UCS 5.0, 5.1 und 5.2 existiert. D.h. aus irgend einem Grund scheint das App Center die Daten nicht zu finden? Netzwerkprobleme? Bug im App Center-Cache? Wir haben in den letzten Monaten immerhin eine Handvoll solcher Meldungen bekommen. Ich würde das gerne analysieren, aber ich kann es partout nicht nachstellen.

univention-app upgrade samba-memberserver muss nicht ausgeführt werden. In diesem Schritt wird tatsächlich nur geschaut, ob wir das Update nicht aufhalten müssen, weil die App in 5.2 gar nicht vorhanden sein wird. Ein Upgrade wird nicht ausgeführt und muss es auch nie. Hier in diesem speziellen Fall bekommt man das Update dann am Ende doch - automatisch: Denn samba-memberserver wird ganz normal beim Update auf 5.2 über die Paketaktualisierungen mitinstalliert. Am Ende wird also 4.21 installiert sein.

Der interessante Part ist univention-app update-check --ucs-version 5.2 - das ist nämlich genau das, was hier ausgeführt wird. Warum glaubt er, keinen “Windows-compatible Memberserver” zu finden? Eigentlich lädt er die App Center-Dateien für UCS 5.2 herunter und gleicht das dann mit den unter 5.1 installierten Apps ab. Wenn es natürlich einen Netzwerkfehler gäbe, kann ich mir vorstellen, dass er quasi eine leere Liste auf der einen Seite vergleicht und deshalb glaubt, die App würde gar nicht existieren. In diesem Fall wäre ein blindes “Weiteraktualisieren” auch fragwürdig, aber mindestens wäre die Fehlermeldung anzupassen.

Gibt es denn auf dem Managed Node noch weitere Apps, die installiert sind? Oder nur samba-memberserver?

Ist das Verhalten immer noch reproduzierbar? Könnten Sie im 5.1-Zustand dann einmal folgendes ausführen?

univention-app info
univention-app update-check --ucs-version 5.2
univention-app update --ucs-version 5.2

Viele Grüße
Dirk Wiesenthal

Hallo @dwiesent, und vielen Dank für deine Antwort.

das beobachtete Verhalten ist natürlich sehr unerfreulich. Aber technisch gesehen spannend.

Absolut, ja.

Ich lege meine Hand dafür ins Feuer, dass die App unter UCS 5.0, 5.1 und 5.2 existiert.

Das glaube ich dir natürlich :slight_smile: .

D.h. aus irgend einem Grund scheint das App Center die Daten nicht zu finden? Netzwerkprobleme? Bug im App Center-Cache?

Das erstere kann ich mittlerweile nach einigen Aktionen zum Test, ausschließen:

  • Zentraler Firewalltausch
  • Zentrale Firewall wegschalten
  • Wechseln der Public IP
  • Netzwerkauditlog aktivieren und auf “nomatched Sessions” oder “blocked connections” prüfen
  • Domaincontroller und Memberserver befinden sich schon immer im gleichen Subnet

Gibt es denn auf dem Managed Node noch weitere Apps, die installiert sind? Oder nur samba-memberserver ?

Nur der “samba-memberserver”.

Ist das Verhalten immer noch reproduzierbar? Könnten Sie im 5.1-Zustand dann einmal folgendes ausführen?

Ja, leider. Hier der Output der Befehle auf der produktiven Managed Node:

univention-app info

UCS: 5.1-0 errata0
Installed: samba-memberserver=4.21
Upgradable:
univention-app update-check --ucs-version 5.2

Unable to cache apps
Unable to cache apps
The update to 5.2 is currently not possible,
because the following Apps are not available for UCS 5.2:
 * Windows-compatible Memberserver
univention-app update --ucs-version 5.2

Downloading "https://appcenter.software-univention.de/meta-inf/app-categories.ini"...
Downloading "https://appcenter.software-univention.de/meta-inf/rating.ini"...
Downloading "https://appcenter.software-univention.de/meta-inf/license_types.ini"...
Downloading "https://appcenter.software-univention.de/meta-inf/ucs.ini"...
Downloading "https://appcenter.software-univention.de/meta-inf/suggestions.json"...
Downloading "https://appcenter.software-univention.de/meta-inf/5.2/all.tar.gpg"...
Downloading "http://appcenter.software-univention.de/meta-inf/5.2/all.tar.zsync"...
File: /usr/share/univention-management-console/modules/apps.xml

Multifile: /etc/apache2/sites-available/000-default.conf

File: /usr/share/univention-management-console/i18n/de/apps.mo

Multifile: /etc/apache2/sites-available/default-ssl.conf

Wobei hier wohl “Unable to cache apps” interessant ist?


Wir haben in den letzten Monaten immerhin eine Handvoll solcher Meldungen bekommen. Ich würde das gerne analysieren, aber ich kann es partout nicht nachstellen.

Ja, sowas kann super nervig sein. Aber zum Glück kann ichs immer wieder reproduzieren, was bei solch komplexen Themen meist selten ist.

Testszenario:

Ich habe mir einfach eine neue UCS5.2 Umgebung komplett frisch installiert (wie schon in meinen ersten Post beschreiben). Der aktuelle Zustand ist das ich eine “Managend Node” installiert habe. Darauf auch “samba-memberserver”. Die Installation war nur manuell über die CMD möglich. Ein Join von “26univention-samba.inst” schlug fehl. Den Zustand konnte ich auch nicht ändern.

Was hat aber die Testinstallation und meiner produktiven Umgebung gemeinsam?

Die "Primary und Backup Directory Node sieht nicht das die App “Windows-compatible Memberserver” (samba-memberserver) installiert ist. Das sieht ausschließlich die “Managed Node”. Ein “univention-app umc-generate-app-cache” ändert das auch nicht.

Ich hab dann zum Test in der neu installierten UCS-Testumgebung einfach mal Fetchmail als App auf die “Managed Node” installiert. Und ja das wird auch von der “Primary Directory Node” dann unter “Installiert in der Domäne” gesehen. Also die Verbindung selbst und die Installation der Apps scheint zu passen.

univention-app info #Auf der "Managed Node" ausgeführt.

UCS: 5.2-1 errata118
Installed: fetchmail=6.4.37 samba-memberserver=4.21
Upgradable:

Nun hab ich heute noch einen zweite “Managed Node” zum Test installiert. Wenn ich dort in das Appcenter gehe, sieht diese Node die App “samba-memberserver” von der anderen “Managed Node” ganz normal.

Als nächsten Schritt habe ich dann auch auf dieser zusätzlichen zweiten “Managed Node” die App"Windows-compatible Memberserver" (samba-memberserver) installiert. Hier ließ sich die App auch ganz normal über die WebUI installieren, aber nur von der “Managed Node” aus. Der Join von “26univention-samba.inst” schlug aber auch hier abermals fehl.

Ich habe das Debuglog vom Join und von der Installation der App hier anhängt.

app-install-log.txt (41,1 KB)
join-log1.txt (1,6 KB)

Intressant klingt es für mich:

New SMB password:
Retype new SMB password:Failed to read new password!
setting idmap secret for '*' from /etc/machine.secret
Secret stored

Falls du noch weitere Informationen oder Installationen benötigst, ich helfe gerne. Das wird sicher zum Hinbekommen sein. Scheint aber wohl etwas tiefer zu liegen.

Vielen Dank
lg
boospy

Hallo,

das bringt uns vielleicht tatsächlich einen Schritt weiter. Aber zunächst einmal ein paar Kleinigkeiten:

Wenn der Primary Directory Node die App nicht als installiert erkennt, ist das ein Problem mit der Registrierung auf dem Managed Node. Dort muss man dann univention-app register ausführen. Das sollte im LDAP die Information hinterlegen, dass samba-memberserver installiert ist. Vermutlich ist mit “war nur über CMD möglich” gemeint, dass das Paket per “univention-install” oder so installiert wurde? Weil dann eine Registrierung über das App Center nicht stattfindet. Es kann aber auch sein, dass der Managed Node überhaupt gerade Probleme mit der Verbindung hat - das nicht erfolgreich ausführbare Joinskript ist da auch ein Hinweis. Aber das ist für unser Problem vielleicht auch nicht entscheidend.

Unable to cache apps ist ein “Anzeigeproblem”. Eigentlich müsste (in diesem Fall) dort stehen: “Ich werde die heruntergeladenen Metadaten der Apps nicht in einer lokalen Datenbank zwischenspeichern, weil mir das explizit so gesagt wurde. Ich arbeite aber mit den Daten - allerdings nur im Arbeitsspeicher”. Also kein Grund zur Sorge.

Nun zu meiner Frage: Kann es sein, dass der Managed Node während des Updates auf 5.2 schon einmal abgebrochen ist (also in seinem derzeitigen Zustand, falls er z.B. einmal auf einen “sauberen” Snapshot revertet wurde, zählt das nicht). Ich frage, weil es hier heißt:

univention-app info

UCS: 5.1-0 errata0
Installed: samba-memberserver=4.21

Und das kann eigentlich nicht sein. Denn unter 5.1 ist die Version eigentlich 4.18. Zu sehen hier (übrigens auch der Beweis, dass die App in beiden UCS-Versionen existiert):

https://appcenter.software-univention.de/meta-inf/5.1/samba-memberserver/samba-memberserver.ini

vs.

https://appcenter.software-univention.de/meta-inf/5.2/samba-memberserver/samba-memberserver.ini

Kann es also sein, dass das System einmal “knapp” 5.2 installiert hatte, aber dann aus irgend einem Grund (z.B. /boot-Partition voll) abbrach und nie offiziell auf 5.2 gegangen ist, aber quasi 90% der Pakete schon hat? Steht etwas in der Datei /var/lib/univention-updater/univention-updater.status?

Getestet am Testsystem/Testdomäne, das ändert nichts:

root@member:~# univention-app register
No repository to register
Creating data directories for samba-memberserver...
...
No hostdn for wekan found. Nothing to remove
Removing localhost from LDAP object
Removing localhost from LDAP object
Removing localhost from LDAP object
Removing localhost from LDAP object
Registering UCR for samba-memberserver
Marking samba-memberserver=4.21 as installed
Adding localhost to LDAP object
Removing localhost from LDAP object
Password for Administrator: 
root@member:~# 

Im LDAP am DC ist es aber vorhanden:
ldap-eintrag-samba-app.txt (3,7 KB)

Vermutlich ist mit “war nur über CMD möglich” gemeint, dass das Paket per “univention-install” oder so installiert wurde?

Ja, auf das UCS Testsystem bezogen, ist das korrekt. Am produktivsystem gibt es die App schon seit ca. 6 Jahren.

Unable to cache apps ist ein “Anzeigeproblem”

Danke für die Erklärung. Dann ignorieren wir das.

Nun zu meiner Frage: Kann es sein, dass der Managed Node während des Updates auf 5.2 schon einmal abgebrochen ist (also in seinem derzeitigen Zustand, falls er z.B. einmal auf einen “sauberen” Snapshot revertet wurde, zählt das nicht). Ich frage, weil es hier heißt:

UCS: 5.1-0 errata0
Installed: samba-memberserver=4.21

Und das kann eigentlich nicht sein. Denn unter 5.1 ist die Version eigentlich 4.18. Zu sehen hier (übrigens auch der Beweis, dass die App in beiden UCS-Versionen existiert):

Ok, jetzt wirds wärmer, weil das ist mir nämlich wie ich es gepostet habe überhaupt nicht aufgefallen. Aber, jetzt schaute ich gerade wieder auf die produktive “Managed Node”. Es wird wieder Version 4.18 angezeigt. Aber nachdem ich die Befehle ausführe, wird Version 4.21 angezeigt:

 Univention  root@data:~# univention-app info
UCS: 5.1-0 errata0
Installed: samba-memberserver=4.18
Upgradable: 

Univention  root@data:~# univention-app update-check --ucs-version 5.2

univention-app update --ucs-version 5.2
Unable to cache apps
Unable to cache apps
The update to 5.2 is currently not possible,
because the following Apps are not available for UCS 5.2:
 * Windows-compatible Memberserver
Downloading "https://appcenter.software-univention.de/meta-inf/app-categories.ini"...
Downloading "https://appcenter.software-univention.de/meta-inf/rating.ini"...
Downloading "https://appcenter.software-univention.de/meta-inf/license_types.ini"...
Downloading "https://appcenter.software-univention.de/meta-inf/ucs.ini"...
Downloading "https://appcenter.software-univention.de/meta-inf/suggestions.json"...
Downloading "https://appcenter.software-univention.de/meta-inf/5.2/all.tar.gpg"...
Downloading "http://appcenter.software-univention.de/meta-inf/5.2/all.tar.zsync"...
Multifile: /etc/apache2/sites-available/default-ssl.conf

Multifile: /etc/apache2/sites-available/000-default.conf

File: /usr/share/univention-management-console/i18n/de/apps.mo

File: /usr/share/univention-management-console/modules/apps.xml

 Univention  root@data:~# univention-app info
 
UCS: 5.1-0 errata0
Installed: samba-memberserver=4.21
Upgradable:

Wenn man ein wenig wartet, wird wieder 4.18 angezeigt.

Kann es also sein, dass das System einmal “knapp” 5.2 installiert hatte, aber dann aus irgend einem Grund (z.B. /boot-Partition voll) abbrach und nie offiziell auf 5.2 gegangen ist, aber quasi 90% der Pakete schon hat? Steht etwas in der Datei /var/lib/univention-updater/univention-updater.status ?

Fast. Ich hatte meine zwei Domänencontroller erfolgreich auf die Version 5.2 aktualisiert. Dann als letzten Schritt startete ich die Aktualisierung der “Managed Node”. Natürlich habte bevor ich überhaupt angefangen habe ein UCS System up zu graden, alle VMs heruntergefahren und Offline Snapshots erstellt.

Nun bei der “Managed Node” ist das Upgrade auf 5.1 schon zwischendrinn mit apt Error abstürtzt, es hab unerfüllte Abhängigkeiten für Proftpd. Somit hab ich die VM zurückgerollt, hab Proftpd und alles was dazu gehört vor dem Start des Upgrades entfernt. Passte, Upgrade durchgelaufen bis 5.1. Bei 5.2 kam dann der besagte Fehler.

Hier der Inhalt der Datei:

current_version=5.1-0
type=NET
status=FAILED
next_version=5.2-0
target_version=5.2-0
errorsource=PREUP

Lieben Dank und Viele Grüße
boospy :slight_smile:

Update: Ich konnte nun auf einem komplett frisch installiertem Testsystem ganz normal und ohne Probleme den Memberserserver als App installieren und integrieren. Ich glaube, mein anderes Testsystem hatte da irgendwo ein Problem. Wahrscheinlich hab ich irgendow einen Fehler gemacht und mal ein Snapshot nicht zurückgerollt.

Der Status am produktiven Sytem ist noch derselbe. Was ich aber mit dem Test herausgefunden habe, der Primary Directory Node sieht die App “samba-memberserver” im Appcenter definitv nicht. Ich musste diese App vom Appcenter am Managed Node installieren.

Ich glaube auch zu wissen warum. Kann es sein das nur Apps angezeigt werden die kompatibel bzw. installierbar sind?
Weil einen samba-memberserver kann man natürlich nicht auf einem Primary Directory Node installieren.

Ich konnt es nun lösen und auch meine “Managed Node” auf 5.2.x aktualisieren. Ich nahm jetzt einfach den Vorschlaghammer :hammer:. Funktioniert (fast) immer :stuck_out_tongue:.

Dafür hab ich die App “Windows-kompatibler Memberserver” deinstalliert. Folgende Pakete wurde dabei removed, das hilft vielleicht heraus zu finden, warum es sich so verhalten hat und sich der Server mit der App nicht updaten ließ.

cpp-10
univention-samba
expect
libasan6
gcc-11-base
librest-0.7-0
libsoup-gnome2.4-1
libsoup2.4-1
glib-networking
glib-networking-services
glib-networking-common
gsettings-desktop-schemas
guile-2.2-libs
libatk1.0-data
libavdevice58
libavfilter7
libavformat58
libavresample4
libbpf0
libcbor0
libdbus-glib-1-2
libdns-export1110
libfftw3-double3
libfl2
libflac8
libgdk-pixbuf2.0-0
libgdk-pixbuf-xlib-2.0-0
libgs9-common
libhcrypto4-heimdal
libicu67
libigdgmm11
libisc-export1105
libjson-glib-1.0-0
libjson-glib-1.0-common
libllvm11
python3.9
libpython3.9
libpython3.9-stdlib
libmpdec3
libnetpbm10
libnss-ldapd
sntp
ntp
libopts25
libotf0
libpam-ldapd
libperl5.32
libpostproc55
libprocps8
libproxy1v5
python3.9-minimal
libpython3.9-minimal
libroken18-heimdal
libsoup2.4-common
libsrt1.4-gnutls
libswscale5
tcl8.6
tcl-expect
libtcl8.6
liburing1
libusb-0.1-4
linux-image-5.10.0-0.deb10.33-amd64
linux-image-5.10.0-30-amd64
mariadb-server-10.5
nslcd-utils
nslcd
ntpdate
perl-modules-5.32
python3-parameterized
python3-pyparsing
univention-samba-local-config
samba
samba-ad-provision
samba-vfs-modules
tdb-tools
univention-saml-schema

Danach hab ich die “Managed Node” auf aktuellen Stand gebracht, neu gestartet, Selbsttest durchgeführt → Alles ok.
Als letzten Schritt hab ich dann aus dem Appcenter von der “Managed Node” wieder die App “Windows-kompatibler Memberserver” installiert. Dabei wurde folgende Pakete installiert:

tdb-tools
samba
libtcl8.6
tcl8.6
tcl-expect
expect
univention-samba-local-config
univention-samba
samba-ad-provision
samba-vfs-modules

Jetzt noch ein “diff” auf die verantwortlichen Configfiles unter /etc/samba → alles ok.
Da die Deinstallation glücklicherwiese kein “--purge” machte, blieben auch fast alle relevanten Configfiles unter /etc/samba vorhanden. Diese die tatsächlich gelöscht wurden, wurden aber bei der Installation auch wieder angelegt. Ein diff mit den zuvor gesicherten Files zeigte nur minimal Unterschiede.

Somit funktioniert nun wieder alles wie soll.