Обновить
423.36

Linux *

Пишем под *nix

Сначала показывать
Порог рейтинга

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

Речь про vi...😱 

Как выйти из vi? Никак. Это не редактор, это пожизненный контракт.

Я открыл vi один раз в 2009 году. С тех пор у меня один и тот же терминал, потому что я всё ещё пытаюсь выйти.

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


Это тот самый редактор, который в обычной жизни можно спокойно не трогать годами… А потом ты оказываешься в air-gap, где:

  • нет vscode

  • нет nano

  • нет mc

  • иногда даже less нет и кажется, что у тебя есть только vi и судьба

И вот ты открываешь конфиг… и мозг такой: эээээ мы не умеем, всё, до свидания.

Давай разберёмся, как перестать бояться vi и научиться выживать с ним спокойно.

Почему vi вызывает ступор? Потому что он не работает как обычные редакторы. Ты нажимаешь клавиши - а текст не печатается. Пытаешься выйти - не выходит. И где-то рядом уже открывается вкладка “как выйти из vi”, но интернет… в другой реальности.

Главное, что нужно понять - в vi есть несколько режимов:

  1. Normal mode - это режим команд и перемещения. Тут ты не печатаешь текст, а управляешь редактором.

  2. Insert mode - это режим, где можно реально редактировать и вводить текст.

  3. Command mode (через :) - cохранение, выход, всякие служебные команды и тд

Минимальный набор клавиш, чтобы выжить:

  • Войти в редактирование -> i, a, o

  • Вернуться обратно в команды -> Esc

  • Сохранить файл -> :w

  • Выйти -> :q

  • Сохранить и выйти -> :wq

  • Выйти без сохранения -> :q!

Полезные команды, которые реально пригодятся:

  • удалить строку -> dd

  • вставить строку ниже -> o

  • отменить действие -> u

  • повторить последнее действие -> .

  • поиск: / и дальше текст который ищем

Пример: быстро поправить конфиг и уйти живым

vi /etc/hostname

Дальше всё по шагам:

  1. нажми i и внеси правки

  2. нажми Esc

  3. введи :wq

  4. готово - конфиг сохранён, ты победил

А если ты хочешь владеть vi как ниндзя, то вот тебе Vim Cheat Sheet https://vim.rtorr.com/

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
+7
Комментарии14

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

Наверняка знакомо ощущение: смотришь логи через tail -f, делаешь какое-то действие - рестарт сервиса, деплой, правку конфига - и потом пытаешься глазами понять, где закончился старый вывод и началось новое. Спойлер: это не всегда просто.

Для таких случаев существует крошечная, но очень полезная утилита
spacer: https://github.com/samwho/spacer

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

В итоге это неожиданно удобно:

  • при отладке,

  • при сопровождении сервисов,

  • при поиске изменений в логах после конкретных действий.

Отдельный плюс - минимализм. Никаких зависимостей, ничего лишнего: скачал, поставил, используешь. Именно тот случай, когда инструмент делает ровно одну вещь - и делает её хорошо.

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
+8
Комментарии0

“Наши руки не для скуки” (с). Я давно хотел накидать скрипт для супер быстрой диагностики Linux. Конечно, это не замена полноценному мониторингу. Это  дополнительный инструмент, который вы можете использовать в своем арсенале чтобы упростить себе жизнь. Самое главное что он сэкономит кучу времени.

В отчете вы получите:

  • Системную информацию - версия ОС, ядро, архитектура, uptime, внешний IP

  • Аппаратные ресурсы - CPU, RAM, Swap, температура процессоров

  • Дисковое пространство - занятое место, inodes, SMART статус

  • Тест скорости дисков - скорость записи/чтения (100MB тест)

  • Сетевые интерфейсы - статус, ошибки, активные соединения

  • Тест сети - ping до шлюза, ya.ru и 8.8.8.8 (по 10 пакетов каждый), скорость интернета

  • Процессы - топ по CPU и памяти, zombie процессы

  • Системные логи - критические ошибки, OOM события, kernel warnings

  • Системные службы - проверка упавших служб

  • Безопасность - неудачные входы, активные SSH сессии

  • Docker - статус контейнеров и их ресурсы

Пример запуска (можно без sudo - но там не будет всех показателей):

curl -o ~/linux-diag-script.sh https://gist.githubusercontent.com/itcaat/45edeaf15f2d508bee766daa9a97400c/raw/linux-diag-script.sh
chmod +x ./linux-diag-script.sh
sudo ./linux-diag-script.sh

# Одной командой
curl https://gist.githubusercontent.com/itcaat/45edeaf15f2d508bee766daa9a97400c/raw/linux-diag-script.sh | sudo bash

Бонусом в скрипте встроена возможность получать Telegram уведомления и сам отчет при обнаружении проблем. Для этого надо создать бота и добавить в выполнение скрипта в cron.

  1. Найди [@BotFather](https://t.me/BotFather) в Telegram

  2. Отправь команду /newbot

  3. Следуй инструкциям и получи токен бота (например: 123456789:ABCdefGHIjklMNOpqrsTUVwxyz)

  4. Получи Chat ID:

        - Отправь сообщение боту

        - Откройте:  https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getUpdates

        - Найди "chat":{"id": - это твой Chat ID

Теперь можешь добавить в cron (подставь свой botToken и chatId) и будешь получать уведомление в telegram если будет обнаружена какая то проблема.

# Проверка каждые 6 часов
0 */6 * * * root TELEGRAM_BOT_TOKEN="your_token" TELEGRAM_CHAT_ID="your_chat_id" /usr/local/bin/linux-diag-script.sh >/dev/null 2>&1

Актуальная версия скрипты доступна на GitHub Gist.  Вы можете модифицировать его под свои нужды, добавлять новые проверки или как то интегрировать в runbook-и.

Пишите что еще можно добавить - я добавлю.

---

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
+1
Комментарии0

Делюсь находкой...

Если тебе надо быстро потыкать что-то из Linux / контейнеров / сетей / namespaces / cgroups, но при этом не хочется поднимать VM, ставить Docker, ковырять окружение, то iximiuz labs playgrounds - это прям топ штука.

Это набор готовых интерактивных лаб, где ты заходишь в браузере и просто:

  • запускаешь контейнеры

  • смотришь namespace’ы

  • играешься с сетью

Причём самое классное, что там не “прочитай статью”, а прям сценарий + терминал + что делать. То есть зашёл → запустил → увидел результат → понял, как оно работает.

---

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩



Теги:
+1
Комментарии1

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

Давайте я просто покажу примеры использования с кратким описанием и все сами поймете.

pdsh -  инструмент, который позволяет выполнять команды на множестве хостов параллельно.

# Проверим uptime на хостах начиная с 1 по 5, исключив 3
$ pdsh -w node[1-5] -x node3 uptime

# Перезагрузим все хосты, кроме node3 и node7
$ pdsh -w node[1-10] -x node3,node7 'sudo reboot'

Если вы достаточно организованы, чтобы вести список хостов - можно даже использовать файл с заранее определенными хостами

# File: my_hosts.txt
# node1
# node2
# db[01-05]

pdsh -w "^my_hosts.txt" 'uptime'

Вы скажете:

Так тебе же ничего не мешает использовать для этих целей Ansible! Например, так:

ansible -i 'node1,node2,node3' all -m shell -a 'uptime'

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

Когда одного pdsh мало - берите PSSH

pssh - отличная альтернатива pdsh

# Одновременное обновление пакетов на всех хостах
pssh -h production_servers.txt -l admin -t 300 "sudo apt update && sudo apt upgrade -y"

pscp - массовое копирование на сервера

# Залить скрипт мониторинга на все хосты
pscp -h all_hosts.txt monitor_script.sh /usr/local/bin/

prsync - параллельное копирование через rsync

# Обновить статические файлы только если они изменились
prsync -h cdn_nodes.txt -a "-avz" static/ /var/www/static/

pslurp - собрать файлы с серверов на локальную тачку

# Собрать логи со всех серверов в отдельные папки
pslurp -h servers.txt -l user -L ./collected_logs /var/log/app/error.log app_error.log

Эти инструменты не заменят полноценные системы управления конфигурациями вроде Ansible или chef, но для быстрых задач, срочных исправлений или массового сбора информации - они незаменимы.

---

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Теги:
+1
Комментарии0

Создание нового пользователя Linux: команды, права и базовые практики безопасности

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

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

Все детали — в базе знаний Рег.облака.

Теги:
+2
Комментарии1

Устранена проблему, из-за которой установщики Adobe Creative Cloud для Windows не могли работать в Linux через Wine из-за некоторых несовместимостей Wine с MSXML3 и MSHTML. После этого открытого фикса Adobe Photoshop 2021 и Photoshop 2025 могут быть установлены и запущены в Linux через Wine.

Теги:
+7
Комментарии1

Установка Ubuntu 24.04

Опыт обновления до Ubuntu 24.04 / установки Ubuntu 24.04 с точки зрения обычного пользователя.

На ноутбуке в течение нескольких лет была установлена Ubuntu 20.04, которая работала стабильно и надежно. В начале 2026 года было принято решение обновиться до 24.04. Казалось, это несложно: нажать кнопку обновить до 22.04 в Software Updater, затем так же обновить до 24.04, что и было сделано. ChatGPT и Deepseek предварительно были опрошены на предмет рисков при обновлениях системы. Оба заверили, что должно пройти нормально, с оговорками что есть некоторые риски и описанием их возможных причин. Стоит отметить, что оба рекомендовали рассмотреть вариант установки «чистой» Ubuntu 24.04. Был выбран вариант обновлений.

Проблем при обновлениях не возникло. Они появились позже: стали тормозить, зависать и крашиться многие приложения.

ChatGPT выдвинул ряд причин и предположений, почему так могло произойти, и в ходе диалога предлагал различные варианты решения (иногда даже просил скинуть логи и выводы некоторых команд), которые были последовательно выполнены, один за другим. Ни один из предложенных чат-ботами вариантов действий (вплоть до полного удаления snap из системы) не решил проблему.

В итоге было решено установить «чистую» Ubuntu 24.04. Был сделан бэкап, скачан образ с официального сайта и с помощью приложения Startup Disk Creator создан загрузочный диск Ubuntu 24.04 на флешке. Перезагружаем/включаем ноутбук с вставленной флешкой, периодически нажимаем F12 или другую клавишу (в зависимости от модели ноутбука) в процессе включения, выбираем пункт «Try or Install Ubuntu». Загружается система с установщиком.

И здесь возникла другая проблема: установщик Ubuntu 24.04 зависал на 3-м или 4-м шаге, после нажатия очередного "Next" (где-то на выборе локации). Было сделано несколько попыток, с подключением к Wi-Fi и без подключения к сети, ничего не помогало. Оказалось, что это известная проблема, описанная даже на сайте поддержки Lenovo. Конкретная рекомендация по решению была найдена в одном из комментарием под топиком на форуме Ubuntu: включить режим самолета на ноутбуке сразу после включения (перед запуском установщика). После этого установщик отработал без проблем.

Рекомендации для тех, кто хочет обновиться до Ubuntu 24.04: чистая установка системы – лучший вариант. Также рекомендую с осторожностью добавлять сторонние репозитории (PPA), это может нарушить зависимости в системе.

Теги:
0
Комментарии2

Представлен проект CapacityTester — утилита с графическим интерфейсом для выявления реальной ёмкости носителей информации. Решение кроссплатформенное, написано на C++ и создано с использованием фреймворка Qt.

Есть два режима работы CapacityTester:

  1. Аналогичный используемому при работе консольных утилит f3write/f3read (пакет f3 — Fight Flash Fraud), когда свободное место на носителе (с файловой системой) заполняется специально сформированными файлами. На носителях большого объёма требуется длительное время для проверки.

  2. Деструктивный режим, когда данные пишутся напрямую на носитель, и фейковая ёмкость может быть выявлена быстрее (у f3 тоже, вроде бы, есть аналогичный режим, но это не точно).

Помимо авторских сборок, у программы есть пакет в репозиториях Altlinux и PKGBUILD в AUR.

Теги:
+3
Комментарии0

Как я пошел на курсы ALT Linux и что из этого вышло.

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

Часть 1: Выбор пути. ALT против Astra и шок от цен.

Всё началось с желания проверить и структурировать знания по отечественным Linux-системам, с которыми приходится работать. Изначально смотрел в сторону Astra Linux, но глазам сразу бросилась разница в цене. ALT Linux предлагал обучение на более доступных условиях, а поскольку в работе я касаюсь обеих ОС, выбор стал очевидным. Начал изучать предложения на официальном сайте. И вот тут — первый удар. Стоимость курсов в некоторых учебных центрах заставила меня серьезно задуматься: «А нужна ли мне эта подготовка, если вроде бы и так всё знаю?» Но любопытство победило. Я решил тестировать, попробовать .

Часть 2: Организация. Поиск курсов и «неспешные» менеджеры.

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

Совет №1: настройтесь на ожидание. Ответ пришел далеко не сразу, прошло несколько дней. Видимо, такова специфика. Но как только контакт состоялся, всё пошло быстро: договор, оплата, зачисление — и вот я уже студент.

Часть 3: Учёба.

Проверенный университетский формат. Мне прислали ссылку и дату старта. Формат напомнил университет: · Лекции — в записи. Смотрел в свободное время, очень удобно. Практика — раз в неделю, онлайн с преподавателем. На ней разбирали лабораторные и отвечали на вопросы. Первая ступень — это два курса: «Альтадмин 1» и «Альтадмин 2». Каждый длится около 4 недель и включает лекции, 4 лабы и итоговый тест. Всё прозрачно и понятно. Обратная связь и преподаватель: Здесь мне повезло. Преподаватель отвечал на вопросы на учебной платформе молниеносно. Чувство юмора у него было своеобразное, но это мелочь. Главное — экспертиза и готовность помочь были на высоте.

Часть 4: Впечатления и нюансы. Кому стоит идти?

В целом курсы «зашли», и я их рекомендую, но с важными оговорками.

Плюсы:

1. Структурированный, практический материал.

2. Быстрая обратная связь.

3. Гибкий формат (запись + живая практика).

Нюансы (о которых стоит знать):

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

2. В лабах встречаются «подводные камни». Иногда в условиях всплывают неочевидные ошибки или недоговоренности. Но иногда о них предупреждают. Если у вас есть даже небольшой опыт, вы с ними справитесь. Для меня это даже стало плюсом — пришлось глубже копать.Иногда версии virtual box показывали сюрпризы,то версии дистрибутивов Linux. Воооообщем разбирался.

Часть 5: Разочарование в сертификации.

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

Итоги и выводы

1. Качество обучения — на хорошем уровне. Если нужны структура и практика, курсы отличные.

2. Целевая аудитория — не абсолютные новички, а те, кто хочет систематизировать опыт и разобрать задачи с экспертом.

3. Главный минус — невозможность для физлица получить полноценный вендорный сертификат после обучения. Уточняйте этот момент ДО оплаты курсов. Мой опыт получился познавательным, но с послевкусием. Надеюсь, мой рассказ поможет вам сделать выбор.

Теги:
+5
Комментарии8

Слышу уже от второго человека, что язык Rust не дает нормально работать с указателями в связанных списках, деревьях и графах (в моей вселенной ЯП без этого - это как свадьба без невесты). Взял ChatGPT, задал промпт: "write a code to insert a node into a doubly linked list in rust". Оно сгенерило нечто с кучей дополнительных слов, которых не было ни в Си, ни в Паскале 40 лет назад: borrow, as_ref, and_then, upgrade, map, downgrade, Some, clone, borrow_mut. Это все реально нужно или они там совсем озверели?

Теги:
Всего голосов 18: ↑13 и ↓5+11
Комментарии59

Философия IT-собеседований: взгляд разработчика и DevOps-инженера

Привет, Хабр! Мой пост носит дискуссионный характер. В веб-разработке, администрировании и DevOps я уже 17 лет. Долгое время работал «на себя», оказывая помощь клиентам, с которыми выстроены надёжные взаимоотношения, но текущие реалии рынка подтолкнули к поиску работы по ТК, об этом я и хочу поговорить.

Обо мне: 40 лет, из которых 17 лет в коммерческой разработке. Прошел долгий путь как в fullstack-разработке (web), так и в создании embedded-решений (каршеринг), администрировании и DevOps.

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

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

  1. Диалог на равных.
    Мое лучшее интервью: техлид не мучил теорией, а предложил обсудить реальную дилемму, которую он решает в данный момент (внедрение NoSQL-хранилища ради одного специфичного сервиса, т.е. доп. точка отказа vs производительность). Без таймера и стресса мы искали решение. Итог — оффер и годы отличной работы.

  2. Проверка логики, а не памяти.
    Люблю кейсы в духе: «Вот дано А, почему происходит Б?». Из банального: может ли Вася из другого города достучаться до вашего локального IP? Это показывает понимание базы лучше любого теста.

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

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

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

  2. Вакансии-обманки.
    Зачем заманивать стеком DevOps (Linux, Nginx, Ansible, Terraform, Puppet, Docker, Kubernetes, MySQL, PostgreSQL, Elasticsearch, Logstash, Kibana, Zabbix), если по факту сообщаете, что ничего этого не будет, а ищите классического сисадмина 9-18? — Давайте адкеватный запрос, а не тратьте время.

  3. Терминологическая каша. Сложно отвечать экспертно, когда интервьюер путает CI и OCI или Redis и Rabbit. Если нет погружения в контекст, конструктивного диалога не выйдет. Готовиться к собеседованию должен не только соискатель, но и тот, кто нанимает.

  4. Отсутствие пунктуальности.
    Для меня было шоком, что фаундер может просто не явиться на собседование, или рекретер забывает о диалоге и назначенной встрече. У вас там всё нормально?) Хотя рекрутер мало чем отличается от агента недвижимости, но фаундер забывающий про собеседование для меня персонаж странный.

  5. Узкая специализация.
    Раньше, как мне кажется, ценилась универсальность, способность разработчика понимать инфраструктуру, а инженера/админа — код. Сегодня индустрия уходит в жесткую сегментацию, видимо, для более точного просчёта рисков. А я считаю, что именно универсальность — это страховка проекта от того, что решение будет принято в вакууме одного стека, без учета общей картины.

Теги:
Всего голосов 6: ↑6 и ↓0+7
Комментарии2

Еще один вариант маршрутизации трафика через два сетевых интерфейса на основе списка доменных имен.

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

Краткое содержание: ставим локальный dns resolver с плагином на python, который, при разрешении имени в адрес, устанавливает маршрут через альтернативный интерфейс, если адрес соответствует регулярному выражению. Для использования решения требуется умение сконфигурировать и запустить сервис в вашем любимом дистрибутиве/сервис-менеджере, готового пакета для установки нет.

При написании кода использовалась статья Составляем DNS-запрос вручную, огромное спасибо автору и переводчику.

Для реализации идеи нужен ДНС сервер, который позволяет достаточно просто писать плагины/хуки. Первым попавшимся на глаза был PowerDNS Recursor, который позволяет писать плагины на lua. И первая реализация была для него. Но lua это больше про компактность, чем про удобство, например, поддержку регулярных выражений можно так назвать только из вежливости. Тем не менее, всё работало как предполагалось, и достаточно надежно, пока не был найден Unbound DNS который позволяет писать плагины на python, и, в итоге, был написан аналог на питоне, который и предлагаю вашему вниманию.

Все файлы доступны на github. Файлов всего 5 и все достаточно короткие.

Файл reroute.conf: пример файла конфигурации ДНС сервера. 192.168.0.1 и 172.16.17.1 — это адреса маршрутизаторов для первого и второго интерфейсов, соответственно. /etc/unbound/reroute.py — собственно плагин выполняющий основную работу. Из существенных моментов: chroot необходимо отключить, чтобы могли нормально работать скрипты на python и сервис должен работать от root чтобы добавлять маршруты.

Файл reroute.py — плагин, который выполняет необходимые дествия, reroute_conf.py — файл конфигурации для плагина, можно записать оба параметра прямо в плагин и обойтись без него. Вся работа выполняется в функции do_reroute, весь остальной код взят, практически без изменений, из документации unbound dns.

Файл rrdomains.txt — список регулярных выражений в формате python regex, при совпадении с которыми для всех ip-адресов разрешаемого доменного имени выполняется установка альтернативного маршрута.

Файл bashrc содержит определение функции reroute. Если во время работы наткнулись на сайт, для которого необходима маршрутизация через второй интерфейс, можно воспользоваться быстрым перенаправлением с помощью команды reroute в терминале. Или добавить доменное имя или регулярное выражение для него в rrdomains.txt и перезапустить dns сервер.

На этом всё, успешного маршрутизирования!

Теги:
Всего голосов 1: ↑1 и ↓0+2
Комментарии0

Ближайшие события

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

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии4

@Regnar, навеяло статьёй

Свалился на меня «последний из 32-битных могикан», но машинка прямо финал возможностей архитектуры — насколько я понял, видит спокойно 8 гигов рамы (PAE во все поля?), слотов не пожалели, в общем, в такое чудо бы камень хотя бы на 2 ядра, но, увы…

Я его практически не смотрел ещё и ХЗ когда посмотрю (вроде не совсем мёртвая), но превентивно задам вопрос. Допустим, поставил я туда 32-битный BunsenLabs. Допустим, я хочу запустить какое-нибудь 64-битное приложение, которое в 32 битах давно уже не обновляется. Допустим, мне пофиг, что там в плане скорости (очень важное допущение, потому что оно как бы понятно, что там будет).

Насколько это реально — настроить для него резервативию… презервацию… короче, специально обученный загон с софтовой эмуляцией 64 бит? Существуют ли решения? Чтобы их установить и отконфигурировать, обязательно пройти все круги ада, как в той статье?

Практического смысла это по понятной причине не несёт — просто пятничное.

Теги:
Всего голосов 2: ↑0 и ↓2-2
Комментарии0

Почему я снова вернулся на Debian после Ubuntu 24.04 и Fedora 42

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

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

Я решил обновиться с Ubuntu 22.04 до 24.04 - казалось бы, логичный шаг: свежий LTS, новые пакеты, улучшения в GNOME. Но спустя пару недель я понял, что дистрибутив нужно менять. Расскажу, почему.

Медленная работа с большим количеством файлов

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

Если регулярно работаешь с проектами, папками картинок или архивами — это превращается в настоящий тормоз.

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

Fedora: понравилась, но не подошла под задачи

Первым я решил попробовать Fedora 42.
Впечатления были отличные:

  • система работает быстро,

  • GNOME выглядит аккуратнее без патчей Canonical,

  • Wayland ощущается максимально плавным,

  • окружение ощущается «современным из коробки».

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

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

В итоге я пытался найти нужные программы, но либо я их не там искал, либо их не было, либо которые я нашел не заработали.

Почему я выбрал Debian 13

В этом году как раз вышел Debian 13 с GNOME 48, я решил попробовать его.

И для себя получил:

  • стабильность, к которой привык,

  • современный GNOME без патчей,

  • огромный набор пакетов в репозиториях,

  • отсутствие лишних предустановленных компонентов,

  • а главное — всё, что мне нужно, установилось без танцев.

В итоге Debian остаётся для меня тем самым балансом:

Итог

Ubuntu 24.04 — неплохой релиз, но сейчас он не подходит под мои задачи.

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

Так я и остановился на Debian 13 с GNOME 48 — и пока это лучший вариант для моего сценария.

А прочитать статью про мой ноутбук, который я приобрел для Линукс за 25000 рублей, вы можете по ссылке:

https://kodprog.ru/noutbuk-dlya-linuks-za-25000

Теги:
Всего голосов 4: ↑4 и ↓0+5
Комментарии10

Почему мне не понравился Arch Linux

Однажды я решил попробовать Arch Linux — в качестве эксперимента, чтобы понять, подходит ли он мне как основная система. Спойлер: нет. Хотя я понимаю, почему Arch нравится многим, лично мне он не зашёл. Расскажу коротко — без холивара, просто субъективный опыт.

1. Слишком много ручной настройки

Да, это философия Arch — «собери систему под себя».
Но когда даже базовые вещи требуют:

  • поиска пакета вручную,

  • чтения вики,

  • настройки конфигов,

в какой-то момент это начинает отвлекать от работы.

Мне хотелось просто пользоваться системой, а не постоянно её собирать.

2. Установка превращается в квест

Я понимаю, что сейчас есть Archinstall, но это всё равно:

  • больше шагов,

  • больше точек, где можно ошибиться,

  • больше нюансов, которые надо держать в голове.

Для сравнения: Ubuntu/Debian/Fedora ставятся буквально за 10–15 минут без сюрпризов.
Arch — это отдельный процесс, который каждый раз занимает время, силы и концентрацию.

3. Постоянные обновления и риск поломок

Rolling release — это круто, но это также:

  • риск, что обновление завтра что-то сломает,

  • необходимость держать в голове зависимости,

  • желание обновляться реже, но при этом понимание, что массово обновлять ещё опаснее.

Мне нужен более предсказуемый рабочий инструмент, а не адреналиновый аттракцион.

4. Много времени уходит на поиск информации

Arch Wiki — одна из лучших в мире, но:

  • почти каждое действие требует чтения документации,

  • часто нужно искать решения на форумах,

  • иногда конфликты пакетов решаются вручную.

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

5. Минимализм оказался минусом

Arch устанавливается «голым».
Ты ставишь:

  • окружение,

  • драйверы,

  • кодеки,

  • шрифты,

  • инструменты,

  • конфигурируешь систему практически с нуля.

Кому-то это даёт свободу.
Мне — лишние часы, которые можно было потратить на реальную работу.

Итог

Я понимаю, за что любят Arch — скорость, свежие пакеты, гибкость. Но для моего сценария использования он требует слишком много времени и внимания. В итоге я вернулся к Debian/Ubuntu: они просто работают, а я могу заниматься задачами, а не конфигами.

Теги:
Всего голосов 4: ↑3 и ↓1+2
Комментарии21

Привет, Хабр! Наступила очередная пятница, поэтому я несу полезные материалы на выходные для тех, кто хочет получше освоить Ubuntu. Информация по ссылкам довольно базовая, для начинающих. Все бесплатно, без регистрации и смс. Поехали!

Теги:
Всего голосов 2: ↑2 и ↓0+3
Комментарии0

Привет, Хабр! Новая пятница — новые знания для начинающий специалистов! Сегодня у нас небольшая подборка инструкций по работе с командами в Linux. Пригодится будущим и начинающим системным администраторам. Как всегда, все материалы доступны бесплатно и без регистрации. Поехали!

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

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Юрьев день для ИТ-бюджета: скидка 40% на ОС «МСВСфера», «Инферит ИТМен» и FinOps-платформу «Клаудмастер»

«Инферит» дарит ИТ-сообществу настоящий «Юрьев день» — ограниченную по времени акцию со скидкой 40% на ключевые продукты своего программного портфеля. С 26 ноября по 30 декабря 2025 года новые клиенты могут не только приобрести лицензии со значительной выгодой, но и зафиксировать цену на них.

В акции участвуют следующие направления «Инферит»:

ОС «МСВСфера»: Российская операционная система на основе RHEL для серверов и рабочих мест. Включена в реестр ПО, имеет сертификат ФСТЭК России и подходит для госсектора и бизнеса.

«Инферит ИТМен»: Система инвентаризации и контроля ИТ-инфраструктуры. Автоматизирует учет оборудования и ПО, помогает контролировать лицензионную чистоту.

«Клаудмастер»: FinOps-платформа для управления и оптимизации облачных расходов. Доступна в формате SaaS и On-premise.

Как принять участие?

Чтобы получить скидку и зафиксировать цену, необходимо до 30 декабря 2025 года оставить заявку на сайтах продуктов:

ОС «МСВСфера»

«Инферит ИТМен»

«Клаудмастер»

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

Теги:
Всего голосов 9: ↑8 и ↓1+7
Комментарии1
1
23 ...