Ich glaube, dass es noch ein weiteres Problem gibt, das mit der aktualisierten Version von texlive zusammenhängt .
Kann es sein, dass unter Ubuntu 22.04 ein paar LaTeX-Pakete fehlen? Ich wollte ein paar Passwort-Kärtchen für die Schüler TeX’en lassen und erhalte Fehler, dass z.B. dass die Style-Pakete pdftexcmds.sty oder auch infwarerr.sty fehlen.
Habt Ihr das auch?
Kann sein, dass ein einfaches apt install texlive-latex-recommended das Problem schon behebt!? Anschließend texhash nicht vergessen…
der PR ist aber ja von @jeffbeck als closed markiert? Und im lmn7.2-testing branch steht im commit 30ff358 zwar etwas von removed -mNT1 aber im Patch ist das nicht enthalten? Kannst du mir einen Schubs geben, damit ich kapiere, wie das letztendlich in sophomorix ankommen soll, wenn nicht nochmal ein PR oder ein Issue aufgemacht wird?
VG Dominik
Holger hat festgestellt, dass der linbo-postsync nicht mehr funktioniert. Das ist bei mir genauso. Der Snyc bricht ab mit:
[StdErr] rsync: getaddrinfo: 873: Name or service not known
[StdErr] rsync error: error in socket IO (code 10) at clientserver.c(137) [Receiver=3.2.3]
Das liegt daran, dass rsync den Server nicht erreicht.
Eine Suche zeigt, dass sich offenbar die dhcp.log in Linbo4.1 geändert hat. Im bisherigen allgemeinen Postsync-Skript steht zur Bestimmung der ServerIP folgende Zeile:
Den String linbo_server gibt es bei Linbo 4.1 in der dhcp.log nicht mehr. Stattdessen gibt es nun serverid. Ersetzt man im Postsyncscript also die Zeile bei der die ServerIP gesucht wird durch folgende:
Hallo Dominik (@foer)
Kannst Du kurz präzisieren, um welche .postsync Datei es sich hier gerade handeln soll? Ich habe bei mir unter [root@server:/srv/linbo/images/fossa]$ cat fossa.postsync geschaut und da wird die ServerIP ganz anders ermittelt:
# IP-Adresse des Servers
#SERVERIP=$(nslookup dummy 2> /dev/null | head -n 1 | awk -F: '{print $2}' | sed "s/\s*//g")
SERVERIP=${siaddr}
export SERVERIP
Die erste Zeile war bereits auskommentiert – ich habe da nichts geändert.
Daher nochmal die Rückfrage, an welcher Stelle Du den Eintrag gefunden hast?
…das ist aus der Stadard-Vorlagendatei von Linbo Exampels…siehe hier…übrigens hier vom aktuellen Linbo 4.1.44…das wird halt Probleme geben, weil die Vorlagendatei nahezu alle da draußen benutzen. Du hast da irgend eine andere Variante, die ich noch nie gesehen habe.
Das macht die Situation nicht besser, weil es verschiedene Varianten in der Wildnis gibt. Meine Variante war die, die ganz zu Beginn der „Postsyncerei“ eingeführt wurde…
Nochmal @thomas : also zumindest in den Exampels muss es angepasst werden und in die Doku und Readme…oder nicht?
danke für den Hinweis. Die Linbo-Examples sind bei mir schon auf der todo-Liste. → @Doku-Team Postsyncscripte müssen angepasst werden.
Evtl. kann auch jemand aus der Community schöne Postsync-Examples zur Verfügung stellen.
Wenn bei der Erstellung von differentiellen Images das Basisimage nicht kompatibel ist, wird jetzt eine entsprechende Fehlermeldung ausgegeben. Beispieldateien wurden aktualisiert und obsolete entfernt.
habe das ganze jetzt mal in der Schule ausgerollt, da gerade Ferien sind, um das live zu testen. Upgrade des Servers lieft ohne unlösbare Probleme durch…an zwei, drei Stellen gab es Abhängigkeitsprobleme mit speziellen (uralten) Epson Druckertreibern und Cannon Treiber für Kopierer, die alte Libraries wollten…war mit Gebastel lösbar. Nach dem Update von 20.04 auf 22.04 wollte samba nicht mehr starten, was daran lag, dass die smb.conf weg war!? Keine Ahnung wieso, ich hatte bei der Konfiguration des Pakets „die alte behalten“ gewählt. Hab dann die smb.conf aus dem Backup hin geschoben und alles war gut. Ich denke, dass ist eher ein sehr esoterischer Fehler…ist in keinem anderen Test bisher aufgetreten. Insgesamt lief es also sehr gut! Wenn man keine blöden Pakete wie meine Druckertreiber installiert hat sollte das glatt durchlaufen.
Habe dann die postsync-Dateien auf die neuen Umgebungsvariablen von linbo4.1 angepasst. Von meinen 220 Clients (extrem heterogene Hardware; Intel und AMD, Notebooks und Desktops von 8 Jahre alt bis 1 Monat alt) haben sich bis auf 10 steinalte Terra Notebooks mit einem Horror-VIA-Chipsatz alle auf Anhieb mit dem neuen Linbo verstanden. Die Terras frieren schon bei der Hardwareinitialisierung direkt ein…habe bisher keinen Kernelparameter gefunden, der die wieder zum Leben erweckt. Danach war bei allen getesteten Clients direkt ein Login möglich. Netzlaufwerke waren da und das SSO für den Proxy hat auch funktioniert…Browsen war direkt möglich. Habe allerdings nur Ubuntu-Clients, zu Windoof kann ich nichts sagen.
Ldap-Auth von externen/internen Diensten klappt. Bei der WebUi habe ich die Nutzerverwaltung getestet, klappt. Morgen werde ich mal weiter testen. Bisher sieht alles gut aus. Wenn ich nichts gravierendes finde, lasse ich das mal nach den Ferien weiter laufen.
meine Vorbereitungen laufen auch.
Heute hab den ganzen Tag ein neues Image für meine ubuntu Clients
eingespielt und angepaßt (Update von 18.04 auf 20.04 … wurde langsam
Zeit).
Backups sind gemacht (gerade fertig).
Upgrade mach ich vielleicht schon Heute Nacht, oder dann halt MOrgen
tagsüber.
Tests an echter Hardware in der Schule werden Mittwoch gemacht.
ich hab die upgrades gemacht.
Nach dem Ändern von: /usr/lib/linuxmuster-webui/etc/requirements.txt
Eintrag von 39.0.0 in der Datei (es stand 39.0.1)
Beim Lauf von dpkg-reconfigure sophomorix-samba linuxmuster-base7 linuxmuster-webui7
kamen dann Fehlermeldungen:
Ich hab darauf hin wieder 39.0.1 in die Datei geschrieben und nochmal dpkg-reconfigure sophomorix-samba linuxmuster-base7 linuxmuster-webui7
laufen lassen: dann lief es durch: vielelciht müssen wir da die Anleitung anpassen.
Es freut mich sehr, dass viele Tester den Upgrade und Meldungen hier sammeln, vielen Dank dafür. Ich muss aber mitteilen, dass ich gerade den Session Plugin in 7.2 neu schreibe. Ich hoffe es wird für euch kein Problem sein.
und weil es bis vor ca. einer Woche auch noch notwendig war: da war die
Eingetragene Nummer in der Datei nämlich kleiner als 39.0.0, bei meinen
letzten 2 oder 3 Upgrades war sie 39.0.1
ich hab Heute mal einen (VM) Client beobachtet, bei dem die GRUPPE.cfg
nicht neu geschrieben wurde, seit dem upgrade von linbo4.0 auf 4.1 (weil
ich die managed by linuxmuster Zeile manipuliert habe).
In der cfg steht außerdem: neu+start von win10 nach 3 Sekunden und es
steht warmstart=no in eben dieser .cfg: also etwas was wir als Problem
gefunden und Thomas gefixed hatte.
Ich kann sagen: der fix funktioniert.
Der Client bootet mit linbo 4.0.44 (darauf wurde geachtet) und restartet
noch vor dem sync. Dann bootet linbo 4.1.25 und tut was es soll
(neu+sync+start)
noch eine Beobachtung zum upgrade von 18.04 über 20.04 auf 22.04 des
servers.
Es hat meine freeradius config geschreddert.
Es fehlten nach dem upgrade auf 20.04 schon essentielle Teile (die ich
nicht genauer untersucht habe: der Dienst startete nciht mehr).
Ich weiter upgegraded und mir danach den Schaden angeschaut.
Der Dienst meldete beim Start, dass er ein Verzeichnis in etc nicht
finden könne: sites-enabled
Ich hab nachgeschaut: sites-availible war da, aber enabled nciht.
Also hab ich ins Backup geschaut: da waren noch mehr Dateien und
Verzeichnisse die unter /etc/freeradius/3.0/ fehlten.
Da hab ich nicht lang rum gemacht und das Verzeichnis
/etc/freeradius/3.0/ zu 3.0-bak umbenannt und das Verzeichnis
/etc/freeradius/3.0/ aus dem Backup wiederhergestellt.
Der Radius lief sofort wieder.
Es ist ja nicht vorgesehen den radius auf dem Server laufen zu lassen:
an dieser Stelle sieht man, war das so eher nicht empfohlen wird.
Zum Glück ist es einfach zu reparieren.