Xophmeister's questions

I am considering migrating my e-mail from one hosted provider to another; specifically to Proton Mail, but I don’t think that matters. My trepidation comes from my personal domain and the potential for either a temporary loss of service, loss of my e-mails, or both.

My current provider manages my domain, DNS and mail hosting (IMAP-based). I have three mailboxes, let’s call them {a,b,c}@example.com; I also have a subdomain, where everything sent to, say, [email protected] is forwarded to [email protected], but there is also a list of exceptions (say {x,y,z,…}@bar.example.com) that get forwarded to [email protected].

Here are the steps that I think I need to do:

• Transfer my domain to a new registrar. (I believe this maintains the current DNS records, except perhaps for the NS records.)
• Sign up for the alternative mail host (Proton Mail).
• Configure the MX records for my domain for Proton Mail.
• Create the {a,b,c}@example.com mailboxes in Proton Mail.
• Migrate the e-mails from the old provider’s mailboxes to the new. (I believe Proton Mail has a tool to do this.)
• AFAIK, Proton Mail doesn’t have forwarders but, regardless, a subdomain would [probably] be considered a separate custom domain, which is outside the scope of my intended price tier. As such, I need to set up mail forwarders outside of Proton Mail. I’ve found ForwardEMail.net, which offers a free, DNS-based solution to this. I can set this up in the DNS records for bar.example.com as documented.

Is that everything? Would you, for example, recommend taking a local backup of e-mails? Importantly, does the order matter: registrar/DNS changes take time to propagate and there’s a bit of a chicken-and-egg problem when it comes to migrating mailboxes? How do I overcome these?

(Meta-question: Is it worth it? Obviously that’s a personal decision, but this will ultimately be more expensive and decentralised than my current service. The current service works and is relatively easy to manage, but is a bit antiquated. Anecdotes from people who have gone through a similar process would be welcome.)

Azure Storage Accounts can have their access restricted by IP address or an Azure virtual network (with a Microsoft.Storage service endpoint). When this is done, the storage resource will only accept connections from those designated origins. This covers data operations (read, write, etc.) and control operations (create new container, etc.); I'm calling these the "data" and "management" planes, respectively.

Is it possible to isolate these at a networking level (e.g., with a firewall), or can it only be done at a role level? For example, could I have a VM on the same network that can only do control operations, regardless of the roles of the principal?

My initial understanding was that an Azure Bastion acts like a lightweight SSH (and RDP) gateway to resources -- specifically, VMs -- on the same virtual network, rather than provisioning a full VM as a jumpbox. That is, I would expect to be able to do this, from anywhere on the public Internet, to SSH into a VM on the same network:

ssh -i /path/to/private.key -J BASTION_IP user@VM_IP

Where BASTION_IP is the public IP associated with the Bastion resource and VM_IP is the internal IP address of the VM in a sibling subnet to the Bastion subnet.

I've set this up in Terraform, using the "Basic" Bastion SKU but, when I try connecting, it times out. In the Azure Poral, there is an option named "Native Client Support" (which needs the "Standard" SKU), exposed as the tunneling_enabled argument in the respective Terraform resource. With those changes made, my connection still times out.

Following the rabbit hole of documentation suggests that you have to use the Azure CLI. Indeed, I can get tunnelling to work using the Azure CLI -- the SSH extension is Windows only, apparently -- but it's a bit of a faff:

az login  # I assume there's a way to login unattended
az account set --subscription SUBSCRIPTION_ID
az network bastion tunnel --name BASTION_NAME --resource-group RG_NAME --target-resource-id REALLY_LONG_VM_RESOURCE_ID --resource-port 22 --port 2222 &
ssh -i /path/to/private.key -p 2222 user@localhost

Is there a non-proprietary way of SSH'ing into an Azure VM through an Azure Bastion? Or is my assumption on its use-case off?

I have installed CouchDB 1.6.1 on a Trusty box via the Apache CouchDB PPA (couchdb/stable). This all seems to work, except that I cannot start the service using service couchdb start (similarly for stop). I've got around this by putting the following script in /usr/local/bin:

#!/bin/bash
export ERL_FLAGS="+A 16"
export ERL_MAX_PORTS=8192
nohup couchdb > /opt/couchdb/log/couch.log 2>&1 &

I have to run this manually (or stop it with kill). The service commands say they work, but CouchDB just immediately fails. This is fine, except in the rare event that the machine needs rebooting; it would be nice if CouchDB came up automatically.

On various pages I've found online, there is reference to a bundled init.d script. In fact, I found a generated init.d script, which is supposed to be installed along with CouchDB: I tried this, edited appropriately, but the same problem persists.

It seems a lot of the documentation I've found online is very out-of-date (e.g., it references paths that are not valid with the PPA installed version and/or Trusty). What is the current "best way to do this"?

Is it possible to just reverse proxy Futon, without exposing the CouchDB root and RESTful API? I have the following nginx config:

server {
  # This should never be hit, as the port isn't open,
  # but it's here for completeness sake
  listen 80;
  return 301 https://$host$request_uri;
}

server {
  listen 443;
  server_name my_futon_host;

  ssl_certificate /path/to/my/certificate.pem;
  ssl_certificate_key /path/to/my/private.key;

  ssl on;
  ssl_session_cache builtin:1000 shared:SSL:10m;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
  ssl_prefer_server_ciphers on;

  location / {
    proxy_set_header    Host $host;
    proxy_set_header    X-Real-IP $remote_addr;
    proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header    X-Forwarded-Proto $scheme;

    # Just reverse proxy Futon, presuming that works...
    proxy_pass          http://localhost:5984/_utils/;
    proxy_read_timeout  90;

    proxy_redirect      http://localhost:5984/_utils/ https://my_futon_host/;
  }
}

Futon appears to load with this configuration, but I can't do anything. It just complains that it can't access the appropriate CouchDB API endpoints. This makes sense, as they are not reverse proxied and presumably Futon attempts to call them directly. Is there any way around this?

I fear this may be a somewhat open-ended question that gets closed: Apologies in advance, but I'll give it a shot!

I'm considering operating an OpenBSD VM with a number of services running on the same instance (SSH, IMAP, SMTP, some HTTP server and VPN). Should I sandbox these daemons, some how (e.g., chroot jails), to ensure they don't interfere with each other, or is the OpenBSD/POSIX model already sufficient? Is there anything else I should be aware of?