this introduces a new env variable 'DOMAIN', and a matching function,
'domain', the function's first argument is the type of record of which
A records are the only supported type (for now), and the second is the
action (create, delete, show). a current limitation of this is that
the subdomain will always be 'auto-mc', as the domain variable has to
be second level.
the motivation for this is so we can prompt the user to open the
server console once installed, and run exec ssh mc@<ip> to do so
this commit copies the authorized_keys from root user to the user
'mc', and adds 'screen -r' and then 'exit' to the .bashrc
the server, when deployed, will check XDG_DATA_DIR/auto-mc-redux for
a server backup (in .tar.zstd format) and upload it if it sees one;
and when undeployed, will now upload the backup to the users's local
machine before destroying it
we want to test if ssh is about to be able to work, so actually testing
if there's an ssh server on the port should help the run condition caused
by of ssh not being up the same instant as networking.
while this doens't exactly feel like the Correct thing to do, there
is a benefit to not having to keep track of the state as much, and
just relying on the tags we've already set and use other places.
this is motivated by wanting to redirect the world/server files
after provisioning, according to user config.
.hushlogin was added to root's home dir as to not interfere with
directly piping ssh's mc-backup output to a file
now we don't have to move extra files over scp or similar and can
simply pipe the contents of the file (along with any variables) into
ssh once connected to the destination server.
previously icmp was not on either inbound or outbound. there were
also no outbound rules whatsoever. this may have been causing issues
when creating a vm in a team with no base-firewall rules.
this will allow us to feed automate.sh via ssh's stdin inside of
deploy.sh as ssh will not open a virtual terminal when stdin is
not is not a terminal.
