Добрый день уважаемые!
Выставляю на Ваш суд свою поделку. Просьба сильно не пинать:) Конечно ещё
сыровата... но я уже кушаю:)))
Просто не нашёл аналогичного... может плохо искал.... вот и пришлось
покодить немножко. Надеюсь полезная будет:)
Сервис "ITCOD-DISK" Облачное хранилище.
-- Copyright (c) 2015 by Yura Vdovytchenko (max(a)itcod.com)
-- Copyright (c)itcod 2010-2015
-- version: 15.06.27
-- license: MIT
Назначение: Сетевой диск(хранилище) файлов по технологии WEBDAV.
С публикацией по http/https и индексный файл с контрольными суммами
md5/etc.
Предназначен для хранения и публикации NoSQL информационных массивов.
Принцип: Сервис-ориентированная архитектура построения. Nginx обеспечивает
стандартный протокол WEBDAV over HTTP/HTTPS. Lua-модули itcod обеспечивают
расширение функций и сетевые сервисы управления ITCOD-DISK'ом.
ITCOD UI WWII обеспечивает WEB-интерфейс между пользователем и сервисами.
ОТЛИЧИЕ ОТ АНАЛОГОВ
NoLAMP NoLEMP NoSQL SOA
На сервере только Nginx + Lua и никаких PHP SQL и т.д.
БАЗОВЫЕ КОМПОНЕНТЫ ITCOD-DISK
LINUX - операционная система
NGINX - http daemod (with WebDAV and Lua)
LUA - язык программирования
Resty - библиотека Lua
add - дополнительные библиотеки (см. require в *.lua)
ITCOD Lua Modules & Services - модули SOA ITCOD для операций с хранилищем
ITCOD WWII - web-интерфейс для ITCOD-DISK (в разработке)
БАЗОВЫЕ КОМПОНЕНТЫ ITCOD Lua Modules & Services
auth-dav.lua - авторизатор для HTTP/HTTPS/WEBDAV
md5index.lua - расширитель функций autoindex NGINX
itcod-user.lua - создание пользовательских юзербоксов на диске WEBDAV
itcod-exchange.lua - сервис транспорта файлов между пользователями и
дисками
itcod-search.lua - REST-сервис авторизованного поиска информации в закрытых
пользовательских массивах
libs/ - библиотека иконок типов файлов для md5index
Подробнее о компанентах см. https://ihome.itcod.com/max/project/
КОНФИГУРАЦИЯ NGINX
nginx version: nginx/1.7.11
built by gcc 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC)
TLS SNI support enabled
configure arguments:
--prefix=/usr/share/nginx
--sbin-path=/usr/sbin/nginx
--conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log
--http-client-body-temp-path=/var/lib/nginx/tmp/client_body
--http-proxy-temp-path=/var/lib/nginx/tmp/proxy
--http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi
--http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi
--http-scgi-temp-path=/var/lib/nginx/tmp/scgi
--pid-path=/run/nginx.pid
--lock-path=/run/lock/subsys/nginx
--user=nginx
--group=nginx
--with-pcre-jit
--with-debug
--with-file-aio
--with-ipv6
--with-http_ssl_module
--with-http_realip_module
--with-http_addition_module
--with-http_xslt_module
--with-http_image_filter_module
--with-http_geoip_module
--with-http_sub_module
--with-http_dav_module
--add-module=/usr/src/nginx-dav-ext-module-master
--with-http_flv_module
--add-module=/usr/src/f4f-hds-master
--with-http_mp4_module
--with-http_gzip_static_module
--with-http_random_index_module
--with-http_secure_link_module
--with-http_degradation_module
--with-http_stub_status_module
--with-http_perl_module --with-mail
--with-mail_ssl_module
--with-http_auth_request_module
--add-module=/usr/src/echo-nginx-module-master
--add-module=/usr/src/nginx_md5_filter-master
--add-module=/usr/src/ngx_devel_kit-master
--add-module=/usr/src/lua-nginx-module-master
--with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic'
--with-ld-opt=' -Wl,-E,-rpath,/usr/local/lib'
КОНФИГУРАЦИЯ ВИРТУАЛЬНОГО WEB-СЕРВЕРА (WEBDAV)
Приведена конфигурация nginx работающего на виртуальной машине
за проксирующим первичным nginx. Для работы на первичном вам необходимо
изменить listen на 80 и 443. А так же не забудьте поправить основные
настройки на ваши собственные (имена сервера и т.д.)
Файл ihome.conf
server {
listen 7070;
server_name "~^ihome\d+\.itcod\.com$"
ihome.virtual.ko
ihome.itcod.com
;
server_name_in_redirect off;
expires epoch;
ssl off;
#default_type application/octet-stream;
set_real_ip_from 10.255.255.7;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
access_log /var/log/nginx/ihome.itcod.com-access.log main;
resolver 10.255.255.1 [::1]:5353;
charset utf-8;
set $dir /opt/home;
set $testdir $dir$uri;
set $uri_type none;
if (-d $testdir) { # такая папка есть
set $uri_type dir;
rewrite ^(.*)$ $1/;
rewrite ^(.*)/+$ $1/;
}
if (-f $testdir) { # такой файл есть
set $uri_type file;
}
if ($request_method = "MKCOL") {
rewrite ^(.*)$ $1/;
rewrite ^(.*)/+$ $1/;
set $uri_type dir; #клиент webdav создает папку
}
if ($request_method = "PUT") {
set $uri_type file; #передаем только файлы
}
if ($request_method = "POST") {
set $uri_type file; #постим только файлы
}
set $sadm_passwd .uhtpsw;
set $user_passwd .htpasswd; #user:password[crypt(3)/md5/sha1]
set $user_permit .htpermit; #user:GET,PUT,....OPTIONS
set $user_permit_default GET,PROPFIND,OPTIONS; # Allow
merge_slashes on;
location / {
limit_req zone=itcod burst=200 nodelay;
limit_rate 2048k;
access_by_lua_file /etc/nginx/lua/auth-dav.lua;
dav_methods PUT DELETE MKCOL COPY MOVE;
dav_ext_methods PROPFIND OPTIONS;
create_full_put_path on;
dav_access user:rw group:rw;
client_body_temp_path /opt/itcod-dav.tmp/;
client_max_body_size 0;
autoindex on;
root $dir;
header_filter_by_lua_file /etc/nginx/lua/itcod-exchange.lua;
set $md5index on; #on/off nil=off # вкл/выкл обработчик
set $md5index_hash md5; #none/md5/md4/sha1/sha/ripemd160 nil=none # тип
выводых хэшей
set $md5index_size 50000; #kb nil=unlimit # не считать для файлов более N
kb
set $md5index_path on; #on/off nil=off # заменять относительный путь
ссылок на полный URI
set $md5index_nonblank on; #on/off nil=off # заменить множественные пробелы
одним
set $md5index_type on; #on/off nil=off # добавит в строки описание типа
file/directory/etc...
set $md5index_ico http://ihome.itcod.com/max/projects/libs/icons16ext/; #
путь к библиотека иконок
set $md5index_icopref icon-; # префикс имени файла иконки
#set $md5index_icosuf -icon; # суфикс имени файла иконки
set $md5index_icoext .gif; # расширение файла иконки
set $md5index_win _blank; # target window for !winext! files
set $md5index_winext htm.html.txt; # file extension for target windows
body_filter_by_lua_file /etc/nginx/lua/md5index.lua; # addon
обработчик
}
location ~/\.uht {
deny all;
}
location /search/ {
content_by_lua_file /etc/nginx/lua/itcod-search.lua;
}
location /user/ {
content_by_lua_file /etc/nginx/lua/itcod-user.lua;
}
}
ПРИМЕЧАНИЕ
Для программистов адекватных perl, проблем определить и загрузить
недостающие
модули require не составит труда. В случае если у вас, что то не получается
пишите тут или на max(a)itcod.com обязательно помогу.
ТЕКУЩИЕ РАБОТЫ
Формирование WebUI ITCOD-DISK
Posted at Nginx Forum: http://forum.nginx.org/read.php?21,259941,259941#msg-259941
Здравствуйте!
У меня наверное быстро решимая
проблема, но я просто решение вопроса
не вижу.
Работает у меня nginx 1.0.8
--------
nginx: nginx version: nginx/1.0.8
nginx: configure arguments: --with-http_gzip_static_module
--with-openssl=/usr/include --with-http_stub_status_module
--http-proxy-temp-path=/dev/shm/nginx/proxy_temp
--http-fastcgi-temp-path=/dev/shm/nginx/fastcgi_temp
--http-uwsgi-temp-path=/dev/shm/nginx/uwsgi_temp
--http-scgi-temp-path=/dev/shm/nginx/scgi_temp
--http-client-body-temp-path=/dev/shm/nginx/client_body_temp
--http-log-path=/var/log/nginx/access.log
--error-log-path=/var/log/nginx/error.log
--conf-path=/etc/nginx/nginx.conf --user=www-data --group=www-data
--------
и в соответствующем файле у меня стоит
в секции Server:
--------
location /status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
------
всё такие я получаю ошибку 404, когда я на
сервере наберу "GET domain/status"
В чем может состоить проблема?
Спасибо вам большое.
Андрей
Posted at Nginx Forum: http://forum.nginx.org/read.php?21,216178,216178#msg-216178
Здравствуйте.
Рад сообщить о выпуске новой версии NGINX Unit.
В этом выпуске мы продолжили развивать возможности внутренней маршрутизации
для более разнообразного и точного распределения запросов. Кроме того, для
упрощения работы с массивами в конфигурации, управляющий API теперь поддерживает
операции POST.
Документация по новым возможностям:
- Правила сопоставления: https://unit.nginx.org/configuration/#condition-matching
- Операции в API: https://unit.nginx.org/configuration/#configuration-management
Также доступна запись митапа NGINX, где хорошо рассказывается про динамическую
маршрутизацию для приложений, хотя туда не вошли новые функции из этого выпуска:
- https://www.youtube.com/watch?v=5O4TjbbxTxw
Ещё было исправлено несколько досадных ошибок, а благодаря вашим отзывам модуль
Node.js теперь поддерживает ещё больше приложений.
Изменения в Unit 1.9.0 30.05.2019
*) Добавление: маршрутизация запросов по аргументам, cookie и полям
заголовка.
*) Добавление: спецсимвол для частичного совпадения теперь можно
использовать и в середине шаблонов сопоставления в маршрутах.
*) Добавление: операция POST для добавления элементов в массивы в
конфигурации.
*) Добавление: поддержка смены пользователя и группы при помощи CAP_SETUID
и CAP_SETGID в Linux без запуска главного процесса под привилегированным
пользователем.
*) Исправление: в процессе роутера могла возникать утечка памяти, если
клиент преждевременно завершал соединение.
*) Исправление: возможный сбой при применении конфигурации большого объема.
*) Исправление: операции PUT и DELETE не работали на элементах массивов в
конфигурации.
*) Исправление: схема запроса в приложениях не отражала TLS-подключения.
*) Исправление: восстановлена совместимость с приложениями Node.js,
использующими функцию ServerResponse._implicitHeader(); ошибка появилась
в версии 1.7.
*) Исправление: различные проблемы совместимости с приложениями Node.js.
В этом выпуске также стали доступны пакеты для Ubuntu 19.04 "disco".
Полный список доступных репозиториев смотрите на нашем сайте:
- https://unit.nginx.org/installation/
Тем временем, мы продолжаем трудиться над поддержкой WebSocket для модулей
Node.js и Java. Все почти готово; шансы на то, что это войдет в следующий
выпуск - очень велики.
Работа над проксированием и отдачей статических файлов также ведется, но на
это уйдет больше времени.
Напоминаю, что мы непрерывно находимся в поиске талантливых разработчиков,
желающих присоединиться к нашей команде. Вакансии в Москве и других локациях
можно посмотреть по ссылке:
- https://www.nginx.com/careers/current-openings/
--
Валентин Бартенев
Доброго дня!
nginx: 1.15.8
Конфигурация простая (конечно она сильно шире, но в качестве бэкенда сейчас
действительно один сервер задается через переменную):
split_clients "${remote_addr}${cookie_uid}" $backend {
* "backend1.eu-central-1.elb.amazonaws.com";
}
server {
listen 80;
location / {
proxy_pass http://$backend;
}
}
Столкнулся с интересной проблемой. В один момент у меня перестали идти
запросы на бэкенд, но быстро запросы восстановились. Поискал в логах, в
итоге нашел такие ошибки:
2019/05/24 08:40:26 [warn] 308#308: *1978088914 upstream server temporarily
disabled while reading response header from upstream, client: x.x.x.x,
server: xxxx, request: "GET / HTTP/1.1", upstream: "http://x.x.x.x:80/",
host: "xxxx"
Честно говоря я предполагал такое поведение при исользовании группы
серверов, но тут такого нет, а апстрим все-равно был забанен из-за ошибок.
В документации ничего интересного на эту тему не нашел.
Есть какая то неявная логика в такой обработке?
Благодарю!
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284301,284301#msg-284301
Есть 3 конфига nginx:
1. общий для всех сайтов (домены типа sub1.site.ru, sub2.site.ru, ... ,
subn.site.ru)
2. общий для для всех статистик сайтов (домены типа stat.sub1.site.ru,
stat.sub2.site.ru, ... , stat.subn.site.ru)
3. общий для всех изображений (домены типа images.sub1.site.ru,
images.sub2.site.ru, ... , images.subn.site.ru)
То есть:
любой поддомен, начинающийся на stat. должен попадать в конфиг 2
любой поддомен, начинающийся на images. должен попадать в конфиг 3
а все остальные поддомены должны попадать в конфиг 1
Для этих конфигов в server_name прописал так
1. server_name *.site.ru
2. server_name stat.*
3. server_name images.*
Но это работает неправильно. Подскажите пожалуйста как правильно?
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284388,284388#msg-284388
Здравствуйте.
Не подскажете, какова судьба вот этого тикета:
https://github.com/nginx/unit/issues/132
А так же, возможно, есть прямой способ, как получить в php, запускаемом
через unit клиентский айпишник? Сейчас там 127.0.0.1, что очень и очень
плохо и ставит использование unit под жирный вопрос.
--
Best regards,
Anton Kiryushkin
всем привет
ПРОБЛЕМА
давно (уже не первый год обновление за обновлением nginx и OpenSSL) наблюдаем,
что ряд страниц при обновлении кэша входят в вечный статус UPDATING
см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)
происходит это совершенно на рандомных страницах, и способа воспроизвести нет – только по прецедентной жалобе от пользователей, что закешированный контент не обновляется пол дня (ночью у нас рестарт nginx, который приводи всё в норму, но ждать до утра никто не хочет)
КОНФИГУРАЦИЯ
релевантные настройки такие:
proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
proxy_cache_background_update on;
proxy_cache_lock on;
proxy_cache_lock_timeout 25s;
недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка кастомная):
nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI support enabled
при этом:
nginx -s reload # не помогает…
а помогает только явный «мягкий» перезапуск сервера (процедура похожая на обновление бинарника):
#!/usr/bin/env bash
# скрипт перезапуска или обновления бинарника:
sudo kill -s USR2 `cat /run/nginx.pid`
sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
echo 'waiting for 5 minutes required for graceful reload'
sleep 300
sudo kill -s TERM `cat /run/nginx.pid.oldbin`
ЛОГИ И ДЕМО
есть предположение, что это из-за эпозодического падения worker'ов (таких набирается несколько десятков за день, при сотнях тысяч запросов)
dmesg:
[4505268.063116] nginx[22951]: segfault at 48 ip 00007f501a38682e sp 00007fff830e1470 error 4 in nginx.so[7f501a384000+5000]
…
error.log:
2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on signal 11 (core dumped)
…
подобные падения нас пресделуют много лет (их в день не много), на самых разных версиях nginx, в разных ДЦ, на разных серверах, при разных окружениях;
(по хорошему, надо включить сбор корок и попытаться разобраться, где оно падает…)
наше предположение такое:
воркер, который должен был обновить истёкшие данные умирает, а статус так и остаётся UPDATING (на вечно),
всём клиентам отдаётся старый контент,
а новые воркеры уже не планируют запрос обновления с бэка
вот свежий пример (в заголовке x-ireland-cache-status выводим значение $upstream_cache_status):
H27: ~ $ curl -I https://www.hse.ru/our/
HTTP/2 200
server: nginx
date: Thu, 30 May 2019 14:54:52 GMT
…
x-ireland-cache-status: UPDATING
… можно очень долго ждать – статус так и будет UPDATING …
H27: ~ $ curl -I https://www.hse.ru/our/
HTTP/2 200
server: nginx
date: Thu, 30 May 2019 14:56:47 GMT
…
x-ireland-cache-status: UPDATING
после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был приведён выше):
H27: ~ $ curl -I https://www.hse.ru/our/
HTTP/2 200
server: nginx
date: Thu, 30 May 2019 14:57:37 GMT
…
x-ireland-cache-status: STALE
H27: ~ $ curl -I https://www.hse.ru/our/
HTTP/2 200
server: nginx
date: Thu, 30 May 2019 14:57:39 GMT
…
x-ireland-cache-status: HIT
всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём следующего звоночка…
у нас нет инструмента по отслеживанию «застрявших UPDATING»,
и нет способа точечно их пнуть
(если только не отслеживать $upstream_cache_status по каждому ресурсу и переходы статусов со временем, которые в 99.99% переходят из UPDATING в правильные статусы);
приходится ждать только сигнала от недовольных пользователей…
РЕЗЮМИРУЕМ
ещё раз, сценарий, как мы видим откуда растёт проблема:
1. некоторая страница успешно кэшируется
2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер падает по SIGSEGV (таких падений несколько десятков за день из сотен тысяч запросов)
3. никакой больше воркер это задание не получает до перезапуска nginx
4. недовольные клиенты получают устаревший контент
РЕШЕНИЕ?
перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.
какие варианты решения подобной проблемы существуют? в чём может быть возможная причина?
может есть рекомендации по дополнительным настройкам?
да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но их (падения воркеров) надо учитывать в работе nginx:
если это рассматривать как баг nginx – можно ли найти ему решение в будущих обновлениях, в виде отправки повторной задачи воркерам на обновление кэша, по таймауту?..
Добрый вечер!
Подскажите пожалуйста есть ли такая возможность и как ещё реализовать?
Задумка такая имеется Nginx 1.16 v расширенный 3 дополнительными модулями
nginx-auth-ldap nginx-dav-ext-module nginx-upload-module
При подключении (dav методом) пользователю предоставляется доступ к
каталогам, но нужно чтобы к определенным были права только на чтение или
вообще ни каких а для других полный доступ.
На пример есть общий каталог ALL на который имеется полный доступ путем
dav_access user:rw group:rw all:rw;
В общем каталоге имеется подкаталоги пользователей:
Ivanov к этому каталогу имеет доступ только Ivanov ну хотя бы что бы другие
не удаляли ничего
Petrov к этом соответствено так же но для Petrov.
Если ставить условие на доступ к location ngix не принимает запись, как
можно сделать проверку?
Posted at Nginx Forum: https://forum.nginx.org/read.php?21,284347,284347#msg-284347
привет!
изучаем утечки памяти. мешает вот такой шум
==5351== 2,160 bytes in 1 blocks are still reachable in loss record 1 of 2
==5351== at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==5351== by 0x157E01: ngx_strerror_init (in /usr/sbin/nginx-debug)
==5351== by 0x1307FE: main (in /usr/sbin/nginx-debug)
==5351==
==5351== 3,030 bytes in 135 blocks are still reachable in loss record 2 of 2
==5351== at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==5351== by 0x157E66: ngx_strerror_init (in /usr/sbin/nginx-debug)
==5351== by 0x1307FE: main (in /usr/sbin/nginx-debug)
==5351==
==5351== LEAK SUMMARY:
==5351== definitely lost: 0 bytes in 0 blocks
==5351== indirectly lost: 0 bytes in 0 blocks
==5351== possibly lost: 0 bytes in 0 blocks
==5351== still reachable: 5,190 bytes in 136 blocks
==5351== suppressed: 0 bytes in 0 blocks
==5351==
==5351== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==5351== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[root@valgrind ~]#