Ubiquiti UniFi против Keenetic

Я давний фанат keenetic’ов. Ну как минимум был до последних событий. Вся их линейка абсолютно соответствовала моему главному принципу “не трахай мне мозг”. Купил, достал, подключил, соеденил, забил логины-пароли и оно работает себе. Так продолжалось… ну лет много в общем.

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

И тут начались странности и жалобы. Если проводная часть (читай стационарные компы и виртуалки) работали отлично, то WiFi колбасило, причем очень странно. Например, у меня появился “заколдованный” угол, где включаешь любой кинетик и через некоторое время у него пропадает диапазон 5ГГц. И время колеблется от “сразу” до “ну где-то через полчаса”. Ок, пока разбираемся с 5ГГц, можно ведь пожить и на 2х, верно ведь? Нет, не верно. Не знаю, что там и где не стыкуется у кинетика с маком, но его иногда начало перепинывать от точки к точке. И ладно бы просто перепинывало, но иногда его забрасывало на самую удаленную точку, где сигнал иногда терялся. А потеря сигнала – потеря коннекта – сброс всех впн и прочих соединений. Быстрая припарка в виде близкой точки доступа, включенной в меш, помогла, но это же костыль…

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

Для корректной работы Wi-Fi системы, от стороннего оборудования в сети требуется пропуск STP и LLDP.

В Wi-Fi системе протокол STP используется для управления связями между ретрансляторами. LLDP – для определения контролера в сети. Если промежуточное оборудование в сети вмешивается в работу STP/LLDP, либо не пропускает пакеты BPDU протокола STP – работа Wi-Fi системы будет нарушена. Симптомы при этом: петли, сетевой шторм, в случае если ретрансляторы видят транспортную сеть контроллера и подключаются к ней. А если ретрансляторы транспортную сеть не видят, то на них остается включенным беспроводной клиент, который вхолостую сканирует эфир, вызывая потери на собственной точке доступа. Могут возникать разные негативные эффекты.

Если все ретрансляторы подключены кабелями, можно отключить на Keenetic-контроллере “Беспроводную транспортную сеть” в настройках Wi-Fi системы, это, как минимум, уберет возможную петлю. Но, если проблема в STP, это не решает ее полностью, лишь отчасти маскирует ее.

Если имеется оборудование с поддержкой STP, его нужно настраивать: можно попробовать отключить на нем STP/RSTP/MSTP, но тогда есть вероятность, что будут отбрасываться BPDU-пакеты, что тоже не годится. Может помочь включение опции BPDU Flooding, если такая есть.

Нужно настроить таким образом, чтобы у всех коммутаторов был меньше приоритет в топологии STP и они не занимали место Keenetic-контроллера. Корнем дерева STP должен быть контроллер. По умолчанию и Keenetic, и коммутаторы имеют значение STP Bridge Priority 32768 DEC или 8000 HEX. Чем ниже значение, тем выше приоритет узла. Нужно либо повысить значение на коммутаторах, либо понизить на Keenetic.

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

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

Пункт 1: Между кинетиками должны быть только хабы. Сейчас они маскируются под “неуправляемые свичи”. Или сами кинетики. Как выяснилось, их сетевая часть плюет на стандарты в этом месте.

Пункт 2: Пока точка доступа не видит контроллер по LLDP, она НЕ ПЕРЕСТАЕТ сканировать сеть в поисках транспортной. Пофиг на то, что контроллер видит точку доступа и рулит ей. Пофиг на пинги и прочее. Нет lldp? Нет и 5ГГц. Это и стало причиной глюков по 5ГГц. Точка доступа поднимает SSID, набирает клиентов, гонит трафик… Потом просыпается что-то внутри “ой, а где контроллер” и она начинает сканировать эфир, посылая клиентов нахер. Не найдя, она поднимает все назад и процедура повторяется. А клиенты шарахаются с точки на точку и с канала на канал.

Быстро собрав отдельную сеть для кинетиков и пригасив негатив (читай: у мака wifi стал отваливаться не каждые 10-15 минут, а пару раз за день), я принялся искать варианты. Первыми попались на глаза и ушли консьюмерские дивайсы. Asus, TP-Link и прочие Xiaomi. Почитав обзоры и погуглив разное, я решил, что повторения болей мне не надо. Где-то нет меша через провод, где-то управлялка только через мобильник, где-то еще какая закавыка…

Ладно, пойдем к корпоратам. Так сказать, чем мой дом не SOHO? Первым попал под микроскоп microtik. Первым минусом стало то, что WiFi у микротиков традиционно слабый. Но это мелочи, можно просто побольше точек напихать, благо у меня чердак неэксплуатируемый. Но вот winbox и прочее стали барьером. Я как-то привык к принципу “рулим отовсюду и без особых заморочек”.

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

Пока она едет, ставлю в виртуалку UniFi Network, единственная задача которой рулить всей сетевой частью дивайсов компании. Есть еще всякие UniFi Access и NVR, но мне не нужны ни замки на двери (читай СКУД), ни запись с камер.

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

Воткнул в РОЕ коммутатор, раздал VLAN… Пошел в UniFi Network, захватил точку и… Всё. Реально все. Она заработала, показала всё, что надо и вообще как будто тут и была. “Подозрительно”, решил я и принялся ее гонять. Диапазоны, каналы, устойчивость к температурам (на улице была жара +40 в тени, под крышей было до +65) и прочее. Да, куча функционала в network не работало, ибо нужны были другие железки от unifi, но именно к точке доступа претензий не возникло ни одной. Даже мак любезно перешел на нее и был совершенно удовлетворен сетевой частью.

Прошла неделя. Без замечаний. Я заказал UniFi Cloud Gateway (читай: роутер), сверху USW Lite 8 POE (читай коммутатор с РОЕ) и еще три точки доступа. Пока железо ехало, читал гайды и смотрел видосики. На youtube реально куча видео, рассказывающих про все аспекты: начиная от “инсталяция с нуля для нубов” и заканчивая “у меня есть ранчо, чего-то вайфай на горе за 200м от дома плохо ловится”.

Приехало железо. Быстренько раскидал как попало, воткнул куда придется и принялся играться. И оно опять-таки подозрительно все заработало буквально с первой попытки. Да, проблемы возникли.

Ну как проблемы. Так, фичи. Например, встроенный показометр топологии почему-то очень вольно обращается с “чужими” свичами. Если поглядеть на картинку сверху, то выглядит, как куча всего подключено напрямую в Main. В реальности они все подключены через свои свитчи. Но это мелочи. В реальности все работает без каких-либо “пропусков LLDP и понижения приоритета STP”.

Наигравшись, через неделю я рано утром выключил все кинетики и переименовал WiFi сеть. И затаился в ожидании “ну чего оно опять не работает”. А фигу. Мне уже стыдно немного за повторения, но оно заработало так, как и ожидалось. Моя лакмусовая бумажка качества сети в виде мака вообще не подавала никаких признаков кислотности в округе. Я даже взял смелость походить между точек доступа во время видеоконференции. Раньше это приводило к секундным паузам, сейчас нет.

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

Следующим шагом станет постепенное избавление от “соплей”, которые я навешал в серверной при игрищах и переезде. В сторону: патч-панель это хорошо!

Но это дела дней грядущих. Теперь краткое резюме о том, в чем же keenetic проигрывает unifi. В том порядке, что пришло в голову.

  1. Все (вообще все) дивайсы от убика умеют в vlan и являются управляемыми. Причем управляемыми из одной точки. При числе дивайсов более одного это дает резкий буст в контроле над сетью. У кинетика надо бегать по каждому отдельно, причем часто без права на ошибку. Иначе сброс и начинай все заново.
  2. Все (опять вообще все) конечные дивайсы от убика умеют в РОЕ. Или раздавать или питаться от него. У кинетика это умеет только voyager (и вроде кто-то еще). Отсутствие необходимости в розетке рядом (или приобретать отдельный РОЕ сплиттер) очень и очень выручает.
  3. Управление сетями WiFi вообще не конек кинетика. У убика можно задать, какая сеть на какой точке будет светиться, а какая нет. У кинетика только все разом и только все вместе.
  4. Управляемость сетью у кинетика тоже на уровне плинтуса. Чтобы развести разные сети по разным VLAN, дать доступ одним и запретить другим, отправить трафик не на маршрут по умолчанию, а куда-то еще – надо трахаться. Реально проще всех оставить в одной сети и не мучаться. У убика это делается парой кликов в админке.
  5. Динамические протоколы маршрутизации. У убика все есть. И OSPF и BGP. У кинетика только RIP и тот в зачаточном состоянии. А это значит, что сделать обход мракобесия РКН на убике на порядок проще и надежнее. И я сделал и оно реально проще.
  6. Убик внутри это обычный линукс. Можно зайти по ssh и посмотреть, как оно все там внутри жужжит. Policy Engine? Это iptables с кучей правил. BGP? Это обычный FRR. Команда ip полностью функциональна и с ней можно сотворить внутри системы что угодно. Даже на точке доступа все это есть и работает. У кинетика же внутри какой-то кастрированный шелл, к которому нет документации. Ну нельзя же считать докой гуляющий по сети pdf от старой гиги.
  7. Кинетик угрюмо курит в углу после вопросов по техническим возможностям. Wifi7? Они только-только WiFi6 освоили. 10Гб порты? Вы чего? У нас 2,5Гб только начали появляться. SFP? Вот вам гигабит, его всем хватает! Уличные точки доступа? Ну под крышей поставьте, норм же!
  8. И наконец то, что импортные называют observability. Посмотреть, где и что происходит в сети, кинетик попросту не умеет.

Может показаться, что я хаю кинетик, но это не так. Вообще так (смаил), но возможно я просто перерос его возможности и наши курсы разошлись…

Git{Lab,Hub} – раскрываем masked переменные

Рано или поздно, но вам понадобится отобразить в логе CI/CD какую-то замаскированную переменную. Причин может быть множество и все они тут не интересны.

Обычно это решается просто методом “на коленке”:

echo ${SSH_USER} | base64

В ответ получаем строку типа Z2l0bGFiLXVzZXIK, копируем ее к себе и пропускаем через base64 -D

Но в 99% нам просто надо убедиться, что значение переменной верное и пойти дальше. Немного погуглив, я сообразил решение:

- echo ${SSH_USER::1}‎${SSH_USER:1}

На первый взгляд, это не должно сработать: выводим сначала первый символ, потом все, начиная со второго. Гитлаб достаточно умный (или тупой?), чтобы не разбираясь, найти и замаскировать в потоке. Однако пруф вот:

Где обман бедного гитлаба? А шутка ровно посредине. Если смотреть на код в текстовом редакторе, то увидим вот это:

Между частями вставлен специальный unicode символ, который просто пустое место. В итоге “для глаз” всё хорошо, а гитлаб не распознает такую последовательность как требующую маскирования. Задача выполнена!

Где взять такой символ? Самое простое сходить на https://emptycharacter.com/ и выбрать любой понравившийся вариант.

Influx и Telegraf

Поначалу я планировал этот пост про InfluxDB. Дескать, вот так поставим, вот так настроим… Однако реальность больно тыкнула вилкой в глаз: поставил, запустил, зашел на influx:8086, установил пароль, завел организацию… и всё. Нет, реально всё. Больше там ничего не потребовалось делать.

А вот с телеграфом пришлось повозиться. Дело в том, что я возжелал с одной машины отправлять разные метрики в разные бакеты. Ну всякие там “загрузка процессора и памяти” в один, а “температура в доме” – в другой. Ну вот захотелось мне так.

Все просто. Для начала прямо в telegraf.conf добавим тег influxdb_database

# Global tags can be specified here in key="value" format.
[global_tags]
  # dc = "us-east-1" # will tag all metrics with dc=us-east-1
  # rack = "1a"
  ## Environment variables can be used as tags, and throughout the config file
  # user = "$USER"
  influxdb_database = "default"

Да, я очень неоригинален в этом плане. Теперь ко всему, что собирает telegraf по умолчанию добавляется тэг influxdb_database со значением default.

Теперь добавляем сборку данных с mqtt. Заполняем файл /etc/telegraf/telegraf.d/mqtt.conf

[[inputs.mqtt_consumer]]
  servers = ["tcp://127.0.0.1:1883"]

  ## Topics that will be subscribed to.
  topics = [
    "/devices/+/controls/temperature",
    "/devices/+/controls/battery",
    "/devices/+/controls/humidity",
    "/devices/+/controls/pressure",
    "/devices/+/controls/co2",
    "/devices/+/controls/MCU Temperature",
    "/devices/+/controls/CPU Temperature",
    "/devices/dark_room_power/controls/voltage",
    "/devices/dark_room_power/controls/power",
    "/devices/sleeping_room_power2/controls/voltage",
    "/devices/sleeping_room_power2/controls/power",
  ]

    data_format = "value"
    data_type = "float"

[inputs.mqtt_consumer.tags]
    influxdb_database = "mqtt"

Тут тоже все просто: указываем адрес сервера, указываем, на какие топики подписаться, их формат и последней строчкой меняем значение тега на mqtt. И теперь самая магия:

[[outputs.influxdb_v2]]
urls = ["http://influxdb.hlevnoe.lan:8086"]
token = "xf3w6SKIPSKIP7z1hPQ=="
organization = "hlevnoe"
bucket = "hlevnoe"
[outputs.influxdb_v2.tagpass]
influxdb_database = ["default"]

И сравните с вторым

[[outputs.influxdb_v2]]
urls = ["http://influxdb.hlevnoe.lan:8086"]
token = "xf3w6nSKIPSKIPvam7z1hPQ=="
organization = "hlevnoe"
bucket = "mqtt"
[outputs.influxdb_v2.tagpass]
influxdb_database = ["mqtt"]

Наверняка для матерых инфлюксоводов это покажестя легкой шуткой, но я честно потратил пару часов на раскуривание функционала tagpass. Больше, правда, на выяснение, как и куда его правильно прописать. В общем, теперь все с influxdb_database = default попадает в бакет hlevnoe, а mqtt в mqtt.

Запустив все это и убедившись в отсутствии ошибок, можно вернуться в influx. Там есть простенький data explorer, позволяющий потыкаться и порисовать графики. Даже можно простейшие дашборды собрать!

Вот, к примеру, график потребления электричества у морозильника.

Или график температуры у меня за окном

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

Готовим котёнка

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

В общем, я решил сменить терминалку. Немного подумал и составил офигенно длинный лист требований:

  • Терминалка должна работать под Linux, MacOS и Windows (WSL)
  • Она должна работать одинаково. То есть один и тот же параметр в конфиге должен приводить к одним и тем же изменениям в поведении.
  • Терминалка должна уметь в truecolor.
  • Терминалка должна уметь в шрифтовые лигатуры.

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

Я не понимаю, чего сложного в подобной конвертации символов -> >> <> != ? Но, например, авторы gnome terminal не осилили подобного и отмазались, что не для всех языков это может работать. Ну сделали бы не для всех…

И, внезапно, всем моим хотелкам удовлетворила только одна терминалка – kitty. Если быть до конца честным, то нет, были и другие, но они не такие гламурные. Ставить котёнка можно 100500 способами, но я предпочел через пакетный менеджер.

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

font_family Fira Code
font_size 12
cursor_shape block
cursor_shape_unfocused hollow
shell_integration no-cursor
scrollback_lines 10000
sync_to_monitor yes
remember_window_size  yes
initial_window_width  800
initial_window_height 600
include theme.conf
tab_bar_style slant
update_check_interval 0
term xterm-256color
paste_actions quote-urls-at-prompt
background_opacity 1
confirm_os_window_close 0
map super+n new_os_window_with_cwd
map super+t new_tab_with_cwd
map super+w close_os_window
map super+c copy_to_clipboard
map super+v paste_from_clipboard

Последние строчки – это дань моей лени, чтобы новые окошки открывались как на макоси. Win+n и не надо пальцы ломать об Ctrl+Shift+n . Мелочь, а удобно. Ну и файлик theme.conf, честно спертый из интернета и имитирующий тему homebrew

# Theme ported from the Mac Terminal application.

background #000000
foreground #00ff00
cursor #23ff18
selection_background #083905
color0 #000000
color8 #666666
color1 #990000
color9 #e50000
color2 #00a600
color10 #00d900
color3 #999900
color11 #e5e500
color4 #0000b2
color12 #0000ff
color5 #b200b2
color13 #e500e5
color6 #00a6b2
color14 #00e5e5
color7 #bebebe
color15 #e5e5e5
selection_foreground #e5e5e5

И вот я уже почти неделю живу на двух операционках и с одним терминалом. Нормально …

Теперь операционко-специфичные штуки.

MacOS: надо в ENV переменные добавить KITTY_CONFIG_DIRECTORY=~/.config/kitty/ , иначе котенок хз где хранит конфиги. А так все в одинаковом месте. Чтобы сменить иконку, надо ее просто рядом с конфигом положить и обозвать kitty.app.png.

Linux: чтобы сменить иконку, надо сделать desktop файл, аналогичный нижеприведенному, и положить его в .local/share/applications/ . Главная боль – путь до иконки должен быть абсолютным.

[Desktop Entry]
Version=1.0
Type=Application
Name=kitty
GenericName=Terminal emulator
Comment=Fast, feature-rich, GPU based terminal
TryExec=kitty
StartupNotify=true
Exec=kitty
Icon=/home/kiltum/.config/kitty/kitty.app

Все 🙂

Умный дом. MQTT сервер

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

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

Вообще у меня уже есть один mqtt сервер, встроенный в wirenboad. Но есть два больших но: 1) сам по себе wirenboard очень дохлый (хотя народ радостно на него даже Home Assistant в докере водружает) и 2) у меня будет очень много устройств, общающихся по MQTT.

Поэтому решение простое: поднимаем на виртуалке MQTT сервер и заставляем всех с ним работать. А кто не умеет или умеет не кошерно – забирать с тех данные самим. Для реально больших нагрузок или отказоустойчивости народ ставит EMQX, но у меня такого не будет, поэтому использую mosquitto.

apt install mosquitto mosquitto-clients

Все настройки оставляю по умолчанию, просто добавляю один мост wirenboard->mosquitto.

# cat /etc/mosquitto/conf.d/wirenboard.con
connection wirenboard
address wirenboard:1883
bridge_insecure true
topic # in 0

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

mosquitto_sub -t \#

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

Первая ачивка получена!

Даешь звук в vmware

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

Скопировал файлик, заменил значения … и вуаля! Звук снова в наличии.

Навожу порядок в музыке

Довольно долго я таскаю с собой архив музыки. Первые треки в нем датируются аж 1995 годом. Естественно, что за все это время внутри образовалась каша. Я много раз пытался подойти к этой свалке, что бы разгрести ее содержимое и разложить все по полочкам. Однако регулярно обламывался из-за банальной лени: все-таки раскидать почти 100 тысяч файлов нужно адское терпение.

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

Наконец в очередной раз я подошел к этой свалке. Тыкался, тыкался, смотрел на всякие редакторы тегов и горестно вздыхал. Пока не решил погуглить, как можно для всего этого поиспользовать всякие шазамы и прочие новомодные (почти) штучки. И вуаля!

https://picard.musicbrainz.org/

Оставлю эту ссылку отдельной строкой. Жрет mp3, ищет по аудиотпечатку что же это за трек и заполняет теги, добавляет обложку и раскладывает получившееся красиво. Я в совершеннейшем восторге. На тестовой выборке в 7 тыщ файлов не нашла соответствие только для 3. Но их никто не знает, ни яндекс, ни яблоки. Мелочь …

Zimbra lets encrypt

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

#!/bin/bash
cp -f /etc/letsencrypt/live/mail.ka12.co/* /opt/zimbra/ssl/letsencrypt/
wget -O /tmp/ISRG-X1.pem https://letsencrypt.org/certs/isrgrootx1.pem.txt
cat /tmp/ISRG-X1.pem > /opt/zimbra/ssl/letsencrypt/fullchain.pem 
cat /etc/letsencrypt/live/mail.ka12.co/fullchain.pem >> /opt/zimbra/ssl/letsencrypt/fullchain.pem 

chown zimbra:zimbra /opt/zimbra/ssl/letsencrypt/*
runuser -u zimbra /opt/zimbra/bin/zmcertmgr verifycrt comm /opt/zimbra/ssl/letsencrypt/privkey.pem /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/fullchain.pem
runuser -l zimbra -c 'zmcontrol stop'
cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.`date "+%Y%m%d"`

runuser -u zimbra cp /opt/zimbra/ssl/letsencrypt/privkey.pem /opt/zimbra/ssl/zimbra/commercial/commercial.key
runuser -u zimbra /opt/zimbra/bin/zmcertmgr deploycrt comm /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/fullchain.pem
runuser -l zimbra -c '/opt/zimbra/bin/zmcertmgr deploycrt comm /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/fullchain.pem'
runuser -l zimbra -c 'zmcontrol start'

mail.ka12.co замените на свой домен. Принцип простой – сначала любым привычным способом получаете сертификат через LE, а потом запуская скрипт выше засовываете сертификат в zimbra

Загоняем маки спать

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

Решение очень простое:

  1. Спрашиваем у мака, сколько раз и когда он просыпается: pmset -g log|grep due
  2. Увидев, что он просыпается практически каждую минуту, запрещаем ему поддерживать соединения: sudo pmset -b tcpkeepalive 0

Плюс: мак теперь переживает ночь, теряя 1-2% заряда батареи

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

Новый датацентр. Сертификаты в почту

Для своих нужд я обычно ставлю Zimbra Open Source Edition. Простой, дуракоустойчивый почтовый сервер со всякими необходимыми плюшками. Но есть в нем одна маленькая проблема: по умолчанию он генерит самоподписанные сертификаты, на которые ругаются всякие почтовые клиенты. Значит, надо подсунуть сертификаты от letsencrypt

Сделаем на сервере каталог для сертификатов

mkdir -p /opt/zimbra/ssl/letsencrypt/
chown zimbra:zimbra /opt/zimbra/ssl/letsencrypt/

Опять же, маленький скриптик, который пускается руками после обновления сертификатов и проверки готовности всего ко всему. Он же zimbra_check

cat /opt/www/chain.pem >> /etc/letsencrypt/live/mail.ka12.co/fullchain.pem 
scp  /etc/letsencrypt/live/mail.ka12.co/* root@mail:/opt/zimbra/ssl/letsencrypt/
ssh root@mail "chown zimbra:zimbra /opt/zimbra/ssl/letsencrypt/*"
ssh root@mail "runuser -u zimbra /opt/zimbra/bin/zmcertmgr verifycrt comm /opt/zimbra/ssl/letsencrypt/privkey.pem /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/fullchain.pem"

Логика понятна из текста: добавляем CA ключ (отсюда) в цепочку, копируем все это в потроха зимбры и проверяем, согласится ли она это съесть. Обычно ответ “да”, но иногда она взбрыкивает и надо смотреть, чего же ей не нравится. Если ошибок нет, то можно запустить zimbra_deploy

#!/bin/bash
ssh root@mail "runuser -l zimbra -c 'zmcontrol stop'"
ssh root@mail "cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.`date \"+%Y%m%d\"`"
ssh root@mail "runuser -u zimbra cp /opt/zimbra/ssl/letsencrypt/privkey.pem /opt/zimbra/ssl/zimbra/commercial/commercial.key"
ssh root@mail "runuser -u zimbra /opt/zimbra/bin/zmcertmgr deploycrt comm /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/fullchain.pem"
ssh root@mail "runuser -l zimbra -c '/opt/zimbra/bin/zmcertmgr deploycrt comm /opt/zimbra/ssl/letsencrypt/cert.pem /opt/zimbra/ssl/letsencrypt/fullchain.pem'"
ssh root@mail "runuser -l zimbra -c 'zmcontrol start'"

Он тормозит нафиг всю зимбру, бекапит и деплоит сертификаты и снова запускает все назад.

Новый датацентр. Web

Что самое главное во всем этом? Правильно, наши интернетики с кисками и прочим. А значит, надо обеспечить заход снаружи внутрь по https

На данный момент я знаю всего 3 способа: с помощью nginx, apache и traefik. Apache как-то старо, traefik наоборот, слишком новомодно.

Предупреждаю сразу: использовать в докере nginx c nginx-gen и companion, как описано вот тут https://github.com/gilyes/docker-nginx-letsencrypt-sample – нельзя. Проблема простая: генератор тупо мешает ip бэкэндов как ему понравится.

Краткий план: ставим виртуалку

virt-builder centos-7.4 --arch amd64 -o nginx.ka12.co.img --size 20G --format qcow2 --hostname nginx.ka12.co --ssh-inject root:file:/root/multik.sshkey --root-password file:root_pass --copy-in ifcfg-eth0:/etc/sysconfig/network-scripts/ --copy-in resolv.conf:/etc
virt-install --name nginx.ka12.co --network bridge=virbr100 --memory 2048 --disk path=nginx.ka12.co.img --import --os-variant centos7.0 --graphics vnc,listen=172.16.100.1 --noautoconsole

бутстрапим ее

ansible-playbook -i inventory -l nginx* centos-bootstrap.yml

Добавляем в нее нужное

yum -y install freeipa-client && ipa-client-install --mkhomedir
yum install certbot python2-certbot-nginx nginx

И запускаем nginx

openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096
systemctl start nginx

Берем из git (https://github.com/kiltum/newdc/tree/master/nginx) и кладем в /opt/www

Там два темплейта – первый для просто “сделай так, что бы nginx узнал о сайте”, а второй – уже готовый полноценный конфиг.

Ну а что делает скрипт new_site, думаю разберетесь сами. Только email правильный пропишите.

Запускаем ./new_site mail.ka12.co и вот результат:

После меняем конфиг сайта как нам надо и вуаля! Теперь по приходу емайла от letsencrypt заходим и обновляем все сразу.

Новый датацентр. Докер

Следующим большим шагом в постройке “датацентра” у меня будет разворачивание докера. Без него нынче никуда, да и удобный он, зараза.

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

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

Добываю/делаю правильный ifcfg фаил

cat ifcfg-eth0
TYPE="Ethernet"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="no"
NAME="eth0"
DEVICE="eth0"
ONBOOT="yes"
IPADDR="172.16.100.11"
PREFIX="24"
GATEWAY="172.16.100.1"
NM_CONTROLLED="no"

Добавляю пароль рута в файл root_pass и кладу рядом свой публичный ключ. Рядом же resolv.conf. Затем создаю образ диска

virt-builder centos-7.4 --arch amd64 -o docker1.ka12.co.img --size 80G --format qcow2 --hostname docker1.ka12.co --ssh-inject root:file:/root/multik.sshkey --root-password file:root_pass --copy-in ifcfg-eth0:/etc/sysconfig/network-scripts/ --copy-in resolv.conf:/etc

И запускаю машину с ним.

virt-install --name docker1.ka12.co --network bridge=virbr100 --memory 8096 --disk path=docker1.ka12.co.img --import --os-variant centos7.0 --graphics vnc,listen=172.16.100.1 --noautoconsole

Минута и виртуалка готова. Меняем ip адрес в конфиге+хостнейм и повторяем так еще два раза. Все, ноды для кластера готовы.

Добавляем их в инвентори и бутсрапим до приемлемого состояния.

ansible-playbook -i inventory -l docker* centos-bootstrap.yml

Делать еще один плейбук лень, поэтому просто прохожу по хостам с командой

yum -y install freeipa-client && ipa-client-install --mkhomedir

ansible-playbook -i inventory docker-install.yml

И на любой машине проверяю, что докер докерит

docker run hello-world

Так как у нас инфраструктура пока из одного хоста, заморачиваться распределенным хранилищем нет смысла от слова совсем. Поэтому просто раскидаю по хостам nfs

На хосте:

mkdir -p /opt/nfs
chmod 777 /opt/nfs
cat /etc/exports
/opt/nfs 172.16.0.0/16(rw,sync,no_root_squash,no_all_squash)
systemctl restart nfs-server

Проверяю, что увидит докер

# showmount -e 172.16.100.1
Export list for 172.16.100.1:
/opt/nfs 172.16.0.0/16

Создаю супер-каталог для volume

mkdir -p /opt/nfs/data
chmod 777 /opt/nfs/data

Теперь на докер-хосте создаю volume


docker volume create --driver local --opt type=nfs --opt o=addr=172.16.100.1,rw --opt device=:/opt/nfs/data --name data

И проверяю

[root@docker1 ~]# docker volume ls
DRIVER VOLUME NAME
local data
[root@docker1 ~]# docker volume inspect data
[
{
"CreatedAt": "2018-01-27T08:46:56-05:00",
"Driver": "local",
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/data/_data",
"Name": "data",
"Options": {
"device": ":/opt/nfs/data",
"o": "addr=172.16.100.1,rw",
"type": "nfs"
},
"Scope": "local"
}
]

Теперь проверяю, как с этим будут работать контейнеры

docker container run -ti -v data:/data alpine sh

Там в /data можно посоздавать файлики и вообще поиграться “как будто в реальной жизни”.

Новый датацентр. Сервер.

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

Но терять кучку удобных штук типа докера нет желания, поэтому буду строить сразу и с запасом. Итак, что мне охота

1. Централизованное управление аккаунтами. Для всяких ssh, git и прочим
2. KVM и докер.
3. Чистый, не засранный хост. Не хочу видеть по интерфейсу и 10 правил на каждый контейнер.
4. Разное.

Итак, стадия номер 1 или “подготовка”. Все использованное мной можно найти тут: https://github.com/kiltum/newdc Ну и я подозреваю, что вы уже имеете опыт администрирования linux, поэтому буду только намечать путь.

Арендую новый сервер. Hetzner, leaseweb – их много. И ставлю туда пустую и голую CentOS 7. Никаких панелей, рюшечек и прочего. Из моих уже личных требований – поставить все на raid1.

Бутстраплю ее с помощью ansible и роли centos-bootstrap.yml. Там снос selinux, firewalld, установка ntp и прочих пакетиков и обновление системы. Самый необходимый минимум.

Ставлю KVM. Эта операция одноразовая, поэтому можно и руками.

yum install qemu-kvm libvirt libvirt-python libguestfs-tools virt-install

Сношу дефаултную сеть от KVM. Это автоматически избавляет меня от кучки правил в iptables.

virsh net-autostart --disable default
virsh net-destroy default

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

modprobe dummy numdummies=1
echo "dummy" > /etc/modules-load.d/dummy.conf
echo "options dummy numdummies=1" >> /etc/modprobe.d/dummy.conf

Генерирую для него мак-адресс (в принципе можно от балды, но лучше что бы с первыми октетами от KVM – так симпатичней)

hexdump -vn3 -e '/3 "52:54:00"' -e '/1 ":%02x"' -e '"\n"' /dev/urandom

И делаю конфиг-фаил для этого интерфейса

cat > /etc/sysconfig/network-scripts/ifcfg-dummy0
DEVICE=dummy0
MACADDR=52:54:00:1b:e1:80
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
IPV6INIT=no
BRIDGE=virbr100

и описываю бридж

cat > /etc/sysconfig/network-scripts/ifcfg-virbr100
DEVICE=virbr100
NAME=virbr100
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Bridge
DELAY=2
STP=on
IPADDR=172.16.100.1
NETMASK=255.255.255.0
IPV6INIT=no

Поднимаю созданное

ifup virbr100

В результате я получил следующее

2: dummy0: mtu 1500 qdisc noqueue master virbr100 state UNKNOWN qlen 1000
link/ether 52:54:00:1b:e1:80 brd ff:ff:ff:ff:ff:ff
inet6 fe80::5054:ff:fe1b:e180/64 scope link
valid_lft forever preferred_lft forever
...
5: virbr100: mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 52:54:00:1b:e1:80 brd ff:ff:ff:ff:ff:ff
inet 172.16.100.1/24 brd 172.16.100.255 scope global virbr100
valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe1b:e180/64 scope link
valid_lft forever preferred_lft forever

Разрешаю форвардинг пакетиков между интерфейсами

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.forwarding=1" >> /etc/sysctl.conf
sysctl -p

Для полноценной работы виртуалок я добавляю в стандартный набор правил еще одно, которое обеспечивает виртуалкам выход в интернет. Вместо иксиков подставьте свой внешний ipшник

-A POSTROUTING -o eth0 -j SNAT --to-source x.x.x.x

И в принципе все, я готов создать первую виртуалку.

virt-install --name head.ka12.ko --network bridge=virbr100 --memory 1024 --disk path=head.ka12.co.img,size=30 --cdrom ../iso/CentOS-7-x86_64-Minimal-1708.iso --graphics vnc,listen=172.16.100.1 --noautoconsole

И получаю к ней доступ по VNC

virsh vncdisplay head.ka12.co

Так как пока нету ничего даже похожего на нормальный доступ, пробрасываю VNC порт на локальную машину

ssh -L 5901:172.16.100.1:5900 kiltum@ka12.co

Дальше открываю VNC клиент и по адресу localhost:5901 получаю консоль виртуалки. Дальше как обычно “Далее-далее-подождать и перезагрузить”. Опять же можно было заморочиться и использовать автостарты, но мне лень такое делать на редких и одноразовых операциях.

У этой новой виртуалки будет совершенно ожидаемый адрес 172.16.100.2. После “ребута” инсталлятора снова запускаем и ставим в автозапуск

virsh start head.ka12.co
virsh autostart head.ka12.co

Первым делом надо решить вопрос с доступом в мою “инфраструктуру”. Тут пока ничего лучше не придумали, как openvpn. Запихиваю в /etc/resolv.conf временный адрес DNS сервера и начинаю

yum -y install epel-release mc
yum -y install openvpn easy-rsa

Меняю конфиги openvpn

cat server.conf
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 172.16.101.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 172.16.0.0 255.255.0.0"
;push "redirect-gateway def1 bypass-dhcp"
;push "dhcp-option DNS 172.16.100.2"
;push "dhcp-option DOMAIN ka12.co"
duplicate-cn
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
verb 3

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

mkdir -p /etc/openvpn/easy-rsa/keys
cp -rf /usr/share/easy-rsa/2.0/* /etc/openvpn/easy-rsa
mcedit /etc/openvpn/easy-rsa/vars
cp /etc/openvpn/easy-rsa/openssl-1.0.0.cnf /etc/openvpn/easy-rsa/openssl.cnf
cd /etc/openvpn/easy-rsa
source ./vars
./clean-all
./build-ca
./build-key-server server
./build-dh
cd /etc/openvpn/easy-rsa/keys
cp dh2048.pem ca.crt server.crt server.key /etc/openvpn
cd /etc/openvpn/easy-rsa
./build-key client

Разрешаю форвардинг

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.forwarding=1" >> /etc/sysctl.conf
sysctl -p

и запускаю openvpn

systemctl enable openvpn@server.service
systemctl start openvpn@server.service

так как там все по умолчанию, очищаю правила фаерволла на виртуалке

iptables -F

Все, теперь на хосте надо открыть порт 1194/udp и пробросить его на виртуалку

-A PREROUTING -d x.x.x.x/32 -i eth0 -p udp --dport 1194 -j DNAT --to-destination 172.16.100.2
-A INPUT -p udp -m state --state NEW -m udp --dport 1194 -j ACCEPT

Добавляю роутинг до подсети vpn

ip route add 172.16.101.0/24 via 172.16.100.2

cat > /etc/sysconfig/network-scripts/route-virbr100
172.16.101.0/24 via 172.16.100.2 dev virbr100

Делаю темплейт клиентского конфига

cat client.template
client
dev tun
proto udp
remote vpn.ka12.co 1194
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
verb 3
key-direction 1
remote-cert-tls server
mssfix
<ca>
ca.crt
</ca>
<cert>
client.crt
</cert>
<key>
client.key
</key>
<tls-auth>
ta.key
</tls-auth>

И заполняю его (в дальнейшем я сделал маленький скрипт gen_config.sh)

sed -e '/ca.crt/rca.crt' -e '/client.crt/reasy-rsa/keys/client.crt' -e '/client.key/reasy-rsa/keys/client.key' -e '/ta.key/rta.key' -e '/crt/d' -e '/\.key/d' client.template | sed -e 's/#.*$//' -e '/^$/d' > cl.ovpn

Цепляюсь и проверяю доступность хоста через vpn

traceroute 172.16.100.1
traceroute to 172.16.100.1 (172.16.100.1), 64 hops max, 52 byte packets
1 172.16.101.1 (172.16.101.1) 53.941 ms 48.797 ms 47.938 ms
2 172.16.100.1 (172.16.100.1) 49.186 ms !Z 48.813 ms !Z 49.865 ms !Z

Пробрасываю ключ, бутстраплю виртуалку и ставлю в ней FreeIPA
ssh-copy-id root@172.16.100.2

ansible-playbook -i inventory -l head.ka12.co centos-bootstrap.yml

yum -y install ipa-server bind bind-dyndb-ldap ipa-server-dns

ipa-server-install --setup-dns --mkhomedir --allow-zone-overlap

Меняю шелл по умолчанию

kinit admin
ipa config-mod --defaultshell=/bin/bash

Внезапно оказалось, что FreeIPA с 1 гигом памяти стартует очень тяжко. Добавляю памяти

virsh setmaxmem head.ka12.co 4G --config
virsh setmem head.ka12.co 2G --config

И включаю VPN на полную

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 172.16.100.2"
push "dhcp-option DOMAIN ka12.co"

Добавляю pam сервис

cd /etc/pam.d/
ln -s system-auth openvpn

Добавляю группу openvpn и sshd и заношу в нее меня. В принципе все тоже самое можно сделать через веб-интерфес FreeIPA.

ipa hbacsvc-add openvpn
ipa hbacrule-add allow_openvpn
ipa hbacrule-add-service allow_openvpn --hbacsvcs=openvpn
ipa hbacrule-add-user allow_openvpn --user=kiltum
ipa hbacrule-add-service allow_sshd --hbacsvcs=sshd
ipa hbacrule-add-user allow_sshd --user=kiltum
ipa hbacrule-add-host allow_sshd --hosts=head.ka12.co
ipa hbactest --user=kiltum --host=head.ka12.co --service=sshd

Теперь остался последний шаг. Добавляю в конфиг сервера

plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

а в конфиг клиента

auth-user-pass

И всё.

В случае проблем проверить работу авторизации можно и прямо на стороне сервера:

pamtester openvpn kiltum authenticate

Что же получил на данном этапе?

1. Хост, на котором крутится только KVM и больше ничего. А значит: ошибиться негде, ломать тоже особо нечего.
2. OpenVPN, доступ до которого защищен сразу двумя методами: клиентским сертификатом и логином-паролем.
3. Внутренний DNS, который снаружи никак не виден.
4. Управление пользователями/группами/сервисами. Располагается исключительно во внутренней сети.
5. Даже если опустить везде фаирволлы, то ничего нового не будет доступно снаружи.

Новый сервер на CentOS 7

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

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

Первое, что необходимо сделать – отрубить 99,9% автоподбиральщиков паролей.

# cat /etc/sysconfig/iptables|grep 22
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 300 --hitcount 4 --name DEFAULT --rsource -j DROP
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT

Затем ставим sslh – мультиплексор протоколов. Его задача – дать доступ до основных сервисов через 443 порт.

# cat /etc/sslh.cfg
# This is a basic configuration file that should provide
# sensible values for "standard" setup.

verbose: false;
foreground: true;
inetd: false;
numeric: false;
transparent: false;
timeout: 2;
user: "sslh";
# Change hostname with your external address name.
listen:
(
{ host: "edge"; port: "443"; }
);
protocols:
(
{ name: "ssh"; service: "ssh"; host: "localhost"; port: "22"; },
{ name: "openvpn"; host: "localhost"; port: "1194"; },
# { name: "xmpp"; host: "localhost"; port: "5222"; },
{ name: "http"; host: "localhost"; port: "80"; },
{ name: "ssl"; host: "localhost"; port: "443"; log_level: 0; },
{ name: "anyprot"; host: "localhost"; port: "443"; }
);

Как видите, конфигурация 100% стандартная, за исключением того, что мне не нужен xmpp. после обкатки можно будет и закрыть “обычный” ssh порт совсем. Минусом станет то, что в логах и утилитах пользователи станут заходить через localhost. Реальные адреса будут видны только через journald

… и все. В остальном инсталляция CentOS 7 не требует дальнейших движений напильником.

Запрет macOS менять имя машины

Довольно часто я со своим макбуком попадаю в чужие сети. И некоторые (не будем показывать пальцем) в DHCP ответе отдают новое имя машины. А macOS как и положено, меняет свое имя на указанное. Мелочь, но напрягает когда в терминале видишь непривычное имя.

Решение простое: сделать скрипт/выполнить следующие команды. Вместо mbook поставьте свое

NAME="mbook"
sudo scutil --set HostName ${NAME}
sudo scutil --set LocalHostName ${NAME}
sudo scutil --set ComputerName "${NAME}"

Решение простое: DHCP может переписать HostName, но приоритет у LocalHostName и остального выше.

Кто такие DevOps?

Слово модное…это да!! Но если публиковать как «Системный администратор», то откликаются мальчики-настройщики компов, если «Программист», то жесткие программеры без фантазии © Объяснения одной дамы

Любой, кто интересовался этой темой, знают, что данное сокращение произошло от Development и Operations. Или если перевести на русский – Программисты и Сисадмины. Да, operations дословно переводится не так, но здесь я использую слово «сисадмины» в самом широком смысле.

Кто такие «сисадмины»? Если кратко, то это именно те люди, на руках которых держится вся инфраструктура. Где-то этим словом называют приходящих «аникейщиков», которые меняют картриджи в принтере и изредка чистят компьютеры от вирусов и троянов. А где-то это целые залы людей, разбитых на свои касты. Кто-то занимается сетями, кто-то базами данных, а кто-то обслуживанием датацентров и их инфраструктуры. Титаны антистрессовых методик.

Точно такое же широкое определение имеют и «программисты». И тот, кто пишет на javascript проверку ввода на сайт и тот, кто добавляет код во внутренний модуль корпоративной системы – все они «программисты». И даже тот, кто пишет на встроенном языке 1С, тоже программист, что бы об этом не думали другие.

В чем же основная причина, приведшая к появлению девопсов? Для этого необходимо немного углубиться в специфику работы каждой «секты».

Для сисадмина самое важное это то, что бы вверенная ему система работала без перебоев. Не обращая внимания на тупых пользователей, идиотов-разработчиков, отключения питания и поломок оборудования. Все, абсолютно все, рассматривается с точки зрения надежности. И венцом этой надежности является достижение времени доступности системы в 99,999% (или «5 девяток»). Поверьте, заставить современные системы работать так, чтобы их время недоступности не превышало 5 минут в год – это очень сложная задача. И когда вы добиваетесь, что максимальное время, когда подчиненная система может сказать «ой, я не могу» – это 6 секунд в сутки, то спокойно можете брать с полки пирожок.

У разработчиков же другое положение. Над ними коршунами вьются кровососы-менеджеры, которые постоянно требуют новый функционал, который должен работать быстрее или лучше. И всё это великолепие не должно поломать уже существующий функционал. И код, который прекрасно работает на твоей машине, почему-то отказывается работать как надо даже в тестовом окружении. А еще эти гамадрилы-сисадмины не дают нормально покопаться в получившейся у них системе и понять, что пошло не так даже после успешно пройденных тестов. Эти чудаки на букву «м» постоянно орут как резанные и набрасывают говен на вентилятор при любом чихе. И никто кроме коллег не способен оценить красоты получившегося кода или изящества алгоритма.

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

В эту сложную и нервную обстановку добавляет перцу то обстоятельство, что «сисадмины» никогда не писали код размером больше чем на пару страниц, а «разработчики» никогда не обслуживали написанные ими системы (а часто даже и не пользовались ими). Результат абсолютно предсказуемый: тотальное непонимание друг друга и подковёрные войны.

Вот в горниле этих битв и родилось новая каста – DevOps или девопсы. Как водится, поначалу были перегибы с обоих сторон и презрение к «переметнувшимся». Плюс из-за молодости самого термина у него множество толкований и определений. Кто-то считает девопс методологией, направленной на автоматизацию и увеличение числа релизов, а кто-то – на уменьшение ошибок. Я же считаю, что девопс – это прежде всего человек, главной задачей которого является снижение головной боли у программеров, сисадминов и QAшников. А те уже сами напишут, отконфигурят и оттестируют нужное.

Ибо если поглядеть с любой стороны, девопс будет выглядеть как некий недоучка, лишь в редких случаях способный выдать что-то толковое. Бегает со своими скриптами наперевес, чего-то там курочит в коде и лишь принадлежность к «своим» не позволяет его послать в очень далекое эротическое путешествие. У меня нет ни капли сомнения, что программер переиграет девопса в программировании, сисадмин – в администрировании, а тестировщик – на своем тестировочном поле.

Но ценность девопса именно в стоянии нараскоряку в постоянном процессе разрушения стен непонимания между «сейчас зальем, а там разгребут» и «чего там эти опять одноклеточные выделили». Да, сложно, но как показывает практика, вполне возможно.

Сейчас, в самом начале жизни девопсов (с 2009 года же), самой основной их задачей является автоматизация. Объёмы того, что необходимо автоматизировать – поистине ужасающие. Ведь все (программеры и сисадмины) непрерывно трудятся над увеличением завалов не один десяток лет.

Что обычно автоматизируют?
– Развертывание очередного релиза кода. В тест, в стейджинг, в продакшн. Да хоть на машину разработчика. С необходимыми сервисами и данными. Разных версий.
– Обновление. Сервера, сервисы и сайты. Быстро и еще быстрей.
– Управление инфраструктурой. Сегодня 100 серверов в одном датацентре, завтра 500 в трех, а послезавтра 1000 снова в одном. Мониторинг, сбор логов и куча других мелких задач, которые раньше выполнялись вручную или не выполнялись совсем.

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

Широкий характер выполняемых задач автоматически формирует и необходимые требования к девопсам:

– Необходимо знать все используемые продукты, языки и технологии. Только тогда стандартная для девопса задача «скрестить ужа с ежом и заставить их летать» автоматически становится выполнимой. Сисадмин сделал бекап? А девопс должен забрать этот бекап, выкинуть из него всякую конфиденциальную информацию и засунуть в систему (которую построил он же), которая позволит разработчикам и тестировщикам без опаски гонять свои творения на «почти продакшене».

– Наличие знаний (есть еще умное слово «компетенций») по всему процессу разработки. Причем знания должны быть реальными и боевыми. Потому что некому кроме девопса остановить программера, когда он решит напрямую засовывать json в обычную базу данных. Для разработчика в этом нет ничего крамольного (база поддерживает? поддерживает!), для сисадмина тоже (ну растет база и требует больше ресурсов – это нормально), а DBA по привычке обматерит всех и молча пойдет строить индексы и партиционировать базу. А то, что полученная конструкция могла быть быстрее и надежней – это никому не интересно. Кроме девопсов.

Нет ни того, ни другого? Тогда получаются люди, которые прекрасно характеризуются как «чуваки с накачанным ЧСВ и недержанием кода».

Требования большие? Да, большие. Зато и награда велика.

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

P.S. Ну и денег дают нормально.

Пробую ATI 2017 на зуб. День 3. Разрыв шаблонов.

Сегодня я хотел заняться версией Acronis True Image для Windows, но в комментах меня спросили: а каким образом ATI для Android восстанавливает программы? И в самом деле, такой функционал не был заявлен … Результат: я посыпаю голову пеплом и каюсь в своем несовершенстве. Программы и прочее восстановил толи гугл, толи самсунг своим софтом. У меня SGS6 и пока я там вводил пароли и делал прочие действия после сброса, эти злобные искажатели истины все вернули “как было”. Издержки цифрового мира с хорошим каналом в интернет.

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

ati03-01

Не важно, из-за чего произошла ошибка (в данном случае я злобно выключил WiFi прямо на взлете), ATI будет висеть на этом экране, даже если условия изменились. Проверил путем оставления телефона на ночь. Мелочь, но очень неприятная мелочь. (делая пассы руками в сторону офиса Acronis) я полностью уверен что скоро это поправят …

А теперь об обидном для меня. Я как-то привык, что софт для маков лучше и функциональней софта для виндовса. Или как минимум выходит раньше. Или хотя-бы просто симпатичней. Но ATI для виндовса полностью порвал мне этот шаблон. Windows версия превосходит OS X версию как президентский лимузин ржавую “копейку”. И то и то доставит вашу пятую точку из пункта А в пункт Б, но на лимузине это будет приятней.

Так вот. ATI для Windows и есть тот самый лимузин. Сравните окно настроек для OS X (честно, я его нашел только после того, как мне виндовс версия ненавязчиво так его подсунула)

ati03-02

И окно настроек для Windows

ati03-03

И да. Данные окна прямо и однозначно указывают на мою ошибку вчера. Acronis True Image является полноценным софтом для резервного копирования и только Android версия ущемленная. Расставив галочки как вам надо, можно получить любую схему копирования. В общем, был категорически не прав, в чем и подписываюсь.

А сколько в Windows-версии опций! Начиная от возможности слать оповещения о проведенном копировании и предупреждения о заканчивающемся месте и заканчивая мелочами типа “при копировании на внешний диск сделай так, что бы с него можно было загрузиться”. Про приятные мелочи типа “разбивай архив так, что бы залез на CD/DVD/BlueRay/Ещекуда” даже не стоит упоминать. Оно там просто есть.

На этом моменте проверяю, что все везде зелененькое …

ati03-04

… все везде копируется и “в облако” и “на диск”. Теперь я насильно “забуду” про софт на некоторое время, а потом посмотрю, что надо будет делать, когда “внезапно” что-нибудь случится.

Пробую ATI 2017 на зуб. День 2. Восстановление …

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

Если коротко, то опять во всем виноваты мои любимые маркетолухи. Дело в том, что Acronis True Image – это софт не для резервного копирования, а для disaster recovery. Дословный перевод: “восстановление после аварии”. В чем разница?

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

Софт для восстановления после аварии действует по другому. Вся его задача это обеспечить максимально быстрое восстановление системы “как было ДО”. И вот Acronis True Image – именно софт для восстановления после аварии. Остальное по такому же принципу, что и в “облаках”.

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

Решил и я проверить, насколько будет мне хорошо. Беру телефон и сбрасываю его в “заводские” настройки. Прохожу все положенные “далее-далее” и первым делом ставлю ATI. Там сразу же давлю на “восстановление”.

Точно такой же экран, как и при копировании, только про восстановление. И … это было реально быстро. Буквально за 5 минут я получил свой телефон назад. Со всем настроенным и предустановленным софтом. Единственное напоминание, что текущее состояние не забекаплено:

ati02-01

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

Теперь с десктопным софтом. А вот тут все плохо. Вообще и полностью.

Во-первых, функционал “архива”. Ну это классический dropbox/onedrive/придумайте сами. Выглядит это так

ati02-02

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

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

ati02-03

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

ati02-04

И даже более того, один раз я все-таки скачал назад свой удаленный файл. Да, я скачал назад удаленное.

Но представьте свое состояние “у меня все упало, все разрушилось”, а тут такое …

Пробую ATI 2017 на зуб. День 1. Бэкап …

Зачем нужно резервное копирование, если сейчас все можно хранить в облаках? Ответ простой: облака обеспечивают доступность, а резервное копирование – сохранность. Толку иметь доступ к облаку, если до этого из них удалил самый нужный на текущий момент файл? Да, некоторые облачные провайдеры дают “хранение 5ти последних копий”, но в реальности от этого смысла мало: при регулярном сохранении файла эти 5 копий исчерпывают себя в течении часа.

Конечно, есть и встроенные решения в современные операционные системы (та же Time Machine в OS X), но они сделаны по остаточному принципу. Кому-то везет, но лично у меня с ними больше проблем, чем радости. Поэтому я решил взять и пощупать Acronis True Image 2017. По уверениям рекламы самый-самый, сохраняет быстро, а восстанавливает еще быстрее.

Что самое важное в резервном копировании? Две вещи: скопировать нужное и дать доступ до нужного после “того случая”. Все остальное – пыль и тлен.

Ок, берем триальный Acronis True Image и ставим на ноутбук и телефон. Процесс установки ничем оригинальным не блещет (и это хорошо), поэтому описание пропускаю.

После запуска предложили выкинуть то, что в “облаках”.

ati01-01

Но почему не предложили исключить из бекапа программы? С одной стороны, будет уверенность, что после восстановления у меня будут именно те версии, с которыми я работал, а с другой – смысл мне бекапить Microsoft Office? Недочет? Недосмотр? Дизайнерский вывих?

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

ati01-02

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

ati01-03

Оставляю копироваться ноутбук и беру в руки мобильный телефон, отмечаю все галочками …

ati01-04

Засекаю, сколько будет идти полное копирование телефона и сколько есть сейчас батарейки …

ati01-05

и фиксирую окончание

ati01-06

45 минут и и 6% батарейки на Samsung Galaxy S6. Не знаю как вам, но по-моему очень хорошо.

(пропущена ночь)

Дожидаюсь, когда на веб-панели мне сообщат, что всё отлично, все забекаплено и вообще шикарно.

ati01-09

Что в следующем шаге? А в следующем шаге обычная работа и утеря чего-либо очень-очень важного для меня.

На роль важного в мобильном телефоне выступит спам от МГТС. Делаю скрин на память.

ati01-08

А на роль очень важного на десктопе выступит скриншот из игры Elite:Dangerous. Название файла space_is_beatiful.jpg и он расположен прямо в моем домашнем каталоге.

ati01-10

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

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

Делаем пользу из телевизора.

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

Но использовать их у меня не получается: смотреть нечего. То, что предлагают имеющиеся каналы совершенно не удовлетворяет мои вкусы. Телевизор стоящий в спальне гордо имеет на боку какую-то кастрированную OS и умеет ходить в интернет. Там есть всякие “амедиатеки”, “ивиру”, “нетфликсы” и прочий хлам, отличающийся от эфирных каналов лишь ценником. Смотреть там точно так же нечего.

Итак, я сформировал задачу: надо сделать так, что бы телевизор не собирал пыль. Для этого эта штука должна обзавестись следующими навыками:
– Научиться играть музыку. Я практически все делаю под музыку.
– Научиться показывать киношки именно те, которые я хочу и те, когда я хочу. Важное дополнение: некоторые киношки я смотрю на языке оригинала, а некоторые – с расположенного дома сетевого диска (просто по причине их тотального отсутствия в магазинах).
– Не трахать мозги.

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

Google Chromecast уже смотрится лучше. Тем более один из телевизоров имеет какую-то старую (ну или аналогичную) версию. Основной минус – трансляция только с телефона/компьютера. Значит, надо иметь постоянно включенным еще один компьютер или держать телефон поблизости. Нет, с компьютерами проблем нет, а вот с телефонами проблема – Chromecast никак не поддерживает Apple.

Куча hdmi-донглов проходит под первым пунктом и точно так же не вызывает энтузиазма.

В итоге остается только новый Apple TV. Старый – он как хромкаст и тоже требует внешнего устройства. Согласно рекламе и описаниям, он умеет делать все, что требуется.

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

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

Второй проблемой стали фильмы. На любой чих приставка выдавала сообщение о неустранимой ошибке и закрывала “приложеньице”. Сказать, что я был огорчен – ничего не сказать. Более того, при попытке играть кино на планшете и потом включение AirPlay приводило к 50% зависанию проигрывания. Отдельные кадры показывает, но кино играть не желает.

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

Перезагрузки и прочие шаманские танцы не помогали точно так же.

Решение оказалось сложным. Что конкретно помогло, я не знаю и знать не желаю. Я просто сбросил приставку в ноль (она при этом заново скачивает прошивку из сети), поставил язык интерфейса английский и подключил appletv по ethernet. Пароли и прочее ввел с помощью планшета (есть при установке такой выбор. я просто в первый раз пропустил)

Все проблемы сняло как рукой. Обычного интернета в 80 мегабит (пиковых,постоянно доступно там 30-40 от силы) в воскресенье вечером хватает на показ фильма в FullHD без каких-либо пауз, квадратиков и прочих аттрибутов.

Поставил VLC. Играет, все что я ему попробовал подсунуть.

Звуковые дорожки переключаются. В iTunes сразу и без проблем, VLC иногда плющит.

Музыка полностью аналогична той же самой на айфонах-айпадах. Все работает.

Задача выполнена и я провел половину воскресенья за пересмотром “звездных войн”. Качественное FullHD на большом экране очень непривычно смотреть. Внезапно обнаружилось, что я как-то уже привык к “мылу”. Как бы не повторилась история с “аудиофильством”

PS Так же внезапно обнаружилось приятное дополнение. Понажимав несколько раз кнопку menu (то есть уйдя на главный экран и попытаться уйти “выше”), можно запустить “скринсейвер”, представляющий собой HD видео разных городов с высоты.