hx510b

Нальзя добавить пользователя в группу с помощью бота.
Бот может поднять привилегии уже существующего пользователя до админа группы:
https://core.telegram.org/bots/api#promotechatmember

Простой ответ: практически любой банк РФ умеет принимать платежи по СБП. для этого надо сообщить плательщику номер телефона, к которому уже привязан СБП.

Правильное решение:
1. Открыть юрлицо или ИП
2. Открыть РКО в банке
3. Подключить Интернет-Эквайринг
4. Подключить к Интернет-Эквайрингу облачную кассу с фискальным накопителем.
5. Настроить виджет/форму на сайте.
6. Начать принимать платежи на расчетный счет юрлица или ИП.
7. Платить налоги в соответствии с налоговым режимом и организационной формой.
Минус: стоимость эквайринга 0.4% по СБП, а по картам еще выше.

Неправильное решение из-за лимитов НПД (2.4 млн в год):
1. Открыть самозанятость (режим НПД).
2. Давать реквизиты для перевода по СБП (телефон).
3. Начать принимать платежи на счет физлица.
4. Каждый месяц оплачивать налог НПД по счету от ФНС.

Рекомендации по снижению рисков по 115фз:
1. Платить налоги НПД с этого же счета.
2. Вести реальные хозяйственные операции: покупать в магазинах, оплачивать услуги.
3. Не выводить деньги в день прихода (с ними нужно "переспать").
4. Держать остаток на счету сопоставимый с оборотом за месяц.
5. Не снимать наличные на все поступления.

Я бы не изобретал велосипед. Считаю правильным воспользоваться отработанными решениями.
Например передавать в форму 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

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

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

Точка - [ссылка на подробности и открытие расчетного счета](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