Ich möchte meinen neuen Rechner über die SSD booten und die
Verzeichnisse /home, /var und /tmp auf die HD in eine einzige Partition
legen. Alle übrigen Verzeichnisse sollen (möglichst vom Mint-Installer)
auf der SSD angelegt werden.
Für /home und /var geht das mit bind mounts, wie es unter der 2. Antwort
auf
https://unix.stackexchange.com/questions/131311/moving-var-home-to-separate-partition
beschrieben ist.
/tmp soll nicht auf die SSD und auch nicht in eine eigene Partition auf
der HD. Wie kann ich /tmp auch in die (einzige) Partition auf der HD
verlegen?
Taucher schrieb:> Daraus folgt Verschleiß, den man vermeiden kann.
Ich verstehe die Sorge vor Verschleiss. Aber sie ist in den weitaus
meisten Fällen substanzlos und kein Grund, auf HDD zu gehen.
Ich verwende SSDs seit über 10 Jahren, im Büro und privat. Diese ersten
beiden, lange Zeit täglich genutzte Crucial m4, sind nach wie vor im
Einsatz und immer noch wenig abgenutzt. Eine 970 EVO Plus im seit über
1,5 Jahren gut genutzten Laptop zeigt immer noch 0% Abnutzung. Weitere
ähnlich.
Eine SSD nicht verwenden zu wollen wo sie besonders gut geeignet wäre
wegen Verschleiß. Erinnert mich an meinen Vater der seine neue Brille
nicht trägt weil er sich erst dran gewöhnen muss.
Im Prinzip musst du einfach die fstab anpassen und update-initramfs
ausführen. Und die Ordner an den neuen Ort schieben natürlich. Man kann
die fstab auch direkt bei der Installation editieren.
Das ist mir "im Prinzip" klar. Nur: wie muss ich das für tmp machen? Die
/etc/mtab ist ein ziemlicher Brocken mit vielen tempfs, aber den
Moutpunkt für /tmp finde ich nicht.
Das ganze hat mit mtab nichts zu tun.
1. Erzeuge ein Verzeichnis tmp in der Partition wo du es haben willst.
2. Füge einen entsprechenden mount zu fstab hinzu bzw ändere den
existierenden.
3. update-initramfs -u -k all
4. /tmp leeren
5. reboot
mtab enthält einfach nur die aktuellen Mounts. Wenn da kein /tmp drin
ist heißt das einfach dass tmp aktuell nur ein Verzeichnis unter ist
und kein eigener Mountpoint.
(prx) A. K. schrieb:> Motiv dafür, gerade die für eine SSD interessanten Verzeichnisse auf das> langsame HDD zu legen?
Früher überlegte man, ob und wie man RAM abzweigt, um /tmp dorthin zu
verfrachten - heute legt man /tmp auf die magnetische Platte? Nun ja …
Walter K. schrieb:> Früher überlegte man, ob und wie man RAM abzweigt, um /tmp dorthin zu> verfrachten - heute legt man /tmp auf die magnetische Platte? Nun ja …
It depends.
/tmp wird vom Installer vermutlich sowieso ins RAM gelegt.
Man sollte sich beim Editieren der fstab nicht vertun.
Ein nicht richtig startendes System ist die übliche Folge.
Taucher schrieb:> Und wie kann man bewerkstelligen, was ich im Eingangsposting geschrieben> habe?
Du hast selbst schon festgestellt, dass du mit bind mounts jede
beliebige Directory an eine andere Stelle mounten kannst. Ich wüsste
nicht, weshalb das bei /tmp anders sein sollte.
Ob allerdings ausgerechnet der Installer für ein sich explizit an
normale Anwender richtende Desktopsystem wie Mint eine derartig
exotische Konstruktion fertig anbietet?
Kann schon sein, dass du dann eben nachträglich selbst für den Eintrag
in /etc/fstab sorgen musst. Das sollte freilich gerade bei /tmp sehr
einfach sein, weil im Gegensatz zu /var der vorherige Inhalt irrelevant
ist.
Dipl.-Ing. (Uni) schrieb:> Man sollte sich beim Editieren der fstab nicht vertun.> Ein nicht richtig startendes System ist die übliche Folge.
Bei solchen Experimenten kann es nützlich sein, wenn man es vorher in
einer VM mit snapshot/rollback übt. Oder sich vorsorglich mit einem
recovery boot per grub oder DVD/USB anfreundet.
> Bei solchen Experimenten kann es nützlich sein...
Manche Fehler muss der Anfänger mindestens einmal machen.
Sonst fehlt der Lerneffekt.
Auch das händische Editieren der passwd/shadow kann übel enden.
Wieso willst du überhaupt dieses Setup?
Wenn deine Anwendung nur einmalig Dateien schreibt ist /tmp sowieso eine
schlechte Wahl, auf vielen Systemen liegt das nämlich im RAM. Ggf. wäre
/opt /var die bessere Wahl.
Und wozu Home auf einer magnetischen Platte?
Damit diese bei jedem Aufruf einer z.B. SSH Verbindung für .ssh/config
anlaufen muss?
Wenn du irgendwelche selten genutzen großen Dateien hast kannst du diese
mittels bind mount oder Symlink genauso in deinen Home Ordner leger aber
gerade für die vielen kleinen Dateien die enormen Vorteile einer SSD
nutzen. Mit deinem Setup kannst du auch einfach nur eine HDD benutzen,
der Unterschied wird kaum zu spüren sein.
PS: Ich halte von dieser Aufteilung nach Partitionen (boot/root/EFI
ausgenommen) rein gar nichts, das ist ein Relikt alter Tage, heutzutage
hat man andere Methoden und auf einem Desktop ist das zu 99% Blödsinn.
Genauso die fixe Einbindung einer HDD gerade für /var, das ist einfach
unsinnig. Auch hier würde ich wenn dann einzelne Verzeichnise/Dateien
umbiegen, aber nicht den ganzen Mount.
Peter schrieb:> auf einem Desktop ist das zu 99% Blödsinn.
Yep, sowas ergibt eher bei Servern einen Sinn, damit voll laufende
Anwendungs- oder Log-Filesysteme dem System nicht die Laune verderben.
Wobei er das ja ähnlich sieht und /tmp, /var und /home deshalb auf der
gleichen Partition haben will. Nur eben seltsamerweise auf der dafür
verkehrten Disk.
Ein Kompromiss wäre über LVM machbar. Das sind dann zwar immer noch
getrennte Partitionen, aber bei Bedarf live vergrösserbar, und das
geht dann wohl auch im Installer.
LVM wäre mir zu starr, mag ich persönlich auch nicht sonderlich.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_file_systems/assembly_limiting-storage-space-usage-on-ext4-with-quotas_managing-file-systemshttps://docs.oracle.com/cd/E19253-01/820-2313/gazud/index.html
Es gibt mittlerweile so viele Möglichkeiten. Bind mounts und starre
Partitionen sind da so grob die älteste und unflexibelste Struktur die
man wählen könnte, in den meisten Fällen eh sinnlos. Ich wünsche
spätestens mit richtigen Containern Spaß mit bind mounts, da darf man
dann schön Tabellen mit UID Mapping usw pflegen.
Und wenn deine Anwendungen so ein Müll sind, dass diese 200GB logs
produzieren und dadurch das System lahmlegen, würde ich eher diese fixen
anstatt starre Partitionslayouts aus dem Jahre 2000 auszugraben. ext4
reserviert zum Beispiel für root Speicher per Default, wenn deine
Anwendung nicht als root läuft reicht das in den meisten Fällen schon.
Da kommt dann richtiges Confinement ins Spiel und nicht Methoden aus
irgendeiner Linux Zeitschrift bei der die Autoren gerade so ein Live
Image booten können. cgroups, Filesystem Quota, seccomp usw.
Snaps wären z.B. eine Lösung für das Confinement deiner Anwendung.
(prx) A. K. schrieb:> Wobei er das ja ähnlich sieht und /tmp, /var und /home deshalb auf der> gleichen Partition haben will. Nur eben seltsamerweise auf der dafür> verkehrten Disk.
Na ja, ich setze ja /home nicht bei Null auf, sondern auf einem
Datenbestand von knapp 3 TiB. Die SSD hat nur ein halbe TiB…
Aber vielleicht habt ihr ja einen heißen Tipp, wie man die Daten auf die
SSD bekommt.
Taucher schrieb:> Na ja, ich setze ja /home nicht bei Null auf, sondern auf einem> Datenbestand von knapp 3 TiB. Die SSD hat nur ein halbe TiB…>> Aber vielleicht habt ihr ja einen heißen Tipp, wie man die Daten auf die> SSD bekommt.
Die Frage ist dann eher warum du das ganze Zeug bei /home drin haben
willst.
Irgendwie ist es witzig. Du hast dir eine Zuordnung u Aufteilung in den
Kopf gesetzt an der du partout kein Infragestellen zulässt. Schön. Aber
von jmd der sich selbst so viel Wissen und Erfahrung in diesem Thema
zutraut, dass er seine Einschätzung als indiskutabel ansieht, müsste die
Einrichtung nebenbei in 10 Minuten gemacht sein.
Das passt doch nicht zusammen. Entweder du bist selbst der Experte der
weiß was er tut und warum - dann mach halt.
Oder aber du bist ein Anfänger der schon beim Blick in seine mtab völlig
überfordert ist. Auch ok. Dann tu aber nicht so als wäre dein Plan die
beste Lösung während alle dir sagen dass es Quatsch ist.
Du kommst hier rüber wie ein Typ der mir 3h Vorträge übers Autofahren
hält und ‚worauf es entgegen der Meinung anderer wirklich ankommt‘ - und
dann wissen will wie er jetzt genau den Motor startet.
Taucher schrieb:> Aber vielleicht habt ihr ja einen heißen Tipp, wie man die Daten auf die> SSD bekommt.
Live Distro booten, Partitionen einhängen, Daten bzw. Verzeichnisse an
gewünschte Stellen verschieben, Mountpoints
eintragen/umbiegen/nachtragen*, rebooten und glücklich sein.
*) Wer das nicht packt, startet eine Neuinstallation und schenkt dem
Partitionierungsfenster etwas mehr Aufmerksamkeit - wählt dort seine
Partitionen und trägt Mountpoints ein.
Macht bitte nicht aus jeder Kleinigkeit ein rieeesen
Raumschiff-Entwicklungs-Projekt.
Drago S. schrieb:> Macht bitte nicht aus jeder Kleinigkeit ein rieeesen> Raumschiff-Entwicklungs-Projekt.
Du weißt, dass /tmp kein normales Verzeichnis ist?
Taucher schrieb:> Du weißt, dass /tmp kein normales Verzeichnis ist?
Weisst du es?
Gegenfrage: was verleitet jemanden 3TB im /home vorzuhalten?
Wie wäre es mit aufräumen/archivieren/umverteilen/auf NAS auslagern...
Taucher schrieb:> Wie wärs, wen du dir deinen Kopf über dein eigenes Zeug zerbrichst?
Wie wäre es mit Müll herausbringen? Von Platte (/home, /tmp) und aus der
Küche auch gleich...
Zurück zum Topic: Was soll ein nichtnormales Verzeichnis sein?
Was ist mit der /tmp?
Erzähl mal...
Taucher schrieb:> Du weißt, dass /tmp kein normales Verzeichnis ist?
Wenn tmp nicht gerade auf einer Ramdisk liegt (was du ja offensichtlich
nicht willst), ist es ein ganz normales Verzeichnis. Lediglich ein
sticky bit und ggf ein noexec flag ist gesetzt; das kannst du aber
selbst nachholen mit chmod bzw. in /etc/fstab.
Taucher schrieb:> Aber vielleicht habt ihr ja einen heißen Tipp, wie man die Daten auf die> SSD bekommt.
Wie ich bereits schrieb: eine 0815 Installation mit boot/root auf die
SSD und dann hängst du die paar großen Ordner per Symlink/bind Mount in
dein home Verzeichnis ein.
Firefox usw kannst ja an die entsprechenden Stellen verschieben...
Taucher schrieb:> Ich nutze /tmp mit großen Dateien, die nur einmal kurz benutzt werden –> das erspart das Aufräumen. Daraus folgt Verschleiß, den man vermeiden> kann.
Es gibt zig Systeme die erzeugen zig Log-Einträge auf SSDs und von
Verschleiß habe ich noch nix gehört. Angefangen von Handy bis was auch
immer. Such mal nach 'SSD Lebensdauer'...
Wenn Du einen Ordner beim Runterfahren des Systems z.B. löschen
möchtest, dann kannst Du das mit systemd machen. Beispiel nicht
ausprobiert, aber sieht auf den ersten Blick korrekt aus:
https://www.golinuxcloud.com/run-script-with-systemd-before-shutdown-linux/Taucher schrieb:> Du weißt, dass /tmp kein normales Verzeichnis ist?
Ein Ordner ist ein Ordner. Sowie auch /tmp. Alle Verzeichnisoperationen
funktionieren wie gewohnt.
Taucher schrieb:> Du weißt, dass /tmp kein normales Verzeichnis ist?
Also jetzt bin ich aber gespannt auf die Erklärung. Was bitte ist an
/tmp kein normales Verzeichnis?
> Was bitte ist an /tmp kein normales Verzeichnis?
Ich habe es tatsaechlich schon erlebt, dass die "lokale" Administration
nicht wusste, dass /tmp nur im RAM liegt. Und sich dann "wunderte"
dass die Daten nach einem Reboot weg waren.
Das war in einer Zeit lange vor dem Aufkommen von SSDs und
das "betroffene" Betriebssystem war Solaris. Zu dieser Zeit,
lag /tmp bei den Linuxen nahezu 100 %ig noch auf einer Platte.
Zu den recbt "speziellen" Wuenscnen des TO mag man eigentlich
gar nichts sagen.
Normalerweise haelt man keine 3 TB Daten im "eigenen" /home.
Ausnahmen moegen in wirklichen "Mehrnutzerumgebungen" wie
Lehreinrichtungen aber vorkommen.
Da sind TB-grosse Homeverzeichnisse wohl nichts ungewoehnliches.
Weil die Benutzer eben ihr "ganzes" Zeug nur dort unterbringen
koennen.
> /home, /var und /tmp auf die HD in eine einzige Partition legen
Partition erstellen und z.B. unter /mnt mounten. Dann:
Einfach die Verzeichnisse auf der HD unter /mnt anlegen und mit
loop/bind-Mounta nach /home, /var und /tmp mounten.
Der Mount /mnt muss natuerlich erhalten bleiben.
Idh wuerde schonmal Wetten darauf abschliessen, dass das dem TO
natuerlich auch nicht passt :).
P.S.:
Wenn du vorhaben solltest, ein solches Setup bei einem $KUNDEN
zu duplizieren, koennte es sein, dass die dortige "Aministration"
nur einmal den Kopf schuettelt und mit Verweis auf
z.B. Backup, Security, Bla... das Ansinnen ebenso zuegig
wie umfassend ablehnt.
Cartman schrieb:>> Was bitte ist an /tmp kein normales Verzeichnis?>> Ich habe es tatsaechlich schon erlebt, dass die "lokale" Administration> nicht wusste, dass /tmp nur im RAM liegt. Und sich dann "wunderte"> dass die Daten nach einem Reboot weg waren.> Das war in einer Zeit lange vor dem Aufkommen von SSDs und> das "betroffene" Betriebssystem war Solaris. Zu dieser Zeit,> lag /tmp bei den Linuxen nahezu 100 %ig noch auf einer Platte.
Allerdings liegt /tmp unter Mint standardmäßig nicht im RAM oder?
Cartman schrieb:> Idh wuerde schonmal Wetten darauf abschliessen, dass das dem TO> natuerlich auch nicht passt :).
In auf der in der Eingangsfrage verlinkten Internetseite steht u.a.:
"can someone guide me on this"
Trivial ist die Geschichte nicht, und /tmp sowie etwas blödsinnig
eingerichtet.
Jetzt nicht grundsätzlich - aber:
Ich hatte mal in Windows den Partitionsplatz für das Betriebssystem
etwas zu knapp eingerichtet. Prinzipiell kein Problem, aber ich musste
halt auf ein paar liebgewonnene Programme verzichten. Schönes schlankes
System gewissermaßen.
Jetzt aber die Haskell Plattform: Standardmäßig wird alles über /tmp
ausgepackt (oder /temp) und da reicht der knapp bemessene Platz für das
OS nicht mehr.
Man musste also den automatischen Eintrag auf einen Bereich, wo mehr
Platz ist (z.B. einen USB-Stick) umbiegen. Ist das erledigt, dann kommt
die Meldung in etwa "Windows zu alt" (Windows ME). Naja, schade.
/tmp muss man sich ja sinnvollerweise als "Neuanfang bei Reboot" denken.
Also nichts festes.
Aber irgendwie müsste man /tmp auch umleiten können, bzw. swappen, was
auch nicht so einfach zu sein scheint.
Ich habe unter Linux ein ganz ähnliches Problem mit Steam und Wine.
Eigentlich brauche ich nur die größere HD um sie für /home zu nutzen,
d.h. es wäre schön, am unproblematischsten, wenn /home von der SSD
einfach auf die größere Platte swappen könnte.
Unmöglich ist das alles nicht - Arroganz oder Persönlichkeitsdiagnostik
aus dem Kaugummiautomaten sind hier fehl am Platz (ich nutze da eher
mein Know How aus der Persönlichkeitspsychologie und weiß genau, dass
selbst diese professionellen Programme da recht schwammig oder
fragwürdig sind - was ja auch ganz OK ist).
Dieter D. schrieb:> Allerdings liegt /tmp unter Mint standardmäßig nicht im RAM oder?
Bei mir (Mint 19.2) ist /tmp nicht in der Ausgabe von mount/mtab
aufgelistet, es sind aber nur Dateien vorhanden, die nach dem letzten
Neustart erstellt wurden.
Mint / Ubuntu Standardinstallationen: Nur ein Filesystem, kein Mount,
kein Symlink. Aber systemd räumt auf, siehe /usr/lib/tmpfiles/tmp.conf
und
man systemd-tmpfiles
man tmpfiles.d
Reinhard S. schrieb:> Dieter D. schrieb:>> Allerdings liegt /tmp unter Mint standardmäßig nicht im RAM oder?>> Bei mir (Mint 19.2) ist /tmp nicht in der Ausgabe von mount/mtab> aufgelistet, es sind aber nur Dateien vorhanden, die nach dem letzten> Neustart erstellt wurden.
Ergo ein stinknormaler Ordner dessen Inhalt beim Herunterfahren gelöscht
wird..
Und wer den jetzt gern woanders haben will schreibt einfach einen (bind)
mount in die fstab. Fertig.
Pepe schrieb:> Wie kommt man in der zeit wo 1gb SSD 70 eur kosten auf die idee eine HDD> einzubauen?
70€ für 1 GB ist aber teuer...
Aber vielleicht reicht dem TO ja 1 TB auch nicht und als Datengrab will
er halt was richtig großes, was als SSD halt auch noch richtig teuer
ist.
> > Wie kommt man ... auf die idee
Unter anderem bricht die Schreibleistung einer SSD oberhalb eines
gewissen Schwellwertes recht dramatisch ein.
Kommerziell loest man das einfach durch Striping und eine gewisse
Ueberdimensionierung des Platzes auf der/n SSD.
Des weiteren fallen SSDs auch einem Sparzwang der Hersteller zum
Opfer, die bewaehrte Technologien durch andere ersetzen.
Das was fuer bisherige Generationen galt, kann morgen nichts mehr
wert sein.
> Aber irgendwie müsste man /tmp auch umleiten können, bzw. swappen, was> auch nicht so einfach zu sein scheint.
Doch ist es. Einfach einen CMD.EXE starten und ein:
set TEMP=C:\TMP ggfs. auch ein set TMP=C:\TMP ausfuehren
und dann im selben(!) CMD beherzt SETUP.EXE starten.
Von wenigen "duemmlichen" Ausnahmen, wie nicht anders zu erwarten
von M$ selbst, sollte dann alles seinen Gang gehen.
Cartman schrieb:> Unter anderem bricht die Schreibleistung einer SSD oberhalb eines> gewissen Schwellwertes recht dramatisch ein.
Böte es sich im Kontext dieses Threads also an, eine HDD als
Schreib-Cache für eine SSD zu verwenden? ;-)
Ach so: Bei Altsystemen CMD.EXE durch COMMAND.COM ersetzen.
Bei diesem Altzeug habe ich immer noch eine externe schnelle (15k)
146 GB-SCSI-Platte in stiller Reserve. Das reicht auch
als TMP fuer die Installation groesserer Software z.B.
Altera Quartus Pro wo der Installer schon 67 GB gross ist.
> Böte es sich im Kontext dieses Threads also an, eine HDD als> Schreib-Cache für eine SSD zu verwenden? ;-)
Solche Gedankengaenge sind dem TO sicher nicht fremd.
Bei mir: Wenn es eine "unregelmaessige" Uebung ist, also
z.B. ein Imagebackup anfertigen: Platte.
Die hat nebenbei auch als Einzelstueck mehr Platz.
Wenn es "regelmaessig" von normalen Nutzern genutzt wird:
SSD-Stripe.
Drago S. schrieb:> Um das ganze abzukürzen:> …>> Und hört bitte auf 'bind' mit 'mount" zu vertauschen - das sind 2 Paar> Schuhe.
Ähm, er wollte nicht wissen wie man tmp in den RAM legt. Und wer
vertauscht bind mit mount? Ich habe es zusammen genannt weil er eben das
eine oder das andere braucht, je nachdem ob tmp nun eine eigene
Partition oder nur ein Verzeichnis auf einer anderen Partition sein
soll.
> Wenn es "regelmaessig" von normalen Nutzern genutzt wird:> SSD-Stripe.
Um das mit Zahlen zu unterlegen:
Fuer eine, im weitesten Sinne physikalische Berechnung,
gehen ca. 2 TB Rohdaten ein, ueber die dann gerechnet wird.
In der Summe entstehen dabei 10 - 16 TB Daten auf den SSDs.
Es kann passieren, dass 2 - 3 von diesen Rechnungen/Daten
vorgehalten werden muessen:
Da stecken dann 8 x 8 TB SSDs im Rechner.
Dabei kommt es weder beim "Einlesen" noch bei der "Rechnung"
zu diesen Einbruechen. Ausserdem ergeben sich exquisite
Lese-/Schreibleistungen.
Als weiteres "Zwischenlager" stehen nochmal ca. 100 TB an HD
ueber SAS angeschlossen bereit.
(prx) A. K. schrieb:> Das Kindchen heisst aber nun einmal bind mount.
bind ist nicht für diesen Fall da.
Mit bind hängt man etwas in die Struktur hinein. Nicht on top, als
Mountpoint.
z.B. das eingehängte Audioarchiv in die /home/$USER/Musik.
Drago S. schrieb:> (prx) A. K. schrieb:>> Das Kindchen heisst aber nun einmal bind mount.> bind ist nicht für diesen Fall da.>> Mit bind hängt man etwas in die Struktur hinein. Nicht on top, als> Mountpoint.> z.B. das eingehängte Audioarchiv in die /home/$USER/Musik.
Du bringst hier gerade alles durcheinander. Er will wenn bestimmtes
Verzeichnis auf einer HDD als tmp nutzen. Dafür braucht er einen bind
mount
> Das Kindchen heisst aber nun einmal bind mount.
In den aelteren Dialekten auch noch: loop mount.
Wobei das Linux loop mount noch etwas anderes meint und ist.
Cartman schrieb:>> Wenn es "regelmaessig" von normalen Nutzern genutzt wird:>> SSD-Stripe.>> Da stecken dann 8 x 8 TB SSDs im Rechner.>> Als weiteres "Zwischenlager" stehen nochmal ca. 100 TB an HD> ueber SAS angeschlossen bereit.
Also ein ganz normaler Nutzer von nebenan. ;-)
Meine verehrten Damen und Herren, sehen Sie heute Drago S. in:
„Wie gebe ich TO eine Anleitung für etwas was er gar nicht wollte und
erkläre allen anderen wie falsch sie liegen, während ich die Frage noch
nicht mal verstanden habe“ 😂
Dieter D. schrieb:> Du bringst hier gerade alles durcheinander. Er will wenn bestimmtes> Verzeichnis auf einer HDD als tmp nutzen. Dafür braucht er einen bind> mount
Naja.
Für solche Spezialanforderungen gibt es 'mktemp'.
Und für den TO habe ich extra size=1g eingetragen. Was man natürlich
nicht macht, er aber braucht.
Dieter D. schrieb:> Meine verehrten Damen und Herren, sehen Sie heute Drago S. in:
Dieter, lass gut sein.
> Also ein ganz normaler Nutzer von nebenan. ;-)
Naja, es ist nicht nur ein Rechner. Es sind schon ein paar. :)
Und es werden noch mehr.
Schneller, hoeher und weiter! Auf zum Atem!
Drago S. schrieb:> Dieter D. schrieb:>> Du bringst hier gerade alles durcheinander. Er will wenn bestimmtes>> Verzeichnis auf einer HDD als tmp nutzen. Dafür braucht er einen bind>> mount> Naja.> Für solche Spezialanforderungen gibt es 'mktemp'.> Und für den TO habe ich extra size=1g eingetragen. Was man natürlich> nicht macht, er aber braucht.>> Dieter D. schrieb:>> Meine verehrten Damen und Herren, sehen Sie heute Drago S. in:> Dieter, lass gut sein.
Er will keine ramdisk. Wie kommst du da drauf? 😂👌
Ich meine nix für ungut. Vielleicht liege ich ja falsch. Dann lasse ich
es mir gerne erklären. Bin kein Linux Profi. Aber so wie ich deine Posts
verstehe gehen sie einfach komplett am Thema vorbei.
Dieter D. schrieb:> Er will keine ramdisk. Wie kommst du da drauf? 😂👌
Wenn er die ersten 5 links durchgekaut hat, bekommt er das
Problem/Anforderung gelöst.
Kommt vielleicht aus Einsicht und Überzeugung die Beratungsresistenz
abzulegen.
So, das wird mir nun zu doof... ich gehe zurück in den Garten und spiele
mit dem Grill & trinke ein Radler.
Schönen Sonntag, euch allen.
Dieter D. schrieb:> Aber so wie ich deine Posts> verstehe gehen sie einfach komplett am Thema vorbei.
Man merkwürdig anmutenden Fragestellungen kann man antworten, indem man
exakt die Frage beantwortet, egal wieviel Sinn das ergibt. Oder indem
man erst einmal rauszukriegen versucht, ob die vom Fragesteller
angepeilte Lösung vielleicht schon auf dem Holzweg liegt.
Drago S. schrieb:> Wenn er die ersten 5 links durchgekaut hat, bekommt er das> Problem/Anforderung gelöst.
Das kollidiert dann aber ein wenig damit:
Taucher schrieb:> möglichst vom Mint-Installer
(prx) A. K. schrieb:> Dieter D. schrieb:>> Aber so wie ich deine Posts>> verstehe gehen sie einfach komplett am Thema vorbei.>> Man merkwürdig anmutenden Fragestellungen kann man antworten, indem man> exakt die Frage beantwortet, egal wieviel Sinn das ergibt. Oder indem> man erst einmal rauszukriegen versucht, ob die vom Fragesteller> angepeilte Lösung vielleicht schon auf dem Holzweg liegt.
Völlig richtig. Es hat ja aber niemand die Frage exakt beantwortet ohne
es infrage zu stellen. Es wurde erklärt wie es geht und warum es Quatsch
ist.
Da fand ich Drago jetzt einfach zu geil der einfach ohne Erklärung eine
Anleitung hinknallt und so tut als wäre das die Lösung - obwohl sie
etwas völlig anderes macht - und dann noch die Erläuterungen von vorher
aus dem Zusammenhang reißt und so tut als hätte das jmd empfohlen.
Man möchte meinen er hat den Thread gelesen ohne ihn gelesen zu haben -
und dann auf Schlagworte reagiert. Stichwort bind und mount verwechseln
- hat niemand getan einfach 😄
Dave schrieb:> Lediglich ein> sticky bit und ggf ein noexec flag ist gesetzt; das kannst du aber> selbst nachholen mit chmod bzw. in /etc/fstab.
Und wer löscht den Inhalt bis zum nächsten Reboot?
Cartman schrieb:> dass /tmp nur im RAM liegt.
Das halte ich für ein Gerücht – ich habe schon zu viele GBs nach tmp
herunter geladen und es hatte danach immer noch Platz…
rbx schrieb:> Unmöglich ist das alles nicht - Arroganz oder Persönlichkeitsdiagnostik> aus dem Kaugummiautomaten sind hier fehl am Platz (ich nutze da eher> mein Know How aus der Persönlichkeitspsychologie und weiß genau, dass> selbst diese professionellen Programme da recht schwammig oder> fragwürdig sind - was ja auch ganz OK ist).
Danke. Schön dass es in diesem verkorksten Land auch noch vernünftige
Leute gibt…
Taucher schrieb:> Dave schrieb:>> Lediglich ein>> sticky bit und ggf ein noexec flag ist gesetzt; das kannst du aber>> selbst nachholen mit chmod bzw. in /etc/fstab.>> Und wer löscht den Inhalt bis zum nächsten Reboot?
Das macht systemd. Und du denkst jetzt /tmp wäre deshalb kein normaler
Ordner mehr oder wie?
Dave schrieb:> Lediglich ein> sticky bit und ggf ein noexec flag ist gesetzt; das kannst du aber> selbst nachholen mit chmod bzw. in /etc/fstab.
Vorsicht, manche (z.B. electron-) Anwendungen erwarten, dass sie aus
"/tmp" binaries ausführen können.
Ein echter Sicherheitsgewinn ist es eh nicht, per
"/lib64/ld-linux-x86-64.so.2 /tmp/irgendwas" kann man das "noexec"-Flag
umgehen.
Taucher schrieb:> Na ja, ich setze ja /home nicht bei Null auf, sondern auf einem> Datenbestand von knapp 3 TiB. Die SSD hat nur ein halbe TiB…>> Aber vielleicht habt ihr ja einen heißen Tipp, wie man die Daten auf die> SSD bekommt.
bcache, lvm-cache.
da sind dann die häufig benötigten Dateien (~/.bashrc, ~/.ssh/*,
Firefox-Profil usw.) auf der SSD, und die 3 TiB Datenberge bleiben auf
der HDD.
Vollautomatisch.
Taucher schrieb:> Cartman schrieb:>> dass /tmp nur im RAM liegt.>> Das halte ich für ein Gerücht – ich habe schon zu viele GBs nach tmp> herunter geladen und es hatte danach immer noch Platz…
Ich habe hier aktuell "einige" Systeme mit 512 GB RAM.
Da koennte eine Ramdisk schon etwas groesser ausfallen.
Aber selbst die wuerde fuer die typischerweise anfallenden
Rohdaten nicht reichen. Also schiebt man sie direkt in
gestripte SSDs. Ein /tmp in dem Sinne gibt es nur als
Systemdefault, wird aber fuer die Berechnungen quasi nicht
genutzt. Siehe auch meine anderen Beitraege.
Was du fuer ein Geruecht haeltst, ist mir egal.
Aber /tmp in eine Ramdisk zu legen, war/ist bei Solaris z.B.
seit Jahrzehnten gaengige Praxis. Auch das kannst du gerne
fuer ein Geruecht halten.
Die Linuexe haben sich das irgendwann auch zu eigen gemacht.
Das /tmp nun ins normale Rootfilesystem umgezogen ist, naja
wenn sie es dort schoen finden.
Ich persoenlich verwende Ramdisks ausgesprochen gern,
z.B. fuer FPGA-Projekte wo sehr viele Dateien als
Zwischenergebnis in der Synthese anfallen.
Und eine Ramdisk ist normalerweise auch heute noch der
schnellste filebasierte Speicher in einem System.
Cartman schrieb:> Aber /tmp in eine Ramdisk zu legen, war/ist bei Solaris z.B.> seit Jahrzehnten gaengige Praxis.
Das mag sein, gilt aber für Mint mit Sicherheit nicht – dort gibt es
keine harte Begrenzung für /tmp.
Εrnst B. schrieb:> bcache, lvm-cache.
Das ist ein interessanter Tipp.
Dieter D. schrieb:> Das macht systemd. Und du denkst jetzt /tmp wäre deshalb kein normaler> Ordner mehr oder wie?
Offensichtlich ist er das nicht – er erfährt eine Sonderbehandlung, die
andere Ordner nicht erfahren und damit ist es eben kein "normaler"
Ordner mehr. Und bei Mint ist es auch kein tempfs – die liegen nämlich
wirklich im RAM…
Eine erschoepfende Analyse meiner Ausfuehrungen wuerde ergeben,
dass ich "Mint" ueberhaupt nicht erwaehnt habe.
Ich habe einen $NACHBARN der sammelt und installiert Linuexe
scheinbar im Akkord. Der scheint hier aber nicht mitzulesen.
Ansonsten ist bei seinen Installationen aber auch mehr kaputt
und nicht funktional als ueblich.
Ich im Gegensatz, installiere einen Rechner oft nur genau einmal.
Und vermutlich werde ich "Mint" auch in den naechsten 12 Monaten
nicht installieren. Er ist mir also herzlich egal, wohin der
"Mint"-Installer sein /tmp packt.
Aus der "Poetteringschen" Spezialbehandlung von /tmp eine
Sonderstellung von /tmp zu implizieren, halte ich fuer etwas
weit hergeholt. Er tut ja nur das, was ein "Blackout" sonst
auch taete und was keiner speziell findet.
Sicherlich kann mit mit "speziellen" Loesungen versuchen sein
Problem zu loesen, aber je exotischer etwas ist, um so laenger
halten sich auch Bugs und Peculiarities im Code.
Im allgemeinen ist man mit K.I.S.S. am besten bedient.
(prx) A. K. schrieb:> Aber systemd räumt auf, siehe /usr/lib/tmpfiles/tmp.conf
/usr/lib/tmpfiles/ gibts bei Mint 19 nicht – bei 21 hab ich nicht
nachgesehen.
Also ich für meinen Teil bin noch auch aus der SUN-Zeit geformt
und lege für alles mögliche eine separate Partition an, auch wenn
es mit btrfs heute nicht mehr zwingend nötig ist.
Ich hoffe meine fstab ist kein abschreckendes Beispiel aber sie
ist schon etwas länger.
Es bedeutet zwar immer etwas Mühe beim Installieren der Systeme
die Partitionierung zu machen aber hat sich bis dato nicht negativ
ausgewirkt, wenn man von der benötigten Zeit absieht.
Wenn man die Filesysteme mit Ihren Parametern sichert, kann man sie
auch gut wieder reparieren, wenn was schief geht, sofern die Disk
noch in Ordnung ist.
Soweit mein Senf zu der Thematik. Ob es jetzt für den TO eine Hilfe
ist, muss er selbst beurteilen.
LG
Markus
Taucher schrieb:> (prx) A. K. schrieb:>> Aber systemd räumt auf, siehe /usr/lib/tmpfiles/tmp.conf>> /usr/lib/tmpfiles/ gibts bei Mint 19 nicht
Bei mir gibts ein /usr/lib/tmpfiles.d/tmp.conf
@Markus W.:
Die Aufteilung auf verschiedene Partitionen stammt aus der Zeit der
kleinen Platten. Als sie größer wurden, teilte man die in mehrere
Partitionen auf und um das etwas flexibler zu machen, wurden die
Partitionen mit lvm verwaltet.
Der Idealfall – finde ich jedenfalls – ist eine riesige Speicherwiese,
die man frei verwenden kann. Das wird aber vermutlich nie erreicht
werden, weil Speichermedien immer zu klein sind, egal wie groß…
Man muss also irgend einen Kompromiss finden, der möglichst wenig
Restriktionen im praktischen Anwendungsfall mit sich bringt.
Reinhard S. schrieb:> Bei mir gibts ein /usr/lib/tmpfiles.d/tmp.conf
Welche Mint-Version ist das?
Wie /tmp und andere temporären Verzeichnisse administriert werden, ist
unter
man tmpfiles.d
beschrieben. Damit kann man tmp-Verzeichnisse nach belieben anlegen, die
beim Boot leer geputzt sind – danke prx.
Taucher schrieb:>> Offensichtlich ist er das nicht – er erfährt eine Sonderbehandlung, die> andere Ordner nicht erfahren und damit ist es eben kein "normaler"> Ordner mehr. Und bei Mint ist es auch kein tempfs – die liegen nämlich> wirklich im RAM…
Nur weil ein Service regelmäßige Aktionen in dem Ordner durchführt ist
es trzd ein stinknormaler Ordner. Und erst recht im Kontext deiner
Frage. Du kannst da mounts oder bind mounts drauf zeigen lassen und ganz
normale fstab Einträge vornehmen wie bei jedem anderen Ordner auch. In
jedem Systemordner führt das System automatisch Operationen durch. In
/home genauso wie in /var, /dev, /tmp usw. Jeder einzelne davon bekommt
eine Sonderbehandlung. Und jeden einzelnen davon kannst du mounten und
bind mounten und wie und was du willst. Denn jeder einzelne davon ist am
Ende des Tages ein stinknormaler Ordner.
Und wie kann man bitte wenn man offensichtlich absolut 0 Ahnung hat
trotzdem so hart diskutieren? Trollst du oder bist du wirklich so hart
hängengeblieben? Hast du es denn in deiner so umfangreichen Expertise
wenigstens inzwischen hingekriegt oder glotzt du immer noch wie ein
Schwein vorm Uhrwerk in deine mtab und fragst dich was du machen sollst?
Oder sollen wir dir lieber einen guten Psychiater suchen?
So einen Typen wie dich hatten wir im 1. und 2. Semester im Studium
auch. Der hat sich immer benommen wie der mega Experte. Einmal hat er
erzählt er würde zuhause gerade einen mega Audio Verstärker entwickeln
der besser ist alles was man so kaufen kann. In der nächsten Elektronik
VL wusste er nicht mal was Class A Betrieb ist. Seine Hausaufgabe fürs
Lab - eine einfache Arbeitspunkt Auslegung - hatte er nicht hinbekommen.
Naja, er hat dann abgebrochen. Möchte echt zu gerne wissen was in Köpfen
von solchen Typen wie euch vorgeht. 😂
> Markus W.:> Die Aufteilung auf verschiedene Partitionen stammt aus der Zeit der> kleinen Platten. Als sie größer wurden, teilte man die in mehrere> Partitionen auf und um das etwas flexibler zu machen, wurden die> Partitionen mit lvm verwaltet.
So stellt Annalena Baerlauch sich das vielleicht vor.
@ Markus W.:
Hoer blos nicht auf "solche" Erklaerungen. Musst du ja auch nicht.
Du weisst ja wie es geht...
Die Aufteilung auf einzelne Filesysteme war eher dazu gedacht,
Filesysteme auf die wenig bis gar nicht geschrieben wurde
von denen mit viel Schreibleistung zu separieren um im Falle
eines Systemcrashs/Blackout/etc. den Aufwand fuer Reparaturmassnahmen
zu minimieren. Unter Solaris konnte man z.B. /usr read only mounten.
Das erleichterte natuerlich auch den Export per NFS fuer
Maschinen ganz ohne Platten.
Das kleinere Backups schneller gehen ist auch eine Tatsache.
Und das Maximum an Flexibilitaet erreichte der LVM vom AIX
ebenfalls schon vor Jahrzehnten. Da wird die ganze Platte naemlich
in winzige Haeppchen (PPs) aufgeteilt, die man einzelnen "Logical
Volumes" zuteilen kann auf denen dann die Mountpoints sitzen.
Solchen Zirkus machte man schon mit 300 MB Platten...
Und mirroring und striping und softraid und physical mapping und ...
ging damit auch noch. Man konnte sogar Filesysteme im laufenden
Betrieb vergroessern!
Da du bislang auch nicht schluessig darlegen konntest, fuer was der
"Unfug" mit /home /var und /tmp in einer Partition gut sein soll
klinke ich mich hier jetzt aus.
Jemand, der nicht gerade der absolute Anfaenger ist, haette
der Stichpunkt "bind mount" allemal gereicht.
Und das nun gleich vom Installer zu verlangen, zeugt auch
von einer gewissen Unkenntnis.
Cartman schrieb:> Jemand, der nicht gerade der absolute Anfaenger ist, haette> der Stichpunkt "bind mount" allemal gereicht.> Und das nun gleich vom Installer zu verlangen, zeugt auch> von einer gewissen Unkenntnis.
Oh, mal wieder ein richtiger Experte… Mein Rat: bewirb dich beim Zirkus
als "Kluger Hans".
OT: Da klöppeln sie sich 3 Tage lang gegenseitig die Köppe ein.. ;)
Habt ihr Jungs keine Freizeit, Hobbys, geht ihr keiner Arbeit nach? Habt
ihr gerade Ferien und noch keinen Job?
Schade, das wieder mal ein Thread zerfleischt wurde.
@Mod: Ab Mitte kann man abschneiden, dass wenigstens die Nachwelt noch
was hat.
Schönen Tag. Seid lieb zueinander.
Was mich noch interessieren würde ist die Aussage
weiter oben, dass man die noexec Konfiguration einer
Partition bzw eines FS umgehen kann - ist das so?
Da habe ich wohl noch eine Wissenslücke.
>> Lediglich ein>> sticky bit und ggf ein noexec flag ist gesetzt; das kannst du aber>> selbst nachholen mit chmod bzw. in /etc/fstab.>Vorsicht, manche (z.B. electron-) Anwendungen erwarten, dass sie aus>"/tmp" binaries ausführen können.>Ein echter Sicherheitsgewinn ist es eh nicht, per>"/lib64/ld-linux-x86-64.so.2 /tmp/irgendwas" kann man das "noexec"-Flag>umgehen.
Markus
Habe es jetzt selber nachgestellt und es geht nicht.
Ist eventuell bei früheren Linux Versionen möglich gewesen.
Falls ich einen Fehler beim Erzeugen des shared Bineries
gemacht haben sollte, so bitte aufzeigen.
Für mich war der Test jetzt schlüssig und widerlegt die
o.g. Behauptung - hätte mich auch etwas entsetzt ;-)
Markus
Markus W. schrieb:> Habe es jetzt selber nachgestellt und es geht nicht.
Ohje, ich werd alt...
Im Kernel 2.6.0 ist der Check dazugekommen, dass kein PROT_EXEC mmap
mehr von "noexec"-gemounteten Dateisystemen zulässig ist.
hättest übrigens nicht extra ein .so für deinen Test kompilieren müssen,
ein
@Εrnst B.
ich dachte Dein Einwandt bezieht sich auf Bineries,
die shared libs nachladen, deshalb diese Art der Compilierung.
Aber ich bin da kein Experte, was das Nachladen von Objekten
in Linux angeht, und lerne gerne dazu.
LG
MArkus
Markus W. schrieb:> ich dachte Dein Einwandt bezieht sich auf Bineries,
Nö, eigentlich Binaries generell.
Analog zu
./x.sh # <- geht nicht bei noexec
bash x.sh # <- geht trotz noexec
war's früher
./binary # <- geht nicht wegen noexec
...ld.so ./binary # <- umgeht noexec
Über den mmap-PROT_EXEC - Fix wird letzteres jetzt auch verhindert.
ld.so will das binary per mmap ausführbar in den RAM mappen, und das
geht nicht.
Nachladen von *.so-Dateien würde ebenso ein mmap verwenden, und ist
genauso geblockt.
Wenn man sich einen elf-loader bastelt, der statt mmap einfach ein
read() verwendet, könnte man das umgehen. Aber: Henne-Ei-Problem, wie
kriegst du diesen Loader ausgeführt :)
