Недавно у нас были небольшие обучающие курсы для повышения нашей компетенции в сетевой части нашей инфраструктуры. Основную идею этих курсов, покрывающую OSPF/BGP/MPLS я тут повторять не буду ибо:

• Пока ещё явно недостаточно компетентен.
• Есть много более объективные ресурсы рассказывающие об этих темах.

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

Ссылки на вики зачастую более примечательны секциями «External links» и «References» нежели самим содержанием

Заведя для себя «почту для домена» на Яндексе, я решил открыть свободную регистрацию посторонним юзерам почтовых ящиков на своем «модном» домене. Помимо включения функции catch-all, которая направляет всю входящую почту несуществующих ящиков моего домена на мой основной ящик, предо мной встала необходимость зарезервировать за собой все «стандартные» названия ящиков, чтобы не было недоразумений, когда какое-то имя уже забил посторонний, и вся «служебная» почта уходит совсем не вам. В П.Д.Д. можно, конечно, в любой момент экспроприировать любой ящик подконтрольного домена, но ведь осадочек-то остается. Я озадачился: какие же имена почтовых ящиков являются стандартными и системными? Техподдержка Яндекса ответила, что они резервируют для себя только имя postmaster@ на каждом домене, чтобы отслеживать жалобы и проблемы с почтой, и что на данный момент вопрос о наборе резервированных имен у них остается открытым. Далее, результат поиска в интернете оказался немного предсказуем.

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

В моем случае ничего криминального на горизонте не предвиделось: требовалось провести расчет времени между двумя событиями в иерархическом XML логе. Дата и время хранились в формате частично совместимом с RFC 3339.

Эта совместимость обеспечивалась корректной нотацией даты yyyy-MM-dd и времени hh:mm:ss.SS, но имели место следующие отступления от стандарта:

1. Дата и время разделялись пробелом, а не буквой T;
2. Число цифр, обозначающих миллисекунды могло варьироваться от «ниодной» до «много-много»;
3. Часовой пояс не указывался вообще.

Сначала я хотел воспользоваться готовым решением с exslt.org – date:difference, но от него пришлось отказаться. Дело в том, что разницу требовалось получать с точностью до миллисекунд, а этот алгоритм возвращал валидный xsd:duration (ISO 8601), который миллисекунд не содержит. К тому же парсить чужой output, хоть и формализованный – дело не очень благодарное. Таким образом, покопавшись немного в exslt, я решил написать парсер сам, в надежде, что смогу сделать это быстро…

Часто перед системными администраторами, как впрочем и перед множеством других околоайтишных людей, возникает необходимость в написании статей, кратких руководств и рецептов настройки оборудования и разного рода софта. В огромном числе подобного рода публикаций можно встретить упоминания о ip-адресах и доменных именах; при этом, фантазия авторов не знает границ, встречаются все виды невозможных с точки зрения двоичной арифметики адресов вроде «120.340.560.780/22» и доменов, к примеру «domen.ru», «test.net» и др.

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

• Согласно RFC 2606 в качестве доменных имен для примеров в документации допустимо использование доменов и поддоменов: .example, example.com, example.net и example.org
• Согласно RFC 5735 в качестве «белых» ip-адресов для примеров в документации допустимо использование ip-диапазонов: 192.0.2.0/24, 198.51.100.0/24 и 203.0.113.0/24

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

Протокол HTTP 1.1 описан в документе rfc2616, в котором так же вводится понятия absoluteURI и abs_path, определение которых описано в rfc2396 «Uniform Resource Identifiers (URI): Generic Syntax», замененный в 2005 году rfc3986 «Uniform Resource Identifier (URI): Generic Syntax».

Хочу обратить внимание на две вещи, которые описаны в rfc3986:

1. URI состоит из ограниченного набора символов (подмножества US-ASCII с кодами 0-127).

2. Кодировка UTF-8 является предпочтительной перед другими, т.к. новые схемы URI должны представляться в универсальной кодировке UTF-8 (When a new URI scheme defines a component that represents textual data consisting of characters from the Universal Character Set [UCS], the data should first be encoded as octets according to the UTF-8 character encoding).

Так же, документ rfc3987 определяет понятие IRI (Internationalized Resource Identifier), которые отличаются от URI возможностью включения unicode-символов в свой состав, определяет отображение IRI в URI с использованием UTF-8. Одним из очевидных местом использования IRI является адресная строка браузера, куда можно вводить ссылку с национальными и прочими символами, не входящими в US-ASCII.

На практике, браузеры могут отступать от требований, что показано ниже.

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

• SRV-записи
• SSL-сертификаты
• Заблуждения о транспортах

	Читал все стандарты
	Один точно прочел
	Парочку с лихом осилил
	С десяток осилил
	Ни разу не получалось, все отрывками.

Проголосовало 319 человек. Воздержался 71 человек.

Первая часть текста взята из инструкции хостинг-провайдера Netangels. Вторая — авторская.

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

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