Archiv ‘Linux’

Samstag, 14. August 2010

E-Mails mit imapfilter serverseitig ablegen

Seit vielen Jahren verwende ich das IMAP-Protokoll zum Zugriff auf alle meine Mail-Adressen. Doch leider nimmt die Mailflut immer mehr zu, und das stört.

Bis zum heutigen Tag habe ich mich „Regeln“ in Apple Mail beholfen, um Mails beim Eintreffen in die entsprechenden Unterordner abzulegen. Seit ich aber einen Laptop und ein iPhone besitze und zunehmend auch unterwegs Mails abrufe, wäre es äusserst nützlich, wenn ich eingehende Mails vollständig automatisch serverseitig vorsortieren und in Unterordner ablegen könnte.

Bisher war ich dazu genötigt, die Regeln von Apple Mail auf meiner Workstation zu Hause auf den Laptop zu übertragen. Immer wieder habe ich mir dabei vorgenommen, diese Redundanz aufzuheben. Heute ist es nun soweit!

Was tun? Wer einen dedizierten Mailserver im Keller stehen hat, wird sich auf procmail-Scripts stützen (ich habe auch schon darüber berichtet), die eingehende E-Mails nach bestimmten Kriterien in Unterordner verschieben. Dies ist für mich keine Option, weil mein von Genotec betriebener Mailserver keinen Shellzugriff bietet. Auch bietet der Hoster keine anständige Möglichkeit an, serverbasierte Filter einzurichten.

Heute nun bin ich via einer diesbezüglichen Frage auf der Community Serverfault auf imapfilter gestossen.

Installation

Zuerst installiert man sich das Paket unter Debian auf einem ans Internet angeschlossenen Server, der nonstopp läuft:

apt-get install imapfilter

Filterregeln erstellen

Anschliessend schreibt man sich mit der Sprache Lua (vgl. die Beispiele Rotating email into your inbox using imapfilter sowie sample.config.lua.txt) entsprechende Filter-Rezepte und legt diese nach einem chmod 600 * im Homefolder beispielsweise unter ~/.imapfilter/filter/ ab.

Nachfolgend ein solches „Rezept“ für einen meiner Mailkonti:

mbox = IMAP {
    server = 'mail.server.tld',
    username = 'user@domain.com',
    password = '********',
    ssl = 'ssl3'
}

-- Facebook
messages = mbox.INBOX:contain_from('facebookmail.com')
messages:move_messages(mbox['Facebook'])

...

-- AHC
messages = mbox.INBOX:contain_field('List-ID','gi-ch.googlegroups.com')
messages:move_messages(mbox['AHC'])

...

Wie man anhand dieses Beispiel sieht, kann man jedes beliebige Feld des Mail-Headers auswerten. Als Hilfe für alle verfügbaren contain_X-Befehle sei auf die Dokumentation unter imapfilter_config – imapfilter configuration file verwiesen. Es gibt auch noch andere Befehle, die es ermöglichen, noch deutlich feingranuliertere Regeln zu programmieren.

Hat man wie ich mehrere Mail-Konti, die abgegrast werden sollen, erstellt man entsprechende Filter für jedes Konto und legt diese im selben Ordner unter einem aussagekräftigen Namen ab.

Shell-Script schreiben

Damit man diese nun alle auf’s Mal durchackern lassen kann, empfiehlt sich, ein kleines Shell-Script zu schreiben:

#!/bin/sh

IMAPFILTER=`which imapfilter`
RECIPESROOT="~/.imapfilter/filter"

cd $RECIPESROOT

for RECIPE in *
do
        #echo "Running $IMAPFILTER -c '$RECIPESROOT/$RECIPE'"
        $IMAPFILTER -c "$RECIPESROOT/$RECIPE"
done

exit 0

Cron-Job einrichten

Anschliessend richtet man einen Cron-Job ein, der die Mailserver beispielsweise alle 5 Minuten nach neuen Nachrichten abfragt und je nachdem die Filterregeln anwendet:

*/5 * * * *	/usr/local/bin/imapfilter.sh

Fertig ist der kostenlose, transparente Filterservice für eingehende Mails.

Tags: , , ,
Labels: Linux

3 Kommentare | neuen Kommentar verfassen

Mittwoch, 28. Juli 2010

Debian GNU Linux auf „dependency-based boot system“ umstellen

Seit einigen Wochen offeriert mir Debian bei jedem apt-get dist-upgrade, mein System auf ein abhängigkeitsbasiertes Bootsystem („dependency-based boot system“) umzustellen.

Störrische Pakete

Leider ist dies bisher jedesmal gescheitert, weil folgende init.d-Skripte die Umstellung verhindert haben:

'libdevmapper1.02' missing LSB tags and overrides, 
'iptables' missing LSB tags and overrides, 
'xfree86-common' missing LSB tags and overrides, 
's3sqld.init' missing LSB tags and overrides, 
'libdevmapper1.00' missing LSB tags and overrides, 
'dhcp' missing LSB tags and overrides, 
'raid2' missing LSB tags and overrides, 
'rendezvous' missing LSB tags and overrides,

Gestern habe ich mir nun endlich die Mühe genommen, mein System zu durchforsten, aufzuräumen und auf die neue Boot-Methode umzustellen. Wie es sich herausstellte, war es doch nicht so kompliziert, wie ich es befürchtet hatte.

Generisches Vorgehen

Zuallererst ist zu überprüfen, ob das bemängelte Script tatsächlich noch vom System benötigt wird oder ob es bei einem apt-get remove <package> versehentlich zurückgelassen wurde.

Als erstes sucht man deshalb auf packages.debian.org mit der Suchfunktion unter „Search the contents of packages“ nach der entsprechenden Datei. Kann diese in keinem aktuellen Paket gefunden werden, ist es wahrscheinlich, dass es sich um ein Überbleibsel handelt. Zur Sicherheit kann man mittels dpkg --list | grep <vermutetes package> überprüfen, ob das Paket tatsächlich vor langer Zeit entfernt wurde (rc steht in diesem Fall zu Beginn der Zeile).

Wird die Datei hingegen irgendwo gefunden, muss man mittels Google herausfinden, ob und wie das init-Skript von Hand angepasst werden kann, um die geforderten „LSB tags“ und „overrides“ eingepflegt zu erhalten.

Konkretes Vorgehen

Konkret sah das Prozedere bei mir folgendermassen aus (Achtung: Sicherheitskopien sind ratsam, um notfalls nicht das gesamte System zu zerschiessen):

  • libdevmapper1.02 wird benötigt. Das Skript muss mit der Anleitung von Bug#361358: marked as done (libdevmapper1.02: Please add LSB formatted dependency info in init.d script) angepasst werden
  • libdevmapper1.00 Überrest, kann gelöscht werden (apt-get remove libdevmapper1.00), da eine neuere Version dieses Pakets auf dem System installiert ist (s. oben)
  • iptables Überrest, kann gelöscht werden (rm /etc/init.d/iptables) — auch wenn es der Package-Maintainer aus Rückwärtskompatibilität dort belassen möchte: „The script was dropped from the package ages ago. Unfortunately, removing it would have been problematic, so it’s just a vestige.“
  • xfree86-common Überrest, kann (in meinem Fall!) gelöscht werden, da dpkg --list | grep xfree meldet: rc xfree86-common 6.9.0.dfsg.1-6
  • s3sqld.init Überrest einer Testinstallation des unbrauchbaren Seco Backups. Kann gelöscht werden.
  • dhcp Es handelt sich hierbei um ein hoffnungslos veraltetes Paket, das aus Sicherheitsgründen umgehend ersetzt werden sollte: apt-get install dhcp3-server Die DHCP-Konfiguration in /etc/dhcp3/dhcpd.conf muss dabei glücklicherweise nicht angepasst werden.
  • raid2 Überrest (?), verweist auf nicht mehr vorhandene raidstart etc. und kann deshalb gelöscht werden.
  • rendezvous Überrest, das Paket wird auf dem Debian-Server nicht mehr gefunden. Das Paket kann entfernt werden: apt-get remove rendezvous. Je nachdem muss man vorher noch einen in der Zwischenzeit gelöschten Benutzer daapd erstellen, der dann von der Deinstallationsroutine gleich wieder entfernt wird.
  • initrd-tools.sh Bei der Suche nach dieser Datei im Debian Package-Archiv wurde kein Paket zurückgeliefert, welches dieses Script auf dem System installieren würde. Ich habe diese Datei deshalb kurzerhand gelöscht.

Endlich den Schalter umlegen …

Schlussendlich kann man die Boot-Methode nun umstellen:

# dpkg-reconfigure sysv-rc
info: Checking if it is safe to convert to dependency based boot.
info: Reordering boot system, log to /var/lib/insserv/run-20100727T1330.log
success: Enabled dependency based boot system.

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 5. April 2010

Wenn man sich mit denyhosts.py selber aussperrt …

… ist es an der Zeit, in der Datei /etc/hosts.allow endlich folgenden Eintrag anzufügen:

...
sshd: 192.168.0.2
...

Wobei hier natürlich anstelle von 192.168.0.2 die IP-Adresse angegeben werden sollte, die der Client (also die Workstation, von welcher man sich per SSH auf den Server verbindet) trägt.

Via: Debian Linux Stop SSH User Hacking / Cracking Attacks with DenyHosts Software

Tags:
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 13. Dezember 2009

Erfahrungen bei einem Server-Upgrade

Gestern um 20:00 begann ich damit, meinen Heimserver dem grössten Upgrade in seiner Geschichte zu unterziehen. Zwei Gründe bewegten mich zu diesem Entscheid: Einerseits war das Gerät längst betagt und mittlerweile äusserst schwach auf der Brust. Andererseits kämpfe ich seit dem Sommer 2009 sporadisch mit „Black Screens Of Death“, welche nur mit einem Reset zu beheben waren. Natürlich machen solche Ausfälle bei einem eigentlich 24/7 verfügbaren Server keinen Sinn. Leider brachte die Fehlersuche über Monate hinweg keine Ursache zu Tage. Vermutlich lag es an der Altersschwäche eines Bauteils.

Was hat sich in der Hardware geändert?

Server alt

  • Yeong Yang YY-B0221 (spezielles Server-Gehäuse mit zwei Abteilen für Motherboard und Laufwerke)
  • Intel Pentium III, 600 MHz
  • Asus P3B-F
  • 4x Kingston 256 MB, SDRAM, PC100 — KVR133X64C3/256
  • Matrox Millennium G200, AGP
  • Intel PWLA8391GT, PCI, Gigabit-Ethernet
  • Adaptec AHA-2940U2W, SCSI-Controller
  • 1x Fujitsu MAJ3182MP, 18.2 GB, U2W-SCSI — System
  • FirmTek SeriTek/1S2, SiL 3112, SATA-Controller
  • 1x Maxtor , 160 GB, SATA — /var
  • 2x Promise Ultra 133 TX2
  • 4x Samsung SP2514N, 250 GB, ATA-7 (RAID1+0) — Storage

Server neu

  • Yeong Yang YY-B0221 (spezielles Server-Gehäuse mit zwei Abteilen für Motherboard und Laufwerke)
  • Intel Core 2 Duo E5400, Dual Core 2.7 GHz, 800 MHz
  • Asus P5QPL-VM-EPU, Mini-ATX
  • 1x Apacer 1 GB, DDR2, 800 MHz
  • Intel PWLA8391GT, PCI, Gigabit-Ethernet
  • 1x Samsung HD161GJ, 160 GB, SATA-3 — System
  • 2x Samsung HD154UI, 1.5 TB, SATA-3 (RAID1) — Storage

Erfahrungshäppchen

  • Grundsätzlich sei wieder einmal zu erwähnen, dass man ein solch tiefgreifendes Hardware-Update unter Windows schlichtwegs hätte vergessen können; um eine Neuinstallation wäre man auf Grund der komplett anderen Hardware nicht herumgekommen. Ich lobe mir deshalb Debian GNU/Linux, welches — zwar auch mit einiger (selbstverursachter) Müh und Not — nach einigen Anpassungen anstandslos unter der neuen Hardware bootete.
  • Durch die Vereinfachung der Storage-Infrastruktur (Wegfall von 3 Platten und 4 Controllern) sank die Stromaufnahme um 5 %, obwohl anzunehmen ist, dass CPU und Motherboard mehr Energie benötigen als die Komponenten des alten Servers.
  • Dass im Server-Gehäuse nun nur noch 3 statt 6 Festplatten hängen, erlaubt mir, diese deutlich effizienter zu kühlen. Auch das Betriebsgeräusch des Servers ist aus meiner Empfindung etwas leiser geworden.
  • Das Motherboard weist einen sog. EATXPWR-Connector auf. Auf den ersten Blick befürchtete ich, am Sonntag noch ein neues Netzteil kaufen zu können. Steckt man den Stromstecker eines normalen ATX-Netzteils ein, sind vier Pins des neuen Steckers nicht belegt. Das Board startet trotzdem — wenn man den zusätzlichen 4-pin 12V-Anschluss in der Nähe des Prozessors mit dem entsprechenden Kabel des Netzteils bestückt. Der Betrieb ist also durchaus möglich — entweder mit 20-pin ATX + 4-pin ATX 12V oder 24-pin EATXPWR.
  • Aus ISO-Images von Ubuntu einen bootbaren USB-Stick zu bauen, ist unter Mac OS X nicht möglich. Es wird vielerorts empfohlen, stattdessen die IMG-Datei des Ubuntu Netbook Remix herunterzuladen, ohne aber auf eine solche Datei zu verlinken. Diese gibt es nämlich nur für das ältere Ubuntu 9.04 (aktuell: 9.10); bspw. auf dem SWITCH-Mirror: ubuntu-9.04-netbook-remix-i386.img. Mit diesem Image soll es anschliessend gemäss Anleitungen im Netz möglich sein, unter Mac OS X mit dem Terminal den Stick mit Ubuntu bootbar zu machen.
  • Da der Download dieser Datei ein gute Stunde dauerte, habe ich schlussendlich einen alten DVD-Brenner im Server verbaut und den Server von CD gebootet.
  • Bei der Partitionierung der neuen 160 GB-Systemplatte mit fdisk unter Ubuntu Live-CD habe ich bei der Grössenangabe für die einzelnen Partitionen vergessen, ein + voranzustellen (Bspw. +512M für eine Partition mit 512 MB Platz). Deshalb ist meine /boot-Partition nun nicht 512 MB gross, sondern 3.1 GB *autsch*
  • Um den Swap-Space zu initialisieren, benutzte ich mkswap, was beim ersten Anlauf aber enorm viel CPU-Resourcen benötigte und nicht vor dem Ende meiner Geduld abgeschlossen werden konnte. Indem ich dieses Executable ohne den Paramenter -c (für „check“) aufrief, rauschte die SWAP-Formatierung wie im Schnellzugstempo durch.
  • Nachdem ich die Daten von der alten SCSI-Systemplatte auf die SATA-Systemplatte kopiert hatte (der Adaptec AHA-2940U2W SCSI-Controller und die daran hängende Platte wurde vom Board und Ubuntu problemlos erkannt), startete der Rechner nicht, weil GRUB einen „Error 2“ meldete. Ich war mir ganz sicher, dass ich den Bootsektor in die richtige Platte geschrieben und mit hd(0,0) auch garantiert die richtige Platte konfiguriert hatte. Wo also lag das Problem? Dank eines Blog-Artikels GRUB „Error 2“ May Mean Incompatible stage1.5, stage2, and ext2 kam ich darauf, dass ich die Platte mit einem brandneuen mkfs.ext3 formatiert, dann aber die GRUB-Stages 1.5 und 2 datierend aus dem 2007 von der alten Platte in den Bootsektor geschrieben hatte. Glücklicherweise fanden sich unter /usr/lib/grub/i386-pc/ neuere Dateien im leicht grösseren Umfang und aus dem Jahr 2009. Nachdem ich diese Dateien über /boot/grub kopiert und den MBR neu geschrieben hatte, funktionierte der Bootvorgang dann endlich wie geschmiert.
  • Nachdem das System zum ersten Mal in der neuen Konfiguration ohne fremde Hilfe hochgekommen war (nicht vergessen: /etc/fstab und /boot/grub/menu.list müssen zwingend angepasst werden!), ging es nun darum, /var von der alten SATA-Platte rüberzukopieren. Wie bei allen Kopieraktionen verwende ich dazu # rsync -av . /mnt/sda1 oder dergleichen. Bricht der Kopiervorgang aus unerfindlichen Gründen ab, stellt man mit rsync sicher, dass nur diejenigen Dateien kopiert werden, die auf dem Zielsystem noch nicht identisch vorhanden sind. Auch werden die Benutzer und Rechte auf jeden Fall mitkopiert.
  • Die Daten vom RAID1+0 kopierte ich heute Sonntag-Nachmittag auf das neu erstellte RAID1. Damit ich die Daten nicht über das langsame Ethernet-Netzwerk kopieren musste, suchte ich mir zwei exteren USB-Festplattengehäuse und wählte dann zwei Festplatten des RAID-Verbundes aus. Wichtig ist bei RAID1+0 natürlich, dass man die zwei komplementären Platten nimmt, die im Degraded-Modus das ganze Volume herstellen. Damit mdadm die Platten erkannte, musste ich in /etc/mdadm/mdadm.conf einige Ergänzungen vornehmen, weil der verschachtelte RAID-Verbund nicht automatisch erkannt wurde. Kernstück waren dabei folgende Zeilen:
    ...
    DEVICE partitions
    ...
    ARRAY /dev/md10 metadata=0.90 UUID=8b74168f:921d62ec:197e72a9:dcc396dd
    ARRAY /dev/md11 metadata=0.90 UUID=c7acb783:7d200806:ba3b0bb9:fba14ed1
    ARRAY /dev/md1 metadata=0.90 UUID=0b0b49d4:63eada39:e2d889b1:01493278

    Die UUIDs waren glücklicherweise in der alten mdadm.conf hinterlegt. Sie sind unbedingt zu notieren und an einem sicheren Ort aufzubewahren. Anschliessend klappte es problemlos, die RAID-Arrays mittels # mdadm --assemble /dev/md0 etc. zu starten (natürlich in der richtigen Reihenfolge, d.h. /dev/md1 am Schluss, wenn die RAIDs der beiden USB-Platten gestartet wurden. Ob metadata=0.90 wirklich nötig ist, weiss ich nicht. Als ein Array nur im auto-read-only-Modus gestartet wurde, führte ich folgenden Befehl aus, um auch Schreibvorgänge zu ermöglichen (im Grund ja unnötig, da wir nur Daten ab der Platte kopieren wollen):

    # mdadm --readwrite /dev/md10
  • Der anschliessende Kopiervorgang war einerseits ein Burn-In-Test für die verschiedenen Bussysteme des neuen Servers (USB, SATA), andererseits zeigte er die Performance der neuen Hardware:
    sent 460359385722 bytes  received 762070 bytes  38412962.39 bytes/sec
    total size is 460300401834  speedup is 1.00

    — 38 MB/Sekunde sind kein schlechter Wert für ATA-7 über USB auf SATA.

  • Da das neue Board nur noch die Pins für einen LPT-Anschluss mitbringt, musste ich meinen HP Laserjet 1300 neu über USB an den Server anschliessen. Leider wurde dabei aber /dev/usb/lp0 nicht automatisch erstellt. Nach einem # apt-get dist-upgrade erschien dieses Device plötzlich in der Dateiliste. Nur noch /etc/printcap anpassen (statt /dev/lp0 ist es neu /dev/usb/lp0 — fertig!). Auf jeden Fall lud der Kernel alle benötigten Module (usblp, usbcore und uhci_hcd). Dass der Drucker auch wirklich da ist, erkennt man mit dem Befehl:
    # lsusb
    ...
    Bus 002 Device 002: ID 03f0:1017 Hewlett-Packard LaserJet 1300
    ...

    Dieser Befehl findet sich im Paket usbutils

  • Bei Aufräumarbeiten in meinem IT-Ersatzteillager fand ich zufälligerweise ein Slotblech, welches zwei serielle Ports (COM1 & COM2) bereitstellte. Da das neue Board Pins für eine COM-Schnittstelle mitbringt, konnte ich so die ältere USV (APC 1400VA) wieder am Server anschliessen.

Labels: IT, Linux

1 Kommentar | neuen Kommentar verfassen

Sonntag, 13. September 2009

Druckaufträge von der Kommandozeile aus verwalten

Gerade würgt sich mein HP Laserjet 1300 – immerhin ein Postscript-Drucker mit einem RAM-Upgrade – durch einen Druckauftrag, den ich aus Adobe Acrobat 9 ausgelöst habe. Da für den Druck einer Seite etwa 10 Minuten vergehen (!), wurde mir die Sache zu blöd und ich suchte nach Möglichkeiten, den Druckauftrag zu löschen.

Da er unter Mac OS X bereits an den Druckerserver raus ist, muss ich Linux und lprng bemühen. Wie es sich herausgestellt hat, ist die Verwaltung von Druckjobs äusserst simpel – wenn man denn weiss, wie:

Druckerwarteschlange anzeigen

# lpq -Plaserdrucker
Printer: Laserdrucker@ALPHA 'HP Laserjet 1300'
 Queue: 2 printable jobs
 Server: pid 26486 active
 Unspooler: pid 26487 active
 Status: waiting for subserver to exit at 00:51:43.257
 Rank   Owner/ID               Pr/Class Job Files                 Size Time
stalled(672sec) mario@beta+327      A   327 657247.pdf        19804211 00:41:08
2      mario@beta+514               A   514 657247.pdf         8249902 00:47:05
done   mario@beta+970               A   970 studium:glossar-fra 326256 16:17:30

19804211 Bytes? 19 MB sind viel, kommen aber offensichtlich hin, denn ich drucke einen 18-seitigen Scan eines Artikels, den ich auf JSTOR gefunden habe.

Druckauftrag löschen

Um einen Druckauftrag in der Warteschlange zu löschen, muss man sich die Zahl unter Job merken und gibt anschliessend auf der Kommandozeile folgendes ein:

lprm -Plaserdrucker 327
Printer Laserdrucker@ALPHA:
  checking perms 'mario@beta+327'
  dequeued 'mario@beta+327'

Quelle: In Unix, how do I print files and list or remove print jobs?

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 4. September 2009

Lonely Planet Pick&Mix respektive Base64 dekodieren

Gestern habe ich bei Lonely Planet drei PDFs über Togo, Burkina Faso und Ghana bestellt. Obwohl ich West Africa bereits als Hardcopy im Regal stehen habe, sind diese ziegelsteingrossen und -schweren Reiseführer nunmal einfach nicht bequem, um sie mit auf Backpacking-Reisen zu nehmen.

Zwei Lösungen gibt es für das Problem: Eine Bekannte, die ich im Februar in Indien kennengelernt habe, reisst sich die Seiten vor ihren Reisen kapitelweise aus dem Reiseführer. So geht sie sicher, dass sie nur das nötigste mit dabei hat und dies äusserst handlich irgendwo verstauen kann. Mir aber widerstrebt es, Reiseführer einfach so zu „zerreissen“, weshalb ich die zweite, deutlich fortschrittlichere Lösung bevorzuge: Pick&Mix – Lonely Planet-Kapitel in Form von PDFs. Kein Passwortschutz, keine Restriktionen bezüglich Druck. Und zudem spottbillig (das grösste Kapitel – Ghana – hat mich 2.47 EUR gekostet).

Lonely Planet hat erkannt, dass man es den potentiellen Kunden äusserst einfach machen muss, damit sie das neue digitale Produkt in Scharen kaufen – kein DRM und auch keine Paranoia, dass die Kapitel alsbald auf Tauschbörsen auftauchen (obwohl, ein Wasserzeichen könnte ja wohl kaum Schaden). Während die Musikindustrie Jahre benötigte, um sich zu Downloads im weltweit anerkannten MP3-Standard durchzuringen, scheint der Prozess bei Lonely Planet deutlich simpler abgelaufen zu sein.

Item. Heute bekam ich nun ein kurliges Mail von einem Shop Batch User <support@lonelyplanet.com.au>, welches wiederum ein Mail enthielt. Doch im Grossen und Ganzen sah das Layout nicht wirklich überzeugend aus – da musste etwas schief gelaufen sein!


Lonely Planet SAP Fail
Originally uploaded by emeidi


Ein Blick in den Quelltext des E-Mails (unter Apples Mail.app mittels Apfel+Alt+U) zeigte zweierlei:

  • X-Mailer: SAP Web Application Server 6.20 – Das erklärt wohl alles. SAP hat einfach das Internet und das Web immer noch nicht begriffen.
  • Ein Wust von kryptischen Zeichen
    JVBERi0xLjMNCiXi48/TDQoyIDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnREZXNjcmlwdG9yDQovQXNj
    ZW50IDcyMA0KL0NhcEhlaWdodCA2NjANCi9EZXNjZW50IC0yNzANCi9GbGFncyAzMg0KL0ZvbnRC
    Qm94IFstMTc3IC0yNjkgMTEyMyA4NjZdDQovRm9udE5hbWUgL0hlbHZldGljYS1Cb2xkDQovSXRh
    bGljQW5nbGUgMA0KL1N0ZW1WIDEwNQ0KPj4NCmVuZG9iag0KMyAwIG9iag0KL1dpbkFuc2lFbmNv ...

Glücklicherweise war es mit dem Hinweis auf Content-Transfer-Encoding: base64 äusserst simpel, das encodierte Attachment wieder in eine richtige Datei umzuwandeln. Zuerst kopierte ich den ganzen Textwust in eine Textdatei und speicherte diese als lonely.b64 ab.

Anschliessend machte ich mich auf die Suche nach einem Kommandozeilentool, welches Base64-enkodierte Dateien dekodieren konnte. Dank Google wurde ich mit Base64 umgehend fündig.

Dank MacPorts war das Teil schnell heruntergeladen und kompiliert:

# port install base64

Nun war ich nicht mehr weit von der dekodierten Datei entfernt:

$ base64 -d lonely.b64 lonely.unk

Ein Blick in den Header der Datei zeigte mir klar an, um was für ein Ursprungsformat es sich beim Attachment handelte:

%PDF-1.3
%????
2 0 obj
<<
/Type /FontDescriptor
/Ascent 720
/CapHeight 660
/Descent -270
/Flags 32
/FontBBox [-177 -269 1123 866]
/FontName /Helvetica-Bold
/ItalicAngle 0
/StemV 105
>>
endobj
3 0 obj
...

PDF! Deshalb passte ich die Dateiendung an, und scho sah ich die Tax Invoice von Lonely Planet in Apples Preview.

Tags: , ,
Labels: Linux

2 Kommentare | neuen Kommentar verfassen

Samstag, 8. August 2009

Auf einen Rutsch alle neuen Dateien ins SVN (svn add)

Selbstverständlich kann man sich streiten, eine Dokuwiki ins SVN zu laden, doch da ich die nächste Woche offline in Frankreich verbringen werde, möchte ich einen einfachen Weg haben, um die an der Côte d’Azur erfassten Änderungen einfach in die Serverinstallation zurückzuspielen.

Doch da ich in der Zwischenzeit noch an einigen Zusammenfassungen weitergeschrieben habe, wurde es nötig, dass ca. 20 neu hinzugekommene Dateien noch ins Repository eingecheckt werden sollten. Wie macht man das möglichst einfach?

Ich habe mich für folgenden Befehl entschieden, den ich im root des versionierten Verzeichnisses ausführte:

svn status | grep "^?" | cut -d ? -f 2 | xargs svn add

Ein

svn add *

ginge natürlich auch, spuckt aber hässliche Fehlermeldungen aus.

Habt ihr einen noch effizienteren Tipp?

Tags: , ,
Labels: Linux

2 Kommentare | neuen Kommentar verfassen

Donnerstag, 2. Juli 2009

lprng debuggen

Gerade habe ich eine Stunde mit debuggen von LPRng verbracht, bis ich schlussendlich feststellen musste, dass das angebliche Druckerproblem mit einem Kaltstart des Druckers (!) gelöst werden konnte.

Dennoch ist es für die Nachwelt sicherlich von Interesse, wie man LPRng im speziellen und Druckerprobleme unter Linux im allgemeinen debuggt.

lprng ausschalten

Damit man ungestörten Zugriff auf den Parallelport hat, schaltet man kurzerhand den von Debian automatisch geladenen Druckserver aus:

# /etc/init.d/lprng stop

Module überprüfen

Anschliessend überprüfen wir grundlegend, ob die Parallelporttreiber geladen wurden:

$ lsmod | grep lp
lp                     11076  0 
parport                34280  2 lp,parport_pc

Berechtigungen des Parallelports

$ ls -l /dev/lp0
crw-rw---- 1 root lp 6, 0 2009-07-02 13:07 /dev/lp0

Sieht gut aus. Falls der Port nicht existiert, legt man in anhand einer anderen auf diesem Blog publizierten Anleitung an.

Auf Parallelport drucken

# cat sample.ps > /dev/lp0

ACHTUNG: Drucker, die kein Postscript sprechen (würde ich nie mehr in meinem Leben anschaffen!), werden seitenweise kryptische Codes ausdrucken. Eine Beispieldatei im Postscript-Format findet sich unter samplec.ps

In meinem Fall beendete sich dieser Befehl auch nach 20 Sekunden nicht, weshalb ich ihn mit Ctrl+C von Hand abbrechen musste (ansonsten hat man nach 1-2 Sekunden wieder freie Hand, sofern die Postscript-Datei nicht gerade 50 MB gross ist …). Hier ging mir plötzlich ein Lichtlein auf, dass das Problem wohl nicht am Druckserver selber zu suchen war, sondern irgendwo an oder zwischen dem Drucker und dem Server lag.

lprng debuggen

Wenn bis hierhin alles geklappt hat, muss das Problem wirklich an lprng liegen. Deshalb starten wir den Druckserver im Debug-Modus:

# lpd -F -D1 >&/tmp/lprng.debug &

Ich habe Werte für D von 1, 2 und 9 ausprobiert, hat alles geklappt. In /tmp/lprng.debug werden alle Statusmeldungen akribisch aufgelistet. Anhand dieser ist es im Zusammenspiel mit Google möglich, andere Leidensgenossen zu finden und eventuell sogar die Lösung des Problems präsentiert zu erhalten.

Tags: , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 21. Juni 2009

svn streikt mit "could not connect to server"

$ svn up
svn: OPTIONS of 'http://svn.server.tld': could not connect to server (http://svn.server.tld)

Wer dieses Problem urplötzlich unter Debian mit

$ svn --version
svn, version 1.5.6 (r36142)

zu Gesicht kriegt, das Repository im Web-Browser aber problemlos ansurfen kann, muss als einfachsten Workaround die lokale SVN-Konfiguration anpassen (diejenige des Clients, nicht des Servers!):

/etc/subversion/servers

...
[global]
...
http-library = serf
...

Quelle: svn: OPTIONS of ‚http://…‘: could not connect to server (http://…)

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 20. Juni 2009

Systeminformationen in der Linux-Shell auslesen

Da unser Printserver auf der Arbeit in letzter Zeit oftmals einen ausgereizten Arbeitsspeicher meldet, werde ich heute ein, zwei zusätzliche Riegel RAM installieren gehen. Doch was für Module muss ich in unserem Ersatzteil-Lager suchen? Mit einem SSH-Zugang ist es absolut kein Problem, alle Fragen zu klären:

PCI-Bus auslesen

Zeigt die Chipsets und alle verbauten PCI-Karten an:

$ lspci
00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 04)
00:02.0 VGA compatible controller: Intel Corporation 82815 Chipset Graphics Controller (CGC) (rev 04)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 02)
00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 Controller (rev 02)
00:1f.4 USB Controller: Intel Corporation 82801BA/BAM USB Controller #1 (rev 02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801BA/BAM AC'97 Audio Controller (rev 02)
02:08.0 Ethernet controller: Intel Corporation 82801BA/BAM/CA/CAM Ethernet Controller (rev 01)

CPU-Eigenschaften auslesen

Verbaut ist also ein Pentium III („model name“) mit 1 GHz („cpu MHz“):

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 10
cpu MHz         : 996.828
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse up
bogomips        : 1995.74
clflush size    : 32
power management:

RAM-Typ

Auf das Tool dmidecode bin ich über der Blog-Artikel Linux: Check Ram Speed and Type aufmerksam geworden. Wie die nachfolgende Ausgabe zeigt, ist momentan ein RAM-Baustein verbaut – und zwar ein Riegel SDRAM 133 MHz mit einer Kapazität von 256 MB. Weiter hat es anscheinend noch Platz für zwei weitere Module („Size: No Module Installed“). Um was für Speicher es sich beim letzten Eintrag handelt, weiss ich hingegen nicht.

# dmidecode --type 17
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0x0023, DMI type 17, 27 bytes
Memory Device
        Array Handle: 0x0021
        Error Information Handle: Not Provided
        Total Width: 64 bits
        Data Width: 64 bits
        Size: 256 MB
        Form Factor: DIMM
        Set: None
        Locator: XMM1
        Bank Locator: Not Specified
        Type: SDRAM
        Type Detail: Synchronous
        Speed: 133 MHz (7.5 ns)
        Manufacturer: JEDEC ID:C1 49 4E 46 49 4E 45 4F
        Serial Number: EEC20808
        Asset Tag: Not Specified
        Part Number: HYS64V32300GU-7.5.

Handle 0x0024, DMI type 17, 27 bytes
Memory Device
        Array Handle: 0x0021
        Error Information Handle: Not Provided
        Total Width: Unknown
        Data Width: Unknown
        Size: No Module Installed
        Form Factor: DIMM
        Set: None
        Locator: XMM2
        Bank Locator: Not Specified
        Type: SDRAM
        Type Detail: Synchronous
        Speed: Unknown
        Manufacturer: JEDEC ID:
        Serial Number:  
        Asset Tag: Not Specified
        Part Number:  

Handle 0x0025, DMI type 17, 27 bytes
Memory Device
        Array Handle: 0x0021
        Error Information Handle: Not Provided
        Total Width: Unknown
        Data Width: Unknown
        Size: No Module Installed
        Form Factor: DIMM
        Set: None
        Locator: XMM3
        Bank Locator: Not Specified
        Type: SDRAM
        Type Detail: Synchronous
        Speed: Unknown
        Manufacturer: JEDEC ID:
        Serial Number:  
        Asset Tag: Not Specified
        Part Number:  

Handle 0x0027, DMI type 17, 27 bytes
Memory Device
        Array Handle: 0x0022
        Error Information Handle: Not Provided
        Total Width: 4 bits
        Data Width: 4 bits
        Size: 512 kB
        Form Factor: Chip
        Set: None
        Locator: XU15
        Bank Locator: Not Specified
        Type: Flash
        Type Detail: Non-Volatile
        Speed: Unknown
        Manufacturer: Not Specified
        Serial Number: Not Specified
        Asset Tag: Not Specified
        Part Number: Not Specified

Nachtrag

Wie ich vor Ort feststellen musste, unterstützt Intels 815er Chipset nur maximal 512MB RAM – egal, ob im dritten DIMM-Slot noch 256MB stecken oder nicht …


216-Memory Size Exceeds Maximum Supported
Originally uploaded by emeidi

Tags: , ,
Labels: IT, Linux

3 Kommentare | neuen Kommentar verfassen