Смотрите, какой прикол. Не знал, что такое в принципе возможно. В голом терминале можно ходить по современным сайтам, даже с подключением по SSH. Причём они выглядят так, что сразу и не поймёшь, что смотришь в терминале. Только картинки выдают, да и то не сразу.
Carbonyl собран на базе Chromium. Он даже видео c ютуба проигрывает. Правда, если подключился к голому серверу по SSH, то звука, очевидно, не будет.
Не знаю, кому и зачем приходит в голову подобное разрабатывать и поддерживать. У кого-то есть идеи, зачем это может пригодиться?
⇨ Исходники
#разное
# docker run --rm -ti fathyb/carbonyl https://google.comCarbonyl собран на базе Chromium. Он даже видео c ютуба проигрывает. Правда, если подключился к голому серверу по SSH, то звука, очевидно, не будет.
Не знаю, кому и зачем приходит в голову подобное разрабатывать и поддерживать. У кого-то есть идеи, зачем это может пригодиться?
⇨ Исходники
#разное
Для тех, кто сам настраивает и обслуживает почтовые сервера, хочу предложить удобный инструмент для диагностики - Swaks (Swiss Army Knife for SMTP). В нём нет чего-то особенного, что вы не смогли бы выполнить с помощью прямых запросов через telnet. Но со swaks удобнее, быстрее и проще, и при этом вы видите полный лог общения с почтовым сервером, как если бы вы с ним общались по telnet.
Утилита есть в стандартных репозиториях популярных систем, так что с установкой никаких проблем:
Можете сразу же проверить свой сервер на возможность отправки сообщений без аутентификации:
Корректно настроенный сервер должен вернуть ошибку, причём её код будет зависеть от конкретных настроек почтового сервера. А вот реальная отправка письма с аутентификацией. Пароль будет запрошен в консоли:
С помощью похожего запроса можно удобно проверить поддерживаемые методы аутентификации. Например, CRAM-MD5:
Сервер ответил, что подобный механизм аутентификации не поддерживает.
Если не хочется каждый раз указывать данные аутентификации, их можно добавить в файл
Чтобы программа приняла этот файл, у него должен быть доступ только для пользователя, от которого вы запускаете программу.
В качестве тела письма можно использовать текстовый файл. Это удобно, если нужно проверить работу антивируса или антиспама. К примеру, берём файл EICAR-Test-File, на который все антивирусы дают реакцию, как на вирус, и отправляем его содержимое письмом:
Gmail не принял письмо: "552 5.7.0 This message was blocked because its content presents a potential security issue."
Тело письма можно и сразу в консоли передать через ключ
В общем, инструмент простой, универсальный, интуитивно понятный. Автор поддерживает и регулярно обновляет. Можно использовать и в каких-то велосипедах на bash. Swaks умеет работать через различные прокси, использовать tls сертификаты с выбором шифров и некоторых настроек.
⇨ Исходники
#mailserver
Утилита есть в стандартных репозиториях популярных систем, так что с установкой никаких проблем:
# 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.txtGmail не принял письмо: "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 есть файл конфигурации
После этого службу надо перезапустить:
Если где-то ошиблись, можно зайти по SSH и внести изменения. Подключение по SSH намного безопаснее открытого веб интерфейса, так что за SSH можно сильно не переживать. А вот веб интерфейс мне всегда стрёмно оставлять в открытом доступе.
Помимо настройки доступа с помощью этого файла конфигурации можно выполнить и другие полезные настройки. Например, явно указать сетевой адрес, на котором веб интерфейс будет принимать соединения.
Также там можно переназначить дефолтные tls сертификаты. Это удобно, если вы используете свои. Все эти возможности описаны в документации.
#proxmox
Если сервер настраивал не я, и тем более если к серверу нет доступа напрямую в консоль, настраивать 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
Я в своё время уже разбирал работу 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 из практики, которыми пользуюсь сам.
📌 Посмотреть размер баз данных на сервере с сортировкой по размеру в мегабайтах:
📌 Посмотреть размер конкретной базы данных:
📌 Посмотреть размер самых больших таблиц в базе данных:
📌 Удалить все таблицы в базе данных, не удаляя саму базу. То есть полная очистка базы без удаления:
Последнюю команду посоветовали в комментариях к заметке, где я то же самое делаю своими костылями на bash. На самом деле эта, казалось бы простая задача, на деле не такая уж и простая. Я себе сохранил предложенный вариант. Он удобнее и проще моего.
Сами понимаете, что это идеальная заметка для того, чтобы её сохранить и использовать, когда будете работать с mysql.
#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 есть большой набор различных тем. Живут они в
Если тема понравилась, то можно установить её по умолчанию. Для этого нужно выключить MC, открыть файл конфигурации
на
Теперь MC будет запускаться с выбранной темой. Если выбираете тему с 256 цветами, то убедитесь, что ваш терминал поддерживает 256 цветов. Настроить это можно в
Если регулярно пользуетесь файловым менеджером, то разные темы могут служить дополнительным отличием разных классов серверов, либо пользователей в них. Их можно различать в том числе и по этому изменяемому признаку.
Сам я обычно оставляю тему по умолчанию. Но после того, как написал эту заметку, решил поменять у себя в WSL тему на xoria256.
❗️Ну и раз уж речь зашла о MC, добавлю информацию о настройке, которую я делаю всегда по умолчанию сразу после установки этого пакета на сервере:
Я копирую правила подсветки синтаксиса для файлов
Большие лог файлы иногда начинают подтормаживать при открытии с подсветкой. Тогда она быстро отключается комбинацией клавиш Ctrl + S.
#linux #mc
В составе пакета 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
У вас уже могут быть указаны какие-то другие значения. Новые добавьте через пробел. Изначально их вообще может не быть, а параметр указан вот так:
Или могут быть какие-то другие значения:
После этого нужно обновить загрузчик. В зависимости от дистрибутива, это может выглядеть по-разному. В deb дистрибутивах то выглядит так:
В rpm уже точно не помню, специально не проверял, но вроде бы раньше это выглядело так:
Как в современных версиях уже не знаю, так как не использую их.
После этого нужно везде в сетевых настройках изменить имена интерфейсов со старых на новые. Для Debian достаточно отредактировать
Теперь можно перезагружать сервер. Загрузится он со старыми названиями сетевых интерфейсов.
Попутно задам вопрос, на который у меня нет ответа. Я не понимаю, почему в некоторых виртуалках по умолчанию используется старое именование сетевых интерфейсов, а в некоторых новое. Причём, это не зависит от версии ОС. У меня прямо сейчас есть две одинаковые Debian 11, где на одной eth0, а на другой ens18. Первая на HyperV, вторая на Proxmox. Подозреваю, что это зависит от типа эмулируемой сетевухи и драйвера, который используется в системе.
#linux #network
Итак, если вам хочется вернуть старое именование интерфейсов, то в файле конфигурации 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 больше брать не буду. Этот в прошлом качественный бренд полностью выродился.
Но и отговаривать тоже кого-то не буду, если попадётся это бушное железо в нормальном состоянии. За исключением перечисленных минусов, каких-то более значительных проблем с ним я не видел. Качество исполнения всего остального нормальное. Хороший механизм открытия экрана, удобный тачпад с жестами, сканер отпечатков пальцев. Я только на этом ноуте стал им пользоваться.
#железо
- Конкретные советы моделей для рабочего ноутбука админа
- Плюсы и минусы 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)
#топ
Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые возможности по настройке (не только публикацию историй):
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 файл примерно такого содержания:
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
Вообще, у программы много различных возможностей. Я использовал только одно — передача параметров rdp подключения в виде параметров командной строки. Выглядело это так:
1️⃣ Скачиваем программу rdp.exe, которая запускается без установки.
2️⃣ Рядом кладём rdp.bat файл примерно такого содержания:
rdp.exe /v:10.20.1.27 /u:user /p:password3️⃣ Отправляем пользователю архив с 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
▶️ 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️⃣ Устанавливаем дополнительные пакеты и запускаем службу:
Dnsmasq заработает на всех интерфейсах, слушая 53 порт. Обязательно отключите к нему доступ из вне с помощью firewall.
2️⃣ Добавляем в
Теперь можно идти в GUI Proxmox, в раздел Datacenter ⇨ SDN ⇨ Zones. Добавляем новую зону типа Simple. Идём в Vnets, добавляем новую сеть, например
Когда внесёте все настройки, возвращайтесь в раздел SDN и нажимайте на кнопку Apply, чтобы изменения применились. А теперь рассказываю, что конкретно происходит после создания этих настроек.
После того, как вы создали сеть в Vnets, в файле конфигураций
При этом сам бридж уже будет в системе с указанным названием. В качестве IP адреса у него будет настроен адрес шлюза, который вы указали в настройках Subnet.
Для созданной зоны, в которую входит сеть, будет создана отдельная директория с настройками dnsmasq в
Там же будут и привязки MAC адресов к IP. Вот в общем-то и всё. Реализовано всё довольно просто и удобно. Никакой уличной магии и собственных костылей. Взяли известные инструменты и добавили управление ими через веб интерфейс. Единственно, чего не хватает, непосредственно локального DNS сервера. Не знаю, почему от dnsmasq взяли только DHCP. Возможности настройки локального DNS сервера в GUI нет. Хотя ничто не мешает добавить их руками в dnsmasq.
При создании VM вы можете добавить созданную сеть в качестве сетевого интерфейса. После загрузки система получит IP адрес в соответствии с настройками подсети. И если вы включили SNAT, то у неё сразу будет доступ в интернет.
Для меня пока остался нерешённым один важный момент. Как аккуратно связать свои настройки iptables с настройками, которые делает SDN. Это нужно, потому что встроенный firewall по прежнему не умеет пробрасывать порты в VM. Технически то это не трудно, надо просто понять, как это сделать максимально удобно. Я привык их хранить в отдельном скрипте и подгружать при старте сервера. Пока просто вручную добавил туда правила от SDN.
Подводя итог, можно сказать, что теперь настроить гипервизор в качестве шлюза для виртуальных машин можно полностью в GUI. Получив в качестве бонуса интегрированный в веб интерфейс IPAM. И это я разобрал только самый простой вариант — Simple Zone для создания виртуальной сети в рамках одного гипервизора. Остальные настройки ещё более масштабные.
#proxmox
Если вы обновили до 8.1 с прошлых релизов, то необходимо выполнить подготовительные действия.
1️⃣ Устанавливаем дополнительные пакеты и запускаем службу:
# apt update# apt install libpve-network-perl dnsmasq# systemctl enable --now dnsmasqDnsmasq заработает на всех интерфейсах, слушая 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.135post-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.1dhcp-range=set:vmlocal-10.200.0.0-24,10.200.0.0,static,255.255.255.0,infiniteinterface=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. Его задания раскиданы по всей системе. Смотреть их надо в:
Это условно можно отнести к системным файлам конфигурации. Есть ещё пользовательские в
У каждого пользователя будет свой файл с задачами.
📌 Переходим к systemd timers. Это сейчас база для современных ОС, так что вполне уместно начинать именно с них. Там сейчас все системные повторяемые задачи, типа logrotate, apt-daily, anacron и т.д. Посмотреть список всех таймеров:
Только активных:
Более подробная информация о таймерах:
📌 И ещё один инструмент для запланированных задач — at. Это очень старая утилита для выполнения разовых запланированных задач. Раньше она была частью базовой системы, так как я лично ей пользовался. Проверил в Debian 11 и 12, в системе её уже нет. А, например, в Centos 7 и 8 (форках RHEL) всё ещё есть. В общем, про неё легко забыть, так как мало кто знает и пользуется, но для общего образования знать не помешает. Её могут использовать какие-то зловреды, чтобы добавлять свои задания, потому что там их будут искать в последнюю очередь.
Посмотреть очередь задач at:
Пример добавления задачи на выключение системы:
Задачи хранятся в текстовых файлах в директории
#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:
И просто запустил его встроенный топ:
Там увидел профиль библиотеки libphp7.so, которая отвечает за исполнение php кода. Зашёл в её подробности и там увидел, что существенную нагрузку даёт исполнение функции php_pcre_exec. Я пишу подробно, потому что повторил всё то же самое на одном из своих нагруженных сайтов на Битриксе.
Исходя из этой информации автор предположил, что причина катастрофического падения производительности как-то связана с модулем php pcre. На деле так и вышло. Этот модуль был по какой-то причине отключен (хотя по умолчанию он должен быть включен, кто-то побаловался с настройками), что и приводило к жутким тормозам. Когда его включили, сайт заработал нормально.
Я обратил внимание на это видео, потому что понравилось простое и быстрое решение. Не думал, что perf может так быстро помочь. Обычно с его помощью снимают полные стек-трейсы, в которых смогут разобраться не только лишь все. Нужны глубокие знания в системных вызовах Linux, функциях ядра, аппаратных счётчиках и т.д. Я, к примеру, особо в этом не разбираюсь, поэтому и не смотрю. Но в данном примере perf довольно быстро и легко помог решить проблему. Берите на вооружение.
#perfomance
▶️ Причина торможения 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
Делал сегодня чистую установку системы Debian 12 и очень удивился, когда установив htop, увидел у него новую вкладку I/O. Потёр глаза, посмотрел повнимательнее. Реально новая вкладка. Сразу понял, как на неё переключиться - с помощью клавиши tab. На вкладке показана нагрузка на диск каждого сервиса.
Htop - это утилита, которую я по умолчанию ставлю на все сервера, которые настраиваю, как замену стандартному top. Я вижу её каждый день. Но сегодня впервые увидел эту вкладку. Для проверки открыл несколько других серверов, на которых бываю регулярно, там этой вкладки нет. То есть это не я такой невнимательный. Её реально раньше не было.
Полез искать в инете информацию и узнал, что, начиная с версии 3.2.0, появилась настройка (войти по F2) Show tabs for screen, которая включает эту вкладку с I/O. В Debian 12 из базового репозитория ставится версия 3.2.2 и там эта опция включена по умолчанию. Увидел мнение, что якобы последнее время активно ведётся разработка и развитие htop.
Такое вот полезное нововведение. Обновляйте или ставьте htop, если ещё не поставили и пользуйтесь новыми возможностями. Они реально полезны и заменяют многие консольные утилиты, которые показывают примерно то же самое.
Это только я такой слоупок? Вы знали об этом нововведении?
#linux #htop
Htop - это утилита, которую я по умолчанию ставлю на все сервера, которые настраиваю, как замену стандартному top. Я вижу её каждый день. Но сегодня впервые увидел эту вкладку. Для проверки открыл несколько других серверов, на которых бываю регулярно, там этой вкладки нет. То есть это не я такой невнимательный. Её реально раньше не было.
Полез искать в инете информацию и узнал, что, начиная с версии 3.2.0, появилась настройка (войти по F2) Show tabs for screen, которая включает эту вкладку с I/O. В Debian 12 из базового репозитория ставится версия 3.2.2 и там эта опция включена по умолчанию. Увидел мнение, что якобы последнее время активно ведётся разработка и развитие htop.
Такое вот полезное нововведение. Обновляйте или ставьте htop, если ещё не поставили и пользуйтесь новыми возможностями. Они реально полезны и заменяют многие консольные утилиты, которые показывают примерно то же самое.
Это только я такой слоупок? Вы знали об этом нововведении?
#linux #htop
Протокол ipv6 получил уже довольно широкое распространение по миру. Но конкретно в нашей стране, а тем более в локальной инфраструктуре он присутствует примерно нигде. По крайней мере я ни сам не видел его, ни упоминания о том, что кто-то использует его в своих локальных сетях. В этом просто нет смысла. Это в интернете заканчиваются IP адреса, а не в наших локалках.
С такими вводными оставлять включенным протокол ipv6 не имеет большого смысла. Его надо отдельно настраивать, следить за безопасностью, совместимостью и т.д. Как минимум, надо не забывать настраивать файрвол для него. Если ipv6 вам не нужен, то логично его просто отключить. В Linux это можно сделать разными способами:
1. Через настройки sysctl.
2. Через параметры GRUB.
3. Через сетевые настройки конкретного интерфейса.
Я не знаю, какой из них оптимальный.
В разное время и в разных ситуациях я действую по обстоятельствам. Если система уже настроена и введена в эксплуатацию, то системные настройки трогать уже не буду. Просто отключу на всех сервисах, что слушают ipv6 интерфейс, его работу.
Если же система только настраивается, то можно в GRUB отключить использование ipv6. Это глобальный метод, который гарантированно отключает во всей системе ipv6. Для этого в его конфиг (
После этого нужно обновить загрузчик. В зависимости от системы выглядеть это может по-разному:
Первые три варианта с большей вероятностью подойдут для deb дистрибутивов (для Debian 12 точно подойдут), последняя для rpm. Лучше отдельно уточнить этот момент для вашей системы.
После этого нужно перезагрузить систему и проверить результат. В настройках сетевых интерфейсов не должно быть ipv6 адресов, как и в открытых портах:
Для Windows такую рекомендацию не могу дать, так как слышал информацию, что отключение ipv6 там может привести к проблемам с системой. Так что лучше этот протокол не трогать. Деталей не знаю, подробно не изучал тему, но что-то там ломается без ipv6.
Отключаете у себя ipv6?
#linux #network #ipv6
С такими вводными оставлять включенным протокол ipv6 не имеет большого смысла. Его надо отдельно настраивать, следить за безопасностью, совместимостью и т.д. Как минимум, надо не забывать настраивать файрвол для него. Если ipv6 вам не нужен, то логично его просто отключить. В Linux это можно сделать разными способами:
1. Через настройки sysctl.
2. Через параметры GRUB.
3. Через сетевые настройки конкретного интерфейса.
Я не знаю, какой из них оптимальный.
В разное время и в разных ситуациях я действую по обстоятельствам. Если система уже настроена и введена в эксплуатацию, то системные настройки трогать уже не буду. Просто отключу на всех сервисах, что слушают ipv6 интерфейс, его работу.
Если же система только настраивается, то можно в GRUB отключить использование ipv6. Это глобальный метод, который гарантированно отключает во всей системе ipv6. Для этого в его конфиг (
/etc/default/grub), конкретно в параметр GRUB_CMDLINE_LINUX, нужно добавить значение ipv6.disable=1. Если там уже указаны другие значения, то перечислены они должны быть через пробел. Примерно так:GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet ipv6.disable=1"После этого нужно обновить загрузчик. В зависимости от системы выглядеть это может по-разному:
# dpkg-reconfigure grub-pc# update-grub# grub-mkconfig -o /boot/grub/grub.cfg# grub2-mkconfig -o /boot/grub2/grub.cfgПервые три варианта с большей вероятностью подойдут для deb дистрибутивов (для Debian 12 точно подойдут), последняя для rpm. Лучше отдельно уточнить этот момент для вашей системы.
После этого нужно перезагрузить систему и проверить результат. В настройках сетевых интерфейсов не должно быть ipv6 адресов, как и в открытых портах:
# ip a# ss -tulnpДля Windows такую рекомендацию не могу дать, так как слышал информацию, что отключение ipv6 там может привести к проблемам с системой. Так что лучше этот протокол не трогать. Деталей не знаю, подробно не изучал тему, но что-то там ломается без ipv6.
Отключаете у себя ipv6?
#linux #network #ipv6
Освоить синтаксис регулярных выражений – непростая задача. Не то, чтобы она очень сложная, но не так много людей работают с ними постоянно. Большинству сисадминов и девопсов они нужны время от времени для разовых задач. В связи с этим сильно погружаться в них и разбираться зачастую не имеет смысла. Через полгода отсутствия практики всё забудешь.
Предлагаю запомнить, если ещё не запомнили, несколько простых вещей, которые требуются более-менее регулярно. По крайней мере я их помню. Покажу на примере парсинга вывода команды
🟢 В регулярных выражениях используются так называемые якоря, или анкоры. Наиболее часто встречающиеся:
Если убрать
Регулярно залетаю в бан на своём сайте, когда тестирую что-то. Команду на разбан всегда подсматриваю.
Оба анкора вместе
🟢 Далее стоит знать специальные символы
Можно заменить переход на новую строку пробелом или удалить все табуляции:
или просто
Удаляем табы:
🟢 Часто приходится использовать оператор или в виде прямой черты
Выведет все строки, где встречается либо postfix, либо dovecot. Здесь же я сразу упомянул ещё один специальный символ регулярных выражений, который занимается экранированием -
И поиск нормально сработает. Дело в том, что у регулярных выражений существуют разные диалекты. Ключ
В общем-то, это всё, что лично я помню. Если нужно использовать шаблоны, диапазоны, условия, открываю шпаргалки. Сходу правильно написать регулярку у меня не получится.
📌 Полезные ссылки по теме:
▪️ regex101.com — проверка регулярных выражений
▪️ grex — автоматическое составление регулярок
▪️ regexper.com — схематическое изображение регулярок
▪️ ihateregex.io — готовые примеры регулярных выражений
▪️ autoregex.xyz — построение регулярок с помощью ИИ
▪️ stepik.org — бесплатный курс для изучения регулярок
▪️ regexlearn.com — обучение regex на русском языке
#regex
Предлагаю запомнить, если ещё не запомнили, несколько простых вещей, которые требуются более-менее регулярно. По крайней мере я их помню. Покажу на примере парсинга вывода команды
history. Это подходящий вариант для демонстрации. 🟢 В регулярных выражениях используются так называемые якоря, или анкоры. Наиболее часто встречающиеся:
^ - начало строки, $ - конец. Сразу пример. Допустим, мы когда-то использовали certbot в консоли. Если сделать grep по этому имени, то вылезут строки, где мы его устанавливали или запускали службу с таким именем, где смотрели логи и т.д. А нам нужна команда, которая в консоли начиналась с certbot:# grep '^certbot' ~/.bash_historycertbot certonlyЕсли убрать
^, то будут выведены все строки, в которых где угодно встречалось слово certbot. То же самое, только с концом строки. Выведу команду, где в конце указан IP адрес:# grep '75.35.224.135$' ~/.bash_historyfail2ban-client set nginx-limit-conn unbanip 75.35.224.135Регулярно залетаю в бан на своём сайте, когда тестирую что-то. Команду на разбан всегда подсматриваю.
Оба анкора вместе
^$ означают пустую строку. Удобно использовать для чистки конфигов, логов от пустых строк.🟢 Далее стоит знать специальные символы
\n - новая строка, \t - табуляция. Это бывает нужно, когда стоит задача удалить эти табуляции, или наоборот добавить. Примерно так:# echo -e '\tThis is line with tab' >> file.txt# echo -e '\nThis is new line' >> file.txtМожно заменить переход на новую строку пробелом или удалить все табуляции:
# cat file.txt | tr '\n' ' ' или просто
# tr '\n' ' ' < file.txtУдаляем табы:
# tr -d '\t' < file.txt🟢 Часто приходится использовать оператор или в виде прямой черты
|. Это прям самое популярное из регулярок. Грепаем что-то с набором условий:# grep 'postfix\|dovecot' ~/.bash_historyВыведет все строки, где встречается либо postfix, либо dovecot. Здесь же я сразу упомянул ещё один специальный символ регулярных выражений, который занимается экранированием -
\. Если его не поставить, то grep будет искать буквально фразу postfix|dovecot и ничего не найдёт. Но при этом можно сделать вот так:# grep -E "postfix|dovecot" ~/.bash_historyИ поиск нормально сработает. Дело в том, что у регулярных выражений существуют разные диалекты. Ключ
-E включает реализацию Extended Regular Expression (ERE), где получается всё наоборот. Метасимвол или | экранировать не надо. А вот если мы хотим найти слово с этим символом, то нам его надо экранировать. По умолчанию grep использует диалект Basic Regular Expressions (BRE). Всё это зачастую добавляет путаницу и приходится постоянно пробовать, то так, то эдак экранировать, когда использует разные утилиты и перенаправления потоков.В общем-то, это всё, что лично я помню. Если нужно использовать шаблоны, диапазоны, условия, открываю шпаргалки. Сходу правильно написать регулярку у меня не получится.
📌 Полезные ссылки по теме:
▪️ regex101.com — проверка регулярных выражений
▪️ grex — автоматическое составление регулярок
▪️ regexper.com — схематическое изображение регулярок
▪️ ihateregex.io — готовые примеры регулярных выражений
▪️ autoregex.xyz — построение регулярок с помощью ИИ
▪️ stepik.org — бесплатный курс для изучения регулярок
▪️ regexlearn.com — обучение regex на русском языке
#regex
До появления Proxmox Backup Server я часто отдавал предпочтение при выборе гипервизора Hyper-V из-за того, что для Proxmox VE не было функционального инструмента для бэкапов VM, кроме его встроенного средства, которое делало только полные бэкапы.
С выходом PBS этот вопрос был закрыт, причём бескомпромиссно. Предложенное решение было лучше, чем любое другое бесплатное. Так что связка Proxmox VE + PBS аналогов сейчас не имеет по удобству, простоте настройки и эксплуатации.
Отдельно отметить и рассказать более подробно я хочу про Proxmox Backup Client. Это консольная утилита для Linux, которая позволяет делать бэкап на уровне файлов из виртуальной машины в PBS, даже если система находится на другом гипервизоре. То есть это полностью отвязанный от инфраструктуры Proxmox клиент, который позволяет складывать резервные копии в PBS. Таким образом этот сервер бэкапов может объединять в себе разнородную инфраструктуру.
Сразу перечислю основные ограничения этого клиента:
▪ бэкап только на уровне файлов или образов дисков, не системы целиком;
▪ официальная поддержка только deb дистрибутивов, для rpm люди сами собирают пакеты, так как исходники открыты;
▪ нет поддержки windows, вариант бэкапа данных оттуда только один - монтирование диска по smb к linux машине и бэкап этого примонтированного диска.
Использовать proxmox-backup-client очень просто. Я не буду подробно описывать его возможности, так как в оригинальной документации представлена исчерпывающая информация. Если хочется на русском, то можно обратиться к документации от altlinux. Кратко покажу пример установки и бэкапа.
Ставим Proxmox Backup Client на Debian:
Вставляем туда для Debian 12
Для Debian 11:
Для Debian 10:
Ставим клиента:
Теперь бэкапим корень сервера без примонтированных дисков. То есть делаем бэкап системы:
Здесь мы указали:
◽root.pxar - имя архива в формате pbs
◽/ - бэкапим корень системы
◽10.20.1.47 - адрес pbs сервера
◽main - имя datastore
По умолчанию используется учётная запись root@pam, то есть дефолтный админ. Разумеется, на проде так делать не надо, потому что у него полные права, в том числе на удаление архивов. Делайте отдельные учётки для разных систем с ограниченными правами. В PBS это организовано удобно и просто, так что разобраться не трудно. Для указания имени пользователя, нужно использовать такой вид репозитория:
Для того, чтобы не вводить пароль пользователя вручную, можно задать его через переменную окружения
Смотреть содержимое бэкапов можно как через веб интерфейс, так и тут локально. Причём бэкап можно примонтировать через fuse. Сморим снэпшоты и выбираем любой для монтирования:
Очень быстро и удобно. При желании бэкапы можно шифровать.
#proxmox #backup
С выходом PBS этот вопрос был закрыт, причём бескомпромиссно. Предложенное решение было лучше, чем любое другое бесплатное. Так что связка Proxmox VE + PBS аналогов сейчас не имеет по удобству, простоте настройки и эксплуатации.
Отдельно отметить и рассказать более подробно я хочу про Proxmox Backup Client. Это консольная утилита для Linux, которая позволяет делать бэкап на уровне файлов из виртуальной машины в PBS, даже если система находится на другом гипервизоре. То есть это полностью отвязанный от инфраструктуры Proxmox клиент, который позволяет складывать резервные копии в PBS. Таким образом этот сервер бэкапов может объединять в себе разнородную инфраструктуру.
Сразу перечислю основные ограничения этого клиента:
▪ бэкап только на уровне файлов или образов дисков, не системы целиком;
▪ официальная поддержка только deb дистрибутивов, для rpm люди сами собирают пакеты, так как исходники открыты;
▪ нет поддержки windows, вариант бэкапа данных оттуда только один - монтирование диска по smb к linux машине и бэкап этого примонтированного диска.
Использовать proxmox-backup-client очень просто. Я не буду подробно описывать его возможности, так как в оригинальной документации представлена исчерпывающая информация. Если хочется на русском, то можно обратиться к документации от altlinux. Кратко покажу пример установки и бэкапа.
Ставим Proxmox Backup Client на Debian:
# wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg# mcedit /etc/apt/sources.list.d/pbs-client.listВставляем туда для Debian 12
deb http://download.proxmox.com/debian/pbs-client bookworm mainДля Debian 11:
deb http://download.proxmox.com/debian/pbs-client bullseye mainДля Debian 10:
deb http://download.proxmox.com/debian/pbs-client buster mainСтавим клиента:
# apt update && apt install proxmox-backup-clientТеперь бэкапим корень сервера без примонтированных дисков. То есть делаем бэкап системы:
# proxmox-backup-client backup root.pxar:/ --repository 10.20.1.47:mainЗдесь мы указали:
◽root.pxar - имя архива в формате pbs
◽/ - бэкапим корень системы
◽10.20.1.47 - адрес pbs сервера
◽main - имя datastore
По умолчанию используется учётная запись root@pam, то есть дефолтный админ. Разумеется, на проде так делать не надо, потому что у него полные права, в том числе на удаление архивов. Делайте отдельные учётки для разных систем с ограниченными правами. В PBS это организовано удобно и просто, так что разобраться не трудно. Для указания имени пользователя, нужно использовать такой вид репозитория:
user01@pbs@10.20.1.47. То есть мы указали созданного вручную пользователя user01@pbs.Для того, чтобы не вводить пароль пользователя вручную, можно задать его через переменную окружения
PBS_PASSWORD. Смотреть содержимое бэкапов можно как через веб интерфейс, так и тут локально. Причём бэкап можно примонтировать через fuse. Сморим снэпшоты и выбираем любой для монтирования:
# proxmox-backup-client snapshot list --repository 10.20.1.47:main# proxmox-backup-client mount host/debian12-vm/2024-02-06T19:19:12Z root.pxar --repository 10.20.1.47:main /mnt/backupОчень быстро и удобно. При желании бэкапы можно шифровать.
#proxmox #backup
На днях столкнулся с ошибкой в эксплуатации и настройке MySQL сервера, о которой решил написать, чтобы самому не забыть решение, и с вами поделиться. Тема довольно распространённая, теория по которой будет полезна всем, кто работает с этой СУБД.
В MySQL есть настройка innodb_temp_data_file_path, которая отвечает за управление временным табличным пространством (temporary tablespace). Это место, где временно хранятся данные на протяжении сеанса пользователя, потом очищаются. В основном это пространство используется для операций сортировки, может чего-то ещё. Точно я не знаю.
По умолчанию этот параметр имеет значение autoextend и в некоторых случаях при такой настройке файл
Тут указано, что создаётся файл изначального размера 12 мегабайт с автоматическим увеличением до 2 гигабайт. Заранее предсказать, какого максимального объёма будет достаточно, трудно. Это зависит от многих факторов. Я такую настройку сделал несколько лет назад на одном сервере, который на днях засбоил.
Проблемы выражались в том, что существенно увеличилась запись на диск. Об этом отрапортовал Zabbix. Посмотрел статистику этой VM на гипервизоре, тоже видно, что нагрузка на диск выросла. В самой VM в логе MySQL примерно в то же время стали появляться ошибки:
Меня они сначала сбили с толку, так как подумал, что на сервере не хватает места. Но нет, с местом всё в порядке. Стал разбираться дальше и понял, что подобная ошибка означает не только недостаток места на диске, (а при нём будет такая же ошибка) но и нехватку выделенного места под temporary tablespace. Увеличил значение в innodb_temp_data_file_path и перезапустил MySQL сервер. Ошибка ушла, как и повышенная нагрузка на диск.
Это один из тех параметров, на который нужно обращать внимание при настройке MySQL сервера, иначе он может в какой-то момент преподнести сюрприз. Можно этот файл вынести на отдельный диск, или вообще указать 2 разных файла на разных дисках. В процессе написания заметки возникла идея, что может его и в память можно перенести. Но это надо погружаться в тему, чтобы понять, к чему это в итоге приведёт и стоит ли так делать. Если кто-то пробовал, напишите о своём опыте.
#mysql
В MySQL есть настройка innodb_temp_data_file_path, которая отвечает за управление временным табличным пространством (temporary tablespace). Это место, где временно хранятся данные на протяжении сеанса пользователя, потом очищаются. В основном это пространство используется для операций сортировки, может чего-то ещё. Точно я не знаю.
По умолчанию этот параметр имеет значение autoextend и в некоторых случаях при такой настройке файл
ibtmp1, в котором хранятся временные данные, может сожрать всё свободное место на сервере. У меня такое было не раз. Поэтому я всегда ограничиваю этот размер. Выглядит это примерно так:innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:2GТут указано, что создаётся файл изначального размера 12 мегабайт с автоматическим увеличением до 2 гигабайт. Заранее предсказать, какого максимального объёма будет достаточно, трудно. Это зависит от многих факторов. Я такую настройку сделал несколько лет назад на одном сервере, который на днях засбоил.
Проблемы выражались в том, что существенно увеличилась запись на диск. Об этом отрапортовал Zabbix. Посмотрел статистику этой VM на гипервизоре, тоже видно, что нагрузка на диск выросла. В самой VM в логе MySQL примерно в то же время стали появляться ошибки:
[ERROR] /usr/sbin/mysqld: The table '/tmp/#sql_1c6f_1' is fullМеня они сначала сбили с толку, так как подумал, что на сервере не хватает места. Но нет, с местом всё в порядке. Стал разбираться дальше и понял, что подобная ошибка означает не только недостаток места на диске, (а при нём будет такая же ошибка) но и нехватку выделенного места под temporary tablespace. Увеличил значение в innodb_temp_data_file_path и перезапустил MySQL сервер. Ошибка ушла, как и повышенная нагрузка на диск.
Это один из тех параметров, на который нужно обращать внимание при настройке MySQL сервера, иначе он может в какой-то момент преподнести сюрприз. Можно этот файл вынести на отдельный диск, или вообще указать 2 разных файла на разных дисках. В процессе написания заметки возникла идея, что может его и в память можно перенести. Но это надо погружаться в тему, чтобы понять, к чему это в итоге приведёт и стоит ли так делать. Если кто-то пробовал, напишите о своём опыте.
#mysql
Для автоматической проверки Docker образов на уязвимости (CVE) есть хороший open source инструмент Trivy. Год назад я делал по нему пару заметок с обзором и автоматическим исправлением уязвимостей. Потом всё это в небольшую статью оформил.
Этот продукт хорошо дополняет open source утилита Dockle. Она тоже проверяет контейнеры на уязвимости, но помимо этого проверяет образ на соответствие best-practice Dockerfile и рекомендации CIS Docker Benchmarks (#cis).
Использовать очень просто, так как это по сути одиночный бинарник. В репозитории есть пакеты для установки под все популярные системы. Можно запустить и в Docker без установки:
Пример отчёта можно посмотреть на тестовом образе, для которого есть замечания:
С помощью ключа
⇨ Исходники
#docker #devops #cicd #security
Этот продукт хорошо дополняет open source утилита Dockle. Она тоже проверяет контейнеры на уязвимости, но помимо этого проверяет образ на соответствие best-practice Dockerfile и рекомендации CIS Docker Benchmarks (#cis).
Использовать очень просто, так как это по сути одиночный бинарник. В репозитории есть пакеты для установки под все популярные системы. Можно запустить и в Docker без установки:
# docker run --rm goodwithtech/dockle:v0.4.14 [YOUR_IMAGE_NAME]Пример отчёта можно посмотреть на тестовом образе, для которого есть замечания:
# docker run --rm goodwithtech/dockle:v0.4.14 goodwithtech/dockle-test:v2С помощью ключа
-f json вывод можно сохранить в json файле. Dockle легко интегрировать в пайплайн. В репозитории есть примеры (gitlab).⇨ Исходники
#docker #devops #cicd #security
