Beiträge von RHA

Der Traffic zum TS lief über die FailOver-IP (wie von ein paar anderen Diensten/Gameservern auch). Ich hatte mal vor diese Dinge auf einen weiteren Server zu ziehen, wenn der vorhandene mal knapp wird. Dann hätte ich den neuen Voice-/Gameserver vorbereiten können, und hätte dann nur geswitcht. An den Punkt bin ich aber nicht gekommen, daher lief der Server ständig so weiter. Jetzt habe ich halt von den betroffenen Diensten die Configs angepasst, damit alles wieder läuft. Die Webdienste sind mit der Main-IP eingerichtet, daher brauchte ich dort keine Anpassungen vornehmen.

Die Form der IP-Zuweisung wie von dir vorgeschlagen kenne ich bisher gar nicht. Man arbeitet halt gerne mit gewohnten Dingen (solange es läuft). Ich werde aber erstmal die zweite IP weglassen.

Meine IP hatte ich in /etc/network/interfaces wie folgt konfiguriert :

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).




# The loopback network interface
auto lo
iface lo inet loopback




# The primary network interface
auto eth0
iface eth0 inet static
	address 46.38.241.240
	netmask 255.255.252.0
	gateway 46.38.240.1
	broadcast 46.38.243.255
	dns-nameservers 46.38.225.230 46.38.252.230




auto eth0:0
iface eth0:0 inet static
	address 46.38.230.169
	netmask 255.255.255.255

Mit DHCP läuft der Server seit heute Mittag einwandfrei

Ich will mich nicht zu früh freuen, aber ....

Nachdem ich alles probiert habe, was mir eingefallen ist, habe ich mich bereits damit abgefunden mein System dringend neu aufsetzen zu müssen. Ich habe mit Deaktivieren von vielen verschiedenen Diensten, Abschalten von IPv6, Abschalten von Gameservern, Umzug auf eine andere Node (vielen Dank an den Support), Wechsel des Netzwerktreibers und einigen anderen Dingen wirklich vieles getestet .... Nichts hat geholfen. Spätestens nach 20 Minuten ist man vom TS3-Server geflogen wegen Ping-Timeout.

Heute hatte ich eine letzte Idee : Im Rettungsmodus waren die MTR's gut ... wo ist der Unterschied? Im Rettungsmodus arbeitet die Netzwerkkarte mit DHCP und nur einer IP!!! Im "normalen" Modus sind die Netzwerkeinstellungen statisch und mit einer 2. IP (Switch-Over-IP).

Also .... die Switch-Over-IP deaktiviert, den Server auf DHCP umgestellt, und die IPs in den Voice-/Gameservern angepasst. Nun sind seit über 2 Stunden User im TS3 ohne Disconnect.

Sollte es wirklich mit der 2. IP zusammen hängen?

Habe es gerade ausprobiert (bevor ich deine Nachricht gesehen habe) ..... scheint alles zu funktionieren, ohne eine Einstellung machen zu müssen. Mein System läuft unter Ubuntu 14.04.

Ich hatte vorher noch in den udev-Regeln gestöbert, aber dort gab es keinen Eintrag.

Trotzdem Danke für die Antwort.

Hallo,

mal von meinem letzten Beitrag losgelöst :

Kann mir jemand sagen, ob ich bei der Umstellung des Netzwerks von e1000 auf virtio im System etwas beachten muss?

Ich habe mal irgendwo gelesen, das im System etwas umgestellt werden muss, kann dies aber weder im System, noch im Forum wiederfinden.

Ich habe jetzt erst nochmal IPv6 komplett auf dem Server deaktiviert. Habe ich bisher eh nicht genutzt (auch Routing nicht im Servercontrolpanel aktiviert).

Hat aber leider auch Nichts gebracht.

Muss ich etwas beachten, wenn ich die Netzwerkkarte von e1000 auf virtio umstellen möchte?

Habe das noch nie gemacht, deshalb frage ich ein wenig blöd. Würde es aber gerne mal probieren, ob die Umstellung etwas bringen würde. Auf einem zweiten vServer läuft auch ein TS3-Server auf Ubuntu 14.04, und der schnurrt vor sich hin ohne Probleme. Bei dem ist virtio eingestellt, bei meinem Problemserver e1000.

Also zu meinem Problem mit den Verbindungsabbrüchen bin ich mit dem Support in Kontakt (dieser hilft auch freundlich weiter), leider noch ohne Erfolg.

An dieser Stelle (der Support ist informiert, hier noch zur Vollständigkeit) muss ich noch erwähnen : Die Verbindungsabbrüche sind nicht nur auf das TS3 begrenzt, sondern betreffen alle Dienste, also http, ssh, ftp, Gameserver, ...

Bei meinen bisher angefertigten MTR's ist verwunderlich, das von Privat zum vServer wohl im letzten Hop (also zum vServer) Paketverluste auftreten. Zur gleichen Zeit von einem anderen vServer (Netcup) zu dem betroffenen vServer treten keine Paketverluste auf. Vom betroffenen vServer nach Außen habe ich auch keine Paketverluste. Im Rettungsmodus ist scheinbar alles in Ordnung. Die Probleme sind mit und ohne iptables sowie mit und ohne gestartete Gameserver vorhanden.

Hat irgendjemand eine Idee, was ich noch testen könnte, wobei ich nicht das System neu aufsetzen muss? Ein neues System würde ich gerne vermeiden, da der Aufwand nicht unerheblich ist.

Ich kann mir im Moment nicht erklären, was hier evtl. seine Arbeit nicht mehr korrekt verrichtet. Wenn es am System liegt, muss es ein zeitlicher Zufall sein, das die Probleme ausgerechnet an dem Tag der letzten gemeldeten Störung begonnen haben. Aber .... Zufälle soll es ja geben. Ich hoffe der Support hat noch eine Idee, oder von euch kann mir noch einer helfen. Würde gerne wieder den Server normal nutzen können.

Uuuups .... hast Recht ..... hatte noch den alten Link gespeichert.

Bekomme derzeit eine Meldung das Zertifikat wäre abgelaufen .......

Also MTR's habe ich gestern schon mal erstellt (im normalen Betrieb), diese muss ich jetzt nochmal im Rettungsmodus durchführen. Die MTR's habe ich erstellt von einem zweiten vServer zu dem betroffenen vServer (also Netcup-Intern), von Zuhause zu dem betroffenen vServer und vom betroffenen vServer zu dem zweiten vServer. Es fehlt noch vom betroffenen vServer zu bspw. Google, und das ganze Prozedere im Rettungsmodus.

Scheinbar ist der letzte Hop betroffen, allerdings nur von Zuhause zum vServer. Netcup-Intern konnte ich keine Paketverluste erkennen. Aber ich will hier nicht zu weit vorgreifen, die MTR's werden erstellt und dem Support zugesendet (kann aber noch einen Tag dauern).

Gibst du im TS3-Client eine (Sub-)Domain als Server-Adresse an, dann löst der Client die Adresse per DNS in die IP auf. Weiterhin wird geschaut, ob ein SRV-Record für diese (Sub-)Domain vorliegt. Ist der SRV-Record vorhanden, dann wird zu diesem versucht zu verbinden (in dem Record ist dann IP & Port angegeben). Ist kein SRV-Record vorhanden, dann verbindet der Client zu der aufgelösten IP mit dem Standard-Port (9987).

Wenn du den TS3-Server auf dem Standard-Port (9987) laufen lässt, dann muss nur die (Sub-)Domain per A-Record auf die IP des Servers zeigen auf welchem der TS3 läuft.

Seit der letzten Störungsmeldung am 18.11.2016 (Routingstörungen am DECIX), welche laut Status-Seite am 21.11.2016 behoben wurde, habe ich massive Probleme mit meinem TS3-Server. In unregelmäßigen Abständen (meist im Bereich 15-50 Minuten) haben alle anwesenden User einen Disconnect. Zu diesen Zeitpunkten kommt dann auch kein Ping mehr durch. Nach einer kurzen Zeit (meist 2-15 Sekunden) hat sich das Ganze dann beruhigt, und die Verbindung zum TS3 wird automatisch wieder hergestellt, und die Pings kommen auch wieder durch.

Am Server hatte sich Nichts verändert. Kein Update (weder System noch TS3-Server oder sonstige Server), keine Veränderung in den iptables, Nichts.

Hat jemand eine Idee? Oder kann jemand von ähnlichen Problemen berichten? Kann ich etwas prüfen, bevor ich den Support befrage?

Im Syslog kann ich immer wieder Meldungen der iptables sehen (SYN flood), welche aber auch vorher schon immer in gleichem Maße vorhanden waren. Ich glaube nicht, das es daran liegt. Wollte diese zwar mal in eine extra Datei schreiben lassen (extra .conf in rsyslog.d), habe dies aber aus irgendeinem Grund nicht zum Laufen bekommen.

Wenn jemand eine Idee hat, immer her damit. Ich probiere gerne aus.

Zitat von Fox1401

Was würdet Ihr euch so wünschen was kommen soll?

Ach, bisher hat Netcup immer eine gute Mischung getroffen. Es waren immer ein Server, Domains, Webspace, Groupware, Tasse (!!!), kleine Gimmicks und sonstiges dabei. Es kann nicht für jeden das optimale Angebot dabei sein, aber wenn man spart, kann man evtl. auch mal einen Server nehmen, welcher eine Nummer größer als der Bedarf ist. Ich freue mich jedenfalls wieder auf den Adventskalender. Mal sehen, ob er mich zu einem Serverwechsel bewegt (wird schwierig, da ich eigentlich für meine Anwendungen gut versorgt bin, aber die neue Generation reizt schon ein wenig).

Ich würde in jedem Fall empfehlen, wenn du dich mit dem administrieren beschäftigen möchtest, dann beginne nicht bei der Installation/Einrichtung einer Website. Das ist leider der falsche Ansatz, und das kannst du mit einem Webhosting-Paket erschlagen.

Ein Server kann Spaß machen, aber er macht in jedem Fall Arbeit. Das Wichtigste ist immer ... der Server muss gut abgesichert sein.

Als ich mit einem Server angefangen habe, da ging es mir um das Bereitstellen eines Gameservers sowie eines Teamspeak-Servers. Ich habe dies zuerst auf einer virtuellen Maschine durchprobiert, was sich mit Game-/TS-Server auch super einfach im eigenen Netzt testen lässt. Danach habe ich mich dann mit der Absicherung des Servers beschäftigt (auch in einer virtuellen Maschine). Im lokalen Netz lässt sich dann schön austesten, ob die Sicherheitsmaßnahmen greifen. Du kannst z.B. bewusst mal deine Zugangsdaten falsch eingeben, und schauen, ob bspw. fail2ban greift und deine IP sperrt.

Erst nach dem lokalen Testen und Probieren habe ich mir einen Server gemietet, und auf diesem erst einmal die Absicherung vorgenommen. Erst wenn der Server abgesichert ist, sollte irgendwelche Software in Betrieb genommen werden. Als Administrator bist du halt für ALLES was mit dem Server passiert und gemacht wird verantwortlich. Ist der Server nicht gesichert, wird im schlimmsten Fall noch gekapert, und dann als Datenschleuder (im schlimmsten Fall noch mit verbotenem Material) missbraucht, dann bist Du als Admin dafür verantwortlich.

Sich mit Linux beschäftigen und einen Server administrieren .... ja, das kann man lernen. Aber bitte mit Vorsicht.

Zitat von [netcup] Felix

Vielen Dank für Ihre Rückmeldungen und Tipps! Das könnten natürlich auch Mitbewerber sein die das schreiben.

Leider ist unter dem Namen keine Kundin bei uns bekannt. Sonst hätten wir diese selbstverständlich kontaktiert.

Wir sind mal gespannt wie Google reagiert. Zur Not geht die Sache am Montag zum RA.

Viele Grüße

Felix Preuß

Na dann mal hin zum RA.

"Google't" man nach dem Profilbild, kommt folgende Ergebnisliste . In den 3 unten aufgeführten Seiten geht es bei den Kommentaren von der betreffenden Person um das Thema sexuelle Belästigung. Ist also wohl kein Einzelfall.

Bei RayWorks zwischen den Scripten gab es auch immer was für ein Backup. Aber halt auch als Script ohne API.

Also, ich finde das Teil sieht echt gut aus. Sollte man mal ausprobieren.

Bisher verwende ich immer EasySCP. Da stört mich allerdings z.B. ein wenig die Struktur Admin/Reseller/User. Da ich keine Reseller habe (ich richte den Usern alles ein, und diese sollen nur Zugang zu deren eigenen Bereich haben), benötige ich die Berechtigungsstufe nicht (ist mir beim Einrichten immer zu viel hin und her Gehopse in der Oberfläche). Ich denke an die Oberfläche von Keyhelp könnte ich mich schnell gewöhnen.

Am einfachsten ist das doch über den Support zu klären. Das Forum ist immer noch Kunde zu Kunde, und der Support klinkt sich gelegentlich ein.

Zitat von [netcup] Benedikt

An dem Diagramm können Sie ablesen, wie viel reale CPU Leistung Ihr Server zu einem bestimmten Zeitpunkt benötigt hat. Das ist insbesondere hilfreich, um Lastspitzen/die CPU Last erkennen und nachvollziehen zu können. Ein kleiner Wert zeigt Ihnen hier an, dass Ihr Server noch genügend Reserve bei der CPU-Auslastung besitzt, und hier keine "Überlastungsprobleme" aufgrund fehlender Compute-Power drohen. Sie können das ganze mit Ihrem heimischen PC vergleichen: Dort ist die CPU ja auch nicht zu jeder Zeit 100% ausgelastet.

Naja, aber was genau sagt der Wert aus? Wann ist die CPU auf 100% also voll ausgelastet? MHz und GHz (falls M und G dafür stehen sollen) finde ich da etwas schlecht gewählt. Wie ThomasChr schon geschrieben hat, sollte die CPU ja eigentlich immer mit vollem Tempo laufen. Die Auslastung auf dem Kern ist ja eher interessant.

Was mit gerade noch aufgefallen ist, die Beschriftung der Y-Achse ist fehlerhaft. Das "2G" wiederholt sich.