Re: [Freeipa-devel] [PATCH 0026-0028] Fix nits in user-visible output
On 04/13/2015 05:05 PM, Petr Spacek wrote: Hello, documentation team proposed few changes in user-visible messages so here it is. It was not worth a ticket and related overhead. The changes look OK to me. I would just have one (prudish) request to not add nazi reference to our git history - whether they are grammar or not. Please keep the git technical :-) -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0026-0028] Fix nits in user-visible output
On 14.4.2015 09:10, Martin Kosek wrote:
On 04/13/2015 05:05 PM, Petr Spacek wrote:
Hello,
documentation team proposed few changes in user-visible messages so here it
is. It was not worth a ticket and related overhead.
The changes look OK to me. I would just have one (prudish) request to not add
nazi reference to our git history - whether they are grammar or not. Please
keep the git technical :-)
Sure, here is the same patch with modified commit message.
--
Petr^2 Spacek
From c929e416a51f7c8b15f8776bb760708546c30230 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Mon, 13 Apr 2015 16:59:50 +0200
Subject: [PATCH] Grammar fix in 'Estimated time' messages printed by installer
Proposed by Tomas Capek.
---
ipaserver/install/service.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipaserver/install/service.py b/ipaserver/install/service.py
index 5a04ef323c1e89588a746603b52cbb4b9cdb8496..e4e5dd3ac304676df41dff2889eead8d8e253ecf 100644
--- a/ipaserver/install/service.py
+++ b/ipaserver/install/service.py
@@ -367,7 +367,7 @@ class Service(object):
end_message = Done configuring %s. % self.service_desc
if runtime 0:
-self.print_msg('%s: Estimated time %s' % (start_message,
+self.print_msg('%s. Estimated time: %s' % (start_message,
format_seconds(runtime)))
else:
self.print_msg(start_message)
--
2.1.0
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] manage replication topology in the shared tree
On 04/13/2015 10:56 AM, Ludwig Krispenz wrote: Hi, in the attachment you find the latest state of the topology plugin, it implements what is defined in the design page: http://www.freeipa.org/page/V4/Manage_replication_topology (which is also waiting for a reviewer) It contains the plugin itself and a core of ipa commands to manage a topology. to be really applicable, some work outside is required, eg the management of the domain level and a decision where the binddn group should be maintained. Hi Ludwig, Thanks for updates. My suggestions would be: 1) Update/finalize the design to fully match the current implementation - there were several discussions around this plugin and I am not sure if all were implemented. The design page often talks about first implementation etc. It should rather talk about the final design for this feature. I went through the design page and fixed formatting of some sections (Use Cases, created table for config attributes - this needs your revision and filling in the gaps) to make it more readable. Overall, the design should only use verbatim (monospace) sections only where absolutely necessary, it is otherwise hard to read. I fixed many typos, I think the docs could use one more complete proof read and cleaning from you so that it can be further reviewed. 2) The code itself should be checked. Will Thierry and Simo check the C parts? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0029] suppress errors arising from deleting non-existent files during client uninstall
This patch addresses https://fedorahosted.org/freeipa/ticket/4966
The noise during rollback/uninstall is caused mainly by unsuccessful
attempts to remove files that do not exist anymore. These errors are now
logged at debug level and do not pop-up to stdout/stderr.
--
Martin^3 Babinsky
From d852d237c86abc1db3780d2be169dd89745a06de Mon Sep 17 00:00:00 2001
From: Martin Babinsky mbabi...@redhat.com
Date: Tue, 14 Apr 2015 13:55:33 +0200
Subject: [PATCH] suppress errors arising from deleting non-existent files
during client uninstall
When rolling back partially configured IPA client a number of OSErrors pop up
due to uninstaller trying to remove files that do not exist anymore. This
patch supresses these errors while keeping them in log as debug messages.
https://fedorahosted.org/freeipa/ticket/4966
---
ipa-client/ipa-install/ipa-client-install | 40 +--
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index 3f9a7419a10ddcb4618e80789a06a05058d1e8a4..06cdb944a023a7d8150f534eda64565d5f020893 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -224,6 +224,29 @@ def logging_setup(options):
console_format='%(message)s')
+def log_file_removal_error(e, filename, add_warning=False):
+
+Logs OSErrors raised during file removal according to their nature.
+OSError 2 (no such file/directory) will be logged only at debug
+level, other OSError exceptions will be logged as errors.
+
+:param e: OSError instance
+:param filename: filename which triggered the error
+:param add_warning: If set to `True`, prints another message which
+instructs the user to manually remove the offending file (if it exists)
+
+assert isinstance(e, OSError)
+logger_func = root_logger.error
+if e.errno == 2:
+logger_func = root_logger.debug
+add_warning = False
+
+logger_func(Failed to remove file %s: %s, filename, e)
+if add_warning:
+logger_func('Please remove %s manually, as it can cause subsequent '
+'installation to fail.', filename)
+
+
def log_service_error(name, action, error):
root_logger.error(%s failed to %s: %s, name, action, str(error))
@@ -532,7 +555,7 @@ def uninstall(options, env):
try:
os.remove(filename)
except OSError, e:
-root_logger.error(Failed to remove %s: %s, filename, e)
+log_file_removal_error(e, filename)
for nickname, trust_flags in ipa_certs:
while sys_db.has_nickname(nickname):
@@ -734,9 +757,8 @@ def uninstall(options, env):
if file_exists(preferences_fname):
try:
os.remove(preferences_fname)
-except Exception, e:
-root_logger.warning('%s' could not be removed: %s. % preferences_fname, str(e))
-root_logger.warning(Please remove file '%s' manually. % preferences_fname)
+except OSError as e:
+log_file_removal_error(e, preferences_fname, True)
rv = 0
@@ -763,10 +785,7 @@ def uninstall(options, env):
try:
os.remove(paths.IPA_DEFAULT_CONF)
except OSError, e:
-root_logger.warning('/etc/ipa/default.conf could not be removed: %s',
-str(e))
-root_logger.warning('Please remove /etc/ipa/default.conf manually, '
-'as it can cause subsequent installation to fail.')
+log_file_removal_error(e, paths.IPA_DEFAULT_CONF, True)
# Remove the CA cert from the systemwide certificate store
tasks.remove_ca_certs_from_systemwide_ca_store()
@@ -775,10 +794,7 @@ def uninstall(options, env):
try:
os.remove(CACERT)
except OSError, e:
-root_logger.warning('%s could not be removed: %s', CACERT, str(e))
-root_logger.warning('Please remove %s manually, '
-'as it can cause subsequent '
-'installation to fail.', CACERT)
+log_file_removal_error(e, CACERT, True)
root_logger.info(Client uninstall complete.)
--
2.1.0
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] manage replication topology in the shared tree
On 04/14/2015 01:39 PM, Martin Kosek wrote: On 04/13/2015 10:56 AM, Ludwig Krispenz wrote: Hi, in the attachment you find the latest state of the topology plugin, it implements what is defined in the design page: http://www.freeipa.org/page/V4/Manage_replication_topology (which is also waiting for a reviewer) It contains the plugin itself and a core of ipa commands to manage a topology. to be really applicable, some work outside is required, eg the management of the domain level and a decision where the binddn group should be maintained. Hi Ludwig, Thanks for updates. My suggestions would be: 1) Update/finalize the design to fully match the current implementation - there were several discussions around this plugin and I am not sure if all were implemented. The design page often talks about first implementation etc. It should rather talk about the final design for this feature. I went through the design page and fixed formatting of some sections (Use Cases, created table for config attributes - this needs your revision and filling in the gaps) to make it more readable. Overall, the design should only use verbatim (monospace) sections only where absolutely necessary, it is otherwise hard to read. I fixed many typos, I think the docs could use one more complete proof read and cleaning from you so that it can be further reviewed. 2) The code itself should be checked. Will Thierry and Simo check the C parts? Yes I will and it will be a pleasure :-) thierry -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0027] do not install CA on replica during integration test if setup_ca=False
On 04/08/2015 08:44 AM, Martin Babinsky wrote: I have discovered another little bug in the integration test suite. Attaching a patch that fixes it. Hello, thanks for the patch. I hereby invoke the One Liner rule. Cheers, Milan -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 811 performance: faster DN implementation
On 04/14/2015 09:32 AM, Petr Spacek wrote: On 10.4.2015 13:11, Petr Viktorin wrote: ACK Pushed to master: 11bd9d96f191066f7ba760549f00179c128a9787 Please be so kind and fix naming. AFAIK the patch refers to 'openldap' DN format but in fact it is python-ldap-ishm. It will surely confuse next generation of FreeIPA developers :-) Will be in separate patch. -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0029] suppress errors arising from deleting non-existent files during client uninstall
On 14/04/15 16:12, Martin Basti wrote: On 14/04/15 14:25, Martin Babinsky wrote: This patch addresses https://fedorahosted.org/freeipa/ticket/4966 The noise during rollback/uninstall is caused mainly by unsuccessful attempts to remove files that do not exist anymore. These errors are now logged at debug level and do not pop-up to stdout/stderr. Hello, thank you for the patch. 1) The option add_warning is quite unclear to me. It does not show warning but error. I suggest something like, show_hint, show_user_action, or something show_additional_..., or promt_manual_removal Martin^2 Continue... 2) if file_exists(preferences_fname): try: os.remove(preferences_fname) except OSError as e: log_file_removal_error(e, preferences_fname, True) In this case file not found error should never happen. Could you remove the 'if file_exists' part and handle just exception? 3) this is inconsistent with change above, choose one style please: if os.path.exists(ca_file): try: os.unlink(ca_file) except OSError, e: root_logger.error( Failed to remove '%s': %s, ca_file, e) -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Splitting out ipaldap
On 04/14/2015 10:38 AM, Petr Viktorin wrote: Hello! As some of you know, I'm looking to help porting FreeIPA to Python 3. One of the major dependencies holding this back is python-ldap, which hasn't been ported yet. Some preliminary porting patches by Raphaël Barrois [0] are ready and have been sent to the python-ldap list. The python-ldap upstream has been very quiet about reviewing them so far, but they're something for me to test against, and maybe improve. Openstack is successfully running a py3 version of python-ldap. Maybe you should look at what Openstack is doing. -- John -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] webui: use no_members option in entity select search
On 04/01/2015 03:01 PM, Martin Babinsky wrote: On 03/31/2015 04:16 PM, Petr Vobornik wrote: Obtaining member information for entity selects is not needed and it causes unwanted performance hit, especially with larger groups. This patch removes it. https://fedorahosted.org/freeipa/ticket/4948 Works as expected and the speedup is substantial (ca 10x faster lookup of default group in user group rules for 16 groups with 100 members each). ACK. Pushed to master: efcd48ad01a39a67f131a2cea9d5477164fb -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0025] proper client host setup/teardown in forced client reenrollment integration test suite
On 04/14/2015 03:54 PM, Milan Kubik wrote: On 04/14/2015 03:20 PM, Milan Kubik wrote: On 03/31/2015 10:42 AM, Martin Babinsky wrote: During the investigation of https://fedorahosted.org/freeipa/ticket/4614 I discovered a bug (?) in forced client reenrollment integration test. During test scenario, master and replica are setup correctly at the beginning of the test, but the client is never setup resulting in a couple of tracebacks. After some investigation I realized that the setUp/tearDown methods are actually never called because they are supposed to be inherited from unittest.TestCase. However, IntegrationTest no longer inherits from this class, hence the bug. I have tried to fix this by adding a fixture which runs client fixup/teardown and doing some other small modifications. Tests now work as expected, but I need a review from QE guys or someone well-versed in pytest framework. TL;DR: I think I have fixed a bug in integration test but I need someone to review the fix because I may not know what I'm doing. Hello, please fix the pep8 complaints. Otherwise looks good to me. Thanks, Milan Taking back request on pep8, this is not related to the patch introduced code. ACK. Milan Pushed to master: c8fae594df474669416b96b8033528332daf9b37 -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Splitting out ipaldap
On 04/14/2015 06:18 PM, Jan Cholasta wrote: Dne 14.4.2015 v 17:50 Petr Viktorin napsal(a): On 04/14/2015 05:22 PM, Jan Cholasta wrote: Hi, Dne 14.4.2015 v 16:38 Petr Viktorin napsal(a): Hello! As some of you know, I'm looking to help porting FreeIPA to Python 3. One of the major dependencies holding this back is python-ldap, which hasn't been ported yet. Some preliminary porting patches by Raphaël Barrois [0] are ready and have been sent to the python-ldap list. The python-ldap upstream has been very quiet about reviewing them so far, but they're something for me to test against, and maybe improve. To make the testing easier, I'd like to split out ipaldap to a stand-alone package, and port it to Python 3 first. This split will make it easier to test (since I don't have to port all of IPA), and being able to use our generic LDAP wrappers in non-IPA projects could maybe also invite some community participation. Also, ipaldap unit tests are somewhat lacking, so I'll help with that. Packaging-wise, I want ipaldap to be on the same level as ipapython or ipaserver; additionally I want to release it on PyPI [1]. Note that I don't consider ipaldap API stable and don't want to put any effort in maintaining backward compatibility when something needs to be changed, so you might want to hold the PyPI release, or at least put a big fat warning in some visible place. If it's released early often, it'll at least be visible to interested people. It would be nice to include a roadmap file saying what needs to change before we start claiming API stability. From the top of my head, in no particular order: * High-level class for attribute values +1 * High-level classes for schema elements * Support different schema styles (LDAPv3, AD), or at least make it possible Here I'm inclined to just say the schema API isn't done. * High-level class for filters As long as we still accept filters as text, I don't see any backcompat problems here. (Assuming we don't expose the current filter-making helpers, which I'd rather kep IPA-specific, anyway.) * Some better way of doing extended operations (paged search, deref search, etc.) * Support different transports (LDAP, local LDIF file), or at least make it possible Those two should be possible to add while keeping compatibility. My general plan is: - Move ipapython.dn - ipaldap.dn (keeping ipapython.dn importable for old scripts/plugins) DNs are not strictly LDAP specific, so I would rather move ipapython.dn to a new ipautil package. I'd rather not, at least until there's something that needs it (and doesn't also depend on ipaldap). The scope of ipautil is far too badly defined for such a package to be useful. IMO generic stuff should be in a package for generic stuff. I guess it should originally have been ipapython, but it's too fused with ipalib ATM, hence my proposal to use a new package. No. Any vaguely defined collection of generic utilities needed in a project is really a single-purpose package. Nobody likes pulling in a bunch of unrelated stuff because of one particular thing they need, and without a scope the amount of unnecessary stuff grows without bound. I'd be OK with an ipadn, if you can manage the overhead of a package. - Move CIDict to ipaldap.cidict. For Python 3, I'd really like to replace this with something based on collections.MutableMapping, since the semantics of subclassing dict aren't very well defined. I have WIP which does just that. Could you send it? Not yet unfortunately, CIDict removal is actually just a side effect of other changes, and it still needs a lot of work before it is sendable. I was thinking the Python 3 boundary is a good point to switch, since stuff will be breaking anyway. I can import the new one under py3, and keep the old one for py2. -- Petr Viktorin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Splitting out ipaldap
On 04/14/2015 06:03 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 04/14/2015 05:19 PM, John Dennis wrote: On 04/14/2015 10:38 AM, Petr Viktorin wrote: Hello! As some of you know, I'm looking to help porting FreeIPA to Python 3. One of the major dependencies holding this back is python-ldap, which hasn't been ported yet. Some preliminary porting patches by Raphaël Barrois [0] are ready and have been sent to the python-ldap list. The python-ldap upstream has been very quiet about reviewing them so far, but they're something for me to test against, and maybe improve. Openstack is successfully running a py3 version of python-ldap. Maybe you should look at what Openstack is doing. I've heard this from several people, but by now I think it's just a rumor. Can you point me to an actual packaged version or a repo of python-ldap for Python 3, or to someone who would know where to find it? https://wiki.openstack.org/wiki/Python3 says python-ldap is not ported at all, and seems dead. https://review.openstack.org/#/c/95827/ Ah, so it's the same patchset I am looking at. Thanks! -- Petr Viktorin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0045] Add message for skipping NTP configuration during client install
On 04/07/2015 05:46 PM, Martin Basti wrote: On 07/04/15 17:06, Gabe Alford wrote: Stupid me. I realized that chronyd was running which messed up my testing and such (sorry about that). New patch attached that implements 'else' On Tue, Apr 7, 2015 at 2:32 AM, Martin Basti mba...@redhat.com mailto:mba...@redhat.com wrote: On 02/04/15 17:47, Gabe Alford wrote: On Thu, Apr 2, 2015 at 8:59 AM, Martin Basti mba...@redhat.com mailto:mba...@redhat.com wrote: On 30/03/15 15:25, Gabe Alford wrote: Hello, With the merging of ticket 4842 https://fedorahosted.org/freeipa/ticket/4842, I believe that half of ticket 3092 https://fedorahosted.org/freeipa/ticket/3092 has been done. This patch just adds a message that says that NTP configuration was skipped which I believe should finish 3092 https://fedorahosted.org/freeipa/ticket/3092. Thanks, Gabe Hello, thank you for the patch. 1) IMO there should be: if *not* options.conf_ntp So, if --no-ntp is not specified, print message that the client is skipping NTP sync? Yes, or did I miss something? I though the message should be shown only if --no-ntp option is used. With your current patch: # ipa-client-install --no-ntp no ntp related output no INFO msg: skipping... # ipa-client-install output omitted / Attempting to sync time using ntpd. Will timeout after 15 seconds Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. Skipping synchronizing time with IPA NTP server. output omitted / But in this case the client did synchronization with NTP (which failed), IMO the message Skipping ... should not be there. This message is shown even the synchronization with NTP is successful. 2) wouldnt be better to use just else? I actually ran ipa-client-install with no options on a system where I used 'else', and it printed the skipping NTP sync when it should not have. That is why the patch does not use 'else'. Interesting, I expected the messages only on client installed on IPA server, or with using --no-ntp option Martin -- Martin Basti -- Martin Basti Thank you! ACK Pushed to master: e537fd202e23a507dd0c43d2dfdf88fd6921e183 -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0210] DNSSEC: CI test
On 04/13/2015 04:07 PM, Milan Kubik wrote: On 04/08/2015 12:46 PM, Martin Basti wrote: On 07/04/15 15:45, Milan Kubik wrote: updated patch attached. -- Martin Basti Thanks, ack. Milan Pushed to: master: 0a1a3d73120bdf20ae05bcf663f14ca1a8b02c25 ipa-4-1: f3b5d163bf7432d1a89e7798a3192968bd08dde7 -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 786 webui: unable to select single value in CB by enter key
On 03/31/2015 06:07 PM, Martin Babinsky wrote: On 03/31/2015 04:19 PM, Petr Vobornik wrote: This little fellow was hiding in a cupboard (patchset 784-786 was abandoned). Fix: If editable combobox has one value, the value is selected and changed by hand, it can't be re-selected by enter key. Works as expected, ACK. Pushed to master: f7eeaa4ce04883d4d8ffbd3305050fabfcd6deb4 -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0213 - 0221] Server Upgrade: LDAPI, Update plugins
On 04/10/2015 02:19 PM, David Kupka wrote: On 04/01/2015 05:22 PM, Martin Basti wrote: On 24/03/15 12:08, Martin Basti wrote: On 24/03/15 09:56, Martin Basti wrote: On 23/03/15 15:47, Martin Basti wrote: Hello, The patches: * allows to specify order of update plugins in update files. * requires to use LDAPI by ipa-ldap-updater patches attached Rebased patches attached. -- Martin Basti I accidentally merged two patches into one in previos rebase. So properly rebased patches attached. -- Martin Basti Patch 221 updated: use option to require root user Requires patch mbasti-223 to work with replica install Patches attached Code looks good to me and upgrade process works as expected, ACK. pushed to master: master: * 13c4631813b7e8ac4afc8d5f350ef136c7107d89 Server Upgrade: use only LDAPI connection * b4ca5c57d230c80ecc4f8eaaa01d8e7a36bcb3b4 Server Upgrade: remove unused code in upgrade * cc19b5a76a37d1fb87deb45d9cbfc71472a99fa4 Server Upgrade: Apply plugin updates immediately * f24f614396de809350b54423ca128b478601a64e Server Upgrade: specify order of plugins in update files * 0e752aab297ad0a2c43d6c8755db175f45de028e Server Upgrade: plugins should use ldapupdater API instance * 4aec9d2280a5ebbf1acae3abee215cd7a28f23c2 Server Upgrade: Handle connection better in updates_from_dict * b605ccc94bef9a280aa500d57caa74d95e230b4b Server Upgrade: use ldap2 connection in fix_replica_agreements * d09706a8c8ed02506a9486f919df3d1c2a8e8087 Server Upgrade: restart DS using ipaplatfom service * b9c5744031675beb831210831f9d4b327ccd5544 Server Upgrade: only root can run updates -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Splitting out ipaldap
Hi, Dne 14.4.2015 v 16:38 Petr Viktorin napsal(a): Hello! As some of you know, I'm looking to help porting FreeIPA to Python 3. One of the major dependencies holding this back is python-ldap, which hasn't been ported yet. Some preliminary porting patches by Raphaël Barrois [0] are ready and have been sent to the python-ldap list. The python-ldap upstream has been very quiet about reviewing them so far, but they're something for me to test against, and maybe improve. To make the testing easier, I'd like to split out ipaldap to a stand-alone package, and port it to Python 3 first. This split will make it easier to test (since I don't have to port all of IPA), and being able to use our generic LDAP wrappers in non-IPA projects could maybe also invite some community participation. Also, ipaldap unit tests are somewhat lacking, so I'll help with that. Packaging-wise, I want ipaldap to be on the same level as ipapython or ipaserver; additionally I want to release it on PyPI [1]. Note that I don't consider ipaldap API stable and don't want to put any effort in maintaining backward compatibility when something needs to be changed, so you might want to hold the PyPI release, or at least put a big fat warning in some visible place. My general plan is: - Move ipapython.dn - ipaldap.dn (keeping ipapython.dn importable for old scripts/plugins) DNs are not strictly LDAP specific, so I would rather move ipapython.dn to a new ipautil package. - Move CIDict to ipaldap.cidict. For Python 3, I'd really like to replace this with something based on collections.MutableMapping, since the semantics of subclassing dict aren't very well defined. I have WIP which does just that. - Create a new module for ipaldap-specific exceptions. IPA will use a hook to swap out this module for its own set of exceptions. (Yes, this is a hack, but I'd like to keep ipaldap clean of IPA dependencies. A proper solution will be quite involved, given translatable error messages and XML-RPC numbers.) I have given this some thought since our last conversation about this and I think there won't always be 1-to-1 mapping between ipaldap and ipalib errors, so IMO we should go with the usual monkey patching approach in ipapython.ipaldap: import ipaldap import ipaldap.errors from ipalib import errors ipaldap.errors.SomeError = errors.SomeError ipaldap.errors.SomeSimilarError = errors.SomeError ipaldap.errors.SomeOtherError = errors.SomeOtherError ... try: ipaldap.something() except ipaldap.errors.BaseError as e: # catch ipaldap errors that weren't monkey-patched raise errors.DatabaseError(str(e)) - Split ipapython.ipaldap into ipaldap.entry, ipaldap.client, ipaldap.schema_cache; but keep some IPA-specific logic in ipapython.ipaldap (and again keeping all the old names importable). I don't think schema cache deserves it's own module. I'll port everything to Python 3 as I move it, but I won't add a py3 run to IPA's test suite, at least until the dependencies are ported. Any breakage on py3 will be mine to fix, for the time being. Speaking of dependencies, one of my goals for this effort is to determine whether replacing python-ldap by another library, ldap3, would be worth it. +1 on looking into ldap3 Let me know if you disagree with this direction. Honza -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Splitting out ipaldap
Hello! As some of you know, I'm looking to help porting FreeIPA to Python 3. One of the major dependencies holding this back is python-ldap, which hasn't been ported yet. Some preliminary porting patches by Raphaël Barrois [0] are ready and have been sent to the python-ldap list. The python-ldap upstream has been very quiet about reviewing them so far, but they're something for me to test against, and maybe improve. To make the testing easier, I'd like to split out ipaldap to a stand-alone package, and port it to Python 3 first. This split will make it easier to test (since I don't have to port all of IPA), and being able to use our generic LDAP wrappers in non-IPA projects could maybe also invite some community participation. Also, ipaldap unit tests are somewhat lacking, so I'll help with that. Packaging-wise, I want ipaldap to be on the same level as ipapython or ipaserver; additionally I want to release it on PyPI [1]. My general plan is: - Move ipapython.dn - ipaldap.dn (keeping ipapython.dn importable for old scripts/plugins) - Move CIDict to ipaldap.cidict. For Python 3, I'd really like to replace this with something based on collections.MutableMapping, since the semantics of subclassing dict aren't very well defined. - Create a new module for ipaldap-specific exceptions. IPA will use a hook to swap out this module for its own set of exceptions. (Yes, this is a hack, but I'd like to keep ipaldap clean of IPA dependencies. A proper solution will be quite involved, given translatable error messages and XML-RPC numbers.) - Split ipapython.ipaldap into ipaldap.entry, ipaldap.client, ipaldap.schema_cache; but keep some IPA-specific logic in ipapython.ipaldap (and again keeping all the old names importable). I'll port everything to Python 3 as I move it, but I won't add a py3 run to IPA's test suite, at least until the dependencies are ported. Any breakage on py3 will be mine to fix, for the time being. Speaking of dependencies, one of my goals for this effort is to determine whether replacing python-ldap by another library, ldap3, would be worth it. Let me know if you disagree with this direction. -- Petr Viktorin [0] https://github.com/rbarrois/python-ldap/compare/py3 [1] https://pypi.python.org/pypi -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Splitting out ipaldap
On 04/14/2015 05:19 PM, John Dennis wrote: On 04/14/2015 10:38 AM, Petr Viktorin wrote: Hello! As some of you know, I'm looking to help porting FreeIPA to Python 3. One of the major dependencies holding this back is python-ldap, which hasn't been ported yet. Some preliminary porting patches by Raphaël Barrois [0] are ready and have been sent to the python-ldap list. The python-ldap upstream has been very quiet about reviewing them so far, but they're something for me to test against, and maybe improve. Openstack is successfully running a py3 version of python-ldap. Maybe you should look at what Openstack is doing. I've heard this from several people, but by now I think it's just a rumor. Can you point me to an actual packaged version or a repo of python-ldap for Python 3, or to someone who would know where to find it? https://wiki.openstack.org/wiki/Python3 says python-ldap is not ported at all, and seems dead. -- Petr Viktorin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Splitting out ipaldap
On 04/14/2015 05:22 PM, Jan Cholasta wrote: Hi, Dne 14.4.2015 v 16:38 Petr Viktorin napsal(a): Hello! As some of you know, I'm looking to help porting FreeIPA to Python 3. One of the major dependencies holding this back is python-ldap, which hasn't been ported yet. Some preliminary porting patches by Raphaël Barrois [0] are ready and have been sent to the python-ldap list. The python-ldap upstream has been very quiet about reviewing them so far, but they're something for me to test against, and maybe improve. To make the testing easier, I'd like to split out ipaldap to a stand-alone package, and port it to Python 3 first. This split will make it easier to test (since I don't have to port all of IPA), and being able to use our generic LDAP wrappers in non-IPA projects could maybe also invite some community participation. Also, ipaldap unit tests are somewhat lacking, so I'll help with that. Packaging-wise, I want ipaldap to be on the same level as ipapython or ipaserver; additionally I want to release it on PyPI [1]. Note that I don't consider ipaldap API stable and don't want to put any effort in maintaining backward compatibility when something needs to be changed, so you might want to hold the PyPI release, or at least put a big fat warning in some visible place. If it's released early often, it'll at least be visible to interested people. It would be nice to include a roadmap file saying what needs to change before we start claiming API stability. My general plan is: - Move ipapython.dn - ipaldap.dn (keeping ipapython.dn importable for old scripts/plugins) DNs are not strictly LDAP specific, so I would rather move ipapython.dn to a new ipautil package. I'd rather not, at least until there's something that needs it (and doesn't also depend on ipaldap). The scope of ipautil is far too badly defined for such a package to be useful. - Move CIDict to ipaldap.cidict. For Python 3, I'd really like to replace this with something based on collections.MutableMapping, since the semantics of subclassing dict aren't very well defined. I have WIP which does just that. Could you send it? - Create a new module for ipaldap-specific exceptions. IPA will use a hook to swap out this module for its own set of exceptions. (Yes, this is a hack, but I'd like to keep ipaldap clean of IPA dependencies. A proper solution will be quite involved, given translatable error messages and XML-RPC numbers.) I have given this some thought since our last conversation about this and I think there won't always be 1-to-1 mapping between ipaldap and ipalib errors, so IMO we should go with the usual monkey patching approach in ipapython.ipaldap: import ipaldap import ipaldap.errors from ipalib import errors ipaldap.errors.SomeError = errors.SomeError ipaldap.errors.SomeSimilarError = errors.SomeError ipaldap.errors.SomeOtherError = errors.SomeOtherError ... try: ipaldap.something() except ipaldap.errors.BaseError as e: # catch ipaldap errors that weren't monkey-patched raise errors.DatabaseError(str(e)) I don't like this idea at all; action-at-a-distance bugs caused by monkeypatching are some of the worst bugs to have to deal with. If someone builds a library on top of ipaldap, and then uses it in a project that also uses ipapython, then the library would suddenly start raising IPA-specific errors. If you pass a collection of errors to LDAPClient to use, or even if you subclass, or monkeypatch a specific instance, other IPAClient instances/subclasses are not affected. I think limiting the impact of a hack is more preferable than a somewhat cleaner solution. - Split ipapython.ipaldap into ipaldap.entry, ipaldap.client, ipaldap.schema_cache; but keep some IPA-specific logic in ipapython.ipaldap (and again keeping all the old names importable). I don't think schema cache deserves it's own module. Sure. When I paint that shed, I'll use whatever color looks most convenient :) I'll port everything to Python 3 as I move it, but I won't add a py3 run to IPA's test suite, at least until the dependencies are ported. Any breakage on py3 will be mine to fix, for the time being. Speaking of dependencies, one of my goals for this effort is to determine whether replacing python-ldap by another library, ldap3, would be worth it. +1 on looking into ldap3 -- Petr Viktorin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Splitting out ipaldap
Petr Viktorin wrote: On 04/14/2015 05:19 PM, John Dennis wrote: On 04/14/2015 10:38 AM, Petr Viktorin wrote: Hello! As some of you know, I'm looking to help porting FreeIPA to Python 3. One of the major dependencies holding this back is python-ldap, which hasn't been ported yet. Some preliminary porting patches by Raphaël Barrois [0] are ready and have been sent to the python-ldap list. The python-ldap upstream has been very quiet about reviewing them so far, but they're something for me to test against, and maybe improve. Openstack is successfully running a py3 version of python-ldap. Maybe you should look at what Openstack is doing. I've heard this from several people, but by now I think it's just a rumor. Can you point me to an actual packaged version or a repo of python-ldap for Python 3, or to someone who would know where to find it? https://wiki.openstack.org/wiki/Python3 says python-ldap is not ported at all, and seems dead. https://review.openstack.org/#/c/95827/ rob -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Splitting out ipaldap
Dne 14.4.2015 v 17:50 Petr Viktorin napsal(a): On 04/14/2015 05:22 PM, Jan Cholasta wrote: Hi, Dne 14.4.2015 v 16:38 Petr Viktorin napsal(a): Hello! As some of you know, I'm looking to help porting FreeIPA to Python 3. One of the major dependencies holding this back is python-ldap, which hasn't been ported yet. Some preliminary porting patches by Raphaël Barrois [0] are ready and have been sent to the python-ldap list. The python-ldap upstream has been very quiet about reviewing them so far, but they're something for me to test against, and maybe improve. To make the testing easier, I'd like to split out ipaldap to a stand-alone package, and port it to Python 3 first. This split will make it easier to test (since I don't have to port all of IPA), and being able to use our generic LDAP wrappers in non-IPA projects could maybe also invite some community participation. Also, ipaldap unit tests are somewhat lacking, so I'll help with that. Packaging-wise, I want ipaldap to be on the same level as ipapython or ipaserver; additionally I want to release it on PyPI [1]. Note that I don't consider ipaldap API stable and don't want to put any effort in maintaining backward compatibility when something needs to be changed, so you might want to hold the PyPI release, or at least put a big fat warning in some visible place. If it's released early often, it'll at least be visible to interested people. It would be nice to include a roadmap file saying what needs to change before we start claiming API stability. From the top of my head, in no particular order: * High-level class for attribute values * High-level classes for schema elements * Support different schema styles (LDAPv3, AD), or at least make it possible * High-level class for filters * Some better way of doing extended operations (paged search, deref search, etc.) * Support different transports (LDAP, local LDIF file), or at least make it possible My general plan is: - Move ipapython.dn - ipaldap.dn (keeping ipapython.dn importable for old scripts/plugins) DNs are not strictly LDAP specific, so I would rather move ipapython.dn to a new ipautil package. I'd rather not, at least until there's something that needs it (and doesn't also depend on ipaldap). The scope of ipautil is far too badly defined for such a package to be useful. IMO generic stuff should be in a package for generic stuff. I guess it should originally have been ipapython, but it's too fused with ipalib ATM, hence my proposal to use a new package. - Move CIDict to ipaldap.cidict. For Python 3, I'd really like to replace this with something based on collections.MutableMapping, since the semantics of subclassing dict aren't very well defined. I have WIP which does just that. Could you send it? Not yet unfortunately, CIDict removal is actually just a side effect of other changes, and it still needs a lot of work before it is sendable. - Create a new module for ipaldap-specific exceptions. IPA will use a hook to swap out this module for its own set of exceptions. (Yes, this is a hack, but I'd like to keep ipaldap clean of IPA dependencies. A proper solution will be quite involved, given translatable error messages and XML-RPC numbers.) I have given this some thought since our last conversation about this and I think there won't always be 1-to-1 mapping between ipaldap and ipalib errors, so IMO we should go with the usual monkey patching approach in ipapython.ipaldap: import ipaldap import ipaldap.errors from ipalib import errors ipaldap.errors.SomeError = errors.SomeError ipaldap.errors.SomeSimilarError = errors.SomeError ipaldap.errors.SomeOtherError = errors.SomeOtherError ... try: ipaldap.something() except ipaldap.errors.BaseError as e: # catch ipaldap errors that weren't monkey-patched raise errors.DatabaseError(str(e)) I don't like this idea at all; action-at-a-distance bugs caused by monkeypatching are some of the worst bugs to have to deal with. If someone builds a library on top of ipaldap, and then uses it in a project that also uses ipapython, then the library would suddenly start raising IPA-specific errors. If you pass a collection of errors to LDAPClient to use, or even if you subclass, or monkeypatch a specific instance, other IPAClient instances/subclasses are not affected. I think limiting the impact of a hack is more preferable than a somewhat cleaner solution. Right you are. I don't really care how it's done as long as it's possible to make the mapping not 1-to-1. -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0025] proper client host setup/teardown in forced client reenrollment integration test suite
On 04/14/2015 03:20 PM, Milan Kubik wrote: On 03/31/2015 10:42 AM, Martin Babinsky wrote: During the investigation of https://fedorahosted.org/freeipa/ticket/4614 I discovered a bug (?) in forced client reenrollment integration test. During test scenario, master and replica are setup correctly at the beginning of the test, but the client is never setup resulting in a couple of tracebacks. After some investigation I realized that the setUp/tearDown methods are actually never called because they are supposed to be inherited from unittest.TestCase. However, IntegrationTest no longer inherits from this class, hence the bug. I have tried to fix this by adding a fixture which runs client fixup/teardown and doing some other small modifications. Tests now work as expected, but I need a review from QE guys or someone well-versed in pytest framework. TL;DR: I think I have fixed a bug in integration test but I need someone to review the fix because I may not know what I'm doing. Hello, please fix the pep8 complaints. Otherwise looks good to me. Thanks, Milan Taking back request on pep8, this is not related to the patch introduced code. ACK. Milan -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0029] suppress errors arising from deleting non-existent files during client uninstall
On 14/04/15 14:25, Martin Babinsky wrote: This patch addresses https://fedorahosted.org/freeipa/ticket/4966 The noise during rollback/uninstall is caused mainly by unsuccessful attempts to remove files that do not exist anymore. These errors are now logged at debug level and do not pop-up to stdout/stderr. Hello, thank you for the patch. 1) The option add_warning is quite unclear to me. It does not show warning but error. I suggest something like, show_hint, show_user_action, or something show_additional_..., or promt_manual_removal Martin^2 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0025] proper client host setup/teardown in forced client reenrollment integration test suite
On 03/31/2015 10:42 AM, Martin Babinsky wrote: During the investigation of https://fedorahosted.org/freeipa/ticket/4614 I discovered a bug (?) in forced client reenrollment integration test. During test scenario, master and replica are setup correctly at the beginning of the test, but the client is never setup resulting in a couple of tracebacks. After some investigation I realized that the setUp/tearDown methods are actually never called because they are supposed to be inherited from unittest.TestCase. However, IntegrationTest no longer inherits from this class, hence the bug. I have tried to fix this by adding a fixture which runs client fixup/teardown and doing some other small modifications. Tests now work as expected, but I need a review from QE guys or someone well-versed in pytest framework. TL;DR: I think I have fixed a bug in integration test but I need someone to review the fix because I may not know what I'm doing. Hello, please fix the pep8 complaints. Otherwise looks good to me. Thanks, Milan -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] manage replication topology in the shared tree
Hi Martin, thanks for your time and comments. The design page should match the current implemtation, but as you said there were some iterations and I will check again and address the points you raised. Ludwig On 04/14/2015 01:39 PM, Martin Kosek wrote: On 04/13/2015 10:56 AM, Ludwig Krispenz wrote: Hi, in the attachment you find the latest state of the topology plugin, it implements what is defined in the design page: http://www.freeipa.org/page/V4/Manage_replication_topology (which is also waiting for a reviewer) It contains the plugin itself and a core of ipa commands to manage a topology. to be really applicable, some work outside is required, eg the management of the domain level and a decision where the binddn group should be maintained. Hi Ludwig, Thanks for updates. My suggestions would be: 1) Update/finalize the design to fully match the current implementation - there were several discussions around this plugin and I am not sure if all were implemented. The design page often talks about first implementation etc. It should rather talk about the final design for this feature. I went through the design page and fixed formatting of some sections (Use Cases, created table for config attributes - this needs your revision and filling in the gaps) to make it more readable. Overall, the design should only use verbatim (monospace) sections only where absolutely necessary, it is otherwise hard to read. I fixed many typos, I think the docs could use one more complete proof read and cleaning from you so that it can be further reviewed. 2) The code itself should be checked. Will Thierry and Simo check the C parts? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
