Добрый день!
Последний тестинг, update && upgrade.
При нажатии на “Скачать архив с rootfs” открывается диалоговое окно с предложением скачать rootfs.htm. Файл, соответственно, не скачивается, пишет, что ошибка. В инспекторе даже запрос не идет. Скриншот во вложении. Win 10 + браузер Opera 109.0.5076.0. Сижу по VPN, на компе есть касперский.
Проверял на MacOS + Opera (соотв., без касперского), в одной сети с контроллером, поведение такое же.
Оффтопик: При ответе с цитированием, диагностический архив не скрывается.
Посмотрел архив. Причин сам не вижу. Попрошу коллег посмотреть.
Попробовал это Не скачивается архив с rootfs
Поменял файл, ребутнулся, не помогло, вернул обратно.
Сейчас /etc/sudoers.d/www-data с таким контентом:
www-data ALL = (root) NOPASSWD: /usr/bin/tar,/usr/bin/mount,/usr/bin/umount,/bin/tar,/bin/mount,/bin/umount
root@wirenboard-A4VEY6PY:~# /usr/lib/cgi-bin/download_rootfs.sh
Status: 200
Content-Disposition: attachment; filename="rootfs_A4VEY6PY_20240220_1218.tar.gz"
Content-Type: application/octet-stream
Usage: pigz [options] [files ...]
will compress files in place, adding the suffix '.gz'. If no files are
specified, stdin will be compressed to stdout. pigz does what gzip does,
but spreads the work over multiple processors and cores when compressing.
Options:
-0 to -9, -11 Compression level (level 11, zopfli, is much slower)
--fast, --best Compression levels 1 and 9 respectively
-A, --alias xxx Use xxx as the name for any --zip entry from stdin
-b, --blocksize mmm Set compression block size to mmmK (default 128K)
-c, --stdout Write all processed output to stdout (won't delete)
-C, --comment ccc Put comment ccc in the gzip or zip header
-d, --decompress Decompress the compressed input
-f, --force Force overwrite, compress .gz, links, and to terminal
-F --first Do iterations first, before block split for -11
-h, --help Display a help screen and quit
-H, --huffman Use only Huffman coding for compression
-i, --independent Compress blocks independently for damage recovery
-I, --iterations n Number of iterations for -11 optimization
-J, --maxsplits n Maximum number of split blocks for -11
-k, --keep Do not delete original file after processing
-K, --zip Compress to PKWare zip (.zip) single entry format
-l, --list List the contents of the compressed input
-L, --license Display the pigz license and quit
-m, --no-time Do not store or restore mod time
-M, --time Store or restore mod time
-n, --no-name Do not store or restore file name or mod time
-N, --name Store or restore file name and mod time
-O --oneblock Do not split into smaller blocks for -11
-p, --processes n Allow up to n compression threads (default is the
number of online processors, or 8 if unknown)
-q, --quiet Print no messages, even on error
-r, --recursive Process the contents of all subdirectories
-R, --rsyncable Input-determined block locations for rsync
-S, --suffix .sss Use suffix .sss instead of .gz (for compression)
-t, --test Test the integrity of the compressed input
-U, --rle Use run-length encoding for compression
-v, --verbose Provide more verbose output
-V --version Show the version of pigz
-Y --synchronous Force output file write to permanent storage
-z, --zlib Compress to zlib (.zz) instead of gzip format
-- All arguments after "--" are treated as files
umount: /tmp/WB-RFS.mF5Dp5K: target is busy.
rm: it is dangerous to operate recursively on '/tmp/WB-RFS.mF5Dp5K' (same as '/')
rm: use --no-preserve-root to override this failsafe
root@wirenboard-A4VEY6PY:~#
Скачал хром - Версия 121.0.6167.185 (Официальная сборка), (64 бит)
Легко повторяю.
Систему переставлял с Вами в этой теме - Не запускается zigbee2mqtt, отсутствует порт ttyMOD4
И до переустановки не работало (вообще ни разу, сколько пробовал, было так же, как сейчас).
Пробую банальное, первым приходящиее в голову::
wget http://10.0.0.79/fwupdate/download/rootfs
--2024-02-20 13:32:18-- http://10.0.0.79/fwupdate/download/rootfs
Подключение к 10.0.0.79:80... соединение установлено.
HTTP-запрос отправлен. Ожидание ответа… 200
Длина: нет данных [application/octet-stream]
Сохранение в: «rootfs»
rootfs [ <=> ] 37,98M 2,04MB/s
root@wirenboard-A4VEY6PY:~# wget http://127.0.0.1/fwupdate/download/root
--2024-02-20 13:35:48-- http://127.0.0.1/fwupdate/download/root
Connecting to 127.0.0.1:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9699 (9.5K) [text/html]
Saving to: ‘root’
root 100%[==========================================================>] 9.47K --.-KB/s in 0.001s
2024-02-20 13:35:48 (11.2 MB/s) - ‘root’ saved [9699/9699]
root@wirenboard-A4VEY6PY:~#
root.htm (9,5 КБ)
Прошу прощения, был не внимателен. Исправился:
root@wirenboard-A4VEY6PY:~# wget http://127.0.0.1/fwupdate/download/rootfs
--2024-02-20 13:39:19-- http://127.0.0.1/fwupdate/download/rootfs
Connecting to 127.0.0.1:80... connected.
HTTP request sent, awaiting response... 502 Bad Gateway
2024-02-20 13:39:19 ERROR 502: Bad Gateway.
root@wirenboard-A4VEY6PY:~#
Зачем с localhost?
С другого компьютера надо. Ну и проверьте статус fcgiwrap
У меня винда. Различий с результатами из браузера нет.
Ну и проверьте статус fcgiwrap
root@wirenboard-A4VEY6PY:~# systemctl status fcgiwrap
● fcgiwrap.service - Simple CGI Server
Loaded: loaded (/lib/systemd/system/fcgiwrap.service; indirect; vendor preset: enabled)
Drop-In: /etc/systemd/system/fcgiwrap.service.d
└─override.conf
Active: active (running) since Tue 2024-02-20 12:12:19 MSK; 1h 35min ago
TriggeredBy: ● fcgiwrap.socket
Main PID: 3291 (fcgiwrap)
Tasks: 3 (limit: 2364)
Memory: 1.5M
CPU: 1.188s
CGroup: /system.slice/fcgiwrap.service
├─3291 /usr/sbin/fcgiwrap -f -c 2
├─3341 /usr/sbin/fcgiwrap -f -c 2
└─3342 /usr/sbin/fcgiwrap -f -c 2
Feb 20 12:12:19 wirenboard-A4VEY6PY systemd[1]: Started Simple CGI Server.
root@wirenboard-A4VEY6PY:~#
Я тут пробовал скрипт (/usr/lib/cgi-bin/download_rootfs.sh) дергать, он с ошибками выполняется.
Это не то?
Пробовал выше по теме.
Вы не устанавливаете параметры контекста. Это правильное поведение без параметров.
Обратите внимание, если выполняю с явной ошибкой:
wget -vvv http://10.0.0.79/fwupdate/download/somesome -O -
--2024-02-20 14:11:22-- http://10.0.0.79/fwupdate/download/somesome
Подключение к 10.0.0.79:80... соединение установлено.
HTTP-запрос отправлен. Ожидание ответа… 200 OK
Длина: 9699 (9,5K) [text/html]
Сохранение в: «STDOUT»
- 0%[ ] 0 --.-KB/s <!doctype html>
то также загружается html.
Ок, понял. Так и должно быть.
А я по GET http://10.0.77.52/fwupdate/download/rootfs должен получить файл? Сейчас 502.
Что мне дальше делать?
Можете верхнеуровнево накидать план действий? Я не юниксойд. Смотреть логи веб сервера? Что еще попробовать?
errorlog nginx
2024/02/20 18:02:35 [error] 2824#2824: *51 FastCGI sent in stderr: "sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set" while reading response header from upstream, client: 172.16.3.33, server: localhost, request: "GET /fwupdate/download/rootfs HTTP/1.1", upstream: "fastcgi://unix:/var/run/fcgiwrap.socket:", host: "10.0.77.52", referrer: "http://10.0.77.52/"
2024/02/20 18:02:35 [error] 2824#2824: *51 upstream prematurely closed FastCGI stdout while reading response header from upstream, client: 172.16.3.33, server: localhost, request: "GET /fwupdate/download/rootfs HTTP/1.1", upstream: "fastcgi://unix:/var/run/fcgiwrap.socket:", host: "10.0.77.52", referrer: "http://10.0.77.52/"
2024/02/20 18:05:20 [error] 2824#2824: *55 FastCGI sent in stderr: "sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set" while reading response header from upstream, client: 172.16.3.33, server: localhost, request: "GET /fwupdate/download/rootfs HTTP/1.1", upstream: "fastcgi://unix:/var/run/fcgiwrap.socket:", host: "10.0.77.52", referrer: "http://10.0.77.52/"
2024/02/20 18:05:20 [error] 2824#2824: *55 upstream prematurely closed FastCGI stdout while reading response header from upstream, client: 172.16.3.33, server: localhost, request: "GET /fwupdate/download/rootfs HTTP/1.1", upstream: "fastcgi://unix:/var/run/fcgiwrap.socket:", host: "10.0.77.52", referrer: "http://10.0.77.52/"
В том случае если 502 отдает именно nginx контроллера - да, надо посмотреть/выложить его логи.
Вообще - оптимально, пожалуй дать к контроллеру доступ по ssh, я с подобным поведением раньше не встречался и сразу план дебага не готов выдать.