|
||||||
|
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. |
||||||
|
Copyright © 2012 clutterbox - All Rights Reserved |
||||||
Letzte Kommentare