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
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
