Beiträge von Lars-Daniel

    Naja, das ist ja erst mal nicht unbedingt ein Grund per se, für Docker bräuchte man ja auch gar kein Proxmox. Docker direkt auf dem RS/VPS ist halt weniger Overhead und Docker hat eigene Web GUIs, mit denen man gut arbeiten kann.

    Ich kenne viele Leute, die Proxmox nutzen, weil sie eben kein Bock auf Kommandozeile haben und Proxmox von Backup über Netzwerkkonfiguration usw. alles über die Oberfläche ermöglicht. Du installierst es auf ein leeres System und ab da musst du nur noch klicken.


    Docker hat bei mir auf den Systemen übrigens keine Heimat mehr - ich nutze durchgehend Podman. Allerdings habe ich noch nie Docker oder Podman in einen LXC Container geworfen und ich bin mir nicht sicher, ob ich mir da ein Sicherheitsgrab buddle. Stichwort "Docker in Docker", was nie für die Produktion geeignet ist. AFAIK muss man "nesting" und "keyctl" aktivieren. Ein LXC Container ist dadurch kein wirklich isoliertes System, wie eine virtuelle Maschine, und sowohl Podman/Docker als auch LXC nutzen viele Kernel-Funktionen (Namespaces, etc.)... ich bin mir unsicher, ob sich das alles verträgt. Wohlgemerkt sicherheitstechnisch. Dass es funktioniert heißt ja nicht, dass es auch sicher ist.


    Ich erinnere mich auch, dass ich Probleme mit overlay2 hatte... vielleicht geht das ja inzwischen? Aber das ist hier Offtopic. Können wir gerne woanders diskutieren, da es sicher auch andere interessiert? @m_ueberall

    Und jetzt noch mit dem Prozentsatz derer, die beim Empfänger im Spam landeten, oder nie ankamen.

    Oh sorry, das sind bestätigte Klicks. Ich kann nicht mehr zur Anwendung sagen, aber unsere Bouncing-Rate ist extrem gering, da sich die Nutzer für den Dienst anmelden müssen und die Postfächer erreichbar sein müssen. Also diese ~ 250.000 Empfänger*innen sind definitiv erreichbar und haben die Mail auch empfangen (entweder einen Link darin angeklickt oder damit angemeldet oder eine andere Aktion durchgeführt).


    Aufgrund der Art der Anwendung haben wir einen Querschnitt über alle Bevölkerungsbereiche. Gelistet sind nur Privat- keine Firmenadressen. "Sonstige" bzw. "Verschiedene" sind idR. private Domains.

    Man darf übrigens nicht denken, dass man mit einer frischen IP, die noch nie auf der Blacklist war (oder deren Subnet), sofort Erfolg haben könnte.


    Selbst die großen Anbieter müssen Ihre dedizierten IPs "vorwärmen". Amazon SES macht das z.B. auch so: Es werden nicht plötzlich hunderte E-Mails von einer frischen IP versendet, sondern noch und nach wenige. Wenn man da also für 20 Euro im Monat eine IP-Adresse exklusiv mietet, kann man nicht einfach loslegen...

    Mal ein wenig Real-Life-Statistik. Wir versenden viele gewollte E-Mails im Monat. Hier die bisherige Statistik für dieses Jahr (~ 250.000 Empfänger*innen):


    Portal Anteil
    G*ail 29,74%
    *utlook 15,93%
    G*X 15,83%
    W*b.d* 13,38%
    Y*hoo 8,36%
    Verschiedene 5,97%
    T-*nline 3,66%
    A*ple 2,20%
    Vod*fone 1,96%
    Free*et 1,21%
    ru-G*uppe 0,40%
    ION*S 0,37%
    P*steo 0,33%
    m*il.de 0,32%
    *2-online 0,19%
    mailb*x.org 0,10%
    1&* 0,05%

    Die Caches von NGINX und Apache haben zwei gravierende Nachteile: Man kann nicht punktuell purgen (beim kostenpflichtigen NGINX geht das offenbar). Will sagen, wenn ich z.B. nur den Content unter dem Endpoint "example.org/blah" oder eine bestimmte Datei aus dem Cache haben möchte, geht dies nicht...


    Vor Jahren habe ich mal mit lsof & Co. getrackt, wohin Apache meine Datei in den Cache schreibt... aber das war eine Performance-Hölle.

    Nur interessehalber: wieso LXCs und keine Docker Container?

    Weil er Proxmox verwendet - und das unterstützt kein Docker über die Web-GUI und die eigenen Kommandozeilen.

    Allerdings ist LXC seit einiger Zeit über Tools OCI-kompatibel. LXC jetzt aber auch kein Beinbruch, wenn man damit umgehen kann. Vorallem müllt es nicht die Regeln voll, wie Docker es tut :)


    PS: Ich habe übrigens das VT-x-Flag, bezahle dafür, aber kann es nicht nutzen :)

    Was mich sehr enttäuscht ist,

    1. dass die Statusmeldungen erst eine Redaktion überlaufen und nicht in Echtzeit gemeldet werden,
    2. dass nicht mitgeteilt wird, dass bereits daran gearbeitet wird und

    3. dass der Grund nie offengelegt wird.

    Der Fehler trat vor 7 Uhr auf. Da gingen bei mir plötzlich alle möglichen Alarme los (Uptime-Robot usw.), dass meine Dienste nicht erreichbar wären. Ich dachte erst: Ups, irgendwelche Logs wegen Zeitumstellung Amok gelaufen. Nein. Auf dem VPS eingeloggt habe ich bemerkt, dass die Verbindung "nach außen" auf meinen Containern stört war. Ich dachte erst, dass es an mir lag, aber ich habe ja geschlafen.


    Ich wollte also ins SCP einloggen und gucken, ob irgendwas kaputt ist. Statusmeldung und Twitter waren noch leer. SCP-Login ging nicht, als bin ich hier ins Forum, wo ich bereits eine Nachricht gesehen habe.


    Es war definitiv mehr als das SCP gestört, nur offenbar war es das, was die meisten Nutzer*innen bemerkt haben. Ich kann natürlich nachvollziehen, dass ein Unternehmen nicht unbedingt Dritten nach außen offen kommunizieren möchte, wenn irgendwas schief läuft und warum (ein Schelm denkt, dass es mit der Zeitumstellung zusammenhängt). Aber ich finde, dass gegenüber seiner/ihrer/seiner Kundschaft, also mit einem Vertragsverhältnis, intern kommunzieren, was und warum da in die Hose geht.


    Ich fände es also wichtig, dass da direkt ein automatischer Hinweis auf der Statusseite aufpoppt: "SCP gestört", "Juniper Router gestört" oder "Nameserver gestört". Und nicht erst eine Redaktion oder die GF entscheidet, welche Meldung wann dort hinkommt. So scheint es nämlich gewesen zu sein. Eine automatische Meldung zu basteln, die Ausfälle oder Störungen an Systemen meldet, erwarte ich von einem modernen Unternehmen einfach.

    Was helfen "2TB SSD", wenn da nicht mal USB 2.0 Stick Geschwindigkeiten erreicht werden.

    Ja, mir geht's ähnlich. Wir erzeugen Produkte auf dem Server, die dann an die Kunden zum Download angeboten werden können. Es kann halt nicht sein, dass die dann nur mit 8-10 MB/s runterladen.


    Zudem kommen ja noch andere Feature hinzu, die ich aktuelle bei NC bezahle, aber fehlerhaft implementiert sind und der Support aber indirekt sagt: Selbst Schuld, wir werden Ihnen nicht helfen.

    Ich habe auf unserer PBX einfach ein IPSet mit allen "nicht deutschen" IPs aufgesetzt (100% unserer Nutzer*innen haben die IP eines deutschen Providers). SSH und SIP von nicht deutschen IPs geht direkt in den REJECT. Seitdem sind die Angriffsversuche um mehr als 98% gefallen. Es gibt selbst auf dem Mini-VPS keinerlei Performanceeinbrüche oder Verzögerungen.

    An Proxmox stört mich tierisch, dass die auf das "normale" Debian und nicht auf eine LTS-Distribution, von mir aus auch auf Ubuntu LTS setzt. Aufgrund des Enterprise-Supports von Ubuntu hätte man über Jahre Ruhe... Bei Netcup hänge ich wg. des Virtualisierungsbugs (wir haben das Flag noch) auf der alten Proxmox-Version fest, die jetzt EOL ist. Es gibt allerdings keine Firmware-Updates mehr... ich musste mir daher ein Franken-Debian und -kernel bauen.

    Hallo zusammen,


    Offenbar hat unser "RS 8000 G9" derzeit Probleme mit dem Upstream. Ich erreiche von verschiedenen Systemen per HTTP nur maximal 10 MiB/s. Im Vergleich dazu, kann ich von unserem kleinen "VPS 200 G8", mit über 40 MiB/s herunterladen.


    Keine Angst, zuviel Traffik haben wir in den ersten Jahrestagen und im letzten Monat nicht erzeugt. Natürlich habe ich bereits eine Live-CD gestartet und dort NGINX aufgesetzt, um einer möglichen Fehlkonfiguration entgegenzuwirken - allerdings mit dem gleichen Ergebnis. Zwischen NGINX, Apache2 und Caddy gibt es auch keinen Unterschied.


    Ticket an den Support ist schon draußen, aber hat jemand schon ähnliche Erfahrungen gemacht?


    Beste Grüße

    Lars-Daniel

    Die Originale Webseite von Proxmox empfiehlt das nur zu Testzwecken in den Systemanforderungen.

    Sie schreiben Desktop-Virtualisierung. AMD-V & Co. sind in den meisten Consumer-Boards einfach nur dilettantisch implementiert. Virtualisierung und Nesting auf Server-Hardware ist vollkommen üblich, nur es war halt bis Kernel 5.8 für EPYC & Co. buggy.