Thomas's questions

We have a couple of machines in AWS EC2 and are running the Amazon CloudWatch Agent on them to collect metrics. Instead of the default ImageId, InstanceId, InstanceType triplet, the agent is configured to aggregate by InstanceId only:

    "aggregation_dimensions": [
        ["InstanceId", "path"],
        ["InstanceId"],
        []
    ],

In CloudWatch we can then use a SEARCH query to produce a graph:

SEARCH('{CWAgent,InstanceId} MetricName="mem_used_percent"', 'Average', 60)

Which looks like this:

It's great, except for the labels. These are only showing instance IDs, not instance names. But I swear that yesterday the instance names were showing up in parentheses after the instance ID!

I would really like to see our hand-picked, artisanal instance names here, instead of Amazon's industrial mass-produced instance IDs. I've read about dynamic labels but they don't seem to be a solution.

Is there a way to make instance names show up reliably – either next to the instance ID or all by themselves?

I have ~30 domains running on my server, all of them with SSL certificates managed by the Certbot nginx plugin. All of them, except one... let's call it selfsigned.example.com.

This domain uses a self-signed certificate because it's being accessed by an embedded device, for which I haven't managed to get a proper certificate chain to work. The embedded device checks the certificate fingerprint, so it's quite secure as long as I don't need revocation. But it's important that the cert on the server doesn't get replaced by Certbot, otherwise the device will refuse to connect.

I frequently add new domains to the configuration, and then I rerun certbot --nginx to generate a new certificate for them. But every time I do that, certbot prompts me:

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: whatever.example.com
2: something.example.com
...
17: selfsigned.example.com
...
32: thelastone.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 

If I just press Enter, Certbot will overwrite the ssl_certificate and ssl_certificate_key directives for selfsigned.example.com with a cert from Let's Encrypt. So I have to manually type out all numbers except 17 in this case.

As a cautious and lazy sysadmin, how can I make it so that I can just press Enter? Maybe there's some magic comment (similar to # managed by Certbot) that lets me say # Certbot ignore?

The situation:

• An OpenVPN (2.3.12) server with public IP 1.1.1.1 running in Amazon EC2, using the UDP protocol.
• A remote OpenVPN (2.3.10) client with public IP 2.2.2.2, somewhere on an ADSL connection and behind a wifi home router and firewall.

The problem is that the client keeps reconnecting, once every 40 seconds, even though the connection appears to be working fine.

As you can see below, we have keepalive 10 40 configured on the server, and this is duly pushed to the client. I can change the value, but of course we do want the client to reconnect if the connection is actually broken (e.g. the wifi router was restarted and forgot all its stateful UDP rules). So that's not a good option.

The disconnect happens even if I ssh onto the client through the VPN and generate some traffic both ways by e.g. scrolling up and down in less, or if I run a continuous ping to the client through the VPN.

We also had trouble with packet loss being caused by MTU size, but that's been fixed by using mssfix 1200 on the client. For the record, the client can ping the server (outside the VPN) using

ping -M do -s 1412 -c 1 1.1.1.1

So our mssfix value can theoretically be set to 1372 according to this answer; 1200 is just to add a safety margin (and so we can reuse this config on other clients on other networks).

From the client log:

[server] Inactivity timeout (--ping-restart), restarting
TCP/UDP: Closing socket
SIGUSR1[soft,ping-restart] received, process restarting
Restart pause, 2 second(s)
Re-using SSL/TLS context
LZO compression initialized
Control Channel MTU parms [ L:1558 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Socket Buffers: R=[212992->212992] S=[212992->212992]
Data Channel MTU parms [ L:1558 D:1200 EF:58 EB:143 ET:0 EL:3 AF:3/1 ]
Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'
Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
Local Options hash (VER=V4): '22188c5b'
Expected Remote Options hash (VER=V4): 'a8f55717'
UDPv4 link local: [undef]
UDPv4 link remote: [AF_INET]1.1.1.1:1194
TLS: Initial packet from [AF_INET]1.1.1.1:1194, sid=78ff051d c8d027a7
VERIFY OK: depth=1, CN=REDACTED
Validating certificate key usage
++ Certificate has key usage  00a0, expects 00a0
VERIFY KU OK
Validating certificate extended key usage
++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
VERIFY EKU OK
VERIFY OK: depth=0, CN=server
Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
[server] Peer Connection Initiated with [AF_INET]1.1.1.1:1194
SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.84.0.1,topology subnet,ping 10,ping-restart 40,ifconfig 10.84.0.6 255.255.0.0'
OPTIONS IMPORT: timers and/or timeouts modified
OPTIONS IMPORT: --ifconfig/up options modified
OPTIONS IMPORT: route-related options modified
Preserving previous TUN/TAP instance: tun0
Initialization Sequence Completed

From the server log:

MULTI: multi_create_instance called
93.254.95.157:33098 Re-using SSL/TLS context
93.254.95.157:33098 LZO compression initialized
93.254.95.157:33098 Control Channel MTU parms [ L:1558 D:1212 EF:38 EB:0 ET:0 EL:3 ]
93.254.95.157:33098 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:143 ET:0 EL:3 AF:3/1 ]
93.254.95.157:33098 Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
93.254.95.157:33098 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'
93.254.95.157:33098 Local Options hash (VER=V4): 'a8f55717'
93.254.95.157:33098 Expected Remote Options hash (VER=V4): '22188c5b'
93.254.95.157:33098 TLS: Initial packet from [AF_INET]93.254.95.157:33098, sid=a3383b01 bc17f487
93.254.95.157:33098 VERIFY OK: depth=1, CN=REDACTED
93.254.95.157:33098 VERIFY OK: depth=0, CN=ClientName
93.254.95.157:33098 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
93.254.95.157:33098 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
93.254.95.157:33098 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
93.254.95.157:33098 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
93.254.95.157:33098 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
93.254.95.157:33098 [ClientName] Peer Connection Initiated with [AF_INET]93.254.95.157:33098
MULTI: new connection by client 'ClientName' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
MULTI_sva: pool returned IPv4=10.84.0.6, IPv6=(Not enabled)
MULTI: Learn: 10.84.0.6 -> ClientName/2.2.2.2:33098
MULTI: primary virtual IP for ClientName/2.2.2.2:33098: 10.84.0.6
ClientName/2.2.2.2:33098 PUSH: Received control message: 'PUSH_REQUEST'
ClientName/2.2.2.2:33098 send_push_reply(): safe_cap=940
ClientName/2.2.2.2:33098 SENT CONTROL [ClientName]: 'PUSH_REPLY,route-gateway 10.84.0.1,topology subnet,ping 10,ping-restart 40,ifconfig 10.84.0.6 255.255.0.0' (status=1)

Client configuration:

client
dev tun
proto udp
remote 1.1.1.1 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
remote-cert-tls server
cipher AES-256-CBC
comp-lzo
verb 4
mssfix 1200

Server configuration:

port 1194
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem
topology subnet
server 10.84.0.0 255.255.0.0
ifconfig-pool-persist ipp.txt
client-to-client
keepalive 10 40
cipher AES-256-CBC
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4

I might be able to fix this by switching to TCP instead of UDP, but I'm wary of the overhead and risks, and feel that it's a silly "solution" even if it ends up working.

Any other ideas on where to look and what to try?