Константин

Виртуальное окружение в проекте есть? Если да, то запускать скрипт надо не системным питоном, а питоном из этого окружения.
EDIT1:

Если из командной строки дать pyhon3 /home/lxm213/script.py, то скрипт работает штатно и без ошибок

Т.е. скрипт запускаешь в системном окружении, а не в виртуальном. ОК, тогда по идее он должен работать...
Но встаёт вопрос: как ты ставил schedule? Просто pip install schedule? Из-под рута ставил или с правами просто пользователя?
Если ставил из-под рута, то библиотека будет установлена в системный интерпретатор и будет доступна всем пользователям.
Если ставил не из-под рута, то, возможно, pip поставил её куда-то в твой домашний каталог - я знаю, что под виндой он так делает. Тогда библиотека доступна только если запускать скрипт из-под твоего пользователя.

Отсюда три возможных решения:
1. Создать виртуальное окружение для проекта, поставить библиотеку в это виртуальное окружение (используя местный pip), запускать скрипт через python3 из этого окружения.
2. Если библиотека была поставлена без рут-прав, указать в .service-файле, что скрипт надо запускать от имени твоего пользователя, а не от имени root.
3. Убедиться, что библиотека поставлена в системный интерпретатор. При необходимости поставить её с рут-правами. Тогда скрипт будет работать из-под любого пользователя.

Привет.

0 - узнать у технической поддержки выбранного сервиса, есть ли инструкции для подключения сайтов без CMS (обычно такие инструкции есть);
1 - нанять специалиста на фрилансе для реализации задачи;
2 - писать код самому, опираясь на решения для CMS в качестве примера.

Похоже на 1 из трех вариантов:
- Кто то случайно ошибся, и добавил ссылку на Ваш сайт в мобильном приложение.
- Кто то решил протестировать свой ультра-парсер, выбор пал на переходы из этого мобильного приложения на Ваш сайт.
- Кто то начал крутить в негатив поведенческие факторы на Вашем сайте.

Если Ваш сайт сильно полагается на SEO, то все случаи выше - необходимо фиксить.

Эффективно сохранить современные сайты почти нереально.
Некоторые, можно частично, особенно если они не слишком сложные и в основном содержат статьи.

Кстати, википедия занимает несколько терабайт только текста, есть сомнения что у тебя скачана вся википедия.
Есть отдельные сайты, где можно скачать дампы википедии, читаем тут:
https://en.wikipedia.org/wiki/Wikipedia:Database_d...

Современные сайты, которые работают на JS функциях, практически нереально спарсить и скачать эффективно и целиком.

Блин! Опять Kali и незнайка.
Открываем тепминал и смотрим, что говорит ip link
Кулхацкерский дистрибутив подразумевает кулхацкера за рулем. Сносите, и ставьте что-то для новичков!!!

Ох, чувак, ты даже не представляешь себе, какую ты сложную задачу поднял... Такая задача решается обычно раскатыванием некоего эталонного образа, где весь софт уже установлен, а при развертывании он только настраивается. Готовый софт мне неизвестен, пишу сам, серверный образ уже развертывается, образа рабочей станции пока нет (ну то есть он есть, но не развертывается полноценное РМ).

Теперь о грустном.

Прямой копии с винды конечно же нифига не получится. Придется долго и муторно клепать "мастер-рабочее место". Корпоративная почта на TB - мигрирует запросто, даже профиль юзера можно при желании подтянуть, а вот со всем остальным рамс.

AD - прямого копирования конечно же нет. Все "импортозамещенные" решения - шляпа (ALD Pro живьем не видел, но судя по тому , что я увидел в Кибер.Бэкапе - это будет либо явный BolgenOS, либо втихую скоммунизменный). Единственное, что хоть что-то похожее делает - это Samba DC, но опять же только в рамках логинов-паролей и (может быть!) GPO. Да, GPO, даже если есть - на винде работать не будут :). Есть еще IDA, если одолеете настройку.

И все вручную. Про ПО ничего не сказали, что за ПО. Возможно оно заработает в Wine, а возможно нет.

В общем задача распадается на две:
- слабать "мастер-образ", где установлено все, что будет работать в линухе
- этот "мастер-образ" раскатать на нужное количество машин

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

Как подчинить алгоритм YouTube?

Никак
Во-первых, он не опубликован - только общее описание
Во-вторых, он меняется часто, поэтому подстраиваться нет смысла

Насколько трудоёмко будет написать такой почтовый сервер самому?

Простой, обрабатывающий только базовый RFC822 - несложно, но при этом половина привычных фич работать тупо не будет ;) Если же морочится поддержкой всего-всего, что уже напридумывали - нужно прочитать все RFC, которые связаны с темой :)

Какие частые проблемы возникают в эксплуатации готовых решений?

В эксплуатации самих решений, как правило особых проблем нет. Проблемы возникают обычно с анти-(спамом, вирусом, чертом лысым). Шифрование, сертификаты, SPF/DKIM/DMARC etc.

Как скрепные сервисы, почтовые и не только, реагируют на самодельную почту, есть тут какие-то проблемы?

Как человек, много лет содержщий собственную почту (на собственном сервере, стоящем в собственной квартире :) ) скажу, что плевали они на это. Протоколов слава Богу придерживаются - и ладно.

Нужно ли регистрировать домен для своей почты?

Доменное имя? Конечно. И еще белый IP нужен и MX-запись, направляющая на него почту.

Обычные проблемы - это:
- сделать так, чтобы твои письма не уходили в спам
- сделать так, чтобы тебя не задробили спамом
Первое обычно решается через SPF/DKIM/DMARC иже с ними, второе - через greylistng и черные списки

Думаю на python, т.к. самому интересно поковыряться.

Не путайте жабу с мотоциклом. Почтовый сервер - это обычно два независимых компонента - SMTP-сервер (тот, что принимает письма и мира и отправляет их в мир) и IMAP-сервер (тот, что передает почту в почтовый клиент - Thunderbird, Outlook etc). Плюс дополнительные модули. Веб-интерфейс к почте - отдельный продукт, с двумя первыми обычно не связанный (кстати, пишутся сервера обычно на С). Антиспам - это еще отдельный продукт (может быть, если морочиться чем-то типа DSPAM).

По той же причине, что и делают совстенное облачное хранилище

В простых кейсах с малым количеством телефонов - смысла не имеет.
Когда у тебя сложный "вариант" с разными переадресациями, уведомлениями итд, то уже требуется свое. Или когда нужна интеграция с софтом, которого нет у облачного провайдера.

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

которая гораздо удобнее и легче в настройке

Ровно до тех пор, пока у вас не появляются нестандартные запросы. Например, перевод входящего звонка в зависимости от графика работы подразделений, меняющегося по праздникам и выходным. Или использование нескольких очередей с самостоятельной регистрацией в них операторов и интерфейсом, отображающим отвеченные и пропущенные звонки в этой очереди. Или дать возможность регистрироваться под одним номером с нескольких телефонов (рабочий аппарат сотрудника, софтфон на смартфоне сотрудника, софтфон на домашнем компьютере сотрудника). Или связать напрямую свой Asterisk с Asterisk организации-партнёра/клиента для прямых звонков.
Чистый Asterisk очень гибок в настройке, способен работать напрямую с базами данных, LDAP/AD и запускать внешние скрипты.