-
Notifications
You must be signed in to change notification settings - Fork 47
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
Fixes #29715: Add option to expose mongodb on a public interface with… #340
Conversation
14c4929
to
7103bc2
Compare
b91de9d
to
68f16cb
Compare
Actually I missed something, there is still notify => Service['httpd'] at https://github.com/theforeman/puppet-pulp/blob/master/manifests/apache.pp#L135 |
So, I think the issue is a bit simpler than I previously thought: When $expose_mongodb is changed to true in katello::pulp what happens? We don't make any changes to the actual pulp classes -- we're actually touching certs and mongodb. |
manifests/pulp.pp
Outdated
include certs::mongodb | ||
include certs::mongodb_client | ||
|
||
Class['certs::mongodb_client'] -> Class['pulp'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Class['certs::mongodb_client'] -> Class['pulp'] | |
Class['certs::mongodb_client'] ~> Class['pulp'] |
I think this will fix your issue, @ehelms
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thin kthat will only cover if the certificates get created or changed? But doesn't cover I feel the whole of the issue which is if /etc/pulp/server.conf
gets updated, then httpd
should get restarted to pick up the changes.
@ekohl adding you in case you had any thoughts as to why I don't seem to be seeing the refreshing happen
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect Pulp doesn't actually manage the vhost and thus doesn't refresh Apache. I'd try Class['certs::mongodb_client'] ~> Class['pulp', 'apache::service']
. Both since pulp
will still refresh the workers.
spec/classes/pulp_spec.rb
Outdated
|
||
context 'with mongodb_ipv6 => true' do | ||
let :params do | ||
super().merge({ 'expose_mongodb_ipv6' => true, }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've grown accustomed to the shorter syntax:
super().merge({ 'expose_mongodb_ipv6' => true, }) | |
super().merge(expose_mongodb_ipv6: true) |
manifests/pulp.pp
Outdated
include certs::mongodb | ||
include certs::mongodb_client | ||
|
||
Class['certs::mongodb_client'] -> Class['pulp'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect Pulp doesn't actually manage the vhost and thus doesn't refresh Apache. I'd try Class['certs::mongodb_client'] ~> Class['pulp', 'apache::service']
. Both since pulp
will still refresh the workers.
067dda7
to
bf4cb42
Compare
44976df
to
78191b7
Compare
This will need -- theforeman/puppet-certs#288 |
18782b4
to
2654948
Compare
manifests/pulp.pp
Outdated
|
||
Class['certs::mongodb_client'] ~> Class['pulp', 'apache::service'] | ||
|
||
$mongodb_seeds_real = "${facts['networking']['fqdn']}:27017" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Edit: Actually it should be using the hostname on the server cert:
$mongodb_seeds_real = "${facts['networking']['fqdn']}:27017" | |
$mongodb_seeds_real = "${certs::mongodb::hostname}:${mongodb::server::port}" |
The definition needs to be moved below mongodb::server
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are 99.9% of the time going to be the same thing because this is a tightly controlled scenario. But I shall may the change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The use of mongodb::server::port
is incorrect here since port is undef -- https://github.com/voxpupuli/puppet-mongodb/blob/master/manifests/server.pp#L27
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are 99.9% of the time going to be the same thing because this is a tightly controlled scenario. But I shall may the change.
The important part is showing that these are linked. That's what variables are for. It gives understanding to the reader of the code.
The use of
mongodb::server::port
is incorrect here since port is undef -- https://github.com/voxpupuli/puppet-mongodb/blob/master/manifests/server.pp#L27
Ah right. Fair enough.
efbf688
to
ca7e3e5
Compare
manifests/pulp.pp
Outdated
@@ -97,10 +104,16 @@ | |||
Optional[Stdlib::Absolutepath] $https_cert = undef, | |||
Optional[Stdlib::Absolutepath] $https_key = undef, | |||
Optional[Stdlib::Absolutepath] $https_ca_cert = undef, | |||
Boolean $expose_mongodb = false, | |||
Boolean $expose_mongodb_ipv6 = false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would this default to false? In which case are you not able to bind to IPv6? Note that in our install Redis already binds to ::1
so not having IPv6 is already a requirement. And if you go that far, why do we need a parameter for it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you are saying we can default to exposing on IPv4 and IPv6 in all cases? Is there a case where IPv4 only is required? Or IPv6 only is required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed I am. I think IPv4-only would be required if the kernel has no IPv6 support but we don't support that case anymore. I'm not sure you can actually run the Linux kernel without IPv4 support so binding should always work.
Maybe I'm missing something, but I'd prefer to at least default to true. Another option is:
Variant[Boolean, Array[Stdlib::IP::Address]] $expose_mongodb = false,
Then true
would imply dual stack. If the user needs full control over exact binding, you have it and only need a single parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I set the default to true and left it there given this is designed for a specific use case and I think the parameters provide the needed flexibility.
} | ||
|
||
$mongodb_seeds_real = "${certs::mongodb::hostname}:27017" | ||
$db_password = extlib::cache_data('foreman_cache_data', 'mongo_db_password', extlib::random_password(32)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already have $mongodb_password
as a parameter and IMH we should at least prefer that if specified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That password is intended for the use case when a user is providing credentials for an external database. I don't think it should apply to this workflow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it does. You're exposing the user with a certain password. The parameter allows the end user to specify something. That makes it easier on the consuming node to use the same password. Now the end user needs to look in files to see which password was generated.
More concrete: we have server-1.example.com
which runs Katello with Pulp and MongoDB. The user runs foreman-installer --katello-pulp-mongodb-password mysecretpassword
.
Now the user wants to consume this on server-2.example.com
. The user runs foreman-installer --foreman-proxy-content-mongo-db-password mysecretpassword
.
The current implementation doesn't support this because it's silently ignored.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My point, unless I am just missing something is, that nobody should be doing this other than our own tooling which is tightly controlled for a very specific upgrade scenario.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So how do you get the password now? Do you parse it out of a config file later on?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That will be the most likely tactic given it's the only reliable way to get the value. I think I get what you are saying now but not form the users perspective, but the if the parameter is used then it can be stored on the answers file. But I don't see how you set the parameter conditionally.
… SSL
Requires: