ich habe die Ursache gefunden: mein linbo-Passwort war bei meinem Testsystem (weil ich mir das sonst immer nicht merken konnte, wenn ich das Testsystem nach Wochen mal wieder hochgefahren habe) „linbo“. Damit geht in /usr/bin/linbo_upload aber die Parameterzuweisung schief, weil in Zeile 36 für diesen Fall ein shift passiert:
[ -z "$1" -o "$1" = "linbo" ] && shift
Wozu das da ist, weiß ich nicht, aber ich habe auf dem Server jetzt in /etc/rsyncd.secrets mein Passwort geändert und schon geht der Upload.
Merke: (zumindest derzeit) darf das Passwort für den Linbo-Admin-Screen nicht linbo heißen. Sollte es sicher sowieso nicht, aber auch im Testsystem funktioniert das nicht.
Also alles kein 7.3-Thema (zumal linbo_upload ja offenbar sowieso unverändert ist).
Persönlich tendiere ich zu b) mit Anmerkungen für klein(st) Schulen zum Verzicht auf File-Server. Da wir ohnehin auf Proxmox setzen und alles für VMs beschreiben, macht es wenig Sinn, nicht auf die drei Server zu setzen.
wo mein grundsätzliches Upload-Problem gelöst ist, darf ich da nochmal hier nachfragen? Das fand ich immer praktisch und fehlt mir jetzt doch etwas … auch die LINBO-Gui zeigt da ja nur „Dieser PC wird ferngesteuert …“.
ich denke dass der Standardweg die 2 Server Lösung ist.
Von dieser aus kannst du immer noch auf die 3 Server Lösung umsteigen.
Aber Standard sollte 2 Server sein.
Grüße Ralf
heute habe ich eine LMN 7.3 Installation und dessen NTP im Netz gestestet.
Die Pakte sind wie von dir oben angegeben alle installiert.
Um eine fehlerfreie Zeitauflösung auf einem Windows System (W2K19 Standard Server) hin zu bekommen, habe ich die /etc/ntpsec/ntp.conf folgendermaßen anpassen müssen.
EDIT 20250804:
driftfile /var/lib/ntpsec/ntp.drift
## damit folgende LOGs gehen musste ich AppArmor anpassen, siehe unten
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
# Zeitquellen (1x internes GW + 2x externe Server)
server 10.16.0.254 iburst prefer
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
# Lokale Uhr als Fallback
server 127.127.1.0
fudge 127.127.1.0 stratum 10
# Restriktionen
restrict -4 default nomodify noquery limited kod
restrict -6 default nomodify noquery limited kod
# Lokale Netzwerke (kein mssntp!)
restrict 10.16.0.0 mask 255.255.255.0 nomodify
restrict 172.17.133.0 mask 255.255.255.0 nomodify
# (Weitere Netze hier hinzufügen OHNE mssntp, OHNE weitere Parameter, falls nötig)
# localhost
restrict 127.0.0.1
restrict ::1
# Quelle
restrict source nomodify
# Entferne diese Zeile, weil ntpsec zZ damit nicht funktioniert
# Entsprechend muss NTP Gruppenrichtlinie fuer Windows Clients auch auf "nur NTP" umgestellt werden:
# ntpsigndsocket /var/lib/samba/ntp_signd
Die Ursache für die Zugirffsverletzung auf
/var/log/ntpsec/
# systemctl stop ntpsec
# ntpd -d -f /etc/ntpsec/ntp.conf
...
2025-07-29T11:10:52 ntpd[133472]: statistics directory /var/log/ntpsec/ does not exist or is unwriteable, error Permission denied
...
2025-07-29T11:10:53 ntpd[133472]: LOG: couldn't unlink /var/log/ntpsec/peerstats: Permission denied
2025-07-29T11:10:53 ntpd[133472]: LOG: can't open /var/log/ntpsec/peerstats.20250729: Permission denied
Trotz richtig gesetzter Rechte, habe ich inzwischen gefunden: AppArmor
Hier musste zuerst ein Fehler in folgende Datei angepasst werden, lxc-start in lxc-copy (führte zu ERROR Melungen:
Dann erst konnte ich die AppArmor ntpd Rechte neu setzen mit folgendem Befehl:
root@server ~ # aa-complain /etc/apparmor.d/usr.sbin.ntpd
Setting /etc/apparmor.d/usr.sbin.ntpd to complain mode.
Befehle zum Testen auf dem Windows zB mit:
net stop w32time
net start w32time
w32tm /config /manualpeerlist:"10.16.0.1,0x8" /syncfromflags:manual /reliable:YES /update
w32tm /resync /nowait
w32tm /query /status
Jetzt funktioniert die NTP Zeitübergabe.
Bleibt meine Frage, warum nicht das von Samba empfohlene ‚chrony‘ verwendet wird.
Bei meinen bisherigen Samba 4 DC Umgebungen setze ich immer auf chrony das ich für unkomplizierter und funktionaler halte. Damit funktioniert bei mir ebenfalls die signierte Übertragung wie sie soll …
Hallo @thomas und die Runde.
Ich hab noch eine Frage zum update von 7.2 auf 7.3:
Werden hier Einstellungen auf der Firewall geändert / gemacht?
Wenn ich weitere Systeme teste und das update scheitert, dann hab ich einen Snapshot und kann zurück auf 7.2 mit allen Aktualisierungen. Aber muss ich dann auch die Firewall snapshoten und auf dieser auch zurück? Oder kann ich die durchlaufen lassen und nochmals ein update testen?
Grüße Ralf
Linuxmuster-Base 7.2.19 in lmn7.2
das ist auf meinem Testsystem der aktuelle Stand.
Aber sollte hier nicht 7.2.20 aktuell sein?
Ein update bringt keine Neuerungen?
Grüße Ralf
stimmt. Das Paket ist nicht im Repo angekommen, obwohl der Workflow fehlerfrei durchlief. Beim zweiten Versuch wird das Paket 7.2.20 abgelehnt, weil es angeblich schon vorhanden ist. Im Repo ist aber kein 7.2.20-Paket. Das github-workflow-Geraffel entwickelt sich immer mehr zum Zeitfresser und nervt zusehends.
Der Paketbau z.B., der auf meinem Laptop 20 Sek. dauert, dauert auf github 12 Min.! Das ging schon mal schneller. Sieht so aus, als ob die Ressourcen für nichtkommerzielle Nutzer massiv zurückgefahren wurden. Das gefällt mir überhaupt nicht.
Wie auch immer, ich habe das Paket als v7.2.21 nochmal gebaut. Das hat geklappt.
Hallo @thomas ,
beim Versuch unser Produktiv System auf 7.3 zu heben kommt die Fehlermeldung, dass nicht alle updates installiert wurden.
Nun habe ich folgendes gefunden: lmn7.2 und linbo7 auf Version 4.3.3.0
Kann das sein? Hab ich da mal was neues getestet?
Ich kann mit Linbo auf 4.2.16-0 gehen, dann will er aber trotzdem das update verhindern.
Grüße Ralf
root@server:~# apt update
OK:1 https://deb.linuxmuster.net lmn72 InRelease
OK:2 https://deb.linuxmuster.net lmn72-testing InRelease
OK:3 http://archive.ubuntu.com/ubuntu jammy InRelease
OK:4 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
OK:5 http://archive.ubuntu.com/ubuntu jammy-backports InRelease
OK:6 http://archive.ubuntu.com/ubuntu jammy-security InRelease
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Aktualisierung für 1 Paket verfügbar. Führen Sie »apt list --upgradable« aus, um es anzuzeigen.
root@server:~# apt list --upgradable
Auflistung… Fertig
linuxmuster-linbo7/unbekannt 4.3.3-0 all [aktualisierbar von: 4.2.16-0]
N: Es gibt 1 zusätzliche Version. Bitte verwenden Sie die Option »-a«, um sie anzuzeigen.
root@server:~# apt list --upgradable -a
Auflistung… Fertig
linuxmuster-linbo7/unbekannt 4.3.3-0 all [aktualisierbar von: 4.2.16-0]
linuxmuster-linbo7/unbekannt,now 4.2.16-0 all [Installiert,aktualisierbar auf: 4.3.3-0]
root@server:~# /usr/sbin/linuxmuster-release-upgrade | tee /root/migration-to-73.log
############################################################
# #
# ATTENTION! #
# #
# This script upgrades your system to linuxmuster.net 7.3! #
# Make sure you have created a snapshot before. #
# #
############################################################
To continue enter "I have been warned": I have been warned
Paketlisten werden gelesen…
Abhängigkeitsbaum wird aufgebaut…
Statusinformationen werden eingelesen…
0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen und 1 nicht aktualisiert.
Es müssen noch 0 B von 107 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
(Lese Datenbank ... 162409 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../python3-debian_0.1.43ubuntu1.1_all.deb ...
Entpacken von python3-debian (0.1.43ubuntu1.1) über (0.1.43ubuntu1.1) ...
python3-debian (0.1.43ubuntu1.1) wird eingerichtet ...
Scanning processes...
Scanning linux images...
Running kernel seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on this host.
Checking for a new Ubuntu release
Please install all available updates for your release before upgrading.
An error ocurred!
root@server:~# apt update
OK:1 https://deb.linuxmuster.net lmn72 InRelease
OK:2 http://archive.ubuntu.com/ubuntu jammy InRelease
OK:3 https://deb.linuxmuster.net lmn72-testing InRelease
OK:4 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
OK:5 http://archive.ubuntu.com/ubuntu jammy-backports InRelease
OK:6 http://archive.ubuntu.com/ubuntu jammy-security InRelease
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Aktualisierung für 1 Paket verfügbar. Führen Sie »apt list --upgradable« aus, um es anzuzeigen.
root@server:~# apt upgrade
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Paketaktualisierung (Upgrade) wird berechnet… Fertig
Get another security update through Ubuntu Pro with 'esm-apps' enabled:
traceroute
Learn more about Ubuntu Pro at https://ubuntu.com/pro
Die folgenden Pakete sind zurückgehalten worden:
linuxmuster-linbo7
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 1 nicht aktualisiert.
Ups. Woher kommt wohl das Testing?
Jetzt läuft es durch.
In der Anleitung steht noch der Hinweis:
Falls Du das Upgrade ohne Rückmeldungen und manuellen Reboot durchführen möchtest, nutze /usr/sbin/linuxmuster-release-upgrade –force –reboot. Achte darauf, dass nach dem Reboot des Servers ebenfalls die Firewall neu zu starten ist.
Gerade beim Proxmox-Upgrade von v8 auf v9 bin ich wieder über die neue Syntax gestolpert. Es gibt (zumindest unter Debian) offenbar ein Script, das die sources.list(s) (optional) an die neue Syntax anpassen kann: https://pve.proxmox.com/wiki/Upgrade_from_8_to_9
Optional: Modernize apt Repository Sources
You can migrate existing repository sources to the recommended deb822 style format, by running:
→ apt modernize-sources
Ob wir das auf dem v7-Server auch benötigen… wer weiß es?
Viele Grüße,
Michael
ich bin auch der Meinung: 2 Serverlösung ist standart. Der Fileserver wird bei großen Schulen benötigt (Performance nimmt zu, selbst wenn sie auf dem selben Host laufen).
Ich würde sagen, der Kipppunkt liegt bei ca. 1000 Usern. Ab da sollte ein Fileserver ein merkliches Plus an Performance bringen. Ich werde ihn in meiner Schule mal realisieren (1400 User) irgend wann dieses Schuljahr.
Man kann ihn ja dazustellen, wann man will (wir sind schon auf 7.3, aber nohch ohne Fileserver).
LG
Holger
