Як відомо, логи у CloudFlare (CF) дивитися дуже незручно. А от в kibana – зовсім інша річ. Наше завдання зробити пересилку log’ів у logstash. Дана стаття припускає, що у вас вже є налаштований ELK стек і розкаже, як додати в існуючий стек новий source, тобто CF. Стаття буде розбита на 2 частини: Logstash і CF
Категорія: WWW
Проблема виглядає наступним чином: є зібраний nginx з openssl-3, але є старі клієнтські сертифікати з ключам 1024 біта і відповідно, стандартним чином воно не працює, бо для openssl-3 ключ повинен бути мінімум 2048 біт і маємо помилку:
"FAILED:CA certificate key too weak"Рішення просте – CipherString = DEFAULT@SECLEVEL=0, але не хочеться ламати все інше на цьому хості, тому просто так вставити це в /etc/ssl/openssl.cnf не можна.
Виявляється, можна через ENV в nginx передавати OPENSSL_CONF, де вказати шлях до кастомного файлу openssl.cnf.
В деяких випадках хочеться обійтися однією конфігурацією nginx для багатьох сайтів. Але у випадку з SSL це не завжди можливо. Починаючи з 1.15.9 можна використовувати змінні для задання сертифікатів.
map $ssl_server_name $domain {
default $ssl_server_name;
~(([^\.]+)\.([^\.]+))$ $1;
}
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
server_name _;
add_header Content-Type text/html;
return 200 "domain: $domain, document_root: $document_root, request_uri: $request_uri";
ssl_certificate /etc/letsencrypt/live/$domain/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/$domain/privkey.pem;
}
Дана конструкція буде працювати, якщо у вас один і той же SSL issuer, SSL chain. Так, в документації nginx сказано
Only OpenSSL 1.0.2 or higher supports separate certificate chains for different certificates. With older versions, only one certificate chain can be used.
але по факту не працює.
Категорії
[jira] Slack alerts
Зʼявилася задача повідомляти про ticket’и jira у slack. На вигляд завдання просте, але є нюанси. google каже, що треба створити новий app у slack’y, згенерувати webhook URL, створити новий webhook у jira вставити його туди.
І… воно не працює. Точніше, якщо тестово відправлєш через curl, то все приходить у slack, а якщо через jira – то отримуєш 400 помилку. Щоб дізнатися, що саме не так, треба ввімкнути debug для webhook’ів у jira. Робиться це так:
Категорії
[nginx] URL encode
Иногда бывает ситуация, когда нужно в location’e написать regexp с nonASCII символами. Тогда на помощь приходит URL encode. Нюанс в том, что вместо % (процент) нужно использовать \x (слеш + “х”). Итого, если в браузере URL выглядит так
test%20test
то в nginx.conf это будет так:
test\x20test
Да, именно с таким сообщением начала падать kafka спустя некоторое время после запуска. Включение режима debug немного увеличило “понятность”
ERROR Error while accepting connection (kafka.network.Acceptor)
java.net.SocketException: Invalid argument
at sun.nio.ch.Net.setIntOption0(Native Method)
at sun.nio.ch.Net.setSocketOption(Net.java:341)
at sun.nio.ch.SocketChannelImpl.setOption(SocketChannelImpl.java:190)
at sun.nio.ch.SocketAdaptor.setBooleanOption(SocketAdaptor.java:271)
at sun.nio.ch.SocketAdaptor.setTcpNoDelay(SocketAdaptor.java:306)
at kafka.network.Acceptor.accept(SocketServer.scala:654)
at kafka.network.Acceptor.run(SocketServer.scala:579)
at java.lang.Thread.run(Thread.java:748)
Данная ошибка начала возникать после обновления simpleSAML. Причём появляется только на один из ресурсов на который настроено SSO и не у всех, а у нескольких человек. С чем конкретно связано – пока неясно. Начал исследовать, что общего у этих проблемных человек – только то, что работают с одним внешним ресурсом и всё. Не густо…
Категорії
[nginx] proxy_pass DNS name
При использовании proxy_pass, особенно если в качестве upstream’ов используется DNS name есть один нюанс, который хоть и описан в документации, но требует пояснения. Ниже цитата из рассылки nginx:
Очень часто это является проблемой при построении редиректов, когда у вас больше 1 домена. Следующая конструкция выглядит работоспособной:
return 301 https://$server_name$request_uri;
Всё работает, когда у вас всего 1 домен в server_name. А когда 2 и больше, то для них redirect работает не правильно (он редиректит на самый первый домен в server_name). А всё потому, что нужно вместо $server_name использовать хост. В документации написано следующее:
- $server_name: имя сервера, принявшего запрос
- $host: в порядке приоритета: имя хоста из строки запроса, или имя хоста из поля “Host” заголовка запроса, или имя сервера, соответствующего запросу
Цитату взял с рассылки про nginx и привожу как есть:
С reload’ом на Linux’е имеется достаточно типичная проблема: в
отличие от других операционных систем, linux не позволяет
одновременно открыть listen-сокеты на *:80 и <ip>:80.