Re: [Freeipa-devel] Meaning of Needs UI design field in Trac?

2014-11-24 Thread Martin Kosek
On 11/24/2014 08:39 AM, Fraser Tweedale wrote:
 Hi all,
 
 The precise meaning and usage of the Needs UI design field in Trac
 is not clear to me.  It has five values:
 
 - blank
 - Not needed
 - Review
 - Consult
 - Design
 
 What is the purpose of this field and the meanings of the different
 values?  And a more general question: is there a resource anywhere
 that explains the various fields in the FreeIPA Trac?

Hi Fraser,

The addition Trac ticket metadata are usually added quite organically, as they
are needed. I am not aware of a page that would describe them. If the field is
not clear just from the description, it means it is possibly badly designed :-)

Needs UI design in particular was used to select tickets that needs, well, UI
review from UX specialist.

But given it is not used on a frequent basis
(https://fedorahosted.org/freeipa/query?uxd=!uxd=!Not+neededstatus=assignedstatus=newstatus=reopenedorder=prioritycol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=component)
I would personally just remove it and use keyword for this one time usage (like
ux-required) to make tickets smaller.

HTH,
Martin

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


Re: [Freeipa-devel] [PATCHES] 0656-0673 Switch the test suite to pytest

2014-11-24 Thread Petr Viktorin

On 11/21/2014 10:13 PM, Rob Crittenden wrote:

Tomas Babej wrote:


On 11/20/2014 10:12 AM, Petr Viktorin wrote:

On 11/19/2014 01:11 PM, Tomas Babej wrote:


On 11/14/2014 09:55 AM, Petr Viktorin wrote:

On 10/29/2014 04:52 PM, Petr Viktorin wrote:

On 10/29/2014 01:22 PM, Tomas Babej wrote:


On 10/27/2014 04:38 PM, Petr Viktorin wrote:

On 10/15/2014 02:58 PM, Petr Viktorin wrote:

This almost completes the switch to pytest. There are two missing
things:
- the details of test results (--with-xunit) are not read
correctly by
Jenkins. I have a theory I'm investigating here.
- the beakerlib integration is still not ready


I'll not be available for the rest of the week so I'm sending this
early, in case someone wants to take a look.


I've updated (and rearranged) the patches after some more testing.
Both points above are fixed. Individual plugins are broken out; some
would be nice to even release independently of IPA. (There is some
demand for the BeakerLib plugin; for that I'd only need to break the
dependency on ipa_log_manager.)


These depend on my patches 0656-0660.




Thanks for this effort!

 Patch 0656: tests: Use PEP8-compliant setup/teardown method
names

There are some references to the old names in the test_ipapython and
test_install:

   [tbabej@thinkpad7 ipatests]$ git grep setUpClass
   [tbabej@thinkpad7 ipatests]$ git grep tearDownClass
   [tbabej@thinkpad7 ipatests]$ git grep setUp
   test_install/test_updates.py:def setUp(self):
   test_ipapython/test_cookie.py:def setUp(self):
   test_ipapython/test_cookie.py:def setUp(self):
   test_ipapython/test_cookie.py:def setUp(self):
   test_ipapython/test_dn.py:def setUp(self):
   test_ipapython/test_dn.py:def setUp(self):
   test_ipapython/test_dn.py:def setUp(self):
   test_ipapython/test_dn.py:def setUp(self):
   test_ipapython/test_dn.py:def setUp(self):
   [tbabej@thinkpad7 ipatests]$ git grep tearDown
   test_install/test_updates.py:def tearDown(self):


These are in unittest.testCase. It would be nice to convert those as
well, but that's for a larger cleanup.


 Patch 0657: tests: Add configuration for pytest

Shouldn't we rather change the class names?


Ideally yes, but I don't think renaming most of our test classes would
be worth the benefit.


 Patch 0658: ipatests.util.ClassChecker: Raise AttributeError in
get_subcls

ACK.

 Patch 0659: test_automount_plugin: Fix test ordering

ACK.

 PATCH 0660: Use setup_class/teardown_class in Declarative tests

   --- a/ipatests/test_ipaserver/test_changepw.py
   +++ b/ipatests/test_ipaserver/test_changepw.py
   @@ -33,8 +33,7 @@
class test_changepw(XMLRPC_test, Unauthorized_HTTP_test):
app_uri = '/ipa/session/change_password'

   -def setup(self):
   -super(test_changepw, self).setup()
   +def setup(cls):
try:
api.Command['user_add'](uid=testuser,
givenname=u'Test', sn=u'User')
api.Command['passwd'](testuser,
password=u'old_password')
   @@ -43,12 +42,11 @@ def setup(self):
'Cannot set up test user: %s' % e
)

   -def teardown(self):
   +def teardown(cls):
try:
api.Command['user_del']([testuser])
except errors.NotFound:
pass
   -super(test_changepw, self).teardown()

The setup/teardown methods are not classmethods, so the name of the
first argument should remain self.


Oops, thanks for the catch!


 PATCH 0661: dogtag plugin: Don't use doctest syntax for
non-doctest
examples

ACK.

 PATCH 0662: test_webui: Don't use __init__ for test classes

I don't think the following change will work:

   -def __init__(self, driver=None, config=None):
   +def setup(self, driver=None, config=None):
self.request_timeout = 30
self.driver = driver
self.config = config
if not config:
self.load_config()
   +self.get_driver().maximize_window()
   +
   +def teardown(self):
   +self.driver.quit()

def load_config(self):

   @@ -161,20 +165,6 @@ def load_config(self):
if 'type' not in c:
c['type'] = DEFAULT_TYPE

   -def setup(self):
   -
   -Test setup
   -
   -if not self.driver:
   -self.driver = self.get_driver()
   -self.driver.maximize_window()
   -
   -def teardown(self):
   -
   -Test clean up
   -
   -self.driver.quit()


The setup(self) method used to set the self.driver attribute on the
class instance, now nothing sets it. The setup method should do:

   def 

Re: [Freeipa-devel] [PATCH] 0031 ipa-restore: Check if directory is provided + better errors.

2014-11-24 Thread Petr Viktorin

On 11/21/2014 02:28 PM, David Kupka wrote:

On 11/21/2014 02:12 PM, Tomas Babej wrote:


On 11/21/2014 01:56 PM, David Kupka wrote:

[...]



On another note, I also noticed that read_header leaves leaking file
descriptor fd.

Can you convert that part to use the with statement? This is a perfect
opportunity to fix this as you're touching related code.


I thought that python takes care of it.[...]


Python does take care of it eventually, but relying on this is messy – a 
bit like relying on the OS to close files when the process exits.
CPython will currently close the file as soon as there are no more 
references to the object, but different garbage collectors might take 
much longer.

Python 3 will issue warnings when opened files are left around.


--
Petr³

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


Re: [Freeipa-devel] [PATCH] 0032 Fix error message for nonexistent members and add tests.

2014-11-24 Thread David Kupka

On 11/21/2014 04:23 PM, Tomas Babej wrote:


On 11/21/2014 04:11 PM, David Kupka wrote:

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


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


-obj.get_dn_if_exists(name)
+try:
+obj.get_dn(name)
+except errors.NotFound:
+obj.handle_not_found(*keys)

You switched from get_dn_if_exists to get_dn, why? The get_dn method
never raises the NotFound error, it just constructs the dn regardless of
the fact whether the actual entry at that dn exists.

You need to use get_dn_if_exists here. Some negative tests for this
would be welcome :).

Indeed, by testing the patch:

[tbabej@vm-218 ~]$ ipa automember_rebuild --users=doesnotexist

Automember rebuild task finished. Processed (0) entries.


Where the old behaviour was:

[tbabej@vm-218 ~]$ ipa automember_rebuild --users=test
ipa: ERROR: no such entry


Thanks for catching this Friday-afternoon brain error.
Attached patch should work as expected.

--
David Kupka
From 2799c22154808f3f5dc0d4373d87f432adfc0ac3 Mon Sep 17 00:00:00 2001
From: David Kupka dku...@redhat.com
Date: Tue, 21 Oct 2014 18:12:23 -0400
Subject: [PATCH] Fix error message for nonexistent members and add tests.

https://fedorahosted.org/freeipa/ticket/4643
---
 ipalib/plugins/automember.py   |  5 +++-
 ipatests/test_xmlrpc/test_automember_plugin.py | 35 ++
 2 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/ipalib/plugins/automember.py b/ipalib/plugins/automember.py
index 0f47393166003e04ec53c16dcd1629038127509a..0c2a246e1c24b36525f61b47878860f4056569fc 100644
--- a/ipalib/plugins/automember.py
+++ b/ipalib/plugins/automember.py
@@ -735,7 +735,10 @@ class automember_rebuild(Command):
 names = options.get(opt_name)
 if names:
 for name in names:
-obj.get_dn_if_exists(name)
+try:
+obj.get_dn_if_exists(name)
+except errors.NotFound:
+obj.handle_not_found(name)
 search_filter = ldap.make_filter_from_attr(
 obj.primary_key.name,
 names,
diff --git a/ipatests/test_xmlrpc/test_automember_plugin.py b/ipatests/test_xmlrpc/test_automember_plugin.py
index 6618ac60531ddce3e651eff16d0ce0031b9f189d..88ed334230fad254c8140e51d27f8cc47a00d405 100644
--- a/ipatests/test_xmlrpc/test_automember_plugin.py
+++ b/ipatests/test_xmlrpc/test_automember_plugin.py
@@ -30,6 +30,7 @@ from ipatests.test_xmlrpc.test_user_plugin import get_user_result
 
 
 user1 = u'tuser1'
+user_does_not_exist = u'does_not_exist'
 manager1 = u'mscott'
 fqdn1 = u'web1.%s' % api.env.domain
 short1 = u'web1'
@@ -41,6 +42,7 @@ fqdn4 = u'www5.%s' % api.env.domain
 short4 = u'www5'
 fqdn5 = u'webserver5.%s' % api.env.domain
 short5 = u'webserver5'
+fqdn_does_not_exist = u'does_not_exist.%s' % api.env.domain
 
 group1 = u'group1'
 group1_dn = DN(('cn', group1), ('cn', 'groups'),
@@ -1625,4 +1627,37 @@ class test_automember(Declarative):
 ),
 ),
 
+dict(
+desc='Rebuild membership with type hostgroup and --hosts',
+command=('automember_rebuild', [], {u'type': u'hostgroup', u'hosts': fqdn1}),
+expected=dict(
+value=None,
+summary=u'Automember rebuild task finished. Processed (1) entries.',
+result={
+}
+),
+),
+
+dict(
+desc='Rebuild membership with type group and --users',
+command=('automember_rebuild', [], {u'type': u'group', u'users': user1}),
+expected=dict(
+value=None,
+summary=u'Automember rebuild task finished. Processed (1) entries.',
+result={
+}
+),
+),
+
+dict(
+desc='Try to rebuild membership with invalid host in --hosts',
+command=('automember_rebuild', [], {u'type': u'hostgroup', u'hosts': fqdn_does_not_exist}),
+expected=errors.NotFound(reason='%s: host not found' % fqdn_does_not_exist),
+),
+
+dict(
+desc='Try to rebuild membership with invalid user in --users',
+command=('automember_rebuild', [], {u'type': u'group', u'users': user_does_not_exist}),
+expected=errors.NotFound(reason='%s: user not found' % user_does_not_exist),
+),
 ]
-- 
2.1.0

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

[Freeipa-devel] [PATCH 0171] Fix encoding detection of zonemgr option

2014-11-24 Thread Martin Basti

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

Patch attached.

--
Martin Basti

From 2cc99c9140bbe07ed6a4e16037ae036e1f0e2eca Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Mon, 24 Nov 2014 12:46:37 +0100
Subject: [PATCH] Fix detection of encoding in zonemgr option

Ticket: https://fedorahosted.org/freeipa/ticket/4762
---
 ipaserver/install/bindinstance.py | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/ipaserver/install/bindinstance.py b/ipaserver/install/bindinstance.py
index 5bf784e62aec7c323a84fc5130e53c3deb86e6fd..f02fe8647dd38d05734311406152c50108077561 100644
--- a/ipaserver/install/bindinstance.py
+++ b/ipaserver/install/bindinstance.py
@@ -401,13 +401,14 @@ def zonemgr_callback(option, opt_str, value, parser):
 
 Properly validate and convert --zonemgr Option to IA5String
 
-# validate the value first
-try:
-# IDNA support requires unicode
-value = value.decode(sys.stdin.encoding)
-validate_zonemgr_str(value)
-except ValueError, e:
-parser.error(invalid zonemgr:  + unicode(e))
+if value is not None:
+# validate the value first
+try:
+# IDNA support requires unicode
+value = value.decode(getattr(sys.stdin, 'encoding', 'utf-8'))
+validate_zonemgr_str(value)
+except ValueError, e:
+parser.error(invalid zonemgr:  + unicode(e))
 
 parser.values.zonemgr = value
 
-- 
1.8.3.1

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

Re: [Freeipa-devel] [PATCH] 1111 Use NSS protocol range setter

2014-11-24 Thread Jan Cholasta

Dne 21.11.2014 v 16:09 Rob Crittenden napsal(a):

Jan Cholasta wrote:

Hi,

Dne 20.11.2014 v 23:26 Rob Crittenden napsal(a):

Use new capability in python-nss-0.16 to use the NSS protocol range
setter. This lets us enable TLSv1.1 and TLSv1.2 for client connections.

I made this configurable via tls_protocol_range in case somebody wants
to override it.

There isn't a whole ton of error handling on bad input but there is
enough, I think, to point the user in the the right direction.

Added a couple more lines of debug output to include the negotiated
protocol and cipher.

rob


1) The patch needs a rebase on top of ipa-4-1 (applies fine on master)


Attached.


2) Could you split the option into two options, say tls_version_min
and tls_version_max? IMO it would be easier to manage the version
range that way, when for example you have to lower just the minimal
version on a client to make it able to connect to a SSL3-only server.


Sure. I waffled back and forth before deciding on a single value.
Separate values are probably less error-prone.


3) Would it make sense to print a warning when the configured minimal
TLS version is not safe and the connection uses a safe TLS version? This
is for the case when you have to lower the minimal version on the client
because of an old server, then the server gets updated, then you
probably no longer want to have unsafe minimal version configured on the
client.


I see what you're saying but I think it could end up being just spam
that user's get used to. That and given that I'd probably want to set it
up to require tls1.1 as a minimum but we can't do that because dogtag
only supports through tls1.0 right now AFAICT. That'd be a lot of warnings.


You are probably right about the spam. Nevermind then.




Functionally the patch is OK.


rob



Thanks for the patch, ACK.

Fixed option names in commit message and pushed to:
master: 5c0ad221e815e8c7b95c1d1095ebd6cf18e7e11c
ipa-4-1: 8ef191448f0511b9c1749f47615437d649db0777

BTW before we can close the ticket, we are going to need a couple more 
fixes:


1) Bump required versions of 389-ds-base, pki-core and openldap, once 
the necessary fixes are available.


2) Configure mod_nss to also support TLS 1.2. It should be done on both 
server install and upgrade. This requires a new version of mod_nss.


--
Jan Cholasta

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


Re: [Freeipa-devel] [PATCH 0171] Fix encoding detection of zonemgr option

2014-11-24 Thread Jan Cholasta

Hi,

Dne 24.11.2014 v 14:01 Martin Basti napsal(a):

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

Patch attached.


Thanks, ACK.

Pushed to:
master: 230df95ed9e043069da0008d046b6b0135b0a8d1
ipa-4-1: 880f1e5c277a8826e3334723cd840cae4e65dfb8

Honza

--
Jan Cholasta

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


[Freeipa-devel] [PATCH] 0170 AD Trust: improve trust validation

2014-11-24 Thread Alexander Bokovoy

Hi,

Trust validation requires AD DC to contact IPA server to verify that
trust account actually works. It can fail due to DNS or firewall issue
or if AD DC was able to resolve IPA master(s) via SRV records, it still
may contact a replica that has no trust data replicated yet.

In case AD DC still returns 'access denied', wait 5 seconds and try
validation again.  Repeat validation until we hit a limit of 10
attempts, at which point raise exception telling what's happening.

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


--
/ Alexander Bokovoy
From 9b2bbe9d229f7c720d39766d3b76646358dce6a8 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
Date: Mon, 24 Nov 2014 15:07:49 +0200
Subject: [PATCH] AD trust: improve trust validation

Trust validation requires AD DC to contact IPA server to verify that trust 
account
actually works. It can fail due to DNS or firewall issue or if AD DC was able to
resolve IPA master(s) via SRV records, it still may contact a replica that has
no trust data replicated yet.

In case AD DC still returns 'access denied', wait 5 seconds and try validation 
again.
Repeat validation until we hit a limit of 10 attempts, at which point raise
exception telling what's happening.

https://fedorahosted.org/freeipa/ticket/4764
---
 ipaserver/dcerpc.py | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py
index caeca3c..e342c49 100644
--- a/ipaserver/dcerpc.py
+++ b/ipaserver/dcerpc.py
@@ -58,6 +58,7 @@ import pysss
 from ipaplatform.paths import paths
 
 from ldap.filter import escape_filter_chars
+from time import sleep
 
 __doc__ = _(
 Classes to manage trust joins using DCE-RPC calls
@@ -93,6 +94,8 @@ dcerpc_error_codes = {
 dcerpc_error_messages = {
 NT_STATUS_OBJECT_NAME_NOT_FOUND:
  errors.NotFound(reason=_('Cannot find specified domain or server 
name')),
+WERR_NO_LOGON_SERVERS:
+ errors.RemoteRetrieveError(reason=_('AD DC was unable to reach any 
IPA domain controller. Most likely it is a DNS or firewall issue')),
 NT_STATUS_INVALID_PARAMETER_MIX:
  errors.RequirementError(name=_('At least the domain or IP address 
should be specified')),
 }
@@ -699,6 +702,7 @@ class TrustDomainInstance(object):
 self._policy_handle = None
 self.read_only = False
 self.ftinfo_records = None
+self.validation_attempts = 0
 
 def __gen_lsa_connection(self, binding):
if self.creds is None:
@@ -1011,9 +1015,18 @@ class TrustDomainInstance(object):
   netlogon.NETLOGON_CONTROL_TC_VERIFY,
   another_domain.info['dns_domain'])
 if (result and (result.flags and 
netlogon.NETLOGON_VERIFY_STATUS_RETURNED)):
-# netr_LogonControl2Ex() returns non-None result only if overall 
call
-# result was WERR_OK which means verification was correct.
-# We only check that it was indeed status for verification process
+if (result.pdc_connection_status[0] != 0) and 
(result.tc_connection_status[0] != 0):
+if result.pdc_connection_status[1] == WERR_ACCESS_DENIED:
+# Most likely AD DC hit another IPA replica which yet has 
no trust secret replicated
+# Sleep and repeat again
+self.validation_attempts += 1
+if self.validation_attempts  10:
+sleep(5)
+return self.verify_trust(another_domain)
+raise errors.ACIError(reason=_('IPA master denied trust 
validation requests from AD DC '
+   '%(count)d times. Most 
likely AD DC contacted a replica '
+   'that has no trust 
information replicated yet.' % (self.validation_attempts)))
+raise assess_dcerpc_exception(*result.pdc_connection_status)
 return True
 return False
 
-- 
2.1.0

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

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

2014-11-24 Thread Alexander Bokovoy

On Mon, 10 Nov 2014, Jan Cholasta wrote:

From 63846b20707b194d0be635fa086fbbe463561d02 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Mon, 10 Nov 2014 18:10:59 +
Subject: [PATCH 5/7] Fix unchecked return values in ipa-winsync

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

ACK


---
.../ipa-winsync/ipa-winsync-config.c   | 40 +++---
1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-winsync/ipa-winsync-config.c 
b/daemons/ipa-slapi-plugins/ipa-winsync/ipa-winsync-config.c
index 65ceaea..8b62aed 100644
--- a/daemons/ipa-slapi-plugins/ipa-winsync/ipa-winsync-config.c
+++ b/daemons/ipa-slapi-plugins/ipa-winsync/ipa-winsync-config.c
@@ -905,9 +905,9 @@ ipa_winsync_config_refresh_domain(

if (!iwdc-realm_name) {
/* error - could not find the IPA config entry with the realm name */
-LOG_FATAL(Error: could not find the entry containing the realm name for 

-  ds subtree [%s] filter [%s] attr [%s]\n,
-  slapi_sdn_get_dn(ds_subtree), realm_filter, realm_attr);
+LOG_FATAL(Error: could not find the entry containing the realm name 
+  [%d] ds subtree [%s] filter [%s] attr [%s]\n,
+  ret, slapi_sdn_get_dn(ds_subtree), realm_filter, realm_attr);
goto out;
}

@@ -918,9 +918,9 @@ ipa_winsync_config_refresh_domain(
   new_user_objclasses, NULL);
if (!new_user_objclasses) {
/* error - could not find the entry containing list of objectclasses */
-LOG_FATAL(Error: could not find the entry containing the new user 
objectclass list for 
-  ds subtree [%s] filter [%s] attr [%s]\n,
-  slapi_sdn_get_dn(ds_subtree), new_entry_filter, 
new_user_oc_attr);
+LOG_FATAL(Error: could not find the entry containing the new user 
objectclass list 
+  [%d] ds subtree [%s] filter [%s] attr [%s]\n,
+  ret, slapi_sdn_get_dn(ds_subtree), new_entry_filter, 
new_user_oc_attr);
goto out;
}

@@ -933,9 +933,9 @@ ipa_winsync_config_refresh_domain(
   NULL, iwdc-homedir_prefix);
if (!iwdc-homedir_prefix) {
/* error - could not find the home dir prefix */
-LOG_FATAL(Error: could not find the entry containing the home directory 
prefix for 
-  ds subtree [%s] filter [%s] attr [%s]\n,
-  slapi_sdn_get_dn(ds_subtree), new_entry_filter, 
homedir_prefix_attr);
+LOG_FATAL(Error: could not find the entry containing the home directory 
prefix 
+  [%d] ds subtree [%s] filter [%s] attr [%s]\n,
+  ret, slapi_sdn_get_dn(ds_subtree), new_entry_filter, 
homedir_prefix_attr);
goto out;
}

@@ -950,8 +950,8 @@ ipa_winsync_config_refresh_domain(
   NULL, iwdc-login_shell);
if (!iwdc-login_shell) {
LOG(Warning: could not find the entry containing the login shell 
-attribute for ds subtree [%s] filter [%s] attr [%s]\n,
-slapi_sdn_get_dn(ds_subtree), new_entry_filter,
+attribute [%d] ds subtree [%s] filter [%s] attr [%s]\n,
+ret, slapi_sdn_get_dn(ds_subtree), new_entry_filter,
login_shell_attr);
}
}
@@ -969,9 +969,9 @@ ipa_winsync_config_refresh_domain(
   NULL, default_group_name);
if (!default_group_name) {
/* error - could not find the default group name */
-LOG_FATAL(Error: could not find the entry containing the default group 
name for 
-  ds subtree [%s] filter [%s] attr [%s]\n,
-  slapi_sdn_get_dn(ds_subtree), new_entry_filter, 
default_group_attr);
+LOG_FATAL(Error: could not find the entry containing the default group 
name 
+  [%d] ds subtree [%s] filter [%s] attr [%s]\n,
+  ret, slapi_sdn_get_dn(ds_subtree), new_entry_filter, 
default_group_attr);
goto out;
}

@@ -1014,9 +1014,9 @@ ipa_winsync_config_refresh_domain(
   NULL, inactivated_group_dn);
if (!inactivated_group_dn) {
/* error - could not find the inactivated group dn */
-LOG(Could not find the DN of the inactivated users group ds 
-subtree [%s] filter [%s]. Ignoring\n,
-slapi_sdn_get_dn(ds_subtree), inactivated_filter);
+LOG(Could not find the DN of the inactivated users group 
+[%d] ds subtree [%s] filter [%s]. Ignoring\n,
+ret, slapi_sdn_get_dn(ds_subtree), inactivated_filter);
goto out;
}
}
@@ -1026,9 +1026,9 @@ ipa_winsync_config_refresh_domain(
   NULL, 

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

2014-11-24 Thread Alexander Bokovoy

On Mon, 10 Nov 2014, Jan Cholasta wrote:

From 5cfc5d50ef7d2e42f10488ddf0d11fa405a8cb84 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Mon, 10 Nov 2014 18:12:02 +
Subject: [PATCH 6/7] Fix unchecked return value in ipa-join

https://fedorahosted.org/freeipa/ticket/4651
---
ipa-client/ipa-join.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ipa-client/ipa-join.c b/ipa-client/ipa-join.c
index 46f6457..ac8251f 100644
--- a/ipa-client/ipa-join.c
+++ b/ipa-client/ipa-join.c
@@ -208,8 +208,11 @@ connect_ldap(const char *hostname, const char *binddn, 
const char *bindpw) {
struct berval bindpw_bv;

if (debug) {
-ldapdebug=2;
+ldapdebug = 2;
ret = ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, ldapdebug);
+if (ret != LDAP_OPT_SUCCESS) {
+goto fail;
+}
}

if (ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, CAFILE) != 
LDAP_OPT_SUCCESS)

ACK

--
/ Alexander Bokovoy

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


[Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration

2014-11-24 Thread Martin Basti

Ticket: https://fedorahosted.org/freeipa/ticket/4721
Patch attached

--
Martin Basti

From a5a19137e3ddf2d2d48cfbdb2968b6f68ac8f772 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Fri, 21 Nov 2014 16:54:09 +0100
Subject: [PATCH] Detect and warn about invalid DNS forward zone configuration

Shows warning if forward and parent authoritative zone do not have
proper NS record delegation, which can cause the forward zone will be
ineffective and forwarding will not work.

The chande in the test was required due python changes order of elemnts
in dict (python doesnt guarantee an order in dict)

Ticket: https://fedorahosted.org/freeipa/ticket/4721
---
 ipalib/messages.py  |  12 +++
 ipalib/plugins/dns.py   | 147 +---
 ipatests/test_xmlrpc/test_dns_plugin.py |   2 +-
 3 files changed, 149 insertions(+), 12 deletions(-)

diff --git a/ipalib/messages.py b/ipalib/messages.py
index 102e35275dbe37328c84ecb3cd5b2a8d8578056f..cc9bae3d6e5c7d3a7401dab89fafb1b60dc1e15f 100644
--- a/ipalib/messages.py
+++ b/ipalib/messages.py
@@ -200,6 +200,18 @@ class DNSServerDoesNotSupportDNSSECWarning(PublicMessage):
uIf DNSSEC validation is enabled on IPA server(s), 
uplease disable it.)
 
+class ForwardzoneIsNotEffectiveWarning(PublicMessage):
+
+**13008** Forwardzone is not effective, forwarding will not work because
+there is authoritative parent zone, without proper NS delegation
+
+
+errno = 13008
+type = warning
+format = _(uforward zone \%(fwzone)s\ is not effective (missing proper 
+   uNS delegation in authoritative zone \%(authzone)s\). 
+   uForwarding may not work.)
+
 
 def iter_messages(variables, base):
 Return a tuple with all subclasses
diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
index c5d96a8c4fcdf101254ecefb60cb83d63bee6310..4f92da645e0faf784c7deb4b8ce386c1440f4229 100644
--- a/ipalib/plugins/dns.py
+++ b/ipalib/plugins/dns.py
@@ -1725,6 +1725,79 @@ def _normalize_zone(zone):
 return zone
 
 
+def _find_zone_which_makes_fw_zone_ineffective(fwzonename):
+
+Check if forward zone is effective.
+
+If parent zone exists as authoritative zone, forward zone will not
+forward queries. It is necessary to delegate authority of forward zone
+to another server (non IPA DNS server).
+
+Example:
+
+Forward zone: sub.example.com
+Zone: example.com
+
+Forwarding will not work, because server thinks it is authoritative
+and returns NXDOMAIN
+
+Adding record: sub.example.com NS nameserver.out.of.ipa.domain.
+will delegate authority to another server, and IPA DNS server will
+forward DNS queries.
+
+:param fwzonename: forwardzone
+:return: None if effective, name of authoritative zone otherwise
+
+assert isinstance(fwzonename, DNSName)
+
+# get all zones
+zones = api.Command.dnszone_find(pkey_only=True,
+sizelimit=0)['result']
+zonenames = [zone['idnsname'][0].make_absolute() for zone in zones]
+zonenames.sort(reverse=True, key=len)  # sort, we need longest match
+
+# check if is there a zone which can cause the forward zone will
+# be ineffective
+sub_of_auth_zone = None
+for name in zonenames:
+if fwzonename.is_subdomain(name):
+sub_of_auth_zone = name
+break
+
+if sub_of_auth_zone is None:
+return None
+
+# check if forwardzone is delegated in authoritative zone
+# test if exists and get NS record
+try:
+ns_records = api.Command.dnsrecord_show(
+sub_of_auth_zone, fwzonename, raw=True)['result']['nsrecord']
+except (errors.NotFound, KeyError):
+return sub_of_auth_zone
+
+# make sure the target is not IPA DNS server
+# FIXME: what if aliases are used?
+normalized_ns_records = set()
+for record in ns_records:
+if record.endswith('.'):
+normalized_ns_records.add(record)
+else:
+normalized_record = %s.%s % (record, sub_of_auth_zone)
+normalized_ns_records.add(normalized_record)
+
+nameservers = [normalize_zone(x) for x in
+   api.Object.dnsrecord.get_dns_masters()]
+
+if any(nameserver in normalized_ns_records
+   for nameserver in nameservers):
+# NS record is pointing to IPA DNS server
+return sub_of_auth_zone
+
+# authoritative zone contains NS records which delegates forwardzone to
+# different server, forwardzone is effective
+return None
+
+
 class DNSZoneBase(LDAPObject):
 
 Base class for DNS Zone
@@ -3164,6 +3237,29 @@ class dnsrecord(LDAPObject):
 dns_name = entry_name[1].derelativize(dns_domain)
 self.wait_for_modified_attrs(entry, dns_name, dns_domain)
 
+def warning_if_ns_change_cause_fwzone_ineffective(self, keys, result,
+  

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

2014-11-24 Thread Alexander Bokovoy

On Mon, 10 Nov 2014, Jan Cholasta wrote:

From 4e4600da5cd9c42b76a56cdbdb4c1314ee7b0a2a Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Mon, 10 Nov 2014 18:12:52 +
Subject: [PATCH 7/7] Fix unchecked return value in krb5 common utils

https://fedorahosted.org/freeipa/ticket/4651
---
util/ipa_krb5.c | 4 
1 file changed, 4 insertions(+)

diff --git a/util/ipa_krb5.c b/util/ipa_krb5.c
index 6334ed3..feb23ea 100644
--- a/util/ipa_krb5.c
+++ b/util/ipa_krb5.c
@@ -730,6 +730,10 @@ struct berval *create_key_control(struct keys_container 
*keys,

if (ksdata[i].salttype == NO_SALT) {
ret = ber_printf(be, });
+if (ret == -1) {
+ber_free(be, 1);
+return NULL;
+}
continue;
}


ACK

--
/ Alexander Bokovoy

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


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

2014-11-24 Thread Alexander Bokovoy

On Tue, 18 Nov 2014, Jan Cholasta wrote:

Dne 12.11.2014 v 08:58 Petr Spacek napsal(a):

On 11.11.2014 12:27, Jan Cholasta wrote:

Dne 11.11.2014 v 11:40 Alexander Bokovoy napsal(a):

On Tue, 11 Nov 2014, Jan Cholasta wrote:

From 82d7d37ca310af015018ebb2da2f9a72c4dabcaa Mon Sep 17 00:00:00 2001

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

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

diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c
b/daemons/ipa-kdb/ipa_kdb_mspac.c
index c8f6c76..debcd1b 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -2071,6 +2071,9 @@ krb5_error_code ipadb_sign_authdata(krb5_context
context,
ipactx-kdc_hostname,
strlen(ipactx-kdc_hostname),
NULL, NULL, result) == 0) {
kerr = ipadb_reinit_mspac(ipactx, true);
+if (kerr != 0  kerr != ENOENT) {
+goto done;
+}
}
}


I'm not sure we should drop the sign_authdata request here. If we were
able to re-initialize our view of trusted domains, we simply cannot
re-sign incoming PAC but this is handled in ipadb_verify_pac() and
ipadb_sign_pac() and if the former returns NULL value for PAC, we exit
with a return code of 0 while this change will fail a cross-realm TGT
request unconditionally.



OK, what would be a proper fix? Just ignore the return value of
ipadb_reinit_mspac here?


Guys, I did not see the code but all instances of ignore return code I have
seen were wrong, including cases where code comment explicitly said we ignore
return code on purpose :-)

At least log an error message if you can't think of anything better ...



I don't disagree, if that's the proper fix.

Alexander, or someone else, could you please finish the review of the 
patches? Thanks.

I've ACKed other patches but I'm not going to accept this patch. Rest is
fine.
--
/ Alexander Bokovoy

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


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

2014-11-24 Thread Jan Cholasta

Dne 24.11.2014 v 14:44 Alexander Bokovoy napsal(a):

On Tue, 18 Nov 2014, Jan Cholasta wrote:

Dne 12.11.2014 v 08:58 Petr Spacek napsal(a):

On 11.11.2014 12:27, Jan Cholasta wrote:

Dne 11.11.2014 v 11:40 Alexander Bokovoy napsal(a):

On Tue, 11 Nov 2014, Jan Cholasta wrote:

From 82d7d37ca310af015018ebb2da2f9a72c4dabcaa Mon Sep 17 00:00:00
2001

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

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

diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c
b/daemons/ipa-kdb/ipa_kdb_mspac.c
index c8f6c76..debcd1b 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -2071,6 +2071,9 @@ krb5_error_code
ipadb_sign_authdata(krb5_context
context,
ipactx-kdc_hostname,
strlen(ipactx-kdc_hostname),
NULL, NULL, result) == 0) {
kerr = ipadb_reinit_mspac(ipactx, true);
+if (kerr != 0  kerr != ENOENT) {
+goto done;
+}
}
}


I'm not sure we should drop the sign_authdata request here. If we were
able to re-initialize our view of trusted domains, we simply cannot
re-sign incoming PAC but this is handled in ipadb_verify_pac() and
ipadb_sign_pac() and if the former returns NULL value for PAC, we exit
with a return code of 0 while this change will fail a cross-realm TGT
request unconditionally.



OK, what would be a proper fix? Just ignore the return value of
ipadb_reinit_mspac here?


Guys, I did not see the code but all instances of ignore return
code I have
seen were wrong, including cases where code comment explicitly said
we ignore
return code on purpose :-)

At least log an error message if you can't think of anything better ...



I don't disagree, if that's the proper fix.

Alexander, or someone else, could you please finish the review of the
patches? Thanks.

I've ACKed other patches but I'm not going to accept this patch. Rest is
fine.


That's fine with me, but I'm still going to need a little hint on how 
this should in fact be fixed.


--
Jan Cholasta

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


Re: [Freeipa-devel] [PATCH] 783 webui: normalize idview tab labels

2014-11-24 Thread Tomas Babej

On 11/04/2014 03:54 PM, Petr Vobornik wrote:
 ID View tab labels are no longer redundant.

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


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

ACK, works fine.

Pushed to:
master: b42b1755dcd0a681709525b4d574e12b77bbce13
ipa-4-1: 2fc53c9426ff976d4732cc1d16b1b61447cb4313

-- 
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org 

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

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

2014-11-24 Thread Jan Cholasta

Dne 11.11.2014 v 11:13 Jan Cholasta napsal(a):

Dne 10.11.2014 v 19:25 Jan Cholasta napsal(a):

Hi,

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

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

Honza


Changed the ticket to https://fedorahosted.org/freeipa/ticket/4713.

Updated patches attached.


Attaching additional patch for an issue that popped up recently.

--
Jan Cholasta
From fef20b5966b4a49cc8c230437cf8f06899b51840 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Mon, 24 Nov 2014 13:57:10 +
Subject: [PATCH] Fix memory leak in GetKeytabControl asn1 code

https://fedorahosted.org/freeipa/ticket/4713
---
 asn1/ipa_asn1.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/asn1/ipa_asn1.c b/asn1/ipa_asn1.c
index 50851a8..9efca96 100644
--- a/asn1/ipa_asn1.c
+++ b/asn1/ipa_asn1.c
@@ -77,12 +77,12 @@ bool ipaasn1_enc_getktreply(int kvno, struct keys_container *keys,
 {
 GetKeytabControl_t gkctrl = { 0 };
 bool ret = false;
+KrbKey_t *KK;
 
 gkctrl.present = GetKeytabControl_PR_reply;
 gkctrl.choice.reply.newkvno = kvno;
 
 for (int i = 0; i  keys-nkeys; i++) {
-KrbKey_t *KK;
 KK = calloc(1, sizeof(KrbKey_t));
 if (!KK) goto done;
 KK-key.type = keys-ksdata[i].key.enctype;
@@ -109,9 +109,18 @@ bool ipaasn1_enc_getktreply(int kvno, struct keys_container *keys,
 }
 
 ret = encode_GetKeytabControl(gkctrl, buf, len);
+KK = NULL;
 
 done:
 ASN_STRUCT_FREE_CONTENTS_ONLY(asn_DEF_GetKeytabControl, gkctrl);
+if (KK) {
+free(KK-key.value.buf);
+if (KK-salt) {
+free(KK-salt-value.buf);
+free(KK-salt);
+}
+free(KK);
+}
 return ret;
 }
 
-- 
2.1.0

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

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

2014-11-24 Thread Alexander Bokovoy

On Mon, 24 Nov 2014, Jan Cholasta wrote:

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

diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c
b/daemons/ipa-kdb/ipa_kdb_mspac.c
index c8f6c76..debcd1b 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -2071,6 +2071,9 @@ krb5_error_code
ipadb_sign_authdata(krb5_context
context,
   ipactx-kdc_hostname,
strlen(ipactx-kdc_hostname),
   NULL, NULL, result) == 0) {
   kerr = ipadb_reinit_mspac(ipactx, true);
+if (kerr != 0  kerr != ENOENT) {
+goto done;
+}
   }
   }


I'm not sure we should drop the sign_authdata request here. If we were
able to re-initialize our view of trusted domains, we simply cannot
re-sign incoming PAC but this is handled in ipadb_verify_pac() and
ipadb_sign_pac() and if the former returns NULL value for PAC, we exit
with a return code of 0 while this change will fail a cross-realm TGT
request unconditionally.



OK, what would be a proper fix? Just ignore the return value of
ipadb_reinit_mspac here?


Guys, I did not see the code but all instances of ignore return
code I have
seen were wrong, including cases where code comment explicitly said
we ignore
return code on purpose :-)

At least log an error message if you can't think of anything better ...



I don't disagree, if that's the proper fix.

Alexander, or someone else, could you please finish the review of the
patches? Thanks.

I've ACKed other patches but I'm not going to accept this patch. Rest is
fine.


That's fine with me, but I'm still going to need a little hint on how 
this should in fact be fixed.

Right. My main issue is that the change in this patch actually changes
the flow for signing MS-PAC in case we were unable to retrieve our
defaults. We need to ignore the return code of ipadb_reinit_mspac() here
because we are simply not going to add MS PAC with our signature, not
fully denying getting the ticket (that check is in a separate place)
because this affects also our realm's principals. Consider a case when
ipa-adtrust-install wasn't even run, this is where we'll get non-working
MS-PAC defaults and we silently drop the MS-PAC signing.
--
/ Alexander Bokovoy

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


[Freeipa-devel] [PATCH] 0033 Use singular in help metavars + update man pages.

2014-11-24 Thread David Kupka

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

IMO this is one of two reasonable ways how to fix this ticket.
The other one is to change just the manual page but it seems more 
consistent to use singular for metavars everywhere.

--
David Kupka
From 54f396b9b8316173b1c295c15feb0bb38025b64a Mon Sep 17 00:00:00 2001
From: David Kupka dku...@redhat.com
Date: Mon, 24 Nov 2014 08:49:05 -0500
Subject: [PATCH] Use singular in help metavars + update man pages.

https://fedorahosted.org/freeipa/ticket/4695
---
 install/tools/ipa-dns-install| 4 ++--
 install/tools/ipa-replica-install| 5 +++--
 install/tools/ipa-server-install | 4 ++--
 install/tools/man/ipa-dns-install.1  | 3 ++-
 install/tools/man/ipa-replica-install.1  | 3 ++-
 install/tools/man/ipa-replica-prepare.1  | 3 ++-
 install/tools/man/ipa-server-install.1   | 4 +++-
 ipaserver/install/ipa_replica_prepare.py | 4 ++--
 8 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/install/tools/ipa-dns-install b/install/tools/ipa-dns-install
index 806c2e2698d63da1f2deaff36e565591769d8538..01ca59be8d0f2530bd96faae0d8ed0fd02a31c8e 100755
--- a/install/tools/ipa-dns-install
+++ b/install/tools/ipa-dns-install
@@ -42,7 +42,7 @@ def parse_options():
   sensitive=True, help=admin password)
 parser.add_option(-d, --debug, dest=debug, action=store_true,
   default=False, help=print debugging information)
-parser.add_option(--ip-address, dest=ip_addresses,
+parser.add_option(--ip-address, dest=ip_addresses, metavar=IP_ADDRESS,
   default=[], action=append,
   type=ip, ip_local=True, help=Master Server IP Address)
 parser.add_option(--forwarder, dest=forwarders, action=append,
@@ -50,7 +50,7 @@ def parse_options():
 parser.add_option(--no-forwarders, dest=no_forwarders, action=store_true,
   default=False, help=Do not add any DNS forwarders, use root servers instead)
 parser.add_option(--reverse-zone, dest=reverse_zones,
-  default=[], action=append,
+  default=[], action=append, metavar=REVERSE_ZONE,
   help=The reverse DNS zone to use)
 parser.add_option(--no-reverse, dest=no_reverse, action=store_true,
   default=False, help=Do not create new reverse DNS zone)
diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install
index 3cd8c41616c8b177e2e2eb164ced3e0af192fc4d..e7a0a53afd430708ff44b3fdd5a5e75ba7abcb5a 100755
--- a/install/tools/ipa-replica-install
+++ b/install/tools/ipa-replica-install
@@ -67,7 +67,7 @@ def parse_options():
   default=False, help=configure a dogtag CA)
 basic_group.add_option(--ip-address, dest=ip_addresses,
   type=ip, ip_local=True, action=append, default=[],
-  help=Replica server IP Address)
+  help=Replica server IP Address, metavar=IP_ADDRESS)
 basic_group.add_option(-p, --password, dest=password, sensitive=True,
   help=Directory Manager (existing master) password)
 basic_group.add_option(-w, --admin-password, dest=admin_password, sensitive=True,
@@ -111,7 +111,8 @@ def parse_options():
 dns_group.add_option(--no-forwarders, dest=no_forwarders, action=store_true,
   default=False, help=Do not add any DNS forwarders, use root servers instead)
 dns_group.add_option(--reverse-zone, dest=reverse_zones, default=[],
- action=append, help=The reverse DNS zone to use)
+ action=append, help=The reverse DNS zone to use,
+metavar=REVERSE_ZONE)
 dns_group.add_option(--no-reverse, dest=no_reverse, action=store_true,
   default=False, help=Do not create new reverse DNS zone)
 dns_group.add_option(--no-dnssec-validation, dest=no_dnssec_validation, action=store_true,
diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install
index fb8db7acadf90c2ec2e6fc48946db2d51ee2c424..1a2d21ff86a41b6abdd2cd1d31d6c53eb35b04f9 100755
--- a/install/tools/ipa-server-install
+++ b/install/tools/ipa-server-install
@@ -179,7 +179,7 @@ def parse_options():
 basic_group.add_option(--hostname, dest=host_name, help=fully qualified name of server)
 basic_group.add_option(--ip-address, dest=ip_addresses,
   type=ip, ip_local=True, action=append, default=[],
-  help=Master Server IP Address)
+  help=Master Server IP Address, metavar=IP_ADDRESS)
 basic_group.add_option(-N, --no-ntp, dest=conf_ntp, action=store_false,
   help=do not configure ntp, default=True)
 basic_group.add_option(--idstart, dest=idstart, default=namespace, type=int,
@@ -285,7 +285,7 @@ def parse_options():
 dns_group.add_option(--no-forwarders, dest=no_forwarders, action=store_true,

Re: [Freeipa-devel] [PATCH] 1111 Use NSS protocol range setter

2014-11-24 Thread Rob Crittenden
Jan Cholasta wrote:
 Dne 21.11.2014 v 16:09 Rob Crittenden napsal(a):
 Jan Cholasta wrote:
 Hi,

 Dne 20.11.2014 v 23:26 Rob Crittenden napsal(a):
 Use new capability in python-nss-0.16 to use the NSS protocol range
 setter. This lets us enable TLSv1.1 and TLSv1.2 for client connections.

 I made this configurable via tls_protocol_range in case somebody wants
 to override it.

 There isn't a whole ton of error handling on bad input but there is
 enough, I think, to point the user in the the right direction.

 Added a couple more lines of debug output to include the negotiated
 protocol and cipher.

 rob

 1) The patch needs a rebase on top of ipa-4-1 (applies fine on master)

 Attached.

 2) Could you split the option into two options, say tls_version_min
 and tls_version_max? IMO it would be easier to manage the version
 range that way, when for example you have to lower just the minimal
 version on a client to make it able to connect to a SSL3-only server.

 Sure. I waffled back and forth before deciding on a single value.
 Separate values are probably less error-prone.

 3) Would it make sense to print a warning when the configured minimal
 TLS version is not safe and the connection uses a safe TLS version? This
 is for the case when you have to lower the minimal version on the client
 because of an old server, then the server gets updated, then you
 probably no longer want to have unsafe minimal version configured on the
 client.

 I see what you're saying but I think it could end up being just spam
 that user's get used to. That and given that I'd probably want to set it
 up to require tls1.1 as a minimum but we can't do that because dogtag
 only supports through tls1.0 right now AFAICT. That'd be a lot of
 warnings.
 
 You are probably right about the spam. Nevermind then.
 

 Functionally the patch is OK.

 rob

 
 Thanks for the patch, ACK.
 
 Fixed option names in commit message and pushed to:
 master: 5c0ad221e815e8c7b95c1d1095ebd6cf18e7e11c
 ipa-4-1: 8ef191448f0511b9c1749f47615437d649db0777
 
 BTW before we can close the ticket, we are going to need a couple more
 fixes:
 
 1) Bump required versions of 389-ds-base, pki-core and openldap, once
 the necessary fixes are available.

Right, to be sure that POODLE is fully addressed.

 
 2) Configure mod_nss to also support TLS 1.2. It should be done on both
 server install and upgrade. This requires a new version of mod_nss.

mod_nss 1.0.10 in F-21 and rawhide should both support TLS 1.2 today.

mod_nss is also very tolerant of bad/unknown protocols. It won't blow up
on unknown protocols.

So if the given mod_nss doesn't support TLSv1.2 it will simply report an
error about an unknown protocol and configure the server for 1.0/1.1 if
configured as:

NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2

rob

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


Re: [Freeipa-devel] [PATCH] 0033 Use singular in help metavars + update man pages.

2014-11-24 Thread Martin Basti

On 24/11/14 15:54, David Kupka wrote:

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

IMO this is one of two reasonable ways how to fix this ticket.
The other one is to change just the manual page but it seems more 
consistent to use singular for metavars everywhere.



I like this approach. But IMO we should instead of You ... form in 
help, this message, as we use with forwarders


This option can be used multiple times

Martin^2

--
Martin Basti

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

Re: [Freeipa-devel] [PATCH] 0032 Fix error message for nonexistent members and add tests.

2014-11-24 Thread Tomas Babej

On 11/24/2014 01:20 PM, David Kupka wrote:
 On 11/21/2014 04:23 PM, Tomas Babej wrote:

 On 11/21/2014 04:11 PM, David Kupka wrote:
 https://fedorahosted.org/freeipa/ticket/4643


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

 -obj.get_dn_if_exists(name)
 +try:
 +obj.get_dn(name)
 +except errors.NotFound:
 +obj.handle_not_found(*keys)

 You switched from get_dn_if_exists to get_dn, why? The get_dn method
 never raises the NotFound error, it just constructs the dn regardless of
 the fact whether the actual entry at that dn exists.

 You need to use get_dn_if_exists here. Some negative tests for this
 would be welcome :).

 Indeed, by testing the patch:

 [tbabej@vm-218 ~]$ ipa automember_rebuild --users=doesnotexist
 
 Automember rebuild task finished. Processed (0) entries.
 

 Where the old behaviour was:

 [tbabej@vm-218 ~]$ ipa automember_rebuild --users=test
 ipa: ERROR: no such entry

 Thanks for catching this Friday-afternoon brain error.
 Attached patch should work as expected.


ACK, works fine.

master:
* b42b1755dcd0a681709525b4d574e12b77bbce13 webui: normalize idview tab
labels
ipa-4-1:
* 2fc53c9426ff976d4732cc1d16b1b61447cb4313 webui: normalize idview tab
labels


-- 
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org 

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


Re: [Freeipa-devel] [PATCH] 0032 Fix error message for nonexistent members and add tests.

2014-11-24 Thread Petr Vobornik

On 11/24/2014 04:07 PM, Tomas Babej wrote:





ACK, works fine.

master:
* b42b1755dcd0a681709525b4d574e12b77bbce13 webui: normalize idview tab
labels
ipa-4-1:
* 2fc53c9426ff976d4732cc1d16b1b61447cb4313 webui: normalize idview tab
labels



Wrong thread? Is it meant for  [PATCH] 783 webui: normalize idview tab 
labels?

--
Petr Vobornik

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


Re: [Freeipa-devel] [PATCH] 0032 Fix error message for nonexistent members and add tests.

2014-11-24 Thread Tomas Babej

On 11/24/2014 04:15 PM, Petr Vobornik wrote:
 On 11/24/2014 04:07 PM, Tomas Babej wrote:



 ACK, works fine.

 master:
 * b42b1755dcd0a681709525b4d574e12b77bbce13 webui: normalize idview tab
 labels
 ipa-4-1:
 * 2fc53c9426ff976d4732cc1d16b1b61447cb4313 webui: normalize idview tab
 labels


 Wrong thread? Is it meant for  [PATCH] 783 webui: normalize idview
 tab labels?

Correct thread, wrong message in the clipboard. Thanks for noticing.

David's patches were pushed to:
master: 56ca47d535156122b2578ff19bc0b1a7642af40c
ipa-4-1: 192c499ef893b7118a2f7ff9f4c939a9348d5123


-- 
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org 

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


[Freeipa-devel] [PATCH] 0675 copy_schema_to_ca: Fallback to old import location for ipaplatform.services

2014-11-24 Thread Petr Viktorin

This fixes a regression from the ipaplatform refactoring.

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

--
Petr³



From 2bea3850ff68c821b4af4e20d3992256e816c849 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Mon, 24 Nov 2014 15:01:29 +0100
Subject: [PATCH] copy_schema_to_ca: Fallback to old import location for
 ipaplatform.services

This file is copied to older servers that might not have the ipaplatform
refactoring.
Import from the old location if the new one is not available.

https://fedorahosted.org/freeipa/ticket/4763
---
 install/share/copy-schema-to-ca.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/install/share/copy-schema-to-ca.py b/install/share/copy-schema-to-ca.py
index fc53fe4cb52486cc618bec77aabe8283ad5eadbc..1614e11636c2f52e231ea2ff40d882209194c60a 100755
--- a/install/share/copy-schema-to-ca.py
+++ b/install/share/copy-schema-to-ca.py
@@ -15,13 +15,17 @@
 import pwd
 import shutil
 
-from ipaplatform import services
 from ipapython import ipautil, dogtag
 from ipapython.ipa_log_manager import root_logger, standard_logging_setup
 from ipaserver.install.dsinstance import DS_USER, schema_dirname
 from ipaserver.install.cainstance import PKI_USER
 from ipalib import api
 
+try:
+from ipaplatform import services
+except ImportError:
+from ipapython import services  # pylint: disable=no-name-in-module
+
 SERVERID = PKI-IPA
 SCHEMA_FILENAMES = (
 60kerberos.ldif,
-- 
2.1.0

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

Re: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration

2014-11-24 Thread Petr Spacek
Hello!

Thank you for the patch. It is not ready yet but the overall direction seems
good. Please see my comments in-line.

On 24.11.2014 14:35, Martin Basti wrote:
 Ticket: https://fedorahosted.org/freeipa/ticket/4721
 Patch attached
 
 -- 
 Martin Basti
 
 
 freeipa-mbasti-0170-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch
 
 
 From a5a19137e3ddf2d2d48cfbdb2968b6f68ac8f772 Mon Sep 17 00:00:00 2001
 From: Martin Basti mba...@redhat.com
 Date: Fri, 21 Nov 2014 16:54:09 +0100
 Subject: [PATCH] Detect and warn about invalid DNS forward zone configuration
 
 Shows warning if forward and parent authoritative zone do not have
 proper NS record delegation, which can cause the forward zone will be
 ineffective and forwarding will not work.
 
 The chande in the test was required due python changes order of elemnts
 in dict (python doesnt guarantee an order in dict)
 
 Ticket: https://fedorahosted.org/freeipa/ticket/4721
 ---
  ipalib/messages.py  |  12 +++
  ipalib/plugins/dns.py   | 147 
 +---
  ipatests/test_xmlrpc/test_dns_plugin.py |   2 +-
  3 files changed, 149 insertions(+), 12 deletions(-)
 
 diff --git a/ipalib/messages.py b/ipalib/messages.py
 index 
 102e35275dbe37328c84ecb3cd5b2a8d8578056f..cc9bae3d6e5c7d3a7401dab89fafb1b60dc1e15f
  100644
 --- a/ipalib/messages.py
 +++ b/ipalib/messages.py
 @@ -200,6 +200,18 @@ class 
 DNSServerDoesNotSupportDNSSECWarning(PublicMessage):
 uIf DNSSEC validation is enabled on IPA server(s), 
 uplease disable it.)
  
 +class ForwardzoneIsNotEffectiveWarning(PublicMessage):
 +
 +**13008** Forwardzone is not effective, forwarding will not work because
 +there is authoritative parent zone, without proper NS delegation
 +
 +
 +errno = 13008
 +type = warning
 +format = _(uforward zone \%(fwzone)s\ is not effective (missing 
 proper 
 +   uNS delegation in authoritative zone \%(authzone)s\). 
 +   uForwarding may not work.)
I think that the error message could be made mode useful:

Forwarding will not work. Please add NS record fwdzone.relativize(authzone)
to parent zone %(authzone)s (or something like that).

 +
  
  def iter_messages(variables, base):
  Return a tuple with all subclasses
 diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
 index 
 c5d96a8c4fcdf101254ecefb60cb83d63bee6310..4f92da645e0faf784c7deb4b8ce386c1440f4229
  100644
 --- a/ipalib/plugins/dns.py
 +++ b/ipalib/plugins/dns.py
 @@ -1725,6 +1725,79 @@ def _normalize_zone(zone):
  return zone
  
  
 +def _find_zone_which_makes_fw_zone_ineffective(fwzonename):
Generally, this method finds an authoritative zone for given fwzonename.
What about method name _find_auth_zone_ldap(name) ?

 +
 +Check if forward zone is effective.
 +
 +If parent zone exists as authoritative zone, forward zone will not
 +forward queries. It is necessary to delegate authority of forward zone
I would clarify it: forward queries by default.


 +to another server (non IPA DNS server).
I would personally omit (non IPA DNS server) because this mechanism is not
related to IPA domain at all.

 +Example:
 +
 +Forward zone: sub.example.com
 +Zone: example.com
 +
 +Forwarding will not work, because server thinks it is authoritative
 +and returns NXDOMAIN
 +
 +Adding record: sub.example.com NS nameserver.out.of.ipa.domain.
Again, this is not related to IPA domain at all. I propose this text:
Adding record: sub.example.com NS ns.sub.example.com.

 +will delegate authority to another server, and IPA DNS server will
 +forward DNS queries.
 +
 +:param fwzonename: forwardzone
 +:return: None if effective, name of authoritative zone otherwise
 +
 +assert isinstance(fwzonename, DNSName)
 +
 +# get all zones
 +zones = api.Command.dnszone_find(pkey_only=True,
 +sizelimit=0)['result']
Ooooh, are you serious? :-) I don't like this approach, I would rather chop
left-most labels from name and so dnszone_find() one by one. What if you
have many DNS zones?


This could be thrown away if you iterate only over relevant zones.
 +zonenames = [zone['idnsname'][0].make_absolute() for zone in zones]
 +zonenames.sort(reverse=True, key=len)  # sort, we need longest match
 +
 +# check if is there a zone which can cause the forward zone will
 +# be ineffective
 +sub_of_auth_zone = None
 +for name in zonenames:
 +if fwzonename.is_subdomain(name):
 +sub_of_auth_zone = name
 +break
 +
 +if sub_of_auth_zone is None:
 +return None
 +
 +# check if forwardzone is delegated in authoritative zone
 +# test if exists and get NS record
 +try:
 +ns_records = api.Command.dnsrecord_show(
 +sub_of_auth_zone, fwzonename, raw=True)['result']['nsrecord']
 +except (errors.NotFound, KeyError):
 +   

[Freeipa-devel] [PATCH] drop archeological feature :)

2014-11-24 Thread Simo Sorce

Getting through krbinstancepy I discovered we are still doing this
thing with the master key that has been unnecessary for a few years now.

Stop doing that.

I haven't really tested this yet ... but ... what could possibly go
wrong ? :-D

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
From a577e0f15fb750eaaf3cf129810e59c248bc0352 Mon Sep 17 00:00:00 2001
From: Simo Sorce s...@redhat.com
Date: Mon, 24 Nov 2014 13:06:23 -0500
Subject: [PATCH] Stop saving the master key in a stash file

This hasn't been used for a number of releases now, as ipa-kdb directly
fetches the key via LDAP.

Signed-off-by: Simo Sorce s...@redhat.com
---
 ipaserver/install/krbinstance.py | 26 --
 1 file changed, 26 deletions(-)

diff --git a/ipaserver/install/krbinstance.py b/ipaserver/install/krbinstance.py
index 81ed10581649b0c5209aadeca9ee162bdb52d100..6a480222fa4918a4950143f576138dc017cb58a7 100644
--- a/ipaserver/install/krbinstance.py
+++ b/ipaserver/install/krbinstance.py
@@ -199,7 +199,6 @@ class KrbInstance(service.Service):
 self.__common_setup(realm_name, host_name, domain_name, admin_password)
 
 self.step(adding sasl mappings to the directory, self.__configure_sasl_mappings)
-self.step(writing stash file from DS, self.__write_stash_from_ds)
 self.step(configuring KDC, self.__configure_instance)
 self.step(creating a keytab for the directory, self.__create_ds_keytab)
 self.step(creating a keytab for the machine, self.__create_host_keytab)
@@ -373,31 +372,6 @@ class KrbInstance(service.Service):
 appendvars=appendvars)
 tasks.restore_context(paths.SYSCONFIG_KRB5KDC_DIR)
 
-def __write_stash_from_ds(self):
-try:
-entries = self.admin_conn.get_entries(
-self.get_realm_suffix(), self.admin_conn.SCOPE_SUBTREE)
-# TODO: Ensure we got only one entry
-entry = entries[0]
-except errors.NotFound, e:
-root_logger.critical(Could not find master key in DS)
-raise e
-
-krbMKey = pyasn1.codec.ber.decoder.decode(
-entry.single_value.get('krbmkey'))
-keytype = int(krbMKey[0][1][0])
-keydata = str(krbMKey[0][1][1])
-
-format = '=hi%ss' % len(keydata)
-s = struct.pack(format, keytype, len(keydata), keydata)
-try:
-fd = open(paths.VAR_KRB5KDC_K5_REALM+self.realm, w)
-fd.write(s)
-fd.close()
-except os.error, e:
-root_logger.critical(failed to write stash file)
-raise e
-
 #add the password extop module
 def __add_pwd_extop_module(self):
 self._ldap_mod(pwd-extop-conf.ldif, self.sub_dict)
-- 
2.1.0

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

[Freeipa-devel] RFE - Number of thoughts on FreeIPA

2014-11-24 Thread William B
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I have been using FreeIPA for some time now. I have done a lot of
testing for the project, and have a desire to see FreeIPA do well.

As some background, I'm a system admin for a University, who currently
runs an unmanaged instance of 389ds. In the future I would love to move
to FreeIPA, but I want to explain some concerns first.

I have always noticed that FreeIPA is feature rich, but over time I
have noticed that this comes at a cost. Most components don't get as
much testing as they deserve, and just installing and running FreeIPA
for a few hours, one can quickly find rough edges and issues. Run it
for longer, and you quickly find more. As a business we value reliable,
and consistent software that doesn't have any surprises when we use
it. Unforseen issues sour peoples taste for things like FreeIPA, as
many people get stuck on their first impressions.

With these features also comes a lack of advanced documentation. Too
often the basics are well covered, but there are lots of simple tasks
that an admin would wish to perform that aren't covered in the
documentation. High quality, and advanced documentation is really key
to my work, as not everyone has as much time as I might to learn the
inside-out of FreeIPA. People want to reference documentation. Again,
one only needs to sit down and use FreeIPA for a few days, to try and
use it in their environment and you will quickly find that many tasks
aren't covered by the documentation. The documentation itself is also
hard to find, or out of date (Such as on fedoraproject.org, which is
the first google hit for me).

FreeIPA also pushes a some policies and ideas by default. Consider the
password reset functionality. By default, when the password is reset,
the password is also expired. In our environment, where we have a third
party tool that does password resets on accounts (Password manager),
this breaks our expectation as a user would then have to reset their
password again in the FreeIPA environment. Little things like this
remove flexibility and inhibit people making the swap. These options
shouldn't be hardcoded, they should be defaults that can be tuned. If
someone wants to do stupid things with those options, that is their
choice, but that flexibility will help FreeIPA gain acceptance into
businesses.

Finally, back to our rich features. Not all businesses want all the
features of FreeIPA. For example, we don't want the Dogtag CA, NTP, DNS
or Kerberos components. But the default install, installs all these
packages even if we don't use them, and it configures services that we
don't necesarily need. Kerberos is especially a risk for us as there
are plenty of unforseen issues that can arise when you have an AD
kerberos domain on the same network, even if they live in different DNS
namespaces. Contractors install systems into unix networks, unix
systems end up in windows networks. Over time, as process and better
discipline is involved, these little mistakes will be removed, but if
we were to deploy FreeIPA tomorrow, I have no doubt the kerberos
install would interfere with other parts of the network. I would really
like to see the FreeIPA build, split into freeipa-servers and
freeipa-servers-core where the core has only the 389ds, web ui and
kerberos components, and perhaps even one day, could even be kerberos
free. This might be taking a step back in some ways, but the
simplicity would be attractive to complex environments wanting to step
up from unmanaged 389ds, to something like FreeIPA, but without all the
complexity and overhead of a full install. Over time the extra modules
can be enabled as administrators please in a controlled fashion.
- - Yes, these things can be controlled through the use of the server
install command line switches, but if I'm installing and using only 389
and krb from FreeIPA, I shouldn't need to install all of dogtag as well.


These are just my thoughts on the project, and I think it boils down to
a few things:

* RFE to split freeipa packages to core and full.
* Asking for a review and enhancement of documentation.
* Better functional testing of FreeIPA server and tasks to help iron out
obvious issues before release.

Don't take this as harsh criticism. I think FreeIPA is a great project, 
and a great system. I would like to see it improve and be used more 
widely.

- -- 
Sincerely,

William Brown

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUc6q9AAoJEO/EFteBqAmaa+gP/1kB4recq6BFI/RkyBTMvdal
mUnjJHm5M07xvaYVvO56tjhyQFwja9MrDHO5XWekQFmyKG34/5uOEc5rSUX3Jgvh
r09r8Tfc8yUmLGtPcbTgw9mK3KgxYKgYCTkucvQPGZN8Yk/mLlkWk8ttGHrO01O4
ZUZnoG0GxdM6q4NP6Iy/U1hpZTOs2jllir0CGUt6v1gUnGXN6vlpF0SLUcto19XN
PLBUQRmuwDmGjlCsvBu4k1o4Zjf0rn52+FXNYCNpY95geFxQ4M6tU0N7iw3g4hW2
u53gklJbQX2u0BdI8KknWnGYg+JzRRh1Gz8wRBHJOZC//SiZndyvekm0SPxkZVPt
6JCyei3Uku6KPQwcFFJT7FVmeG5Q5ZSOgzFa6mN7Tky5qu6NwLNe8Rld0/vGQUp+
5i0YkPwNo9IV2F+A8KDVQ2BPEjfbjB74c5n0rJojMpS//R192ocoFHVbjQjXK2ho

Re: [Freeipa-devel] RFE - Number of thoughts on FreeIPA

2014-11-24 Thread Rich Megginson

On 11/24/2014 03:01 PM, William B wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I have been using FreeIPA for some time now. I have done a lot of
testing for the project, and have a desire to see FreeIPA do well.

As some background, I'm a system admin for a University, who currently
runs an unmanaged instance of 389ds. In the future I would love to move
to FreeIPA, but I want to explain some concerns first.

I have always noticed that FreeIPA is feature rich, but over time I
have noticed that this comes at a cost. Most components don't get as
much testing as they deserve, and just installing and running FreeIPA
for a few hours, one can quickly find rough edges and issues. Run it
for longer, and you quickly find more. As a business we value reliable,
and consistent software that doesn't have any surprises when we use
it. Unforseen issues sour peoples taste for things like FreeIPA, as
many people get stuck on their first impressions.

With these features also comes a lack of advanced documentation. Too
often the basics are well covered, but there are lots of simple tasks
that an admin would wish to perform that aren't covered in the
documentation. High quality, and advanced documentation is really key
to my work, as not everyone has as much time as I might to learn the
inside-out of FreeIPA. People want to reference documentation. Again,
one only needs to sit down and use FreeIPA for a few days, to try and
use it in their environment and you will quickly find that many tasks
aren't covered by the documentation. The documentation itself is also
hard to find, or out of date (Such as on fedoraproject.org, which is
the first google hit for me).

FreeIPA also pushes a some policies and ideas by default. Consider the
password reset functionality. By default, when the password is reset,
the password is also expired. In our environment, where we have a third
party tool that does password resets on accounts (Password manager),
this breaks our expectation as a user would then have to reset their
password again in the FreeIPA environment. Little things like this
remove flexibility and inhibit people making the swap. These options
shouldn't be hardcoded, they should be defaults that can be tuned. If
someone wants to do stupid things with those options, that is their
choice, but that flexibility will help FreeIPA gain acceptance into
businesses.

Finally, back to our rich features. Not all businesses want all the
features of FreeIPA. For example, we don't want the Dogtag CA, NTP, DNS
or Kerberos components.


Then why do you want to use FreeIPA?  Is it just for 389 LDAP + nice 
command line interface + nice web based UI?



But the default install, installs all these
packages even if we don't use them, and it configures services that we
don't necesarily need. Kerberos is especially a risk for us as there
are plenty of unforseen issues that can arise when you have an AD
kerberos domain on the same network, even if they live in different DNS
namespaces. Contractors install systems into unix networks, unix
systems end up in windows networks. Over time, as process and better
discipline is involved, these little mistakes will be removed, but if
we were to deploy FreeIPA tomorrow, I have no doubt the kerberos
install would interfere with other parts of the network. I would really
like to see the FreeIPA build, split into freeipa-servers and
freeipa-servers-core where the core has only the 389ds, web ui and
kerberos components, and perhaps even one day, could even be kerberos
free. This might be taking a step back in some ways, but the
simplicity would be attractive to complex environments wanting to step
up from unmanaged 389ds, to something like FreeIPA, but without all the
complexity and overhead of a full install. Over time the extra modules
can be enabled as administrators please in a controlled fashion.
- - Yes, these things can be controlled through the use of the server
install command line switches, but if I'm installing and using only 389
and krb from FreeIPA, I shouldn't need to install all of dogtag as well.


These are just my thoughts on the project, and I think it boils down to
a few things:

* RFE to split freeipa packages to core and full.
* Asking for a review and enhancement of documentation.
* Better functional testing of FreeIPA server and tasks to help iron out
 obvious issues before release.

Don't take this as harsh criticism. I think FreeIPA is a great project,
and a great system. I would like to see it improve and be used more
widely.

- -- 
Sincerely,


William Brown

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUc6q9AAoJEO/EFteBqAmaa+gP/1kB4recq6BFI/RkyBTMvdal
mUnjJHm5M07xvaYVvO56tjhyQFwja9MrDHO5XWekQFmyKG34/5uOEc5rSUX3Jgvh
r09r8Tfc8yUmLGtPcbTgw9mK3KgxYKgYCTkucvQPGZN8Yk/mLlkWk8ttGHrO01O4
ZUZnoG0GxdM6q4NP6Iy/U1hpZTOs2jllir0CGUt6v1gUnGXN6vlpF0SLUcto19XN
PLBUQRmuwDmGjlCsvBu4k1o4Zjf0rn52+FXNYCNpY95geFxQ4M6tU0N7iw3g4hW2

[Freeipa-devel] ds-migrate feature enhancements

2014-11-24 Thread Alan Evans
I am in the midst of preparing for a migration from OpenLDAP to FreeIPA.
ds-migrate wasn't going to fill all of my needs so I thought I would use it
for most and then make up some LDIF's and massage them to do the last bit
of migration.

I have instead decided to extend ds-migrate and I think that my features
might be of use to others so I would like to contribute them.  Before I get
too for I wanted to get some input from the community.

Here are MY original goals:
* Migrate ssh public keys
  The openssh-lpk schema is used in my tree so objectClass: ldapPublicKey
attribute: sshPublicKey
* Migrate disabled accounts as disabled
  We 'disable' usere by setting their shadowExpire to a date in the past
and setting their shell to /bin/false

I realized that the ssh-public key problem is more generally an attribute
mapping problem and dealing with disabled users could be more generalized
too.

Here are instead the new features I would provide.

* Attribute mapping
  Feature should check the new syntax exists and is the same as the old
syntax (perhaps further check for compatible syntax)
  --user-attribute-map=oldAttribute=newAttribute
  --group-attribute-map=foo=bar
  Should I drop user/group and just make it --attribute-map and apply it to
both?
  Should certain attributes be mapped by default, i.e.
sshPublicKey=ipaSSHPubKey (this means we also need to ignore the
objectClass ldapPublicKey by default)  Maybe make a separate switch
--with-ssh-keys that automatically adds a map and an ignore?

* Handling disabled users
  1. How to identify disabled users?
a. shadowExpire  now()
--use-disable-shadow-expire
b. loginShell is one of configurable shells
--use-disable-login-shell
--disabled-shell=/bin/false --disabled-shell=/sbin/nologin (these
two would be the defaults)
c. nsAccountLocked (though that would be straight copied by the
migrator anyway
d. From Open DJ the attribute ds-pwp-account-disabled can be used to
identify disabled users
(are there others?)
  2.  What do do with disabled users (in my case migrate and disable)
a. Migrate them and don't touch nsAccountLocked
b. Migrate them and set nsAccountLocked = true
   --disable-users
c. Do not migrate them
   --skip-disabled-users
d. Which is the default?  Migrate and disable?  If so which are the
default methods for identifying them?  All methods?

So is there anything I'm missing?  Any suggestions on the switches? I'm not
entirely sure I like them the way they are.

I have code to cover about 60% of the above already.  The user-attr-map
feature is working and the --disabled-users and disabled-shells options are
working.

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

Re: [Freeipa-devel] RFE - Number of thoughts on FreeIPA

2014-11-24 Thread William B
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 24 Nov 2014 15:10:49 -0700
Rich Megginson rmegg...@redhat.com wrote:

 
  Finally, back to our rich features. Not all businesses want all the
  features of FreeIPA. For example, we don't want the Dogtag CA, NTP,
  DNS or Kerberos components.
 
 Then why do you want to use FreeIPA?  Is it just for 389 LDAP + nice 
 command line interface + nice web based UI?
 

Yes, that's exactly what. When you think about FreeIPA, at it's core it's not
about dogtag ca, or ntp etc. It's about more effectively managed identity and
policy.

At my work, I have to observe the horrors of a directory instance that has
evolved by people who didn't have the discipline to put all objects in the
correct places, or use the correct objectClasses, who have hacked ACI's etc.

Having a nice webui, the commandline tools enforces consistency in actions that
admins take. It's not about the features as much as using the technology to 
enforce discipline and have vendor supported methodolgies. 


- -- 
Sincerely,

William Brown

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUc721AAoJEO/EFteBqAmayZsQAJqy+J7gWlAFasDIruJDaxaP
1/aG4N8crngFVbzqFjPYQ0j6ZmtrWOeIbTZxXlCk4jwcCEW/yjF8l6fCDRKEt3v2
iCjejsb3id4sWbl9V9Ldkq8d17NzJ74Noun41bqNeT/Q4ktmEQRWAbgC6ZpZ8dm+
aJFbEb9/NgCXtzymNAfEH6cjCDh0QoBqwmSz/0FF7vdqYX5J0isx6ut6VdI/DZGb
BUHtHYyghUNmB1cV7kp630Dv/Qo90yxth3o9EJ92yUSe/iRKV1KsYcimVqlRx6dA
WXo9Q8R1b6Ofod7wv+wW5os5FNCk12nrJbaNl2H/t4kQut3S9evyy5y7jAFHW3R3
TbEhC8f4WRHV6clFF6ovchHLHJ57heGGaNprHcqrnbb/CaH8Ec+zvmkZzqWmrkNv
71ZqlkbS0CRK7NNBVjrZ8bUg1QzpfonU2zOniN/mFy9NMpRfNDmSvYxQ4dyi7W7y
ZjAUAODyZE8fo1it53RFjNTW45JlBos7LTeJKq4cWANrMbcSxi760eU9WmSIpeDq
mn5zQAkMpwDahwgqjYJL88eb94xJy1wnV79QR9RcGgtGxqrlSo/Dxr4zS2uLZDHZ
dHWYZj0D4Fk45hRqbiOXeRYE0+98CtBV2K0LO4Nm2ii5Dxd+dATa3cSEAkYrfCBG
lWwfKh0aURl69MGrK0s3
=w8jd
-END PGP SIGNATURE-

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


Re: [Freeipa-devel] Meaning of Needs UI design field in Trac?

2014-11-24 Thread Fraser Tweedale
On Mon, Nov 24, 2014 at 09:23:50AM +0100, Martin Kosek wrote:
 On 11/24/2014 08:39 AM, Fraser Tweedale wrote:
  Hi all,
  
  The precise meaning and usage of the Needs UI design field in Trac
  is not clear to me.  It has five values:
  
  - blank
  - Not needed
  - Review
  - Consult
  - Design
  
  What is the purpose of this field and the meanings of the different
  values?  And a more general question: is there a resource anywhere
  that explains the various fields in the FreeIPA Trac?
 
 Hi Fraser,
 
 The addition Trac ticket metadata are usually added quite organically, as they
 are needed. I am not aware of a page that would describe them. If the field is
 not clear just from the description, it means it is possibly badly designed 
 :-)
 
 Needs UI design in particular was used to select tickets that needs, well, UI
 review from UX specialist.
 
 But given it is not used on a frequent basis
 (https://fedorahosted.org/freeipa/query?uxd=!uxd=!Not+neededstatus=assignedstatus=newstatus=reopenedorder=prioritycol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=component)
 I would personally just remove it and use keyword for this one time usage 
 (like
 ux-required) to make tickets smaller.
 
 HTH,
 Martin

Thanks Martin, that does help.

I'll not remove the field just now but I will make a page on the
wiki about this.  There we can codify semantics of fields and common
tags, and indicate fields that are candidates for removal.

Cheers,

Fraser

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


Re: [Freeipa-devel] RFE - Number of thoughts on FreeIPA

2014-11-24 Thread Simo Sorce
On Tue, 25 Nov 2014 08:31:33 +1030
William B will...@firstyear.id.au wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi,
 
 I have been using FreeIPA for some time now. I have done a lot of
 testing for the project, and have a desire to see FreeIPA do well.
 
 As some background, I'm a system admin for a University, who currently
 runs an unmanaged instance of 389ds. In the future I would love to
 move to FreeIPA, but I want to explain some concerns first.
 
 I have always noticed that FreeIPA is feature rich, but over time I
 have noticed that this comes at a cost. Most components don't get as
 much testing as they deserve, and just installing and running FreeIPA
 for a few hours, one can quickly find rough edges and issues. Run it
 for longer, and you quickly find more. As a business we value
 reliable, and consistent software that doesn't have any surprises
 when we use it. Unforseen issues sour peoples taste for things like
 FreeIPA, as many people get stuck on their first impressions.
 
 With these features also comes a lack of advanced documentation. Too
 often the basics are well covered, but there are lots of simple tasks
 that an admin would wish to perform that aren't covered in the
 documentation. High quality, and advanced documentation is really key
 to my work, as not everyone has as much time as I might to learn the
 inside-out of FreeIPA. People want to reference documentation. Again,
 one only needs to sit down and use FreeIPA for a few days, to try and
 use it in their environment and you will quickly find that many tasks
 aren't covered by the documentation. The documentation itself is also
 hard to find, or out of date (Such as on fedoraproject.org, which is
 the first google hit for me).
 
 FreeIPA also pushes a some policies and ideas by default. Consider the
 password reset functionality. By default, when the password is reset,
 the password is also expired. In our environment, where we have a
 third party tool that does password resets on accounts (Password
 manager), this breaks our expectation as a user would then have to
 reset their password again in the FreeIPA environment. Little things
 like this remove flexibility and inhibit people making the swap.
 These options shouldn't be hardcoded, they should be defaults that
 can be tuned. If someone wants to do stupid things with those
 options, that is their choice, but that flexibility will help FreeIPA
 gain acceptance into businesses.
 
 Finally, back to our rich features. Not all businesses want all the
 features of FreeIPA. For example, we don't want the Dogtag CA, NTP,
 DNS or Kerberos components. But the default install, installs all
 these packages even if we don't use them, and it configures services
 that we don't necesarily need. Kerberos is especially a risk for us
 as there are plenty of unforseen issues that can arise when you have
 an AD kerberos domain on the same network, even if they live in
 different DNS namespaces. Contractors install systems into unix
 networks, unix systems end up in windows networks. Over time, as
 process and better discipline is involved, these little mistakes will
 be removed, but if we were to deploy FreeIPA tomorrow, I have no
 doubt the kerberos install would interfere with other parts of the
 network. I would really like to see the FreeIPA build, split into
 freeipa-servers and freeipa-servers-core where the core has only
 the 389ds, web ui and kerberos components, and perhaps even one day,
 could even be kerberos free. This might be taking a step back in
 some ways, but the simplicity would be attractive to complex
 environments wanting to step up from unmanaged 389ds, to something
 like FreeIPA, but without all the complexity and overhead of a full
 install. Over time the extra modules can be enabled as administrators
 please in a controlled fashion.
 - - Yes, these things can be controlled through the use of the server
 install command line switches, but if I'm installing and using only
 389 and krb from FreeIPA, I shouldn't need to install all of dogtag
 as well.
 
 
 These are just my thoughts on the project, and I think it boils down
 to a few things:
 
 * RFE to split freeipa packages to core and full.
 * Asking for a review and enhancement of documentation.
 * Better functional testing of FreeIPA server and tasks to help iron
 out obvious issues before release.
 
 Don't take this as harsh criticism. I think FreeIPA is a great
 project, and a great system. I would like to see it improve and be
 used more widely.

Hi William, good news is, Dogtag, DNS and NTP are all optional
components, you can install a FreeIPa server withouth the CA and
without DNS. NTP is installed by default, but it is very easy to
diasable it if you want.

Kerberos is a core feature and cannot be disabled, but I thing you
figured that out already.

We have some plans to split the rpm packaging so that DNS and CA
components can be split into separate subpackages, however we are not
there yet, as