On 11/02/2012 12:25 AM, Loris Santamaria wrote:
> El jue, 01-11-2012 a las 12:47 -0400, Dmitri Pal escribió:
>> On 11/01/2012 11:32 AM, Simo Sorce wrote:
>>> On Thu, 2012-11-01 at 09:30 -0430, Loris Santamaria wrote:
>>>> Hi all,
>>>> we plan to write a freeIPA configuration plugin for Asterisk, aiming to
>>>> be general and useful enough to be included in Fedora and EPEL, so we
>>>> would like to have your input on some issues before we write any code.
>>> Hi Loris,
>>> this is really exciting!
>> Several procedural questions to the list:
>> 1) The design is on the github, Simo, should we have a proxy page on our
>> wiki that will point to the github project?
>> 2) Do we need to track it in some way via our ticketing system to make
>> sure that it is aligned with our release cycle?
>> 3) Loris, will it be a completely external effort or you want the code
>> to land in the IPA repository or IPA tools/plugins/satellite repository
>> that currently does not exist but we probably should have?
>> 4) Loris, in a long run how you foresee this functionality being
>> delivered? IPA + EPEL and support from your organization or you want it
>> completely blend into the project and be supported as a part of the core
>> IPA over time?
> Of course it would be great if this plugin could be distributed as an
> optional but official IPA component.
IMO it can be eventually. It really depends on your goals.
> If you see it possible we will
> submit the code for review as soon as it is in a working state, else we
> will at least submit it for inclusion in Fedora with a dependency on
So you are potentially open to moving the project under the "IPA"
optional area that currently does not exists but can be created because
this project sets a precedent.
Let us work out the details when the code is functional.
> You could set some guidelines for projects like this.
Yes, but we do not have them yet, so it is a good opportunity to
identify what these guidelines should include and start putting together
a wiki page to provide a guidance. But this is so far uncharted
territory so please bear with us and any help in this area would be
I will try to put together a wiki page to cover what we already learned
from this thread. I also need to read more about Asterisk before I can
> I see that a dhcp
> plugin is in the works, maybe both this plugin and the dhcp plugin
> should get assigned containers under a generic cn=apps container? Ip
> phones and maybe printers should be listed under a cn=devices container?
Yes and no. IMO we need to differentiate the components even optional
ones that are or will be developed within IPA project and are completely
external and independent components developed independently. We need
guidance for both but historically it is hard to plan in advance until
someone starts actual work. So may be the guideline should state "figure
out what the container name for the data you are going to add will be,
here are XYZ constraints to consider".
This is exactly what you are doing now.
> How one should integrate optional components with the Web UI?
Yeah this is a gray area to me to. I would love to see a clear doc on
Petr, is this doable?
> IPA is a great framework to write LDAP configuration templates, very
> complete and easy to use, so some guidelines for "satellite" work could
> really get more contributions which you could then pull in the official
> distribution when they are ready and useful enough.
Absolutely. We just have not has a chance to invest into making it
easier. Looks like it is time.
>>>> I wrote down the plans so far on this wiki page:
>>>> Basically we would like to know if:
>>>> * It is ok to use cn=asterisk as the base object
>>> This looks like a good choice, maybe check with the asterisk people if
>>> they are ok with using the name that way ?
>>> Anyway any product specific name would work here, as it makes it
>>> extremely unlikely to clash with any future work in upstream FreeIPA or
>>> for any custom data in users' sites.
>> The only concern I have is "potential" "future" multitenancy work.
>> We probably need to think about guidelines that integration projects
>> like this should follow to avoid being completely broken in the future
>> multitenant case.
>>>> * The planned DIT, separating object per type and not per site, is
>>>> * The whole stuff of using CoS as a mechanism to apply default
>>>> values to every new object seems right
>>> CoS may have some performance implications, and some usage implication,
>>> you need to evaluate if you are ok with those, but in general setting
>>> defaults is its job so it may be a good fit.
>>> I am CCing Nathan and Rich to ask them about the CoS definitions and
>>> whether using that many attributes would be problematic, so far I've
>>> only seen CoS used for overriding a single attribute so I am not sure
>>> what are the implications with that many.
>>> (Nathan, Rich, can you take a quick look at the paragraph named 'CoS
>>> definition entries' around the middle of the github wiki page pointed by
>>> Loris ?)
>>>> Another issue is that Asterisk SIP objects in real life are generally
>>>> associated with real people and with physical devices.
>>>> The physical devices are configured with a piece of software called the
>>>> "endpoint manager", which could pull from the directory the data
>>>> required to generate the IP phones configuration. We have to choices
>>>> here. Store the IP phone extra data _with_ the Asterisk SIP object,
>>>> adding a ieee802device objectClass to the asteriskSIPuser object. The
>>>> other option is to store the ieee802device object separately in a more
>>>> appropriate part of the IPA tree and have it reference the SIP object
>>>> vía a "seeAlso" or "managedBy" attribute.
>>> I am not sure that there is an actual 'more appropriate' part of the
>>> tree. Although we do manage 'devices' (computer objects) that is for
>>> machines that are joined to the IPA domain so it would not be applicable
>>> in cases where the device can't actually 'join' an ipa domain. However I
>>> would stay flexible here and allow both cases.
>>> Ie allow to have objects both within the cn=asterisk subtree or in some
>>> other subtree.
>>> The ieee802device is an auxiliary class so it can be associated with any
>>> object in the schema at any time. The AsteriskSIPUser is also an
>>> auxiliray class, so as long as you allow searches that span the whole
>>> tree you can allow people to choose whether to associate these classes
>>> to external objects or to create device objects under cn=asterisk.
>>> Of course you need to decide if allowing that will make your plugin more
>>> complex and how you will manage those objects then.
>>>> As for linking SIP users to real people, it would be great to link the
>>>> asteriskSIPuser object to an IPA user, but probably not all
>>>> organizations interested in this kind of functionality for Asterisk
>>>> would manage all of their users with IPA. What if the real user belongs
>>>> to a trusted directory, for example? So it seems that for simplicity's
>>>> sake we will have to store the name of the person using the phone in the
>>>> asteriskSIPuser description attribute.
>>> As for devices I think it would be nice if you could allow both options.
>>> Some deployments may choose to provision new user accounts from the get
>>> go with all the data including asterisk data.
>>> Also putting the data on the user entry make it simpler to allow the
>>> user to change some of the fields in a self service fashion (assuming
>>> there is any attribute that users should be able to change in a self
>>> service way).
>>> Other deployments that may want to handle additional users may need to
>>> be able to add additional unrelated users though, so being able to do
>>> that is also nice.
>>>> Speaking of packaging, reading http://abbra.fedorapeople.org/guide.html
>>>> it doesn't seems clear to me how to have an extra category of
>>>> configuration pages added to the Web UI without modifying the main IPA
>>>> page. What is the proper way to add extra pages to the web UI ?
>>> I will let the UI expert reply on this point.
>>> More questions follow :-)
>>> I am reading the project page description and I see your schema files
>>> needs to be converted in a format that is ok for 389 DS, that requires
>>> you to add the attributes and objectclasses full OIDs to the specific
>>> attribute/object definition, IIRC 389 does not allow for macro expansion
>>> of OIDs like is done in the official Digium schema files.
>>> Btw can you explain what is the use of the AsteriskSiteDefault
>>> objectclass, it looks like an über-objectclass that allows to associate
>>> a lot of Asterisk attributes, but it is not clear why you need this
>>> class and why you extend AsteriskExtension with it but then add
>>> additional Ast attributes.
>>> At a quick glance it seem to defeat the purpose of the objectclass
>>> division done by the asterisk people.
>>> Also 'Asterisk/Ast' is a prefix used by Digium, so it would be better
>>> not to use that prefix for custom objects to avoid potential accidental
>>> conflicts should they decide to add a class with that name, and in
>>> general it is better to avoid confusion, using a different prefix makes
>>> it clear that this is not an official digium object but a custom
>>> Also you need an OID for this calss, do you have your own OID
>>> numberspace from which to assign from ?
>>> Otherwise we need to decide how to get you OIDs for your additional
>>> I see also that you created some attributes that use the ipa prefix for
>>> their name. for these you will also need an OID, and we should probably
>>> agree on a subprefix you can use and that we mark as assigned to your
>>> plugin so we do not accidentally use a conflicting name for whatever
>>> I see the actual prefix ends up being ipaAutoAst for the 2 attributes
>>> you defined. Perhaps if would be better to use ipaAstAuto as a prefix
>>> instead, and we mark the whole sub-namespace 'ipaAst' as a name space
>>> that you use in your plugin. (So maybe you want to use
>>> ipaAstSitesDefaults for your custom objectclass)
>>> To make things clearer I would suggest you to use 2 schema files; one
>>> with the official digium objects and an additional one that depends on
>>> it with the plugin custom objects.
>>> The basic DIT looks ok, but there isn't much detail on what you plan to
>>> put in each sub container (sorry if this should be obvious to
>>> Asterisk-versed people, I know the project only by name and never
>>> configured an Asterisk server myself).
>>> I see that there is a astAccountSecret attribute that seem to hold a
>>> clear text password ? I assume it is desired that the SIP password is
>>> actually *not* synchronized with the FreeIPA account password as it
>>> usually is transmitted in the clear by a lot of devices/SIP phones ?
>>> Can regular computers be 'endpoint' devices ? (I am thinking softphones)
>>> Or an endpoint is always a physical device ?
>>> As I said I am not really familiar with Asterisk configuration but all
>>> the plugin CLI command looks quite reasonable.
>>> What kind of UI do you have in mind for the Web part ?
>>> Something inspired by our DNS plugin ? Or something different ?
>>> Lots of questions, but you are on a good start!
>>> Have fun.
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-devel mailing list