Re: [Freeipa-devel] [PATCH 0127] advice: Add legacy client configuration script using nss-ldap

[Alexander Bokovoy]

On Thu, 31 Oct 2013, Tomas Babej wrote:


Hi,

Part of: https://fedorahosted.org/freeipa/ticket/3833


ACK, since nss_ldap package contains both NSS and PAM modules.

--
/ Alexander Bokovoy

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

Re: [Freeipa-devel] [PATCH 0127] advice: Add legacy client configuration script using nss-ldap

[Martin Kosek]

On 10/31/2013 09:10 AM, Alexander Bokovoy wrote:
> On Thu, 31 Oct 2013, Tomas Babej wrote:
> 
>> Hi,
>>
>> Part of: https://fedorahosted.org/freeipa/ticket/3833
>>
> ACK, since nss_ldap package contains both NSS and PAM modules.
> 

Pushed to master, ipa-3-3.

Martin

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

Re: [Freeipa-devel] [PATCH 0125] ipatests: Add which package to legacy client advice

[Ana Krivokapic]

On 10/30/2013 04:18 PM, Tomas Babej wrote:
> Hi,
>
> Adds which package to the requirements, since older distros do not have it by
> default.
>
> Part of: https://fedorahosted.org/freeipa/ticket/3833
>
>
>
> ___
> Freeipa-devel mailing list
> Freeipa-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

You can use the bash built-in command `command`, instead of `which`, to find out
if a program exists:

command -v cacertdir_rehash

In other words, just replace `which` with `command -v`; there's no need to
install any additional packages.

-- 
Regards,

Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.

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

Re: [Freeipa-devel] [PATCH 0124] ipatests: Extend clear_sssd_cache to support non-systemd

[Ana Krivokapic]

On 10/30/2013 04:40 PM, Tomas Babej wrote:
> Hi,
>
> This allows us to clean sssd cache on older, non-systemd platforms.
>
> Part of: https://fedorahosted.org/freeipa/ticket/3833
>
>
>
> ___
> Freeipa-devel mailing list
> Freeipa-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

Looks good, ACK.

-- 
Regards,

Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.

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

Re: [Freeipa-devel] [PATCH 0126] ipatests: Restore SELinux context after restoring files from

[Ana Krivokapic]

On 10/30/2013 04:19 PM, Tomas Babej wrote:
> Hi,
>
> Without this patch, restored directories get home_t SELinux context.
>
> Part of: https://fedorahosted.org/freeipa/ticket/3833
>
>
>
> ___
> Freeipa-devel mailing list
> Freeipa-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

ACK

-- 
Regards,

Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.

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

Re: [Freeipa-devel] [PATCH 0124] ipatests: Extend clear_sssd_cache to support non-systemd

[Petr Viktorin]

On 10/31/2013 12:38 PM, Ana Krivokapic wrote:

On 10/30/2013 04:40 PM, Tomas Babej wrote:

Hi,

This allows us to clean sssd cache on older, non-systemd platforms.

Part of: https://fedorahosted.org/freeipa/ticket/3833



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


Looks good, ACK.



Pushed to
master: 775f2de4ecc047428034ed68dbbae934fa38de8a
ipa-3-3: a4ea378e5123c9883814952df06dfe6482da307d


--
Petr³

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

Re: [Freeipa-devel] [PATCH 0126] ipatests: Restore SELinux context after restoring files from

[Petr Viktorin]

On 10/31/2013 01:02 PM, Ana Krivokapic wrote:

On 10/30/2013 04:19 PM, Tomas Babej wrote:

Hi,

Without this patch, restored directories get home_t SELinux context.

Part of: https://fedorahosted.org/freeipa/ticket/3833



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


ACK



Pushed to:
master: 4fd88140b181b5f69c9312070840a4020593eb90
ipa-3-3: 63451c0b16ea501fafc2678873e604f55ae81437


--
Petr³

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

Re: [Freeipa-devel] [PATCH 0123] ipatests: Do not use /usr/bin hardcoded paths

[Ana Krivokapic]

On 10/30/2013 04:01 PM, Tomas Babej wrote:
> Hi,
>
> The RHEL 5.9 clients do not have /usr/bin symlinks.
>
> Part of: https://fedorahosted.org/freeipa/ticket/3833
>
>
>
> ___
> Freeipa-devel mailing list
> Freeipa-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

ACK

-- 
Regards,

Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.

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

Re: [Freeipa-devel] [PATCH 0123] ipatests: Do not use /usr/bin hardcoded paths

[Petr Viktorin]

On 10/31/2013 02:05 PM, Ana Krivokapic wrote:

On 10/30/2013 04:01 PM, Tomas Babej wrote:

Hi,

The RHEL 5.9 clients do not have /usr/bin symlinks.

Part of: https://fedorahosted.org/freeipa/ticket/3833



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


ACK


Pushed to:
master: 44998feace93a01b3dfda8fce6ff7aa35fffbabf
ipa-3-3: d90862aaabfe663c1696152e982460821b0cb564



--
Petr³

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

[Freeipa-devel] [PATCHES] 198-202 Refactor indirect membership processing

[Jan Cholasta]

Hi,

the attached patches fix .

Tested with 25000 users.

Honza

--
Jan Cholasta
>From e4b1880a7159377fe9996d9353edce80d495e051 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Thu, 31 Oct 2013 11:47:53 +
Subject: [PATCH 1/5] Move IPA specific code from LDAPClient to the ldap2
 plugin.

https://fedorahosted.org/freeipa/ticket/3971
---
 ipapython/ipaldap.py   | 208 +
 ipaserver/plugins/ldap2.py | 199 +++
 2 files changed, 203 insertions(+), 204 deletions(-)

diff --git a/ipapython/ipaldap.py b/ipapython/ipaldap.py
index b6a5305..f6966e0 100644
--- a/ipapython/ipaldap.py
+++ b/ipapython/ipaldap.py
@@ -893,13 +893,6 @@ class LDAPClient(object):
 def _init_connection(self):
 self.conn = None
 
-def get_api(self):
-"""Return the API if available, otherwise None
-
-May be overridden in a subclass.
-"""
-return None
-
 @contextlib.contextmanager
 def error_handler(self, arg_desc=None):
 """Context manager that handles LDAPErrors
@@ -1219,14 +1212,10 @@ class LDAPClient(object):
 res = []
 truncated = False
 
-if time_limit is None or size_limit is None:
-config = self.get_ipa_config()
-if time_limit is None:
-time_limit = config.get('ipasearchtimelimit', [-1])[0]
-if size_limit is None:
-size_limit = config.get('ipasearchrecordslimit', [0])[0]
-if time_limit == 0:
-time_limit = -1
+if time_limit is None or time_limit == 0:
+time_limit = -1.0
+if size_limit is None:
+size_limit = 0
 if not isinstance(size_limit, int):
 size_limit = int(size_limit)
 if not isinstance(time_limit, float):
@@ -1257,37 +1246,6 @@ class LDAPClient(object):
 if not res and not truncated:
 raise errors.NotFound(reason='no such entry')
 
-if attrs_list and (
-'memberindirect' in attrs_list or '*' in attrs_list):
-for r in res:
-if not 'member' in r[1]:
-continue
-else:
-members = r[1]['member']
-indirect = self.get_members(
-r[0], members, membertype=MEMBERS_INDIRECT,
-time_limit=time_limit, size_limit=size_limit)
-if len(indirect) > 0:
-r[1]['memberindirect'] = indirect
-if attrs_list and (
-'memberofindirect' in attrs_list or '*' in attrs_list):
-for r in res:
-if 'memberof' in r[1]:
-memberof = r[1]['memberof']
-del r[1]['memberof']
-elif 'memberOf' in r[1]:
-memberof = r[1]['memberOf']
-del r[1]['memberOf']
-else:
-continue
-direct, indirect = self.get_memberof(
-r[0], memberof, time_limit=time_limit,
-size_limit=size_limit)
-if len(direct) > 0:
-r[1]['memberof'] = direct
-if len(indirect) > 0:
-r[1]['memberofindirect'] = indirect
-
 return (res, truncated)
 
 def find_entry_by_attr(self, attr, value, object_class, attrs_list=None,
@@ -1336,164 +1294,6 @@ class LDAPClient(object):
 raise errors.LimitsExceeded()
 return entry[0]
 
-def get_ipa_config(self, attrs_list=None):
-"""Returns the IPA configuration entry.
-
-Overriden in the subclasses that have access to IPA configuration.
-"""
-return {}
-
-def get_memberof(self, entry_dn, memberof, time_limit=None,
- size_limit=None):
-"""
-Examine the objects that an entry is a member of and determine if they
-are a direct or indirect member of that group.
-
-entry_dn: dn of the entry we want the direct/indirect members of
-memberof: the memberOf attribute for entry_dn
-
-Returns two memberof lists: (direct, indirect)
-"""
-
-assert isinstance(entry_dn, DN)
-
-self.log.debug(
-"get_memberof: entry_dn=%s memberof=%s", entry_dn, memberof)
-if not type(memberof) in (list, tuple):
-return ([], [])
-if len(memberof) == 0:
-return ([], [])
-
-search_entry_dn = ldap.filter.escape_filter_chars(str(entry_dn))
-attr_list = ["memberof"]
-searchfilter = "(|(member=%s)(memberhost=%s)(memberuser=%s))" % (
-search_entry_dn, search_entry_dn, search_entry_dn)
-
-# Search only the groups for which the object is a member to
-# determine if it is directly or indirectly associated.
-
-results = []
-for group in m

Re: [Freeipa-devel] [PATCH 0121] ipatests: Add support for hosts referenced by a keyword

[Petr Viktorin]

On 10/30/2013 03:57 PM, Tomas Babej wrote:

On 10/29/2013 01:00 PM, Petr Viktorin wrote:

On 10/24/2013 12:20 PM, Tomas Babej wrote:

On 10/22/2013 10:44 AM, Petr Viktorin wrote:

On 10/22/2013 10:09 AM, Tomas Babej wrote:

On 10/22/2013 09:54 AM, Petr Viktorin wrote:

On 10/22/2013 09:20 AM, Tomas Babej wrote:

Hi,

Adds support for host definition by a environment variables of the
following form:

KEYWORDHOST__envX, where X is the number of the environment
for which host referenced by a keyword should be defined.

You can also optionally use KEYWORDHOST__IP_envX to define
the IP address directly, otherwise the framework will try to resolve
the hostname.

Adds a required_keyword_hosts attribute to the IntegrationTest
class,
which can test developer use to specify the keyword hosts that this
particular test requires. If not all required keyword hosts are
available, the test will be skipped.

All keyword hosts are accessible to the IntegrationTests via the
keyword_hosts attribute, which contains a dictionary keyed by the
keywords.



Why is this necessary?
What's wrong with just extending the current scheme with more roles?




The need for keyword hosts arised with the implementation of the
legacy
client test suite.

As each of these tests needs a precise type (pre-defined and
pre-configured) of VM, and not a generic client, you need to restrict
the test case to specific host type.

One test might be restricted to RHEL 5.10 with nss-pam-ldapd,
another to
FreeBSD, next one to CentOS with nss-pam-ldapd, next to CentOS with
old
version of SSSD...

Each testcase that needs a new type of preconfigured host, we would
need
to introduce a new role, which would need to be integrated in the
framework. In such implementation, we would lose loose coupling
between
the test framework and the test themselves, and make them less
pluggable.


The framework itself (excluding the configuration part) should be able
to handle this nicely using the existing role mechanism. It's true
that in some places it's currently hard-wired to just a few roles, but
supporting completely custom roles shouldn't be a problem.
I'd prefer if this system was used, rather than basically adding a
second role system, which we'd have to support even if we get rid of
the current config part.

The envvar-based configuration is not as flexible, but I'd rather make
this part somewhat unpleasant than making the framework complex. We
plan to move to a simpler configuration method anyway.
That said, you can basically keep the variable name scheme you use in
this patch; just maybe use TESTHOST rather than KEYWORDHOST.



I rewired the patch to use the current role system.

Please look if you have any additional issues.



I only have two naming nitpicks.
- The roles aren't really "dynamic"; eventually all the "dynamicness"
should be specific just to the envvar configuration system, and a few
shortcuts like `replicas` for `host_by_role('replica')`. I think
"extra" would be a better term.
- The environment variable names could be more descriptive. They store
a hostname, not a role, so instead of $ROLE__envX I'd prefer
$TESTHOST__envX

Other than that the changes look great!



Thanks, updated patch attached.



ACK, pushed to
master: b1bffb5ecad0fdaa2f560efd2b75c76bedc4423c
ipa-3-3: 960c6bf301fe3a00205a895acabe47bac5ac9349


--
Petr³

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

Re: [Freeipa-devel] [PATCHES] 106-113 Access raw LDAP values directly from LDAPEntry

[Martin Kosek]

On 10/29/2013 04:17 PM, Petr Viktorin wrote:
> On 10/29/2013 01:34 PM, Jan Cholasta wrote:
>> On 16.10.2013 18:13, Petr Viktorin wrote:
>>> On 10/14/2013 10:59 AM, Jan Cholasta wrote:
 On 10.10.2013 09:45, Jan Cholasta wrote:
> On 9.10.2013 13:57, Petr Viktorin wrote:
> [...]
>> 109. Decode and encode attribute values in LDAPEntry on demand.
>>
>> The syncing looks rather over-engineered to me.
>> Did you consider a custom MutableSequence for the values?
>> I think it would be much cleaner in the end than merging two sets of
>> changes together.
>
> I'm not entirely happy about it either, but it works. I did consider a
> custom sequence type, but I didn't feel like it was the right time to
> this kind of change in this patchset.
>
> Unlike the (DN, dict) -> LDAPEntry
> transition, this change won't be backward compatible and there is a lot
> of isinstance(value, list) and entry[attr] = list() kind of things in
> the framework code.
>>>
>>> That's what I was afraid of.
>>>
>>> We could live with `isinstance(value, list)`; hopefully we could get rid
>>> of `type(value) == list` that is the real problem.
>>> With `entry[attr] = list()` we could convert automatically.
>>>
>>> But OK, let's settle for a worse solution in the meantime.
>>>
>>>
>>> To be frank I don't particularly like the LDAPEntryView.
>>> While the dict-like interface is great, there isn't a case for storing a
>>> Raw view long-term, i.e. you'd always want to do something like
>>>  values = entry.raw[x]
>>>  ...
>>>  entry.raw[x] = new_values
>>> rather than
>>>  raw = entry.raw
>>>  values = raw[x]
>>>  ...
>>>  raw[x] = new_values
>>> The latter is confusing because LDAPEntryView and RawLDAPEntryView are
>>> two classes that have exactly the same interface, but do something
>>> different. In a duck-typed world that's a recipe for disaster.
>>> I think it would be better if the view implemented just the dict
>>> protocol, and not `conn`, `dn`, `nice`, `raw`, etc.
>>> The code would also be much simpler without the elaborate view class
>>> hierarchy.
>>>
>>> If you don't agree then at least don't make `raw` available on raw views
>>> and `nice` on nice views; the programmer *always* needs to know which
>>> version they're working with so these aren't necessary.
>>
>> I agree. Most of the attributes are leftovers from a previous
>> implementation, which didn't work very well. I should have removed them
>> a long time ago. Thanks for pointing this out!
>>
>> Updated the views to provide only the dict interface, removed "nice" and
>> "multi_value" properties and also removed "single_value" from the raw view.
> 
> Looks much better now. Hopefully _sync_attr can dissappear one day.
> 
>> I think it would also help (in the future?) to make the value lists
>> more
>> set-like, since the order doesn't matter.
>
> +1
>
> Honza
>

 Updated patches attached.

>>>
>>> 110.
>>> It can't hurt to have this in for now.
>>>
>>> 111 - 121 look great!
> 
> 106 - 121: ACK

106-121 pushed to master.

Martin

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

[Freeipa-devel] Reminder: Patchwork

[Ana Krivokapic]

Hello IPA developers,

I would like to remind everyone about our Patchwork instance[1]. This tool helps
us to better coordinate work and be more efficient, so let's try to remember to
use it consistently. It takes only a few seconds of extra work per patch
submission/review, which could potentially save us much more time. It is
especially useful to mark the patch as 'Under Review' when you start reviewing
it, so that others are aware of it and they don't start reviewing the same
patch. That way, we can avoid the situation of two people accidentally doing the
review of the same patch at the same time.

I have just cleaned up the Patchwork instance as best as I could so it should
now hopefully reflect the real situation on the state of patches.

We also have some instructions on how to use it on our wiki[2].

Thanks!

[1] https://patchwork.acksyn.org/project/FreeIPA/list/
[2] 
http://www.freeipa.org/page/Contribute/Code#Tracking_patches_.28Experimental.29

-- 
Regards,

Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.

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

Re: [Freeipa-devel] Reminder: Patchwork

[Simo Sorce]

On Thu, 2013-10-31 at 18:52 +0100, Ana Krivokapic wrote:
> Hello IPA developers,
> 
> I would like to remind everyone about our Patchwork instance[1]. This tool 
> helps
> us to better coordinate work and be more efficient, so let's try to remember 
> to
> use it consistently. It takes only a few seconds of extra work per patch
> submission/review, which could potentially save us much more time. It is
> especially useful to mark the patch as 'Under Review' when you start reviewing
> it, so that others are aware of it and they don't start reviewing the same
> patch. That way, we can avoid the situation of two people accidentally doing 
> the
> review of the same patch at the same time.
> 
> I have just cleaned up the Patchwork instance as best as I could so it should
> now hopefully reflect the real situation on the state of patches.
> 
> We also have some instructions on how to use it on our wiki[2].
> 
> Thanks!
> 
> [1] https://patchwork.acksyn.org/project/FreeIPA/list/
> [2] 
> http://www.freeipa.org/page/Contribute/Code#Tracking_patches_.28Experimental.29

Ana,
thanks for going through it, I try to keep it up to date but have had
little time recently.
I
Incidentally the machine run out of memory and the database crashed :-(
I added more memory and restarted the instance, please let me know if
everything is ok, it looks good to me.

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] Reminder: Patchwork

[Jakub Hrozek]

On Thu, Oct 31, 2013 at 06:52:10PM +0100, Ana Krivokapic wrote:
> Hello IPA developers,
> 
> I would like to remind everyone about our Patchwork instance[1]. This tool 
> helps
> us to better coordinate work and be more efficient, so let's try to remember 
> to
> use it consistently. It takes only a few seconds of extra work per patch
> submission/review, which could potentially save us much more time. It is
> especially useful to mark the patch as 'Under Review' when you start reviewing
> it, so that others are aware of it and they don't start reviewing the same
> patch. That way, we can avoid the situation of two people accidentally doing 
> the
> review of the same patch at the same time.
> 
> I have just cleaned up the Patchwork instance as best as I could so it should
> now hopefully reflect the real situation on the state of patches.
> 
> We also have some instructions on how to use it on our wiki[2].
> 
> Thanks!
> 
> [1] https://patchwork.acksyn.org/project/FreeIPA/list/
> [2] 
> http://www.freeipa.org/page/Contribute/Code#Tracking_patches_.28Experimental.29

Does setting the patch state with "X-Patchwork-Status:" header work for
anyone? I haven't tried it recently, but it would be a nice improvement.

Currently I update all SSSD reviews manually which is a bit tedious.
With a sane e-mail client (*cough*mutt*cough*), one can add a header
with one keystroke.

btw I also found out that automatically marking the patch as Pushed only
works for me some times. I'm not sure about the pattern, but it happens
more often for patches that are pushed to multiple branches. Do other
developers see the same?

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

Re: [Freeipa-devel] certificate renewal

[Rob Crittenden]

Vaede, Roger (Contractor) wrote:

I cannot upgrade to IPA 3.0 at this time, these are live machines.
I only want to renew only the primary server the one that has an expired 
certificate.
How can I tell if the server is running on CA?


If you do a search like this:

# ldapsearch -LLL -Y GSSAPI -b cn=masters,cn=ipa,cn=etc,dc=example,dc=com cn

You'll get a listing, per-master, of the services on it. Look for the CA 
service.


Some of the certificates are common among multiple CA replicas, and some 
are machine-specific. They can be renewed only one one master and then 
copied to the others, this is why I asked.


As you'll see, this process is rather hairy and prone to error. I've 
done this any number of times on an IPA 3.x server while I worked on 
automating it but AFAIK never on a 2.x one. In theory it should work the 
same. In theory.


The first thing you'll need to do is get a newer version of certmonger, 
at least certmonger-0.61-3.el6.


IIRC you are currently tracking a bunch of bogus certs in certmonger. 
I'd one by one stop tracking them:


# getcert list | grep Request

for each cert do

# getcert stop-tracking -i 

Next, you need to determine the PIN for the CA NSS database:

# grep internal= /var/lib/pki-ca/conf/password.conf

Now we need to tell certmonger about all the CA certificates it needs to 
renew


for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert 
cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca"

do
/usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n 
\"${nickname}\" -c dogtag-ipa-renew-agent -P 

done

We also need to renew the agent certificate that IPA uses to authenticate:

# /usr/bin/getcert start-tracking -d /etc/httpd/alias -n ipaCert -c 
dogtag-ipa-renew-agent -p /etc/httpd/alias/pwdfile.txt


Use "getcert list" to confirm that these 5 certs are now being tracked 
and note the Request IDs.


Now time for the wayback machine, go back to when these certs are all 
still valid. I'd recommend a day or two before the earliest expiration.


You can force a renewal with:

 # getcert resubmit -i 

Do this for each one. Each should end up in a MONITORING state.

Double-check that the audit certificate has a trust of u,u,Pu. If not 
you can fix this with:


# certutil -M -n "auditSigningCert cert-pki-ca" -d /var/lib/pki-ca/alias 
-t u,u,Pu


Ok, now things get really fun. The dogtag configuration file has a 
base64-encoded copy of most of these certificates in it. You'll need to 
update those by hand.


What I'd recommend is for each nickname in /var/lib/pki-ca/alias do:

certutil -L -d /var/lib/pki-ca/alias -n  -a > /tmp/nickname

Then edit /etc/pki-ca/CS.cfg and find the cert entry for each one and 
replace the blobs. The option names are like ca.audit_signing.cert, 
ca.ocsp_signing.cert, etc. It should be fairly straightforward. There 
are 5 certs you need to replace.


Here are the nicknames and values:

'auditSigningCert cert-pki-ca': 'ca.audit_signing.cert'
'ocspSigningCert cert-pki-ca': 'ca.ocsp_signing.cert'
'caSigningCert cert-pki-ca': 'ca.signing.cert'
'subsystemCert cert-pki-ca': 'ca.subsystem.cert'
'Server-Cert cert-pki-ca': 'ca.sslserver.cert'

Note that the output from certutil will be in PEM format, with headers 
and broken on a 64-character line. You'll need to drop the header/footer 
and make them into a single line.


Backing up this file in advance would be a good idea.

Now you can try to restart the CA to see what happens. It should come up 
fine:


# /sbin/service pki-cad restart

For the ipaCert value in /etc/httpd/alias you have another job to do. 
The certificates allowed to authenticate are stored in the CA LDAP 
database. You'll need to use ldapmodify to fix things up.


Start by looking at the new value for ipaCert. You need to do two things:

# certutil -L -d /etc/httpd/alias -n ipaCert

Note the value of serial number.

Next you need the base64-encoded value of the cert like before:

# certutil -L -d /etc/httpd/alias -n ipaCert -a

Again you'll need to drop the header/footer and combine this into a 
single line.


Next see what is already there with:

# ldapsearch -x -h localhost -p 7389 -D 'cn=directory manager' -W -b 
uid=ipara,ou=People,o=ipaca


You need to replace the serial number in the description attribute with 
the new one. The serial number is the 2nd number. The format of the 
description line is:


2;;;

The change is going to look something like:

# ldapmodify -x -h localhost -p 7389 -D 'cn=directory manager' -W
dn: uid=ipara,ou=People,o=ipaca
changetype: modify
add: usercertificate;binary
usercertificate;binary: MII...=
replace: description
description: 2;9;CN=Certificate Authority,O=EXAMPLE.COM;CN=IPA 
RA,O=EXAMPLE.COM


^D to exit

Now tackle the Apache and 389-ds certs:

# /usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-REALM -n 
Server-Cert -p /etc/dirsrv/slapd-REALM/pwdfile.txt


# /usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n 
Server-Cert -p /etc/dirsrv/slapd

Re: [Freeipa-devel] Reminder: Patchwork

[Simo Sorce]

On Thu, 2013-10-31 at 19:26 +0100, Jakub Hrozek wrote:
> On Thu, Oct 31, 2013 at 06:52:10PM +0100, Ana Krivokapic wrote:
> > Hello IPA developers,
> > 
> > I would like to remind everyone about our Patchwork instance[1]. This tool 
> > helps
> > us to better coordinate work and be more efficient, so let's try to 
> > remember to
> > use it consistently. It takes only a few seconds of extra work per patch
> > submission/review, which could potentially save us much more time. It is
> > especially useful to mark the patch as 'Under Review' when you start 
> > reviewing
> > it, so that others are aware of it and they don't start reviewing the same
> > patch. That way, we can avoid the situation of two people accidentally 
> > doing the
> > review of the same patch at the same time.
> > 
> > I have just cleaned up the Patchwork instance as best as I could so it 
> > should
> > now hopefully reflect the real situation on the state of patches.
> > 
> > We also have some instructions on how to use it on our wiki[2].
> > 
> > Thanks!
> > 
> > [1] https://patchwork.acksyn.org/project/FreeIPA/list/
> > [2] 
> > http://www.freeipa.org/page/Contribute/Code#Tracking_patches_.28Experimental.29
> 
> Does setting the patch state with "X-Patchwork-Status:" header work for
> anyone? I haven't tried it recently, but it would be a nice improvement.

I thought I had enabled it, ping me tomorrow morning (EST) if it doesn't
work and we can test it.

> Currently I update all SSSD reviews manually which is a bit tedious.
> With a sane e-mail client (*cough*mutt*cough*), one can add a header
> with one keystroke.
> 
> btw I also found out that automatically marking the patch as Pushed only
> works for me some times. I'm not sure about the pattern, but it happens
> more often for patches that are pushed to multiple branches. Do other
> developers see the same?

It matches the patch using a sha hash, so if you do things like
stripping automatically stripping whitespaces with git am or the sender
uses a different mode to generate the diff (like presence or absence of
--patience) it may fail to recognize the patch.

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] Reminder: Patchwork

[Jakub Hrozek]

On Thu, Oct 31, 2013 at 02:50:21PM -0400, Simo Sorce wrote:
> On Thu, 2013-10-31 at 19:26 +0100, Jakub Hrozek wrote:
> > On Thu, Oct 31, 2013 at 06:52:10PM +0100, Ana Krivokapic wrote:
> > > Hello IPA developers,
> > > 
> > > I would like to remind everyone about our Patchwork instance[1]. This 
> > > tool helps
> > > us to better coordinate work and be more efficient, so let's try to 
> > > remember to
> > > use it consistently. It takes only a few seconds of extra work per patch
> > > submission/review, which could potentially save us much more time. It is
> > > especially useful to mark the patch as 'Under Review' when you start 
> > > reviewing
> > > it, so that others are aware of it and they don't start reviewing the same
> > > patch. That way, we can avoid the situation of two people accidentally 
> > > doing the
> > > review of the same patch at the same time.
> > > 
> > > I have just cleaned up the Patchwork instance as best as I could so it 
> > > should
> > > now hopefully reflect the real situation on the state of patches.
> > > 
> > > We also have some instructions on how to use it on our wiki[2].
> > > 
> > > Thanks!
> > > 
> > > [1] https://patchwork.acksyn.org/project/FreeIPA/list/
> > > [2] 
> > > http://www.freeipa.org/page/Contribute/Code#Tracking_patches_.28Experimental.29
> > 
> > Does setting the patch state with "X-Patchwork-Status:" header work for
> > anyone? I haven't tried it recently, but it would be a nice improvement.
> 
> I thought I had enabled it, ping me tomorrow morning (EST) if it doesn't
> work and we can test it.

Will do, I need someone to submit an acceptable patch first :-)

> 
> > Currently I update all SSSD reviews manually which is a bit tedious.
> > With a sane e-mail client (*cough*mutt*cough*), one can add a header
> > with one keystroke.
> > 
> > btw I also found out that automatically marking the patch as Pushed only
> > works for me some times. I'm not sure about the pattern, but it happens
> > more often for patches that are pushed to multiple branches. Do other
> > developers see the same?
> 
> It matches the patch using a sha hash, so if you do things like
> stripping automatically stripping whitespaces with git am or the sender
> uses a different mode to generate the diff (like presence or absence of
> --patience) it may fail to recognize the patch.

Ah, stripping the whitespace might be the culprit. I do have that option
enabled. Most SSSD contributors use the same git format-patch flags[1], so
hopefully that shouldn't be an issue.

[1] git format-patch -M -C --patience --full-index

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

[Freeipa-devel] Building FreeIPA on Debian Unstable

[Adam Young]

I'm about to take off for a week, and want to make sure that I don't 
lose the momentum I've put in so far.  I spent agood portion of 
yesterday and today trying to get a Debian build going, and I think that 
this is worth sharing with the larger team.  Since FreeIPA has been RPM 
focused thus far,  I suspect that there is a need to prime-the-pump on 
Debian development.



1.  Installed Debian testing in a VM via an ISO.  I've had this VM for a 
while, so really just had to clone it and boot it.
2.  Set the repos to be the sid (unstable) repos instead of Jessie 
(testing)  by editing the file /etc/apt/sources.list  and replacing 
jessie with sid

3.  created a file /etc/apt/apt.conf with just the following line:
APT::Default-Release "unstable";
4.apt-get dist-upgrade
5. Reboot.
6. Loggd in and cloned the debian repo:
 git clone git://anonscm.debian.org/git/pkg-freeipa/freeipa.git

Technically, that is a lie...I had another FreeIPA repo already cloned, 
so instead I edited the .git/config file to add support for the above 
repo, and then did a fetch and checkout of the debian-unstable branch.



OK...now I am in trial and error state.  I've tried doing two different 
tasks, both related, but I am not sure how.



I used this as a guide
http://www.debian.org/doc/manuals/maint-guide/build.en.html


To build the package I ran:

dpkg-buildpackage

Which told me about all of the missing packages.  I had to modify the 
control file as some of the packages are no longer supporting the same 
files.  Onechange I made, which is suspect is shown here:


diff --git a/debian/control b/debian/control
index 66aedb4..e69cf6c 100644
--- a/debian/control
+++ b/debian/control
@@ -33,9 +33,7 @@ Build-Depends: quilt, debhelper (>= 9), dh-autoreconf,
  python-support,
 # server
  389-ds-base-dev (>= 1.1.3),
- libndr-dev,
- libndr-standard-dev,
- libsamba-util-dev,
+ samba-dev,
  libsvrcore-dev,
  libtevent-dev,
  uuid-dev,

Eventully this failed because I need a tarball to build a package. In 
FreeIPA, this is done via


make  tarballs

but that failed early on.  Rob's suggestion was to run

make version-update tarballs

which seemed to fix the issue somewhat.

The dpkg-buildpackage seems to be applying patches in place in the git 
repo.  I suspect that I should be running it with different command line 
switches telling it where to put the interim files etc.


I was able to fake out the process above by doing

cd ..
tar -zcf freeipa_3.2.1.orig.tar.gz freeipa

and re-running dpkg-buildpackage.  That was how I identified that the 
the krad.h files were not in libkrb-dev.  I comment them out with the 
below patch:


diff --git a/daemons/configure.ac b/daemons/configure.ac
index 21d4e7a..cda4498 100644
--- a/daemons/configure.ac
+++ b/daemons/configure.ac
@@ -53,15 +53,15 @@ dnl - Check for KRB5
 dnl 
---


 AC_CHECK_HEADER(krb5.h, [], [AC_MSG_ERROR([krb5.h not found])])
-AC_CHECK_HEADER(krad.h, [], [AC_MSG_ERROR([krad.h not found])])
+#AC_CHECK_HEADER(krad.h, [], [AC_MSG_ERROR([krad.h not found])])
 AC_CHECK_LIB(krb5, main, [], [AC_MSG_ERROR([libkrb5 not found])])
 AC_CHECK_LIB(k5crypto, main, [krb5crypto=k5crypto], [krb5crypto=crypto])
-AC_CHECK_LIB(krad, main, [], [AC_MSG_ERROR([libkrad not found])])
+#AC_CHECK_LIB(krad, main, [], [AC_MSG_ERROR([libkrad not found])])
 KRB5_LIBS="-lkrb5 -l$krb5crypto -lcom_err"
-KRAD_LIBS="-lkrad"
+#KRAD_LIBS="-lkrad"


And...that was pretty much as far as I got.

Once we get a working process we can clean up the documentation.

Looks like we need 1.12 of Kerberos to get Radius support, worth pinging 
the Debian krb supporters to see if they have a package in the works.


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

Re: [Freeipa-devel] certificate renewal

[Vaede, Roger (Contractor)]

+ for nickname in '"auditSigningCert cert-pki-ca"' '"ocspSigningCert 
cert-pki-ca"' '"subsystemCert cert-pki-ca"' '"Server-Cert cert-pki-ca"'
+ /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n '"Server-Cert' 
'cert-pki-ca"' -c dogtag-ipa-renew-agent -P 969321642067
Error: unused extra arguments were supplied.
getcert - client certificate enrollment tool

error popped up.

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: Thursday, October 31, 2013 2:41 PM
To: Vaede, Roger (Contractor); 'freeipa-devel@redhat.com'
Subject: Re: [Freeipa-devel] certificate renewal

Vaede, Roger (Contractor) wrote:
> I cannot upgrade to IPA 3.0 at this time, these are live machines.
> I only want to renew only the primary server the one that has an expired 
> certificate.
> How can I tell if the server is running on CA?

If you do a search like this:

# ldapsearch -LLL -Y GSSAPI -b cn=masters,cn=ipa,cn=etc,dc=example,dc=com cn

You'll get a listing, per-master, of the services on it. Look for the CA 
service.

Some of the certificates are common among multiple CA replicas, and some are 
machine-specific. They can be renewed only one one master and then copied to 
the others, this is why I asked.

As you'll see, this process is rather hairy and prone to error. I've done this 
any number of times on an IPA 3.x server while I worked on automating it but 
AFAIK never on a 2.x one. In theory it should work the same. In theory.

The first thing you'll need to do is get a newer version of certmonger, at 
least certmonger-0.61-3.el6.

IIRC you are currently tracking a bunch of bogus certs in certmonger. 
I'd one by one stop tracking them:

# getcert list | grep Request

for each cert do

# getcert stop-tracking -i 

Next, you need to determine the PIN for the CA NSS database:

# grep internal= /var/lib/pki-ca/conf/password.conf

Now we need to tell certmonger about all the CA certificates it needs to renew

for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" 
"subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca"
do
 /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n 
\"${nickname}\" -c dogtag-ipa-renew-agent -P  done

We also need to renew the agent certificate that IPA uses to authenticate:

# /usr/bin/getcert start-tracking -d /etc/httpd/alias -n ipaCert -c 
dogtag-ipa-renew-agent -p /etc/httpd/alias/pwdfile.txt

Use "getcert list" to confirm that these 5 certs are now being tracked and note 
the Request IDs.

Now time for the wayback machine, go back to when these certs are all still 
valid. I'd recommend a day or two before the earliest expiration.

You can force a renewal with:

  # getcert resubmit -i 

Do this for each one. Each should end up in a MONITORING state.

Double-check that the audit certificate has a trust of u,u,Pu. If not you can 
fix this with:

# certutil -M -n "auditSigningCert cert-pki-ca" -d /var/lib/pki-ca/alias -t 
u,u,Pu

Ok, now things get really fun. The dogtag configuration file has a 
base64-encoded copy of most of these certificates in it. You'll need to update 
those by hand.

What I'd recommend is for each nickname in /var/lib/pki-ca/alias do:

certutil -L -d /var/lib/pki-ca/alias -n  -a > /tmp/nickname

Then edit /etc/pki-ca/CS.cfg and find the cert entry for each one and replace 
the blobs. The option names are like ca.audit_signing.cert, 
ca.ocsp_signing.cert, etc. It should be fairly straightforward. There are 5 
certs you need to replace.

Here are the nicknames and values:

'auditSigningCert cert-pki-ca': 'ca.audit_signing.cert'
'ocspSigningCert cert-pki-ca': 'ca.ocsp_signing.cert'
'caSigningCert cert-pki-ca': 'ca.signing.cert'
'subsystemCert cert-pki-ca': 'ca.subsystem.cert'
'Server-Cert cert-pki-ca': 'ca.sslserver.cert'

Note that the output from certutil will be in PEM format, with headers and 
broken on a 64-character line. You'll need to drop the header/footer and make 
them into a single line.

Backing up this file in advance would be a good idea.

Now you can try to restart the CA to see what happens. It should come up
fine:

# /sbin/service pki-cad restart

For the ipaCert value in /etc/httpd/alias you have another job to do. 
The certificates allowed to authenticate are stored in the CA LDAP database. 
You'll need to use ldapmodify to fix things up.

Start by looking at the new value for ipaCert. You need to do two things:

# certutil -L -d /etc/httpd/alias -n ipaCert

Note the value of serial number.

Next you need the base64-encoded value of the cert like before:

# certutil -L -d /etc/httpd/alias -n ipaCert -a

Again you'll need to drop the header/footer and combine this into a single line.

Next see what is already there with:

# ldapsearch -x -h localhost -p 7389 -D 'cn=directory manager' -W -b 
uid=ipara,ou=People,o=ipaca

You need to replace the serial number in the description attribute with the new 
one. The serial number is the 2nd number. The format of the description line is:

2;;;

The change

Re: [Freeipa-devel] certificate renewal

[Rob Crittenden]

Vaede, Roger (Contractor) wrote:

+ for nickname in '"auditSigningCert cert-pki-ca"' '"ocspSigningCert cert-pki-ca"' 
'"subsystemCert cert-pki-ca"' '"Server-Cert cert-pki-ca"'
+ /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n '"Server-Cert' 
'cert-pki-ca"' -c dogtag-ipa-renew-agent -P 969321642067
Error: unused extra arguments were supplied.
getcert - client certificate enrollment tool

error popped up.


Looks like the quoting is a problem. I guess I'd run them individually, 
there are only 5 after all. The nicknames have a space so you need to 
quote them to keep the shell happy.


rob



-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Thursday, October 31, 2013 2:41 PM
To: Vaede, Roger (Contractor); 'freeipa-devel@redhat.com'
Subject: Re: [Freeipa-devel] certificate renewal

Vaede, Roger (Contractor) wrote:

I cannot upgrade to IPA 3.0 at this time, these are live machines.
I only want to renew only the primary server the one that has an expired 
certificate.
How can I tell if the server is running on CA?


If you do a search like this:

# ldapsearch -LLL -Y GSSAPI -b cn=masters,cn=ipa,cn=etc,dc=example,dc=com cn

You'll get a listing, per-master, of the services on it. Look for the CA 
service.

Some of the certificates are common among multiple CA replicas, and some are 
machine-specific. They can be renewed only one one master and then copied to 
the others, this is why I asked.

As you'll see, this process is rather hairy and prone to error. I've done this 
any number of times on an IPA 3.x server while I worked on automating it but 
AFAIK never on a 2.x one. In theory it should work the same. In theory.

The first thing you'll need to do is get a newer version of certmonger, at 
least certmonger-0.61-3.el6.

IIRC you are currently tracking a bunch of bogus certs in certmonger.
I'd one by one stop tracking them:

# getcert list | grep Request

for each cert do

# getcert stop-tracking -i 

Next, you need to determine the PIN for the CA NSS database:

# grep internal= /var/lib/pki-ca/conf/password.conf

Now we need to tell certmonger about all the CA certificates it needs to renew

for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert 
cert-pki-ca" "Server-Cert cert-pki-ca"
do
  /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n \"${nickname}\" -c 
dogtag-ipa-renew-agent -P  done

We also need to renew the agent certificate that IPA uses to authenticate:

# /usr/bin/getcert start-tracking -d /etc/httpd/alias -n ipaCert -c 
dogtag-ipa-renew-agent -p /etc/httpd/alias/pwdfile.txt

Use "getcert list" to confirm that these 5 certs are now being tracked and note 
the Request IDs.

Now time for the wayback machine, go back to when these certs are all still 
valid. I'd recommend a day or two before the earliest expiration.

You can force a renewal with:

   # getcert resubmit -i 

Do this for each one. Each should end up in a MONITORING state.

Double-check that the audit certificate has a trust of u,u,Pu. If not you can 
fix this with:

# certutil -M -n "auditSigningCert cert-pki-ca" -d /var/lib/pki-ca/alias -t 
u,u,Pu

Ok, now things get really fun. The dogtag configuration file has a 
base64-encoded copy of most of these certificates in it. You'll need to update 
those by hand.

What I'd recommend is for each nickname in /var/lib/pki-ca/alias do:

certutil -L -d /var/lib/pki-ca/alias -n  -a > /tmp/nickname

Then edit /etc/pki-ca/CS.cfg and find the cert entry for each one and replace 
the blobs. The option names are like ca.audit_signing.cert, 
ca.ocsp_signing.cert, etc. It should be fairly straightforward. There are 5 
certs you need to replace.

Here are the nicknames and values:

'auditSigningCert cert-pki-ca': 'ca.audit_signing.cert'
'ocspSigningCert cert-pki-ca': 'ca.ocsp_signing.cert'
'caSigningCert cert-pki-ca': 'ca.signing.cert'
'subsystemCert cert-pki-ca': 'ca.subsystem.cert'
'Server-Cert cert-pki-ca': 'ca.sslserver.cert'

Note that the output from certutil will be in PEM format, with headers and 
broken on a 64-character line. You'll need to drop the header/footer and make 
them into a single line.

Backing up this file in advance would be a good idea.

Now you can try to restart the CA to see what happens. It should come up
fine:

# /sbin/service pki-cad restart

For the ipaCert value in /etc/httpd/alias you have another job to do.
The certificates allowed to authenticate are stored in the CA LDAP database. 
You'll need to use ldapmodify to fix things up.

Start by looking at the new value for ipaCert. You need to do two things:

# certutil -L -d /etc/httpd/alias -n ipaCert

Note the value of serial number.

Next you need the base64-encoded value of the cert like before:

# certutil -L -d /etc/httpd/alias -n ipaCert -a

Again you'll need to drop the header/footer and combine this into a single line.

Next see what is already there with:

# ldapsearch -x -h localhost -p 7389 -D 'cn=directory manage