Ja, wirklich. Die IPs laufen hier im 172.16.1.0/24 Netz seit Beginn problemlos…
Nein, nicht aktiv. Mir ist wie gesagt nur aufgefallen, dass beim ssh-login plötzlich „Das System muss neu gestartet werden“ auftauchte. Das hat man ja normalerweise nur nach einem Kernel-Update. Ich habe das nicht näher kontrolliert und dachte das vielleicht ein cron-job ein update gemacht hat. Ein cron.monthly hätte ja z.B. vom Datum her gepasst, ist aber leer. Nur ein placeholder drin…
Alles wie gehabt:
Server steht auf UTC (korrekte Zeit)
Linbo meckern nun nicht mehr und die Zeit von Linbo ist ebenfalls (nach wie vor) UTC.
Allerdings meckert nun Linbo auf den Clients beim hochfahren wieder rum.
Diesmal konnte ich mir die exakte Fehlermeldung merken:
ntpd: reply from 172.16.1.1: peer is unsynced|
Die Linbo Zeit stimmt aber noch immer
das sit nicht schlimm: das bedeutet, dass auf dem server der ntp.service
nicht läuft: der wird bei mir auch aus irgend einem Grund nciht oder
nicht richtig gestartet beim reboot.
Was sagt den
systemctl status ntp.service
falls da „dead“ oder sowas steht, starte ihn und kontrollier nochmal
Der Service läuft, das hatte ich zwischenzeitlich auch schon gecheckt.
UPDATE:
Warum aus immer… Domänenlogin vom Win 10 Client aus läuft wieder!
Ich habe nix gemacht außer 2x den Server neu zu starten
Linux nach wie vor auf allen Rechnern keine Domänenanmeldung möglich
Vermischen sich hier vielleicht zwei Probleme? Es gibt ja seit zwei Tagen den Thread mit den alternierenden OS-Starts, wo sich die Linux-Clients nicht mehr anmelden können sobald ein Login von Windoze aus erfolgt ist.
Einen Linux-Client habe ich gerade gesynct… immer noch kein Login möglich…
Linux nach wie vor auf allen Rechnern keine Domänenanmeldung möglich
Vermischen sich hier vielleicht zwei Probleme? Es gibt ja seit zwei
Tagen den Thread mit den alternierenden OS-Starts, wo sich die
Linux-Clients nicht mehr anmelden können sobald ein Login von Windoze
aus erfolgt ist.
Einen Linux-Client habe ich gerade gesynct… immer noch kein Login möglich…
zuerst schaut man, ob auf dem Client der Rechnername stimmt in der
/etc/hosts Datei.
Dann kontrolliert man die Systemzeit.
Hallo zusammen,
ich hab mir mal die Logs bei unsynchronisierten Starts angesehen:
Win10:
### rsync pre download begin: Mi 1. Jul 16:11:32 CEST 2020 ###
HOSTNAME: lc-r01.linuxmuster.lan
IP: 10.16.100.1
RSYNC_REQUEST: linbo/win10.cloop.macct
FILE: /srv/linbo/win10.cloop.macct
PIDFILE: /tmp/rsync.4232
EXT: .macct
Machine account ldif file: /srv/linbo/win10.cloop.macct
Host: lc-r01
DN: CN=LC-R01,CN=Computers,DC=linuxmuster,DC=lan
Modified CN=LC-R01,CN=Computers,DC=linuxmuster,DC=lan
Modified 1 records successfully
RC:
### rsync pre download end: Mi 1. Jul 16:11:33 CEST 2020 ###
### rsync pre download begin: Mi 1. Jul 16:11:33 CEST 2020 ###
HOSTNAME: lc-r01.linuxmuster.lan
IP: 10.16.100.1
RSYNC_REQUEST: linbo/tmp/lc-r01_linbo.log
FILE: /srv/linbo/tmp/lc-r01_linbo.log
PIDFILE: /tmp/rsync.4266
EXT: .log
Upload request for lc-r01_linbo.log.
linbo.log
sent 43 bytes received 23,454 bytes 46,994.00 bytes/sec
total size is 23,367 speedup is 0.99
RC:
### rsync pre download end: Mi 1. Jul 16:11:33 CEST 2020 ###
Linux:
### rsync pre download begin: Mi 1. Jul 16:09:35 CEST 2020 ###
HOSTNAME: lc-r01.linuxmuster.lan
IP: 10.16.100.1
RSYNC_REQUEST: linbo/ubuntu1804.cloop.macct
FILE: /srv/linbo/ubuntu1804.cloop.macct
PIDFILE: /tmp/rsync.3263
EXT: .macct
Machine account ldif file: /srv/linbo/ubuntu1804.cloop.macct
Host: lc-r01
DN: CN=LC-R01,CN=Computers,DC=linuxmuster,DC=lan
Modified CN=LC-R01,CN=Computers,DC=linuxmuster,DC=lan
Modified 1 records successfully
RC:
### rsync pre download end: Mi 1. Jul 16:09:36 CEST 2020 ###
### rsync pre download begin: Mi 1. Jul 16:09:36 CEST 2020 ###
HOSTNAME: lc-r01.linuxmuster.lan
IP: 10.16.100.1
RSYNC_REQUEST: linbo/tmp/lc-r01_linbo.log
FILE: /srv/linbo/tmp/lc-r01_linbo.log
PIDFILE: /tmp/rsync.3297
EXT: .log
Upload request for lc-r01_linbo.log.
linbo.log
sent 43 bytes received 21,883 bytes 43,852.00 bytes/sec
total size is 21,796 speedup is 0.99
RC:
### rsync pre download end: Mi 1. Jul 16:09:36 CEST 2020 ###
Die sehen ziemlich gleich aus.
Und so wie ich das sehe, wird bei jedem Start der Maschinen Access Token an den AD übertragen
Leider reichen meine Kenntnisse nicht aus, um zu checken, ob der MACCT beim AD richtig angekommen ist.
Vielleicht kennt sich da ja jemand etwas besser als ich aus
Gruß,
Mathias
sieht eigentlich gut aus.
Nach dem
AAAAAHAKAAAAAAAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAUAAEADYAVAMBAFAAcgBpAG0AYQByAHkA
cat /etc/hosts
# /etc/hosts
# Diese Datei wird per postsync gepatcht.
# Pfad: ${linbodir}/${postsyncdir}/${patchclass}/common/etc/hosts -> /mnt/etc/hosts in LINBO
########## DO NOT EDIT START
# PC09 wird im Postsyncskript mit dem echten Namen gepatcht
127.0.0.1 localhost
127.0.0.1 PC09.linuxmuster.lan PC09
#Die nächste Zeile enthält die Hostnamen so, wie sie auf dem Server eingetragen sind...
172.16.1.1 server.linuxmuster.lan server
## damit CUPS zufrieden ist, muss noch diese Zeile hier dazu:
172.16.1.1 server.lokal server.local
########## DO NOT EDIT END
Wie kann man auf der Konsole den MACCT an den AD schicken? Da gäbe es entweder interessante Fehlermeldungen oder der Linuxclient könnte sich anmelden oder …
Das könnte uns dem Problem ein bisschen näher bringen…
Ich habe mir gerade ebenfalls die Log-Datei rsync-pre-download.log angesehen und bin auf einen Fehler gestoßen:
### rsync pre download begin: Do 2. Jul 06:38:45 UTC 2020 ###
HOSTNAME: pc12.linuxmuster.lan
IP: 172.16.1.32
RSYNC_REQUEST: linbo/tmp/PC12_linbo.log
FILE: /srv/linbo/tmp/PC12_linbo.log
PIDFILE: /tmp/rsync.23936
EXT: .log
Upload request for PC12_linbo.log.
rsync: change_dir "/srv/linbo/tmp" failed: No such file or directory (2)
sent 8 bytes received 84 bytes 184.00 bytes/sec
total size is 0 speedup is 0.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1668) [Receiver=3.1.2]
rsync: [Receiver] write error: Broken pipe (32)
RC:
### rsync pre download end: Do 2. Jul 06:38:46 UTC 2020 ###
Es scheint als würde das Verzeichnis /srv/linbo/tmp fehlen
Hallo zusammen,
weiß jemand, wo das Maschinenpasswort oder MACCT im LDAP-Baum von Samba steht?
Unter CN=LC-R01,CN=Computers,DC=linuxmuster,DC=lan hab ich’s nicht gefunden.
Gruß,
Mathias
ich hab jetzt noch ein paar Versuche gemacht und möchte die Ergebnisse hier schreiben. In meinen Augen ergeben sich hier ein paar neue Fragen.
Vorgehen:
Ich habe auf dem Linux-Client 1 (lmn-bionic-200507) die Datei /etc/kbr5.keytab und auf dem Server die Datei lmn-bionic-200507.cloop.macct gelöscht.
Dann linuxmuster-client-adsso-setup ausgeführt, ein neues Image erzeugt und hochgeladen und anschließend die Linux-Clients synchronisiert gestartet.
Die Anmeldung lief auf allen (zwei) Clients
Jetzt habe ich auf dem Client 1 Windows gestartet. Ich habe mich nicht angemeldet.
Auf dem anderen Client 2 war ich noch unter Linux angemeldet. Plötzlich hat mir Firefox den Proxy-Anmeldedialog gezeigt.
Nach dem Abmelden konnte ich mich nicht mehr anmelden.
Auf dem Client 1, auf dem Windows gestartet wurde lief alles.
Nach einem Neustart mit Linux war auch dort ein Anmelden nicht mehr möglich.
Auch nach einem synchronisierten Start kann man sich in Linux nicht mehr anmelden.
Da stellen sich folgende Fragen:
Wie kann sich ein MACCT, der beim Start von Windows auf Client 1 auf den AD kopiert wird, auf den Client 2 auswirken?
Für welche Clients wird das MACCT auf den AD kopiert?
Was mich interessieren würde:
Bei wem laufen Clients mit Linux und Windows ohne diese Problem? Bitte schreibt, wie ihr das gemacht habt.
Bei wem läufts auch nicht?
Holger, du hast geschrieben, dass bei dir alles läuft. Wie bist du vorgegangen? Weist du das noch oder ist es schon sehr lange her?
Ich möchte mich bereits jetzt für eure Antworten bedanken.
ich habe heute im Seminar mit meinem Netzwerkerkurs mit meiner
Schulungsumgebung gearbeitet.
Die war vor ein paar MOnaten noch mit 4 Clients bestückt: 2 Windows only
und zwei ubuntu only.
Nach meinen Tests bei der Mitgliederversammlung dieses Jahr hab ich sie
umgestellt: dazu habe ich die beiden ubuntuclients weggeworfen und ide
start.confs der winclients um weitere Parititonen erweitert und das
ubuntu dazu geklont.
Nun weiß ich nicht mehr, ob ich danach mit dem ubuntu nochmal beitreten
musste oder nicht, aber ich kann sagen; das funktioniert seit Monaten so.
Jetzt mach doch mal folgendes:
nenn einen Client in der devices.csv um: er soll einen Namen
bekommen, den es noch ie in deiner lmn gab: nenn ihn karlspc01
lösch alle Partitionen auf dem Client, bevor du linbo startest.
partitionier ihn mit linbo und spiel windows zurück.
Anmelden geht? wenn ja ->
spiel das ubuntu Image zurück
Anmelden geht? falls ja: andere Clients testen, falls nein->
lokal die /etc/kbr5key.tab dingens löschen und nochmal
linuxmuster-client-adsso laufen lassen
auf dem server die linuximage.cloop.macct Datei löschen oder wegbewegen
Image erstellen
Image auf dem Client zurückspielen
an dem Client anmelden: wenns geht: auf anderen clients testen.
ich habe die Clients von lc-rxx in test-rxx umbenannt habe und die Festplatten gelöscht und durch neue Festplatten resetzt habe bin ich wie folgt vorgegangen:
Festplatte mit linbo partitioniert und Neustart.
Formatiert partitioniert und windows synchronisiert gestartet.
Anmeldung hat geklappt.
Linux gesynct gestartet
Anmeldung hat nicht geklappt
Als linuxadmin kbr5.keytab gelöscht und linuxmuster-client-adsso laufen gelassen.
Auf dem Server die .macct-Datei gelöscht.
Image erstellt.
Linux synchronisiert gestartet
Anmeldung ging
Windows gestartet.
Anmeldung ging
Linux gestartet.
Anmeldung ging nicht
Dann habe ich ein ganz neues System aus den ova-Dateien aufgesetzt:
Auf einem Client ein Windows aufgesetzt und in die Domäne eingebunden.
Anmeldung ging,
Auf dem Client einen linuxclient aufgespielt.
Anmeldung ging
Windows gestartet.
Anmeldung ging.
Linux gestartet.
Keine Anmeldung
Linux synchronisiert gestartet.
Keine Anmeldung
Es ist mir ein Rätsel, wie du das mit dem Dualboot gemacht hast.
Hast du an Linbo etwas geändert?
In meinen Augen funktioniert das Übertragen des MACCT auf den AD nicht bei Linux.
Übrigens:
Beim Runterladen des Linux-Clients mit dem linuxmuster-client-servertools musste ich das Volume für /var/cache vergrößern, da sonst /var/cache voll läuft.
Bei mir ebenfalls. Ich habe schon zig mal das Linux neu aufgespielt, da ich immer davon ausgegangen bin das ich einen Fehler mache…
Diesen Umstand habe ich bereits gemeldet. Das ist eine unschöne Falle wenn man (wie ich) nicht damit rechnet, dass die Partitionsgröße noch nicht einmal für ein Cloop reicht.
