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.
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.
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 ...
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.
Das sind keine Gigahertz in der Anzeige
Das sind keine Gigahertz in der Anzeige
sondern?
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.
[..]
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.
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.
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.
Alles anzeigenNene, 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.
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á:
run: alertmanager: (pid 30829) 14207s; run: log: (pid 13906) 2432044s
run: gitaly: (pid 30771) 14210s; run: log: (pid 13843) 2432046s
run: gitlab-monitor: (pid 30788) 14209s; run: log: (pid 13868) 2432045s
run: gitlab-workhorse: (pid 30758) 14210s; run: log: (pid 13855) 2432046s
run: logrotate: (pid 30246) 3407s; run: log: (pid 13825) 2432047s
run: nginx: (pid 30849) 14207s; run: log: (pid 13856) 2432046s
run: node-exporter: (pid 30929) 14206s; run: log: (pid 13877) 2432045s
run: postgres-exporter: (pid 30935) 14206s; run: log: (pid 13931) 2432044s
run: postgresql: (pid 13133) 2432214s; run: log: (pid 13848) 2432046s
run: prometheus: (pid 30807) 14209s; run: log: (pid 13884) 2432045s
run: redis: (pid 30560) 14274s; run: log: (pid 13807) 2432047s
run: redis-exporter: (pid 30946) 14205s; run: log: (pid 13869) 2432045s
run: sidekiq: (pid 30953) 14205s; run: log: (pid 13810) 2432047s
run: unicorn: (pid 30960) 14204s; run: log: (pid 13809) 2432047s
Alles anzeigen
Zumindest kommt man da einfacher mit einem Schraubenzieher ran und es wird komplett mit chef von den Entwicklern/Community gewartet und auch aktuell gehalten.
SSH-Socks-Proxy
irgendwie mochte/mag ich die nicht (kann aber keinen Grund nennen). Ein normaler Squid tuts auch, und der läuft eh
gruss
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.)
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...
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.)
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 ...
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.
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;