10. Tips & Tricks

In diesem Abschnitt finden Sie ein paar Tips & Tricks, wie Sie UUCP effektiver nutzen können. Falls Sie einen Trick kennen, schicken Sie mir diesen doch bitte; Danke.

10.1 "alternate" - Irgendwie muß es doch klappen.

Es ist möglich, daß nach dem Aufruf von UUCP solange verschiedene Konfigurationen probiert werden, bis eine Verbindung zustande gekommen ist.

Der sogenannte alternate-Befehl erlaubt es, für einzelne Systeme Alternativen anzubieten, falls ein Fehler aufgetreten ist. Dieses Feature nutze ich, um zuerst eine Verbindung per TCP zu versuchen, die zustande kommt, wenn ich online bin, und erst danach einen Datenaustausch per DialUp zu veranlassen.

Wenn Sie dieses Feature nutzen möchten, sollten Sie schon ein funktionierendes UUCP (entweder DialUp oder TCP) besitzen. Kopieren Sie nun einen zusätzlichen Konfigurationsausschnitt für die sys-Datei hinter Ihre Konfiguration. Trennen Sie diese mit einem alternate. Eine fertige sys-Datei sollte dann so aussehen:

# Login und Paßwort aus der Datei call übernehmen
call-login *
call-password *
# öffentliches Spoolverzeichnis
pubdir /var/spool/uucppublic
# Timeout nach dem Verbindungsaufbau während der 
# Login-Prozedur
chat-timeout 20
# UUCP darf immer gemacht werden
time any
# UUCP darf alle 600 Sekunden wiederholt werden
success-wait 600
# Befehle, die ausgeführt werden dürfen
commands rmail rnews
command-path /usr/lib/news/bin/ /usr/bin /usr/sbin
# Name des Systems, das Sie anrufen
system tpki
port ttyI0
chat ogin: \L word: \P
protocol ig
# hier bitte die Telefonnummer anpassen
phone 0431123123
protocol-parameter i window             7
protocol-parameter i packet-size        2048
protocol-parameter i startup-retries    16
protocol-parameter i init-retries       8
protocol-parameter i init-timeout       10
protocol-parameter i retries            3
protocol-parameter i timeout            20
protocol-parameter i garbarge           20000
protocol-parameter i errors             256
protocol-parameter i error-decay        8
protocol-parameter i remote-window      0
protocol-parameter i remote-packet-size 0
protocol-parameter i short-packets      true
#
alternate
#
port uucp-tcp
protocol tig
# Hier den Systemnamen im Format systemname.provider.de
# eintragen
address tpki.toppoint.de
chat ogin: \L word: \P

10.2 Maximale Größe für EMails begrenzen (sendmail)

Wenn irgendein User große EMails verschickt, kann es unter Umständen sehr teuer für Sie werden ;-(.

Um dies zu verhindern, kann der Mailserver sendmail so konfiguriert werden, daß er große EMails nicht annimmt. Sie müssen dazu als root die Sendmail-Konfigurationsdatei /etc/sendmail.cf anpassen. Öffnen Sie als root mit dem Editor vi die Datei /etc/sendmail.cf. Geben Sie /MaxMessage ein. Nun sollten Sie in der Zeile sein, die ungefähr so aussieht:

#0 MaxMessageSize=100000

Die Zeile gibt die maximale Größe einer EMail in Bytes an. In diesem Fall also 100000 Bytes (fast 100 kb). Passen Sie den Wert Ihren Bedürfnissen an ;-).

Eine neue Zeile, die die maximale Größe einer EMail auf 1 MB begrenzt, sieht so aus:

0 MaxMessageSize=1048576

Nachdem Sie die Änderungen an der Datei mit ESC :wq abgespeichert haben, müssen Sie den Mailserver neu starten, um die Änderungen wirksam zu machen.

10.3 Mail und News schon während des Pollens einsortieren

Normalerweise übergibt der uuxqt erst nach dem kompletten Poll seine Daten per rnews und rmail an den Newsserver und den Mailserver. Mit zwei Zeilen in der config können Sie diese Verhalten beeinflussen:

run-uuxqt 1
max-uuxqts 2

run-uuxqt 1 sorgt dafür, daß uuxqt aufgerufen wird, wenn ein komplettes Paket (Mail oder News) empfangen wurde. max-uuxqts 2 verhindert, daß zu viele uuxqts und die daraus resultierenden Arbeiten gleichzeitig passieren. Es dürfen bei dieser Einstellung nur maximal zwei uuxqts gleichzeitig arbeiten. Diese Konfiguration hat sich als sinnvoll und schnell erwiesen.

Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 17:56:56