The scenario is that we have a Websphere server, for example, with 70 application JVM instances. We have a single install of the probe and apply a custom Introscope service and JVM parameters in the Websphere console on each application so that the Agent is named automatically. However, they all use the same Agent.jar and profile. The applications all run as different user accounts. So if a particular application writes to the hotdeploy directory, then another application is not the file owner and so does not have the permissions.
How should the permissions be set on the hotdeploy directory? Should I use 777? Can all applications running as different users all utilize the same folders/files in hotdeploy and extensions? Our security and UNIX admins frown on using 777.
In Linux, using 777, obviously that would be the main setting for all users to be allowed to write to the hotdeploy directory. However, 777 also is a security issue.
While 777 may be great for testing purposes, it is not great for production servers that are linked to the network. So basically this boils down to what the OS can allow and this is how APM handles the users who are allowed to write to the hotdeploy directory.
We go by those the OS will allow based on the permissions. Even if we took 1 file and tried to allow only 2 users to it, Linux would not allow it as a file can only have a single owner. You could create a group that contains the users that should have the access and make that the owning group of the file, but a lot of administrative overhead will be needed.
If your filesystem supports ACL's, then that is another option, however not every local filesystem is mounted to support ACL's.
Another option is to turn off the automatic entry point detection, if you are not using this.
To do this, set introscope.agent.deep.entrypoint.enabled to false in the IntroscopeAgent.profile. No restart is required for this property.
NOTE: If you turn this feature off, smart instrumentation still works, however you will not automatically get the following.
If you turn this feature off, smart instrumentation still works, however you will not automatically get the following. You would have to manually add these in.
- Technology stacks and frameworks that Introscope instrumentation does not already monitor
- Custom or proprietary api calls
- Background threads that consume critical resources and can affect the overall application performance