Hello,
we have made big progress with ansible-freeipa to be able to install ipa clients using ansible.
These are the things that we are able to do now:
- Simple installation on more than one machine - One configuration file (inventory file) per realm (One place for configuration options) - Authentication types - Simple use of OTP for installation and update - More secure (admin password not transferred to the clients) - Only setting of a variable is needed to enable the use of OTP - Admin principal and password - Existing host keytab - Advanced auto detection (server only, no need to provide domain) - Repair of broken configurations - Known limitation: /etc/krb5.keytab can not be repaired - Working with freeipa-4.4 and up - RHEL-7.3 and up - Fedora-25+ - Support for Python3 based freeipa in Fedora-27
The basic usage is explained in the README of the repository: https://github.com/freeipa/ansible-freeipa
I'd like to start a discussion about naming conventions and also about customer and user requests for extensions and changes.
Please give it a try and report issues you are running into.
Regards, Thomas
I've been doing this using a custom Ansible playbook for over a month now. It appears to me to be very variable dependent.
On Thu, Oct 5, 2017 at 7:04 AM, Thomas Woerner via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hello,
we have made big progress with ansible-freeipa to be able to install ipa clients using ansible.
These are the things that we are able to do now:
- Simple installation on more than one machine
- One configuration file (inventory file) per realm (One place for configuration options)
- Authentication types
- Simple use of OTP for installation and update
- More secure (admin password not transferred to the clients)
- Only setting of a variable is needed to enable the use of OTP
- Admin principal and password
- Existing host keytab
- Advanced auto detection (server only, no need to provide domain)
- Repair of broken configurations
- Known limitation: /etc/krb5.keytab can not be repaired
- Working with freeipa-4.4 and up
- RHEL-7.3 and up
- Fedora-25+
- Support for Python3 based freeipa in Fedora-27
The basic usage is explained in the README of the repository: https://github.com/freeipa/ansible-freeipa
I'd like to start a discussion about naming conventions and also about customer and user requests for extensions and changes.
Please give it a try and report issues you are running into.
Regards, Thomas _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hello Mark,
On 10/05/2017 03:57 PM, Mark Haney wrote:
I've been doing this using a custom Ansible playbook for over a month now. It appears to me to be very variable dependent.
For the full autodetection case you do not need more than the client hostname and the admin password/keytab (with or without OTP).
The optional variables are there to alter the default configuration according to the needs. Or did I not get it right?
Please be more specific on the things that you do not like.
Regards, Thomas
On Thu, Oct 5, 2017 at 7:04 AM, Thomas Woerner via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hello,
we have made big progress with ansible-freeipa to be able to install ipa clients using ansible.
These are the things that we are able to do now:
- Simple installation on more than one machine
- One configuration file (inventory file) per realm (One place for configuration options)
- Authentication types
- Simple use of OTP for installation and update
- More secure (admin password not transferred to the clients)
- Only setting of a variable is needed to enable the use of OTP
- Admin principal and password
- Existing host keytab
- Advanced auto detection (server only, no need to provide domain)
- Repair of broken configurations
- Known limitation: /etc/krb5.keytab can not be repaired
- Working with freeipa-4.4 and up
- RHEL-7.3 and up
- Fedora-25+
- Support for Python3 based freeipa in Fedora-27
The basic usage is explained in the README of the repository: https://github.com/freeipa/ansible-freeipa
I'd like to start a discussion about naming conventions and also about customer and user requests for extensions and changes.
Please give it a try and report issues you are running into.
Regards, Thomas _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
I never said I didn't like. Just that it's not that complicated to setup a playbook to do what you're doing.
On Thu, Oct 5, 2017 at 11:17 AM, Thomas Woerner twoerner@redhat.com wrote:
Hello Mark,
On 10/05/2017 03:57 PM, Mark Haney wrote:
I've been doing this using a custom Ansible playbook for over a month
now.
It appears to me to be very variable dependent.
For the full autodetection case you do not need more than the client hostname and the admin password/keytab (with or without OTP).
The optional variables are there to alter the default configuration according to the needs. Or did I not get it right?
Please be more specific on the things that you do not like.
Regards, Thomas
On Thu, Oct 5, 2017 at 7:04 AM, Thomas Woerner via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hello,
we have made big progress with ansible-freeipa to be able to install ipa clients using ansible.
These are the things that we are able to do now:
- Simple installation on more than one machine
- One configuration file (inventory file) per realm (One place for configuration options)
- Authentication types
- Simple use of OTP for installation and update
- More secure (admin password not transferred to the clients)
- Only setting of a variable is needed to enable the use of OTP
- Admin principal and password
- Existing host keytab
- Advanced auto detection (server only, no need to provide domain)
- Repair of broken configurations
- Known limitation: /etc/krb5.keytab can not be repaired
- Working with freeipa-4.4 and up
- RHEL-7.3 and up
- Fedora-25+
- Support for Python3 based freeipa in Fedora-27
The basic usage is explained in the README of the repository: https://github.com/freeipa/ansible-freeipa
I'd like to start a discussion about naming conventions and also about customer and user requests for extensions and changes.
Please give it a try and report issues you are running into.
Regards, Thomas _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.
fedorahosted.org
On to, 05 loka 2017, Mark Haney via FreeIPA-users wrote:
I never said I didn't like. Just that it's not that complicated to setup a playbook to do what you're doing.
There is a context to Thomas' message, Mark. We are trying to create a set of playbooks that would be supported by FreeIPA development team going forward. They may or may not become official ones in the Galaxy context but this is what we as an upstream would like to support.
They cover right now a client side of install. Server installation would be a next step -- not wrapping around ipa-server-install and ipa-replica-install but making it possible to decouple parts of what ipa-*-install scripts are and reuse them in the playbook context in a more flexible way. This is different to what is done by other playbooks we know which mostly wrap existing scripts' execution.
Thus, we are looking for a feedback to these playbooks because we want them to be useful in the field and be supported long term upstream.
On Thu, Oct 5, 2017 at 11:17 AM, Thomas Woerner twoerner@redhat.com wrote:
Hello Mark,
On 10/05/2017 03:57 PM, Mark Haney wrote:
I've been doing this using a custom Ansible playbook for over a month
now.
It appears to me to be very variable dependent.
For the full autodetection case you do not need more than the client hostname and the admin password/keytab (with or without OTP).
The optional variables are there to alter the default configuration according to the needs. Or did I not get it right?
Please be more specific on the things that you do not like.
Regards, Thomas
On Thu, Oct 5, 2017 at 7:04 AM, Thomas Woerner via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hello,
we have made big progress with ansible-freeipa to be able to install ipa clients using ansible.
These are the things that we are able to do now:
- Simple installation on more than one machine
- One configuration file (inventory file) per realm (One place for configuration options)
- Authentication types
- Simple use of OTP for installation and update
- More secure (admin password not transferred to the clients)
- Only setting of a variable is needed to enable the use of OTP
- Admin principal and password
- Existing host keytab
- Advanced auto detection (server only, no need to provide domain)
- Repair of broken configurations
- Known limitation: /etc/krb5.keytab can not be repaired
- Working with freeipa-4.4 and up
- RHEL-7.3 and up
- Fedora-25+
- Support for Python3 based freeipa in Fedora-27
The basic usage is explained in the README of the repository: https://github.com/freeipa/ansible-freeipa
I'd like to start a discussion about naming conventions and also about customer and user requests for extensions and changes.
Please give it a try and report issues you are running into.
Regards, Thomas _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.
fedorahosted.org
-- [image: photo] Mark Haney Network Engineer at NeoNova 919-460-3330 <(919)%20460-3330> (opt 1) • mark.haney@neonova.net www.neonova.net https://neonova.net/ https://www.facebook.com/NeoNovaNNS/ https://twitter.com/NeoNova_NNS http://www.linkedin.com/company/neonova-network-services
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
I'm fine with that. Just that IPA's implementation is very much end-user specific. I really doubt you could abstract the playbook enough to make it viable for even a majority of users.
Then again, what do I know, I'm just an engineer with 20+ years experience.
On Thu, Oct 5, 2017 at 12:41 PM, Alexander Bokovoy abokovoy@redhat.com wrote:
On to, 05 loka 2017, Mark Haney via FreeIPA-users wrote:
I never said I didn't like. Just that it's not that complicated to setup a playbook to do what you're doing.
There is a context to Thomas' message, Mark. We are trying to create a set of playbooks that would be supported by FreeIPA development team going forward. They may or may not become official ones in the Galaxy context but this is what we as an upstream would like to support.
They cover right now a client side of install. Server installation would be a next step -- not wrapping around ipa-server-install and ipa-replica-install but making it possible to decouple parts of what ipa-*-install scripts are and reuse them in the playbook context in a more flexible way. This is different to what is done by other playbooks we know which mostly wrap existing scripts' execution.
Thus, we are looking for a feedback to these playbooks because we want them to be useful in the field and be supported long term upstream.
On Thu, Oct 5, 2017 at 11:17 AM, Thomas Woerner twoerner@redhat.com
wrote:
Hello Mark,
On 10/05/2017 03:57 PM, Mark Haney wrote:
I've been doing this using a custom Ansible playbook for over a month
now.
It appears to me to be very variable dependent.
For the full autodetection case you do not need more than the client hostname and the admin password/keytab (with or without OTP).
The optional variables are there to alter the default configuration according to the needs. Or did I not get it right?
Please be more specific on the things that you do not like.
Regards, Thomas
On Thu, Oct 5, 2017 at 7:04 AM, Thomas Woerner via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hello,
we have made big progress with ansible-freeipa to be able to install
ipa
clients using ansible.
These are the things that we are able to do now:
- Simple installation on more than one machine
- One configuration file (inventory file) per realm (One place for configuration options)
- Authentication types
- Simple use of OTP for installation and update
- More secure (admin password not transferred to the clients)
- Only setting of a variable is needed to enable the use of OTP
- Admin principal and password
- Existing host keytab
- Advanced auto detection (server only, no need to provide domain)
- Repair of broken configurations
- Known limitation: /etc/krb5.keytab can not be repaired
- Working with freeipa-4.4 and up
- RHEL-7.3 and up
- Fedora-25+
- Support for Python3 based freeipa in Fedora-27
The basic usage is explained in the README of the repository: https://github.com/freeipa/ansible-freeipa
I'd like to start a discussion about naming conventions and also about customer and user requests for extensions and changes.
Please give it a try and report issues you are running into.
Regards, Thomas _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.
fedorahosted.org
-- [image: photo] Mark Haney Network Engineer at NeoNova 919-460-3330 <(919)%20460-3330> (opt 1) • mark.haney@neonova.net www.neonova.net https://neonova.net/ https://www.facebook.com/NeoNovaNNS/ https://twitter.com/NeoNova_NNS http://www.linkedin.com/company/neonova-network-services
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedo rahosted.org
-- / Alexander Bokovoy
Mark Haney via FreeIPA-users wrote:
I'm fine with that. Just that IPA's implementation is very much end-user specific. I really doubt you could abstract the playbook enough to make it viable for even a majority of users.
Can you expand on why?
Is it that no playbook could be viable for a majority of users or is it this particular playbook?
The more details the better things can be, or perhaps it's back to the drawing board.
Then again, what do I know, I'm just an engineer with 20+ years experience.
Which is why this review is public, to gain insight from the community.
rob
On Thu, Oct 5, 2017 at 12:41 PM, Alexander Bokovoy <abokovoy@redhat.com mailto:abokovoy@redhat.com> wrote:
On to, 05 loka 2017, Mark Haney via FreeIPA-users wrote: I never said I didn't like. Just that it's not that complicated to setup a playbook to do what you're doing. There is a context to Thomas' message, Mark. We are trying to create a set of playbooks that would be supported by FreeIPA development team going forward. They may or may not become official ones in the Galaxy context but this is what we as an upstream would like to support. They cover right now a client side of install. Server installation would be a next step -- not wrapping around ipa-server-install and ipa-replica-install but making it possible to decouple parts of what ipa-*-install scripts are and reuse them in the playbook context in a more flexible way. This is different to what is done by other playbooks we know which mostly wrap existing scripts' execution. Thus, we are looking for a feedback to these playbooks because we want them to be useful in the field and be supported long term upstream. On Thu, Oct 5, 2017 at 11:17 AM, Thomas Woerner <twoerner@redhat.com <mailto:twoerner@redhat.com>> wrote: Hello Mark, On 10/05/2017 03:57 PM, Mark Haney wrote: > I've been doing this using a custom Ansible playbook for over a month now. > It appears to me to be very variable dependent. > For the full autodetection case you do not need more than the client hostname and the admin password/keytab (with or without OTP). The optional variables are there to alter the default configuration according to the needs. Or did I not get it right? Please be more specific on the things that you do not like. Regards, Thomas > On Thu, Oct 5, 2017 at 7:04 AM, Thomas Woerner via FreeIPA-users < > freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org>> wrote: > >> Hello, >> >> we have made big progress with ansible-freeipa to be able to install ipa >> clients using ansible. >> >> These are the things that we are able to do now: >> >> - Simple installation on more than one machine >> - One configuration file (inventory file) per realm (One place for >> configuration options) >> - Authentication types >> - Simple use of OTP for installation and update >> - More secure (admin password not transferred to the clients) >> - Only setting of a variable is needed to enable the use of OTP >> - Admin principal and password >> - Existing host keytab >> - Advanced auto detection (server only, no need to provide domain) >> - Repair of broken configurations >> - Known limitation: /etc/krb5.keytab can not be repaired >> - Working with freeipa-4.4 and up >> - RHEL-7.3 and up >> - Fedora-25+ >> - Support for Python3 based freeipa in Fedora-27 >> >> The basic usage is explained in the README of the repository: >> https://github.com/freeipa/ansible-freeipa <https://github.com/freeipa/ansible-freeipa> >> >> I'd like to start a discussion about naming conventions and also about >> customer >> and user requests for extensions and changes. >> >> Please give it a try and report issues you are running into. >> >> Regards, >> Thomas >> _______________________________________________ >> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> >> To unsubscribe send an email to freeipa-users-leave@lists. fedorahosted.org <http://fedorahosted.org> >> > > > -- [image: photo] Mark Haney Network Engineer at NeoNova 919-460-3330 <tel:919-460-3330> <(919)%20460-3330> (opt 1) • mark.haney@neonova.net <mailto:mark.haney@neonova.net> www.neonova.net <http://www.neonova.net> <https://neonova.net/> <https://www.facebook.com/NeoNovaNNS/ <https://www.facebook.com/NeoNovaNNS/>> <https://twitter.com/NeoNova_NNS <https://twitter.com/NeoNova_NNS>> <http://www.linkedin.com/company/neonova-network-services <http://www.linkedin.com/company/neonova-network-services>> _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org <mailto:freeipa-users@lists.fedorahosted.org> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org <mailto:freeipa-users-leave@lists.fedorahosted.org> -- / Alexander Bokovoy-- photo Mark Haney Network Engineer at NeoNova
919-460-3330 tel:(919)%20460-3330 (opt 1) • mark.haney@neonova.net mailto:mark.haney@neonova.net** www.neonova.net https://neonova.net/ https://www.facebook.com/NeoNovaNNS/ https://twitter.com/NeoNova_NNS http://www.linkedin.com/company/neonova-network-services
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
On to, 05 loka 2017, Mark Haney wrote:
I'm fine with that. Just that IPA's implementation is very much end-user specific. I really doubt you could abstract the playbook enough to make it viable for even a majority of users.
That's why we want to make it possible to reference individual steps performed by IPA scripts in these playbooks. May be not so individual that each step within 'create DS instance' or 'create KDC instance' can be addressed as that doesn't always make sense, but allowing to mix and match some of most important ones where we have a flexibility to do so.
Then again, what do I know, I'm just an engineer with 20+ years experience.
Me too.
So, from your experience, what is missing in these playbooks?
On Thu, Oct 5, 2017 at 12:41 PM, Alexander Bokovoy abokovoy@redhat.com wrote:
On to, 05 loka 2017, Mark Haney via FreeIPA-users wrote:
I never said I didn't like. Just that it's not that complicated to setup a playbook to do what you're doing.
There is a context to Thomas' message, Mark. We are trying to create a set of playbooks that would be supported by FreeIPA development team going forward. They may or may not become official ones in the Galaxy context but this is what we as an upstream would like to support.
They cover right now a client side of install. Server installation would be a next step -- not wrapping around ipa-server-install and ipa-replica-install but making it possible to decouple parts of what ipa-*-install scripts are and reuse them in the playbook context in a more flexible way. This is different to what is done by other playbooks we know which mostly wrap existing scripts' execution.
Thus, we are looking for a feedback to these playbooks because we want them to be useful in the field and be supported long term upstream.
On Thu, Oct 5, 2017 at 11:17 AM, Thomas Woerner twoerner@redhat.com
wrote:
Hello Mark,
On 10/05/2017 03:57 PM, Mark Haney wrote:
I've been doing this using a custom Ansible playbook for over a month
now.
It appears to me to be very variable dependent.
For the full autodetection case you do not need more than the client hostname and the admin password/keytab (with or without OTP).
The optional variables are there to alter the default configuration according to the needs. Or did I not get it right?
Please be more specific on the things that you do not like.
Regards, Thomas
On Thu, Oct 5, 2017 at 7:04 AM, Thomas Woerner via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hello,
we have made big progress with ansible-freeipa to be able to install
ipa
clients using ansible.
These are the things that we are able to do now:
- Simple installation on more than one machine
- One configuration file (inventory file) per realm (One place for configuration options)
- Authentication types
- Simple use of OTP for installation and update
- More secure (admin password not transferred to the clients)
- Only setting of a variable is needed to enable the use of OTP
- Admin principal and password
- Existing host keytab
- Advanced auto detection (server only, no need to provide domain)
- Repair of broken configurations
- Known limitation: /etc/krb5.keytab can not be repaired
- Working with freeipa-4.4 and up
- RHEL-7.3 and up
- Fedora-25+
- Support for Python3 based freeipa in Fedora-27
The basic usage is explained in the README of the repository: https://github.com/freeipa/ansible-freeipa
I'd like to start a discussion about naming conventions and also about customer and user requests for extensions and changes.
Please give it a try and report issues you are running into.
Regards, Thomas _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.
fedorahosted.org
-- [image: photo] Mark Haney Network Engineer at NeoNova 919-460-3330 <(919)%20460-3330> (opt 1) • mark.haney@neonova.net www.neonova.net https://neonova.net/ https://www.facebook.com/NeoNovaNNS/ https://twitter.com/NeoNova_NNS http://www.linkedin.com/company/neonova-network-services
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedo rahosted.org
-- / Alexander Bokovoy
-- [image: photo] Mark Haney Network Engineer at NeoNova 919-460-3330 <(919)%20460-3330> (opt 1) • mark.haney@neonova.net www.neonova.net https://neonova.net/ https://www.facebook.com/NeoNovaNNS/ https://twitter.com/NeoNova_NNS http://www.linkedin.com/company/neonova-network-services
Thank you for this. I can definitely use this and will provide feedback
-g
On Oct 5, 2017, at 10:45 AM, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On to, 05 loka 2017, Mark Haney wrote: I'm fine with that. Just that IPA's implementation is very much end-user specific. I really doubt you could abstract the playbook enough to make it viable for even a majority of users.
That's why we want to make it possible to reference individual steps performed by IPA scripts in these playbooks. May be not so individual that each step within 'create DS instance' or 'create KDC instance' can be addressed as that doesn't always make sense, but allowing to mix and match some of most important ones where we have a flexibility to do so.
Then again, what do I know, I'm just an engineer with 20+ years experience.
Me too.
So, from your experience, what is missing in these playbooks?
On Thu, Oct 5, 2017 at 12:41 PM, Alexander Bokovoy abokovoy@redhat.com wrote:
On to, 05 loka 2017, Mark Haney via FreeIPA-users wrote:
I never said I didn't like. Just that it's not that complicated to setup a playbook to do what you're doing.
There is a context to Thomas' message, Mark. We are trying to create a set of playbooks that would be supported by FreeIPA development team going forward. They may or may not become official ones in the Galaxy context but this is what we as an upstream would like to support.
They cover right now a client side of install. Server installation would be a next step -- not wrapping around ipa-server-install and ipa-replica-install but making it possible to decouple parts of what ipa-*-install scripts are and reuse them in the playbook context in a more flexible way. This is different to what is done by other playbooks we know which mostly wrap existing scripts' execution.
Thus, we are looking for a feedback to these playbooks because we want them to be useful in the field and be supported long term upstream.
On Thu, Oct 5, 2017 at 11:17 AM, Thomas Woerner twoerner@redhat.com
wrote:
Hello Mark,
On 10/05/2017 03:57 PM, Mark Haney wrote:
I've been doing this using a custom Ansible playbook for over a month
now.
It appears to me to be very variable dependent.
For the full autodetection case you do not need more than the client hostname and the admin password/keytab (with or without OTP).
The optional variables are there to alter the default configuration according to the needs. Or did I not get it right?
Please be more specific on the things that you do not like.
Regards, Thomas
On Thu, Oct 5, 2017 at 7:04 AM, Thomas Woerner via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
> Hello, > > we have made big progress with ansible-freeipa to be able to install
ipa
> clients using ansible. > > These are the things that we are able to do now: > > - Simple installation on more than one machine > - One configuration file (inventory file) per realm (One place for > configuration options) > - Authentication types > - Simple use of OTP for installation and update > - More secure (admin password not transferred to the clients) > - Only setting of a variable is needed to enable the use of OTP > - Admin principal and password > - Existing host keytab > - Advanced auto detection (server only, no need to provide domain) > - Repair of broken configurations > - Known limitation: /etc/krb5.keytab can not be repaired > - Working with freeipa-4.4 and up > - RHEL-7.3 and up > - Fedora-25+ > - Support for Python3 based freeipa in Fedora-27 > > The basic usage is explained in the README of the repository: > https://github.com/freeipa/ansible-freeipa > > I'd like to start a discussion about naming conventions and also about > customer > and user requests for extensions and changes. > > Please give it a try and report issues you are running into. > > Regards, > Thomas > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave@lists.
fedorahosted.org
>
-- [image: photo] Mark Haney Network Engineer at NeoNova 919-460-3330 <(919)%20460-3330> (opt 1) • mark.haney@neonova.net www.neonova.net https://neonova.net/ https://www.facebook.com/NeoNovaNNS/ https://twitter.com/NeoNova_NNS http://www.linkedin.com/company/neonova-network-services
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedo rahosted.org
-- / Alexander Bokovoy
-- [image: photo] Mark Haney Network Engineer at NeoNova 919-460-3330 <(919)%20460-3330> (opt 1) • mark.haney@neonova.net www.neonova.net https://neonova.net/ https://www.facebook.com/NeoNovaNNS/ https://twitter.com/NeoNova_NNS http://www.linkedin.com/company/neonova-network-services
-- / Alexander Bokovoy _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Grace Thompson -
Mark Haney -
Rob Crittenden -
Thomas Woerner