docker: Error response from daemon: Get "https://redacted-local-hostname.net/v2/": x509: certificate has expired or is not yet valid  

Turns out my Synology hasn't been picking up the latest CA root certificates. I could verify that this is the issue by running curl

curl -I https://alexnj.com  
curl: (60) SSL certificate problem: certificate has expired  
More details here: https://curl.haxx.se/docs/sslcerts.html  
...

Fixing this turned out rather easy. The commands below download the up-to-date root certificates from curl.se, in PEM format. We move it to the place where Synology keeps the CA-certificate bundle, overwriting it. We create a backup of the origin CA-certificate bundle, with a .backup extension, just in case you'd want to revert for any reason.

cp /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt.backup  
wget --no-check-certificate https://curl.se/ca/cacert.pem  
mv cacert.pem /etc/ssl/certs/ca-certificates.crt  

After this, the same curl command started succeeding. However, Docker was still throwing the same error — meaning it didn't pick up the updated root certificates. Solution? Let's try restarting the Synology Docker daemon:

synoservice --restart pkgctl-Docker  

That took care of it. If you run into the same issue with your Synology, hope this helps!

Since Docker doesn't allow a container's entrypoint being modified, we need to create a new container on the same image, and modify entrypoint to be a shell. One can use the command below to shell into a Docker image to examine contents, or to debug the image.

docker run -it --entrypoint sh node:10-alpine  

Replace the image name, node:10-alpine with the correct image name. Shell here is sh, which is available in Alpine images, but you can change it with any other command as well.

USG remembers the preferred DNS hostname of local devices as they negotiate DHCP, and records it in its /etc/hosts file. When clients change their preferred name, USG doesn't seem to respect it, and continues to vendor the previously cached name from hosts file.

To fix this:
1. Login to your USG gateway via SSH
2. Open its /etc/hosts file and remove all the cached entries.
3. Reboot USG gateway and force your clients to reconnect and acquire new DHCP leases.

setw -g mouse on  

First, create two folders conf and lib in the current folder. We'll setup these as two-way shares between Docker container and host, and use to get certificates once the steps are complete.

sudo docker run -it \  
  --rm --name certbot \
  --mount src="$(pwd)/conf",target=/etc/letsencrypt,type=bind \
  --mount src="$(pwd)/lib",target=/var/lib/letsencrypt,type=bind  \
  certbot/certbot certonly --manual \
  --preferred-challenges dns

volumes:  
  shared:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: "/home/alexnj/projects/test/shared"

services:  
  web:
    build: .
    command: npm run start
    volumes:
      - shared:/app/shared

curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/os-release
test $VERSION_ID = "7" && echo "deb https://repos.influxdata.com/debian wheezy stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
test $VERSION_ID = "8" && echo "deb https://repos.influxdata.com/debian jessie stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
test $VERSION_ID = "9" && echo "deb https://repos.influxdata.com/debian stretch stable" | sudo tee /etc/apt/sources.list.d/influxdb.list

Followed by installing Telegraf service:

sudo apt-get update 
sudo apt-get install telegraf
sudo service telegraf start

The most elegant way that I have come across so far is an npm package module-alias.

With the package installed, I can then configure aliases like @app and @root that makes local dependency locations manageable and much more pleasant to interact with.

To configure, install the package as usual:

npm i module-alias --save  

As the first line of your program entrypoint, i.e, index.js or server.js, register the package:

require('module-alias/register')  

Aliases are defined in package.json, as follows:

  "_moduleAliases": {
    "@app": "./src",
    "@root": "."
  },

This setup now allows you to refer to your local dependencies as:

const userRoutes = require('@app/routes/user')

// or using import
import User from '@app/models/User'  

That works for your server-side application. What about client? Fortunately, this package can also be used with Webpack, which allows use of alias via its resolve configuration. An example configuration webpack.config.js snippet is below:

const packageJson = require('./package.json')

let webpackConfig = {  
  // ...
  resolve: {
    alias: packageJson._moduleAliases
  },
  // ...
}

This pulls in the same alias definitions from package.json. From that point, you can refer to client-side dependencies also with the same @app/path/to/file syntax.

If you are using less-loader with Webpack resolver, the syntax for @imports are as below example (Note the preceding ~, which enables less-loader version 4 and above to resolve using Webpack's resolver):

@import (reference) "~@app/styles/mixins/buttons.less";

Hope that helps. If you are aware of a better pattern, please share via comments below.

iptables -A IN_public_allow -p tcp -m tcp --dport 1337 -j ACCEPT  

Once you test the configuration, make the ruleset permanent by:

service iptables save  

Install Fail2Ban.

sudo apt-get update  
sudo apt-get install fail2ban  

Review configuration at /etc/fail2ban/jail.conf to see if you want to modify any default values.

Create a local jail config as below:

vim /etc/fail2ban/jail.local  

with the following contents:

[ssh-iptables]

enabled  = true  
filter   = sshd  
action   = iptables[name=SSH, port=ssh, protocol=tcp]  
logpath  = /var/log/secure  
maxretry = 5  

Start Fail2Ban service:

sudo service fail2ban start  

To see which IPs are blocked:

iptables -L -n  

CentOS

Install Fail2Ban.

yum install epel-release  
yum install fail2ban  

Review configuration at /etc/fail2ban/jail.conf to see if you want to modify any default values.

Create a local jail config as below:

vim /etc/fail2ban/jail.local  

with the following contents:

[ssh-iptables]

enabled  = true  
filter   = sshd  
action   = iptables[name=SSH, port=ssh, protocol=tcp]  
logpath  = /var/log/secure  
maxretry = 5  

Start Fail2Ban service:

chkconfig --level 23 fail2ban on  
service fail2ban start  

To see which IPs are blocked:

iptables -L -n  

Fortunately, the fix isn't that hard with the sleepwatcher brew.

brew install sleepwatcher  
brew services start sleepwatcher  
echo /usr/local/bin/docker run --rm --privileged \  
    node:argon hwclock -s > ~/.wakeup
chmod +x ~/.wakeup  

What does this do? Using sleepwatcher, schedule a forced hwclock -s sync in containers each time the Mac wakes up from sleep. Here I'm using node:argon as my OS name. Be sure to replace that with the OS image you are using.

The correct solution is to create an adapter override at app/adapters/post.js with the appropriate method to provide the correct endpoint URL. See the sample below:

import ApplicationAdapter from './application';

export default ApplicationAdapter.extend({  
    urlForCreateRecord(modelName, snapshot) {
        let blogID = snapshot.belongsTo('blog').id;
        return `/${this.namespace}/blogs/${blogID}/posts`;
    }
});

Here we are using the snapshot object to get the parent model and its ID to construct the URL. This is about the minimal override I could find, compared to overriding the complete createRecord, for example. Hope it helps!

Within the repo, run:

git config core.sshCommand "ssh -i ~/.ssh/id_rsa.github.alexnjose -F /dev/null"  

For initial clone of the repo, you can make use of the GIT_SSH_COMMAND environment variable:

GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa.github.alexnjose -F /dev/null" \  
    git clone git@github.com:alexnj/dotfiles.git