Bug 1043091

Summary:	jboss-on-agent rpm to download agent from server to avoid version mismatch troubles
Product:	[JBoss] JBoss Operations Network	Reporter:	Aleksandar Kostadinov <akostadi>
Component:	Agent	Assignee:	Stefan Negrea <snegrea>
Status:	CLOSED NOTABUG	QA Contact:	Mike Foley <mfoley>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	JON 3.2	CC:	loleary, myarboro, snegrea
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-03-07 03:17:59 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Aleksandar Kostadinov 2013-12-13 22:40:12 UTC

Currently jboss-on-agent RPM comes containing RHEL init scripts and JON agent binaries. Update of agent from JON server is disabled.

The problem is that if agent and server don't have the same version, they fail to work together. This means that customers must take extra care to keep the correct version of jboss-on-agent installed to have it working. Mostly the problem I see is when we release a new version of the agent RPM but customers still use older version of the server, if they don't have the package marked in yum, a `yum update` will cause newer version of agent to be installed and thus version mismatch with the server. Same goes for provisioning new machines - special care needs to be taken to install not the latest agent RPM so it matches server.

I think it makes a lot of sense to have jboss-on agent RPM contain only scripts that download agent binaries from server when needed (on initial run as well when server is updated). This way customers will always run the correct agent version. Additionally QA work from our side will be cut a little bit because we will have only one build of jon agent to test instead of two or more.

What I'm trying to say is that we still have the RPM. But it conains no agent binaries actually. Only init scripts. The init scripts download agent from server and then everything works as before. The only user visible difference (positive) is RPM version is not coupled with server version but (ideally) works with any server version.

Comment 1 Stefan Negrea 2014-01-29 15:43:22 UTC

The JON agent installed via RPM has the agent specific auto update option disabled on purpose. The feature was disable to allow the RPM update mechanism handle the updates between different versions of the RPM agent. This is the official recommendation for deploying software via RPM and RHN.

It is not possible to just have slim agent RPM that contains just some download scripts. Primarily because the installation needs to follow Linux standards for file locations. Secondly, the RPM takes care of creating a daemon script that is highly dependent on the payload. 

Also, the RPM is specifically designed to distribute software payloads via secured channels. It is highly undesirable to get an RPM that loads an additional software payload from an untrusted source.

In summary:
1) Auto update agent feature is disabled for RPM installations
2) Users should never enable agent auto update manually for RPM installations
3) Users should use the RPM update functionality to get new versions
4) Users can plan JON agent updates via external tools (there are a few ways to do this)
5) The agent RPM should be self contained to avoid potential attacks

Comment 2 Aleksandar Kostadinov 2014-01-29 15:53:30 UTC

I would argue that "untrusted source" is JON server run by the same user using the RPM. So not really less trusted than anything else.

The problem currently is that unaware user can cause agent upgrade through RPM unintentionally. If it is so impossible to have a slim download only RPM, then why not have the agent RPM have a particular version as part of the package name to avoin unintentional update of the agent while server still kept in the old version?
I'm putting the issue back to assigned. Let me know if you prefer to create another issue with the new proposal.

Comment 5 Larry O'Leary 2014-03-07 03:17:59 UTC

Closing as not a bug.

As suggested in comment 2, the 3.2 agent RPM will include the version identifier in the package name to ensure make it clear that each agent RPM is directly linked to a specific version of the server. Additionally, the RPM will include conflict declarations to ensure that a previous incompatible agent RPM can not be installed at the same time as the new version.

This work is being done as part of the productization release of JBoss ON and will be available via the errata in the very near future.