(fehler beseitigt) |
(bugfix) |
||
Line 5: | Line 5: | ||
== Einführung/Zusammenfassung == | == Einführung/Zusammenfassung == | ||
Das ''open sharedroot project'' dient dazu mehrere Linux-Systeme mit einem | Das ''open sharedroot project'' dient dazu mehrere Linux-Systeme mit einem Root-File-System zu benutzen. Ins besondere Cluster-Systeme deren Nodes sich ein gemeinsames Root-File-System teilen. Der Sinn dahinter ist, das die Arbeit für die Syncronisierung der Nodes weg fällt. So teilen sich z.B. alle Nodes die Apache-Konfiguration. Wenn auf einem Node die Apache-Konfiguration geändert wird, muss diese Änderung nicht auf den anderen Nodes nachgezogen werden. Die Hostabhängigen-Dateien werden mittels CDSL eingehängt. | ||
Folgende File-Systeme werden vom ''open sharedroot project'' unterstützt: | |||
Folgende File-Systeme werden vom ''open sharedroot project'' | |||
* NFSv3, NFSv4 | * NFSv3, NFSv4 | ||
* GFS2 | * GFS2 | ||
* Ocfs2 | * Ocfs2 | ||
* Ext3 als lokales | * Ext3 als lokales Filesystem | ||
''open sharedroot cluster'' besteht aus drei Hauptkomponenten: | ''open sharedroot cluster'' besteht aus drei Hauptkomponenten: | ||
# Einem angepassten initrd (com.oonics-bootimage) um das System zu booten, da es einige Anpassungen braucht, um von einem Cluster-File-System booten zu können. | |||
# Einem angepassten initrd ( | # Zum Teil angepasste Cluster-Dienste für die Cluster-Funktionalität. Diese Tools sind als ''com.oonics-Cluster Suite'' zusammengefasst.. | ||
# Zum Teil angepasste Cluster-Dienste für die Cluster-Funktionalität. Diese Tools sind als '' | # com.oonics-cdsls Ein Tool zum erstellen der cdsl Struktur (context dependent symbolic links). Das cdsl Konzept basiert auf bindmounts. | ||
# | |||
== Getestete Distributionen == | == Getestete Distributionen == | ||
Line 29: | Line 27: | ||
* Fedora 12 | * Fedora 12 | ||
* Fedora 14 | * Fedora 14 | ||
== Beispiel-Konfiguration/Installation == | == Beispiel-Konfiguration/Installation == | ||
Line 35: | Line 32: | ||
=== Übersicht === | === Übersicht === | ||
Es wird ein Fedora 14 als KVM-Wirt-System installiert. Dieser Wirt-Server dient auch als DHCP-Server und als TFTP-Server. Hier werden als zwei virtuelle | Es wird ein Fedora 14 als KVM-Wirt-System installiert. Dieser Wirt-Server dient auch als DHCP-Server und als TFTP-Server. Hier werden als zwei virtuelle Maschienen, (als zwei Nodes) installiert. Dies ist natürlich keine hochverfügbare Lösung, sondern dient nur dazu, das Grundprinzip zu demonstrieren ohne teure Hardware bereit zu müssen. Würden die beiden Nodes auf eigener Hardware laufen und auf ein richtiges HA-Storage zugreifen, hätte man eine richtige HA-Lösung. | ||
=== Wirt-System und Infrastruktur === | === Wirt-System und Infrastruktur === | ||
Eine normale Fedora Installation mit KVM Dient als Wirt-System. Standardmäßig ist KVM so konfiguriert dass alle v-Maschinen mit einer 192.168.122.* nach draußen geroutet werden. | |||
Auf dem Wirt-System sollten zwei virtuelle Gäste installiert werden. Jeder der beiden repräsentiert ein Node. | |||
=== Vorbereitung === | === Vorbereitung === | ||
Es müssen DHCP/TFTP/PXE so eingerichtet werden, | Es müssen DHCP/TFTP/PXE so eingerichtet werden, dass die Nodes später damit booten können. | ||
=== Installation der OSR-Pakete === | === Installation der OSR-Pakete === | ||
Zunächst muss natürlich | Zunächst muss natürlich Dracut in der letzten Version installiert sein (Siehe: [[dracut|Dracut]]). | ||
==== Die unterschiedliche Arten einen Cluster zu booten ==== | ==== Die unterschiedliche Arten einen Cluster zu booten ==== | ||
Line 57: | Line 52: | ||
Es gibt prinzipiell zwei Wege das booten des Clusters zu steuern/konfigurieren. | Es gibt prinzipiell zwei Wege das booten des Clusters zu steuern/konfigurieren. | ||
# ''static initrd'': | # ''static initrd'': Dem Bootloader können Parameter mitgegeben werden. Diese Parameter werden über den üblichen Weg gesetzt. Entweder über die Grub-Konfiguration oder beim Booten mittels Boot-Menü (hier edit-Modus). | ||
# ''full featured initrd'': Beim erstellen des initrd über Dracut werden die Werte der Cluster-Konfiguration ausgelesen und im initrd gespeichert | # ''full featured initrd'': Beim erstellen des initrd über Dracut werden die Werte der Cluster-Konfiguration ausgelesen und im initrd gespeichert, einschließlich Root-Device, Node-ID, MAC-Adresse usw. | ||
Der erste Weg hat den Vorteil, | Der erste Weg hat den Vorteil, daß das initrd nicht geändert werden muss wenn sich die Konfiguration des Cluster ändert. Der Vorteil des zweiten Wegs ist, dass alle Features unterstützt werden die ein OSR-Cluster bietet. Zudem kann eine Boot-Konfiguration für alle Nodes benutzt werden. | ||
==== Benötigte RPMs für ''static initrd'' ==== | ==== Benötigte RPMs für ''static initrd'' ==== | ||
Line 83: | Line 78: | ||
yum install osr-dracut-module comoonics-cdsl-py osr-dracut-module-cluster | yum install osr-dracut-module comoonics-cdsl-py osr-dracut-module-cluster | ||
Oder installiere folgende rRPMs (aber jeweils letzte Version): | Oder installiere folgende rRPMs (aber jeweils letzte Version): | ||
Line 115: | Line 108: | ||
make uninstall | make uninstall | ||
=== Erstellen einer Cluster-Konfiguration === | === Erstellen einer Cluster-Konfiguration === | ||
Erstelle | Erstelle eine Cluster-Konfigurations-Datei im Pfad /etc/cluster/cluster.conf . | ||
In der folgenden Beispiel-Konfiguration fehlen die valid fencing Konfigurationen. Das ist natürlich später ein mal wichtig, wenn der Cluster produktiv arbeitet soll. | In der folgenden Beispiel-Konfiguration fehlen die valid fencing Konfigurationen. Das ist natürlich später ein mal wichtig, wenn der Cluster produktiv arbeitet soll. | ||
Line 143: | Line 135: | ||
=== Erstellen eines ''shared root filesystem'' === | === Erstellen eines ''shared root filesystem'' === | ||
Das ''shared root filesystem'' muss - natürlich - von einem NFS exportiert werden, damit es zur Verfügung steht. Dann kann auf dem Node der für die Installation dient | Das ''shared root filesystem'' muss - natürlich - von einem NFS exportiert werden, damit es zur Verfügung steht. Dann kann auf dem Node der für die Installation dient das NFS eingehangen werden. Mit diesem Befehl hängen wir das '/mnt/virtual/nfsosr/fc11' als künftiges Root ein.: | ||
mount -t nfs 192.168.122.1:/mnt/virtual/nfsosr/fc11 /mnt/newroot/ | mount -t nfs 192.168.122.1:/mnt/virtual/nfsosr/fc11 /mnt/newroot/ | ||
Line 151: | Line 143: | ||
cp -ax / /mnt/newroot/ | cp -ax / /mnt/newroot/ | ||
cp /boot/*$(uname -r)* /mnt/newroot/boot | cp /boot/*$(uname -r)* /mnt/newroot/boot | ||
Dann müssen wir noch ein paar benötigte Verzeichnisse erstellen (wenn es sie noch nicht gibt): | Dann müssen wir noch ein paar benötigte Verzeichnisse erstellen (wenn es sie noch nicht gibt): | ||
Line 183: | Line 174: | ||
com-mkcdsl -s /var/lib | com-mkcdsl -s /var/lib | ||
Das '/etc/sysconfig/network' wird wiederum ''hostdependent'' gemacht: | Das '/etc/sysconfig/network' wird wiederum ''hostdependent'' gemacht: | ||
Line 189: | Line 179: | ||
com-mkcdsl -a /etc/sysconfig/network | com-mkcdsl -a /etc/sysconfig/network | ||
Bearbeite die hostdependent network-Konfiguration und ändere den | Bearbeite die hostdependent network-Konfiguration und ändere den Hostname. Mit dem vorgeschlagenen Befehl öffnest du alle Netzwerk-Konfigurationen auf einmal. Um mit vi zur nächsten Datei zu gelangen drückst du ''Esc'' gefolgt von ''n'' (für ''next''). Entfernt werden muss der Eintrag der MAC-Adresse.: | ||
vi /cluster/cdsl/?/etc/sysconfig/network | vi /cluster/cdsl/?/etc/sysconfig/network | ||
Line 204: | Line 193: | ||
rm -f /etc/sysconfig/network-scripts/ifcfg-eth0 | rm -f /etc/sysconfig/network-scripts/ifcfg-eth0 | ||
Anpassen von '/mnt/newroot/etc/fstab'. Es darf kein Root-Filesystem mehr eingetragen sein.: | |||
Anpassen von '/mnt/newroot/etc/fstab'. Es darf kein | |||
devpts /dev/pts devpts gid=5,mode=620 0 0 | devpts /dev/pts devpts gid=5,mode=620 0 0 | ||
Line 231: | Line 219: | ||
=== Erstellen der boot-Konfiguration === | === Erstellen der boot-Konfiguration === | ||
Es muss eine PXE-boot-Konfiguration erstellt worden sein. | Es muss eine PXE-boot-Konfiguration erstellt worden sein. | ||
Line 239: | Line 226: | ||
Die TFTP Konfiguration könnte etwa so aussehen... | Die TFTP Konfiguration könnte etwa so aussehen... | ||
'''Beispiel A:''' Hier werden dem Cluster beim booten die wichtigsten Informationen mitgegeben.: | |||
'''Beispiel A | |||
# Menus | # Menus | ||
Line 254: | Line 240: | ||
APPEND initrd=/nfsdracut/initrd_sr root=nfs:192.168.122.1:/mnt/virtual/nfsosr/fc11 rw rd.shell rd.debug | APPEND initrd=/nfsdracut/initrd_sr root=nfs:192.168.122.1:/mnt/virtual/nfsosr/fc11 rw rd.shell rd.debug | ||
'''Beispiel B:''' Hier eine Konfiguration die alle Information aus der Cluster-Konfiguration zieht bzw. zur boot-Zeit automatisch generiert: | |||
'''Beispiel B | |||
# Menus | # Menus | ||
Line 269: | Line 253: | ||
KERNEL /OR-nfsdracut/vmlinuz | KERNEL /OR-nfsdracut/vmlinuz | ||
APPEND initrd=/nfsdracut/initrd_sr | APPEND initrd=/nfsdracut/initrd_sr | ||
==== Erstellen des ''Shared Root initrd'' ==== | ==== Erstellen des ''Shared Root initrd'' ==== | ||
Auf dem Node, der zur Installation verwendet wird und zu diesem Zeitpunkt immer noch im chroot-Modus sein sollte, wird jetzt das initrd erstellt. | |||
Auf dem Node, der zur | |||
Für ein ''static initrd'' wird dieser Befehl ausgeführt: | Für ein ''static initrd'' wird dieser Befehl ausgeführt: | ||
Line 285: | Line 266: | ||
dracut -f -a "osr osr-cluster" /boot/initrd_sr-$(uname -r).img $(uname -r) | dracut -f -a "osr osr-cluster" /boot/initrd_sr-$(uname -r).img $(uname -r) | ||
Das erstellte initrd und der Kernel muss jetzt noch in den TFTP bzw. PXE-Server kopiert werden, damit diese für den Netzwerk-boot zur | Das erstellte initrd und der Kernel muss jetzt noch in den TFTP bzw. PXE-Server kopiert werden, damit diese für den Netzwerk-boot zur Verfügung steht. | ||
=== Aufräumen === | === Aufräumen === | ||
Auf dem Node der (bisher) zum | Auf dem Node der (bisher) zum Installieren verwendet wurde, wird nun der chroot-Modus verlassen und folgende Verzeichnisse ausgehangen: | ||
exit | exit | ||
Line 301: | Line 281: | ||
=== Starten des zweiten Nodes === | === Starten des zweiten Nodes === | ||
Es ist eine sehr gute Idee, an dieser Stelle, den zweiten Node zu starten. Auf diese Weise ist zu sehen, ob die Konfiguration okay ist. Kommt es zu Problemen, können noch Korrekturen mit dem ersten Node gemacht werden. Dazu | Es ist eine sehr gute Idee, an dieser Stelle, den zweiten Node zu starten. Auf diese Weise ist zu sehen, ob die Konfiguration okay ist. Kommt es zu Problemen, können noch Korrekturen mit dem ersten Node gemacht werden. Dazu müssen die nötigen Verzeichnisse im ersten Node wieder eingehangen werden und ein chroot gemacht werden. | ||
== Weiterführende Links == | == Weiterführende Links == | ||
Line 311: | Line 289: | ||
* Git-Repository: [https://github.com/Open-Sharedroot/Open-Sharedroot-Dracut github.com] | * Git-Repository: [https://github.com/Open-Sharedroot/Open-Sharedroot-Dracut github.com] | ||
== Kommentare und Diskussionen == | |||
== Kommentare und | |||
* Siehe [[Talk:Features/Opensharedroot]] | * Siehe [[Talk:Features/Opensharedroot]] | ||
== Quellen == | == Quellen == |
Revision as of 21:58, 7 July 2011
Open Sharedroot
Einführung/Zusammenfassung
Das open sharedroot project dient dazu mehrere Linux-Systeme mit einem Root-File-System zu benutzen. Ins besondere Cluster-Systeme deren Nodes sich ein gemeinsames Root-File-System teilen. Der Sinn dahinter ist, das die Arbeit für die Syncronisierung der Nodes weg fällt. So teilen sich z.B. alle Nodes die Apache-Konfiguration. Wenn auf einem Node die Apache-Konfiguration geändert wird, muss diese Änderung nicht auf den anderen Nodes nachgezogen werden. Die Hostabhängigen-Dateien werden mittels CDSL eingehängt.
Folgende File-Systeme werden vom open sharedroot project unterstützt:
- NFSv3, NFSv4
- GFS2
- Ocfs2
- Ext3 als lokales Filesystem
open sharedroot cluster besteht aus drei Hauptkomponenten:
- Einem angepassten initrd (com.oonics-bootimage) um das System zu booten, da es einige Anpassungen braucht, um von einem Cluster-File-System booten zu können.
- Zum Teil angepasste Cluster-Dienste für die Cluster-Funktionalität. Diese Tools sind als com.oonics-Cluster Suite zusammengefasst..
- com.oonics-cdsls Ein Tool zum erstellen der cdsl Struktur (context dependent symbolic links). Das cdsl Konzept basiert auf bindmounts.
Getestete Distributionen
- RHEL5
- RHEL4
- Fedora 11
- Fedora 12
- Fedora 14
Beispiel-Konfiguration/Installation
Übersicht
Es wird ein Fedora 14 als KVM-Wirt-System installiert. Dieser Wirt-Server dient auch als DHCP-Server und als TFTP-Server. Hier werden als zwei virtuelle Maschienen, (als zwei Nodes) installiert. Dies ist natürlich keine hochverfügbare Lösung, sondern dient nur dazu, das Grundprinzip zu demonstrieren ohne teure Hardware bereit zu müssen. Würden die beiden Nodes auf eigener Hardware laufen und auf ein richtiges HA-Storage zugreifen, hätte man eine richtige HA-Lösung.
Wirt-System und Infrastruktur
Eine normale Fedora Installation mit KVM Dient als Wirt-System. Standardmäßig ist KVM so konfiguriert dass alle v-Maschinen mit einer 192.168.122.* nach draußen geroutet werden.
Auf dem Wirt-System sollten zwei virtuelle Gäste installiert werden. Jeder der beiden repräsentiert ein Node.
Vorbereitung
Es müssen DHCP/TFTP/PXE so eingerichtet werden, dass die Nodes später damit booten können.
Installation der OSR-Pakete
Zunächst muss natürlich Dracut in der letzten Version installiert sein (Siehe: Dracut).
Die unterschiedliche Arten einen Cluster zu booten
Es gibt prinzipiell zwei Wege das booten des Clusters zu steuern/konfigurieren.
- static initrd: Dem Bootloader können Parameter mitgegeben werden. Diese Parameter werden über den üblichen Weg gesetzt. Entweder über die Grub-Konfiguration oder beim Booten mittels Boot-Menü (hier edit-Modus).
- full featured initrd: Beim erstellen des initrd über Dracut werden die Werte der Cluster-Konfiguration ausgelesen und im initrd gespeichert, einschließlich Root-Device, Node-ID, MAC-Adresse usw.
Der erste Weg hat den Vorteil, daß das initrd nicht geändert werden muss wenn sich die Konfiguration des Cluster ändert. Der Vorteil des zweiten Wegs ist, dass alle Features unterstützt werden die ein OSR-Cluster bietet. Zudem kann eine Boot-Konfiguration für alle Nodes benutzt werden.
Benötigte RPMs für static initrd
Führe folgenden Befehl aus:
yum install osr-dracut-module comoonics-cdsl-py
Oder installiere folgende RPMs (aber jeweils letzte Version):
Benötigte RPMs für full featured initrd
Führe folgenden Befehl aus:
yum install osr-dracut-module comoonics-cdsl-py osr-dracut-module-cluster
Oder installiere folgende rRPMs (aber jeweils letzte Version):
Entwickler-Versionen installieren
Wenn du die neueste Entwickler-Version benutzen möchtest, verwende unser Git-Repository: github.com
Verfahre dazu wie folgt:
yum install git git clone git://github.com/Open-Sharedroot/Open-Sharedroot-Dracut.git cd Open-Sharedroot-Dracut yum remove osr-dracut-module osr-dracut-module-cluster git pull make make install
Um die Pakete wieder zu deinstallieren (wenn du das möchtest/musst):
make uninstall
Erstellen einer Cluster-Konfiguration
Erstelle eine Cluster-Konfigurations-Datei im Pfad /etc/cluster/cluster.conf .
In der folgenden Beispiel-Konfiguration fehlen die valid fencing Konfigurationen. Das ist natürlich später ein mal wichtig, wenn der Cluster produktiv arbeitet soll.
<?xml version="1.0"?> <cluster config_version="1" name="axqad109" type="gfs"> <clusternodes> <clusternode name="node1" nodeid="1" votes="1"> <com_info> <rootvolume fstype="nfs" name="192.168.122.1:/mnt/virtual/nfsosr/fc11"/> <eth name="eth0" ip="192.168.122.171" mac="00:0C:29:C9:C6:F5" mask="255.255.255.0" gateway="192.168.122.1"/> </com_info> </clusternode> <clusternode name="node2" nodeid="2" votes="2"> <com_info> <rootvolume fstype="nfs" name="192.168.122.1:/mnt/virtual/nfsosr/fc11"/> <eth name="eth0" ip="192.168.122.172" mac="00:0C:29:C9:C6:F5" mask="255.255.255.0" gateway="192.168.122.1"/> </com_info> </clusternode> </clusternodes> </cluster>
Das shared root filesystem muss - natürlich - von einem NFS exportiert werden, damit es zur Verfügung steht. Dann kann auf dem Node der für die Installation dient das NFS eingehangen werden. Mit diesem Befehl hängen wir das '/mnt/virtual/nfsosr/fc11' als künftiges Root ein.:
mount -t nfs 192.168.122.1:/mnt/virtual/nfsosr/fc11 /mnt/newroot/
Jetzt alle Daten des lokalen Systems in das (künftige) shared root filesystem kopieren:
cp -ax / /mnt/newroot/ cp /boot/*$(uname -r)* /mnt/newroot/boot
Dann müssen wir noch ein paar benötigte Verzeichnisse erstellen (wenn es sie noch nicht gibt):
mkdir /mnt/newroot/proc mkdir /mnt/newroot/sys
Nun wird die neue cdsl-Infrastruktur auf dem shared root filesystem angelegt:
com-mkcdslinfrastructure -r /mnt/newroot
Diese wird in das File-System eingehangen:
mount --bind /mnt/newroot/cluster/cdsl/1/ /mnt/newroot/cdsl.local/
Dann werden weiter Verzeichnisabhängigkeiten dazu gemountet:
mount -t proc proc /mnt/newroot/proc mount -t sysfs none /mnt/newroot/sys mount --bind /mnt/newroot/dev /mnt/newroot/dev
Jetzt wird in das neue shared root filesystem gewechselt und als root verwendet:
chroot /mnt/newroot
Das '/var' Verzeichnis wird hostdependent (hostabhängig) gemacht (Parameter -a):
com-mkcdsl -a /var
Das '/var/lib' Verzeichnis wird wieder als shared(geteilt) eingerichtet (Parameter -s):
com-mkcdsl -s /var/lib
Das '/etc/sysconfig/network' wird wiederum hostdependent gemacht:
com-mkcdsl -a /etc/sysconfig/network
Bearbeite die hostdependent network-Konfiguration und ändere den Hostname. Mit dem vorgeschlagenen Befehl öffnest du alle Netzwerk-Konfigurationen auf einmal. Um mit vi zur nächsten Datei zu gelangen drückst du Esc gefolgt von n (für next). Entfernt werden muss der Eintrag der MAC-Adresse.:
vi /cluster/cdsl/?/etc/sysconfig/network
Erstellen des '/etc/mtab' link zu '/proc/mounts':
cd /etc/ rm -f mtab ln -s /proc/mounts mtab
Entfernen der Network-Konfiguration des Cluster:
rm -f /etc/sysconfig/network-scripts/ifcfg-eth0
Anpassen von '/mnt/newroot/etc/fstab'. Es darf kein Root-Filesystem mehr eingetragen sein.:
devpts /dev/pts devpts gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0
Ausschalten von SELinux:
[root@install-node3 comoonics]# cat /etc/sysconfig/selinux # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=disabled # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # mls - Multi Level Security protection. SELINUXTYPE=targeted
Ausschalten des NetworkManager:
chkconfig NetworkManager off
Erstellen der boot-Konfiguration
Es muss eine PXE-boot-Konfiguration erstellt worden sein.
TFTP Konfigurationsbeispiel
Die TFTP Konfiguration könnte etwa so aussehen...
Beispiel A: Hier werden dem Cluster beim booten die wichtigsten Informationen mitgegeben.:
# Menus # for OSR based on NFS timeout 100 prompt 1 default NFS-dracut-Cluster LABEL NFS-dracut-Cluster MENU LABEL NFSdracut NFS Configuration KERNEL /OR-nfsdracut/vmlinuz APPEND initrd=/nfsdracut/initrd_sr root=nfs:192.168.122.1:/mnt/virtual/nfsosr/fc11 rw rd.shell rd.debug
Beispiel B: Hier eine Konfiguration die alle Information aus der Cluster-Konfiguration zieht bzw. zur boot-Zeit automatisch generiert:
# Menus # for OSR based on NFS timeout 100 prompt 1 default NFS-dracut-Cluster LABEL NFS-dracut-Cluster MENU LABEL NFSdracut NFS Configuration KERNEL /OR-nfsdracut/vmlinuz APPEND initrd=/nfsdracut/initrd_sr
Auf dem Node, der zur Installation verwendet wird und zu diesem Zeitpunkt immer noch im chroot-Modus sein sollte, wird jetzt das initrd erstellt.
Für ein static initrd wird dieser Befehl ausgeführt:
dracut -f -a "osr" /boot/initrd_sr-$(uname -r).img $(uname -r)
Oder - wer alle features nutzen will verwendet den folgenden Befehl:
dracut -f -a "osr osr-cluster" /boot/initrd_sr-$(uname -r).img $(uname -r)
Das erstellte initrd und der Kernel muss jetzt noch in den TFTP bzw. PXE-Server kopiert werden, damit diese für den Netzwerk-boot zur Verfügung steht.
Aufräumen
Auf dem Node der (bisher) zum Installieren verwendet wurde, wird nun der chroot-Modus verlassen und folgende Verzeichnisse ausgehangen:
exit umount /mnt/newroot/cdsl.local umount /mnt/newroot/dev umount /mnt/newroot/proc umount /mnt/newroot/sys umount /mnt/newroot
Starten des zweiten Nodes
Es ist eine sehr gute Idee, an dieser Stelle, den zweiten Node zu starten. Auf diese Weise ist zu sehen, ob die Konfiguration okay ist. Kommt es zu Problemen, können noch Korrekturen mit dem ersten Node gemacht werden. Dazu müssen die nötigen Verzeichnisse im ersten Node wieder eingehangen werden und ein chroot gemacht werden.
Weiterführende Links
- Projekt-Seite open-sharedroot.org (alt) bzw. [ttp://comoonics.org/ comoonics.org (künftig)]
- Buzilla Instance: https://bugzilla.open-sharedroot.org/
- Mailing-Liste: open-sharedroot-users@lists.sourceforge.net, open-sharedroot-devel@lists.sourceforge.net
- Git-Repository: github.com
Kommentare und Diskussionen
Quellen
- Dieser Artikel basiert auf dem Text von Marc Grimme aus dem fedora-wiki der unter der Creative Commons Attribution-Share Alike License 3.0 Unported steht.
- Website des Projektes open-sharedroot.org
- Open-Sharedroot on SourceForge.net
- Source-hosting (github):
- Wikipedia-Artikel