[Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output

[Martin Basti]

On 22.10.2015 16:56, Petr Spacek wrote:
> On 22.10.2015 16:51, Martin Basti wrote:
>>
>> On 22.10.2015 16:35, Petr Spacek wrote:
>>> On 22.10.2015 16:13, Martin Basti wrote:
>>>> On 22.10.2015 10:44, Martin Babinsky wrote:
>>>>> https://fedorahosted.org/freeipa/ticket/5181
>>>>>
>>>>>
>>>>>
>>>> Thank you for the patch.
>>>>
>>>> 1)
>>>> +OPTIONAL_SERVICES = {
>>>> +    'DNS',
>>>> +    'CA',
>>>> +    'KRA',
>>>> +    'ADTRUST',
>>>> +    'EXTID',
>>>> +    'DNSKeyExporter',
>>>> +    'DNSSEC',
>>>> +    'DNSKeySync',
>>>> +}
>>>>
>>>> This did not scale well, maybe we should improve it to use some general
>>>> solution for whole IPA to distinct mandratory and optionl service, but I do
>>>> not know how (or if it is possible)
>>> Personally I would not create 'generic' solution until necessary. We have too
>>> much 'generic' code which was never tested outside the single use-case we
>>> have. Let's generalize it when needed.
>>>
>>>
>>>> 2)
>>>> +        search_filter=('(&(objectclass=ipaConfigObject)'
>>>> +                       '(ipaConfigString=enabledService))')
>>>>
>>>> Common user cannot read ipaConfigString, so this will work only for admins, I
>>>> do not see any limitations of access in code for other users.
>>> I think that this is okay. The user will see exactly what LDAP ACI allows him
>>> to see, i.e. nothing. We do the same with DNS, for example.
>> I disagree:
>>
>> [root at vm-065 ~]# kinit commonuser
>>
>> [root at vm-065 ~]# ldapsearch -Y GSSAPI -b
>> 'cn=masters,cn=ipa,cn=etc,dc=example,dc=com'
>> ...
>> # LDAPv3
>> # base <cn=masters,cn=ipa,cn=etc,dc=example,dc=com> with scope subtree
>> # filter: (objectclass=*)
>> # requesting: ALL
>> #
>> ...
>> # CA, vm-065.example.com, masters, ipa, etc,  example.com
>> dn: cn=CA,cn=vm-065.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
>> objectClass: top
>> objectClass: nsContainer
>> objectClass: ipaReplTopoManagedServer
>> objectClass: ipaConfigObject
>> objectClass: ipaSupportedDomainLevelConfig
>> cn: CA
>>
>>
>> [root at vm-065 ~]# ldapsearch -Y GSSAPI -b
>> 'cn=masters,cn=ipa,cn=etc,dc=example,dc=com' '(ipaConfigString=enabledService)'
>> ...
>> # LDAPv3
>> # base <cn=masters,cn=ipa,cn=etc,dc=example,dc=com> with scope subtree
>> # filter: (ipaConfigString=enabledService)
>> # requesting: ALL
>> #
>>
>> # search result
>> search: 4
>> result: 0 Success
>>
>> So as I said, a common user has no access to ipaConfigString attribute
> I agree with you - and I believe that current behavior is not a problem.
>
> $ ipa server-show will display the same information about enabled services as
> LDAP search - i.e. no information :-)
>
> In other words, ordinary user cannot see if the component is enabled or not,
> and because the user cannot judge this we will not show the information to
> him. I'm fine with that.
>
> Petr^2 Spacek
>
Okay, I missed your point, I understand now and I'm agree that only 
admin or more privileged users are able to see services.


>>> 4) Could you extend ipa server-find with an option to search for servers with
>>> a particular optional service? I think that it would be handy to do
>>> something like
>>> $ ipa server-find --service=CA
>>> to see list of CA servers.
>>>
>>> Thank you!