Closed mr-butch closed 8 years ago
Согласно указанным вами данным проблема не воспроизводится. Проверьте права доступа к файлам, разрешений пользователя, selinux (если установлен и активен).
Что необходимо еще прислать, чтобы было более ясно и проблема воспроизвелась? Все тоже самое с выставленным DEBUG=1? Права на файл, например: -rw-rw-rw- 1 admin root 6741884 Jul 24 06:36 eav_nt32_enu.nup Запускается от admin через cron. Запуск вручную приводит к тем же ошибкам загрузки существующих файлов, а не пропускам их. Возможно некие ключи wget у меня не поддерживаются, которые используете Вы?
Правда, не знаю. Можете прислать мне на почту данные для доступа по ssh - попробую разобраться на месте.
В точности такое же поведение скрипта. Запускал на чистой виртуалке с Ubuntu 16.04.1 LTS Скрипт запускается в домашней папке пользователя. Повторный запуск приводит к тому, что файлы, которые обновились на серверах, скачиваются со статусом SUCCESS, а которые не обновлялись вместо того чтобы иметь статус SKIPPED выводятся как "Downloading file error". Если из целевой папки очистить файлы, то первый запуск скрипта пройдет как положено (выкачается все без ошибок), а повторные запуски повторятся с ошибками.
Дебаг-лог в студию, пожалуйста
Пожалуйста.
cat /proc/version
Linux version 4.4.0-21-generic (buildd@lgw01-21) (gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2) ) #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016
bash --version
GNU bash, версия 4.3.46(1)-release (x86_64-pc-linux-gnu)
wget -V
GNU Wget 1.17.1 для linux-gnu.
curl -V
curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
cat ./settings.conf ./conf.d/*.conf | grep -v -e '^#' -e '^$'
export NOD32MIRROR_COLOR_OUTPUT=1;
export NOD32MIRROR_USE_FREE_KEY=1;
export NOD32MIRROR_MIRROR_DIR="$HOME/webroot/download";
export NOD32MIRROR_TEMP_DIR="$HOME/tmp";
export NOD32MIRROR_SERVER_0='http://update.eset.com:80/eset_upd/ username password';
export NOD32MIRROR_SERVER_1='http://nod32.someserver.com/';
export NOD32MIRROR_SERVER_2='http://someserver2.com/nod32/';
export NOD32MIRROR_PLATFORMS='__ALL__';
export NOD32MIRROR_TYPES='__ALL__';
export NOD32MIRROR_LANGUAGES='1033 1049';
export NOD32MIRROR_LOG_PATH="$HOME/nod32mirror.log";
export NOD32MIRROR_CURL_BIN='false';
export NOD32MIRROR_TEST_URI='http://update.eset.com:80/v8-rel-sta/mod_010_smon_1036/em010_32_l0.nup';
export NOD32MIRROR_TIMESTAMP_FILE_NAME='lastevent.txt';
export NOD32MIRROR_VERSION_FILE_NAME='version.txt';
В nod32mirror.log я включил вывод с DEBUG: nod32mirror.txt
Недостаточно дебаг-информации по причине того, что скрипт сам её ограничивает. Пойдем следующим путём:
/nod32-mirror/include/network.sh
ищем строку 165 ui_message 'debug' 'Wget result' "$debug_data";
;ui_message 'debug' 'Wget result' "$result";
[YYYY-MM-DD/HH:MM:SS] [Debug] Wget result ('...')
- все можно не прикладывать.А так же скажите - хоть и выводится сообщение об ошибке - но зеркало-то работает успешно? Это сообщение не должно влиять на его работу, так как это - вопрос лишь косметики
А так же скажите - хоть и выводится сообщение об ошибке - но зеркало-то работает успешно? Это сообщение не должно влиять на его работу, так как это - вопрос лишь косметики
Да, зеркало работает. Пока гоняю в тестовой лабе из двух виртуалок: Ubuntu/nod32mirror + Win8.1/nod4 Nod успешно употребляет предлагаемые обновления. Но, до этого момента не было уверенности, что это - всего-лишь косметическая ругань. Лаба крутится вторые сутки.
P.S. - дебаг пришлю чуть позже.
Это только косметика, не переживайте. Разные версии wget отдают разный ответ, но переданную команду выполняют. Как будет полный дебаг - попробую исправить и это
Я нисколько не переживаю. ;) Наоборот, мне настолько нравится ваш подход к этому скрипту, что возникло желание покопаться в его кишочках. Не смотря, на мои жалкие навыки в баше.
network.sh поправил, прогнал еще одну итерацию. В логе получил единственную повторяющуюся строку:
[2016-08-12/16:50:02] [Debug] Wget result (Setting --cache (cache) to off
Меняется только время.
Т.е. код сейчас выглядит:
result=$("$NOD32MIRROR_WGET_BIN" ... 2>&1);
local debug_data=$(head -n 90 <<< "$result");
ui_message 'debug' 'Wget result' "$result";
case "$result" in
И нет полного дебага? Не может быть такого. Ну давай сделаем:
result=$("$NOD32MIRROR_WGET_BIN" ... 2>&1);
local debug_data=$(head -n 999 <<< "$result");
ui_message 'debug' 'Wget result' "$debug_data";
case "$result" in
Гори оно всё огнём
Код выглядит именно так. Меня сбила с толку просьба искать паттерн. Ну, я grep'ом и прошелся. Прошу прощения. Полный вывод wget выглядит так:
Saving HSTS entries to /home/stigory/.wget-hsts)
[2016-08-12/17:06:40] [Debug] Wget result (Setting --cache (cache) to off
Setting --timestamping (timestamping) to 1
Setting --use-server-timestamps (useservertimestamps) to 0
Setting --user-agent (useragent) to ESS Update (Windows; U; 32bit; VDB 21927; BPC 7.0.527.0; OS: 5.1.2600 SP 3.0 NT; CH 1.1; LNG 1049; x32c; APP eavbe; BEO 1; ASP 0.10; FW 0.0; PX 0; PUA 0;
RA 0)
Setting --connect-timeout (connecttimeout) to 5
Setting --tries (tries) to 2
Setting --http-user (httpuser) to EAV-0169960816
Setting --http-password (httppassword) to 8d4d25shdm
Setting --directory-prefix (dirprefix) to /home/stigory/webroot/download/v10
DEBUG output created by Wget 1.17.1 on linux-gnu.
Не может быть такого. Ранее лог был:
[2016-08-12/13:55:33] [Debug] Wget result (Setting --cache (cache) to off
Setting --timestamping (timestamping) to 1
Setting --use-server-timestamps (useservertimestamps) to 0
Setting --user-agent (useragent) to ESS Update (Windows; U; 32bit; VDB 11544; BPC 6.0.544.0; OS: 5.1.2600 SP 3.0 NT; CH 1.1; LNG 1049; x32c; APP eavbe; BEO 1; ASP 0.10; FW 0.0; PX 0; PUA 0; RA 0)
Setting --connect-timeout (connecttimeout) to 5
Setting --tries (tries) to 2
Setting --http-user (httpuser) to EAV-0169426161
Setting --http-password (httppassword) to t6jjjdfusn
Setting --directory-prefix (dirprefix) to /home/stigory/webroot/download/v4
DEBUG output created by Wget 1.17.1 on linux-gnu.
Reading HSTS entries from /home/stigory/.wget-hsts
URI encoding = 'ANSI_X3.4-1968'
converted 'http://update.eset.com:80/v4-rel-sta/mod_021_horus_7950/em021_32_l0.nup' (ANSI_X3.4-1968) -> 'http://update.eset.com:80/v4-rel-sta/mod_021_horus_7950/em021_32_l0.nup' (UTF-8)
--2016-08-12 13:55:32-- http://update.eset.com/v4-rel-sta/mod_021_horus_7950/em021_32_l0.nup
Host 'update.eset.com' has not issued a general basic challenge.
Resolving update.eset.com (update.eset.com)... 38.90.226.36
Caching update.eset.com => 38.90.226.36
Connecting to update.eset.com (update.eset.com)|38.90.226.36|:80... connected.
Created socket 3.
Releasing 0x0000555e21f78180 (new refcount 1).
---request begin---
GET /v4-rel-sta/mod_021_horus_7950/em021_32_l0.nup HTTP/1.1
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
If-Modified-Since: Thu, 11 Aug 2016 04:50:08 GMT
User-Agent: ESS Update (Windows; U; 32bit; VDB 11544; BPC 6.0.544.0; OS: 5.1.2600 SP 3.0 NT; CH 1.1; LNG 1049; x32c; APP eavbe; BEO 1; ASP 0.10; FW 0.0; PX 0; PUA 0; RA 0)
Accept: */*
Accept-Encoding: identity
Host: update.eset.com
Connection: Keep-Alive
---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 401 Unauthorized
Server: nginx
Date: Fri, 12 Aug 2016 03:55:32 GMT
Content-Type: text/html
Content-Length: 188
Connection: keep-alive
WWW-Authenticate: Basic realm="NOD32 Engine Updates"
---response end---
401 Unauthorized
Registered socket 3 for persistent reuse.
Skipping 188 bytes of body: [<html>
<head><title>401 Authorization Required</title></head>
<body bgcolor="white">
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx</center>
</body>
</html>
] done.
Auth scheme found 'Basic'
Auth param list ' realm="NOD32 Engine Updates"'
Auth param realm=NOD32 Engine Updates
Authentication selected: Basic realm="NOD32 Engine Updates"
Inserted 'update.eset.com' into basic_authed_hosts
Reusing existing connection to update.eset.com:80.
Reusing fd 3.
---request begin---
GET /v4-rel-sta/mod_021_horus_7950/em021_32_l0.nup HTTP/1.1
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
If-Modified-Since: Thu, 11 Aug 2016 04:50:08 GMT
User-Agent: ESS Update (Windows; U; 32bit; VDB 11544; BPC 6.0.544.0; OS: 5.1.2600 SP 3.0 NT; CH 1.1; LNG 1049; x32c; APP eavbe; BEO 1; ASP 0.10; FW 0.0; PX 0; PUA 0; RA 0)
Accept: */*
Accept-Encoding: identity
Host: update.eset.com
Connection: Keep-Alive
Authorization: Basic RUFWLTAxNjk0MjYxNjE6dDZqampkZnVzbg==
---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 12 Aug 2016 03:55:33 GMT
Content-Type: application/octet-stream
Content-Length: 5725366
Last-Modified: Wed, 10 Aug 2016 00:00:00 GMT
Connection: keep-alive
ETag: "57aa6e80-575cb6"
Accept-Ranges: bytes
---response end---
200 OK)
И он ограничен 90 строками, что мало. Верни код в вид, какой он был изначально, изменив лишь:
local debug_data=$(head -n 90 <<< "$result");
на:
local debug_data=$(head -n 999 <<< "$result");
Информации от вас не дождаться? Закрываю тикет?
Прошу прощения. Иногда приходится выпадать из-за ноутбука.
На данный момент запускал тест со следующими параметрами: NOD32MIRROR_DEBUG_MODE=1
Код в network.sh выглядит так:
local debug_data=$(head -n 999 <<< "$result");
ui_message 'debug' 'Wget result' "$debug_data";
Полный лог в файле. nod32mirror.log.txt
Оооо, я не один оказывается. Рад что вы таки начали работу над нашей проблемой. Если будут нужны дополнительные логи, постараюсь помочь своими.
Да только толку-то.. В дебаг-логе ничего внятного, подумаю как быть
Поизучал логи на досуге. Возник один вопрос: А чем обусловлена логика при которой скрипт сначала пытается вытянуть с сервера файл без авторизации, а после получения 401 уже повторяет попытку, указав логин/пароль?
Единственное объяснение, которое приходит в голову - вы хотели получить определенную гибкость при работе с неизвестным количеством и видом серверов обновлений. Но зачем это делать с каждым файлом? Не проще ли однократно определить тип авторизации при первом обращении к серверу и затем работать уже без повторных проверок? И не может ли значение, возвращаемое при первой попытке (401), повлиять на выдачу в лог, если , допустим его не перезапишет успешное значение, которое вернется во второй попытке?
P.S. - прошу прощения за подобные вопросы. Гадать по логам, вместо того чтобы глянуть в код - не есть хорошо. Но с моим опытом, я могу зависнуть в нем очень надолго.
Постскриптум очень правильный. Сперва гляньте код, а после этого вдавайтесь в рассуждения.
Есть ли идеи как выловить ошибку?
Нет ещё. Те, что есть - не лучше того как сделано всё сейчас.
Для себя проблему лифтинга решил так, добавив ответ wgetа на 101 skipped
*[Ss]erver\ ignored*) return 101;;
...
case "$result" in
*[Nn]ot\ retrieving*) return 101;;
*[Oo]mitting\ download*) return 101;;
*[Nn]ot\ modified\ on\ server*) return 101;;
*[Ss]erver\ ignored*) return 101;;
*[Ss]aved*) return 100;;
*ERROR\ 404*) return 12;;
*) return 10;;
...
Приветствую. Появились ли мысли по исправлению ошибки загрузки уже существующих файлов?
@mr-butch, слушай, а патч что был описан @volde-mar ты опробовал на себе? Пока занят двумя другими проектами, разворачивать всю среду для полноценного тестирования чертовски лень. Если если есть возможность - попробуй его на себе - и если подтвердишь что твою проблему он решает - добавлю его в master
ветку.
Я рассматривал это как лифтинг, ну да ладно.. Да, это работает, вместо "Downloading file error" выводит "Skipped", подтверждаю.
Принято, закрываю тикет
Шаги для воспроизведения проблемы (steps to reproduce)
Какое действие ожидалось (expected behaviour)
Расскажите, какое поведение от скрипта вы ожидали (tell us what should happen)
Что произошло на самом деле (actual behaviour)
Расскажите что произошло на самом деле (tell us what happens instead)
Например, "Successfully downloaded files: 3, skipped: 0, with errors: 85"
Данные системы (system information)
Операционная система (operating system):
Bash:
wget / curl:
Настройки (settings):
Настройки скрипта (script settings):
Лог-файл (log-file):
nod32mirror.log.txt
***log Вывод скрипта на экран
16.07.19-06.30.txt