Fragen Debian 6

[AWOHille]

Hallo,

ich bin gerade dabei einen Root-Server einzurichten. Dabei sind einige Fragen aufgekommen.

1. 32-bit oder 64-bit Debian? Der Arbeitsspeicher liegt bei 4GB. Rein theoretisch würde ein 32-bit System möglich sein. Wie sieht es mit einem 64-bit System aus, sinnvoll? Könnte es da Probleme mir irgend welchen Paketen geben? Ich persönlich hatte bis jetzt immer nur 32-bit System in Anwendung.

2.ich benutze Postfix in Verbindung mit amavis. Durch Amavis ist die local.cf vom spamassassin nur noch teilweise aktiv. Einstellungen werden ja von amavis übernommen. Aber wo genau kann bei amavis die verschiedenen scores z.B.dkim,spf usw. einstellen bzw. verändern?

3.welche Partitionierung wäre bei einem einfach Webserver inkl. Mail, FTP usw. sinnvoll? FTP, SSH Zugang nutze ich komplett alleine. E-Mails werden per Quota eingegrenzt.

Festplatten: 2x1TB

- 4 GB swap (Raid-1)
- 1 GB ext3 /boot (Raid-1)
- ? GB /temp (Raid-1)
- 800GB /var (Raid-1)
- 195GB Rest (Raid-1)

Wäre das so sinnvoll?

Gruß Hille

[daemotron]

Moin & herzlich willkommen im RootForum!

zu 1: 64 Bit. Mit 32 Bit kannst Du keine 4 GiB RAM adressieren, da ein Teil des Adressraums für PCI-Adressen reserviert ist. Dadurch sind mit 32 Bit nur etwas über 3 GiB adressierbar. Mittlerweile dürfte es auch keine nennenswerten Probleme mehr mit 64 Bit Paketen geben; das müsste aber ggf. noch mal von einem Debian-Nutzer bestätigt werden.

zu 3: RAID-1 ist auf jeden Fall sinnvoll, wenn zwei identische Platten vorhanden sind. Bei der Partitionierung würde ich jedoch so vorgehen:

- 256MB /boot
- 4GB Swap
- Rest LVM2

Mehr Platz für /boot lohnt sich nur, wenn Du testhalber viele Kernel parallel am Start hast.

Auf dem LVM2 würde ich folgende Volumes anlegen:

- / 1GB ext4
- /usr 6GB ext4
- /var 4GB ext4
- /srv 8GB ext4
- /tmp 1GB ext4

Wenn MySQL seine Daten in /var ablegt, ggf. noch 2 GiB drauflegen; wenn die Web-Verzeichnisse ebenfalls in /var liegen, kann man auf /srv auch verzichten. Sonst sollten 4 GiB für Log-Daten ausreichend sein, wenn man eine saubere Rotation eingerichtet hat.

/tmp kann auch optional auf eine Ramdisk verlagert werden (tmpfs), aber bei nur 4Gib RAM würde ich darauf verzichten und dem RAM lieber für Web- und Datenbankserver verwenden.

Den großen Rest hast Du dann als Reserve und kannst damit dynamisch die Volumes vergrößern, bei denen der Platz knapp wird.

[AWOHille]

Hallo,

danke für die Antwort.
Ja, WEB-Verzeichnisse werden in /var liegen.
Welchen Vorteil bringen mir die dynamischen Volumes? Rein theoretisch könnte ich Platten, wie von dir empfohlen, partitionieren und /var den kompletten Rest zuweisen. Die anderen Partitionen sollten ja ausreichend sein.

Gruß Hille

[ddm3ve]

Naja, zum Thema ausreichend ..

ein bestimmter Provider gibt ja den Kunden auch immer so seine Partitionen vor. Regelmässig sind die aber nicht mehr passend / ausreichend.

Mit LVM, lassen sich Partitionsgrössen dynamisch anpassen, das kann u.U. ein grosser Vorteil sein, wenn man seine Partitionen ggf. falsch dimenisoniert hat. Und da man das Wachstum ja nie so genau kennt....

LVM und Debian ist leider bei einigen Versionen etwas buggy, ich würde den Einsatz von LVM grundlegend testen.
Ansonsten ist natürlich LVM für Konsistente Backups eine schöne Lösung.

[AWOHille]

Hallo,

danke erst mal für die Antworten. Ob ich LVM einsetze oder nicht muß ich mal sehen. Die 2xTB Festplattenkapazität werde ich definitiv nie ausschöpfen. Vielleicht werde ich auch die anderen Partitionen etwas großzügiger partitionieren und der Rest dann für die Web und Mail.

Wäre es nicht sinnvoll, für die Log-Dateien /var/log eine extra Partition anzulegen, da die web Dateien im /var/www liegen?

Gruß Hille

[ddm3ve]

Ja, würde ich so machen und habe ich bei mir auch entsprechend getrennt.

Ganz Faule erstellen aber nur 3 Partitionen

/boot
SWAP
/

[daemotron]

Ganz Faule erstellen aber nur 3 Partitionen

RichtigTM faule erstellen nur noch einen Zpool und erstellen statt Verzeichnissen ZFS Datasets (wenn es dann irgendwann mal reif ist, kann man das auch mit Btrfs machen). Die allokieren Speicher dynamisch, wachsen und schrumpfen also passend zum Platzbedarf ;) *scnr*

Wie ddm3ve schon schrieb, liegt ein weiterer Vorteil von LVM in seiner Fähigkeit, Snapshots in Sekundenschnelle erstellen zu können. Das ist sehr nützlich für Backups. Hilfreich ist es aber auch, wenn man ein Upgrade o. ä. fahren möchte - vorher Snapshot erstellen, und wenn das Upgrade schief geht, dann einfach den Snapshot zurückrollen - und schon ist wieder ein betriebsfähiger Zustand hergestellt.

Aber bei einer 2TB Platte sind LVMs nicht wirklich notwendig, um den Platz sinnvoll aufzuteilen, da gebe ich Dir recht. Da kann man jede Partition mit genügend Reserve ausstatten, um später nicht in Verlegenheit zu kommen.

[ddm3ve]

RichtigTM faule erstellen nur noch einen Zpool und erstellen statt Verzeichnissen ZFS Datasets (wenn es dann irgendwann mal reif ist, kann man das auch mit Btrfs machen). Die allokieren Speicher dynamisch, wachsen und schrumpfen also passend zum Platzbedarf ;) *scnr*

Gibt es dass denn auch mal für Debian?

[daemotron]

Gibt es dass denn auch mal für Debian?

Btrfs ja, ZFS erst wenn die Hölle zufriert.

[Roger Wilco]

Wieso, ist dir schon kalt? :p

[daemotron]

Das Fuse-Zeugs ist doch bloß Proof-of-concept

[Joe User]

Kühl aber nicht kalt:
http://zfsonlinux.org/
https://github.com/zfs-linux

[daemotron]

Technisch ist das noch nicht mal so ein großes Problem; das Problem liegt eher auf Seiten der Lizenzen. ZFS steht unter der CDDL, der Linux-Kernel unter GPLv2. Beides sind Copyleft-Lizenzen; ein abgeleitetes Werk müsste also wieder unter derselben Lizenz verbreitet werden. Das geht aber logischerweise nicht, da in diesem Fall mindestens gegen eine der beiden Lizenzen verstoßen würde.

Natives ZFS für Linux kann man also nur als Patch verteilen, so dass der Admin sich selbst einen ZFS-fähigen Kernel bauen kann - diesen darf er jedoch nicht weiter verteilen. Daher denke ich, dass sich das niemals durchsetzen wird, da keine Distribution natives ZFS über ihre Paket-Repositories verteilen könnte.