Перейти к содержимому


Фото
- - - - -

Не обновляется Dr.Web ESS с 11.00.02 до 12.0


  • Please log in to reply
46 ответов в этой теме

#1 Александр Б.

Александр Б.

    Member

  • Posters
  • 143 Сообщений:

Отправлено 09 Ноябрь 2019 - 16:56

Попытка обновления через вебинтерфейс.

 

В dwupdater.log вроде всё идет штатно, потом последняя запись:

 

20191109 16:50:50 [DBG] [ Script ] Execute start_server([=[/etc/init.d/drwcsd]=]) from form start_server, [=[/etc/init.d/drwcsd]=]

20191109 16:50:50 [DBG] [ Script ] Starting server through `/etc/init.d/drwcsd start'
20191109 16:50:52 [DBG] [ Script ] Starting server process exit code is 0
20191109 16:50:52 [DBG] [ Script ] Execute ignore(spit, [=[INSERT INTO admin_activity(record,subsys,login,address,oper,status,createtime) VALUES('008a13d8-3d4a-4ce6-aa1e-c475d4ffc3b3',1,'admin','https://ip:33676:43',10605,2,20191109134947000);INSERT INTO activity_data(record,item,value,createtime) VALUES('008a13d8-3d4a-4ce6-aa1e-c475d4ffc3b3','Error','Failed to run `update_db("/opt/drwcs/bin/drwcsd", "/var/opt/drwcs/etc/upgrade-conf.lua", "update")'', details: unable to update database, process exit code is 3584',20191109134947000);]=], [=[/var/opt/drwcs/update/backup/11020190227000000-12020191015000000/rollback.sql]=]) from form ignore, spit, [=[INSERT INTO admin_activity(record,subsys,login,address,oper,status,createtime) VALUES('008a13d8-3d4a-4ce6-aa1e-c475d4ffc3b3',1,'admin','https://ip:33676:43',10605,2,20191109134947000); INSERT INTO activity_data(record,item,value,createtime) VALUES('008a13d8-3d4a-4ce6-aa1e-c475d4ffc3b3','Error','Failed to run `update_db("/opt/drwcs/bin/drwcsd", "/var/opt/drwcs/etc/upgrade-conf.lua", "update")'', details: unable to update database, process exit code is 3584',20191109134947000);]=], [=[/var/opt/drwcs/update/backup/11020190227000000-12020191015000000/rollback.sql]=]
20191109 16:50:52 [DBG] [ Script ] Execute ifexist([=[/var/opt/drwcs/update/backup/11020190227000000-12020191015000000/rollback.sql]=], ignore, update_db, [=[/opt/drwcs/bin/drwcsd]=], [=[/var/opt/drwcs/update/backup/11020190227000000-12020191015000000/rollback.sql]=], [=[revert]=]) from form ifexist, [=[/var/opt/drwcs/update/backup/11020190227000000-12020191015000000/rollback.sql]=], ignore, update_db, [=[/opt/drwcs/bin/drwcsd]=], [=[/var/opt/drwcs/update/backup/11020190227000000-12020191015000000/rollback.sql]=], [=[revert]=]
20191109 16:50:52 [DBG] [ Script ] Updating database with `/var/opt/drwcs/update/backup/11020190227000000-12020191015000000/rollback.sql'
20191109 16:50:54 [DBG] [ Script ] Updating database process exit code is 0
20191109 16:50:54 [DBG] [ Script ] Execute start_server([=[/etc/init.d/drwcsd]=]) from form start_server, [=[/etc/init.d/drwcsd]=]
20191109 16:50:54 [DBG] [ Script ] Starting server through `/etc/init.d/drwcsd start'
20191109 16:50:54 [DBG] [ Script ] Server already running
20191109 16:50:54 [DBG] [ Script ] Successfully completed `revert'
20191109 16:50:54 [DBG] [ Script ] Revert process exit code (revert -> master) is 0
20191109 16:50:54 [ERR] [ Script ] Failed on `master'

 

И сервер возвращается к исходной 11.00.02


12.00.0 (15-10-2019 03:00:00) / Linux 4.15.18-041518-generic x86_64; Ubuntu 16.04.6 LTS; glibc 2.23 / PostgreSQL 9.5.19

#2 Afalin

Afalin

    Guru

  • Dr.Web Staff
  • 4 007 Сообщений:

Отправлено 10 Ноябрь 2019 - 12:35

Это Вы привели конец процедуры отката обновления. Интересует целиком dwupdater.log и updater-update.*log*


Семь раз отрежь – один раз проверь

#3 Afalin

Afalin

    Guru

  • Dr.Web Staff
  • 4 007 Сообщений:

Отправлено 10 Ноябрь 2019 - 12:37

Кстати у Вас случаем не MSSQL? Это так, без логов пальцем в небо.


Семь раз отрежь – один раз проверь

#4 Александр Б.

Александр Б.

    Member

  • Posters
  • 143 Сообщений:

Отправлено 10 Ноябрь 2019 - 12:41

Postgresql.

 

Сейчас лог достану, просто до последних абзацев всё шло штатно, думал роли не играет.


12.00.0 (15-10-2019 03:00:00) / Linux 4.15.18-041518-generic x86_64; Ubuntu 16.04.6 LTS; glibc 2.23 / PostgreSQL 9.5.19

#5 DoggoD

DoggoD

    Member

  • Posters
  • 195 Сообщений:

Отправлено 11 Ноябрь 2019 - 06:41

тоже самое как и у ТС..

dwupdater.log и updater-update.*log* прилагаю.. второй файл правда старый.. с попытки обновиться в него ничего не записалось..

Прикрепленные файлы:



#6 Afalin

Afalin

    Guru

  • Dr.Web Staff
  • 4 007 Сообщений:

Отправлено 11 Ноябрь 2019 - 10:21

тоже самое как и у ТС..

Не, не то же. Тут апдейтный скрипт от 12 сервера в связке с 11 сервером не смог таки адекватно работать с var-root, вынесенным на другой диск. Чуть позже прикинем, как проще это решить.


Семь раз отрежь – один раз проверь

#7 Afalin

Afalin

    Guru

  • Dr.Web Staff
  • 4 007 Сообщений:

Отправлено 11 Ноябрь 2019 - 12:47

DoggoD, попробуйте обновить сервер, используя этот скрипт.

Есть два варианта:

1) положить его в Z:/DrWeb/repository/20-drwcs/12020191015000000/windows/, удалив при этом Z:/DrWeb/repository/20-drwcs/12020191015000000/.cache и Z:/DrWeb/repository/20-drwcs/12020191015000000/windows/.state-*, чтобы сервер не обнаружил подмены (впрочем, если он успеет сходить за апдейтом, то всё равно заметит, но это делается раз в полчаса по дефолту);

2) запустить апдейтер руками от имени администратора, заменив в двух (!) местах (/path/to/this/update.lua) путь к скрипту, это тоже по-моему должно сработать: "C:/Program Files/DrWeb Server/bin/drwupsrv.exe" --enable-runcopy --log-dir "Z:/DrWeb" --log-file dwupdater.log --verbosity debug -c exec -s "path/to/this/update.lua" -p rotate=10z,10m from=11020190227000000 to=12020191015000000 "home=C:/Program Files/DrWeb Server" "var=Z:/DrWeb" "etc=C:/Program Files/DrWeb Server/etc" "lib=C:/Program Files/DrWeb Server/bin" "bin=C:/Program Files/DrWeb Server" platform=windows-nt-x64 "updater=C:/Program Files/DrWeb Server/bin/drwupsrv.exe" "script=/path/to/this/update.lua" "service=C:/Program Files/DrWeb Server/bin/drwcsd.exe" verbose=true admlogin=admin "admaddr=http://172.16.4.72:49954" maxbackup=3 "lock=Z:/DrWeb/plugins/tmp/WEBMIN/maintenance"


Сообщение было изменено Afalin: 11 Ноябрь 2019 - 12:52

Семь раз отрежь – один раз проверь

#8 Afalin

Afalin

    Guru

  • Dr.Web Staff
  • 4 007 Сообщений:

Отправлено 11 Ноябрь 2019 - 14:07

и Z:/DrWeb/repository/20-drwcs/12020191015000000/windows/.state-*

Очепятка, правильно читать Z:/DrWeb/repository/20-drwcs/12020191015000000/.state-*


Семь раз отрежь – один раз проверь

#9 DoggoD

DoggoD

    Member

  • Posters
  • 195 Сообщений:

Отправлено 12 Ноябрь 2019 - 01:59

Afalin, а штатным этот скрипт скоро завезут в продакшн? а то я бы выбрал подождать )



#10 Afalin

Afalin

    Guru

  • Dr.Web Staff
  • 4 007 Сообщений:

Отправлено 12 Ноябрь 2019 - 09:11

Afalin, а штатным этот скрипт скоро завезут в продакшн? а то я бы выбрал подождать )

Кто его знает. Надо хотя б пенку собрать по результатам обновления, чтоб выдать фиксы наиболее популярных проблем.

Конкретно этот скрипт уже проверили – обновление в такой схеме работает. Есть ли на Вашей тропе грабли дальше – мы пока не знаем. =)


Семь раз отрежь – один раз проверь

#11 Александр Б.

Александр Б.

    Member

  • Posters
  • 143 Сообщений:

Отправлено 12 Ноябрь 2019 - 09:18

По моей проблеме.

Оказалось особенности установки по мануалам.

Внешняя БД Postgresql с дефолтной настройкой, по которой сама БД слушает конкретный интерфейс сервера (не localhost/127.0.0.1)

 

А сервер Dr.Web ESS подключается к серверу по localhost. По идее вообще не должно было работать, но вот так.

 

В итоге в процессе обновления соединение с БД честно пропадало и происходил откат.

 

Сооветственно фикс - указать в настройках внешней БД не localhost, а ip-адрес. 

 

После чего обновление успешно проходит.


12.00.0 (15-10-2019 03:00:00) / Linux 4.15.18-041518-generic x86_64; Ubuntu 16.04.6 LTS; glibc 2.23 / PostgreSQL 9.5.19

#12 Kirill Polubelov

Kirill Polubelov

    Forth Thinker

  • Dr.Web Staff
  • 3 440 Сообщений:

Отправлено 12 Ноябрь 2019 - 11:31

А pg_hba.conf настроен ли?


(exit 0)


#13 Александр Б.

Александр Б.

    Member

  • Posters
  • 143 Сообщений:

Отправлено 13 Ноябрь 2019 - 08:31

А pg_hba.conf настроен ли?

 

Я когда-то при установке к дефолтному локалхосту добавил ип-адрес, оно с тех пор и работало:

 

# Database administrative login by Unix domain socket
local   all             postgres                                peer
 
# TYPE  DATABASE        USER            ADDRESS                 METHOD
 
# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
host all all 172.18.2.40/32 md5
#host    all     all     10.0.0.222/32    md5
# IPv6 local connections:
host    all             all             ::1/128                 md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local   replication     postgres                                peer
#host    replication     postgres        127.0.0.1/32            md5
#host    replication     postgres        ::1/128                 md5

12.00.0 (15-10-2019 03:00:00) / Linux 4.15.18-041518-generic x86_64; Ubuntu 16.04.6 LTS; glibc 2.23 / PostgreSQL 9.5.19

#14 Kirill Polubelov

Kirill Polubelov

    Forth Thinker

  • Dr.Web Staff
  • 3 440 Сообщений:

Отправлено 13 Ноябрь 2019 - 12:37

Тогда непонятно.

Непонятно, что за "дефолтная" настройка, по которой pg слушает только внешн. интерфейс.

Непонятно, как работало через локалхост, при этом, до этого.


(exit 0)


#15 Afalin

Afalin

    Guru

  • Dr.Web Staff
  • 4 007 Сообщений:

Отправлено 13 Ноябрь 2019 - 12:48

Да всё тут понятно. listen_addresses в postgresql.conf.

На самом деле, можно было там добавить localhost в дополнение к 172.18.2.40, тогда б мы к 127.0.0.1 тоже нормально подключились.


Сообщение было изменено Afalin: 13 Ноябрь 2019 - 12:50

Семь раз отрежь – один раз проверь

#16 Kirill Polubelov

Kirill Polubelov

    Forth Thinker

  • Dr.Web Staff
  • 3 440 Сообщений:

Отправлено 13 Ноябрь 2019 - 13:00

Да всё тут понятно. listen_addresses в postgresql.conf.

Это не дефолт. Дефолт как раз localhost. Если только предположить, что когда поменяли локалхост на адрес интерфейса, вместо *, то после этого не рестартовали постгрес/drwcsd и он работал на существующем подключении, что кажется очень маловероятным.


(exit 0)


#17 Afalin

Afalin

    Guru

  • Dr.Web Staff
  • 4 007 Сообщений:

Отправлено 13 Ноябрь 2019 - 13:09

 

Да всё тут понятно. listen_addresses в postgresql.conf.

Это не дефолт. Дефолт как раз localhost.

Так тут никто не говорил, что postgresql.conf оставлен с дефолтными настройками.


Семь раз отрежь – один раз проверь

#18 Kirill Polubelov

Kirill Polubelov

    Forth Thinker

  • Dr.Web Staff
  • 3 440 Сообщений:

Отправлено 13 Ноябрь 2019 - 13:19

Мне послышалось: "Внешняя БД Postgresql с дефолтной настройкой".


(exit 0)


#19 Александр Б.

Александр Б.

    Member

  • Posters
  • 143 Сообщений:

Отправлено 13 Ноябрь 2019 - 17:02

Тогда непонятно.

Непонятно, что за "дефолтная" настройка, по которой pg слушает только внешн. интерфейс.

Непонятно, как работало через локалхост, при этом, до этого.

 

в postgresql.conf всегда стояло:

#listen_addresses = ''

 

но при этом постгрес слушал именно интерфейс.

 

и опять таки - при этом др.веб слушал локалхост в настройках внешней бд.

 

как это работало - непонятно.

 

но сервер периодически перезагружали и ничего не падало.

 

я бы вообще на это внимание не обратил, если бы не проблема с обновлением до 12-й версии.


12.00.0 (15-10-2019 03:00:00) / Linux 4.15.18-041518-generic x86_64; Ubuntu 16.04.6 LTS; glibc 2.23 / PostgreSQL 9.5.19

#20 Kirill Polubelov

Kirill Polubelov

    Forth Thinker

  • Dr.Web Staff
  • 3 440 Сообщений:

Отправлено 14 Ноябрь 2019 - 11:15

listen_addresses закомментарен, стало быть дефолт в чистом виде. Дефолт (не знаю, может в разных версиях различается, но вряд ли) -- это именно локалхост. Именно поэтому дрвеб мог. Откуда утверждение "но при этом постгрес слушал именно интерфейс." следует?


Сообщение было изменено Kirill Polubelov: 14 Ноябрь 2019 - 11:15

(exit 0)



Читают тему: 0

0 пользователей, 0 гостей, 0 скрытых