Hallo zusammen,
in den Logfiles steht nichts komisches, außer dass immer UNKNOWN.lender.schule dasteht.
Das ist vermutlich nicht normal, oder?
Eine macct datei kommt nicht vor.
Log auf von Linbo
Upload of bionic64.cloop was successful.
HOSTNAME: UNKNOWN.lender.schule
FILE: /srv/linbo/bionic64.cloop.info
PIDFILE: /tmp/rsync.26858
BACKUP: /srv/linbo/bionic64.cloop.info.BAK
FTYPE: .info
Upload of bionic64.cloop.info was successful.
HOSTNAME: UNKNOWN.lender.schule
FILE: /srv/linbo/bionic64.cloop.torrent
PIDFILE: /tmp/rsync.26936
BACKUP: /srv/linbo/bionic64.cloop.torrent.BAK
FTYPE: .torrent
Upload of bionic64.cloop.torrent was successful.
HOSTNAME: UNKNOWN.lender.schule
FILE: /srv/linbo/bionic64.cloop.desc
PIDFILE: /tmp/rsync.26901
BACKUP: /srv/linbo/bionic64.cloop.desc.BAK
FTYPE: .desc
Upload of bionic64.cloop.desc was successful.
umbenannt ‚/srv/linbo/bionic64.cloop.BAK‘ -> ‚/srv/linbo/bionic64-2019-09-01-1117.cloop‘
Archive file bionic64-2019-09-01-1117.cloop created.
Image file bionic64.cloop detected. Restarting multicast service if enabled.
umbenannt ‚/srv/linbo/bionic64.cloop.torrent.BAK‘ -> ‚/srv/linbo/bionic64-2019-09-01-1117.cloop.torrent‘
Archive file bionic64-2019-09-01-1117.cloop.torrent created.
Torrent file bionic64.cloop.torrent detected. Restarting bittorrent service.
umbenannt ‚/srv/linbo/bionic64.cloop.info.BAK‘ -> ‚/srv/linbo/bionic64-2019-09-01-1117.cloop.info‘
Archive file bionic64-2019-09-01-1117.cloop.info created.
RC: 0
rsync post upload end: So 1. Sep 11:17:36 CEST 2019
erstelle mal ein Image und schau dann in die logs von linbo…vielleicht
liefert das irgendwas brauchbares. Die Datei muss auch in der lmn7
erzeugt werden. Wo genau der Fehler liegt kann ich nicht
sagen…vielleicht kennen andere hier das Problem!?
vielleciht wird sie schon erzeugt, aber nicht hochgeladen.
Mal mit
ls -al
auf die Cachpartition schauen …
Was auch helfen könnte:
alle .cloop.* Dateien und das cloop selbst im Clientcache
löschen und dann noch mal ein Image erstellen.
Ist die macct Datei dann da?
nein statt UNKNOWN müsste da der Hostname des Rechners stehen. Was steht bei dem Rechner denn in der /etc/hosts?
Eigentlich patcht Linbo da den richtigen Namen nach dem Sync rein…auch ohne spezielles postsync Skript!
Irgendwas ist bei euch Faul…entweder beim Client oder im Linbo.
Setze doch mal schnell ein völlig neues Ubuntu-Mate auf, installiere die linuxmuster Pakete mache ein Image und schau ob da dann alles klappt…wenn ja weißt du das bei eurem Client was verbastelt ist und kannst nach Unzetschieden suchen…das würde ich jetzt tun…
das Problem tritt ja auch nun mit dem heruntergeladenem Image auf. Auch dort ist nach dem ersten Image schreiben (linuxmuster-client-adsso-setup gemacht) keine macct Datei vorhanden.
Ich habe ja die ganzen alten Images noch, das ist nie eine macct dabei.
Das kann dann nicht am Clienten liegen.
Übrigens steht, wenn linbo läuft in hostname das richtige drin.
In den linbo-logs habe ich auch mal in die ältesten logs (nach Aufsetzen des LMN7) gesehen: Removing dummy logfile /srv/linbo/tmp/inf3-h14_linbo.log. ### rsync post download begin: Do 8. Aug 16:53:02 CEST 2019 ### HOSTNAME: UNKNOWN.lender.schule
Das ist bei jedem Gerät so, in der ersten Zeile steht der richtige Name , dann UNKNOWN…
Ich habe auch mal die Dateien im cache gelöscht und ein neues Image erzeugt -> auch keine macct Datei.
Auf dem Server ergibt journalctl|grep linbo|grep macct
Sep 01 10:59:15 hlserver.lender.schule rsyncd[22816]: rsync on linbo/bionic64.cloop.macct from UNKNOWN (10.0.15.3)
Sep 01 10:59:15 hlserver.lender.schule rsyncd[22816]: rsync: link_stat "bionic64.cloop.macct" (in linbo) failed: No such file or directory (2)
Hallo zusammen,
ich habe mal eine macct aus unseren Test noch in lmn6 auf den Server gelegt.
Dann kommt in pre download
rsync pre download begin: So 1. Sep 23:33:24 CEST 2019 ###
HOSTNAME: UNKNOWN.lender.schule
RSYNC_REQUEST: linbo/bionic64.cloop.macct
FILE: /srv/linbo/bionic64.cloop.macct
PIDFILE: /tmp/rsync.69637
EXT: .macct
Machine account ldif file: /srv/linbo/bionic64.cloop.macct
Host: unknown
Cannot determine DN of unknown! Aborting!
RC:
rsync pre download end: So 1. Sep 23:33:24 CEST 2019 ###`
und
Upload request for kvm-pc_linbo.log.
ssh: connect to host unknown.lender.schule port 2222: Network is unreachable
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: unexplained error (code 255) at io.c(235) [Receiver=3.1.2]
RC:
Es ist wohl doch ein Fehler mit dem Namen. Hat da jemand eine Idee?
Stimmt der Hostname des Masterclients denn mit dem in der devices.csv überein? Ändere mal den Rechnernamen in der devices. csv lass kinuxmuster-import-devices laufen, starte dann den Rechner synchronisiert und schau ob der neue Name in die /etc/hostname geschrieben wird. Durchsuche evtl. mal die Linbologs am Ende der Synchronisation, ob der Hostname überhaupt gepatcht wird…wenn nicht würde ich als nächstes Mal ein Postsync einrichten bei dem der Hostname gesetzt wird…siehe dazu die Doku zum universellen Postsyncscript…
Eine andere Idee habe ich gerade nicht…
Hallo zusammen,
ein Sache haben wir gestern noch gefunden.
Wenn ich ein Ping auf dem Server 10.0.0.1 mit dem Namen eines PCs machte, dann wurde dieser falsch aufgelöst. Das wurde korrigiert im DNS, das Problem bleibt aber trotzdem bestehen.
Wenn der PC in Linbo läuft, steht in hostname das Richtige (aus devices.csv) drin, auch wenn er im Mate- Betriebssystem läuft.
Journalctl gibt:
`
Sep 02 11:04:43 hlserver.lender.schule rsyncd[20222]: rsync on linbo/tmp/r308_linbo.log from UNKNOWN (10.0.103.8)
`
Unter rsyncd.conf habe ich /usr/share/linuxmuster/linbo/rsync-pre-download.sh gefunden, dort wird die Variable $RSYNC_HOST_NAME benutzt, die ja dann wohl falsch ist.
Zum Verständnis, wo läuft das Skript , auf dem PC in der Linbo-Phase (es wird vom Server geholt?) oder auf dem Server? Wie wird die Variable befüllt?
Was ich auch nicht verstehe, warum die log-Datei sogar richtig nach dem PC-Namen heißt.
Viele Grüße
Johannes
Hallo zusammen,
ich habe mal per ssh nachgesehen, während linbo läuft, sind alle Namen, IPs usw richtig gesetzt. Der Fehler entsteht dann wohl auf dem Server.
Grüße
Johannes
Leider funktioniert meine Anmeldung auf den Ubuntu 18.04-Clients auch nicht mehr.
Am 16.08.19 hat die Anmeldung noch auf allen Testrechnern funktioniert. Jetzt nach dem Urlaub, ohne irgend welche Änderungen, funktioniert die Anmeldung nicht mehr.
Ich habe auf einem Client eine Anmeldung kurzfristig wieder ermöglichen können durch linuxmuster-client-adsso-setup . Dieser Erfolg war allerdings nur von kurzer Dauer. Keine Ahnung warum.
Jedenfalls habe ich folgende Erkenntnisse gewonnen:
Die macct-Datei zu einem cloop exisitiert bei meinen Rechnern ausschließlich auf dem Server. Die Datei kann daher erst nach dem Upload des Images auf dem Server erzeugt werden. Mit dieser Datei wird dann vermutlich der AD manipuliert, damit von einem Rechner mit diesem Image eine Anmeldung an der Domäne erfolgen kann.
Wenn ich ein neues Image erzeuge, wird die macct-Datei identisch erzeugt. Eine zwischenzeitliches Ausführen von linuxmuster-client-adsso-setup ändert daran nichts. Das Ergebnis in der macct-Datei ist immer das Gleiche (auslesen mit: „# klist -kte /etc/krb5.keytab“ ).
Für den Moment bin ich ratlos, vermute aber einen Zusammenhang mit kerberos, da auf dem client klist folgendes Ergebnis liefert:
„klist: No credentials cache found (filename: /tmp/krb5cc_0)“
Nach dem Durchführen von linuxmuster-client-adsso-setup erhält man dagegen den Ticketzwischenspeicher: FILE:/tmp/krb5cc_0
dessen Tickets ein Tag gültig sind und nach einer Woche erneuert werden müssen.
„Valid starting Expires Service principal
03.09.2019 01:19:18 03.09.2019 11:19:18 krbtgt/DOMÄNE@DOMÄNE
erneuern bis 10.09.2019 01:19:10 …“
Da kerberos zeitkritsch ist, habe ich auch auf die Synchronität der Uhrzeit auf den Rechnern geachtet.
Dann habe ich noch die kerberos-key-Tabelle /etc/krb5.keytab auf dem Client gelöscht und mit linuxmuster-client-adsso-setup neu erzeugen lassen.
Leider bisher alles ohne Erfolg.
Aktuell erhalte ich auf dem client mit „#systemctl status sssd.service“ die Fehler:
„Sep 03 03:23:04 HOSTNAME sssd[1232]: response to SOA query was unsuccessful
Sep 03 03:23:04 HOSTNAME sssd[1232]: ; TSIG error with server: tsig verify failure“
ich hab jetzt den ganzen Thread nochmal durchgelesen: auf der Suche nach Inspiration.
Ich fasse mal zusammen:
Dominik hat das Problem entdeckt und mit löschen und durch linbo neu erstellter macct Datei bei sich behoben.
Bei Johannes wird die macct Datei grundsätzlich nicht erstellt
Bei Rainer wird sie erstellt, aber wohl nicht erneuert: deswegen fliegen seine Clients nach sieben Tagen wieder aus der Domäne.
Bei Johannes haben wir einen Fehler gefunden: einer der Rechnernamensauflösungsmechanismen (geiles Wort ) scheint bei ihm nicht zu funktionieren.
Ein Prozess auf dem Server scheint aber genau diesen zu verwenden, um die macct Datei zu erstellen.
Linbo scheint das anders zu lösen und der linuxclient selbst auch, weil beide den richtigen Namen kennen.
Es stellen sich also folgende Fragen:
An Rainer: wie sieht es den mit den Namen bei dir aus (siehe frühere Posts mit UNKNOWN)?
An Johannes: das Namensauflösungsgedöns hab ich noch nie ganz durchdrungen, deswegen schlage ich nun vielleicht Mist vor: aber vielleicht willst du es ja mal versuchen.
Bei Namensauflösung fällt mir der unbound auf der opnsense ein: hast du SSO auf der opnsense eingerichtet, so wie hier beschrieben?
Besonderes Augenmerk sei auf das erste Bild gerichtet, wo unter „Überbrückung“ der DNS aktualisiert wird.
Und wo wir schon bei unbound sind: es fällt auf, dass es nur bei Dominik funktioniert und er aber auch, soweit ich weiß, der einzige ist, der unbound den Zwang zu DNSSEC abgewöhnt hat … klingt doch auch mal nach was, oder?
Hallo zusammen,
mittlerweile wird die macct Datei erstellt, nach ein paar mal deviceimport ging es plötzlich.
Alle logs in Linbo sind jetzt mit den richtigen Namen. (DNS hatte nicht richtig die eigenen Rechner umgesetzt)
Interessanterweise geht auch plötzlich linuxmuster-import-devices viel schneller. Das hat bei uns immer minutenlang gedauert, plötzlich läuft es ganz schnell durch.
Gestern konnte ich dann mich anmelden, heute nicht mehr. Was mir aufgefallen ist, dass bei der macct-Datei die Rechte vielleicht falsch sind.
Sep 03 02:13:49 hlserver.lender.schule rsyncd[122780]: rsync: send_files failed to open "bionic64.cloop.macct" (in linbo): Permission denied (13)
Statt 644 muss da wohl 664 stehen, so wie für die anderen Dateien auch.
Dann wird es gemacht (macct zum Clienten)
Schaut mal bei systemctl status sssd.service , da gibt es Fehler mit dem Ticketgedöns.
Sep 03 12:39:53 test-pc [sssd[ldap_child[1289]: Failed to initialize credentials
Sep 03 12:39:53 test-pc sssd[1287]: Starting up
Sep 03 12:39:53 test-pc sssd[1288]: Starting up
Sep 03 12:39:53 test-pc systemd[1]: Started System Security Services Daemon.
Sep 03 12:41:18 test-pc [sssd[ldap_child[1463]: Failed to initialize credentials
Sep 03 12:41:18 test-pc [sssd[ldap_child[1464]: Failed to initialize credentials
Wenn ich in sssd.conf
krb5_validate=false
setze, dann kommt noch
Sep 03 12:44:58 test-pc [sssd[ldap_child[1623]: Failed to initialize
credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed
Sep 03 12:44:58 test-pc sssd[1621]: Starting up
Neulich hatte es nach dieser Änderung bei mir funktioniert.
Es ist tatsächlich wie ein hässlicher Wackelkontakt das ganze, gestern konnte ich mich nun anmelden, jetzt nicht mehr.
Könnte man als Drumherum die Lebenszeit der Tickets erhöhen, es gibt sowohl auf dem Server als auch auf dem Clienten configs dazu?
Hallo zusammen,
ich krieg die Krise, auf dem PC war jetzt die Zeit 2h voraus, Zeit gesetz->kann mich anmelden.
Ich denke dieser chrony.service erledigt das? Aber er hats falsch gesetzt.
Dann vielleicht doch ein Zusammenhang mit der Zeitkritik von Kerberos!? So a al Systemzeit auf Server und Client deutlich abweichend, weil kein NTP und/oder wegen UTC vs. MESZ!?
Nur als Schuss ins Blaue…
OK falls es ein Zeitsyncproblem ist muss man per postsync dafür sorgen, dass die Rechnerzeit (Software- und Hardwareuhr) immer beim Booten gesetzt wird.
In Ubuntu passiert das über einen Systemd-Startup-Hook in /etc/systemd/timesyncd.conf.
Standardmäßig steht da ein Ubuntu Zeitserver drin, der aber durch die Firewall in der Regel geblockt wird, weswegen die Clients irgendwann davon driften. Bei uns im Netzwerk ist ja die OpnSense der Zeitserver für alle (auch für die AD), daher trägt man in die o.g. Konfigurationsdatei bei NTP die IP der OpnSense ein. Die Datei sieht dann bei Ubuntu 18.04 so aus:
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See timesyncd.conf(5) for details.
[Time]
NTP=10.16.1.254
#FallbackNTP=ntp.ubuntu.com
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048
In meine Fall hat die OpnSense also die IP 10.16.1.254.
Ich glaube aber nicht, dass das wirklich das alleinige Problem ist, da ich die hier beschriebenen Probleme auch hatte und bei mir die Systemzeit von Anfang an i.O. war.
Bei mir stimmen die Zeiten überein, trotzdem kein Erfolg.
Doch ich fühle mit Johannes (Wackelkontakt), denn gestern hatte ich auch kurz EINE erfolgreiche Anmeldung nach einem Durchgang von linuxmuster-client-adsso.setup.
Ich denke momentan in Richtung der macct-Datei. Bei mir ist dort immer der gleiche Inhalt. Ich hätte erwartet nach neuem Domänenbeitritt (mit linuxmuster-client-adsso.setup) ein anderes Passwort darin zu finden. Das ist bei mir immer gleich.
Wie sieht das bei anderen aus? @foer ?
Gruß - Rainer
Ich denke momentan in Richtung der macct-Datei. Bei mir ist dort immer
der gleiche Inhalt. Ich hätte erwartet nach neuem Domänenbeitritt (mit
linuxmuster-client-adsso.setup) ein anderes Passwort darin zu finden.
Das ist bei mir immer gleich.
Wie sieht das bei anderen aus? @foerhttps://ask.linuxmuster.net/u/foer ?
er sagte mir Heute Mittag, dass die bei ihm auch immer gleich ist.
In deinem Fall würde ich mal die macct Datei auf dem client im Cache und
auf dem server löschen (wegschieben) und dann nochmal
linuxmuster-client-adsso machen und dann gleich ein Image erzeugen.
Ist die macct dann wieder da?
Auf Cleint?
Auf Server?
jetzt habe ich es mal auf die harte Tour probiert und das ganze krb5-Zeug rausgeworfen, auch wenn’s jetzt nicht mehr so sicher ist (Ist , glaube ich, für die PCs in den Klassen- und Computerräumen auch nicht so wichtig)
dyndns hat auch immer Fehler gemeldet in sssd.service, wozu braucht man das?
3 Zeilen in sssd.conf dazu:
[domain/LENDER.SCHULE]
id_provider = ad
access_provider = ad
krb5_store_password_if_offline = False
krb5_validate = False
dyndns_update = false
In /etc/pam.d/lightdm habe ich die krb5-Sachen auskommentiert
So geht es, mal sehen wie es morgen ist (man weiss ja nie)
Falls ihr euch fragt, wie ich darauf komme - unser Ubuntu-Client hing auch am logodidact-adserver und es war genauso ein Wackelkontakt beim Anmelden. Das fiel mir jetzt wieder ein (ist 3 1/2 Jahre her), vor allem wo es steht. Wie ich damals drauf kam, weiß ich nicht mehr.
Vielleicht bekommen wir das noch ordentlich hin, aber ich brauche jetzt eine Anmeldung, sonst werde ich nächste Woche gesteinigt.
Ein linuxmuster-client-adsso-setup darf ich jetzt nicht mehr laufen lassen, sonst ist alles wieder weg.
so wie ich das verstehe, hast du die Wallets rausgeschmissen, d.h. dass man sich zwar anmelden kann, aber dass man nicht mehr automatisch geöffnete Wallets hat.
Das ganze Kerberos erscheint mir deshalb so komplex, weil es schon auf der consolenebene nicht so durchsichtig ist, wie was wann funktioniert. Da ist der login-vorgang sicher das komplizierteste.
) scheint bei ihm nicht zu funktionieren.