Re: [Freeipa-devel] DESIGN: Recover DNA Ranges
Sumit Bose wrote: On Mon, Feb 25, 2013 at 03:12:19PM +0100, Martin Kosek wrote: On 02/25/2013 03:09 PM, Rob Crittenden wrote: Martin Kosek wrote: ... 4) What does NOTE: We will need to be clear that this range has nothing to do with Trust ranges. actually mean? AFAIU, IPA should have all local ranges covered with a local idrange range(s). IPA ranges is completely separate from DNA ranges. You can set/modify all the local ranges you want and it won't affect the UIDs getting assigned. If it does not have it covered, it could happen that for example a new trust would overlap with this user-defined local range and we would have colliding POSIX IDs... Hmm, that's a good point. IMO, dnarange-set and dnanextrange-set should at first check if the range is covered with some local idrange and only then allowed setting the new range. I can do that as well, but again, the local ranges don't really affect the ids we hand out via DNA. rob You are right, that DNA plugin is really not aware of the idranges we set in IPA. But the idrange is still a safeguard for our POSIX IDs to not overlap with trust ranges and I think we should respect that with ipa-replica-manage. I wonder if there was not even a plan to increase cooperation between our idranges and DNA plugin, maybe Sumit or Alexander knows more. If I understand the use case and design properly, it is about re-arranging the sub-ranges each replica can use from the original range, which was given/created at installation time and which is also stored as idrange in DOMAIN.NAME_id_range,cn=ranges,cn=etc,dc=domain,dc=name with objectclass=ipaDomainIDRange. If the re-arrangement does not result in IDs which are outside of this range give by the ipaDomainIDRange object, no conflicts with idranges used by trusted domain will occur, because it is one of the task of the idrange objects to avoid those conflicts. If the original given range is exhausted completely and a completely new DNA range must be created, it should be checked with ipa idrange-find that the new range is not used and a new ipaDomainIDRange object which reserves the local range should be added. There are https://fedorahosted.org/freeipa/ticket/591 which can be used to track the coordinated creation of DNA and id-range. Honestly, I was going to skip the range stuff altogether and just focus on the DNA ranges. I'm primarily interested in saving any range from a server that is going to be deleted. I can save that in the on-base attribute of any existing servers. Where I run into trouble is if all the on-base are populated, then we'd lose range. So I need to alert the user somehow. This leads to wanting to be able to add that back in so I came up with the idea of letting users manage the DNA range directly. It may be possible to check the DOMAIN ranges as well but that bumps the complexity up considerably. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DESIGN: Recover DNA Ranges
On Wed, Feb 27, 2013 at 09:50:21AM -0500, Rob Crittenden wrote: Sumit Bose wrote: On Mon, Feb 25, 2013 at 03:12:19PM +0100, Martin Kosek wrote: On 02/25/2013 03:09 PM, Rob Crittenden wrote: Martin Kosek wrote: ... 4) What does NOTE: We will need to be clear that this range has nothing to do with Trust ranges. actually mean? AFAIU, IPA should have all local ranges covered with a local idrange range(s). IPA ranges is completely separate from DNA ranges. You can set/modify all the local ranges you want and it won't affect the UIDs getting assigned. If it does not have it covered, it could happen that for example a new trust would overlap with this user-defined local range and we would have colliding POSIX IDs... Hmm, that's a good point. IMO, dnarange-set and dnanextrange-set should at first check if the range is covered with some local idrange and only then allowed setting the new range. I can do that as well, but again, the local ranges don't really affect the ids we hand out via DNA. rob You are right, that DNA plugin is really not aware of the idranges we set in IPA. But the idrange is still a safeguard for our POSIX IDs to not overlap with trust ranges and I think we should respect that with ipa-replica-manage. I wonder if there was not even a plan to increase cooperation between our idranges and DNA plugin, maybe Sumit or Alexander knows more. If I understand the use case and design properly, it is about re-arranging the sub-ranges each replica can use from the original range, which was given/created at installation time and which is also stored as idrange in DOMAIN.NAME_id_range,cn=ranges,cn=etc,dc=domain,dc=name with objectclass=ipaDomainIDRange. If the re-arrangement does not result in IDs which are outside of this range give by the ipaDomainIDRange object, no conflicts with idranges used by trusted domain will occur, because it is one of the task of the idrange objects to avoid those conflicts. If the original given range is exhausted completely and a completely new DNA range must be created, it should be checked with ipa idrange-find that the new range is not used and a new ipaDomainIDRange object which reserves the local range should be added. There are https://fedorahosted.org/freeipa/ticket/591 which can be used to track the coordinated creation of DNA and id-range. Honestly, I was going to skip the range stuff altogether and just focus on the DNA ranges. I'm primarily interested in saving any range from a server that is going to be deleted. I can save that in the on-base attribute of any existing servers. Where I run into trouble is if all the on-base are populated, then we'd lose range. So I need to alert the user somehow. If it is only about moving existing DNA range it is fine, because this means that DNA will not give ID which are outside of the idrange of the IPA domain which is created at installation or during upgrade to v3. This leads to wanting to be able to add that back in so I came up with the idea of letting users manage the DNA range directly. It may be possible to check the DOMAIN ranges as well but that bumps the complexity up considerably. But it looks like dnarange-set and dnanextrange-set can also be used to not only move existing DNA ranges but to create new DNA ranges which will lead to ID which are not in the idrange of the IPA domain but might be in an idrange which is used by a trusted domain. So I think a check and a warning are desirable. bye, Sumit rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DESIGN: Recover DNA Ranges
Sumit Bose wrote: On Wed, Feb 27, 2013 at 09:50:21AM -0500, Rob Crittenden wrote: Sumit Bose wrote: On Mon, Feb 25, 2013 at 03:12:19PM +0100, Martin Kosek wrote: On 02/25/2013 03:09 PM, Rob Crittenden wrote: Martin Kosek wrote: ... 4) What does NOTE: We will need to be clear that this range has nothing to do with Trust ranges. actually mean? AFAIU, IPA should have all local ranges covered with a local idrange range(s). IPA ranges is completely separate from DNA ranges. You can set/modify all the local ranges you want and it won't affect the UIDs getting assigned. If it does not have it covered, it could happen that for example a new trust would overlap with this user-defined local range and we would have colliding POSIX IDs... Hmm, that's a good point. IMO, dnarange-set and dnanextrange-set should at first check if the range is covered with some local idrange and only then allowed setting the new range. I can do that as well, but again, the local ranges don't really affect the ids we hand out via DNA. rob You are right, that DNA plugin is really not aware of the idranges we set in IPA. But the idrange is still a safeguard for our POSIX IDs to not overlap with trust ranges and I think we should respect that with ipa-replica-manage. I wonder if there was not even a plan to increase cooperation between our idranges and DNA plugin, maybe Sumit or Alexander knows more. If I understand the use case and design properly, it is about re-arranging the sub-ranges each replica can use from the original range, which was given/created at installation time and which is also stored as idrange in DOMAIN.NAME_id_range,cn=ranges,cn=etc,dc=domain,dc=name with objectclass=ipaDomainIDRange. If the re-arrangement does not result in IDs which are outside of this range give by the ipaDomainIDRange object, no conflicts with idranges used by trusted domain will occur, because it is one of the task of the idrange objects to avoid those conflicts. If the original given range is exhausted completely and a completely new DNA range must be created, it should be checked with ipa idrange-find that the new range is not used and a new ipaDomainIDRange object which reserves the local range should be added. There are https://fedorahosted.org/freeipa/ticket/591 which can be used to track the coordinated creation of DNA and id-range. Honestly, I was going to skip the range stuff altogether and just focus on the DNA ranges. I'm primarily interested in saving any range from a server that is going to be deleted. I can save that in the on-base attribute of any existing servers. Where I run into trouble is if all the on-base are populated, then we'd lose range. So I need to alert the user somehow. If it is only about moving existing DNA range it is fine, because this means that DNA will not give ID which are outside of the idrange of the IPA domain which is created at installation or during upgrade to v3. This leads to wanting to be able to add that back in so I came up with the idea of letting users manage the DNA range directly. It may be possible to check the DOMAIN ranges as well but that bumps the complexity up considerably. But it looks like dnarange-set and dnanextrange-set can also be used to not only move existing DNA ranges but to create new DNA ranges which will lead to ID which are not in the idrange of the IPA domain but might be in an idrange which is used by a trusted domain. So I think a check and a warning are desirable. That is an excellent point. I've updated the design. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DESIGN: Recover DNA Ranges
Sumit Bose wrote: On Wed, Feb 27, 2013 at 02:03:24PM -0500, Rob Crittenden wrote: Sumit Bose wrote: But it looks like dnarange-set and dnanextrange-set can also be used to not only move existing DNA ranges but to create new DNA ranges which will lead to ID which are not in the idrange of the IPA domain but might be in an idrange which is used by a trusted domain. So I think a check and a warning are desirable. That is an excellent point. I've updated the design. Thank you. I would like to suggest a slight edit. Instead of That doesn't remove our responsibility to not test for overlaps in the idranges though. We will need to verify that the manual configuration changes do not overlap with all ranges in cn=ranges,cn=etc,$SUFFIX. I would say That doesn't remove our responsibility to not test for overlaps in the idranges though. We will need to verify that the manual configuration changes do * not overlap with ranges from trusted domains (objectclass=ipatrustedaddomainrange) in cn=ranges,cn=etc,$SUFFIX, or reject the change otherwise. * overlap completely with ranges from the local IPA domain (objectclass=ipaDomainIDRange) in cn=ranges,cn=etc,$SUFFIX, or give a warning otherwise which asks the user to add a new suitable idrange. Codewise the logic could be: - check if the new range is a subset of a local idrange, if yes, all is fine - if not, check if it overlaps with an idrange of a trusted domain, if yes, reject - if not, give a warning and ask to add a new idrange for the local domain I took this almost verbatim but I'm more harsh. If the range is outside the local range and not overlapping anything I will still reject it. If we're going to go through the trouble of keeping them in sync we should be consistent. thanks rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DESIGN: Recover DNA Ranges
On Wed, 2013-02-27 at 15:00 -0500, Rob Crittenden wrote: Sumit Bose wrote: On Wed, Feb 27, 2013 at 02:03:24PM -0500, Rob Crittenden wrote: Sumit Bose wrote: But it looks like dnarange-set and dnanextrange-set can also be used to not only move existing DNA ranges but to create new DNA ranges which will lead to ID which are not in the idrange of the IPA domain but might be in an idrange which is used by a trusted domain. So I think a check and a warning are desirable. That is an excellent point. I've updated the design. Thank you. I would like to suggest a slight edit. Instead of That doesn't remove our responsibility to not test for overlaps in the idranges though. We will need to verify that the manual configuration changes do not overlap with all ranges in cn=ranges,cn=etc,$SUFFIX. I would say That doesn't remove our responsibility to not test for overlaps in the idranges though. We will need to verify that the manual configuration changes do * not overlap with ranges from trusted domains (objectclass=ipatrustedaddomainrange) in cn=ranges,cn=etc,$SUFFIX, or reject the change otherwise. * overlap completely with ranges from the local IPA domain (objectclass=ipaDomainIDRange) in cn=ranges,cn=etc,$SUFFIX, or give a warning otherwise which asks the user to add a new suitable idrange. Codewise the logic could be: - check if the new range is a subset of a local idrange, if yes, all is fine - if not, check if it overlaps with an idrange of a trusted domain, if yes, reject - if not, give a warning and ask to add a new idrange for the local domain I took this almost verbatim but I'm more harsh. If the range is outside the local range and not overlapping anything I will still reject it. If the local ranges ^^ the admin may have already added additional ones, so it needs to be plural. we're going to go through the trouble of keeping them in sync we should be consistent. Otherwise good plan. 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] DESIGN: Recover DNA Ranges
On Wed, Feb 27, 2013 at 03:00:10PM -0500, Rob Crittenden wrote: Sumit Bose wrote: On Wed, Feb 27, 2013 at 02:03:24PM -0500, Rob Crittenden wrote: Sumit Bose wrote: But it looks like dnarange-set and dnanextrange-set can also be used to not only move existing DNA ranges but to create new DNA ranges which will lead to ID which are not in the idrange of the IPA domain but might be in an idrange which is used by a trusted domain. So I think a check and a warning are desirable. That is an excellent point. I've updated the design. Thank you. I would like to suggest a slight edit. Instead of That doesn't remove our responsibility to not test for overlaps in the idranges though. We will need to verify that the manual configuration changes do not overlap with all ranges in cn=ranges,cn=etc,$SUFFIX. I would say That doesn't remove our responsibility to not test for overlaps in the idranges though. We will need to verify that the manual configuration changes do * not overlap with ranges from trusted domains (objectclass=ipatrustedaddomainrange) in cn=ranges,cn=etc,$SUFFIX, or reject the change otherwise. * overlap completely with ranges from the local IPA domain (objectclass=ipaDomainIDRange) in cn=ranges,cn=etc,$SUFFIX, or give a warning otherwise which asks the user to add a new suitable idrange. Codewise the logic could be: - check if the new range is a subset of a local idrange, if yes, all is fine - if not, check if it overlaps with an idrange of a trusted domain, if yes, reject - if not, give a warning and ask to add a new idrange for the local domain I took this almost verbatim but I'm more harsh. If the range is outside the local range and not overlapping anything I will still reject it. If we're going to go through the trouble of keeping them in sync we should be consistent. even better, thank you. bye, Sumit thanks rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DESIGN: Recover DNA Ranges
On Mon, Feb 25, 2013 at 03:12:19PM +0100, Martin Kosek wrote: On 02/25/2013 03:09 PM, Rob Crittenden wrote: Martin Kosek wrote: ... 4) What does NOTE: We will need to be clear that this range has nothing to do with Trust ranges. actually mean? AFAIU, IPA should have all local ranges covered with a local idrange range(s). IPA ranges is completely separate from DNA ranges. You can set/modify all the local ranges you want and it won't affect the UIDs getting assigned. If it does not have it covered, it could happen that for example a new trust would overlap with this user-defined local range and we would have colliding POSIX IDs... Hmm, that's a good point. IMO, dnarange-set and dnanextrange-set should at first check if the range is covered with some local idrange and only then allowed setting the new range. I can do that as well, but again, the local ranges don't really affect the ids we hand out via DNA. rob You are right, that DNA plugin is really not aware of the idranges we set in IPA. But the idrange is still a safeguard for our POSIX IDs to not overlap with trust ranges and I think we should respect that with ipa-replica-manage. I wonder if there was not even a plan to increase cooperation between our idranges and DNA plugin, maybe Sumit or Alexander knows more. If I understand the use case and design properly, it is about re-arranging the sub-ranges each replica can use from the original range, which was given/created at installation time and which is also stored as idrange in DOMAIN.NAME_id_range,cn=ranges,cn=etc,dc=domain,dc=name with objectclass=ipaDomainIDRange. If the re-arrangement does not result in IDs which are outside of this range give by the ipaDomainIDRange object, no conflicts with idranges used by trusted domain will occur, because it is one of the task of the idrange objects to avoid those conflicts. If the original given range is exhausted completely and a completely new DNA range must be created, it should be checked with ipa idrange-find that the new range is not used and a new ipaDomainIDRange object which reserves the local range should be added. There are https://fedorahosted.org/freeipa/ticket/591 which can be used to track the coordinated creation of DNA and id-range. bye, Sumit Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DESIGN: Recover DNA Ranges
On 02/22/2013 09:19 PM, Rob Crittenden wrote: Design to allow one to recover DNA ranges when deleting a replica or just for normal range management. http://freeipa.org/page/V3/Recover_DNA_Ranges Supporting ticket https://fedorahosted.org/freeipa/ticket/3321 rob I wonder if it would be possible to have more on-deck ranges. Could dnaNextRange be multi-valued, and when the low-water mark is hit the plugin would pick one of them? -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DESIGN: Recover DNA Ranges
On 02/25/2013 01:44 PM, Petr Viktorin wrote: On 02/22/2013 09:19 PM, Rob Crittenden wrote: Design to allow one to recover DNA ranges when deleting a replica or just for normal range management. http://freeipa.org/page/V3/Recover_DNA_Ranges Supporting ticket https://fedorahosted.org/freeipa/ticket/3321 rob I wonder if it would be possible to have more on-deck ranges. Could dnaNextRange be multi-valued, and when the low-water mark is hit the plugin would pick one of them? Not at the moment, this is a single valued attribute type: attributetypes: ( 2.16.840.1.113730.3.1.2129 NAME 'dnaNextRange' DESC 'DNA ran ge of values to get from replica' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE -VALUE X-ORIGIN '389 Directory Server' ) But it is a good question for 389-ds guys, it would be a good extension to the DNA plugin and would prevent us from not-loosing the range when there is no master with empty dnaNextRange. But maybe there is a strong reason why this was made single value... As for the RFE, I have few comments/questions for Rob: 1) I would expand Setting the on-deck range section and add an information what should we do when the remote master is not accessible (this would result only in a warning probably). 2) We may want to make sure that the removed replica is readonly before we copy the range (just to be sure that we do not miss some value due to race condition. 3) In Enhancing ipa-replica-manage: What does ipa-replica-manage dnarange-set masterA.example.com 250-499 exactly do? I though that it would just overwrite active range, but based on the next ipa-replica-manage dnanextrange-show example, it moved the currently active range of masterA.example.com to the on-deck range. Do we want to do that? 4) What does NOTE: We will need to be clear that this range has nothing to do with Trust ranges. actually mean? AFAIU, IPA should have all local ranges covered with a local idrange range(s). If it does not have it covered, it could happen that for example a new trust would overlap with this user-defined local range and we would have colliding POSIX IDs... IMO, dnarange-set and dnanextrange-set should at first check if the range is covered with some local idrange and only then allowed setting the new range. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DESIGN: Recover DNA Ranges
Martin Kosek wrote: On 02/25/2013 01:44 PM, Petr Viktorin wrote: On 02/22/2013 09:19 PM, Rob Crittenden wrote: Design to allow one to recover DNA ranges when deleting a replica or just for normal range management. http://freeipa.org/page/V3/Recover_DNA_Ranges Supporting ticket https://fedorahosted.org/freeipa/ticket/3321 rob I wonder if it would be possible to have more on-deck ranges. Could dnaNextRange be multi-valued, and when the low-water mark is hit the plugin would pick one of them? Not at the moment, this is a single valued attribute type: attributetypes: ( 2.16.840.1.113730.3.1.2129 NAME 'dnaNextRange' DESC 'DNA ran ge of values to get from replica' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE -VALUE X-ORIGIN '389 Directory Server' ) But it is a good question for 389-ds guys, it would be a good extension to the DNA plugin and would prevent us from not-loosing the range when there is no master with empty dnaNextRange. But maybe there is a strong reason why this was made single value... As for the RFE, I have few comments/questions for Rob: 1) I would expand Setting the on-deck range section and add an information what should we do when the remote master is not accessible (this would result only in a warning probably). Ok. I'll try to clarify this. 2) We may want to make sure that the removed replica is readonly before we copy the range (just to be sure that we do not miss some value due to race condition. That is attempted now as part of CLEANALLRUV. I'll mention it in the design so we time this properly. 3) In Enhancing ipa-replica-manage: What does ipa-replica-manage dnarange-set masterA.example.com 250-499 exactly do? I though that it would just overwrite active range, but based on the next ipa-replica-manage dnanextrange-show example, it moved the currently active range of masterA.example.com to the on-deck range. Do we want to do that? I'm guessing I wasn't very precise with my example, focusing more on usage than output. These are all independent of one another. I'll make it more of a sequence. 4) What does NOTE: We will need to be clear that this range has nothing to do with Trust ranges. actually mean? AFAIU, IPA should have all local ranges covered with a local idrange range(s). IPA ranges is completely separate from DNA ranges. You can set/modify all the local ranges you want and it won't affect the UIDs getting assigned. If it does not have it covered, it could happen that for example a new trust would overlap with this user-defined local range and we would have colliding POSIX IDs... Hmm, that's a good point. IMO, dnarange-set and dnanextrange-set should at first check if the range is covered with some local idrange and only then allowed setting the new range. I can do that as well, but again, the local ranges don't really affect the ids we hand out via DNA. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DESIGN: Recover DNA Ranges
On 02/25/2013 03:09 PM, Rob Crittenden wrote: Martin Kosek wrote: ... 4) What does NOTE: We will need to be clear that this range has nothing to do with Trust ranges. actually mean? AFAIU, IPA should have all local ranges covered with a local idrange range(s). IPA ranges is completely separate from DNA ranges. You can set/modify all the local ranges you want and it won't affect the UIDs getting assigned. If it does not have it covered, it could happen that for example a new trust would overlap with this user-defined local range and we would have colliding POSIX IDs... Hmm, that's a good point. IMO, dnarange-set and dnanextrange-set should at first check if the range is covered with some local idrange and only then allowed setting the new range. I can do that as well, but again, the local ranges don't really affect the ids we hand out via DNA. rob You are right, that DNA plugin is really not aware of the idranges we set in IPA. But the idrange is still a safeguard for our POSIX IDs to not overlap with trust ranges and I think we should respect that with ipa-replica-manage. I wonder if there was not even a plan to increase cooperation between our idranges and DNA plugin, maybe Sumit or Alexander knows more. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DESIGN: Recover DNA Ranges
On 02/25/2013 06:09 AM, Martin Kosek wrote: On 02/25/2013 01:44 PM, Petr Viktorin wrote: On 02/22/2013 09:19 PM, Rob Crittenden wrote: Design to allow one to recover DNA ranges when deleting a replica or just for normal range management. http://freeipa.org/page/V3/Recover_DNA_Ranges Supporting ticket https://fedorahosted.org/freeipa/ticket/3321 rob I wonder if it would be possible to have more on-deck ranges. Could dnaNextRange be multi-valued, and when the low-water mark is hit the plugin would pick one of them? Not at the moment, this is a single valued attribute type: attributetypes: ( 2.16.840.1.113730.3.1.2129 NAME 'dnaNextRange' DESC 'DNA ran ge of values to get from replica' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE -VALUE X-ORIGIN '389 Directory Server' ) But it is a good question for 389-ds guys, it would be a good extension to the DNA plugin and would prevent us from not-loosing the range when there is no master with empty dnaNextRange. But maybe there is a strong reason why this was made single value... If you make it multi-valued, then you probably want to have some sort of ordering to the values . . . As for the RFE, I have few comments/questions for Rob: 1) I would expand Setting the on-deck range section and add an information what should we do when the remote master is not accessible (this would result only in a warning probably). 2) We may want to make sure that the removed replica is readonly before we copy the range (just to be sure that we do not miss some value due to race condition. 3) In Enhancing ipa-replica-manage: What does ipa-replica-manage dnarange-set masterA.example.com 250-499 exactly do? I though that it would just overwrite active range, but based on the next ipa-replica-manage dnanextrange-show example, it moved the currently active range of masterA.example.com to the on-deck range. Do we want to do that? 4) What does NOTE: We will need to be clear that this range has nothing to do with Trust ranges. actually mean? AFAIU, IPA should have all local ranges covered with a local idrange range(s). If it does not have it covered, it could happen that for example a new trust would overlap with this user-defined local range and we would have colliding POSIX IDs... IMO, dnarange-set and dnanextrange-set should at first check if the range is covered with some local idrange and only then allowed setting the new range. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DESIGN: Recover DNA Ranges
Rich Megginson wrote: On 02/25/2013 06:09 AM, Martin Kosek wrote: On 02/25/2013 01:44 PM, Petr Viktorin wrote: On 02/22/2013 09:19 PM, Rob Crittenden wrote: Design to allow one to recover DNA ranges when deleting a replica or just for normal range management. http://freeipa.org/page/V3/Recover_DNA_Ranges Supporting ticket https://fedorahosted.org/freeipa/ticket/3321 rob I wonder if it would be possible to have more on-deck ranges. Could dnaNextRange be multi-valued, and when the low-water mark is hit the plugin would pick one of them? Not at the moment, this is a single valued attribute type: attributetypes: ( 2.16.840.1.113730.3.1.2129 NAME 'dnaNextRange' DESC 'DNA ran ge of values to get from replica' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE -VALUE X-ORIGIN '389 Directory Server' ) But it is a good question for 389-ds guys, it would be a good extension to the DNA plugin and would prevent us from not-loosing the range when there is no master with empty dnaNextRange. But maybe there is a strong reason why this was made single value... If you make it multi-valued, then you probably want to have some sort of ordering to the values . . . I don't know. We don't have a whole lot of control of ordering when DNA gets a range, so I think that holes in the range happen now, so I wouldn't have a problem with lack of control. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DESIGN: Recover DNA Ranges
On 02/25/2013 09:23 AM, Rob Crittenden wrote: Rich Megginson wrote: On 02/25/2013 06:09 AM, Martin Kosek wrote: On 02/25/2013 01:44 PM, Petr Viktorin wrote: On 02/22/2013 09:19 PM, Rob Crittenden wrote: Design to allow one to recover DNA ranges when deleting a replica or just for normal range management. http://freeipa.org/page/V3/Recover_DNA_Ranges Supporting ticket https://fedorahosted.org/freeipa/ticket/3321 rob I wonder if it would be possible to have more on-deck ranges. Could dnaNextRange be multi-valued, and when the low-water mark is hit the plugin would pick one of them? Not at the moment, this is a single valued attribute type: attributetypes: ( 2.16.840.1.113730.3.1.2129 NAME 'dnaNextRange' DESC 'DNA ran ge of values to get from replica' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE -VALUE X-ORIGIN '389 Directory Server' ) But it is a good question for 389-ds guys, it would be a good extension to the DNA plugin and would prevent us from not-loosing the range when there is no master with empty dnaNextRange. But maybe there is a strong reason why this was made single value... If you make it multi-valued, then you probably want to have some sort of ordering to the values . . . I don't know. We don't have a whole lot of control of ordering when DNA gets a range, so I think that holes in the range happen now, so I wouldn't have a problem with lack of control. Ok. Please file an RFE ticket. There are some code changes that we will need to make to DNA to make next range take multiple values. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] DESIGN: Recover DNA Ranges
Design to allow one to recover DNA ranges when deleting a replica or just for normal range management. http://freeipa.org/page/V3/Recover_DNA_Ranges Supporting ticket https://fedorahosted.org/freeipa/ticket/3321 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
