[Freeipa-devel] RFC: freeipa-asterisk plugin

Tue Nov 27 13:34:38 UTC 2012

El lun, 26-11-2012 a las 18:41 -0500, Dmitri Pal escribió:
> On 11/26/2012 05:55 PM, Simo Sorce wrote:
> > On Mon, 2012-11-26 at 17:30 -0500, Dmitri Pal wrote:
> >> On 11/26/2012 02:15 PM, Loris Santamaria wrote:
> >>> 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.
> >>>
> >>>> In future it might make sense to consider a different plugin that would
> >>>> add schema to IPA users only and would allow users to have additional
> >>>> Asterisk related attributes. I do not see a problem with user going into
> >>>> IPA web UI self service to manage his personal voice mail box settings.
> >>>> This seems like a logical operation. However it should be possible to
> >>>> split Asterisk configuration information between IPA and some other LDAP
> >>>> server or database. It might not make sense to pollute IPA with objects
> >>>> and entries that do not have a good relation to what IPA is for. So the
> >>>> best would be if Asterisk servers would be able to store user related
> >>>> info in the identity management system like IPA while having the rest of
> >>>> data about the infrastructure elsewhere. I do not know whether such
> >>>> approach is possible or feasible from the Asterisk project point of
> >>>> view. But if such extension for IPA users is in fact developed it has a
> >>>> much better chance to become over time a part of optional but supported
> >>>> portfolio of IPA plugins. No guarantees but at least such approach would
> >>>> be much closer to the core of what IPA is.
> >>> Ok this can be done, asterisk is very flexible in this respect, so the
> >>> voice mail box information could be stored alongside the users'
> >>> information.
> >> I am not sure we are on the same page.
> >> I suggested that *only* user related information will be in IPA and all
> >> other objects not related to identities will be stored elsewhere.
> >> Do you agree with such approach? It is not clear from your reply above.
> > Sorry Dmitri,
> > why would we want that ?
> >
> > I do not see an issue with a subtree being used by the asterisk plugin.
> >
> > However I would prefer Loris to use their own OID space for the schema
> > extensions so that we are not a bottleneck there.
> >
> > Simo.
> >
> OK it looks like there is some mis communication.
> I do no see an issue with storing all information in IPA: the data
> related to the users and the data that is absolutely unrelated to what
> IPA is about.
> We will do our best to help with the development of such solution
> regardless of the approach taken.
> 
> However of it is possible to split the work into two completely
> unrelated plugins one for user related data and one for the rest so that
> these two chunks of data can come from two different sources i.e. the
> user related info from IPA and all the rest from some other back end it
> being DB, LDAP or something else then there is a higher chance that the
> user management plugin would be integrated over time into the core of
> IPA (no guarantee but there is a chance). This can be a mute point
> becuase it might be that Asterisk does not support ability to get data
> from two completely different data sources (I mean data servers not just
> parts of the same tree). If this is the case then only a single plugin
> is possible. If so there is a much lower chance that any part of this
> solution would be integrated into the core of IPA code.
> It still can be offered independently. We will have it listed on our
> wiki and have pointers to it but we will not be integrated. And as I
> said we will help regardless.
> On the contrary if such split is possible I would think that it would
> make sense to try to develop the user portion as part of the IPA tree
> and use IPA OIDs while the complementing part can be implemented in the
> external repository. I hope it is more clear now.
> I agree that single plugin is simpler and faster to implement but the
> second option also has its long term merits.
> I just want to make sure that these implications are factored in at the
> beginning of the design and development.

Hi all,

it is indeed possible to have asterisk configuration information come
from different and unrelated sources, but doing it that way we would
lose all of the advantages that IPA offers.

First of all, asterisk configuration information is a kind of data that
is not often modified but it gets a lot of queries and this is the kind
of workload where a LDAP server performs the best. Also it is much
easier to replicate an LDAP server than, say, Postgres or MySQL.

But then, why not use OpenLDAP or 389 Directory Server directly, using a
frontend like phpLdapAdmin for data entry? Well just the thought of it
brings back sad memories of hard to configure replication, missing
indexes, editing spaghetti php code for extending templates.

The advantages we see with IPA are:

 - Easy installation, easy replication management
 - Installs a great LDAP server, 389, reasonably well tuned for general
use
 - A nice, easy to use python framework for managing schema, ACIs and
data entry

While I understand that resources are limited and the IPA team focus is
on the IDM aspects of the platform, I see that this platform has the
potential to become a configuration store for many applications, like
bind, isc dhcp, postfix, asterisk, freeswitch, etc.

So far, considering all the opinions, I think the best approach is for
the plugin to keep all asterisk data under a single container
(cn=asterisk) so it can be developed and distributed separately from the
core of IPA, and just aim for EPEL inclusion. The user serviceable parts
of the asterisk configuration (just a few voice mail settings) could be
managed by extending the selfservice plugin.

Thank you
-- 
Loris Santamaria   linux user #70506   xmpp:loris at lgs.com.ve
Links Global Services, C.A.            http://www.lgs.com.ve
Tel: 0286 952.06.87  Cel: 0414 095.00.10  sip:103 at lgs.com.ve
------------------------------------------------------------
"If I'd asked my customers what they wanted, they'd have said
a faster horse" - Henry Ford