[SSSD] ipv6?
Is sssd IPv6 aware/ready? I notice that despite the fact that my network is IPv6 capable and my DNS returns records, sssd seems to prefer IPv4 connections to LDAP and kerberos, etc. Is there a config and/or build option I'm just missing? b. signature.asc Description: This is a digitally signed message part ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
[SSSD] should not return "x" for password when there is no shadow information
I was going to file this as a bug in Trac but it's not clear how one creates an account there. Witness the difference between nss_ldap and sssd (0.7.1) with regard to the password in passwd map entries: nss_ldap $ getent passwd brian brian:*:1001:1001:Brian J. Murrell:/home/brian:/bin/bash sssd $ getent passwd brian brian:x:1001:1001:Brian J. Murrell:/home/brian:/bin/bash Notice that sssd is reporting an "x" in the password field when nss_ldap is reporting an "*". The reason nss_ldap is reporting an "*" is because there is no password information for this user in LDAP because this user authenticates with kerberos. The way nss_ldap knows whether to return an "x" or an "*" for the password entry is based on whether the ldap entry has a shadowAccount object class defined. It all makes sense doesn't it? So, sssd needs to be doing the same thing. The reason is that the pam_unix pam module's account personality does sanity checks on the shadow information (password expired, going to expire?, etc.) when the passwd entry says there is shadow information by specifying "x" in the password field. If there is no shadow information, which there is not when there is no authentication data in ldap, then the sssd NSS module should be returning something other than an "x". I'd be happy to test a patch, or even do the hacking myself if somebody wants to point me to where this "hardcoding" of the "x" is. Cheers, b. signature.asc Description: This is a digitally signed message part ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] domain vs provider in SSSD
Jenny Galipeau wrote: > Stephen Gallagher wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 11/02/2009 12:43 AM, David O'Brien wrote: >> >>> From what I've read, these two are equivalent. Should I be using one >>> term in one place and the other elsewhere or doesn't it matter? >>> >>> >> >> Domains and providers are NOT the same thing. A domain is a conceptual >> object that contains one or more providers. For example, an IPA domain >> is actually a domain with an ID provider of LDAP and an authentication >> provider of Kerberos. >> >> These terms must not be used interchangeably. In some communications, we >> refer to an "LDAP domain", but in these examples, we're usually talking >> about a domain that uses LDAP for all the provider types (ID, AUTH, >> ACCESS and CHPASS) >> >> A provider on the other hand is a connection to the remote (or local) >> data store. >> > I would have said exactly what Stephen said, here's an example sssd.conf > with two LDAP Domains, just so you can visualize what it's configuration > would look like ... Examples are always good, thanks :) > > [sssd] > config_file_version = 2 I didn't see config_file_version documented anywhere... is that anything like the version number for BIND config files, where you inc. the version when you make changes and then restart named to re-read the file? Everything else makes sense, thanks. /dob > domains = EXAMPLE1.COM, EXAMPLE2.COM > reconnection_retries = 3 > services = nss, pam > > [nss] > debug_level = 4 > filter_groups = root > filter_users = root > reconnection_retries = 3 > > [pam] > reconnection_retries = 3 > > [domain/EXAMPLE1.COM] > cache_credentials = TRUE > enumerate = TRUE > id_provider = ldap > ldap_group_search_base = ou=groups,dc=example1,dc=com > ldap_uri = ldap://hostname.example1.com:389 > ldap_user_search_base = ou=people,dc=example1,dc=com > max_id = 1010 > min_id = 1000 > > [domain/EXAMPLE2.COM] > cache_credentials = TRUE > enumerate = TRUE > id_provider = ldap > ldap_group_search_base = ou=groups,dc=example2,dc=com > ldap_uri = ldap://hostname.example2.com:11329 > ldap_user_search_base = ou=people,dc=example2,dc=com > max_id = 2010 > min_id = 2000 > >> - -- Stephen Gallagher >> RHCE 804006346421761 >> >> Delivering value year after year. >> Red Hat ranks #1 in value among software vendors. >> http://www.redhat.com/promo/vendor/ >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.9 (GNU/Linux) >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAkruzR4ACgkQeiVVYja6o6OPIgCdGru/NkCsjk/zII3Ik6TnTkSM >> pVEAoJhNYi23F5vh/rwO1oKs+QDts5fb >> =McyP >> -END PGP SIGNATURE- >> ___ >> sssd-devel mailing list >> sssd-devel@lists.fedorahosted.org >> https://fedorahosted.org/mailman/listinfo/sssd-devel >> >> > > -- David O'Brien Red Hat Asia Pacific +61 7 3514 8189 http://freeipa.org/page/DocumentationPortal http://git.fedorahosted.org/git/ipadocs.git "The most valuable of all talents is that of never using two words when one will do." Thomas Jefferson ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] domain vs provider in SSSD
Stephen Gallagher wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/02/2009 12:43 AM, David O'Brien wrote: >> From what I've read, these two are equivalent. Should I be using one >> term in one place and the other elsewhere or doesn't it matter? >> > > Domains and providers are NOT the same thing. A domain is a conceptual > object that contains one or more providers. For example, an IPA domain > is actually a domain with an ID provider of LDAP and an authentication > provider of Kerberos. ok, this is good. That helps a lot, thanks. > > These terms must not be used interchangeably. In some communications, we > refer to an "LDAP domain", but in these examples, we're usually talking > about a domain that uses LDAP for all the provider types (ID, AUTH, > ACCESS and CHPASS) > > A provider on the other hand is a connection to the remote (or local) > data store. > > - -- > Stephen Gallagher > RHCE 804006346421761 > > Delivering value year after year. > Red Hat ranks #1 in value among software vendors. > http://www.redhat.com/promo/vendor/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkruzR4ACgkQeiVVYja6o6OPIgCdGru/NkCsjk/zII3Ik6TnTkSM > pVEAoJhNYi23F5vh/rwO1oKs+QDts5fb > =McyP > -END PGP SIGNATURE- -- David O'Brien Red Hat Asia Pacific +61 7 3514 8189 http://freeipa.org/page/DocumentationPortal http://git.fedorahosted.org/git/ipadocs.git "The most valuable of all talents is that of never using two words when one will do." Thomas Jefferson ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] start adding an attribute map for generic attributes
On Fri, 2009-10-30 at 08:05 -0400, Stephen Gallagher wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/30/2009 04:44 AM, Sumit Bose wrote:
> > On Thu, Oct 29, 2009 at 06:20:48PM -0400, Simo Sorce wrote:
> >> While adding infrastructure to use the USN counter for enumerations I
> >> found that sdap_id_map is not really a good name as the map represent a
> >> generic attribute map. This patch renames the structure and adds some
> >> generic infrastructure for non user/group specific attribute mappings.
> >>
> >> This infrastructure is not used yet, will be in the next patches.
> >>
> >
> > I expect that the updates to config/etc/sssd.api.d/sssd-ldap.conf are in
> > the next patch :-), but they should be in this one. Otherwise the patch
> > works fine for me.
>
> Agreed, please include the API config changes in this patch.
Attached new patch with changes to sssd-ldap.conf
--
Simo Sorce * Red Hat, Inc * New York
>From a8b131d3d1856d73fe20885a56110c97e35ab1ea Mon Sep 17 00:00:00 2001
From: Simo Sorce
Date: Thu, 29 Oct 2009 18:16:59 -0400
Subject: [PATCH] Rename sdap_id_map to sdap_attr_map
Also start adding some infrastructure to use the USN counter when available.
In particular add a place to add generic attrs mapping, ie attributes that are
neither user nor group specific.
---
server/config/etc/sssd.api.d/sssd-ldap.conf |2 +
server/db/sysdb.h |3 ++
server/providers/ipa/ipa_common.c | 17 ++-
server/providers/ldap/ldap_common.c | 40 +++
server/providers/ldap/ldap_id.c |2 +-
server/providers/ldap/sdap.c| 10 +++---
server/providers/ldap/sdap.h| 22 ++-
7 files changed, 75 insertions(+), 21 deletions(-)
diff --git a/server/config/etc/sssd.api.d/sssd-ldap.conf b/server/config/etc/sssd.api.d/sssd-ldap.conf
index 1c094f6..af1e66c 100644
--- a/server/config/etc/sssd.api.d/sssd-ldap.conf
+++ b/server/config/etc/sssd.api.d/sssd-ldap.conf
@@ -16,6 +16,8 @@ krb5_kdcip = str, None
krb5_realm = str, None
ldap_krb5_keytab = str, None
ldap_krb5_init_creds = bool, None
+ldap_entry_usn = str, None
+ldap_rootdse_last_usn = str, None
[provider/ldap/id]
ldap_search_timeout = int, None
diff --git a/server/db/sysdb.h b/server/db/sysdb.h
index 72f56db..642cc30 100644
--- a/server/db/sysdb.h
+++ b/server/db/sysdb.h
@@ -75,6 +75,9 @@
#define SYSDB_ORIG_DN "originalDN"
#define SYSDB_ORIG_MODSTAMP "originalModifyTimestamp"
+#define SYSDB_USN "entryUSN"
+#define SYSDB_HIGH_USN "highestUSN"
+
#define SYSDB_NEXTID_FILTER "("SYSDB_NEXTID"=*)"
#define SYSDB_UC "objectclass="SYSDB_USER_CLASS
diff --git a/server/providers/ipa/ipa_common.c b/server/providers/ipa/ipa_common.c
index 3f4d25d..a571aea 100644
--- a/server/providers/ipa/ipa_common.c
+++ b/server/providers/ipa/ipa_common.c
@@ -63,7 +63,12 @@ struct dp_option ipa_def_ldap_opts[] = {
{ "krb5_realm", DP_OPT_STRING, NULL_STRING, NULL_STRING }
};
-struct sdap_id_map ipa_user_map[] = {
+struct sdap_attr_map ipa_attr_map[] = {
+{ "ldap_entry_usn", "entryUSN", SYSDB_USN, NULL },
+{ "ldap_rootdse_last_usn", "lastUSN", SYSDB_HIGH_USN, NULL }
+};
+
+struct sdap_attr_map ipa_user_map[] = {
{ "ldap_user_object_class", "posixAccount", SYSDB_USER_CLASS, NULL },
{ "ldap_user_name", "uid", SYSDB_NAME, NULL },
{ "ldap_user_pwd", "userPassword", SYSDB_PWD, NULL },
@@ -89,7 +94,7 @@ struct sdap_id_map ipa_user_map[] = {
{ "ldap_pwd_attribute", "pwdAttribute", SYSDB_PWD_ATTRIBUTE, NULL }
};
-struct sdap_id_map ipa_group_map[] = {
+struct sdap_attr_map ipa_group_map[] = {
{ "ldap_group_object_class", "posixGroup", SYSDB_GROUP_CLASS, NULL },
{ "ldap_group_name", "cn", SYSDB_NAME, NULL },
{ "ldap_group_pwd", "userPassword", SYSDB_PWD, NULL },
@@ -354,6 +359,14 @@ int ipa_get_id_options(struct ipa_options *ipa_opts,
SDAP_GROUP_SEARCH_BASE)));
}
+ret = sdap_get_map(ipa_opts->id, cdb, conf_path,
+ ipa_attr_map,
+ SDAP_AT_GENERAL,
+ &ipa_opts->id->gen_map);
+if (ret != EOK) {
+goto done;
+}
+
ret = sdap_get_map(ipa_opts->id,
cdb, conf_path,
ipa_user_map,
diff --git a/server/providers/ldap/ldap_common.c b/server/providers/ldap/ldap_common.c
index b117d02..f7cdf75 100644
--- a/server/providers/ldap/ldap_common.c
+++ b/server/providers/ldap/ldap_common.c
@@ -56,7 +56,22 @@ struct dp_option default_basic_opts[] = {
{ "krb5_realm", DP_OPT_STRING, NULL_STRING, NULL_STRING }
};
-struct sdap_id_map rfc2307_user_map[] = {
+struct sdap_attr_map generic_attr_map[] = {
+{ "ldap_entry_usn", NULL, SYSDB_USN, NULL },
+{ "ldap_rootdse_last_usn", NULL, SYSDB_USN, NULL }
+};
+
+struct sdap_attr_map gen_ipa_attr_map[] = {
+{ "ldap_entry_usn", "entryUSN", SYSDB_USN, NULL },
+{ "ld
Re: [SSSD] [PATCH] add sysdb_delete_recursive request to sysdb API
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/02/2009 04:01 PM, Simo Sorce wrote: > On Mon, 2009-11-02 at 14:06 +0100, Sumit Bose wrote: Looks good to me, I have only a minor nitpick, shouldn't the >> ENOENT error in sysdb_delete_recursive_op_done() be fatal ? Given it should never happen, does it make sense to allow to >> continue ? Simo. >>> >>> ok, it is now fatal as all other errors >>> >>> bye, >>> Sumit >> >> This new version adds a missing return after a tevent_req_done() call. > > ACK > > Simo. Pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkrvT+EACgkQeiVVYja6o6Ok/wCfc9TRwKdjhMfq/xp0spaDzXCc ZHUAnjE3cZK/49b8cYLPVen41Z14U/d6 =6iMa -END PGP SIGNATURE- ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCHES] Fail over helper functions and reference counting wrappers
On Fri, 2009-10-30 at 14:07 +0100, Martin Nagy wrote: > Hi, > attached are patches needed for the fail over functionality. The > service discovery is not there yet, I want to hold of with that until > I > have at least a basic SRV-based one so I can test it properly. It's > possible that we will discover something missing when we'll be > integrating it into providers. Together with Steven we at least > figured > out that for ldapi:// for example we need an "extra" treatment. So I > made the name resolution optional and you can provide a server with > user data. The commit messages and header files should explain it > better. Just a formal NACK. We discussed changes on IRC. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] add sysdb_delete_recursive request to sysdb API
On Mon, 2009-11-02 at 14:06 +0100, Sumit Bose wrote: > > > Looks good to me, I have only a minor nitpick, shouldn't the > ENOENT > > > error in sysdb_delete_recursive_op_done() be fatal ? > > > > > > Given it should never happen, does it make sense to allow to > continue ? > > > > > > Simo. > > > > > > > ok, it is now fatal as all other errors > > > > bye, > > Sumit > > This new version adds a missing return after a tevent_req_done() call. ACK Simo. -- Simo Sorce * Red Hat, Inc * New York ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] Make debug message less irritating.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/02/2009 11:26 AM, Simo Sorce wrote: > On Mon, 2009-11-02 at 14:36 +0100, Sumit Bose wrote: >> Hi, >> >> this patch should fix #251. > > ACK > > Simo. > Pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkrvQhwACgkQeiVVYja6o6PaMwCePmeq/ZFNWMw83tRYDmT96kwe Rx4AnjnoG+VNSC6gzplLUWnN0rYww7u4 =PxGW -END PGP SIGNATURE- ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] set ipa_hostname if not given in config file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/02/2009 11:11 AM, Simo Sorce wrote: > On Mon, 2009-11-02 at 14:47 +0100, Sumit Bose wrote: >> Hi, >> >> I find this patch useful. If IPA_HOSTNAME is found to be NULL later on >> in the code you can simply assume an error and don't have to call >> gethostname again and again. > > Looks good to me, > ACK. > > Simo. > Pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkrvQhMACgkQeiVVYja6o6OEOgCfeTzcG7RE1DgBOcvTV2goxrIW iTwAn0in3c/OOyc/+k+R2734EAPOij4s =7f2M -END PGP SIGNATURE- ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] Add support for option descriptions to SSSDConfig API
On 10/30/2009 03:28 PM, Stephen Gallagher wrote:
> Addresses https://fedorahosted.org/sssd/ticket/242 related to
> authconfig integration
>
>
> Note: this applies atop my previous patch "Make config_file_version a
> hidden setting in SSSDConfig API" which is still pending review.
>
>
>
>
>
> ___
> sssd-devel mailing list
> sssd-devel@lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel
New patches (includes the config_file_version patch that has not been
reviewed)
0001: Make config_file_version a hidden option. It should not be
configurable, so hide it from the api schema spec.
0002: Remove the magic_private_groups option from the api schema spec.
This was overlooked somehow.
0003: New version of the descriptions patch. This is a nasty hack that
simo and I decided on as "good enough" in SSSD 1.0. We will store the
translatable strings inside the SSSDConfig.py file as a lookup dictionary.
0004: Enable translations on these strings.
--
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
From 64404380a7b9d8c745b20927d2a1f34c9181e014 Mon Sep 17 00:00:00 2001
From: Stephen Gallagher
Date: Thu, 29 Oct 2009 14:17:22 -0400
Subject: [PATCH 1/4] Make config_file_version a hidden setting in SSSDConfig API
The config_file_version should never be changed by the API, so we
will hide the option inside the SSSDConfig API and remove it from
the schema.
---
server/config/SSSDConfig.py | 12
server/config/SSSDConfigTest.py | 26 ++
server/config/etc/sssd.api.conf |1 -
3 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/server/config/SSSDConfig.py b/server/config/SSSDConfig.py
index 07e967b..578f292 100644
--- a/server/config/SSSDConfig.py
+++ b/server/config/SSSDConfig.py
@@ -199,12 +199,20 @@ class SSSDService:
# Set up the service object with any known defaults
self.options = {}
+# Include a list of hidden options
+self.hidden_options = []
+
# Set up default options for all services
self.options.update(self.schema.get_defaults('service'))
# Set up default options for this service
self.options.update(self.schema.get_defaults(self.name))
+# For the [sssd] service, force the config file version
+if servicename == 'sssd':
+self.options['config_file_version'] = 2
+self.hidden_options.append('config_file_version')
+
def get_name(self):
return self.name
@@ -228,6 +236,10 @@ class SSSDService:
option_schema = self.schema.get_option(self.name, optionname)
elif self.schema.has_option('service', optionname):
option_schema = self.schema.get_option('service', optionname)
+elif optionname in self.hidden_options:
+# Set this option and do not add it to the list of changeable
values
+self.options[optionname] = value
+return
else:
raise NoOptionError('Section [%s] has no option [%s]' %
(self.name, optionname))
diff --git a/server/config/SSSDConfigTest.py b/server/config/SSSDConfigTest.py
index 0baa912..96a650a 100644
--- a/server/config/SSSDConfigTest.py
+++ b/server/config/SSSDConfigTest.py
@@ -30,8 +30,6 @@ class SSSDConfigTestValid(unittest.TestCase):
sssd_service = sssdconfig.get_service('sssd')
service_opts = sssd_service.list_options()
-self.assertTrue('config_file_version' in service_opts.keys())
-self.assertEquals(sssd_service.get_option('config_file_version'), 2)
self.assertTrue('services' in service_opts.keys())
service_list = sssd_service.get_option('services')
@@ -59,9 +57,6 @@ class SSSDConfigTestValid(unittest.TestCase):
self.assertTrue('reconnection_retries' in new_options)
self.assertEquals(new_options['reconnection_retries'][0], int)
-self.assertTrue('config_file_version' in new_options)
-self.assertEquals(new_options['config_file_version'][0], int)
-
self.assertTrue('services' in new_options)
self.assertEquals(new_options['debug_level'][0], int)
@@ -201,7 +196,6 @@ class SSSDConfigTestSSSDService(unittest.TestCase):
options = service.list_options()
control_list = [
-'config_file_version',
'services',
'domains',
'timeout',
@@ -229,23 +223,23 @@ class SSSDConfigTestSSSDService(unittest.TestCase):
'Option [%s] unexpectedly found' %
option)
-self.assertTrue(type(options['config_file_version']) == tuple,
+self.assertTrue(type(options['reconnection_retries']) == tuple,
"Option values should be a tuple")
-self.assertTrue(options['config_file_version'][0] =
Re: [SSSD] [PATCH] Make debug message less irritating.
On Mon, 2009-11-02 at 14:36 +0100, Sumit Bose wrote: > Hi, > > this patch should fix #251. ACK Simo. -- Simo Sorce * Red Hat, Inc * New York ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] set ipa_hostname if not given in config file
On Mon, 2009-11-02 at 14:47 +0100, Sumit Bose wrote: > Hi, > > I find this patch useful. If IPA_HOSTNAME is found to be NULL later on > in the code you can simply assume an error and don't have to call > gethostname again and again. Looks good to me, ACK. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] domain vs provider in SSSD
Stephen Gallagher wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/02/2009 12:43 AM, David O'Brien wrote: > >> From what I've read, these two are equivalent. Should I be using one >> term in one place and the other elsewhere or doesn't it matter? >> >> > > Domains and providers are NOT the same thing. A domain is a conceptual > object that contains one or more providers. For example, an IPA domain > is actually a domain with an ID provider of LDAP and an authentication > provider of Kerberos. > > These terms must not be used interchangeably. In some communications, we > refer to an "LDAP domain", but in these examples, we're usually talking > about a domain that uses LDAP for all the provider types (ID, AUTH, > ACCESS and CHPASS) > > A provider on the other hand is a connection to the remote (or local) > data store. > I would have said exactly what Stephen said, here's an example sssd.conf with two LDAP Domains, just so you can visualize what it's configuration would look like ... [sssd] config_file_version = 2 domains = EXAMPLE1.COM, EXAMPLE2.COM reconnection_retries = 3 services = nss, pam [nss] debug_level = 4 filter_groups = root filter_users = root reconnection_retries = 3 [pam] reconnection_retries = 3 [domain/EXAMPLE1.COM] cache_credentials = TRUE enumerate = TRUE id_provider = ldap ldap_group_search_base = ou=groups,dc=example1,dc=com ldap_uri = ldap://hostname.example1.com:389 ldap_user_search_base = ou=people,dc=example1,dc=com max_id = 1010 min_id = 1000 [domain/EXAMPLE2.COM] cache_credentials = TRUE enumerate = TRUE id_provider = ldap ldap_group_search_base = ou=groups,dc=example2,dc=com ldap_uri = ldap://hostname.example2.com:11329 ldap_user_search_base = ou=people,dc=example2,dc=com max_id = 2010 min_id = 2000 > - -- > Stephen Gallagher > RHCE 804006346421761 > > Delivering value year after year. > Red Hat ranks #1 in value among software vendors. > http://www.redhat.com/promo/vendor/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkruzR4ACgkQeiVVYja6o6OPIgCdGru/NkCsjk/zII3Ik6TnTkSM > pVEAoJhNYi23F5vh/rwO1oKs+QDts5fb > =McyP > -END PGP SIGNATURE- > ___ > sssd-devel mailing list > sssd-devel@lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/sssd-devel > > -- Jenny Galipeau Principal Software QA Engineer Red Hat, Inc. Security Engineering Register now for Red Hat Virtual Experience, December 9. Enterprise Linux, virtualization, cloud, and more. http://www.redhat.com/virtualexperience Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
[SSSD] [PATCH] set ipa_hostname if not given in config file
Hi,
I find this patch useful. If IPA_HOSTNAME is found to be NULL later on
in the code you can simply assume an error and don't have to call
gethostname again and again.
bye,
Sumit
>From d87db5a63e0737cc5da955c6679a410350939419 Mon Sep 17 00:00:00 2001
From: Sumit Bose
Date: Wed, 28 Oct 2009 13:09:51 +0100
Subject: [PATCH] set ipa_hostname if not given in config file
---
server/providers/ipa/ipa_common.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/server/providers/ipa/ipa_common.c
b/server/providers/ipa/ipa_common.c
index d324970..3f4d25d 100644
--- a/server/providers/ipa/ipa_common.c
+++ b/server/providers/ipa/ipa_common.c
@@ -144,7 +144,9 @@ int ipa_get_options(TALLOC_CTX *memctx,
struct ipa_options *opts;
char *domain;
char *server;
+char *ipa_hostname;
int ret;
+char hostname[HOST_NAME_MAX + 1];
opts = talloc_zero(memctx, struct ipa_options);
if (!opts) return ENOMEM;
@@ -173,6 +175,24 @@ int ipa_get_options(TALLOC_CTX *memctx,
goto done;
}
+ipa_hostname = dp_opt_get_string(opts->basic, IPA_HOSTNAME);
+if (ipa_hostname == NULL) {
+ret = gethostname(hostname, HOST_NAME_MAX);
+if (ret != EOK) {
+DEBUG(1, ("gethostname failed [%d][%s].\n", errno,
+ strerror(errno)));
+ret = errno;
+goto done;
+}
+hostname[HOST_NAME_MAX] = '\0';
+DEBUG(9, ("Setting ipa_hostname to [%s].\n", hostname));
+ret = dp_opt_set_string(opts->basic, IPA_HOSTNAME, hostname);
+if (ret != EOK) {
+goto done;
+}
+}
+
+
ret = EOK;
*_opts = opts;
--
1.6.2.5
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCHES] Fail over helper functions and reference counting wrappers
Simo Sorce wrote:
> On Fri, 2009-10-30 at 14:07 +0100, Martin Nagy wrote:
> > Hi,
> > attached are patches needed for the fail over functionality. The
> > service discovery is not there yet, I want to hold of with that until I
> > have at least a basic SRV-based one so I can test it properly. It's
> > possible that we will discover something missing when we'll be
> > integrating it into providers. Together with Steven we at least figured
> > out that for ldapi:// for example we need an "extra" treatment. So I
> > made the name resolution optional and you can provide a server with
> > user data. The commit messages and header files should explain it
> > better.
>
> Martin,
> why there are so many static global variables in this code ?
> (static struct { ... } global )
>
> Why aren't you using a context based approach like all the rest of the
> code in sssd ?
>
> Simo.
My reason was that I thought it might not be easy to share one context.
If I would use a context base approach then we would have to make sure
that every provider uses the same one. If you think this is not a
problem I'll gladly change the patch. Since a pointer to a context
could be stored in struct service for example, you would only need it
in few calls anyway.
Martin
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
[SSSD] [PATCH] Make debug message less irritating.
Hi,
this patch should fix #251.
bye,
Sumit
>From 9ec33e808fe82895473e8350eb2e8c5a78ba1ccb Mon Sep 17 00:00:00 2001
From: Sumit Bose
Date: Mon, 2 Nov 2009 14:32:00 +0100
Subject: [PATCH] Make debug message less irritating.
The 'Unable to load' debug message is now only shown when the backend
target is given explicitly in the config file. I the other case we
let the caller decided how to handle this error condition.
---
server/providers/data_provider_be.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/server/providers/data_provider_be.c
b/server/providers/data_provider_be.c
index 65f33ce..b20ac1f 100644
--- a/server/providers/data_provider_be.c
+++ b/server/providers/data_provider_be.c
@@ -939,8 +939,6 @@ static int load_backend_module(struct be_ctx *ctx,
mod_init_fn = (bet_init_fn_t)dlsym(ctx->loaded_be[lb].handle,
mod_init_fn_name);
if (mod_init_fn == NULL) {
-DEBUG(0, ("Unable to load init fn %s from module %s, error: %s\n",
- mod_init_fn_name, mod_name, dlerror()));
if (default_mod_name != NULL &&
strcmp(default_mod_name, mod_name) == 0 ) {
/* If the default is used and fails we indicate this to the caller
@@ -948,6 +946,8 @@ static int load_backend_module(struct be_ctx *ctx,
* handle the different types of error conditions. */
ret = ENOENT;
} else {
+DEBUG(0, ("Unable to load init fn %s from module %s, error: %s\n",
+ mod_init_fn_name, mod_name, dlerror()));
ret = ELIBBAD;
}
goto done;
--
1.6.2.5
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCHES] Fail over helper functions and reference counting wrappers
On Fri, 2009-10-30 at 14:07 +0100, Martin Nagy wrote:
> Hi,
> attached are patches needed for the fail over functionality. The
> service discovery is not there yet, I want to hold of with that until I
> have at least a basic SRV-based one so I can test it properly. It's
> possible that we will discover something missing when we'll be
> integrating it into providers. Together with Steven we at least figured
> out that for ldapi:// for example we need an "extra" treatment. So I
> made the name resolution optional and you can provide a server with
> user data. The commit messages and header files should explain it
> better.
Martin,
why there are so many static global variables in this code ?
(static struct { ... } global )
Why aren't you using a context based approach like all the rest of the
code in sssd ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] add sysdb_delete_recursive request to sysdb API
On Fri, Oct 30, 2009 at 10:51:13PM +0100, Sumit Bose wrote:
> On Fri, Oct 30, 2009 at 05:42:10PM -0400, Simo Sorce wrote:
> > On Fri, 2009-10-30 at 12:01 +0100, Sumit Bose wrote:
> > > On Thu, Oct 29, 2009 at 11:26:39PM +0100, Sumit Bose wrote:
> > > > On Thu, Oct 29, 2009 at 09:32:34PM +, Simo Sorce wrote:
> > > > > On Thu, 2009-10-29 at 19:40 +0100, Sumit Bose wrote:
> > > > > > On Thu, Oct 29, 2009 at 01:39:21PM +0100, Sumit Bose wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > this patch adds a recursive delete request to the sysdb API. It
> > > > > > > has
> > > > > > the
> > > > > > > same interface as sysdb_delete_entry, but does not delete the
> > > > > > > entry,
> > > > > > but
> > > > > > > its children.
> > > > > > >
> > > > > > > bye,
> > > > > > > Sumit
> > > > > >
> > > > > > This is a new version of the patch which tries to delete the entry
> > > > > > AND
> > > > > > all its children. It searches all objects with a subtree search,
> > > > > > sorts
> > > > > > the result so that the ones with the most components come first and
> > > > > > finally loops over the results and deletes them.
> > > > >
> > > > > Comments inline.
> > > > >
> > > > > > +
> > > > > > +subreq = sysdb_search_entry_send(state, ev, handle, dn,
> > > > > > LDB_SCOPE_SUBTREE,
> > > > > > + "distinguishedName=*", NULL);
> > > > >
> > > > > Please use "(objectclass=*)" as filter to catch all entries.
> > > > >
> > > >
> > > > I would prefer to stay with distinguishedName, because it is
> > > > auto-generated and always present.
> > > >
> > > > > Also please set attrs. Passing NULL, means you will retrieve all
> > > > > attributes wasting a lot of memory unnecessarily. You are interested
> > > > > only in the entries msg->dn, so you probably do not want any attribute
> > > > > returned at all.
> > > >
> > > > ah, I thought NULL means nothing, now I pass { NULL }
> > > >
> > > > >
> > > > > [..]
> > > > >
> > > > > > +static int compare_ldb_dn_comp_num(const void *m1, const void *m2)
> > > > > > +{
> > > > > > +struct ldb_message *msg1 = talloc_get_type(*(const void **) m1,
> > > > > > + struct ldb_message);
> > > > > > +struct ldb_message *msg2 = talloc_get_type(*(const void **) m2,
> > > > > > + struct ldb_message);
> > > > > > +
> > > > > > +return ldb_dn_get_comp_num(msg2->dn) -
> > > > > > ldb_dn_get_comp_num(msg1->dn);
> > > > > > +}
> > > > >
> > > > > Please move this function in sysdb.c, it's a generic function that can
> > > > > be used by multiple functions and here just interrupts reading the
> > > > > program flow.
> > > >
> > > > done
> > > >
> > > > >
> > > > > > +static void sysdb_delete_recursive_loop(struct tevent_req *subreq)
> > > > > [...]
> > > > >
> > > > > I think you should split the this function into a function that
> > > > > receives
> > > > > the results of sysdb_search_entry_recv() and then another one that
> > > > > sets
> > > > > the loop. If necessary use the trick I used in sdap_cli_connect to do
> > > > > continuation functions (see the sdap_cli_*_step functions).
> > > > >
> > > >
> > > > done
> > > >
> > > > > The rest looks good to me.
> > > > >
> > > >
> > > > Thanks for reviewing.
> > > >
> > > > bye,
> > > > Sumit
> > > >
> > >
> > > sorry, this new patch fixes a compiler warning.
> >
> > Looks good to me, I have only a minor nitpick, shouldn't the ENOENT
> > error in sysdb_delete_recursive_op_done() be fatal ?
> >
> > Given it should never happen, does it make sense to allow to continue ?
> >
> > Simo.
> >
>
> ok, it is now fatal as all other errors
>
> bye,
> Sumit
This new version adds a missing return after a tevent_req_done() call.
bye,
Sumit
>From 44a77225d38dd5998e6da56fa420cdb817bddf94 Mon Sep 17 00:00:00 2001
From: Sumit Bose
Date: Thu, 29 Oct 2009 12:57:57 +0100
Subject: [PATCH] add sysdb_delete_recursive request to sysdb API
---
server/db/sysdb.c | 12
server/db/sysdb.h | 10 +++
server/db/sysdb_ops.c | 153
server/tests/sysdb-tests.c | 111 ++-
4 files changed, 282 insertions(+), 4 deletions(-)
diff --git a/server/db/sysdb.c b/server/db/sysdb.c
index 5811ddc..a2ac3b2 100644
--- a/server/db/sysdb.c
+++ b/server/db/sysdb.c
@@ -1417,3 +1417,15 @@ int sysdb_get_ctx_from_list(struct sysdb_ctx_list
*ctx_list,
/* definitely not found */
return ENOENT;
}
+
+
+int compare_ldb_dn_comp_num(const void *m1, const void *m2)
+{
+struct ldb_message *msg1 = talloc_get_type(*(void **) discard_const(m1),
+ struct ldb_message);
+struct ldb_message *msg2 = talloc_get_type(*(void **) discard_const(m2),
+ struct ldb_message);
+
+return ldb_dn_get_comp_num(msg2->dn) - ldb_dn_get_comp_n
Re: [SSSD] a few questions about sssd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/01/2009 11:44 PM, David O'Brien wrote: > Greetings one and all. I have a couple of questions about sssd, from > various places. > > 1. "How long should nss_sss cache negative cache hits before asking the > back end again?" (from NSS config options in the sssd.conf man page) This describes the negative cache. In order to avoid flooding the data provider with requests for a user that does not exist, we will maintain a temporary negative cache that will short-circuit the usual lookup. Normally the process would be: 1) Is the user in cache? No. 2) Ask the data provider to update the cache. 3) Data provider asks the remote data store about the user. No such user. (This is an expensive operation, time-wise) 4) Data provider returns without updating the cache. 5) Cache reports no such user. With this setting, after the first time that the data provider returns no such user, we add this to a special negative cache (for as long as this option specifies). This adds an additional step 0 to the above, which is to check whether the user is in the negative cache first. If it is, it immediately reports no such user instead of checking the data provider. This is useful in cases where someone might mistype a name and then the process they run attempts to use this name many, many times in a very short period. Rather than go to the data provider every time (which we know will always be negative), we use the negative cache. > > I don't quite get how you query the cache for something and cache the > results, unless there are two caches. > > 2. Are the cache and other option's values specified in seconds? I've > seen values of 15, 120, and 600, but I'm green enough with this sort of > thing to ask to make sure. With one exception, they're all specified in seconds. That exception is the offline_credentials_expiration, which as the manpage states is specified in days. > > thanks - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkruznsACgkQeiVVYja6o6Ni0gCcCLPxUrZUToYWTLP45suG35Sq UkcAnidwcFTldKoVtM1lwBCnWu2mBn1b =WXH8 -END PGP SIGNATURE- ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] domain vs provider in SSSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/02/2009 12:43 AM, David O'Brien wrote: > From what I've read, these two are equivalent. Should I be using one > term in one place and the other elsewhere or doesn't it matter? > Domains and providers are NOT the same thing. A domain is a conceptual object that contains one or more providers. For example, an IPA domain is actually a domain with an ID provider of LDAP and an authentication provider of Kerberos. These terms must not be used interchangeably. In some communications, we refer to an "LDAP domain", but in these examples, we're usually talking about a domain that uses LDAP for all the provider types (ID, AUTH, ACCESS and CHPASS) A provider on the other hand is a connection to the remote (or local) data store. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkruzR4ACgkQeiVVYja6o6OPIgCdGru/NkCsjk/zII3Ik6TnTkSM pVEAoJhNYi23F5vh/rwO1oKs+QDts5fb =McyP -END PGP SIGNATURE- ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] Problem or not?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/30/2009 04:54 PM, Jeff Schroeder wrote: > I've built this package for Fedora 10 and am testing it out. > http://kojipkgs.fedoraproject.org/packages/sssd/0.7.1/1.fc12/src/sssd-0.7.1-1.fc12.src.rpm > > In /var/log/sssd/sssd.log: > [sssd[be[LDAP]]] [load_backend_module] (0): Unable to load init fn > sssm_ldap_access_init from module ldap, error: > /usr/lib64/sssd/libsss_ldap.so: undefined symbol: > sssm_ldap_access_init > > Is this a problem? Authentication appears to be working but I'm not > sure 100% as that can't be good. > Please see https://fedorahosted.org/sssd/ticket/251 This is a known issue, but a harmless one. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkruzF8ACgkQeiVVYja6o6Nv1ACfSeKWkwXkuNULrjX2NR2FtJ3a wd4An3VrWojg7AJqeTzjV69vsKdxXV0F =FqmE -END PGP SIGNATURE- ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] a few questions about sssd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/02/2009 05:44 AM, David O'Brien wrote: > Greetings one and all. I have a couple of questions about sssd, from > various places. > > 1. "How long should nss_sss cache negative cache hits before asking the > back end again?" (from NSS config options in the sssd.conf man page) > > I don't quite get how you query the cache for something and cache the > results, unless there are two caches. > This is probably my poor wording..what I meant to say was just "how long is negative cache valid", IOW how long SSSD will just return that the entry is negative before asking providers. > 2. Are the cache and other option's values specified in seconds? I've > seen values of 15, 120, and 600, but I'm green enough with this sort of > thing to ask to make sure. > AFACT, enum_cache_timeout, entry_cache_nowait_timeout, entry_negative_timeout are all in seconds, they are compared against now=time(NULL) which returns seconds since The Epoch. offline_credentials_expiration is in days (as the manpage states) Hope this helps, Jakub -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkrurSIACgkQHsardTLnvCWlRACgj85b5RHqrm8+HU+1xoYjmb3Y oM8AoIBedu6rz61rh5TE2LUvEXteJS/4 =hGrn -END PGP SIGNATURE- ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
