!MltTAZHJuQJDVxijSL:matrix.org

Radio (In)Security

22 Members
Diskussionen zu IT-Sicherheit | Podcast unter https://insecurity.radio.fm/12 Servers

Load older messages


Timestamp Message
5 Jan 2020
10:34:14@ddeimeke:bau-ha.usDirk DeimekeIn Containern muss ja nicht das gleiche Userland laufen.
10:36:28@joerg:alea.gnuu.deJörg SommerGenau. Die Freiheit entsteht nur auf Seiten der Entwickler, weil sie sagen, wir bringen alles mit, und packen da fast ein vollständiges OS zusammen. Aber für den Admin entsteht praktisch keine größere Freiheit, weil sie einfach nur eine Box irgendwohin stellen und die mit Strom versorgen müssen.
10:37:46@ddeimeke:bau-ha.usDirk DeimekeUnd patchen
10:38:10@ddeimeke:bau-ha.usDirk DeimekeContainer erlauben ganz andere Deploymentmethoden.
10:38:27@joerg:alea.gnuu.deJörg SommerDie Abstraktion, was die Basis ist, um die Grundvoraussetzungen zu erfüllen, hat sich einfach verschoben. So wie das jetzt auch mit den Application as a Service kommt.
10:38:39@ddeimeke:bau-ha.usDirk DeimekeOS-Betreuung ist Fabrikbetrieb. Doof aber wahr.
10:39:07@ddeimeke:bau-ha.usDirk DeimekeDie Zeit, dass Sysadmins auch Applikationen betreuen, ist lange vorbei.
10:39:14@ddeimeke:bau-ha.usDirk Deimekehttps://speakerdeck.com/ddeimeke/praktische-administration-3
10:40:07@joerg:alea.gnuu.deJörg SommerDas Container etwas anderes ermöglichen, ist verständlich und dass das auch für einen Teil der »Gesellschaft« Vorteile bringt, ist auch so. Aber die Frage für mich ist, ob das im Blick auf das Gesamtsystem so toll ist.
10:42:54@joerg:alea.gnuu.deJörg Sommer
In reply to @ddeimeke:bau-ha.us
OS-Betreuung ist Fabrikbetrieb. Doof aber wahr.
Es gibt auch den Vergleich zur Massentierhaltung: »When one server goes down, it's taken out back, shot, and replaced on the line.«
10:47:00@joerg:alea.gnuu.deJörg SommerAuch in der materiellen Welt ist es ja zu diesem Denken mit abgeschlossenen Systemen gekommen. Der Fernseher ist heute so billig und so stark verschmolzen, dass es dem Eigentümer/Konsumenten gar nicht mehr ermöglicht, ihn in seinem Inneren zu betrachten und zu reparieren, also mit Teilkomponenten zu interagieren. Das Ding wird gekauft, betrieben und dann weggeworfen.
10:50:43@joerg:alea.gnuu.deJörg SommerIch sehe Container auch als solche geschlossenen Boxen an. Im Idealfall bei Sonnenschein und blauem Himmel läuft das für alle Beteiligten angenehm. Aber wenn z.B. der Entwickler/Hersteller seine Software nicht weiterpflegt, sind einem stärker die Hände gebunden, als bei einer reinen Anwendung.
11:07:57@ddeimeke:bau-ha.usDirk Deimeke
In reply to @joerg:alea.gnuu.de
Es gibt auch den Vergleich zur Massentierhaltung: »When one server goes down, it's taken out back, shot, and replaced on the line.«
Das ist so.
11:09:36@ddeimeke:bau-ha.usDirk Deimeke
In reply to @joerg:alea.gnuu.de
Auch in der materiellen Welt ist es ja zu diesem Denken mit abgeschlossenen Systemen gekommen. Der Fernseher ist heute so billig und so stark verschmolzen, dass es dem Eigentümer/Konsumenten gar nicht mehr ermöglicht, ihn in seinem Inneren zu betrachten und zu reparieren, also mit Teilkomponenten zu interagieren. Das Ding wird gekauft, betrieben und dann weggeworfen.
Das ist mit Containern ja gerade das Gegenteil, selbst wenn ein Modul (Container) defekt ist, läuft der Server als Ganzes weiter. Sobald das defekte Modul ausgetauscht wurde, läuft auch die Applikation wieder.
11:12:12@ddeimeke:bau-ha.usDirk Deimeke
In reply to @joerg:alea.gnuu.de
Ich sehe Container auch als solche geschlossenen Boxen an. Im Idealfall bei Sonnenschein und blauem Himmel läuft das für alle Beteiligten angenehm. Aber wenn z.B. der Entwickler/Hersteller seine Software nicht weiterpflegt, sind einem stärker die Hände gebunden, als bei einer reinen Anwendung.
Das ist einfach falsch. Ich kann einen Container komplett auseinander nehmen (Layer für Layer) und haben dann auch die Anwendung vor mir und kann einen neuen Container bauen. Da gibt es keine Unterschiede. Aber anders als bei Anwendungen, die direkt auf dem Basissystem operieren, kompromitiert eine defekte Anwendung nicht das Gesamtsystem. Interessanterweise gab es die gleichen Argumente als virtuelle Maschinen neuen waren.
11:13:16@ddeimeke:bau-ha.usDirk DeimekeDie Herausforderung hier sind unsere unterschiedlichen Sichtweisen. Ich gucke mehr von unten und Du mehr von oben ...
11:22:51@joerg:alea.gnuu.deJörg SommerDass es diese Argumente auch bei VMs gab/gibt, ist klar, es geht um das selbe. Es ist das selbe, wie die Kritik an statisch-gelinkten Anwendungen. Da war es damals auch für die Entwickler bequem, einfach alles in die Anwendung zu packen.
11:30:11@joerg:alea.gnuu.deJörg Sommer
In reply to @ddeimeke:bau-ha.us
Das ist mit Containern ja gerade das Gegenteil, selbst wenn ein Modul (Container) defekt ist, läuft der Server als Ganzes weiter. Sobald das defekte Modul ausgetauscht wurde, läuft auch die Applikation wieder.
Ein Container beinhaltet ja mehr als ein nur das Programm, sondern auch eine gewisse Infrastruktur. Was ist, wenn Teile des Containers Probleme haben und der Entwickler nichts tut? Meine Auffassung ist, dass der Container größer geworden ist als die reine Anwendung und die Entwickler damit den Einflussbereich für den Betrieb der Anwendung zu Ungunsten der Besitzer verschoben hat.
11:43:41@ddeimeke:bau-ha.usDirk Deimeke
In reply to @joerg:alea.gnuu.de
Ein Container beinhaltet ja mehr als ein nur das Programm, sondern auch eine gewisse Infrastruktur. Was ist, wenn Teile des Containers Probleme haben und der Entwickler nichts tut? Meine Auffassung ist, dass der Container größer geworden ist als die reine Anwendung und die Entwickler damit den Einflussbereich für den Betrieb der Anwendung zu Ungunsten der Besitzer verschoben hat.
Was ist denn in einer VM oder einem physischen Server, wenn die Applikation nicht gepflegt wird?
11:44:12@ddeimeke:bau-ha.usDirk DeimekeWir haben noch Applikationen, die Java 1.6 benötigen und nicht weiterentwickelt werden.
11:44:30@ddeimeke:bau-ha.usDirk DeimekeDie hätte ich schon lieber in einem Container.
13:13:43@joerg:alea.gnuu.deJörg SommerDann triffst Du als Admin die Entscheidung, sie in einen Container zu packen. Aus dieser Sicht finde ich Container auch gut und hilfreich, weil man plötzlich ganz anders mit den Ressourcen umgehen kann. So wie man z.B. auch früher schon auf primitive Weise mit chroot Prozesse anders fassen konnten. Da ergreift aber der Admin eine der Möglichkeiten, die ihm geboten werden. Wenn der Entwickler aber sagt »Du hast Container zu machen«, dann ist das wider den Freiheiten der anderen.
13:16:20@ddeimeke:bau-ha.usDirk DeimekeNein, dafür fehlt mir die Zeit. Das muss der Applikationsbetreuer liefern. Wir betreuen mit drei Personen eine hohe dreistellige Anzahl an Servern mit hunderten von Applikationen.
13:16:41@ddeimeke:bau-ha.usDirk DeimekeUnd dann sind wir wieder beim Ursprungsproblem.
13:30:29@y0ho:matrix.orgyoho
In reply to @joerg:alea.gnuu.de
Ich sehe Container auch als solche geschlossenen Boxen an. Im Idealfall bei Sonnenschein und blauem Himmel läuft das für alle Beteiligten angenehm. Aber wenn z.B. der Entwickler/Hersteller seine Software nicht weiterpflegt, sind einem stärker die Hände gebunden, als bei einer reinen Anwendung.
Nein, wenn man den Quellcode hat, kann man ja alles machen. Im Dockerfile steht genau drin, wie die App installiert wird, so dass sie hinterher funktioniert.
Auch kannst du ja in einen Container hineingehen und dann Kommandos ausführen / logs lesen / debuggen.
14:17:06@wolf:schwoon.orgwolfMir gefallen ja richtige VMs besser. Auf Basis von KVM am liebsten
14:23:09@wolf:schwoon.orgwolfWas nicht bedeutet, das ich Docker nicht nutze.. Hab das auf meinem Mietserver. Und da drin ein kleines Ubuntu OS, das ein paar Scripte per cron startet. Allein der Cron muss nach einem Neustart immer wieder von Hand aufgerufen werden. In dem Container läuft ja fast nichts sonst an Prozessen...
6 Jan 2020
18:18:37@mr.blabla:matrix.org@mr.blabla:matrix.org joined the room.
18:28:55@mr.blabla:matrix.org@mr.blabla:matrix.org left the room.
21 Jan 2020
03:16:39@m.andreev:matrix.org@m.andreev:matrix.org joined the room.

There are no newer messages yet.


Back to Room List