Please review at your earliest convenience. I've tested via experiment dry runs, examining generated files, minimega script, etc. I have not yet had a chance to test in an actual deployment, making sure VMs actually boot with miniccc injected and enabled automatically.
Comment by @activeshadow
Cracking open snapshots of the same image multiple times in an experiment to inject the agent really seems to slow down the deployment of large experiments since the miniccc agent is large enough to notice the copy time.
I'm wondering if we shouldn't consider keeping track of the underlying image being used by each VM and only inject the agent once per base image. Doing so would limit the effectiveness of a per-VM auto start setting, but I'm not convinced that will be set to false very often anyway.
This is an alternative to the new image inject-miniccc subcommand added to phenix. I don't see the harm in having multiple alternatives. The new image subcommand in phenix is very specific to miniccc, while this is more generic (though meant for miniccc).
If we're going to keep this app (which I think we should), then I would like to update it to only do an injection once per base image. My thought would be to create a snapshot from the base image to do the agent injection into, then for each VM using the base image, use the agent snapshot instead.
Comment by @glattercj
That makes sense.
Comment by @zach-r-long
Two comments. @activeshadow is correct the intent of the app was to be more generic to allow the easy setup and injection of any Command and Control agent. Targeted miniccc because it is built into the code base. As for the injections, I have not looked at that code but I seem to remember patching this issue on an older version of phenix. Believe the patch was to que all disk changes from apps ect and perform the injection at startup after the user apps completed. Believe the injects where also placed in the snapshot file.
Please review at your earliest convenience. I've tested via experiment dry runs, examining generated files, minimega script, etc. I have not yet had a chance to test in an actual deployment, making sure VMs actually boot with miniccc injected and enabled automatically.
Comment by @activeshadow
Cracking open snapshots of the same image multiple times in an experiment to inject the agent really seems to slow down the deployment of large experiments since the miniccc agent is large enough to notice the copy time.
I'm wondering if we shouldn't consider keeping track of the underlying image being used by each VM and only inject the agent once per base image. Doing so would limit the effectiveness of a per-VM auto start setting, but I'm not convinced that will be set to false very often anyway.
Comment by @glattercj
Agreed. Is this app an alternative/replacement to https://github.com/activeshadow/minimega/issues/89? Ideally we have one way to do CC, rather than a phenix app OR a phenix command.
Comment by @activeshadow
This is an alternative to the new
image inject-minicccsubcommand added to phenix. I don't see the harm in having multiple alternatives. The new image subcommand in phenix is very specific to miniccc, while this is more generic (though meant for miniccc).If we're going to keep this app (which I think we should), then I would like to update it to only do an injection once per base image. My thought would be to create a snapshot from the base image to do the agent injection into, then for each VM using the base image, use the agent snapshot instead.
Comment by @glattercj
That makes sense.
Comment by @zach-r-long
Two comments. @activeshadow is correct the intent of the app was to be more generic to allow the easy setup and injection of any Command and Control agent. Targeted miniccc because it is built into the code base. As for the injections, I have not looked at that code but I seem to remember patching this issue on an older version of phenix. Believe the patch was to que all disk changes from apps ect and perform the injection at startup after the user apps completed. Believe the injects where also placed in the snapshot file.