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.
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
# 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
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
# kommentiert die Zeile aus, so daß diese bei der
Konfiguration des Mailservers nicht beachtet wird.
Entfernen Sie zuerst das Hash-Zeichen.
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.
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.