Re: [Freeipa-devel] Understanding FreeIPA replica internals

[Simo Sorce]

On Fri, 2014-05-23 at 22:57 -0400, James wrote:
> On Fri, 2014-05-23 at 22:50 -0400, Simo Sorce wrote:
> > No, but those need to be accessible to the user, I think you can
> > create
> > a meta-package that contains those password when you create the first
> > master, encrypted in a gpg file with private keys only stored in the
> > freeipa servers.
> I do something similar for the admin.
> https://github.com/purpleidea/puppet-ipa/tree/feat/better-pw
> I'll blog (as docs) about the details shortly.
> 
> > 
> > Then you can move them around w/o puppet knowing what they contain,
> > although puppet will have to transfer at least public keys around.
> Are you okay with each individual ipa server having a different
> pub/private keypair, and a gpg encrypted file being passed around
> containing the cleartext dm_password ? The private key on each host
> wouldn't be able to have a password, _and_ ultimately someone with root
> could get the cleartext password, where as the current status quo
> probably hashes it. So I would see this as less secure.

The problem is, you need to use those password for the install, so you
have to have them somehow available on the systems themselves,
especially if you autogenerate them.

The admin will need to know to go on the systems, read and memorize/save
elsewhere the passwords and delete the gpg files.

We are bootstrapping the system here, so something needs to know those
secrets. The CA private certificate is also on one of those systems, so
if you decide puppet has access to them you have to come to terms with
the fact puppet will have access to the keys of the kingdom. If you do
not like that ... don't use puppet and manually install.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Understanding FreeIPA replica internals

[James]

On Fri, 2014-05-23 at 22:50 -0400, Simo Sorce wrote:
> No, but those need to be accessible to the user, I think you can
> create
> a meta-package that contains those password when you create the first
> master, encrypted in a gpg file with private keys only stored in the
> freeipa servers.
I do something similar for the admin.
https://github.com/purpleidea/puppet-ipa/tree/feat/better-pw
I'll blog (as docs) about the details shortly.

> 
> Then you can move them around w/o puppet knowing what they contain,
> although puppet will have to transfer at least public keys around.
Are you okay with each individual ipa server having a different
pub/private keypair, and a gpg encrypted file being passed around
containing the cleartext dm_password ? The private key on each host
wouldn't be able to have a password, _and_ ultimately someone with root
could get the cleartext password, where as the current status quo
probably hashes it. So I would see this as less secure.

> 
> Simo.



signature.asc
Description: This is a digitally signed message part
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Understanding FreeIPA replica internals

[Simo Sorce]

On Fri, 2014-05-23 at 21:26 -0400, James wrote:
> On Fri, May 23, 2014 at 7:49 PM, Simo Sorce  wrote:
> > On Fri, 2014-05-23 at 17:16 -0400, James wrote:
> >> On Fri, 2014-05-23 at 15:44 +0200, Martin Kosek wrote:
> >> > One cannot easily improve ipa-replica-prepare to work through LDAPI as
> >> > we also
> >> > need to encypher the replica info package - and we cannot do that
> >> > without clear
> >> > text DM password.
> >> >
> >> > The right way seems to be rather the RFE you filed:
> >> > https://fedorahosted.org/freeipa/ticket/2888
> >> >
> >> > Martin
> >>
> >> Here is the model I am considering:
> >>
> >> Since each replica in a multi-master cluster is said to be functionally
> >> "identical" once they're all setup, I'd actually like to try and match
> >> this elegant symmetry that you've provided with an equally symmetrical
> >> (or homogeneous, rather) design. That's to say I want the config
> >> management parts to "be identical" on each host.
> >>
> >> What this means:
> >> * It should be possible to parallelize a good chunk of the setup, if I
> >> were to bring up a cluster of four hosts at the same time.
> >>
> >> * It's convenient if each individual host follows the same initial
> >> ipa-server-install process, but that there is a secondary "join with my
> >> peer" process.
> >>
> >> * In theory, if I set up two identical freeipa servers with the same
> >> options (but different hostnames) I would like to be able to introduce
> >> them to each other at a later date and join them (even if this means
> >> that we pick one as the source of the data and the others data gets
> >> overwritten)
> >
> > What is the point really ?
> >
> > You get this "symmetrical" install by doing a useless install of all
> > fours and then practically redoing the install for 3 of the 4. Might as
> > well just install 1 first and then do the other 3 in parallel, less CPU
> > gets wasted.
> This might actually be a good approach. I'll be trying to prototype
> some things this week, and I'll try this out.
> 
> >
> >> Does this help explain the need? For an example of peering that works
> >> this way and is symmetrical with configuration management, my
> >> puppet-gluster module does this.
> >
> > I think this is a case where aesthetics clash with reality.
> I think I agree. The exception is that if the hosts are not all the
> same, this makes specifying the config management bits significantly
> harder. If they're the same, you can use a common pattern for all
> hosts. This gives you a sort of "high availability" at the config
> management level, meaning that if the host you designated as #1 is
> down, you'd still be able to continue.
> 
> > Reality requires a serialization due to the need of having a common CA
> > that releases certificates and a common KDC database that release
> > keytabs for all services before all of them are installed.
> 
> Thank you for your input. One of my goals is to satisfy your
> requirements on the "security" side. I'm sure you wouldn't approve of
> the status quo of storing the dm_password and admin_password in
> puppet. Me neither :)

No, but those need to be accessible to the user, I think you can create
a meta-package that contains those password when you create the first
master, encrypted in a gpg file with private keys only stored in the
freeipa servers.

Then you can move them around w/o puppet knowing what they contain,
although puppet will have to transfer at least public keys around.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Understanding FreeIPA replica internals

[James]

On Fri, May 23, 2014 at 7:49 PM, Simo Sorce  wrote:
> On Fri, 2014-05-23 at 17:16 -0400, James wrote:
>> On Fri, 2014-05-23 at 15:44 +0200, Martin Kosek wrote:
>> > One cannot easily improve ipa-replica-prepare to work through LDAPI as
>> > we also
>> > need to encypher the replica info package - and we cannot do that
>> > without clear
>> > text DM password.
>> >
>> > The right way seems to be rather the RFE you filed:
>> > https://fedorahosted.org/freeipa/ticket/2888
>> >
>> > Martin
>>
>> Here is the model I am considering:
>>
>> Since each replica in a multi-master cluster is said to be functionally
>> "identical" once they're all setup, I'd actually like to try and match
>> this elegant symmetry that you've provided with an equally symmetrical
>> (or homogeneous, rather) design. That's to say I want the config
>> management parts to "be identical" on each host.
>>
>> What this means:
>> * It should be possible to parallelize a good chunk of the setup, if I
>> were to bring up a cluster of four hosts at the same time.
>>
>> * It's convenient if each individual host follows the same initial
>> ipa-server-install process, but that there is a secondary "join with my
>> peer" process.
>>
>> * In theory, if I set up two identical freeipa servers with the same
>> options (but different hostnames) I would like to be able to introduce
>> them to each other at a later date and join them (even if this means
>> that we pick one as the source of the data and the others data gets
>> overwritten)
>
> What is the point really ?
>
> You get this "symmetrical" install by doing a useless install of all
> fours and then practically redoing the install for 3 of the 4. Might as
> well just install 1 first and then do the other 3 in parallel, less CPU
> gets wasted.
This might actually be a good approach. I'll be trying to prototype
some things this week, and I'll try this out.

>
>> Does this help explain the need? For an example of peering that works
>> this way and is symmetrical with configuration management, my
>> puppet-gluster module does this.
>
> I think this is a case where aesthetics clash with reality.
I think I agree. The exception is that if the hosts are not all the
same, this makes specifying the config management bits significantly
harder. If they're the same, you can use a common pattern for all
hosts. This gives you a sort of "high availability" at the config
management level, meaning that if the host you designated as #1 is
down, you'd still be able to continue.

> Reality requires a serialization due to the need of having a common CA
> that releases certificates and a common KDC database that release
> keytabs for all services before all of them are installed.

Thank you for your input. One of my goals is to satisfy your
requirements on the "security" side. I'm sure you wouldn't approve of
the status quo of storing the dm_password and admin_password in
puppet. Me neither :)

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Understanding FreeIPA replica internals

[Simo Sorce]

On Fri, 2014-05-23 at 17:16 -0400, James wrote:
> On Fri, 2014-05-23 at 15:44 +0200, Martin Kosek wrote:
> > One cannot easily improve ipa-replica-prepare to work through LDAPI as
> > we also
> > need to encypher the replica info package - and we cannot do that
> > without clear
> > text DM password.
> > 
> > The right way seems to be rather the RFE you filed:
> > https://fedorahosted.org/freeipa/ticket/2888
> > 
> > Martin
> 
> Here is the model I am considering:
> 
> Since each replica in a multi-master cluster is said to be functionally
> "identical" once they're all setup, I'd actually like to try and match
> this elegant symmetry that you've provided with an equally symmetrical
> (or homogeneous, rather) design. That's to say I want the config
> management parts to "be identical" on each host.
> 
> What this means:
> * It should be possible to parallelize a good chunk of the setup, if I
> were to bring up a cluster of four hosts at the same time.
> 
> * It's convenient if each individual host follows the same initial
> ipa-server-install process, but that there is a secondary "join with my
> peer" process.
> 
> * In theory, if I set up two identical freeipa servers with the same
> options (but different hostnames) I would like to be able to introduce
> them to each other at a later date and join them (even if this means
> that we pick one as the source of the data and the others data gets
> overwritten)

What is the point really ?

You get this "symmetrical" install by doing a useless install of all
fours and then practically redoing the install for 3 of the 4. Might as
well just install 1 first and then do the other 3 in parallel, less CPU
gets wasted.

> Does this help explain the need? For an example of peering that works
> this way and is symmetrical with configuration management, my
> puppet-gluster module does this.

I think this is a case where aesthetics clash with reality.
Reality requires a serialization due to the need of having a common CA
that releases certificates and a common KDC database that release
keytabs for all services before all of them are installed.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] OTP Sync Client Design

[Nathaniel McCallum]

On Wed, 2014-05-14 at 14:08 -0400, Nathaniel McCallum wrote:
> Occasionally OTP tokens get out of sync with the server. When this
> happens, the user or an admin need to synchronize the token. To this
> end, we landed server-side synchronization support, which is a simple
> bind with a custom control. This all works with my sample test script.
> 
> Client support is proving a bit more difficult. In the ideal world, the
> client would contact LDAP directly and perform the operation. This would
> make a man in the middle attack difficult and we can ensure encryption
> over the entire operation.
> 
> However, browsers, without server-side assistance, cannot perform this
> operation from javascript. This means that, in this case, the first
> factor and two second factors must be transmitted to the FreeIPA server
> and then proxied to 389. Is this an acceptable compromise?
> 
> This command also needs to be accessible *without* an existing user
> login since, if a user's token is out of sync, the user can't login. Is
> it possible to expose such an API? If so, how? Both "ipa env" and "ipa
> ping" seem to require kinit, so I don't see any obvious examples.

Thanks everyone for your feedback. This particular feature is proving
difficult to implement, even with our agreed upon design. To reiterate
this design: there will be an HTTP method by which to synchronize
tokens.

There are two assumptions in the code which are making this difficult:
1. All cli commands are Command subclasses.
2. All Command subclasses create authenticated server methods.

There are thus two ways to tackle this problem.

First, I can create a standard POST method in rpcserver.py. This is not
very modular. But the biggest problem is that there is no way to create
the cli-side command to call it (assumption #1).

Second, I can create a Command subclass, similar to the passwd plugin.
This will create both the client- and server-side components. However,
there is no way to disable the server-side authentication.

I think that solving the second of these problems is the most reusable.
Just as an example, the ping command currently requires authentication
but does not need to do so. The passwd Command too shouldn't need to
authenticate before executing the command because the command
authenticates itself.

I think it very likely that we are going to have need for other Command
subclasses in the future which do not require authentication.

However, implementing this approach is rather difficult as it will
require a refactoring of rpcserver.py. The code in rpcserver.py contains
many layering violations and the class structure is rather unclear
(look, for instance, at the different orders in which xmlrpc and jsonrpc
classes inherit from their parent classes).

The current problem forcing this refactoring is that authentication
appears to happen across several different layers, but always before the
command to be executed is unmarshalled. We need to invert this order:
the command needs to be unmarshalled first in order to determine whether
or not authentication is necessary. I don't think that switching this
order is practical without constraining authentication to a single layer
(or two: session and krb5) late in the request process.

Git tells me that lots of people have touched this code, so I'm hoping
for good feedback! ;)

Alternatively, we could create a way to inject cli commands without
having Command subclasses. Isolating these concerns is itself probably a
good design choice. Ideally we'd have a structure where the Command
class itself inherits from a CLICommand class and a ServerMethod class.
But this too will be a massive refactoring, perhaps even bigger than the
rpcserver.py refactoring.

So, which assumption should we break: #1 or #2? And who wants to help me
do it? Also, I am all ears for easier solutions for this feature.

Nathaniel

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Understanding FreeIPA replica internals

[James]

On Fri, 2014-05-23 at 15:44 +0200, Martin Kosek wrote:
> One cannot easily improve ipa-replica-prepare to work through LDAPI as
> we also
> need to encypher the replica info package - and we cannot do that
> without clear
> text DM password.
> 
> The right way seems to be rather the RFE you filed:
> https://fedorahosted.org/freeipa/ticket/2888
> 
> Martin

Here is the model I am considering:

Since each replica in a multi-master cluster is said to be functionally
"identical" once they're all setup, I'd actually like to try and match
this elegant symmetry that you've provided with an equally symmetrical
(or homogeneous, rather) design. That's to say I want the config
management parts to "be identical" on each host.

What this means:
* It should be possible to parallelize a good chunk of the setup, if I
were to bring up a cluster of four hosts at the same time.

* It's convenient if each individual host follows the same initial
ipa-server-install process, but that there is a secondary "join with my
peer" process.

* In theory, if I set up two identical freeipa servers with the same
options (but different hostnames) I would like to be able to introduce
them to each other at a later date and join them (even if this means
that we pick one as the source of the data and the others data gets
overwritten)

Does this help explain the need? For an example of peering that works
this way and is symmetrical with configuration management, my
puppet-gluster module does this.

Cheers, and thanks for reading.
James



signature.asc
Description: This is a digitally signed message part
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Understanding FreeIPA replica internals

[James]

On Fri, 2014-05-23 at 09:28 -0400, Dmitri Pal wrote:
> I guess the question is more:
> If I am root is there any way to do the operation without providing
> the 
> password but rather using something like LDAPI to drive the operation.
> The issue is that if you use puppet there is no way to get the
> password 
> dynamically from some kind of source without baking it into the
> scripts.
> Baking passwords into scripts is bad so to avoid it there needs to be
> a 
> way for root to install replica without it. I am not sure it is 
> currently possible though.

This is correct... It makes sense to me that there could be some way to
do it without actually knowing the plain-text password as long as there
is an existing secure channel to the new host. More on this in another
mail...



signature.asc
Description: This is a digitally signed message part
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Understanding FreeIPA replica internals

[James]

On Fri, 2014-05-23 at 12:42 +0200, Martin Kosek wrote:
> On 05/23/2014 07:01 AM, James wrote:
> > I'm trying to understand some of the FreeIPA replication internals so
> > that I can better know how to do this properly in Puppet without
> > storing any secret information in Puppet, and so that automating
> > FreeIPA is awesome.
> > 
> > Please point me to any docs, if there is reading I could be doing :)
> > 
> > Here are some open questions I have:
> > 
> > 1) Is the GPG file created with ipa-replica-prepare using a symmetric
> > password and is that password equal to the dm_password ? If not, where
> > do the pub/priv key pairs come from and how do they get transferred to
> > the replica.
> 
> Yes. Grep for function expand_replica_info in FreeIPA git.
Found it, very helpful, thanks!

> 
> > 
> > 2) If I have root on the IPA server (actually all of them) how can I
> > run ipa-replica-prepare without needing interactive prompting for
> > entering the password. It's not possible with puppet. Is there another
> > (possibly less user friendly even) method to "prepare" the replica?
> > What is prepare actually doing?
> 
> For, you can for example use --password for passing the DM password.
Good to know, but I'd like to avoid knowing the password actually. More
in the other thread...

> 
> 
> > 3) With a multi master setup, what happens if I run the same action
> > (eg: user-mod or user-add or user-del) on more than one server.
> 
> I would not do that, you risk replication conflicts on entries or attributes.
> More here:
> 
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
If the exact same action is run on different servers at the same time,
will it still cause a replication conflict, or will it auto-resolve ?

> 
> > Can I
> > run it on any server?
> 
> Yes.
> 
> > What if I run different user-mod commands of the
> > same user on different masters. Is there split brain?
> 
> Then you get a replication conflict. I think in case of attributes, last
> modification wins.
> 
> > Are all the
> > transactions and writes synchronous across the whole cluster?
> 
> They are not synchronous, it takes some time for a change to replica to all
> masters.
> 
> > Please
> > point me to a doc that explains this FAQ stuff if possible. Sorry for
> > the noise
> 
> You should be able to get a reasonable starting information here:
> 
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Deployment_Guide/Designing_the_Replication_Process.html
> 
> or here:
> 
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication.html

This is good information, thanks. I will have to do my homework and come
back when I have more questions.

Thanks again,
James

> 
> HTH,
> Martin



signature.asc
Description: This is a digitally signed message part
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] User life cycle: question regarding the design

[Simo Sorce]

On Fri, 2014-05-23 at 17:47 +0200, thierry bordaz wrote:
> About membership. I think it could be risky to keep membership in 
> 'delete' or 'stage'. Those entries are not valid user and should not 
> belong to any active group. Should we keep membership attributes in 
> those state or let the plugin recompute the valid values when the
> entry 
> is back to active ?
> 
Recompute.
When a user is deleted it loses the memberships, when it is reactivated
then new memberships need to be computed or explicitly added.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] User life cycle: question regarding the design

[thierry bordaz]

On 05/23/2014 10:13 AM, Petr Viktorin wrote:

On 05/23/2014 08:33 AM, Martin Kosek wrote:

On 05/23/2014 07:48 AM, Jan Cholasta wrote:

On 22.5.2014 19:27, Simo Sorce wrote:

On Thu, 2014-05-22 at 15:35 +0200, Martin Kosek wrote:

On 05/21/2014 10:11 PM, Dmitri Pal wrote:

On 05/21/2014 03:06 PM, Martin Kosek wrote:

On 05/21/2014 08:14 PM, Simo Sorce wrote:

On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote:

Hello,

   Thanks for all these detailed descriptions.
   Just to be sure to be on the same page, here is my 
understanding of

   the provisioning templates and placeholder definitions. An
   administrator can provide a provisioning template. I 
suppose it
   would be a file containing a lines of placeholder 
definitions.


 * Where is located the template file ? Is there a 
standard

   repository where templates are put ? (somewhere under
/etc/ipa/* ?)


FreeIPA is a multi-master system, a file stored in a file would be
extremely cumbersome to use as it would require the admin to 
manually

copy it for every new replica and then keep it in sync.
It would also make it hard to change 'on-line'.

Placeholders should be defined in an object similar to
cn=ipaConfig,cn=etc,$suffix

 * Is there an already defined syntax for the 
provisionning
   template. ('$' is separator attr/value, %{} 
is substitute
   pattern...). If not, is it possible to user 
': ' as

   separator ?


Using initial and final ? like in Martin's example doesn't work ?

 * What is the priority. The user can provide the 
'homeDirectory'
   through different methods. Is it ok to use the 
following order:

 o the CLI option
 o the provisionning template
 o the default config value (in 
cn=ipaConfig,cn=etc,$SUFFIX)


   For example, if it exists the provisioning template:
   /etc/ipa/provisioning/shell-user.template

   roomnumber$-2
   homeDirectory$/home/net/shell-%{uid}
   loginShell$?shell-plugin-autogenerate?


I do not understand this, we are not building a templating 
engine here,

you only have 2 options:
1) a required (MUST) attribute has an explicit value
2) a require (MUST) attribute has a placeholder value

the placeholder value is fixed per type, and what it is 
substituted with
uses the same rules as the current code uses to autogenerate 
values.



   the command: ipa user-add tuser
   --homedir=/tmp/tuser--roomnumber=1234 --to-stage would 
create a

   staging entry:

   dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
   ...
   roomNumber: 1234
   homeDirectory: /tmp/tuser
   loginShell: shell-plugin-autogenerate


loginShell is a MAY attribute, not a MUST attribute, so nothing 
should
be stored at all in the staged entry unless explicitly provided 
for by

the admin.

   Then a private DS plugin (catching 
shell-plugin-autogenerate)
   generate the loginShell value when the entry becomes 
active.



   the command: ipa user-add tuser 
--homedir=/tmp/tuser--to-stage would

   create a staging entry:

   dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
   ...
   roomNumber: -2
   homeDirectory: /tmp/tuser
   loginShell: shell-plugin-autogenerate


roomNumber is also a MAY, so what would cause it to be set at 
-2, and

why ?

   the command: ipa user-add tuser --to-stage would create 
a staging

entry:

   dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
   ...
   roomNumber: -2
   homeDirectory: /home/net/shell-tuser
   loginShell: shell-plugin-autogenerate


homeDirectory should be something like: ?placeholder? IMO, we 
do not

really want to play templating here.

   In case the provisioning template does not define 
'homeDirectory',
   then the created entry would take the value from the 
ipa config

   definition:


that value should be taken and applied at the time the user is 
unstaged

and brought in the actual tree, not at the time a user is staged.

HTH,
Simo.



Hello Thierry and Simo,

I think Thierry was confused with this part of the design:

"
This format of placeholders gives enough space for future 
enhancements. For

example, Administrator could configure a new template
"myhomedirtemplate$/home/net/%{uid}" and use it in the staged 
LDAP entry.
Such value would be replaced by "/home/net/tuser if user uid 
attribute is set

to tuser
"

My intention when writing this design was to enable future use of
configurable placeholders, i.e. a value "?someplaceholder?" 
could be turn
into "/custom/path/%{uid}". But I meant that this can be 
considered as a
future enhancement. For now, I think implementing a placeholder 
"-1" for

numerical values and "?autogenerate?" for string ones a good start.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/

Re: [Freeipa-devel] Status/Question about User life cycle

[Simo Sorce]

On Fri, 2014-05-23 at 17:18 +0200, thierry bordaz wrote:
> On 05/23/2014 05:03 PM, Simo Sorce wrote:
> > On Fri, 2014-05-23 at 10:07 +0200, thierry bordaz wrote:
> >> On 05/22/2014 07:21 PM, Simo Sorce wrote:
> >>> On Thu, 2014-05-22 at 17:52 +0200, 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
> >> public.
> >>
> >> 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
> >>> started
> >>> 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.
> >>> 'uid'
> >>> 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:
> >> http://www.freeipa.org/page/V4/User_Life-Cycle_Management
> >>
> >>> 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
> >>> miss
> >>> something ?
> >>>
> >>> regards
> >>> thierry
> >> Hmm, no, I think you are right.  We can change 
> >> --from-stage to
> >> just
> >> Bool
> >> parameter. When it is true, it'd mean that get_dn or
> >> pre-callback
> >> should
> >> retrieve the record from stage and use all it's attributes 
> >> (and
> >> add
> >> standard
> >> 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
>  don't
>  support something like:
>  ipa user-add tuser --from-stage --phone=123456789
>  --email=newem...@example.com
>  If this is the case, what's the reason for using user-add for
>  this?
>  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
> > and
> > 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

Re: [Freeipa-devel] Status/Question about User life cycle

[thierry bordaz]

On 05/23/2014 05:03 PM, Simo Sorce wrote:

On Fri, 2014-05-23 at 10:07 +0200, thierry bordaz wrote:

On 05/22/2014 07:21 PM, Simo Sorce wrote:

On Thu, 2014-05-22 at 17:52 +0200, 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
public.

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
started
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.
'uid'
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:
http://www.freeipa.org/page/V4/User_Life-Cycle_Management


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
miss
something ?

regards
thierry

Hmm, no, I think you are right.  We can change --from-stage to
just
Bool
parameter. When it is true, it'd mean that get_dn or
pre-callback
should
retrieve the record from stage and use all it's attributes (and
add
standard
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
don't
support something like:
ipa user-add tuser --from-stage --phone=123456789
--email=newem...@example.com
If this is the case, what's the reason for using user-add for
this?
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
and
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.
But
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
containers.

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 
like:
   ipa user-stage tuser --first=abc --last=xyz --phone=123 ..
   ipa user-stage --deleted=tuser  # 
We should avoid this, if only for the reason that it makes the help text
confusing.


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)

Re: [Freeipa-devel] Status/Question about User life cycle

[Simo Sorce]

On Fri, 2014-05-23 at 10:07 +0200, thierry bordaz wrote:
> On 05/22/2014 07:21 PM, Simo Sorce wrote:
> > On Thu, 2014-05-22 at 17:52 +0200, 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
>  public.
> 
>  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
> > started
> >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.
> > 'uid'
> > 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:
>  http://www.freeipa.org/page/V4/User_Life-Cycle_Management
> 
> >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
> > miss
> >something ?
> >
> >regards
> >thierry
>  Hmm, no, I think you are right.  We can change --from-stage 
>  to
>  just
>  Bool
>  parameter. When it is true, it'd mean that get_dn or
>  pre-callback
>  should
>  retrieve the record from stage and use all it's attributes 
>  (and
>  add
>  standard
>  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
> >> don't
> >> support something like:
> >>ipa user-add tuser --from-stage --phone=123456789
> >> --email=newem...@example.com
> >> If this is the case, what's the reason for using user-add for
> >> this?
> >> 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
> >>> and
> >>> 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.
> >> But
> >> 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

Re: [Freeipa-devel] User life cycle: question regarding the design

[Simo Sorce]

On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote:
> This, I believe, has already been covered, but I'm concerned with the
> (over)use of active/inactive in this discussion.
> 
> I think use of "inactive" and "active" to describe users might be
> confusing since there is already an account enable/disable command.
> This
> on top of unlock, are there now 3 possible boolean states a user can
> be
> in? locked/unlocked, enabled/disabled, active/inactive, plus
> deleted/active and staged/active?
> 
Agree, we should only have "ipa user-unstage " and not call
this operations with words like active/inactive.

User's in the staging area are not inactive, they are *not* users yet in
the first place.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] User life cycle: question regarding the design

[Simo Sorce]

On Fri, 2014-05-23 at 08:33 +0200, Martin Kosek wrote:
> On 05/23/2014 07:48 AM, Jan Cholasta wrote:
> > On 22.5.2014 19:27, Simo Sorce wrote:
> >> On Thu, 2014-05-22 at 15:35 +0200, Martin Kosek wrote:
> >>> On 05/21/2014 10:11 PM, Dmitri Pal wrote:
>  On 05/21/2014 03:06 PM, Martin Kosek wrote:
> > On 05/21/2014 08:14 PM, Simo Sorce wrote:
> >> On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote:
> >>> Hello,
> >>>
> >>>   Thanks for all these detailed descriptions.
> >>>   Just to be sure to be on the same page, here is my 
> >>> understanding of
> >>>   the provisioning templates and placeholder definitions. An
> >>>   administrator can provide a provisioning template. I suppose it
> >>>   would be a file containing a lines of placeholder definitions.
> >>>
> >>> * Where is located the template file ? Is there a standard
> >>>   repository where templates are put ? (somewhere under
> >>> /etc/ipa/* ?)
> >>
> >> FreeIPA is a multi-master system, a file stored in a file would be
> >> extremely cumbersome to use as it would require the admin to manually
> >> copy it for every new replica and then keep it in sync.
> >> It would also make it hard to change 'on-line'.
> >>
> >> Placeholders should be defined in an object similar to
> >> cn=ipaConfig,cn=etc,$suffix
> >>
> >>> * Is there an already defined syntax for the provisionning
> >>>   template. ('$' is separator attr/value, %{} is 
> >>> substitute
> >>>   pattern...). If not, is it possible to user ': ' as
> >>>   separator ?
> >>
> >> Using initial and final ? like in Martin's example doesn't work ?
> >>
> >>> * What is the priority. The user can provide the 
> >>> 'homeDirectory'
> >>>   through different methods. Is it ok to use the following 
> >>> order:
> >>> o the CLI option
> >>> o the provisionning template
> >>> o the default config value (in 
> >>> cn=ipaConfig,cn=etc,$SUFFIX)
> >>>
> >>>   For example, if it exists the provisioning template:
> >>>   /etc/ipa/provisioning/shell-user.template
> >>>
> >>>   roomnumber$-2
> >>>   homeDirectory$/home/net/shell-%{uid}
> >>>   loginShell$?shell-plugin-autogenerate?
> >>
> >> I do not understand this, we are not building a templating engine here,
> >> you only have 2 options:
> >> 1) a required (MUST) attribute has an explicit value
> >> 2) a require (MUST) attribute has a placeholder value
> >>
> >> the placeholder value is fixed per type, and what it is substituted 
> >> with
> >> uses the same rules as the current code uses to autogenerate values.
> >>
> >>>   the command: ipa user-add tuser
> >>>   --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a
> >>>   staging entry:
> >>>
> >>>   dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
> >>>   ...
> >>>   roomNumber: 1234
> >>>   homeDirectory: /tmp/tuser
> >>>   loginShell: shell-plugin-autogenerate
> >>
> >> loginShell is a MAY attribute, not a MUST attribute, so nothing should
> >> be stored at all in the staged entry unless explicitly provided for by
> >> the admin.
> >>
> >>>   Then a private DS plugin (catching shell-plugin-autogenerate)
> >>>   generate the loginShell value when the entry becomes active.
> >>>
> >>>
> >>>   the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage 
> >>> would
> >>>   create a staging entry:
> >>>
> >>>   dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
> >>>   ...
> >>>   roomNumber: -2
> >>>   homeDirectory: /tmp/tuser
> >>>   loginShell: shell-plugin-autogenerate
> >>
> >> roomNumber is also a MAY, so what would cause it to be set at -2, and
> >> why ?
> >>
> >>>   the command: ipa user-add tuser --to-stage would create a 
> >>> staging
> >>> entry:
> >>>
> >>>   dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
> >>>   ...
> >>>   roomNumber: -2
> >>>   homeDirectory: /home/net/shell-tuser
> >>>   loginShell: shell-plugin-autogenerate
> >>
> >> homeDirectory should be something like: ?placeholder? IMO, we do not
> >> really want to play templating here.
> >>
> >>>   In case the provisioning template does not define 
> >>> 'homeDirectory',
> >>>   then the created entry would take the value from the ipa config
> >>>   definition:
> >>
> >> that value should be taken and applied at the time the user is unstaged
> >> and brought in the actual tree, not at the time a user is staged.
> >>
> >>

Re: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user

[Simo Sorce]

On Fri, 2014-05-23 at 10:59 +0200, Martin Kosek wrote:
> On 05/22/2014 04:20 PM, Petr Viktorin wrote:
> > On 05/21/2014 12:14 PM, Simo Sorce wrote:
> >> On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote:
> >>> On 05/16/2014 04:33 PM, Petr Viktorin wrote:
>  On 05/16/2014 01:54 PM, Martin Kosek wrote:
> > On 04/29/2014 11:00 PM, Petr Viktorin wrote:
> >> Patch 0540 adds a bunch of managed read ACIs for user, as discussed
> >> previously
> >> [0].
> >>
> >> Patch 0541 is some minor refactoring for the next part.
> >>
> >> Patch 0542 sets the read acces to addressbook attributes to anonymous 
> >> when
> >> upgrading from pre-4.0.
> >> I first this by checking if the update is run from ipa-server-install 
> >> or
> >> not,
> >> but then I realized the logic I want is simple: if the global anon 
> >> read ACI
> >> exists, we want to preserve its spirit by setting addressbook attribute
> >> ACI to
> >> anonymous.
> >>
> >>
> >> [0] 
> >> http://www.redhat.com/archives/freeipa-devel/2014-April/msg00363.html 
> >> et
> >> al.
> >>
> >
> > 540:
> >
> > Looks good! The only attributes I am concerned about are special IPA
> > attributes:
> >
> > - ipauniqueid
> > - ipasshpubkey
> > - ipauserauthtype
> > - userclass
> >
> > I personally do not think they should be included in POSIX attributes
> > permissions, they are far from POSIX definition...
> >
> > What about creating one more permission "System: Read User IPA 
> > Attributes" as
> > these are specific to FreeIPA use and allowing that permission for all
> > authenticated users?
> 
>  Sounds reasonable. I assume we want this one to be also set to anonymous 
>  when
>  upgrading from old versions.
>  Attaching updated patches.
> >>>
> >>> Ok, looks good.
> >>>
> >>> I am now just pondering whether "System: Read User POSIX Attributes" is 
> >>> the
> >>> right name for the permission as there are not just POSIX attributes, but 
> >>> also
> >>> attributes from organizationalPerson or inetOrgPerson objectclasses.
> >>>
> >>> Maybe we should name it "System: Read User Core Attributes" or "System: 
> >>> Read
> >>> User Basic Attributes"? Simo, any preference?
> >>
> >> We could use: "System: Read User Standard Attributes"
> > 
> > I've used this one, then.
> > 
> >>
> >> but the 'posix' version is also ok to me.
> > 
> > On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote:
> >> Also, I just realized we forgot memberOf attribute - it needs to be 
> >> available
> >> to authenticated users otherwise group membership will fall apart.
> > 
> > Good catch. Added.
> > 
> 
> We are very close to push this one - I have just one last concern about
> userpkcs12 attribute. On upgrade, we previously hidden userpkcs12 from user,
> now we added it to be read by default. This results in this warning during 
> upgrade:
> 
> Excluded attributes for System: Read User Addressbook Attributes: userpkcs12
> 
> Simo (or others), is this OK or do we want to keep hiding userpkcs12 by 
> default?

Is there any client that needs access to that information that we are
aware of ?

Simo.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Is CA certificate storage correct?

[Martin Kosek]

On 05/20/2014 11:16 AM, Jan Cholasta wrote:
> On 20.5.2014 08:28, Martin Kosek wrote:
>> Hi there,
>>
>> I checked the update CA Certificate renewal feature design page and one part
>> seemed awkward to me:
>>
>> http://www.freeipa.org/page/V4/CA_certificate_renewal#Shared_certificate_store
>>
>> IIUC, when there are multiple iterations of a certificate stored, there will 
>> be
>> one LDAP object with multiple cACertificate attributes, multiple ipaKeyUsage
>> attributes, ipaKeyTrust, ...
>>
>> Given that LDAP does not guarantee order, how do I identify which 
>> cACertificate
>> belongs to which attribute?
> 
> There is no such relation, ipaKey* attributes apply to all of the 
> cACertificate
> attributes.
> 
>>
>> If I do ldapsearch for some specific ipaKeyUsage and I get this LDAP record
>> returned, how do I find out which certificate it is? Do I need to go through
>> all binary blobs, parse them and look which blob matches?
> 
> No.

Could you then please state some example in

http://www.freeipa.org/page/V4/CA_certificate_renewal#Shared_certificate_store

with more than one cACertificate;binary? I think it would greatly help
understand the relation of the new schema attributes and cACertificate. As you
can see, it may be pretty confusing.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] User life cycle: question regarding the design

[Rob Crittenden]

Martin Kosek wrote:
> On 05/23/2014 07:48 AM, Jan Cholasta wrote:
>> On 22.5.2014 19:27, Simo Sorce wrote:
>>> On Thu, 2014-05-22 at 15:35 +0200, Martin Kosek wrote:
 On 05/21/2014 10:11 PM, Dmitri Pal wrote:
> On 05/21/2014 03:06 PM, Martin Kosek wrote:
>> On 05/21/2014 08:14 PM, Simo Sorce wrote:
>>> On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote:
 Hello,

   Thanks for all these detailed descriptions.
   Just to be sure to be on the same page, here is my understanding 
 of
   the provisioning templates and placeholder definitions. An
   administrator can provide a provisioning template. I suppose it
   would be a file containing a lines of placeholder definitions.

 * Where is located the template file ? Is there a standard
   repository where templates are put ? (somewhere under
 /etc/ipa/* ?)
>>>
>>> FreeIPA is a multi-master system, a file stored in a file would be
>>> extremely cumbersome to use as it would require the admin to manually
>>> copy it for every new replica and then keep it in sync.
>>> It would also make it hard to change 'on-line'.
>>>
>>> Placeholders should be defined in an object similar to
>>> cn=ipaConfig,cn=etc,$suffix
>>>
 * Is there an already defined syntax for the provisionning
   template. ('$' is separator attr/value, %{} is 
 substitute
   pattern...). If not, is it possible to user ': ' as
   separator ?
>>>
>>> Using initial and final ? like in Martin's example doesn't work ?
>>>
 * What is the priority. The user can provide the 
 'homeDirectory'
   through different methods. Is it ok to use the following 
 order:
 o the CLI option
 o the provisionning template
 o the default config value (in cn=ipaConfig,cn=etc,$SUFFIX)

   For example, if it exists the provisioning template:
   /etc/ipa/provisioning/shell-user.template

   roomnumber$-2
   homeDirectory$/home/net/shell-%{uid}
   loginShell$?shell-plugin-autogenerate?
>>>
>>> I do not understand this, we are not building a templating engine here,
>>> you only have 2 options:
>>> 1) a required (MUST) attribute has an explicit value
>>> 2) a require (MUST) attribute has a placeholder value
>>>
>>> the placeholder value is fixed per type, and what it is substituted with
>>> uses the same rules as the current code uses to autogenerate values.
>>>
   the command: ipa user-add tuser
   --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a
   staging entry:

   dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
   ...
   roomNumber: 1234
   homeDirectory: /tmp/tuser
   loginShell: shell-plugin-autogenerate
>>>
>>> loginShell is a MAY attribute, not a MUST attribute, so nothing should
>>> be stored at all in the staged entry unless explicitly provided for by
>>> the admin.
>>>
   Then a private DS plugin (catching shell-plugin-autogenerate)
   generate the loginShell value when the entry becomes active.


   the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage 
 would
   create a staging entry:

   dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
   ...
   roomNumber: -2
   homeDirectory: /tmp/tuser
   loginShell: shell-plugin-autogenerate
>>>
>>> roomNumber is also a MAY, so what would cause it to be set at -2, and
>>> why ?
>>>
   the command: ipa user-add tuser --to-stage would create a staging
 entry:

   dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
   ...
   roomNumber: -2
   homeDirectory: /home/net/shell-tuser
   loginShell: shell-plugin-autogenerate
>>>
>>> homeDirectory should be something like: ?placeholder? IMO, we do not
>>> really want to play templating here.
>>>
   In case the provisioning template does not define 
 'homeDirectory',
   then the created entry would take the value from the ipa config
   definition:
>>>
>>> that value should be taken and applied at the time the user is unstaged
>>> and brought in the actual tree, not at the time a user is staged.
>>>
>>> HTH,
>>> Simo.
>>>
>>
>> Hello Thierry and Simo,
>>
>> I think Thierry was confused with this part of the design:
>>
>> "
>> This format

Re: [Freeipa-devel] Understanding FreeIPA replica internals

[Rob Crittenden]

Dmitri Pal wrote:
> On 05/23/2014 06:42 AM, Martin Kosek wrote:
>> On 05/23/2014 07:01 AM, James wrote:
>>> I'm trying to understand some of the FreeIPA replication internals so
>>> that I can better know how to do this properly in Puppet without
>>> storing any secret information in Puppet, and so that automating
>>> FreeIPA is awesome.
>>>
>>> Please point me to any docs, if there is reading I could be doing :)
>>>
>>> Here are some open questions I have:
>>>
>>> 1) Is the GPG file created with ipa-replica-prepare using a symmetric
>>> password and is that password equal to the dm_password ? If not, where
>>> do the pub/priv key pairs come from and how do they get transferred to
>>> the replica.
>> Yes. Grep for function expand_replica_info in FreeIPA git.
>>
>>> 2) If I have root on the IPA server (actually all of them) how can I
>>> run ipa-replica-prepare without needing interactive prompting for
>>> entering the password. It's not possible with puppet. Is there another
>>> (possibly less user friendly even) method to "prepare" the replica?
>>> What is prepare actually doing?
>> For, you can for example use --password for passing the DM password.
> 
> I guess the question is more:
> If I am root is there any way to do the operation without providing the
> password but rather using something like LDAPI to drive the operation.
> The issue is that if you use puppet there is no way to get the password
> dynamically from some kind of source without baking it into the scripts.
> Baking passwords into scripts is bad so to avoid it there needs to be a
> way for root to install replica without it. I am not sure it is
> currently possible though.

No, there is nothing special root can do. There is no server yet that
root could do anything with.

We still need the DM password to do a lot of installation, so either you
bake that into the replica file or it is provided at install time. There
are good and bad points to both.

rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Understanding FreeIPA replica internals

[Martin Kosek]

On 05/23/2014 03:28 PM, Dmitri Pal wrote:
> On 05/23/2014 06:42 AM, Martin Kosek wrote:
>> On 05/23/2014 07:01 AM, James wrote:
>>> I'm trying to understand some of the FreeIPA replication internals so
>>> that I can better know how to do this properly in Puppet without
>>> storing any secret information in Puppet, and so that automating
>>> FreeIPA is awesome.
>>>
>>> Please point me to any docs, if there is reading I could be doing :)
>>>
>>> Here are some open questions I have:
>>>
>>> 1) Is the GPG file created with ipa-replica-prepare using a symmetric
>>> password and is that password equal to the dm_password ? If not, where
>>> do the pub/priv key pairs come from and how do they get transferred to
>>> the replica.
>> Yes. Grep for function expand_replica_info in FreeIPA git.
>>
>>> 2) If I have root on the IPA server (actually all of them) how can I
>>> run ipa-replica-prepare without needing interactive prompting for
>>> entering the password. It's not possible with puppet. Is there another
>>> (possibly less user friendly even) method to "prepare" the replica?
>>> What is prepare actually doing?
>> For, you can for example use --password for passing the DM password.
> 
> I guess the question is more:
> If I am root is there any way to do the operation without providing the
> password but rather using something like LDAPI to drive the operation.
> The issue is that if you use puppet there is no way to get the password
> dynamically from some kind of source without baking it into the scripts.
> Baking passwords into scripts is bad so to avoid it there needs to be a way 
> for
> root to install replica without it. I am not sure it is currently possible 
> though.

One cannot easily improve ipa-replica-prepare to work through LDAPI as we also
need to encypher the replica info package - and we cannot do that without clear
text DM password.

The right way seems to be rather the RFE you filed:
https://fedorahosted.org/freeipa/ticket/2888

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Understanding FreeIPA replica internals

[Dmitri Pal]

On 05/23/2014 06:42 AM, Martin Kosek wrote:

On 05/23/2014 07:01 AM, James wrote:

I'm trying to understand some of the FreeIPA replication internals so
that I can better know how to do this properly in Puppet without
storing any secret information in Puppet, and so that automating
FreeIPA is awesome.

Please point me to any docs, if there is reading I could be doing :)

Here are some open questions I have:

1) Is the GPG file created with ipa-replica-prepare using a symmetric
password and is that password equal to the dm_password ? If not, where
do the pub/priv key pairs come from and how do they get transferred to
the replica.

Yes. Grep for function expand_replica_info in FreeIPA git.


2) If I have root on the IPA server (actually all of them) how can I
run ipa-replica-prepare without needing interactive prompting for
entering the password. It's not possible with puppet. Is there another
(possibly less user friendly even) method to "prepare" the replica?
What is prepare actually doing?

For, you can for example use --password for passing the DM password.


I guess the question is more:
If I am root is there any way to do the operation without providing the 
password but rather using something like LDAPI to drive the operation.
The issue is that if you use puppet there is no way to get the password 
dynamically from some kind of source without baking it into the scripts.
Baking passwords into scripts is bad so to avoid it there needs to be a 
way for root to install replica without it. I am not sure it is 
currently possible though.






3) With a multi master setup, what happens if I run the same action
(eg: user-mod or user-add or user-del) on more than one server.

I would not do that, you risk replication conflicts on entries or attributes.
More here:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html


Can I
run it on any server?

Yes.


What if I run different user-mod commands of the
same user on different masters. Is there split brain?

Then you get a replication conflict. I think in case of attributes, last
modification wins.


Are all the
transactions and writes synchronous across the whole cluster?

They are not synchronous, it takes some time for a change to replica to all
masters.


Please
point me to a doc that explains this FAQ stuff if possible. Sorry for
the noise

You should be able to get a reasonable starting information here:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Deployment_Guide/Designing_the_Replication_Process.html

or here:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication.html

HTH,
Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel



--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0544 Remove the global anonymous read ACI

[Martin Kosek]

On 05/22/2014 04:03 PM, Petr Viktorin wrote:
> On 05/21/2014 08:08 AM, Martin Kosek wrote:
>> On 05/19/2014 03:27 PM, Petr Viktorin wrote:
>>> On 05/16/2014 02:00 PM, Martin Kosek wrote:
 On 04/29/2014 11:02 PM, Petr Viktorin wrote:
> I didn't test this as much as I'd like to, but it might come in handy when
> testing my earlier patches.
>
> The ACI is removed in the managed permissions plugin because I want to 
> make
> sure it's done after all the managed permission updates, which query it.

 It worked in my case (I tested upgrade from 3.3.5). What do we do about 
 other
 permissions we will want to remove? I am talking about following ACIs:

 - no anonymous access to roles
 - no anonymous access to sudo
 - no anonymous access to hbac
 - no anonymous access to member information

 I would like to remove them in 544 as well as otherwise they would bias the
 testing.
>>>
>>> Right. Here is the updated patch.
>>
>> I tested upgrade from 3.3.5 to 4.0 and in SUFFIX I still had some of the ACIs
>> left:
>>
>> (targetattr = "*")(target =
>> "ldap:///cn=*,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test";)(version 3.0;
>> acl "No anonymous access to roles"; deny (read,search,compare) userdn !=
>> "ldap:///all";;)
>>
>> (targetattr = "*")(target =
>> "ldap:///cn=*,ou=SUDOers,dc=mkosek-fedora20,dc=test";)(version 3.0; acl "No
>> anonymous access to sudo"; deny (read,search,compare) userdn != 
>> "ldap:///all";;)
>>
>> The problem is that you used your testing suffix instead of suffix variable.
> 
> Shame on me. I've updated & rebased the patch.
> 
> I've also made a git hook yell at me when I commit something containing "BRQ",
> hopefully this won't happen again.

Would it make sense to publish your FreeIPA git hooks somewhere on
http://www.freeipa.org/page/Contribute/Code or your github and link it? I think
it already contains couple gems that may help other people prevent basic errors
like this one.

Otherwise, the patch worked fine - ACK!

I would like it to be pushed as soon as user ACI patch is pushed so that we
have some time to find issues.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Understanding FreeIPA replica internals

[Martin Kosek]

On 05/23/2014 07:01 AM, James wrote:
> I'm trying to understand some of the FreeIPA replication internals so
> that I can better know how to do this properly in Puppet without
> storing any secret information in Puppet, and so that automating
> FreeIPA is awesome.
> 
> Please point me to any docs, if there is reading I could be doing :)
> 
> Here are some open questions I have:
> 
> 1) Is the GPG file created with ipa-replica-prepare using a symmetric
> password and is that password equal to the dm_password ? If not, where
> do the pub/priv key pairs come from and how do they get transferred to
> the replica.

Yes. Grep for function expand_replica_info in FreeIPA git.

> 
> 2) If I have root on the IPA server (actually all of them) how can I
> run ipa-replica-prepare without needing interactive prompting for
> entering the password. It's not possible with puppet. Is there another
> (possibly less user friendly even) method to "prepare" the replica?
> What is prepare actually doing?

For, you can for example use --password for passing the DM password.


> 3) With a multi master setup, what happens if I run the same action
> (eg: user-mod or user-add or user-del) on more than one server.

I would not do that, you risk replication conflicts on entries or attributes.
More here:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html

> Can I
> run it on any server?

Yes.

> What if I run different user-mod commands of the
> same user on different masters. Is there split brain?

Then you get a replication conflict. I think in case of attributes, last
modification wins.

> Are all the
> transactions and writes synchronous across the whole cluster?

They are not synchronous, it takes some time for a change to replica to all
masters.

> Please
> point me to a doc that explains this FAQ stuff if possible. Sorry for
> the noise

You should be able to get a reasonable starting information here:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Deployment_Guide/Designing_the_Replication_Process.html

or here:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication.html

HTH,
Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Status/Question about User life cycle

[thierry bordaz]

On 05/23/2014 10:55 AM, Martin Kosek wrote:

On 05/23/2014 10:22 AM, thierry bordaz wrote:

On 05/23/2014 10:04 AM, Martin Kosek wrote:

On 05/23/2014 09:34 AM, thierry bordaz wrote:

...

  3) inactivate the user

  (active to inactive)  ipa user-inactivate# (after the command
  ipaUniqueID=)

  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.

Right.

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...

We do not need to care about what approval is in a particular deployment, what
we need to care about is how to give privileges to someone to do the activation
(ipa user-activate). This should be solved via standard permission/ACI to
MODRDN from staging area to active users area (the MODRDN ACI you did) that can
be assigned to group of privileged operators.


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

Right.


For example, the user attribute should be:

 Staging Active Disabled
ipaUniqueID: generate   ipaUniqueID: abc-def-ghi-jkl ipaUniqueID:
abc-def-ghi-jkl
uidNumber: -1   uidNumber: 1234uidNumber: 1234
gidNumber: -1   gidNumber: 1234gidNumber: 1234
 attribute memberof: *  :
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.

It is true that the entries will be similar from attributes and values POV.
However, they will be different in a meaning. Staging area may contain dozen
recently provisioned users *planned* to be activated after the approval is
made, while the deleted users container may contain hundreds or thousands of
users deleted long time ago.

But from LDAP behavior POV, the users will be similar - you cannot BIND to
them, you cannot kinit with them.

Martin

ok thanks for the clarifications :-)
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user

[Martin Kosek]

On 05/22/2014 04:20 PM, Petr Viktorin wrote:
> On 05/21/2014 12:14 PM, Simo Sorce wrote:
>> On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote:
>>> On 05/16/2014 04:33 PM, Petr Viktorin wrote:
 On 05/16/2014 01:54 PM, Martin Kosek wrote:
> On 04/29/2014 11:00 PM, Petr Viktorin wrote:
>> Patch 0540 adds a bunch of managed read ACIs for user, as discussed
>> previously
>> [0].
>>
>> Patch 0541 is some minor refactoring for the next part.
>>
>> Patch 0542 sets the read acces to addressbook attributes to anonymous 
>> when
>> upgrading from pre-4.0.
>> I first this by checking if the update is run from ipa-server-install or
>> not,
>> but then I realized the logic I want is simple: if the global anon read 
>> ACI
>> exists, we want to preserve its spirit by setting addressbook attribute
>> ACI to
>> anonymous.
>>
>>
>> [0] 
>> http://www.redhat.com/archives/freeipa-devel/2014-April/msg00363.html et
>> al.
>>
>
> 540:
>
> Looks good! The only attributes I am concerned about are special IPA
> attributes:
>
> - ipauniqueid
> - ipasshpubkey
> - ipauserauthtype
> - userclass
>
> I personally do not think they should be included in POSIX attributes
> permissions, they are far from POSIX definition...
>
> What about creating one more permission "System: Read User IPA 
> Attributes" as
> these are specific to FreeIPA use and allowing that permission for all
> authenticated users?

 Sounds reasonable. I assume we want this one to be also set to anonymous 
 when
 upgrading from old versions.
 Attaching updated patches.
>>>
>>> Ok, looks good.
>>>
>>> I am now just pondering whether "System: Read User POSIX Attributes" is the
>>> right name for the permission as there are not just POSIX attributes, but 
>>> also
>>> attributes from organizationalPerson or inetOrgPerson objectclasses.
>>>
>>> Maybe we should name it "System: Read User Core Attributes" or "System: Read
>>> User Basic Attributes"? Simo, any preference?
>>
>> We could use: "System: Read User Standard Attributes"
> 
> I've used this one, then.
> 
>>
>> but the 'posix' version is also ok to me.
> 
> On Wed, 2014-05-21 at 08:03 +0200, Martin Kosek wrote:
>> Also, I just realized we forgot memberOf attribute - it needs to be available
>> to authenticated users otherwise group membership will fall apart.
> 
> Good catch. Added.
> 

We are very close to push this one - I have just one last concern about
userpkcs12 attribute. On upgrade, we previously hidden userpkcs12 from user,
now we added it to be read by default. This results in this warning during 
upgrade:

Excluded attributes for System: Read User Addressbook Attributes: userpkcs12

Simo (or others), is this OK or do we want to keep hiding userpkcs12 by default?

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Status/Question about User life cycle

[Martin Kosek]

On 05/23/2014 10:22 AM, thierry bordaz wrote:
> On 05/23/2014 10:04 AM, Martin Kosek wrote:
>> On 05/23/2014 09:34 AM, thierry bordaz wrote:
...
>  3) inactivate the user
>
>  (active to inactive)  ipa user-inactivate# (after the command
>  ipaUniqueID=)
>
>  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.
>> Right.
> 
> 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...

We do not need to care about what approval is in a particular deployment, what
we need to care about is how to give privileges to someone to do the activation
(ipa user-activate). This should be solved via standard permission/ACI to
MODRDN from staging area to active users area (the MODRDN ACI you did) that can
be assigned to group of privileged operators.

>>
>>> Before the approval, the ipaUniqueID is 'generate'
>>> and after it is a valid account.
>> Right.
>>
>>> For example, the user attribute should be:
>>>
>>> Staging Active Disabled
>>> ipaUniqueID: generate   ipaUniqueID: abc-def-ghi-jkl ipaUniqueID:
>>> abc-def-ghi-jkl
>>> uidNumber: -1   uidNumber: 1234uidNumber: 1234
>>> gidNumber: -1   gidNumber: 1234gidNumber: 1234
>>>  attribute memberof: *  >> memberof>:
>>> 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.

It is true that the entries will be similar from attributes and values POV.
However, they will be different in a meaning. Staging area may contain dozen
recently provisioned users *planned* to be activated after the approval is
made, while the deleted users container may contain hundreds or thousands of
users deleted long time ago.

But from LDAP behavior POV, the users will be similar - you cannot BIND to
them, you cannot kinit with them.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0048] Default the token owner to the person adding the token

[Alexander Bokovoy]

On Fri, 23 May 2014, Jan Cholasta wrote:

On 22.5.2014 16:21, Nathaniel McCallum wrote:

I still need a review on this.

On Wed, 2014-05-07 at 10:06 -0400, Nathaniel McCallum wrote:

On Wed, 2014-05-07 at 15:54 +0200, Petr Vobornik wrote:

On 6.5.2014 17:07, Nathaniel McCallum wrote:

On Tue, 2014-05-06 at 16:11 +0200, Jan Cholasta wrote:

On 6.5.2014 15:16, Nathaniel McCallum wrote:

On Tue, 2014-05-06 at 13:46 +0200, Jan Cholasta wrote:

Hi,

On 5.5.2014 18:40, Nathaniel McCallum wrote:

Creating tokens for yourself is the most common operation. Making this
the default optimizes for the common case.


The user-find call should be inside the if statement.


This is actually for a reason. See my patch 0049 for further context.


IMO something like this would be better:

  if 'ipatokenowner' not in entry_attrs or 'ipatokenprotected' not in
entry_attrs:
  result = self.api.Command.user_find(whoami=True)['result']
  if result:
  cur_uid = result[0]['uid'][0]
  prev_uid = entry_attrs.setdefault('ipatokenowner', cur_uid)
  if cur_uid != prev_uid:
  entry_attrs.setdefault('ipatokenprotected', True)


Fixed (see also my new revision of patch 0049).

Nathaniel



I assume that this won't allow to create a token without an owner. Do we
want to have this restriction?

Usecase: import a batch of hw tokens


This case is currently very much on my radar (I'm finishing the import
script now). To set no owner, just use --owner="". We are testing for
key presence here, not the value of the key. So if the key is present
with an empty value, no owner will be set.

FYI, the import format (RFC 6030) also permits a mechanism for declaring
ownership in DN format.

Nathaniel

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel



ACK.


Pushed to master
* db7d0219bac72daa270ee28d5db5c18ea41fb8b1 Default the token owner to the 
person adding the token


--
/ Alexander Bokovoy

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] User life cycle: question regarding the design

[Jan Cholasta]

On 23.5.2014 10:13, Petr Viktorin wrote:

On 05/23/2014 08:33 AM, Martin Kosek wrote:

On 05/23/2014 07:48 AM, Jan Cholasta wrote:

On 22.5.2014 19:27, Simo Sorce wrote:

On Thu, 2014-05-22 at 15:35 +0200, Martin Kosek wrote:

On 05/21/2014 10:11 PM, Dmitri Pal wrote:

On 05/21/2014 03:06 PM, Martin Kosek wrote:

On 05/21/2014 08:14 PM, Simo Sorce wrote:

On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote:

Hello,

   Thanks for all these detailed descriptions.
   Just to be sure to be on the same page, here is my
understanding of
   the provisioning templates and placeholder definitions. An
   administrator can provide a provisioning template. I
suppose it
   would be a file containing a lines of placeholder
definitions.

 * Where is located the template file ? Is there a
standard
   repository where templates are put ? (somewhere under
/etc/ipa/* ?)


FreeIPA is a multi-master system, a file stored in a file would be
extremely cumbersome to use as it would require the admin to
manually
copy it for every new replica and then keep it in sync.
It would also make it hard to change 'on-line'.

Placeholders should be defined in an object similar to
cn=ipaConfig,cn=etc,$suffix


 * Is there an already defined syntax for the
provisionning
   template. ('$' is separator attr/value, %{} is
substitute
   pattern...). If not, is it possible to user
': ' as
   separator ?


Using initial and final ? like in Martin's example doesn't work ?


 * What is the priority. The user can provide the
'homeDirectory'
   through different methods. Is it ok to use the
following order:
 o the CLI option
 o the provisionning template
 o the default config value (in
cn=ipaConfig,cn=etc,$SUFFIX)

   For example, if it exists the provisioning template:
   /etc/ipa/provisioning/shell-user.template

   roomnumber$-2
   homeDirectory$/home/net/shell-%{uid}
   loginShell$?shell-plugin-autogenerate?


I do not understand this, we are not building a templating
engine here,
you only have 2 options:
1) a required (MUST) attribute has an explicit value
2) a require (MUST) attribute has a placeholder value

the placeholder value is fixed per type, and what it is
substituted with
uses the same rules as the current code uses to autogenerate
values.


   the command: ipa user-add tuser
   --homedir=/tmp/tuser--roomnumber=1234 --to-stage would
create a
   staging entry:

   dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
   ...
   roomNumber: 1234
   homeDirectory: /tmp/tuser
   loginShell: shell-plugin-autogenerate


loginShell is a MAY attribute, not a MUST attribute, so nothing
should
be stored at all in the staged entry unless explicitly provided
for by
the admin.


   Then a private DS plugin (catching
shell-plugin-autogenerate)
   generate the loginShell value when the entry becomes
active.


   the command: ipa user-add tuser
--homedir=/tmp/tuser--to-stage would
   create a staging entry:

   dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
   ...
   roomNumber: -2
   homeDirectory: /tmp/tuser
   loginShell: shell-plugin-autogenerate


roomNumber is also a MAY, so what would cause it to be set at
-2, and
why ?


   the command: ipa user-add tuser --to-stage would create
a staging
entry:

   dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
   ...
   roomNumber: -2
   homeDirectory: /home/net/shell-tuser
   loginShell: shell-plugin-autogenerate


homeDirectory should be something like: ?placeholder? IMO, we do
not
really want to play templating here.


   In case the provisioning template does not define
'homeDirectory',
   then the created entry would take the value from the ipa
config
   definition:


that value should be taken and applied at the time the user is
unstaged
and brought in the actual tree, not at the time a user is staged.

HTH,
Simo.



Hello Thierry and Simo,

I think Thierry was confused with this part of the design:

"
This format of placeholders gives enough space for future
enhancements. For
example, Administrator could configure a new template
"myhomedirtemplate$/home/net/%{uid}" and use it in the staged
LDAP entry.
Such value would be replaced by "/home/net/tuser if user uid
attribute is set
to tuser
"

My intention when writing this design was to enable future use of
configurable placeholders, i.e. a value "?someplaceholder?" could
be turn
into "/custom/path/%{uid}". But I meant that this can be
considered as a
future enhancement. For now, I think implementing a placeholder
"-1" for
numerical values and "?autogenerate?" for string ones a good start.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel



Please consider the flow: user adde

Re: [Freeipa-devel] [PATCH 0052] Only specify the ipatokenuniqueid default in the add operation

[Alexander Bokovoy]

On Thu, 22 May 2014, Petr Viktorin wrote:

On 05/22/2014 05:13 PM, Petr Vobornik wrote:

On 22.5.2014 17:00, Nathaniel McCallum wrote:

On Thu, 2014-05-22 at 10:53 -0400, Nathaniel McCallum wrote:

On Thu, 2014-05-22 at 16:45 +0200, Petr Viktorin wrote:

On 05/22/2014 04:12 PM, Nathaniel McCallum wrote:

On Tue, 2014-05-13 at 12:55 -0400, Nathaniel McCallum wrote:

On Tue, 2014-05-13 at 16:47 +0200, Jan Cholasta wrote:

On 12.5.2014 20:50, Nathaniel McCallum wrote:

On Mon, 2014-05-12 at 18:40 +0200, Misnyovszki Adam wrote:

On Tue, 06 May 2014 11:46:14 -0400
Nathaniel McCallum  wrote:


On Tue, 2014-05-06 at 11:38 -0400, Nathaniel McCallum wrote:

On Tue, 2014-05-06 at 17:34 +0200, Petr Vobornik wrote:

On 6.5.2014 17:13, Nathaniel McCallum wrote:

On Tue, 2014-05-06 at 17:04 +0200, Petr Vobornik wrote:

On 6.5.2014 16:51, Nathaniel McCallum wrote:

Specifying the default in the LDAP Object causes the
parameter to be specified for non-add operations. This is
especially problematic when performing the modify operation
as it causes the primary key to change for every
modification.

https://fedorahosted.org/freeipa/ticket/4227



shouldn't removal of `autofill=True,` be enough?


Removing autofill=True results in the default not being used
for the otptoken-add operation. That may be a different bug
(I'm not sure what the expectation of autofill is).

Nathaniel



Seems to work form me with:

diff --git a/ipalib/plugins/otptoken.py
b/ipalib/plugins/otptoken.py index f68ea7d..623f1f1 100644
--- a/ipalib/plugins/otptoken.py
+++ b/ipalib/plugins/otptoken.py
@@ -121,9 +121,7 @@ class otptoken(LDAPObject):
cli_name='id',
label=_('Unique ID'),
default_from=lambda: unicode(uuid.uuid4()),
-autofill=True,
primary_key=True,
-flags=('optional_create'),
),
StrEnum('type?',
label=_('Type'),


Doing this causes the ipa otptoken-add command to prompt for the
Unique ID. This may be the desired behavior, but it is not
how it
worked previously (no prompt).


Here is an alternate patch for this second approach. I have no
strong
opinion on the correct behavior here.

Nathaniel


IMO you should update API.txt with ./makeapi


Running ./makeapi results in no changes to API.txt.


This is not right, there *are* changes in the API and build fails
for me
becase API.txt is not updated.


I think maybe I ran it from the wrong branch. Fixed.


I still need a review of this. It is pretty trivial.

Nathaniel


This still prompts for the unique ID on add:

$ ipa otptoken-add
Unique ID [25cb3aa9-db19-40f8-acf4-33ef65ca863c]:

I don't think that's the intended behavior.


Hence the alternate patch (0052a). If we don't want to prompt, we'll
need to use the first patch (0052). I have no strong opinion on the
correct behavior and I am fine with merging either patch.


Attached is the non-alternate (0052) with the api updated.

Nathaniel


IMO 52a is better if used by hand and it keeps code cleaner.


I don't think that should influence the design of the CLI that much.


It might
not be ideal though if used from a script because of nonexistent
--unattended/-u option which would disable prompt (set
env.interactive=False ?).


Right.


ACK to the non-prompting version (0052.1).


Pushed to master
* 3f26ff8c37ef3f8a484220f8e514bb2691905d47 Only specify the ipatokenuniqueid 
default in the add operation

--
/ Alexander Bokovoy

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Status/Question about User life cycle

[thierry bordaz]

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
public.

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
started
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.
'uid'
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:
http://www.freeipa.org/page/V4/User_Life-Cycle_Management


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
miss
something ?

regards
thierry

Hmm, no, I think you are right.  We can change --from-stage to
just
Bool
parameter. When it is true, it'd mean that get_dn or
pre-callback
should
retrieve the record from stage and use all it's attributes (and
add
standard
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
don't
support something like:
ipa user-add tuser --from-stage --phone=123456789
--email=newem...@example.com
If this is the case, what's the reason for using user-add for
this?
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
and
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.
But
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
containers.

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
like:
   ipa user-stage tuser --first=abc --last=xyz --phone=123 ..
   ipa user-stage --deleted=tuser  # 
We should avoid this, if only for the reason that it makes the help text
confusing.


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 tus

Re: [Freeipa-devel] User life cycle: question regarding the design

[Petr Viktorin]

On 05/23/2014 08:33 AM, Martin Kosek wrote:

On 05/23/2014 07:48 AM, Jan Cholasta wrote:

On 22.5.2014 19:27, Simo Sorce wrote:

On Thu, 2014-05-22 at 15:35 +0200, Martin Kosek wrote:

On 05/21/2014 10:11 PM, Dmitri Pal wrote:

On 05/21/2014 03:06 PM, Martin Kosek wrote:

On 05/21/2014 08:14 PM, Simo Sorce wrote:

On Wed, 2014-05-21 at 16:01 +0200, thierry bordaz wrote:

Hello,

   Thanks for all these detailed descriptions.
   Just to be sure to be on the same page, here is my understanding of
   the provisioning templates and placeholder definitions. An
   administrator can provide a provisioning template. I suppose it
   would be a file containing a lines of placeholder definitions.

 * Where is located the template file ? Is there a standard
   repository where templates are put ? (somewhere under
/etc/ipa/* ?)


FreeIPA is a multi-master system, a file stored in a file would be
extremely cumbersome to use as it would require the admin to manually
copy it for every new replica and then keep it in sync.
It would also make it hard to change 'on-line'.

Placeholders should be defined in an object similar to
cn=ipaConfig,cn=etc,$suffix


 * Is there an already defined syntax for the provisionning
   template. ('$' is separator attr/value, %{} is substitute
   pattern...). If not, is it possible to user ': ' as
   separator ?


Using initial and final ? like in Martin's example doesn't work ?


 * What is the priority. The user can provide the 'homeDirectory'
   through different methods. Is it ok to use the following order:
 o the CLI option
 o the provisionning template
 o the default config value (in cn=ipaConfig,cn=etc,$SUFFIX)

   For example, if it exists the provisioning template:
   /etc/ipa/provisioning/shell-user.template

   roomnumber$-2
   homeDirectory$/home/net/shell-%{uid}
   loginShell$?shell-plugin-autogenerate?


I do not understand this, we are not building a templating engine here,
you only have 2 options:
1) a required (MUST) attribute has an explicit value
2) a require (MUST) attribute has a placeholder value

the placeholder value is fixed per type, and what it is substituted with
uses the same rules as the current code uses to autogenerate values.


   the command: ipa user-add tuser
   --homedir=/tmp/tuser--roomnumber=1234 --to-stage would create a
   staging entry:

   dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
   ...
   roomNumber: 1234
   homeDirectory: /tmp/tuser
   loginShell: shell-plugin-autogenerate


loginShell is a MAY attribute, not a MUST attribute, so nothing should
be stored at all in the staged entry unless explicitly provided for by
the admin.


   Then a private DS plugin (catching shell-plugin-autogenerate)
   generate the loginShell value when the entry becomes active.


   the command: ipa user-add tuser --homedir=/tmp/tuser--to-stage would
   create a staging entry:

   dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
   ...
   roomNumber: -2
   homeDirectory: /tmp/tuser
   loginShell: shell-plugin-autogenerate


roomNumber is also a MAY, so what would cause it to be set at -2, and
why ?


   the command: ipa user-add tuser --to-stage would create a staging
entry:

   dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX
   ...
   roomNumber: -2
   homeDirectory: /home/net/shell-tuser
   loginShell: shell-plugin-autogenerate


homeDirectory should be something like: ?placeholder? IMO, we do not
really want to play templating here.


   In case the provisioning template does not define 'homeDirectory',
   then the created entry would take the value from the ipa config
   definition:


that value should be taken and applied at the time the user is unstaged
and brought in the actual tree, not at the time a user is staged.

HTH,
Simo.



Hello Thierry and Simo,

I think Thierry was confused with this part of the design:

"
This format of placeholders gives enough space for future enhancements. For
example, Administrator could configure a new template
"myhomedirtemplate$/home/net/%{uid}" and use it in the staged LDAP entry.
Such value would be replaced by "/home/net/tuser if user uid attribute is set
to tuser
"

My intention when writing this design was to enable future use of
configurable placeholders, i.e. a value "?someplaceholder?" could be turn
into "/custom/path/%{uid}". But I meant that this can be considered as a
future enhancement. For now, I think implementing a placeholder "-1" for
numerical values and "?autogenerate?" for string ones a good start.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel



Please consider the flow: user added staged -> activated/moved to main tree -

Re: [Freeipa-devel] Status/Question about User life cycle

[thierry bordaz]

On 05/22/2014 07:21 PM, Simo Sorce wrote:

On Thu, 2014-05-22 at 17:52 +0200, 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
public.

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
started
   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.
'uid'
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:
http://www.freeipa.org/page/V4/User_Life-Cycle_Management


   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
miss
   something ?

   regards
   thierry

Hmm, no, I think you are right.  We can change --from-stage to
just
Bool
parameter. When it is true, it'd mean that get_dn or
pre-callback
should
retrieve the record from stage and use all it's attributes (and
add
standard
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
don't
support something like:
   ipa user-add tuser --from-stage --phone=123456789
--email=newem...@example.com
If this is the case, what's the reason for using user-add for
this?
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
and
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.
But
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
containers.

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 
like:
  ipa user-stage tuser --first=abc --last=xyz --phone=123 ..
  ipa user-stage --deleted=tuser  # 
We should avoid this, if only for the reason that it makes the help text
confusing.


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) mo

Re: [Freeipa-devel] Status/Question about User life cycle

[Martin Kosek]

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
> public.
>
> 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
>> started
>>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.
>> 'uid'
>> 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:
> http://www.freeipa.org/page/V4/User_Life-Cycle_Management
>
>>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
>> miss
>>something ?
>>
>>regards
>>thierry
> Hmm, no, I think you are right.  We can change --from-stage to
> just
> Bool
> parameter. When it is true, it'd mean that get_dn or
> pre-callback
> should
> retrieve the record from stage and use all it's attributes 
> (and
> add
> standard
> 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
>>> don't
>>> support something like:
>>>ipa user-add tuser --from-stage --phone=123456789
>>> --email=newem...@example.com
>>> If this is the case, what's the reason for using user-add for
>>> this?
>>> 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
 and
 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.
>>> But
>>> 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=st

Re: [Freeipa-devel] Status/Question about User life cycle

[thierry bordaz]

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
public.

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
started
   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.
'uid'
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:
http://www.freeipa.org/page/V4/User_Life-Cycle_Management


   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
miss
   something ?

   regards
   thierry

Hmm, no, I think you are right.  We can change --from-stage to
just
Bool
parameter. When it is true, it'd mean that get_dn or
pre-callback
should
retrieve the record from stage and use all it's attributes (and
add
standard
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
don't
support something like:
   ipa user-add tuser --from-stage --phone=123456789
--email=newem...@example.com
If this is the case, what's the reason for using user-add for
this?
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
and
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.
But
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
containers.

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
like:
  ipa user-stage tuser --first=abc --last=xyz --phone=123 ..
  ipa user-stage --deleted=tuser  # 
We should avoid this, if only for the reason that it makes the help text
confusing.


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 ma