Re: [Freeipa-devel] The Community Auth.NEXT Working Group Inagural Meeting

2015-09-30 Thread Alexander Bokovoy 

On Tue, 29 Sep 2015, Brian Stinson wrote:

Hi FreeIPA!

We are starting a working group of member projects looking to solve problems
related to Community Authentication. The FreeIPA Community Portal feature added
this summer is one of the important bits we are evaluating.

We are hoping to collaborate on centos-de...@centos.org, and have IRC meetings
in #centos-devel on Freenode every now and then to check in. We currently have
interest from CentOS, Fedora, and a few other projects, and would love to
invite anyone interested to participate.

Patrick Uiterwijk will be starting a thread soon scheduling our next IRC
meeting in 2 weeks time.

Thanks, Brian.

There is also community-auth-next...@lists.fedoraproject.org for the same
purpose around Fedora Project needs. Reading your first meeting notes,
it is unclear why we couldn't use this list and would instead need to
subscribe to centos-devel@ (which I assume has more than this topic to
discuss).



Here are the minutes from our first meeting:

=
#centos-devel: Community Authentication Working Group Meeting 29-Sep-2015
=


Meeting started by puiterwijk at 13:00:07 UTC. The full logs are
available at 
https://www.centos.org/minutes/2015/september/centos-devel.2015-09-29-13.00.html



Meeting summary
---
* Working Group Intro  (puiterwijk, 13:00:27)
 * LINK:
   https://lists.centos.org/pipermail/centos-devel/2015-September/013854.html
   (puiterwijk, 13:03:22)
 * AGREED: mailing list for discussions: centos-devel, notifications
   cross-posted to community-auth-next-wg list at fedorahosted
   (puiterwijk, 13:17:59)
 * ACTION: bstinson to distribute minutes to the IPA team, and do a
   call for a WG representative  (bstinson, 13:25:41)

* Goals  (puiterwijk, 13:28:13)
 * LINK:
   
https://lists.fedorahosted.org/pipermail/community-auth-next-wg/2015-September/00.html
   (puiterwijk, 13:28:43)
 * AGREED: adopt puiterwijk's two goals from the community-auth-next-wg
   mailing list, and add in a technical goal of collaborating on a FAS
   -> IPA migration  (puiterwijk, 13:42:02)
 * Agreed: adopt puiterwijk's two goals from the community-auth-next-wg
   mailing list, and add in a technical goal of collaborating on a FAS
   -> IPA migration  (puiterwijk, 13:42:38)
 * GOAL: determine what features FreeIPA with the community portal
   lacks to replace FAS for community projects  (bstinson, 13:42:44)
 * GOAL: coordinate their development if the FreeIPA community is
   willing to add them to make FreeIPA a valid replacement for FAS
   (bstinson, 13:43:05)
 * GOAL: ensuring that there is a migration path from FAS => IPA
   (bstinson, 13:43:20)
 * Neither Fedora Infra nor CentOS will commit to moving to IPA as part
   of this working group at this point  (puiterwijk, 13:44:46)
 * ACTION: puiterwijk to start a requirements gathering thread
   (bstinson, 13:50:13)
 * ACTION: puiterwijk to start a "scheduling" thread for the next
   syncup meeting (~2 weeks)  (bstinson, 13:55:46)
 * ACTION: bstinson to cross-post the first meeting's minutes to
   centos-devel, community-auth-next-wg, and freeipa-devel(with an
   introduction)  (bstinson, 13:56:13)

* Open floor  (puiterwijk, 13:57:02)

Meeting ended at 13:58:01 UTC.




Action Items

* bstinson to distribute minutes to the IPA team, and do a call for a WG
 representative
* puiterwijk to start a requirements gathering thread
* puiterwijk to start a "scheduling" thread for the next syncup meeting
 (~2 weeks)
* bstinson to cross-post the first meeting's minutes to centos-devel,
 community-auth-next-wg, and freeipa-devel(with an introduction)




Action Items, by person
---
* bstinson
 * bstinson to distribute minutes to the IPA team, and do a call for a
   WG representative
 * bstinson to cross-post the first meeting's minutes to centos-devel,
   community-auth-next-wg, and freeipa-devel(with an introduction)
* puiterwijk
 * puiterwijk to start a requirements gathering thread
 * puiterwijk to start a "scheduling" thread for the next syncup
   meeting (~2 weeks)
* **UNASSIGNED**
 * (none)




People Present (lines said)
---
* puiterwijk (84)
* bstinson (46)
* Arrfab (16)
* csim (15)
* gwd (3)
* centbot (3)
* kbsingh (2)
* billings (2)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot


Cheers!

--
Brian Stinson
CentOS Infrastructure Team

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


--
/ 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] More Python 3 porting

2015-09-30 Thread Petr Viktorin 
On 09/23/2015 04:46 PM, Petr Viktorin wrote:
> On 09/22/2015 02:59 PM, David Kupka wrote:
>> On 18/09/15 17:00, Petr Viktorin wrote:
>>> Hello,
>>> Here are more patches that bring IPA closer to Python 3 compatibility.
>>>
>>>
>>>
>>>
>>
>> Hi Petr,
>> thanks for another batch of Python 3 compatibility patches.
>> Unfortunately I hit a lot of pylint errors. Some of them are false
>> positives for sure. Could you please look at them, mark the false
>> positive with "pylint: disable=E" directive and fix the rest?
>>
>> http://fpaste.org/270090/92665414/
>>
> 
> Thanks.
> I'm actually having some trouble running pylint on an f23 machine; have
> you seen this error before?
> 
> $ ./make-lint
> Traceback (most recent call last):
>   File "./make-lint", line 280, in 
> sys.exit(main())
>   File "./make-lint", line 251, in main
> linter.check(files)
>   File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 747, in check
> self._do_check(files_or_modules)
>   File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 869, in
> _do_check
> self.check_astroid_module(ast_node, walker, rawcheckers, tokencheckers)
>   File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 924, in
> check_astroid_module
> tokens = utils.tokenize_module(ast_node)
>   File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 137, in
> tokenize_module
> with module.stream() as stream:
> AttributeError: 'Module' object has no attribute 'stream'
> 
> 
> Anyway, I've ran pylint on f21. Updated patches attached.

ping, could someone take a look at the patches?


-- 
Petr Viktorin

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

Re: [Freeipa-devel] [PATCH] Replace StandardError with Exception

2015-09-30 Thread Jan Cholasta 

On 24.9.2015 11:02, Petr Viktorin wrote:

On 09/17/2015 05:35 PM, Petr Viktorin wrote:

Hello,
In Python 2, Exception has only two built-in subclasses: StandardError,
and StopIteration.
This makes StandardError pretty useless, and Python 3 removes it.

This patch replaces StandardError with Exception. It has no effect on
IPA code. However, it could theoretically affect external plugins (e.g.
if they do "except StandardError").


ping, anybody for review of this patch?


Works for me, ACK.

Pushed to master: 01da4a8de3ed8651cc95df6125751e1603dbd14e

--
Jan Cholasta

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

Re: [Freeipa-devel] [PATCH] Proper fix for ticket 5306

2015-09-30 Thread Oleg Fayans 

Guys,

could you please review this patch again? I'd like to have this fix in 
the new ipa-tests package for downstream team



On 09/29/2015 09:12 AM, Oleg Fayans wrote:

Hi all,

On 09/23/2015 09:13 AM, Petr Spacek wrote:

On 22.9.2015 10:42, Oleg Fayans wrote:

+++ b/ipatests/test_integration/tasks.py
@@ -58,6 +58,14 @@ def check_arguments_are(slice, instanceof):
  return wrapped
  return wrapper

+def prepare_reverse_zone(host, ip):
+nums = ip.split('.')[:-1]
+zone = ".".join(reversed(nums)) + ".in-addr.arpa."
+host.run_command(["ipa",
+  "dnszone-add",
+  zone,
+  "--name-from-ip=%s" % ip], raiseonerr=False)
+


NACK:
- this will break IPv6-only hosts
- you should use DNSName class or other functions from python-dns for
DNS name
manipulation

I hope this helps.


Thanks, it did :)
Used a ipalib.util get_reverse_zone_default function that does just
that: creates a reverse zone name.





--
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] [PATCH] Proper fix for ticket 5306

2015-09-30 Thread Martin Basti 



On 09/30/2015 12:19 PM, Oleg Fayans wrote:



On 09/30/2015 11:46 AM, Petr Spacek wrote:

On 29.9.2015 09:12, Oleg Fayans wrote:

+def prepare_reverse_zone(host, ip):
+zone = get_reverse_zone_default(ip)
+host.run_command(["ipa",
+  "dnszone-add",
+  zone,
+  "--name-from-ip=%s" % ip], raiseonerr=False)


There is probably no point in specifying --name-from-ip because you 
did that

already by calling get_reverse_zone_default(ip).


Agree. Fixed



Anyway, I'm not sure that this

+prepare_reverse_zone(master, replica.ip)
will not break if the reverse zone already exists (think about case 
where two

or more replicas are in the same subnet).


That's why I am using the raiseonerr=False here.



I did not test the code, I simply do not have time for it right now.






 LGTM, I will test it soon, but it needs rebase for ipa-4-2 branch
-- 
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] Proper fix for ticket 5306

2015-09-30 Thread Petr Spacek 
On 29.9.2015 09:12, Oleg Fayans wrote:
> +def prepare_reverse_zone(host, ip):
> +zone = get_reverse_zone_default(ip)
> +host.run_command(["ipa",
> +  "dnszone-add",
> +  zone,
> +  "--name-from-ip=%s" % ip], raiseonerr=False)

There is probably no point in specifying --name-from-ip because you did that
already by calling get_reverse_zone_default(ip).

Anyway, I'm not sure that this
> +prepare_reverse_zone(master, replica.ip)
will not break if the reverse zone already exists (think about case where two
or more replicas are in the same subnet).

I did not test the code, I simply do not have time for it right now.

-- 
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] [rfc-dist] RFC 7642 on System for Cross-domain Identity Management (SCIM)

2015-09-30 Thread Martin Kosek 
Thanks for sharing. Just for the record, there was a lot of SCIM related
presentations at the latest LDAPCon where FreeIPA was present as well:

http://lanyrd.com/2013/ldapcon/

I would like to know if there is actually any FreeIPA user interested in this
type of interface, worth asking on freeipa-users?

On 09/29/2015 08:51 AM, Petr Spacek wrote:
> Hello,
> 
> I did not read any of the RFCs referenced below, but it sounds relevant to us:
> 
> 1.  Introduction
> 
> [...]
> 
>Unlike the practice of some protocols like Application Bridging for
>Federated Access Beyond web (ABFAB) and SAML2 WebSSO, SCIM provides
>provisioning and de-provisioning of resources in a separate context
>from authentication (aka just-in-time provisioning).
> 
> [...]
> 
> 2.  SCIM User Scenarios
> 
> 2.1.  Background and Context
> 
>The System for Cross-domain Identity Management (SCIM) specification
>is designed to manage user identity in cloud-based applications and
>services in a standardized way to enable interoperability, security,
>and scalability.  The specification suite seeks to build upon
>experience with existing schemas and deployments, placing specific
>emphasis on simplicity of development and integration, while applying
>existing authentication, authorization, and privacy models.  The
>intent of the SCIM specification is to reduce the cost and complexity
>of user management operations by providing a common user schema and
>extension model, as well as binding documents to provide patterns for
>exchanging this schema using standard protocols.  In essence, make it
>fast, cheap, and easy to move users in to, out of, and around the
>cloud.
> 
> Links:
> * http://tools.ietf.org/html/rfc7642
> * http://tools.ietf.org/html/rfc7643
> * http://tools.ietf.org/html/rfc7644
> 
> 
> I hope this is not just noise.
> 
> Petr^2 Spacek
> 
> 
> 
>  Forwarded Message 
> Subject: [rfc-dist] RFC 7642 on System for Cross-domain Identity Management:
> Definitions, Overview, Concepts, and Requirements
> Date: Fri, 25 Sep 2015 16:34:54 -0700 (PDT)
> From: rfc-edi...@rfc-editor.org
> To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
> CC: drafts-update-...@iana.org, s...@ietf.org, rfc-edi...@rfc-editor.org
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
> RFC 7642
> 
> Title:  System for Cross-domain Identity Management:
> Definitions, Overview, Concepts, and Requirements
> Author: K. LI, Ed., P. Hunt, B. Khasnabish,
> A. Nadalin, Z. Zeltsan
> Status: Informational
> Stream: IETF
> Date:   September 2015
> Mailbox:kepeng@alibaba-inc.com,
> phil.h...@oracle.com,
> vum...@gmail.com,  tony...@microsoft.com,
> zachary.zelt...@gmail.com
> Pages:  19
> Characters: 38759
> Updates/Obsoletes/SeeAlso:   None
> 
> I-D Tag:draft-ietf-scim-use-cases-08.txt
> 
> URL:https://www.rfc-editor.org/info/rfc7642
> 
> DOI:http://dx.doi.org/10.17487/RFC7642
> 
> This document provides definitions and an overview of the System for
> Cross-domain Identity Management (SCIM).  It lays out the system's
> concepts, models, and flows, and it includes user scenarios, use
> cases, and requirements.
> 
> This document is a product of the System for Cross-domain Identity Management
> Working Group of the IETF.
> 
> 
> INFORMATIONAL: This memo provides information for the Internet community.
> It does not specify an Internet standard of any kind. Distribution of
> this memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   https://www.ietf.org/mailman/listinfo/ietf-announce
>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/rfc.html
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 
> ___
> rfc-dist mailing list
> rfc-d...@rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-dist
> http://www.rfc-editor.org
> 
> 
> 

-- 
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] Proper fix for ticket 5306

2015-09-30 Thread Oleg Fayans 



On 09/30/2015 11:46 AM, Petr Spacek wrote:

On 29.9.2015 09:12, Oleg Fayans wrote:

+def prepare_reverse_zone(host, ip):
+zone = get_reverse_zone_default(ip)
+host.run_command(["ipa",
+  "dnszone-add",
+  zone,
+  "--name-from-ip=%s" % ip], raiseonerr=False)


There is probably no point in specifying --name-from-ip because you did that
already by calling get_reverse_zone_default(ip).


Agree. Fixed



Anyway, I'm not sure that this

+prepare_reverse_zone(master, replica.ip)

will not break if the reverse zone already exists (think about case where two
or more replicas are in the same subnet).


That's why I am using the raiseonerr=False here.



I did not test the code, I simply do not have time for it right now.



--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.
From c4e662394ad9b2dd6ce6a6c5aae570724d1028b0 Mon Sep 17 00:00:00 2001
From: Oleg Fayans 
Date: Wed, 30 Sep 2015 12:17:53 +0200
Subject: [PATCH] Added a proper workaround for dnssec test failures in Beaker
 environment

In beaker lab the situation when master and replica have ip addresses from
different subnets is quite frequent. When a replica has ip from different
subnet than master's, ipa-replica-prepare looks up a proper reverse zone to
add a pointer record, and if it does not find it, it asks a user for permission
to create it automatically. It breaks the tests adding the unexpected input.
The workaround is to always create a reverse zone for a new replica.

Corresponding ticket is https://fedorahosted.org/freeipa/ticket/5306
---
 ipatests/test_integration/tasks.py | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py
index 06049d4ae01332e0af4d8775b745342406fc868d..63e1018388efbee282f657052f93bb255287d899 100644
--- a/ipatests/test_integration/tasks.py
+++ b/ipatests/test_integration/tasks.py
@@ -37,6 +37,7 @@ from ipapython.ipa_log_manager import log_mgr
 from ipatests.test_integration import util
 from ipatests.test_integration.env_config import env_to_script
 from ipatests.test_integration.host import Host
+from ipalib.util import get_reverse_zone_default
 
 log = log_mgr.get_logger(__name__)
 
@@ -58,6 +59,11 @@ def check_arguments_are(slice, instanceof):
 return wrapped
 return wrapper
 
+def prepare_reverse_zone(host, ip):
+zone = get_reverse_zone_default(ip)
+host.run_command(["ipa",
+  "dnszone-add",
+  zone], raiseonerr=False)
 
 def prepare_host(host):
 if isinstance(host, Host):
@@ -240,17 +246,17 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False):
 
 apply_common_fixes(replica)
 fix_apache_semaphores(replica)
-
+prepare_reverse_zone(master, replica.ip)
 master.run_command(['ipa-replica-prepare',
 '-p', replica.config.dirman_password,
-'--ip-address', replica.ip, '--no-reverse',
+'--ip-address', replica.ip,
 replica.hostname])
 replica_bundle = master.get_file_contents(
 paths.REPLICA_INFO_GPG_TEMPLATE % replica.hostname)
 replica_filename = os.path.join(replica.config.test_dir,
 'replica-info.gpg')
 replica.put_file_contents(replica_filename, replica_bundle)
-args = ['ipa-replica-install', '-U', '--no-host-dns',
+args = ['ipa-replica-install', '-U',
 '-p', replica.config.dirman_password,
 '-w', replica.config.admin_password,
 '--ip-address', replica.ip,
-- 
2.4.3

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

Re: [Freeipa-devel] [PATCH 0012-0019] CA ACL tracker and functional test

2015-09-30 Thread Martin Basti 



On 09/24/2015 02:49 PM, Milan Kubík wrote:

Hi all,

an update for CA ACL tests!

I, with help from M. Babinsky, managed to find a way how to change the 
identity during acceptance cest run, which allows
to test CA ACLs (and perhaps other areas with some form of access 
controll).


This allowed me to write a test for CA ACLs and certificate profiles 
that checks if the ACL/profile is being used and enforced.
The first several tests are based on Fraser's blogpost using SMIME 
profile [1].


The master and ipa-4-2 branches diverged a bit, so I had to change two 
commits when rebasing to ipa-4-2 branch.


Commits should be applied in the order (including rebased patches I 
sent in an earlier email):


master:
* 12 - 17

ipa-4-2:
* 18, 13 - 15, 19, 17

For convenience:
patches on top of master: 
https://github.com/apophys/freeipa/tree/acl-profile-functional

patches on top of ipa-4-2: https://github.com/apophys/freeipa/tree/acl-42


[1]: 
https://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/


Cheers,
Milan




NACK

0)
rpm file does not contain test_xmlrpc/data directory, please modify 
setup.py.in.


1)
Code contains to much todo for my taste.

2)
Please do not use filter function, use dict comprehension.

-- 
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] [PATCHSET] Replica promotion patches

2015-09-30 Thread Jan Cholasta 

On 24.9.2015 15:10, Simo Sorce wrote:

On 24/09/15 04:43, Martin Basti wrote:



On 09/24/2015 02:25 AM, Martin Basti wrote:



On 09/22/2015 10:45 AM, Jan Cholasta wrote:

Hi,

On 9.9.2015 20:25, Simo Sorce wrote:

On Wed, 2015-08-26 at 17:27 -0400, Simo Sorce wrote:

This patchset implements https://fedorahosted.org/freeipa/ticket/2888
and introduces a number of required  changes and dependencies to
achieve
this goal.
This work requires the custodia project to securely transfer keys
between ipa servers.

This work is not 100% complete, it still misses the ability to
install
kra instances and the ability to install a CA (via ipa-ca-install)
with
externally signed certs.

However it is massive enough that warrants review and pushing, the
resat
of the changes can be applied later as this work should not disrupt
the
classic install methods.

In order to build my previous patches (530-533) are needed as well
as a
number of updated components.

I used the following coprs for testing:
simo/jwcrypto
simo/custodia
abbra/sssd-kkdcproxy (for sssd 1.13.1)
lkrispen/389-ds-current (for 389 > 1.3.4.4)
vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7)
mkosek/freeipa-4.2-fedora-22 (misc)
fedora/updates-testing (python-gssapi 1.1.2)

Ludwig's copr is necessary to have a functional DNA plugin in
replicas,
eventually his patches should be committed in 389-ds-base 1.3.4.4
when
it will be released.

We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580
that may cause installation issues in some case (re-install of a
replica).

The domain must be raised to level 1 in order to use replica
promotion.

In order to promote a replica the server must be first joined as a
regular client to the domain.

This is the flow I usually use for testing:

# ipa-client-install
# kinit admin
# ipa-replica-install --promote --setup-ca


These patches are also available in this git tree rebnase on current
master:
https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review




FYI: I rebased this branch on top of master and applied minor
changes to
one of the DNS patches. I also added the missing support to install
KRA.

DS 1.3.4.4 is also in Fedora updates testing, so ludwig's copr is not
needed anymore.

Dogtag's ticket is not fixed yet so running both --setup-ca and
--setup-kra at the same time will still yield an error and install
will
fail.

Please let me know if there are any major issues with this patchset,
I'd
like to push it to master and attack the remaining issues as add ons
(install with external certs not supported yet for example)


So far I have only read through the code without running it (mostly).


"Remove unused arguments": ACK


"Simplify the install_replica_ca function": ACK


"IPA Custodia Daemon":

1) Instead of putting the code in "ipakeys" package, could you put it
in "ipapython.keys"? This way it would be consistent with DNSSEC,
which has binaries in daemons/dnssec/ and modules in ipapython/dnssec/.

2) Is it safe to create cn=custodia in update file only? Updates are
executed late in ipa-server-install. Is is guaranteed that nothing
will try to access cn=custodia before the updates are run?

(Nevermind, it is added to bootstrap-template.ldif 2 commits below.)

3) Shouldn't cn=custodia be created only when domain level >= 1?

4) pylint fails with:

daemons/ipa-custodia/ipakeys/kem.py:156: [E1002(super-on-old-class),
IPAKEMKeys.__init__] Use of super on an old style class)
daemons/ipa-custodia/ipakeys/kem.py:178: [E1101(no-member),
IPAKEMKeys.generate_server_keys] Instance of 'IPAKEMKeys' has no
'config' member)
daemons/ipa-custodia/ipakeys/kem.py:187: [E1101(no-member),
IPAKEMKeys.server_keys] Instance of 'IPAKEMKeys' has no 'config'
member)

5) There are some PEP8 transgressions:

./daemons/ipa-custodia/ipakeys/kem.py:202:80: E501 line too long (82
> 79 characters)
./daemons/ipa-custodia/ipakeys/kem.py:203:80: E501 line too long (82
> 79 characters)
./daemons/ipa-custodia/ipakeys/store.py:33:1: E302 expected 2 blank
lines, found 1
./daemons/ipa-custodia/setup.py:8:9: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:8:11: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:9:12: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:9:14: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:10:12: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:10:14: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:11:15: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:11:17: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:12:21: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:12:23: E251 unexpected spaces around
keyword / parameter equals

Re: [Freeipa-devel] [PATCHSET] Replica promotion patches

2015-09-30 Thread Simo Sorce 

On 30/09/15 08:32, Jan Cholasta wrote:

On 24.9.2015 15:10, Simo Sorce wrote:

On 24/09/15 04:43, Martin Basti wrote:



On 09/24/2015 02:25 AM, Martin Basti wrote:



On 09/22/2015 10:45 AM, Jan Cholasta wrote:

Hi,

On 9.9.2015 20:25, Simo Sorce wrote:

On Wed, 2015-08-26 at 17:27 -0400, Simo Sorce wrote:

This patchset implements
https://fedorahosted.org/freeipa/ticket/2888
and introduces a number of required  changes and dependencies to
achieve
this goal.
This work requires the custodia project to securely transfer keys
between ipa servers.

This work is not 100% complete, it still misses the ability to
install
kra instances and the ability to install a CA (via ipa-ca-install)
with
externally signed certs.

However it is massive enough that warrants review and pushing, the
resat
of the changes can be applied later as this work should not disrupt
the
classic install methods.

In order to build my previous patches (530-533) are needed as well
as a
number of updated components.

I used the following coprs for testing:
simo/jwcrypto
simo/custodia
abbra/sssd-kkdcproxy (for sssd 1.13.1)
lkrispen/389-ds-current (for 389 > 1.3.4.4)
vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7)
mkosek/freeipa-4.2-fedora-22 (misc)
fedora/updates-testing (python-gssapi 1.1.2)

Ludwig's copr is necessary to have a functional DNA plugin in
replicas,
eventually his patches should be committed in 389-ds-base 1.3.4.4
when
it will be released.

We are aware of a dogtag bug
https://fedorahosted.org/pki/ticket/1580
that may cause installation issues in some case (re-install of a
replica).

The domain must be raised to level 1 in order to use replica
promotion.

In order to promote a replica the server must be first joined as a
regular client to the domain.

This is the flow I usually use for testing:

# ipa-client-install
# kinit admin
# ipa-replica-install --promote --setup-ca


These patches are also available in this git tree rebnase on current
master:
https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review





FYI: I rebased this branch on top of master and applied minor
changes to
one of the DNS patches. I also added the missing support to install
KRA.

DS 1.3.4.4 is also in Fedora updates testing, so ludwig's copr is not
needed anymore.

Dogtag's ticket is not fixed yet so running both --setup-ca and
--setup-kra at the same time will still yield an error and install
will
fail.

Please let me know if there are any major issues with this patchset,
I'd
like to push it to master and attack the remaining issues as add ons
(install with external certs not supported yet for example)


So far I have only read through the code without running it (mostly).


"Remove unused arguments": ACK


"Simplify the install_replica_ca function": ACK


"IPA Custodia Daemon":

1) Instead of putting the code in "ipakeys" package, could you put it
in "ipapython.keys"? This way it would be consistent with DNSSEC,
which has binaries in daemons/dnssec/ and modules in
ipapython/dnssec/.

2) Is it safe to create cn=custodia in update file only? Updates are
executed late in ipa-server-install. Is is guaranteed that nothing
will try to access cn=custodia before the updates are run?

(Nevermind, it is added to bootstrap-template.ldif 2 commits below.)

3) Shouldn't cn=custodia be created only when domain level >= 1?

4) pylint fails with:

daemons/ipa-custodia/ipakeys/kem.py:156: [E1002(super-on-old-class),
IPAKEMKeys.__init__] Use of super on an old style class)
daemons/ipa-custodia/ipakeys/kem.py:178: [E1101(no-member),
IPAKEMKeys.generate_server_keys] Instance of 'IPAKEMKeys' has no
'config' member)
daemons/ipa-custodia/ipakeys/kem.py:187: [E1101(no-member),
IPAKEMKeys.server_keys] Instance of 'IPAKEMKeys' has no 'config'
member)

5) There are some PEP8 transgressions:

./daemons/ipa-custodia/ipakeys/kem.py:202:80: E501 line too long (82
> 79 characters)
./daemons/ipa-custodia/ipakeys/kem.py:203:80: E501 line too long (82
> 79 characters)
./daemons/ipa-custodia/ipakeys/store.py:33:1: E302 expected 2 blank
lines, found 1
./daemons/ipa-custodia/setup.py:8:9: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:8:11: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:9:12: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:9:14: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:10:12: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:10:14: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:11:15: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:11:17: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:12:21: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:12:23: E251 unexpected spaces

Re: [Freeipa-devel] The Community Auth.NEXT Working Group Inagural Meeting

2015-09-30 Thread Christian Heimes 
On 2015-09-30 08:05, Alexander Bokovoy wrote:
> On Tue, 29 Sep 2015, Brian Stinson wrote:
>> Hi FreeIPA!
>>
>> We are starting a working group of member projects looking to solve
>> problems
>> related to Community Authentication. The FreeIPA Community Portal
>> feature added
>> this summer is one of the important bits we are evaluating.
>>
>> We are hoping to collaborate on centos-de...@centos.org, and have IRC
>> meetings
>> in #centos-devel on Freenode every now and then to check in. We
>> currently have
>> interest from CentOS, Fedora, and a few other projects, and would love to
>> invite anyone interested to participate.
>>
>> Patrick Uiterwijk will be starting a thread soon scheduling our next IRC
>> meeting in 2 weeks time.
> Thanks, Brian.
> 
> There is also community-auth-next...@lists.fedoraproject.org for the same
> purpose around Fedora Project needs. Reading your first meeting notes,
> it is unclear why we couldn't use this list and would instead need to
> subscribe to centos-devel@ (which I assume has more than this topic to
> discuss).

Hi Brian,

thanks for your mail and for keeping us in the loop.

I agree with Alexander's suggestion to use Patrick's new mailing list
community-auth-next-wg. The centos-devel mailing list and #centos-devel
channel are too busy to follow. For me and the other FreeIPA devs a
dedicated mailing list has a better signal to noise ratio. I'm already
subscribed to more mailing lists than I'm able to read on a daily bases...

About the working-group representative for FreeIPA, I'm probably the
best candidate. I'm familiar with the community portal. For the next
months I'm busy with another project, but I can spare one to two hours a
week to give feedback.

I also like to get started on the design process early. Some neessary
features and changes belong in the FreeIPA core, e.g. password change or
unique email addresses. I like to addresss the modifications in FreeIPA 4.4.

Christian



signature.asc
Description: OpenPGP digital 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

Re: [Freeipa-devel] The Community Auth.NEXT Working Group Inagural Meeting

2015-09-30 Thread Brian Stinson 
On Sep 30 09:05, Alexander Bokovoy wrote:
> On Tue, 29 Sep 2015, Brian Stinson wrote:
> >Hi FreeIPA!
> >
> >We are starting a working group of member projects looking to solve problems
> >related to Community Authentication. The FreeIPA Community Portal feature 
> >added
> >this summer is one of the important bits we are evaluating.
> >
> >We are hoping to collaborate on centos-de...@centos.org, and have IRC 
> >meetings
> >in #centos-devel on Freenode every now and then to check in. We currently 
> >have
> >interest from CentOS, Fedora, and a few other projects, and would love to
> >invite anyone interested to participate.
> >
> >Patrick Uiterwijk will be starting a thread soon scheduling our next IRC
> >meeting in 2 weeks time.
> Thanks, Brian.
> 
> There is also community-auth-next...@lists.fedoraproject.org for the same
> purpose around Fedora Project needs. Reading your first meeting notes,
> it is unclear why we couldn't use this list and would instead need to
> subscribe to centos-devel@ (which I assume has more than this topic to
> discuss).
> 
> >
> >Here are the minutes from our first meeting:
> >
> >=
> >#centos-devel: Community Authentication Working Group Meeting 29-Sep-2015
> >=
> >
> >
> >Meeting started by puiterwijk at 13:00:07 UTC. The full logs are
> >available at 
> >https://www.centos.org/minutes/2015/september/centos-devel.2015-09-29-13.00.html
> >
> >
> >
> >Meeting summary
> >---
> >* Working Group Intro  (puiterwijk, 13:00:27)
> > * LINK:
> >   https://lists.centos.org/pipermail/centos-devel/2015-September/013854.html
> >   (puiterwijk, 13:03:22)
> > * AGREED: mailing list for discussions: centos-devel, notifications
> >   cross-posted to community-auth-next-wg list at fedorahosted
> >   (puiterwijk, 13:17:59)
> > * ACTION: bstinson to distribute minutes to the IPA team, and do a
> >   call for a WG representative  (bstinson, 13:25:41)
> >
> >* Goals  (puiterwijk, 13:28:13)
> > * LINK:
> >   
> > https://lists.fedorahosted.org/pipermail/community-auth-next-wg/2015-September/00.html
> >   (puiterwijk, 13:28:43)
> > * AGREED: adopt puiterwijk's two goals from the community-auth-next-wg
> >   mailing list, and add in a technical goal of collaborating on a FAS
> >   -> IPA migration  (puiterwijk, 13:42:02)
> > * Agreed: adopt puiterwijk's two goals from the community-auth-next-wg
> >   mailing list, and add in a technical goal of collaborating on a FAS
> >   -> IPA migration  (puiterwijk, 13:42:38)
> > * GOAL: determine what features FreeIPA with the community portal
> >   lacks to replace FAS for community projects  (bstinson, 13:42:44)
> > * GOAL: coordinate their development if the FreeIPA community is
> >   willing to add them to make FreeIPA a valid replacement for FAS
> >   (bstinson, 13:43:05)
> > * GOAL: ensuring that there is a migration path from FAS => IPA
> >   (bstinson, 13:43:20)
> > * Neither Fedora Infra nor CentOS will commit to moving to IPA as part
> >   of this working group at this point  (puiterwijk, 13:44:46)
> > * ACTION: puiterwijk to start a requirements gathering thread
> >   (bstinson, 13:50:13)
> > * ACTION: puiterwijk to start a "scheduling" thread for the next
> >   syncup meeting (~2 weeks)  (bstinson, 13:55:46)
> > * ACTION: bstinson to cross-post the first meeting's minutes to
> >   centos-devel, community-auth-next-wg, and freeipa-devel(with an
> >   introduction)  (bstinson, 13:56:13)
> >
> >* Open floor  (puiterwijk, 13:57:02)
> >
> >Meeting ended at 13:58:01 UTC.
> >
> >
> >
> >
> >Action Items
> >
> >* bstinson to distribute minutes to the IPA team, and do a call for a WG
> > representative
> >* puiterwijk to start a requirements gathering thread
> >* puiterwijk to start a "scheduling" thread for the next syncup meeting
> > (~2 weeks)
> >* bstinson to cross-post the first meeting's minutes to centos-devel,
> > community-auth-next-wg, and freeipa-devel(with an introduction)
> >
> >
> >
> >
> >Action Items, by person
> >---
> >* bstinson
> > * bstinson to distribute minutes to the IPA team, and do a call for a
> >   WG representative
> > * bstinson to cross-post the first meeting's minutes to centos-devel,
> >   community-auth-next-wg, and freeipa-devel(with an introduction)
> >* puiterwijk
> > * puiterwijk to start a requirements gathering thread
> > * puiterwijk to start a "scheduling" thread for the next syncup
> >   meeting (~2 weeks)
> >* **UNASSIGNED**
> > * (none)
> >
> >
> >
> >
> >People Present (lines said)
> >---
> >* puiterwijk (84)
> >* bstinson (46)
> >* Arrfab (16)
> >* csim (15)
> >* gwd (3)
> >* centbot (3)
> >* kbsingh (2)
> >* billings (2)
> >
> >
> >
> >
> >Generated by `MeetBot`_ 0.1.4
> >
> >.. _`MeetBot`: http://wiki.debian.org/MeetBot
> >
> >
> >Cheers!
> >
> >--
> >Brian Stinson
> >CentOS Infrastructure Team
> >

Re: [Freeipa-devel] [PATCHSET] Replica promotion patches

2015-09-30 Thread Jan Cholasta 

On 30.9.2015 15:15, Simo Sorce wrote:

On 30/09/15 08:32, Jan Cholasta wrote:

On 24.9.2015 15:10, Simo Sorce wrote:

On 24/09/15 04:43, Martin Basti wrote:



On 09/24/2015 02:25 AM, Martin Basti wrote:



On 09/22/2015 10:45 AM, Jan Cholasta wrote:

Hi,

On 9.9.2015 20:25, Simo Sorce wrote:

On Wed, 2015-08-26 at 17:27 -0400, Simo Sorce wrote:

This patchset implements
https://fedorahosted.org/freeipa/ticket/2888
and introduces a number of required  changes and dependencies to
achieve
this goal.
This work requires the custodia project to securely transfer keys
between ipa servers.

This work is not 100% complete, it still misses the ability to
install
kra instances and the ability to install a CA (via ipa-ca-install)
with
externally signed certs.

However it is massive enough that warrants review and pushing, the
resat
of the changes can be applied later as this work should not disrupt
the
classic install methods.

In order to build my previous patches (530-533) are needed as well
as a
number of updated components.

I used the following coprs for testing:
simo/jwcrypto
simo/custodia
abbra/sssd-kkdcproxy (for sssd 1.13.1)
lkrispen/389-ds-current (for 389 > 1.3.4.4)
vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7)
mkosek/freeipa-4.2-fedora-22 (misc)
fedora/updates-testing (python-gssapi 1.1.2)

Ludwig's copr is necessary to have a functional DNA plugin in
replicas,
eventually his patches should be committed in 389-ds-base 1.3.4.4
when
it will be released.

We are aware of a dogtag bug
https://fedorahosted.org/pki/ticket/1580
that may cause installation issues in some case (re-install of a
replica).

The domain must be raised to level 1 in order to use replica
promotion.

In order to promote a replica the server must be first joined as a
regular client to the domain.

This is the flow I usually use for testing:

# ipa-client-install
# kinit admin
# ipa-replica-install --promote --setup-ca


These patches are also available in this git tree rebnase on
current
master:
https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review






FYI: I rebased this branch on top of master and applied minor
changes to
one of the DNS patches. I also added the missing support to install
KRA.

DS 1.3.4.4 is also in Fedora updates testing, so ludwig's copr is
not
needed anymore.

Dogtag's ticket is not fixed yet so running both --setup-ca and
--setup-kra at the same time will still yield an error and install
will
fail.

Please let me know if there are any major issues with this patchset,
I'd
like to push it to master and attack the remaining issues as add ons
(install with external certs not supported yet for example)


So far I have only read through the code without running it (mostly).


"Remove unused arguments": ACK


"Simplify the install_replica_ca function": ACK


"IPA Custodia Daemon":

1) Instead of putting the code in "ipakeys" package, could you put it
in "ipapython.keys"? This way it would be consistent with DNSSEC,
which has binaries in daemons/dnssec/ and modules in
ipapython/dnssec/.

2) Is it safe to create cn=custodia in update file only? Updates are
executed late in ipa-server-install. Is is guaranteed that nothing
will try to access cn=custodia before the updates are run?

(Nevermind, it is added to bootstrap-template.ldif 2 commits below.)

3) Shouldn't cn=custodia be created only when domain level >= 1?

4) pylint fails with:

daemons/ipa-custodia/ipakeys/kem.py:156: [E1002(super-on-old-class),
IPAKEMKeys.__init__] Use of super on an old style class)
daemons/ipa-custodia/ipakeys/kem.py:178: [E1101(no-member),
IPAKEMKeys.generate_server_keys] Instance of 'IPAKEMKeys' has no
'config' member)
daemons/ipa-custodia/ipakeys/kem.py:187: [E1101(no-member),
IPAKEMKeys.server_keys] Instance of 'IPAKEMKeys' has no 'config'
member)

5) There are some PEP8 transgressions:

./daemons/ipa-custodia/ipakeys/kem.py:202:80: E501 line too long (82
> 79 characters)
./daemons/ipa-custodia/ipakeys/kem.py:203:80: E501 line too long (82
> 79 characters)
./daemons/ipa-custodia/ipakeys/store.py:33:1: E302 expected 2 blank
lines, found 1
./daemons/ipa-custodia/setup.py:8:9: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:8:11: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:9:12: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:9:14: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:10:12: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:10:14: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:11:15: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:11:17: E251 unexpected spaces around
keyword / parameter equals
./daemons/ipa-custodia/setup.py:12:21: E251 unexpected spaces around
keyword / parameter equals

Re: [Freeipa-devel] [PATCHSET] Replica promotion patches

2015-09-30 Thread Jan Pazdziora 
On Tue, Sep 29, 2015 at 03:31:23PM -0400, Simo Sorce wrote:
> On 29/09/15 14:56, Oleg Fayans wrote:
> >
> >
> >On 09/29/2015 06:47 PM, Simo Sorce wrote:
> >>On 29/09/15 11:50, Oleg Fayans wrote:
> >>>Hi Simo,
> >>>
> >>>It seems to have resolved the initial issue, but now the build fails due
> >>>to lint complaints: https://paste.fedoraproject.org/272714/54174014/
> >>
> >>These happens if you do not have custodia installed.
> >>I guess I should make it also a BuildRequires ?
> >
> >I think so, yes.
> 
> Turns out it is already there.

Oleg, were you able to build from the branch now?

Simo, could you maybe make a copr repo from your branch?

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

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