Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[enh] Simplify the whole LDAP interface thing #721
This is a cherry-pick from #585 for the part that handle LDAP authentication using root instead of asking for the admin password each time. Considering that the whole group permission PR is likely to take some time, yet this thing is a pretty interesting independent feature ...
I started iterating on it to also get rid of the whole '
So to summarize the two major benefits right now are :
Made a quick test and it looks like this is a working, but considering this is a touchy part I want to do moar tests. Also I might find some fancy stuff to factorize a bit the part where we fetch the
How to test
... Checkout this branch (and the corresponding one). You need to make sure that the ldap conf is updated otherwise this won't work ... then try any step that usually requires to enter the admin password (e.g. postinstall or user create)
Currently this PR creates a weird issue occuring after calling
It doesn't seem to be so troublesome appart that it's a pretty annoying message ... the most puzzling thing is that I can't figure out why that seem to happen only with
Well, why we don't just go forward with the group permission. I know that I don't have much time these days, but the problem with that is that after we might need fix many conflict.
The other problem is that with this PR we also need to update the LDAP config still problematic.
Yes, I too would like to move forward with group permissions. But there are important bugs to be fixed and I'm not comfortable / expert enough with the code and the whole LDAP thing to handle it ... So in the meantime, this feature of auth through root is just independent and easy to merge ...
I know that there will be many conflict, yes. In fact I recently had to basically redo a PR from scratch because it was one year old and too outdated... We just terribly lack humanpower to work on boring general interest tasks such as the incoming migration to Buster, the migration to Python 3, and in general reviewing/fixing/finishing opened PRs ... And despite this I'd really like to have some time some day to work on important features such as the high-level diagnosis thing...
I don't think it is because it just changes the slapd.conf, which should be handled automatically by the regenconf ? It doesn't need a schema update
Please read the diff. I just fetch the ldap interface right when we actually need it instead of passing the
For this, I could help you if it's the only issue.
I just think that if the time that you past over this PR was passed on the group-permission probably less work would be needed. And why this feature is soo important ? I just feel with this PR that the group-permission will be never merged if we continue like that. And in my point of view passing the time to do 2 time the same thing is really a wast of time.
Yes but as same as for the group-permission, we need to think about a user which as customized his config. In this case Yunohost might be completely broken...
I hope to find some time to work on this, this summer when the group-permission is completely finished.
Sorry I didn't see really quickly the diff.
I don't know what to tell you... Let's get things straight : we're all in the same boat. A large part of my implication in the technical side of YunoHost consist in trying to help merge as many PR as I can so the project moves forward and hopefully I can at some point win the right to implement the cool stuff I'm dreaming of... I'm not trying to jeopardize stuff, especially considering that the group permission feature is an important thing that people ask for. I myself already took the time to review and fix what I could and it took me at least 2 days from what I can remember ?
There is nothing "so important" about the present PR, it's just something quite independent of the whole group permission thing, and it's nice to have as it removes weird UX behavior and simplify code. It's a small thing and is easily mergeable so we can just benefit it immediately and move forward, and then that's one thing less to validate in the group permission thing. It "only" took me basically half a day to test (the existing part from the group permission PR) and implement the other small code simplification. The additional commits are not related to the group permission thing either ... It's just complementary work to the whole 'use root to authenticate on the LDAP' idea...
I perfectly understand your frustration that the group permission don't get merged more quickly even tho most of the work is done. But to me that's just a classic illustration of the Pareto principe applied to development : the first 80% of the work will take only 20% of the development time (or if you prefer : the last 20% will take 80% of the development time) - because edge cases are hard to handle, things must be tested and reviewed, and so on. We see this everyday with many non-trivial PRs both in core and apps.
If you are worried about the conflicts then :
But as stated I don't really master the whole permission/LDAP thing. For instance about this issue I found I can't really say anything more than "I don't know how to fix it", and several comments are related to the fact that it's not clear for me what's the intention / design choice / ... Not because it's bad or anything, just that the feature is big and complex, so it's expected that there's a need to iterate.
Meh I dunno, I don't really have a solution about this, other than saying that I expect this to only correspond to a small minority of technical user (even more technical than tweaking the nginx or ssh conf) so meh ... We can just explain those people to force the regenconf of ldap and everything shall be back to normal :/
OK, might give a good statistic for the next step with group-permission how many instance is impacted
referenced this pull request
May 16, 2019
Sooo in fact I'm gonna yolomerge this because we really need to test this on the battle field and the sooner the better ... (and also that'll allow to move forward with other PRs).
Like with any other merged PR, we can still iterate if needed anyway ...