Reply With QuoteRucha, можно, только радость была преждевременна - сервак потушили, похоже. Сутки радовался жизни...
А так, rsync - отличная штука для копирования файлов, но нужно чтобы на сервере апдейтов его демон крутился.
Senior Member
bbsc
Можно подробнее?
RT-N65U 3.0.3.8-081 (Padavan).
WL500gp V1 128 MB. 1.9.2.7-rtn-r4330.
Senior Member
Rucha, можно, только радость была преждевременна - сервак потушили, похоже. Сутки радовался жизни
А так, rsync - отличная штука для копирования файлов, но нужно чтобы на сервере апдейтов его демон крутился.
Senior Member
Класс, вроде работает.Originally Posted by Nebulosa
Особенно понравилась фича сбора ключей :lol
Хотелось бы всё-таки навести порядок вот с этим:
Code:PHP Notice: Undefined offset: 1 in /opt/nod32/nod32update.php on line 33 PHP Notice: Undefined offset: 1 in /opt/nod32/nod32update.php on line 33 PHP Notice: Undefined index: build in /opt/nod32/nod32update.php on line 70 PHP Notice: Undefined index: HOSTS in /opt/nod32/nod32update.php on line 70 PHP Notice: Undefined variable: urls in /opt/nod32/nod32update.php on line 71
Junior Member
Nebulosa thx
Кому не нравятся нотисы добавляем после <?php
у кого пустой файл keysPHP Code:ini_set('display_errors', 0);
error_reporting(0);
Файл с Ключами должен иметь вид
если код будет на одной строке а пароль на другой не заработаетPHP Code:блаблабла КОД блаблабла Пароль
блаблабла КОД блаблабла Пароль
Last edited by junkies; 11-12-2008 at 11:45.
WL-500gP[1.9.2.7-10] + WD Passport 120Gb
Старый друг
Идея интересная, но пока не пашет.
Файл keys пустой. Но есть файлы update2.rar, update3.rar, update2new.ver, update3new.ver.
А более ничего.
Файл ключей формата:
КОД ПАРОЛЬ
Что же ему не так? Али НОДы что поменяли?
Last edited by lekos; 16-01-2009 at 21:33.
Member
Nod3 update error
YAG
Привет!
Проблема с обновлением Nod 3.x при использование твоего скрипта. Причем скрипт для обновления Nod 2.x работает отлично. Ключи рабочие точно. Сам скрипт стягивает всю базу, но удаляет update.ver и пишет что мол ключи не верные.
Если положить update.ver взяв его с какого нить не офф сервера, все обновляется отлично.
log.txt
........
........
2009-02-12 12:13:50 URL:http://u24.eset.com////download/engine3/em008_32_n3.nup [80285/80285] -> "em008_32_n3.nup" [1]
2009-02-12 12:13:52 URL:http://u24.eset.com////download/engine3/em008_32_n4.nup [84974/84974] -> "em008_32_n4.nup" [1]
2009-02-12 12:13:54 URL:http://u24.eset.com////download/engine3/em008_32_n5.nup [86164/86164] -> "em008_32_n5.nup" [1]
2009-02-12 12:13:56 URL:http://u24.eset.com////download/engine3/em008_32_n6.nup [86335/86335] -> "em008_32_n6.nup" [1]
2009-02-12 12:13:58 URL:http://u24.eset.com////download/engine3/em008_32_n7.nup [87722/87722] -> "em008_32_n7.nup" [1]
Authorization failed.
Authorization failed.
Authorization failed.
Authorization failed.
Authorization failed.
Authorization failed.
Authorization failed.
Authorization failed.
Authorization failed.
Authorization failed.
2009-02-12 12:14:13 URL:http://u24.eset.com////download/engine3/em011_32_l0.nup [126177/126177] -> "em011_32_l0.nup" [1]
2009-02-12 12:14:15 URL:http://u24.eset.com////download/engine3/em011_32_n1.nup [87422/87422] -> "em011_32_n1.nup" [1]
2009-02-12 12:14:18 URL:http://u24.eset.com////download/engine3/em011_32_n2.nup [120948/120948] -> "em011_32_n2.nup" [1]
2009-02-12 12:14:21 URL:http://u24.eset.com////download/engine3/em011_32_n3.nup [121452/121452] -> "em011_32_n3.nup" [1]
2009-02-12 12:14:24 URL:http://u24.eset.com////download/engine3/em011_32_n4.nup [121448/121448] -> "em011_32_n4.nup" [1]
2009-02-12 12:14:26 URL:http://u24.eset.com////download/engine3/em000_64_l0.nup [57625/57625] -> "em000_64_l0.nup" [1]
........
........
2009-02-12 12:14:59 URL:http://u24.eset.com////download/engine3/em008_64_n6.nup [106492/106492] -> "em008_64_n6.nup" [1]
2009-02-12 12:15:01 URL:http://u24.eset.com////download/engine3/em008_64_n7.nup [106635/106635] -> "em008_64_n7.nup" [1]
2009-02-12 12:15:04 URL:http://89.202.157.135///eset_upd/update.ver [2583/2583] -> "update.ver" [1]
2009-02-12 12:15:04 URL:http://89.202.157.136///eset_upd/update.ver [2583/2583] -> "update.ver" [1]
2009-02-12 12:15:05 URL:http://89.202.157.137///eset_upd/update.ver [2583/2583] -> "update.ver" [1]
........
........
Удалил из скрипта if проверки на авторизацию..
Auth=`grep 'Authorization failed' log.txt`
if [ ${#Auth} != 0 ]; then
echo Неверные ключики
rm -f log.txt
echo Неверные ключики > log.txt
rm -f update.rar
rm -f update.old
rm -f update.ver
mv -f $WEB_ROOT/$AVBASE_DIR/tmp/log.txt $WEB_ROOT/$AVBASE_DIR/log.txt
rm -r -f $WEB_ROOT/$AVBASE_DIR/tmp
rm -f /var/run/$AVBASE_DIR.PID
rm -f $WEB_ROOT/$AVBASE_DIR/update.new
ERROR="Зеркало $WEB_ROOT/$AVBASE_DIR не было обновлено. Пора бы найти новые рабочие ключики... :-)"
senderror
exit
fi
все работает, базы качаются, нод обновляется.. хотя в логе и присутствует
Authorization failed.
Authorization failed.
хмм...
Last edited by Nolik; 12-02-2009 at 09:34.
Senior Member
Nolik, честно говоря давно уже не лазил в скрипт. У меня он работает. Лезть не хочу, потому что работает, потому что некогда и потому что логика его работы мне совершенно не нравицца и надо переделывать все заново.
Если кто может описать логику работы обновления НОД во всех тонкостях, именно как он это делает, может я бы и написал что-нибудь более правильное. Вообще надо файерволом половить его и посмотреть куда, зачем он лезет и в какой последовательности.
Катящиеся камни не обрастают мхом...
Member
NOD32 update v0.5
Посидел, поанализировал работу твоего скрипта - нормальная логика работы у него. Она слегка избыточна, зато сработает почти при любом раскладе (временная недоступность нескольких серверов, несинхронизированность серверов - в любом случае мы будем иметь самые последние базы).
Я твой скрипт доработал:
заменил передачу ошибки с email на sms http://wl500g.info/showthread.php?t=17474, оптимизировал работу по времени в случае проблем с доступностью серверов (уменьшил таймауты при скачивании), оптимизировал алгоритмы (ты там так шустро перекидывал туда-сюда временные файлы - решил убрать на мой взгляд лишние телодвижения со скачаными update.ver)
добавил:
- невозможность обновлятся через наше зеркало в момент работы скрипта или при неудачном скачивании;
- нормальное протоколирование работы (по крайней мере так легче понять в каком месте ошибка возникает);
- проверки на различные ошибки;
- распознавалку версии для странички на которой отображается состояние онлайн базы;
- упаковку базы в один файл для оффлайн обновлений;
- возможность не скачивать части баз для x64-версий;
- сделал скачивание списка ключей с сайта "верзилла", автоматический перебор и проверку на их валидность.
Короче, если нигде не набокопорил, в теории этот скрипт должен работать абсолютно автоматически.
Думаю надо дать возможность общественности потестить.
В целом алгоритм работы скрипта не менял, для общественности он заключается в следующем:
Скачиваем update.ver с основного сайта обновлений (если сервер оказался недоступным - то прерываем работу скрипта до следующего запуска), в нормальном случае берем из него список серверов.
Далее пробегаем по списку для того, что-бы выяснить есть-ли бОлее новый update.ver по сравнению с нашим. Если сервак недоступный - просто пропускаем его и проверяем следующий. Если ничего не нашли, то пробежав по всем известным, в настоящий момент, серверам завершаем работу.
В случае обнаружения бОлее нового update.ver скачиваем его и проверяем по каждому компоненту обновления. По сути сравниваем не появилась-ли бОлее новая версия каждого из компонентов на текущем сервере обновлений, естественно находим и скачиваем новые компоненты и вместе с этим создаем наш новый локальный update.ver, который будет содержать лиш то, что мы задали в настройках скрипта.
В случае проблем со скачиванием компонентов обновления (упал инет, упал сервер или ещё какая-нибудь бяка) скрипт завершается, при этом наше зеркало не будет доступно для обновлений до тех пор, пока мы опять не запустим скрипт, что-бы он все-таки додел свою работу.
По поводу ключей для доступа к сервакам:
"верзилла" выкладывает файл со списком активных ключей, которые ими проверены. Собственно скрипт его скачивает и создает список ключей для версии ESS (это антивирус + фаервол, наиболее полный вариант NOD32). Логика его работы такова: берем пару USERNAME и PASSWORD из списка, сохраняем его в файлике и пытаемся подлогинится и скачать обновления, если все нормально, то делаем свои дела и заканчиваем работу. При следующем запуске будем брать логин и пароль уже с нашего файла, до тех пор пока нас будут пускать на сервера обновлений.
В случае ошибки авторизации, берем следующую пару логин/пароль из нашего списка и проверяем его и т.д. В случае если ни одна из пар не подойдет, отсылаем sms с ошибкой и завершаем работу. При следующем запуске мы опять скачаем новый файл со списком паролей и попробуем найти корректную пару. По моим наблюдениям: ни разу не было случая что-б ни одна пара не подошла. Фактически всегда подходит первая пара.
P.S. Собственно советую всем после первой настройки скрипта удалить полностью зеркало и дать возможность скрипту создать его заново... Это позволит избавится от лишнего груза в папке.
P.P.S. Если гуру заметят какую-либо неудачную конструкцию в синтаксисе регулярных выражений, то прошу указать мне, потому как
командный интерпретатор bash начал изучать только при написании этого скрипта, а это по сути неделя вечеров.
Senior Member
Браво!!!
Попробую потихоньку потестить. Есть в принципе мысли по поводу сбора ключей еще. Хочу заметить несколько моментов.
1. Логика работы все-таки слишком избыточна.
2. На мой взгляд нужно сделать не невозможность обновления с зеркала в момент его обновления (сорри за каламбур), а изменять структуру зеркала только после того как все новое закачано. Именно с этой целью и была куча телодвижений с update.ver. Обновление же отдельных компонентов зеркала ни разу не давало ошибки у клиента (хотя это конечно возможно). С этой целью я оставлял старый update.ver до окончания процесса обновления зеркала и в самом конце его подменял.
Почему мне не нравицца предложенный тобой вариант. Потому что каналы у многих дохлые, избыточность работы скрипта очень серьезная. Сервера НОДа часто тупят (перегружены всякими скриптами вроде этого которые их все оббегают каждый час). Размер обновлений может достигать десятков мегабайт. В результате имеем не функционирующее пару часов (в самом худшем варианте) зеркало, даже если таймауты ты и подправил.
3. Если уж опирацца на верзиллу (хотя это не правильно, сегодня верзилла - завтра не верзилла, нужно выносить список таких сайтов в отдельный файл, чтобы можно было легко менять, а скрипт уже должен их перебирать), то целесообразно брать последнюю пару ключей, потому как если вдруг раньше срока не забанят, то последняя проживет больше.
Last edited by YAG; 23-07-2009 at 07:02.
Катящиеся камни не обрастают мхом...
Member
А что делать, если оборвалась закачка какого-то из компонентов?
Мы становимся перед фактом испорченого компонента.
Мне кажется неоптимальность этого алгоритма в следующем:
Нашли мы новую базу на каком-то из серверов, скачали обновления, и пошли дальше по списку, через пару серверов находим еще более новую базу и опять скачиваем. Я такое наблюдал при отладке.
Тут два варианта:
1. Мы не оббегаем список серверов (хотя это занимает пару десятков секунд), а останавливаемся на первом доступном.
2. Мы сначала оббегаем все сервера в поисках самой новой базы и после этого скачиваем её с последнего из доступных серверов. Тем самым мы в любом случае чаще всего будем качать не с самого первого сервера, а с менее загруженых: последних, хотя ни разу не видел, что-б первый сервер отдавал со скоростью меньше моей мегабитки.
На мегабитке время обновления зеркала 5-7 минут.
Вот сегодня утром было:
2009-07-23 07:44:25 Start NOD32 Updating script. ver 0.5. PID: 4145
...
2009-07-23 07:50:07 NOD32 Updating script successfully completed.
Время оббегания всех серверов - 20-25 сек.
2009-07-23 10:04:18 Start NOD32 Updating script. ver 0.5. PID: 14612
...
2009-07-23 10:04:41 NOD32 Updating script successfully completed.
Тут ничего не сделаешь потому как постояно целиком выкачивается обновленное ядро (кумулятив), которое весит 15 метров - это основная потеря. Можно конечно выкачивать только дифы (компоненты предназначеные для обновления предыдущей быза на текущую - они совсем крохотные), но тогда что делать с клиентами, у которых очень старая база.. Так что все равно приходится тратить время на скачивание всего кумулятива. Хотя надо попытатся разобратся как все таки правильно делать зеркало. Может достаточно скачивать ядро раз в неделю, а ежедневно мелкие файлы-изменения. Хотя тут как-бы не натолкнутся на неприятности с работоспособностью базы.
Да конечно, в идеале можно перебирать кучу китайских серверов и оттуда выцарапывать ключи... Но они банятся быстрее скорости света.
С верзиллы ключи работают неделями.
Насчет опирания только на одну верзиллу.. Не судите сильно строго, мне нужен был хоть който автомат.На следующей неделе еду в отпуск - хочу что-б зеркало работало без моего участия.
Ну и ещё фактор имеется: для каждого сайта прийдется лепить свой парсер - структура у сайтов-то разная.
Member
Кстати тут http://www.eset.eu/support/update-xy1 можно видеть как часто обновляются официальные базы для NOD, не сложно заметить, что обновляются они не чаще чем три раза в сутки:
в районе 6-7 часов утра,
в районе 14-15 часов дня и
в районе 19-21 часа вечера.
Так что есть повод подумать когда именно обновлять зеркало.
На мой взгляд наилучшим временем будет запуск скрипта обновления в
08:00, 15:00 и 21:00. Безусловно это не идеально, можно и вообще каждый час запускать. Но у кого канал не резиновый рекомендую обратить внимание на подобное время.
Senior Member
Начну с конца... Обновляются они по мере готовности новых сигнатур... Но не чаще чем раз в час. Иногда и по два дня не обновляются. Такое часто бывает.
Испорченные компоненты. В идеале надо вначале закачивать, что необходимо и только потом менять структуру зеркала. От этого не уйти.
Неоптимальность. Тут один единственно верный вариант. Второй из Ваших предложенных. По поводу отдачи... Отдают-то они все достаточно быстро, а вот авторизуют иногда очень долго.
Как все таки правильно делать зеркало. Выкачивать нада то что обновилось. Это однозначно. Другой вопрос, что нада бы еще подтирать, то что стало не нужно.
Судить Вас строго не собираюсь. :-) И когда сам лепил это и сейчас опираюсь на несколько требований.
1. Зеркало должно всегда иметь самые новые обновления с официальных серверов на момент обновления этого зеркала.
2. Зеркало всегда должно быть доступно и работоспособно пусть и не с самыми новыми базами независимо от того обновляется ли оно или там какие-то проблемы неизвестно с чем.
Катящиеся камни не обрастают мхом...
wl-500gp user
Есть замечание, даже два:
- В скрипте есть строчка
Она сработает неверно, если файла update.old ещё не существует. Соответственно, при первом запуске скрипт пролетает по списку серверов, но базы не скачивает. Причём, если скрипт запускать из-под bash, а не sh, то сработает правильно. Решение - добавить проверку существования файла:Code:if [ "update.ver" -nt "update.old" ]; then
Code:if [ ! -e "update.old" ] || [ "update.ver" -nt "update.old" ]; then- Мне кажется, лучше не вставлять явные пути типа "/opt/bin/wget", "/opt/bin/unrar" и т.п., а добавить в скрипт строчку PATH="/opt/bin:$PATH" и в вызовах писать просто "wget" и т.п. Мало ли у кого что где установлено.
Everybody stand back. I know iptables.
Мой вариант правильного выключения роутера.
Senior Member
WGET'ы у всех разные... И не каждый WGET может подойти...
Катящиеся камни не обрастают мхом...
Member
Согласен... особенно суббота-воскресенье.
Угу. Хоть это и усложняет скрипт, но это будет правильно.
Тогда при предварительном сканировании серверов обновлений, на предмет наиболее свежего обновления, измерять ещё и время. И в дальнейшем скачивать с самого быстрого, имеющию самую свежую базу.
О... надо будет подумать как сделать.
Тогда надо всё новое скачивать в отдельную папку и в случае удачного окончания скачивания всех обновлений, перемещать в папку с базой вместе с новым update.ver. Тогда время недоступности базы будет по сути временем перемещения новых файлов, а это секунды.
Posting Permissions
