IRC.OPER FAQ
Този документ описва правата, задълженията и същността на операторския статус в дадена IRC мрежа от моя точка. Не претендира за изчерпателност или всеобхватност, нито за шаблонност и задължителност.
Въведение
Ще се опитам да дам малко повече информация по въпроса, както и малко лично мнение какво трабва да представляват примерните правила и поведение в дадена IRC мрежа, без това да е отношение към мрежовата политика на сървъра и мрежата, в която съм оператор. Присъствал съм на разпадането на няколко малки IRC мрежи, доста от които заради липсата на строго фиксирани и определени правила, или самозабрава на оператори и администратори. Едва ли някой може да претендира за изчерпателност и всеобхватност - не бих го направил и аз. Вярвам, че могат да се изпишат и тонове хартия относно IRC, макар да не виждам смисъл. Доста от нещата е добре даденият потребител да си ги открие сам и да получи удоволетворение (което би трябвало да е повече от удоволетворението да получиш нещата за 10 мин. наготово). Ако считате, че има неточности и грешки, или не сте съгласни с изразеното мнение - можете да ме уведомите.
Поведение спрямо другите потребители и операторите
Това един от най-важните аспекти, които следва да се имат предвид. Съществуват доста различни политики на различните мрежи относно обществото на IRC операторите, и дали Ви харесват или не - те са създадени и приети и следва да се спазват.
Операторът не трябва да гледа отвисоко на потребителите, да си прави шоу с тях или да им се подиграва, да ги игнорира. Всеки оператор е длъжен доколкото има свободно време да помага на потребителите, отговаряйки на техните въпроси или оказвайки им помощ по принцип. Освен ако съобщенията на прайвит не са безсмислени, обидни, свързани с въпроси описани в помощната секция на мрежата. Би било добре всеки оператор когато има време да прекарва по някой час в някой от официалните помощни канали на мрежата, помагайки на потребителите.
Трябва да се има предвид, че потребителите имат навика да манипулират операторите както и да им представят невярна информация. Биха Ви карали да им помогнете като ги omode в някой канал, който "уж" е техен, но няма services за да се провери това. Биха Ви помолили да kill някой, който им е взел ника, а това си е техния ник и само да бяха налични services щяхте да видите. Биха Ви помолили да kill еди кой си, защото правел invite, или пък ги бил обидил, не им отговарял на private, бил техен брат, сестра и незнам си още какво (обикновено са доста изобретателни).
Обикновено няма да получавате молби от друг оператор да kill или kline даден потребител. Трябва да се има доверие на колегите оператори, освен ако не са Ви излъгали доверието преди това. Необходимо и да се заинтересувате от причината за въпрасния kill или kline. И ако не е безпричинен, добавете `requested by [opernick]` или подобно съобщение в kill или kline който правите.
Не е правилно решение да kill потребител, който Ви flood на private, защото щом ние очакваме нормалните потребители да игнорират flooders, то тогава следва и ние като оператори да правим точно това. Въпреки това следва да се съгласим, че е глупаво да се flood оператор...
Понякога и операторите имат разногласия. Които разногласия следва да се решават коректно и с добър тон на личен чат, а не на WALLOPS, LOCOPS или OPERWALL. Не е необходимо потребителите и локалните оператори да участват дори и като свидетели на подобни скандали, нали?! Ако проблема е нерешим по този начен - то той е нерешим извън добрия тон. Kill и Kline на друг оператор определено също не решават различията или проблема. В такива ситуации следва въпраса да се отнесе към администраторите на сървърите, като се обясни подробно проблема, приложат се логове и т.н. Не занимавайте администраторите с подобни неща, асвен ако не са важни.
Използване на команди KILL и KLINE
Синтаксиса на командите е както следва:
KILL nick причина
KLINE nick :причинаreason
KLINE time username@hostmask :причина
В моите K-lines, използвам почти винаги "reason [NightWish]" за да се знае откого и поради какви причини е солжен дадения K-line.
Не се допуска KLINE на C class мрежа, освен при изключителни причини затова, и във връзка със опазването нормалното функциониране на мрежата. Подобен KLINE неможе да е темпорален, а за определено време. Като обезателно трябва да съдържа ника на оператора, който го е сложил и причините затова.
Обикновено локалните kills не са голям проблем. Въпреки това следва да са заради нарушение правилата на лакалния сървър или мрежата като цяло. На никой не му е приятно да гледа безсмислени kills, били те и локални.
За глобален kill (kill на потребител, който не се намира на вашия сървър) следва да се имат предвид както правилата на мрежата, така и локалните правила на дадения remote сървър. Не трябва да има безпричинни и безсмислени kills. А kill-а трябва да е с подобаваща причина, показваща защо се извършва kill.
Потребителите обикновено реагират по 2-3 начина на kill. Повечето пъти разбират, че трябва да променят, нещото което е в нарушение на правилата. Друг тип реакция е да Ви се търси отговорност защо са били killed. Опитайте се да им обясните, ако няма шанс и желание да Ви разберат, просто им сложете K-line. След като бъдат K-lined от няколко сървъра, може би ще Ви разберат.
Не трябва да се допускат безсмислени K-lines, освен ако не е крайно наложително. K-line представлява забрана за потребителя да ползва даден сървър от мрежата, поради някаква причина. В зависимост от сървъра и неговата локална политика, тези K-lines могат да се прамахват след ден, седмица или две, след месец, дори и да не се мехат (най-характерно е за EFnet, IRCnet и др. големи мрежи). Преди да се изчистят K-lines, в повечето слячаи е добра идея да се поговори с човека, който ги е сложил.
Най-добрия въпрос, преди да извършите global kill, е да си запитате "Това наистина ли е наложително?" Предполага лесно можете да намерите друг оператор локално на сървъра, на който е провинилия се според Вас потребител, който да се заеме със случая. Ако този оператор е против да направи local kill, то той сигурно би бил против и 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 :причина
GLINE представлява най-общо глобална K-линия. На различните мрежи има различни правила и начин, по който да се Trigger GLINE. На UniBG Network това става или от администратор с права в OS ( MSG OS GLINE TIME username@hostmask :reason ). Или от 4 глобални оператора, като по този начин се намалява възможността за злоупотреби от страна на операторите.
Преди да подкрепите подобна глобална линия, е добре да се поинтересувате за причините, както и да проверите доколкото Ви е възможно за верността на причините. Такава линия се допуска само в изключителни случаи и само във връзка с опазването на нормалното функциониране на сървъра и мрежата като цяло.
Не се допуска GLINE на C class мрежа, освен при изключителни причини затова, и във връзка със опазването нормалното функциониране на мрежата. Подобен GLINE неможе да е темпорален, а за определено време. Като обезателно трябва да съдържа ника на оператора, който го е сложил и причините затова.
Ботове
"bot" се дефинира като всяка автоматична програма или клиент, които функционират следвайки определени инструкции на поведение. Има няколко причини, поради които се възприема, че понякога ботовете представляват проблем. Първо, те отнемат ресурси в IRC, които биха могли да се ползват от нормални потребители. Главната причина всъщност е защото ботовете често се използват за да пречат на потребителите - под формата на флууд разбира се. В различните мрежи се третират по различен начин ботовете, но бот нарушаващ политиката на мрежата не бива да се толерира.
Откриването на ботовете не е много трудно. Повечето отговарят със своята реална версия на ctcp version, а именно eggdrop x.x.x. Също така ботовете се откриват с почти всеки порт скенер, понеже повечето слушат на даден порт или портове (почето избрани така, че да се помнят лесно - 3344, 4433, 3333, 4444, 5555, и др.) за входящи telnet връзки.
Clones, Flooders, and Spoofing
Клонингите се дефинират като множество клиенти от едно място (хост или адрес). Повечето сървъри дефинират това като множество конекции от една и съща маска ( user@*host.tld). По принцип клонингите не са толкова голямо зло, стига да не се използват за connection flood към сървъра, за flood или TakeOver на канали.
Най-добрия подход срещу клонингите е да ги килнете и да видите дали ще се върнат отново. Ако това се повтаря и потребителя продължава да ги пуска, време е зе K-line. А ако са на различни сървъри за G-line. Тези линии не бива да са перманентни - от няколко часа до 1-2 дни са достатъчни. Излишно е да се слака K-line или G-line на dialup, понеже потребителя набира отново своя доставчик и влиза с друг хост или IP адрес, или пък следващия след него от този адрес няма да може да ползва IRC и то без да е имал вина затова.
Обикновено в IRC се срещат два начина за flood. Първия е CTCP flood, който има за цел да накара потребителя да флудне IRC сървъра с CTCP отговори, което включва защитата на сървъра, и изхвърляйки потребителя с причина"Excess Flood". Скриптове със flood protection могат да предпазват донякъде от такива атаки, но истинския проблем е самата мрежа. Ако 20 бота флуднат потребител за 10 секунди, изпращайки пет 100 битови CTCP заявки в секунда, това са 20 * 100 * 5 = 10k/sec, или 100k информация за 10 секунди. При една голяма мрежа такова поведение неможе да се толерира.
Вотрият тип flooding, който няма много отношение с IRC (но е често в резултат на конфликти в IRC), е ICMP flooding. Това обикновено става от бърза линия (ISDN или по-бърза) и включва флуд на потребителя с ICMP пакети (какъвто е ping). Това се възприема като "Denial Of Service" атака (DoS), и е противозаконно.
Съществуват доста скриптове за флуд, и някой от тях имат определени никове, които се използват за CTCP flooding. Бихте могли да си ги добавите в notify. Някой скриптове с такова предназначение също така карат клонингите да влизат в определени канали (като да кажем #srfloodclones).
DNS spoofing е нещо срещано в IRC. Има най-общо два начина за отркриването му - да следите всички потребители, които се закачат за сървъра (usermode +c) като по този начин бихте забелязали подобен спуфинг, или ако някой друг потребител докладва за наличието на това. Първото нещо, което следва да се направи и да се открие потребителския IP адрес (/stats L nick), и да се провери дали DNS lookup съвпада с този IP адрес. Ако не съвпада, имате spoof.
Защо операторите (обикновено) не се месят в политиката на каналите
Основната функция е да се поддържат сървърите и мрежата стабилна и работоспособна, а не да се занимават с канали. Главната причина особено при сплит на мрежата, когато няма сървисес е че понякога е трудно да се установи кой всъщност трябва да контролира дадения канал. Има доста потребители, които биха злоупотребили - искайки да им дадете оп в `техния` канал по време на сплит (ако въобще е техен), да килнете еди кой си понеже правел инвайт и т.н.
Справяйки се с въпроса "Как да стана IRC Operator?"
Повечето потребители не се стесняват да питат какво представлява това да си оператор или как се става оператор, и колкото и хора да Ви задават този въпрос не означава, че заслужават обиден отговор на въпроса си. Най-лесно е да си направите малък алиас на скрипта си, който да дава крътак отговор на въпроса. Нещо от сорта на "За да станете оператор се изисква не само задълбочени познания за IRC и IRC мреже, но също така и добри отношения с администраторите и другите оператори. Оператори се избират когато това е необходимо, а не когато се моли затова". Не бива да се забравя, че винаги ще има потребители, които ще имат въпроси, дори като този, и затова е добре да се отговаря на подобни въпроси в канали като #irchelp или #help.
IRCD и файлове към него IRCD е IRC демон, наричан още IRC сървър. Големите IRC мрежи позволяват само unix и linux-базирани сървъри, защото само те са доказали наистина своята стабилност да обсляжват голяма мрежа. UniBG използва hybrid версия на сървърите. Файловата структура варира в зависимост от различните сървъри, но при всички положения следва да съдържа тези два основни файла:
ircd IRC демон (основна програма)
ircd.conf конфигурационния файл
Конфигурационния файл съдържа множество настройки в себе си, които са под формата на буква и колона. Този файл се чете и използва като заден процес, така че когато използвате команди за статистика STATS (следвани от буква), Вие ще видите описаните настройки по-доло:
A:Компания/Институция:Описание на сървъра:Име на Администратора
Това е т.нар. административна информация за дадения сървър, която се получава с команда /admin на дадения сървър. The fields are completely up to the administrator of the server, but what I put above seems fairly standard. This is a mandatory field.
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
E-линиите служат за защита и изключение на потребителите от K-линии. Главно се използват от операторите за да се защитават тях самите от инцидентни k-линии, понякога неоправдано някой доставчици на интернет слагат такива линии за всички свои потребители.
H:remote servers permitted::hub server
Тази линия дефинира hub сървърите, които са сървъри към които се закачат други сървъри (leaf сървъри). Отдоличиншти пжзвжлинш сървъри са обикновено"*" или съдържат хостмаска, която да ограничи свързващите се сървъри извън нея.
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: <виж C:>
O:ident@hostname:password:nickname:connection class
o:ident@hostname:password:nickname:connection class
Тези линии дефинират операторите на сървъра. Малката o-линия е за локалните оператори, които могат да правят локални KILLs и KLINE, също така SQUIT и CONNECT на техния сървър от/към Hub сървъра им. Голямата O-линия е за глобалните оператори, които могат да правят глобални KILLs (да килват потребители на всеки един сървър от мрежата) както де SQUIT и CONNECT който и да е сървър от мрежата. connection class е определен от Y-линиите.
P:hostmask:::port
Това са портовете, които сървъра допуска потребители да го ползват (обикновено се оказват допълнитените портове изван указания като основен или наречен още default в M-линията). hostmask е допълнително поле, което може да определи от кои хостове може да се ползва дадения порт.
Q:nickname:reason
Използват се за да забранят използването на дадени никове. Например NickServ:Quarantined nick.
R:*.exe
Забранява предаването на файлове през сървъра с зададени разширения. Обикновено служи за предпазване на новите потребители от вируси и други подобни програми, разпрастраняващи се по irc сървъра и клиентите за чат.
Y:class id:ping frequency:connect frequency:max connections:max sendq
Y-линиите дефинират connection class. class id е номер който идентифицира дадения клас, и се използва в I-линиите и C/N-линиите. e ping frequency е времето (в секунди) между ping requests (за да порвери дали линията още е активна или клиента не е излязал или дропнал). Connect frequency е времето между опитите за автоматичен линк между сървърите (трабвя да е нула за класовете на потребителите). Max connections е максималния брой потребители за дадения клас. "sendq" е обема данни (в bytes) който е позволен за дадена връзка преди сървъра да я затвори (със съобщение"Sendq exceeded").
Препоръчва се да се прочете внимателно example.conf идващ със всяка ircd дистрибуция.
Команди за информация от сървъра (TRACE, STATS, LINKS, и HTM)
TRACE [сървър|ник] - Командата TRACE се използва за да проследи пътя от Вашия сървър към друг сървър или потребител.
Когато това е сървър, TRACE ще покаже информация за него и за съществуващите към него връзки, влизащите връзки заедно със типа на техния клас, и номера на потребителите от всеки клас. Операторските връзки съдържат клас, ник на оператора, и user@hostmask на оператора. Връзките на сървъра - показва класа, номера на сървърите зад него (следвани от"S"), номера на клиентите на него и зад него (следвани от "C"), име на сървъра и кой е направил свързването му.
Когато това е потребител, TRACE показва класа на връзване, ник и user@hostmask за този потребител.
STATS [буква] - командата STATS служи за получаване на информация от сървъра. Някой администратори скриват тази важможност за нормалните потребители и тя може да бъде видяна само от оператор на няко от сървърите на дадената мрежа. Варират в зависимост от версията на сървъра, но това са най-често повтарящите се във почти всички ircd версии:
? статистика относно трансфер и свързване на сървъра
b B-линии
c C/N-линии
d D-линии
e E-линии
h H/L-линии
i I-линии
k K-линии
l трансфер на данни според класа
Цифровите полета са както следва:
sendQ (последователност или лимит на излизащите съобщения)
sendM (протоколни съобщения изпратени)
sendK (общо изпратени kilobytes)
receiveM (протоколни съобщения получени)
receiveK (общо получени kilobytes)
времетраене в секунди от създаването на връзката
L същото като STATS l, само дето показва IP адреси а не хостове
m статистика за командите
o O/o-линии
p идентнати оператори на сървъра
t обща статистика за сървъра
u uptime на сървъра
v link информация за сървъра
y Y-линии
z допълнителна статистика за сървъра
Ако не сте IRC Operator, не е препоръчително да тествате всичките тези неща наведнъж. Множеството STATS искания се възприемат често като атака към сървъра, пожене би могло да запълни sendq лимита на сървъра и да предизвика сплит.
LINKS [server mask] - показва структурата на irc мрежата. Всяка линия съдържа име на сървъра, неговия hub, брой `hops` от вашия до другия сървър, и описание на сървъра.
HTM - използва се да се даде информация или да се използва режима на висок трафик или нормален трафик, особено при ситуации на сплитови и разкачане/закачане на сървъра към мрежата.
Рутиране и свързване на сървъра
Тази секция се отнася преди всичко до hub сървърите, както и до отдалеченото разкачане/дакачане на сървъри от мрежата. Да приемем, че една мрежа има следния вид:
A-----B----C----D
| |
E-----F G----H
| | |
I J----K L----M
Обикновено когато има проблем, първо се забелязва по забавения отговор на request-ите от другите потребители. Да приемем, че се намираме на сървър A, всичко до сървър C е наред, но всички от сървър D и след него са лагнати. Първото нещо, което се прави е STATS l на сървър C (/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 на сървър C (/stats y irc.c.com), можем също да видим максималния размер на позволения sendq.
218 Y:0:120:600:10:4000000
Значи ако цифрата стане 4000000, сървър C ще откачи от себе си сървър D, и всички от негo ще излязат със съощение от сорта на *** Quit: nick (irc.c.com irc.d.com).
Now, if you were on server L, you would do STATS l on server D (/stats l irc.d.com) and look for the entry for server C. In this scenerio, you might see
211 irc.c.com[132.213.123.231] 142 8841 512 485915 21058 1234
След като sendq от сървър irc.d.com към сървър irc.c.com е само 142 bytes, изглежда че това и еднопосочен лаг (сървър irc.d.com има проблем при получаването на данните от сървър irc.c.com).
Да кажем, че продължаваме да проверямаве данните за sendq от irc.d.com към irc.c.com (с помощта на командата /stats l irc.d.com от сървъра на който се намираме - A), и се е увеличило от предишните 1621588 bytes на 3140419 bytes. Значи наближава положение, при което ще има сплит и решаваме да прерутираме мрежата.
Преди да направите каквото и да е било, е добре да пуснете втори клиент на сървър L за да направи STATS c на сървър D (/stats c irc.d.com) за да види къде може да се закачи. Да кажем, че подгодящ алтернативен сървър за закачане и сървър F. Сега остава само да изберем подходящия за целта порт. От друг Ваш клиент на сървър L, правите STATS l за сървърr 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 от server C, и след това казваме на сървър F да се закачи за сървър D на порт 6665. Това го правим от сървър A. Започваме със командата SQUIT
/squit irc.d.com :reroute
В този случай е добре да се изчака около минута за да приемат сървърите смяната и след това да се продължи с командата CONNECT
/connect irc.d.com 6665 irc.f.com
Можете да проверите дали всичко е наред с командата STATS l на irc.f.com, въпреки че в повечето случаи добрия линк става за по-малко от минута, дори за секунди.
Ако сте локален оператор или искате да прерутирате сървъра на който сте оператор:
A----B----C
|
D----E
на сървър A имате сериозен лаг в мрежата, можете да се прерутирате на към сървър D със:
/squit irc.b.com :reroute
/connect irc.d.com [port]
Ако даден сървър има проблеми с голям лаг или не му е в ред синхронизацията на времето, което води до TS DELTA и голяма разлика във времето и невъзможност за закачатне на сървъра към неговия Hub, то той обекновено бива Squit-нат или Jupe-нат от мрежата до неговото оправяне.
Други команди на сървъра (REHASH, RESTART, и DIE)
Това са команди, които няма да ви се наложи да ползвате често, освен ако не сте администратор на дадения сървър
REHASH - командата кара сървъра да прочете отново конфигурационния файл. Праве се след промени по него. Като този ефект може да се постигне и в конзола с командата kill -HUP pid
RESTART - командата рестартира сървъра. Всички клиенти биват изхвърлени от него докато се рестартира (включително и Вие).
DIE - командата спира сървъра. За да се пусне отново е необходим достъп до сървъра, от който се пуска.
Комуникация между операторите (WALLOPS, LOCOPS и OPERWALL)
WALLOPS (LOCOPS и OPERWALL) командите се използват зе изпращане на събощение към другите оператори в мрежата. Oper wallops were originally publically visible and intended to be used for disaster announcements and the like, but have been abused to the point where now they are operator only.
Имайки предвид, че доста от съвременните чат клиенти го имат включено като alias и в такъв случай двуеточието е излишно, формата на командите е :
WALLOPS :съобщение
OPERWALL :съобщение
LOCOPS :съобщение
Когато използвате CONNECT или SQUIT, сървъра изпраща автоматичен нотис на WALLOPS за Вашите действия. Имайте предвид, че използването на тези команди е в зависимост от мрежовата политика относно правата на локалните, глобалните оператори и администраторите за начина и ситуацията на използване на тези команди. В някои мрежи командата OPERWALL и/или WALLOPS е забранена за използване от локалните оператори.
Закачане на други сървъри към дадена мрежа
Всеки потребител иска да закачи свой сървър, най-много заради издигането на самочувствието да бъдеш администратор на сървър на голяма мрежа, и в частност защото иска да го представи като услуга към потребителските бази.
Всяка различна мрежа си има свои правила за линк на нови IRC сървъри, затова следва по този въпрос да се поинтересувате за правилата на мрежата, към която възнамерявате да поискате включване. Обикновено се изисква попълването на специална форма за закачане, в която се описват - собсвеник на сървъра, операционна среда, хардуерни компоненти на сървъра, каква програма използва за синхронизация на времето, име и e-mail на администратора му, дали има root права на сървъра, адрес и телефони, географско разположение, топографско разположение спрямо основните интернет доставчици и спрямо peering-а, traceroute и ping информация до основните hub-ове на мрежата и др.
Някой основни изисквания, все пак на които следва да се наблегне са : скоростта, която можете да заделите за IRC сървъра операционната среда следва да е Linux или Unix оперативна памет на сървъра съществуващи IRC потребители бъдещи оператори на сървъра Ви политика на сървъра и мрежата
Заключителни бележки
Не трябва да се забравя, че на дадена мрежа има правила, които са задължителни за спазване. Особено не бива да се забравя, че операторите на даден сървър трябва да следват особено стриктно правилата и да не използват специалните си привилегии за излизане от спор, налагане на собственото си мнение, или упражняване на безсмислена власт. Една мрежа се прави от потребителите, а не от администратора и операторите на сървърите. Да притежаваш операторски статус е отговорност, която трябва да се поема сериозно. Операторът е длъжен доколкото разполага с време и възможност да помага на потребителите на мрежата.
2001-10-01
фотография Kaladan | email | www
keywords
oper, operator, admin, administrator, server, irc server, power, rules, faq, help, users, flood, rehash, kill, die
