On Thursday, June 23, 2016 at 12:56:54 AM UTC-7, Dominic Cleal wrote:
>
> On 23/06/16 08:34, Thomas Cheng wrote:
> > Hi all,
> >
> > I've just begun to scale up Foreman as more blade servers to support.
> > I've leveraged an all-in-one setup for some time before and it has been
> > a very pleasure experience.
> >
> > But when I try to scale it up now -- in fact I setup a new cluster
> > (1.11.3) to avoid screwing up existing setup -- it posts me many
> > challenges, one of the tough one is this:
> >
> > Foreman Audits shows that settings updated too often -- cluster
> > members steps on each other on options(values) like:
> >
> > oauth consumer keys/secret, ssl_priv_keys, foreman_url,
> > unattended_url, etc.
>
> oauth_consumer_key/secret is usually written in
> /etc/foreman/settings.yaml on each installation when using the
> installer, so you should ensure these are all the same to prevent them
> changing. You can pass --foreman-oauth-consumer-key/secret to the
> installer to set them (this is in addition to the similar options you've
> already got).
>
Thanks, I run it with your option on all members and the
oauth_consumer_key/secret issues disappear:
foreman-installer -v --foreman-oauth-consumer-key=<1stserverOauthKey>
--foreman-oauth-consumer-secert=<1stserverOauthSecret>
>
> ssl_* settings, foreman_url and unattended_url depend on the host's
> FQDN, which is probably why they're changing. If you edit these under
> Administer > Settings, or write them into settings.yaml, setting them to
> the right FQDN and paths, then they should stay with your customisations
> without being changed.
>
This part is confusing, I did set the ssl_*, foreman_url and unattended_url
through Administer > Settings to FIXed valued -- let me explain:
1, on each machine I symlinked ssl_FQDN* to
/etc/pki/tls/{private/foreman.key, certs/foreman.crt}, then I use the
latter.
2, for foreman_url and unattended_url I directly use the Load balanced
based URL.
Every time I comes back to Administer -> Settings these values are the same
-- not changed at all. But Foreman Audits shows that FQDN based values
overwrite each other all the time, I'm pretty confused how it happens.
Does that mean there are some settings -- foreman/foreman-proxy settings
files on disk -- need to be updated, please elaborate. Thanks.
>
> > And, should I set the option
> > --foreman-db-manage=true?
> > I am not clear how the option '--foreman-db-manage' works behind the
> > scene, say, if two cluster members both set the option to 'true', does
> > the second member will overwrite the first one?
>
> db-manage controls two things:
>
> 1. Whether the installer configures a database server.
> 2. Whether the installer runs db:migrate/db:seed/apipie:cache:index.
>
> If you have a shared database then it should be false as you don't
> require a local database server. You also will probably not need to run
> db:migrate/seed from the installer as it's already been run against the
> database once.
>
> Yes, I do have a shared database for 'foreman' DB. when I set
'--foreman-db-mange' to be 'true' (and MySQL driver), I see that the
installer always trying to create/run a local (same machine) MySQL
instance, although it still writes table/date into remote shared database.
That's why I set the option '--foreman-db-mange' to be 'false', as I
prefer not to bring up one (empty)database process on each member server.
Does that have any (not good) side effects? Thanks.
I tried to debug the 'foreman-installer' process, but there are so many
ruby debugger issues as these are RHEL/Centos 6 boxes.
--
> Dominic Cleal
> [email protected] <javascript:>
>
--
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.
