Na die Idee dahinter ist doch ganz einfach. Wenn ALLE bei MS sind gibt es das Problem logischerweise nicht mehr... :-/
Beiträge von absence
-
-
Hilft vermutlich nicht viel, aber ein Blick in unseren Mailprozessor zeigt vermehrt solche E-Mails seit etwa 6 Monaten im Spam- oder Virusfilter, aber immer noch verhältnismäßig sporadisch.
Allerdings scheint der jeweils zitierte Verlauf auf gut Glück relativ eindeutig gefälscht zu sein... (Die zitierten Mitarbeiter gibt es teilweise gar nicht, teilweise in der falschen Sprache. Wenn Max Mustermann aus Berlin mit Miranda Muster aus München z.B. auf Spanisch reden ist das ja schon etwas auffällig
Könnte es vllt. auch eine Art "Glückstreffer" sein? -
irgendwas was den download erst mal aufwendig durchnudeln muss und sich für upload-inhalte dagegen nicht weiter interessiert? (Sprich... Firewall/Antivirus?)
Auch mal ein mtr gemacht in beide Richtungen? -
Oh. jetzt hab ich Dich überlesen
Nun, wichtig ist: Der Webserver muss Subdomains können (und eben die benutzten auch kennen).
Als cname "test.domain.de." einzutragen sorgt nur dafür, dass eben statt der IP des (web)servers mitgeteilt wird "schau stattdessen bitte nach, welche IP test.domain.de hat". Das bringt dir ja nichts...
Nimm einfach die IP von "www" und trage einen record für "*" ein mit dieser IP - oder für jede subdomain (z.B. "test") einen IN A-Record auf diese IP
-
naja. Ich bin von der alten Schule (Gib mir Konsole, mehr als das BIOS brauch ich nicht :D) - von daher muss ich zugeben das WCP gar nicht zu kennen
Aber warten wir mal ab was er dazu sagt, so ganz eindeutig finde ich es immerhin nicht was er überhaupt vorhat, also spekulieren wir hier gerade einfach nur fleissig rum... -
vllt willst dir auch varnish (ggf. zusammen mit pound) anschauen.
-
eh... es spricht dagegen dass eine URL nicht nur eine Domain enthält, sondern i.d.R. einen Pfad (z.B. "meinedomain.de/unterseite/index.php") und ich den Verdacht hege, es könnte eine URL-Weiterleitung über DNS erwartet worden sein
Vllt. sollte Tr33 erst mal darstellen was _genau_ er gemacht hat bzw. erreichen will (das finde ich im Eingangspost nicht eindeutig, mich stört aber der Begriff "Unterseiten" da massiv...) -
Interessant. Ich habe seit 10 Jahren nicht eine andere Email als (frei übersetzt) "wir gucken uns das an" bekommen. Und zwar egal für welches Netz
Direkten Kontakt habe ich NIE hinbekommen. Ende vom Lied: Wir haben zum Glück (noch) genügend kleine Netze, aber es nervt einfach nur...
Hab hier Kunden, bei denen das immer im Kreis läuft (über Jahre):
a) Kunde wechselt zu uns, weil MS zu teuer oder siehe d)
b) Kunde beschwert sich nicht allen Email schicken zu können. -> neues NetzSchritt b beliebig oft wiederholen
c) Kunde wechselt zu office365
d) Kunde beschwert sich (bei UNS!) dass sie nicht mehr alle emails BEKOMMENirgendwann Neustart bei a)
Zum Kotzen...
-
Eh... WAS genau hast du gemacht?
Doch nicht etwa eine URL als CNAME eingetragen? -
Idee: RAM und SWAP vllt. komplett voll? Das geht manchmal in die Hose (settings check: oom_killer, swappiness etc...)
-
Aktueller Teamspeakclient läuft nur noch mit Servern ab 3.3.1 oder neuer (aktuell ist Server 3.3.3 glaube ich, oder der kommt jetzt demnächst). Allerdings bekommt man als User eigentlich dann 'ne super eindeutige Fehlermeldung...?
Dann kenne ich noch das Problem dass der ts3server (Linux) auf einigen (nicht allen) Ports zwar gebunden ist und lauscht, aber stumpf nicht mehr antwortet. Neustart hilft. Passiert aber äußerst, äußerst selten, den Grund habe ich in alle den Jarhen noch nicht gefunden.
Aber: Teamspeak ist prinzipbedingt recht empfindlich bei Routenänderungen im Netz oder sehr hohem Packet loss. Da is dann aber stumpf "das Internet" schuld - betrifft aber i.d.R. nicht alle User, sondern z.B. alle t-online-Kunden aus einer bestimmten Region oder sowas.
Der Packet loss ist dazu lediglich ein Indiz, nicht der eigentliche Grund. Aber wo packet loss, da i.d.R. auch lag, und wird der lag zu groß ist "schluss".
UDP-Pakete sind zwar deutlich schneller, aber eben nicht die bevorzugt transportierten Pakete im Netz und die ersten die verworfen werden wenn irgendwo ein Nadelöhr ist... Aber: ICMP Pings i.d.r noch eher, also ist der 9% Packet loss bei einem Ping/Traceroute ein noch schwächeres Indiz. (Aber es ist eines. Packet loss trotzdem immer auch im TS selbst anzeigen lassen) -
Tja, schön war anders.
Etwas mehr Vorlaufzeit hätte ich mir schon gewünscht, von den betroffenen Kunden hatten nur etwa die Hälfte unsere Ankündigung bis dato mitbekommen. Und wir selbst konnten uns auch nicht so schnell umstellen (alle wesentlichen Leute im Urlaub, krank oder beim Kunden) - natürlich ist dann nicht alles einfach wieder gestartet und wir waren über 2h offline.
Ich beantworte jetzt gerade noch die letzten Mails...
(Ich in froh dass nur einer unserer Dedicated hier betroffen war)