Не так давно (в декабре 2024) на свет появилось любопытное ПО, которое условно можно назвать аналогом Apache Guacamole. Речь пойдёт о Termix – open source шлюзе и менеджере подключений к удалённым системам. Я его попробовал. Понравились идея и реализация, так что решил написать о ПО, хотя оно ещё по сути в стадии разработки и использовать его можно только для тестов или каких-то локальных контуров. Пишу о нём, чтобы не забыть и потом вернуться к более зрелым версиям.
Идея Termix следующая. Вы устанавливаете и настраиваете веб приложение, в которое добавляете удалённые соединения к серверам и другим системам. В настоящий момент работает только SSH, но в планах у автора VNC, RDP, SFTP. В браузере логинитесь в личный кабинет и оттуда получаете доступ к своим соединениям, которые работают там же в браузере. Причём у вас есть возможность делиться доступом к соединениям с другими пользователями. То есть это по сути групповой менеджер соединений с управляемым доступом.
Проект уже рабочий, можно попробовать. Запускаем через docker compose:
Идём по IP адресу сервера на порт 8080 и создаём нового пользователя. Далее добавляем соединения и подключаемся. Как я уже сказал, пока доступен только протокол SSH и аутентификация по паролю или ключу.
Сделано всё максимально просто и удобно, не то, что Apache Guacamole. Я его не очень люблю. Функционально он нормально сделан, но в плане установки и настройки немного геморройно. Постоянно приходится вспоминать формат конфигов, решать какие-то мелкие проблемы.
А тут всё просто. Запустил и пошёл в веб интерфейс создавать подключения. Сразу всё получилось без каких-то нюансов.
Автор планирует добавить разные темы терминалам, управление правами доступа на основе пользователей и групп, SSH туннелирование, 2FA ну и другие протоколы, которые я уже упоминал. Надеюсь у него всё получится. Мне кажется, продукт будет востребован. Да, такого рода софт уже есть, но он более сложен и масштабен. А вот такого простого, чтобы зашёл, быстро настроил, расшарил по пользователям и начал пользоваться, нет.
Ну и сразу добавлю, что такого рода софт нельзя выставлять напрямую в интернет. Надо закрывать либо белыми списками IP адресов, либо прятать за firewall. Это относится не только к этой программе, но ко всем подобным, в том числе и более зрелым, известным. Через уязвимость в такого роде программах можно разом всю инфраструктуру потерять, если у вас к ней был настроен доступ.
⇨ 🌐 Исходники / ▶️ Обзор
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#remote
Идея Termix следующая. Вы устанавливаете и настраиваете веб приложение, в которое добавляете удалённые соединения к серверам и другим системам. В настоящий момент работает только SSH, но в планах у автора VNC, RDP, SFTP. В браузере логинитесь в личный кабинет и оттуда получаете доступ к своим соединениям, которые работают там же в браузере. Причём у вас есть возможность делиться доступом к соединениям с другими пользователями. То есть это по сути групповой менеджер соединений с управляемым доступом.
Проект уже рабочий, можно попробовать. Запускаем через docker compose:
# mkdir ~/termix && cd ~/termix# touch docker-compose.ymlservices:
termix:
image: ghcr.io/lukegus/termix:latest
container_name: termix
restart: unless-stopped
ports:
- "8080:8080"
volumes:
- mongodb-data:/data/db
environment:
SALT: "2v.F7!6a!jIzmJsu|[)h61$ZMXs;,i+~"
volumes:
mongodb-data:
driver: local
# docker-compose up -dИдём по IP адресу сервера на порт 8080 и создаём нового пользователя. Далее добавляем соединения и подключаемся. Как я уже сказал, пока доступен только протокол SSH и аутентификация по паролю или ключу.
Сделано всё максимально просто и удобно, не то, что Apache Guacamole. Я его не очень люблю. Функционально он нормально сделан, но в плане установки и настройки немного геморройно. Постоянно приходится вспоминать формат конфигов, решать какие-то мелкие проблемы.
А тут всё просто. Запустил и пошёл в веб интерфейс создавать подключения. Сразу всё получилось без каких-то нюансов.
Автор планирует добавить разные темы терминалам, управление правами доступа на основе пользователей и групп, SSH туннелирование, 2FA ну и другие протоколы, которые я уже упоминал. Надеюсь у него всё получится. Мне кажется, продукт будет востребован. Да, такого рода софт уже есть, но он более сложен и масштабен. А вот такого простого, чтобы зашёл, быстро настроил, расшарил по пользователям и начал пользоваться, нет.
Ну и сразу добавлю, что такого рода софт нельзя выставлять напрямую в интернет. Надо закрывать либо белыми списками IP адресов, либо прятать за firewall. Это относится не только к этой программе, но ко всем подобным, в том числе и более зрелым, известным. Через уязвимость в такого роде программах можно разом всю инфраструктуру потерять, если у вас к ней был настроен доступ.
⇨ 🌐 Исходники / ▶️ Обзор
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#remote
3👍105👎4
С системным временем в Linux с одной стороны всё просто - установил и запустил какую-то службу для синхронизации и дальше всё работает автоматически. Например службу systemd-timesyncd, chrony или ntp. А с другой - есть множество нюансов, которые в основном связаны с особенностями systemd.
В целом, любой из способов задачу решает, но иногда возникают небольшие проблемы. Например, бывают виртуалки, которые со старта имеют сильный сдвиг по времени - 2-3 минуты, или даже больше. Я не знаю, с чем конкретно это может быть связано. Наблюдал и на арендованных виртуалках, и на своих. Служба синхронизации времени исправляет эту погрешность, но в зависимости от системы и настроек в ней, служба синхронизации времени может стартануть после другой службы. В итоге в логах после загрузки системы некоторое время может быть небольшая путаница, пока все службы не получат актуальное время.
Заметил ещё такую особенность. Служба chrony в Debian как правило со своими стандартными настройками запускается и отрабатывает раньше всех, а вот в Ubuntu - нет, хотя настройки юнитов вроде как схожи. Но я не разбирался детально. В systemd не так просто разобраться. Много нюансов и ссылок с зависимостями юнитов, таргетов и т.д. А если взять службу systemd-timesyncd, то она по умолчанию может довольно поздно запуститься. Я последнее время именно её использую, чтобы не ставить лишних пакетов в систему, но по факту chrony удобнее и функциональнее.
Эту проблему частично можно решить простым хаком в лоб. Ставим chrony и создаём службу, которая будет стартовать раньше всех остальных, один раз запускать синхронизацию и выключаться. А дальше уже всё остальное будет загружаться как обычно. Не нужно будет лезть в потроха systemd и разбираться в настройках и зависимостях стандартных служб.
Можно посмотреть зависимости служб:
Chrony-once-sync.service должна стоять первой в списке
Также можно посмотреть весь лог загрузки и убедиться, что chrony-once-sync.service отработала раньше всех остальных. Практически сразу после активации сети.
Не претендую на полноту и правильность решения. Решил задачу, как говорится, в лоб. Более правильным было бы разобраться с зависимостями служб. Например, выставить службам, критичным к точному времени зависимость от chrony:
Хотя тут правильнее было бы привязаться к специальному таргету, который придуман для этих задач -
В этом случае придётся вручную каждый раз разбираться со службами, а с одноразовым юнитом можно особо не заморачиваться. Он просто запустится раньше всех и если служба точного времени у вас локальная, отработает очень быстро, остальные сервисы уже подхватят точное время. При этом такое решение подойдёт для разовой начальной синхронизации, а дальше можно использовать любые другие службы, не обязательно chrony. Или вообще не использовать, если запускаете какое-то одноразовое окружение.
☝️ Представленный юнит можно использовать как заготовку для других подобных задач с разовыми задачами раньше всех остальных служб.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#systemd
В целом, любой из способов задачу решает, но иногда возникают небольшие проблемы. Например, бывают виртуалки, которые со старта имеют сильный сдвиг по времени - 2-3 минуты, или даже больше. Я не знаю, с чем конкретно это может быть связано. Наблюдал и на арендованных виртуалках, и на своих. Служба синхронизации времени исправляет эту погрешность, но в зависимости от системы и настроек в ней, служба синхронизации времени может стартануть после другой службы. В итоге в логах после загрузки системы некоторое время может быть небольшая путаница, пока все службы не получат актуальное время.
Заметил ещё такую особенность. Служба chrony в Debian как правило со своими стандартными настройками запускается и отрабатывает раньше всех, а вот в Ubuntu - нет, хотя настройки юнитов вроде как схожи. Но я не разбирался детально. В systemd не так просто разобраться. Много нюансов и ссылок с зависимостями юнитов, таргетов и т.д. А если взять службу systemd-timesyncd, то она по умолчанию может довольно поздно запуститься. Я последнее время именно её использую, чтобы не ставить лишних пакетов в систему, но по факту chrony удобнее и функциональнее.
Эту проблему частично можно решить простым хаком в лоб. Ставим chrony и создаём службу, которая будет стартовать раньше всех остальных, один раз запускать синхронизацию и выключаться. А дальше уже всё остальное будет загружаться как обычно. Не нужно будет лезть в потроха systemd и разбираться в настройках и зависимостях стандартных служб.
# apt install chrony# systemctl edit --full --force chrony-once-sync.service[Unit]Description=Chrony one time sync and exitWants=network-online.targetAfter=network-online.targetBefore=multi-user.target[Service]Type=oneshotExecStart=/usr/sbin/chronyd -t 10 -qRemainAfterExit=True[Install]WantedBy=multi-user.target# systemctl enable chrony-once-sync.serviceМожно посмотреть зависимости служб:
# systemctl list-dependencies --afterChrony-once-sync.service должна стоять первой в списке
multi-user.target. Перезагружаемся и проверяем. Смотрим, как отработала служба:# journalctl -u chrony-once-syncТакже можно посмотреть весь лог загрузки и убедиться, что chrony-once-sync.service отработала раньше всех остальных. Практически сразу после активации сети.
# journalctlНе претендую на полноту и правильность решения. Решил задачу, как говорится, в лоб. Более правильным было бы разобраться с зависимостями служб. Например, выставить службам, критичным к точному времени зависимость от chrony:
[Unit]After=chrony.serviceХотя тут правильнее было бы привязаться к специальному таргету, который придуман для этих задач -
time-sync.target. Можно использовать его в зависимостях, но надо внимательно смотреть, что все остальные зависимости с этим таргетом корректно настроены.В этом случае придётся вручную каждый раз разбираться со службами, а с одноразовым юнитом можно особо не заморачиваться. Он просто запустится раньше всех и если служба точного времени у вас локальная, отработает очень быстро, остальные сервисы уже подхватят точное время. При этом такое решение подойдёт для разовой начальной синхронизации, а дальше можно использовать любые другие службы, не обязательно chrony. Или вообще не использовать, если запускаете какое-то одноразовое окружение.
☝️ Представленный юнит можно использовать как заготовку для других подобных задач с разовыми задачами раньше всех остальных служб.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#systemd
👍121👎6
Есть небольшой и неприметный сервис, который может очень существенно помочь в отладке различных HTTP запросов. В контексте тематики канала он может помочь в создании и отладке мониторинга. Речь пойдёт о httpbin.org. Это публичный сервис, который можно использовать как по указанному адресу, так и запустить у себя локально:
По главной странице сервиса не совсем понятно, как его использовать. Я покажу сразу на примерах. Допустим, вы настраиваете мониторинг сайта или API. Вам нужно проверить работу различных триггеров. Например, на код ответа 404. Чтобы получить от httpbin код ответа 404, обращаемся к нему по адресу:
Соответственно, если вам нужен другой код, то просто меняете его:
Аналогично можно тестировать ответы с заданными заранее заголовками. Проверяем ответ с заголовком
Идём далее. Тестируем триггер на время ответа сервиса. Например, проверяем работу при задержке более 3-х секунд:
Получите тестовый ответ с задержкой в 3 секунды. Можно проверить с помощью time.
Учимся принимать поток из нескольких строк. В данном случае трёх:
Получите 3 разных строки с json.
Принимаем картинку:
Сервис много всего умеет. Посмотрите на главной странице, открывая раскрывающиеся списки. Я привёл самые ходовые на мой взгляд примеры при настройке типового мониторинга. А так там поддерживаются и разные методы, и динамические списки, и разное сжатие, и куки, и кодирование и т.д.
Сервис полезен не только администраторам и девопсам, но и разработчикам для отладки своих веб приложений. Думаю, он для них в основном и был написан.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#мониторинг
# docker run -p 80:80 kennethreitz/httpbinПо главной странице сервиса не совсем понятно, как его использовать. Я покажу сразу на примерах. Допустим, вы настраиваете мониторинг сайта или API. Вам нужно проверить работу различных триггеров. Например, на код ответа 404. Чтобы получить от httpbin код ответа 404, обращаемся к нему по адресу:
# curl -I "https://httpbin.org/status/404"HTTP/2 404Соответственно, если вам нужен другой код, то просто меняете его:
# curl -I "https://httpbin.org/status/501"HTTP/2 501Аналогично можно тестировать ответы с заданными заранее заголовками. Проверяем ответ с заголовком
Server=httpbin# curl "https://httpbin.org/response-headers?Server=httpbin"{ "Content-Length": "92", "Content-Type": "application/json", "Server": "httpbin"}Идём далее. Тестируем триггер на время ответа сервиса. Например, проверяем работу при задержке более 3-х секунд:
# curl "https://httpbin.org/delay/3"Получите тестовый ответ с задержкой в 3 секунды. Можно проверить с помощью time.
# time curl "https://httpbin.org/delay/3"Учимся принимать поток из нескольких строк. В данном случае трёх:
# curl "https://httpbin.org/stream/3"Получите 3 разных строки с json.
Принимаем картинку:
# curl "https://httpbin.org/image/png"# curl "https://httpbin.org/image/png" --output picture.pngСервис много всего умеет. Посмотрите на главной странице, открывая раскрывающиеся списки. Я привёл самые ходовые на мой взгляд примеры при настройке типового мониторинга. А так там поддерживаются и разные методы, и динамические списки, и разное сжатие, и куки, и кодирование и т.д.
Сервис полезен не только администраторам и девопсам, но и разработчикам для отладки своих веб приложений. Думаю, он для них в основном и был написан.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#мониторинг
2👍106👎2
Одним из самых популярных репозиториев на github (21-е место по кол-ву звёзд) является репозиторий с ohmyzsh. Это фреймворк для создания конфигураций оболочки zsh. Для тех, кто не понимает, что это такое, скажу просто. Это сильно прокачанный по функциональности bash.
Никогда не понимал страсти и большой народной любви к zsh и ohmyzsh в частности. Хотя несколько раз пробовал. У меня и на рабочей станции, и на серверах всегда обычный bash. Мне кажется такое единообразие удобнее.
Если захотите попробовать zsh c ohmyzsh, то сделать это можно так:
Дальше поверх этого делаются различные настройки
Основные возможности ohmyzsh:
◽️Поддержка тем для консоли и промта в частности. Причём тем не только по изменению внешнего вида, но и в плане функциональности: отображение ветки git, таймер выполнения текущей команды и другие возможности.
◽️Большой набор готовых плагинов. Они могут добавлять алиасы, включать автодополнение при наборе команд, к примеру, от docker, git, kubectl, ansible и т.д. Там есть интеграции с менеджерами паролей, с screen и tmux, с батареей ноутбука. Чего там только нет.
В общем, ohmyzsh открывает безграничный простор для изменения и настройки командной строки. Мне это напоминает времена, когда были очень популярный виджеты в Windows. Я время от времени ковырялся в них, настраивал какую-то красоту и удобство. Через неделю все всё это надоедало и я убирал.
С ohmyzsh то же самое. Я аналог этой оболочки даже на виндовый терминал сталвил – oh-my-posh. Потом надоело, убрал. Отзывчивость консоли падает. Все эти расширения и плагины какие-то ресурсы забирают и добавляют задержку. В итоге ни zsh, ни его расширения у меня так и не прижились.
А вы используете эти украшательства или предпочитаете обычный bash? Я даже promt в нём не меняю, оставляю стандартный user@hostname.
#terminal #linux
Никогда не понимал страсти и большой народной любви к zsh и ohmyzsh в частности. Хотя несколько раз пробовал. У меня и на рабочей станции, и на серверах всегда обычный bash. Мне кажется такое единообразие удобнее.
Если захотите попробовать zsh c ohmyzsh, то сделать это можно так:
# apt install zsh# wget https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh# sh install.shДальше поверх этого делаются различные настройки
Основные возможности ohmyzsh:
◽️Поддержка тем для консоли и промта в частности. Причём тем не только по изменению внешнего вида, но и в плане функциональности: отображение ветки git, таймер выполнения текущей команды и другие возможности.
◽️Большой набор готовых плагинов. Они могут добавлять алиасы, включать автодополнение при наборе команд, к примеру, от docker, git, kubectl, ansible и т.д. Там есть интеграции с менеджерами паролей, с screen и tmux, с батареей ноутбука. Чего там только нет.
В общем, ohmyzsh открывает безграничный простор для изменения и настройки командной строки. Мне это напоминает времена, когда были очень популярный виджеты в Windows. Я время от времени ковырялся в них, настраивал какую-то красоту и удобство. Через неделю все всё это надоедало и я убирал.
С ohmyzsh то же самое. Я аналог этой оболочки даже на виндовый терминал сталвил – oh-my-posh. Потом надоело, убрал. Отзывчивость консоли падает. Все эти расширения и плагины какие-то ресурсы забирают и добавляют задержку. В итоге ни zsh, ни его расширения у меня так и не прижились.
А вы используете эти украшательства или предпочитаете обычный bash? Я даже promt в нём не меняю, оставляю стандартный user@hostname.
#terminal #linux
👍90👎4
Для просмотра дерева запущенных процессов в системе Linux можно использовать разные способы. Я давно знаю 2 из них и постоянно применяю:
1️⃣ В утилите
2️⃣ Консольная команда
На днях просматривал репозиторий the-art-of-command-line. Там в основном информация для новичков. Большую часть я и так знаю, но нашёл для себя кое-что новое.
3️⃣ Есть программа
Есть ещё пара полезных ключей:
Посмотрел все остальные ключи, полезными их не нашёл.
Берите на вооружение, если как и я не знали о существовании этой утилиты.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal
htop, которую я всегда ставлю на сервера под своим управлением, есть режим древовидного отображения процессов. Для этого надо нажать клавишу t (tree view). Это удобно, когда в моменте надо что-то быстро посмотреть. Если процессов много и надо вдумчиво изучить список, то в htop не очень удобно из-за того, что интерфейс интерактивный.ps axf, а если список большой то она же, но направленная в текстовый файл ps axf > ~/ptree.txt. Там уже можно более спокойно и осмысленно всё посмотреть.На днях просматривал репозиторий the-art-of-command-line. Там в основном информация для новичков. Большую часть я и так знаю, но нашёл для себя кое-что новое.
pstree в составе пакета psmisc. Он во многих системах есть в базовом наборе системных утилит, либо ставится из стандартных репозиториев. С помощью pstree можно вывести древовидный список процессов в наглядном виде. Нагляднее, чем у ps. # pstree -pЕсть ещё пара полезных ключей:
-t – показывает полные имена подпроцессов. Для некоторых служб показывает чуть больше информации.-n – сортировка по pid, а не имени.-С age – раскраска имён процессов по возрасту. Процессы новее 60 секунд выводятся зелёными, новее часа – жёлтыми, а остальные красными.Посмотрел все остальные ключи, полезными их не нашёл.
Берите на вооружение, если как и я не знали о существовании этой утилиты.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍163👎2
Для тех, кому в консоли достаточно обычного bash, могу порекомендовать ресурс, с помощью которого можно быстро настроить себе prompt. Для тех, кто не знает, что это такое, поясню. Promt – это информация, которая отображается в командной строке перед полем с вводом своей команды. Его называют приглашением командной строки.
Стандартный promt чаще всего
Из того, что обычно добавляют, отмечу следующие вещи:
- отображение IP адреса сервера
- подсветка промта разными цветами на разных серверах
- подсветка промта красным цветом при работе от root
- вывод времени
Немного поигрался в конструкторе и собрал следующий промт:
Теперь эту команду надо добавить в
В данном случае мы настроили promt у конкретного пользователя. Я цвет имени пользователя сделал красным, потому что это root. Для остальных пользователей promt можно вообще не менять, либо задать индивидуальный. Общие же настройки для всех пользователей живут в системном файле
Если у вас какой-то прикольный и необычный promt, поделитесь, пожалуйста, информацией.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#terminal #bash
Стандартный promt чаще всего
user@host-name:current-directory# . С помощью сайта bash-prompt-generator.org можете легко его изменить, просто собрав как в конструкторе те элементы, что вам нужны. И тут же на сайте видно, как будет выглядеть приглашение командной строки. Из того, что обычно добавляют, отмечу следующие вещи:
- отображение IP адреса сервера
- подсветка промта разными цветами на разных серверах
- подсветка промта красным цветом при работе от root
- вывод времени
Немного поигрался в конструкторе и собрал следующий промт:
[[email protected]|192.168.1.100] 20:32:03 (~/bin)$ █PROMPT_COMMAND='PS1_CMD1=$(ip route get 1.1.1.1 | awk -F"src " '"'"'NR == 1{ split($2, a," ");print a[1]}'"'"')'; PS1='[\[\e[38;5;196m\]\u\[\e[0m\]@\H|${PS1_CMD1}] \t (\[\e[4m\]\w\[\e[0m\])\$ 'Теперь эту команду надо добавить в
~/.bashrc и применить изменения:# source ~/.bashrcВ данном случае мы настроили promt у конкретного пользователя. Я цвет имени пользователя сделал красным, потому что это root. Для остальных пользователей promt можно вообще не менять, либо задать индивидуальный. Общие же настройки для всех пользователей живут в системном файле
/etc/bash.bashrc. Если у вас какой-то прикольный и необычный promt, поделитесь, пожалуйста, информацией.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#terminal #bash
103👍174👎3
В разное время на канале выходили публикации на тему логирования действий пользователя в терминале, в частности при подключениях по SSH. Тема востребованная, актуальная, так что решил все заметки по ней собрать в одном месте. К тому же решения предлагались очень сильно разные. Будет полезно их увидеть и сравнить в одном месте, от самых простых, до больших корпоративных систем.
◽️Snoopy — небольшая библиотека под Linux, которая может логировать не только команды пользователей, но многое другое. Например, команды системных процессов. Продукт простой в настройке, живой, обновляется. Приехал в базовые репозитории популярных дистрибутивов. Работает сам по себе, без необходимости менять настройки SSH или пользователей.
◽️Log-user-session — программа, которая запускается вместо оболочки пользователя и пропускает через себя все его команды, записывая их в текстовый файл. Продукт старый, не поддерживается, но продолжает работать. Подключившись по SSH пользователь никак не закроет log-user-session и не выполнит команду мимо неё. Его просто отключит от сервера.
◽️PROMPT_COMMAND — использование встроенных возможностей оболочки bash. Содержимое переменной PROMPT_COMMAND выполняется после каждой введённой интерактивной команды. Мы просто выполняем команду
◽️Sshlog — работает как отдельная служба, умеет не только логировать действия пользователей по SSH, но и слать уведомления, в том числе на заданные действия, собирать метрики по подключениям, осуществлять внешний доступ к открытым сессиям пользователей. Программа в своё время была сделана добротно и законченно, с сайтом и документацией, но потом разработку как-будто забросили.
◽️Tlog — современная программа от RedHat с полным названием Terminal logger. Поддерживает различные хранилища для логов: текстовые файлы, syslog сервер, журнал systemd или в elasticsearch. Формат - json, то есть удобно делать поиск и выборку. Разработана для интеграции в экосистему Redhat, поддерживает интеграцию с FreeIPA через SSSD. Есть в базовых репозиториях.
◽️Teleport — масштабная система по управлению удалённым доступом к закрытым от внешнего доступа системам. В том числе осуществляет управление SSH соединениями с помощью своего приложения для установления соединений. Умеет записывать сессии не просто на уровне перехвата команд и вывода в консоль с хранением в текстовом виде, но полноценно записывает сессию, которую можно воспроизвести в режиме реального времени.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#ssh #logs #подборка
◽️Snoopy — небольшая библиотека под Linux, которая может логировать не только команды пользователей, но многое другое. Например, команды системных процессов. Продукт простой в настройке, живой, обновляется. Приехал в базовые репозитории популярных дистрибутивов. Работает сам по себе, без необходимости менять настройки SSH или пользователей.
◽️Log-user-session — программа, которая запускается вместо оболочки пользователя и пропускает через себя все его команды, записывая их в текстовый файл. Продукт старый, не поддерживается, но продолжает работать. Подключившись по SSH пользователь никак не закроет log-user-session и не выполнит команду мимо неё. Его просто отключит от сервера.
◽️PROMPT_COMMAND — использование встроенных возможностей оболочки bash. Содержимое переменной PROMPT_COMMAND выполняется после каждой введённой интерактивной команды. Мы просто выполняем команду
history 1, которая показывает последнюю введённую команду и куда-то записываем её: в файл или syslog. Решение максимально простое и понятное, но со своими нюансами. Надо промты менять и следить, чтобы обратно не менялись.◽️Sshlog — работает как отдельная служба, умеет не только логировать действия пользователей по SSH, но и слать уведомления, в том числе на заданные действия, собирать метрики по подключениям, осуществлять внешний доступ к открытым сессиям пользователей. Программа в своё время была сделана добротно и законченно, с сайтом и документацией, но потом разработку как-будто забросили.
◽️Tlog — современная программа от RedHat с полным названием Terminal logger. Поддерживает различные хранилища для логов: текстовые файлы, syslog сервер, журнал systemd или в elasticsearch. Формат - json, то есть удобно делать поиск и выборку. Разработана для интеграции в экосистему Redhat, поддерживает интеграцию с FreeIPA через SSSD. Есть в базовых репозиториях.
◽️Teleport — масштабная система по управлению удалённым доступом к закрытым от внешнего доступа системам. В том числе осуществляет управление SSH соединениями с помощью своего приложения для установления соединений. Умеет записывать сессии не просто на уровне перехвата команд и вывода в консоль с хранением в текстовом виде, но полноценно записывает сессию, которую можно воспроизвести в режиме реального времени.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#ssh #logs #подборка
1👍99👎2
Я уже ранее делал заметку насчёт LVM, где пояснил, что чаще всего виртуалки делаю с LVM. Это добавляет некоторые удобства, которые по сути ничего не стоят. То есть не вижу смысла их не использовать. Хоть и не часто, но LVM может сильно выручить.
Например, была виртуалка с большим разделом под хранилище. Покупалось всё с запасом, но через несколько лет место всё равно закончилось. В сервере были свободные слоты под диски. Добавили пару дисков, сделали RAID1, подключили его к виртуалке и расширили раздел с данными. Никаких рискованных движений, никаких переносов данных, даже перезапуск виртуалки не понадобился. Всё сделали наживую.
Расскажу про ещё одну фичу LVM, которую легко использовать, и которая в некоторых ситуациях может серьезно выручить. Речь пойдёт про снепшоты. Именно снепшот LVM спас Gitlab во время эпической аварии, когда они могли потерять все данные, но между делом сделанный снепшот их спас.
Снепшоты могут выручить, если у вас хранилище гипервизора без их поддержки, что не так уж редко бывает. Например, хранилище в Proxmox типа LVM, не LVMThin, снепшоты не поддерживает. Также актуально, если вы арендуете VPS без доступа к гипервизору. Обычно там можно только расширить диск, что достаточно для использования снепшотов.
Для того, чтобы использовать снепшоты LVM никаких настроек делать не надо. Главное условие – в VG должно быть свободное место. Если его нет, то надо его где-то найти. Покажу на конкретном примере.
Беру виртуалку, которая полностью установлена на LVM, что я чаще всего и делаю. На VG свободного места нет. Проверяем это:
Добавляем в виртуальную машину ещё один диск, либо расширяем существующий. Принципиальной разницы нет. У вас либо появится новый диск, либо новый раздел на текущем диске. Их и используем для расширения VG. Я добавил диск sdb размером 10G. Расширяю им VG:
По хорошему лучше сначала сделать раздел sdb1, и расширить уже им, но для краткости опускаю этот момент.
Теперь могу создать снепшот корня. Делаю ему размер 9G:
Смотрю, что получилось:
По сути появился ещё один LV. С ним можно работать, как с обычным разделом. Например, подмонтировать его:
Увидим в /mnt состояние системы на момент создания снепшота.
Посмотрим, как снепшот работает. Полностью обновим систему и перезагрузимся:
После перезагрузки посмотрим на статус LV и на версию загруженного ядра:
Допустим, что-то пошло не так и нам надо откатиться на состояние до обновления. Восстанавливаем снепшот:
Видим ошибку:
Это нормально, так как для восстановления нужно размонтировать LV. Наживую восстановить снепшот нельзя. Восстановление будет запущено после перезагрузки, во время активации LV. Текущий корневой LV будет помечен как (O)rigin with merging snapshot, это видно в lvs:
После первой перезагрузки начнётся восстановление из снепшота. Так как это корневой раздел, полностью всё перезаписать не получится, так как раздел системный, файлы заняты рабочими процессами. Делаем
Для несистемного раздела всё выполняется без перезагрузок. В случае, если всё ОК и снепшот не пригодился, удаляем его:
💥 Обязательно удалите снепшот после того, как убедитесь, что он не нужен.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#lvm
Например, была виртуалка с большим разделом под хранилище. Покупалось всё с запасом, но через несколько лет место всё равно закончилось. В сервере были свободные слоты под диски. Добавили пару дисков, сделали RAID1, подключили его к виртуалке и расширили раздел с данными. Никаких рискованных движений, никаких переносов данных, даже перезапуск виртуалки не понадобился. Всё сделали наживую.
Расскажу про ещё одну фичу LVM, которую легко использовать, и которая в некоторых ситуациях может серьезно выручить. Речь пойдёт про снепшоты. Именно снепшот LVM спас Gitlab во время эпической аварии, когда они могли потерять все данные, но между делом сделанный снепшот их спас.
Снепшоты могут выручить, если у вас хранилище гипервизора без их поддержки, что не так уж редко бывает. Например, хранилище в Proxmox типа LVM, не LVMThin, снепшоты не поддерживает. Также актуально, если вы арендуете VPS без доступа к гипервизору. Обычно там можно только расширить диск, что достаточно для использования снепшотов.
Для того, чтобы использовать снепшоты LVM никаких настроек делать не надо. Главное условие – в VG должно быть свободное место. Если его нет, то надо его где-то найти. Покажу на конкретном примере.
Беру виртуалку, которая полностью установлена на LVM, что я чаще всего и делаю. На VG свободного места нет. Проверяем это:
# pvsДобавляем в виртуальную машину ещё один диск, либо расширяем существующий. Принципиальной разницы нет. У вас либо появится новый диск, либо новый раздел на текущем диске. Их и используем для расширения VG. Я добавил диск sdb размером 10G. Расширяю им VG:
# vgextend vgroup /dev/sdbПо хорошему лучше сначала сделать раздел sdb1, и расширить уже им, но для краткости опускаю этот момент.
# pvsPV VG Fmt Attr PSize PFree /dev/sda1 vgroup lvm2 a-- <20.00g 0 /dev/sdb vgroup lvm2 a-- <10.00g <10.00gТеперь могу создать снепшот корня. Делаю ему размер 9G:
# lvcreate -L 9G -s -n root_snap /dev/vgroup/rootСмотрю, что получилось:
# lvsПо сути появился ещё один LV. С ним можно работать, как с обычным разделом. Например, подмонтировать его:
# mount /dev/vgroup/root_snap /mntУвидим в /mnt состояние системы на момент создания снепшота.
Посмотрим, как снепшот работает. Полностью обновим систему и перезагрузимся:
# apt update && apt upgrade -y && rebootПосле перезагрузки посмотрим на статус LV и на версию загруженного ядра:
# lvsroot vgroup owi-aos--- <20.00g root_snap vgroup swi-a-s--- 9.00g root 15.85 # uname -aДопустим, что-то пошло не так и нам надо откатиться на состояние до обновления. Восстанавливаем снепшот:
# lvconvert --merge /dev/vgroup/root_snapВидим ошибку:
Delaying merge since origin is open.Merging of snapshot vgroup/root_snap will occur on next activation of vgroup/root.Это нормально, так как для восстановления нужно размонтировать LV. Наживую восстановить снепшот нельзя. Восстановление будет запущено после перезагрузки, во время активации LV. Текущий корневой LV будет помечен как (O)rigin with merging snapshot, это видно в lvs:
# lvsroot vgroup Owi-aos--- <20.00gПосле первой перезагрузки начнётся восстановление из снепшота. Так как это корневой раздел, полностью всё перезаписать не получится, так как раздел системный, файлы заняты рабочими процессами. Делаем
reboot ещё раз. После него система вернётся в состояние до снепшота. Можно проверить это по загруженному ядру:# uname -aДля несистемного раздела всё выполняется без перезагрузок. В случае, если всё ОК и снепшот не пригодился, удаляем его:
# lvremove /dev/vgroup/root_snap💥 Обязательно удалите снепшот после того, как убедитесь, что он не нужен.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#lvm
1👍187👎3
Продолжу вчерашнюю тему со снепшотами LVM, так как в публикации не хватило лимита по объёму. Работать со снепшотами можно как с обычными разделами. Его можно монтировать, сохранять в образ и передавать куда-то по сети. Либо без сохранения сразу по сети передать напрямую.
Допустим, вы сделали снепшот
Получили живой бэкап. Его можно, к примеру, подмонтировать и посмотреть данные:
У нас копия сервера, подключенная к другому серверу. Точно так же можно сохранить снимок локально в файл. Только нужно иметь ввиду, что это должен быть другой раздел. Иначе вы снепшот в снепшот сохранять начнёте.
Из этого снимка можно восстановить систему полностью. Для этого нужен будет какой-то загрузочный диск c Linux. Нужно будет восстановить данные из образа на какой-то диск и отдельно установить на него загрузчик grub. То есть это простой и гарантированный способ получить целостную копию работающей системы и спокойно передать её куда-то по сети.
☝️ Отмечу ещё раз отдельно, что снепшоты LVM – вполне стабильная и рабочая функциональность. Это не какой-то хак, трюк, костыль, который работает на свой страх и риск. Можно без особых опасений её использовать, главное понимать нюансы работы снепшотов. Они немного снижают производительность, их нельзя оставлять надолго, так как они начинают занимать место в VG, которое может кончиться. Могут возникнуть проблемы.
Снепшот делается по ситуации, проверяется работа после его создания. Потом он либо куда-то сохраняется, либо откатывается, либо сливается с текущим состоянием. Оставлять его не нужно. Слияние большого снепшота, особенно на нагруженной системе, может прилично нагрузить дисковую подсистему.
Вот ещё одно коротенькое руководство, как можно с помощью снепшотов безопасно обновить систему, которая установлена в VG vgroup на LV root.
Переименовываем текущий LV и создаём вместо него snapshot с таким же названием:
Перезагружаемся. Теперь у нас снепшот в роли корневого раздела. Мы можем выполнять какие-то действия с системой - обновлять, ломать, тестировать какую-то функциональность. Когда закончите, можно зафиксировать это. Переименовываем текущее состояние в виде снепшота в новое, а корень возвращаем обратно, как было:
Если изменения вам подошли и вы готовы их принять, то сливаем снепшот нового состояния с текущем корнем:
После перезагрузки по lvs смотрим, когда слияние закончится и перезагружаемся ещё раз:
Чтобы все изменения применились, надо перезагрузиться 2 раза. Снепшот при слиянии удаляется автоматически, ничего для этого делать не надо.
Если же вам изменения не нужны, то просто удаляем снепшот:
Инструкция 100% рабочая. Проверял несколько раз и на прошлой заметке, и на этой. Снепшоты, когда вся система вместе с /boot разделом на LVM работают без проблем.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#lvm
Допустим, вы сделали снепшот
/dev/vgroup/root_snap. Можете его сразу передать на другой сервер:# dd if=/dev/vgroup/root_snap | ssh [email protected] "dd of=vgroup-root.img"Получили живой бэкап. Его можно, к примеру, подмонтировать и посмотреть данные:
# mount vgroup-root.img /mntУ нас копия сервера, подключенная к другому серверу. Точно так же можно сохранить снимок локально в файл. Только нужно иметь ввиду, что это должен быть другой раздел. Иначе вы снепшот в снепшот сохранять начнёте.
# dd if=/dev/vgroup/root_snap of=/mnt/backup/vgroup-root.imgИз этого снимка можно восстановить систему полностью. Для этого нужен будет какой-то загрузочный диск c Linux. Нужно будет восстановить данные из образа на какой-то диск и отдельно установить на него загрузчик grub. То есть это простой и гарантированный способ получить целостную копию работающей системы и спокойно передать её куда-то по сети.
☝️ Отмечу ещё раз отдельно, что снепшоты LVM – вполне стабильная и рабочая функциональность. Это не какой-то хак, трюк, костыль, который работает на свой страх и риск. Можно без особых опасений её использовать, главное понимать нюансы работы снепшотов. Они немного снижают производительность, их нельзя оставлять надолго, так как они начинают занимать место в VG, которое может кончиться. Могут возникнуть проблемы.
Снепшот делается по ситуации, проверяется работа после его создания. Потом он либо куда-то сохраняется, либо откатывается, либо сливается с текущим состоянием. Оставлять его не нужно. Слияние большого снепшота, особенно на нагруженной системе, может прилично нагрузить дисковую подсистему.
Вот ещё одно коротенькое руководство, как можно с помощью снепшотов безопасно обновить систему, которая установлена в VG vgroup на LV root.
Переименовываем текущий LV и создаём вместо него snapshot с таким же названием:
# lvrename vgroup root root-old# lvcreate -n root -s /dev/vgroup/root-old -L 9G# rebootПерезагружаемся. Теперь у нас снепшот в роли корневого раздела. Мы можем выполнять какие-то действия с системой - обновлять, ломать, тестировать какую-то функциональность. Когда закончите, можно зафиксировать это. Переименовываем текущее состояние в виде снепшота в новое, а корень возвращаем обратно, как было:
# lvrename vgroup root root-new # lvrename vgroup root-old rootЕсли изменения вам подошли и вы готовы их принять, то сливаем снепшот нового состояния с текущем корнем:
# lvconvert --merge /dev/vgroup/root-new# rebootПосле перезагрузки по lvs смотрим, когда слияние закончится и перезагружаемся ещё раз:
# lvs# rebootЧтобы все изменения применились, надо перезагрузиться 2 раза. Снепшот при слиянии удаляется автоматически, ничего для этого делать не надо.
Если же вам изменения не нужны, то просто удаляем снепшот:
# lvremove /dev/vgroup/root-new# rebootИнструкция 100% рабочая. Проверял несколько раз и на прошлой заметке, и на этой. Снепшоты, когда вся система вместе с /boot разделом на LVM работают без проблем.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#lvm
9👍132👎2
Media is too big
VIEW IN TELEGRAM
▶️ ИНЖЕНЕР "ПРО РУТИНУ"
Специфичный юмор, заточенный под позднесоветскую ностальгию для тех, кому 40+, а может и все 50+. Сразу скажу, что у этого автора больше ничего не нравится. А этот ролик как-то запал. Не знаю почему. Мне он показался очень близким к современному крупному корпоративному IT с его удалёнкой, зачастую бессмысленной рутиной и кластерами Кубернетис, которые всё внедряют и внедряют.
"Везде все одинаковые. Всё вокруг одно и то же. Одно и то же по кругу, как на стадионе."
"Я уже неделю на работу хожу и ни разу туда не пришёл!"
"Мы изобрели какой-то провод странный, зачем он нужен? 5 лет работали над ним."
К сожалению, не обладаю хорошими навыками монтажа видео. В конце так и просится переделка в стиле:
"Мы внедрили кластер Kubernetes. Зачем он нужен? 5 лет работали над ним, монолит пилили."
И потом вот это видео в продолжении:❓ А у вас есть Кубернетис?
#юмор
Специфичный юмор, заточенный под позднесоветскую ностальгию для тех, кому 40+, а может и все 50+. Сразу скажу, что у этого автора больше ничего не нравится. А этот ролик как-то запал. Не знаю почему. Мне он показался очень близким к современному крупному корпоративному IT с его удалёнкой, зачастую бессмысленной рутиной и кластерами Кубернетис, которые всё внедряют и внедряют.
"Везде все одинаковые. Всё вокруг одно и то же. Одно и то же по кругу, как на стадионе."
"Я уже неделю на работу хожу и ни разу туда не пришёл!"
"Мы изобрели какой-то провод странный, зачем он нужен? 5 лет работали над ним."
К сожалению, не обладаю хорошими навыками монтажа видео. В конце так и просится переделка в стиле:
"Мы внедрили кластер Kubernetes. Зачем он нужен? 5 лет работали над ним, монолит пилили."
И потом вот это видео в продолжении:
#юмор
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍62👎4
🎓 Известный титулованный питерский институт ИТМО, который готовит ИТ специалистов, выкладывает в сеть много обучающего материала. Точнее не он, а его лекторы на неофициальных каналах. Я как минимум 2 нашёл, где выложены полноценные академические лекции для студентов. К некоторым даже конспекты есть.
В уникальное время мы живём. Все знания доступны. Бери и пользуйся. Никакой сакрализации научных знаний. Каждому доступно университетское образование, причём на всех языках мира.
Я нашёл как минимум 2 насыщенных лекциями преподавателей ИТМО youtube канала. Сразу дам ссылки на конкретные курсы лекций:
Записи курса компьютерных сетей, который читается для студентов третьего года обучения программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в шестом семестре.
Лектор: Сергей Мельников
▶️ [s6 | 2023] Компьютерные сети
✍️ Конспект лекций
Лекции Артема Береснева по курсу Компьютерные сети в университете ИТМО
▶️ Лекции по курсу Компьютерные сети
Живая, аудиторная запись. Звук не очень, но атмосферу передает.
▶️ Администрирование Windows Server
Полный курс из 15-ти лекций по администрированию GNU/Linux
▶️ Администрирование в ОС GNU/Linux
Записи лекций по курсу «Разработка на Go», который читается для студентов программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в качестве курса по выбору.
Лектор: Панасюк И.А.
▶️ [SC | 2024] Разработка на Go
Записи лекций по курсу «Операционные системы», который читается для студентов программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в третьем семестре.
Лектор: А. В. Маятин
▶️ [s3 | 2024] Операционные системы (light)
Записи лекций по курсу «Операционные системы (hard)», который читается для студентов программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в третьем семестре.
Лектор: А. В. Романовский
▶️ [s3 | 2024] Операционные системы (hard) - лекции
Записи лекций по курсу «Операционные системы (hard) — практики», который читается для студентов программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в третьем семестре.
Лектор: Никита Сычев
▶️ Операционные системы (hard) - практики
Стало интересно, что это вообще за институт. Посмотрел образовательные программы и программы обучения. Всё самое современное, типа DevOps в разработке и управлении информационными системами. Вспоминаю, как я учился в начале 2000-х и что тогда проходили в вузах. По IT вообще ничего актуального не было. Все в основном учились где и как попало, а потом сами всё изучали на работе. Я учился в МИРЭА на бюджете и потом в РосНОУ платно. Как хорошо, что я ушёл из МИРЭА. Там вообще ничего востребованного не преподавали в то время. В РосНОУ хоть что-то похожее на актуальные знания были: программирование, в том числе C++, Java, системное администрирование, операционные системы. Институт был новый, более-менее современный на тот момент.
Другое дело, что в том же ИТМО всё в основном платное. В среднем 450-550 т.р. за год. Дорого, конечно, но не запредельно, если у тебя мало детей. А если как у меня 4-ро, то денег для всех на такое обучение скорее всего не будет. Пока не знаю, как буду выкручиваться.
Мне интересно, есть примеры людей, которые не получили высшее образование, но учились по подобным лекциям в интернете? Они вообще хоть кем-нибудь изучаются или выкладываются в основном чтобы были?
#обучение
В уникальное время мы живём. Все знания доступны. Бери и пользуйся. Никакой сакрализации научных знаний. Каждому доступно университетское образование, причём на всех языках мира.
Я нашёл как минимум 2 насыщенных лекциями преподавателей ИТМО youtube канала. Сразу дам ссылки на конкретные курсы лекций:
Записи курса компьютерных сетей, который читается для студентов третьего года обучения программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в шестом семестре.
Лектор: Сергей Мельников
▶️ [s6 | 2023] Компьютерные сети
✍️ Конспект лекций
Лекции Артема Береснева по курсу Компьютерные сети в университете ИТМО
▶️ Лекции по курсу Компьютерные сети
Живая, аудиторная запись. Звук не очень, но атмосферу передает.
▶️ Администрирование Windows Server
Полный курс из 15-ти лекций по администрированию GNU/Linux
▶️ Администрирование в ОС GNU/Linux
Записи лекций по курсу «Разработка на Go», который читается для студентов программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в качестве курса по выбору.
Лектор: Панасюк И.А.
▶️ [SC | 2024] Разработка на Go
Записи лекций по курсу «Операционные системы», который читается для студентов программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в третьем семестре.
Лектор: А. В. Маятин
▶️ [s3 | 2024] Операционные системы (light)
Записи лекций по курсу «Операционные системы (hard)», который читается для студентов программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в третьем семестре.
Лектор: А. В. Романовский
▶️ [s3 | 2024] Операционные системы (hard) - лекции
Записи лекций по курсу «Операционные системы (hard) — практики», который читается для студентов программы «Прикладная математика и информатика» факультета ИТиП университета ИТМО в третьем семестре.
Лектор: Никита Сычев
▶️ Операционные системы (hard) - практики
Стало интересно, что это вообще за институт. Посмотрел образовательные программы и программы обучения. Всё самое современное, типа DevOps в разработке и управлении информационными системами. Вспоминаю, как я учился в начале 2000-х и что тогда проходили в вузах. По IT вообще ничего актуального не было. Все в основном учились где и как попало, а потом сами всё изучали на работе. Я учился в МИРЭА на бюджете и потом в РосНОУ платно. Как хорошо, что я ушёл из МИРЭА. Там вообще ничего востребованного не преподавали в то время. В РосНОУ хоть что-то похожее на актуальные знания были: программирование, в том числе C++, Java, системное администрирование, операционные системы. Институт был новый, более-менее современный на тот момент.
Другое дело, что в том же ИТМО всё в основном платное. В среднем 450-550 т.р. за год. Дорого, конечно, но не запредельно, если у тебя мало детей. А если как у меня 4-ро, то денег для всех на такое обучение скорее всего не будет. Пока не знаю, как буду выкручиваться.
Мне интересно, есть примеры людей, которые не получили высшее образование, но учились по подобным лекциям в интернете? Они вообще хоть кем-нибудь изучаются или выкладываются в основном чтобы были?
#обучение
YouTube
[s6 | 2023] Компьютерные сети, Сергей Мельников
Записи курса компьютерных сетей, который читается для студентов третьего года обучения программы «Прикладная математика и информатика» факультета ИТиП универ...
2👍136👎3
На прошлой неделе делал подборку инструментов для логирования действий пользователя в консоли. В комментариях справедливо заметили, что всё это умеет делать практически штатный инструмент - auditd. Его всегда рекомендуют включать и настраивать в контексте вопросов безопасности. Например, в руководствах CIS (#cis) о нём всегда упоминают.
Auditd я знаю, иногда настраиваю. Я о нём писал, как об инструменте для контроля за изменениями файлов. С его помощью это сделать относительно просто. Но честно скажу, не очень его люблю. Настройка неинтуитивна, логи перенасыщены информацией, чтобы просто посмотреть лог и что-то там найти, надо вспоминать команды или грепать текстовый лог.
Тем не менее, auditd это линуксовая база, так что знать его полезно. Настроим в нём логирование пользовательских команд. Auditd будет записывать не только запущенную команду, но и реально выполненную, а так же сопутствующую информацию: рабочая директория, файлы, связанные с выполнением, системный вызов, pid, uid, gid, tty и другие вещи.
Устанавливаем auditd:
Создаём правило, добавив в файл
По совету читателя добавил два правила: для пользователя root и для всех остальных. Правила идентичные, пользователя root идентифицировали через euid=0 и auid=0. Нулевые значения соответствуют root.
Применяем правила:
Теперь все команды пользователей записываются в соответствием с правилами. Смотрим команды root:
Вывалится большая портянка. Каждая команда в своём блоке, где будет указано:
◽️Дата и время выполнения
◽️PROCTITLE - выполненная команда
◽️PATH - файлы, связанные с выполнением (какие-нибудь библиотеки, сам исполняемый файл и т.д.)
◽️CWD - рабочая директория
◽️EXECVE - аргументы команды, если есть.
◽️SYSCALL - выполненный системный вызов со всеми свойствами в виде пользователя, pid, самой команды, исполняемого файла и т.д.
Как можно увидеть, информация исчерпывающая. Вроде и хорошо, что так подробно. С точки зрения безопасности полезная информация. Но быстро глянуть, кто тут что запускал, не получится. Например, если пользователь просто запустил mc, то в лог улетит не только эта команда, но и сопутствующие. Mc открывает свой bash и это тоже будет отражено в логе, также он запускает бинарники cons.saver, dircolors. Избыток подробной информации может сбивать с толку и усложнять аудит. С точки зрения безопасности это полезная информация, а с точки зрения посмотреть, кто тут что делал, не очень.
Может помочь команда, которая выведет список всех выполненных исполняемых файлов:
Также неудобно смотреть команды, запущенные через pipe. В auditd они будут отображены по отдельности.
По умолчанию auditd хранит логи в
Либо настроить пересылку логов в syslog. Для локального syslog сервера есть плагин с настройками в файле
Auditd – мощный инструмент для мониторинга событий операционной системы. Он взаимодействует напрямую с ядром, наблюдает за системными вызовами. Всё, что с ними связано, может записывать. Можно создавать отдельные правила для конкретных приложений и наблюдать за ними.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#auditd #ssh #security
Auditd я знаю, иногда настраиваю. Я о нём писал, как об инструменте для контроля за изменениями файлов. С его помощью это сделать относительно просто. Но честно скажу, не очень его люблю. Настройка неинтуитивна, логи перенасыщены информацией, чтобы просто посмотреть лог и что-то там найти, надо вспоминать команды или грепать текстовый лог.
Тем не менее, auditd это линуксовая база, так что знать его полезно. Настроим в нём логирование пользовательских команд. Auditd будет записывать не только запущенную команду, но и реально выполненную, а так же сопутствующую информацию: рабочая директория, файлы, связанные с выполнением, системный вызов, pid, uid, gid, tty и другие вещи.
Устанавливаем auditd:
# apt install auditdСоздаём правило, добавив в файл
/etc/audit/rules.d/audit.rules несколько новых строк:-a always,exit -F arch=b64 -F euid=0 -F auid=0 -S execve -S execveat -k root_auth_command_execution
-a always,exit -F arch=b32 -F euid=0 -F auid=0 -S execve -S execveat -k root_auth_command_execution
-a always,exit -F arch=b64 -F auid!=-1 -S execve -S execveat -k generic_command_execution
-a always,exit -F arch=b32 -F auid!=-1 -S execve -S execveat -k generic_command_execution
По совету читателя добавил два правила: для пользователя root и для всех остальных. Правила идентичные, пользователя root идентифицировали через euid=0 и auid=0. Нулевые значения соответствуют root.
Применяем правила:
# auditctl -R /etc/audit/rules.d/audit.rulesТеперь все команды пользователей записываются в соответствием с правилами. Смотрим команды root:
# ausearch -k root_auth_command_executionВывалится большая портянка. Каждая команда в своём блоке, где будет указано:
◽️Дата и время выполнения
◽️PROCTITLE - выполненная команда
◽️PATH - файлы, связанные с выполнением (какие-нибудь библиотеки, сам исполняемый файл и т.д.)
◽️CWD - рабочая директория
◽️EXECVE - аргументы команды, если есть.
◽️SYSCALL - выполненный системный вызов со всеми свойствами в виде пользователя, pid, самой команды, исполняемого файла и т.д.
Как можно увидеть, информация исчерпывающая. Вроде и хорошо, что так подробно. С точки зрения безопасности полезная информация. Но быстро глянуть, кто тут что запускал, не получится. Например, если пользователь просто запустил mc, то в лог улетит не только эта команда, но и сопутствующие. Mc открывает свой bash и это тоже будет отражено в логе, также он запускает бинарники cons.saver, dircolors. Избыток подробной информации может сбивать с толку и усложнять аудит. С точки зрения безопасности это полезная информация, а с точки зрения посмотреть, кто тут что делал, не очень.
Может помочь команда, которая выведет список всех выполненных исполняемых файлов:
# aureport -x -iТакже неудобно смотреть команды, запущенные через pipe. В auditd они будут отображены по отдельности.
По умолчанию auditd хранит логи в
/var/log/audit/audit.log. Читать их или грепать напрямую неудобно. Там всё сплошным потоком, без дат. Можно через ausearch или aureport выгружать их в файлы:# aureport -x -i > /var/log/audit_exec_summary.logЛибо настроить пересылку логов в syslog. Для локального syslog сервера есть плагин с настройками в файле
/etc/audit/plugins.d/syslog.conf. С локального можно на внешний пересылать.Auditd – мощный инструмент для мониторинга событий операционной системы. Он взаимодействует напрямую с ядром, наблюдает за системными вызовами. Всё, что с ними связано, может записывать. Можно создавать отдельные правила для конкретных приложений и наблюдать за ними.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#auditd #ssh #security
4👍123👎2
Когда-то давно писал про одну полезную консольную команду, которой иногда пользуюсь. Она принудительно и моментально отправляет сервер с Linux в перезагрузку. Эффект аналогичен нажатию на кнопку reset:
Разница с консольными командами reboot или shutdown как минимум в том, что они обычные бинарники на диске.
Хотя на самом деле это уже давно не бинарники, а только ссылки на
Если с диском какие-то проблемы, либо он загружен так, что ни на что не отвечает, штатный reboot не состоится, либо будет долго исполняться. К тому же reboot пытается корректно отключить примонтированные диски. Очевидно, что если с одним из них проблемы, то тоже будет всё тупить и подвисать.
В случае же с приведенной командой, если вы уже находитесь в какой-то загруженной оболочке, сервер моментально перезапустится.
Недавно, кстати, в статье видел использование команды с принудительной перезагрузкой. Там автор наживую накатил на VPS поверх работающей системы RouterOS. Соответственно, текущую файловую систему он уничтожил, никакой бинарник запустить невозможно. А само ядро ОС всё ещё живёт в памяти и работает. Вот ему и можно отправить напрямую команду на перезагрузку.
Эта команда является частью так называемых Linux Magic System Request Key Hacks (sysrq). Магические сочетания клавиш, которые отправляют команды напрямую в ядро. Они реально привязаны к сочетаниям клавиш, выполняемых с управляющего терминала и подключенной клавиатуры. ALT + SysRq + <command key>. Клавиша SysRq часто совмещена с PrtSc. Уже не помню, когда последний раз сидел за экраном реального сервера, если это не мои домашние тестовые компы. Обычно везде хоть какой-то IPMI есть.
Ядро должно поддерживать эти команды. Обычно в популярных дистрибутивах это так:
◽️ 0 - sysrq отключен
◽️ 1 - sysrq полностью включен
◽️ >1 - включены отдельные функции
На Debian или Centos, с которыми я больше всего работал, перезагрузка всегда срабатывала.
Команд, которые можно отправить ядру, довольно много. Я лично использую только b для перезагрузки. Остальные не помню и никогда не использовал. А про reboot помню. Видел рекомендации, что перед перезагрузкой попробовать какие-то другие команды, типа тех, что отмонтируют диски, завершат процессы и т.д. Обычно если ты жёстко ресетишь сервер, то пробовать что-то не имеет большого смысла, потому что уже висим.
Если всё же интересно, то весь список команд можно запросить у ядра:
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal
# echo b > /proc/sysrq-triggerРазница с консольными командами reboot или shutdown как минимум в том, что они обычные бинарники на диске.
# type rebootreboot is /usr/sbin/reboot# type shutdownshutdown is /usr/sbin/shutdownХотя на самом деле это уже давно не бинарники, а только ссылки на
/bin/systemctl, но это не отменяет того, что последний тем не менее исполняемый файл. Он должен существовать, а во время выполнения пошуршать диском. У него куча ссылок на таргеты и службы systemd. Если с диском какие-то проблемы, либо он загружен так, что ни на что не отвечает, штатный reboot не состоится, либо будет долго исполняться. К тому же reboot пытается корректно отключить примонтированные диски. Очевидно, что если с одним из них проблемы, то тоже будет всё тупить и подвисать.
В случае же с приведенной командой, если вы уже находитесь в какой-то загруженной оболочке, сервер моментально перезапустится.
Недавно, кстати, в статье видел использование команды с принудительной перезагрузкой. Там автор наживую накатил на VPS поверх работающей системы RouterOS. Соответственно, текущую файловую систему он уничтожил, никакой бинарник запустить невозможно. А само ядро ОС всё ещё живёт в памяти и работает. Вот ему и можно отправить напрямую команду на перезагрузку.
Эта команда является частью так называемых Linux Magic System Request Key Hacks (sysrq). Магические сочетания клавиш, которые отправляют команды напрямую в ядро. Они реально привязаны к сочетаниям клавиш, выполняемых с управляющего терминала и подключенной клавиатуры. ALT + SysRq + <command key>. Клавиша SysRq часто совмещена с PrtSc. Уже не помню, когда последний раз сидел за экраном реального сервера, если это не мои домашние тестовые компы. Обычно везде хоть какой-то IPMI есть.
Ядро должно поддерживать эти команды. Обычно в популярных дистрибутивах это так:
# cat /proc/sys/kernel/sysrq◽️ 0 - sysrq отключен
◽️ 1 - sysrq полностью включен
◽️ >1 - включены отдельные функции
На Debian или Centos, с которыми я больше всего работал, перезагрузка всегда срабатывала.
Команд, которые можно отправить ядру, довольно много. Я лично использую только b для перезагрузки. Остальные не помню и никогда не использовал. А про reboot помню. Видел рекомендации, что перед перезагрузкой попробовать какие-то другие команды, типа тех, что отмонтируют диски, завершат процессы и т.д. Обычно если ты жёстко ресетишь сервер, то пробовать что-то не имеет большого смысла, потому что уже висим.
Если всё же интересно, то весь список команд можно запросить у ядра:
# echo h > /proc/sysrq-trigger | less /var/log/kern.log❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#linux #terminal
👍268👎2
❗️Важная информация для тех, кто числится системным администратором и оформлен по этой специальности. А также для тех, кто оказывает услуги по ремонту и настройке компьютеров и серверов. Наши законотворцы не перестают удивлять и подготовили очередные нововведения. Они вроде бы и не про нас, но по касательной задевает. Новость не новая, но я только на днях увидел и слегка напрягся. Только недавно всех блогеров в реестр загнали, а тут и за технарей взялись.
Правительство России готовится утвердить проект реформирования интернет-отрасли. В обозримом будущем будет создано государственное полукоммерческое учреждение «МУП Интернет», в которое войдут все провайдеры сети Интернет, дата-центры, хостинги, регистраторы доменов, мессенджеры, серверы электронной почты, производители телекоммуникационного оборудования, системные администраторы а также частные предприниматели, оказывающие услуги по ремонту компьютеров.
.........................................................
Новая организация будет контролировать все TCP и UDP пакеты в стране, отвечать за их целостность, а также их соответствие критериям, установленным госбезопасностью. Ей поручат организовать досмотр всех исходящих и входящих пакетов как автоматизированными средствами, так и операторами ЭВМ вручную. Системных администраторов и прочих технических специалистов смежных специальностей внесут в соответствующий реестр для привлечения к анализу внештатных всплесков сетевого трафика на магистральных каналах связи. Выезд заграницу таким специалистам будет ограничен.
⇨ Подробности по ссылке
#разное
Правительство России готовится утвердить проект реформирования интернет-отрасли. В обозримом будущем будет создано государственное полукоммерческое учреждение «МУП Интернет», в которое войдут все провайдеры сети Интернет, дата-центры, хостинги, регистраторы доменов, мессенджеры, серверы электронной почты, производители телекоммуникационного оборудования, системные администраторы а также частные предприниматели, оказывающие услуги по ремонту компьютеров.
.........................................................
Новая организация будет контролировать все TCP и UDP пакеты в стране, отвечать за их целостность, а также их соответствие критериям, установленным госбезопасностью. Ей поручат организовать досмотр всех исходящих и входящих пакетов как автоматизированными средствами, так и операторами ЭВМ вручную. Системных администраторов и прочих технических специалистов смежных специальностей внесут в соответствующий реестр для привлечения к анализу внештатных всплесков сетевого трафика на магистральных каналах связи. Выезд заграницу таким специалистам будет ограничен.
⇨ Подробности по ссылке
#разное
ИА Панорама
В России будет создано ФОУ АГО ГУП «МУП Интернет»
Организация будет отвечать за все TCP- и UDP-пакеты в рунете.
7👍190👎27
🔝 ТОП постов за прошедший месяц. Все самые популярные публикации по месяцам можно почитать со соответствующему хэштэгу #топ. Отдельно можно посмотреть ТОП за прошлые года: 2023 и 2024.
Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://www.tg-me.com/boost/srv_admin.
📌 Больше всего пересылок:
◽️Записи лекций института ИТМО (513)
◽️Сервис newreleases.io для отслеживания обновлений ПО (399)
◽️Подборка бесплатных почтовых серверов (399)
📌 Больше всего комментариев:
◽️Выбор рабочего ноутбука (1095 😱)
◽️Мысли на тему своего почтового сервера (240)
◽️Рассуждения на тему Docker (173)
📌 Больше всего реакций:
◽️Работа со службами в systemd (219)
◽️Настройка протокола HTTPv3 в веб сервере (173)
◽️Подборка бесплатных почтовых серверов (172)
📌 Больше всего просмотров:
◽️Управление WireGuard в консоли через wg-cmd (10532)
◽️Сервис newreleases.io для отслеживания обновлений ПО (9804)
◽️Очередная подборка авторских IT роликов (9314)
#топ
Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://www.tg-me.com/boost/srv_admin.
📌 Больше всего пересылок:
◽️Записи лекций института ИТМО (513)
◽️Сервис newreleases.io для отслеживания обновлений ПО (399)
◽️Подборка бесплатных почтовых серверов (399)
📌 Больше всего комментариев:
◽️Выбор рабочего ноутбука (1095 😱)
◽️Мысли на тему своего почтового сервера (240)
◽️Рассуждения на тему Docker (173)
📌 Больше всего реакций:
◽️Работа со службами в systemd (219)
◽️Настройка протокола HTTPv3 в веб сервере (173)
◽️Подборка бесплатных почтовых серверов (172)
📌 Больше всего просмотров:
◽️Управление WireGuard в консоли через wg-cmd (10532)
◽️Сервис newreleases.io для отслеживания обновлений ПО (9804)
◽️Очередная подборка авторских IT роликов (9314)
#топ
Telegram
ServerAdmin.ru
🎄🔝 Под конец года имеет смысл подвести некоторые итоги. В повседневной жизни я не привык это делать. Обычно только доходы/расходы анализирую. А вот в разрезе канала было интересно посмотреть итоги.
Я подготовил ТОП публикаций за прошедший год. Это было…
Я подготовил ТОП публикаций за прошедший год. Это было…
👍22👎2