Just some question: Why is ipHost host mapping not supported in SSSD - and deferred, because this is strange when ipServicePort is supported?
Not a 100% necessary feature for our environment, but could be useful for an IP mapping to important administration servers (monitoring, puppet)...
(https://fedorahosted.org/sssd/ticket/359)
Sincerely, PieterB
On Wed, 2012-08-01 at 15:03 +0200, Pieter Baele wrote:
Just some question: Why is ipHost host mapping not supported in SSSD - and deferred, because this is strange when ipServicePort is supported?
Not a 100% necessary feature for our environment, but could be useful for an IP mapping to important administration servers (monitoring, puppet)...
It's deferred because very few deployments use LDAP for host mapping. Most use DNS for this purpose. If you want this feature sooner, we'd be happy to help point you in the right direction to add it yourself.
We have a lot of features on our plates, and we have to prioritize the features that the largest set of people use.
Why? Because there is DNS serving exactly the same purpose. And since sssd is relying on DNS functionality anyway, it does not make any sense wasting the time with ipHosts.
Ondrej
On 08/01/2012 03:03 PM, Pieter Baele wrote:
Just some question: Why is ipHost host mapping not supported in SSSD - and deferred, because this is strange when ipServicePort is supported?
Not a 100% necessary feature for our environment, but could be useful for an IP mapping to important administration servers (monitoring, puppet)...
(https://fedorahosted.org/sssd/ticket/359)
Sincerely, PieterB _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Mmm. No problem. I use LDAP as a Puppet External Node Classifier. Adding device with an IP number to a node configuration is then a logical move.
Always interesting in adding it myself however.
On Wed, Aug 1, 2012 at 3:53 PM, Ondrej Valousek ondrejv@s3group.cz wrote:
Why? Because there is DNS serving exactly the same purpose. And since sssd is relying on DNS functionality anyway, it does not make any sense wasting the time with ipHosts.
Ondrej
On 08/01/2012 03:03 PM, Pieter Baele wrote:
Just some question: Why is ipHost host mapping not supported in SSSD - and deferred, because this is strange when ipServicePort is supported?
Not a 100% necessary feature for our environment, but could be useful for an IP mapping to important administration servers (monitoring, puppet)...
(https://fedorahosted.org/sssd/ticket/359 )
Sincerely, PieterB _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Wed, 2012-08-01 at 18:18 +0200, Pieter Baele wrote:
Mmm. No problem. I use LDAP as a Puppet External Node Classifier. Adding device with an IP number to a node configuration is then a logical move.
Always interesting in adding it myself however.
If you're interested in adding it yourself, you will need to implement the following features:
1) A new set of entry points in the libnss_sss sss_client: /* HOSTS database NSS interface */ enum nss_status _nss_sss_gethostbyname_r(const char *name, struct hostent *result, char *buffer, size_t buflen, int *errnop, int *h_errnop); enum nss_status _nss_sss_gethostbyname2_r(const char *name, int af, struct hostent *result, char *buffer, size_t buflen, int *errnop, int *h_errnop); enum nss_status _nss_sss_gethostbyaddr_r(const void *addr, socklen_t len, int af, struct hostent *result, char *buffer, size_t buflen, int *errnop, int *h_errnop); enum nss_status _nss_sss_sethostent(void); enum nss_status _nss_sss_gethostent_r(struct hostent *result, char *buffer, size_t buflen, int *errnop, int *h_errnop); enum nss_status _nss_sss_endhostent(void);
2) A new set of routines to check the cache in the NSS responder, as well as a wire protocol between the responder and sss_client.
3) A data provider implementation for the LDAP and (ideally) Proxy providers.
Please read https://fedorahosted.org/sssd/wiki/DevelTutorials and join #sssd on irc.freenode.net if you want to tackle this. We'll help you get started.
Just while thinking about it... Right now we use Bind with a plugin to store DNS zones in ldap, right? So this could be actually quite a nice way to do it quicker. But yes DNS zones are store in different format, not using ipHost objectclasses.
Maybe implementing this would be actually contra productive as it would mean there would be 2 ways to store the same thing in ldap - a mess.
Ondrej
On 08/01/2012 06:31 PM, Stephen Gallagher wrote:
On Wed, 2012-08-01 at 18:18 +0200, Pieter Baele wrote:
Mmm. No problem. I use LDAP as a Puppet External Node Classifier. Adding device with an IP number to a node configuration is then a logical move.
Always interesting in adding it myself however.
If you're interested in adding it yourself, you will need to implement the following features:
- A new set of entry points in the libnss_sss sss_client:
/* HOSTS database NSS interface */ enum nss_status _nss_sss_gethostbyname_r(const char *name, struct hostent *result, char *buffer, size_t buflen, int *errnop, int *h_errnop); enum nss_status _nss_sss_gethostbyname2_r(const char *name, int af, struct hostent *result, char *buffer, size_t buflen, int *errnop, int *h_errnop); enum nss_status _nss_sss_gethostbyaddr_r(const void *addr, socklen_t len, int af, struct hostent *result, char *buffer, size_t buflen, int *errnop, int *h_errnop); enum nss_status _nss_sss_sethostent(void); enum nss_status _nss_sss_gethostent_r(struct hostent *result, char *buffer, size_t buflen, int *errnop, int *h_errnop); enum nss_status _nss_sss_endhostent(void);
- A new set of routines to check the cache in the NSS responder, as
well as a wire protocol between the responder and sss_client.
- A data provider implementation for the LDAP and (ideally) Proxy
providers.
Please read https://fedorahosted.org/sssd/wiki/DevelTutorials and join #sssd on irc.freenode.net if you want to tackle this. We'll help you get started.
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Thu, Aug 2, 2012 at 10:28 AM, Ondrej Valousek ondrej.valousek@s3group.com wrote:
Maybe implementing this would be actually contra productive as it would mean there would be 2 ways to store the same thing in ldap - a mess.
Ondrej
I don't know ... it serves a different purpose.
One scenario: There a lot of problems and the DNS server (appliance) is down.... because it's running on Windows ;-) but you've some really important - clusters or servers, a lot of settings not using IP addresses but DNS names (as it should be...)
If you then have host entries cached by sssd, you still *can* resolve the hosts... without having to distribute /etc/hosts files with a configuration mgmt system.
-- PieterB
I don't know ... it serves a different purpose.
One scenario: There a lot of problems and the DNS server (appliance) is down.... because it's running on Windows ;-) but you've some really important - clusters or servers, a lot of settings not using IP addresses but DNS names (as it should be...)
If you then have host entries cached by sssd, you still *can* resolve the hosts... without having to distribute /etc/hosts files with a configuration mgmt system.
-- PieterB
You can have multiple redundant dns servers and /etc/resolv.conf can (and is by default) be managed by the dhcp client. NIS hosts table is obsoleted as well as the whole NIS concept. Moreover DNS is a well defined standard. Just compare it with Windows and NetBIOS, same thing, they got rid of it in favour of DNS.
Ondrej
You can have multiple redundant dns servers and /etc/resolv.conf can (and is by default) be managed by the dhcp client.
So true :-) DHCP is not used on our server network...
NIS hosts table is obsoleted as well as the whole NIS concept.
And what's the best alternative for Access Control then? groupdn ?
Moreover DNS is a well defined standard. Just compare it with Windows and NetBIOS, same thing, they got rid of it in favour of DNS.
Ondrej
I wish I had some hooks into DNS in our environment. Would make provisioning a lot easier...
So true :-) DHCP is not used on our server network...
Too bad. DHCP is good and powerful - use reservations if you like static IPs (like me) or configure dhclient to ignore IP provided by the dhcp server.
And what's the best alternative for Access Control then? groupdn ?
What do you mean by access control? Filesystem ACLs or machine access control? You could use Netgroups (supported by sssd) for the latter one.
I wish I had some hooks into DNS in our environment. Would make provisioning a lot easier...
There we go :-) . This is actually why you asked about ipHosts.... Ondrej
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Thu, 2012-08-02 at 12:34 +0200, Pieter Baele wrote:
You can have multiple redundant dns servers and /etc/resolv.conf can (and is by default) be managed by the dhcp client.
So true :-) DHCP is not used on our server network...
NIS hosts table is obsoleted as well as the whole NIS concept.
And what's the best alternative for Access Control then? groupdn ?
Moreover DNS is a well defined standard. Just compare it with Windows and NetBIOS, same thing, they got rid of it in favour of DNS.
Ondrej
I wish I had some hooks into DNS in our environment. Would make provisioning a lot easier...
FWIW if you use FreeIPA you will be able to join domains there and use DNS Dynamic Updates to update the DNS when some IP address change letting hosts manage themselves mostly.
Simo.
On Thu, 2012-08-02 at 10:28 +0200, Ondrej Valousek wrote:
Just while thinking about it... Right now we use Bind with a plugin to store DNS zones in ldap, right? So this could be actually quite a nice way to do it quicker. But yes DNS zones are store in different format, not using ipHost objectclasses.
Maybe implementing this would be actually contra productive as it would mean there would be 2 ways to store the same thing in ldap - a mess.
If we are talking about a FreeIPA scenario then what we can do there is to have the ipHost entries be generated via the compat plugin, so you'd manage the data in the DNs tables and it would be exported also as a NIS host map without having to manage 2 tables. However I can also see how people may not really want to have DNS and ipHosts be copies and may want to have independent entries ...
Simo.
On Thu, Aug 2, 2012 at 1:45 PM, Ondrej Valousek ondrejv@s3group.cz wrote:
So true :-) DHCP is not used on our server network...
Too bad. DHCP is good and powerful - use reservations if you like static IPs (like me) or configure dhclient to ignore IP provided by the dhcp server.
I know. Big enterprises :-)
And what's the best alternative for Access Control then? groupdn ?
What do you mean by access control? Filesystem ACLs or machine access control? You could use Netgroups (supported by sssd) for the latter one.
Netgroups.... NIS, you mentioned it being outdated.
I wish I had some hooks into DNS in our environment. Would make provisioning a lot easier...
There we go :-) . This is actually why you asked about ipHosts.... Ondrej
Not really, makes no difference, because DNS and DHCP is being managed by another team
FWIW if you use FreeIPA you will be able to join domains there and use DNS Dynamic Updates to update the DNS when some IP address change letting hosts manage themselves mostly.
Simo.
I tested FreeIPA thoroughly. The problem is we want the same domain on the Linux servers, and I want to use the AD Kerberos as authentication provider. But the freeipa client always resolves to the KDC of AD, what is causing a lot of trouble. The other issue is the DNS is a seperate appliance managed by another team.
So I went with OpenLDAP.
And on the client LDAP as ID provider Kerberos on AD as auth provider
Netgroups.... NIS, you mentioned it being outdated.
NIS != Netgroups Netgroup is just a table (just like passwd or group) to be provided either via files, NIS or sssd. But yes, it is maybe somewhat outdates, too. You could probably achieve the same results using different ldap containers for users...
Ondrej
NIS != Netgroups Netgroup is just a table (just like passwd or group) to be provided either via files, NIS or sssd. But yes, it is maybe somewhat outdates, too. You could probably achieve the same results using different ldap containers for users...
Ondrej
Ok. so "provided using files, NIS or sssd" But with sssd you mean an LDAP backend I suppose? And that's the nis objectClasses from my rfc2307bis schema....
thx a lot!
-- PieterB
Ok. so "provided using files, NIS or sssd" But with sssd you mean an LDAP backend I suppose? And that's the nis objectClasses from my rfc2307bis schema....
yes. ldap backend w/ rfc2307 schema
thx a lot!
-- PieterB _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 08/02/2012 08:53 AM, Pieter Baele wrote:
FWIW if you use FreeIPA you will be able to join domains there and use DNS Dynamic Updates to update the DNS when some IP address change letting hosts manage themselves mostly.
Simo.
I tested FreeIPA thoroughly. The problem is we want the same domain on the Linux servers, and I want to use the AD Kerberos as authentication provider. But the freeipa client always resolves to the KDC of AD, what is causing a lot of trouble. The other issue is the DNS is a seperate appliance managed by another team.
So I went with OpenLDAP.
And on the client LDAP as ID provider Kerberos on AD as auth provider
Just FYI the 3.0 is supposed to address this scenario in the following way.
You make the AD your source of the DNS info You add entries into AD DNS for the IPA servers so that they can resolve themselves You install clients with the argument that will tell the SSSD the names of the IPA servers and with the argument to not perform any DNS discovery.
For the authentication you can use AD trust feature or sync users from AD to IPA. I suspect that you already sync accounts to OpenLDAP in some way.
SSSD can be told not to resolve DNS and use the fixed list of servers even now in 1.8. It is the ipa-client that always sticks DNS resolution configuration into the SSSD config but since you use the custom sssd configuration anyways you might very well just remove the _srv_ from the SSSD config using a simple script. This part will be fixed in 3.0 but you have a workaround to try using freeipa 2.2 and adjusted SSSD config.
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
I tested FreeIPA thoroughly.
<cut>
So I went with OpenLDAP.
And on the client LDAP as ID provider Kerberos on AD as auth provider
Just FYI the 3.0 is supposed to address this scenario in the following way.
You make the AD your source of the DNS info You add entries into AD DNS for the IPA servers so that they can resolve themselves You install clients with the argument that will tell the SSSD the names of the IPA servers and with the argument to not perform any DNS discovery.
For the authentication you can use AD trust feature or sync users from AD to IPA. I suspect that you already sync accounts to OpenLDAP in some way.
SSSD can be told not to resolve DNS and use the fixed list of servers even now in 1.8. It is the ipa-client that always sticks DNS resolution configuration into the SSSD config but since you use the custom sssd configuration anyways you might very well just remove the _srv_ from the SSSD config using a simple script. This part will be fixed in 3.0 but you have a workaround to try using freeipa 2.2 and adjusted SSSD config.
Thx for the info.
FreeIPA will be the next thing, and I believe in it, but not yet. Problem: as LDAP (/IDM) is a very important part of infrastructure, support is needed in a big company.
I can go without support for some months but....
Also: - waiting on the audit part and some other features - running on EL6 instead of Fedora - ...
On Fri, 2012-08-03 at 08:18 +0200, Pieter Baele wrote:
Thx for the info.
FreeIPA will be the next thing, and I believe in it, but not yet. Problem: as LDAP (/IDM) is a very important part of infrastructure, support is needed in a big company.
I can go without support for some months but....
Also:
- waiting on the audit part and some other features
- running on EL6 instead of Fedora
- ...
For the record, FreeIPA v3 is expected to ship in RHEL 6.4
FreeIPA will be the next thing, and I believe in it, but not yet. Problem: as LDAP (/IDM) is a very important part of infrastructure, support is needed in a big company.
I can go without support for some months but....
Also:
- waiting on the audit part and some other features
- running on EL6 instead of Fedora
- ...
For the record, FreeIPA v3 is expected to ship in RHEL 6.4
Technical Preview?
It is not gonna be a paid addon? (as Load balancing, clustering, XFS...)
On Fri, Aug 03, 2012 at 02:52:24PM +0200, Pieter Baele wrote:
FreeIPA will be the next thing, and I believe in it, but not yet. Problem: as LDAP (/IDM) is a very important part of infrastructure, support is needed in a big company.
I can go without support for some months but....
Also:
- waiting on the audit part and some other features
- running on EL6 instead of Fedora
- ...
For the record, FreeIPA v3 is expected to ship in RHEL 6.4
Technical Preview?
It is not gonna be a paid addon? (as Load balancing, clustering, XFS...)
IPA has been a fully supported part of core RHEL since 6.2: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/6.2...
Quoting from the 6.2 release notes:
"These services have been present as a Technology Preview in previous Red Hat Enterprise Linux 6 releases. With this release, identity management has been promoted to fully supported."
On 08/03/2012 08:52 AM, Pieter Baele wrote:
FreeIPA will be the next thing, and I believe in it, but not yet. Problem: as LDAP (/IDM) is a very important part of infrastructure, support is needed in a big company.
I can go without support for some months but....
Also:
- waiting on the audit part and some other features
- running on EL6 instead of Fedora
- ...
For the record, FreeIPA v3 is expected to ship in RHEL 6.4
Technical Preview?
It is not gonna be a paid addon? (as Load balancing, clustering, XFS...)
It is part of RHEL and is refined as we go. We support it since 6.2 with no extra fee. 6.3 got an update. 6.4 targeted functionality is in works.
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Ondrej Valousek -
Ondrej Valousek -
Pieter Baele -
Simo Sorce -
Stephen Gallagher