Archiv ‘Linux’

Samstag, 7. Juli 2007

Mac OS X Terminal einfärben

Link zu diesem Artikel

Nun bin ich also gerade daran, (gemäss Anweisungen der GTD-Gurus) meinen Desktop von altem Ballast zu „decluttern“ und arbeite mich durch hunderte von .webloc-Dateien. Eine davon zeigt auf den Artikel Color Your OS X Command Prompt.

Um unter Mac OS X 10.3.9 in den Genuss farbiger Listings zu kommen, muss die Datei ~/.bash_profile mit folgendem Inhalt erstellt werden:

export CLICOLOR=1
export LSCOLORS=ExFxCxDxBxegedabagacad

Bei einem schwarzen Hintergrund sind folgende Farben lesbarer:

export LSCOLORS=dxfxcxdxbxegedabagacad

Ausserdem sollte das Terminal unter Preferences auf xterm-color geschaltet werden. Nun noch ein Neustart der Applikation, und fertig ist das Farbenwunder!

Tags:
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Donnerstag, 21. Juni 2007

Wie viele RSS-Abonnenten habe ich? (oder: Shell-Tricks)

Link zu diesem Artikel

Angespornt durch den Artikel 10 Techniques I Used To Go From 0 To 12,000 RSS Subscribers In Seven Months – With No Ads Or Leverage nahm mich Wunder, wieviele RSS-Abonnenten ich denn ungefähr habe.

Dank meinem Hosting-Provider Genotec habe ich Zugriff auf die RAW Log-Files von Apache. Als Stichprobenraum wählte ich den ganzen Monat Mai.

Zur Analyse lud ich die 31 2007-05-*.gz per FTP auf den lokalen PC herunter. Damit war die Arbeit mit dem Mac-GUI erledigt und ich wendete mich einer Mac OS X Terminal-Session zu.

  1. Entpacken und zusammenfügen der täglichen Log-Dateien zu einem grossen File 
    gunzip *.gz
cat access_log* > access.log
  2. Herausfiltern der Zugriffe auf atom.xml sowie rss.xml (die beiden Dateien enthalten die Feeds im XML-Format) 
    cat access.log | grep atom.xml > access-atom.log
cat access.log | grep rss.xml > access-rss.log
  3. Isolieren der Hosts (d bedeutet „Delimiter“ oder Trennzeichen; in meinem Fall ist es das Leerzeichen; f bedeutet „Field“). Mit der Kenntnis des Formats des Apache-access.logs sollte es klar sein, dass ich damit die Spalte mit der IP- oder DNS-Adresses des zugreifenden Clients vom restlichen Datenmüll trenne 
    cat access-atom.log | cut -d " " -f 1
  4. Nun bringen wir etwas Ordnung in die Sache, fasse Anfragen von identischen Hosts zusammen und geben aus reinem Gwunder auch gleich noch aus, wieviele Anfragen der jeweilige Host verursacht hat: 
    sort | uniq -c
  5. Um die Anzahl Abonnenten zu eruieren, benutzen wir das Tool wc (wordcount) mit dem Switch l, der das Tool anweist, Linien (und nicht etwa Wörter) zu zählen 
    wc -l

Alle Befehle nacheinander gepipet ergeben folgenden Einzeiler (für Zugriffe auf das altmodische atom.xml):

cat access.log | grep atom.xml | cut -d " " -f 1 | sort | uniq | wc -l

Wer

Die Antwort

Im Monat Mai war mein Blog also von 1634* Lesern abonniert.

*) Bemerkungen

  • Hinter einem Host können sich auch mehrere Leser verbergen (bspw. Google Reader)
  • In dieser Statistik werden auch Hosts gezählt, die im ganzen Monat nur gerade eine Anfrage auf den Feed gemacht haben. Einerseits können dies Leute mit dynamischen IP-Adressen sein, andererseits auch Leute, die ich mit meinem Geschreibsel nicht zu fesseln vermochte.

Qualitative Aussagen

Zu meinen Abonnenten gehören Computer, die (neben anderen) in folgenden Unternehmensnetzwerken stehen:

  • Universität Bern
  • Universität Zürich
  • ZHW
  • ISZ
  • GIBB
  • Universität Leipzig
  • Planetlab MIT/Princeton
  • UCLA Computer Science
  • Ravensbourne College of Design and Communication
  • Espace Media
  • Swisscom
  • Axpo
  • Bundesverwaltung
  • Netstyle
  • Init7
  • Merck

Es scheint sogar einen (?) Leser zu geben, der meine Blogs auf seinem Mobiltelefon liest. Suchthaufen! *zwinker*

Google-Kandidaten aufgepasst!

Eine solche Frage kann einem übrigens während einem Telefoninterview mit Google gestellt werden. Merkt euch als die glorreichen cat, grep, cut, sort, uniq, und ihr seid eurem Traumjob näher.

Tags:
Labels: Linux, Web

1 Kommentar | neuen Kommentar verfassen

Dienstag, 29. Mai 2007

Mails serverseitig filtern mit .procmailrc

Link zu diesem Artikel

Auf der Arbeit komme ich in den Genuss eines Unix-Mailservers und eines SSH-Zugangs auf ebendiesen (der mittlerweile etwas veraltete „Big Iron“-Ansatz hat wohl nicht mehr lange Bestand und ich fürchte um meine liebevoll eingepflegten procmail-Filter). Damit sind alle Voraussetzungen erfüllt, um eintreffende E-Mails serverseitig zu filtern.

Der Vorteil gegenüber einer clientseitigen Filterung (mit Apple Mail übrigens ein Kinderspiel) liegt auf der Hand: Greife ich zum Beispiel mit einem Mobiltelefon auf den IMAP-Server zu, liegen weniger Nachrichten in der INBOX, was sich in einer schnelleren Übertragung wiederspiegelt.

Syntax

Ein kleiner Ausschnitt aus meiner .procmailrc:

:0
* ^Subject.*new station eth0.
IMAP/arpwatch-n

:0
* ^From.*arpwatch
IMAP/arpwatch

Der Aufbau ist recht simpel:

  • :0 Der Ursprung dieser Zeichenfolge entzieht sich meiner Kenntnis; die Bedeutung lautet „Es folgt eine Regel“
  • * Signalisiert einen Filter. Nachfolgend werden reguläre Ausdrücke („regular expressions“) angefügt. ^ bedeutet beispielsweise „am Anfang einer Zeile“; das Gegenteil wäre $, was „am Ende einer Zeile“ bedeutet. Ein . (Punkt) ist ein Platzhalter für genau ein Zeichen, ein .* (Punkt mit nachfolgendem Stern) bedeutet „eine beliebig lange Zeichenkette“ usw. usf.
  • IMAP/arpwatch bedeutet den Zielordner; eine grosse Datei im .mbx-Format

Bestimmte E-Mails weiterleiten

Vor einigen Tagen kam der Wunsch auf, bestimmte automatisch generierte Mails an gewisse Leute auf der Arbeit weiterzuleiten. Von Hand wäre das sehr mühsam gewesen, ein Eingriff in den Programmcode (Drupal) stand ebenfalls ausser Diskussion.

Doch wieso in die Ferne schweifen? .procmailrc bringt alles mit, um auch so etwas auf drei Zeilen zu bewerkstelligen:

:0 c
* ^Subject.*Kontodetails f
! user@server.tld
  • :0 c „c“ weist procmail an, eine Kopie der Nachricht zu erstellen (damit ich die Nachricht weiterhin in meine INBOX geliefert erhalte)
  • * Signalisiert (immer noch) einen Filter (siehe oben)
  • ! user@server.tld Die Nachricht wird an die Mail-Adresse user@server.tld weitergeleitet

Weiterführendes

5. Mails lokal zustellen

Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 4. Mai 2007

Wenn Smarty nicht schreiben will

Link zu diesem Artikel

Vor kurzem erhielt ich bei der Installation einer PHP-Web-Applikation folgende Fehlermeldung in die error.log geschrieben:

[client 0.0.0.0] PHP Warning:  Smarty error: problem creating directory "/var/webs/smarty/templates_c/%%778/%%778656331" in /var/webs/smarty/Smarty.class.php on line 589, referer: http://www.server.tld/
[client 0.0.0.0] PHP Warning:  Smarty error: problem writing '/var/webs/smarty/templates_c/%%778/%%778656331/error.tpl.php.' in /var/webs/smarty/Smarty.class.php on line 589, referer: http://www.server.tld/

Obwohl ich die Berechtigungen des übergeordneten Verzeichnisses auf rwxrwxrwx (chmod 777) gesetzt hatte, weigerte sich Smarty resp. PHP, einen neuen Unterordner zu erstellen.

Nach einigen Pröbeleien und Google-Suchen fand ich dann doch noch eine einleuchte Antwort auf die Ursache des Problems:

A: This is the problem with your hosting provider. The directories which are created by php modules, have 644 permissions by default. You cannot fix it.

Quelle: Smarty error

Am selben Ort ist ein Workaround beschrieben. Man bearbeite inc/smarty.inc.php und ändere folgende Konfigurationsvariable:

$this->use_sub_dirs = false;

Voilà! Nun funkioniert auch UCCASS 1.8.1 auf meinem Server.

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 27. April 2007

mysqlhotcopy streikt

Link zu diesem Artikel

Seit einiger Zeit sichere ich die Datenbanktabellen auf meinem Entwicklungsserver (Debian) jeden Abend mit dem Perl-Script mysqlhotcopy. Einerseits beuge ich so einem Datenverlust vor, wenn ich für ein neues Projekt die Nacht durchgecodet habe und am nächsten Tag dummerweise DROP database ausführe, andererseits wenn Partyguide wieder einmal versuchen sollte, die Datenbank vollzuspammen.

Seit dem letzten

apt-get upgrade

spinnt die Routine leider und produziert folgende Fehlermeldungen:

Invalid db.table name 'mysql.mysql`.`columns_priv' at
usr/local/mysql/current/bin/mysqlhotcopy line 855.

Quelle: mysqlhotcopy dies with error Invalid db.table name ‚foo.bar`.`baz‘

Das Problem taucht mit dem Upgrad auf DBD::mysql 4.003 auf. Da ich in der Eile nicht herausfinden konnte, wie ich dieses Package downgrade, habe ich mysqlhotcopy folgendermassen gepatcht:

...
my @dbh_tables = eval { $dbh->tables() };
map { s/^.*?\.//o } @dbh_tables;

## Remove quotes around table names
...

Quelle: mysqlhotcopy dies with error Invalid db.table name ‚foo.bar`.`baz‘

Nun läuft das Backup wieder sorgenfrei.

Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 14. April 2007

Linux und micro&soft

Link zu diesem Artikel

Mootabolife: You can clearly see that Linux has a smaller user base.

idonthack: No, Microsoft’s products are just more bloated.

Quelle: PICTURE: Microsoft & Linux together at last.

Und das beste kommt erst noch: Beides sind ureigene Schweizer-Produkte! Vergesst das Silicon Valley, das Silicon Gallen is the place to be …

Tags:
Labels: Funny, Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 30. März 2007

APC Smart-UPS SUA750I mit cacti aufzeichnen

Link zu diesem Artikel


APC Smart-UPS SUA750I
Originally uploaded by emeidi.

Gestern ist sie eingetroffen, meine neue, übergrosse Batterie (APC Smart-UPS SUA750I), die meinen Server sowie die sich am gleichen Ort befindlichen Breitband-Geräte in Zukunft vor kurzen Stromausfällen oder Sicherungen beschützen soll.

Vor diesem Neugerät hatte ich einige Monate lang eine APC Smart-UPS 1400 in Betrieb, doch bei mehreren Ernstfällen verweigerte die Batterie ihren Dienst. Entweder hätte ich für mindestens 200 Stutz die Batterie wechseln oder aber für etwas mehr Geld ein Neugerät mit allem Drum und Dran, inklusive Garantie, anschaffen können. Ich entschied mich für letzteres.

Erste Tests liefen völlig zufriedenstellend – das Stromkabel ausziehen: Der Server surrt weiter vor sich hin, die LEDs des Router und des Kabelmodems blinken weiter unablässig. Ziel erreicht. In den letzten Wochen war das nicht mehr so gewiss – wurde die USV vom Stromnetz getrennt, verstummten alle Geräte blitzartig.

Kontrolle muss sein

Damit auch das Herz des Kontrollfreaks höher schlägt, werden zwei – aus meiner Sicht – wichtige Parameter der USV von meinem Linux-Server aufgezeichnet: Temperatur sowie die „Load Percentage“. Dank apcupsd, einem OSS-Ersatz für die offizielle PowerChute-Software, und dem darin enthaltenen Tool apcaccess ist das alles kein Problem.

Folgendes Script liefert die zwei Zahlen zur einfachen Integration in cacti:

#!/bin/sh

ITEMP=`apcaccess | grep ITEMP | cut -d ":" -f 2 | cut -d " " -f 2`
LOADPCT=`apcaccess | grep LOADPCT | cut -d ":" -f 2 | cut -d " " -f 3`
LINEV=`apcaccess | grep "^LINEV" | cut -d ":" -f 2 | cut -d " " -f 2`

echo ITEMP:$ITEMP LOADPCT:$LOADPCT LINEV:$LINEV >> /var/log/apcupsd.temp

exit 0

Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 18. März 2007

Microsoft-freies Datencenter

Link zu diesem Artikel

You’re up against a formidable competitor and one you’ve never seen before that has some real, significant weapons that you can’t deal with (and YouTube isn’t even close to it). Google’s secret weapon? It controls the entire stack in the datacenter. Google writes its own hard disk drivers. It has its datacenter hardware built to its spec. Ever wonder why Live.com is slower than Google? Hint: it’s cause Google is out executing Microsoft in the datacenter.

Quelle: Microsoft tells MVPs “we’re in it to win” — Really?

Der Kampf Windows gegen Linux scheint im Stellvertreterkrieg „Suchmaschinentechnologie“ längst entschieden.

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 17. März 2007

Gigabit-Netzwerk testen

Link zu diesem Artikel

Man bemächtige sich iperf und lasse dann einige Tests laufen:

Server

In meinem Fall Debian mit Kernel 2.6.18-4-686; Intel PWLA8391GT und Intel Pentium III 600MHz:

ALPHA:/tmp# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------

Client

In meinem Fall Mac OS X 10.3.9; Gigabit-Ethernet (Chipsatz unbekannt) und PowerPC G5 2x 1.8GHz:

beta:~/Desktop mario$ ./iperf -c 192.168.0.101
------------------------------------------------------------
Client connecting to 192.168.0.101, TCP port 5001
TCP window size: 65.0 KByte (default)
------------------------------------------------------------

Resultate

[  4] local 192.168.0.101 port 5001 connected with 192.168.0.102 port 49664
[  4]  0.0-10.0 sec    431 MBytes    361 Mbits/sec
[  5] local 192.168.0.101 port 5001 connected with 192.168.0.102 port 49665
[  5]  0.0-10.0 sec    349 MBytes    293 Mbits/sec
[  4] local 192.168.0.101 port 5001 connected with 192.168.0.102 port 49666
[  4]  0.0-10.0 sec    410 MBytes    343 Mbits/sec

Wow – schneller als das Licht!

Tags:
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 16. März 2007

Gigabit Ethernet mit Debian

Link zu diesem Artikel

Dass ich heute Freitag morgen etwas müde aus der Wäsche geguckt habe, hängt einerseits mit den 1. Schweizerischen Geschichtstagen zusammen, die derzeit in Bern stattfinden. Andererseits aber auch, weil gestern digitec endlich das heissersehnte Päckchen geliefert hat.

Komponenten

Dessen Inhalt:

Fallstrick ethX

Im Server werkelte bisher eine dieser „tubelisicheren“ 3Com-Karten, für die Linux wohl seit Ewigkeiten Treiber-Support mitbringt. Deren Dienstpflicht war nun zu Ende und sie wurde zwecks Antritt des Ruhestands ausgebaut. In denselben Slot steckte ich nun die Gigabit-NIC.

Der erste Boot-Vorgang mit der neuen Ethernet-Karte verlief zu Beginn völlig reibungslos – mit dem mit Ctrl-S zu erreichenden Konfigurations-Menu schaltete ich die PXE-Funktion aus und sparte so ca. 10-20 Sekunden, die für die Suche nach einem DHCP-Server draufgingen.

Als jedoch Linux die Kontrolle übernahm, klappte dagegen nicht alles sauber. Zwar wurde das für den Betrieb der Netzwerkkarte nötige Modul e1000 anstandslos geladen – im Laufe des Boot-Prozesses stachen mir aber einige FATAL-Meldungen ins Gesicht, die sich auf eth0 respektive e1000 bezogen („could not set device flags“ oder ähnlich). Was zum Teufel?

Jedenfalls hatte ich keine aktive Netzwerkverbindung zur Verfügung, und ifconfig zeigte kein schönes Bild:

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:323240 errors:0 dropped:0 overruns:0 frame:0
          TX packets:323240 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:226873684 (216.3 MiB)  TX bytes:226873684 (216.3 MiB)

(Ersatz-Ausgabe nach 24h Betrieb). Wo blieb eth0?

Nach einer ca. 30 Minuten dauernden Schrecksekunde, die auch unzählige Google-Suchen beinhaltete, fand ich die Lösung dann eher unerwartet, als ich folgenden Befehl eingab:

ifconfig -a

Dort wurde eth1 erwähnt, eth0 fehlte hingegen. Wieso das so ist, kann ich mir immer noch nicht erklären. Entweder hat Linux die Identifikation der Vorgänger-Karte gespeichert und vergibt neuen Karten eine fortlaufende Nummer, oder irgendwas ist mit dieser NIC anders. Ich weiss es nicht.

Jedenfalls genügte es nun, eth0 in /etc/network/interfaces mit eth1 zu ersetzen. Nach dem nächsten Reboot funktionierte die Karte endlich.

Fallstrick Patchkabel

ALPHA kernel: e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex

Was’n löus? Wieso nur 100 Mbps, wenn ich doch soeben viel Geld für ein Gigabit-Netzwerk ausgegeben hatte?

Meine erste Vermutung erwies sich dieses eine Mal als goldrichtig: Das ca. 2001 mit dem Kauf eines Wireless-Access-Points (Elsa/Lancom L-11) mitgelieferte Patch-Kabel erfüllte die Qualitätsanforderungen an ein Gigabit-Netzwerkkabel nicht (mind. Cat 5e – hier wohl Cat 5). Nachdem ich dieses Kabel entfernt und mit einem neueren Modell ersetzt hatte, hiess es nun endlich:

ALPHA kernel: e1000: eth1: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex

Durchsatz?

Folgender Test führte ich aus „Gwunder“ durch, um den Durchsatz zu messen:

BETA:/Volumes/INCOMING/KNOPPIX mario$ time cp KNOPPIX_V5.1.1CD-2007-01-04-EN.iso /Volumes/Multimedia/Software/

real    0m39.920s
user    0m0.040s
sys     0m6.730s

40 Sekunden für ein knapp 700MB grosses File? Das ergibt 17.5MB pro Sekunde oder 140Mbit/s. Freude herrscht!

Doch wieso? Die errechnete Zahl ist ja meilenweit von 1000Mbit/s weg … Ja, schon, aber:

  1. Das CIFS/SMB-Protokoll ist nicht gerade bekannt dafür zu sein, besonders performant zu laufen (die Datei wurde von einem unter Mac OS X gemounteten Samba-Share auf die lokale Festplatte kopiert)
  2. Auch wenn es sich um eine Intel-Netzwerkkarte handelt – im Vergleich zu einer PWLA8490MT muss wohl irgendwo gespart worden sein. Ich betrachte die im Einsatz befindliche Karte als Consumer-Variante.
  3. Dasselbe gilt wohl für den Netzwerk-Chipsatz im PowerMac G5
  4. Auch der Zyxel-Switch GS-105A ist ein Consumer-Gerät, von dem nicht Spitzenleistungen erwartet werden dürfen
  5. Die Festplatten im Quellsystem (ATA100, RAID10) sowie die SATA im Zielsystem sind wohl die Bottlenecks
  6. Jumbo-Frames sind keine im Einsatz – Mac OS X erlaubt diese Option nur bei den Xserves

Wie dem auch sei – der Geschwindigkeitsgewinn ist bereits jetzt äusserst spürbar und ich habe absolut keinen Grund für Wehklagen.

Tags:
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

« Older Entries
Newer Entries »