@maz Hello again.
Good news.
Nice term but unfortunately not, at least as of yet. I believe @suman has some diagrams in the works but don’t think they are as of yet release ready.
I wouldn’t worry about that, python is very friendly and mostly the project’s complexity comes from it’s scope and the django elements. I would say that we are a bit weak on code comments however so as you work stuff out a nice addition is to add comments as you go, this has been a more recent and ongoing effort so not a whole lot of coverage just yet: but getting there.
I would say that this is not something we can do, given that this is exactly what @suman did and then undid in the referenced release notes repeated for ease of reference:
The end result of the original ‘flip’ was that many users just can’t manage with sssd and had compatibility issues. From my understanding the two systems have a slightly different bias with sssd having a more independent approach where it relied more on trusted domain relationship with existing domains where as windbind was happier / more compatible in some ways. I’m afraid I just don’t know enough to be more helpful here but that was my understanding after having a little look. It may well be that sssd has come on far enough since then to risk another change but given it seems to be quite a popular feature I think the way to go would be to enact the two systems in a mutually exclusive fashion. This is going to be more difficult but I think will lead to the best overall compatibility and choice. And hopefully avoid the breakage we encountered last time the flip approach was attempted.
So the approach I was going to take was to re-introduce @suman prior work but with the addition of an initial check to see if an existing winbind service was active and warn that the two implementations are incompatible and so refuse to enable one when the other was enabled. This is a little messy but I don’t see a way around it.
I would say a re-read of the above referenced wifi entries (remembering that they are now reversed again) and to study what @suman did last time, along with the what was then re-instated.
So the following announcement and pull requests plus any others you can find that touch the same files (git history) are going to be the key:
Note that this was a long time ago now and much has changed but the origin and development of the prior sssd approach should be usefull:
and it’s related pull request:
Note worthy in that pr is the following commit: “remove deprecated winbind service. #860”
There was then a significant improvement announced a little while later in the 3.8-12 dev log:
which referenced the following pr:
ie look to the files changed tab in that pr and the commit messages.
But then shortly there after Rockstor reverted to windbind as covered earlier ie:
and it’s associated pr:
Be sure to read all the commit messages as that will give you a good idea of how it all works and why.
Ie the following is particularly relevant:
By programmatic in-line editing (mostly) ie a services config is used to replace an existing config entry if found or added otherwise, varies slightly form service to servcie.
Sometimes, ie some services start with a template and then edit it while others just attempt to edit what ever they find there in the first place. Some times Rockstor machine edits are put at the of a file but often this is not viable and inline edits are required to enact a config change without duplicate entries for the same item.
Hope that helps.
I would say that this is a slightly monster task to start with but if your game then great. It might be more encouraging to start with something smaller to ‘warm up’ ie picking something from the issues list:
Or anything you find otherwise which is a-miss.
And I’m assuming you are already familiar with the Developers section of the Contributing to Rockstor - Overview docs.
Good luck, have fun, and @Flyer and @suman are your main contacts here as I’ve done very little in this area of the code my self.
See how you get on and always ask question when needed. Might be best to start a new thread and link back to this one for context.
Hope that helps, at least with pointing out the genesis, development, and hopefully temporary deprecation of a prior attempt to enact sssd based active directory capability.