Обложка канала

ServerAdmin.ru. Страница 23

12437 @srv_admin

Авторская информация о системном администрировании.

  • ServerAdmin.ru

    ❓ Ко мне поступил вопрос, ответ на который я знаю. Более того, он реализован в виде статьи, по которой можно решить похожие задачи по аналогии. Я не буду копировать вопрос слово в слово, сокращу, оставив суть. Zabbix мониторит инфраструктуру, метрики собираются, триггеры работают. Но хочется получать больше фактической информации в момент срабатывания триггера. Например, при срабатывании триггера на нехватку места на диске, сразу же пройтись по серверу командой: find -type f -exec du -Sh {} + | sort -rh | head -n 10 И результат отправить в уведомление или где-то сохранить для просмотра. Желание понятное. Я сам одно время задумался над такой же задачей и реализовал её в лоб. Мне захотелось, чтобы вместе с оповещением триггера о том, что высокая нагрузка на CPU, мне сразу же прилетела информация о топ 10 самых нагруженных процессов. У Zabbix нет готовых инструментов для реализации такой задачи. Я реализовал следующим образом: 1️⃣ Добавляю в стандартный шаблон новый айтем типа Zabbix Trapper. 2️⃣ Разрешаю на zabbix agent запуск внешних команд. 3️⃣ Настраиваю на Zabbix Server действие при срабатывании одного из нужных мне триггеров. В действии указываю выполнение команды на целевом сервере, которая сформирует список процессов и отправит его на сервер мониторинга с помощью zabbix-sender. В моём случае я отправлял результат работы команды: # ps aux --sort=-pcpu,+pmem | awk 'NR<=10' По аналогии решается любая похожая задача. Подробности рассказывать здесь не буду, так как всё это наглядно по шагам описано в статье: ⇨ serveradmin.ru/monitor…v-zabbix #вопрос_читателя #zabbix
    Мониторинг списка запущенных процессов в Zabbix | serveradmin.ru

    Получение информации о топ 10 нагруженных процессов в Linux в момент срабатывания триггера в Zabbix на нагрузку CPU.

    Server Admin
  • ServerAdmin.ru

    Старый мем из комментариев к одной статье на сайте. Я его публиковал уже пару лет назад, когда тут читателей раз в 5 меньше было. Читать диалог снизу вверх. Как обычно, мемы в комментариях приветствуются. Я все просмотрел к прошлому посту. #мем
  • ServerAdmin.ru

    ​​Открытые практикумы DevOps, Linux, Networks и Golang by Rebrain: расписание на Февраль 2023 Успевайте зарегистрироваться. Количество мест строго ограничено! Запись практикума "DevOps by Rebrain" в подарок за регистрацию! 👉 Регистрация 🗓 7 февраля DevOps: Сквозное логирование с использованием транзакционных логов (Александр Крылов - Lead DevOps В ПАО СК Росгосстрах) 🗓 8 февраля Linux: Базовые команды - 2 (Андрей Буранов - Специалист по UNIX-системам в компании VK) 🗓 9 февраля Networks: Multicast, часть 3 (Дмитрий Радчук - Team Lead Вконтакте) 🗓 13 февраля TeamLead: Документирование по Agile (Павел Фискович - Инженер) 🗓 14 февраля DevOps: Анализ скорости загрузки сайтов (Николай Лавинский - Технический директор в ООО “Метод Лаб”) 🗓 15 февраля Linux: LVM - 2 (Андрей Буранов - Специалист по UNIX-системам в компании VK) 🗓 16 февраля Golang: Организация асинхронных приложений (Дмитрий Гордеев - Руководитель практикума Golang by REBRAIN) 🗓 16 февраля Networks: Мониторинг и управление устройствами по протоколу SNMP (Ольга Яновская - Руководитель направления Networks by Rebrain, разработчик в Pyzzle.ISP) 🗓 20 февраля TeamLead: Как тимлиду уйти в отпуск и продолжить эффективно управлять командой (Максим Ульянов - Руководитель отдела клиентской разработки в RUTUBE)  🗓 21 февраля DevOps: Ansible 101 (Павел Фискович - Инженер) 🗓 22 февраля Linux: Пакеты RPM и DEB (Даниил Батурин - Основатель проекта VyOS)  🗓 27 февраля TeamLead: Оптимизируем время команды (Александр Крылов - Lead DevOps В ПАО СК Росгосстрах) 🗓 28 февраля DevOps: Основной алгоритм траблшутинга (Василий Озеров - Co-Founder REBRAIN/Fevlake)  Посмотреть программу практикумов и записаться бесплатно  Открытые еженедельные DevOps практикумы - Присоединяйтесь! #реклама
  • Реклама

  • ServerAdmin.ru

    Делюсь с вами историей из практики, которая случилась на днях. Она вышла типовой и показательной, поэтому рассказываю. Поясню, что я участвовал в рамках платной консультации и настройками не занимался. Только предлагал разные варианты на основе своего опыта. Ко мне обратился владелец сервиса со средней нагрузкой примерно в 600 rps (запросов в секунду). Использовался типовой стек на базе Nginx, Php-fpm, MySQL и некоторых вспомогательных сервисов. Все запросы клиентов стекались в один php скрипт. Частично был настроен мониторинг на базе Prometheus и Grafana, но сделан был для галочки и большая часть нужных метрик там отсутствовала (по nginx и php-fpm ничего не было). MySQL сервер был отдельной VPS, запросы к нему шли через ProxySQL. Проблема была на первый взгляд простая. Часть клиентов получали 502 ошибку, которая в nginx выглядела вот так: connect() to unix:/run/php-fpm/www.sock failed (11: Resource temporarily unavailable) while connecting to upstream Обычно это следствие нехватки php-fpm воркеров. Если ресурсы сервера позволяют, то надо увеличить их количество. Ресурсов было много. Из 16 ядер и 32 Гб памяти занято было от силы 3-4 ядра и 3-4 Гб памяти. При этом в php-fpm был настроен статичный запуск воркеров, а их кол-во всего 32, что по моим представлениям очень мало для подобной задачи и сервера. Дальше началось самое интересное. Увеличение числа воркеров не приводило к исчезновению ошибки об их нехватке в nginx. Более того, чем больше добавляешь воркеров, тем больше 502 ошибок у пользователей и тем меньше 200 ответов. После того, как поиграли с числом воркеров php-fpm, я понял, что узкое место не со стороны веб сервера, но так как мониторинга не было, не понятно, куда смотреть. На всякий случай проверили лимиты операционной системы на подключения к unix сокетам, сетевым подключениям, файловым дескрипторам. Проблем не было. Потом таймауты nginx и fastcgi. На первый взгляд тоже всё в порядке. Настроили быстро мониторинг php-fpm и через консоль вручную смотрели метрики, но ничего полезного там не увидели. Для эксперимента я предложил сменить режим работы php-fpm с unix сокета на tcp и добавить много воркеров, штук 100-200, можно было бы и 500, сервер тянул. Ошибка в Nginx изменилась, но суть осталась прежней. Там просто по таймауту отваливались подключения к воркерам. Увеличение количества воркеров не решало проблему. На этом этапе я уже окончательно убедился, что проблема не с веб сервером. У меня были две идеи: либо не тянет БД, либо в php скрипте какой-то замкнутый цикл, который с ростом числа воркеров просто плодит паразитную нагрузку, а запросы клиентов так и остаются с ошибками. Для БД был какой-то мониторинг, но он толком ничего не показывал. Были метрики числа и времени выполнения запросов, число столбцов, участвовавших в них и что-то ещё. Эти метрики показывали ровные линии, без всплесков и провалов. Каких-то базовых метрик на тему производительности не было, поэтому трудно было оценить, что там вообще происходит. По htop повышенная нагрузка не просматривалась. В завершении я предположил, что в ProxySQL стоит ограничение на входящие запросы, поэтому сверх лимита они все отбрасываются, либо висят в очереди, поэтому нагрузка на MySQL ровная. На всякий случай ещё проверил количество TCP подключений к серверу, нет ли там узкого места. Его не было, коннектов не сказать, что сильно много и ни в какие лимиты они не упирались. На этом распрощались. Потом заказчик добавил ещё один веб сервер и часть запросов отправил туда, но это не помогло. Проблема решилась просто — увеличили в 2 раза ресурсы MySQL сервера и всё поехало, как надо. 💡Написал я всё это к чему. Всегда надо делать хороший мониторинг. Без него решать подобные задачи трудно, уходит много времени, результат непредсказуем. Настройка мониторинга заняла бы меньше времени, чем в итоге решение всего лишь одной проблемы. Весь софт, который участвует в работе системы, должен мониториться, и не для галочки, а нужными метриками. #мониторинг
  • ServerAdmin.ru

    ​​Предлагаю вашему вниманию необычный мониторинг от китайских программистов. Сразу уточню, что поддержка английского языка там есть, так что китайские корни не являются проблемой. А сам мониторинг необычен своей визуализацией. Выглядит непривычно, но интересно и функционально. Речь идёт про open source проект nezha. Можете сразу оценить функционал в публичном demo - https://ops.naibahq.com. Данный мониторинг поддерживает следующие метрики: ▪ базовые системные метрики (cpu, mem, disik, network) ▪ HTTP, в том числе TLS сертификаты ▪ TCP порты и ICMP проверки То есть это простой, легковесный мониторинг на GO, который можно развернуть у себя. Проект живой, регулярно обновляется. Попробовать можно в докере, есть готовый образ - ghcr.io/naiba/nezha-dashboard, либо воспользоваться установщиком в виде bash скрипта. # bash curl -L \ https://raw.githubusercontent.com/naiba/nezha/master/script/install_en.sh \ -o nezha.sh && chmod +x nezha.sh && ./nezha.sh Все инструкции живут в на отдельном сайте - https://nezha.wiki/en_US/index.html. Единственное, что я не понял — аутентификацию в панели зачем-то привязали к Github. Не знаю, в чём тут фишка. Может кто-то считает это удобным, но точно не я. Скрипт установки попросит Client ID и Secret, которые можно получить в github developers, создав новый OAuth app. В принципе, ничего сложного нет и делается за 3 минуты, но я как-то не оценил. Зато после этого доступ можно выдавать на основе учёток Github. Метрики с серверов собираются с помощью агентов (поддерживаются Windows, Linux, macOS, Synology, OpenWRT). Установить его очень просто. Достаточно добавить новый сервер в панель, и для него появится ссылка для скачивания агента. После установки агента данные автоматически появятся в панели управления. То есть сами агенты настраивать не надо. На серверы с агентами можно зайти по SSH через веб интерфейс панели управления. Мониторинг максимально простой и удобный, кроме привязки к Github. Если бы не она, можно было смело рекомендовать как вариант простого легко настраиваемого мониторинга. А так решать вам, подходит такой вариант или нет. #мониторинг
  • ServerAdmin.ru

    Серверы для бизнеса и частных проектов 📱 EKACOD. Data Center предлагает выделенные серверы в аренду от 4990 руб./мес. Собственная инфраструктура в Екатеринбурге 🇷🇺, уровень Tier III, SLA от 99,98%, опыт работы с 2013 года. ✅ 70+ готовых к работе конфигураций или любая сборка из 1000+ комплектующих; ✅ Полный доступ к управлению сервером: личный кабинет, KVM-консоль, установка ОС, статистика по трафику; ✅ Техническая поддержка 24/7, помощь в настройке и переносе проектов; ✅ Бесплатная замена любых вышедших из строя комплектующих; ✅ Решения для бизнес задач: серверы с GPU, для 1С-Битрикс и 1С:Бухгалтерии; ✅ Сопутствующие услуги ЦОД: каналы связи, диск для бэкапов, защита от DDOS-атак. Работаем с юридическими и физическими лицами, поддерживаем ЭДО Диадок. Оформите заказ в несколько кликов на 👉 https://ekacod.ru/ Или напишите нам, мы подберем нужный сервер для ваших задач по выгодной цене. #реклама
  • ServerAdmin.ru

    ​​Когда искал в сети материалы по Loki, наткнулся на интересную статью, где автор хранит в Loki все введённые команды в bash. Понравился подход, поэтому решил его приспособить под свои нужды. Я большого смысла для себя не вижу собирать эти логи где-то во вне, поэтому проработал момент только с сохранением их локально в лог с помощью syslog. Подход тут простой. Используется переменная bash PROMPT_COMMAND. Её содержимое выполняется после каждой введённой интерактивной команды. Так что достаточно указать выполнение нужного кода в этой переменной, чтобы собирать логи. Я предлагаю такой вариант: export PROMPT_COMMAND='RETRN_VAL=$?; logger -S 10000 -p local6.debug "{\"user\": \"$(whoami)\", \"path\": \"$(pwd)\", \"pid\": \"$$\", \"command\": \"$(history 1)\", \"status\": \"$RETRN_VAL\"}";' Эту переменную нужно добавить в файл ~/.bashrc и применить изменения, либо просто перезайти пользователем. Данная команда сохраняет имя пользователя, путь, откуда выполнялась команда, pid процесса (в данном случае это всегда будет pid баша, не уверен, что эта информация где-то нужна), сама команда, которая берётся из history, и статус её выполнения. Всё это отправляется в syslog в local6.debug. Теперь нам надо перехватить этот local6.debug. Добавляем в конфиг /etc/rsyslog.conf одну строку: local6.* /var/log/bash/bash.log создаём директорию и перезапускаем его: # mkdir -p /var/log/bash # systemctl restart rsyslog Вот, в принципе, и всё. Теперь после выполнения команды в консоли, она будет сразу улетать в лог. Формат лога - json. Можете его подредактировать для своего удобства. В статье автор также рассказывает, как можно сохранять вывод команды, но у меня не получилось настроить по его инструкции. Не смог разобраться, как это делать. Да и у него на всех скринах эта функция тоже не работает. А было бы неплохо это реализовать. Если кто-то знает или видел, как это делают, подскажите. И ещё есть один момент. Если вы работаете в MC, то в историю команд будет прилетать много мусора. Это типичная проблема MC и сохранения истории. Она постоянно возникает, когда пользуешься этим файловым менеджером. Ещё со времён Freebsd с этим сталкивался, так как у MC есть своя отдельная баш консоль, куда залетают команды во время перемещения по директориям. Напомню ещё способы логирования консольных команд: ◽snoopylog-user-session Решение с PROMPT_COMMAND наиболее простое и универсальное, так как не требует стороннего софта. Logger и syslog обычно присутствуют во всех популярных дистрибутивах. #bash #terminal #linux #security
  • ServerAdmin.ru

    ​​Давно не писал ничего на тему программ для бэкапа, потому что все наиболее популярные и удобные программы я уже описывал. Рекомендую посмотреть мои прошлые заметки по тэгу #backup, вот эту заметку с подборкой или статью на сайте. Там всё в одном месте собрано. Только не хватает программы restic, писал про неё позже. Я узнал и попробовал программу bup, про которую раньше не слышал. Она мне понравилась и показалась очень полезной, поэтому решил написать и поделиться с вами. Bup использует тот же алгоритм, что и rsync для деления файлов на фрагменты и проверки контрольных сумм, так что производительность у него на хорошем уровне. Особенность bup в том, что она использует гитовский формат хранения данных в репозиториях. При этом не возникает проблем с огромным числом файлов и большим объёмом. Плюс такого хранения в том, что легко создаются инкрементные копии, причём данные могут быть совсем разные с разных хостов. Но если они одинаковые, то станут частью инкрементной копии. Это хорошо экономит дисковое пространство. Bup умеет делать как локальные бэкапы, так и ходить за ними на удалённые серверы по SSH. Есть простенький встроенный веб интерфейс. Всё управление через консоль. Это в первую очередь консольный инструмент для самостоятельного велосипедостроения. Показываю, как его установить на Debian. # git clone https://github.com/bup/bup # cd bup # git checkout 0.33 # apt-get build-dep bup # apt install python3-pip # pip install tornado # make # make install Теперь надо выполнить инициализацию репозитория. По умолчанию, он будет в ~/.bup. Задать его можно через переменную окружения BUP_DIR. Добавим её сразу в .bashrc и применим изменения: export BUP_DIR=/mnt/backup # source ~./bashrc Инициализируем репозиторий: # bup init Создаём индекс бэкапа. Для примера возьму директорию /etc на сервере: # bup index /etc Делаем бэкап, назвав его etc с помощью параметра -n: # bup save -n local-etc /etc Посмотреть список репозиториев, файлов или бэкапов можно вот так: # bup ls # bup ls local-etc # bup ls local-etc/2023-01-31-190941 Бэкап удалённой машины делается примерно так: # bup index /etc # bup save -r SERVER -n backupname /etc Доступ к серверу надо настроить по ключам. Восстановление данных: # bup restore -C ./dest local-etc/latest/etc Восстановили директорию /etc с ветки latest бэкапа local-etc в директорию /.dest. Соответственно, выбирая разные ветки, вы восстанавливаете данные с того или иного инкрементного бэкапа. Очень необычная для бэкапов, но при этом весьма удобная схема хранения и работы с данными, точно так же, как с обычными git репозиториями. У bup есть простенький веб интерфейс, через который можно посмотреть и скачать файлы. По умолчанию он запускается на localhost, поэтому явно указываю интерфейс и порт: # bup web 172.25.84.75:8080 Если кто-то пользуется bup, поделитесь впечатлением. Программа старая и известная, но я про неё ранее не слышал и не пользовался. ⇨ Сайт / Исходники #backup
  • ServerAdmin.ru

    Как автоматизировать работу с серверами Linux?  Узнайте 🗓 16 февраля в 20:00 на открытом уроке «Infrastructure-as-code (Iac): Ansible, Vagrant, Terraform» онлайн-курса «Administrator Linux. Professional» в OTUS. На открытом уроке вы: - Узнаете что такое инфраструктура как код и что значит «сервера снежинки». - Узнаете, как автоматизировать рутинные процессы создания и настройки серверов с помощью инструментов Vagrant, Terraform, Ansible.  - Настроите свою мини-лабораторию и сохраните код от неё в системе контроля версий git. 👉 Пройдите вступительный тест для записи на занятие https://otus.pw/R38G/ Курс рассчитан на тех, кто уже знаком с базовыми настройками Linux. #реклама
  • ServerAdmin.ru

    ​​На днях писал про CIS. Решил не откладывать задачу и проработать документ с рекомендациями по Nginx. Делюсь с вами краткой выжимкой. Я буду брать более ли менее актуальные рекомендации для среднетиповых веб серверов. Например, отключать все лишние модули и делать свою сборку в обход готовых пакетов я не вижу для себя смыла. 📌Проверяем наличие настройки autoindex. В большинстве случаев она не нужна. С её помощью работает автоматический обзор содержимого директорий, если в них напрямую зайти, минуя конкретный или индексный файл. # egrep -i '^\s*autoindex\s+' /etc/nginx/nginx.conf  # egrep -i '^\s*autoindex\s+' /etc/nginx/conf.d/* # egrep -i '^\s*autoindex\s+' /etc/nginx/sites-available/* Не должно быть настройки autoindex on. Если увидите, отключите. 📌Обращения на несуществующие домены или по ip адресу лучше сразу отклонять. По умолчанию отдаётся приветственная страница. Проверить можно так: # curl -k -v https://127.0.0.1 -H 'Host: invalid.host.com' Если в ответ показывает приветственную страницу или что-то отличное от 404, то надо добавить в самую первую секцию server следующие настройки: server {  return 404; } Можно просто удалить конфиг с дефолтным хостом, а приведённый код добавить в основной nginx.conf. Тогда это точно будет первая секция server. В остальных секциях server везде должны быть явно указаны server_name. 📌Параметр keep-alive timeout имеет смысл сделать 10 секунд или меньше. По умолчанию он не указан и им управляет подключающийся. keepalive_timeout 10; То же самое имеет смысл сделать для send_timeout. send_timeout 10; Скрываем версию сервера параметром server_tokens. Проверяем так: # curl -I 127.0.0.1 | grep -i server Отключаем: server { ... server_tokens    off; ...  } 📌Дефолтные страницы index.html и error page лучше отредактировать, удалив всё лишнее. Обычно они хранятся в директориях /usr/share/nginx/html или /var/www/html. 📌Запрещаем доступ к скрытым файлам и директориям, начинающимся с точки. Для этого в добавляем в самое начало виртуального хоста location: location ~ /\. { deny all; return 404; } Если нужно исключение, например для директории .well-known, которую использует let's encrypt для выпуска сертификатов, то добавьте его выше предыдущего правила. location ~ /\.well-known\/acme-challenge { allow all; } 📌Скрываем proxy headers. Добавляем в location: location /docs { .... proxy_hide_header X-Powered-By;  proxy_hide_header Server; ....  } 📌Не забываем про настройку логирования. Логи нужны, но настройка сильно индивидуальна. Если логи хранятся локально, то обязательно настроить ротацию не только с привязкой ко времени, но и к занимаемому объёму. В идеале, логи должны храниться где-то удалённо без доступа к ним с веб сервера. 📌Настраиваем передачу реального IP адреса клиента в режиме работы Nginx в качестве прокси. server { ... location / { proxy_pass 127.0.0.1:8080); proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  } } 📌Ограничиваем версию TLS только актуальными 1.2 и 1.3. Если используется режим проксирования, то надо убедиться, что эти версии совпадают на прокси и на сервере. Если не уверены, что все ваши клиенты используют современные версии TLS, то оставьте поддержку более старых, но это не рекомендуется. Настройка для секции http в nginx.conf ssl_protocols TLSv1.2 TLSv1.3; 📌Настраиваем ssl_ciphers. Список нужно уточнять, вот пример из документа CIS: ssl_ciphers ALL:!EXP:!NULL:!ADH:!LOW:!SSLv2:!SSLv3:!MD5:!RC4; Дальше идут более узкие рекомендации типа ограничения доступа по IP, отдельных методов, настройка лимитов, более тонкие настройки таймаутов и т.д. В общем случае это не всегда требует настройки. Ничего особо нового в документе не увидел. Большую часть представленных настроек я и раньше всегда делал. В дополнение к этому материалу будет актуальна ссылка на предыдущую заметку по настройке Nginx. Надо будет всё свести в общий типовой конфиг для Nginx и опубликовать. #cis #nginx #security
  • ServerAdmin.ru

    ​​Летом была новость, что у платной программы HDDSuperClone были открыты исходники. Она стала полностью бесплатной, в том числе Pro версия. Я сейчас кратко поясню в чём её особенность и предложу вам связку из двух программ, сохранить себе на чёрный день, если вдруг понадобится восстановить данные с обычных дисков. Их хоть активно и заменяют SSD, но тем не мнее, HDD ещё используются. У меня как-то в NAS накрылся обычный диск, пришлось восстанавливать данные. Писал статью об этом. Как ясно из названия, HDDSuperClone предназначена для клонирования неисправных жёстких дисков. Подобного рода программ много, но у этой есть некоторые особенности. Она умеет напрямую обращаться к жёстким дискам и, к примеру, перезапускать их по питанию в случае зависания. Также у неё есть собственный драйвер для работы с дисками. Принцип работы драйвера следующий. Во время чтения с диска различными программами по восстановлению данных, всё, что удалось прочитать, драйвер пишет на виртуальный диск. А те данные, что нестабильны или их не удаётся сразу прочитать, считываются с диска. Таким образом, увеличивается шанс восстановления данных с минимальным беспокойством сбойного диска. Всё, что удалось с него прочитать и сохранить, считывается с копии, а всё остальное пробуют прочитать с него. Это функционал в прошлом платной версии. Сейчас она бесплатна. На сайте популярной бесплатной программы для восстановления данных R-Linux есть подробная статья с описанием восстановления данных с умирающего жёсткого диска с помощью связки R-Studio и HDDSuperClone. Сохраните себе эту информацию, чтобы потом не пришлось искать и подбирать программы для этих целей. ⇨ Сайт / Исходники / R-Studio и HDDSuperClone / Видеоинструкции #restore
  • ServerAdmin.ru

    🎯 Хардкорный тест по Базам данных Ответьте на 20 вопросов и проверьте, насколько вы готовы к обучению на онлайн-курсе «Базы данных» от OTUS. ⚠️ За полгода живых вебинаров вы научитесь работать с основными СУБД, которые могут вам пригодиться: PostgreSQL, MySQL, Redis, MongoDB, Cassandra и сможете оптимизировать медленные запросы. 📌 РЕЗУЛЬТАТ ПРОХОЖДЕНИЯ КУРСА Собственный SQL-проект, который усилит ваше портфолио и поможет получить выгодный оффер. Протестируйте обучение на открытом уроке «PostgreSQL 15. Новый функционал» — https://otus.pw/zoVt/   👉 ПРОЙТИ ТЕСТИРОВАНИЕ  https://otus.pw/lPeQ/ #Реклама Информация о рекламодателе на сайте otus.ru
  • ServerAdmin.ru

    ​​Ранее я уже затрагивал тему работы с регулярными выражениями, рассказав про сервис regex101.com. Хочу её немного развить и дополнить ещё несколькими полезными ссылками, которые имеет смысл собрать в одном месте, чтобы воспользоваться, когда нужно будет написать очередную регулярку. Есть очень удобный сервис, который на основе введённых вами данных сам напишет регулярку. Звучит, как фантастика, но он действительно это умеет. Это программа grex, которую можно запустить у себя, либо воспользоваться публичным сервисом — https://pemistahl.github.io/grex-js. Приведу простой пример для наглядности. Вам нужна регулярка, которая покрывает IP адреса из подсети 192.168.0.0/24. Мне не очевидно, как её сделать. А с помощью этого сервиса никаких проблем. Пишу простой скрипт, который мне сформирует строку со всеми 256 адресами: #!/bin/bash count=1 while [ $count -le 256 ] do echo 192.168.0.$count count=$(( $count + 1 )) done Копирую полученную строку в grex, получаю регулярку: ^192\.168\.0\.(?:2(?:5[0-6]|[6-9])|(?:1[0-9]|2[0-4]|[3-9])[0-9]?|25?|1)$ Для проверки прогоняю её через regex101.com и убеждаюсь, что пример рабочий. Конечно, какие-то сложные выражения с помощью этого сервиса не составить, но что-то простое запросто можно сделать, особенно если вы не особо разбираетесь в самостоятельном написании. Я буквально за 5 минут решил поставленную задачу. Сам бы точно ковырялся дольше с составлением. И ещё несколько ссылок. Сервис https://regexper.com наглядно разбирает регулярку с картинками. Удобно для изучения и понимания. А в сервисе https://ihateregex.io можно посмотреть примеры наиболее востребованных регулярок тоже с примерами разбора правил. Также хочу порекомендовать вам хороший бесплатный курс по изучению регулярных выражений — https://stepik.org/course/107335/promo. 📌 А теперь всё кратко одним списком: ▪ regex101.com — проверка регулярных выражений ▪ grex — автоматическое составление регулярок ▪ regexper.com — схематическое изображение регулярок ▪ ihateregex.io — готовые примеры регулярных выражений ▪ stepik.org — бесплатный курс для изучения регулярок #regexp #сервис
  • ServerAdmin.ru

    ​​Хочу познакомить вас с простой и крайне полезной консольной утилитой в Linux — basename. Я её регулярно использую при написании bash скриптов для различных задач. В примерах, которыми я с вами делился здесь, она тоже встречалась. С помощью basename удобно извлечь имя файла из полного пути. # basename /var/log/auth.log auth.log Вместо полного пути к файлу вы получаете только его имя. Можете сразу убрать расширение файла, если оно вам не нужно: # basename /var/log/auth.log .log auth Вот пример из реального скрипта, которым пользуюсь. Мне нужно было с помощью rsync передать с одного сервера на другой бэкапы прошлого дня. Более старые не трогать. Забирать файлы нужно было строго со стороннего сервера, а не копировать их со стороны исходного, где лежат файлы. При этом нужно было добавить еще и исключение в файлах, чтобы забрать только то, что нужно. Сделал так: # rsync -av --files-from=<(ssh [email protected] '/usr/bin/find /var/lib/pgpro/backup -type f -mtime -1 -exec basename {} \; | egrep -v timestamp') [email protected]:/var/lib/pgpro/backup/ /data/backup/ Список нужных файлов для копирования формирую на удаленном сервере с помощью find, оставляю только имена через basename, добавляю исключение через egrep и передаю этот список на целевой сервер через параметр rysnc --files-from.  Сходу не вспомнил ещё свои примеры с basename. Обычно она как раз с find используется. Причём, не удивлюсь, если у find есть какой-то ключ, чтобы вывести список файлов без полных путей. Я привык в итоге использовать basename. Ещё пример был недавно с импровизированной корзиной в Linux, где я тоже использовал basename, чтобы все удалённые файлы класть в отдельную папку в общую кучу, без сохранения путей. Мне так показалось удобнее. С помощью basename можно однострочником сменить расширение у всех файлов .txt на .log в директории: # for file in *.txt; do mv -- "$file" "$(basename $file .txt).log"; done Очевидно, что это не самый оптимальный и быстрый способ. Показал просто для примера. То же самое можно сделать с помощью rename, которая не везде есть по умолчанию, может понадобится установить отдельно. # rename 's/.txt/.log/g' *.txt Или ещё раз то же самое, только с помощью find, sed, xargs: # find . -type f | sed 'p;s:.txt:.log:g' | xargs -n2 mv Скрипты в Linux — бесконечный простор для творчества, особенно если писать их в bash. Там можно десяток различных способов придумать для решения одной и той же задачи. Чем больше утилит знаешь, тем больше вариантов. #bash #script
  • ServerAdmin.ru

    Максимально простое, автоматизированное и современное решение для управления удаленным доступом сотрудников. Alphabyte ZTNA позволит вам легко управлять доступом к корпоративным ресурсам, а вашим сотрудникам — быстро подключаться к любой корпоративной сети и безопасно работать из любой точки мира. Устанавливайте свои правила доступа к тем или иным корпоративным ресурсам: по ролям, типу трафика, дню недели, протоколу и порту. Демоверсия с полным доступом к сервису — 90 дней до конца января. Попробуйте сами: https://clck.ru/33JARa #реклама
  • Реклама

  • ServerAdmin.ru

    ​​Мне на днях в комментариях подсказали полезный сайт на тему безопасности. Раньше про него не слышал. Я обычно все рекомендации в общую очередь постов ставлю, где они чаще всего несколько месяцев проводят и при моём повторном внимании с подтверждением полезности оформляются в отдельную публикацию. А тут решил сразу изучить и написать, потому что сайт очень понравился. Речь пойдёт про workbench.cisecurity.org (CIS — Center for Internet Security). Это некоммерческая организация, которая разрабатывает собственные рекомендации по обеспечению безопасности различных систем. Там представлены как настройки различных операционных систем (win, lin, macos и т.д.) и готовых продуктов на их основе (sophos, pfsense и т.д.), так и одиночных программ (nginx, apache, mysql, elasticsearch, mongodb и т.д.) При этом рекомендации максимально подробные с описанием конкретных действий, которые надо сделать, вектором атак и общей теории по проблеме. Например, есть какая-то ОС Linux. Есть рекомендация отключить поддержку всех неиспользуемых файловых систем. И сразу представлены команды, как посмотреть, какие фс поддерживаются и как выгрузить модули ядра, которые осуществляют поддержку. Всё очень понятно и подробно. Я посмотрел некоторые документы по системам и программам, которые сам использую. Очень понравилась подача. Увидел некоторые вещи, про которые даже не слышал раньше. Появилось большое желание что-то нужное мне перевести, сократить и оформить в короткие рекомендации. Но не знаю, как получится. На это надо много времени. Документы на сайте CIS очень объёмные. С одной стороны это хорошо, если хочешь подробно изучить тему, а с другой плохо, потому что если тебе нужно только выполнить основные рекомендации, без детального погружения, ничего не выйдет. А не всем и не всегда нужно изучать материал на уровне специалиста по безопасности. Для примера скачал и выложил 3 документа оттуда по настройке Debian 11, Nginx, PostgreSQL 15. ⇨ https://disk.yandex.ru/d/P1Ph7IvUKHmnKQ #security #cis
  • ServerAdmin.ru

    ​​▶️ Недавно школа Слёрм проводила бесплатную трехдневную онлайн конференцию на тему мониторинга. Если она вам близка, то обратите внимание. У меня, конечно, не было времени всё это смотреть, но краем уха в фоне кое-что слушал. Все выступления аккуратно обрезаны по темам и залиты на youtube канал. Можете быстро оценить по названиям, что вам интересно, и посмотреть. Выступления комфортной длины в 20-30 минут. Если же хотите увидеть полные записи всех трёх дней, то они выложены в отдельном play листе. Конференция была сделана не для галочки. Выступали хорошие специалисты, некоторые известные люди в своих кругах. Темы рассматривали злободневные и актуальные. Описание всех докладов есть на отдельной странице мероприятия. Там же и ссылки на выступления в более удобном виде. Мне понравились следующие темы: ◽Начинаем внедрять мониторинг, без боли, регистрации и смсГоршочек, не вари! Сколько алертов вам нужно?Удобная работа с алертами, организация дежурных ротаций с помощью GrafanaOncallGrafana Loki как инструмент для сбора логов с вашей инфраструктурыКастомизация шаблонов для ZabbixМониторинг маркетинговых показателей #видео #мониторинг
  • ServerAdmin.ru

    Решил начать новую рубрику на канале с мемасиками. Я сам не особо люблю, когда постоянно публикуются картинки в каналах. Тем не менее, я их иногда смотрю, и что-то нравится, вызывает улыбку. Так что, думаю, одной картинки в неделю по пятницам будет достаточно. Публиковать буду то, что сам видел в течении недели и то, что показалось наиболее интересным. Если у вас есть желание поделиться чем-то прикольным, то можно это делать в комментариях. К подобным постам это будет уместно. Мультик из мема недавно просматривал с детьми. Очень клёвый, рекомендую. #мем