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


_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org

_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org

Reply via email to