Univention Bugzilla – Bug 55729
Unsolveable S4 Connector Rejects cause no samba on master/primary
Last modified: 2023-06-12 16:14:24 CEST
In the manual is not stated, that a samba server on the master/primary is mandatory; so the design without samba on the master should be supported by UCS. That design is btw following the "BSI Grundschutz" recommendation not to run unneeded services. I have seen a lot of environments that are designed like that. All environments have in common, that objects higher than the OU are rejected by the S4 connector as the replication server is not allowed to edit such objects. If the primary got a samba server the reject will be solved by that samba. In environments without samba on the primary there is no way out! You can delete the reject, but it will come back. As the design seems to be supported (see manual) and it is following the "BSI Grundschutz" recommendations, there should be a solution for these environments. I have opened the bug against UCS@school as the problem looks to me like a UCS@school only problem, but the involved component is the S4 connector. If the bug is in the wrong place, please move or clone in the right position.
Indeed, Samba is not required on the Primary of UCS@school. If you install it however there is no Samba -> Samba replication between Primary and Replicas, only the LDAP is replicated and then synchronized to the respective Samba via the S4 connector, rejects are therefore always something that occurs locally and should not be because of replication. To assess this we need to know: 1. What kind of rejects are you experiencing and on which server? 2. Who changed which kind of object that lead to this reject? 3. What happens exactly when the reject is deleted? If possible please also tell me how you feel about the bug (if it really is a bug): Does this cause great pain or is it something that can be worked around?
Thanks for working on that issue. :-) First of all, I think it would be a good idea to point to that problem in the documentation. No samba on primary may lead into not solvable s4-rejects. We see regular rejects on edu-replica comming from objects higher than the school-ou. Most simple example is a user in <LDAP-Root>/users/ that changed the password. This will never be synced. Another example are printers that are installed in the top of ldap tree. If we delete the reject (f.e. because the object is not important for the schools/samba) the reject will come back after a connector or server restart. That's annoying; as I need to check every time is that important? We have a workaround in most cases, but from my point of view that is a dirty hack. We set the object to the s4 ignorelist. It helps but the main problem is, that objects above the school ou are not syncable if there is no samba on the primary. Maybe it is possible to elevate a s4 connector to more right to specific objects configurable by UCR? That would be great, as you do not need to install samba on the primary, but you can grant the s4 the right to modify certain object above the school-ou. Is something wrong with forge? I can only set status resolved or need more info, what is the current status. I set new in the past when I provided more info.