Ich hoffe Tuvok kümmert sich auch um die Nachbetreuung.
Beiträge von A:H
-
-
Miete dir einfach einen fertigen TS Server wenn du mit der Administration eines Servers nicht vertraut bist?
Oder eigne dir das nötige Wissen an.
-
Paketverluste von 127.0.0.1 auf 127.11.22.33 liegen meist nicht am Netzwerk. Nur als Hinweis.
-
Das Erklären von möglichen Folgen macht bei solchen Leuten keinen Sinn.
-
Versuch das mittels HDD Benchmark / den Performance-Graphen von Windows herauszufinden
-
Sieh dir vielleicht mal die I/O Performance des Systems an. Wenn dein Bot Aussetzer hat obwohl er ebenso lokal auf dem System läuft, kann's nicht das Netzwerk sein.
-
Läuft der Musikbot denn am selben System wie der Teamspeak Server?
-
Servus. Ich möchte nicht deine Entscheidungen in Frage stellen aber dennoch den gut gemeinten Tipp anbringen, einen Mailserver nicht zu clustern. Das macht im kleineren Rahmen in meinen Augen nur für IMAP/POP3 Systeme Sinn und auch nur dann, wenn es sich dabei um kritische Infrastruktur handelt die keine Ausfälle von um die 30 Minuten verkraftet.
Das Clustern von E-Mail Systemen birgt viele Stolpersteine und Gefahren und auf jeden Fall auch eine deutliche Erhöhung des Administrationsaufwands mit sich.
Es kann zu Splitbrain Situationen in der Datenbank kommen, das zweite System kann schlechter Spam filtern weil die Synchronisation der Filterregeln nicht klappt, usw..
Gerade bei Mail, bei der ein Server bis zu 4 Tage unerreichbar sein kann und lt. RFC dennoch alle Mails zugestellt bekommt ist es meines Erachtens nach total sinnlos.
Solltest du deine MX doppelt auslegen kann die Übermittlung zum IMAP Server fehlerhaft sein, was du eventuell nicht mitbekommst weil über den ersten MX eh alles normal reinkommt. Das kann auch rechtlich relevant sein, weil die Mail in dem Fall als zugestellt gilt.
-
Einen VPS mit durchgehend 50% Steal würd ich kündigen, Preis hin oder her, da stimmt dann die Produktbeschreibung nicht und ist irreführend. Wenn er hin und wieder auf 50% ausreißt aber sonst bei 0-10 ist find ich das aber wieder total ok und dem Produkt angemessen.
-
Bitte kündige den Server und bestell dir ein managed System.
-
https://github.com/mailcow/mailcow-dockerized/issues/1439
Aber ich will da jetzt keine weitere Zeit damit verschwenden, bei mir läuft alles andere ja.
Und nein bis jetzt hatte ich nur mit docker im Zusammenhang mit mailcow Probleme und nur deren container haben die Kernel Panik verursacht, meine eigenen nicht. Denn als ich die mailcow container mittels Rettungssystem am auto start gehindert habe, bootete das System wieder.
Mir scheint es als ob mailcow wohl auch die Heilige Kuh einiger Leute hier zu sein scheint... Naja ich wünsch euch noch viel Spaß und möchte auch keine weiteren Tipps zu Mailcow, ist hier auch nicht das Thema.
Ich habe lediglich meine Meinung dazu geäußert.
Sorry, da muss ich noch einmal darauf antworten, ich will das so nicht stehen lassen.
Eine Antwort weiter unten findest du nachfolgendes:ZitatThis also never happens on port 587 and 465. Plus it never sticks the whole website. You are doing something very wrong.

Mailcow hat wie bereits erwähnt keine künstlich erzeugte Verzögerung.
Der Kernel-Panic wurde auch - wie in dem Bugreport zu sehen ist - nicht von Mailcow erzeugt sondern von einem Bug im Ubuntu Kernel.
Mailcow ist nicht der heilige Gral, jedoch sollte man an deiner Stelle keine Software und kein Projekt schlecht reden weil es einen Fehler triggert der im Kernel eines Betriebssystems zu finden ist. Du musst hier klar unterscheiden und auch bei den Fakten bleiben. Das was ich mache ist, deine schrägen Aussagen gerade zu biegen um den Ruf des Projekts zu schützen.
Meinung äußern ist gut, dann bilde dir deine Meinung aber auch aufgrund von Fakten und nicht aufgrund von unverifizierten Beobachtungen und Vermutungen.
-
Du kannst das gerne auch hier nachlesen:
https://bugs.launchpad.net/bugs/1842447
Die Mailcow-Community war mehr oder weniger sogar Entdecker dieses Kernel Bugs.
Da gabs dann bestimmt einen Configfehler deinerseits. Ich kenne das Projekt gut und weiß mit 100%iger Sicherheit, dass da keine künstliche Verzögerung eingebaut ist.
-
Trotz längerer Suche konnte ich nicht herausfinden, wie ich die eingebaute Verzögerung beim Versenden über smtp abschalten kann. Das hat dazu geführt, dass Bestellungen usw. teilweise mehrere Sekunden gedauert haben, weil eben E-Mails versendet wurden.
Dann hat mailcow mein System lahm gelegt, da nach einem Update eine Kernel Panik (mit 4er Kernel) verursacht wurde. Später haben sie dann eine Prüfung in ihrem Update Skript eingebaut und es wurde erst ausgeführt, wenn man einen 5er Kernel verwendet.
Das von dir angesprochene Problem lag nicht an Mailcow sondern am entsprechenden Ubuntu Kernel in Verbindung mit Docker Netzwerken (NAT Fragmentierung).
Achja, auch eine eingebaute Verzögerung gibt‘s nicht.
-
Wie wär’s wenn du deine Webseite von jemanden optimieren lässt der sich damit auskennt und so nachhaltig etwas verbesserst ohne den Server wechseln zu müssen?
1,2MB sind eben 1,2MB. Wenn dein User dafür 4 Sekunden zum Laden braucht wird er durch einen neuen Server nicht plötzlich weniger Zeit benötigen.
Ich bin selbst nebenbei Fotograf und hab auf meiner Webseite keine solchen Probleme, trotz größerer Seiten und ebenso vielen Bildern.
-
Servus, da kann man jetzt nur Rätsel raten. Wie hast du den Umzug der Seite gemacht? Was sagen die Logs? Hast du den vHost richtig konfiguriert?
-
Servus. „Sicherheit durch Geoblocking“ zu erreichen ist meiner Meinung nach komplett der falsche Weg. Eher solltest du darauf achten nur vernünftige Plugins und nicht jeden Müll zu installieren. Zusätzlich dazu solltest du darauf achten, dass deine Software immer aktuell ist, dass du sichere Passwörter verwendest und dass der Server selbst proffessionell gewartet wird (in dem Fall durch netcup bereits erledigt).
Du kannst natürlich auch übertreiben und Web Application Firewall plus Intrusion Detection davor zu schalten, das erachte ich aber eher als unnötig auf kleinen Webseiten. Cloudflare (bietet eine WAF gegen Geld) könntest du dir aber tatsächlich mal ansehen, falls das für dich interessant ist.
-
Hab gerade bei einer meiner neuen Domains nachgesehen. Die MX Einträge sehen dort aus wie im Screenshot zu sehen ist.
-
Ich könnte mich auch täuschen aber denke, dass die Redirect-Setzings bei Namecheap voraussetzen, dass du deren MX Einträge verwendest (sonst könnten sie auch keine Mails empfangen).
Frag mal deine Domain ab ob da MX Einträge hinterlegt sind. Als Beispiel unter Linux:
dig MX example.de
-
Wenn du bereits ein Produkt besitzt und damit verifiziert bist wird das Produkt in der Regel innerhalb von wenigen Minuten (5-30) bereitgestellt.
-
Ist die IP der Bridge zufällig die selbe wie die der VM? H6G hat dir ja eine tolle Anleitung geschrieben. Versuch die mal umzusetzen.
Achja, der Nameserver im Container stimmt sicherlich auch nicht.