Learn more about these different git repos.
Other Git URLs
After yet another discussion about DNS updates in SSSD, I think that it would be better to separate DNS update code into separate binary and let NetworkManager to call it on interface changes. Possible fallback for systems without NetworkManager could be to call the binary when going to online mode, but I would not enable it by default.
As a consequence (besides less complicated SSSD code) it would allow the user to easily replace the DNS update binary/code with something hand-made.
In principle I agree, I want less code in sssd and move the responsibilities to components that are better suited for them, but I doubt we would have time in 1.14.
I propose 1.15.
Speaking about prioritization, it is worth considering if split out will make fixing #2872 and #2873 easier, maybe it is worth doing sooner rather than investing into the 'unwanted' solution.
I believe that the new code can be synchronous one-shot binary, which should make it way easier to maintain.
What would be purpose of separated binary from sssd code? We already use external binary "nsupdate".
The ideal would be just to send dbus message to NetworkManager. Or disable DNS updates in sssd and rely on other software (NetworkManager, systemd-*, ...)
Lukas, you are completely right. The new binary (or script of whatever) could be split completely out of SSSD tree, hooked to DBus (or whatever) and called by NetworkManager.
I.e. end of DNS update bussiness in SSSD. Given that SSSD is the only component which implements complete DNS update logic, it makes sense to start by splitting the existing code out so we do not need to reinvent the wheel.
Replying to [comment:4 pspacek]:
Lukas, you are completely right. The new binary (or script of whatever) could be split completely out of SSSD tree, hooked to DBus (or whatever) and called by NetworkManager. I do not understand why NetworkManager should call binary provided by sssd? It should be other way or sssd should not be involved at all. I.e. end of DNS update bussiness in SSSD. Given that SSSD is the only component which implements complete DNS update logic, it makes sense to start by splitting the existing code out so we do not need to reinvent the wheel.
I do not understand why NetworkManager should call binary provided by sssd? It should be other way or sssd should not be involved at all.
The logic is very simple. Concatenation of strings for nsupdate. NetworkManger can inspire in SSSD C-code and rewrite it as hook in a scripting language which is more suitable for work with strings.
Lukas, I was saying that the binary should be 'split completely out of SSSD tree'. I.e. it would not be provided by SSSD anymore. So NetworkManager would have no relation to SSSD.
I'm not oposed to re-writting it from scratch, it is also an option. Just keep in mind that it has to work on bare minimal installs like Fedora Clound image etc., so a fancy scripting language with ton of dependencies might not be an option.
Replying to [comment:6 pspacek]:
Lukas, I was saying that the binary should be 'split completely out of SSSD tree'. I.e. it would not be provided by SSSD anymore. So NetworkManager would have no relation to SSSD. I still do not understand why it should be done by sssd. This RFE should be filed in NetworkManager ticket tracker. The reasonable RFE for SSSD would be to disable DNS updates by default. I'm not oposed to re-writting it from scratch, it is also an option. Just keep in mind that it has to work on bare minimal installs like Fedora Clound image etc., so a fancy scripting language with ton of dependencies might not be an option.
I still do not understand why it should be done by sssd. This RFE should be filed in NetworkManager ticket tracker. The reasonable RFE for SSSD would be to disable DNS updates by default.
sssd implementation depends on libtalloc, libtevent, libcares, libsss_util.so libsss_child.
So it would be much simpler to write it from scratch in python. python is integral part of Fedora, CentOS (due to yum, dnf) and Debian (apt-utils)
Replying to [comment:7 lslebodn]:
I still do not understand why it should be done by sssd. This RFE should be filed in NetworkManager ticket tracker. The reasonable RFE for SSSD would be to disable DNS updates by default. That is up to you, sure.
My reasoning was this: I expect that SSSD code cannot be removed unless there is equivalent functionality available somewhere else. It is certainly up to SSSD devels to decide if it is preferable to 'wait for Godot' and keep fixing code in SSSD or get hands dirty and split out the functionality outside of SSSD and hand it over to NetworkManager or whatever else project.
So it would be much simpler to write it from scratch in python. python is integral part of Fedora, CentOS (due to yum, dnf) and Debian (apt-utils) I'm not oposing to that in principle. Let to the final implementor.
I'm afraid we don't have time in 1.14. I agree with the general direction and we should start talking to the NetworkManager people soon (Petr, Pavel, feel free to start doing so), but I don't think we should commit our resources to another work in the 1.14 scope, sorry.
It would be fantastic if NM developers could help us here.
milestone: NEEDS_TRIAGE => SSSD 1.15 beta
I sill do not think that it should be task for sssd developers. We do not know the requirements from NetworkManager and extracting binary from sssd code would be very difficult task.
The proper process should be:
Therefore closing this RFE.
_comment0: I sill do not think that it should be task for sssd developers. We do not know the requirements from NetworkManager and extracting binary from sssd code would be very difficult task.
The proper process should be: file tickets to NetworkManager (or other project) there would be describe current state in sssd. We can provide links to out design document. file ticket to sssd do drop current implementation.
Therefore closing this RFE. => 1448045608232814 resolution: => wontfix status: new => closed
It's better to decide on radical resolutions like wontfix (as opposed to deferred) during triage.
In the future, please move the ticket to triage before closing.
milestone: SSSD 1.15 beta => NEEDS_TRIAGE resolution: wontfix => status: closed => reopened
Replying to [comment:11 jhrozek]:
It's better to decide on radical resolutions like wontfix (as opposed to deferred) during triage. It's not radical resolution because it is an improper request for sssd.
It's not radical resolution because it is an improper request for sssd.
If we create such binary we do not know if it is acceptable for NetworkManager or other relevant projects because there wasn't discussion between teams. There is not a design document which would describe interface for such binary (command line arguments ...). So it can happen that other project will not use binary extracted from sssd.
In the future, please move the ticket to triage before closing. This ticket was moved to the milestone "SSSD 1.15" without triage. I would like to apologise that I did the same.
Up to you, guys. I'm not going to spend any more time on this. Enjoy the maintenance ;-)
Replying to [comment:12 lslebodn]:
Hmm, that was the week where we only did the triage over mail and not phone. Sorry, I shouldn't have moved the ticket. We can discuss later this week again.
This might be a good idea for a thesis, intern or someone's side project. But probably won't happen in the short future.
Fields changed
keywords: => thesis milestone: NEEDS_TRIAGE => SSSD Deferred
rhbz: => todo
cc: => preichl@redhat.com
Another use case for separate utility is with IPA servers that might need to update more than just machine's own hostname (ipa-ca) and that might want to set the IP address to some external (NAT, iptables) IP address which cannot be found on the host. I've filed https://fedorahosted.org/freeipa/ticket/5629 for that now but I guess some of the logic is already in SSSD code base.
cc: preichl@redhat.com => preichl@redhat.com, jpazdziora@redhat.com
I completely agree that it would be better to implement it in freeipa. We can provide our design pages as an inspiration.
Metadata Update from @pspacek: - Issue set to the milestone: SSSD Patches welcome
Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfill this request I am closing the issue as wontfix.
If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.
Thank you for understanding.
Metadata Update from @pbrezina: - Issue close_status updated to: wontfix - 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/3912
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.