New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ron/miniccc/minimega: improving reconnect #1177

Merged
merged 2 commits into from Sep 28, 2018

Conversation

Projects
None yet
3 participants
@jcrussell
Contributor

jcrussell commented Sep 21, 2018

Add synchronization bytes to hopefully allow ron and miniccc to reconnect. Write the magic bytes in both directions to flush both sides.

Add redial to the things we do when we start a VM.

jcrussell added some commits Sep 13, 2018

ron/minimega: refactoring to redial on Start
Refactor minimega so that we connect CC when starting a VM. Add test to
ensure that we can reconnect after VMs are killed and restarted.

Add additional checks in ron to make sure that we aren't trying to
listen on the same thing twice and properly cleaning up the listeners
that we have closed.

Suppress tunnel EOF messages.
ron/miniccc: add synchronization bytes
Should allow miniccc to reconnect after the VM restarts, even if there
is data left in the buffer.
@jcrussell

This comment has been minimized.

Contributor

jcrussell commented Sep 26, 2018

Tested with a debian VM. If you shutdown the VM and then vm start it, the connection is re-established and you can issue new commands. If you restart the VM (using the OS restart mechanism), the connection is not re-established since minimega doesn't know to call redial. We could add a listener to fix this.

One potentially problematic thing is that the miniccc state is fresh so it doesn't know what the previous command was so it reruns them all.

@mkunz7

This comment has been minimized.

Contributor

mkunz7 commented Sep 27, 2018

Can you have the agent generate a random number and save it to disk on first run? From then on out make this the agents unique identifier.

@jcrussell

This comment has been minimized.

Contributor

jcrussell commented Sep 27, 2018

@mkunz7: is that to prevent miniccc from rerunning commands?

There are some commands that we would want to rerun (e.g. set static IP) and others that we wouldn't (e.g. run setup.bash). It's hard for us to know which those are.

I'm leaning towards letting the user figure this out -- run clear cc commands if all your commands have responses and you're shutting things down for some reason.

@mkunz7

This comment has been minimized.

Contributor

mkunz7 commented Sep 27, 2018

Yeah, that's my intent. Perhaps we can add a persistence command.

cc persistence true

If persistence is enabled it writes every command it executes to disk. On reconnect it phones home for the list of commands to run, and skips any it has done already.

@djfritz

This comment has been minimized.

Contributor

djfritz commented Sep 27, 2018

Yea the original intent behind having command persist like they do currently is exactly that. If a vm cycles, it can re-ingest all of the past commands.

This all looks good to me.

@djfritz

LGTM

@jcrussell jcrussell merged commit 6ba49ba into sandia-minimega:master Sep 28, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@jcrussell jcrussell deleted the jcrussell:cc++ branch Sep 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment