Red Hat Bugzilla – Bug 963332
Fix mcollective-client.log permissions
Last modified: 2017-03-08 12:39 EST
Related to: https://bugzilla.redhat.com/show_bug.cgi?id=880385 and: https://bugzilla.redhat.com/show_bug.cgi?id=849558 I don't believe a doc fix is the right way to go, I think we need to fix mcollective: - add ownership capabilities to client.cfg - allow mcollective to rely on logrotate. See this: http://markmail.org/message/5fpqyb5ncljjvthz When mcollective rolls it's log file, the new file has the wrong ownership. mcollective controls log rolling internally (doesn't rely on logrotate). Not sure we can use logrotate to fix up permissions. Notes: apparently mcollective has it's own file size limit control [1]. But it doesn't seem to be able to control ownership. Our client.cfg doesn't mention size, so it defaults to 2MB (which is what happened on my system; it got rolled at 2MB, and the new log file was owned root:root). [1] http://docs.puppetlabs.com/mcollective/reference/basic/configuration.html
mcollective is a generalized tool from puppet. there's no reason for it to be aware that it needs to deal with conflicts in ownership of its log file. perhaps, though, we could have the mcollective plugin on the broker modify the log file in its %post. or, just own the log file (perhaps have it use something other than the default).
if it's done in rpm post, what happens when the log file gets rolled ? thats the actual issue. the new log file created after rolling gets root:root
Actually, I would expect the log file after rolling to be owned by whoever was using it, which should be apache usually; but you have a point, when the mcollective client is being used by root, filling the log so it rolls would change the log file ownership. The original problem we were having was at install time - the first test would be root running "mco ping" and the log file created would belong to root. You're talking about something that is not a one-time fix. I don't think there's a good way to have mcollective change ownership when it's writing that log file. The only thing I can think of is forcing all scripts that hook into the broker code to operate as the apache user when doing so. Yikes.
We have a few options: * Monkey-patch things so our cli tools never write to mcollective-client.log * Use mcollective's syslog logger for the client I'm leaning towards syslog. We might even be able to drop a file in /etc/rsyslog.d to keep it logging in /var/log/mcollective-client.log.
I tested by created a file called /etc/rsyslog.d/mcollective-client.conf with the following content: user.* /var/log/mcollective-client2.log I then updated /etc/mcollective/client.conf with these settings: logger_type = syslog logfacility = user The "user" facility is technically the default. Unfortunately it doesn't appear that we can use custom facilities. It seems "user" or "local0-7" are used for this sort of thing. After touching /var/log/mcollective-client2.log as root both mco and the broker could write to that file with selinux enforcing. Another interesting thing is that it picked up some gear logs like: python: DEBUG: var entry /var/lib/openshift/5194dd726892df5361000001/php/env/OPENSHIFT_PHP_IDENT Apparently a python script is called when creating php apps? Whatever we do if we end up using syslog we'd likely have to also drop a file in /etc/logrotate.d.
(In reply to Brenton Leanhardt from comment #6) > Another interesting thing is that it picked up some gear logs like: > > python: DEBUG: var entry > /var/lib/openshift/5194dd726892df5361000001/php/env/OPENSHIFT_PHP_IDENT > > Apparently a python script is called when creating php apps? I think that might actually be part of the mcollective response getting dumped to DEBUG. Not sure.
One other reasonable possibility for resolving this: don't log to a file. http://docs.puppetlabs.com/mcollective/configure/client.html#logging MCo allows logging to console or syslog. If logged to console, it goes to the console (from command line) or to broker httpd error_log. If logged to syslog then it ends up in /var/log/messages unless filtered elsewhere. I would vote for console, with a log level of warn. There's rarely anything useful in this log anyway. Easy enough to doc, change the install script, make a kbase for the change. Possibly change automatically on upgrade to 2.1?
+100. I agree this isn't the most useful log in the world and it's frustrating that it causes so many problems with different users writing to it.
*** Bug 1077135 has been marked as a duplicate of this bug. ***
Should be addressed with merge of https://github.com/openshift/openshift-extras/pull/319
After installing a ose-2.1 env using the installation script, check /opt/rh/ruby193/root/etc/mcollective/client.cfg The log related configuration has been changed to: logger_type = console loglevel = warn When running oo-mco ping, there's no log appended to ruby193-mcollective-client.log, if change loglevel = debug, re-run oo-mco ping again, debug info will be printed out on terminal, not appended to log file.
This is fixed in <https://github.com/openshift/openshift-extras/blob/enterprise-2.2/enterprise/install-scripts/generic/openshift.sh> and in the openshift.sh script that is included in the current oo-install archive, <https://install.openshift.com/ose-2.2/oo-install-ose-2.2-20150825-1235.tgz>.