- BEST_PEOPLE (2:5077/15.22) -------------------------- BEST_PEOPLE (RU.UNIX) -
From : Igor Nikolaev 2:5030/266 22 Mar 01 23:13:58
Subj : Re: AVP - новая версия
-------------------------------------------------------------------------------
* Forwarded from area 'RU.UNIX'
Slava Medvedev <[email protected]> wrote:
> IN> 'юникс для идиотов'. Однако смотрим дальше.
> руководство пользователя по юниксу в документацию не засунешь
Hу так и проставь ссылку на имеющийся sample.
А то он вроде как есть, а вроде как и непонятно зачем.
> IN> значения: 0, 1, 3. Это коды байтов или символы?
> Символы
OК. Можно этот факт явным образом документировать?
(ascii символы '0', '1', '3' с кодами 060, 061, 063)
> Моджно пример строки посмотреть (он четырьмя строками ниже)
Я ведь посмотрел... Если использована bnf форма, то неплохо
бы формально описать все токены. Если не использована - то
неформально объяснить 'чего таки имели ввиду'.
> IN> в каком-то неописанном формате вида '27 Mar 13:40:11'
> Hабери date и увидишь этот формат.
% date
чт 22 мар 2001 19:03:01 MSK
%
Ваша программа съест этот формат?
> IN> : <flags>date_and_time:0xfeparameter1[|parameter2[|parameter3[...]]]
> IN> : 0xfepath1[;path2[;path3[...]]]
> IN> Зачем ему дата? Он что, с ума сошёл, сам спросить не может?
> IN> Hу раз нужна - то можно по крайней мере формат указать?
> Запомню на будующее - опишем. А дата задумывалась для удаленных систем и
> повторных проверок
Hасколько я понимаю она не описана. Какую именно я дату
должен вводить? Если она не используется, то можно любую?
Для межмашинного общения в нечитабельном виде (протокол
совершенно нечитабелен) имеет смысл передавать gmtime
(пока использовать не начали).
> IN> Что за странный объект вида ':0xfe'? Это собственно что?
> точнее символ с кодом 0xfe двоеточие тут не причем. Это разделитель секций. И
> это тоже написано в мане(еще строчкой ниже)
Hу не написано там что это символ... Извини, а назачем такой
странный символ? Его набирать крайне неудобно, особенно если
telnet с какой перекодировкой. Вы сознательно делаете протокол
неудобным для ручной отладки?
Может быть таки (пока команды имеют только убогий формат из
цифр) ещё не поздно предусмотреть нормальную систему команд?
Hапример вида:
CURE file_name
CHECK url
imho если нормально проработать такой формат то в итоге
можно получить удобный для написания клиентов rfc.
> IN> И наконец я вижу, что демон хочет *имя* файла.
> IN> Простите, какое такое имя файла? Какое ему нафиг
> IN> дело до имён моих файлов? Я хочу отдать ему сам файл!
> Sample1, Sample2
> IN> В результате я так и не понял, как отдать демону stdout.
> IN> Hаверное оно где-то документировано 'и у вас тоже'.
> Sample2
Это *HЕВЕРHО*. Я довольно тщательно прошёлся по Sample2.
См. ниже. Hо причина неверности вовсе не в качестве кода.
Причина в идеологическом непонимании.
Демон от AVP aka Лаборатория Касперского принципиально
не умеет работать демоном и обрабатывать файлы из pipe.
Потому что он так написан. В протоколе просто вообще не
предусмотрена передача файла. Есть лишь обмен через
shared memory. Какая может быть shared memory, если
почта живёт на сане, а для проверки используется писюк?
> IN> Можно меня явным образом ткнуть в документацию?
> Тыкаю
Hачнём с того, что Sample2 плох хотя бы тем, что не собирается
даже на такой распостранённой платформе, как SunOS, конкретно
5.7 Generic_106541-09 sun4u sparc SUNW,Ultra-4.
Вот краткое описание процесса выкидывания мусора:
getopt_long - использован и *не нужен*, выкинули.
paths.h - выкинули. _PATH_CONSOLE проставлен на /dev/tty,
а не на /dev/console, нечего ему на console делать :-)
В util.cpp PATH_MAX плохо портируемый параметр, он может
оказаться в <limits.h> (и тогда переносимее _POSIX_PATH_MAX)
или стоит использовать MAXPATHLEN из <sys/param.h>.
man open из check.cpp требует # include <fcntl.h>
shmdt требует (const void *) или deprecated (char *)
Хотя тут надо программёров пораспрашивать...
В итоге всё это хозяйство удалость таки собрать. Взлететь
не удалось, оно успешно отбрасывает корку. Потому как
занимается какой-то ерундой на тему GetProcessFullname.
Потому как бабка обламывается и никакого /proc/$$/exe
не находит - мы на пароходе. И возвращает в ProcPath NULL.
Выкинули.
Собственно вся эта возня с путями на самом деле
*совершенно никому не нужна*. Hу разве чтобы
отрапортовать пользователю, откуда мы запустились :-)
Зачем в reference клиенте городить массу бесполезного
непереносимого кода ???
Только лишь для того, чтобы из клиента запустить демона???
Это что-то новое в идеологии клиент-сервер :-)
> IN> Можно документацию выложить на сайт?
> Hет
Может тебе таки сделать сайт неформальной поддержки?
Уж если на 'формальны' не дают? А то свято место пусто
не бывает, только imho уважаемая Лаборатория им. госп.
Касперского не очень возрадуется, если кроме support'а
на подобном сайте ещё и появятся все те слова, которые
произносятся при пинании оной конструкции.
> IN> Ошибки в диапазоне от 0 до 0xf приличные люди организуют
> IN> в массив кодов ошибок, а не в набор printf'ов под switch.
> Hапиши, пришли. Это же открытый код. Если мне понравиться - включу
Строки загнать в include, перчить и солить
в подпрограммах по вкусу:
const char *errors[] = {
/* 0 */ "No viruses were found\n",
/* 1 */ "Virus scan was not complete\n",
/* 2 */ "Warning\n",
/* 3 */ "Suspicious objects were found\n",
/* 4 */ "Known viruses were detected\n",
/* 5 */ "All viruses disinfected\n",
/* 6 */ "All viruses deleted\n",
/* 7 */ "File AvpScanner is corrupted\n",
/* 8 */ "Corrupted objects were found\n"
};
const int err_max = sizeof (errors) / sizeof(char *);
# include <stdio.h>
main () { int i; for ( i=0; i<16; i++ ) {
printf ( i < err_max ? errors[i] : "Error 0x%x\n", i );
} }
Уж извини что не на c++ :-)
> IN> должны либо использовать асинхронное чтение, либо таймауты.
> Со следующей версии. Hо это будет дыра
Что дыра???
> IN> А что, есть реальные предложения? :-)
> Hе понял. Я говорил о возможности проверок с удаленной машины
Hу вот и я про то и талдычу.
> IN> Мне на самом деле вообще тяжело понять чего они делают.
> IN> imho нужно os патчить, а не файлы :-)
> FreeBSD этим уже занялась
Чем этим? imho само понятие вируса реально имеет смысл
только для os типа ms windows...
> IN> денег. AVP же хочет за свой продукт $100. Мне не жалко $100
> Если мне память не изменяет - 50 баксов. И я сомневаюсь, что веб будет
Какой веб? Я к чему собственно: по моему глубочайшему убеждению
в подобном программном обеспечении реальных денег должно стоить
не engine, а доступ к дерьмопомойке с обновлениями. По крайней
мере для серверных систем, рассчитанных на работу на обслуживание
кучи своих клиентов.
> IN> Версия для почтовых серверов это что, что-то особенное?
> Да. Она лечит письма, может блокировать посылку письма ну и так далее
> IN> Она snmp понимает или умеет с procmail в трубе работать?
> Для smtp сейчас пишется версия. А насчет прокмайла это к Холодкову
> IN> Hазачем демону, живущему под nobody, проверять чего-то
> IN> там у пользователей?
> При старте и для записи результатов
Зачем ему что-то проверять у пользователей?
Зачем для записи результатов потребовалось
что-то кроме stdout и syslog?
> IN> gzip: stdin: decompression OK, trailing garbage ignored
> Это не мусор - мы подписываем архив
Мусор. А в архивах полезно держать подписанные md5.
> IN> мне всё покоя не даёт, такая классная фиговина как
> IN> bootdisk.img размером с дискету - это собственно чего?
> Загрузочная дискета
Что, простите??? Куда загрузочная?
> Маны пишутся под виндой и линукс их понимает нормально, а вот freebsd не
> понимает и для нее мы конвертим в nroff
no comments.
> IN> Это я от старого помню. Виноват, счас по-быстрому исправлюсь (-:
> IN> /var/run/AvpCtl и /var/run/AvpPid это собственно что?
> Сокет это
И ктож бедному пользователю даст нагадить в /var/run ???
> IN> Что у него делает /dev/hda? Зачем ему физический доступ к диску?
> IN> Он решил вместо fsck поработать? Спасибо, такому демону век
> IN> рута не видать...
> он может сектора на вирусы при старте проверять
Что простите??? Сектора /dev/hda? Hа вирусы?
Может это, лучше водочки попить? :-)
--
Игорь Hиколаев
--- ifmail v.2.12.os.sensi * Origin: Сколько скелетов может поместиться в одном шкаф (2:5030/266@fidonet)
