Мы — долго запрягаем, быстро ездим, и сильно тормозим.

RFC
  RFC1180 (TCP/IP)
  RFC791 (IP)
  RFC792 (ICMP)
  RFC793 (TCP)
  RFC768 (UDP)
  RFC1459 (IRC)
  RFC1521 (MIME)
  RFC1951 (DEFLATE)
  RFC2839 (IKS)
Программирование
FreeBSD
man
EXIM


www.lissyara.su —> документация —> RFC —> RFC1459 (IRC)

RFC1459 - Internet Relay Chat Protocol - RFC 1459


Network Working Group                                      J. Oikarinen
Request for Comments: 1459                                      D. Reed
                                                              May 1993

перевод: vadim s. sabinich http://sabinich-translate.blogspot.com

                     Internet Relay Chat Protocol

Статус документа

  Данный документ описывает Экспериментальный Протокол для Интернет
  обьединения. Обсуждения и предложения для улучшения приветствуются.
  Пожалуйста, изучите текущую редакцию "Официальные Стандарты протокола
  IAB". Распространение документа не ограничено.

Резюме

  IRC-протокол был разработан 4 года назад (в 1989 году, относительно
  года издания этого документа. — прим. пер.) для того, чтобы
  пользователи BBS могли общаться между собой. Сейчас этот протокол
  поддерживается web-серверами и клиентами, и на этом он завершает свое
  развитие. Последние 2 года среднее количество пользовательских
  соединений к IRC-сети возросло в 10 раз.

  IRC-протокол работает с текстом, и поэтому даже самый простой клиент,
  оснащенный сокет-программой, может соединиться с сервером.

Содержание

  1.  ВСТУПЛЕНИЕ .................................................    4
     1.1  Серверы ................................................    4
     1.2  Клиенты ................................................    5
        1.2.1 Операторы ..........................................    5
     1.3 Каналы ..................................................    5
     1.3.1  Операторы Каналов ....................................    6
  2. СПЕЦИФИКАЦИЯ IRC ............................................    7
     2.1 Ознакомление ............................................    7
     2.2 Коды символов ...........................................    7
     2.3 Сообщения ...............................................    7
        2.3.1  Формат сообщения в 'псевдо' BNF ...................    8
     2.4 Нумерация ответов .......................................   10
  3. КОНЦЕПЦИЯ IRC ...............................................   10
     3.1 Соединение один-на-один .................................   10
     3.2 Один-со-всеми ...........................................   11
        3.2.1 Со списком .........................................   11
        3.2.2 С группой (каналом) ................................   11
        3.2.3 С маской хоста/сервера .............................   12
     3.3 Один-всем ...............................................   12
        3.3.1 Клиент-Клиенту .....................................   12
        3.3.2 Клиент-Серверу .....................................   12
        3.3.3 Сервер-Серверу .....................................   12
  4. ДЕТАЛЬНОЕ РАССМОТРЕНИЕ СООБЩЕНИЙ ............................   13
     4.1 Регистрация Соединения ..................................   13
        4.1.1 Password ...........................................   14
        4.1.2 Nickname ...........................................   14
        4.1.3 User ...............................................   15
        4.1.4 Server .............................................   16
        4.1.5 Oper ...............................................   17
        4.1.6 Quit ...............................................   17
        4.1.7 Server Quit ........................................   18
     4.2 Операторы Каналов .......................................   19
        4.2.1 Join-сообщение .....................................   19
        4.2.2 Part-сообщение .....................................   20
        4.2.3 Mode-команда .......................................   21
           4.2.3.1 Режимы канала .................................   21
           4.2.3.2 Режимы пользователя ...........................   22
        4.2.4 Topic-сообщение ....................................   23
        4.2.5 Names-сообщение ....................................   24
        4.2.6 List-сообщение .....................................   24
        4.2.7 Invite-сообщение ...................................   25
        4.2.8 Kick-сообщение .....................................   25
     4.3 Серверные запросы и комманды ............................   26
        4.3.1 Version-сообщение ..................................   26
        4.3.2 Stats-сообщение ....................................   27
        4.3.3 Links-сообщения ....................................   28
        4.3.4 Time-сообщение .....................................   29
        4.3.5 Connect-сообщение ..................................   29
        4.3.6 Trace-сообщение ....................................   30
        4.3.7 Admin-команда ......................................   31
        4.3.8 Info-команда .......................................   31
     4.4 Сообщения отправки ......................................   32
        4.4.1 Private-сообщения ..................................   32
        4.4.2 Notice-сообщения ...................................   33
     4.5 Пользовательские запросы ................................   33
        4.5.1 Who-запрос .........................................   33
        4.5.2 Whois-запрос .......................................   34
        4.5.3 Whowas-сообщение ...................................   35
     4.6 Всевозможные сообщения ..................................   35
        4.6.1 Kill-сообщение .....................................   36
        4.6.2 Ping-сообщение......................................   37
        4.6.3 Pong-сообщение .....................................   37
        4.6.4 Error-сообщение ....................................   38
  5. ОПЦИОНАЛЬНЫЕ СООБЩЕНИЯ ......................................   38
     5.1 Away-сообщение ..........................................   38
     5.2 Rehash-команда  .........................................   39
     5.3 Restart-команда .........................................   39
     5.4 Summon-сообщение.........................................   40
     5.5 Users-сообщение .........................................   40
     5.6 Operwall-команда ........................................   41
     5.7 Userhost-сообщение.......................................   42
     5.8 Ison-сообщение ..........................................   42
  6. ОТВЕТЫ ......................................................   43
     6.1 Error-ответы ............................................   43
     6.2 Отклики команд ..........................................   48
     6.3 Зарезервированные числа .................................   56
  7. ИДЕНТИФИКАЦИЯ КЛИЕНТА И СЕРВЕРА .............................   56
  8. ПОДРОБНОЕ РАССМОТРЕНИЕ ТЕКУЩИХ СРЕДСТВ СВЯЗИ ................   56
     8.1 Сетевой протокол TCP ....................................   57
        8.1.1 Поддержка Unix-сокетов .............................   57
     8.2 Проверка команд .........................................   57
     8.3 Передача сообщений ......................................   57
     8.4 Соединение 'Liveness' ...................................   58
     8.5 Установка соединения сервер-клиент ......................   58
     8.6 Установка соединения сервер-сервер ......................   58
        8.6.1 Обмен информацией о состоянии соединения ...........   59
     8.7 Разрыв соединения сервер-клиент .........................   59
     8.8 Разрыв соединения сервер-сервер .........................   59
     8.9 Слежение за измененияит никнейма ........................   60
     8.10 Flood-контроль клиентов ................................   60
     8.11 Non-blocking lookups ...................................   61
        8.11.1 Hostname (DNS) lookups ............................   61
        8.11.2 Username (Ident) lookups ..........................   61
     8.12 Конфигурационный файл ..................................   61
        8.12.1 Допуск клиентов к соединению ......................   62
        8.12.2 Операторы .........................................   62
        8.12.3 Допуск серверов к соединению ......................   62
        8.12.4 Административная часть ............................   63
     8.13 Формирование сообществ .................................   63
  9. ТЕКУЩИЕ ПРОБЛЕМЫ ............................................   63
     9.1 Расширение ..............................................   63
     9.2 Знаки ...................................................   63
        9.2.1 Никнеймы ...........................................   63
        9.2.2 Каналы .............................................   64
        9.2.3 Серверы ............................................   64
     9.3 Алгоритмы ...............................................   64
  10. ПОДДЕРЖКА И ДОСТУП .........................................   64
  11. РАССМОТРЕНИЕ БЕЗОПАСНОСТИ ..................................   65
  12. АДРЕСА АВТОРОВ .............................................   65


1.  ВСТУПЛЕНИЕ

  IRC ("Internet Relay Chat" можно перевести как "Общение передающееся
  посредством Интернета". Если не забыли, что первоначально этот протокол
  связывал пользователей BBS — прим. пер.) протокол был разработан
  несколько лет назад для общения посредством текста (чат). Этот документ
  описывает текущее (на 1993 год — прим. пер.) состояние IRC-протокола.

  IRC-протокол разработан для систем, использующих сетевой протокол
  TCP/IP, хотя это не требование, чтобы этот пережиток работал только в
  этой сфере.

  IRC представляет собой систему телеконференций, которые (через
  использование модели клиент-сервер) хорошо подходят для работы на
  многих машинах в распространяемой зоне. Типичная настройка представляет
  собой процесс (сервер), предоставляющий доступ для клиентов (или других
  серверов), и выполняющий доставку/мультиплексирование сообщений и
  других функций.

1.1 Серверы

  Сервер формирует бэкбон IRC, предоставляющий точки присоединения
  клиентов для общения и присоединения других серверов для формирования
  IRC-сети. Серверы, доступные в сети формируют IRC-сеть, образуя сетевое
  дерево (см. рис. 1), в котором каждый сервер является самостоятельным, но
  тем не менее взаимодействующим с остальными серверами. (Подобная форма
  сети предполагает наибольшую сохранность сети, даже при падении одного
  или нескольких серверов. — прим. пер.).


 [ Сервер 15 ] [ Сервер 13 ] [ Сервер 14]
 / \ /
 / \ /
 [ Сервер 11 ] ------ [ Сервер 1 ] [ Сервер 12]
 / \ /
 / \ /
 [ Сервер 2 ] [ Сервер 3 ]
 / \ \
 / \ \
 [ Сервер 4 ] [ Сервер 5 ] [ Сервер 6 ]
 / | \ /
 / | \ /
 / | \____ /
 / | \ /
 [ Сервер 7 ] [ Сервер 8 ] [ Сервер 9 ] [ Сервер 10 ]
 :
 [ etc. ]
 :



                [ Рис. 1. Схематичное изображение IRC-сети ]

1.2 Клиенты

  Клиент это любое присоединение к серверу, и который не является
  сервером. Каждый клиент отличается от других клиентов наличием
  уникального (не похожего ни на чей другой. — прим. пер.) никнейма,
  имеющего длину не больше девяти (9) символов. Посмотрите правила
  протокольной грамматики для того, чтобы знать что можно и что нельзя
  использовать в никнейме. В дополнение к никнейму, все серверы должны
  иметь следующую информацию о всех клиентах: настоящее имя хоста, с
  которого запустился клиент, имя пользователя клиента на этом хосте и
  сервер, к которому присоединился клиент.

1.2.1 Операторы

  Для поддержания порядка в IRC-сети, существует специальный класс
  клиентов (операторы. В данный момент их называют "иркопы" — прим.
  пер.). Хотя, возможности операторов можно рассматривать как 'опасные',
  они не подчиняются приказам. Операторы выполняют основные сетевые
  задачи, такие как отсоединение и пересоединение серверов для улучшения
  состояния сети или исправления каких-либо сетевых ошибок. Смотрите разделы
  4.1.7 (SQUIT) и 4.3.5 (CONNECT).

  В дополнение к возможностям операторов можно добавить, что в их силах
  так же закрыть соединение между клиентов и сервером. Правда, подобное
  бывает только при диструктивных и раздражающих действиях клиента.
  Подробней об этом действии сказано в разделе 4.6.1 (KILL).

1.3 Каналы

  Канал это обозначение группы из одного или большего числа клиентов,
  которые получают сообщения, адресованные в этот канал. Канал создается
  при соединении первого клиента с ним и канал исчезает, когда его
  покидает последний клиент. Пока канал отсутствует, любой клиент может
  завладеть каналом, назвав свой таким же именем.

  Имена каналов - строка (начинающаяся с символа '&' или '#') длинной до
  200 символов. В стороне от требований, что первый символ должен быть
  или '&' или '#'; органичение на то, что название канала не может
  содержать пробелов (' '), Ctrl-G (^G или ASCII 7), или запятых (','
  которая используется для создания списка каналов).
 
  Протоколом предоставляется два типа каналов, Один распространяемый
  канал, который известен всем серверам, подсоединенным к сети.

  Эти каналы помечены первым символом; доступны только тем клиентам, на
  сервере которых он существует. Такие каналы отличаются начальным
  символом '&'. этих двух типов, доступны различные режимы каналов
  для изменения индивидуальных характеристик канала.
  Смотрите раздел 4.2.3 (MODE-команда) для более подробной информации.

  Для создания нового канала или входа в существующий, пользователь
  должен запросить JOIN канала. Если канал отсутствовал, то канал
  создается и вошедший пользователь станоавится оператором канала. Если
  канал уже существует, но так или иначе он не отвечает на попытки войти,
  значит в настройках канала установлен какой-либо из нижеприведенных
  режимов. Возможно, этот канал только-для-приглашенных (invite-only),
  (режим +i), и вы сможете на его войти только будучи приглашенным.
  Пользователь может находится не нескольких каналах одновременно, но
  рекомендуется ограничиться десятью (10) каналами, ибо это полне
  достаточно для новичков и набирания опыта. Для более подробной
  информации обо всем этом смотрите раздел 8.13.

  Если в IRC-сети происходит разрыв, вызванный разъединением двух
  серверов, канал так же разрывается на несколько частей, в которых
  остаются пользователи, сидящие на своих серверах. Когда серверы
  соединяются вновь, они восстанавливают части канала и его режимы. Если
  канал доступен по разные стороны, вхождения и режимы канала
  интерпретируются в своих манерах.

1.3.1 Операторы каналов

  Оператор канала (так же называемые "чоп" [сокращение и
  транскрибирование словосочетания "чаннел оператор", но их принято
  называть просто "оп". — прим. пер.]) на данном канале рассматривается
  как владелец канала. В добавление к этому статусу, оператор канала
  выполняет функции стража порядка на канале. Как владелец канала,
  оператор не осуждается за действия на своей территории, хотя если его
  действия несут антисоциальные или какие другие оскорбительные действия,
  то будет благоразумней обратиться к IRC-оператору за поддержкой, или
  даже смещения с поста оператора канала.

  Список команд, которые могут использоваться только оператором канала:

       KICK    - Выброс клиента с канала
       MODE    - Изменение режима канала
       INVITE  - Приглашение клиента на канал с режимом +i (invite-only)
       TOPIC   - Изменение топика канала в режиме канала - +t

  Оператор канала идентифицируется символом '@', следующим за его
  никнеймом, всякий раз, как он ассоциируется с каналом (например, ответы
  на команды NAMES, WHO и WHOIS).

2. СПЕЦИФИКАЦИЯ IRC

2.1 Ознакомление

  Протокол, как описывалось выше, используется для соединений между
  серверами и, серверами и клиентами. Ограничение стоит больше на
  клиентские соединения (которые рассматриваются как не стоящие доверия)
  чем на серверные.
 
2.2 Коды символов

  Используются обычные символы. Протокол базируется на установке кодов,
  которые составляют восемь (8) бит, составляя октет. Каждое сообщение
  может содержать любое количество октетов: к тому же, некоторые
  восьмизначные величины использутся для контрольных кодов, которые
  распознаются как неограниченые сообщения.

  Не обращая внимания на 8-битный протокол, неограниченность и
  переменные этого протокола наиболее используемые терминалом USASCII
  и телнет-соединением.

  Так как IRC имеет скандинавские корни, символы {}| рассматриваются как
  эквивалент символов []\, но в малом регистре. Это приводит к критическим
  результатам, когда определяется уникальность двух никнеймов.

2.3 Сообщения

  Серверы и клиенты создают сообщения на которые можно ответить, а можно
  и нет. Если сообщение содержит правильные команды, как описано в
  предыдущем разделе, клиенту следует ответить как полагается, но это не
  означает, что всегда можно дождаться ответа; связь клиент-сервер и
  сервер-сервер очень рассинхронизированы по своей природе.

  Каждое IRC-сообщение может содержать до трех главных частей: префикс
  (опционально), команду и параметры команды (которых может быть до 15).
  Префикс, команда и все параметры разделены одним (или более) символом
  пробела (' ', 0x20).

  Префикс обозначается одним символом, стоящим вначале (':', 0x3b),
  который должен быть первым символом в сообщении. Между префиксом и
  двоеточием не должно быть никаких пробелов. Префикс используется
  серверами для обозначения источника появления сообщения.

  Если префикс сообщения утерян, то за источник сообщения берут
  соединение, с которого было получено сообщение. Клиентам не следует
  использоваться префиксами при отсылке сообщения; если они начнут
  использовать префиксы, то приниматься будут только правильные и только
  с зарегистрированных никнеймов. Если исходные идентификаторы префиксов
  не будет найдены в серверных базах данных, или если они зарегистрированы
  с различных линков, то сервер будет игнорировать сообщение.

  Команда должна содержать правильную IRC-команду или трехзначное число,
  представленное в ASCII-тексте.

  IRC-сообщения всегда выглядят как строки символов, заканчивающихся
  парой символов CR-LF (Carriage Return - Line Feed. Возврат Каретки -
  Перевод Строки) и длиной строки, не превышающей 512 символов (в эти
  512 входят и CR-LF). Так что, максимальная длина строки для команд и
  параметров - 510 символов. Перенос строки невозможен. Для более подробной
  информации смотрите раздел 7.

2.3.1 Формат сообщения в 'псевдо' BNF

  Протокол сообщений должен быть извлечен из смежных потоков октетов
  Текущим решением стало определение двух символов, CR и LS, как
  разделители сообщений. Игнорирование пустых сообщений, которые
  используют последовательности CR-LF между сообщениями без каких-либо
  проблем.

  Распакованное сообщение проверяется внутри компонентов <prefix>,
  <command> и список параметров подравнивается с помощью <middle> или
  <trailing> компонентами

  BNF представляет собой нечто подобное:

 ::= [':'   ]   
 ::=  |  [ '!'  ] [ '@'  ]
 ::=  {  } |   
 ::= ' ' { ' ' }
 ::=  [ ':'  |   ]
 ::= <Любая *не пустая* последовательность октетов, не 
 включающая в себя пробел, или NUL, или CR, или LF;
 первой не может быть ':'>
 ::= <Любая, возможно *пустая*, последовательность октетов, не 
 включающих в себя NUL или CR, или LF>
 ::= CR LF



ЗАМЕЧАНИЯ:

 1)    <SPACE> содержит только символ(ы) пробела (0x20). Табуляция и
       другие контрольные символы рассматриваются как НЕ-ПУСТЫЕ-ПРОБЕЛЫ
       (NON-WHITE-SPACE).

 2)    После извлечения списка параметров, все параметры равняются
       с помощью <middle> или <trailing>. <trailing> просто
       синтаксическая штуковина, включающая SPACE внутри параметра.

 3)    Факт, что CR и LF нельзя добавить в строки параметров, просто
       артефакт оформления сообщения. Его можно изменить позже.

 4)    NUL не является специальным символом в оформлении сообщения и
       в основе служит окончанием внутри параметра, но это является
       причиной усложнения в нормальной C-строке. Так же, NUL не
       позволителен внутри сообщений.

 5)    Последний параметр может быть пустой строкой.

 6)    Использование расширенного префикса (['!' <user> ] ['@' <host> ])
       может быть в связи сервера с сервером и предполагается
   только для сообщений между сервером и клиентом, предоставляя
   клиентам больше полезной информации о пользователях без
   использования дополнительных запросов.

  Многопротокольные сообщения указывают на дополнительную семантику и
  синтаксис для параметров извлечения строк, указанием их позицией в
  списке. Например, многие команды серверов будут предполагать, что первый
  параметр после команды - список заданий, которые описаны таким образом:

  ::=  [ ","  ]
  ::=  |  '@'  |  | 
  ::= ('#' | '&') 
  ::= 
  ::= смотри RFC 952 [DNS:4] для информации о именах хостов
  ::=  {  |  |  }
  ::= ('#' | '$') 
  ::= <любой 8-битный код, включающий в себя SPACE, BELL, 
 NUL, CR, LF и запятую (',')>
 Другие параметры синтаксиса:
  ::=  {  }
  ::= 'a' ... 'z' | 'A' ... 'Z'
  ::= '0' ... '9'
  ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}'
  ::= <любой 8-битный код, включающий SPACE, (0x20), 
 NUL (0x0), CR(0xd), и LF (0xa)>


2.4 Нумерация ответов

  Многие сообщения, отправленные к серверу, создают отсортированные
  ответы. Многие полученные ответы являются пронумерованными, что
  используется как для отлова ошибок, так и нормальных ответов.
  Пронумерованный ответ может быть послан как одно сообщение, содержащее
  префикс отправителя, трехзначный номер и цель ответа. Нумерация ответов
  не допускает сообщения от клиента-отправителя; любые такие сообщения,
  полученные сервером, удаляются. Во всех других случаях, нумерованный
  ответ просто обычное сообщение, которое содержит переменную. Переменная
  имеет вид трехзначного номера, что неизменно лучше, чем строка символов.
  Список различных ответов находится в разделе 6.

3. КОНЦЕПЦИЯ IRC

  Этот раздел призван описать нынешнюю концепцию организации протокола
  IRC и представление о различных классах сообщений.

 1--\
 A D---4
 2--/ \ /
 B----C
 / \
 3 E
 Серверы: A, B, C, D, E Клиенты: 1, 2, 3, 4


                   [ Рис. 2. Пример небольшой IRC-сети ]

3.1 Соединение один-на-один

  Соединение один-на-один обычно осуществляется клиентами, но с тех пор
  как траффик между серверами стал не так важен, данный вид соединения
  упразднили. Предоставление возможности безопасного общения для клиентов,
  предполагает собой, что все серверы должны предоставить возможность
  прохождение сообщения по всей длине дерева до любого клиента. Сообщение
  должно найти наиболее короткий путь между двумя точками в серверном
  дереве.

  Следующие примеры относятся к рис. 2.

Пример 1:
    Сообщение между клиентами 1 и 2 должно пройти только через сервер A,
    который отправит его прямо к клиенту 2.

Пример 2:
    Сообщение между клиентами 1 и 3 должно пройти через серверы A и B.
    Остальным клиентам и серверам увидеть сообщение не суждено.

Пример 3:
    Сообщение между клиентами 2 и 4 пройдет по серверам A, B, С и D.

3.2 Один-со-всеми

  Основная цель IRC - предоставить форум, который позволит легко и
  эффективно устраивать конференции (одному с многими собеседниками).
  И IRC как нельзя лучше справляется с этой обязанностью.

3.2.1 Со списком

  Самый большое неудобство в общении один-со-всеми - разговор с помощью
  клиентов со "списком" пользователей. Как это происходит: клиенты
  предоставляют список получателей, которым адресовано сообщение и сервер
  копирует сообщение всем указанным получателям. Это не так эффективно,
  как использование группы, при нарушении списка получателей и отправке
  сообщений без проверки может породить дубликаты сообщений.

3.2.2 С группой (каналом)

  В IRC-канале имеется фунцкия, эквивалентная многосоставной группе; их
  жизнь динамична (люди входят и покидают каналы) и текущая беседа
  выходит на канал и отсылается серверам, которые поддерживают
  пользователей на данном канале. Если на сервере несколько
  пользователей, сидящих на одном канале, текст сообщения отсылается
  только серверу, который в свою очередь отсылает каждому клиенту на
  канале. Это действие повторяется для каждого соединения клиент-сервер,
  пока исходное сообщение не дойдет до каждого пользователя на канале.

  Следующие примеры относятся к рис. 2.

Пример 4:
    Любой канал с одним клиентом(клиент 1). Сообщения в канал уходят на
    сервер и потом кому-нибудь еще.

Пример 5:
    На канале клиент 1 и клиент 2. Все сообщения проходят путь, как если
    бы они были приватными сообщениями между двумя клиентами вне канала.

Пример 6:
    На канале клиенты 1, 2 и 3. Все сообщения канала отправляются всем
    клиентам и только их сервера, которые обязаны пропустить сообщение,
    как если бы оно было приватное и для одного клиента. Если клиент 1
    отправил сообщение, оно повернет обратно на клиента 2 и только тогда
    через сервер B к клиенту 3.

3.2.3 С маской хоста/сервера

  Предоставляя IRC-операторам возможность отправки сообщений большому
  числу общающихся пользователей, используются маски отправки сообщений
  по хосту или серверу. Эти сообщения отправляются пользователям,
  чья информация о хоста или сервера попала под маску. Сообщения
  отсылаются только туда,  где расположены пользователи, в виду похожести
  каналов.

3.3 Один-всем

  Тип сообщения один-всем лучше описать как обьявление,
  отправляемое всем клиентам или серверам, или тем и другим вместе. В
  больших сетях одно сообщение может повлечь большое количество траффика
  для того, чтобы попасть ко всем желающим.

  Для многих сообщений, которые не имеют выбора, но извещение ими всех
  серверов эта форма посылки информации каждым сервером - разумная
  последовательность между серверами.

3.3.1 Клиент-Клиенту

  Класса подобных сообщений нет, который позволяет отсылать сообщение
  от пользователя, к каждому другому клиенту.

3.3.2 Клиент-Серверу

  Многие команды, которые в результате изменения информации (такой как
  членство канала, режим канала, статус пользователя, etc), могут быть
  отправлены всем сервером по умолчанию, и их распространение не может
  быть изменено клиентом.

3.3.3 Сервер-Серверу

  Пока многие сообщения между серверами распространяются на все 'другие'
  серверы, требования для любого такого сообщения - влиять на каждого
  пользователя, канал или сервер. С тех пор, как эти начальные пункты
  находятся в IRC, почти все сообщения, отправленные с сервера, являются
  извещениями для всех остальных присоединенных серверов.

4. ДЕТАЛЬНОЕ РАССМОТРЕНИЕ СООБЩЕНИЙ

  На следующих страницах описывается каждое сообщение узнаваемое
  IRC-сервером и клиентом. Все команды, описанные в этом разделе должны
  быть обеспечены любым сервером для этого протокола.

  Когда приходит ответ ERR_NOSUCSERVER, это значит, что параметр <server>
  не найден. Сервер может не отсылать других ответов после этой команды.

  Сервер, к которому присоединился клиент требует к парсингу
  (проверка на синтаксис. — прим. пер.) полное сообщение, возвращая
  любые найденные ошибки. Если сервер встретит смертельную ошибку в процессе
  парсинга, ошика может быть возвращена обратно клиенту с остановкой
  процесса проверки. Эта ошибка может быть вызвана некорректной
  командой, направление которой неизвестно серверу (сервер, никнейм или
  название канала подходят под эту категорию), не достаточно параметров
  или неправильные привилегии.

  Если представлен полная список параметров, тогда каждый из них должен
  быть проверен на правильность и с присущим ответом вернуться клиенту.
  В этом случае сообщения, которые использовалист списками параметров,
  использующие запятую как разделитель пунктов, должны получить ответы
  для каждого такого пункта.

  В примерах ниже, многие сообщения, кажется, используют полный формат:

  :Name COMMAND список параметров

  Как .. примеров, сообщение от "Name" отправлена транзитом между
  серверами, где оно  вставит имя оригинального отправителя сообщения
  и удаленные серверы смогут отправить ответ по правильному пути.

4.1 Регистрация Соединения

  Команды, описываемые здесь, используется для регистрации соединения с
  IRC-серверов, как для пользователя или сервер, как лучше и как
  правильней рассоединяться.

  Команда "PASS" не требуется для регистрации каждого клиентского или
  серверного соединения, но она должна предшествовать сообщения сервера
  или быть после комбинации NICK/USER. Она очень рекомендуется, чтобы у
  всех серверных соединений был пароль, который дает некоторый уровень
  защиты в текущих соединениях. Рекомендуемые условия для регистрации
  клиента ниже:

          1. Pass-сообщение
          2. Nick-сообщение
          3. User-сообщение

4.1.1 Password-сообщение


    Команда: PASS
  Параметры: <password>

  Команда PASS используется для установки 'парольного соединения'. Пароль
  может и должен быть установлен перед любой попыткой регистрации
  установленного соединения. В текущий момент, это требования к клиентам
  отправлять команду PASS перед отправкой комбинации NICK/USER и серверы
  *должны* отправить команду PASS перед любой SERVER-командой. Пароль
  должен быть снабжен одним содержимым в C/N-строках (для серверов) или
  I-строках (для клиентов). Это возможно для отправки большого количества
  PASS-команд перед регистрированием, но только одно последнее
  используется для проверки и может не изменить уже зарегистрированое.
  Числовые ответы:

          ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED

  Пример:

          PASS secretpasswordhere

4.1.2 Nick-сообщение

    Команда: NICK
  Параметры: <nickname> [ <hopcount> ]

  NICK используется для установки пользовательского никнейма или
  изменения предыдущего. Параметр <hopcount> используется только
  серверами, показывая как далеко никнейм от своего "домашнего" сервера.
  При локальном соединении счетчик (hopcount) будет равен 0. Если этот
  параметр запросится клиентом, параметр будет игнорирован.

  Если NICK-сообщение придет от сервера, который уже знает об
  идентификации никнейма другим клиентов, никнейм ...
  Результатом этого ..., все примеры этого никнейма сотрутся из серверной
  базы данных и командой KILL удалит этот никнейм из базы данных остальных
  серверов. Если сообщение NICK станет причиной изменения никнейма, то
  оргинальный (старый) никнейм удалится.

  Если сервер получит идентичный NICK от клиента, который подсоединился
  напрямую, он может вывести ERR_NICKCOLLISION локальному клиенту,
  отменить команду NICK и не генерировать любых киллов.

  Числовые ответы:

          ERR_NONICKNAMEGIVEN             ERR_ERRONEUSNICKNAME
          ERR_NICKNAMEINUSE               ERR_NICKCOLLISION

  Пример:

  NICK Wiz                        ; Вступление нового никнейма "Wiz".

  :WiZ NICK Kilroy                ; WiZ изменяет свой никнейм на Kilroy.

4.1.3 User-сообщение

    Команда: USER
  Параметры: <username> <hostname> <servername> <realname>

  Сообщение USER используется вначале соединения для указания имени
  пользователя, названия хоста, названия сервера и реального имени нового
  пользователя. Так же оно используется в соединении между серверами для
  указания нового пользователя, попавшего на IRC, с того только после USER
  или NICK, полученными от клиента, пользователь будет зарегистрирован.

  Между серверами USER должен быть использован как префикс для
  клиентского NICKнейма. Замечено, что имя хоста и имя сервера обычно
  игнорируются IRC-сервером, когда приходит команда USER от клиента,
  присоединенного напрямую (по причине безопасности), но они
  использовались в соединении сервер-сервер. По этому NICK должен всегда
  посылаться удаленному серверу, когда новый юзер появляется в сети,
  перед посылкой USER.

  Должно быть обьявлено, что параметр realname должен быть последним,
  потому что он может содержать пробелы и перед ним должен быть префикс
  (':'), делающим распознавание более лучшим.

  С тех пор для клиентов стало обычным делом - сочинять свое имя
  исключительно с помощью USER, рекомендуется использовать "Сервер
  Идентификации" ("Identity Server")

  Числовые ответы:

          ERR_NEEDMOREPARAMS              ERR_ALREADYREGISTRED

  Примеры:


  USER guest tolmoon tolsun :Ronnie Reagan
                                  ; Пользователь зарегистрировал себя
                                  под именем "guest" и его реальное имя
                                  "Ronnie Reagan".


  :testnick USER guest tolmoon tolsun :Ronnie Reagan
                                  ; Сообщение между серверами с
                  никнеймом, установленным командой USER

4.1.4 Server-сообщение

    Команда: SERVER
  Параметры: <servername> <hopcount> <info>

  Эта команда используется для того, чтобы сервер мог понять, что на
  другом конце соединения тоже сервер. Так же используется для передачи
  данных сервера через всю сеть. Когда новый сервер присоединяется к
  сети, информация об этом расходится по всей сети. <hopcount>
  используется для передачи всем серверам информации о том, на каком
  расстоянии находятся друг от друга серверы. С полным списком серверов
  возможно создать карту серверного дерева, но маски хостов предотвратят
  подобное дело.

  Сообщение SERVER может быть подтверждено только (a) соединеним, которое
  еще будет зарегистрировано и зарегистрировано как сервер, или (b)
  соединение другого сервера, в этом случае сообщение SERVER является,
  как бы, приветствием нового сервера.

  Многие ошибки, случающиеся при получении команды SERVER, являются
  результатом разрыва соединения хостом-получателем (мишень SERVER).
  Ответы ошибок обычно посылаются, используя команду "ERROR", что
  несравненно лучше, чем числовые. Подобные ответы несут больше полезной
  информации.

  Если SERVER-сообщение проверено и пытается пробится к серверу, который
  уже знает запрашиваемый сервер, соединение, с которого идет это
  сообщение, может быть закрыто (следую корректным процедурам).

  Числовые ответы:

          ERR_ALREADYREGISTRED

  Пример:

SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server
                               ; Новый сервер test.oulu.fi представляет
                               себя и пытается зарегистрироваться.    
                               В [] имя хоста для хоста, запущенного
                               test.oulu.fi.


:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server
                               ; Сервер tolsun.oulu.fi является вашим
                               аплинком для csd.bu.edu, который
                               находится в 5 скачках от вас.

4.1.5 Oper

    Команда: OPER
  Параметры: <user> <password>

  Сообщение OPER используется нормальным пользователем для взятия
  операторских привилегий. Комбинация <user> и <password> используется
  для идентификации пользователя, запрашивающего права IRC-оператора.

  Если клиент послал команду OPER с корректным паролем для текущего
  пользователя, сервер информамирует сеть о новом операторе, используя
  "MODE +o" для никнейма клиента.

  Сообщение OPER только для клиент-сеовер.

  Числовые ответы:

          ERR_NEEDMOREPARAMS              RPL_YOUREOPER
          ERR_NOOPERHOST                  ERR_PASSWDMISMATCH

  Пример:

  OPER foo bar                    ; Попытка зарегистрироваться как
                                  оператору, используя имя пользователя
                  "foo" и пароль "bar".

4.1.6 Quit-сообщение

     Команда: QUIT
   Параметры: [<Quit message>]

  Сессия клиента заканчивается с QUIT-сообщением. Сервер должен закрыть
  соединение с клиентом, когда увидит посланное сообщение.

  При нетсплите (разрыве соединения между двумя серверами), сообщение
  QUIT содержит в себе имена двух серверов, разделенные пробелами.

  Первое имя это сервер, который соединяется, второе имя сервера, который
  отсоединился.

  Если, по какой-либо причине, соединение клиента закрылось без введения
  клиентом команды QUIT (например, обрыв связи), сервер потребует запаса
  в quit-сообщениях с некоторой сортировкой сообщения, в поисках причины
  разрыва.

  Числовые ответы:

          None.

  Пример:

  QUIT :Gone to have lunch        ; Обычный формат сообщения.

4.1.7 Server Quit-сообщение

    Команда: SQUIT
  Параметры: <server> <comment>

  Сообщение SQUIT требуется для указания мертвых или вышедших серверов.
  Если сервер желает оборвать соединение с другим сервером, он должен
  послать сообщение SQUIT другому серверу, используя имя другого сервера
  в качестве параметра server.

  Эта команда так же доступна IRC-операторам для помощи в сохранеии сети
  соединений IRC-серверов в порядке. IRC-операторы могут так же послать
  SQUIT для удаленных серверных соединений. В этом случае, SQUID будет
  парситься каждым сервером, находящимся между IRC-оператором и удаленным
  сервером.

  Параметр <comment> обеспечивается всеми операторами, которые запускают
  SQUIT для удаленных серверов (которые не присоединены к серверу,
  который хотят выключить), так что все операторы знают причины этого
  действия.

  Один из серверов, которые находятся на другой стороне соединения, будет
  закрыт по требованию, высланным сообщением SQUID (ко всем другим
  соединениям) дл остальных серверво, которые рассматриваются как линки.

  Подобным образом, SQUIT может быть послана другим серверам, находящимся
  в сети ради клиентов. В дополнение к этому, все члены канала, который
  разбило сплитом, может послать SQUIT-сообщение.

  Если соединение сервера закрыто преждевременно (т.е сервер на другом
  конце соединения разорвал линк), сервер, который засек этот разрыв
  соединения, информирует всю сеть о том, что соединение закрыто и
  показывает поле <comment>, обьясняя причину рассоединения.

  Числовые ответы:

          ERR_NOPRIVILEGES                ERR_NOSUCHSERVER

  Пример:

  SQUIT tolsun.oulu.fi :Bad Link ? ; серверный линк tolson.oulu.fi has
                                   будет закрыт, потому что "Bad Link".

  :Trillian SQUIT cm22.eng.umd.edu :Server out of control
                                   ; сообщение от Trillian, отсоединило
                                   cm22.eng.umd.edu от сети,    
                                   потому что "Server out of control".

4.2 Операторы каналов

  Этот раздел посвящен управлению каналами, их настройками (режимы
  каналов), и их содержимым (обычно - клиенты). Для обеспечения этого,
  число коренных обстоятельств неизбежен,  когда клиенты на разных концах
  сети начнут посылать команды, которые приведут в конечном счете к
  конфликту. Так же требует, что серверы хранят историю никнейма,
  обеспечивая ввод параметра <nick>, сервер проверяет его историю, в
  случае, если он был изменен.

4.2.1 Join-сообщение

    Команда: JOIN
  Параметры: <channel>{,<channel>} [<key>{,<key>}]

  Команда JOIN используется клиентом для входа на канал. Так или иначе,
  клиенту позволительно войти на канал, проверенным только сервером, к
  которому подсоединен; все остальные серверы автоматически добавляют
  пользователя на канал, когда получают уведомление от других серверов.
  Условия выполнения все того, ниже:

          1.  Пользователь может быть приглашен, если канал invite-only;

          2.  Никнейм/имя пользователя/имя хоста не должны быть
              забанеными;

          3.  Если установлен пароль, но должен быть верным.

  Это обсуждается в разделе MODE-команды более подробно (см. 4.2.3).
  Когда пользователи заходят на канал, они получат уведомление о всех
  командах их сервера. Оно вмещает в себе MODE, KICK, PART, QUIT и,
  конечно же, PRIVMSG/NOTICE. Команда JOIN требуется для сообщения всем
  серверам, чтобы каждый сервер знал, где искать пользователей, которые
  находятся на канале. Это позволяет оптимальную передачу сообщений
  PRIVMSG/NOTICE в канал.

  Если JOIN прошла хорошо, пользователь получает топик канала
  (используя RPL_TOPIC) и список пользователей, которые находятся на канале
  (используя RPL_NAMREPLY).

  Числовые ответы:

          ERR_NEEDMOREPARAMS              ERR_BANNEDFROMCHAN
          ERR_INVITEONLYCHAN              ERR_BADCHANNELKEY
          ERR_CHANNELISFULL               ERR_BADCHANMASK
          ERR_NOSUCHCHANNEL               ERR_TOOMANYCHANNELS
          RPL_TOPIC

  Примеры:

  JOIN #foobar                    ; вход на канал #foobar.

  JOIN &foo fubar                 ; вход на канал &foo, используя ключ "fubar".

  JOIN #foo,&bar fubar            ; вход на канал #foo, используя ключ "fubar"
                                  и на канал &bar без использования ключа.

  JOIN #foo,#bar fubar,foobar     ; вход на канал #foo, используя ключ "fubar".
                                  и на канал #bar, используя ключ "foobar".

  JOIN #foo,#bar                  ; вход на каналы #foo и #bar.

  :WiZ JOIN #Twilight_zone        ; JOIN-сообщение от WiZ

4.2.2 Part-сообщение

    Команда: PART
  Параметры: <channel>{,<channel>}

  Сообщение PART удаляет клиента, пославшего эту команду из списка
  активных пользователей для всех каналов, указанных в параметре.

  Числовые ответы:

          ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
          ERR_NOTONCHANNEL

  Примеры:

  PART #twilight_zone             ; покинуть канал "#twilight_zone"

  PART #oz-ops,&group5            ; покинуть каналы "&group5" и
                                  "#oz-ops".

4.2.3 Mode-сообщение

    Команда: MODE

  Команда MODE интересна своей двоякостью в IRC. Она позволяет изменять
  режим как имен пользователей, так и каналов. Рациональность этого
  выбора в том, что один день никнеймы будут устаревшими. Так же дела
  обстоят и с настройкой канала.

  Когда проверяются MODE-сообщения, это рекомендуется делать, ибо
  вводимое сообщение будет проверено первым, и тогда изменения, которые
  проверены и верны, вступят в силу.

4.2.3.1 Режимы канала

  Параметры: <channel> {[+|-]|o|p|s|i|t|n|b|v} [<limit>] [<user>]
              [<ban mask>]

  Команда MODE предоставляет операторам канала изменять характеристики
  'своего' канала. Так же есть требование, что изменять режимы канала
  могут только те операторы канала, которые создали канал.

  Список доступных режимов канала:

          o - брать/давать привилегии операторов канала
          p - флаг приватности канала;
          s - флаг секретности канала;
          i - флаг канала invite-only;
          t - при установке этого флага, менять топик могут только
              операторы;
          n - запрещает сообщения на канал от посторонних клиентов;
          m - модерируемый канал;
          l - установка ограничения на количество пользователей;
          b - установка маски бана;
          v - брать/давать возможность голоса при модерируемом режиме;
          k - установка на канал ключа (пароля).
     
  Когда используются установки 'o' и 'b', ограничение на полный из трех
  When using the 'o' and 'b' options, a restriction on a total of three
  per mode command has been imposed.  That is, any combination of 'o'
  and

4.2.3.2 Параметры пользователя

  Параметры: <nickname> {[+|-]|i|w|s|o}

  Режимы пользователя обычны такими изменениями, которые воздействуют на
  то, каким видят клиента или какие 'экста'-сообщения посылает клиент.
  Пользовательская команда MODE может относитется или к отправителю
  сообщения или к тому, чей никнейм указали в качестве параметра.

  Доступные режимы:

          i - делает пользователя невидимым;
          s - marks a user for receipt of server notices;
          w - user receives wallops;
          o - флаг оператора.

  Дополнительне режимы будут доступны позже.

  Если пользователь пытается сделать себя оператором, используя "+o"
  флаг, его попытка будет проигнорирована. Это не разрешено, в отличие от
  чьего-либо `деопа' себя самого (используя "-o").
 
  Числовые ответы:

          ERR_NEEDMOREPARAMS              RPL_CHANNELMODEIS
          ERR_CHANOPRIVSNEEDED            ERR_NOSUCHNICK
          ERR_NOTONCHANNEL                ERR_KEYSET
          RPL_BANLIST                     RPL_ENDOFBANLIST
          ERR_UNKNOWNMODE                 ERR_NOSUCHCHANNEL

          ERR_USERSDONTMATCH              RPL_UMODEIS
          ERR_UMODEUNKNOWNFLAG

  Примеры:

          Использования режимов канала:

MODE #Finnish +im               ; Делает канал #Finnish модерируемым и
                               'invite-only'.

MODE #Finnish +o Kilroy         ; Дает привилегии оператора Kilroy
                               на канале #Finnish.

MODE #Finnish +v Wiz            ; Дает WiZ право голоса на канале #Finnish.

MODE #Fins -s                   ; Убирает флаг 'secret' с канала #Fins.

MODE #42 +k oulu                ; Устанавливает на канал пароль "oulu".

MODE #eu-opers +l 10            ; Устанавливает максимальное количество
                               пользователей на канале (10).

MODE &oulu +b                   ; Вывод списка масок бана для канала.

MODE &oulu +b *!*@*             ; Предотвращает вход на канал для любого
                               пользователя.

MODE &oulu +b *!*@*.edu         ; Предотвращает вход любого пользователя
                               подходящего под маску хоста *.edu.

       Использование пользовательских режимов:

:MODE WiZ -w                    ; turns reception of WALLOPS messages
                               off for WiZ.

:Angel MODE Angel +i            ; Сообщение от Angel далает его невидимым.

MODE WiZ -o                     ; WiZ 'деопится' (убирает статус
                               оператора). Прямой доступ к этой команде
                               ("MODE WiZ +o") не может быть доступен
                               пользователям, с тех пор как введена
                               команда OPER.

4.2.4 Topic-сообщение

    Команда: TOPIC
  Параметры: <channel> [<topic>]

  Используется для изменения или просмотра топика канала. Топик канала
  <channel> останется прежним, если не будет дан новый топик <topic>.
  Если параметр <topic> подставлен, - топик канала изменится, если режим
  канала позволяет это сделать.

  Числовые ответы:

          ERR_NEEDMOREPARAMS              ERR_NOTONCHANNEL
          RPL_NOTOPIC                     RPL_TOPIC
          ERR_CHANOPRIVSNEEDED

  Примеры:

  :Wiz TOPIC #test :New topic     ;Пользователь Wiz устанавливает топик.

  TOPIC #test :another topic      ;Установка на #test топика "another
                                  topic".

  TOPIC #test                     ;Проверка топика на #test.

4.2.5 Names-сообщение

    Команда: NAMES
  Параметры: [<channel>{,<channel>}]

  Используя команду NAMES, пользователь может получитт список всех
  никнеймов, которые он видит на любом канале, на которых они находятся.
  Имена каналов, которые они могут видеть это те, которые не приватные
  (+p) или секретные (+s), или те, на которых сидит пользователь.
  Параметр <channel> указывает, с какого канала(ов) собрать информацию.
  Эта команда не возвращает кода ошибки из-за неправильных названий
  каналов.

  Если параметр <channel> не задан, выводится список всех каналов и имен
  тех, кто на них находится. И к концу списка - список пользователей,
  которые видимые, но не находятся ни на одной канале, или не на одном
  видимом канале, которые начинаюся как 'channel' "*".

  Числовые ответы:

          RPL_NAMREPLY                    RPL_ENDOFNAMES

  Примеры:

  NAMES #twilight_zone,#42        ; Список видимых пользователей на канале
                                  #twilight_zone и #42, если каналы
                                  видимы вам.

  NAMES                           ; Список всех видимых каналов и
                                  пользователей.

4.2.6 List-сообщение

    Команда: LIST
  Параметры: [<channel>{,<channel>} [<server>]]

  LIST используется для вывода списка канало и их топиков. Если
  используется параметр <channel>, то выводится только статус этого
  канала. Приватные каналы указаны (без их топиков) как каналы "Prv", без
  указания количества клиентов, сидящих на этом канале. Само собой -
  секретные каналы не приводятся в списке,
  если, конечно, клиент не является членом подобного канала.

  Числовые ответы:

          ERR_NOSUCHSERVER                RPL_LISTSTART
          RPL_LIST                        RPL_LISTEND

  Примеры:

  LIST                            ; Список всех каналов.

  LIST #twilight_zone,#42         ; Список каналов #twilight_zone и #42

4.2.7 Invite-сообщение

    Команда: INVITE
  Параметры: <nickname> <channel>

  Сообщение INVITE используется для приглашения пользователей на канал.
  Параметр <nickname> - указание пользователя, которого требуется
  пригласить на канал, который указывается следующим параметром <channel>.
  Не обязательно, чтобы канал, на который приглашается указанный
  пользователь, был отсутствующим или не правильным каналом. Приглашая
  пользователя на канал, который является invite-only (MODE +i), клиент,
  посылающий приглашение, должет быть указан как оператор канала на
  данном канале.

  Числовые ответы:

          ERR_NEEDMOREPARAMS              ERR_NOSUCHNICK
          ERR_NOTONCHANNEL                ERR_USERONCHANNEL
          ERR_CHANOPRIVSNEEDED
          RPL_INVITING                    RPL_AWAY

  Примеры:

  :Angel INVITE Wiz #Dust         ; Пользователь Angel пригласил WiZ на
                                  канал #Dust

  INVITE Wiz #Twilight_Zone       ; Команда приглашения WiZ на канал
                                  #Twilight_zone

4.2.8 Kick-команда

    Команда: KICK
  Параметры: <channel> <user> [<comment>]

  Команда KICK может быть использована для ускоренного удаления
  пользователя с канала. Как бы выпинывает его с канала (быстрый PART).
  Только оператора канала может "кикнуть" другого пользователя с канала.
  Каждый сервер, который получил сообщение KICK, проверяет ее на
  достоверность (напрмер, что отправитель являтся оператором канала),
  перед удалением жертвы с канала.

  Числовые ответы:

          ERR_NEEDMOREPARAMS              ERR_NOSUCHCHANNEL
          ERR_BADCHANMASK                 ERR_CHANOPRIVSNEEDED
          ERR_NOTONCHANNEL

  Примеры

KICK &Melbourne Matthew         ; Кик Matthew с канала &Melbourne

KICK #Finnish John :Speaking English
                               ; Кик John с #Finnish, используя
                               "Speaking English", как причину
                               (комментарий).

:WiZ KICK #Finnish John         ; KICK-сообщение WiZ удаляет John
                               с канала #Finnish

ПРИМЕЧАНИЕ:
    Возможно расширение команды KICK следующими параметрами:

<channel>{,<channel>} <user>{,<user>} [<comment>]

4.3 Серверные запросы и команды

  Группа команд запроса сервера была разработана для возврата информации о
  любом сервере, который находится в сети. Все присоединенные сервера
  должны отвечать на эти запросы и отвечать корректно. Любой неверный
  ответ должен быть рассмотрен как знак того, что сервер неисправен и его
  следует отсоединить/отключить до прояснения ситуации.

  В этих запросах, в качестве параметра <server> можно указать как
  никнейм или сервер, так и маску имен. Для каждого параметра будет
  создан один запрос и установлены ответы.

4.3.1 Version-сообщение

    Команда: VERSION
  Параметры: [<server>]

  Используется для запроса версии программы сервера. Параметр <server>
  используется для указания сервера, к которому клиент не подсоединен.

  Числовые ответы:

          ERR_NOSUCHSERVER                RPL_VERSION

  Примеры:

  :Wiz VERSION *.se               ; Сообщение от Wiz для проверки версии
                                  сервера, попадающего под маску "*.se"

  VERSION tolsun.oulu.fi          ; Проверка версии сервера "tolsun.oulu.fi".

4.3.2 Stats-сообщение

    Команда: STATS
  Параметры: [<query> [<server>]]

  STATS предназначен для запроса статистики указанного сервера. Если
  параметр <server> опущен, то возвращается обратно только окончание
  stats-ответа.

  Запрос может быть дан любым письмом, которое проверяется только
  сервером-получателем (если указан параметр <server>) и в противном
  случае - на промежуточных серверах, игнорируя и неизменяя.
  Следующие запросы содержаться в текущем IRC, обеспечивая и предоставляя
  большую часть информации о нужном сервере. Хотя, они могут не
  поддерживаться в некоторых версиях, все серверы будут обеспечивать
  корректный ответ на запрос STATS, который содержится в текущих
  используемых форматах ответа.

  На данный момент поддерживаются следующие запросы:

          c - возврат списка серверов, к которым может присоединится
              сервер;
          h - возврат списка серверов, которые доступны как хабы или
              свободные;
          i - возврат списка хостов, сервер которых доспускает соединение
              клиента;
          k - возврат списка забаненых имен пользователей/хостов для
              указанного сервера;
          l - возврат списка серверных соединений, проказывающих
              длину каждого соединения и траффик в байтах и сообщениях
              для каждого направления;
          m - возврат списка команд, поддерживаемых сервером и
              используемый подсчет для каждого, если не равен нулю;          
          o - возврат списка хостов, с которых нормальные клиенты могут
              достать операторов;
          y - показ Y (Class) строк из конфигурационного файла сервера;
          u - возврат строки, показывающей как давно был поднят сервер.

  Числовые Ответы:

          ERR_NOSUCHSERVER
          RPL_STATSCLINE                  RPL_STATSNLINE
          RPL_STATSILINE                  RPL_STATSKLINE
          RPL_STATSQLINE                  RPL_STATSLLINE
          RPL_STATSLINKINFO               RPL_STATSUPTIME
          RPL_STATSCOMMANDS               RPL_STATSOLINE
          RPL_STATSHLINE                  RPL_ENDOFSTATS

  Примеры:

STATS m                         ; проверка используемой команды для
                               сервера, с которым вы соединены

:Wiz STATS c eff.org            ; запрос WiZ для C/N строки
                               информации с сервера eff.org

4.3.3 Links-сообщение

    Команда: LINKS
  Параметры: [[<remote server>] <server mask>]

  С LINKS пользователь может создать список всех серверов, которые
  знают сервер ответом на запрос. Возвращенный список серверов должен
  попадать под маску, или если маска не задана - вернуть полный список.

  Если <remote server> задан в дополнительно в <server mask>, команда
  LINKS отправится на первый сервер, найденный по этому значению, имени
  (если несколько), и этот сервер будет опрашиваться.

  Числовые ответы:

          ERR_NOSUCHSERVER
          RPL_LINKS                       RPL_ENDOFLINKS

  Примеры:

LINKS *.au                      ; список всех серверов, попадающих  
                               под маску *.au;

:WiZ LINKS *.bu.edu *.edu       ; LINKS-сообщение от WiZ первому серверу
                               из попадающих под маску *.edu для выдачи
                               списка серверов с маской *.bu.edu.

4.3.4 Time-сообщение

    Команда: TIME
  Параметры: [<server>]

  Используется для запроса локального времени указанного сервера. Если
  параметр <server> опущен, будет выдан ответ с сервера ващего соединения.

  Числовые ответы:

          ERR_NOSUCHSERVER                RPL_TIME

  Примеры:

  TIME tolsun.oulu.fi             ; проверка времени на сервере
                                  "tolson.oulu.fi"

  Angel TIME *.au                 ; пользователь Angel запрашивает время
                                   на серверах, попадающих под маску "*.au"

4.3.5 Connect-сообщение

    Команда: CONNECT
  Параметры: <target server> [<port> [<remote server>]]

  Команда используется для попытки создания сервером нового соединения с
  другим сервером. CONNECT-сообщением могут пользоваться только
  IRC-операторы. Если удаленный сервер указан в строке параметров, он
  присоединяется к <target server> на <port>.

  Числовые ответы:

          ERR_NOSUCHSERVER                ERR_NOPRIVILEGES
          ERR_NEEDMOREPARAMS

  Примеры:

CONNECT tolsun.oulu.fi          ; Попытка присоединиться к серверу
                               tolsun.oulu.fi

:WiZ CONNECT eff.org 6667 csd.bu.edu
                               ; CONNECT вызывает WiZ для соединения
                               eff.org и csd.bu.edu на порт 6667.

4.3.6 Trace-сообщение

    Команда: TRACE
  Параметры: [<server>]

  TRACE используется для поиска маршрута до указанного сервера. Каждый
  сервер, через которого проходит это сообщение, должен информировать
  отправителя о прозрачности линка и формировать цепочку ответов от
  использования "traceroute". После отправления ответа, он должен послать
  TRACE-сообщение следующему серверу и так до указанного сервера. Если
  параметр <server> опущен, то отправителю придет ответ, который будет
  содержать всех серверы, которые соединены с его сервером.
 
  Если указанный в <server> является текущим сервером, тогда придет
  ответ, содержащий все серверы и пользователей, которые присоединены к
  нему, хотя просмотр пользователей разрешается делать только операторам.
  Если в <server> указать никнейм, придет ответ для этого никнейма.

  Числовые ответы:

          ERR_NOSUCHSERVER

  Если TRACE отправлено к другому серверу, все промежуточные серверы
  должны вернуть ответ RPL_TRACELINK для сообщения о прохождении сквозь
  них TRACE-сообщения.

          RPL_TRACELINK
  TRACE-ответ может быть составлен из любых следующих числовых ответов.

          RPL_TRACECONNECTING             RPL_TRACEHANDSHAKE
          RPL_TRACEUNKNOWN                RPL_TRACEOPERATOR
          RPL_TRACEUSER                   RPL_TRACESERVER
          RPL_TRACESERVICE                RPL_TRACENEWTYPE
          RPL_TRACECLASS

  Примеры:

TRACE *.oulu.fi                 ; TRACE серверу из маски *.oulu.fi
:WiZ TRACE AngelDust            ; TRACE используется WiZ для никнейма AngelDust

4.3.7 Admin-команда

    Команда: ADMIN
  Параметры: [<server>]

  Сообщение ADMIN используется для поиска администратора указанного
  сервера, или текущего сервера, если параметр <server> не указан. Каждый
  сервер должен иметь возможность отправить ADMIN-сообщения другим
  серверам.

  Числовые ответы:

          ERR_NOSUCHSERVER
          RPL_ADMINME                     RPL_ADMINLOC1
          RPL_ADMINLOC2                   RPL_ADMINEMAIL

  Примеры:

  ADMIN tolsun.oulu.fi            ; запрос ADMIN-ответа с tolsun.oulu.fi

  :WiZ ADMIN *.edu                ; ADMIN-запрос от WiZ для первого
                                  сервера, найденного по маске *.edu.

4.3.8 Info-команда

    Команда: INFO
  Параметры: [<server>]

  Команда запрашивает информацию, которой описывается сервер: версия,
  когда скомпилирован, patchlevel, когда запущен, и другую информацию,
  которая может заинтерисовать запрашивающего.

  Числовые ответы:

          ERR_NOSUCHSERVER
          RPL_INFO                        RPL_ENDOFINFO

  Примеры:

  INFO csd.bu.edu                 ; запрос INFO с csd.bu.edu

  :Avalon INFO *.fi               ; INFO запрошен Avalon для первого
                                  сервера, найденного по маске *.fi.

  INFO Angel                      ; запрос INFO от сервера, к которому
                                  подсоединен Angel.

4.4 Сообщения отправки

  Основное предназначение IRC-протокола - предоставление основы для связи
  и общения между клиентами. PRIVMSG и NOTICE являются текстовыми
  сообщениями от одного клиента к другим.

4.4.1 Private-сообщения

    Команда: PRIVMSG
  Параметры: <receiver>{,<receiver>} <text to be sent>

  PRIVMSG используется для частной переписки между пользователями.
  <receiver> - никнейм получателя сообщения. Так же там можно указать
  список имен или каналов, разделенных запятыми.

  Параметр <receiver> так же может быть маской хоста (#mask) или маски
  сервера ($mask). В обоих случаях сервер будет отсылать PRIVMSG только
  тем, кто попадает под серверную или хост-маску. Маска должна содержать
  в себе как минимум 1 (одну) ".". Это требование вынуждаеит пользователей
  отсылать сообщения к "#*" или "$*", которые уже потом рассылаются всем
  пользователям; по опыту, этим злоупотребляет большое количество
  пользователей. В масках используются такие символы как '*' и '?'. Это
  расширение команды PRIVMSG доступно только IRC-операторам.

  Числовые ответы:

          ERR_NORECIPIENT                 ERR_NOTEXTTOSEND
          ERR_CANNOTSENDTOCHAN            ERR_NOTOPLEVEL
          ERR_WILDTOPLEVEL                ERR_TOOMANYTARGETS
          ERR_NOSUCHNICK
          RPL_AWAY

  Примеры:

:Angel PRIVMSG Wiz :Hello are you receiving this message ?
                               ; Сообщение от Angel к Wiz;

PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br ;
                               Сообщение к Angel;

PRIVMSG jto@tolsun.oulu.fi :Hello !
                               ; Сообщение от клиента на сервер.
                               tolsun.oulu.fi с именем "jto";

PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting.
                               ; Сообщение ко всем, кто находится на
                               серверах, попадающих под маску *.fi;

PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions
                               ; Сообщение для всех пользователей,
                               сидящих на хосте, попадающим под маску *.edu.

4.4.2 Notice-сообщения

    Команда: NOTICE
  Параметры: <nickname> <text>

  Сообщение NOTICE используеьтся подобно PRIVMSG. Отличия между ними в
  том, что на NOTICE-сообщение ждать автоматического ответа бесполезно.
  Это правило распространяется и на серверы, - они не должны отсылать
  обратно сообщения-NOTICE клиентам, содержащие ошибки. Обьект этого
  правила заключается в петле между клиентом, автоматически посылающим
  что-либо в ответ на что-либо полученное. Обычно, это используется
  автоматами (клиентами с AI или другой интерактивной программой,
  управляющей их действиями).

  См. PRIVMSG для более подробной информации о запросах и ответах.

4.5 Пользовательские запросы

  Пользовательские запросы являют собой группу команд, которая главным
  образом касается поиска подробностей на особенном пользователе или
  группы пользователей. Когда используются маски с разнымит командами,
  если они подставляются, они должны возвращать информацию только тех
  пользователей, которые 'видны' вам. Видимость пользователя определяется
  как комбинация режима пользователя и установки каналов.

4.5.1 Who-запрос

    Команда: WHO
  Параметры: [<name> [<o>]]

  Сообщение WHO используется клиентом для создания запроса, который
  возвращает список информации, которая 'подставляется' параметром <name>
  указанным клиентом. В отсутствии параметра <name>, все видимые
  (пользователи, которых не видно (пользовательский режим +i) и те, кто
  находятся на других каналах, нежели запрашивающий клиент) попадают в
  список. Результат может быть достигнут использованием вместо <name> "0"
  или других масок, которые будут подставлять все возможные окончания.

  <name> обратиться к WHO, подставленному против пользовательского
  хоста, сервера, реального имени или никнейма, если канал <name> не найден.

  Если параметр "o" прошел только операторам, обеспечивается возврат
  только маски имени.

  Числовые ответы:

          ERR_NOSUCHSERVER
          RPL_WHOREPLY                    RPL_ENDOFWHO

  Примеры:

  WHO *.fi                        ; Список пользователей, кто стоит
                                  напротив "*.fi";

  WHO jto* o                      ; Список пользователей, кто находится
                                  напротив подходящей маски "jto*", если
                  они являются операторами.

4.5.2 Whois-запрос

    Команда: WHOIS
  Параметры: [<server>] <nickmask>[,<nickmask>[,...]]

  Это сообщение используется для запроса информации об отдельном
  пользователе. Сервер будет отвечать на это сообщением различными
  числовыми сообщениями, указывая разность положений каждого пользователя,
  который попал под маску (если вы указали ее). Если в <nickmask> не
  указана никакая информация о том, какой никнейм опросить, вы получите
  информацию о всех доступных никнеймах. Запятая разделяет список
  никнеймов.

  Предыдущая версия отправляла запрос на указанный сервер. Это полезно,
  если хотите знать как долго опрашиваемый пользователь будет
  бездействовать , как только локальный сервер (т.е, пользователь
  напрямую соединен с сервером) узнает эту информацию.

  Числовые ответы:

          ERR_NOSUCHSERVER                ERR_NONICKNAMEGIVEN
          RPL_WHOISUSER                   RPL_WHOISCHANNELS
          RPL_WHOISCHANNELS               RPL_WHOISSERVER
          RPL_AWAY                        RPL_WHOISOPERATOR
          RPL_WHOISIDLE                   ERR_NOSUCHNICK
          RPL_ENDOFWHOIS

  Примеры:

  WHOIS wiz                       ; возврат пользователю информацию  
                                  о никнейме WiZ;

  WHOIS eff.org trillian          ; опрос сервера eff.org о информации
                                  пользователя trillian.

4.5.3 Whowas-сообщение

    Команда: WHOWAS
  Параметры: <nickname> [<count> [<server>]]

  WHOWAS запрашивает информацию о никнейме, который долгое время
  отсутствует. Это может понадобиться при изменении никнейма или если
  пользователь покинул IRC. В ответе на этот запрос, сервер ищет историю
  никнейма, просматривая все никнеймы, которые хоть как-то похожи на
  нужный (без использования масок). Наибольший размер найденного
  отсылается обратно. Если было многоразовый ввод, ответы будут равны
  числу указанного в <count> (или все из них, если параметр будет не
  задан).
 
  Числовый ответы:

          ERR_NONICKNAMEGIVEN             ERR_WASNOSUCHNICK
          RPL_WHOWASUSER                  RPL_WHOISSERVER
          RPL_ENDOFWHOWAS

  Примеры:

  WHOWAS Wiz                      ; возврат всей информации в истории о
                                  никнейме "WiZ";

  WHOWAS Mermaid 9                ; возврат 9 наиболее запрашиваемых
                                  вводов в никнейм-истории для "Mermaid";

  WHOWAS Trillian 1 *.edu         ; возврат наиболее запрашиваемой
                                  истории для "Trillian" с первого
                                  сервера, попавшего под маску  "*.edu".

4.6 Всевозможные сообщения

  Сообщения этого раздела не попали в другие категории, но они так же
  доступны и требуемые протоколом.

4.6.1 Kill-сообщение

    Команда: KILL
  Параметры: <nickname> <comment>

  Сообщение KILL используется соединением клиент-сервер для закрытия
  сервером текущего соедиения. KILL используется серверами, когда они
  замечают двойной вход в список разрешенных никнеймов и удаляют второго
  зашедшего. Так же, команда доступна IRC-операторам.

  Клиенты, у которых настройки позволяют автоматически пересоединяться,
  делают эту команду бесполезной. Этому так же может служить ухудшение
  связи и использоваться в остановке большого количества ошибок, любой
  пользователь может выбрать получение KILL-сообщений, созданных для
  других, сохраняя 'глаз' на наличествующей проблеме.

  В месте, где к никнеймам существует требование уникальности, сообщения
  KILL отправляется всем замеченым 'дупликатам' (что пытаются
  зарегистрировать двух пользователей с некоторым никнеймом) в надежде,
  что один из них исчезнет и останется только один.

  Коментарий указывается для сообщения причины KILL. Для KILL'ов,
  созданных сервером, обычно причина указывается как конфликт между двумя
  никнеймами. Для пользователей это является достаточной адекватной
  причиной для удовлетворения тех, кто видел это. Предотвращая обманные
  KILL'ы, коментарий так же показывает 'kill-path', который обновляется
  каждым сервером, тем самым показывая "источник" KILL-сообщения.

  Числовые ответы:

          ERR_NOPRIVILEGES                ERR_NEEDMOREPARAMS
          ERR_NOSUCHNICK                  ERR_CANTKILLSERVER


  KILL David (csd.bu.edu <- tolsun.oulu.fi)
                                  ; Никнейм застрял между csd.bu.edu
                                  и tolson.oulu.fi


  ЗАМЕЧАНИЕ:
  Рекомендуется разрешить "убивать" других пользователей только
  IRC-операторам. В идеальном мире не каждому оператору понадобиться
  делать подобное.

4.6.2 Ping-сообщение

    Команда: PING
  Параметры: <server1> [<server2>]

  PING испольщуется для тестирования наличия активности клиента на другом
  конце соединения. Это сообщение посылается с регулярными интервалами,
  если не замечено другой активности, исходящей от соединения. Если
  соединение не отвечает на PING - соединение закрыто.

  Любой клиент, который получил PING-сообщение, должен ответить на
  <server1> (сервер, который посылает сообщение PING) так быстро, как это
  только возможно, с PONG-сообщением, указывая на то, что он еще здесь и
  живой. Серверы могут не отвечать на команды PING, но полагаясь на
  PING'и с другого конца соединения, устанавливают живо ли соединение.
  Если указан параметр <server2>, PING'сообщение перенаправляется туда.

  Числовые ответы:

          ERR_NOORIGIN                    ERR_NOSUCHSERVER

  Примеры:

  PING tolsun.oulu.fi             ; сервер послал PING-сообщение другому
                                  серверу для проверки живости соединения.

  PING WiZ                        ; PING-сообщение послано никнейму WiZ

4.6.3 Pong-сообщение

    Команда: PONG
  Параметры: <daemon> [<daemon2>]

  PONG является ответной реакцией на PING. Если дан параметр <daemon2>,
  это сообщение должно быть перенаправленна данному демону. Параметр
  <daemon> является именем демона, который отвечает на PING-сообщение и
  генерирует это сообщение.

  Числовые ответы:

          ERR_NOORIGIN                    ERR_NOSUCHSERVER

  Примеры:

  PONG csd.bu.edu tolsun.oulu.fi  ; PONG-сообщение от csd.bu.edu к
                                  tolsun.oulu.fi

4.6.4 Error-сообщение

    Команда: ERROR
  Параметры: <error message>

  Команда ERROR предназначена для использования серверами, когда они
  сообщают о серьезных или смертельных ошибках IRC-операторам. Сообщение
  так же может быть отправлена с одного сервера на другой, но это не
  сможет быть подтверждено с любых нормальных неизвестных клиентов.

  ERROR используется для сообщения ошибок, которые случаются только при
  соединениях класса сервер-к-серверу. Сообщение отсылается на сервер с
  другого конца соединения (который оправляет его всем IRC-операторам,
  подсоединенным к нему) и всем операторам текущего соединения. Оно не
  может быть отослано каким-либо другим серверам, если оно не получено с
  сервера.

  Когда сервер отсылает полученное ERROR-сообщение к своим операторам,
  сообщение следует поместить в сообщение NOTICE, сообщающее, что клиент
  не может отвечать на ошибку.

  Числовые ответы:

          None.

  Примеры:

  ERROR :Server *.fi already exists; ERROR-сообщение с другого сервера,
                                  являющегося причиной ошибки.

  NOTICE WiZ :ERROR from csd.bu.edu — Server *.fi already exists
                                  ; Несколько ERROR-сообщений, но
                                  посланнных от пользователя WiZ на
                  другой сервер.

5. ОПЦИОНАЛЬНЫЕ СООБЩЕНИЯ

  Этот раздел описывает опциональные сообщения. Они не требуются в рабочем
  сервере, но так или иначе они тоже часть протокола. В отсутствии опции,
  может создаваться ERROR-сообщение или просто неизвестная командная
  ошибка. Если сообщение адресовано другому серверу, тогда она должна
  быть пропущена (потребуется элементарный парсинг). Назначенные
  числители для того, описаны ниже.

5.1 Away-сообщение

    Команда: AWAY
  Параметры: [message]

  С сообщением AWAY, клиенты могут устанавливать автоматическую строку
  ответа на любые PRIVMSG-команды, направленные им (не на канал).
  Автоматический ответ посылается сервером к клиенту, пославшего команду
  PRIVMSG. Только отвечающий сервер может быть только один, к которому
  подсоединен клиент.

  AWAY используется вместе с одним параметром (установка сообщения AWAY)
  или без параметров (снятие сообщения AWAY).

  Числовые ответы:

          RPL_UNAWAY                      RPL_NOWAWAY

  Примеры:

  AWAY :Gone to lunch.  Back in 5 ; установка away-сообщения "Gone to lunch.
                                  Back in 5".

  :WiZ AWAY                       ; снятие пользователем WiZ сообщения
                                  AWAY.

5.2 Rehash-сообщение

    Команда: REHASH
  Параметры: None

  REHASH используется IRC-оператором для перечитывания конфигурационных
  файлов сервера.

  Числовые ответы:

       RPL_REHASHING                   ERR_NOPRIVILEGES

  Примеры:

REHASH                          ; сообщение от клиента со статусом
                               IRC-оператора запускает процесс перечитывания
               конфигурационных файлов сервера.

5.3 Restart-сообщение

    Команда: RESTART
  Параметры: None

  RESTART также испольщуется только IRC-оператором для перезагрузки
  сервера. Это сообщение опциональное, хотя оно может быть рассмотрено
  как рискованное - позволяя пользователям присоединяться к серверу в
  качестве IRC-оператора и запустить эту команду, причиняя разрушения
  сервису.

  Команда RESTART должна всегда быть полностью выполняема сервером,
  к которому присоединен посылающий команду клиент и не принимать от
  других серверов.

  Числовые ответы:

          ERR_NOPRIVILEGES

  Примеры:

  RESTART                         ; не требует параметров.

5.4 Summon-сообщение

    Команда: SUMMON
  Параметры: <user> [<server>]

  Команда может быть использована для вызова пользователей, сидящих на
  том же хосте, что и IRC-сервер, в IRC. Это сообщение посылается только
  если требуемый сервер (a) имеет включенный SUMMON, (b) пользователь
  находится в сети и (c) сервер может написать в пользовательский tty
  (или подобное).

  Если параметр <server> не задан, то попытки вызвать <user> с сервера
  будут на сервере, на котором подсоединен клиент, вызывающий <user>.

  Если SUMMON отключена на сервере, должен возвратиться числовой ответ
  ERR_SUMMONDISABLED и оригинал сообщения.

  Числовые ответы:

          ERR_NORECIPIENT                 ERR_FILEERROR
          ERR_NOLOGIN                     ERR_NOSUCHSERVER
          RPL_SUMMONING

  Примеры:

  SUMMON jto                      ; вызов пользователя jto на хост сервера

  SUMMON jto tolsun.oulu.fi       ; вызов пользователя jto на схост
                                  сервера, который обьявлен параметром -
                  "tolsun.oulu.fi"



5.5 Users-сообщение

    Команда: USERS
  Параметры: [<server>]

  USERS выводит список пользователей находящихся на сервера в формате,
  подобном who(1), rusers(1) и  finger(1). Многие могут отключить эту
  команду на своем сервере по причине безопасности. Если отключено, то
  выйдет числовой ответ, указавая на это.

  Числовые ответы:

          ERR_NOSUCHSERVER                ERR_FILEERROR
          RPL_USERSSTART                  RPL_USERS
          RPL_NOUSERS                     RPL_ENDOFUSERS
          ERR_USERSDISABLED

  Ответ отключенной команды:

          ERR_USERSDISABLED

  Примеры:

USERS eff.org                   ; запрос списка пользователей с сервера
                               eff.org

:John USERS tolsun.oulu.fi      ; запрос от John списка пользователей
                               с сервера tolsun.oulu.fi

5.6 Operwall-команда

    Команда: WALLOPS
  Параметры: Текст, отсылаемый всем IRC-операторам, находящихся в сети.

  Отправка сообщения всем IRC-оператороам, которые находятся в данный
  момент в сети. После выполнения WALLOPS как команды пользователя,
  это будет расцениваться как частое и обычно неверное, ибо отправлено
  сообщение большому количеству людей (подобно WALL). Прямо рекомендуемо,
  что текущая принадлежность WALLOP будет использована каак пример
  доступности и узнаваема только серверами, как отправителями WALLOPS.

  Числовые ответы:
 
          ERR_NEEDMOREPARAMS

  Примеры:

  :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua; WALLOPS
                                  сообщение от csd.bu.edu, обьявляющая,
                                  что CONNECT-сообщение получено и
                                  активизировано Joshua.

5.7 Userhost-сообщение

    Команда: USERHOST
  Параметры: <nickname>{<space><nickname>}

  Команда USERHOST требует список больше 5-ти никнеймов, разделеных
  пробелом и возвращает информацию о каждом никнейме, который был найден.

  Числовые ответы:

          RPL_USERHOST                    ERR_NEEDMOREPARAMS

  Примеры:

  USERHOST Wiz Michael Marty p    ;USERHOST запрос информации о никнеймах
                                  "Wiz", "Michael", "Marty" и "p"

5.8 Ison-сообщение

    Команда: ISON
  Параметры: <nickname>{<space><nickname>}

  ISON предоставляет быстрый и экономичный вариант отдачи отклика о
  каком-либо из двух никнеймов, находящихся в IRC. ISON использует тольуо
  один (1) параметр: список никнеймов, разделенных пробелами. Для каждого
  никнейма, представленного в списке, сервер добавляет в свою ответную
  строку. Но эта строка может вернуться и пустой, и просто копией
  параметра строки, или какой-другой подстановкой никнеймов. Есть только
  одно ограничение - длина списка никнеймов не должна превышать 512
  символов, иначе сервер обрежет параметр под этот предел.

  ISON поддерживается сервером только для клиентов, присоединенных к нему
  и игнорирует запросы других.

  Числовые ответы:

          RPL_ISON                ERR_NEEDMOREPARAMS

  Примеры:

  ISON phone trillian WiZ jarlek Avalon Angel Monstah
                                  ; Пример ISON запроса 7 никнеймов.

6. ОТВЕТЫ

  Следующий список числовых ответов, которые создаются как ответная
  реакция на вводимые команды. Каждый
  Each numeric is given with its number, name and reply string.

6.1 Error-ответы

       401     ERR_NOSUCHNICK
                       "<nickname> :No such nick/channel"

               - Используется для сообщения, что опущен параметр,
                 отвечающий за никнейм.

       402     ERR_NOSUCHSERVER
                       "<server name> :No such server"

               - Используется для сообщения, что сервер, указанный в
                 строке параметров, не найден.

       403     ERR_NOSUCHCHANNEL
                       "<channel name> :No such channel"

               - Используется для сообщения, что название канала не
                 верно.

       404     ERR_CANNOTSENDTOCHAN
                       "<channel name> :Cannot send to channel"

               - Отсылается пользователю, который либо (a) не на канале,
                 с режимом +n, либо (b) не является чанопом (или режима
                 +v) на канале, который имеет режим +m, и пытается
                 отослать PRIVMSG-сообщение  на этот канал.

       405     ERR_TOOMANYCHANNELS
                       "<channel name> :You have joined too many \
                        channels"
               - Отсылается пользователю, когда он уже находится на
                 максимально разрешенном количестве каналов и пытается
                 зайти на еще один канал.

       406     ERR_WASNOSUCHNICK
                       "<nickname> :There was no such nickname"

               - Возвращается командой WHOWAS, показывая тем самым
                 отсутствие истории информации об указанном никнейме.

       407     ERR_TOOMANYTARGETS
                       "<target> :Duplicate recipients. No message \
                        delivered"

               - Возвращается клиенту, который пытается отослать
                 PRIVMSG/NOTICE, используя формат отправки user@host и
                 для user@host, который имеет особые случаи.

       409     ERR_NOORIGIN
                       ":No origin specified"

               - PING или PONG сообщения теряют параметр источника,
                 который требуется, хотя эти команды должны работать без
                 правильных префиксов.

       411     ERR_NORECIPIENT
                       ":No recipient given (<command>)"
       412     ERR_NOTEXTTOSEND
                       ":No text to send"
       413     ERR_NOTOPLEVEL
                       "<mask> :No toplevel domain specified"
       414     ERR_WILDTOPLEVEL
                       "<mask> :Wildcard in toplevel domain"

               - 412 - 414 возвращаются командой PRIVMSG, показывая, что
                 сообщение не смогло пройти по некоторым причинам.
                 ERR_NOTOPLEVEL и ERR_WILDTOPLEVEL ошибки, что
                 возвращаются, когда неправильно используют
                 "PRIVMSG $<server>" или "PRIVMSG #<host>".

       421     ERR_UNKNOWNCOMMAND
                       "<command> :Unknown command"

               - Возвращается зарегистрированному клиенту, при попытке
                 отослать неизвестную серверу команду.

       422     ERR_NOMOTD
                       ":MOTD File is missing"

               - Серверный файл MOTD не может быть открыт сервером.

       423     ERR_NOADMININFO
                       "<server> :No administrative info available"

               - Возвращается сервером при ответе на ADMIN-сообщение,
                 когда оно является ошибкой в найденной информации.

       424     ERR_FILEERROR
               ":File error doing <file op> on <file>"
               - Генерация ERROR-сообщения, используя для отчета
                 поврежденного файла.

       431     ERR_NONICKNAMEGIVEN
                       ":No nickname given"

               - Возвращается, когда в параметре отсутствует никнейм.

       432     ERR_ERRONEUSNICKNAME
                       "<nick> :Erroneus nickname"

               - Возвращается после получения NICK-сообщения, которое
                 содержит символы, которые запрещены. Смотрите раздел
                 х.х.х для более подробной информации.

       433     ERR_NICKNAMEINUSE
                       "<nick> :Nickname is already in use"

               - Возвращается при смене никнейма на другой, уже
                 используемый.

       436     ERR_NICKCOLLISION
                       "<nick> :Nickname collision KILL"

               - Возвращается сервером к клиенту, когда сервер видит
                 конфликт никнейма (зарегистрированный никнейм уже есть).

       441     ERR_USERNOTINCHANNEL
                       "<nick> <channel> :They aren't on that channel"

               - Возвращается сервером, указывая на то, что данный
                 пользователь отсутствует на канале, заданном в
                 параметре.

       442     ERR_NOTONCHANNEL
                       "<channel> :You're not on that channel"

               - Возвращается сервером, как только клиент пытается
                 выполнить команду канала, на котором отсутствует.

       443     ERR_USERONCHANNEL
                       "<user> <channel> :is already on channel"

               - Возвращается, когда клиент пытается пригласить
                 пользователя на канал, на котором пользователь
         уже присутствует.

       444     ERR_NOLOGIN
                       "<user> :User not logged in"

               - Возвращается вызывающим после команды SUMMON для
                 пользователя, который в данное время недоступен в сети.

       445     ERR_SUMMONDISABLED
                       ":SUMMON has been disabled"

               - Возвращается как ответ на команду SUMMON. Может быть
                 возвращено любым сервером.

       446     ERR_USERSDISABLED
                       ":USERS has been disabled"

               - Возвращается как ответ на команду USERS.  Может быть
                 возвращено любым сервером.

       451     ERR_NOTREGISTERED
                       ":You have not registered"

               - Возвращается сервером для напоминания, что клиент должен
                 быть зарегистрирован, перед тем, как сервер даст
                 дополнительные возможности.

       461     ERR_NEEDMOREPARAMS
                       "<command> :Not enough parameters"

               - Возвращается сервером, числительными командами для
                 указания пользователю, что тот не указал всех параметров.

       462     ERR_ALREADYREGISTRED
                       ":You may not reregister"

               - Возвращается сервером любому линку, который пытается
                 изменить часть подробностей регистрации (подобные паролю
                 или пользовательской информацией из второго
                 USER-сообщения).


       463     ERR_NOPERMFORHOST
                       ":Your host isn't among the privileged"

               - Возвращается клиенту, который пытается
                 зарегистрироваться с сервером, который не настроен на
                 поддержку соединений с хостом, который пытается
                 присоединиться.

       464     ERR_PASSWDMISMATCH
                       ":Password incorrect"

               - Возвращается при неправильно введеном или неуказанным
                 паролем.

       465     ERR_YOUREBANNEDCREEP
                       ":You are banned from this server"

               - Возвращается после попытки соединения и регистрации с
                 сервером, который настроен на отказ регистрации с вами.


       467     ERR_KEYSET
                       "<channel> :Channel key already set"
       471     ERR_CHANNELISFULL
                       "<channel> :Cannot join channel (+l)"
       472     ERR_UNKNOWNMODE
                       "<char> :is unknown mode char to me"
       473     ERR_INVITEONLYCHAN
                       "<channel> :Cannot join channel (+i)"
       474     ERR_BANNEDFROMCHAN
                       "<channel> :Cannot join channel (+b)"
       475     ERR_BADCHANNELKEY
                       "<channel> :Cannot join channel (+k)"
       481     ERR_NOPRIVILEGES
                       ":Permission Denied- You're not an IRC operator"

               - Любая команда, требующая привилегий IRC-оператора,
                 должна вернуть подобную ошибку, показывая на
                 безуспешность действий рядового пользователя.

       482     ERR_CHANOPRIVSNEEDED
                       "<channel> :You're not channel operator"

               - Любая команда, требущая привилегий "чанопа" (подобно
                 MODE-сообщениям), должна вернуть подобную ошибку,
         показывая на безуспешность действий рядового пользователя.

       483     ERR_CANTKILLSERVER
                       ":You cant kill a server!"

               - Любые попытки использования KILL-команды на сервере
                 будут отклонены и эта ошибка вернется клиенту.

       491     ERR_NOOPERHOST
                       ":No O-lines for your host"

               - Если сервер не настроен на поддержку клиентского хоста
                 для сообщения OPER, клиенту будет возвращена эта ошибка.

       501     ERR_UMODEUNKNOWNFLAG
                       ":Unknown MODE flag"

               - Возвращается сервером, если MODE-сообщение не было
                 распознано.

       502     ERR_USERSDONTMATCH
                       ":Cant change mode for other users"

               - Ошибка отсылается любому пользоватею, пытающемуся
                 посмотреть или изменить режим какого-либо другого
                 пользователя.

6.2 Отклики команд

       300     RPL_NONE
                       Dummy reply number. Not used.

       302     RPL_USERHOST
                       ":[<reply>{<space><reply>}]"

               - Формат ответа, используемый командой USERHOST для списка
                 ответов к запрашиваемому списку. Строка ответа
                 представляет собой следующее:

                 <reply> ::= <nick>['*'] '=' <'+'|'-'><hostname>

                 '*' обозначает, что клиент зарегистрирован как
                 IRC-оператор. Символы '-' или '+' обозначает, что клиент
                 установил режим AWAY или не доступен.

       303     RPL_ISON
                       ":[<nick> {<space><nick>}]"

               - Формат ответа, используемый командой ISON для списка
                 ответов к запрашиваемому списку.

       301     RPL_AWAY
                       "<nick> :<away message>"

       305     RPL_UNAWAY
                       ":You are no longer marked as being away"
       306     RPL_NOWAWAY
                       ":You have been marked as being away"

               - Эти ответы используются с командой AWAY (если доступно).
                 RPL_AWAY отсылается любому клиенту, пославшему PRIVMSG
                 клиенту, который находит в состоянии AWAY. RPL_AWAY
                 отсылается только сервером, к котому присоединен клиент.
                 Ответы RPL_UNAWAY и RPL_NOWAWAY отправляются, когда
                 клиент удаляет или устанавливает режим AWAY.

       311     RPL_WHOISUSER
                       "<nick> <user> <host> * :<real name>"
       312     RPL_WHOISSERVER
                       "<nick> <server> :<server info>"
       313     RPL_WHOISOPERATOR
                       "<nick> :is an IRC operator"
       317     RPL_WHOISIDLE
                       "<nick> <integer> :seconds idle"
       318     RPL_ENDOFWHOIS
                       "<nick> :End of /WHOIS list"
       319     RPL_WHOISCHANNELS
                       "<nick> :{[@|+]<channel><space>}"

               - Ответы 311 - 313, 317 - 319 генерируются в ответ на
                 WHOIS-сообщение. Отвечающий сервер должен
                 формулировать каждый ответ числовым (если найден
                 запрашиваемый никнейм) или возвращать ERROR-ответ. '*' В
                 RPL_WHOISUSER не является маской, но буквенным символом.
                 Для каждого ответа установка, только RPL_WHOISCHANNELS
                 может казаться больше, тогда только (для длинных списков
                 имен каналов). '@' и '+' символы, указывающие какой
                 клиент является оператором канала или кому разрашается
                 говорить на модерируемом канале. RPL_ENDOFWHOIS
                 используется для пометки окончания WHOIS-сообщения.

       314     RPL_WHOWASUSER
                       "<nick> <user> <host> * :<real name>"
       369     RPL_ENDOFWHOWAS
                       "<nick> :End of WHOWAS"

               - Когда отвечают на WHOWAS-сообщения, сервер должен
                 использовать ответы RPL_WHOWASUSER, RPL_WHOISSERVER или
                 ERR_WASNISUCHNICK для каждого никнейма в указаном
                 списке. К концу всех пакетов ответов, может быть
                 RPL_ENDOFWHOWAS (только если будет один ответ или будет
                 являться ошибкой).

       321     RPL_LISTSTART
                       "Channel :Users  Name"
       322     RPL_LIST
                       "<channel> <# visible> :<topic>"
       323     RPL_LISTEND
                       ":End of /LIST"

               - Ответы RPL_LISTSTART, RPL_LIST, RPL_LISTEND помечают
                 начало текущих ответос с данными и конец серверных
                 ответов на команду LIST. Если недоступен ни один канал,
                 отправятся только начало и конец ответа.

       324     RPL_CHANNELMODEIS
                       "<channel> <mode> <mode params>"

       331     RPL_NOTOPIC
                       "<channel> :No topic is set"
       332     RPL_TOPIC
                       "<channel> :<topic>"

               - Когда отправляется TOPIC-сообщение, обозначающее топик
                 канала, отправиться должен один из двуъ ответов. Если
                 топик установлен, отсылается RPL_TOPIC. Иначе -
                 RPL_NOTOPIC.

       341     RPL_INVITING
                       "<channel> <nick>"

               - Возвращается сервером, обозначая что попытка
                 INVITE-сообщения была успешно выполнена по отношению к
                 приглашенному клиенту.

       342     RPL_SUMMONING
                       "<user> :Summoning user to IRC"

               - Возвращается сервером, отвечающего на SUMMON-сообщение
                 и обозначающего, что вызывается пользователь.

       351     RPL_VERSION
                       "<version>.<debuglevel> <server> :<comments>"

               - Ответ сервером, показывающий версию в подробностях.
                 <version> - версия программного обеспечения,
                 (включая все патчи) и <debuglevel> использующийся для
                 обозначения того, что сервер запущен "дебаг-режиме".

                 Поле "comments" может содержать любые комментарии о
                 версии и других подробностях.

       352     RPL_WHOREPLY
                       "<channel> <user> <host> <server> <nick> \
                        <H|G>[*][@|+] :<hopcount> <real name>"
       315     RPL_ENDOFWHO
                       "<name> :End of /WHO list"

               - RPL_WHOREPLY и RPL_ENDOFWHO пара, используемая для
                 ответа WHO-сообщения. RPL_WHOREPLY отсылается только
                 если предназначена подстановкой к WHO-запросу. Если
                 список параметров обеспечен WHO-сообщением, RPL_ENDOFWHO
                 должен отослаться после обработки каждого пункта
                 списка, начинающегося на <name>.

       353     RPL_NAMREPLY
                       "<channel> :[[@|+]<nick> [[@|+]<nick> [...]]]"
       366     RPL_ENDOFNAMES
                       "<channel> :End of /NAMES list"

               - Для ответа на NAMES-сообщения, пара ответов, содержащих
                 RPL_NAMEREPLY и RPL_ENDOFNAMES отправляются сервером
                 обратно к клиенту. Если запрашиваемый канал не найден,
                 возвращается RPL_ENDOFNAMES. Исключая то, когда
                 NAMES-сообщение отправлено без параметров, и все каналы
                 видимые с содержимым - возвращается серия
                 RPL_NAMEREPLY-сообщений с RPL_ENDOFNAMES, как пометкой
                 окончания.

       364     RPL_LINKS
                       "<mask> <server> :<hopcount> <server info>"
       365     RPL_ENDOFLINKS
                       "<mask> :End of /LINKS list"

               - В ответе на LINKS-сообщение, сервер должен отослать
                 ответы обратно, используя RPL_LINKS и пометкой конца
                 списка - RPL_INDOFREPLY.

       367     RPL_BANLIST
                       "<channel> <banid>"
       368     RPL_ENDOFBANLIST
                       "<channel> :End of channel ban list"

               - Когда создается список активных 'банов' для данного канал,
         сервер требует отправки списка обратно, используя
                 сообщения RPL_BANLIST и RPL_ENDOFBANLIST. Разделитель
                 RPL_BANLIST отсылается для каждого активного забаненного.
                 После того, как все забаненные попали в список (или если
                 отсутствуют), должен отослаться RPL_ENDOFBANLIST.

       371     RPL_INFO
                       ":<string>"
       374     RPL_ENDOFINFO
                       ":End of /INFO list"

               - Сервер, отвечая на INFO-сообщение требует отправления
                 всех этих 'info' в серии RPL_INFO-сообщений с
                 RPL_ENDOFINFO ответом, указывающем окончание ответов.

       375     RPL_MOTDSTART
                       ":- <server> Message of the day - "
       372     RPL_MOTD
                       ":- <text>"
       376     RPL_ENDOFMOTD
                       ":End of /MOTD command"

               - При ответе на MOTD-сообщение и MOTD-файл найден, файл
                 отбражается строка к строке с каждой строкой, не длше80
                 символов, используя RPL_MOTD-формат ответов. Их следует
                 разместить между RPL_MOTDSTART (перед RPL_MOTD) и
                 RPL_ENDOFMOTD (после).

       381     RPL_YOUREOPER
                       ":You are now an IRC operator"

               - RPL_YOUREOPER отправляется клиенту, который благополучно
                 выполнил OPER-сообщение и получил статус IRC-оператора.

       382     RPL_REHASHING
                       "<config file> :Rehashing"

               - Если использовалась функция REHASH и оператор послал
                 REHASH-сообщение, RPL_REHASHING отправилась обратно
                 оператору.

       391     RPL_TIME "<server> :<string showing server's local time>"

               - При ответе на TIME-сообщение, сервер должен отправить
                 ответ, используя RPL_TIME-формат. Строка, показывающая
                 время, должна содержать только правильный день и время.
                 Это не является допольнительным требованием к строке
         времени.

       392     RPL_USERSSTART
                       ":UserID   Terminal  Host"
       393     RPL_USERS
                       ":%-8s %-9s %-8s"
       394     RPL_ENDOFUSERS
                       ":End of users"
       395     RPL_NOUSERS
                       ":Nobody logged in"

               - Если USERS-сообщение обработано сервером, использовались
                 ответы RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS и
                 RPL_NOUSERS. RPL_USERSSTART должен отправится первым,
                 следуя за одним из RPL_USERS или одним RPL_NOUSER.
                 Следом идет RPL_ENDOFUSERS.

       200     RPL_TRACELINK
                       "Link <version & debug level> <destination> \
                        <next server>"
       201     RPL_TRACECONNECTING
                       "Try. <class> <server>"
       202     RPL_TRACEHANDSHAKE
                       "H.S. <class> <server>"
       203     RPL_TRACEUNKNOWN
                       "???? <class> [<client IP address in dot form>]"
       204     RPL_TRACEOPERATOR
                       "Oper <class> <nick>"
       205     RPL_TRACEUSER
                       "User <class> <nick>"
       206     RPL_TRACESERVER
                       "Serv <class> <int>S <int>C <server> \
                        <nick!user|*!*>@<host|server>"
       208     RPL_TRACENEWTYPE
                       "<newtype> 0 <client name>"
       261     RPL_TRACELOG
                       "File <logfile> <debug level>"

               - Все RPL_TRACE* возвращаются сервером в ответ на
                 TRACE-сообщение. Как много будет возвратов на
                 TRACE-сообщение зависит от того, посланы они
                 IRC-оператором или нет. Ответы RPL_TRACEUNKNOW,
                 RPL_TRACECONNECTING И RPL_TRACEHANDSHAKE используются
                 для соединений, которые не имеют полного разрешения и
                 неизвестны, попытки соединения, оканчивающиеся на
                 'server handshake'. RPL_TRACELINK посылается любым
                 сервером, который пропустил TRACE-сообщение и отправил
                 ее к следующему серверу. Список команд RPL_TRACELINK
                 отправится в ответ на TRACE-команду через всю IRC-сеть,
                 создавая карту серверных соединений. RPL_TRACENEWTYPE
                 будет использован для другого соединения, которое не
                 стыкуется с остальными категориями, но было отображено.

       211     RPL_STATSLINKINFO
                       "<linkname> <sendq> <sent messages> \
                        <sent bytes> <received messages> \
                        <received bytes> <time open>"
       212     RPL_STATSCOMMANDS
                       "<command> <count>"
       213     RPL_STATSCLINE
                       "C <host> * <name> <port> <class>"
       214     RPL_STATSNLINE
                       "N <host> * <name> <port> <class>"
       215     RPL_STATSILINE
                       "I <host> * <host> <port> <class>"
       216     RPL_STATSKLINE
                       "K <host> * <username> <port> <class>"
       218     RPL_STATSYLINE
                       "Y <class> <ping frequency> <connect \
                        frequency> <max sendq>"
       219     RPL_ENDOFSTATS
                       "<stats letter> :End of /STATS report"
       241     RPL_STATSLLINE
                       "L <hostmask> * <servername> <maxdepth>"
       242     RPL_STATSUPTIME
                       ":Server Up %d days %d:%02d:%02d"
       243     RPL_STATSOLINE
                       "O <hostmask> * <name>"
       244     RPL_STATSHLINE
                       "H <hostmask> * <servername>"

       221     RPL_UMODEIS
                       "<user mode string>"
                       - Для ответа запроса о режиме владельца клиенту,
                         RPL_UMODEIS отправляектся обратно.

       251     RPL_LUSERCLIENT
                       ":There are <integer> users and <integer> \
                        invisible on <integer> servers"
       252     RPL_LUSEROP
                       "<integer> :operator(s) online"
       253     RPL_LUSERUNKNOWN
                       "<integer> :unknown connection(s)"
       254     RPL_LUSERCHANNELS
                       "<integer> :channels formed"
       255     RPL_LUSERME
                       ":I have <integer> clients and <integer> \
                         servers"

                       - При обработке LUSERS-сообщения, сервер
                         отправляет настроки ответов от RPL_LUSERCLIENT,
                         RPL_LUSEROP, RPL_USERUNKNOWN, RPL_LUSERCHANNELS
             и RPL_LUSERME. При ответе, сервер должен
                         отослать обратно RPL_LUSERCLIENT и RPL_LUSERME.
                         Другие ответы отсылаются только если найдено их  
                         не нулевое значение.

       256     RPL_ADMINME
                       "<server> :Administrative info"
       257     RPL_ADMINLOC1
                       ":<admin info>"
       258     RPL_ADMINLOC2
                       ":<admin info>"
       259     RPL_ADMINEMAIL
                       ":<admin info>"

                       - При ответе на ADMIN-сообщение, сервер ожидает
                         использование ответов RPL_ADMINME через
             RPL_ADMINEMAIL и предоставляет текст сообщения с
                         каждым. Для RPL_ADMINLOC1 описывапется город,
                         шатат и страна сервера, следуемый подробностями
                         университета и факультета (RPL_ADMINLOC2) и
                         оканчивается административной связью для сервера
                         (здесь потребуется e-mail адрес) в RPL_ADMINEMAIL.

6.3 Зарезервированные числа

   Эти числа не описани, хотя они попадают в одну из следующих категорий:

       1. не долго в использовании;

       2. зарезервированы для последющего использования;

       3. используются в данный момент, но часть "прибамбасов" не
          генерируются текущим IRC-сервером.

       209     RPL_TRACECLASS          217     RPL_STATSQLINE
       231     RPL_SERVICEINFO         232     RPL_ENDOFSERVICES
       233     RPL_SERVICE             234     RPL_SERVLIST
       235     RPL_SERVLISTEND
       316     RPL_WHOISCHANOP         361     RPL_KILLDONE
       362     RPL_CLOSING             363     RPL_CLOSEEND
       373     RPL_INFOSTART           384     RPL_MYPORTIS
       466     ERR_YOUWILLBEBANNED     476     ERR_BADCHANMASK
       492     ERR_NOSERVICEHOST

7. ИДЕНТИФИКАЦИЯ КЛИЕНТА И СЕРВЕРА

  Клиенты и серверы используют одни и те же уровни идентификации. Для
  обоих это IP-номер имени хоста (и обратная проверка этого) это
  выполняется для всех соединений к серверу. Так же соединения
  проверяются парольно (если возможно установить пароль для этого
  соединения и он установлен). Их проверяют на всех возможных
  соединениях, хотя проверка пароля испольщуется только с серверами.

  В дополнение проверка отклика имени пользователя для созданных
  соединений. Поиск пользовательского имени на другом конце соединения,
  обычно включаются соединения, идентификация сервера подобна IDENT, или
  описана в RFC 1413.

  Есть мнение, что без паролей не так то легко достоверно определить, кто
  находится на другом конце сетевого соединения, использовать пароли очень
  рекомендуется в интер-сервер соединениях в дополнеение к другим
  возможностям идентификации сервера.

8. ПОДРОБНОЕ РАССМОТРЕНИЕ ТЕКУЩИХ СРЕДСТВ СВЯЗИ

  Текущей версией IRC-сервера, для рассмотрения этого протокола, является
  версия 2.8. Более ранние версии могут быть совместимы некоторыми или
  всеми командами, описанные в этом документе с NOTICE-сообщениями
  расположены многие числовые ответы. К несчастью, требуется обратная
  совместимость, предоставленные части этого документа различаются с
  выложенным. Отличия в:

       * определение, что любые LF или CR везде в сообщении помечают
         окончание этого сообщения (в отличие от требуемых CR-LF);

  Остаток этого раздела наиболее важен тем, кто желает держать сервер, но
  некоторые части так же напрямую связаны с клиентом.

8.1 Сетевой протокол TCP - почему его здесь лучше использовать

  IRC обеспечивается на высоте TCP, и TCP предоставляет надежный сетевой
  протокол, который наиболее хорошо вписывается в масштабы общения.
  Использование многослойность IP является альтернативой, но он не пока
  не получил широкого растространения и поддержки.

8.1.1 Поддержка Unix-сокетов

  Unix-domain-сокетам доступны операции прослушивания/соединения, в
  текущем исполнении может быть настроена на прослушивание и
  подтверждение как клиентских, так и серверных соединений на
  Unix-domain-сокете. Их узнают как сокеты, где имя хоста начинается с '/'.

  Когда предоставление любой информации о соединениях на
  Unix-domain-сокете, сервер требует вытеснения текущего имени хоста в
  пути, если текущее имя сокета будет этого просить.

8.2 Проверка команд

  В предоставление полезной 'non-buffered' сети IO для клиентов и
  серверов, каждое соединение из которых является частным 'input buffer',
  в котором результируются большинство полученного, читается и
  проверяется. Размер буфера 512 байт, используется как одно полное
  сообщение, хотя обычно оно бывает с разными командам. Приватный буфер
  проверяется после каждой операции чтения на правильность сообщений.
  Когда распределение с многослойными сообщениями от одного клиента в
  буфере, следует быть в качестве одного случившегося, клиент может быть
  'удален'.

8.3 Передача сообщения

  Это простой поиск сети, насыщенной линками или хостами, к которым вы
  отправляете данные. Хотя Unix обычно это делает через TCP-окно и
  внутренними буферами, часто сервер имеет большое количество данных,
  готовых к отправке (особенно при формировании нового сервер-сервер
  линка) и небольших буферов в ядре не хватает для исходящей очереди.
 
  Для облегчения этой проблемы, "send queue" использует как FIFO-очередь
  для пересылки данных. Обычно, "send queue" может возрастать до 200 кб
  в большой IRC-сети с медленным сетевым соединением при соединении
  нового сервера.

  Когда они начинают соединяться, сервер первым читает и проверяет все
  входящие данные, откладывая все исходящие данные. Когда все доступные
  вводы обработаны, посылаются отложенные данные. Это понижение числа
  write() системных звонков и помогает TCP создавать большие пакеты.

8.4 Соединение 'Liveness'

  Для выявления прекращения соединения или отклика, сервер должен
  пинговать каждое из соединений.

  Если соединение не отвечает некоторое время, это соединение
  закрывается, используя предназначенные для этого процедуры. Так же
  соединение может оборваться, если отправлено сверх обозначенного
  максимума, ибо это наилучщий выход при медленном соединении.

8.5 Установка соединения сервер-клиент

  При соединении с IRC-сервером, клиенту посылается MOTD (если
  присутствует), а так же текущее число серверов/клиентов (подобно
  команде LUSER). Так же сервер требует сообщения к клиенту, которое
  содержит имя и версию, как и любые другие сообщения-вступления.

  После разделения с этим, сервер должен отправить наружу новый никнейм
  пользователя и другой информации, как снабжение себя (команда USER) и
  как открываюший сервер (из DNS/серверы идентификации). Сервер должен
  послать эту информацию с NICK первым следующим USER.

8.6 Установка соединения сервер-сервер

  Процесс установки соединения сервер-к-серверу чреват опасностью с тех
  пор, как много возможных областей, где возникают проблемы - наименьшие
  из которых - конфликтные ситуации.

  После соединения сервера, следуя PASS/SERVER, которыми
  При соединении, сервера обмениваются парами PASS/SERVER, с помощью
  которых устанавливаются парольные линки. С помощью этих же команд и их
  ответов, сервера обмениваются информацией о соединении, которая описана
  ниже.

  При инициализировании серверных запросов пары PASS/SERVER, так же
  проверярся, что сервер должным образом отвечает на идентификацию перед
  подтверждением соединения (проверяется для того, чтобы убедиться в том,
  что это действительно сервер).

8.6.1 Обмен информацией о состоянии соединения

  Информацию необходимо будет разделить между  серверами. Преимущества
  следущие:

       * все знают другие сервера;

       * все знают пользовательскую информацию;

       * все знают информацию каналов.

  Информация которой располагают сервера, пересылается SERVER-сообщениями,
  пользовательская информация с сообщениями NICK/USER/MODE/JOIN и с
  каналов (MODE-сообщения).

  ЗАМЕЧАНИЕ: топики канала *НЕ* обмениваются здесь. потому что команда
  TOPIC перезапишет всю остальную информацию о топиках, это хорошо при
  двухстороннем соединении и обмене топиками.

  Прохождением информации о серверах первой, любые конфликты с серверами,
  которые уже существуют, занимая место перед никнеймом, могут
  происходить только всвязи со специфичностью никнейма, находящегося на
  втором сервере. IRC-сеть только будучи к существующему, как
  нециклический график; это может быть возможно, что сеть уже
  переподсоединилась в другом месте, где происходит конфликт, показывая
  сети необходимость в разрыве.

8.7 Разрыв соединения сервер-клиент

  Когда клиет закрывает соединение, создается QUIT-сообщение от имени
  клиента сервером, к которому присоединен клиент. Не используется и не
  создается никакое другое сообщение.

8.8 Разрыв соединения сервер-сервер

  При закрытии соединения сервер-сервер, и тот и другой удаленно создают
  SQUIT или 'натуральные' причины закрытия соединения с IRC-сетью,
  которые должны быть известны всем серверам. Для этого сервер отсылает
  список SQUIT'ов (по одному на каждый сервер, имеющий соединение с ним)
  и список QUIT'ов (снова, по одному для каждого клиента, соединенных
  с ним).

8.9 Слежение за изменениями никнейма

  Все IRC-сервера требуют хранение истории последних изменений никнейма.
  Это требование предоставляет серверу шанс предоставить нетронутую
  информацию по изменениями никнейма при возникновении конфликтов с
  командами управления им. Команды, которые должны фиксировать изменения
  никнейма.

       * KILL (прибитие никнейма)

       * MODE (+/- o,v)

       * KICK (кик никнейма)

  Остальные команды не проверяют изменения никнейма.

  В упомянутых случаях, сервер требует, во-первых, проверку на наличие
  никнейма, тогда проверяется его история, смотря кому этот никнейме
  принадлежит в данный момент. Это уменьшает шансы возникновения
  конфликтов, но они могут встретиться на сервере, упомянутые по ошибке
  клиентом. При выполнении изменения дается некий отрезок времени,
  которые дает возможность игнорировать более старые.

  Для умеренной истории, серверу следует хранить предыдущие никнеймы для
  каждого известного ему клиента, если они все решатся их изменить. Этот
  обьем ограничен другими факторами (такие как обьем памяти и тому
  подобное).

8.10 Flood-контроль клиентов

  В больших сетях соединенных между собой IRC-серверов, действительно
  легко для любого клиента, присоединенного к сети, обеспечивать
  непрерывный потоксообщений, как результат не только сетевого флуда,
  но так же и ухудшение работы сервисов. Лучше чем требовать от каждой
  `жертву' защиты самих себя, флуд-защита была встроена в сервер и
  добавлена к сервисам, доступных всем клиентам. Текущий алгоритм таков:

       * проверка клиентского `таймера сообщений', если он отстает от
         текущего времени - подкорректировать;

       * чтение любых данных, поступающих с клиента;

       * пока таймер опережает текущее время меньше, чем на десять
         секунд, - проверять любые сообщения с клиента и штрафовать
         клиента по две секунды за каждое сообщение;

  который, в сущности, разрешает клиенту посылать одно сообщение
  каждые две секунды без каких-либо последствий.

8.11 Non-blocking lookups

  В окружении реального времени, необходимо чтобы сервер мог делать как
  можно меньшие остановки для того, чтобы все клиенты обслуживались в
  равной мере. Очевидно, этот асинхронный IO работает во всех сетевых
  операциях чтения\записи. Для нормальных серверных соединений, это было
  не трудно, но здесь другая поддержка операций, что может статть
  причиной блокирования сервера (подобно чтениям диска). Это возможно,
  подобно активации, следующей быть выполненной с коротким перерывом.

8.11.1 Hostname (DNS) lookups

  Использование стандартных resolver-библиотек от Berkeley и другие,
  имеющие предназначение больших задержек в некоторых случаях, где ответы
  имеют перерывы. Во избежение этого, разделяют уставноленные
  DNS-шаблоны, которые настраивают для асинхронных операций ввода\вывода
  (IO) и тогда вызывается внутренняя IO-петля главного сервера.

8.11.2 Username (Ident) lookups

  Хотя эти многочисленные ident-библиотеки существуют для использования и
  включения в другие программы, они являются причинами проблем, с тех пор
  как они работают в синхронном режиме и выводят результат в обычных
  задержках. Вновь разрешение записано установкой шаблонов, которые будет
  обьединяться с неподвижностью сервера и работать, используя асинхронный
  ввод\вывод.

8.12 Конфигурационный файл

  Предоставляя гибкость настройки и запуска сервера, рекомендуется
  исползовать конфигурационный файл, который содержит инструкции к
  серверу на следующие темы:

       * с каких хостов допускать соединения клиентов;

       * с каких хостов допускать серверные соединения;

       * с какими хостами соединяться (как активно, так и пассивно);

       * иформация о нахождении сервера (университет, город/район,
         компания и тому подобное);

       * кто отвечает за сервер и е-мейл адрес, по которому можно
         связаться с администратором;

       * имена хостов и пароли для клиентов, которые хотят получить
         доступ к командам IRC-операторов.

  В указании имен хостов, следует указывать как имена доменов, так и
  использовать 'точечную' запись (127.0.0.1). Это дает возможность
  указания пароля, используемого/подтверждаемого все входящие и исходящие
  соединения (хотя, на другие серверы используются только исходящие
  соедения).

  Выше есть список минимальных требований для любого сервера, который
  желает создать соединение с каким-либо другим сервером. Остальные
  пункты, которые могут быть использованы:

       * указание, каким серверам можно присоединяться;

       * глубина серверного дерева, разрешенного на доступ;

       * часы, в которые могут присоединяться клиенты.

8.12.1 Допуск клиентов к соединению

  Серверу следует использовать некую сортировку 'списка контроля допуска'
  (или в конфигурационном файле, или еще где), который читается при
  загрузке и используется для приятия решения о том, могут или нет хосты
  клиентов использовать его для соединения.

  'Запрет', как и 'разрешение' следует предоставлять для более гибкого
  контроля доступа хоста.

8.12.2 Операторы

  Предоставление привилегий оператору для уничтожения пользователя может
  иметь ужасные последствия для благополучия IRC-сети. В следствии чего
  возникают трения. В текущей настройке требуется два 'пароля', один из
  которых отгадывается весьмо просто. Хранение IRC-операторских паролей в
  конфигурационных файлах предпочительно в хорошо закодированном виде
  (например, использование crypt(3) из Unix), предотвращая легкое
  похищение.

8.12.3 Допуск серверов к соединению

  Взаимное соединение серверов не имеет тривиального значения: плохое
  соединение может быть вызвано большим столкновением на usefulness of
  IRC. Таким образом, каждому серверу следует имет список серверовв, к
  которым он может присоединиться и тех, кто может присоединиться к нему.
  Под безцеремонностью следует понимать сервер, доступный к соединению с
  произвольным хостом, как с сервером. В дополнение ко всему этому,
  серверы могут присоединяться или не присоединяться, и вследствии этого
  предпочительней хранить пароль и другие характеристики на линка в
  конфигурационном файле.

8.12.4 Административная часть

  Для предоставления верных и правильных отклиеов на ADMIN-команды (см.
  раздел 4.3.7), сервер следует на обеспечить нужными подробностями в
  конфигурации.

8.13 Формирование сообществ

  Текущий сервер предоставляет любому зарегистрированному локальному
  пользователю зайти на не более 10 различных каналов. Это не ограничение
  на не-локальных пользователей, а скорей предпочтение, для формирования
  неких сообществ, которые находятся на определенных каналах.

9. ТЕКУЩИЕ ПРОБЛЕМЫ

 Число известных проблем с этим протоколом, все из которых надеются быть
 решенными в ближайщее время, в ближайшем будущем будет переписано. В
 данный момент, идет работа по разрешению этих проблем.

9.1 Расширение

  В расширенном распознании этот протокол бывает не достаточно хорош.
  Основная проблема происходит от требования, чтобы все сервера знали обо
  всех остальных серверах, и пользователи; и что информация, относительно
  их, будет обновляться по мере ее изменения. Желательно, так же, хранить
  число серверов доступно для того, чтобы расстояние между двумя точками
  сохранялась минимальной и дерево ветвилось как можно сильней.

9.2 Имена

  В данный момент, протокол IRC имеет три типа имени: никнейм, имя
  канала и имя сервера. Каждый из них имеет свой домен и не пересекается
  друг с другом. Так же, для пользователей возможен выбор любого из трех
  имен, не вызывая возражений. Для расширения распознавания требуется
  переработка, с намерением для уникальности имен для каналов и
  никнеймов, чтобы предотвратить нежелателные столкновения, так же как и
  растворение доступа к циклическому дереву.

9.2.1 Никнеймы

  Идея никнеймов в IRC очень удобна для пользователей в использовании при
  общении с любым на другом конце канала. Но только ограничение размера
  никнейма увеличивает шансы попытки испаользования одного никнейма
  разными людьми. Если такое происходит, то каждый из этих людей
  становится под угрозой KILL (4.6.1).

9.2.2 Каналы

  Требования к текущему каналу всего лишь, чтоб все сервера знали о всех
  каналах, их место расположения и настройки. Конфликты каналов
  обьясняются как тем же случаем (так и людей, кто создал новый канал,
  рассматривают как членов канала), подобно которому возникают конфликты
  по поводу использования никнеймов.
 
9.2.3 Серверы

  Хотя число серверов, обычно, намного меньше числа пользователей или
  каналов, их требования будут известны всем.

9.3 Алгоритмы

  В некотрых местах серверного кода, не возможно отклониться от N^2
  алгоритмов, подобных проверке списка каналов установки клиентов.

  В текущих версиях сервера отсутствуют проверки базы данных на
  содержимое, каждый сервер отвечает за корректность информации соседнего
  сервера. Это открытые двери к большим проблемам, если присоединенный
  сервер содержит ошибки или наоборот пытается противоречить каким-либо
  сетевым правилам и установкам.

  В данном случае, потому что недостаток уникальных внутренних и
  глобальных имен является многогранным камнем преткновения. Конфликты
  возникают, главным образом, из-за проблемы захвата времени для ответных
  сообщений и еффекта IRC-сети. Как раз изменением уникальных имен и
  решаются проблемы с командами настроек канала.

10. ПОДДЕРЖКА И ДОСТУП

          Листы подписки:
               Будущее протокола: ircd-three-request@eff.org
               Общие обсуждения: operlist-request@eff.org

          Программное обеспечение:
               cs.bu.edu:/irc
               nic.funet.fi:/pub/irc
               coombs.anu.edu.au:/pub/irc

          Newsgroup: alt.irc

11. РАССМОТРЕНИЕ БЕЗОПАСНОСТИ

  Безопасность обсуждалась в разделах 4.1, 4.1.1, 4.1.3, 5.5, и 7.

12. АДРЕСА АВТОРОВ

  Jarkko Oikarinen
  Tuirantie 17 as 9
  90500 OULU
  FINLAND

  Email: jto@tolsun.oulu.fi


  Darren Reed
  4 Pateman Street
  Watsonia, Victoria 3087
  Australia

  Email: avalon@coombs.anu.edu.au


перевод: vadim s. sabinich http://sabinich-translate.blogspot.com





Хостинг HOST-FOOD

2014-07-27, lissyara
gmirror

Удалённое создание софтверного зеркала средствами gmirror, на диске разбитом с использованием gpart. Использование меток дисков для монтирования разделов.
2013-08-20, zentarim
Scan+Print server FreeBSD 9

Настройка сервера печати и сервера сканирования под управлением операционной системы FreebSD 9 для МФУ Canon PIXMA MP540
2011-11-20, BlackCat
Разъём на WiFi-карту

Делаем съёмной несъёмную антену на WiFi-карте путём установки ВЧ-разъёма
2011-09-14, manefesto
Настройка git+gitosis

Настройка системы контроля версия исходного кода в связке git+gitosis+ssh
2011-08-14, zentarim
Wi-FI роутер + DHCP + DNS

Настройка Wi-Fi роутера на Freebsd 8 + DNS сервер + DHCP сервер: чтобы Wi-Fi клиенты были в одной подсети с проводными, проводные и беспроводные клиенты получали адреса автоматически по DHCP, кэширующ
2011-06-15, -ZG-
Охранная система на FreeBSD+LPT

В этой статье описана попытка реализации простой охранной системы на базе FreeBSD с подключением к ней охранных устройтсв на LPT порт и видеорегистрацией.
2011-03-13, terminus
ng_nat

Описание работы ng_nat, практическое использование, достоинства и недостатки в сравнении с ipfw nat
2011-02-20, Капитан
Nagios+Digitemp

Статья описывает создание системы оповещения о превышении температуры в специальных помещениях на основе Nagios с использованием программы Digitemp.
2011-02-17, Le1
Zyxel Configuration

Скрипт для массового изменения конфига свичей Zyxel. Берет из файла iplist список ip-шек, заходит последовательно на каждый и выполняет комманды из файла commands, записывая происходящее в лог файл.
2011-02-16, fox
hast carp zfs ucarp cluster

HAST (Highly Available Storage), CARP, UCARP, ZFS, Cluster настройка и одаптация плюс личные размышления…
2011-02-04, BlackCat
Восстановление ZFS

История о том, как был восстановлен развалившийся RAIDZ ZFS-пул (перешедший в FAULTED) с помощью скотча и подручных средств. Или о том, какие приключения ожидают тех, кто не делает резервных копий.
2011-02-03, Капитан
1-Wire

Статья описывает самостоятельное изготовление контроллера DS9097 для съёма показаний с датчиков температуры DS1820 с помощью программы Digitemp.
2011-01-28, Капитан
Температура в серверной

Статья описывает построение системы наблюдения за температурой в помещении серверной с использованием программы Digitemp и выводом графиков в MRTG
2011-01-21, m4rkell
Syslog server

Как то буквально на днях, у нас завалилось, что то в еве) или не в еве не суть. Суть в том, что когда захотели снять логи с хостов esx обнаружили, что хранят эти негодяи логии только за последнии сутк
2011-01-11, Fomalhaut
cvs, svn, portsnap

Обновление сорцов системы через CVS и SVN, портов - CVS и portsnap. Обновление через Proxy-сервер.
2011-01-07, lissyara
Canon/gphotofs

Монтирование цифровых фотоаппаратов Canon (PTP) как файловой системы, автоматизация этого процесса через события devd и внешние скрипты.
2010-12-13, Al
IPSec

Описание принципов работы IPSEC и способов аутентификации.
2010-12-07, manefesto
FreeBSD on flash

Было принято решении переехать на USB Flash и установить минимальный джентельменский набор для работы своего роутера. Делаем =)
2010-12-05, Fomalhaut
root ZFS, GPT

Инструкция по установке FreeBSD с использованием в качестве таблицы разделов GPT и в качестве основной файловой системы - ZFS
2010-09-05, Cancer
Настройка аудиоплеера на ximp3

Цели: Простенький аудиоплеер, для того что бы тетя продавец в магазине утром пришла нажала на кнопку Power и заиграла в зале музыка, так же был доступ по сети, общая шара куда можно заливать музыку, к
2010-08-31, Cancer
Установка и настройка OpenVPN

На днях появилась задача - объединить головной офис и 3 филиала в одну сеть через интернет посредством OpenVPN, чтобы люди могли подключаться через RDP к базам 1С на серверах.
2010-08-25, manefesto
freebsd lvm

Использование linux_lvm для работы с LVM разделами из-под FreeBSD. Проблемы которые возники при монтирование lvm раздела
2010-04-30, gonzo111
proftpd file auth&quota

Proftpd - квоты и авторизация из файлов, без использования базы данных и/или системных пользователей
2010-04-22, lissyara
tw_cli

Пошаговая инструкция по восстановлению RAID на контроллере 3ware, из которого выпал один диск. Настройка мониторинга состояния рейда и отчётов о его состоянии на email.
2010-04-14, fox
MySQL Master+Master

MySQL (Master Master) and (Master Slave) Как настроить репликацию…
2010-03-22, Mufanu
named 9.7.0

Система доменных имен (Domain Name Service, DNS) - одна из тех незаметных, закулисных программ, которым не уделяется и половины того внимания, которого они заслуживают.
2010-03-09, terminus
DNS zones

Краткий ликбез про управление DNS зонами. Примеры проведения делегирования прямых и обратных DNS зон.
2010-03-09, aspera
Squid+AD (group access)

Настройка прокси сервера SQUID с автроризацией пользователей в AD. Разделение пользователей на группы
2010-03-02, BlackCat
Шлюз: Часть 4

Настройка дополнительных сервисов: синхронизация времени (OpenNTPD), клиент DynDNS.org.
2010-03-01, BlackCat
Шлюз: Часть 3

Настройка DHCP и DNS серверов для работы внутри частной сети, c поддержкой внутренних (частных зон) DNS, а так же интеграция DHCP и DNS сервисов.
2010-03-01, BlackCat
Шлюз: Часть 2

Конфигурация МСЭ pf для проброса портов с изменением порта назначения и без, а так же поддержки активного режима FTP и ограничения максимального размера сегмента
2010-03-01, BlackCat
Шлюз: Часть 1

Быстрая настройка шлюза/маршрутизатора с установлением PPPoE-соединения, поддержкой NAT и DNS-forwarding.
2010-02-23, Morty
darkstat

Простая считалка траффика, со встроенным веб-сервером. Очень маленькая, может делать отчеты трафика по хостам, портам, протоколам, а также строить графики
2010-01-23, gonzo111
squid+sams+sqstat

Пилим squid и sams - примеры конфигов с объяснениями. Установка SqStat.
2009-12-19, schizoid
mpd5 + radius + ng_car + Abills

Настройка pppoe-сервера с биллинговой системой Abills и шейпером ng_car
2009-11-16, lissyara
UFS->ZFS

Удалённая миграция с UFS на ZFS. Загрузка с раздела zfs. Настройка для работы с малым количеством памяти под архитектурой i386.
2009-11-13, gx_ua
fusefs-ntfs

Установка, настройка и использование fusefs-ntfs, драйвер NTFS, предназанченного для монтирования NTFS разделов под FreeBSD
2009-11-12, Morty
LiveCD

Создание собственного LiveCD с необходимыми вам изменениями, автоматизирование данного процесса, а так же вариант скоростной сборки СД.
2009-09-27, lissyara
Samba как PDC

Контроллер домена - аналог M$ NT4 домена под самбой, без использования LDAP и прочей хиромантии. Просто и быстро =)
2009-08-30, terminus
ipfw nat

Подробное руководство по ipfw nat, сложные случаи конфигурации.
2009-08-24, levantuev
HotSpot

Установка Hotspot системы в общественное заведение.
2009-08-18, lissyara
diskless

Создание бездисковых терминалов под управлением FreeBSD - с загрузкой по сети. Используются для старта rdesktop и подключения к виндовому серверу терминалов.
2009-07-29, BAV_Lug
Видеонаблюдение

Настройка бюджетного варианта видеонаблюдения на удаленном объекте
2009-07-22, Cancer
OpenLDAP адресная книга

Настройка и создание адресной книги на базе OpenLDAP + phpLDAPadmin
2009-06-30, SergeySL
AimSniff

Руководство по созданию системы мониторинга ICQ-переписки на базе AimSniff, использующей базу данных MySQL для хранения и Web-интерфейс WAS (Web Aim Sniff) для просмотра перехваченных сообщений
2009-06-25, atrium
Управление правами доступа

Полномочия пользователей и файлов, принадлежащих им, формирует концепцию ОС UNIX.
2009-06-16, DNK
Exim+PgSQL

Установка почтовой системы exim+pgsql на FreeBSD 7.1
2009-05-30, mvalery
HDD(mbr) -> HDD(gpt)

Как разбить диск размером более 2TB на разделы, сделать загрузочным, а затем перенести на него информацию с рабочей системы — донора.
2009-05-22, Cancer
SendXMPP

Отправка сообщений на Джаббер сервер по средствам SendXMPP
2009-05-11, Raven2000
Network UPS Tools

Network UPS Tools представляет собой набор программ, которые обеспечивают общий интерфейс для мониторинга и администрирование UPS оборудования.
2009-04-29, m0ps
IPSEC over GRE with RIP

Пример IPSEC over GRE и динамическим роутингом (RIP), с ADSL в качестве последней мили на оборудовании Cisco.
2009-04-24, WhiteBear777
qemu network

Появилась необходимость поставить на БСД эмулятор(qemu) и настроить в качестве гостевой ОС Windows XP, предоставив ей выход в локалку и в сеть internet...
2009-04-22, vp
freebsd + huawei 162 gsm modem

В статье описывается простой способ подключения модема huawei 162 к freebsd + первичная настройка smstools
2009-04-12, mvalery
Мониторинг RAID

Мониторинг из командной строки RAID компаний AMCC 3ware, HighPoint, Dell (Perc 5/i и PERC 6/i) и LSI (MegaRAID SAS 8408E и SAS1078)
2009-04-09, texnotronic
RAID1 via LAN

Функциональности DRBD во FreeBSD можно добиться примонтировав блочное устройство по сети при помощи GEOM Gate (ggate) и добавив его в зеркало с локальным диском средствами gmirror.
2009-04-03, Raven2000
Оптимизация хоста для CMS

В последнее время на старый и не очень быстрый ПК (Celeron 800 RAM 256) мною было навешано с десяток сайтов и некоторые были из серии тяжелых CMS. И так нам дано FreeBSD 7.1 и ~10 сайтов/CMS.
2009-04-01, atrium
VSFTPD + AD && MySQL

Настройка самого безопасного сервера FTP - vsftpd.
2009-03-31, Dron
Peoplenet + C-motech (3G)

Описание подключения к сети Peoplenet посредством 3G модема С-motech CCu-650U на FreeBSD
2009-03-25, lissyara
mod_auth_external

mod_auth_external - авторизация пользователей в apache c помощью внешней программы - например, системных пользователей.
2009-03-24, gx_ua
Lightsquid

Частично lightsquid может заменить sams: быстрая и простая инсталляция, быстрый парсер, cgi скрипт для динамической генерации отчета, нет привязки к БД, различные графические отчеты, мультиязычный инт
2009-03-18, LHC
Установка Zabbix-1.6

Установка и первоначальная настройка системы мониторинга Zabbix (версия 1.6)
2009-03-16, Cancer
Принт-Сервер Samba+LPD & AD

Простейшая настройка Принт-Сервера на FreeBSD используя Samba+LPD & AD
2009-03-04, Mad_caterpillar
ipsec_vpnc

Настройка VPN IPSec концентратора на FreeBSD 6.2 для клиента cisco с использованием ipsec-tools и авторизацией в активной директории
2009-02-18, Andy
Free-SA

Программа анализирует log файлы Squid'а и формирует по ним отчет.
2009-02-02, Cancer
Openfire Jabber Server

Установка Jabber сервера на примере Openfire
2009-01-28, Cancer
mpd5 + сжатие и шифрование

Установка VPN сервера mpd5 + сжатие и шифрование
2009-01-26, vp
freebsd + webcamera

Подключение и настройка вебмкамеры для работы с freebsd на примере Logitech QCam STX
2009-01-10, Grishun_U_S
конфиг для офисов

В статье разбирается конфиг для офиса, пользователи которого имеют строгие ограничения по портам. Заворачиваем www трафик на транспарентный прокси, а остальное NAT'им. Эффективно делим канал интернет
2008-12-27, Storoge
sftp+chroot

Возникла необходимость дать возможность нескольким пользователям заливать на сервер контент для своих сайтов через sftp, чтобы при этом не страдала безопасность.
2008-12-13, Morty
PurefFTPd

Администрирование pureftpd-сервера с помощью вэб интерфейса Usermanager
2008-12-11, lissyara
termlog

Небольшая простая утилита, использующаяся для записи в файл всего что происходит на терминалах системы. Полезно, когда есть доступ по ssh у тех, кому не очень доверяете. Паранойя - это не плохо =)
2008-11-26, Cancer
SQUID+SAMS +Rejik-(ADLDAP)

Установка Прокси сервера SQUID с красивой мордой SAMS и редиректором REJIK,для учета кто куда ходил + графики в pdf,РЕЖИК собственно рубит банеры и запрещает пользователям ходить на запрещенные сайты,
2008-11-22, dvg_lab
php5-oci8

Решение проблем segmentation fault (core dumped) при работе с oracle8-client и php5-oci8
2008-11-21, m0ps
NTP

Пример настройки NTP сервера для локальной сети и клиента, для синхронизации времени с локальный NTP сервером. Обновление ntpd из портов.
2008-11-20, Cancer
SQUID+SAMS +Rejik-(NTLM)

Установка Прокси сервера SQUID с аутентификацией по NTL с красивой мордой SAMS и редиректором REJIK,для учета кто куда ходил + графики в pdf, РЕЖИК собственно рубит банеры и запрещает пользователям хо
2008-11-20, UA
Hotspot

Настройка безпроводной точки доступа (WiFi) на freebsd
2008-11-12, Shaman
Enemy Territory

Появилась у меня такое желание поднять сервер Enemy Territory. Поискал погуглил, ничего толкового не нашел пришлось все самому делать. И вот решил поделиться опытом. Начинаем......
2008-11-11, lissyara
Samba+ NT ACL

Использование vfs самбы - модули full_audit и recycle. Настройка для использования в качестве файлопомойки с 500+ одновременно работающих юзеров. Раздача прав через нативный виндовый интерфейс.
2008-11-11, Raven2000
Upgrading OpenBSD

Сегодня мы будем обновлять OpenBSD. Систему необходимо поддерживать в актуальном виде и следить, чтобы все работало, как часы и все дырки были залатаны до прихода врага =)
2008-11-10, lexy
SMSTools 3

Как автоматизировать отправку и обработку входящих сообщений при помощи мобильного телефона, датакабеля и компа
2008-11-06, Cancer
Asterisk IP PBX

Установка VoiP сервера Asterisk IP PBX для соединения двух шлюзов и АТС
2008-10-30, atrium
Samba & CUPS & AD & ACL

Настройка Samba в роли доменного файл-сервера, и CUPS в роли принт-сервера для Windows клиентов
2008-10-17, Raven2000
src & ports

Конечно, в OpenBSD система портов никогда не сможет быть полной сравнение с той же системой во FreeBSD. Связано это с тем, что разработчики включают в порты лишь те приложение которые протестированн
2008-10-13, Morty
Mysql - базовое описание

Базовое описание и принципы работы с MySQL
2008-10-10, Cancer
exim&dovecot + fetchmail + SSL

Exim & Dovecot + Postfixadmin & Roundcube + Fetchmail & smtp_relay С возможностью отправлять письма через смтп релей провайдера. С использование SSL шифрование: POP3s IMAPs sSMTP
2008-10-09, m0ps
Дополнительные порты для роутера

Увеличение количества Ethernet портов маршрутизатора за счет свободных портов коммутатора пробросив vlan с сабинтерфейса роутера на интерфейс коммутатора.
2008-10-06, princeps
Bacula

Настройка сервера системы резервного копирования Bacula на FreeBSD для бэкапов FreeBSD и Windows машин
2008-10-02, zheromo
Postfix + DBMail

Создание почтовой системы на основе Postfix + DBMail + SASL2 + TLS + DSpam + ClamAV + RoundCubeWebMail
2008-10-02, Cancer
SugarForge CRM

SugarForge CRM предоставляет подавляющее большинство функциональных возможностей CRM систем
2008-09-12, arksu
ng_ipacct + squid

Подсчет трафика с помощью ng_ipacct. Связка ng_ipacct + squid + парсер логов + авторизатор + nginx + mysql и куча служебных скриптов для работы всей системы.
2008-09-03, Raven2000
GLPI

Мне надо было найти замену существующей программы инвентаризации, чтобы за компьютерами, принтерами, картриджами, лицензиями и тп был учет. Желательно с дополнительными бонусами типа системы подачи...
2008-09-03, salimk
POWERDNS

Статья о том как мигрировать с DNS сетвера ISC Bind на POWERDNS
2008-09-03, DNK
Rinetd

Редирект TCP портов с помощью утилиты rinetd - просто до безобразия - само прилодение простое, конфиг в одну строчку - что ещё надо для счастья? =)
2008-09-03, L!Ner
eGroupWare

Это сервер групповой работы. Он укомплектован собственным веб-интерфейсом, который обеспечивает доступ к вашим данным с любой платформы по всей планете.
2008-08-30, jafff
MAC адрес

У девайса VoIP Planet VIP-000 слетел MAC адрес и стал FF-FF-FF-FF-FF-FF, как я его востанавливал
2008-08-30, Morty
clonehdd

Перенесение, бэкапирование HDD,легко и просто
2008-07-31, Raven2000
Proxy Auto Configuration

Возникла необходимость автоматически настраивать прокси для всех компов и не бегать например если поменялось что-то на сервере прокси. Для этого давно существует технология Proxy Auto Configuration.
2008-07-29, f0s
NNTP сервер

Конфигурирование собственного NNTP-сервера.
2008-07-28, Al
spamooborona

настройка yandex spamooborona в качестве smtp-proxy для работы с exim
2008-07-28, Cancer
SQUID+SAMS +Rejik-(NCSA)

Установка Прокси сервера SQUID с красивой мордой SAMS и редиректором REJIK,для учета кто куда ходил + графики в pdf,РЕЖИК собственно рубит банеры и запрещает пользователям ходить на запрещенные сайты,
2008-07-20, Raven2000
Pax

Эта замечательная утилита поставляется с FreeBSD по умолчанию, и она имеет неплохой потенциал. Можно создавать архивы модифицировать их, а так же живьем переносить всю операционную систему с данными
2008-07-16, Andy2k
BIND & AD

Настройка BIND для обслуживания запросов контроллеров Active Directory. Альтернатива поднятию DNS от Microsoft.
2008-07-16, aleksey.kravchenko
Samba (PDC+BDC)

Поднять главный (офис) и резервный (филиал) контроллер домена на базе Samba и OpenLDAP, организовать синхронизацию и репликацию между ними. Запись в LDAP должена выполняться только на PDC.
2008-07-14, aleksey.kravchenko
OpenVPN + LDAP

Статья о том, как настроить OpenVPN с авторизацией пользователей в OpenLDAP.
2008-07-14, aleksey.kravchenko
ProFTPd + LDAP

ProFTPd с авторизацией пользователей в OpenLDAP
2008-07-13, lissyara
Asus Eee PC

Дали на несколько дней поиграться Asus Eee PC - мелкий ноутбок по смешной цене. Ну, первым делом ставим правильный ОС и смотрим - что из этого получиться.
2008-07-09, terminus
DNS сервер Unbound

Установка и настройка кеширующего DNS сервера Unbound под управлением FreeBSD 7.0
2008-07-08, f0s
mozilla autoconfig

Автонастройка браузера и почты Mozilla Seamonkey пользователям
2008-07-05, lissyara
iftop

Утилита предназначена для мониторинга загрузки канала в режиме реального времени - позволяет видеть кто именно занял полосу. Полезно для организаций с FreeBSD на шлюзовой машине.
2008-07-02, manefesto
snd_hda

Патчим snd_hda для корректной работы с наушниками
2008-06-27, Grishun_U_S
dd : бэкапируем windows

Клонирование разделов windows с помощью загрузочного диска FreeBSD
2008-06-25, terminus
DNS сервер NSD

Установка и настройка авторитарного DNS сервера NSD под управлением FreeBSD 7.0
2008-06-17, Al
NetXtreme BCM5722

Драйвер для сетевой карты NetXtreme BCM5722 Gigabit Ethernet
2008-06-15, tango
Amanda

Установка и настройка сервера резервного копирования Amanda на FreeBSD.
2008-06-12, LMik
Виртуальный свитч

Статья описывает создание виртуального коммутатора для соединения удаленных физических ethernet сетей.
2008-06-08, littlesavage
SiS*Mirage*1 на D201GLY2

Как заставить работать видеоrарту SiS*Mirage*1 на материнской D201GLY2
2008-06-06, nsand
Рыбалка на FreeBSD

Стьатья о том как настроить рыбалку со спутника под FreeBSD
2008-06-06, nsand
TT budget S-1401

Настройка драйвера ttbudget (SkyStar3) под FreeBSD
2008-05-30, Andy2k
NOD32 mirror

Скрипт для создания зеркала обновлений для антивируса NOD. Автоматически ищет нужные логин-пароль для получения обновлений. В теории не требует обслуживания.
2008-05-25, Romzes
метаданные exif

Пример сортировки фотографий сделаных разными фотоаппаратами, с разными названиями, датами создания/модификации. Из под консоли, конечно.
2008-05-23, FenX
svn+apache+trac

Установка связки Apache2.2 + Subversion + Trac (Установка и настройка SVN сервера с доступом к репозиториям по http протоколу)
2008-05-22, Grishun_U_S
простой конфиг PF

В статье разбирается простой конфигурационный файл pf "изнутри можно все"
2008-05-20, KrivoSoft
HAVP

HAVP(HTTP AntiVirus proxy)- работает как http прокси, проверяющий файлики используя LibClamav. В заметке описан процес прикручивания антивируса к уже работающему прокси серверу squid.
2008-05-20, Covax
ALTQ в IPFW

Исполльзование ALTQ вместе с IPFW
2008-05-19, nonalog2007
pppoe

Настройка ADSL-модема для подключения к Интернет.
2008-05-04, Abigor
php + mssql

Настройка php на freebsd для работы с базами в mssql по доменной авторизации.
2008-04-28, serge
i386=>amd64

Рассматриваеться способ удаленной миграции с архитектуры i386 на amd64 на рабочем сервере.
2008-04-24, Mr.Y
Lan over Bluetooth

Статья описывает как используя Bluetooth, объединить две FreeBSD машины в сеть.
2008-04-19, lissyara
WiFi WPA

Подключение FreeBSD к беспроводной WiFi сети с использованием шифрования WPA.
2008-04-18, nikll
nginx+php-fpm+mysql

Статья о настройке мощного веб сервера который не ляжет от хорошей нагрузки.
2008-04-16, nikll
qmail-ldap + AD

Статья о том как я прикрутил qmail к АД win2003 (с упровлением почтовыми аккаунтами через консоль mmc из под винды)
2008-04-14, SHPAk
Приглашение csh/tcsh

Приглашение csh/tcsh не всегда удобно. Здесь описано как помянять оное...
2008-04-07, inspirra
deltup, xdelta, bdelta

Некоторые тонкости создания бинарных патчей. И использование "The dynamic deltup server network" для экономии на обновлениях исходников программ устанавливаемых из портов.
2008-04-02, fr33man
exim + cyrus-imapd

Руководство по настройке почтовой системы на базе OpenBSD-4.2: exim + cyrus-imapd + mysql
2008-03-30, Morty
LiveCD (+restore)

LiveCD, который развернет мне на жёсткий диск готовую настроенную систему
2008-03-25, lissyara
BlueTooth mouse

Краткое повествование о том, как привернуть BlueTooth мышь к FreeBSD. Краткое - потому как делается это с полпинка...
2008-03-21, moonug
ProFTPD+iconv

Порт позволяющий включить перекодировку имён файлов в proftpd. Раньше для этого был патч, а щас всё поломали =))
2008-03-11, helloworld
vsftpd + mysql

Настройка фтп сервера vsftpd с пользователями из mysql
2008-03-06, Raven2000
Call of Duty 4

Call of Duty 4: Modern Warfare — компьютерная игра, продолжение серии COD, разработанное студией Infinity Ward. Это первая игра в серии, действие которой происходит не во время мировой войны.
2008-03-04, schizoid
NeTAMS 2

Netams, статистика, биллинг, огрнаичение и подсчет трафика
2008-03-04, schizoid
NeTAMS

Программа для учета и управления сетевым трафиком
2008-03-01, Le1
EA Battlefield 2 server

Установка игрового сервера EA Battlefield 2 под ОС FreeBSD
2008-02-25, dikens3
Dynamic DNS

Свой сервер с динамическим IP-Адресом.
2008-02-23, fr33man
squid ntlm

Настройка Squid с аутентификацией ntlm, под OpenBSD. Решение проблем сборки с поддержкой АД.
2008-02-18, lissyara
BlueTooth

Встала задача залить на Нокию гиг музыки через BlueTooth. ОС - правильный - FreeBSD, вот про то как это сделать из под неё - и рассказ. Также немного про нынешнее состояние дел с голубыми зубами =)
2008-02-17, Raven2000
NFS & Win2k3

При работе с UNIX системами на предприятиях часто приходится организовывать совместную работу с Windows. Необходимо обеспечить взаимодействие UNIX<>WIN бывает, что доступ по FTP или др не устраивает.
2008-02-14, Morty
Lightsquid

Снятие статистики с OOPS, SQUID с помощью lightsquid - нечто на подобии SARGa, и выполняет туже задачу, подбивает статистику пользования прокси сервером
2008-02-14, Morty
OOPS

Краткое описание установки и настройки прозрачного прокси-сервера OOPS
2008-02-12, fr33man
Apache

Настройка web-сервера apache, на базе OpenBSD. Нужен был web сервер. Стандартно нужно было ставить apache. Но я помнил, когда раньше работал с OpenBSD, что апач поставляется вместе с системой. Так
2008-02-11, Raven2000
Установка OpenBSD

OpenBSD — свободная многоплатформенная операционная система, основанная на 4.4BSD — BSD-реализации UNIX системы. Основным отличием OpenBSD от других свободных операционных систем, базирующихся на
2008-01-31, serge
ApacheStats

Сбор статистики с веб-сервера Apache в Cacti с использованием модулей mod_status и mod_info. Отображается число хитов в секунду, загрузка чилдренов и прочая полезная инфа.
2008-01-30, Raven2000
CVSUP и софт через Proxy

При работе за прокси люди испытывают неудобство при обновление портов и установки портов. Хотя, наверное, догадываются, что FreeBSD может элегантно обходить эти камни, но не знают как.
2008-01-25, nikll
kde и smb

статья о том как фрю сделать членом win2003 домена и о том как в кде 3.5 ходить по доменным шарам с нормальной русской кодировкой
2008-01-21, Fastman
Создание программ на QT4/С++

Установка и настройка QT4. Пример создание приложения с GUI.
2008-01-17, Morty
stunnel для pop3,smtp

Создание защищенного подключения для сервисов POP3, SMTP, Imap , www с помощью stunnel
2008-01-09, lissyara
Atheros AR5007EG

Прикручивание карточки Atheros AR5007EG (в ноутбуке Toshiba L40-139) под FreeBSD.
2008-01-04, LMik
growfs

Статья наглядно описывает изменение размера раздела диска в FreeBSD при помощи growfs, без потери данных находящихся на диске.
2007-12-23, serge
FreeBSD на VDS

Рассматривается настройка FreeBSD6.2 на VDS с чистой ОС.
2007-12-22, serge
OTRS на Apache1

Рассматривается установка Open Ticket Request System для работы на хостинг сервере в связке apache1.3 + mod_perl + mysql50.
2007-12-11, INFected
SkyStar-2+SlonAx

Встала задача организовать прием трафика от спутникового провайдера. Естественно на раздающем сервере должна быть FreeBSD. А как же иначе?
2007-12-08, netcat
GEOM-ELI

Шифрование файловых систем посредством класса GEOM-ELI
2007-12-07, helloworld
PVPGN

Настройка сервера Battle.net в небольшой локальной сети.
2007-12-06, seacon
ESET NOD32

Описание настройки антивирусной системы NOD32 ESET File Security
2007-11-23, azu
Bluetooth proximity monitor

Описание и скрипты для отслеживания удаленности bluetooth устройства.
2007-11-19, catdog_
verlihub (p2p)

описывается, как установить, настроить p2p-сервер и как им управлять
2007-11-14, UA
OpenVPN

руководство по настройке openvpn между FreeBSD и Windows
2007-11-11, AlkoGekS
atacontrol

Проверка работы raid-1 с помощью штатной утилиты atacontrol на freebsd 6.2
2007-11-08, Raven2000
Transport Tycoon Deluxe

Transport Tycoon Deluxe (сокращенно - TTD) - экономическая транспортная стратегия, в которой целью игрока является создание максимально доходной транспортной империи.
2007-11-06, lissyara
squid+AD

Инструкция - как авторизовать пользователей в домене, разделив доступ к ресурсам по виндовым группам - кому куда можно, а кому нельзя, с использованием squid2.6. Ну и объяснение - почему пока не 3.0.
2007-11-03, schizoid
icecast2

Вещание интернет радио в локальной сети с помощью icecast2
2007-11-02, AlkoGekS
RoundCube

Возникла необходимость перевести пользователей с squirrelmail на roundcube, завязать все это хотелось на postgresql, чтобы и в ней разобратьс заодно.
2007-10-30, SniZ
queues

Краткая заметка по использованию очередей В IPFW
2007-10-29, s@sh@
LACP и VLAN

Описание настройки LACP отдельно и совместно с VLAN во FreeBSD 7.0
2007-10-26, Al
portaudit

Эти приложение используется для контроля уязвимостей и обновления приложений, установленных из портов.
2007-10-24, -cat-
Заметки об IPFW

Заметки о настройке IPFW, подключение IPFW и NATD, принцип взаимодействия, принципы построения правил IPFW.
2007-10-23, Raven2000
X-Bomber

Представляю вниманию отличную аркаду которая скрасит наш быт и существование в офисном пространстве именуемая как "работа" И так прошу любить и жаловать X-Bomber
2007-10-22, Raven2000
TeamSpeak

Teamspeak (тимспик) — семейство программ, предназначенных для общения голосом в сети. От классического телефона отличается практически неограниченным количеством абонентов, разговаривающих одноврем
2007-10-22, RageLT
Nginx+php+fcgi

"Nginx + PHP + Spawn-fcgi" - установка nginx под FreeBSD и настройка для выполнения PHP скриптов.
2007-10-20, dikens3
UFS2

Как устроена UFS2. Небольшой взгляд изнутри.
2007-10-19, Al
Nagios - мониторинг сети

настройка мониторинга сети с использованием Nagios
2007-10-19, BlackCat
FFS из-под WinXP

Описание програмки для чтения BSD разделов под Windows. К сожалению, диск подключается в режиме только чтения - но и это уже неплохо.
2007-10-14, dikens3
recovery files

Восстановление файлов на FreeBSD с использованием foremost, sleuthkit, photorec. Немного теории о хранении файлов на диске.
2007-10-05, lissyara
ClamAV mirror

Понадобилось создать внутри локальной сети зеркало обновлений ClamAV, c учётом того, что разработчики это не привтствуют - пришлось изобретать подпорки и велосипеды.
2007-10-04, SeeD
irc + services

Установка irc сервера (unreailircd) + сервисов (anope) на FreeBSD 6.0. Приведён тот необходимый минимум, который вполне подойдет для одиночных серверов.
2007-10-04, lissyara
установка по сети

Столкнувшись с невозможностью поставить FreeBSD на старенький ноут с CD-ROM (толи диск царапаный, толи чё), пришлось изгаляться с установкой по сети - благо на нём был PXE у встроенной сетевухи.
2007-10-04, Al
cups-samba на samba+AD

Пример настройки сервера печати с использованием CUPS, Samba и AD. Пример установки и настройки клиентских (для винды) драйверов принтера на сервер с использованием порта cups-samba.
2007-10-03, schizoid
ipcalc

Скрипт для вычисления широковещательного адреса, диапазон хостов, шаблон сетевой маски по полученному IP и сетевой маске. Может использоваться для конструирования сетей и подсетей, а также в обучающих
2007-09-26, lissyara
немного о ssh

Краткое описание как пробросить порты с удалённой локальной сети на локальную машину при помощи ssh. Может быть полезным, когда нет VPN в удалённую сеть, а есть ssh, и нужен доступ к какому-то сервису
2007-09-26, SniZ
mod_ntlm2

mod_ntlm2 - модуль для apache22, позволяющий прозрачно авторизовать пользователя использую его доменную учетную запись. Удобно, если необходимо сделать ограниченный доступ к содержимому корпоротивного
2007-09-18, lissyara
klaptopdaemon

даемон KDE для мониторинга состояния батареи ноутбука. Наверное, самое удобное и функциональное из того, что я перебрал.
2007-09-17, bisyarin
Удаленное разбиение HDD

В статье рассмотрен пример удаленной доразбивки винчестера. Показан путь решения задачи как с использованием sysinstall, так и с помощью утилит fdisk, bsdlabel и newfs.
2007-09-14, freeman_tnu
DSL-G804V и FreeBSD 6.2

Настройка VPN-туннеля между D-Link DSL-G804V и FreeBSD 6.2
2007-09-13, lissyara
KNemo

Служба KDE отображающая в трее значка сетевого подключения, с богатым функционалом - позволяет собирать статистику, строить графики, выполнять скрипты при изменении статуса сетевого подключения.
2007-09-12, lissyara
desktopbsd-tools

Набор утилит для упрощения жизни под KDE. Включают в себя утилиты трея для слежения за сетью, монтирования/ демонтирования, информацию о заряде батереи. Также несколько апплетов для контрольной панели
2007-09-06, lissyara
nettop

Приложение позволяющее отслеживать сетевую активность по портам-протоколам, и отображать скорость передачи данных по этим портам и протоколам. Весьма удобно для наблюдения - что происходит на сервере.
2007-09-04, squid
sshd & AD

Использование одной учетной записи на FreeBSD и Windows - используя AD для авторизации пользователей по ssh
2007-09-02, lissyara
ISPmanager

Краткое описание того, как заменить дефолтовый майлер на ISPmanager, если он у вас - sendmail. Может пригодится тем кто берёт виртуальный сервер, и хочет большей гибкости в настройке.
2007-08-25, serge
mod_ntlm

mod_ntlm - модуль для apache13, позволяющий прозрачно авторизовать пользователя использую его доменную учетную запись. Удобно, если необходимо сделать ограниченный доступ к сайту.
2007-08-15, lissyara
colorize

colorize - утилита для подсветки ключевых слов в просматриваемых логах. Весьма удобно - становится более понятно и доходчиво, тока временами слишком уж пёстро :)))
2007-08-13, Raven2000
Документация на Unix

Здесь представляем список необходимой документации для чтения и полного освоения FreeBSD как основной серверной операционной системы. И не только ее.
2007-08-06, lissyara
QTFW

Графический интерфейс для составления и редактирования правил файрволла IPFW - абсолютно бесполезная приблуда...
2007-08-01, Raven2000
Counter-Strike 1.6

По просьбам трудящихся, точнее по их заявлениям, о том что нужна им Counter-Strike 1.6 хоть "убейся об стену". Решил разобраться, наконец, с этим вопросом, что и сделал. И так поехали. :)
2007-07-31, f0s
LDAP: samba, dns, dhcp

Настраиваем PDC на самбе, все данные в LDAP. Попутно вешаем DDNS+DHCP - их данные тоже храним в LDAP.
2007-07-27, lissyara
root-tail

Практически бесполезное, но довольно забавное приложение, показывающее логи на рабочем стол. Может пригодится лишь если на ваш десктоп логи передаются с удалённых хостов.
2007-07-27, lissyara
laptop battery

Краткий обзор программ мониторинга состояния заряда батареи ноутбука - что можно использовать на FreeBSD7.0 (CURRENT) и AMD64.
2007-07-24, Raven2000
phpBB-2/3

phpBB – это мощное, полностью масштабируемое и легко изменяемое программное обеспечение с открытым исходным кодом для создания конференций. Основанный на мощном языке PHP и имеющий поддержку серверов
2007-07-23, lissyara
apache 2.0

Настройка WEB-сервера на apache2 и php в режиме CGI с использованием mod_fastcgi.
2007-07-15, lissyara
geom_uzip

Создание образа сжатой ФС с загрузкой по сети - данный метод может использоваться для создания загрузочных дисков/сидюков и прочего - на машинах где мало оперативки, например...
2007-07-06, bdmalex
2 CD -> 1 DVD

FreeBSD: Заменим 2 инсталляционных диска на 1 DVD.... чтобы коллекцию дисков уменьшить....
2007-07-04, Andy
NSPluginWrapper

Перевод с французского очень хорошего мануала, досконально объясняющего, как инсталлировать линуксовые плугины для firefox, используя NSPluginWrapper. В том числе и 9-й flash.
2007-07-01, lissyara
sshit

Перловый скрипт мониторящий попытки подбора паролей для ssh/ftp в режиме реального времени, и блокирующий атакующего используя файрволл - pf/ipfw/ipfw2 - просто и со вкусом :)
2007-06-19, Raven2000
CMS - TYPO3

Ставим CMS TYРOЗ - Корпоративная система управления веб-контентом TYРOЗ — система управления сайтами (CMS/CMF) с открытым исходным кодом и свободной лицензией. Написана на PHP, для хранения данных...
2007-06-15, lissyara
SAMBA+ACL

SAMBA + правка расширенных пермишенов (ACL) через виндовые галочки - полезно для передачи управления шарами на самбе виндовым админам, ничё кроме галок и не умеющим :)
2007-06-13, roygbiv
ntop 4.10

Установка, настройка, оптимизация сетевого анализатора трафика ntop 4.1 stable с плагинами (в т.ч.SPAN-Sniffer и NetFlow) на FreeBSD 8.2 release. Описание nProbe.
2007-06-09, Andy
vsftpd

перевод мана на vsftpd
2007-06-04, lissyara
exim + dovecot + win2003 AD

Как заставить связку exim+dovecot использовать в качестве БД пользователей виндовый домен. Статья неполноценная - тока основные моменты и ссылки, где взять остальное. Скорее - просто заметка для себя.
2007-05-30, lissyara
exim + exchange

Настройка релея на exim для сервера M$ exchange находящегося внутри локальной сети. Настройка перезаписи адресов локального домена на внешний.
2007-05-13, Raven2000
Бронированный FreeBSD

Как и любую другую систему FreeBSD нужно так же защищать от посягательств на нее. Она не так уж защищена, как много людей о ней думают и ее можно так же сломать и крякнуть, как и тот же Windows.
2007-05-12, alex3
Печать из фри в винду

Печать из FreeBSD на сетевой принтер виндов
2007-05-03, Raven2000
Десктоп c FreeBSD

По просьбам трудящихся возьмусь за неблагодарную тему по одомашниванию FreeBSD.Начнем с одомашниванием консоли закончим русским KDE и настройками видео карт.
2007-04-28, fr33man
iPod

Использование iPod во FreeBSD
2007-04-25, lissyara
AutoMount

Как настроить автоматическое монтирование флэшек и CD-ROM в KDE. Заодно пришлось победить грабли с неверной русской кодировкой на флэшках.
2007-04-24, Fastman
Socket сервер на FreeBSD.

Пишем tcp демона на С++ !
2007-04-14, BAV_Lug
ATSlog

Ведение статистики звонков с офисной мини-АТС.
2007-04-11, nk
Backup MX

Настройка fetchmail для сбора писем с сервера провайдера или резервного сервера и дальнейшая передача их локальному MTA
2007-04-11, Raven2000
Quake III Arena

Представляю установку всеми любимого игро-мясо-экшена Quake III Arena именно так и никак не иначе! Будет чем заняться Васе и Пете (и отделу) во время работы, т.е. вместо нее :) И так Kill'em All!!
2007-03-31, Raven2000
Работа с HDD

Есть много вопросов как грамотно разбить диск, выделить своп и диагностировать узкие места дисковой системы и т.к.дисковая подсистема-узкое место и разбивка его во многом определяет производительность
2007-03-29, Abigor
mpd + freeradius + mysql

Настройка связки mpd + freeradius + mysql с дальнейшим превращением ее в биллинговую систему. Может пригодится совсем мелкому домашнему провайдеру
2007-03-27, fr33man
Exim + LDAP

Настройка почтового сервера на базе Exim, с хранением информации в директориях LDAP.
2007-03-21, dikens3
PBR & IPFW

Настройка 2-х каналов в Интернет.
2007-03-16, fr33man
Samba(PDC) + Ldap

Множество неточностей заставили меня полностью переписать статью по настройке Samba + LDAP.
2007-03-16, lissyara
IPSEC

Настройка шифрованного туннеля с использованием IPSEC на FreeBSD6.2, с использованем сертификатов. Используются только штатные прграммы (не считая racoon из портов).
2007-03-11, Raven2000
make.conf

Так как мы сидим под фряхой и ставим все исключительно из портов (как умные ;)) компилим ядра и тд то неплохо было бы оптимизировать процесс компиляции многие часто не придают этому значение, но ведь
2007-03-07, lissyara
/usr/sbin

Системные приложения из '/usr/sbin'
2007-03-06, lissyara
/usr/bin

Системные приложения из '/usr/bin'
2007-03-02, lissyara
/sbin

Это даже не статья, а просто однострочное описание каждого приложения находящегося в '/sbin'. К каждому приложению можно оставить комментарий, что уже и сделано для многих - примеры использования.
2007-02-28, lissyara
/bin

Краткое описание (в одну строку, в основном) всех системных приложений из '/bin'
2007-02-22, Raven2000
Jabber - OpenFire

OpenFire — это свободный многофункциональный и отказоустойчивый Jabber-сервер написанный на Java.На базе использования данной технологии было создано множество частных и корпоративных серверов Jabber.
2007-02-07, lissyara
ru man

Интересный проект нашёлся - товарисчи переводят маны от FreeBSD. Народу не много, перевели тоже не много - но всё же, хоть что-то. Дело нужное - поэтому ставим.
2007-02-05, Raven2000
SkyLink-CDMA

SkyLink-CDMA + FreeBSD 6.1 Подрубаем телефоны SkyLinkие т.е. CDMA к нашей любимой фряхе :) Например мне надо было подключить к BSD 2 телефона, мобильный Ubiquam UM-105 и стационарник RWT FCT-CDMA.2
2007-01-29, dikens3
Rejik

Блокирование баннеров с помощью SQUID+REJIK
2007-01-25, lissyara
Samba как PDC

Понадобилось поднять домен без винды - намучавшись со всякими LDAP`ами сделал по простому - на системных учётках. Работает и работает - разве что пришлось десяток скриптов на шелле написать.
2007-01-15, Raven2000
Настройка AWStats

Статистика с AWStats 6.6 AWStats – еще один парсер, написанный на perl. Поддерживает запуск из командной строки и динамически через CGI Настройка для Аpache, Proftp, Postfix, Sendmail, QMail, MDae
2007-01-14, lissyara
loader.conf

Перевод комментариев файла loader.conf (FreeBSD 6.2 RC2RC2) В нём довольно много интересных вещщей, в частности, через него можно добавить некоторые возможности без сборки нового ядра.
2006-12-27, dikens3
if_bridge

Настройка DMZ при помощи if_bridge
2006-12-18, lissyara
BIOS & PXE

Прошивка загрузочного PXE биоса для сетевых плат RTL8139(A/B/C)/RTL8130 прямо в БИОС материнской платы - полезно, когда на сетевухах нет кроватки под микросхему, или когда нет самих микросхем :)
2006-12-12, lissyara
DSPAM

Наиболее эффективное использование этой программы - в качестве второго фильтра, на спам. Первичный "грубый" отсев стоит проводить самим MTA Exim, благо он обладает широкими возможностями фильтрации.
2006-12-01, seacon
D-Link DWL-G520

Понадобилось сделать радиолинк на базе карточки DWL-G520 и апэшки DWL-2100AP, особых проблем вроде не возникло...
2006-11-29, lissyara
pppd

Понадобилось поднять dial-in сервер на фре. Ввиду того, что этот самый сервер, будучи под виндой достал всех, решили на новом оторваться по полной :)) Но - сервак всё равно подняли :)))
2006-11-27, fr33man
newsyslog

Программа для ротации логов -- newsyslog.
подписка

    вверх      
Статистика сайта
Сейчас на сайте находится: 12 чел.
За последние 30 мин было: 72 человек
За сегодня было
12869 показов,
1678 уникальных IP
 

  Этот информационный блок появился по той простой причине, что многие считают нормальным, брать чужую информацию не уведомляя автора (что не так страшно), и не оставляя линк на оригинал и автора — что более существенно. Я не против распространения информации — только за. Только условие простое — извольте подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой, незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
  Если соизволите поставить автора в известность — то вообще почёт вам и уважение.

© lissyara 2006-10-24 08:47 MSK

веселые картинки развлекательные гифки интресные факты смешные видео смешные истории из соцсетей

Время генерации страницы 2.174 секунд
Из них PHP: 99%; SQL: 1%; Число SQL-запросов: 46 шт.
У Вас отключено GZIP-сжатие в браузере. Размер страницы 381787