[devel] system-report с профилями

[devel] system-report с профилями

[Evgeny Sinelnikov]

Здравствуйте,

хочу поделиться идеей-предложением о расширении возможностей утилиты
system-report. Само предложение я собрал в виде тестового задания:
#172104 EPERM #1 [test-only] sisyphus system-report.git=0.2.0-alt1
git.altlinux.org/people/sin/packages/system-report.git

$ system-report --help | tail -n7
   -o, --outfile=FILE  Save report archive info <FILE>;
   -p, --profile=TYPE  Type of report: system, client, server, all;
   -q, --quiet         Try to be more quiet;
   -v, --verbose       Print a message for each action;
   -V, --version       Print program version and exit;
   -h, --help          Show this message.

Собственно, что добавлено?
Добавлена опция --profiles, которая позволяет задавать тип собираемой
информации. По-умолчанию используется system, который соответствует
текущему набору.

Дополнительно можно задать client, server или all. Если опция
-p/--profile задана, то к имени архива добавляется соответствующий
суффикс.

Для клиента и сервера общим является сбор информации о:
- настройках возможностей control;
- клиентских настройках Kerberos;
- настройках NSS и PAM;
- а также release и rpmlist.

К набору настроек клиента добавлены настройки и логи Xorg, а к набору
настроек сервера - сетевые настройки и настройки Samba.

Можно подумать - подходит ли нам такой вариант?
Ну, а пользоваться этим расширенным вариантом утилиты я уже начал.


# system-report --profile server
Obtaining status of control facilities [ DONE ]
Obtaining client Kerberos configuration  [ DONE ]
Obtaining network information [ DONE ]
Obtaining NSS (Name Service Switch) configuration [ DONE ]
Obtaining PAM configuration and auth log files [ DONE ]
Obtaining distribution release file [ DONE ]
Obtaining installed RPM packages [ DONE ]
Obtaining Samba configuration and log files [ DONE ]
Saving system information to sysreport-server-20161110.tar.xz [ DONE ]


Please submit /root/sysreport-server-20161110.tar.xz to sysreport@altlinux.org


$ sudo system-report -p client
Obtaining status of control facilities [ DONE ]
Obtaining client Kerberos configuration [ DONE ]
Obtaining NSS (Name Service Switch) configuration [ DONE ]
Obtaining PAM configuration and auth log files [ DONE ]
Obtaining distribution release file [ DONE ]
Obtaining installed RPM packages [ DONE ]
Obtaining Xorg configuration files [ DONE ]
Obtaining Xorg log files [PASSED]
Saving system information to sysreport-client-20161110.tar.xz [ DONE ]


Please submit /home/sin/build/altlinux/system/system-report/sysreport-client-20161110.tar.xz
to sysreport@altlinux.org



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] system-report с профилями

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

Здравствуйте Evgeny Sinelnikov
  В сообщении от 10 ноября 2016 Evgeny Sinelnikov написал(a):
> Здравствуйте,
>
> хочу поделиться идеей-предложением о расширении возможностей
> утилиты system-report. Само предложение я собрал в виде
> тестового задания: #172104 EPERM #1 [test-only] sisyphus
> system-report.git=0.2.0-alt1
> git.altlinux.org/people/sin/packages/system-report.git
>
........
>
>
> Please submit
> /home/sin/build/altlinux/system/system-report/sysreport-client
>-20161110.tar.xz to sysreport@altlinux.org
Очень интересно,
На форуме силами "sb" ведётся разработка поддерживаемого 
оборудования, в котором используется system-report. 
https://forum.altlinux.org/index.php?topic=36472

Хорошо-бы внимательно посмотреть с этой точки зрения. Что ничего 
не сломается у него. И вообще ... - стоит обратить на его работу 
внимание.


-- 
  А ещё говорят так  (fortune): 
 
Democracy is the name we give the people whenever we need 
them. -- Arman de Caillavet, 1913 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] system-report с профилями

[Alexey Gladkov]

On Thu, Nov 10, 2016 at 04:33:48AM +0300, Evgeny Sinelnikov wrote:
> Добавлена опция --profiles, которая позволяет задавать тип собираемой
> информации. По-умолчанию используется system, который соответствует
> текущему набору.

Можете объяснить необходимость такого деления ?

По какому критерию вы предлагаете делить собираемую информацию на эти
категории (профили) ?

> Дополнительно можно задать client, server или all. Если опция
> -p/--profile задана, то к имени архива добавляется соответствующий
> суффикс.

Такое резделение нарушает основную идею этого скрипта. Он создавался для
того чтобы его запускали неподготовленные пользователи. Это одна из причин
почему он был написан монолитным скриптом, а не кучей модулей. Сейчас он
написан так, чтобы пользователь минимально принимал участие в его работе.

Вы же предлагаете создавать профили, которые можно/нужно выбирать. Это
приведёт к тому, что пользователи будут слать не всю возможную полезную
информацию а только её часть.

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

> Для клиента и сервера общим является сбор информации о:
> - настройках возможностей control;
> - клиентских настройках Kerberos;
> - настройках NSS и PAM;

Поясните о каких настроцках NSS идёт речь ?

> - а также release и rpmlist.
> 
> К набору настроек клиента добавлены настройки и логи Xorg, а к набору
> настроек сервера - сетевые настройки и настройки Samba.

Почему эти данные нельзя собирать с остальными (например с lspci) ?

-- 
Rgrds, legion

Re: [devel] system-report с профилями

[Michael Shigorin]

On Thu, Nov 10, 2016 at 04:33:48AM +0300, Evgeny Sinelnikov wrote:
> Please submit
> /home/sin/build/altlinux/system/system-report/sysreport-client-20161110.tar.xz
> to sysreport@altlinux.org

Его кто-нить получает/читает, кстати?

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] system-report с профилями

[Evgeny Sinelnikov]

10 ноября 2016 г., 13:42 пользователь Alexey Gladkov
<legion@altlinux.ru> написал:
> On Thu, Nov 10, 2016 at 04:33:48AM +0300, Evgeny Sinelnikov wrote:
>> Добавлена опция --profiles, которая позволяет задавать тип собираемой
>> информации. По-умолчанию используется system, который соответствует
>> текущему набору.
>
> Можете объяснить необходимость такого деления ?

Первоначальная мысль - обратная совместимость.

>
> По какому критерию вы предлагаете делить собираемую информацию на эти
> категории (профили) ?

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


>
>> Дополнительно можно задать client, server или all. Если опция
>> -p/--profile задана, то к имени архива добавляется соответствующий
>> суффикс.
>
> Такое резделение нарушает основную идею этого скрипта. Он создавался для
> того чтобы его запускали неподготовленные пользователи. Это одна из причин
> почему он был написан монолитным скриптом, а не кучей модулей. Сейчас он
> написан так, чтобы пользователь минимально принимал участие в его работе.
>
> Вы же предлагаете создавать профили, которые можно/нужно выбирать. Это
> приведёт к тому, что пользователи будут слать не всю возможную полезную
> информацию а только её часть.
>
> Даже сейчас есть возможность отключить те или иные проверки, что позволяет
> лишиться части полезной информации, но это была необходимая мера. Мне не
> очень понятно зачем укрупнять это.

Понятно почему. Объяснить пользователю или роботу собрать инфу о
клиенте или сервере - задача понятная. Выпиливать отдельные элементы -
задача не очевидная, исключительная.

Но я не спорю. Мне нужен был инструмент для сборки иной инфы, чем о
железе (PAM, NSS, Samba, Kerberos). Я не хотел плодить ещё один
инструмент. Я не хотел придумывать схему работы скрипта. Поэтому я
доработал system-report так, чтобы это никак не повлияло на его
текущее состояние.

>> Для клиента и сервера общим является сбор информации о:
>> - настройках возможностей control;
>> - клиентских настройках Kerberos;
>> - настройках NSS и PAM;
>
> Поясните о каких настроцках NSS идёт речь ?

Как о каких?

/etc/nsswitch.conf и потенциально неограниченное количество
NSS-модулей (например, ldap, winbind или sss), у каждого из которых
ещё и свой набор настроек и логов.

>
>> - а также release и rpmlist.
>>
>> К набору настроек клиента добавлены настройки и логи Xorg, а к набору
>> настроек сервера - сетевые настройки и настройки Samba.
>
> Почему эти данные нельзя собирать с остальными (например с lspci) ?

Можно. Я не против собирать всё. Но...
- всегда будут непонятные тесты, которые для пользователя не
отработали, потому что не всё у него есть;
- объём лога для информации о железе сильно вырастает.

Кстати, я бы предложил паковать в архив карту о прошедших и не
прошедших этапах сбора. Тогда будет понятно какие тесты проходили и
что стоит ожидать найти в архиве.

Итого, профили мне кажутся логичными по смыслу:
- Железо (system)
- Клиенты (client) здесь инфа об иксах, DM, DE и т.п.
- Сервера (server) здесь инфа о сервисах (DNS, LDAP, ...)

Но можно и не делить, а просто наращивать портянку. И тогда, когда
потребуется что-то выключать группами, потребуются всё те же профили.
Но это спорный момент. Мне нужны логи конфиги (PAM, NSS, Samba, ...
далее sssd, bind, dnsmasq, krb5kdc, lightdm, kdm, ...)

Это можно в профили для серверов и клиентов заправить, а можно всё в
одной кучей собирать.
В общем случае, не принципиально будут ли при этом профили или нет.

Как раз и хотелось, чтобы пользователи слали "не всю возможную
полезную информацию а только её часть". Возможно это ошибочное
желание. Но что более ошибочно: "Догадываться что мы собираем, пытаясь
собрать всё,  или собирать явно понятный набор?" Хотя... мы так уже
догадываемся...

Кстати, если в профиле что-то пропущено из полезного, то его можно
туда добавить. Например, client и server могут включать в себя большую
часть или весь system.

Но, ещё раз, это не принципиальный вопрос. Принципиально иметь
возможность собирать системную инфу не только о железе, но и ключевых
настройках операционной системы.



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] system-report с профилями

[Alexey Gladkov]

On Fri, Nov 11, 2016 at 03:17:12PM +0300, Evgeny Sinelnikov wrote:
> > Поясните о каких настроцках NSS идёт речь ?
> 
> Как о каких?
> 
> /etc/nsswitch.conf и потенциально неограниченное количество
> NSS-модулей (например, ldap, winbind или sss), у каждого из которых
> ещё и свой набор настроек и логов.

Я подумал про другой nss :)

> Можно. Я не против собирать всё. Но...
> - всегда будут непонятные тесты, которые для пользователя не
> отработали, потому что не всё у него есть;

Это происходит и сейчас.

> - объём лога для информации о железе сильно вырастает.

Это не важно.

> Кстати, я бы предложил паковать в архив карту о прошедших и не
> прошедших этапах сбора. Тогда будет понятно какие тесты проходили и
> что стоит ожидать найти в архиве.

Хорошая мысль. Я положу в архив список тестов и их статусы.

> Но, ещё раз, это не принципиальный вопрос. Принципиально иметь
> возможность собирать системную инфу не только о железе, но и ключевых
> настройках операционной системы.

Уже сейчас собирается информация о состоянии сетевых интерфейсов и
маршрутах, список установленных rpm. Это явно не "железная" информация :)

Для меня нет понятия client и server. На мой взгляд, нужно просто добавить
проверок с тем, что вам нужно и собирать всё что обнаружится. Если у
пользователя нет bind или openldap, то информация о них и не попадёт в
репорт, а попадёт информация о kdm и kde.

-- 
Rgrds, legion

Re: [devel] system-report с профилями

[Evgeny Sinelnikov]

Итого, профили убираем.
Собираем, что нашлось
Список, проверяемого добавляем в архив.

Что мне теперь нужно сделать, чтобы добавленные действия по сбору
данных попали в основную ветку?
Добавить их по одному за коммит заново без поддержки профилей и залить в git?




11 ноября 2016 г., 15:53 пользователь Alexey Gladkov
<legion@altlinux.ru> написал:
> On Fri, Nov 11, 2016 at 03:17:12PM +0300, Evgeny Sinelnikov wrote:
>> > Поясните о каких настроцках NSS идёт речь ?
>>
>> Как о каких?
>>
>> /etc/nsswitch.conf и потенциально неограниченное количество
>> NSS-модулей (например, ldap, winbind или sss), у каждого из которых
>> ещё и свой набор настроек и логов.
>
> Я подумал про другой nss :)
>
>> Можно. Я не против собирать всё. Но...
>> - всегда будут непонятные тесты, которые для пользователя не
>> отработали, потому что не всё у него есть;
>
> Это происходит и сейчас.
>
>> - объём лога для информации о железе сильно вырастает.
>
> Это не важно.
>
>> Кстати, я бы предложил паковать в архив карту о прошедших и не
>> прошедших этапах сбора. Тогда будет понятно какие тесты проходили и
>> что стоит ожидать найти в архиве.
>
> Хорошая мысль. Я положу в архив список тестов и их статусы.
>
>> Но, ещё раз, это не принципиальный вопрос. Принципиально иметь
>> возможность собирать системную инфу не только о железе, но и ключевых
>> настройках операционной системы.
>
> Уже сейчас собирается информация о состоянии сетевых интерфейсов и
> маршрутах, список установленных rpm. Это явно не "железная" информация :)
>
> Для меня нет понятия client и server. На мой взгляд, нужно просто добавить
> проверок с тем, что вам нужно и собирать всё что обнаружится. Если у
> пользователя нет bind или openldap, то информация о них и не попадёт в
> репорт, а попадёт информация о kdm и kde.
>
> --
> Rgrds, legion
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] system-report с профилями

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]

Здравствуйте Alexey Gladkov
  В сообщении от 11 ноября 2016 Alexey Gladkov написал(a):
> Для меня нет понятия client и server. На мой взгляд, нужно
> просто добавить проверок с тем, что вам нужно и собирать всё
> что обнаружится. Если у пользователя нет bind или openldap, то
> информация о них и не попадёт в репорт, а попадёт информация о
> kdm и kde.

Хорошо-бы сразу продумать как полученный архив обрабатывать 
каким-нибудь роботом. Типа вначале описать структуру архива, а 
потом её придерживаться, независимо от состава проверенных 
тестов. На примере 
https://forum.altlinux.org/index.php?topic=36472.0
видно, что изменение формата архива может "отбить всю охоту" его 
обрабатывть.

И по-моему профили тут не должны мешать, если поведение 
по-умолчанию не меняется. Нужна стандартная кофигурация об 
железе - запускай system-report без параметров, имеешь 
специфичный интерес - запусти с нужным профилем. Опять-же, если 
rescue образ положен в специальный дистрибутив, он может 
запускаться в нём с учётом его особенностей. А делать свалку из 
всего, что можно собрать, по-моему не разумно.


-- 
  А ещё говорят так  (fortune): 
 
Work without a vision is slavery, Vision without work is a pipe 
dream, But vision with work is the hope of the world. 
________________________________________________________________________
С уважением Хихин Руслан 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] system-report с профилями

[Alexey Gladkov]

On Fri, Nov 11, 2016 at 08:18:06PM +0300, Evgeny Sinelnikov wrote:
> Итого, профили убираем.
> Собираем, что нашлось
> Список, проверяемого добавляем в архив.
> 
> Что мне теперь нужно сделать, чтобы добавленные действия по сбору
> данных попали в основную ветку?
> Добавить их по одному за коммит заново без поддержки профилей и залить в git?

Да. Сделайте бранч с изменениями и пришлите ссылку. Обсудим и смерджим.

-- 
Rgrds, legion

Re: [devel] system-report с профилями

[Alexey Gladkov]

On Fri, Nov 11, 2016 at 10:57:47PM +0300, Hihin Ruslan wrote:
> Здравствуйте Alexey Gladkov
>   В сообщении от 11 ноября 2016 Alexey Gladkov написал(a):
> > Для меня нет понятия client и server. На мой взгляд, нужно
> > просто добавить проверок с тем, что вам нужно и собирать всё
> > что обнаружится. Если у пользователя нет bind или openldap, то
> > информация о них и не попадёт в репорт, а попадёт информация о
> > kdm и kde.
> 
> Хорошо-бы сразу продумать как полученный архив обрабатывать 
> каким-нибудь роботом. Типа вначале описать структуру архива, а 
> потом её придерживаться, независимо от состава проверенных 
> тестов. На примере 
> https://forum.altlinux.org/index.php?topic=36472.0
> видно, что изменение формата архива может "отбить всю охоту" его 
> обрабатывть.

system-report формирует архив используя утилиты из разных проектов.
Гарантировать неизменность формата вывода этих утилит я не могу.

Чтобы зафиксировать формат архива нужно вывод каждой утилиты, каждый отчёт
разобрать и перевести в "стандартизированный" формат. После этого имеет
смысл говорить о об описании структуры и формата. Проделать такое я вряд
ли возьмусь, но вы можете попробовать. Или же вы можете обратиться к
проекту sosreport[1].

[1] github.com/sosreport/sos

> И по-моему профили тут не должны мешать, если поведение 
> по-умолчанию не меняется. Нужна стандартная кофигурация об 
> железе - запускай system-report без параметров, имеешь 
> специфичный интерес - запусти с нужным профилем.

Именно этой свободы выбора я и хочу избежать. Изначально эта утилита была
придумана для инсталлятора. Чтобы по окончании установки автоматически
(без вопросов) создать отчёт и только попросить пользователя отправить
его. Лишь потом эту утилиту стали использовать в rescue и для получения
дополнительной инфорации в случае проблем у пользователя. Так что утилита
расчитана на минимальное участие пользователя и минимальную его
подготовку. "запусти с нужным профилем" не то что каждый пользователь
осилит.

> Опять-же, если 
> rescue образ положен в специальный дистрибутив, он может 
> запускаться в нём с учётом его особенностей. А делать свалку из 
> всего, что можно собрать, по-моему не разумно.

Вот такой я неразумный. А ещё я упрямый.

-- 
Rgrds, legion