Setup-Praktiken für Linux / UNIX-Server für / tmp

Basierend auf dem, was Sie alle da draußen sehen, was eine empfohlene Konfiguration von / tmp auf einem Serversystem ist und warum. Ich habe über die Jahre über diese Punkte diskutiert, manchmal mit grundlegenden Meinungsverschiedenheiten.

Das Folgende sind im Grunde die Fragen, die ich sehe. Einige schlagen möglicherweise vor, diese Fragen mit mehreren Fragen zu stellen. Ich denke jedoch, dass es für Administratoren einfacher sein könnte, wenn diese Informationen unter einer Überschrift stehen. Ich bin sicher, dass dies informativ sein wird.

Speziell für / tmp:

1. Sollte ln -s / var / tmp / tmp?

2. Sollte / tmp zwischen Neustarts beibehalten werden oder nicht?

3. Sollte sich / tmp auf einem realen Festplattenbereich befinden oder grundsätzlich auf dem SWAP-Bereich (oder tmpfs) implementiert werden dürfen?

4. Sollte sich / tmp auf einer anderen Festplatte als die / (Root-) Festplatte befinden?

5. Würden Sie / tmp auf einem anderen Festplattencontroller als / (root) platzieren?

6. Irgendwelche Faustregeln für die Größe von / tmp?

7. Wie würden Sie / tmp Speicher verwalten, während das System läuft? Alle Dateien löschen> bestimmtes Alter? Bereich in Ruhe lassen, bis ein% Alter von max erreicht ist?

8. Sollten Verfahrenspunkte in Kraft gesetzt werden, um diesen Bereich zu regeln?

Speziell für / tmp:

• Sollte ln -s / var / tmp / tmp?

Im Fall eines vollständigen In-Memory-Disk-Images (denken Sie an "Live-Boot-CD") kann dies akzeptabel sein, da jedes Byte RAM gequetscht werden muss. Andernfalls, nein, es sei denn, Sie sind fest auf Speicherplatz angewiesen, nein. / var hat seine eigenen Besonderheiten und das Mischen von / tmp mit / var / tmp kann unbeabsichtigte Konsequenzen bei der Durchführung der Systemwartung haben. Außerdem wird eine zusätzliche Abhängigkeit hinzugefügt, da / tmp bereitgestellt werden muss, damit / var / tmp ordnungsgemäß funktioniert. Nicht alles benötigt / tmp und es kann vorkommen, dass Sie es auf eine andere Partition oder ein anderes Laufwerk migrieren möchten, dies jedoch nicht, da Sie / var nicht aushängen möchten.

• Sollte / tmp zwischen Neustarts beibehalten werden oder nicht?

Nein. Wenn Sie sich darauf als konsistentes Verhalten verlassen, werden Sie früher oder später auf Probleme stoßen.

• Sollte sich / tmp auf einem realen Festplattenbereich befinden oder grundsätzlich auf dem SWAP-Bereich (oder tmpfs) implementiert werden dürfen?

Wenn es stark genutzt wird, ist dies eine Versuchung - "Wir werden / tmp in eine RAM-Disk einlegen, es wird den Zugriff beschleunigen, und wenn das System neu startet / herunterfährt, gibt es nichts zu bereinigen". Wenn Sie jedoch daran denken, temporären Speicherplatz als RAM-Disk zu implementieren, der ausgetauscht werden soll, würde ich die Auswirkungen der Swap-Speicherauslastung Ihres Systems durch andere Programme berücksichtigen. Wenn Swap als eine Art "Notfallüberlauf" vorhanden ist, wenn sich das System in einer schwierigen Situation befindet und benötigt wird, müssen Sie als letztes den Swap-Speicherplatz durch einen außer Kontrolle geratenen Prozess füllen / tmp belegen, Speicher verbrauchen und Druck auf das System ausüben VM-Subsystem zum Wechseln auf die Festplatte. Zwischen der Swap-Aktivität und dem zusätzlichen E / A-Streaming auf die RAM-Disk (was wiederum dazu führen kann, dass zusätzliche Page-Ins eine Suche erfüllen ()) wird Ihr System schnell an die E / A gebunden.

• Sollte sich / tmp auf einer anderen Festplatte als die / (Root-) Festplatte befinden?

Am liebsten ja, obwohl es nicht nötig ist. Wenn Sie es stark nutzen oder eine konstante Arbeitsbelastung haben, die es erfordert, dann definitiv ja. Hypothetisches Beispiel: Eine Datenbank, die temporäre Dateien in / tmp speichert, würde eine leichte Beschleunigung erzielen, wenn / tmp in eine separate Spindel (dh ein Laufwerk) eingeführt wird.

• Würden Sie / tmp auf einem anderen Festplattencontroller als / (root) platzieren?

Wenn Sie Anforderungen an die Wiederherstellbarkeit oder Geschwindigkeit haben, sollten Sie diese berücksichtigen.

• Irgendwelche Faustregeln für die Größe von / tmp?

Es sollte 2x Ihre erwartete Arbeitsbelastung aufnehmen. Damit meine ich, dass, wenn lokale Benutzer diesen Bereich regelmäßig nutzen, früher oder später jemand etwas Dummes tut und versucht, ihn zu füllen. Wenn Sie ein leichtes Übermaß haben, können Sie seltsame "Probleme" mit Programmen vermeiden, die angehalten werden, weil ihre temporären Dateien den verbleibenden Speicherplatz ausgefüllt haben.

Wenn es sich um eine "Common Services" -Installation handelt, bei der der Server einen oder mehrere Netzwerkdienste bereitstellt, jedoch keine Benutzer hostet, ist dies wahrscheinlich eher gering. Wenn es sich um eine Mehrbenutzerinstallation handelt, ist dies eine große Herausforderung (ja, es gibt immer noch Orte, an denen tatsächliche Benutzer und nicht nur deren Netzwerkdienste gehostet werden).

• Wie würden Sie / tmp Speicher verwalten, während das System läuft? Alle Dateien löschen> bestimmtes Alter? Bereich in Ruhe lassen, bis ein% Alter von max erreicht ist?

Schauen Sie sich den Befehl tmpwatch an . Ich denke, Sie werden feststellen, dass er gut zu diesem Teil Ihrer Frage (n) passt. Der Befehl löscht einfach alle Dateien, die ein bestimmtes Alter überschreiten, in Stunden. Je nachdem, wie schnell es voll ist, können Sie 30 Tage, 45 Tage, 90 Tage usw. tun.

• Sollten Verfahrenspunkte in Kraft gesetzt werden, um diesen Bereich zu regeln?

Ich würde folgendes empfehlen:

1. Alle Dateien sind vorübergehend und können einen Neustart nicht überleben.
2. Veraltete Dateien, die älter als% sind, werden jeden Abend um Mitternacht Ortszeit über einen Cron-Job entfernt, der den Befehl tmpwatch ausführt.

Der Rest ist eine Frage Ihrer spezifischen Bedürfnisse.

Sehr viel hängt von der jeweiligen Anwendungslast ab, die Sie verwenden. Einige Anwendungsserver (SunONE, altes Netscape-Zeug) schreiben ein paar hundert bis ein paar tausend Dateien in / tmp - in dieser Situation möchten Sie wirklich nicht, dass es sich um eine gemountete Ramdisk handelt, und es gibt keinen Grund, sie zwischen den Neustarts beizubehalten.

Server werden immer weniger allgemeiner und spezieller - diese Art von Frage (und die ähnliche Frage "Wie partitioniere ich mein System?") Hängt wirklich von Ihrer Auslastung ab.

Ich hatte kürzlich einen Server, der nach ungefähr 4 Jahren zum ersten Mal neu gestartet wurde - er blieb nach der Hälfte des Startvorgangs hängen und löschte alle Dateien in / tmp - es gab so viel Cruft, dass es eine gute Stunde dauerte, ihn zu bereinigen . Auf jeden Fall eine gute Idee, es regelmäßig zu reinigen, wenn Ihre Box nicht sehr oft neu startet.

Aus Erfahrung empfehle ich, die Verzeichnisse / var / tmp und / tmp nicht zu mischen.

Der Grund für / var ist (hoffentlich), wo sich alle Ihre Protokoll-, Cache- und Servicedaten (z. B. Datenbanken) befinden. Es ist im Allgemeinen eine gute Idee, / var auf einer separaten Partition zu platzieren. Wenn also ein signifikantes Datenereignis (z. B. viele Protokollierungs- oder Datenbankschreibvorgänge) auftritt, haben Ihre Root- und / tmp-Partitionen immer noch freien Speicherplatz, um zuverlässig zu arbeiten.

Zum Beispiel bin ich buchstäblich gerade von einer Site zurückgekehrt, an der diese Praxis nicht befolgt wurde (dh alles befand sich auf einer Partition), und als Ergebnis des Protokollaufbaus wurde das gesamte System in die Knie gezwungen. Wenn ein vernünftiges Partitionierungslayout befolgt worden wäre, wäre der / var-Partition der Speicherplatz ausgegangen, aber der Server wäre reaktionsschnell geblieben.

Nur einige Punkte beantworten ...

Ich würde / tmp auf eine andere Partition als / setzen, nur damit ich / ro während des normalen Betriebs mounten kann. Separate Festplatte? Das hängt davon ab, wie viel / tmp und / get verwendet werden und ob sie sich gegenseitig im Weg stehen.

Was die Teile 1 und 2 betrifft, wird auf meiner Box (Mac OS X) / var / tmp nicht täglich bereinigt, sondern / tmp. Daher gelten unterschiedliche Richtlinien und sollten daher nicht miteinander verknüpft werden. Ich bin mir nicht sicher, ob die tägliche Reinigung von / var / tmp nichts kaputt machen würde, und ich würde das untersuchen wollen, bevor ich lauter werde - es sind im Moment nur 172.000.

Ein Punkt, den ich in Bezug auf Ihre letzte Frage in Betracht ziehen würde, ist, / tmp noexec, nosuid zu erstellen - das heißt, keine ausführbaren Dateien können von / tmp ausgeführt werden, und keine suid-Binärdateien können die Benutzer-ID wechseln. Dies kann sich jedoch auf einige Programme auswirken. Testen Sie es daher, bevor Sie sich vollständig darauf verlassen. Ich denke, ssh war sogar eines davon, aber ich vergesse es.

Dies ist eine Sicherheitsmaßnahme, die Ihre Sicherheit in Bezug auf / tmp verbessert.

Eine andere Sache: Viele Benutzer werden versuchen, / tmp als permanenten temporären Speicher zu verwenden: Jede erzwungene Bereinigung von / tmp muss zusammen mit der Schulung der Benutzer durchgeführt werden: Erinnern Sie sie daran, dass / tmp temporär ist und alles, was dort platziert wird, jederzeit verschwinden kann Zeit.

Sollte sich / tmp auf einem realen Festplattenbereich befinden oder grundsätzlich auf dem SWAP-Bereich (oder tmpfs) implementiert werden dürfen?

Haben Sie darüber nachgedacht, was passiert, wenn / tmp in dieser Situation voll ist? So etwas macht man nicht zweimal. Ich habe es einmal gemacht (unter Solaris / tmp wird der gesamte verfügbare RAM und Swap aufgebraucht), und es hat den Server in die Knie gezwungen.