Read-Only-System
Hallo, hat hier schon mal jemand ein RO-System aufgezogen? Es sollen keine Änderungen über einen Reboot hinaus gespeichert bleiben. /tmp und /var hab ich in nem tmpfs, aber was mach ich mit dem Rest? Einfach RO-Mounten geht schon mal nicht, da der X-Server was nach /etc/X11 schreiben will :/ Gruß Daniel -- Daniel Spannbauer Systemadministration marco Systemanalyse und Entwicklung GmbH Tel +49 8333 9233-27 Fax -11 Rechbergstr. 4-6, D 87727 Babenhausen Mobil +49 171 4033220 http://www.marco.de/ Email ds@marco.de Geschäftsführer Martin Reuter HRB 171775 Amtsgericht München -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 04.03.2019 um 14:32 schrieb Daniel Spannbauer:
Hallo,
hat hier schon mal jemand ein RO-System aufgezogen? Es sollen keine Änderungen über einen Reboot hinaus gespeichert bleiben.
/tmp und /var hab ich in nem tmpfs, aber was mach ich mit dem Rest? Einfach RO-Mounten geht schon mal nicht, da der X-Server was nach /etc/X11 schreiben will :/
Hmmm, in Grunde genommen ist doch jede Live - cd/dvd ein R/O system Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 04.03.2019 um 15:12 schrieb Manfred Kreisl:
Am 04.03.2019 um 14:32 schrieb Daniel Spannbauer:
Hallo,
hat hier schon mal jemand ein RO-System aufgezogen? Es sollen keine Änderungen über einen Reboot hinaus gespeichert bleiben.
/tmp und /var hab ich in nem tmpfs, aber was mach ich mit dem Rest? Einfach RO-Mounten geht schon mal nicht, da der X-Server was nach /etc/X11 schreiben will :/
Hmmm, in Grunde genommen ist doch jede Live - cd/dvd ein R/O system
Manfred
Hi, ich würde versuchen, alles, was beschrieben werden muss, in eine Ramdisk zu packen, AFAIK machen das Livesysteme acu, wenn man genug RAM hat. cu jth -- Joerg Thuemmler -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hmmm, in Grunde genommen ist doch jede Live - cd/dvd ein R/O system
Manfred
Hi,
ich würde versuchen, alles, was beschrieben werden muss, in eine Ramdisk zu packen, AFAIK machen das Livesysteme acu, wenn man genug RAM hat.
cu jth
Danke Leute, Live-System, klar. Da kann ich spicken. Super, vielen Dank. Wieder mal ein Klaps auf den Hinterkopf.... Gruß Daniel -- Daniel Spannbauer Systemadministration marco Systemanalyse und Entwicklung GmbH Tel +49 8333 9233-27 Fax -11 Rechbergstr. 4-6, D 87727 Babenhausen Mobil +49 171 4033220 http://www.marco.de/ Email ds@marco.de Geschäftsführer Martin Reuter HRB 171775 Amtsgericht München -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 04.03.19 um 15:28 schrieb Daniel Spannbauer:
Danke Leute, Live-System, klar. Da kann ich spicken.
Super, vielen Dank. Wieder mal ein Klaps auf den Hinterkopf....
Ich glaube eher nicht, dass das ein einfaches Projekt wird. Ein Live-System allein reicht z.B. nicht, denn man muss zusätzlich das Live-System mit einem normalen System vergleichen oder besser noch schauen, wie das Live-System erstellt wurde. Für Ubuntu gibt es ein Paket Overlayroot, mit dem man ein Read-Only-System aufsetzen kann. https://spin.atomicobject.com/2015/03/10/protecting-ubuntu-root-filesystem/ https://packages.ubuntu.com/de/xenial/overlayroot Mit dem Paket Overlayroot schraubt man im wesentlichen an der Initramfs herum, sodass Schreibzugriffe auf dem Overlay erfolgen während das darunterliegende Root-Filesystem Read-Only bleibt. Für openSUSE wäre ein solches Paket auch wünschenswert. Vielleicht hilft es als Vorlage für openSUSE-Lösungen. Halte uns mal auf den Laufenden, falls Du mit einer Lösung vorankommst. Mich würde ein Read-Only-Setup auch interessieren. Björn -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 03/04/2019 um 03:28 PM schrieb Daniel Spannbauer:
Hmmm, in Grunde genommen ist doch jede Live - cd/dvd ein R/O system
Manfred
Hi,
ich würde versuchen, alles, was beschrieben werden muss, in eine Ramdisk zu packen, AFAIK machen das Livesysteme acu, wenn man genug RAM hat.
cu jth
Danke Leute, Live-System, klar. Da kann ich spicken.
Super, vielen Dank. Wieder mal ein Klaps auf den Hinterkopf....
Live-System fällt aus...die packen alles in eine große Ramdisk. Vermutlich mit KIWI. Die Dokumentation zu KIWI ist mal wieder (wie leider bei vielen Linux-Projekten) ziemlich mies. Man kriegt ne Anleitung, wie man mit vorgefertigter Config irgendwelche Images erstellt. Aber wie die Konfig aufgebaut ist konnte ich bis jetzt nicht rausfinden.... Ein Drama mal wieder... GRuß Daniel -- Daniel Spannbauer Systemadministration marco Systemanalyse und Entwicklung GmbH Tel +49 8333 9233-27 Fax -11 Rechbergstr. 4-6, D 87727 Babenhausen Mobil +49 171 4033220 http://www.marco.de/ Email ds@marco.de Geschäftsführer Martin Reuter HRB 171775 Amtsgericht München -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 05.03.2019 um 10:32 schrieb Daniel Spannbauer:
Am 03/04/2019 um 03:28 PM schrieb Daniel Spannbauer:
Hmmm, in Grunde genommen ist doch jede Live - cd/dvd ein R/O system
Manfred
Hi,
ich würde versuchen, alles, was beschrieben werden muss, in eine Ramdisk zu packen, AFAIK machen das Livesysteme acu, wenn man genug RAM hat.
cu jth
Danke Leute, Live-System, klar. Da kann ich spicken.
Super, vielen Dank. Wieder mal ein Klaps auf den Hinterkopf....
Live-System fällt aus...die packen alles in eine große Ramdisk. Vermutlich mit KIWI. Die Dokumentation zu KIWI ist mal wieder (wie leider bei vielen Linux-Projekten) ziemlich mies. Man kriegt ne Anleitung, wie man mit vorgefertigter Config irgendwelche Images erstellt. Aber wie die Konfig aufgebaut ist konnte ich bis jetzt nicht rausfinden....
Ein Drama mal wieder...
GRuß
Daniel
Hi, deshalb denke ich ja, Du solltest die Ramdisk selbst bauen. Soviel schreiben wirst Du doch nicht... erstmal /var/[log|spool|...] und alles, was er sonst noch anmeckert, naja und Deinen Benutzer, das alles in die Ramdisk kopieren und die Verzeichnisse dann mounten... Ist sicher ein bisschen Fummelei, aber Kiwi habe ich mir auch mal angesehen, ist auf jeden Fall auch Einarbeitung nötig. Ein anderer Weg ist natürlich auch eine virtuelle Maschine... einmal erstellen, abziehen, bei jedem Neustart das gesicherte Image über das aktuelle drüberbügeln und die VM damit starten... Wenn es nicht Suse sein muss, Knoppix kann man sich IMHO zurechtfummeln und dann wieder ein Knoppix-Image erstellen, ich entsinne mich, das mal probiert zu haben, war sehr funktionell... kann man dann als Image von der Platte starten lassen... sollte mit dd zu machen sein... cu jth -- Joerg Thuemmler -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 04.03.19 um 15:28 schrieb Daniel Spannbauer:
Danke Leute, Live-System, klar. Da kann ich spicken.
Super, vielen Dank. Wieder mal ein Klaps auf den Hinterkopf....
Ich glaube eher nicht, dass das ein einfaches Projekt wird. Ein Live-System allein reicht z.B. nicht, denn man muss zusätzlich das Live-System mit einem normalen System vergleichen oder besser noch schauen, wie das Live-System erstellt wurde. Für Ubuntu gibt es ein Paket Overlayroot, mit dem man ein Read-Only-System aufsetzen kann. https://spin.atomicobject.com/2015/03/10/protecting-ubuntu-root-filesystem/ https://packages.ubuntu.com/de/xenial/overlayroot Mit dem Paket Overlayroot schraubt man im wesentlichen an der Initramfs herum, sodass Schreibzugriffe auf dem Overlay erfolgen während das darunterliegende Root-Filesystem Read-Only bleibt. Für openSUSE wäre ein solches Paket auch wünschenswert. Vielleicht hilft es als Vorlage für openSUSE-Lösungen. Halte uns mal auf den Laufenden, falls Du mit einer Lösung vorankommst. Mich würde ein Read-Only-Setup auch interessieren. Björn -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Daniel, hallo zusammen, Am Montag, 4. März 2019, 14:32:07 CET schrieb Daniel Spannbauer:
hat hier schon mal jemand ein RO-System aufgezogen? Es sollen keine Änderungen über einen Reboot hinaus gespeichert bleiben.
/tmp und /var hab ich in nem tmpfs, aber was mach ich mit dem Rest? Einfach RO-Mounten geht schon mal nicht, da der X-Server was nach /etc/X11 schreiben will :/
Guck Dir mal das Paket transactional-update an. Das macht zwar eigentlich[tm] was anderes (das System ist read-only, Systemupdate werden in einem neuen btrfs-Snapshot gemacht, der dann beim nächsten Booten aktiv wird) - aber wenn Du immer den gleichen Snapshot bootest, dürfte es Deinen Anforderungen ziemlich nahekommen. Vielleicht (ungetestet!) reicht es sogar, wenn Du beim Shutdown jeweils das overlayfs löschst - wo genau das liegt, darfst Du selbst rausfinden ;-) BTW: Nix gegen ein RO-System, aber behalte bitte im Hinterkopf, dass Du auch Sicherheitsupdates etc. installieren solltest ;-) Gruß Christian Boltz -- Da hast Du doch nicht allen Ernstes erwartet, dass nach 8 Jahren (6 davon angeblich schon stabil und produktiv benutzbar) bei dem KDE4-Gemurkse so etwas ganz einfaches, was bei jedem anderem MUA Standard ist, auf ein mal bei Kmail von einer Version auf die andere funktioniert? [Thomas Lueck in opensuse-de] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 06.03.2019 um 21:13 schrieb Christian Boltz:
Hallo Daniel, hallo zusammen,
Am Montag, 4. März 2019, 14:32:07 CET schrieb Daniel Spannbauer:
hat hier schon mal jemand ein RO-System aufgezogen? Es sollen keine Änderungen über einen Reboot hinaus gespeichert bleiben.
/tmp und /var hab ich in nem tmpfs, aber was mach ich mit dem Rest? Einfach RO-Mounten geht schon mal nicht, da der X-Server was nach /etc/X11 schreiben will :/
Guck Dir mal das Paket transactional-update an. Das macht zwar eigentlich[tm] was anderes (das System ist read-only, Systemupdate werden in einem neuen btrfs-Snapshot gemacht, der dann beim nächsten Booten aktiv wird) - aber wenn Du immer den gleichen Snapshot bootest, dürfte es Deinen Anforderungen ziemlich nahekommen.
So etwas in der Art ist mir auch kurz in den Sinn gekommen (da gab es letztes Jahr mal einen Artikel in der c't), aber ich fand das als ich den Artikel las schon irgendwie schwachsinnig (das erinnert mich so an Windows, jedes Update erfordert einen Reboot) und meine Meinung hat sich da noch nicht geändert. Darum habe ich den Gedanken gleich wieder verworfen, dieses in den Ring zu werfen.
Vielleicht (ungetestet!) reicht es sogar, wenn Du beim Shutdown jeweils das overlayfs löschst - wo genau das liegt, darfst Du selbst rausfinden ;-)
BTW: Nix gegen ein RO-System, aber behalte bitte im Hinterkopf, dass Du auch Sicherheitsupdates etc. installieren solltest ;-)
Dafür einfach das Filesystem r/w remounten und Update durchführen. Sollte das Problem nicht sein, sofern das Filesystem das zulässt Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Manfred, hallo zusammen, Am Mittwoch, 6. März 2019, 21:26:33 CET schrieb Manfred Kreisl:
Am 06.03.2019 um 21:13 schrieb Christian Boltz:
Guck Dir mal das Paket transactional-update an. Das macht zwar eigentlich[tm] was anderes (das System ist read-only, Systemupdate werden in einem neuen btrfs-Snapshot gemacht, der dann beim nächsten Booten aktiv wird) - aber wenn Du immer den gleichen Snapshot bootest, dürfte es Deinen Anforderungen ziemlich nahekommen.
So etwas in der Art ist mir auch kurz in den Sinn gekommen (da gab es letztes Jahr mal einen Artikel in der c't), aber ich fand das als ich den Artikel las schon irgendwie schwachsinnig (das erinnert mich so an Windows, jedes Update erfordert einen Reboot) und meine Meinung hat sich da noch nicht geändert. Darum habe ich den Gedanken gleich wieder verworfen, dieses in den Ring zu werfen.
Das kommt auf den Einsatzzweck an ;-) transactional-updates hat einen großen Vorteil: das Update kann im Hintergrund laufen und hat garantiert keine Auswirkungen aufs laufende System. Ursprünglich wurde transactional-updates für openSUSE Kubic [1] entwickelt, aber vorhin wäre es mir auch für mein Tumbleweed-System recht gewesen - ein KDE-Update bei laufendem KDE kann zu lustigen Effekten führen ;-) Größter Nachteil ist IMHO, dass man nicht "spontan" ein Paket nachinstallieren kann, sondern danach immer rebooten muss. Bei Updates würde mich das nichtmal stören (ich schalte den Laptop eh zweimal am Tag ein und wieder aus), aber wenn mal ein Paket fehlt, nervt die Reboot-"Pflicht" schon. Das war dann auch der (einzige) Grund, warum ich mich gegen transactional-updates entschieden habe. Auch bei "einzelnen" Servern würden mich die häufigen Reboots nerven, aber bei einer Kubic-Serverfarm, auf der ein Haufen Container laufen (und vor dem Reboot eines Servers automatisch auf einen anderen verschoben werden), sind die Reboots harmlos und besser als Prozesse in schwer definierbarem Zustand, denen ein paar Dateien unterm Hintern weggelöscht oder ausgetauscht wurden ;-) Gruß Christian Boltz [1] https://en.opensuse.org/Portal:Kubic -- That'll be a lot of facepalming today. [Jan Engelhardt in opensuse-factory] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Das kommt auf den Einsatzzweck an ;-)
transactional-updates hat einen großen Vorteil: das Update kann im Hintergrund laufen und hat garantiert keine Auswirkungen aufs laufende System. Ursprünglich wurde transactional-updates für openSUSE Kubic [1] entwickelt, aber vorhin wäre es mir auch für mein Tumbleweed-System recht gewesen - ein KDE-Update bei laufendem KDE kann zu lustigen Effekten führen ;-)
Größter Nachteil ist IMHO, dass man nicht "spontan" ein Paket nachinstallieren kann, sondern danach immer rebooten muss. Bei Updates würde mich das nichtmal stören (ich schalte den Laptop eh zweimal am Tag ein und wieder aus), aber wenn mal ein Paket fehlt, nervt die Reboot-"Pflicht" schon. Das war dann auch der (einzige) Grund, warum ich mich gegen transactional-updates entschieden habe.
Auch bei "einzelnen" Servern würden mich die häufigen Reboots nerven, aber bei einer Kubic-Serverfarm, auf der ein Haufen Container laufen (und vor dem Reboot eines Servers automatisch auf einen anderen verschoben werden), sind die Reboots harmlos und besser als Prozesse in schwer definierbarem Zustand, denen ein paar Dateien unterm Hintern weggelöscht oder ausgetauscht wurden ;-)
Das ganze wird kein Arbeitssystem. ICh muss von einem Stick oder einer CF-Card ein System booten und einen HArdwaretest von uns laufen lassen. Der spuckt ein Protokoll aus und das wird gespeichert. Ich will mir nur nicht den Stick mit irgendwelchen Log-Files oder sonstigen (z.B. automatisch erstellten UDEV-Device-Zuordnungen) den Speicherplatz zublasen. Drum sollte nach dem Shutdown alles wieder beim alten sein. Das DIng kommt nicht ans Netz, Systemupdates braucht es also nicht. Gruß Daniel -- Daniel Spannbauer Systemadministration marco Systemanalyse und Entwicklung GmbH Tel +49 8333 9233-27 Fax -11 Rechbergstr. 4-6, D 87727 Babenhausen Mobil +49 171 4033220 http://www.marco.de/ Email ds@marco.de Geschäftsführer Martin Reuter HRB 171775 Amtsgericht München -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (5)
-
Bjoern Voigt -
Christian Boltz -
Daniel Spannbauer -
Joerg Thuemmler -
Manfred Kreisl