Das längste Thema

Ja sorry, du bist zu schnell - das hab ich dann auch gesehen. War zuvor davon ausgegangen das wäre die Non-Docker-Methode. Da ich aber keinen Grund sehe es nicht, wie von den Entwicklern vorgesehen, in Docker zu betreiben, war ich nachlässig und habe das überlesen.

die Antwort auf deine Frage wäre dann wohl: Installiere Docker auf dem System, dann ist es ein System auf dem es Docker gibt und du kannst der regulären Anleitung folgen.

Quote from Homwer

eider war der packet maintainer schon ein paar Jahre nicht mehr aktiv…

Das Argument zieht in dem Beispiel ja nicht, wenn der Maintainer derjenige ist der die Software als solche vorantreibt. Denn dann hast du so oder so keine Updates mehr, egal ob Docker oder "nativ", falls die Entwicklung eingestellt wird.

Quote from heavygale

Installiere Docker auf dem System

Sobald Docker für die auf meinen Servern laufenden Betriebssysteme zur Verfügung steht, haben wir da vielleicht eine andere Diskussionsgrundlage. Tut es halt nicht. Also die Kurzfassung ist: Immich will nicht, dass Menschen, die sich etwas besser mit Servern auskennen, es nutzen. Wird vermerkt.

Quote from tuxproject.de

Noch mal meine Frage: Wie installiert man das auf einem Betriebssystem, auf dem es kein Docker gibt?

Es läuft auch auf Kubernetes! Installierbar über ein bereitgestelltes Helm Chart.

So zum Beispiel:

Link

Durchaus ein "Aufriss", aber es geht. Ebenso mit anderen Service wie bspw. Vaultwarden.

Der/die Entwickler entscheiden, wie ihre Dienste bereitgestellt werden.

Bin ich Docker-User und einen Dienst gibt es in der Form nicht...bin ich nicht die Zielgruppe (und vice versa).

Ich denke auch, das jeder seinen Standpunkt mitgeteilt hat und man sich darauf einigt, sich nicht einig zu sein. Absolut legitim, aber (und da stimme ich den anderen zu) "verdockert" sich der Thread jetzt immer mehr

Foren sind manchmal auch die falsche Plattform für gewisse Grundsatzdiskussionen, die wohl in Natura bei einem Bier,Eis oder whatever ganz anders verlaufen würden;-)

Quote from -Manu-

Foren sind manchmal auch die falsche Plattform für gewisse Grundsatzdiskussionen, die wohl in Natura bei einem Bier,Eis oder whatever ganz anders verlaufen würden;-)

Ich trinke nicht mit Dockernutzern.

Das schönste Konstrukt ist doch immernoch Docker-in-Docker

Quote from tuxproject.de

Sobald Docker für die auf meinen Servern laufenden Betriebssysteme zur Verfügung steht, haben wir da vielleicht eine andere Diskussionsgrundlage. Tut es halt nicht. Also die Kurzfassung ist: Immich will nicht, dass Menschen, die sich etwas besser mit Servern auskennen, es nutzen. Wird vermerkt.

We get it: Du bist der allerbeste. BSDs sind das wahre Betriebssystem. Alle anderen die GNU/Linux (Debian, Ubuntu, Gentoo etc. pp) nutzen haben keine Ahnung/Skill Server zu betreiben. Convience Argumente für Docker Akzeptierst du nicht, sondern machst dich darüber lustig. Jeder Software Entwickler der nicht eine riesige Matrix an Betriebssystemen mit jeden Commit über UnitTest und CI testet ist ein schlechter Developer. Aber am wichtigsten ist es natürlich das die Software für dein BSD funktioniert, wenn nicht dann ist es ein schlechter Developer. Bloß keine anderen Herangehensweisen zulassen, ohne diese nicht im selben Atemzug nieder zu machen. Good Job.

Quote from saremox

We get it: Du bist der allerbeste.

Also du gettest es also schon mal nicht, trotzdem danke für den Beitrag.

Quote from saremox

BSDs sind das wahre Betriebssystem.

So einen unglaublich dummen Stuss aus meinem Hinweis, dass Docker bei mir nicht läuft, herauszudestillieren muss man ja auch erst mal schaffen.

Quote from saremox

Alle anderen die GNU/Linux (Debian, Ubuntu, Gentoo etc. pp) nutzen haben keine Ahnung/Skill Server zu betreiben.

Steht wo?

Ach, steht nirgends. Mein Fehler. Also reines Hirngespinst von dir. Ich hoffe, du erwartest nicht, dass ich auf deine völlig aus der Luft gegriffenen Unterstellungen irgendeine inhaltliche Entgegnung folgen lasse.

Quote from saremox

Convience Argumente für Docker Akzeptierst du nicht, sondern machst dich darüber lustig.

Hast du denn auch nur ein einziges Gegenargument für meine ausführliche Begründung, warum Docker bestenfalls überflüssig ist, aufzubieten oder möchtest du es beim virtuellen Ansabbern meiner Person bewenden lassen? Ich frage für die Einschätzung, wie ernst dich irgendjemand hier nehmen sollte.

Quote from saremox

Jeder Software Entwickler der nicht eine riesige Matrix an Betriebssystemen mit jeden Commit über UnitTest und CI testet ist ein schlechter Developer.

Jeder Softwareentwickler, der seinen eigenen Computer für den Nabel der Welt hält, ist ein schlechter Softwareentwickler. Alles Übrige ist ein weiteres Hirngespinst von dir.

Quote from saremox

Aber am wichtigsten ist es natürlich das die Software für dein BSD funktioniert, wenn nicht dann ist es ein schlechter Developer.

Mir ist es völlig scheißegal, ob irgendwelche Internetdödel ihre Software auf "mein BSD" (soso, denn natürlich benutze ich nur BSD...) portieren oder nicht. Ich finde es nur ein bisschen schade, dass "läuft bei mir" ausgerechnet im Netcupforum dasselbe sein sollte wie "also muss es bei dir auch laufen".

Quote from saremox

Bloß keine anderen Herangehensweisen zulassen

Tu' ich. Ist ja nicht meine Herangehensweise. Irritierenderweise muss ich mich deswegen von einem weiteren Internetdödel ("saremox") beschimpfen lassen, wie etepetete, hochnäsig und sonstwie abgehoben es von mir sei, dass ich die Begeisterung für Docker nicht nur nicht teile, sondern es gar wage, sie argumentativ auseinanderzunehmen.

Lass es mich so ausdrücken: Mach mal dein Fenster auf kipp, Kollege.

Der Moderation gemeldet. Es reicht.

Ich denke wir würden alle wieder gerne zum üblichen, zivilisierten Offtopic übergehen.

Quote from TBT

Der Moderation gemeldet.

Danke. Irgendwo ist das Maß auch voll.

Quote from TBT

Ich denke wir würden alle wieder gerne zum üblichen, zivilisierten Offtopic übergehen.

Schade. Ich warte ja immer noch sehnsüchtig auf eine inhaltliche Auseinandersetzung.

Quote from tuxproject.de

Hast du denn auch nur ein einziges Gegenargument für meine ausführliche Begründung, warum Docker bestenfalls überflüssig ist, aufzubieten oder möchtest du es beim virtuellen Ansabbern meiner Person bewenden lassen? Ich frage für die Einschätzung, wie ernst dich irgendjemand hier nehmen sollte.

Sorry ich habe mich nur versucht deinen bisherigen Umgangston gegenüber den anderen Teilnehmern anzunähern.

Quote from tuxproject.de

Übersetzt: "Es löst das 'Problem', dass Entwickler schlechter Software zu faul für Unittests und/oder CI sind."

Gerade in CI Umgebungen sind Container echt Gold wert, da Sie mir erlauben eine System Umgebung reproduzierbar immer wieder neu aufzubauen für meinen Integration Test. Auch kann ich hier dann sehr einfach meinen Unittests gegen x verschiedene RDMS (mariadb, postgresql, mysql etc. pp.) oder andere Dependencies testen. Also spätestens hier zeigt sich eine Starke von Containerisierung. Ja klar dass ganze bekomme ich auch hin indem ich über Ansible/Puppet jedes mal eine VM hochziehe oder ein VM Snapshot boote. Ist hier also auch eine gewisse Frage des, was ist einfacher aufzusetzen mit der jeweiligen CI System Umgebung. Habe ich ein Gitlab mit Gitlab-Ci sind container deutlich einfacher zu handhaben. Benutze ich eine Jenkins Farm die direkt in meine VMWare cluster, VMs für die cI test hochfahren kann, ist evtl das die bessere Wahl.

Quote from tuxproject.de

Übersetzt: "Es stellt eine unnötig komplizierte Infrastruktur bereit, die sich mit weit weniger RAM und Plattenplatz auch mit chroot und shared libraries abbilden ließe."

Siehe oben. Das Szenario ließe sich wahrscheinlich nicht einfach so mal eben 1:1 abbilden. Ja den Punkt kann ich dir geben die Abstraktion mit Docker sorgt durchaus für einen gewissen RAM overhead. Hier muss man abwägen ob die sonstigen Vorteile diesen Nachteil von mehr RAM und Platte weg machen. Hier ist aber die Frage, ob jeder immer die Lust hat die Anwendung in ein Chroot einzusperren. Evtl ist hier das Tooling besser geworden. Aber ich kann mich noch erinnern dass es sehr aufwändig war eine Anwendung im Chroot lauffähig zu bekommen (insbesondere wenn diese sich nicht selbst chrooten kann). Auch Chroot scheint hier nicht die versprochene Sicherheit zu bieten: https://blog.pentesteracademy.…a08df5c28?gi=0aa1fd1ff592

Ich empfinde es als deutlich weniger Aufwand z.b. ein Redis/Mariadb etc. pp. in einen Docker container ohne privilegien laufen zu lassen. In meiner Docker compose / Kubernetes Deployment sind das nur wenige zeilen konfiguration und der Container läuft nicht als root, hat ein Read-Only FS (außer das Directory mit den Daten). Dropt noch vor der Ausführung sämmtliche Capabilities und ich kann durch Network Policies (Kubernetes) ganz genau sagen welche Anwendung überhaupt auf Netzwerkebene zu meinen Redis/Mariadb/Postgres container kommt. Auch kann ich direkt Ausgehend es so blockieren das es nicht möglich ist vom Redis/Mariadb/Postgres überhaupt ins internet zu kommen. Damit habe ich eine sehr feine isolation möglichkeit. Sowas lässt sich bestimmt auf einen System lösen indem man statt tcp socket, unix sockets nimmt und dann über default Dateirechte oder sogar ACL das ganze einschränkt.

Aber spätestens wenn ich sowieso auf mehr als 1 System Skalieren möchte zwecks Ausfallsicherheit und/oder Lastverteilung bringt gerade die Containerisierung in Zusammenspiel mit Kubernetes oder Docker Swarm (bisher nicht getestet, also keine Ahnung wie gut das geht) doch gute Vorteile in der Handhabung der Komplexität. Ja hier verliere ich wieder Effizienz im Sinne von RAM, CPU und Platte. Ist also eine Frage wie viel mich das mehr kostet und wie viel mir meine Zeit wert ist.

Quote from tuxproject.de

Übersetzt: "Container ignorieren Sicherheitspatches des Betriebssystems, aber das macht ja nichts, weil man mit ihnen auf die viel besseren Sicherheitspatches von Drittanbietern angewiesen sein kann." (?)

Also die meisten Container die ich so im Einsatz habe basieren auf Ubuntu, Debian oder Alpine. Manche bestehen sogar einfach nur aus der glibc und einer statisch kompilierten Go Binary. Für die meisten Container kann ich mir sogar das Dockerfile holen und den Container mit einen docker build selber bauen. Natürlich muss man hier sein Patch Management anpassen. Ein einfaches Unattended Upgrade über Apt (Ubuntu / Debian) mit Auto restart um 4 Uhr morgens tut es da dann natürlich nicht mehr. Aber auch da gibt es Lösungen. Man kann hier mit clair die Container scannen lassen welche man im Einsatz hat und bei gefundenen Sicherheitslücken seine Incident Prozesse starten. Falls es ein Update bereits gibt spielt man das auch bei Docker container einfach ein. Falls es kein Update gibt muss man eine andere Mitigation wählen, hier hat man evtl bei Container mehr Werkzeuge zur Verfügung oder man hat wie bereits oben genannt bereits sehr viel hardening betrieben, dass eine Sicherheitslücke gar keine Relevanz hat für das eigene Container Geflecht/System.

Quote from tuxproject.de

Übersetzt: "Container wie Docker erfinden Solaris-Zonen, FreeBSD-Jails und/oder einfaches UNIX-chroot mitsamt loopback device noch mal neu, nur halt schlechter."

Weil Linux das letzte System war, das noch keine mindestens gleichwertige Lösung im Kernel hatte?

Wie gesagt ich bin hier wahrscheinlich nicht aktuell, aber das oben von mir genannte mit CAP DROP, Read-Only FS, Netzwerk Isolation kenne ich so von einen chroot nicht. Evtl können das die FreeBSD-Jails, habe ich aber selber noch nie verwendet. Aber hier Grundsätzlich zu sagen, Docker/Container wäre schlechter als ein einfacher UNIX-chroot ist tatsächlich falsch. Evtl gibt es da tools welche einfach und so convienent wie Docker/Container network namespace einrichten können für einen Prozess der im Chroot läuft. Ob das dann nicht aber eigl schon fast wieder ein Docker/Container mit extra manual steps ist?!

Wir haben jetzt aber auch das Ganze Argument ohne Apparmor / SELinux gemacht. Apparmor könnte ich sowohl auf meinen System verwenden um meine Prozesse nochmal mehr abzusichern, als auch im Container. (Kubernetes hat gerade erst den Support in die Beta graduated). Ich persönlich habe aber bisher noch nicht wirklich Apparmor profiles oder SELinux profiles geschrieben und könnte jetzt nicht mit zuversicht sagen, dass ich in ähnlicher Geschwindigkeit damit eine Software abhärten kann, als ich es aktuell mit meinen defaults Konfigurationen für Kubernetes und/oder docker compose ( docker compose probiere ich mich gerade in meiner Freizeit ) tun kann.

Ich gebe dir vollkommen Recht, dass wenn ich nur 1 Maschine habe, es sehr wahrscheinlich Signifikant weniger Resourcen braucht, als wenn ich den selben Software Stack mit Docker Container aufbaue. Aber der richtige Vorteil von Container kommt meines Erachtens dann zum Vorschein wenn ich n Maschinen habe auf denen ich aufgrund von Lastverteilung und Ausfallsicherheit die Anwendung verteilen möchte, und diese mit Network Namespaces und Cgroups isoliere und dafür sorge, dass diese andere Prozesse, bei Fehlfunktion oder überlast, nicht mit runter reißen können (CPU limits, memory Limits in den cgroups).

Ich kann aber auch Leute verstehen, die einfach nur den Docker container vom nächsten fancy Tool über docker compose deployen wollen und der Traefik terminiert dann das TLS und leitet dann mithilfe der Label am Container automatisch den HTTP traffic zu der neuen fancy node.js/python/ruby Anwendung. Es ist Convienent wenn man neue Software schnell mal ausprobieren möchte oder nur mal für 1-2 Wochen hostet für ein Event oder sonst was und danach wieder ausmacht.

Schade dass solche Diskussionen oftmals derart ausarten. Ich für meinen Teil versuche immer aus beidseitigen Argumenten zu lernen, auch wenn dies manchmal fast ausschließlich nur von einer Seite möglich ist.

Quote from tuxproject.de

Schade. Ich warte ja immer noch sehnsüchtig auf eine inhaltliche Auseinandersetzung.

Wie man in den Serverschrank hineinruft…

Quote from TBT

Ich denke wir würden alle wieder gerne zum üblichen, zivilisierten Offtopic übergehen.

Ich denke wir sind uns alle einig, dass stilles Wasser eindeutig das bessere ist...

Bitte nicht hauen

Quote from Bud

Wie man in den Serverschrank hineinruft…

Boah, lege dich nie mit Serverschränken an. Teilweise können die so scharfkantig sein, ich hatte es schon öfters, dass ich von einem Einsatz zurück oder nach Hause komme und plötzlich sehe wie ich Schnitte an mehreren Stellen habe und es erst gar nicht bemerkt habe.

Ich bin als ITler bei uns der Hauptteil der wenigen Unfallbuch Einträge

Kommt doch einfach beide nächstes Wochenende aufs Event. Dann kann man das doch in Ruhe ausdiskutieren

Guten Morgen - hatte schonmal jemand das Problem, das das TLS Zertifikat des Netcup Webhosting Mailservers abgelaufen ist? :O

openssl s_client -connect mx2e84.netcup.net:25 -starttls smtp

CONNECTED(00000003)

depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL TLS RSA CA G1
verify return:1
depth=0 CN = *.netcup.net
verify error:num=10:certificate has expired
notAfter=Oct  9 23:59:59 2024 GMT
verify return:1
depth=0 CN = *.netcup.net
notAfter=Oct  9 23:59:59 2024 GMT
verify return:1
---
Certificate chain
0 s:CN = *.netcup.net
  i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL TLS RSA CA G1
  a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
  v:NotBefore: Oct 10 00:00:00 2023 GMT; NotAfter: Oct  9 23:59:59 2024 GMT
1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL TLS RSA CA G1
  i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2
  a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
  v:NotBefore: Nov  2 12:24:33 2017 GMT; NotAfter: Nov  2 12:24:33 2027 GMT
2 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2
  i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2
  a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
  v:NotBefore: Aug  1 12:00:00 2013 GMT; NotAfter: Jan 15 12:00:00 2038 GMT
---

Ich hab eben einen Anruf eines Kunden bekommen das outlook ein Zertifikatsfehler hat und auf dem Handy keine Mails ankommen. Hab den Notfallsupport angerufen aber da ging keiner dran..

Edit: Und scheinbar sollte ich dann mal mein Monitoring erweitern und auch den Mailserver hinzufügen

Quote from Marcel2508

hatte schonmal jemand das Problem, das das TLS Zertifikat des Netcup Webhosting Mailservers abgelaufen ist?

Ich meine mich zu erinnern, dass das schon mal hier im Forum erwähnt wurde. Sollte im Normalfall natürlich nicht passieren.

Quote from Marcel2508

Hab den Notfallsupport angerufen aber da ging keiner dran..

Das sollte eigentlich auch nicht passieren. Einfach weiter probieren. Ist für mich ein sehr berechtigter Grund den Notfallsupport anzurufen.

Es ist möglich ein eigenes Zertifikat beim Mailserver zu hinterlegen. Vielleicht wäre das ja eine Alternative für die Zukunft. Dann liegt die Verantwortung für die Zertifikatsaktualisierung aber komplett bei dir.

Vor ein paar Jahren haben wir einen Weihnachtsbaum im Topf gekauft. Dieser ist diesen Sommer leider eingegangen. Daher überlegen wir jetzt was für ein Baum das Wohnzimmer zieren soll.

Die Tendenz geht Richtung Nordmanntanne. Nadelt nicht, riecht gut, hat ein sehr schönes grün.

Wie seht ihr das?

Danke für die Antwort - Hab jetzt jemanden erreicht. Mal schauen..

Bin ganz Froh wenn Netcup sich darum kümmert. Sofern es denn funktioniert.

Leider scheint uptime kuma aktuell keine option zu haben die gültigkeit des TLS Zertifikats zu checken (https://github.com/louislam/uptime-kuma/pull/4806) wie monitored ihr denn sowas?

Ich klinke mich hier einmal ein, da uns in der Moderation mehrere Meldungen zu dem Umgangston erreicht haben.

Wie bereits von einigen Usern erwähnt, möchten wir euch bitten wieder zu einem freundlichen Miteinander zu wechseln.

Sollte es noch Gesprächsbedarf geben, würde ich euch bitten dafür ein eigenes Thema zu erstellen.

Das Einzige, was wir hier als allgemeinen Tipp geben können: Sollte sich jemand einmal im Ton vergreifen, versucht, wenn möglich, nur auf den Inhalt und nicht auf den (vermeintlichen) Ton einzugehen.

Wenn das nicht gelingt, gibt es für jedes Mitglied im Worst Case auch die Möglichkeit, andere Mitglieder zu blockieren, um die Nachrichten des anderen nicht mehr angezeigt zu bekommen.

Quote from Valkyrie

Boah, lege dich nie mit Serverschränken an. Teilweise können die so scharfkantig sein, ich hatte es schon öfters, dass ich von einem Einsatz zurück oder nach Hause komme und plötzlich sehe wie ich Schnitte an mehreren Stellen habe und es erst gar nicht bemerkt habe.

Ich bin als ITler bei uns der Hauptteil der wenigen Unfallbuch Einträge

Vor vielen, vielen Jahren durfte ich mal für einen größeren Echtzeit-Trader ein neues Test-Environment im RZ einbauen. Alleine, weil der Kollege, der das mit mir machen sollte, immer krank wurde, wenn ein RZ-Einsatz auf dem Programm stand. Also stand ich da, mit 18 neu verpackten HP (damals noch nicht HPE) Proliant DL360 G5-Servern. RZ-Arbeiten waren noch nie so mein Lieblingsding, und dieses spezielle Telekom-RZ war nicht nur zu heiß, zu kalt und zu laut, sondern auch noch echt mies beleuchtet. Nach der Hälfte der Server ging die Taschenlampe kaputt, die ich dabei hatte, was auch nicht hilfreich war. Ich hab dann schon gemerkt, dass ich mich paar mal geschnitten hab, aber ich war der Meinung, das ist nicht wild. Beim Verlassen des RZ hat mich die Empfangsdame etwas komisch angeschaut, weil ich nen großen Blutfleck auf dem Hemd hatte, aber das geht schon raus, dachte ich mir.

Am nächsten Tag gegen 11 Uhr ruft mich der Empfang unserer Firma an, die Polizei steht im Haus. Stellt sich raus, ein RZ-Techniker hatte bei einem Kontrollgang in unseren Schränken mehrere Blutspuren auf Servern entdeckt und die Polizei informiert, weil ihm das und mein blutiges Hemd beim Verlassen des RZ spanisch vorgekommen sind. Das ganze konnte schnell aufgeklärt werden, aber seitdem weiß ich ganz genau, dass man so kleine Schnitte und Risse an den Händen nicht unterschätzen darf, was den Blutfluss angeht 😅