Многие пользователи интернета почти наверняка слышали о ситуацию с .masterhost. Искренне жаль, что такая судьба постигла в прошлом родную, в прошлом мощную компанию. Еще больше жаль тех, кого настигла такая неприятная ситуация. Но сейчас я хотел бы поволноваться о другом. Дело в том, что в группе компаний .masterhost есть аккредитованный регистратор доменных имен — .mastername. Отсюда у владельцев доменов, к которым и я себя отношу, может возникнуть несколько вполне не иллюзорных сложностей.

Сложность первая — NS-серверы, у некоторых из пользователей они были и есть, т. е. те самые люди, которые пользовались DNS-регистратора. Работу вроде как восстановили и плача по этому поводу слышно меньше, но изменить ничего нельзя: ни ns-серверы, ни dns-записи. Биллинг лежит.

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

Сложность третья — убежать все также нет возможности. Может быть по причине того, что домен не продлен, или отсутствует техническая возможность у регистратора. Биллинг лежит и auth code не приходит.

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

На первый же взгляд среди них следующие нарушения:

2.3. Регистратор обязан бесплатно и круглосуточно предоставлять пользователю (администратору) необходимую и достоверную информацию, указанную в разделе 3 настоящих Требований.
2.4. Регистратор обязан иметь службу поддержки пользователей (администраторов).
2.5. Регистратор обязан бесплатно и круглосуточно принимать от пользователей (администраторов) информацию о технических неисправностях, препятствующих пользованию услугами регистрации доменных имен; устранять в сроки, установленные самим Регистратором и опубликованные на его сайте, неисправности, препятствующие пользованию услугами, связанными с регистрацией доменных имен.
2.8. Регистратор обязан поддерживать систему учета услуг, учитывающую особенности оказания услуг регистрации доменных имен.
3.4. Сайт регистратора и личный кабинет пользователя (администратора) должны быть доступны для предоставления сведений и информации 24 часа в сутки 7 дней в неделю. Регистратор обязан уведомлять пользователей (администраторов) о времени и продолжительности возможных перерывов в работе сайта и/или личного кабинета, связанных с обслуживанием технических средств, путем опубликования информации на сайте регистратора в срок не позднее чем за 48 (сорок восемь) часов до момента наступления перерывов. При этом общая продолжительность возможных перерывов не может превышать 72 (семьдесят два) часа за 12 месяцев.
8.1. обеспечить возможность администратору доменного имени направить запрос/обращение регистратору по вопросам регистрации и/или продления регистрации доменного имени посредством, как минимум, следующих каналов связи: по телефону, электронным способом;
11.4.Регистратор обязан предоставить пользователю (администратору) личный кабинет для взаимодействия с информационной системой Регистратора. Функции информационной системы Регистратора, перечисленные в подпунктах 11.3.1 и 11.3.3.-11.3.8. настоящих Требований, должны быть доступны пользователям (администраторам) через личный кабинет.
11.7.Регистратор обязан располагать средствами защиты от действий третьих лиц, направленных на получение несанкционированного доступа к информационной системе Регистратора и/или программно-аппаратному комплексу Регистратора, или на нарушение их нормального функционирования.

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

...регулярно вижу вопросы из серии: «Где бы мне научиться работать с оборудованием Mikrotik, а то что-то ничего непонятно». Более или менее закрою вопрос этим опусом.

Есть буквально несколько способов изучить предмет:

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

2. Обучение заочное — можно пройти онлайн курс Дмитрия Скоромнова, экзамен сдавать или не сдавать — дело ваше. Курс довольно подробный. По нему я готовился сдавать MTCNA и довольно таки он мне сильно помог. Плюсы — самостоятельно изучение в свободном ритме, можно проконсультироваться по электропочте, полный и добротный курс. Минусы — не будет официального сертификата, нужно немного заплатить.

3. Обучение очное лайт-версия — у Романа Козлова «Курс молодого бойца» пока не проходит по техническим причинам, но есть вариант от MTI — MikroTik Basic MTBMTI. Плюсы — хорошее начало, один день, есть бонусы. Минусы — обычно в будний день и нужно ехать ножками в Москву.

4. Обучение реальное и живое — речь о начальном курсе MTCNA, это полноценное обучение с экзаменом и сертификатами. Здесь у вас довольно широкий выбор как места, так и тренеров. Обычно говорят, что первый курс можно слушать практически у всех. Кого-то определенного рекомендовать не буду — здесь на ваш выбор. Сильные и слабые стороны есть у всех тренеров. Плюсы — полноценное обучение, сертификат (если сдадите экзамен). Минусы — затраты по деньгами и времени (3-4 дня курс).

В Эгея версии 2.8 появился свой sitemap и вроде как стало не нужно использовать костыли для его генерации, но в нем был недостаток, а именно формат даты в lastmod. На него ругался в частности валидатор от Яндекса, что довольно сильно расстраивало.

Исправить поведение довольно не сложно — было сделано на версии 3387 (e2_distr_v3387). Нужно слегка отредактировать system/core.php и искать такую конструкцию (она встречается дважды):

echo '<lastmod>';'

Конструкцию со временем менять на вот такую:

('Y-m-d\TH:i:s+03:00'

При этом не забываем обнулить user/caches.

Обратите внимание на то, что у нас появился разделитель «Т» — в коде соответcвенно «\Т», а также смещение времени по UTC — для Москвы это +03:00. Делается это в соответствии с W3C Datetime (Complete date plus hours and minutes: YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00)).

Обратите внимание на выделенные части:

Результат:

PS: Проблема была как минимум до альфы-беты 2.9, в ней дату упростили, оставив по стандарту только дату без учета времени, т. е. в таком виде 2020-02-07). Проверялось на версии v3543.

Gooooogle Girl — милый такой клип от MAD SHOW BOYS, не настолько токсичный как Google that shit! от Тарин Саутерн .

Доходчиво и понятно, какая из технологий как работает:

UDP: Кинул тебе за щеку
ТСР: Кинул тебе за щеку, проверяй
SNMP: Щас посмотрим, кто тебе за щеку пихал.
POP3: Вам письмо за щеку
IEEE 802.11: Радио «За щеку FM»
P2P: Давай сейчас я кину тебе за щеку, а потом ты мне
SIP: Давай послушаем, как тебе за щеку кинут
IPv6: Сейчас тебе за щеку прилетит, только будет длиннее обычного, приготовься
IRC: Давай дед тебе за щеку кинет
Ethernet: И еще 15 способов кинуть тебе за щеку
ARP: Кто знает этого, которому можно кинуть за щеку?
ICMP: Кинул тебе за щеку, ДОШЛО?
IGMP JOIN: Будьте добры, киньте мне тоже за щеку
NTP: Кажется, пришло время принять за щеку
SSH: Дам тебе за щеку, только никому не говори
MTU/MRU: Кинул тебе за ще
RIP: За щеку могут дать вот там, но их надо ещё попросить, они большие шишки
OSPF: За щеку дают там
BGP: Передайте за щеку всей маршрутке!
STP: Здесь только я могу тебе за щеку напихать
LACP: Ща кинем хэш-функцию, она укажет того, кто тебе напихает за щеку.
LLDP: За щеку тебе может напихать этот, вот тот и тот. Два из них твои соседи.
PBR: Это Олег, он из другого города, но он напихает тебе за щеку
QoS: Я напихаю тебе за щеку, но сначала мы подождем моего друга
DHCP: Что? Хочешь, чтобы я тебе за щеку напихал?
802.3ad: Кинул тебе за обе щеки
802.5: Кинул тебе за щёку, передай дальше
VRRP: Ты никогда не узнаешь кому из близняшек ты кинул за щеку
BFD: Кинул за щеку и тебе откусили
ACL: Кину за щеку после свадьбы
DNS: Спроси у меня, как зовут того, кто кинул тебе за щеку
WebSocket: Лови за щеку, лови за щеку, лови за щеку
amqp: Встаньте в очередь для получения за щеку
Graphana: Здесь ты можешь посмотреть как, кто, с какой скоростью и длиной давал тебе за щеку
Proxy: Надену карнавальный костюм и кину за щеку
VPN: Дам за щеку, но только у тебя дома
MQTT: Здрасьте, кто тут на за щеку подписывался? Принимай!
TOKEN RING: Чья сейчас очередь принимать за щеку?

Оригинал, насколько я смог установить — i_am_romochka

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

Не правильно
$Installed < $Latest

Правильно
$Installed != $Latest

Например мы сравниванием версии 6.45.6 (Installed) и 6.46 (Latest). Получается, что Mikrotik берет значение как число и выходит, что 646 (Latest) никак не может быть больше 6.45.6 (Installed) . В итоге неправильное сравнение больше-меньше конечно будет работать, но не во всех случаях. Для обеспечения универсальности лучше использовать сравнение. Иными словами, если у нас есть различия в версии, то явно нужно обновляться.

Mikrotik обновляется и обновляет прошивку на точках доступа, если включена политика Upgrade policy — require-same-version. Скачивать прошивку не обязательно. Единственный нюанс — работает только для одной и той же архитектуры, например ARM. Дополнительно скачивать прошивку не нужно. Если к CAPsMAN подключены точки доступа с разной архитектурой процессора, то неизбежно нужно выкладывать прошику и задавать каталог для нее в CAP Interface -> Manager -> Package Path.

К примеру у нас RB3011 или RB4011 с архитектурой ARM, а к ним HAP AC2 и/или CAP AC с той же самой архитектурой и таким образом мы можем обновлять весь парк без каких-либо дополнительных телодвижений. Естественно это не касается Routherboard Firmware.

Видео об этом чудесной вещи:

Сказка про то, что капсман не работает с точками не различающимися версиями уже какое-то время сказка, но не совсем. Все зависит от политики Upgrade policy — если требуется та же версия, то точки с другой версией и правда не смогут подключиться. А вот при Upgrade policy в значении none — смогут и это даже будет работать. Подозреваю сложности могут начаться в том случае, если вдруг обновятся частоты и значения будут разные. Но это тоже такое... не слишком частое явление.

Камрад разбирал рекламный экран CL_LedArt, а там неожиданно — латвийский зверек...

Напоминает послания мастеров. :-)