Ръководство за IRC операторите

Този документ описва правата, задълженията и същността на операторския статус в дадена IRC мрежа. Не претендира за изчерпателност или всеобхватност, нито за шаблонност и задължителност. Целта е да се даде малко повече информация, както и малко лично мнение, по въпроса какво трябва да представляват примерните правила и поведение в дадена IRC мрежа. Ръководството е написано от оператор привидно за други оператори, но главно се чете от нормалните потребители.


Съдържание

   I. Взаимоотношения с потребителите и другите оператори
  II. Използване на команди KILL, KLINE и GLINE
 III. Ботове и лов на Ботове
  IV. Клонинги, Flooders, and Spoofing
   V. Защо операторите (обикновено) не се намесват в афери свързани с канали
  VI. Отношение към въпроса "Как да стана IRC оператор?"
 VII. IRCD и свързаните с него файлове (за Hybserv)
VIII. Команди за информация от сървъра (TRACE, STATS, LINKS и HTM)
  IX. Определяне мястото на сървър, разкачане и съединяване (SQUIT и CONNECT)
   X. Други команди свързани със сървъра (REHASH, RESTART и DIE)
  XI. Комуникация между операторите (WALLOPS, LOCOPS и OPERWALL)
 XII. Закачане на нови сървъри към мрежата
XIII. Заключителни бележки

I. Взаимоотношения с потребителите и другите оператори

Това е най-важната част от от "операторството". Или ще Ви изгради или ще Ви развали като оператор. Има политика за спазване на определени правила в IRC за различните мрежи и харесва ли ви или не, тази политика ще се спазва винаги. Борейки се срешу нея или оплаквайки се от нея няма да стигнете до никъде.

Операторът не трябва да гледа отвисоко на потребителите или да им се подиграва, да ги игнорира. Всеки оператор е длъжен, доколкото има свободно време, да помага на потребителите, да отговаря на техните въпроси или да им оказва помощ по принцип. Изключение е, ако личните съобщения са безсмислени, обидни, или свързани с въпроси, които са описани в помощната секция на мрежата. Би било добре всеки оператор, когато има време, да прекарва по някой час в някой от официалните помощни канали на мрежата, помагайки на потребителите.

Трябва да се има предвид, че някои потребители се опитват да манипулират операторите, както и да им представят невярна информация. Възможно е да Ви помолят да им помогнете, като ги omode в някой канал, който "уж" е техен, но няма services за да се провери това. Биха Ви помолили да kill някой, който им е взел ника, но това не е техния ник и, ако бяха налични services, щяхте да видите. Биха Ви помолили да kill някого, защото правел invite, или пък ги бил обидил, не им отговарял на private, бил техен брат, сестра и незнам си още какво (обикновено са доста изобретателни).

Обикновено няма да получавате молби от друг оператор да kill или kline даден потребител. Трябва да се има доверие на колегите оператори, освен ако не сте имали проблеми с някого преди това. Необходимо и да се заинтересувате от причината за въпросния kill или kline. И ако не е безпричинен, добавете "requested by <oper>" или нещо подобно в причината за наказанието.

Не е правилно решение да kill потребител, който Ви flood на private, защото щом ние очакваме нормалните потребители да игнорират flooders, то тогава следва и ние като оператори да правим точно това. Въпреки че е доста глупаво да се flood оператор...

Понякога и операторите имат разногласия, които следва да се решават коректно и с добър тон на личен чат, а не на WALLOPS, LOCOPS или OPERWALL. Не е необходимо потребителите и локалните оператори да участват дори и като свидетели на подобни скандали, нали?! Ако проблема е нерешим по този начин - то той е нерешим извън добрия тон. Kill и Kline на друг оператор определено също не решават различията или проблема. В такива ситуации следва въпроса да се отнесе към администраторите на сървърите, като се обясни подробно проблема, приложат се логове и т.н. Не занимавайте администраторите с подобни неща, освен ако не са важни.


II. Използване на команди KILL, KLINE и GLINE

Командите KILL и KLINE се използват по следния начин:

KILL nick :reason
KLINE nick :reason |hidden reason
KLINE time username@hostmask :reason |hidden reason
UNKLINE username@hostmask

Желателно е в K-lines да се посочва "reason [nick time/date]" за да се знае кога, от кого и поради какви причини е сложен дадения K-line. Скритата причина "hidden reason" се вижда само от други оператори. Маха се с команда UNKLINE.
Не се допуска KLINE на C class мрежа, освен при изключителни причини за това и във връзка с опазване на нормалното функциониране на мрежата. Подобен KLINE не може да е постоянен, а за определено време, като обезателно трябва да съдържа ника на оператора, който го е сложил и причините за това.

Обикновено локалните kills не са голям проблем. Въпреки това следва да са заради нарушение правилата на локалния сървър или мрежата като цяло. На никой не му е приятно да гледа безсмислени kills, били те и локални.

За глобален kill (kill на потребител, който не се намира на вашия сървър) следва да се имат предвид както правилата на мрежата, така и локалните правила на дадения remote сървър. Не трябва да има безпричинни и безсмислени kills, а трябва да са с подобаваща причина, показваща защо се извършва kill.

Потребителите обикновено реагират по 2-3 начина на kill. Повечето пъти разбират, че трябва да променят това, което е в нарушение на правилата. Друг тип реакция е да Ви се търси отговорност защо са били killed. Опитайте се да им обясните, но ако нямат желание да Ви разберат, просто им сложете K-line. След като бъдат K-lined от няколко сървъра, може би ще Ви разберат.

Обикновено трябва да избягвате да слагате K-linе на потребителите, освен ако не е наистина наложително. K-line представлява забрана за потребителя да ползва даден сървър от мрежата, поради някаква причина. В зависимост от сървъра и неговата локална политика, тези K-lines могат да се прамахват след ден, седмица или две, след месец, дори и да не се махат (най-характерно е за EFnet, IRCnet и др. големи мрежи). Преди да се изчистят K-lines, в повечето случаи е добра идея да се поговори с човека, който ги е сложил.

Добре е, преди да извършите global kill, да се запитате "Това наистина ли е наложително?" Обикновено можете да намерите оператор на сървъра, на който е потребителя, и той да свърши работата вместо вас. Ако оператора не иска да го направи, тогава той не иска да премахвате потребителя от сървъра му.

Не е добре да се допускат kills с reason "abuse". Това предполага игнориране на потребителя, който Ви обижда, но не и Kill. Защото, след като го kill, той ще продължи да Ви обижда, а не може да се kill-ва до безкрайност. Недопустимо е операторът да си търси причина за да Kill-ва и kline потребителите.

За flood на private също следва да се игнорира потребителя, а не да се kill или kline. Това важи и за channel flood, особено ако в канала има активни ботове, които са с оп. Ако в канала няма канален оператор е позволен kill само зе предотвратяване на flood, и то ако няма друг начин за да се избегне.

Почти е задължително всеки оператор да си пази логове от всичко, което прави и всичко, което се случва. Няма клиент за IRC чат, който да не позволява логване (включително и след инсталация на допълнителен скрипт). Ако потребител или друг оператор постави въпроса относно някой Ваш operkill (обикновено пред администратора на сървъра Ви или на опер мейл листата), Вие трябва да можете да докажете или подкрепите действията си. Най-често се срещат оплаквания за превишаване на оперски права и логовете са добра идея наистина.

Използване на командата GLINE:

GLINE nick :reason
GLINE time username@hostmask :reason
UNGLINE username@hostmask

GLINE представлява най-общо глобална K-линия. На различните мрежи има различни правила и начин, по който да се Trigger GLINE. На UniBG Network това става или от администратор с права в OS (MSG OS GLINE TIME username@hostmask :reason), или от 4 глобални оператора, като по този начин се намалява възможността за злоупотреби от страна на операторите. Маха се с команда UNGLINE.

Преди да подкрепите подобна глобална линия, е добре да се поинтересувате за причините, както и да проверите, доколкото Ви е възможно, за верността на причините. Такава линия се допуска само в изключителни случаи и само във връзка с опазването на нормалното функциониране на сървъра и мрежата като цяло.

Не се допуска GLINE на C class мрежа, освен при изключителни причини за това и във връзка с опазване на нормалното функциониране на мрежата. Подобен GLINE не може да е постоянен, а за определено време, като обезателно трябва да съдържа ника на оператора, който го е сложил и причините за това.


III. Ботове и лов на Ботове

"bot" се дефинира като всяка автоматична програма или клиент, които функционират следвайки определени инструкции на поведение. Ако клиентът е бездеен за дълъг период от време и ако се държи като бот, той обикновено е считан за такъв.

Има няколко причини, поради които ботовете се смятат за проблем. Първо, те отнемат ресурси в IRC, които биха могли да се ползват от нормални потребители. Главната причина е защото ботовете често се използват за flood и тормоз на потребителите. В различните мрежи ботовете се третират по различен начин, но бот, нарушаващ политиката на мрежата, не бива да се толерира.

Откриването на ботовете не е много трудно. Повечето отговарят със своята реална версия на ctcp version, а именно eggdrop x.x.x. Също така ботовете се откриват с почти всеки порт скенер, понеже повечето слушат на даден порт или портове (почето избрани така, че да се помнят лесно - 3344, 4433, 3333, 4444, 5555, и др.) за входящи telnet връзки.

Разбира се никога няма да можете да намерите всички ботове. Освен това начините за намирането им се променят, затова говорете с другите оператори за новите методи.


IV. Клонинги, Flooders, и Spoofing

Клонингите (clones) се дефинират като множество клиенти от едно място (хост или адрес). Повечето сървъри дефинират това като множество връзки от една и съща маска (user@*host.tld). По принцип клонингите не са толкова голямо зло, стига да не се използват за connection flood към сървъра, за flood или превземане на канали.

Най-добрия подход срещу клонингите е да ги килнете и да видите дали ще се върнат отново. Ако го направите няколко пъти и потребителя продължава да ги пуска, време е за K-line. Тези линии не бива да са перманентни - от няколко часа до 1-2 дни са достатъчни. Излишно е да се слака K-line или G-line на dialup, понеже потребителя набира отново своя доставчик и влиза с друг хост или IP адрес, или пък следващия след него от този адрес няма да може да ползва IRC и то без да е имал вина за това.

Обикновено в IRC се срещат два начина за flood. Първия е CTCP flood, който има за цел да накара потребителя да флудне IRC сървъра с CTCP отговори, при което се включва защитата на сървъра, изхвърляйки потребителя с причина "Excess Flood". Много бот мрежи ("fludnets") използват този тип на flood. Скриптове със flood protection могат да предпазват донякъде от такива атаки, но истинския проблем е самата мрежа. Ако 20 бота flood потребител за 10 секунди, изпращайки пет 100 битови CTCP заявки в секунда, това са 20 * 100 * 5 = 10k/sec, или 100k информация за 10 секунди. При една голяма мрежа такова поведение неможе да се толерира.

Вторият вид flood, който не е свързан с IRC (но е свързан с конфликти в IRC), е ICMP flood. Той обикновено се прави от сравнително бързи връзки (ISDN или по-бързи) и се състои от flood върху потребителя или върху сървъра чрез ICMP пакети (каквито са ping). Това се счита за "Denial Of Service" атака (DoS) и е противозаконно.

Съществуват доста скриптове за flood и някои от тях имат определени никове, които се използват за CTCP flooding. Бихте могли да си ги добавите в notify. Някои скриптове с такова предназначение също така карат клонингите да влизат в определени канали (например #srfloodclones).

DNS spoofing е нещо срещано в IRC. Има най-общо два начина за отркриването му - да следите всички потребители, които се закачат за сървъра (usermode +c) и забележите специфична hostmask, или някой потребител да Ви уведоми за това. Първото нещо, което можете да направите, е да вземете IP на потребителя (/stats L nick) и да видите дали DNS lookup съвпада с IP адреса. Ако не съвпада, знайте, че това е spoof. С тази информация можете да KILL потребителя и, когато се върже отново, вижте кой е истинския host и сложете K-line (което няма да ги спре да spoof отново, но ще ги спре да се свържат *без* spoof). Някои сървъри имат възможността за D-lines, които ви позволяват да забранявате връзките по ip mask. D-line ще спре потребителя да се свързва изобщо, независимо дали е с DNS spoof или не е. Ако сървъра позволява командата DLINE, можете да направите /dline ipmask :причина.


V. Защо операторите (обикновено) не се намесват в афери свързани с канали

Главната цел на операторите е да поддържат сървъра и мрежата, а не да се занимават с канали. Политика за операторите е да не се замесват, понеже не винаги е възможно да се определи на кого трябва да е канала. Има доста потребители, които биха злоупотребили, искайки да им дадете оп в "техния" канал по време на сплит (ако въобще е техен), да килнете еди кой си понеже правел инвайт и т.н.


VI. Отношение към въпроса "Как да стана IRC оператор?"

Повечето потребители не се стесняват да питат какво представлява това да си оператор или как се става оператор, което не означава, че заслужават обиден отговор на въпроса си. Най-лесно е да си направите автоматичен отговор на този въпрос, например:
"За да станете IRC Оператор трябва да имате не само много големи познания за IRC и познания свързани с IRC мрежата, но също така и добри отношения с администраторите и другите оператори. Оператори се избират когато това е необходимо, а не когато се моли за това."

Не бива да се забравя, че винаги ще има потребители, които ще имат въпроси, дори като този, и затова е добре да се отговаря на подобни въпроси в канали като #irchelp или #help.


VII. IRCD и свързаните с него файлове (за Hybserv)

IRCD е процес, който се пуска на сървър с възможност за оставяването му в background - постоянна работа - и се нарича IRC сървър. Големите IRC мрежи допускат само сървъри, базирани на unix и linux операционни системи, защото само те са доказали качеството си за обслужване на големи мрежи. Файловата структура варира в зависимост от вида на сървъра, но трябва да съдържа тези два основни файла:

ircd                     IRC server daemon (главната програма)
ircd.conf             файлът с конфигурациите на сървърът

Конфигурационния файл съдържа множество настройки в себе си, които са под формата на буква и колона. Този файл се чете и използва като заден процес, така че когато използвате команди за статистика STATS (обяснени по-долу), ще видите информация от въведенoтo в ircd.conf. Този файл има следните конфигурации:

A:Company/Institute Name:Server Description:Admin Name <email@address.com>

Това е административна информация за дадения сървър, която се получава с команда /admin на сървъра. Тези полета трябва да са точни за администратора на сървъра, но аз съм сложил тук стандартни.

B:hostmask::nick::

Тази линия включва разрешен бот. Сървърът има вграден бот, който проверява за специфични връзки и ще премахне връзка ако детектне такива. Ако ботът има тази линия в конфигурационния файл, сървърът няма да отхвърля връзки.

C:server hostname:password:server name:port:connection class
N:server hostname:password:server name:hostmask:connection class

C/N-линиите са връзки към други сървъри. C-line дефинира към кои сървъри може да се закача вашия сървър, а N-линията дефинира Вашия сървър на кои сървъри позволява да се закачат за него. Те се използват винаги заедно, неможе да има C без N линия. Server hostname, password и servername са достатъчно ясни. Ако е указан порт, на него Вашия сървър ще се опитва да се закачи автоматично, а ако не е указан такъв, сървъра няма да прави автоматични опити да се закача. Обикновено hostmask не се ползва и всичко е наред. Connection class е цифров и е дефиниран в Y-линиите.

D:ipmask:reason:

Тази линия се използва за да забрани достъп на IP адреси. Например с D-линия можете да забраните 205.230.73.* (причина), като никой от тази C клас мрежа няма да може да влезе на този сървър.

E:hostmask::username

Е-линията предпазва някои потребители от банове на сървърът (К-линии). Главно се използват от операторите за да се предпазят те самите от случайни К-линии, но понякога неоправдано някои доставчици на интернет слагат такива линии за всички свои потребители.

H:remote servers permitted::hub server

Тази линия дефинира hub сървърите, които са сървъри, към които се закачат други сървъри (leaf сървъри). "remote servers permitted" (отдалечен сървър) почти винаги е "*" или съдържа хостмаск за да ограничи връзките от други сървъри.

I:address mask:password:domain mask::connection class

I-линиите определят какви клиенти се допускат до сървъра. Служат и за дефиниране на това в какъв клас за ползване е даденият потребител (определен от Y-линиите). Полето за паролата обикновено е празно.

K:hostmask:time:username

K-линиите са забрана за ползване на сървъра. Възможно е да включва и часови интервал, в който е активна линията. Обикновено тези линии се слагат с командата KLINE, като причината се запомня като коментар в конфигурационния файл.

L:restricted servers::connected server:depth

Служи за идентификация на leaf сървърите закачени за даден hub сървър. Полето за restricted servers е хостмаска на сървър, който няма да бъде допуснат зад закачения сървър (обикновено това поле е празно). depth е колко сървъра могат да бъдат закачени зад него.

M:hostname:*:server description:default port

Тази линия задава основна информация за вашият сървър. Няма строго фиксирано съдържание. Това е задължително поле.

N:

Виж линия С:

О:ident@hostname:password:nickname:connection class
о:ident@hostname:password:nickname:connection class

Тези линии определят операторите на сървъра. Малката o-линия е за локалните оператори, които могат да правят KILLs и K-линии само на този сървър, също така SQUIT и CONNECT на техния сървър от/към Hub сървъра им. Голямата O-линия е за глобалните оператори, които могат да правят глобални KILLs (да килват потребители на всеки сървър от мрежата) както да SQUIT и CONNECT който и да е сървър от мрежата. connection class е определен от Y-линиите.

P::hostmask::port

Това са портовете, на които могат да се свързват потребители към вашият сървър (в добавка към портът, вписан в М-линията). Хостмаската е незадължително поле, чрез което можете да определите какви клиенти могат да се свързват на този порт.

Q::reason:server
Q:nickname:reason

Q-линията определя сървър, който няма да бъде допуснат да се свърже към мрежата като цяло (всички сървъри трябва да имат една и съща Q-линия). Или за да се забрани използването на дадени никове. Например NickServ:Quarantined nick.

R:hostmask:program path:username

Това е разширен вариант на K-линиите. Описва се пътя до външна програма, която определя дали потребителят да бъде допуснат. Когато клиентът се свърже, сървърът вика тази програма с информацията на потребителя. Тогава програмата отговаря дали да му се даде достъп до сървърът или не. Отговорът е или "Y съобщение" и потребителя се допуска, или "N съобщение" и потребителя се отхвърля, като му се изпраща съобщението. За да работи, линията трябва да е активирана от config.h.

Y:class id:ping frequency:connect frequency:max connections:max sendq

Y-линиите определят класът на връзка (connection class). Class id е номер, който идентифицира класът и се използва в I-линиите и C/N-линиите. Ping frequency е времето (в секунди) между ping requests (за да провери дали линията още е активна и клиента не е излязъл). Connect frequency е времето между опитите за автоматичен линк между сървърите (трябва да е нула за класовете на потребителите). Max connections е максималния брой потребители за дадения клас. "SendQ" е обема данни (в байтове), който е позволен за дадена връзка, преди сървъра да я затвори (със съобщение "SendQ Exceeded").

Препоръчвам да прочетете example.conf в дистрибуцията на IRCD, където ще намерите примери с подробно описание.


VIII. Команди за информация от сървъра (TRACE, STATS, LINKS и HTM)

Има няколко команди, които можете да използвате за да се сдобиете с информация за състоянието на сървъра, за да ви помогнат в контрола:

TRACE [server|nick]

Командата TRACE се използва за проследяване на пътя от вашия сървър до друг сървър или клиент.

Когато е към сървър, TRACE ще покаже информация за него и за съществуващите към него връзки, влизащите връзки заедно с типа на техния клас и номера на потребителите от всеки клас. Връзките на операторите съдържат класа на връзката, псевдонима и user@hostmask. За връзките на други сървъри се показва класът на връзка, броят на сървърите, които стоят зад нея (последвани от "S"), броят на клиентите зад и на нея (последвани от "C"), името на сървъра и кой е направил свързването му.

Когато е към потребител, TRACE показва класът връзка, псевдоним и user@hostmask на потребителя.

STATS [letter]

Командата STATS връща информация от сървъра. Някои администратори скриват тази въжможност за нормалните потребители и тя може да бъде видяна само от оператор на някой от сървърите на мрежата. Параметрите варират в зависимост от версията на сървъра, но това са най-често срещаните в почти всички ircd версии:

     ?   Статистика за трансфер и свързване на сървъра
     b   B-линии
     c   C/N-линии
     d   D-линии
     е   E-линии
     h   H/L-линии
     i   I-линии
     k   K-линии
     l   Сведения за трансфера по връзки. Цифровите полета са както следва:
            sendQ (последователност или лимит на излизащите съобщения)
            sendM (протоколни съобщения изпратени)
            sendK (общият брой изпратени килобайти)
            receiveM (протоколни съобщения получени)
            receiveK (общият брой получени килобайти)
            времето в секунди от създаването на връзката
     L   Същото като STATS l, но показва IP вместо хост
     m   Статистика за командите
     о   О/о-линии
     р   Показва идентифициралите се в момента оператори на сървъра
     t   Обща статистика за сървъра
     u   Показва от колко време не е спиран сървъра - uptime
     v   Информация за свързването на сървъра към другите сървъри
     y   Y-линии
     z   Допълнителна информация за сървъра

Ако не сте IRC Operator, не е препоръчително да тествате всичките тези неща наведнъж. Многократното използване на командата STATS обикновено се възприема като атака към сървъра, защото може да запълни sendQ лимита на сървъра и да предизвика сплит.

LINKS [server mask]

Тази команда показва структурата на IRC мрежата. Всеки ред съдържа името на сървъра, неговия hub, брой "hops" от вашия до другия сървър и описание на сървъра.

HTM

Използва се за да се види и зададе режим на висок трафик. Допълнително показва постъпващото количество данни, което е полезно, когато се следи как се свързва сървъра наново към мрежата след сплит.


IX. Определяне мястото на сървър, разкачане и съединяване (SQUIT и CONNECT)

Тази секция се отнася преди всичко до hub сървърите, както и до отдалеченото разкачане и закачане на сървъри от мрежата. Да приемем, че мрежата има следния вид:

        A-----B----C----D
              |         |
        E-----F         G----H
        |     |         |
        I     J----K    L----M

Обикновено, когато възникне проблем, първо се забелязва по забавянето на отговорите от другите потребители. Може да ping няколко потребителя и забелязвате, че времето за отговор е голямо. Обикновено с ping на канал или LINKS, можете да установите къде е проблема.
Да приемем, че Вие сте на сървър А, отговорите от ping към сървър С са добре, но всичко от сървър D и нататък е забавено. Първото нещо, което трябва да направите е STATS l на сървър С (/stats l irc.c.com) за да видите изходния sendQ към сървър D. Той може да изглежда така:

211 irc.d.com[123.231.132.213] 1621588 9780 559 469469 24111 5862

SendQ е първото число след IP адреса, или 1621588 в този случай. Ако направите STATS y на сървър С (/stats y irc.c.com), можете да видите максималното sendQ позволено от сървъра. Потърсете клас на връзка с различна от 0 стойност за честотата на свързване (600 в този случай).

218 Y:0:120:600:10:4000000

Така че, ако това число достигне 4000000, сървър С ще откачи от себе си сървър D и ще видите всички от негo да излизат със съобщение от вида "*** Quit nick (irc.c.com irc.d.com)".

Сега, ако сте на сървър L, би трябвало да направите STATS l на сървър D (/stats l irc.d.com) и да потърсите информация за сървър С. В този случай вие може да видите следното:

211 irc.c.com[123.213.123.231] 142 8841 512 485915 21059 1234

След като sendq от сървър irc.d.com към сървър irc.c.com е само 142 байта, изглежда има забавяне само в едната посока (сървър irc.d.com има проблем при получаването на данните от irc.c.com).

Да кажем, че продължавате да наблюдавате sendQ от irc.d.com кам irc.c.com (с команда /stats l irc.d.com от вашата позиция на сървър А) и той се е увеличил от 1621588 байта на 3140419 байта. Можете да изчакате да видите дали ще се сплитнат, но приемаме, че решавате да прерутирате мрежата.

Преди да направите каквото и да е било, трябва да влезете с още един клиент на сървър L и да направите STATS c на сървър D (/stats c irc.d.com) за да видите къде може да се закачи. Да кажем, че е подходящо да се свърже към сървър F. Сега остава да изберете подходящ за целта порт. От вашият клиент на сървър L, направете STATS l на сървър D (/stats l irc.d.com) и вижте какви портове има отворени.

211 irc.d.com 0 30844455 1978134 15372958 794195 156641 156641 -
211 irc.d.com[@*@*.6665] 0 702234 48662 118794 5963 156641 156641 -
211 irc.d.com[@*@*.6666] 0 1750847 130878 547336 22204 156641 156641 -
211 irc.d.com[@*@*.6668] 0 568644 38618 100102 4626 156641 156641 -
211 irc.d.com[@*@*.6669] 0 701079 48973 121065 5271 156641 156641 -

Първият ред е default порта (6667) и изглежда, че е доста натоварен, затова нека използваме някои друг порт за свръзка, например 6665. Сега трябва да разкачите сървър D от сървър С и тогава да кажете на сървър F да се свърже към сървър D на порт 6665. Ние ще направим всичко това от сървър А. Започваме с команда SQUIT, която има вида

SQUIT server :reason

/squit irc.d.com :reroutе

Сега е добре да се изчака около минута, за да може сървърите да обработят смяната и след това да се продължи с командата CONNECT, която има вида

CONNECT server port link_server

/connect irc.d.com 6665 irc.f.com

Можете да проверите дали всичко е наред с командата STATS l на irc.f.com, въпреки че в повечето случаи добрия линк става за по-малко от минута.

Ако извършвате всички действия не от хъб-а, а от някой от свързаните leaf сървъри (както аз го направих сега), тогава вие общо взето ще направите SQUIT и CONNECT само локално. Така че ще имате следната мрежа:

	A----B----C
	          |
	     D----E

И ако вие сте на сървър А, с реално закъснение към мрежата, тогава можете сам да се презакачите към сървър D с:

/squit irc.b.com :reroute
/connect irc.d.com [port]

Ако даден сървър има проблеми с голям лаг или не му е в ред синхронизацията на времето, което води до TS DELTA и голяма разлика във времето и невъзможност за закачане на сървъра към неговия Hub, то той обикновено бива Squit-нат или Jupe-нат от мрежата до неговото оправяне.


X. Други команди свързани със сървъра (REHASH, RESTART и DIE)

Това са команди, които няма да ви се наложи да ползвате често, освен ако не сте администратор на сървър.

REHASH

Командата кара сървъра да прочете отново конфигурационния файл. Това се прави след промени в ircd.conf. Същото може да се постигне и в конзола с командата kill -HUP pid

RESTART

Командата рестартира сървъра. Всички клиенти биват изхвърлени от него докато се рестартира (включително и Вие).

DIE

Тази команда спира сървърът. Това се прави, когато се рестартира компютърът, на който е пуснат IRCD.


XI. Комуникация между операторите (WALLOPS, LOCOPS и OPERWALL)

Командите се използват зе изпращане на съобщения към другите оператори в мрежата. Начинът за използването им е следният:

WALLOPS :съобщение
OPERWALL :съобщение
LOCOPS :съобщение

Когато правите отдалечен CONNECT или SQUIT, сървърът изпраща автоматично съобщение на WALLOPS за вашите действия. Имайте предвид, че използването на тези команди е в зависимост от мрежовата политика относно правата на локалните, глобалните оператори и администраторите за начина и ситуацията на използване на тези команди. В някои мрежи командата OPERWALL и/или WALLOPS е забранена за използване от локалните оператори.


XII. Закачане на нови сървъри към мрежата

Всеки потребител може да поиска да закачи свой сървър, най-вече заради самочувствието да бъдеш администратор на сървър в голяма мрежа.

Всяка мрежа си има свои правила за линк на нови IRC сървъри, затова следва да се поинтересувате за правилата на мрежата, към която възнамерявате да поискате включване. Обикновено се изисква попълването на специална форма за закачане, в която се описват - собсвеник на сървъра, операционна среда, хардуерни компоненти на сървъра, каква програма използва за синхронизация на времето, име и e-mail на администратора му, дали има root права на сървъра, адрес и телефони, географско разположение, топографско разположение спрямо основните интернет доставчици и спрямо peering-а, traceroute и ping информация до основните hub-ове на мрежата и др.

Някои основни изисквания, на които следва да се наблегне са:
скоростта, която можете да заделите за IRC сървъра;
операционната среда следва да е Linux или Unix;
оперативна памет на сървъра, която не трябва да се заема с други процеси;
съществуващи IRC потребители;
бъдещи оператори на сървъра;
политика на сървъра и мрежата.


XIII. Заключителни бележки

Не трябва да се забравя, че на дадена мрежа има правила, които са задължителни за спазване. Особено не бива да се забравя, че операторите на даден сървър трябва да следват особено стриктно правилата и да не използват специалните си привилегии за излизане от спор, налагане на собственото си мнение, или упражняване на безсмислена власт. Една мрежа се прави от потребителите, а не от администратора и операторите на сървърите. Да притежаваш операторски статус е отговорност, която трябва да се поема сериозно. Операторът е длъжен доколкото разполага с време и възможност да помага на потребителите на мрежата.