Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make NRPE lens less strict #454

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

hillu
Copy link
Contributor

@hillu hillu commented Mar 18, 2017

See Debian bug #749919

@lutter
Copy link
Member

lutter commented Mar 20, 2017

I am wondering whether it wouldn't be better to have the lens parse the comma-separated list of hosts so that the test

  test Nrpe.item get "allowed_hosts=127.0.0.1, 127.0.0.2\n" =
    { "allowed_hosts" = "127.0.0.1, 127.0.0.2" }

would become

  test Nrpe.item get "allowed_hosts=127.0.0.1, 127.0.0.2\n" =
    { "allowed_hosts" = "127.0.0.1" }
    { "allowed_hosts" =  127.0.0.2" }

The reason for that is so that users of the lens do not have to parse the list of hosts themselves. This will require a little more work on the Nrpe lens, but if we are ever going to do that, this is the right time for that.

@lutter
Copy link
Member

lutter commented Mar 20, 2017

Since there is a little bit of trickery involved, The main changes would be to disallow , in word, and then redefining item to

let item = [ key item_re . eq . store word .
             [ label "more" . del /, */ ", " . store word]* . eol ]

It's actually not possible to get the structure I mentioned in my last post (at least not with quite a bit more headache in the lens). What the above would result in is

test Nrpe.item get "allowed_hosts=127.0.0.1, 127.0.0.2\n" =
{ 
  { "allowed_hosts" = "127.0.0.1"
    { "more" = "127.0.0.2" }
  }
}

It's a little annoying that there is no way to get at the label of the parent node in the lens - otherwise we could just use that, instead of the somewhat goofy more.

@raphink
Copy link
Member

raphink commented Mar 21, 2017

Or even

{ "allowed_hosts"
   { "1" = "127.0.0.1" }
   { "2" =  127.0.0.2" }
}

which breaks compatibility but makes more sense.

@hillu
Copy link
Contributor Author

hillu commented Aug 22, 2018

Oh, apparently I never noticed your answers, sorry. I'd be happy to make changes to my patch if somebody tells me what the structure produced by the lens should look like. I don't really mind, but I suppose that breaking compatibility is not necessarily the best idea...

@lutter
Copy link
Member

lutter commented Aug 24, 2018

I would strongly prefer a solution that does not break backwards compatibility. If allowed_hosts is the only kind of item that allows lists of things in it, I'd do the following:

  • disallow allowed_hosts in item_re
  • add a new allowed_hosts lens that generates a tree structure like { "allowed_hosts" = "ip1" { "ip" = "ip2" } { "ip" = "ip3" } .. }
  • add that new lens to the definition of lns

The allowed_hosts lens would look something like:

let allowed_hosts = [ key "allowed_hosts" . eq . store Rx.ip .
                            [ label "ip" . del /, */ ", " . store word]* . eol ]

@raphink
Copy link
Member

raphink commented Feb 25, 2019

@hillu do you still intend to get this PR merged? If so, could you address @lutter's comments please?

@hillu
Copy link
Contributor Author

hillu commented Feb 25, 2019

I currently don't have the time to do that.
The Debian package has contained my patch as proposed for almost two years.

@raphink
Copy link
Member

raphink commented Feb 4, 2020

@lutter what do we do about this? Not merging it will break compatibility in Debian because they merged the patch 3 years ago…

@lutter
Copy link
Member

lutter commented Feb 8, 2020

Yeah, that's unfortunate; we should just merge this as is, and live with the fact that we could have offered a better breakdown of the file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants