Meines Wissens lautet die Devise wie beim Highlander: „Es kann nur einen geben!“ ??
Wenn der Client ausgestellt wird, müsste das ja immer neu verhandelt werden.
Das kann imho nicht richtig sein!??
Wir haben übergangsweise (nicht funktionierender Dualboot win10-Ubuntu) in einigen Räumen Linux/Bionic Beaver Clients.
Mir sind bisher folgende Dinge aufgefallen:
- lightDM als greeter (ist das Standard? Gefällt mir optisch, dachte aber gdm wäre Standard bei Ubuntu 18): es sind bei uns mehrere Sessions eingetragen auf Wunsch, z.B. Cinnamon, läuft einwandfrei, und gnome. Wählt man einmal nicht (über den weißen Punkt beim login) die 1. Option, und will wieder zurück zur 1., wird diese nicht sofort übernommen. Mann muss erst eine andere anklicken, und dann wieder die 1. und dann einloggen. Dies verwirrt Schüler und Lehrer und kostet Zeit. Lässt man den „weißen Punkt“ in Ruhe, startet erwartungsgemäß die 1. Option.
Nach Recherche habe ich folgende Möglichkeit gefunden: in /usr/share/xsessions/ die unerwünschten Sessions *.desktop umbenennen, dann verschwinden diese im Greeter. Noch nicht getestet, an einem Privatrechner hat es so geklappt.
-
nach dem einloggen hängt sporadisch manchmal der ganze PC oder nur einzelne Programme (firefox) und man muss sich erneut einloggen (könnten auch die uralten Clients dran schuld sein…)
-
Linux ist zu schlau und wählt immer die erkannte Auflösung. Falls ein blöder d.h. passiver VGA-Splitter dazwischen ist (wegen Beamer etc.) wird immer auf 1024x768 oder so zurückgestellt. Eine manuelle Umschaltung wäre hilfreich. Meine xrandr Versuche sind erstmal auf die Schnelle fehlgeschlagen, es müssen Bibliotheken nachinstalliert werden etc.
Eine zu überdenkende Einstellung bzw verdrehte Welt: Der ssh-Zugang vom Server zum Client wird unterbunden (nur PublicKey erlaubt). Aber umgekehrt kommt man mit dem root-Login (
) vom Client auf den Server. Das sollte imho genau umgekehrt sein…
LInbo macht folgendes:
Ich habe ein cloop auf dem Server. Das Gesamtpaket besteht aus 6 Files, und zwar
.cloop .desc .info .macct .postsync und .torrent
Wenn ich ein neues Image anlege und hochlade, wird bekanntlich das alte Image umbenannt. Dabei wird aber die Postsync-Datei auch umbenannt und für das aktuelle Image steht die Datei dann nicht automatisch zur Verfügung! Das habe ich bereits wiederholt beobachtet, so dass ich von einem Bug ausgehe. Ist dies die richtige Stelle, um die ganzen Fehler und Beobachtungen aufzulisten? Liest hier ein Entwickler mit? Oder wie sollen wir vorgehen?
Hallo Michael!
Welche Linbo-Version?
Wenn du einen Github-Account hast, dann hier bei den Issue eintragen. Wenn nicht dann mach ich das / oder ein anderer wenn er schneller ist.
Lieben Gruß
Thorsten
Hallo,
ich hab noch eine Anmerkung für alle, die das lmn-bionic.cloop einsetzen.
Eine Einstellung hatte ich noch vergessen: in der Datei
/srv/linbo/linuxmuster-client/bionic/common/etc/systemd/timesync.conf
muss noch die IP meiner opnsense gegen die von eurer getauscht werden.
Ich hab das ins Readme aufgenommen und ein neues Paket geschnürt.
LG
Holger
das stimmt, daher habe ich die
entsprechenden DAteien gelöscht.
ne, hab ich auch schon gehabt beim Firefox, ich konnte mich remote einloggen und den firefox killen
Das liegt daran, dass du die aktualisierte Doku hier nicht bis zum ende gelesen hast: Linuxmuster default cloop bionic fuer v7
vor-vorletzter Bulletpoint.
Da hast du recht, das muss man selbst unterbinden, sobald man sichergestellt hat, dass man ein Zertifikat auf den Server kopiert hat. Das kann man nicht standardmäßig einfach abstellen m.M. nach. Aber in die Doku…
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?
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=failedHallo 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 
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