Open Source Tools for Network and Automation. Kurz was zu mir. Wer bin ich, was mache ich, warum stehe ich hier? Ich mache eigentlich von Netzwerk über Unix, Linux Server Administration so ziemlich alles. Ich bin Consultant bei der Profi Engineering Systems AG

und verdiene quasi meine Brötchen damit, irgendwie anderen Leuten zu erzählen, wie man anständig Server managt, wie man Netzwerke baut und sowas. So, worum geht's? Open Source Tools. Fangen wir mal mit dem Gegenfall an. Kommerzielle Tools. Wer kennt sie nicht?

Wir haben von euch schon mal so größte Sachen von vorhin in der Hand gehabt, wie Realize Automation oder so. Ist auch schon mal irgendwie benutzt. Das war das, was mir dazu einfällt. Die Tools haben immer alles und wenn ich

was anpassen möchte, ist es schwierig. Das geht meistens nur von einem Hersteller. Das heißt, wenn ich irgendwie mein Cisco Netzwerkmanagement Tool habe, managt das auch nur Cisco Geräte. Oder das HP Netzwerkmanagement Tool managt nur HP Geräte. Oder das Dell OpenManage managt Dell Server. Das heißt, ich hänge immer so auf einem

Hersteller fest. Die Tools sind zwar meistens vom Umfang her recht brauchbar, aber wenn man dann irgendwie doch mal irgendwie das ein oder andere Spezialfeature braucht, heißt es dann meistens, ja, ach nee, also der Aufwand, das lohnt sich alles nicht, da jetzt Entwicklungszeit reinzustecken, weil ihr seid die Einzigen, die das machen wollen.

Stimmt dann zwar meistens nicht. Ja, und diese ganzen Kommerz-Tools laufen alle meistens unter Windows. Ich habe bis jetzt wenig Management-Tools gesehen, die auch unter Linux laufen. Man möge mich verbessern. Ich glaube,

so ein Dell OpenManage läuft irgendwie unter Linux vielleicht noch. Aber das wars dann auch. Oh, lauter? Ah, zu laut. Ja, ein bisschen. Ja, gleich pfeift es. Open Source Tools sind auch nicht das Allheilmittel. Man braucht da schon so ein bisschen

Vorwissen und die Bereitschaft, sich auf sowas einzulassen und einzuarbeiten, wenn man es anpassen will. Das heißt, so grundlegende Administrations-Skills sollten schon vorhanden sein. Hier und wieder brauchen wir auch mal das gute alte Beißholz, wenn man mal in den Source Code guckt, weil Dinge wieder nicht so funktionieren, wie erwartet. Dann sieht es so, oh mein Gott, das hat jemals funktioniert.

Das ist da eine gute Gelegenheit, einen Patch zu schreiben. Ja, also egal, an welcher Seite ich das habe. Ja, warte. Gehen wir das mal hier hin, damit ich es gleich runterreißen kann.

Weintwäsche? Geht besser? Ja, wie gesagt, es gibt manchmal suboptimale Dokumentation, nenne ich das immer. Weil ein Tool kann meistens deutlich mehr jetzt in der Doku steht, weil Dokuschreiben ist immer doof. Und wenn man der Open Source Community so ein

bisschen was zurückgeben will und nicht coden kann, kann man immer noch Doku schreiben. So, das ist dann immer ganz hilfreich. Da freuen die Leute sich, wenn man irgendwie auch mal 20 Zeilen Doku irgendwie contributed, das als Patch Request einschickt. Ja, kurze Geschichte zur Open Source. So bis Ende der 60er war das Gang und Gebe,

dass es Open Source gibt, weil die Software an den Unis entwickelt wurde und man Sachen ausgetauscht hat. In den 70ern fingen dann Firmen plötzlich an, für Software Geld zu verlangen. Wie können sie nur? IBM hat dann auch nicht mehr den Source Code von ihren Bibliotheken

und Programmen mitgeliefert. AT&T wollte plötzlich Geld für Unix haben, was in Berkeley entwickelt wurde, auch in einer Forschungseinrichtung. Und dann geht es so Anfang der 80er geht es wieder los mit Open Source als Richard Stormand und das GNU-Projekt gründet. Anfang der 90er

ging es dann los mit dem ersten Linux-Kernel. Und was Mitte der 90er bei Open Source immer sehr interessant war, der Default war komischerweise immer Solaris. Das heißt, egal was man kompilieren wollte, es lief immer auf Solaris. Man musste es für Linux anpassen

oder für irgendwelche andere Kommerzionixen. Mittlerweile dreht sich das Ganze. Es läuft mittlerweile alles unter Linux und mittlerweile fängt es bald an, dass alles unter Mac OS läuft auf den ganzen BSDs und man für Linux irgendwie hinterher treten muss, weil die ganzen Entwickler irgendwie ihren Mac dastehen haben. Ich bin da auch nicht so eine Ausnahme. Fangen wir

an. Ich würde anfangen mit Monitoring, weil das so eine der wichtigen Sachen ist,

die man im Systembetrieb tun sollte, auch im Netzwerk. Klassiker ist da Icinga 2, so ein Ableger von ehemals Nagios. Icinga 2 hat sich halt deutlich gewandelt. Ich kann mittlerweile so viele Bibliotheken und Sachen einbinden. Ich muss nicht mehr die

Textdateien benutzen, um es zu konfigurieren. Ich kann es mit dem Director auch über die GUI machen. Das kann ich tatsächlich alles schön zusammenklicken. Ich muss mich da nicht mehr in Textdateien verlieren. Dann gibt es LibreNMS. LibreNMS ist auch ein Fork von Observium. Das ist entstanden, weil der damalige Maintainer gesagt hat, wir haben

Open Source, schöne Gute, aber irgendwie muss man ja auch mal Geld verdienen und aktuelle Releases nur noch gegen Geld verkauft hat. So gegen Subscription ist ja eigentlich auch nichts gegen einzuwenden. Aber fing dann halt gleichzeitig an, Contributions nicht mehr anzunehmen. Die stauten sich und irgendwann hat man gesagt, na gut, machen

wir das halt selber. LibreNMS macht ganz viel Netzwerk Monitoring, ganz viel Autodiscovery, wo ich bei Icinga 2 meine Checks teilweise halt noch so selber schreiben muss, was ich auf dem Gerät gecheckt haben will, kann ich mit LibreNMS und Discovery machen.

Also es funktioniert zumindest für Netzwerkgeräte sehr gut, für sage mal normale, Windows, Linux, Hosts, über SNMP geht das auch noch halbwegs. Das ist aber nicht so Kern von dem Ganzen. Was ich bei LibreNMS noch anbinden kann, sind so Sachen wie

Config Monitoring. Das heißt, wenn ich das mit Oxidize zusammen genubbel, zieht es sich regelmäßig die Konfiguration runter. Ich kann das mit Greylock zusammenhängen, um mir die Logfiles meiner Geräte anzeigen zu lassen, alles in einer GUI. Das ist sehr praktisch und ich habe da so ein bisschen Baukasten, das Baukastenprinzip, dass ich ein Tool um weitere erweitern kann. Dann ist im Monitoring momentan sehr beliebt

Prometheus, das eigentlich eine Matrix Storage Engine ist. Prometheus speichert eigentlich hauptsächlich Metriken, scrapt die per HTTP irgendwo ab und kann dann

Regeln dagegen laufen lassen. Und bei Überschreiten irgendwelcher Grenzwerte zum Beispiel, ich kann da so Sachen machen wie, wenn der Festplattenfüllstand in zwei irgendwie in zwei Wochen auf 100 Prozent geht durch eine Holt Winters Vorhersage, dann alarmier mich doch mal. Das ist ein ganz spannender Ansatz für Monitoring,

weil ich halt nicht mehr gucke, wie ist es denn jetzt, sondern ich kann halt gucken, okay, wie war es irgendwie die letzten zwei Wochen und geht der Trend dahin, dass irgendwie morgen meine Festplatte voll ist. Ich will ja alarmiert werden, bevor die Platte voll ist, nicht also wenn sie voll ist. Aber das ist so ein generelles

Monitoring Ding. Dann haben wir die guten alten Klassiker wie MRTG, wer kennt es nicht? Wahrscheinlich nie benutzt. Multirouter Traffic Grafer ist eine Sammlung wild gewordener Pulse Scripts, die per SNMP Daten sammeln und in eine RRD-Tool,

also in eine RRD-Datenbank schieben. RRD müsste ich jetzt noch mal überlegen, was ist das? Frau und Robin Database, genau. Ich habe halt so einen definierten Satz an

der Zeit, die über die Zeit immer unscherfer werden. Das heißt, ich habe für die ersten fünf Stunden oder ersten sechs Stunden eine Minutenauflösung, dann habe ich für eine Woche fünf Minutenauflösung und dann für ein Jahr eine Stundenauflösung zum Beispiel.

Was mir für Traffic Monitoring reicht für manche Dinge, da will ich eine genauere Auflösung haben. Deswegen kommen wir jetzt mal zu so Sachen wie Matrix Storage, weil Dinge, die ich monitore, die erzeugen Daten. Diese Daten will ich auch irgendwo speichern. Ich kann das wie gesagt mit RRD-Tool machen, da bin ich aber auf meine Datenquelle festgesetzt.

Da kann ich nicht einfach sagen, ok vergleich mir doch mal den Stromverbrauch mit der CPU-Last, damit ich weiß irgendwie, was kostet mich so ein Webserver Request eigentlich an Stromverbrauch. Weil wenn ich irgendwie 60 Request-Zisekunde habe und ich weiß ich brauche 200 Watt, kann ich mir den Stromverbrauch für so ein Request ausrechnen. Das kann man mit RRD-Tool zwar

machen, wird dann aber sehr schnell sehr hässlich, weil ich mehrere Datenquellen kombinieren muss. Das können so Dinge wie Graphite zum Beispiel. Graphite hat ein ähnliches Storage-Format wie ein RRD-Tool, also wird auch irgendwann unscherfer, das kann ich konfigurieren. Ich kann aber mehrere Datenserien miteinander verknüpfen,

vergleichen oder auch mit einem Graph holen. Dann haben wir InfluxDB. InfluxDB kann auch Datenserien speichern, da kann ich so ein bisschen wie SQL drauf rummeiern. Das kann ich über das SQL ähnliches abfragen. Gehört zum sogenannten Tickstack, da gibt es halt

Telegraph, der Metriken sammelt, InfluxDB, der das da reinschiebt, Capacitor, der Regeln drauf anwenden kann und Kronos dann eine Alarmierung macht. Sowas ähnliches habe ich auch bei Prometheus, wo ich halt meinen Note-Exporter habe und dann die

Sachen auch in den Alert-Manager schieben kann, der mich auf bestimmte Arten alarmieren kann. Ich kann mir mit dem ganzen Zeug ein sehr gutes Monitoring zusammenbauen. Ich habe plötzlich ein sehr gutes Bild über den Zustand meiner ganzen Systeme, wie es ihnen gestern, vorgestern und so weiterging. Das ist eigentlich, was da sollte man sich so ein bisschen mit

beschäftigen. Gut, wenn ihr Fragen habt, einfach zwischendurch melden. Machen wir mal weiter. Config-Management. Das ist auch ganz spannend.

Auch so ein Ding, was man machen sollte. Du lachst wegen Napalm? Ja, genau. Den ganzen Tools ist eigentlich so gemein. Die sind eigentlich alle in Ruby oder Python geschrieben. Das fängt mit Ansible und Solstack an. Die sind

beide in Python geschrieben. Das heißt, wenn man die erweitern will, sollte man so ein bisschen Python können. Genauso, wenn man etwaige Templates damit baut. Ansible finde ich ganz spannend, weil ich mit einem Zuo-Yaml-Dateien

meine ganze Umgebung beschreiben kann und dann den Zustand meiner Sauer beschreiben kann und dann sagen kann, ok, jetzt machst du mal und ich muss keinen Agent dafür installieren. Bei so Sachen wie Puppet Chef Salt, wie wir gestern gesehen, brauche ich immer einen Minion oder Chef Client oder ein Puppet Agent irgendwo auf dem Rechner. Ansible macht das Ganze

per SSH. Ähnlich wie Sol in SSH. Puppet ist auch ein Automatisierungssystem geschrieben in Ruby oder zumindest sieht die Konfigurationssprache stark nach

Ruby aus. Das ist eine Ruby DSL, Domain Specific Language. Da gebe ich den Zustand meines Systems vor und der Puppet Client versucht, das quasi eben anzupassen. Das heißt, wenn ich sage, ok, auf dem Server muss ein Paket installiert sein, dann wird der Puppet Agent hergehen und das Paket

entsprechend installieren. Macht das ähnlich wie bei Salt, nur dass der dauerhaft läuft. Das heißt, ich kann bei Puppet meine States quasi auf den Puppet Master pushen. Von dem holen sich dann die Agents

regelmäßig ihre Konfiguration und wenden ihre Skripte entsprechend an. So ähnlich funktioniert auch Chef. Ich wüsste jetzt nicht, was zwischen den beiden irgendwo ein Alleinstellungsmerkmal ist, außer es ist Geschmackssache und je nachdem, womit man gerade angefangen hat. Über

Saltstack hat ja der Christian gestern lange gesprochen und dann gibt es ein schönes Tool, das nennt sich Terraform. Terraform beschreibt Infrastructure as Code. Da könnte man nicht fast einen eigenen Talk drüber machen. Aber ich, na ja, sehr gut. Genau. Terraform hat die angenehme

Eigenschaft, ich kann mit fast allen Cloud- und Infrastruktur-Providern reden. Das heißt, ich kann zum Beispiel beschreiben, hey, ich hätte gerne fünf VMs dazu, irgendwie diese VMs sollen diese DNS-Einträge bekommen, sollen so viel Platte und CPU haben und Terraform geht dann

groß und sorgt dafür, dass Dinge so sind, wie sie beschrieben sind. Und wenn ich dann zum Beispiel sage, hey, ich hätte gerne das Ganze bei AWS statt bei Hetzner ausgerollt, dann ändere ich meinen Infrastruktur-Provider und das Ganze läuft bei AWS ohne Fehlhers. Und ich kann vor allen Dingen

Änderungen in meiner Infrastruktur nachvollziehen, weil wer hat denn wann den Server installiert? Kann das einer von euch beantworten, wer wann welchen Server bei euch installiert hat oder wer wann welche virtuell über Schiene warum angelegt hat? Ja genau, es gibt da so

E-Mail-Verteiler. Und Tickets gibt es bestimmt auch, aber es ist doch einfach angenehmer, wenn ich im Editor am Gitlog nachgucken kann, dass der Kollege XY vorgestern die VM-Anzahl von drei auf fünf gedreht hat. Ja, ich weiß.

Ja, Ruby und Python bieten sich generell so für Config-Management an, gerade durch die ganzen Template-Sprachen wie Ginger 2 oder Embedded Ruby. Ein nettes Tool fürs Netzwerk ist eine Python Library namens Napalm. Napalm spricht mit einer ganzen

Handvoll Switches, entweder per SSH, per YANG oder per Netconf, um zum Beispiel Konfigurationen auf die Geräte zu schieben, Konfigurationen darunter zu nuckeln, sich Fakten zu holen, was wie konfiguriert ist. Dann kann man sich eine schöne Automatisierung

zusammenbauen. Muss man allerdings auch bauen, weil das ist dann wirklich Lego-Technik. Das sind die kleinen Klemmbausteine mit den Zähnen dran. So, wir machen ja Netzwerk eigentlich. Network-Management. Ich kann Ansible für mein Network-Management

verwenden. Kommen Sie rein. Ich kann meine Konfigurationen aus Templates zusammenbauen. Das heißt, wenn ich bei jedem Switch oder so immer meinen gleichen Syslog-Server drin

haben möchte, meinen gleichen User drin haben möchte, dann habe ich schon mein erstes Template, was ich da drauf schieben kann. Dann kann ich halt entsprechend weitermachen, irgendwann noch meine Interfaces-Templaten, indem ich mir das als Konfig-Dateien hole und habe damit dann tatsächlich diese gesamte Switch-Konfiguration auch üblicherweise in einem

Git, wo ich dann nachvollziehen kann, wer wann was konfiguriert hat. Und vielleicht sogar, wenn derjenige einständige Commit-Message schreibt, warum. Und wenn es nur die Ticket-Nummer ist. Und ich kann die Konfig vorher testen, ob alles drin ist. Das heißt, ob meine

Konfiguration gewissen Regeln entspricht. Und ich habe halt immer das, hast du auch das VLAN auf dem Port geteckt? Oh, das habe ich vergessen. Das fällt da meistens auch weg. So die üblichen Kleinigkeiten oder je nachdem, was für Einstellungen man auf seinen Edge-Ports hat. Storm-Control, 80216, ähnliches. Das ist ja

manchmal bei der Hersteller irgendwie gerne mal so ein Batzen. Das kann ich einfach raus templaten, muss ich nicht 27 mal schreiben. Ja, Napalm hatten wir gerade schon drüber gesprochen. Python-Library redet mit

Oxidized, zieht Konfigurationen von beliebigen Netzwerkgeräten und ist Nachfolger von Rancid, wo Rancid noch irgendwie eine Sack voll, was war das? Shell, Expect und Napalm, glaube ich, noch war.

Das Oxidized tatsächlich ein bisschen sauber in Ruby geschrieben und hat für die jeweiligen Modelle eine eigene kleine Beschreibungssprache. Also wie ich zum Beispiel auf mein Gerät komme, wie ich der Konfig runter nucke und wie ich sie wegspeichere. Das ist eigentlich schon ganz hilfreich. Ja,

lieber NMS, auch wieder Network Management kann man, wie gesagt, mit Oxidized und Greylock vergnubbeln. Das ist ein schönes Open Source Projekt, hat vernünftige Governance. Das heißt, wenn ich einen Patch einreiche, geht er erst mal durchs automatische Testing. Das sagt mir dann schon mal, ob ich den Code Style eingehalten habe, ob alles grün ist, ob es funktioniert und wird

dann entsprechend meistens auch angenommen. Also ich glaube, Pull Request da haben wir den selten länger als drei, vier Tage, wenn das Feature vernünftig ist und der Rest der Community das haben will. Max Grinst, hast du da einen etwas

längeren Pull Request offen? Harte. Ja. Kommen wir zum Kernnetzwerk Routing Suites. Zu Anfang war das Zebra. Nein, zu Anfang war nicht der Gate Deed. Aus Mangel an Routing Funktionalitäten,

also so OSPF, BGP ähnliches hat irgendwann mal jemand angefangen, das Zebra zu entwickeln. Das war eine Sammlung voller Demons, die aussahen wie eine Cisco, ein bisschen. Diese wurden irgendwann so ein bisschen

vernachlässigt, dann wurde das Quagga gefolgt. Quagga ist halt auch ein Zebra, aber nicht ganz. Und nachdem auch die Quagga-Entwicklung so ein bisschen eingeschlafen ist, hat die Linux Foundation das Free Range Routing ins Leben gerufen, also quasi freigelassen. Das ist

so eine der Routing Suites, die mittlerweile ganz stark Features kriegen, die zum BGP-End, ich glaube anfangen von MPLSen dabei. Ich weiß nicht, was Free Range Routing

noch alles kann. Auf jeden Fall ein ganz sackvoll wirklich nützlicher Dinge im Routing-Umfeld. Da kommt der BERT noch nicht ganz hinterher, obwohl die BGP- Implementation von BERT vielleicht ein bisschen besser ist, ein bisschen stabiler. Dann gibt es so Sachen wie Bio-Routing. Bio-Routing steht für BGP, IS, IS und OSPF.

Wenn die alles täuscht, Max Nicktard, der baut da selber dann rum. Das ist eine Reimplementation von diesem ganzen Routing-Zeug in Go. Ich glaube, ihr macht das sogar testdriven, oder? Dann gibt es so

Sachen wie Go BGP, EXA BGP. Also BGP erlebt gerade so ein bisschen Höhenflug auch im Open-Source-Bereich, spricht irgendwie alles BGP, weil Google das anscheinend auch so tut. Und weil es aber tatsächlich einfach zu konfigurieren ist. Zumindest solange man nur ein, zwei Adressen irgendwie

rausgeben will. Weil IP Fabric und Anycast entscheiden. Ja, genau, weil sowas damit funktioniert und ich halt alles an Routentypen in so ein BGP reinpacken kann. Freck, warum hast du das Routentypen, die ich nicht erwähnt? Oh, stimmt, den habe ich vergessen.

Es gibt unter OpenBSD. Und Linux. Gibt es mittlerweile auch für Linux. OpenBGP, da gibt es noch irgendwie, ich glaube, mittlerweile für OpenBSD und OpenOS BFD. Und da entsteht auch gerade so ein Routing-Zoo.

Es ist jetzt nicht Open Source, aber selbst der Windows-Server 2012 aufwärts spricht BGP mittlerweile. Du lachst auch, ein Windows 2003 kann das auch schon. Sprichst auch RIP und sowas. Ist nicht schön, aber es funktioniert.

Ja, jetzt haben wir so ein bisschen Netzwerk drunter. Mal ein bisschen was als Abriss zur Virtualisierung. Es gibt da so ein paar schöne Open Source Tools. OpenStack gehört nicht dazu. Ist nur der Vollständigkeit halber empfohnt. Benutzt irgendwer von euch OpenStack?

Freiwillig? OpenStack ist ein großes Open Source Tool gestartet von Rackspace, um eine Virtualisierungsplattform haben, die ähnlich wie Amazon EC2 ist.

Dann hat das Ganze die Industrie entdeckt und hat gesagt, wir wollen auch Clouds bauen. Und jetzt ist das Ganze ein großer Zoo von Industriekonsortien, die da irgendwie mitstricken wollen, policy machen wollen. Wer mehr darüber wissen will, dem empfehle ich von Christian und Martin

den Talk 45 Minutes of OpenStack Hate. Das ist sehr passend. Dann gibt es so, wenn man sich selber eine Cloud bauen will und das irgendwie eine halbe Stunde tun will, kann ich nur jedem ans Herzen legen, sich mal OpenNabla anzugucken. Weil das kriege ich in 10-15 Minuten installiert. Sie haben

ein sehr gutes Handbuch. Und danach habe ich eine API, mit der ich mir imagebasiert Maschinen erstellen kann, mit Netzwerk dran und alle möglichen. Das finde ich tatsächlich ganz angenehm. Das Projekt an sich ist auch relativ klein noch, wird aber von einigen größeren Firmen

eingesetzt. Also irgendwie eine BlackBerry ist dabei, eine RunTestStick, eine Akamai und noch einiges auf der Website. Ja, dann gibt es noch Proxmox Virtual Environment. Ist auch eine Virtualisierungslösung, die sich auch mit dem ESX messen kann. Unterstützt ZFS, CEF, alles was man

braucht. Ich habe jetzt persönlich nicht so viel Erfahrung mit, aber da sie auch auf KVM setzen, kann das so schlecht nicht sein. Bitte? Ich höre von hinten, die API ist ein bisschen schwierig. Aber ich glaube der Ansatz ist auch ein anderer. OpenNabla und OpenStack ist

halt, ich hätte gerne gescriptete Infrastruktur. Also auch einfach mal, ich brauche zehn Maschinen, fünf Minuten später alles fertig. Und Proxmox ist eher so für die Kuscheltiere an Rechnern, nicht für die Herde. Nicht nur die API ist

schwierig, auch die Netzwerkkonfiguration hat Spezialität. Das hast du aber schön gesagt. Ja, was habe ich dann noch an OpenStore? Wenn ich jetzt mein ganzes Einheimen habe, habe ich damit auch üblicherweise Probleme. So, die

will ich tracken. Dazu brauche ich üblicherweise irgendwo so ein Incident Management oder ein Ticketsystem. Einer von euch schon mal mit einem der drei gearbeitet? Stimmt, ein Requer. Gut, sollte also bekannt sein.

Request Tracker ist alt, sehr gut abgehangen, sehr gut erweiterbar, wenn man den Perl kann und mag. OTRS ist auch sehr gut abgehangen, kann man angeblich auch erweitern, aber das halte ich persönlich immer für ein bisschen schwierig. Das ist nicht ganz so

durchsichtig wie ein Request Tracker. Und relativ neu ist Zammert von den Gründern von OTRS, glaube ich, von einem der OTRS Entwickler, die jetzt tatsächlich mal gedacht haben, okay, Ticket ist nicht nur E-Mail, sondern wir integrieren auch Telefon, Telegram,

E-Mail, Twitter, weißte Koko, was sich da anzapfen lässt und haben eigentlich diesen ganzen Ticket-Workflow mal neu gedacht. Vielleicht auch was, wenn man sowas neu aufsetzt, was man sich mal angucken könnte. So, dann haben wir noch die üblichen Command Line Tools, die üblichen

Verdächtigen. Dinge wie SoCut, NetCut. SoCut ist so ein bisschen Schweizer Taschenmesser. Wenn ich Dinge irgendwo rein und irgendwo rauskriegen will, ich kann auf Dateien, Socket, Streams irgendwas hören und das irgendwo anders hinschieben. Das heißt, ich kann auch

zum Beispiel meinen, wenn ich zwei Prozesse miteinander reden lassen will, kann ich das über SoCut machen, statt einer Pipe zum Beispiel, wenn ich noch andere Dinge dazwischen tun will. Ich kann also den Prozess in Socket schreiben lassen, mit das mit SoCut da wieder rausholen, damit Dinge tun und wieder zurückschreiben zum Beispiel.

NetCut. Ich will Dinge von irgendwie einem Rechner auf den anderen schieben, habe aber gerade keine Lust, irgendwie das mit SCP zu tun, sondern will einfach nur eine TAR-Datei rüber schieben oder habe halt so Sachen wie Sparse Files, die TAR ziemlich gut unterstützt, wo SCP dann sagt so, ja, ich kopiere die ganze Datei. Nicht nur die ersten 80 bytes, die

ich eigentlich nur habe. Dann kann ich zum Beispiel meinen TAR durch NetCut schieben, das einfach auf der einen Seite einen Server aufmacht und mir dann so virtuelles Rohr zwischen beiden Maschinen baut. N-Grep ist ziemlich cool, ist ziemlich ein Grep fürs Netzwerk.

Das heißt, ich kann zum Beispiel nach bestimmten HTTP-Verbindungen greppen und mir dann entsprechend die Pakete anzeigen lassen. Das Dreigestirn, Wireshark, T-Shark, TCP-Dump. TCP-Dump war relativ früh da,

genauso wie Snoop auf Solaris, dass das eigentlich so ein bisschen emuliert. Damit kann ich mir auf meinem Rechner angucken, okay, was für Netzwerkverkehr passiert irgendwo auf der Netzwerkkarte. Das hat der Jörg wahrscheinlich gestern in seinem Talk auch noch benutzt, TCP-Dump, zum zeigen.

Mit TCP-Dump kann ich mir das Ganze zum Beispiel auch in der Datei schreiben. Die kann ich dann irgendwie in einem grafischen Wireshark aufmachen und mir meine ganzen Paketströme angucken und Paketanalysen fahren, IO-Analysen fahren, ähnliche Sachen. Wenn ich jetzt mir nur die Pakete angucken will, geht auch ein T-Shark. Die Ausgabe ist ähnlich der

Detailausgabe von einem Wireshark. Das heißt, ich mir nur 10 Pakete angucken will, geht das ganz gut. Wenn ich einen längeren HTTP-Stream habe, scrollt es ein bisschen. Wenn ich das auf eine Weibesstelle stelle. Wenn ich wissen möchte, was auf meiner Netzwerkkarte los ist, gibt es einen IFTOP.

Damit sehe ich, welche Prozesse, wie viel Netzwerklast machen oder wie viel Netzwerk-IO gerade passiert. Gibt es auch noch so als IOTOP. Sollte man nicht zu lange laufen lassen, das Ding hat ein kleines Problem mit Memory Leaks. Das heißt, wenn man das über 24 Stunden laufen lässt, ist

das ein Problem. Aber um mal 10 Minuten zu gucken, was da eigentlich gerade Sache ist, ein paar hübsche Balken dran. Dann gibt es noch das gute Endmap, wenn ich gar nicht weiß, was in meinem Netzwerk eigentlich los ist. Kann ich damit mal durch die Gegend scannen, gucken, welche Hosts sind ab, welche Ports

sind da. Es gibt da draußen jede Menge Zeug. Max hat noch was. Es gibt noch VN Start neben IFTOP, wenn es mir nur darum geht, wie viel puste ich gerade durch die Interfaces durch. Das macht schöne Grafiken, auch wenn man möchte. Und My Trace Route oder Dublin Trace Route würde ich

noch hinzufügen wollen. MTR. Genau. MTR noch. Lepecap hätte ich noch erwähnt, weil da kannst du mit Pricing relativ simpel auch Sachen rausholen aus dem Unser Verkoden. Snort hätte ich vielleicht noch erwähnt. TrafShow ist übrigens auch so etwas, was bei meisten Unix-Systemen auch existiert. TrafShow muss du aber

glaube ich meistens nach installen. IP Traf gibt es auch auch. IP Traf gibt mir auch schöne Statistiken. Lepecap haben wir ja hier mit Wireshark, T-Shark, TCP-Dump, die alle tatsächlich diese Leap Packet Capture oder P-Cap benutzen, die auch überall zum Glück eine einheitliche Syntax hat. Das heißt, jedes dieser Tools hat tatsächlich den

gleichen Filterparameter hinten dran, wenn ich spezifische Hosts oder Portsfilter möchte. Gut, so viel zu Open Source Tools. Fragen? Nein. Dazu habe ich eine sehr

spezielle Meinung. Wir können nachher beim Kaffee gerne drüber reden. Gibt es noch Fragen? Okay, dann vielen Dank Falk für die Zusammenstellung.

Ich glaube, das ist nicht schlimm. Wir sind damit erstmal für die Vormittag durch. Hier geht es weiter dann um 14 Uhr mit dem Workshop. Wer jetzt den Raum verlässt, bitte den Talkraten. Bis später. Vielen Dank.