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).
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
sssctl overrides-backup
sssctl overrides-restore
and later also all the functionality of sss_overrides
sssctl overrides-user-add
sssctl overrides-user-del
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
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.
What do you think?
>
>>
>>>>>
>>>>> * cache-backup Backup local data
>>>>> * cache-restore Restore local data from backup
>>>>>
>>>>
>>>> That was confusion on my side. I thought local data means
>>>> entire cache. In that case I would propose topic name "local"
>>>> for actions that work with data that is not present on remote
>>>> server.
>>>>
>>>> local-backup
>>>> local-restore
>>>>
>>>> What do you think?
>>>>
>>>> New patch is attached. I also added
>>>> patch for missing gettext macro (did not want
>>>> to hide this change in the first patch).
>>>>
>>>> Michal
>>>
>>> I'd still stick with local-data-backup and local-data-restore, what do
>>> others thing? But otherwise ack.
>>
>> I'm not sure, on one hand the admins would think 'cache' but on the
>> other hand, if we save and restore all cache data, the we operate on
>> more than the cache..
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
>
>
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org