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 
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…
Hallo Michael,
das ist halt so sollte man jetzt mal in ganz großen Buchstaben in die Doku schreiben, denn:
Wenn man diese beiden Dinge beachtet, dann weiß man was man zu tun hat, z.B. r101-pc01 in die no-Proxy-Liste aufnehmen, als root anmelden und die Variablen „http_proxy“ und „https_proxy“ etc. auf „“ setzen, z.B. so
http_proxy= https_proxy= apt updateDasselbe gilt übrigens auch für Windows-Clients: keine Auth - kein Internetzugriff, außer: noProxy und proxy gar nicht verwenden.
VG, Tobias
Hallo Tobias.
Ok – mir kommt es allerdings (unnötig?) kompliziert vor 
. Vielleicht kann man sich irgendwie mit einem Alias-Befehl oder so helfen? Alle VMs, die im Moment installiert sind, stehen mittlerweile in der noProxy-Liste in der Firewall. Punkt 1 wird ja immer mal wieder abgefragt – aber auch nicht immer, wenn man den Firefox startet. Den Mechanismus wann und wie oft habe ich aber noch nicht ganz verstanden.
Wenn ich mich als linuxadmin auf der grafischen Oberfläche einlogge bin ich übrigens sofort online. Dann muss ich nicht mehr an den Proxy denken und „linuxmuster distupgrade“ läuft sofort. Per ssh und als root geht’s aber nicht ootb. Das ist dann aber nicht einheitlich, wenn die oben genannte Punkte 1 und 2 immer gelten sollen, oder?
Mir fiel noch ein weiterer Punkt auf, den ich zumindest für mich überdenken muss und zwar handelt es sich um die per default eingestellten Passwörter für Lehrer, die 12 kryptische Zeichen lang sind 
. Safety first … aber man muss es seinen Kollegen auch „verkaufen können“. Das wird schwer… ich habe aber gesehen, dass man es unter school.conf einstellen kann.
Wenn ich von 6.x → 7.0 migriere, werde ich nach Möglichkeit die alten Passwörter aller User übernehmen. Ich hoffe sehr, dass das gelingt… der Weg ist jedenfalls noch weit.
Schöne Grüße,
Michael
ja, natürlich.
auch klar: Das haben sich die MAcher des clients auch gedacht und „unset http_proxy“ an das login von linuxadmin gekoppelt, glaube ich.
MAch in einem Terminal einfach mal „printenv“ oder genauer: echo $http_proxy, dann siehst du, ob auf konsolen-ebene der proxy gefragt wird oder nicht.
mach ich auch runter auf 7 oder 8, aber ich glaube da geht es um neu vergebene Passwörter, so genau hab ich die 12 Zeichen auch nicht in AKtion gesehen.
Das hat bei mir im Prinzip geklappt. bisher hatte ich keinen FAll von migriertem PAsswort, der sich nicht an der Cloud oder an der SChulkonsole anmelden konnte. Ich hatte aber Fälle, die sich nicht am Client anmelden konnten, bis sie ihr Passwort geändert (bzw. einfach neu gesetzt) hatten. Schätzungsweise 20% aller User, Grund bislang unklar. Evtl. auch andere Artefakte mit der Anmeldung die da reinspielen.
VG, Tobias
Das ist ein guter Tipp – steht der schon in der Doku? Falls nicht, sollte das da rein, oder? Ich aktualisiere meinen Master-Client z.B. sehr häufig per ssh ohne grafischen Login. Da ist dieser Befehl ab jetzt dann ja unumgänglich!
Michael
Hi.
Gerade habe ich zum wiederholten Mal diese Beobachtung gemacht:
bionic-Client startet aber Anmeldung als Lehrer nicht möglich.
Auf dem Server ein „service samba-ad-dc restart“ hat geholfen – danach ging es.
Beim Systemstart des Servers habe ich jetzt aber kein einziges „FAILED“ mehr. Dennoch scheint der Prozess serverseitig öfter mal zu hängen??
Dann aber noch diese Beobachtung: Auf dem Client gab es bereits ein Profil eines Testschülers unter /home/cache – damit konnte ich mich anmelden auch ohne den samba-ad-dc neu starten zu müssen. Dann war es aber so, dass im Dateimanager die Shares alle als tote Links auftauchten.
Das Profil des Lehrers war aber nicht (mehr) im Cache auf dem Client vorhanden. Der Login ist komplett gescheitert – bis der Samba-AD neu gestartet wurde; danach war alles ok. Kann es sein, dass auch auf dem Server die Reihenfolge der Services festgenagelt werden muss?
Schöne Grüße,
Michael
Hallo Michael,
Beim Systemstart des Servers habe ich jetzt aber kein einziges „FAILED“
mehr. Dennoch scheint der Prozess serverseitig öfter mal zu hängen??
ich nehem an, dass da an deiner Installation oder an deinem Server was
nicht stimmt.
Bei ir läuft das seit 2 Wochen Produktiv mit über 100 Rechnern und über
1000 Nutzern: und der samba Dienst ist noch kein einziges mal abgeschmiert.
Wieviel Hauptspeicher hast du den dem lmn7 Server zugestanden?
samba4 braucht da schon mehr als samba 3
Wie ist den die swapauslastung am Server?
Wieviele Kerne hat er?
LG
Holger
Hi Holger,
Der größte Unterschied zwischen deiner und meiner Installation dürfte der sein, dass du alles from scratch gemacht hast und ich eine fertige Vorlage importiert habe, oder?
Bei der Installation des Servers und aller VMs sind wir der offiziellen Anleitung gefolgt und haben die Proxmox/KVM-Vorlagen von netzint genommen. Ich habe auch an der Hardware der VM nichts geändert – alles auf den Werten gelassen, wie es im Wiki steht und wie es vorgegeben war. Aber ich gebe -wie schon gesagt- auch nur das wieder, was auch @gamma bei seiner Installation beobachtet hat…
Kann dem Server aber gerne etwas mehr Speicher und mehr Kerne spendieren… seltsam ist es aber schon, dass der Samba-/AD des öfteren steht bzw neu gestartet werden muss.
Schöne Grüße,
Michael
Hi.
Ok, hier kommen wir der Sache näher. Ich kann leider nur mit Screenshots aus der VM dienen. Gerade habe ich festgestellt, dass ich vom Server aus nicht per ssh/ftp/whatever auf unsere „echte“ Domain gelange. Als Subdomain für den Server habe ich einfach „linux“ gewählt, aber ich erreiche die Domain „meine-schule.de“ von intern nicht. (das sind hier natürlich Phantasienamen)
Hier der Screenshot (mit ersetzten Namen) – die VM hat jetzt übrigens 8 GB RAM und 6 Cores:
hi tobias: verifiziert, löscht die anderen punkte. aber das ist ein BUG vom greeter?
naja, und das mit dem ff ist auch nicht schön, macht einen schlechten eindruck, gerade wenn man zum 1. mal linux-clients hat, und so etablierte progs wie ff dann abschmieren. kennt jemand abhilfe?
