Suse 10.0 Installation
Geizhals » Forum » Linux-Support » Suse 10.0 Installation (69 Beiträge, 1764 Mal gelesen) Top-100 | Fresh-100
Du bist nicht angemeldet. [ Login/Registrieren ]
...........
Re(11): Suse 10.0 Installation
20.10.2005, 15:35:49
Grundsätzlich alles unter LVM (außer /boot).
Soweit möglich und KnowHow vorhanden SW-Raid.
lv's zB wie folgt:

/dev/mapper/system-slash
                       1056728    189016    867712  18% /
tmpfs                   517592        12    517580   1% /dev/shm
/dev/md0               1052120     42184   1009936   5% /boot
/dev/mapper/system-home
                      23076152  21133556   1942596  92% /home
/dev/mapper/system-opt
                      10493624    675140   9818484   7% /opt
/dev/mapper/system-srv
                       1056728     82108    974620   8% /srv
/dev/mapper/system-tmp
                       6291260   5082276   1208984  81% /tmp
/dev/mapper/system-usr
                      10493624   3872200   6621424  37% /usr
/dev/mapper/system-usrsrc
                       2113464    517916   1595548  25% /usr/src
/dev/mapper/system-var
                       1056728    195808    860920  19% /var
/dev/mapper/system-pgsql
                       2113464     58232   2055232   3% /var/lib/pgsql
/dev/mapper/system-varlog
                       1056728     40884   1015844   4% /var/log
/dev/mapper/system-varlogsa
                       1056728     32840   1023888   4% /var/log/sa
/dev/mapper/system-vartmp
                       1056728     49564   1007164   5% /var/tmp


Bei SuSE10 müßt' man halt experimentieren, was man braucht

Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
.....
Re(5): Suse 10.0 Installation
21.10.2005, 15:23:08
Wie gesagt, ich kenn's nur von früheren Versionen - bis 9.2.

Ich geh' jetzt mal frech von jemand mit NULL Linux-KnowHow und nur einer Platte aus, net böse sein ;-).


LVM oder nicht LVM:


LVM-Partitionen haben einen anderen Partitionierungstyp(8E) als "normale" Linux-partitionen(83). Dort, wo du die Partitionierung ändern kannst, mußt also deine Platte wie folgt aufteilen:
1 Partition 400M Typ Linux Dateisystem reiserfs Mountpoint /boot
die andere Partition:
Nicht Formatieren, Typ LVM.

Irgendwo dort kommst in die LVM-Konfig.
Da mußt du zuerst eine VG (Volume Group) definieren - Name egal, zB "system".
Der VG kannst du dann dein PV (Physical Volume) zuordnen - eben die 2. Partition.
Dann mußt zu den LV's (Logical Volume).
Du legst dann ein LV für /home (name zB "home") an - 400M, Typ reiserfs, eines für /usr, ein_paar_GB, typ reiserfs, ....

Die LV's sind fast genau gleich zu Konfigurieren wie die Partitionen - das bekommst hin. Wichtig ist, daß du dir in deiner VG wenn möglich Reserven lassen solltest - also nicht alles aufbrauchen.

LV's bringen dir in der Folge, wenn du dein System beherrscht, extrem viele Goodies, auf die du nicht verzichten willst... Wenn du damit aber nicht klar kommst, laß' es halt auf Default-Partition.


Paketauswahl:


Da gab's doch beim klicken auf "Paketauswahl" oder so immer ein paar Varianten: "Minimal", "Graphisch ohne KDE", "Graphisch mit KDE", "Einfach alles", "eigene Konfiguration" (sinngemäß ;-)).

Versuche auf die Minimalinstallation zu kommen.
Wenn du selber Pakete installierst und dir XEN noch nichts sagt - wähle es niemals an. Unser Ziel ist, daß eben die Minimalinstallation eben Fehlerfrei geht.

Bei SuSE gab's bei einer von den 9ern AFAIK Streß, wenn man manche Pakete installieren wollte: Die Installationsroutine war buggy - daher ließ es sich nicht vollständig installieren. Deinstallieren ließ es sich auch nicht - weil nicht komplett installiert ;-).  Und... Sobald man es installiert hatte, klappte der Apache nicht mehr (weil das Paket in seiner Config was umfummelte). Dadurch
klappte auch CUPS und so net... Kurzum:
SuSE liefert(e) immer einen sehr aktuellen Stand mit den IMHO neuesten Paketen und zu 99.9% in sehr gutem Zustand. Wenn du allerdings das 0.1% erwischt hast - wurde es extrem schlimm... Und ich befürchte, daß das bei Dir passierte.

Hast du inzwischen die dmesg-Ausgabe probiert ?

BTW, du mußt ja nicht neu installieren - du solltest immer mit YaST weitermachen können...


21.10.2005, 15:23 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier
Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
....
Re(4): Suse 10.0 Installation
28.10.2005, 10:25:23
Yup, das bringt enorm viel ;-).

Ich lege mir immer viele LV's an... und lasse allen LV's nur wenig "freien" Platz. Die Ideen sind folgende:
1.) Obwohl OpenSource ja sooo fehlerfrei sei ;-) kommt es doch immer wieder mal vor, daß ein Prozeß "randaliert". So füllt er i.d.R. nur ein LV an - bis es voll ist. Damit blockiert er aber nur sich selbst und nicht andere Dienste
2.) Du vermeidest das Windows-Phänomen, daß dein Platz auf der Platte langsam schwindet - und du keine Ahnung hast, wofür der genau draufgeht. Wenn du viele LV's hast, siehst auf einen Blick, was sich wie schnell füllt (zB bei LOG-Dateien, die gelegentlich in nicht-FHS-konformen Directories auftreten.
3.) Fragmentierung:
Die Dateisysteme, in denen viel compiliert wird bzw. dauernd viele Dateien modifiziert... werden (zB /usr/src/linux) fragmentieren natürlich stark. Durch viele LV's wirkt sich das nicht nachteilig auf das restliche System aus
4.) Sicherheit corrupted FS:
Wenn wirklich einmal ein Dateisystem beschädigt wird, ist die Schadwirkung geringer
5.) Sicherheit rw:
Diverse Filesysteme wie /usr, /opt, ... sind bei mir read-only gemountet. Nur wenn ich wirklich was modifizieren will - zB bei einem Update - schalte ich sie auf read-write. Eine ganz billige und bequeme Methode, rootkits zu vermeiden (kein mir bekanntes Tool mountet vor dem infizieren die Dateisysteme mit -o remount,rw ;-) )
6.) Sicherheit ro:
Dadurch, daß die Systemteile ro sind, wird darauf logischerweise nie geschrieben. Gerade bei den Systemteilen (die du ja in einem Recoveryfall brauchst) hast so die höchste Chance der Funktionsfähigkeit.
7.) Performance ro:
Dadurch, daß bei ro-Dateisystemen die "Last Access Time" nicht modifiziert wird, reduzierst du sinnlosen DiskIO. Verschärft noch bei den Journalling-FS wie reiser oder ext3, wo diese Modifikation natürlich auch Transaktionen im Journal auslöst.
8.) Flexibilität:
Früher legte man ein paar Partitionen an - und mit der Dauer des Betriebs entstanden "Linkfarmen", weil zB in / noch Platz war aber /usr voll... mit LVM kein Problem
9.) Unterschiedliche Dateien - unterschiedliche Dateisystemoptionen.
Du kannst so bequem das Optimum für deinen Rechner rausholen. Natürlich gelten für Verzeichnisse mit vielen, kleinen Dateien (zB dein Samba-Share für Word-Documente) ganz andere Parameter als für zB deine Datenbank-Directories. Durch verschiedene LV's legst ganz einfach verschiedene FS an - und kannst jedes separat tunen
10.) Bequemlichkeit bei virtuellen Maschinen:
Du legst dir dein LV mit der "Basisinstallation" für alle virtuelle Maschinen an - und installierst vom Host bequem dorthin. Durch COW sparst viel Platz - und gewinnst wieder Sicherheit durch LVM
11.) Performance FS-Auswahl:
Wenn du einige Dateisysteme eh nur read-only benutzt, ist natürlich journalling ein sinnloser Aufwand und Urrassen von Storage fürs System. /boot, /usr, /opt, ... sind dadurch natürlich bequeme Kandidaten für ein nicht-journalling-FS wie ext2
12.) Einfache Erweiterung:
Dateisysteme lassen sich einfach zB via
lvextend -L +1G /dev/system/home
vergrößern (wenn deine VG "system" benammst ist)
13.) Einfaches Plattenanfügen
Wenn du eine neue Platte hast - zB hdb - machst einfach
pvcreate /dev/hdb
vgextend system /dev/hdb
und du hast den zusätzlichen Platz zur Verfügung und kannst ihnen den LV's zuordnen - als ob es dieselbe alte Platte wäre.
14.) Snapshots
Du kannst bequem ein Snapshot von einer LV ziehen. Sinngemäß sagst du dadurch "Erzeuge einen neuen Mountpoint, der genau dem Status des Dateisystems /genau/ jetzt entspricht, lasse aber alle wie bisher weiterarbeiten".
Das ist total bequem und wichtig fürs Backup. Angenommen, irgendein Benutzer modifiziert gerade eine Datei am Server... zB er benammst HUGO in AHUGO um. Wenn parallel dein Backup läuft (und das beim Buchstaben "A" vorbei ist, aber noch nicht bei "H") - dann hättest du normal deine Datei verloren. Durch Snapshotting gibt's diese Race-Condition nicht.
15.) Feintunen von LV's bei mehreren Platten:
Du kannst jedes LV genau auf Platten binden. So habe ich zB ein paar alte Platten in meinem Rechner... auf denen ich LV's für Log-Dateien, ... definierte.
ein paar Schnelle sind für's System (/lib, ..), meine /wichtigen/ Userdaten  (also nicht MP3's und so, sondern meine Sourcen, ...)  fahre ich so bequem unter RAID1 - denn wenn man ehrlich ist, macht man eh zu selten ein Backup ;-).


Kurzum:
Du bekommst /massenhaft/ Vorteile mit LVM... Und alles, was du tun must, ist mit "man lvm" oder so zu beginnen und Dir einmal sagen wir 4-8 Stunden zeitnehmen, um dann aber wirklich alles zu haben (gelernt, getestet, ...).

Die investierte Zeit kommt relativ schnell rein... Je nach Systemänderung, Recovery-Fall, ... seeehr schnell.

cu
gepeinigter

Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
......
Re(6): Suse 10.0 Installation
04.11.2005, 10:29:00
Hmmm...

Du kriegst eben nicht alles mit Partitionen hin, was du mit LVM hinbekommst. Das scheitert schon an der Anzahl der möglichen Partitionen.

LVM schreit nach "MEHR"-Einsatz. Mehr Raffelung, mehr Sicherheit, mehr Partitionen, mehr Bequemlichkeit, ...

Es hat schon seinen guten Grund, warum einige Betriebssysteme (zB AIX von IBM) /ausschließlich/ auf LVM fahren - dort kannst nicht "normal" partitionieren.

Es ist wie bei vielen Sachen. Solange man es nicht ausprobiert hat, kann man die Vorteile nicht sehen. Früher dachte ich mir zB auch "Wozu Datenbanken".. Heute kann ich nicht mehr drauf verzichten ;-)

Anyways, die Logfiles hätte ich eben /nicht/ unter Raid - zumindest nicht alle.
die Logfiles sind allerdings ein Kandidat für eine Langsame Platte... Und auch hier ist es seehr praktisch, auf LVM zu setzen.

Angenommen, du hast eine VG ("system") mit einer LV "varlog", die du nach "/var/log" mountest.

Du hast varlog natürlich (zumindest ich mach es so ;-) ) auf der langsamsten Platte angelegt - das kannst mit Partitionen auch machen, zugegeben (abgesehen von der Anzahl).

Auf deiner langsamsten Platte hast in der Folge einige LVs - bei mir zB meine Kernelsourcen (weil da eh der gcc das Bottleneck ist) - also auch mein LV "usrsrc".

Wenn ich mir einen neuen Kernel downloade, kann es passieren, daß ich zB usrsrc um ein paar Megs vergrößern muß. Du machst nun einfach dein "lvextend" - und das System geht wie folgt vor:
.) Ermittle, ob noch genug frei in der VG ist - wenn nein, abbruch.
.) Ordne freien Platz von der Platte zu, auf der das LV liegt.
.) Wenn das nicht genügt, geh weiter zu einer anderen.

Du hast also ganz automatisch das erreicht, was du sonst wieder über repartitionierung lösen müßtest. Repartitionieren im Laufenden Betrieb gehört übrigens zu den Sachen, die ich /niemals/ auf meinem Produktionsserver machen würde - LV vergrößern hingegen schon.

BTW, im Vergleich zu windows...
Ich habe wohl weit mehr Zeit investieren müssen (rund 4 Tage) um die "Dynamischen Datenträgergruppen" auf einem XP Home zu konfigurieren und zum Laufen zu kriegen... Beginnend mit dem 2-Byte-Patch von der c'T, ...

Linux bleibt bequemer, einfacher, ...

Antworten PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
 

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung