Bug 790753 - unable to remove deployment without manifest file when agent runs under different user as server
unable to remove deployment without manifest file when agent runs under diffe...
Product: RHQ Project
Classification: Other
Component: Content (Show other bugs)
Unspecified Linux
high Severity high (vote)
: ---
: RHQ 4.5.0
Assigned To: Stefan Negrea
Mike Foley
Depends On:
Blocks: 758753 824503
  Show dependency treegraph
Reported: 2012-02-15 05:43 EST by Libor Zoubek
Modified: 2015-11-01 19:42 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 824503 (view as bug list)
Last Closed: 2013-09-01 06:05:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Libor Zoubek 2012-02-15 05:43:18 EST
Description of problem: Latest Stefan's changes in content system added new feature: RHQ-Sha256 value is being written into manifest of deployed WAR once it becomes managed by content subsystem. My WAR is deployed exploded and it is as simple as it does not have manifest. I run server under user eap and agent under root. I come in to troubles when I need to undeploy my app (using JON UI). Agent tries to add RHQ-Sha256 to manifest and when it does not exist, it creates it, with root's permissions. 

Version-Release number of selected component (if applicable):
Version: 3.0.1.GA
Build Number: dd8a001:c5270fb

How reproducible:always

Steps to Reproduce:
1.have JON server, agent (run under root), EAP 5 (run under any non-privileged user)
2. deploy WAR without manifest to EAP as exploded
3. updateBackingContent of your WAR using CLI (I suppose that this action triggers writing RHQ-SHA256 to manifest)
4. remove WAR from server using JON UI
Actual results: remove operation seems to succeed, but deployment is rediscovered and maked as offline, on server, manifest created by JON remains in deployment's dir

Expected results: not sure, maybe agent could read and use permissions of deployment dir when creating manifest

Additional info: This is not a common usecase. Most WARs have manifest and also running agent under root is not recommended.
Comment 1 Libor Zoubek 2012-02-15 07:59:43 EST
Changing severity to high, because it actually makes sense to run agent under different user than EAP. I have tomcat6 under user tomcat and eap5 under user eap, running agent under root is one solution or having user agent being member of some group having write access to eap and tomcat dirs.
Comment 2 Mike Foley 2012-02-15 14:06:35 EST
setting target release to JON 3.1
Comment 3 Stefan Negrea 2012-02-15 14:33:18 EST
There is a general requirement that managed resources and the agent run under the same user. This extends to JBoss and Tomcat servers too. 

In AS5's case, the deployment process is handled half by the JBoss instance and half by the RHQ agent. The manifest file is created by the agent if missing or updated by the agent if present. Because in your test case the manifest file is missing, it is created but with ownership and permissions for user that started the agent. The removal process is handled exclusively by the JBoss instance. The JBoss server cannot remove cleanly the previous deployment because there are files/folders created by the agent user during deployment. So the operations fails partially leaving behind the files it does not have permissions to remove  (eg. the manifest file and it's parent folder).

Running the agent under a different user than the JBoss instance also leads to deployment issues. The removal of the original application will fail for the reasons mentioned above. When removal process fails, then agent will request a redeployment of the original application.

This is just one type of failure for running managed resources and the agent under different users. There are other types of failures for AS4 and Tomcat servers not captured by this ticket (... and outside the scope of changes for the content system).

The recommendation is to run the agent and any managed resource under the same user.
Comment 4 Mike Foley 2012-02-27 12:10:48 EST
triage 2/27/2012 asantos, loleary, crouch, mfoley 

may need documentation or explanation

JON 3.01 timeframe.
Comment 5 Charles Crouch 2012-02-27 12:12:49 EST
Two issues: 
1) rhq-agent users needs write access
2) EAP user needs to be able to delete files created by rhq-agent user
Comment 8 Charles Crouch 2012-03-06 16:27:16 EST
The preferable option here is to not to require the agent have write access at all to the EAP instance.
Comment 10 Stefan Negrea 2012-05-23 11:09:11 EDT
This BZ already had a partial fix prior to the releas of RHQ 4.4. The only case not in the original solution was storing the SHA256 for exploded deployments when creating a webapp as new child of the server. This has now been fixed.

master branch commits:

Comment 11 Heiko W. Rupp 2013-09-01 06:05:38 EDT
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.

Note You need to log in before you can comment on or make changes to this bug.