|
||||||
|
Manchmal kommt es vor, das man vor einem schwer zu debuggenden Problem steht und deswegen tcpdump nutzt um die dumps nachher mit Wireshark zu analysieren. Wenn tcpdump allerdings länger läuft, werden die Dumps meist mehrere 100 MiB gross, so dass diese sich nicht mehr allzu schnell bearbeiten lassen. Abhilfe schafft tcpdump selbst – es kann die Datei selbständig rotieren, so dass die Dateigröße klein gehalten werden kann. Hier ein Beispiel, um ein Log jede Stunde rotieren zu lassen tcpdump -pni eth0 -s65535 -G 3600 -w 'trace_%Y-%m-%d_%H:%M:%S.pcap' -G ist dabei die Zeit in sekunden zwischen den rotationen. -w akzeptiert dann strftime-Platzhalter – bei dem Beispiel würde die Datei z.B. trace_2010-08-30_13:04:55.pcap heißen können. Alle Platzhalter sind in strftime(3) dokumentiert. Als alternative zum rotieren “nach x Sekunden”, bietet tcpdump mit der Option -C auch die Möglichkeit das Capturefile zu rotieren, wenn eine gewisse Dateigröße erreicht wurde. Um die Dateigröße auf 100MB zu beschränken, kann man folgenden Befehl verwenden tcpdump -pni eth0 -s65535 -C 100 -w capture Zusammen mit -C werden bei -w allerdings keine strftime-Platzhalter mehr ausgewertet. Die Dateinamen sind einfach der Reihenfolge nach capture, capture1, capture2, …, capture<n>. Alles, was nicht fixiert ist, fällt runter, dank der Gravitation. Aber wieso ist das bei Webseiten eigentlich anders? Ein Experiment zeigt, was mit Google passiert, wenn die Gravitation wirk: Google Gravity. Interressant ist, dass alle Elemente auf der Webseite weiterhin bedienbar sind – versucht einfach etwas zu suchen Update: funktioniert nicht vernünftig mit Firefox und mit IE gar nicht – ist halt ein Chrome-Experiment. Auf Debian-basierten Systemen wird in der standartmäßigen Konfiguration jede Nachricht des snmpd nach syslog in die /var/log/daemon.log geloggt. An sich ist das eine gute Sache, allerdings wird dadurch auch jede Verbindung geloggt, was doch etwas unangenehm werden kann. Gerade bei snmpwalks oder auch snmp-basierten checks von Nagios häufen sich die Logmeldungen. Jul 11 16:24:56 www1 snmpd[2120]: Connection from UDP: [10.50.0.1]:56686->[10.50.0.11] Jul 11 16:25:27 www1 snmpd[2120]: last message repeated 965 times Abhilfe gibt es in der Form, das man dem snmpd sagt, dass er erst ab einem bestimmten Level loggen soll. Bei Debian/Ubuntu findet man die Einstellungen in der Datei /etc/default/snmpd. Die Standarteinstellung für die Optionen für den snmpd sehen dabei momentan so aus: SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1' Für uns interessant ist im Grunde nur der Parameter “-Lsd”. Dieser besagt, das alles Logging (L) über Syslog (s) Laufen soll, und zwar in die Daemon (d) Facility. “-Lf /dev/null” deaktiviert dazu noch das logging direkt in eine Datei. Um das Logging jetzt auf bestimmte Prioritäten zu beschränken, ändert man das “-Ls” in “-LS”. Der Parameter erwartet vor der Facility jetzt noch eine Priorität, entweder ab welchem Level geloggt werden soll, oder eine von-bis Angabe. Um alles ab Warnungen zu loggen, ändert man den Paramter auf -LS4d. Die komplette Zeile könnte nun so aussehen: SNMPDOPTS='-LS4d -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid' Nach einem neustarten des snmpd werden nun die Verbindungen nicht mehr geloggt. Ich merke dabei zur Sicherheit nochmal an, dass ein snmpd niemals “einfach so” übers Internet erreichbar sein sollte, da bis snmp v2 alles einfach nur Klar-Text ist. Die komplette Dokumentation findet man unter Ubuntu in der manpage snmpcmd(1) unter “LOGGING OPTIONS”. Mit VirtualBox aus der aktullen 3.2er Serie ist ein sehr interessantes Feature dazu gekommen: Multi Monitor Support. Das bedeutet, dass VirtualBox einem Gast bis zu 8 virtuelle Bildschirme zur Verfügung stellen kann. Diese werden dann als separate Fenster in dem Host angzeigt. Praktisch ist das vor allem in den Fullscreen und Seamless Modi. Hier “mappt” VirtualBox einen virtellen Monitor auf einen physikalischen. Dadurch hat man dann zum Beispiel einen virtuellen Windows Desktop auch auf beiden Bildschirmen des Linux Hosts. Die Konfiguration davon ist VirtualBox-typisch gehalten: Bei den Settings einer VM gibt es in der Kategorie “Display” einen neuen Slider “Monitor Count”. Hier einfach die gewünschte Anzahl der virtuellen Bildschirme setzen – idealerweise die Anzahl der Monitore, die man auch angeschlossen hat. Das Mapping der virtuellen an die physikalischen Monitore kann man an der VM direkt im laufenden Betrieb vornehmen. Entweder über das Menü, oder über die Host-Taste (standartmäßig: rechte STRG) + Pos 1. Dort über das “View”-Menü kann man dann die Mappings an die eigenen Vorstellungen anpassen.
Sessions in PHP sind schon eine feine Sache, allerdings kann es problematisch werden, wenn man vor einer Anwendung einen Load-Balancer hat. Dann muss man entweder seine eigenen Session-Handler mittels session_set_save_handler schreiben, was allerdings einige Zeit verschlingen kann, oder auf bereits vorgefertigte Handler ausweichen. Memcached hat sich auf der anderen Seite hat sich zum cachen von Daten schon mehrfach beweisen und es bietet sich für das Speichern von Sessions direkt an – und das beste ist, dass es dafür schon direkt einen Session-Handler in der PHP-Extension memcached gibt und die Installation davon bei Debian/Ubuntu schon fast trivial ist. Einen Nachteil hat das ganze allerdings: Man sollte den memcached-Server nicht “mal eben” neu starten, weil dann alle darin gespeicherten Sessions verloren gehen. Um das zu verhindern, muss man allerdings eine Lösung einsetzten die einen persistenten Speicher verwenden, wie z.B. memcachedb oder membase. Auf dem Server, der die Sessions mittels memcached speichern soll, muss erstmal memcached installiert werden apt-get install memcached Auf dem Client (auf dem die PHP-Scripte liegen) jetzt noch die memcached-extension für php installieren apt-get install php5-memcached Jetzt muss in der php.ini nur noch eingestellt werden, dass der “memcached”-Handler für php-Sessions verwendet werden soll und welche Adresse der memcached Server hat. Dazu einfach die /etc/php/apache2/php.ini bearbeiten. [Session] session.save_handler = memcached session.save_path = "10.50.0.2:11211" Sessions werden jetzt unter der IP-Adresse gespeichert, die bei session.save_path angegeben ist. Anstatt einer einzelen IP kann man auch eine Komma-separierte Liste mit IPs angeben, die als Pool verwendet werden, z.B. “10.50.0.2:11211,10.50.0.3:11211″. Die beiden memcached-Server können auch auf der gleichen IP auf unterschiedlichen Ports liegen, allerdings verliert man dadurch den Vorteil, dass einer der Server wegbrechen kann. Jetzt nur noch den apache neu laden, dass die Einstellungen auch angewendet werden. apache2ctl graceful Fertig – ab jetzt werden die Sessions direkt in memcached gespeichert. Joe hat mir einen netten Kommentar hinterlassen, wie man ALIX-Boards und Gehäuse kommt, wenn man in den USA lebt. Die Gehäuse bekommt man im Shop von Netgate. Zusätzlich hat er auch noch ein CentOS-Image für ALIX-Boards erstellt, welches passend ist, wenn man mehr machen möchte als nur das Vyatta-übliche Routing und Firewall. Für eine Anleitung und den Download-Link, besucht einfach sein blog (englisch). Alle 2 Jahre wieder – jetzt gibt es das langerwartete, neue Long Term Support-Release von Ubuntu. 10.04 wurde gestern offiziell veröffentlich und ist zum download verfügbar. Das LTS-Release bietet, im Gegensatz zu den normalen releases, 5 Jahre Updates an. Das ist gerade bei Servern interessant, bei denen weniger release-updates weniger Kopfschmerzen und weniger Arbeit für den Admin bedeuten. Normalerweise werden solche langen Supportperioden nur bei kostenpflichtigen “Enterprise”-Versionen angeboten, aber bei Ubuntu bekommt man die kostenlos. Mein System hier werde ich die nächsten Tage dann wohl auch updaten Hier jetzt noch die Konfiguration, wie ich mein Sierra Wireless-Modem (MC8790) konfiguriert habe. Leider konnte ich das Modem nicht direkt mit vyatta konfigurieren. Das Problem ist, dass die Verbindung niemals automatisch erstellt werden darf – eine Einwahl kostet immerhin für den jeweiligen Tag gleich 5€. Deswegen habe ich die Konfiguration manuell angelegt. Nachteil dabei ist natürlich, dass man dann keine weiteren Konfigurationen, wie z.B. eine Firewall, nicht direkt über vyatta hunzufügen kann. Das Modem selbst ist mittels mini-PCIe verbaut und nutzt USB 2.0 connectivity. Das heisst, das das Modem im Grunde nur ein intern verbautes USB-Gerät ist und als solches auch gehandelt wird. Bei meinem MC8790 brauchte ich ausserdem eine rechte aktuelle Kernel-Version – 2.6.30 nutze ich momentan. Ob auch ältere Versionen unterstützt werden, weiss ich leider nicht. Deswegen habe ich momentan eine Vyatta-Version direkt aus dem git-repository. Mittlerweile gibt es allerdings auch von der VC6 eine alpha direkt auf CD, das macht das ein bisschen einfacher Nach Installation und booten des Routers habe ich mich erstmal Vergewissert, dass das Modem korrekt erkannt wurde: vyatta@vyatta:~$ lsusb Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 1199:683c Sierra Wireless, Inc. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Das Modem wurde also erkannt, einmal noch mittels dmesg geprüft, ob der Treiber auch geladen wurde: [ 16.945727] usbcore: registered new interface driver usbserial [ 16.945808] USB Serial support registered for generic [ 16.946068] usbcore: registered new interface driver usbserial_generic [ 16.946084] usbserial: USB Serial Driver core [ 16.986380] USB Serial support registered for Sierra USB modem [ 16.986478] sierra 1-2:1.0: Sierra USB modem converter detected [ 17.029253] cs5535_gpio: base=0x6100 mask=0xb003c66 major=251 [ 17.048506] usb 1-2: Sierra USB modem converter now attached to ttyUSB0 [ 17.048581] sierra 1-2:1.1: Sierra USB modem converter detected [ 17.056541] usb 1-2: Sierra USB modem converter now attached to ttyUSB1 [ 17.056616] sierra 1-2:1.2: Sierra USB modem converter detected [ 17.059656] usb 1-2: Sierra USB modem converter now attached to ttyUSB2 [ 17.059725] sierra 1-2:1.3: Sierra USB modem converter detected [ 17.064442] usb 1-2: Sierra USB modem converter now attached to ttyUSB3 [ 17.064504] sierra 1-2:1.4: Sierra USB modem converter detected [ 17.066123] usb 1-2: Sierra USB modem converter now attached to ttyUSB4 [ 17.066195] sierra 1-2:1.5: Sierra USB modem converter detected [ 17.067960] usb 1-2: Sierra USB modem converter now attached to ttyUSB5 [ 17.068033] sierra 1-2:1.6: Sierra USB modem converter detected [ 17.069120] usb 1-2: Sierra USB modem converter now attached to ttyUSB6 [ 17.069194] usbcore: registered new interface driver sierra [ 17.069209] sierra: v.1.3.3:USB Driver for Sierra Wireless USB modems So weit, so gut – das Modem bietet 7 serielle Ports – ttyUSB0-7. Davon sind einige als Modem ansprechbar – bei mir genau eins, da mein Router nur einen SIM-Socket hat. Da es viel zu aufwändig wäre, alle Modems mit allen seriellen Geschwindigkeiten auszuprobieren, habe ich dafür wvdial verwendet. wvdial wird allerdings nicht direkt von vyatta mitgeliefert – aber vyatta ist auch “nur” ein Debian, deswegen kann man entweder:
Da ich ja Faul bin habe ich einfach letzteres gemacht Bei vyatta dazu einfach in den configure-Modus wechseln und folgende Konfig anlegen: system {
[...]
package {
[...]
repository lenny {
components main
distribution lenny
url http://ftp.informatik.rwth-aachen.de/ftp/pub/Linux/debian/
}
}
}
Aus Gründen der Übersichtlichkeit habe ich die anderen Parameter aus den sektionen system und package einfach durch [...] ersetzt. Jetzt ein “commit” und “save”, um die neuen Werte zu speichern und dann wieder mit “exit” auf die Shell. Dann mit “sudo -s” root werden und mittels “apt-get update” einmal die Paketquellen aktualisieren. Jetzt kann man mittels “apt-get install wvdial” einfach wvdial installieren. Als nächstes muss das passende Modem gefunden werden. Dazu einfach als root auf der Shell “wvdialconf” eingeben. Das Programm testet alle Serial-Devices mit allen Geschwindigkeiten und INIT-Optionen und wartet auf eine passende Antwort von dem Modem. root@vyatta:~# wvdialconf Editing `/etc/wvdial.conf'. Scanning your serial ports for a modem. [Ausgabe gekürzt] Found a modem on /dev/ttyUSB3. Modem configuration written to /etc/wvdial.conf. ttyUSB3<Info>: Speed 9600; init "ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0" ttyUSB4<Info>: Speed 9600; init "ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0" ttyUSB5<Info>: Speed 9600; init "ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0" ttyUSB6<Info>: Speed 9600; init "ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0" wvdialconf sagt einem im Prinzip hier direkt, dass man /dev/ttyUSB3 als Modem mit 9600 baud verwenden kann. Da das Modem jetzt gefunden ist, bietet es sich an, von der SIM-Karte den simlock zu entfernen, weil sonst muss man nach jedem reboot den PIN wieder eingeben. Alternativ lässt sich das aber auch über ein chatscript machen. Bei mir habe ich einfach den simlock entfernt. Dazu habe ich noch minicom installiert (apt-get install minicom). Bei minicom zuerst einmal eine default-config anlegen. Dazu einfach “minicom -s” aufrufen. Hier im 3. Menüpunkt “Serial Port Setup” die Einstellungen für den Seriellen Port hinterlegen. Wichtig sind im Grunde die Punkte “Serial Device” und “Bps/Par/Bits”, so dass die Konfig danach wie folgt aussieht: A - Serial Device : /dev/ttyUSB3 B - Lockfile Location : /var/lock C - Callin Program : D - Callout Program : E - Bps/Par/Bits : 9600 8N1 F - Hardware Flow Control : No G - Software Flow Control : No Dann das ganze als “dfl” speichern und minicom beenden. Danach nochmal minicom starten, diesmal allerdings als “minicom -o”. Das “-o” bewirkt, dass minicom nicht versuchen soll, das Modem zu initialisieren. Das machen wir selbst (XXXX dabei gegeben den PIN der Karte ersetzen): ATZ OK AT+CPIN=XXXX OK AT+CLCK="SC",0,"XXXX" OK Jetzt bucht sich das Modem automatisch ins Netz ein und ist auch sofort verwendbar. Jetzt sind es nur noch 2 kleine Schritte, bis das Modem voll verwendbar ist! Als nächstes muss ein ChatScript angelegt werden. In diesem stehen die nötigen AT-Befehle, um eine Datenverbindung aufzubauen. Bei Vyatta liegen diese in ” /opt/vyatta/share/ppp/network/”. Ich habe dort eine Datei namens “vodafone.it” für meine Konfiguration angelegt, die folgendermaßen aussieht: ECHO ON TIMEOUT 60 ABORT ERROR ABORT BUSY ABORT VOICE ABORT "NO CARRIER" ABORT "NO DIALTONE" ABORT "NO DIAL TONE" ABORT "NO ANSWER" '' ATZ OK AT+CGDCONT=1,"IP","web.omnitel.it" OK ATD*99# CONNECT '' Wichtig hierbei ist eigentlich lediglich der “AT+CGDCONT”-Befehlt, der die Verbindungsspezifischen eingenschaften für den Datenkontext festlegt: 1 steht für die erste Konfiguration, IP steht für eine IP-Session und web.omnitel.it ist der APN-Name. Um den APN für den eigenen Provider herauszufinden, muss man ein wenig googlen – mit den Suchbegriffen “APN” und dem Providernamen ist untern den ersten 2-3 Ergebnissen der APN-Name zu finden. Jetzt fehlt nur noch die Konfiguration für den pppd selbst. In “/etc/ppp/peers/” habe ich dafür eine Datei “wlm99″ angelegt mit folgendem Inhalt: ipparam "wlm99 " usepeerdns /dev/ttyUSB3 9600 lcp-echo-failure 0 debug nodefaultroute ipcp-max-failure 4 ipcp-accept-local ipcp-accept-remote noauth crtscts lock persist linkname wlm99 connect '/usr/sbin/chat -v -t6 -f /opt/vyatta/share/ppp/network/vodafone.it' Das sind meist auch die Optionen, die vyatta hier nutzen würde – es gibt allerdings 2 Wichtige unterschiede:
Das wars. Von dem Router selbst aus, sollte sich die Verbindung nun mit einem “pppd call wlm99″ starten lassen: root@vyatta:~# pppd call wlm99 ATZ OK AT+CGDCONT=1,"IP","web.omnitel.it" OK ATD*99# CONNECT Serial connection established. using channel 2 Using interface ppp0 Connect: ppp0 <--> /dev/ttyUSB3 [ausgabe gekürzt] Could not determine remote IP address: defaulting to 10.64.64.64 Script /etc/ppp/ip-pre-up started (pid 24095) Script /etc/ppp/ip-pre-up finished (pid 24095), status = 0x0 Cannot determine ethernet address for proxy ARP local IP address 109.115.28.106 remote IP address 10.64.64.64 primary DNS address 83.224.65.134 secondary DNS address 83.224.66.134 … und endlich online! Wer jetzt allerdings noch mit Geräten hinter dem Router die Verbindung nutzen möchte, muss noch eine NAT einrichten. Das lässt sich wieder über Vyatta einstellen, die Konfiguration dafür sieht so aus: service {
[...]
nat {
rule 1 {
outbound-interface wlm99
type masquerade
}
}
}
Noch ein “commit” und ein “save” – damit ist auch die NAT eingerichtet und der Router ist voll verwendbar. Eigentlich hatte ich ja auf milderes Klima im Urlaub (sprich: Gardasee) gehofft, allerdings ist ja kaum jemand in Europa von der Rückkehr des Winters verschont geblieben. Das auf dem Monte Baldo noch Schnee bis in den Frühling liegt, ist normal. Allerdings habe ich hier bisher noch nie Schnee erlebt – und es höhrt jetzt seit gestern abend auch nicht mehr auf zu schneien. Dazu kommt noch ein Nebel, bei dem man die Hand vor Augen kaum noch sehen kann. 
Manchmal passiert es halt, dass man versucht das Rad neu zu erfinden. Besser gesagt, wollte ich immer noch ein vyatta installations howto online stellen, was bei mir immernoch als Entwurf im Backend rumliegt. Allerdings gibt es bereits andere, die das schon viel besser gemacht haben – also hier einfach ein Link Ich veröffentliche die Konfiguration der Wireless Karte dennoch. |
||||||
|
Copyright © 2010 clutterbox - All Rights Reserved |
||||||
Letzte Kommentare