I'm sorry I was less than clear. There is no problem with IPA. I was
adding an attribute that was in a non-IPA-included objectclass. Since
it was included in the 389 ds schema, it was easy to add it in the
cn=ipaConfig,cn=etc,dc=domain,dc=tld ipaUserObjectClasses attribute
using a directory browser and it works great now.

Question though, is there some reason that you can't browse the rest
of the directory tree now like you could some parts in v1? I know it
probably takes away from the clean simplicity of the UI, but it would
be really neat if you could maybe access through an "Advanced" button
or such. You've created such an outstanding interface to the rest of
the directory--I would be so excited to be able to browse the hidden
parts as well using the same great UI.


On Sun, Aug 7, 2011 at 5:29 PM, Adam Young <> wrote:
> On 08/06/2011 04:29 PM, Stephen Ingram wrote:
>> On Sat, Aug 6, 2011 at 12:18 PM, Stephen Ingram<>
>>  wrote:
>>> On Fri, May 6, 2011 at 1:11 PM, Adam Young<>  wrote:
>>>> On 05/06/2011 08:49 AM, Simo Sorce wrote:
>>>>> On Wed, 2011-05-04 at 17:41 -0700, Stephen Ingram wrote:
>>>>>> I currently maintain a directory with MTA configuration data in it
>>>>>> (among other items). I'm wondering what is the best way to add to the
>>>>>> FreeIPA schema without stepping on current and future schema additions
>>>>>> that might conflict with what I add. I know at one time you were
>>>>>> expecting to add information for Postfix and other common server
>>>>>> programs. Was this schema ever prepared and agreed upon, or is it best
>>>>>> to use some special branch to put this all under?
>>>>> Ok it seem we are confusing 2 things here, on one side schema
>>>>> extensions
>>>>> (new attributes and objectclasses) and on the other side DIT structure
>>>>> (subtrees within the tree where to put your information).
>>>>> If you use standard schema or schema you made yourself after you got
>>>>> assigned a base OID there should be no issue at all. if you do your own
>>>>> schema please be careful in trying to use a prefix for attribute and
>>>>> objectclass names so that you do not risk future name conflicts).
>>>>> For the DIT part it really depends on what you need to do.
>>>>> If you just need to add attributes to users then you have no other
>>>>> option but to attach them to the users and that's fine it shouldn't
>>>>> cause any issue.
>>>>> If you need to add entirely new objects I can suggest to create a
>>>>> cn=custom container as a top level subtree (ie at the same level of
>>>>> cn=accounts and cn=etc, ...
>>>>> And within it do what you need to do. This way it will not conflict
>>>>> with
>>>>> anything we may add in future.
>>>>>> Also, although I read Adam Young's blog article about how to extend
>>>>>> the WebUI, I'm having difficulty adding attributes within the existing
>>>>>> structure. For example, on the user page, is there a prescribed way of
>>>>>> adding say, the mailAlternateAddress attribute such that it shows as a
>>>>>> field in the WebUI?
>>>> The rule is that  you need to be able to do it in the CLI first, and
>>>> then
>>>> attempt it in the WebUI.  The attribute you are attmpeting to access
>>>> needs
>>>> to be added to the user object in freeipa/ipalib/plugins/  first.
>>>>  Once you have that, you can add it to the ui  just like email address:
>>>>  {factory: IPA.multivalued_text_widget, name:'mail'},
>>>> However,  mail is already a multivalued attribute.  You can store
>>>> multiple
>>>> email addresses there if you want, and that is the intention.  If you
>>>> want
>>>> to make these both single value fields, change it to:
>>>>  fields:
>>>>                [  "mail","mailalternateaddress",
>>>>                   {factory: IPA.multivalued_text_widget,
>>>> name:'telephonenumber'},...
>>> Off on another project for awhile, but I finally had a chance to
>>> attack this. Yes, I did have to make mailalternateaddress a separate
>>> attribute as I need to be able to search the directory for this and
>>> treat it differently than an email address (or multiple email
>>> addresses). After a nasty browser caching problem, I got everything to
>>> work. This is great! I'm a little weak in the javascript department,
>>> but with your instructions above and here
>>> (
>>> I was able to edit everything and make it work! The CLI worked great
>>> too. I could not believe it when I saw the command line options change
>>> (even in help) to reflect the added attribute. This is so unbelievably
>>> cool.
>>> The only problem I'm having is that if there is no attribute entry to
>>> begin with (I added the first mailalternateaddress with the command
>>> line after the changes), there is no "Add" link in the UI next to the
>>> attribute like on the Email address. Is there something that has to be
>>> done to get this to appear? Note that the "Delete" link and "Add" link
>>> does appear if there is already a value for the attribute.
>> Please just disregard this last problem. The correct objectclass was
>> missing from the directory entry. It works perfectly now.
>> Steve
> Glad to hear it. Interesting failure case.

Freeipa-users mailing list

Reply via email to