Beiträge von DeaD_EyE

    Meine Datei /etc/oidentd.conf:


    So wie ich das beurteilen kann, hast du keine Klammern vergessen. Könnte es sein, dass du die Konfigdatei mit einem Windows-Editor bearbeitet hast? Wenn ja, dann musst du CR (Carrige Return) enternen. Ein vernünftiger Editor ermöglicht das. Ich hab mal gelesen, dass der ASCII Upload bei einem FTP-Programm auch dieses Zeichen entfernt.

    oder


    Nur Usernamen anzeigen:


    Code
    cat /etc/passwd | cut -d ' ' -f 1


    Zur Anzeige von zugehörigen uids und gids:


    Code
    for user in $(cat /etc/passwd | cut -d ':' -f 1); do id $user; done


    Alle User zählen:

    Code
    cat /etc/passwd | wc -l

    Ja, der Mieter ist für alles, was auf seinem gemieteten Server abläuft verantwortlich. Das weiß jeder. Doch was der Provider dort macht ist grob Fahrlässig. Wenigstens bei der Übergabe sollte der Server nicht direkt gehackt werden.

    Stimmt. Es zeigt dennoch die Unfähigkeit des Providers, auch wenn er nicht diese Aufgabe hat. Normal sollte ein Server bei der Übergabe halbwegs sicher sein. Hier ist das Gegenteil gegeben. Die Aussage disqualifiziert den Provider und ich möchte nicht wissen, was die beim Support machen.


    Am besten ist das mit dem TS2-Server. Seit den letzten Bugs würde ich diesen Server nichtmals in der Gruppe user laufen lassen. Bei einer Betaversion gab es z.B. einen Bug, der es erlaubte Zugriff per Webinterface auf das Dateisystem vom Root-Server zu erlangen. Unschön wird es dann, wenn der TS-Server mit root-Rechten läuft.

    Generall sollte man sich nur nen Root-Server mieten, wenn man Ahnung hat. Was hat der Anbieter damit zu tun? Waren die Server vom Anbieter vorinstalliert? Wenn ja, dann frage ich mich, ob sie ihre anderen Server auch so verwalten (ich meine auch die eigen für Webspace, Kundendaten usw..). Was aber die Antwort vom Anbieter soll verstehe ich auch nicht. allein schon wegen dieser Aussage sollte man den Anbieter wirklich meiden :D


    Am besten ist es wenn man alles selber macht und sich nicht auf andere verlässt. So kann man wenigstens wegen den eigenen Fehlern belangt werden und nicht durch Fehler dritter.

    Ich hab dafür eine Anleitung: [Linux] Maps Nav-Generator


    Ich habe 3 Scripte geschrieben, mit denen man Nav-Dateien erstellen, komprimieren (tauschen) und zurückkopieren kann.


    1) Nav-Dateien erstellen
    Das Script startet den Server mit einer bestimmten Map, nachdem die Nav-Datei generiert wurde, wird die Map neugeladen. Durch einen kleinen Trick wird der Server nach dem Laden der neuen Map beendet. In der Schleife wird dann die nächste Map abgearbeitet.


    Das Script muss in das gleiche Verzeichnis, in dem sich srcds_run befindet.


    navgen.sh


    Die beiden Dateien server_nav.cfg und s_restart.cfg werden automatisch generiert.


    erver_nav.cfg

    Code
    nav_generate
    servercfgfile "s_restart.cfg"



    s_restart.cfg

    Code
    _restart


    Vorgehensweise:
    Zuerst muss über HLSW sv_cheats 1 und nav_check_file_consistency ausgeführt werden. Alles nach dem Befehl "nav_check_file_consistency" muss kopiert werden die letzte Zeile "$UHRZEIT HLSW Information: Verbindung getrennt" muss ausgelassen werden. Der Inhalt muss dann in der Datei "navfiles.txt" gespeichert werden, die dann zusammen mit dem Script zum Gleichen Ort wie "srcds_run" kopiert wird.


    Der Server wird mit nice -n $nice ./srcds_run -game "$game" -port $port -maxplayers 2 +map $map +servercfgfile server_nav.cfg +sv_password "xx" +sv_cheats 1 +rcon_password "$rcon" +hostname $hostname gestartet.


    Mit "nice" wird dem Prozess eine Nettigkeit zugeordnet. Je höher der Wert (-20 - 19), desto niedriger ist die Priorität.


    Die "servercfgfile" wird nach dem Mapchange geladen. Da in der server_nav.cfg die Variable servercfgfile neu gesetzt wird, wird die Datei s_restart.cfg nach Beendigung der Generierung geladen (Mapchange). Da der Inhalt einfach nur "_restart" ist, wird der Server einfach beendet. Nach Beendigung wird die For-Schleife weiter abgearbeitet.


    Die beiden Echo-Befehle am Anfang vor der Schleife generieren nur die beiden Dateien, die nach der Abarbeitung der Schleife wieder gelöscht werden.


    Das ganze kann man noch im Screen starten.


    Ich kann nicht für Fehlerfreiheit garantieren. Maps, die den Server zum abstürzen bringen werden nicht nocheinmal abgearbeitet. Es sollte nicht vergessen werden die Datei navfiles.txt wieder zu entfernen.


    2) Nav-Dateien kopieren und komprimieren
    compress_nav_files.sh: Das Script ist ein bisschen einfacher aufgebaut. Es kopiert die ganzen nav-Dateien in ein Temp-Verzeichnis das vorher erstellt wird. Nachdem alle Dateien kopiert worden sind, wird vom allen bsp-Dateien eine md5summe erstellt. Diese Dateien dienen später zur Überprüfung beim Zurückkopieren, ob es sich auch um die gleiche Map handelt.


    Update: Ich habe noch ein paar Bugs entfernt.


    3) Nav-Dateien zurückkopieren
    copy_nav_files.sh: Kopiert die Nav-Dateien aus dem Archiv. Da es manchmal verschiedene Versionen von Maps gibt, wird mit "md5sum" überprüft, ob es sich um die gleiche Datei handelt. Die Nav-Dateien werden dann bei positiver Überprüfung einfach überschrieben (Veraltete sowie aktuelle, vorher besser ein Backup machen).


    Paar fertige Nav-Dateien: http://ftp.gbs-server.de/valve/hl2/cstrike/maps/nav_files/

    Zitat

    ich habe einen server von 1blu , V-Server unlimited XXL, der hat irgendwas mit 64bit und deshalb wars ein klein wenig kompliziert mit ts .. naja ichhoffe das es bei DOD:S nichts ausmacht ...


    Kündige den Server. Das spart Zeit und Ärger. Du wirst recht enttäuscht sein mit deinem DOD:S Server.

    Ja, Tickrate 33 reicht. Die Konsolenvariable "tv_snapshotrate" (Standard 16) bestimmt mit wie vielen Änderungen pro Sekunde der SourceTV-Server senden soll. Dieser Wert kann nicht höher als die Tickrate vom Server sein <meine Vermutung>. Der Masterserver (der Server auf dem gespielt wird) wird dabei das Maximum festlegen. Ich denke mal, dass für eine Erhöhung von "tv_snapshotrate" auf dem Masterserver nur was bringt, wenn dieser Wert auch auch dem Relayserver verwendet wird.


    Das bringt beim Aufnehmen von SrcTV-Demos was. Sie laufen beim Abspielen dann flüssiger. Es belastet den Gameserver aber auch stärker.

    Er hat doch hier geantwortet. Reicht das nicht?
    So geheim kann das nicht sein. Ich kannte diesen Befehl und die Möglichkeit. Ich habs vorhin auch zum ersten mal getestet.

    Wenn ich das hier so lese bekomme ich es mit der Angst zu tun. Die Zahl der Leute, die sich einen Linux-Root mieten und noch keine Kenntnisse haben steigt immer weiter. Ob du sowas zuhause machst oder mit einem Server, der eine Fette 100Mbit Anbindung hat, ist ein kleiner Unterschied. Die Leute schreiben in allen Foren nicht ohne Grund, dass man die Finger von einem Linux-Root lassen soll.


    Das sollte helfen:
    chown -R hltv /home/hltv/cstrike/demos

    Gameserver:
    autoexec.cfg:

    Code
    tv_port 27100
    tv_password "xxx"
    tv_delay 90
    tv_maxclients 1
    tv_transmitall 1
    tv_snapshotrate 16 //höherer Wert ist flüssiger belastet den Server aber mehr
    tv_title "blubb"
    tv_name "blubb"
    tv_enable 1


    SrcTV-Relayserver:


    autoexec.cfg:

    Code
    tv_port 27200
    tv_title "Relayserver von blubb"
    tv_name "Relayserver von blubb"
    tv_enable 1
    tv_relaypassword "xxx"
    tv_relay "IP:PORT vom Gameserver"


    Ich habs vorhin zum ersten mal getestet. Es funktioniert so. Der SrcTV-Relayserver wird erst als normaler Gameserver gestartet. Nachdem der der Befehl tv_relay abgearbeitet wurde, kann man nur noch auf den SrcTV-Server vom RelayServer connecten. Viel Spaß beim testen.


    EDIT: Schon witzig, dass ein Supporter eines GSP schreibt, dass es nicht geht.