hx510b

Я бы не изобретал велосипед. Считаю правильным воспользоваться отработанными решениями.
Например передавать в форму uuid с сервера.
Утилита uuidgen базируется на библиотеке libuuid.
Например, при вызове uuidgen с ключем -t , uuid базируется и на времени и уникальном ид системы, где была запущена утилита. Т.е. при такой генерации uuid одновременно на множестве серверов коллизия будет невозможна.

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

screen -ls | grep "mybotname\s"   ||screen -d -m -S mybotname bash -c 'cd /path/to/bot; bash mybotname-daemon.sh' >>/dev/null

в самом скрипте mybotname-daemon.sh'

#!/bin/bash
cd /path/to/bot
while `true`
do 
  # здесь команда запуска нашего бот, например:
  python mybotname-daemon.py
  sleep 1
  echo "Restarting program..."
done

В таком виде все это работает уже несколько лет.

В линуксе qemu|kvm делаем что-то типа:
1. копируем физический винт в образ:
dd if=/dev/sdb bs=1M of=/path/to/asterisk.img
(потом желательно все это конвертнуть в qcow2), но начать можно с raw образа

2. создаем конфиг для libvirt:
vim /path/to/asterisk.xml

<domain type='kvm'>
<os><type arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type>
<boot dev='hd'/><boot dev='cdrom'/><boot dev='network'/><bootmenu enable='yes' timeout='10000'/>
</os>
<features><acpi/><apic/></features>
<clock offset='utc'><timer name='rtc' tickpolicy='catchup'/><timer name='pit' tickpolicy='delay'/><timer name='hpet' present='no'/></clock>
<on_poweroff>destroy</on_poweroff><on_reboot>restart</on_reboot><on_crash>destroy</on_crash>
<pm><suspend-to-mem enabled='no'/><suspend-to-disk enabled='no'/></pm>
<devices>
<emulator>/usr/libexec/qemu-kvm</emulator>
<memballoon model='virtio'></memballoon>
<video><model type='cirrus' vram='16384' heads='1' primary='yes'/></video>

<!-- ДИСКИ -->
<disk type='file' device='disk'><driver name='qemu' type='raw'/><source file='/path/to/asterisk.img'/><target dev='vda' bus='sata'/></disk>
<!--<disk type='file' device='cdrom'><driver name='qemu' type='raw'/><source file='/srv/kvm/iso/srcd.iso'/><target dev='hdd' bus='ide'/><readonly/></disk>-->

<!-- СЕТЬ -->
<interface type='bridge'><mac address='00:00:11:22:33:44'/><source bridge='br0'/><target dev='vnet0'/><model type='virtio'/></interface>

<!-- VNC -->
<graphics type='vnc' port='5901' autoport='no' listen='0.0.0.0'><listen type='address' address='0.0.0.0'/></graphics>
</devices>
<!-- -->

<!-- НАЗВАНИЕ -->
<name>asterisk</name>
<uuid>12345678-cccc-bbbb-aaaa-651921689250</uuid> <!-- уникальный GUID -->

<!-- ОЗУ В ГИГАБАЙТАХ -->
<memory unit='GiB'>8</memory>

<!-- КОЛИЧЕСТВО ЯДЕР -->
<vcpu placement='static'>2</vcpu>
</domain>

3. подкидываем конфиг в libvirt:
virsh define /path/to/asterisk.xml

4. запускаем машину в libvirt
virsh start asterisk

5. сеть скорее всего придется заново настроить, поэтому соединяемcя по vnc по адресу ноды, порт 5901 в данном примере.

На тему свободного места. Сейчас широко представлены различные накопители и внешние USB/SATA адаптеры, т.к. что скопировать можно локально.

Еще вариант:
1. Загрузиться с флешки sysrescuecd

2. Смонтировать с помощью sshfs сторадж по сети:
sshfs 123.123.123.123:/path/to/remote /mnt

3. Скопировать туда образ жесткого диска:

dd bs=1M conv=sparse if=/dev/sda | pigz -c --fast >/mnt/sda.raw.gz

4. Там локально использовать, распаковав:

cat /path/to/remote/asterisk.img.gz | pigz -dc|dd bs=1M conv=sparse of=/path/to/remote/asterisk.img

5. Либо распаковать локально:

sshfs 123.123.123.123:/path/to/remote  /mnt
cat /mnt/asterisk.img.gz | pigz -dc|dd bs=1M conv=sparse of=/local/path/to/asterisk.img

Это решается стандартными возможностями разметки:

Точка - [ссылка на подробности и открытие расчетного счета](https://site.tld/t?to=open-rko&ch=bot)

Должно получиться:

Точка - ссылка на подробности и открытие расчетного счета

NB: телеграм переваривает в качестве ссылок только ссылки на протоколы http и https

Можно взять MYSQL и зарезать пользователю права на удаление записей )), либо написать к нему REST сервис, который будет принимать данные и не удалять. А можно и то и другое - будет двойная устойчивость.

пропишите при каждом вызове скрипта bash с полным путем, тогда будет работать надежно.
cron как правил запускает задачи без переменных окружения, а значит переменная PATH пустая.
если это cron пользователя, то указывать пользователя не надо:

@reboot /usr/bin/bash /var/www/user_site/data/www/nodejs/zapusk-nodejs.sh

если cron системный, то надо прописать пользователя:

@reboot root /usr/bin/bash /var/www/user_site/data/www/nodejs/zapusk-nodejs.sh

в этом варианте я бы создал файл задания в каталоге /etc/cron.d/zapusk-nodejs, а не мучал бы crontab

используйте IPP в CUPS или LPD сервис, винда нормально работает с ними, если принтер не GDI, а PCL/Postscript
- т.е. расшарьте принтер по сети и пусть клиент печатает на него независимо от состояния RDP / SMB.

Я использую другой подход:
Есть различные сервисы, которые по текстовому лаконичному описанию сами рисуют диаграмы.
Т.е. чтобы изменить диаграму ее не надо заново рисовать или двигать блоки вручную, достаточно поправить исходник и диаграма будет перестроена.
Пример такого языка D2 и сервис https://play.d2lang.com/
Есть и другие.
Я думаю, что если набить руку по написанию на подобном языке, возможно часть проблем удасться решить.

В подобной задаче: у нас были сотни миллионов файлов мы их хранили на виртуальных дисках. Одна из причин такого подхода - это ограничение по inode и по iops.
На низлежащей базовой файловой системе эти файлы не хранили, а только на виртуальных дисках.
Таким подходом решались следующие проблемы:
1. Cнимались проблемы с количеством inode
2. Двигать виртуальные диски быстрее, т.к. копирование образа идет с наиболее эффективной скоростью, чем пофайлово. т.е. любые перемещения, перекладки, преобразование хранилища давались меньшей кровью.
3. Делать резервное копирование проще с образами, чем с миллионами файлов.
4. Если вдруг рухнет какая-то файловая система, то она может рухнуть, не утащив за собой все. да, мы попутно разделяли на разные блочные устройства. Чтобы доступ к одному блочному устройству не вешал всю систему.
при это rootfs вообще лучше сделать маленьким и разместить в RAM. Надо сказать, что с разрушением фс на сторадже мы не сталкивались, несмотря на бутерброд: drbd -> ext4 -> loop image -> ext4
5. За счет loop имиджей достигалась экономия пространства за счет оверселлинга: суммарные объем внутри виртуальных дисков мог быть равным или превышать объем низлежащего блочного устройства. Конечно за этим надо следить. Этому помогал zabbix и статичность хранимых файлов.
6. Для прикладных приложений все оставалось обычными файлами. Не пришлось менять код.
В момент создания этого проекта технологий было меньше чем сейчас, еще меньше было проверенных технологий. Все облачные масштабируемые хранилища слишком медленные и не дают прямого доступа к файлам.
Поэтому использовали обычный набор:
1. DRBD для сетевого зеркаливания между нодами.
2. EXT3/EXT4 инициализированные с большим количеством inode.
3. loop images - штатная возможность создания блочных устройств в файлах.
4. sparse files - технология пропуска пустых блоков внутри файла.
5. обычные symlinks.
Несмотря на некоторую сложность в начале, подход себя оправдал.

По монтированию все выглядит примерно так:

root /
+- block device ext4
+- block device ext4
+- block device ext4
...

Внутри каждого блочного устройства block device ext4:

vdisk0.img
vdisk1.img
vdisk2.img
...

Монтируются они все в каталоги в дерево виртуального хранилища:

/virtstore
+- virtfolder0 
+- virtfolder1 
+- virtfolder2
...

За счет древовидной структуры каталогов, симлинков получали более менее пригодную схему для работы
Что еще можно сделать:
1. для миллионов мелких файлов можно в образе диска использовать btrfs со сжатием. для доступа только на чтение получается серьезная экономия по месту. но только в режиме чтения. при перезаписи плотность "упаковки" падает.
2. для интенсивной записи нужно разнести запись на разные блочные устройства. Чем больше физических блочных устройств, тем легче расшить узкие места по нагрузке и получить приемлемую производительность всей системы.

Для примера, команды для работы:

Создаем sparse имидж на 850 гб

dd if=/dev/zero bs=1M seek=850000 count=1 of=/path/to/image.img

либо
truncate -s 850G /path/to/image.img

Инициализация ФС:

mkfs.ext4 -m 0 -O dir_index -O resize_inode -t ext4  /path/to/image.img

Монтируем имидж:

mount -o loop /path/to/image.img /path/to/mount/point/

Для ускорения работы, монтировать лучше с оптимизированным параметрами монтирования, например:
rw,nosuid,nodev,noatime,nodiratime,strictatime
Соответственно такие образы можно монтировать, размонтировать, копировать и двигать. Можно уменьшать и увеличивать размер такого образа.

Гипервизора с Libivt/KVM вполне достаточно. Тем более для одного хоста.
Все управляется из командной строки, объем знаний для типовых операций наверное уместится на 1й странице.
16 Гб ОЗУ - это не так много, чтобы еще из тратить на вспомогательные сервисы в виде веб-сервера.

Можно прописать в cron / crontab задачу, которая будет запусаться при загрузке системы:

@reboot root   iptables -t nat -A POSTROUTING -o enp0s3 -j MASQUERADE

- такой простой вариант на все случаи и дистрибутивы (если используется iptables).

в RHEL/CentOS можно исправить файл руками, при запуске iptables конфигурация подгружается их этого файла:
/etc/sysconfig/iptables

Можно сохранить текующую конфигурацию в этот файл:
iptables-save >/etc/sysconfig/iptables

Используйте расширение unaccent
Подробности https://www.postgresql.org/docs/current/unaccent.html
С дистрибутивом поставляются правила соответствия символов, например:
/usr/pgsql-13/share/tsearch_data/unaccent.rules
После подключения правил и перестроения индексов БД согласно этим правилам, поиск должен осуществляться без учета разницы между "е" и "ё".

Поведение зависит от ответа сервера.

Если сервер сообщает браузеру, что файлы можно кешировать. Т.е. остальные 9 загрузок будут сделаны из локального кеша браузера.

Если же сервер сообщает, что файл нельзя кешировать, то браузер должен его запрашивать заново.

Помимо кеширования на стороне бразуера, кешировать может промежуточный прокси сервер, если таковой есть. Прокси сервер может быть явно использоваться браузером, а может неявно использоваться в сети.

Попробуйте добавить в конфиг файл mysql, например так:

[mysqld]
init_connect='SET collation_connection = utf8mb4_unicode_ci'
collation-server=utf8mb4_unicode_ci

Чтобы прокинуть конфиг во внутрь docker образа используйте опцию -v

-v /local/path/to/hosts/config/collation.conf:/etc/my.cnf.d/collation.conf

Конечно влияет. Ведь torrent клиент постоянно записывает фрагменты на диск при скачивании.
Вот если только раздавать - то не должен.
А если swap еще все время пишется, то совсем криминал. Если система уходит в swap, то надо добавить ОЗУ или снизить аппетиты - количество приложений в памяти. Вообще наращивание ОЗУ всегда повышает производительность системы.