Possible documentation issue 2

Users Feedback
1

In section 3.2 (“LDAP Connector”) is it correct to say that the “ldap_auth” section should contain list items rather than map key/value pairs? (I may have my YAML terminology a bit wrong.) In the example below it appears the first “ldap_auth” configuration (referencing “ldap1”) may be incorrect (whereas the second, referencing “ldap2” seems to be correct).

Thoughts? (If one of these is incorrect, the documentation may need to be updated.)

(I had been struggling for a while to get my “ldap_auth” configuration to work using the first syntax below; but when when I switched to the second syntax below, it does.)

Thanks,
Greg

- name: Accept requests from users in group team1 on index1
  type: allow
  ldap_auth:
      name: "ldap1"                                       # ldap name from below 'ldaps' section
      groups: ["g1", "g2"]                                # group within 'ou=Groups,dc=example,dc=com'
  indices: ["index1"]
  
- name: Accept requests from users in group team2 on index2
  type: allow
  ldap_auth:
      - name: "ldap2"
        groups: ["g3"]
        cache_ttl_in_sec: 60
  indices: ["index2"]
2

The first example is correct in the newest version of ROR plugin. Second one works in first version of plugin with LDAP support (but the syntax was wrong - was fixed in the newest version).

3

Good to know!

I’m on 5.3.0. So If I go to 5.3.2, should I switch to the first syntax?

4

The new syntax and various other improvements are in the master branch, which is receiving quite a few fixes right now after the invaluable feedback received from CERN the past week.

5

Thanks for the info. Do you know what will be the first version to support the corrected syntax (and when it will likely be released)? Just curious.Thanks.

6

Hi @gtorrance the new builds are out! Grab yours at https://readonlyrest.com

7

Great! Thank you again.

8

One more question, if you don’t mind @sscarduzio:

I understand if I use 5.3.2 of ReadonlyREST I need to make sure I use 5.3.2 of the rest of the ELK stack. Correct?

9

yeah the versioning system works like this, if you downloaded readonlyrest-1.15.0_es5.3.2.zip, that means:
plugin version = 1.15.0
compatible elasticsearch version = 5.3.2

When you use Kibana, if ES version is not exactly the same of Kibana, it prints a warning. Ideally Kibana and ES should be the same version though.

1 Like
10

@gtorrance very curious to know how your integration goes, both from technical and user experience standpoint. Suggestions and questions are welcome :slight_smile:

11

@sscarduzio, thanks for asking. It’s going well so far. It has taken me a while longer than planned, but I’m making progress.

If I were to pick one positive and one negative to mention:

Positive: Your highly responsive and helpful support. Thank you! Oh, and it’s a great tool, too :slight_smile:

Negative: Well, not really a negative, but something that caused me some frustrations. When trying to set up something like this I admit I tend to rely on searching a lot rather than reading documentation through from top to bottom. (Maybe had I read the documentation more thoroughly, I would not have had this problem.) Essentially, I found myself spending a lot of time trying to find answer by searching the documentation page (GitHub - beshu-tech/readonlyrest-docs: Official Documentation of ReadonlyREST Plugin). (For example, trying to search for “kibana” on that page did not yield a lot.) I didn’t realize that there was a lot of other good information in the README.md. Had I realized, it would have saved me a lot of time and frustration. I guess I’m wondering if it might be a good idea to have all of the official documentation in one place, rather than two separate locations. Just a thought :slight_smile: I’ll try to read more carefully in future, though :slight_smile:

Thanks again for being so helpful (and for the great product).

Greg