Helcode | Хелкод | Скрипты и автоматизация

! Запускаю сайт. Не буду красиво рассказывать "вот мы шли долгим путём" - расскажу как есть. Последний месяц - завал. В мой филиал к двум компаниям, которые я полностью админю, добавляются ещё две. Параллельно - основная работа, серверы, инциденты, куча открытых задач. Последние 3-4 недели времени вообще почти нет, Вы и сами заметили - постов стало сильно меньше. Постараюсь исправляться. При этом сайт почти готов. Работает, уже в поисковиках. Но анонса не было. Почему? Причина - уведомление в РКН. По закону о персональных данных, если сайт обрабатывает данные пользователей, нужно подавать уведомление...

Не для взлома, не для изоляции продакшена, а для быстрой проверки "а что будет, если запустить этот скрипт в чистой среде". Зачем: - Протестировать скрипт в чистой Ubuntu, не ломая рабочую систему - Проверить, как конфиг ведёт себя в окружении другого сервера - Поиграться с пакетами без последствий - Восстановить систему, когда загрузка не работает (классический sceanario) Создать минимальный chroot за минуту: mkdir -p /tmp/test sudo debootstrap --variant=minbase jammy /tmp/test http://archive.ubuntu.com/ubuntu Зайти внутрь: sudo chroot /tmp/test /bin/bash Вы внутри чистой Ubuntu. Можно ставить пакеты, ломать конфиги, тестировать скрипты...

Была у меня ситуация: сижу, правлю конфиг на удалённом сервере через SSH, связь дёрнулась, терминал закрылся. Полчаса работы в vim пропали вместе с несохранённым буфером, а задача была в самом разгаре. Знакомо? У меня tmux в базе ровно из-за таких моментов - и обрыв связи перестал быть катастрофой. Что это tmux - терминальный мультиплексор. Он создаёт сессию, которая живёт независимо от вашего SSH-подключения. Отвалился - переподключился - и всё на месте: те же окна, те же запущенные процессы. Для серверов, где сессия может висеть днями, это база. Запустить сессию и отцепиться tmux new -s work...

Была у меня ситуация: обновил ядро на сервере, через десять минут нужно было перезапустить службу, а времени на ожидание не было. Писать юнит-файл ради одного запуска - перебор. Править crontab, чтобы потом мучительно вспоминать, что строку надо убрать, - тоже сомнительное удовольствие. А at стоит не везде и требует отдельного демона. В общем, я сам себе создал проблемы. Но зато после этого открыл для себя systemd-run, и теперь подобные задачи решаются одной командой. Что это systemd-run запускает команду во временном юните systemd. Без написания юнит-файлов, без правки конфигов и без записей в crontab...