Relocate SSNv2 nextRange attribute #4890
Conversation
The nextRange attribute for SSNv2 has been moved to ou=requests,ou=ranges_v2 for requests and ou=certificateRepository,ou=ranges_v2 for certs such that the nextRange for SSNv1 is unchanged during migration. This will simplify the recovery process in case there's an issue during migration. The SubsystemIdGeneratorUpdateCLI has been updated to compute the request nextRange for SSNv2 with the same process used to compute the cert nextRange for SSNv2.
The SSNv1 and SSNv2 tests have been updated to use the new SSNv2 nextRange location.
|
| LDAPModification mods = new LDAPModification(LDAPModification.REPLACE, attrRequestNextRange); | ||
|
|
||
| conn.modify(newRangeDN, mods); | ||
| } |
There was a problem hiding this comment.
Actually, these check should not be needed since there are not gap/conversion for the request numbers so the nextRange could be just copied to the new location. However, it should not add error and it could be a double check for the code which is almost the same of the serial number. Maybe they could be merged but it is OK to leave as it is for the moment
|
@fmarco76 Thanks! I'll merge. Yes, ideally they should be merged so we don't have to maintain the code twice. One thing though, I was expecting the SSNv2 |
In which case are they different? Looking at the tests I do not see differences! |
|
In the single CA case the next range changes from 41 to 51 as soon as we switch to SSNv2 (no new enrollment): In CA clone case it changes from 31 to 51: |
|
I thought this increment was because of the restart and the allocation of a new range. The range was exhausted when we switch to legacy2. |
|
In SSNv1 we've observed the range changing when it's exhausted during enrollment. We don't have a test to see if the range changes when the server is restarted, so I'm not sure if this is the proper behavior. Ideally I don't think it should, but so far it doesn't seem to be causing any problem. |
|
In SSNv1 we have 40 requests on line 1105. The nextRange is 41 on line 1165 and on line 1237 there is the generator switch to |
The
nextRangeattribute for SSNv2 has been moved toou=requests,ou=ranges_v2for requests andou=certificateRepository,ou=ranges_v2for certs such that thenextRangefor SSNv1 is unchanged during migration. This will simplify the recovery process in case there's an issue during migration.The
SubsystemIdGeneratorUpdateCLIhas been updated to compute the requestnextRangefor SSNv2 with the same process used to compute the certnextRangefor SSNv2.The SSNv1 and SSNv2 tests have been updated to use the new SSNv2
nextRangelocation.