Re: [Freeipa-devel] cert profiles - test plan + patches

[Lenka Doudova]

Hi,

there's no traceback in the file you mentioned, but I'm running it 
through lite-server, so here's the traceback from there:

http://pastebin.test.redhat.com/310598

I can't really get to the problem. What I forgot to mention in the 
previous email was that the tests fail when attempting to add a 
certprofile, but if I try to do is manually using 'ipa 
certprofile-import' command with the exact same data as used in the 
test, it works fine.


Lenka

On 09/03/2015 02:35 PM, Tomas Babej wrote:


On 09/03/2015 01:40 PM, Lenka Doudova wrote:

Hi,

I took a look at it at Milan's request.

patch 0008 - tracker looks ok, ACK
patch 0009 - test cases look ok as well, but can't get it to run, 10 out
of 14 tests fail, starting with internal error, which I haven't been
able to track down, nor fix it.

You can investigate the internal error by inspecting the
/var/log/httpd/error_log on the IPA server that executed the command.

There should be a traceback.


Lenka

=== FAILURES
===
 TestProfileCRUD.test_create_duplicate
_

self = 
user_profile =


 def test_create_duplicate(self, user_profile):
 msg = u'Certificate Profile with name "{}" already exists'

   user_profile.ensure_exists()

ipatests/test_xmlrpc/test_certprofile_plugin.py:178:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
ipatests/test_xmlrpc/ldaptracker.py:169: in ensure_exists
 self.create(force=True)
ipatests/test_xmlrpc/ldaptracker.py:206: in create
 result = command()
ipatests/test_xmlrpc/ldaptracker.py:127: in run_command
 result = cmd(*args, **options)
ipalib/frontend.py:443: in __call__
 ret = self.run(*args, **options)
ipalib/frontend.py:761: in run
 return self.forward(*args, **options)
ipalib/frontend.py:782: in forward
 return self.Backend.rpcclient.forward(self.name, *args, **kw)
ipalib/rpc.py:947: in forward
 return self._call_command(command, params)
ipalib/rpc.py:924: in _call_command
 return command(*params)
ipalib/rpc.py:1075: in _call
 return self.__request(name, args)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 
name = 'certprofile_import'
args = (('caIPAserviceCert_mod',), {'all': False, 'description':
'Storing copy of a profile', 'file': 'profileId=caIPAservice...sion Default
policyset.serverCertSet.11.default.params.userExtOID=2.5.29.17
', 'ipacertprofilestoreissued': True, ...})

 def __request(self, name, args):
 payload = {'method': unicode(name), 'params': args, 'id': 0}
 version = args[1].get('version', VERSION_WITHOUT_CAPABILITIES)
 payload = json_encode_binary(payload, version)

 if self.__verbose >= 2:

 root_logger.info('Request: %s',
  json.dumps(payload, sort_keys=True, indent=4))

 response = self.__transport.request(

 self.__host,
 self.__handler,
 json.dumps(payload),
 verbose=self.__verbose >= 3,
 )

 try:

 response = json_decode_binary(json.loads(response))
 except ValueError as e:
 raise JSONError(str(e))

 if self.__verbose >= 2:

 root_logger.info(
 'Response: %s',
 json.dumps(json_encode_binary(response, version),
sort_keys=True, indent=4)
 )
 error = response.get('error')
 if error:
 try:
 error_class = errors_by_code[error['code']]
 except KeyError:
 raise UnknownError(
 code=error.get('code'),
 error=error.get('message'),
 server=self.__host,
 )
 else:

   raise error_class(message=error['message'])

E   InternalError: an internal error has occurred




On 08/31/2015 03:25 PM, Fraser Tweedale wrote:

On Mon, Aug 31, 2015 at 12:24:13PM +0200, Martin Basti wrote:

On 08/18/2015 04:06 PM, Milan Kubík wrote:

On 08/11/2015 03:17 AM, Fraser Tweedale wrote:

On Mon, Aug 10, 2015 at 11:36:31AM +0200, Milan Kubík wrote:

On 08/05/2015 02:57 PM, Milan Kubík wrote:

Hi list,

I'm sending the test plan [1] for certificate profiles and preliminary
patches for it.
The plan covers basic CRUD test and some corner cases. I'm open to
more
suggestions.

More complicated tests involving certificate profiles will require the
code (and tests)
for CA ACLs merged, so it's not there at the moment.

There are some unfinished test cases in places I wasn't sure what the
result should be.
We need to iterate through these to fix it.


[1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan

Cheers,
Milan

Hi all,

have you had some time to look at the code and proposal?
Today I want to write a basic CRUD test for the ACLs as 

Re: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA

[thierry bordaz]

On 09/03/2015 04:03 PM, David Kupka wrote:

On 02/09/15 14:27, Simo Sorce wrote:

On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote:

On 01/09/15 16:53, Simo Sorce wrote:

On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote:

Hi list,

I own the following ticket 
https://fedorahosted.org/freeipa/ticket/3864
and I would like to clarify what needs to be done in order to make 
IPA

to fully support multiple aliases per entry.

So far I have identified these task based on the ticket comments and
discussion with Simo way back in the past:

1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is
not used in the new code.

2.) fix ACIs that do not permit setting multiple values of
'krbPrincipalName' attribute per entry (see
https://fedorahosted.org/freeipa/ticket/3961)

3.) Modify KDB backend (namely 'ipadb_fetch_principal' and
'ipadb_find_principal' functions) to correctly perform lookup of
krbprincipalname/krbcanonicalname, i.e. search krbprincipalname
case-insensitively and krbcanonicalname case-sensitively, return
krbcanonicalname when canonicalization is requested.

4.) Modify KDB backend and IPA framework to handle creation of both
krbprincipalname and krbcanonicalname. I am not quite sure what cases
should be covered here (I remember that we should create
krbcanonicalname when we add another aliases to krbprincipalname), 
so it

would be nice if you could comment on this.

5.) write tests which cover all this stuff so that we don't shoot
ourselves in the foot.

I am not very well versed in Kerberos so I might get some of this 
stuff
wrong. If that's the case please point me to the right direction. 
Also
please write me some additional stuff which I have fogot and needs 
to be

done.



I think the summary is correct, the only thing we need to be 
careful is
to keep handling entries that have only a single valued 
krbprincipalname

correctly as that will happen in upgrade paths and potentially if
someone uses external tools.

The tricky part for point 3 is to implement it *without* changing the
schema. KrbPrincipalName is case-sensitive, however I think we can 
solve

the issue of "searching case-insensitively" by always lower-casing the
principal name components and always upper casing the realm part on
storage. If we always store a krbCanonicalName we get the "correct" 
case
there anyway so out mucking with the krbPrincipalName case will not 
be a

problem for any new entry.


Or as Honza pointed out we can use case-insensitive search like this:
(krbPrincipalName:caseIgnoreMatch:=ad...@example.com). This will return
all variants of casing and reduce the need for fallback code.


The principal name is not case insensitive, a search like that would
probably cause DS to do a full search through the krbPrincipalName
index, it might quickly become a performance issue. Before choosing a
method please create an install with a 1 principals, and then
compare the speed of a few thousand search with exact matching case and
a few with specifying caseIgnoreMatch and see the difference.

Simo.


We will add index for caseIgnoreCaseIA5Match matching rule on 
krbPrincipalName and then the case insensitive match should be as 
quick as the case sensitive.


Without the index it is indeed far slower. I've generated 10k users 
and compared 100 ldapsearches: The indexed ones took ~ 4 seconds and 
the nonindexed one ~2 minutes. That's by two orders of magnitude worse.


When we tried to add the index into DS we uncovered a bug in the way 
DS handles nsMatchingRule attributes. Thierry investigated it and is 
filling the ticket for DS right now. Thierry can you please send link?


The ticket is https://fedorahosted.org/389/ticket/48270.
I think understand where the problem is but I have no fix yet.
David, when you said the unindexed search was slow, did you index 
'krbPrincipalName' but added a matching rule to your filter ?

I would like to also verify the fix against that perf hit.

thanks
thierry


Once it's fixed we should be good.

David




This *may* cause issues with upgrades though, so we may need fallback
code that searches with the case sent by the client if we determine 
the
entry has no krbCanonicalName attribute (sign that it was created 
before

we started adding krbCanonicalName and never "updated").

Note that we also need to think what will happen during and upgrade 
when

some servers still use the current code and some servers will use the
new code. So I guess it would be nice if you could write down a table
with all possible forms a principal can be in on rows, and old/new
server states in columns, and mark what will happen for various
operations in each case.

Simo.









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

Re: [Freeipa-devel] FreeIPA 4.2.1 checklist

[Martin Kosek]

On 09/04/2015 10:10 AM, Jan Pazdziora wrote:
> On Fri, Sep 04, 2015 at 09:03:27AM +0200, Martin Kosek wrote:
>> ticket to the right version milestone ("FreeIPA 4.2.1") at the time the 
>> ticket
>> is closed. But without proper tooling, I am afraid people may simply close 
>> the
>> ticket within "FreeIPA 4.2.x backlog" and it would then not be clear what
>> version it is fixed in.
> 
> Moving all resolved "FreeIPA 4.2.x backlog" to the correct milestone
> at the point that release is released and/or branched might be
> reasonable approximation.

Good idea, that could work.

-- 
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] 377 Using LDAPI to setup CA and KRA agents.

[Martin Basti]

On 09/02/2015 06:42 AM, Endi Sukma Dewata wrote:

On 9/1/2015 1:52 AM, Martin Basti wrote:

The CA and KRA installation code has been modified to use LDAPI
to create the CA and KRA agents directly in the CA and KRA
database. This way it's no longer necessary to use the Directory
Manager password or CA and KRA admin certificate.

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





Thank you.

1) Can you use following code instead of direct call of 
ldap2.ldap2()?


if not api.Backend.ldap2.is_connected():
 api.Backend.ldap2.connect(autobind=True)

conn = api.Backend.ldap2


Why would you want to do that? The original code is fine, except the
connection check is not necessary (it is a new instance of ldap2, so
.isconnected() will always return False).



It's actually isconnected() instead of is_connected(), but even so, 
the

proposed code doesn't work:

ipa.ipapython.install.cli.install_tool(Server): DEBUGThe
ipa-server-install command failed, exception: TypeError: 'ldap2' 
object

is not callable
ipa.ipapython.install.cli.install_tool(Server): ERROR 'ldap2' object
is not callable


2) Patch needs rebase to master branch.


The original patch does apply cleanly to master. Did you see a 
conflict?

Sorry my bad.

Martin^2



3)
+user_dn = DN(('uid', "ipara"), ('ou', 'People'), 
self.basedn)

+conn.create(
+dn=user_dn,

can you use add entry() instead of create()? We don't use native
python-ldap, but rather ipaldap methods


It's actually calling the ldap2.create() defined in
ipaserver/plugins/ldap2.py, which calls add_entry().


NACK. We don't use ldap2.create(). Use add_entry().



So my original patch still stands.


New patch attached.

ACK, but IMO that comments is not necessary and I would like to push the 
patch without it.


Martin^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] [PATH 0053] Inconsistency between ipasearchrecordslimit and --sizelimit

[Gabe Alford]

Bump for review.

On Wed, Aug 12, 2015 at 9:32 AM, Gabe Alford  wrote:

> On Tue, Aug 11, 2015 at 1:34 AM, Jan Cholasta  wrote:
>
>> On 6.8.2015 21:43, Gabe Alford wrote:
>>
>>> Hello,
>>>
>>> Updated patch attached.
>>>
>>> - Time limit is -1 for unlimited. I found this
>>> https://www.redhat.com/archives/freeipa-devel/2011-January/msg00330.html
>>> in reference to keeping the time limit as -1 for unlimited.
>>>
>>
>> This patch does two conflicting things: it coerces time limit of 0 to -1
>> and at the same time prohibits the user to use 0 for time limit. We should
>> do just one of these and IMHO it should be the coercion of 0 to -1.
>>
>> Sure enough, testing time limit at 0 did not work for unlimited as well
>>> as appeared to have negative effects on IPA.
>>>
>>
>> This is because the time limit read from ipa config is not converted to
>> int in ldap2.find_entries(), so the coercion does not work. Fix this and 0
>> will work just fine.
>>
>> Also, I believe that
>>>
>>> http://www.python-ldap.org/doc/html/ldap.html#ldap.LDAPObject.search_ext_s
>>> specifies unlimited for time limit as -1. (Please correct me if I am
>>> wrong.)
>>>
>>
>> python-ldap is layers below our API and should not determine what we use
>> for unlimited time limit. I would prefer if we were self-consistent and use
>> 0 for both time limit and size limit.
>>
>
> A misunderstanding on my part as I thought it was higher up in the API for
> some reason. Updated patch attached.
>
> Thanks,
>
> Gabe
>
-- 
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 487] ldap: Make ldap2 connection management thread-safe again

[Tomas Babej]

On 09/02/2015 04:47 PM, Jan Cholasta wrote:
> On 2.9.2015 16:20, thierry bordaz wrote:
>> On 09/02/2015 03:16 PM, Jan Cholasta wrote:
>>> On 2.9.2015 14:51, Martin Basti wrote:


 On 09/02/2015 02:32 PM, Jan Cholasta wrote:
> Hi,
>
> the attached patch fixes
> .
>
> Honza
>
>
>

 This patch needs a big rebase to ipa-4-2 branch
>>>
>>> Patch attached.
>>>
>>>
>>>
>> Hello,
>>
>> Two minors questions. LDAPClient close/__del__/__exit__ are now just
>> resetting self._conn without disconnecting the connection.
> 
> They do the same even without the patch, "object.__setattr__(self,
> '_conn', None)" is effectively the same as "self._conn = None".
> 
>> Only ldap2.close() disconnect the connection. Could it be a risk to see
>> connection leaks with __del__ or __exit__ ?
> 
> This behavior is unchanged, and so far no one complained about
> connection leaks.
> 
>>
>> Also in the fix there is:
>>
>> @@ -118,10 +115,11 @@ class ldap2(CrudBackend, LDAPClient):
>>   if debug_level:
>>   _ldap.set_option(_ldap.OPT_DEBUG_LEVEL, debug_level)
>>
>> -LDAPClient._connect(self)
>> -conn = self._conn
>> +client = LDAPClient(self.ldap_uri,
>> +   
>> force_schema_updates=self._force_schema_updates)
>> +conn = client._conn
>>
>>
>> Is it the same as 'conn = client.conn()' ?
> 
> No. It's the same as "conn = client.conn", but I'd like to get rid of
> LDAPClient.conn in the future (internal attributes should not be
> public), hence the use of self._conn.
> 
>>
>> Thanks
>> thierry
>>
> 

This fixes the connection issue, ACK.

Tomas

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

Re: [Freeipa-devel] FreeIPA 4.2.1 checklist

[Jakub Hrozek]

On Fri, Sep 04, 2015 at 09:30:39AM +0200, Jakub Hrozek wrote:
> On Fri, Sep 04, 2015 at 09:25:59AM +0200, Martin Kosek wrote:
> > On 09/04/2015 09:23 AM, Jakub Hrozek wrote:
> > > On Fri, Sep 04, 2015 at 09:19:16AM +0200, Martin Kosek wrote:
> > >> On 09/04/2015 09:12 AM, Jakub Hrozek wrote:
> > >>> On Fri, Sep 04, 2015 at 08:42:47AM +0200, Martin Kosek wrote:
> >  Hello everyone,
> > 
> >  It is now only couple days before Fedora 23 Beta freeze [1] and as we
> >  discussed, we would like to release FreeIPA 4.2.1, which already 
> >  contains 148
> >  patches on top of FreeIPA 4.2.0, mostly stabilization of the new 4.2 
> >  features
> >  or upgrade fixes.
> > 
> >  IIRC, we miss 2 dependencies:
> > 
> >  1) pki-ca 10.2.6
> > 
> >  This is still waiting in Updates Testing [2]. We need 3 positive karma 
> >  (only if
> >  it works of course) to make it move to stable updates repo and so that 
> >  we do
> >  not have broken deps.
> > 
> >  2) sssd 1.13.1
> > 
> >  This upstream release does not officially exist, AFAIK, only in a COPR 
> >  repo. I
> >  see 2 options here:
> >  - SSSD project releases 1.13.1 to Fedora 23 Beta too and we can keep 
> >  the Requires
> >  - SSSD 1.13.0 in Fedora 23 kindly adds the missing patch that caused 
> >  us to bump
> >  the requires and we set the requires in Fedora 23 to 1.13.0.
> > >>>
> > >>> I would prefer to release 1.13.1, there's too many patches to backport.
> > >>
> > >> Well, an case of FreeIPA and it's requires, we should only need 5 of 
> > >> them:
> > >> https://fedorahosted.org/sssd/ticket/2558#comment:12
> > > 
> > > But the number of fixes is quite high, there's already close to 50
> > > tickets fixed and if we rebase, we better to it before Beta.
> > 
> > I fully agree with SSSD release before Beta. I was now mostly only 
> > discussing
> > the unfulfilled FreeIPA requires that has different requirements
> 
> Noted; we will release 1.13.1 on Monday, then.

Actually...

There is a late regression (no ticket yet), so please ping us before
releasing freeipa version that requires 1.13.1, maybe we'll need to use
.0+patches for F-23.

We'll sort in out on Monday

-- 
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 0063] fix crash during standalone CA installation on CA-less master

[Martin Babinsky]

A quick fix for https://fedorahosted.org/freeipa/ticket/5288

--
Martin^3 Babinsky
From ba43a113194b49dcbf3e0eeaa3a41bc204120c08 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Fri, 4 Sep 2015 15:14:48 +0200
Subject: [PATCH] load RA backend plugins during standalone CA install on
 CA-less IPA master

CA-less IPA master has 'ra_plugin' set to 'none' in IPA config. When setting
up Dogtag CA on the master we must override this setting in order to load
dogtag backend plugins and succesfully complete CA installation.

https://fedorahosted.org/freeipa/ticket/5288
---
 install/tools/ipa-ca-install | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/install/tools/ipa-ca-install b/install/tools/ipa-ca-install
index 8b1cea8d557f315ae38c2448e816ca0b2557077f..6564e4d0304d4e189b133c495b75f200b04e2988 100755
--- a/install/tools/ipa-ca-install
+++ b/install/tools/ipa-ca-install
@@ -160,7 +160,9 @@ def install_master(safe_options, options):
 if not dsinstance.DsInstance().is_configured():
 sys.exit("IPA server is not configured on this system.\n")
 
-api.bootstrap(in_server=True)
+# override ra_plugin setting read from default.conf so that we have
+# functional dogtag backend plugins during CA install
+api.bootstrap(in_server=True, ra_plugin='dogtag')
 api.finalize()
 
 dm_password = options.password
-- 
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] 377 Using LDAPI to setup CA and KRA agents.

[Endi Sukma Dewata]

On 9/4/2015 6:35 AM, Martin Basti wrote:



On 09/02/2015 06:42 AM, Endi Sukma Dewata wrote:

On 9/1/2015 1:52 AM, Martin Basti wrote:

The CA and KRA installation code has been modified to use LDAPI
to create the CA and KRA agents directly in the CA and KRA
database. This way it's no longer necessary to use the Directory
Manager password or CA and KRA admin certificate.

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





Thank you.

1) Can you use following code instead of direct call of
ldap2.ldap2()?

if not api.Backend.ldap2.is_connected():
 api.Backend.ldap2.connect(autobind=True)

conn = api.Backend.ldap2


Why would you want to do that? The original code is fine, except the
connection check is not necessary (it is a new instance of ldap2, so
.isconnected() will always return False).



It's actually isconnected() instead of is_connected(), but even so,
the
proposed code doesn't work:

ipa.ipapython.install.cli.install_tool(Server): DEBUGThe
ipa-server-install command failed, exception: TypeError: 'ldap2'
object
is not callable
ipa.ipapython.install.cli.install_tool(Server): ERROR 'ldap2' object
is not callable


2) Patch needs rebase to master branch.


The original patch does apply cleanly to master. Did you see a
conflict?

Sorry my bad.

Martin^2



3)
+user_dn = DN(('uid', "ipara"), ('ou', 'People'),
self.basedn)
+conn.create(
+dn=user_dn,

can you use add entry() instead of create()? We don't use native
python-ldap, but rather ipaldap methods


It's actually calling the ldap2.create() defined in
ipaserver/plugins/ldap2.py, which calls add_entry().


NACK. We don't use ldap2.create(). Use add_entry().



So my original patch still stands.


New patch attached.


ACK, but IMO that comments is not necessary and I would like to push the
patch without it.

Martin^2


It is necessary if we don't want people to use it. Otherwise someone 
could make the same mistake. Or better yet, just remove the method.


--
Endi S. Dewata

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

Re: [Freeipa-devel] cert profiles - test plan + patches

[Martin Babinsky]

On 09/04/2015 11:06 AM, Lenka Doudova wrote:

Hi,

there's no traceback in the file you mentioned, but I'm running it
through lite-server, so here's the traceback from there:
http://pastebin.test.redhat.com/310598

I can't really get to the problem. What I forgot to mention in the
previous email was that the tests fail when attempting to add a
certprofile, but if I try to do is manually using 'ipa
certprofile-import' command with the exact same data as used in the
test, it works fine.

Lenka

Do you get the traceback also when you run the tests using 
'ipa-run-tests' with installed IPA master?


--
Martin^3 Babinsky

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

Re: [Freeipa-devel] [PATCH] 377 Using LDAPI to setup CA and KRA agents.

[Petr Vobornik]

On 09/04/2015 04:03 PM, Endi Sukma Dewata wrote:

On 9/4/2015 6:35 AM, Martin Basti wrote:



On 09/02/2015 06:42 AM, Endi Sukma Dewata wrote:

On 9/1/2015 1:52 AM, Martin Basti wrote:

The CA and KRA installation code has been modified to use LDAPI
to create the CA and KRA agents directly in the CA and KRA
database. This way it's no longer necessary to use the Directory
Manager password or CA and KRA admin certificate.

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





Thank you.

1) Can you use following code instead of direct call of
ldap2.ldap2()?

if not api.Backend.ldap2.is_connected():
 api.Backend.ldap2.connect(autobind=True)

conn = api.Backend.ldap2


Why would you want to do that? The original code is fine, except the
connection check is not necessary (it is a new instance of ldap2, so
.isconnected() will always return False).



It's actually isconnected() instead of is_connected(), but even so,
the
proposed code doesn't work:

ipa.ipapython.install.cli.install_tool(Server): DEBUGThe
ipa-server-install command failed, exception: TypeError: 'ldap2'
object
is not callable
ipa.ipapython.install.cli.install_tool(Server): ERROR 'ldap2' object
is not callable


2) Patch needs rebase to master branch.


The original patch does apply cleanly to master. Did you see a
conflict?

Sorry my bad.

Martin^2



3)
+user_dn = DN(('uid', "ipara"), ('ou', 'People'),
self.basedn)
+conn.create(
+dn=user_dn,

can you use add entry() instead of create()? We don't use native
python-ldap, but rather ipaldap methods


It's actually calling the ldap2.create() defined in
ipaserver/plugins/ldap2.py, which calls add_entry().


NACK. We don't use ldap2.create(). Use add_entry().



So my original patch still stands.


New patch attached.


ACK, but IMO that comments is not necessary and I would like to push the
patch without it.

Martin^2


It is necessary if we don't want people to use it. Otherwise someone
could make the same mistake. Or better yet, just remove the method.



+
+NOTE: Do not use this method.

I agree that the comment should not be in this patch - it is not 
relevant to vaults.


The comment or a removal of the method(if it is really useless) should 
be in a different patch. If comment is the way than please also add why 
it should not be used.

--
Petr Vobornik

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

Re: [Freeipa-devel] [PATCH 0004] Rewrap errors in get_principal to CCacheError

[Michael Šimáček]

On 2015-09-03 14:32, Tomas Babej wrote:



On 09/03/2015 12:54 PM, Michael Šimáček wrote:

After porting to gssapi, the ipa command prints ugly traceback when
kerberos credentials are not available. Rewrapping to CCacheError when
getting the principal name results in nicer error message.

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




This fixes the issue, however, I am getting a trailing forward slash in
the error message:

$ ipa user-find
ipa: ERROR: Kerberos error: did not receive Kerberos credentials/



Attaching updated revision. I altered more places where kerberos errors 
were used.


Michael
From 50095b3ab224a871ac3bd6e7823755cdba744b60 Mon Sep 17 00:00:00 2001
From: Michael Simacek 
Date: Mon, 31 Aug 2015 14:04:33 +0200
Subject: [PATCH] Rewrap errors in get_principal to CCacheError

Causes nicer error message when kerberos credentials are not available.

https://fedorahosted.org/freeipa/ticket/5272
---
 install/tools/ipa-adtrust-install |  2 +-
 ipalib/krb_utils.py   | 10 --
 ipalib/rpc.py | 10 ++
 ipaserver/rpcserver.py|  2 +-
 4 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install
index 9ff1ac9be24a9f16f59ebe8dd46b2ff0d27b06aa..92c6ef3bda16de8e45a2a12011181541bbb0672c 100755
--- a/install/tools/ipa-adtrust-install
+++ b/install/tools/ipa-adtrust-install
@@ -306,7 +306,7 @@ def main():
 
 try:
 principal = krb_utils.get_principal()
-except gssapi.exceptions.GSSError as e:
+except errors.CCacheError as e:
 sys.exit("Must have Kerberos credentials to setup AD trusts on server: %s" % e.message)
 
 try:
diff --git a/ipalib/krb_utils.py b/ipalib/krb_utils.py
index db1cffc1e32a2e50fba64897ff1eba005f90fdc3..019f7ab6cee7f441489c4bd6dd84eb423b2ff6ca 100644
--- a/ipalib/krb_utils.py
+++ b/ipalib/krb_utils.py
@@ -168,9 +168,15 @@ def get_principal(ccache_name=None):
 default
 :returns:
   Default principal name as string
+:raises:
+  errors.CCacheError if the principal cannot be retrieved from given
+  ccache
 '''
-creds = get_credentials(ccache_name=ccache_name)
-return unicode(creds.name)
+try:
+creds = get_credentials(ccache_name=ccache_name)
+return unicode(creds.name)
+except gssapi.exceptions.GSSError as e:
+raise errors.CCacheError(message=unicode(e))
 
 def get_credentials_if_valid(name=None, ccache_name=None):
 '''
diff --git a/ipalib/rpc.py b/ipalib/rpc.py
index dcbfafe0567d653273fccb96d31d4c407fdf256c..6b666418769ffdf0f9ac6242d765a6bd965d4c80 100644
--- a/ipalib/rpc.py
+++ b/ipalib/rpc.py
@@ -67,7 +67,7 @@ import ipapython.nsslib
 from ipapython.nsslib import NSSHTTPS, NSSConnection
 from ipalib.krb_utils import KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN, KRB5KRB_AP_ERR_TKT_EXPIRED, \
  KRB5_FCC_PERM, KRB5_FCC_NOFILE, KRB5_CC_FORMAT, \
- KRB5_REALM_CANT_RESOLVE, get_principal
+ KRB5_REALM_CANT_RESOLVE, KRB5_CC_NOTFOUND, get_principal
 from ipapython.dn import DN
 from ipalib.capabilities import VERSION_WITHOUT_CAPABILITIES
 from ipalib import api
@@ -532,8 +532,10 @@ class KerbTransport(SSLTransport):
 raise errors.BadCCacheFormat()
 elif minor == KRB5_REALM_CANT_RESOLVE:
 raise errors.CannotResolveKDC()
+elif minor == KRB5_CC_NOTFOUND:
+raise errors.CCacheError()
 else:
-raise errors.KerberosError(major=e.maj_code, minor=minor)
+raise errors.KerberosError(message=unicode(e))
 
 def get_host_info(self, host):
 """
@@ -839,7 +841,7 @@ class RPCClient(Connectible):
 # is still valid
 if not delegate:
 rpc_uri = self.apply_session_cookie(rpc_uri)
-except ValueError:
+except (errors.CCacheError, ValueError):
 # No session key, do full Kerberos auth
 pass
 # This might be dangerous. Use at your own risk!
@@ -885,7 +887,7 @@ class RPCClient(Connectible):
 break
 except KerberosError as krberr:
 # kerberos error on one server is likely on all
-raise errors.KerberosError(major=str(krberr), minor='')
+raise errors.KerberosError(message=unicode(krberr))
 except ProtocolError as e:
 if hasattr(context, 'session_cookie') and e.errcode == 401:
 # Unauthorized. Remove the session and try again.
diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py
index 3b0fee534eba1d2b902df72c859253cfcbd053fe..84b440a42c288edeeccf90c254ae4b930068d42c 100644
--- a/ipaserver/rpcserver.py
+++ b/ipaserver/rpcserver.py
@@ -964,7 +964,7 @@ class login_password(Backend, KerberosSession, HTTP_Status):
 try:
 ipautil.kinit_keytab(armor_principal, paths.IPA_KEYTAB, 

Re: [Freeipa-devel] fixing Kerberos principal aliases handling in IPA

[Simo Sorce]

On Thu, 2015-09-03 at 16:03 +0200, David Kupka wrote:
> On 02/09/15 14:27, Simo Sorce wrote:
> > On Wed, 2015-09-02 at 08:11 +0200, David Kupka wrote:
> >> On 01/09/15 16:53, Simo Sorce wrote:
> >>> On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote:
>  Hi list,
> 
>  I own the following ticket https://fedorahosted.org/freeipa/ticket/3864
>  and I would like to clarify what needs to be done in order to make IPA
>  to fully support multiple aliases per entry.
> 
>  So far I have identified these task based on the ticket comments and
>  discussion with Simo way back in the past:
> 
>  1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is
>  not used in the new code.
> 
>  2.) fix ACIs that do not permit setting multiple values of
>  'krbPrincipalName' attribute per entry (see
>  https://fedorahosted.org/freeipa/ticket/3961)
> 
>  3.) Modify KDB backend (namely 'ipadb_fetch_principal' and
>  'ipadb_find_principal' functions) to correctly perform lookup of
>  krbprincipalname/krbcanonicalname, i.e. search krbprincipalname
>  case-insensitively and krbcanonicalname case-sensitively, return
>  krbcanonicalname when canonicalization is requested.
> 
>  4.) Modify KDB backend and IPA framework to handle creation of both
>  krbprincipalname and krbcanonicalname. I am not quite sure what cases
>  should be covered here (I remember that we should create
>  krbcanonicalname when we add another aliases to krbprincipalname), so it
>  would be nice if you could comment on this.
> 
>  5.) write tests which cover all this stuff so that we don't shoot
>  ourselves in the foot.
> 
>  I am not very well versed in Kerberos so I might get some of this stuff
>  wrong. If that's the case please point me to the right direction. Also
>  please write me some additional stuff which I have fogot and needs to be
>  done.
> 
> >>>
> >>> I think the summary is correct, the only thing we need to be careful is
> >>> to keep handling entries that have only a single valued krbprincipalname
> >>> correctly as that will happen in upgrade paths and potentially if
> >>> someone uses external tools.
> >>>
> >>> The tricky part for point 3 is to implement it *without* changing the
> >>> schema. KrbPrincipalName is case-sensitive, however I think we can solve
> >>> the issue of "searching case-insensitively" by always lower-casing the
> >>> principal name components and always upper casing the realm part on
> >>> storage. If we always store a krbCanonicalName we get the "correct" case
> >>> there anyway so out mucking with the krbPrincipalName case will not be a
> >>> problem for any new entry.
> >>
> >> Or as Honza pointed out we can use case-insensitive search like this:
> >> (krbPrincipalName:caseIgnoreMatch:=ad...@example.com). This will return
> >> all variants of casing and reduce the need for fallback code.
> >
> > The principal name is not case insensitive, a search like that would
> > probably cause DS to do a full search through the krbPrincipalName
> > index, it might quickly become a performance issue. Before choosing a
> > method please create an install with a 1 principals, and then
> > compare the speed of a few thousand search with exact matching case and
> > a few with specifying caseIgnoreMatch and see the difference.
> >
> > Simo.
> 
> We will add index for caseIgnoreCaseIA5Match matching rule on 
> krbPrincipalName and then the case insensitive match should be as quick 
> as the case sensitive.
> 
> Without the index it is indeed far slower. I've generated 10k users and 
> compared 100 ldapsearches: The indexed ones took ~ 4 seconds and the 
> nonindexed one ~2 minutes. That's by two orders of magnitude worse.
> 
> When we tried to add the index into DS we uncovered a bug in the way DS 
> handles nsMatchingRule attributes. Thierry investigated it and is 
> filling the ticket for DS right now. Thierry can you please send link?
> 
> Once it's fixed we should be good.
> 
> David
> 
> >
> >>> This *may* cause issues with upgrades though, so we may need fallback
> >>> code that searches with the case sent by the client if we determine the
> >>> entry has no krbCanonicalName attribute (sign that it was created before
> >>> we started adding krbCanonicalName and never "updated").

Another "upgrade" issue came to mind.
Will the referential integrity plugin properly handle a rename of
service entries should they be referenced in some object ?

Simo.


> >>> Note that we also need to think what will happen during and upgrade when
> >>> some servers still use the current code and some servers will use the
> >>> new code. So I guess it would be nice if you could write down a table
> >>> with all possible forms a principal can be in on rows, and old/new
> >>> server states in columns, and mark what will happen for various
> >>> operations in each case.
> >>>
> >>> Simo.
> 

Re: [Freeipa-devel] FreeIPA 4.2.1 checklist

[Alexander Bokovoy]

On Fri, 04 Sep 2015, Martin Kosek wrote:

On 09/04/2015 09:08 AM, Alexander Bokovoy wrote:

On Fri, 04 Sep 2015, Martin Kosek wrote:

...

We also need to get krb5 update for KDC client referrals. Robby is
working on that at bug https://bugzilla.redhat.com/show_bug.cgi?id=1259844
The patch is ready, we just need to push out the packages.


Besides the package requiremenst, What patches do you want to include to do the
release in the end of today or the beginning of the next week?

I'd like to see client referral (ticket 3559) fixes in 4.2.1. Patches
are on the list and require krb5 update.


Ok. But I do not see it as something that should postpone 4.2.1 as it is not a
regression and this simply never worked (AFAIK).

It is mostly going to create a major confusion when people start using
one-way trust with elaborate forest structure.
--
/ 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] FreeIPA 4.2.1 checklist

[Martin Kosek]

On 09/04/2015 09:12 AM, Jakub Hrozek wrote:
> On Fri, Sep 04, 2015 at 08:42:47AM +0200, Martin Kosek wrote:
>> Hello everyone,
>>
>> It is now only couple days before Fedora 23 Beta freeze [1] and as we
>> discussed, we would like to release FreeIPA 4.2.1, which already contains 148
>> patches on top of FreeIPA 4.2.0, mostly stabilization of the new 4.2 features
>> or upgrade fixes.
>>
>> IIRC, we miss 2 dependencies:
>>
>> 1) pki-ca 10.2.6
>>
>> This is still waiting in Updates Testing [2]. We need 3 positive karma (only 
>> if
>> it works of course) to make it move to stable updates repo and so that we do
>> not have broken deps.
>>
>> 2) sssd 1.13.1
>>
>> This upstream release does not officially exist, AFAIK, only in a COPR repo. 
>> I
>> see 2 options here:
>> - SSSD project releases 1.13.1 to Fedora 23 Beta too and we can keep the 
>> Requires
>> - SSSD 1.13.0 in Fedora 23 kindly adds the missing patch that caused us to 
>> bump
>> the requires and we set the requires in Fedora 23 to 1.13.0.
> 
> I would prefer to release 1.13.1, there's too many patches to backport.

Well, an case of FreeIPA and it's requires, we should only need 5 of them:
https://fedorahosted.org/sssd/ticket/2558#comment:12

This is the ticket that bumped the FreeIPA SSSD Requires:
https://fedorahosted.org/freeipa/ticket/4249

> The only question is whether we include some patches that I just
> yesterday finished testing. I'll send them to the list so that we can
> see if they are digestable in the couple of days, otherwise we include
> them in .2 and patch downstream later.
> 
>>
>> Jakub, any preference?
>>
>> Besides the package requiremenst, What patches do you want to include to do 
>> the
>> release in the end of today or the beginning of the next week?
> 
> The schedule says the Beta freeze is on Wednesday, so we need to release
> on Tuesday, correct?

Correct, but on Wednesday, the update should be in stable already, according to:
https://fedoraproject.org/wiki/Updates_Policy#Milestone_freezes

So it would be safer to release upstream on Monday, get the positive karma and
request the transition to stable so that the transition is completed before
Wednesday.

>> [1] https://fedoraproject.org/wiki/Releases/23/Schedule
>> [2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-13905
>>
>> -- 
>> 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] FreeIPA 4.2.1 checklist

[Martin Kosek]

On 09/04/2015 09:15 AM, Alexander Bokovoy wrote:
> On Fri, 04 Sep 2015, Martin Kosek wrote:
>> On 09/04/2015 09:08 AM, Alexander Bokovoy wrote:
>>> On Fri, 04 Sep 2015, Martin Kosek wrote:
>> ...
>>> We also need to get krb5 update for KDC client referrals. Robby is
>>> working on that at bug https://bugzilla.redhat.com/show_bug.cgi?id=1259844
>>> The patch is ready, we just need to push out the packages.
>>>
 Besides the package requiremenst, What patches do you want to include to do
 the
 release in the end of today or the beginning of the next week?
>>> I'd like to see client referral (ticket 3559) fixes in 4.2.1. Patches
>>> are on the list and require krb5 update.
>>
>> Ok. But I do not see it as something that should postpone 4.2.1 as it is not 
>> a
>> regression and this simply never worked (AFAIK).
> It is mostly going to create a major confusion when people start using
> one-way trust with elaborate forest structure.

Sure. But my point is that we should not miss the Beta deadline so that we have
the big stabilization 4.2.1 release in and being tested.

This particular Trust change can come in 4.2.2 week or two after, in case it
does not make 4.2.1 deadline.

Martin

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

Re: [Freeipa-devel] FreeIPA 4.2.1 checklist

[Jakub Hrozek]

On Fri, Sep 04, 2015 at 09:19:16AM +0200, Martin Kosek wrote:
> On 09/04/2015 09:12 AM, Jakub Hrozek wrote:
> > On Fri, Sep 04, 2015 at 08:42:47AM +0200, Martin Kosek wrote:
> >> Hello everyone,
> >>
> >> It is now only couple days before Fedora 23 Beta freeze [1] and as we
> >> discussed, we would like to release FreeIPA 4.2.1, which already contains 
> >> 148
> >> patches on top of FreeIPA 4.2.0, mostly stabilization of the new 4.2 
> >> features
> >> or upgrade fixes.
> >>
> >> IIRC, we miss 2 dependencies:
> >>
> >> 1) pki-ca 10.2.6
> >>
> >> This is still waiting in Updates Testing [2]. We need 3 positive karma 
> >> (only if
> >> it works of course) to make it move to stable updates repo and so that we 
> >> do
> >> not have broken deps.
> >>
> >> 2) sssd 1.13.1
> >>
> >> This upstream release does not officially exist, AFAIK, only in a COPR 
> >> repo. I
> >> see 2 options here:
> >> - SSSD project releases 1.13.1 to Fedora 23 Beta too and we can keep the 
> >> Requires
> >> - SSSD 1.13.0 in Fedora 23 kindly adds the missing patch that caused us to 
> >> bump
> >> the requires and we set the requires in Fedora 23 to 1.13.0.
> > 
> > I would prefer to release 1.13.1, there's too many patches to backport.
> 
> Well, an case of FreeIPA and it's requires, we should only need 5 of them:
> https://fedorahosted.org/sssd/ticket/2558#comment:12

But the number of fixes is quite high, there's already close to 50
tickets fixed and if we rebase, we better to it before Beta.

> 
> This is the ticket that bumped the FreeIPA SSSD Requires:
> https://fedorahosted.org/freeipa/ticket/4249
> 
> > The only question is whether we include some patches that I just
> > yesterday finished testing. I'll send them to the list so that we can
> > see if they are digestable in the couple of days, otherwise we include
> > them in .2 and patch downstream later.
> > 
> >>
> >> Jakub, any preference?
> >>
> >> Besides the package requiremenst, What patches do you want to include to 
> >> do the
> >> release in the end of today or the beginning of the next week?
> > 
> > The schedule says the Beta freeze is on Wednesday, so we need to release
> > on Tuesday, correct?
> 
> Correct, but on Wednesday, the update should be in stable already, according 
> to:
> https://fedoraproject.org/wiki/Updates_Policy#Milestone_freezes
> 
> So it would be safer to release upstream on Monday, get the positive karma and
> request the transition to stable so that the transition is completed before
> Wednesday.

OK.

> 
> >> [1] https://fedoraproject.org/wiki/Releases/23/Schedule
> >> [2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-13905
> >>
> >> -- 
> >> 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

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

Re: [Freeipa-devel] FreeIPA 4.2.1 checklist

[Martin Kosek]

On 09/04/2015 09:23 AM, Jakub Hrozek wrote:
> On Fri, Sep 04, 2015 at 09:19:16AM +0200, Martin Kosek wrote:
>> On 09/04/2015 09:12 AM, Jakub Hrozek wrote:
>>> On Fri, Sep 04, 2015 at 08:42:47AM +0200, Martin Kosek wrote:
 Hello everyone,

 It is now only couple days before Fedora 23 Beta freeze [1] and as we
 discussed, we would like to release FreeIPA 4.2.1, which already contains 
 148
 patches on top of FreeIPA 4.2.0, mostly stabilization of the new 4.2 
 features
 or upgrade fixes.

 IIRC, we miss 2 dependencies:

 1) pki-ca 10.2.6

 This is still waiting in Updates Testing [2]. We need 3 positive karma 
 (only if
 it works of course) to make it move to stable updates repo and so that we 
 do
 not have broken deps.

 2) sssd 1.13.1

 This upstream release does not officially exist, AFAIK, only in a COPR 
 repo. I
 see 2 options here:
 - SSSD project releases 1.13.1 to Fedora 23 Beta too and we can keep the 
 Requires
 - SSSD 1.13.0 in Fedora 23 kindly adds the missing patch that caused us to 
 bump
 the requires and we set the requires in Fedora 23 to 1.13.0.
>>>
>>> I would prefer to release 1.13.1, there's too many patches to backport.
>>
>> Well, an case of FreeIPA and it's requires, we should only need 5 of them:
>> https://fedorahosted.org/sssd/ticket/2558#comment:12
> 
> But the number of fixes is quite high, there's already close to 50
> tickets fixed and if we rebase, we better to it before Beta.

I fully agree with SSSD release before Beta. I was now mostly only discussing
the unfulfilled FreeIPA requires that has different requirements

> 
>>
>> This is the ticket that bumped the FreeIPA SSSD Requires:
>> https://fedorahosted.org/freeipa/ticket/4249
>>
>>> The only question is whether we include some patches that I just
>>> yesterday finished testing. I'll send them to the list so that we can
>>> see if they are digestable in the couple of days, otherwise we include
>>> them in .2 and patch downstream later.
>>>

 Jakub, any preference?

 Besides the package requiremenst, What patches do you want to include to 
 do the
 release in the end of today or the beginning of the next week?
>>>
>>> The schedule says the Beta freeze is on Wednesday, so we need to release
>>> on Tuesday, correct?
>>
>> Correct, but on Wednesday, the update should be in stable already, according 
>> to:
>> https://fedoraproject.org/wiki/Updates_Policy#Milestone_freezes
>>
>> So it would be safer to release upstream on Monday, get the positive karma 
>> and
>> request the transition to stable so that the transition is completed before
>> Wednesday.
> 
> OK.
> 
>>
 [1] https://fedoraproject.org/wiki/Releases/23/Schedule
 [2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-13905

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

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

Re: [Freeipa-devel] FreeIPA 4.2.1 checklist

[Alexander Bokovoy]

On Fri, 04 Sep 2015, Martin Kosek wrote:

On 09/04/2015 09:15 AM, Alexander Bokovoy wrote:

On Fri, 04 Sep 2015, Martin Kosek wrote:

On 09/04/2015 09:08 AM, Alexander Bokovoy wrote:

On Fri, 04 Sep 2015, Martin Kosek wrote:

...

We also need to get krb5 update for KDC client referrals. Robby is
working on that at bug https://bugzilla.redhat.com/show_bug.cgi?id=1259844
The patch is ready, we just need to push out the packages.


Besides the package requiremenst, What patches do you want to include to do
the
release in the end of today or the beginning of the next week?

I'd like to see client referral (ticket 3559) fixes in 4.2.1. Patches
are on the list and require krb5 update.


Ok. But I do not see it as something that should postpone 4.2.1 as it is not a
regression and this simply never worked (AFAIK).

It is mostly going to create a major confusion when people start using
one-way trust with elaborate forest structure.


Sure. But my point is that we should not miss the Beta deadline so that we have
the big stabilization 4.2.1 release in and being tested.

This particular Trust change can come in 4.2.2 week or two after, in case it
does not make 4.2.1 deadline.

Yes, that's fine as long as we are able to put all pieces together
before F23 release.
--
/ 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] FreeIPA 4.2.1 checklist

[Jakub Hrozek]

On Fri, Sep 04, 2015 at 09:25:59AM +0200, Martin Kosek wrote:
> On 09/04/2015 09:23 AM, Jakub Hrozek wrote:
> > On Fri, Sep 04, 2015 at 09:19:16AM +0200, Martin Kosek wrote:
> >> On 09/04/2015 09:12 AM, Jakub Hrozek wrote:
> >>> On Fri, Sep 04, 2015 at 08:42:47AM +0200, Martin Kosek wrote:
>  Hello everyone,
> 
>  It is now only couple days before Fedora 23 Beta freeze [1] and as we
>  discussed, we would like to release FreeIPA 4.2.1, which already 
>  contains 148
>  patches on top of FreeIPA 4.2.0, mostly stabilization of the new 4.2 
>  features
>  or upgrade fixes.
> 
>  IIRC, we miss 2 dependencies:
> 
>  1) pki-ca 10.2.6
> 
>  This is still waiting in Updates Testing [2]. We need 3 positive karma 
>  (only if
>  it works of course) to make it move to stable updates repo and so that 
>  we do
>  not have broken deps.
> 
>  2) sssd 1.13.1
> 
>  This upstream release does not officially exist, AFAIK, only in a COPR 
>  repo. I
>  see 2 options here:
>  - SSSD project releases 1.13.1 to Fedora 23 Beta too and we can keep the 
>  Requires
>  - SSSD 1.13.0 in Fedora 23 kindly adds the missing patch that caused us 
>  to bump
>  the requires and we set the requires in Fedora 23 to 1.13.0.
> >>>
> >>> I would prefer to release 1.13.1, there's too many patches to backport.
> >>
> >> Well, an case of FreeIPA and it's requires, we should only need 5 of them:
> >> https://fedorahosted.org/sssd/ticket/2558#comment:12
> > 
> > But the number of fixes is quite high, there's already close to 50
> > tickets fixed and if we rebase, we better to it before Beta.
> 
> I fully agree with SSSD release before Beta. I was now mostly only discussing
> the unfulfilled FreeIPA requires that has different requirements

Noted; we will release 1.13.1 on Monday, then.

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

Re: [Freeipa-devel] FreeIPA 4.2.1 checklist

[Martin Kosek]

On 09/04/2015 08:57 AM, Jan Pazdziora wrote:
> On Fri, Sep 04, 2015 at 08:42:47AM +0200, Martin Kosek wrote:
>> Hello everyone,
>>
>> It is now only couple days before Fedora 23 Beta freeze [1] and as we
>> discussed, we would like to release FreeIPA 4.2.1, which already contains 148
> 
> Looking at
> 
>   https://fedorahosted.org/freeipa/milestone/FreeIPA%204.2.1
> 
> it says there are 56 active tickets and clicking that 56 I get to
> 
>   
> https://fedorahosted.org/freeipa/query?milestone=FreeIPA+4.2.1=new=assigned=reopened=status
> 
> where I can see eight critical defects (besides numerous major).
> 
> Is that expected?

Based on how stabilization ticket buckets are organized now, it is expected.
Right now, "FreeIPA 4.2.1" milestone rather means "FreeIPA 4.2.1 or later 4.2.x
release" as non-closed tickets are simply moved to "FreeIPA 4.2.2" at the
release time and we continue working on the stabilization branch.

This makes the job easier and less error-prone for people closing the tickets
when patches are merged as the Milestone name always refer to the right FreeIPA
version (it did not in the past). If this setup is confusing for people, other
option would be to have something like "FreeIPA 4.2.x backlog" and move the
ticket to the right version milestone ("FreeIPA 4.2.1") at the time the ticket
is closed. But without proper tooling, I am afraid people may simply close the
ticket within "FreeIPA 4.2.x backlog" and it would then not be clear what
version it is fixed in.

Martin

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

Re: [Freeipa-devel] FreeIPA 4.2.1 checklist

[Jakub Hrozek]

On Fri, Sep 04, 2015 at 08:42:47AM +0200, Martin Kosek wrote:
> Hello everyone,
> 
> It is now only couple days before Fedora 23 Beta freeze [1] and as we
> discussed, we would like to release FreeIPA 4.2.1, which already contains 148
> patches on top of FreeIPA 4.2.0, mostly stabilization of the new 4.2 features
> or upgrade fixes.
> 
> IIRC, we miss 2 dependencies:
> 
> 1) pki-ca 10.2.6
> 
> This is still waiting in Updates Testing [2]. We need 3 positive karma (only 
> if
> it works of course) to make it move to stable updates repo and so that we do
> not have broken deps.
> 
> 2) sssd 1.13.1
> 
> This upstream release does not officially exist, AFAIK, only in a COPR repo. I
> see 2 options here:
> - SSSD project releases 1.13.1 to Fedora 23 Beta too and we can keep the 
> Requires
> - SSSD 1.13.0 in Fedora 23 kindly adds the missing patch that caused us to 
> bump
> the requires and we set the requires in Fedora 23 to 1.13.0.

I would prefer to release 1.13.1, there's too many patches to backport.

The only question is whether we include some patches that I just
yesterday finished testing. I'll send them to the list so that we can
see if they are digestable in the couple of days, otherwise we include
them in .2 and patch downstream later.

> 
> Jakub, any preference?
> 
> Besides the package requiremenst, What patches do you want to include to do 
> the
> release in the end of today or the beginning of the next week?

The schedule says the Beta freeze is on Wednesday, so we need to release
on Tuesday, correct?

> 
> [1] https://fedoraproject.org/wiki/Releases/23/Schedule
> [2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-13905
> 
> -- 
> 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

[Freeipa-devel] FreeIPA 4.2.1 checklist

[Martin Kosek]

Hello everyone,

It is now only couple days before Fedora 23 Beta freeze [1] and as we
discussed, we would like to release FreeIPA 4.2.1, which already contains 148
patches on top of FreeIPA 4.2.0, mostly stabilization of the new 4.2 features
or upgrade fixes.

IIRC, we miss 2 dependencies:

1) pki-ca 10.2.6

This is still waiting in Updates Testing [2]. We need 3 positive karma (only if
it works of course) to make it move to stable updates repo and so that we do
not have broken deps.

2) sssd 1.13.1

This upstream release does not officially exist, AFAIK, only in a COPR repo. I
see 2 options here:
- SSSD project releases 1.13.1 to Fedora 23 Beta too and we can keep the 
Requires
- SSSD 1.13.0 in Fedora 23 kindly adds the missing patch that caused us to bump
the requires and we set the requires in Fedora 23 to 1.13.0.

Jakub, any preference?

Besides the package requiremenst, What patches do you want to include to do the
release in the end of today or the beginning of the next week?

[1] https://fedoraproject.org/wiki/Releases/23/Schedule
[2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-13905

-- 
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] FreeIPA 4.2.1 checklist

[Jan Pazdziora]

On Fri, Sep 04, 2015 at 08:42:47AM +0200, Martin Kosek wrote:
> Hello everyone,
> 
> It is now only couple days before Fedora 23 Beta freeze [1] and as we
> discussed, we would like to release FreeIPA 4.2.1, which already contains 148

Looking at

https://fedorahosted.org/freeipa/milestone/FreeIPA%204.2.1

it says there are 56 active tickets and clicking that 56 I get to


https://fedorahosted.org/freeipa/query?milestone=FreeIPA+4.2.1=new=assigned=reopened=status

where I can see eight critical defects (besides numerous major).

Is that expected?

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

Re: [Freeipa-devel] FreeIPA 4.2.1 checklist

[Alexander Bokovoy]

On Fri, 04 Sep 2015, Martin Kosek wrote:

Hello everyone,

It is now only couple days before Fedora 23 Beta freeze [1] and as we
discussed, we would like to release FreeIPA 4.2.1, which already contains 148
patches on top of FreeIPA 4.2.0, mostly stabilization of the new 4.2 features
or upgrade fixes.

IIRC, we miss 2 dependencies:

1) pki-ca 10.2.6

This is still waiting in Updates Testing [2]. We need 3 positive karma (only if
it works of course) to make it move to stable updates repo and so that we do
not have broken deps.

10.2.6-7.f22 works for me well. Didn't test F23 yet.


2) sssd 1.13.1

This upstream release does not officially exist, AFAIK, only in a COPR repo. I
see 2 options here:
- SSSD project releases 1.13.1 to Fedora 23 Beta too and we can keep the 
Requires
- SSSD 1.13.0 in Fedora 23 kindly adds the missing patch that caused us to bump
the requires and we set the requires in Fedora 23 to 1.13.0.

Jakub, any preference?

I would prefer getting 1.13.1 out.

We also need to get krb5 update for KDC client referrals. Robby is
working on that at bug https://bugzilla.redhat.com/show_bug.cgi?id=1259844
The patch is ready, we just need to push out the packages.


Besides the package requiremenst, What patches do you want to include to do the
release in the end of today or the beginning of the next week?

I'd like to see client referral (ticket 3559) fixes in 4.2.1. Patches
are on the list and require krb5 update.

--
/ 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] FreeIPA 4.2.1 checklist

[Martin Kosek]

On 09/04/2015 09:08 AM, Alexander Bokovoy wrote:
> On Fri, 04 Sep 2015, Martin Kosek wrote:
...
> We also need to get krb5 update for KDC client referrals. Robby is
> working on that at bug https://bugzilla.redhat.com/show_bug.cgi?id=1259844
> The patch is ready, we just need to push out the packages.
> 
>> Besides the package requiremenst, What patches do you want to include to do 
>> the
>> release in the end of today or the beginning of the next week?
> I'd like to see client referral (ticket 3559) fixes in 4.2.1. Patches
> are on the list and require krb5 update.

Ok. But I do not see it as something that should postpone 4.2.1 as it is not a
regression and this simply never worked (AFAIK).

Martin

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

Re: [Freeipa-devel] FreeIPA 4.2.1 checklist

[Jan Pazdziora]

On Fri, Sep 04, 2015 at 09:03:27AM +0200, Martin Kosek wrote:
> ticket to the right version milestone ("FreeIPA 4.2.1") at the time the ticket
> is closed. But without proper tooling, I am afraid people may simply close the
> ticket within "FreeIPA 4.2.x backlog" and it would then not be clear what
> version it is fixed in.

Moving all resolved "FreeIPA 4.2.x backlog" to the correct milestone
at the point that release is released and/or branched might be
reasonable approximation.

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

Re: [Freeipa-devel] [PATCH 0309-0310] DNSSEC CI: extend DNSSEC CI tests

[Martin Basti]

On 09/03/2015 07:21 PM, Oleg Fayans wrote:

Hi Martin,

The two functions
test_disable_reenable_signing_master and
test_disable_reenable_signing_replica
the error message for the laste assertion is different, although the 
assertions are identical:

"RRSIG should be different" and "DNSKEY should be different".
Other than that, it's fine


On 09/03/2015 05:55 PM, Martin Basti wrote:

Attached patches improve DNSSEC CI tests.






Thank you for review.

Updated patches attached.
From f7fcac72cde98d84ecba31e99ad2fc50499a8f8f Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Tue, 1 Sep 2015 12:07:13 +0200
Subject: [PATCH 1/2] DNSSEC: improve CI test

Test disabling and re-enabling zone signing.
---
 ipatests/test_integration/test_dnssec.py | 113 +--
 1 file changed, 109 insertions(+), 4 deletions(-)

diff --git a/ipatests/test_integration/test_dnssec.py b/ipatests/test_integration/test_dnssec.py
index 74dc1be25476353e676f2601ace673212234df63..eca2aa0af94781c9dccd7788b12d287556583930 100644
--- a/ipatests/test_integration/test_dnssec.py
+++ b/ipatests/test_integration/test_dnssec.py
@@ -30,13 +30,17 @@ def resolve_with_dnssec(nameserver, query, log, rtype="SOA"):
 ans = res.query(query, rtype)
 return ans
 
+def get_RRSIG_record(nameserver, query, log, rtype="SOA"):
+ans = resolve_with_dnssec(nameserver, query, log, rtype=rtype)
+return ans.response.find_rrset(
+ans.response.answer, dns.name.from_text(query),
+dns.rdataclass.IN, dns.rdatatype.RRSIG,
+dns.rdatatype.from_text(rtype))
+
 
 def is_record_signed(nameserver, query, log, rtype="SOA"):
 try:
-ans = resolve_with_dnssec(nameserver, query, log, rtype=rtype)
-ans.response.find_rrset(ans.response.answer, dns.name.from_text(query),
-dns.rdataclass.IN, dns.rdatatype.RRSIG,
-dns.rdatatype.from_text(rtype))
+get_RRSIG_record(nameserver, query, log, rtype=rtype)
 except KeyError:
 return False
 except dns.exception.DNSException:
@@ -130,6 +134,103 @@ class TestInstallDNSSECLast(IntegrationTest):
 self.master.ip, test_zone_repl, self.log, timeout=5
 ), "DNS zone %s is not signed (master)" % test_zone
 
+def test_disable_reenable_signing_master(self):
+
+dnskey_old = resolve_with_dnssec(self.master.ip, test_zone,
+ self.log, rtype="DNSKEY").rrset
+
+# disable DNSSEC signing of zone on master
+args = [
+"ipa",
+"dnszone-mod", test_zone,
+"--dnssec", "false",
+]
+self.master.run_command(args)
+
+time.sleep(20)  # sleep a bit until LDAP changes are applied to DNS
+
+# test master
+assert not is_record_signed(
+self.master.ip, test_zone, self.log
+), "Zone %s is still signed (master)" % test_zone
+
+# test replica
+assert not is_record_signed(
+self.replicas[0].ip, test_zone, self.log
+), "DNS zone %s is still signed (replica)" % test_zone
+
+# reenable DNSSEC signing
+args = [
+"ipa",
+"dnszone-mod", test_zone,
+"--dnssec", "true",
+]
+self.master.run_command(args)
+
+time.sleep(20)  # sleep a bit until LDAP changes are applied to DNS
+
+# test master
+assert wait_until_record_is_signed(
+self.master.ip, test_zone, self.log, timeout=100
+), "Zone %s is not signed (master)" % test_zone
+
+# test replica
+assert wait_until_record_is_signed(
+self.replicas[0].ip, test_zone, self.log, timeout=200
+), "DNS zone %s is not signed (replica)" % test_zone
+
+dnskey_new = resolve_with_dnssec(self.master.ip, test_zone,
+ self.log, rtype="DNSKEY").rrset
+assert dnskey_old != dnskey_new, "DNSKEY should be different"
+
+def test_disable_reenable_signing_replica(self):
+
+dnskey_old = resolve_with_dnssec(self.replicas[0].ip, test_zone_repl,
+ self.log, rtype="DNSKEY").rrset
+
+# disable DNSSEC signing of zone on replica
+args = [
+"ipa",
+"dnszone-mod", test_zone_repl,
+"--dnssec", "false",
+]
+self.master.run_command(args)
+
+time.sleep(20)  # sleep a bit until LDAP changes are applied to DNS
+
+# test master
+assert not is_record_signed(
+self.master.ip, test_zone_repl, self.log
+), "Zone %s is still signed (master)" % test_zone_repl
+
+# test replica
+assert not is_record_signed(
+self.replicas[0].ip, test_zone_repl, self.log
+), "DNS zone %s is still signed (replica)" % test_zone_repl
+
+# reenable DNSSEC signing
+args = [
+"ipa",
+