Dear Andreas,
I am the other guy who is working on this project. The answers are
inline:
>>
>> The following old configuration settings are overwriting the new
>> attribute based authorization. If U wouldn't like to use attribute
>> based authoriztaion then the following must be set:
>>
>> authorized_for_system_information=guest
>> authorized_for_configuration_information=guest
>> authorized_for_system_commands=guest
>> authorized_for_all_services=guest
>> authorized_for_all_hosts=guest
>> authorized_for_all_service_commands=guest
>> authorized_for_all_host_commands=guest
>>
>
> Err... Wait now. If I don't want to use attribute-based settings, only
> guest can log in? I won't take a patch that breaks the old way of
> setting
> auth parameters. I will take one that augments it, but not one that
> irrevocably replaces it with something incompatible.
It is just an example. If you disable the attribute-based
athorization with this config:
#authorization_config_file=/etc/niif/netm/cgiauth.cfg
then the old one will be used. So it will not break the old config.
Example:
>> authorized_for_system_information=guest admin
>> authorized_for_configuration_information=*
>> authorized_for_system_commands=*
>> authorized_for_all_services=*
>> authorized_for_all_hosts=guest judy johj
>> authorized_for_all_service_commands=guest
>> authorized_for_all_host_commands=guest
>> #authorization_config_file=/etc/niif/netm/cgiauth.cfg
>> Feature plan:
>> - We'll change the attribute based variable from fix 'entitlement'
>> to adjustable in either config file. We'll designing it and send U
>> a new patch with the documentation.
>>
>
> Don't use an adjustable environment variable name. That's just
> confusing.
> But why use an environment variable at all?
The reason is that we are using Shibboleth in our intitute and the
variables content everything (it is "entitlement" by Nagios at the
current situation).
Cheers,
Gabor
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]