Серверное администрирование *

Плохо настроенные доступы к инфраструктуре могут стать причиной необратимых инцидентов: были случаи, когда буквально несколько обнаруженных сканером устройств BMC позволили скомпрометировать целое облако с 25 тыс. хостов.

Меня зовут Павел Пушкарёв, я разработчик сервиса по аренде выделенных серверов Yandex BareMetal. Мы с коллегами из Yandex Infrastructure создавали его для пользователей Yandex Cloud, опираясь на накопленный в Яндексе опыт работы с железом, и максимально переиспользовали лучшие практики. 

В 2025 году в Вирджинии несколько дата-центров разом отвалились от сети — и 1,5 ГВт исчезли за секунды. Оператор чудом избежал каскадной аварии. Проблема ЦОД для энергосети оказалась не в том, сколько они потребляют, а в том, как: рывками, синхронно и в пределах миллисекунд. Разбираемся, почему ИИ-нагрузка ломает привычную логику планирования сетей.

Доброго времени суток, Хабр! Я ИБтивист Александр, скоро как 10 лет профессионально увлекаюсь информационной безопасностью и применяю свои исследования на практике. Эта статья будет полезна ИТ‑ и ИБ‑специалистам, которые интересуются аспектами логирования (аудита) и мониторинга безопасности в операционных системах семейства Linux. Рассмотрим и сравним классический подход к логированию auditd с осовремененными решениями на базе eBPF — tetragon, kunai, falco и Sysmon for Linux.

Мы разобрались, какие типы вычислений реально важны для LLM, почему мой вычислительный кластер на CMP90HX работал хуже чем ожидалось — узнали что вычислительная мощность искусственно ограничена именно на них, и как работает китайская модификация, снимающая это ограничение. Затем проверили всё на практике и получили реальные цифры прироста.

Self-hosted Sentry — это 65 контейнеров, 16-32 ГБ RAM и выделенный инженер на поддержку. Всё ради того, чтобы ловить стектрейсы. Разбираемся, почему индустрия приняла это как норму, сравниваем альтернативы (GlitchTip, BugSink, Hawk) и знакомимся с Metric — Sentry-совместимым мониторингом на, которому хватает 1 ГБ RAM и двух контейнеров. Миграция — смена одной строки DSN.

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

Файл /dev/null есть в каждой Linux-системе. Он весит ноль байт, но именно туда ежедневно сливаются терабайты ненужного вывода, а если его удалить, то вовсе падут cron, ssh и половина ваших bash-скриптов. Под катом расскажу, откуда взялась эта «чёрная дыра», почему это не обычный файл, а псевдоустройство, и что на нём завязано. 

Ставить WordPress руками — занятие на полтора часа: веб‑сервер, PHP с десятком расширений, база данных, конфиг Nginx, права на файлы, лимиты загрузки, сертификат. Я устал повторять этот ритуал и собрал скрипт, который делает всё сам и спрашивает только то, что действительно зависит от меня.

Итог, к которому мы придём: работающий сайт с настроенной админкой, ЧПУ‑ссылками, русской локализацией, при желании — с сертификатом Let’s Encrypt, phpMyAdmin и защитой от подбора паролей. Все доступы будут лежать в одном файле на сервере.

Каждый, кто работает в терминале, держит открытыми сразу несколько вкладок: в первой смотрит логи, во второй следит за списком запущенных процессов через htop, в третьей работает с Git, в четвертой запускает миграции базы данных. При переключении между вкладками легко запутаться, закрыть нужную, а при обрыве связи — потерять запущенные процессы и сессии. 

Привет! Я Саломея, продуктовый технический писатель в Selectel. В этой статье поделюсь своим опытом, как с помощью tmux упорядочить этот хаос и сделать работу удобнее. Разделим окно терминала на панели, запустим сессию, которая не прервется при закрытии окна, автоматизируем настройку рабочего пространства. Посмотрим, как выполнять команду сразу на нескольких серверах.

Всем привет, в этой статье я описал свой взгляд на инфраструктуру, которая помогает:

- доставлять запросы до бекенда и фронтенда при переходе по купленному домену;

- ковыряться на сервере через терминал;

- входить в контейнер через множество действий;

- отлаживать через терминал;

- заново изучать, как сделать мониторинг Docker-приложений;

- брать уже готовые решения, а не писать велосипеды

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

Разбираем сетевые драйверы Docker — bridge, host, overlay, macvlan, ipvlan — DNS, порты и плагины: от основ до продвинутых сценариев.

Есть довольно простой вопрос, который стоит задать ИТ-архитектору: «Что произойдёт, если сервер, на котором расположена служба каталогов, решит прилечь?». Если ответ начинается со слов «ну, вообще-то у нас есть бэкап», это не совсем отказоустойчивая архитектура.

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

Поэтому в новой версии MULTIDIRECTORY мы развиваем архитектуру службы каталогов в сторону мультиконтроллерной установки: несколько контроллеров домена, локальные (автономные) копии данных, репликация файлов и балансировка запросов.

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

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

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

В прошлой статье мы рассказали, почему решили съехать с корпоративной почты Mail.Ru на свою инфраструктуру. Тогда мы обошлись без деталей — а зря, судя по комментариям. В этот раз разбираем всё по шагам: как разворачивали MailCow и какие нюансы есть.

Эта статья — техническое продолжение. Без макроэкономики, только руки, консоль и шишки.

P.S. в прошлой статье сообщество решило, что у нас работает школьник и все это настраивает, поэтому статья как раз написана с помощью этого школьного товарища. Не судите строго, все таки мы еще в школу ходим :)

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

Привет, Хабр! В работе почти каждого, кто плотно сидит в Linux, есть один недостаток: одни и те же команды забываются с завидной регулярностью. Я, например, иногда по десять раз лезу в историю, чтобы уточнить - «так как в rsync директорию исключить, но структуру оставить?»

Можно, конечно, вести свои заметки. Можно - дрессировать Ctrl+R. А можно установить небольшую утилиту, которая будет жить в трее и выдавать нужную подсказку за полсекунды. Именно о такой утилите сегодня и расскажу - DevToolbox Cheats.

Любые серьёзные изменения инфраструктуры начинаются с одного вопроса: что именно у нас есть сейчас?

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

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

Документация существует, но её актуальность вызывает вопросы. В одном документе устройство называется одним образом, в другом — другим, а на самой стойке используется третье обозначение. В таблице порт отмечен как свободный, хотя в него включён рабочий линк. На схеме uplink уходит в один коммутатор, а LLDP показывает другой. Какие-то подключения давно не используются, но продолжают числиться в документации. Какие-то, наоборот, работают много месяцев и нигде не описаны.

Всё началось с обычного письма от хостинга: VPS слишком долго держит CPU выше 70%. Я открыл Gitea посмотреть, что происходит, а там уже был чужой репозиторий.

По логам восстановил атаку почти по секундам: регистрация, repository, diffpatch, Git hook, RCE. От первого запроса до proof прошло около 11 секунд.

А дальше обнаружился loader крипто-майнера. Покажу, как это произошло и что пришлось переделать на сервере.

Мониторинг шлёт тревогу, пользователи пишут, что «всё лежит», но SSH пускает на сервер. Значит, машина включена и 22-й порт доступен. О домене, портах 80 и 443, TLS, веб-сервере и приложении это пока ничего не говорит… Кажется, что нужно просто перезапустить nginx, но перезапуск стирает часть следов и может превратить частичную аварию в полную беду. Под катом расскажу, как пройти путь запроса сверху вниз и найти место, где он остановился.