AlexVWill, мы тут немного дальше пошли. Отчёт на почту послать, хоть про удачу, хоть про неудачу. Есть настроенный веб-сервер, на котором готовые функции, чтобы настучать админу. Написал логику, что если не получилось выпустить сертификат, то заслать curl POST-запрос на сервер. И что же. В те неудачные запуски, когда сертификат не получилось выпустить, curl в журнал написал
curl: (7) Failed to connect to траляля port 443: No route to host
AlexVWill, я выяснил, что без snap эта служба называется certbot. Но там вызов
ExecStart=/usr/bin/certbot -q renew
В таком синтаксисе certbot не сможет применить настройки. Можно вместо bash скрипта попробовать устроить подкоп в виде --post-hook "systemctl reload имя-службы", но пока пробую всё же для скрипта сделать service+timer по аналогии. Вдруг systemd timer работает лучше crontab
AlexVWill, ну вообще в нормальной логике в скрипте стоит set -e, и если сертификаты обновить не получилось, то и дальше исполнение не идёт, ничего не перезаписывается. А если подглядывать за изменением файла, а вдруг там какой-то сертификат поломанный будет.
Unit snap.certbot.renew.service could not be found.
Какой-то не очень штатный, видимо.
можешь делать и в кроне всякое
А почему вдруг sftp сертификата на другой сервер сработает, если у certbot и ping такие проблемы
Там ещё надо серверу дать понять, что сертификаты новые. И ещё, бывает, что нужно скопировать сертификаты на другие сервера, и там на других серверах тоже стукнуть в службы. Не изучал возможности демона
Drno, с командной строки (ssh) работает безупречно. Из cron сплошные проблемы, и DNS в несколько попыток не ответил, и соединение не установилось, всё что-то не ладится
web3_Venture, каждый домен единолично¹ решает, какие себе поставить куки.
Кукис можно поставить средствами JavaScript, и для этого должна быть открыта новая вкладка, либо всплывающее окно, либо фрейм, с адресом в подходящем домене, и в этом фрейме может сработать скрипт, который обратится к document.cookies и установит кукис в подходящий домен
Кукис можно поставить средствами HTTP-заголовков в ответ на запрос по адресу в подходящем домене. Это либо переход во фрейме, либо отправка формы во фрейме, либо подгрузка картинки/скрипта/и т.п. Либо междоменный запрос с withCredentials true. Если один междоменный запрос поставил кукисы, то другой междоменный запрос получает кукисы, которые были поставлены при прошлом запросе. Сам сервер должен захотеть поставить себе кукис, вы снаружи без участия сервера никак не сможете забросить в чужой домен ничего
¹Когда грузится всякая Яндекс.Метрика, сторонние чаты и т.п., это внешние скрипты, которые исполняются в контексте того фрейма, который загрузил их, а, значит, обращаясь к document.cookies, скрипты могут редактировать кукисы в чужом неяндексовом домене, но при этом скрипты могут и звонить домой в Яндекс, и при таких запросах участвуют и кукисы домена Яндекса.
web3_Venture, кукисы можно передать, принадлежащие соответствующему домену, потому что простой CORS будет сделан вообще без кукисов, даже если пользователь авторизован на чужом сайте. С флагом withCredentials кукисы передаются, но только принадлежащие соответствующему домену. Между доменами они вообще никогда не смешиваются
shurshur, я в Скайп не вводил пароль полтора года. Можно считать, пароль от Скайп хранится на том самом устройстве, к которому у злоумышленника нет доступа
shurshur, ну, в том виде, как я видел WA, там привязка к телефонному номеру по коду, получаемому на СМС, и если угнать этот код, можно провернуть то же самое
shurshur, запускаем WhatsApp на одном-единственном устройстве и наблюдаем QR-код. Никуда дальше не пробиться. А вот Скайп работает хоть на одном-единственном устройстве, хоть на нескольких
Чё-то не вижу нигде это Recovery Mode