Errata-Update / Samba wurde deinstalliert

Ich habe gestern das Errata Update von 4.1-3 errata331 auf 4.1-3 errata360 einspielen wollen.

Leider habe ich nicht auf die Systemmeldung geachtet und die gemeldete Deinstallation einiger wichtiger Systemkomponenten abgenickt :frowning:

[quote]Starting dist-upgrade at Mo 19. Dez 21:30:15 CET 2016
Paketlisten werden gelesen…
Abhängigkeitsbaum wird aufgebaut…
Statusinformationen werden eingelesen…
Die folgenden Pakete werden ENTFERNT:
samba samba-common-bin smbclient univention-dansguardian
univention-s4-connector univention-samba-local-config univention-samba4
univention-squid univention-squid-kerberos winbind
Die folgenden NEUEN Pakete werden installiert:
librelp0 rsyslog-relp
Die folgenden Pakete sind zurückgehalten worden:
libsmbclient python-samba samba-dsdb-modules samba-libs samba-vfs-modules
Die folgenden Pakete werden aktualisiert (Upgrade):
bash bind9 bind9-host bind9utils dnsutils dpkg dpkg-dev libbind9-80 libdns88
libdpkg-perl libexpat1 libisc84 libisccc80 libisccfg82 liblwres80
libunivention-config0 libwbclient0 libxml2 libxml2-utils memcached
python-imaging python-univention-appcenter python-univention-config-registry
samba-common squid3 squid3-common tar tzdata univention-appcenter
univention-appcenter-docker univention-base-files univention-base-packages
univention-config univention-config-registry univention-errata-level
univention-management-console-frontend
univention-management-console-frontend-theme
univention-management-console-module-appcenter
univention-management-console-module-apps
univention-management-console-module-udm
univention-management-console-web-server
41 aktualisiert, 2 neu installiert, 10 zu entfernen und 5 nicht aktualisiert.
[/quote]

Danach konnte ich die benannten Pakete auch nicht mehr installieren. Es gab immer wieder Abhängigkeitsfehler. In der Hoffnung, ich könnte die Pakete wieder installieren, wenn sie denn einwandfrei deinstalliert wurden, habe auch noch ein “apt-get autoremove --purge” ausgeführt. Ohne Erfolg.

Durch Recherche im Netz habe ich den Abhängigkeitsfehler lösen können. Das Paket “libwbclient0” wurde in der Version 2:4.5.1-… installiert, min. ein Paket setzten aber die Version 2:4.3.7-1.835.201607051244 voraus - also eine ältere. Die verlangte Version konnte ich per apt-get installieren. Danach liesen sich auch alle anderen zuvor deinstallierte Pakete wieder installieren.

Problem ist nun, dass der UCS hier als DC konfiguriert ist und es hier natürlich zu Problemen kommt. Ich war noch guter Hoffnung, da die Einstellungen soweit ich es überschauen kann, noch alle vorhanden sind (z.B. LDAP oder UCS-Registry). Das war es aber auch schon. Verbindungen der Domänen-Mitglieder scheitern beharrlich. (“ucr commit” und “join” wie an anderen Stellen empfohlen habe ich ausgeführt)

Hier komme ich nun nicht mehr weiter und bräuchte einen Ratschlag (oder mehrere), wie ich weiter vorgehen sollte. Backups (Bacula) der Vortage habe ich im Zugriff. Das Dokument “Backup und Wiederherstellung eines UCS-Systems” bringt mich leider nicht so richtig weiter. Ich bräuchte eine Schritt-für-Schritt-Anleitung, was ich wann auszuführen habe. Die genannte Doku ist hier für mich nicht eindeutig.

Wäre schon, wenn jemand helfen könnte.

mfg,
MKr

Hi,

habe dasselbe Problem hier auf 3 UCS-Installationen (Master, ein Slave und ein Member). Errata-Updates werden Nachts automatisch installiert. :frowning:
Den Master habe ich nach dem Upgrade auf 4.1-4, Neuinstallation von univention-samba4, univention-s4-connector und smbclient, und dem Einspielen des samba4_private und sysvol Backups wieder belebt.
Kurz mal die Schritte als Kommandozeilenaufrufe aus der Erinnerung ohne Anspruch auf Korrektheit und Vollständigkeit:

[code]univention-upgrade --ignoressh
univention-install univention-samba4
univention-run-join-scripts
service samba stop

Hier Restore von /var/lib/samba/private aus /var/univention-backup/samba/samba4_private.2016-12-19.tar.bz2

Hier Restore von /var/lib/samba/sysvol aus /var/univention-backup/samba/sysvol.2016-12-19.tar.bz2

univention-install univention-s4-connector
univention-install smbclient
service samba restart

Korrektur von /etc/krb5.keytab

eval “$(ucr shell)”
echo -e “dn: flatname=$windows_domain,cn=Primary Domainsnchangetype: modifynreplace: krb5Keytabnkrb5Keytab: /tmp/krb5.keytab” | ldbmodify -H /var/lib/samba/private/secrets.ldb
echo -e “dn: flatname=$windows_domain,cn=Primary Domainsnchangetype: modifynreplace: krb5Keytabnkrb5Keytab: /etc/krb5.keytab” | ldbmodify -H /var/lib/samba/private/secrets.ldb
[/code]

DC-Master läuft damit wieder (Dateifreigaben, Domänenanmeldung), aber auf dem Memberserver, der auch ein Fileserver ist, laufen die Join-Skripte nicht sauber durch.
Letze Ausgabe in /var/log/univention/join.log nach univention-run-join-scripts

[quote]RUNNING 98univention-samba4-dns.inst
2016-12-21 00:50:28.472585125+01:00 (in joinscript_init)
Samba4 backend database not available yet, exiting joinscript 98univention-samba4-dns.
EXITCODE=1
[/quote]
Der S4-Connector ist auf dem Memberserver nicht installiert.

Werde jetzt noch ein paar Sachen probieren.

Tschüss,
Daniel

Hallo zusammen,

Leider hat für die UCS Version 4.1-3 das Errata xxx dazu geführt, das unter anderem die Pakete univention-samba4 und univention-s4-connector automatisch deinstalliert wurden. Das Verhalten wurde am 20.12. bereits korrigiert.

In @School Umgebungen sollte es ausreichend sein, die Pakete univention-samba4 und univention-s4-connector mittels univention-install erneut zu installieren.

# univention-install -s samba samba-common-bin smbclient univention-s4-connector univention-samba-local-config univention-samba4 winbind

Prüfen, dann live:

# univention-install samba samba-common-bin smbclient univention-s4-connector univention-samba-local-config univention-samba4 winbind

Dabei wird der Univention Active Directory Domaincontroller erneut installiert und mit Informationen aus dem LDAP erneut gefüllt. Das ist relativ sicher ohne weitere Rejoins möglich, da die Informationen für das @School S4 primär aus dem LDAP gefüllt werden.

In nicht-School Umgebungen wird nach dem obigen Vorgehen (Neu-Installation samba4 und s4-connector) es nötig die Clients und Server neu zu joinen - das kann je nach Größe der Umgebung sehr umfangreich sein. Hier kann bei Bedarf ein Samba-Backup genutzt werden (bei kleineren Umgebungen kann es einfacher sein, die Clients neu zu joinen, dann ist nur eine Installation der Pakete nötig) - das unjoin Script hat die Samba Daten nur verschoben. Es sind nun einige weitere Schritte nötig, falls der Rejoin umgangen werden soll:

Service Samba4 wieder dem Computerobjekt des Servers hinzufügen, falls es fehlt.

ucr set samba4/ldap/base='<your_S4_ldap_base>' samba4/role='DC' samba4/autostart='yes' samba4/sysvol/sync/cron='*/5 * * * *' kerberos/kdc='127.0.0.1' kerberos/kpasswdserver='127.0.0.1'

mv /var/lib/samba_backup_2016<some_further_date> /var/lib/samba

danach:

# univention-install -s samba samba-common-bin smbclient univention-s4-connector univention-samba-local-config univention-samba4 winbind

Prüfen, dann live:

# univention-install samba samba-common-bin smbclient univention-s4-connector univention-samba-local-config univention-samba4 winbind

Prüfen ob Heimdall KDC wieder läuft und wenn nötig deaktivieren!

[code]# ucr search kerberos/autostart

ucr set kerberos/autostart=no

service heimdal-kdc stop

service samba restart[/code]

Der S4 Connector wird danach trotzdem durchlaufen und Syncs durchführen, das kann etwas dauern.

Mit freundlichem Gruß,
Jens Thorp-Hansen

Mein Memberserver läuft nun auch wieder. Dort fehlen andere Pakete:

univention-install univention-samba smbclient

Wichtig ist …samba ohne 4 für Memberserver. Danach habe ich den Join zum Master wiederholt und die Dateifreigaben des Memberservers funktionieren wieder.

Die unnötigen Zwischenschritte habe ich weggelassen. :wink:

Damit scheint dieses Problem auch wieder beseitigt zu sein.

Tschüss,
Daniel

Hallo,

vielen Dank für die Rückmeldungen. Haben auf meiner Seite aber leider bisher nicht geholfen. Es wäre ok für mich, die Clients neu in die Domäne zu bringen (so viele sind es in der Tat nicht) - ich komme aber erst gar nicht soweit :frowning:

Ich bekomme nun “S4CONNECTOR WARNING: Found 14 reject(s)! Please check output of univention-s4connector-list-rejected.”. Die Rückmeldungen des Befehls sind für mich auch nicht sehr erhellend. Im “connector-s4.log” werden für all die “Rejected”-Objekte diese Fehlermeldungen ausgegeben

[quote] 23.12.2016 22:19:00,65 LDAP (ERROR ): Unknown Exception during sync_to_ucs
23.12.2016 22:19:00,65 LDAP (ERROR ): Traceback (most recent call last):
[/quote]
Dies scheint mir aber nicht das Problem zu sein, warum ich keinen Client “rejoinen” kann: Ein “net view ucs” von irgendeinem Win7-Clienten gibt

[quote] Systemfehler 5 aufgetreten.
Zugriff verweigert
[/quote]
zurück.

Weitere Ideen?

Gruß,
MKr

P.S. Frohe und fehlerfreie Feiertage

Hallo,

kurzer Zwischenstandsbericht: Ich bin nun nochmals nach der Doku #2010 “Vollständiger Rebuild eines UCS-Systems” vorgegangen (nur die für mich rel. Teile). Ich bekomme nun nur noch 2 Rejected-Objekte und mit anders lautender Fehlermeldung:

[quote]26.12.2016 15:44:45,123 LDAP (ERROR ): sync of rejected object failed
CN=ipsecISAKMPPolicy{72385237-70FA-11D1-864C-14A300000000},CN=IP Security,CN=System,DC=kosinus,DC=local
26.12.2016 15:44:45,123 LDAP (ERROR ): Traceback (most recent call last):
[/quote]

Immerhin!

Das Problem mit dem Verbinden der Clients besteht weiterhin. Allerdings habe ich festgestellt, dass scheinbar nur die Windows-Clients dieses Problem haben!? Mein Medien-Server (Kodi) als auch das iPhone können auf die Freigaben anstandslos zugreifen.

Gruß,
MKr

Steht in den Logdateien unter /var/log/samba irgendwas erhellendes?
Das hat mir zumindest weitergeholfen.

Ich glaube zur Analyse fehlen grad noch einige Informationen. Wenn durch das Update Samba4 deinstalliert wurde, müsste es ausreichen per

# univention-install samba samba-common-bin smbclient univention-s4-connector univention-samba-local-config univention-samba4 winbind

die fehlenden Pakete nachzuinstallieren. Ein funktionstüchtiges LDAP vorausgesetzt wird das Samba4 dann neu provisioniert. Man kann die Neu-Provisionierung auch manuell anstoßen: http://sdb.univention.de/content/6/274/en/re_provisioning-samba4-on-a-dc-master.html

Können Sie ggf. den nach dem SDB Artikel das Samba4 noch einmal “zurückrollen” wenn es da Probleme gibt?

[quote]Systemfehler 5 aufgetreten.
Zugriff verweigert[/quote]
heißt übrigens, dass die commandshell von Windows mit Administratorrechten aufgerufen werden will. Das “Zugriff verweigert” bezieht sich auf den ausgeführten Befehl.

Hallo!

Das Samaba Re-Provisioning hat mich einen großen Schritt weiter gebracht. Die Benutzeranmeldungen funktionieren nun wieder :slight_smile:

Der Hinweis

[quote]Systemfehler 5 aufgetreten.
Zugriff verweigert

heißt übrigens, dass die commandshell von Windows mit Administratorrechten aufgerufen werden will. Das “Zugriff verweigert” bezieht sich auf den ausgeführten Befehl.[/quote]

kann ich so nicht stehen lassen. Auch mit Administratoren-Rechten bekomme ich diese Rückmeldung.

Das Problem mit “net view” besteht weiterhin. Es scheint mir so, als würde Samba “Anonymous”-Zugriffe auf die Share-Liste nicht zu zulassen. Wenn ich von einem Nicht-Domänen-Mitglied “net view” aufrufe, erhalte ich die Fehlermeldung. Habe ich mich zuvor per “net use” auf ein Share mit einem Domänen-Benutzerkonto verbunden, erhalte ich die Freigabeliste ohne Fehlermeldung.

Außerdem kann ich mit dem Media-Server (Kodi) nun nicht mehr auf die Shares zugreifen.

In welchen Logs könnte ich etwas erhellendes finden? In /var/log/samba/ wird diesbez. nichts verwertbares protokolliert.

mfg,
MKr

Kommando pimperle, das Thema kann als gelöst betrachtet werden!

Das zuletzt geschilderte Problem (Zugriff Media-Servers) war einfach nur ein Kennwort-Problem. Wie ich bereits geschrieben habe, konnte ich das eigentliche Problem schlussendlich mit der Neu-Provisionierung des Samba lösen (s. sdb.univention.de/content/6/274/ … aster.html).

Vielen Dank für die Unterstützung,

MKr

Mastodon