Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Wed, May 29, 2013 at 08:38:37AM +0300, Alexander Bokovoy wrote: > On Tue, 28 May 2013, Dmitri Pal wrote: > >On 05/28/2013 04:29 PM, Alexander Bokovoy wrote: > >>On Tue, 28 May 2013, Dmitri Pal wrote: > >>>On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: > On Tue, 28 May 2013, Dmitri Pal wrote: > >On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: > >>Hi, > >> > >> > >>http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts > >> > >>= Overview = > >> > >>Since version 3.0 FreeIPA supports cross-realm trusts with Active > >>Directory. In order to allow AD users to utilize services on IPA > >>clients, up to date version of SSSD should be configured at the IPA > >>client. In case it is not possible to install and configure SSSD > > >>1.09, > >>Active Directory users cannot access services on IPA clients. > >> > >>This feature is designed to bridge the gap and provide minimal > >>compatibility level that allows to log-in to IPA clients for AD > >>users. > >>IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd > >>version. > >>= Use Cases = > >> > >>Access to IPA client machine resources for AD users in case IPA > >>client > >>cannot utilize up to date version of SSSD with native support for IPA > >>cross-realm trusts. > >> > >>= Design= > >>Since IPA client is configured with the use of older SSSD or > >>nss_ldap/pam_ldap, all work should be performed at the IPA master. > >>Primary design decision is to provide a separate LDAP tree, > >>similar to > >>compat tree, that has following features: > >> > >>* information about both IPA and AD users can be queried; > >>* it ispossible to enumerate members of IPA and AD groups; > >>* authentication bind to IPA LDAP as AD users should automatically > >>* trigger obtaining ticket from AD DC; in case TGT is obtained, > >>* authentication bind should be treated as successful. > >> > >>From a client perspective, use of the separate LDAP tree is viewed as > >>traditional nss_ldap/pam_ldap configuration. > >> > >>Proposed base for the LDAP tree: > >>'''cn=users,cn=trust-accounts,dc=example,dc=com''' > >> > >>= Implementation = > >> > >># IPA server sets SSSD configuration to 'ipa_server_mode = true' on > >>install or upgrade > >># ipa-adtrust-install configures additional directory server > >>plugin to > >>serve trusted domains tree > >># Directory server plugin uses getpwnam_r(), getgrnam_r() and > >>related > >>calls to obtain information about AD user. For IPA users the > >>information is fetched directly from the LDAP. > >># IPA KDC database driver adds MS-PAC information into ticket > >>granting > >>ticket for host/fqdn@REALM principal of IPA master. This is required > >>to allow SSSD on IPA master to authenticate against AD using > >>host/fqdn@REALM principal. > >> > >>For SSSD design see > >>https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode > >> > >>= Feature Management = > >> > >>=== UI === > >> > >>The feature is transparent and not exposed in UI > >> > >>=== CLI === > >> > >>The feature is not directly exposed in CLI. > >>IPA idrange management is expanded to specify idrange type (IPA > >>local, > >>AD trust, AD with winsync, IPA trust, ..) to affect the way how AD > >>users > >>SIDs are mapped to POSIX IDs. > >> > >>= Major configuration options and enablement = > >> > >>sssd.conf will have 'ipa_server_mode = true' set for IPA master. > >> > >>= Replication = > >> > >>No effect on replication. Since directory server plugin is only > >>configured when ipa-adtrust-install is run, IPA masters may opt out > >>from > >>serving AD clients. > >> > >>= Updates and Upgrades = > >> > >>During upgrade of IPA master, sssd.conf should be updated to set > >>'ipa_server_mode = true'. > >> > >>= Dependencies = > >> > >>Depends on SSSD implementing IPA server mode (sssd 1.10.x) > >> > >>= External Impact = > >> > >>https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode > >> > >>= Backup and Restore = > >> > >>No external configuration files are affected > >> > >>= Test Plan = > >> > >>Testing the feature will require following: > >> > >># Configure IPA to serve AD trusts > >># Establish trust with AD domain > >># Configure a client to use nss_ldap/pam_ldap against AD-compatible > >>tree > >># Attempt to log-in to the client as AD user > >> > >>= RFE Author = > >> > >>[[User:Ab|ab]] ([[User talk:Ab|talk]]) > >> > > > > > >Can you please explain how the older SSSD or other UNIX versions would > >use Kerberos for authentication? > pam_k
Re: [Freeipa-devel] [Patchwork] command line client
On 28.5.2013 14:12, Simo Sorce wrote: On Tue, 2013-05-28 at 10:46 +0200, Martin Kosek wrote: On 05/28/2013 10:38 AM, Petr Spacek wrote: On 27.5.2013 22:05, Simo Sorce wrote: On Mon, 2013-05-27 at 16:36 +0200, Petr Spacek wrote: On 27.5.2013 15:57, Simo Sorce wrote: On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: Hello Simo, could you install/allow XMLRPC for our Patchwork, please? I found the CLI for Patchwork but it requires XMLRPC. On 27.5.2013 10:41, Petr Spacek wrote: see https://www.varnish-cache.org/patchwork/help/pwclient/ Should be enabled now. Hmm, I'm still getting HTTP 404 (URL https://patchwork.acksyn.org/xmlrpc/): xmlrpclib.ProtocolError: I've restarted the apahe server, apparently not all threads would see the new config w/o a full reload. I confirm that it works now. BTW did you considered migration to freeipa.org? :-) We could eventually migrate it to OpenShift just like FreeIPA.org's mediawiki site. As patchwork is based on Django which is common on OpenShift, it should not be so difficult. We could then create alias patchwork.freeipa.org if we want to use it. Yup, I think we should do it, Petr are you ihnterested in comaintainng it if we move it to an OpenShift instance ? I'm sorry, but I have hands full with labs in Brno and Boston and I don't want to raise the speed of losing my hair. -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0060] Do not translate trust type and direction with --raw in trust-show
On 05/28/2013 05:32 PM, Ana Krivokapic wrote: On 05/28/2013 01:20 PM, Tomas Babej wrote: On 05/27/2013 03:04 PM, Ana Krivokapic wrote: On 05/27/2013 02:38 PM, Tomas Babej wrote: Hi, In trust_show command, make sure that --raw flag is honoured. Attributes ipanttrusttype and ipanttrustdirection are no longer translated to strings from their raw ldap values when --raw is used. https://fedorahosted.org/freeipa/ticket/3525 Tomas The patch causes these two attributes to not be displayed, when --raw switch is used: [akrivoka@vm-040 freeipa]$ ipa trust-show addomain.example.com Realm name: addomain.example.com Domain NetBIOS name: ADDOMAIN Domain Security Identifier: S-1-5-21-115633519-1816729995-712395322 Trust direction: Two-way trust Trust type: Active Directory domain [akrivoka@vm-040 freeipa]$ ipa trust-show addomain.example.com --raw cn: addomain.example.com ipantflatname: ADDOMAIN ipanttrusteddomainsid: S-1-5-21-115633519-1816729995-712395322 Thanks. Updated patch attached. I modified trust-find according to the new behaviour. Tomas Works nicely. Please just amend the commit message to mention that the trust-find command is also affected. ACK. Pushed to master. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0060] Do not translate trust type and direction with --raw in trust-show
On 05/28/2013 05:32 PM, Ana Krivokapic wrote:
On 05/28/2013 01:20 PM, Tomas Babej wrote:
On 05/27/2013 03:04 PM, Ana Krivokapic wrote:
On 05/27/2013 02:38 PM, Tomas Babej wrote:
Hi,
In trust_show command, make sure that --raw flag is honoured.
Attributes ipanttrusttype and ipanttrustdirection are no longer
translated to strings from their raw ldap values when --raw is
used.
https://fedorahosted.org/freeipa/ticket/3525
Tomas
The patch causes these two attributes to not be displayed, when --raw
switch is used:
[akrivoka@vm-040 freeipa]$ ipa trust-show addomain.example.com
Realm name: addomain.example.com
Domain NetBIOS name: ADDOMAIN
Domain Security Identifier: S-1-5-21-115633519-1816729995-712395322
Trust direction: Two-way trust
Trust type: Active Directory domain
[akrivoka@vm-040 freeipa]$ ipa trust-show addomain.example.com --raw
cn: addomain.example.com
ipantflatname: ADDOMAIN
ipanttrusteddomainsid: S-1-5-21-115633519-1816729995-712395322
Thanks. Updated patch attached.
I modified trust-find according to the new behaviour.
Tomas
Works nicely.
Please just amend the commit message to mention that the trust-find
command is also affected.
ACK.
Commit message ammended.
Tomas
From 41e951e05166b3163eb96ac79f88b0d99163141f Mon Sep 17 00:00:00 2001
From: Tomas Babej
Date: Mon, 27 May 2013 14:21:57 +0200
Subject: [PATCH] Do not translate trust type and direction with --raw in
trust_show
In trust_show command, make sure that --raw flag is honoured.
Attributes ipanttrusttype and ipanttrustdirection are no longer
translated to strings from their raw ldap values when --raw is
used.
The trust_find command has been altered to follow the same
behaviour.
https://fedorahosted.org/freeipa/ticket/3525
---
ipalib/plugins/trust.py | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index 9bcfb417a9413faffdeb4009d9de06d6041b223e..3cb0ed98005ae5bd11b39f8ae01c9470d1bfc9c4 100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -487,7 +487,8 @@ class trust_mod(LDAPUpdate):
class trust_find(LDAPSearch):
__doc__ = _('Search for trusts.')
-has_output_params = LDAPSearch.has_output_params + trust_output_params
+has_output_params = LDAPSearch.has_output_params + trust_output_params +\
+(Str('ipanttrusttype'),)
msg_summary = ngettext(
'%(count)d trust matched', '%(count)d trusts matched', 0
@@ -505,13 +506,18 @@ class trust_find(LDAPSearch):
for entry in entries:
(dn, attrs) = entry
-attrs['trusttype'] = trust_type_string(attrs['ipanttrusttype'][0])
+
+# Translate ipanttrusttype to trusttype if --raw not used
+if not options.get('raw', False):
+attrs['trusttype'] = trust_type_string(attrs['ipanttrusttype'][0])
+del attrs['ipanttrusttype']
return truncated
class trust_show(LDAPRetrieve):
__doc__ = _('Display information about a trust.')
-has_output_params = LDAPRetrieve.has_output_params + trust_output_params
+has_output_params = LDAPRetrieve.has_output_params + trust_output_params +\
+(Str('ipanttrusttype'), Str('ipanttrustdirection'))
def execute(self, *keys, **options):
error = None
@@ -524,9 +530,7 @@ class trust_show(LDAPRetrieve):
result = None
error = e
if result:
- result['result']['trusttype'] = [trust_type_string(result['result']['ipanttrusttype'][0])]
- result['result']['trustdirection'] = [trust_direction_string(result['result']['ipanttrustdirection'][0])]
- break
+break
if error or not result:
self.obj.handle_not_found(*keys)
@@ -536,6 +540,24 @@ class trust_show(LDAPRetrieve):
assert isinstance(dn, DN)
if 'trust_show_type' in options:
return make_trust_dn(self.env, options['trust_show_type'], dn)
+
+return dn
+
+def post_callback(self, ldap, dn, entry_attrs, *keys, **options):
+
+# Translate ipanttrusttype to trusttype
+# and ipanttrustdirection to trustdirection
+# if --raw not used
+
+if not options.get('raw', False):
+type_str = trust_type_string(entry_attrs['ipanttrusttype'][0])
+dir_str = trust_direction_string(entry_attrs['ipanttrustdirection']
+[0])
+entry_attrs['trusttype'] = [type_str]
+entry_attrs['trustdirection'] = [dir_str]
+del entry_attrs['ipanttrusttype']
+del entry_attrs['ipanttrustdirection']
+
return dn
api.register(trust)
--
1.8.1.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/fre
[Freeipa-devel] [PATCH] 417 Regression fix: missing control buttons in nested search facets
Automount maps, keys and dnsrecord search facet are missing control
buttons (add, delete, refresh).
Regression introduced by 6e90920233cc9a7c9feb040dea22cda837715c39 -
'Move spec modifications from facet factories to pre_ops'.
https://fedorahosted.org/freeipa/ticket/3605
--
Petr Vobornik
From 12ec9a7b2aa394e43ad887bd4b5487069f814161 Mon Sep 17 00:00:00 2001
From: Petr Vobornik
Date: Wed, 29 May 2013 10:12:44 +0200
Subject: [PATCH] Regression fix: missing control buttons in nested search
facets
Regression introduced by 6e90920233cc9a7c9feb040dea22cda837715c39 - 'Move spec modifications from facet factories to pre_ops'.
https://fedorahosted.org/freeipa/ticket/3605
---
install/ui/src/freeipa/search.js | 40
1 file changed, 24 insertions(+), 16 deletions(-)
diff --git a/install/ui/src/freeipa/search.js b/install/ui/src/freeipa/search.js
index e923316f6c9697167131c1eb5e0e1220f0576b44..03ec0b12adedb8c8ad0272f308e8dc7931da 100644
--- a/install/ui/src/freeipa/search.js
+++ b/install/ui/src/freeipa/search.js
@@ -33,22 +33,7 @@ define([
var exp = {};
-exp.search_facet_pre_op = function(spec, context) {
-
-var entity = context.entity;
-su.context_entity(spec, context);
-
-spec.name = spec.name || 'search';
-spec.title = spec.title || entity.metadata.label;
-spec.label = spec.label || entity.metadata.label;
-spec.tab_label = spec.tab_label || '@i18n:facets.search';
-
-spec.managed_entity = spec.managed_entity ? IPA.get_entity(spec.managed_entity) : spec.entity;
-
-spec.disable_breadcrumb =
-spec.disable_breadcrumb === undefined ? true : spec.disable_breadcrumb;
-spec.disable_facet_tabs =
-spec.disable_facet_tabs === undefined ? true : spec.disable_facet_tabs;
+exp.search_facet_control_buttons_pre_op = function(spec, context) {
spec.actions = spec.actions || [];
spec.actions.unshift(
@@ -83,7 +68,27 @@ exp.search_facet_pre_op = function(spec, context) {
spec.state.evaluators.push(
IPA.selected_state_evaluator,
IPA.self_service_state_evaluator);
+return spec;
+};
+exp.search_facet_pre_op = function(spec, context) {
+
+var entity = context.entity;
+su.context_entity(spec, context);
+
+spec.name = spec.name || 'search';
+spec.title = spec.title || entity.metadata.label;
+spec.label = spec.label || entity.metadata.label;
+spec.tab_label = spec.tab_label || '@i18n:facets.search';
+
+spec.managed_entity = spec.managed_entity ? IPA.get_entity(spec.managed_entity) : spec.entity;
+
+spec.disable_breadcrumb =
+spec.disable_breadcrumb === undefined ? true : spec.disable_breadcrumb;
+spec.disable_facet_tabs =
+spec.disable_facet_tabs === undefined ? true : spec.disable_facet_tabs;
+
+exp.search_facet_control_buttons_pre_op(spec, context);
return spec;
};
@@ -372,6 +377,7 @@ exp.nested_search_facet_preop = function(spec, context) {
var entity = context.entity;
su.context_entity(spec, context);
+spec.name = spec.name || 'search';
spec.title = spec.title || entity.metadata.label_singular;
spec.label = spec.label || entity.metadata.label;
spec.tab_label = spec.tab_label || '@i18n:facets.search';
@@ -380,6 +386,8 @@ exp.nested_search_facet_preop = function(spec, context) {
spec.disable_breadcrumb = false;
spec.disable_facet_tabs = false;
+
+exp.search_facet_control_buttons_pre_op(spec, context);
return spec;
};
--
1.8.1.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust
On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Tomas Babej wrote: On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: On Mon, 27 May 2013, Tomas Babej wrote: We got rid of openldap utilities now. While using python.ldap module, I also made the tests much more robust and added a new test case. In general patches look fine, there is one small nitpick. I'll run tests on Monday and then will provide final ACK. --- a/tests/test_xmlrpc/test_range_plugin.py +++ b/tests/test_xmlrpc/test_range_plugin.py @@ -22,66 +22,171 @@ Test the `ipalib/plugins/idrange.py` module, and XML-RPC in general. """ from ipalib import api, errors, _ +from ipapython.ipautil import run This import is unused, can be removed. Fixed, thanks for catching that. Updated patch attached. So I tried to run this test on a machine where there is already trust established and I think there should be done some changes. I perused the log. Seems that the failures you're experiencing are not relevant to the patch itself, since the newly added tests passed. This is problem with test_range_plugin.py tests that has been there for quite a while, the parameters of the ranges such as size, and base ID/RID/secondary RID are hardcoded in the test case. Yep. Probably it would be wise to add pre-start procedure to pull existing ranges and define constants for the ranges so that they don't overlap with existing ones. Perhaps selecting something from a top of the range space... Attached is the log I agree. This has not been relevant until now, since we did not do much testing on IPA instances with trusts set up, and even then there's random factor in having the overlap with the already created trust range. I'd propose fixing this in a separate effort as a part of continouous integration improvements. I see it as a separate issue of its own. What do you think? Please file a separate ticket then. ACK for this one. For the record: https://fedorahosted.org/freeipa/ticket/3662 Tomas ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Tue, May 28, 2013 at 02:50:59PM +0300, Alexander Bokovoy wrote: > Hi, > > > http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts > > = Overview = > > Since version 3.0 FreeIPA supports cross-realm trusts with Active > Directory. In order to allow AD users to utilize services on IPA > clients, up to date version of SSSD should be configured at the IPA > client. In case it is not possible to install and configure SSSD > 1.09, > Active Directory users cannot access services on IPA clients. > > This feature is designed to bridge the gap and provide minimal > compatibility level that allows to log-in to IPA clients for AD users. > IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd > version. > > = Use Cases = > > Access to IPA client machine resources for AD users in case IPA client > cannot utilize up to date version of SSSD with native support for IPA > cross-realm trusts. > > = Design= > > Since IPA client is configured with the use of older SSSD or > nss_ldap/pam_ldap, all work should be performed at the IPA master. > Primary design decision is to provide a separate LDAP tree, similar to > compat tree, that has following features: > > * information about both IPA and AD users can be queried; > * it ispossible to enumerate members of IPA and AD groups; > * authentication bind to IPA LDAP as AD users should automatically > * trigger obtaining ticket from AD DC; in case TGT is obtained, > * authentication bind should be treated as successful. > > From a client perspective, use of the separate LDAP tree is viewed as > traditional nss_ldap/pam_ldap configuration. > > Proposed base for the LDAP tree: > '''cn=users,cn=trust-accounts,dc=example,dc=com''' I guess older SSSD versions, e.g. 1.8. might be the most difficult use cases because they already support some specific features for IPA users and groups, e.g. HBAC, netgroups, SELinux and automount maps. Since most of them depends on DNs one way or the other I think older SSSD version must continue to use the main tree for IPA users and groups and local look at the new tree for trusted accounts. Luckily multiple search bases were introduced in SSSD 1.7, I wonder if older version have to be supported as well? But if multiple search bases are used the IPA users and groups should not be visible in the new tree for trusted accounts. Maybe the new plugin can offer different trees like - cn=users,cn=trust-accounts,dc=example,dc=com - cn=users,cn=trust-accounts-sssd,dc=example,dc=com where the first contains IPA and AD accounts as mentioned above and the latter only the AD accounts? Since we are planning to do the lookups on the fly I think both trees can be handled in the same code path and the path name is just config option which switches the IPA accounts on and off respectively. With iyet another tree it might be also possible to support either rfc2307 or rfc2037bis. I assume that the plan is that the new tree will use rfc2307bis but I wonder if we have to support clients which only support rcf2307. bye, Sumit > > = Implementation = > > # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install > or upgrade > # ipa-adtrust-install configures additional directory server plugin to serve > trusted domains tree > # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls > to obtain information about AD user. For IPA users the information is fetched > directly from the LDAP. > # IPA KDC database driver adds MS-PAC information into ticket granting ticket > for host/fqdn@REALM principal of IPA master. This is required to allow SSSD > on IPA master to authenticate against AD using host/fqdn@REALM principal. > > For SSSD design see > https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode > > = Feature Management = > > === UI === > > The feature is transparent and not exposed in UI > > === CLI === > > The feature is not directly exposed in CLI. > > IPA idrange management is expanded to specify idrange type (IPA local, > AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users > SIDs are mapped to POSIX IDs. > > = Major configuration options and enablement = > > sssd.conf will have 'ipa_server_mode = true' set for IPA master. > > = Replication = > > No effect on replication. Since directory server plugin is only > configured when ipa-adtrust-install is run, IPA masters may opt out from > serving AD clients. > > = Updates and Upgrades = > > During upgrade of IPA master, sssd.conf should be updated to set > 'ipa_server_mode = true'. > > = Dependencies = > > Depends on SSSD implementing IPA server mode (sssd 1.10.x) > > = External Impact = > > https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode > > = Backup and Restore = > > No external configuration files are affected > > = Test Plan = > > Testing the feature will require following: > > # Configure IPA to serve AD trusts > # Establish trust with AD domain > # Configure a client to use
Re: [Freeipa-devel] [PATCH 0057] Do not allow removal of ID range of an active trust
On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: > On Tue, 28 May 2013, Tomas Babej wrote: >> On 05/28/2013 02:35 PM, Alexander Bokovoy wrote: >>> On Mon, 27 May 2013, Tomas Babej wrote: >>> We got rid of openldap utilities now. While using python.ldap module, I >>> also made the tests much more robust and added a new test case. >> In general patches look fine, there is one small nitpick. >> I'll run tests on Monday and then will provide final ACK. >> >>> --- a/tests/test_xmlrpc/test_range_plugin.py >>> +++ b/tests/test_xmlrpc/test_range_plugin.py >>> @@ -22,66 +22,171 @@ Test the `ipalib/plugins/idrange.py` module, and >>> XML-RPC in general. >>> """ >>> >>> from ipalib import api, errors, _ >>> +from ipapython.ipautil import run >> This import is unused, can be removed. >> > Fixed, thanks for catching that. > > Updated patch attached. >>> So I tried to run this test on a machine where there is already trust >>> established and I think there should be done some changes. >> >> I perused the log. Seems that the failures you're experiencing are not >> relevant to the patch itself, >> since the newly added tests passed. >> >> This is problem with test_range_plugin.py tests that has been there for quite >> a while, the parameters >> of the ranges such as size, and base ID/RID/secondary RID are hardcoded in >> the test case. > Yep. > > >>> Probably it would be wise to add pre-start procedure to pull existing >>> ranges and define constants for the ranges so that they don't overlap >>> with existing ones. Perhaps selecting something from a top of the range >>> space... >>> >>> Attached is the log >> >> I agree. This has not been relevant until now, since we did not do much >> testing on IPA instances >> with trusts set up, and even then there's random factor in having the overlap >> with the already created >> trust range. >> >> I'd propose fixing this in a separate effort as a part of continouous >> integration improvements. I see it >> as a separate issue of its own. >> >> What do you think? > Please file a separate ticket then. > > ACK for this one. > May-be-NACK. Would it make sense to replace the error with DependentEntry error? We use in cases like this elsewhere and I think it makes more sense in this case too. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0155] Fix IPv6 handling in PTR record synchronization
On 28.5.2013 10:44, Tomas Hozza wrote: ACK The patch looks good and works as expected. Pushed to master: 304b7e74e9d92d0973ef4428be7b9794c8905056 -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 418 Make ssbrowser.html work in IE 10
Manual configuration page for other browsers (ssbrowser.html) doesn't
work in IE 10 - error page is displayed.
This patch is conditioning creation of Firefox configuration object so
that configure.jar is requested only in Firefox. IE doesn't request it
and so it does not fail.
https://fedorahosted.org/freeipa/ticket/3645
--
Petr Vobornik
From af2c2fb00e0146f60ad31f17fba25be5e89120af Mon Sep 17 00:00:00 2001
From: Petr Vobornik
Date: Wed, 29 May 2013 13:06:11 +0200
Subject: [PATCH] Make ssbrowser.html work in IE 10
Manual configuration page for other browsers (ssbrowser.html) doesn't work in IE 10 - error page is displayed.
This patch is conditioning creation of Firefox configuration object so that configure.jar is requested only in Firefox. IE doesn't request it and so it does not fail.
https://fedorahosted.org/freeipa/ticket/3645
---
install/html/ssbrowser.html | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/install/html/ssbrowser.html b/install/html/ssbrowser.html
index 2afb0facf5c112d6595fbf2f9d2d81e6e5eb61df..72fd573cf907e7ce3a27a17a2857633480cff9de 100644
--- a/install/html/ssbrowser.html
+++ b/install/html/ssbrowser.html
@@ -16,7 +16,14 @@
$('.example-domain').text(domain);
if ($.browser.mozilla) {
-$("#configurefirefox").show();
+var ff_config = $("#configurefirefox");
+var obj = $('', {
+type: 'text/html',
+'class': 'browser-config'
+});
+obj.prop('data', 'jar:/ipa/errors/configure.jar!/preferences.html');
+obj.appendTo(ff_config);
+ff_config.show();
}
});
@@ -72,8 +79,7 @@
1. Import CA certificate. Make sure you checked all three checkboxes.
2. Click on "Configure Browser" button below.
-
+
--
1.8.1.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Serving legacy systems cliens for trusts
On Wed, 29 May 2013, Sumit Bose wrote: On Tue, May 28, 2013 at 02:50:59PM +0300, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD > 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' I guess older SSSD versions, e.g. 1.8. might be the most difficult use cases because they already support some specific features for IPA users and groups, e.g. HBAC, netgroups, SELinux and automount maps. Since most of them depends on DNs one way or the other I think older SSSD version must continue to use the main tree for IPA users and groups and local look at the new tree for trusted accounts. Luckily multiple search bases were introduced in SSSD 1.7, I wonder if older version have to be supported as well? But if multiple search bases are used the IPA users and groups should not be visible in the new tree for trusted accounts. Maybe the new plugin can offer different trees like - cn=users,cn=trust-accounts,dc=example,dc=com - cn=users,cn=trust-accounts-sssd,dc=example,dc=com where the first contains IPA and AD accounts as mentioned above and the latter only the AD accounts? Since we are planning to do the lookups on the fly I think both trees can be handled in the same code path and the path name is just config option which switches the IPA accounts on and off respectively. With iyet another tree it might be also possible to support either rfc2307 or rfc2037bis. I assume that the plan is that the new tree will use rfc2307bis but I wonder if we have to support clients which only support rcf2307. Yep. Summarizing for the list discussion we had with Sumit on IRC, I think we can re-use slapi-nis plugin for the purpose of this feature. The way slapi-nis works for schema compatibility is that one needs to define first a subtree to search against, with a filter, and then additional transformations are applied to the result of search. The end result is presented to the client. What we need to do is to make possible to return a result of initial 'search' against SSSD instead of actual LDAP subtree. A 'search' result is then processed according to defined transformation rules. slapi-nis supports multiple resulting trees already, this solves the problem Sumit raises above. Additionally, for LDAP auth bind we need to make sure it is actually possible to hook to in a directory server plugin for a virtual DN like slapi-nis presents. This is something Sumit and I need to check with 389-ds developers. We already have some support for that with new feature to allow fallbacks for SASL auth but in this case we need to use simple bind to get hold of the password (to kinit agasint AD DC) over secure channel. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 417 Regression fix: missing control buttons in nested search facets
On 05/29/2013 10:38 AM, Petr Vobornik wrote: > Automount maps, keys and dnsrecord search facet are missing control > buttons (add, delete, refresh). > > Regression introduced by 6e90920233cc9a7c9feb040dea22cda837715c39 - > 'Move spec modifications from facet factories to pre_ops'. > > https://fedorahosted.org/freeipa/ticket/3605 > > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel This fixes the issue, ACK. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0160] Fix crash triggered by missing sasl_user parameter
Hello,
Fix crash triggered by missing sasl_user parameter.
--
Petr^2 Spacek
From 5e9454744939b64825b330135c7ab5579567be0e Mon Sep 17 00:00:00 2001
From: Petr Spacek
Date: Wed, 29 May 2013 14:56:28 +0200
Subject: [PATCH] Fix crash triggered by missing sasl_user parameter.
Signed-off-by: Petr Spacek
---
src/ldap_helper.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index 424bc4b8afef924e92524ceca620e047380d70a4..4d22f2803ba4e9f5658b086dc7bb53579c5a3b92 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -440,6 +440,7 @@ validate_local_instance_settings(ldap_instance_t *inst, settings_set_t *set) {
"gethostname() failed");
CLEANUP_WITH(ISC_R_FAILURE);
} else {
+ CHECK(str_new(inst->mctx, &buff));
CHECK(str_sprintf(buff,
"DNS/%s", hostname));
log_debug(2, "SASL mech GSSAPI defined "
@@ -466,6 +467,7 @@ validate_local_instance_settings(ldap_instance_t *inst, settings_set_t *set) {
result = ISC_R_FAILURE;
cleanup:
+ str_destroy(&buff);
if (result != ISC_R_SUCCESS)
log_error_r("LDAP config validation failed for database '%s'",
inst->db_name);
--
1.7.11.7
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0161] Validate authentication settings strictly
Hello,
Validate authentication settings strictly.
- auth_method 'SASL' do not accept bind_dn and password options
- auth_method 'simple' do not accept sasl_* and krb5_* options
- auth_method 'none' do not accept any of options above
--
Petr^2 Spacek
From 6866c4e1edb5633b5a82c2d28f603f9660994d6a Mon Sep 17 00:00:00 2001
From: Petr Spacek
Date: Wed, 29 May 2013 15:01:30 +0200
Subject: [PATCH] Validate authentication settings strictly.
- auth_method 'SASL' do not accept bind_dn and password options
- auth_method 'simple' do not accept sasl_* and krb5_* options
- auth_method 'none' do not accept any of options above
Signed-off-by: Petr Spacek
---
src/ldap_helper.c | 42 +-
1 file changed, 33 insertions(+), 9 deletions(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index 4d22f2803ba4e9f5658b086dc7bb53579c5a3b92..46d2dccf8df57759da6b1282eff4aa56c50f0d37 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -362,7 +362,11 @@ validate_local_instance_settings(ldap_instance_t *inst, settings_set_t *set) {
isc_uint32_t uint;
const char *sasl_mech = NULL;
const char *sasl_user = NULL;
+ const char *sasl_realm = NULL;
+ const char *sasl_password = NULL;
const char *krb5_principal = NULL;
+ const char *bind_dn = NULL;
+ const char *password = NULL;
ld_string_t *buff = NULL;
char print_buff[PRINT_BUFF_SIZE];
@@ -427,6 +431,33 @@ validate_local_instance_settings(ldap_instance_t *inst, settings_set_t *set) {
CHECK(setting_get_str("sasl_mech", set, &sasl_mech));
CHECK(setting_get_str("krb5_principal", set, &krb5_principal));
CHECK(setting_get_str("sasl_user", set, &sasl_user));
+ CHECK(setting_get_str("sasl_realm", set, &sasl_realm));
+ CHECK(setting_get_str("sasl_password", set, &sasl_password));
+ CHECK(setting_get_str("bind_dn", set, &bind_dn));
+ CHECK(setting_get_str("password", set, &password));
+
+ if (auth_method_enum != AUTH_SIMPLE &&
+ (strlen(bind_dn) != 0 || strlen(password) != 0)) {
+ log_error("options 'bind_dn' and 'password' are allowed only "
+ "for auth_method 'simple'");
+ CLEANUP_WITH(ISC_R_FAILURE);
+ }
+
+ if (auth_method_enum == AUTH_SIMPLE &&
+ (strlen(bind_dn) == 0 || strlen(password) == 0)) {
+ log_error("auth_method 'simple' requires 'bind_dn' and 'password'");
+ log_info("for anonymous bind please use auth_method 'none'");
+ CLEANUP_WITH(ISC_R_FAILURE);
+ }
+
+ if (auth_method_enum != AUTH_SASL &&
+ (strlen(sasl_realm) != 0 || strlen(sasl_user) != 0 ||
+ strlen(sasl_password) != 0 || strlen(krb5_principal) != 0)) {
+ log_error("options 'sasl_realm', 'sasl_user', 'sasl_password' "
+ "and 'krb5_principal' are effective only with "
+ "auth_method 'sasl'");
+ CLEANUP_WITH(ISC_R_FAILURE);
+ }
if ((auth_method_enum == AUTH_SASL) &&
(strcasecmp(sasl_mech, "GSSAPI") == 0)) {
@@ -2487,15 +2518,6 @@ ldap_reconnect(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn,
return ISC_R_SOFTQUOTA;
}
- /* If either bind_dn or the password is not set, we will use
- * password-less bind. */
- CHECK(setting_get_str("bind_dn", ldap_inst->global_settings, &bind_dn));
- CHECK(setting_get_str("password", ldap_inst->global_settings, &password));
- if (strlen(bind_dn) == 0 || strlen(password) == 0) {
- bind_dn = NULL;
- password = NULL;
- }
-
/* Set the next possible reconnect time. */
{
isc_interval_t delay;
@@ -2525,6 +2547,8 @@ force_reconnect:
ret = ldap_simple_bind_s(ldap_conn->handle, NULL, NULL);
break;
case AUTH_SIMPLE:
+ CHECK(setting_get_str("bind_dn", ldap_inst->global_settings, &bind_dn));
+ CHECK(setting_get_str("password", ldap_inst->global_settings, &password));
ret = ldap_simple_bind_s(ldap_conn->handle, bind_dn, password);
break;
case AUTH_SASL:
--
1.7.11.7
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0031] Deprecate options --dom-sid and --dom-name in idrange-mod
Hello,
This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3636
--
Regards,
Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.
From 704114481caed03cf02daac56d78dc43a3759a3a Mon Sep 17 00:00:00 2001
From: Ana Krivokapic
Date: Wed, 29 May 2013 09:15:19 -0400
Subject: [PATCH] Deprecate options --dom-sid and --dom-name in idrange-mod
https://fedorahosted.org/freeipa/ticket/3636
---
API.txt | 4 ++--
VERSION | 2 +-
ipalib/plugins/idrange.py | 17 ++---
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/API.txt b/API.txt
index e5bb7beb49c287badecb36ed95451a2561a68976..0a4b356e6f8a66d785e222f5941ff65a3cb484b7 100644
--- a/API.txt
+++ b/API.txt
@@ -2014,8 +2014,8 @@ option: Str('delattr*', cli_name='delattr', exclude='webui')
option: Int('ipabaseid', attribute=True, autofill=False, cli_name='base_id', multivalue=False, required=False)
option: Int('ipabaserid', attribute=True, autofill=False, cli_name='rid_base', multivalue=False, required=False)
option: Int('ipaidrangesize', attribute=True, autofill=False, cli_name='range_size', multivalue=False, required=False)
-option: Str('ipanttrusteddomainname', attribute=False, autofill=False, cli_name='dom_name', multivalue=False, required=False)
-option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='dom_sid', multivalue=False, required=False)
+option: DeprecatedParam('ipanttrusteddomainname?')
+option: DeprecatedParam('ipanttrusteddomainsid?')
option: Str('iparangetype', attribute=True, autofill=False, cli_name='iparangetype', multivalue=False, required=False)
option: Int('ipasecondarybaserid', attribute=True, autofill=False, cli_name='secondary_rid_base', multivalue=False, required=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
diff --git a/VERSION b/VERSION
index 359a43bb329757c298e54184456975d1b09991d8..a95ccb91457c4caf9767843951b8290b15b377d6 100644
--- a/VERSION
+++ b/VERSION
@@ -89,4 +89,4 @@ IPA_DATA_VERSION=2010061412
# #
IPA_API_VERSION_MAJOR=2
-IPA_API_VERSION_MINOR=58
+IPA_API_VERSION_MINOR=59
diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
index 54f6fbb3e19b9aa01dfde2a8d0c5da4498632386..fa2569ad34557d0d65567e631cef0d66b6fd544e 100644
--- a/ipalib/plugins/idrange.py
+++ b/ipalib/plugins/idrange.py
@@ -17,13 +17,10 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see
Re: [Freeipa-devel] [Patchwork] command line client
On Wed, 2013-05-29 at 10:06 +0200, Petr Spacek wrote: > On 28.5.2013 14:12, Simo Sorce wrote: > > On Tue, 2013-05-28 at 10:46 +0200, Martin Kosek wrote: > >> On 05/28/2013 10:38 AM, Petr Spacek wrote: > >>> On 27.5.2013 22:05, Simo Sorce wrote: > On Mon, 2013-05-27 at 16:36 +0200, Petr Spacek wrote: > > On 27.5.2013 15:57, Simo Sorce wrote: > >> On Mon, 2013-05-27 at 10:45 +0200, Petr Spacek wrote: > >>> Hello Simo, > >>> > >>> could you install/allow XMLRPC for our Patchwork, please? > >>> > >>> I found the CLI for Patchwork but it requires XMLRPC. > >>> > >>> On 27.5.2013 10:41, Petr Spacek wrote: > see https://www.varnish-cache.org/patchwork/help/pwclient/ > >>> > >> > >> Should be enabled now. > > > > Hmm, I'm still getting HTTP 404 (URL > > https://patchwork.acksyn.org/xmlrpc/): > > > > xmlrpclib.ProtocolError: > patchwork.acksyn.org/xmlrpc/: 404 > > NOT FOUND> > > I've restarted the apahe server, apparently not all threads would see > the new config w/o a full reload. > >>> > >>> I confirm that it works now. BTW did you considered migration to > >>> freeipa.org? :-) > >> > >> We could eventually migrate it to OpenShift just like FreeIPA.org's > >> mediawiki > >> site. As patchwork is based on Django which is common on OpenShift, it > >> should > >> not be so difficult. We could then create alias patchwork.freeipa.org if we > >> want to use it. > > > > Yup, > > I think we should do it, Petr are you ihnterested in comaintainng it if > > we move it to an OpenShift instance ? > > I'm sorry, but I have hands full with labs in Brno and Boston and I don't > want > to raise the speed of losing my hair. No worries, however I'll wait for a volunteer before trying to move the hosting to something I am not familiar with. 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] Serving legacy systems cliens for trusts
On 05/29/2013 03:28 AM, Sumit Bose wrote: > On Wed, May 29, 2013 at 08:38:37AM +0300, Alexander Bokovoy wrote: >> On Tue, 28 May 2013, Dmitri Pal wrote: >>> On 05/28/2013 04:29 PM, Alexander Bokovoy wrote: On Tue, 28 May 2013, Dmitri Pal wrote: > On 05/28/2013 03:48 PM, Alexander Bokovoy wrote: >> On Tue, 28 May 2013, Dmitri Pal wrote: >>> On 05/28/2013 07:50 AM, Alexander Bokovoy wrote: Hi, http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts = Overview = Since version 3.0 FreeIPA supports cross-realm trusts with Active Directory. In order to allow AD users to utilize services on IPA clients, up to date version of SSSD should be configured at the IPA client. In case it is not possible to install and configure SSSD > 1.09, Active Directory users cannot access services on IPA clients. This feature is designed to bridge the gap and provide minimal compatibility level that allows to log-in to IPA clients for AD users. IPA clients will be able to use any reasonable nss_ldap/pam_ldap/sssd version. = Use Cases = Access to IPA client machine resources for AD users in case IPA client cannot utilize up to date version of SSSD with native support for IPA cross-realm trusts. = Design= Since IPA client is configured with the use of older SSSD or nss_ldap/pam_ldap, all work should be performed at the IPA master. Primary design decision is to provide a separate LDAP tree, similar to compat tree, that has following features: * information about both IPA and AD users can be queried; * it ispossible to enumerate members of IPA and AD groups; * authentication bind to IPA LDAP as AD users should automatically * trigger obtaining ticket from AD DC; in case TGT is obtained, * authentication bind should be treated as successful. >>> >From a client perspective, use of the separate LDAP tree is viewed as traditional nss_ldap/pam_ldap configuration. Proposed base for the LDAP tree: '''cn=users,cn=trust-accounts,dc=example,dc=com''' = Implementation = # IPA server sets SSSD configuration to 'ipa_server_mode = true' on install or upgrade # ipa-adtrust-install configures additional directory server plugin to serve trusted domains tree # Directory server plugin uses getpwnam_r(), getgrnam_r() and related calls to obtain information about AD user. For IPA users the information is fetched directly from the LDAP. # IPA KDC database driver adds MS-PAC information into ticket granting ticket for host/fqdn@REALM principal of IPA master. This is required to allow SSSD on IPA master to authenticate against AD using host/fqdn@REALM principal. For SSSD design see https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Feature Management = === UI === The feature is transparent and not exposed in UI === CLI === The feature is not directly exposed in CLI. IPA idrange management is expanded to specify idrange type (IPA local, AD trust, AD with winsync, IPA trust, ..) to affect the way how AD users SIDs are mapped to POSIX IDs. = Major configuration options and enablement = sssd.conf will have 'ipa_server_mode = true' set for IPA master. = Replication = No effect on replication. Since directory server plugin is only configured when ipa-adtrust-install is run, IPA masters may opt out from serving AD clients. = Updates and Upgrades = During upgrade of IPA master, sssd.conf should be updated to set 'ipa_server_mode = true'. = Dependencies = Depends on SSSD implementing IPA server mode (sssd 1.10.x) = External Impact = https://fedorahosted.org/sssd/wiki/DesignDocs/IPAServerMode = Backup and Restore = No external configuration files are affected = Test Plan = Testing the feature will require following: # Configure IPA to serve AD trusts # Establish trust with AD domain # Configure a client to use nss_ldap/pam_ldap against AD-compatible tree # Attempt to log-in to the client as AD user = RFE Author = [[User:Ab|ab]] ([[User talk:Ab|talk]]) >>> >
Re: [Freeipa-devel] [PATCHES 0156-0158] Automatically disable empty zones when necessary
ACK. Patches look good and work as expected! Regards, Tomas Hozza - Original Message - > Hello, > > this patch set enables bind-dyndb-ldap to automatically unload empty zone > (see > RFC 6303) if an explicit configuration for this zone is present in LDAP. > > Please test it with idnsZone and also idnsForwardZone objectClasses. > > -- > Petr^2 Spacek > ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 0156-0158] Automatically disable empty zones when necessary
On 29.5.2013 16:38, Tomas Hozza wrote: ACK. Patches look good and work as expected! Pushed to master: 96f795180d182bcc008159e5ce0102af9fc8324f, 3df30edeae3e1025c899338b554460aa9f0c742e, c9cdbe34b0d9a514d2b95a295d239ce0b2a0386f -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0159] Deprecate configuration without persistent search
On 28.5.2013 15:55, Petr Spacek wrote:
Hello,
Deprecate configuration without persistent search.
https://fedorahosted.org/bind-dyndb-ldap/ticket/120
This version of the patch adds notice to the README.
--
Petr^2 Spacek
From 7b685ff7077d10c1917c5a9a97b50d77587b8f04 Mon Sep 17 00:00:00 2001
From: Petr Spacek
Date: Tue, 28 May 2013 15:54:24 +0200
Subject: [PATCH] Deprecate configuration without persistent search.
https://fedorahosted.org/bind-dyndb-ldap/ticket/120
Signed-off-by: Petr Spacek
---
README| 4 +++-
src/ldap_helper.c | 4
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/README b/README
index e25108aea464d0568098f58946ecefca5bed6c41..2b4926e3356956198f2b3b75f1f5b682f981d8d1 100644
--- a/README
+++ b/README
@@ -198,12 +198,13 @@ cache_ttl (default 120)
probably want to set this option on a higher value.
zone_refresh (default 0)
+ ! This option is DEPRECATED and will be removed in the future. !
Interval (in seconds) of how often the LDAP driver should query the
LDAP server for changes in zone settings. If this option is set to 0,
the LDAP driver will never refresh the settings.
Currently, global settings in idnsConfigObject and zone specific
settings in idnsZone attributes are refreshed.
- Value is ignored if persistent search (psearch) is enabled.
+ Zone refresh and persistent search (psearch) are mutually exclusive.
timeout (default 10)
Timeout (in seconds) of the queries to the LDAP server. If the LDAP
@@ -217,6 +218,7 @@ fake_mname (default "")
SOA record, for example.
psearch (default no)
+ ! Persistent search will be mandatory in future releases. !
Set this option to "yes" if you would like to use persistent search
query for zone records and global settings. When server supports
persistent search your zones and configuration will be automatically
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index 0de62025e67d466a5c656ce8a5d6b3042fadce67..424bc4b8afef924e92524ceca620e047380d70a4 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -386,6 +386,10 @@ validate_local_instance_settings(ldap_instance_t *inst, settings_set_t *set) {
/* watcher needs one and update_*() requests second connection */
CLEANUP_WITH(ISC_R_RANGE);
}
+ if (!psearch)
+ log_info("configuration without persistent search is deprecated "
+ "and the support for zone_refresh will be removed "
+ "in the future");
CHECK(setting_get_bool("serial_autoincrement", set, &serial_autoincrement));
if (serial_autoincrement && !psearch) {
--
1.7.11.7
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [file ipa_cldap.c, line 148]: Failed to create socket
Agreed. I was using an AD Enterprise Admin account from an "ADMIN" realm out of habit. Once I used the "Administrator" user from the "AD" realm it was fine. Thanks again. On Tue, May 28, 2013 at 4:30 AM, Alexander Bokovoy wrote: > On Tue, 28 May 2013, Nicholas MacKenzie wrote: > >> You were spot on about that. I enabled IPv6 and now the CLDAP plugin >> installs fine. I am now faced with this... >> >> dcerpc: alter_resp - rpc fault: WERR_ACCESS_DENIED >> Failed to bind to uuid 12345778-1234-abcd-ef00-**0123456789ab for >> 12345778-1234-abcd-ef00-**0123456789ab@ncacn_ip_tcp: >> domain_controller.ad.dc.com[**49500] NT_STATUS_NET_WRITE_FAULT >> [Tue May 28 08:20:03 2013] [error] ipa: INFO: ad...@ipa.dc.com: >> trust_add(u' >> ad.dc.sita.aero', trust_type=u'ad', realm_admin=u'username', >> realm_passwd=u'', range_size=20, all=False, raw=False, >> version=u'2.46'): ACIError >> > Specify your AD admin username fully-qualified, either DOMAIN\username > or username@REALM. > > -- > / Alexander Bokovoy > ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
