STRIKE!
Okay ich hab einfach folgendes gemacht:
cd /mnt
rm * -rf
(ich brauchte keine Sicherung)
Und schon hat alles so geklappt wies oben im HowTo steht.
Der Server lief direkt nachdem ersten reboot mit SSHd.
Man sollte noch hinzuschreiben: Dass man für den Benutzer root ein Passwort setzen sollte, weil sonst muss man noch mal zurück ins Rescue, chrooten und PW setzen..das ist mir nämlich passiert
Okay: S4Y - VServer mit SuSE 9.3 Image läuft jetzt mit Debian Sarge! Jetzt funktioniert auch der aktuelle Debootstrap!
Also zusammen gefasst:
Okay ich hab einfach folgendes gemacht:
cd /mnt
rm * -rf
(ich brauchte keine Sicherung)
Und schon hat alles so geklappt wies oben im HowTo steht.
Der Server lief direkt nachdem ersten reboot mit SSHd.
Man sollte noch hinzuschreiben: Dass man für den Benutzer root ein Passwort setzen sollte, weil sonst muss man noch mal zurück ins Rescue, chrooten und PW setzen..das ist mir nämlich passiert
Okay: S4Y - VServer mit SuSE 9.3 Image läuft jetzt mit Debian Sarge! Jetzt funktioniert auch der aktuelle Debootstrap!
Also zusammen gefasst:
DIESES HOWTO FUNKTIONIERT AUF S4Y VSERVERN
Hallo!
(Ich kann leider den ursprünglichen Eintrag nicht mehr editieren. Deswegen hier: )
Es fehlt noch eine Zeile im Howto, die das Problem mit dem fehlenden Root-Passwort lösen sollte:
Am Ende von Schritt 4 (irgendwo nach der Netzwerkkonfiguration) sollte man
ausführen, um das root-Passwort zu setzen und einen normalen Benutzer anzulegen.
Ich hatte geschrieben, dass debootstrap das schon abfragt, das stimmt aber nicht.
Schöne Grüße,
Daniel D
PS: Ich war etwas skeptisch, als mein apt zusammen mit gcc auch das Paket kernel-header installiert hat. Aber ein kleines Programm, das sowohl auf Dateien als auch auf das Netzwerk zugreift, wurde erfolgreich kompiliert und es läuft auch. Wird schon alles schief gehen Ansonsten ist mein vServer immer noch zu rudimentär, um etwaige Folgen dieses Umbaus beurteilen zu können.
PPS: Bevor ich es vergesse ... Natürlich kann man debootstrap und die Konfiguration im chroot auch aus dem normalen OS (nicht recovery) des vServers heraus ausführen. (Dann bitte in ein leeres Verzeichnis hineinstallieren!) Das sorgt vielleicht für weniger Downzeit, weil man nur zum Hin- und Herschieben der Systeme in die Konsole muss.
(Ich kann leider den ursprünglichen Eintrag nicht mehr editieren. Deswegen hier: )
Es fehlt noch eine Zeile im Howto, die das Problem mit dem fehlenden Root-Passwort lösen sollte:
Am Ende von Schritt 4 (irgendwo nach der Netzwerkkonfiguration) sollte man
Code:
/usr/sbin/base-config newIch hatte geschrieben, dass debootstrap das schon abfragt, das stimmt aber nicht.
Schöne Grüße,
Daniel D
PS: Ich war etwas skeptisch, als mein apt zusammen mit gcc auch das Paket kernel-header installiert hat. Aber ein kleines Programm, das sowohl auf Dateien als auch auf das Netzwerk zugreift, wurde erfolgreich kompiliert und es läuft auch. Wird schon alles schief gehen
Ansonsten ist mein vServer immer noch zu rudimentär, um etwaige Folgen dieses Umbaus beurteilen zu können.PPS: Bevor ich es vergesse ... Natürlich kann man debootstrap und die Konfiguration im chroot auch aus dem normalen OS (nicht recovery) des vServers heraus ausführen. (Dann bitte in ein leeres Verzeichnis hineinstallieren!) Das sorgt vielleicht für weniger Downzeit, weil man nur zum Hin- und Herschieben der Systeme in die Konsole muss.
Hi also ich hab es auf einem vserver von 1blu getestet und es läuft spitze.
Dickes THX an euch.
Hardeware von meiner 1 Blu kiste ABER
-----------------
wenn bei /usr/sbin/base-config new
Terminated << kommt dann müsst ihr
ihr dev/pts mounten und es funktioniert
# cp Suse93/etc/fstab /etc/fstab
# mount -a
-----------------
hwclock wird blockiert
Anmerkung
----------
Dieser Post ist ein bisschen unübersichtlich wenn DanielD will kann er ja gerne meine "Installationserfahrungen" ^^ mit in den Thread aufnehmen
----------
Anmerkung während /usr/sbin/base-config new
----------
nicht apt konfigurieren das nimmt testing stattdessen bitte
# Security
deb ftp://ftp.de.debian.org/debian-security sarge/updates main contrib non-free
# Sarge Pakete
deb ftp://ftp.de.debian.org/debian stable main contrib non-free
----------
DIESES HOWTO FUNKTIONIERT AUF 1BLU VSERVERN
1blu Daten
Dickes THX an euch.
Hardeware von meiner 1 Blu kiste ABER
-----------------
wenn bei /usr/sbin/base-config new
Terminated << kommt dann müsst ihr
ihr dev/pts mounten und es funktioniert
# cp Suse93/etc/fstab /etc/fstab
# mount -a
-----------------
hwclock wird blockiert
Anmerkung
----------
Dieser Post ist ein bisschen unübersichtlich wenn DanielD will kann er ja gerne meine "Installationserfahrungen" ^^ mit in den Thread aufnehmen
----------
Anmerkung während /usr/sbin/base-config new
----------
nicht apt konfigurieren das nimmt testing stattdessen bitte
# Security
deb ftp://ftp.de.debian.org/debian-security sarge/updates main contrib non-free
# Sarge Pakete
deb ftp://ftp.de.debian.org/debian stable main contrib non-free
----------
DIESES HOWTO FUNKTIONIERT AUF 1BLU VSERVERN
1blu Daten
Last edited by a moderator:
Hi,
hab nen vServer von 1blu und als Standardsystem SuSE 9.3.
Jetzt habe ich eine ganz banale Frage, wie lösche ich das komplette Standardsystem damit es Platz für Debian gibt?
Wenn ich z.B. /bin lösche kann ich alle anderen Verzeichnisse nicht mehr löschen und er erstellt nachdem ich das repair-System beende und wieder neustarte wieder das Verzeichnis /bin her.
Wäre für eine schnelle Hilfe sehr dankbar.
Gruß
ouzo23
hab nen vServer von 1blu und als Standardsystem SuSE 9.3.
Jetzt habe ich eine ganz banale Frage, wie lösche ich das komplette Standardsystem damit es Platz für Debian gibt?
Wenn ich z.B. /bin lösche kann ich alle anderen Verzeichnisse nicht mehr löschen und er erstellt nachdem ich das repair-System beende und wieder neustarte wieder das Verzeichnis /bin her.
Wäre für eine schnelle Hilfe sehr dankbar.
Gruß
ouzo23
Hallo ouzo23, was machst denn du so?
Bist du dir sicher, dass du aus dem Rettungssystem heraus die Verzeichnisse des eigentlichen Systems löschst?
Mal am Beispiel von /bin ... Das Rettungssystem hat ja eine andere Verzeichnisstruktur (besser: Mount-Struktur) als das Standardsystem. Das /bin im Rettungssystem ist das /bin des Rettungssystem und nicht das /bin des Standardsystems, dass sich vielleicht eher unter /repair/bin oder /mount/bin oder sowas in der Art verbirgt. Deswegen siehst du auch das /bin des Standardsystems nach einem Neuboot wieder, weil du es gar nicht gelöscht hast. Und das /bin in der Rettungskonsole kommt wieder, weil das wesentlich für die Idee der Rettungskonsole ist, dass man die sich nicht kaputtmachen kann.
Also, nochmal etwas anders gesagt
Standardsystem bootet von virtueller Festplatte 1 (VP1)
Rettungssystem bootet von VP2 (keine dauerhaften Veränderungen daran möglich!)
Im Standardsystem ist z.B. /bin dann VP1:/bin. Und VP2 dürfte gar nicht sichtbar sein.
Im Rettungssystem ist /bin aber VP2:/bin und VP1:/bin findet man möglicherweise in /mount/bin.
Hoffentlich war das hilfreich.
Viel Erfolg!
Daniel D
Bist du dir sicher, dass du aus dem Rettungssystem heraus die Verzeichnisse des eigentlichen Systems löschst?
Mal am Beispiel von /bin ... Das Rettungssystem hat ja eine andere Verzeichnisstruktur (besser: Mount-Struktur) als das Standardsystem. Das /bin im Rettungssystem ist das /bin des Rettungssystem und nicht das /bin des Standardsystems, dass sich vielleicht eher unter /repair/bin oder /mount/bin oder sowas in der Art verbirgt. Deswegen siehst du auch das /bin des Standardsystems nach einem Neuboot wieder, weil du es gar nicht gelöscht hast. Und das /bin in der Rettungskonsole kommt wieder, weil das wesentlich für die Idee der Rettungskonsole ist, dass man die sich nicht kaputtmachen kann.
Also, nochmal etwas anders gesagt
Standardsystem bootet von virtueller Festplatte 1 (VP1)
Rettungssystem bootet von VP2 (keine dauerhaften Veränderungen daran möglich!)
Im Standardsystem ist z.B. /bin dann VP1:/bin. Und VP2 dürfte gar nicht sichtbar sein.
Im Rettungssystem ist /bin aber VP2:/bin und VP1:/bin findet man möglicherweise in /mount/bin.
Hoffentlich war das hilfreich.
Viel Erfolg!
Daniel D
Hallo ergo!
Mir gegebene Tipps habe ich bis jetzt immer eingearbeitet. Ich wäre also dankbar für deine Erfahrungen.
Wirklich ganz genau kann die Anleitung leider nicht sein. Jedoch sollten die Befehle in dieser Reihenfolge in etwa das richtige machen. Es ist auch nichts wirklich neues, was ich da beschreibe, sondern einfach das Anwenden einer bestimmten Debian-Install-Methode.
Wie ich meinen Server gesichert habe ... Nun ja, beim Minimalsystem muss nur SSH einigermaßen sicher gemacht werden, sonst läuft da nicht wirklich was drauf. Also, normalen Benutzer mit starkem Passwort einrichten und root-login in der entsprechenden Datei ausschalten. Für das Thema sind abere andere Forenbereiche besser geeignet und andere Leute kompetenter als ich
MfG, Daniel D
Mir gegebene Tipps habe ich bis jetzt immer eingearbeitet. Ich wäre also dankbar für deine Erfahrungen.
Wirklich ganz genau kann die Anleitung leider nicht sein. Jedoch sollten die Befehle in dieser Reihenfolge in etwa das richtige machen. Es ist auch nichts wirklich neues, was ich da beschreibe, sondern einfach das Anwenden einer bestimmten Debian-Install-Methode.
Wie ich meinen Server gesichert habe ... Nun ja, beim Minimalsystem muss nur SSH einigermaßen sicher gemacht werden, sonst läuft da nicht wirklich was drauf. Also, normalen Benutzer mit starkem Passwort einrichten und root-login in der entsprechenden Datei ausschalten. Für das Thema sind abere andere Forenbereiche besser geeignet und andere Leute kompetenter als ich
MfG, Daniel D
Hallo Ergo!
Einen Crash habe ich noch nicht erfolgreich geschafft
Backup-Howtos gibt es gleich nebenan in einem Thread, da würde ich mal reinschauen. Falls aber etwas Down-Zeit vertretbar ist (wie bei mir), würde ich das Backup sogar aus der Rettungskonsole machen und damit das ganze System im heruntergefahrenen Zustand dateiweise sichern. Dann muss man beim Sichern am wenigsten Denken. Das Zurückspielen passiert dann halt entweder komplett oder je nach Anwendung per Handarbeit.
MfG, Daniel D
Einen Crash habe ich noch nicht erfolgreich geschafft
Backup-Howtos gibt es gleich nebenan in einem Thread, da würde ich mal reinschauen. Falls aber etwas Down-Zeit vertretbar ist (wie bei mir), würde ich das Backup sogar aus der Rettungskonsole machen und damit das ganze System im heruntergefahrenen Zustand dateiweise sichern. Dann muss man beim Sichern am wenigsten Denken. Das Zurückspielen passiert dann halt entweder komplett oder je nach Anwendung per Handarbeit.
MfG, Daniel D
Hi,
ich habe ebenfalls den gleichen VServer auf Debian umgestellt. Allerdings habe ich nun ein Problem mit dem Webserver Apache. "nur-HTML" und "nur-PHP" funktioniert so weit. Kommt aber MySQL mit ins Spiel (phpmyadmin zB), dann antwortet der Server immer erst nach langer Verzögerung. Es ist, als ob er auf etwas wartet und nach einem Timeout dann losmacht. Hat jemand von euch das gleiche Problem und hat es vielleicht auch schon gelöst? Ansonsten habe ich mich bis auf die IP exakt an das HowTo gehalten.
Vielen Danke schon einmal,
Matthias
ich habe ebenfalls den gleichen VServer auf Debian umgestellt. Allerdings habe ich nun ein Problem mit dem Webserver Apache. "nur-HTML" und "nur-PHP" funktioniert so weit. Kommt aber MySQL mit ins Spiel (phpmyadmin zB), dann antwortet der Server immer erst nach langer Verzögerung. Es ist, als ob er auf etwas wartet und nach einem Timeout dann losmacht. Hat jemand von euch das gleiche Problem und hat es vielleicht auch schon gelöst? Ansonsten habe ich mich bis auf die IP exakt an das HowTo gehalten.
Vielen Danke schon einmal,
Matthias
ergo
Registered User
hi,
ich glaube mein eigentliches Problem ist ein deutlicher Performance-Verlust. Dateisystem-Zugriffe und eben auch MySQL-zugriffe von Apache sind extrem langsam. hast du dieses Howto 1:1 bis auf die IP-Adresse übernommen oder musstest du noch andere Einstellungen machen. insbesondere in richtung /etc/hostname zB.
gruß, metti
edit: hast du auch phpmyadmin in Benutzung?
ich glaube mein eigentliches Problem ist ein deutlicher Performance-Verlust. Dateisystem-Zugriffe und eben auch MySQL-zugriffe von Apache sind extrem langsam. hast du dieses Howto 1:1 bis auf die IP-Adresse übernommen oder musstest du noch andere Einstellungen machen. insbesondere in richtung /etc/hostname zB.
gruß, metti
edit: hast du auch phpmyadmin in Benutzung?
Last edited by a moderator:
Hallo!
Also, das Problem scheint offensichtlich irgendwo im MySQL-Bereich zu liegen. Such (oder frag) doch mal im entsprechenden Forum.
Trotzdem hier mal mein Tipp: DNS kann den Verbindungsaufbau zu MySQL extrem verlangsamen, nämlich dann, wenn DNS bzw. inverser DNS nicht funktioniert. Überprüfe doch bitte mal, ob in /etc/hostname ein Eintrag steht, der auf deine IP zeigt und für den am besten inverse DNS auch tut, also beispielsweise m².de oder ähnliches. Außerdem schadet es bestimmt nicht. in /etc/hosts auch noch 127.0.0.1 auf m².de zeigen zu lassen.
Und sei dir bitte bewusst, dass MySQL in der Standardkonfiguration ohne Passwort ausgeliefert wird. Wenn du dann noch einen phpmyadmin draufsetzt, der aus dem Web erreichbar ist, kann jeder auf deine DB zugreifen ...
Viel Erfolg,
DanielD
Also, das Problem scheint offensichtlich irgendwo im MySQL-Bereich zu liegen. Such (oder frag) doch mal im entsprechenden Forum.
Trotzdem hier mal mein Tipp: DNS kann den Verbindungsaufbau zu MySQL extrem verlangsamen, nämlich dann, wenn DNS bzw. inverser DNS nicht funktioniert. Überprüfe doch bitte mal, ob in /etc/hostname ein Eintrag steht, der auf deine IP zeigt und für den am besten inverse DNS auch tut, also beispielsweise m².de oder ähnliches. Außerdem schadet es bestimmt nicht. in /etc/hosts auch noch 127.0.0.1 auf m².de zeigen zu lassen.
Und sei dir bitte bewusst, dass MySQL in der Standardkonfiguration ohne Passwort ausgeliefert wird. Wenn du dann noch einen phpmyadmin draufsetzt, der aus dem Web erreichbar ist, kann jeder auf deine DB zugreifen ...
Viel Erfolg,
DanielD
Last edited by a moderator:
hi,
vielen Dank für die zahlreichen Beiträge. Ich habe mir nochmal testweise SuSE drauf gemacht und habe festgestellt, dass es obwohl es viel vollgepackter ist als das Debian trotzdem wesentlich performanter läuft. Einfache Dinge wie gunzip oder selbst Downloads waren mit Debian um einiges langsamer. Ich kann mir das irgendwie nicht so richtig erklären. Habt ihr ähnliches bemerkt?
mfg, metti
vielen Dank für die zahlreichen Beiträge. Ich habe mir nochmal testweise SuSE drauf gemacht und habe festgestellt, dass es obwohl es viel vollgepackter ist als das Debian trotzdem wesentlich performanter läuft. Einfache Dinge wie gunzip oder selbst Downloads waren mit Debian um einiges langsamer. Ich kann mir das irgendwie nicht so richtig erklären. Habt ihr ähnliches bemerkt?
Ja, das ist mir klar. Danke.
mfg, metti
Last edited by a moderator:
Hi,
ich habe gute Neuigkeiten. Naja, zumindest sind sie für mich gut. Scheinbar war irgendwas verdreht mit dem hostname. Ich habe diesmal bei der Debian-Installation so wenig wie möglich selbst Einfluss genommen und siehe da: Jetzt habe ich die Performance, die ich mir erhofft habe. Nochmal vielen Dank für die hilfreichen Hinweise.
Gruß, Metti
ich habe gute Neuigkeiten. Naja, zumindest sind sie für mich gut. Scheinbar war irgendwas verdreht mit dem hostname. Ich habe diesmal bei der Debian-Installation so wenig wie möglich selbst Einfluss genommen und siehe da: Jetzt habe ich die Performance, die ich mir erhofft habe. Nochmal vielen Dank für die hilfreichen Hinweise.
Gruß, Metti