Авторская информация о системном администрировании.
# ./apt-offline set --update apt-offline.sig
Тут же в директории будет создан файл apt-offline.sig. Теперь можно всю папку с apt-offline и этим файлом перенести на сервер с интернетом и там запустить:
# ./apt-offline get --bundle bundle.zip apt-offline.sig
Информация с содержимым репозиториев будет сохранена в файл bundle.zip. Возвращаемся на сервер без инета и там запускаем обновление реп:
# ./apt-offline install bundle.zip
Теперь обновим все пакеты целевого сервера:
# ./apt-offline set --update --upgrade apt-offline.sig
Идём на компьютер с интернетом и там качаем пакеты:
# ./apt-offline get --bundle bundle.zip apt-offline.sig
Будут скачаны все обновления пакетов и зависимости. Опять берём всю директорию и копируем на сервер без инета. Там запускаем:
# ./apt-offline install bundle.zip
# apt upgrade
Для установки только одного пакета делаем следующее:
# ./apt-offline set --install-packages PACKAGENAME --update apt-offline.sig
Копируем папку на комп с инетом и там выполняем:
# ./apt-offline get --bundle bundle.zip apt-offline.sig
Возращаем на комп без инета и запускаем установку пакета:
# ./apt-offline install bundle.zip
# apt install PACKAGENAME
У вас есть в хозяйстве сервера без интернета? У меня это некоторые сервера с бэкапами, правда там я сам вручную включаю инет когда надо, а потом отключаю. А вот полностью без инета приходилось работать у некоторых заказчиков. Таскал туда руками пакеты, пока не узнал про apt-offline. На днях про него вспомнил и написал заметку.
#debian #ubuntuHTTP/2.0 connection failed
restore failed: broken pipe
Скорее всего из-за каких-то проблем с каналом, хотя на практике он не отваливался. Восстановление падало в произвольном месте, но с 3-5 попытки в итоге всё получалось. Из-за этих проблем невозможно спрогнозировать время восстановления. Можно целый день пытаться и ничего не получится. Если других бэкапов нет, это провал. Нужно обязательно иметь архив на уровне данных, а не только VM.
Второй пример c Veeam. Есть архивы на уровне файлов, хотелось ещё и VM забэкапить полностью. А это файловые сервера с дисками по 1,5-2Т. Канал в интернет - 50 мегабит. На практике оказалось просто невозможно выполнить первый полный бэкап. Он должен длиться где-то 3-4 дня для каждый VM. Если по какой-то причине связь прервётся, всё надо начинать с начала. Докачки нет. Даже если каким-то чудом удастся сделать полный бэкап, очевидно, что восстановиться из него потом тоже не получится в разумные сроки. Я в итоге применил такую тактику. Оставлял по одному диску на VM, делал бэкап, потом добавлял второй диск, делал бэкап с ним и т.д., пока не будут добавлены все диски сервера. Так что рекомендую по возможности не делать один большой диск для VM. Лучше разбить на маленькие и потом объединить уже на уровне ОС. Это если вы хотите через интернет делать полные бэкапы VM. С одним большим диском это просто невозможно на практике сделать. При этом на уровне файлов все эти файловые сервера успешно бэкапятся, так как не критичны кратковременные обрывы связи. В данном случае мне полные бэкапы VM нужны, чтобы восстанавливать их локально на подменный сервер, который в случае необходимости будет физически доставлен в нужное место.
Какой из всего этого стоит сделать вывод? Надо всегда держать под рукой два вида бэкапов - полные VM и исходные данные в них (дампы баз, файлы и т.д.). Ну и проверять регулярно и то, и другое. Я повсеместно вижу, как люди делают бэкапы VM и на этом успокаиваются. И при этом много раз сталкивался с ситуациями, когда потом не получается восстановиться из этих бэкапов по разным причинам.
#backup# ./termdbms -p /var/lib/fail2ban/fail2ban.sqlite3
Помимо SQLite с помощью termdbms можно открывать CSV файлы, работать с ними и экспортировать в формат SQLite. То же самое работает и в обратную сторону - SQLite конвертирует в CSV.
#sqlite# cat /proc/sys/kernel/sysrq
▪ 0 - sysrq отключен
▪ 1 - sysrq полностью включен
Так же возможны другие варианты значений. Не буду приводить все их здесь, можно прочитать в ядерной документации - www.kernel.org/doc/htm…srq.html
Включить весь функционал sysrq можно так:
echo "1" >/proc/sys/kernel/sysrq
Если вы подключены напрямую к консоли сервера, то отправлять команды в ядро можно следующей комбинацией клавиш: ALT-SysRq-<command key>. Клавиша SysRq часто совмещена с PrtSc. Когда я первый раз тестировал эти функции, то пытался их ввести при SSH соединении. Работать не будет. При удалённом подключении команды можно отправлять так:
# echo <command key> > /proc/sysrq-trigger
Полное описание команд можно посмотреть в документации, на которую дал ссылку выше. Перечислю те, которые чаще всего могут пригодиться:
◽ b - моментальная перезагрузка;
◽ o - моментальное завершение работы;
◽ d - показывает блокировки, которые держат устройства или файлы;
◽ e - посылает SIGTERM всем процессам, кроме init;
◽ l - посылает SIGKILL всем процессам, кроме init;
◽ f - принудительно запускает oom killer;
◽ u - попытка перемонтировать все файловые системы в read-only;
◽ s - синхронизация подмонтированных файловых систем;
На основе перечисленных команд, можно прикинуть комбинацию, которую стоит попробовать сделать, если у вас подвис сервер и штатный reboot не проходит: e + l + s + u + b. То есть завершаем все процессы, синхронизируем файловые системы, отключаем запись на них и перезагружаемся. Не факт, что всё отработает без ошибок, но мы хотя бы попытались.
Больше примеров проблем, которые можно решить с помощью SysRq, смотрите по ссылке в самом конце статьи. Там отдельный раздел с примерами.
#terminal #linux/^\s+-L
/ - поиск вперёд
^ - начало строки
\s - пробельный символ
+ - повторитель, указывает, что предыдущий символ должен повторяться один или несколько раз
-L - то, что мы ищем.
То есть будет найдена строка, которая начинается с пробелов, а далее идут символы -L. Типовая разметка для описания ключей в man.
Ориентироваться в результатах поиска можно следующим образом:
- перейти к следующему совпадению клавиша (n);
- перейти к предыдущему совпадению клавиша (N);
- перейти в начало страницы клавиша (g);
- перейти в конец страницы клавиша (G).
Также less хранит историю поиска. Вводите / и листаете клавишами вверх, вниз. Таким образом можно выбрать предыдущий шаблон поиска. Более подробно man less, man man. Как там искать вы уже знаете 😁
В конце страниц для утилит командной строки, обычно есть коды возврата и прочая полезная информация. Кстати утилиты systemd по умолчанию тоже используют less. Так что всё написанное выше актуально и для поиска в systemd.
И ещё одна маленькая и полезная фишка, которая сохранит вам много времени и нервов. Когда что-то ищешь в man, потом хочешь проверить это в терминале, по ошибке выходишь из справки и потом приходится опять искать то, что было найдено. Но man не обязательно закрывать. Его можно свернуть комбинацией клавиш CTRL+Z. Приложение уйдёт в фоновый режим. Посмотреть, что работает в фоне, можно введя в консоли:
# bg
[1]+ man ls &
[1]+ Stopped man ls
Теперь возвращаем из фона процесс с man:
# fg man
И продолжаем читать там, где остановились. Подобные трюки можно делать с любыми процессами, запущенными в консоли.
#terminal #linux