On 07/28/2016 01:57 PM, Jakub Hrozek wrote:
On Thu, Jul 28, 2016 at 01:51:40PM +0200, Pavel Březina wrote:
> On 07/28/2016 01:38 PM, Jakub Hrozek wrote:
>> On Thu, Jul 28, 2016 at 12:23:24PM +0200, Michal Židek wrote:
>>> On 07/28/2016 10:00 AM, Pavel Březina wrote:
>>>> On 07/27/2016 03:28 PM, Michal Židek wrote:
>>>>> On 07/27/2016 11:09 AM, Jakub Hrozek wrote:
>>>>>> On Wed, Jul 27, 2016 at 11:03:34AM +0200, Pavel Březina wrote:
>>>>>>> On 07/26/2016 04:19 PM, Michal Židek wrote:
>>>>>>>> On 07/26/2016 01:19 PM, Pavel Březina wrote:
>>>>>>>>> On 07/25/2016 02:12 PM, Michal Židek wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> this patches makes the sssctl commands more
similar to
>>>>>>>>>> ipa tool commands. I also think this pattern
makes it
>>>>>>>>>> easier to remember the commands.
>>>>>>>>>>
>>>>>>>>>> Note that in the future, there will be more
user-*
>>>>>>>>>> group-* and netgroup-* commands (like seed for
user,
>>>>>>>>>> list of all etc.)
>>>>>>>>>>
>>>>>>>>>> Comments are welcome.
>>>>>>>>>>
>>>>>>>>>> Michal
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> ok, it looks like a good idea. When touching the
code, can you also
>>>>>>>>> convert sss_override command to use the macro
instead? And I think it
>>>>>>>>> may be nice to also add a macro for command sentinel
i.e. for {NULL,
>>>>>>>>> ...}.
>>>>>>>>>
>>>>>>>>> I'm not very fond of renaming local-data-* to
cache-* so it doesn't
>>>>>>>>> imply that we backup the whole cache content. We only
backup and
>>>>>>>>> restore
>>>>>>>>> data that are local to the client and not present in
LDAP. Currently
>>>>>>>>> only local overrides, but it may include local users
and groups in
>>>>>>>>> the
>>>>>>>>> future.
>>>>>>
>>>>>> When we have the files provider there would
>>>>>> be a cache as well. Moreover, we store secrets now. The restore
command
>>>>>> backs up all *.ldb files, right?
>>>>>
>>>>> This is how I understood it at first, but the current backup
>>>>> and restore only work for local overrides. But as Pavel mentioned,
>>>>> it may work for local users and groups in the future
>>>>> (id_provider=local). My original confusion was that I also
>>>>> thought it backs-up and restores all ldb files, which is
>>>>> not the case.
>>>>
>>>> No, the intention is to backup only data that are not stored on server
>>>> and would be lost when the cache is removed. In the time, only local
>>>> overrides were local. If secrets creates local data, the tool should be
>>>> modified.
>>>
>>> Yes, but users and groups from local domain would also be
>>> lost if the local data is deleted. So I though we want to backup
>>> them as well in the future versions (I mean the local provider,
>>> not the files provider).
>>
>> Well, probably not in the first version, but definitely in a couple of
>> months we want to add the capability to set extended attributes to the
>> files provider which we'll want to back up as well. But I also think we
>> will add the additional data into a new directory, just like we did with
>> the secrets database.
>>
>>>
>>> Btw. do we want to merge sss_override tool into sssctl?
>>> Because if the local-data-* commands work currently with
>>> overrides only, then we could make a new topic 'overrides' and add
commands
>>> like
>>
>> I would like to merge all tools into sssctl unless there is a strong
>> reason to keep them separate (the local domain tools should be kept
>> separate IMO).
>>
>> The reason is simply discoverability, if there is a new sssd release,
>> the admin would just run sssctl and if there are any new tools, their
>> topics would be displayed.
>>
>> (Also I think the code duplication would be reduced as a side-effect).
>>
>>>
>>> sssctl overrides-backup
>>> sssctl overrides-restore
>>>
>>> and later also all the functionality of sss_overrides
>>>
>>> sssctl overrides-user-add
>>> sssctl overrides-user-del
>>
>> Maybe, but later.
>>
>>>
>>> etc.
>>>
>>> This way we could avoid confusion between local-data and
>>> cache. If secrets will also create some local data, we will
>>> add topic 'secrets' to deal with that separately.
>>>
>>> sssctl secrets-backup
>>> sssctl secrets-restore
>>
>> I think I got lost in the thread :-) What is the benefit of having more
>> backup/restore commands than one that backs up or removes of value under
>> the /var/lib/sss/ structure? So far I can only think of cache being more
>> intuitive to admins than local-data.
>
> How about client-data instead of local-data?
SGTM (sounds good to me :-))
SGTM too :)
I will send version with client-data after the meeting.
Michal