Das längste Thema

  • Hecke29 genau das ist auch der Grund, wieso bei mailbox.org quasi keine SPAM-Mails als SPAM markiert durchkommen sondern erst gar nicht angenommen werden;

    Genau, ich bekomme dort bislang keinerlei SPAM und alles wichtige geht ohne Probleme durch.

    Denken ist wie googeln, nur viel krasser ....

    ——

    Alle Beiträge geben nur meine persönliche Meinung wieder und nicht mehr.

  • Wtf? Auf Port 443 läuft bei mir OpenVPN sowie SSH. So kommt man schön durch alle Firewalls durch

    aber nicht durch einen Proxy, oder?

    blockieren von ausgehenden Traffik ohne Proxy ist irgendwie unausgegoren ...:evil:

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • aber nicht durch einen Proxy, oder?

    blockieren von ausgehenden Traffik ohne Proxy ist irgendwie unausgegoren ...

    Dabei kann das Leben mit SSH-Portforwarding und SSH-Socks-Proxy doch so schön sein. Ihr wisst einfach nicht, was gut für Euch ist.

    Telnet auf Port 443 fehlt einfach der gewisse Charme. ;)

  • Nutzt wirklich jemand die Mailkuh für seine Mails? Also auf einer Büchse die 17 (?) Docker Images?


    Ich bin mir noch nicht sicher ob ich erschüttert oder begeistert bin, tendenz geht aber klar zum erschüttert sein.

  • Nutzt wirklich jemand die Mailkuh für seine Mails? Also auf einer Büchse die 17 (?) Docker Images?


    Ich bin mir noch nicht sicher ob ich erschüttert oder begeistert bin, tendenz geht aber klar zum erschüttert sein.

    Ja, ich nutze die Mailkuh auf einem RS 1000 G8 SAS, ... sehe da persönlich auch kein Problem drin. Läuft bei mir hinter nem nginx Reverseproxy bzw. Zertifikate kommen zentral von nem VPS.


    Ob man die Services nun einzeln auf ner Maschine laufen hat, oder als Docker Container, ... macht den Kohl dann auch nicht fett.

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • [..]


    Ob man die Services nun einzeln auf ner Maschine laufen hat, oder als Docker Container, ... macht den Kohl dann auch nicht fett.

    Gerade das sehe ich komplett anders, was auch die Wartbarkeit/Debugging angeht und auch zum Teil Transparenz. Die Idee ist auch richtig von Mailcow solch ein Setup zu vereinfachen aber der Docker Weg der schlimmste der hätte gewählt werden können. Ich sehe da als "gutes" Beispiel z.B. die gitlab-ce Lösung, ein fertiges Paket welches mittels "chef" gewartet und upgedadet wird.


    Muß nur jeder für sich selbst entscheiden, habe mir da ein etwas anderes Mailsetup gebaut, immer mal wieder in den Jahren aber jeweils aus den einzelnen komponenten zusammen gebaut auf einer Kiste.

  • Gerade das sehe ich komplett anders, was auch die Wartbarkeit/Debugging angeht und auch zum Teil Transparenz. Die Idee ist auch richtig von Mailcow solch ein Setup zu vereinfachen aber der Docker Weg der schlimmste der hätte gewählt werden können. Ich sehe da als "gutes" Beispiel z.B. die gitlab-ce Lösung, ein fertiges Paket welches mittels "chef" gewartet und upgedadet wird.


    Muß nur jeder für sich selbst entscheiden, habe mir da ein etwas anderes Mailsetup gebaut, immer mal wieder in den Jahren aber jeweils aus den einzelnen komponenten zusammen gebaut auf einer Kiste.

    Kommt halt auch drauf an, wofür man die Mailkuh nutzt, ich für meinen Teil hab da ca. 30 Mails laufen, die alle geringe Relevanz haben. Hab alles vereinfacht unter einem Dach, mit wenig Aufwand.

    Wirklich wichtige Mails privat und geschäftlich laufen auf unterschiedlichen Groupwares (SOGo, Open-Xchange und MS Exchange) - wofür ich dementsprechend zahle.

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • der Docker Weg der schlimmste der hätte gewählt werden können

    Was Debugging angeht vielleicht. Was die Installation angeht definitiv nicht. Denn Du musst dich als Entwickler nicht um andere Programme kümmern und kannst einfach das bauen, was für Deine Anwendung am besten ist.


    Treibst Du dich auf einem normalen System rum hast Du immer irgendwelche geteilten Abhängigkeiten die einem das Leben schwer machen können.


    Ich bin immer wieder davon überrascht, dass sich gitlab auf einem vorhandenen System mit LAMP Setup installieren lässt ohne das irgendwas explodiert.

  • Was Debugging angeht vielleicht. Was die Installation angeht definitiv nicht. Denn Du musst dich als Entwickler nicht um andere Programme kümmern und kannst einfach das bauen, was für Deine Anwendung am besten ist.


    Treibst Du dich auf einem normalen System rum hast Du immer irgendwelche geteilten Abhängigkeiten die einem das Leben schwer machen können.


    Ich bin immer wieder davon überrascht, dass sich gitlab auf einem vorhandenen System mit LAMP Setup installieren lässt ohne das irgendwas explodiert.

    Das tendiert zu sehr gerade in Richtung Docker vs. kein Docker...ich sehe ein das es für Entwickler Vorteile hat auch wenn man in Richtung Kubernetes schaut, komme eher aus der anderen Richtung, daher leichte vorbehalte. Ist halt dennoch kein one-size-fits-all Lösung, so genug trolling und phrasen von mir dazu. :D

    Nagut, eine Frage noch, welche geteilten Abhängigkeiten z.B.?


    Gitlab hat es sehr elegant gelöst und kommt auch wirklich selten Feuer raus.

  • Nene, nen Docker trolling wollte ich auf keinen Fall starten.

    Finde halt nur, dass es nicht "der schlimmste Weg" sondern "der einfachste Weg für Entwickler" ist. :)

    Nagut, eine Frage noch, welche geteilten Abhängigkeiten z.B.?

    Gitlab hat es sehr elegant gelöst und kommt auch wirklich selten Feuer raus.

    Naja, allein auf apt-Ebene schon ne ganze Menge:

    https://packages.debian.org/stretch/gitlab


    Dazu bringt gitlab ja noch haufenweise Fremd-Software mit die integriert ist. Wie zum Beispiel ne Datenbank (Postgre war das, oder?) Engine und einen eigenen NGINX.


    Ist also definitiv beeindruckend, dass man das einfach so auf einem klassischen Mischmasch System installiert bekommt ohne andere Teile des Systems zu stören.


  • Ah, das konkret meinst du, naja es sollte schon eine eigene Kiste für den Gitlab sein, schon alleine wegen den benötigten offenen Ports 443, 22 etc. dann kleben die anderen Prozesse in /opt an einem "runsvdir". Bissl Logging nach /var/log und voilá:


    Zumindest kommt man da einfacher mit einem Schraubenzieher ran und es wird komplett mit chef von den Entwicklern/Community gewartet und auch aktuell gehalten.

  • Habe gerade festgestellt, dass ein Backport einer neueren Version von curl (aktuell: 7.64.0) auf Ubuntu 16.04[.5] LTS nicht ohne weiteres möglich ist, da libcurl4 hier automatisch HTTP/2 versucht und Repository-Server, welche letzteres "gemeinerweise" auch verstehen und sprechen, apt aus dem Tritt bringen ("The HTTP server sent an invalid reply header"). Eine einfache und insbesondere saubere Möglichkeit (ohne Modifikation von curl/apt), das Problem zu umgehen, sehe ich nicht. (Das ist genau so lustig wie mit GnuPG, welches man unter Ubuntu 16.04 auch nicht ohne Weiteres "auffrischen" kann.) :pinch:

    Ich meine, mich dunkel zu erinnern, dass man apt irgendwie mit wget zusammenarbeiten lassen konnte, aber einen Online-/man-page-Hinweis habe ich nicht gefunden. Durch den Code mag ich mich jetzt nicht durchlesen...

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Habe gerade festgestellt, dass ein Backport einer neueren Version von curl (aktuell: 7.64.0) auf Ubuntu 16.04[.5] LTS nicht ohne weiteres möglich ist, da libcurl4 hier automatisch HTTP/2 versucht und Repository-Server, welche letzteres "gemeinerweise" auch verstehen und sprechen, apt aus dem Tritt bringen ("The HTTP server sent an invalid reply header"). Eine einfache und insbesondere saubere Möglichkeit (ohne Modifikation von curl/apt), das Problem zu umgehen, sehe ich nicht. (Das ist genau so lustig wie mit GnuPG, welches man unter Ubuntu 16.04 auch nicht ohne Weiteres "auffrischen" kann.) :pinch:

    Ich meine, mich dunkel zu erinnern, dass man apt irgendwie mit wget zusammenarbeiten lassen konnte, aber einen Online-/man-page-Hinweis habe ich nicht gefunden. Durch den Code mag ich mich jetzt nicht durchlesen...

    Na dann wird es ja mal Zeit auf eine "anständige" Distribution zu wechseln ;)

  • Habe gerade festgestellt, dass ein Backport einer neueren Version von curl (aktuell: 7.64.0) auf Ubuntu 16.04[.5] LTS nicht ohne weiteres möglich ist, da libcurl4 hier automatisch HTTP/2 versucht und Repository-Server, welche letzteres "gemeinerweise" auch verstehen und sprechen, apt aus dem Tritt bringen ("The HTTP server sent an invalid reply header"). Eine einfache und insbesondere saubere Möglichkeit (ohne Modifikation von curl/apt), das Problem zu umgehen, sehe ich nicht.

    Eine Idee: .curlrc für den root/debian-Nutzer anlegen und darin das Protokoll definieren, klappt nicht?

    https://ec.haxx.se/cmdline-configfile.html


    Zitat aus curl --manual:

    --http1.1

    (HTTP) Tells curl to use HTTP version 1.1.


    This option overrides -0, --http1.0 and --http2. Added in

    7.33.0.

  • aber nicht durch einen Proxy, oder?

    blockieren von ausgehenden Traffik ohne Proxy ist irgendwie unausgegoren ...:evil:

    Doch, auch das ist möglich. Man kann den Proxy einfach in z.B. OpenVPN Client oder PuTTY eintragen. Und wenn der Admin des Netzwerkes ein Spaßvogel ist und meint, Authentifizierung zu benötigen, schaffen kleine Helferlein wie cntlm oder px im Fall der Fälle auch einfach und schnell abhilfe. ;)


    Aber vorsicht, die Mehrheit der Admins bzw. IT Security Truppen sehen derartige Tunnelverbindungen aus Firmennetzwerken heraus äußerst ungern. Sicherheitsrisiko und so... Bei mir auf Arbeit ist sowas jedenfalls verboten. ^^

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Und wenn der Admin des Netzwerkes ein Spaßvogel ist und meint, Authentifizierung zu benötigen

    mit Spaßvogel hat sowas nicht unbedingt etwas zu tun, es gibt ja auch die Mglkt. von personifizierten Inhalten;

    eben weil manches erhöhte Risiken birgt, gibt es das auch nur f. einen eingeschränkten Personenkreis mit gesonderter Anforderung;

    wobei und bei diversen Seiten wird auch zusätzlich SSL-interception gemacht;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)