You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We may not want to expose "rancher-wins" names on a host in all cases, and in some cases, we may want to disable this renaming of the process (for example, if you want to hack a patch into a file, you might want rancher to just run the file as-is). Also there might be security or other reasons why you dont want to expose that as a process name.
To my knowledge, there are two things to consider with changing the renaming process for the host processes:
Currently, wins fully solves the problem of getting a binary onto the host but does not handle all cases of removing a binary from the host. For example, if the wins server is restarted or stopped, all the processes that were added onto the host on behalf of clients may potentially remain stuck on the host if they aren't re-registered in the process pool that the wins server tracks (e.g. if the wins client that requested it died while the wins server was down). As a result, keeping a common prefix is a way for a Windows admin to be able to manually identify and kill such orphaned processes.
Even if we provided a way to modify the processPrefix, this would have to be a command line argument for the wins server, not for each wins client.
We may not want to expose "rancher-wins" names on a host in all cases, and in some cases, we may want to disable this renaming of the process (for example, if you want to hack a patch into a file, you might want rancher to just run the file as-is). Also there might be security or other reasons why you dont want to expose that as a process name.
Would it break anyhing to change https://github.com/rancher/wins/blob/master/pkg/apis/process_service.go#L20 to , say, a cmd line option or environment variable ?
The text was updated successfully, but these errors were encountered: