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?
>
> We can then keep the topic 'local' for the local
> provider related tools (if we want to merge them at
> some point). Like
>
> sssctl local-user-add (to replace sss_useradd)
> sssctl local-user-del (to replace sss_userdel) etc.
I'm not sure we want to merge id_provider=local into sssctl..
>
> What do you think?
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org