Администрирование

Этот проект я изначально писал для себя и под свои рабочие привычки: хотелось иметь быстрый «пульт» к компьютеру/серверу из Telegram, где всё управляется кнопками, без постоянного ввода команд.

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

Репозиторий на GitHub

Последняя версия на GitHub на момент публикации: v1.1.7.

Если интересно, как всё начиналось и к чему я пришёл по ходу разработки, у меня уже выходили две статьи на Хабре:

Привет, Хабр! Меня зовут Андрей Гордиенко, я ведущий специалист поддержки облачных услуг в Selectel.

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

Продолжаем погружение в сетевые технологии: детально изучим тему распределения нагрузок. Пройдем путь от теории к практике. Начнем с простого облачного балансировщика. Затем соберем сложную гибридную схему с использованием глобального роутера, которая распределяет трафик между Москвой и Санкт-Петербургом.

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

Всем привет! Потребовалось на старом ядре linux запустить несколько docker-контейнеров, требующих getrandom и/или getentropy. В ядрах Linux старше 3.17 нет этих системных вызовов. Решение применимо не только к docker, но и к запуску программ на старых ядрах вообще.

Предположим, вам необходимо мигрировать ваш кластер k8s в другой vlan или просто сменить ip адреса. Насколько это необходимо каждый решает сам. Будем считать, что перенос нагрузки ямлами на другой кластер затруднён или у кластера специфические настройки.

В качестве начальных условий: кластер on prem с root доступом на узлы, установлен через kubeadm или kubespray, в качестве cni calico. В нашем случае под ногами ubuntu в качестве системы. Если у вас кластер установлен the hard way , то статья вам не нужна, вы сами всё умеете.

В какой-то момент своей жизни, я стал понимать, что мне все сложнее справляться с информационным давлением. О чем речь? Что за давление? Может вы заметили, что сейчас, как говорится, «из каждого утюга» льется большой поток информации, которую стало не просто фильтровать. И далее по списку: социальные сети, мессенджеры, email почта, банковские приложения, реклама, интернет журналы, телевизор, ютуб, короткие ролики (да, это стоит выделить отдельно), звонки с телефона, СМС, музыка, фильмы, подкасты, радио, куча подписок (и это отдельно).  Если вы трейдер или как то связаны с рынком, то еще и это. Может еще что упустил , но суть в общем в том, что очень много источников информации, которые требуют нашего внимания. Что же делать?

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

И эти приложения надо обновлять на протяжении всего жизненного цикла. Процесс поддержки таких приложений это часть работы с техническим долгом. По другому можно это назвать налогом на инфраструктуру. И иногда налог получается довольно большой!
Думаю все знают в какой ад может превратиться обновление приложений и их зависимостей.

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

В 2023 году к нам регулярно приходили разработчики с вопросом: «Кажется, тупит сеть. Посмотрите?» Вопросы были по делу, и каждый раз отвечать было сложно. Когда тойл от подобных обращений превысил разумные пределы, мы решили разработать SLO на летенси в Ingress. Но оказалось, что это не так уж просто.

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

Когда мы впервые увидели AI-чаты, это выглядело впечатляюще. Они писали код, помогали с документацией, объясняли архитектурные решения.

Это было хорошо. Но довольно быстро стало понятно главное:

Всем привет!

Так вышло, что в месте, где я преподаю и занимаюсь менторством стажёров, начался переход с GitHub-репозиториев на GitLab, развёрнутый на собственных серверах. Пока что перенесли не все проекты, но даже этого оказалось достаточно, чтобы у стажёров возникло немало вопросов — особенно в части настройки CI/CD-процессов.

Формально CI/CD в GitHub и GitLab решают одну и ту же задачу, но на практике подходы, терминология и детали конфигурации отличаются. Из-за этого попытки «сделать как в GitHub Actions» часто приводят к путанице и ошибкам.

У меня уже есть статья про CI/CD и workflow, но она целиком посвящена GitHub Actions. Чтобы сократить количество вопросов, разночтений и бессонных ночей у стажёров, я решил написать отдельную статью про CI/CD именно в GitLab — с учётом его особенностей и типичных подводных камней.

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

Привет, Хабр! Меня зовут Павел Князькин, я системный архитектор в Orion soft, занимаюсь развитием платформы виртуализации zVirt. Сегодня мы поговорим о миграции виртуальной инфраструктуры. 

Миграция с иностранных платформ виртуализации, таких как VMware, HyperV, XEN, а иногда даже и с других отечественных систем виртуализации становится актуальной задачей для многих организаций. Но их останавливают трудности перехода: нужно каким-то образом переместить ВМ из одной платформы виртуализации в другую.

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

Кто-то знает и пользуется, а кому-то, возможно, короткая статья освежит в памяти этот лайфхак. Я так пользуюсь постоянно.

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

Хорошо, если в поле ввода пароля есть стандартная кнопка «Отобразить пароль»，и можно посмотреть, что подставляется в поле ввода пароля:

Флешки постепенно уходят в прошлое, а облачные хранилища не всегда подходят для домашних проектов и экспериментов. Иногда хочется простого и предсказуемого способа обмена файлами — без подписок, лимитов и лишней инфраструктуры.

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

В этой статье вы найдёте пошаговый гайд по развёртыванию FTP-сервера на VPS UltraVDS под управлением Debian 12 с использованием vsftpd (Very Secure FTP Daemon).

Привет, Хабр! На связи команда Рег.облака. Для нас 2025 год стал одновременно годом разделения и большой сборки. Облако окончательно перестало быть просто еще одним сервисом в линейке крупной технологической компании и сформировалось как самостоятельная экосистема — с собственным сайтом и доменом, витриной продуктов, командой, продуктовой стратегией и набором проектов.

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

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

Привет, Хабр! На связи снова Дмитрий, инженер по инфраструктурным решениям РЕД СОФТ. В прошлой статье мы разбирали, как настроить службу каталогов РЕД АДМ в ручном режиме, а также рассматривали самые распространённые ошибки в этом процессе. А в сегодняшней статье я постараюсь дать ответ, пожалуй, на весьма сложный вопрос — как работает репликация в РЕД АДМ «под капотом».

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

Согласитесь, что встретить Новый год рядом с семьёй и друзьями - намного приятнее, чем сидеть за ноутбуком в 02:40 и с квадратными глазами разбираться, почему “что-то там легло”, а доступ к нужным секретам остался только у одного человека… который как раз в этот момент режет оливье и не слышит телефон.

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

В статье подробно разбираем, как устроен CSI (Container Storage Interface), как проходит жизненный цикл тома от PVC до удаления и что на самом деле делают sidecar-контейнеры и драйверы.

Привет Хабр! Я Дмитрий Закорючкин, в компании Avanpost я занимаюсь развитием нашей службы каталогов, Avanpost  Directory Service.

Сегодня я хотел бы поговорить о групповых политиках и их применимости в Linux-мире. Тема для меня близкая не только в связи с моей текущей деятельностью: так сложилось, что практически всю свою карьеру я так или иначе имел дело с AD DS, так что, надеюсь, рассказ предстоит интересный.

На протяжении многих лет тестовые наборы ReactOS оставались без должного внимания. Они представляли собой случайный набор:

- собственных тестов проекта;

- старых тестов Wine, которые проверялись только на Windows Server 2003 иногда — на случайных более новых версиях Windows (на усмотрение участника).

Импортированные тесты Wine были сильно модифицированы, а внесённые изменения не всегда хорошо документировались.

Я взялся навести порядок в этом хаосе.

Планировщик Linux долгое время оставался зоной, куда можно было заглянуть, но почти невозможно вмешаться без пересборки ядра. С появлением sched_ext эта граница сдвинулась: теперь логику планирования можно описывать кодом на C и загружать в ядро через eBPF. В статье разберём минимальный рабочий планировщик, посмотрим, как он взаимодействует с ядром, и обсудим, какие новые возможности это открывает для экспериментов и диагностики поведения системы под нагрузкой.