Hi all,
we are operating a DataMiner system in a closed network without access to the public internet. The system is also not connected to dataminer.services.
During regular monitoring, we noticed the DataMiner CloudFeed process showing up in Windows Task Manager and consuming memory. The actual resource consumption is not critical, but it does not serve any purpose, so we would prefer not to have an unnecessary service running at all.
We therefore stopped, disabled and eventually uninstalled CloudFeed.
However, we noticed that CloudFeed is installed again during newer DataMiner upgrades.
For example, when upgrading to DataMiner 10.6.10, the progress.log showed:
<code>Found installer: C:\Skyline DataMiner\Tools\ModuleInstallers\DataMiner CloudFeed 1.4.9.48340.msi No DataMiner CloudFeed was installed before. Trying to install DataMiner CloudFeed 1.4.9.48340... Successfully installed DataMiner CloudFeed 1.4.9.48340</code>
We have now upgraded to DataMiner 10.6.11, and CloudFeed was installed again.
What is interesting is that CloudGateway behaves differently. In the same upgrade log we saw:
<code>The DataMiner CloudGateway service is not installed. Not updating this Module.</code>
This behavior makes sense to us for an air-gapped system: if CloudGateway is not installed, the upgrade does not install it.
For CloudFeed, however, the behavior seems to be the opposite: even if it has intentionally been removed, the DataMiner upgrade installs it again.
Is there any way to prevent CloudFeed from being installed during DataMiner upgrades? If not, is there a particular reason why CloudGateway is only updated when already installed, while CloudFeed is installed even when it was previously absent? Would it make sense for CloudFeed to follow the same logic as CloudGateway on systems where it has explicitly been removed?
The resource consumption itself is small, but from an operational perspective we would like to avoid running services that cannot be used in this environment and unnecessarily consume system resources.
Thanks in advance!
Hi Gregor,
Valid remark, we'll tackle this.
(Ref. #49504)