shurshur

Всё прекрасно работает.

В чём проблема? Там проще некуда.

rsync -av --progress user@host:/path/to/site/ /local/directory/for/site/

(слеши на концах путей нужны)

Можно на лету сжимать, добавив ключ -z.

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

Для этого модули вообще не нужны.

https://api.telegram.org/bot{token}/getMe

Например, Mapbox SDK до 25 тыс. пользователей в месяц бесплатно. Ну и вообще смотреть сюда для начального знакомства с вопросом.

Кроме того, можно просто напрямую использовать тайловые сервера различных рендереров OSM, но нужно понимать, что у них может быть usage policy, например, у рендерера на главной странице официального сайта он такой, так что для активно используемого приложения лучше обратиться к коммерческим поставщикам или даже сделать рендеринг нужной территории самостоятельно (для территории одного города это потребует не так уж и много ресурсов).

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

Не надо этого бояться. Postgresql идёт из пакетов уже минимально настроенным. Нужно потратить немного времени, чтобы научиться создавать пользователя и базу (руководств в сети полно), это будет намного проще, чем возиться с настройкой базы в докере.

Нельзя. Боты не могут создавать группы.

Новую группу может создать только полноценный пользователь Telegram, так что это возможно реализовать только с помощью клиентского (MTProto) API.

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

Например, я парсил один сайт, а он ровно после 500 страниц показал капчу. Весьма вероятно, что если бы я сидел и кликал по сайту в браузере и накликал за полчаса 500 страниц, то тоже бы увидел капчу.

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

Теоретически, если поборость последнее, то есть неодинаковый результат в разных условиях (путём запуска кода в предсказуемо одинаковых), то можно, например, оформить хеширующий микросервис, который будет получать данные и хешировать их по кривому алгоритму. Но лучше бы, конечно, этой фигнёй не страдать, а исправить изначальную проблему. Это как заболевания генетического происхождения: лечить их практически невозможно, потому что у человека уже миллиарды неверных копий ДНК в организме, которые поздно исправлять.

Поле reply_to_message у класса Message содержит информацию о сообщении, на которое отвечают. Ну или None, если это обычное сообщение.

man getuid
man getpwuid

Есть стандартные функции для подобных задач. Их использовать намного правильнее, чем парсить utmp (в который пользователь может не попасть, особенно если это неинтерактивный логин или su/sudo) и /etc/passwd (поскольку пользователи могут храниться не только в passwd, но и в winbind/ldap/nis/итд).

Вообще говоря, правильно отслеживать ботом публикации и запоминать id, например, в базу. Но так-то можно найти в клиенте пост, и сделать копирование ссылки на пост в меню, она будет иметь вид:

https://t.me/my_awesome_channel/message_id

Bot API не позволяет прочитать историю, боты видят только новые публикации. Если ручной способ не подходит (например, постов слишком много для ручной работы), придётся пилить бота на клиентском MTProto API (telethon, pyrogram).