ServerAdmin.ru
26.7K subscribers
208 photos
24 videos
8 files
2.5K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru
Download Telegram
​​Любопытный проект на github для совместной работы в консоли - TermPair.

https://github.com/cs01/termpair

Идея такая. Ты запускаешь у себя в консоли сервер:
termpair serve --port 8000

Дальше можно расшарить консоль:
termpair share --port 8000

Вы получите ссылку вида:
http://ip-server:8000/?terminal_id=fd96c0f8476872950e19c

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

Можно расшарить консоль и через внешний хост. Для этого надо будет воспользоваться каким-то внешним сервером. Например, вот так:
termpair share --host "https://chadsmith.dev/termpair/" --port 443

Сразу получите внешнюю ссылку и через браузер окажетесь в консоли.

Программа написана на python, так что поставить можно через pip:
pip install termpair

Перед установкой обновите pip до последней версии. У меня сначала не прошла установка из-за каких-то проблем с криптографией. Когда обновил pip, все прошло успешно.

Гифка с демонстрацией работы - https://raw.githubusercontent.com/cs01/termpair/master/termpair_browser.gif

#утилита
​​Есть в линуксе полезный архиватор - pigz (Parallel Implementation of GZip). На мой взгляд, он не очень известный. Редко его вижу где-то в статьях или чьих то скриптах. Сам я его использую постоянно. Главная его особенность - он жмёт всеми ядрами. Большинство привычных консольных архиваторов жмут только одним ядром. Когда архивируете большие объемы, разница в скорости огромная.

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

Одиночный файл:
pigz -c filename > /tmp/filename.gz
Распаковываем:
unpigz filename.gz

Либо сразу дамп базы:
pg_dump -U postgres base | pigz > /tmp/base.sql.gz

Жмём директорию:
tar cf - directory | pigz - > directory.tar.gz
Распаковываем:
cat directory.tar.gz | unpigz - | tar xf -

Жмём несколько файлов по маске:
find /data -type f -name *filemask* -exec pigz -c '{}' \;
Распаковываем:
find /data -type f -name *filemask.gz -exec unpigz '{}' \;

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

#утилита
​​Очень удобная и простая утилита наподобие top, только для пропускной способности сети - nethogs.

dnf install nethogs (живёт в epel)
apt install nethogs

После запуска в командной строке вы увидите pid процесса, его название, сетевой интерфейс и пропускную способность сети, которую в данный момент занимает конкретный процесс.

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

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

#утилита #сеть
​​Просматривал вчера в консоли большие дампы mysql с помощью утилиты less и подумал, что неплохо было бы о ней рассказать. Я её чаще всего использую, чтобы быстро посмотреть начало или конец какого-то объемного файла с текстовой информацией. Если файл небольшой (до 100 мб), то сразу открываю в mcedit или vi и смотрю там.

А вот если у вас дамп на пару гигов, к примеру, и хочется посмотреть, он вообще корректно завершился, то less очень подходит. Открываете файл, дальше жмёте shift + G и оказываетесь сразу в самом конце файла. Альтернативным способом можно сделать так:
tail -n 10 20210707_12-35_vdakernel.sql
Но с less быстрее и удобнее, как по мне.

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

Горячие клавиши:
Стрелка вверх – перемещение на одну строку вверх
Стрелка вниз – перемещение на одну строку вниз
Пробел или PgDn – перемещение на одну страницу вниз
b или PgUp – переместить на одну страницу вверх
g – переместить в начало файла
G – переместить в конец файла
ng – перейти на n-ю строку

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

#bash #утилита
​​Я тут затестил на удивление удобную утилиту. Даже не знаю, как её обозвать. Это такой top с кучей информации не только по процессам. Речь идёт про glances.

https://github.com/nicolargo/glances

Не слышал о ней раньше, хотя на вид мне сразу показалась удобной и живет в стандартных репах. Для Centos и форков в репозитории epel. Установить можно как оттуда, так и через pip.

# dnf install epel-release
# dnf install python python-devel
# dnf install glances

Утилита написана под все современные linux системы и даже freebsd. Для нее существует куча расширений для увеличения метрик, и не только. Можно поставить веб интерфейс, чтобы через него смотреть за метриками, либо модуль для экспорта метрик в формате prometheus или elasticsearch. Через pip это ставится примерно так:

pip install 'glances[browser,docker,export]'

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

#terminal #утилита
​​Знакомлю вас с утилитой командной строки, которая мне очень понравилась. Речь пойдёт про bat, аналоге cat, только с подсветкой синтаксиса и не только. Лично я утилиту cat использую постоянно. Сформировалась привычка при поиске чего-то делать сначала cat, потом grep. Например:
# cat /var/log/messages | grep kernel

По идее, логичнее и проще сделать так:
# egrep "kernel" /var/log/messages

Но я привык к первому варианту и cat использую постоянно. И при грепанье, и просто при просмотре чего-то в консоли. Перед тем, как что-то скопировать из файла, вывожу через cat в консоль.

Bat очень классно подсвечивает вывод в консоли. Нет смысла рассказывать, на картинке к посту все и так видно:
# bat /etc/hosts

Репозиторий утилиты - https://github.com/sharkdp/bat. В Debian/Ubuntu bat ставится из стандартных реп:
# apt install bat
# ln -s /usr/bin/batcat /usr/bin/bat

В Centos 8 (на 7 не заработает из-за устаревших пакетов) и форках придется бинарник качать:
# wget https://github.com/sharkdp/bat/releases/download/v0.18.2/bat-v0.18.2-x86_64-unknown-linux-gnu.tar.gz
# tar xzvf bat-v0.18.2-x86_64-unknown-linux-gnu.tar.gz
# cd bat-v0.18.2-x86_64-unknown-linux-gnu
# cp bat /usr/bin/

Жаль, что подобного рода утилиты либо вообще не доедут до состава стандартного дистрибутива, либо появятся там лет через 20, когда оттуда наконец-то выпилят vi и им подобное. Так что использовать получится только на своих серверах, которых обычно не много.

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

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

Через некоторое время на этот же ip адрес может приехать что-то другое. Например, у меня приехал новый сервер и на этот ip был посажен idrac. Каково же было мое удивление, когда я, сканируя внешний ip, увидел доступ к консоли управления сервером. Сначала перепугался, думал кто-то что-то сломал. Полез разбираться, оказалось, что старый проброс 443 порта остался на этом внешнем ip.

Можете настроить что-то простое и банальное, типа подобной проверки и засунуть её в крон:

nmap -T4 87.250.250.242 | mail -s "Nmap Scan 87.250.250.242" serveradmin@gmail.com

Раз в неделю будете получать отчёты на почту по проверке своих IP. И более детальную и подробную проверку сделать. Например, так:

nmap -T0 -A -v 87.250.250.242 | mail -s "Nmap Scan 87.250.250.242" serveradmin@gmail.com

Полный список параметров можно посмотреть в документации - https://nmap.org/man/ru/man-briefoptions.html

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

Сканирование подсети или отдельных адресов:
nmap 192.168.1.0/24 или nmap 192.168.1.*
nmap 192.168.1.1,2,3

Быстрый скан сети пингом. Позволяет сразу увидеть, какие хосты в сети запущены и отвечают на пинг.
nmap -sP 192.168.1.0/24

Скан хоста, не отвечающего на пинг. Актуально, если открытые порты есть, но хост не отвечает на icmp запросы.
nmap -Pn 192.168.1.1

Быстрое сканирование. Если не добавить ключи, увеличивающие скорость, дефолтный скан будет длиться очень долго.
nmap -F 192.168.1.1
nmap -T4 192.168.1.1

Подробный скан всех портов хоста. Небольшой скрипт nmap.sh, который по очереди подробно сканирует все открытые порты. Процесс может длиться долго.
#!/bin/bash
ports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)
nmap -p$ports -A $1

Использовать
./nmap.sh 192.168.1.1

Как обычно, не забываем забрать в закладки.

#terminal #утилита #nmap
​​Существует программа для тестирования производительности сервера - sysbench. Она умеет всякими разными способами нагружать систему, но мне обычно это не надо. Да и в целом софта для теста процессора, памяти, дисков существует много. Гораздо полезнее другая ее возможность - тестирование производительности Mysql или Postgresql сервера.

Программа бесплатная, живет на github. Можно самому собирать, можно поставить из репозитория. Есть под все популярные системы. Быстро добавить репу можно через скрипт. Содержимое небольшое, можно проверить перед установкой:

# curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash
# yum install sysbench

Список доступных тестов можно посмотреть в директории /usr/share/sysbench/. Перед началом тестов, надо создать тестовую базу:
> create database sbtest;

Я буду подключаться локально, авторизация через root уже настроена. Наполняем тестовую базу данными. Будут 16 таблиц по 10000 строк в каждой.
# sysbench \
--db-driver=mysql \
--mysql-user=root \
--mysql-db=sbtest \
--mysql-host=127.0.0.1 \
--mysql-port=3306 \
--tables=16 \
--table-size=10000 \
/usr/share/sysbench/oltp_read_write.lua prepare

Смотрим, что получилось:
# du -sh /var/lib/mysql/sbtest/
161M /var/lib/mysql/sbtest/

После этого запускаем сам тест oltp_read_write на 10 секунд:
# sysbench \
--db-driver=mysql \
--mysql-user=root \
--mysql-db=sbtest \
--mysql-host=127.0.0.1 \
--mysql-port=3306 \
--tables=16 \
--table-size=10000 \
--threads=4 \
--time=10 \
--events=0 \
--report-interval=1 \
/usr/share/sysbench/oltp_read_write.lua run

На выходе получите количество транзакций в секунду и некоторые другие данные. Настроек и возможностей у sysbench много, в рамках заметки это всё не рассказать. Надеюсь, показал главное - этой утилитой достаточно легко пользоваться. Не надо долго разбираться. Можно быстро оценить производительность, сравнить разные виртуальные машины или конфигурации mysql / postgresql.

#terminal #утилита
​​Вы знали, что в rpm-based дистрибутивах есть утилита, которая определяет, нужна серверу в данный момент перезагрузка или нет? Она живет в базовом репозитории (baseos) и называется needs-restarting. Входит в состав пакета yum-utils.

# yum install yum-utils

Проверяем, нужна ли перезагрузка:

# needs-restarting -r
No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

После установки обновлений вывод меняется:

# needs-restarting -r
Core libraries or services have been updated:
 kernel -> 3.10.0-1160.42.2.el7

Reboot is required to ensure that your system benefits from these updates.

More information:
https://access.redhat.com/solutions/27943

Debian и Ubuntu эту информацию выдают обычно в приветствии после ssh подключения. Не знаю, на основе чего там реализован этот функционал, не разбирался.

#terminal #утилита
​​В репозиториях популярных дистрибутивов живёт небольшая утилита exa, которая делает всё то же самое, что и ls, только красиво окрашивает вывод. В Debian/Ubuntu она в unstable репе. В rpm-based дистрах в федореном репозитории.

https://github.com/ogham/exa
https://the.exa.website/

Утилита состоит из одного бинарника, так что можно просто скачать и запустить. Есть поддержка git, так что можно увидеть статус (modified, Untracked) каждого файла.

Exa умеет делать древовидное отображение каталогов и файлов с возможностью ограничивать глубину. Например:

# exa --tree --level=2 /boot

Удобная и функциональная утилита. Можно просто заменить ls символьной ссылкой и пользоваться только exa. Работает так же быстро.

#terminal #утилита
​​Одна из программ командной строки Linux, которую часто приходится использовать - find. При этом у неё не очень простой синтаксис. Я лично постоянно его забываю, поэтому всегда использую шпаргалку с наиболее часто используемыми конструкциями.

Существует утилита fd (https://github.com/sharkdp/fd), которая упрощает использование поиска через консоль. Она есть под все популярные системы, даже windows. В репе перечислены все способы установки, а также ссылки на готовые пакеты. Бинарник после установки будет называться fdfind, так как в некоторых системах имя fd уже занято. Чтобы использовать короткое обозначение придётся либо алиас, либо символьную ссылку сделать.

Основные особенности утилиты:
интуитивный синтаксис и дефолтные значения
быстрый параллельный поиск
возможность выполнить внешнюю команду не с каждым результатом поиска, а отправить весь результат, как аргумент (это может существенно ускорить удаление огромного кол-ва файлов, но это не точно 😁)
расцветка вывода

Примеры использования.
Поиск файла в текущей директории:
fdfind file
Поиск файла в конкретной директории. По умолчанию он будет рекурсивный. Для поиска по всему серверу можно использовать корень.
fdfind file /var
fdfind file /
Поиск файлов с определённым расширением:
fdfind -e php
Найти все архивы и распаковать их:
fdfind -e zip -x unzip
Найти файлы и удалить одной командой:
fdfind -e log -X rm

Еще больше примеров разобраны в описании репозитория. Для простого поиска этой утилитой реально удобнее пользоваться, чем стандартным find. Более сложные конструкции я не тестировал. Они обычно в скриптах используются, а там уже не критично, где один раз собрать команду.

#terminal #утилита
​​Существует крутой консольный просмотрщик логов Lnav. Он умеет объединять логи из разных источников, подсвечивать их, распаковывать из архивов, фильтровать по регуляркам и многое другое. При этом пользоваться им достаточно просто. Не надо изучать и вникать в работу. Всё интуитивно и максимально просто.

Lnav это просто одиночный бинарник, который можно загрузить из github - https://github.com/tstack/lnav/releases.

# wget https://github.com/tstack/lnav/releases/download/v0.10.0/lnav-0.10.0-musl-64bit.zip
# unzip lnav-0.10.0-musl-64bit.zip
# mv lnav-0.10.0/lnav /usr/local/bin

Теперь, к примеру, можно разом посмотреть все логи /var/log/messages, в том числе и сжатые, ротированные файлы:

# lnav /var/log/messages*

Можно неудобочитаемый вывод journalctl направить в lnav:

# journalctl | lnav

При просмотре логов автоматически работает всторенная навигация на перемещение к ошибкам по горячей клавише e (error) или предупреждениям по клавише w (warning). Новые строки логов автоматически отображаются, то есть lnav можно использовать вместо tail -f.

Для корректной работы lnav нужен 256 цветный терминал. Если у вас используется обычный term, то надо добавить в ~/.bashrc и перезайти:

export TERM=xterm-256color

Сайт программы - https://lnav.org На нём описаны все возможности этой утилиты.

#утилита #terminal
​​Существует любопытная консольная утилита для пинга хостов - gping. Казалось бы, что тут можно придумать. Утилита ping есть почти во всех системах и работает примерно одинаково. Что еще можно ожидать от обычного пинга?

Авторы gping сумели наполнить обычный ping новым функционалом. Утилита умеет:
Строить график времени отклика хоста
Одновременно пинговать и строить график для нескольких хостов

Последнее особенно полезно, когда надо понять, это у тебя проблемы с сетью или у какого-то удаленного хоста. Можно для теста пингануть несколько разных серверов и проверить.

Утилиты нет в стандартных репозиториях систем, но можно найти в сторонних.
# dnf copr enable atim/gping
# dnf install gping

# echo "deb http://packages.azlux.fr/debian/ buster main" | sudo tee /etc/apt/sources.list.d/azlux.list
# wget -qO - https://azlux.fr/repo.gpg.key | sudo apt-key add -
# apt update && apt install gping

Gping есть и под Windows. Поставить можно через choco:
# choco install gping
Или просто скачать бинарник.

Github - https://github.com/orf/gping

#terminal #утилита
​​Простая и современная утилита для шифрования данных - age. Написана в духе Unix-style. Никаких конфигов. Всё управление ключами. Для шифрования используется связка приватного и публичного ключа.

Отлично подходит для автоматизации, юниксовых пайпов и скриптов. В стандартных репах ubuntu / centos я ее не нашел, так что ставить придётся с гитхаба. Утилита представляет из себя два бинарника - непосредственно шифровальщик и keygen для паролей.

Установка:
# wget https://github.com/FiloSottile/age/releases/download/v1.0.0/age-v1.0.0-linux-amd64.tar.gz
# tar xzvf age-v1.0.0-linux-amd64.tar.gz
# mv age/* /usr/local/bin

Использование. Сформируем ключи:
# age-keygen -o key.txt
Шифруем обычный файл с использованием публичного ключа:
# echo "Actually Good Encryption" > file.txt
# age -r age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p file.txt > file.txt.age

Убеждаемся, что файл зашифрован и затем расшифровываем его закрытым ключом:
# cat file.txt.age
# age -d -i key.txt file.txt.age > file_decrypted.txt
# cat file_decrypted.txt

Если используете ключи для подключения по ssh, то age может использовать их точно так же, как и свои. Никакой разницы не будет.

github - https://github.com/FiloSottile/age

#terminal #утилита
​​Иногда бывает нужно замерить время выполнения какой-то команды. Есть специальная утилита, в которой это сделать очень удобно - Hyperfine. Это более продвинутый аналог time. Если запустить её без дополнительных параметров, то по умолчанию она не менее 10 раз выполнит заданную команду и выведет среднее время выполнения.

Проще всего проверить работу программы на команде sleep:
# hyperfine 'sleep 0.5'
Benchmark 1: sleep 0.5
 Time (mean ± σ):   501.3 ms ±  0.2 ms  [User: 1.2 ms, System: 0.1 ms]
 Range (min … max):  501.0 ms … 501.8 ms  10 runs

Где это может пригодиться кому-то из вас, не знаю. Первое, что приходит на ум, в мониторинге. Например, я иногда делаю item в Zabbix для мониторинга за локальным nginx следующего типа. Через curl дергал http://localhost/nginx-status и замерял время отклика. Ставил триггер на отклонение от среднего значения.

Для этих целей удобно использовать hyperfine, так как он умеет экспортировать результат в json. В том же Zabbix можно сразу же распарсить его в постобработке через jsonpath и записать результат. Если по нескольку раз дергать какой-то url и замерять через hyperfine, то точность мониторинга будет выше, чем есть в стандартном функционале.

# hyperfine 'curl http://127.0.0.1:80' --export-json ~/curl.json

На выходе получите сразу же min, max, медианное время выполнения запроса. Если любопытно, можете просто сравнить отклик сайта по http и https.

# hyperfine 'curl http://127.0.0.1' 'curl https://127.0.0.1'

В общем, утилита интересная, может пригодиться в хозяйстве. Есть deb пакет, всё остальное из репозитория можно взять. Это просто бинарник.

# wget https://github.com/sharkdp/hyperfine/releases/download/v1.12.0/hyperfine_1.12.0_amd64.deb
# dpkg -i hyperfine_1.12.0_amd64.deb

Исходники - https://github.com/sharkdp/hyperfine

#terminal #утилита
​​Команда, которую часто приходится использовать в Linux - ps. Но не просто ps, а с ключами:
# ps ax или ps aux
Она выводит список всех процессов. Чаще всего этот список приходится грепать, чтобы получить подробную информацию о конкретном процессе.
# ps ax | grep mysql

Есть утилита procs, которая расширяет функционал ps. Она имеет более удобный для восприятия вывод и некоторые другие возможности. Например, добавляет информацию о занимаемых TCP/UDP портах. В ней можно использовать поиск, делать древовидный вывод и многое другое.

Procs есть под Linux, Macos и даже Windows. Есть готовый rpm пакет:
# rpm -i https://github.com/dalance/procs/releases/download/v0.11.10/procs-0.11.10-1.x86_64.rpm

В Ubuntu можно из snap поставить:
# snap install procs

Под винду экзешник из репозитория надо скачать. Я попробовал, реально работает на Win10. Единственное, что я не понял, так это почему у меня не отображались используемые процессом порты. Ни в centos, ни в windows. Всё описание и все ключи запуска изучил, но так и не понял, как вывести эту информацию. На скринах из репозитория она есть.

У меня как-то появилась идея получать список запущенных процессов в системе после того, как в Zabbix сработает триггер на нагрузку CPU. Так можно сразу понять, кто нагрузил систему. В Linux я без проблем это реализовал с помощью ps. Подробно описал в статье. Если нужно будет сделать то же самое в Windows, то можно взять для этого утилиту procs.

Исходники - https://github.com/dalance/procs

#утилита #terminal
​​Буквально на днях вышла в свет очень простая утилита на Go - dstp. Вот, что она делает:
Показывает пинг сайта
Resolve ip адреса локальным dns и ns сервером домена
Срок действия TLS сертификата
HTTP код ответа

Утилита собрана под все популярные системы в виде готового бинарника. Вывод может быть в тектсовом виде, либо в json. Авторы в репозитории пишут, что кто-то очень просил подобную утилиту и они сделали.

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

Исходники - https://github.com/ycd/dstp

#утилита