[Freeipa-devel] RFC: freeipa-asterisk plugin

[Dmitri Pal]

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!

Indeed!

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?
>
>> I wrote down the plans so far on this wiki page:
>>
>> https://github.com/sorbouc/sorbo/wiki/freeipa-asterisk
>>
>> 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
>>         ok
>>       * 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
> extension.
> 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
> schema.
>
> 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
> reason.
> 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.
>
> Simo.
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/