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

Portability refactor #3074

Closed
wants to merge 5 commits into from

Conversation

daurnimator
Copy link
Contributor

No description provided.

@thibaultcha
Copy link
Member

@daurnimator Thanks for the PR! No major complaint but some minor stuff on my side.

I would really like @shashiranjan84 and @p0pr0ck5 to take a look at this as well (since you contributed those plugins and/or maintain the building pipeline for our Kong release artifacts, any consequences you can foresee? Should we give this branch a try internally?).

@p0pr0ck5
Copy link
Contributor

p0pr0ck5 commented Dec 5, 2017

Seems reasonable from a build perspective at first glance. I have a few minor comments as wel. Will give this a spin through our artifact pipeline in the next few days.

@@ -9,6 +9,7 @@ local fmt = string.format
local nginx_bin_name = "nginx"
local nginx_search_paths = {
"/usr/local/openresty/nginx/sbin",
"/opt/openresty/nginx/sbin",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is almost certainly undesirable to be hardcoded. I can definitely see a case where this could be configurable, though. Maybe a separate scope of change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's already configurable; however there's much to be said for sensible defaults.
/opt/openresty/nginx/sbin is the location on a few distros, so I don't know why we wouldn't add it to places we search

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I don't see this local var being defined anywhere else? Is it in a config in forgetting about? (I suspect so, I seem to be doing that a lot lately ;)).

To me it makes the most sense to make this user-configurable if appropriate. Otherwise it just becomes an opinionated list of where we think the bin might live (the current definition is the only location that's used in officially supported distros, fwiw)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I don't see this local var being defined anywhere else? Is it in a config in forgetting about? (I suspect so, I seem to be doing that a lot lately ;)).

It's implicitly configurable via $PATH

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise it just becomes an opinionated list of where we think the bin might live

Is that not the whole point of a function called find_nginx_bin?

local format = string.format

local function tohex(s)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are bindings in lua-resty-string to ngx_hex_dump. Probably worth using that existing call than rolling our own here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kong doesn't currently have a dependency on lua-resty-string. Should I add it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lua-resty-string is built with all modern versions of openresty. Seems unnecessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

K. pushed/updated.

@@ -16,6 +23,6 @@ return {
-- @return hash of the salted credential's password
encrypt = function(credential)
local salted = salt_password(credential)
return crypto.digest("sha1", salted)
return tohex(openssl_digest.new("sha1"):final(salted))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's just use the built-in binding for sha1 composition that openresty makes available here. Using an openssl binding at all is not necessary

@daurnimator daurnimator force-pushed the refactor/daurn-portability branch 2 times, most recently from e1e5f96 to 2e03769 Compare December 11, 2017 01:39
@p0pr0ck5
Copy link
Contributor

Ran this through our build pipeline and didn't see any issues.

@thibaultcha
Copy link
Member

@p0pr0ck5 Awesome! Thanks!

@thibaultcha
Copy link
Member

I'll have a look at this on OS X today and will merge if nothing comes up, so it can go out in our upcoming 0.12.0 release.

@@ -24,7 +24,7 @@ dependencies = {
"luatz == 0.3",
"lua_system_constants == 0.1.2",
"lua-resty-iputils == 0.3.0",
"luacrypto == 0.3.2",
"luaossl == 20171028",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@daurnimator Would you mind adding the CRYPTO_DIR variable in the install rule of the Makefile as part of the same commit? It seems luaossl requires both OPENSSL_DIR and CRYPTO_DIR (previously, we only needed OPENSSL_DIR. It can probably just be:

@luarocks make OPENSSL_DIR=$(OPENSSL_DIR) CRYPTO_DIR=$(OPENSSL_DIR)

@thibaultcha
Copy link
Member

Awesome, manually merged to next and scheduled for 0.12.0 @daurnimator! Thanks!

@daurnimator daurnimator deleted the refactor/daurn-portability branch December 14, 2017 01:32
thibaultcha pushed a commit that referenced this pull request Jan 16, 2018
thibaultcha pushed a commit that referenced this pull request Jan 16, 2018
thibaultcha pushed a commit that referenced this pull request Jan 19, 2018
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.

3 participants