[Freeipa-devel] RFC: freeipa-asterisk plugin

[Rob Crittenden]

Simo Sorce wrote:
> On Mon, 2012-11-26 at 21:04 +0100, Jérôme Fenal wrote:
>> 2012/11/26 Loris Santamaria <loris at lgs.com.ve>
>>          El vie, 16-11-2012 a las 14:35 -0500, Dmitri Pal escribió:
>>          > On 11/01/2012 10:00 AM, 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.
>>          > >
>>          > > 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
>>          > >       * 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
>>          > >
>>          > > 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.
>>          > >
>>          > > 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.
>>          > >
>>          > > 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 ?
>>          > >
>>          > > Thanks in advance for your input!
>>          > >
>>          > Hello Loris,
>>          >
>>          > Sorry for the delay.
>>          > I finally got a moment to read about Asterisk and looked
>>          into your plans.
>>          > Based on what you are proposing there is no real tight
>>          integration
>>          > between IPA identities and services provided by IPA and
>>          Asterisk. What I
>>          > see is IPA's DS would just be used as a data store for
>>          Asterisk
>>          > configuration data and it would be managed via CLI
>>          leveraging the plugin
>>          > framework we put together.  If such approach is interesting
>>          for a
>>          > customer I do not see a reason why it should not be done. I
>>          also do not
>>          > see a value of having such plugin as a part of the
>>          integrated IPA
>>          > supported offering. It is too independent and far from the
>>          core for us.
>>          > But it is definitely a starting point. It might change over
>>          time.
>>
>>
>>          Hi Dmitri, sorry for my late response, I was on vacation and
>>          just now
>>          resuming work on this plugin.
>>
>>          I agree with you, this plugin while it could be useful to a
>>          number of
>>          sysadmins it is not really part of an identity management
>>          solution.
>>
>> Hi all,
>>
>> Wild question related to this one: would it be possible to add a
>> plugin deployment/activation mechanism to allow admins to easily add
>> such plugins maintained outside the IPA main tree?
>
> Yes we want to work alongside Loris to make this happen.
>
>> And a centralized repository (or at least directory) for those
>> community plugins?
>
> This is a neat idea, once we'll have our first external plugin we will
> have to do something like this.

It is likely to take the form of a wiki page pointing to various 
plugins. I'm not sure we'd get much interest if we tried to host the 
repository ourselves. We'd also have to deal with all sorts of other 
issues like commit privileges, releases, etc. It would be a major 
headache on both sides.

rob