Monat: August 2011

Blog-Stoeckchen: Darum mag ich Foobar!

2011-08-30 / ports

Das habe ich ja schon laenger nicht mehr gesehen. Dirk hat mir ein Stoeckchen zugeworfen. Ausgeloest wurde das Stoeckchen durch Christoph, der das ganze wie folgt beschreibt:

Darum mag ich: Foobar!

Als Linux-Ein- und Umsteiger steht man wie ein Ochs vorm Berg. Nicht nur das Betriebssystem ist anders, sondern es “fehlen” auch bekannte und bewährte Programme. Nicht dass es die unter Linux nicht geben würde, die Vielfalt an guten Programmen ist riesig, doch welches soll man benutzen? Ich möchte daher ein Blog-Stöckchen starten, wo andere Linux-Blogger begründen, warum sie Foobar gerne benutzen. Beschreibt das Programm nicht lang und breit, sondern stellt eine besondere Funktion heraus, die Foobar von ähnlichen Programmen unterscheidet, die vielleicht ein bisschen unbekannt und versteckt ist und aufgrund der Foobar von eurem Desktop nicht wegzudenken ist.

Das ist in mehrfacher Hinsicht nicht leicht. Zum einen wegen „Desktop“ und zum anderen eine Funktion zu beschreiben, die das Programm von anderen abhebt. Spontan ist mir hier tpcdump/Wireshark eingefallen. Beide nutzen die (lib)pcap. Wireshark, um mal bei einem Tool zu bleiben, ist aus meiner Sicht eines der coolsten Tools fuer den Netzwerkbereich. Keine Frage, es gibt viele gute und freie Tools. Aber was hier angeboten wird ist einfach klasse.

Auf den ersten Blick, und nach dem ersten mitschneiden von Netzwerkverkehr, sieht man erst mal nur viel unverstaendliches Zeug. Aber Wireshark bringt unglaublich viele Moeglichkeiten fuer die Auswertung und Analyse der mitgeschnittenen Daten mit.

Ob man nun erst mal mit einfachen Filtern (ip.src==192.168.100.10, tcp.dstport==80) anfaengt oder gleich etwas komplexere Filter ((!(ip.src == 192.168.100.10)) || !(tcp.port == 80)) erstellt. Oder man nutzt die gerne verwendete „Follow TCP Stream“-Funktion. Auch die ganzen Optionen im Statistics-Bereich sind hilfreich und gepflegt umfangreich. Und wer mal Mitbewerberprodukte gesehen hat, der merkt, dass Wireshark viel bietet. Und damit meine ich keinen unfairen Vergleich gegen sowas wie den Netzwerkmonitor von Microsoft 🙂

Was man mit tcpdump machen kann habe ich vor ein paar Tagen mal bei adminstories.de beschrieben. Ich sag nur:
ramon@bar ~ $ sudo tcpdump -c 30 -ne -i eth0 dst port 80 and ‚tcp[13] == 2‘ \
| awk ‚{print $10}‘ \
| cut -d. -f1,2,3,4 \
| sort \
| uniq -c \
| sort -n

Und auch wenn sich mein Beitrag nicht ganz mit den urspruenglichen Erfordernissen deckt, so moechte ich das Stoeckchen doch weiter werfen.
Alexander
Hampa
Marko (wuerde mich doch mal interessieren)

Kinder Kinder

2011-08-29 / ports

Kinder wie die Zeit vergeht… Eben noch lasse ich mich ueber die Realnamendiskussion aus und ein kurzen Moment spaeter ist ein Monat um 🙂 Der neue Job fordert einen zu Anfang doch mehr als ich gedacht haette. Und dann war da ja noch das „aufhuebschen“ von Dirks und meinem Projekt: adminstories.de

Wir hatten fuer das Projekt ja am Anfang auf Dotclear gesetzt. Aber irgendwie sind wir beide doch eher die Serendipity-Nutzer. Und daher haben wir dann migriert. Und das war nicht ohne darf ich sagen. Nicht so plump wie WordPress->Serendipity, wo man was mit fertigen Importern machen kann. Also teilweise habe ich mir da schon einen abgebrochen. Aber Dirk und ich sind mit dem Ergebnis zufrieden. 🙂

Und sonst? Ja, ich hatte mir ein Dell XPS 17 gekauft, da mein Acer ja abgeraucht war. Das Dell war echt cool. Schnelle CPU, heftige Grafikkarte, 12 GB Ram und zwei Platten. Aber wie so oft haben so tolle Dinge manchmal einen Haken. Hier war es der Luefter. Der war derart stoerend, dass ich das Notebook nach einigen Tagen wieder abgegeben habe. Nun schaue ich wieder was ich nehmen kann.

Flags von aptitude

2011-08-26 / ports

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

So, und jetzt der zweite Beitrag. Noch eine Uebersicht verschiedener Flags fuer „aptitude“. Die hatte ich mir mal notiert, bzw. rausgesucht, da ich immer wieder mal Flags angezeigt bekommen hatte, die mir nicht so praesent waren.

Values of the „current state“ flag

i – the package is installed and all its dependencies are satisfied.
c – the package was removed, but its configuration files are still present.
p – the package and all its configuration files were removed, or the package was never installed.
v – the package is virtual.
B – the package has broken dependencies.
u – the package has been unpacked but not configured.
C – half-configured: the package’s configuration was interrupted.
H – half-installed: the package’s installation was interrupted.

Values of the „action“ flag

i – the package will be installed.
u – the package will be upgraded.
d – the package will be deleted: it will be removed, but its configuration files will remain on the system.
p – the package will be purged: it and its configuration files will be removed.
h – the package will be held back: it will be kept at its current version, even if a newer version becomes available, until the hold is cancelled.
F – An upgrade of the package has been forbidden.
r – the package will be reinstalled.
B – the package is „broken“: some of its dependencies will not be satisfied. aptitude will not allow you to install, remove, or upgrade anything while you have broken packages

Jobwechsel

2011-08-26 / ports

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Heute mal zwei Beitraege. Nicht jeder freut sich ueber „nichttechnische“ Beitraege, daher eben heute eine kleine Anpassung 😉

Erstes Thema dreht sich um den Jobwechsel. Es gibt einige gute Buecher die sich im Hinblick auf IT mit Karriere und der Entwicklung beschaeftigen. Eines der Buecher, dass ich sehr lesenswert fand, war „Das IT-Karrierehandbuch“ von Martina Diel (danke an Dirk fuer die Leihgabe).

Bei einem Jobwechsel sollte man, aus meiner Sicht, einige Punkte beachten und beherzigen. Grob kann man das vielleicht mit „Ende ohne Aerger“ und „Start mit Erfolg/Freude“ umschreiben. Erst mal zum „Ende ohne Aerger“.

Es gibt viele Gruende das Unternehmen zu verlassen und zu wechseln. Vielleicht ist man zufrieden, bekommt aber ein Angebot, dass einfach so fantastisch zu sein scheint, dass man deshalb den Arbeitgeber wechselt. Realistischer ist aber, dass man im aktuellen Job nicht mehr zufrieden ist. Vielleicht gibt es keine weiteren Entwicklungsmoeglichkeiten (Gehalt, Position, Arbeitsgebiet) oder die Arbeitssituation hat sich verschlechtert. Also geht man auf die Suche, oder nimmt dann doch auch mal erste Angebote von Headhuntern wahr. Irgendwann hat man dann endlich das gewuenschte gefunden und es ist klar, es wird gewechselt. Wie geht es nun weiter?

• Arbeite, soweit moeglich, wie gewohnt bis zum letzten Tag
• Verhalte dich gegenueber den Kollegen wie gewohnt
• Ergaenze oder erstelle fehlende Dokumentation
• Hinterlasse einen aufgeraeumten Arbeitsplatz
• Mach eine Uebergabe an den Kollegen/Nachfolger
• Hinterlasse keine verbrannte Erde

Das sind einige Punkte und vermutlich kann man diese auch noch hier und da ergaenzen. Die Punkte zeigen aber schon wo es lang geht. Letztlich fasst der letzte Punkt die vorherigen auch ein Stueck weit zusammen. Auch wenn klar ist, dass ihr demnaechst woanders arbeitet, solltet ihr in den letzten Wochen weiterhin gewohnte Qualitaet abliefern. Natuerlich kann man einen Wechsel auch als Chance sehen, endlich mal durchzuladen und dem Chef fein einzuschenken. Aber mir sind nur Gruende bekannt, die dagegen sprechen sowas zu machen. Alleine schon, dass man sich immer zweimal im Leben sieht und man natuerlich auch gerne ein ordentliches Zeugnis haben moechte. Dirk wuerde das ganze sogar noch etwas kuerzer, aber dafuer nicht weniger korrekt, darstellen.

• Arbeit gut machen bis zum Schluss
• So aufhoeren, dass man wieder dort anfangen darf

Etwas schwieriger wird es bei „Start mit Erfolg/Freude“. Das liegt zum Teil auch daran, dass man auf viele Dinge anfaenglich keinen Einfluss hat. Entweder, weil im neuen Unternehmen die entsprechenden Prozesse fehlen oder weil man die Struktur (natuerlich) noch nicht kennt. Glueck hat, wer gleich zu Anfang in den wichtigsten Abteilungen den Kollegen vorgestellt wird. Natuerlich wird man sich nicht alle Namen merken koennen. Aber die Kollegen merken sich in der Regel das neue Gesicht und den dazugehoerigen Namen. Und auch wenn Kleidung noch lange keinen guten Mitarbeiter ausmacht. Aber oft ist der erste Eindruck, ob zu Recht oder Unrecht, besser, wenn man beispielsweise mir ordentlicher Hose und Hemd erscheint.

Was man sich immer vor Augen halten sollte ist, dass es zu Anfang ausgepraegte Phasen der Langeweile und des Stress geben wird. Und vor allem bei den Langeweile-Phasen wird es manchmal hart, da man auch noch fuer das Nichtstun bezahlt wird. Je nach Groesse des Umfeldes, in dem man nun arbeitet, kann man nicht erwarten, dass man nach zwei Wochen alle Prozesse, Zusammenhaenge und Organisationsdetails kennt. In meinem Fall hat man mir am Anfang gleich gesagt, dass man nicht damit rechnet, dass ich vor Ablauf von sechs Monaten „richtig“ arbeiten werde. Natuerlich kann man nach einiger Zeit die Kollegen bereits unterstuetzen. Aber wirklich alles zu lernen und kennen zu lernen, was fuer den aktuellen Job wichtig ist, dauert. Und dieses Entwicklung ist ja auch nicht immer von einem selbst kontrollierbar. Es wird auch immer wieder passieren, dass der Kollege oder „Ausbilder“ nicht immer Zeit fuer einen hat. Darueber muss man sich klar sein und sollte nicht frustriert sein, wenn man mal ein paar Tage lang keine Entwicklung sieht.

Und dann noch ein abschliessender Punkt, der aus eigener Erfahrung auch gerne unterbewertet wird. Im Rahmen der Einarbeitung wird man nicht nur viel lernen, sondern auch viele neue Eindruecke mitnehmen muessen und duerfen. Das alles fuehrt dazu, dass man fuer andere Dinge oft nicht mehr aufnahmefaehig ist oder schlicht einfach keine Lust mehr hat. Bei mir betrifft das beispielsweise unter anderem die Betreuung unserer Server, die nun etwas leidet, weil ich einfach oft keinen freien Kopf mehr habe, wenn ich nach Hause komme.

Blackholes identifizieren

2011-08-04 / ports

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Nein, wir bleiben im weiten Feld der EDV und wechseln nicht in die Astronomie. Obwohl Schwarze Loecher durchaus interessant sind. Aktuell geht es aber um sogenannte Blackholes in Netzen.

Wer sich ein wenig mit Netzwerken beschaeftigt wird wissen, dass Daten nicht am Stueck, sondern in Pakete verteilt, uebertragen werden. Bei TCP/IP sind das in einem Ethernet 1500 Byte. Die 1500 Byte sind natuerlich nicht der Bereich, der fuer Nutzdaten verwendet werden kann. Hier gehen dann noch die sogenannten Headerinformationen fuer IP (Source Address, Destination Address, Protocol, etc.) und TCP (Source Port, Destination Port, Flags, etc.) ab, so dass spaeter entsprechend weniger Platz fuer die Daten bleibt. Im Normalfall haben wir 20 Byte fuer IP und noch mal 20 Byte fuer TCP, womit dann 1460 Byte fuer weiter oben liegende Protokolle ueber bleiben.

Wenn nun einer der beteiligten Router nicht in der Lage ist ein Paket mit gesetztem DF-Bit (Don’t Fragment) ohne Fragmentierung zu uebertragen und keine entsprechende Meldung abgibt, dann haben wir ein Problem. Denn die beteiligten Hosts gehen davon aus, dass sie Pakete in der Groesse X versenden koennen, die gehen aber nicht ueber die Leitung, da der Router diese verwirft. Die Effekte koennen nun von Abbruechen der Verbindungen bis hin zu einfachen Aussetzern und Performanceproblemen fuehren. Was also tun, wenn man ein Blackhole vermutet?

Am einfachsten ist hier der Einstieg mit Ping. Unter Linux waere beispielsweise ein ping -c 1 -M do -s 1472 $ZIEL ein guter Ansatz. Mit -c 1 definieren wir, dass nur ein Paket geschickt wird. Das -M do bedeutet soviel wie Don’t fragment. Mit -s 1472 wird die Anzahl der Daten-Bytes festgelegt und mit $ZIEL, kaum ueberraschend, das Ziel. Das mit dem -c 1 (oder einem anderen sinnvollen kleineren Wert) sollte man machen. Andernfalls kann es passieren, dass einem nachher ewig viele Frag needed and DF set -Meldungen durch die Shell rauschen.

Die maximale Groesse der MTU (Maximum Transmission Unit) in unserem Beispiel (mal so ein „normales“ Ethernet angenommen) ist 1500 Bytes. Da ziehen wir dann noch 20 Bytes fuer IP und 8 Bytes fuer ICMP ab. Hier mal ein Beispiel.

ramon@superfrog ~ $ ping -c 1 -M do -s 1473 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 1473(1501) bytes of data.
From 192.168.150.10 icmp_seq=1 Frag needed and DF set (mtu = 1500)

— 192.168.0.1 ping statistics —
0 packets transmitted, 0 received, +1 errors

Hier sehen wir, dass es Probleme gibt, da die MTU 1500 Bytes gross ist. Wir wollten aber, zusaetzlich zu den 20 Bytes fuer IP und den 8 Bytes fuer ICMP, noch 1473 Bytes an Daten uebertragen. Und das ohne zu fragmentieren. Da wir in Summe mehr als 1500 Bytes haben, gibt es eine entsprechende Meldung. Als Vergleich noch ein Beispiel, in der das Paket ueber das Netz geht.

ramon@superfrog ~ $ ping -c 1 -M do -s 1472 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 1472(1500) bytes of data.
1480 bytes from 192.168.0.1: icmp_req=1 ttl=62 time=5.51 ms

— 192.168.0.1 ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.515/5.515/5.515/0.000 ms

Soweit so gut. Moechte man nun allerdings den Hop identifizieren, der Probleme macht, ist man nur mit der Ping-Methode nicht auf der sicheren Seite. Denn, wir erinnern uns, der „boese“ Router meldet ja nichts zurueck. Also nehmen wir uns traceroute als Werkzeug zur Hilfe. Fuer den Anfang machen wir erst einmal ein einfachen traceroute auf das Ziel via traceroute $ZIEL. Anschliessend kann man sich dann durch die Tabelle durcharbeiten. Der traceroute-Befehl von Windows und Linux unterscheiden sich allerdings, nicht nur in den Parametern, ein Stueck weit. Verwendet tracert unter Windows ICMP, so haben wir mit traceroute unter Linux im Standard UDP-Pakete.

ramon@superfrog ~ $ traceroute -n 192.168.0.1
traceroute to 192.168.121.254 (192.168.121.254), 30 hops max, 60 byte packets
1 192.168.150.1 0.341 ms 0.368 ms 0.411 ms
2 192.168.100.1 0.343 ms 0.362 ms 0.409 ms
3 192.168.0.1 18.310 ms

Nun haben wir eine Liste der beteiligten Stationen und koennen diese nun einzeln mit einem ping -f -l $PAKETGROESSE $ZIEL (um auch dem Windows-Ping mal eine Chance zu geben) testen.

Kleine Ergaenzung. Ich konnte nicht durchgaengig originale Ausgaben der Befehle verwenden, da der WLAN-Router in meinem Netzwerk beim Testen, vor allem mit zu grossen Paketen und dem gesetzten DF, aus dem Tritt kam und neu gestartet werden musste. *huestel*

Sollte es Fragen oder Unklarheiten geben, koennt ihr mich gerne ansprechen!