Re: [Freeipa-devel] [PATCH] Fix format string typo

[Sumit Bose]

On Tue, Jun 04, 2013 at 10:56:59AM +0200, Sumit Bose wrote:
> On Tue, Jun 04, 2013 at 10:49:45AM +0200, Petr Viktorin wrote:
> > On 06/03/2013 03:41 PM, Martin Kosek wrote:
> > >On 06/03/2013 03:39 PM, Sumit Bose wrote:
> > >>Hi,
> > >>
> > >>this patch just fixes a typo.
> > >>
> > >>bye,
> > >>Sumit
> > >>
> > >
> > >Obvious ACK. Pushed to master, ipa-3-2.
> > >
> > >Martin
> > 
> > Is the patch really right? It caused a new compiler warning:
> > 
> > format '%lu' expects argument of type 'long unsigned int', but
> > argument 6 has type 'uint32_t' [-Wformat=]
> 
> ah, sorry, I didn't check the compiler output carefully enough, I'll
> send a fix.

sorry, for the delay, fix attached.

bye,
Sumit
> 
> bye,
> Sumit
> > 
> > -- 
> > Petr³
> 
> ___
> Freeipa-devel mailing list
> Freeipa-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
From 1bbf2626a0ef5c127b35e700e7eb2e2feec6659e Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Fri, 7 Jun 2013 18:17:55 +0200
Subject: [PATCH] Fix type of printf argument

---
 daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_common.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_common.c 
b/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_common.c
index 
fafc55a497620024e45186b48ed84029e273f5ef..6f784804cd39acdf88ceceb0e21b272a04fa13fc
 100644
--- a/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_common.c
@@ -518,7 +518,8 @@ int find_sid_for_ldap_entry(struct slapi_entry *entry,
 
 ret = find_sid_for_id(id, plugin_id, base_dn, dom_sid, ranges, &sid);
 if (ret != 0) {
-LOG_FATAL("Cannot convert Posix ID [%lu] into an unused SID.\n", id);
+LOG_FATAL("Cannot convert Posix ID [%lu] into an unused SID.\n",
+  (unsigned long) id);
 goto done;
 }
 
-- 
1.8.1.4

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

[Freeipa-devel] Announcing the release of Dogtag 10.0.3

[Ade Lee]

The Dogtag team is proud to announce the third errata build for 
Dogtag v10.0.0. 

Builds are available for Fedora 18 and Fedora 19 in the updates-testing
repositories.  Please try them out and provide karma to move them to the
F18 and F19 stable repositories.

== Build Versions ==
pki-core-10.0.3-1
pki-ra-10.0.3-1
pki-tps-10.0.3-1
dogtag-pki-10.0.3-1
dogtag-pki-theme-10.0.3-1
pki-console-10.0.3-1

== Highlights since Dogtag v. 10.0.2 ==
* Fixes for security flaws in the TPS as described in CVE-2013-1885 and 
  CVE-2013-1886
* Added checking for sane lengths of the fields in subject DNs in the 
  TPS, to prevent a TPS crash.
* Previously the server certificate name was partially hard-coded.  Now
  in Tomcat-based subsystems, it can be fully configured using 
  pki_ssl_server_nickname parameter.
* Corrections and additions to man pages and other documentation.

== Detailed Changes since Dogtag v. 10.0.2 ==
akoneru (1):
#599 Improve pkispawn "Installation Summary" block
 
alee (1):
#486 Document migration steps for dogtag 9 -> dogtag 10 instances
 
awnuk (4):
#607 Port plug-in randomizing validity
#571 Port patch allowing to include in CRLs NextUpdate calculated base 
 on ThisUpdate
BZ 951501 - correcting JavaScript inability to handle big numbers
BZ 966189 - fix various TPS flaws

cfu (1):
BZ 952500 - small patch to remove eclipse warning in fix to BZ 952500

edewata (1)
#631 Hard-coded server certificate nickname.

jmagne (1):
BZ 963073 - rhcs81 tps crash for CN over than 64 bytes

mharmsen (3):
#606 add restart/start at boot info to pkispawn man page
#610 Document limitation in using GUI install
#629 Package ownership of '/usr/share/pki/etc/' directory 



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

Re: [Freeipa-devel] Configuring FreeIPA with JBoss EAP

[Peter Skopek]

Hi Martin,

the main reason why I suggested to not include the script in EAP is that we removed all similar scripts (for example data-source 
definition files) from its directories to keep is as simple and clean as possible.
JBoss EAP 6 configuration changes needed to integrate with FreeIPA are quite stable and as EAP has it as API/CLI it is not going to 
change in the near future (all JBoss EAP 6 [6.0.0, 6.0.1, 6.1.0] releases will work with configuration proposed in config. document).


I can understand, that similar reasons exist in FreeIPA side. So, the best way would be your proposal to create the 
"freeipa-client-jboss" subpackage.


Regards,
Peter

On 06/07/2013 02:58 PM, Martin Kosek wrote:

Hello Jan a Peter, freeipa-devel users,

There was recently a project of integrating FreeIPA server with Jboss EAP. One
of the results of this project should be a script able to conveniently
configure JBoss EAP on a machine to use FreeIPA as an identity&authentication
backend.

What I would like to find out is what would be the best place to store&maintain
such script. AFAIK, JBoss EAP did not want to keep the configuration script
with their project - can you Peter please share the reasons for it? I was
thinking it would be then easier to maintain the script according to JBoss EAP
releases.

Second option would be to deploy the script with FreeIPA project. Then, they
would also conform to FreeIPA release schedule and not JBoss ones. So I was
pondering where should we put scripts like this one, it is quite a specific
script, so I do not want to keeping it with freeipa-client package.

In this case I would propose creating a new optional subpackage
"freeipa-client-jboss" which would include all scripts/docs for the JBoss EAP
integration (may extend in future). In future, there may also come more
thematic FreeIPA integration scripts when they cannot be stored in relevant
upstream projects.

Any ideas? Is the correct approach to keep configuration scripts for other
upstream projects?

Thanks,
Martin



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

Re: [Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range

[Ana Krivokapic]

On 06/07/2013 12:15 PM, Tomas Babej wrote:
> On 05/31/2013 12:08 PM, Ana Krivokapic wrote:
>> Hello,
>>
>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3635.
>>
>>
>>
>> ___
>> Freeipa-devel mailing list
>> Freeipa-devel@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
> Hi, the patch itself works as it should, I have only some refactoring 
> comments:
>
> 1.) There already is a add_range method that is called from within trust_add's
> execute()
> and handles some range validation (currently only whether domain's SID of new 
> and
> existing range are equal, my patch 67 add some more).
>
> Your patch introduces a new method validate_range() that is called from 
> execute(),
> which leads to some duplication of the logic, mainly two same calls to the API
> (getting
> the info about the old range via idrange_show)
>
> I'd rather we keep all the validation in one place, preferably inside the
> add_range method
> or refactored out of it in the new method that is called only from 
> add_range().
>
> 2.) That being said, other parts of refactoring are nice and make code more
> clear, +1.
>
> Tomas

My first instinct was to place this validation in the add_range() method.
However, add_range() is called after the trust itself is added, and validation
introduced by this patch needs to happen before the trust is added (we need to
prevent the addition of trust in case the validation fails).

As for the code duplication, you are right about that. I tried to minimize
duplication - resulting updated patch attached.

-- 
Regards,

Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.

From bccca7cdfc94aeac27168baa1a4c0d32d312c2b2 Mon Sep 17 00:00:00 2001
From: Ana Krivokapic 
Date: Fri, 31 May 2013 12:01:23 +0200
Subject: [PATCH] Fail when adding a trust with a different range

When adding a trust, if an id range already exists for this trust,
and options --base-id/--range-size are provided with the trust-add command,
trust-add should fail.

https://fedorahosted.org/freeipa/ticket/3635
---
 ipalib/plugins/trust.py | 59 +++--
 1 file changed, 43 insertions(+), 16 deletions(-)

diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index 3cb0ed98005ae5bd11b39f8ae01c9470d1bfc9c4..9b5676820347044c469e98e2998170528a9fb05d 100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -155,6 +155,8 @@
 autofill=True,
 )
 
+DEFAULT_RANGE_SIZE = 20
+
 def trust_type_string(level):
 """
 Returns a string representing a type of the trust. The original field is an enum:
@@ -287,7 +289,7 @@ class trust_add(LDAPCreate):
 Int('range_size?',
 cli_name='range_size',
 label=_('Size of the ID range reserved for the trusted domain'),
-default=20,
+default=DEFAULT_RANGE_SIZE,
 autofill=True
 ),
 )
@@ -301,14 +303,26 @@ def execute(self, *keys, **options):
 error=_('pysss_murmur is not available on the server ' \
 'and no base-id is given.'))
 
-if 'trust_type' in options:
-if options['trust_type'] == u'ad':
-result = self.execute_ad(*keys, **options)
-else:
-raise errors.ValidationError(name=_('trust type'), error=_('only "ad" is supported'))
-else:
+if 'trust_type' not in options:
 raise errors.RequirementError(name=_('trust type'))
 
+if options['trust_type'] != u'ad':
+raise errors.ValidationError(
+name=_('trust type'),
+error=_('only "ad" is supported')
+)
+
+if not self.validate_range(*keys, **options):
+raise errors.ValidationError(
+name=_('id range'),
+error=_(
+'An id range already exists for this trust. '
+'You should either delete the old range, or '
+'exclude --base-id/--range-size options from the command.'
+)
+)
+
+result = self.execute_ad(*keys, **options)
 self.add_range(*keys, **options)
 
 trust_filter = "cn=%s" % result['value']
@@ -325,19 +339,32 @@ def execute(self, *keys, **options):
 
 return result
 
+def get_old_range(self, range_name):
+try:
+return api.Command['idrange_show'](range_name)
+except errors.NotFound:
+return None
+
+def validate_range(self, *keys, **options):
+"""
+If a range for this trusted domain already exists,
+'--base-id' or '--range-size' options should not be specified.
+"""
+range_name = keys[-1].upper()+'_id_range'
+range_exists = self.get_old_range(range_name) is not None
+base_id = options.get('base_id')
+range_size = opti

Re: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types

[Alexander Bokovoy]

On Fri, 07 Jun 2013, Tomas Babej wrote:

On 06/07/2013 03:41 PM, Alexander Bokovoy wrote:

Hi,

in patch 0061:

On Fri, 07 Jun 2013, Tomas Babej wrote:

+range_types = {
+u'ipa-local': unicode(_(u'local domain range')),
+u'ipa-ad-winsync': unicode(_('Active Directory winsync 
range')),

+u'ipa-ad-trust': unicode(_('Active Directory domain range')),
+u'ipa-ad-trust-posix': unicode(_('Active Directory 
trust range with '

+'POSIX attributes')),
+u'ipa-ipa-trust': unicode(_('IPA trust range')),
+  }

Why there is _(u'local domain range') and then others without Unicode
strings? Either way is fine but there should be consistency.


Sure, fixed.


The rest of this patch would be much shorter if there wouldn't
additional whitespace. Could you please git rid of that?


Whitespaces are intentional, these are fixes for PEP8 E302 errors.

If they are intentional, please send them as separate patch.


Sending the whole patchset updated.

Please split the whitespace fixes from the functional ones.

--
/ Alexander Bokovoy

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

[Freeipa-devel] Announcing FreeIPA 3.2.1

[Martin Kosek]

The FreeIPA team is proud to announce FreeIPA v3.2.1.

It can be downloaded from http://www.freeipa.org/page/Downloads. The new
version has also been built for Fedora 19 and is on its way to updates-testing.

== Highlights in 3.2.1 ==

=== New features for 3.2.1 ===
* dnszone-add command now interactively prompts user when it needs IP address
of a name server instead of failing in the server phase
* Improved debugging level of DNS dynamic update in ipa-client-install (see
ipaclient-install.log)
* Support multiple local domain ID ranges with RID base set

=== Bug fixes ===
* Directory Server CLDAP responder now returns a result in all cases to avoid
timeouts or freezes with Windows DC or other tools probing this interface.
* User passwords may contain non-ASCII characters again
* Missing Web UI HBAC Test tab is returned back in the UI menu
* Manual Web UI configuration page for other browsers (e.g. Internet Explorer
10) is fixed
* Removal of ID range of an active trust is no longer allowed
* ... and many others stabilization fixes, see Detailed changelog for full 
details

== Upgrading ==
An IPA server can be upgraded simply by installing updated rpms. The server
does not need to be shut down in advance.

Due to changes related to OCSP/CRL URI fix [1], ipa-ca.DOMAIN DNS name is
automatically converted from a set of CNAMEs to a set of A/ records
pointing to FreeIPA servers with CA configured.

FreeIPA servers installed with the --selfsign option will be converted to
CA-less.  See the section above titled "Dropped --selfsign option".

Please note, that the referential integrity extension requires an extended set
of indexes to be configured. RPM update for an IPA server with a excessive
number of hosts, SUDO or HBAC entries may require several minutes to finish.

If you have multiple servers you may upgrade them one at a time. It is expected
that all servers will be upgraded in a relatively short period (days or weeks
not months). They should be able to co-exist peacefully but new features will
not be available on old servers and enrolling a new client against an old
server will result in the SSH keys not being uploaded.

Downgrading a server once upgraded is not supported.

Upgrading from 2.2.0 and later versions is supported. Upgrading from previous
versions is not supported and has not been tested.

An enrolled client does not need the new packages installed unless you want to
re-enroll it. SSH keys for already installed clients are not uploaded, you will
have to re-enroll the client or manually upload the keys.

== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users mailing
list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel
on Freenode.

== References ==
[1] http://freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs

== Detailed Changelog since 3.2.0 ==
=== Alexander Bokovoy (1): ===
* Fix cldap parser to work with a single equality filter (NtVer=...)

=== Ana Krivokapic (3): ===
* Prompt for nameserver IP address in dnszone-add
* Do not display success message on failure in web UI
* Prevent error when running IPA commands with su/sudo

=== Diane Trout (1): ===
* Fix log format not a string literal.

=== Martin Kosek (4): ===
* Set KRB5CCNAME so that dirsrv can work with newer krb5-server
* Avoid exporting KRB5_KTNAME in dirsrv env
* Remove redundant u'' character
* Become 3.2.1

=== Nathaniel McCallum (6): ===
* Add ipaUserAuthType and ipaUserAuthTypeClass
* Add IPA OTP schema and ACLs
* ipa-kdb: Add OTP support
* Add the krb5/FreeIPA RADIUS companion daemon
* Remove unnecessary prefixes from ipa-pwd-extop files
* Add OTP support to ipa-pwd-extop

=== Petr Spacek (1): ===
* ipa-client-install: Add 'debug' and 'show' statements to nsupdate commands

=== Petr Viktorin (1): ===
* Remove leading zero from IPA_NUM_VERSION

=== Petr Vobornik (7): ===
* Fix: HBAC Test tab is missing
* Move spec modifications from facet factories to pre_ops
* Unite and move facet pre_ops to related modules
* Web UI: move ./_base/metadata_provider.js to ./metadata.js
* Regression fix: missing control buttons in nested search facets
* Make ssbrowser.html work in IE 10
* Fix regression: missing facet tab group labels

=== Simo Sorce (2): ===
* CLDAP: Fix domain handling in netlogon requests
* CLDAP: Return empty reply on non-fatal errors

=== Sumit Bose (1): ===
* Fix format string typo

=== Tomas Babej (9): ===
* Remove redundancy from hbactest help text
* Support multiple local domain ranges with RID base set
* Do not allow removal of ID range of an active trust
* Use private ccache in ipa install tools
* Remove redundant check for env.interactive
* Add prompt_param method to avoid code duplication
* Incorporate interactive prompts in idrange-add
* Do not check userPassword with 7-bit plugin
* Manage ipa-otpd.socket by IPA

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

Re: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types

[Tomas Babej]

On 06/07/2013 03:41 PM, Alexander Bokovoy wrote:

Hi,

in patch 0061:

On Fri, 07 Jun 2013, Tomas Babej wrote:

+range_types = {
+u'ipa-local': unicode(_(u'local domain range')),
+u'ipa-ad-winsync': unicode(_('Active Directory winsync 
range')),

+u'ipa-ad-trust': unicode(_('Active Directory domain range')),
+u'ipa-ad-trust-posix': unicode(_('Active Directory trust 
range with '

+'POSIX attributes')),
+u'ipa-ipa-trust': unicode(_('IPA trust range')),
+  }

Why there is _(u'local domain range') and then others without Unicode
strings? Either way is fine but there should be consistency.


Sure, fixed.


The rest of this patch would be much shorter if there wouldn't
additional whitespace. Could you please git rid of that?


Whitespaces are intentional, these are fixes for PEP8 E302 errors.

Sending the whole patchset updated.

Tomas
From 5502e0817aace0b1aa7ae4bd5cd62a3463164ff5 Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Thu, 30 May 2013 14:12:52 +0200
Subject: [PATCH] Extend idrange commands to support new range origin types

Following values of ipaRangeType attribute are supported
and translated accordingly in the idrange commands:

 'ipa-local': 'local domain range'
 'ipa-ad-winsync': 'Active Directory winsync range'
 'ipa-ad-trust': 'Active Directory domain range'
 'ipa-ad-trust-posix': 'Active Directory trust range with
POSIX attributes'
 'ipa-ipa-trust': 'IPA trust range'

Part of https://fedorahosted.org/freeipa/ticket/3647
---
 API.txt   |  7 ++---
 ipalib/plugins/idrange.py | 75 +--
 2 files changed, 63 insertions(+), 19 deletions(-)

diff --git a/API.txt b/API.txt
index 0a4b356e6f8a66d785e222f5941ff65a3cb484b7..1313460de66d8e12fc7a068cda0cf30658bcdd1b 100644
--- a/API.txt
+++ b/API.txt
@@ -1969,7 +1969,7 @@ option: Int('ipabaserid', attribute=True, cli_name='rid_base', multivalue=False,
 option: Int('ipaidrangesize', attribute=True, cli_name='range_size', multivalue=False, required=True)
 option: Str('ipanttrusteddomainname', attribute=False, cli_name='dom_name', multivalue=False, required=False)
 option: Str('ipanttrusteddomainsid', attribute=True, cli_name='dom_sid', multivalue=False, required=False)
-option: Str('iparangetype', attribute=True, cli_name='iparangetype', multivalue=False, required=False)
+option: StrEnum('iparangetype', attribute=True, cli_name='type', multivalue=False, required=False, values=(u'ipa-ad-trust-posix', u'ipa-ad-trust', u'ipa-local', u'ipa-ad-winsync', u'ipa-ipa-trust'))
 option: Int('ipasecondarybaserid', attribute=True, cli_name='secondary_rid_base', multivalue=False, required=False)
 option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
 option: Str('setattr*', cli_name='setattr', exclude='webui')
@@ -1994,7 +1994,7 @@ option: Int('ipabaseid', attribute=True, autofill=False, cli_name='base_id', mul
 option: Int('ipabaserid', attribute=True, autofill=False, cli_name='rid_base', multivalue=False, query=True, required=False)
 option: Int('ipaidrangesize', attribute=True, autofill=False, cli_name='range_size', multivalue=False, query=True, required=False)
 option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='dom_sid', multivalue=False, query=True, required=False)
-option: Str('iparangetype', attribute=True, autofill=False, cli_name='iparangetype', multivalue=False, query=True, required=False)
+option: StrEnum('iparangetype', attribute=True, autofill=False, cli_name='type', multivalue=False, query=True, required=False, values=(u'ipa-ad-trust-posix', u'ipa-ad-trust', u'ipa-local', u'ipa-ad-winsync', u'ipa-ipa-trust'))
 option: Int('ipasecondarybaserid', attribute=True, autofill=False, cli_name='secondary_rid_base', multivalue=False, query=True, required=False)
 option: Flag('pkey_only?', autofill=True, default=False)
 option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
@@ -2006,7 +2006,7 @@ output: ListOfEntries('result', (, ), Gettext('A list
 output: Output('summary', (, ), None)
 output: Output('truncated', , None)
 command: idrange_mod
-args: 1,14,3
+args: 1,13,3
 arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True)
 option: Str('addattr*', cli_name='addattr', exclude='webui')
 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
@@ -2016,7 +2016,6 @@ option: Int('ipabaserid', attribute=True, autofill=False, cli_name='rid_base', m
 option: Int('ipaidrangesize', attribute=True, autofill=False, cli_name='range_size', multivalue=False, required=False)
 option: DeprecatedParam('ipanttrusteddomainname?')
 option: DeprecatedParam('ipanttrusteddomainsid?')
-option: Str('iparangetype', attribute=True, autofill=False, cli_name='iparangetype', multivalue=False, required=False)
 option: Int('ipasecondarybaserid', attribu

Re: [Freeipa-devel] Configuring FreeIPA with JBoss EAP

[Dmitri Pal]

On 06/07/2013 09:31 AM, Alexander Bokovoy wrote:
> On Fri, 07 Jun 2013, Dmitri Pal wrote:
>> On 06/07/2013 08:58 AM, Martin Kosek wrote:
>>> Hello Jan a Peter, freeipa-devel users,
>>>
>>> There was recently a project of integrating FreeIPA server with
>>> Jboss EAP. One
>>> of the results of this project should be a script able to conveniently
>>> configure JBoss EAP on a machine to use FreeIPA as an
>>> identity&authentication
>>> backend.
>>>
>>> What I would like to find out is what would be the best place to
>>> store&maintain
>>> such script. AFAIK, JBoss EAP did not want to keep the configuration
>>> script
>>> with their project - can you Peter please share the reasons for it?
>>> I was
>>> thinking it would be then easier to maintain the script according to
>>> JBoss EAP
>>> releases.
>>>
>>> Second option would be to deploy the script with FreeIPA project.
>>> Then, they
>>> would also conform to FreeIPA release schedule and not JBoss ones.
>>> So I was
>>> pondering where should we put scripts like this one, it is quite a
>>> specific
>>> script, so I do not want to keeping it with freeipa-client package.
>>>
>>> In this case I would propose creating a new optional subpackage
>>> "freeipa-client-jboss" which would include all scripts/docs for the
>>> JBoss EAP
>>> integration (may extend in future). In future, there may also come more
>>> thematic FreeIPA integration scripts when they cannot be stored in
>>> relevant
>>> upstream projects.
>>>
>>> Any ideas? Is the correct approach to keep configuration scripts for
>>> other
>>> upstream projects?
>>
>> There are two parts of the question:
>> 1) Code aspect
>> 2) RPM/SRPM aspect
>>
>> IMO the code can live in IPA git repo in a separate directory or be a
>> completely separate source code project.
>> We can start with IPA repo and spin it off like we did with the
>> ding-libs if we see a need.
>>
>> As for packaging IMO it should be a separate SRPM (or a part of IPA for
>> now) and produce a separate rpm that should be conditionally installed
>> if IPA client and EAP are installed on the same system. I wonder if rpm
>> can do that? Sounds like a conditional require (if something like this
>> is possible).
> Not possible in rpm.
>
> What we do with trusts is equally applicable here -- a separate
> subpackage that holds all needed requires. In this case it would be
> Requires: to JBoss EAP provides.
>
> Then this separate rpm can be installed alone, pulling JBoss EAP.
> Also Anaconda allows to choose a collection to install. Adding 'FreeIPA
> Identity Management for JBoss EAP' would be relatively easy -- it is
> just a list of packages to pull.
>
Makes sense.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types

[Alexander Bokovoy]

On Fri, 07 Jun 2013, Tomas Babej wrote:

From 85ec5eca8a4dac379902b535b17995c0bfacb428 Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Thu, 30 May 2013 14:02:44 +0200
Subject: [PATCH 61/63] Add ipaRangeType attribute to LDAP Schema

This adds a new LDAP attribute ipaRangeType with
OID 2.16.840.1.113730.3.8.11.41 to the LDAP Schema.

ObjectClass ipaIDrange has been altered to require
ipaRangeType attribute.

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

ACK.

--
/ Alexander Bokovoy

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

Re: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types

[Alexander Bokovoy]

On Fri, 07 Jun 2013, Tomas Babej wrote:

From e3b073011518f37497f08b0b4f4e34881b671a0a Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Thu, 30 May 2013 14:07:09 +0200
Subject: [PATCH 62/63] Add update plugin to fill in ipaRangeType attribute

Previously, we deduced the range type from the range objectclass
and filled in virtual attribute in post_callback phase.

Having a ipaRangeType attributeType in schema, we need to fill
the attribute values to ranges created in previous IPA versions.

The plugin follows the same approach, setting ipa-local or
ipa-ad-trust value to the ipaRangeType attribute according
to the objectclass of the range.

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

ACK.


--
/ Alexander Bokovoy

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

Re: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types

[Alexander Bokovoy]

Hi,

in patch 0061:

On Fri, 07 Jun 2013, Tomas Babej wrote:

+range_types = {
+u'ipa-local': unicode(_(u'local domain range')),
+u'ipa-ad-winsync': unicode(_('Active Directory winsync range')),
+u'ipa-ad-trust': unicode(_('Active Directory domain range')),
+u'ipa-ad-trust-posix': unicode(_('Active Directory trust range with '
+'POSIX attributes')),
+u'ipa-ipa-trust': unicode(_('IPA trust range')),
+  }

Why there is _(u'local domain range') and then others without Unicode
strings? Either way is fine but there should be consistency.

The rest of this patch would be much shorter if there wouldn't
additional whitespace. Could you please git rid of that?

--
/ Alexander Bokovoy

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

[Freeipa-devel] [PATCHES] 134-139 CA-less fixes

[Jan Cholasta]

Hi,

the attached patches fix some of the issues I have found while working 
on test plan for CA-less install (see 
 for more 
information on that).


https://fedorahosted.org/freeipa/ticket/3665
https://fedorahosted.org/freeipa/ticket/3667
https://fedorahosted.org/freeipa/ticket/3673
https://fedorahosted.org/freeipa/ticket/3674
https://fedorahosted.org/freeipa/ticket/3675

Honza

--
Jan Cholasta
>From 75ffce804845cba828e4e95d1bc3540459299ddf Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Wed, 5 Jun 2013 14:47:31 +0200
Subject: [PATCH 1/6] Use the correct PKCS#12 file for HTTP server.

https://fedorahosted.org/freeipa/ticket/3665
---
 install/tools/ipa-server-install | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install
index 992da90..098e639 100755
--- a/install/tools/ipa-server-install
+++ b/install/tools/ipa-server-install
@@ -707,7 +707,7 @@ def main():
 
 if options.http_pkcs12:
 http_pin_file = ipautil.write_tmp_file(options.http_pin)
-http_pkcs12_info = (options.dirsrv_pkcs12, http_pin_file.name)
+http_pkcs12_info = (options.http_pkcs12, http_pin_file.name)
 
 if options.dirsrv_pkcs12:
 dirsrv_pin_file = ipautil.write_tmp_file(options.dirsrv_pin)
-- 
1.8.3

>From 0791d5a1734c47e9505157b49f4628be3bd8c56c Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Wed, 5 Jun 2013 14:47:58 +0200
Subject: [PATCH 2/6] Remove stray error condition in ipa-server-install.

---
 install/tools/ipa-server-install | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install
index 098e639..ccf24e6 100755
--- a/install/tools/ipa-server-install
+++ b/install/tools/ipa-server-install
@@ -286,9 +286,6 @@ def parse_options():
 if options.dirsrv_pkcs12 and not options.root_ca_file:
 parser.error(
 "--root-ca-file must be given with the PKCS#12 options.")
-if options.dirsrv_pkcs12 and not options.root_ca_file:
-parser.error(
-"The PKCS#12 options must be given with --root-ca-file.")
 
 if (options.external_cert_file or options.external_ca_file) and options.dirsrv_pkcs12:
 parser.error(
-- 
1.8.3

>From 71275ffdf6997525cbe07a725ab26a5b3ce779c1 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Mon, 3 Jun 2013 09:14:21 +0200
Subject: [PATCH 3/6] Handle exceptions gracefully when verifying PKCS#12
 files.

https://fedorahosted.org/freeipa/ticket/3667
---
 ipaserver/install/certs.py| 8 +++-
 ipaserver/install/installutils.py | 5 -
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py
index b170c7c..643cbda 100644
--- a/ipaserver/install/certs.py
+++ b/ipaserver/install/certs.py
@@ -29,6 +29,7 @@ import base64
 from hashlib import sha1
 
 from nss import nss
+from nss.error import NSPRError
 
 from ipapython.ipa_log_manager import root_logger
 from ipapython import dogtag
@@ -286,7 +287,12 @@ class NSSDatabase(object):
 certdb = nss.get_default_certdb()
 cert = nss.find_cert_from_nickname(nickname)
 intended_usage = nss.certificateUsageSSLServer
-approved_usage = cert.verify_now(certdb, True, intended_usage)
+try:
+approved_usage = cert.verify_now(certdb, True, intended_usage)
+except NSPRError, e:
+if e.errno != -8102:
+raise ValueError(e.strerror)
+approved_usage = 0
 if not approved_usage & intended_usage:
 raise ValueError('invalid for a SSL server')
 if not cert.verify_hostname(hostname):
diff --git a/ipaserver/install/installutils.py b/ipaserver/install/installutils.py
index bc28dec..9d7aca2 100644
--- a/ipaserver/install/installutils.py
+++ b/ipaserver/install/installutils.py
@@ -721,7 +721,10 @@ def check_pkcs12(pkcs12_info, ca_file, hostname):
 # Import the CA cert first so it has a known nickname
 # (if it's present in the PKCS#12 it won't be overwritten)
 ca_cert_name = 'The Root CA'
-nssdb.import_pem_cert(ca_cert_name, "CT,C,C", ca_file)
+try:
+nssdb.import_pem_cert(ca_cert_name, "CT,C,C", ca_file)
+except ValueError, e:
+raise ScriptError(str(e))
 
 # Import everything in the PKCS#12
 nssdb.import_pkcs12(pkcs12_filename, db_pwd_file.name, pin_filename)
-- 
1.8.3

>From 0e07e00106b895236e63af5c16c324f3c3605d17 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Wed, 5 Jun 2013 14:50:38 +0200
Subject: [PATCH 4/6] Skip empty lines when parsing pk12util output.

---
 ipaserver/install/certs.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py
index 643cbda..06925d5 100644
--- a/ipaserver/install/certs.py
+++ b/ip

Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used

[John Dennis]

On 06/07/2013 09:26 AM, Jan Cholasta wrote:

On 7.6.2013 15:17, John Dennis wrote:

On 06/07/2013 08:57 AM, Jan Cholasta wrote:

Yes, this is correct. The DS certificate must be directly signed by the
CA trusted by IPA (specified by --root-ca-cert in ipa-server-install),
there may be no intermediate CAs, because ldapsearch and friends and
python-ldap don't like them.


That doesn't sound right. Do we understand why a chain length > 1 is
failing?



LDAP utilities and python-ldap only trust certificates directly issued
by CAs you point them to (at least on Fedora 18).


This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto provider). 
Have we filed a bug? Let's file the bug here in the Red Hat bugzilla, 
not upstream, we're the maintainers of MozLDAP and upstream is already 
frustrated with it.


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

Re: [Freeipa-devel] Configuring FreeIPA with JBoss EAP

[Alexander Bokovoy]

On Fri, 07 Jun 2013, Dmitri Pal wrote:

On 06/07/2013 08:58 AM, Martin Kosek wrote:

Hello Jan a Peter, freeipa-devel users,

There was recently a project of integrating FreeIPA server with Jboss EAP. One
of the results of this project should be a script able to conveniently
configure JBoss EAP on a machine to use FreeIPA as an identity&authentication
backend.

What I would like to find out is what would be the best place to store&maintain
such script. AFAIK, JBoss EAP did not want to keep the configuration script
with their project - can you Peter please share the reasons for it? I was
thinking it would be then easier to maintain the script according to JBoss EAP
releases.

Second option would be to deploy the script with FreeIPA project. Then, they
would also conform to FreeIPA release schedule and not JBoss ones. So I was
pondering where should we put scripts like this one, it is quite a specific
script, so I do not want to keeping it with freeipa-client package.

In this case I would propose creating a new optional subpackage
"freeipa-client-jboss" which would include all scripts/docs for the JBoss EAP
integration (may extend in future). In future, there may also come more
thematic FreeIPA integration scripts when they cannot be stored in relevant
upstream projects.

Any ideas? Is the correct approach to keep configuration scripts for other
upstream projects?


There are two parts of the question:
1) Code aspect
2) RPM/SRPM aspect

IMO the code can live in IPA git repo in a separate directory or be a
completely separate source code project.
We can start with IPA repo and spin it off like we did with the
ding-libs if we see a need.

As for packaging IMO it should be a separate SRPM (or a part of IPA for
now) and produce a separate rpm that should be conditionally installed
if IPA client and EAP are installed on the same system. I wonder if rpm
can do that? Sounds like a conditional require (if something like this
is possible).

Not possible in rpm.

What we do with trusts is equally applicable here -- a separate
subpackage that holds all needed requires. In this case it would be
Requires: to JBoss EAP provides.

Then this separate rpm can be installed alone, pulling JBoss EAP.
Also Anaconda allows to choose a collection to install. Adding 'FreeIPA
Identity Management for JBoss EAP' would be relatively easy -- it is
just a list of packages to pull.

--
/ Alexander Bokovoy

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

Re: [Freeipa-devel] Configuring FreeIPA with JBoss EAP

[Martin Kosek]

On 06/07/2013 03:21 PM, Dmitri Pal wrote:
> On 06/07/2013 08:58 AM, Martin Kosek wrote:
>> Hello Jan a Peter, freeipa-devel users,
>>
>> There was recently a project of integrating FreeIPA server with Jboss EAP. 
>> One
>> of the results of this project should be a script able to conveniently
>> configure JBoss EAP on a machine to use FreeIPA as an identity&authentication
>> backend.
>>
>> What I would like to find out is what would be the best place to 
>> store&maintain
>> such script. AFAIK, JBoss EAP did not want to keep the configuration script
>> with their project - can you Peter please share the reasons for it? I was
>> thinking it would be then easier to maintain the script according to JBoss 
>> EAP
>> releases.
>>
>> Second option would be to deploy the script with FreeIPA project. Then, they
>> would also conform to FreeIPA release schedule and not JBoss ones. So I was
>> pondering where should we put scripts like this one, it is quite a specific
>> script, so I do not want to keeping it with freeipa-client package.
>>
>> In this case I would propose creating a new optional subpackage
>> "freeipa-client-jboss" which would include all scripts/docs for the JBoss EAP
>> integration (may extend in future). In future, there may also come more
>> thematic FreeIPA integration scripts when they cannot be stored in relevant
>> upstream projects.
>>
>> Any ideas? Is the correct approach to keep configuration scripts for other
>> upstream projects?
> 
> There are two parts of the question:
> 1) Code aspect
> 2) RPM/SRPM aspect
> 
> IMO the code can live in IPA git repo in a separate directory or be a
> completely separate source code project.
> We can start with IPA repo and spin it off like we did with the
> ding-libs if we see a need.

Yes, we can start small and see how it goes further.

> 
> As for packaging IMO it should be a separate SRPM (or a part of IPA for
> now) and produce a separate rpm that should be conditionally installed
> if IPA client and EAP are installed on the same system. I wonder if rpm
> can do that? Sounds like a conditional require (if something like this
> is possible).
> 
> 2c.

What is the advantage of separate SRPM?

I planned to produce a separate rpm, i.e.
freeipa-client-jboss--.rpm which would require freeipa-client
package (or in JBoss's case maybe also on freeipa-server package).

I am not sure if we can make it require also JBoss EAP - AFAIK, they ship the
project only via ZIP files, so no rpm tricks :-(

Martin

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

Re: [Freeipa-devel] [PATCHES 0061-0063] Extend ID range types

[Tomas Babej]

On 06/06/2013 12:00 PM, Alexander Bokovoy wrote:

On Thu, 06 Jun 2013, Tomas Babej wrote:

From 0580d3c03319c72d731d0598b19e633fc536b866 Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Thu, 30 May 2013 14:07:09 +0200
Subject: [PATCH 62/63] Add update plugin to fill in ipaRangeType 
attribute


Previously, we deduced the range type from the range objectclass
and filled in virtual attribute in post_callback phase.

Having a ipaRangeType attributeType in schema, we need to fill
the attribute values to ranges created in previous IPA versions.

The plugin follows the same approach, setting ipa-local or
ipa-ad-trust value to the ipaRangeType attribute according
to the objectclass of the range.

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

You need also to fix bootstrap template as ipaRangeType now is mandatory
attribute for the range class:



Updated patches attached.

Tomas

From 6448e7b58ffbfaa92bcb2d9412e28934afb825b8 Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Thu, 30 May 2013 14:12:52 +0200
Subject: [PATCH] Extend idrange commands to support new range origin types

Following values of ipaRangeType attribute are supported
and translated accordingly in the idrange commands:

 'ipa-local': 'local domain range'
 'ipa-ad-winsync': 'Active Directory winsync range'
 'ipa-ad-trust': 'Active Directory domain range'
 'ipa-ad-trust-posix': 'Active Directory trust range with
POSIX attributes'
 'ipa-ipa-trust': 'IPA trust range'

Part of https://fedorahosted.org/freeipa/ticket/3647
---
 API.txt   |  7 ++---
 ipalib/plugins/idrange.py | 75 +--
 2 files changed, 63 insertions(+), 19 deletions(-)

diff --git a/API.txt b/API.txt
index 0a4b356e6f8a66d785e222f5941ff65a3cb484b7..1313460de66d8e12fc7a068cda0cf30658bcdd1b 100644
--- a/API.txt
+++ b/API.txt
@@ -1969,7 +1969,7 @@ option: Int('ipabaserid', attribute=True, cli_name='rid_base', multivalue=False,
 option: Int('ipaidrangesize', attribute=True, cli_name='range_size', multivalue=False, required=True)
 option: Str('ipanttrusteddomainname', attribute=False, cli_name='dom_name', multivalue=False, required=False)
 option: Str('ipanttrusteddomainsid', attribute=True, cli_name='dom_sid', multivalue=False, required=False)
-option: Str('iparangetype', attribute=True, cli_name='iparangetype', multivalue=False, required=False)
+option: StrEnum('iparangetype', attribute=True, cli_name='type', multivalue=False, required=False, values=(u'ipa-ad-trust-posix', u'ipa-ad-trust', u'ipa-local', u'ipa-ad-winsync', u'ipa-ipa-trust'))
 option: Int('ipasecondarybaserid', attribute=True, cli_name='secondary_rid_base', multivalue=False, required=False)
 option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
 option: Str('setattr*', cli_name='setattr', exclude='webui')
@@ -1994,7 +1994,7 @@ option: Int('ipabaseid', attribute=True, autofill=False, cli_name='base_id', mul
 option: Int('ipabaserid', attribute=True, autofill=False, cli_name='rid_base', multivalue=False, query=True, required=False)
 option: Int('ipaidrangesize', attribute=True, autofill=False, cli_name='range_size', multivalue=False, query=True, required=False)
 option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='dom_sid', multivalue=False, query=True, required=False)
-option: Str('iparangetype', attribute=True, autofill=False, cli_name='iparangetype', multivalue=False, query=True, required=False)
+option: StrEnum('iparangetype', attribute=True, autofill=False, cli_name='type', multivalue=False, query=True, required=False, values=(u'ipa-ad-trust-posix', u'ipa-ad-trust', u'ipa-local', u'ipa-ad-winsync', u'ipa-ipa-trust'))
 option: Int('ipasecondarybaserid', attribute=True, autofill=False, cli_name='secondary_rid_base', multivalue=False, query=True, required=False)
 option: Flag('pkey_only?', autofill=True, default=False)
 option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
@@ -2006,7 +2006,7 @@ output: ListOfEntries('result', (, ), Gettext('A list
 output: Output('summary', (, ), None)
 output: Output('truncated', , None)
 command: idrange_mod
-args: 1,14,3
+args: 1,13,3
 arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True)
 option: Str('addattr*', cli_name='addattr', exclude='webui')
 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
@@ -2016,7 +2016,6 @@ option: Int('ipabaserid', attribute=True, autofill=False, cli_name='rid_base', m
 option: Int('ipaidrangesize', attribute=True, autofill=False, cli_name='range_size', multivalue=False, required=False)
 option: DeprecatedParam('ipanttrusteddomainname?')
 option: DeprecatedParam('ipanttrusteddomainsid?')
-option: Str('iparangetype', attribute=True, autofill=False, cli_name='iparangetype', multivalue=False, required=False)
 option: Int('ipasecondarybaserid', attribute=True, autofill=False, cli_name='secondary_rid

Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used

[Jan Cholasta]

On 7.6.2013 15:17, John Dennis wrote:

On 06/07/2013 08:57 AM, Jan Cholasta wrote:

Yes, this is correct. The DS certificate must be directly signed by the
CA trusted by IPA (specified by --root-ca-cert in ipa-server-install),
there may be no intermediate CAs, because ldapsearch and friends and
python-ldap don't like them.


That doesn't sound right. Do we understand why a chain length > 1 is
failing?



LDAP utilities and python-ldap only trust certificates directly issued 
by CAs you point them to (at least on Fedora 18).


Honza

--
Jan Cholasta

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

Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used

[Dmitri Pal]

On 06/07/2013 09:08 AM, Jan Cholasta wrote:
> On 7.6.2013 14:54, Dmitri Pal wrote:
>> On 06/07/2013 08:26 AM, Martin Kosek wrote:
>>> On 06/07/2013 02:04 PM, Dmitri Pal wrote:
 On 06/07/2013 03:47 AM, freeipa wrote:
> #3668: CA-less install fails when intermediate CA is used
> -+-
>
> Reporter:  jcholast   | Owner:  jcholast
> Type:  defect |Status:  assigned
> Priority:  major  | Milestone:  2013
> Month 06 -
>Component: |  June (3.2.x bug fixing)
>Installation   |   Version:
>   Resolution: |  Keywords:
>   Blocked By: |  Blocking:
>Tests Updated:  0  |   Affects DOC:  0
> Patch posted for review:  0  |  Red Hat Bugzilla:
>   Source: |   Effort Type:
> Targeted feature: |   Design link:
>Design review:  0  |  Fedora test page:
>   Chosen: |   Needs UI design:
> -+-
>
> Release Notes:
>
>
> -+-
>
> Changes (by mkosek):
>
>   * rhbz:  0 =>
>
>
> Comment:
>
>   We not support intermediate CAs for external CA install or CA-less
>   install. Thus, this ticket cannot be easily solved extensive
> changes to
>   the installer. Related to #3274 (Pilsner milestone).
>
>   Moving back to triage to decide what to do about this ticket.
>
 So you are saying that CA we chain to or get the certs from should
 always be a root CA?
 Why does it matter for our code whether the CA we deal with a Root
 CA or
 not?
>>> No, this is a case when a CA you pass for FreeIPA is not a direct
>>> "parent" of
>>> HTTP/DIRSRV certificates, i.e. there is an intermediate CA between
>>> the CA
>>> passed to IPA and the actual certs.
>>
>> My question is what prevents you to give IPA the certs from the direct
>> parent. What is the use case or real world scenario where the parent
>> certs are not available?
>> Just trying to wrap my head.
>>
>> I have CA 1 and CA 2. CA 2 is a sub CA of 1.
>> I have certs from CA 1
>> If I pass them to IPA but point to CA2 it would not work. OK
>> The example can be that CA1 is a public CA and CA2 is my CA. But what
>> prevents me from giving IPA the certs from CA2? Why would I try to give
>> IPA certs from CA1?
>>
>> Do I understand the scenario correctly?
>>
>
> Nothing is preventing you to give IPA certs from CA2, this works fine.
>
> The problem is that if you pass IPA certificates issued by CA2 and
> point it to CA1 at the same time, it does not work (despite having the
> complete trust chain).
>
> Honza
>

But why would you do so? What would be the reason and business case? Why
not to point to CA2?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-devel] Configuring FreeIPA with JBoss EAP

[Dmitri Pal]

On 06/07/2013 08:58 AM, Martin Kosek wrote:
> Hello Jan a Peter, freeipa-devel users,
>
> There was recently a project of integrating FreeIPA server with Jboss EAP. One
> of the results of this project should be a script able to conveniently
> configure JBoss EAP on a machine to use FreeIPA as an identity&authentication
> backend.
>
> What I would like to find out is what would be the best place to 
> store&maintain
> such script. AFAIK, JBoss EAP did not want to keep the configuration script
> with their project - can you Peter please share the reasons for it? I was
> thinking it would be then easier to maintain the script according to JBoss EAP
> releases.
>
> Second option would be to deploy the script with FreeIPA project. Then, they
> would also conform to FreeIPA release schedule and not JBoss ones. So I was
> pondering where should we put scripts like this one, it is quite a specific
> script, so I do not want to keeping it with freeipa-client package.
>
> In this case I would propose creating a new optional subpackage
> "freeipa-client-jboss" which would include all scripts/docs for the JBoss EAP
> integration (may extend in future). In future, there may also come more
> thematic FreeIPA integration scripts when they cannot be stored in relevant
> upstream projects.
>
> Any ideas? Is the correct approach to keep configuration scripts for other
> upstream projects?

There are two parts of the question:
1) Code aspect
2) RPM/SRPM aspect

IMO the code can live in IPA git repo in a separate directory or be a
completely separate source code project.
We can start with IPA repo and spin it off like we did with the
ding-libs if we see a need.

As for packaging IMO it should be a separate SRPM (or a part of IPA for
now) and produce a separate rpm that should be conditionally installed
if IPA client and EAP are installed on the same system. I wonder if rpm
can do that? Sounds like a conditional require (if something like this
is possible).

2c.


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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used

[John Dennis]

On 06/07/2013 08:57 AM, Jan Cholasta wrote:

Yes, this is correct. The DS certificate must be directly signed by the
CA trusted by IPA (specified by --root-ca-cert in ipa-server-install),
there may be no intermediate CAs, because ldapsearch and friends and
python-ldap don't like them.


That doesn't sound right. Do we understand why a chain length > 1 is 
failing?


John


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

Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used

[Jan Cholasta]

On 7.6.2013 14:54, Dmitri Pal wrote:

On 06/07/2013 08:26 AM, Martin Kosek wrote:

On 06/07/2013 02:04 PM, Dmitri Pal wrote:

On 06/07/2013 03:47 AM, freeipa wrote:

#3668: CA-less install fails when intermediate CA is used
-+-
Reporter:  jcholast   | Owner:  jcholast
Type:  defect |Status:  assigned
Priority:  major  | Milestone:  2013 Month 06 -
   Component: |  June (3.2.x bug fixing)
   Installation   |   Version:
  Resolution: |  Keywords:
  Blocked By: |  Blocking:
   Tests Updated:  0  |   Affects DOC:  0
Patch posted for review:  0  |  Red Hat Bugzilla:
  Source: |   Effort Type:
Targeted feature: |   Design link:
   Design review:  0  |  Fedora test page:
  Chosen: |   Needs UI design:
-+-
Release Notes:


-+-
Changes (by mkosek):

  * rhbz:  0 =>


Comment:

  We not support intermediate CAs for external CA install or CA-less
  install. Thus, this ticket cannot be easily solved extensive changes to
  the installer. Related to #3274 (Pilsner milestone).

  Moving back to triage to decide what to do about this ticket.


So you are saying that CA we chain to or get the certs from should
always be a root CA?
Why does it matter for our code whether the CA we deal with a Root CA or
not?

No, this is a case when a CA you pass for FreeIPA is not a direct "parent" of
HTTP/DIRSRV certificates, i.e. there is an intermediate CA between the CA
passed to IPA and the actual certs.


My question is what prevents you to give IPA the certs from the direct
parent. What is the use case or real world scenario where the parent
certs are not available?
Just trying to wrap my head.

I have CA 1 and CA 2. CA 2 is a sub CA of 1.
I have certs from CA 1
If I pass them to IPA but point to CA2 it would not work. OK
The example can be that CA1 is a public CA and CA2 is my CA. But what
prevents me from giving IPA the certs from CA2? Why would I try to give
IPA certs from CA1?

Do I understand the scenario correctly?



Nothing is preventing you to give IPA certs from CA2, this works fine.

The problem is that if you pass IPA certificates issued by CA2 and point 
it to CA1 at the same time, it does not work (despite having the 
complete trust chain).


Honza

--
Jan Cholasta

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

[Freeipa-devel] Configuring FreeIPA with JBoss EAP

[Martin Kosek]

Hello Jan a Peter, freeipa-devel users,

There was recently a project of integrating FreeIPA server with Jboss EAP. One
of the results of this project should be a script able to conveniently
configure JBoss EAP on a machine to use FreeIPA as an identity&authentication
backend.

What I would like to find out is what would be the best place to store&maintain
such script. AFAIK, JBoss EAP did not want to keep the configuration script
with their project - can you Peter please share the reasons for it? I was
thinking it would be then easier to maintain the script according to JBoss EAP
releases.

Second option would be to deploy the script with FreeIPA project. Then, they
would also conform to FreeIPA release schedule and not JBoss ones. So I was
pondering where should we put scripts like this one, it is quite a specific
script, so I do not want to keeping it with freeipa-client package.

In this case I would propose creating a new optional subpackage
"freeipa-client-jboss" which would include all scripts/docs for the JBoss EAP
integration (may extend in future). In future, there may also come more
thematic FreeIPA integration scripts when they cannot be stored in relevant
upstream projects.

Any ideas? Is the correct approach to keep configuration scripts for other
upstream projects?

Thanks,
Martin

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

Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used

[Jan Cholasta]

On 7.6.2013 14:26, Martin Kosek wrote:

On 06/07/2013 02:04 PM, Dmitri Pal wrote:

On 06/07/2013 03:47 AM, freeipa wrote:

#3668: CA-less install fails when intermediate CA is used
-+-
Reporter:  jcholast   | Owner:  jcholast
Type:  defect |Status:  assigned
Priority:  major  | Milestone:  2013 Month 06 -
   Component: |  June (3.2.x bug fixing)
   Installation   |   Version:
  Resolution: |  Keywords:
  Blocked By: |  Blocking:
   Tests Updated:  0  |   Affects DOC:  0
Patch posted for review:  0  |  Red Hat Bugzilla:
  Source: |   Effort Type:
Targeted feature: |   Design link:
   Design review:  0  |  Fedora test page:
  Chosen: |   Needs UI design:
-+-
Release Notes:


-+-
Changes (by mkosek):

  * rhbz:  0 =>


Comment:

  We not support intermediate CAs for external CA install or CA-less
  install. Thus, this ticket cannot be easily solved extensive changes to
  the installer. Related to #3274 (Pilsner milestone).

  Moving back to triage to decide what to do about this ticket.


So you are saying that CA we chain to or get the certs from should
always be a root CA?
Why does it matter for our code whether the CA we deal with a Root CA or
not?


No, this is a case when a CA you pass for FreeIPA is not a direct "parent" of
HTTP/DIRSRV certificates, i.e. there is an intermediate CA between the CA
passed to IPA and the actual certs.

It should not mean that the root CA you pass to IPA must be necessarily a root
CA of the entire chain. Jan, is this correct? Can you elaborate?


Yes, this is correct. The DS certificate must be directly signed by the 
CA trusted by IPA (specified by --root-ca-cert in ipa-server-install), 
there may be no intermediate CAs, because ldapsearch and friends and 
python-ldap don't like them.


Honza

--
Jan Cholasta

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

Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used

[Dmitri Pal]

On 06/07/2013 08:26 AM, Martin Kosek wrote:
> On 06/07/2013 02:04 PM, Dmitri Pal wrote:
>> On 06/07/2013 03:47 AM, freeipa wrote:
>>> #3668: CA-less install fails when intermediate CA is used
>>> -+-
>>>Reporter:  jcholast   | Owner:  jcholast
>>>Type:  defect |Status:  assigned
>>>Priority:  major  | Milestone:  2013 Month 06 -
>>>   Component: |  June (3.2.x bug fixing)
>>>   Installation   |   Version:
>>>  Resolution: |  Keywords:
>>>  Blocked By: |  Blocking:
>>>   Tests Updated:  0  |   Affects DOC:  0
>>> Patch posted for review:  0  |  Red Hat Bugzilla:
>>>  Source: |   Effort Type:
>>>Targeted feature: |   Design link:
>>>   Design review:  0  |  Fedora test page:
>>>  Chosen: |   Needs UI design:
>>> -+-
>>> Release Notes:
>>>
>>>
>>> -+-
>>> Changes (by mkosek):
>>>
>>>  * rhbz:  0 =>
>>>
>>>
>>> Comment:
>>>
>>>  We not support intermediate CAs for external CA install or CA-less
>>>  install. Thus, this ticket cannot be easily solved extensive changes to
>>>  the installer. Related to #3274 (Pilsner milestone).
>>>
>>>  Moving back to triage to decide what to do about this ticket.
>>>
>> So you are saying that CA we chain to or get the certs from should
>> always be a root CA?
>> Why does it matter for our code whether the CA we deal with a Root CA or
>> not?
> No, this is a case when a CA you pass for FreeIPA is not a direct "parent" of
> HTTP/DIRSRV certificates, i.e. there is an intermediate CA between the CA
> passed to IPA and the actual certs.

My question is what prevents you to give IPA the certs from the direct
parent. What is the use case or real world scenario where the parent
certs are not available?
Just trying to wrap my head.

I have CA 1 and CA 2. CA 2 is a sub CA of 1.
I have certs from CA 1
If I pass them to IPA but point to CA2 it would not work. OK
The example can be that CA1 is a public CA and CA2 is my CA. But what
prevents me from giving IPA the certs from CA2? Why would I try to give
IPA certs from CA1?

Do I understand the scenario correctly?




>
> It should not mean that the root CA you pass to IPA must be necessarily a root
> CA of the entire chain. Jan, is this correct? Can you elaborate?
>
>> If we are trying to say that we do not follow the chains of trust I can
>> understand that. So the limitation is that we should always be given the
>> certs from the same CA we chain to and not its sub CA's, right? That
>> makes sense.
>>
>> Can someone describe a use case where in real life the certs would come
>> from one CA in the chain but we would be told to chain or use a sub CA
>> of that CA. That seems strange. What am I missing?


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used

[Martin Kosek]

On 06/07/2013 02:04 PM, Dmitri Pal wrote:
> On 06/07/2013 03:47 AM, freeipa wrote:
>> #3668: CA-less install fails when intermediate CA is used
>> -+-
>>Reporter:  jcholast   | Owner:  jcholast
>>Type:  defect |Status:  assigned
>>Priority:  major  | Milestone:  2013 Month 06 -
>>   Component: |  June (3.2.x bug fixing)
>>   Installation   |   Version:
>>  Resolution: |  Keywords:
>>  Blocked By: |  Blocking:
>>   Tests Updated:  0  |   Affects DOC:  0
>> Patch posted for review:  0  |  Red Hat Bugzilla:
>>  Source: |   Effort Type:
>>Targeted feature: |   Design link:
>>   Design review:  0  |  Fedora test page:
>>  Chosen: |   Needs UI design:
>> -+-
>> Release Notes:
>>
>>
>> -+-
>> Changes (by mkosek):
>>
>>  * rhbz:  0 =>
>>
>>
>> Comment:
>>
>>  We not support intermediate CAs for external CA install or CA-less
>>  install. Thus, this ticket cannot be easily solved extensive changes to
>>  the installer. Related to #3274 (Pilsner milestone).
>>
>>  Moving back to triage to decide what to do about this ticket.
>>
> So you are saying that CA we chain to or get the certs from should
> always be a root CA?
> Why does it matter for our code whether the CA we deal with a Root CA or
> not?

No, this is a case when a CA you pass for FreeIPA is not a direct "parent" of
HTTP/DIRSRV certificates, i.e. there is an intermediate CA between the CA
passed to IPA and the actual certs.

It should not mean that the root CA you pass to IPA must be necessarily a root
CA of the entire chain. Jan, is this correct? Can you elaborate?

> If we are trying to say that we do not follow the chains of trust I can
> understand that. So the limitation is that we should always be given the
> certs from the same CA we chain to and not its sub CA's, right? That
> makes sense.
> 
> Can someone describe a use case where in real life the certs would come
> from one CA in the chain but we would be told to chain or use a sub CA
> of that CA. That seems strange. What am I missing?

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

Re: [Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used

[Dmitri Pal]

On 06/07/2013 03:47 AM, freeipa wrote:
> #3668: CA-less install fails when intermediate CA is used
> -+-
>Reporter:  jcholast   | Owner:  jcholast
>Type:  defect |Status:  assigned
>Priority:  major  | Milestone:  2013 Month 06 -
>   Component: |  June (3.2.x bug fixing)
>   Installation   |   Version:
>  Resolution: |  Keywords:
>  Blocked By: |  Blocking:
>   Tests Updated:  0  |   Affects DOC:  0
> Patch posted for review:  0  |  Red Hat Bugzilla:
>  Source: |   Effort Type:
>Targeted feature: |   Design link:
>   Design review:  0  |  Fedora test page:
>  Chosen: |   Needs UI design:
> -+-
> Release Notes:
>
>
> -+-
> Changes (by mkosek):
>
>  * rhbz:  0 =>
>
>
> Comment:
>
>  We not support intermediate CAs for external CA install or CA-less
>  install. Thus, this ticket cannot be easily solved extensive changes to
>  the installer. Related to #3274 (Pilsner milestone).
>
>  Moving back to triage to decide what to do about this ticket.
>
So you are saying that CA we chain to or get the certs from should
always be a root CA?
Why does it matter for our code whether the CA we deal with a Root CA or
not?

If we are trying to say that we do not follow the chains of trust I can
understand that. So the limitation is that we should always be given the
certs from the same CA we chain to and not its sub CA's, right? That
makes sense.

Can someone describe a use case where in real life the certs would come
from one CA in the chain but we would be told to chain or use a sub CA
of that CA. That seems strange. What am I missing?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-devel] [PATCH] 0035 Prevent error when running IPA commands with su/sudo

[Martin Kosek]

On 06/06/2013 01:31 PM, Tomas Babej wrote:
> On 06/06/2013 12:58 PM, Ana Krivokapic wrote:
>> Hello,
>>
>> This patch fixes https://fedorahosted.org/freeipa/ticket/3685.
>>
>>
>>
>> ___
>> Freeipa-devel mailing list
>> Freeipa-devel@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
> 
> ACK
> 
> Tomas
> 

Pushed to master, ipa-3-2.

Martin

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

Re: [Freeipa-devel] [PATCH] 0033 Fail when adding a trust with a different range

[Tomas Babej]

On 05/31/2013 12:08 PM, Ana Krivokapic wrote:

Hello,

This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3635.



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


Hi, the patch itself works as it should, I have only some refactoring 
comments:


1.) There already is a add_range method that is called from within 
trust_add's execute()
and handles some range validation (currently only whether domain's SID 
of new and

existing range are equal, my patch 67 add some more).

Your patch introduces a new method validate_range() that is called from 
execute(),
which leads to some duplication of the logic, mainly two same calls to 
the API (getting

the info about the old range via idrange_show)

I'd rather we keep all the validation in one place, preferably inside 
the add_range method
or refactored out of it in the new method that is called only from 
add_range().


2.) That being said, other parts of refactoring are nice and make code 
more clear, +1.


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

Re: [Freeipa-devel] [PATCH] 0029 Make sure replication works after DM password is changed

[Tomas Babej]

On 05/15/2013 01:36 PM, Ana Krivokapic wrote:

On 05/15/2013 12:29 PM, Petr Viktorin wrote:

On 05/15/2013 12:04 PM, Tomas Babej wrote:

On 05/15/2013 11:40 AM, Ana Krivokapic wrote:

Hello,

See the commit message for details.

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



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

+def regenerate_ca_file(self, ca_file):
+dm_pwd_fd, dm_pwd_fname = tempfile.mkstemp()
+keydb_pwd_fd, keydb_pwd_fname = tempfile.mkstemp()
+
+os.write(dm_pwd_fd, self.dirman_password)
+os.close(dm_pwd_fd)
+
+keydb_pwd = ''
+with open('/etc/pki/pki-tomcat/password.conf') as f:
+for line in f.readlines():
+key, value = line.strip().split('=')
+if key == 'internal':
+keydb_pwd = value
+break
+
+os.write(keydb_pwd_fd, keydb_pwd)
+os.close(keydb_pwd_fd)
+
+ipautil.run([
+'/usr/bin/PKCS12Export',
+'-d', '/etc/pki/pki-tomcat/alias/',
+'-p', keydb_pwd_fname,
+'-w', dm_pwd_fname,
+'-o', ca_file
+])
+

If the PKCS12Export call fails (returns non-zero code), we raise
exception here, and the temporary files are never removed.

+os.remove(dm_pwd_fname)
+os.remove(keydb_pwd_fname)

This might not be a big issue since mkstemp() call creates temporary
file readable and writable only be given user ID,
however, we should not leave files with passwords in plaintext on the
disk if it is not necessary.

This can be easily prevented by wrapping the call up with
try-chatch-finally block, or using raiseonerr=False options of run
method.

Or by using ipautil.write_tmp_file() -- the file it creates is always
removed after it's closed/garbage collected, and it has a name attribute.


Updated patch uses `ipautil.write_tmp_file()`.



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

I'm testing on a fairly updated F19 VM:

I'm getting the following error when preparing the replica info file:

[root@vm-002 ~]# ipa-replica-prepare vm-003.ipa.com --ip-address 
192.168.122.213

Directory Manager (existing master) password:

Preparing replica for vm-003.ipa.com from vm-002.ipa.com
Command '/usr/bin/PKCS12Export -d /etc/pki/pki-tomcat/alias/ -p 
/tmp/tmp15Je9R -w /tmp/tmpCGD5Sr -o /root/cacert.p12' returned non


When trying that manually:

[root@vm-002 ~]# /usr/bin/PKCS12Export -d /etc/pki/pki-tomcat/alias/ -p 
/tmp/tmp15Je9R -w /tmp/tmpCGD5Sr -o /root/cacert.p12
Exception in thread "main" java.lang.NoClassDefFoundError: 
org/mozilla/jss/util/PasswordCallback

at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
at java.lang.Class.getMethod0(Class.java:2694)
at java.lang.Class.getMethod(Class.java:1622)
at sun.launcher.LauncherHelper.getMainMethod(LauncherHelper.java:494)
at 
sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:486)
Caused by: java.lang.ClassNotFoundException: 
org.mozilla.jss.util.PasswordCallback

at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
... 6 more

We might need to investigate what causes this, and if the issue is not 
on our side, file appropriate bugs.


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