[Freeipa-devel] [PATCH] 370 Fixed missing KRA agent cert on replica.
The code that exports the KRA agent certificate has been moved
such that it will be executed both on master and replica.
https://fedorahosted.org/freeipa/ticket/5174
--
Endi S. Dewata
From 04abaf7354d5c140d2bb88c7a58e54f0691fcbe4 Mon Sep 17 00:00:00 2001
From: Endi S. Dewata edew...@redhat.com
Date: Sat, 1 Aug 2015 02:46:26 +0200
Subject: [PATCH] Fixed missing KRA agent cert on replica.
The code that exports the KRA agent certificate has been moved
such that it will be executed both on master and replica.
https://fedorahosted.org/freeipa/ticket/5174
---
ipaserver/install/krainstance.py | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/ipaserver/install/krainstance.py b/ipaserver/install/krainstance.py
index
50ab424b0e59becfea9e7af4b8d43a32ccbdc823..fa50c3dec897d63b9d3522d196054163f7b3369a
100644
--- a/ipaserver/install/krainstance.py
+++ b/ipaserver/install/krainstance.py
@@ -256,6 +256,15 @@ class KRAInstance(DogtagInstance):
os.remove(cfg_file)
shutil.move(paths.KRA_BACKUP_KEYS_P12, paths.KRACERT_P12)
+
+# export ipaCert with private key for client authentication
+args = [/usr/bin/pki,
+-d, paths.HTTPD_ALIAS_DIR,
+-C, paths.ALIAS_PWDFILE_TXT,
+client-cert-show, ipaCert,
+--client-cert, paths.KRA_AGENT_PEM]
+ipautil.run(args)
+
self.log.debug(completed creating KRA instance)
def __add_ra_user_to_agent_group(self):
@@ -330,14 +339,6 @@ class KRAInstance(DogtagInstance):
finally:
os.remove(filename)
-# export ipaCert with private key for client authentication
-args = [/usr/bin/pki,
--d, paths.HTTPD_ALIAS_DIR,
--C, paths.ALIAS_PWDFILE_TXT,
-client-cert-show, ipaCert,
---client-cert, paths.KRA_AGENT_PEM]
-ipautil.run(args)
-
def __add_vault_container(self):
sub_dict = {
'SUFFIX': self.suffix,
--
2.4.3
--
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 0002] Port from python-krbV to python-gssapi
On 2015-07-31 07:52, Jan Cholasta wrote: Hi Michael, Dne 29.7.2015 v 10:09 Michael Šimáček napsal(a): Hi, this is the first attempt to port FreeIPA from deprecated python3-incompatible python-krbV library to python-gssapi. The patch depends on python-kerberos-python-gssapi patch [1] to apply cleanly, but the overlap is small, so I think it can be at least partially reviewed without it. Comments: I removed Backend.krb and KRB5_CCache classes as they were wrappers around krbV classes. I added few utility functions to krb_utils module that perform part of its functionality (no need for classes, because gssapi acquire calls don't pass any context objects, they wouldn't have any state). I merged the two different kinit_keytab functions. GSSAPI doesn't provide any method (that I'm aware of) to get default ccache name. In most cases this is not needed as we can simply not pass any name and it will use the default. The ldap plugin had to be adjusted for this - the connect method now takes new use_gssapi argument, which can turn on gssapi support without the need to supply explicit ccache name. The only place where the ccache name is really needed is the test server, where I use system klist command to obtain it. I would prefer if the semantics were the same as in IPAdmin, i.e. GSSAPI is used by default if bind password is not specified, see IPAdmin.do_bind() in ipapython.ipaldap. Just to clarify, the current flow in ldap module is: if ccache: # I added or use_gssapi here in this patch gssapi_bind elif autobind: external_bind else: simple_bind and you would like it to be changed into: if bind_pw: simple_bind elif autobind: external_bind else: gssapi_bind Is that correct? It's also not possible to directly get default realm name, what I do is importing nonexistent name, cannonicalizing it and extracting the realm from it. Which should work but is ugly. It would be better if we could modify the places that use it to not need it at all, but it's mostly used in ldap code and I don't understand that part of FreeIPA. Alternative would be parsing /etc/krb.conf. You should use api.env.realm where possible. I think this should be most of the places where default realm is currently used, if not all of them. That would be great if all the usages could be replaced. How can I determine where api.env.realm can be used? In particular, I'm unsure about ipapython/config.py/__discover_config and ipaserver/plugins/join.py. Sorry for long patch, but I'm afraid it cannot be reasonably split. Ticket: https://fedorahosted.org/freeipa/ticket/5164 [1] https://fedorahosted.org/freeipa/ticket/5147 Honza Michael -- 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] 0028 add --out option to user-show
On 31/07/15 14:22, Martin Basti wrote: On 30/07/15 06:22, Fraser Tweedale wrote: On Thu, Jul 30, 2015 at 10:19:19AM +1000, Fraser Tweedale wrote: On Wed, Jul 29, 2015 at 03:48:47PM +0200, Jan Cholasta wrote: Dne 29.7.2015 v 15:46 Martin Basti napsal(a): On 29/07/15 15:41, Martin Basti wrote: On 25/07/15 03:40, Fraser Tweedale wrote: On Fri, Jul 24, 2015 at 05:53:56PM +0200, Tomas Babej wrote: On 07/24/2015 05:34 PM, Martin Basti wrote: On 24/07/15 16:52, Tomas Babej wrote: On 07/24/2015 03:40 PM, Fraser Tweedale wrote: The attached patch adds --out option to user-show for saving user's certificate(s) to file. Thanks, Fraser I hate to nitpick here, but is out really a descriptive option name here? I'd prefer something more explicit, like '--save-cert-to', or maybe even have this operation implemented as a separate command altogether. Tomas This keyword was already used with several commands. For consistency might be better to have it the same. True. I see this options is being used in the following commands: - cert-show - vault-retrieve - host-show - service-show - user-show (proposed) While the first two seem to be an acceptable fit for an option called --out, as they mainly deal with cert/secret, using the '--out' for the latter three is a poor decision imho. I agree the consistency is important, I'm just not happy to see this spread further. Tomas Perhaps we should go with something like `--certout' instead, and support `--certout' in addition to `--out' in host-show and service-show, esentially deprecating `--out' for those commands. Cheers, Fraser Good idea, but we should do this for all commands, at the same time. IMO this is not for 4.2, you may file a ticket to deprecate --out option and replace it by --certout or something. The in option is named --certificate, so it should be --certificate-out. I will do review is nobody is against this patch :) Martin^2 LGTM Is a ticket somewhere for this? No ticket; I just wanted it so I wrote the patch :) I'll file the ticket for future change to `--certificate-out' though. Ticket: https://fedorahosted.org/freeipa/ticket/5166 ACK Ticket for this patch created: https://fedorahosted.org/freeipa/ticket/5171 I amended commit message, ticket was added. Pushed to: ipa-4-2: 3332a0a7c83a9e35532327252231b71e07a44f13 master: 896783bae817ef16ca1cb31a0c434fe863287cc3 -- 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] [PATCH 017] certprofile-import: do not require profileId in profile data
On 30/07/15 12:44, Christian Heimes wrote: On 2015-07-24 12:41, Martin Basti wrote: On 24/07/15 05:15, Fraser Tweedale wrote: diff --git a/ipalib/plugins/certprofile.py b/ipalib/plugins/certprofile.py index 5550ed942521dbab2e783fba1570520268f9b378..fe8934690fe09499f0bacb6610d9815a2b4367a4 100644 --- a/ipalib/plugins/certprofile.py +++ b/ipalib/plugins/certprofile.py @@ -233,8 +233,8 @@ class certprofile_import(LDAPCreate): match = self.PROFILE_ID_PATTERN.search(options['file']) if match is None: -raise errors.ValidationError(name='file', -error=_(Profile ID is not present in profile data)) +# no profileId found, use CLI value as profileId. +options['file'] = u'profileId=%s\n%s' % (keys[0], options['file']) NACK This assignment has no external effect; `post_callback' is called with original `options['file']' and dogtag profile import can fail due to missing profileId. The solution is to do the same thing in post_callback; updated patch attached. Thanks, Fraser I dont like to have the same code twice in pre and post callback. Can you use contexmanager to store the right value in pre callback and then use it in post callback? (can find it in dns plugin, search for context) Sounds good to me! Christian PS: Context is a fancy name for a TLS dict. ;) ACK Pushed to: master: a4ade199aa594307cdd6bc43d1729cc42e92fd1e ipa-4-2: d80e90fa5c5ad41f5f29a02c11bca7c7da269938 -- 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] [patch 0007] tests: Allow Tracker.dn be an instance of Fuzzy
On 30/07/15 14:43, Lenka Doudova wrote: ACK, just configure your email client not to prepend '' to the patch. Lenka Dne 27.7.2015 v 12:32 Milan Kubík napsal(a): Hi, the patch changes the check on the Tracker.dn setter, allowing to use an instance of ipatests.util.Fuzzy to ease writing Trackers for plugins like CA ACL, which use ipaUniqueID as their primary key. Thanks, Milan Pushed to: master: 3f90aa0c18727f02e5e373ea0b625cfa6edb7a37 ipa-4-2: 3b90044f309548a7d0c508622b2858c010ba352f -- 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] [PATCH] 0035 client: Update DNS with all available local IP addresses.
On 28/07/15 09:52, David Kupka wrote:
On 27/07/15 16:45, David Kupka wrote:
On 15/01/15 17:13, David Kupka wrote:
On 01/15/2015 03:22 PM, David Kupka wrote:
On 01/15/2015 12:43 PM, David Kupka wrote:
On 01/12/2015 06:34 PM, Martin Basti wrote:
On 09/01/15 14:43, David Kupka wrote:
On 01/07/2015 04:15 PM, Martin Basti wrote:
On 07/01/15 12:27, David Kupka wrote:
https://fedorahosted.org/freeipa/ticket/4249
Thank you for patch:
1)
-root_logger.error(Cannot update DNS records!
- Failed to connect to server '%s'.,
server)
+ips = get_local_ipaddresses()
+except CalledProcessError as e:
+root_logger.error(Cannot update DNS records. %s % e)
IMO the error message should be more specific, add there
something
like
Unable to get local IP addresses. at least in log.debug()
2)
+lines = ipresult[0].replace('\\', '').split('\n')
.replace() is not needed
3)
+if len(ips) == 0:
if not ips:
is more pythonic by PEP8
Thanks for catching these. Updated patch attached.
merciful NACK
Thank you for the patch, unfortunately I hit one issue which needs
to be
resolved.
If sync PTR is activated in zone settings, and reverse zone
doesn't
exists, nsupdate/BIND returns SERVFAIL and ipa-client-install print
Error message, 'DNS update failed'. In fact, all A/ records was
succesfully updated, only PTR records failed.
Bind log:
named-pkcs11[28652]: updating zone 'example.com/IN': adding an RR at
'vm-101.example.com'
named-pkcs11[28652]: PTR record synchronization (addition) for
A/
'vm-101.example.com.' refused: unable to find active reverse zone
for IP
address '2620:52:0:104c:21a:4aff:fe10:4eaa': not found
With IPv6 we have several addresses from different reverse zones and
this situation may happen often.
I suggest following:
1) Print list of addresses which will be updated. (Now if update
fails,
user needs to read log, which addresses installer tried to update)
2) Split nsupdates per A/ record.
3a) If failed, check with DNS query if A/ and PTR record are
there
and print proper error message
3b) Just print A/ (or PTR) record may not be updated for
particular
IP address.
Any other suggestions are welcome.
After long discussion with DNS and UX guru I've implemented it this
way:
1. Call nsupdate only once with all updates.
2. Verify that the expected records are resolvable.
3. If no print list of missing A/, list of missing PTR records
and
list to mismatched PTR record.
As this is running inside client we can't much more and it's up to
user
to check what's rotten in his DNS setup.
Updated patch attached.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
One more change to behave well in -crazy- exotic environments that
resolves more PTR records for single IP.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Yet another change to make language nerds and our UX guru happy :-)
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Rebased patch attached.
Updated patch attached.
Just for record this patch is for dualstack/IPv6 support.
IMO this ticket also requires to fix ipa-join to support IPv6.
I still have doubts to have multihomed support as default, this may be
unexpected change of ipa-client-install behavior.
I know, is hard to detect which addresses user want to register in IPA
without crystal ball, but it should not be impossible :-) .
I propose following solution:
To add new options:
--multihomed or --all-ip-address - all IP addresses from client will be used
--ip-address - adress which will be registered on (IPA) DNS server
--ip-address-interface - interface from which address will be registered
0) without any option specified, current behavior will be used + IPv6
* detect which address is used to communicate with IPA server
* detect interface where this address belongs
* use ipv4 and all ipv6 addresses of this interface
* if --enable-dns-updates=true: configure SSSD as is configured now:
automatically detect which address is used + patched SSSD will also
updates proper IPv6 address
1) --multihomed or --all-ip-addresses (this is multihomed ticket)
* all adresses will be used
* if --enable-dns-updates=true: SSSD will be configured to send all
ip_addresses
2) --ip-address option specified:
* only specified addresses will be used (+ check if this addresses exist
locally)
* if --enable-dns-updates=true: ERROR dynamic updates may change this
address (user should choose static vs dynamic)
3) --ip-address-interface option specified:
* only addresses from specified interfaces will be used
* if --enable-dns-updates=true: SSSD will be configured to use these
Re: [Freeipa-devel] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit
Updated patch attached.
Thanks,
Gabe
On Thu, Jul 30, 2015 at 7:15 AM, Gabe Alford redhatri...@gmail.com wrote:
On Thu, Jul 30, 2015 at 1:32 AM, Jan Cholasta jchol...@redhat.com wrote:
Dne 30.7.2015 v 09:23 Jan Cholasta napsal(a):
Hi,
Dne 29.7.2015 v 17:23 Gabe Alford napsal(a):
Hello,
Fix for https://fedorahosted.org/freeipa/ticket/4023
Actually, 0 means unlimited for size limit, see
http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.search_ext_s
.
After reading the ticket I think this should be fixed the other way
around: make 0 mean unlimited for both time and size limit and fix the
config plugin and LDAPClient to respect that.
Thanks for the review. Updated patch attached.
--
Jan Cholasta
From 953f5bd85ee7d1ac6fee3034fda63b9a5783b418 Mon Sep 17 00:00:00 2001
From: Gabe redhatri...@gmail.com
Date: Fri, 31 Jul 2015 09:06:05 -0600
Subject: [PATCH] Standardize minvalue for ipasearchrecordlimit and
ipasesarchsizelimit for unlimited minvalue
https://fedorahosted.org/freeipa/ticket/4023
---
API.txt | 4 ++--
VERSION | 4 ++--
install/ui/test/data/ipa_init_commands.json | 10 +-
install/ui/test/data/ipa_init_objects.json | 10 +-
install/ui/test/data/json_metadata.json | 8
ipalib/plugins/baseldap.py | 4 ++--
ipalib/plugins/config.py| 10 +-
7 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/API.txt b/API.txt
index 2e19d6b2f1e16cc1c89d71ed7d443145426a28e3..ef1aa080c9b4c0139dc4fe77c27f47c7b6d91226 100644
--- a/API.txt
+++ b/API.txt
@@ -778,8 +778,8 @@ option: StrEnum('ipakrbauthzdata', attribute=True, autofill=False, cli_name='pac
option: Int('ipamaxusernamelength', attribute=True, autofill=False, cli_name='maxusername', minvalue=1, multivalue=False, required=False)
option: Bool('ipamigrationenabled', attribute=True, autofill=False, cli_name='enable_migration', multivalue=False, required=False)
option: Int('ipapwdexpadvnotify', attribute=True, autofill=False, cli_name='pwdexpnotify', minvalue=0, multivalue=False, required=False)
-option: Int('ipasearchrecordslimit', attribute=True, autofill=False, cli_name='searchrecordslimit', minvalue=-1, multivalue=False, required=False)
-option: Int('ipasearchtimelimit', attribute=True, autofill=False, cli_name='searchtimelimit', minvalue=-1, multivalue=False, required=False)
+option: Int('ipasearchrecordslimit', attribute=True, autofill=False, cli_name='searchrecordslimit', minvalue=0, multivalue=False, required=False)
+option: Int('ipasearchtimelimit', attribute=True, autofill=False, cli_name='searchtimelimit', minvalue=0, multivalue=False, required=False)
option: Str('ipaselinuxusermapdefault', attribute=True, autofill=False, cli_name='ipaselinuxusermapdefault', multivalue=False, required=False)
option: Str('ipaselinuxusermaporder', attribute=True, autofill=False, cli_name='ipaselinuxusermaporder', multivalue=False, required=False)
option: StrEnum('ipauserauthtype', attribute=True, autofill=False, cli_name='user_auth_type', csv=True, multivalue=True, required=False, values=(u'password', u'radius', u'otp', u'disabled'))
diff --git a/VERSION b/VERSION
index ca43f3e0c06880d355c068514134187c5edda175..f31498b39c53bd41fff20fc7a3d9de9a6bdf4397 100644
--- a/VERSION
+++ b/VERSION
@@ -90,5 +90,5 @@ IPA_DATA_VERSION=2010061412
# #
IPA_API_VERSION_MAJOR=2
-IPA_API_VERSION_MINOR=148
-# Last change: ftweedal - add --out option to user-show
+IPA_API_VERSION_MINOR=149
+# Last change: galford - Change ipasearchtimelime and ipasearchrecordslimit to 0 for unlimited
diff --git a/install/ui/test/data/ipa_init_commands.json b/install/ui/test/data/ipa_init_commands.json
index 743f508e2a733b766008bdd21838454ef7df8c21..477d7cf75aabd5c23dbf91a6305bfcbb9fbf5b1b 100644
--- a/install/ui/test/data/ipa_init_commands.json
+++ b/install/ui/test/data/ipa_init_commands.json
@@ -2446,13 +2446,13 @@
attribute: true,
class: Int,
deprecated_cli_aliases: [],
-doc: Maximum amount of time (seconds) for a search ( 0, or -1 for unlimited),
+doc: Maximum amount of time (seconds) for a search ( 0, or 0 for unlimited),
flags: [
nonempty
],
label: Search time limit,
maxvalue: 2147483647,
-minvalue: -1,
+minvalue: 0,
name: ipasearchtimelimit,
type: int
},
@@ -2460,13 +2460,13 @@
attribute: true,
class: Int,
deprecated_cli_aliases: [],
-
Re: [Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi
On Fri, 2015-07-31 at 16:41 +0200, Michael Šimáček wrote: On 2015-07-31 07:52, Jan Cholasta wrote: Hi Michael, Dne 29.7.2015 v 10:09 Michael Šimáček napsal(a): Hi, this is the first attempt to port FreeIPA from deprecated python3-incompatible python-krbV library to python-gssapi. The patch depends on python-kerberos-python-gssapi patch [1] to apply cleanly, but the overlap is small, so I think it can be at least partially reviewed without it. Comments: I removed Backend.krb and KRB5_CCache classes as they were wrappers around krbV classes. I added few utility functions to krb_utils module that perform part of its functionality (no need for classes, because gssapi acquire calls don't pass any context objects, they wouldn't have any state). I merged the two different kinit_keytab functions. GSSAPI doesn't provide any method (that I'm aware of) to get default ccache name. In most cases this is not needed as we can simply not pass any name and it will use the default. The ldap plugin had to be adjusted for this - the connect method now takes new use_gssapi argument, which can turn on gssapi support without the need to supply explicit ccache name. The only place where the ccache name is really needed is the test server, where I use system klist command to obtain it. I would prefer if the semantics were the same as in IPAdmin, i.e. GSSAPI is used by default if bind password is not specified, see IPAdmin.do_bind() in ipapython.ipaldap. Just to clarify, the current flow in ldap module is: if ccache: # I added or use_gssapi here in this patch gssapi_bind elif autobind: external_bind else: simple_bind I had to make this change as well for my replica promotion code, and incidentally used the same indicator use_gssapi. and you would like it to be changed into: if bind_pw: simple_bind elif autobind: external_bind else: gssapi_bind Is that correct? I think this is what Jan wanted, but I am wondering if it is the right thing to do. In ipa we have basically 2 possible default approaches. One is to use GSSAPI, and one is to use LDAPI with external bind. The latter makes sense mostly only when running as root, so I am wondering, should the default change depending on whether we are root and we are connecting to the local LDAP server ? If this is a sensible option it means we have to preserver use_gssapi as we may need to force use of gssapi in some case even when we are root and connectiong to the local server (for example to test that the local ccache can successfully be used). Jan, what do you think ? It's also not possible to directly get default realm name, what I do is importing nonexistent name, cannonicalizing it and extracting the realm from it. Which should work but is ugly. It would be better if we could modify the places that use it to not need it at all, but it's mostly used in ldap code and I don't understand that part of FreeIPA. Alternative would be parsing /etc/krb.conf. You should use api.env.realm where possible. I think this should be most of the places where default realm is currently used, if not all of them. That would be great if all the usages could be replaced. How can I determine where api.env.realm can be used? In particular, I'm unsure about ipapython/config.py/__discover_config and ipaserver/plugins/join.py. try: realm = api.env.realm except: realm = dirty gssapi trick ? Simo. Sorry for long patch, but I'm afraid it cannot be reasonably split. Ticket: https://fedorahosted.org/freeipa/ticket/5164 [1] https://fedorahosted.org/freeipa/ticket/5147 Honza Michael -- Simo Sorce * Red Hat, Inc * New York -- 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] 0691-0695 Modernization
On Fri, 2015-07-31 at 19:14 +0200, Petr Viktorin wrote: Hello, Here is a batch of mostly mechanical changes: removing deprecated features to prepare for Python 3. Do we have accompanying lint (or similar) tests that will prevent new patches from reintroducing py3 incompatible syntax ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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] programmer documentation
On 07/31/2015 10:39 AM, Milan Kubík wrote: On 07/30/2015 05:42 PM, Alexander Bokovoy wrote: On Thu, 30 Jul 2015, Milan Kubík wrote: Hi all, I'm curious, is there some documentation of the IPA internals? During my playing with plugins, I was quite amazed and frustrated at the code, not entirely (or remotely) understanding what happens after the call to a command starts and before I get the result. The main problem I have is that the command takes an argument. This argument gets automagically into LDAP, where it quite often is an attribute with a different name, and as the output of the command I get an object that has yet another name for the value I just sent to the command. Is there some (easy to understand) guide how this works, complete with the callback mechanism, etc? In general, where to search for $SUBJ and who to bug when it is missing or out of date? I know there is quite extensive tutorial to writing plugins in ipalib/__init__.py, but nowhere there are pre/post operation callbacks explained nor the format of the command output described (that I know of). Is there some guide that could even a newcomer use to get started? Can you point me to some documentation or designs for the framework itself, if it exists? Did you read my (outdated) guide already? https://abbra.fedorapeople.org/freeipa-extensibility.html It is first link in the http://www.freeipa.org/page/Documentation#Additional_Resources_2 section Hi, thanks for the link. Though outdated, it covers most of what I needed. Is there some document describing the rules used in JSON serialization? Sometimes the api call result has interesting representation of the values. Don't know of any. But you can always call `ipa` command with -vvv and observe the communication. -- 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] programmer documentation
On 07/31/2015 10:42 AM, Petr Vobornik wrote: On 07/31/2015 10:39 AM, Milan Kubík wrote: On 07/30/2015 05:42 PM, Alexander Bokovoy wrote: On Thu, 30 Jul 2015, Milan Kubík wrote: Hi all, I'm curious, is there some documentation of the IPA internals? During my playing with plugins, I was quite amazed and frustrated at the code, not entirely (or remotely) understanding what happens after the call to a command starts and before I get the result. The main problem I have is that the command takes an argument. This argument gets automagically into LDAP, where it quite often is an attribute with a different name, and as the output of the command I get an object that has yet another name for the value I just sent to the command. Is there some (easy to understand) guide how this works, complete with the callback mechanism, etc? In general, where to search for $SUBJ and who to bug when it is missing or out of date? I know there is quite extensive tutorial to writing plugins in ipalib/__init__.py, but nowhere there are pre/post operation callbacks explained nor the format of the command output described (that I know of). Is there some guide that could even a newcomer use to get started? Can you point me to some documentation or designs for the framework itself, if it exists? Did you read my (outdated) guide already? https://abbra.fedorapeople.org/freeipa-extensibility.html It is first link in the http://www.freeipa.org/page/Documentation#Additional_Resources_2 section Hi, thanks for the link. Though outdated, it covers most of what I needed. Is there some document describing the rules used in JSON serialization? Sometimes the api call result has interesting representation of the values. Don't know of any. But you can always call `ipa` command with -vvv and observe the communication. I do that. And take the format as a fact of life. :) -- 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] programmer documentation
On 07/30/2015 05:42 PM, Alexander Bokovoy wrote: On Thu, 30 Jul 2015, Milan Kubík wrote: Hi all, I'm curious, is there some documentation of the IPA internals? During my playing with plugins, I was quite amazed and frustrated at the code, not entirely (or remotely) understanding what happens after the call to a command starts and before I get the result. The main problem I have is that the command takes an argument. This argument gets automagically into LDAP, where it quite often is an attribute with a different name, and as the output of the command I get an object that has yet another name for the value I just sent to the command. Is there some (easy to understand) guide how this works, complete with the callback mechanism, etc? In general, where to search for $SUBJ and who to bug when it is missing or out of date? I know there is quite extensive tutorial to writing plugins in ipalib/__init__.py, but nowhere there are pre/post operation callbacks explained nor the format of the command output described (that I know of). Is there some guide that could even a newcomer use to get started? Can you point me to some documentation or designs for the framework itself, if it exists? Did you read my (outdated) guide already? https://abbra.fedorapeople.org/freeipa-extensibility.html It is first link in the http://www.freeipa.org/page/Documentation#Additional_Resources_2 section Hi, thanks for the link. Though outdated, it covers most of what I needed. Is there some document describing the rules used in JSON serialization? Sometimes the api call result has interesting representation of the values. 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
[Freeipa-devel] Changing CA replication agreements after raising domain level
Discussed with Ludwig, but it might be interesting to the rest of the
team(and mainly Simo)
In FreeIPA 4.3 - management of CA agmts by a replication plugin, there
is a scenario as follows:
- existing couple of replicas of version 4.2 and earlier (no topology
management)
- upgrade all to future 4.3
- raise domain level to 1
- optionally add a replica
All agmts are now managed by a topology plugin but there is an issue
with the old CA agreements because they were created with bind method:
simple. Atm. no code in IPA framework is executed after raising a domain
level. Therefore the old CA agreements are not converted to use GSSAPI.
If the segments related to the old agreements are removed and then
re-added, topology plugin creates agreements which use GSSAPI.
The old agreements are not converted automatically by a topology plugin
because simple auth is still required for ipa-replica-install (for both
realm and o=ipaca suffix).
Nor they can't be converted in IPA upgrade because domain level is
raised after the upgrade.
Question is who should convert the old amgts after raising a domain
level. IPA or topology plugin?
Some of possible solutions are:
1. Convert the CA agmts in domailevel-set method
2. Change replica installer to setup Kerberos earlier so that new
agreements could use GSSAPI and therefore topology plugin can convert
all managed agreements which don't use GSSAPI automatically.
3. Automatically convert all agmts by topo plugin. Introduce an attr in
repl agmnt which would be set during replica installation to tell the
topo plugin to not covert the agmnt while the attr is set. Then convert
in installer or when the attr is removed.
#1 is an easy workaround but it creates yet another sort of upgrade
path in domain level set.
#2 is more or less a replica promotion.
#3 another workaround
From long term perspective, I like #2 but I don't know what's the state
of replica promotion. Simo?
Attaching IPA patches which I use now (doesn't contain required topo
plugin patches).
--
Petr Vobornik
From 5a1f8ad3b8948d858729b8562e2c01eef161272e Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Wed, 15 Jul 2015 11:17:14 +0200
Subject: [PATCH 1/2] topology: manage ca replication agreements
Configure IPA so that topology plugin will manage also CA replication
agreements.
If domain level 0, ipa-replica-install:
- ipa replica install prepares DB for PKI
- setups replications agreements (o=ipaca) with simple bind method
- re-initializes the suffix
- calls pkispawn
- changes agreements to use GSSAPI
upgrades if CA is congigured:
- ipaca suffix is added to cn=topology,cn=ipa,cn=etc,$SUFFIX
- ipaReplTopoManagedSuffix: o=ipaca is added to master entry
- binddngroup is added to o=ipaca replica entry
---
freeipa.spec.in | 4 +-
install/share/Makefile.am | 1 +
install/share/ca-topology.uldif | 15 +
install/updates/20-replication.update | 5 ++
install/updates/90-post_upgrade_plugins.update | 1 +
ipaplatform/base/paths.py | 1 +
ipaserver/install/cainstance.py | 80 -
ipaserver/install/installutils.py | 1 +
ipaserver/install/krbinstance.py| 19 --
ipaserver/install/plugins/update_ca_topology.py | 34 +++
ipaserver/install/replication.py| 68 -
ipaserver/install/server/replicainstall.py | 4 +-
12 files changed, 195 insertions(+), 38 deletions(-)
create mode 100644 install/share/ca-topology.uldif
create mode 100644 ipaserver/install/plugins/update_ca_topology.py
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 328894c551acde88fbf789537fd9c9a5a39da816..b1da0a66ff51e5b9a1a3bbf3e1504e4fdbaacdd9 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -143,8 +143,8 @@ Requires(post): systemd-units
Requires: selinux-policy = %{selinux_policy_version}
Requires(post): selinux-policy-base
Requires: slapi-nis = 0.54.2-1
-Requires: pki-ca = 10.2.6
-Requires: pki-kra = 10.2.6
+Requires: pki-ca = 10.2.7
+Requires: pki-kra = 10.2.7
Requires(preun): python systemd-units
Requires(postun): python systemd-units
Requires: python-dns = 1.11.1
diff --git a/install/share/Makefile.am b/install/share/Makefile.am
index 80e959a751a0800c4d56c379a73b68a2f12570d7..156ee3f528a10a3615b0cc48a8fccad36e143da3 100644
--- a/install/share/Makefile.am
+++ b/install/share/Makefile.am
@@ -27,6 +27,7 @@ app_DATA =\
72domainlevels.ldif \
anonymous-vlv.ldif \
bootstrap-template.ldif \
+ ca-topology.uldif \
caJarSigningCert.cfg.template \
default-aci.ldif \
default-caacl.ldif \
diff --git a/install/share/ca-topology.uldif b/install/share/ca-topology.uldif
new file mode 100644
index ..3da9eaee1478ba0849a164fd2a150772c0151dd8
--- /dev/null
+++ b/install/share/ca-topology.uldif
@@ -0,0 +1,15 @@
+# add
[Freeipa-devel] [PATCHES] changes in preparation of replica promotion work
I've been carrying these patches in my tree for a while, I think it is
time to put them in master as they stand on their own.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
From 9f24666266a0d19547f6e1bda3b177d8c52431d6 Mon Sep 17 00:00:00 2001
From: Simo Sorce s...@redhat.com
Date: Wed, 1 Jul 2015 09:40:09 -0400
Subject: [PATCH] Remove custom utility function from krbinstance
Remove the custom update_key_val_in_file() and instead use the common
function config_replace_variables() available from ipautil.
---
ipaserver/install/krbinstance.py | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/ipaserver/install/krbinstance.py b/ipaserver/install/krbinstance.py
index 648fc76018f8342e787e74863e62dd85164af247..a0581565df6312a446cf0ba0c3a5a640f97e234d 100644
--- a/ipaserver/install/krbinstance.py
+++ b/ipaserver/install/krbinstance.py
@@ -49,26 +49,6 @@ from distutils import version
from ipaplatform.tasks import tasks
from ipaplatform.paths import paths
-def update_key_val_in_file(filename, key, val):
-if os.path.exists(filename):
-pattern = ^[\s#]*%s\s*=\s*%s\s* % (re.escape(key), re.escape(val))
-p = re.compile(pattern)
-for line in fileinput.input(filename):
-if p.search(line):
-fileinput.close()
-return
-fileinput.close()
-
-pattern = ^[\s#]*%s\s*= % re.escape(key)
-p = re.compile(pattern)
-for line in fileinput.input(filename, inplace=1):
-if not p.search(line):
-sys.stdout.write(line)
-fileinput.close()
-f = open(filename, a)
-f.write(%s=%s\n % (key, val))
-f.close()
-
class KpasswdInstance(service.SimpleServiceInstance):
def __init__(self):
service.SimpleServiceInstance.__init__(self, kadmin)
@@ -386,7 +366,9 @@ class KrbInstance(service.Service):
self.fstore.backup_file(paths.DS_KEYTAB)
installutils.create_keytab(paths.DS_KEYTAB, ldap_principal)
-update_key_val_in_file(paths.SYSCONFIG_DIRSRV, KRB5_KTNAME, paths.DS_KEYTAB)
+vardict = {KRB5_KTNAME: paths.DS_KEYTAB}
+ipautil.config_replace_variables(paths.SYSCONFIG_DIRSRV,
+ replacevars=vardict)
pent = pwd.getpwnam(dsinstance.DS_USER)
os.chown(paths.DS_KEYTAB, pent.pw_uid, pent.pw_gid)
--
2.4.2
From 1ae59d9d8a8ebf88135c58ba535516385dcda7b4 Mon Sep 17 00:00:00 2001
From: Simo Sorce s...@redhat.com
Date: Sun, 5 Jul 2015 07:18:25 -0400
Subject: [PATCH] Move sasl mappings creation to dsinstance
Sasl mappings can be created directly by the DS Instance, there is
no reason to create them in the krbinstance as they do not depend on
the kdc to be configured just to be created.
Signed-off-by: Simo Sorce s...@redhat.com
---
ipaserver/install/dsinstance.py | 51
ipaserver/install/krbinstance.py | 48 -
2 files changed, 51 insertions(+), 48 deletions(-)
diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py
index d561ca5b6d0d586cb1c27ec1c495413dad102e69..93ad60e36ab76c2e57829c5c4aa13c5c2766074f 100644
--- a/ipaserver/install/dsinstance.py
+++ b/ipaserver/install/dsinstance.py
@@ -353,6 +353,7 @@ class DsInstance(service.Service):
self.__common_setup(True)
self.step(setting up initial replication, self.__setup_replica)
+self.step(adding sasl mappings to the directory, self.__configure_sasl_mappings)
self.step(updating schema, self.__update_schema)
# See LDIFs for automember configuration during replica install
self.step(setting Auto Member configuration, self.__add_replica_automember_config)
@@ -377,6 +378,56 @@ class DsInstance(service.Service):
r_bindpw=self.dm_password)
self.run_init_memberof = repl.needs_memberof_fixup()
+
+def __configure_sasl_mappings(self):
+# we need to remove any existing SASL mappings in the directory as otherwise they
+# they may conflict.
+
+if not self.admin_conn:
+self.ldap_connect()
+
+try:
+res = self.admin_conn.get_entries(
+DN(('cn', 'mapping'), ('cn', 'sasl'), ('cn', 'config')),
+self.admin_conn.SCOPE_ONELEVEL,
+(objectclass=nsSaslMapping))
+for r in res:
+try:
+self.admin_conn.delete_entry(r)
+except Exception, e:
+root_logger.critical(
+Error during SASL mapping removal: %s, e)
+raise
+except Exception, e:
+root_logger.critical(Error while enumerating SASL mappings %s, e)
+raise
+
+entry = self.admin_conn.make_entry(
+DN(
+('cn', 'Full Principal'), ('cn', 'mapping'), ('cn', 'sasl'),
+('cn', 'config')),
