Usernames of deleted users must be stored, because they cannot ever be used again. That data must be replicated to at least the DC backups, so that in case of a promotion the information is retained.
OpenLDAP seems to be slow retrieving nodes with 100.000s of values, so probably a subtree will contain one node per username prefix, containing a counter that increments. ~20.000 different usernames were seen at one customer.
One object per username-base under cn=ucsschool,cn=univention,$base_dn: objectclass ucsschoolUsername attributetype ucsschoolUsernameNextNumber # univention-ldapsearch -LLL '(ucsschoolUsernameNextNumber=*)' dn: cn=B.Schmidt,cn=unique-usernames,cn=ucsschool,cn=univention,dc=uni,dc=dtr objectClass: ucsschoolUsername cn: B.Schmidt ucsschoolUsernameNextNumber: 4
[ALWAYSCOUNTER] and [COUNTER2] are covered by 34_import-users_via_cli_v2. The test checks if the unique-usernames object is created. Missing is currently a test, that the usernames are not reused if a previous user has been removed.
I don't see any commits for this bug.
Test for this bug is in 90_ucsschool/34_import-users_via_cli_v2 test_create_with_username_scheme(). ... although it does not really check if the next import with the same username will use the counter, it merely checks if the "unique-usernames object" LDAP objects are created.
r72476: Enhanced test_create_with_username_scheme() to run three imports for each role, creating and deleting the same user for both ALWAYSCOUNTER and COUNTER2, using username extensions ['1', '2', '3'] and ['', '2', '3'].