Re: [Freeipa-devel] [PATCH 0079] Catch USBError during YubiKey location

2014-11-10 Thread Martin Kosek 
On 11/10/2014 08:31 AM, Alexander Bokovoy wrote:
 On Mon, 10 Nov 2014, Jan Cholasta wrote:
 Hi,

 Dne 7.11.2014 v 16:51 Nathaniel McCallum napsal(a):
 https://fedorahosted.org/freeipa/ticket/4693

 Is it good enough to just say No YubiKey found? Would it make sense to log
 the original message, for the sake of debugging why the yubikey was not 
 found?
 This is logged on the client side so it only would be visible if you
 would run 'ipa' tool with -v. Perhaps useful but my practice with
 yubikeys says that most of issues are basically permission-related:
 you've inserted the key and udev rules didn't change access to allow
 getting to it via libusb. In this case our debugging will hardly be
 helpful beyond 'yes, it is not accessible' which is already conveyed by
 the original message.

Ok. Though IMO, passing the USBError string to the error would still be a good
thing to do - unless we have a strong reason to hide it. Error stating Access
denied (insufficient permissions) would steer the person closer to the root
cause that just No YubiKey found.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0021] Fix minimal version of BIND for Fedora 20 and 21

2014-11-10 Thread Martin Kosek 
On 11/07/2014 05:14 PM, Petr Vobornik wrote:
 On 7.11.2014 16:57, Nathaniel McCallum wrote:
 On Fri, 2014-11-07 at 16:55 +0100, Petr Spacek wrote:
 Hello,

 Fix minimal version of BIND for Fedora 20 and 21.

 We should build new mkosek/freeipa COPR package ASAP to solve conflicts on
 upgrade.

 ACK

 
 Pushed to:
 ipa-4-1: 4662f28750e5d68cc268a090d5612d6cfb51e3e1
 master: 74e0a8cebca251bf89144597f521440407a469ba

I added this patch to F21rawhide and fired a new build in the COPR.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] FreeIPA 4.1 release preparations

2014-11-10 Thread Lukas Slebodnik 
On (09/11/14 10:09), Martin Kosek wrote:
On 11/08/2014 02:43 PM, Lukas Slebodnik wrote:
On (20/10/14 16:08), Martin Kosek wrote:
On 10/20/2014 04:00 PM, Jan Pazdziora wrote:
On Mon, Oct 20, 2014 at 03:58:27PM +0200, Petr Vobornik wrote:

The plan is to release 4.1 and then 4.0.4. Besides usual tarballs, 4.1 will
go into Fedora rawhide, f21-updates-testing and mkosek/freeipa copr repo 
(to
be usable on F20).

And RHEL 7 / CentOS 7?

For now, I would only maintain RHEL/CentOS 7.0 compatibility for main
mkosek/freeipa repo.

It is almost 3 weeks from this mail and freeipa-server cannot be installed 
from
mkosek/freeipa repo on  RHEL/CentOS 7.0.

bash-4.2# yum install freeipa-server
//snip

--- Package pki-base.noarch 0:10.2.0-3.el7.centos will be installed
-- Processing Dependency: jackson-jaxrs-json-provider for package: 
pki-base-10.2.0-3.el7.centos.noarch
-- Finished Dependency Resolution
Error: Package: pki-base-10.2.0-3.el7.centos.noarch (mkosek-freeipa)
Requires: jackson-jaxrs-json-provider
  You could try using --skip-broken to work around the problem
  You could try running: rpm -Va --nofiles --nodigest

There were some promises on freeipa-users but nothing has changed.

Is somebody working on this problem?
Maybe it is another candidate for inegtation tests.

LS

This problem is known, but it is not simple one to solve.
jackson-jaxrs-json-provider is a new dogtag Java dependency which broke the
package set on EL 7.0 which however brings a lot of and other build/runtime
dependencies.

Agree.
I just want to find solution and help desperate users on CentOS 7.

Question is how to solve this properly, this still needs some work and
discussion to happen as current approach obviously do not scale, as you
noticed.

IMHO, the best solution would be to separate dogtag from freeipa yum repo.
Pros:
* It would reduce dependency in freeipa repo
* dogtag team would maintain separate COPR repo for older distributions.
  (they know better about new dependencies and java packaging)
Cons:
Two COPR repositories would need to be enabled for installing latest
freeipa.

LS

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] FreeIPA 4.1 release preparations

2014-11-10 Thread Martin Kosek 
On 11/10/2014 10:09 AM, Lukas Slebodnik wrote:
 On (09/11/14 10:09), Martin Kosek wrote:
 On 11/08/2014 02:43 PM, Lukas Slebodnik wrote:
 On (20/10/14 16:08), Martin Kosek wrote:
 On 10/20/2014 04:00 PM, Jan Pazdziora wrote:
 On Mon, Oct 20, 2014 at 03:58:27PM +0200, Petr Vobornik wrote:

 The plan is to release 4.1 and then 4.0.4. Besides usual tarballs, 4.1 
 will
 go into Fedora rawhide, f21-updates-testing and mkosek/freeipa copr repo 
 (to
 be usable on F20).

 And RHEL 7 / CentOS 7?

 For now, I would only maintain RHEL/CentOS 7.0 compatibility for main
 mkosek/freeipa repo.

 It is almost 3 weeks from this mail and freeipa-server cannot be installed 
 from
 mkosek/freeipa repo on  RHEL/CentOS 7.0.

 bash-4.2# yum install freeipa-server
 //snip

 --- Package pki-base.noarch 0:10.2.0-3.el7.centos will be installed
 -- Processing Dependency: jackson-jaxrs-json-provider for package: 
 pki-base-10.2.0-3.el7.centos.noarch
 -- Finished Dependency Resolution
 Error: Package: pki-base-10.2.0-3.el7.centos.noarch (mkosek-freeipa)
Requires: jackson-jaxrs-json-provider
  You could try using --skip-broken to work around the problem
  You could try running: rpm -Va --nofiles --nodigest

 There were some promises on freeipa-users but nothing has changed.

 Is somebody working on this problem?
 Maybe it is another candidate for inegtation tests.

 LS

 This problem is known, but it is not simple one to solve.
 jackson-jaxrs-json-provider is a new dogtag Java dependency which broke the
 package set on EL 7.0 which however brings a lot of and other build/runtime
 dependencies.

 Agree.
 I just want to find solution and help desperate users on CentOS 7.

+1, me too.

 Question is how to solve this properly, this still needs some work and
 discussion to happen as current approach obviously do not scale, as you
 noticed.

 IMHO, the best solution would be to separate dogtag from freeipa yum repo.
 Pros:
 * It would reduce dependency in freeipa repo
 * dogtag team would maintain separate COPR repo for older distributions.
   (they know better about new dependencies and java packaging)

That makes sense, yes. I was thinking along these lines yesterday too.

 Cons:
 Two COPR repositories would need to be enabled for installing latest
 freeipa.

Exactly. With multiple required repos, those may quickly get out of sync with
regards to suppoted architectures or expectations about these repos.

However, if we agree on the expectations with the PKI team, could IPA own
cronjob that would watch PKI Copr repo on specified arches and rebuild it for
the common one using PKI team SRPMs?

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] FreeIPA Copr repo plan

2014-11-10 Thread Martin Kosek 
Hi guys,

Some time ago we started managing FreeIPA Copr repos (mkosek/freeipa) with a
target to have the latest greatest FreeIPA available for older arches (read -
RHEL/CentOS) and to allow people using older stable Fedoras (read - Fedora 20)
try FreeIPA 4.0+ releases which brought in several dependencies.

So far this was a more ad hoc approach, I think a more firm plan and tools are
due. I see several questions that needs to be decided:

1) What Copr repos do we want to maintain and what should be the expectations?
My take:

a) mkosek/freeipa: latest and greatest *released* FreeIPA. Built for F20+,
EPEL-7.0. Jan, this is the one you use in the FreeIPA CentOS container, right?
Does it fit your needs?

b) Branch repos: as mkosek/freeipa Copr repo would contain only the latest and
greatest release, would it make sense to have a Copr repo with *releases* per
supported branch to give users a choice? I.e.
* mkosek/freeipa-4.1
* mkosek/freeipa-4.0
These repos are there already, but not used consistently. I do not think we
should build all the dependency chain (too much overhead) for older systems
(F20/EPEL). But I assume we could at least build the freeipa SRPM itself for
these systems if it uses mkosek/freeipa as additional build root in Copr.

c) Daily repos
Should we deprecate old John's repos
(http://www.freeipa.org/page/Downloads#Bleeding_Edge) which is difficult to
maintain and replace them with Copr ones? I.e. to have common repo (e.g.
mkosek/freeipa-daily) built for the supported Fedoras (F20, F21, rawhide ATM)
including dependencies?

Should it contain daily master builds for all tracked projects (FreeIPA, SSSD,
389 DS, bind-dyndb-ldap)? Or do we simply want to let distribute it across
projects mkosek/freeipa-master, someone/sssd-master,
someone/389-ds-base-master? Second option may scale better better, the list of
such repos may be maintained somewhere (freeipa.org wiki).


2) We will need to have some tool chain and Jenkins CI jobs watching these
repos to make sure the build  run deps are OK. So far I used the attached 2
clumsy bash scripts to handle the repos build and one for analysis. But we will
need something better.


3) Scalability of the approach
Some dependencies are more difficult to maintain than the others. Especially
the PKI ones often required custom Java packaging (resteasy-base) or a
complicated dependency chain (the latest jackson-jaxrs-json-provider). It would
be great if PKI team helps with this effort, as Lukas proposed. Downside is
that mkosek/freeipa installation would require 2 Copr repos. But maybe we could
have a job syncing the PKI build/runtime dependencies directly to FreeIPA copr.
Whatever works and scale.

-- 
Martin Kosek mko...@redhat.com
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.


build-srpms.sh
Description: Bourne shell script
#!/usr/bin/python

from bs4 import BeautifulSoup
from optparse import OptionParser
import requests
import re

class Build(object):
def __init__(self):
self.build_status = build_status
self.files = files
self.missing_packages = missing_packages
self.p

def get_build_status(package):
s = requests.Session()
url = http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/epel-7-x86_64/%s; % package
r = s.get(url)
soup = BeautifulSoup(r.text)

files = []
build_result = False
for tr in soup.find(tbody).findAll(tr):
tds = tr.findAll(td)
f = tds[0].find(text=True)
if f == 'Parent Directory':
continue
if f.endswith('.rpm'):
build_result = True
files.append(f)

missing_packages = []
if not build_result:
url = http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/epel-7-x86_64/%s/root.log; % package
r = s.get(url)
root_log = r.text

m = re.search(r'Error: No Package found for (\S+)', root_log)
if m is not None:
missing_packages.append(m.groups(1)[0])

return build_result, files, missing_packages

def main():
# parse arguments
parser = OptionParser()

# parse options
(options, args) = parser.parse_args()

url = 'http://copr-be.cloud.fedoraproject.org/results/mkosek/freeipa/epel-7-x86_64/'
s = requests.Session()
r = s.get(url, data={})
soup = BeautifulSoup(r.text)

built_packages = []
broken_packages = []
missing_dependencies = {}

for tr in soup.find(tbody).findAll(tr):
tds = tr.findAll(td)
package = tds[0].find(text=True)
package_name = package.rsplit(-, 2)[0]
if package.endswith(.log) or package in ('Parent Directory', 'repodata'):
continue
build_result, files, missing_packages = get_build_status(package)

print package_name, OK if build_result else FAIL, missing_packages
if build_result:
built_packages.append(package_name)
else:
missing_dependencies[package_name] =

Re: [Freeipa-devel] [PATCH] 0027 Produce better error in group-add command.

2014-11-10 Thread David Kupka 

On 11/10/2014 08:20 AM, Jan Cholasta wrote:

Hi,

Dne 7.11.2014 v 15:26 David Kupka napsal(a):

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


I think you should use MutuallyExclusiveError.

Honza

Thanks, that's the error class I was searching for. Unfortunately, I 
didn't know this one so I used more abstract error class.


Fixed patch attached.

--
David Kupka
From bd7ed8ca7a43a423603d744a6081a49450fdc9af Mon Sep 17 00:00:00 2001
From: David Kupka dku...@redhat.com
Date: Wed, 5 Nov 2014 02:40:10 -0500
Subject: [PATCH] Produce better error in group-add command.

https://fedorahosted.org/freeipa/ticket/4611
---
 ipalib/plugins/group.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipalib/plugins/group.py b/ipalib/plugins/group.py
index 03e6893e3c7604268b503b28ea39ed3f610aec47..9ac9c7cd3595709d476687ee2efbe342a8ae0f6b 100644
--- a/ipalib/plugins/group.py
+++ b/ipalib/plugins/group.py
@@ -287,7 +287,7 @@ class group_add(LDAPCreate):
 if options['external']:
 entry_attrs['objectclass'].append('ipaexternalgroup')
 if 'gidnumber' in options:
-raise errors.RequirementError(name='gid')
+raise errors.MutuallyExclusiveError(message=_('Paramters can not be used together: \'gid\', \'external\''))
 elif not options['nonposix']:
 entry_attrs['objectclass'].append('posixgroup')
 if not 'gidnumber' in options:
-- 
2.1.0

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] FreeIPA Copr repo plan

2014-11-10 Thread Jakub Hrozek 
On Mon, Nov 10, 2014 at 12:07:46PM +0100, Martin Kosek wrote:
 Hi guys,
 
 Some time ago we started managing FreeIPA Copr repos (mkosek/freeipa) with a
 target to have the latest greatest FreeIPA available for older arches (read -
 RHEL/CentOS) and to allow people using older stable Fedoras (read - Fedora 20)
 try FreeIPA 4.0+ releases which brought in several dependencies.
 
 So far this was a more ad hoc approach, I think a more firm plan and tools are
 due. I see several questions that needs to be decided:
 
 1) What Copr repos do we want to maintain and what should be the expectations?
 My take:
 
 a) mkosek/freeipa: latest and greatest *released* FreeIPA. Built for F20+,
 EPEL-7.0. Jan, this is the one you use in the FreeIPA CentOS container, right?
 Does it fit your needs?

+1

 
 b) Branch repos: as mkosek/freeipa Copr repo would contain only the latest and
 greatest release, would it make sense to have a Copr repo with *releases* per
 supported branch to give users a choice? I.e.
 * mkosek/freeipa-4.1
 * mkosek/freeipa-4.0
 These repos are there already, but not used consistently. I do not think we
 should build all the dependency chain (too much overhead) for older systems
 (F20/EPEL). But I assume we could at least build the freeipa SRPM itself for
 these systems if it uses mkosek/freeipa as additional build root in Copr.

Is it worth it? Is the older supported branch some kind of LTM or just
happens to be alive because of some Fedora or RHEL release using it?

I think there is value in providing early access to RHEL/CentOS users
prior to dumping the RPMs onto them, but maintaining the repos is hard,
I think we should only commit to this work if there is a use-case.

 
 c) Daily repos
 Should we deprecate old John's repos
 (http://www.freeipa.org/page/Downloads#Bleeding_Edge) which is difficult to
 maintain and replace them with Copr ones? I.e. to have common repo (e.g.
 mkosek/freeipa-daily) built for the supported Fedoras (F20, F21, rawhide ATM)
 including dependencies?

Is there a build script or other infrastructure that would make the new
repo easy to maintain (easier than John's repo)? In general I think there
is quite a bit of value in the daily builds -- we can ask users if their
problem goes away with the latest builds and we could even use this for
some CI setups and we know early if something breaks.

 
 Should it contain daily master builds for all tracked projects (FreeIPA, SSSD,
 389 DS, bind-dyndb-ldap)? Or do we simply want to let distribute it across
 projects mkosek/freeipa-master, someone/sssd-master,
 someone/389-ds-base-master? Second option may scale better better, the list 
 of
 such repos may be maintained somewhere (freeipa.org wiki).

I think I might be missing something, but why do you think separate
repos are better?

 
 
 2) We will need to have some tool chain and Jenkins CI jobs watching these
 repos to make sure the build  run deps are OK. So far I used the attached 2
 clumsy bash scripts to handle the repos build and one for analysis. But we 
 will
 need something better.
 
 
 3) Scalability of the approach
 Some dependencies are more difficult to maintain than the others. Especially
 the PKI ones often required custom Java packaging (resteasy-base) or a
 complicated dependency chain (the latest jackson-jaxrs-json-provider). It 
 would
 be great if PKI team helps with this effort, as Lukas proposed. Downside is
 that mkosek/freeipa installation would require 2 Copr repos. But maybe we 
 could
 have a job syncing the PKI build/runtime dependencies directly to FreeIPA 
 copr.
 Whatever works and scale.

I thought you could 'include' one repo in another with COPR? Wouldn't
that solve the problem?

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] FreeIPA Copr repo plan

2014-11-10 Thread John Dennis 
On 11/10/2014 06:07 AM, Martin Kosek wrote:

 c) Daily repos Should we deprecate old John's repos 
 (http://www.freeipa.org/page/Downloads#Bleeding_Edge) which is
 difficult to maintain and replace them with Copr ones? I.e. to have
 common repo (e.g. mkosek/freeipa-daily) built for the supported
 Fedoras (F20, F21, rawhide ATM) including dependencies?

Nalin does the actual builds, I noticed he wasn't on the CC list so I
just added Nalin to this reply.

From what I know of Copr it's a better tool than our homegrown solution.
If you're already doing Copr builds then I don't see much logic in
keeping the old system. It makes sense to me there should be 1 entity
pumping out the builds using the same technology, why duplicate efforts?
Let's use the better technology.

 Should it contain daily master builds for all tracked projects
 (FreeIPA, SSSD, 389 DS, bind-dyndb-ldap)? Or do we simply want to let
 distribute it across projects mkosek/freeipa-master,
 someone/sssd-master, someone/389-ds-base-master? Second option may
 scale better better, the list of such repos may be maintained
 somewhere (freeipa.org wiki).

 3) Scalability of the approach Some dependencies are more difficult
 to maintain than the others. Especially the PKI ones often required
 custom Java packaging (resteasy-base) or a complicated dependency
 chain (the latest jackson-jaxrs-json-provider). It would be great if
 PKI team helps with this effort, as Lukas proposed. Downside is that
 mkosek/freeipa installation would require 2 Copr repos. But maybe we
 could have a job syncing the PKI build/runtime dependencies directly
 to FreeIPA copr. Whatever works and scale.

I'm not sure I'm a fan of the scattered repo approach simply because
it's hard for end users, too many yum repo configs to manage. One thing
I think did work well with the old setup is the repo contained all the
necessary dependencies which could not be satisfied from the system
repos. I recognize the difficulty of trying to be a build master for a
collection of difficult to build packages. What were we doing with the
old system was to pull packages built elsewhere (i.e. Kevin did the CS
builds) and merge them into the repo thus a user needed only point to
one user, but we weren't responsible for doing builds for everything,
just integrating, this makes the most sense to me.


-- 
John

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] FreeIPA Copr repo plan

2014-11-10 Thread Lukas Slebodnik 
On (10/11/14 07:53), John Dennis wrote:
On 11/10/2014 06:07 AM, Martin Kosek wrote:

 c) Daily repos Should we deprecate old John's repos 
 (http://www.freeipa.org/page/Downloads#Bleeding_Edge) which is
 difficult to maintain and replace them with Copr ones? I.e. to have
 common repo (e.g. mkosek/freeipa-daily) built for the supported
 Fedoras (F20, F21, rawhide ATM) including dependencies?

Nalin does the actual builds, I noticed he wasn't on the CC list so I
just added Nalin to this reply.

From what I know of Copr it's a better tool than our homegrown solution.
If you're already doing Copr builds then I don't see much logic in
keeping the old system. It makes sense to me there should be 1 entity
pumping out the builds using the same technology, why duplicate efforts?
Let's use the better technology.

 Should it contain daily master builds for all tracked projects
 (FreeIPA, SSSD, 389 DS, bind-dyndb-ldap)? Or do we simply want to let
 distribute it across projects mkosek/freeipa-master,
 someone/sssd-master, someone/389-ds-base-master? Second option may
 scale better better, the list of such repos may be maintained
 somewhere (freeipa.org wiki).

 3) Scalability of the approach Some dependencies are more difficult
 to maintain than the others. Especially the PKI ones often required
 custom Java packaging (resteasy-base) or a complicated dependency
 chain (the latest jackson-jaxrs-json-provider). It would be great if
 PKI team helps with this effort, as Lukas proposed. Downside is that
 mkosek/freeipa installation would require 2 Copr repos. But maybe we
 could have a job syncing the PKI build/runtime dependencies directly
 to FreeIPA copr. Whatever works and scale.

I'm not sure I'm a fan of the scattered repo approach simply because
mkosek/freeipa contains 44 different packages.
and approximately 1/4 of them are related just to dogtag for rhel7

it's hard for end users, too many yum repo configs to manage. One thing
I think did work well with the old setup is the repo contained all the
necessary dependencies which could not be satisfied from the system
repos. I recognize the difficulty of trying to be a build master for a
collection of difficult to build packages. What were we doing with the
old system was to pull packages built elsewhere (i.e. Kevin did the CS
builds) and merge them into the repo thus a user needed only point to
It *is not* possible to merge one COPR repo into another.
It is possible to add another yum repo into build dependencies in COPR
but it usually mean you will need to enable 2nd repo for installation of
freeipa as well.

LS

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] FreeIPA Copr repo plan

2014-11-10 Thread John Dennis 
 It *is not* possible to merge one COPR repo into another.
 It is possible to add another yum repo into build dependencies in COPR
 but it usually mean you will need to enable 2nd repo for installation of
 freeipa as well.

The script I wrote to manage the IPA repo entire purpose is to pull
packages from diverse locations and merge them into one single unified
repo. We call this the repo builder.

The way this system currently works is the repo builder listens for
messages from any number of builders, when it receives a message a new
build is available it merges the new package into the repo. To be more
precise it actually merges all the different OS versions, arches,
debuginfo, multilib etc. to produce one single repo whose layout is
identical to a Fedora repo. This is how we get a one-stop shopping repo
for users to point to.

My contribution to this process does not include doing any builds,
instead my repo and the script that drives it assembles a unified repo
from builds others do. I though Copr was capable of doing essentially
the same thing, but at the same time doing the actual builds. If Copr
cannot assemble an entire repo tree of OS's, arches, debuginfo,
multilib, etc, then that is a big missing piece which already
implemented and has been working well.


-- 
John

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 0671 ipa-restore: Don't crash if AD trust is not installed

2014-11-10 Thread Petr Viktorin 

This is a fix for: https://fedorahosted.org/freeipa/ticket/4668

--
Petr³

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] FreeIPA Copr repo plan

2014-11-10 Thread Jakub Hrozek 
On Mon, Nov 10, 2014 at 02:04:34PM +0100, Lukas Slebodnik wrote:
 It *is not* possible to merge one COPR repo into another.
 It is possible to add another yum repo into build dependencies in COPR

Ah, right. Adding the build dependencies allows you to add another SRPM,
to be built though..

 but it usually mean you will need to enable 2nd repo for installation of
 freeipa as well.
 
 LS

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH 0160] Fix objectclass violation during upgrade

2014-11-10 Thread Martin Basti 

Ticket: https://fedorahosted.org/freeipa/ticket/4680

Entry
dn: cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX

must be updated before
dn: cn=ADTrust Agents,cn=privileges,cn=pbac,$SUFFIX

Patch attached
Martin^2
From 0d2e383e080943be82b7edfd9396caef699ab8ee Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Mon, 10 Nov 2014 14:13:07 +0100
Subject: [PATCH] Upgrade: fix trusts objectclass violationi

Execute updates in proper ordering.
Curently ldap-updater implementation doesnt allow better fix.

Ticket: https://fedorahosted.org/freeipa/ticket/4680
---
 install/updates/59-trusts-sysacount.update | 8 
 install/updates/60-trusts.update   | 6 --
 install/updates/Makefile.am| 1 +
 3 files changed, 9 insertions(+), 6 deletions(-)
 create mode 100644 install/updates/59-trusts-sysacount.update

diff --git a/install/updates/59-trusts-sysacount.update b/install/updates/59-trusts-sysacount.update
new file mode 100644
index ..b90de80d27b36c9a7bfd3b358338a0a79d969813
--- /dev/null
+++ b/install/updates/59-trusts-sysacount.update
@@ -0,0 +1,8 @@
+# this update must be applied before 60-trusts.update, because current
+# implementation of ipa-ldap-updater doesn't keep the order of updates in
+# filesets
+dn: cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX
+add: objectClass: nestedgroup
+default: objectClass: GroupOfNames
+default: objectClass: top
+default: cn: adtrust agents
diff --git a/install/updates/60-trusts.update b/install/updates/60-trusts.update
index 9dabc806e2f747c47ab809cd2ed2150b2a13c2a6..79caa837a55eae0e05e1a94f3eabdda7b2b9cc38 100644
--- a/install/updates/60-trusts.update
+++ b/install/updates/60-trusts.update
@@ -10,12 +10,6 @@ default: member: uid=admin,cn=users,cn=accounts,$SUFFIX
 default: nsAccountLock: FALSE
 default: ipaUniqueID: autogenerate
 
-dn: cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX
-add: objectClass: nestedgroup
-default: objectClass: GroupOfNames
-default: objectClass: top
-default: cn: adtrust agents
-
 dn: cn=ADTrust Agents,cn=privileges,cn=pbac,$SUFFIX
 default: objectClass: top
 default: objectClass: groupofnames
diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am
index e62a64cea925aaeae9d013ab01a89371c727a6fd..255586c6de1cab52a526c1ca82b4720adf998eee 100644
--- a/install/updates/Makefile.am
+++ b/install/updates/Makefile.am
@@ -41,6 +41,7 @@ app_DATA =\
 	50-nis.update			\
 	50-ipaconfig.update		\
 	55-pbacmemberof.update		\
+	59-trusts-sysacount.update	\
 	60-trusts.update		\
 	61-trusts-s4u2proxy.update	\
 	62-ranges.update		\
-- 
1.8.3.1

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] FreeIPA Copr repo plan

2014-11-10 Thread Simo Sorce 
On Mon, 10 Nov 2014 12:07:46 +0100
Martin Kosek mko...@redhat.com wrote:

 3) Scalability of the approach
 Some dependencies are more difficult to maintain than the others.
 Especially the PKI ones often required custom Java packaging
 (resteasy-base) or a complicated dependency chain (the latest
 jackson-jaxrs-json-provider). It would be great if PKI team helps
 with this effort, as Lukas proposed. Downside is that mkosek/freeipa
 installation would require 2 Copr repos. But maybe we could have a
 job syncing the PKI build/runtime dependencies directly to FreeIPA
 copr. Whatever works and scale.

Do we use the REST interface ?
Would it be possible to simply build dogtag w/o it and avoid this
massive set of annoying dependencies ?

Simo.

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

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] FreeIPA Copr repo plan

2014-11-10 Thread Martin Kosek 
On 11/10/2014 01:49 PM, Jakub Hrozek wrote:
 On Mon, Nov 10, 2014 at 12:07:46PM +0100, Martin Kosek wrote:
 Hi guys,

 Some time ago we started managing FreeIPA Copr repos (mkosek/freeipa) with a
 target to have the latest greatest FreeIPA available for older arches (read -
 RHEL/CentOS) and to allow people using older stable Fedoras (read - Fedora 
 20)
 try FreeIPA 4.0+ releases which brought in several dependencies.

 So far this was a more ad hoc approach, I think a more firm plan and tools 
 are
 due. I see several questions that needs to be decided:

 1) What Copr repos do we want to maintain and what should be the 
 expectations?
 My take:

 a) mkosek/freeipa: latest and greatest *released* FreeIPA. Built for F20+,
 EPEL-7.0. Jan, this is the one you use in the FreeIPA CentOS container, 
 right?
 Does it fit your needs?
 
 +1
 

 b) Branch repos: as mkosek/freeipa Copr repo would contain only the latest 
 and
 greatest release, would it make sense to have a Copr repo with *releases* per
 supported branch to give users a choice? I.e.
 * mkosek/freeipa-4.1
 * mkosek/freeipa-4.0
 These repos are there already, but not used consistently. I do not think we
 should build all the dependency chain (too much overhead) for older systems
 (F20/EPEL). But I assume we could at least build the freeipa SRPM itself for
 these systems if it uses mkosek/freeipa as additional build root in Copr.
 
 Is it worth it? Is the older supported branch some kind of LTM or just
 happens to be alive because of some Fedora or RHEL release using it?
 
 I think there is value in providing early access to RHEL/CentOS users
 prior to dumping the RPMs onto them, but maintaining the repos is hard,
 I think we should only commit to this work if there is a use-case.

In this particular case we wanted to have a repo to build FreeIPA 4.0.x given
that mkosek/freeipa repo already contained 4.1. The purpose was to provide
option to people who do not want to update to early 4.1.0 yet.

 c) Daily repos
 Should we deprecate old John's repos
 (http://www.freeipa.org/page/Downloads#Bleeding_Edge) which is difficult to
 maintain and replace them with Copr ones? I.e. to have common repo (e.g.
 mkosek/freeipa-daily) built for the supported Fedoras (F20, F21, rawhide ATM)
 including dependencies?
 
 Is there a build script or other infrastructure that would make the new
 repo easy to maintain (easier than John's repo)? In general I think there
 is quite a bit of value in the daily builds -- we can ask users if their
 problem goes away with the latest builds and we could even use this for
 some CI setups and we know early if something breaks.

There seems to be a traction to use a single supported way of building RPMs and
not maintain 2 systems - see John Dennis' response.

 Should it contain daily master builds for all tracked projects (FreeIPA, 
 SSSD,
 389 DS, bind-dyndb-ldap)? Or do we simply want to let distribute it across
 projects mkosek/freeipa-master, someone/sssd-master,
 someone/389-ds-base-master? Second option may scale better better, the list 
 of
 such repos may be maintained somewhere (freeipa.org wiki).
 
 I think I might be missing something, but why do you think separate
 repos are better?

My idea was to decentralize it - to not overload FreeIPA developers with
maintaining nightly devel builds and it's potentially new dependencies but to
let domain experts from different teams to maintain it.

Also, people interested in nightly builds may not be interested in nightly
builds for all these packages, but maybe just SSSD. So they would just download
SSSD yum repo and enable it.

But if there is a value in having a united repo with nightly builds of all
these packages, maybe there could simply be a cron script merging all the
distributed Copr repos RPMs and placing them on fedorapeople.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] FreeIPA Copr repo plan

2014-11-10 Thread Martin Kosek 
On 11/10/2014 04:22 PM, Simo Sorce wrote:
 On Mon, 10 Nov 2014 12:07:46 +0100
 Martin Kosek mko...@redhat.com wrote:
 
 3) Scalability of the approach
 Some dependencies are more difficult to maintain than the others.
 Especially the PKI ones often required custom Java packaging
 (resteasy-base) or a complicated dependency chain (the latest
 jackson-jaxrs-json-provider). It would be great if PKI team helps
 with this effort, as Lukas proposed. Downside is that mkosek/freeipa
 installation would require 2 Copr repos. But maybe we could have a
 job syncing the PKI build/runtime dependencies directly to FreeIPA
 copr. Whatever works and scale.
 
 Do we use the REST interface ?

Yes:
https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=462beacc9d13968128fa320d155016df2d72a20a

And we plan to leverage it even more:
https://fedorahosted.org/freeipa/ticket/3473

IMO it is the right way instead of current HTML parsing approach.

 Would it be possible to simply build dogtag w/o it and avoid this
 massive set of annoying dependencies ?

Given above, unfortunately not.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] FreeIPA Copr repo plan

2014-11-10 Thread thierry bordaz 

On 11/10/2014 04:26 PM, Martin Kosek wrote:

On 11/10/2014 01:49 PM, Jakub Hrozek wrote:

On Mon, Nov 10, 2014 at 12:07:46PM +0100, Martin Kosek wrote:

Hi guys,

Some time ago we started managing FreeIPA Copr repos (mkosek/freeipa) with a
target to have the latest greatest FreeIPA available for older arches (read -
RHEL/CentOS) and to allow people using older stable Fedoras (read - Fedora 20)
try FreeIPA 4.0+ releases which brought in several dependencies.

So far this was a more ad hoc approach, I think a more firm plan and tools are
due. I see several questions that needs to be decided:

1) What Copr repos do we want to maintain and what should be the expectations?
My take:

a) mkosek/freeipa: latest and greatest *released* FreeIPA. Built for F20+,
EPEL-7.0. Jan, this is the one you use in the FreeIPA CentOS container, right?
Does it fit your needs?

+1


b) Branch repos: as mkosek/freeipa Copr repo would contain only the latest and
greatest release, would it make sense to have a Copr repo with *releases* per
supported branch to give users a choice? I.e.
* mkosek/freeipa-4.1
* mkosek/freeipa-4.0
These repos are there already, but not used consistently. I do not think we
should build all the dependency chain (too much overhead) for older systems
(F20/EPEL). But I assume we could at least build the freeipa SRPM itself for
these systems if it uses mkosek/freeipa as additional build root in Copr.

Is it worth it? Is the older supported branch some kind of LTM or just
happens to be alive because of some Fedora or RHEL release using it?

I think there is value in providing early access to RHEL/CentOS users
prior to dumping the RPMs onto them, but maintaining the repos is hard,
I think we should only commit to this work if there is a use-case.

In this particular case we wanted to have a repo to build FreeIPA 4.0.x given
that mkosek/freeipa repo already contained 4.1. The purpose was to provide
option to people who do not want to update to early 4.1.0 yet.

DS is building the latest and greatest release in copr.
I am using this DS repo to test it against IPA 4.0.x  and IPA 4.1.x latests.
Currently I am building IPA latests (srpms+rpms) on my own copr repos, 
so with a risk of taking wrong dependencies.
I would prefer to have a global per supported branches copr repos, like 
mkosek/freeipa-4-0...


thanks
thierry





c) Daily repos
Should we deprecate old John's repos
(http://www.freeipa.org/page/Downloads#Bleeding_Edge) which is difficult to
maintain and replace them with Copr ones? I.e. to have common repo (e.g.
mkosek/freeipa-daily) built for the supported Fedoras (F20, F21, rawhide ATM)
including dependencies?

Is there a build script or other infrastructure that would make the new
repo easy to maintain (easier than John's repo)? In general I think there
is quite a bit of value in the daily builds -- we can ask users if their
problem goes away with the latest builds and we could even use this for
some CI setups and we know early if something breaks.

There seems to be a traction to use a single supported way of building RPMs and
not maintain 2 systems - see John Dennis' response.


Should it contain daily master builds for all tracked projects (FreeIPA, SSSD,
389 DS, bind-dyndb-ldap)? Or do we simply want to let distribute it across
projects mkosek/freeipa-master, someone/sssd-master,
someone/389-ds-base-master? Second option may scale better better, the list of
such repos may be maintained somewhere (freeipa.org wiki).

I think I might be missing something, but why do you think separate
repos are better?

My idea was to decentralize it - to not overload FreeIPA developers with
maintaining nightly devel builds and it's potentially new dependencies but to
let domain experts from different teams to maintain it.

Also, people interested in nightly builds may not be interested in nightly
builds for all these packages, but maybe just SSSD. So they would just download
SSSD yum repo and enable it.

But if there is a value in having a united repo with nightly builds of all
these packages, maybe there could simply be a cron script merging all the
distributed Copr repos RPMs and placing them on fedorapeople.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 365 Fix CA certificate backup and restore

2014-11-10 Thread Jan Cholasta 

Hi,

the attached patch fixes https://fedorahosted.org/freeipa/ticket/4711.

Honza

--
Jan Cholasta
From 5c00f80cce0e0952252df4f7ec3922d71e8f2cc9 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Mon, 10 Nov 2014 16:24:22 +
Subject: [PATCH] Fix CA certificate backup and restore

Backup and restore /etc/pki/ca-trust/source/ipa.p11-kit.

Create /etc/ipa/nssdb after restore if necessary.

https://fedorahosted.org/freeipa/ticket/4711
---
 ipaplatform/base/paths.py|  2 +-
 ipaplatform/base/tasks.py|  9 +
 ipaplatform/redhat/tasks.py  | 43 
 ipaserver/install/ipa_backup.py  |  1 +
 ipaserver/install/ipa_restore.py | 35 +++-
 5 files changed, 66 insertions(+), 24 deletions(-)

diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py
index af50262..e28147a 100644
--- a/ipaplatform/base/paths.py
+++ b/ipaplatform/base/paths.py
@@ -92,7 +92,7 @@ class BasePathNamespace(object):
 PAM_LDAP_CONF = /etc/pam_ldap.conf
 PASSWD = /etc/passwd
 ETC_PKI_CA_DIR = /etc/pki-ca
-SYSTEMWIDE_CA_STORE = /etc/pki/ca-trust/source/anchors/
+SYSTEMWIDE_IPA_CA_CRT = /etc/pki/ca-trust/source/anchors/ipa-ca.crt
 IPA_P11_KIT = /etc/pki/ca-trust/source/ipa.p11-kit
 NSS_DB_DIR = /etc/pki/nssdb
 PKI_TOMCAT = /etc/pki/pki-tomcat
diff --git a/ipaplatform/base/tasks.py b/ipaplatform/base/tasks.py
index f2ba81f..9b15119 100644
--- a/ipaplatform/base/tasks.py
+++ b/ipaplatform/base/tasks.py
@@ -55,6 +55,15 @@ class BaseTaskNamespace(object):
 
 return
 
+def reload_systemwide_ca_store(self):
+
+Reloads the systemwide CA store.
+
+Returns True if the operation succeeded, False otherwise.
+
+
+return True
+
 def insert_ca_certs_into_systemwide_ca_store(self, ca_certs):
 
 Adds CA certificates from 'ca_certs' to the systemwide CA store
diff --git a/ipaplatform/redhat/tasks.py b/ipaplatform/redhat/tasks.py
index 3f5fc90..d0e3cde 100644
--- a/ipaplatform/redhat/tasks.py
+++ b/ipaplatform/redhat/tasks.py
@@ -158,8 +158,19 @@ class RedHatTaskNamespace(BaseTaskNamespace):
 auth_config.add_option(nostart)
 auth_config.execute()
 
+def reload_systemwide_ca_store(self):
+try:
+ipautil.run([paths.UPDATE_CA_TRUST])
+except CalledProcessError, e:
+root_logger.error(
+Could not update systemwide CA trust database: %s, e)
+return False
+else:
+root_logger.info(Systemwide CA database updated.)
+return True
+
 def insert_ca_certs_into_systemwide_ca_store(self, ca_certs):
-new_cacert_path = os.path.join(paths.SYSTEMWIDE_CA_STORE, 'ipa-ca.crt')
+new_cacert_path = paths.SYSTEMWIDE_IPA_CA_CRT
 
 if os.path.exists(new_cacert_path):
 try:
@@ -248,24 +259,18 @@ class RedHatTaskNamespace(BaseTaskNamespace):
 f.close()
 
 # Add the CA to the systemwide CA trust database
-try:
-ipautil.run([paths.UPDATE_CA_TRUST])
-except CalledProcessError, e:
-root_logger.info(Failed to add CA to the systemwide 
- CA trust database: %s % str(e))
-else:
-root_logger.info('Added the CA to the systemwide CA trust '
- 'database.')
-return True
+if not self.reload_systemwide_ca_store():
+return False
 
-return False
+return True
 
 def remove_ca_certs_from_systemwide_ca_store(self):
-ipa_ca_crt = os.path.join(paths.SYSTEMWIDE_CA_STORE, 'ipa-ca.crt')
+result = True
 update = False
 
 # Remove CA cert from systemwide store
-for new_cacert_path in (paths.IPA_P11_KIT, ipa_ca_crt):
+for new_cacert_path in (paths.IPA_P11_KIT,
+paths.SYSTEMWIDE_IPA_CA_CRT):
 if not os.path.exists(new_cacert_path):
 continue
 try:
@@ -273,21 +278,15 @@ class RedHatTaskNamespace(BaseTaskNamespace):
 except OSError, e:
 root_logger.error(
 Could not remove %s: %s, new_cacert_path, e)
+result = False
 else:
 update = True
 
 if update:
-try:
-ipautil.run([paths.UPDATE_CA_TRUST])
-except CalledProcessError, e:
-root_logger.error(
-Could not update systemwide CA trust database: %s, e)
+if not self.reload_systemwide_ca_store():
 return False
-else:
-root_logger.info(Systemwide CA database updated.)
-return True
 
-return False
+return result
 
 def backup_and_replace_hostname(self, fstore, statestore, hostname):
 old_hostname = socket.gethostname()
diff --git

[Freeipa-devel] [PATCHES] 366-372 Additional Coverity fixes

2014-11-10 Thread Jan Cholasta 

Hi,

the attached patches provide additional fixes for 
https://fedorahosted.org/freeipa/ticket/4651.


I'm not 100% sure if the fixes for ipa-sam and ipa-kdb are correct, 
please check them carefully.


Honza

--
Jan Cholasta
From a195644143042a0161de81472646f41f503ffe48 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Mon, 10 Nov 2014 17:20:18 +
Subject: [PATCH 1/7] Remove redefinition of LOG from ipa-otp-lasttoken

https://fedorahosted.org/freeipa/ticket/4651
---
 daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c
index d20fca1..15b404d 100644
--- a/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c
+++ b/daemons/ipa-slapi-plugins/ipa-otp-lasttoken/ipa_otp_lasttoken.c
@@ -47,9 +47,6 @@
 #include util.h
 
 #define PLUGIN_NAME   ipa-otp-lasttoken
-#define LOG(sev, ...) \
-slapi_log_error(SLAPI_LOG_ ## sev, PLUGIN_NAME, \
-%s: %s\n, __func__, __VA_ARGS__), -1
 
 static void *plugin_id;
 static const Slapi_PluginDesc preop_desc = {
-- 
2.1.0

From b5800224806278ed0d1a165acbe7a12fdd74fbf6 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Mon, 10 Nov 2014 17:33:23 +
Subject: [PATCH 2/7] Unload P11_Helper object's library when it is finalized
 in ipap11helper

https://fedorahosted.org/freeipa/ticket/4651
---
 ipapython/ipap11helper/library.c   | 5 +
 ipapython/ipap11helper/p11helper.c | 9 +++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/ipapython/ipap11helper/library.c b/ipapython/ipap11helper/library.c
index 51e24eb..619604d 100644
--- a/ipapython/ipap11helper/library.c
+++ b/ipapython/ipap11helper/library.c
@@ -70,6 +70,11 @@ CK_C_GetFunctionList loadLibrary(char* module, void** moduleHandle)
 
 	// Retrieve the entry point for C_GetFunctionList
 	pGetFunctionList = (CK_C_GetFunctionList) dlsym(pDynLib, C_GetFunctionList);
+	if (pGetFunctionList == NULL)
+	{
+		dlclose(pDynLib);
+		return NULL;
+	}
 
 	// Store the handle so we can dlclose it later
 	*moduleHandle = pDynLib;
diff --git a/ipapython/ipap11helper/p11helper.c b/ipapython/ipap11helper/p11helper.c
index 038c26c..558185e 100644
--- a/ipapython/ipap11helper/p11helper.c
+++ b/ipapython/ipap11helper/p11helper.c
@@ -66,6 +66,7 @@ PyObject_HEAD
 CK_SLOT_ID slot;
 CK_FUNCTION_LIST_PTR p11;
 CK_SESSION_HANDLE session;
+void *module_handle;
 } P11_Helper;
 
 typedef enum {
@@ -478,6 +479,7 @@ P11_Helper_new(PyTypeObject *type, PyObject *args, PyObject *kwds) {
 self-slot = 0;
 self-session = 0;
 self-p11 = NULL;
+self-module_handle = NULL;
 }
 
 return (PyObject *) self;
@@ -496,12 +498,12 @@ static int P11_Helper_init(P11_Helper *self, PyObject *args, PyObject *kwds) {
 CK_C_GetFunctionList pGetFunctionList = loadLibrary(library_path,
 module_handle);
 if (!pGetFunctionList) {
-if (module_handle != NULL)
-unloadLibrary(module_handle);
 PyErr_SetString(ipap11helperError, Could not load the library.);
 return -1;
 }
 
+self-module_handle = module_handle;
+
 /*
  * Load the function list
  */
@@ -567,9 +569,12 @@ P11_Helper_finalize(P11_Helper* self) {
  */
 self-p11-C_Finalize(NULL);
 
+unloadLibrary(self-module_handle);
+
 self-p11 = NULL;
 self-session = 0;
 self-slot = 0;
+self-module_handle = NULL;
 
 return Py_None;
 }
-- 
2.1.0

From 26d61f0284dba1ac98ae02260536772465da8819 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Mon, 10 Nov 2014 17:40:35 +
Subject: [PATCH 3/7] Fix Kerberos error handling in ipa-sam

https://fedorahosted.org/freeipa/ticket/4651
---
 daemons/ipa-sam/ipa_sam.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c
index 3b69f9e..e711299 100644
--- a/daemons/ipa-sam/ipa_sam.c
+++ b/daemons/ipa-sam/ipa_sam.c
@@ -4233,7 +4233,7 @@ static int bind_callback(LDAP *ldap_struct, struct smbldap_state *ldap_state, vo
 	krb5_free_principal(data.context, in_creds.server);
 	krb5_free_principal(data.context, in_creds.client);
 
-	if (rc) {
+	if (rc != 0  rc != KRB5KRB_AP_ERR_TKT_NYV  rc != KRB5KRB_AP_ERR_TKT_EXPIRED) {
 		rc = bind_callback_obtain_creds(data);
 		if (rc) {
 			bind_callback_cleanup(data, rc);
-- 
2.1.0

From 6a386daa320c0db9c47709330d793881bda3 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Mon, 10 Nov 2014 18:10:27 +
Subject: [PATCH 4/7] Fix unchecked return value in ipa-kdb

https://fedorahosted.org/freeipa/ticket/4651
---
 daemons/ipa-kdb/ipa_kdb_mspac.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index c8f6c76..debcd1b 100644
---