Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
On 11/27/2012 08:34 AM, Loris Santamaria wrote: 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
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
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
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
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. We also took as stab at recommendations about writing such plugins. The list of things to consider turned to be long and scary. It is definitely a candidate for the external plugin development guide or alike but we do not have time to spend cycles to create such a guide now. We are still discussing how to better deliver this information to FreeIPA community and potential plugin developers like you. Please stay tuned. Thank you for your feedback! -- Loris Santamaria linux user #70506
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
2012/11/26 Loris Santamaria lo...@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? And a centralized repository (or at least directory) for those community plugins? Regards, J. -- Jérôme Fenal ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
On Mon, 2012-11-26 at 21:04 +0100, Jérôme Fenal wrote: 2012/11/26 Loris Santamaria lo...@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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
Simo Sorce wrote: On Mon, 2012-11-26 at 21:04 +0100, Jérôme Fenal wrote: 2012/11/26 Loris Santamaria lo...@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. It is likely to take the form of a wiki page pointing to various plugins. I'm not sure we'd get much interest if we tried to host the repository ourselves. We'd also have to deal with all sorts of other issues like commit privileges, releases, etc. It would be a major headache on both sides. rob
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
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. We also took as stab at recommendations about writing such plugins. The list of things to consider turned to be long and scary. It is definitely a candidate for the external plugin development guide or alike but we do not have time to spend cycles to
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
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.
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
On Mon, 2012-11-26 at 16:44 -0500, Rob Crittenden wrote: It is likely to take the form of a wiki page pointing to various plugins. I'm not sure we'd get much interest if we tried to host the repository ourselves. We'd also have to deal with all sorts of other issues like commit privileges, releases, etc. It would be a major headache on both sides. Well I guess we could have a yum repo that has pointers elsewhere, but I agree a yum repo may not be that interesting, for Fedora/RHEL it would probably be more interesting to make the plugin part of Fedora and EPEL repos. That way people gets the right bits aligned by version in the distro of choice. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
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
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
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. 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. We also took as stab at recommendations about writing such plugins. The list of things to consider turned to be long and scary. It is definitely a candidate for the external plugin development guide or alike but we do not have time to spend cycles to create such a guide now. We are still discussing how to better deliver this information to FreeIPA community and potential plugin developers like you. Please stay tuned. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
On 11/02/2012 09:40 AM, Rob Crittenden wrote: Dmitri Pal wrote: On 11/02/2012 12:25 AM, Loris Santamaria wrote: El jue, 01-11-2012 a las 12:47 -0400, Dmitri Pal escribió: On 11/01/2012 11: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! Indeed! Several procedural questions to the list: 1) The design is on the github, Simo, should we have a proxy page on our wiki that will point to the github project? 2) Do we need to track it in some way via our ticketing system to make sure that it is aligned with our release cycle? 3) Loris, will it be a completely external effort or you want the code to land in the IPA repository or IPA tools/plugins/satellite repository that currently does not exist but we probably should have? 4) Loris, in a long run how you foresee this functionality being delivered? IPA + EPEL and support from your organization or you want it completely blend into the project and be supported as a part of the core IPA over time? Of course it would be great if this plugin could be distributed as an optional but official IPA component. IMO it can be eventually. It really depends on your goals. If you see it possible we will submit the code for review as soon as it is in a working state, else we will at least submit it for inclusion in Fedora with a dependency on freeipa-server. So you are potentially open to moving the project under the IPA optional area that currently does not exists but can be created because this project sets a precedent. Let us work out the details when the code is functional. You could set some guidelines for projects like this. Yes, but we do not have them yet, so it is a good opportunity to identify what these guidelines should include and start putting together a wiki page to provide a guidance. But this is so far uncharted territory so please bear with us and any help in this area would be appreciated. I will try to put together a wiki page to cover what we already learned from this thread. I also need to read more about Asterisk before I can proceed. I see that a dhcp plugin is in the works, maybe both this plugin and the dhcp plugin should get assigned containers under a generic cn=apps container? Ip phones and maybe printers should be listed under a cn=devices container? Yes and no. IMO we need to differentiate the components even optional ones that are or will be developed within IPA project and are completely external and independent components developed independently. We need guidance for both but historically it is hard to plan in advance until someone starts actual work. So may be the guideline should state figure out what the container name for the data you are going to add will be, here are XYZ constraints to consider. This is exactly what you are doing now. How one should integrate optional components with the Web UI? Yeah this is a gray area to me to. I would love to see a clear doc on this too. Petr, is this doable? We have this guide, which has a UI component: http://abbra.fedorapeople.org/guide.html rob I did not realize that it covers the UI. Last time I read it I do not remember see a UI section. So is it up to date and sufficient? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
On 11/02/2012 09:53 AM, Alexander Bokovoy wrote: On Fri, 02 Nov 2012, Dmitri Pal wrote: How one should integrate optional components with the Web UI? Yeah this is a gray area to me to. I would love to see a clear doc on this too. Petr, is this doable? We have this guide, which has a UI component: http://abbra.fedorapeople.org/guide.html rob I did not realize that it covers the UI. Last time I read it I do not remember see a UI section. So is it up to date and sufficient? We do have hooks for extensions in Web UI already so it is possible to add external modules, albeight it is being directed to support sysadmins with local tuning rather than full blown modes. That local tuning gives you chance to load additionally any JS modules on the server. As we found recently with AD trusts, there is also an issue of refreshing running server configuration once a new feature is added -- since WSGI process does load IPA plugins only at startup. This is sort of maintenance machinery that needs to be done for all additional IPA plugins. Yes. I already came up with a list of 17 items that need to go into the guidelines. Plugin deployment is one of them. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
On 11/02/2012 03:35 PM, Dmitri Pal wrote: On 11/02/2012 10:15 AM, Petr Vobornik wrote: On 11/02/2012 02:36 PM, Dmitri Pal wrote: On 11/02/2012 12:25 AM, Loris Santamaria wrote: El jue, 01-11-2012 a las 12:47 -0400, Dmitri Pal escribió: On 11/01/2012 11: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. How one should integrate optional components with the Web UI? Yeah this is a gray area to me to. I would love to see a clear doc on this too. Petr, is this doable? 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. Do you target existing releases (up to 3.0) or some next? In versions 2.2 and 3.0 not-touching existing Web UI sources might not be doable. You will have to put some code into ext/extension.js which is blank file, marked as configuration file and is loaded with the rest of Web UI. I do not think it is worth targeting existing versions. You will face two problems: 1) Load extension code. Currently Web UI has all links to JS sources hard coded in index.html. You can put all your code into extension.js or you have to put there a code which will dynamically load your JS file. 2) Register entity and update navigation You need to update navigation to display a link for the new pages. It's not straightforward without touching webui.js. I doubt that anybody done it before. I can help you with it if needed. IMO we should eliminate both issues to allow extending Web UI just by adding files to some directory. Please file a ticket. I would argue it will be the goal for the Pilsner release to address it. Tickets for both issues filed: https://fedorahosted.org/freeipa/ticket/3235 https://fedorahosted.org/freeipa/ticket/3236 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] RFC: freeipa-asterisk plugin
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! -- 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
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
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 ?) 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
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
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
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
On 11/01/2012 11: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! Indeed! Several procedural questions to the list: 1) The design is on the github, Simo, should we have a proxy page on our wiki that will point to the github project? 2) Do we need to track it in some way via our ticketing system to make sure that it is aligned with our release cycle? 3) Loris, will it be a completely external effort or you want the code to land in the IPA repository or IPA tools/plugins/satellite repository that currently does not exist but we probably should have? 4) Loris, in a long run how you foresee this functionality being delivered? IPA + EPEL and support from your organization or you want it completely blend into the project and be supported as a part of the core IPA over time? 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 only concern I have is potential future multitenancy work. We probably need to think about guidelines that integration projects like this should follow to avoid being completely broken in the future multitenant case. * 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
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
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
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
El jue, 01-11-2012 a las 12:47 -0400, Dmitri Pal escribió: On 11/01/2012 11: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! Indeed! Several procedural questions to the list: 1) The design is on the github, Simo, should we have a proxy page on our wiki that will point to the github project? 2) Do we need to track it in some way via our ticketing system to make sure that it is aligned with our release cycle? 3) Loris, will it be a completely external effort or you want the code to land in the IPA repository or IPA tools/plugins/satellite repository that currently does not exist but we probably should have? 4) Loris, in a long run how you foresee this functionality being delivered? IPA + EPEL and support from your organization or you want it completely blend into the project and be supported as a part of the core IPA over time? Of course it would be great if this plugin could be distributed as an optional but official IPA component. If you see it possible we will submit the code for review as soon as it is in a working state, else we will at least submit it for inclusion in Fedora with a dependency on freeipa-server. You could set some guidelines for projects like this. I see that a dhcp plugin is in the works, maybe both this plugin and the dhcp plugin should get assigned containers under a generic cn=apps container? Ip phones and maybe printers should be listed under a cn=devices container? How one should integrate optional components with the Web UI? IPA is a great framework to write LDAP configuration templates, very complete and easy to use, so some guidelines for satellite work could really get more contributions which you could then pull in the official distribution when they are ready and useful enough. 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 only concern I have is potential future multitenancy work. We probably need to think about guidelines that integration projects like this should follow to avoid being completely broken in the future multitenant case. * 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
