​​❓Как бы вы решили следующую задачу.

Как проверить, есть ли обращение клиента на порт TCP 22 сервера с определённого IP адреса и порта?

Это, кстати, вопрос из того же списка, что я публиковал ранее, но я решил его вынести в отдельную публикацию, потому что он объёмный, а там уже лимит сообщения был превышен.

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

Если же речь идёт о любом другом соединении, то если оно активно, посмотреть его можно с помощью netstat или более современного ss:

# netstat -ntu
# ss -ntu

Нужный адрес и порт можно грепнуть:

# netstat -ntu | grep ':22'

Менее очевидный вариант с помощью lsof:

# lsof -ni TCP:22

Если же речь вести про прошлые, а не активные соединения, то первое, что мне приходит на ум из подручных системных средств - логирование с помощью firewall. В iptables я это делаю примерно так:

# iptables -N ssh_in
# iptables -A INPUT -j ssh_in
# iptables -A ssh_in -j LOG --log-level info --log-prefix "--IN--SSH--"
# iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Сделал отдельную цепочку для логирования и отправил туда запись всех пакетов с портом назначения 22. Логи будут по умолчанию собираться в системном логе syslog. При желании можно в отдельный файл вынести через правило в rsyslog. Отдельную цепочку для каждой службы я обычно не делаю. Вместо этого создаю три цепочки - input, output, forward, куда добавляю правила для тех адресов и портов, которые я хочу логировать.

Это всё, что мне пришло в голову по данному вопросу. Если знаете ещё какие-то способы, то напишите. Будет интересно посмотреть.

Пока заканчивал материал, вспомнил про ещё один:

# cat /proc/net/nf_conntrack | grep 'dport=22'

В принципе, это тот же самый ss или netstat. Они скорее всего отсюда и берут информацию.

#network #terminal

​​Расскажу вам про одну систему, которая привлекла моё внимание. Сначала думал, что это какая-то малорабочая поделка, но когда навёл справки понял, что нет. Видел отзывы людей, которые её использовали месяцами. Речь пойдёт об Qubes OS.

Идея там очень похожа на то, что я описывал ранее в рассказе про Distrobox. Только тут вместо контейнеров полноценные виртуальные машины на базе гипервизора XEN. То есть вся система - это набор самостоятельных виртуальных машин, разделённых по некоторым логическим признакам или приложениям. Например, отдельная VM для работы, для развлечений, для приватной информации и т.д. Можно настроить работу какого-то приложения в отдельной виртуальной машине.

Система построена на базе Fedora. В качестве основной хостовой системы может быть выбрана Fedora либо Debian. Все виртуальные машины интегрированы в единый интерфейс основной системы. Разработчики постарались всё это организовать так, чтобы было похоже на единую систему на базе Linux.

Для того, чтобы всё нормально работало, железо должно поддерживать технологию IOMMU (Intel VT-d или AMD IOMMU). Она нужна для корректной работы изолированных сетей и проброса PCI устройств в виртуалки. Я попробовал развернуть Qubes OS во вложенной виртуализации в Proxmox. Систему поставил, но сеть между VM не заработала как раз из-за отсутствия IOMMU. Так что для нормальной работы системы её надо ставить на соответствующее железо. Оценить удобства работы такой необычной схемы не получилось.

Вообще, идея подобной системы кажется здравой. Современные гипервизоры уже достаточно развиты, чтобы реализовать подобную концепцию. Дело только за практической реализацией. Было бы удобно иметь ОС, которая по сути состоит из отдельных кубиков, внутри которых может быть любая ОС, в том числе и Windows. Qubes OS как раз позволяет создать такую систему. Нужно только корректно и без багов реализовать межсистемное взаимодействие. Технических проблем нет. Все системы, что поддерживает гипервизор, в теории могут запускаться и работать в такой системе.

Если кто-то уже пользовался этой системой, поделитесь впечатлениями. Концепция, как я уже сказал, выглядит заманчивой. Загрузил шаблон нужной системы и развернул любой софт на его основе. И всё это добавил в единое рабочее пространство. Удобно же. Чем-то похоже на Windows и WSL, только более масштабно. Qubes OS, кстати, Windows тоже поддерживает.

⇨ Сайт / Свежий обзор

#разное

​​Вчера кратко коснулся темы логирования сетевых соединений с помощью iptables. Решил посвятить этой теме отдельную заметку и рассказать, как я настраиваю логирование.

Задач вести какую-то статистику с помощью iptables у меня обычно нет, так что логирую я чаще всего заблокированные соединения. И то только на момент отладки, потому что часто это большой объём информации.

Вот пример простейшего набора правил для веб сервера, где запрещено всё, что не разрешено явно (22,80,443 порты). Показываю для понимания принципа.

# default rules
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# allow localhost
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# allow established
iptables -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT

# allow ping
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# allow server connections
iptables -A OUTPUT -o ens3 -j ACCEPT

# allow ssh, www
iptables -A INPUT -i ens3 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i ens3 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i ens3 -p tcp --dport 443 -j ACCEPT

# logging
iptables -N block_in
iptables -N block_out
iptables -N block_fw
iptables -A INPUT -j block_in
iptables -A OUTPUT -j block_out
iptables -A FORWARD -j block_fw
iptables -A block_in -j LOG --log-level info --log-prefix "-IN-BLOCK-"
iptables -A block_in -j DROP
iptables -A block_out -j LOG --log-level info --log-prefix "-OUT-BLOCK-"
iptables -A block_out -j DROP
iptables -A block_fw -j LOG --log-level info --log-prefix "-FW-BLOCK-"
iptables -A block_fw -j DROP

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

📌 Полезные материалы по теме:

▪ Графическое отображение правил iptables
▪ Защита от брута и скана портов
▪ Отладка работы с помощью iptables-tracer
▪ Бан всех, кто стучит в закрытый порт
▪ Блокировка стран по IP

#iptables

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

Очень нужен совет. Имеется два выделенных сервера, арендованных в Selectel. Сервера с приватной сетью. На серверах планируется поставить RDP сервер на Windows и сервер под базу данных. Сервера должны уметь общаться между собой. Плюс еще нужен безопасный доступ к RDP серверу. Как лучше на ваш взгляд все это организовать? Поставить на оба сервер Proxmox и на него виртуалки? Возможно ли при таком раскладе чтобы виртуалки с разных хостов Proxmox видели друг друга? Как обезопасить доступ RDP? Поднимать какой-то шлюз или как? Или вообще без Proxmox обойтись?

Я бы делал следующим образом:
 
1️⃣ В обязательном порядке на сервера поставил Proxmox и всю функциональность реализовывал бы только в виртуальных машинах. Так как есть приватная сеть, никаких дополнительных сложностей со взаимодействием виртуальных машин не будет. Делаем бридж на интерфейсах приватной сети и добавляем сетевые интерфейсы с этим бриджем виртуальным машинам. Они будут обращаться друг к другу напрямую.

2️⃣ На машине с терминальным сервером сделал бы отдельную виртуалку под шлюз. Все остальные виртуальные машины ходили бы в интернет через неё. В эту виртуалку прокинул бы сетевой интерфейс с внешним IP. Сами гипервизоры настроил бы только в приватной сети, чтобы они ходили в интернет тоже только через этот шлюз. Обязательно настроить автоматический запуск этой виртуальной машины.

3️⃣ На шлюзе настроил бы firewall и управлял доступом к виртуалкам и их доступом в интернет через него. На него же поставил бы Nginx для проксирования запросов к внутренним веб ресурсам.

4️⃣ Доступ к терминальному серверу реализовал бы либо с помощью Openvpn, если нужен прямой доступ через терминальный клиент, либо с помощью Guacamole, если будет достаточен такой режим работы на сервере через браузер. Настраивал бы это на шлюзе. Можно сразу и то, и другое.

5️⃣ В отдельной виртуальной машине поднял бы Zabbix для мониторинга всего этого хозяйства и какую-то систему для сбора логов (ELK или Loki). И добавил бы внешний мониторинг, типа uptimerobot или uptime-kuma.

6️⃣ Если есть возможность по месту на дисках, на одном из серверов организовал бы вируталку под локальные бэкапы как самих виртуальных машин, так и сырых данных. С этой виртуалки забирал бы данные куда-то во вне. Если есть возможность поднять Proxmox Backup Server, поднял бы его для внешнего бэкапа виртуалок целиком.
 
Итого, получается следующая минимальная конфигурация по виртуалкам:

▪ СУБД
▪ Терминальник
▪ Шлюз
▪ Мониторинг и логи
▪ Бэкап.

Раскидываются между серверами в зависимости от ресурсов и нагрузки. Скорее всего СУБД и Мониторинг с логами это один сервер, Терминальник, Шлюз и Бэкап это второй сервер. При желании можно раздробить всё это на большее количество виртуальных машин. Мониторинг, Guacamole, Логи разнести по разным машинам. Это будет удобнее и безопаснее, но больше расходов по ресурсам и поддержке.

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

#виртуализация #совет

​​Тема с Portmaster получила очень живой отклик в виде сохранений заметки. Решил её немного развить и предложить альтернативу этому хоть и удобному, но очень объёмному и тяжёлому приложению. Тяжёл прежде всего интерфейс на Electron, само ядро там на Go. В противовес можно поставить simplewall. Это обёртка над Windows Filtering Platform (WFP) весом буквально в мегабайт. В репозитории все скрины на русском языке, так что автор, судя по всему, русскоязычный.

Компания Microsoft действует очень разумно и логично в своей массовой системе Windows. Закрывает наиболее актуальные потребности людей, замыкая их в своей экосистеме. Отрезает всех остальных от бигдаты пользователей. Её встроенных средств безопасности и защиты достаточно среднестатистическому пользователю. Нет необходимости ставить сторонние антивирусы или прочие приложения.

WFP - это набор системных служб для фильтрации трафика, охватывающий все основные сетевые уровни, от транспортного (TCP/UDP) до канального (Ethernet). Simplewall взаимодействует с WFP через встроенный API. То есть это не обёртка над Windows Firewall, как может показаться вначале.

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

Simplewall поддерживает работу с системными службами, приложениями из магазина, WSL, с обычными приложениями. Можно логировать сетевую активность приложений или служб. Несмотря на то, что используется встроенный системный инструмент, он позволяет заблокировать в том числе и обновления системы с телеметрией.

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

#windows #security #network

▶️ Нескончаемая тема приколов на тему разработчиков и тестировщиков. Ютуб подкинул в рекомендации. Вообще, неплохо эти рекомендации работают. Я постоянно что-то оттуда смотрю и периодически сохраняю, чтобы вам показать. Некоторое вижу там впервые. То есть не видел в других каналах с приколами, как, к примеру, представленное видео.

Кто не видел, рекомендую ещё вот это посмотреть по схожей теме: https://t.me/srv_admin/1189

#юмор

​​🎓 За всё время ведения канала не было ни одной рекомендации по хорошему обучающему материалу по Ansible. Хотел сам что-то пройти, чтобы освежить знания, и не нашёл ничего у себя на канале.

Если у кого-то есть рекомендации на хорошие бесплатные курсы по этой теме, то поделитесь информацией. Вот то, что нашёл я.

▪ Ansible На Русском Языке от небезызвестного Дениса Астахова, автора канала ADV-IT. Зная другие материалы этого автора, предполагаю, что это качественный материал.

▪ ИТМО: Инфраструктура как код - свежий курс от известного сообщества DeusOps. У них свой канал в ютубе, телеграме, там же есть чат. Я сам не слежу за этим сообществом, но временами видел материалы оттуда, как и пересылку своих постов отсюда в их чат.

▪ Ansible для начинающих + практический опыт - бесплатный курс на Stepik, плюс от этой же компании небольшой плейлист на ютубе.

▪ Небольшой курс из двух уроков от автора канала Unix way. Я уже не раз упоминал его на канале. Уровень материала у него хороший. Да и отзывы к урокам говорят о том, что уроки сделаны качественно.

Ansible это стопроцентная база, как и git, современной эксплуатации, поддержки серверов и сервисов. Обязательно нужно знать. Даже если на практике сейчас вам это не нужно, пройдите хотя бы один курс, чтобы иметь представление о том, что это такое.

#обучение #ansible

​​Смотрите, какой прикол. Не знал, что такое в принципе возможно. В голом терминале можно ходить по современным сайтам, даже с подключением по SSH. Причём они выглядят так, что сразу и не поймёшь, что смотришь в терминале. Только картинки выдают, да и то не сразу.

# docker run --rm -ti fathyb/carbonyl https://google.com

Carbonyl собран на базе Chromium. Он даже видео c ютуба проигрывает. Правда, если подключился к голому серверу по SSH, то звука, очевидно, не будет.

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

⇨ Исходники

#разное

​​Для тех, кто сам настраивает и обслуживает почтовые сервера, хочу предложить удобный инструмент для диагностики - Swaks (Swiss Army Knife for SMTP). В нём нет чего-то особенного, что вы не смогли бы выполнить с помощью прямых запросов через telnet. Но со swaks удобнее, быстрее и проще, и при этом вы видите полный лог общения с почтовым сервером, как если бы вы с ним общались по telnet.

Утилита есть в стандартных репозиториях популярных систем, так что с установкой никаких проблем:

# apt install swaks

Можете сразу же проверить свой сервер на возможность отправки сообщений без аутентификации:

# swaks --to user@example.com --server mail.example.net

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

# swaks --to zeroxzed@gmail.com --from vladimir@zeroxzed.ru --auth PLAIN --auth-user vladimir@zeroxzed.ru --server mail.zeroxzed.ru

С помощью похожего запроса можно удобно проверить поддерживаемые методы аутентификации. Например, CRAM-MD5:

# swaks --to zeroxzed@gmail.com --from vladimir@zeroxzed.ru --auth CRAM-MD5 --auth-user vladimir@zeroxzed.ru --server mail.zeroxzed.ru

=== Trying mail.zeroxzed.ru:25...
=== Connected to mail.zeroxzed.ru.
<- 220 mail.zeroxzed.ru ESMTP
 -> EHLO debian11.homelab.local
<- 250-mail.zeroxzed.ru
<- 250-8BITMIME
<- 250-SIZE 31457280
<- 250-AUTH PLAIN LOGIN
<- 250-STARTTLS
<- 250 PIPELINING
*** Auth not attempted, requested type not available
 -> QUIT
<- 221 Goodbye

Сервер ответил, что подобный механизм аутентификации не поддерживает.

Если не хочется каждый раз указывать данные аутентификации, их можно добавить в файл .netrc. Это тот же файл, что поддерживает и curl. Формат его такой:

machine mail.server.ru login root@server.ru password password123

Чтобы программа приняла этот файл, у него должен быть доступ только для пользователя, от которого вы запускаете программу.

В качестве тела письма можно использовать текстовый файл. Это удобно, если нужно проверить работу антивируса или антиспама. К примеру, берём файл EICAR-Test-File, на который все антивирусы дают реакцию, как на вирус, и отправляем его содержимое письмом:

# wget http://eicar.eu/eicar.com.txt
# swaks --to zeroxzed@gmail.com --from vladimir@zeroxzed.ru --auth PLAIN --auth-user vladimir@zeroxzed.ru --server mail.zeroxzed.ru --attach - --suppress-data <eicar.com.txt

Gmail не принял письмо: "552 5.7.0 This message was blocked because its content presents a potential security issue."

Тело письма можно и сразу в консоли передать через ключ --body 'foo', тему через --header 'Subject: foo'. Можно и случайные заголовки добавлять примерно так: --header-X-Test "test email".

В общем, инструмент простой, универсальный, интуитивно понятный. Автор поддерживает и регулярно обновляет. Можно использовать и в каких-то велосипедах на bash. Swaks умеет работать через различные прокси, использовать tls сертификаты с выбором шифров и некоторых настроек.

⇨ Исходники

#mailserver

У меня давняя привычка — прятать все непубличные службы за firewall. Это касается и веб интерфейса Proxmox. Если сервер настраиваю сам, то всегда на самом хосте настраиваю iptables. Мало того, что так проще всего ограничить доступ к гипервизору, так он еще и шлюзом может выступить для виртуальных машин, так как всё управление NAT тоже через правила iptables.

Если сервер настраивал не я, и тем более если к серверу нет доступа напрямую в консоль, настраивать firewall я уже не буду. Все эти вещи всегда делаю после установки системы и перед переносом рабочей нагрузки. Если по какой-то причине доступ к веб интерфейсу Proxmox не ограничили, сделать это можно отдельно для службы pveproxy, которая отвечает за веб интерфейс. Это безопасно и всегда можно исправить ошибки, если что-то пошло не так.

У службы pveproxy есть файл конфигурации /etc/default/pveproxy, в который можно добавить правила с ограничением доступа. По умолчанию файла нет, его нужно создать. Выглядит это примерно так:

ALLOW_FROM="10.0.0.1-10.0.0.5,192.168.0.0/22"
DENY_FROM="all"
POLICY="allow"

После этого службу надо перезапустить:

# systemctl restart pveproxy.service

Если где-то ошиблись, можно зайти по SSH и внести изменения. Подключение по SSH намного безопаснее открытого веб интерфейса, так что за SSH можно сильно не переживать. А вот веб интерфейс мне всегда стрёмно оставлять в открытом доступе.

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

LISTEN_IP="192.0.2.1"

Также там можно переназначить дефолтные tls сертификаты. Это удобно, если вы используете свои. Все эти возможности описаны в документации.

#proxmox

​​Iptables по прежнему остаётся наиболее распространённым файрволом на Linux. Несмотря на то, что nftables уже давно анонсированы и по умолчанию установлены во многих дистрибутивах, тот же Docker по прежнему по умолчанию использует iptables.

Я в своё время уже разбирал работу nftables, делал для себя типовой набор правил. Могу сказать, что nftables реально удобнее, функциональнее iptables. Набор правил там нагляднее и читабельнее. Так что если будет нужно, я спокойно на него перейду. Пока так и не вижу смысла, так как конкретно я не решаю ни одну из своих задач быстрее и удобнее в nftables по сравнению с iptables. То есть мне в целом всё равно, поэтому использую то, что привычнее и более распространено.

Возвращаюсь к iptables. В этом файрволе очень важно расположение правил. Я первое время, когда его настраивал, не обращал на это внимания. В принципе, если нагрузки небольшие, то современные процессоры переварят практически любое расположение правил. Но для общего развития лучше понимать, как они работают.

Пакеты проходят по списку правил по порядку, сверху вниз. Если пакет соответствует какому-то правилу, то он прекращает движение по цепочке. Из этого следует важный вывод — первыми в цепочке должны быть правила, которые охватывают максимальный объем трафика, чтобы он дальше не обрабатывался устройством. Примером такого правила является разрешение пакетов уже установленных (established) или связанных (related) соединений, которые ранее были разрешены каким-то правилом. Повторно проверять по всем правилам их не имеет смысла. То же самое относится к проблемным пакетам (например, invalid), которые нам не нужны и мы можем их сразу отбросить.

Правила читаются по порядку в каждой отдельной цепочке: Input, Forward, Output. Если вы в списке своих правил как-то их перемешаете, то это не повлияет на порядок их обработки. Каждое правило попадёт в ту цепочку, к которой оно относится и будет выполняться в соответствии со списком правил в этой цепочке.

Таким образом, порядок построения правил для iptables должен быть примерно следующий:

1️⃣ Разрешающие правила, охватывающие максимальный объём трафика.
2️⃣ Остальные разрешающие правила.
3️⃣ Правило, запрещающее весь трафик данной цепочки.

Это пример настройки нормально закрытого файрвола, когда запрещено всё, что не разрешено явно. Антиподом данного подхода может быть нормально открытый брандмауэр, в котором всё разрешено, кроме того, что запрещено явно. Я лично почти всегда использую нормально закрытый файрвол за редкими исключениями. Одно из таких исключений — настройка шлюза для локальной сети, где всё, что касается внешнего интерфейса и доступа извне, нормально закрыто, а всё, что касается локальной сети и доступа из неё в интернет, нормально открыто и блокируется выборочно по мере необходимости.

Вот пример минимального набора правил для шлюза на базе Linux и iptables. Он подойдёт как для обычного офиса, так и для шлюза виртуальных машин гипервизора. Его же можно использовать прямо на гипервизоре Proxmox, если он сам выступает шлюзом для виртуальных машин.
⇨ https://pastebin.com/0sw4Cr5w

#iptables

​​Несколько полезных команд для консоли клиента mysql из практики, которыми пользуюсь сам.

📌 Посмотреть размер баз данных на сервере с сортировкой по размеру в мегабайтах:

SELECT table_schema "DB Name", ROUND(SUM(data_length + index_length) / 1024 / 1024, 1) "Size in MB" FROM information_schema.tables GROUP BY table_schema ORDER BY `Size in MB` DESC;

📌 Посмотреть размер конкретной базы данных:

SELECT table_schema `Database`, round(Sum(data_length + index_length) / 1024 / 1024, 1) `Size in MB` FROM information_schema.TABLES WHERE table_schema = "имя базы";

📌 Посмотреть размер самых больших таблиц в базе данных:

SELECT table_name `Table`, round(((data_length + index_length) / 1024 / 1024), 2) `Size in MB` FROM information_schema.TABLES WHERE table_schema = "имя базы" ORDER BY `Size in MB` DESC LIMIT 10;

📌 Удалить все таблицы в базе данных, не удаляя саму базу. То есть полная очистка базы без удаления:

SELECT CONCAT ('DROP TABLE ',GROUP_CONCAT(TABLE_NAME),';') INTO @qery FROM INFORMATION_SCHEMA.TABLES WHERE table_schema = "имя базы"; PREPARE drop_tables FROM @qery; EXECUTE drop_tables;

Последнюю команду посоветовали в комментариях к заметке, где я то же самое делаю своими костылями на bash. На самом деле эта, казалось бы простая задача, на деле не такая уж и простая. Я себе сохранил предложенный вариант. Он удобнее и проще моего.

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

#mysql

​​Мы все привыкли к тому, что интерфейс MC — это синий цвет двух панелей. Я когда-то давно узнал, что у популярного файлового менеджера можно выбрать другую цветовую тему оформления. Немного поигрался и забросил это дело. Но с тех времён у меня до сих пор осталась одна виртуальная машина с тёмной темой MC. Решил рассказать об этом. Наверняка многие не знают, что у Midnight Commander есть разные темы оформления.

В составе пакета MC есть большой набор различных тем. Живут они в /usr/share/mc/skins. Чтобы быстро посмотреть, как выглядит файловый менеджер с любой из тем, достаточно указать нужную тему отдельным ключом:

# mc -S darkfar

Если тема понравилась, то можно установить её по умолчанию. Для этого нужно выключить MC, открыть файл конфигурации ~/.config/mc/ini редактором, отличным от mcedit и изменить параметр с
skin=default
на
skin=darkfar

Теперь MC будет запускаться с выбранной темой. Если выбираете тему с 256 цветами, то убедитесь, что ваш терминал поддерживает 256 цветов. Настроить это можно в .bashrc или .bash_profile, добавив туда:

export TERM=xterm-256color

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

Сам я обычно оставляю тему по умолчанию. Но после того, как написал эту заметку, решил поменять у себя в WSL тему на xoria256.

❗️Ну и раз уж речь зашла о MC, добавлю информацию о настройке, которую я делаю всегда по умолчанию сразу после установки этого пакета на сервере:

# cp /usr/share/mc/syntax/sh.syntax /usr/share/mc/syntax/unknown.syntax

Я копирую правила подсветки синтаксиса для файлов .sh на все неопознанные форматы файлов. Сюда будут относиться в основном лог файлы и файлы конфигураций без расширений. Чаще всего для них как раз актуален стандартный синтаксис скриптов sh.

Большие лог файлы иногда начинают подтормаживать при открытии с подсветкой. Тогда она быстро отключается комбинацией клавиш Ctrl + S.

#linux #mc

​​Если вам по какой-то причине не нравится современное именование сетевых интерфейсов в Linux вида ens18, enp0s18 и т.д. то вы можете довольно просто вернуться к привычным названиям eth0, eth1 и т.д. Только сразу предупрежу, что не стоит это делать на уже работающем сервере. Если уж вам так хочется переименовать сетевые интерфейсы, то делайте это сразу после установки системы.

Итак, если вам хочется вернуть старое именование интерфейсов, то в файле конфигурации grub /etc/default/grub добавьте в параметр GRUB_CMDLINE_LINUX дополнительные значения net.ifnames и biosdevname:

GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

У вас уже могут быть указаны какие-то другие значения. Новые добавьте через пробел. Изначально их вообще может не быть, а параметр указан вот так:

GRUB_CMDLINE_LINUX=""

Или могут быть какие-то другие значения:

GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet"

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

# dpkg-reconfigure grub-pc

В rpm уже точно не помню, специально не проверял, но вроде бы раньше это выглядело так:

# grub2-mkconfig -o /boot/grub2/grub.cfg

Как в современных версиях уже не знаю, так как не использую их.

После этого нужно везде в сетевых настройках изменить имена интерфейсов со старых на новые. Для Debian достаточно отредактировать /etc/network/interfaces. Не забудьте про firewall, если у вас правила привязаны к именам интерфейсов.

Теперь можно перезагружать сервер. Загрузится он со старыми названиями сетевых интерфейсов.

Попутно задам вопрос, на который у меня нет ответа. Я не понимаю, почему в некоторых виртуалках по умолчанию используется старое именование сетевых интерфейсов, а в некоторых новое. Причём, это не зависит от версии ОС. У меня прямо сейчас есть две одинаковые Debian 11, где на одной eth0, а на другой ens18. Первая на HyperV, вторая на Proxmox. Подозреваю, что это зависит от типа эмулируемой сетевухи и драйвера, который используется в системе.

#linux #network

​​Более года назад я приобрёл для постоянной работы ноутбук ThinkPad T480. Тема рабочего ноутбука всегда вызывала активные обсуждения, поэтому решил поделиться своими впечатлениями и опытом продолжительного использования. Ссылки по теме:

- Конкретные советы моделей для рабочего ноутбука админа
- Плюсы и минусы ThinkPad T480 после начала использования
- Использование Throttlestop для отключения троттлинга
- Мои настройки ThrottleStop

Спустя чуть более года использования ThinkPad T480 поделюсь выводами.
➖ Сначала минусы:

🔴 Отвратительная кнопка G (русская П). Она постоянно выскакивает, когда при наборе текста определённым образом на неё нажимаешь. У меня это происходит примерно в 30% случаев. Жутко раздражает. Уже за одну эту кнопку я бы не рекомендовал этот ноут. Она меня достала. Если кто знает, как это исправить, поделитесь информацией.

🔴 Экран так себе. Не могу сказать, что он прям какой-то очень плохой. Раньше у серии ThinkPad были хорошие экраны. А тут он обычный, как у средненького ноута. Углы нормальные, но он какой-то не очень яркий. У меня кое-где небольшие засветы есть, но заметны только на чёрном фоне. У меня везде светлые темы, так что я вообще не замечаю.

🔴 При закрытии крышки на экране остаются следы от клавиш клавиатуры. Если экран не пыльный, почти не заметно. Если чуть запылился, то очень заметно. В процессе работы меня это особо не беспокоит, не заметно на включенном экране, но сам факт не нравится.

Минусы какие-то детские, нелепые, особенно с клавишей. Вообще не понятно, как такой именитый бренд наделал таких ошибок с кнопкой и отпечатком клавиш на экране.

➕ Теперь про плюсы для меня:

🟢 Поддержка полноценной док станции. Это была основная причина покупки ThinkPad. Мне нравится, что можно прийти домой, воткнуть ноут в док и нормально работать за полноценным рабочим местом, не перетыкивая экраны, периферию, блок питания. Сейчас небольшой выбор подобных ноутбуков.

🟢 Хорошее охлаждение конкретно этой модели, где встроена дискретная видеокарта, которой я не пользуюсь. В итоге встроенный запас по охлаждению позволяет мне всегда работать с максимальной частотой процессора 4.2 GHz. И при этом в обычном режиме работы у меня даже вентиляторы не запускаются, потому что процессор не доходит до 70-ти градусов. Я вставил режим работы вентилятора такой, что он включается только если процессор нагревается выше 70-ти градусов.

🟢 Поставил нормальный SSD, добавил памяти до 32 GB. Получил хорошую производительность. Спокойно запускаю 1-2 виртуалки, если нужно. В том числе на винде. На скорость работы основной системы не сказывается. Иногда забываю выключить их, они так весь день и работают в фоне. То есть я купил уже не новое бушное железо и получил производительность, которой с головой хватает для повседневной работы.

🟢 Два аккумулятора это удобно. Можно один отцепить, если не нужен, и ноут становится легче. Можно более гибко управлять настройками электропитания. Автономная работа сильно зависит от профиля нагрузки. Мне для моих стандартных дел хватает заряда аккумуляторов на 4-5 часов работы.

Подводя итог скажу, что это обычный ноут. Если бы не поддержка док станций, то он ничем не лучше каких-нибудь других одноклассников. А скорее всего хуже из-за экрана. Я себе ThinkPad больше брать не буду. Этот в прошлом качественный бренд полностью выродился.

Но и отговаривать тоже кого-то не буду, если попадётся это бушное железо в нормальном состоянии. За исключением перечисленных минусов, каких-то более значительных проблем с ним я не видел. Качество исполнения всего остального нормальное. Хороший механизм открытия экрана, удобный тачпад с жестами, сканер отпечатков пальцев. Я только на этом ноуте стал им пользоваться.

#железо

🔝 Традиционный ТОП постов за прошедший месяц. Все самые популярные публикации можно почитать со соответствующему хэштэгу #топ.

Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые возможности по настройке (не только публикацию историй):
https://t.me/boost/srv_admin

И ещё хочу напомнить или уточнить, что мой канал не является обучающим. Никогда не делал на этом акцент. Я не выверяю формулировки, не ищу оптимальные решения тех или иных задач. Это просто мой личный блог, где я пишу то, что делаю, что думаю, что знаю или не знаю, что нахожу интересного и т.д. Не надо брать и слепо повторять за мной. Какие-то вещи я сам узнаю впервые из комментариев.

📌 Больше всего просмотров:
◽️Заметка про мою работу в новогодние праздники (12200)
◽️Браузер Mypal68 для Windows XP (11765)
◽️Мем про интернет по карточкам (11380)

📌 Больше всего комментариев:
◽️Настройка виртуалок и сети для них на базе Proxmox (166)
◽️Мем про интернет по карточкам (100)
◽️Браузер Mypal68 для Windows XP (96)
◽️Вопросы на собеседовании DevOps (93)

📌 Больше всего пересылок:
◽️Бесплатные курсы по Ansible (537)
◽️Вопросы на собеседовании DevOps (445)
◽️Монтирование дисков с помощью systemd (438)
◽️Клиент для WireGuard TunnlTo (421)

📌 Больше всего реакций:
◽️Мем про интернет по карточкам (283)
◽️Использование hostnamectl (270)
◽️Вопросы на собеседовании DevOps (214)
◽️Монтирование дисков с помощью systemd (214)
◽️Использование qemu-guest-agent для запуска команд (170)

#топ

​​Вспомнил недавно про небольшую, но полезную программу для тех, кто подключает пользователей по RDP. Я сам её использовал некоторое время в прошлом. Речь пойдёт про Remote Desktop Plus. Это бесплатный (исходный код закрыт, это не open source) wrapper поверх стандартного клиента удалённого рабочего стола mstsc.exe. С его помощью можно настроить любое подключение, в том числе указав сразу логин с паролем, передать его пользователю, чтобы он смог подключиться по rdp, не вводя никаких данных и настроек.

Вообще, у программы много различных возможностей. Я использовал только одно — передача параметров rdp подключения в виде параметров командной строки. Выглядело это так:

1️⃣ Скачиваем программу rdp.exe, которая запускается без установки.
2️⃣ Рядом кладём rdp.bat файл примерно такого содержания:
rdp.exe /v:10.20.1.27 /u:user /p:password
3️⃣ Отправляем пользователю архив с rdp.exe и rdp.bat.
4️⃣ Пользователь распаковывает архив, запускает rdp.bat и подключается по rdp к серверу 10.20.1.27 с автоматическим вводом пользователя и пароля. То есть ему ничего делать не надо. И не будет никаких запросов на тему доверия к сертификату сервера.

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

Эта программа удобна для того, чтобы какой-то компьютер автоматически подключать по RDP при загрузке. Достаточно добавить rdp.exe с параметрами командной строки в автозапуск с помощью стандартного планировщика.

У Remote Desktop Plus есть msi пакет и шаблон групповой политики в формате ADMX для централизованного управления RDP соединениями. Я показал самый простой пример соединения. На сайте перечислены все поддерживаемые параметры командной строки и примеры использования.

⇨ Сайт

#windows #rdp

​​Давно уже вышло обновление Proxmox 8.1, в котором несмотря на то, что это не новая ветка, появилось много значительных изменений. Для тех, кто хочет сразу посмотреть видеообзор на них, предлагаю видео на канале RomNero, где помимо 8.1, показаны изменения версии 8.0 по сравнению с 7.4, если вы их пропустили:

▶️ Proxmox 8.1 Upgrade. Обзор. Как безопасно обновиться

Если бы не это видео, я бы так и не узнал, что в версии 8.1 столько изменений. Не привык обращать внимание на промежуточные обновления внутри релиза. Основные нововведения 8.1:

◽ Появилась возможность создания программно определяемых сетей (SDN, Software-Defined Networking). Теперь можно создавать сетевые сегменты, помещать в них виртуальные машины, назначать IP адреса. И управлять всем этим через веб интерфейс в отдельном разделе. Реализован встроенный DHCP сервер на базе dnsmasq.
◽ Расширили возможности настройки оповещений через внешние SMTP сервера. Плюс, добавили условия, по которым можно направлять уведомления через разные способы доставки.
◽ Добавили поддержку Secure Boot.
◽ Добавили массовые действия для виртуальных машин. Можно выделить пачку машин, и, к примеру, перезагрузить их разом или потушить.
◽ Теперь при создании виртуальных машин на Windows можно сразу в интерфейсе настройки VM добавить диск с драйверами virtio.

Изменения масштабные. Больше и полезнее, чем в 8.0. Надо будет на днях обновиться и потестировать всё это. Полный список нововведений и обзор от разработчиков:

⇨ https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_8.1
▶️ https://www.proxmox.com/en/services/videos/proxmox-virtual-environment/what-s-new-in-proxmox-ve-8-1

#proxmox

​​Решил, не откладывая в долгий ящик, проверить работу SDN на Proxmox 8.1. У меня как раз стоял настроенный недавно чистый сервер, причём версии именно 8.1. Я даже не обратил внимание на нововведения этого релиза и настроил всё по старинке с ручным созданием бриджа, правилами iptables с NAT, для того, чтобы гипервизор выступал в роли шлюза для виртуальных машин. Сейчас сделаю всё то же самое, только через настройки SDN.

Если вы обновили до 8.1 с прошлых релизов, то необходимо выполнить подготовительные действия.

1️⃣ Устанавливаем дополнительные пакеты и запускаем службу:
# apt update
# apt install libpve-network-perl dnsmasq
# systemctl enable --now dnsmasq
Dnsmasq заработает на всех интерфейсах, слушая 53 порт. Обязательно отключите к нему доступ из вне с помощью firewall.

2️⃣ Добавляем в /etc/network/interfaces в самый конец:
# source /etc/network/interfaces.d/*

Теперь можно идти в GUI Proxmox, в раздел Datacenter ⇨ SDN ⇨ Zones. Добавляем новую зону типа Simple. Идём в Vnets, добавляем новую сеть, например vm. Имя этой сети будет задавать имя сетевого бриджа, который будет создан в системе. Выбираем созданную сеть и добавляем к ней подсеть. Например, 10.200.0.0/24, шлюз 10.200.0.1, в SNAT ставим галочку. Во вкладке DHCP Ranges указываете диапазон IP адресов, которые будут назначаться виртуалкам с этой сетью.

Когда внесёте все настройки, возвращайтесь в раздел SDN и нажимайте на кнопку Apply, чтобы изменения применились. А теперь рассказываю, что конкретно происходит после создания этих настроек.

После того, как вы создали сеть в Vnets, в файле конфигураций /etc/network/interfaces.d/sdn появятся настройки обычного сетевого бриджа Linux. Если при создании сети вы выбрали использование SNAT, к параметрам бриджа добавятся правила для iptables, типа таких:

post-up iptables -t nat -A POSTROUTING -s '10.200.0.0/24' -o inet0 -j SNAT --to-source 214.42.6.135
post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1

При этом сам бридж уже будет в системе с указанным названием. В качестве IP адреса у него будет настроен адрес шлюза, который вы указали в настройках Subnet.

Для созданной зоны, в которую входит сеть, будет создана отдельная директория с настройками dnsmasq в /etc/dnsmasq.d/, а диапазон выбранных ip адресов будет указан в отдельном файле конфигурации с именем сети:

dhcp-option=tag:vmlocal-10.200.0.0-24,option:router,10.200.0.1
dhcp-range=set:vmlocal-10.200.0.0-24,10.200.0.0,static,255.255.255.0,infinite
interface=vm

Там же будут и привязки MAC адресов к IP. Вот в общем-то и всё. Реализовано всё довольно просто и удобно. Никакой уличной магии и собственных костылей. Взяли известные инструменты и добавили управление ими через веб интерфейс. Единственно, чего не хватает, непосредственно локального DNS сервера. Не знаю, почему от dnsmasq взяли только DHCP. Возможности настройки локального DNS сервера в GUI нет. Хотя ничто не мешает добавить их руками в dnsmasq.

При создании VM вы можете добавить созданную сеть в качестве сетевого интерфейса. После загрузки система получит IP адрес в соответствии с настройками подсети. И если вы включили SNAT, то у неё сразу будет доступ в интернет.

Для меня пока остался нерешённым один важный момент. Как аккуратно связать свои настройки iptables с настройками, которые делает SDN. Это нужно, потому что встроенный firewall по прежнему не умеет пробрасывать порты в VM. Технически то это не трудно, надо просто понять, как это сделать максимально удобно. Я привык их хранить в отдельном скрипте и подгружать при старте сервера. Пока просто вручную добавил туда правила от SDN.

Подводя итог, можно сказать, что теперь настроить гипервизор в качестве шлюза для виртуальных машин можно полностью в GUI. Получив в качестве бонуса интегрированный в веб интерфейс IPAM. И это я разобрал только самый простой вариант — Simple Zone для создания виртуальной сети в рамках одного гипервизора. Остальные настройки ещё более масштабные.

#proxmox

Разберу ещё один объёмный вопрос из собеседований специалистов со знанием Linux, то бишь девопсов и линукс админов. Он хорошо показывает обзорное знание системы, так как затрагивает многие её инструменты.

Как и где посмотреть список регулярно выполняемых заданий в ОС на базе Linux?

📌 Начнём с традиционного cron. Его задания раскиданы по всей системе. Смотреть их надо в:

- /etc/crontab
- /etc/cron.d/
- /etc/cron.daily/, /etc/cron.hourly/, /etc/cron.monthly/

Это условно можно отнести к системным файлам конфигурации. Есть ещё пользовательские в /var/spool/cron/crontabs. Смотреть их можно как напрямую, открывая текстовые файлы, так и командой:

# crontab -u user01 -l

У каждого пользователя будет свой файл с задачами.

📌 Переходим к systemd timers. Это сейчас база для современных ОС, так что вполне уместно начинать именно с них. Там сейчас все системные повторяемые задачи, типа logrotate, apt-daily, anacron и т.д. Посмотреть список всех таймеров:

# systemctl list-timers --all

Только активных:

# systemctl list-timers

Более подробная информация о таймерах:

# systemctl status *timer

📌 И ещё один инструмент для запланированных задач — at. Это очень старая утилита для выполнения разовых запланированных задач. Раньше она была частью базовой системы, так как я лично ей пользовался. Проверил в Debian 11 и 12, в системе её уже нет. А, например, в Centos 7 и 8 (форках RHEL) всё ещё есть. В общем, про неё легко забыть, так как мало кто знает и пользуется, но для общего образования знать не помешает. Её могут использовать какие-то зловреды, чтобы добавлять свои задания, потому что там их будут искать в последнюю очередь.

Посмотреть очередь задач at:

# atq

Пример добавления задачи на выключение системы:

# echo "shutdown -h now" | at -m 10:20

Задачи хранятся в текстовых файлах в директории /var/spool/cron/atjobs/или /var/spool/at/. Одно из напрашивающихся применений этой утилиты — разовая задача на восстановление правил firewall через короткий промежуток времени после применения новых. Ставите задачу на восстановление старых правил, применяете новые. Если связь потеряли, через 3 минуты будут восстановлены старые правила. Если всё ОК, то сами отключаете задачу на восстановление.

#linux

​​Вчера посмотрел короткое видео на тему тормозов php сайта. В данном примере это был Битрикс, но проблема была не в нём, а в настройках веб сервера. Мне понравился способ решения проблемы с помощью perf, поэтому решил его отдельно разобрать текстом:

▶️ Причина торможения PHP в Битриксе

Обращаю внимание на автора ролика. Он ведёт открытые уроки в Rebrain и Otus. У Отус видел его преподавателем на некоторых курсах.

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

Автор взял инструмент для профилирования нагрузки perf:

# apt install linux-perf
# yum install perf

И просто запустил его встроенный топ:

# perf top

Там увидел профиль библиотеки libphp7.so, которая отвечает за исполнение php кода. Зашёл в её подробности и там увидел, что существенную нагрузку даёт исполнение функции php_pcre_exec. Я пишу подробно, потому что повторил всё то же самое на одном из своих нагруженных сайтов на Битриксе.

Исходя из этой информации автор предположил, что причина катастрофического падения производительности как-то связана с модулем php pcre. На деле так и вышло. Этот модуль был по какой-то причине отключен (хотя по умолчанию он должен быть включен, кто-то побаловался с настройками), что и приводило к жутким тормозам. Когда его включили, сайт заработал нормально.

Я обратил внимание на это видео, потому что понравилось простое и быстрое решение. Не думал, что perf может так быстро помочь. Обычно с его помощью снимают полные стек-трейсы, в которых смогут разобраться не только лишь все. Нужны глубокие знания в системных вызовах Linux, функциях ядра, аппаратных счётчиках и т.д. Я, к примеру, особо в этом не разбираюсь, поэтому и не смотрю. Но в данном примере perf довольно быстро и легко помог решить проблему. Берите на вооружение.

#perfomance