Re: [Freeipa-devel] Community Portal Milestone

[Martin Kosek]

On 06/10/2015 05:11 AM, Adam Young wrote:
> On 06/09/2015 06:34 PM, Simo Sorce wrote:
>> On Tue, 2015-06-09 at 16:15 -0400, Drew Erny wrote:
>>> Hey, Freeipa, same thread new subtopic.
>>>
>>> So, I was bouncing some ideas around with another developer (ayoung) and
>>> I think I have a pretty good idea for self-service user registration.
>>>
>>> The idea is that I put self-service user registration into its own
>>> application that calls out to ipa user-add after getting admin approval.
>>>
>>> Workflow goes like this:
>>>
>>> 1.) User goes to registration page, inputs details into form.
>>> Registration page and application are not part of FreeIPA.
>>> 2.) User's registration goes into a non-FreeIPA database, something like
>>> SQLite.
>>> 3.) Admin gets a notification email with a link to approve/deny
>>> registration.
>>>   A.) Admin clicks approval link, registration application (which has
>>> limited privileges) makes call out to ipa user-add command, adding the
>>> new user to FreeIPA.
>>>   B.) Admin click deny link, user is not added.
>>> 4.) User's registration information, approved or denied, is deleted from
>>> the external database.
>>>
>>> This has a couple of advantages. For starters, it provides a layer of
>>> protection against the creation of spam accounts. Accounts do not add
>>> directly to LDAP (inserting to LDAP is a slow operation), instead sit in
>>> intermediate area waiting approval. Second, we don't have to write a big
>>> extension to ipa user-add or staginguser-add that allows anonymous
>>> access to that command. Third, it can be bundled into its own package
>>> and given to the community separate from FreeIPA proper. Finally, it
>>> would allow me to gracefully defer becoming buried up to my neck in
>>> D-Bus notifications and whatever other fanciness we want to send email,
>>> because FreeIPA won't be sending the email.
>>>
>>> Opinions?
>> You could avoid using an external database by using the new USer
>> Lifecycle management feature [1]. This will allow you to do a simple
>> ldapadd, but the user will not be enabled until an admin logs into the
>> FreeIPA interface to enable the user.
>> This manes your app never needs to see the admin's credentials or use
>> s4u2proxy and will pose a lower risk to the system.
> The big issue was having an unauthentiucated user add o the datastore;  I 
> don't
> think you want to push new values directly into LDAP.  A separate Databse 
> makes
> a lot of sense, and using SQLite for a proof of concept allows us to migrate 
> up
> to MySQL for a live deployment.

The separate database does not make lot of sense to me, why not using the Stage
User tree when it's there, ready for you? I would like to know what is the
motivation and reasoning for using completely separate DB. Besides others, I
think Stage Users area for example checks for login name or UID/GID collisions.

The Selfservice just needs to operate under an identity that has a Stage User
Administrator privilege or we can create more contained privilege that could
just add the staged users and not modify/remove them.

-- 
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] Password vault

[Martin Kosek]

On 06/09/2015 11:13 PM, Endi Sukma Dewata wrote:
> Please take a look at the attached patch to add symmetric & asymmetric vaults.
> Some comments about the patch:
> 
> 1. The vault_add was split into a client-side vault_add and server-side
> vault_add_internal since the parameters are different (i.e. public key file 
> and
> future escrow-related params). Since vault_add inherits from Local all
> non-primary-key attributes have to be added explicitly.
> 
> 2. Since the vault_archive_internal inherits from Update, it accepts all non
> primary-key attributes automatically. This is incorrect since we don't want to
> update these parameters during archival. Can this behavior be overridden?

Just for the record, this changes API, right? It would be better to have this
in Alpha planned for this week. Not a blocker for Alpha though, we can give
warning that the internal API may change before GA.

-- 
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 Milestone

[Alexander Bokovoy]

On Tue, 09 Jun 2015, Adam Young wrote:

On 06/09/2015 06:34 PM, Simo Sorce wrote:

On Tue, 2015-06-09 at 16:15 -0400, Drew Erny wrote:

Hey, Freeipa, same thread new subtopic.

So, I was bouncing some ideas around with another developer (ayoung) and
I think I have a pretty good idea for self-service user registration.

The idea is that I put self-service user registration into its own
application that calls out to ipa user-add after getting admin approval.

Workflow goes like this:

1.) User goes to registration page, inputs details into form.
Registration page and application are not part of FreeIPA.
2.) User's registration goes into a non-FreeIPA database, something like
SQLite.
3.) Admin gets a notification email with a link to approve/deny
registration.
 A.) Admin clicks approval link, registration application (which has
limited privileges) makes call out to ipa user-add command, adding the
new user to FreeIPA.
 B.) Admin click deny link, user is not added.
4.) User's registration information, approved or denied, is deleted from
the external database.

This has a couple of advantages. For starters, it provides a layer of
protection against the creation of spam accounts. Accounts do not add
directly to LDAP (inserting to LDAP is a slow operation), instead sit in
intermediate area waiting approval. Second, we don't have to write a big
extension to ipa user-add or staginguser-add that allows anonymous
access to that command. Third, it can be bundled into its own package
and given to the community separate from FreeIPA proper. Finally, it
would allow me to gracefully defer becoming buried up to my neck in
D-Bus notifications and whatever other fanciness we want to send email,
because FreeIPA won't be sending the email.

Opinions?

You could avoid using an external database by using the new USer
Lifecycle management feature [1]. This will allow you to do a simple
ldapadd, but the user will not be enabled until an admin logs into the
FreeIPA interface to enable the user.
This manes your app never needs to see the admin's credentials or use
s4u2proxy and will pose a lower risk to the system.
The big issue was having an unauthentiucated user add o the datastore;  
I don't think you want to push new values directly into LDAP.  A 
separate Databse makes a lot of sense, and using SQLite for a proof of 
concept allows us to migrate up to MySQL for a live deployment.


I don't think S4U2Proxy is necessary.  A client app with permission to 
read from the registration app could use the users own credentials to 
push to the IPA server.   This could be done in a a web app with CORS 
support as well.

So now you have two apps instead of one. How would you do password
resets in this scheme? Password resets is what Drew is doing in first
place.
--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 00012-0013 v7] Profiles and CA ACLs

[Fraser Tweedale]

On Tue, Jun 09, 2015 at 04:37:56PM +0200, Martin Basti wrote:
> On 09/06/15 08:58, Fraser Tweedale wrote:
> >On Mon, Jun 08, 2015 at 08:49:06AM +0200, Martin Kosek wrote:
> >>On 06/08/2015 03:31 AM, Fraser Tweedale wrote:
> >>>New patches attached.  Comments inline.
> >>Thanks Fraser!
> >>
> >>...
> 5)
> Missing referint plugin configuration for attribute
> 'ipacaaclmembercertprofile'
> Please add it into install/updates/25-referint.update (+ other member
> attributes if missing)
> 
> >>>Added this.  There is a comment in 25-referint.update:
> >>>
> >>> # pres and eq indexes defined in 20-indices.update must be set
> >>> # for all the attributes
> >>>
> >>>Can you explain what is required here?  Is it just to add: I see
> >>>things for memberUser and memberHost in indices.ldif but nothing for
> >>>memberService.  Do I need to add to indices.ldif:
> >>>
> >>> dn: cn=memberProfile,cn=index,cn=userRoot,cn=ldbm 
> >>> database,cn=plugins,cn=config
> >>> changetype: add
> >>> cn: memberProfile
> >>> ObjectClass: top
> >>> ObjectClass: nsIndex
> >>> nsSystemIndex: false
> >>> nsIndexType: eq
> >>> nsIndexType: pres
> >>> nsIndexType: sub
> >>>
> >>>, and similarly for memberCa?  Sorry I do not know much about LDAP
> >>>indexing.
> >>AFAIR, yes. BTW, where does the "sub" index come from? It is quite an 
> >>expensive
> >>index to use and I now cannot think of memberProfile search where you would
> >>need a substring...
> >>
> >>Thanks,
> >>Martin
> >Updated patch attached, which adds the indices.  (Also rebased).
> >
> >There is a commit that seems to indicate that substring index is
> >needed, so I have included substring indices in this patchset.
> >Copied Honza in case he wants to comment.
> >
> > commit a10521a1dcf69960d6ce0bf5657180b709c297c0
> > Author: Jan Cholasta 
> > Date:   Tue Jun 25 13:16:40 2013 +
> >
> > Add missing substring indices for attributes managed by the 
> > referint plugin.
> >
> > The referint plugin does a substring search on these attributes 
> > each time an
> > entry is deleted, which causes a noticable slowdown for large 
> > directories if
> > the attributes are not indexed.
> >
> > https://fedorahosted.org/freeipa/ticket/3706
> >
> >Cheers,
> >Fraser
> ACK
> 
> Please send the upgrade patch ASAP :)
> 
> -- 
> Martin Basti
> 
Thank you for the ACK \o/

Since the patches have not been pushed, here is an updated patchset
which adds the upgrade behaviour.  There are no changes apart from
the additions to ipaserver/install/server/upgrade.py.

Cheers,
Fraser
From 4c18dde46c42abce4963f5ebe555b3865c84feeb Mon Sep 17 00:00:00 2001
From: Fraser Tweedale 
Date: Mon, 25 May 2015 08:39:07 -0400
Subject: [PATCH 12/13] Add CA ACL plugin

Implement the caacl commands, which are used to indicate which
principals may be issued certificates from which (sub-)CAs, using
which profiles.

At this commit, and until sub-CAs are implemented, all rules refer
to the top-level CA (represented as ".") and no ca-ref argument is
exposed.

Also, during install and upgrade add a default CA ACL that permits
certificate issuance for all hosts and services using the profile
'caIPAserviceCert' on the top-level CA.

Part of: https://fedorahosted.org/freeipa/ticket/57
Part of: https://fedorahosted.org/freeipa/ticket/4559
---
 ACI.txt   |  10 +
 API.txt   | 184 
 VERSION   |   4 +-
 install/share/60certificate-profiles.ldif |   5 +
 install/share/Makefile.am |   1 +
 install/share/bootstrap-template.ldif |   6 +
 install/share/default-caacl.ldif  |  11 +
 install/share/indices.ldif|  20 ++
 install/updates/20-indices.update |  18 ++
 install/updates/25-referint.update|   2 +
 install/updates/41-caacl.update   |   4 +
 install/updates/Makefile.am   |   1 +
 ipalib/constants.py   |   1 +
 ipalib/plugins/caacl.py   | 476 ++
 ipaserver/install/dsinstance.py   |   4 +
 ipaserver/install/server/upgrade.py   |  25 ++
 16 files changed, 770 insertions(+), 2 deletions(-)
 create mode 100644 install/share/default-caacl.ldif
 create mode 100644 install/updates/41-caacl.update
 create mode 100644 ipalib/plugins/caacl.py

diff --git a/ACI.txt b/ACI.txt
index 
59173ac1b593f15e079c7b1fce43ec9b0084ec91..bf63cb4caac09fb9d9697290e31afdee0a364882
 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -22,6 +22,16 @@ dn: cn=automount,dc=ipa,dc=example
 aci: (targetattr = "automountmapname || description")(targetfilter = 
"(objectclass=automountmap)")(version 3.0;acl "permission:System: Modify 
Automount Maps";allow (write) groupdn = "ldap:///cn=System: Modify Automount 
Maps,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=automount,dc=ipa,dc=example
 aci: (targetfilter =

Re: [Freeipa-devel] Community Portal Milestone

[Alexander Bokovoy]

On Wed, 10 Jun 2015, Adam Young wrote:

On 06/09/2015 04:44 PM, Alexander Bokovoy wrote:

On Tue, 09 Jun 2015, Drew Erny wrote:

Hey, Freeipa, same thread new subtopic.

So, I was bouncing some ideas around with another developer 
(ayoung) and I think I have a pretty good idea for self-service 
user registration.


The idea is that I put self-service user registration into its own 
application that calls out to ipa user-add after getting admin 
approval.


Workflow goes like this:

1.) User goes to registration page, inputs details into form. 
Registration page and application are not part of FreeIPA.
2.) User's registration goes into a non-FreeIPA database, 
something like SQLite.
3.) Admin gets a notification email with a link to approve/deny 
registration.
  A.) Admin clicks approval link, registration application (which 
has limited privileges) makes call out to ipa user-add command, 
adding the new user to FreeIPA.

  B.) Admin click deny link, user is not added.
4.) User's registration information, approved or denied, is 
deleted from the external database.


This has a couple of advantages. For starters, it provides a layer 
of protection against the creation of spam accounts. Accounts do 
not add directly to LDAP (inserting to LDAP is a slow operation), 
instead sit in intermediate area waiting approval. Second, we 
don't have to write a big extension to ipa user-add or 
staginguser-add that allows anonymous access to that command. 
Third, it can be bundled into its own package and given to the 
community separate from FreeIPA proper. Finally, it would allow me 
to gracefully defer becoming buried up to my neck in D-Bus 
notifications and whatever other fanciness we want to send email, 
because FreeIPA won't be sending the email.


Opinions?

Sounds good. For external application like your portal to be able to
call IPA CLI (or JSON) with Kerberos on behalf of an admin, you need to
support S4U2Proxy configuration. See
https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/
for details how to make it working. This would allow you to have an
application running on a separate IPA client and still be able to re-use
admin Kerberos credentials to perform the work after admin granted the
permission to create a user or to reset a password.
I don't think so;  S4U2Proxy would only make sense if the user does 
not have direct access.  I think that, with proper CORS support,  we 
could have the admin users authenticate the new users directly. Should 
be a simpler set up.

??? You would need admin to login into the community portal to approve
users. And you would then want to use admin credentials to connect to
IPA to actually create users/set passwords/etc. This is what S4U2Proxy
is for, not for the users themselves.

The users would not have direct access as the idea of the community
portal is to allow reset passwords and create additional users.

If you want to make it all accessible under a different account, you'd
need to add a number of permissions and it would quickly become
unmanageable. I see very little use in that.
--
/ Alexander Bokovoy

--
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 Milestone

[Adam Young]

On 06/09/2015 04:44 PM, Alexander Bokovoy wrote:

On Tue, 09 Jun 2015, Drew Erny wrote:

Hey, Freeipa, same thread new subtopic.

So, I was bouncing some ideas around with another developer (ayoung) 
and I think I have a pretty good idea for self-service user 
registration.


The idea is that I put self-service user registration into its own 
application that calls out to ipa user-add after getting admin approval.


Workflow goes like this:

1.) User goes to registration page, inputs details into form. 
Registration page and application are not part of FreeIPA.
2.) User's registration goes into a non-FreeIPA database, something 
like SQLite.
3.) Admin gets a notification email with a link to approve/deny 
registration.
   A.) Admin clicks approval link, registration application (which 
has limited privileges) makes call out to ipa user-add command, 
adding the new user to FreeIPA.

   B.) Admin click deny link, user is not added.
4.) User's registration information, approved or denied, is deleted 
from the external database.


This has a couple of advantages. For starters, it provides a layer of 
protection against the creation of spam accounts. Accounts do not add 
directly to LDAP (inserting to LDAP is a slow operation), instead sit 
in intermediate area waiting approval. Second, we don't have to write 
a big extension to ipa user-add or staginguser-add that allows 
anonymous access to that command. Third, it can be bundled into its 
own package and given to the community separate from FreeIPA proper. 
Finally, it would allow me to gracefully defer becoming buried up to 
my neck in D-Bus notifications and whatever other fanciness we want 
to send email, because FreeIPA won't be sending the email.


Opinions?

Sounds good. For external application like your portal to be able to
call IPA CLI (or JSON) with Kerberos on behalf of an admin, you need to
support S4U2Proxy configuration. See
https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/
for details how to make it working. This would allow you to have an
application running on a separate IPA client and still be able to re-use
admin Kerberos credentials to perform the work after admin granted the
permission to create a user or to reset a password.
I don't think so;  S4U2Proxy would only make sense if the user does not 
have direct access.  I think that, with proper CORS support,  we could 
have the admin users authenticate the new users directly. Should be a 
simpler set up.





See also
https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/
how to communicate to IPA with JSON directly, without any dependency to
IPA client tools.



--
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 Milestone

[Adam Young]

On 06/09/2015 06:34 PM, Simo Sorce wrote:

On Tue, 2015-06-09 at 16:15 -0400, Drew Erny wrote:

Hey, Freeipa, same thread new subtopic.

So, I was bouncing some ideas around with another developer (ayoung) and
I think I have a pretty good idea for self-service user registration.

The idea is that I put self-service user registration into its own
application that calls out to ipa user-add after getting admin approval.

Workflow goes like this:

1.) User goes to registration page, inputs details into form.
Registration page and application are not part of FreeIPA.
2.) User's registration goes into a non-FreeIPA database, something like
SQLite.
3.) Admin gets a notification email with a link to approve/deny
registration.
  A.) Admin clicks approval link, registration application (which has
limited privileges) makes call out to ipa user-add command, adding the
new user to FreeIPA.
  B.) Admin click deny link, user is not added.
4.) User's registration information, approved or denied, is deleted from
the external database.

This has a couple of advantages. For starters, it provides a layer of
protection against the creation of spam accounts. Accounts do not add
directly to LDAP (inserting to LDAP is a slow operation), instead sit in
intermediate area waiting approval. Second, we don't have to write a big
extension to ipa user-add or staginguser-add that allows anonymous
access to that command. Third, it can be bundled into its own package
and given to the community separate from FreeIPA proper. Finally, it
would allow me to gracefully defer becoming buried up to my neck in
D-Bus notifications and whatever other fanciness we want to send email,
because FreeIPA won't be sending the email.

Opinions?

You could avoid using an external database by using the new USer
Lifecycle management feature [1]. This will allow you to do a simple
ldapadd, but the user will not be enabled until an admin logs into the
FreeIPA interface to enable the user.
This manes your app never needs to see the admin's credentials or use
s4u2proxy and will pose a lower risk to the system.
The big issue was having an unauthentiucated user add o the datastore;  
I don't think you want to push new values directly into LDAP.  A 
separate Databse makes a lot of sense, and using SQLite for a proof of 
concept allows us to migrate up to MySQL for a live deployment.


I don't think S4U2Proxy is necessary.  A client app with permission to 
read from the registration app could use the users own credentials to 
push to the IPA server.   This could be done in a a web app with CORS 
support as well.






Simo.

[1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management




--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [PATCH] Use Exception class instead of StandardError

[Niranjan]

Niranjan wrote:
Greetings,

Please find the modified patch for ipapython/adminutil.py. 

I have run few tests manually like running ipa-server-install
as non-root user or provide --quiet and --verbose  to see 
if it raises ScriptError properly. 

Also i checked by running ipa-server-install and using CTRL-C
to break and see if the KeyboardInterrupt is properly caught. 

Please let me know your views on this.

Regards
Niranjan




> Niranjan wrote:
> > Greetings,
> > 
> > I would like to present patch for replacing StandardError exception
> > with Exception class in ipapython/adminutil.py. Also replacing
> > BaseException class with Exception class. 
> > 
> > Though the use of StandardError is many places. I would like to start
> > with ipapython/adminutil.py
> > 
> > This is my first patch. Please let me know if my approach on this is 
> > correct.
> Could anyone have a look at this please. 
> > 
> > Regards
> > Niranjan
> 
> > From 018312f76952ea86c8c6e2396657e0531d2d61ba Mon Sep 17 00:00:00 2001
> > From: Niranjan Mallapadi 
> > Date: Mon, 1 Jun 2015 09:41:05 +0530
> > Subject: [PATCH] Use Exception class instead of BaseException
> > 
> > 1. Replace BaseException with Exception class.
> > 2. Remove StandardError and use Exception class. StandError is deprecated 
> > (Python3)
> > 3 .From python3.0 use of , is not recommended, instead
> > use "as" keyword (PEP 3110)
> > 
> > Signed-off-by: Niranjan Mallapadi 
> > ---
> >  ipapython/admintool.py | 11 +--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> > 
> > diff --git a/ipapython/admintool.py b/ipapython/admintool.py
> > index 
> > d55bd18499ac427db8adc0c04096bc2aabdc2bbd..891232b9f387182ac5dbfb279a6f666805261ba1
> >  100644
> > --- a/ipapython/admintool.py
> > +++ b/ipapython/admintool.py
> > @@ -32,7 +32,7 @@ from ipapython import config
> >  from ipapython import ipa_log_manager
> >  
> >  
> > -class ScriptError(StandardError):
> > +class ScriptError(Exception):
> >  """An exception that records an error message and a return value
> >  """
> >  def __init__(self, msg='', rval=1):
> > @@ -169,13 +169,20 @@ class AdminTool(object):
> >  self.ask_for_options()
> >  self.setup_logging()
> >  return_value = self.run()
> > -except BaseException, exception:
> > +except Exception as exception:
> >  traceback = sys.exc_info()[2]
> >  error_message, return_value = self.handle_error(exception)
> >  if return_value:
> >  self.log_failure(error_message, return_value, exception,
> >  traceback)
> >  return return_value
> > +except SystemExit as exception:
> > +traceback = sys.exc_info()[2]
> > +error_message, return_value = self.handle_error(exception)
> > +if return_value:
> > +self.log_failure(error_message, return_value, exception,
> > +traceback)
> > +return return_value
> >  self.log_success()
> >  return return_value
> >  
> > -- 
> > 1.9.3
> > 
> 
> 
> > Removed an attachment of 322 bytes with the following headers:
> > 
> > Content-Type: application/pgp-signature
> 
> > -- 
> > 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
> 



> -- 
> 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

From aa74dad193a42b8d7ea1715391c461bcbad888b4 Mon Sep 17 00:00:00 2001
From: Niranjan Mallapadi 
Date: Wed, 10 Jun 2015 04:19:46 +0530
Subject: [PATCH] Use Exception class instead of StandardError

In except clause, use of "," is not recommended (PEP 3110)

Signed-off-by: Niranjan Mallapadi 
---
 ipapython/admintool.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ipapython/admintool.py b/ipapython/admintool.py
index 
d55bd18499ac427db8adc0c04096bc2aabdc2bbd..5aa1c19bb70f9d9049130d1e2a253abb4b86677b
 100644
--- a/ipapython/admintool.py
+++ b/ipapython/admintool.py
@@ -32,7 +32,7 @@ from ipapython import config
 from ipapython import ipa_log_manager
 
 
-class ScriptError(StandardError):
+class ScriptError(Exception):
 """An exception that records an error message and a return value
 """
 def __init__(self, msg='', rval=1):
@@ -169,7 +169,7 @@ class AdminTool(object):
 self.ask_for_options()
 self.setup_logging()
 return_value = self.run()
-except BaseException, exception:
+except BaseException as exception:
 traceback = sys.exc_info()[2]
 error_message, return_value = self.handle_error(exception)
 if return_value:
-- 
1.9.3



pgpBEOA6w7AWI.pgp
Description: PGP signature
-- 
Manage your subscription

Re: [Freeipa-devel] Community Portal Milestone

[Simo Sorce]

On Tue, 2015-06-09 at 16:15 -0400, Drew Erny wrote:
> Hey, Freeipa, same thread new subtopic.
> 
> So, I was bouncing some ideas around with another developer (ayoung) and 
> I think I have a pretty good idea for self-service user registration.
> 
> The idea is that I put self-service user registration into its own 
> application that calls out to ipa user-add after getting admin approval.
> 
> Workflow goes like this:
> 
> 1.) User goes to registration page, inputs details into form. 
> Registration page and application are not part of FreeIPA.
> 2.) User's registration goes into a non-FreeIPA database, something like 
> SQLite.
> 3.) Admin gets a notification email with a link to approve/deny 
> registration.
>  A.) Admin clicks approval link, registration application (which has 
> limited privileges) makes call out to ipa user-add command, adding the 
> new user to FreeIPA.
>  B.) Admin click deny link, user is not added.
> 4.) User's registration information, approved or denied, is deleted from 
> the external database.
> 
> This has a couple of advantages. For starters, it provides a layer of 
> protection against the creation of spam accounts. Accounts do not add 
> directly to LDAP (inserting to LDAP is a slow operation), instead sit in 
> intermediate area waiting approval. Second, we don't have to write a big 
> extension to ipa user-add or staginguser-add that allows anonymous 
> access to that command. Third, it can be bundled into its own package 
> and given to the community separate from FreeIPA proper. Finally, it 
> would allow me to gracefully defer becoming buried up to my neck in 
> D-Bus notifications and whatever other fanciness we want to send email, 
> because FreeIPA won't be sending the email.
> 
> Opinions?

You could avoid using an external database by using the new USer
Lifecycle management feature [1]. This will allow you to do a simple
ldapadd, but the user will not be enabled until an admin logs into the
FreeIPA interface to enable the user.
This manes your app never needs to see the admin's credentials or use
s4u2proxy and will pose a lower risk to the system.

Simo.

[1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management


-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] Password vault

[Endi Sukma Dewata]

Please take a look at the attached patch to add symmetric & asymmetric 
vaults. Some comments about the patch:


1. The vault_add was split into a client-side vault_add and server-side 
vault_add_internal since the parameters are different (i.e. public key 
file and future escrow-related params). Since vault_add inherits from 
Local all non-primary-key attributes have to be added explicitly.


2. Since the vault_archive_internal inherits from Update, it accepts all 
non primary-key attributes automatically. This is incorrect since we 
don't want to update these parameters during archival. Can this behavior 
be overridden?


--
Endi S. Dewata
>From 9cc5b1a22c4545124a13e73343db598d6fb58b2c Mon Sep 17 00:00:00 2001
From: "Endi S. Dewata" 
Date: Fri, 24 Oct 2014 19:53:16 -0400
Subject: [PATCH] Added symmetric and asymmetric vaults.

The vault plugin has been modified to support symmetric and asymmetric
vaults to provide additional security over the standard vault by
encrypting the data before it's sent to the server. The encryption
functionality is implemented using the python-cryptography library.

https://fedorahosted.org/freeipa/ticket/3872
---
 API.txt   |  52 ++-
 VERSION   |   4 +-
 freeipa.spec.in   |   2 +
 install/share/60basev3.ldif   |   4 +-
 ipalib/plugins/vault.py   | 507 +++---
 ipatests/test_xmlrpc/test_vault_plugin.py | 218 +++--
 6 files changed, 717 insertions(+), 70 deletions(-)

diff --git a/API.txt b/API.txt
index 
9e3f223b7ac338840d7090299f9108e951ea920a..2ce57fb09293bf3cf1f82f4d0bf4e93b30e0fd60
 100644
--- a/API.txt
+++ b/API.txt
@@ -5132,14 +5132,33 @@ output: Output('result', , None)
 output: Output('summary', (, ), None)
 output: PrimaryKey('value', None, None)
 command: vault_add
-args: 1,9,3
+args: 1,12,3
+arg: Str('cn', attribute=True, cli_name='name', maxlength=255, 
multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, 
required=True)
+option: Str('addattr*', cli_name='addattr', exclude='webui')
+option: Flag('all', autofill=True, cli_name='all', default=False, 
exclude='webui')
+option: Str('description?', cli_name='desc')
+option: Bytes('ipapublickey?', cli_name='public_key')
+option: Str('ipavaulttype?', cli_name='type')
+option: Str('public_key_file?', cli_name='public_key_file')
+option: Flag('raw', autofill=True, cli_name='raw', default=False, 
exclude='webui')
+option: Str('service?')
+option: Str('setattr*', cli_name='setattr', exclude='webui')
+option: Flag('shared?', autofill=True, default=False)
+option: Str('user?')
+option: Str('version?', exclude='webui')
+output: Entry('result', , Gettext('A dictionary representing an 
LDAP entry', domain='ipa', localedir=None))
+output: Output('summary', (, ), None)
+output: PrimaryKey('value', None, None)
+command: vault_add_internal
+args: 1,10,3
 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, 
multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, required=True)
-option: Str('addattr*', cli_name='addattr', exclude='webui')
 option: Flag('all', autofill=True, cli_name='all', default=False, 
exclude='webui')
 option: Str('description', attribute=True, cli_name='desc', multivalue=False, 
required=False)
+option: Bytes('ipapublickey', attribute=True, cli_name='public_key', 
multivalue=False, required=False)
+option: Bytes('ipavaultsalt', attribute=True, cli_name='salt', 
multivalue=False, required=False)
+option: Str('ipavaulttype', attribute=True, autofill=True, cli_name='type', 
default=u'standard', multivalue=False, required=False)
 option: Flag('raw', autofill=True, cli_name='raw', default=False, 
exclude='webui')
 option: Str('service?')
-option: Str('setattr*', cli_name='setattr', exclude='webui')
 option: Flag('shared?', autofill=True, default=False)
 option: Str('user?')
 option: Str('version?', exclude='webui')
@@ -5147,11 +5166,13 @@ output: Entry('result', , Gettext('A 
dictionary representing an LDA
 output: Output('summary', (, ), None)
 output: PrimaryKey('value', None, None)
 command: vault_archive
-args: 1,8,3
+args: 1,10,3
 arg: Str('cn', attribute=True, cli_name='name', maxlength=255, 
multivalue=False, pattern='^[a-zA-Z0-9_.-]+$', primary_key=True, query=True, 
required=True)
 option: Flag('all', autofill=True, cli_name='all', default=False, 
exclude='webui')
 option: Bytes('data?')
 option: Str('in?')
+option: Str('password?', cli_name='password')
+option: Str('password_file?', cli_name='password_file')
 option: Flag('raw', autofill=True, cli_name='raw', default=False, 
exclude='webui')
 option: Str('service?')
 option: Flag('shared?', autofill=True, default=False)
@@ -5160,11 +5181,14 @@ option: Str('version?', exclude='webui')
 output: Entry('result', , Gettext('A dictionary representing an 
LDAP entry', domain='ipa', localedir=None))
 output: Output('summary', (, ), None)
 output: PrimaryKey('value', None, None)
-c

Re: [Freeipa-devel] Community Portal Milestone

[Alexander Bokovoy]

On Tue, 09 Jun 2015, Drew Erny wrote:

Hey, Freeipa, same thread new subtopic.

So, I was bouncing some ideas around with another developer (ayoung) 
and I think I have a pretty good idea for self-service user 
registration.


The idea is that I put self-service user registration into its own 
application that calls out to ipa user-add after getting admin 
approval.


Workflow goes like this:

1.) User goes to registration page, inputs details into form. 
Registration page and application are not part of FreeIPA.
2.) User's registration goes into a non-FreeIPA database, something 
like SQLite.
3.) Admin gets a notification email with a link to approve/deny 
registration.
   A.) Admin clicks approval link, registration application (which 
has limited privileges) makes call out to ipa user-add command, adding 
the new user to FreeIPA.

   B.) Admin click deny link, user is not added.
4.) User's registration information, approved or denied, is deleted 
from the external database.


This has a couple of advantages. For starters, it provides a layer of 
protection against the creation of spam accounts. Accounts do not add 
directly to LDAP (inserting to LDAP is a slow operation), instead sit 
in intermediate area waiting approval. Second, we don't have to write 
a big extension to ipa user-add or staginguser-add that allows 
anonymous access to that command. Third, it can be bundled into its 
own package and given to the community separate from FreeIPA proper. 
Finally, it would allow me to gracefully defer becoming buried up to 
my neck in D-Bus notifications and whatever other fanciness we want to 
send email, because FreeIPA won't be sending the email.


Opinions?

Sounds good. For external application like your portal to be able to
call IPA CLI (or JSON) with Kerberos on behalf of an admin, you need to
support S4U2Proxy configuration. See
https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/
for details how to make it working. This would allow you to have an
application running on a separate IPA client and still be able to re-use
admin Kerberos credentials to perform the work after admin granted the
permission to create a user or to reset a password.

See also
https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/
how to communicate to IPA with JSON directly, without any dependency to
IPA client tools.

--
/ Alexander Bokovoy

--
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 Milestone

[Drew Erny]

Hey, Freeipa, same thread new subtopic.

So, I was bouncing some ideas around with another developer (ayoung) and 
I think I have a pretty good idea for self-service user registration.


The idea is that I put self-service user registration into its own 
application that calls out to ipa user-add after getting admin approval.


Workflow goes like this:

1.) User goes to registration page, inputs details into form. 
Registration page and application are not part of FreeIPA.
2.) User's registration goes into a non-FreeIPA database, something like 
SQLite.
3.) Admin gets a notification email with a link to approve/deny 
registration.
A.) Admin clicks approval link, registration application (which has 
limited privileges) makes call out to ipa user-add command, adding the 
new user to FreeIPA.

B.) Admin click deny link, user is not added.
4.) User's registration information, approved or denied, is deleted from 
the external database.


This has a couple of advantages. For starters, it provides a layer of 
protection against the creation of spam accounts. Accounts do not add 
directly to LDAP (inserting to LDAP is a slow operation), instead sit in 
intermediate area waiting approval. Second, we don't have to write a big 
extension to ipa user-add or staginguser-add that allows anonymous 
access to that command. Third, it can be bundled into its own package 
and given to the community separate from FreeIPA proper. Finally, it 
would allow me to gracefully defer becoming buried up to my neck in 
D-Bus notifications and whatever other fanciness we want to send email, 
because FreeIPA won't be sending the email.


Opinions?

--
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] topology issues

[Oleg Fayans]

On 06/09/2015 05:32 PM, Ludwig Krispenz wrote:

Hi Oleg,
thanks for access to your machine, the replication agreements are 
still there - and that is expected since the server was not removed.


In the access log I see:

[09/Jun/2015:08:32:42 -0400] conn=150 op=52 SRCH 
base="cn=f22replica1.bagam.net,cn=masters,cn=ipa,cn=etc,dc=bagam,dc=net" 
scope=2 filter="(objectClass=*)" attrs=ALL
[09/Jun/2015:08:32:42 -0400] conn=150 op=52 RESULT err=0 tag=101 
nentries=8 etime=0 notes=U
[09/Jun/2015:08:32:42 -0400] conn=150 op=53 DEL 
dn="cn=KDC,cn=f22replica1.bagam.net,cn=masters,cn=ipa,cn=etc,dc=bagam,dc=net"
[09/Jun/2015:08:32:42 -0400] conn=150 op=53 RESULT err=0 tag=107 
nentries=0 etime=0 csn=5576dceb00060004
[09/Jun/2015:08:32:42 -0400] conn=150 op=54 DEL 
dn="cn=KPASSWD,cn=f22replica1.bagam.net,cn=masters,cn=ipa,cn=etc,dc=bagam,dc=net"
[09/Jun/2015:08:32:42 -0400] conn=150 op=54 RESULT err=0 tag=107 
nentries=0 etime=0 csn=5576dceb00070004
[09/Jun/2015:08:32:42 -0400] conn=150 op=55 DEL 
dn="cn=MEMCACHE,cn=f22replica1.bagam.net,cn=masters,cn=ipa,cn=etc,dc=bagam,dc=net"
[09/Jun/2015:08:32:43 -0400] conn=150 op=55 RESULT err=0 tag=107 
nentries=0 etime=1 csn=5576dcec00010004

[09/Jun/2015:08:32:43 -0400] conn=150 op=56 UNBIND

the search for cn=f22replica1.bagam.net,cn=masters, returns 8 
entries, which then should be deleted, but only 3 ae deleted and the
cn=f22replica1.bagam.net,cn=masters,... entry is not deleted, so the 
topology segments are not deleted, and the agreement is not removed.


I don't know why ipa-replica-manage del does stop deleting services 
and the master entry
You are welcome. This issue get reproduced regularly, so It is hardly an 
accidental disconnect.




On 06/09/2015 04:25 PM, Oleg Fayans wrote:



On 06/09/2015 04:19 PM, Ludwig Krispenz wrote:


On 06/09/2015 04:14 PM, Oleg Fayans wrote:



On 06/09/2015 04:04 PM, Ludwig Krispenz wrote:


On 06/09/2015 03:55 PM, Oleg Fayans wrote:

Hi everybody,

The current status of Topology plugin testing is as follows:

1. There is still no proper way of removing the replica.
Standard procedure using `ipa-replica-manage del` throws "Server 
is unwilling to perform: Entry is managed by topology 
plugin.Deletion not allowed.". 
yes, that is for the first attempt to directly remove the 
agreement, but when the server is removed the agreements should be 
removed
We should probably think of less threatening error message in this 
case. Just from reading the command output one might conclude that 
replica removal failed.
The replication agreement though does get deleted, 

then it is ok,
but the topology information does not get updated. 
what do you mean, where do you check ? in the "remaining" topology 
the shared tree should be updated, for the removed replica it will 
not, but this should be uninstalled anyway
The problem here, is that the topology information does not get 
updated on master as well.
could you be a bit more precise. what do you still see ? the 
agreement will be only removed if the segment is removed, and this 
should be reoplicated to all severs in the remaining topology - if 
you don't disconnect it by removing the replica.
and what was the topology structure and which replica did you 
remove, on which server did you remove it?
So,  Here is the results of the `topologysegment-find` command before 
replica removal:

root@f22master:/var/log/dirsrv/slapd-BAGAM-NET]$ ipa topologysegment-find
Suffix name: realm
--
2 segments matched
--
  Segment name: f22master.bagam.net-to-f22replica1.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica1.bagam.net
  Connectivity: both

  Segment name: f22master.bagam.net-to-f22replica2.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica2.bagam.net
  Connectivity: both

Number of entries returned 2

Then, after issuing `ipa-replica-manage-del f2replica1.bagam.net 
--force` on the master, the same command on master still shows 
exactly the same topology:


root@f22master:/var/log/dirsrv/slapd-BAGAM-NET]$ ipa topologysegment-find
Suffix name: realm
--
2 segments matched
--
  Segment name: f22master.bagam.net-to-f22replica1.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica1.bagam.net
  Connectivity: both

  Segment name: f22master.bagam.net-to-f22replica2.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica2.bagam.net
  Connectivity: both

Number of entries returned 2


When I then issue `ipa topologysegment-del`, it fails due to 
"ipa: ERROR: Server is unwilling to perform: Removal of Segment 
disconnects topology.Deletion not allowed."

correct, you can only do it after removal of the server
I do not get it. Master still thinks it has the replica, it 
displays it both in CLI using `ipa topologysegment-find` and in the 
web-ui. (although it does n

Re: [Freeipa-devel] topology issues

[Ludwig Krispenz]

Hi Oleg,
thanks for access to your machine, the replication agreements are still 
there - and that is expected since the server was not removed.


In the access log I see:

[09/Jun/2015:08:32:42 -0400] conn=150 op=52 SRCH 
base="cn=f22replica1.bagam.net,cn=masters,cn=ipa,cn=etc,dc=bagam,dc=net" 
scope=2 filter="(objectClass=*)" attrs=ALL
[09/Jun/2015:08:32:42 -0400] conn=150 op=52 RESULT err=0 tag=101 
nentries=8 etime=0 notes=U
[09/Jun/2015:08:32:42 -0400] conn=150 op=53 DEL 
dn="cn=KDC,cn=f22replica1.bagam.net,cn=masters,cn=ipa,cn=etc,dc=bagam,dc=net"
[09/Jun/2015:08:32:42 -0400] conn=150 op=53 RESULT err=0 tag=107 
nentries=0 etime=0 csn=5576dceb00060004
[09/Jun/2015:08:32:42 -0400] conn=150 op=54 DEL 
dn="cn=KPASSWD,cn=f22replica1.bagam.net,cn=masters,cn=ipa,cn=etc,dc=bagam,dc=net"
[09/Jun/2015:08:32:42 -0400] conn=150 op=54 RESULT err=0 tag=107 
nentries=0 etime=0 csn=5576dceb00070004
[09/Jun/2015:08:32:42 -0400] conn=150 op=55 DEL 
dn="cn=MEMCACHE,cn=f22replica1.bagam.net,cn=masters,cn=ipa,cn=etc,dc=bagam,dc=net"
[09/Jun/2015:08:32:43 -0400] conn=150 op=55 RESULT err=0 tag=107 
nentries=0 etime=1 csn=5576dcec00010004

[09/Jun/2015:08:32:43 -0400] conn=150 op=56 UNBIND

the search for cn=f22replica1.bagam.net,cn=masters, returns 8 
entries, which then should be deleted, but only 3 ae deleted and the
cn=f22replica1.bagam.net,cn=masters,... entry is not deleted, so the 
topology segments are not deleted, and the agreement is not removed.


I don't know why ipa-replica-manage del does stop deleting services and 
the master entry




On 06/09/2015 04:25 PM, Oleg Fayans wrote:



On 06/09/2015 04:19 PM, Ludwig Krispenz wrote:


On 06/09/2015 04:14 PM, Oleg Fayans wrote:



On 06/09/2015 04:04 PM, Ludwig Krispenz wrote:


On 06/09/2015 03:55 PM, Oleg Fayans wrote:

Hi everybody,

The current status of Topology plugin testing is as follows:

1. There is still no proper way of removing the replica.
Standard procedure using `ipa-replica-manage del` throws "Server 
is unwilling to perform: Entry is managed by topology 
plugin.Deletion not allowed.". 
yes, that is for the first attempt to directly remove the 
agreement, but when the server is removed the agreements should be 
removed
We should probably think of less threatening error message in this 
case. Just from reading the command output one might conclude that 
replica removal failed.
The replication agreement though does get deleted, 

then it is ok,
but the topology information does not get updated. 
what do you mean, where do you check ? in the "remaining" topology 
the shared tree should be updated, for the removed replica it will 
not, but this should be uninstalled anyway
The problem here, is that the topology information does not get 
updated on master as well.
could you be a bit more precise. what do you still see ? the 
agreement will be only removed if the segment is removed, and this 
should be reoplicated to all severs in the remaining topology - if 
you don't disconnect it by removing the replica.
and what was the topology structure and which replica did you remove, 
on which server did you remove it?
So,  Here is the results of the `topologysegment-find` command before 
replica removal:

root@f22master:/var/log/dirsrv/slapd-BAGAM-NET]$ ipa topologysegment-find
Suffix name: realm
--
2 segments matched
--
  Segment name: f22master.bagam.net-to-f22replica1.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica1.bagam.net
  Connectivity: both

  Segment name: f22master.bagam.net-to-f22replica2.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica2.bagam.net
  Connectivity: both

Number of entries returned 2

Then, after issuing `ipa-replica-manage-del f2replica1.bagam.net 
--force` on the master, the same command on master still shows exactly 
the same topology:


root@f22master:/var/log/dirsrv/slapd-BAGAM-NET]$ ipa topologysegment-find
Suffix name: realm
--
2 segments matched
--
  Segment name: f22master.bagam.net-to-f22replica1.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica1.bagam.net
  Connectivity: both

  Segment name: f22master.bagam.net-to-f22replica2.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica2.bagam.net
  Connectivity: both

Number of entries returned 2


When I then issue `ipa topologysegment-del`, it fails due to "ipa: 
ERROR: Server is unwilling to perform: Removal of Segment 
disconnects topology.Deletion not allowed."

correct, you can only do it after removal of the server
I do not get it. Master still thinks it has the replica, it displays 
it both in CLI using `ipa topologysegment-find` and in the web-ui. 
(although it does not show it using `ipa host-find`, which is 
correct), and there is no way to manually make it change it's mind?


I tried to disable the segment fi

[Freeipa-devel] [PATCH 0051] Use 389-ds centralized scripts.

[David Kupka]

https://fedorahosted.org/freeipa/ticket/4051
--
David Kupka
From da898ff6fbe760ff6786763297ecbf31bf10d300 Mon Sep 17 00:00:00 2001
From: David Kupka 
Date: Wed, 1 Apr 2015 11:27:36 -0400
Subject: [PATCH] Use 389-ds centralized scripts.

Directory server is deprecating use of tools in instance specific paths. Instead
tools in bin/sbin path should be used.

https://fedorahosted.org/freeipa/ticket/4051
---
 ipaplatform/base/paths.py|  4 
 ipaserver/install/ipa_backup.py  |  5 +++--
 ipaserver/install/ipa_restore.py | 11 +--
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py
index 9ba87523b5619188f02bdad6c23d2446a2c4b0f2..6c0dd2bb458a87d523b60983a05479371a6b8d71 100644
--- a/ipaplatform/base/paths.py
+++ b/ipaplatform/base/paths.py
@@ -337,6 +337,10 @@ class BasePathNamespace(object):
 ALL_SLAPD_INSTANCE_SOCKETS = "/var/run/slapd-*.socket"
 ADMIN_CERT_PATH = '/root/.dogtag/pki-tomcat/ca_admin.cert'
 ENTROPY_AVAIL = '/proc/sys/kernel/random/entropy_avail'
+LDIF2DB = '/usr/sbin/ldif2db'
+DB2LDIF = '/usr/sbin/db2ldif'
+BAK2DB = '/usr/sbin/bak2db'
+DB2BAK = '/usr/sbin/db2bak'
 
 
 
diff --git a/ipaserver/install/ipa_backup.py b/ipaserver/install/ipa_backup.py
index c3611b241d4818bc718d8bcd83da8d3c1755457e..01871c7b57a3e491cebf8fe81f040268992f1ada 100644
--- a/ipaserver/install/ipa_backup.py
+++ b/ipaserver/install/ipa_backup.py
@@ -417,7 +417,8 @@ class Backup(admintool.AdminTool):
 self.log.info("Waiting for LDIF to finish")
 wait_for_task(conn, dn)
 else:
-args = ['%s/db2ldif' % self.__find_scripts_dir(instance),
+args = [paths.DB2LDIF,
+'-Z', instance,
 '-r',
 '-n', backend,
 '-a', ldiffile]
@@ -464,7 +465,7 @@ class Backup(admintool.AdminTool):
 self.log.info("Waiting for BAK to finish")
 wait_for_task(conn, dn)
 else:
-args = ['%s/db2bak' % self.__find_scripts_dir(instance), bakdir]
+args = [paths.DB2BAK, bakdir, '-Z', instance]
 (stdout, stderr, rc) = run(args, raiseonerr=False)
 if rc != 0:
 self.log.critical("db2bak failed: %s" % stderr)
diff --git a/ipaserver/install/ipa_restore.py b/ipaserver/install/ipa_restore.py
index 56d31376570fc4e1ce9046ff8d323e2cc49e0c9e..528a6daf0d4b6d3dfc69b6bbf8e8b05ad91ce02d 100644
--- a/ipaserver/install/ipa_restore.py
+++ b/ipaserver/install/ipa_restore.py
@@ -544,7 +544,13 @@ class Restore(admintool.AdminTool):
 self.log.info("Waiting for LDIF to finish")
 wait_for_task(conn, dn)
 else:
-args = ['%s/ldif2db' % self.__find_scripts_dir(instance),
+try:
+os.makedirs(paths.VAR_LOG_DIRSRV_INSTANCE_TEMPLATE % instance)
+except OSError as e:
+pass
+
+args = [paths.LDIF2DB,
+'-Z', instance,
 '-i', ldiffile,
 '-n', backend]
 (stdout, stderr, rc) = run(args, raiseonerr=False)
@@ -596,7 +602,8 @@ class Restore(admintool.AdminTool):
 self.log.info("Waiting for restore to finish")
 wait_for_task(conn, dn)
 else:
-args = ['%s/bak2db' % self.__find_scripts_dir(instance),
+args = [paths.BAK2DB,
+'-Z', instance,
 os.path.join(self.dir, instance)]
 if backend is not None:
 args.append('-n')
-- 
2.4.2

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 00012-0013 v7] Profiles and CA ACLs

[Martin Basti]

On 09/06/15 08:58, Fraser Tweedale wrote:

On Mon, Jun 08, 2015 at 08:49:06AM +0200, Martin Kosek wrote:

On 06/08/2015 03:31 AM, Fraser Tweedale wrote:

New patches attached.  Comments inline.

Thanks Fraser!

...

5)
Missing referint plugin configuration for attribute
'ipacaaclmembercertprofile'
Please add it into install/updates/25-referint.update (+ other member
attributes if missing)


Added this.  There is a comment in 25-referint.update:

 # pres and eq indexes defined in 20-indices.update must be set
 # for all the attributes

Can you explain what is required here?  Is it just to add: I see
things for memberUser and memberHost in indices.ldif but nothing for
memberService.  Do I need to add to indices.ldif:

 dn: cn=memberProfile,cn=index,cn=userRoot,cn=ldbm 
database,cn=plugins,cn=config
 changetype: add
 cn: memberProfile
 ObjectClass: top
 ObjectClass: nsIndex
 nsSystemIndex: false
 nsIndexType: eq
 nsIndexType: pres
 nsIndexType: sub

, and similarly for memberCa?  Sorry I do not know much about LDAP
indexing.

AFAIR, yes. BTW, where does the "sub" index come from? It is quite an expensive
index to use and I now cannot think of memberProfile search where you would
need a substring...

Thanks,
Martin

Updated patch attached, which adds the indices.  (Also rebased).

There is a commit that seems to indicate that substring index is
needed, so I have included substring indices in this patchset.
Copied Honza in case he wants to comment.

 commit a10521a1dcf69960d6ce0bf5657180b709c297c0
 Author: Jan Cholasta 
 Date:   Tue Jun 25 13:16:40 2013 +

 Add missing substring indices for attributes managed by the referint 
plugin.

 The referint plugin does a substring search on these attributes each 
time an
 entry is deleted, which causes a noticable slowdown for large 
directories if
 the attributes are not indexed.

 https://fedorahosted.org/freeipa/ticket/3706

Cheers,
Fraser

ACK

Please send the upgrade patch ASAP :)

--
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] topology issues

[Ludwig Krispenz]

On 06/09/2015 04:25 PM, Oleg Fayans wrote:



On 06/09/2015 04:19 PM, Ludwig Krispenz wrote:


On 06/09/2015 04:14 PM, Oleg Fayans wrote:



On 06/09/2015 04:04 PM, Ludwig Krispenz wrote:


On 06/09/2015 03:55 PM, Oleg Fayans wrote:

Hi everybody,

The current status of Topology plugin testing is as follows:

1. There is still no proper way of removing the replica.
Standard procedure using `ipa-replica-manage del` throws "Server 
is unwilling to perform: Entry is managed by topology 
plugin.Deletion not allowed.". 
yes, that is for the first attempt to directly remove the 
agreement, but when the server is removed the agreements should be 
removed
We should probably think of less threatening error message in this 
case. Just from reading the command output one might conclude that 
replica removal failed.
The replication agreement though does get deleted, 

then it is ok,
but the topology information does not get updated. 
what do you mean, where do you check ? in the "remaining" topology 
the shared tree should be updated, for the removed replica it will 
not, but this should be uninstalled anyway
The problem here, is that the topology information does not get 
updated on master as well.
could you be a bit more precise. what do you still see ? the 
agreement will be only removed if the segment is removed, and this 
should be reoplicated to all severs in the remaining topology - if 
you don't disconnect it by removing the replica.
and what was the topology structure and which replica did you remove, 
on which server did you remove it?
So,  Here is the results of the `topologysegment-find` command before 
replica removal:

root@f22master:/var/log/dirsrv/slapd-BAGAM-NET]$ ipa topologysegment-find
Suffix name: realm
--
2 segments matched
--
  Segment name: f22master.bagam.net-to-f22replica1.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica1.bagam.net
  Connectivity: both

  Segment name: f22master.bagam.net-to-f22replica2.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica2.bagam.net
  Connectivity: both

Number of entries returned 2

Then, after issuing `ipa-replica-manage-del f2replica1.bagam.net 
--force` on the master, the same command on master still shows exactly 
the same topology:


root@f22master:/var/log/dirsrv/slapd-BAGAM-NET]$ ipa topologysegment-find
Suffix name: realm
--
2 segments matched
--
  Segment name: f22master.bagam.net-to-f22replica1.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica1.bagam.net
  Connectivity: both

  Segment name: f22master.bagam.net-to-f22replica2.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica2.bagam.net
  Connectivity: both

Number of entries returned 2

that's weird if the agreement is removed, the removal of the agreement 
is only done in the postop of the removal of the segment.

do you have the access and error logs for the master ?


When I then issue `ipa topologysegment-del`, it fails due to "ipa: 
ERROR: Server is unwilling to perform: Removal of Segment 
disconnects topology.Deletion not allowed."

correct, you can only do it after removal of the server
I do not get it. Master still thinks it has the replica, it displays 
it both in CLI using `ipa topologysegment-find` and in the web-ui. 
(although it does not show it using `ipa host-find`, which is 
correct), and there is no way to manually make it change it's mind?


I tried to disable the segment first and then delete it, but with 
the segment properly disabled, the attempt to delete it raised a 
GSS error: "ipa: ERROR: Kerberos error: Kerberos error: 
('Unspecified GSS failure.  Minor code may provide more 
information', 851968)/('KDC returned error string: PROCESS_TGS', 
-1765328324)/". I am not sure, where to search for corresponding 
logs. The session transcript is attached.


2. The following is probably unrelated to the topology plugin:
I installed a replica with --setup-ca option. Then, on this 
replica tried to prepare another replica:
- 

root@f22replica2:/home/ofayans/f22]$ ipa-replica-prepare 
--ip-address 192.168.122.141 f22replica3.bagam.net

Directory Manager (existing master) password:

Preparing replica for f22replica3.bagam.net from 
f22replica2.bagam.net

Creating SSL certificate for the Directory Server
Certificate issuance failed
- 


The corresponding line in the dirsrv log:
[09/Jun/2015:09:54:46 -0400] - Entry "uid=admin,ou=people,o=ipaca" 
-- attribute "krbExtraData" not allowed










--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.








--
Oleg

Re: [Freeipa-devel] topology issues

[Oleg Fayans]

Simo, yep, I entered the name manually when writing this letter

On 06/09/2015 04:28 PM, Simo Sorce wrote:

On Tue, 2015-06-09 at 16:25 +0200, Oleg Fayans wrote:

Then, after issuing `ipa-replica-manage-del f2replica1.bagam.net

Is this a copy and paste error or the command you actually used ?
(replica name is wrong).

Simo.



--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.

--
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] #5056: Rename topologysegment-refresh to topologysegment-reinitialize

[Martin Kosek]

FYI, as mentioned on today conversation, I filed the ticket to rename
topologysegment-refresh to topologysegment-reinitialize:

https://fedorahosted.org/freeipa/ticket/5056

If there are any objections, please shout. If not, Petr - you know what to do...

-- 
Martin Kosek 
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.

-- 
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] topology issues

[Simo Sorce]

On Tue, 2015-06-09 at 16:25 +0200, Oleg Fayans wrote:
> Then, after issuing `ipa-replica-manage-del f2replica1.bagam.net 

Is this a copy and paste error or the command you actually used ?
(replica name is wrong).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] topology issues

[Oleg Fayans]

On 06/09/2015 04:19 PM, Ludwig Krispenz wrote:


On 06/09/2015 04:14 PM, Oleg Fayans wrote:



On 06/09/2015 04:04 PM, Ludwig Krispenz wrote:


On 06/09/2015 03:55 PM, Oleg Fayans wrote:

Hi everybody,

The current status of Topology plugin testing is as follows:

1. There is still no proper way of removing the replica.
Standard procedure using `ipa-replica-manage del` throws "Server is 
unwilling to perform: Entry is managed by topology plugin.Deletion 
not allowed.". 
yes, that is for the first attempt to directly remove the agreement, 
but when the server is removed the agreements should be removed
We should probably think of less threatening error message in this 
case. Just from reading the command output one might conclude that 
replica removal failed.
The replication agreement though does get deleted, 

then it is ok,
but the topology information does not get updated. 
what do you mean, where do you check ? in the "remaining" topology 
the shared tree should be updated, for the removed replica it will 
not, but this should be uninstalled anyway
The problem here, is that the topology information does not get 
updated on master as well.
could you be a bit more precise. what do you still see ? the agreement 
will be only removed if the segment is removed, and this should be 
reoplicated to all severs in the remaining topology - if you don't 
disconnect it by removing the replica.
and what was the topology structure and which replica did you remove, 
on which server did you remove it?
So,  Here is the results of the `topologysegment-find` command before 
replica removal:

root@f22master:/var/log/dirsrv/slapd-BAGAM-NET]$ ipa topologysegment-find
Suffix name: realm
--
2 segments matched
--
  Segment name: f22master.bagam.net-to-f22replica1.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica1.bagam.net
  Connectivity: both

  Segment name: f22master.bagam.net-to-f22replica2.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica2.bagam.net
  Connectivity: both

Number of entries returned 2

Then, after issuing `ipa-replica-manage-del f2replica1.bagam.net 
--force` on the master, the same command on master still shows exactly 
the same topology:


root@f22master:/var/log/dirsrv/slapd-BAGAM-NET]$ ipa topologysegment-find
Suffix name: realm
--
2 segments matched
--
  Segment name: f22master.bagam.net-to-f22replica1.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica1.bagam.net
  Connectivity: both

  Segment name: f22master.bagam.net-to-f22replica2.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica2.bagam.net
  Connectivity: both

Number of entries returned 2


When I then issue `ipa topologysegment-del`, it fails due to "ipa: 
ERROR: Server is unwilling to perform: Removal of Segment 
disconnects topology.Deletion not allowed."

correct, you can only do it after removal of the server
I do not get it. Master still thinks it has the replica, it displays 
it both in CLI using `ipa topologysegment-find` and in the web-ui. 
(although it does not show it using `ipa host-find`, which is 
correct), and there is no way to manually make it change it's mind?


I tried to disable the segment first and then delete it, but with 
the segment properly disabled, the attempt to delete it raised a 
GSS error: "ipa: ERROR: Kerberos error: Kerberos error: 
('Unspecified GSS failure.  Minor code may provide more 
information', 851968)/('KDC returned error string: PROCESS_TGS', 
-1765328324)/". I am not sure, where to search for corresponding 
logs. The session transcript is attached.


2. The following is probably unrelated to the topology plugin:
I installed a replica with --setup-ca option. Then, on this replica 
tried to prepare another replica:
- 

root@f22replica2:/home/ofayans/f22]$ ipa-replica-prepare 
--ip-address 192.168.122.141 f22replica3.bagam.net

Directory Manager (existing master) password:

Preparing replica for f22replica3.bagam.net from f22replica2.bagam.net
Creating SSL certificate for the Directory Server
Certificate issuance failed
- 


The corresponding line in the dirsrv log:
[09/Jun/2015:09:54:46 -0400] - Entry "uid=admin,ou=people,o=ipaca" 
-- attribute "krbExtraData" not allowed










--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.








--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.

-- 
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] topology issues

[Ludwig Krispenz]

On 06/09/2015 04:14 PM, Oleg Fayans wrote:



On 06/09/2015 04:04 PM, Ludwig Krispenz wrote:


On 06/09/2015 03:55 PM, Oleg Fayans wrote:

Hi everybody,

The current status of Topology plugin testing is as follows:

1. There is still no proper way of removing the replica.
Standard procedure using `ipa-replica-manage del` throws "Server is 
unwilling to perform: Entry is managed by topology plugin.Deletion 
not allowed.". 
yes, that is for the first attempt to directly remove the agreement, 
but when the server is removed the agreements should be removed
We should probably think of less threatening error message in this 
case. Just from reading the command output one might conclude that 
replica removal failed.
The replication agreement though does get deleted, 

then it is ok,
but the topology information does not get updated. 
what do you mean, where do you check ? in the "remaining" topology 
the shared tree should be updated, for the removed replica it will 
not, but this should be uninstalled anyway
The problem here, is that the topology information does not get 
updated on master as well.
could you be a bit more precise. what do you still see ? the agreement 
will be only removed if the segment is removed, and this should be 
reoplicated to all severs in the remaining topology - if you don't 
disconnect it by removing the replica.
and what was the topology structure and which replica did you remove, on 
which server did you remove it?
When I then issue `ipa topologysegment-del`, it fails due to "ipa: 
ERROR: Server is unwilling to perform: Removal of Segment 
disconnects topology.Deletion not allowed."

correct, you can only do it after removal of the server
I do not get it. Master still thinks it has the replica, it displays 
it both in CLI using `ipa topologysegment-find` and in the web-ui. 
(although it does not show it using `ipa host-find`, which is 
correct), and there is no way to manually make it change it's mind?


I tried to disable the segment first and then delete it, but with 
the segment properly disabled, the attempt to delete it raised a GSS 
error: "ipa: ERROR: Kerberos error: Kerberos error: ('Unspecified 
GSS failure.  Minor code may provide more information', 
851968)/('KDC returned error string: PROCESS_TGS', -1765328324)/". I 
am not sure, where to search for corresponding logs. The session 
transcript is attached.


2. The following is probably unrelated to the topology plugin:
I installed a replica with --setup-ca option. Then, on this replica 
tried to prepare another replica:
- 

root@f22replica2:/home/ofayans/f22]$ ipa-replica-prepare 
--ip-address 192.168.122.141 f22replica3.bagam.net

Directory Manager (existing master) password:

Preparing replica for f22replica3.bagam.net from f22replica2.bagam.net
Creating SSL certificate for the Directory Server
Certificate issuance failed
- 


The corresponding line in the dirsrv log:
[09/Jun/2015:09:54:46 -0400] - Entry "uid=admin,ou=people,o=ipaca" 
-- attribute "krbExtraData" not allowed










--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.




-- 
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] topology issues

[Oleg Fayans]

On 06/09/2015 04:04 PM, Ludwig Krispenz wrote:


On 06/09/2015 03:55 PM, Oleg Fayans wrote:

Hi everybody,

The current status of Topology plugin testing is as follows:

1. There is still no proper way of removing the replica.
Standard procedure using `ipa-replica-manage del` throws "Server is 
unwilling to perform: Entry is managed by topology plugin.Deletion 
not allowed.". 
yes, that is for the first attempt to directly remove the agreement, 
but when the server is removed the agreements should be removed
We should probably think of less threatening error message in this case. 
Just from reading the command output one might conclude that replica 
removal failed.
The replication agreement though does get deleted, 

then it is ok,
but the topology information does not get updated. 
what do you mean, where do you check ? in the "remaining" topology the 
shared tree should be updated, for the removed replica it will not, 
but this should be uninstalled anyway
The problem here, is that the topology information does not get updated 
on master as well.
When I then issue `ipa topologysegment-del`, it fails due to "ipa: 
ERROR: Server is unwilling to perform: Removal of Segment disconnects 
topology.Deletion not allowed."

correct, you can only do it after removal of the server
I do not get it. Master still thinks it has the replica, it displays it 
both in CLI using `ipa topologysegment-find` and in the web-ui. 
(although it does not show it using `ipa host-find`, which is correct), 
and there is no way to manually make it change it's mind?


I tried to disable the segment first and then delete it, but with the 
segment properly disabled, the attempt to delete it raised a GSS 
error: "ipa: ERROR: Kerberos error: Kerberos error: ('Unspecified GSS 
failure.  Minor code may provide more information', 851968)/('KDC 
returned error string: PROCESS_TGS', -1765328324)/". I am not sure, 
where to search for corresponding logs. The session transcript is 
attached.


2. The following is probably unrelated to the topology plugin:
I installed a replica with --setup-ca option. Then, on this replica 
tried to prepare another replica:
- 

root@f22replica2:/home/ofayans/f22]$ ipa-replica-prepare --ip-address 
192.168.122.141 f22replica3.bagam.net

Directory Manager (existing master) password:

Preparing replica for f22replica3.bagam.net from f22replica2.bagam.net
Creating SSL certificate for the Directory Server
Certificate issuance failed
- 


The corresponding line in the dirsrv log:
[09/Jun/2015:09:54:46 -0400] - Entry "uid=admin,ou=people,o=ipaca" -- 
attribute "krbExtraData" not allowed










--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.

-- 
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] topology issues

[Ludwig Krispenz]

On 06/09/2015 03:55 PM, Oleg Fayans wrote:

Hi everybody,

The current status of Topology plugin testing is as follows:

1. There is still no proper way of removing the replica.
Standard procedure using `ipa-replica-manage del` throws "Server is 
unwilling to perform: Entry is managed by topology plugin.Deletion not 
allowed.". 
yes, that is for the first attempt to directly remove the agreement, but 
when the server is removed the agreements should be removed
The replication agreement though does get deleted, 

then it is ok,
but the topology information does not get updated. 
what do you mean, where do you check ? in the "remaining" topology the 
shared tree should be updated, for the removed replica it will not, but 
this should be uninstalled anyway
When I then issue `ipa topologysegment-del`, it fails due to "ipa: 
ERROR: Server is unwilling to perform: Removal of Segment disconnects 
topology.Deletion not allowed."

correct, you can only do it after removal of the server


I tried to disable the segment first and then delete it, but with the 
segment properly disabled, the attempt to delete it raised a GSS 
error: "ipa: ERROR: Kerberos error: Kerberos error: ('Unspecified GSS 
failure.  Minor code may provide more information', 851968)/('KDC 
returned error string: PROCESS_TGS', -1765328324)/". I am not sure, 
where to search for corresponding logs. The session transcript is 
attached.


2. The following is probably unrelated to the topology plugin:
I installed a replica with --setup-ca option. Then, on this replica 
tried to prepare another replica:
- 

root@f22replica2:/home/ofayans/f22]$ ipa-replica-prepare --ip-address 
192.168.122.141 f22replica3.bagam.net

Directory Manager (existing master) password:

Preparing replica for f22replica3.bagam.net from f22replica2.bagam.net
Creating SSL certificate for the Directory Server
Certificate issuance failed
- 


The corresponding line in the dirsrv log:
[09/Jun/2015:09:54:46 -0400] - Entry "uid=admin,ou=people,o=ipaca" -- 
attribute "krbExtraData" not allowed






-- 
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] 0001 Provide Kerberos over HTTP (MS-KKDCP)

[Christian Heimes]

On 2015-05-27 15:16, Christian Heimes wrote:
> Hello,
> 
> here is my first patch for FreeIPA. The patch integrates python-kdcproxy
> for MS-KKDCP support (aka Kerberos over HTTPS).
> 
> https://www.freeipa.org/page/V4/KDC_Proxy
> 
> Ticket: https://fedorahosted.org/freeipa/ticket/4801

freeipa-cheimes-0001-2-Provide-Kerberos-over-HTTP-MS-KKDCP.patch doesn't
apply anymore. The new patch is based on the current master.

Christian

From ee1bb0384eecfa6d6fe7770c44d54474b0d55951 Mon Sep 17 00:00:00 2001
From: Christian Heimes 
Date: Thu, 21 May 2015 12:42:27 +0200
Subject: [PATCH] Provide Kerberos over HTTP (MS-KKDCP)

Add integration of python-kdcproxy into FreeIPA to support the MS
Kerberos KDC proxy protocol (MS-KKDCP), to allow KDC and KPASSWD
client requests over HTTP and HTTPS.

- freeipa-server now depends on python-kdcproxy >= 0.2.1. All kdcproxy
  dependencies are already satisfied.
- The service can be globally toggled with the boolean attribute
  ipaKDCproxyEnabled in cn=ipaConfig,cn=etc. The switch is supported by
  ipa config-mod --enable-kdcproxy.
- The installers and update create a new Apache config file
  ipa-kdc-proxy.conf that mounts a WSGI app at /KdcProxy. The app is run
  inside its own WSGI daemon group.
- The WSGI app at /KdcProxy is a WSGI wrapper, that checks the state of
  the switch. When ipaKDCproxyEnabled is FALSE, a HTTP 404 error is
  returned. For performance reasons the flag is only checked at start
  of the WSGI app. Apache must be reloaded or restarted to read the
  switch state again.
- The WSGI app uses the Apache principal to acquire a Kerberos ticket to
  perform GSSAPI bindings for the LDAP query of ipaKDCproxyEnabled.
- The WSGI wrapper script sets KDCPROXY_CONFIG=/etc/ipa/kdcproxy.conf,
  so that an existing config is not used.
- python-kdcproxy is configured to *not* use DNS SRV lookups. The
  location of KDC and KPASSWD servers are read from /etc/krb5.conf

Changes since patch 1:
- Further simplify krb ticket code
  Simo has pointed out that KRB5_CLIENT_KTNAME and MEMORY ccache are sufficient
  for the GSSAPI. http://k5wiki.kerberos.org/wiki/Projects/Keytab_initiation
- switch is now in ipaConfigString=kdcProxyEnabled of
  cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc
- add service principal KDCPROXY
- add own keytab /etc/ipa/kdcproxy/kdcproxy.keytab
- add permission 'System: Read IPA Masters KDC Proxy'
- add privilege 'IPA Masters KDC Proxy Readers'
- add ipa-ldap-updater scripts to enable/disable KDC Proxy
- Create a separate user and group account
  The KDC Proxy WSGI app now uses a separate user account to run the
  daemon process. The keytab is only readable by that user, too.

https://www.freeipa.org/page/V4/KDC_Proxy

https://fedorahosted.org/freeipa/ticket/4801
---
 ACI.txt|   4 +-
 API.txt|   3 +-
 freeipa.spec.in|  25 +++
 install/conf/Makefile.am   |   1 +
 install/conf/ipa-kdc-proxy.conf|  14 ++
 install/conf/ipa.conf  |   6 +-
 install/share/60ipaconfig.ldif |   4 +-
 install/share/Makefile.am  |   2 +
 install/share/kdcproxy-disable.ldif|   3 +
 install/share/kdcproxy-enable.ldif |   6 +
 install/share/kdcproxy.conf|   4 +
 install/share/kdcproxyshim.py  | 161 +
 install/ui/src/freeipa/serverconfig.js |   4 +
 install/updates/40-delegation.update   |   7 +
 install/updates/50-ipaconfig.update|   4 +
 ipalib/plugins/config.py   |   8 +-
 ipaplatform/base/paths.py  |   4 +-
 ipaserver/install/ipa_backup.py|   1 +
 ipaserver/install/kdcproxyinstance.py  | 201 +
 .../install/plugins/update_managed_permissions.py  |  11 ++
 ipaserver/install/server/install.py|   8 +-
 ipaserver/install/server/replicainstall.py |   9 +-
 ipaserver/install/server/upgrade.py|   8 +
 23 files changed, 488 insertions(+), 10 deletions(-)
 create mode 100644 install/conf/ipa-kdc-proxy.conf
 create mode 100644 install/share/kdcproxy-disable.ldif
 create mode 100644 install/share/kdcproxy-enable.ldif
 create mode 100644 install/share/kdcproxy.conf
 create mode 100644 install/share/kdcproxyshim.py
 create mode 100644 ipaserver/install/kdcproxyinstance.py

diff --git a/ACI.txt b/ACI.txt
index 59173ac1b593f15e079c7b1fce43ec9b0084ec91..974a0b7da60bc8cecbe5b7712033e2c1a07d65fb 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -31,7 +31,7 @@ aci: (targetattr = "cn || description || ipacertprofilestoreissued")(targetfilte
 dn: cn=certprofiles,cn=ca,dc=ipa,dc=example
 aci: (targetattr = "cn || createtimestamp || description || entryusn || ipacertprofilestoreissued || modifytimestamp || objectclass")(targe

[Freeipa-devel] topology issues

[Oleg Fayans]

Hi everybody,

The current status of Topology plugin testing is as follows:

1. There is still no proper way of removing the replica.
Standard procedure using `ipa-replica-manage del` throws "Server is 
unwilling to perform: Entry is managed by topology plugin.Deletion not 
allowed.". The replication agreement though does get deleted, but the 
topology information does not get updated. When I then issue `ipa 
topologysegment-del`, it fails due to "ipa: ERROR: Server is unwilling 
to perform: Removal of Segment disconnects topology.Deletion not allowed."


I tried to disable the segment first and then delete it, but with the 
segment properly disabled, the attempt to delete it raised a GSS error: 
"ipa: ERROR: Kerberos error: Kerberos error: ('Unspecified GSS failure.  
Minor code may provide more information', 851968)/('KDC returned error 
string: PROCESS_TGS', -1765328324)/". I am not sure, where to search for 
corresponding logs. The session transcript is attached.


2. The following is probably unrelated to the topology plugin:
I installed a replica with --setup-ca option. Then, on this replica 
tried to prepare another replica:

-
root@f22replica2:/home/ofayans/f22]$ ipa-replica-prepare --ip-address 
192.168.122.141 f22replica3.bagam.net

Directory Manager (existing master) password:

Preparing replica for f22replica3.bagam.net from f22replica2.bagam.net
Creating SSL certificate for the Directory Server
Certificate issuance failed
-
The corresponding line in the dirsrv log:
[09/Jun/2015:09:54:46 -0400] - Entry "uid=admin,ou=people,o=ipaca" -- 
attribute "krbExtraData" not allowed


--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.

root@f22master:/home/ofayans]$ ipa topologysegment-find
Suffix name: realm
--
2 segments matched
--
  Segment name: f22master.bagam.net-to-f22replica1.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica1.bagam.net
  Connectivity: both

  Segment name: f22master.bagam.net-to-f22replica2.bagam.net
  Left node: f22master.bagam.net
  Right node: f22replica2.bagam.net
  Connectivity: both

Number of entries returned 2

root@f22master:/home/ofayans]$ ipa-replica-manage del f22replica1.bagam.net
Deleting a master is irreversible.
To reconnect to the remote master you will need to prepare a new replica file
and re-install.
Continue to delete? [no]: yes
Deleting replication agreements between f22replica1.bagam.net and 
f22master.bagam.net
ipa: INFO: Setting agreement 
cn=meTof22master.bagam.net,cn=replica,cn=dc\=bagam\,dc\=net,cn=mapping 
tree,cn=config schedule to 2358-2359 0 to force synch
ipa: INFO: Deleting schedule 2358-2359 0 from agreement 
cn=meTof22master.bagam.net,cn=replica,cn=dc\=bagam\,dc\=net,cn=mapping 
tree,cn=config
ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica acquired 
successfully: Incremental update succeeded: start: 0: end: 0
Unable to remove agreement on f22replica1.bagam.net: Server is unwilling to 
perform: Entry is managed by topology plugin.Deletion not allowed.
Forcing removal on 'f22master.bagam.net'
Any DNA range on 'f22replica1.bagam.net' will be lost
There were issues removing a connection for f22replica1.bagam.net from 
f22master.bagam.net: Server is unwilling to perform: Entry is managed by 
topology plugin.Deletion not allowed.
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
root@f22master:/home/ofayans]$ ipa topologysegment-del 
Suffix name: realm
Segment name: f22master.bagam.net-to-f22replica1.bagam.net
ipa: ERROR: Server is unwilling to perform: Removal of Segment disconnects 
topology.Deletion not allowed.
root@f22master:/home/ofayans]$ ipa help topologysegment-mod
Usage: ipa [global-options] topologysegment-mod TOPOLOGYSUFFIX NAME [options]

Modify a segment.
Options:
  -h, --helpshow this help message and exit
  --leftnode=STRLeft replication node - an IPA server
  --rightnode=STR   Right replication node - an IPA server
  --direction=['both', 'left-right', 'right-left', 'none']
Direction of replication between left and right
replication node
  --stripattrs=STR  A space separated list of attributes which are removed
from replication updates.
  --replattrs=STR   Attributes that are not replicated to a consumer
server during a fractional update. E.g.,
`(objectclass=*) $ EXCLUDE accountlockout memberof
  --replattrstotal=STR  Attributes that are not replicated to a consumer
server during a total

Re: [Freeipa-devel] Community Portal Milestone

[Petr Spacek]

On 9.6.2015 12:30, Petr Spacek wrote:
> On 8.6.2015 21:37, Drew Erny wrote:
>> Hi, all,
>>
>> I'm going to start working on the Community Portal milestone this week. The
>> first thing I'm noticing is that for almost all of the community portal, 
>> there
>> has to be some way for the IPA server to send email, which right now isn't
>> possible. It has been brought to my attention, however, that there is an
>> existing ticket (https://fedorahosted.org/freeipa/ticket/1593) that includes
>> email under its purview. I don't want to write a bunch of code that'll get
>> tossed when work starts on the notification system if I don't have to, but I
>> will if I must.
>>
>> I need a little bit of guidance. Is working on code to let the IPA server 
>> send
>> email to users a good place to start chipping at this?
> 
> Hello!
> 
> I would recommend you to base your implementation on the generic principle
> sketched in https://fedorahosted.org/freeipa/ticket/1593 .
> 
> Let's take https://fedorahosted.org/freeipa/ticket/3613 as an example:
> [RFE] Provide a self service enrollment capability with admin approval and
> notification workflow
> 
> 1. User fills-in a web form for account registration.
> 2. A new user object in staging area is created.
> 3. FreeIPA framework calls a D-Bus method
> com.redhat.ipa.hook_user_self_registration (or something like that)
> 
> This method/service/how is it called can be then provided by arbitrary script
> which can be connected to D-Bus using Oddjob.
> http://people.redhat.com/nalin/oddjob/
> 
> This will lift the burden of e-mail processing from you and will allow users
> to do anything with the data passed to hooks.
> 
> I hope this helps.

Speaking about D-Bus, interns in Brno successfully used this tutorial a month 
ago:
http://excid3.com/blog/an-actually-decent-python-dbus-tutorial/

I do not remember why but we slightly modified the code for consumer to use
Interface() constructor instead of get_dbus_method():

infopipe_obj = bus.get_object("org.freedesktop.sssd.infopipe",
"/org/freedesktop/sssd/infopipe")

ifp = dbus.Interface(infopipe_obj, 
dbus_interface='org.freedesktop.sssd.infopipe')

# call the method remotely
result = ifp.GetUserAttr(username, ["ipaSshPubKey"])

So, if you encounter a mysterious failure you might want to try this variant :-)

FreeIPA framework should act as 'consumeservice.py' and oddjob will implement
most of 'myservice.py' for you.

Let us know if you have any questions!

-- 
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] DNA range distribution to replicas by default

[Simo Sorce]

On Tue, 2015-06-09 at 10:30 +0200, Petr Spacek wrote:
> Hello,
> 
> I would like to discuss
> https://bugzilla.redhat.com/show_bug.cgi?id=1211366
> "Error creating a user when jumping from an original server to replica".
> 
> Currently the DNA ranges are distributed from master to other replicas on
> first attempt to get a number from particular range.
> 
> This works well as long as the original master is reachable but fails
> miserably when the master is not reachable for any reason.
> 
> It is apparently confusing to users [1][2] because it is counter-intuitive.
> They have created a replica to be sure that everything will work when the
> first server is down, right?
> 
> Remediation is technically simple [3] (just assign a range to the new replica)
> but it is confusing to the users, error-prone, and personally I feel that this
> is an unnecessary obstacle.
> 
> It seems to me that the original motivation for this behavior was that the
> masters were not able to request range back from other replicas when a local
> range was depleted.
> 
> This deficiency is tracked as
> https://bugzilla.redhat.com/show_bug.cgi?id=1029640 and it is slated for fix
> in 4.2.x time frame.
> 
> Can we distribute ranges to the replicas during ipa-replica-install when we
> fix bug 1029640?

That was not the only reason, another reason is that you do not want to
distribute and fragment ranges to replicas that will never be used to
create users. What we should do perhaps, is to automatically give a
range to CA enabled masters so that at least those servers have a range.
If all your CAs are unavailable you have major issues anyway.

Though it is a bit bad to have magic behaviors, maybe we should have a
"main DNA range holder" role that can be assigned to arbitrary servers
(maybe the first replica gets it by default), and when done the server
acquire part of the range if it has none.


Another option is that a replica can instantiate a whole new range if
all the range bearing servers are not around, but that also comes with
its own issues.

In general I wouldn't want to split by default, because in domains with
*many* replicas most of them are used for load balancing and will never
be used to create users, so the range would be wasted.

Simo.

> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1211366#c0
> [2] https://www.redhat.com/archives/freeipa-users/2015-May/msg00515.html
> [3] http://blog-rcritten.rhcloud.com/?p=50
> 
> -- 
> Petr^2 Spacek
> 


-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [PATCHES 439-442] install: Migrate ipa-replica-install to the install framework

[Jan Cholasta]

Hi,

the attached patches implement another part of 
.


Honza

--
Jan Cholasta
>From 9ebc623478065d582a449dde56f39ec927f12628 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Tue, 9 Jun 2015 11:33:13 +
Subject: [PATCH 1/4] install: Handle Knob cli_name and cli_aliases values
 consistently

https://fedorahosted.org/freeipa/ticket/4468
---
 ipapython/install/cli.py| 11 ++-
 ipaserver/install/server/install.py | 36 ++--
 2 files changed, 24 insertions(+), 23 deletions(-)

diff --git a/ipapython/install/cli.py b/ipapython/install/cli.py
index b83fd9a..e121f3d 100644
--- a/ipapython/install/cli.py
+++ b/ipapython/install/cli.py
@@ -114,8 +114,8 @@ class ConfigureTool(admintool.AdminTool):
 short_opt_str = '-{0}'.format(knob_cls.cli_short_name)
 else:
 short_opt_str = ''
-cli_name = knob_cls.cli_name or name
-opt_str = '--{0}'.format(cli_name.replace('_', '-'))
+cli_name = knob_cls.cli_name or name.replace('_', '-')
+opt_str = '--{0}'.format(cli_name)
 if not knob_cls.deprecated:
 help = knob_cls.description
 else:
@@ -127,8 +127,9 @@ class ConfigureTool(admintool.AdminTool):
 )
 
 if knob_cls.cli_aliases:
+opt_strs = ['--{0}'.format(a) for a in knob_cls.cli_aliases]
 opt_group.add_option(
-*knob_cls.cli_aliases,
+*opt_strs,
 help=optparse.SUPPRESS_HELP,
 **kwargs
 )
@@ -201,8 +202,8 @@ class ConfigureTool(admintool.AdminTool):
 cfgr = transformed_cls(**kwargs)
 except core.KnobValueError as e:
 knob_cls = getattr(transformed_cls, e.name)
-cli_name = knob_cls.cli_name or e.name
-opt_str = '--{0}'.format(cli_name.replace('_', '-'))
+cli_name = knob_cls.cli_name or e.name.replace('_', '-')
+opt_str = '--{0}'.format(cli_name)
 self.option_parser.error("option {0}: {1}".format(opt_str, e))
 except RuntimeError as e:
 self.option_parser.error(str(e))
diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py
index 7a5aa3c..59a9d1e 100644
--- a/ipaserver/install/server/install.py
+++ b/ipaserver/install/server/install.py
@@ -1165,8 +1165,8 @@ class ServerCA(common.Installable, core.Group, core.Composite):
 (list, str), None,
 description=("File containing the IPA CA certificate and the external "
  "CA certificate chain (can be specified multiple times)"),
-cli_name='external_cert_file',
-cli_aliases=['--external_cert_file', '--external_ca_file'],
+cli_name='external-cert-file',
+cli_aliases=['external_cert_file', 'external_ca_file'],
 cli_metavar='FILE',
 )
 
@@ -1184,8 +1184,8 @@ class ServerCA(common.Installable, core.Group, core.Composite):
 (list, str), None,
 description=("File containing the Directory Server SSL certificate "
  "and private key"),
-cli_name='dirsrv_cert_file',
-cli_aliases=['--dirsrv_pkcs12'],
+cli_name='dirsrv-cert-file',
+cli_aliases=['dirsrv_pkcs12'],
 cli_metavar='FILE',
 )
 
@@ -1193,8 +1193,8 @@ class ServerCA(common.Installable, core.Group, core.Composite):
 (list, str), None,
 description=("File containing the Apache Server SSL certificate and "
  "private key"),
-cli_name='http_cert_file',
-cli_aliases=['--http_pkcs12'],
+cli_name='http-cert-file',
+cli_aliases=['http_pkcs12'],
 cli_metavar='FILE',
 )
 
@@ -1202,8 +1202,8 @@ class ServerCA(common.Installable, core.Group, core.Composite):
 (list, str), None,
 description=("File containing the Kerberos KDC SSL certificate and "
  "private key"),
-cli_name='pkinit_cert_file',
-cli_aliases=['--pkinit_pkcs12'],
+cli_name='pkinit-cert-file',
+cli_aliases=['pkinit_pkcs12'],
 cli_metavar='FILE',
 )
 
@@ -1211,7 +1211,7 @@ class ServerCA(common.Installable, core.Group, core.Composite):
 str, None,
 sensitive=True,
 description="The password to unlock the Directory Server private key",
-cli_aliases=['--dirsrv_pin'],
+cli_aliases=['dirsrv_pin'],
 cli_metavar='PIN',
 )
 
@@ -1219,7 +1219,7 @@ class ServerCA(common.Installable, core.Group, core.Composite):
 str, None,
 sensitive=True,
 description="The password to unlock the Apache Server private key",
-cli_aliases=['--http_pin'],
+cli_aliases=['http_pin'],
 cli_metavar='PIN',
 )
 
@@ -1227,7 +1227,7 @@ class ServerCA(common.Installable, core.Group, core.Composit

Re: [Freeipa-devel] [PATCH] 0005 User life cycle: del/mod/find/show stageuser commands

[Jan Cholasta]

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.
Now if the second time the preserve option is present, it makes sense to
not delete it.


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.

--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [PATCH 0040] generalize certificate creation during testing

[Martin Babinsky]

A slight hack to ipatests/test_xmlrpc/testcert.py module in order to 
enable generation of multiple host/service/user certificates.


It should make writing tests for new CA profile/sub-CA/user certificate 
functionality easier.


--
Martin^3 Babinsky
From 41578368546bca02654016c1df1295227ac89554 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Tue, 9 Jun 2015 10:06:53 +0200
Subject: [PATCH] generalize certificate creation during testing

With added support for multiple certificates for hosts, services, and even
users, IPA testing framework will need a more flexible way to generate
temporary testing certificates for these entities. This patch modifies the
currently used `testcert` module to support these requirements.

Related to work on http://www.freeipa.org/page/V4/User_Certificates
---
 ipatests/test_xmlrpc/test_host_plugin.py|  7 +--
 ipatests/test_xmlrpc/test_service_plugin.py | 20 +++-
 ipatests/test_xmlrpc/testcert.py| 25 ++---
 3 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/ipatests/test_xmlrpc/test_host_plugin.py b/ipatests/test_xmlrpc/test_host_plugin.py
index e46e502d2db397be457d193e2802c379e4f6c289..4c574b95745d25ac2b81ca4604a516cf523a2bde 100644
--- a/ipatests/test_xmlrpc/test_host_plugin.py
+++ b/ipatests/test_xmlrpc/test_host_plugin.py
@@ -94,6 +94,9 @@ hostgroup1 = u'testhostgroup1'
 hostgroup1_dn = DN(('cn',hostgroup1),('cn','hostgroups'),('cn','accounts'),
 api.env.basedn)
 
+host_cert = get_testcert(DN(('CN', api.env.host), x509.subject_base()),
+ 'host/%s@%s' % (api.env.host, api.env.realm))
+
 
 class HostTracker(Tracker):
 """Wraps and tracks modifications to a Host object
@@ -360,10 +363,10 @@ class TestCRUD(XMLRPC_test):
 def test_update_simple(self, host):
 host.update(dict(
 description=u'Updated host 1',
-usercertificate=get_testcert()),
+usercertificate=host_cert),
 expected_updates=dict(
 description=[u'Updated host 1'],
-usercertificate=[base64.b64decode(get_testcert())],
+usercertificate=[base64.b64decode(host_cert)],
 issuer=fuzzy_issuer,
 md5_fingerprint=fuzzy_hash,
 serial_number=fuzzy_digits,
diff --git a/ipatests/test_xmlrpc/test_service_plugin.py b/ipatests/test_xmlrpc/test_service_plugin.py
index 946dc572b0d0e5b3f26cd7bfd6ad8128f113493f..006c35999a2ca8540116ff62b8ee6176b2518c2f 100644
--- a/ipatests/test_xmlrpc/test_service_plugin.py
+++ b/ipatests/test_xmlrpc/test_service_plugin.py
@@ -46,6 +46,8 @@ host3dn = DN(('fqdn',fqdn3),('cn','computers'),('cn','accounts'),api.env.basedn)
 role1 = u'Test Role'
 role1_dn = DN(('cn', role1), api.env.container_rolegroup, api.env.basedn)
 
+servercert= get_testcert(DN(('CN', api.env.host), x509.subject_base()),
+ 'unittest/%s@%s' % (api.env.host, api.env.realm))
 badservercert = 'MIICbzCCAdigAwIBAgICA/4wDQYJKoZIhvcNAQEFBQAwKTEnMCUGA1UEAxMeSVBBIFRlc3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEwMDgwOTE1MDIyN1oXDTIwMDgwOTE1MDIyN1owKTEMMAoGA1UEChMDSVBBMRkwFwYDVQQDExBwdW1hLmdyZXlvYWsuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwYbfEOQPgGenPn9vt1JFKvWm/Je3y2tawGWA3LXDuqfFJyYtZ8ib3TcBUOnLk9WK5g2qCwHaNlei7bj8ggIfr5hegAVe10cun+wYErjnYo7hsHYd+57VZezeipWrXu+7NoNd4+c4A5lk4A/xJay9j3bYx2oOM8BEox4xWYoWge1ljPrc5JK46f0X7AGW4F2VhnKPnf8rwSuzI1U8VGjutyM9TWNy3m9KMWeScjyG/ggIpOjUDMV7HkJL0Di61lznR9jXubpiEC7gWGbTp84eGl/Nn9bgK1AwHfJ2lHwfoY4uiL7ge1gyP6EvuUlHoBzdb7pekiX28iePjW3iEG9IawIDAQABoyIwIDARBglghkgBhvhCAQEEBAMCBkAwCwYDVR0PBAQDAgUgMA0GCSqGSIb3DQEBBQUAA4GBACRESLemRV9BPxfEgbALuxH5oE8jQm8WZ3pm2pALbpDlAd9wQc3yVf6RtkfVthyDnM18bg7IhxKpd77/p3H8eCnS8w5MLVRda6ktUC6tGhFTS4QKAf0WyDGTcIgkXbeDw0OPAoNHivoXbIXIIRxlw/XgaSaMzJQDBG8iROsN4kCv'
 
 user1 = u'tuser1'
@@ -78,7 +80,7 @@ class test_service(Declarative):
 
 dict(
 desc='Try to update non-existent %r' % service1,
-command=('service_mod', [service1], dict(usercertificate=get_testcert())),
+command=('service_mod', [service1], dict(usercertificate=servercert)),
 expected=errors.NotFound(
 reason=u'%s: service not found' % service1),
 ),
@@ -390,12 +392,12 @@ class test_service(Declarative):
 
 dict(
 desc='Update %r' % service1,
-command=('service_mod', [service1], dict(usercertificate=get_testcert())),
+command=('service_mod', [service1], dict(usercertificate=servercert)),
 expected=dict(
 value=service1,
 summary=u'Modified service "%s"' % service1,
 result=dict(
-usercertificate=[base64.b64decode(get_testcert())],
+usercertificate=[base64.b64decode(servercert)],
 krbprincipalname=[se

Re: [Freeipa-devel] Community Portal Milestone

[Petr Spacek]

On 8.6.2015 21:37, Drew Erny wrote:
> Hi, all,
> 
> I'm going to start working on the Community Portal milestone this week. The
> first thing I'm noticing is that for almost all of the community portal, there
> has to be some way for the IPA server to send email, which right now isn't
> possible. It has been brought to my attention, however, that there is an
> existing ticket (https://fedorahosted.org/freeipa/ticket/1593) that includes
> email under its purview. I don't want to write a bunch of code that'll get
> tossed when work starts on the notification system if I don't have to, but I
> will if I must.
> 
> I need a little bit of guidance. Is working on code to let the IPA server send
> email to users a good place to start chipping at this?

Hello!

I would recommend you to base your implementation on the generic principle
sketched in https://fedorahosted.org/freeipa/ticket/1593 .

Let's take https://fedorahosted.org/freeipa/ticket/3613 as an example:
[RFE] Provide a self service enrollment capability with admin approval and
notification workflow

1. User fills-in a web form for account registration.
2. A new user object in staging area is created.
3. FreeIPA framework calls a D-Bus method
com.redhat.ipa.hook_user_self_registration (or something like that)

This method/service/how is it called can be then provided by arbitrary script
which can be connected to D-Bus using Oddjob.
http://people.redhat.com/nalin/oddjob/

This will lift the burden of e-mail processing from you and will allow users
to do anything with the data passed to hooks.

I hope this helps.

-- 
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] [PATCHES 00012-0013 v7] Profiles and CA ACLs

[Martin Basti]

On 09/06/15 09:07, Fraser Tweedale wrote:

On Thu, Jun 04, 2015 at 03:58:25PM +0200, Martin Basti wrote:

On 04/06/15 15:48, Martin Kosek wrote:

On 06/04/2015 03:40 PM, Martin Basti wrote:

On 04/06/15 08:59, Fraser Tweedale wrote:

On Wed, Jun 03, 2015 at 06:49:13PM +0200, Martin Basti wrote:

On 03/06/15 16:17, Fraser Tweedale wrote:

On Tue, Jun 02, 2015 at 06:37:42PM +0200, Martin Basti wrote:

On 02/06/15 14:11, Fraser Tweedale wrote:

On Mon, Jun 01, 2015 at 05:22:28PM +1000, Fraser Tweedale wrote:

On Mon, Jun 01, 2015 at 05:10:58PM +1000, Fraser Tweedale wrote:

On Fri, May 29, 2015 at 01:03:46PM +0200, Martin Kosek wrote:

On 05/29/2015 11:21 AM, Martin Basti wrote:

On 29/05/15 06:17, Fraser Tweedale wrote:

On Thu, May 28, 2015 at 02:42:53PM +0200, Martin Basti wrote:

On 28/05/15 11:48, Martin Basti wrote:

On 27/05/15 16:04, Fraser Tweedale wrote:

Hello all,

Fresh certificate management patchset; Changelog:

- Now depends on patch freeipa-ftweedal-0014 for correct
cert-request behaviour with host and service principals.

- Updated Dogtag dependency to 10.2.4-1.  Should should be in
f22 soon, but for f22 right now or for f21, please grab from my
copr: https://copr.fedoraproject.org/coprs/ftweedal/freeipa/

Martin^1 could you please add to the quasi-official freeipa
copr?  SRPM lives at
https://frase.id.au/pki-core-10.2.4-1.fc21.src.rpm.

- cert-request now verifies that for user principals, CSR CN
matches uid and, DN emailAddress and SAN rfc822Name match user's
email address, if either of those is present.

- Fixed one or two other sneaky little bugs.

On Wed, May 27, 2015 at 01:59:30AM +1000, Fraser Tweedale wrote:

Hi all,

Please find attached the latest certificate management
patchset, which introduces the `caacl' plugin and various fixes
and improvement to earlier patches.

One important change to earlier patches is reverting the name
of the default profile to 'caIPAserviceCert' and using the
existing instance of this profile on upgrade (but not install)
in case it has been modified.

Other notes:

- Still have changes in ipa-server-install (fewer lines now,
though)

- Still have the ugly import hack.  It is not a high priority
for me, i.e. I think it should wait until after alpha

- Still need to update 'service' and 'host' plugins to support
multiple certificates.  (The userCertificate attribute schema
itself is multi-valued, so there are no schema issues here)

- The TODOs in [1]; mostly certprofile CLI conveniences and
supporting multiple profiles for hosts and services (which
requires changes to framework only, not schema).  [1]:
http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress

Happy reviewing!  I am pleased with the initial cut of the
caacl plugin but I'm sure you will find some things to be fixed
:)

Cheers, Fraser

[root@vm-093 ~]#  ipa-replica-prepare vm-094.example.com
--ip-address 10.34.78.94 Directory Manager (existing master)
password:

Preparing replica for vm-094.example.com from vm-093.example.com
Creating SSL certificate for the Directory Server not well-formed
(invalid token): line 2, column 14

I cannot create replica file.  It work on the upgraded server,
but it doesn't work on the newly installed server.  I'm not sure
if this causes your patches which modifies the ca-installer, or
the newer version of dogtag.

Or if there was any other changes in master, I will continue to
investigate with new RPM from master branch.

Martin^2


ipa-replica-prepare works for: * master branch * master branch +
pki-ca 10.2.4-1

So something in your patches is breaking it

Martin^2


Martin, master + my patches with pki 10.2.4-1 is working for me on
f21 and f22.  Can you provide ipa-replica-prepare --debug output and
Dogtag debug log?  ( /var/log/pki/pki-tomcat/ca/debug )

Thanks,
Fraser

I can not reproduce it today. And I already recycled the VMs from
yesterday. :-(


In that case I would suggest ACKing&pushing the patch and fixing the
bug if
it comes again. The tree may now be a bit unstable, given the number of
patches going in.

My main motivation here is to unblock Fraser.

Thanks,
Martin

Rebased patchset attached; no other changes.

Heads up: I just discovered I have introduced a bug with
ipa-replica-install, when it is spawning the CA instance.  I think
replication it only causes issues with ``--setup-ca``.

I will try and sort it out tomorrow or later tonight (I have to head
out for a few hours now, though); and I'm not suggesting it should
block the push but it's something to be aware of.

Cheers,
Fraser


New patchset attached ; haven't gotten to the bottom of the
ipa-replica-install issue mentioned above, but it fixes an upgrade
bug.

The change is:

diff --git a/ipaserver/install/server/upgrade.py
b/ipaserver/install/server/upgrade.py
index c288282..c5f4d37 100644
--- a/ipaserver/install/server/upgrade.py
+++ b/ipaserver/install/server/upgrade.py
@@ -316,7 +316,7 @@ def ca_enable_ldap_profile_subsystem(ca):
   caconfig.CS_CFG_PAT

[Freeipa-devel] DNA range distribution to replicas by default

[Petr Spacek]

Hello,

I would like to discuss
https://bugzilla.redhat.com/show_bug.cgi?id=1211366
"Error creating a user when jumping from an original server to replica".

Currently the DNA ranges are distributed from master to other replicas on
first attempt to get a number from particular range.

This works well as long as the original master is reachable but fails
miserably when the master is not reachable for any reason.

It is apparently confusing to users [1][2] because it is counter-intuitive.
They have created a replica to be sure that everything will work when the
first server is down, right?

Remediation is technically simple [3] (just assign a range to the new replica)
but it is confusing to the users, error-prone, and personally I feel that this
is an unnecessary obstacle.

It seems to me that the original motivation for this behavior was that the
masters were not able to request range back from other replicas when a local
range was depleted.

This deficiency is tracked as
https://bugzilla.redhat.com/show_bug.cgi?id=1029640 and it is slated for fix
in 4.2.x time frame.

Can we distribute ranges to the replicas during ipa-replica-install when we
fix bug 1029640?


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1211366#c0
[2] https://www.redhat.com/archives/freeipa-users/2015-May/msg00515.html
[3] http://blog-rcritten.rhcloud.com/?p=50

-- 
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] [PATCHES 00012-0013 v7] Profiles and CA ACLs

[Fraser Tweedale]

On Thu, Jun 04, 2015 at 03:58:25PM +0200, Martin Basti wrote:
> On 04/06/15 15:48, Martin Kosek wrote:
> >On 06/04/2015 03:40 PM, Martin Basti wrote:
> >>On 04/06/15 08:59, Fraser Tweedale wrote:
> >>>On Wed, Jun 03, 2015 at 06:49:13PM +0200, Martin Basti wrote:
> On 03/06/15 16:17, Fraser Tweedale wrote:
> >On Tue, Jun 02, 2015 at 06:37:42PM +0200, Martin Basti wrote:
> >>On 02/06/15 14:11, Fraser Tweedale wrote:
> >>>On Mon, Jun 01, 2015 at 05:22:28PM +1000, Fraser Tweedale wrote:
> On Mon, Jun 01, 2015 at 05:10:58PM +1000, Fraser Tweedale wrote:
> >On Fri, May 29, 2015 at 01:03:46PM +0200, Martin Kosek wrote:
> >>On 05/29/2015 11:21 AM, Martin Basti wrote:
> >>>On 29/05/15 06:17, Fraser Tweedale wrote:
> On Thu, May 28, 2015 at 02:42:53PM +0200, Martin Basti wrote:
> >On 28/05/15 11:48, Martin Basti wrote:
> >>On 27/05/15 16:04, Fraser Tweedale wrote:
> >>>Hello all,
> >>>
> >>>Fresh certificate management patchset; Changelog:
> >>>
> >>>- Now depends on patch freeipa-ftweedal-0014 for correct
> >>>cert-request behaviour with host and service principals.
> >>>
> >>>- Updated Dogtag dependency to 10.2.4-1.  Should should be in
> >>>f22 soon, but for f22 right now or for f21, please grab from my
> >>>copr: https://copr.fedoraproject.org/coprs/ftweedal/freeipa/
> >>>
> >>>Martin^1 could you please add to the quasi-official freeipa
> >>>copr?  SRPM lives at
> >>>https://frase.id.au/pki-core-10.2.4-1.fc21.src.rpm.
> >>>
> >>>- cert-request now verifies that for user principals, CSR CN
> >>>matches uid and, DN emailAddress and SAN rfc822Name match 
> >>>user's
> >>>email address, if either of those is present.
> >>>
> >>>- Fixed one or two other sneaky little bugs.
> >>>
> >>>On Wed, May 27, 2015 at 01:59:30AM +1000, Fraser Tweedale 
> >>>wrote:
> Hi all,
> 
> Please find attached the latest certificate management
> patchset, which introduces the `caacl' plugin and various 
> fixes
> and improvement to earlier patches.
> 
> One important change to earlier patches is reverting the name
> of the default profile to 'caIPAserviceCert' and using the
> existing instance of this profile on upgrade (but not install)
> in case it has been modified.
> 
> Other notes:
> 
> - Still have changes in ipa-server-install (fewer lines now,
> though)
> 
> - Still have the ugly import hack.  It is not a high priority
> for me, i.e. I think it should wait until after alpha
> 
> - Still need to update 'service' and 'host' plugins to support
> multiple certificates.  (The userCertificate attribute schema
> itself is multi-valued, so there are no schema issues here)
> 
> - The TODOs in [1]; mostly certprofile CLI conveniences and
> supporting multiple profiles for hosts and services (which
> requires changes to framework only, not schema).  [1]:
> http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress
> 
> Happy reviewing!  I am pleased with the initial cut of the
> caacl plugin but I'm sure you will find some things to be 
> fixed
> :)
> 
> Cheers, Fraser
> >>[root@vm-093 ~]#  ipa-replica-prepare vm-094.example.com
> >>--ip-address 10.34.78.94 Directory Manager (existing master)
> >>password:
> >>
> >>Preparing replica for vm-094.example.com from vm-093.example.com
> >>Creating SSL certificate for the Directory Server not 
> >>well-formed
> >>(invalid token): line 2, column 14
> >>
> >>I cannot create replica file.  It work on the upgraded server,
> >>but it doesn't work on the newly installed server.  I'm not sure
> >>if this causes your patches which modifies the ca-installer, or
> >>the newer version of dogtag.
> >>
> >>Or if there was any other changes in master, I will continue to
> >>investigate with new RPM from master branch.
> >>
> >>Martin^2
> >>
> >ipa-replica-prepare works for: * master branch * master branch +
> >pki-ca 10.2.4-1
>