On Thursday, June 23, 2016 at 1:20:32 AM UTC-7, Dominic Cleal wrote:
>
> On 23/06/16 09:17, Thomas Cheng wrote:
> > On Thursday, June 23, 2016 at 12:56:54 AM UTC-7, Dominic Cleal wrote:
> >
> > On 23/06/16 08:34, Thomas Cheng wrote:
> > 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.
>
> If the audit is reporting that the _default_ value changes, then that's
> probably an issue that I don't think you can fix by setting the value in
> the UI or the settings file. You could file it.
>
> Yeah, Let me clarify it a little bit, I am not clear what '_default_'
value means.
Say, I have 3 servers Sa, Sb, Sc, and I set the value of unattended URL to
be 'LB_fixed_url' through Administer -> settings -> Provisioning,
then that value is fixed and not changed at all, this can be confirmed
either through MySQL table 'settings' (select * from settings where name
like 'unattended%');
or just visit the Administer -> settings -> Provisioning page a few times.
Though, the Foreman Audits pages have tons of entries in the history:
Update Setting: unattended_url
Items | old | new
Default | http://Sa | http://Sb
Default | http://Sc | http://Sa
Default | http:// Sb | http://Sc
...
Could be a bug -- I runs latest stable release 1.11.3.
> > > 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.
>
> Right, it should be false for a shared database. I don't see a reason
> you'd need it enabled for a pre-existing shared database.
>
> --
> 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.
