Включение авторизации только для пользователей из Интернет.
Есть сервер nginx запущенный на шлюзе, локальная сеть и два провайдера (два
public ip).
Есть сайт вида:
server {
listen 80;
server_name site.example.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl;
server_name site.example.com;
...
}
Хочу добавить авторизацию, но только для тех кто приходит через Интернет.
Для внутренней сети всё должно работать без авториазции.
Самый простой вариант это использовать listen, и описать один и тот же сайт
(конечно с использованием include - дабы не дублировать одно и тоже) два
раза. Добавить авторизацию туда где сервер будет слушать на внешних IP.
Но если внутренний ip - статичен. То внешние pub_ip периодически всё таки
меняются. И при смене внешнего ip мне нужно будет не забыть о конфигах
nginx. А я не хочу об этом помнить.
Как решить эту задачу ?
Спасибо.
--
Faithfully yours,
CVision Lab System Administrator
Vladimir Skubriev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
nginx в роли frontend к owncloud
Внутри сети есть owncloud с apache.Снаружи на public ip слушает nginx, установленный из репозитория (http://nginx.org/packages/ubuntu) Мне нужно чтобы при обращении к nginx frontend пользователь "пробрасывался" на внутренний сервер. У меня есть два пути как я понял: 1. iptables, но тогда мне придеться использовать другой порт 80 и 443 снаружи слушает nginx.Хотя я не исключаю, что через iptables возможно сделать умный проброс в зависимости от заголовка, но опять же ssl точно не будет работать. Поэтому этот вариант не подходит. 2. Заставить nginx "проксировать" на внутренний сервер. nginx, который у меня стоит собран поидее или без поддержки webdav или с поддержкой webdav но не webdav-ext. Точнее сказать не могу. Но как я понимаю, для функционирования owncloud прокси должен поддерживать webdav-ext. Вопрос: Возможно ли как то настроить nginx на "проксирование" webdav к apache другим способом ? Мне на днях попались такие строки: ... rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect; rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect; rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;... rewrite ^/.well-known/carddav /remote.php/carddav/ redirect; rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;... из: https://github.com/onddo/owncloud-cookbook/blob/master/templates/default/nginx_vhost.erb И я подумал, возможно они мне могут помочь. Но я не понимаю их смысла. Объясните пожалуйста. Спасибо. --Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
server для zope managment interface
Есть бэкэнд с запущенным plone сайтом и интерфейсом управления zope Есть конфиг nginx - frontend: upstream zope { server 192.168.128.16:8080;} server { # ENABLE FOR redirect always to SSL site let's go ssl only now. #rewrite ^ https://$server_name$request_uri? permanent; listen 80; server_name www.example.com; access_log /var/log/nginx/example-access.log; error_log /var/log/nginx/example-error.log; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 0; client_body_buffer_size 128k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; location / { proxy_pass http://192.168.128.16:8080; rewrite ^/(.*)$ /VirtualHostBase/http/example.ru:80/exampleru/VirtualHostRoot/$1 break; } location ~* /plone/ { proxy_pass http://192.168.128.16:8080; #rewrite ^(.*) http://192.168.128.16:8080/manage_main; allow 192.168.128.0/24; allow 192.168.129.0/24; allow 127.0.0.1; deny all; } } Сайт example.com открывается, правда частично без картинок, опять же подозреваю, что дело в неправильном rewrite или у меня не отдает их zope. Но эта проблема будущего. Сейчас меня интересует как мне сделать так, чтобы интерфейс управления zope открывался в браузере при обращении к example.com/plone. Сам интерфейс управления(http://192.168.128.16:8080/manage_main) открывается вместо сайта, если закомментировать rewrite. Я даже пытался сделать отдельный location ~* /plone/, но что то пока у меня совсем не получается. Вопрос что неправильно я делаю в location ~* /plone/ { proxy_pass http://192.168.128.16:8080; #rewrite ^(.*) http://192.168.128.16:8080/manage_main; allow 192.168.128.0/24; allow 192.168.129.0/24; allow 127.0.0.1; deny all; } или ошибка совсем в другом месте ? Как это работает можете объяснить на пальцах - что за чем происходит в моем конкретном случае отображения интерфейса управления zope в url вида example.com/plone ? Самому ни как не получается разобраться.Можете ткнуть пальцем в документацию дополнительно. Буду благодарен.Спасибо. --Faithfully yours, Vladimir Skubriev ___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: wget static file 1024mb localhost first attepmt 167Mb/sec, second attempt 22 Mb/sec, third attempt 47 Mb/sec - WHT ?
Да это я и так знаю) 20.02.2014, 17:36, Валентин Бартенев vb...@nginx.com: On Thursday 20 February 2014 09:51:28 Vladimir Skubriev wrote: неа на диск обычного компа рабочего на линуксе ( Так изучите как дисковое I/O в линуксах работает. При первом запуске большая часть файла у вас осела в памяти, а затем он пошел сбрасывать странички на диск и тот просел. могу конечно для чистоты эксперимента сделать в /dev/null проверю с /dev/null wget http://st.example.lab/1024mb_file -O /dev/null ... 2014-02-20 09:47:42 (70.3 MB/s) - `/dev/null' saved [1073741824/1073741824 Тут вы прочитали файл с диска. wget http://st.example.lab/1024mb_file -O /dev/null next attepmts: 100%[===] 1,073,741,824 1.37G/s in 0.7s А тут уже из пейджкэша. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
wget static file 1024mb localhost first attepmt 167Mb/sec, second attempt 22 Mb/sec, third attempt 47 Mb/sec - WHT ?
wget static file 1024mb localhost first attepmt 167Mb/sec, second attempt 22 Mb/sec, third attempt 47 Mb/sec - WHT ? Есть сервер на нем стоит nginx из ubuntu 12.04 latest. Сервяться на нем пару тройка дистрибов для локальных целей, по сути их ни кто ни когда не качает. Проверка проводилась когда сервер практически не нагружен. Там просто не чему нагружать. Думаю дело не в этом. Сервиться также статический файл размером ровно гигабайт - для тестов. Захожу я на этот сервер и делаю wget локально. Но точнее обращаюсь я к внутреннему адресу его, т.е. не 127.0.0.1 а 192.168.1.1, а точнее даже к его servername.example.lan Так вот первый раз он скачивается со скоростью 167 Мегабайт в секунду Тут же - второй раз уже 22 Мб/сек. Третий - 47 Мб/сек. WTF ? Причем месяц назад я по очереди с каждого компа в сети (15 штук) скачивал этот же файл со скоростью гигабитной сети, т.е 112 Мб/сек. Спасибо. --Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: wget static file 1024mb localhost first attepmt 167Mb/sec, second attempt 22 Mb/sec, third attempt 47 Mb/sec - WHT ?
неа на диск обычного компа рабочего на линуксе ( могу конечно для чистоты эксперимента сделать в /dev/null проверю с /dev/null wget http://st.example.lab/1024mb_file -O /dev/null ... 2014-02-20 09:47:42 (70.3 MB/s) - `/dev/null' saved [1073741824/1073741824 wget http://st.example.lab/1024mb_file -O /dev/null next attepmts: 100%[===] 1,073,741,824 1.37G/s in 0.7s Вот те на! Не понимаю. 19.02.2014, 22:07, Валентин Бартенев vb...@nginx.com: On Wednesday 19 February 2014 22:05:43 Vladimir Skubriev wrote: Просто мне было интересно узнать как может загрузка процессора и загрузка диска (не значительные) влиять на отдачу файла через по сути localhost. [..] Ну а сохраняли вы его куда при этом, в /dev/null надеюсь? -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: wget static file 1024mb localhost first attepmt 167Mb/sec, second attempt 22 Mb/sec, third attempt 47 Mb/sec - WHT ?
Намек понятен. Что посоветуете почитать маны или может книжки есть хорошие для админов по этой теме? 19.02.2014, 22:50, Dmitry dmitry.goryai...@gmail.com: В хайлоад было три проблемы: руки, tcp/ip стэк и файловая система. Что-то появилось нового? 19.02.2014 22:05 пользователь Vladimir Skubriev vladi...@skubriev.ru написал: Просто мне было интересно узнать как может загрузка процессора и загрузка диска (не значительные) влиять на отдачу файла через по сути localhost. Ведь пакеты адресованные comp1 от comp1 не выходят за пределы comp1. Просто странно что такая большая разница на не загруженном сервере. И еще вопрос как это тестирование организовать в смысле через что построить графики в моем случае проще ? top, iftop, atop, htop не совсем наглядны в том плане, что там все быстро меняется и не возможно сопоставить скорость отдачи загрузке дисковой подсистемы и загрузке процессора. Как (с помощью каких средств) это делают ? Что гуглить в плане анализа влияния загрузки на отдачу ? Вот в принципе и все что я хотел спросить. Остальное уже моя работа естественно. 19.02.2014, 19:45, Михаил Монашёв postmas...@softsearch.ru: Здравствуйте, Vladimir. Посмотрите на top, например. На статистику по диску... -- С уважением, Михаил mailto:postmas...@softsearch.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru , ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
17.01.2014 12:09, Васильев Zmey! Олег пишет: В таком случае мы усложняем схему и у нас половина клиентов может потеряться не на умершем канале в офис, а на упавшей ВПСке. Тогда нужен полноценный failover и всё такое. Но автор топика уже пояснил свои цели и намерения, так что схемы с одной VPS-frontend хватит, полагаю. Так сказать, чтобы подтвердить то, как я понял что мне лушче сделать - отвечу Вам. Если умрет одна ВПС-ка - то это равнозначно тому, что в городе не будет Интернет. Что в принципе не очень критично, т.к. такое бывает редко. День без сайта мы потертим. А более дня я считаю со сторону хостера не приемлево в принципе. -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
17.01.2014 12:26, Daniel Podolsky пишет: 2014/1/17 Vladimir Skubriev vladi...@skubriev.ru: День без сайта мы потертим. А более дня я считаю со сторону хостера не приемлево в принципе. Перекинуть DNS на другого хостера можно значительно быстрее, чем за день. Можно поднять резервный прокси в амазоне. Вернее - подготовить AMI. Он, когда выключен, денег не ест. Трафик там, правда, довольно дорогой... Спасибо я обязательно обращу на этот совет внимание руководства. Тем более что они положительно относятся к амазону. -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
15.01.2014 11:46, Pavel V. пишет: Тоже, пожалуй, вклинюсь в тред. Ну так никто не мешает сделать две (или более) ВПС-ок фронт-ендов. От них сделать каналы до серверов (с каждой впски через каждый из аплинков) Вы имеете в виду VPN ? В общем случае тут же можно и внутренний BGP запустить, чтобы от впски канал выбирался нужным образом. если BGP можно реализовать стандартными спсобами linux то я рассмотрю этот вариант. На эти же впски можно выкинуть некий статический контент... Для этих же впсок можно прислюнявить DNS с ненулевым TTL, чтобы исключать впски из схемы в случае их падения.. Я уже если честно запутался во все возможных вариантах. Можете пояснить куда его прислюнявить и зачем ? Если положим есть у нас fronend с nginx на который ссылается A запись www.example.com и example.com. Есть Бэкенд, который доступен только для frontend по IP адресу. Зачем еще DNS сервер(ы) не пониманию если честно. Схему можно усложнять до бесконечности, были бы мозги на плечах и желание/ (и необходимость!) этими наворотами заниматься. -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
14.01.2014 12:24, s...@bykov.odessa.ua пишет: Зачем вам вообще эти хостинги-шмостинги, сервера асинхронные, днс-ы непонятные. Ящетаю так - захотелось купить молочка - сходи на рынок, пообщайся с людьми, поторгуйся в конце концов Нормальные люди днем уголь разгружают или лес рубят, а вечером с друзьями в баре пиво сидят пьют. А эти компьютерщики уткнулись в свои мониторы, тыкают непонятные букофки по кнопочкам. Сидят что-то выискивают в своих интернетах. Что вы там выискиваете? Коль вздумалось что-то найти - выйди ты, не поленись, на крыльцо, послушай, о чем бабки сплетничают, впитай народную мудрость как береста. Вы это серьезно ? Хотелось бы тогда услышать ваше мнение по поводу всех этих хостингов и иже с ними. Ну так для общего развития - не помешает. А если по кнопочкам охота потыкать - возьми гармошку, выйди в честной народ, спой колядки и получи благодарственный калач (а может и окорок зажиточный крестьянин в мешок покладет). Тем более Новый год сегодня! С праздником! Да такие комментарии только под новый год и увидишь. Спасибо. Рассмеялся от души. А можно на заметку взять ? Это вы сейчас все выдумали или заготовочка была ? -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
14.01.2014 13:30, Валентин Бартенев пишет: On Tuesday 14 January 2014 13:23:29 Vladimir Skubriev wrote: [..] Куда ни плюнь везде свои ньюансы. Так а что после ваших слов посоветуете делать? Или так: На что обратить внимание? Просто я уже даже настроился на TTL а 1 минуту. А тут на тебе очередная уточка. Я, как уже тут прозвучало, посоветовал бы взять нормальный хостинг, полагаю хороший датацентр будет всяко лучше, чем свой велосипед. И если уже боитесь весь проект выносить на него, то можно хотя бы поставить nginx и настроить проксирование с кэшированием. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru Спасибо за еще один совет. У нас используется redmine и много репозиториев. Возникает вопрос что кэшировать ? Основная масса - это репозитории, которые нельзя выносить наружу. Сам redmine - не могу сказать. Т.к. совсем не знаком с темой кэширования. Шеф сказал Eat you dog ... Че то там. Типа нам не нужен Atlassin или что то еще т.к. он не доверяет им вплане - а вдруг украдут идеи. Есть такое подозрение, что как раз купить хостинг для frontend в бэкэнды держать у себя. Но тогда вопрос: на сколько это будет тормозить ? Если каналы у нас 10 и 25 мегабит оптика. Не очень сведую в этом вопросе. Хотя и пожалуй стоит рассмотреть данный вариант. Так как он по сути тоже интересен и совсем не сложен в реализации в отличии от танцов c DNS, TTL и т.д. Если честно я даже о таком подумать не мог. Даже и в мыслях такого не было. Хотя что в этом такого поидее. -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
14.01.2014 13:31, damir bikmuhametov пишет: On Tue, Jan 14, 2014 at 01:20:56PM +0400, Vladimir Skubriev wrote: Далеко не всегда можно выносить информацию на сторонние ресурсы. Кстати у меня как раз такой случай. Слижком уж ценна разработка. поставьте в vps nginx и настройте на нем проксирование на два бакенда + кеширование статики. Спасибо 1+1=2 за vps с nginx . Буду рассматривать. -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
14.01.2014 16:24, Васильев Zmey! Олег пишет: Вклинюсь в тред. Если вам нужно организовать надёжность связи с вашими серверами, у которых два аплинка, то да, вам просто нужна ВПС-ка фронтенд. Если вы хотите общую отказоустойчивость, то у вас появляется новая единая точка отказа - внешняя ВПС-ка. Спасибо. Мне достаточно того, чтобы изнутри локальной сети можно было работать в Интернет и снаружи был виден сайт ) Все намного проще ) Соответсвенно ВПС-ка и фронтенд. -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
13.01.2014 20:41, Daniel Podolsky пишет: Если сделать еще одну запись А на IP второго провайдера, но при этом этот второй провайдер будет отключен как будет работать соединение с веб сервером и севером вообще? Как вообще клиенты будут работать нормально или же если не предсказуемо ? Половина попыток подключиться будет обламываться по таймауту. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru т.е. это не дело для продакшена ? в итоге клиенты будут не довольны ? -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
13.01.2014 21:46, VovansystemS пишет: Половина попыток подключиться будет обламываться по таймауту. в итоге клиенты будут не довольны ? да. я уже много лет с нетерпением жду того момента, когда браузеры научатся понимать SRV записи типа а они имеют вид: _service._proto.name. TTL class SRV priority weight port target. т.е. когда-нибудь будет возможно сделать то, что сейчас реализовано с mx записями - задавать вес для айпишников так: _http._tcp.example.com. 86400 IN SRV 0 10 80 ip1.example.com. _http._tcp.example.com. 86400 IN SRV 0 20 80 ip2.example.com. тогда будет счастье и отказоустойчивость без ботлнеков.. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru Странно что уже много лет. Видимо это кому то нужно ( Всмысле существования и процветания бот нет сетей. Если я конечно правильно понимаю этот вопрос. -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
13.01.2014 22:22, Валентин Бартенев пишет: On Monday 13 January 2014 20:17:34 Sergey Kobzar wrote: On 01/13/14 19:46, VovansystemS wrote: Половина попыток подключиться будет обламываться по таймауту. в итоге клиенты будут не довольны ? да. я уже много лет с нетерпением жду того момента, когда браузеры научатся понимать SRV записи типа а они имеют вид: _service._proto.name. TTL class SRV priority weight port target. т.е. когда-нибудь будет возможно сделать то, что сейчас реализовано с mx записями - задавать вес для айпишников так: _http._tcp.example.com. 86400 IN SRV 0 10 80 ip1.example.com. _http._tcp.example.com. 86400 IN SRV 0 20 80 ip2.example.com. тогда будет счастье и отказоустойчивость без ботлнеков.. Ну фэловер и сейчас решается с пом. named + dlz + какая-ть чекалка. Естественно NS сервер должен быть где-то в ДЦ. [..] Едва ли это можно назвать фэловер при ненулевом TTL. -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru А нулевой TTL используется? -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ?
14.01.2014 08:17, Лапочкин Константин пишет: Можно организовать схему, когда живость сайта будет проверять сам ДНС. Описание http://habrahabr.ru/post/177145/ -Original Message- From: nginx-ru-boun...@nginx.org [mailto:nginx-ru-boun...@nginx.org] On Behalf Of Sergey Kobzar Sent: Tuesday, January 14, 2014 12:57 AM To: nginx-ru@nginx.org Subject: Re: две А записи в DNS - будет ли тормозить, если один из провайдеров отвалится ? On 01/13/14 20:30, VovansystemS wrote: Кстати, готовые решения есть? А то постоянно приходиться самому че-то сочинять. есть route 53 амазона, он умеет проверять на доступность и изменять днс записи по соответствующим правилам. Не-не. Сервисы, котоырй считают каждый запрос - не наш выбор. Мы еще не столько много зарабатываем ;). Едва ли это можно назвать фэловер при ненулевом TTL. да :( ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru Спасибо. Очень хорошая подсказка. Только вопрос: Ведь здесь описывается несколько дата центров. В моем варианте - это не вариант. У меня просто двай провайдера и серверная в одном здании. В таком случае как лучше организовать доступ к сайту компании, при наличии двух провайдеров? -- -- Faithfully yours, Vladimir Skubriev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
upstream prematurely closed connection while reading response header from upstream
Вопрос, если в логе nginx появляется сообщение (раз в 10-20 обновлений страницы) upstream prematurely closed connection while reading response header from upstream и при этом на бэкенде в логах конкретно об этом запросе ни чего нет но предыдущие запросы и последующие запросы нормально логируются. Зачит куда нужно копать ? Я понимаю, что дело в бэкенде, тем более, что я менял бэкенд - со старым все работает нормально. Проверял работу через HTTPS поднятом на nginx c валидными сертификатами. Использовать для тестов 443 порт не могу, т.к. через него сейчас работают люди со старым сервером. Другой backend - очень старая версия redmine под apache и из старой ubuntu 10.04 Новый backend - lxc контейнер с новой версией redmine и новым apache из ubuntu 12.04 на том же же серевере где стоит прокси nginx. Спасибо. -- С Уважением, специалист по техническому и программному обеспечению, системный администратор Скубриев Владимир ~~~ Россия, Ростовская область, г. Таганрог тел. моб: +7 (918) 504 38 20 skype: v.skubriev icq: 214-800-502 www: skubriev.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Сервер по-умолчанию для конкретного домена
01.11.2013 14:07, Никита Кардашин пишет: Так, я, видимо, не очень правильно описал проблему. Попробую еще раз: - Есть домены: domain1.tld domain2.tld domain3.tld Сами главные домены хостятся где-то в другом, отличном от нашего сервера, месте. Для каждого из них есть wildcard SSL-сертификат. На нашем сервере хостятся приложения, доступные по поддоменам этих доменов (app1.domain2.tld, app10.domain3.tld, etc). Для каждого приложения создан конфиг в sites-enabled с описанием сервера (где задается и нужный SSL-сертификат, в зависимости от того, в каком домене находится приложение). Доступны они только по SSL (по сертификату *.domain.tld). Но иногда приложения удаляются, а ссылки на них где-то живут. Мне нужно каким-то образом реализовать возможность редиректить все запросы к адресам а-ля https://appX.domainX.tld/, в случае, если приложение уже не существует (т.е. сервер appX.domainX.tld не описан в конфиге nginx). Пока домен был один - я эту проблему решал просто, определил в конфиге один сервер с признаком default и там уже в location / осуществлял редирект на нужный сайт. Все прекрасно работало. А теперь сайтов стало три. В описании default-сервера я могу задать только одну пару сертификат:ключ, соответственно, те, кто придет по appX.domainX.tld (в случае, если домен отличается от того, чей сертификат прописан) в default-сервер получат в браузере ошибку (и не получат редирект). Прописать для каждого из доменов сервер с server_name *.domainX.tld я тоже не могу, т.к. тогда туда пойдут не только запросы к несуществующим приложениям, а вообще ВСЕ запросы (т.е. в приложение никто не попадет). Т.е. проблема моя не в том, что мне нужно иметь несколько SSL-сервисов на одном IP (это-то прекрасно работает, тут проблем нет), а в том, что мне нужно каким-то образом иметь несколько default-серверов с поддержкой SSL (либо иметь возможность задавать приоритеты серверам, чтобы запрос всегда попадал в более точный сервер (appX.domainX.tld), а не в wildcard *.domainX.tld). Как мне из этой ситуации выйти? Из документации Более общее решение для работы нескольких HTTPS-серверов на одном IP-адресе ---расширение Server Name Indication протокола TLS http://en.wikipedia.org/wiki/Server_Name_Indication(SNI, RFC 6066), которое позволяет браузеру передать запрашиваемое имя сервера во время SSL handshake, а значит сервер будет знать, какой сертификат ему следует использовать для соединения. Однако, поддержка SNI браузерами ограничена. Сейчас это поддерживается браузерами начиная со следующих версий: Другим способом является использование wildcard-сертификата, например|*.example.org|. Такой сертификат защищает все поддомены указанного домена, но только на заданном уровне. Под такой сертификат подходит|www.example.org|, но не подходят|example.org|и|www.sub.example.org|. Два вышеуказанных способа можно комбинировать. Сертификат может одновременно содержать и точное, и wildcard имена в поле SubjectAltName, например|example.org|и|*.example.org|. Боюсь что это не может быть, т.к. не могу все клиенты поддерживать SNI. -- С Уважением, специалист по техническому и программному обеспечению, системный администратор Скубриев Владимир ~~~ Россия, Ростовская область, г. Таганрог тел. моб: +7 (918) 504 38 20 skype: v.skubriev icq: 214-800-502 www: skubriev.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: почему при запросе на 443 порт я попадаю не на прописанный в конфиге бэкэнд
On 10/16/2013 04:56 PM, Anton Yuzhaninov wrote: On 10/16/13 16:53, Vladimir Skubriev wrote: 2. Почему браузер после ввода запроса https://redmine.examplelab.com открывает страницу без https, т.е. http://redmine.examplelab.com и соответсвенно я вижу страницу backendredmine Возможно бэкенд выдает редирект на версию без http, посмотрите все запросы от браузера через firebug или аналогичные инструменты. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru Смотрел нет ни каких редиректов вроде. Я тут сделал вчера себе сертификаты от StartSSL а сегодня с утра все заработало как надо. Т.е. как должно было работать. -- С Уважением, специалист по техническому и программному обеспечению, системный администратор Скубриев Владимир ~~~ Россия, Ростовская область, г. Таганрог тел. моб: +7 (918) 504 38 20 skype: v.skubriev icq: 214-800-502 www: skubriev.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
