Archiv ‘Linux’

Mittwoch, 17. Oktober 2007

Mails mit exim4 pipen

Link zu diesem Artikel

Kürzlich hatte ich auf der Arbeit das Problem, dass ein neu eingeführtes Ticketing-System sich automatisch aller auf die Support-Adresse eingehenden Mails annehmen hätte sollen – es aber nicht tat.

Auf dem Server läuft Debian, als MTA ist exim4 installiert.

In /etc/aliases stand nach der erfolgreichen Installation von Request Tracker (RT) bereits alles zum Besten …

rt3: "|/home/rt3/bin/rt-mailgate --queue incoming --action correspond --url http://rt3.domain.tld"

… sogar die Weiterleitung war aktiv …

pc-support: rt3

… doch irgendwie wollte die Zustellung der Mails nach RT einfach nicht klappen! In /var/log/exim4/mainlog war nach erfolglosen Mail-Versuchen (vorerst vom localhost aus, später auch aus dem LAN) zu lesen:

2007-10-09 05:23:42 1Ieqtj-0000u4-40 == |/home/rt3/bin/rt-mailgate --queue incoming --action correspond --url http://rt3.domain.tld  R=system_aliases defer (-30): pipe_transport unset in system_aliases router

Nach einer etwas längeren Google-Suche war das Problem eingegrenzt: exim4 pipet Mails in der Standardkonfiguration nicht. Die Entwickler raten in der Doku zwar vom Pipen nach herkömmlicher Art ab – aber wenn niemand ein anständiges Beispiel beilegt und die Dokumentation im Kreis herumführt (In Z steht: „Schaue in XY nach“ und in XY steht „Schaue in Z nach“), biegt man die Konfiguration halt so um, dass zumindest die „mittelalterliche“ und gewohnte Vorgehensweise klappt.

Hierzu mussten in der Datei /etc/exim4/exim4.conf.template (falls eine monolithische Konfigurationsdatei verwendet wird) folgende Zeilen eingetragen werden:

...
# for explanation and some workarounds.

SYSTEM_ALIASES_USER = rt3
SYSTEM_ALIASES_GROUP = rt3
SYSTEM_ALIASES_PIPE_TRANSPORT = address_pipe

system_aliases:
...

Seither gelangen neu eintreffende Mails direkt in das Ticketing-System und warten nun darauf, freiwillig von einem der Supporter übernommen zu werden. Dies scheint ein deutlich grösseres Problem zu sein *zwinker*

Tags:
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 1. Oktober 2007

Linux-Pinguin

Link zu diesem Artikel

Tux: Was nicht fliegen kann, kann auch nicht abstürzen.

Labels: Funny, Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 14. September 2007

Bye bye, SCO!

Link zu diesem Artikel

SCO Group today filed for bankruptcy protection.

Quelle: SCO files for US bankruptcy protection

Endlich ist die Bude hops gegangen. In den letzten Jahren produzierte das Unternehmen nichts substanzielles mehr, als es mit Hilfe einer Horde Rechtsverdreher gegen den Giganten IBM vor Gericht zog. Grund der Klage: IBM habe Unix-Quellcode geklaut und in Linux eingebaut.

Ausser Spesen nichts gewesen: In einem Monat sollen 9 Millionen US-Dollar an die Anwälte überwiesen worden sein. Wenn zwei sich streiten freuen sich am Ende nur die Anwälte.

Labels: Linux, USA, Wirtschaft

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 13. September 2007

MySQL: Table is marked as crashed and should be repaired

Link zu diesem Artikel

Als ich gestern phpMyAdmin auf einem von mir betreuten Web-Server aufrief, erhielt ich folgende Fehlermeldung präsentiert:

#145 - Table './wsu/smt_stats' is marked as crashed and should be repaired

Hossa! In meiner ganzen Karriere habe ich so etwas noch nie erlebt. Nun, was tun? phpMyAdmin verfügt in seiner Oberfläche unter tabelle > Operations > Table Maintenance diverse Möglichkeiten zur Fehlerbehebung:

  • Check table
  • Analyze table
  • Repair table
  • Optimize table

Leider waren diese Befehle im aktuellen Fall nicht zugänglich – anstelle der Liste erschien oben genannte Fehlermeldung.

Glücklicherweise kann man in der Tabellenübersicht einer Datenbank Tabellen mit der Checkbox markieren und aus dem Befehle-Drop-Down dann ‚Repair‘ auswählen. Leider brachte dies nichts, die Fehlermeldung erschien weiterhin. Das Problem schien schwerwiegender zu sein, als zuerst angenommen.

Deshalb ging es einerseits rüber zu Google, ums ich über die Möglichkeiten der Tabellenreparatur schlau zu machen, andererseits per SSH auf den Server selbst.

Auf Ways to repair MYSQL Databases fand ich Empfehlungen für solche Fälle, welche ich der Reihe nach ausprobierte.

mysqlcheck

hist-web:~# mysqlcheck -uroot -p wsu smt_stats
Enter password: 
wsu.smt_stats
error    : Table './wsu/smt_stats' is marked as crashed and should be repaired

Oookey … der Nächste bitte!

myisamchk

Zuerst fährt man MySQL ordnungsgemäss herunter:

/etc/init.d/mysql stop

Dann kann man sich mit dem Brachial-Tool ans Werk machen:

hist-web:/var/lib/mysql/wsu# myisamchk smt_stats.MYI
Checking MyISAM file: smt_stats.MYI
Data records:  139144   Deleted blocks:       0
myisamchk: warning: Table is marked as crashed
- check file-size
myisamchk: error: Size of datafile is: 10473472          Should be: 10473480
- check record delete-chain
- check key delete-chain
- check index reference
- check data record references index: 1
myisamchk: error: Found 139145 keys of 139144
- check record links
myisamchk: error: Recordlink that points outside datafile at 10473420
MyISAM-table 'smt_stats.MYI' is corrupted
Fix it using switch "-r" or "-o"

Ich tat, wie mir befohlen wurde:

hist-web:/var/lib/mysql/wsu# myisamchk -r smt_stats.MYI
- recovering (with sort) MyISAM-table 'smt_stats.MYI'
Data records: 139144
- Fixing index 1
Found block that points outside data file at 10473420

Zur Sicherheit überprüfte ich die Tabelle erneut:

hist-web:/var/lib/mysql/wsu# myisamchk smt_stats.MYI
Checking MyISAM file: smt_stats.MYI
Data records:  139144   Deleted blocks:       0
- check file-size
- check record delete-chain
- check key delete-chain
- check index reference
- check data record references index: 1
- check record links

Da alles wieder rosig aussah, konnte man MySQL wieder hochfahren:

/etc/init.d/mysql start

Labels: Linux

22 Kommentare | neuen Kommentar verfassen

Mittwoch, 12. September 2007

VLC gibt Audio von Netzlaufwerk zerhackt wieder

Link zu diesem Artikel

Auf meinem File-Server (Debian GNU/Linux) hier zu Hause liegen unzählige Gigabytes an Musik und Filmen herum. Um sie auf meiner Workstation (Mac OS X) anzuschauen, mounte ich die Verzeichnisse mit dem SMB-Protokoll über das vor einiger Zeit zugekaufte Gigabit-Netzwerk. Zur Wiedergabe benutze ich den Videolan-Client 0.8.6 (heute als VLC bekannt) in der PowerPC-Version.

Leider kommt es immer wieder vor, dass Audio-Signale zerhäckselt ausgegeben werden. Unter Window > Message steht in solchen Fällen folgendes:

main debug: audio output is starving (210051), playing silence

Nachdem ich mich jahrelang um dieses Problem foutiert hatte, platzte mir gestern bei Episode 3 der zweiten Staffel von The IT Crowd der Kragen. Einige Google-Suchen später präsentierte man mir die Lösung:

  1. Preferences
  2. Input / Codes
  3. Access Modules
  4. File
  5. Caching value in ms = 5000

Quelle: VLC and wireless networks

So kam ich in den Genuss einer amüsanten Folge, in der einerseits die RIAA hochgenommen wurde (die Anti-Piraterie-Werbung hat sich seit der Austrahlung auf Channel 4 rasant im Netz verbreitet) …

… andererseits die deutschen Kannibalen persifliert wurden. Anscheinend hat dieser Menschenesser bei den Briten für Furore gesorgt wie niemand mehr seit Adolf:

Tags: , , ,
Labels: Linux, Medien

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 11. September 2007

Mit wget ganze Sites abräumen

Link zu diesem Artikel

wget -r -nd -np -erobots=off "http://server.tld/"
  • -r recursive (= folge und Downloade alle verlinkten Dokumente wie HTML-Dateien und Bilder)
  • -nd nodirectories (= lege Downloads nicht in Unterordner ab)
  • -np noproblem … eh … noparent (= folge keinen Links, die eine Ordner-Ebene höher liegen)
  • -erobots=off evaluate robots.txt (= beachte robots.txt)

Im Netz habe ich auch noch diese Version gefunden:

wget -m -k -K -E "http://server.tld/"

Hat ebenso gut geklappt.

Labels: Linux, Web

Keine Kommentare | neuen Kommentar verfassen

Montag, 10. September 2007

Wo dpkg seine Installationsscripts ablegt

Link zu diesem Artikel

Vor kurzem hatte ich mit einem .deb-Paket zu kämpfen, dass bei der Installation Probleme verursachte. Nachdem ich mich im Internet kundig gemacht hatte, konnte ich unter

/var/lib/dpkg/info/<paket>.preinst
/var/lib/dpkg/info/<paket>.postinst

Einsicht in die Installationsroutine (Shell-Scripts) nehmen und denn Fehler isolieren.

Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 9. September 2007

Kernel Hackers

Link zu diesem Artikel

Quelle: Kernel Summit 2007 group photo, annotated

Dazu das Gespräch mit meiner Freundin per MSN:

Mario: lwn.net/Articles/248891/

Melanie: was si das fürtigi

Mario: programmier vom linux kernel

Melanie: die gseh au chli behinderet us

Mario: ja, wesi würe usgseh wie supermodels würi si äuä ke kernel programmiere …

Übersetzung für deutsche Mitleser:

Mario: lwn.net/Articles/248891/

Melanie: Was sind das für Leute?

Mario: Programmier des Linux-Kernels

Melanie: Die sehen alle ein wenig behindert aus

Mario: Ja, wenn sie wie Supermodels aussehen würden, würden sie wohl kaum Kernel programmieren …

Ich halte Millionen Mal mehr auf diesen Jungs als auf alle Heidis, Naomis und Giseles da draussen.

Ferner: The IT Crowd is back!


The IT Crowd – Season 2 – Zattoo
Originally uploaded by emeidi

Die ersten Folgen der zweiten Season der Kult-Serie für Geeks und solche, die es werden möchten, finden sich bereits auf einschlägigen Web-Sites:

Torrentz: it crowd

Siehe auch: Artikel vom Februar 2006 über die erste Staffel

Labels: Funny, Linux

Keine Kommentare | neuen Kommentar verfassen

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

« Older Entries
Newer Entries »