Please help: Foreman Audits shows settings updates stepping on each other

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.

I don't know how this mess came into being – My scale-out setup is like
this:

1, install an new all-in-one foreman,
2, install puppet master nodes with options like:
foreman-installer -v
–enable-foreman --enable-foreman-cli enable-foreman-proxy
–enable-puppet
–foreman-proxy-oauth-key=<1stNodesOauthKey>
–foreman-proxy-oauth-secret=<1stNodesOautSecret>
–forman-db-manage=false
–foreman-proxy-puppetca=false --foreman-proxy-tftp=false
–puppet-server=true --puppet-server-ca=false
–puppet-ca-server=<firstServer>
3, then I setup a load balance to distribute load to new puppet master
nodes, and create a smart proxy (puppet master service) out of load
balancer.

The strategy works not bad, from web UI the health of new smart proxy seems
in good shape, and I can see service (puppet master) behind it;
on new puppet masters I can also run node.rb (under puppet account) account
to get expected yaml output.

So my question is: why the audit reports so many (stepping on each other)
issues? How can I fix it? 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?

Thanks a lot.

> 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).

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.

> 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.

··· On 23/06/16 08:34, Thomas Cheng wrote:


Dominic Cleal
dominic@cleal.org

>
> > 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.

··· On Thursday, June 23, 2016 at 12:56:54 AM UTC-7, Dominic Cleal wrote: > On 23/06/16 08:34, Thomas Cheng wrote:

Dominic Cleal
dom...@cleal.org <javascript:>

>
> 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.

> > 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.

··· 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:


Dominic Cleal
dominic@cleal.org

>
> >
> > 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.

··· 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:
>  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
dom...@cleal.org <javascript:>

This is updating the default value I was referring to above, which is
persisted alongside the value you're setting. #14954 tracks removing
this from auditing, though for a different reason.

··· On 23/06/16 09:54, Thomas Cheng wrote: > > > 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


Dominic Cleal
dominic@cleal.org

>
> >
> >
> >
> > >
> > > 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
>
> This is updating the default value I was referring to above, which is
> persisted alongside the value you're setting. #14954 tracks removing
> this from auditing, though for a different reason.
>

Thanks for Confirmation. In my version (latest stable 1.11.3) seems this
problem exists.
I looked at the issue your mentioned here
Bug #14954: Stop auditing the default field in settings - Foreman,
it was last updated one month ago, and 1.11.3 was built on Jun 21, 2016 (
two days ago),
so can I assume that a sub-minor release, say, 1.11.4/5/6 recently may have
a plan to patch it?

a backport patch, if possible, will be great if no recent plan to merge
into master branch.

··· On Thursday, June 23, 2016 at 3:15:21 AM UTC-7, Dominic Cleal wrote: > On 23/06/16 09:54, Thomas Cheng wrote: > > 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:


Dominic Cleal
dom...@cleal.org <javascript:>

I have a clustered setup as well and somewhere around 1.10-ish even though
settings like unattended url and the like are the same on each of my nodes
in the config file and set through the UI I still get that they have been
changed in the Audit log. I haven't had time to dig into it yet though. . .
really busy with other stuff and it doesn't seem to be impactful.

··· On Thursday, June 23, 2016 at 12:41:54 PM UTC-4, Thomas Cheng wrote: > > > > On Thursday, June 23, 2016 at 3:15:21 AM UTC-7, Dominic Cleal wrote: >> >> On 23/06/16 09:54, Thomas Cheng wrote: >> > >> > >> > 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 >> >> This is updating the default value I was referring to above, which is >> persisted alongside the value you're setting. #14954 tracks removing >> this from auditing, though for a different reason. >> > > Thanks for Confirmation. In my version (latest stable 1.11.3) seems this > problem exists. > I looked at the issue your mentioned here > http://projects.theforeman.org/issues/14954, > it was last updated one month ago, and 1.11.3 was built on Jun 21, 2016 ( > two days ago), > so can I assume that a sub-minor release, say, 1.11.4/5/6 recently may > have a plan to patch it? > > a backport patch, if possible, will be great if no recent plan to merge > into master branch. > > >> -- >> Dominic Cleal >> dom...@cleal.org >> >

There isn't a patch to fix it yet, so I can't really comment. If it's
fixed then it will probably go into a subsequent patch release too,
which is more likely to be 1.12 than 1.11 currently.

··· On 23/06/16 17:41, Thomas Cheng wrote: > Thanks for Confirmation. In my version (latest stable 1.11.3) seems this > problem exists. > I looked at the issue your mentioned here > http://projects.theforeman.org/issues/14954, > it was last updated one month ago, and 1.11.3 was built on Jun 21, 2016 > ( two days ago), > so can I assume that a sub-minor release, say, 1.11.4/5/6 recently may > have a plan to patch it? > > a backport patch, if possible, will be great if no recent plan to merge > into master branch.


Dominic Cleal
dominic@cleal.org

>
> I have a clustered setup as well and somewhere around 1.10-ish even though
> settings like unattended url and the like are the same on each of my nodes
> in the config file and set through the UI I still get that they have been
> changed in the Audit log. I haven't had time to dig into it yet though. . .
> really busy with other stuff and it doesn't seem to be impactful.
>
> Agree. The major effect is that human changes (needed to be audited) are
immersed in these messages.

I can select, have a pick, these audited messages with the following
command:

> select * from audits where auditable_type='Setting' and
action='update' and auditable_name in ('unattended_url', 'ssl_priv_key',
'ssl_certificate', 'foreman_url') and audited_changes like '%default:%'
limit 3\G

So, question is: is it safe to remove/purge the above audited messages
(generated by Foreman itself) with 'mysql delete …'? any other tables or
foreman codes refer to some fields of this table, directly or indirectly?
Thanks a lot.

··· On Thursday, June 23, 2016 at 2:55:38 PM UTC-7, Christopher Pisano wrote:

On Thursday, June 23, 2016 at 12:41:54 PM UTC-4, Thomas Cheng wrote:

On Thursday, June 23, 2016 at 3:15:21 AM UTC-7, Dominic Cleal wrote:

On 23/06/16 09:54, Thomas Cheng wrote:

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

This is updating the default value I was referring to above, which is
persisted alongside the value you’re setting. #14954 tracks removing
this from auditing, though for a different reason.

Thanks for Confirmation. In my version (latest stable 1.11.3) seems this
problem exists.
I looked at the issue your mentioned here
Bug #14954: Stop auditing the default field in settings - Foreman,
it was last updated one month ago, and 1.11.3 was built on Jun 21, 2016 (
two days ago),
so can I assume that a sub-minor release, say, 1.11.4/5/6 recently may
have a plan to patch it?

a backport patch, if possible, will be great if no recent plan to merge
into master branch.


Dominic Cleal
dom...@cleal.org

Yes, it should be safe to remove these.

··· On 24/06/16 00:08, Thomas Cheng wrote: > > > On Thursday, June 23, 2016 at 2:55:38 PM UTC-7, Christopher Pisano wrote: > > I have a clustered setup as well and somewhere around 1.10-ish even > though settings like unattended url and the like are the same on > each of my nodes in the config file and set through the UI I still > get that they have been changed in the Audit log. I haven't had time > to dig into it yet though. . . really busy with other stuff and it > doesn't seem to be impactful. > > Agree. The major effect is that human changes (needed to be audited) are > immersed in these messages. > > I can select, have a pick, these audited messages with the following > command: > > > select * from audits where auditable_type='Setting' and > action='update' and auditable_name in ('unattended_url', 'ssl_priv_key', > 'ssl_certificate', 'foreman_url') and audited_changes like '%default:%' > limit 3\G > > So, question is: is it safe to remove/purge the above audited messages > (generated by Foreman itself) with 'mysql delete ...'? any other tables > or foreman codes refer to some fields of this table, directly or > indirectly? Thanks a lot.


Dominic Cleal
dominic@cleal.org

>
> >
> >
> >
> > I have a clustered setup as well and somewhere around 1.10-ish even
> > though settings like unattended url and the like are the same on
> > each of my nodes in the config file and set through the UI I still
> > get that they have been changed in the Audit log. I haven't had time
> > to dig into it yet though. . . really busy with other stuff and it
> > doesn't seem to be impactful.
> >
> > Agree. The major effect is that human changes (needed to be audited) are
> > immersed in these messages.
> >
> > I can select, have a pick, these audited messages with the following
> > command:
> >
> > > select * from audits where auditable_type='Setting' and
> > action='update' and auditable_name in ('unattended_url', 'ssl_priv_key',
> > 'ssl_certificate', 'foreman_url') and audited_changes like '%default:%'
> > limit 3\G
> >
> > So, question is: is it safe to remove/purge the above audited messages
> > (generated by Foreman itself) with 'mysql delete …'? any other tables
> > or foreman codes refer to some fields of this table, directly or
> > indirectly? Thanks a lot.
>
> Yes, it should be safe to remove these.
>
> Great. I'll setup a cron to clean it from time to time. Thanks for
confirmation.

··· On Monday, June 27, 2016 at 12:34:34 AM UTC-7, Dominic Cleal wrote: > On 24/06/16 00:08, Thomas Cheng wrote: > > On Thursday, June 23, 2016 at 2:55:38 PM UTC-7, Christopher Pisano > wrote:


Dominic Cleal
dom...@cleal.org <javascript:>