Re: [Freeipa-devel] [PATCH] 0060 Ensure ipa-adtrust-install is run as admin user
On Tue, 17 Jul 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Fri, 13 Jul 2012, Alexander Bokovoy wrote: Hi, when adding AD trusts support, we need to ensure we have valid kerberos ticket of the user from 'admins' group or otherwise appropriate ACIs will not be granted. This patch introduces a check for that. We already check if ipa-adtrust-install is run by root so this complements existing checks. https://fedorahosted.org/freeipa/ticket/2815 After discussing on IRC with Simo and Rob, we came to conclusion that it is possible to switch to LDAPI and autobind feature of dirsrv for authentication and remove requirement for Directory Manager credentials altogether. Updated patch makes use of LDAPI + autobind under root privileges to map automatically to Directory Manager privileges in dirsrv. Additionally it ensures we have Kerberos credentials to fetch keytab with CIFS service key. Service._ldap_mod() is extended to switch to autobind when self.ldapi is set to True and we are running as root. For those interested in why ACIError is mapped to 'outdated Kerberos credentials' error message, this is because we'll get ACIError for 'ipa user-show uid' command when authenticated by the Kerberos credentials for uid in a default ccache only when Kerberos credentials are stale -- either belong to a user that was removed or to a previous IPA install that was wiped before reinstalling. The latter is how I discovered this case. :) I think that this should raise an exception if one tries to use ldapi, doesn't provide the DM password and is not root. Otherwise it won't authenticate at all. This is not exactly true. $ id uid=75701(abokovoy) gid=75701(abokovoy) groups=75701(abokovoy) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ ldapsearch -vvv -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' /dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL EXTERNAL bind requires an SSL connection $ ldapsearch -vvv -Y GSSAPI -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' /dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/GSSAPI authentication started SASL username: abokovoy@IPA.LOCAL SASL SSF: 56 SASL data security layer installed. filter: (objectclass=*) requesting: * So GSSAPI auth works with LDAPI access. I can simply enforce -Y GSSAPI when non-root and no dm_password regardless of self.ldapi, this would extend previously available logic to following: - ldapi: use -H ldapi://url instead of -h hostname - dm_password: add Directory Manager auth - root without dm_password: use autobind - non-root without dm_password: use GSSAPI In reality, I think all this service code always runs as root, so it may be a moot point, but this code is kinda convoluted. Yep. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0032-0035]
Hello,
attached patch 0032 adds support for MODDN operation to persistent search
implementation.
Related ticket: https://fedorahosted.org/bind-dyndb-ldap/ticket/72
Patches 0033-0035 does minor cleanup in old persistent search code.
Petr^2 Spacek
From 79769c5ad71a10540cdd9b571eed9407e31da9e6 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Wed, 18 Jul 2012 13:01:28 +0200
Subject: [PATCH] Add support for modify DN operation to persistent search.
Signed-off-by: Petr Spacek pspa...@redhat.com
---
src/ldap_helper.c | 108 +++-
1 files changed, 89 insertions(+), 19 deletions(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index 8015db7018ddc9956471a99d6397ab95d83fbc3d..d49d72bc6ad23e8cec1c1f8a45135e79290b1422 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -239,6 +239,7 @@ struct ldap_psearchevent {
isc_mem_t *mctx;
char *dbname;
char *dn;
+ char *prevdn;
int chgtype;
};
@@ -316,6 +317,9 @@ static isc_result_t ldap_pscontrol_create(isc_mem_t *mctx, LDAPControl **ctrlp);
static void ldap_pscontrol_destroy(isc_mem_t *mctx, LDAPControl **ctrlp);
static isc_threadresult_t ldap_psearch_watcher(isc_threadarg_t arg);
+static void psearch_update(ldap_instance_t *inst, ldap_entry_t *entry,
+ LDAPControl **ctrls);
+
/* Persistent updates watcher */
static isc_threadresult_t
@@ -789,6 +793,7 @@ ldap_delete_zone2(ldap_instance_t *inst, dns_name_t *name, isc_boolean_t lock)
if (result == ISC_R_SUCCESS)
unlock = ISC_TRUE;
+ /* TODO: flush cache records belonging to deleted zone */
CHECK(discard_from_cache(inst-cache, name));
}
@@ -2957,37 +2962,69 @@ update_action(isc_task_t *task, isc_event_t *event)
isc_result_t result ;
ldap_instance_t *inst = NULL;
ldap_connection_t *conn = NULL;
- ldap_qresult_t *ldap_qresult = NULL;
- ldap_entry_t *entry;
+ ldap_qresult_t *ldap_qresult_zone = NULL;
+ ldap_qresult_t *ldap_qresult_record = NULL;
+ ldap_entry_t *entry_zone = NULL;
+ ldap_entry_t *entry_record = NULL;
isc_boolean_t delete = ISC_TRUE;
isc_mem_t *mctx;
- char *attrs[] = {
+ dns_name_t prevname;
+ char *attrs_zone[] = {
idnsName, idnsUpdatePolicy, idnsAllowQuery,
idnsAllowTransfer, idnsForwardPolicy, idnsForwarders, NULL
};
+ char *attrs_record[] = {
+ objectClass, dn, NULL
+ };
UNUSED(task);
mctx = pevent-mctx;
+ dns_name_init(prevname, NULL);
result = manager_get_ldap_instance(pevent-dbname, inst);
/* TODO: Can it happen? */
if (result != ISC_R_SUCCESS)
goto cleanup;
CHECK(ldap_pool_getconnection(inst-pool, conn));
-
- CHECK(ldap_query(inst, conn, ldap_qresult, pevent-dn,
- LDAP_SCOPE_BASE, attrs, 0,
+ CHECK(ldap_query(inst, conn, ldap_qresult_zone, pevent-dn,
+ LDAP_SCOPE_BASE, attrs_zone, 0,
((objectClass=idnsZone)(idnsZoneActive=TRUE;
- for (entry = HEAD(ldap_qresult-ldap_entries);
- entry != NULL;
- entry = NEXT(entry, link)) {
+ for (entry_zone = HEAD(ldap_qresult_zone-ldap_entries);
+ entry_zone != NULL;
+ entry_zone = NEXT(entry_zone, link)) {
delete = ISC_FALSE;
result = ldap_parse_zoneentry(entry, inst);
if (result != ISC_R_SUCCESS)
goto cleanup;
+
+ if (PSEARCH_MODDN(pevent-chgtype)) {
+ if (dn_to_dnsname(inst-mctx, pevent-prevdn, prevname, NULL)
+ == ISC_R_SUCCESS) {
+CHECK(ldap_delete_zone(inst, pevent-prevdn, ISC_TRUE));
+ } else {
+log_debug(5, update_action: old zone wasn't managed
+ by plugin, dn '%s', pevent-prevdn);
+ }
+
+ /* fill the cache with records from renamed zone */
+ CHECK(ldap_query(inst, conn, ldap_qresult_record, pevent-dn,
+ LDAP_SCOPE_ONELEVEL, attrs_record, 0,
+ (objectClass=idnsRecord)));
+
+ /* LDAP schema requires SOA record (at least) */
+ INSIST(HEAD(ldap_qresult_record-ldap_entries) != NULL);
+ for (entry_record = HEAD(ldap_qresult_record-ldap_entries);
+ entry_record != NULL;
+ entry_record = NEXT(entry_record, link)) {
+
+psearch_update(inst, entry_record, NULL);
+ }
+ }
+
+ INSIST(NEXT(entry_zone, link) == NULL); /* no multiple zones with same DN */
}
if (delete)
@@ -2999,9 +3036,14 @@ cleanup:
Zones can be outdated, run `rndc reload`,
pevent-dn, isc_result_totext(result));
- ldap_query_free(ISC_FALSE, ldap_qresult);
+ ldap_query_free(ISC_FALSE, ldap_qresult_zone);
+ ldap_query_free(ISC_FALSE, ldap_qresult_record);
ldap_pool_putconnection(inst-pool, conn);
+ if (dns_name_dynamic(prevname))
+ dns_name_free(prevname, inst-mctx);
isc_mem_free(mctx, pevent-dbname);
+ if (pevent-prevdn != NULL)
+ isc_mem_free(mctx, pevent-prevdn);
isc_mem_free(mctx, pevent-dn);
isc_mem_detach(mctx);
isc_event_free(event);
@@ -3090,8 +3132,12 @@ update_record(isc_task_t *task, isc_event_t *event)
/* Convert domain name from text to struct dns_name_t. */
dns_name_t name;
dns_name_t origin;
+ dns_name_t prevname;
+ dns_name_t prevorigin;
dns_name_init(name, NULL);
Re: [Freeipa-devel] DN patch and documentation
On 07/18/2012 12:47 AM, John Dennis wrote: On 07/10/2012 04:23 AM, Petr Viktorin wrote: I've read your summary (which you should summarize into a commit message before this is pushed), and gone through the patch. Here is what I found doing that; I didn't get to actual testing yet. I also didn't do a detailed review of ldap2.py changes yet. Thank you for your careful review Petr, you had many good suggestions and comments. It was an enormous amount of material to wade through, thank you for your diligence. I'm in agreement with most of your suggestions. Great :) I don't have much to reply, I mostly agree too. [...] Originally I was against automatic type promotion on the belief if you were comparing a string to a DN it was a failure of program logic, but there were some circumstances where it was evil necessity. Would you care to elaborate? I also think that's a logic failure; such circumstances should at least be marked by a TODO. I should have taken better notes because I don't remember the exact place this came up, it was late in the testing and I believe the problem showed up in the ldap updater, possibly some other places. But here is the bottom line: I encountered a handful of places in the code where a string was being compared to a DN object for equality (I seem to recall the equality comparison was indirect by virtue of the in operator). What I do recall is it was logically impossible to know a prori the string being tested was supposed to be a DN. If it were possible to know the string represented a DN it would have been easy to promote it to a DN object. But there were a handful of situations where there simply was not enough information available to ascertain if the string was logically a DN or not. This was never an issue when dn's were simple strings. If it's getting compared to a DN that's a pretty strong hint it's supposed to be a DN (fwiw the coercion must occur in the equality operator). So I pondered the problem for a while and decided there was legitimate value in allowing an equality comparison between a string and DN. I could see no downside to it other than it *might* mask an error in program logic. I didn't take the decision lightly. I looked through the Python internals to see where type coercion occurs. While not often it's certainly done where it makes sense (e.g. between string types, between numerical types, between buffer types, etc.). I thought one could make the argument that a DN object is akin to a string type and hence falls into the same category of coercion as occurs between string types. I'm not saying I'm in love with it, rather it's a pragmatic necessity and can be justified if you look at it a certain way. We could add a debug message with a backtrace whenever the coercion occurs if we wanted to completely eliminate all places in the code where a string-to-DN comparison occurs. But as I said I'm not sure it's possible to absolutely eliminate this comparison. We've eliminated 99.9% of those cases already, I'm not sure the other 0.1% can be eliminated or that it's worth the work involved. I'm happy with 99.9% :-) Fair enough. The find() and rfind() methods (modeled after their string cousins) to locate a RDN or DN in an existing DN. I would much rather see the index() and rindex() methods, which do the Pythonic thing of raising an exception rather than silently returning -1 when the thing isn't found. Compare: something[something.find(thing)] = something[-1] if not found something[something.index(thing)] = raises exception if not found You're right exceptions are more Pythoninc than return codes. I can add index and rindex and convert the code to catch an exception. However, we use find and rfind extensively in the IPA code base (DN.find() and DN.rfind() simply replaced their string equivalents during the conversion). Perhaps you should open a ticket to purge all use of find() and rfind() from our code base and add a prohibition against their use in our Python coding standard document. I don't think it's that urgent. ipapython/dn.py:448: Each argument must be scalar convertable to unicode or a callable object whose result is convertable to unicode. Is it really necessary to allow callables here? If the user has a callable, he/she should call it before making an AVA out of it. Same with converting to Unicode. As you point out in dn_summary, automatic coercion is evil. There are two issues here, type coercion and string encoding. Not all coercion is evil, there is value in making it easy to do the right thing and minimizing inline coercion that otherwise obfuscates the logical intent of the code. We shouldn't require programmers to be perfect coders who never forget to perform some operation in the hundreds of places it might be required. Rather the tools should quietly and consistently enforce the rules while leaving the code readable, concise and with clear intent. There is a well established precedent in
Re: [Freeipa-devel] [PATCH 0032-0035] Add support for MODDN operation to persistent search implementation
Sorry for the missing subject! Petr^2 Spacek On 07/18/2012 01:32 PM, Petr Spacek wrote: adds support for MODDN operation to persistent search implementation ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0056 Framework for admin/install tools, with ipa-ldap-updater
On 07/17/2012 10:41 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 06/29/2012 11:28 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 06/25/2012 03:00 PM, Petr Viktorin wrote: On 06/20/2012 06:15 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 06/04/2012 04:56 PM, Petr Viktorin wrote: Currently, FreeIPA's install/admin scripts are long pieces of code that aren't very reusable, importable, or testable. They have been extended over time with features such as logging and error handling, but since each tool was extended individually, there is much inconsistency and code duplication. This patch starts a framework which the admin tools can use, and converts ipa-ldap-updater to use the framework. In an earlier patch I found that improving a particular functionality in all the commands is not workable, so I want to tackle this one tool at a time. I'm starting with ipa-ldap-updater, because it's pretty small, doesn't use DNs (I don't want conflicts with John's work), and has the interesting --upgrade option. The framework does these tasks: - Parse options - Select tool to run (see below) - Validate options - Set up logging - Run the tool code - Handle any errors - Log success/failure The base class has some defaults for these that the tools can extend/override. To handle the case where one script does two different things (ipa-ldap-updater with/without --upgrade, or ipa-server-install with/without --uninstall), I want to split the tool in two classes rather than have repeated ifs in the code. This meant that option parsing (and initializing the parser) has to be done before creating an instance of the tool. I use a factory classmethod. I put the admintool base class in ipapython/ as it should be useful for ipa-client-install as well. First part of the work for: https://fedorahosted.org/freeipa/ticket/2652 Attaching rebased patch. I gather you want people to be calling run_cli() in their admin tools. Should main() be made private then? I could see someone getting confused and using main instead, which would work, but then the return value might not do the right thing. Or maybe just drop run_cli and have main exit with sys.exit()? I don't see why running a command as a Python function should be discouraged. In fact it could even help -- for example logging could only be set up once, so if we call, say, ipa-ldap-updater from ipa-server-install, all related logs would go to a single file. A C-style main (taking a list of arguments and returning the exit status) is a good thing for modularity and testability. The `run_cli` method is just a convenient shortcut for the usual usage, so the calling modules can be as small as possible. If people get confused and call main instead of run_cli, they need to manually pass in sys.argv. I think this is enough of a warning that their assumptions aren't right. To make it even clearer I've removed the possibility to pass None as argv to main() and have it auto-filled. Some relevant reading: http://www.artima.com/weblogs/viewpost.jsp?thread=4829 (old but still valid) http://en.wikipedia.org/wiki/Main_function#Python It isn't correctly handling the case of an update not found: ipa : INFO Parsing file ad [Errno 2] No such file or directory: 'ad' ipa : INFO File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 151, in execute self.run() File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py, line 180, in run modified = ld.update(self.files) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 828, in update sys.exit(1) ipa : INFO The ipa-ldap-updater command failed, exception: SystemExit: 1 I've added validation for missing files, and improved the error message ldapupdate raises (for cases the validation doesn't catch, like passing directories or unreadable files). Ideally ldapupdate would not try to handle the error itself, but that code is used in more places that I don't want to break, so I'm leaving the extraneous print in. Running in test mode with the attached update doesn't seem to work either. There is nothing special about this file, just something I had lying around: ipa : INFO File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 151, in execute self.run() File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py, line 184, in run 'Update complete, changes to be made, test mode', 2) ipa : INFO The ipa-ldap-updater command failed, exception: ScriptError: Update complete, changes to be made, test mode ipa : ERROR Update complete, changes to be made, test mode ipa : ERROR None Fixed. The unit tests still pass which is good. With ipa-ldap-updater the return value is a bit strange. All the updates themselves can fail for one reason or another and the command can still consider this a success (it may fail because a feature is not enabled, for example). Still, the success message displayed at the end is a bit jarring when the updates
[Freeipa-devel] [PATCH 0036] Raise connection count automatically if serial_autoincrement is enabled
Hello,
this patch reflects new demand from serial_autoincrement feature.
Generally, change in configuration file should by IPA install/upgrade scripts.
This patch prevents deadlock in situation where scripts failed in their job
(as you can see right now).
Will be obsoleted by https://fedorahosted.org/bind-dyndb-ldap/ticket/68 .
Petr^2 Spacek
From b41d06248a199e618fd963f32cf16d2c8384276f Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Wed, 18 Jul 2012 13:39:12 +0200
Subject: [PATCH] Raise connection count automatically if serial_autoincrement
is enabled.
Signed-off-by: Petr Spacek pspa...@redhat.com
---
src/ldap_helper.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index 8015db7018ddc9956471a99d6397ab95d83fbc3d..a51a9fe384b7133b06b50a8ff498755d37dafffe 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -480,6 +480,12 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name,
result = ISC_R_FAILURE;
goto cleanup;
}
+ if (ldap_inst-serial_autoincrement == ISC_TRUE
+ ldap_inst-connections 4) {
+ log_error(serial_autoincrement needs at least 4 connections,
+ increasing limit);
+ ldap_inst-connections = 4;
+ }
CHECK(new_ldap_cache(mctx, argv, ldap_inst-cache, ldap_inst-psearch));
CHECK(ldap_pool_create(mctx, ldap_inst-connections, ldap_inst-pool));
--
1.7.7.6
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0037] Add missing return value check to new_ldap_instance()
Hello,
this patch adds missing return value check to new_ldap_instance().
https://fedorahosted.org/bind-dyndb-ldap/ticket/85
Bug was reported by Coverity.
Petr^2 Spacek
From 85574b9ffe4757b93b6eb9b99ceb1172a5c37002 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Wed, 18 Jul 2012 14:32:48 +0200
Subject: [PATCH] Add missing return value check to new_ldap_instance().
Signed-off-by: Petr Spacek pspa...@redhat.com
---
src/ldap_helper.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index a51a9fe384b7133b06b50a8ff498755d37dafffe..f21c449bbfe7e0cb7718ae5479989db16c103958 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -454,7 +454,8 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name,
result = ISC_R_FAILURE;
goto cleanup;
} else {
- str_sprintf(ldap_inst-krb5_principal, DNS/%s, hostname);
+ CHECK(str_sprintf(ldap_inst-krb5_principal,
+ DNS/%s, hostname));
log_debug(2, SASL mech GSSAPI defined but krb5_principal
and sasl_user are empty, using default %s,
str_buf(ldap_inst-krb5_principal));
--
1.7.7.6
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0060 Ensure ipa-adtrust-install is run as admin user
On Wed, 18 Jul 2012, Alexander Bokovoy wrote: On Tue, 17 Jul 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Fri, 13 Jul 2012, Alexander Bokovoy wrote: Hi, when adding AD trusts support, we need to ensure we have valid kerberos ticket of the user from 'admins' group or otherwise appropriate ACIs will not be granted. This patch introduces a check for that. We already check if ipa-adtrust-install is run by root so this complements existing checks. https://fedorahosted.org/freeipa/ticket/2815 After discussing on IRC with Simo and Rob, we came to conclusion that it is possible to switch to LDAPI and autobind feature of dirsrv for authentication and remove requirement for Directory Manager credentials altogether. Updated patch makes use of LDAPI + autobind under root privileges to map automatically to Directory Manager privileges in dirsrv. Additionally it ensures we have Kerberos credentials to fetch keytab with CIFS service key. Service._ldap_mod() is extended to switch to autobind when self.ldapi is set to True and we are running as root. For those interested in why ACIError is mapped to 'outdated Kerberos credentials' error message, this is because we'll get ACIError for 'ipa user-show uid' command when authenticated by the Kerberos credentials for uid in a default ccache only when Kerberos credentials are stale -- either belong to a user that was removed or to a previous IPA install that was wiped before reinstalling. The latter is how I discovered this case. :) I think that this should raise an exception if one tries to use ldapi, doesn't provide the DM password and is not root. Otherwise it won't authenticate at all. This is not exactly true. $ id uid=75701(abokovoy) gid=75701(abokovoy) groups=75701(abokovoy) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ ldapsearch -vvv -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' /dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL EXTERNAL bind requires an SSL connection $ ldapsearch -vvv -Y GSSAPI -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' /dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/GSSAPI authentication started SASL username: abokovoy@IPA.LOCAL SASL SSF: 56 SASL data security layer installed. filter: (objectclass=*) requesting: * So GSSAPI auth works with LDAPI access. I can simply enforce -Y GSSAPI when non-root and no dm_password regardless of self.ldapi, this would extend previously available logic to following: - ldapi: use -H ldapi://url instead of -h hostname - dm_password: add Directory Manager auth - root without dm_password: use autobind - non-root without dm_password: use GSSAPI In reality, I think all this service code always runs as root, so it may be a moot point, but this code is kinda convoluted. Yep. Here is updated patch. -- / Alexander Bokovoy From 81b1e0305ac8ad3516bb7bcaeb13999480e0f14f Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy aboko...@redhat.com Date: Fri, 13 Jul 2012 18:12:48 +0300 Subject: [PATCH 2/5] Ensure ipa-adtrust-install is run with Kerberos ticket for admin user When setting up AD trusts support, ipa-adtrust-install utility needs to be run as: - root, for performing Samba configuration and using LDAPI/autobind - kinit-ed IPA admin user, to ensure proper ACIs are granted to fetch keytab As result, we can get rid of Directory Manager credentials in ipa-adtrust-install https://fedorahosted.org/freeipa/ticket/2815 --- install/tools/ipa-adtrust-install | 42 +++ install/tools/man/ipa-adtrust-install.1 |3 --- ipaserver/install/adtrustinstance.py| 21 ipaserver/install/service.py| 15 +-- 4 files changed, 55 insertions(+), 26 deletions(-) diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install index 6678018e6346d75d5042894cfb833d38079d3f21..f367d5b2b516bd411bce9275ff299eb3ffdf6bf9 100755 --- a/install/tools/ipa-adtrust-install +++ b/install/tools/ipa-adtrust-install @@ -37,8 +37,6 @@ log_file_name = /var/log/ipaserver-install.log def parse_options(): parser = IPAOptionParser(version=version.VERSION) -parser.add_option(-p, --ds-password, dest=dm_password, - sensitive=True, help=directory manager password) parser.add_option(-d, --debug, dest=debug, action=store_true, default=False, help=print debugging information) parser.add_option(--ip-address, dest=ip_address, @@ -86,6 +84,30 @@ def read_netbios_name(netbios_default): return netbios_name +def ensure_kerberos_admin_rights(api): +try: +ctx = krbV.default_context() +ccache = ctx.default_ccache() +principal = ccache.principal() +
[Freeipa-devel] [PATCH] 0063 change sid_check_is_domain() to sid_check_is_our_sam()
Hi,
due to API change in Samba4 between beta3 and beta4, following small
patch is needed for ipasam.
I've also added forward declaration for the function.
https://fedorahosted.org/freeipa/ticket/2929
--
/ Alexander Bokovoy
From d58b997587551744515c50e019148adf005f5c3f Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
Date: Wed, 18 Jul 2012 15:52:33 +0300
Subject: [PATCH 5/5] Follow change in samba4 beta4 for sid_check_is_domain to
sid_check_is_our_sam
With c43505b621725c9a754f0ee98318d451b093f2ed in samba git master
the function sid_check_is_domain() was renamed to sid_check_is_our_sam().
https://fedorahosted.org/freeipa/ticket/2929
---
daemons/ipa-sam/ipa_sam.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c
index
86ed3fbd3e6d1894fd398c3c1c94d34c2b7ec273..ab4b116c5f2b3b8dae6e8309403afba5fdf86708
100644
--- a/daemons/ipa-sam/ipa_sam.c
+++ b/daemons/ipa-sam/ipa_sam.c
@@ -83,6 +83,8 @@ enum ndr_err_code ndr_pull_trustAuthInOutBlob(struct ndr_pull
*ndr, int ndr_flag
bool fetch_ldap_pw(char **dn, char** pw); /* available in libpdb.so */
void nt_lm_owf_gen(const char *pwd, uint8_t nt_p16[16], uint8_t p16[16]); /*
available in libcliauth.so */
bool sid_check_is_builtin(const struct dom_sid *sid); /* available in
libpdb.so */
+/* available in libpdb.so, renamed from sid_check_is_domain() in
c43505b621725c9a754f0ee98318d451b093f2ed */
+bool sid_check_is_our_sam(const struct dom_sid *sid);
void strlower_m(char *s); /* available in libutil_str.so */
char *talloc_asprintf_strupper_m(TALLOC_CTX *t, const char *fmt, ...); /*
available in libutil_str.so */
void sid_copy(struct dom_sid *dst, const struct dom_sid *src); /* available in
libsecurity.so */
@@ -300,7 +302,7 @@ static NTSTATUS ldapsam_lookup_rids(struct pdb_methods
*methods,
}
if (!sid_check_is_builtin(domain_sid)
- !sid_check_is_domain(domain_sid)) {
+ !sid_check_is_our_sam(domain_sid)) {
result = NT_STATUS_INVALID_PARAMETER;
goto done;
}
--
1.7.10.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0060 Ensure ipa-adtrust-install is run as admin user
Alexander Bokovoy wrote: On Tue, 17 Jul 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Fri, 13 Jul 2012, Alexander Bokovoy wrote: Hi, when adding AD trusts support, we need to ensure we have valid kerberos ticket of the user from 'admins' group or otherwise appropriate ACIs will not be granted. This patch introduces a check for that. We already check if ipa-adtrust-install is run by root so this complements existing checks. https://fedorahosted.org/freeipa/ticket/2815 After discussing on IRC with Simo and Rob, we came to conclusion that it is possible to switch to LDAPI and autobind feature of dirsrv for authentication and remove requirement for Directory Manager credentials altogether. Updated patch makes use of LDAPI + autobind under root privileges to map automatically to Directory Manager privileges in dirsrv. Additionally it ensures we have Kerberos credentials to fetch keytab with CIFS service key. Service._ldap_mod() is extended to switch to autobind when self.ldapi is set to True and we are running as root. For those interested in why ACIError is mapped to 'outdated Kerberos credentials' error message, this is because we'll get ACIError for 'ipa user-show uid' command when authenticated by the Kerberos credentials for uid in a default ccache only when Kerberos credentials are stale -- either belong to a user that was removed or to a previous IPA install that was wiped before reinstalling. The latter is how I discovered this case. :) I think that this should raise an exception if one tries to use ldapi, doesn't provide the DM password and is not root. Otherwise it won't authenticate at all. This is not exactly true. $ id uid=75701(abokovoy) gid=75701(abokovoy) groups=75701(abokovoy) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ ldapsearch -vvv -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' /dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL EXTERNAL bind requires an SSL connection $ ldapsearch -vvv -Y GSSAPI -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' /dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/GSSAPI authentication started SASL username: abokovoy@IPA.LOCAL SASL SSF: 56 SASL data security layer installed. filter: (objectclass=*) requesting: * So GSSAPI auth works with LDAPI access. I can simply enforce -Y GSSAPI when non-root and no dm_password regardless of self.ldapi, this would extend previously available logic to following: - ldapi: use -H ldapi://url instead of -h hostname - dm_password: add Directory Manager auth - root without dm_password: use autobind - non-root without dm_password: use GSSAPI In reality, I think all this service code always runs as root, so it may be a moot point, but this code is kinda convoluted. Yep. Sorry, I didn't mean this in general, but this code is going to result in no auth being used which is going to fail. So rather than failing with some no auth error we either enforce that Service is executed as root or raise an exception in this auth code. In other words, if we know something isn't going to work before we try it, we should fail with a more friendly error. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0063 change sid_check_is_domain() to sid_check_is_our_sam()
On Wed, 2012-07-18 at 15:58 +0300, Alexander Bokovoy wrote: Hi, due to API change in Samba4 between beta3 and beta4, following small patch is needed for ipasam. I've also added forward declaration for the function. https://fedorahosted.org/freeipa/ticket/2929 Nack, please add build requires in spec file to require beta4. Please consider it acked automatically as soon as you do that and then please push asap. 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] [PATCH] 0060 Ensure ipa-adtrust-install is run as admin user
On Wed, 18 Jul 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Tue, 17 Jul 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Fri, 13 Jul 2012, Alexander Bokovoy wrote: Hi, when adding AD trusts support, we need to ensure we have valid kerberos ticket of the user from 'admins' group or otherwise appropriate ACIs will not be granted. This patch introduces a check for that. We already check if ipa-adtrust-install is run by root so this complements existing checks. https://fedorahosted.org/freeipa/ticket/2815 After discussing on IRC with Simo and Rob, we came to conclusion that it is possible to switch to LDAPI and autobind feature of dirsrv for authentication and remove requirement for Directory Manager credentials altogether. Updated patch makes use of LDAPI + autobind under root privileges to map automatically to Directory Manager privileges in dirsrv. Additionally it ensures we have Kerberos credentials to fetch keytab with CIFS service key. Service._ldap_mod() is extended to switch to autobind when self.ldapi is set to True and we are running as root. For those interested in why ACIError is mapped to 'outdated Kerberos credentials' error message, this is because we'll get ACIError for 'ipa user-show uid' command when authenticated by the Kerberos credentials for uid in a default ccache only when Kerberos credentials are stale -- either belong to a user that was removed or to a previous IPA install that was wiped before reinstalling. The latter is how I discovered this case. :) I think that this should raise an exception if one tries to use ldapi, doesn't provide the DM password and is not root. Otherwise it won't authenticate at all. This is not exactly true. $ id uid=75701(abokovoy) gid=75701(abokovoy) groups=75701(abokovoy) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ ldapsearch -vvv -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' /dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL EXTERNAL bind requires an SSL connection $ ldapsearch -vvv -Y GSSAPI -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' /dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/GSSAPI authentication started SASL username: abokovoy@IPA.LOCAL SASL SSF: 56 SASL data security layer installed. filter: (objectclass=*) requesting: * So GSSAPI auth works with LDAPI access. I can simply enforce -Y GSSAPI when non-root and no dm_password regardless of self.ldapi, this would extend previously available logic to following: - ldapi: use -H ldapi://url instead of -h hostname - dm_password: add Directory Manager auth - root without dm_password: use autobind - non-root without dm_password: use GSSAPI In reality, I think all this service code always runs as root, so it may be a moot point, but this code is kinda convoluted. Yep. Sorry, I didn't mean this in general, but this code is going to result in no auth being used which is going to fail. So rather than failing with some no auth error we either enforce that Service is executed as root or raise an exception in this auth code. In other words, if we know something isn't going to work before we try it, we should fail with a more friendly error. What the code did before in such case (no DM, non-root, non-ldapi) is to use -Y GSSAPI. So this forces to try GSSAPI auth already. My latest patch (-2) expands this also to (no DM, non-root, ldapi) case. However, one case is not covered yet: no DM, root, non-ldapi. We either can try -Y GSSAPI here as well or raise exception. I'd prefer the former. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0060 Ensure ipa-adtrust-install is run as admin user
On Wed, 2012-07-18 at 16:19 +0300, Alexander Bokovoy wrote: On Wed, 18 Jul 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Tue, 17 Jul 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Fri, 13 Jul 2012, Alexander Bokovoy wrote: Hi, when adding AD trusts support, we need to ensure we have valid kerberos ticket of the user from 'admins' group or otherwise appropriate ACIs will not be granted. This patch introduces a check for that. We already check if ipa-adtrust-install is run by root so this complements existing checks. https://fedorahosted.org/freeipa/ticket/2815 After discussing on IRC with Simo and Rob, we came to conclusion that it is possible to switch to LDAPI and autobind feature of dirsrv for authentication and remove requirement for Directory Manager credentials altogether. Updated patch makes use of LDAPI + autobind under root privileges to map automatically to Directory Manager privileges in dirsrv. Additionally it ensures we have Kerberos credentials to fetch keytab with CIFS service key. Service._ldap_mod() is extended to switch to autobind when self.ldapi is set to True and we are running as root. For those interested in why ACIError is mapped to 'outdated Kerberos credentials' error message, this is because we'll get ACIError for 'ipa user-show uid' command when authenticated by the Kerberos credentials for uid in a default ccache only when Kerberos credentials are stale -- either belong to a user that was removed or to a previous IPA install that was wiped before reinstalling. The latter is how I discovered this case. :) I think that this should raise an exception if one tries to use ldapi, doesn't provide the DM password and is not root. Otherwise it won't authenticate at all. This is not exactly true. $ id uid=75701(abokovoy) gid=75701(abokovoy) groups=75701(abokovoy) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ ldapsearch -vvv -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' /dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL EXTERNAL bind requires an SSL connection $ ldapsearch -vvv -Y GSSAPI -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' /dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/GSSAPI authentication started SASL username: abokovoy@IPA.LOCAL SASL SSF: 56 SASL data security layer installed. filter: (objectclass=*) requesting: * So GSSAPI auth works with LDAPI access. I can simply enforce -Y GSSAPI when non-root and no dm_password regardless of self.ldapi, this would extend previously available logic to following: - ldapi: use -H ldapi://url instead of -h hostname - dm_password: add Directory Manager auth - root without dm_password: use autobind - non-root without dm_password: use GSSAPI In reality, I think all this service code always runs as root, so it may be a moot point, but this code is kinda convoluted. Yep. Sorry, I didn't mean this in general, but this code is going to result in no auth being used which is going to fail. So rather than failing with some no auth error we either enforce that Service is executed as root or raise an exception in this auth code. In other words, if we know something isn't going to work before we try it, we should fail with a more friendly error. What the code did before in such case (no DM, non-root, non-ldapi) is to use -Y GSSAPI. So this forces to try GSSAPI auth already. My latest patch (-2) expands this also to (no DM, non-root, ldapi) case. However, one case is not covered yet: no DM, root, non-ldapi. We either can try -Y GSSAPI here as well or raise exception. I'd prefer the former. When in doubt always try GSSAPI please. 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] [PATCH] 0060 Ensure ipa-adtrust-install is run as admin user
On Wed, 18 Jul 2012, Simo Sorce wrote: On Wed, 2012-07-18 at 16:19 +0300, Alexander Bokovoy wrote: On Wed, 18 Jul 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Tue, 17 Jul 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: On Fri, 13 Jul 2012, Alexander Bokovoy wrote: Hi, when adding AD trusts support, we need to ensure we have valid kerberos ticket of the user from 'admins' group or otherwise appropriate ACIs will not be granted. This patch introduces a check for that. We already check if ipa-adtrust-install is run by root so this complements existing checks. https://fedorahosted.org/freeipa/ticket/2815 After discussing on IRC with Simo and Rob, we came to conclusion that it is possible to switch to LDAPI and autobind feature of dirsrv for authentication and remove requirement for Directory Manager credentials altogether. Updated patch makes use of LDAPI + autobind under root privileges to map automatically to Directory Manager privileges in dirsrv. Additionally it ensures we have Kerberos credentials to fetch keytab with CIFS service key. Service._ldap_mod() is extended to switch to autobind when self.ldapi is set to True and we are running as root. For those interested in why ACIError is mapped to 'outdated Kerberos credentials' error message, this is because we'll get ACIError for 'ipa user-show uid' command when authenticated by the Kerberos credentials for uid in a default ccache only when Kerberos credentials are stale -- either belong to a user that was removed or to a previous IPA install that was wiped before reinstalling. The latter is how I discovered this case. :) I think that this should raise an exception if one tries to use ldapi, doesn't provide the DM password and is not root. Otherwise it won't authenticate at all. This is not exactly true. $ id uid=75701(abokovoy) gid=75701(abokovoy) groups=75701(abokovoy) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ ldapsearch -vvv -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' /dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Inappropriate authentication (48) additional info: SASL EXTERNAL bind requires an SSL connection $ ldapsearch -vvv -Y GSSAPI -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket '*' /dev/null ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-IPA-LOCAL.socket/??base ) SASL/GSSAPI authentication started SASL username: abokovoy@IPA.LOCAL SASL SSF: 56 SASL data security layer installed. filter: (objectclass=*) requesting: * So GSSAPI auth works with LDAPI access. I can simply enforce -Y GSSAPI when non-root and no dm_password regardless of self.ldapi, this would extend previously available logic to following: - ldapi: use -H ldapi://url instead of -h hostname - dm_password: add Directory Manager auth - root without dm_password: use autobind - non-root without dm_password: use GSSAPI In reality, I think all this service code always runs as root, so it may be a moot point, but this code is kinda convoluted. Yep. Sorry, I didn't mean this in general, but this code is going to result in no auth being used which is going to fail. So rather than failing with some no auth error we either enforce that Service is executed as root or raise an exception in this auth code. In other words, if we know something isn't going to work before we try it, we should fail with a more friendly error. What the code did before in such case (no DM, non-root, non-ldapi) is to use -Y GSSAPI. So this forces to try GSSAPI auth already. My latest patch (-2) expands this also to (no DM, non-root, ldapi) case. However, one case is not covered yet: no DM, root, non-ldapi. We either can try -Y GSSAPI here as well or raise exception. I'd prefer the former. When in doubt always try GSSAPI please. This gets us back to my patch (-1) because -auth_parms = [-Y, GSSAPI] +auth_params = [] +if not (os.getegid() == 0 and self.ldapi): +auth_parms = [-Y, GSSAPI] covers both (no DM, root, non-ldapi) and (no DM, non-root, non-ldapi) -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0061 ValidationError takes 'error' named argument, not 'reason'
On Tue, 17 Jul 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: Hi, https://fedorahosted.org/freeipa/ticket/2865 ACK Pushed to master -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0062 support various forms of user account when establishing trusts
On Tue, 17 Jul 2012, Rob Crittenden wrote: Alexander Bokovoy wrote: Hi, Realm administrator account may be specified using different form: Administrator, DOM\Administrator, Administrator@DOMAIN This patch introduces handling of the second two forms: - In DOM\Administrator only user name is used, short domain name is then taken from a discovered record from the AD DC - In Administrator@DOMAIN first DOMAIN is verified to be the same as the domain we are establishing trust to, and then user name is taken, together with short domain name taken from a discovered record from the AD DC Note that we do not support using to-be-trusted domain's trusted domains' accounts to establish trust as there is basically zero chance to verify that things will work with them. In addition, in order to establish trust one needs to belong to Enterprise Admins group in AD or have specially delegated permissions. These permissions are unlikely delegated to the ones in already trusted domain. https://fedorahosted.org/freeipa/ticket/2864 ACK Pushed to master. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 172 Bigger textarea for permission type=subtree
On 07/17/2012 04:57 PM, Endi Sukma Dewata wrote:
On 7/17/2012 9:25 AM, Petr Vobornik wrote:
Possible improvement, instead of using a fixed column size the text area
also could be made to occupy 100% of available width. Ideally it should
have the same width as the text field or drop down list in this dialog.
Updated patch attached.
I added two styles:
.textarea-widget textarea {
width: 250px;
}
.facet-content .textarea-widget textarea {
width: 400px;
}
First one makes textarea width the same as text_widget - good for
dialogs.
Second one makes textareas wider in facets. IMO it is better - more
space for the text. Also previous implementation was about 330px in FF
so it isn't big difference. 400px is about the same width as ssh-key
widget and in also leaves space for possible action panel.
Looks much better. ACK.
Pushed to master.
--
Petr Vobornik
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0063 change sid_check_is_domain() to sid_check_is_our_sam()
On Wed, 18 Jul 2012, Simo Sorce wrote: On Wed, 2012-07-18 at 15:58 +0300, Alexander Bokovoy wrote: Hi, due to API change in Samba4 between beta3 and beta4, following small patch is needed for ipasam. I've also added forward declaration for the function. https://fedorahosted.org/freeipa/ticket/2929 Nack, please add build requires in spec file to require beta4. Please consider it acked automatically as soon as you do that and then please push asap. Pushed to master. Currently it only will build against ipa-devel repo as somehow Rawhide hasn't yet picked up http://kojipkgs.fedoraproject.org/packages/samba4/4.0.0/128.fc18.beta4/ -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] one-liner, don't hardcode serial_autoincrement
The bind option serial_autoincrement was being hardcoded to True so passing in an install option to not enable it was not working. Pushed as a one-liner. rob From 77b854fbf3f0e0d0c9780db997500a2982889107 Mon Sep 17 00:00:00 2001 From: Rob Crittenden rcrit...@redhat.com Date: Wed, 18 Jul 2012 10:32:50 -0400 Subject: [PATCH] Don't hardcode serial_autoincrement to True. https://fedorahosted.org/freeipa/ticket/2554 --- ipaserver/install/bindinstance.py |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipaserver/install/bindinstance.py b/ipaserver/install/bindinstance.py index 9faf17698d3cb806ed601f728c3870bfe28c9424..c348cdbb278f222dfbc034cbe1220df26262cb9d 100644 --- a/ipaserver/install/bindinstance.py +++ b/ipaserver/install/bindinstance.py @@ -480,7 +480,7 @@ class BindInstance(service.Service): self.reverse_zone = reverse_zone self.zone_refresh = zone_refresh self.persistent_search = persistent_search -self.serial_autoincrement = True +self.serial_autoincrement = serial_autoincrement if not zonemgr: self.zonemgr = 'hostmaster.%s' % self.domain -- 1.7.10.4 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 495 Fix ipa-replica-manage issues
Simo Sorce wrote: These 2 patches fix issues found with ipa-replica-manage and connect/disconnect commands. Fixes ticket #2925 Simo. ACK, pushed both to master. I slightly reformatted the commit messages. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0070 Fix updating minimum_connections in ipa-upgradeconfig
Petr Viktorin wrote: minimum_connections was sometimes not updated properly on install because the script set psearch on but assumed it was still off. Also, the number of connections was not set if the directive was missing. Fix of the patch for https://fedorahosted.org/freeipa/ticket/2554 Your changes look good but I found perhaps another bug. I think Petr Spacek may need to chime in on this part. If you start out with serial_autoincrement yes and psearch undefined and connections undefined the result is: connections 2 There is a comment in the code that connections needs to be 4 for autoincrement. I believe psearch needs to be enabled for autoincrement. I'm not sure how much sanity checking we want to do, mostly I'm curious if things will blow up with connections 2 and no psearch and autoincrement. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
