shurshur

Сделай из под root

lsof -n | grep root/mdb103

при запущенной mariadb. Если найдёт запущенные процессы mariadb, использующие файлы в этом каталоге, значит да, файлы там нужны.

В каталоге лежат deb-пакеты, они после установки не нужны. В подкаталоге лежат исходники сервера скомпилированные. В зависимости от того, как они установлены, они могут быть также не нужны. Если их ставили через make install без префикса в /root, то сервер должен, скорее всего, стоять в /usr/local. Если через сборку пакетов с помощью debian/rules (при этом готовые пакеты кладутся в вышестоящий каталог, что весьма логично), то тоже не нужны - они должны быть затем установлены в систему.

В конце концов, необязательно файлы сразу удалять. Можно попробовать переименовать этот каталог, перезагрузить базу или даже весь сервер и убедиться, что всё работает.

Например, можно посмотреть на проекты Кевина Маклауда:
https://incompetech.com/ требует только упоминания автора
https://freepd.com/ музыка, перешедшая в общественное достояние (public domain)

А вообще искать музыку royalty free, под public domain или под лицензиями Creative Commons (внимательно смотреть на конкретный тип, некоторые разрешают коммерческое использование, а некоторые нет).

Почтовые клиенты принципиально не поддерживают javascript, так как это офигенная дыра в безопасности пользователя. Более того, приличные почтовые клиенты по умолчанию даже картинки с внешних ресурсов не скачивают, не то что скрипты.

В консоли раскладка клавиатуры грузится с помощью команды loadkeys, раскладки лежат в /usr/share/keymaps (в deb*untu их по умолчанию нет, надо доставить пакетом console-data).

Шрифт в консоли устанавливается командой setfont, шрифты и таблицы кодировок лежат в /usr/share/console{fonts,trans} (тоже в пакете console-data).

loadkeys и setfont устанавливают раскладку и шрифт до перезагрузки. Лучше этим не страдать, а использовать штатную настройку, в debubuntu это dpkg-reconfigure console-setup.

Для использования мыши в консоли надо установить и запустить сервис gpm.

Если есть желание обслуживать свой сервис, то перспективнее стать клиентом одного из многочисленных агрегаторов, удобнее даже местного (подсмотрел, что в профиле автора вопроса Украина), чтобы проще было с оплатой и техподдержкой, но это необязательно, можно искать агрегаторов в том числе и в странах целевого трафика. Самому заключать договора с операторами кучи стран неразумно сложно. Во многих странах ещё и придётся озаботиться подключением к базам/сервисам MNP, что может доставлять в том числе регуляторные проблемы (могут не давать доступ иностранцам).

Если задача стоит в перепродаже трафика смс от различных сервисов, то если речь не идёт как минимум о десятках миллионов смс в месяц, проще вступить в партнёрские отношения с каким-то другим сервисом и получать скидки за объём или агентскую комиссию.

СМС для A2P (application-to-person) в целом стоят неразумно дорого, за счёт их цены операторы в том числе пытаются компенсировать снижение цен на услуги для частных лиц.

Самому стать одним из таких крупных агрегаторов в настоящее время малореально, так как рынок уже плотно освоен опытными игроками, а заработать там можно только на копеечных комиссиях (практически вся цена смс достаётся операторам). До кучи, трафик A2P SMS не растёт, сейчас модно пилить свои мобильные приложения с пушами и интеграции с мессенджерами.

Facebook с некоторых пор требует, чтобы этот URL был https://, для localhost можно сделать с самоподписанным сертификатом (всё равно Facebook на него только redirect делает, проблема сертификата будет проблемой клиента). Когда мне такое потребовалось, для отладочных целей нашёл первый попавшийся докер с nginx+https и его применил для проксирования в реальное приложение.

Это невозможно - боты никак не могут общаться друг с другом.

Если есть алгоритм генерации бесконечного ключа K(n) (n - порядковый номер элемента ключа) с заданными параметрами, взломщик будет перебирать значения параметров, пытаясь применять сгенерированный ключ к шифрованному тексту. Полученное проверяется на текстовую валидность. Когда получится нормальный естественный текст - ключ взломан.

Например, пусть параметры p и q, алгоритм K(n)=p^n mod q, тогда взломщик просто устроит перебор значений (p; q) от (0; 0) до бесконечности.

Или пусть алгоритм будет K(n)=цифра числа пи "n+p", где p - параметр ключа. Тогда будем делать перебор значений p. Это будет довольно быстро, ведь нам надо будет просто последовательно генерировать цифры числа пи, помнить последние $длина_шифротекста символов и проверять их применимость как ключа.

Более того, если мы не знаем, использует ли наша жертва цифры числа пи или дискретную степенную функцию, мы можем проверять обе версии параллельно, атакуя оба варианта генерации ключа. И даже три или 10 вариантов генерации ключа.

Собственно, чтобы подобный алгоритм имел хоть какой-то смысл, надо, чтобы поиск этих самых параметров p и q был безумно сложным. Если можно проверять миллион вариантов ключа в секунду, то для криптостойкости потребуется, чтобы требовались даже не миллиарды, а как минимум триллионы секунд перебора. Ведь миллиард секунд - это жалкие 8 лет, если взять тысячу вычислителей, то 8 лет превратятся в месяц. а при 30 тыс. - в сутки.

Любой дискретный шифр с известным или предполагаемым алгоритмом ломается перебором. Даже хрестоматийный весьма стойкий RSA ломается. Защита данных дополнительно обеспечивается сменой ключа, алгоритмами Диффи-Хеллмана, реализацией PFS итд итп.

Есть ещё одно обстоятельство. Пусть у нас есть шифр простого сдвига с бесконечным неизвестным ключом, такой чёрный ящик, выдающий шифротекст. Тогда если подать на вход ящику сплошные нули, на выходе он будет выдавать ключ. Чем больше нулей подать, тем больше элементов ключа будет раскрыто. С xor такая же фигня. С нормальными шифрами это, разумеется, не прокатывает.

Никак, по кнопке выполняется всего одно действие. Так что можно передать только то, что передаётся с этой кнопкой, плюс каким-либо образом ранее полученую информацию.

Если пользователь задаёт такой вопрос, то он, скорее всего, не включил двухфакторную авторизацию и не использует секретные чаты, а Телеграм у него зареган на свой собственный российский номер на своё собственное имя. Силовики просто сделают сброс пароля, получат у оператора содержимое смс и залогинятся тобой, затем автоматизированно скачают всю твою переписку для анализа. На всё про всё потребуются считанные минуты, и если это сделать посреди ночи, ты даже ничего не успеешь заметить. И никакое шифрование не спасёт.

Ну а если тебя поймают с телефоном в руках, то можно будет просто открыть твой Телеграм и прям на нём проверить твои переписки.

Используй декоратор bot.callback_query_handler.

@bot.callback_query_handler(func=lambda call: True)
def my_handler(call):
    # call.data - содермое callback_data кнопки
    # call.message - исходное сообщение с кнопкой
    # call.message.from_user - отправитель исходного сообщения
    # call.from_user - нажавший на кнопку пользователь
    # call.message.chat - чат, в котором всё происходит