Hallo zusammen,
ist schon etwas her, aber ich berichtete vom falschen Icon, das bei einem Neu+Start-Knopfdruck über den Bildschirm wandert.
Da es hieß, das könne nicht sein - hier der Beweis 
Nichts dramatisches (es wird ja das richtige Image genommen) - aber vielleicht ja auch nur eine Kleinigkeit in der GUI.
Viele Grüße
Thomas
Moingiorno!
Es gibt jetzt linuxmuster-base7 7.2.0-rc12:
VG, Thomas
Hallo zusammen,
mir ist noch eine Kleinigkeit aufgefallen:
Gruß,
Mathias
Alles klar.
Gruß,
Mathias
Ja, ich weiß bescheid, und ist schon teilweise vorbereitet.
Ich muss nur noch überprüfen, wie die Gruppen rekursiv Mitglieder sein können.
Gruß
Arnaud
Hallo zusammen,
Version 7.2.23 von der Webui ist raus:
Gruß
Arnaud
Hallo zusammen,
ich habe letzte Nacht meinen „privaten“ 7.1-Server auf 7.2 aktualisiert.
Beim Schritt dpkg-reconfigure sophomorix-samba linuxmuster-base7 linuxmuster-webui7 kam bei mir zu mehreren Problemen.
Zunächst ein „alter Bekannter“ - Versionsprobleme beim Kryptographie-Modul. Problem war, dass man pip bei mir gar nicht mehr starten konnte!
Was half, war das manuelle Löschen: rm -R /usr/lib/python3/dist-packages/OpenSSL.
Danach konnte man die passenden Bibliotheken wie damals vorgeschlagen installieren: pip3 install cryptography==3.4.6
Das nächste Problem:
Attempting uninstall: simplejson Found existing installation: simplejson 3.16.0 ERROR: Cannot uninstall 'simplejson'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.
Das habe ich lösen können mit dem Entfernen von simplejson (und Abhängigkeiten) mit apt: apt remove python3-simplejson. Danach lief der reconfigure-Befehl dann durch.
Ob ich damit irgendetwas kaputt gemacht habe, kann ich natürlich nicht sagen - nur, dass es nun zu laufen scheint.
Viele Grüße
Thomas
Hallo zusammen,
ich habe nach dem Update auf 7.2 ein Problem mit linbo-remote.
Zuerst habe ich alle Clients einmal durchstarten lassen, damit sie linbo 4.1 (genauer 4.1.35-0) haben. Nun habe ich das Problem, dass wenn ich linbo-remote nutze mit bspw.:
linbo-remote -i test_client -w 60 -n -c format:3,sync:1,halt
der Client in linbo bootet, dann aber den Autostart weiter ausführt und das eingestellte OS startet. Zur Ausführung der Befehle kommt es dann gar nicht.
Hat dieses Problem schon jemand beobachten können und vielleicht einen Tipp, wie ich es weiter debuggen könnte?
Edit: Gerade bemerkt, dass ich nach dem Upgrade linuxmuster-import-devices vergessen hatte. Ich werde es nochmal probieren evtl. hat sich das Problem damit aber gelöst.
Viele Grüße
Dominik
Tag auch,
falls das so tut wie Du das geplant hast, dann mach ich das schon immer zu umstaendlich, wusste nicht, dass das „-w 60“ den autostart deaktiviert, damit die -c-Befehlen entgegengenommen werden koennen - dachte dazu muss der Client in linbo ruhen.
Ich hab dazu immer „-p“ abgedrueckt und danach noch den WOL-Befehl (-w 0) gesendet.
Gruss Harry
Hallo zusammen,
„-w 60“ bewirkt, dass der Cleint ein WOL-Paket bekommt und dann wird 60 Sekunden gewartet. Wenn der Client innerhalb der 60 Sekunden in Linbo ist, werden die -c-Befehle abgeschickt.
Wenn der Client länger als 60 sekunden braucht, werden die -c-Befehle nicht vom Client ausgeführt.
Mit „-p“ ist das etwas eleganter. Der Client wird mit „-w 0“ gestartet und sobald der Client Linbo gestartet hat, werden die -p-Befehle ausgeführt.
Da ich den Autostart in der /srv/linbo/boot/grub/imagename.cfg realisiere, brauche ich -n nicht.
# ### NOT managed by linuxmuster.net ###
# edit to your needs
set default=1
set timeout=5
set fallback=1
Mit default=1 wird sofort das BS gestartet, also ohne Linbo zu starten.
Gruß,
Mathias
Hallo zusammen,
heute haben wir (meine Klasse und ich) eine interessante Entdeckung gemacht:
Die Schüler haben über die Schulkonsole ihr Passwort geändert. Das witzige ist jetzt, dass sich die Schüler mit dem alten und dem neuen Passwort in der Schulkonsole anmelden können.
Die Anmeldung am Rechner, der Nextcloud oder Moodle geht nur mit dem neuen Passwort.
In der zweiten Doppelstunde ging dann nur noch das neue Passwort.
Gruß,
Mathias
Hallo Mathias,
war das auch bei einer Anmeldung an einem anderen Rechner so? Bzw. mit einem anderen Browser?
Vermutlich war da einfach nur noch ein gültiges Session-Cookie vorhanden.
Beste Grüße
Jörg
Hallo Jörg,
ich hab’s jetzt nochmal ausprobiert:
Die beiden letzten Passwörter werden akzeptiert!!
Das alles lief mit dem Firefox. Was anderes haben wir nicht…
Gruß,
Mathias
Hallo Mathias,
Das ist normal, es liegt am Parameter old password allowed period = 60 im Samba, der die User erlaubt, das alter PW noch eine Stunde lang verwenden zu können, damit sie nicht sofort von allen Services ausgeloggt werden.
Gruß
Arnaud
Hallo Arnaud,
das erklärt alles. Vielen Dank.
Gruß,
Mathias
Hallo zusammen,
Auch wenn wir inzwischen vieles hinbekommen haben - folgendes ist seit dem Wechsel zur 7.2 aufgefallen (was nicht heißt, dass die zwingend durch das Upgrade entstanden sind):
bei unseren Geräten mit NVME-SSDs funktioniert die Anzeige bei HDD links unten in der Linbo GUI nicht. Man kann nur lesen: „HDD: Prints partition size.Usage: linbo_“. Dahinter kommt die - korrekte - Anzeige des freien Platzes im Cache.
schon mal erwähnt, der Vollständigkeit halber: klick auf Sync+Start oder Neu+Start beim 2. Betriebssystem lässt das falsche Symbol (Windows statt Linux) durch die GUI wandern.
heute hatten wir erneut ein Gerät, bei dem die Anmeldung in der Domäne nicht funktioniert (unter Windows 10: Vertrauensstellung, unter Ubuntu 22.04: Passwort nicht akzeptiert). Das beunruhigt mich jetzt doch etwas. Bisher war es „nur“ ein virtueller Client, jetzt passiert das auch bei realen Clients. Gleiches Gerät, gleiches Image, gleicher Hostname - nur eine andere Nummer am Ende. Die anderen Geräte funktionieren einwandfrei. Regpatch ist eingespielt, Zeit und Hostname passen. Auch als lokaler Admin kann ich mich anmelden und komme dann auf den Server.
Ich kann mir das derzeit nicht anders erklären, als dass da irgendwo im AD mit diesen Clients etwas schief geht - wüsste aber nicht, was und wann - die Rechner wurden ja gemeinsam aufgenommen. Vielleicht hat ja irgendwer eine Idee.
Viele Grüße
Thomas
Hallo Thomas,
heute hatten wir erneut ein Gerät, bei dem die *Anmeldung in der Domäne* nicht funktioniert (unter Windows 10: Vertrauensstellung, unter Ubuntu 22.04: Passwort nicht akzeptiert). Das beunruhigt mich jetzt doch etwas. Bisher war es „nur“ ein virtueller Client, jetzt passiert das auch bei realen Clients. Gleiches Gerät, gleiches Image, gleicher Hostname - nur eine andere Nummer am Ende. Die anderen Geräte funktionieren einwandfrei. Regpatch ist eingespielt, Zeit und Hostname passen. Auch als lokaler Admin kann ich mich anmelden und komme dann auf den Server. Ich kann mir das derzeit nicht anders erklären, als dass da irgendwo im AD mit diesen Clients etwas schief geht - wüsste aber nicht, was und wann - die Rechner wurden ja gemeinsam aufgenommen. Vielleicht hat ja irgendwer eine Idee.
… dass da irgend was mit den Computerkonten einzelner Clients beim oder
nach dem Upgrade passiert wäre halte ich für sehr unwahrscheinlich: ich
hab das auch in meinen Einrichtungen kein einziges mal beobachten können.
Meine Vermutung wäre jetzt: die gute alte Systemzeit auf dem Client.
Du schreibst, dass sie stimmt: du hast das also bedacht: trotzdem ist
sie nicht als „Täter“ raus.
Sie kann sich ja in der Zeit, die du zum testen und dann zum Anmelden
des lokalen Admins benötigt hast, richtig gestellt haben.
Vor allem wenn du Windows und Ubuntu zusammen auf einem Rechner hast
mußt du bedenken, dass Betriebsysteme in aller Regel ihre Systemzeit
selber stellen und diese ins BIOS eintragen.
Dummerweise nehmen alle Betriebsysteme dabei UTC … außer Windows: das
nimmt Localtime.
Wenn nun beide Betriebsysteme auf einem Rechner nacheinander laufen,
dann finden sie also erstmal die falsche Zeit im BIOS: und diese
verwenden sie.
Deswegen ist es essentiell in einer solchem Umgebung Windows so ein zu
stellen, dass es auch UTC ins BIOS schreibt (in die RealTime Clock RTC).
LG
Holger