Третьего дня привезли чудесные агрегаты — 27-дюймов, 2к экран, колонки, камера, процессор Core i7-10700T, 16Гб памяти на борту, SSD 512Gb, а также nVidia GTX1650 4GB. Ждали мы эту пару довольно долго, оказалось, довольно таки не частые экземпляры. Но вот беда, комплектовались они Windows 10 Home...

Но беда — не беда, т. к. сменить версию почти всегда (на самом деле нет, не всегда, но часто) можно штатными методами и без переустановки.

Шаг 1 — Нажимаем WIN + R.
Шаг 2 — Вызываем slui.exe
Шаг 3 — Запускаем
Шаг 4 — Вводим ключ для Windows 10 Pro (обычно не прокатывает, что удивительно!), если это так, то используем стандартный ключ — VK7JG-NPHTM-C97JM-9MPGT-3V66T.
Шаг 5 — Нюанс, если есть ругать на ключ, а у меня так было — отключаемся от интернетов и вводим ключ повторно, после чего перезагружаемся.

Возникла задача добавить несколько десятков пользователей в Яндекс.Коннект и сразу же начались поиски пути решения, чтобы избавиться от ручного труда и в дальнейшем облегчить жизнь. Решил попробовать вариант от Energys — статья на habr’e. Почему попробовать? За пару лет что-то могло перестать работать, как говорится — «За время пути собака могла подрасти!»

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

Самое не простое в этой истории — возня с токеном от Яндекса. В статье она описана, пройдем по шагам для истории и чтобы ничего не забыть:

• * зайти в аккаунт яндекса под администратором домена;
• * в Я.OAuth первым делом нужно создать приложение;
• * приложению даем права, в нашем случае — Яндекс.Коннект Directory API;
• * выбираем платформу «веб-сервисы» и нажимаем «подставить url для разработки»;
• * сохраняемся и получим ID приложения — именно оно понадобится для получения токене;
• * вставляем ID приложения и получаем токен:

https://oauth.yandex.ru/authorize?response_type=token&client_id=<ID приложения>

• * именно этот токен и будет использоваться в скрипте;

Идея сравнительно не сложная:

1. готовим файл определенного образца;
2. добавляем переменных;
3. читаем список из файла;
4. в запросе в цикле добавляем переменные;
5. в каждой итерации ждем пару секунд.

Сам скрипт выглядит следующим образом — он же на GitHub:

#!/bin/bash
# path to users list - путь к списку пользователей
employees='./usrlist'
# line example from users list - пример строки файла 
# usrlist: email_lastname_firstname_middlename_password_position
# for example: petrova_Петрова_Авдотья_Федоровна_eeKrutoiparol23_Менеджер

# OAuth_Token
# link to material about token - ссылка на формирование отладочного токена
# https://tech.yandex.ru/oauth/doc/dg/tasks/get-oauth-token-docpage/
# link about our apps - список ваших приложений
# https://oauth.yandex.ru/
# get token from apps id - получить токен из ID приложения
# https://oauth.yandex.ru/verification_code#access_token=435843755894374389
TOKEN="token-here-and-there"

# read and trim user file - читаем и перебираем файл со списком пользователей
for i in $( cat $employees ); do
value=($(echo $i | tr "_" " "))

# make variables for api request from file - заводим переменные для запроса из файла
email="${value[0]}"
lastname="${value[1]}"
firstname="${value[2]}"
middlename="${value[3]}"
password="${value[4]}"
position="${value[5]}"

# Make user for good - создаем сотрудника ради добра
# department = 1 for default - департамент 1 умолчанию
#only http answers, not full - только http ответы, не полный лог
curl -i -X POST -H 'Content-type: application/json' -d '{"department_id": 1, "position": "'$position'", "password": "'$password'", "nickname": "'$email'", "name": {"first": "'$firstname'", "last": "'$lastname'", "middle": "'$middlename'"}}' -H "Authorization: OAuth $TOKEN" 'https://api.directory.yandex.net/v6/users/' | grep HTTP
#full answers - полные ответы
#curl -i -X POST -H 'Content-type: application/json' -d '{"department_id": 1, "position": "'$position'", "password": "'$password'", "nickname": "'$email'", "name": {"first": "'$firstname'", "last": "'$lastname'", "middle": "'$middlename'"}}' -H "Authorization: OAuth $TOKEN" 'https://api.directory.yandex.net/v6/users/' 
# wait for 2 sec - ждем пару секунд
wait 2
done

C чем удалось столкнуться при отладке и работе скрипта? Буквально несколько моментов:

• * если посылать запросы слишком часто, часть может не сработать — нужно подбирать тайминги между запросами.. пауза в 1-2 секунды работает;
• * обязательно нужно смотреть на входные данные — аккуратность с символами в названиях важна;
• * моя частая ошибка — 422 Unprocessable Entity — при разборе оказалось, что пароль был слишком простой;

Не так давно мне удалось попасть на официальный курс MTCSWE (MikroTik Certified Switching Engineer) к Дмитрию Скоромнову. На сколько понимаю первый или один из первых в этой стране. Курс был интересен мне тем, что там ожидалось раскрытие темы VLAN целиком и полностью, плюс работа с коммутаторами от «рижских парней», которых из новых у меня в хозяйстве пока нет.

Обучение проходило в районе Красных Ворот, недалеко от Басманного суда, в центре PM Expert. К помещению никаких претензий нет. Все сравнительно удобно — как столы, так и внутренность. Перекур тоже можно провести недалеко. Столы бы только побольше, чтобы можно было капитально разложиться, но здесь, как говорится, чем богаты.

Работали на реальном «железе», никаких виртуалок. Стенд давал возможность на деле оценить поведение оборудования в тех или иных ситуациях. Получался немного громоздкий, но тем не менее живой стенд для проверки разных режимов работы.

Материалы традиционно были авторские, традиционно цветные и сшитые на пружине. Не кислый такой томик на 138 страниц плюс лабораторные работы на 98 страниц. Большая подборка по курсу MTCSWE с глубоким погружением в материал. Без преувеличения — информации дается много: как и теоретической, так и практической. Теории по L2 довольно таки много, как по мне. MTU например весьма глубоко рассматривается. Также подробно идет (R/M) STP, ARP, VLAN.

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

Сразу скажу, что сам экзамен я не сдал. Мне удалось набрать только 53%. Не смотря на качественный подход, практических умений не хватило все-таки. Сложности обещали сразу, видел комментарии, что экзамен не простой. Сам только не представлял насколько. Традиционно на экзамен дается час времени и 24 вопроса (хотя почему-то пишут про 25). Вопросы снова по традиции с закавыками на один выбор или множественный выбор. Самая большая засада для меня была с нехваткой времени — на перепроверку ответов его тоже не хватило, разбором типовых конфигураций с VLAN’ами и расчетами по RSTP. Без практического опыта, полученного и переваренного предварительно — сложно. Теперь, когда стали понятны слабые стороны, можно будет подготовиться лучше и попробовать сдать повторно. Надеюсь, что во второй раз результат получится более приятный. Менее болезненным для меня, как слушателя — повторное обучение в случае неудачной сдачи экзамена у Дмитрия проходит полностью бесплатно. Такие риски он на себя берет — дает возможность укрепить знания и полноценно сдать экзамен.

PS: Большое спасибо Дмитрию, что решился читать реально непростой курс. А также было здорово увидеться с коллегами, с которыми были знакомы исключительно заочно :-)

Второго дня в версии 6.47 ветки stable завезли поддержку DoH (DNS over HTTPS). До этого оно было только в ветке с beta и использовать ее не очень хотелось в виду отсутствия стабильности. Почему это так важно? Дело в том, что DNS без каких-либо дополнений дает возможность вышестоящему провайдеру смотреть и подменять dns-запросы. Не видно причин, зачем ему давать такое делать. А также есть некая простота в том, что теперь свои dns-запросы не нужно заворачивать в тот же VPN.

DNS поверх HTTPS (DoH) — протокол для выполнения разрешения DNS по протоколу HTTPS. Целью этого метода >является повышение конфиденциальности и безопасности пользователей путём предотвращения перехвата и >манипулирования данными DNS с помощью атак типа «Атака посредника».

Первым делом нужно обновиться до 6.47 в ветке stable (или воспользовать beta). В случае с long-term стоит либо потерпеть и подождать или переключиться на stable.

Далее идем в IP -> DNS. Сразу же стоит обратить внимание, что вы можете получать DNS динамически (вышестоящий провайдер или настройки APN) и надо бы убрать автоматику. Чаще всего выглядит это как-то так:

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

/tool fetch url=https://erza.ru/cert/cacert.pem
/certificate import file-name=cacert.pem passphrase=""

Также список корневых сертификатов можно взять на сайте haxx.se или же с DigiCert

После чего удалим лишние dns-серверы и впишем свои. В итоге у нас все выглядит вот так:

Провести проверку можно с помощью torch или в connection tracker:

Список DoH серверов — смотреть тут, но самые популярные скорее всего будут Google ( https://8.8.8.8/dns-query ) и Cloudflare ( https://1.1.1.1/dns-query ).

Тестируем и проверяем на сайте Cloudflare

На всякий случай привожу листинг команд:

/tool fetch url=https://erza.ru/cert/cacert.pem
/certificate import file-name=cacert.pem passphrase=""
/ip dns set use-doh-server=https://1.1.1.1/dns-query
/ip dns set verify-doh-cert=yes
/ip dns set servers=""

UPDATE: Никита Тарикин набросал еще более интересную штуку со скриптом и поворотами — MikroTik DNS-over-HTTPS CloudFlare :)

С выходом Winbox 3.22 появился в этой чудесной программе Legacy Mode, который позволяет, не смотря на усилия инженеров, подключаться менее защищенными методами к роутерам с RouterOS младше версии 6.43. Довольно полезная фишка для тех, кто не может или не хочет обновляться. Стоит заметить, что она выключена по умолчанию, включается впрочем просто:

Так что если вдруг видите ошибку — router does not support secure connection please enable legacy mode — знаете, что нужно включить.

Задумались мы как-то взять какое-нибудь не сильно дорогое МФУ (чб, А4, печать, сканирование), чтоб запчасти и картриджи не дорогие да и функционал был поинтереснее и начали искать. В предложениях было много всего интересного, в том числе OKI и Xerox предлагали довольно четкие агрегаты, но вот ценовое предложение слегка расстраивало.

Начали присматриваться к Brother. Аппараты их низкого ценового сегмента по отзывам были вполне интересными и выносливыми, но вот о 5000 или 6000 серии отзывов было мало. Попробовал написать дилерам, которые продают сами аппараты, но никаких демо залов у них не было и живьем их не посмотреть. История так и закончилась бы ничем, если бы не написал в российское представительство.

Подозреваю, что напрямую им пишут не так часто. Не сразу, но на письмо мне ответили. Как водится поблагодарили за интерес и мы обменялись контактами. А что после того, как мы созвонились и осознали, что хотели бы пообщаться и посмотреть аппараты живьем, плюс потыкать в меню некоторых из них, ничего не оставалось, кроме как встретиться лично. Со стороны Brother получил приглашение и посетил их офис недалеко от станции метро Белорусская, что на улице 1-я Тверская-Ямская. Там мне довольно быстро смогли показать интересующие меня модели. Поскольку они были последними и довольно новыми, они у них были прямо в офисе. Их можно было открыть, посмотреть устройство и задать вопросы. Ко всему прочему удалось пообщаться с их техническим специалистом на предмет меню и особенностей работы аппаратов, оценить функционал. Попутно и удалось для себя решить, что 5750 и 6800 — весьма интересные по стоимости и возможностям аппараты

Искренне рад, что представительство открыто к встречам с людьми практически «с улицы» (достаточно было пояснить задачу и договориться о встрече.) Хотя по сути они проводят прямых продаж — ведь по сути закупки шли через дилеров, таким образом раскрывают свой бренд больше косвенно. От себя хотел бы поблагодарить Ольгу Степанову и Алексея Попкова, очень уж мы плодотворно пообщались.

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

Визуально настройки выглядят как на картинке ниже:

1. Первым делом ставим пакет multicast, без него можно не продолжать — ставим традиционным способом: скачиваем дополнительные пакеты, закидываем в роутер и перезагружаемся;
2. В пункте Routing появится IGMP Proxy — нам туда;
3. Нам нужно создать логику для нашей IGMP Proxy — кто апстрим и кто слушатель. Создается аналогично правилам;
4. Настройки для апстрима — откуда приходить наш поток, у нас это ether1 — порт провайдера или WAN;
5. Настройки для слушателя — в зависимости от вашей сети, но чаще все остальные порты в бридже, потому логичнее отдавать на него. У вас могут быть и более сложные варианты, соответственно, можно выбрать и другое;
6. Опциональный пункт, который зависит от ваших firewall filter rules — если все наглухо заблокировано, то нужно будет открыть UDP в цепочке forward. В ограничителях можно ничего не выставлять, но безопаснее будет сократить диапазон разрешенных адресов до сети провайдера или сервера вещания (нужно учитывать, что он может меняться).

Можно праздновать победу и отключать приставку от телевизора, особенно если вы его не особо смотрите :)

Многие пользователи интернета почти наверняка слышали о ситуацию с .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.Регистратор обязан располагать средствами защиты от действий третьих лиц, направленных на получение несанкционированного доступа к информационной системе Регистратора и/или программно-аппаратному комплексу Регистратора, или на нарушение их нормального функционирования.

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