Beiträge von theDude

  • KVM vServer?

    Zitat von [netcup] Felix;31488

    KVM ist eine Vollvirtualisierung. Sie bietet die Möglichkeit eigene Kernel zu nutzen. Bei Linux-VServer wird die Laufzeitumgebung virtualisiert, sprich der Kernel ist shared. Dieses bringt deutliche Performance-Vorteile.


    Da KVM immer mehr an Bedeutung gewinnt, wollen wir KVM auch anbieten. Unser Ziel ist, dass Sie als Kunde zwischen beiden Arten der Virtualisierung wählen können.



    Dafür! :)


    (Hier kommt irgendein Text, damit das Forum mich auch posten lässt... Mindestens 10 Zeichen... Pah!)

  • Backup: Welche Pfade sichern / Besonderheiten vServer

    Zitat von holzratte;25488

    es geht mir schon um komplettbackups, also wiederherstellung heißt: rettungskonsole anwerfen, alles löschen und mit dem restore überschreiben. da dürfte es ja eigentlich keinerlei probleme geben.


    Na gut, dann kannst du meinen Beitrag ignorieren. :rolleyes:


    Ich mache lieber Backups von den Daten alleine, installiere meine Pakete frisch, führe ein paar Skripte aus (Datenbank-Dump zurückspielen), ziehe die Daten & config zurück kopieren, Dienste neu starten).


    Das ist vielleicht etwas aufwändiger, bei meinem überwiegend privat genutzten Server aber insofern besser, als dass ich bei der Gelegenheit ggf. anstehende Änderungen einspielen kann. Außerdem werden ggf. vorhandene Inkonsistenzen (sofern sie nicht auch gesichert wurden) ausgemerzt.

  • Backup: Welche Pfade sichern / Besonderheiten vServer

    IMHO brauchst du /lib in einem Backup nicht. Dort liegen, wie der Name schon sagt, Bibliotheken (libs). Diese werden (oder sollten zumindest!) vom OS installiert und können sich im Prinzip bei jedem Software-Update ändern.


    /usr/


    Mal abgesehen davon, solltest du auf dein frisch installiertes System nicht die Bibliotheken eines anderen OS bügeln. Im schlimmsten Fall enthält das Backup x64 libs, dein OS ist x86.


    /var/spool ist hingegen tatsächlich recht wichtig (kann z.B. die in Bearbeitung befindlichen Mails, Druckaufträge, etc. enthalten - alles was "gespoolt" wird).


    Vielleicht hilft dir dieser Link weiter: http://www.debianadmin.com/lin…y-structure-overview.html

  • Interesse an Windows-vServern?

    Zitat von Artimis;22770

    Stimmt. Für mich als Student wäre es auch sehr genial, wenn ich meine kostenlose Lizenz von http://www.dreamspark.com nutzen könnte.


    Also bei uns hieß/heißt das das noch MSDNAA (MS Developer Network Academic Alliance, Stand), war weniger bunt (gottseidank, die Grafiker von MS gehören gesteinigt!) und recht unkomfortabel. Außerdem brauchte man zwingend einen Windows PC um z.B. die Windows Installations-DVD herunter zu laden.


    Ich schicke den Jungs mal ein Buch über Hennen und Eier.

  • Pma

    Zitat von killerbees19;25222

    Befehle, die man irgendwo findet, sollte man auch nicht einfach blind abkopieren und ausführen... ;)


    Ja. Man sollte wenigstens ungefähr wissen was man tut. Deswegen: Buch lesen! (gerne auch mehrere...)

  • Pma

    Zitat von killerbees19;25209

    Du liest die Beiträge hier aber schon, oder? Was daran falsch ist weiß übrigens sogar fast jeder Webspace User. Als vServer Inhaber und Administrator musst du das sowieso wissen :rolleyes:


    Ich schließe mich an. Das sind Basics. Auch wenn ich es nicht mag, wenn man solche Kommentare von sich gibt: So etwas sollte man wissen! :eek:


    Du versuchst /phpmyadmin zu verschieben (also einen nicht existierenden phpmyadmin-Ordner im root-Verzeichnis). Das kann nicht klappen!


    BITTE tu dir einen gefallen und kauf dir ein gutes Buch. Tipp: ISBN 978-38266-1587-0 oder neuere Fassung 978-38266-5520-3. Ich habe nur die alte (Debian 4), die Basics sollten überall die selben sein.


    Außerdem solltest du sowas vielleicht Daheim auf einem alten PC oder in einer VMWare ausprobieren.

  • Pma

    Ein nett gemeinter Hinweis: Du dir einen Gefallen und besorge dir ein Buch über Linux (Server)-Basics. Einfach mal im Buchladen um die Ecke oder auch im gut ausgestatteten Onlinehandel nachschauen.


    [edit]nächster Absatz wurde richtiggestellt, Sorry für den Fehler[/edit]
    slukas: Bei Digest werden die Zugangsdaten nicht direkt ausgetauscht. Das ist allerdings schnuppe, weil sich ein Man-in-the-middle recht einfach einschalten kann. Wenn man um dem entgegenzuwirken allerdings alles über SSL absichert, ist's recht Wurst ob man nun Digest oder Basic nutzt.


    Ansonsten fassen wir mal für JanH zusammen:

    • SSL einsetzen
    • Zugriffsschutz (z.B. .htaccess)
    • phpmyadmin Verzeichnis umbenennen


    Zu 1) Das solltest du hinkriegen. AFAIK liefert Apache die passende Config gleich mit (siehe /etc/apache2/sites-available). Im Zweifelsfall hilft das Apache-Handbuch und Google.
    Zu 2) Du kannst mit einer Apache-Direktive das Überschreiben der Zugriffskontrollmechanismen unterbinden (AllowOverride None). Das ist standardmäßig auch aktiviert!
    Zu 3) Das solltest du auch noch schaffen... :(

  • srcds init-script

    stachi: Kannst du mir das Skript mal zukommen lassen oder hier posten? Vielleicht kann ich ja etwas davon gebrauchen?


    thosch: Danke für das Angebot. Ich möchte suche aber ein (möglichst) waschechtes init-script.


    Falls jemand Interesse an meinem Ansatz hat einfach melden.

  • srcds init-script

    So, ich hab's mir jetzt selbst zusammengebastelt.


    srcds_run wird über start-stop-daemon gestartet. s-s-d fischt mir die PID raus und verwendet sie auch später wieder zum abschießen.


    Zusätzlich speichert srcds_i486/srcds_linux für jeden geforkten Server die PID weg. Diese wird dann für ein manuelles kill benutzt.


    Das ist IMHO noch die schönste und sauberste Variante. Am besten wäre es natürlich, wenn srcds_run selbst dafür sorgt, dass alle untergeordneten Prozesse mitgekillt werden.


    Immerhin: Kein screen, ich brauche nur einen Benutzer für alle scrds-Server und der aufwand für einen neuen Server beschränkt sich auf das Kopieren und anpassen des init-scripts bzw der default-datei.

  • srcds init-script

    Zitat von Artimis;25014

    Aber es mit Screen zu machen, ist m.M.n. der GAU.


    Begründung?


    Ich nehme halt screen, weil es nichts bringt nur den ursprünglichen srcds abzuschießen (der forkt ja den eigentlichen Serverprozess) oder nur den Serverprozess zu killen (der wird von parent-srcds neu gestartet).


    Beides zu killen kann auch in die Hose gehen; wenn der Serverprozess irgendwann mal gecrasht war und neu gestartet wurde, hat er dabei auch eine neue PID erhalten. Davon weiß ich dann aber nichts.


    Hängt alles unter screen und kille ich screen, dann sterben beide Prozesse.

  • srcds init-script

    Naja, nicht ganz: Das Skript startet eine screen-sitzung, fischt sich die PID dieser sitzung aus der ausgabe von PS und nutzt diese PID später zum killen.



    Finde ich sehr Unschön (neben einigen anderen sachen). Ich gebe der Sitzung einen Namen. Beim Abschießen selektiere ich die Sitzung über den Namen sende dann einen quit-Befehl.


    Und ich habe noch immer Probleme mit screen unter bestimmten Bedingungen. Aber da muss ich erstmal gucken, ob ich den Fehler nicht selbst hervorrufe. Für TF2 klappts ja soweit.

  • srcds init-script

    Ich habe auf dem hier diskutierten skript aufgebaut. Leider habe ich bei mir das Problem, dass screen nicht gestartet werden kann (Cannot open your terminal '/dev/pts/1' - please check.)



    Ich habe mir inzwischen ein eigenes script gebastelt, dass zwar mit TF2 klappt, nicht aber mit L4D ?!?


    Nur bei L4D kommt nun das Problem mit dem nicht verfügbaren/lesbaren Terminal.



    Was für mich gegen killall spricht: Wenn ich dann z.B. mal per Hand einen Server im jeweiligen Benutzer starten wollte, würde der auch mit gekillt. Und für jeden Server ein Benutzer - das ist mir zu umständlich gelöst.

  • srcds init-script

    Zitat von Artimis;25006

    Da ein Init-Script normal nur "start" und "stop", eventuell auch "restart" für die Faulen, unterstützen soll und somit a priori nicht mehrere Instanzen unterstützt, würde ich für jeden CS:S-Server ein eigenes Init-Script anlegen. Das ist auch deutlich ressourcenschonender, da es keinen Sinn macht, alle Server gleichzeitig den Server lahmlegen zu lassen.


    Ich weiß was ein init-Script ist. Viele, die irgendetwas unter dem namen anbieten anscheinend nicht (Such bei Google mal nach init scripten... auauau!)


    Zitat von Artimis;25006

    Was das killall angeht: Entweder, du nutzt pro CS:S-Instanz einen eigenen Benutzer oder läst es "vernünftig" über die PID. Die variable "$!" gibt die PID des letzten BG-Prozesses aus. Musst mal schauen, ob das klappt.


    ich weiß auch, wie ich das im Prinzip handhaben soll, aber aber wie gesagt: Ich bin zu faul mir selbst eins zu schreiben, deswegen habe ich gesucht. Leider tauchten bei der suche auch Skripte von "Spezialisten" auf, die die killall-variante eingesetzt haben.


    Mein Problem:


    Ich wollte das ganze dann doch selbst schreiben.


    Ansatz 1: start-stop-daemon. srcds ist aber kein daemon (läuft immer im vordergrund. dafür gibts --background, allerdings wird's beim killen schwierig. srcds forkt (zumindest bei l4d) einen serverprozess ab. Ich kille ich den, startet srcds eine neue instanz. Kille ich srcds, bleibt der server am leben. Und wenn der server aus irgendeinem grund mal crasht, wird er mit einer neuen pid neu gestartet. Also kann man hier nicht sauber killen.


    Ansatz 2: screen verwenden. Sobald ich aber su oder sudo verwende um screen als der server-user zu starten, bekomm eich Ärger: "Cannot open your terminal '/dev/pts/xx' - please check."


    Nach einiger Bastelei habe ich die Lust verloren und Nackenschmerzen bekommen. deswegen möchte ich mal horchen, wie ihr das so geregelt habt.

  • srcds init-script

    Ich bin auf der Suche nach einem ordentlichen init-script für srcds (source dedicated server)


    Das ganze sollte

    • die server nicht als root starten
    • sowohl start als auch stoppen können
    • nicht nur einen server unterstützen (kein "killall srcds" zum abschalten eines servers)


    Vorschläge?

  • fastDL auf Webspace einrichten?

    Bitte denkt immer daran diese Shells/PHP skipte auch wieder zu löschen oder gut zu sichern. Sonst kann jemand damit eine Menge Unfug treiben und euch eine hohe Rechnung für angestellte Schäden/Sperrung bescheren.

  • Gnome auf Ubuntu 10.04

    gnome-session ist ein programm (und ja, auch ein Paket). max gnome-session sagt:


    blablabla.


    Ohne gnome-session gibt's keine Gnome Sitzung.


    Ich habe gerade mal auf meinem eigenen vServer (Debian Lenny) aptitude install gnome-session ausprobiert. Ich bekomme eine lange liste von Paketen (322), die installiert werden müssten. Allerdings sehe ich dort nichts in Richtung fuse.
    Bist du sicher, dass deine vorherige Installation von ubuntu-desktop (das AFAIK fuse enthält) erfolgreich war? Ich vermute, dass die letzte Installation fehl schlug und apt nun bei jeder weiteren Installation fuse nachinstallieren will.


    Ich würde alles noch mal runter schmeißen und nur gnome-session installieren.



    Zum Thema Sicherheit: Wie du siehst werden dort viele Pakete installiert, die wahrscheinlich nicht für den Einsatz auf Servern entwickelt wurden. Sie können ggf. Sicherheitslücken enthalten, die dir das Genick brechen können (sprich: Schaden anrichten können). Aber das nur am Rande - es ist deine Verantwortung damit richtig umzugehen.