Файлы блоков 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
После блокировки западных стриминговых платных платформ можно оживить устройство Songs AMQ с помощью MPD
На любом хостинг-сервере ставим mpd
apt install mpd
закачиваем музыку в /var/lib/mpd/music
меняем на неё права
chown -R mpd:nogroup /var/lib/mpd/music/
в файле конфигурации /etc/mpd.conf можно оставить только такие настройки
playlist_directory "/var/lib/mpd/playlists"
db_file "/var/lib/mpd/tag_cache"
log_file "/var/log/mpd/mpd.log"
pid_file "/run/mpd/pid"
state_file "/var/lib/mpd/state"
sticker_file "/var/lib/mpd/sticker.sql"
user "mpd"
bind_to_address "0.0.0.0" # слушаем все вшешние адрес
port "6600"
password "Z2022.02.24@read,add,control,admin"
input {
plugin "curl"
}
audio_output {
type "httpd"
encoder "lame" # кодек lame необходим для работы с Songs AMQ
port "8000"
bitrate "256" # повышенный битрейт
format "44100:16:1"
}
filesystem_charset "UTF-8"
перезапускаем mpd
service mpd restart
Полученную ссылку в виде http://хостинг-сервер:8000 прописываем в songsApp
Всё работает. Управлять можно через приложение GMPC, так же есть приложения управления mpd для Android. Для управления используем адрес [хостинг-сервер], порт 6600, пароль из опции password
Для того чтобы смержить два проекта потребуется git начиная с версии >=2.9. Такого нет в репозитариях стабильной версии Ubuntu 16.04. Для установки более новой версии необходимо сделать вот так:
Создание резервных копий необходимо для обеспечения восстановления работы базы данных в случае системного сбоя. Самой простой методикой является периодический запуск скрипт делающего дамп базы данных на сервере с сохранением результатов на сервере. Такая методика прекрасно работает до тех пор пока работает сервер. Может случится ситуация когда с сервером что-то случилось и невозможно восстановить данные из его файловой системы. Обычно, для решения этой проблемы хостеры предлагают использовать внешний FTP сервер и обычно они требуют за него деньги. То-есть скрипт должен закачивать созданный дамп базы данных на другой сервер по протоколу FTP.
Но нам ни кто не мешает поступить следующим образом, полученный дамп базы данных сжимается архиватором (для уменьшения размера), а затем полученный архив отсылается на почту администратора сайта, например на gmail. А для того чтобы не захламлять почтоый ящик регулярными дампами можно настроить ящик так, чтобы он письма с дампом базы данных перекладывал в спам. Таким образом, письмо не мешает работать с почтой и гмайл самостоятельно удаляет слишком старый спам и у вас всегда будет доступна самая актульаня версия базы данных, а устаревшие будут автоматически удаляться. Даже если не настраивать перенос писем в спам, то можно удалять письмо и оно автоматически будет удаленно через n-дней, так уж устроен gmail
У меня на одной базе данных проявилась проблема, так как база данных получалась слишком большая из-за таблицы которая хранила тексты входящей почты. Эти данные не являются актульными и я просто не включал их в дамп базы данных с помощью опции --ignore-table
Таким образом у меня получился вот такой скрипт
#!/bin/bash
site_name="site-name.ru" # переменная с именем проекта
# формирование имения файла дампа с датой
file_base_name="/home/$site_name/backup/$site_name-`date +%F`.sql.bz2"
# создание дампа резервной копии
mysqldump -u логин -pпароль $site_name --ignore-table $site_name.mails | bzip2 > $file_base_name
# отправка дампа на почту
uuencode $file_base_name $file_base_name | mail -s "backup $site_name `date '+%Y-%m-%d'`" admin@gmail.com
# удаление резервных копий старше 7 дней
find /home/$site_name/backup/ -ctime +7 -delete
#PS, утилита uuencode входит в состав пакета sharutils
Когда Яндекс.домены просят подтвердить домен с помощью CNAME записи то этот поддомен прописывается в панели управления доменом у хостера, а затем проверяется с помощью следующей команды
host -t CNAME python.breys.ru ns1.firstvds.ru
Using domain server:
Name: ns1.firstvds.ru
Address: 82.146.43.2#53
Aliases:
python.breys.ru has no CNAME record
в выхлопе команды будет видно является ли запись типа CNAME, в данном случае не является, в от этот поддомен является CNAME на breys.ru
host -t CNAME static.python.breys.ru ns1.firstvds.ru
Using domain server:
Name: ns1.firstvds.ru
Address: 82.146.43.2#53
Aliases:
static.python.breys.ru is an alias for breys.ru.
Для проверки MX записи можно воспользоваться вот такой командой
host -t MX breys.ru
breys.ru mail is handled by 20 mail.breys.ru.
breys.ru mail is handled by 10 mail.breys.ru.
host -t MX python.breys.ru
python.breys.ru has no MX recor
Внимательный глаз сразу заметит что можно указывать внешний NS сервер для проверки записи, это необходимо чтобы не дожидаться обновления зоны на локальном DNS сервере и у провайдера.
