/opt/newrelic directory is being created owned by newrelic with permissions "0750"

[et304383]

Makes zero sense as I see the mode set to 0775 here:

https://github.com/escapestudios-cookbooks/newrelic/blob/master/providers/agent_java.rb#L34

However, here is what I end up with on my EC2 instances:

[root@ip-10-63-96-33 opt]# ll
total 16
drwxr-x--- 3 newrelic newrelic 4096 Aug 26 12:14 newrelic
[root@ip-10-63-96-33 opt]# 

As a result, tomcat fails to start as it cannot even read the jar files. Is the solution here to set these attributes to tomcat?

default['newrelic']['java_agent']['app_user'] = 'tomcat'
default['newrelic']['java_agent']['app_group'] = 'tomcat'

[djoos]

Hi @eric-tucker,

hmm, why do you see 750 instead of 755?

Yep, changing the app_user and app_group to 'tomcat' rather than 'newrelic' (default) should allow tomcat to be able to read the jar files and start...

Please do let me know how that goes!

Kind regards, David

[et304383]

So here's what I did:

• deleted /opt/newrelic
• set the app user and group attributes to tomcat
• run Chef

I ended up this time with:

drwxr-xr-x 3 root root 4096 Aug 28 11:56 newrelic

And /opt/newrelic/java:

drwxrwxr-x 3 tomcat tomcat 4096 Aug 28 11:56 java

In order words, it's all good. The puzzling thing is how on first run the owner is "newrelic".

I actually cannot reproduce this issue after tomcat is installed. I think what's happening is that if the Java agent is installed (via this cookbook) before Tomcat is installed, the tomcat user does not exist on the system so things get a little "messed" as far as directories go.

I think the issue is with my run list installing the agent before installing tomcat. I think I can fix the issue by swapping the run list order.

I will close this issue if this proves to work for first time run (when tomcat not installed yet).

[djoos]

I'd suggest to change the order - the server monitor can obviously be installed pretty soon, but the actual application monitor I'd only install once the app server-bits are all in place... (well, that's how we roll anyway ;-) )

Please do keep me updated!

[et304383]

Unfortunately changing the order did not help. I still get this weird behaviour on the parent directory:

[root@ip-10-63-96-19 ec2-user]# ll /opt
total 16
drwxr-x--- 3 newrelic newrelic 4096 Aug 28 12:20 newrelic
[root@ip-10-63-96-19 ec2-user]# ll /opt/newrelic/
total 4
drwxrwxr-x 2 tomcat tomcat 4096 Aug 28 12:20 java

Any suggestions? It seems like the Chef directory resource doesn't set permissions on parent directories correctly when using recursive true.

[et304383]

Looks like this was complained about before: https://tickets.opscode.com/browse/CHEF-1621

It just makes no sense that in this case the parent directory is being created 750 and owned by "newrelic" rather than 755 and owned by root.

[djoos]

Thanks for adding in the reference to that Chef ticket here.

The docs of the directory resource also highlight this behaviour: "For the owner, group, and mode properties, the value of this attribute applies only to the leaf directory."...

[et304383]

So in a way it's working as expected.

However, it doesn't explain the parent getting randomly owned by newrelic and set to 750. :(

[et304383]

FYI: since I use a wrapper cookbook for newrelic, I ended up adding this resource call to my wrapper around the java_agent recipe call (just before):

directory "/opt/newrelic" do
  owner "root"
  group "root"
  mode 0755
end

I got by for now but perhaps this needs to be incorporated into your cookbook when you have the chance.

Obviously this fix doesn't work if someone changes their newrelic install dir away from /opt/newrelic/java.

[patcon]

Just pasting the error that I got in my catalina.out log because of this problem, in case it helps anyone else:

Error opening zip file or JAR manifest missing : /opt/newrelic/java/newrelic.jar
Error occurred during initialization of VM
agent library failed to init: instrument

It almost seems like it's a problem of java itself though, as I see no reason why a higher level directory of /opt/newrelic/java need to be readable, so long as /opt/newrelic/java itself (and that jar file) are readable. Definitely left me spinning my wheels confused for awhile :)

[mvdkleijn]

I believe the issue here is that the agent_java provider is using root as hardcoded ownerships, causing tomcat (for example) to not be able to access the file. Though I guess you could change the permissions, I feel its cleaner to change the actual ownership.

[iiro]

Hmm. Does it work for you now? /opt/newrelic is owned by newrelic with 750 and there goes app launch... Wrapper cookbook needed still...