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:
mysql> 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 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
>>> [email protected]
>>>
>>
--
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.