– Лицата от екипа на мрежата са преди всичко и потребители, и освен ако правилата не го позволяват (и/или изискват), трябва да се държат като такива, и нямат право да използват привилегиите си по нерегламентиран от правилата начин.
– Всеки потребител има право на свободен достъп до мрежата, стига по време на престоя си в нея да не нарушава правилата й.
– Достъпът до мрежата може да бъде ограничен чрез филтриране на връзки през proxy-та (и/или други подобни), както и чрез проверки за вируси, flood, drones, clones, spam (реклами), злонамерени скриптове или други новоустановени заплахи за мрежата.
– Правото за достъп до мрежата на даден потребител може да му бъде отнето, при констатиране на негово нарушение, от страна на лице от екипа на мрежата.
– Освен вече конкретизираните нарушения в правилата, за такива се смятат и: spam/реклами, flood;

Разпространение на вируси и/или злонамерени кодове/софтуери:
– Целенасочени опити за дестабилизиране на дадена услуга или сървър от мрежата;
използване на мрежата и услугите й за незаконни цели.
– Лице, което официално не е част от екипа на мрежата, няма право да използва операторска линия (била тя на даден сървър, в services или други инструменти предназначени за използване от екипа на мрежата) независимо дали достъпът до нея му е даден доброволно или е придобит по друг начин.

CORE TEAM – Всички IRC администратори на сървъри и собственици на уеб чатове с над 50 потребителя, както и всички съоснователи на FreeUniBG IRC Network.
GLOBAL CHANNEL – #Bulgaria

1. Всички в CORE TEAM имат право да предлагат нови идеи, правила, промени в техническо или политическо отношение свързани с мрежата.
2. Всички в CORE TEAM имат право на равнопоставен глас при гласуването на дадена идея, проблем, промяна в политика или правила в мрежата.
3. Всички в CORE TEAM са добавени с еднакъв левел в GLOBAL CHANNEL, с цел да се съблюдава глобалната политика на мрежата, тей като до голяма степен той олицетворява самата нея.
4. Всички в CORE TEAM които са добавени в GLOBAL CHANNEL НЯМАТ ПРАВО ДА:

а. премахват или променят левела и статуса на останалите от CORE TEAM в канала
б. да налагат еднолична политика по отношение на канала (това става чрез предложение и всеобщо гласуване от всички core admins)
в. да добавят еднолично нови канални оператори (това става чрез предложение и всеобщо гласуване от всички CORE TEAM , в случай че няма добавени канални оператори – CORE TEAM изпълняват техните функции и задължения)

5. Всеки член на CORE TEAM нарушил правилата от точка 4 бива моментално изтрит премахнат от GLOBAL CHANNEL!
6. Всеки администратор на сървър има право да добавя IRC оператори на сървъра си по свое усмотрение – като IRC операторите не са част от CORE TEAM и нямат право на глас при взимането на решения свързани с мрежата!
7. Всеки IRC оператор нарушил точка от кодекса на мрежата – подлежи на наказание след гласуване от CORE TEAM.
8. Точки от едно до 8 – не могат да бъдат променяни или предлагани за гласуване, те са основните закони по които се ръководи мрежата и важат за всички!

Съществуват 3 типа канали:

– Операторски
– Със специален статут
– Обикновени

Операторски канали са #operwall и #bopm:

– в тях имат право да влизат само хора от екипа на мрежата
– управляват се изцяло от администраторите на мрежата

Каналите със специален статут са:

– #Bulgaria

• това е официалният канал на мрежата
• канала си има собствени правила
• канала може да бъде регистриран единствено от човек от екипа на мрежата
• при нужда, канала може да бъде временно модериран от администратор

– #IRCHelp

• за него важат всички правила за обикновените канали в мрежата, с долуизброените изключения
• това е официалният канал за помощ в мрежата
• в случай, че канала остане opless или при очевидно некоректно управление на канала, екипа на мрежата може да избере ново лице, което да се заеме с него

Обикновени канали са всички, с изключение на гореизброените:

– право да ги регистрира, има всеки потребител с регистриран и активен псевдоним, който е влязъл в канала и в момента на регистрацията е придобил chanop(@) статус без намесата на човек от екипа на мрежата
– никой от екипа на мрежата няма право да помага на даден потребител да регистрира свободен канал, в който той няма chanop(@)
– никой от екипа на мрежата няма право да се намесва в политиката на канала, освен при следните условия:

• канал, който се пълни чрез вируси, програми принудително вкарващи потребители в канала и drones, може да бъде временно модериран или (перманентно) затворен
• при сериозен flood или масов спам в канала – човек от екипа на мрежата може да модерира канала, до отстраняване на проблема
• при реклама за друга мрежа в topic-а на канала – човек от екипа на мрежата има право да го смени и да предупреди евентуалните собственици на канала да не го правят повече; ако провинението не е еднократно, канала може и да бъде (перманентно) затворен
• канал, който служи за нелегални цели може да бъде (перманентно) затворен

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

Канала се управлява от екипа на мрежата и е позволено(но не препоръчително) използването на операторски привилегии в services(OS) при нужда
– не са позволени псувни и всякакви обидни квалификации към лица от екипа на мрежата и/или към други потребители на канала
– не са позволени безпричинни банове и кикове на хора в канала(не важи за лица, които са създавали проблеми в миналото, a.k.a. abusers)
– спама и рекламата под каквато и да е форма са строго забранени.

Всеки потребител е свободен да регистрира псевдоними и канали по свое усмотрение, при следните условия:

– регистрациите да не се правят само с цел “колекционерство”, т.е. не е редно един човек да регистрира голям брой псевдоними и канали, които реално не използва (да … всеки може да си харесва по няколко ника, но не е редно един човек да има десетки регистрации, които не се използват, а биха могли да бъдат – от други потребители)

• Aко общият брой регистрации на псевдоними и/или канали, направени от даден потребител (бива разпознат по e-mail адрес и/или hostmask(s)) вече е надвишава 40, то те могат да бъдат изтрити от базата данни без предупреждениеПотребителят също трябва да бъде уведомен по e-mail за извършеното действие.границата от 40 регистрации е относителна, а не твърда бройка … т.е. потребители които правят по 35-36 регистрации, само за да минат между капките също могат да бъдат “наказани” – съвсем ясно си личи, когато даден псевдоним/канал се използва активно и кога регистрацията му е фиктивна

– регистрираните псевдоними не трябва да наподобяват целенасочено такива на съществуващи услуги(services) в мрежата и/или хора от екипа на мрежата, както и не трябва да бъдат регистрирани с явната цел да се използва за да нагруби някого – такива псевдоними могат да бъдат забранени чрез suspend и/или resv

• не е редно някой да се представя за NS/NickServ(примерно) или за даден човек от екипа на мрежата – това е потенциална заплаха за сигурността на мрежата и няма да бъде толерирано по никакъв начин
• псевдоними от сорта на <nick>LapaPishki и eba`<nick> не са съобразени с никакъв етикет, могат да създават единствено напрежение и да стават поводи за много неприятни ситуации; поради тази причина са недопустими

– канали с име на сървър от мрежата, такива представящи се за официални канали на мрежата или пък представящи се за официални на дадена организация, без да са оторизирани като такива могат да бъдат забранени чрез suspend и/или resv

• не е нито редно, нито етично някой да регистрира канал #irc.server.tld, #unibg и/или #<име_на_интернет_доставчик> и да се възползва от името на канала, за да може по изкуствен/измамен начин да привлече потребителиТова не означава, че не може да има “фен” канали или такива за ентусиасти около даден проект/организация – просто не трябва да бъдат представяни като официално обвързани с въпросната структура.

На кратко, принципа от който се ръководим е равнопоставеност на всички допринасящи за развитието на мрежата и гарантиране правото им на глас. FreeUniBG IRC Network си запазва правото на промени в правилата, не защото така ни харесва или изнася, а защото може да сме пропуснали нещо.

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

Модеве за сървър:
+а – admin – вижда кой е админ
+b – bots – Вижда съобщенията за flood-а от ботове и дронове
+c – cconn – Вижда кой клиент се свързва и кой клиент излиза от сървъра
+d – debug – Вижда съобщенията за debug
+f – full – Вижда когато I: линия се запълни
+i – invisible – Не се показвате, когато се изпълни командата NAMES или WHO, освен ако този, който изпълнява командата не е в един канал с вас
+k – skill – Вижда KILL съобщенията, които сървъра праща
+l – locops – Специален флаг, само за IRC Оператори, който им дава неуписуемо големи права /* псевдонима трябва да е IRC Оператор и да има +N в своята o: линия */
+n – nchange – Вижда когато някой си смени псевдонима /* псевдонима трябва да е IRC Оператор и да има +N в своята o: линия */
+o/O – oper – Операторски статус /* трябва да имате o/O: линия ; o е за локални оператори, а O за глобални*/
+r – rej – Вижда на кои клиенти им е отказано достъп до сървъра
+s – servnotice – Вижда главните съобщения от сървъра / сплитове/splits
+w – wallop – Вижда WALLOPS, които сървъра праща
+x – external – Вижда, когато някой отдалечен сървър се опита да се свърже към сървъра и сплит съобщенията
+y – spy – Вижда, когато се поиска LINKS, STATS (ако е конфигурирано така), TRACE както и кой те whois
+z – operwall – Вижда операторския WALLOPS
———————————————————-
Модеве за канал:
+n – Без външни съобщения. Само юзерите в канала могат да пишат.
+t – Само +о или @ могат да сменят топика в канала.
+s – Дадения канал не илиза при команди /whois и /list
+p – Канала става Private.
+m – Само потребител с voice/+ или оп/@ може да пише в канала.
+i – Само този който бъде поканен само той може да влезе в канала.
+c – Без цветови съобщения.
+H – Без спам в канала не може да се използва www/http
+N – Не може да се прави /notice
+A – Само оператори може да влизат в канала.
———————————————————-
Част от операторските команди:
SQUIT – SQUIT <server> [reason]
Разкача сървърът от вашата страна от мрежата с някаква причина
KILL – KILL <nick> <reason>
Разкача потребител от сървърът към който е бил свързан поради някаква причина.
Локалните оператори могат да използват командата KILL само за потребители на техният сървър.Глобалните
оператори могат да я използват в/у всеки потребител на мрежата.
STATS – STATS <letter> [server|nick]
Ако не е зададен сървър ще се обърне към вашият сървър.
CONNECT – CONNECT <server_A> [port] [server_B]
Когато се използва [server_B], CONNECT кара [server_B] да се свърже с <server_A>.Само глобални оператори
могат да използват командата в този си вид
Когато не е използван [server_B], CONNECT кара сървърът ви да се свърже с <server_A>.Може да се използва от
локални и глобални оператори.
Когато използвате порт, връзката ще се осъществи на зададеният порт, ако не сте използвали порт по
подразбиране ще се осъществи на 6667.
WALLOPS – WALLOPS :<message>
Изпраща WALLOPS съобщение на всички оператори които имат +zw мод
OPERWALL – OPERWALL :<message>
Изпраща OPERWALL съобщение на всички оператори които имат +zw мод
LOCOPS – LOCOPS :<message>
Изпраща съобщение на всички локални оператори на сървърът които имат +zw мод
TRACE – TRACE [server|nick]
TRACE показва информация на клиента за [server|nick] или за сървърът на който сте ако не сте задали
[server|nick]
Всички потребители които използват TRACE могат да видят пътят до [server|nick] ако е зададен и всички
сървъри и оператори свързани към него, както и класът на връзка в които попадат.
Операторите могат да виждат всички потребители които са се свързали към сървърът с TRACE както и класът на
връзка който използват
LTRACE – LTRACE [server|nick]
Показва само информация за Oper, Serv, Link, и Class.Полезно ако искате да видите само перманентната
информация за сървърът.Сървър който има тази опция премахва ‘STATS p’ тъй като имат една и съща функция.
REHASH – REHASH [option]
Когато не е зададена никаква опция REHASH ще презареди конфигурационият файл наново.
/rehash DNS – Ще презареди /etc/resolve.conf
/rehash MOTD – Презареждане на файлът съдържащ новините на деня.
/rehash OMOTD – Презареждане на операторските новини за деня.
/rehash HELP – Презареждане на помощните файлове.
/rehash TRESVS – Изчистване на временно запазените никове и канали.
/rehash TDLINES – Изчистване на временните локални банове.
/rehash TKLINES – Изчистване на временните локални банове/kline.
/rehash TXLINES – Изчистване на временните X линии
/rehash GLINES – Изчистване на активните глобални банове.
/rehash PGLINES – Изчистване на заявените, но не активни глобални банове.
/rehash REJECTCACHE – Изчиства отхвърления кеш.
RESTART – RESTART
Рестартира сървърът.
CLOSE – CLOSE
Затваря връзката на всеки клиент който не се е регистриъл напълно
DIE – DIE server.name [reason]
Спира сървърът с зададена причина.
HASH – HASH
Показва статистика за internal hashes на сървърът
DNS – DNS
Показва статистика за asynchronous resolving code на сървърът
KLINE – KLINE <nick|user@host> :[reason]
Добавя KLINE в kline.conf-а който ще банне даденият потребител от сървърът.Потребителят ще получи
събщение че той/тя е банната от съръвър.
KLINE [email protected] :[reason]
Ще KLINE потребител от даденият адрес
ip.ip.ip.ip може да бъде в CIDR форма, тоест 192.168.0.0/24
или 192.168.0.*
За временен KLINE времетраенето се дава в минути като първи параметър:
KLINE 10 <nick|user@host> :cool off for 10 minutes
Ако в причината за банването на потребителят има | вичко преди нея ще се види от потребителя като причина
при слагането на банът.
UNKLINE – UNKLINE <user@host>
Ще направи опит да махне KLINE на даденият <user@host>
———————————————————-
Статистики по сървъра:
/stats k – показва перманентните klines
/stats c – показва описаните сървъри
/stats l – показва реалните хостове или IP-та ( 255.255.255.255 ) означава, че има spoof
/stats u – показва uptime-a на сървъра ( от кога е онлайн/пуснат ) и колко юзера е имало най-много както и конекции
/stats O – показва описаните операторски линии
/stats m – показва заредените модули
/stats h – показва описанте хъбове/hubs
/stats f – показва никовете на юзерите
Команнди към IRCD:
/admin – показва реалния админ на сървъра /admin irc.spnet.bg – показва реалния админ на избрания от ваш сървър
/motd – показва motd на сървъра /motd irc.spnet.bg – показва motd на избрания от ваш сървър
/version – показва текущата версия на ircd-to
/time – показва текущото време
/lusers – показва глобална статистика
/map – показва сървърите в мрежата
/links – същото като /map само че по-грозно!
———————————————————-

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. На FreeUniBG 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 и свързаните с него файлове (за ratbox)
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 protected]>
Това е административна информация за дадения сървър, която се получава с команда /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. Заключителни бележки
Не трябва да се забравя, че на дадена мрежа има правила, които са задължителни за спазване. Особено не бива да се забравя, че операторите на даден сървър трябва да следват особено стриктно правилата и да не използват специалните си привилегии за излизане от спор, налагане на собственото си мнение, или упражняване на безсмислена власт. Една мрежа се прави от потребителите, а не от администратора и операторите на сървърите. Да притежаваш операторски статус е отговорност, която трябва да се поема сериозно. Операторът е длъжен доколкото разполага с време и възможност да помага на потребителите на мрежата.