Andreas Janssen: Linux Server - Wie partitioniere ich am besten?

Beitrag lesen

Hallo

Es ist grundsätzlich eine gute Idee, mehrere
Partitionen anzulegen.

Nein, es ist nicht (mehr) _grundsätzlich_ so.
Wenn alles auf einer Platte ist, bringt die Trennung
von Daten und Programmen nichts: geht die Platte
kaputt, ist alles weg.

/Wenn/ die Platte kaputt geht. Vielleicht ist es auch
nur das Dateisystem.

Bei den heutigen RAM-Größen ist ein SWAP nicht mehr
_zwingend_ notwendig.

Richtig. Übrigens konnte man vor einiger Zeit eine
längere Diskussion über den Sinn und Unsinn von Swap
lesen: http://kerneltrap.org/node/view/3202

Eines der Arguments für Swap war: selbst wenn
eigentlich genug Speicher für die Programme vorhanden
ist, kann bei vorhandenem Swap trotzdem ungenutzter
Krempel ausgelagert werden, und der so freigewordene
RAM steht für andere Dinge, zum Beispiel als Cache für
Dateien, zu Verfügung.

[...]

Auf jeden Fall solltest Du das
System und Deine persönlichen Datei (/home)
getrennt halten. Ein weiterer Vorteil ist, daß
bei einem Dateisystemschaden nur ein Teil des
Systems beschädigt wird.

Die Dateisysteme heutzutage sind stabiler als die
Hardware.

Ich habe einmal eine abgerauchte Platte erlebt, aber
schon zwei zerstörte Reiser-Dateisysteme. Zugegeben,
das ist schon eine Weile her, aber in einschlägigen
Newsgroups kann man gelegentlich immer mal wieder
von solchen Fällen lesen. Außerdem: die Tatsache, das
ein Hardwareschaden wahrscheinlicher als ein
Dateisystemschaden ist bedeutet /nicht/, daß man auf
jeden Fall keinen Dateisystemschaden bekommt, weil ja
vorher die Hardware kaputtgehen würde.

Und zu der Trennung von persönlichen Datei und System:
Es geht nicht nur um Zuverlässigkeit und Sicherheit.
Diese Trennung ermöglicht es Dir auch, das System
durch eine neuere Version zu ersetzen (ist bei Debian
natürlich nicht nötig;-)), es durch eine andere
Distribution zu ersetzen, oder es aus irgendwelchen
Gründen neu zu installieren. Insbesondere bei
Neueinsteigern ist Letzteres oft eine beliebte Methode,
Probleme mit ihrer Linux-Distribution zu lösen. Daher
ist der wichtigste Grund für diese Trennung schlicht
und einfach Bequemlichkeit.

Für das Restrisiko ist das regelmäßige Backup
zuständig.

Ja, das ist natürlich unabdingbar. Je nach Szenario
gibt es aber Obergrenzen für die Häufigkeit von
Backups. Ich mache einmal pro Woche mit afio eine
Sicherungskopie von /home, /etc, Teilen von /var und
der Ausgabe von dpkg --get-selections. Diese wird auf
einer CD gespeichert. Trotzdem wäre es bei einer
drohenden Katastrophe oder einem Teilschaden
wünschenswert, zusätzlich einen Teil der seit dem
letzten Backup geänderten Daten (z.B. Posteingang)
retten zu können.

Wenn zum Beispiel /tmp auf einer eigenen
Partition liegt und kaputt geht, dann ist das
nicht so schlimm, als wenn das Dateisystem der
Root-Partition hin ist.

Es ist beides gleich schlimm.
Ein Dateisystem geht heutzutage nicht so ohne
weiteres kaputt, es ist im beschriebenem Fall eher
die Platte selber, die so langsam den Geist
aufgibt.

Mag sein, daß es wahrscheinlicher ist. Allerdings kann
auch ein vorerst begrenzt auftretender Schaden an der
Hardware ein Dateisystem unbrauchbar machen. In dem
Fall wäre man besser dran, wenn erst mal nur /tmp
hin ist und man noch eine Möglichkeit hat, den Rest
zu retten.

Außerdem kannst Du für die einzelnen Dateisysteme
verschiedene Optionen angeben. Es ist zum
Beispiel möglich, Partitionen
wie /usr, /usr/local und /opt read-only
einzuhängen.

Ja, das kann man. Aber das ist nur ein Zusatz,
bringt nicht wirklich was. Einschränkung der
Schreibrechte auf Root reicht, denn wenn die Kiste
gerooted wurde, kann auch ein remount auf rw
ausgeführt werden, ein Defaulteinhängen mit
read-only ist nur lästig, mehr nicht.

Es ist richtig, daß es keinen Schutz bietet, wenn der
Rechner gerooted wurde. Das macht es noch nicht gleich
sinnlos. Außerdem war das "read-only" nur ein Beispiel,
es gibt weitere sinnvolle Optionen, zum Beispiel nosuid
und noexec (letzteres ist wohl nur bei Kernel 2.6
brauchbar), oder Einstellungen, mit denen man die
Performance steigern kann. Bei einem System mit vielen
Dateien, auf die dauernd zugegriffen wird (z.B.
Newsspool-Verzeichnis auf einem Newsserver) könnte man
beispielsweise noatime verwenden. Von der Möglichkeit,
für unterschiedliche Bereiche unterschiedliche
Dateisysteme oder angepasste Einstellungen bei der
Formatierung zu verwenden mal ganz zu schweigen.

Bei Debian wird normalerweise
recht genau darauf geachtet, daß veränderliche
Daten an passenden Orten, z.B. in /var,
gespeichert werden.

»»

Das ist aber hauptsächlich wegen dere Einhaltung des
Filesystemstandards, weniger wegen der Sicherheit.

Es geht dabei natürlich nicht ausschließlich um
Sicherheit und Zuverlässigkeit, aber wenn Du die
Standards erwähnst, dann solltest Du auch daran denken,
das man sich diese nicht so zum Spaß ausgedacht hat.
Die im File Hierarchy Standard vorgeschlagene Struktur
erfüllt einen Zweck. Einige der von mir erwähnten
Punkte werden dort auch explizit aufgeführt.

Beispiel:

,---
|Disk errors that corrupt data on the root filesystem
|are a greater problem than errors on any other
|partition. A small root filesystem is less prone to
|corruption as the result of a system crash.
`---

,---
|/var is specified here in order to make it possible to
|mount /usr read-only. Everything that once went
|into /usr that is written to during system operation
|(as opposed to installation and software maintenance)
|must be in /var.
`---

Daher muß nach /usr (fast) nur geschrieben
werden, wenn Du mit der Paketverwaltung Software
installierst und entfernst. Natürlich kann apt
dabei so eingestellt werden, daß es für die Dauer
der Installation/des Entfernens den Status auf
read-write ändert, ganz automatisch.

Und wofür ist das dann?

Dafür, daß /usr nur und genau dann beschreibbar ist,
wenn ich über die Paketverwaltung etwas dorthin
installieren will, sonst nicht.

Nein, das read-only mounten
ist nicht wg Sicherheit eingeführt worden, sondern
eher dafür, das nicht versehentlich auf die CDROM
geschrieben wird. Ja, das war vor der Einführung
billiger Brenner ;-)

[Liste mit Doku]

»»

Auch wenn ich den Grund für den Hinweis nicht
unterstützen kann, sind diese Seiten (Und der Rest
von http://www.nl.debian.org/doc/ natürlich
ebenfalls) wärmstens zur Lektüre empfohlen.

Der Rechner hat 512 MB RAM. Du siehst, das
praktisch alles auf einer eigenen Partition ist,
was nicht für den Systemstart benötigt wird.
Damit kann die Root-Partition sehr klein sein (es
sind ca. 50 MB belegt).

Macht es irgendeinen Sinn die /boot Partition so
Mini zu halten?

Ich habe mir die Frage andersherum gestellt: macht es
einen Sinn, sie größer zu machen, wenn ich den Platz
dort nicht brauche?

andreas@sirius:~$ df -h | grep boot
/dev/hda6              30M  3,1M   25M  12% /boot

Das ist mehr als genug Platz für mehrere Kernel.

Die Größe von /var und /tmp hängen sehr vom
Verwendungszweck des Servers (oder wie bei mir
des Desktops) ab. Dein /usr könnte wahrscheinlich
kleiner sein, da Du auf Riesen wie OpenOffice,
XFree und KDE auf dem Server verzichten kannst.

Mein Gott, er hat 80 GiB! Er muß sich nun wahrlich
keine Sorgen wg Platz machen!

Das dachte ich auch mal. Ich habe mittlerweile eine
120-GB-Platte. Die mit 40 GB ist zu klein geworden.
Davor dachte ich, 6.4 GB wären genug für alle Zeiten.
Und davor waren es 520 MB.

(Das hatte ich allerdings auch gesagt, als ich mir
die 30 GiB Platte für teuer Geld erworben hatte. Die
ist mittlerweile auch randvoll. Ging irgendwie
ziemlich flott ;-)

Erst waren es Spiele, dann MP3-Sammlungen, jetzt Filme.
Das ist das Kartoffel-Theorem: Jetzt ist der Platz da,
jetzt wird er auch verwendet. Ich hatte bei Debian
Woody auch die komplette Debian-Paketsammlung auf der
Platte. Damit konnte ich mir das Wechseln der CDs
sparen.

OpenOffice auf dem Server ist übrigens so schlecht
nicht, da man das Dingen mittlerweile als Filter
gebrauchen kann also z.B. Rohdaten als PDF ausgeben.
Aber den Sicherheitsaspekt natürlich nicht zu
unterschätzen!

Ja, außerdem gibt es doch andere Möglichkeiten. Es gibt
eine ganze Reihe von kleineren Programmen, mit denen
man aus diversen Dateiformaten PDF erstellen kann.
Und für CUPS kann man sich recht einfach ein Backend
für einen PDF-Drucker erstellen. Das ganze geht dann
auch, ohne irgendwelche Abhängigkeiten von XFree o.ä.
zu haben.

In /usr/local
befinden sich bei mir vor allem ein paar große
Spiele (und SelfHTML :-)).

Was hat SelfHTML auf /usr/local zu suchen?
OK, wenn's /usr/local/share ist, werd' ich mal ein
Auge zudrücken ;-)

/usr/local/share/doc, um genau zu sein. Mal ganz im
Ernst: mir ist auch nichts anderes eingefallen, außer
vielleicht /opt.

Möglicherweise möchtest Du auf
einem Dateiserver eine eigene Partition für die
bereitgestellten Daten verwenden.

Der einzige Vorteil dafür ist, das man eine ganze
Partition schneller gelöscht hat, mehr auch nicht.

Oder das man sie nicht löschen muß, wenn man das System
neu installieren oder ersetzen will.

Grüße
 Andreas Janssen

0 58

Linux Server - Wie partitioniere ich am besten?

Peter
  • webserver
  1. 0
    Peter
  2. 0
    Andreas Korthaus
    1. 0
      Peter
  3. 0
    Karin Töbel
    1. 0
      Peter
      1. 0
        Karin Töbel
  4. 0
    Christoph Zurnieden
    1. 0
      Peter
  5. 0
    Sven Rautenberg
    1. 0
      Peter
  6. 0
    Christoph Schnauß
    1. 0
      Peter
    2. 0
      Andreas Janssen
      1. 0
        Peter
        1. 0
          Andreas Janssen
  7. 0

    Linux Server - Ein Vorschlag...

    Peter
    1. 0
      Jens Holzkämper
      1. 0
        Peter
        1. 0
          Christian Seiler
          1. 0
            Christoph Schnauß
            1. 0
              Andreas Janssen
            2. 0
              Christian Seiler
              1. 0
                Christoph Schnauß
          2. 0
            Sven Rautenberg
        2. 0
          Christoph Zurnieden
          1. 0
            Jens Holzkämper
    2. 0
      Christian Seiler
    3. 0
      Christoph Zurnieden
      1. 0
        Christian Seiler
        1. 0
          Christoph Zurnieden
          1. 0
            Christian Seiler
            1. 0
              Christoph Zurnieden
      2. 0
        Peter
        1. 0
          Christoph Zurnieden
          1. 0
            Peter
            1. 0
              Christoph Zurnieden
          2. 0
            Andreas Janssen
            1. 0
              Christoph Zurnieden
          3. 0

            Debian-Kauderwelsch - Eine kleine Einführung

            Fabian Transchel
            • projektverwaltung
            1. 0
              Andreas Janssen
              1. 0
                Fabian Transchel
                1. 0
                  Christoph Zurnieden
                  1. 0
                    Fabian Transchel
                    1. 0
                      Christoph Zurnieden
                      1. 0
                        Fabian Transchel
                        1. 0
                          Christoph Zurnieden
                          1. 0
                            at
                          2. 0
                            Fabian Transchel
                            1. 0
                              Christoph Zurnieden
            2. 0
              Jens Holzkämper
  8. 0
    Andreas Janssen
    1. 0
      Peter
    2. 0
      Christoph Zurnieden
      1. 0
        Andreas Janssen
        1. 0
          Christoph Zurnieden
          1. 0
            Andreas Janssen
            1. 0
              Christoph Zurnieden