57 ответов в этой теме

[pig]

Это путь на целевом сервере. А вот записать оно не может на локальный диск. Он часом не переполнен?

[sirius220]

Это путь на целевом сервере. А вот записать оно не может на локальный диск. Он часом не переполнен?

свободно 400 гигов.

 

Отключил возможность работы агента в мобильном режиме. Значки в дереве группы компьютеров стали БЕЗ значка с проблемами обновления. Я проедполагал что эта функция активируется если нету связи с сервером, а она по ходу работает всегда и не принимает обновления от сервера в любом случае.

 

Обновление репозитория еще пока идет. После запуска в ручном режиме. Осталось разобраться почему не смог стартова атоматический апдейт

Сообщение было изменено sirius220: 09 Февраль 2015 - 11:55

[Valentina Yugai]

Отключил возможность работы агента в мобильном режиме. Значки в дереве группы компьютеров стали БЕЗ значка с проблемами обновления. Я проедполагал что эта функция активируется если нету связи с сервером, а она по ходу работает всегда и не принимает обновления от сервера в любом случае.

 

Вы предполагали правильно. Я подозреваю, что исчезнувшие значки - это просто совпадение.

[sirius220]

Вы предполагали правильно. Я подозреваю, что исчезнувшие значки - это просто совпадение.

 

 

Маловероятно, я больше ничего не делал, только отключил Мобильный режим.

 

Ситуация на сей момент:

Состояние репозитория:

Вирусные базы Dr.Web    09-02-2015 15:27:25
Базы SpIDer Gate    09-02-2015 15:10:37
Базы Dr.Web Antispam    09-02-2015 11:49:49
Dr.Web Updater    26-01-2015 16:59:26
Dr.Web Agent для Windows    02-02-2015 17:02:55
Dr.Web Agent для Android    09-02-2015 15:39:17
Dr.Web Server    09-12-2014 07:00:00
Новости компании «Доктор Веб»    07-02-2015 08:28:21

 

т.е. антивирусные базы обновились вчера в ручном режиме и автоматом обновиться не смогли.

Прикладываю свежий лог.

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

•  drwcsd.rar   179,01К   0 Скачано раз

Сообщение было изменено sirius220: 10 Февраль 2015 - 05:44

[sirius220]

Создал задание на обновление в планировщике. Пока полёт нормальный

[Jumbo Frame]

Немного оффтопа, но не могу не поделиться.

После того, как база SQLite (500+ станций) рухнула третий раз за неделю - я сделал бэкап политик и закрытого ключа, и переустановил ES, подняв базу на PostGRE.

После этого администрировать ES стало исключительно в удовольствие. Рекомендую.

Сообщение было изменено Jumbo Frame: 10 Февраль 2015 - 16:09

[Kirill Polubelov]

>> Немного оффтопа, но не могу не поделиться.

Внизу подписать номер версии сервера позабыли

[sirius220]

Немного оффтопа, но не могу не поделиться.

После того, как база SQLite (500+ станций) рухнула третий раз за неделю - я сделал бэкап политик и закрытого ключа, и переустановил ES, подняв базу на PostGRE.

После этого администрировать ES стало исключительно в удовольствие. Рекомендую.

 

задумываюсь сделать нечто подобное. Для PostGRE нодо устанавливать отдельно СУБД или можно простой дллкой обойтись как для локальной верссии? (с PostGRE никогда не работал)

[sirius220]

нашел полную инструкцию по переходу. Вопрос в предыдущем посте считать недействительным

[Jumbo Frame]

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

 

Как ни странно - 

Версия Dr.Web Server 10.00.0 (09-12-2014 03:00:00)

 

При этом в 2-х случаях из трёх базу пришлось восстанавливать из бэкапа и один раз было database disk image is malformed

 

Сообщение было изменено Jumbo Frame: 10 Февраль 2015 - 19:32

[Kirill Polubelov]

Очень странно, версия вроде не совсем старая. А логов сервера не сохранилось, на посмотреть?

[Jumbo Frame]

Очень странно, версия вроде не совсем старая. А логов сервера не сохранилось, на посмотреть?

 

Увы...

Но переход на PostGRE ещё и заставил интерфейс админки ворочаться раза в два шустрее.

Так что SQLite для меня тут в однозначном проигрыше.

[Valentina Yugai]

Jumbo Frame, это довольно логично, с учетом того, что любая нормальная СУБД (не псевдо-СУБД вроде sqlite) обеспечивает существенно более хорошее быстродействие и меньше зависит от производительности диска. А 500+ станций - это внушительный поток информации.

[Kirill Polubelov]

>> любая нормальная СУБД (не псевдо-СУБД вроде sqlite) обеспечивает существенно более хорошее быстродействие и меньше зависит от производительности диска.

 

Шикарно (с)

[Jumbo Frame]

это довольно логично, с учетом того, что любая нормальная СУБД (не псевдо-СУБД вроде sqlite)

 

Вот как раз хотел спросить, почему SQLite предлагается в инсталляторе по умолчанию.

Судя по форуму - проблем с ней достаточно.

[Kirill Polubelov]

Потому что все проблемы с ней, это не проблемы SQLite.

[Yury Vovk]

 

это довольно логично, с учетом того, что любая нормальная СУБД (не псевдо-СУБД вроде sqlite)

 

Вот как раз хотел спросить, почему SQLite предлагается в инсталляторе по умолчанию.

Судя по форуму - проблем с ней достаточно.

 

Для того что бы пользователь имел из коробки готовый к работе продукт и не возился установкой какой либо конкретной СУБД

[chs]

Вот мне интересно ... SQLite хорошая СУБД. Там где её умеют готовить и пользуются по делу. Как-то ни у скайпа ни у Мозиллы проблем с ней нет. И название "псевдо-СУБД" меня коробит.

 

<sarcazm>

А так пропишите в требованиях, что для работы EE необходим Oracle, MS SQL или DB/2 уровня не меньше энтерпрайза :-(

</sarkazm>

 

Вот и вопрос - если с PostgreSQL на том же компьютере, что и контрол центер всё  работает на порядок быстрее, почему бы и не устанавливать её вместе с DrWEB ES ?

[IlyaS]

Угу, или PostgreSQL Embedded.

[Valentina Yugai]

Вот мне интересно ... SQLite хорошая СУБД. Там где её умеют готовить и пользуются по делу. Как-то ни у скайпа ни у Мозиллы проблем с ней нет. И название "псевдо-СУБД" меня коробит.

 

<sarcazm>

А так пропишите в требованиях, что для работы EE необходим Oracle, MS SQL или DB/2 уровня не меньше энтерпрайза :-(

</sarkazm>

 

Вот и вопрос - если с PostgreSQL на том же компьютере, что и контрол центер всё  работает на порядок быстрее, почему бы и не устанавливать её вместе с DrWEB ES ?

 

Видите, в чем дело, SQLite нормально работает на небольших объемах данных. Надо отдавать себе отчет, что она никогда не предназначалась для enterprise-уровня баз. Это всего лишь способ использовать файлик на диске вместо БД, чуть более лучший, чем просто файлик на диске. Но у термина СУБД есть некоторые критерии, и данное решение проходит не по всем.

 

Я могу прочитать длинную лекцию о том, чем одни СУБД отличаются от других, почему одни на каких-то задачах работают быстрее и т.д., но это надолго и вряд ли кому-то здесь интересно. Можно просто указать, что если использовать SQLite для хранения данных, которые выбираются большими последовательными блоками, это совсем не то же самое, что выполнять запрос по нескольким миллионам строк с выборкой поиском по строке. Хоть я и не помню, чтобы такое у нас практиковалось, но производительность целого ряда запросов к базе напрямую зависит от "уровня" самой базы данных, и тут мы получаем довольной четкую пирамиду, на вершине которой находятся MSSQL и Oracle, а в самом низу - простой, но довольно медленный SQLite.