[Freeipa-devel] [PATCH 0039] Enforce exact SID match when adding or modifying a ID range
Hi,
SID validation in idrange.py now enforces exact match on SIDs, thus
one can no longer use SID of an object in a trusted domain as a
trusted domain SID.
https://fedorahosted.org/freeipa/ticket/3432
Tomas
From 8a8eca8a2113802273036386b46a96ce0f292671 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 6 Mar 2013 12:17:28 +0100
Subject: [PATCH] Enforce exact SID match when adding or modifying a ID range
SID validation in idrange.py now enforces exact match on SIDs, thus
one can no longer use SID of an object in a trusted domain as a
trusted domain SID.
https://fedorahosted.org/freeipa/ticket/3432
---
ipalib/plugins/idrange.py | 2 +-
ipaserver/dcerpc.py | 55 ---
2 files changed, 43 insertions(+), 14 deletions(-)
diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
index d8989327a24af2d4aa278a215d934b9ca0fab87b..39d713e332aaf41e8c8e8d9116a07f3baba47e79 100644
--- a/ipalib/plugins/idrange.py
+++ b/ipalib/plugins/idrange.py
@@ -289,7 +289,7 @@ class idrange(LDAPObject):
domain_validator = self.get_domain_validator()
-if not domain_validator.is_trusted_sid_valid(sid):
+if not domain_validator.is_trusted_sid_valid_domain(sid):
raise errors.ValidationError(name='domain SID',
error=_('SID is not recognized as a valid SID for a '
'trusted domain'))
diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py
index b8f83e9a479d2d68cac46000500ddb1051251a22..5e69ef67ca765b273b0f03a2097c27f0b9ec5121 100644
--- a/ipaserver/dcerpc.py
+++ b/ipaserver/dcerpc.py
@@ -183,37 +183,58 @@ class DomainValidator(object):
except errors.NotFound, e:
return []
-def get_domain_by_sid(self, sid):
+def get_domain_by_sid(self, sid, exact_match=False):
if not self.domain:
# our domain is not configured or self.is_configured() never run
# reject SIDs as we can't check correctness of them
raise errors.ValidationError(name='sid',
error=_('domain is not configured'))
+
# Parse sid string to see if it is really in a SID format
try:
test_sid = security.dom_sid(sid)
-except TypeError, e:
+except TypeError:
raise errors.ValidationError(name='sid',
error=_('SID is not valid'))
+
# At this point we have SID_NT_AUTHORITY family SID and really need to
# check it against prefixes of domain SIDs we trust to
if not self._domains:
self._domains = self.get_trusted_domains()
if len(self._domains) == 0:
# Our domain is configured but no trusted domains are configured
-# This means we can't check the correctness of a trusted domain SIDs
+# This means we can't check the correctness of a trusted
+# domain SIDs
raise errors.ValidationError(name='sid',
error=_('no trusted domain is configured'))
-# We have non-zero list of trusted domains and have to go through them
-# one by one and check their sids as prefixes
-test_sid_subauths = test_sid.sub_auths
-for domain in self._domains:
-domsid = self._domains[domain][1]
-sub_auths = domsid.sub_auths
-num_auths = min(test_sid.num_auths, domsid.num_auths)
-if test_sid_subauths[:num_auths] == sub_auths[:num_auths]:
-return domain
-raise errors.NotFound(reason=_('SID does not match any trusted domain'))
+
+# We have non-zero list of trusted domains and have to go through
+# them one by one and check their sids as prefixes / exact match
+# depending on the value of exact_match flag
+if exact_match:
+# check exact match of sids
+for domain in self._domains:
+if sid == str(self._domains[domain][1]):
+return domain
+
+root_logger.error('No trusted domain with given SID found, '
+ 'listing SIDS for all the trusted domains:')
+for domain in self._domains:
+root_logger.error('SID: %s' % self._domains[domain][1])
+
+raise errors.NotFound(reason=_(SID does not match exactly
+ with any trusted domain's SID))
+else:
+# check as prefixes
+test_sid_subauths = test_sid.sub_auths
+for domain in self._domains:
+domsid = self._domains[domain][1]
+sub_auths = domsid.sub_auths
+num_auths = min(test_sid.num_auths, domsid.num_auths)
+if test_sid_subauths[:num_auths] == sub_auths[:num_auths]:
+return domain
+raise errors.NotFound(reason=_('SID does not match any '
+
Re: [Freeipa-devel] [PATCH 0039] Enforce exact SID match when adding or modifying a ID range
On Wed 13 Mar 2013 09:47:09 AM CET, Tomas Babej wrote:
Hi,
SID validation in idrange.py now enforces exact match on SIDs, thus
one can no longer use SID of an object in a trusted domain as a
trusted domain SID.
https://fedorahosted.org/freeipa/ticket/3432
Tomas
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Just renamed the patch filename to follow the convention.
Tomas
From 8a8eca8a2113802273036386b46a96ce0f292671 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 6 Mar 2013 12:17:28 +0100
Subject: [PATCH] Enforce exact SID match when adding or modifying a ID range
SID validation in idrange.py now enforces exact match on SIDs, thus
one can no longer use SID of an object in a trusted domain as a
trusted domain SID.
https://fedorahosted.org/freeipa/ticket/3432
---
ipalib/plugins/idrange.py | 2 +-
ipaserver/dcerpc.py | 55 ---
2 files changed, 43 insertions(+), 14 deletions(-)
diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py
index d8989327a24af2d4aa278a215d934b9ca0fab87b..39d713e332aaf41e8c8e8d9116a07f3baba47e79 100644
--- a/ipalib/plugins/idrange.py
+++ b/ipalib/plugins/idrange.py
@@ -289,7 +289,7 @@ class idrange(LDAPObject):
domain_validator = self.get_domain_validator()
-if not domain_validator.is_trusted_sid_valid(sid):
+if not domain_validator.is_trusted_sid_valid_domain(sid):
raise errors.ValidationError(name='domain SID',
error=_('SID is not recognized as a valid SID for a '
'trusted domain'))
diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py
index b8f83e9a479d2d68cac46000500ddb1051251a22..5e69ef67ca765b273b0f03a2097c27f0b9ec5121 100644
--- a/ipaserver/dcerpc.py
+++ b/ipaserver/dcerpc.py
@@ -183,37 +183,58 @@ class DomainValidator(object):
except errors.NotFound, e:
return []
-def get_domain_by_sid(self, sid):
+def get_domain_by_sid(self, sid, exact_match=False):
if not self.domain:
# our domain is not configured or self.is_configured() never run
# reject SIDs as we can't check correctness of them
raise errors.ValidationError(name='sid',
error=_('domain is not configured'))
+
# Parse sid string to see if it is really in a SID format
try:
test_sid = security.dom_sid(sid)
-except TypeError, e:
+except TypeError:
raise errors.ValidationError(name='sid',
error=_('SID is not valid'))
+
# At this point we have SID_NT_AUTHORITY family SID and really need to
# check it against prefixes of domain SIDs we trust to
if not self._domains:
self._domains = self.get_trusted_domains()
if len(self._domains) == 0:
# Our domain is configured but no trusted domains are configured
-# This means we can't check the correctness of a trusted domain SIDs
+# This means we can't check the correctness of a trusted
+# domain SIDs
raise errors.ValidationError(name='sid',
error=_('no trusted domain is configured'))
-# We have non-zero list of trusted domains and have to go through them
-# one by one and check their sids as prefixes
-test_sid_subauths = test_sid.sub_auths
-for domain in self._domains:
-domsid = self._domains[domain][1]
-sub_auths = domsid.sub_auths
-num_auths = min(test_sid.num_auths, domsid.num_auths)
-if test_sid_subauths[:num_auths] == sub_auths[:num_auths]:
-return domain
-raise errors.NotFound(reason=_('SID does not match any trusted domain'))
+
+# We have non-zero list of trusted domains and have to go through
+# them one by one and check their sids as prefixes / exact match
+# depending on the value of exact_match flag
+if exact_match:
+# check exact match of sids
+for domain in self._domains:
+if sid == str(self._domains[domain][1]):
+return domain
+
+root_logger.error('No trusted domain with given SID found, '
+ 'listing SIDS for all the trusted domains:')
+for domain in self._domains:
+root_logger.error('SID: %s' % self._domains[domain][1])
+
+raise errors.NotFound(reason=_(SID does not match exactly
+ with any trusted domain's SID))
+else:
+# check as prefixes
+test_sid_subauths = test_sid.sub_auths
+for domain in self._domains:
+domsid = self._domains[domain][1]
+sub_auths = domsid.sub_auths
+
[Freeipa-devel] OID assignment request: new objectClass idnsForwardZone
Hello list, I would like to obtain new OID for new objectClass idnsForwardZone, as planed in https://fedorahosted.org/bind-dyndb-ldap/ticket/99 . idnsForwardZone is meant as sane subset of existing idnsZone. Currently, IPA uses idnsZone for master and forward zones at the same time. The result of this situation is a mess. Users are forced to fill in non-senses like fake SOA records for forward zones etc. IPAv3 uses OID space 2.16.840.1.113730.3.8.12.x for objectClasses, right? New objectClass proposal: objectClasses: ( 2.16.840.1.113730.3.8.12.x NAME 'idnsForwardZone' DESC 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ idnsZoneActive $ idnsForwarders ) MAY idnsForwardPolicy ) -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 376-377, 385 Use tkey-gssapi-keytab in named.conf
On 03/11/2013 09:39 AM, Petr Spacek wrote:
On 11.3.2013 09:09, Martin Kosek wrote:
On 03/08/2013 09:49 AM, Petr Spacek wrote:
On 8.3.2013 00:14, Rob Crittenden wrote:
Martin Kosek wrote:
Remove obsolete BIND GSSAPI configuration options tkey-gssapi-credential
and tkey-domain and replace them with tkey-gssapi-keytab which avoids
unnecessary Kerberos checks on BIND startup and can cause issues when
KDC is not available.
Both new and current IPA installations are updated.
https://fedorahosted.org/freeipa/ticket/3429
Still reviewing this but I noticed that after upgrading my 3.1.99 server
pre-patch to with with-patch version the connections argument in named.conf
got set to 4 (courtesy of ipa-upgradeconfig). Should we be setting that to
4
during the initial install too?
For 3.2 it doesn't matter. Anything = 2 should be okay, but more
connections
should not harm.
Higher value should allow higher level of parallelism, it is one of tuning
parameters. Value 4 was necessary to prevent deadlocks in some previous
versions of bind-dyndb-ldap.
Previously, when I implemented the upgrade script, I set connections arg only
if it was present in named.conf and thus bind-dyndb-ldap could not use a
reasonable default on its own decision.
This was changed in e578183ea25a40aedf6dcc3e1ee4bcb19b73e70f and connections
is set always. Rob is correct, that in that case we might want to add it to
named.conf by default to make it consistent... or we could also fix upgrade
script to change connections only if it is present in named.conf.
Petr, what does make more sense bind-dyndb-ldap wise?
Default values should work. Personally I would include only override values
in named.conf, but technically it doesn't matter.
Note: Latest bind-dyndb-ldap versions refuse to start if configuration is
insane. Fatal error will point admin to errors in configuration and should
prevent surprises from auto-magically changed values.
Invalid configurations - examples:
connections 1
connections 2 psearch is enabled
serial_autoincrement enabled psearch disabled
Ok, lets set the connections argument only if it is in named.conf _and_ it is
lower than the required minimum. All patches attached.
Martin
From 323856232e40f9678a599a5392eb4826aca8954d Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Tue, 5 Mar 2013 12:02:58 +0100
Subject: [PATCH 1/2] Update named.conf parser
Refactor the named.conf parsing and editing functions in bindinstance
so that both dynamic-db and options sections of named.conf can
be read and updated
https://fedorahosted.org/freeipa/ticket/3429
---
ipaserver/install/bindinstance.py | 60 ---
1 file changed, 43 insertions(+), 17 deletions(-)
diff --git a/ipaserver/install/bindinstance.py b/ipaserver/install/bindinstance.py
index dff661dd600dfd7933d8094326209fb55884fd5b..057b73f88ba1984a9a82da0bf0fc63dbcf7d1cc9 100644
--- a/ipaserver/install/bindinstance.py
+++ b/ipaserver/install/bindinstance.py
@@ -43,8 +43,12 @@ from ipalib.util import (validate_zonemgr, normalize_zonemgr,
NAMED_CONF = '/etc/named.conf'
RESOLV_CONF = '/etc/resolv.conf'
+named_conf_ipa_start = 'dynamic-db ipa'
+named_conf_options_start = 'options {'
named_conf_ipa_re = re.compile(r'(?Pindent\s*)arg\s+(?Pname\S+)\s(?Pvalue[^]+);')
+named_conf_options_re = re.compile(r'(?Pindent\s*)(?Pname\S+)\s+(?Pvalue[^]+)\s*;')
named_conf_ipa_template = %(indent)sarg \%(name)s %(value)s\;\n
+named_conf_options_template = %(indent)s%(name)s \%(value)s\;\n
def check_inst(unattended):
has_bind = True
@@ -86,26 +90,36 @@ def named_conf_exists():
return True
return False
-def named_conf_get_directive(name):
+NAMED_SECTION_OPTIONS = options
+NAMED_SECTION_IPA = ipa
+def named_conf_get_directive(name, section=NAMED_SECTION_IPA):
Get a configuration option in bind-dyndb-ldap section of named.conf
+if section == NAMED_SECTION_IPA:
+named_conf_start = named_conf_ipa_start
+named_conf_re = named_conf_ipa_re
+elif section == NAMED_SECTION_OPTIONS:
+named_conf_start = named_conf_options_start
+named_conf_re = named_conf_options_re
+else:
+raise NotImplementedError('Section %s is not supported' % section)
with open(NAMED_CONF, 'r') as f:
-ipa_section = False
+target_section = False
for line in f:
-if line.startswith('dynamic-db ipa'):
-ipa_section = True
+if line.startswith(named_conf_start):
+target_section = True
continue
if line.startswith('};'):
-if ipa_section:
+if target_section:
break
-if ipa_section:
-match = named_conf_ipa_re.match(line)
+if target_section:
+match = named_conf_re.match(line)
if match and name == match.group('name'):
Re: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master
On 03/12/2013 06:50 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 03/11/2013 05:00 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 03/07/2013 08:27 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 03/06/2013 09:52 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
[...]
On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric
Assignment Plugin,cn=plugins,cn=config is added before the entry
itself.
I didn't test everything as I didn't get the access.
[...]
Gotcha. I moved where the replica acis are loaded.
Thanks! Everything works now, I just found two issues in error reporting.
I set up three masters like this:
$ ipa-replica-manage dnarange-show
vm-084.idm.lab.eng.brq.redhat.com: 1109050002-110909
vm-081.idm.lab.eng.brq.redhat.com: 1109012501-1109024999
vm-079.idm.lab.eng.brq.redhat.com: 1109025001-110904
$ ipa-replica-manage dnanextrange-show
vm-084.idm.lab.eng.brq.redhat.com: 110900-1109012499
vm-081.idm.lab.eng.brq.redhat.com: 110919-1109190001
vm-079.idm.lab.eng.brq.redhat.com: No on-deck range set
vm-079 is git master, the other two have the patch applied.
Now when I deleted vm-081, there was no indication which ranges I lost:
vm-084$ ipa-replica-manage del vm-081.idm.lab.eng.brq.redhat.com
Deleting a master is irreversible.
To reconnect to the remote master you will need to prepare a new replica
file
and re-install.
Continue to delete? [no]: y
Deleting replication agreements between
vm-081.idm.lab.eng.brq.redhat.com and vm-084.idm.lab.eng.brq.redhat.com
ipa: INFO: Setting agreement
cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping
tree,cn=config schedule to 2358-2359 0 to force synch
ipa: INFO: Deleting schedule 2358-2359 0 from agreement
cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping
tree,cn=config
ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica
acquired successfully: Incremental update succeeded: start: 0: end: 0
Unable to remove agreement on vm-081.idm.lab.eng.brq.redhat.com:
Insufficient access: Insufficient 'write' privilege to the
'dnaNextRange' attribute of entry 'cn=posix ids,cn=distributed numeric
assignment plugin,cn=plugins,cn=config'.
Forcing removal on 'vm-084.idm.lab.eng.brq.redhat.com'
Any DNA range on 'vm-081.idm.lab.eng.brq.redhat.com' will be lost
Deleted replication agreement from 'vm-084.idm.lab.eng.brq.redhat.com'
to 'vm-081.idm.lab.eng.brq.redhat.com'
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
Fixed.
One more detail: Ranges where start==end are invalid. We should fail the
same way as for startend.
$ ipa-replica-manage dnanextrange-set vm-081.idm.lab.eng.brq.redhat.com
677100401-677100401
ipa: INFO: Unhandled LDAPError: {'info': 'Changes result in an invalid
DNA configuration.', 'desc': 'Server is unwilling to perform'}
Updating next range failed: Server is unwilling to perform: Changes
result in an invalid DNA configuration.
done
rob
ACK
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 0031-0032] Improve HBAC rule handling in selinuxusermap-add/mod/find
On 02/27/2013 10:28 AM, Martin Kosek wrote:
On 02/20/2013 12:31 PM, Tomas Babej wrote:
On 02/19/2013 10:33 PM, Rob Crittenden wrote:
Tomas Babej wrote:
On 02/06/2013 07:57 PM, Rob Crittenden wrote:
Tomas Babej wrote:
Hi,
this pair of patches improves HBAC rule handling in selinuxusermap
commands.
Patch 0031 deals with:
https://fedorahosted.org/freeipa/ticket/3349
Patch 0032 takes care of:
https://fedorahosted.org/freeipa/ticket/3348
and is to be applied on top of Patch 0031.
See commit messages for detailed info.
Tomas
ACK for patch 0032.
For patch 0031 we can't change the data type of an existing attribute.
It will break backwards compatibility. Can you test with an older
client to see if it cares (it may not care about the name of the
type). If older clients will work then this is probably ok.
I gather that seealso detected as a DN attribute and converted into a
DN class and this is blowing up the Str validator?
Yes, that was exactly the case.
rob
I added a workaround for older client versions, tested it with
freeipa-client/admintools 2.2, works as expeceted.
However, this only should be issue if there is older admintools package
on the client than on the server.
Outline is such as follows: I added a new flag for DNParam seelalso
attribute, called 'allow_malformed' that allows any string to be passed
to DNParam. Its value gets wrapped in 'malformed=yes,value=value'.
This allows to parse out the string in selinuxusermap-add/mod
pre_callback out of the DN and search for the rule with such name so
that it's DN gets in LDAP instead.
Updated patch attached.
Tomas
I like where you're going with this, just a couple of comments:
1. Should we come up with a more universal name for allow_malformed? Is this
something that we should allow at a higher level? I was thinking allow_raw,
or allow_non_dn, or something like that.
To me, allow_non_dn sounds is just as specific as allow_malformed,
they both refer to DN specifically.
I'd go with allow_raw, if need for such pattern may eventually arise for
other parameter classes than DNParam.
What do you mean by higher level, turning this hack into a feature
Param class? I don't see how this would work, each parameter
class that implements its own type validation as DNParam needs
to override _convert_scalar(). And in every such class we would need
to wrap our raw value so that it is represented in the type of this parameter,
as we do with DN(('malformed','yes'),('value',value)) now.
Maybe we could skip type validation in _convert_scalar default
implementation or catch the error raised somehow, and let the type be
invalid, but I'm not aware of the consenquences. I would need to investigate.
Wouldn't it cause failure deeper in the framework?
Or did you by higher level mean simply picking a more general name for the
flag so it can be reused in other parameter classes with the same name?
2. I think that if a bad dn is passed in as a Str the conversion into a DN
won't be handled:
+if 'allow_malformed' in self.flags:
+dn = DN(('malformed','yes'),('value',value))
Should this be wrapped in a try/except to raise a ConversionError if it fails?
Yes, thanks for that catch.
rob
Tomas
Is it just me, or does the 0031 look overengineered? I think this is a general
problem for each Str parameter which we then process/convert to DN in our
pre_callbacks.
selinuxusermap is one example where this does not work. This fix leaves other
examples not working:
# ipa trustconfig-mod --setattr ipantfallbackprimarygroup=cn=Default SMB
Group,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
ipa: ERROR: invalid 'ipantfallbackprimarygroup': must be Unicode text
I would rather propose to not automatically encode DN of known attributes set
by *attr:
diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py
index 1ebbe7a..e4b9834 100644
--- a/ipalib/plugins/baseldap.py
+++ b/ipalib/plugins/baseldap.py
@@ -768,12 +768,6 @@ last, after all sets and adds.),
# None means delete this attribute
value = None
-if ldap.has_dn_syntax(attr):
-try:
-value = DN(value)
-except ValueError:
-raise errors.InvalidSyntax(attr=attr)
-
if attr in newdict:
if type(value) in (tuple,):
newdict[attr] += list(value)
I think this conversion is just done too early as this Str param is processed
and converted later in the pre_callback, when needed. The code above introduced
inconsistent processing of IPA attributes with DN syntax coming from regular
option and from *attr option - Str
When I did this change, both selinuxusermap-mod and trustconfig-mod started
working:
# ipa selinuxusermap-mod foo
--setattr=seealso=ipaUniqueID=70e42636-75db-11e2-9df6-001a4a104edc,cn=hbac,dc=rhel64,dc=ad,dc=test
---
Modified SELinux User Map foo
Re: [Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer password migration
On 03/12/2013 03:34 PM, Petr Viktorin wrote:
On 03/12/2013 01:37 PM, Martin Kosek wrote:
On 03/12/2013 10:10 AM, Petr Viktorin wrote:
On 03/11/2013 02:56 PM, Martin Kosek wrote:
On 03/11/2013 01:48 PM, Jan Cholasta wrote:
On 11.3.2013 13:43, Petr Viktorin wrote:
On 03/11/2013 01:13 PM, Jan Cholasta wrote:
On 8.3.2013 14:14, Petr Viktorin wrote:
On 03/07/2013 05:42 PM, Jan Cholasta wrote:
Patch 191:
The patch is missing the ipapython/ipaldap.py file.
On 7.3.2013 18:29, Petr Viktorin wrote:
It's there, it's just copied from ipaserver/ipaldap.py with a small
change at the bottom.
There is no sign of the file, except in the patch header and the patch
cannot be applied with git am nor with git apply. But perhaps I'm doing
something wrong.
Attaching a re-formatted version of the patch.
[...]
ACK.
Honza
ACK for real.
Honza
I would not want to rush this, I still see errors:
1) ipa-ldap-updater is broken:
# ipa-ldap-updater --upgrade
Upgrading IPA:
[1/8]: stopping directory server
[2/8]: saving configuration
[3/8]: disabling listeners
[4/8]: starting directory server
[5/8]: upgrading server
Upgrade failed with 'NameSpace' object has no attribute 'ldap2'
[6/8]: stopping directory server
[7/8]: restoring configuration
[8/8]: starting directory server
Done.
IPA upgrade failed.
Thanks for the catch!
This is a symptom of the fact the plugins attach themselves to the default
API
object as soon as they're imported.
Before, ipaldap imported ldap2, so the ldap2 server plugin was magically
available whenever ipaldap was imported before.
Now, ldap2 needs to be imported explicitly if api.Backend.ldap2 needs to be
available.
2) What's the purpose of this new error?
+class DatabaseTimeout(DatabaseError):
+
+**4211** Raised when an LDAP call times out
+
+For example:
+
+ raise DatabaseTimeout()
+Traceback (most recent call last):
+ ...
+DatabaseTimeout: LDAP timeout
+
+
+errno = 4211
+format = _('LDAP timeout')
Thanks for this catch too, I mis-squashed the code to raise it.
It is not raised anywhere (as far as I can see). BTW I assume it is not
related to errors.LimitsExceeded in any way, right?
No, it's timeout in the client↔server communication rather than the LDAP
operation. It wraps ldap.TIMEOUT rather than ldap.TIMELIMIT_EXCEEDED.
3) Client installation no longer works if the server has disabled
anonymous authentication:
# ipa-client-install
Error checking LDAP: Inappropriate authentication: Anonymous access is
not allowed.
DNS discovery failed to determine your DNS domain
Provide the domain name of your IPA server (ex: example.com): ^C
I couldn't reproduce this. But I did find some misleading log messages in
this
case. It work well now.
4) I suddenly cannot run some tests, looks like import loop:
# ./make-test tests/test_xmlrpc/test_host_plugin.py
/usr/bin/nosetests -v --with-doctest --doctest-tests --exclude=plugins
tests/test_xmlrpc/test_host_plugin.py
Failure: ImportError (cannot import name ipautil) ... ERROR
==
ERROR: Failure: ImportError (cannot import name ipautil)
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/loader.py, line 390, in
loadTestsFromName
addr.filename, addr.module)
File /usr/lib/python2.7/site-packages/nose/importer.py, line 39, in
importFromPath
return self.importFromDir(dir_path, fqname)
File /usr/lib/python2.7/site-packages/nose/importer.py, line 86, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File /root/freeipa-master/tests/test_xmlrpc/test_host_plugin.py,
line 27, in module
from ipapython import ipautil
File /root/freeipa-master/ipapython/ipautil.py, line 52, in module
from ipalib import errors
File /root/freeipa-master/ipalib/__init__.py, line 930, in module
api.finalize()
File /root/freeipa-master/ipalib/plugable.py, line 674, in finalize
self.__do_if_not_done('load_plugins')
File /root/freeipa-master/ipalib/plugable.py, line 454, in
__do_if_not_done
getattr(self, name)()
File /root/freeipa-master/ipalib/plugable.py, line 613, in
load_plugins
self.import_plugins('ipalib')
File /root/freeipa-master/ipalib/plugable.py, line 655, in
import_plugins
__import__(fullname)
File /root/freeipa-master/ipalib/plugins/cert.py, line 30, in
module
from ipalib import pkcs10
File /root/freeipa-master/ipalib/pkcs10.py, line 24, in module
from ipapython import ipautil
ImportError: cannot import name ipautil
Gasp... I have no idea how we didn't catch this earlier.
Simplifying a bit, it's partly due to the fact that ipalib does a lot of
work
on import in __init__ -- including
Re: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master
On 03/13/2013 11:03 AM, Petr Viktorin wrote:
On 03/12/2013 06:50 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 03/11/2013 05:00 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 03/07/2013 08:27 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 03/06/2013 09:52 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
[...]
On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric
Assignment Plugin,cn=plugins,cn=config is added before the entry
itself.
I didn't test everything as I didn't get the access.
[...]
Gotcha. I moved where the replica acis are loaded.
Thanks! Everything works now, I just found two issues in error reporting.
I set up three masters like this:
$ ipa-replica-manage dnarange-show
vm-084.idm.lab.eng.brq.redhat.com: 1109050002-110909
vm-081.idm.lab.eng.brq.redhat.com: 1109012501-1109024999
vm-079.idm.lab.eng.brq.redhat.com: 1109025001-110904
$ ipa-replica-manage dnanextrange-show
vm-084.idm.lab.eng.brq.redhat.com: 110900-1109012499
vm-081.idm.lab.eng.brq.redhat.com: 110919-1109190001
vm-079.idm.lab.eng.brq.redhat.com: No on-deck range set
vm-079 is git master, the other two have the patch applied.
Now when I deleted vm-081, there was no indication which ranges I lost:
vm-084$ ipa-replica-manage del vm-081.idm.lab.eng.brq.redhat.com
Deleting a master is irreversible.
To reconnect to the remote master you will need to prepare a new replica
file
and re-install.
Continue to delete? [no]: y
Deleting replication agreements between
vm-081.idm.lab.eng.brq.redhat.com and vm-084.idm.lab.eng.brq.redhat.com
ipa: INFO: Setting agreement
cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping
tree,cn=config schedule to 2358-2359 0 to force synch
ipa: INFO: Deleting schedule 2358-2359 0 from agreement
cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping
tree,cn=config
ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica
acquired successfully: Incremental update succeeded: start: 0: end: 0
Unable to remove agreement on vm-081.idm.lab.eng.brq.redhat.com:
Insufficient access: Insufficient 'write' privilege to the
'dnaNextRange' attribute of entry 'cn=posix ids,cn=distributed numeric
assignment plugin,cn=plugins,cn=config'.
Forcing removal on 'vm-084.idm.lab.eng.brq.redhat.com'
Any DNA range on 'vm-081.idm.lab.eng.brq.redhat.com' will be lost
Deleted replication agreement from 'vm-084.idm.lab.eng.brq.redhat.com'
to 'vm-081.idm.lab.eng.brq.redhat.com'
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
Fixed.
One more detail: Ranges where start==end are invalid. We should fail the
same way as for startend.
$ ipa-replica-manage dnanextrange-set vm-081.idm.lab.eng.brq.redhat.com
677100401-677100401
ipa: INFO: Unhandled LDAPError: {'info': 'Changes result in an invalid
DNA configuration.', 'desc': 'Server is unwilling to perform'}
Updating next range failed: Server is unwilling to perform: Changes
result in an invalid DNA configuration.
done
rob
ACK
Btw Rob you will likely need to rebase the patch a bit before pushing as
ipaldap is now in ipapython module (see Petr^3's patches 0191-0195).
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] OID assignment request: new objectClass idnsForwardZone
On Wed, 2013-03-13 at 11:00 +0100, Petr Spacek wrote: Hello list, I would like to obtain new OID for new objectClass idnsForwardZone, as planed in https://fedorahosted.org/bind-dyndb-ldap/ticket/99 . idnsForwardZone is meant as sane subset of existing idnsZone. Currently, IPA uses idnsZone for master and forward zones at the same time. The result of this situation is a mess. Users are forced to fill in non-senses like fake SOA records for forward zones etc. IPAv3 uses OID space 2.16.840.1.113730.3.8.12.x for objectClasses, right? New objectClass proposal: objectClasses: ( 2.16.840.1.113730.3.8.12.x NAME 'idnsForwardZone' DESC 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ idnsZoneActive $ idnsForwarders ) MAY idnsForwardPolicy ) ACK, use 2.16.840.1.113730.3.8.12.19 Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 386 Fix client discovery crash
Client discovery LDAP search assumes that the remote LDAP server will
send an entry with lowercase attribute names. When it discovers for
example on openldap which sends it in CamelCase, the discovery
crashes.
Convert retrieved entry to CIDict to avoid this error. Also add
a fallback to ipa-client-install server discovery process so that
it rather skips the faulty server instead of crashing.
https://fedorahosted.org/freeipa/ticket/3446
---
NOTE: this is just a hotfix for IPA 3.1.x (ipa-3-1 branch). Proper fix was done
by Petr Viktorin (patches 0191-0195).
Martin
From 08803ff63ebd0118ee06b09279d32c38605a4f89 Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Wed, 13 Mar 2013 13:21:11 +0100
Subject: [PATCH] Fix client discovery crash
Client discovery LDAP search assumes that the remote LDAP server will
send an entry with lowercase attribute names. When it discovers for
example on openldap which sends it in CamelCase, the discovery
crashes.
Convert retrieved entry to CIDict to avoid this error. Also add
a fallback to ipa-client-install server discovery process so that
it rather skips the faulty server instead of crashing.
https://fedorahosted.org/freeipa/ticket/3446
---
ipa-client/ipaclient/ipadiscovery.py | 3 +++
ipapython/ipautil.py | 17 +
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/ipa-client/ipaclient/ipadiscovery.py b/ipa-client/ipaclient/ipadiscovery.py
index 7fc6aae88672e15a6bf3068ef8769e4cc80184a4..254d1a965fa77da8ebf1b23808e37b024511983a 100644
--- a/ipa-client/ipaclient/ipadiscovery.py
+++ b/ipa-client/ipaclient/ipadiscovery.py
@@ -404,6 +404,9 @@ class IPADiscovery(object):
root_logger.error(LDAP Error: %s: %s %
(err.args[0]['desc'], err.args[0].get('info', '')))
return [UNKNOWN_ERROR]
+except Exception, e:
+root_logger.error(Error checking LDAP: %s, e)
+return [UNKNOWN_ERROR]
def ipadns_search_srv(self, domain, srv_record_name, default_port,
diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py
index 1c1ce7352b0f2394835f7370a17363acd9b5a3f9..dd42fb4c9d80688cc5ea4bfd5a64d860d37a8a72 100644
--- a/ipapython/ipautil.py
+++ b/ipapython/ipautil.py
@@ -835,13 +835,22 @@ def get_ipa_basedn(conn):
'', scope=ldap.SCOPE_BASE, attrlist=['defaultnamingcontext', 'namingcontexts']
)
-contexts = entries[0][1]['namingcontexts']
-if entries[0][1].get('defaultnamingcontext'):
+# get_ipa_basedn may be used in client discovery and may thus hit other
+# LDAP servers beyond 389-ds. These may not return namingcontexts
+# attribute as lowercase but rather as CamelCase (e.g. openldap server)
+# which could make client discovery to crash.
+# Hotfix this issue by converting LDAP entry to CIDict.
+# Proper fix was pushed in https://fedorahosted.org/freeipa/ticket/3446
+dn, entry = entries[0]
+entry = CIDict(entry)
+
+contexts = entry['namingcontexts']
+if entry.get('defaultnamingcontext'):
# If there is a defaultNamingContext examine that one first
-default = entries[0][1]['defaultnamingcontext'][0]
+default = entry['defaultnamingcontext'][0]
if default in contexts:
contexts.remove(default)
-contexts.insert(0, entries[0][1]['defaultnamingcontext'][0])
+contexts.insert(0, entry['defaultnamingcontext'][0])
for context in contexts:
root_logger.debug(Check if naming context '%s' is for IPA % context)
try:
--
1.8.1.4
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0040] Make sure uninstall script prompts for reboot as last
Hi,
Parts of client uninstall logic could be skipped in attended
uninstallation if user agreed to reboot the machine. Particulary,
the uninstall script would not try to remove /etc/ipa/default.conf
and therefore subsequent installation would fail, client being
detected as already configured.
https://fedorahosted.org/freeipa/ticket/3462
Tomas
From 465e5c01a760fb99c43658a0aa97abdec169882c Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 13 Mar 2013 12:53:24 +0100
Subject: [PATCH] Make sure uninstall script prompts for reboot as last
Parts of client uninstall logic could be skipped in attended
uninstallation if user agreed to reboot the machine. Particulary,
the uninstall script would not try to remove /etc/ipa/default.conf
and therefore subsequent installation would fail, client being
detected as already configured.
https://fedorahosted.org/freeipa/ticket/3462
---
ipa-client/ipa-install/ipa-client-install | 54 ---
1 file changed, 35 insertions(+), 19 deletions(-)
diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index 4433fc7175a7d565538fa7f3a681a36c0f91dc09..97332d1a02e4e78c648d02501c6055c0618ae1c7 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -611,41 +611,57 @@ def uninstall(options, env):
if was_sshd_configured and ipaservices.knownservices.sshd.is_running():
ipaservices.knownservices.sshd.restart()
-if not options.unattended:
-root_logger.info(
-The original nsswitch.conf configuration has been restored.)
-root_logger.info(
-You may need to restart services or reboot the machine.)
-if not options.on_master:
-if user_input(Do you want to reboot the machine?, False):
-try:
-run([/sbin/reboot])
-except Exception, e:
-root_logger.error(
-Reboot command failed to exceute: %s, str(e))
-return CLIENT_UNINSTALL_ERROR
-
rv = 0
if fstore.has_files():
-root_logger.error('Some files have not been restored, see /var/lib/ipa-client/sysrestore/sysrestore.index')
+root_logger.error('Some files have not been restored, see '
+ '/var/lib/ipa-client/sysrestore/sysrestore.index')
has_state = False
for module in statestore.modules.keys():
-root_logger.error('Some installation state for %s has not been restored, see /var/lib/ipa/sysrestore/sysrestore.state' % module)
+root_logger.error('Some installation state for %s has not been '
+'restored, see /var/lib/ipa/sysrestore/sysrestore.state',
+module)
has_state = True
rv = 1
if has_state:
-root_logger.warning('Some installation state has not been restored.\nThis may cause re-installation to fail.\nIt should be safe to remove /var/lib/ipa-client/sysrestore.state but it may\nmean your system hasn\'t be restored to its pre-installation state.')
+root_logger.warning(
+'Some installation state has not been restored.\n'
+'This may cause re-installation to fail.\n'
+'It should be safe to remove /var/lib/ipa-client/sysrestore.state '
+'but it may\n mean your system hasn\'t been restored '
+'to its pre-installation state.')
# Remove the IPA configuration file
try:
os.remove(/etc/ipa/default.conf)
-except Exception:
-pass
+except OSError, e:
+root_logger.warning('/etc/ipa/default.conf could not be removed: %s',
+str(e))
+root_logger.warning('Please remove /etc/ipa/default.conf manually, '
+'as it can cause subsequent installation to fail.')
root_logger.info(Client uninstall complete.)
+# The next block of code prompts for reboot, therefore all uninstall
+# logic has to be done before
+
+if not options.unattended:
+root_logger.info(
+The original nsswitch.conf configuration has been restored.)
+root_logger.info(
+You may need to restart services or reboot the machine.)
+if not options.on_master:
+if user_input(Do you want to reboot the machine?, False):
+try:
+run([/sbin/reboot])
+except Exception, e:
+root_logger.error(
+Reboot command failed to exceute: %s, str(e))
+return CLIENT_UNINSTALL_ERROR
+
+# IMPORTANT: Do not put any client uninstall logic after the block above
+
return rv
def configure_ipa_conf(fstore, cli_basedn, cli_realm, cli_domain, cli_server):
--
1.7.11.7
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
Re: [Freeipa-devel] [PATCH] 381, 386 Preserve order of servers in ipa-client-install
On 03/11/2013 12:40 PM, Martin Kosek wrote: On 03/07/2013 03:07 PM, Petr Viktorin wrote: On 03/07/2013 02:00 PM, Martin Kosek wrote: When multiple servers are passed via --server option, ipadiscovery module changed its order. Make sure that we preserve it. Also make sure that user is always warned when a tested server is not available as then the server will be excluded from the fixed server list. The message doesn't actually say that the server will be removed. It would be nice if it did. Otherwise, ACK. Sending a patch with improved logging. User should now be more clear what server is failing to verify (and why). -- When working on this ticket I was thinking - do we make the right thing we deliberately remove a server from user-provided server list just because we cannot connect to it at the moment if discovery? It may just be temporarily down or something. Maybe we should preserve the original --server list in this case and use this list when writing krb5.conf or sssd.conf. Of course, for ipa-join or other active configuration commands we would have to use only the valid servers so that the we do not hit the server that is currently down. Martin Good point, this deserves a ticket. Rob, do you think this deserves to be changed? Or is this behavior indeed intended? Martin Sending a rebased patch 381, logging was also improved. Client discovery logging now looks like that: # ipa-client-install Skip vm-024.idm.lab.bos.redhat.com: not an IPA server Skip doesnotexist.test: cannot verify if this is an IPA server Discovery was successful! Hostname: vm-148.idm.lab.bos.redhat.com Realm: IDM.LAB.BOS.REDHAT.COM DNS Domain: idm.lab.bos.redhat.com IPA Server: vm-037.idm.lab.bos.redhat.com BaseDN: dc=idm,dc=lab,dc=bos,dc=redhat,dc=com Continue to configure the system with these values? [no]: ... I also attached a related fix for redundant discoveries with fixed server list (found that when testing logging), details are in the patch description. Martin From a7a6d66e5f85f3a7bce4acdd78a1a144451c717a Mon Sep 17 00:00:00 2001 From: Martin Kosek mko...@redhat.com Date: Wed, 13 Mar 2013 14:42:12 +0100 Subject: [PATCH 1/2] Preserve order of servers in ipa-client-install When multiple servers are passed via --server option, ipadiscovery module changed its order. Make sure that we preserve it. Also make sure that user is always warned when a tested server is not available as then the server will be excluded from the fixed server list. Log messages were made more informative so that user knows which server is actually failing to be verified. https://fedorahosted.org/freeipa/ticket/3418 --- ipa-client/ipaclient/ipadiscovery.py | 21 - 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/ipa-client/ipaclient/ipadiscovery.py b/ipa-client/ipaclient/ipadiscovery.py index 6ae9616def818642c6fdf88eb93b860befa19afd..9a58b967857a374809b2a85294010eb2f7f688a5 100644 --- a/ipa-client/ipaclient/ipadiscovery.py +++ b/ipa-client/ipaclient/ipadiscovery.py @@ -246,7 +246,7 @@ class IPADiscovery(object): self.realm = ldapret[2] self.server_source = self.realm_source = ( 'Discovered from LDAP DNS records in %s' % self.server) -valid_servers.insert(0, server) +valid_servers.append(server) # verified, we actually talked to the remote server and it # is definetely an IPA server verified_servers = True @@ -256,7 +256,7 @@ class IPADiscovery(object): break elif ldapret[0] == NO_ACCESS_TO_LDAP or ldapret[0] == NO_TLS_LDAP: ldapaccess = False -valid_servers.insert(0, server) +valid_servers.append(server) # we may set verified_servers below, we don't have it yet if autodiscovered: # No need to keep verifying servers if we discovered them @@ -264,11 +264,14 @@ class IPADiscovery(object): break elif ldapret[0] == NOT_IPA_SERVER: root_logger.warn( -'%s (realm %s) is not an IPA server', server, self.realm) + 'Skip %s: not an IPA server', server) elif ldapret[0] == NO_LDAP_SERVER: -root_logger.debug( -'Unable to verify that %s (realm %s) is an IPA server', -server, self.realm) +root_logger.warn( + 'Skip %s: LDAP server is not responding, unable to verify if ' + 'this is an IPA server', server) +else: +root_logger.warn( + 'Skip %s: cannot verify if this is an IPA server', server) # If one of LDAP servers checked rejects access (maybe anonymous # bind is disabled), assume realm and basedn generated off domain. @@
[Freeipa-devel] [PATCH 0041] Add logging to join command
Hi,
The following is mentioned in the server log now:
- existence of host entry (if it already does exist)
- missing krbprincipalname and its new value (if there was no
principal name set)
https://fedorahosted.org/freeipa/ticket/3481
Tomas
From 6e2ec40056f65aa75b761e752942f70f823a7736 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 13 Mar 2013 14:47:03 +0100
Subject: [PATCH] Add logging to join command
The following is mentioned in the log now:
- existence of host entry (if it already does exist)
- missing krbprincipalname and its new value (if there was no
principal name set)
https://fedorahosted.org/freeipa/ticket/3481
---
ipaserver/plugins/join.py | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/ipaserver/plugins/join.py b/ipaserver/plugins/join.py
index 6ea02b2e1b7105c7865602c601f11231dd2b64b1..86d6674c10add529e7e2ca04cc588a1b50004655 100644
--- a/ipaserver/plugins/join.py
+++ b/ipaserver/plugins/join.py
@@ -23,12 +23,13 @@ Joining an IPA domain
import krbV
-from ipalib import api, util
+from ipalib import api
from ipalib import Command, Str
from ipalib import errors
from ipalib import _
from ipaserver.install import installutils
+
def get_realm():
Returns the default kerberos realm configured for this server.
@@ -37,6 +38,7 @@ def get_realm():
return unicode(krbctx.default_realm)
+
def validate_host(ugettext, cn):
Require at least one dot in the hostname (to support localhost.localdomain)
@@ -46,6 +48,7 @@ def validate_host(ugettext, cn):
return 'Fully-qualified hostname required'
return None
+
class join(Command):
Join an IPA domain
@@ -59,7 +62,8 @@ class join(Command):
#normalizer=lamda value: value.lower(),
),
)
-takes_options= (
+
+takes_options = (
Str('realm',
doc=_(The IPA realm),
default_from=lambda: get_realm(),
@@ -90,33 +94,41 @@ class join(Command):
assert 'cn' not in kw
ldap = self.api.Backend.ldap2
-host = None
try:
# First see if the host exists
kw = {'fqdn': hostname, 'all': True}
attrs_list = api.Command['host_show'](**kw)['result']
dn = attrs_list['dn']
+# No error raised so far means that host entry exists
+self.log.info('Host entry for %s already exists', hostname)
+
# If no principal name is set yet we need to try to add
# one.
if 'krbprincipalname' not in attrs_list:
service = host/%s@%s % (hostname, api.env.realm)
api.Command['host_mod'](hostname, krbprincipalname=service)
+self.log.info('No principal set, setting to %s', service)
# It exists, can we write the password attributes?
allowed = ldap.can_write(dn, 'krblastpwdchange')
if not allowed:
-raise errors.ACIError(info=_(Insufficient 'write' privilege to the 'krbLastPwdChange' attribute of entry '%s'.) % dn)
+raise errors.ACIError(info=_(Insufficient 'write' privilege
+to the 'krbLastPwdChange' attribute of entry '%s'.) % dn)
+# Reload the attrs_list and dn so that we return update values
kw = {'fqdn': hostname, 'all': True}
attrs_list = api.Command['host_show'](**kw)['result']
dn = attrs_list['dn']
+
except errors.NotFound:
-attrs_list = api.Command['host_add'](hostname, force=True)['result']
+attrs_list = api.Command['host_add'](hostname,
+ force=True)['result']
dn = attrs_list['dn']
config = api.Command['config_show']()['result']
-attrs_list['ipacertificatesubjectbase'] = config['ipacertificatesubjectbase']
+attrs_list['ipacertificatesubjectbase'] =\
+config['ipacertificatesubjectbase']
return (dn, attrs_list)
--
1.7.11.7
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 381, 387 Preserve order of servers in ipa-client-install
On 03/13/2013 02:58 PM, Martin Kosek wrote: On 03/11/2013 12:40 PM, Martin Kosek wrote: On 03/07/2013 03:07 PM, Petr Viktorin wrote: On 03/07/2013 02:00 PM, Martin Kosek wrote: When multiple servers are passed via --server option, ipadiscovery module changed its order. Make sure that we preserve it. Also make sure that user is always warned when a tested server is not available as then the server will be excluded from the fixed server list. The message doesn't actually say that the server will be removed. It would be nice if it did. Otherwise, ACK. Sending a patch with improved logging. User should now be more clear what server is failing to verify (and why). -- When working on this ticket I was thinking - do we make the right thing we deliberately remove a server from user-provided server list just because we cannot connect to it at the moment if discovery? It may just be temporarily down or something. Maybe we should preserve the original --server list in this case and use this list when writing krb5.conf or sssd.conf. Of course, for ipa-join or other active configuration commands we would have to use only the valid servers so that the we do not hit the server that is currently down. Martin Good point, this deserves a ticket. Rob, do you think this deserves to be changed? Or is this behavior indeed intended? Martin Sending a rebased patch 381, logging was also improved. Client discovery logging now looks like that: # ipa-client-install Skip vm-024.idm.lab.bos.redhat.com: not an IPA server Skip doesnotexist.test: cannot verify if this is an IPA server Discovery was successful! Hostname: vm-148.idm.lab.bos.redhat.com Realm: IDM.LAB.BOS.REDHAT.COM DNS Domain: idm.lab.bos.redhat.com IPA Server: vm-037.idm.lab.bos.redhat.com BaseDN: dc=idm,dc=lab,dc=bos,dc=redhat,dc=com Continue to configure the system with these values? [no]: ... I also attached a related fix for redundant discoveries with fixed server list (found that when testing logging), details are in the patch description. Martin I just creating a conflict in my patch numbering, renaming 386 to 387... Martin From a7a6d66e5f85f3a7bce4acdd78a1a144451c717a Mon Sep 17 00:00:00 2001 From: Martin Kosek mko...@redhat.com Date: Wed, 13 Mar 2013 14:42:12 +0100 Subject: [PATCH 1/2] Preserve order of servers in ipa-client-install When multiple servers are passed via --server option, ipadiscovery module changed its order. Make sure that we preserve it. Also make sure that user is always warned when a tested server is not available as then the server will be excluded from the fixed server list. Log messages were made more informative so that user knows which server is actually failing to be verified. https://fedorahosted.org/freeipa/ticket/3418 --- ipa-client/ipaclient/ipadiscovery.py | 21 - 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/ipa-client/ipaclient/ipadiscovery.py b/ipa-client/ipaclient/ipadiscovery.py index 6ae9616def818642c6fdf88eb93b860befa19afd..9a58b967857a374809b2a85294010eb2f7f688a5 100644 --- a/ipa-client/ipaclient/ipadiscovery.py +++ b/ipa-client/ipaclient/ipadiscovery.py @@ -246,7 +246,7 @@ class IPADiscovery(object): self.realm = ldapret[2] self.server_source = self.realm_source = ( 'Discovered from LDAP DNS records in %s' % self.server) -valid_servers.insert(0, server) +valid_servers.append(server) # verified, we actually talked to the remote server and it # is definetely an IPA server verified_servers = True @@ -256,7 +256,7 @@ class IPADiscovery(object): break elif ldapret[0] == NO_ACCESS_TO_LDAP or ldapret[0] == NO_TLS_LDAP: ldapaccess = False -valid_servers.insert(0, server) +valid_servers.append(server) # we may set verified_servers below, we don't have it yet if autodiscovered: # No need to keep verifying servers if we discovered them @@ -264,11 +264,14 @@ class IPADiscovery(object): break elif ldapret[0] == NOT_IPA_SERVER: root_logger.warn( -'%s (realm %s) is not an IPA server', server, self.realm) + 'Skip %s: not an IPA server', server) elif ldapret[0] == NO_LDAP_SERVER: -root_logger.debug( -'Unable to verify that %s (realm %s) is an IPA server', -server, self.realm) +root_logger.warn( + 'Skip %s: LDAP server is not responding, unable to verify if ' + 'this is an IPA server', server) +else: +root_logger.warn( + 'Skip %s: cannot verify if this is an IPA server', server)
Re: [Freeipa-devel] [PATCH] 1088 Recover DNA ranges when deleting a master
Martin Kosek wrote:
On 03/13/2013 11:03 AM, Petr Viktorin wrote:
On 03/12/2013 06:50 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 03/11/2013 05:00 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 03/07/2013 08:27 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
On 03/06/2013 09:52 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
[...]
On new installs, the ACI on cn=Posix IDs,cn=Distributed Numeric
Assignment Plugin,cn=plugins,cn=config is added before the entry
itself.
I didn't test everything as I didn't get the access.
[...]
Gotcha. I moved where the replica acis are loaded.
Thanks! Everything works now, I just found two issues in error reporting.
I set up three masters like this:
$ ipa-replica-manage dnarange-show
vm-084.idm.lab.eng.brq.redhat.com: 1109050002-110909
vm-081.idm.lab.eng.brq.redhat.com: 1109012501-1109024999
vm-079.idm.lab.eng.brq.redhat.com: 1109025001-110904
$ ipa-replica-manage dnanextrange-show
vm-084.idm.lab.eng.brq.redhat.com: 110900-1109012499
vm-081.idm.lab.eng.brq.redhat.com: 110919-1109190001
vm-079.idm.lab.eng.brq.redhat.com: No on-deck range set
vm-079 is git master, the other two have the patch applied.
Now when I deleted vm-081, there was no indication which ranges I lost:
vm-084$ ipa-replica-manage del vm-081.idm.lab.eng.brq.redhat.com
Deleting a master is irreversible.
To reconnect to the remote master you will need to prepare a new replica
file
and re-install.
Continue to delete? [no]: y
Deleting replication agreements between
vm-081.idm.lab.eng.brq.redhat.com and vm-084.idm.lab.eng.brq.redhat.com
ipa: INFO: Setting agreement
cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping
tree,cn=config schedule to 2358-2359 0 to force synch
ipa: INFO: Deleting schedule 2358-2359 0 from agreement
cn=meTovm-084.idm.lab.eng.brq.redhat.com,cn=replica,cn=dc\=idm\,dc\=lab\,dc\=eng\,dc\=brq\,dc\=redhat\,dc\=com,cn=mapping
tree,cn=config
ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica
acquired successfully: Incremental update succeeded: start: 0: end: 0
Unable to remove agreement on vm-081.idm.lab.eng.brq.redhat.com:
Insufficient access: Insufficient 'write' privilege to the
'dnaNextRange' attribute of entry 'cn=posix ids,cn=distributed numeric
assignment plugin,cn=plugins,cn=config'.
Forcing removal on 'vm-084.idm.lab.eng.brq.redhat.com'
Any DNA range on 'vm-081.idm.lab.eng.brq.redhat.com' will be lost
Deleted replication agreement from 'vm-084.idm.lab.eng.brq.redhat.com'
to 'vm-081.idm.lab.eng.brq.redhat.com'
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
Fixed.
One more detail: Ranges where start==end are invalid. We should fail the
same way as for startend.
$ ipa-replica-manage dnanextrange-set vm-081.idm.lab.eng.brq.redhat.com
677100401-677100401
ipa: INFO: Unhandled LDAPError: {'info': 'Changes result in an invalid
DNA configuration.', 'desc': 'Server is unwilling to perform'}
Updating next range failed: Server is unwilling to perform: Changes
result in an invalid DNA configuration.
done
rob
ACK
Btw Rob you will likely need to rebase the patch a bit before pushing as
ipaldap is now in ipapython module (see Petr^3's patches 0191-0195).
Martin
Yup, was actually the least painful merge I've done in a while :-)
pushed to master
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0040] Make sure uninstall script prompts for reboot as last
On 03/13/2013 02:34 PM, Tomas Babej wrote: Hi, Parts of client uninstall logic could be skipped in attended uninstallation if user agreed to reboot the machine. Particulary, the uninstall script would not try to remove /etc/ipa/default.conf and therefore subsequent installation would fail, client being detected as already configured. https://fedorahosted.org/freeipa/ticket/3462 Tomas ACK. Pushed to master, ipa-3-1. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0039] Enforce exact SID match when adding or modifying a ID range
On 03/13/2013 09:50 AM, Tomas Babej wrote:
On Wed 13 Mar 2013 09:47:09 AM CET, Tomas Babej wrote:
Hi,
SID validation in idrange.py now enforces exact match on SIDs, thus
one can no longer use SID of an object in a trusted domain as a
trusted domain SID.
https://fedorahosted.org/freeipa/ticket/3432
Tomas
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Just renamed the patch filename to follow the convention.
Tomas
I do not think that the debug message is needed:
+root_logger.error('No trusted domain with given SID found, '
+ 'listing SIDS for all the trusted domains:')
+for domain in self._domains:
+root_logger.error('SID: %s' % self._domains[domain][1])
User will not see it anyway and he can easily get list of SIDs/domains with
ipa trust-find.
Otherwise the patch looks and works fine. I would just consider renaming the
method from is_trusted_sid_valid_domain to is_trusted_domain_sid_valid. Sounds
better to me, but I have no strong feelings about that.
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 0031-0032] Improve HBAC rule handling in selinuxusermap-add/mod/find
On 03/13/2013 12:28 PM, Tomas Babej wrote:
On 02/27/2013 10:28 AM, Martin Kosek wrote:
On 02/20/2013 12:31 PM, Tomas Babej wrote:
On 02/19/2013 10:33 PM, Rob Crittenden wrote:
Tomas Babej wrote:
On 02/06/2013 07:57 PM, Rob Crittenden wrote:
Tomas Babej wrote:
Hi,
this pair of patches improves HBAC rule handling in selinuxusermap
commands.
Patch 0031 deals with:
https://fedorahosted.org/freeipa/ticket/3349
Patch 0032 takes care of:
https://fedorahosted.org/freeipa/ticket/3348
and is to be applied on top of Patch 0031.
See commit messages for detailed info.
Tomas
ACK for patch 0032.
For patch 0031 we can't change the data type of an existing attribute.
It will break backwards compatibility. Can you test with an older
client to see if it cares (it may not care about the name of the
type). If older clients will work then this is probably ok.
I gather that seealso detected as a DN attribute and converted into a
DN class and this is blowing up the Str validator?
Yes, that was exactly the case.
rob
I added a workaround for older client versions, tested it with
freeipa-client/admintools 2.2, works as expeceted.
However, this only should be issue if there is older admintools package
on the client than on the server.
Outline is such as follows: I added a new flag for DNParam seelalso
attribute, called 'allow_malformed' that allows any string to be passed
to DNParam. Its value gets wrapped in 'malformed=yes,value=value'.
This allows to parse out the string in selinuxusermap-add/mod
pre_callback out of the DN and search for the rule with such name so
that it's DN gets in LDAP instead.
Updated patch attached.
Tomas
I like where you're going with this, just a couple of comments:
1. Should we come up with a more universal name for allow_malformed? Is
this
something that we should allow at a higher level? I was thinking allow_raw,
or allow_non_dn, or something like that.
To me, allow_non_dn sounds is just as specific as allow_malformed,
they both refer to DN specifically.
I'd go with allow_raw, if need for such pattern may eventually arise for
other parameter classes than DNParam.
What do you mean by higher level, turning this hack into a feature
Param class? I don't see how this would work, each parameter
class that implements its own type validation as DNParam needs
to override _convert_scalar(). And in every such class we would need
to wrap our raw value so that it is represented in the type of this
parameter,
as we do with DN(('malformed','yes'),('value',value)) now.
Maybe we could skip type validation in _convert_scalar default
implementation or catch the error raised somehow, and let the type be
invalid, but I'm not aware of the consenquences. I would need to
investigate.
Wouldn't it cause failure deeper in the framework?
Or did you by higher level mean simply picking a more general name for the
flag so it can be reused in other parameter classes with the same name?
2. I think that if a bad dn is passed in as a Str the conversion into a DN
won't be handled:
+if 'allow_malformed' in self.flags:
+dn = DN(('malformed','yes'),('value',value))
Should this be wrapped in a try/except to raise a ConversionError if it
fails?
Yes, thanks for that catch.
rob
Tomas
Is it just me, or does the 0031 look overengineered? I think this is a
general
problem for each Str parameter which we then process/convert to DN in our
pre_callbacks.
selinuxusermap is one example where this does not work. This fix leaves other
examples not working:
# ipa trustconfig-mod --setattr ipantfallbackprimarygroup=cn=Default SMB
Group,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
ipa: ERROR: invalid 'ipantfallbackprimarygroup': must be Unicode text
I would rather propose to not automatically encode DN of known attributes set
by *attr:
diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py
index 1ebbe7a..e4b9834 100644
--- a/ipalib/plugins/baseldap.py
+++ b/ipalib/plugins/baseldap.py
@@ -768,12 +768,6 @@ last, after all sets and adds.),
# None means delete this attribute
value = None
-if ldap.has_dn_syntax(attr):
-try:
-value = DN(value)
-except ValueError:
-raise errors.InvalidSyntax(attr=attr)
-
if attr in newdict:
if type(value) in (tuple,):
newdict[attr] += list(value)
I think this conversion is just done too early as this Str param is processed
and converted later in the pre_callback, when needed. The code above
introduced
inconsistent processing of IPA attributes with DN syntax coming from regular
option and from *attr option - Str
When I did this change, both selinuxusermap-mod and trustconfig-mod started
working:
# ipa selinuxusermap-mod foo
Re: [Freeipa-devel] [PATCH] 376-377, 385 Use tkey-gssapi-keytab in named.conf
Martin Kosek wrote:
On 03/11/2013 09:39 AM, Petr Spacek wrote:
On 11.3.2013 09:09, Martin Kosek wrote:
On 03/08/2013 09:49 AM, Petr Spacek wrote:
On 8.3.2013 00:14, Rob Crittenden wrote:
Martin Kosek wrote:
Remove obsolete BIND GSSAPI configuration options tkey-gssapi-credential
and tkey-domain and replace them with tkey-gssapi-keytab which avoids
unnecessary Kerberos checks on BIND startup and can cause issues when
KDC is not available.
Both new and current IPA installations are updated.
https://fedorahosted.org/freeipa/ticket/3429
Still reviewing this but I noticed that after upgrading my 3.1.99 server
pre-patch to with with-patch version the connections argument in named.conf
got set to 4 (courtesy of ipa-upgradeconfig). Should we be setting that to 4
during the initial install too?
For 3.2 it doesn't matter. Anything = 2 should be okay, but more connections
should not harm.
Higher value should allow higher level of parallelism, it is one of tuning
parameters. Value 4 was necessary to prevent deadlocks in some previous
versions of bind-dyndb-ldap.
Previously, when I implemented the upgrade script, I set connections arg only
if it was present in named.conf and thus bind-dyndb-ldap could not use a
reasonable default on its own decision.
This was changed in e578183ea25a40aedf6dcc3e1ee4bcb19b73e70f and connections
is set always. Rob is correct, that in that case we might want to add it to
named.conf by default to make it consistent... or we could also fix upgrade
script to change connections only if it is present in named.conf.
Petr, what does make more sense bind-dyndb-ldap wise?
Default values should work. Personally I would include only override values
in named.conf, but technically it doesn't matter.
Note: Latest bind-dyndb-ldap versions refuse to start if configuration is
insane. Fatal error will point admin to errors in configuration and should
prevent surprises from auto-magically changed values.
Invalid configurations - examples:
connections 1
connections 2 psearch is enabled
serial_autoincrement enabled psearch disabled
Ok, lets set the connections argument only if it is in named.conf _and_ it is
lower than the required minimum. All patches attached.
Martin
This works ok if the format of named.conf is stable.
If, for example, there are extra spaces between options and { then the
values are not updated. This is nothing new with this patch, our
previous code was also space dependent (augeas will address this eventually)
I just wonder: Should we log if a warning if a change has not been applied?
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 383 Use new 389-ds-base cleartext password API
Martin Kosek wrote: The way how unhashed password is stored in the entry was changed in 389-ds-base-1.3.0, it is now stored in an entry extension rather than in a magic attribute unhashed#user#password. New API using an entry extension was introduced. ipa-pwd-extop should take advantage of the new API as the old one will be removed in 389-ds-base-1.3.1. https://fedorahosted.org/freeipa/ticket/3439 --- This patch is based on Noriko's candidate patch in 389-ds-base ticket. I tested various password scenarios including migration of users with cleartext/hashed passwords, everything worked OK. ACK, pushed to master rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 382 Do not hide idrange-add errors when adding trust
Martin Kosek wrote: We catched all errors that could be raised by idrange-add command and just raised an uncomprehensible ValidationError. This could hide a real underlying problem and make the debugging harder. We should rather just let the command raise the real error (which will be already a PublicError). https://fedorahosted.org/freeipa/ticket/3288 --- NOTE: I discussed this issue with tsunamie (ticket logger). He hit this error in some early FreeIPA 3.0 release and he does not hit it any more. I also did not reproduce it with current master so I am just sending a patch to allow us/user to see the reason of the range error in case it occurs again. Martin Seems reasonable to me. I wasn't able to reproduce this either and it makes sense to just raise whatever ValidationErrors were discovered. ACK. Pushed to master rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
