<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 05/20/2014 10:30 PM, Martin Kosek wrote: </div> <blockquote cite="mid:537BBB4D.8030000@redhat.com" type="cite">I am sharing the question below with the list as I think the information is useful and relevant for everyone interested in this feature. See answers in the text. On 05/20/2014 06:26 PM, thierry bordaz wrote: <blockquote type="cite">Hello Martin, Petr, I implemented 'user-add --to-stage' in a very simple way. Basically rather than filling the 'accounts' container it fills the 'staged users' container. It helped me to start digging into the code. Now I am looking at details of this entry. Especially the attributes present when the entry is in staging container. So far, the entry is looking like: ldapsearch -LLL -h localhost -p 389 -D "cn=directory manager" -w Secret123 -b "dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" uid=tb1 dn: uid=tb1,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos,d c=redhat,dc=com displayName: tb1 tb1 cn: tb1 tb1 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh initials: tt gecos: tb1 tb1 sn: tb1 homeDirectory: /home/tb1 uid: tb1 mail: <a class="moz-txt-link-abbreviated" href="mailto:tb1@idm.lab.bos.redhat.com">tb1@idm.lab.bos.redhat.com</a> krbPrincipalName: <a class="moz-txt-link-abbreviated" href="mailto:tb1@IDM.LAB.BOS.REDHAT.COM">tb1@IDM.LAB.BOS.REDHAT.COM</a> givenName: tb1 ipaUniqueID: 5556123c-e036-11e3-9915-001a4a104ecd uidNumber: 646400005 gidNumber: 646400005 memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= com As you can see it contains extra objectclasses and some attributes are set (like uidNumber or gidNumber). According to the design that the entry should rather look like: dn: uid=tb1,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos,d c=redhat,dc=com displayName: tb1 tb1 cn: tb1 tb1 objectClass: top objectClass: organizationalperson objectClass:krbprincipalaux objectClass: posixaccount loginShell: autogenerated sn: tb1 homeDirectory: /home/tb1 uid: tb1 krbPrincipalName: <a class="moz-txt-link-abbreviated" href="mailto:tb1@IDM.LAB.BOS.REDHAT.COM">tb1@IDM.LAB.BOS.REDHAT.COM</a> uidNumber: -1 gidNumber: -1 Is that correct ? </blockquote> user-add sets the uidNumber and gidNumber to -1, meaning that these numbers should be autogenerated by a plugin. If the plugin scope is updated according to design to disregard staging users container, the number should stay -1 until the entry is really moved to active users container. The same applies for ipaUniqueId, just the generation triggering text is "autogenerate". <blockquote type="cite"> Then when the entry get activated ('ipa user-activate tb1 --from-stage), we should have the attribute being generated uidNumber/gidNumber/ipaUniqueId... My understanding is that those attributes should be generate by DS plugins when the entry is moved to 'accounts' container. So playing with plugin scope would help to have staged users without all these attributes and 'accounts' users with them. </blockquote> Right. <blockquote type="cite"> What is not clear to me is the chapter related to the 'placeholders'. My understanding is that it should be a kind of template defining how to fill attribute values. I am looking for some code/doc dealing with placeholders but I do not know where to start from. Do you know any pointers on this. </blockquote> I tried to write down the reasons for using placeholders in this section: <a class="moz-txt-link-freetext" href="http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Placeholders">http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Placeholders</a> Placeholder allows provisioning systems to specify only some attributes of for example posixAccount objectclass while not having to fill all the MUST attributes. I think the example with filled "homeDirectory: /home/tuser" tells it all - homeDirectory is filled, other attributes are left for FreeIPA to generate based on it's settings. </blockquote> <blockquote cite="mid:537BBB4D.8030000@redhat.com" type="cite"> As for UID and GID, you do not need to do anything - "-1" already means autogenerate the values. Attributes not controlled by a plugin needs to be controlled by the command that moves user from staging users to active users - following list shows how should be the values generated: </blockquote> Hello, <blockquote>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. <ul> <li>Where is located the template file ? Is there a standard repository where templates are put ? (somewhere under /etc/ipa/* ?)</li> <li>Is there an already defined syntax for the provisionning template. ('$' is separator attr/value, %{<attr>} is substitute pattern...). If not, is it possible to user ':<space> ' as separator ? </li> <li>What is the priority. The user can provide the 'homeDirectory' through different methods. Is it ok to use the following order:</li> <ul> <li>the CLI option</li> <li>the provisionning template </li> <li>the default config value (in cn=ipaConfig,cn=etc,$SUFFIX)</li> </ul> </ul> For example, if it exists the provisioning template: /etc/ipa/provisioning/shell-user.template <blockquote> <tt>roomnumber$-2</tt><tt> </tt><tt>homeDirectory$/home/net/shell-%{uid}</tt><tt> </tt><tt>loginShell$?shell-plugin-autogenerate?</tt> </blockquote> the command: <tt>ipa user-add tuser --homedir=/tmp/tuser</tt><tt> --roomnumber=1234 --to-stage </tt>would create a staging entry: <tt>dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX</tt> <tt>...</tt> <tt>roomNumber: 1234</tt> <tt>homeDirectory: /tmp/tuser</tt> <tt>loginShell: </tt><tt>shell-plugin-autogenerate</tt> Then a private DS plugin (catching <tt>shell-plugin-autogenerate) </tt>generate the loginShell value when the entry becomes active. the command: <tt>ipa user-add tuser --homedir=/tmp/tuser</tt><tt> --to-stage </tt>would create a staging entry: <tt>dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX</tt> <tt>...</tt> <tt>roomNumber: -2</tt> <tt>homeDirectory: /tmp/tuser</tt> <tt>loginShell: </tt><tt>shell-plugin-autogenerate </tt> <tt> </tt> the command: <tt>ipa user-add tuser </tt><tt> --to-stage </tt>would create a staging entry: <tt>dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX</tt> <tt>...</tt> <tt>roomNumber: -2</tt> <tt>homeDirectory: /home/net/shell-tuser</tt> <tt>loginShell: </tt><tt>shell-plugin-autogenerate </tt> <tt> </tt> In case the provisioning template does not define 'homeDirectory', then the created entry would take the value from the ipa config definition:<tt> </tt><tt>dn: uid=tuser,cn=staged users,cn=provisioning,$SUFFIX</tt> <tt>...</tt> <tt>roomNumber: -2</tt> <tt>homeDirectory: /home/tuser</tt> <tt>loginShell: </tt><tt>shell-plugin-autogenerate</tt> best regards thierry </blockquote> <blockquote cite="mid:537BBB4D.8030000@redhat.com" type="cite"> <a class="moz-txt-link-freetext" href="http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Placeholder_Definition">http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Placeholder_Definition</a> HTH, Martin </blockquote> </body> </html>