Artwork

Inhalt bereitgestellt von Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen. Alle Podcast-Inhalte, einschließlich Episoden, Grafiken und Podcast-Beschreibungen, werden direkt von Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen oder seinem Podcast-Plattformpartner hochgeladen und bereitgestellt. Wenn Sie glauben, dass jemand Ihr urheberrechtlich geschütztes Werk ohne Ihre Erlaubnis nutzt, können Sie dem hier beschriebenen Verfahren folgen https://de.player.fm/legal.
Player FM - Podcast-App
Gehen Sie mit der App Player FM offline!

GST030 - Turnschuhadministration

2:03:22
 
Teilen
 

Manage episode 230257837 series 2497287
Inhalt bereitgestellt von Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen. Alle Podcast-Inhalte, einschließlich Episoden, Grafiken und Podcast-Beschreibungen, werden direkt von Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen oder seinem Podcast-Plattformpartner hochgeladen und bereitgestellt. Wenn Sie glauben, dass jemand Ihr urheberrechtlich geschütztes Werk ohne Ihre Erlaubnis nutzt, können Sie dem hier beschriebenen Verfahren folgen https://de.player.fm/legal.
Wir sprachen mit Essy (@casheeew) über das spannende Dasein einer Administratorinnen

Unser Gast (00:00:00)

  • Essy podcastet sonst bei der Nerdkunde: http://nerdkun.de
  • Hat mal "Bindestrichinformatik" studiert und macht nun ihren berufsbegleitenden Master an der FH-Köln
  • Weiterempfehlungsgrad von WebScience: Kommt drauf an was man möchte ;-)

Deployment über Netzwerkfreigabe (00:10:44)

  • In GST029 (http://geekstammtisch.de/#GST029) haben wir über Java-Entwicklung und Betrieb gesprochen, dabei viel der Begriff JBoss
  • Und Essy setzt sich beruflich mit dem Betrieb von Anwendungen auf dem JBoss auseinander
  • Essy arbeitet bei einem großen Rechenzentrum in Köln
  • Betrieben werden dort die unterschiedlichsten Anwendungen (vor allem auch große Anwendungen mit vielen Abhängigkeiten)
  • Herausforderungen: Leben mit komplexeren Prozessen als bei einem Fancy-Web-Startup™
  • Deployment für den JBoss läuft zum Beispiel so ab:
    • Kunde legt Auszug aus seinem JBoss inkl. aller Konfigurationen auf einer Netzwerkfreigabe ab
    • Essy sucht Änderungen zwischen altem und neuem Stand heraus
    • Änderungen werden auf allen Systemen eingespielt
  • Klingt umständlich und ist es auch, daher der Plan: Verwendung von Puppet: http://puppetlabs.com/
  • Trotz der Strukturen und Prozesse ist es Essy und ihren Kollegen überlassen welche Tools intern verwendet werden, solange das Ergebnis am Ende passt
  • Warum mit Puppet? Die nächste Version des Red Hat Enterprise Satellite Server (http://de.redhat.com/products/enterprise-linux/satellite/) setzt auf Puppet auf, daher war hier der Wunsch Puppet auch für weitere Bereiche einzusetzen

Server, Monitoring & Bereitschaft (00:26:00)

  • Essy verantwortet den vollständigen Server
  • Die Maschine wird lediglich von einem anderen Team bereitgestellt und übergeben
  • Neben Maschinen für Kunden gibt es auch Maschinen für Forschung & Entwicklung
  • Basis-Monitoring (Erreichbarkeit, Plattenfüllstand, etc) kommt mit dem Server mit
  • Weiteres Monitoring lässt sich dann hinzufügen
  • Monitoring läuft über Icinga (https://www.icinga.org/), einem Nagios (http://www.nagios.org/) Ableger
  • Es gibt natürlich auch eine 24x7 Bereitschaft (in der nicht alle Server enthalten sind)
  • Folge ist: Systeme werden so redundant und solide aufgesetzt, dass man Nachts nicht angerufen wird
  • Das bedeutet auch, dass man Bereitschaft für Systeme machen muss, die man in der Regel nicht selbst betreut
  • Dafür existiert dann entsprechende Dokumentation, die regelmäßig kontrolliert und auditiert wird

Softwarelandschaft (00:35:48)

  • Unterschiedlichste Versionsstände von (beispielsweise) Java (von alt bis ganz neu)
  • JBoss wird nicht in der Community-Variante verwendet, sondern in der kommerziell unterstützten
  • Die Open-Source Variante wird auch nicht mehr JBoss heißen, sondern WildFly (https://github.com/wildfly/wildfly)
  • Kostet nicht unerheblich, aber weniger im Vergleich zu anderen Produkten
  • Support lohnt sich und wurde von Essy auch immer mal wieder in Anspruch genommen
  • Als Dienstleister hat mal im Grunde keine andere Wahl als den kommerziellen Support sowohl von Red Hat Linux als auch JBoss zu nehmen
  • Aus diesem Grund wird Ruby 1.8.7 auch immer noch von Red Hat gepflegt
  • Was dann natürlich zu anderen Problemen führt ^^

Virtualisierung (00:40:40)

  • Ein Großteil der Server laufen auf VMWare ESX Virtualisierung:
    • Der ESX-Hypervisor läuft direkt auf dem Server ohne weiteres Betriebssytem (https://en.wikipedia.org/wiki/VMware_ESX)
    • VMware (http://www.vmware.com/de)
    • VMware vSphere (http://www.vmware.com/de/products/vsphere)
    • VMware vCenter zum Verwalten/Clustern von mehreren VMware ESX Servern mit DRS (Dynamic Resource Scheduling) und HA (High Availability)(http://www.vmware.com/de/products/vcenter-server)
  • Einige Dinge machen virtualisiert einfach keinen Sinn (manchmal auch aus Lizenzgründen…)
  • Virtualisierung ist auf diesem Niveau schon sehr spaßig: Einfach mal laufende Server per Mausklick auf andere Hardware ziehen
  • Für ein Rechenzentrum extrem sinnvoll

Prozesszertifizierung, Support und Monitoring der Kaffeemaschinen (00:44:35)

  • Zertifizierung ist für einen Betreiber eines Rechenzentrums sehr wichtig
  • Die ISO in diesem Fall ist die 27001 (http://de.wikipedia.org/wiki/ISO/IEC_27001)
  • In diesem Zuge werden vor allem organisatorische Aspekte geprüft
  • Neben der Dokumentation der Prozesse werden aber auch Gespräche mit Mitarbeitern geführt und exemplarisch Server betrachtet
  • Das Audit findet jährlich statt
  • Pentesting (http://de.wikipedia.org/wiki/Penetrationstest_(Informatik)) ist nicht Teil der Zertifizierung
  • Glücklicherweise keine PCI Zertifizierung (http://de.wikipedia.org/wiki/PaymentCardIndustryDataSecurity_Standard)
  • Bei der Vielzahl von Kunden und Projekten lassen sich umfangreiche Prozesse am Ende aber nicht vermeiden
  • Das Maximum an Projekten, die man so übernimmt varriert und hängt von der Komplexität der jeweiligen Projekte ab
  • Essy macht glücklicherweise kaum bis keinen Support (:
  • Der Rest des Teams macht aber durchaus auch mehr 2nd-Level Support
  • 2nd-Level Support hat keinen unmittelbaren Kontakt mit dem Kunden
  • Inhouse Servicecenter für den First Level Support, wenn das nicht reicht, landen die Tickets im Team im Second Level Support
  • Ärzte schrauben ganz gerne mal selbst an PCs rum und mailen an alle über den Mailverteiler
  • Basti hat mal in einer Firma die Druckerlandschaft mitkonfiguriert, globales Auslesen von über SNMP von Tonerfüllständen mit Abgleich auf den Lagerbestand und ggf. direkte automatisierte Bestellung beim Händler
  • Drucker sind natürlich auch im Icinga ;-) Telefone allerdings nicht mehr
  • Icinga hört immer dort auf, wo es spezialisierte Tools der jeweilgen Produkte gibt
    • JBoss Operation Network (http://de.redhat.com/products/jbossenterprisemiddleware/operations-network/)
  • Ungelöstes Problem: Monitoring und Alerting der Kaffeemaschinen

K-Fälle (01:02:35)

  • K-Fälle wie Katastrophenfälle
  • Redundanz bedeutet in diesem Fall auch, dass ein Rechenzentrum wegbrechen kann
  • Für diesen Fall werden unterschiedliche Szenarien durchgespielt, um Lücken im System zu entdecken
  • ESX-Cluster werden inkl. Storage zwischen den Rechenzentren gespiegelt und im Hot-Standby gehalten
  • Dafür braucht man dann allerdings auch entsprechend Bandbreite
  • Wir vermuten, dass Darkfibers in Köln zu bekommen kein Problem sein sollten
  • Diese hohe Ausfallsicherheit lohnt sich erst für Projekte/System ab einem gewissen Grad, vorher macht es finanziell einfach keinen Sinn
  • Finanziell bedeutet in diesem Fall weniger Hardware, sondern vor allem Personal, Organisation und Prozess
  • Resultat ist in jedem Fall die Einbüßung von Flexibilität
  • Hohe Anhängigkeiten zwischen verschiedenen Teams

Deployment, Koordination (01:10:30)

  • Produktmanager koordinieren zwischen Kunde, externer Entwicklung und Infrastruktur
  • Es gibt komplexe Abhängigkeiten zwischen verschiedenen System (sowohl in Hard- als auch Software)
  • Zero-Downtime Deployments werden angestrebt, aber sind nicht immer möglich
  • Vor Deployments: Wöchentliche Meetings von Teams zur Koordination

Tooling (01:16:00)

  • Excel ist ein wichtiges Werkzeug hust, soll aber langsam abgelöst werden
  • Confluence ist seit neustem im Einsatz (https://www.atlassian.com/de/software/confluence)
  • OwnCloud (http://owncloud.org/) ist auch hinzugekommen

git, Gitlab, Stash, Github Enterprise (01:18:35)

Administration und Automatisierung (01:25:00)

  • Turnschuh-Administration: Monkey see, Monkey do!
  • Automatisierung ist nicht for-free und ein anhaltender Prozess
  • "Läuft's noch oder automatisierst du schon?" (@bascht)

Backups (01:28:20)

  • Regelmäßig machen, lang genug aufbewahren UND
  • Restore testen!
  • Bei Essys Arbeitgeber gibt es dazu ein dediziertes Backup Team
  • von VMs werden Snapshots erstellt und gesichert
  • Restore ist ein Informationssicherheitsvorfall

Chaos Monkey (01:32:20)

  • Wir fragen Essy, was mit dem Testen von Infrastruktur ist
  • Chaos Monkey bei Netflix (http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html)
  • Essy sagt, das sei im VMware Land (auch) möglich

IPv6 (01:38:05)

Verschiedenes (01:38:30)

Telearbeit (01:45:00)

  • Essy hat einen (Windows) Arbeitsrechner und darf mit ihrem Mac Book nicht ins Firmennetz
  • WPA2: https://en.wikipedia.org/wiki/Wi-FiProtectedAccess
  • Remote Zugang via Citrix, dann via Remote Desktop (RDP) zum Arbeitsrechner und von da aus zu den Servern
  • Problem dabei: Keyboard Shortcuts funktionieren wegen dem hin- und hermapping nicht so richtig
  • Essy kann Heimarbeit machen, sofern es keine Notwendigkeit gibt, Vorort zu arbeiten

Homesetup (01:53:55)

  • Essy hat drei Displays (sowohl zuhause als auch auf der Arbeit) und sich kürzlich neue Hardware für einen Desktop Rechner gekauft
  • Dirk und Basti haben schon EWIG keinen Rechner mehr komplett aus Einzelteilen gebaut

Abschluß (01:59:15)

  continue reading

Kapitel

1. Unser Gast (00:00:00)

2. Deployment über Netzwerkfreigabe (00:10:44)

3. Server, Monitoring & Bereitschaft (00:26:00)

4. Softwarelandschaft (00:35:48)

5. Virtualisierung (00:40:40)

6. Prozesszertifizierung, Support und Monitoring der Kaffeemaschinen (00:44:35)

7. K-Fälle (01:02:35)

8. Deployment, Koordination (01:10:30)

9. Tooling (01:16:00)

10. git, Gitlab, Stash, Github Enterprise (01:18:35)

11. Administration und Automatisierung (01:25:00)

12. Backups (01:28:20)

13. Chaos Monkey (01:32:20)

14. IPv6 (01:38:05)

15. Verschiedenes (01:38:30)

16. Telearbeit (01:45:00)

17. Homesetup (01:53:55)

18. Abschluß (01:59:15)

42 Episoden

Artwork
iconTeilen
 
Manage episode 230257837 series 2497287
Inhalt bereitgestellt von Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen. Alle Podcast-Inhalte, einschließlich Episoden, Grafiken und Podcast-Beschreibungen, werden direkt von Dirk Breuer, Sebastian Cohnen, Dirk Breuer, and Sebastian Cohnen oder seinem Podcast-Plattformpartner hochgeladen und bereitgestellt. Wenn Sie glauben, dass jemand Ihr urheberrechtlich geschütztes Werk ohne Ihre Erlaubnis nutzt, können Sie dem hier beschriebenen Verfahren folgen https://de.player.fm/legal.
Wir sprachen mit Essy (@casheeew) über das spannende Dasein einer Administratorinnen

Unser Gast (00:00:00)

  • Essy podcastet sonst bei der Nerdkunde: http://nerdkun.de
  • Hat mal "Bindestrichinformatik" studiert und macht nun ihren berufsbegleitenden Master an der FH-Köln
  • Weiterempfehlungsgrad von WebScience: Kommt drauf an was man möchte ;-)

Deployment über Netzwerkfreigabe (00:10:44)

  • In GST029 (http://geekstammtisch.de/#GST029) haben wir über Java-Entwicklung und Betrieb gesprochen, dabei viel der Begriff JBoss
  • Und Essy setzt sich beruflich mit dem Betrieb von Anwendungen auf dem JBoss auseinander
  • Essy arbeitet bei einem großen Rechenzentrum in Köln
  • Betrieben werden dort die unterschiedlichsten Anwendungen (vor allem auch große Anwendungen mit vielen Abhängigkeiten)
  • Herausforderungen: Leben mit komplexeren Prozessen als bei einem Fancy-Web-Startup™
  • Deployment für den JBoss läuft zum Beispiel so ab:
    • Kunde legt Auszug aus seinem JBoss inkl. aller Konfigurationen auf einer Netzwerkfreigabe ab
    • Essy sucht Änderungen zwischen altem und neuem Stand heraus
    • Änderungen werden auf allen Systemen eingespielt
  • Klingt umständlich und ist es auch, daher der Plan: Verwendung von Puppet: http://puppetlabs.com/
  • Trotz der Strukturen und Prozesse ist es Essy und ihren Kollegen überlassen welche Tools intern verwendet werden, solange das Ergebnis am Ende passt
  • Warum mit Puppet? Die nächste Version des Red Hat Enterprise Satellite Server (http://de.redhat.com/products/enterprise-linux/satellite/) setzt auf Puppet auf, daher war hier der Wunsch Puppet auch für weitere Bereiche einzusetzen

Server, Monitoring & Bereitschaft (00:26:00)

  • Essy verantwortet den vollständigen Server
  • Die Maschine wird lediglich von einem anderen Team bereitgestellt und übergeben
  • Neben Maschinen für Kunden gibt es auch Maschinen für Forschung & Entwicklung
  • Basis-Monitoring (Erreichbarkeit, Plattenfüllstand, etc) kommt mit dem Server mit
  • Weiteres Monitoring lässt sich dann hinzufügen
  • Monitoring läuft über Icinga (https://www.icinga.org/), einem Nagios (http://www.nagios.org/) Ableger
  • Es gibt natürlich auch eine 24x7 Bereitschaft (in der nicht alle Server enthalten sind)
  • Folge ist: Systeme werden so redundant und solide aufgesetzt, dass man Nachts nicht angerufen wird
  • Das bedeutet auch, dass man Bereitschaft für Systeme machen muss, die man in der Regel nicht selbst betreut
  • Dafür existiert dann entsprechende Dokumentation, die regelmäßig kontrolliert und auditiert wird

Softwarelandschaft (00:35:48)

  • Unterschiedlichste Versionsstände von (beispielsweise) Java (von alt bis ganz neu)
  • JBoss wird nicht in der Community-Variante verwendet, sondern in der kommerziell unterstützten
  • Die Open-Source Variante wird auch nicht mehr JBoss heißen, sondern WildFly (https://github.com/wildfly/wildfly)
  • Kostet nicht unerheblich, aber weniger im Vergleich zu anderen Produkten
  • Support lohnt sich und wurde von Essy auch immer mal wieder in Anspruch genommen
  • Als Dienstleister hat mal im Grunde keine andere Wahl als den kommerziellen Support sowohl von Red Hat Linux als auch JBoss zu nehmen
  • Aus diesem Grund wird Ruby 1.8.7 auch immer noch von Red Hat gepflegt
  • Was dann natürlich zu anderen Problemen führt ^^

Virtualisierung (00:40:40)

  • Ein Großteil der Server laufen auf VMWare ESX Virtualisierung:
    • Der ESX-Hypervisor läuft direkt auf dem Server ohne weiteres Betriebssytem (https://en.wikipedia.org/wiki/VMware_ESX)
    • VMware (http://www.vmware.com/de)
    • VMware vSphere (http://www.vmware.com/de/products/vsphere)
    • VMware vCenter zum Verwalten/Clustern von mehreren VMware ESX Servern mit DRS (Dynamic Resource Scheduling) und HA (High Availability)(http://www.vmware.com/de/products/vcenter-server)
  • Einige Dinge machen virtualisiert einfach keinen Sinn (manchmal auch aus Lizenzgründen…)
  • Virtualisierung ist auf diesem Niveau schon sehr spaßig: Einfach mal laufende Server per Mausklick auf andere Hardware ziehen
  • Für ein Rechenzentrum extrem sinnvoll

Prozesszertifizierung, Support und Monitoring der Kaffeemaschinen (00:44:35)

  • Zertifizierung ist für einen Betreiber eines Rechenzentrums sehr wichtig
  • Die ISO in diesem Fall ist die 27001 (http://de.wikipedia.org/wiki/ISO/IEC_27001)
  • In diesem Zuge werden vor allem organisatorische Aspekte geprüft
  • Neben der Dokumentation der Prozesse werden aber auch Gespräche mit Mitarbeitern geführt und exemplarisch Server betrachtet
  • Das Audit findet jährlich statt
  • Pentesting (http://de.wikipedia.org/wiki/Penetrationstest_(Informatik)) ist nicht Teil der Zertifizierung
  • Glücklicherweise keine PCI Zertifizierung (http://de.wikipedia.org/wiki/PaymentCardIndustryDataSecurity_Standard)
  • Bei der Vielzahl von Kunden und Projekten lassen sich umfangreiche Prozesse am Ende aber nicht vermeiden
  • Das Maximum an Projekten, die man so übernimmt varriert und hängt von der Komplexität der jeweiligen Projekte ab
  • Essy macht glücklicherweise kaum bis keinen Support (:
  • Der Rest des Teams macht aber durchaus auch mehr 2nd-Level Support
  • 2nd-Level Support hat keinen unmittelbaren Kontakt mit dem Kunden
  • Inhouse Servicecenter für den First Level Support, wenn das nicht reicht, landen die Tickets im Team im Second Level Support
  • Ärzte schrauben ganz gerne mal selbst an PCs rum und mailen an alle über den Mailverteiler
  • Basti hat mal in einer Firma die Druckerlandschaft mitkonfiguriert, globales Auslesen von über SNMP von Tonerfüllständen mit Abgleich auf den Lagerbestand und ggf. direkte automatisierte Bestellung beim Händler
  • Drucker sind natürlich auch im Icinga ;-) Telefone allerdings nicht mehr
  • Icinga hört immer dort auf, wo es spezialisierte Tools der jeweilgen Produkte gibt
    • JBoss Operation Network (http://de.redhat.com/products/jbossenterprisemiddleware/operations-network/)
  • Ungelöstes Problem: Monitoring und Alerting der Kaffeemaschinen

K-Fälle (01:02:35)

  • K-Fälle wie Katastrophenfälle
  • Redundanz bedeutet in diesem Fall auch, dass ein Rechenzentrum wegbrechen kann
  • Für diesen Fall werden unterschiedliche Szenarien durchgespielt, um Lücken im System zu entdecken
  • ESX-Cluster werden inkl. Storage zwischen den Rechenzentren gespiegelt und im Hot-Standby gehalten
  • Dafür braucht man dann allerdings auch entsprechend Bandbreite
  • Wir vermuten, dass Darkfibers in Köln zu bekommen kein Problem sein sollten
  • Diese hohe Ausfallsicherheit lohnt sich erst für Projekte/System ab einem gewissen Grad, vorher macht es finanziell einfach keinen Sinn
  • Finanziell bedeutet in diesem Fall weniger Hardware, sondern vor allem Personal, Organisation und Prozess
  • Resultat ist in jedem Fall die Einbüßung von Flexibilität
  • Hohe Anhängigkeiten zwischen verschiedenen Teams

Deployment, Koordination (01:10:30)

  • Produktmanager koordinieren zwischen Kunde, externer Entwicklung und Infrastruktur
  • Es gibt komplexe Abhängigkeiten zwischen verschiedenen System (sowohl in Hard- als auch Software)
  • Zero-Downtime Deployments werden angestrebt, aber sind nicht immer möglich
  • Vor Deployments: Wöchentliche Meetings von Teams zur Koordination

Tooling (01:16:00)

  • Excel ist ein wichtiges Werkzeug hust, soll aber langsam abgelöst werden
  • Confluence ist seit neustem im Einsatz (https://www.atlassian.com/de/software/confluence)
  • OwnCloud (http://owncloud.org/) ist auch hinzugekommen

git, Gitlab, Stash, Github Enterprise (01:18:35)

Administration und Automatisierung (01:25:00)

  • Turnschuh-Administration: Monkey see, Monkey do!
  • Automatisierung ist nicht for-free und ein anhaltender Prozess
  • "Läuft's noch oder automatisierst du schon?" (@bascht)

Backups (01:28:20)

  • Regelmäßig machen, lang genug aufbewahren UND
  • Restore testen!
  • Bei Essys Arbeitgeber gibt es dazu ein dediziertes Backup Team
  • von VMs werden Snapshots erstellt und gesichert
  • Restore ist ein Informationssicherheitsvorfall

Chaos Monkey (01:32:20)

  • Wir fragen Essy, was mit dem Testen von Infrastruktur ist
  • Chaos Monkey bei Netflix (http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html)
  • Essy sagt, das sei im VMware Land (auch) möglich

IPv6 (01:38:05)

Verschiedenes (01:38:30)

Telearbeit (01:45:00)

  • Essy hat einen (Windows) Arbeitsrechner und darf mit ihrem Mac Book nicht ins Firmennetz
  • WPA2: https://en.wikipedia.org/wiki/Wi-FiProtectedAccess
  • Remote Zugang via Citrix, dann via Remote Desktop (RDP) zum Arbeitsrechner und von da aus zu den Servern
  • Problem dabei: Keyboard Shortcuts funktionieren wegen dem hin- und hermapping nicht so richtig
  • Essy kann Heimarbeit machen, sofern es keine Notwendigkeit gibt, Vorort zu arbeiten

Homesetup (01:53:55)

  • Essy hat drei Displays (sowohl zuhause als auch auf der Arbeit) und sich kürzlich neue Hardware für einen Desktop Rechner gekauft
  • Dirk und Basti haben schon EWIG keinen Rechner mehr komplett aus Einzelteilen gebaut

Abschluß (01:59:15)

  continue reading

Kapitel

1. Unser Gast (00:00:00)

2. Deployment über Netzwerkfreigabe (00:10:44)

3. Server, Monitoring & Bereitschaft (00:26:00)

4. Softwarelandschaft (00:35:48)

5. Virtualisierung (00:40:40)

6. Prozesszertifizierung, Support und Monitoring der Kaffeemaschinen (00:44:35)

7. K-Fälle (01:02:35)

8. Deployment, Koordination (01:10:30)

9. Tooling (01:16:00)

10. git, Gitlab, Stash, Github Enterprise (01:18:35)

11. Administration und Automatisierung (01:25:00)

12. Backups (01:28:20)

13. Chaos Monkey (01:32:20)

14. IPv6 (01:38:05)

15. Verschiedenes (01:38:30)

16. Telearbeit (01:45:00)

17. Homesetup (01:53:55)

18. Abschluß (01:59:15)

42 Episoden

Alle Folgen

×
 
Loading …

Willkommen auf Player FM!

Player FM scannt gerade das Web nach Podcasts mit hoher Qualität, die du genießen kannst. Es ist die beste Podcast-App und funktioniert auf Android, iPhone und im Web. Melde dich an, um Abos geräteübergreifend zu synchronisieren.

 

Kurzanleitung