Обсуждение и предложения по реализации базы данных проб оборудования

[ASte]

Так накидайте список того, что по-вашему отправлять не стоит

Ну как минимум - из пробы должны быть исключены mac-адреса, ip-адреса и все что с ними связано, имена хостов, имена пользователей, разного рода серийные номера идентифицирующие конкретные экземпляры  железок. В некоторых BIOS ноутбуков могут быть прошиты серийные номера лицензий windows. Если они присутствуют, они тоже ни в каком виде не должны попадать в пробы.

[sb]

Так накидайте список того, что по-вашему отправлять не стоит

Ну как минимум - из пробы должны быть исключены mac-адреса, ip-адреса и все что с ними связано, имена хостов, имена пользователей, разного рода серийные номера идентифицирующие конкретные экземпляры  железок. В некоторых BIOS ноутбуков могут быть прошиты серийные номера лицензий windows. Если они присутствуют, они тоже ни в каком виде не должны попадать в пробы.

Имею ввиду не вырезку данных (этого я делать как раз не собираюсь, т.к. есть ключи сбора, которые позволяют не собирать те логи, которые содержат данные, не допускаемые не то что в публичный доступ, но и вообще к сбору - так будет спокойнее и мне и тем, кто ратует за анонимность), а файлы логов, которые содержат эти самые нежелательные данные. Но более того, почти все придётся слать заново, т.к. проб, которые на данный момент удовлетворяют перспективным требованиям по анонимности в базе исчезающе мало. И даже сверх этого: мне придётся переписать значительную часть кода, отвечающую за обработку данных, т.к. анонимизация коснётся, вероятнее всего, тех логов, на которых строится построение сбора информации о системе. Как результат: скорее всего я просто делать ничего не буду, вместо этого пойду заниматься другим видом деятельности и уберу домен arenet.ru с поддоменами, за который приходится платить с недавнего времени совсем неадекватные деньги.

[asy]

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

Вопрос, есть ли эти ключи. Но, как минимум, уже известны несколько файлов, которые просто стоит удалить не глядя.

Или можно начать с разбора использования system-report, так как всё сомнительное, в основном, собирает он. Для чего в пробе его данные? Что реально берётся оттуда? Xorg.0.log, допустим, может представлять интерес (но не забываем про hostname). Xorg.1.log уже точно избыточен. Так же, интерес могут представлять proc/cmdline, proc/config.gz, proc/cpuinfo, proc/version. Ещё sysreport.ls*, всё остально не нужно, если я не ошибаюсь. Соответственно, system-report можно вообще выкинуть (ну не для того он написан, чтобы данные по железу собирать массово, у него совсем другая задача), а нужное поместить в архив соответствующими командами.

Код: [Выделить]

[ -f "/var/log/Xorg.0.log" ] && cat /var/log/Xorg.0.log | grep -iv "Current Operating System" > tmp/Xorg.0.log
cp /proc/cmdline tmp/cmdline
modprobe configs
[ -f "/proc/config.gz" ] && cp /proc/config.gz tmp/config.gz
...
[ -x "/usr/bin/lspci" ] && lspci -k > tmp/report.lspci # не помню, кажется arm бывает без pci
[ -x "/usr/sbin/dmidecode" ] && dmidecode | grep -iv "Serial Number" > tmp/report.dmidecode
...
И так далее, только пути скорректировать и имена файлов. Можно и разложить так, как system-report раскладывает, чтобы остальное не переделывать. Причём proc/cmdline и proc/cpuinfo тоже не нужны по идее, так как присутствуют в hwinfo.

Если хочется отдельную утилиту, надо написать hw-report по аналогии с system-report.

[asy]

А хорошим идентификатором уникальности может быть вывод blkid. Правда, иногда, hdd может кочевать без переразбивки в более компьютеры... Можно связь с моделью материнки сделать.

[sb]

Если хочется отдельную утилиту, надо написать hw-report по аналогии с system-report.

У меня нет желания писать повторно то, что уже написано. Раз считате лишними файлы, значит будем добавлять ключи, которые исключают сбор этих файлов. И мне не нужно ничего писать вообще, только выпустить обновленный клиент. От принципа максимального использования готового кода я вряд ли отойду, потому как весь сервис на это заточен.

А хорошим идентификатором уникальности может быть вывод blkid. Правда, иногда, hdd может кочевать без переразбивки в более компьютеры... Можно связь с моделью материнки сделать.

Ну как минимум - из пробы должны быть исключены mac-адреса, ip-адреса и все что с ними связано, имена хостов, имена пользователей, разного рода серийные номера идентифицирующие конкретные экземпляры  железок. В некоторых BIOS ноутбуков могут быть прошиты серийные номера лицензий windows. Если они присутствуют, они тоже ни в каком виде не должны попадать в пробы.

Причём proc/cmdline и proc/cpuinfo тоже не нужны по идее, так как присутствуют в hwinfo.

Всё дело в том, что используется по предпочтению не hwinfo, а обычные выхлопы. Писать же мегапарасер, который ориентирован на один hwinfo в своём большинстве, у меня желания не возникает (я против вендор лока). И в нашем случае есть e2k со товарищи, на которых оно может не взлететь или быть обрезанным достаточно, чтобы подобный парсер просто не работал и достаточно спотыкался.

[asy]

Если хочется отдельную утилиту, надо написать hw-report по аналогии с system-report.

Мы вообще сейчас не говорим по эту утилиту росы

Я ничего не знаю про Росу, ВООБЩЕ НИЧЕГО. Я обсуждаю исключительно реализацию, которорой посвещена тема. Название hw-report я взял с потолка, если в Росе так же называется - ну я не виноват. Давайте по-другому назовём. Это если, действительно, есть желание иметь отдельную утилиту, которую будет использовать hcl-get. Но я, честно говоря, особого смысла в отдельной утилите не вижу - она будет таким же нишевым решением, только под hcl-get и заточенным.

blkid выводит UUID, котрые создаются при создании файловых систем. Это не на столько жёсткий идентификатор, как серийный номер, первый же запуск mkfs его поменяет. Или через tune2fs можно поменять (это для ext, но и для других FS, наверняка, возможно). Думаю, это разумный компромис.

[asy]

Причём proc/cmdline и proc/cpuinfo тоже не нужны по идее, так как присутствуют в hwinfo.

Всё дело в том, что используется по предпочтению не hwinfo, а обычные выхлопы.

Тогда вопрос в другую сторону: а что вообще используется из hwinfo ? Может весь вывод тоже не нужен тогда ? Там вот есть /dev/mem кусочек. Кажется, там тоже серийные номера есть.

[sb]

Для чего в пробе его данные? Что реально берётся оттуда?

Я, кажется, у же неоднократно указывал на возможный вариант решения проблем, когда тот, кто нуждается в помощи, может одним действием собрать данные и предоставить всем желающим доступ к логам без личных данных. Но вы по-прежнему не хотите понять, что это, пожалуй, самый верный путь к востребованности. Все остальное идёт на автомате, в силу привычек (а покажите выхлоп такой-то, а покажите выхлоп сякой-то). Но если есть возможность сократить лишние действия и ускорить процесс, почему бы этим не воспользоваться ? Вместо этого вы предлагаете обрубить эти возможности, выбросив из пробы вообще всё. Какой мне тогда смысл продолжать делать что-то дальше, если в пробе не будет логов того же fdisk'а или настроек сети (без белых айпишников). Я согласен, что логи с маками, адресами внешки и т.п. на серверах администраторов вряд ли понадобятся для решения каких-либо задач. Но фишка тут в том что, как оказалось, некоторые участники сервиса пользовались системой и не обращали внимания на эти файлы с сообщениями. А там была весьма полезная информация для решения их проблем. Это как диагноз по обследованию. Посмотрел логи и человеку даже не надо говорить, что у него за проблема - это и так по логам видно. Тут вот фирмварь не загрузилась, тут вот в настройках сети косяк и .т.п. Вот для чего сервис нужен, а не для того, чтобы всё у всех вырезать. Лично мне такой сервис не интересен совсем, т.к. он позволяет весьма узкий круг вопросов решать, а большую часть придется решать на форуме изо дня в день повторяя путь генерального наступления на грабли. По сто раз же темы создаются по одним и тем же причинам, которые в логах отражены. Но мы возьмём это всё и уберём из пробы - пусть люди по граблям ходят и спотыкаются вместо того, чтобы получить решение.

[sb]

Тогда вопрос в другую сторону: а что вообще используется из hwinfo ? Может весь вывод тоже не нужен тогда ? Там вот есть /dev/mem кусочек. Кажется, там тоже серийные номера есть.

Система добычи и обработки информации весьма непростая, меняется бывает заметно, потому что нет устоявшихся требований к данным, а хотелки на показ прибывают. При этом надо учитывать кучу различных факторов: от минимальных зависимостей клиента (чтобы поставить на мелкую технику с консолькой с минимумом достановки пакетов там, где она к сети не подключена) до чистого по части анонимности массива выдаваемой пользователю информации. Я просто повторюсь тут, что никакого обрезания каких-либо логов до попадания в архив не будет: это проблема для сервиса и его механики работы (придется переписывать), это проблема для клиента (придется переписывать). Это проблема для системы отслеживания идентичности файлов проб. Другими словами, это не про нас всё. Либо файлов нет совсем и это для всех стандарт либо файлы есть (если имеются источники данных, установлены ли соответствующие утилиты для этого и возможности самого system-report, т.к. на разных платформах возможности его отличаются), но всякие разные данные как при платежах электронными картами закрываем звездочками или вообще не показываем. Если что-то не нравится, то есть другие сервисы, которые наверняка подобный функционал предоставляют (возможность что-то там выборочно слать, не слать и прочая, но не имеют потенциальных возможностей jyahd и, соответственно, это просто сбор данных даже не для решщения проблем, а просто для статистики). И мне проще не писать очередной велосипед - во-первых, я чайник от программирования, во-вторых, лишние расходы на доменное обслуживание. И, в-третьих, всё это в свободное время, которое вполне можно потратить гораздо более продуктивно, не тратя попусту. Понимаете, нет ? Люди должны сами все эти вещи понимать и поддерживать каждый в меру своего понимания. Но на поверку оказывается, что просить выводы команд по логам и прочим настройкам это признак линуксоидов и это навсегда к ним прилипнет. Прошу прощения, но я не мог это не сказать. Целый год, уже даже больше прошёл. Но до сих пор нет понимания, казалось бы, очевидных вещей. Если не очевидно, то полистайте в конце концов форум и посмотрите частоту встречающихся фраз вроде "покажите лог" на предмет одних и тех же вопросов, которые решаются на раз просто с использованием сервиса (вместо этого мне говорят "логи лишние - убрать почти всё и оставить с десяток, больше не надо"). Да, возможно я в чём то и заблуждаюсь, но предлагаю решение для решения проблем, а не для создания новых, как мне кажется.

[asy]

Я, кажется, у же неоднократно указывал на возможный вариант решения проблем, когда тот, кто нуждается в помощи, может одним действием собрать данные и предоставить всем желающим доступ к логам без личных данных.

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

Тут надо просто не путать helpdesk и hardware database. Вопрос - что такое "база данных проб оборудования".

Данные для хелпдеска нужны конкретно в момент проблемы, причём они могут быть удалены после решения проблемы. А от того, что они навечно сохраняются в hardware database вообще по каждому чиху смысла нет никакого. Смысл в hardware database совершенно другой: посмотреть, работает ли, и с чем какое-то конкретное оборудование. И совмещать эти два понятия, helpdesk и hardware database, не следует как раз исходя из вопросов безопасности полученной базы данных. Вот сколько сейчас в базе проб, которые были не только для статистики по железу сделаны, но и для того, чтобы логи посмотреть ? Кстати, а кто их может посмотреть ?

Как вариант предлагаю сделать так, чтобы hcl-get отсылал, по-умолчанию, исключительно данные для hardware database. А уж если кто-то хочет helpdesk, то пусть у него будет ключик --full. Что я точно знаю, это то, что я не желаю отправлять куда-то логи без предварительного личного их просмотра. У меня там может что угодно оказаться: я, иногда, syslog для очень подробной диагностики использую. В этой ситуации получается, что я не могу предоставлять информацию о железе в этот проект в произвольный момент, делать это надо исключительно в начальной стадии подготовки оборудования, когда там ещё ничего важного не может быть даже случайно. Реальные IP тут даже не самый большой вред. И меня не волнует, что Вы обещаете обеспечить недоступность полных данных: я просто не хочу, чтобы они где-то там, без моего личного контроля, были вообще. Тоже не мог не высказаться.

[ASte]

asy, полностью согласен.

[Dmytro]

Тут надо просто не путать helpdesk и hardware database. Вопрос - что такое "база данных проб оборудования".

Я думал, возможно неверно, что программа позиционируется, прежде всего, как база совместимого оборудования. Если так, то она должна именно собирать информацию об оборудовании. Не больше, не меньше.

Я просто повторюсь тут, что никакого обрезания каких-либо логов до попадания в архив не будет: это проблема для сервиса и его механики работы (придется переписывать), это проблема для клиента (придется переписывать).

Да, возможно я в чём то и заблуждаюсь, но предлагаю решение для решения проблем, а не для создания новых, как мне кажется.

Верно, но Ваше решение решает проблемы, отсутствующие в постановке исходной задачи. По крайней мере, в том варианте задачи, который был изначально официально озвучен. Именно об этом коллеги и говорят. Т.е. надо определяться, либо вносить изменения в программу, либо ее несколько иначе позиционировать.

Что касается лично меня, я данные еще 2-3 проб, как до этих машин доберусь, закину.  Конкретно в моем случае даже открытая публикация этих данных ощутимого вреда не принесет.

Идея полноценного Helpdesk для Altlinux - тема стоящая. Успехов в развитии проекта Вам.

Понятно, что трудно писать в 1 руки и в свободное время. Соавторов искать не пробовали?

[sb]

Исходная постановка задачи, во-первых, уважаемые участники дискуссии, была не моя. Я лишь оттолкнулся от потребности конкретного человека (кстати, спасибо ему за то, что задал подобный вопрос).
Во-вторых, в первом сообщении темы написано, что она (тема) для обсуждения и выработки целеполагания. За более чем год с начала проекта в качестве "просто базы" не было получено ни одного сигнала о том, что это кому-то реально нужно для реальных задач (в том числе и от того самого участника, что задал вопрос). После же того, как это до меня дошло и целеполагание было смещено в сторону того, что, вероятно, будет востребовано, тут же получил кучу возражений о том, что, мол что-то не то делается, заявлялось вроде одно, а делается другое (опять же см. первый абзац первого поста темы). Об этом и на вики странице по сервису вынесено в отдельный пункт.
Одно дело - личное видение, другое дело - ожидания потенциальных участников. Поэтому вместо того, чтобы пенять мне на то, к чему, мягко говоря, я не причастен, сделайте доброе дело: обрисуйте то, что будет востребовано, может быть даже лично вами. Я же просто сравню это со своими представлениями и той архитектурой, что уже заложена в сервисе. Нет у меня желания делать что-то невостребованное. Вот что удобно и нужно - будет сделано, а что гипотетически может быть нужно - не будет с большой долей вероятности (интерес и так околонулевой к самой сути сервиса, а улучшения по мелочи для меня малосущественны в этом смысле, т.к. они реально не сделают сервис более востребованным именно как сервис, а не просто страничку в интернете).

[sb]

Что касается лично меня, я данные еще 2-3 проб, как до этих машин доберусь, закину.  Конкретно в моем случае даже открытая публикация этих данных ощутимого вреда не принесет.

Понятно, что трудно писать в 1 руки и в свободное время. Соавторов искать не пробовали?

Увы, но приёмка данных приостановлена (не только по следующей причине). Есть сомнения в том, что стоит продолжать что-то писать дальше в отсутствии четких запросов и ограниченности личных ресурсов. Поймите одну простую вещь: мне этот сервис, по большому счёту, не нужен и пользоваться им лично, скорее всего, я не буду, а если и буду, то кране редко. Так есть ли причина для его написания ?

[sb]

Вот сколько сейчас в базе проб, которые были не только для статистики по железу сделаны, но и для того, чтобы логи посмотреть ? Кстати, а кто их может посмотреть ?

А вы спросите тех, кто пробы загружал. Я точно в их голову не залазил и мысли на расстоянии не читал. Но судя по запросам, логи вообще не востребованы (очередной привет линуксоидам с "покажите лог x, y и z").
Логи может просмотреть любой желающий (у кого есть ссылка на пробу или установленный клиент), но только те логи, которые заданы (выводятся по запросу списка доступных логов для пробы). Никаких других логов по умолчанию просмотреть нельзя.