[RFE] make nss/pam modules released independently of SSSD source tree

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2240

• Created at 2014-02-12 14:19:57 by abbra
• Closed at 2020-03-24 14:11:05 as wontfix
• Assigned to nobody

---

NSS/PAM modules provided by SSSD are good by themselves to be used as stable frontends against anything that implements SSSD's protocol for them.

Samba projects considers an option to implement the protocol in winbindd to allow winbind to serve NSS/PAM clients and have a common NSS/PAM modules with SSSD. Existing winbindd protocol is going to be replaced and SSSD protocol might be an option.

Please consider releasing NSS/PAM modules provided by SSSD as a separate project and also document the protocol they use against SSSD responders.

Comments

---

Comment from dpal at 2014-02-13 15:48:50

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.12 beta
rhbz: => 0

---

Comment from dpal at 2014-02-13 15:50:43

Fields changed

summary: RFE: make nss/pam modules released independently of SSSD source tree => [RFE] make nss/pam modules released independently of SSSD source tree

---

Comment from dpal at 2014-05-22 14:51:25

Fields changed

milestone: SSSD 1.12 beta => SSSD 1.12.1

---

Comment from sbose at 2014-05-22 16:19:16

With this ticket the pam_sss and libnss_sss client modules/libraries shall be made available for other projects and it should be verified that SSSD can really work with different versions of the client libraries. Currently clients and SSSD are tested together build from the same version hence it is possible that there are some issues although the interface was designed to support different versions. Handling multiple versions might be important for the container/docker use case where each container might have a different version of the client.

The following steps should be done before splitting the clients into a separate project:
- review and extend the existing documentation for the interfaces
- identify exiting code in the SSS responder which reads or writes the on-wire data which can be put into a library to be released with the clients.
- add tests

---

Comment from asn at 2014-06-05 09:34:18

This is something we need to work on soon.

cc: => asn@redhat.com

---

Comment from jhrozek at 2014-09-08 20:09:13

Mass-moving all tickets that didn't make 1.12.1 into 1.12.2

milestone: SSSD 1.12.1 => SSSD 1.12.2

---

Comment from jhrozek at 2014-09-30 19:06:29

We need to do a release as requested by downstream. Moving tickets that are not fixed already or very close to acking to 1.12.3

milestone: SSSD 1.12.2 => SSSD 1.12.3

---

Comment from jhrozek at 2014-11-20 13:20:02

Fields changed

mark: => 0
milestone: SSSD 1.12.3 => SSSD 1.13 beta

---

Comment from jhrozek at 2015-02-10 16:01:12

Per the conversations we had in Brno with Alexander last week, this is not as much needed as it used to be. We'll work with Samba developers if this is still required.

milestone: SSSD 1.13 beta => SSSD 1.13 backlog
priority: major => minor

---

Comment from jhrozek at 2015-02-12 20:27:14

Mass-moving tickets not planned for the next two releases.

Please reply with a comment if you disagree about the move..

milestone: SSSD 1.13 backlog => SSSD 1.15 beta

---

Comment from jhrozek at 2016-05-17 08:49:25

Marking as blocker for the 1.15 release since documenting the API should be the first step towards making SSSD and Winbind play nicer together.

priority: minor => blocker
sensitive: => 0

---

Comment from abbra at 2017-02-24 15:06:02

Metadata Update from @abbra:

• Issue set to the milestone: SSSD Future releases (no date set yet)

---

Comment from thalman at 2020-03-13 13:28:37

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
• Issue tagged with: Canditate to close

---

Comment from pbrezina at 2020-03-24 14:11:04

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.

---

Comment from pbrezina at 2020-03-24 14:11:05

Metadata Update from @pbrezina:

• Issue close_status updated to: wontfix
• Issue status updated to: Closed (was: Open)