Neue Beobachtungen und Probleme mit v7 Bionic-Client

kannst du das auch im TOP post Linuxmuster default cloop bionic fuer v7 noch ändern.

Ich hätte noch folgende Anmerkungen:

  • beim User linuxuser ist auch noch „Windeck“ Desktop eingetragen (unwichtig)
  • im Firefox die richtigen Proxy-Ausnahmen eintragen
  • in der Variable no_proxy die Proxy-Ausnahmen richtigstellen (wo eigentlich?)
  • die krb keytab löschen (wo eigentlich?)

VG; Tobias

Ok, hier noch ein Screenshot vom Server v7, der neuerdings mit diesen Meldungen hochfährt. …das gehört eigentilch in einen Extra-Thread. Wo sammeln wir diese Dinge am besten zentral? Hier im Forum oder lieber auf github?

Unbenannt
Die Meldung zum flush wiederholt sich später und es dauer dann ziemlich, bis es weitergeht.

Man kann eine List aller Services anzeigen lassen, die im Status „FAILED“ sind, mit:

systemctl list-units --state=failed

Hallo Tobias,

kannst du das auch im TOP post Linuxmuster default cloop bionic fuer v7
https://ask.linuxmuster.net/t/linuxmuster-default-cloop-bionic-fuer-v7/4098
noch ändern.

… mach ich nachher…

Ich hätte noch folgende Anmerkungen:

  • beim User linuxuser ist auch noch „Windeck“ Desktop eingetragen
    (unwichtig)

im readme ist beschrieben, wie man das anpaßt.

  • im Firefox die richtigen Proxy-Ausnahmen eintragen

kann ich nicht, weil ich nicht weiß, in welchem Netz das cloop verwendet
wird…
Ich kann aber ins readme schreiben, dass man da anpassen muss…

  • in der Variable no_proxy die Proxy-Ausnahmen richtigstellen (wo
    eigentlich?)

… verstehe ich nicht. no proxy ist die Aliasgruppe auf der opnsense:
ich biete hier aber einen client an, keine opnsense …

  • die krb keytab löschen (wo eigentlich?)

ja, das dachte ich auch, aber ich hatte nicht die Zeit das Ding nochmal
auf einen Cleint zu spielen, zu syncen, an zu passen und wieder ein
cloop zu schmieden.
Das mach ich wan anders (wenn nicht grad Schuljahresanfang mit
komplettumstellung ist).

Die kbr Datei liegt direkt in /etc/

LG

Holger

Hi Michael,

da das bei mir nicht vorkommt würde ich vorschlagen, du fängst nochmal an, nämlich mit einem unveränderten cloop von Holger und dem richtigen Postsync.
Schau mal, ob das immernoch auftritt.
VG, Tobias

Hallo Tobias.
Darüber habe ich auch schon nachgedacht … daher gestern nochmal der Doku gefolgt und den ubuntu-Client, der dort angeboten wird (.tbz), zusätzlich als virt. VM installiert. Auch dort kommt es zu Fehlern: So ist z.B. die Cache-Partition in der start.conf als sda3 angegeben, sie liegt aber im cloop auf sda2 – das führt zu einem Fehler beim Booten. Das „linuxmuster-distupgrade“ und „linuxmuster-adsso-client-setup“ lief auf dem Client (nachdem die IP unter noProxy eingestellt wurde) dann aber sofort durch. Die Doku ist da etwas knapp aber die Anmeldung als Domänenuser hat danach mit dem ubuntu1804basisClient.tbz sofort funktioniert. Nur ist dort leider nicht so viel vorbereitet wie in dem großen Paket von Holger & Dominik … daher:

… zurück zum Bionic-Client: Dass die VM die ganzen Fehler ausspuckt, könnte evtl an systemd liegen bzw daran, dass die VM nicht genug Power hat. Daher wollte ich heute das .cloop nochmal auf einem bare-metal-Client ausrollen (der gleiche, den ich letzte Woche als ersten Test verwendet hatte). Nun tauchen aber weitere Merkwürdigkeiten auf: Auf dem Blech erhalte ich diese Meldungen:

Radeon-Meldung:

LINBO-Uhrzeit ist weiterhin UTC (also 2 Stunden zurück. Ich weiß nicht, ob das zu einem Problem mit den Kerberos-Zert. führt??)

Bei Klick auf Neu+Start läuft bittorrent nicht an; bzw es wird nix übertragen :frowning: Server schon neu gestartet. „service bittorrent restart“ schon durchgeführt. Client und Server mehrfach neu gestartet. Den Effekt hatte ich schon mal beobachtet und nicht weiter beachtet – jetzt aber kommt es mir komisch vor:

Daher kann ich auf diese Art auch den bionic-Client im Moment nicht neu ausrollen …
Michael

Hallo Michael,

du solltest mein Readme nochmal genau und ganz lesen.
Es ist (aktualisiert) im ersten Post hier:

LG

Holger

Der Schritt unter 8 „/etc/init.d/linbo-bittorrent restart lmn-bionic.cloop force“ habe ich nochmal laufen lassen. Bittorrent überträgt jetzt wieder…

  • Ok , auf „echter Hardware“ erscheinen die Fehler bzgl der FAILED-Services nicht mehr. Es scheint also an der VM zu liegen! Auch die Anmeldung lief auf dem bare-metal-Client durch. Das cloop läuft also soweit und ist aktualisiert …

  • SSH-Login läuft aber weiterhin nicht vom Server auf den Client, obwohl ich den pub.key dorthing kopiert habe.

  • Proxy-Auth erscheint als Lehrer trotz Eintrags in der OPNSense unter „noProxy“

  • Firefox frage jedes Mal beim Aufruf des Servers, ob er der Seite 10.16.1.1 vertrauen soll – auch wenn man das schon mal akzeptiert hat.

das muss funktionieren, evtl. hast du dich vertippt oder den falschen Schlüssel ins postsync kopiert, siehe ANleitung im anderen Thread.

Alles andere sind keine Fehler mehr:

Ja, der Proxy läuft weiterhin und im Firefox ist weiterhin der Proxy eingetragen. Wenn du das umstellst auf „keinen Proxy verwenden“, dann kommst du auch raus.

Ja, das liegt daran, dass das Zertifikat nur noch temporär akzeptiert wird. Mal googlen oder Holger schreibt, wie man das Zertifikat in den firefox reinbekommt.
VG, Tobias

Hi Tobias.

na ja … vertippen ist nicht möglich, wenn man die TAB-Taste benutzt … aber ich habe nicht den RSA- sondern wie angegeben den ECDSA-pub.Key kopiert – und kontrolliert, ob er an die authorized_keys angehängt wurde, was der Fall war.
Vielleicht hätte es aber doch der RSA-Key sein müssen??

Bin übrigens froh, dass ich heute doch noch ein Erfolgserlebnis hatte … jetzt kann man mal darüber nachdenken, welche Software vom alten System unbedingt übernommen werden muss und welche nicht…

Meine andere Idee war ja: Den 16.04er Client zu migrieren und dann versuchen, den alten PAM-Mechanismus rauszuwerfen und den neuen zu aktivieren. Hat das jemand getestet? Klappt das oder ist das zum Scheitern veruteilt?

Schönen Gruß,
Michael

Ne, auch das g’heert wohl so.

„not found“ ist erstmal keine Fehlermeldung. Entweder Holger irrt sich und die syntax muss anders heißen oder radeon ist in deinem System nicht relevant, daher muss er das auch nicht finden, also: alles ok.

kann sein, probier mal den rsa. Du kannst ja mit >> beide in der Datei haben, andererseits: mach es genauso wie in der Zeile, dann bist du auf der sicheren Seite.
VG, Tobias

Hallo,

Michael:

Firefox frage /jedes/ Mal beim Aufruf des Servers, ob er der Seite
10.16.1.1 vertrauen soll – auch wenn man das schon mal akzeptiert hat.

Ja, das liegt daran, dass das Zertifikat nur noch temporär akzeptiert
wird. Mal googlen oder Holger schreibt, wie man das Zertifikat in den
firefox reinbekommt.

… hat jemand Holger gesagt? …

Man muss private browsing im Firefox ausschalten, dann die webUI
ansurfen, das Zertifikat dauerhaft speichern und dann kann man private
browsing wieder einschalten.

Das geht in der
about:config
(in der Adresszeile eintippen) und nach dem NagScreen (wegklicken) tippt
man in die Leiste über den ganzen Einträgen einfach
p r i v a t e
dann erscheint private browsing als Auswahl.
Doppelklick macht aus true ein dickes false

LG

Holger

Hallo,

Meine andere Idee war ja: Den 16.04er Client zu migrieren und dann
versuchen, den alten PAM-Mechanismus rauszuwerfen und den neuen zu
aktivieren. Hat das jemand getestet? Klappt das oder ist das zum
Scheitern veruteilt?

Dominik hat den 18.04 Client den er in der lmn62 verwendet hatte an die
lmn7 angebunden.
Er hat das geschafft: aber er hat auch davon abgeraten das zu machen.
Dann hat er neu installiert.

Mein Tipp: lass es.

LG

Holger

Hallo,

„not found“ ist erstmal keine Fehlermeldung. Entweder Holger irrt

… wie meinst du das?
Das verstehe ich nicht.
irren?? kenn ich nicht …

sich
und die syntax muss anders heißen /oder/ radeon ist in deinem System
nicht relevant, daher muss er das auch nicht finden, also: alles ok.

es steht genau so in meinen start.confs und da hat es eindeutig eine
Wirkung: das ist also schon richtig so.
Er hat wohl keine radeon im system stecken …

LG

Holger

Hallo,

man muss den key /root/.ssh/id_ecdsa.pub in die zuvor erstellte Datei:
/srv/linbo/linuxmuster-client/bionic/common/root/.ssh/authorized_keys
stecken.

Schon klappt es.
Die Rechte der Datei werden im postsync angepaßt: sie darf nämlich nicht
nur root readable sein (600): sonst kann linbo sie nicht kopieren.
Auf dem Client muß sie aber 600 haben, sonst nimmt der sshd sie nicht an.

LG

Holger

Hi.
Ich habe nochmal die VM gestartet, die sich ebenfalls in der bionic-Hardwareklasse befindet, da ich das aktuelle cloop nochmal dort ausrollen wollte. Leider stellte ich erneut fest, dass bittorrent bei „Neu + Start“ nicht anläuft. Es wird nichts übertragen.
Führe ich hingegen auf dem Server „/etc/init.d/linbo-bittorrent restart“ aus, funktioniert es!

Vielleicht liegen viele der hier auftretenden Probleme aber tatsächlich an der rel. schwachen Hypervisor-Hardware. Es ist ein alter Server mit 8 Kernen und 32 GB RAM … er hat aber nur eine einzelne SATA-Platte mit ZFS drin. Kann schon sein, dass der zu schwach für 6-7 VMs ist…

Die Sache mit den ssh-Keys habe ich mir nochmal angesehen: Es klappt hier definitiv nicht ottb. Man muss nochmal Hand anlegen. Der lokale root-Login auf dem bionic-Client scheint unterbunden zu sein.
Wenn ich auf dem bionic-Client ein „ssh localhost -l root“ versuche, komme ich da ebenfalls nicht rein – es funktioniert nur als linuxadmin. Daher habe ich den pub.key nun mit ssh-copy-id zunächst ins linuxadmin-Profil und von dort ins root-Profi geschoben. Danach lief der pub.key-Login. Das Postsync-Script hat die Datei offenbar nicht oder nicht richtig kopiert – Ursache unklar. Ich habe aber im Moment den Verdacht, dass die Postsync-Dateien alle GAR nicht kopiert werden. Kann man das in einem Log-File überprüfen, ob alles kopiert wurde?

Schönen Gruß,
Michael

Server v7: Upgrade auf aktuelle Version:

Seltsamerweise musste ich zuvor nochmal „service samba-ad-dc restart“ verwenden – erst dann lief das Upgrade durch. Was ist mit der pip Meldung? Upgraden oder lassen?

Hallo Michael,

verwenden – erst dann lief das Upgrade durch. Was ist mit der pip
Meldung? Upgraden oder lassen?

das haben die Entwickler im Blick: die sagen dann schon bescheid.

LG

Holger

Ja, das ist der Fall. … ich habe nochmal einen Sync+Start ausgeführt, aber die .postsync-Datei wird offenbar nicht abgearbeitet. Kann es sein, dass es da Inkonsistenzen gibt was die Namen angeht:
„bionic ↔ lmn-bionic“
Muss das Verzeichnis unter /srv/linbo/linuxmuster-client nicht lmn-bionic heißen?

Ich habe auf dem Client die Partition /dev/sda2 gemountet und nachgeschaut – dort sind alle lmn-bionic.* Files – außer lmn-bionic.cloop.postsync. Die wurde offenbar nicht mit übertragen. Ist das bei euch auch so?
Das Verzeichnis /mnt/linuxmuster-client/serverpatches ist allerdings sehr wohl da und darin liegen auch alle Files vom Server. Jetzt wird aber klar, warum einige der o.g. Probleme hier aufgetreten sind: Offenbar klemmt der postsync-Mechanismus. Nur: Wo?
Schöne Grüße,
Michael

… und des Rätsels Lösung: Mal wieder die Rechte!

Aus unerfindlichen Gründen hatte die Postsync-Datei nur
-rw----- und nicht rw-rw-r (664).
Geändert, synchronisiert und siehe da: SSH läuft sofort :slight_smile:

Es bleibt aber unschön, dass man nun zwar als root auf den Client kommt, dann aber dennoch keinen Internetzugriff hat. Der Proxy schlägt weiterhin zu…