Beiträge von [netcup] Alex W.

    warum geht das eigentlich nicht, dass man diese einfach zurückgibt?

    Das geht jederzeit. Entweder man macht einen close, was einer "Löschung/Freigabe" gleichkommt, die Domain steht also wieder für jedermann zum Registrieren zur Verfügung, oder es gibt eben den Transit. Der Transit steht nur bei de Domains zur Verfügung und bezüglich des genauen Close Verfahren ist dies durchaus unterschiedlich je nach Registrierungsstelle. ICANN Endungen z.B. werden bei einem Domain Close erst durch viele Verfahren geschickt wo der Besitzer die Domain wieder herstellen lassen kann, wo alle Provider Anträge auf Wiederherstellung einreichen können und eine abschließende Löschfrist wo keiner mehr eingreifen kann.

    Das Transit Verfahren ist nicht für "reguläre" Kündigungen gedacht, daher setzen Provider dies nicht bei jeder Kündigung von de Domains ein.

    Wir bieten da durchaus Lösungen an die ich hier jedoch leider nicht alle detailliert aufzählen kann, ich würde Sie daher gerne darum bitten uns eine kurze Anfrage dazu an mail@netcup.de oder auch gerne direkt an a.wachert@netcup.de zu senden. Desto mehr Details Sie in der E-Mail angeben desto expliziter können wir Ihnen gerne auch direkte Angebote unterbreiten. Es gibt unsererseits durchaus Wege dies auch bei einem "normalen" vServer anzubieten.

    Ich persönlich würde so in der Art vorgehen:

    • Domain bei netcup bestellen
    • Alle Daten auf den netcup Space umziehen
    • Bei netcup auf dem Space im Script einstellen das es die Datenbank beim jetzige Hoster nutzt wenn der externe Zugriff möglich ist
    • Die Domain mit Hilfe des AuthCodes transferieren
    • Nach erfolgreichem Umzug und 24Std warten das Script beim jetzige Hoster in den Wartungsmodus schalten
    • Die Datenbank umziehen
    • Bei netcup auf dem Space einstellen das die lokale Datenbank genutzt wird.

    Ich kann hier nur für mich persönlich sprechen, das muss ich vorab anmerken.

    Die Software ist auf die ersten Blicke mehr für dedizierte Systeme ausgelegt die dann wiederum in KVM Instanzen arbeitet oder in KVM Instanzen läuft. Des weiteren handelt es sich um eine Windows Software die lediglich per mono betrieben wird. Im Zusammenspiel mit den bekannten System Umgänglichkeiten von Minecraft ist dies eine denkbar ressourcenunfreundliche Weise einen Minecraft Server zu betreiben und zu administrieren.

    Da die Software zusätzlich auch noch verschlüsselt ist kann man nicht prüfen auf welche Weise dort die Distribution ermittelt wird und woher daher das Problem genauer kommen kann. Sie müssten sich daher also an den Hersteller der Software wenden.

    Das lässt sich nicht ganz nachvollziehen? Sie haben im VCP ein grafisches Interface um die Firewall, ähnlich wie bei Iptables, verwalten zu können, nur "schöner". Sie können die Firewallregeln angenehm sortieren und sogar temporär deaktivieren. Sie können sich selbst nicht vom Server aussperren da Sie unabhängig vom vServer jederzeit die Firewall steuern können und es steht eine API zum VCP zur Verfügung mit der Sie die Firewall auch automatisiert verwenden können, z.B. durch eigene Scripte oder fertige Scripte anderer User hier aus dem Forum, wie z.B. die fail2ban Konfiguration vom User sim.

    Wie gesagt, dafür kann es etliche Gründe geben, allerdings ist hier im Thema bisher nicht mal bekannt welches Basis Image auf dem vServer installiert wurde, ausser das es Debian ist.

    Lenny, Squeeze, Wheezy (Beta)... wurden alle Voraussetzungen für den Betrieb der Software erfüllt? Wie liest die Software die installierte Distribution bzw. deren Version aus? Woher stammt die Software? Welche Version der Software wurde verwendet?

    Ohne solche Informationen kann man leider, auch mit bestem Willen, leider nur raten.

    Ich hoffe netcup ist hier daran etwas zu ändern?

    Das Problem ist das der Hersteller weder kooperativ ist noch in der Lage eine ordentliche Lizenzverwaltung zu realisieren. Seitens Teamspeak sind dort viele Macken und Probleme bekannt, allerdings wird seit mittlerweile "Jahren" nichts unternommen.

    Wir können auf Anfrage, wie man dem Forum und dem Wiki entnehmen kann, ein tmpfs bereit stellen was Teamspeak benötigt damit es ohne aktive Lizenz genutzt werden kann. Auch hier ist jedoch der unumgängliche Weg anzuwenden das der Teamspeak Server so konfiguriert wird das er nur auf die IP-Adresse des vServers horcht da sonst Probleme seitens des Lizenzservermanagements von Teamspeak auftreten. Hier hilft es leider nur das immer mehr Anbieter und betroffene Kunden bei Teamspeak auf den Tisch klopfen damit deren System "vernünftig" umgesetzt wird.

    Hat Ihr vServer mindestens 6GB RAM das Sie den Minecraft mit 6G starten? Falls nicht, dürfte dies bereits das Problem sein. Java und Minecraft versagen den Dienste da keine 6GB RAM allokiert werden können. Das ist nur eine Vermutung, es kann natürlich diverse Ursachen dafür geben. Wenn selbst der Screen Prozess als solches stirbt klingt das nicht gut. Allerdings sind das nun auch zu wenig Informationen daher kann man leider nur Vermutungen anstellen.

    Wurden schon die Logs von Minecraft und die Syslogs untersucht?

    Es wird nichts heruntergefahren ;)

    Das Lizenzsystem seitens Teamspeak ist schlicht unintelligent umgesetzt (persönliche Meinung des Autors). Wenn der TS so startet das er an keine IP gebunden ist und somit auf 0.0.0.0 horcht, also alle IPs die es ggf. im vServer gibt, wird die TS Serverinstanz am Lizenzserver per MAC Adresse registriert auch wenn keine Lizenz zum Einsatz kommt, bzw. vor allem dann erst recht. Die MAC Adresse ist natürlich gleich für alle vServer die das gleiche ETH Interface nutzen.

    Meldet sich ein Client an einem TS Server an, wird geprüft ob dieser in der Datenbank seitens TS eine Lizenz hat, wenn dies nicht der Fall ist, liefert die TS Datenbank die letzte gestartete Instanz (IP) die auf die gleiche MAC registriert wurde zurück. Dadurch landen die Leute dann auf völlig falschen TS Servern.

    Hinweis: Dies wurde sinngemäß wieder gegeben, wie genau das Lizenzsystem arbeitet ist leider nicht bekannt. Aber dies scheint der technische Vorgang zu sein wenn man sich die Fehler und Problematik genauer anschaut.

    Es ist somit ein Fehler seitens Teamspeak. Der Hersteller scheint bisher auch keine Ambitionen haben dies zu ändern. Leider nimmt man bei Teamspeak offenbar schlichtweg in keinster Weise auf shared Kernel vServer Betreiber oder Kunden Rücksicht. Dass das Problem sehr sehr viele Leute und Anbieter haben, sieht man bei entsprechenden Google Suchen danach.

    Man kann dies beheben in dem man seinen Teamspeak Server so konfiguriert das dieser ausschließlich auf eine konfigurierte IP-Adresse des vServers horcht. Dies muss der Betreiber des Teamspeakservers vornehmen.

    Wir als Support haben keinerlei Einfluß auf diesen Vorgang.

    Wenn die Domain "nur" weiterleiten soll ist die SSL Proxy Funktion die falsche Anlaufstelle.

    Wenn Sie Webhosting haben können Sie dort Domains weiterleiten lassen, siehe dazu Confixx Handbuch für Kunden – netcup Wiki

    Wenn Sie einen vServer besitzen sollten Sie die Weiterleitung entsprechend Ihrer Dienste einrichten.

    Wenn Sie die Domain per DNS Record umleiten möchten, müssen Sie sich dort erkunden wo Sie die Webseiten betreiben, was als A-Record bzw. welche DNS Records Sie setzen müssen. Die DNS Einstellungen können Sie regulär im Kundenbereich bearbeiten.