tag:dreamwidth.org,2011-04-07:750757 Swami Dhyan Nataraj Swami Dhyan Nataraj 2019-05-04T15:59:20Z tag:dreamwidth.org,2011-04-07:750757:979470 2019-05-04T15:59:20Z 2019-05-04T15:59:20Z public 2 Поставил ejabberd когда в /etc/hosts было<br /><br /><pre>127.0.0.1 localhost</pre><br />При разворачивании debbootstrap'ом туда имя хоста автоматом почему-то не пишется...<br />Поскольку кто-то из софта (ssh или sudo) ругается когда hostname не резолвится, добавил туда hostname<br /><br /><pre>127.0.0.1 localhost ejabberd</pre><br />ejabberd перестал останавливаться и запускаться... Как не прыгай.<br /><br />Убрал, все заработало обратно.<br /><br />Поменял тогда местами, перезагрузил контейнер.<br /><br /><pre>127.0.0.1 ejabberd localhost</pre><br />И все заработало... Как родное...<br /><br />Вот чего это?!<br /><br /><img src="https://www.dreamwidth.org/tools/commentcount?user=nataraj&ditemid=979470" width="30" height="12" alt="comment count unavailable" style="vertical-align: middle;"/> comments tag:dreamwidth.org,2011-04-07:750757:979315 2019-05-03T19:32:16Z 2019-05-03T19:32:16Z public 7 Чегой-то я не пОняла...<br />А с какого перепугу для работы xmpp dhyan@nataraj.su все ожидаю что у меня будет сертификат не только на тот хостнейм который в SRV прописан, но и nataraj.su<br />Они там немножко много кушать рыбного супа? Леценкрипт головного мозга?<br />Ладно некая неизвестная сетевая проверялка<br /><a href="https://xmpp.net/result.php?domain=nataraj.su&type=server">https://xmpp.net/result.php?domain=nataraj.su&type=server</a><br />Но и psi и pidgin тоже желают обоих сертификатов, при этом psi сертификатов не самоподписанных...<br />Это какой-то... позор! (тм)<br />Я в возмущении...<br />Не буду леценкрипта. И денег лишних платить тоже не буду!<br /><br /><img src="https://www.dreamwidth.org/tools/commentcount?user=nataraj&ditemid=979315" width="30" height="12" alt="comment count unavailable" style="vertical-align: middle;"/> comments tag:dreamwidth.org,2011-04-07:750757:979059 2019-05-03T14:16:45Z 2019-05-03T14:18:34Z public 0 Сегодня я узнал что у nginx'а есть особый код возврата 444 который по факту принудительно разрывает соединение.<br /><a href="http://nginx.org/en/docs/http/request_processing.html#how_to_prevent_undefined_server_names">http://nginx.org/en/docs/http/request_processing.html#how_to_prevent_undefined_server_names</a><br /><a name="cutid1"></a><br />Прекрасно работает для http и в чем-то наверное самый правильный способ отвечать на запросы левых доменов:<br /><pre>server { listen 80 default_server; return 444; # Немедленный разрыв соединения }</pre><br />Однако для https оно в прямом виде не работает если вместо 80 поставить 443 ssl то оно без разговоров почему-то начинает рвать все https соединения, в том числе и те, для которых есть подобающий server_name в других разделах.<br /><br />Если добавить туда информацию о каком-нибудь ключе и сертификате, то браузер сначала поругается на неверный сертификат, и если добавить его в исключения, то вот потом уже севрер разорвет соединение...<br /><br />Ходят легенды, что в более новых nginx'ах есть переменная $ssl_server_name в из которой можно добыть имя домена прилетевшее в SNI при установке TLS соединения, и тогда можно учинить проверку вида<br /><pre> if ( $ssl_server_name = nataraj.su) { return 444; }</pre><br />см. <a href="https://serverfault.com/questions/325485/nginx-how-to-prevent-an-exactly-named-ssl-server-block-from-acting-as-the-catch/910419#910419">https://serverfault.com/questions/325485/nginx-how-to-prevent-an-exactly-named-ssl-server-block-from-acting-as-the-catch/910419#910419</a><br />и <a href="https://nginx.org/en/docs/http/ngx_http_ssl_module.html#variables">https://nginx.org/en/docs/http/ngx_http_ssl_module.html#variables</a><br /><br />Но проверить мне это не удалось, потому что у меня боевой фронтенд nginx стар как моя жизнь, просто так его не обновишь, а городить отдельный огород чиста чтобы проверить мне лень...<br /><br />Поэтому пусть будет непроверенной информацией...<br /><br />Итого: того чего я хотел, а именно чтобы не обслуживаемые по https домены не обслуживались, я добился лишь частично. Нахрен шлют после добавления сертификата в исключения. Но есть надежда, что в светлом будущем это когда-нибудь получится... <br /><br /><br /><img src="https://www.dreamwidth.org/tools/commentcount?user=nataraj&ditemid=979059" width="30" height="12" alt="comment count unavailable" style="vertical-align: middle;"/> comments