[Freeipa-devel] RFC: freeipa-asterisk plugin

[Simo Sorce]

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.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York