Archiv ‘Linux’

Freitag, 7. September 2007

ktrace und kdump (strace unter Mac OS X)

Link zu diesem Artikel

Das unter GNU/Linux so nützliche Tool strace findet sich leider nicht unter Mac OS X. Glücklicherweise haben die Macher Darwin aber ktrace mitgegeben, welches die identische Aufgabe erfüllt.

Informationen dazu erhielt ich über eine Dokumentationsseite von Kaspersky sowie über eine vorzügliche Präsentation von den „Kollegen“ in Zürich.

Heute habe ich dieses Tool auf der Arbeit benutzt, um auf einem widerspenstigen PowerMac G5 1.6GHz die Applikation Software Update zu debuggen. Jedes Mal, wenn man diese Applikation über das Apfel-Menu aufrief, verbreiterte sich das freie Plätzchen im Dock für einige Hundertstelsekunden, ohne dass aber das Icon erschien. Das Programm konnte aus irgendeinem Grund nicht geladen werden.

Es war wieder einmal der Zeitpunkt gekommen, an dem ich mein geballtes Mac/Unix-Fachwissen anwenden konnte *höhö*

fs_usage

Zuerst einmal durfte sich fs_usage profilieren, indem es mir aufzeigen sollte, was die Applikation beim Start so alles an Dateien aufrief (fs_usage = „Zugriffe auf des Dateisystems“):

[dkf38-222:~] mario% sudo fs_usage | grep pdat
16:19:35  getattrlist     /System/Library/CoreServices/Software Update.app                                  0.000048   Dock        
16:19:35  lstat           /System/Library/CoreServices/Software Update.app                                  0.000031   Dock        
16:19:35  stat            /System/Library/CoreServices/Software Update.app/Contents                         0.000016   Dock        
16:19:35  open            /System/Library/CoreServices/Software Update.app/Contents/Info-macos.plist        0.000039   Dock        
16:19:35  open            /System/Library/CoreServices/Software Update.app/Contents/Info.plist              0.000018   Dock        
16:19:35  open            /System/Library/CoreServices/Software Update.app/Contents/Resources               0.000020   Dock        
16:19:35  open            Services/Software Update.app/Contents/Resources/English.lproj/InfoPlist.strings   0.000033   Dock  
16:19:35  lstat           /System/Library/CoreServices/Software Update.app                                  0.000012   Dock
16:19:35  getattrlist     /.vol/234881034/22761/Contents/Resources/Software Update.icns                     0.000019   Dock

Hmmm – irgendwie nicht das Gelbe vom Ei.

ktrace und kdump

Bevor ich ktrace anwenden konnte, musste ich zuerst das Executable innerhalb des .app-Ordners ausfindig machen (.app-Bundles – dafür sollten die seligen NeXT-Entwickler den think eMeidi Liftetime Achievement-Award erhalten):

/System/Library/CoreServices/Software\ Update.app/Contents/MacOS/Software\ Update

Mit dieser Erkenntnis ausgerüstet, konnte ich mit der Brechstange ktrace hinter den Prozess:

[dkf38-222:~] mario% sudo ktrace /System/Library/CoreServices/Software\ Update.app/Contents/MacOS/Software\ Update

Nichts geschah. Häh? Erst nach reichlichen Überlegungen und Konsultationen von Web-Sites bemerkte ich die nun in ~ liegende ktrace.out, deren man nun mit kdump die Geheimnisse entlocken musste:

[dkf38-222:~] mario% sudo kdump
   668 ktrace   RET   ktrace 0
   668 ktrace   CALL  execve(0xbffffdff,0xbffffd7c,0xbffffd84)
   668 ktrace   NAMI  "./Software Update"
   668 ktrace   RET   execve -1 errno 8 Exec format error
   668 ktrace   CALL  execve(0x9012bf18,0xbffff730,0xbffffd84)
   668 ktrace   NAMI  "/bin/sh"
   668 ktrace   NAMI  "/usr/lib/dyld"
   668 sh       RET   execve 0
   668 sh       CALL  open(0x152c,0,0)
   668 sh       NAMI  "/usr/lib/libncurses.5.dylib"
   668 sh       RET   open 4
   668 sh       CALL  fstat(0x4,0xbffffaf0)
   668 sh       RET   fstat 0
   668 sh       CALL  load_shared_file(0x152c,0x98000,0x441d8,0xbffff900,0x4,0xbffff890,0xbffff904)
   668 sh       NAMI  "/usr/lib/libncurses.5.dylib"
   668 sh       RET   load_shared_file 0
   668 sh       CALL  close(0x4)
   668 sh       RET   close 0
   668 sh       CALL  open(0x1560,0,0)
   668 sh       NAMI  "/usr/lib/libSystem.B.dylib"
   668 sh       RET   open 4
   668 sh       CALL  fstat(0x4,0xbffffaf0)
   668 sh       RET   fstat 0
   668 sh       CALL  load_shared_file(0x1560,0x98000,0x1ac500,0xbffff900,0x4,0xbffff890,0xbffff904)
   668 sh       NAMI  "/usr/lib/libSystem.B.dylib"
   668 sh       RET   load_shared_file 0
   668 sh       CALL  close(0x4)
   668 sh       RET   close 0
   668 sh       CALL  open(0x900006e8,0,0)
   668 sh       NAMI  "/usr/lib/system/libmathCommon.A.dylib"
   668 sh       RET   open 4
   668 sh       CALL  fstat(0x4,0xbffffa80)
   668 sh       RET   fstat 0
   668 sh       CALL  load_shared_file(0x900006e8,0x98000,0x6ac4,0xbffff890,0x3,0xbffff820,0xbffff894)
   668 sh       NAMI  "/usr/lib/system/libmathCommon.A.dylib"
   668 sh       RET   load_shared_file 0
   668 sh       CALL  close(0x4)
   668 sh       RET   close 0
   668 sh       CALL  __sysctl(0xbffffc98,0x2,0xbffffca0,0xbffffca4,0,0)
   668 sh       RET   __sysctl 0
   668 sh       CALL  sigprocmask(0x1,0,0x93a34)
   668 sh       RET   sigprocmask 0
   668 sh       CALL  open(0x797b4,0x6,0x20000000)
   668 sh       NAMI  "/dev/tty"
   668 sh       RET   open 4
   668 sh       CALL  close(0x4)
   668 sh       RET   close 0
   668 sh       CALL  getuid
   668 sh       RET   getuid 0
   668 sh       CALL  getgid
   668 sh       RET   getgid 0
   668 sh       CALL  getuid
   668 sh       RET   getuid 0
   668 sh       CALL  getgid
   668 sh       RET   getgid 0
   668 sh       CALL  sigprocmask(0x1,0,0x93724)
   668 sh       RET   sigprocmask 0
   668 sh       CALL  fstat(0x2,0xbffff960)
   668 sh       RET   fstat 0
   668 sh       CALL  fstat(0x1,0xbffff960)
   668 sh       RET   fstat 0
   668 sh       CALL  sigaction(0x14,0xbffff960,0xbffff9d0)
   668 sh       RET   sigaction 0
   668 sh       CALL  sigaction(0x14,0xbffff960,0xbffff9d0)
   668 sh       RET   sigaction 0
   668 sh       CALL  sigaction(0x2,0xbffff960,0xbffff9d0)
   668 sh       RET   sigaction 0
   668 sh       CALL  sigaction(0x2,0xbffff960,0xbffff9d0)
   668 sh       RET   sigaction 0
   668 sh       CALL  sigaction(0x3,0xbffff960,0xbffff9d0)
   668 sh       RET   sigaction 0
   668 sh       CALL  sigaction(0x3,0xbffff960,0xbffff9d0)
   668 sh       RET   sigaction 0
   668 sh       CALL  sigprocmask(0x1,0,0x94128)
   668 sh       RET   sigprocmask 0
   668 sh       CALL  sigaction(0x3,0xbffff910,0xbffff980)
   668 sh       RET   sigaction 0
   668 sh       CALL  __sysctl(0xbffffa20,0x2,0xbffffa80,0xbffffa28,0,0)
   668 sh       RET   __sysctl 0
   668 sh       CALL  stat(0x100ef0,0xbffff8b0)
   668 sh       NAMI  "/System/Library/CoreServices/Software Update.app/Contents/MacOS"
   668 sh       RET   stat 0
   668 sh       CALL  stat(0x79f24,0xbffff910)
   668 sh       NAMI  "."
   668 sh       RET   stat 0
   668 sh       CALL  getpid
   668 sh       RET   getpid 668/0x29c
   668 sh       CALL  getpid
   668 sh       RET   getpid 668/0x29c
   668 sh       CALL  stat(0x79f24,0xbffff8d0)
   668 sh       NAMI  "."
   668 sh       RET   stat 0
   668 sh       CALL  stat(0x1016a0,0xbffff7c0)
   668 sh       NAMI  "/bin/sh"
   668 sh       RET   stat 0
   668 sh       CALL  stat(0x1016a0,0xbffff7d0)
   668 sh       NAMI  "/bin/sh"
   668 sh       RET   stat 0
   668 sh       CALL  getpgrp
   668 sh       RET   getpgrp 668/0x29c
   668 sh       CALL  sigaction(0x14,0xbffff950,0xbffff9c0)
   668 sh       RET   sigaction 0
   668 sh       CALL  sigprocmask(0x1,0,0x93a34)
   668 sh       RET   sigprocmask 0
   668 sh       CALL  open(0x101de0,0,0x1)
   668 sh       NAMI  "./Software Update"
   668 sh       RET   open 4
   668 sh       CALL  ioctl(0x4,FIODTYPE,0xbffffa60)
   668 sh       RET   ioctl -1 errno 25 Inappropriate ioctl for device
   668 sh       CALL  ioctl(0x4,TIOCGETA,0xbffffa30)
   668 sh       RET   ioctl -1 errno 25 Inappropriate ioctl for device
   668 sh       CALL  lseek(0x4,0,0,0x1)
   668 sh       RET   lseek 0
   668 sh       CALL  read(0x4,0xbffffac0,0x50)
   668 sh       GIO   fd 4 read 0 bytes
       ""
   668 sh       RET   read 0
   668 sh       CALL  lseek(0x4,0,0,0)
   668 sh       RET   lseek 0
   668 sh       CALL  getrlimit(0x8,0xbffff9f0)
   668 sh       RET   getrlimit 0
   668 sh       CALL  dup2(0x4,0xff)
   668 sh       RET   dup2 255/0xff
   668 sh       CALL  close(0x4)
   668 sh       RET   close 0
   668 sh       CALL  fcntl(0xff,0x2,0x1)
   668 sh       RET   fcntl 0
   668 sh       CALL  fcntl(0xff,0x3,0)
   668 sh       RET   fcntl 0
   668 sh       CALL  fstat(0xff,0xbffffad0)
   668 sh       RET   fstat 0
   668 sh       CALL  lseek(0xff,0,0,0x1)
   668 sh       RET   lseek 0
   668 sh       CALL  sigprocmask(0x1,0,0x93a34)
   668 sh       RET   sigprocmask 0
   668 sh       CALL  read(0xff,0x100180,0x1)
   668 sh       GIO   fd 255 read 0 bytes
       ""
   668 sh       RET   read 0
   668 sh       CALL  exit(0)

Hmmm. Nachdem ich mich in die Prozeduren eingelesen hatte, fielen mir folgende Zeilen auf:

668 sh       CALL  ioctl(0x4,FIODTYPE,0xbffffa60)
   668 sh       RET   ioctl -1 errno 25 Inappropriate ioctl for device
   668 sh       CALL  ioctl(0x4,TIOCGETA,0xbffffa30)
   668 sh       RET   ioctl -1 errno 25 Inappropriate ioctl for device

Eine Google-Suche nach „ioctl -1 errno 25 Inappropriate ioctl for device“ ergab zwar einige Treffer, doch ich konnte mir keinen Reim daraus machen.

Netzwerk-Einstellungen?

Durch einige gefundene Seiten sensibilisiert erachtete ich nun Netzwerk-Troubles als Ursache. Was liegt da näher, als die Netzwerkeinstellungen zurückzusetzen?

Würde die Maschine unter Windows arbeiten, wären hierzu viele komische Klicks und wohl ein Abstecher in den Registry-Dschungel nötig. Unter Mac OS X hingegen beschränkte sich der Aufwand auf ein simples:

sudo rm /Library/Preferences/SystemConfiguration/preferences.plist

Beim nächsten Zugriff auf die Netzwerkeinstellunge via Apfel-Menu > Location fand ich eine jungfräuliche Netzwerkkonfiguration vor. Leider hat auch dies nichts gebracht.

tcpdump

Nun, der Feierabend rückte unaufweigerlich näher, doch ein cooles Tool wollte ich noch ausprobieren: tcpdump. Fantastisch, was nach dem Aufruf dieses Tools alles über die Shell flimmert – in einem Unternehmens-LAN hört die TCP-Party wohl nie auf *smile*

Leider gab auch dies keine Aufschlüsse über das Problem. Immerhin weiss ich jetzt, dass IP-Adressen, die mit 224.0. beginnen, ganz besondere (Multicast-)Adressen sind …

Tags: , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 4. September 2007

exim4: Message is frozen

Link zu diesem Artikel

Heute habe ich in meiner /var/log/exim4/mainlog komischen Zeilen vorgefunden:

2007-09-04 17:15:30 Start queue run: pid=3437
2007-09-04 17:15:30 1ISVRa-0003X6-Ag Message is frozen
2007-09-04 17:15:30 1ISVPl-0003UC-HI Message is frozen
2007-09-04 17:15:30 1ISVSO-0003YE-FE Message is frozen
2007-09-04 17:15:30 End queue run: pid=3437

Folgender Befehl löste (zumindest auf meinem Rechner) die temporäre „Verstopfung“ tadellos:

exim4 -qff

Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 14. August 2007

LaTeX mit maximaler Seitenausnutzung und minimalen Seitenrändern

Link zu diesem Artikel

Heute habe ich eine meiner Web-Applikationen auf der Arbeit um die nützliche Funktion erweitert, PDF-Dateien auszugeben. Der Inhalt ist eine Tabelle (longtable, wer LaTeX-kundig ist), die im Querformat ausgegeben werden soll. Mit den Standardeinstellungen der Dokumentenklasse report konnte sich die Tabelle überhaupt nicht entfalten, weshalb ich mich auf der Suche nach Einstellungen machte, die den auf einer Seite zur Verfügung stehenden Platz maximieren:

\documentclass[10pt,a4paper,landscape]{report}

\setlength\topmargin{0cm}
\setlength\headheight{0cm}
\setlength\headsep{0cm}
\setlength\textheight{160mm}
\setlength\textwidth{245mm}
\setlength\oddsidemargin{0cm}
\setlength\evensidemargin{0cm}

\begin{document}
\end{document}

\textheight{} und \textwidth{} waren dabei die massgeblichen Befehle, auch wenn die anderen \setlengths ihren Teil zum Endprodukt beitragen.

Fazit: Anstelle von 16 habe ich das PDF auf 11 Seiten heruntergerechnet.

Tags:
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 29. Juli 2007

IIS vs. Apache

Link zu diesem Artikel

Windows Server/IIS

Linux/Apache

In his post, Stiennon explains that both images (shown here) represent a map of system calls that occur when a web server serves a single HTML page with a picture. The same page and picture have been used on both servers for the purpose of testing.

Quelle: Windows vs Linux Server

Wir haben es immer vermutet, jetzt ist es klar: Wer kein Gefrickel will, wählt Open-Source!

In its long evolution, Windows has grown so complicated that it is harder to secure. Well these images make the point very well.

Quelle: Why Windows is less secure than Linux

Tags: ,
Labels: Linux, Web

Keine Kommentare | neuen Kommentar verfassen

Freitag, 27. Juli 2007

Datei aus tar-Archiv wiederherstellen

Link zu diesem Artikel

Von Zeit zu Zeit erstelle ich von meinem Linux-Server hier zu Hause ein Backup mit mkcdrec. Das daraus resultierende iso-Image wird dann auf CD gebrannt und in mein Bankschliessfach nach Bern transferiert. Damit ich bei einem Notfall nicht bei meiner Bank vorsprechen muss, belasse ich das iso auf dem Server.

Leider muss ich hie und da auf die Backups zurückgreifen – wie heute. Mit einer blöden Aktion habe ich mir meine named.conf überschrieben. Was nun?

Als erstes habe ich das Image auf meine Workstation (Mac OS X) kopiert und danach gemountet (das Mounten ginge selbstverständlich auch ohne Transfer über das Netzlaufwerk). Danach habe ich die entsprechende Partition gesucht und das Datei-basierte, komprimierte Backup auf den Desktop verschoben.

Als nächstes musste die gz-Datei entpackt werden:

$ gunzip sda7._.tar.gz

Nun haben wir eine tar-Datei rumliegen. Im Normalfall möchte man einige wenige Dateien wiederherstellen, weshalb es sich nicht lohnt, gleich den ganzen Inhalt des „Tape Archives“ zurückzuschreiben. Deshalb sucht man den exakten Pfadnamen der Datei, in meinem Fall named.conf:

$ tar --list --file=sda7._.tar | grep named.conf
./etc/bind/named.conf

Mit der obigen Angabe können wir nun die Datei aus dem Archiv herausholen:

$ tar --extract --file=sda7._.tar ./etc/bind/named.conf

Fertig.

Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 7. Juli 2007

fink bringt GNU-Software auf den Mac

Link zu diesem Artikel

Der Ordnung halber sei fink erwähnt – wer GNU-Software auf seinem Mac braucht (und demzufolge ein Power-User von Terminal & Co. ist), hat das Ding längst installiert:

How to install Linux applications in OS X – a complete walkthrough

Nebenbei: Leider war ich bisher zu Faul, die Pfad-Variable mit /sw/bin zu ergänzen, weshalb ich jedesmal, wenn ich das gute, alte wget verwenden will, den absoluten Pfad zum Tool angeben muss:

beta:~ mario$ /sw/bin/wget -V
GNU Wget 1.8.2

Copyright (C) 1995, 1996, 1997, 1998, 2000, 2001 Free Software Foundation, Inc.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

Originally written by Hrvoje Niksic .

Alternative

Die Alternative ist Darwin Ports – doch mit diesem Paket-Manager und Repository habe ich (leider) keine Erfahrung.

Tags:
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

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

« Older Entries
Newer Entries »