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

Evgeny Sinelnikov sin на altlinux.ru
Пт Ноя 11 15:17:12 MSK 2016


10 ноября 2016 г., 13:42 пользователь Alexey Gladkov
<legion at 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)


Подробная информация о списке рассылки Devel