On 11/01/2012 09:32 AM, Simo Sorce wrote:
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 ?
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 ?)
The one major drawback of CoS attributes is that they cannot currently
be indexed, but you could write a virtual attribute indexing plugin.
That is, you cannot do a search like (astAccountNAT=somevalue) and have
it be indexed. You would have to write a virtual attribute indexing
plugin (similar to what Roles does to allow searches like (nsRole=some
role dn)).
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.
Right. That is planned for a future version of 389.
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.
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.
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 ?
Can regular computers be 'endpoint' devices ? (I am thinking softphones)
Or an endpoint is always a physical device ?
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 ?
Lots of questions, but you are on a good start!
Have fun.
Simo.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
