gitlab cicd + telegram

Можно взять готовое, вроде интересное

https://hub.docker.com/r/upagge/gitlab-telegram-notify

Можно взять яндекс хостинг и поднять на serverless технологиях

https://cloud.yandex.ru/docs/tutorials/serverless/telegram-bot-serverless

Как получить chat_id и опционально thread_id, чтобы послать туда сообщение?

1) https://api.telegram.org/bot<YourBOTToken>/getUpdates

Не сработает, если уже где-то развернули бота с вебхуком, будет 

{"ok":false,"error_code":409,"description":"Conflict: can't use getUpdates method while webhook is active; use deleteWebhook to delete the webhook first"}

2) в нужном чате копируем ссылку на сообщение, будет типа https://t.me/c/1234567890/4/5 - большое число (добавить минус в начало) это ид чата, второе - тред, третье - номер сообщения и нам не важно. Если тредов нет то среднего числа не будет.

3) всякие боты типа https://t.me/getmyid_bot - но там нужна всякая магия, треды оно не умеет итд.

Делаем тестовую отправку

curl -X POST -H "Content-Type: application/json" -d "{\"chat_id\": \"<YourGroupID>\", \"text\": \"===ТЕСТ===\"}" https://api.telegram.org/bot<YourBOTToken>/sendMessage

Если нужно в тред (топик) то после значения чата в chat_id добавляем

\"message_thread_id\": \"<THREAD>\",

И тут прикол: офдока содержит кривое поле top_msg_id, а message_thread_id там вообще нет:

https://core.telegram.org/method/messages.sendMessage

Вот с таким Г нам приходится работать, что гугл точнее чем офдока. Печалька.

ЗЫ оба поля проверены, первое не работает, второе работает...

ansible: некоторые особенности with_fileglob

 Типовое применение: из templates/nginx/sites-available/ нужно скопировать с заменой переменных ряд конфигов. Вариант "в лоб":

- name: install sites
   template:
     src: "{{ item }}"
     dest: "/etc/nginx/sites-enabled/{{ item }}"
   with_items:
     - nginx/sites-available/site1.conf
     - nginx/sites-available/site2.conf

ssh виды ключей

                  [-t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa]

а что выбрать? Можно по привычке просто ssh-keygen, но будет создан id_rsa с длиной ключа 1024, что в современном мире откровенно мало.

ssh-keygen -b 4096 - и это будет работать и будет достаточно безопасно. Но что такое остальные виды?

Сразу про -sk: это security key, для FIDO/U2F (например YubiKey)

EC* ключи - основаны на эллиптических кривых

https://habr.com/ru/articles/335906/

ecdsa (elliptic curve dsa) это очень небольшой ключ, основанный на эллиптических кривых, но при этом более безопасный чем обычный -t rsa -n 1024

Как я понимаю, ed25519 по надёжности как ecdsa, но более быстый:

https://security.stackexchange.com/questions/50878/ecdsa-vs-ecdh-vs-ed25519-vs-curve25519

https://latacora.singles/2018/04/03/cryptographic-right-answers.html

Итог: лучше всего взять ed25519

sentry

 Есть такой пакет sentry, нужен для сбора событий, их учёту...  Прежде всего ошибок.

Можно воспользоваться как облачным решением с шансом что удалят инстанс, лимитами по интенсивности, месту итд.

Можно поднять на своём сервере, примерно так

https://develop.sentry.dev/self-hosted/

будет собран набор докер образов, доступ через порт 9000.

How to find your IP address in Linux

 https://opensource.com/article/18/5/how-find-ip-address-linux

curl ifconfig.me

curl -4/-6 icanhazip.com

curl ipinfo.io/ip

curl api.ipify.org

curl checkip.dyndns.org

dig +short myip.opendns.com @resolver1.opendns.com

host myip.opendns.com resolver1.opendns.com

curl ident.me

curl bot.whatismyipaddress.com

curl ipecho.net/plain

частые проблемы при смене версии mysql

 Первым делом проверять:

sql_mode (тут вообще разброд и шатание, самое простое но не очень правильное делать sql_mode = "")

innodb_strict_mode - та же мария 10.1 - офф, 10.5 - он. Выставляется

[mysqld]

innodb_strict_mode = OFF

https://mariadb.com/kb/en/troubleshooting-row-size-too-large-errors-with-innodb/

Ansible Role: Raspberry Pi (geerlingguy)

Ansible Role: Raspberry Pi

https://galaxy.ansible.com/geerlingguy/raspberry-pi

Методы обновления сертификатов lets encrypt (certbot)

 Классика:

certbot renew

но есть и готовый сервис

systemctl status certbot.timer

...

   Triggers: ● certbot.service

systemctl status certbot

○ certbot.service - Certbot

     Loaded: loaded (/lib/systemd/system/certbot.service; static)

     Active: inactive (dead) since Tue 2023-05-02 13:11:37 MSK; 1s ago

TriggeredBy: ● certbot.timer

Сервис, запускаемый по таймеру и обновляющий сертификаты.

Но нужно проверять: бывает что certbot renew работает, а сервис завершается с ошибкой.

PS можно доработать сервис (edit --full) и добавить в Exec в конец

--post-hook "nginx -t && systemctl reload nginx"

тогда не надо ничего придумывать с перезапуском nginx. При необходимости заменить на нужный сервис.