Valentin Barbolin, через инструменты разработчика во вкладке сеть я промониторил что проиходит при попытка загрузки файла на сайт, консоль ссылается на некий js файл в котором содержится ошибка
Mixed Content: The page at 'https://мой-домен/library/49e53a17-6f50-4d4c-93c7-926611f008d3/%D0%9C%D0%BE%D1%8F%20%D0%B1%D0%B8%D0%B1%D0%BB%D0%B8%D0%BE%D1%82%D0%B5%D0%BA%D0%B0/%D1%8B%D0%B2%D0%B0%D1%8B%D0%B2%D0%B0' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://мой-домен/seafhttp/upload-aj/fd57d2cf-4743-4072-b587-75392c244660?ret-json=1'. This request has been blocked; the content must be served over HTTPS.
значит проблема в самом nginx конфиг файле я так понимаю,
server {
server_name мой-сайт;
location / {
proxy_pass http://localhost:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Forwarded-Proto $scheme;
client_max_body_size 0;
proxy_connect_timeout 36000s;
proxy_read_timeout 36000s;
proxy_send_timeout 36000s;
send_timeout 36000s;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/мой-сайт/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/мой-сайт/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = мой-сайт) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name мой-сайт;
listen 80;
return 404; # managed by Certbot
}
Valentin Barbolin, вот вот, через сайт все очень даже шустренько работает, меня радует, а клиент...
А если поставить клиент сторонний который использует webdav, то скорость файлов предельно низкая в обе стороны но хотя бы не нужно ждать непонятную процедуру индексации.
Обратно к seafile:
sudo docker exec -it seafile nginx -T > nginx_conf.txt
-bash: nginx_conf.txt: Permission denied
да и не думаю что официальный репозиторий как то бы ошибку сохранил, неужели они не проверяют конфиги перед деплоем?)
Valentin Barbolin, да в nginx есть много ошибок, чаще всего
[error] 4762#4762: *18 connect() failed (111: Unknown error) while connecting to upstream
docker logs seafile - все хорошо
по nginx стоит redis, в целом тут даже не сам nextcloud, а его клиенты бедокурят, например у меня на сервере 700к файлов, если я кому либо поставлю клиент с функцией облачного подключения, он начинает все эти файлы индексировать и синхронизировать (без скачивания) , мне не понятно зачем это делается но отнимает такая операция даже на очень шустром ПК около 5 часов, а если ПК медленный то несколько дней, это не в какие ворота. Без redis такая же операция может занять неделю. Скачивание "заголовков файлов" примерно 20-30 в секунду идет, а если у меня будет не 700к, а 2кк файлов или больше? Страшно подумать...
Seafile я поставил косо криво и у него таких заморочек нет, подключил и работай, кроме того он все же на более быстрых языках написан, осталось только понять как его приготовить )
да именно выделенный, я понимаю что на виртуалке виртуалку не поднять
ну белых ip я могу заказать несколько штук, пусть к примеру 1 будет за web proxmox
второй отдаем на VM которая будет вместо роутера? А что туда ставить, как управлять? Хоть примерно что гуглить?)
на докер могу только несколько сервисов перевести, остальное слишком спецефическое
вся соль в чем, у меня будет 1 SQL база , которая должна быть доступна в LAN на всех VM/ОС , а уже на самих ОС выделенный белый ip
Антон Литвиненко, ну в моем случае контент статичен и уже есть на странице, вопрос только в отображении, в примере который я прикрепил я не пойму почему "показать еще" не работает
rPman, как сейчас построена система:
есть документация за многие годы, документы эти копятся и множатся, но в архив перемещать не выйдет потому как многие документы используются как образец, выходит нужен доступ ко всем документам но без скачивания (ясное дело 2ТБ никто даже частично не осилит
нагрузка на сервер редко бывает одновременной, максимум 10 человек работает
чаще всего это открытие одного - пяти документов и сохранение их же обратно , реже загрузка новых документов прямо пачкой и очень редко загрузка прямо 20+ гб архивов (не в плане сжатых, а просто много)
при обычно работе хватает webdav , хотя скорость скачивания тоже не ахти но терпимо, а вот при загрузке уже такое себе, ну и косяки когда люди работают с одним и тем же документом
по пингам ну максимум 2-3мс у 90% людей так как сейчас сервер стоит очень рядом , у некоторых прямо lan + гигабитный интернет
rPman, у меня уже есть nextcloud, но на этих же 50 человек работа слишком медленная, даже перейдя на postgresql и с хорошим сервером, не знаю может что то я недонастроил но проблема с большим количеством документов, много мелких файлов, когда я ставлю офф клиент, он даже для облачного хранения все файлы должен "проиндексировать" (хотя сложно это индексацией назвать...), прежде чем можно будет работать, а этот процесс может занять до двух дней, что = бред. Я пробовал использовать программы которые аля webdav (raidrive) , но скорость по этому протоколу ну просто ппц маленькая , например через веб 10 мб/сек , клиент 2-5 мб/сек , а webdav 200 кб/сек и если мелких файлов много то еще медленнее..
поэтому и возникла идея про гугл диск, но это пока только наброски, если бы можно было 1 папку расшарить на много юзеров и все файлы лежали у "главного" , а редактировали и сохраняли в исходной, было бы здорово, а свои файлы смысла хранить нет, все общее
значит проблема в самом nginx конфиг файле я так понимаю,