Exporting config maps crashes randomly

[Hans-Martin Mosner]

Hi, when exporting config maps (complete or changes to a previous version) from a server repository to a local file, I often get an "Error accessing ...: Access denied" in the #flush operation. I have a suspicion that the obnoxious malware scanner on this company laptop may be the culprit, but cannot verify or falsifiy this as I can't disable that thing.

Do others have similar experiences, and does my suspicion match your observations?

Cheers,
Hans-Martin

[Marcus Wagner]

Hans-Martin,

in a broad sense, I had many such similar experiences. 

There are many reasons resulting in such observations.

My estimate that this is related to security, but not necessarily to malware scanning, but resulting from more general rules denying users access to certain resources (file access in your case).

And from such security aspects it would be counterproductive to be able to disable that easely.

There are many details missing, so to narrow that down: I assume you suffer from a problem in the client (local) - server (repository) cooperation in a distributed VAST installation crossuing environment borders.

flush (error accessing, access denied) indicates a local problem on the client if this flush is part of an export.

I assume this client is located on the company laptop you mention. And further, this company laptop underlies some company security rules, centrally adminstrated and spread out to the infrastructure (of that company).

So my guess is: the whole VAST client does not match any security profile covering this laptop. 

This is in particular very likely if that company business is not software development related and even if it is, VAST became exotic even in this universe. 

And as long as this VAST client works fine locally, it won't be able to communicate elsewhere without negative effects.

Another guess of mine is (also of my experience) that this might result from a firewall protecting the company (containing the server).

To give you an example: a customer of mine runs a dedicated computer center serving many dislocated offices, all of them (securily) connected in a huge network. 

Computer center adminstration decided to establish a higher security level to reduce the risk.

The result: a similar client - server communication as in VAST all over sudden did not finish within DAYS instead of a minute.

The cause was the firewall in between established a (hidden) load on every transmitted paket, causing this overall break down. 

The whole thing was based on a knock on the door and do not react pattern established on certain server ports, neglecting the specific needs of the particular conversation.

Another extreme example: another certain customer disabled the execution of any program if the program is not located in certain secure places (like ...program files..) and to avoid bypasses, it disallowed to run any interpreter (not to mention under a rigorous file structure security) bases on byte codes. Result was any script failed (to protect from indirect attacks originating from eMail and the like). 

Although this case does not match your observation, I mention this as VAST provides an interpreter (of Smalltalk) which might be denied to be run at all, even if is granted access to ports and files.

My advice: do not attempt to run VAST crossing borders of different business environments. 

Although this is a special case of a normal information transfer using standard infrastructure (sockets and ports) exactly the protocol (client image - server repository) there is confidential.

Instead rely on standard file access patterns as far as they are more common and in better understood, in general.

That means in this case: export s.th. from a central repository to a specialized one (.DAT) on the server - transport this file (via ? share, download, whatsover) local to the laptop and the try to import is from the local place. But ... see above, even this might fail.

This is not a Windows specific issue alone - think about SELINUX as an example.

In general this was and still is an important issue to be clarified in advance for a distributed development infrastucture - since the early days in 90ies of the previous century.

Kind regards

M