Aktualisierung Slave nicht möglich

Hallo zusammen,

wir haben vor einiger Zeit einen Slave aufgesetzt der seitdem läuft.
Heute haben wir unseren DC MAster und den Backup auf 4.1.4 aktualisiert, der Slave jedoch lässt sich nicht aktualisieren bzw findet keine Aktualisierung.

Über die CLI liefert ein apt-get update nur folgende Ausgabe:

Ign cdrom://[UCS GNU/Linux 4.1-3 _Ucs413_ - Official Release amd64 DVD Binary-1 20160809-09:34] ucs413 Release.gpg
Ign cdrom://[UCS GNU/Linux 4.1-3 _Ucs413_ - Official Release amd64 DVD Binary-1 20160809-09:34] ucs413 Release

scheint als wären da die sources nicht ganz richtig.. Ist das auf dem Slave so gewollt oder ist da bei der Installation ein Fehler unterlaufen?
Ebenfalls habe ich die Join Scripte nochmals ausgeführt welches keine Lösung für das vorliegende Problem war.

Habe mir grad auch mal die sourcel angeschaut. folgendes steht in der file:

root@dc-slave:/etc/apt/sources.list.d# cat 15_ucs-online-version.list
#Warning: This file is auto-generated and might be overwritten by
#         univention-config-registry.
#         Please edit the following file(s) instead:
#Warnung: Diese Datei wurde automatisch generiert und kann durch
#         univention-config-registry überschrieben werden.
#         Bitte bearbeiten Sie an Stelle dessen die folgende(n) Datei(en):
#
#	/etc/univention/templates/files/etc/apt/sources.list.d/15_ucs-online-version.list
#

# The online repository is disabled and can be enabled with:
#   univention-config-registry set repository/online=true

auf dem Master DC sieht das ganze natürlich anders aus..

Beste Grüße

Hallo xinput,

da scheinen bei dir einige Repository-Einträge zu fehlen. Vermutlich ist das Update nicht sauber durchgelaufen.
Kannst du einmal prüfen, was in der Logdatei /var/log/univention/updater.log steht?

Wie du schon selber richtig gefunden hast, sollte das Online-Repository aktiviert werden:
univention-config-registry set repository/online=true

Viele Grüße,
Tobias Birkefeld

Danke für deine Antwort.

die updater.log ist voll mit Appcenter Meldungen aber auf anhieb sehe ich nichts was die Univention updates betrifft.

Habe jetzt mal mit univention-config-registry set repository/online=true die Sources aktiviert und kann das Update durchführen.
Dadurch würde ich mein Problem als behoben ansehen! Warum genau das ganze bei der Installation schief gelaufen ist wird wohl ein Geheimnis bleiben. Die Installation war im November und somit liegen die Logfiles sehr weit zurück..

Danke nochmals für die Unterstützung. War mir tatsächlich nicht sicher ob das beim Slave vielleicht so gewollt ist dass die Sources deaktiviert sind.

Beste Grüße
Pascalis

In dem Logfile /var/log/univention/config-registry.replog kannst du sehen, wann diese Variable umgesetzt worden ist. Wenn dies zeitlich mit dem Update übereinstimmt, kommt man mit der Ursachenforschung schon näher :slight_smile:

Viele Grüße,
Tobias Birkefeld

Dieses Logfile geht leider auch nur bis zum 12.03.17 zurück da ich ja heute auch noch die Join Scripte habe laufen lassen.. :slight_smile:

Jetzt steh ich dummerwerise vor dem Problem dass der Slave nach der Aktualisierung bzw dem reboot die Univention Dienste nicht mehr startet.

folgendes finde ich im /var/log/univention/univention/management-console-server.log dazu:
17.03.17 11:40:46.702 MAIN ( PROCESS ) : Server started
17.03.17 11:47:45.015 DEBUG_INIT
17.03.17 11:47:48.050 MAIN ( ERROR ) : Traceback (most recent call last):
File "/usr/sbin/univention-management-console-server", line 236, in
umc_daemon.do_action()
File "/usr/lib/pymodules/python2.7/daemon/runner.py", line 186, in do_action
func(self)
File "/usr/lib/pymodules/python2.7/daemon/runner.py", line 121, in _start
self.daemon_context.open()
File "/usr/lib/pymodules/python2.7/daemon/daemon.py", line 344, in open
self.pidfile.enter()
File "/usr/lib/pymodules/python2.7/lockfile.py", line 223, in enter
self.acquire()
File "/usr/lib/pymodules/python2.7/daemon/pidlockfile.py", line 109, in acquire
super(TimeoutPIDLockFile, self).acquire(timeout, *args, **kwargs)
File "/usr/lib/pymodules/python2.7/daemon/pidlockfile.py", line 59, in acquire
super(PIDLockFile, self).acquire(*args, **kwargs)
File "/usr/lib/pymodules/python2.7/lockfile.py", line 261, in acquire
raise LockTimeout
LockTimeout

Welche Dienste müssen auf dem Slave laufen damit dieser wie Angedacht funktioniert?

Beste Grüße
Pascalis

Grundlegend sollte die Replikation und die UMC (und damit auch der Apache) laufen. Ich vermute das beim Update nicht alles sauber konfiguriert worden ist. Was sagt ein dpkg --audit?
Den Status einen Systems kann man mit den Befehlen aus dem SDB Artikel: How to determine the status of the system? herausfinden.

Welche Funktionen funktionieren denn genau nicht? Zugriff auf die UMC? Anmelden per SSH? LDAP-Replikation? Wenn das UCS Nagios/Icinga im Einsatz ist, wäre ein Blick auf die Standard-Checks hilfreich.

Viele Grüße,
Tobi

Dies sind die einzigen Befehle die einen Fehler liefern:

root@dc-slave:~# smbclient -UAdministrator //$(ucr get hostname)/sysvol -c quit
WARNING: The "syslog" option is deprecated
Enter Administrator's password:
Connection to dc-slave failed (Error NT_STATUS_CONNECTION_REFUSED)
root@dc-slave:~# grep "oom\|segfault" /var/log/syslog
Mar 17 09:39:45 dc-slave kernel: [323191.383679] univention-dire[16806]: segfault at 18 ip 00007f2e88a7ed75 sp 00007ffedc9789a0 error 4 in libpython2.7.so.1.0[7f2e88949000+284000]
root@dc-slave:~#

Alles andere geht problemlos (dpkg -audit liefert keine errors, kinit und klist funktionieren wie gehabt)
SSH Verbindung funktioniert problemlos, web management interface lässt sich jedoch nicht aufrufen mit dem Error dc-slave.twt.intern unexpectedly closed the connection.

Also LDAP und SSH funktionstüchtig, UMC nicht. Weiterer reboot liefert keine Lösung. Nagios/Icinga wird leider nicht eingesetzt.

Grade noch das hier ausprobiert:

root@dc-slave:~# samba-tool drs showrepl
ldb: unable to stat module /usr/lib/x86_64-linux-gnu/samba/ldb : No such file or directory
ERROR(<class 'samba.drs_utils.drsException'>): DRS connection to dc-slave. failed - drsException: DRS connection to dc-slave. failed: (-1073741772, 'The object name is not found.')
  File "/usr/lib/python2.7/dist-packages/samba/netcmd/drs.py", line 41, in drsuapi_connect
    (ctx.drsuapi, ctx.drsuapi_handle, ctx.bind_supported_extensions) = drs_utils.drsuapi_connect(ctx.server, ctx.lp, ctx.creds)
  File "/usr/lib/python2.7/dist-packages/samba/drs_utils.py", line 54, in drsuapi_connect
    raise drsException("DRS connection to %s failed: %s" % (server, e))

Beste Grüße
Pascalis

Wenn kein Samba4 (bzw kein "Active Directory-kompatibler Domänencontroller") auf dem Slave installiert ist, sind die beiden Fehler hinfällig.

Für die UMC gibt es mehrere Logfiles, die Informationen über den möglichen Fehler geben:

/var/log/univention/management-console-server.log
/var/log/univention/management-console-web-server.log

Ggf sind auch unter var/log/apache2 Infos zu möglichen Fehlern zu finden.

Laufen auch die Dienste für die UMC?

univention-management-console-web-server
univention-management-console-server

Ggf diese einmal durchstarten:

service univention-management-console-server restart && service univention-management-console-web-server restart

Viele Grüße,
Tobi

#########

Hab jetzt soweit alles durchprobiert.

Sowohl
/var/log/univention/management-console-server.log
/var/log/univention/management-console-web-server.log

als auch /var/log/apache2/error.log sind frei von fehlern.

Alle dienste laufen aber UMC ist weiterhin nicht erreichbar. Was merkwürdig ist:
in /var/log/apache2/access.log werden keine zugriffe mehr verzeichnet obwohl ich versuche die Seite aufzurufen.

Vielleicht werd ich den Slave Montag mal neu aufsetzen bevor ich noch mehr Zeit ins debugging investiere.

EDIT: Tja da war ich wohl schon mit dem Gedanken beim Wochenende.
Siehe da, apache ist garnich gestartet bzw lässt sich nicht starten wegen eines Zertifikatfehlers:

[....] Starting web server: apache2Syntax error on line 20 of /etc/apache2/sites-enabled/default-ssl:
SSLCertificateFile: file '/tmp/tmp.58C5MFGq3R' does not exist or is empty
Action 'start' failed.
The Apache error log may have more information.

geht man also in /etc/apache2/sites-enables/default-ssl und trägt dort statt des /tmp/tmp.58C5MFGq3R das richtige zertifikat ein geht's auch wieder..

Danke dir nochmals und ein schönes Wochenende wünsche ich!

Beste Grüße
Pascalis

1 Like

Hallo Pascalis,

bitte nicht direkt in der Datei /etc/apache2/sites-enabled/default-ssl editieren. Diese Datei wird aus einem Template generiert. Änderungen in dieser Datei werden durch eine Änderung an bestimmten UCR Variablen oder einem ucr commit /etc/apache2/sites-enabled/default-ssl überschrieben.
Ich vermute, dass die UCR Variable apache2/ssl/certificate bei dir gesetzt ist. In einer Standard-Installation sollten die Variablen wie folgt nicht gesetzt sein (außer du hast irgendetwas für deine Umgebung angepasst, eigenes Zertifikat, o.ä.):

root@ucsmaster:~# ucr search --brief apache2/ssl
apache2/ssl/ca: <empty>
apache2/ssl/certificate: <empty>
apache2/ssl/certificatechain: <empty>
apache2/ssl/ciphersuite: <empty>
apache2/ssl/compression: <empty>
apache2/ssl/honorcipherorder: <empty>
apache2/ssl/key: <empty>
apache2/ssl/tlsv11: <empty>
apache2/ssl/tlsv12: <empty>
apache2/ssl/v3: <empty>

Wenn bei dir eine Variable gesetzt ist und du dir sicher bist, dass es nicht von dir oder einer installierten Applikation kommt, kannst du z.B. mit ucr unset apache2/ssl/certificate die Variable für apache2/ssl/certificate “löschen”.
Wenn nicht, könntest du mit einem ucr commit /etc/apache2/sites-available/* alle Konfigurationsdateien für die Apache-Sites aus den Templates neu erstellen lassen.

Viele Grüße,
Tobi

Mastodon