Learn more about these different git repos.
Other Git URLs
Instead of two transaction:
update delete 180.122.168.192.in-addr.arpa. in PTR send update add 4.3.2.1.in-addr.arpa. 1200 in PTR husker.human.bs. send
Do only one:
update delete 180.122.168.192.in-addr.arpa. in PTR update add 4.3.2.1.in-addr.arpa. 1200 in PTR husker.human.bs. send
Why do we need it?
Will be record added if the delete fails? IIRC it requires quite recent version of nsupdate.
The original reporter of this problem (reported via e-mail, I can bounce the thread if you like) claimed that multiple transactions result in much larger replication churn in his AD environment.
Replying to [comment:2 jhrozek]:
So it means it's not a defect but enhancement.
type: defect => enhancement
Are we sure that this solution woudl not be affected by the same bug as in ticket #2783
The commit message say: nsupdate fails definitely if any of update request fails when GSSAPI is used.
If we want to do such change we need to be sure that nsupdate will work properly on distributions with LTS: rhel6, rhel7, debian stable ...
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.15 beta
rhbz: => todo
Metadata Update from @preichl: - Issue set to the milestone: SSSD Future releases (no date set yet)
We would also like to see this implemented for our hybrid environment.
Hi -
Is there an update on this?
We have multiple domain controllers and found that since the add update is sent immediately following the delete update, if the add is sent to a different DC to the one that the delete was sent to, and that DC had not yet replicated the delete, the add would be ignored as the PTR record already exists on that DC. Once replication catches up the PTR record would be removed leaving us with no record.
We have had to use static PTR records as a work around.
thanks
This issue is duplicate to #3829 I think. See also upstream commit 5565dd3. @tonylegend3243 - does it solve your issue?
Metadata Update from @thalman: - Custom field design_review reset (from 0) - Custom field mark reset (from 0) - Custom field patch reset (from 0) - Custom field review reset (from 0) - Custom field sensitive reset (from 0) - Custom field testsupdated reset (from 0) - Issue close_status updated to: None
This ticket seems to be lost in the sands of time. There were two similar tickets opened:
dyndns_update_per_family
The later one is only in 2.x.
2.x
Metadata Update from @pbrezina: - Custom field design_review reset (from false) - Custom field mark reset (from false) - Custom field patch reset (from false) - Custom field review reset (from false) - Custom field sensitive reset (from false) - Custom field testsupdated reset (from false)
Metadata Update from @thalman: - Custom field design_review adjusted to on (was: false) - Custom field mark adjusted to on (was: false) - Custom field patch adjusted to on (was: false) - Custom field review adjusted to on (was: false) - Custom field sensitive adjusted to on (was: false) - Custom field testsupdated adjusted to on (was: false) - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/3914
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.