Re: [Freeipa-devel] FreeIPA 4.2 Alpha preparations
On 06/17/2015 05:44 PM, Martin Kosek wrote: On 06/17/2015 12:31 PM, Fraser Tweedale wrote: On Wed, Jun 17, 2015 at 07:55:10AM +0200, Martin Kosek wrote: On 06/16/2015 05:29 PM, Fraser Tweedale wrote: On Tue, Jun 16, 2015 at 05:10:00PM +0200, Martin Kosek wrote: On 06/12/2015 11:34 AM, Martin Kosek wrote: Hello all, As discussed in the last 2 weeks, we are getting close to the 4.2 finish line and releasing FreeIPA 4.2 Alpha 1. We already have most of the major RFEs complete, some still miss some partial functionality, but most are testable and in Alpha state already. We need to now find out what is blocking us from releasing the Alpha. I know only about 2 issues: - ipa-replica-manage del does not work well with the Topology plugin yet - Petr Vobornik and Ludwig are working on it - ipa-replica-prepare had some issues after upgrade from 4.1.x to 4.2.0 due to inaccesible certificate profiles - Jan, Martin2, Fraser was investigating Is that correct? Feature owners, please let me know if any of the major feature regressed and is not working properly, maybe by other patch sets being merged. When the blockers are resolved or documented, we should release the beast. Any volunteer for the release process? Finally, I put together a release note draft for the Alpha, please help me completing and updating it: http://www.freeipa.org/page/Releases/4.2.0.alpha1 Thanks everyone! I saw many fixes in Topology, that's good. I heard that pki-core 10.2.4 broke us, but I could not reproduce it today with fully updated F22 machine and I was able to install FreeIPA 4.2.git If this is the case, can we just release the Alpha? There are still some big brokens for upgrades. The fixes for pki are merged but there is no release yet. What is the ETA? It would be nice to have the fix for Alpha, the package can be built in the freeipa-4.2 COPR repo, together with the 4.2 Alpha release. If the ETA is too far, we may need to release Alpha regardless as there are some Test Days planned next week and upgrade is not required for such test days. Based on people educating me about how LDAP replication works: tomorrow, hopefully. In any case, I'm glad to know that the test days will not be affected by upgrade issues. Well, I will need some release in COPR for the test day. If clean install works, it is good for me. So if you do not have Dogtag release with upgrade issues fixed, I would just release Alpha as is, with this limitation. I do not expect people upgrading to Alpha from production releases before 4.2 anyway. I am only aware of one reported issue for new installations: ipa-replica-prepare failing when run on a replica (I haven't gotten to investigating this one yet). Right. This must be fixed before GA, but Alpha can live without it IMO. I investigated this regression today - details are in another thread, but it appears to be introduced by a different change and I have requested comment from those more familiar with that change. Thanks, Fraser I'm going to tag alpha_1-4-3-0 today at 15:00 CET. I'm not aware of any alpha blockers on FreeIPA side. Please contact me if there are patches which should make the release. This release will be available in mkosek/freeipa-4-2 COPR repository. When ready, the new dogtag should go into the COPR as well. What are the know issues which should be mentioned in release notes? http://www.freeipa.org/page/Releases/4.2.0.alpha1#Known_Issues -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0256] DNS: add UnknonwRecord attribute to schema
On 06/11/2015 04:55 PM, Petr Spacek wrote: On 22.5.2015 14:14, Martin Basti wrote: Patch attached. Initial part of https://fedorahosted.org/freeipa/ticket/4939 ACK Pushed to master: 3ababb763b93af4012705d59d2f55801d172835c -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands
On Thu, 2015-06-18 at 09:30 +0200, Jan Cholasta wrote: Dne 15.6.2015 v 17:29 thierry bordaz napsal(a): On 06/15/2015 05:00 PM, Simo Sorce wrote: On Mon, 2015-06-15 at 16:48 +0200, Petr Vobornik wrote: On 06/09/2015 02:02 PM, Jan Cholasta wrote: Dne 20.5.2015 v 11:26 Jan Cholasta napsal(a): Dne 18.5.2015 v 10:33 thierry bordaz napsal(a): On 05/15/2015 04:44 PM, David Kupka wrote: Hello Thierry, thanks for the patch set. Overall functionality of ULC feature looks good to me and is definitely alpha ready. I found following issues but don't insist on fixing it right now: 1) When stageuser-activate fails due to already existent active/deleted user. DN is show instead of user name that's used in other commands (user-add, stageuser-add). $ ipa user-add tuser --first Test --last User $ ipa stageuser-add tuser --first Test --last User $ ipa stageuser-activate tuser ipa: ERROR: Active user uid=tuser,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com already exists Hi David, Jan, Thanks you so much for all those tests and feedback. I agree, some minor bugs can be fixed separatly from this main patches. You are right, It should return the user ID not the DN. 2) According to the design there should be '--only-delete' and '--also-delete' options for user-find command instead there is '--preserved' option. Honza proposed adding virtual boolean attribute 'deleted' to user entry and filter on it. The 'deleted' attribute would be useful also in user-show where is no way to tell if the displayed user is active or deleted. (Except running with --all and looking on the dn). Yes a bit late to resynch the design. The final option is 'preserved' for user-find and 'preserve' for user-del. '--only-delete' or 'also-delete' are old name that I need to replace in the design. About the 'deleted' attribute, do you think adding a DS cos virtual attribute ? See the attached patch. Can someone please review the patch? 3) uidNumber and gidNumber can't be set back to '-1' once set to other value. This would be useful when admin changes its mind and want IPA to assign them. IIUC, there should be no validation in cn=staged user container. All validation should be done during stageuser-activate. Yes that comes from user plugin that enforce the number to be 0. That is a good point giving the ability to reset uidNumber/gidNumber. I will check if it is possible, how (give a value or an option to reset), and also if it would not create other issue. 4) Support for deleted - stage workflow is still missing. But I'm unsure if we agreed to finish it now or later. Yes thanks 5) Twice deleting user with '--preserve' deletes him permanently. $ ipa user-add tuser --first Test --last User $ ipa user-del tuser --preserve $ ipa user-del tuser --preserve $ ipa user-find --preserved 0 (delete) users matched Number of entries returned 0 Deleting a deleted (preserved) entry, should permanently remove the entry. +1, but no-op if default behavior is preserve Now if the second time the preserve option is present, it makes sense to not delete it. +1, should be no-op BTW: I might be stating the obvious here, but it would be better to use one boolean parameter rather than two mutually exclusive flags in user-del. I would like an opinion on this as well. So the proposal is, e.g.,: Replace: ipa user del fbar --preserve ipa user del fbar --permanently with: ipa user del fbar --permanently=False ipa user del fbar --permanently=True and ipa user del fbar uses the default behavior(permanently atm.) I don't think there is a big difference. A boolean is easier for scripting. 2 options are more descriptive for humans. With a single boolean, I would be afraid that omitting it would imply False to some users which is not always the same as the default behavior [1]. With Web UI developer hat I would vote for single boolean but as a CLI user I would like the current options. Given that Web UI or any other API client should not define CLI, I would keep the current options. my 2c [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Delete_User -- Petr Vobornik +1 --preserve is 100x better for a human than --permanently=False I also prefere --preserve for usability of 'user del'. In addition we have 'user find|show --preserved' to retrieve users that have been preserved. So it seems to me better that the action that preserved the user uses the option '--preserve' rather '--permanently=False'. It's ridiculous that the CLI taints the RPC API and it should be fixed. Also on a more nitpicky side, I think the flag should be called --no-preserve
Re: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands
Dne 18.6.2015 v 13:22 Petr Vobornik napsal(a): On 06/18/2015 12:52 PM, Jan Cholasta wrote: Dne 18.6.2015 v 09:30 Jan Cholasta napsal(a): Dne 15.6.2015 v 17:29 thierry bordaz napsal(a): On 06/15/2015 05:00 PM, Simo Sorce wrote: On Mon, 2015-06-15 at 16:48 +0200, Petr Vobornik wrote: On 06/09/2015 02:02 PM, Jan Cholasta wrote: Dne 20.5.2015 v 11:26 Jan Cholasta napsal(a): Dne 18.5.2015 v 10:33 thierry bordaz napsal(a): On 05/15/2015 04:44 PM, David Kupka wrote: Hello Thierry, thanks for the patch set. Overall functionality of ULC feature looks good to me and is definitely alpha ready. I found following issues but don't insist on fixing it right now: 1) When stageuser-activate fails due to already existent active/deleted user. DN is show instead of user name that's used in other commands (user-add, stageuser-add). $ ipa user-add tuser --first Test --last User $ ipa stageuser-add tuser --first Test --last User $ ipa stageuser-activate tuser ipa: ERROR: Active user uid=tuser,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com already exists Hi David, Jan, Thanks you so much for all those tests and feedback. I agree, some minor bugs can be fixed separatly from this main patches. You are right, It should return the user ID not the DN. 2) According to the design there should be '--only-delete' and '--also-delete' options for user-find command instead there is '--preserved' option. Honza proposed adding virtual boolean attribute 'deleted' to user entry and filter on it. The 'deleted' attribute would be useful also in user-show where is no way to tell if the displayed user is active or deleted. (Except running with --all and looking on the dn). Yes a bit late to resynch the design. The final option is 'preserved' for user-find and 'preserve' for user-del. '--only-delete' or 'also-delete' are old name that I need to replace in the design. About the 'deleted' attribute, do you think adding a DS cos virtual attribute ? See the attached patch. Can someone please review the patch? 3) uidNumber and gidNumber can't be set back to '-1' once set to other value. This would be useful when admin changes its mind and want IPA to assign them. IIUC, there should be no validation in cn=staged user container. All validation should be done during stageuser-activate. Yes that comes from user plugin that enforce the number to be 0. That is a good point giving the ability to reset uidNumber/gidNumber. I will check if it is possible, how (give a value or an option to reset), and also if it would not create other issue. 4) Support for deleted - stage workflow is still missing. But I'm unsure if we agreed to finish it now or later. Yes thanks 5) Twice deleting user with '--preserve' deletes him permanently. $ ipa user-add tuser --first Test --last User $ ipa user-del tuser --preserve $ ipa user-del tuser --preserve $ ipa user-find --preserved 0 (delete) users matched Number of entries returned 0 Deleting a deleted (preserved) entry, should permanently remove the entry. +1, but no-op if default behavior is preserve Now if the second time the preserve option is present, it makes sense to not delete it. +1, should be no-op BTW: I might be stating the obvious here, but it would be better to use one boolean parameter rather than two mutually exclusive flags in user-del. I would like an opinion on this as well. So the proposal is, e.g.,: Replace: ipa user del fbar --preserve ipa user del fbar --permanently with: ipa user del fbar --permanently=False ipa user del fbar --permanently=True and ipa user del fbar uses the default behavior(permanently atm.) I don't think there is a big difference. A boolean is easier for scripting. 2 options are more descriptive for humans. With a single boolean, I would be afraid that omitting it would imply False to some users which is not always the same as the default behavior [1]. With Web UI developer hat I would vote for single boolean but as a CLI user I would like the current options. Given that Web UI or any other API client should not define CLI, I would keep the current options. my 2c [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Delete_User -- Petr Vobornik +1 --preserve is 100x better for a human than --permanently=False I also prefere --preserve for usability of 'user del'. In addition we have 'user find|show --preserved' to retrieve users that have been preserved. So it seems to me better that the action that preserved the user uses the option '--preserve' rather '--permanently=False'. It's ridiculous that the CLI taints the RPC API and it should be fixed. Also on a more nitpicky side, I think the flag should be called --no-preserve rather than --permanently. There is plenty of commands (rm, cp, ...) which have --no-preserve as opposite of --preserve. The attached patch fixes
[Freeipa-devel] [PATCH 0035] Bump run-time requires to SoftHSM 2.0.0rc1
Hello,
Another easytest! :-)
Bump run-time requires to SoftHSM 2.0.0rc1.
This is necessary to make DNSSEC support functional.
Unfortunately my previous patch updated BuildRequires but I forgot to bump the
same in Requires. Please get push it into alpha if possible.
Thanks!
--
Petr^2 Spacek
From a9544386ccdb6c3c84a0982f3e5a574415b8adae Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Thu, 18 Jun 2015 13:47:12 +0200
Subject: [PATCH] Bump run-time requires to SoftHSM 2.0.0rc1.
---
freeipa.spec.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 8324bd21b3fa7be56cc2f0121269e6902c6ae307..809ac1e5bb877c85e29c082ecfb9ad91aa97b4f5 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -148,7 +148,7 @@ Requires(pre): 389-ds-base = 1.3.4.a1
Requires: fontawesome-fonts
Requires: open-sans-fonts
Requires: openssl
-Requires: softhsm = 2.0.0b1-3
+Requires: softhsm = 2.0.0rc1-1
Requires: p11-kit
Requires: systemd-python
Requires: %{etc_systemd_dir}
--
2.1.0
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] with new cert profiles patches ipa-replica-prepare fails after update
Dne 17.6.2015 v 12:26 Fraser Tweedale napsal(a):
On Fri, Jun 12, 2015 at 03:47:38PM +0200, Petr Vobornik wrote:
On 06/12/2015 03:18 PM, Fraser Tweedale wrote:
On Thu, Jun 11, 2015 at 09:59:03AM +0200, Martin Babinsky wrote:
On 06/04/2015 04:03 PM, Petr Vobornik wrote:
- ipa-replica-prepare works
- old IPA server was upgraded to today's master (with Cert profiles
patches)
- ipa-replica-prepare fails with:
Log:
ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server
ipa: DEBUG: cert valid True for CN=repl.example.com,O=EXAMPLE.COM
ipa: DEBUG: handshake complete, peer = [beef::cafe]:8443
ipa: DEBUG: Protocol: TLS1.2
ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_128_GCM_SHA256
ipa: DEBUG: request status 200
ipa: DEBUG: request reason_phrase u'OK'
ipa: DEBUG: request headers {'date': 'Thu, 04 Jun 2015 13:54:09 GMT',
'content-length': '148', 'content-type': 'application/xml', 'server':
'Apache-Coyote/1.1'}
ipa: DEBUG: request body '?xml version=1.0 encoding=UTF-8
standalone=no?XMLResponseStatus1/StatusErrorProfile
caIPAserviceCert Not Found/Error/XMLResponse'
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File
/usr/lib/python2.7/site-packages/ipapython/admintool.py, line 171, in
execute
return_value = self.run()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py,
line 338, in run
self.copy_ds_certificate()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py,
line 383, in copy_ds_certificate
self.export_certdb(dscert, passwd_fname)
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py,
line 595, in export_certdb
db.create_server_cert(nickname, hostname, ca_db)
File /usr/lib/python2.7/site-packages/ipaserver/install/certs.py,
line 337, in create_server_cert
cdb.issue_server_cert(self.certreq_fname, self.certder_fname)
File /usr/lib/python2.7/site-packages/ipaserver/install/certs.py,
line 419, in issue_server_cert
raise RuntimeError(Certificate issuance failed)
Bump, I have also came across this issue (see log:
http://pastebin.test.redhat.com/289434).
--
Martin^3 Babinsky
It was reported to me that the issue was reproducible after upgrade
from 4.1.4 to master, but I was not able to reproduce. Can anyone
who has encountered it please:
- state fedora version(s) affected and precise build of Dogtag
- provide ipaupgrade.log and /var/log/pki/pki-tomcat/ca/debug
Thanks,
Fraser
I see similar issue when creating a replica file from second
replica/master, all git master. I.e. the prepare on first server obviously
works.
The error is different though:
ipa: DEBUG: request status 200
ipa: DEBUG: request reason_phrase u'OK'
ipa: DEBUG: request headers {'date': 'Fri, 12 Jun 2015 13:46:32 GMT',
'content-length': '133', 'content-type': 'application/xml', 'server':
'Apache-Coyote/1.1'}
ipa: DEBUG: request body '?xml version=1.0 encoding=UTF-8
standalone=no?XMLResponseStatus1/StatusErrorInvalid
Credential./Error/XMLResponse'
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File
/usr/lib/python2.7/site-packages/ipapython/admintool.py, line 171, in
execute
return_value = self.run()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py,
line 338, in run
self.copy_ds_certificate()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py,
line 383, in copy_ds_certificate
self.export_certdb(dscert, passwd_fname)
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py,
line 595, in export_certdb
db.create_server_cert(nickname, hostname, ca_db)
File /usr/lib/python2.7/site-packages/ipaserver/install/certs.py, line
337, in create_server_cert
cdb.issue_server_cert(self.certreq_fname, self.certder_fname)
File /usr/lib/python2.7/site-packages/ipaserver/install/certs.py, line
419, in issue_server_cert
raise RuntimeError(Certificate issuance failed)
--
Petr Vobornik
I spent some time debugging tihs issue today. It appears to be
introduced by commit:
commit 2acedb2d5d4a4c0987c670e14eb04b8bd9ffc034
Author: David Kupka dku...@redhat.com
Date: Mon Jun 8 05:23:56 2015 +
Move CA installation code into single module.
https://fedorahosted.org/freeipa/ticket/4468
Reviewed-By: Jan Cholasta jchol...@redhat.com
During the execution of ipa-replica-prepare, the RA cert (nickname
ipaCert) gets added to the /etc/httpd/alias/ NSSDB, but then
removed somehow while executing http.create_instance(). I have not
yet precisely identified the cause enough to fix it. Hopefully
David or Honza can some light.
Fixed.
--
Jan Cholasta
From dca319d651c578a3c7c763a32160aaa70e16efd2 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Thu, 18 Jun 2015 10:35:09 +
Subject: [PATCH] install: Fix ipa-replica-install not installing RA cert
https://fedorahosted.org/freeipa/ticket/4468
---
[Freeipa-devel] [PATCH 0032-0034] Clarify DNS error messages in ipa-replica-prepare
Easytest! :-)
--
Petr^2 Spacek
From 8c9af1e8e15f0b0a37c554bbbfab176b9558f943 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Thu, 18 Jun 2015 12:56:09 +0200
Subject: [PATCH] Improve error messages about reverse address resolution in
ipa-replica-prepare
---
ipaserver/install/installutils.py | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/ipaserver/install/installutils.py b/ipaserver/install/installutils.py
index 5fb2bb29fa123d137e3605709690024d62767ad2..42df2b7119c0e74a2b85b1a6f835f9d2c707b6f4 100644
--- a/ipaserver/install/installutils.py
+++ b/ipaserver/install/installutils.py
@@ -195,12 +195,18 @@ def verify_fqdn(host_name, no_host_dns=False, local_hostname=True):
revname = socket.gethostbyaddr(address)[0]
except Exception, e:
root_logger.debug('Check failed: %s', e)
-raise HostReverseLookupError(Unable to resolve the reverse ip address, check /etc/hosts or DNS name resolution)
+raise HostReverseLookupError(
+Unable to resolve the IP address %s to a host name,
+check /etc/hosts and DNS name resolution % address)
root_logger.debug('Found reverse name: %s', revname)
if revname != host_name:
-raise HostReverseLookupError(The host name %s does not match the reverse lookup %s % (host_name, revname))
+raise HostReverseLookupError(
+The host name %s does not match the value %s obtained
+by reverse lookup on IP address %s
+% (host_name, revname, address))
verified.add(address)
+
def record_in_hosts(ip, host_name=None, conf_file=paths.HOSTS):
Search record in /etc/hosts - static table lookup for hostnames
--
2.1.0
From 6bf72e93854d85a90b26e520db896a67eb60b5f7 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Thu, 18 Jun 2015 13:07:06 +0200
Subject: [PATCH] Clarify recommendation about --ip-address option in
ipa-replica-prepapre
---
ipaserver/install/ipa_replica_prepare.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/ipaserver/install/ipa_replica_prepare.py b/ipaserver/install/ipa_replica_prepare.py
index da492a96be3b618e78a3294ae924ed212ea448f5..2e81839e2b5702f2e5cf7f12d635f28272a28bf9 100644
--- a/ipaserver/install/ipa_replica_prepare.py
+++ b/ipaserver/install/ipa_replica_prepare.py
@@ -231,8 +231,9 @@ class ReplicaPrepare(admintool.AdminTool):
api.env.host, api.env.basedn,
dm_password=self.dirman_password,
ldapi=True, realm=api.env.realm):
-self.log.info('Add the --ip-address argument to '
-'create a DNS entry.')
+self.log.info('You might use the --ip-address option '
+ 'to create a DNS entry if the DNS zone '
+ 'is managed by IPA.')
raise
else:
# The host doesn't exist in DNS but we're adding it.
--
2.1.0
From d6b8ce7a8026e500f9204d5372ceae2ebbb0d1e1 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Thu, 18 Jun 2015 13:13:45 +0200
Subject: [PATCH] Clarify error messages in ipa-replica-prepare:
add_dns_records()
---
ipaserver/install/ipa_replica_prepare.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ipaserver/install/ipa_replica_prepare.py b/ipaserver/install/ipa_replica_prepare.py
index 2e81839e2b5702f2e5cf7f12d635f28272a28bf9..3a2975bf66f593d9f0429b78d046f0021295006b 100644
--- a/ipaserver/install/ipa_replica_prepare.py
+++ b/ipaserver/install/ipa_replica_prepare.py
@@ -482,7 +482,7 @@ class ReplicaPrepare(admintool.AdminTool):
add_zone(domain)
except errors.PublicError, e:
raise admintool.ScriptError(
-Could not create forward DNS zone for the replica: %s % e)
+Could not create master DNS zone for the replica: %s % e)
for reverse_zone in options.reverse_zones:
self.log.info(Adding reverse zone %s, reverse_zone)
@@ -494,15 +494,15 @@ class ReplicaPrepare(admintool.AdminTool):
add_fwd_rr(domain, name, ip_address)
except errors.PublicError, e:
raise admintool.ScriptError(
-Could not add forward DNS record for the replica: %s % e)
+Could not add A/ DNS record for the replica: %s % e)
if not options.no_reverse:
reverse_zone = bindinstance.find_reverse_zone(ip)
try:
add_ptr_rr(reverse_zone, ip_address, self.replica_fqdn)
except errors.PublicError, e:
raise admintool.ScriptError(
-Could not add reverse DNS record for the replica: %s
+
Re: [Freeipa-devel] FreeIPA 4.2 Alpha preparations
Hi, I think you did not yet (want) to push patch0014 about one directional segments. In that case we should add something that the addition of one directional segments id not recommended (failure in some cases to chheck duplicates or removing agreements when deleting a merged segment). Ludwig On 06/18/2015 02:05 PM, Petr Vobornik wrote: On 06/17/2015 05:44 PM, Martin Kosek wrote: On 06/17/2015 12:31 PM, Fraser Tweedale wrote: On Wed, Jun 17, 2015 at 07:55:10AM +0200, Martin Kosek wrote: On 06/16/2015 05:29 PM, Fraser Tweedale wrote: On Tue, Jun 16, 2015 at 05:10:00PM +0200, Martin Kosek wrote: On 06/12/2015 11:34 AM, Martin Kosek wrote: Hello all, As discussed in the last 2 weeks, we are getting close to the 4.2 finish line and releasing FreeIPA 4.2 Alpha 1. We already have most of the major RFEs complete, some still miss some partial functionality, but most are testable and in Alpha state already. We need to now find out what is blocking us from releasing the Alpha. I know only about 2 issues: - ipa-replica-manage del does not work well with the Topology plugin yet - Petr Vobornik and Ludwig are working on it - ipa-replica-prepare had some issues after upgrade from 4.1.x to 4.2.0 due to inaccesible certificate profiles - Jan, Martin2, Fraser was investigating Is that correct? Feature owners, please let me know if any of the major feature regressed and is not working properly, maybe by other patch sets being merged. When the blockers are resolved or documented, we should release the beast. Any volunteer for the release process? Finally, I put together a release note draft for the Alpha, please help me completing and updating it: http://www.freeipa.org/page/Releases/4.2.0.alpha1 Thanks everyone! I saw many fixes in Topology, that's good. I heard that pki-core 10.2.4 broke us, but I could not reproduce it today with fully updated F22 machine and I was able to install FreeIPA 4.2.git If this is the case, can we just release the Alpha? There are still some big brokens for upgrades. The fixes for pki are merged but there is no release yet. What is the ETA? It would be nice to have the fix for Alpha, the package can be built in the freeipa-4.2 COPR repo, together with the 4.2 Alpha release. If the ETA is too far, we may need to release Alpha regardless as there are some Test Days planned next week and upgrade is not required for such test days. Based on people educating me about how LDAP replication works: tomorrow, hopefully. In any case, I'm glad to know that the test days will not be affected by upgrade issues. Well, I will need some release in COPR for the test day. If clean install works, it is good for me. So if you do not have Dogtag release with upgrade issues fixed, I would just release Alpha as is, with this limitation. I do not expect people upgrading to Alpha from production releases before 4.2 anyway. I am only aware of one reported issue for new installations: ipa-replica-prepare failing when run on a replica (I haven't gotten to investigating this one yet). Right. This must be fixed before GA, but Alpha can live without it IMO. I investigated this regression today - details are in another thread, but it appears to be introduced by a different change and I have requested comment from those more familiar with that change. Thanks, Fraser I'm going to tag alpha_1-4-3-0 today at 15:00 CET. I'm not aware of any alpha blockers on FreeIPA side. Please contact me if there are patches which should make the release. This release will be available in mkosek/freeipa-4-2 COPR repository. When ready, the new dogtag should go into the COPR as well. What are the know issues which should be mentioned in release notes? http://www.freeipa.org/page/Releases/4.2.0.alpha1#Known_Issues -- 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 0032-0034] Clarify DNS error messages in ipa-replica-prepare
On 18/06/15 13:36, Petr Spacek wrote: Easytest! :-) ACK -- 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 0041] add DS index for userCertificate attribute
On 16/06/15 18:03, Martin Babinsky wrote: Related to http://www.freeipa.org/page/V4/User_Certificates and https://fedorahosted.org/freeipa/ticket/4238 ACK -- 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 0266] ipa-ca-install fix: reconnect ldap2 after DS restart
On 06/17/2015 02:28 PM, Martin Basti wrote: https://fedorahosted.org/freeipa/ticket/5064 Patch attached. ACK -- Martin^3 Babinsky -- 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] 0005 User life cycle: del/mod/find/show stageuser commands
On 06/18/2015 12:52 PM, Jan Cholasta wrote: Dne 18.6.2015 v 09:30 Jan Cholasta napsal(a): Dne 15.6.2015 v 17:29 thierry bordaz napsal(a): On 06/15/2015 05:00 PM, Simo Sorce wrote: On Mon, 2015-06-15 at 16:48 +0200, Petr Vobornik wrote: On 06/09/2015 02:02 PM, Jan Cholasta wrote: Dne 20.5.2015 v 11:26 Jan Cholasta napsal(a): Dne 18.5.2015 v 10:33 thierry bordaz napsal(a): On 05/15/2015 04:44 PM, David Kupka wrote: Hello Thierry, thanks for the patch set. Overall functionality of ULC feature looks good to me and is definitely alpha ready. I found following issues but don't insist on fixing it right now: 1) When stageuser-activate fails due to already existent active/deleted user. DN is show instead of user name that's used in other commands (user-add, stageuser-add). $ ipa user-add tuser --first Test --last User $ ipa stageuser-add tuser --first Test --last User $ ipa stageuser-activate tuser ipa: ERROR: Active user uid=tuser,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com already exists Hi David, Jan, Thanks you so much for all those tests and feedback. I agree, some minor bugs can be fixed separatly from this main patches. You are right, It should return the user ID not the DN. 2) According to the design there should be '--only-delete' and '--also-delete' options for user-find command instead there is '--preserved' option. Honza proposed adding virtual boolean attribute 'deleted' to user entry and filter on it. The 'deleted' attribute would be useful also in user-show where is no way to tell if the displayed user is active or deleted. (Except running with --all and looking on the dn). Yes a bit late to resynch the design. The final option is 'preserved' for user-find and 'preserve' for user-del. '--only-delete' or 'also-delete' are old name that I need to replace in the design. About the 'deleted' attribute, do you think adding a DS cos virtual attribute ? See the attached patch. Can someone please review the patch? 3) uidNumber and gidNumber can't be set back to '-1' once set to other value. This would be useful when admin changes its mind and want IPA to assign them. IIUC, there should be no validation in cn=staged user container. All validation should be done during stageuser-activate. Yes that comes from user plugin that enforce the number to be 0. That is a good point giving the ability to reset uidNumber/gidNumber. I will check if it is possible, how (give a value or an option to reset), and also if it would not create other issue. 4) Support for deleted - stage workflow is still missing. But I'm unsure if we agreed to finish it now or later. Yes thanks 5) Twice deleting user with '--preserve' deletes him permanently. $ ipa user-add tuser --first Test --last User $ ipa user-del tuser --preserve $ ipa user-del tuser --preserve $ ipa user-find --preserved 0 (delete) users matched Number of entries returned 0 Deleting a deleted (preserved) entry, should permanently remove the entry. +1, but no-op if default behavior is preserve Now if the second time the preserve option is present, it makes sense to not delete it. +1, should be no-op BTW: I might be stating the obvious here, but it would be better to use one boolean parameter rather than two mutually exclusive flags in user-del. I would like an opinion on this as well. So the proposal is, e.g.,: Replace: ipa user del fbar --preserve ipa user del fbar --permanently with: ipa user del fbar --permanently=False ipa user del fbar --permanently=True and ipa user del fbar uses the default behavior(permanently atm.) I don't think there is a big difference. A boolean is easier for scripting. 2 options are more descriptive for humans. With a single boolean, I would be afraid that omitting it would imply False to some users which is not always the same as the default behavior [1]. With Web UI developer hat I would vote for single boolean but as a CLI user I would like the current options. Given that Web UI or any other API client should not define CLI, I would keep the current options. my 2c [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Delete_User -- Petr Vobornik +1 --preserve is 100x better for a human than --permanently=False I also prefere --preserve for usability of 'user del'. In addition we have 'user find|show --preserved' to retrieve users that have been preserved. So it seems to me better that the action that preserved the user uses the option '--preserve' rather '--permanently=False'. It's ridiculous that the CLI taints the RPC API and it should be fixed. Also on a more nitpicky side, I think the flag should be called --no-preserve rather than --permanently. There is plenty of commands (rm, cp, ...) which have --no-preserve as opposite of --preserve. The attached patch fixes both. ... and it also accidentaly changes the
Re: [Freeipa-devel] with new cert profiles patches ipa-replica-prepare fails after update
On 06/18/2015 02:43 PM, David Kupka wrote:
Dne 18.6.2015 v 13:18 Jan Cholasta napsal(a):
Dne 17.6.2015 v 12:26 Fraser Tweedale napsal(a):
On Fri, Jun 12, 2015 at 03:47:38PM +0200, Petr Vobornik wrote:
On 06/12/2015 03:18 PM, Fraser Tweedale wrote:
On Thu, Jun 11, 2015 at 09:59:03AM +0200, Martin Babinsky wrote:
On 06/04/2015 04:03 PM, Petr Vobornik wrote:
- ipa-replica-prepare works
- old IPA server was upgraded to today's master (with Cert profiles
patches)
- ipa-replica-prepare fails with:
Log:
ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server
ipa: DEBUG: cert valid True for CN=repl.example.com,O=EXAMPLE.COM
ipa: DEBUG: handshake complete, peer = [beef::cafe]:8443
ipa: DEBUG: Protocol: TLS1.2
ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_128_GCM_SHA256
ipa: DEBUG: request status 200
ipa: DEBUG: request reason_phrase u'OK'
ipa: DEBUG: request headers {'date': 'Thu, 04 Jun 2015 13:54:09
GMT',
'content-length': '148', 'content-type': 'application/xml',
'server':
'Apache-Coyote/1.1'}
ipa: DEBUG: request body '?xml version=1.0 encoding=UTF-8
standalone=no?XMLResponseStatus1/StatusErrorProfile
caIPAserviceCert Not Found/Error/XMLResponse'
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG:
File
/usr/lib/python2.7/site-packages/ipapython/admintool.py, line
171, in
execute
return_value = self.run()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py,
line 338, in run
self.copy_ds_certificate()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py,
line 383, in copy_ds_certificate
self.export_certdb(dscert, passwd_fname)
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py,
line 595, in export_certdb
db.create_server_cert(nickname, hostname, ca_db)
File
/usr/lib/python2.7/site-packages/ipaserver/install/certs.py,
line 337, in create_server_cert
cdb.issue_server_cert(self.certreq_fname, self.certder_fname)
File
/usr/lib/python2.7/site-packages/ipaserver/install/certs.py,
line 419, in issue_server_cert
raise RuntimeError(Certificate issuance failed)
Bump, I have also came across this issue (see log:
http://pastebin.test.redhat.com/289434).
--
Martin^3 Babinsky
It was reported to me that the issue was reproducible after upgrade
from 4.1.4 to master, but I was not able to reproduce. Can anyone
who has encountered it please:
- state fedora version(s) affected and precise build of Dogtag
- provide ipaupgrade.log and /var/log/pki/pki-tomcat/ca/debug
Thanks,
Fraser
I see similar issue when creating a replica file from second
replica/master, all git master. I.e. the prepare on first server
obviously
works.
The error is different though:
ipa: DEBUG: request status 200
ipa: DEBUG: request reason_phrase u'OK'
ipa: DEBUG: request headers {'date': 'Fri, 12 Jun 2015 13:46:32 GMT',
'content-length': '133', 'content-type': 'application/xml', 'server':
'Apache-Coyote/1.1'}
ipa: DEBUG: request body '?xml version=1.0 encoding=UTF-8
standalone=no?XMLResponseStatus1/StatusErrorInvalid
Credential./Error/XMLResponse'
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File
/usr/lib/python2.7/site-packages/ipapython/admintool.py, line 171, in
execute
return_value = self.run()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py,
line 338, in run
self.copy_ds_certificate()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py,
line 383, in copy_ds_certificate
self.export_certdb(dscert, passwd_fname)
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py,
line 595, in export_certdb
db.create_server_cert(nickname, hostname, ca_db)
File
/usr/lib/python2.7/site-packages/ipaserver/install/certs.py, line
337, in create_server_cert
cdb.issue_server_cert(self.certreq_fname, self.certder_fname)
File
/usr/lib/python2.7/site-packages/ipaserver/install/certs.py, line
419, in issue_server_cert
raise RuntimeError(Certificate issuance failed)
--
Petr Vobornik
I spent some time debugging tihs issue today. It appears to be
introduced by commit:
commit 2acedb2d5d4a4c0987c670e14eb04b8bd9ffc034
Author: David Kupka dku...@redhat.com
Date: Mon Jun 8 05:23:56 2015 +
Move CA installation code into single module.
https://fedorahosted.org/freeipa/ticket/4468
Reviewed-By: Jan Cholasta jchol...@redhat.com
During the execution of ipa-replica-prepare, the RA cert (nickname
ipaCert) gets added to the /etc/httpd/alias/ NSSDB, but then
removed somehow while executing http.create_instance(). I have not
yet precisely identified the cause enough to fix it. Hopefully
David or Honza can some light.
Fixed.
Works for me, ACK.
Pushed to master: c3a3d789b5da353a6abf2722932df4f5fc05dbe5
--
Petr Vobornik
--
Manage your subscription for the Freeipa-devel mailing list:
Re: [Freeipa-devel] [PATCH 0032-0034] Clarify DNS error messages in ipa-replica-prepare
On 06/18/2015 02:50 PM, Martin Basti wrote: On 18/06/15 13:36, Petr Spacek wrote: Easytest! :-) ACK pushed to master: * 3c95a5aea23b6deb9d9b91799d9fd29ab25a6d78 Improve error messages about reverse address resolution in ipa-replica-prepare * 6259be5fd6010d7e77101769e3421e6f3a141b0b Clarify recommendation about --ip-address option in ipa-replica-prepapre * b5b8dd6cec4ddfd6cff91aba503963d2a4095bed Clarify error messages in ipa-replica-prepare: add_dns_records() -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0035] Bump run-time requires to SoftHSM 2.0.0rc1
On 06/18/2015 01:49 PM, Petr Spacek wrote: Hello, Another easytest! :-) Bump run-time requires to SoftHSM 2.0.0rc1. This is necessary to make DNSSEC support functional. Unfortunately my previous patch updated BuildRequires but I forgot to bump the same in Requires. Please get push it into alpha if possible. Thanks! ACK Pushed to master: e29f85344ced845f3d1999773fa2437de9b028af -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0041] add DS index for userCertificate attribute
On 06/18/2015 02:59 PM, Martin Basti wrote: On 16/06/15 18:03, Martin Babinsky wrote: Related to http://www.freeipa.org/page/V4/User_Certificates and https://fedorahosted.org/freeipa/ticket/4238 ACK Pushed to master: 3bea4418089dc97136040cfc58157a77aea8b0aa -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands
On 06/18/2015 01:22 PM, Petr Vobornik wrote: On 06/18/2015 12:52 PM, Jan Cholasta wrote: Dne 18.6.2015 v 09:30 Jan Cholasta napsal(a): Dne 15.6.2015 v 17:29 thierry bordaz napsal(a): On 06/15/2015 05:00 PM, Simo Sorce wrote: On Mon, 2015-06-15 at 16:48 +0200, Petr Vobornik wrote: On 06/09/2015 02:02 PM, Jan Cholasta wrote: Dne 20.5.2015 v 11:26 Jan Cholasta napsal(a): Dne 18.5.2015 v 10:33 thierry bordaz napsal(a): On 05/15/2015 04:44 PM, David Kupka wrote: Hello Thierry, thanks for the patch set. Overall functionality of ULC feature looks good to me and is definitely alpha ready. I found following issues but don't insist on fixing it right now: 1) When stageuser-activate fails due to already existent active/deleted user. DN is show instead of user name that's used in other commands (user-add, stageuser-add). $ ipa user-add tuser --first Test --last User $ ipa stageuser-add tuser --first Test --last User $ ipa stageuser-activate tuser ipa: ERROR: Active user uid=tuser,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com already exists Hi David, Jan, Thanks you so much for all those tests and feedback. I agree, some minor bugs can be fixed separatly from this main patches. You are right, It should return the user ID not the DN. 2) According to the design there should be '--only-delete' and '--also-delete' options for user-find command instead there is '--preserved' option. Honza proposed adding virtual boolean attribute 'deleted' to user entry and filter on it. The 'deleted' attribute would be useful also in user-show where is no way to tell if the displayed user is active or deleted. (Except running with --all and looking on the dn). Yes a bit late to resynch the design. The final option is 'preserved' for user-find and 'preserve' for user-del. '--only-delete' or 'also-delete' are old name that I need to replace in the design. About the 'deleted' attribute, do you think adding a DS cos virtual attribute ? See the attached patch. Can someone please review the patch? 3) uidNumber and gidNumber can't be set back to '-1' once set to other value. This would be useful when admin changes its mind and want IPA to assign them. IIUC, there should be no validation in cn=staged user container. All validation should be done during stageuser-activate. Yes that comes from user plugin that enforce the number to be 0. That is a good point giving the ability to reset uidNumber/gidNumber. I will check if it is possible, how (give a value or an option to reset), and also if it would not create other issue. 4) Support for deleted - stage workflow is still missing. But I'm unsure if we agreed to finish it now or later. Yes thanks 5) Twice deleting user with '--preserve' deletes him permanently. $ ipa user-add tuser --first Test --last User $ ipa user-del tuser --preserve $ ipa user-del tuser --preserve $ ipa user-find --preserved 0 (delete) users matched Number of entries returned 0 Deleting a deleted (preserved) entry, should permanently remove the entry. +1, but no-op if default behavior is preserve Now if the second time the preserve option is present, it makes sense to not delete it. +1, should be no-op BTW: I might be stating the obvious here, but it would be better to use one boolean parameter rather than two mutually exclusive flags in user-del. I would like an opinion on this as well. So the proposal is, e.g.,: Replace: ipa user del fbar --preserve ipa user del fbar --permanently with: ipa user del fbar --permanently=False ipa user del fbar --permanently=True and ipa user del fbar uses the default behavior(permanently atm.) I don't think there is a big difference. A boolean is easier for scripting. 2 options are more descriptive for humans. With a single boolean, I would be afraid that omitting it would imply False to some users which is not always the same as the default behavior [1]. With Web UI developer hat I would vote for single boolean but as a CLI user I would like the current options. Given that Web UI or any other API client should not define CLI, I would keep the current options. my 2c [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Delete_User -- Petr Vobornik +1 --preserve is 100x better for a human than --permanently=False I also prefere --preserve for usability of 'user del'. In addition we have 'user find|show --preserved' to retrieve users that have been preserved. So it seems to me better that the action that preserved the user uses the option '--preserve' rather '--permanently=False'. It's ridiculous that the CLI taints the RPC API and it should be fixed. Also on a more nitpicky side, I think the flag should be called --no-preserve rather than --permanently. There is plenty of commands
Re: [Freeipa-devel] [PATCH 0266] ipa-ca-install fix: reconnect ldap2 after DS restart
On 18/06/15 15:04, Martin Babinsky wrote:
On 06/17/2015 02:28 PM, Martin Basti wrote:
https://fedorahosted.org/freeipa/ticket/5064
Patch attached.
ACK
Rebased patch attached.
--
Martin Basti
From e6827b6993706d16831af24e8be7d1ccec4c4975 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Wed, 17 Jun 2015 14:19:25 +0200
Subject: [PATCH] ipa-ca-install fix: reconnect ldap2 after DS restart
https://fedorahosted.org/freeipa/ticket/5064
---
ipaserver/install/ca.py | 9 +
1 file changed, 9 insertions(+)
diff --git a/ipaserver/install/ca.py b/ipaserver/install/ca.py
index b84756922be6deba11038d58b5ffb0fa3c150f6a..498cc48a742d1b2d862eb9dfdb18743cfb211b78 100644
--- a/ipaserver/install/ca.py
+++ b/ipaserver/install/ca.py
@@ -122,7 +122,16 @@ def install_step_0(standalone, replica_config, options):
postinstall = True
else:
postinstall = False
+
+if standalone:
+api.Backend.ldap2.disconnect()
+
cainstance.install_replica_ca(replica_config, postinstall)
+
+if standalone:
+api.Backend.ldap2.connect(bind_dn=DN(('cn', 'Directory Manager')),
+ bind_pw=dm_password)
+
return
if options.external_cert_files:
--
2.1.0
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands
On 06/18/2015 03:42 PM, David Kupka wrote: Dne 18.6.2015 v 13:22 Petr Vobornik napsal(a): On 06/18/2015 12:52 PM, Jan Cholasta wrote: Dne 18.6.2015 v 09:30 Jan Cholasta napsal(a): Dne 15.6.2015 v 17:29 thierry bordaz napsal(a): On 06/15/2015 05:00 PM, Simo Sorce wrote: On Mon, 2015-06-15 at 16:48 +0200, Petr Vobornik wrote: On 06/09/2015 02:02 PM, Jan Cholasta wrote: Dne 20.5.2015 v 11:26 Jan Cholasta napsal(a): Dne 18.5.2015 v 10:33 thierry bordaz napsal(a): On 05/15/2015 04:44 PM, David Kupka wrote: Hello Thierry, thanks for the patch set. Overall functionality of ULC feature looks good to me and is definitely alpha ready. I found following issues but don't insist on fixing it right now: 1) When stageuser-activate fails due to already existent active/deleted user. DN is show instead of user name that's used in other commands (user-add, stageuser-add). $ ipa user-add tuser --first Test --last User $ ipa stageuser-add tuser --first Test --last User $ ipa stageuser-activate tuser ipa: ERROR: Active user uid=tuser,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com already exists Hi David, Jan, Thanks you so much for all those tests and feedback. I agree, some minor bugs can be fixed separatly from this main patches. You are right, It should return the user ID not the DN. 2) According to the design there should be '--only-delete' and '--also-delete' options for user-find command instead there is '--preserved' option. Honza proposed adding virtual boolean attribute 'deleted' to user entry and filter on it. The 'deleted' attribute would be useful also in user-show where is no way to tell if the displayed user is active or deleted. (Except running with --all and looking on the dn). Yes a bit late to resynch the design. The final option is 'preserved' for user-find and 'preserve' for user-del. '--only-delete' or 'also-delete' are old name that I need to replace in the design. About the 'deleted' attribute, do you think adding a DS cos virtual attribute ? See the attached patch. Can someone please review the patch? 3) uidNumber and gidNumber can't be set back to '-1' once set to other value. This would be useful when admin changes its mind and want IPA to assign them. IIUC, there should be no validation in cn=staged user container. All validation should be done during stageuser-activate. Yes that comes from user plugin that enforce the number to be 0. That is a good point giving the ability to reset uidNumber/gidNumber. I will check if it is possible, how (give a value or an option to reset), and also if it would not create other issue. 4) Support for deleted - stage workflow is still missing. But I'm unsure if we agreed to finish it now or later. Yes thanks 5) Twice deleting user with '--preserve' deletes him permanently. $ ipa user-add tuser --first Test --last User $ ipa user-del tuser --preserve $ ipa user-del tuser --preserve $ ipa user-find --preserved 0 (delete) users matched Number of entries returned 0 Deleting a deleted (preserved) entry, should permanently remove the entry. +1, but no-op if default behavior is preserve Now if the second time the preserve option is present, it makes sense to not delete it. +1, should be no-op BTW: I might be stating the obvious here, but it would be better to use one boolean parameter rather than two mutually exclusive flags in user-del. I would like an opinion on this as well. So the proposal is, e.g.,: Replace: ipa user del fbar --preserve ipa user del fbar --permanently with: ipa user del fbar --permanently=False ipa user del fbar --permanently=True and ipa user del fbar uses the default behavior(permanently atm.) I don't think there is a big difference. A boolean is easier for scripting. 2 options are more descriptive for humans. With a single boolean, I would be afraid that omitting it would imply False to some users which is not always the same as the default behavior [1]. With Web UI developer hat I would vote for single boolean but as a CLI user I would like the current options. Given that Web UI or any other API client should not define CLI, I would keep the current options. my 2c [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Delete_User -- Petr Vobornik +1 --preserve is 100x better for a human than --permanently=False I also prefere --preserve for usability of 'user del'. In addition we have 'user find|show --preserved' to retrieve users that have been preserved. So it seems to me better that the action that preserved the user uses the option '--preserve' rather '--permanently=False'. It's ridiculous that the CLI taints the RPC API and it should be fixed. Also on a more nitpicky side, I think the flag should be called --no-preserve rather than --permanently. There is plenty of commands (rm, cp, ...) which have --no-preserve as opposite
Re: [Freeipa-devel] Community Portal Prototype
On 18.6.2015 16:09, Drew Erny wrote: On 06/18/2015 03:53 AM, Petr Spacek wrote: On 17.6.2015 21:21, Drew Erny wrote: a) Most importantly, obtaining credentials for authentication to the FreeIPA server is completely missing. You need to 'somehow' fill in Kerberos credential cache with a valid ticket (~ equivalent of kinit user) and use this ticket for authentication to the FreeIPA server. Ugly and hacky way to do that can be seen in https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/dnssec/ipa-ods-exporter?id=4dfa23256dc2e35480843beef92e03b1bafd578b#n395 Maybe you should use GSS-Proxy so your code does not have to deal with authentication at all and let GSS-Proxy to do that for you behind the scenes. https://fedoraproject.org/wiki/Features/gss-proxy https://fedorahosted.org/gss-proxy/ Please ask Simo for further details. This is definitely something I was keeping in mind, but I wasn't too worried about it in the short term, because I always assumed that the user would configure the Community Portal to run as a special user, and I know there is a way for machine users to get Kerberos tickets. I figured I'd work out the details of that once the design was approved, because the Community Portal will have a configuration script to deploy it, and setting up that authentication will be part of the configuration script. Okay then. b) I understand that this is a first prototype but we should replace the e-mailing thingy before we release it. Direct generation of e-mails goes against the spirit of (envisioned) notification system and has it's inherent problems. - It is not going to scale if you have a lot of requests. - Does not allow additional logic (auto-approval/denial based on some criteria etc.) built on top of that. Also, e.g. public website using FreeIPA behind the scenes for user management might want to auto-approve accounts and put them to some pre-defined group with lowest possible privileges. D-Bus hooks makes this auto-approval possible and does not depend on a cron job, i.e. eliminates the delay. The hook can of course do anything, use your imagination :-) I hope this helps to clarify why I insist on proper hook. With some tweaking emailing from the web application would scale fine if we use some sort of non-blocking call to send the emails. I think, because the Let me clarify this: It will not scale on the receiving side. Free-form e-mail is meant for humans. If you are going to send XMLs (or some other structured data) in e-mails and parse them on the receiving side then you actually need a message bus and reliable transport and not unreliable e-mail as used today. Community Portal is an exterior fixture (it's a client to the FreeIPA server, not part of the server itself), it's outside of the purview of the planned message system. The Community Portal might live on a completely different server. FreeIPA consist of several almost-independent services so I do not see a reason why this should be different in any way. Moreover, the hook should not be in the self-service portal but inside stageuser-add code in FreeIPA framework so the hook can be called universally, even if the command is called manually or from different implementation of the Community Portal. Furthermore, If we wanted to build additional logic on approve/deny a user, that would have to be done on the client side anyway, to enforce the separation of concerns I have here (where the FreeIPA main application doesn't even have to be aware that there is a self service portal). So, to D-Bus serves as the separation layer. FreeIPA should know *nothing* about any hook. FreeIPA code should only calls proper D-Bus method with correct parameters and let hook implementation to use the parameters in whatever way they want (and ignore the call if the hook does not exist, probably). auto-approve/deny, we would just add additional logic to the User.save() method. I do not know how this would be easily user-configurable, and I think it's probably a bit out of scope for now anyway. Exactly - ease of configuration is the goal. D-Bus will provide separation so we do not need to worry about users tweaking the code we ship (with the intent to modify the behavior). Let me give you an example: 1) Community portal: Call IPA.stageuser_add(params) 2) IPA framework: call D-Bus method freeipa.hook.stageuser.add(params) 3) D-Bus: Invoke whatever implementation is registered for freeipa.hook.stageuser.add 4) freeipa.hook.stageuser.add implementation: Auto-approve the user and/or generate an e-mail to the admin. Please note that step (4) can be arbitrarily changed by user just by modifying service file for Systemd. User will simply bind own script as implementation of freeipa.hook.stageuser.add interface and that is it. No change to FreeIPA code is necessary. Does it make sense? So, basically, it's not clear to me why we need to be worrying about a proper D-Bus hook at this
Re: [Freeipa-devel] [PATCH 0266] ipa-ca-install fix: reconnect ldap2 after DS restart
On 06/18/2015 03:53 PM, Martin Basti wrote: On 18/06/15 15:04, Martin Babinsky wrote: On 06/17/2015 02:28 PM, Martin Basti wrote: https://fedorahosted.org/freeipa/ticket/5064 Patch attached. ACK Rebased patch attached. ACK to rebased patch :). -- Martin^3 Babinsky -- 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 0265] Server Upgrade: Create NIS server configuration during upgrade in off mode
On 06/11/2015 04:04 PM, Martin Basti wrote: Without this patch, upgrader shows the parent entry not found error. NIS Server plugin is disabled by default, must be enabled by ipa-nis-manage Patch attached. ACK -- Martin^3 Babinsky -- 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] Community Portal Prototype
On 06/18/2015 03:53 AM, Petr Spacek wrote: On 17.6.2015 21:21, Drew Erny wrote: Hello, all, I've built a prototype of the community portal, and I'd like a quick sanity check on it. If someone would look over the architecture of this code and make sure that the design is sensible before I proceed any further, that would be very helpful. The source code can be found here: https://github.com/dperny/freeipa-communityportal This code should run on your machine, and you should be able to add users to the staging tree. It might not, howver; the point is to have the code looked at before I spend anymore time on it. The Community Portal prototype is a Python Flask web-application that acts as a client to a FreeIPA server. It collects input from the unwashed masses (in the form of a user sign-up page) and then sends it to the FreeIPA server. This way, the Community Portal acts like a gateway between the FreeIPA server and the anonymous community users, restricting the commands they can send to the server. Right now, the server imports FreeIPA's Python ipalib module, which allows it to act like a client. It uses api.Command.stageuser_add(...) to add new users to the staging area of the FreeIPA database. It then sends an email to the admin (or, rather, it logs an email to the console instead of sending one, in the prototype) to alert them to the fact that a user has signed up. All feedback is welcome. It seems reasonable except for two things: a) Most importantly, obtaining credentials for authentication to the FreeIPA server is completely missing. You need to 'somehow' fill in Kerberos credential cache with a valid ticket (~ equivalent of kinit user) and use this ticket for authentication to the FreeIPA server. Ugly and hacky way to do that can be seen in https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/dnssec/ipa-ods-exporter?id=4dfa23256dc2e35480843beef92e03b1bafd578b#n395 Maybe you should use GSS-Proxy so your code does not have to deal with authentication at all and let GSS-Proxy to do that for you behind the scenes. https://fedoraproject.org/wiki/Features/gss-proxy https://fedorahosted.org/gss-proxy/ Please ask Simo for further details. This is definitely something I was keeping in mind, but I wasn't too worried about it in the short term, because I always assumed that the user would configure the Community Portal to run as a special user, and I know there is a way for machine users to get Kerberos tickets. I figured I'd work out the details of that once the design was approved, because the Community Portal will have a configuration script to deploy it, and setting up that authentication will be part of the configuration script. b) I understand that this is a first prototype but we should replace the e-mailing thingy before we release it. Direct generation of e-mails goes against the spirit of (envisioned) notification system and has it's inherent problems. - It is not going to scale if you have a lot of requests. - Does not allow additional logic (auto-approval/denial based on some criteria etc.) built on top of that. Also, e.g. public website using FreeIPA behind the scenes for user management might want to auto-approve accounts and put them to some pre-defined group with lowest possible privileges. D-Bus hooks makes this auto-approval possible and does not depend on a cron job, i.e. eliminates the delay. The hook can of course do anything, use your imagination :-) I hope this helps to clarify why I insist on proper hook. With some tweaking emailing from the web application would scale fine if we use some sort of non-blocking call to send the emails. I think, because the Community Portal is an exterior fixture (it's a client to the FreeIPA server, not part of the server itself), it's outside of the purview of the planned message system. The Community Portal might live on a completely different server. Furthermore, If we wanted to build additional logic on approve/deny a user, that would have to be done on the client side anyway, to enforce the separation of concerns I have here (where the FreeIPA main application doesn't even have to be aware that there is a self service portal). So, to auto-approve/deny, we would just add additional logic to the User.save() method. I do not know how this would be easily user-configurable, and I think it's probably a bit out of scope for now anyway. So, basically, it's not clear to me why we need to be worrying about a proper D-Bus hook at this stage in the process. -- 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 0265] Server Upgrade: Create NIS server configuration during upgrade in off mode
On 06/18/2015 03:50 PM, Martin Babinsky wrote: On 06/11/2015 04:04 PM, Martin Basti wrote: Without this patch, upgrader shows the parent entry not found error. NIS Server plugin is disabled by default, must be enabled by ipa-nis-manage Patch attached. ACK Pushed to master: 20ffd4b61434e2630bf6512170a213767ff8d679 But I filled wrong reviewer by mistake - mbasti instead of mbabinsk. My apologies. -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0266] ipa-ca-install fix: reconnect ldap2 after DS restart
On 06/18/2015 05:29 PM, Martin Babinsky wrote: On 06/18/2015 03:53 PM, Martin Basti wrote: On 18/06/15 15:04, Martin Babinsky wrote: On 06/17/2015 02:28 PM, Martin Basti wrote: https://fedorahosted.org/freeipa/ticket/5064 Patch attached. ACK Rebased patch attached. ACK to rebased patch :). Pushed to master: d2d13826c661e2ba244812897da13b40fbf2bc67 -- 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] Need to figure out how to make a schema change
On Thu, Jun 18, 2015 at 11:02:03AM -0700, Nathan Kinder wrote: On 06/18/2015 10:45 AM, Ade Lee wrote: In order for IPA to use some new functionality in Profile Management and Sub CAs, we need to add some additional schema to the Dogtag LDAP instance. Fraser has written a Dogtag upgrade script to do this upgrade, but this script expects the DM password to be in password.conf. Some discussion on this script can be found here .. https://www.redhat.com/archives/pki-devel/2015-June/msg00054.html In general, I think that while Dogtag will provide a database upgrade framework and/or upgrade LDIF scripts, we will not - in general - know how to connect to the DB with a user that has credentials to make schema changes. Fortunately, these types of changes are rare. Note that in all the years Dogtag has been part of IPA, this is the first time this situation has arisen. The question now though is - how can we co-ordinate with IPA to make this change? This question may have both a short term (for this particular change) and long term answer. What about using LDAPI and autobind functionality? If the upgrade script is run locally as root, then it can autobind to cn=Directory Manager without requiring a password. I like this idea, but I'm not sure how to accurately locate the socket, because the name depends on the domain, e.g. `/var/run/slapd-EXAMPLE-COM.socket'. Since the new schema is for now only used by and supported for IPA, I think the immediate way forward is to provide the new schema LDIF in the Dogtag package (as the current patch does), and have FreeIPA use it to update the DS. I will have patch for IPA and updated patch for Dogtag shortly. We will then work out what is the way forward for Dogtag to reliably manage its schema updates in the variety of authentication scenarios. Thanks, Fraser Thanks, -NGK Thanks, Ade -- 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] Need to figure out how to make a schema change
On 6/18/2015 8:19 PM, Fraser Tweedale wrote: In order for IPA to use some new functionality in Profile Management and Sub CAs, we need to add some additional schema to the Dogtag LDAP instance. Fraser has written a Dogtag upgrade script to do this upgrade, but this script expects the DM password to be in password.conf. Some discussion on this script can be found here .. https://www.redhat.com/archives/pki-devel/2015-June/msg00054.html In general, I think that while Dogtag will provide a database upgrade framework and/or upgrade LDIF scripts, we will not - in general - know how to connect to the DB with a user that has credentials to make schema changes. Fortunately, these types of changes are rare. Note that in all the years Dogtag has been part of IPA, this is the first time this situation has arisen. The question now though is - how can we co-ordinate with IPA to make this change? This question may have both a short term (for this particular change) and long term answer. What about using LDAPI and autobind functionality? If the upgrade script is run locally as root, then it can autobind to cn=Directory Manager without requiring a password. I like this idea, but I'm not sure how to accurately locate the socket, because the name depends on the domain, e.g. `/var/run/slapd-EXAMPLE-COM.socket'. I think the socket name would have to be provided by IPA via PKI deployment configuration. I'm just wondering how LDAPI with autobind would work with nuxwdog. Supposedly when nuxwdog is enabled the server can only be started by providing the NSS and LDAP database passwords. Does LDAPI with autobind make it less secure since the LDAP password is no longer required? Also, LDAPI wouldn't work if the DS is on a different machine in general PKI deployment. I created this page about PKI database upgrade: http://pki.fedoraproject.org/wiki/Database_Upgrade Since the new schema is for now only used by and supported for IPA, I think the immediate way forward is to provide the new schema LDIF in the Dogtag package (as the current patch does), and have FreeIPA use it to update the DS. I will have patch for IPA and updated patch for Dogtag shortly. We will then work out what is the way forward for Dogtag to reliably manage its schema updates in the variety of authentication scenarios. Thanks, Fraser -- Endi S. Dewata -- 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] Need to figure out how to make a schema change
On 06/18/2015 07:08 PM, Endi Sukma Dewata wrote: On 6/18/2015 8:19 PM, Fraser Tweedale wrote: In order for IPA to use some new functionality in Profile Management and Sub CAs, we need to add some additional schema to the Dogtag LDAP instance. Fraser has written a Dogtag upgrade script to do this upgrade, but this script expects the DM password to be in password.conf. Some discussion on this script can be found here .. https://www.redhat.com/archives/pki-devel/2015-June/msg00054.html In general, I think that while Dogtag will provide a database upgrade framework and/or upgrade LDIF scripts, we will not - in general - know how to connect to the DB with a user that has credentials to make schema changes. Fortunately, these types of changes are rare. Note that in all the years Dogtag has been part of IPA, this is the first time this situation has arisen. The question now though is - how can we co-ordinate with IPA to make this change? This question may have both a short term (for this particular change) and long term answer. What about using LDAPI and autobind functionality? If the upgrade script is run locally as root, then it can autobind to cn=Directory Manager without requiring a password. I like this idea, but I'm not sure how to accurately locate the socket, because the name depends on the domain, e.g. `/var/run/slapd-EXAMPLE-COM.socket'. I think the socket name would have to be provided by IPA via PKI deployment configuration. That would work. The other alternative is that we could advertise it in the root DSE. I'm just wondering how LDAPI with autobind would work with nuxwdog. Supposedly when nuxwdog is enabled the server can only be started by providing the NSS and LDAP database passwords. Does LDAPI with autobind make it less secure since the LDAP password is no longer required? LDAPI still requires the server to be started to work. How does nuxwdog fit into this issue? Also, LDAPI wouldn't work if the DS is on a different machine in general PKI deployment. Correct. I created this page about PKI database upgrade: http://pki.fedoraproject.org/wiki/Database_Upgrade Since the new schema is for now only used by and supported for IPA, I think the immediate way forward is to provide the new schema LDIF in the Dogtag package (as the current patch does), and have FreeIPA use it to update the DS. I will have patch for IPA and updated patch for Dogtag shortly. We will then work out what is the way forward for Dogtag to reliably manage its schema updates in the variety of authentication scenarios. Thanks, Fraser -- 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] Need to figure out how to make a schema change
On 06/18/2015 10:45 AM, Ade Lee wrote: In order for IPA to use some new functionality in Profile Management and Sub CAs, we need to add some additional schema to the Dogtag LDAP instance. Fraser has written a Dogtag upgrade script to do this upgrade, but this script expects the DM password to be in password.conf. Some discussion on this script can be found here .. https://www.redhat.com/archives/pki-devel/2015-June/msg00054.html In general, I think that while Dogtag will provide a database upgrade framework and/or upgrade LDIF scripts, we will not - in general - know how to connect to the DB with a user that has credentials to make schema changes. Fortunately, these types of changes are rare. Note that in all the years Dogtag has been part of IPA, this is the first time this situation has arisen. The question now though is - how can we co-ordinate with IPA to make this change? This question may have both a short term (for this particular change) and long term answer. What about using LDAPI and autobind functionality? If the upgrade script is run locally as root, then it can autobind to cn=Directory Manager without requiring a password. Thanks, -NGK Thanks, Ade -- 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] FreeIPA 4.2 Alpha preparations
On 06/18/2015 02:05 PM, Petr Vobornik wrote: I'm going to tag alpha_1-4-3-0 today at 15:00 CET. I'm not aware of any alpha blockers on FreeIPA side. Please contact me if there are patches which should make the release. This release will be available in mkosek/freeipa-4-2 COPR repository. When ready, the new dogtag should go into the COPR as well. What are the know issues which should be mentioned in release notes? http://www.freeipa.org/page/Releases/4.2.0.alpha1#Known_Issues There was a slight delay but all patches for the alpha were pushed. FreeIPA was tagged. COPR build is ready [1]. Given that the last tag in master branch was release-4-0-0, the detailed change log contains quite a lot of commits[2] Is there a convenient command to do a commit diff between master and ipa-4-1 to list just the commits which are not in ipa-4-1? Ideally it should also take different versions of the same thing into account. [1] https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.2/builds/ [2] http://www.freeipa.org/page/Releases/4.2.0.alpha1#Detailed_Changelog_since_4.0 -- 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] FreeIPA 4.2 Alpha preparations
On Thu, Jun 18, 2015 at 08:02:23PM +0200, Petr Vobornik wrote: On 06/18/2015 02:05 PM, Petr Vobornik wrote: I'm going to tag alpha_1-4-3-0 today at 15:00 CET. I'm not aware of any alpha blockers on FreeIPA side. Please contact me if there are patches which should make the release. This release will be available in mkosek/freeipa-4-2 COPR repository. When ready, the new dogtag should go into the COPR as well. What are the know issues which should be mentioned in release notes? http://www.freeipa.org/page/Releases/4.2.0.alpha1#Known_Issues There was a slight delay but all patches for the alpha were pushed. FreeIPA was tagged. COPR build is ready [1]. Given that the last tag in master branch was release-4-0-0, the detailed change log contains quite a lot of commits[2] Is there a convenient command to do a commit diff between master and ipa-4-1 to list just the commits which are not in ipa-4-1? Ideally it should also take different versions of the same thing into account. No, I had a dumb Python script that acted on commit messages (sic!) to filter out the already-released commits. -- 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] Need to figure out how to make a schema change
In order for IPA to use some new functionality in Profile Management and Sub CAs, we need to add some additional schema to the Dogtag LDAP instance. Fraser has written a Dogtag upgrade script to do this upgrade, but this script expects the DM password to be in password.conf. Some discussion on this script can be found here .. https://www.redhat.com/archives/pki-devel/2015-June/msg00054.html In general, I think that while Dogtag will provide a database upgrade framework and/or upgrade LDIF scripts, we will not - in general - know how to connect to the DB with a user that has credentials to make schema changes. Fortunately, these types of changes are rare. Note that in all the years Dogtag has been part of IPA, this is the first time this situation has arisen. The question now though is - how can we co-ordinate with IPA to make this change? This question may have both a short term (for this particular change) and long term answer. Thanks, Ade -- 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] [RFC] Community Portal
Hi, all, More email about the community portal. This time, I have a design proposal for you: http://www.freeipa.org/page/V4/Community_Portal Tell me what you think. Thanks, Drew Erny -- 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] disabling topology segment has no effect
Hi Ludwig, I've saved and analyzed all the console outputs from my activity on master and replica1 (from consoles that I by chance did not close). I was not able to detect the moment when the things went wrong. My guess is that the changes in topology get replicated slowly enough to be able to introduce 2 contradictory changes on different nodes, that leads to infrastructure inconsistency. It could also be that at some point I made topology changes having one of the nodes turned off, which could have lead to temporary loss in infrastructure integrity. Right now I have 4 nodes, one of which has incorrect topology data. As a result any changes that are made on this node do not get replicated on others, while changes made on other nodes do get replicated to this first one. Today I'll try to reproduce this on fresh VMs with the fresh code. On 06/17/2015 05:53 PM, Ludwig Krispenz wrote: On 06/17/2015 05:43 PM, Oleg Fayans wrote: On 06/17/2015 05:34 PM, Ludwig Krispenz wrote: On 06/17/2015 05:26 PM, Oleg Fayans wrote: Hi Ludwig, On 06/17/2015 05:13 PM, Ludwig Krispenz wrote: Hi, On 06/17/2015 05:07 PM, Oleg Fayans wrote: On 06/17/2015 04:59 PM, Ludwig Krispenz wrote: On 06/17/2015 04:46 PM, Oleg Fayans wrote: Hi Ludwig, On 06/17/2015 04:15 PM, Ludwig Krispenz wrote: On 06/17/2015 03:37 PM, Oleg Fayans wrote: Hi Ludwig, Petr, Presently I have noticed that disabling a segment, using `ipa topologysegment-mod realm replica1-to-replica2 --enabled=off` does not have effect on the way the data is replicated. I mean that if we have the following tolopogy: master - replica1 - replica2 on which server did you apply the mod ? On master. just to be clear, you have master - replica1 - replica2 on master you disable replica1-replica2 why would you expect mods on master not to be replicated ? at least to replica1 ? the disable should only effect the connection between r1 and r2. There is one problem in this linear topology, the disable reaches r1, it disables the agmt to r2 and so fails to replicate the disable to r2. To be precise, my topology is as follows master - replica3 - replica2 - replica1 And I disabled the replica3 - replica2. So I expected the changes on master to be only visible on master and replica3, but actually it kept replicating to all nodes. root@f22replica1:/home/ofayans]$ ipa topologysegment-find realm -- 3 segments matched -- Segment name: f22master.bagam.net-to-f22replica3.bagam.net Left node: f22master.bagam.net Right node: f22replica3.bagam.net Connectivity: both Segment name: replica1-to-replica2 Left node: f22replica1.bagam.net Right node: f22replica2.bagam.net Connectivity: both Segment name: replica3-to-replica2 Left node: f22replica3.bagam.net Right node: f22replica2.bagam.net Connectivity: both Number of entries returned 3 root@f22replica1:/home/ofayans]$ ipa topologysegment-show realm replica3-to-replica2 Segment name: replica3-to-replica2 Left node: f22replica3.bagam.net Right node: f22replica2.bagam.net Connectivity: both Replication agreement enabled: off can you do a ldapsearch on cn=realm,cn=topology, .. $ ldapsearch -LLL -b cn=realm,cn=topology,cn=ipa,cn=etc,dc=bagam,dc=net -D cn=Directory Manager -w 'password' dn: cn=realm,cn=topology,cn=ipa,cn=etc,dc=bagam,dc=net cn: realm ipaReplTopoConfRoot: dc=bagam,dc=net objectClass: top objectClass: iparepltopoconf dn: cn=replica1-to-replica2,cn=realm,cn=topology,cn=ipa,cn=etc,dc=bagam,dc=net ipaReplTopoSegmentRightNode: f22replica2.bagam.net ipaReplTopoSegmentDirection: both cn: replica1-to-replica2 ipaReplTopoSegmentLeftNode: f22replica1.bagam.net objectClass: iparepltoposegment objectClass: top replica1 - replica2 dn: cn=f22master.bagam.net-to-f22replica3.bagam.net,cn=realm,cn=topology,cn=ip a,cn=etc,dc=bagam,dc=net ipaReplTopoSegmentDirection: both objectClass: iparepltoposegment objectClass: top cn: f22master.bagam.net-to-f22replica3.bagam.net ipaReplTopoSegmentLeftNode: f22master.bagam.net ipaReplTopoSegmentRightNode: f22replica3.bagam.net ipaReplTopoSegmentStatus: autogen master - replica3 dn: cn=f22replica3.bagam.net-f22replica1.bagam.net,cn=realm,cn=topology,cn=ipa ,cn=etc,dc=bagam,dc=net objectClass: iparepltoposegment objectClass: top ipaReplTopoSegmentLeftNode: f22replica3.bagam.net cn: f22replica3.bagam.net-f22replica1.bagam.net ipaReplTopoSegmentDirection: both ipaReplTopoSegmentRightNode: f22replica1.bagam.net replica3 - replica1 but this does not match your segment-find output, there is no segment replica2 - replica3 You know what, this is because I did ldapsearch on replica3, while I posted the results of topologysegment-find run on replica1. But this means that there is a breakage in the replication between replica1 and the rest of topology (the result of topologysegment-find is the same across master-replica2-replica3
Re: [Freeipa-devel] Community Portal Prototype
On 17.6.2015 21:21, Drew Erny wrote: Hello, all, I've built a prototype of the community portal, and I'd like a quick sanity check on it. If someone would look over the architecture of this code and make sure that the design is sensible before I proceed any further, that would be very helpful. The source code can be found here: https://github.com/dperny/freeipa-communityportal This code should run on your machine, and you should be able to add users to the staging tree. It might not, howver; the point is to have the code looked at before I spend anymore time on it. The Community Portal prototype is a Python Flask web-application that acts as a client to a FreeIPA server. It collects input from the unwashed masses (in the form of a user sign-up page) and then sends it to the FreeIPA server. This way, the Community Portal acts like a gateway between the FreeIPA server and the anonymous community users, restricting the commands they can send to the server. Right now, the server imports FreeIPA's Python ipalib module, which allows it to act like a client. It uses api.Command.stageuser_add(...) to add new users to the staging area of the FreeIPA database. It then sends an email to the admin (or, rather, it logs an email to the console instead of sending one, in the prototype) to alert them to the fact that a user has signed up. All feedback is welcome. It seems reasonable except for two things: a) Most importantly, obtaining credentials for authentication to the FreeIPA server is completely missing. You need to 'somehow' fill in Kerberos credential cache with a valid ticket (~ equivalent of kinit user) and use this ticket for authentication to the FreeIPA server. Ugly and hacky way to do that can be seen in https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/dnssec/ipa-ods-exporter?id=4dfa23256dc2e35480843beef92e03b1bafd578b#n395 Maybe you should use GSS-Proxy so your code does not have to deal with authentication at all and let GSS-Proxy to do that for you behind the scenes. https://fedoraproject.org/wiki/Features/gss-proxy https://fedorahosted.org/gss-proxy/ Please ask Simo for further details. b) I understand that this is a first prototype but we should replace the e-mailing thingy before we release it. Direct generation of e-mails goes against the spirit of (envisioned) notification system and has it's inherent problems. - It is not going to scale if you have a lot of requests. - Does not allow additional logic (auto-approval/denial based on some criteria etc.) built on top of that. Also, e.g. public website using FreeIPA behind the scenes for user management might want to auto-approve accounts and put them to some pre-defined group with lowest possible privileges. D-Bus hooks makes this auto-approval possible and does not depend on a cron job, i.e. eliminates the delay. The hook can of course do anything, use your imagination :-) I hope this helps to clarify why I insist on proper hook. -- Petr^2 Spacek -- 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] 0005 User life cycle: del/mod/find/show stageuser commands
Dne 15.6.2015 v 17:29 thierry bordaz napsal(a): On 06/15/2015 05:00 PM, Simo Sorce wrote: On Mon, 2015-06-15 at 16:48 +0200, Petr Vobornik wrote: On 06/09/2015 02:02 PM, Jan Cholasta wrote: Dne 20.5.2015 v 11:26 Jan Cholasta napsal(a): Dne 18.5.2015 v 10:33 thierry bordaz napsal(a): On 05/15/2015 04:44 PM, David Kupka wrote: Hello Thierry, thanks for the patch set. Overall functionality of ULC feature looks good to me and is definitely alpha ready. I found following issues but don't insist on fixing it right now: 1) When stageuser-activate fails due to already existent active/deleted user. DN is show instead of user name that's used in other commands (user-add, stageuser-add). $ ipa user-add tuser --first Test --last User $ ipa stageuser-add tuser --first Test --last User $ ipa stageuser-activate tuser ipa: ERROR: Active user uid=tuser,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com already exists Hi David, Jan, Thanks you so much for all those tests and feedback. I agree, some minor bugs can be fixed separatly from this main patches. You are right, It should return the user ID not the DN. 2) According to the design there should be '--only-delete' and '--also-delete' options for user-find command instead there is '--preserved' option. Honza proposed adding virtual boolean attribute 'deleted' to user entry and filter on it. The 'deleted' attribute would be useful also in user-show where is no way to tell if the displayed user is active or deleted. (Except running with --all and looking on the dn). Yes a bit late to resynch the design. The final option is 'preserved' for user-find and 'preserve' for user-del. '--only-delete' or 'also-delete' are old name that I need to replace in the design. About the 'deleted' attribute, do you think adding a DS cos virtual attribute ? See the attached patch. Can someone please review the patch? 3) uidNumber and gidNumber can't be set back to '-1' once set to other value. This would be useful when admin changes its mind and want IPA to assign them. IIUC, there should be no validation in cn=staged user container. All validation should be done during stageuser-activate. Yes that comes from user plugin that enforce the number to be 0. That is a good point giving the ability to reset uidNumber/gidNumber. I will check if it is possible, how (give a value or an option to reset), and also if it would not create other issue. 4) Support for deleted - stage workflow is still missing. But I'm unsure if we agreed to finish it now or later. Yes thanks 5) Twice deleting user with '--preserve' deletes him permanently. $ ipa user-add tuser --first Test --last User $ ipa user-del tuser --preserve $ ipa user-del tuser --preserve $ ipa user-find --preserved 0 (delete) users matched Number of entries returned 0 Deleting a deleted (preserved) entry, should permanently remove the entry. +1, but no-op if default behavior is preserve Now if the second time the preserve option is present, it makes sense to not delete it. +1, should be no-op BTW: I might be stating the obvious here, but it would be better to use one boolean parameter rather than two mutually exclusive flags in user-del. I would like an opinion on this as well. So the proposal is, e.g.,: Replace: ipa user del fbar --preserve ipa user del fbar --permanently with: ipa user del fbar --permanently=False ipa user del fbar --permanently=True and ipa user del fbar uses the default behavior(permanently atm.) I don't think there is a big difference. A boolean is easier for scripting. 2 options are more descriptive for humans. With a single boolean, I would be afraid that omitting it would imply False to some users which is not always the same as the default behavior [1]. With Web UI developer hat I would vote for single boolean but as a CLI user I would like the current options. Given that Web UI or any other API client should not define CLI, I would keep the current options. my 2c [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Delete_User -- Petr Vobornik +1 --preserve is 100x better for a human than --permanently=False I also prefere --preserve for usability of 'user del'. In addition we have 'user find|show --preserved' to retrieve users that have been preserved. So it seems to me better that the action that preserved the user uses the option '--preserve' rather '--permanently=False'. It's ridiculous that the CLI taints the RPC API and it should be fixed. Also on a more nitpicky side, I think the flag should be called --no-preserve rather than --permanently. There is plenty of commands (rm, cp, ...) which have --no-preserve as opposite of --preserve. The attached patch fixes both. -- Jan Cholasta From 0a59f9394fc2e8f84142d45b2c588dac19c0c611 Mon Sep 17 00:00:00 2001 From: Jan Cholasta jchol...@redhat.com Date: Thu,
Re: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands
Dne 18.6.2015 v 09:30 Jan Cholasta napsal(a): Dne 15.6.2015 v 17:29 thierry bordaz napsal(a): On 06/15/2015 05:00 PM, Simo Sorce wrote: On Mon, 2015-06-15 at 16:48 +0200, Petr Vobornik wrote: On 06/09/2015 02:02 PM, Jan Cholasta wrote: Dne 20.5.2015 v 11:26 Jan Cholasta napsal(a): Dne 18.5.2015 v 10:33 thierry bordaz napsal(a): On 05/15/2015 04:44 PM, David Kupka wrote: Hello Thierry, thanks for the patch set. Overall functionality of ULC feature looks good to me and is definitely alpha ready. I found following issues but don't insist on fixing it right now: 1) When stageuser-activate fails due to already existent active/deleted user. DN is show instead of user name that's used in other commands (user-add, stageuser-add). $ ipa user-add tuser --first Test --last User $ ipa stageuser-add tuser --first Test --last User $ ipa stageuser-activate tuser ipa: ERROR: Active user uid=tuser,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com already exists Hi David, Jan, Thanks you so much for all those tests and feedback. I agree, some minor bugs can be fixed separatly from this main patches. You are right, It should return the user ID not the DN. 2) According to the design there should be '--only-delete' and '--also-delete' options for user-find command instead there is '--preserved' option. Honza proposed adding virtual boolean attribute 'deleted' to user entry and filter on it. The 'deleted' attribute would be useful also in user-show where is no way to tell if the displayed user is active or deleted. (Except running with --all and looking on the dn). Yes a bit late to resynch the design. The final option is 'preserved' for user-find and 'preserve' for user-del. '--only-delete' or 'also-delete' are old name that I need to replace in the design. About the 'deleted' attribute, do you think adding a DS cos virtual attribute ? See the attached patch. Can someone please review the patch? 3) uidNumber and gidNumber can't be set back to '-1' once set to other value. This would be useful when admin changes its mind and want IPA to assign them. IIUC, there should be no validation in cn=staged user container. All validation should be done during stageuser-activate. Yes that comes from user plugin that enforce the number to be 0. That is a good point giving the ability to reset uidNumber/gidNumber. I will check if it is possible, how (give a value or an option to reset), and also if it would not create other issue. 4) Support for deleted - stage workflow is still missing. But I'm unsure if we agreed to finish it now or later. Yes thanks 5) Twice deleting user with '--preserve' deletes him permanently. $ ipa user-add tuser --first Test --last User $ ipa user-del tuser --preserve $ ipa user-del tuser --preserve $ ipa user-find --preserved 0 (delete) users matched Number of entries returned 0 Deleting a deleted (preserved) entry, should permanently remove the entry. +1, but no-op if default behavior is preserve Now if the second time the preserve option is present, it makes sense to not delete it. +1, should be no-op BTW: I might be stating the obvious here, but it would be better to use one boolean parameter rather than two mutually exclusive flags in user-del. I would like an opinion on this as well. So the proposal is, e.g.,: Replace: ipa user del fbar --preserve ipa user del fbar --permanently with: ipa user del fbar --permanently=False ipa user del fbar --permanently=True and ipa user del fbar uses the default behavior(permanently atm.) I don't think there is a big difference. A boolean is easier for scripting. 2 options are more descriptive for humans. With a single boolean, I would be afraid that omitting it would imply False to some users which is not always the same as the default behavior [1]. With Web UI developer hat I would vote for single boolean but as a CLI user I would like the current options. Given that Web UI or any other API client should not define CLI, I would keep the current options. my 2c [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Delete_User -- Petr Vobornik +1 --preserve is 100x better for a human than --permanently=False I also prefere --preserve for usability of 'user del'. In addition we have 'user find|show --preserved' to retrieve users that have been preserved. So it seems to me better that the action that preserved the user uses the option '--preserve' rather '--permanently=False'. It's ridiculous that the CLI taints the RPC API and it should be fixed. Also on a more nitpicky side, I think the flag should be called --no-preserve rather than --permanently. There is plenty of commands (rm, cp, ...) which have --no-preserve as opposite of --preserve. The attached patch fixes both. ... and it also accidentaly changes the default behavior. Updated patch attached. -- Jan
