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?
Motiv dafür, gerade die für eine SSD interessanten Verzeichnisse auf das langsame HDD zu legen?
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
Und wie kann man bewerkstelligen, was ich im Eingangsposting geschrieben habe?
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.
:
Bearbeitet durch User
(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 …
Angehängte Dateien:
-
it-depends.jpg
82 KB
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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-systems https://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.
Peter schrieb: > 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-systems > > https://docs.oracle.com/cd/E19253-01/820-2313/gazud/index.html Quoten? Witzbold…
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...
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Angehängte Dateien:
-
Untitled.png
190 KB
Wie kommt man in der zeit wo 1gb SSD 70 eur kosten auf die idee eine HDD einzubauen?
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.
Um das ganze abzukürzen:
1 | sudo mkdir -p /tmp # verzeichnis anlegen |
2 | sudo chmod 1777 /tmp # sticky bit setzen |
3 | #sudo chmod +rwxt /tmp # oder auch so |
4 | |
5 | # /etc/fstab: mode=1777 muss hinein; rest nach belieben |
6 | echo "tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=1g 0 0" | sudo tee -a /etc/fstab |
7 | sudo mount /tmp |
8 | df -h /tmp |
Hier noch etwas Lesestoff. Die beiden letzten links sind sehr nützlich. https://wiki.ubuntuusers.de/fstab/ https://wiki.ubuntuusers.de/SSD/Auslagerung/ https://www.pcwelt.de/ratgeber/Wichtige-Dateisysteme-im-Ueberblick-7115007.html What is Fstab in Linux: https://www.linuxhowto.net/what-is-fstab-in-linux-an-introduction-to-linux-etc-fstab-file/ Unterschied zwischen tmpfs und ramfs: https://techgoat.net/index.php?id=87 How to create temporary files using mktemp: https://linuxconfig.org/how-to-create-temporary-files-using-mktemp-on-linux Und hört bitte auf 'bind' mit 'mount" zu vertauschen - das sind 2 Paar Schuhe. Schönen Sonntag noch.
Drago S. schrieb: > Und hört bitte auf 'bind' mit 'mount" zu vertauschen - das sind 2 Paar > Schuhe. Das Kindchen heisst aber nun einmal bind mount.
Dieter D. schrieb: > Und wer den jetzt gern woanders haben will schreibt einfach einen (bind) > mount in die fstab. Fertig. Genau das macht man nicht!
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.
Drago S. schrieb: > Genau das macht man nicht! Das erklären wir ihm ja auch die ganze Zeit aber er will es ja unbedingt…
(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.
:
Bearbeitet durch User
> 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Der TO trollt doch nur. Ich wette der tritt auch unter dem Namen VM Freak auf :D
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.
1 | >cat /etc/fstab |
2 | LABEL=ROOT / btrfs defaults 0 0 |
3 | /dev/mmcblk0p1 /mnt/mmcblk0p1 ext4 noatime,ro 0 0 |
4 | /dev/mmcblk0p2 /mnt/mmcblk0p2 ext4 noatime 0 0 |
5 | LABEL=HOME /home xfs defaults 0 0 |
6 | LABEL=BOOT /boot btrfs noatime 0 0 |
7 | LABEL=BOOT_EFI /boot/efi vfat codepage=437 0 0 |
8 | LABEL=BCK /bck xfs noatime,noexec,nosuid,nodev 0 0 |
9 | LABEL=SWAP swap swap pri=0,x-systemd.device-timeout=10 0 0 |
10 | LABEL=VAR /var btrfs noatime 0 0 |
11 | LABEL=USR_LOC /usr/local btrfs noatime 0 0 |
12 | LABEL=TMP /tmp btrfs noatime,noexec,nosuid,nodev 0 0 |
13 | LABEL=SRV /srv btrfs noatime 0 0 |
14 | LABEL=ROOT /root btrfs subvol=/@/root 0 0 |
15 | LABEL=OPT /opt btrfs noatime 0 0 |
Für temporäre Arbeiten bewege ich mich meist auf /dev/shm, das in meinem Fall mit 32GB für meine Belange reicht.
1 | >df -h |
2 | Filesystem Size Used Avail Use% Mounted on |
3 | devtmpfs 4.0M 0 4.0M 0% /dev |
4 | tmpfs 32G 566M 31G 2% /dev/shm |
5 | tmpfs 13G 2.1M 13G 1% /run |
6 | /dev/nvme0n1p2 256G 35G 222G 14% / |
7 | /dev/mmcblk0p1 119M 26K 110M 1% /mnt/mmcblk0p1 |
8 | /dev/mmcblk0p2 15G 24K 14G 1% /mnt/mmcblk0p2 |
9 | /dev/nvme0n1p1 1.0G 246M 658M 28% /boot |
10 | /dev/nvme0n1p2 256G 35G 222G 14% /root |
11 | /dev/nvme0n1p3 128G 14G 114G 11% /opt |
12 | /dev/nvme1n1p2 666G 457G 209G 69% /srv |
13 | /dev/nvme1n1p1 256G 6.0G 250G 3% /usr/local |
14 | /dev/sda3 256G 437M 254G 1% /tmp |
15 | /dev/sda1 500M 5.1M 495M 2% /boot/efi |
16 | /dev/sda2 128G 14G 113G 11% /var |
17 | /dev/mapper/cr_ata-ST2000LM015-2E8174_WDZPQV5A-part5 1.5T 1.2T 354G 77% /home |
18 | /dev/mapper/cr_ata-ST2000LM015-2E8174_ZDZ9X1LX-part4 1.5T 925G 549G 63% /bck |
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?
:
Bearbeitet durch User
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".
Alter hör doch auf zu trollen. Du bist einfach nur lächerlich. Geh weiter deine mtab anstarren.
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
1 | >pwd |
2 | /tmp |
3 | mw@linux-kwm1:/tmp |
4 | |
5 | >cat testsomw.c |
6 | #include<stdio.h> |
7 | |
8 | const char my_interp[] __attribute__((section(".interp"))) = "/lib64/ld-linux-x86-64.so.2";
|
9 | |
10 | int entry() |
11 | {
|
12 | printf("%s\n","Es geht");
|
13 | exit(0); |
14 | } |
15 | |
16 | gcc -shared -fPIC -e entry testsomw.c -o testsomw.so |
17 | |
18 | >ldd testsomw.so |
19 | linux-vdso.so.1 (0x00007ffd3a767000) |
20 | libc.so.6 => /lib64/libc.so.6 (0x00007f16662a6000) |
21 | /lib64/ld-linux-x86-64.so.2 (0x00007f166650f000) |
22 | |
23 | /dev/sda3 on /tmp type btrfs (rw,nosuid,nodev,noexec,noatime,space_cache,subvolid=5,subvol=/) |
24 | |
25 | >/lib64/ld-linux-x86-64.so.2 ./testsomw.so |
26 | ./testsomw.so: error while loading shared libraries: ./testsomw.so: failed to map segment from shared object |
27 | |
28 | /dev/sda3 on /tmp type btrfs (rw,nosuid,nodev,noatime,space_cache,subvolid=5,subvol=/) |
29 | |
30 | >/lib64/ld-linux-x86-64.so.2 ./testsomw.so |
31 | Es geht |
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
1 | gcc -o test_noexec test_noexec.c |
2 | /lib64/ld-linux-x86-64.so.2 ./test_noexec |
erfüllt denselben Zweck.
@Ε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 :)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.