Sieht so aus:
root@sv1:~# nslookup sv1
Server: 192.168.178.100
Address: 192.168.178.100#53
Name: sv1.familie-hein.intranet
Address: 192.168.178.100
root@sv1:~# nslookup pcbuero
Server: 192.168.178.100
Address: 192.168.178.100#53
Name: pcbuero.familie-hein.intranet
Address: 192.168.178.104
Funktioniert es denn mit dem LDAP-Backend?
ucr set dns/backend='ldap'
systemctl restart univention-bind
Ich glaube nicht.
root@sv1:/var/log/univention# ucr set dns/backend=‘ldap’
Setting dns/backend
root@sv1:~# systemctl restart univention-bind
Failed to get D-Bus connection: Unbekannter Fehler -1
Dann bitte wieder auf “samba4” umstellen.
Der Zugriff auf den openLDAP funktioniert dann wahrscheinlich auch nicht?
univention-ldapsearch cn=ucs-sso
Vermutlich muüssen wir uns erstmal dem Connector zuwenden.
Das is das Ergebnis des Kommandos:
root@sv1:~# univention-ldapsearch cn=ucs-sso
# extended LDIF
#
# LDAPv3
# base <dc=familie-hein,dc=intranet> (default) with scope subtree
# filter: cn=ucs-sso
# requesting: ALL
#
# search result
search: 3
result: 0 Success
# numResponses: 1
Wie funktioniert das Umstellen auf Samba4?
Was ist der Connector?
Sorry der Befehl war falsch kopiert. Richtig ist
univention-ldapsearch relativeDomainName=ucs-sso
Umstellen geht so:
ucr set dns/backend='samba4'
systemctl restart univention-bind
Das ist dei Ausgabe des ersten Kommandos:
root@sv1:~# univention-ldapsearch relativeDomainName=ucs-sso
# extended LDIF
#
# LDAPv3
# base <dc=familie-hein,dc=intranet> (default) with scope subtree
# filter: relativeDomainName=ucs-sso
# requesting: ALL
#
# ucs-sso, familie-hein.intranet, dns, familie-hein.intranet
dn: relativeDomainName=ucs-sso,zoneName=familie-hein.intranet,cn=dns,dc=famili
e-hein,dc=intranet
aRecord: 192.168.178.100
objectClass: top
objectClass: dNSZone
objectClass: univentionObject
univentionObjectType: dns/host_record
dNSTTL: 80600
relativeDomainName: ucs-sso
zoneName: familie-hein.intranet
# search result
search: 3
result: 0 Success
# numResponses: 2
# numEntries: 1
Das Umstellen auf samba4 funktioniert leider auch nicht:
root@sv1:~# ucr set dns/backend='samba4'
Setting dns/backend
root@sv1:~# systemctl restart univention-bind
Failed to get D-Bus connection: Unbekannter Fehler -1
Sehr seltsam. Gibt es den Eintrag eigentlich auch im Samba 4?
univention-s4search DC=ucs-sso
Gibt es irgendwelche Rejects?
univention-s4connector-list-rejected
Gibt es weitere Logs bezüglich Bind? Nach dem Befehl im seperaten Terminal noch mal Bind neustarten
journalctl -xef
Hier sind die Ergebisse der Ausgabe:
root@sv1:~# univention-s4search DC=ucs-sso
# Referral
ref: ldap://familie-hein.intranet/CN=Configuration,DC=familie-hein,DC=intranet
# Referral
ref: ldap://familie-hein.intranet/DC=DomainDnsZones,DC=familie-hein,DC=intranet
# Referral
ref: ldap://familie-hein.intranet/DC=ForestDnsZones,DC=familie-hein,DC=intranet
# returned 3 records
# 0 entries
# 3 referrals
root@sv1:~# univention-s4connector-list-rejected
UCS rejected
S4 rejected
There may be no rejected DNs if the connector is in progress, to be
sure stop the connector before running this script.
last synced USN: 11693
Das Ausführen des Befehls in einem separatem Fenster ‘systemctl restart univention-bind’ führt zu folgendem (keinem) Ergebniss:
root@sv1:~# journalctl -xef
No journal files were found.
^C
Journald wird also nicht verwendet. Dann probier es stattdessen mal mit
tail -f /var/log/syslog
Der syslog zeigt folgedes an:
root@sv1:~# tail -f /var/log/syslog
Jul 11 09:17:02 sv1 CRON[14818]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jul 11 09:20:01 sv1 CRON[14918]: (root) CMD (/usr/sbin/jitter 60 /usr/share/univention-samba4/scripts/sysvol-sync.sh >>/var/log/univention/sysvol-sync.log 2>&1)
Jul 11 09:20:01 sv1 CRON[14925]: (root) CMD (/usr/share/univention-ssl/ssl-sync >>/var/log/univention/ssl-sync.log 2>&1)
Jul 11 09:20:01 sv1 CRON[14930]: (root) CMD (if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg.cfg ] && [ -d "$(grep '^[[:space:]]*[^#]*[[:space:]]*WorkDir' /etc/mrtg.cfg | awk '{ print $NF }')" ]; then mkdir -p /var/log/mrtg ; env LANG=C /usr/bin/mrtg /etc/mrtg.cfg 2>&1 | tee -a /var/log/mrtg/mrtg.log ; fi)
Jul 11 09:20:01 sv1 CRON[14942]: (root) CMD ( if [ -x /usr/sbin/univention-umount-homedirs ]; then /usr/sbin/univention-umount-homedirs; fi)
Jul 11 09:25:02 sv1 CRON[15021]: (root) CMD (/usr/sbin/jitter 60 /usr/share/univention-samba4/scripts/sysvol-sync.sh >>/var/log/univention/sysvol-sync.log 2>&1)
Jul 11 09:25:02 sv1 CRON[15035]: (root) CMD (if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg.cfg ] && [ -d "$(grep '^[[:space:]]*[^#]*[[:space:]]*WorkDir' /etc/mrtg.cfg | awk '{ print $NF }')" ]; then mkdir -p /var/log/mrtg ; env LANG=C /usr/bin/mrtg /etc/mrtg.cfg 2>&1 | tee -a /var/log/mrtg/mrtg.log ; fi)
Jul 11 09:28:15 sv1 dhcpd: LDAP server was down, trying to reconnect...
Jul 11 09:28:15 sv1 dhcpd: DHCPREQUEST for 192.168.178.24 from e4:b3:18:51:ba:49 via eth0: unknown lease 192.168.178.24.
Jul 11 09:28:19 sv1 dhcpd: DHCPREQUEST for 192.168.178.24 from e4:b3:18:51:ba:49 via eth0: unknown lease 192.168.178.24.
Jul 11 09:30:02 sv1 CRON[15264]: (root) CMD (if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg.cfg ] && [ -d "$(grep '^[[:space:]]*[^#]*[[:space:]]*WorkDir' /etc/mrtg.cfg | awk '{ print $NF }')" ]; then mkdir -p /var/log/mrtg ; env LANG=C /usr/bin/mrtg /etc/mrtg.cfg 2>&1 | tee -a /var/log/mrtg/mrtg.log ; fi)
Jul 11 09:30:02 sv1 CRON[15274]: (root) CMD ([ -x /usr/sbin/univention-system-stats ] && /usr/sbin/univention-system-stats >/dev/null)
Jul 11 09:30:02 sv1 CRON[15310]: (root) CMD ( if [ -x /usr/sbin/univention-umount-homedirs ]; then /usr/sbin/univention-umount-homedirs; fi)
Jul 11 09:30:02 sv1 rsyslogd-2007: action 'action 17' suspended, next retry is Tue Jul 11 09:30:32 2017 [try http://www.rsyslog.com/e/2007 ]
Jul 11 09:30:02 sv1 CRON[15312]: (root) CMD ( [ -x /usr/lib/univention-pam/ldap-group-to-file.py ] && /usr/lib/univention-pam/ldap-group-to-file.py --check_member)
Jul 11 09:30:02 sv1 CRON[15320]: (root) CMD (/usr/sbin/jitter 60 /usr/share/univention-samba4/scripts/sysvol-sync.sh >>/var/log/univention/sysvol-sync.log 2>&1)
Jul 11 09:30:02 sv1 CRON[15323]: (root) CMD (/usr/sbin/univention-mrtg)
Beim Ausführen des Kommandos im extra Fenster kommt folgendes:
root@sv1:~# systemctl restart univention-bind
Failed to get D-Bus connection: Unbekannter Fehler -1
Aber von dem Kommando ist im syslog nichts zu sehen.
Hallo,
gibt es noch eine Lösung für mein Problem?
Hat jemand eine andere Idee? Backup der Daten und der AD-Konfiguration mit anschließender Neuinstallation?
Ich bin für jede Unterstützung dankbar.
Viele Grüße
Uwe
Hallo uhbi,
das hier:
hört sich ganz stark nach einem Fehler bei Systemd an. Nur weiss ich gar nicht, ob der bei dir genutzt wird ?
Gibt denn folgender Befehl irgendwelche Infos ?
systemctl --state=failed
Ich kann mich entfernt daran erinnern, das ich vor langer Zeit mal ähnliche Probleme mit Debian auf einem
Laptop hatte. Ich meine auch, das nach langer Suche ich dann zu dem Schluss gekommen bin, doch alles nochmal neu
zu installieren.
Viele Grüße
Oliver
Hallo Oliver,
der Befehl gibt auch nur einen Fehler zurück:
root@sv1:~# systemctl --state=failed
Failed to get D-Bus connection: Unbekannter Fehler -1
Besteht noch eine Chance das System wieder ans Laufen zu bringen?
Viele Grüße
UweHallo Uwe,
was sagt denn:
ps -p 1 -o comm=
Ich würde, bevor ich jetzt anfange, in den Eingeweiden des Realsystems auf Fehlersuche zu gehen, vom Server ein Image ziehen und dieses in einer virtuellen Maschine booten.
Und die Änderungen/ Reparaturversuche am System in dieser virtuellen Maschine vornehmen.
Ich vermute mal, das ist aber nur ein Verdacht, das beim UpDate von 4.1 auf 4.2 init durch systemd ersetzt wird und das hierbei irgendetwas schief gelaufen ist.
Vielleicht weiss Univention hier mehr ?
Ich habe selber meine Server noch unter 4.1 am laufen und bin dabei, mir zu überlegen, wie ich diese update, ohne grössere Probleme und downtimes zu bekommen ^^
Viele Grüße,
Oliver
Hallo Oliver,
das ist die Ausgabe des Kommandos:
root@sv1:~# ps -p 1 -o comm=
init
Ich habe nur das eine Sytem als Server und AD-Kontroller für mein Heimnetz in Betrieb… Nach dem Update funktionieren die vorhandenen Computer und Laufwerksfreigaben weiter. Nur kann ich das System nicht mehr warten.
Mit wäre sehr daran gelegen, das das System wieder funktioniert. Für deinem Vorschlag mit der VM habe ich keine Hardware und auch zuwenig Wissen.
Viele Grüße
Uwe
MoinMoin Uwe,
bei dir läuft init mit der Prozessnummer 1, quasi der “Vater aller Prozesse” 
Der Befehl systemctl gehört, soweit ich das weiss, aber zu systemd. Systemd soll eigentlich als Ersatz
für init dienen. Anscheinend scheinen jetzt irgendwie beide bei dir zu laufen, bzw. eigentlich nicht ^^
Einige Funktionen scheinen über systemctl gestartet zu werden, die allerdings ins leere laufen, da systemd
ja nicht als “Vater” eingetragen ist.
Der erste Prozess wird eigentlich vom gebooteten Kernel gestartet (man möge mich bitte korrigieren, falls ich hier
irre).
Von welcher Version hast du eigentlich upgedatet ? Ich vermute mal 4.1 ?
Gab es da irgendwelche Probleme ?
Wenn Du deinen Server bootest, kannst du auch ältere Kernel auswählen.
Hast Du das schonmal probiert?
Viel grüße
Oliver
Hallo Oliver,
ich habe bisher noch keine Zeit gehabt einen anderen Kernel zu booten. Das Update war jeden falls von eine 3.x Version. Das Update ist durchgelaufen, mir fehlte lediglich die Konfigurationsoberfläche. Ich melede mich Anfang nächster Woche nochmal. Danke für die Unterstützung.
Viele Grüße
Uwe
Hallo Oliver,
ich habe es endlich geschaft einen anderen Kernel zu booten. Folgende habe ich zu Auswahl:
Univention Corporate Server, with Linux 4.9.0-ucs104-amd64
Univention Corporate Server, with Linux 4.9.0-ucs104-amd64 (sysinit)
Univention Corporate Server, with Linux 4.9.0-ucs104-amd64 (recovery mode
Univention Corporate Server, with Linux 4.1.0-ucs207-amd64
Univention Corporate Server, with Linux 4.1.0-ucs207-amd64 (sysinit)
Univention Corporate Server, with Linux 4.1.0-ucs207-amd64 (recovery mode
Univention Corporate Server, with Linux 3.16-ucs109-amd64
Univention Corporate Server, with Linux 3.16-ucs109-amd64 (sysinit)
Univention Corporate Server, with Linux 3.16-ucs109-amd64 (recovery mode
Univention Corporate Server, with Linux 3.16-ucs102-amd64
Univention Corporate Server, with Linux 3.16-ucs102-amd64 (sysinit)
Univention Corporate Server, with Linux 3.16-ucs102-amd64 (recovery mode
Mein Problem tritt mit verschieden Kernelversionen mit dem Zusatz (sysinit) auf. Die Variante ohne Zusatz bootet nur teilweise
A start job is running for dev-disk-by\x2duu …
nach Ablauf der Wartezeit von 1:30 Minuten lande ich hier:
Wecome to the emergency mode! After logging in type “journalctl -xb” to view
systemlogs, “systemctl rebbot” to reboot, “systemctl default” to try again
to boot into default mode.
Give root password for maintenance
(or type Control-D to continue):
Die betroffene Partion ist /home. Beim booten mit dem Kernel …(sysinit) startet das System. Der Zugriff auf die Samba-Laufwerksfreigaben (auch /home) für die Windowsrechner und die Benutzerauthentifizeirung funktionieren, nur die Administartionsoberfläche fehlt.
Ich hoffe diese Infos helfen weiter um dem Problem auf die Spur zu kommen und es zu beseitigen.
Danke für die Unterstützung und viele Grüße
Uwe
Moin,
als erstes sollten wir dafür sorgen, dass der Server wieder mit systemd booten kann (also einer der Kernel ohne Zusatz in Klammern hinten). Was passiert, ist dass systemd eine zu mountende Partition in /etc/fstab sieht, aber die Gerätedatei dafür die nicht zu finden ist. Das kann verschiedenste Ursachen haben: der Eintrag ist alt und gehört eigentlich gelöscht; die Partition gibt es zwar aber in der initrd fehlen Treiber für das Gerät oder Dateisystem; es gibt einen Schreibfehler in /etc/fstab.
Um das erst mal zu umgehen, sollten Sie die Zeile in der /etc/fstab mit der betroffenen Partition schlicht auskommentieren oder in den Optionen nofail hinzufügen, also z.B. so:
UUID=4177-0815-… /home ext4 default,nofail 0 0
Das nofail markiert, dass das Mounten der Partition für den Boot-Prozess nicht als kritisch anzusehen ist.
Die Datei sollten Sie im »maintenance mode« ändern können; andernfalls von einer x-beliebigen Rescue-CD wie grml starten, root-Partition mounten, editieren, Reboot.
Wenn der Server anschließend wieder oben ist, so posten Sie bitte die Ausgaben von cat /etc/fstab sowie blkid, damit wir sehen können, welche Partitionen mit welchen UUIDs dem Kernel bekannt sind, und welche benötigt werden.
Gruß,
mosu