Ignoring all reqests for more compatible OpenLDAP access

Archive Rancher 1.x
1

please could you explain, why ranchers managment team seams to ignore all the requests for anonymous LDAP access (=without rancher specific service accounts) repeatedly articulated by users for quite a long time (#2372 etc.)

IMHO it’s a very simple and easy realizable feature and in fact also an indispensable requirement for RFC compliant LDAP support.

i really don’t get, why all the concerning user requests got rejected over and over again and finally became flagged as unscheduled.

are there any serious considerations behind this decision, or does it just represent plain disregard concerning sufficiently declared user needs?

2

We happily take pull requests if you think it’s so simple and easy to build.

We run a business and have spent tens of thousands of hours and millions of dollars developing software we think solves a problem companies will pay for. As part of that we make all of that work available completely free and open-source, which encourages wider adoption and experimentation and ultimately more users using it in companies in production situations that will pay for support.

There is limited time in the day so we prioritize things we want to do, things current or prospective customers are asking for, and the issues from the community in the way we think best accomplishes those goals.

  • OpenLDAP is one of the least used auth providers among open-source users (and not because of this)
  • It’s even less popular among customers, and no customer (I’m aware of) has requested this
  • So working on this benefits a tiny portion of users
  • This is not really that popular of a request, there are issues we haven’t done with far more +1/thumbs up/duplicates, from people who actually ask nicely.
  • There is a way to make it work, even if it’s not your favorite way

The entitled attitude of anonymous users of free software on the internet never ceases to occasionally amaze me. I bet you’d never walk into to my house and tell me I should be buying Coke Zero instead of Diet Coke because that’s your favorite kind… but you put a keyboard between people and suddenly you demanding we spend our time making something do what you want is apparently normal.

4 Likes
3
1 Like
4

Quite an endemic attitude. There is also the expectation that fixes are provided in a un-realistic time frame and its all for free as well. This is open source, if you want a feature, write it yourself that is how open source works.

5

Just consider that you are “standing on shoulders of giants”, the last thing anyone with sense would do is kick the giant in the head.

6

yes – i was trying to fix it myself…

but frankly, i wasn’t able setup a debug/development installation to test the necessary fixes. :frowning:

it’s really a pity – the necessary code changes to fix the issue itself are quite trivial and easy to write, but the complexity and fragmented source organization of rancher makes it very uncomfortable and time consuming for foreign participants unfamiliar with all its idiosyncrasies to change/test anything.

i still think, there are only two changes needed:

  1. on the UI/API side we need to remove the field-required attribute for serviceAccountUsername and serviceAccountPassword if they are used in isOpenLdap context.

  2. the authentification callbacks have to use simple access without explicit DN-binding if no username/passwort is given.
    in the case of the ldap library used by rancher (ldap.v2) this is handles a little bit different than e.g. for openldap bindings. openldap uses empty username/passwort options to enable this kind of access. that’s very close to its representation in the ldap network protocol and the relevant specifications. but the actual library used by rancher needs another workaround to use this kind of anonymous access. in this case simple anonymous access will be chosen automatically for a search, if no explicit other binding are used before. it’s therefore only necessary to look in rancher-auth-service/providers/ldap/ldap_client.go:newConn(), if username/passwort fields are empty and bypass the lConn.Bind(serviceAccountUsername, l.Config.ServiceAccountPassword) command in this case.

i hope, that works…

but again – this changes look quite trivial and just mimic, how LDAP is usually used in unix environments resp. what’s necessary to fulfill the requirements specified in the relevant RFCs.
it’s only the complexity of ranchers build and deploy system, which i couldn’t master as developer ad hoc.

and as a gerneral side note about the OPEN SOURCE nature:

meanwhile i’m working and developing nearly exclusive using open source tools and operating systems for nearly three decades! :slight_smile: – really. i’know, what it means!

and believe it or not, i’m able to differentiate between open source software, in the sense of maximized transparency and collective development efforts, and those more fashionable approaches, where proclaimed open source terms are just camouflage proprietary and paternalistic business strategies…

and in this particular case i had to evaluate a few orchestration solutions for a corporation. i just tried to integrate their existing LDAP administration infrastructure and found this obvious issue.

sure, i simply could have worked around it, but as i stumbled over it in ‘evaluation’-mode, i didn’t choose this option. instead i wrote a bug report – that’s IMHO the most useful way simple ordinary users have to participate and help in open source development.
later, when i found all this other ignored similar bug reports, i really felt alarmed. and when i finally saw you response here in this forum, my judgment about your software and the report i have to give about it was more are less clear and inevitable:

i just can summarize: stay away from this software!

not because it’s developers are demanding, that users have to fix bugs themself – that’s something i could perhaps accept :wink: – but because of the ignorance concerning standard compliance and compatibility with non-proprietary solutions. that’s something, i really can’t stand. IMHO it’s an infallible indicator for software we should better avoid. :frowning:

7

If you’d asked about setting up a development environment or how to fix this issue instead of berating us for not fixing it for you, someone would have pointed you to the wiki and helped with questions. Not that it probably matters now, but https://github.com/rancher/rancher/wiki/Cowpoke-1%3A-Getting-Started-with-Rancher . {{field-required}} is just displaying the star, the actual required-ness is part of the API schema.

Much of the reason it’s been ignored is because all the auth code is being slowly moved out of Java and into a Go service to make it easier to manage and add new providers. e.g. AD is moving in the next release. If we were going to do something about this it would be while moving OpenLDAP, not doing throwaway work on code that’s going away.

The world is not black and white, and RFCs aren’t laws. Just about every major DNS implementation and hosted provider supports underscores in hostname labels in blatant disregard for RFC952 but you still probably use Bind without attacking their developers.

And you can keep saying it, but your interpretation of the RFC is wrong. RFCs describe what things a conformant server must implement and the client’s interaction with those things. It makes no sense for an RFC to specify that a client must implement an auth mechanism that it doesn’t want to use. And that’s why section 2 says that a server implementations must support anonymous (in order to provide StartTLS). 5.1.1 is referring to the client and says the client may use the anonymous mechanism.

1 Like