ssnn --help
Использовать так: ssnn [-hVv] [-p <port>] [--ttl=<ttl>] [-a <admin>]... [--zones=<zones>]... [TYPE=NAME=VALUE]...
Такие есть аргументы.
-h, --help показать подсказку и выйти
-V, --version показать версию и выйти
-v, --verbose расширенный вывод
-p, --port=<port> Номер порта (1024)
--ttl=<ttl> TTL (default: 600)
-a, --admin=<admin> Админ по умолчанию
--zones=<zones> Путь к директории зон (zones)
TYPE=NAME=VALUE Multiple records (e.g., A=test.ru=127.0.0.1)
Запустить на 53 порту можно только с root правами или в Docker контейнере с пробросом порта
sudo ./ssnn --port=53
Через опцию командной строки добавить две ресурсные A-записи для домена test.ru
./ssnn A=test.ru=127.0.0.1 A=test.ru=192.168.0.1
Поддерживаются следующие записи
Тип ресурсной записи
Структура значения
A
список IP адресов, по одной на каждую строку
MX
число адрес-сервера
CNAME
строка
HINFO
список строк ключ;значение
SOA
строка емейла администратора зоны
TXT
список строк длиной до 255 символов
URI
число число урл
Так же опциями запуска можно изменить значение по умолчанию для параметра TTL и емейл администратора всех зон
Настройки зоны можно сохранить в виде иерархии директорий и файлов, представленной в виде:
[D:путь к настройкам]/[D:название ресурсной записи]/[D:ТИП РЕСУРСНОЙ ЗАПИСИ/[F:значение ресурсной записи]
По умолчанию настройки должны размещаться в директории zones либо можно изменить с помощью опции --zones=/etc/ssnn/zones/
После запуска программа анализирует опции запуска и формирует группу хешь-таблиц ресурсных запией,
затем загружаются данные из директории ZONES (при этом замещая ранее определённые записи)
затем сервер переходит в режим обслуживания неблокируемых UDP соединений с DNS клиентами
для внесения изменений в настройки ресурсных записей необходимо изменить данные в хранилища --zones и перезапустить сервер
либо можно отправить серверу сигнал SIGHUP, после получения сигнала сервер заново загружает все данные из хранилища --zones
pkill -q ssnn
По-умолчанию, сервер для каждого домена, после каждой переконфигурации, вычисляет значение SERIAL на основе текущей даты и времени, изменить это поведение можно с помощью создания и редактирования значения в файле SERIAL
Для получения навыка работы в дисковыми устройствами в среде Linux лучше начать экспериментировать в виртуальными устройствами в домашней папке пользователя
Это позволит безопасно для данных и оборудования освоить процессы разметки раздело, создания файловых систем, монтирования, размонтирования, так же лучше понять принципы работы ядра Linux с данными на дисках
Процесс экспериментов сводится к созданию обычного файла в домашней директори, а затем настройка ядра Linux для представления созданного файла как обычного дискового устройства с которым можно проводить безопасные экперименты
Подключить файл как блочное устройство(диск), тут с помощью утилиты losetup ядро получает имя нового виртуального устройства и имя файла, затем ядро связывает эти данные в новое виртуальное устройство
sudo losetup /dev/loop33 test-image
Теперь в директории /dev/ появлось виртуальное устройство /dev/loop33 и с ним можно работать как с обычными диском используя инструменты fdisk cfdisk или gparted
Разметить разделы на новом "диске" под свои тестовые нужны
sudo cfdisk /dev/loop33
Так как структура файла изменилась и на нём появились разделы, необходимо перемонтировать файл-виртуальное устройство
Теперь в директории /dev/ появятся файлы устройств-разделов находящихся в тестовом файле и с ними можно работать как обычными разделами, там можно создавать файловые системы
ffsdmad@basm:~$ sudo mkfs.ext4 /dev/loop33p1
[sudo] пароль для ffsdmad:
mke2fs 1.46.5 (30-Dec-2021)
Discarding device blocks: done
Creating filesystem with 128000 4k blocks and 128000 inodes
Filesystem UUID: d184b921-84f1-4fbe-8e98-729e67fbbfeb
Superblock backups stored on blocks:
32768, 98304
Allocating group tables: done
Сохранение таблицы inod'ов: done
Создание журнала (4096 блоков): готово
Writing superblocks and filesystem accounting information: готово
ffsdmad@basm:~$ sudo mkfs.ext4 /dev/loop33p2
mke2fs 1.46.5 (30-Dec-2021)
Discarding device blocks: done
Creating filesystem with 133888 4k blocks and 33520 inodes
Filesystem UUID: fc175588-43de-4731-973c-875722ed273f
Superblock backups stored on blocks:
32768, 98304
Allocating group tables: done
Сохранение таблицы inod'ов: done
Создание журнала (4096 блоков): готово
Writing superblocks and filesystem accounting information: готово
Просмотр разделов устройства с помощью консольной версии gparted
Смонтировать новые файловые системы
# создаёт две директории в /tmp
mkdir -p /tmp/{1..2}
# монтирование в созданные директории
sudo mount /dev/loop33p1 /tmp/1
sudo mount /dev/loop33p2 /tmp/2
Заполнить тестовыми данными
sudo cp -r /etc /tmp/1/
sudo cp -r /var/mail /tmp/2/
# открыть смонтированные файловые системы в файловом менеджере mc
mc /tmp/1/ /tmp/2/
Отмонтировать файловые системы, отмонтировать виртуальные устройства и удалить следы
# отмонтировать файловые системы
sudo umount /tmp/{1..2}
# отмонтировать виртуальное устройств
losetup -d /dev/loop33
# удалить файл устройства
rm test-image
Для того чтобы обойти блокировку ДокерХаба необходимо
на сервере который не заблокирова DockerHub установить непрозрачный прокси
настроить авторизацию по паролю
настроить Docker на работу с Proxy
Вот пример моих настроек tinyproxy
User tinyproxy
Group tinyproxy
Port 8888
Timeout 600
DefaultErrorFile "/usr/share/tinyproxy/default.html"
StatFile "/usr/share/tinyproxy/stats.html"
LogFile "/var/log/tinyproxy/tinyproxy.log"
LogLevel Info
PidFile "/run/tinyproxy/tinyproxy.pid"
MaxClients 100
BasicAuth user superPsWd
ViaProxyName "superproxy"
ConnectPort 443
ConnectPort 563
Теперь необходимо перенастроить докер приложение, у меня удалось только через глобальную правку конфига /lib/systemd/system/docker.service, в секции [Service] добавляем прокси переменные
Иногда чтото происходит с материнской платой и отваливается USB порт. Но ядро Linux продолжает пытаться общаться с этим портом и в логах появляются вот такие логи
Для исправления этой ошибки необходимо сообщить ядру о необходимости исключить заданный порт из работы, для этого необходимо отправить ID порта в файл /sys/bus/pci/drivers/xhci_hcd/unbind
Имею несколько компьютеров с прошлым LTS релизом Ubuntu 24.04, согласно рекомендация перед сменой версий необходимо обновить текущий дистрибутив
root@micro-server:~# apt update
Сущ:1 http://ru.archive.ubuntu.com/ubuntu jammy InRelease
Сущ:2 http://ru.archive.ubuntu.com/ubuntu jammy-updates InRelease
Сущ:3 http://ru.archive.ubuntu.com/ubuntu jammy-backports InRelease
Сущ:4 http://security.ubuntu.com/ubuntu jammy-security InRelease
Сущ:5 https://esm.ubuntu.com/apps/ubuntu jammy-apps-security InRelease
Сущ:6 https://esm.ubuntu.com/apps/ubuntu jammy-apps-updates InRelease
Сущ:7 https://esm.ubuntu.com/infra/ubuntu jammy-infra-security InRelease
Сущ:8 https://esm.ubuntu.com/infra/ubuntu jammy-infra-updates InRelease
Чтение списков пакетов… Готово
Построение дерева зависимостей… Готово
Чтение информации о состоянии… Готово
Все пакеты имеют последние версии.
root@micro-server:~# apt upgrade
Чтение списков пакетов… Готово
Построение дерева зависимостей… Готово
Чтение информации о состоянии… Готово
Расчёт обновлений… Готово
Обновлено 0 пакетов, установлено 0 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено.
root@micro-server:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.4 LTS
Release: 22.04
Codename: jammy
root@micro-server:~# grep Prompt /etc/update-manager/release-upgrades
Prompt=lts
#Prompt=normal
root@micro-server:~# do-release-upgrade
Проверка наличия нового релиза Ubuntu
Нет доступной LTS версии для разработчиков.
Чтобы произвести полное обновление до последнего разрабатываемого (без долгосрочной поддержки) выпуска
установите Prompt=normal в /etc/update-manager/release-upgrades.
Причём совсем недавно обновление работало и я для тестов обновил 22.04,4 до тестовой версии 24.04, но там обнаружился сломанный пакет docker-python и я ожидал что его починят в официальном релизе
Так вот после выхода релиза ничего не изменилось,
root@csvt:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04 LTS
Release: 24.04
Codename: noble
root@csvt:~# apt update
Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Hit:2 http://archive.ubuntu.com/ubuntu noble-updates InRelease
Hit:3 http://archive.ubuntu.com/ubuntu noble-security InRelease
Hit:4 http://archive.ubuntu.com/ubuntu noble-backports InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
root@csvt:~# apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
То-есть сейчас, пока не получается обновиться до офицального LTS Ubuntu 24.04
Users of Ubuntu 23.10 will be offered an automatic upgrade to 24.04 soon after the release.
Users of 22.04 LTS however will be offered the automatic upgrade when 24.04.1 LTS is released, which is scheduled for the 15th of August.
Современный backend может не содержать на физическом сервере своих привычных файлов, там может даже не было СУБД и Веб-сервера потому что вся система размещается в контейнерах Docker
Для того чтобы предоставить доступ к файлам в таком контейнере можно воспользовать образом proFTPD и включить его в конфигурацию docker-compose
Переменная FTPUSER_UID должна быть равна ID текущего пользовать от имени которого запускается контейнер
Переменные FTPUSER_NAME и FTPUSER_PASSWORD_SECRET ипользуется для генерации пароля и поиска этого пароля в специальном файле в директории /run/secrets
Дело в том, что proFTPD использует пароли в определённом формате, для нормальной работы необходимо сгенерировать пароль и положить в специальный файл, который будет подмотирован в образ proFTPD
python3 -c "import crypt,random,string; print(crypt.crypt('$FTPUSER_PASSWORD_SECRET', '\$6\$' + ''.join( [random.choice(string.ascii_letters + string.digits) for _ in range(16)])))" > ftp/secrets/$FTPUSER_PASSWORD_SECRET
Файлы блоков LVM/RAID0 будут размещать на 3 типах физических устройств
Шпиндельный диск HDD с интерфейсом SATA
Твердотельное хранилище SSD с интерфейсом SATA
NVME с интерфейсом M2
Для перемещения блоков LVM/RAID0 необходимо остановить VG, удалить виртуальные устройства, перенести файлы, создать устройства, запустить VG по следующему сценарию
Ниже будут показаны три комбинации конфигураций, в каждой конфигурации по два скриншота замеров производительности диска на котором размещёны блоки LVM/RAID0 и замер производительности LVM/RAID0
Первая, самая медленная, конфигурация: здесь блоки raid размещаются на SSD с интерфейсом SATA
средняя скорость чтения с SSD/SATA диска 540Мб/с
Вторая конфигурация: здесь блоки raid размещаются на обычном шпиндельном SATA диске
Средняя скорость чтения SATA 144Мб/с
Последняя, самая быстрая конфигурация: здесь блоки raid размещаются на скоростном NVME установленнам через переходник в слот PCI-Express
Средняя скорость чтения NVME 2,7Гб/м
Вывод: с помощью LVM/Raid можно получить повышение производительности цифрового хранилища.
Получается, можно взять обычный шпиндельный SATA диск, разделить его на 4 раздел, на их основе создать LVM/RAID0 и получить увеличение скорости чтения в несколько раз
даже звучит дико
сводная таблица, в кавычках количество разделов используемых в LVM/RAID0
# перейти в директорию с сертифкатами
cd /usr/local/share/ca-certificates
# скачать корневые сертификаты минцифры РФ
wget https://gu-st.ru/content/lending/russian_trusted_root_ca_pem.crt https://gu-st.ru/content/lending/russian_trusted_sub_ca_pem.crt
# обновить список доверенных сертификатов операционной системы
update-ca-certificates --verbose
# создаёт виртуальный Диск и отображает имя файла виртуального диска, в моём случае /dev/loop15
# список разделов можно посмотреть вот так sudo fdisk -l /dev/loop15
sudo mount /dev/loop15p2 /mnt
# монтирует второй раздел виртуальный диска в директорую /mnt/
# тут какие то работы с данными образами
docker run -v $OVPN_DATA:/etc/openvpn --rm kylemanna/openvpn ovpn_getclient USERNAME > USERNAME.ovpn
И всё, можно пользоваться
Чтобы в дальнейшем сохранилась возможность генерировать новые ключи необходимо восстанавливать значение export OVPN_DATA="ovpn-data-example" и использовать passkey использованный для генерации корневого сертификата
Посмотреть статус OpenVPN сервера можно вот так
docker exec -it funny_varahamihira ovpn_status
Если необходимо запустить VPN клиента на постоянной основе, например на ubuntu сервере, то необходимо сгенерировать ключ для этого сервера, скопировать его в директорию /etc/openvpn/client.conf