On 05/23/2014 10:04 AM, Martin Kosek wrote:
On 05/23/2014 09:34 AM, thierry bordaz wrote:
On 05/23/2014 08:29 AM, Martin Kosek wrote:
On 05/22/2014 05:52 PM, thierry bordaz wrote:
On 05/22/2014 04:38 PM, Martin Kosek wrote:
On 05/22/2014 10:47 AM, Petr Viktorin wrote:
On 05/21/2014 10:00 PM, Dmitri Pal wrote:
On 05/19/2014 10:45 AM, thierry bordaz wrote:
On 05/19/2014 04:44 PM, Jan Cholasta wrote:
On 19.5.2014 16:34, thierry bordaz wrote:
On 05/19/2014 04:22 PM, Jan Cholasta wrote:
On 19.5.2014 16:03, thierry bordaz wrote:
On 05/19/2014 03:54 PM, Jan Cholasta wrote:
On 19.5.2014 15:19, Petr Viktorin wrote:
Hello list,
Here's a conversation that started internally. I'm making it

On 05/19/2014 01:00 PM, Martin Kosek wrote:
On 05/19/2014 12:46 PM, Petr Viktorin wrote:
On 05/19/2014 08:25 AM, Martin Kosek wrote:
On 05/19/2014 08:24 AM, Martin Kosek wrote:
On 05/16/2014 04:48 PM, thierry bordaz wrote:
Hello Martin,

        I am getting familiar with the freeipa CLI code and
        implemented '--to-stage' and '--from-stage'. This
really an
        impressive set of code :-)
Great! :-)

        I completed 'to-stage' and testing '--from-stage'.

        I have a question regarding the '--from-stage' syntax.
is a
        mandatory argument to 'user-add' subcommand. In the
design the
        '--from-stage' option is described with:

            ipa user-add --from-stage=tuser
Note, the design is here:

        But as 'uid' is mandatory the command should rather be

            ipa user-add tuser --from-stage=tuser

        In that case the option value for '--from-stage' is not
required and
        the command should be

            ipa user-add tuser --from-stage

        Is that ok if I implement the command like above or did I
        something ?

Hmm, no, I think you are right.  We can change --from-stage to
parameter. When it is true, it'd mean that get_dn or
retrieve the record from stage and use all it's attributes (and
default attributes values on top of that).

Also CC-ing Petr Viktorin for reference.
This operation can't change the user's attributes, can it?
I.e., we
support something like:
        ipa user-add tuser --from-stage --phone=123456789
If this is the case, what's the reason for using user-add for
Wouldn't it
be better to make this a separate command, say:
        ipa user-activate tuser
        ipa user-activate tuser --from-deleted
        ipa user-activate tuser --from-deleted --to-staged
+1, I would even go as far as having separate commands for staged
deleted users, e.g.:

       ipa user-unstage tuser
       ipa user-undelete tuser
       ipa user-undelete tuser --to-staged
A deleted entry has already been active so it contains already set
attributes while the pure staged entries are "almost" empty boxes.
from an administrator point of view, both staged/deleted entries are
inactive. What would be the advantages of two separated commands ?
You just said it yourself: activating/unstaging a user is quite
different from undeleting a user. Cramming multiple different
operations in a single command is bad design IMHO.
Ok I understand.
I believe that deleted entries and staged entries will be in the same
container (provisioning).
The design page mentions "cn=staged
users,cn=accounts,cn=provisioning,$SUFFIX" and "cn=deleted
users,cn=accounts,cn=provisioning,$SUFFIX", which are two different
Oppsss.. Sorry for the confusion :-[
So we may have at least those two possibilities:

     * ipa user-activate tuser [--from-staging|--from-delete]
     * ipa user-unstage tuser
       ipa user-undelete tuser
I like the idea of different verbs for different hives.
Something like:

Adding directly to stage via CLI: ipa user-stage
Removing from stage: user-unstage (user is gone)
Stage to Main -> activate; <- deactivate
Main to delete -> del; <-restore or undelete
Delete to stage -> I think we can use ipa user-stage command with
--deleted=user or similar
To be honest, I don't like this idea.
Too many names are confusing, if we can find a consistent option to cut the
number of names down we should do it.
IMO This is the worst part of Git:
http://assets.osteele.com/images/2008/git-transport.png . We can do better.

Another good thing would be if options did not affect the applicability of
other options (too much). For example in your proposal there'd be something
       ipa user-stage tuser --first=abc --last=xyz --phone=123 ......
       ipa user-stage --deleted=tuser  # <no attribute options allowed>
We should avoid this, if only for the reason that it makes the help text

My proposal would be that the move commands use the verb for the target
and an
option for the source, and add/mod use an option for the container:

1) adding a new user
(to active)   ipa user-add tuser ...
(to stage)    ipa user-add tuser --staged ...
(to deleted)  ipa user-add tuser --deleted ...  (*)

2) moving to main
(from stage)  ipa user-activate tuser  (**)
(from del)    ipa user-activate tuser --deleted

3) moving to deleted
(from active) ipa user-del tuser
(from stage)  ipa user-del tuser --staged

4) moving to stage
(from active) ipa user-stage tuser
(from del)    ipa user-stage tuser --deleted

5) modifying
(in active)   ipa user-mod tuser ...
(in stage)    ipa user-mod tuser --staged ...
(in del)      ipa user-mod tuser --deleted ...

Five commands (two of which are user-specific), plus two fairly consistent

If the delete container isn't configured, the --deleted option is illegal and
`user-del` deletes permanently.

(*) may be useful in some situations?
I personally cannot imagine such situation - I would not add this command. If
somebody needs that, he can workaround with

ipa user-add tuser --staged
ipa user-del tuser --staged

... and report us the use case when it's needed. But I general, Petr's
makes sense to me, I would go for it. (and update the design as Dmitri
correctly proposed).


Freeipa-devel mailing list

     I will update the design following Petr proposal. Great one !
     However I was thinking to a sligthly different proposal.  For
     example if we have 3 states: staging, active, inactive.
I personally think that inactive state may be confusing. Is inactive deleted
user? Or staged user? Or active disabled user (user-disable command)? Inactive
state would have too many meanings. The previously proposed states active,
staging and deleted sounds clearer to me.
Correct. Inactive is confusing and I prefer 'disabled'.
For me a 'disabled' used is a user that has been 'active' (should I say
'enabled'). That means he/she has a uidNumber/guidNUmber/ipaUniqueiD set... ,
in addition it is in a dedicated container and likely 'nsaccountlock: yes'.
In terms of FreeIPA vocabulary, disabled user is a user in an active user
container, but switch to disabled (nsaccountlock is yes). It can be easile
enabled with "ipa user-enable" command. I.e. "disabled user" term is already
taken and actively user for other state.

     1) adding a user

         (...to active) ipa user-add# ( after the command
         ipaUniqueID=<final value>)
         (... to staging) ipa user-add --stage# (after the command

         So here we can not add a user directly into inactive state
If by inactive you mean deleted, then yes.
Yes I was meaning 'inactive' as 'deleted' in Petr proposal.
I do not like very much the word 'deleted' because in term of LDAP it has a
different meaning.
In term of User life cycle, I have a feeling that 'delete' is a final state, we
can not return from 'delete'. This is why I prefered 'inactive' or now 
Ok, I see your point in the meaning from LDAP POV. However, we cannot use
'inactive' as it is confusing and we cannot use 'disabled' as it is already
used in other scenario. That leaves us with 'delete' state which IMO is
consistent in FreeIPA vocabulary - user is moved to *deleted users* container
with user-*del* command.

Ok I understand. 'delete' is the right choice, I vote for it and will update the design.

     2) activating the user

         (staging to active)   ipa user-activate# (after the command
         ipaUniqueID=<final value>)
         (inactive to active)  ipa user-activate --inactive# (after the
         command ipaUniqueID=<final value>)
--inactive -> --deleted

     3) inactivate the user

         (active to inactive)  ipa user-inactivate# (after the command
         ipaUniqueID=<final value>)

         Here there is no possibility to move back an active entry to
         staging, because in staging
         the entries do not have ipaUniqueID set
Why is having ipaUniqueID attribute a problem for a staged user?
My understanding is that an account moves from 'staging' to 'active' when we
receive a formal approval.

Here what is not clear to me is what is this approval.
Would it be a user granted the autorization to run 'ipa user-activate', or an attribute set in the 'staging' entry (a task could them 'activate' all the staging entries which receive the approval), or a kind of 'approved group' that contains the DN of approved entries, or...

Before the approval, the ipaUniqueID is 'generate'
and after it is a valid account.

For example, the user attribute should be:

                Staging Active                             Disabled
ipaUniqueID: generate           ipaUniqueID: abc-def-ghi-jkl ipaUniqueID:
uidNumber: -1                   uidNumber: 1234uidNumber: 1234
gidNumber: -1                   gidNumber: 1234gidNumber: 1234
<no memberof> attribute         memberof: *                              <no
nsaccountlock: true             nsaccountlock: false
nsaccountlock: true
Nice overview, we may even add it to design. Looks correct to me, though I
still do not undestand practical reasons why a user moved from active to staged
container cannot have ipaUniqueID already generated.
I think an advantage of having 'active'->'staging' is that the customer has not to understand some constraint of the state machine. Everything is allowed staging<-->active<-->delete.

On the opposite I believe

 * the entries in staging will not have the same "properties". Some may
   have ipaUniqueID/uidNumber set, some others may not.
 * What would be the real difference between 'staging' and 'delete'. It
   looks like the same state.

The command to "inactivate" the user is user-del.

     4) modify the user

         (from active)       ipa user-mod # (after the command
         ipaUniqueID=<final value>)
         (from inactive)     ipa user-mod   --inactive# (after the
         command ipaUniqueID=<final value>)
--inactive -> --deleted

         (from staging)      ipa user-mod --stage # (after the command

     5) delete user

         (staging to delete)   ipa user-del
         (inactive to delete)  ipa user-del --inactive

         Here the entries are definitely removed
I would stick to original proposal:

(from active) ipa user-del tuser
(from stage)  ipa user-del tuser --staged
Is this command to move entry from active/staging into delete container.
How to delete definitely an entry ? with a option like '--remove' ?
The move from active users to deleted users container was planned to be done by
a plugin so that a simple ldapdelete can be called and the user is saved:


To delete permanently, we could offer

ipa user-del tuser --deleted

command. (Or do not offer the command at all and force admins to use ldapdelete
to *permanently* delete the account). Missing this API should not be a problem
as in most small-scale deployments, advanced user life-cycle will not be 


Freeipa-devel mailing list

Reply via email to