IRCServices Funktionen

3-1-1 NickName Management (NickServ)

IRC Services Funktionen basieren auf das Registrieren von NickNames. Wenn Du einmal einen Namen registriert hast, werden die Services Dich als den Besitzer des NickNames anerkennen und jeden anderen Benutzer warnen, diesen zu nutzen;
Gegebenenfalls sind die Services auch in der Lage, dem Fremdbenutzer einen anderen Benutzernamen aufzuzwingen oder ihn gar aus dem Netzwerk entfernen.
Der „NickServ“ Pseudoklient ( Pseudoclient ) bietet ein Interface in Verbindung zur NickName-Registration und Wartung. Der Benutzername „NickServ“ kann in der modules.conf unter NickServName einstellen.
NickServ empfängt die Kommandos über /msg (messages)
Z.B.

/msg NickServ register password

Beispiel:
/msg NickServ register Schutzgeist TopSecret

Dieses Beispiel würde NickServ den Befehl „register“ senden, welcher den jeweiligen Nick mit dem dazugehörigen Passwort registrieren würde.
Die Kommandos sind nicht „Case-in sensitiv“ , somit ist es egal ob
man register oder gar ReGiSTeR schreiben würde.

Normalerweise registriert man seinen Benutzernamen, mit dem Register-Befehl, sobald man ein neues Netzwerk betritt, sofern dieser noch nicht belegt wurde.
Wenn dieser NickName nun einmal registriert wurde, benutzt man nach jedem Reconnect den sogenannten identify-Befehl im Zusammenhang mit dem bei der Registrierung angegebenen Passwort, um den Services zu übermitteln, dass man der Besitzer des Nicks ist!

#Geschützten Benutzernamen annehmen
/nick Schutzgeist
#NickServ gegenüber authentifizieren/identifizieren
/msg NickServ identify TopSecret

Sollte ein Benutzer sich entschieden haben einen NickName nicht mehr weiter benutzen zu wollen, kann er diesen mit dem Drop-Befehl löschen lassen. Andernfalls wird der Benutzername, nach 30 unbenutzten Tagen automatisch verfallen.
Diese 30 Tage richten sich nach dem in der modules.conf eingetragenen NSexpire -Wert.

Benutzer können ebenso ihre E-Mail-Adresse angeben, welche gespeichert wird, damit IRCOPs die Benutzer bei Bedarf erreichen können.
Mit dem Setzen der NSRequireEmail Option , kann die E-Mailangabe bei der Registrierung als eine Voraussetzung geltend gemacht werden.
In Verbindung mit der E-Mailadresse kann die Zahl der Registrierungen pro E-Mail begrenzt werden.
Diese Begrenzung findet in der modules.conf , unter NSRegEmailMax statt.

Die List und Information Kommandos stehen zur Verfügung, um eine Liste von vorher aussortierten NickNames anzeigen zulassen bzw. detaillierte Informationen über einzelne Nicks.

Der List Befehl zeigt lediglich Informationen, wie die zuletzt benutzte Maske eines Nicks, also User@Host an; Der Info – Befehl hingegen, zeigt Informationen wie der zuletzt benutzte Realname oder der zuletzt benutzte Host an.

Beispiel: NickServ Info-Befehl

-NickServ- Schutzgeist ist Dennis Selativum 
-NickServ- Ist online von: ~SG@212.202.221.134
-NickServ- Registrationsdatum: 30. Mai 19:54:03 2002 MEST -NickServ- Letzte QUIT-Nachricht: Quit: http://www.IRC-Mania.de -NickServ- Optionen: Chatnamen-Übernahmeschutz, Secure Option -NickServ- 
/msg NickServ INFO Schutzgeist ALL für weitere Informationen

Jeder Nick-Besitzer kann durch die „set hide“ Befehle selbst bestimmen, ob andere User das Privileg haben dürfen diese Informationen über einen abzurufen oder nicht.
Der List Befehl, kann in der modules.conf nur für IRC-Operatoren begrenzt werden, indem man den Wert NSLISTOpersOnly setzt.

Normalerweise melden die Services nur, dass der jeweilige Nick nicht registriert werden kann, wenn dies vorher schon von einer anderen Person getan wurde.
Die IRCServices hingegen bieten die Möglichkeit über die SET KILL Funktion, Fremd-Nutzer /killen zu lassen, sofern sie nach Abstreichen der Zeit versuchen den Nick weiterzunutzen.
Wenn es der IRCD unterstützt, ist es dank der NSForceNickChange – Funktion auch möglich, lediglich den Nick des Fremdbenutzers zu wechseln bzw. diesen zu zwingen, den Nick zu wechseln.
Ein weiterer Pseudo-Klient wird dann den jeweiligen Nick schützen, indem er diesen für eine gewisse Zeit einnimmt (normal 60 Sekunden).
Dies dient dazu, dass der Missbrauch eines Nicks eingeschränkt wird. Die „Kill“-Funktion kann sowohl nach 60 Sekunden als auch nach 20 Sekunden erfolgen. Die beiden Zeitabstände kann man mit dem Set kill Befehl justieren.

Der set hide und der set kill -Befehl, sind nicht die einzigen Set-Befehle.
Wie oben schon einmal erwähnt kann der Benutzer über die Set Funktion, Informationen über sich preisgeben oder gar unterdrücken. Der Set info -Befehl dient dazu sich eine INFOLine einzurichten, die per
/msg NickServ Info <NICKNAME> abgerufen werden kann. Zudem kann man sich selbst noch eine URL oder E-Mailadresse zuweisen, die ebenfalls, wie im vorherigen Beispiel beschrieben, abgerufen werden kann.

Wie es die SET -Funktion gibt, gibt es natürlich auch eine unset –Funktion , die die SET-Anweisung, wieder rückgängig macht. Sollte die NSRequireEmail Funktion in der modules.conf aktiv sein, ist es verständlicherweise nicht möglich, die E-Mail zurücksetzen zu lassen. Denn diese ist dann erforderlich.

Sollte der Besitzer eines NickNames bemerken, dass sein Name von einem Fremdling benutzt wird, dann kann er den NickServ recover -Befehl benutzen, denn dann wird der jeweilige Nick sofort vom Netzwerk getrennt oder ggf. umbenannt.
Der release Befehl ist nützlich, um den Enforcer zu entfernen, der den Nick nach einem Missbrauch für 60 Sekunden einnimmt.
Der Ghost -Befehl entfernt den Benutzer eines Nicks sofort nach Ausführung!
Dieser Befehl ist recht nützlich, wenn die eigene Verbindung abbricht und der eigene Geist noch im Netz fest hängt. Der Enforcer wird in dem Fall nicht aktiv;

Ein anderer Befehl ist der Status- Befehl dieser kann von allen Klienten aus abfragen, ob ein NickName identifiziert ist oder nicht. Die Ausgabe des Befehls ist eine Zahl.

Darüber hinaus haben Services Operatoren Zugriff auf:

den DropNick-Befehl, welcher es erlaubt jeglichen Nick zu löschen
den set Expire-Befehl, welcher es erlaubt Nicknames so zu setzen, dass diese nicht mehr verfallen.
den GetPass-Befehl, welcher das Passwort eines Channels oder Users anzeigen lässt, sofern in der ircservices.conf die Option ENABLEGETPASS aktiviert ist
den Suspend-Befehl, welcher die Nutzung eines Nicks für eine bestimmte Zeit verhindert.
Und den forbid Befehl, welcher den Gebrauch eines Nicks sperrt.
Je nach dem können Services Administratoren auch den SET Befehl auf andere Nick benutzen.
Sollte in der ircservices.conf die jeweilige WallSetPass Funktion aktiviert sein, bekommt jeder IRCOP im Netzwerk eine Nachricht, sobald der Befehl ausgeführt wird

3-1-2 NickName -Verlinkungen

Eine besondere Aufmerksamkeit gilt den Funktionen, die durch so genannte Add-ons, also Modulen, hinzugefügt werden.
Auch die Hauptfunktionen dieser „NickName Verlinkungen“ wird durch das nickserv/link Modul zur Verfügung gestellt
Die meisten Chatnutzer wollen mehrere Chatnamen besitzen.
Zum Beispiel will ein User mit dem NickName „Alice“ möglicherweise auch Alice|away heißen, während sie im away-Modus ist , oder gar „Alice|zzzZZZ“ während sie schläft.
Da es möglich ist, jeden einzelnen NickName separat zu registrieren, müsste sie nach jedem Nickwechsel diesen auch wieder separat identifizieren.
Auch die ChannelZugriffsListe müsste dann pro User (NickName) mehrere Einträge verwalten. Um jedem Nick dieselben Informationen hinzuzufügen, müssten auch die URL, E-Mail und ggf. die INFOLines , individuell hinzugefügt werden.

Um dieses Problem zu beseitigen, verfügen die Services über einen speziellen Weg, mehrere NickNames parallel zu verbinden, sodass alle verlinkten Namen als ein und den selben Nick(Owner) repräsentieren. Dies gilt für die „Nickname last seen, address, Real Name, QuitMessage “ – Einträge, ohne größeren Aufwand betreiben zu müssen.

NickName-Besitzer können über den link -Befehl andere unregistrierte NickNames zu Ihrer Gruppe hinzufügen. Der unlink -Befehl bewirkt das genaue Gegenteil.
Ein bestimmter NickName wird somit aus der Gruppe herausgenommen. Zudem stellt der Listlinks -Befehl eine Liste von bereits verlinkten NickNames zur Verfügung. Der mit einem * (Sternchen) markierten NickName ist der Haupt-Nick der Gruppe.

Man beachte das der drop -Befehl sämtliche NickNames löschen würde, einschließlich den zudem Zeitpunkt benutzten Nick. Um einen einzelnen Nick aus der Gruppe auszuschließen, muss der unlink – Befehl benutzt werden.

Zudem ist noch ein Modul namens nickserv/oldlink enthalten, welches die Verlinkung der NickNames der älteren Services steuert. Dieses Modul soll den Benutzern der älteren IRC-Services-Generationen nur helfen mit dem neuen Format klarzukommen. In späteren Versionen wird dieses Module nicht mehr zur Verfügung stehen.

3-1-3. E-mail Autorisation

Um ein wenig Verantwortung in Bezug auf NickNames zu erschaffen, können die Services die werdenden Benutzer dazu zwingen, Ihren Account erst zu autorisieren.
Dies geschieht, indem man nach der NickName Registrierung einen nummerischen Code per e-Mail zugeschickt bekommt. Damit der Nick-Owner den kompletten Zugriff auf den registrierten NickName in Anspruch nehmen kann, hat er sich vorher dem jeweiligen Autorisierungscode bei den Services zurückzumelden.
Dies ist eine einmalige Aktion, um die Richtigkeit der angegebenen E-Mailadresse zu gewährleisten. Diese Funktionen basieren auf das NickServ/mail-Auth – Modul
Wenn dieses Modul in Funktion genommen wird, läuft der Registrierungsprozess wie folgt ab:
Der sendet den gewöhnlichen **register** Befehl zum NickServ(inkl. Passwort und E-Mailadresse).
Die normalen Registrierangsthecks werden absolviert. Das heißt es wird überprüft , ob der NickName ggf. gesperrt ist, ob die E-Mailadresse das richtige Format hat, oder ob sich sonstige Syntax-Fehler eingeschlichen haben.
Eine zufällige 9stellige Zahl wird generiert und dem jeweiligen NickName zugesprochen. Dieser wird dann ebenfalls an die gegebene E-Mailadresse geschickt.
Die E-Mail könne wie folgt aussehen:
Der Autorisierungscode für den NickName (Schutzgeist) lautet:978457898 Bitte autorisieren Sie sich wie folgt :

/msg NickServ AUTH 978457898

Diese E-Mail wurde von NickServ in Verbindung mit der Adresse Schutzgeist@fakeSchutzgeist.de Ihnen zugesandt.
Die Services informieren also den Benutzer, dass er sich beim NickServ mit dem zugeschickten Code autorisieren lassen muss, bevor er den NickName endgültig benutzen kann.
Der Benutzer sendet den Code mit Hilfe des **Auth -Befehls an NickServ
Die IRCServices werden diesen Code dann auf seine Gültigkeit checken und falls dies positiv ausfällt, wird der Nick komplett freigegeben und kann somit normal genutzt werden
Selbe Prozedur findet dann noch einmal statt, wenn man die jeweilige E-Mail über den set E-Mail Befehl ändert.

Sollte es zur Zeit der E-Mail-Zusendung bei Problemen mit dem Mailserver oder sonstiges kommen, so dass man diese Mail nicht empfangen kann, ist es möglich , eine Kopie dieser e-Mail ein weiteres mal zugesendet zu bekommen. Die Default-Einstellungen lässt diesen sogenannten sendauth Befehl nur einmal pro Tag zu. . Diese genaue Einstellung dieser Zeitspanne ist in der modules.conf setzbar. Der Eintrag hierfür lautet NSSendpassDelay.

Die Services sind somit auch fähig, NickNames, die die über eine gewisse Zeit nicht identifiziert worden sind zu droppen. Auch diese Zeiteinstellung ist in der modul.conf, unter NSNoAuthExpire editierbar.
Zudem haben die Services Admins noch folgende Befehle zur Verfügung,
setauth, getauth und clearauth, welche es ihnen erlaubt,
dem Benutzer etwas entgegen zu kommen.
Sethauth generiert einen neuen AutorisierungsCode für einen
bestimmten NickName (Benutzer), der Besitzer des Nicks muss diesen also zum Autorisieren benutzen.
GetAuth lässt den jeweiligen Auth-Code eines NickNames zusenden.
Der ClearAuth– Befehl löscht sämtliche Autorisierungscodes und lässt den
jeweiligen NickName wie gewohnt benutzen, als wenn er den Auth – Befehl genutzt hätte

3-1-4.Access-Liste ( ZugriffsListe)

In der Regel muss ein IRC-Benutzer sich beim NickServ identifizieren, bis die Services ihm die vollen Nick-Rechte zugestehen.
Die Zugriffs-Liste (Access-list) „verfügen über einen Weg“, der den Benutzer erlaubt sich über seine Hostadresse ( User@Host ) zu identifizieren.

Die NickName-ZugriffsListe ( hier auch AccessListe – genannt) enthält mehrere Masken. Diese Masken dürfen sogenannte Wildcards enthalten, vergleichbar mit der Ban-Maske in einem Channel, also für den Usernamen und den HostName. Wenn ein NickName das erste mal registriert wird, wird dieser ZugriffsListe automatisch der aktuelle Username und Host zugewiesen.
Wenn die NSFirstAccessWild Option gesetzt wurde, wird ein Teil des Hostnames (IP) mit Wildcards belegt. Nach der Registrierung kann jeder User selbst die Zugriff-liste einsehen bzw. verändern. Dies geschieht dann über den access Befehl.

Die Standardeinstellung lässt den jeweiligen Nick keine besonderen Rechte in einem ChatRaum, nur weil er auf diese bestimmte ZufriffsMaske passt, ohne das Nick-Passwort eingegeben zu haben. Die set secure Einstellung kann diese SicherheitsFunktion disablen.
Somit ist es dann möglich dem USER, der auf eine bestimmte NickServ-ZugriffsMaske passt, auch ChanServ-Zugriffe zu gewähren.

Die kill Option kann benutzt werden um User die für einen NickName keinen gültigen Access-Eintrag haben und welche sich nicht manuell identifizieren,
automatisch killen zu lassen oder ggf. einen anderen Namen aufzwingen.
Diese Option kann über den set kill Befehl auf „quick“ oder „immediate“ gesetzt werde.
Bei der „Quick-Einstellung“ hat der User der einen Nickname benutzt, indem seine Maske nicht in der Access-Liste aufgeführt wird, 20 Sekunden Zeit diesen zu identifizieren, andernfalls wird er nach Abstreichen dieser Zeit geforced (gekillt oder umbenannt).
Die Immediate-Einstellung greift sofort ein, wenn die Maske nicht auf eine in der ZufriffsListe (Access-List) vorhanden ist.
Sollte die kill immediate Funktion aktiv sein, die Access-Liste jedoch leer, wird niemand mehr fähig sein den jeweiligen Nick benutzen zu koennen.
Der ServicesAdmin muss diesen Nick dann droppen.

Warnung: Sollte ein Nickname-Besitzer diese Access-Liste in Anspruch nehmen und keine statische IP/Host besitzen,
so sollte er bei der Zugriffs-Liste mit Wildcards arbeiten!
Aus port-212-202-196-252.reverse.qdsl-home.de kann man port-*.reverse.qdsl-home.de machen.
Auch hier sei anzumerken, dass mit dieser Maske jeder qdsl-Kunde automatisch in der Zugriffs-Liste steht.
Daher sollte die Secure Option immer eingeschaltet sein, um die privilegierte Benutzung von Channel und Nick-Optionen zu verhindern.

Ab hier wurde eine Auto-Übersetzung genutzt.

3-1-5. Diverse Funktionen

Eine weitere zusätzliche Funktion ist über ein separates NickServ-Modul verfügbar:

• Autojoin-Listen (Modul nickserv / autojoin ), die dazu führen, dass Dienste einen Benutzer automatisch dazu bringen, bestimmten Kanälen beizutreten, wenn er sich nach seinem Spitznamen identifiziert. Dies kann beispielsweise für Benutzer nützlich sein, die eine Verbindung von gemeinsam genutzten Computern oder öffentlichen Terminals herstellen und den IRC-Client nicht so anpassen können, dass er beim Herstellen einer Verbindung automatisch den Kanälen beitritt. Die Liste der Kanäle, die automatisch verbunden werden sollen, kann mit dem Befehl AJOIN angezeigt und aktualisiert werden .Diese Funktionalität erfordert die Verwendung eines IRC-Servers, mit dem Benutzer zwangsweise mit bestimmten Kanälen (häufig als SVSJOIN bezeichnet ) verbunden werden können.

3-1-7. Befehls-Aliase

NickServ enthält eine einfache „Befehlsalias“ -Funktion, mit der (zum Beispiel) Abkürzungen für Befehle wie “ ID “ anstelle von “ IDENTIFY “ erstellt oder der Übergang von einem anderen dienstähnlichen Programm erleichtert werden kann. Aliase werden über die NSAlias- Konfigurationsanweisung in modules.conf erstellt . Das Parameterformat lautet “ alias = command „, wobei alias der neu zu erstellende Name (Alias) ist und command der bereits vorhandene Befehl ist, der ausgeführt werden soll, wenn ein Benutzer den Alias ​​verwendet. In einer einzelnen NSAlias- Direktive kann nur ein Alias ​​angegeben werden , es können jedoch mehrere Direktiven angegeben werden, um weitere Aliase zu erstellen.

Beachten Sie, dass rekursive Aliase nicht zulässig sind. Mit anderen Worten, wenn Sie einen Alias ​​“ ID “ für den Befehl IDENTIFY haben , können Sie keinen weiteren Alias I = ID erstellen . Wenn Sie versuchen, diesen Alias ​​zu verwenden, wird der Fehler “ Unbekannte Befehls-ID “ angezeigt .

Aliase sind auch für ChanServ und MemoServ über die Direktiven CSAlias und MSAlias in modules.conf verfügbar .

---

Channel Management (ChanServ)

3-2-1. Kernfunktionen von ChanServ

Genau wie bei Spitznamen können Kanäle auch bei Services registriert werden. Sobald Sie einen Kanal registriert haben, erhalten Sie von Services beim Betreten des Kanals automatisch die Berechtigungen des Kanalbetreibers („ops“), auch wenn Sie nicht der erste Benutzer im Kanal sind. Umgekehrt können andere Benutzer keine Operationen einfach dadurch erhalten der erste Benutzer im Kanal sein; Sie können auch andere Benutzer festlegen, denen automatisch Operationen oder Sprachberechtigungen gewährt werden (Modus + v ). Darüber hinaus speichern Dienste das Thema auf dem Kanal, auch wenn es nicht verwendet wird, und können verschiedene Modi auf dem Kanal erzwingen, z. B. + m (moderiert) oder + s (geheim).

Der Pseudoklient “ ChanServ “ ermöglicht den Zugriff auf die verschiedenen Kanalverwaltungsfunktionen, ähnlich wie NickServ es bei Spitznamen tut, und wie bei NickServ empfängt ChanServ Befehle über / msg . (Ebenso wie bei NickServ kann der Spitzname von ChanServ über eine Konfigurationseinstellung geändert werden: ChanServName in modules.conf .)

ChanServ die gleichen grundlegenden Befehle wie NickServ verwendet Kanäle für die Verwaltung: REGISTER einen Kanal als eigene, registrieren IDENTIFY – Privilegien über das Kennwort auf einem Kanal zu erhalten SET und UNSET verschiedenen Kanaloptionen festlegen, DROP eines Kanals Anmeldung zu löschen und LIST und INFO , um Informationen zu registrierten Kanälen anzuzeigen. Beachten Sie, dass bei der Registrierung eines Kanals zusätzlich zu einem Kennwort ein Parameter „description“ erforderlich ist. Diese Beschreibung wird in der Ausgabe der Befehle LIST und INFO angezeigt .

Standardmäßig darf ein einzelner Benutzer ( d. h. eine Nicknamegruppe) nicht mehr als 20 Kanäle registrieren. Jeder Versuch, Kanäle über diesem Grenzwert zu registrieren, führt zu einem Fehler. Diese Grenze kann über die geändert werden CSMaxReg Option in modules.conf . Außerdem verfallen Kanäle standardmäßig in 14 Tagen (änderbar über die CSExpire– Option in modules.conf ), wenn sie für diesen Zeitraum nicht „verwendet“ werden. Ausführliche Informationen zur Durchführung des Kanalablaufs finden Sie in Abschnitt 3-2-3 .

Wenn ein Benutzer einen Kanal registriert, wird dieser Benutzer als Gründer des Kanals in den Datenbanken von Services aufgezeichnet . Der Gründer eines Kanals empfängt beim Betreten automatisch Operationen in diesem Kanal und ist der einzige, der bestimmte ChanServ-Befehle verwenden darf, insbesondere SET und DROP . Kanalgründerrechte können entweder durch Identifizieren des Spitznamens, der zum Registrieren eines Kanals verwendet wird (oder eines damit verknüpften Spitznamens), wie in Abschnitt 3-1-1 beschrieben , oder durch Verwenden des Befehls ChanServ IDENTIFY mit dem bei der Registrierung angegebenen Passwort zum Identifizieren erhalten werden als Kanalgründer. Der Gründer eines Kanals kann mit dem SET FOUNDER geändert werden, ohne den Kanal zu löschen und neu zu registrieren Befehl.

Wenn der Spitzname des Gründers gelöscht wird oder wenn er abläuft und keine anderen nicht abgelaufenen Spitznamen damit verknüpft sind, wird der Kanal automatisch gelöscht. Wenn jedoch ein Nachfolger mit dem Befehl SET SUCCESSOR festgelegt wird , wird der als Nachfolger festgelegte Spitzname zum neuen Gründer des Kanals, und der Kanal wird nicht gelöscht (es sei denn, der Nachfolge-Spitzname hat bereits Kanäle bis zum Registrierungslimit registriert In diesem Fall wird der Kanal wie gewohnt gelöscht. Der Nachfolger eines Kanals kann mit dem Befehl UNSET SUCCESSOR gelöscht werden .

Wie bei NickServ kann das Passwort des Kanals nach der Registrierung mit dem Befehl SET PASSWORD geändert werden . Bei Verwendung mit ChanServ verfügt dieser Befehl jedoch über eine zusätzliche Funktion: Er löscht Gründerberechtigungen von allen anderen Benutzern, die diese Berechtigungen zuvor mit dem Befehl IDENTIFY erhalten haben , und jeder dieser Benutzer muss sich erneut mit dem neuen Kennwort identifizieren, um den Gründer wiederzugewinnen Privilegien.

Mit dem Befehl SET MLOCK kann der Gründer eines Kanals festlegen , dass Dienste immer bestimmte Modi auf dem Kanal einstellen oder löschen. Dieser Befehl wird ähnlich wie der Befehl IRC / mode verwendet , mit einer Liste von Moduszeichen, die mit + und – durchsetzt sind , möglicherweise gefolgt von Modusparametern (z. B. einer Kanaltaste oder einem Benutzerlimit für die Modi + k oder + l ). Der wichtige Unterschied besteht darin, dass die hier angegebenen Modi von den Diensten immer gezwungen werden, die angegebenen zu sein. Wenn beispielsweise für einen Kanal eine Modus-Sperre von + s festgelegt ist, setzen Services immer + s auf diesem Kanal, wenn ein Benutzer zum ersten Mal beitritt, und erlauben niemandem, -s festzulegen auf dem Kanal (umgekehrt würde eine Modus-Sperre von -s Benutzer daran hindern, + s auf dem Kanal einzustellen). Alle Modi, die nicht in der Modus-Sperre angegeben sind, werden weder ein- noch ausgeschaltet. Im vorherigen Beispiel einer Modus-Sperre von + s kann der + i- Modus von Kanalbetreibern frei eingestellt oder deaktiviert werden. Die Standardmodus-Sperre für einen neuen Kanal ist + nt ; Dies kann mit der geändert werden CSDefModeLock Konfigurationsdirektive in modules.conf .

Beachten Sie, dass das Festlegen bestimmter Modi in der Modus-Sperre eines Kanals dazu führt, dass Dienste Benutzer, die einem Kanal beitreten, automatisch kicken, wenn die gesperrten Modi diesem Benutzer normalerweise nicht erlauben würden, dem Kanal beizutreten. Dies soll die Tatsache kompensieren, dass der IRC-Server die Modus-Sperre nicht kennt und daher den unangemessenen Befehl JOIN vom Benutzer nicht ablehnen kann . Während keiner der Standard-IRC-Kanalmodi in diese Kategorie fällt, lösen Modi wie „Nur IRC-Operatoren“ ( + O in vielen Protokollen) und „Nur registrierte Spitznamen“ ( + R in vielen Protokollen) dieses Verhalten aus. Letzteres ( + R ) verdient besondere Erwähnung: Aufgrund der Funktionsweise von IRC können Netsplits und nachfolgende Netjoins dazu führen, dass einige Benutzer aus dem Programm genommen werden+ R- Kanäle, in die sie normalerweise zugelassen werden. Wenn dies zu Problemen führt, kann die Prüfung mit der Option CSSkipModeRCheck in modules.conf deaktiviert werden (mit dem Ergebnis, dass böswillige Benutzer möglicherweise Netsplits nutzen können, um + R- Kanäle mit nicht registrierten Spitznamen einzugeben ).

Weitere für den Befehl SET verfügbare Optionen sind DESC , um die Beschreibung des Kanals zu ändern. URL und E- MAIL , um eine URL oder E-Mail-Adresse für den Kanal festzulegen (beide können mit UNSET gelöscht werden ); ENTRYMSG , um eine Nachricht festzulegen , die von ChanServ an jeden Benutzer gesendet werden soll, der den Kanal betritt (dies kann auch mit UNSET gelöscht werden ); KEEPTOPIC , um festzulegen , ob das Thema des Kanals gespeichert wird, wenn sich niemand im Kanal befindet. PRIVATE , um festzulegen , ob der Kanal in den Ergebnissen für einen LIST- Befehl angezeigt werden soll . und SICHER, um die Kennwortsicherheit für Spitznamen für den Kanal zu erzwingen, auch für Spitznamen, für die die Option SICHER nicht festgelegt ist (wie in Abschnitt 3-1-5 beschrieben ).

Um einen Kanalgründer bei der Wiederherstellung der Kontrolle von einem böswilligen Benutzer oder einem außer Kontrolle geratenen Skript zu unterstützen, kann der Befehl CLEAR verwendet werden, um bestimmte Modi aus dem Kanal zu entfernen oder sogar alle Benutzer gleichzeitig aus dem Kanal zu entfernen (ein „Massen-„). trete“).

Zusätzlich kann ein Kanalgründer eine Autokick-Liste definieren , die auch als „AKICK-Liste“ bezeichnet wird, und zwar nach dem Befehl, der zum Verwalten der Liste verwendet wird, AKICK . Dies ist eine Liste von Benutzern, denen es nicht gestattet sein sollte, dem Kanal beizutreten. Sie ähnelt einer normalen Kanalverbotsliste (festgelegt mit / mode channel + b … ), außer dass sich die Dienste die Liste auch dann merken, wenn sich der Kanal befindet nicht in Gebrauch, und treten automatisch und verbieten Sie den Benutzer nach Bedarf. Neben den üblichen Unterbefehlen ADD , DEL und LIST stehen auch folgende Unterbefehle zur Verfügung:

• ANSICHT : Zeigt die Autokick-Liste an, ähnlich wie derUnterbefehl LIST, jedoch mit mehr Details (einschließlich des letztenMales, als ein Benutzer, der mit dem Eintrag übereinstimmt, versucht hat, dem Kanal beizutreten, was hilfreich sein kann, um veraltete Einträge zu finden).
• COUNT : Gibt die Anzahl der Einträge in der Autokick-Liste zurück.
• DURCHSETZEN : Bewirkt, dass Services alle Benutzer im Kanal anhand der Autokick-Liste überprüfen und alle Benutzer, die mit Einträgen in der Autokick-Liste übereinstimmen, treten und sperren. Dies kann verwendet werden, nachdem ein neuer Eintrag hinzugefügt wurde, anstatt den Benutzer manuell zu treten.

Wie bei NickServ sind mehrere Befehle für Services-Administratoren reserviert. Diese Befehle sind:

• SET NOEXPIRE
• GETPASS
• VERBIETEN
• AUSSETZEN
• UNSUSPEND

und arbeiten auf Kanälen genauso wie ihre NickServ-Entsprechungen auf Spitznamen; siehe den entsprechenden Teil von Abschnitt 3-1-1 . Die Hinweise in diesem Abschnitt des Befehls SET gelten auch in dem Sinne, dass sich Service-Administratoren nicht für einen Kanal identifizieren müssen, um seine Einstellungen zu ändern. Darüber hinaus dürfen Service-Administratoren verbotene und gesperrte Kanäle betreten.

Es ist auch möglich zu verhindern, dass normale Benutzer Kanäle registrieren. Die Konfigurationsoption CSEnableRegister (in modules.conf ) steuert, ob der Befehl REGISTER verfügbar ist. Wenn Sie diese Anweisung entfernen, lässt ChanServ die Registrierung neuer Kanäle nur von Dienstadministratoren zu (siehe Abschnitt 3-4-1 ). Bereits registrierte Kanäle können wie gewohnt mit Services verwendet werden.

Die meisten modernen IRC-Server verfolgen die Zeit, zu der ein Kanal erstellt wurde, und verwenden diese Zeit, um zu verfolgen, welcher Kanal während der Netzaufteilung der „ursprüngliche“ Kanal ist. Wenn sich beispielsweise Server A vom Netzwerk trennt und sich keine Benutzer auf Server A in Kanal #B befinden , verschwindet Kanal #B von Server A; Wenn ein Benutzer auf Server A den Kanal #B betritt Während der Server noch aufgeteilt ist, erhält er Kanalbetreiberrechte, die er (ohne diese Zeitstempel) auch nach dem erneuten Beitritt des Servers zum Netzwerk behalten würde. Dienste können diese Funktion nutzen, um den Zeitstempel registrierter Kanäle auf den Zeitpunkt der Kanalregistrierung einzustellen und sicherzustellen, dass die richtigen Modi des Kanals immer über Netsplits beibehalten werden. Diese Funktionalität wird mit der aktivierten CSSetChannelTime Konfigurationsoption in modules.conf(Beachten Sie, dass sich die Option im Abschnitt Protokollprotokoll und nicht im Abschnitt ChanServ-Modul befindet.) Die Verwendung dieser Option hat jedoch den unglücklichen Nebeneffekt, dass auf vielen IRC-Servern falsche Modusänderungen und Warnmeldungen generiert werden. Diese können ignoriert werden. Wenn sie sich jedoch als störend herausstellen, sollten Sie die Option deaktivieren. ( Einzelheiten finden Sie in FAQ E.11 .)

Beachten Sie schließlich, dass der Kanal “ # “ (ein einzelnes “ # “ – Zeichen ohne folgenden Namen) von den Diensten speziell behandelt wird. Obwohl dieser Kanal gemäß dem IRC-Protokoll (RFC 1459) legal ist und von den meisten, wenn nicht allen IRC-Servern unterstützt wird, erfordert er eine spezielle Behandlung für die Verwendung mit einer Reihe von Dienstfunktionen und tatsächlich auch Fehler in früheren Versionen von Diensten wie andere Dienste-ähnliche Programme haben Benutzer erlaubt, diese Programme über den Kanal “ # “ zum Absturz zu bringen . Um das Potenzial für solche Probleme zu vermeiden, lehnen Services die Registrierung (oder das Verbot) dieses Kanals ausdrücklich ab, was wiederum verhindert, dass andere Services-Funktionen mit ihm verwendet werden.

Aufgrund dieser (fehlenden) Behandlung können Benutzer den Kanal “ # “ frei nutzen. Wenn Sie dies stört, kann die Option CSForbidShortChannel in modules.conf aktiviert werden. Dadurch behandelt Services diesen Kanal als verbotenen Kanal und lässt keine Clients ihn verwenden. (Im Gegensatz zu normalen verbotenen Kanälen dürfen selbst Dienstadministratoren den Kanal nicht verwenden, wenn diese Option aktiviert ist.)

3-2-2. Kanalzugriffslisten

Der Rest der ChanServ-Befehle und -Optionen dreht sich um ein Konzept, das als Kanalzugriffsliste bezeichnet wird . Dies ist eine Liste von Spitznamen und zugehörigen Zugriffsebenen, die definiert, wer welche Berechtigungen für einen bestimmten Kanal erhalten soll. Abhängig von der einem Spitznamen zugewiesenen Zugriffsebene kann dem Benutzer dieses Spitznamens beim Betreten des Kanals automatisch ein Zugriff gewährt werden oder er darf privilegierte Befehle wie AKICK verwenden . Alternativ kann eine niedrige Zugriffsebene einen Benutzer daran hindern, Operationen auf dem Kanal zu erhalten oder überhaupt in den Kanal einzutreten.

Zugriffsebenen sind ganzzahlige Zahlen zwischen -999 und 999 einschließlich, wobei höhere Werte ein höheres Privileg bedeuten. Ein Benutzer, dessen Spitzname nicht in der Zugriffsliste enthalten ist oder der sich nicht für seinen Spitznamen identifiziert hat (außer wie in Abschnitt 3-1-5 für Kurznamen-Zugriffslisten beschrieben ), hat eine Zugriffsebene von 0 (Null). Ein Benutzer mit einer bestimmten Zugriffsebene verfügt über alle in Tabelle 3-1 aufgeführten Berechtigungen mit einer geringeren oder gleichen Mindestzugriffsebene. (Die Spalte „Name“ in der Tabelle bezieht sich auf Berechtigungsnamen für den Befehl LEVELS , der später erläutert wird .)Tabelle 3-1. Kanalberechtigungen und Standard-Mindestzugriffsebenen

Name	Niveau	Privileg
Automatic-mode privileges
AUTOVOICE	30	Automatikmodus + v (Sprache) beim Aufrufen des Kanals
AUTOHALFOP	40	Automatikmodus + h (Halfop) beim Aufrufen des Kanals (*)
AUTOOP	50	Automatikmodus + o (Kanalbetreiber) bei Kanaleintritt
AUTOPROTECT	100	Automatikmodus + a (geschützt) beim Betreten des Kanals (*)
Befehlsrechte
ACC-LISTE	0	Erlaubt die Verwendung des Unterbefehls LIST für den Befehl ACCESS
STIMME	30	Erlaubt die Verwendung der Befehle VOICE und DEVOICE
HALBOP	40	Erlaubt die Verwendung der Befehle HALFOP und DEHALFOP
ACC-CHANGE	40	Erlaubt die Verwendung des Befehls ACCESS
OPDEOP	50	Erlaubt die Befehle OP und DEOP
EINLADEN	50	Erlaubt die Verwendung des Befehls INVITE
EIN DIME	50	Erlaubt die Verwendung des UNBAN- Befehls
TRETE	50	Erlaubt die Verwendung des KICK- Befehls
THEMA	50	Erlaubt die Verwendung des Befehls TOPIC
SCHÜTZEN	100	Erlaubt die Verwendung des Befehls PROTECT
EIN TRITT	100	Erlaubt die Verwendung des Befehls AKICK
STATUS	100	Erlaubt die Verwendung des STATUS- Befehls
EINSTELLEN	(**)	Erlaubt die Verwendung der Befehle SET und UNSET
KLAR	(**)	Erlaubt die Verwendung des Befehls CLEAR
Andere Privilegien
MEMO	100	Erhält Kopien von Kanalnotizen (siehe Abschnitt 3-3-2 )

(*) Nur bei Unterstützung von IRC-Servern
(**) Nur Gründer

Automatische Modi

Die häufigste Verwendung von Zugriffslisten besteht darin, dass Dienste bestimmten Benutzern automatisch den Kanalbetreiber oder einen anderen Status geben, wenn sie den Kanal betreten. Wenn Sie beispielsweise einen Benutzer zur Zugriffsliste auf Ebene 50 (oder höher) hinzufügen, erhält dieser Benutzer beim Betreten des Kanals immer die Berechtigung eines Kanalbetreibers, auch wenn er nicht der erste Benutzer im Kanal ist. Das Hinzufügen eines Benutzers auf Stufe 30 (automatische Sprachausgabe) kann auf moderierten Kanälen (Modus + m ) hilfreich sein , damit ein Benutzer frei auf dem Kanal sprechen kann, ohne ihm Operationen zu geben. Beachten Sie, dass ein Benutzer ab Stufe 50 nicht Modus + v erhält , da die Berechtigung des Kanalbetreibers auch die Berechtigung zur Sprachübertragung impliziert.

Die verbleibenden Berechtigungen Auto-Halfop (Stufe 40) und Auto-Protect (Stufe 100) gelten nur für IRC-Server mit diesen Modi ( + h bzw. + a ) und führen dazu, dass Benutzern auf oder über diesen Ebenen die Berechtigung erteilt wird entsprechende Modi automatisch beim Beitritt. Wie bei + o und + v erhält ein Benutzer auf Stufe 40 ( + h ) nicht + v , und ein Benutzer auf Stufe 50 ( + o ) erhält nicht + h . Der Kanalschutz ( + a ) ist jedoch ein separater Status und wird zusätzlich zu + o und nicht stattdessen vergeben.

Umgekehrt werden einem Benutzer mit einer negativen Zugriffsebene (-1 oder weniger) keine Kanalbetreiber- oder Halfop-Berechtigungen gewährt. Selbst wenn ein anderer Kanalbetreiber für einen solchen Benutzer den Modus + o einstellt , wird er von den Diensten sofort entfernt. Darüber hinaus dürfen Benutzer mit einem Level von -100 oder weniger dem Kanal überhaupt nicht beitreten, und Services werden solche Benutzer treten und sperren, wenn sie versuchen, sich anzumelden. Beachten Sie, dass dieses Verhalten getrennt von den oben genannten Berechtigungen behandelt wird und nur mit den unten beschriebenen Befehlen SET SECUREOPS und SET RESTRICTED geändert werden kann.

Privilegierte Befehle

Eine Reihe von ChanServ-Befehlen steht nur Benutzern mit bestimmten Berechtigungen zur Verfügung. Diese sind unten aufgeführt.

Die Befehle VOICE , HALFOP , OP und PROTECT sowie ihre negativen Gegenstücke DEVOICE , DEHALFOP , DEOP und DEPROTECT sind die manuellen Entsprechungen der Berechtigungsstufen im Automatikmodus und können jeweils nur von Benutzern verwendet werden, die dies normalerweise tun würden den angegebenen automatischen Modus (oder einen besseren). Beispielsweise kann ein Benutzer auf Stufe 50 (Auto-Op) die Befehle VOICE , HALFOP und OP verwenden , nicht jedoch den Befehl PROTECT . Wie bei den automatischen Modi HALFOP / DEHALFOP und PROTECT/ DEPROTECT sind nur auf IRC-Servern verfügbar, die diese Modi unterstützen. Außerdem ist eine Kanaloption verfügbar ( SET OPNOTICE ), mit der Services bei jeder Verwendung eines dieser Befehle eine Nachricht an den Kanal senden.

Der Befehl ACCESS wird zum Ändern oder Anzeigen der Kanalzugriffsliste verwendet und wird nachfolgend erläutert . Beachten Sie, dass diesem Befehl zwei separate Berechtigungen zugeordnet sind: ACC-LIST zum Anzeigen der Zugriffsliste (stellen Sie sich dies als „schreibgeschützte“ Berechtigung für die Liste vor) und ACC-CHANGE zum Ändern („Lese- / Schreibzugriff“) „).

Die Befehle INVITE und UNBAN können von Benutzern mit ausreichenden Berechtigungen verwendet werden, um Einschränkungen beim Betreten eines Kanals zu umgehen. INVITE wird verwendet, um Services zu veranlassen, Sie zum Kanal „einzuladen“, als hätte ein Kanalbetreiber den IRC-Befehl / invade verwendet . Dies ist besonders nützlich, wenn Modus + i aktiviert ist (mit SET MLOCK ). UNBAN veranlasst Services, alle Verbote auf dem Kanal zu entfernen, die Sie am Betreten hindern.

Die Befehle KICK und TOPIC machen dasselbe wie ihre IRC-Entsprechungen / kick und / topic . Der letztere Befehl TOPIC ist besonders nützlich in Kombination mit der TOPICLOCK-Kanaloption (festgelegt mit SET TOPICLOCK ), die verhindert, dass Benutzer das Kanalthema ändern, außer über den Befehl TOPIC . Beachten Sie jedoch, dass mit dem Befehl KICK ein Benutzer mit dem Operator „Dienste“ oder höheren Berechtigungen (siehe Abschnitt 3-4-1 ) nicht gekickt werden kann.

Mit dem Befehl STATUS kann ein Benutzer die Zugriffsebene eines anderen Benutzers auf dem Kanal überprüfen.

Zugriffslistenbezogene Kanaloptionen

Neben den oben genannten Optionen OPNOTICE und TOPICLOCK stehen mehrere weitere Optionen für Kanalzugriffslisten zur Verfügung.

Dienste ergreifen normalerweise keine bestimmten Maßnahmen für automatische Modi, nachdem ein Benutzer dem Kanal beigetreten ist. So kann beispielsweise ein Auto-Op-Benutzer von einem anderen Kanalbetreiber gelöscht werden (oder er kann sich selbst deaktivieren), und die Dienste tun nichts. Durch Festlegen der Option „Durchsetzen“ mit SET ENFORCE können Dienste dazu gebracht werden, auf solche unangemessenen Modusänderungen zu achten und sie umzukehren, wenn sie auftreten.

Am anderen Ende des Spektrums weist die Option „Leave-Ops“ ( SET LEAVEOPS ) die Dienste an, den ersten Benutzer, der einem Kanal beitritt, nicht zu deaktivieren (ein solcher Benutzer erhält vom IRC-Server automatisch Ops). Dies kann nützlich sein, wenn ein Kanal nur registriert wird, um das Thema und die Modi des Kanals zu speichern oder eine Autokick-Liste zu erstellen, und die Steuerung der Kanalbetreiber- und Sprachberechtigungen nicht erforderlich ist. Informationen zu Problemen dieser Art finden Sie in Abschnitt 3-2-3 kann in Bezug auf Kanalablauf erhöhen.

Wie bereits erwähnt, wird Benutzern, die nicht in der Zugriffsliste aufgeführt sind, eine Zugriffsebene von 0 zugewiesen. Normalerweise bedeutet dies nur, dass die Benutzer keine besonderen Berechtigungen haben und von den Diensten im Wesentlichen ignoriert werden. Mit zwei Kanaloptionen kann dieses Verhalten jedoch geändert werden. SET SECUREOPS verhindert, dass Benutzer, die nicht auf der Zugriffsliste stehen, von anderen Benutzern abgelehnt werden, wie dies bei Benutzern mit negativen Zugriffsebenen der Fall ist. SET RESTRICTED verhindert, dass solche Benutzer überhaupt dem Kanal beitreten, und tritt und sperrt sie, wenn sie es versuchen.

Ändern der Zugriffsliste

Services bietet zwei Methoden zum Ändern der Zugriffsliste eines Kanals: den Befehl ACCESS , der vom Modul chanserv / access-level bereitgestellt wird , und den Befehlssatz SOP / AOP / HOP / VOP / NOP (häufig zusammen als XOP bezeichnet ), der vom bereitgestellt wird chanserv / access-xop- Modul. (Daher muss mindestens eines dieser beiden Module geladen sein, damit Zugriffslisten verwendet werden können!) Mit dem Befehl ACCESS kann die Zugriffsliste mithilfe von Zugriffsebenenwerten direkt angezeigt oder geändert werden, während die XOP- Befehle eine einfachere Schnittstelle mit fünf Ebenen bieten des Zugangs.

Sowohl der ACCESS- Befehl als auch der XOP- Befehlssatz haben dieselben Unterbefehle: ADD , um einen Benutzer (Kurznamen) zur Zugriffsliste hinzuzufügen, DEL , um einen Benutzer aus der Liste zu entfernen, LIST , um die Liste ganz oder teilweise anzuzeigen, und COUNT, um sie anzuzeigen die Anzahl der Einträge in der Liste. Wenn der Zugriffsliste ein Spitzname hinzugefügt wird, erhalten alle Spitznamen in derselben Gruppe (siehe Abschnitt 3-1-3 zur Verknüpfung von Kurznamen) dieselben Berechtigungen. Der Spitzname, der bei Verwendung des Befehls LIST angezeigt wird, ist derjenige, der als „Haupt-Spitzname“ für die Gruppe markiert ist (mit dem Befehl NickServ SET MAINNICK festgelegt ).

Beide Methoden arbeiten intern mit derselben Liste von Spitznamen und Zugriffsebenen, und tatsächlich können beide gleichzeitig verwendet werden (mit bestimmten Ausnahmen, die am Ende dieses Abschnitts erläutert werden ). Der Unterschied zwischen den beiden Methoden besteht darin, wie Zugriffslisteneinträge vom Standpunkt des Benutzers aus verwaltet werden.

Der Befehl ACCESS bietet direkten Zugriff auf die Liste der Spitznamen und Zugriffsebenen, aus denen die Kanalzugriffsliste besteht. Zum Beispiel könnte ein Befehl wie “ ACCESS #somechannel ADD SomeNick 50 “ verwendet werden, um den Spitznamen „SomeNick“ zur Zugriffsliste des Kanals „#somechannel“ auf Ebene 50 hinzuzufügen (Auto-Op). Der Unterbefehl ADD kann auch verwendet werden, um die Ebene eines Benutzers zu ändern, der sich bereits in der Liste befindet, ohne ihn zuerst aus der Liste entfernen zu müssen. Wenn Sie einen neuen Benutzer zur Zugriffsliste hinzufügen oder die Zugriffsebene eines Benutzers ändern, der bereits in der Liste enthalten ist, wird die Ebene dem ADD zugewiesenDer Befehl muss strikt unter der Zugriffsebene des Benutzers liegen, der den Befehl erteilt. Wenn Sie einen Benutzer entfernen oder die Zugriffsebene eines Benutzers ändern, muss auch die aktuelle Zugriffsebene des Benutzers, der entfernt oder geändert wird, niedriger sein als die des Benutzers, der den Befehl erteilt. Der Gründer eines Kanals hat eine höhere Zugriffsebene als jeder andere Benutzer auf diesem Kanal.

Der Befehl ACCESS enthält außerdem den zusätzlichen Unterbefehl LISTLEVEL , mit dem die Zugriffsliste nach Ebene und nicht nach Spitzname gefiltert wird.

Der XOP- Befehlssatz hingegen behandelt die Zugriffsliste als fünf (vier, auf IRC-Servern, die keine Halfops unterstützen) separate Listen, die jeweils von einem eigenen Befehl verwaltet werden:

• SOP (Stufe 100) für die „Super-Op“ -Liste (Auto-Op, Auto- Protect auf unterstützenden Servern und Zugriff auf den AKICK- Befehl);
• AOP (Stufe 50) für die Auto-Op-Liste (Auto-Op und Zugriff auf die meisten privilegierten Kanalbefehle);
• HOP (Stufe 40) für die Auto-Halfop-Liste (nur auf Servern verfügbar, die Halfops unterstützen);
• VOP (Stufe 30) für die Auto-Voice-Liste; und
• NOP (Level -1) für die Never-Op-Liste.

Dieses System, das grob auf dem System basiert, das von DALnet [ www.dal.net ] -Diensten und anderen dienstähnlichen Programmen verwendet wird, verbirgt die numerischen Zugriffsebenen vor dem Benutzer und bietet ihnen stattdessen einen kleinen Satz unterschiedlicher Ebenen zur einfachen Steuerung . Da der Name des Befehls direkt die Zugriffsebene angibt, muss der Benutzer mit dem Unterbefehl ADD keine explizite Zugriffsebene angeben. Wie beim Befehl ACCESS können Benutzer Benutzer nur zu Listen hinzufügen oder aus Listen entfernen, die eine niedrigere Zugriffsebene als ihre eigene haben. Beispielsweise kann ein Benutzer in der AOP- Liste nur die HOP- , VOP- und NOP- Listen ändern .

Da der XOP- Befehlssatz intern für eine einzelne Zugriffsliste ausgeführt wird, wird der Versuch, einen Benutzer zu einer XOP- Liste hinzuzufügen, wenn sich dieser Benutzer bereits in einer anderen solchen Liste befindet, wie beim Befehl ACCESS ADD als Änderung der Zugriffsebene behandelt . Der Befehl schlägt fehl, wenn sich der hinzugefügte Benutzer bereits in derselben oder einer höheren Liste befindet als der Benutzer, der den Befehl erteilt, und wenn der Befehl erfolgreich ist, wird der Zielbenutzer aus der Liste entfernt, in der er zuvor war. Außerdem sind Benutzer, die mit dem Befehl ACCESS ADD auf einer anderen Ebene als den fünf oben angegebenen Zugriffsebenen (100, 50, 40, 30 oder -1) zur Zugriffsliste hinzugefügt wurden, für die XOP- Befehle unsichtbar .

Ändern der Mindestzugriffsebenen für Berechtigungen

Erfahrene Benutzer möchten möglicherweise die für bestimmte Berechtigungen erforderlichen Mindestzugriffsebenen ändern. Beispielsweise könnte man das AUTOVOICE- Privileg auf einen Mindestwert von Null setzen, was bedeutet, dass Benutzer, die nicht auf der Zugriffsliste stehen, beim Betreten des Kanals automatisch Modus + v erhalten . Dies kann über den Befehl LEVELS erreicht werden , der vom Modul chanserv / access-level (das auch den Befehl ACCESS bereitstellt ) bereitgestellt wird .

Der Befehl LEVELS verfügt über vier primäre Unterbefehle. SET verwendet einen Berechtigungsnamen (aus der Spalte „Name“ in Tabelle 3-2) und eine Zugriffsebene und legt die Mindestzugriffsebene für diese Berechtigung auf die angegebene Ebene fest. DISABLE (was mit DIS abgekürzt werden kann ) deaktiviert ein Privileg. Bei Berechtigungen für den automatischen Modus bedeutet dies, dass keine Benutzer den Modus unabhängig von ihrer Zugriffsebene erhalten. Bei Berechtigungen für Befehle bedeutet dies, dass nur der Gründer den betreffenden Befehl verwenden darf. RESET setzt alle Berechtigungen auf ihre Standardstufen zurück und LIST zeigt die Mindestzugriffsebene für jede Berechtigung auf dem Kanal an.

Bei der Verwendung des Befehls LEVELS in Kombination mit dem XOP- Befehlssatz ist Folgendes zu beachten : Da die XOP- Befehle immer dieselben festen Zugriffsebenen (100, 50, 40, 30 und -1) verwenden, müssen Sie die Ebenen des automatischen Modus ändern kann insbesondere unerwartete Auswirkungen haben! Wenn beispielsweise die Auto-Op-Stufe auf 75 erhöht wird, erhalten Benutzer in der AOP -Liste (angeblich „Auto-Op“) beim Betreten des Kanals keine Operationen. Im Allgemeinen ist es keine gute Idee, die Befehle LEVELS und XOP auf demselben Kanal zu verwenden.

Zurück nach oben

3-2-3. Kanalablauf

Der Kanalablauf ist ein etwas komplexes Problem. Das Hauptproblem bei der Bestimmung, wann ein Kanal abläuft, ist: Wie bestimmen Sie, ob der Kanal „verwendet“ wird?

Eine einfache Idee besteht darin, zu messen, wann ein Benutzer das letzte Mal im Kanal war. Dies kann jedoch unter bestimmten Umständen übermäßig schützend sein. Angenommen, Benutzer A hat den Kanal #mychannel registriert , verwendet ihn jedoch nicht mehr. Einen Tag vor Ablauf des Kanals kommt Benutzer B in das Netzwerk und möchte #mychannel selbst verwenden, ohne jedoch zu wissen, dass er bereits registriert wurde. Wenn Benutzer B den Kanal betritt, teilt ChanServ ihr mit, dass er registriert ist – und aktualisiert die zuletzt verwendete Zeit, sodass sie viel länger als einen Tag warten muss, bevor der Kanal endgültig freigegeben wird.

Es ist klar, dass Dienste eine Möglichkeit benötigen, um zu bestimmen, ob ein Benutzer als Benutzer des registrierten Kanals betrachtet werden soll, im Gegensatz zu einem nicht verwandten Benutzer, der gerade den Kanal betreten hat. Die Vielzahl der Kanalverwaltungsstile macht dies schwierig. Da jedoch die meisten Kanäle wahrscheinlich das Auto-Op-Kanalprivileg nutzen (wie in Abschnitt 3-2-2 beschrieben ), verwenden Services dieses Privileg als Grundlage für die Bestimmung, an wen sie sich wenden sollen zählen als Benutzer des registrierten Kanals.

Daher lautet die Regel für Kanalablauf: Der Ablaufzeitgeber eines Kanals zählt ab dem letzten Mal, als ein Benutzer mit Auto-Op-Berechtigungen im Kanal anwesend war. (Diese Zeit ist die „zuletzt verwendete Zeit“, die in den Kanalinformationen angezeigt wird.) Folglich verfallen Kanäle nicht, solange sich ein Benutzer mit Auto-Op-Berechtigungen im Kanal befindet.

Wenn Sie nur die XOP- Befehle zum Ändern der Kanalliste verwenden, ist dies leicht zu verstehen: Jeder in den AOP- und SOP- Listen sowie der Kanalgründer bewirken, dass die zuletzt verwendete Zeit des Kanals aktualisiert wird. Ebenso setzt jeder Benutzer mit Zugriffsstufe 50 oder höher mit dem Befehl ACCESS den Ablauf-Countdown zurück. Wenn Sie jedoch den Befehl LEVELS verwenden , um die Auto-Op-Berechtigungsstufe zu ändern, gilt dies nicht mehr. Insbesondere wenn Sie das Auto-Op-Kanalprivileg deaktivieren, können Sie nicht verhindern, dass der Kanal abläuft!

Für diese Überprüfungen verwenden die Dienste außerdem die aktuellen Kanalberechtigungen jedes Benutzers für den Kanal. Selbst wenn der Kanalgründer im Kanal verbleibt, wird er nicht als Kanalbenutzer gezählt, es sei denn, er hat sich für seinen Spitznamen identifiziert (oder die Optionen Spitzname und Kanal SICHER sind deaktiviert).

Zurück nach oben

---

3-3. Memo senden (MemoServ)

3-3-1. MemoServ-Kernfunktionen

„Memos“ sind Kurznachrichten, die an Benutzer gesendet werden können, auch wenn diese nicht online sind. Sie werden von den Diensten gespeichert, damit der Empfänger sie später lesen kann. Memos werden vom Pseudoklienten “ MemoServ “ verarbeitet, der genauso funktioniert wie NickServ und ChanServ. (Der Spitzname kann über die geändert werden MemoServName Option in modules.conf.) Um potenzielle Probleme mit anonymen Überflutungen von Memos und anderen Problemen zu vermeiden und die Speicherung von Memos zu vereinfachen, muss sich ein Benutzer bei MemoServ registrieren und seinen Spitznamen identifizieren, bevor er Memos sendet oder empfängt oder andere memo-bezogene Vorgänge ausführt. Wenn ein Benutzer zwei oder mehr Spitznamen zu einer Gruppe verknüpft hat, haben alle diese Spitznamen denselben Satz von Memos, und Memos zu einem Spitznamen in der Gruppe können mit einem anderen gelesen werden.

Das Senden eines Memos an einen anderen Benutzer erfolgt über den Befehl SENDEN . Wenn Sie ein Memo an einen Benutzer senden, wird es in der Datenbank der Dienste gespeichert und kann vom Empfänger beim nächsten Herstellen einer Verbindung gelesen werden. Wenn der Empfänger zum Zeitpunkt des Versands des Memos online ist (und anhand seines Spitznamens identifiziert wurde), erhält er eine Benachrichtigung, dass ein Memo an ihn gesendet wurde. Wenn die Verknüpfung von Spitznamen aktiviert ist, erhält der Empfänger auch eine Benachrichtigung, wenn er einen Spitznamen verwendet, der mit dem Spitznamen verknüpft ist, der das Memo erhalten hat.

Wenn ein Benutzer ein Memo erhält, kann er mit dem Befehl READ dessen Inhalt anzeigen. Dieser Befehl zeigt den Text des Memos an, dessen Nummer mit dem Befehl angegeben wird (die Zeichenfolge “ LAST “ kann verwendet werden, um „das zuletzt empfangene Memo “ zu bedeuten , oder “ NEW „, um „alle ungelesenen Memos“ zu bedeuten) sowie das Spitzname des Benutzers, der es gesendet hat, sowie Datum und Uhrzeit des Versands. Es ist auch möglich, mehrere Memos gleichzeitig zu lesen, indem die Zahlen durch Kommas (für einzelne Memos) oder Bindestriche (für Memobereiche) getrennt werden. Beispiel: “ READ 2,4-6,9 “ bewirkt, dass die Memos 2, 4, 5, 6 und 9 angezeigt werden.

Wenn ein Benutzer mehrere neue Memos hat oder nach einem alten Memo suchen möchte, ist es normalerweise einfacher, eine einzeilige Liste mit Memos abzurufen. Dies wird mit dem Befehl LIST erreicht , der den Spitznamen und die Uhrzeit des Absenders anzeigt, die für jedes angeforderte Memo gesendet wurden. Dieser Befehl kann entweder eine einzelne Memonummer, eine Liste oder einen Zahlenbereich, die Zeichenfolge “ NEU “ für alle neuen Memos oder gar nichts zum Auflisten jedes gespeicherten Memos verwenden.

Sobald ein Memo gelesen wurde, wird es normalerweise nicht mehr benötigt und kann gelöscht werden. In der Tat kann , da eine einzige Spitznamen Gruppe nur eine begrenzte Anzahl von Memos (20 standardmäßig änderbar über die Empfangs MSMaxMemos Option in modules.conf ), Löschen nicht benötigte Memos wichtigen Platz für neue zu machen. Dies geschieht mit dem Befehl DEL , der als Parameter eine einzelne Memonummer oder eine Liste von Nummern verwendet, oder mit der Zeichenfolge “ ALL „, um jedes gespeicherte Memo zu löschen. Beachten Sie, dass das Löschen ein irreversibler Vorgang ist: Sobald Memos gelöscht wurden, gibt es keine Möglichkeit, sie zurückzubekommen!

Wenn die MSExpire- Option in modules.conf festgelegt ist , werden Memos nach dem mit dieser Option angegebenen Zeitraum automatisch gelöscht, auch wenn sie nicht explizit mit dem Befehl DEL gelöscht werden (ungelesene Memos werden niemals automatisch gelöscht). Der Befehl SAVE ist jedoch verfügbar, um bestimmte Memos als nicht ablaufend zu markieren. Sobald ein Memo so markiert ist, bleibt es so, bis der Befehl DEL zum Löschen verwendet wird, und wird niemals automatisch gelöscht.

Um zu vermeiden , alt , aber ungelesen Memos aus sofort gelöscht wird auf gelesen werden, die MSExpireDelay kann Option in eingestellt wird modules.conf . Wenn diese Option aktiviert ist , gibt sie an, wie lange Services nach dem ersten Lesen des Memos warten sollen , bevor das Memo abläuft. Wenn der Ablauf des Memos nicht verwendet wird, wird diese Option ignoriert.

Beachten Sie, dass sich die Anzahl späterer Memos nicht ändert , wenn ein Memo in der Mitte der Memoliste gelöscht wird oder abläuft . Dies soll verhindern, dass aufeinanderfolgende DEL- Befehle das Falsche (nicht intuitive) tun. Stellen Sie sich beispielsweise einen Benutzer mit vier Memos mit den Nummern 1, 2, 3 und 4 vor. Wenn der Benutzer den Befehl DEL 2 gibt , wird Memo 2 gelöscht, die Memos 3 und 4 bleiben jedoch als Memos 3 und 4 erhalten. Wenn der Benutzer dann DEL 3 eingibt , wird das dritte Memo in der ursprünglichen Liste gelöscht. (Wenn die Memos automatisch neu nummeriert wurden, DEL 3würde stattdessen löschen, was ursprünglich Memo 4 war – wahrscheinlich nicht das, was der Benutzer tun wollte!) Dies hinterlässt jedoch „Lücken“ in der Nummerierung, und wenn ein Benutzer einige Memos für eine lange Zeit aufbewahrt oder Memos häufiger empfängt als sie ablaufen, Sie können sehr große Memo-Nummern haben. Um dieses Problem zu beheben, kann der Benutzer den Befehl RENUMBER verwenden , mit dem die Memos des Benutzers in derselben Reihenfolge gehalten werden, die Nummern jedoch nacheinander beginnend mit 1 neu zugewiesen werden.

Normalerweise werden Benutzer benachrichtigt, wenn sie sich mit dem Netzwerk verbinden, über neue Memos. Außerdem werden sie benachrichtigt, wenn sie neue Memos erhalten, wie oben beschrieben. Dieses Verhalten kann mit dem Befehl SET NOTIFY geändert werden . Benutzer können auch ein Limit für die Anzahl der Memos festlegen, die sie zwischen 0 empfangen können, wodurch verhindert wird, dass der Benutzer überhaupt Memos empfängt, und das Standardlimit mit dem Befehl SET LIMIT . (Beachten Sie jedoch, dass das Limit für von Dienstadministratoren gesendete Memos ignoriert wird.)

Der Befehl SET LIMIT ist jedoch eher für Dienstadministratoren gedacht (siehe Abschnitt 3-4-1 ), die ihn verwenden können, um einem Spitznamen das Empfangen einer unbegrenzten Anzahl von Memos zu ermöglichen (“ SET LIMIT- Spitzname NONE „) oder um einen Benutzer zu verhindern das eigene Limit nicht ändern (“ SET LIMIT Spitzname 0 HARD „, um ein Limit von 0 zu erzwingen und den Empfang von Memos zu verhindern).

Schließlich kann der Befehl INFO verwendet werden, um die Anzahl der gespeicherten und ungelesenen Memos, das Memolimit und die Benachrichtigungsoptionen eines Benutzers anzuzeigen. Normale Benutzer können diesen Befehl nur für ihren eigenen Nick verwenden, während Services-Administratoren Memoinformationen für jeden Nick anzeigen können (“ INFO- Nickname „).

Zurück nach oben

3-3-2. Memos und Kanäle

Während MemoServ normalerweise zum Senden von Nachrichten von einem Benutzer (Spitzname) an einen anderen verwendet wird, kann es auch verwendet werden, um stattdessen Nachrichten für einen Kanal zu hinterlassen. In diesem Fall wird das Memo an den Gründer des Kanals und an jeden Benutzer mit dem MEMO- Privileg auf dem Kanal gesendet (siehe Abschnitt 3-2-2 ). Der Kanal muss registriert sein, um Memos empfangen zu können. Wenn die Kanaloption MEMO-RESTRICTED für den Kanal festgelegt ist, dürfen nur Benutzer mit der Berechtigung MEMO Memos an den Kanal senden.

Wenn Sie das Memo senden, reicht es aus, den Ziel-Spitznamen einfach durch einen Kanalnamen zu ersetzen, um das Memo zu senden. Jeder Benutzer dieses Kanals mit dem MEMO- Privileg wird über das neue Memo informiert (abhängig von der Einstellung SET NOTIFY des Benutzers ) und kann es mit den Befehlen READ oder DEL wie normale Memos lesen oder löschen . Um Kanalmemos von normalen Memos zu unterscheiden, enthalten die Dienste den Namen des Kanals, an den das Memo gesendet wurde, wenn Benutzer über Kanalmemos benachrichtigt oder diese angezeigt werden.

Da ein Kanalmemo mehrere Empfänger haben kann, kann das Memo möglicherweise nicht an alle Empfänger gesendet werden. Beispielsweise ist einer der Empfänger möglicherweise im Urlaub und hat Memos für seinen Spitznamen deaktiviert. Die Dienste sagen jedoch „Nachricht erfolgreich gesendet“, wenn das Memo an mindestens einen Benutzer gesendet wurde. Nur wenn nicht alle Empfänger das Memo empfangen können, wird von Services eine Fehlermeldung angezeigt.

Zurück nach oben

3-3-3. Memo-Ignorierlisten

Gelegentlich möchten Benutzer möglicherweise vermeiden, Memos von bestimmten anderen Benutzern zu erhalten, z. B. in Fällen von Belästigung. Mit dem Memoserv / Ignorier- Modul können Benutzer genau das tun, indem sie eine Ignorierliste von Platzhaltermasken (die entweder Spitznamen- oder User @ Host- Masken sein können) verwalten, von denen Memos nicht empfangen werden sollen. Wenn ein Memo an den Benutzer gesendet wird, vergleicht Service den Nicknamen und Benutzer @ Host – Adresse des Absenders zu jedem Eintrag auf der Empfängerliste zu ignorieren; Wenn eine Übereinstimmung gefunden wird, lehnt der Dienst das Senden des Memos ab und informiert den Absender darüber, dass der Empfänger „keine Memos empfangen darf“ (unter Verwendung derselben Nachricht, die gesendet wird, wenn der Empfänger SET LIMIT 0 verwendet hatBefehl, den Empfang von Memos überhaupt zu verhindern; Auf diese Weise kann der Absender nicht direkt feststellen, ob der Benutzer alle Memos oder nur Memos von diesem bestimmten Spitznamen oder dieser bestimmten Adresse ablehnt. IGNORE blockiert auch die Übermittlung von Kanalnotizen von Benutzern in der Ignorierliste.

Der Befehl IGNORE wird zum Verwalten der Ignorierliste verwendet. Es verfügt über drei Unterbefehle: ADD eine Maske hinzufügen , um die Liste zu ignorieren, DEL , eine Maske zu löschen und LIST alle Masken auf der Liste angezeigt werden soll .

Zurück nach oben

3-3-4. Weiterleitung von Memos

Einige Benutzer finden es möglicherweise einfacher, ihre Memos direkt an ihre E-Mail-Adresse weiterzuleiten, als eine Verbindung zum IRC herzustellen, um sie zu überprüfen. Das memoserv / forward- Modul ermöglicht es Benutzern, dieses Verhalten für ihre Spitznamen auszuwählen, und konvertiert jedes Memo an den Benutzer in eine E-Mail-Nachricht, die an die mit dem Spitznamen registrierte E-Mail-Adresse gesendet wird. (Um Spam zu vermeiden, muss für dieses Modul die E-Mail-Authentifizierung mit dem Spitznamen aktiv sein. Weitere Informationen finden Sie in Abschnitt 3-1-4 .) Beachten Sie, dass für dieses Modul ein E-Mail-Modul ( Abschnitt 3-8 ) geladen werden muss, damit es funktioniert.

Wenn dieses Modul geladen ist, können Benutzer mit dem Befehl SET FORWARD auswählen, ob ihre Memos an ihre E-Mail-Adresse weitergeleitet werden sollen. Diese Option kann entweder auf “ EIN “ (Memos per E-Mail weiterleiten), “ AUS “ (nicht weiterleiten) oder “ KOPIEREN “ (Memos weiterleiten, aber auch eine Kopie in der Servicedatenbank speichern) eingestellt werden. Bei der Option KOPIEREN gilt das Limit für die Anzahl der gespeicherten Memos pro Spitznamengruppe auch für E-Mails: Wenn das Limit erreicht ist, werden alle weiteren Memos abgelehnt, obwohl sie möglicherweise per E-Mail gesendet wurden. In einem solchen Fall muss der Benutzer eine Verbindung zum IRC herstellen und nicht benötigte Memos löschen, bevor er weitere empfangen darf, so als ob die Option FORWARD auf gesetzt wäre AUS .

Darüber hinaus steht ein separater FORWARD- Befehl zur Verfügung, mit dem Benutzer Memos selektiv an ihre E-Mail-Adresse weiterleiten können. Dies kann beispielsweise nützlich sein, um bestimmte Nachrichten in einer dauerhafteren Form zu speichern, ohne dass jedes einzelne Memo an die eigene Mailbox gesendet wird.

Zurück nach oben

---

3-4. Netzwerk- / Dienststeuerung und -wartung (OperServ)

3-4-1. Berechtigungsstufen für Dienste

Bevor die Funktionen von OperServ erläutert werden, muss das Konzept der Berechtigungsstufen für Services verstanden werden . Hierbei handelt es sich um Berechtigungsstufen, die IRC-Operatoren zugewiesen werden und sowohl von OperServ als auch von anderen Teilen von Diensten verwendet werden, um den Zugriff auf bestimmte Funktionen zu beschränken. Es gibt vier verschiedene Berechtigungsstufen für Dienste, die ein Benutzer haben kann:

• Kein Privileg
• Dienstbetreiberprivileg
• Administratorrechte für Dienste
• Services super-user privilege

Standardmäßig haben alle Benutzer keine besonderen Berechtigungen.

Mit der Berechtigung „Dienstbetreiber“ (auch als „Dienstbetreiber“ oder „Dienstbetreiber“ bezeichnet) können IRC-Bediener den Modus eines beliebigen Kanals ändern oder Benutzer von jedem Kanal aus oder „Massenvernichter“ -Benutzer, die denselben Hostnamen verwenden (z. B. Klone) Ändern Sie die Autokill-, Sitzungsausnahme- und S-Line-Listen, wenn die relevanten Module verwendet werden. Dies ist für IRC-Operatoren gedacht, denen vertraut werden kann, dass sie nicht im Netzwerk wild laufen. Mit dem Befehl OPER können Sie die Liste der Benutzer mit dem Dienststatus „Dienste“ ändern oder anzeigen.

Mit der Berechtigung „Dienstadministrator“ (auch als „Dienstadministrator“ oder „Servadmin“ bezeichnet) können IRC-Bediener die Dienste selbst steuern. Dienstadministratoren können verschiedene Dienstoptionen festlegen, die Konfigurationsdateien erneut aufbereiten (erneut lesen) und Einstellungen aktualisieren sowie Dienste neu starten oder vollständig beenden. Die Administratorrechte für Dienste sind auch erforderlich, um die Betreiberliste für Dienste zu ändern oder um die Superbenutzerberechtigung für Dienste zu erhalten (siehe unten). Der ADMINMit diesem Befehl können Sie die Liste der Benutzer mit dem Administratorstatus „Dienste“ ändern oder anzeigen. Beachten Sie, dass die Vergabe des Administratorstatus eines Benutzers dazu führt, dass er aus der Liste der Dienste-Operatoren entfernt wird, wenn er sich darauf befindet. Benutzer in der Services-Administratorliste müssen zuerst aus dieser Liste entfernt werden, bevor sie zur Services-Operatorliste hinzugefügt werden können. Dadurch wird verhindert, dass ein Services-Administrator die Berechtigungsstufe eines anderen Herabstufens herabsetzt, indem er sie zu einem Services-Operator macht.

Dienstleistungen Super-User (auch als „Service root“ bekannt, nach dem Unix Superuser Benutzername root ) Privileg ist die höchsten Leistungen Berechtigungsebene zur Verfügung und wird zum Modifizieren der Services – Administrator – Liste erforderlich. Es ermöglicht auch die Verwendung des gefährlichen RAW – Befehls, der von Dienstleistungen ohne Intervention Text direkt an das IRC – Netzwerk sendet, wenn die AllowRaw Option wird in gesetzt modules.conf ; Dies kann nützlich sein, um neue Funktionen eines IRC-Servers zu testen. Eine unsachgemäße Verwendung kann jedoch dazu führen, dass sich Dienste und andere Server im Netzwerk nicht ordnungsgemäß verhalten oder sogar abstürzen. Normalerweise wird nur der Spitzname angegeben, der mit der ServicesRoot- Konfigurationsanweisung in modules.conf angegeben wurdeverfügt über das Superuser -Privileg „Dienste“. Wenn dieser Benutzer jedoch mit dem Befehl “ SET SUPASS“ ein Superuser -Kennwort festlegt , können Services-Administratoren temporäre Superuser -Privilegien für Services erhalten, indem sie dieses Kennwort mit dem Befehl “ SU“ vergeben .

Als besondere Ausnahme von den normalen Regeln zum Löschen und Ablaufen von Kurznamen läuft der mit der ServicesRoot- Direktive als Services- Superuser festgelegte Kurzname unabhängig von der Einstellung der NOEXPIRE- Option des Kurznamens niemals ab und kann von anderen Services-Administratoren nicht mit dem Befehl DROPNICK gelöscht werden . Dies verhindert, dass nicht autorisierte Benutzer das versehentliche oder absichtliche Löschen des Spitznamens nutzen, indem sie ihn selbst neu registrieren.

Zurück nach oben

3-4-2. Kernfunktionen von OperServ

In diesem Abschnitt werden die Kernfunktionen von OperServ (im operserv / main- Modul) erläutert . Es ist nach Berechtigungsstufe „Dienste“ in vier Unterabschnitte unterteilt:

• Befehle für alle IRC-Operatoren
• Befehle, die auf Dienstbetreiber beschränkt sind
• Befehle, die auf Dienstadministratoren beschränkt sind
• Befehle, die auf den Superuser „Dienste“ beschränkt sind

Ein IRC-Operator mit einer bestimmten Berechtigungsstufe für Dienste hat auch Zugriff auf Befehle für niedrigere Berechtigungsstufen. Beispielsweise hat ein Services-Administrator auch Zugriff auf Services-Operatorbefehle, und ein Benutzer mit Services-Superuser-Berechtigungen kann jeden OperServ-Befehl verwenden. Wenn ein Benutzer, der kein IRC – Operator ist ein Befehl an OperServ sendet, wird es unabhängig vom Inhalt verweigert werden, und (wenn die WallBadOS Option gesetzt modules.conf ) wird eine Meldung an alle Online – IRC – Betreiber übertragen.

Beachten Sie, dass alle an OperServ gesendeten Befehle in der Services-Protokolldatei aufgezeichnet sind (mit Ausnahme der Kennwörter, die für die unten beschriebenen Befehle SU und SET SUPASS angegeben wurden). Achten Sie also auf Ihre Eingabe!

Befehle für alle IRC-Operatoren

IRC-Betreiber ohne Dienstberechtigungen sind in erster Linie auf Befehle zum Anzeigen des aktuellen Status von Diensten und des IRC-Netzwerks beschränkt. Zu diesen Befehlen gehören der Befehl STATS , der die seit dem Start der Dienste verstrichene Zeit sowie die aktuelle / maximale Anzahl von Benutzern und IRC-Operatoren anzeigt , und der Befehl SERVERMAP , der die Topologie des IRC-Netzwerks aus Sicht der Dienste anzeigt. Mit einem anderen Befehl, GLOBAL , kann eine Benachrichtigung an alle Benutzer im IRC-Netzwerk gesendet werden.

Darüber hinaus können die Befehle ADMIN und OPER von jedem IRC-Operator verwendet werden, um die aktuelle Liste der Dienstadministratoren bzw. -operatoren anzuzeigen ( Unterbefehl LIST ). Die Dienste erlauben jedoch keine Änderungen an einer dieser Listen durch einen Benutzer ohne die erforderlichen Berechtigungen.

Befehle, die auf Dienstbetreiber beschränkt sind

Zusätzlich zu den Befehlen, die von allen IRC-Betreibern verwendet werden können, haben Dienstbetreiber Zugriff auf Befehle, mit denen die Stabilität aufrechterhalten und Probleme im IRC-Netzwerk behoben werden können. Fünf dieser Befehle – GETKEY , MODE , CLEARMODES , KICK und CLEARCHAN – ermöglichen die Steuerung der Kanalmodi sowie die Möglichkeit, einen Benutzer (oder alle Benutzer) aus einem Kanal zu entfernen. Der letzte betreiberspezifische Befehl, Services, KILLCLONESermöglicht eine schnelle Lösung zum „Klonen“ von Problemen, bei denen viele Clients gleichzeitig von derselben Adresse aus eine Verbindung zum IRC-Netzwerk herstellen; Dieser Befehl bewirkt, dass alle Clients mit derselben Adresse wie der dem Befehl zugewiesene Kurzname sofort getrennt werden. Außerdem wird ein temporärer Autokill hinzugefügt (wenn die Autokill-Unterstützung aktiviert ist), um zu verhindern, dass die Clients sofort wieder eine Verbindung herstellen.

Befehle, die auf IRC Service-Administratoren beschränkt sind

IRC Service-Administratoren haben Zugriff auf Befehle, die die Dienste selbst steuern. Einer davon ist der SET- Befehl, mit dem verschiedene Services-Optionen festgelegt werden können: READONLY , mit dem gesteuert wird , ob Services Änderungen an der Datenbank zulassen , und DEBUG , mit dem gesteuert wird , ob und wie viele Debugging-Informationen in die Protokolldatei geschrieben werden. (Die dritte SET- Option, SUPASS , ist auf Benutzer mit Superuser -Berechtigungen für Dienste beschränkt.) Dienstadministratoren können Dienste auch dazu zwingen, die Kopien ihrer Datenbanken auf der Festplatte mit dem Befehl UPDATE zu aktualisieren , damit Dienste ihre Konfigurationsdatei erneut lesen der REHASHBefehl und fahren Sie die Dienste mit den Befehlen SHUTDOWN , QUIT und RESTART herunter oder starten Sie sie neu .

In Bezug auf das IRC-Netzwerk können Dienstadministratoren den Befehl JUPE verwenden, um einen Server zu “ jupiterieren „, dh um Dienste dazu zu bringen, einen gefälschten Server mit einem bestimmten Namen zu erstellen, um zu verhindern, dass ein realer Server mit demselben Namen eine Verbindung herstellt. Dies kann nützlich sein, wenn ein Server in Ihrem Netzwerk beschädigt (oder gehackt) ist und Probleme für andere Server im Netzwerk verursacht.

Wenn der Services- Superuser mit dem Befehl SET SUPASS ein Superuser -Kennwort festgelegt hat , können Services-Administratoren dieses Kennwort mit dem SU- Befehl verwenden, um Superuser-Berechtigungen zu erhalten.

Befehle, die auf den Superuser „Dienste“ beschränkt sind

Die Berechtigungsstufe für Superuser der Dienste ähnelt der Administratorstufe der Dienste. Es dient hauptsächlich dazu, die Administratorliste der Dienste (mit dem Befehl ADMIN ) zu ändern und das Superuser -Kennwort (mit dem Befehl SET SUPASS ) festzulegen . Ein anderer Befehl ist jedoch auf den Superuser „Dienste“ (oder auf Dienstadministratoren mit Superuserberechtigung) beschränkt: den RAW- Befehl, mit dem beliebige Daten direkt an den Server gesendet werden können, mit dem die Dienste verbunden sind. Dies kann verwendet werden, um bestimmte Arten von „Spezialeffekten“ zu erzielen oder um die Entwicklung oder das Debuggen eines IRC-Servers oder eines Servicemoduls zu unterstützen. Wie bereits erwähnt, ist dieser Befehl jedoch sehr gefährlich.Eine unsachgemäße Verwendung kann leicht dazu führen, dass Dienste oder die IRC-Server Ihres Netzwerks (oder beides) abstürzen oder Daten beschädigen. Aus diesem Grund ist der RAW- Befehl selbst für den Superuser “ Dienste“ nicht verfügbar, es sei denn, die Option “ AllowRaw “ ist in modules.conf festgelegt (standardmäßig deaktiviert).

Darüber hinaus stehen dem Superuser Dienste bestimmte Debugging-Befehle zur Verfügung, wenn diese im Makefile aktiviert sind . Diese Befehle sind nicht dokumentiert. Weitere Informationen finden Sie im Quellcode ( modules / operserv / main.c ).

Zurück nach oben

3-4-3. Autokills und S-Linien

Nahezu jedes Netzwerk hat seinen Anteil an Unruhestiftern oder anderen „unerwünschten“ Benutzern. IRC-Server haben immer eine Methode bereitgestellt – „K-Zeilen“, die so genannt wird, weil die Zeilen in der Konfigurationsdatei, die sie definieren, mit dem Buchstaben “ K “ beginnen -, um zu verhindern, dass diese Benutzer eine Verbindung zum Netzwerk herstellen. Das Problem bei diesen ist jedoch, dass sie nur den Server betreffen, auf dem sie definiert sind. Um zu verhindern, dass ein Benutzer überhaupt eine Verbindung zum Netzwerk herstellt, muss jeder Server die entsprechenden K-Leitungen für diesen Benutzer hinzufügen. Darüber hinaus können K-Zeilen nur zum Blockieren von Kombinationen aus Benutzername und Hostname verwendet werden. Unter bestimmten Umständen kann es wünschenswert sein, Benutzer basierend auf dem Spitznamen, dem „echten Namen“ oder der IP-Adresse zu blockieren.

Das frühere Problem, K-Leitungen zwischen Servern synchron zu halten, wird durch die Autokill- Funktion von Services gelöst , die vom operserv / akill- Modul bereitgestellt wird. Dieses Modul führt eine Liste von K-Zeilen ( dh Platzhaltermasken für Benutzername / Hostname), die auf allen Servern verwaltet werden sollen. Wenn ein Benutzer, der mit einer solchen Maske übereinstimmt, versucht, eine Verbindung zum Netzwerk herzustellen , geben die Dienste automatisch eine KILL- Nachricht dafür aus Benutzer, entfernen Sie sie aus dem Netzwerk (daher der Name „autokill“). Einige Server unterstützen eine Funktion, mit der Services K-Leitungen für alle Server dynamisch aktualisieren können, und Services nutzt dies ebenfalls.

Das letztere Problem, Benutzer aufgrund anderer Dinge als ihres Benutzernamens und Hostnamens zu blockieren, wird von der S-Line- Funktion behandelt, die vom operserv / sline- Modul bereitgestellt wird. Es gibt drei Arten von S-Linien:

• SGline , die mit dem „echten Namen“ eines Benutzers übereinstimmt (auch „gecos“ genannt, daher das „G“);
• SQline , die mit dem Spitznamen eines Benutzers übereinstimmt (das „Q“ stammt aus „Quarantäne“, und einige Server unterstützen „Q-Zeilen“ in Konfigurationsdateien, um die Verwendung bestimmter Spitznamen auf diesem Server zu verbieten). und
• SZline , die mit der IP-Adresse eines Benutzers übereinstimmt (das „Z“ stammt von „zap“, und einige Server unterstützen „Z-Lines“ in Konfigurationsdateien).

Wie bei Autokills geben Services automatisch eine KILL- Nachricht für jeden Benutzer aus, der mit einer dieser Masken übereinstimmt, mit zwei Ausnahmen. Wenn der verwendete IRC-Server für SQlines das erzwungene Ändern von Nick unterstützt und SQlineKill nicht in modules.conf festgelegt ist , wird der Benutzer von Services nicht getötet, sondern der Spitzname des Benutzers wird in einen „Gast“ -Nicknamen geändert, und es wird auch eine Fehlermeldung gesendet Dies zwingt den Client, den Benutzer zu zwingen, einen anderen Spitznamen zu wählen. IRC Operatoren können durch Einstellen der von der SQLINE Prüfung ausgenommen werden SQlineIgnoreOpers Option in modules.conf. Außerdem stellen einige Server keine IP-Adressinformationen bereit, sodass die Dienste SZlines auf diesen Servern nicht überprüfen können. In diesem Fall geben die Dienste eine Warnung aus und SZlines werden deaktiviert. (Einige Server erlauben SZlines von Dienstleistungen auf jedem Server festgelegt werden, und in diesem Fall SZlines kann weiterhin verwendet werden , wenn die ImmediatelySendSline Option eingestellt ist modules.conf .)

Da die Autokill- und S-Line-Funktionen praktisch identisch sind, wird hier nur die Autokill-Funktion ausführlich beschrieben. Weitere Informationen zur Verwendung von S-Zeilen finden Sie in der Dokumentation zu den Befehlen SGLINE , SQLINE und SZLINE sowie im Abschnitt operserv / sline der Datei modules.conf .

Wie Autokills funktionieren

Wenn ein Benutzer eine Verbindung zum IRC-Netzwerk herstellt, leitet der Server, mit dem der Benutzer verbunden ist, Informationen über diesen Benutzer, einschließlich des Benutzernamens und des Hostnamens des Benutzers, zusammen mit den anderen IRC-Servern im Netzwerk an Services weiter. Wenn Services diese Informationen erhält, werden der Benutzername und der Hostname mit einem at-sign-Zeichen verknüpft, um eine Zeichenfolge für Benutzername @ Hostname zu bilden . Diese Zeichenfolge wird dann mit jeder Maske in der Autokill-Liste verglichen. Wenn eine Übereinstimmung gefunden wird, gibt Services eine KILL- Nachricht für den Benutzer aus, wodurch der Benutzer vom Netzwerk getrennt wird. der Text in der verwendeten KILL – Nachricht kann mit dem festgelegt wird AutokillReason Option in modules.conf. Darüber hinaus senden Services für Server, die einen „Netzwerk-K-Line“ -Mechanismus unterstützen, der alle unterstützten Server mit Ausnahme der klassischen RFC 1459- und TS8-basierten Server umfasst, eine K-Line für den Benutzernamen und den Hostnamen, mit denen der Benutzer übereinstimmt. Dadurch werden die Server angewiesen, alle Benutzer, die mit dieser Benutzernamen- und Hostnamenmaske übereinstimmen, sofort zu trennen. (Wenn mehr als eine Autokill-Maske übereinstimmt, wird die erste gefundene verwendet.)

Autokills können so eingestellt werden, dass sie nach einer bestimmten Zeitspanne ablaufen (automatisch gelöscht werden). Diese Zeitspanne wird durch die AutokillExpiry- Konfigurationsoption in modules.conf festgelegt und in der mit Services verteilten Beispieldatei modules.conf auf 30 Tage festgelegt . Nach dieser Zeit entfernen die Dienste die Maske aus der Autokill-Liste, sodass Benutzer, die mit der Maske übereinstimmen, erneut eine Verbindung herstellen können. wenn die WallAutokillExpire Wenn die Konfigurationsoption festgelegt ist, informiert Services alle IRC-Bediener, wenn dies auftritt. Bei Servern mit einem „Netzwerk-K-Linien“ -Mechanismus werden K-Linien, die einer Maske entsprechen, automatisch entfernt, wenn sie ablaufen (oder explizit gelöscht werden). Die Zeitspanne vor dem Ablauf kann auch für jede einzelne Autokill-Maske eingestellt werden, wie unten beschrieben.

Verwenden des AKILL- Befehls

Der AKILL- Befehl, der nur für Dienstbetreiber verfügbar ist, wird zum Verwalten der Autokill-Liste verwendet. Es hat fünf Unterbefehle:

• ADD , eine Maske auf die AutokillListe hinzuzufügen;
• DEL , um eine Maske aus der Autokill-Liste zu entfernen;
• LIST , um alle Masken in der Autokill-Liste aufzulisten;
• VIEW , um detaillierte Informationen zu Masken in der Autokill-Liste zu geben;
• PRÜFEN Sie , um Autokill-Masken zu finden, die einem bestimmten user @ host- Paar entsprechen. und
• COUNT , um die Anzahl der Masken in der Autokill-Liste anzuzeigen.

Autokill-Masken haben die Form user @ host – beachten Sie, dass Spitznamen nicht verwendet werden. (S-Zeilen verwenden unterschiedliche Formate; siehe entsprechende Befehlsdokumentation.) Wenn Sie der Autokill-Liste eine Maske hinzufügen, müssen Sie auch einen Grund dafür angeben. Auf diese Weise können andere Dienstbetreiber (oder Sie, falls Sie dies später vergessen) wissen, warum die Maske hinzugefügt wurde. Der Grund wird in der Antwort auf einen LIST- oder VIEW- Befehl angezeigt . Wenn die WallOSAkill- Option in modules.conf festgelegt ist , sendet OperServ eine Benachrichtigung an alle IRC-Operatoren, wenn ein Autokill hinzugefügt oder gelöscht wird.

Wie oben erwähnt, verfällt autokills nach der Höhe der Zeit standardmäßig in der angegebenen AutokillExpiry Option in modules.conf . Ein bestimmter Autokill kann so eingestellt werden, dass er in einer anderen Zeitspanne abläuft oder überhaupt nicht abläuft, indem die gewünschte Ablaufzeit in den ADD- Befehl aufgenommen wird, wie in der AKILL- Befehlsdokumentation beschrieben. Mit der Option OperMaxExpiry in modules.conf können Sie auch eine Obergrenze für die von Service-Betreibern festgelegten Ablaufzeiten festlegen (im Gegensatz zu Services-Administratoren) . Wenn dies festgelegt ist, dürfen Dienstbetreiber keine Autokills festlegen, die länger als der angegebene Zeitraum dauern oder nicht ablaufen.

Der Unterschied zwischen den Unterbefehlen LIST und VIEW besteht in ihrer Ausführlichkeit. LIST zeigt jede Autokill-Maske in einer Zeile an und zeigt nur die Maske und den Grund an (wenn die Maske oder der Grund jedoch lang ist, kann dies von Ihrem IRC-Client in mehrere Zeilen eingeschlossen werden). AUSSICHTverwendet andererseits mehrere Zeilen für jede Maske und zeigt zusätzlich den Spitznamen der Person an, die sie hinzugefügt hat, das Datum und die Uhrzeit, zu der sie hinzugefügt wurde, die letzte Verwendung (wenn überhaupt) und wann sie abläuft auf die Maske selbst und Vernunft. Die zuletzt verwendete Zeit zeigt das letzte Mal an, wenn ein Benutzer mit der mit dem Netzwerk verbundenen Maske übereinstimmt, und ist hilfreich, um festzustellen, ob noch eine Autokill-Maske benötigt wird. Dies ist jedoch möglicherweise nicht korrekt, wenn Ihre IRC-Server einen serverbasierten Autokill-Mechanismus unterstützen. Solche Server blockieren die Verbindung des Benutzers, ohne die Dienste zu informieren, sodass die zuletzt verwendete Zeit nur das erste Mal anzeigt, wenn ein übereinstimmender Benutzer verbunden ist. (Wenn die Option Sofort sendenAutokill in der Datei modules.conf aktiviert ist, wird die zuletzt verwendete Zeit auf diesen Servern niemals eingestellt.)

Der Befehl CHECK kann als „inverse LIST “ betrachtet werden: Anstatt Autokills zu finden, die einem bestimmten Muster entsprechen, sucht CHECK nach Autokills, die einem bestimmten user @ host- String entsprechen würden. Dies kann hilfreich sein, um herauszufinden, welcher Autokill auf einen bestimmten Benutzer angewendet wurde, der vom Netzwerk getrennt wurde.

Autokill-Ausschlüsse

(Hinweis: Dieser Abschnitt gilt nur für Autokills. S-Leitungen sind nicht ausschlussfähig.)

Es ist auch möglich, „Anti-Autokill“ -Masken hinzuzufügen, dh Masken für Benutzer, die eine Verbindung herstellen dürfen, auch wenn sie mit einem Autokill übereinstimmen. Diese sind bekannt als Autokill Ausschlüsse und sind mit der aktivierten EnableExclude Option in modules.conf . Die Autokill-Ausschlussliste wird mit dem Befehl EXCLUDE verwaltet , der ähnlich wie der oben beschriebene Befehl AKILL funktioniert . (Neu hinzugefügte Ausschlüsse werden jedoch unabhängig vom Status der Einstellung “ Sofort sendenAutokill“ immer sofort an den Server gesendet . Dies soll verhindern, dass ein Autokill durch eine nicht ausgeschlossene Übereinstimmung ausgelöst wird, bevor der Ausschluss gesendet wurde, was dazu führt, dass die ausgeschlossenen Benutzer gesendet werden auch blockiert.)

Wenn Autokill-Ausschlüsse verwendet werden, überprüfen die Dienste zunächst die Ausschlussliste für jeden Benutzer, der eine Verbindung zum Netzwerk herstellt. Wenn in der Ausschlussliste eine übereinstimmende Maske gefunden wird, ermöglicht Services diesem Benutzer, eine Verbindung herzustellen, wobei die normale Überprüfung der Autokill-Liste für diesen Benutzer übersprungen wird. Wenn beispielsweise ein Autokill auf *@*.example.com platziert wurde , aber einer der IRC-Operatoren für einen Server im Netzwerk, der vom Host foo.example.com verbunden ist , ein Autokill-Ausschluss für *@foo.example.com Dies würde es diesem Benutzer ermöglichen, eine Verbindung herzustellen , während andere Benutzer in der Domäne example.com weiterhin daran gehindert werden, eine Verbindung herzustellen.

Ein wichtiger Nebeneffekt von Autokill-Ausschlüssen ist eine potenzielle Zunahme des Netzwerkverkehrs. Wenn der verwendete IRC-Server serverbasierte Autokills unterstützt, werden diese normalerweise von den Diensten genutzt, um zu verhindern, dass Benutzer, die mit Autokills übereinstimmen, eine Verbindung zum Netzwerk auf der Serverseite herstellen. Wenn die Server jedoch keine serverbasierten Autokill-Ausschlüsse unterstützen (die einzigen unterstützten Server mit dieser Fähigkeit sind die IRC-Server InspIRCd, tr-ircd und Unreal 3.2), können Services auch keine serverbasierten Autokills verwenden – Wenn dies der Fall wäre, würden die Server auch Benutzer in der Ausschlussliste blockieren, ohne dass Services eingreifen könnten – und auf die Standardmethode zum Senden eines KILL zurückgreifen Nachricht für automatisch gekillte Benutzer. Dies führt nicht nur zu mehr Datenverkehr im IRC-Netzwerk, sondern auch dazu, dass automatisch geschädigte Benutzer Nachrichten senden können, bevor sie getötet werden, wenn zwischen den Diensten und dem Server, mit dem der Benutzer eine Verbindung hergestellt hat, eine ausreichende Verzögerung besteht.

Zurück nach oben

3-4-4. Sitzungsbegrenzung

Eine andere Möglichkeit, unerwünschte Clients daran zu hindern, eine Verbindung zum Netzwerk herzustellen, ist die Sitzungsbeschränkung , die vom Modul operserv / session bereitgestellt wird . Wenn die Sitzungsbegrenzung aktiv ist ( dh wenn das Modul verwendet wird), verfolgt Services die Anzahl der von jedem Host verbundenen Clients und gibt KILL- Nachrichten für alle Clients aus, die die durch die Konfigurationsoption DefSessionLimit in Modulen festgelegte Grenze überschreiten . conf (oder bestimmte Grenzwerte für den Host, die durch unten beschriebene Sitzungsausnahmen festgelegt werden). Vor dem eigentlichen Trennen des Clients können die Dienste so konfiguriert werden, dass Benachrichtigungen mit SessionLimitExceeded und SessionLimitDetailsLoc gesendet werden Einstellmöglichkeiten.

Wenn das Autokill-Modul (siehe Abschnitt 3-4-3 ) geladen ist, können Services auch einen Autokill hinzufügen, wenn das Sitzungslimit eines bestimmten Hosts in kurzer Zeit häufig überschritten wird. Dies wird durch die SessionLimitAutokill- Konfigurationsanweisung gesteuert, mit der genaue Definitionen von „häufig“ und „kurz“ sowie die Ablaufzeit für das Einstellen solcher Autokills festgelegt werden können.

Sitzungsausnahmen werden über den Befehl EXCEPTION verwaltet . Dieser Befehl funktioniert ähnlich wie der Befehl AKILL , aber wenn Sie Sitzungsausnahmen hinzufügen, müssen Sie das Limit (die maximale Anzahl zulässiger Clients) in den Befehl aufnehmen. Mit der Option MaxSessionLimit kann eine Obergrenze für diesen Wert festgelegt werden . Wie bei Autokills können Ausnahmen so eingestellt werden, dass sie nach einer bestimmten Zeit ablaufen ( ExceptionExpiry ), und Services können so eingestellt werden, dass sie IRC-Operatoren informieren, wenn eine Ausnahme hinzugefügt oder gelöscht wird ( WallOSException ) oder abläuft ( WallExceptionExpire ).

Zurück nach oben

3-4-5. Nachrichten

Das Modul operserv / news bietet einen einfachen „News“ -Dienst, mit dem Nachrichten automatisch an alle Benutzer gesendet werden können, wenn sie sich im Netzwerk anmelden , oder an IRC-Bediener, wenn sie den Befehl / oper geben . Nachrichten werden über die Befehle LOGONNEWS bzw. OPERNEWS hinzugefügt und gelöscht . Für jeden Satz werden die letzten drei Elemente (oder alle Elemente, wenn drei oder weniger vorhanden sind) angezeigt.

Zurück nach oben

---

3-5. Sammlung von Netzwerkstatistiken (StatServ)

IRC Services bietet einen einfachen Netzwerkstatistik-Erfassungsdienst, auf den über den Pseudoklienten “ StatServ “ zugegriffen werden kann . StatServ verfolgt das letzte Mal, wenn jeder Server im Netzwerk verbunden und getrennt wurde, sowie die Anzahl der Benutzer auf jedem Server und die Gesamtzahl der Benutzer im Netzwerk. Normalerweise haben alle Benutzer Zugriff auf diese Informationen, aber die Verwendung von StatServ kann durch Setzen der nur auf IRC Operatoren beschränkt SSOpersOnly Option in modules.conf .

Auf Serverinformationen wird über den Befehl SERVERS zugegriffen . StatServ kann Informationen auf allen Servern oder nur auf Online- oder Offline-Servern anzeigen, einschließlich der letzten Verbindungs- und Trennungszeit, der aktuellen Anzahl von Benutzern und IRC-Betreibern sowie der jeweiligen Prozentsätze der Gesamtzahl der Benutzer und IRC-Betreiber im Netzwerk. Darüber hinaus können Dienstadministratoren Servereinträge kopieren, umbenennen oder löschen, um die Daten in Bezug auf Netzwerkänderungen auf dem neuesten Stand zu halten.

Mit dem Befehl USERS können die aktuelle Anzahl der Benutzer und IRC-Operatoren im Netzwerk sowie die durchschnittliche Anzahl der Benutzer und Operatoren pro Server angezeigt werden.

Zurück nach oben

---

3-6. Eingebauter HTTP-Server

Neben der direkten Interaktion mit dem IRC-Netzwerk können Services auch Informationen für World Wide Web-Clients (Browser) über das HTTP-Protokoll bereitstellen. Diese Funktionalität ist zwar nicht annähernd so umfangreich wie vollwertige HTTP-Server wie Apache, bietet jedoch die Möglichkeit, auf aktuelle Informationen zu Diensten und zum IRC-Netzwerk zuzugreifen, ohne ein CGI oder ein anderes externes Programm durchlaufen zu müssen.

Die HTTP-Serverfunktionalität von Services besteht aus drei Teilen: dem zentralen HTTP-Servermodul, den Autorisierungsmodulen und den Inhaltsmodulen. Diese werden in den folgenden Abschnitten erläutert.

3-6-1. Kern-HTTP-Servermodul

Das zentrale HTTP-Servermodul httpd / main bildet die Grundlage für die anderen HTTP-Module, einschließlich der Möglichkeit, HTTP-Anforderungen abzuhören und zu analysieren. Dieses Modul ähnelt einem typischen eigenständigen HTTP-Server (httpd), ist jedoch wesentlich weniger funktionsfähig als dieser.

Das Verhalten des HTTP-Servers wird durch Einstellungen in der Datei modules.conf definiert . Das wichtigste davon, ListenTo , gibt die IP-Adresse und die Portnummer an, auf der der HTTP-Server auf Verbindungen wartet . Es ist möglich, mehrere Adressen anzugeben, wodurch die Dienste auf Verbindungen für alle Adressen warten. Die Portnummer kann ein beliebiger Port sein, der nicht bereits von einem anderen Dienst auf demselben Computer verwendet wird, obwohl für die Verwendung von Ports unter 1024 normalerweise Superuser-Berechtigungen erforderlich sind. Die IP-Adresse kann als “ * “ angegeben werden“Im einfachsten Fall bedeutet dies“ auf Verbindungen unter einer beliebigen IP-Adresse warten „. Wenn Sie jedoch einen Computer mit mehreren IP-Adressen verwenden, müssen Sie möglicherweise eine bestimmte IP-Adresse eingeben, um Kollisionen mit Diensten zu vermeiden, die andere IP-Adressen abhören Sie können auch festlegen, dass nur Verbindungen von Clients auf demselben Computer zugelassen werden, indem Sie die “ localhost “ -Adresse 127.0.0.1 angeben . Dieselbe Art der Zugriffssteuerung kann auch auf Ressourcenbasis unter Verwendung von httpd / auth-ip durchgeführt werden Autorisierungsmodul, das später erläutert wird. Wenn Sie jedoch alle Ressourcen auf den lokalen Computer beschränken möchten, ist diese Methode sicherer und effizienter.

Es ist auch möglich, anstelle der IP-Adresse einen Hostnamen zu verwenden. In diesem Fall suchen die Dienste beim Start nach dem Hostnamen und verwenden die gefundene IP-Adresse (alle Adressen, falls mehr als eine gefunden wird) als Adresse zum Abhören. Diese Adressen ändern sich jedoch auch dann nicht, wenn sich die DNS-Informationen des Hostnamens ändern, es sei denn, die Dienste werden neu gestartet oder angewiesen, die Konfigurationsdateien erneut zu lesen (siehe Abschnitt 2-6 ).

Die Anzahl der gleichzeitig zulässigen Verbindungen und die Zeitdauer, die eine einzelne Verbindung geöffnet bleiben kann, werden durch die Anweisungen MaxConnections , MaxRequests und IdleTimeout festgelegt . MaxConnections legt die maximale Anzahl gleichzeitiger Verbindungen fest, die von Services akzeptiert werden. Verbindungen, die über diesem Grenzwert liegen, werden getrennt, sobald sie akzeptiert werden. MaxRequests legt die maximale Anzahl von HTTP-Anforderungen fest, die über eine einzelne Verbindung gesendet werden können, während IdleTimeout die maximale Zeitdauer angibt, für die eine Verbindung inaktiv sein kann ( dhkeine Daten vom Kunden erhalten); Wenn eine dieser Grenzwerte überschritten wird, wird die Verbindung getrennt. (Beachten Sie, dass einige Ressourcen dazu führen, dass die Verbindung getrennt wird, nachdem der Server das Senden von Daten beendet hat, unabhängig von diesen Einstellungen.)

Wenn die LogConnections- Direktive angegeben ist, schreibt der HTTP-Server für jede akzeptierte Verbindung eine Protokollnachricht in die Services-Protokolldatei. Beachten Sie, dass die angeforderte Ressource (URL) nicht protokolliert wird und nur eine Nachricht pro Verbindung geschrieben wird, selbst wenn mehrere HTTP-Anforderungen über dieselbe Verbindung gestellt werden. (Wenn die Protokollierung pro Anforderung gewünscht wird, können MaxRequests auf 1 gesetzt werden, um Clients zu zwingen, für jede Anforderung eine neue Verbindung zu öffnen.)

Die verbleibenden Einstellungen, ListenBacklog und RequestBufferSize , können normalerweise unverändert bleiben . ListenBacklog gibt an, wie viele Verbindungen das Betriebssystem zu einem einzelnen HTTP-Server-Port herstellen soll, ohne von den Diensten akzeptiert zu werden. Dies kann auftreten, wenn der HTTP-Server stark ausgelastet ist und Anforderungen schneller eingehen, als Dienste sie verarbeiten können. (Einige Betriebssysteme lassen jedoch keinen Wert zu, der größer als der Standardwert von 5 ist. Auf solchen Systemen führt das Erhöhen des Werts nicht zu einem Fehler, hat jedoch keine Auswirkungen.) RequestBufferSize Gibt die Größe des Empfangspuffers an, der jeder Anforderung zugewiesen wird. Wenn eine Anforderung diese Größe überschreitet, wird dem Client der Fehler „Anforderungsentität zu groß“ gesendet und die Verbindung wird getrennt. Es sollte nicht erforderlich sein, diesen Wert für die mit Services verteilten Module zu ändern.

Beachten Sie, dass die Einstellung RequestBufferSize nur die Größe des Empfangspuffers selbst beeinflusst. Zusätzlich zu diesem Puffer werden für jede Verbindung eine Kontrollstruktur mit fester Größe und eine Liste von Headern und Formularvariablen zugewiesen. Im schlimmsten Fall benötigen diese ungefähr 4/3 des für RequestBufferSize angegebenen Werts . Somit kann die maximale Speichermenge, die vom HTTP- Servermodul verwendet wird, konservativ als ungefähr MaxConnections * RequestBufferSize * 2.5 berechnet werden .

Zurück nach oben

3-6-2. Autorisierungsmodule

Da es möglicherweise nicht wünschenswert ist, jedem Zugriff auf die vom HTTP-Server bereitgestellten Ressourcen zu gewähren, bietet Services „Autorisierungsmodule“, deren Namen mit “ auth- “ beginnen, um den Zugriff auf diese Ressourcen zu steuern.

Kontrolle über die Client-IP-Adresse: das httpd / auth-ip- Modul

Das httpd / auth-ip- Modul ermöglicht die Zugriffssteuerung basierend auf der IP-Adresse des verbindenden Clients. Das Modul verwendet zwei Konfigurationsanweisungen, AllowHost und DenyHost , um den Zugriff auf bestimmte Ressourcen (URLs) zu steuern. Beide Anweisungen verwenden zwei Parameter: die Ressource, auf die der Zugriff gesteuert werden soll, und die IP-Adresse oder den Hostnamen, über die der Zugriff zugelassen oder verweigert werden soll.

Der erste Parameter, die Ressource, auf die der Zugriff gesteuert werden soll, besteht aus einer relativen URL, die mit dem Zeichen / beginnt . dh ohne den führenden “ http: // host.name „, der in den Browser eingegeben wurde. Dienste steuern den Zugriff gemäß der Anweisung auf diese Ressource und auf jede Ressource, deren URL mit derselben Zeichenfolge beginnt. Wenn Sie beispielsweise “ / dir “ als zu steuernde Ressource angeben, wirkt sich dies nicht nur auf “ / dir / file “ aus. aber auch “ / schmutzig „. Der Richtlinie des Effekts auf ein bestimmtes Verzeichnis zu beschränken, stellen Sie sicher , gehören ein „ / “ am Ende der Ressource URL, zB „“. Die Zugriffssteuerung kann mithilfe der Ressourcen-URL“ / “ auf jede Ressource auf dem Server angewendet werden .

Der zweite Parameter, die IP-Adresse, wird ähnlich wie bei der ListenTo- Direktive des Kernmoduls angegeben : Die Zeichenfolge “ * “ kann für „alle IP-Adressen“ verwendet werden, und ein Hostname wird durch die oder die zugeordneten IP-Adressen ersetzt mit diesem Hostnamen. (Beachten Sie, dass Hostnamen beim Programmstart nur einmal in IP-Adresse aufgelöst werden. Wenn sich die IP-Adresse des Hostnamens während der Ausführung von Diensten ändert, erkennen Dienste die neue IP-Adresse für Autorisierungszwecke nicht.) Für diese Anweisungen gibt es einen zusätzlichen Typ von IP-Adressspezifikation ist möglich: eine Netzwerkspezifikation der Form aaa . bbb . ccc . ddd / xx , wobei xxist eine Ganzzahl von 1 bis einschließlich 31, die die Anzahl der Bits im Netzwerkteil der Adresse angibt. Beispielsweise repräsentiert 192.168.1.64/26 den Bereich von IP-Adressen von 192.168.1.64 bis 192.168.1.127 (alle IP-Adressen, deren erste 26 Bits mit denen in 192.168.1.64 identisch sind).

Wenn Sie mehrere Steueranweisungen angeben, ist es wichtig, dass diese in der richtigen Reihenfolge angegeben werden. Alle AllowHost- und DenyHost- Direktiven werden in der Reihenfolge überprüft, in der sie in modules.conf aufgeführt sind, ohne Rücksicht auf die Spezifität der IP-Adresse oder der Ressource, und der erste gefundene übereinstimmende Eintrag wird verwendet. Infolgedessen hat ein spezifischerer Eintrag keine Auswirkung, wenn er unter (nach) einem allgemeineren Eintrag platziert wird. Betrachten Sie als Beispiel das folgende Richtlinienpaar:AllowHost / 192.168.0.1
DenyHost / 192.168.0.0/24Der erste ermöglicht den Zugriff auf den gesamten Server von der IP-Adresse 192.168.0.1 aus , während der zweite den Zugriff von allen IP-Adressen im 192.168.0. * -Netzwerk verweigert . In der angegebenen Reihenfolge, ermöglicht dies den Zugang von nur 192.168.0.1 in diesem Netzwerk, während alle anderen Hosts im Netzwerk zu verhindern , zu verbinden. Wenn die Anweisungen jedoch in umgekehrter Reihenfolge angegeben werden:DenyHost / 192.168.0.0/24
AllowHost / 192.168.0.1Dann werden Clients von 192.168.0.1 zusammen mit dem Rest des Netzwerks 192.168.0. * blockiert , da die erste Anweisung die Dienste anweist, den Zugriff auf 192.168.0.1 sowie andere Hosts in diesem Netzwerk zu verweigern , sodass die zweite Anweisung niemals lautet überprüft.

Die Liste der Anweisungen sollte immer entweder mit “ AllowHost / * “ oder “ DenyHost / * “ enden, um zu steuern, ob Anforderungen, die keiner anderen Anweisung entsprechen, zugelassen oder abgelehnt werden sollen. Das Verhalten des Moduls, wenn keine Einträge mit der IP-Adresse eines bestimmten Clients übereinstimmen, ist undefiniert.

Steuerung per Passwort: das Modul httpd / auth-password

Es ist auch möglich, den Zugriff zu steuern, indem der Client einen Benutzernamen und ein Kennwort eingeben muss, um auf eine bestimmte Ressource zuzugreifen. Dies wird mit dem Modul httpd / auth-password erreicht . Wie beim httpd / auth-ip- Modul wird der Zugriff durch eine Liste von Anweisungen gesteuert. Für dieses Modul lautet der Direktivenname Protect , und der zweite Parameter ist ein Paar aus Benutzername und Kennwort, wobei Benutzername und Kennwort durch einen Doppelpunkt getrennt sind ( z. B. “ Benutzername: Kennwort „). Darüber hinaus gibt die AuthName- Direktive den Namen an, den der HTTP-Client in Kennwortansagen verwendet, z. B. „Benutzername und Kennwort für Namen eingeben :“.

Wie beim httpd / auth-ip- Modul wird die erste Protect- Direktive verwendet, die einer bestimmten Anforderung entspricht. Daher sollten bestimmte Einträge vor allgemeinen platziert werden. Es ist jedoch nicht erforderlich, am Ende der Liste eine Schutz- / Direktive einzufügen, es sei denn, Sie möchten einen Kennwortschutz für den gesamten Server. Wenn eine Anfrage nicht mit Direktiven übereinstimmt, wird sie ohne Passwort durchgelassen.

Zurück nach oben

3-6-3. Inhaltsmodule

Der Rest der HTTP-Servermodule sind „Inhaltsmodule“, die, wie der Name schon sagt, den tatsächlichen Inhalt bereitstellen, der den Browsern bereitgestellt wird.

Seite „Index“: das httpd / top-page- Modul

Mit diesem einfachen Modul können Sie eine HTML-Datei (oder eine andere Datei) bereitstellen, die beim Zugriff auf die „Top Page“ (die “ / “ URL) des HTTP-Servers bereitgestellt werden soll. Da in einem typischen Setup andere Inhaltsmodule jeweils einen eigenen Unterpfad innerhalb des HTTP-Servers haben, können Sie mit diesem Modul (zum Beispiel) einen Index der verfügbaren Informationen bereitstellen. Die zu bedienende Datei wird durch die Dateinamenanweisung in modules.conf angegeben . Optional kann auch der MIME-Typ der Datei angegeben werden.

Es ist auch möglich, mithilfe der Redirect- Direktive eine URL zu einer Remote-Site (die ein separater HTTP-Server auf demselben Computer sein kann) für die Startseite anzugeben . In diesem Fall leiten die Dienste die Zugriffe von oben auf die angegebene URL um. Wenn sowohl Redirect als auch Dateiname angegeben sind, hat Redirect Vorrang und Dateiname wird ignoriert.

Beachten Sie, dass mit Dateiname die angegebene Datei unverändert bereitgestellt wird. Services versuchen nicht, es auszuführen, selbst wenn es wie ein CGI-Skript aussieht, und können PHP oder andere in die Datei eingebettete Sprachen nicht verarbeiten.

Bereitstellung von Links zu Kurznamen- und Kanal-URLs: das httpd / redirect- Modul

Das httpd / redirect- Modul kann verwendet werden, um automatische Weiterleitungen von einem Spitznamen oder Kanal zu der für den Spitznamen oder Kanal registrierten URL (falls vorhanden) bereitzustellen. Dies kann auf einfache Weise verwendet werden, damit Ihre Benutzer Informationen über sich selbst bereitstellen können, ohne dass sich der Betrachter im IRC anmelden und einen NickServ- oder ChanServ INFO- Befehl ausführen muss .

Spitznamen- und Kanalumleitungen verwenden jeweils eine Basis-URL, die in modules.conf angegeben ist : NicknamePrefix für Spitznamen und ChannelPrefix für Kanäle. Der Spitzname oder Kanal, dessen URL verwendet wird, ist die Zeichenfolge unmittelbar nach dem angegebenen Präfix (bei Kanälen wird das führende “ # “ verworfen, da es nicht in URLs verwendet werden kann). Dies bedeutet, dass zum Abrufen von URLs wie “ http://services.example.net/channel/ channel-name “ das Präfix als “ / channel / “ mit einem abschließenden Schrägstrich angegeben werden sollte, Sie jedoch auch “ / ~ “ angeben können „für das Spitznamenpräfix und erhalten Sie URLs wie“ http://services.example.net/~ Spitzname„. (Beides sind die Standardeinstellungen.)

NicknamePrefix und ChannelPrefix sollten so angegeben werden, dass sie sich nicht überlappen. Wenn eine bestimmte URL sowohl als Spitznamenreferenz als auch als Kanalreferenz interpretiert werden kann, hat der Spitzname immer Vorrang, auch wenn er nicht registriert ist oder keiner URL zugeordnet ist.

Online-Datenbankzugriff: das httpd / dbaccess- Modul

Warnung: Dieses Modul bietet vollständigen Zugriff auf alle Servicedaten. Unerlaubter Zugriff kann zu Passwortdiebstahl, Denial-of-Service-Angriffen oder Schlimmerem führen. Stellen Sie sicher, dass Sie den Zugriff auf dieses Modul mit Autorisierungsmodulen oder anderen Mitteln schützen.

Das httpd / dbaccess- Modul ist ein Verwaltungstool, mit dem auf die Services-Datenbanken über die einfache Point-and-Click-Oberfläche eines Browsers und nicht über die textbasierten Befehle von IRC zugegriffen werden kann. Während das Modul nicht zulässt, dass die Datenbanken geändert werden, können registrierte Spitznamen und Kanäle, Autokills und S-Zeilen usw. über ein einfaches Menüsystem aufgerufen und angezeigt werden. Darüber hinaus kann eine Kopie aller Services-Daten im XML-Format heruntergeladen werden, wenn das Modul misc / xml-export geladen ist ( Einzelheiten siehe Abschnitt 5-1 ).

Beachten Sie insbesondere beim Durchführen eines XML-Downloads der Services-Datenbanken, dass Services erst nach Abschluss der HTTP-Anforderung auf Netzwerkaktivitäten reagieren. Wenn Sie einen langsamen Computer oder eine große Datenbank haben, kann dies dazu führen, dass Dienste im IRC-Netzwerk „verzögert“ werden oder in extremen Fällen vollständig vom Netzwerk getrennt werden. Seien Sie daher vorsichtig.

Die URL, unter der auf die Daten zugegriffen werden kann , wird durch die Präfix- Direktive in modules.conf festgelegt . Wenn es nicht mit einem Schrägstrich endet, wird einer automatisch angehängt. Wenn Sie auf diese URL zugreifen, wird ein Menü mit verfügbaren Daten angezeigt. Wenn Sie unterschiedliche Zugriffsregeln für unterschiedliche Datenkategorien verwenden möchten, finden Sie in der folgenden Tabelle die entsprechenden Pfadnamen (in allen Fällen ist der Pfad der in der Präfix- Direktive angegebene URL-Pfadname ):

Pfad /	Hauptmenü
Pfad / operserv /	OperServ-Daten und -Menü
Pfad / operserv / akill /	Autokill-Liste
Pfad / operserv / news /	Nachrichtenliste
Pfad / operserv / Sessions /	Sitzungs- und Ausnahmelisten
Pfad / operserv / sline /	S-Line-Listen
Pfad / nickserv /	Spitznamenliste und Informationen
Pfad / chanserv /	Kanalliste und Informationen
Pfad / Statistik /	Netzwerkstatistik
path/xml-export/	Download der Datenbank im XML-Format

Debugging-Informationen: das httpd / debug- Modul

Das httpd / debug- Modul richtet sich in erster Linie an Modulentwickler und bietet Informationen zu der von Services empfangenen HTTP-Anforderung unter einer URL, die in der DebugURL- Direktive in modules.conf angegeben ist . Dieses Modul wird für den normalen Betrieb von Diensten nicht benötigt und sollte nur beim Testen des HTTP-Servers aktiviert werden.

Zurück nach oben

---

3-7. Passwortverschlüsselung

Services bietet die Möglichkeit, Kennwörter (Spitznamen-Kennwörter, Kanal-Kennwörter und das OperServ-Superuser-Kennwort) zu verschlüsseln, um einen zusätzlichen Schutz vor Kennwortdiebstahl zu bieten. Normalerweise werden Kennwörter nicht verschlüsselt. Wenn ein nicht autorisierter Benutzer Zugriff auf die Datenbanken erhält, werden die Kennwörter der Benutzer kompromittiert. Die Verschlüsselung verhindert das Auftreten dieses Kompromisses (obwohl es für einen Angreifer immer noch möglich ist, die verschlüsselten Passwörter zu „knacken“, insbesondere wenn die Passwörter leicht zu erraten sind). Beachten Sie, dass unter den Standardinstallationsverfahren nur der Benutzer, auf dem Dienste installiert werden, und der Administrator des Computers, auf dem Dienste installiert sind, Zugriff auf die Datenbanken haben.

Der Nachteil bei der Verwendung der Verschlüsselung ist, dass die Befehle NickServ und ChanServ GETPASS unbrauchbar werden , obwohl sie geringfügig sind . Dies liegt daran, dass einige Arten der Verschlüsselung, einschließlich aller von Diensten unterstützten Typen, nur in eine Richtung erfolgen (auch als „Trapdoor-Funktionen“ bezeichnet). Mit solchen Verschlüsselungstypen kann ein Kennwort in eine verschlüsselte Zeichenfolge konvertiert werden, das Kennwort kann jedoch nicht aus dieser Zeichenfolge wiederhergestellt werden.

Um die Verschlüsselung von Kennwörtern zu aktivieren, stellen Sie sicher, dass das gewünschte Verschlüsselungsmodul mit einer LoadModule- Direktive geladen ist , und geben Sie den Verschlüsselungstyp (den Namen des Moduls ohne die führende “ Verschlüsselung / „) in die EncryptionType- Direktive in ircservices.conf ein . Es gibt keine Strafe für das Laden mehrerer Verschlüsselungsmodule, aber nur das in der EncryptionType- Direktive angegebene Modul wird zum Verschlüsseln neuer Kennwörter verwendet.

Die verfügbaren Verschlüsselungsmodule lauten wie folgt:

• Verschlüsselung / md5 : Verwendet den MD5-Hashing-Algorithmus zum Verschlüsseln von Passwörtern. Dies ist ein Einweg-Verschlüsselungsalgorithmus, der einen 128-Bit-Digest des Kennworts generiert und von mehreren Unix-Systemen auch zum Verschlüsseln von Benutzerkennwörtern verwendet wird.
• Verschlüsselung / Unix-Krypta : DISCOURAGED. Verwendet die in den meisten Unix-Systemen verfügbare crypt () -Funktion, normalerweise eine Variante des DES-Verschlüsselungsalgorithmus, um Kennwörter zu verschlüsseln. Dies ist ein Einweg-Verschlüsselungsalgorithmus. Da es nicht sehr stark ist (nur 56 Bit), neigen neuere Betriebssysteme dazu, es zugunsten von MD5, SHA1 oder anderen stärkeren Algorithmen zu vermeiden. Dieses Modul wird hauptsächlich aus Gründen der Kompatibilität mit extern generierten Kennwörtern oder Datenbanken von anderen Diensten bereitgestellt. wie Programme. Beachten Sie, dass dieses Modul erfordert, dass Ihr Betriebssystem dieFunktion crypt () unterstützt , und dass es sonst nicht geladen werden kann.

Wenn ein Kennwort verschlüsselt wird, speichert Services den verwendeten Verschlüsselungstyp, sodass auch bei einer späteren Änderung der EncryptionType- Direktive ältere Kennwörter verwendet werden können (sofern das entsprechende Modul geladen ist).

Zurück nach oben

---

3-8. E-Mail senden

Dienste können E-Mails an Benutzer außerhalb des IRC-Protokolls senden. Diese Funktion wird beispielsweise vom Modul NickServ E-Mail-Authentifizierung ( Abschnitt 3-1-4 ) verwendet. Die E-Mail-Funktionalität gliedert sich in zwei Teile: ein Hauptmodul, das eine Schnittstelle für andere Module bereitstellt, und Methodenmodule, die die E-Mail-Funktionen auf Systemebene tatsächlich implementieren.

Das Hauptmodul mail / main bietet eine methodenunabhängige Schnittstelle zum Senden von E-Mails. Dieses Modul wird von anderen Modulen verwendet, die E-Mails senden müssen. (Wenn Sie dieses Modul nicht laden, können andere davon abhängige Module Fehler drucken, z. B. “ Symbol“ sendmail „kann nicht aufgelöst werden „, und Dienste werden abgebrochen. Beachten Sie, dass die Reihenfolge des Ladens des Moduls wichtig ist. Sie müssen dieses Modul laden vor denen, die es benutzen!)

Das Haupt-E-Mail-Modul verfügt über vier Konfigurationseinstellungen in modules.conf : FromAddress und FromName , die die E-Mail-Adresse und den Namen angeben , die in der Zeile „Von“ der E-Mail-Nachrichten verwendet werden sollen. MaxMessages , mit dem die maximale Anzahl von Nachrichten festgelegt wird, die gleichzeitig „gesendet“ werden können (noch nicht abgeschlossen); und SendTimeout , mit dem festgelegt wird , wie lange Services warten, bis eine Nachricht vollständig gesendet wurde, bevor sie abgebrochen wird.

Die Methodenmodule bilden die Schnittstelle zwischen dem Hauptmodul und dem Betriebssystem. Es stehen zwei Methodenmodule zur Verfügung:

• mail / sendmail : Verwendet das Sendmail-Programm, das auf vielen Unix-Systemen vorhanden ist, um E-Mails zu senden. Das Modul kann auch mit anderer Mail-Software zusammenarbeiten, die einausführbares Programmfür sendmail bereitstellt. Diese Methode unterliegt jedoch Verzögerungen durch das sendmail- Programm, während derer die Dienste nicht auf Nachrichten antworten können. Bei einigen Sendmail- Programmen können Sie die „Von“ -Adresse nur auf Ihre tatsächliche Adresse und Ihren Namen festlegen, was in einigen Fällen möglicherweise nicht wünschenswert ist. Daher wird empfohlen,wenn möglichdas Mail / SMTP- Modul (unten) zu verwenden.Die Konfigurationseinstellung SendmailPath (in modules.conf ) sollte auf den Pfadnamen Ihres sendmail- Programms festgelegt werden. Typische Speicherorte auf Unix-Systemen sind / usr / lib / sendmail oder / usr / sbin / sendmail ; Wenn Sie die richtige Einstellung für Ihr System nicht kennen, wenden Sie sich an Ihren Systemadministrator.
• mail / smtp : Verwendet das SMTP-Protokoll, um E-Mails über einen SMTP-Relay-Server zu senden. Der zu verwendende Server wird durch die RelayHost- Konfigurationsanweisung (in modules.conf ) angegeben. Wenn möglich, sollte dies entweder auf denselben Computer eingestellt werden, auf dem Dienste ausgeführt werden, oder auf einen anderen Server im selben lokalen Netzwerk, um Verzögerungen beim Senden von E-Mails zu verringern. (Die Dienste führen keine tatsächliche Zustellung von E-Mails durch, die dem Relay-Server überlassen bleiben.) Der Servername, der beim Herstellen einer Verbindung zum Remote-Server verwendet werden soll, wird durch die Anweisung SMTPName festgelegt . Dies sollte normalerweise mit dem Hostnamen des Computers übereinstimmen, auf dem Services ausgeführt werden.

Zurück nach oben

---

3-9. Mehrsprachige Unterstützung

Dienste können Nachrichten an Benutzer in mehreren verschiedenen Sprachen senden, sodass Benutzer aus verschiedenen Ländern Nachrichten in ihrer eigenen Muttersprache lesen können. Die folgenden nicht englischen Sprachen werden vollständig oder fast vollständig unterstützt:

• Niederländisch
• ungarisch
• japanisch
• Spanisch
• Türkisch

Die folgenden Sprachen werden teilweise unterstützt (einige Nachrichten in diesen Sprachen sind veraltet oder fehlen und werden auf Englisch angezeigt):

• Französisch
• Deutsche
• Russisch

Benutzer mit registrierten Spitznamen können mit dem Befehl NickServ SET LANGUAGE die Sprache auswählen, die von den Diensten für Benachrichtigungen und Antworten verwendet werden soll (dies schließt keine Memos und Kanaleintragsnachrichten ein, die von Benutzern eingegeben werden). Standardmäßig verwenden Services die Sprache, die durch die in der Quelldatei defs.h definierte Konstante DEF_LANGUAGE angegeben wird. Im verteilten Zustand ist dies auf Englisch ( LANG_EN_US ) eingestellt. Sofern Sie nicht vorhaben, ein regionales Netzwerk zu betreiben, in dem die Mehrheit der Benutzer dieselbe nicht-englische Sprache spricht, sollten Sie die Standardeinstellung wahrscheinlich in Ruhe lassen.

Es ist möglich , die Nachrichten von Dienstleistungen durch den Einsatz von „externen Sprachdateien“ (im Gegensatz zu den Standard – Sprachdateien enthaltenen Service) und die verwendeten zu ändern LoadLanguageText Konfigurationsdirektive in ircservices.conf . Jede Nachricht, die vom mehrsprachigen System von Services verarbeitet wird und fast alle an Benutzer gesendeten Nachrichten enthält, mit Ausnahme einiger weniger Nachrichten, die für Administratoren bestimmt sind, kann auf diese Weise geändert werden. („Nachricht“ bezieht sich hier auf eine Texteinheit, die von Diensten als Antwort auf ein bestimmtes Ereignis gesendet wird. Es besteht nicht immer eine Eins-zu-Eins-Entsprechung zwischen diesen Texteinheiten und den „Nachrichten“, wie sie von den Benutzern gesehen werden, wie unten beschrieben .)

Externe Sprachdateien sind einfache Textdateien, die aus einer Reihe von Nachrichtendeskriptoren bestehen , die jeweils einen einzeiligen Header gefolgt von null oder mehr Zeilen Ersatztext enthalten. Wie bei den Services-Konfigurationsdateien werden Leerzeilen und Zeilen, die mit dem Zeichen # beginnen , ignoriert. Wenn Sie eine Nachrichtenkennungszeile ohne folgenden Text angeben, wird für diese Nachricht nichts ausgegeben. Jede Zeile des Ersatztextes muss mit einem Tabulatorzeichen (ASCII 9, TAB) beginnen, das nicht im Text selbst enthalten ist. Stellen Sie beim Erstellen Ihrer Datei sicher, dass Ihr Texteditor keine Tabulatoren in Leerzeichen konvertiert, die von den Diensten nicht erkannt werden.

Die erste Zeile eines Nachrichtendeskriptors besteht aus einer Nachrichtenkennung und einer durch Leerzeichen getrennten Sprachkennung. Die Sprachkennung ist einfach der Dateiname der entsprechenden Standardsprachendatei (installiert im Sprachunterverzeichnis des Datenverzeichnisses). Die Sprachkennung für Englisch in den USA lautet beispielsweise en_us . Der Nachrichtendeskriptor ist der interne Name, der von den Diensten verwendet wird, um auf die Nachricht zu verweisen, und wird in Großbuchstaben geschrieben. Um die Nachricht Name für eine bestimmte Nachricht zu finden, suchen die Dienste Sprache Quelldateien (die * .l Dateien im langVerzeichnis der Quelldistribution) für den gewünschten Text, dann suchen Sie die erste Zeile über dieser Nachricht, die keine Registerkarte enthält; Diese Zeile ist der Nachrichtenname.

Als Beispiel könnte die folgende zweizeilige Datei verwendet werden, um die Meldung „Passwort falsch“ zu ersetzen (beachten Sie, dass die zweite Zeile mit einem Tabulatorzeichen und nicht mit Leerzeichen beginnt):

PASSWORD_INCORRECT en_us
	Dies ist ein Ersatz für die Nachricht PASSWORD_INCORRECT.

Beim Ersetzen von Nachrichten ist zu beachten, dass einige „Nachrichten“ tatsächlich aus mehreren unterschiedlichen Texteinheiten bestehen, von denen einige möglicherweise nur unter bestimmten Bedingungen angezeigt werden. Beispielsweise besteht der grundlegende Hilfetext für NickServ, der als Antwort auf einen / msg NickServ HELP- Befehl angezeigt wird, aus drei „Nachrichten“ im Sinne von Services: NICK_HELP mit dem grundlegenden Hilfetext ; NICK_HELP_EXPIRES , wird angezeigt, wenn der Ablauf des Spitznamens aktiv ist. und NICK_HELP_WARNING , die angezeigt werden, wenn die Konfigurationsoption NSHelpWarning festgelegt ist. Wenn Sie die NickServ-Hilfemeldung ändern möchten, möchten Sie wahrscheinlich alle drei dieser Meldungen neu definieren.

Zurück nach oben

---

3-10. Erweiterungen von Drittanbietern

Das Modulsystem in IRC Services ermöglicht das einfache Hinzufügen von Funktionen zu Services durch Drittanbieter. Erweiterungsmodule von Drittanbietern werden normalerweise als Quellcode-Pakete verteilt, die aus einem Verzeichnis bestehen, das ein Makefile und verschiedene Quellcodedateien enthält.

So installieren Sie eine solche Erweiterungen von Drittanbietern, müssen Sie das Erweiterungsmodul Quellcode – Verzeichnis in den Dienstleistungen Quellcode Baum unter dem kopieren Module Verzeichnis. (Stellen Sie sicher , dass Sie nicht kopieren Sie die Quelldateien sich in die Module Verzeichnis oder Dienstleistungen möglicherweise nicht mehr korrekt kompilieren Zum Beispiel, wenn der Quellcode in einem Verzeichnis „genannt enthalten ist! Mymodule “, könnten Sie den Befehl: “ cp -dpr mymodule / usr / local / src / ircservices / modules / mymodule „, um die Dateien zu kopieren.) Anschließend können Sie die Dienste wie gewohnt kompilieren (siehe Abschnitt 2-3)), und Services erkennt das Erweiterungsmodul automatisch und kompiliert es. Nach Abschluss der Kompilierung kann das Erweiterungsmodul genauso wie ein integriertes Modul verwendet werden, indem der Datei ircservices.conf eine entsprechende LoadModule- Direktive hinzugefügt wird.

Für Module haben wir eine eigene Eingangsseite. Siehe IRCServices-Module