Beiträge von Exiver

Hallo zusammen,

ich habe aktuell ein komisches Problem mit meinen RS 500 SAS G7SEa1 12M und VPS 1000 G7SEa1 12M.

Seit vorgestern zeigt mir mein Monitoring mehrfache Nicht-Erreichbarkeiten meines RS 500 SAS (der VPS 1000 ist bisher noch nicht im Monitoring, werde ich aber nachholen) für ein paar Minuten. Am 28.11 mehrfach zw. 5:40-5:48, 7:22-7:30, 9:12-9:20, 11:08-11:14 Uhr und heute zw. 3:37-3:55, 6:53-6:55, 14:17-14:25 Uhr. Gerade (~15:45 Uhr) war ich auf beiden Servern per SSH verbunden und hatte einen Timeout, gleichzeitig testweise auf dem Teamspeak-Server, welcher auf einem der Systeme läuft rausgeflogen. Komischerweise scheinen die Abbrüche nur via IPv4 zu passieren, andere User (alle, welche mit IPv6 verbinden) hatten zumindest im Teamspeak keinen disconnect.

Ich hatte vorhin bereits den Support kontaktiert, da war aber die SSH-Verbindung noch nicht abgebrochen und ich dachte, der zweite Server (VPS 1000) wäre nicht betroffen.

Nun könnte es natürlich an irgendeinem Anbieter oder Peering liegen, mein Anschluss liegt im Belwue (AS443) und ich habe aus dem Netz von Versatel (AS8881) eine Traceroute gemacht, die folgendermaßen aussieht:

1 213.30.xxx.xxx                      0% 4097   0.7ms     0.9 0.6    26.5     1.6

 2 195.202.xxx.xxx                     0% 4097   1.8ms     9.6 1.6   351.2    33.4

 3 62.214.35.141                      0% 4097   1.7ms     2.4 1.5    44.4     3.9

 4 62.214.37.130                      0% 4097   9.4ms    10.4 9.1   127.5      11

   62.214.37.118

 5 80.81.193.182                      0% 4097   9.5ms    10.4 9.3    23.5    10.3

   80.81.192.187

   193.178.185.44

 6 46.38.224.49                       0% 4097  15.6ms      18 10.2   110.1    20.4

   46.38.224.50

   81.95.2.41

   80.255.15.197

 7 37.120.175.xxx                   2.7% 4097    29ms    13.8 13.3    65.7    13.8

   80.255.15.197

   80.255.14.22

Von zu Hause siehts folgendermaßen aus:

# ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS

1 134.155.xxx.xxx 0% 2313 4.9ms 8.9 1.9 234.1 15.8

2 129.143.55.121 0% 2312 6ms 6.2 3.5 189.7 8.4

3 129.143.59.253 0% 2312 4.4ms 6.5 3.5 201.9 8.9

4 129.143.59.245 0% 2312 8ms 7.8 3.8 42.1 8.7

5 62.69.146.96 0% 2312 10.6ms 6.5 3.5 43.5 7.7

62.69.146.15

6 46.38.224.49 0% 2312 9.6ms 10.8 7.3 53.9 11.6

46.38.224.50

213.239.245.249

7 37.120.175.xxx 1% 2312 8.7ms 10 7.2 44.5 10.7

213.239.245.194

Jetzt frage ich mich doch, was machen Core-Backbone bzw. IP's von dem Anbieter mit dem roten H in meiner Traceroute? IPv4-Peering Problem?

Ich hatte ja wie bereits beschrieben mit dem Support-Kontakt, würde jedoch gerne von der Community mal das Feedback abwarten, ob dies jemand anderes auch schon festgestellt hat.

Meine beiden Server liegen in 37.120.160.0/19 bzw. 37.221.192.0/21. Konfigurationen wurden in den letzten Tagen nicht geändert, weshalb ich davon ausgehe, dass ich nichts kaputt gemacht habe, bzw. ich bei der Einrichtung von beiden Servern Fehler gemacht haben müsste, welcher sich jetzt erst auswirkt...

Grüße

Ein Mitarbeiter von Microsofts Mail Team (Spam Analysis) antwortet regelmäßig auf der mailop.org Mailingliste. Dort weißt er in solchen Fällen immer auf das von thomba vorgeschlagene Verhalten hin:

Open a HotMail Ticket http://go.microsoft.com/fwlink/?LinkID=614866&clcid

Dort dann nach der ersten Antwort (kommt vom Robot) erneut antworten und ggf. ein drittes Mal antworten. In der Regel kommt man dann dort runter. Zusätzlich im SNDS registrieren und die IP verifizieren. Das hilft normalerweise beim Ticket und man hat beim ersten menschlichen Kontakt schon eine positive Antwort.

Ps.: Die mailop.org Mailingliste kann ich nur empfehlen. Falls bei den großen Providern Probleme auftreten, weiß man es relativ zügig und muss gar nicht erst an seinem Setup forschen

Moin,

habe bei Gmail schon teilweise komisches Verhalten mit IPv6 festgestellt. SPF und DKIM für alle Domains gesetzt, ca 30-50 Mails am Tag in Richtung Google und trotzdem wird die ein oder andere Mail mit einem generischen Fehler geblockt. Nach ein wenig Recherche stellte sich heraus, dass Google im IPv6 Bereich ein wenig zickig beim akzeptieren von E-Mails ist. Habe daher komplett auf v6 Transport zu Gmail verzichtet und fahre dort nurnoch IPv4.

Auch, wenn es nicht direkt mit einem Problem zu tun hat - wollte nur kurz meine Erfahrung da lassen. Gegebenenfalls hat sich das aber mittlerweile gebessert, da ich seit ca einem Jahr nurnoch per v4 zustelle.

Hi,

wie hast du OTRS denn installiert? Du solltest in solchen Problemfällen immer auflisten, welche Schritte du wie gegangen bist (z.B. das Tutorial nennen) und welche Software (OS, Webserver etc) eingesetzt wird. Alles andere würde hier zu Rätselspielen führen

LG

Bei mir kommen Newsletter-Mails in der Regel direkt von einem Otto-Server

Received from r44.newsletter.otto.de (unknown [185.15.51.44]) by xxx.yyy.de (Postfix) with ESMTP id E4D5925C6030 for <ottode@xxx.de>; Sun,  4 Jun 2017 04:23:14 +0000 (UTC)

Habe auch schon andere Ausgangsserver gesehen, variiert stark.

Mails, die z.B. Bestellungen bestätigen oder Rechnungen senden, kommen von einer anderen Quelle:

Received from duoquinquetres.gamma.eccluster.com (duoquinquetres.gamma.eccluster.com [195.140.187.253]) by xxx.yyy.de (Postfix) with ESMTPS id 6B93325C6030 for <ottode@xxx.de>; Fri, 26 Feb 2016 21:46:32 +0000 (UTC)

Received from api06.muc.ec-messenger.com (api06.muc.domeus.com [172.16.8.91]) by mta16.muc.domeus.com (READY) with ESMTP id 0702F100132D0 for <ottode@xxx.de>; Fri, 26 Feb 2016 22:46:32 +0100 (CET)

Hast du deinen Mailserver nach einem Tutorial aufgesetzt? Wenn ja, welches?

Hast du bei der Installation des Servers im "vservercontrolpanel" ausgewählt, dass nur ein Teil der Festplatte benutzt werden soll?
Da die Partition relativ klein ist war das wohl der Fall - dann musst du erneut installieren und dort die gesamte Festplatte wählen..

Ps.: Serveradministration ist in der Regel mehr Aufwand, als nur einem Tutorial nach einen Gameserver zu installieren. Da du dich mit root einloggst gehe ich davon aus, dass dir die ein oder andere Grundlage unter Linux fehlt... Du bist in diesem Fall für die Sicherheit des Servers verantwortlich...

Ich gehe mal davon aus, dass das nicht die komplette Ausgabe war, oder?

Du musst leider ein wenig mitarbeiten, wenn ich dir schon versuche zu helfen

Ja das macht auch Sinn, da die Fehlermeldung auf einen fehlenden Authkey hinweist...

Was sagt denn df -h ?

Wir wollen deinen Key ja auch nicht sehen, aber testweise könntest du ihn doch in die Start-Datei einfügen und einfach testen, oder?
Zumindest einfacher, als jetzt erstmal Windows inkl. dem SRCDS zu installieren...

Ich glaube die Fehlermeldung LAN only deutet darauf hin, dass etwas mit dem Authkey nicht stimmt. Bitte packe diesen direkt in den Aufruf, also in die start-Datei hinter -authkey und nicht in irgendeine andere Config-File

Dann mach doch bitte mal in dem entsprechenden Ordner
cat startttt

und poste uns den Output hier ins Forum

Zitat von Dragon93

Guten Tag ,
ich habe seit Tagen ein problehm was oft mir angezeigt wird und nicht weiter weiß.Er ladt aauch workshop ,doch nach ner zeit hat er kein bock glaub ab 180 passiert das von 202 .

startet per putty mein ttt server und dann kommt das am Anfang .

[...]

Kannst du dein Problem bitte nochmal genauer beschreiben? Ich kann leider mit der Aussage noch nicht so viel anfangen
Bitte zeige uns auch den Befehl, mit dem du den Gameserver starten möchtest.

Vielen Dank an das Netcup-Team!
Bei mir hat nun auch alles geklappt - Container wurde vom Support auf 500GB vergrößert, OpenBSD liess sich ohne Probleme installieren.

So muss das sein!

Vielen Dank für die Klarstellung. Ist es denn dann eher sinnlos, das im Thread beschriebene Prozedere erneut auszurobieren und dann ggf. wieder eine 8 GB Partition zu erhalten? Wenn ich das mache würde ich nämlich ungern den Support mehrmals damit belasten. Wenn ihr einen ungefähren ETA habt, ab wann das Image wieder sicher zu verwenden ist könnte ich auch ggf. damit noch warten.
Gibt es vielleicht von Netcup irgendwelche Ideen, warum OpenBSD nicht direkt gelaufen ist? Gibt es die Möglichkeit auf virtio-block zu wechseln?

Das Problem hatte ich ja auch, habe beim ersten Versuch mit dem FreeBSD Image "complete disc" ausgewählt und dann auch nur eine 8GB große Platte im VCP angezeigt bekommen. Danach habe ich es noch einmal mit der anderen Option versucht und auch andere Betriebssysteme, die 8GB haben sich dann entsprechend nichtmehr verändert. Wenn du jetzt aber OpenBSD noch am Laufen hast und dir 500GB im VCP angezeigt werden denke ich besteht die Möglichkeit, dass du die Partition einfach vergrößern kannst.
Das müsste entsprechend mit fdisk -e sd0 und disklabel möglich sein, dort Anpassungen vorzuneh

Welches OS hast du denn jetzt aktuell auf dem Root Server 2000 Plus? Kannst du entsprechend die Partition vergrößern?

Zitat von echi

KB19
Danke für den Tipp - habe den Support angeschrieben
Ich habe 500GB bestellt. Ein anderer Server wird auch mit 8GB statt (120GB) angezeigt.

Habe ebenso 500GB bestellt. Wenn ich nun wieder ein Netcup Image nach der OpenBSD Installation einspielen will, bekomme ich den gleichen Fehler wie echi.
Ich werde nun einmal abwarten, welche Antwort echi erhält und dann entsprechend auch den Support kontaktieren.

gparted sagt folgendes:
Frubar FruPic - Picture Upload

leider zeigt dmesg nicht allzuviel an

[4.373308]  vda: vda1 vda2 vda3

Zitat von echi

Was ich grad gesehen habe: meine HDD wird im VCP mit nur 8GB angezeigt. Und nur die 8GB wurden auch partitioniert. Fällt mir erst jetzt auf, da ich die Installation ganz schnell durchgeklickt habe (und "use whole disk").

Selbiges bei mir, disklabel zeigt folgendes:
Frubar FruPic - Picture Upload

Edit: Kann in fdisk die Partition nicht weiter vergrößern, irgendwie geht er da wie das VCP von nur 8 GB aus..

Nun ist nur die Frage, ob es an deiner Supportanfrage, der Reihenfolge der Installation oder sonstigem gelegen hat.

Wie bist du genau vorgegangen? Hast du GPT oder MBR gewählt? Auto Konfiguration der Partitionsgrößen?

Edit: Lustig, ich habe es nun genauso gemacht wie du vorhin und bei mir hat es auch geklappt !
Vielen Dank für den Hinweis