Re: [Freeipa-devel] FreeIPA translations
On 11/13/2014 12:35 AM, Tomas Babej wrote: On 11/12/2014 01:44 PM, Martin Kosek wrote: Hi folks, With Petr changing focus out of FreeIPA, somebody will need to replace his work as the person behind FreeIPA Transifex translation. I think this is now the right time and place to ask - Is Transifex still the translation tool we want to continue supporting? I know there were objections in the past it is not completely open source. But AFAIK, it is one of the most used ones, even OpenStack uses it. If no, we need to find something better. If yes, we will need to make sure the process is well documented on the FreeIPA.org wiki + integrated to our Release process so that it can be handed to someone else. (volunteers? :) Thanks. I'll gladly take the translations, I've translated several projects, and Zanata looks interesting too learn to work with. It would make sense to fix things up a bit when we move. Some notes: We probably don't want the ipa-2-2 resource any more. I don't know if Zanata has a more sane mechanism for versions. If not it would be nice to combine strings from all active releases and put that up for translation, so when the next IPA 4.1.x is released it can have the new translations. We might want to sort the strings in .po files in Git so the diffs aren't so big (use the --sort-output flag to msgattrib in strip-po). But still keep the source order for files uploaded to Zanata (the ones merge-po creates) – the order is useful for translators. I keep a history of translations in a Git repo, as I don't trust clouds with my data. Might be useful: https://github.com/encukou/freeipa-translations Let me know if you have any questions regarding our translations setup. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0163] Fix compiler warning for pk11helper module
On 12/11/14 15:55, Martin Basti wrote:
Part of ticket: https://fedorahosted.org/freeipa/ticket/4657
And here is the patch, sorry :-)
--
Martin Basti
From 4e1c366543e4b70ebd79cb1d143eccdebb9a5b2d Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Wed, 29 Oct 2014 14:45:45 +0100
Subject: [PATCH] Fix pk11helper module compiler warnings
Ticket: https://fedorahosted.org/freeipa/ticket/4657
---
ipapython/ipap11helper/library.c | 10 +++---
ipapython/ipap11helper/library.h | 2 +-
ipapython/ipap11helper/p11helper.c | 3 ++-
ipapython/ipap11helper/setup.py| 1 -
4 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/ipapython/ipap11helper/library.c b/ipapython/ipap11helper/library.c
index 51e24ebc2be5953a6820b768e75a3e8ccb026a64..fc4c1e41c9b3d3eb5ac5a0af7895bdf6a173a79e 100644
--- a/ipapython/ipap11helper/library.c
+++ b/ipapython/ipap11helper/library.c
@@ -44,7 +44,7 @@
#include dlfcn.h
// Load the PKCS#11 library
-CK_C_GetFunctionList loadLibrary(char* module, void** moduleHandle)
+CK_C_GetFunctionList loadLibrary(const char* module, void** moduleHandle)
{
CK_C_GetFunctionList pGetFunctionList = NULL;
@@ -54,13 +54,9 @@ CK_C_GetFunctionList loadLibrary(char* module, void** moduleHandle)
if (module)
{
pDynLib = dlopen(module, RTLD_NOW | RTLD_LOCAL);
+ } else {
+ return NULL;
}
- /*
- else
- {
- pDynLib = dlopen(DEFAULT_PKCS11_LIB, RTLD_NOW | RTLD_LOCAL);
- }
- */
if (pDynLib == NULL)
{
diff --git a/ipapython/ipap11helper/library.h b/ipapython/ipap11helper/library.h
index 2ceb9e375b457be298d683d784481326fd878c7f..afcbd9fd2e43106cd5592ba8a91b1da337452388 100644
--- a/ipapython/ipap11helper/library.h
+++ b/ipapython/ipap11helper/library.h
@@ -42,7 +42,7 @@
#include p11-kit/pkcs11.h
-CK_C_GetFunctionList loadLibrary(char* module, void** moduleHandle);
+CK_C_GetFunctionList loadLibrary(const char* module, void** moduleHandle);
void unloadLibrary(void* moduleHandle);
#endif // !_SOFTHSM_V2_BIN_LIBRARY_H
diff --git a/ipapython/ipap11helper/p11helper.c b/ipapython/ipap11helper/p11helper.c
index 038c26c4520cc8f71edbee15b0ccd9bf292d7588..c1d100772e03660aeee831c76c1db96b6af49d76 100644
--- a/ipapython/ipap11helper/p11helper.c
+++ b/ipapython/ipap11helper/p11helper.c
@@ -1659,10 +1659,11 @@ P11_Helper_set_attribute(P11_Helper* self, PyObject *args, PyObject *kwds) {
goto final;
}
if (PyString_AsStringAndSize(value, (char **) attribute.pValue,
-attribute.ulValueLen) == -1) {
+len) == -1) {
ret = NULL;
goto final;
}
+attribute.ulValueLen = len;
break;
case CKA_LABEL:
if (!PyUnicode_Check(value)) {
diff --git a/ipapython/ipap11helper/setup.py b/ipapython/ipap11helper/setup.py
index 338cdcb2ebf30fe6b0b29d7b11ac03f0a14cbe3c..e8e824a3386db7653b33d539a05927b8de9f029d 100644
--- a/ipapython/ipap11helper/setup.py
+++ b/ipapython/ipap11helper/setup.py
@@ -23,7 +23,6 @@ module = Extension('_ipap11helper',
'-ggdb3',
'-O2',
'-W',
- '-pedantic',
'-Wall',
'-Wno-unused-parameter',
'-Wbad-function-cast',
--
1.8.3.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0158] FIX: upgrade refential integrity plugin configuration
On 12/11/14 16:55, David Kupka wrote:
On 11/07/2014 03:22 PM, Martin Basti wrote:
Ticket: https://fedorahosted.org/freeipa/ticket/4622
Patch attached.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
LGTM, please rebase to ipa-4-0.
Thanks.
Rebased patch for 4.0 attached.
Original patch for 4.1 and master attached.
--
Martin Basti
From f3c19b3719b9e9e25e8f45a1787de8e46ed5e1b7 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Fri, 7 Nov 2014 13:28:01 +0100
Subject: [PATCH] Fix upgrade referint plugin
Mixing 'Old' and 'New' attr style for referential integrity plugin causes errors.
Now old setting are migrated to new style setting before upgrade
Ticket: https://fedorahosted.org/freeipa/ticket/4622
---
install/updates/25-referint.update | 13 +---
ipaserver/install/plugins/Makefile.am| 1 +
ipaserver/install/plugins/update_referint.py | 90
3 files changed, 92 insertions(+), 12 deletions(-)
create mode 100644 ipaserver/install/plugins/update_referint.py
diff --git a/install/updates/25-referint.update b/install/updates/25-referint.update
index c4bff5dac4956eb0ef4b132a2ce5dafdb53e286e..2cb8782263a51caf99c3b33d94bbb3f76372de2c 100644
--- a/install/updates/25-referint.update
+++ b/install/updates/25-referint.update
@@ -1,19 +1,8 @@
# Expand attributes checked by Referential Integrity plugin
# pres and eq indexes defined in 20-indices.update must be set for all these
# attributes
+# NOTE: migration to new style is done in update_referint.py
dn: cn=referential integrity postoperation,cn=plugins,cn=config
-remove: nsslapd-pluginArg7: manager
-remove: nsslapd-pluginArg8: secretary
-remove: nsslapd-pluginArg9: memberuser
-remove: nsslapd-pluginArg10: memberhost
-remove: nsslapd-pluginArg11: sourcehost
-remove: nsslapd-pluginArg12: memberservice
-remove: nsslapd-pluginArg13: managedby
-remove: nsslapd-pluginArg14: memberallowcmd
-remove: nsslapd-pluginArg15: memberdenycmd
-remove: nsslapd-pluginArg16: ipasudorunas
-remove: nsslapd-pluginArg17: ipasudorunasgroup
-remove: nsslapd-pluginArg18: ipatokenradiusconfiglink
add: referint-membership-attr: manager
add: referint-membership-attr: secretary
add: referint-membership-attr: memberuser
diff --git a/ipaserver/install/plugins/Makefile.am b/ipaserver/install/plugins/Makefile.am
index 7cf0495131b2108ee78a79758cee42ec344652c7..90c59b3caf4f6e1c92563f7750051ee255b79c5b 100644
--- a/ipaserver/install/plugins/Makefile.am
+++ b/ipaserver/install/plugins/Makefile.am
@@ -11,6 +11,7 @@ app_PYTHON = \
update_services.py \
update_anonymous_aci.py \
update_pacs.py \
+ update_referint.py \
ca_renewal_master.py \
$(NULL)
diff --git a/ipaserver/install/plugins/update_referint.py b/ipaserver/install/plugins/update_referint.py
new file mode 100644
index ..1b7411035b27ebba04246a7ee6f220d470b46688
--- /dev/null
+++ b/ipaserver/install/plugins/update_referint.py
@@ -0,0 +1,90 @@
+#
+# Copyright (C) 2014 FreeIPA Contributors see COPYING for license
+#
+
+from ipaserver.install.plugins import MIDDLE
+from ipaserver.install.plugins.baseupdate import PreUpdate
+from ipalib import api, errors
+from ipapython.dn import DN
+from ipapython.ipa_log_manager import root_logger
+
+class update_referint(PreUpdate):
+
+Update referential integrity configuration to new style
+http://directory.fedoraproject.org/docs/389ds/design/ri-plugin-configuration.html
+
+old attr - new attr
+nsslapd-pluginArg0- referint-update-delay
+nsslapd-pluginArg1- referint-logfile
+nsslapd-pluginArg2- referint-logchanges
+nsslapd-pluginArg3..N - referint-membership-attr [3..N]
+
+Old and new style cannot be mixed, all nslapd-pluginArg* attrs have to be removed
+
+
+order = MIDDLE
+
+referint_dn = DN(('cn', 'referential integrity postoperation'),
+ ('cn', 'plugins'), ('cn', 'config'))
+
+def execute(self, **options):
+
+root_logger.debug(Upgrading referential integrity plugin configuration)
+ldap = self.obj.backend
+try:
+entry = ldap.get_entry(self.referint_dn)
+except errors.NotFound:
+root_logger.error(Referential integrity configuration not found)
+return False, False, []
+
+referint_membership_attrs = []
+
+root_logger.debug(Initial value: %s, repr(entry))
+
+# nsslapd-pluginArg0- referint-update-delay
+update_delay = entry.get('nsslapd-pluginArg0')
+if update_delay:
+root_logger.debug(add: referint-update-delay: %s, update_delay)
+entry['referint-update-delay'] = update_delay
+entry['nsslapd-pluginArg0'] = None
+else:
+root_logger.info(Plugin already uses new style, skipping)
+return False, False, []
Re: [Freeipa-devel] FreeIPA translations
On Thu, Nov 13, 2014 at 09:56:54AM +0100, Petr Viktorin wrote: On 11/13/2014 12:35 AM, Tomas Babej wrote: On 11/12/2014 01:44 PM, Martin Kosek wrote: Hi folks, With Petr changing focus out of FreeIPA, somebody will need to replace his work as the person behind FreeIPA Transifex translation. I think this is now the right time and place to ask - Is Transifex still the translation tool we want to continue supporting? I know there were objections in the past it is not completely open source. But AFAIK, it is one of the most used ones, even OpenStack uses it. If no, we need to find something better. If yes, we will need to make sure the process is well documented on the FreeIPA.org wiki + integrated to our Release process so that it can be handed to someone else. (volunteers? :) Thanks. I'll gladly take the translations, I've translated several projects, and Zanata looks interesting too learn to work with. It would make sense to fix things up a bit when we move. Some notes: We probably don't want the ipa-2-2 resource any more. I don't know if Zanata has a more sane mechanism for versions. If not it would be nice to combine strings from all active releases and put that up for translation, so when the next IPA 4.1.x is released it can have the new translations. We might want to sort the strings in .po files in Git so the diffs aren't so big (use the --sort-output flag to msgattrib in strip-po). But still keep the source order for files uploaded to Zanata (the ones merge-po creates) – the order is useful for translators. I keep a history of translations in a Git repo, as I don't trust clouds with my data. Might be useful: https://github.com/encukou/freeipa-translations Let me know if you have any questions regarding our translations setup. I'm curious, what is the reason you consider moving to Zanata? (Genuine question, SSSD is currently using Transifex and I admit I don't know much about the translation tools..) Feel free to point me to an older thread, but my quick search in freeipa-devel folder didn't turn up much.. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA translations
On Thu, 13 Nov 2014, Jakub Hrozek wrote: On Thu, Nov 13, 2014 at 09:56:54AM +0100, Petr Viktorin wrote: On 11/13/2014 12:35 AM, Tomas Babej wrote: On 11/12/2014 01:44 PM, Martin Kosek wrote: Hi folks, With Petr changing focus out of FreeIPA, somebody will need to replace his work as the person behind FreeIPA Transifex translation. I think this is now the right time and place to ask - Is Transifex still the translation tool we want to continue supporting? I know there were objections in the past it is not completely open source. But AFAIK, it is one of the most used ones, even OpenStack uses it. If no, we need to find something better. If yes, we will need to make sure the process is well documented on the FreeIPA.org wiki + integrated to our Release process so that it can be handed to someone else. (volunteers? :) Thanks. I'll gladly take the translations, I've translated several projects, and Zanata looks interesting too learn to work with. It would make sense to fix things up a bit when we move. Some notes: We probably don't want the ipa-2-2 resource any more. I don't know if Zanata has a more sane mechanism for versions. If not it would be nice to combine strings from all active releases and put that up for translation, so when the next IPA 4.1.x is released it can have the new translations. We might want to sort the strings in .po files in Git so the diffs aren't so big (use the --sort-output flag to msgattrib in strip-po). But still keep the source order for files uploaded to Zanata (the ones merge-po creates) – the order is useful for translators. I keep a history of translations in a Git repo, as I don't trust clouds with my data. Might be useful: https://github.com/encukou/freeipa-translations Let me know if you have any questions regarding our translations setup. I'm curious, what is the reason you consider moving to Zanata? (Genuine question, SSSD is currently using Transifex and I admit I don't know much about the translation tools..) Feel free to point me to an older thread, but my quick search in freeipa-devel folder didn't turn up much.. Transifex is a commercial product that used to be a free software and not anymore. Old code on github has no resemblance to the current state of it. Zanata is a free software available under LGPL. It is actively supported by Red Hat as it is already used for JBoss family of projects. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0027 Produce better error in group-add command.
Dne 10.11.2014 v 13:24 David Kupka napsal(a): On 11/10/2014 08:20 AM, Jan Cholasta wrote: Hi, Dne 7.11.2014 v 15:26 David Kupka napsal(a): https://fedorahosted.org/freeipa/ticket/4611 I think you should use MutuallyExclusiveError. Honza Thanks, that's the error class I was searching for. Unfortunately, I didn't know this one so I used more abstract error class. Fixed patch attached. Given the messages that are used for MutuallyExclusiveError everywhere else in the framework, I think a better message would be gid cannot be set for external group. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0672 - ipaplatform: Use the dirsrv service, not target
Hi, Dne 11.11.2014 v 17:03 Petr Viktorin napsal(a): https://fedorahosted.org/freeipa/ticket/4709 With this patch, IPA should no longer call systemctl on dirsrv.tagret, but rather on its concrete service. Since systemctl stop waits for shutdown of services (but not targets), we can assume dirsrv will be down (and the database unlocked) after stop() is done. There's a DS ticket [0] to explicitly tell systemd which process to wait on, but in my experience, systemd guesses correctly even without that fix. [0] https://fedorahosted.org/389/ticket/47951 Thanks, ACK. Pushed to: master: e60ef1fe029594876bd0e075cd5efc0173743138 ipa-4-1: 082485c2832a51cf6018bc172881e67e979de69c Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0158] FIX: upgrade refential integrity plugin configuration
On 11/13/2014 10:18 AM, Martin Basti wrote: On 12/11/14 16:55, David Kupka wrote: On 11/07/2014 03:22 PM, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4622 Patch attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel LGTM, please rebase to ipa-4-0. Thanks. Rebased patch for 4.0 attached. Original patch for 4.1 and master attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hello, Just a novice question. If the RI config entry was something like: dn: cn=referential integrity postoperation,cn=plugins,cn=config objectClass: top ... nsslapd-pluginArg0: xxx nsslapd-pluginArg1: yyy nsslapd-pluginArg2: zzz nsslapd-pluginArg3: +++ Will it create an entry like dn: cn=referential integrity postoperation,cn=plugins,cn=config objectClass: top ... referint-update-delay: xxx referint-logfile: yyy referint-logchanges: zzz referint-membership-attr: +++ or like dn: cn=referential integrity postoperation,cn=plugins,cn=config objectClass: top ... referint-update-delay: xxx referint-logfile: yyy referint-logchanges: zzz referint-membership-attr: +++ nsslapd-pluginArg0: nsslapd-pluginArg1: nsslapd-pluginArg2: nsslapd-pluginArg3: Thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0158] FIX: upgrade refential integrity plugin configuration
On 13/11/14 12:02, thierry bordaz wrote: On 11/13/2014 10:18 AM, Martin Basti wrote: On 12/11/14 16:55, David Kupka wrote: On 11/07/2014 03:22 PM, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4622 Patch attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel LGTM, please rebase to ipa-4-0. Thanks. Rebased patch for 4.0 attached. Original patch for 4.1 and master attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hello, Just a novice question. If the RI config entry was something like: dn: cn=referential integrity postoperation,cn=plugins,cn=config objectClass: top ... nsslapd-pluginArg0: xxx nsslapd-pluginArg1: yyy nsslapd-pluginArg2: zzz nsslapd-pluginArg3: +++ Will it create an entry like dn: cn=referential integrity postoperation,cn=plugins,cn=config objectClass: top ... referint-update-delay: xxx referint-logfile: yyy referint-logchanges: zzz referint-membership-attr: +++ or like dn: cn=referential integrity postoperation,cn=plugins,cn=config objectClass: top ... referint-update-delay: xxx referint-logfile: yyy referint-logchanges: zzz referint-membership-attr: +++ nsslapd-pluginArg0: nsslapd-pluginArg1: nsslapd-pluginArg2: nsslapd-pluginArg3: Thanks thierry Hello, It removes all nsslapd-pluginArg* referint-update-delay: xxx referint-logfile: yyy referint-logchanges: zzz referint-membership-attr: +++ But I can check it again if you have any doubts. Martin^2 -- Martin Basti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA translations
On Thu, Nov 13, 2014 at 11:52:29AM +0200, Alexander Bokovoy wrote: On Thu, 13 Nov 2014, Jakub Hrozek wrote: On Thu, Nov 13, 2014 at 09:56:54AM +0100, Petr Viktorin wrote: On 11/13/2014 12:35 AM, Tomas Babej wrote: On 11/12/2014 01:44 PM, Martin Kosek wrote: Hi folks, With Petr changing focus out of FreeIPA, somebody will need to replace his work as the person behind FreeIPA Transifex translation. I think this is now the right time and place to ask - Is Transifex still the translation tool we want to continue supporting? I know there were objections in the past it is not completely open source. But AFAIK, it is one of the most used ones, even OpenStack uses it. If no, we need to find something better. If yes, we will need to make sure the process is well documented on the FreeIPA.org wiki + integrated to our Release process so that it can be handed to someone else. (volunteers? :) Thanks. I'll gladly take the translations, I've translated several projects, and Zanata looks interesting too learn to work with. It would make sense to fix things up a bit when we move. Some notes: We probably don't want the ipa-2-2 resource any more. I don't know if Zanata has a more sane mechanism for versions. If not it would be nice to combine strings from all active releases and put that up for translation, so when the next IPA 4.1.x is released it can have the new translations. We might want to sort the strings in .po files in Git so the diffs aren't so big (use the --sort-output flag to msgattrib in strip-po). But still keep the source order for files uploaded to Zanata (the ones merge-po creates) – the order is useful for translators. I keep a history of translations in a Git repo, as I don't trust clouds with my data. Might be useful: https://github.com/encukou/freeipa-translations Let me know if you have any questions regarding our translations setup. I'm curious, what is the reason you consider moving to Zanata? (Genuine question, SSSD is currently using Transifex and I admit I don't know much about the translation tools..) Feel free to point me to an older thread, but my quick search in freeipa-devel folder didn't turn up much.. Transifex is a commercial product that used to be a free software and not anymore. Old code on github has no resemblance to the current state of it. I wasn't aware of this change. Thank you. Zanata is a free software available under LGPL. It is actively supported by Red Hat as it is already used for JBoss family of projects. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0159] FIX: DNS policy upgrade raises assertion error
On 07/11/14 15:15, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4708 Patch attached. As I and Honza discussed personally, the updated patch modifies place of the fix Updated patch attached -- Martin Basti From 003b429f755970aa86d0cf8f3dd9c2da57cda14d Mon Sep 17 00:00:00 2001 From: Martin Basti mba...@redhat.com Date: Fri, 7 Nov 2014 15:09:29 +0100 Subject: [PATCH] Fix: DNS policy upgrade raises asertion error Ticket: https://fedorahosted.org/freeipa/ticket/4708 --- ipaserver/install/plugins/dns.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ipaserver/install/plugins/dns.py b/ipaserver/install/plugins/dns.py index 1aef837f63176cd307868c726460485fd4a004ed..62cf588d27155acb03026f69ea09ff15582d26dc 100644 --- a/ipaserver/install/plugins/dns.py +++ b/ipaserver/install/plugins/dns.py @@ -86,7 +86,9 @@ class update_dnszones(PostUpdate): api.env.realm) if update: -api.Command.dnszone_mod(zone[u'idnsname'][0], **update) +# FIXME: https://fedorahosted.org/freeipa/ticket/4722 +api.Command.dnszone_mod(zone[u'idnsname'][0].make_absolute(), +**update) return (False, False, []) -- 1.8.3.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0158] FIX: upgrade refential integrity plugin configuration
On 11/13/2014 10:18 AM, Martin Basti wrote: On 12/11/14 16:55, David Kupka wrote: On 11/07/2014 03:22 PM, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4622 Patch attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel LGTM, please rebase to ipa-4-0. Thanks. Rebased patch for 4.0 attached. Original patch for 4.1 and master attached. Thanks, ACK. -- David Kupka ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0159] FIX: DNS policy upgrade raises assertion error
Hi, Dne 13.11.2014 v 13:00 Martin Basti napsal(a): On 07/11/14 15:15, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4708 Patch attached. As I and Honza discussed personally, the updated patch modifies place of the fix Updated patch attached Thanks, ACK. Pushed to: ipa-4-0: e5ec47992cd641def024cc77c07f98ca66b7b673 ipa-4-1: 1b22a53717cd2ead8a8f3fec84d04dac698d8925 master: 40ea328a78bec511377b464700e3add09cedc2b9 Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0029 Remove service file even if it isn't link.
On 10.11.2014 08:30, Jan Cholasta wrote: Hi, Dne 7.11.2014 v 15:29 David Kupka napsal(a): Depends on freeipa-dkupka-0028. https://fedorahosted.org/freeipa/ticket/4658 ACK. Honza David, this patch doesn't apply on ipa-4-1 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1110 fix search scope
On 6.11.2014 22:46, Nathaniel McCallum wrote: On Thu, 2014-11-06 at 16:16 -0500, Rob Crittenden wrote: The wrong search scope was being used to determine if a given master had a CA installed during ipa-csreplica-manage connect. ACK Pushed to: master: c32ecbff8cfe219499c15afe34e617ec7a9297cf ipa-4-1: 606de21dd565cf0becc7f33e4d26565acf6940ae -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0158] FIX: upgrade refential integrity plugin configuration
On 11/13/2014 12:16 PM, Martin Basti wrote: On 13/11/14 12:02, thierry bordaz wrote: On 11/13/2014 10:18 AM, Martin Basti wrote: On 12/11/14 16:55, David Kupka wrote: On 11/07/2014 03:22 PM, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4622 Patch attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel LGTM, please rebase to ipa-4-0. Thanks. Rebased patch for 4.0 attached. Original patch for 4.1 and master attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hello, Just a novice question. If the RI config entry was something like: dn: cn=referential integrity postoperation,cn=plugins,cn=config objectClass: top ... nsslapd-pluginArg0: xxx nsslapd-pluginArg1: yyy nsslapd-pluginArg2: zzz nsslapd-pluginArg3: +++ Will it create an entry like dn: cn=referential integrity postoperation,cn=plugins,cn=config objectClass: top ... referint-update-delay: xxx referint-logfile: yyy referint-logchanges: zzz referint-membership-attr: +++ or like dn: cn=referential integrity postoperation,cn=plugins,cn=config objectClass: top ... referint-update-delay: xxx referint-logfile: yyy referint-logchanges: zzz referint-membership-attr: +++ nsslapd-pluginArg0: nsslapd-pluginArg1: nsslapd-pluginArg2: nsslapd-pluginArg3: Thanks thierry Hello, It removes all nsslapd-pluginArg* referint-update-delay: xxx referint-logfile: yyy referint-logchanges: zzz referint-membership-attr: +++ But I can check it again if you have any doubts. Martin^2 -- Martin Basti Hi Martin, Thanks for the explanation. Reading generate_modlist(), I realize that it will do a mod/del on each 'nsslapd-pluginarg*' so they will be clearly removed. Thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add
On 11/13/2014 07:53 AM, Nathaniel McCallum wrote:
On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote:
This is possible because python-qrcode's output now fits in a standard
terminal. Also, update ipa-otp-import and otptoken-add-yubikey to
disable QR code output as it doesn't make sense in these contexts.
https://fedorahosted.org/freeipa/ticket/4703
I removed the period from the doc string to maintain consistency with
the rest of the plugin.
Nathaniel
I am not reviewing, just curious. What is the purpose of --qrcode option with
default=True?
takes_options = LDAPCreate.takes_options + (
-Flag('qrcode?', label=_('Display QR code')),
+Flag('qrcode', label=_('Display QR code'), default=True),
)
How can user turn it off? Both passing no option and passing --qrcode will get
the same result, no? :-)
Shouldn't we instead change --qrcode to --no-qrcode and process somehow fill
qrcode=0 when it's enabled? (To achieve API compatibility with old clients).
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0160] Fix objectclass violation during upgrade
On 11/10/2014 03:21 PM, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4680 Entry dn: cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX must be updated before dn: cn=ADTrust Agents,cn=privileges,cn=pbac,$SUFFIX Patch attached Martin^2 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Works for me, ACK, thanks. -- David Kupka ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0158] FIX: upgrade refential integrity plugin configuration
On 13.11.2014 13:08, David Kupka wrote: On 11/13/2014 10:18 AM, Martin Basti wrote: On 12/11/14 16:55, David Kupka wrote: On 11/07/2014 03:22 PM, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4622 Patch attached. LGTM, please rebase to ipa-4-0. Thanks. Rebased patch for 4.0 attached. Original patch for 4.1 and master attached. Thanks, ACK. Pushed to: ipa-4-0: * 9a9eccb94bcade97edb8aa877aedc35c191745e5 Fix upgrade referint plugin ipa-4-1: * 65624c9d61ba0bf8a1e5e040357406712dd42245 Fix upgrade referint plugin master: * f62c7843ffeda1e841719cb35f9f773f186780a6 Fix upgrade referint plugin -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0160] Fix objectclass violation during upgrade
On 13.11.2014 13:20, David Kupka wrote: On 11/10/2014 03:21 PM, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4680 Entry dn: cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX must be updated before dn: cn=ADTrust Agents,cn=privileges,cn=pbac,$SUFFIX Patch attached Martin^2 Works for me, ACK, thanks. Pushed to: master: * 2712b609cb1edb478aa6a55da1f6529befaa2edb Upgrade: fix trusts objectclass violationi ipa-4-1: * 60ff57b644e34b80784bd75c6c2da7a04d248b2c Upgrade: fix trusts objectclass violationi ipa-4-0: * ae9e6842736f785b8b6e24493540c520a89e95a8 Upgrade: fix trusts objectclass violationi -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0027 Produce better error in group-add command.
On 11/13/2014 11:24 AM, Jan Cholasta wrote:
Dne 10.11.2014 v 13:24 David Kupka napsal(a):
On 11/10/2014 08:20 AM, Jan Cholasta wrote:
Hi,
Dne 7.11.2014 v 15:26 David Kupka napsal(a):
https://fedorahosted.org/freeipa/ticket/4611
I think you should use MutuallyExclusiveError.
Honza
Thanks, that's the error class I was searching for. Unfortunately, I
didn't know this one so I used more abstract error class.
Fixed patch attached.
Given the messages that are used for MutuallyExclusiveError everywhere
else in the framework, I think a better message would be gid cannot be
set for external group.
Fixed patch attached.
--
David Kupka
From dddadcc5c3ed5aff3880b7794d6d7ba7aae66d88 Mon Sep 17 00:00:00 2001
From: David Kupka dku...@redhat.com
Date: Wed, 5 Nov 2014 02:40:10 -0500
Subject: [PATCH] Produce better error in group-add command.
https://fedorahosted.org/freeipa/ticket/4611
---
ipalib/plugins/group.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipalib/plugins/group.py b/ipalib/plugins/group.py
index 03e6893e3c7604268b503b28ea39ed3f610aec47..d25ed9a1958119a5872db85e958323fdb8205366 100644
--- a/ipalib/plugins/group.py
+++ b/ipalib/plugins/group.py
@@ -287,7 +287,7 @@ class group_add(LDAPCreate):
if options['external']:
entry_attrs['objectclass'].append('ipaexternalgroup')
if 'gidnumber' in options:
-raise errors.RequirementError(name='gid')
+raise errors.MutuallyExclusiveError(reason=_('gid cannot be set for external group'))
elif not options['nonposix']:
entry_attrs['objectclass'].append('posixgroup')
if not 'gidnumber' in options:
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0028 Remove unneeded internal methods. Move code to public, methods.
On 11.11.2014 09:19, Petr Viktorin wrote: On 11/10/2014 08:21 AM, Jan Cholasta wrote: Hi, ACK. Pushed to master: 82c3c2b242c3f2b8113c2021cf4d17cab54c2a86 Pushed to ipa-4-1: 814479a5678741f106283b61666e4bd093852fa7 (required for David's patch #29) -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0029 Remove service file even if it isn't link.
On 13.11.2014 13:13, Petr Vobornik wrote: On 10.11.2014 08:30, Jan Cholasta wrote: Hi, Dne 7.11.2014 v 15:29 David Kupka napsal(a): Depends on freeipa-dkupka-0028. https://fedorahosted.org/freeipa/ticket/4658 ACK. Honza David, this patch doesn't apply on ipa-4-1 prerequisite patch #28 was resolved on ipa-4-1. Patch #29 was pushed to: master: e28eb13907053ca9d49e4bf66cb32820f1a2ef1d ipa-4-1: 51795254b2384a4b12908804b53c3da56e70f946 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH, slapi-nis] ID view-related patches to slapi-nis
On 29.10.2014 15:20, thierry bordaz wrote: On 10/29/2014 02:23 PM, Alexander Bokovoy wrote: On Wed, 29 Oct 2014, thierry bordaz wrote: The patches fixed the test case in https://bugzilla.redhat.com/show_bug.cgi?id=1157989. Hi Alexander, The patches are good to me. Ack thanks thierry was pushed to master: * https://git.fedorahosted.org/cgit/slapi-nis.git/commit/?id=778c95866f28d894822e37223b69816981d29529 * https://git.fedorahosted.org/cgit/slapi-nis.git/commit/?id=c9c9d1413a6950344bc842024fda84212cc7322f part of slapi-nis-0.54.1 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0161] Fix dyndb-ldap working dir permission
Dne 12.11.2014 v 13:33 Martin Basti napsal(a): On 11/11/14 16:58, Jan Cholasta wrote: Hi, Dne 11.11.2014 v 16:22 Martin Basti napsal(a): Using specfile to create file doesn't work if named user is not on system. Appropriate permission have to be set during ipa-dns installation. Patch attached Why is the directory set up in dnskeysyncinstance instead of bindinstance? Because, dnskeysyncinstance is the daemon which requires permission change. (dir is created by dyndb-ldap plugin) OK. But please rename the method to something more suitable (fix_dyndb_ldap_workdir_permissions?) and add a docstring/comment. Also please change the ticket link to https://fedorahosted.org/freeipa/ticket/4716 (cloned from BZ). The original patch was released with 4.1.1, shouldn't there be update in ipa-upgradeconfig? Cases: 1) fresh RPM install, no named user during RPM install - named doesn't start, user had to fix it immediately, can't wait until next release. 2) fresh RPM install, named user - no impact 3) upgrade IPA with DNS - no impact 4) upgrade IPA without DNS - after DNS installation, same as 1) 5) IPA 4.1.0 with installed DNS, upgrade to 4.1.2 - DNSSEC will not work (If user doesnt use DNSSEC) Only 5) looks serious for me, so here is updated patch. Could you do the update without the code duplication? In similar code an appropriate *instance method is usually called. Martin^2 Honza Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0027 Produce better error in group-add command.
Dne 13.11.2014 v 13:45 David Kupka napsal(a): On 11/13/2014 11:24 AM, Jan Cholasta wrote: Dne 10.11.2014 v 13:24 David Kupka napsal(a): On 11/10/2014 08:20 AM, Jan Cholasta wrote: Hi, Dne 7.11.2014 v 15:26 David Kupka napsal(a): https://fedorahosted.org/freeipa/ticket/4611 I think you should use MutuallyExclusiveError. Honza Thanks, that's the error class I was searching for. Unfortunately, I didn't know this one so I used more abstract error class. Fixed patch attached. Given the messages that are used for MutuallyExclusiveError everywhere else in the framework, I think a better message would be gid cannot be set for external group. Fixed patch attached. Thanks, ACK. Pushed to: master: b032debd233c70541e52d3ee677cb82f9840b291 ipa-4-1: cef8e06f8adc116936238264abf5883a0e49ec0a Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0161] Fix dyndb-ldap working dir permission
On 13/11/14 13:59, Jan Cholasta wrote:
Dne 12.11.2014 v 13:33 Martin Basti napsal(a):
On 11/11/14 16:58, Jan Cholasta wrote:
Hi,
Dne 11.11.2014 v 16:22 Martin Basti napsal(a):
Using specfile to create file doesn't work if named user is not on
system.
Appropriate permission have to be set during ipa-dns installation.
Patch attached
Why is the directory set up in dnskeysyncinstance instead of
bindinstance?
Because, dnskeysyncinstance is the daemon which requires permission
change.
(dir is created by dyndb-ldap plugin)
OK. But please rename the method to something more suitable
(fix_dyndb_ldap_workdir_permissions?) and add a docstring/comment.
Also please change the ticket link to
https://fedorahosted.org/freeipa/ticket/4716 (cloned from BZ).
The original patch was released with 4.1.1, shouldn't there be update
in ipa-upgradeconfig?
Cases:
1) fresh RPM install, no named user during RPM install - named doesn't
start, user had to fix it immediately, can't wait until next release.
2) fresh RPM install, named user - no impact
3) upgrade IPA with DNS - no impact
4) upgrade IPA without DNS - after DNS installation, same as 1)
5) IPA 4.1.0 with installed DNS, upgrade to 4.1.2 - DNSSEC will not
work (If user doesnt use DNSSEC)
Only 5) looks serious for me, so here is updated patch.
Could you do the update without the code duplication? In similar code
an appropriate *instance method is usually called.
Martin^2
Honza
Honza
Thanks.
updated patch attached.
Martin^2
--
Martin Basti
From b0fdc2d3e2feddcabb46bbef3fd1e9c519835164 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Tue, 11 Nov 2014 13:00:18 +0100
Subject: [PATCH] Fix named working directory permissions
Just adding dir to specfile doesnt work, because is not guarantee the
named is installed, during RPM installation.
Ticket: https://fedorahosted.org/freeipa/ticket/4716
---
freeipa.spec.in | 3 +--
install/tools/ipa-upgradeconfig | 26 ++
ipaplatform/base/paths.py | 1 +
ipaserver/install/dnskeysyncinstance.py | 18 ++
4 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 36c2a35e7a0c60d4f68e2d945688ee30506e47c6..d0e9f910e2247ce1620e9b62f412d43ff663652d 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -420,7 +420,6 @@ mkdir -p %{buildroot}%{_usr}/share/ipa/html/
/bin/touch %{buildroot}%{_usr}/share/ipa/html/preferences.html
mkdir -p %{buildroot}%{_initrddir}
mkdir %{buildroot}%{_sysconfdir}/sysconfig/
-mkdir -p %{buildroot}%{_localstatedir}/named/dyndb-ldap/ipa/
install -m 644 init/ipa_memcached.conf %{buildroot}%{_sysconfdir}/sysconfig/ipa_memcached
install -m 644 init/ipa-dnskeysyncd.conf %{buildroot}%{_sysconfdir}/sysconfig/ipa-dnskeysyncd
install -m 644 init/ipa-ods-exporter.conf %{buildroot}%{_sysconfdir}/sysconfig/ipa-ods-exporter
@@ -660,7 +659,6 @@ fi
%config(noreplace) %{_sysconfdir}/sysconfig/ipa-ods-exporter
%dir %attr(0700,apache,apache) %{_localstatedir}/run/ipa_memcached/
%dir %attr(0700,root,root) %{_localstatedir}/run/ipa/
-%dir %attr(0770,named,named) %{_localstatedir}/named/dyndb-ldap/ipa/
# NOTE: systemd specific section
%{_tmpfilesdir}/%{name}.conf
%attr(644,root,root) %{_unitdir}/ipa.service
@@ -774,6 +772,7 @@ fi
%attr(700,root,root) %dir %{_localstatedir}/lib/ipa/sysupgrade
%attr(755,root,root) %dir %{_localstatedir}/lib/ipa/pki-ca
%ghost %{_localstatedir}/lib/ipa/pki-ca/publish
+%ghost %{_localstatedir}/named/dyndb-ldap/ipa
%attr(755,root,root) %{_libdir}/krb5/plugins/kdb/ipadb.so
%{_mandir}/man1/ipa-replica-conncheck.1.gz
%{_mandir}/man1/ipa-replica-install.1.gz
diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig
index 6556d8f313d3a9efeb32d4cba97cb82796459652..7655451becc8d49ef361a5e14c1aea8aaf18f696 100644
--- a/install/tools/ipa-upgradeconfig
+++ b/install/tools/ipa-upgradeconfig
@@ -30,6 +30,7 @@ import shutil
import pwd
import fileinput
import ConfigParser
+import grp
from ipalib import api
import SSSDConfig
@@ -1161,6 +1162,30 @@ def mask_named_regular():
return False
+def fix_dyndb_ldap_workdir_permissions():
+Fix dyndb-ldap working dir permissions. DNSSEC daemons requires it
+if sysupgrade.get_upgrade_state('dns', 'dyndb_ipa_workdir_perm'):
+return
+
+if bindinstance.named_conf_exists():
+root_logger.info('[Fix bind-dyndb-ldap IPA working directory]')
+named = services.knownservices.named
+
+try:
+named_uid = pwd.getpwnam(named.get_user_name()).pw_uid
+except KeyError:
+raise RuntimeError(Named UID not found)
+
+try:
+named_gid = grp.getgrnam(named.get_group_name()).gr_gid
+except KeyError:
+raise RuntimeError(Named GID not found)
+
+dnskeysyncinstance.set_dyndb_ldap_workdir_permissions(named_uid,
+
Re: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add
On Thu, 2014-11-13 at 13:17 +0100, Martin Kosek wrote:
On 11/13/2014 07:53 AM, Nathaniel McCallum wrote:
On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote:
This is possible because python-qrcode's output now fits in a standard
terminal. Also, update ipa-otp-import and otptoken-add-yubikey to
disable QR code output as it doesn't make sense in these contexts.
https://fedorahosted.org/freeipa/ticket/4703
I removed the period from the doc string to maintain consistency with
the rest of the plugin.
Nathaniel
I am not reviewing, just curious. What is the purpose of --qrcode option with
default=True?
takes_options = LDAPCreate.takes_options + (
-Flag('qrcode?', label=_('Display QR code')),
+Flag('qrcode', label=_('Display QR code'), default=True),
)
How can user turn it off? Both passing no option and passing --qrcode will get
the same result, no? :-)
Shouldn't we instead change --qrcode to --no-qrcode and process somehow fill
qrcode=0 when it's enabled? (To achieve API compatibility with old clients).
I see three options:
1. Don't let the user turn it off from the command line (he can still
turn it off from the Python API).
2. Change it to --no-qrcode (API change)
3. Change the type to Bool (API change)
Like you, I like #2 the best. Attached is an implementation.
From 816d3d5f98b78a8b82d81ef2f7162614b8ead4b2 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Thu, 6 Nov 2014 15:30:13 -0500
Subject: [PATCH] Enable QR code display by default in otptoken-add
This is possible because python-qrcode's output now fits in a standard
terminal. Also, update ipa-otp-import and otptoken-add-yubikey to
disable QR code output as it doesn't make sense in these contexts.
https://fedorahosted.org/freeipa/ticket/4703
---
API.txt | 2 +-
VERSION | 4 ++--
ipalib/plugins/otptoken.py | 4 ++--
ipalib/plugins/otptoken_yubikey.py | 1 +
ipaserver/install/ipa_otptoken_import.py | 2 +-
5 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/API.txt b/API.txt
index 491d7a76fd1d2d50208d314d1600839ce295..357c0b1aeaafcacf8d82d57fbfb3fabc21ec8f93 100644
--- a/API.txt
+++ b/API.txt
@@ -2611,7 +2611,7 @@ option: Int('ipatokentotpclockoffset', attribute=True, autofill=True, cli_name='
option: Int('ipatokentotptimestep', attribute=True, autofill=True, cli_name='interval', default=30, minvalue=5, multivalue=False, required=False)
option: Str('ipatokenvendor', attribute=True, cli_name='vendor', multivalue=False, required=False)
option: Flag('no_members', autofill=True, default=False, exclude='webui')
-option: Flag('qrcode?', autofill=True, default=False)
+option: Flag('no_qrcode', autofill=True, default=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
option: Str('setattr*', cli_name='setattr', exclude='webui')
option: StrEnum('type', attribute=False, autofill=True, cli_name='type', default=u'totp', multivalue=False, required=False, values=(u'totp', u'hotp', u'TOTP', u'HOTP'))
diff --git a/VERSION b/VERSION
index b0d41e5e1ec59ddefbdcccf588b97bac2ff798ee..bae782a4ec4333f8fdb610465a7b9ea3877c990e 100644
--- a/VERSION
+++ b/VERSION
@@ -90,5 +90,5 @@ IPA_DATA_VERSION=2010061412
# #
IPA_API_VERSION_MAJOR=2
-IPA_API_VERSION_MINOR=108
-# Last change: pvoborni - manage authorization of keytab operations
+IPA_API_VERSION_MINOR=109
+# Last change: npmccallum - display qrcode by default
diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py
index 2b5f1c5fb83341d392e165a3507f5076820f1d3a..dc687e37b398fb413cd565ac9793a013beda8504 100644
--- a/ipalib/plugins/otptoken.py
+++ b/ipalib/plugins/otptoken.py
@@ -249,7 +249,7 @@ class otptoken_add(LDAPCreate):
msg_summary = _('Added OTP token %(value)s')
takes_options = LDAPCreate.takes_options + (
-Flag('qrcode?', label=_('Display QR code')),
+Flag('no_qrcode', label=_('Do not display QR code'), default=False),
)
has_output_params = LDAPCreate.has_output_params + (
@@ -329,7 +329,7 @@ class otptoken_add(LDAPCreate):
rv = super(otptoken_add, self).output_for_cli(textui, output, *args, **options)
# Print QR code to terminal if specified
-if uri and options.get('qrcode', False):
+if uri and not options.get('no_qrcode', False):
print \n
qr = qrcode.QRCode()
qr.add_data(uri)
diff --git a/ipalib/plugins/otptoken_yubikey.py b/ipalib/plugins/otptoken_yubikey.py
index e70ddb6e42b5ea34d7ebecb252d6bbd73ac64d03..7095887ac7cdf5d4b7d0d30edc6cab046664 100644
--- a/ipalib/plugins/otptoken_yubikey.py
+++ b/ipalib/plugins/otptoken_yubikey.py
@@ -124,6 +124,7 @@ class otptoken_add_yubikey(Command):
Re: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add
On 13.11.2014 16:00, Nathaniel McCallum wrote:
On Thu, 2014-11-13 at 13:17 +0100, Martin Kosek wrote:
On 11/13/2014 07:53 AM, Nathaniel McCallum wrote:
On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote:
This is possible because python-qrcode's output now fits in a standard
terminal. Also, update ipa-otp-import and otptoken-add-yubikey to
disable QR code output as it doesn't make sense in these contexts.
https://fedorahosted.org/freeipa/ticket/4703
I removed the period from the doc string to maintain consistency with
the rest of the plugin.
Nathaniel
I am not reviewing, just curious. What is the purpose of --qrcode option with
default=True?
takes_options = LDAPCreate.takes_options + (
-Flag('qrcode?', label=_('Display QR code')),
+Flag('qrcode', label=_('Display QR code'), default=True),
)
How can user turn it off? Both passing no option and passing --qrcode will get
the same result, no? :-)
Shouldn't we instead change --qrcode to --no-qrcode and process somehow fill
qrcode=0 when it's enabled? (To achieve API compatibility with old clients).
I see three options:
1. Don't let the user turn it off from the command line (he can still
turn it off from the Python API).
2. Change it to --no-qrcode (API change)
3. Change the type to Bool (API change)
Like you, I like #2 the best. Attached is an implementation.
I like --no-qrcode as well.
Should we also keep qrcode as 'no_option' to maintain API compatibility
(but not CLI)?
--
Petr Vobornik
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add
On Thu, 2014-11-13 at 16:13 +0100, Petr Vobornik wrote:
On 13.11.2014 16:00, Nathaniel McCallum wrote:
On Thu, 2014-11-13 at 13:17 +0100, Martin Kosek wrote:
On 11/13/2014 07:53 AM, Nathaniel McCallum wrote:
On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote:
This is possible because python-qrcode's output now fits in a standard
terminal. Also, update ipa-otp-import and otptoken-add-yubikey to
disable QR code output as it doesn't make sense in these contexts.
https://fedorahosted.org/freeipa/ticket/4703
I removed the period from the doc string to maintain consistency with
the rest of the plugin.
Nathaniel
I am not reviewing, just curious. What is the purpose of --qrcode option
with
default=True?
takes_options = LDAPCreate.takes_options + (
-Flag('qrcode?', label=_('Display QR code')),
+Flag('qrcode', label=_('Display QR code'), default=True),
)
How can user turn it off? Both passing no option and passing --qrcode will
get
the same result, no? :-)
Shouldn't we instead change --qrcode to --no-qrcode and process somehow
fill
qrcode=0 when it's enabled? (To achieve API compatibility with old
clients).
I see three options:
1. Don't let the user turn it off from the command line (he can still
turn it off from the Python API).
2. Change it to --no-qrcode (API change)
3. Change the type to Bool (API change)
Like you, I like #2 the best. Attached is an implementation.
I like --no-qrcode as well.
Should we also keep qrcode as 'no_option' to maintain API compatibility
(but not CLI)?
I don't think it is necessary. It only makes sense to specify --qrcode
in an interactive session.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0075] Ensure users exist when assigning tokens to them
On 13.11.2014 07:51, Nathaniel McCallum wrote: On Mon, 2014-11-10 at 08:36 +0100, Jan Cholasta wrote: Hi, Dne 24.10.2014 v 22:21 Nathaniel McCallum napsal(a): https://fedorahosted.org/freeipa/ticket/4642 please use userobj.handle_not_found(owner) instead of raising NotFound manually. Fixed. Pushed to: master: c38e2d7394522a4b4f98f9d7e1ce234fa3be985f ipa-4-1: 2c1d40bf1f649edb82eafb29b7ce62a922e051f6 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0075] Ensure users exist when assigning tokens to them
On 13.11.2014 16:19, Petr Vobornik wrote: On 13.11.2014 07:51, Nathaniel McCallum wrote: On Mon, 2014-11-10 at 08:36 +0100, Jan Cholasta wrote: Hi, Dne 24.10.2014 v 22:21 Nathaniel McCallum napsal(a): https://fedorahosted.org/freeipa/ticket/4642 please use userobj.handle_not_found(owner) instead of raising NotFound manually. Fixed. and also ACK :) Pushed to: master: c38e2d7394522a4b4f98f9d7e1ce234fa3be985f ipa-4-1: 2c1d40bf1f649edb82eafb29b7ce62a922e051f6 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0164] Fix warning message should not contain CLI commands due WebUI
Ticket: https://fedorahosted.org/freeipa/ticket/4647
Patch attached.
--
Martin Basti
From 98132a1ba593cb4b4390678a2037b9db92b5905b Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Thu, 13 Nov 2014 14:02:02 +0100
Subject: [PATCH] Fix warning message should not contain CLI commands
Message is now universal for both CLI and WebUI
Ticket: https://fedorahosted.org/freeipa/ticket/4647
---
ipalib/messages.py | 3 +--
ipalib/plugins/dns.py | 8 +++-
ipatests/test_xmlrpc/test_dns_plugin.py | 6 +++---
3 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/ipalib/messages.py b/ipalib/messages.py
index 5eeab3c54caf3a7318d89a4aeaee1357fceb787f..1e28cd1d6d572f7698ed3221e29c29160963ebad 100644
--- a/ipalib/messages.py
+++ b/ipalib/messages.py
@@ -175,8 +175,7 @@ class OptionSemanticChangedWarning(PublicMessage):
errno = 13005
type = warning
-format = _(usemantic of '%(option)s' option was changed:
- u%(current_behavior)s.\n%(hint)s)
+format = _(uSemantic was changed: %(current_behavior)s.)
class DNSServerNotRespondingWarning(PublicMessage):
diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
index dd1e640f4062a32921bf1edf316e122b81a6d485..133b562dc16aa78646c127265532a0a991bd5398 100644
--- a/ipalib/plugins/dns.py
+++ b/ipalib/plugins/dns.py
@@ -2369,11 +2369,9 @@ class dnszone(DNSZoneBase):
messages.add_message(
options['version'],
result, messages.OptionSemanticChangedWarning(
-option=u--name-server,
-current_behavior=_(uthe option is used only for
- usetting up the SOA MNAME attribute),
-hint=_(uTo edit NS record(s) in zone apex, use command
- u'dnsrecord-mod [zone] @ --ns-rec=nameserver'.)
+current_behavior=_(
+uthe name server value is used only for setting up
+uthe SOA MNAME attribute),
)
)
diff --git a/ipatests/test_xmlrpc/test_dns_plugin.py b/ipatests/test_xmlrpc/test_dns_plugin.py
index a34d11a3278c67a3d00ca8f59bb8d8d19cf8a46e..35579dec1912117e19a9cdaf6f54938cbaed75ca 100644
--- a/ipatests/test_xmlrpc/test_dns_plugin.py
+++ b/ipatests/test_xmlrpc/test_dns_plugin.py
@@ -497,9 +497,9 @@ class test_dns(Declarative):
'objectclass': objectclasses.dnszone,
},
'messages': (
-{'message': usemantic of '--name-server' option was changed: the option is used only for setting up
-u the SOA MNAME attribute.\nTo edit NS record(s) in zone apex, use command
-u'dnsrecord-mod [zone] @ --ns-rec=nameserver'.,
+{'message': uSemantic was changed: the name server value
+uis used only for setting up the SOA MNAME
+uattribute.,
'code': 13005,
'type': u'warning',
'name': u'OptionSemanticChangedWarning'},
--
1.8.3.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add
On 11/13/2014 04:40 PM, Petr Vobornik wrote:
On 13.11.2014 16:19, Nathaniel McCallum wrote:
On Thu, 2014-11-13 at 16:13 +0100, Petr Vobornik wrote:
On 13.11.2014 16:00, Nathaniel McCallum wrote:
On Thu, 2014-11-13 at 13:17 +0100, Martin Kosek wrote:
On 11/13/2014 07:53 AM, Nathaniel McCallum wrote:
On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote:
This is possible because python-qrcode's output now fits in a
standard
terminal. Also, update ipa-otp-import and otptoken-add-yubikey to
disable QR code output as it doesn't make sense in these contexts.
https://fedorahosted.org/freeipa/ticket/4703
I removed the period from the doc string to maintain consistency with
the rest of the plugin.
Nathaniel
I am not reviewing, just curious. What is the purpose of --qrcode
option with
default=True?
takes_options = LDAPCreate.takes_options + (
-Flag('qrcode?', label=_('Display QR code')),
+Flag('qrcode', label=_('Display QR code'), default=True),
)
How can user turn it off? Both passing no option and passing
--qrcode will get
the same result, no? :-)
Shouldn't we instead change --qrcode to --no-qrcode and process
somehow fill
qrcode=0 when it's enabled? (To achieve API compatibility with old
clients).
I see three options:
1. Don't let the user turn it off from the command line (he can still
turn it off from the Python API).
2. Change it to --no-qrcode (API change)
3. Change the type to Bool (API change)
Like you, I like #2 the best. Attached is an implementation.
I like --no-qrcode as well.
Should we also keep qrcode as 'no_option' to maintain API compatibility
(but not CLI)?
I don't think it is necessary. It only makes sense to specify --qrcode
in an interactive session.
Makes sense.
ACK
Not pushing yet to give time for NACK if anybody doesn't agree with the
API change.
Hold on, what is happening here?
Aren't all clients since 4.0 sending the qrcode option to the server?
We absolutely can not break backwards compatibility with released versions.
We also should not break the CLI. Just make it a no-op option, and say
it's deprecated in the doc.
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add
On Thu, 2014-11-13 at 16:57 +0100, Petr Viktorin wrote:
On 11/13/2014 04:40 PM, Petr Vobornik wrote:
On 13.11.2014 16:19, Nathaniel McCallum wrote:
On Thu, 2014-11-13 at 16:13 +0100, Petr Vobornik wrote:
On 13.11.2014 16:00, Nathaniel McCallum wrote:
On Thu, 2014-11-13 at 13:17 +0100, Martin Kosek wrote:
On 11/13/2014 07:53 AM, Nathaniel McCallum wrote:
On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote:
This is possible because python-qrcode's output now fits in a
standard
terminal. Also, update ipa-otp-import and otptoken-add-yubikey to
disable QR code output as it doesn't make sense in these contexts.
https://fedorahosted.org/freeipa/ticket/4703
I removed the period from the doc string to maintain consistency with
the rest of the plugin.
Nathaniel
I am not reviewing, just curious. What is the purpose of --qrcode
option with
default=True?
takes_options = LDAPCreate.takes_options + (
-Flag('qrcode?', label=_('Display QR code')),
+Flag('qrcode', label=_('Display QR code'), default=True),
)
How can user turn it off? Both passing no option and passing
--qrcode will get
the same result, no? :-)
Shouldn't we instead change --qrcode to --no-qrcode and process
somehow fill
qrcode=0 when it's enabled? (To achieve API compatibility with old
clients).
I see three options:
1. Don't let the user turn it off from the command line (he can still
turn it off from the Python API).
2. Change it to --no-qrcode (API change)
3. Change the type to Bool (API change)
Like you, I like #2 the best. Attached is an implementation.
I like --no-qrcode as well.
Should we also keep qrcode as 'no_option' to maintain API compatibility
(but not CLI)?
I don't think it is necessary. It only makes sense to specify --qrcode
in an interactive session.
Makes sense.
ACK
Not pushing yet to give time for NACK if anybody doesn't agree with the
API change.
Hold on, what is happening here?
Aren't all clients since 4.0 sending the qrcode option to the server?
We absolutely can not break backwards compatibility with released versions.
We also should not break the CLI. Just make it a no-op option, and say
it's deprecated in the doc.
As I understand the current behavior, the qrcode option is *not* sent to
the server by default in any scenario. The only thing this change would
break would be if someone had scripted on top of this and had manually
specified the qrcode option. I think this is extremely unlikely as
scripts are much more likely to want to disable the qrcode output.
Nathaniel
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0165] --zonemgr options must be unicode
To allow IDNA zonemgr email, value must be unicode not ASCII Ticket: https://fedorahosted.org/freeipa/ticket/4724 Patch attached. -- Martin Basti From a90379c83e3e10373e54868402f55e965713236e Mon Sep 17 00:00:00 2001 From: Martin Basti mba...@redhat.com Date: Thu, 13 Nov 2014 18:22:22 +0100 Subject: [PATCH] Fix: zonemgr must be unicode value To support IDNA --zonemgr option must be unicode not ascii https://fedorahosted.org/freeipa/ticket/4724 --- ipaserver/install/bindinstance.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ipaserver/install/bindinstance.py b/ipaserver/install/bindinstance.py index 6cf018e9cda3734a99a8ac5ac1df134e9e4c2293..70e987aa1eb48466c36cae5aadda1aa56f9c34f9 100644 --- a/ipaserver/install/bindinstance.py +++ b/ipaserver/install/bindinstance.py @@ -403,6 +403,8 @@ def zonemgr_callback(option, opt_str, value, parser): # validate the value first try: +# IDNA support requires unicode +value = value.decode(sys.stdin.encoding) validate_zonemgr_str(value) except ValueError, e: parser.error(invalid zonemgr: + unicode(e)) -- 1.8.3.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add
On 11/13/2014 06:02 PM, Nathaniel McCallum wrote:
On Thu, 2014-11-13 at 16:57 +0100, Petr Viktorin wrote:
On 11/13/2014 04:40 PM, Petr Vobornik wrote:
On 13.11.2014 16:19, Nathaniel McCallum wrote:
On Thu, 2014-11-13 at 16:13 +0100, Petr Vobornik wrote:
On 13.11.2014 16:00, Nathaniel McCallum wrote:
On Thu, 2014-11-13 at 13:17 +0100, Martin Kosek wrote:
On 11/13/2014 07:53 AM, Nathaniel McCallum wrote:
On Thu, 2014-11-06 at 15:33 -0500, Nathaniel McCallum wrote:
This is possible because python-qrcode's output now fits in a
standard
terminal. Also, update ipa-otp-import and otptoken-add-yubikey to
disable QR code output as it doesn't make sense in these contexts.
https://fedorahosted.org/freeipa/ticket/4703
I removed the period from the doc string to maintain consistency with
the rest of the plugin.
Nathaniel
I am not reviewing, just curious. What is the purpose of --qrcode
option with
default=True?
takes_options = LDAPCreate.takes_options + (
-Flag('qrcode?', label=_('Display QR code')),
+Flag('qrcode', label=_('Display QR code'), default=True),
)
How can user turn it off? Both passing no option and passing
--qrcode will get
the same result, no? :-)
Shouldn't we instead change --qrcode to --no-qrcode and process
somehow fill
qrcode=0 when it's enabled? (To achieve API compatibility with old
clients).
I see three options:
1. Don't let the user turn it off from the command line (he can still
turn it off from the Python API).
2. Change it to --no-qrcode (API change)
3. Change the type to Bool (API change)
Like you, I like #2 the best. Attached is an implementation.
I like --no-qrcode as well.
Should we also keep qrcode as 'no_option' to maintain API compatibility
(but not CLI)?
I don't think it is necessary. It only makes sense to specify --qrcode
in an interactive session.
Makes sense.
ACK
Not pushing yet to give time for NACK if anybody doesn't agree with the
API change.
Hold on, what is happening here?
Aren't all clients since 4.0 sending the qrcode option to the server?
We absolutely can not break backwards compatibility with released versions.
We also should not break the CLI. Just make it a no-op option, and say
it's deprecated in the doc.
As I understand the current behavior, the qrcode option is *not* sent to
the server by default in any scenario.
Nope, defaults are filled in by the client. (And also on the server if
they're still missing; it's part of the common validation.)
You can try it out, actually:
$ ipa -vv otptoken-add
ipa: INFO: trying https://vm-175.idm.lab.eng.brq.redhat.com/ipa/json
ipa: INFO: Forwarding 'otptoken_add' to json server
'https://vm-175.idm.lab.eng.brq.redhat.com/ipa/json'
ipa: INFO: Request: {
id: 0,
method: otptoken_add,
params: [
[
null
],
{
all: false,
ipatokenhotpcounter: 0,
ipatokenotpalgorithm: sha1,
ipatokenotpdigits: 6,
ipatokenotpkey:
5\ufffdK\ufffd1\u000e\ufffd7,\ufffd_\ufffd\ufffd.0\ufffdM\ufffd\u0016\ufffd,
ipatokentotpclockoffset: 0,
ipatokentotptimestep: 30,
no_members: false,
qrcode: false,
raw: false,
type: totp,
version: 2.108
}
]
}
ipa: INFO: Response: {
error: null,
id: 0,
principal: ad...@idm.lab.eng.brq.redhat.com,
...
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients
On Fri, 2014-11-07 at 15:39 +0100, Martin Kosek wrote:
On 11/07/2014 03:28 PM, Nathaniel McCallum wrote:
On Nov 7, 2014, at 9:21 AM, Martin Kosek mko...@redhat.com wrote:
On 11/07/2014 03:03 PM, Simo Sorce wrote:
On Fri, 07 Nov 2014 14:53:17 +0100
Martin Kosek mko...@redhat.com wrote:
On 11/07/2014 02:51 PM, Simo Sorce wrote:
On Fri, 07 Nov 2014 14:26:06 +0100
Martin Kosek mko...@redhat.com wrote:
On 11/07/2014 02:20 PM, Simo Sorce wrote:
On Fri, 07 Nov 2014 08:02:02 +0100
Martin Kosek mko...@redhat.com wrote:
On 11/07/2014 01:46 AM, Simo Sorce wrote:
On Thu, 06 Nov 2014 18:00:21 -0500
Nathaniel McCallum npmccal...@redhat.com wrote:
On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote:
- Original Message -
On 3.10.2013 23:43, Nathaniel McCallum wrote:
Patch attached.
I'm curious - what is the purpose of this patch? To prevent 1
second timeouts and re-transmits when OTP is in place?
What is the expected performance impact? Could it be
configured for OTP separately - somehow? (I guess that it is
not possible now ...)
It benefits also communication of large packets (when large
MS-PAC or CAMMAC AD Data are attached), so it is a better
choice for IPA in general. Especially given we have multiple
KDC processes configured we do not want clients wasting KDC
resources by making multiple processes do the same operation.
So apparently this patch never got reviewed over a year ago.
It was related to a bug which was opened in SSSD. However, when
it became clear we wanted to solve this in FreeIPA, the SSSD
bug was closed but no corresponding FreeIPA bug was opened. The
patch then fell through the cracks.
Right - without an associated ticket tracking the patch, it is
too easy to loose it unless the author prods people to review it.
Without this patch, if OTP validation runs long we get
retransmits and failures.
One question I have is how to handle this for upgrades since (I
think) this patch only handles new installs.
Anyway, this patch is somewhat urgent now. So help is
appreciated.
I have attached a rebased version which has no other changes.
Nathaniel
I am not sure we can do much on updates, we do not have a
client-update tool, I would just document it I guess.
Otherwise we'd have to go back to sssd which can inject
additional values in krb5.conf, however I am not sure it would
be ok to set something like this in the sssd's pubconf
includes ...
Agreed, pubconf update does not sound right.
However, we already update krb5.conf on client updates, in %post:
%post client
if [ $1 -gt 1 ] ; then
# Has the client been configured?
restore=0
test -f '/var/lib/ipa-client/sysrestore/sysrestore.index'
restore=$(wc -l
'/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print
$1}')
if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then
if ! grep -E -q
'/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf
2/dev/null ; then
echo
includedir /var/lib/sss/pubconf/krb5.include.d/
/etc/krb5.conf.ipanew cat /etc/krb5.conf
/etc/krb5.conf.ipanew
mv /etc/krb5.conf.ipanew /etc/krb5.conf
/sbin/restorecon /etc/krb5.conf
fi
fi
...
This particular update is more difficult as not a first line
needs to be changed. Without adding ipa client update tool with
some reasonable krb5.conf parser, we could do something along
the lines of
sed -E 0i 's/(forwardable = \w+)/\1\n udp_preference_limit =
0/g' /etc/krb5.conf
(tested), but it is not pretty.
What happen the next time you run it again ?
Simo.
It would of course be added again, you would need to first grep for
presence of udp_preference_limit setting. Question is if this
approach is safe enough to be in our client %post upgrade. We
already upgrade krb5.conf here, just the change is much easier as
we just add a line to the beginning of the file.
Well the concern (aside of duplication) is that an admin may
correct the krb5.conf file to remove that option (for example
because his clients also connect to a differen (older) KDC and must
use UDP in preference. But now we end up messing with its krb5.conf
every time an update is released. An update tool that keep tracks
of whether a specific update has already been applied and does not
retry every time would be needed IMO.
Simo.
In 4.1.x (as there is not much time to develop a separate client
update tool), we could grep just for udp_preference_limit presence
so that if admin changes it's value or comment it, it would not be
added again.
Ok then maybe we add this:
# The following value has been added by a freeipa client update
# if you want to disable it, please comment it, do not delete it
# or it will be re-added on the next update
udp_preference_limit = 0
Re: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients
On Thu, 2014-11-13 at 14:02 -0500, Nathaniel McCallum wrote:
On Fri, 2014-11-07 at 15:39 +0100, Martin Kosek wrote:
On 11/07/2014 03:28 PM, Nathaniel McCallum wrote:
On Nov 7, 2014, at 9:21 AM, Martin Kosek mko...@redhat.com wrote:
On 11/07/2014 03:03 PM, Simo Sorce wrote:
On Fri, 07 Nov 2014 14:53:17 +0100
Martin Kosek mko...@redhat.com wrote:
On 11/07/2014 02:51 PM, Simo Sorce wrote:
On Fri, 07 Nov 2014 14:26:06 +0100
Martin Kosek mko...@redhat.com wrote:
On 11/07/2014 02:20 PM, Simo Sorce wrote:
On Fri, 07 Nov 2014 08:02:02 +0100
Martin Kosek mko...@redhat.com wrote:
On 11/07/2014 01:46 AM, Simo Sorce wrote:
On Thu, 06 Nov 2014 18:00:21 -0500
Nathaniel McCallum npmccal...@redhat.com wrote:
On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote:
- Original Message -
On 3.10.2013 23:43, Nathaniel McCallum wrote:
Patch attached.
I'm curious - what is the purpose of this patch? To prevent 1
second timeouts and re-transmits when OTP is in place?
What is the expected performance impact? Could it be
configured for OTP separately - somehow? (I guess that it is
not possible now ...)
It benefits also communication of large packets (when large
MS-PAC or CAMMAC AD Data are attached), so it is a better
choice for IPA in general. Especially given we have multiple
KDC processes configured we do not want clients wasting KDC
resources by making multiple processes do the same operation.
So apparently this patch never got reviewed over a year ago.
It was related to a bug which was opened in SSSD. However, when
it became clear we wanted to solve this in FreeIPA, the SSSD
bug was closed but no corresponding FreeIPA bug was opened. The
patch then fell through the cracks.
Right - without an associated ticket tracking the patch, it is
too easy to loose it unless the author prods people to review it.
Without this patch, if OTP validation runs long we get
retransmits and failures.
One question I have is how to handle this for upgrades since (I
think) this patch only handles new installs.
Anyway, this patch is somewhat urgent now. So help is
appreciated.
I have attached a rebased version which has no other changes.
Nathaniel
I am not sure we can do much on updates, we do not have a
client-update tool, I would just document it I guess.
Otherwise we'd have to go back to sssd which can inject
additional values in krb5.conf, however I am not sure it would
be ok to set something like this in the sssd's pubconf
includes ...
Agreed, pubconf update does not sound right.
However, we already update krb5.conf on client updates, in %post:
%post client
if [ $1 -gt 1 ] ; then
# Has the client been configured?
restore=0
test -f '/var/lib/ipa-client/sysrestore/sysrestore.index'
restore=$(wc -l
'/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print
$1}')
if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then
if ! grep -E -q
'/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf
2/dev/null ; then
echo
includedir /var/lib/sss/pubconf/krb5.include.d/
/etc/krb5.conf.ipanew cat /etc/krb5.conf
/etc/krb5.conf.ipanew
mv /etc/krb5.conf.ipanew /etc/krb5.conf
/sbin/restorecon /etc/krb5.conf
fi
fi
...
This particular update is more difficult as not a first line
needs to be changed. Without adding ipa client update tool with
some reasonable krb5.conf parser, we could do something along
the lines of
sed -E 0i 's/(forwardable = \w+)/\1\n udp_preference_limit =
0/g' /etc/krb5.conf
(tested), but it is not pretty.
What happen the next time you run it again ?
Simo.
It would of course be added again, you would need to first grep for
presence of udp_preference_limit setting. Question is if this
approach is safe enough to be in our client %post upgrade. We
already upgrade krb5.conf here, just the change is much easier as
we just add a line to the beginning of the file.
Well the concern (aside of duplication) is that an admin may
correct the krb5.conf file to remove that option (for example
because his clients also connect to a differen (older) KDC and must
use UDP in preference. But now we end up messing with its krb5.conf
every time an update is released. An update tool that keep tracks
of whether a specific update has already been applied and does not
retry every time would be needed IMO.
Simo.
In 4.1.x (as there is not much time to develop a separate client
update tool), we could grep just for udp_preference_limit presence
so that if admin changes it's value or comment it, it would not be
added again.
Ok then maybe we add this:
# The
Re: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients
On Thu, 13 Nov 2014 14:20:14 -0500
Nathaniel McCallum npmccal...@redhat.com wrote:
On Thu, 2014-11-13 at 14:02 -0500, Nathaniel McCallum wrote:
On Fri, 2014-11-07 at 15:39 +0100, Martin Kosek wrote:
On 11/07/2014 03:28 PM, Nathaniel McCallum wrote:
On Nov 7, 2014, at 9:21 AM, Martin Kosek mko...@redhat.com
wrote:
On 11/07/2014 03:03 PM, Simo Sorce wrote:
On Fri, 07 Nov 2014 14:53:17 +0100
Martin Kosek mko...@redhat.com wrote:
On 11/07/2014 02:51 PM, Simo Sorce wrote:
On Fri, 07 Nov 2014 14:26:06 +0100
Martin Kosek mko...@redhat.com wrote:
On 11/07/2014 02:20 PM, Simo Sorce wrote:
On Fri, 07 Nov 2014 08:02:02 +0100
Martin Kosek mko...@redhat.com wrote:
On 11/07/2014 01:46 AM, Simo Sorce wrote:
On Thu, 06 Nov 2014 18:00:21 -0500
Nathaniel McCallum npmccal...@redhat.com wrote:
On Fri, 2013-10-04 at 06:12 -0400, Simo Sorce wrote:
- Original Message -
On 3.10.2013 23:43, Nathaniel McCallum wrote:
Patch attached.
I'm curious - what is the purpose of this patch? To
prevent 1 second timeouts and re-transmits when OTP
is in place?
What is the expected performance impact? Could it be
configured for OTP separately - somehow? (I guess
that it is not possible now ...)
It benefits also communication of large packets (when
large MS-PAC or CAMMAC AD Data are attached), so it
is a better choice for IPA in general. Especially
given we have multiple KDC processes configured we do
not want clients wasting KDC resources by making
multiple processes do the same operation.
So apparently this patch never got reviewed over a
year ago.
It was related to a bug which was opened in SSSD.
However, when it became clear we wanted to solve this
in FreeIPA, the SSSD bug was closed but no
corresponding FreeIPA bug was opened. The patch then
fell through the cracks.
Right - without an associated ticket tracking the patch,
it is too easy to loose it unless the author prods
people to review it.
Without this patch, if OTP validation runs long we get
retransmits and failures.
One question I have is how to handle this for upgrades
since (I think) this patch only handles new installs.
Anyway, this patch is somewhat urgent now. So help is
appreciated.
I have attached a rebased version which has no other
changes.
Nathaniel
I am not sure we can do much on updates, we do not have
a client-update tool, I would just document it I guess.
Otherwise we'd have to go back to sssd which can inject
additional values in krb5.conf, however I am not sure
it would be ok to set something like this in the sssd's
pubconf includes ...
Agreed, pubconf update does not sound right.
However, we already update krb5.conf on client updates,
in %post:
%post client
if [ $1 -gt 1 ] ; then
# Has the client been configured?
restore=0
test -f
'/var/lib/ipa-client/sysrestore/sysrestore.index'
restore=$(wc -l
'/var/lib/ipa-client/sysrestore/sysrestore.index' | awk
'{print $1}')
if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2
]; then if ! grep -E -q
'/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf
2/dev/null ; then
echo
includedir /var/lib/sss/pubconf/krb5.include.d/
/etc/krb5.conf.ipanew cat /etc/krb5.conf
/etc/krb5.conf.ipanew
mv /etc/krb5.conf.ipanew /etc/krb5.conf
/sbin/restorecon /etc/krb5.conf
fi
fi
...
This particular update is more difficult as not a first
line needs to be changed. Without adding ipa client
update tool with some reasonable krb5.conf parser, we
could do something along the lines of
sed -E 0i 's/(forwardable = \w+)/\1\n
udp_preference_limit = 0/g' /etc/krb5.conf
(tested), but it is not pretty.
What happen the next time you run it again ?
Simo.
It would of course be added again, you would need to first
grep for presence of udp_preference_limit setting.
Question is if this approach is safe enough to be in our
client %post upgrade. We already upgrade krb5.conf here,
just the change is much easier as we just add a line to
the beginning of the file.
Well the concern (aside of duplication) is that an admin
may correct the krb5.conf file to remove that option (for
example because his clients also connect to a differen
(older) KDC and must use UDP in preference. But now we end
up messing with its krb5.conf every time an update is
released. An update tool that keep tracks of whether a
specific update has already been applied and does not retry
every time would be needed IMO.
Simo.
In 4.1.x (as there
Re: [Freeipa-devel] FreeIPA integration with external DNS services
On Tue, 11 Nov 2014 16:29:51 +0100 Petr Spacek pspa...@redhat.com wrote: Hello, this thread is about RFE IPA servers when installed should register themselves in the external DNS https://fedorahosted.org/freeipa/ticket/4424 It is not a complete design, just a raw idea. Use case FreeIPA installation to a network with existing DNS infrastructure + network administrator who is not willing to add/maintain new DNS servers just for FreeIPA. High-level idea === - Transform dns* commands from FreeIPA framework to equivalent nsupdate commands and send DNS updates to existing DNS servers. - Provide necessary encryption/signing keys to nsupdate. 1) Integration to FreeIPA framework === First of all, we need to decide if external DNS integration can be used at the same time with FreeIPA-integrated DNS or not. Side-question is what to do if a first server is installed with external-DNS but another replica is being installed with integrated-DNS and so on. I think being able to integrate with an external DNS is important, and not just at the server level, being able to distribute TSIG keys to client would be nice too, though a lot less important, than getting server integration.. In other words, the question is if current dns.py plugin shipped with FreeIPA framework should be: a) Extended dns.py with dnsexternal-* commands -- Disadvantages: - It complicate FreeIPA DNS interface which is a complex beast even now. - We would have add condition to every DNS API call in installers which would increase horribleness of the installer code even more (or add another layer of abstraction...). I agree having a special command is undesirable. - I don't see a point in using integrated-DNS with external-DNS at the same time. To use integrated-DNS you have to get a proper DNS delegation from parent domain - and if you can get the delegation then there is no point in using external DNS ... I disagree on this point, it makes a lot of sense to have some zones maintained by IPA and ... some not. Advantages: - You can use external integrated DNS at the same time. We can achieve the same w/o a new ipa level command. b) Replace dns.py with another implementation of current dnszone-* dnsrecord-* API. - This seems like a cleaner approach to me. It could be shipped as ipa-server-dns-external package (opposed to standard ipa-server-dns package). Advantages: - It could seamlessly work with FreeIPA client installer because the dns*-nsupdate command transformation would be done on FreeIPA server and client doesn't need to know about it. - Does not require re-training/not much new documentation because commands are the same. Disadvantages: - You can't use integrated external DNS at the same time (but I don't think it justifies the added complexity). I disagree. One of the reason to use a mix is to allow smooth migrations where zones are moved into (or out of) IPA one by one. Petr^3 or anyone else, what do you propose? I think what I'd like to see is to be able to configure a DNS zone in LDAP and mark it external. The zone would held the TSIG keys necessary to perform DNS updates. When the regular ipa dnsrecord-add etc... commands are called, the framework detects that the zone is external, fewttches the TSIG key (if the user has access to it) and spawn an nsupdate command that will perform the update against whatever DNS server is authoritative for the zone. Some commands may be disabled if the zone is external and appropriate errors would be returned. 2) Authentication to external DNS server/keys = This is separate problem from FreeIPA framework integration. We will have to somehow store raw symmetric keys (for DNS TSIG) or keytabs (for DNS GSS-TSIG) and distribute them somehow to replicas so every replica can update DNS records as necessary. For TSIG keys I think we should just store them in a LDAP record, see above. For keytabs we can simply store them just like any other kerberos key if we really need it (in a trust case for example, we may not need a new keytab, we may be allowed to use our own credentials through the trust. So we'll need to explore a bit how to properly express that in configuration. REtrieval ok keytabs is then just a matter of running ipa-getkeytab -r on the replica that needs it. This will be the funny part because in case of AD trusts we have chicken-egg problem. You need to establish trust to get ticket for DNS/dc1.ad.example@AD principal but you can't (I guess) establish trust until proper DNS records are in place ... No, in this case we should create the records at trust establishment time using the admin credentials we have been provided. NO chicken-egg issue. For 'experimental' phase I would go with
