work offline checklist

January 21, 2016

When I started programming, one language I learned was “C” using the “ECO-C88” compiler. Another was “Microsoft QuickBASIC”. These came on floppy disks and had “manuals” – fascinating tombs of arcanary printed on actual paper. Without even dialing up a local Bulletin Board System (BBS) you could accompish a lot!

These days, most of my professional (and “sport”) programming is remote. Sometimes, there are literally dozens of minutes I go without a search request or IRC comment!

However, it’s rare when “remote” actually means “no Internet connection at all”. It’s surprising how hard it is to work completely disconnected – that one virtualenv you forgot to rebuild, or one Git repository that went un-synchronized can completely hose you (or at least slow things down considerably). Worst is documentation, as my first inclination at a hint of a roadblock is the nearest search engine.

On the other hand, with absolutely no way to pop in on Twitter or be distracted by an email, IRC, Slack, Jabber or other message – and with the right information, tools and source at hand – it can be very rewarding, focus-wise. Luckily, open-source development with Git is very well-suited to bouts of such “off the grid” progamming.

So, here’s my work-in-progress checklist before heading off to The Place Where There’s No Free WiFi Anymore:

NOTE that some of these bullet-points won’t make sense because they’re for me, not you. Do not dispair, Everything Is Fine. My dotfiles repo “probably” doesn’t reveal any seekrits, but it’s not public (yet?).

Synchronization

  • sync “tools” repo; (re-)install it
  • sync “dotfiles” repo; (re-)install it
  • blindly git fetch --all in all repos you might possibly care about; this won’t update any refs or mess with your working directory, it just pulls in all missing objects from all remotes (using ssh-agent cuts down on password typings). Run: repo-sync.sh
  • apt-get update ; apt-get upgrade if not doing unattended-upgrades already
  • use Zeal for documentation
    • make sure you download (or update) anything remotely interesting
  • as backup, install Debian documentation packages (e.g. twisted-doc)
  • re-create and/or update all virtualenv instances that might be used
    • cache wheels!
    • install all optional things (doc-building tools, test-tools, optional dependencies)
    • XXX can we copy a wheel cache-dir from dev box?
  • test! can you really run stuff with no network connection (turn it off, and try)?
    • can you re-install a venv with no network? (e.g. w/ wheel cache)
    • turn network back on, re-test you have the credentials required

Credentials

No matter how “offline” you are, it’s likely you can get intermittent access somehow and will want to login to certain machines. This requires credentials, possibly NAT traversal set up on the “certain machines”. For maximum utility, write down current IP addresses of things you care about.

Test it! (Not from your home network, mind). Nothing worse than gaining some opportunity to re-sync, only to find out you forgot the one key or didn’t turn on the one iptables rule on the router. Go ahead and test again!

  • one-time-passwords or private keys required?
    • need to copy anything from network-machines?
    • need any offline things?
    • can’t fail: missing credentials == fucked
  • test! can you login to the machines you expect to be able to? (from not your own internal network, mind!). -> WAY easier to fix now, instead of remotely.
  • make sure to bring any 2FA devices required!

OpSec

The hard-drive is encrypted, there is no swap partition (or, if you must, it’s inside an encrypted Linux Volume Manager [LVM] or similar). If travelling, additional to the above, ensure:

  • clear (all) browser(s) cache(s)
  • clear /tmp (usually done on reboot)
  • any unnecessary credentials? Audit:
    • ~/.ssh/*
    • backup + nuke + re-create /etc/ssh/ssh_host*.key*?
      • that is, can the remote machine login to anything important via keys?
      • is it worth temporarily shutting off all remote acces for this host?
      • possibly audit authorized_keys on remote hosts
      • or: don’t care, can still revoke access in case of compromise?
  • clear all (?) browser cookies
    • e.g. github’s bypasses 2FA
    • but: maybe you want this feature if leaving 2FA at home?
    • tradeoff: bring 2FA device, or leave cookie in browser store
    • current preference is cookie
      • clear entire cookie store
      • log in to important sites with 2FA
  • possibly time-based logins on “important machines”
    • issue a new host key for the “travelling” machine
    • enable cron-job (or similar) somewhere that adds said key to authorized_keys on the “important machines” some time after travel is predicted to end
    • con: impossible to log in until cron job runs
    • pro: impossible to log in until cron job runs (and have right key)
  • do you want any OTR keys with you? (ideally: no)
  • do you want any private crypto keys with you? (ideally: no)
  • do you need any 2FA devices? (ideally: no, use cookies)