Re: [Freeipa-devel] [PATCH] 937 configure /etc/openldap/ldap.conf
On Tue, 2012-01-31 at 23:25 -0500, Rob Crittenden wrote: Configure the openldap configuration file with the basics for IPA. This is mostly to make querying with StartTLS easier but it does make ldapsearch a lot nicer in general. I got a little carried away with the man page. I wanted to include that we were updating yet another configuration file and found no FILES section at all so I added one. I think I caught every file we update, it is the bulk in any case. rob Works fine. ACK if you add missing /etc/krb5.conf to the new FILES section. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 937 configure /etc/openldap/ldap.conf
On Tue, 2012-01-31 at 23:25 -0500, Rob Crittenden wrote: Configure the openldap configuration file with the basics for IPA. This is mostly to make querying with StartTLS easier but it does make ldapsearch a lot nicer in general. I got a little carried away with the man page. I wanted to include that we were updating yet another configuration file and found no FILES section at all so I added one. I think I caught every file we update, it is the bulk in any case. Ack Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 344 Added icons for status column.
On 01/31/2012 05:29 PM, Endi Sukma Dewata wrote: The status formatter was modified to show enabled/disabled icon before the status text. The format classes were renamed to formatter to avoid confusion with the format() method. A new parameter 'type' was added to the formatter to determine the output type (e.g. text/html). Ticket #1996 ACK, pushed to master, ipa-2-2 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 345 Hide Add/Delete buttons in self-service mode.
On 01/31/2012 06:50 PM, Endi Sukma Dewata wrote: Users do not have add/delete permission in self-service mode, so the search facet was modified to hide the Add/Delete buttons. Ticket #2188 ACK, pushed to master, ipa-2-2 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 346 Use fixed font when displaying certificate.
On 01/31/2012 06:51 PM, Endi Sukma Dewata wrote: The textareas used to display certificates were modified to use fixed font. Ticket #2017 ACK, pushed to master, ipa-2-2 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 347 Show password expiration date.
On 01/31/2012 09:45 PM, Endi Sukma Dewata wrote: The user details page was modified to show the password expiration date next to the existing password field. Fixed problem resetting password in self-service mode. The JSON interface for the passwd command requires the username to be specified although the equivalent CLI command doesn't require it. Ticket #2064 ACK, pushed to master, ipa-2-2 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 204 Improve netgroup-add error messages
These two situations in netgroup-add need to be distinguished:
1) Netgroup cannot be added because a hostgroup with the same name
created a colliding managed netgroup
2) Another native netgroup with the same name exists
This patch checks the colliding netgroup and raise appropriate
error message based on this finding.
https://fedorahosted.org/freeipa/ticket/2069
From 1ea7d945cfcfddc71c5b12bc9c724e6f71704f53 Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Wed, 1 Feb 2012 16:33:54 +0100
Subject: [PATCH] Improve netgroup-add error messages
These two situations in netgroup-add need to be distinguished:
1) Netgroup cannot be added because a hostgroup with the same name
created a colliding managed netgroup
2) Another native netgroup with the same name exists
This patch checks the colliding netgroup and raise appropriate
error message based on this finding.
https://fedorahosted.org/freeipa/ticket/2069
---
ipalib/plugins/netgroup.py | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/ipalib/plugins/netgroup.py b/ipalib/plugins/netgroup.py
index d8c3c4707a1f8a657ba2cc82aa94173147953b04..149936dc4fc09ac7a796c8c55bed6caaf23abb76 100644
--- a/ipalib/plugins/netgroup.py
+++ b/ipalib/plugins/netgroup.py
@@ -143,13 +143,20 @@ class netgroup_add(LDAPCreate):
has_output_params = LDAPCreate.has_output_params + output_params
msg_summary = _('Added netgroup %(value)s')
+
+msg_collision = _(u'hostgroup with name %s already exists. ' \
+ u'Hostgroups and netgroups share a common namespace')
+
def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options):
entry_attrs.setdefault('nisdomainname', self.api.env.domain)
try:
-# check duplicity with netgroups first to provide proper error
-netgroup = api.Command['netgroup_show'](keys[-1])
-self.obj.handle_duplicate_entry(*keys)
+dn = self.obj.get_dn(keys[-1])
+(dn_, netgroup) = ldap.get_entry(dn, ['objectclass'])
+if 'mepManagedEntry' in netgroup.get('objectclass', []):
+raise errors.DuplicateEntry(message=unicode(self.msg_collision % keys[-1]))
+else:
+self.obj.handle_duplicate_entry(*keys)
except errors.NotFound:
pass
@@ -158,10 +165,7 @@ class netgroup_add(LDAPCreate):
# make sure that we don't create a collision if the plugin is
# (temporarily) disabled
netgroup = api.Command['hostgroup_show'](keys[-1])
-raise errors.DuplicateEntry(message=unicode(_(\
-u'hostgroup with name %s already exists. ' \
-u'Hostgroups and netgroups share a common namespace'\
-) % keys[-1]))
+raise errors.DuplicateEntry(message=unicode(self.msg_collision % keys[-1]))
except errors.NotFound:
pass
--
1.7.7.6
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 205 Remove UDP checks from conncheck
UDP port checks in ipa-replica-conncheck always returns OK even if they are closed by firewall. They cannot be reliably checked in the same way as TCP ports as there is no session management as in TCP protocol. We cannot guarantee a response on the checked side without our own echo server bound to checked port. This patch removes UDP port checks altogether so that user gets a consistent conncheck report without confusing UDP results. https://fedorahosted.org/freeipa/ticket/2062 From 60042e2ae7d5857ea355895bedab988687554f97 Mon Sep 17 00:00:00 2001 From: Martin Kosek mko...@redhat.com Date: Wed, 1 Feb 2012 17:12:17 +0100 Subject: [PATCH] Remove UDP checks from conncheck UDP port checks in ipa-replica-conncheck always returns OK even if they are closed by firewall. They cannot be reliably checked in the same way as TCP ports as there is no session management as in TCP protocol. We cannot guarantee a response on the checked side without our own echo server bound to checked port. This patch removes UDP port checks altogether so that user gets a consistent conncheck report without confusing UDP results. https://fedorahosted.org/freeipa/ticket/2062 --- install/tools/ipa-replica-conncheck | 31 ++- 1 files changed, 14 insertions(+), 17 deletions(-) diff --git a/install/tools/ipa-replica-conncheck b/install/tools/ipa-replica-conncheck index 2622130e7c6f6ceabe6ff8a17e89412089897c5f..2a6651416f7a8b19d8def2b3b2e7e089cf3efcb6 100755 --- a/install/tools/ipa-replica-conncheck +++ b/install/tools/ipa-replica-conncheck @@ -42,24 +42,21 @@ CCACHE_FILE = /etc/ipa/.conncheck_ccache KRB5_CONFIG = None class CheckedPort(object): -def __init__(self, port, stream, description): +def __init__(self, port, description): self.port = port -self.stream = stream self.description = description BASE_PORTS = [ -CheckedPort(389, True, Directory Service: Unsecure port), -CheckedPort(636, True, Directory Service: Secure port), -CheckedPort(88, True, Kerberos KDC: TCP), -CheckedPort(88, False, Kerberos KDC: UDP), -CheckedPort(464, True, Kerberos Kpasswd: TCP), -CheckedPort(464, False, Kerberos Kpasswd: UDP), -CheckedPort(80, True, HTTP Server: Unsecure port), -CheckedPort(443, True, HTTP Server: Secure port), +CheckedPort(389, Directory Service: Unsecure port), +CheckedPort(636, Directory Service: Secure port), +CheckedPort(88, Kerberos KDC port), +CheckedPort(464, Kerberos Kpasswd port), +CheckedPort(80, HTTP Server: Unsecure port), +CheckedPort(443, HTTP Server: Secure port), ] CA_PORTS = [ -CheckedPort(7389, True, PKI-CA: Directory Service port), +CheckedPort(7389, PKI-CA: Directory Service port), ] def print_info(msg): @@ -211,18 +208,18 @@ def configure_krb5_conf(realm, kdc, filename): class PortResponder(threading.Thread): -def __init__(self, port, socket_stream = True, socket_timeout=1): +def __init__(self, port, socket_timeout=1): super(PortResponder, self).__init__() self.port = port -self.socket_stream = socket_stream self.socket_timeout = socket_timeout self._stop_request = False def run(self): while not self._stop_request: try: -ipautil.bind_port_responder(self.port, self.socket_stream, -self.socket_timeout, responder_data=FreeIPA) +ipautil.bind_port_responder(self.port, +socket_timeout=self.socket_timeout, +responder_data=FreeIPA) except socket.timeout: pass except socket.error, e: @@ -242,7 +239,7 @@ def port_check(host, port_list): failed_ports = [] for port in port_list: -if ipautil.host_port_open(host, port.port, port.stream, CONNECT_TIMEOUT): +if ipautil.host_port_open(host, port.port, socket_timeout=CONNECT_TIMEOUT): result = OK else: failed_ports.append(port) @@ -284,7 +281,7 @@ def main(): print_info(Start listening on required ports for remote master check) for port in required_ports: root_logger.debug(Start listening on port %d (%s) % (port.port, port.description)) -responder = PortResponder(port.port, port.stream) +responder = PortResponder(port.port) responder.start() RESPONDERS.append(responder) -- 1.7.7.6 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3
On 01/31/2012 06:45 AM, Sumit Bose wrote: Hi, for the IPAv3 trust feature we have to add the objectclass ipaNTUserAttrs/ipaNTGroupAttrs to every user/group which should be visible on the Windows side of the trust. The only MUST attribute of both objectclasses is ipaNTSecurityIdentifier the SID or the user or group. We would like to manage the SIDS with the DNA plugin since they have to be unique in the IPA domain. The trust support will typically be added to a running IPA domain, because we do not plan to install it by default and we have to consider updated v2 environments as well. So the question arises what is the most preferred way to add a DNA configuration to an existing Directory Server setup with replication. Nathan suggested to create the configuration with the full range on the first master, configure the other master with no available values and let the DNA plugin transfer the ranges between the masters. This will lead to the following steps: 1. Check if there are already shared configuration entries in cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX 2a. if not we can create the initial configuration on the current master: dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: SIDs dnaType: ipaNTSecurityIdentifier dnaNextValue: 1000 dnaMaxValue: eval($SIDMAX)# Maybe 200k ? dnaMagicRegen: 999 dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) dnaScope: $SUFFIX dnaThreshold: 500 dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX 3a. Add ipaNTUserAttrs/ipaNTGroupAttrs to all users/groups with ipaNTSecurityIdentifier=999 on the current master 4a. Done on the first master 2b. if there are already entries we can create the configuration for an additional master: dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: SIDs dnaType: ipaNTSecurityIdentifier dnaNextValue: 1101 dnaMaxValue: 1100 dnaMagicRegen: 999 dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) dnaScope: $SUFFIX dnaThreshold: 500 dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX 3b. Done on the additional master, DNA plugin will sort out the rest Do these steps make sense? Is it necessary to add a lock to prevent a race condition btween step 1 and 2a, i.e. two admins try to prepare IPA for trusts independently at the same time? Do I understand it correctly that if dnaMaxValue is set to e.g. 2^32 on the first master, the range on the second master will start at 2^31? So the usage of the full range will be quite sparse if dnaMaxValue is set too high. Step 3a on the first master might need some time to finish. Is it necessary to set some kind of lock to prevent the configuration of the DNA plugin on other masters while this task is running or is it safe to add another master at any time? Are there other ways to introduce the DNA configuration? Nathan suggested also that the ranges can be configured manually without overlap, but if possible I would prefer the automatic way. Thank you for your help. bye, Sumit ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Couple comments. 1) What is the impact on the replication? 2) How we can prevent the case when in the distributed topology the change starts from two ends? 3) What is the speed of the propagation of this configuration in a 20 replica architecture? 4) Would it be better to generate the SIDs on every replica? We already have UID/GID and GUIDs for the entries. If SID is derived from entry GUID the change can be made locally and does not require replication. The GUIDs are already replicated so the SID can be generated locally like we do with the other non replicated attributes. In this case you just need to install a new plugin on your replicas and change configuration entry to enable it. As soon as this entry is replicated the plugin will kick in and would start adding SIDs to users and groups in the background on every replica. Overall there will be less traffic and no need to deal with DNA ranges. Is it possible to derive SID from other attribute in the User or group object? 5) If we go with the way Summit suggested we also need to have a special handling in the ipa-replica-prepare depending upon whether the SID support is on or off. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3
Sumit Bose wrote: Hi, for the IPAv3 trust feature we have to add the objectclass ipaNTUserAttrs/ipaNTGroupAttrs to every user/group which should be visible on the Windows side of the trust. The only MUST attribute of both objectclasses is ipaNTSecurityIdentifier the SID or the user or group. We would like to manage the SIDS with the DNA plugin since they have to be unique in the IPA domain. The trust support will typically be added to a running IPA domain, because we do not plan to install it by default and we have to consider updated v2 environments as well. So the question arises what is the most preferred way to add a DNA configuration to an existing Directory Server setup with replication. Nathan suggested to create the configuration with the full range on the first master, configure the other master with no available values and let the DNA plugin transfer the ranges between the masters. This will lead to the following steps: 1. Check if there are already shared configuration entries in cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX 2a. if not we can create the initial configuration on the current master: dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: SIDs dnaType: ipaNTSecurityIdentifier dnaNextValue: 1000 dnaMaxValue: eval($SIDMAX)# Maybe 200k ? dnaMagicRegen: 999 dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) dnaScope: $SUFFIX dnaThreshold: 500 dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX 3a. Add ipaNTUserAttrs/ipaNTGroupAttrs to all users/groups with ipaNTSecurityIdentifier=999 on the current master 4a. Done on the first master 2b. if there are already entries we can create the configuration for an additional master: dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: SIDs dnaType: ipaNTSecurityIdentifier dnaNextValue: 1101 dnaMaxValue: 1100 dnaMagicRegen: 999 dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) dnaScope: $SUFFIX dnaThreshold: 500 dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX 3b. Done on the additional master, DNA plugin will sort out the rest Do these steps make sense? Is it necessary to add a lock to prevent a race condition btween step 1 and 2a, i.e. two admins try to prepare IPA for trusts independently at the same time? There is no locking/notification mechansim to do this AFAIK. The first master in this case really means the first one that gets updated packages. The updates that happen at rpm upgrade time happen with the server listening only on ldapi so it would be very possible for two servers to apply the updates at the same time without knowing it. Do I understand it correctly that if dnaMaxValue is set to e.g. 2^32 on the first master, the range on the second master will start at 2^31? So the usage of the full range will be quite sparse if dnaMaxValue is set too high. Step 3a on the first master might need some time to finish. Is it necessary to set some kind of lock to prevent the configuration of the DNA plugin on other masters while this task is running or is it safe to add another master at any time? In fact it might take a REALLY long time if there are a lot of users. This would happen at the end of an rpm upgrade, I wonder if we'd want a separate task to run instead. If we can figure out a way to have only one server do all the updates then I don't think the DNA config would be an issue. Are there other ways to introduce the DNA configuration? Nathan suggested also that the ranges can be configured manually without overlap, but if possible I would prefer the automatic way. I think coordinating manual ranges would be hard, I agree with Sumit that automatic is the way to go. I wonder if before shutting things down for upgrade something creates cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX and sets a magic value in it specific to the host that added it. When any other changes are done relating to this update if the hostname doesn't match that magic value the updates are skipped. We tend to construct full dns for reference rather than searching so I'd think that even if there was a replication conflict entry created it would never get used because of the unique dn it would get. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3
On Wed, 2012-02-01 at 12:00 -0500, Dmitri Pal wrote: On 01/31/2012 06:45 AM, Sumit Bose wrote: Hi, for the IPAv3 trust feature we have to add the objectclass ipaNTUserAttrs/ipaNTGroupAttrs to every user/group which should be visible on the Windows side of the trust. The only MUST attribute of both objectclasses is ipaNTSecurityIdentifier the SID or the user or group. We would like to manage the SIDS with the DNA plugin since they have to be unique in the IPA domain. The trust support will typically be added to a running IPA domain, because we do not plan to install it by default and we have to consider updated v2 environments as well. So the question arises what is the most preferred way to add a DNA configuration to an existing Directory Server setup with replication. Nathan suggested to create the configuration with the full range on the first master, configure the other master with no available values and let the DNA plugin transfer the ranges between the masters. This is the way to go. This will lead to the following steps: 1. Check if there are already shared configuration entries in cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX 2a. if not we can create the initial configuration on the current master: dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: SIDs dnaType: ipaNTSecurityIdentifier dnaNextValue: 1000 dnaMaxValue: eval($SIDMAX)# Maybe 200k ? dnaMagicRegen: 999 dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) dnaScope: $SUFFIX dnaThreshold: 500 dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX 3a. Add ipaNTUserAttrs/ipaNTGroupAttrs to all users/groups with ipaNTSecurityIdentifier=999 on the current master This should be done as a task in Directory server. 4a. Done on the first master I am not sure I understand what does this means. 2b. if there are already entries we can create the configuration for an additional master: dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: SIDs dnaType: ipaNTSecurityIdentifier dnaNextValue: 1101 dnaMaxValue: 1100 dnaMagicRegen: 999 dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) dnaScope: $SUFFIX dnaThreshold: 500 dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX 3b. Done on the additional master, DNA plugin will sort out the rest Do these steps make sense? Yes. Is it necessary to add a lock to prevent a race condition btween step 1 and 2a, i.e. two admins try to prepare IPA for trusts independently at the same time? No, if admins are so dumb not to coordinate on adding this infrastructure changing stuff and do it at the exact same moment it's really their problem. We will, of course, document that they should be careful. Do I understand it correctly that if dnaMaxValue is set to e.g. 2^32 on the first master, the range on the second master will start at 2^31? So the usage of the full range will be quite sparse if dnaMaxValue is set too high. True, ranges are always split in half for now. Step 3a on the first master might need some time to finish. Is it necessary to set some kind of lock to prevent the configuration of the DNA plugin on other masters while this task is running or is it safe to add another master at any time? safe, the task to add SIDs to users should be an explicit DS task set up only by the ipa-trust-install script. Are there other ways to introduce the DNA configuration? Nathan suggested also that the ranges can be configured manually without overlap, but if possible I would prefer the automatic way. Automatic is better, less error prone. Couple comments. 1) What is the impact on the replication? If you have many users the first replication would take a long time. 2) How we can prevent the case when in the distributed topology the change starts from two ends? By documenting that you do not run ipa-trust-install on 2 ends. 3) What is the speed of the propagation of this configuration in a 20 replica architecture? It depends on the replica topology and what master you run the install on. 4) Would it be better to generate the SIDs on every replica? We already have UID/GID and GUIDs for the entries. If SID is derived from entry GUID the change can be made locally and does not require replication. SIDs cannot be derived from GUIDs. The GUIDs are already replicated so the SID can be generated locally like we do with the other non replicated attributes. In this case you just need to install a new plugin on your replicas and change configuration entry to enable it. As soon as this entry is replicated the plugin will kick in and would start adding SIDs to users and groups in the background on every replica. Overall there
Re: [Freeipa-devel] Adding a new DNA plugin configuration in IPAv3
On Wed, 2012-02-01 at 13:39 -0500, Rob Crittenden wrote: Sumit Bose wrote: Hi, for the IPAv3 trust feature we have to add the objectclass ipaNTUserAttrs/ipaNTGroupAttrs to every user/group which should be visible on the Windows side of the trust. The only MUST attribute of both objectclasses is ipaNTSecurityIdentifier the SID or the user or group. We would like to manage the SIDS with the DNA plugin since they have to be unique in the IPA domain. The trust support will typically be added to a running IPA domain, because we do not plan to install it by default and we have to consider updated v2 environments as well. So the question arises what is the most preferred way to add a DNA configuration to an existing Directory Server setup with replication. Nathan suggested to create the configuration with the full range on the first master, configure the other master with no available values and let the DNA plugin transfer the ranges between the masters. This will lead to the following steps: 1. Check if there are already shared configuration entries in cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX 2a. if not we can create the initial configuration on the current master: dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: SIDs dnaType: ipaNTSecurityIdentifier dnaNextValue: 1000 dnaMaxValue: eval($SIDMAX)# Maybe 200k ? dnaMagicRegen: 999 dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) dnaScope: $SUFFIX dnaThreshold: 500 dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX 3a. Add ipaNTUserAttrs/ipaNTGroupAttrs to all users/groups with ipaNTSecurityIdentifier=999 on the current master 4a. Done on the first master 2b. if there are already entries we can create the configuration for an additional master: dn: cn=SIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: SIDs dnaType: ipaNTSecurityIdentifier dnaNextValue: 1101 dnaMaxValue: 1100 dnaMagicRegen: 999 dnaFilter: (|(objectclass=ipaNTUserAttrs)(objectClass=ipaNTGroupAttrs)) dnaScope: $SUFFIX dnaThreshold: 500 dnaSharedCfgDN: cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX 3b. Done on the additional master, DNA plugin will sort out the rest Do these steps make sense? Is it necessary to add a lock to prevent a race condition btween step 1 and 2a, i.e. two admins try to prepare IPA for trusts independently at the same time? There is no locking/notification mechansim to do this AFAIK. The first master in this case really means the first one that gets updated packages. The updates that happen at rpm upgrade time happen with the server listening only on ldapi so it would be very possible for two servers to apply the updates at the same time without knowing it. The trust stuff is always explicitly installed manually, so there is no problem at rpm upgrade time. Either the configuration is already there or there is no configuration to care about. Do I understand it correctly that if dnaMaxValue is set to e.g. 2^32 on the first master, the range on the second master will start at 2^31? So the usage of the full range will be quite sparse if dnaMaxValue is set too high. Step 3a on the first master might need some time to finish. Is it necessary to set some kind of lock to prevent the configuration of the DNA plugin on other masters while this task is running or is it safe to add another master at any time? In fact it might take a REALLY long time if there are a lot of users. This would happen at the end of an rpm upgrade, I wonder if we'd want a separate task to run instead. Nothing to do at rpm updagrade time. If we can figure out a way to have only one server do all the updates then I don't think the DNA config would be an issue. Only one server should do them see my other email. Are there other ways to introduce the DNA configuration? Nathan suggested also that the ranges can be configured manually without overlap, but if possible I would prefer the automatic way. I think coordinating manual ranges would be hard, I agree with Sumit that automatic is the way to go. I wonder if before shutting things down for upgrade something creates cn=sids,cn=dna,cn=ipa,cn=etc,$SUFFIX and sets a magic value in it specific to the host that added it. When any other changes are done relating to this update if the hostname doesn't match that magic value the updates are skipped. We tend to construct full dns for reference rather than searching so I'd think that even if there was a replication conflict entry created it would never get used because of the unique dn it would get. I don't think this is necessary, it does not avoid races anyways. Simo. -- Simo Sorce * Red Hat, Inc *
Re: [Freeipa-devel] [PATCH] 072 Navigation and redirection to various facets
On 1/27/2012 10:49 AM, Petr Vobornik wrote: In current implementation target facet of navigation(from menu) and redirection is always one exact facet per entity. There isn't a way to navigate to different facet from menu or redirect to different facets from various facets. This patch adds: * possibility to define menu items which can navigate to different facets of various entities. This also means that now current menu tree can contain leafs with the same entity. * possibility to define redirection target per facet - it is needed to keep breadcrumb navigation consistent with various navigation tree patch leading leafs with same entity. This functionality is needed for Automember UI. Automember UI is designed as if it was for two entities but it is in fact only one. Note: attaching early (missing a lot of stuff) WIP patch of Automember UI to illustrate usage of this patch. https://fedorahosted.org/freeipa/ticket/2195 ACK. Pushed to master and ipa-2-2. There are some existing problems with redirection. In users search facet, when you click a user that's already deleted via CLI, the UI doesn't redirect. This is because it uses a batch command to pull user data policies. The batch itself will return a success although the operations inside it fail. The automount location and map do not redirect either if it's already deleted. The automount key does redirect, but to the locations instead of to the map. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 938 consolidate external member code
We had code all over the place to handle adding and removing external
members from a variety of attributes. I consolidated these all into two
functions in baseldap.py.
This obsoletes my patch 920 but this patch includes the improved error
reporting that was present.
rob
From af2c04e812e870cf75da73e8a80cb83641cd5b5a Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Wed, 1 Feb 2012 16:20:54 -0500
Subject: [PATCH] Consolidate external member code into two functions in
baseldap.py
External members (users and hosts) are assumed when doing member
management on certain attributes. If the member isn't in IPA it
is assumed to be external. When doing member management we need
to sift through the list of failures and pull out all those
that were simply not found in IPA.
https://fedorahosted.org/freeipa/ticket/1734
---
ipalib/plugins/baseldap.py| 75 +++
ipalib/plugins/hbacrule.py| 51 +---
ipalib/plugins/netgroup.py| 49 +---
ipalib/plugins/sudorule.py| 195 ++---
tests/test_xmlrpc/test_sudorule_plugin.py |2 +-
5 files changed, 89 insertions(+), 283 deletions(-)
diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py
index f59a0d4106729573cfdbd8bdf2c407619eb051d5..0fba0016959c6c53691cd6192fe965ff88993c39 100644
--- a/ipalib/plugins/baseldap.py
+++ b/ipalib/plugins/baseldap.py
@@ -306,6 +306,81 @@ def wait_for_value(ldap, dn, attr, value):
return entry_attrs
+def add_external_post_callback(memberattr, membertype, externalattr, ldap, completed, failed, dn, entry_attrs, *keys, **options):
+
+Post callback to add failed members as external members.
+
+This should be called by a commands post callback directly.
+
+memberattr is one of memberuser,
+membertype is the type of member: user,
+externalattr is one of externaluser,
+
+completed_external = 0
+# Sift through the failures. We assume that these are all
+# entries that aren't stored in IPA, aka external entries.
+if memberattr in failed and membertype in failed[memberattr]:
+(dn, entry_attrs_) = ldap.get_entry(dn, [externalattr])
+members = entry_attrs.get(memberattr, [])
+external_entries = entry_attrs_.get(externalattr, [])
+failed_entries = []
+for entry in failed[memberattr][membertype]:
+membername = entry[0].lower()
+member_dn = api.Object[membertype].get_dn(membername)
+if membername not in external_entries and \
+ member_dn not in members:
+# Not an IPA entry, assume external
+external_entries.append(membername)
+completed_external += 1
+elif membername in external_entries and \
+ member_dn not in members:
+# Already an external member, reset the error message
+msg = unicode(errors.AlreadyGroupMember().message)
+newerror = (entry[0], msg)
+ind = failed[memberattr][membertype].index(entry)
+failed[memberattr][membertype][ind] = newerror
+failed_entries.append(membername)
+else:
+# Really a failure
+failed_entries.append(membername)
+
+if completed_external:
+try:
+ldap.update_entry(dn, {externalattr: external_entries})
+except errors.EmptyModlist:
+pass
+failed[memberattr][membertype] = failed_entries
+entry_attrs[externalattr] = external_entries
+
+return (completed + completed_external, dn)
+
+def remove_external_post_callback(memberattr, membertype, externalattr, ldap, completed, failed, dn, entry_attrs, *keys, **options):
+# Run through the failures and gracefully remove any member defined
+# as an external member.
+if memberattr in failed and membertype in failed[memberattr]:
+(dn, entry_attrs_) = ldap.get_entry(dn, [externalattr])
+external_entries = entry_attrs_.get(externalattr, [])
+failed_entries = []
+completed_external = 0
+for entry in failed[memberattr][membertype]:
+membername = entry[0].lower()
+if membername in external_entries:
+external_entries.remove(membername)
+completed_external += 1
+else:
+failed_entries.append(membername)
+
+if completed_external:
+try:
+ldap.update_entry(dn, {externalattr: external_entries})
+except errors.EmptyModlist:
+pass
+failed[memberattr][membertype] = failed_entries
+entry_attrs[externalattr] = external_entries
+
+return (completed + completed_external, dn)
+
+
class LDAPObject(Object):
Object representing a LDAP entry.
diff --git a/ipalib/plugins/hbacrule.py
