Комментарии 15
Можно запретить nginx буферидовать ответ от fcgi на диск (x-accel-buffering), чтобы избежать лишнего io. Но в этом случае в памяти будет висеть по экземпляру zip на клиента.
Я бы рекомендовал реализовать упаковку на каком-нибудь асинхронном фреймворке (node, tornado), тогда это будет не проблема.
Я бы рекомендовал реализовать упаковку на каком-нибудь асинхронном фреймворке (node, tornado), тогда это будет не проблема.
запретить nginx буферидовать ответ от fcgi на диск (x-accel-buffering)X-Accel-Buffering не для этого предназначен. Запрет кэширования на диск осуществляется директивой proxy_max_temp_file_size. А директива proxy_buffering и X-Accel-Buffering в значении off — это такой способ убить производительность.
В Linux есть проблемы с неблокирующим вводом-выводом из файлов. Параллелить оный придется все равно тредами или процессами.
А что будет если, например, вызвать
Не должна же запаковаться корневая директория с конфигами… Не вижу проверок на такие ситуации
/download.cgi?/etc
или /download.cgi?/
?Не должна же запаковаться корневая директория с конфигами… Не вижу проверок на такие ситуации
Не смотрели на вот такую реализацию вашей задачи: wiki.nginx.org/NgxZip?
Почему бы не заменить вот это:
pushd "$homeDir" > /dev/null
простым cd?
А popd совсем удалить?
pushd "$homeDir" > /dev/null
простым cd?
А popd совсем удалить?
Верно ли я понимаю, что любой юзер, обладающий любым доступом на сайт, может дописать к
upd: имею в виду, что все юзеры имеют доступ ко всем папкам внутри
/download.cgi?имя-любой-директории
, если он знает имя этой директории? Т.е. никакого разграничения по правам доступа к папкам у вас нет?upd: имею в виду, что все юзеры имеют доступ ко всем папкам внутри
/storage/media/audio
?Думаю, можно обойтись без fcgiwrap и перенести bash-скрипт на xinet.d
Как-то так
Как-то так
service ws
{
port = 8081
socket_type = stream
wait = no
type = UNLISTED
user = www-data
server = /bin/bash
server_args = /root/ws.sh
log_on_success += USERID
log_on_failure += USERID
disable = no
}
Есть небольшой закрытый сайти
но у нас обычные пользователи и для многих будет загадкой что делать с tar
Как-то не вяжется. Если количество пользователей ограничено, то сделать краткую инструкцию по распаковке .tar не должно составить труда.
p. s.: Как-то нехорошо на Хабре говорить про пиратские сайты. Нет?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация возможности скачивания директорий пользователями сайта