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

pg_gem resource needs better test for omnibus #462

Closed
lamont-granquist opened this issue Oct 30, 2017 · 13 comments

Comments

Projects
3 participants
@lamont-granquist
Copy link
Contributor

commented Oct 30, 2017

begin
chef_gem 'pg' do
compile_time true
version new_resource.version
end
rescue Gem::Installer::ExtensionBuildError, Mixlib::ShellOut::ShellCommandFailed => e

that block of code is wrong.

if the distro has a pg lib then the chef_gem will succeed and will link against the distro pg libs, which will link against the distro openssl. when the distro openssl tries to get loaded into the embedded ruby linked against the embedded openssl then everything explodes and it defeats the whole purpose of this recipe.

if the user is using omnibus then all the code in the rescue block must run -- the conditional needs to not be based on the chef_gem failing or not, but needs to be based on an is_omnibus? check. the only reason this is working for some people right now is that they accidentally do not have distro support and/or their openssl lib version happens to match the
omnibus version.

@damacus

This comment has been minimized.

Copy link
Member

commented Nov 14, 2017

thanks for pointing this one out @lamont-granquist it was mostly a late night copy 'n pasta.

I'll work on this one next as a priority.

@lamont-granquist

This comment has been minimized.

Copy link
Contributor Author

commented Nov 15, 2017

Its been there as a bug for a long time i think

@damacus

This comment has been minimized.

Copy link
Member

commented Nov 15, 2017

Indeed. The linked OpenSSL bug is a right nightmare.

I'm quite tempted to remove the resource for now and it's unreliable as to what platforms it currently builds on.

@damacus

This comment has been minimized.

Copy link
Member

commented Nov 18, 2017

So to fix this, I think we have a few options

  1. Install and configure pg_config with the lib_dir from Chef's embedded libs.
  2. Install pg gem using a non-Chef Ruby, which will link to the system libs correctly (As described in this post )

IMHO 1, is out of the question. Doing this would increase the complexity of the overall install process, and supportability of the cookbook.

Option 2 seems more reasonable (and I've just got it working), but requires either the user or us to install a modern Ruby on the system (aka 2.0+) and then use that gem binary to install pg.

@lamont-granquist

This comment has been minimized.

Copy link
Contributor Author

commented Nov 19, 2017

I'm not quite following you.

The outer block needs to be more like:

if RbConfig.ruby.scan(/(chef|opscode)/).empty?
  # not an omnibus install
  chef_gem "pg" do
    compile_time true
  end
else
  [ ... all the nasty stuff to link against omnibus ... ]
end

If you're omnibus, you never want to just do a chef_gem and try to link against the system. If you're not omnibus you never want to do all the omnibus magic.

@damacus

This comment has been minimized.

Copy link
Member

commented Nov 19, 2017

Forcing pg gem to link against the omnibus libraries all the time is, from my time looking into this, basically impossible.

You configure the pg gem and related libraries to link against a ssl library, by setting libdir in the postgresql config libdir setting.
Sadly from what I can tell the libdir is only configurable at the time that postgresql is compiled.

@lamont-granquist

This comment has been minimized.

Copy link
Contributor Author

commented Nov 20, 2017

oh lordy, i thought this built the pg libs as well as the pg gem...

@lamont-granquist

This comment has been minimized.

Copy link
Contributor Author

commented Nov 20, 2017

So from the bug report:

/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/pg-0.21.0/lib/pg_ext.so is also linked against libssl.so.1.1 and libcrypto.so.1.1

That is only coming from the pg_gem.

So it may still work to link the pg_gem against the omnibus ruby (and the omnibus openssl) while against the system pg libs. If there's no transitive dep (like the system pg libs depending on system openssl libs) then that will still work. And that's the only way this code in this cookbook would have ever worked.

At any rate the complicated side of the codeblock here has worked for at least some people and distros in the past, and all I intended was to fix up the use case so that it tried to be correct as it could possibly be.

Right now its just fairly broken since if you're on omnibus you must always do the complicated side of the codeblock in order to link against the omnibus openssl libs. Linking to the system libs only works in the cases where the openssl libs on the system and on omnibus are accidentally the same APIs.

@lamont-granquist

This comment has been minimized.

Copy link
Contributor Author

commented Nov 20, 2017

So was there ever (like 3+ years ago?) a client.rb recipe which did a source install of the postgres libraries linking against the omnibus libs? Because that is the missing piece here, and it may have gotten removed in some cookbook simplification and general streamlining to no longer support source compiles and only install packages from repos?

@lamont-granquist

This comment has been minimized.

Copy link
Contributor Author

commented Nov 20, 2017

(still the bug here would need to get solved in the simply way that i outlined above)

@dayne

This comment has been minimized.

Copy link

commented Feb 14, 2018

In case others run into this issue and the related #480 issue (which has a locked conversation so I can't toss this message there where these notes are likely more appropriate) and want to be able to move forward while a proper fix is found:

A temporary work around:

Remove the pg gem and reinstall pg gem against the install /usr/pgsql version this recipe had installed. In my case I was on CentOS trying to install an older (9.3) version of postgresql:

sudo /opt/chef/embedded/bin/gem uninstall pg
sudo /opt/chef/embedded/bin/gem install pg -v 0.21.0 -- --with-pg-config=/usr/pgsql-9.3/bin/pg_config

That got me past the uninitialized constant PGconn error and right into a psql: command not found error that I was able to work past by doing this silly dance:
sudo ln -s /usr/pgsql-9.3/bin/* /usr/local/bin

None of this is very helpful in the broader sense and I look forward to a new version of this cookbook and the pg gem that don't have this issue.

@damacus

This comment has been minimized.

Copy link
Member

commented Mar 23, 2018

Woo!

Closing because we're getting rid of the resource ;)

@damacus damacus closed this Mar 23, 2018

PostgreSQL Custom Resources automation moved this from In progress to Done Mar 23, 2018

@lock

This comment has been minimized.

Copy link

commented Mar 23, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Mar 23, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.