MausCon und mehrere User
Eine Beschreibung wie man Mauscon für mehrere Benutzer auf einer
Maschine konfigurieren kann, oder Mauscon zum Tausch an mehreren Boxen
benutzen kann.
Ich hab' nicht den Eindruck daß mir die Beschreibung optimal gelungen
ist, aber vielleicht hilft es ja trotzdem.
Message-ID: <19980221121322.45493@ohse.de>
Date: Sat, 21 Feb 1998 12:13:23 +0100
From: Uwe Ohse <uwe@ohse.de>
To: Georg Bauer <gb@goggle.westfalen.de>
Subject: Re: MausCon und mehrere User
Hallo Georg,
Endloszeilen? Hm ...
> Mal ne (warscheinlich blöde) Frage: kann ich mit MausCon es ermöglichen,
> daß zwei User über eine gemeinsame Linux-Kiste Mausgruppen lesen,
> ohne daß im MausNet erkennbar ist, daß das keine Maus-User waren?
Ja.
> Müsste doch eigentlich gehen, oder? Kann man vielleicht auch generell
> angeben, welche User auf welche Maus-User gemapped werden?
Nein. Wenn mauscon die Nachrichten erhält sieht es nichts mehr von der
Benutzer-ID. Die effektiven/realen Userids sind die von Mauscon, dem
Mailsystem und dem Newssystem, und $USER und $LOGNAME sind nicht gesetzt.
Die Antwort stimmt wenn man Deine Frage strict interpretiert.
Natürlich geht es doch. Mauscon kann anhand der Adress aus der From-Zeile
bzw. dem Envelope-Absender (Mail) entscheiden wer durch welchen Kanal
schreiben darf. Im Prinzip ist das durchaus dokumentiert ("allowed" in
der Konfigurationsdatei, sowie `/var/spool/mauscon/routes').
Aber mal ein Beispiel, aus dem täglichen Leben auf meiner Maschine
gegriffen (ein Benutzer ich, der andere Gate - kein besonders wichtiger
Unterschied zu dem was Du willst. Die Box ist die DU3, die Linuxkiste
auf der mauscon läuft die tirka.ohse.de, und als Absender hab' ich fast
überall ohse.de eingetragen).
-------------------------------------------------------------------------
default:
mailhost=tirka.ohse.de
newshost=tirka.ohse.de
gatemaster=uwe
[etc usw]
# common
du3:
pollsite=du3
# voll qualifizierter Domainname. Ich mag' keine DNS-Lookups dafür machen.
pollsitedomain=du3.ohse.de
boxtyp=quark ii
# historical garbage follows
send_crosspostings=true
send_sender=true
send_reply_to=true
send_followup_to=true
reach-sites=*
mime-coded-headers=TRUE
[etc usw]
uwe-du3:
includestanza du3
mode=user
keep-sent=TRUE
# nicht gut, aber IMO das am wenigstens schlechte ... B für beantwortet
# ist die Alternative, oder halt gar nichts senden.
autostatus=Z
# Zieladresse für Infofiles (und -diffs), Envelopeabsender für
# von der Box im Benutzermodus (nicht Gatemodus) empfangene PMs.
# Die angegebene Adresse darf immer durch diese Kanal schreiben, braucht
# also nicht zu `allowed' hinzugefügt werden. Nichtsdestotrotz tu' ich
# es dennoch ...
mailuserdomain=uwe@ohse.de
# uwe-*@*ohse.de ginge auch, will ich aber nicht.
allowed=uwe@ohse.de uwe@tirka.ohse.de
gate-du3:
includestanza du3
mode=gate
# OK, _dieser_ Status ist richtig!
autostatus=Y
# hier könnte man die news.maus.de-Dummheit begehen. Es geht auch anders.
# zum Beispiel gruppenweise (siehe `groups'), was die einzige halbwegs
# sinnvolle Alternative ist.
path-entry=
# das ist hochgradig quarkspezifisch!
send_path=true
# unbegrenzte Versuche machen eine Transfer-ID zu holen. Sollte irrelevant
# sein ...
lock-tries=0
# ok, mittlerweile gibt es "XR-", das "exportiere mich nicht"-Flag für
# Nachrichten. Die 0.9.4 unterstützt es auch. Nur Linkit noch nicht ...
# und ich bin auch gar nicht so scharf darauf durchzurouten.
foreign-export-restricted=TRUE
foreign-export-path=tirka-noexport
unconvertable-from-path=tirka-noexport
empty-envelope-for=mausnet mailer-daemon
# Zieladresse für infofilediffs, und grundsätzlich _allowed_.
mailuserdomain=uwe@ohse.de
allowed=*
-------------------------------------------------------------------------
Der allowed-Mechanismus ist zwar nett, aber nicht ausreichend. Er bestimmt
ob mroute eine Nachricht die es für einen gegebenen Kanal erhält auch
durchläßt. Das reicht für news auch durchaus, siehe unten. Bei Mail sieht
es anders aus. Wenige Mailsysteme können ohne großen Aufwand nach Absendern
routen und die Nachricht selbst dem richtigen Mauscon-Kanal zuordnen. Deshalb
gibt es einen Hack, den Kanal `route' (wobei man sich das bei einer einfachen
Installation für nur einen Benutzer sparen kann - bis auf eine leere `routes'-
Datei dank eines Bugs im mroute). Wird mroute mit dem Kanalnamen `route'
aufgerufen versucht es anhand der Datei `/var/spool/mauscon/routes' selbst
zu routen.
Das Format der Datei ist relativ simpel: Beliebig viele Textzeilen. Leerzeilen
und mit `#' beginnende Zeilen werden ignoriert. Alle anderen haben folgendem
Schema zu gehorchen (Felder mit Leerzeichen/Tabs getrennt):
- zuerst ein Kanalname (nicht `route', sondern ein echter).
- dann eine mit Doppelpunkt getrennte Liste von erlaubten Absendern.
Wildcards sind erlaubt.
- dann eine mit Doppelpunkt getrennte Liste der erreichbaren Ziele. Wildcards
sind erlaubt und der Regelfall. `Ziel' heißt hier `vollqualifizierter
Boxname' und wird im Allgemeinen als `*' eingetragen.
Beispiele:
uwe-du3 uwe:uwe@tirka.ohse.de:uwe@ohse.de *
gate-du3 * *
Die Zeilen werden in der angegebenen Reihenfolge eingetragen.
Übrigens sollte dieser Mechanismus auch prächtig mit News funktionieren,
nicht nur mit Mail, allerdings wird das `Ziel' bei News nicht beachtet.
Wie benutzt man das jetzt, Teil 1: Mailsystemkonfiguration, am Beispiel
qmail:
a) man trägt z.B. folgende Zeilen in /var/qmail/control/virtualdomains
ein:
.maus.de:alias-mausnet
du3.ohse.de:alias-mausnet
b) man legt eine Datei /var/qmail/alias/.qmail-mausnet-default an. Inhalt:
|/usr/local/bin/mroute -f "$SENDER" -m -T "$EXT2@$HOST" route
c) man testet mal kurz als Benutzer `alias' ob das auch funktionieren kann:
cat eine_mail_an_mich | \
/usr/local/bin/mroute -f "ich@linux.kiste" -m -T "ich_in@der.box" route
und schaut dann man noch was aus der Nachricht geworden ist (syslog und
die Mausconlogfiles).
d) man sendet qmail-send ein SIGHUP, damit es `virtualdomains' neu einliest.
Wie benutzt man das jetzt, Teil 2: Mailsystemkonfiguration, am Beispiel INN:
Variante a)
Man trägt für jeden Kanal einen feed in der newsfeeds-Datei ein:
#Benutzeraccount Uwe Ohse @ DU3
MausNet/du3.maus.de,du3.ohse.de,nicht-via-du3.ohse.de:!*,maus.*/!tirka:\
Tp:/usr/local/bin/mroute --news -i /var/news/spool/articles/%s uwe-du3
#Gateway der DU3, gekürzt ...
du3.ohse.de/du3.maus.de,tirka-noexport:\
alt.*,comp.*,maus.*,!*binaries*,!*pictures*,/!tirka,!via-maus:Tf:Wnb:
anders gesagt: dem Gateway verfüttere ich gebatchte News. Ansonsten
braucht es für die Mahlzeit viel zu lange ...
Variante b)
Man trägt nur einen Kanal ein und überläßt mroute das Routing. Das
funktioniert aber nur mit einzelnen, ungebatchten News ... weshalb ich
das auch nicht verwende, hier laufen täglich viel zu viele Nachrichten
durch.
MausNet/du3.maus.de,du3.ohse.de,nicht-via-du3.ohse.de:!*,maus.*/!tirka:\
Tp:/usr/local/bin/mroute --news -i /var/news/spool/articles/%s route
Vielleicht noch ein Hinweis: der `allowed'-Mechanismus bleibt immer in
Kraft. Ein Nachricht von irgendjemandem sonst, die im Kanal `uwe-du3'
landet, wird auf jeden Fall entsorgt (oder, bei Mail, gebounced).
> Sowohl das Linux-System als auch die Maus sind meine, beide sind also
> voll unter meiner Kontrolle :-)
Dann solltest Du auch in der Lage sein die Doku zu installieren :-)
Gruß, Uwe
Noch ein Nachtrag: über dieselben Mechanismen kann man Mauscon dazu nutzen für
einen oder mehrere Benutzer an verschiedenen Boxen zu tauschen. Für PMs ist das
in der Praxis relativ schön - bei News muß man aufpassen: Die Entscheidung,
über welchen Kanal eine öffentliche Nachricht in welche Box gesendet kann
nur im Newssystem einkonfiguriert werden. Das hier:
MausNet/du3.maus.de:,maus.*/!local:\
Tp:/usr/local/bin/mroute --news -i /var/news/spool/articles/%s uwe-du3
MausNet/lu.maus.de:maus.gate/local:\
Tp:/usr/local/bin/mroute --news -i /var/news/spool/articles/%s uwe-lu
bewirkt, daß eine von mir geschriebene Nachricht in maus.gate in beide Boxen
geschickt wird, wenn in der mauscon.cnf nicht noch irgendwelche Spielereien
mit `allowed' gemacht werden. Das ist eine gute Möglichkeit netzweit bekannt
zu werden!