Hallo,
ein PC soll nur eine bestimmte Anwendung ausführen und die muss lokal
nichts schreiben, man könnte / read-only mounten. Anscheinend muss man
dazu /etc/fstab ändern (geht das wirklich nicht anders?). Es gibt
sowieso ein Script, um alles einzurichten, das sollte also auch die
fstab ändern. Diese Zeilen funktionieren scheinbar, aber das ist mein
erster Versuch mit sed, und, macht man das so?
Bauform B. schrieb:> Anscheinend muss man> dazu /etc/fstab ändern (geht das wirklich nicht anders?).
Eigentlich benutzt man dafür das mount command:
https://man7.org/linux/man-pages/man8/mount.8.html
Das hat auch den Vorteil, dass bei einem Crash Dein System nicht die
geänderte /etc/fstab benutzen würde.
/regards
Bauform B. schrieb:> ein PC soll nur eine bestimmte Anwendung ausführen und die muss lokal> nichts schreiben, man könnte / read-only mounten. Anscheinend muss man> dazu /etc/fstab ändern (geht das wirklich nicht anders?). Es gibt> sowieso ein Script, um alles einzurichten, das sollte also auch die> fstab ändern. Diese Zeilen funktionieren scheinbar, aber das ist mein> erster Versuch mit sed, und, macht man das so?
Du machst solche Dinge ja öfter, deswegen würde ich Dir empfehlen, Dich
in ein Automatisierungsframework wie Ansible einzuarbeiten. Das braucht
nicht mehr als einen SSH-Zugang mit der Möglichkeit zur
Privilegienerweiterung und bietet für Deinen Anwendungsfall das Modul
ansible.builtin.lineinfile [1] an. HF!
[1]
https://docs.ansible.com/ansible/latest/collections/ansible/builtin/lineinfile_module.html
Ein T. schrieb:> in ein Automatisierungsframework wie Ansible einzuarbeiten. Das braucht
Interessant das fuer solchen Pipifax immer gleich grosse Kaliber
herausgeholt werden.
Ein:
mount -o remount,ro /
als root ausgefuehrt, sollte eigentlich reichen.
Wird aber wohl scheitern:
mount: / is busy
Man kann sich sein System so umschnitzen, dass es auch
schon beim Boot nur R/O-gemountet ist. Bei einer "normalen"
Distribution wird das aber wohl in vielen Fehlermeldungen
enden.
Motopick schrieb:> Ein T. schrieb:>> in ein Automatisierungsframework wie Ansible einzuarbeiten. Das braucht>> Interessant das fuer solchen Pipifax immer gleich grosse Kaliber> herausgeholt werden.
Und gleichzeitig auch noch die Nutzung davon fehlerhaft zu propagieren.
Die Nutzung von lineinfile von ansible ist in diesem Fall genauso
unvollständig und fehleranfällig wie das sed Beispiel.
Motopick schrieb:> mount -o remount,ro /> als root ausgefuehrt, sollte eigentlich reichen.
Das wäre vielleicht eine Notlösung, aber
> Man kann sich sein System so umschnitzen, dass es auch> schon beim Boot nur R/O-gemountet ist.
Eben, das kostet genau ein zusätzliches "ro," in der fstab. Das
funktioniert problemlos, wenn man es von Hand einträgt (und natürlich
weiß, wie und wo). Man kann es auch gleich bei der Installation so
einrichten, das wäre die offizielle korrekte Methode. Ich weiß aber
nicht, ob man dafür mit priority=low installieren müsste. Daher dieser
Versuch mit sed.
> Bei einer "normalen" Distribution wird das aber wohl in vielen> Fehlermeldungen enden.
Jein, seit /run benutzt wird, funktionieren viele Dinge automatisch,
jedenfalls bei Debian. Es bleiben nur ein paar Kleinigkeiten, z.B. will
irgendwer /etc/resolv.conf schreiben und hwclock /etc/adjtime. Aber
egal, hwclock hat für speziellere Konfigurationen noch nie richtig
funktioniert.
G. K. schrieb:> Motopick schrieb:>> Ein T. schrieb:>>> in ein Automatisierungsframework wie Ansible einzuarbeiten. Das braucht>>>> Interessant das fuer solchen Pipifax immer gleich grosse Kaliber>> herausgeholt werden.>> Und gleichzeitig auch noch die Nutzung davon fehlerhaft zu propagieren.> Die Nutzung von lineinfile von ansible ist in diesem Fall genauso> unvollständig und fehleranfällig wie das sed Beispiel.
nur genauso fehleranfällig ist aber sehr optimistisch ;)
Andreas H. schrieb:> Eigentlich benutzt man dafür das mount command:> Das hat auch den Vorteil, dass bei einem Crash Dein System nicht die> geänderte /etc/fstab benutzen würde.
Was bei einem Crash benutzt wird, ist mir ziemlich egal. In dem Fall
muss man mit allem rechnen, da kommt es auf das read-only auch nicht
mehr an. Im Gegenteil, man kann weniger kaputt machen.
Das "remount,ro" sollte so früh wie möglich passieren, aber natürlich
nachdem das init-System es / read-write gemountet hat. Also irgendwo
mitten im Bootvorgang. Im Zweifelsfall wird vielleicht /etc/resolv.conf
noch überschrieben und das kann dann nicht korrigiert werden oder sowas.
> Das "remount,ro" sollte so früh wie möglich passieren, aber natürlich> nachdem das init-System es / read-write gemountet hat. Also irgendwo> mitten im Bootvorgang.
Hast du es denn schon einmal probiert?
Nach einem R/W-Mount ist das Filesystem in Benutzung, und laesst
sich nicht mehr einfach R/O-(re)mounten.
Wenn deine benutzte Distri mit Root R/O startet dann hast du
doch schon was du willst.
Wenn die Eintraege in resolv.conf und adjtime so passen...
Motopick schrieb:>> Das "remount,ro" sollte so früh wie möglich passieren, aber natürlich>> nachdem das init-System es / read-write gemountet hat.> Hast du es denn schon einmal probiert?
Jein. Ich lasse das init-System read-only mounten, und kann dann
jederzeit remount,rw - schreiben - remount,ro.
> Nach einem R/W-Mount ist das Filesystem in Benutzung, und laesst> sich nicht mehr einfach R/O-(re)mounten.
Einfach ist relativ. Während ich das hier schreibe, sagt mir lsof, dass
nur eine einzige Datei in $HOME/.cache zum Schreiben offen ist! Auf die
kann ich verzichten. Woran könnte es sonst noch scheitern? Aber egal,
das gehört in die fstab.
> Wenn deine benutzte Distri mit Root R/O startet dann hast du> doch schon was du willst.
Beinahe. Das funktioniert ja, nur wie bekomme ich das "ro," per Script
in die fstab?
> Wenn die Eintraege in resolv.conf und adjtime so passen...
Die werden passend gemacht, das ist nur Fleißarbeit.
Sehr interessantes Thema.
Im Embedded Bereich ist RO gar nicht mal so unüblich. Oft sind es
Firewalls oder Steuergeräte, welche grundsätzlich nur lesend arbeiten.
Zur Konfuguration wird ein remount-rw aufgerufen, umkonfiguriert,
anschließend wieder mit remount-ro dicht gemacht.
Ich muss gestehen den Aufbau bisher nie genauer angeschaut zu haben.
Spontan fällt mir die Mini-Distro Voyage ein. Die hat es, dort könnte
man sich die config und das remount script anschauen.
Beim Raspberry gab es auch ein paar ähnlich Ansätze. Um die sdcard zu
schonen ging es mit To-RAM und dann ein persistence bzw. sync beim
shutdown.
@bauformb Auf Basis von Dateirechten d.h. Gruppenzugehörigkeit wäre
vielleicht ein einfacher Ansatz.
Sowas wie chmod u+rwx,g-w,o- /srv
Bauform B. schrieb:> Diese Zeilen funktionieren scheinbar, aber das ist mein erster Versuch> mit sed, und, macht man das so?>> sed "$backup" 's/ \/ ext4 [a-z].*$/ \/ ext4 ro,noatime 0 1/'> fstab>> Eine frische fstab sieht ungefähr so aus, aber in den options kann ja> alles mögliche stehen, nur defaults oder noatime und wer-weiß-was
Im Prinzip würde ich es auch so machen. Aber ist es beabsichtigt dass
egal welche Optionen in der Datei stehen, die durch "ro,noatime 0 1"
ersetzt werden sollen? Falls nicht, würde ich entweder
a) den linken Teil vom s/// so explizit schreiben dass er nur auf die
bekannte Zeile matcht, und mir anderenfalls eine Warnung ausgeben
lassen, dann kann ich entscheiden wie es dann geändert werden soll, oder
b) den Ausdruck so umschreiben dass er nur das "ro," an passender Stelle
einfügt
Ansonsten noch: außer Leerzeichen könnten auch Tabs vorkommen
Drago S. schrieb:> Im Embedded Bereich ist RO gar nicht mal so unüblich. (...)> Zur Konfuguration wird ein remount-rw aufgerufen, umkonfiguriert,> anschließend wieder mit remount-ro dicht gemacht.
Ja, das dachte ich bis gerade eben auch, und dann
Drago S. schrieb:> Sowas wie chmod u+rwx,g-w,o- /srv
Jetzt hast du mich völlig verwirrt.
Warum gibst du noch irgendwem Schreibrechte?
Die sind doch garnicht nötig, weil niemand schreiben will.
Wenn sowieso niemand schreibt, muss man das nicht verbieten.
Wenn man nichts verhindern muss, ist read-only unnötig.
Was wird mit read-only besser, warum macht man das?
OK, im Superblock von ext4 gibt es Daten wie "Last mount time" und
"Mount count", also wird der Superblock normalerweise geschrieben. Das
könnte man mit ro sparen, aber sonst?
Mathias A. schrieb:> Aber ist es beabsichtigt dass egal welche Optionen in der Datei> stehen, die durch "ro,noatime 0 1" ersetzt werden sollen?
Ja, das ist Absicht. errors=remount-ro und evt. discard fehlen hier
noch, aber auf jeden Fall ist festgelegt, was hinterher drin stehen
soll.
> Ansonsten noch: außer Leerzeichen könnten auch Tabs vorkommen
Natürlich, vielen Dank für die Warnung. Das sind genau die Sachen, warum
ich die fstab lieber nicht ändern würde.
Bauform B. schrieb:> Was wird mit read-only besser, warum macht man das?
Meine Suchmaschine liefert genau eine einzige (falsche) Antwort:
"Why mount read-only? This can be handy if for example you want to look
up files in your backups while making sure that you cannot accidentally
add, change or delete files in the backup."
Ja, ok, dafür, meinetwegen.
Ohne read-only könnte man die "Last mount time" als RTC-Ersatz
missbrauchen, so ähnlich wie fake-hwclock das macht. Also, warum?
Bauform B. schrieb:> Drago S. schrieb:>> Sowas wie chmod u+rwx,g-w,o- /srv>> Jetzt hast du mich völlig verwirrt.> Warum gibst du noch irgendwem Schreibrechte?> Die sind doch garnicht nötig, weil niemand schreiben will.> Wenn sowieso niemand schreibt, muss man das nicht verbieten.> Wenn man nichts verhindern muss, ist read-only unnötig.> Was wird mit read-only besser, warum macht man das?
Weil der Mountpoint immer root gehört.
root darf, soll und muss.
User(s) darf oder auch nicht.
Von other halte ich nichts, die dürfen bei mir gar nichts.
Verwechsle bitte nicht den Mountpoint und das gemoutete device.
Die /etc/fstab lässt du wie sie ist, also /srv bekommt sein rw bzw. ein
default
sudo umount /srv
sudo chmod u+rwx,g-w,o- /srv
sudo chown root:dieusergruppe /srv
sudo mount /srv
sudo adduser deinuser dieusergruppe
sudo chown -R deinuser:dieusergruppe /srv/*
chmod -R u-w,g-w,o- /srv/* # notfalls bügelst du jetzt alles gerade
> nur wie bekomme ich das "ro," per Script> in die fstab?
Warum muss das unbedingt per Script sein?
Wenn das System mit Root R/O laueft, klappt das eh nicht. :)
Da ist die fstab ja dann auch R/O.
Wenn man etwas "dynamisch" umkonfigurieren will, dann per
mount mit passenden Optionen.
>> Wenn die Eintraege in resolv.conf und adjtime so passen...> Die werden passend gemacht, das ist nur Fleißarbeit.
Die Fleissarbeit an der adjtime leistet eigentlich NTP.
Am besten ist es wohl, ganz auf adjtime zu verzichten.
Ein "flascher" Wert in der adjtime sorgt sonst fuer eine
permanent falsch gehende Uhr wenn NTP nicht laueft.
Bauform B. schrieb:>> Bei einer "normalen" Distribution wird das aber wohl in vielen>> Fehlermeldungen enden.>> Jein, seit /run benutzt wird, funktionieren viele Dinge automatisch,> jedenfalls bei Debian. Es bleiben nur ein paar Kleinigkeiten, z.B. will> irgendwer /etc/resolv.conf schreiben und hwclock /etc/adjtime. Aber> egal, hwclock hat für speziellere Konfigurationen noch nie richtig> funktioniert.
Und noch einige andere Dinge. Siehe https://wiki.debian.org/ReadonlyRoot
Bauform B. schrieb:> Was wird mit read-only besser, warum macht man das?
Gute Frage, hatte ich bisher noch garnicht hinterfragt -- meine
Vermutung wäre dass man damit verhindern will dass bei Fehlern, sei es
in der Konfiguration oder im Code von irgendwelchen Programmen, dann
doch Schreibvorgänge passieren könnten (nebst den von dir ja schon
genannten Einträgen im Superblock). Wäre aber interessant ob es auch
einen "echten" Grund gibt, und es nicht nur eine Vorsichtsmaßnahme ist?
Motopick schrieb:> Ein T. schrieb:>> in ein Automatisierungsframework wie Ansible einzuarbeiten. Das braucht>> Interessant das fuer solchen Pipifax immer gleich grosse Kaliber> herausgeholt werden.
In Deiner üblichen "Weisheit" ignorierst Du einige wesentliche Teile
meines Hinweises: nämlich, daß unser TO solche Dinge häufiger braucht.
Ich kann mich noch prima an den letzten Thread dieser Art vom TO
erinnern, da ging es um die Einrichtung eines Kiosk-Systems. In jenem
Thread tauchte auch so ein besonders "kluger" Mensch auf und empfahl,
alles -- unter Verletzung des Filesystem Hierarchy Standard -- doch
einfach in /home zu installieren.
> Ein:> mount -o remount,ro /> als root ausgefuehrt, sollte eigentlich reichen.
Genau, und wegen solcher "klugen Ratschläge" wird Linux in gewissen
Kreisen den Ruf nicht los, ein "Frickelsystem" zu sein. Man kann so
etwas natürlich jedes Mal aufs Neue irgendwie hinfrickeln. Allerdings...
> Wird aber wohl scheitern:> mount: / is busy
Ach, sieh an. Man kann so etwas aber auch einfach richtig machen, also:
professionell, reproduzierbar, wartbar und sauber (selbst)dokumentiert.
Muß ja nicht unbedingt mit Ansible sein, das hat als Pushsystem ohne
Agenten halt gewisse Vorteile für die Anwendungsfälle des TO. Und dann
packt man seine Playbooks, Inventories, Konfigurationsdateien und
-templates einfach in ein Versionskontrollsystem, und wenn das nächste
Mal dieselben Aufgaben gelöst werden sollen, muß man nur noch ein paar
Knöpfchen drücken.
G. K. schrieb:> Und gleichzeitig auch noch die Nutzung davon fehlerhaft zu propagieren.> Die Nutzung von lineinfile von ansible ist in diesem Fall genauso> unvollständig und fehleranfällig wie das sed Beispiel.
Wenn Du bessere Ideen hättest, dann könntest Du sie vorschlagen. Aber
dafür reicht es offensichtlich nicht.
Motopick schrieb:>> nur wie bekomme ich das "ro," per Script in die fstab?> Warum muss das unbedingt per Script sein?
Es muss nicht unbedingt sein, offensichtlich ist es einfacher/besser,
das gleich im Debian Installer zu machen. Weil man auch eine
EFI-Partition braucht, kommt man wohl zwangsläufig zu dem Menüpunkt. An
der Stelle muss man dran denken, im postinst Script von meinem .deb
würde es automatisch gehen.
> Wenn das System mit Root R/O laueft, klappt das eh nicht. :)
Muss es ja nicht, dann ist ja schon alles gut und richtig.
> Am besten ist es wohl, ganz auf adjtime zu verzichten.
Meine Rede. Ein Link nach /dev/null macht das ganz gut, unabhängig von
read-only, auf jedem Rechner. Für resolv.conf hat früher mal ein Link
nach /run funktioniert, mal sehen, ob das immer noch geht.
ABER: inzwischen kamen Zweifel auf: was bringt read-only überhaupt?
Bauform B. schrieb:> Drago S. schrieb:>> Sowas wie chmod u+rwx,g-w,o- /srv> Jetzt hast du mich völlig verwirrt
Bauform B. schrieb:> im postinst Script von meinem .deb> würde es automatisch gehen.
Ja, da ist es gut aufgehoben.
> ABER: inzwischen kamen Zweifel auf: was bringt read-only überhaupt?
Ein unkaputtbares root-fs ist fuer manche Anwendung schon unverzichtbar.
Ich habe selbst mal ein Stock-S.u.S.E. 7.0 auf R/O umgebaut, dass
dann unter anderem eins der Systeme auf meinem Notebook war.
Das konnte man zu jedem beliebigen Zeitpunkt ausschalten. :)
> wird Linux in gewissen> Kreisen den Ruf nicht los, ein "Frickelsystem" zu sein
In manchen Kreisen hat Linux mittlerweile ueberhaupt keinen Ruf mehr.
Da laesst man selbst HPC-Anwendungen unter Windows laufen.
Oder Firewalls. Das ist schon gruselig. :)
Und das Zeug wird von noch ahnungsloseren VMWARE-Admins
"zusammengeklickt".
> muß man nur noch ein paar Knöpfchen drücken.
Die sind hoffentlich formschoen und in einer netten Farbe.
Die Arbeit soll ja Spass machen. :)
Bauform B. schrieb:> ABER: inzwischen kamen Zweifel auf: was bringt read-only überhaupt?
Diese Frage müßtest Du Dir selbst beantworten, methinks. Im Grunde
erhöht das die Sicherheit des Systems in mehrlei Hinsicht, zum Beispiel
bei unsauberen Reboots (kein FS-Check nötig), fehlerhafter Software oder
Angriffen. Zudem benötigst Du bei Readonly-Dateisystemen natürlich auch
kein Journaling, und obendrein entfallen die mitunter zeitraubenden
Dateisystemchecks, die Linux bei Reboots regelmäßig ausführt.
Nebenbei sei auf den Kernel-Bootparameter "ro" hingewiesen, der dafür
sorgt, daß das Root-Dateisystem beim Booten readonly gemountet wird,
siehe dazu in Documentation/admin-guide/kernel-parameters.txt. Aber
klar, zuerst wirst Du Dir natürlich Deine Frage beantworten müssen. :-)
Drago S. schrieb:> Ich muss gestehen den Aufbau bisher nie genauer angeschaut zu haben.> Spontan fällt mir die Mini-Distro Voyage ein. Die hat es, dort könnte> man sich die config und das remount script anschauen.
Was soll denn Voyage sein? Finde nur "Voyager". Meinst du die?
> ABER: inzwischen kamen Zweifel auf: was bringt read-only überhaupt?
Ein netter Nebeneffekt ist, dass man das Root-fs fuer nahezu
beliebig viele Klonsysteme per NFS exportieren kann, die dann
per NFS-root ein identisches System ausfuehren.
Das konnte mein Notebook damals natuerlich auch. :)
Und war fuer Wartung/Installation/Troubleshooting anderer Systeme
ueberaus nuetzlich.
Ein T. schrieb:> Im Grunde erhöht das [ro mounten] die Sicherheit des Systems> in mehrlei Hinsicht, zum Beispiel bei unsauberen Reboots> (kein FS-Check nötig), fehlerhafter Software oder Angriffen.
OK, überredet. Es lohnt sich allerdings nur so richtig, wenn /tmp noexec
ist (und trotzdem noch alles funktioniert).
> Nebenbei sei auf den Kernel-Bootparameter "ro" hingewiesen, der dafür> sorgt, daß das Root-Dateisystem beim Booten readonly gemountet wird
Leider hält dieser ro Zustand nicht lange an, wenn in der fstab kein ro
steht.
Motopick schrieb:> Ein netter Nebeneffekt ist, dass man das Root-fs fuer nahezu> beliebig viele Klonsysteme per NFS exportieren kann
Nicht nur per NFS. Man kann es als "Rettungssystem" auf eine zweite
Partition kopieren oder zwecks Fortpflanzung auf einen bootfähigen
USB-Stick.
Joe schrieb:> Was soll denn Voyage sein? Finde nur "Voyager". Meinst du die?
Ja, du hast Recht, es ist Voyager. Tu mal nicht so obergescheit, liefere
lieber weitere Optionen.
So, ich klinke mich an diese Stelle aus. Wieder einmal wird alles von
Schmutzfinken, Besserwissern, Diskutanten und Nörglern zertrampelt ohne
konstruktiven Beitrag einer Lösung.
Wer nicht weis wozu ein System im RO laufen soll, braucht es auch nicht.
Wer nichts von Zugriffs- und Rechteverwaltung hällt, braucht es auch
nicht. Wer seine App nicht unter Kontrolle halten kann, sollte sie nicht
nutzen. Und wer sein OS nicht kennt oder kennenlernen möchte soll bitte
bei Windoofs bleiben. Linux ist kein Frickelsysten sondern endlos
anpassbar. Auf die eigenen Wünsche und Anforderungen.
Viel Glück noch.
Bauform B. schrieb:> Ein T. schrieb:>> [...]> OK, überredet. Es lohnt sich allerdings nur so richtig, wenn /tmp noexec> ist (und trotzdem noch alles funktioniert).
Wenn ein System mit noexec auf /tmp nicht funktioniert, dann ist
irgendwas an dessen Konzept kaputt.
>> Nebenbei sei auf den Kernel-Bootparameter "ro" hingewiesen, der dafür>> sorgt, daß das Root-Dateisystem beim Booten readonly gemountet wird>> Leider hält dieser ro Zustand nicht lange an, wenn in der fstab kein ro> steht.
True. Ich wollte inmitten einer Diskussion, die sich rein auf die
/etc/fstab konzentriert hat, nur darauf hinweisen, daß das
Root-Dateisystem ohne diesen Bootparameter... sagen wir, nicht ganz so
readonly ist wie gedacht. :-)
Ein T. schrieb:> Wenn ein System mit noexec auf /tmp nicht funktioniert, dann ist> irgendwas an dessen Konzept kaputt.
Das kann man so stehen lassen. Leider hat(te?) ausgerechnet debconf
(oder dpkg-reconfigure?) dieses Problem. Man muss immer mit allem
rechnen :(
Ein T. schrieb:> Ich wollte inmitten einer Diskussion, die sich rein auf die> /etc/fstab konzentriert hat, nur darauf hinweisen, daß das> Root-Dateisystem ohne diesen Bootparameter... sagen wir, nicht ganz so> readonly ist wie gedacht. :-)
Wohl wahr, auch das gehört dazu. Obwohl es eine saubere Lösung wäre. Es
ist doch eine Frechheit von irgendeinem init-Mechanismus, dass
/proc/cmdline einfach ignoriert wird ;)
Drago S. schrieb:> Ja, du hast Recht, es ist Voyager. Tu mal nicht so obergescheit, liefere> lieber weitere Optionen.
Haaallooo! Du schreibst was falsch, ich finde deswegen nicht und wenn
ich nachfrage wirst du noch frech. Bist du sicher das bei dir sonst
alles in Ordnung ist?
Motopick schrieb:> Ein netter Nebeneffekt ist, dass man das Root-fs fuer nahezu> beliebig viele Klonsysteme per NFS exportieren kann, die dann> per NFS-root ein identisches System ausfuehren.
Das mache ich auch, per NFS als RO exportieren, inklusive PXE boot.
Auf dem Server habe ich dann aber einen LXC container, der das Ding RW
gemountet hat, und automatisch updated. Ist eine coole Sache, wenn ich
was ändern will, mach ich das in dem Container, und alle PCs haben die
Änderung sofort. Und die PCs können selbst nichts ändern. Hier noch die
fstab:
Ich habe dort einige Configs in ein Verzeichnis verschoben, und einen
Symlink darauf angelegt. Im Container bind mounte ich das Verzeichnis,
um dort andere Configs zu haben. Im Container ist meine fstab leer.
Edit: Das "ovtmp" ist das oben abgehängte Script. Muss unter
/sbin/mount.ovtmp liegen. Mountet ein Overlay, mit tmpfs als backing
store, über das Verzeichnis.
> Auf dem Server habe ich dann aber einen LXC container, der das Ding RW> gemountet hat, und automatisch updated.
Wenn da mal keine Raceconditions dir ins Handwerk pfuschen...
NFS-Root ist aber eigentlich ein ganz alter Hut, den sicher die
Haelfte der Rechner in einem Computermuseum auch schon konnten.
Wurden doch an den Universitaeten die Rechnerpools fuer die Studenten
so betrieben.
Und es gab ja auch Zeiten, wo jedes Megabyte eines USB-Flashsticks
mit einer DM aufgewogen wurde, und moeglicherweise gerade mal
USB-Fullspeed schaffte. Das konnte NFS ueber Ethernet schon lange.
Aber trotzdem QLe Sache. :)
Motopick schrieb:>> Auf dem Server habe ich dann aber einen LXC container, der das Ding RW>> gemountet hat, und automatisch updated.>> Wenn da mal keine Raceconditions dir ins Handwerk pfuschen...
Was soll da racen? Die Frage ist für mich eher, wie die Rechner
mitbekommen, wenn sich was aktualisiert und was dann ggf. neu gestartet
werden muss.
> Und es gab ja auch Zeiten, wo jedes Megabyte eines USB-Flashsticks> mit einer DM aufgewogen wurde, und moeglicherweise gerade mal> USB-Fullspeed schaffte. Das konnte NFS ueber Ethernet schon lange.
Ja, alles lange her. Heut gibt man dann doch lieber jedem Rechner sein
eigenes lokales Root-Verzeichnis, und dann werden die eben ggf. per
Ansible oder so synchron gehalten.
> Aber trotzdem QLe Sache. :)
Ja, irgendwie schon.
Rolf M. schrieb:> Die Frage ist für mich eher, wie die Rechner> mitbekommen, wenn sich was aktualisiert und was dann ggf. neu gestartet> werden muss.
Ja, das Problem habe ich noch nicht gelöst. Ich habe das PXE Boot zeug
zwar eingerichtet, aber ich verwende es nur selten tatsächlich.
Bauform B. schrieb:> Eigentlich ist in meinem Thread jeder willkommen, aber früher ging> man> zum Streiten nach draußen vor die Tür ;)
Nee nee, ich bin vorher rausgegangen und stehe jetzt vor der Tür. Erst
kucken, dann meckern.
Ein T. schrieb:> Du machst solche Dinge ja öfter, deswegen würde ich Dir empfehlen, Dich> in ein Automatisierungsframework wie Ansible einzuarbeiten.
Ack. Einfach Debian-Standardinstallation durchfahren (oder einfach ein
jungfräuliches Image klonen) und danach mit Ansible die spezifischen
Anpassungen machen lassen. BTDT - der initiale Aufwand lohnt sich
ziemlich schnell.
> Das braucht> nicht mehr als einen SSH-Zugang mit der Möglichkeit zur> Privilegienerweiterung und bietet für Deinen Anwendungsfall das Modul> ansible.builtin.lineinfile [1] an. HF!
Örks. Damit kann man das zwar theoretisch auch machen, aber eigentlich
ist für diesen speziellen Zweck doch ansible.posix.mount vorgesehen, das
einem das Leben viel einfacher macht. ;-)
Ralf D. schrieb:> Ein T. schrieb:>> bietet für Deinen Anwendungsfall das Modul>> ansible.builtin.lineinfile [1] an. HF!>> Örks. Damit kann man das zwar theoretisch auch machen, aber eigentlich> ist für diesen speziellen Zweck doch ansible.posix.mount vorgesehen, das> einem das Leben viel einfacher macht. ;-)
Just dieses Modul hat mich letztes oder vorletztes Jahr böse gebissen,
hab aber nicht mehr genau im Kopf, was. IIRC wars irgendwas mit
Newlines, aber vermutlich ist das mittlerweile gefixt?!
Die Jungs der Ansible Community sind ziemlich fix -- ein Kollege hat
letzte Woche einen Feature Request wegen Labels für Docker-Images
eingereicht, der war keine drei Stunden später umgesetzt. :-)
Man kann in der fstab auch label oder UUIDs verwenden. Wenn man bei
seinen Maschinen jeweils immer das selbe bei seinen Partitionen setzt,
kann man die selbe fstab auch einfach kopieren.
Was ich auch mal gemacht habe, war als fstab ein Verzeichnis zu nehmen.
Früher konnte fstab kurzfristig mal mit /etc/fstab.d umgehen, aber der
Support dafür wurde dann recht schnell wieder entfernt. Für den "mount
-T myfstab" bzw. "mount --fstab myfstab" Parameter erlauben aber
weiterhin auch ein Verzeichnis. Deshalb kann man /etc/fstab/ auch durch
ein Verzeichnis ersetzen. Die Dateien darin müssen nur mit .fstab enden.
(Als ich das damals gemacht habe, hatte ich aber einen Symlink von
/etc/fstab/ nach /etc/fstab.d/ gemacht, damit die init Scripte damit
klar kommen. Die kannten /etc/fstab.d/ auch noch).
Daniel A. schrieb:> Früher konnte fstab kurzfristig mal mit /etc/fstab.d umgehen, aber der> Support dafür wurde dann recht schnell wieder entfernt.
Interessant, das ging schon in die richtige Richtung, aber mehr auch
nicht. Es passt für zusätzliche eigene Partitionen. Aber damit man die
Optionen für die root-Partition ändern kann, müsste fstab.d ja Priorität
haben, aber für jede Partition einzeln. Die Regeln dafür waren dann wohl
doch zu kompliziert.
Bauform B. schrieb:> Aber damit man die> Optionen für die root-Partition ändern kann, müsste fstab.d ja Priorität> haben, aber für jede Partition einzeln.
Hat es. https://manpages.org/mount/8> -T, --fstab path> Specifies an alternative fstab file. If path is a directory then the files> in the directory are sorted by strverscmp(3); files that start with "." or> without an .fstab extension are ignored.
Man könnte es also genauso wie bei anderen Configs üblich machen, und
einfach eine Nummer an den Anfang setzen, um die Reihenfolge zu regeln.
Thread beobachten
Seitenaufteilung abschalten