[Freeipa-devel] RFC: freeipa-asterisk plugin
Simo Sorce
simo at redhat.com
Mon Nov 26 20:56:17 UTC 2012
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
More information about the Freeipa-devel
mailing list