Hey guys,
I've got another C7 problem I was hoping to solve. I installed appdynamics-php-agent-4.0.5.0-1.x86_64 on a C7.1 host.
It's failing to communicate with it's controller on another host. And this is the interesting part. Whether or not I have SELinux enabled, I have apache reporting SELinux problems.
[root@web1:~] #getenforce Permissive
May 10 20:47:56 web1 python[25735]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file /usr/lib/appdynamics-php5/logs/agent.log.lck.
***** Plugin catchall (100. confidence) suggests **************************... May 10 20:47:56 web1 python[25735]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file /usr/lib/appdynamics-php5/logs/agent.log.lck.
***** Plugin catchall (100. confidence) suggests **************************... May 10 20:47:57 web1 python[25735]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file /usr/lib/appdynamics-php5/logs/agent.log.lck.
***** Plugin catchall (100. confidence) suggests **************************... May 10 20:47:58 web1 python[25735]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file /usr/lib/appdynamics-php5/logs/agent.log.lck.
***** Plugin catchall (100. confidence) suggests **************************... May 10 20:48:00 web1 python[25735]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file /usr/lib/appdynamics-php5/logs/agent.log.lck.
***** Plugin catchall (100. confidence) suggests **************************... May 10 20:48:01 web1 python[25735]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file /usr/lib/appdynamics-php5/logs/agent.log.lck.
***** Plugin catchall (100. confidence) suggests **************************... May 10 20:49:16 web1 python[25952]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file /usr/lib/appdynamics-php5/logs/agent.log.lck.
***** Plugin catchall (100. confidence) suggests **************************... May 10 20:49:17 web1 python[25952]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file /usr/lib/appdynamics-php5/logs/agent.log.lck.
***** Plugin catchall (100. confidence) suggests **************************... May 10 20:53:14 web1 python[26609]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file /usr/lib/appdynamics-php5/logs/agent.log.lck.
***** Plugin catchall (100. confidence) suggests **************************... May 10 20:53:15 web1 python[26609]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file /usr/lib/appdynamics-php5/logs/agent.log.lck.
***** Plugin catchall (100. confidence) suggests **************************...
So I enabled SELinux and started troubleshooting with audit2why.
[root@web1:~] #setenforce 1 [root@web1:~] #getenforce Enforcing
And I'm seeing messages like these:
[root@web1:~] #grep appd /var/log/audit/audit.log | audit2why -w
type=AVC msg=audit(1431305820.292:393420): avc: denied { write } for pid=27289 comm="java" path="/usr/lib/appdynamics-php5/logs/testfile1615417693000946121.tmp" dev="vda" ino=965852 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file
Was caused by: Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
The part I am stuck on is using audit2allow to generate a loadable module that can allow this.
Can anyone spare any pointers on how to do that?
Thanks! Tim
------------ Original Message ------------
Date: Sunday, May 10, 2015 09:02:11 PM -0400 From: Tim Dunphy bluethundr@gmail.com
Hey guys,
I've got another C7 problem I was hoping to solve. I installed appdynamics-php-agent-4.0.5.0-1.x86_64 on a C7.1 host.
It's failing to communicate with it's controller on another host. And this is the interesting part. Whether or not I have SELinux enabled, I have apache reporting SELinux problems.
[root@web1:~] #getenforce Permissive
May 10 20:47:56 web1 python[25735]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file /usr/lib/appdynamics-php5/logs/agent.log.lck.
***** Plugin catchall (100.
That's a rather odd (personally, I think bad) place for a log (or even logfile lock) and I'm not at all surprised that selinux is keeping your application from writing there. I would check to see if there is a setup/configuration option for your application to put the log files and related in a more standard location (/var/log, /var/run), where it is less likely to run into an issue.
This isn't really a C7-specific issue/"problem".
That's a rather odd (personally, I think bad) place for a log (or even logfile lock) and I'm not at all surprised that selinux is keeping your application from writing there. I would check to see if there is a setup/configuration option for your application to put the log files and related in a more standard location (/var/log, /var/run), where it is less likely to run into an issue.
Yeah I agree that it's an unusual place to store log files. However I'm not aware of any way to change that location since it's an RPM install. Maybe a source install is possible. I'll do some googling.
This isn't really a C7-specific issue/"problem".
Yeah that's right. I said that poorly. I had just been dealing with an issue with systemctl priror to that which was due to it being a C7 machine. But really only because I had been using systemctl.
What I'm most curious about is how Apache is reporting SELinux problems whether or not SELinux is enabled. Like I said earlier, if I have SELinux set to off, you still see those kind of messages relating to SELinux when you do a status on httpd.
Odd. One thing I did try was to do a restorecon -R -v /usr/lib/appdynamics-php5/.
Since it might not be easy to change paths I was hoping to find a way to solve this using SELinux.. Does anyone else have any suggestions on how to solve this?
Thanks, Tim
On Sun, May 10, 2015 at 10:20 PM, Richard < lists-centos@listmail.innovate.net> wrote:
------------ Original Message ------------
Date: Sunday, May 10, 2015 09:02:11 PM -0400 From: Tim Dunphy bluethundr@gmail.com
Hey guys,
I've got another C7 problem I was hoping to solve. I installed appdynamics-php-agent-4.0.5.0-1.x86_64 on a C7.1 host.
It's failing to communicate with it's controller on another host. And this is the interesting part. Whether or not I have SELinux enabled, I have apache reporting SELinux problems.
[root@web1:~] #getenforce Permissive
May 10 20:47:56 web1 python[25735]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file /usr/lib/appdynamics-php5/logs/agent.log.lck.
***** Plugin catchall (100.
That's a rather odd (personally, I think bad) place for a log (or even logfile lock) and I'm not at all surprised that selinux is keeping your application from writing there. I would check to see if there is a setup/configuration option for your application to put the log files and related in a more standard location (/var/log, /var/run), where it is less likely to run into an issue.
This isn't really a C7-specific issue/"problem".
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, May 11, 2015 9:47 am, Tim Dunphy wrote:
That's a rather odd (personally, I think bad) place for a log (or even logfile lock) and I'm not at all surprised that selinux is keeping your application from writing there. I would check to see if there is a setup/configuration option for your application to put the log files and related in a more standard location (/var/log, /var/run), where it is less likely to run into an issue.
Yeah I agree that it's an unusual place to store log files. However I'm not aware of any way to change that location since it's an RPM install.
If rpm is configured for _that_ location of log files, I would remove the repository this rpm comes from from configuration and will remember to never-never ever use that repository for anything.
Just my $0.02
Valeri
Maybe a source install is possible. I'll do some googling.
This isn't really a C7-specific issue/"problem".
Yeah that's right. I said that poorly. I had just been dealing with an issue with systemctl priror to that which was due to it being a C7 machine. But really only because I had been using systemctl.
What I'm most curious about is how Apache is reporting SELinux problems whether or not SELinux is enabled. Like I said earlier, if I have SELinux set to off, you still see those kind of messages relating to SELinux when you do a status on httpd.
Odd. One thing I did try was to do a restorecon -R -v /usr/lib/appdynamics-php5/.
Since it might not be easy to change paths I was hoping to find a way to solve this using SELinux.. Does anyone else have any suggestions on how to solve this?
Thanks, Tim
On Sun, May 10, 2015 at 10:20 PM, Richard < lists-centos@listmail.innovate.net> wrote:
------------ Original Message ------------
Date: Sunday, May 10, 2015 09:02:11 PM -0400 From: Tim Dunphy bluethundr@gmail.com
Hey guys,
I've got another C7 problem I was hoping to solve. I installed appdynamics-php-agent-4.0.5.0-1.x86_64 on a C7.1 host.
It's failing to communicate with it's controller on another host. And this is the interesting part. Whether or not I have SELinux enabled, I have apache reporting SELinux problems.
[root@web1:~] #getenforce Permissive
May 10 20:47:56 web1 python[25735]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file /usr/lib/appdynamics-php5/logs/agent.log.lck.
***** Plugin catchall (100.
That's a rather odd (personally, I think bad) place for a log (or even logfile lock) and I'm not at all surprised that selinux is keeping your application from writing there. I would check to see if there is a setup/configuration option for your application to put the log files and related in a more standard location (/var/log, /var/run), where it is less likely to run into an issue.
This isn't really a C7-specific issue/"problem".
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
If rpm is configured for _that_ location of log files, I would remove the repository this rpm comes from from configuration and will remember to never-never ever use that repository for anything.
Just my $0.02
Yeah I completely get where you're coming from there. However it's not an RPM from a repo. I downloaded the rpm from the appdynamics site itself. While it may be easy to say "well then just don't use appdynamics"! That's not a luxury I have. My company uses it and I need to get up to speed on how to work with it. So that's why I'm trying out this experiment.
Thanks, Tim
On Mon, May 11, 2015 at 11:22 AM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On Mon, May 11, 2015 9:47 am, Tim Dunphy wrote:
That's a rather odd (personally, I think bad) place for a log (or even logfile lock) and I'm not at all surprised that selinux is keeping your application from writing there. I would check to see if there is a setup/configuration option for your application to put the log files and related in a more standard location (/var/log, /var/run), where it is less likely to run into an issue.
Yeah I agree that it's an unusual place to store log files. However I'm not aware of any way to change that location since it's an RPM install.
If rpm is configured for _that_ location of log files, I would remove the repository this rpm comes from from configuration and will remember to never-never ever use that repository for anything.
Just my $0.02
Valeri
Maybe a source install is possible. I'll do some googling.
This isn't really a C7-specific issue/"problem".
Yeah that's right. I said that poorly. I had just been dealing with an issue with systemctl priror to that which was due to it being a C7 machine. But really only because I had been using systemctl.
What I'm most curious about is how Apache is reporting SELinux problems whether or not SELinux is enabled. Like I said earlier, if I have SELinux set to off, you still see those kind of messages relating to SELinux when you do a status on httpd.
Odd. One thing I did try was to do a restorecon -R -v /usr/lib/appdynamics-php5/.
Since it might not be easy to change paths I was hoping to find a way to solve this using SELinux.. Does anyone else have any suggestions on how
to
solve this?
Thanks, Tim
On Sun, May 10, 2015 at 10:20 PM, Richard < lists-centos@listmail.innovate.net> wrote:
------------ Original Message ------------
Date: Sunday, May 10, 2015 09:02:11 PM -0400 From: Tim Dunphy bluethundr@gmail.com
Hey guys,
I've got another C7 problem I was hoping to solve. I installed appdynamics-php-agent-4.0.5.0-1.x86_64 on a C7.1 host.
It's failing to communicate with it's controller on another host. And this is the interesting part. Whether or not I have SELinux enabled, I have apache reporting SELinux problems.
[root@web1:~] #getenforce Permissive
May 10 20:47:56 web1 python[25735]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file /usr/lib/appdynamics-php5/logs/agent.log.lck.
***** Plugin catchall (100.
That's a rather odd (personally, I think bad) place for a log (or even logfile lock) and I'm not at all surprised that selinux is keeping your application from writing there. I would check to see if there is a setup/configuration option for your application to put the log files and related in a more standard location (/var/log, /var/run), where it is less likely to run into an issue.
This isn't really a C7-specific issue/"problem".
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, May 11, 2015 10:38 am, Tim Dunphy wrote:
If rpm is configured for _that_ location of log files, I would remove the repository this rpm comes from from configuration and will remember to never-never ever use that repository for anything.
Just my $0.02
Yeah I completely get where you're coming from there. However it's not an RPM from a repo. I downloaded the rpm from the appdynamics site itself. While it may be easy to say "well then just don't use appdynamics"! That's not a luxury I have. My company uses it and I need to get up to speed on how to work with it. So that's why I'm trying out this experiment.
OK, then this is what I would do: create some benign place for that, say,
/opt/appdynamics
Then install rpm with "--root /opt/appdynamics" option. This will force rpm prepend all paths with "/opt/appdynamics". Instead of, say, putting something into /usr/lib, it will put this stuff into /opt/appdynamics/usr/lib (and will create missing paths there when necessary). So:
rpm -ivh --root /opt/appdynamics/ [your appdynamics rpm name].rpm
After that done, you may need to describe the paths to binaries, libraries there, say, by adding for libraries:
echo "/opt/appdynamics" >> /etc/ld.so.conf /sbin/ldconfig -v
and adding extra paths to, say, /etc/profile...
I hope, this helps.
Valeri
Thanks, Tim
On Mon, May 11, 2015 at 11:22 AM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On Mon, May 11, 2015 9:47 am, Tim Dunphy wrote:
That's a rather odd (personally, I think bad) place for a log (or even logfile lock) and I'm not at all surprised that selinux is keeping your application from writing there. I would check to see if there is a setup/configuration option for your application to put the log files and related in a more standard location (/var/log, /var/run), where it is less likely to run into an issue.
Yeah I agree that it's an unusual place to store log files. However
I'm
not aware of any way to change that location since it's an RPM install.
If rpm is configured for _that_ location of log files, I would remove the repository this rpm comes from from configuration and will remember to never-never ever use that repository for anything.
Just my $0.02
Valeri
Maybe a source install is possible. I'll do some googling.
This isn't really a C7-specific issue/"problem".
Yeah that's right. I said that poorly. I had just been dealing with an issue with systemctl priror to that which was due to it being a C7 machine. But really only because I had been using systemctl.
What I'm most curious about is how Apache is reporting SELinux
problems
whether or not SELinux is enabled. Like I said earlier, if I have
SELinux
set to off, you still see those kind of messages relating to SELinux
when
you do a status on httpd.
Odd. One thing I did try was to do a restorecon -R -v /usr/lib/appdynamics-php5/.
Since it might not be easy to change paths I was hoping to find a way
to
solve this using SELinux.. Does anyone else have any suggestions on
how to
solve this?
Thanks, Tim
On Sun, May 10, 2015 at 10:20 PM, Richard < lists-centos@listmail.innovate.net> wrote:
------------ Original Message ------------
Date: Sunday, May 10, 2015 09:02:11 PM -0400 From: Tim Dunphy bluethundr@gmail.com
Hey guys,
I've got another C7 problem I was hoping to solve. I installed appdynamics-php-agent-4.0.5.0-1.x86_64 on a C7.1 host.
It's failing to communicate with it's controller on another host. And this is the interesting part. Whether or not I have SELinux enabled, I have apache reporting SELinux problems.
[root@web1:~] #getenforce Permissive
May 10 20:47:56 web1 python[25735]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file /usr/lib/appdynamics-php5/logs/agent.log.lck.
***** Plugin catchall (100.
That's a rather odd (personally, I think bad) place for a log (or even logfile lock) and I'm not at all surprised that selinux is keeping your application from writing there. I would check to see if there is a setup/configuration option for your application to put the log files and related in a more standard location (/var/log, /var/run), where it is less likely to run into an issue.
This isn't really a C7-specific issue/"problem".
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Tim Dunphy wrote:
If rpm is configured for _that_ location of log files, I would remove the repository this rpm comes from from configuration and will remember to never-never ever use that repository for anything.
Just my $0.02
Yeah I completely get where you're coming from there. However it's not an RPM from a repo. I downloaded the rpm from the appdynamics site itself. While it may be easy to say "well then just don't use appdynamics"! That's not a luxury I have. My company uses it and I need to get up to
speed on
how to work with it. So that's why I'm trying out this experiment.
No, that's called "bug report", or "enhancement request".
mark "and is done by amateurs, or 'subject matter experts', who think they know how to do the computer side...."
Well, I was having a heck of a time with the rpm install in terms of customizing the install directory.
So I thought the easy way out might be to go for a source install. Which I tried and this was the output from the install:
[root@web1:/opt/AppDynamics/appdynamics-php-agent] #./install.sh appd.jokefire.com 443 beta.jokefire.com "Web Front End" web1.jokefire.com Install script for AppDynamics PHP Agent 4.0.5.0GA.8351.c72adcc398473f98f9cb976a652747d94c617ec9 Found PHP installation in /bin
Detected PHP Version: PHP 5.4.40 (cli) (built: Apr 15 2015 15:44:44) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
PHP version id: 5.4 PHP extensions directory: /usr/lib64/php/modules PHP ini directory: /etc/php.d Controller Host: appd.mydomain.com Controller Port: 443 Application Name: beta.mydomain.com Tier Name: Web Front End Node Name: web1.mydomain.com Account Name: Access Key: SSL Enabled: false HTTP Proxy Host: HTTP Proxy Port: HTTP Proxy User: HTTP Proxy Password File:
Writing '/opt/AppDynamics/appdynamics-php-agent/php/conf/appdynamics_agent_log4cxx.xml' Writing '/etc/php.d/appdynamics_agent.ini' Writing '/opt/AppDynamics/appdynamics-php-agent/proxy/conf/controller-info.xml' rm -f "/usr/lib64/php/modules/appdynamics_agent.so" ln -s "/opt/AppDynamics/appdynamics-php-agent/php/modules/ appdynamics_agent_php_5.4.so" "/usr/lib64/php/modules/appdynamics_agent.so" Writing '/opt/AppDynamics/appdynamics-php-agent/proxy/runProxy'
That seemed a little more like it! At least it's out of the way and in a directory that's a little easier to control - /opt. And also I was able to specify some important information like what appd controller I was using etc that I wasn't using a source install.
However, I found that really strange SELinux just followed me to the new location. Sigh...
[root@web1:~] #systemctl status httpd httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled) Active: active (running) since Mon 2015-05-11 22:31:36 EDT; 26s ago Process: 14829 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=0/SUCCESS) Process: 25728 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS) Main PID: 14840 (httpd) Status: "Total requests: 19; Current requests/sec: 1.2; Current traffic: 614 B/sec" CGroup: /system.slice/httpd.service ├─14840 /usr/sbin/httpd -DFOREGROUND ├─14844 /usr/sbin/httpd -DFOREGROUND ├─14845 /usr/sbin/httpd -DFOREGROUND ├─14846 /usr/sbin/httpd -DFOREGROUND ├─14848 /usr/sbin/httpd -DFOREGROUND ├─14849 /usr/sbin/httpd -DFOREGROUND ├─14850 /opt/AppDynamics/appdynamics-php-agent/proxy/jre/bin/java -server -Xmx300m -Xms50m -classpath /opt/AppDynamics/appdynamics-php-agent/proxy/conf/logging:/opt/AppDynamics/appdynamics-p... ├─14905 /usr/sbin/httpd -DFOREGROUND ├─32210 /usr/bin/newrelic-daemon -A -s -p /var/run/newrelic-daemon.pid -l /var/log/newrelic/newrelic-daemon.log -d verbosedebug └─32211 /usr/bin/newrelic-daemon -A -s -p /var/run/newrelic-daemon.pid -l /var/log/newrelic/newrelic-daemon.log -d verbosedebug
May 11 22:31:38 web1 python[14832]: SELinux is preventing /opt/AppDynamics/appdynamics-php-agent/proxy/jre/bin/java from unlink access on the file testfile7644450607057334348.tmp.
***** Plugin catchall_labels (83.8 confidence) suggests *******************... May 11 22:31:38 web1 python[14832]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from block_suspend access on the capability2 Unknown.
***** Plugin catchall (100. confidence) suggests **************************... May 11 22:31:39 web1 python[14832]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the directory lib.
***** Plugin catchall (100. confidence) suggests **************************... May 11 22:31:39 web1 python[14832]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from write access on the file libjzmq.so.0.
***** Plugin catchall (100. confidence) suggests **************************... May 11 22:31:39 web1 python[14832]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from setattr access on the file libjzmq.so.0.
***** Plugin catchall (100. confidence) suggests **************************... May 11 22:31:40 web1 python[14832]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from setattr access on the directory tp.
***** Plugin catchall (100. confidence) suggests **************************... May 11 22:31:40 web1 python[14832]: SELinux is preventing /opt/AppDynamics/appdynamics-php-agent/proxy/jre/bin/java from setattr access on the file runProxy.template.
***** Plugin catchall_labels (83.8 confidence) suggests *******************... May 11 22:31:40 web1 python[14832]: SELinux is preventing /usr/sbin/httpd from setattr access on the directory logging.
***** Plugin catchall_labels (83.8 confidence) suggests *******************... May 11 22:31:43 web1 python[14832]: SELinux is preventing /opt/AppDynamics/appdynamics-php-agent/proxy/jre/bin/java from write access on the file agent.log.lck.
***** Plugin catchall_labels (83.8 confidence) suggests *******************... May 11 22:31:43 web1 python[14832]: SELinux is preventing /usr/sbin/httpd from append access on the file agent.log.
***** Plugin catchall_labels (83.8 confidence) suggests *******************...
Why is that odd? Well mainly because I have SELinux off at the moment.
[root@web1:~] #getenforce 0 Permissive
I also tried a restorecon -R -v /opt/AppDynamics. But even after doing that the SELinux errors in the output of systemctl status httpd are still happening.
And if I take a look at the SELinux permissions on that directory, this is what I have:
[root@web1:~] #ls -lZ /opt/ | grep -i appd drwxr-xr-x. apache apache unconfined_u:object_r:usr_t:s0 AppDynamics
[root@web1:~] #ls -lZ /opt/AppDynamics/ drwxrwxr-x. apache apache unconfined_u:object_r:usr_t:s0 appdynamics-php-agent drwxr-xr-x. apache apache unconfined_u:object_r:usr_t:s0 var
Anyone have any ideas on how I can beat this problem?
Thanks!! Tim
On Mon, May 11, 2015 at 3:08 PM, m.roth@5-cent.us wrote:
Tim Dunphy wrote:
If rpm is configured for _that_ location of log files, I would remove the repository this rpm comes from from configuration and will remember to never-never ever use that repository for anything.
Just my $0.02
Yeah I completely get where you're coming from there. However it's not an RPM from a repo. I downloaded the rpm from the appdynamics site itself. While it may be easy to say "well then just don't use appdynamics"! That's not a luxury I have. My company uses it and I need to get up to
speed on
how to work with it. So that's why I'm trying out this experiment.
No, that's called "bug report", or "enhancement request".
mark "and is done by amateurs, or 'subject matter experts', who think they know how to do the computer side...."
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 12 May 2015, at 03:39, Tim Dunphy bluethundr@gmail.com wrote: ***** Plugin catchall_labels (83.8 confidence) suggests *******************... May 11 22:31:38 web1 python[14832]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from block_suspend access on the capability2 Unknown.
Why is that odd? Well mainly because I have SELinux off at the moment.
[root@web1:~] #getenforce 0 Permissive
This means SELinux is ON in a kind of testing mode. It is only reporting what would be blocked and not "enforcing" anything. So the messages are basically informing you that you WILL have problems IF you enable enforcing mode.
Checking AppDynamic PHP agent it does not support SELinux (which is insanely poor for the license cost!) so best you can do is ignore the messages. It may be better to contact their support channels for help too rather then here if you need any more.
Disabling SELinux completely should stop the messages appearing completely, though I advise against anything but enforcing mode.
Jason
Hi Jason,
This means SELinux is ON in a kind of testing mode. It is only reporting what would be blocked and not "enforcing" anything. So the messages are basically informing you that you WILL have problems IF you enable enforcing mode. Checking AppDynamic PHP agent it does not support SELinux (which is insanely poor for the license cost!) so best you can do is ignore the messages. It may be better to contact their support channels for help too rather then here if you need any more. Disabling SELinux completely should stop the messages appearing completely, though I advise against anything but enforcing mode
OK thanks. That makes complete sense. I do plan on enabling SELinux enforcing mode soon! And I find it more than a little surprising that the appdynamics php agent won't support SELinux. I'll have to bring this up to them, we have a pretty big account with them.
Thanks! Tim
On Tue, May 12, 2015 at 1:47 AM, Jason Woods devel@jasonwoods.me.uk wrote:
On 12 May 2015, at 03:39, Tim Dunphy bluethundr@gmail.com wrote: ***** Plugin catchall_labels (83.8 confidence) suggests *******************... May 11 22:31:38 web1 python[14832]: SELinux is preventing /usr/lib/appdynamics-php5/proxy/jre/bin/java from block_suspend access on the capability2 Unknown.
Why is that odd? Well mainly because I have SELinux off at the moment.
[root@web1:~] #getenforce 0 Permissive
This means SELinux is ON in a kind of testing mode. It is only reporting what would be blocked and not "enforcing" anything. So the messages are basically informing you that you WILL have problems IF you enable enforcing mode.
Checking AppDynamic PHP agent it does not support SELinux (which is insanely poor for the license cost!) so best you can do is ignore the messages. It may be better to contact their support channels for help too rather then here if you need any more.
Disabling SELinux completely should stop the messages appearing completely, though I advise against anything but enforcing mode.
Jason _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Am 11.05.2015 um 16:47 schrieb Tim Dunphy bluethundr@gmail.com:
That's a rather odd (personally, I think bad) place for a log (or even logfile lock) and I'm not at all surprised that selinux is keeping your application from writing there. I would check to see if there is a setup/configuration option for your application to put the log files and related in a more standard location (/var/log, /var/run), where it is less likely to run into an issue.
Yeah I agree that it's an unusual place to store log files. However I'm not aware of any way to change that location since it's an RPM install. Maybe a source install is possible. I'll do some googling.
This isn't really a C7-specific issue/"problem".
Yeah that's right. I said that poorly. I had just been dealing with an issue with systemctl priror to that which was due to it being a C7 machine. But really only because I had been using systemctl.
What I'm most curious about is how Apache is reporting SELinux problems whether or not SELinux is enabled. Like I said earlier, if I have SELinux set to off, you still see those kind of messages relating to SELinux when you do a status on httpd.
Odd. One thing I did try was to do a restorecon -R -v /usr/lib/appdynamics-php5/.
Since it might not be easy to change paths I was hoping to find a way to solve this using SELinux.. Does anyone else have any suggestions on how to solve this?
what was mentioned was the run time configuration. Despite the install location some application allow to specify alternative argument, e.g.
/usr/bin/mycomapp --logfile /var/log/mycomapp/mycomapp.log
or via configuration file
# grep LOGFILE /etc/mycomapp/mycomapp.conf LOGFILE=/var/log/mycomapp/mycomapp.log
-- LF