El jue, 01-11-2012 a las 11:32 -0400, Simo Sorce escribió:
> 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!
> 
> > 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 ?

Yes we will have to introduce the project to the asterisk-devel mailing
list as well.

> 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 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.

You have a point here. The purpose was to have a global search on
objectClass=AsteriskSIPUser not returning the site configuration/global
configuration stuff, but since real SIP objects are in their own
container this is not really needed. 

> 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.

Agreed, every new object will belong to the ipaAst sub-namespace. We
will need an OID for that.

Please note that this schema may grow in the future as Asterisk is very
flexible in this respect. In fact the list of LDAP attributes used by
Asterisk is configured at runtime, and it can retrieve from LDAP the
configuration of other types of telephony features, like queues and
conference rooms, even tough these are not defined in the standard
schema.

For now we will begin with SIP, IAX and Voicemail stuff

> 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 ?

The secret is used by the phone to authenticate itself against Asterisk,
and the phone gets this password over a configuration file downloaded
via TFTP or HTTP, a file which should be generated automatically by an
"endpoint manager", so it would have to be kept in clear text. Only
Asterisk and the endpoint manager would be able to read this password
from the directory using a proper ACI and a bind user.

It is not an ideal situation but for now it is the only authentication
scheme that works with all brands of phones. Maybe in the future one
will be able to use certificate authentication for phones.

> Can regular computers be 'endpoint' devices ? (I am thinking softphones)
> Or an endpoint is always a physical device ?

Yes, the endpoint could be a computer.

> 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 ?

Nothing defined so far, it could be something like

Asterisk
===========================================================
Sites   SIP    IAX    Voicemail   Dialplan    Global Config

> Lots of questions, but you are on a good start!
> Have fun.
> 
> Simo.
> 

Thanks for the feedback!
-- 
Loris Santamaria   linux user #70506   xmpp:lo...@lgs.com.ve
Links Global Services, C.A.            http://www.lgs.com.ve
Tel: 0286 952.06.87  Cel: 0414 095.00.10  sip:1...@lgs.com.ve
------------------------------------------------------------
"If I'd asked my customers what they wanted, they'd have said
a faster horse" - Henry Ford

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to