On 07/28/2016 02:11 PM, Michal Židek wrote:
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.
I forgot to update this after the meeting.
New patch is attached.
Michal