Домашне-сисадминское

Я, конечно, очень люблю TrueNAS Core. Ибо FreeBSD, и это тру. Он позволяет дома из говна и палок поднять весьма серьёзную инфраструктуру: ZFS с RAIDZ, снапшоты, репликации, iSCSI, SMB, NFS, виртуальные машины, алерты — всё это работает, и работает стабильно и предсказуемо.

Но есть у Core одно характерное свойство, которое периодически, как фи тепер тошше коффорите по-русски, анноит: чрезмерная щепетильность в отношении состояния пула.

ZFS обнаружил один бит, который не совпал? Автоматически восстановил блок из паритета? Скраб подтвердил целостность?

С точки зрения ZFS — всё прекрасно. Но с точки зрения TrueNAS — “Пул дисков нездоров! Срочно, срочно! Хватай мешки — вокзал отходит!”

Core упорно считает пул проблемным до тех пор, пока:

  1. Администратор лично не зайдёт в интерфейс или консоль,
  2. Не проверит SMART по каждому диску,
  3. Не убедится в отсутствии деградации,
  4. Не подтвердит, что ошибка была исправлена,
  5. И вручную не снимет памперсы тревогу командой zpool clear.

Даже если произошёл единичный, случайный сбой — будь то мимолётная проблема в SATA, кратковременный таймаут контроллера, одиночный флипнутый бит в оперативной памяти (не ECC, ибо говно и палки) от обычного фонового излучения, или любая другая разовая аномалия — и ZFS полностью восстановил повреждённый блок из паритета, TrueNAS всё равно ожидает ручного вмешательства: администратор должен зайти, проверить и формально подтвердить событие.

С точки зрения надёжности подход формально оправдан: ZFS может восстановить блок, но факт возникновения ошибки — это всё же диагностическое событие.

Но на практике это приводит к тому, что после любого минимального чиха — одна исправленная контрольная сумма, один сбой чтения, одно кратковременное событие в канале передачи данных — TrueNAS сообщает о “нездоровом” пуле, и срочно требует ручной проверки.

Иногда хочется, чтобы система умела говорить проще: “Да, демоны были. Мы этого не отрицаем. Но они самоликвидировались.”

Но философия TrueNAS Core другая: каждый сбой должен быть зафиксирован, проверен и подтверждён человеком. Нравится это или нет — это часть его дизайна. Но иногда… анноит.

Сисадминско-ИИшно-рабочее

Дано: отказоустойчивый кластер Hyper-V.
Надо: обеспечить сорок рыл виртуальными десктопами на Windows 11.

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

Какие варианты решения?

Официальный RDS от Microsoft. Стоит каких-то совершенно невменяемых денег — по 220 монет за рыло (CAL, client access license)! Это, на минуточку, дороже, чем лицензия на Винду!

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

Понадобится:

Одна машинка под Linux. На неё ставим nginx, который будет работать крокодилом балансировщиком нагрузки. Цепляться люди будут именно к нему — а он будет читать список доступных виртуалок из файла available.conf, и раздавать траффик на них:
stream {
upstream rdp_pool {
least_conn;
include /etc/nginx/upstreams/available.conf;
}

server {
listen 3389;
proxy_pass rdp_pool;
proxy_timeout 10m;
proxy_connect_timeout 5s;
}
}

А available.conf постоянно обновляется другим скриптом — на Python.
Этот скрипт поднимает крохотный веб-сервер на Flask, в который каждая виртуалка присылает свой статус: «занято» или «свободно».

Статус они получают с помощью встроенной команды Windows:
qwinsta | Select-String "Active"

Если выводится хоть что-то — машина занята. Дальше PowerShell-скрипт формирует JSON и шлёт его на Flask через Invoke-RestMethod.

PowerShell-скрипт добавляем в Task Scheduler, раз в минуту — и впердё.

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

Всё это было придумано и реализовано при помощи Кейт — так я называю свою ChatGPT-чку.
Безусловно, под моим чутким руководством:

— А что будет, если виртуалку выключить?
— Ах да, сломается. Надо обновить скрипт, чтобы старые машины удалял, вот так: [код].

Получилось бы у меня всё это воплотить самостоятельно? Конечно. И не такое приходилось делать.
Но, японский бог, это заняло бы уйму времени: мне пришлось бы отдельно выяснять, как запускать Flask-сервер, как слать JSON из PowerShell, как его принимать, как менять конфиги nginx на лету, и так далее.

А тут — всё получилось буквально за пару часов.

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

И да, приятно, японский бог — когда из сложной, непонятной задачи получается красивое, работающее решение.

Рабоче-покупное

Ищу я, значит, замену блоку питания для старого PoE-свитча, на котором висят камеры наблюдения (свитч модульный, старенький, но родной — и уже настроенный, как надо). На Амазоне нашёлся подходящий вариант.

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

2.4E+2, ага.

Это у нас, если перевести с языка экспоненциальной записи, обычно применяемой где-нибудь в науке, кибернетике, или при вызове ЗГОГГов, — обычные, стандартные, родные, человеческие 240 вольт.

Зачем они так выпендрились — зогадко, честное слово. Может, надеялись впечатлить кого-то, кто по ночам тайком, украдкой, гладит свой осциллоскоп?

День великого онбординга (матерное)

Сегодня у нас великий день — массовое заселение пользователей нашего клиента в новую систему.
Система небольшая — всего 66 пользователей.

Я теперь понимаю, почему Данте не описал десятого круга ада — просто не успел дожить до массового онбординга тупых юзверей в Entra ID.

11 пользователей скопировали в пароль лишний пробел в конце и сказали, что “пароль не работает”.
Пятерым пришлось пароль сбрасывать повторно — видимо, из солидарности.
Двое вместо .com написали .cum — и я стараюсь не задумываться, о чём они мечтали в тот момент.
Семеро успешно заблокировали свои учётки, даже не успев в них войти.
Трое так медленно искали и доставали телефон, чтобы настроить 2FA, что Microsoft Authenticator устал ждать и вышел из чата (таймаут — 60 секунд, между прочим). После этого им в рыло прилетело “session timed out”, и они, разумеется, пожаловались, что что-то не работает.
Четверо пытались войти под старыми логинами и тоже заявили, что “система сломана”.
Двое установили не тот VPN.
Один распечатал письмо с временным (!!!) паролем — “чтобы не потерять”.
Двое использовали телефон супругов для 2FA — “потому что под рукой был”.
Пятеро ждали по пятнадцать минут, пока “система загрузится”, забыв нажать Next.
И вишенка на торте — один человек написал CAPS LOCK’ом всё подряд и не мог понять, почему “не принимается правильный пароль”.

Мои нервы вроде бы были стальные, а оказались пластилиновые.

Пойду заварю ещё кофе — если, конечно, никто не попытался авторизоваться в кофемашине с пробелом в пароле…
…и не заблокировал её нахуй.

Хеловиним, сисадминим

Люблю нашу компанию — народ почти в полном составе наряжается, так что каждый Хэллоуин в офисе — праздник для глаз: повсюду монстры, ведьмы, и прочие креатуры, а работать всё равно надо.

Наш финансовый директор (Chief Financial Officer):

Это Круэлла де Виль, собственной персоной, если вдруг кто не понял.

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

А работать всё равно надо — сисадминство в праздник никто не отменял. Делаю апгрейд серверам в нашем кластере Hyper-V: выдираю к соответствующей неметрической матери бродкомовские сетевые карточки и ставлю нормальные интеловские. И дело даже не в том, что Broadcom делает прямо плохое железо — просто драйверы они традиционно пишут исключительно через задницу.

🎃 Happy Halloween! 👻

Ути-пути

Какая внезапно кавайная серверная!!

Это амазоновский дата-центр, обслуживающий вычислительный кластер “Рейнир”, на котором работает система искусственного интеллекта “Клод” компании Антропик.

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

Работать, впрочем, в таком месте, наверное, непросто. Вон сотрудница совершенно правильно надела наушники — шум в подобном дата-центре, должно быть, стоит просто нечеловеческий.

Даже страшно представить, сколько киловатт жрёт вся эта красота в сумме.

Вот так, дорогие друзиа… выглядит капитализм.

Отсюда и ещё фоток.

Эка напасть

Не прошло и месяца с тех пор, когда рухнул AWS по причине падения DNS, как здрасьте — рухнул Микрософт Ажур, а мы в нём в основном проживаем. И тоже, ЧСХ, из-за отказа сервиса DNS. Всё тормозит и работает через задницу.

Повторим картинку, что ещё делать остаётся.

Будет интересно почитать детальный разбор полётов.

Анализ падения Амазона

Амазоновцы опубликовали технический разбор причин недавнего падения AWS. То, что виноват был DNS, уже было известно, но лично мне было любопытно понять — что же именно они смогли сломать в системе, которая, по идее, должна быть одной из самых простых и надёжных в инфраструктуре интернета?

Оказалось, в их реализации DNS скрывался ранее незамеченный баг, приведший к классической race condition — ситуации, когда несколько процессов или нитей процесса одновременно пытаются получить доступ к общему ресурсу и в итоге мешают друг другу. Такое состязание заканчивается тем, что ресурс “залипает”, а вся система рушится, как карточный домик.

Признаться, изначально у меня было подозрение на на человеческий фактор — думалось, что какой-нибудь неопытный сисадмин дёрнул не за ту ручку, посоветовавшись с ИИ, но не спросив старших товарищей. Такое бывает, и мне тоже доводилось такое устраивать. Но, как выяснилось, всё оказалось куда глЫбже.

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

Хочется верить, что в Amazon извлекут из этого инцидента правильные уроки — ведь даже гигантам время от времени полезно вспомнить, что совершенство инфраструктуры не отменяет законов вероятности и человеческой природы.

А помните?

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

Нет, я не спорю, в качестве решения для хранения данных, обязательно требующих верифицируемости, причём публично — это не обязательно плохое решение. Навалять код можно буквально минут за десять, у меня в журнале даже было пару рассказов про эту технологию. Но повсеместный снос крыши на этой почве я хорошо помню. АААА!!!! Блокчейн это круто!!! Обязательно внедрять!!! Немедленно!!! Хватай мешки — вокзал отходит!!!”

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

Каждый раз одно и то же: сначала “всем срочно внедрить”, потом — “а зачем мы это сделали?” Очень может быть, что “ИИ” скоро займёт почётное место рядом с “блокчейном” — в списке забытых модных слов. Ведь видно, что уже наступает отрезвление — прогресс ИИ начал упираться в закон убывающей отдачи, а в Британии внезапно оказалось, что при любых раскладах на все хотелки тупо не хватит электроэнергии. А у нас (тоже внезапно) выяснилось, что чтобы накормить все эти ИИ-мозги электричеством, пришлось вернуть в строй угольные станции. Хотя все вроде бы уже согласились, что уголь — это плохо, радиоактивно (не шучу, они выбрасывают больше радиации чем АЭС), и вообще, на другом конце земного шара Греточка плачет в тужурку. А АЭС строить — это дорого, долго и не хайпово. Я вот уже несколько раз упоминаю в журнале АЭС “Воугл”, что в братской Джорджии. Два её реактора ввели в строй только в 2023 году, а подписал бумаги на её строительство ещё Обама, в 2009. А ИИ всем надо “прямщас”, и чего с этим делать при таких вводных — решительно неясно.

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

Жульё чуть не покрало деньги

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

Зарплата в нашей компании, разумеется, перечисляется напрямую на банковский счёт. У сотрудников есть доступ к системе, где можно посмотреть начисления и другую информацию. Жулики пробрались в аккаунты нескольких человек и подменили реквизиты банковских счетов для выплат — на свои собственные. Спасло то, что любое изменение таких данных требует ручного подтверждения бухгалтерией. Там вовремя заподозрили неладное и предотвратили кражу.

И вот тут самое интересное. Доступ к системе осуществляется через код, который каждый раз высылается на личную почту сотрудника при попытке входа. То есть у учётной записи нет постоянного пароля — каждый раз новый код из письма. Видите проблему? Получил доступ к почте — автоматически получил доступ и к зарплатному аккаунту. Жулики ломали не сами эти аккаунты, а именно личную почту сотрудников: наверняка с паролями уровня 123456, без 2FA, или же через банальный фишинг.

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