macOS

This is a bit cheaty because it doesn't use macOS's built-in date. For uniformity, since I work on both macOS and Linux a lot, I just use GNU's tools. For example, date is provided through coreutils, which can be installed through Brew:

brew install coreutils  

This should, by default, add gdate to your $PATH (all GNU commands are prefixed with g to not conflict with the built-in macOS commands).

In ~/.zshrc:

dates() {

cat << EOD  
        Format/result               |       Command               |          Output
------------------------------------+-----------------------------+------------------------------
YYYY-MM-DD_hh:mm:ss                 | gdate +%F_%T                | $(gdate +%F_%T)  
YYYYMMDD_hhmmss                     | gdate +%Y%m%d_%H%M%S        | $(gdate +%Y%m%d_%H%M%S)  
YYYYMMDD_hhmmss (UTC version)       | gdate --utc +%Y%m%d_%H%M%SZ | $(gdate --utc +%Y%m%d_%H%M%SZ)  
YYYYMMDD_hhmmss (with local TZ)     | gdate +%Y%m%d_%H%M%S%Z      | $(gdate +%Y%m%d_%H%M%S%Z)  
YYYYMMDD_Thhmmss (with num TZ) *    | gdate +%Y%m%d_T%H%M%S%z     | $(gdate +%Y%m%d_T%H%M%S%z)  
YYYYMMSShhmmss                      | gdate +%Y%m%d%H%M%S         | $(gdate +%Y%m%d%H%M%S)  
YYYYMMSShhmmssnnnnnnnnn             | gdate +%Y%m%d%H%M%S%N       | $(gdate +%Y%m%d%H%M%S%N)  
YYMMDD_hhmmss                       | gdate +%y%m%d_%H%M%S        | $(gdate +%y%m%d_%H%M%S)  
Seconds since UNIX epoch:           | gdate +%s                   | $(gdate +%s)  
Nanoseconds only:                   | gdate +%N                   | $(gdate +%N)  
Nanoseconds since UNIX epoch:       | gdate +%s%N                 | $(gdate +%s%N)  
ISO8601 UTC timestamp               | gdate --utc +%FT%TZ         | $(gdate --utc +%FT%TZ)  
ISO8601 UTC timestamp + ms          | gdate --utc +%FT%T.%3NZ     | $(gdate --utc +%FT%T.%3NZ)  
ISO8601 Local TZ timestamp          | gdate +%FT%T%Z              | $(gdate +%FT%T%Z)  
YYYY-MM-DD (Short day)              | gdate +%F\(%a\)             | $(gdate +%F\(%a\))  
YYYY-MM-DD (Long day)               | gdate +%F\(%A\)             | $(gdate +%F\(%A\))  
"ISO8601"-ish timestamp + w/        | gdate +%F_T%H-%M-%S%z       | $(gdate +%F_T%H-%M-%S%z)
  numerical timezone                |                             |
YYYYMMDD_hhmmss (with local TZ)     | gdate +%F_T%H%M%S%z         | $(gdate +%F_T%H-%M-%S%z)  
  numerical timezone (no dash)      |                             |

Notes:  
* use this for filenames 
EOD  
}

On Linux you just use date instead of gdate:

dates() {

cat << EOD  
        Format/result               |       Command               |          Output
------------------------------------+-----------------------------+------------------------------
YYYY-MM-DD_hh:mm:ss                 | date +%F_%T                | $(date +%F_%T)  
YYYYMMDD_hhmmss                     | date +%Y%m%d_%H%M%S        | $(date +%Y%m%d_%H%M%S)  
YYYYMMDD_hhmmss (UTC version)       | date --utc +%Y%m%d_%H%M%SZ | $(date --utc +%Y%m%d_%H%M%SZ)  
YYYYMMDD_hhmmss (with local TZ)     | date +%Y%m%d_%H%M%S%Z      | $(date +%Y%m%d_%H%M%S%Z)  
YYYYMMDD_Thhmmss (with num TZ) *    | date +%Y%m%d_T%H%M%S%z     | $(date +%Y%m%d_T%H%M%S%z)  
YYYYMMSShhmmss                      | date +%Y%m%d%H%M%S         | $(date +%Y%m%d%H%M%S)  
YYYYMMSShhmmssnnnnnnnnn             | date +%Y%m%d%H%M%S%N       | $(date +%Y%m%d%H%M%S%N)  
YYMMDD_hhmmss                       | date +%y%m%d_%H%M%S        | $(date +%y%m%d_%H%M%S)  
Seconds since UNIX epoch:           | date +%s                   | $(date +%s)  
Nanoseconds only:                   | date +%N                   | $(date +%N)  
Nanoseconds since UNIX epoch:       | date +%s%N                 | $(date +%s%N)  
ISO8601 UTC timestamp               | date --utc +%FT%TZ         | $(date --utc +%FT%TZ)  
ISO8601 UTC timestamp + ms          | date --utc +%FT%T.%3NZ     | $(date --utc +%FT%T.%3NZ)  
ISO8601 Local TZ timestamp          | date +%FT%T%Z              | $(date +%FT%T%Z)  
YYYY-MM-DD (Short day)              | date +%F\(%a\)             | $(date +%F\(%a\))  
YYYY-MM-DD (Long day)               | date +%F\(%A\)             | $(date +%F\(%A\))  
"ISO8601"-ish timestamp + w/        | date +%F_T%H-%M-%S%z       | $(date +%F_T%H-%M-%S%z)
  numerical timezone                |                            |
YYYYMMDD_hhmmss (with local TZ)     | date +%F_T%H%M%S%z         | $(date +%F_T%H-%M-%S%z)  
  numerical timezone (no dash)     

EOD  
}

Example output:

        Format/result               |       Command               |          Output
------------------------------------+-----------------------------+------------------------------
YYYY-MM-DD_hh:mm:ss                 | gdate +%F_%T                | 2025-02-01_15:30:00  
YYYYMMDD_hhmmss                     | gdate +%Y%m%d_%H%M%S        | 20250201_153000  
YYYYMMDD_hhmmss (UTC version)       | gdate --utc +%Y%m%d_%H%M%SZ | 20250201_233000Z  
YYYYMMDD_hhmmss (with local TZ)     | gdate +%Y%m%d_%H%M%S%Z      | 20250201_153000PST  
YYYYMMDD_Thhmmss (with num TZ) *    | gdate +%Y%m%d_T%H%M%S%z     | 20250201_T153000-0800  
YYYYMMSShhmmss                      | gdate +%Y%m%d%H%M%S         | 20250201153000  
YYYYMMSShhmmssnnnnnnnnn             | gdate +%Y%m%d%H%M%S%N       | 20250201153000726647000  
YYMMDD_hhmmss                       | gdate +%y%m%d_%H%M%S        | 250201_153000  
Seconds since UNIX epoch:           | gdate +%s                   | 1738452600  
Nanoseconds only:                   | gdate +%N                   | 734241000  
Nanoseconds since UNIX epoch:       | gdate +%s%N                 | 1738452600737131000  
ISO8601 UTC timestamp               | gdate --utc +%FT%TZ         | 2025-02-01T23:30:00Z  
ISO8601 UTC timestamp + ms          | gdate --utc +%FT%T.%3NZ     | 2025-02-01T23:30:00.741Z  
ISO8601 Local TZ timestamp          | gdate +%FT%T%Z              | 2025-02-01T15:30:00PST  
YYYY-MM-DD (Short day)              | gdate +%F\(%a\)             | 2025-02-01(Sat)  
YYYY-MM-DD (Long day)               | gdate +%F\(%A\)             | 2025-02-01(Saturday)  
"ISO8601"-ish timestamp + w/        | gdate +%F_T%H-%M-%S%z       | 2025-02-01_T15-30-00-0800
  numerical timezone                |                             |
YYYYMMDD_hhmmss (with local TZ)     | gdate +%F_T%H%M%S%z         | 2025-02-01_T15-30-00-0800  
  numerical timezone (no dash)      |                             |

Notes:  
* use this for filenames 

For people having issues accessing containers from their macOS here's some info:

Docker networking works differently for macOS than it does on Linux (it uses HyperKit).

If you're using Docker Desktop for Mac, you won't be able to ping your containers by IP. See: https://docs.docker.com/docker-for-mac/networking/

Issue: I cannot ping my containers

Docker Desktop for Mac can’t route traffic to containers.

BUT you should be able to connect using another port if you publish the ports correctly, using localhost, not the IP address.

Example: If I run the following command to run nginx in a container and expose port 80 inside the container, and map to port 80 on the host:

docker run -d -p 80:80 --name webserver nginx  

It will have the following effect in macOS. It works as expected with curl using localhost.

$ curl -I localhost:80
HTTP/1.1 200 OK  
Server: nginx/1.15.10  

But if I try to use the IP address in macOS:

# Getting the IP address of the webserver container
$ docker inspect webserver | jq '.[] | .NetworkSettings.Networks.bridge.IPAddress'

which returned in this case "172.17.0.3".

Now using that returned IP in macOS (i.e. fails ping, and fails curl):

$ ping 172.17.0.3
PING 172.17.0.3 (172.17.0.3): 56 data bytes  
Request timeout for icmp_seq 0  
Request timeout for icmp_seq 1  
^C
--- 172.17.0.3 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss  

The following times out:

$ curl -I 172.17.0.3:80

...

This link contains a lot more troubleshooting on macOS + Docker networking: https://docs.docker.com/docker-for-mac/networking/

So I woke up today and ssh'd into a VM that I own on a network that isn't connected to the internet and with no access to it. I typed in my annoyingly long password to sudo !! as my non-root (but sudoer) user, and the thing happens where I know I typed in my password wrong and now I have to wait what feels like an eternity to type in a command after forgetting to use sudo in the first place.

So anyway this has been plaguing me for years and stealing precious minutes of my attention span so I decided to figure out and how to change it.

I only know this for this VM's specs, which is currently Ubuntu 16.04.6 LTS. It might be different from yours. If I do it for other distros I'll maybe update this post, but it should be similar.

Why have this in the first place?

If you haven't thought about this before, you should. We have timed lock-outs for failed authentication for security reasons for general things, mainly because it limits the number of times that a bot/hacker/script can brute-force your password.

Now, the implementation/practical effectiveness of the lock-out for sudo and general login (i.e via PAM) can be argued for and against, but I won't go into that here. I assume you know the following:

1. security should be an aspect of all layers
2. every approach to building things has pros and cons with different weights

Also, lastly, be aware that anything I write about PAM will be littered with these gifs and pictures.

Okay so how?

Pretty ready to not have this workflow.

btamayo@px01:~$ su deploy  
Password:  
<THREE SECONDS OF UGH>  
su: Authentication failure  

btamayo@px01:~$ sudo su -  
[sudo] password for btamayo:
<THREE SECONDS OF UGH>  
Sorry, try again.  

So the first google result I looked at told me to go to /etc/logins.defs and look for something called FAIL_DELAY which was commented out and didn't affect anything. I checked on just Debian and it was the same way as well.

So I skipped that part and went to the second part where it told me to go to /etc/pam.d/ and look in the configs there. I looked in the files /etc/pam.d/login, /etc/pam.d/su, and /etc/pam.d/sudo.

In login, there was a line that said:

...
# Enforce a minimal delay in case of failure (in microseconds).
# (Replaces the `FAIL_DELAY' setting from login.defs)
# Note that other modules may require another minimal delay. (for example,
# to disable any delay, you should add the nodelay option to pam_unix)
auth       optional   pam_faildelay.so  delay=3000000  
...

NOTE that said microseconds which I missed and wrongly assumed was in milliseconds the first time and was confused for five whole minutes as I didn't understand why it would be 50+ minutes long.

1. login, sudo, and su (and other files I assume) all included a file called common-auth, which I looked in and found the line that it told me to look for:

...
auth    [success=1 default=ignore]  pam_unix.so nullok_secure  
...

(The above is from /etc/pam.d/common-auth.)

Ok, so I just want to change sudo at this point because I really need to not get sidetracked in to learning PAM today, even though I'm curious and tempted because I love digging around stuff like this.

nullok_secure

I don't remember seeing this in the manpage I read, so looked it up, and it seems to be a Debian thing. I'm not sure whether it's supported in other distros, and if so, if it's just that it's the default in Debian. Let me know!

🔗 TLDR: Changing the delay

Change this line in /etc/pam.d/common-auth (Debian systems):

...
auth    [success=1 default=ignore]  pam_unix.so nullok_secure  
...

to

...
auth    [success=1 default=ignore]  pam_unix.so nullok_secure nodelay  
...

The nodelay removes the default 2-second delay, allowing other configs to possibly override this delay with something less than 2 seconds. All configs inheriting this file without adding their own delay, including sshd will have no delay.

To add in a delay now, (I assume that that minimum 2-second delay is built-in to pam_unix.so but lmk if that's not true! curious.) You can add a config to specify the delay by adding the following line to any file:

auth       optional   pam_faildelay.so  delay=1500000  

(You can read the man page of this module via man pam_faildelay.)

And change the value of the delay= (which is in microseconds) in any of the config files.

For example, my /etc/pam.d/sudo file is now:

auth       optional   pam_faildelay.so  delay=1000000

@include common-auth
@include common-account
@include common-session-noninteractive

Which gives me 1000000 microseconds of a delay when I password-authenticate with sudo and fail.

(If you mess around with PAM configuration on systems over the internet, you should also look into how PAM interacts with sshd. Read /etc/ssh/sshd_config's text info block on the UsePAM option, /etc/pam.d/sshd file, and do some Googling as well.)

You can also mess around with the control flags (optional in the case of pam_faildelay.so to something that better suits you. I won't go into that now, but you can find their meanings here: https://linux.die.net/man/5/pam.d

I hope this helps somehow. It's really interesting and I wish I had time today to fall into the PAM rabbit-hole but that's next time and we can write a blog post then too :)

I had trouble running the Datadog Agent (v6) on my Raspberry Pi. Here's what I did to get it running. I guess. Also available in this gist, yay.

Sections:

1. Installing Go (skip if you already have Go 1.9+)
2. Install/build the Datadog Agent

System Info:

pxpi is the Raspberry Pi's host name.

root@pxpi:/etc/datadog-agent# uname -a

Linux pxpi 4.14.50-v7+ #1122 SMP Tue Jun 19 12:26:26 BST 2018 armv7l GNU/Linux  

root@pxpi:/etc/datadog-agent# cat /etc/*rel*

/usr/lib/arm-linux-gnueabihf/libarmmem.so
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"  
NAME="Raspbian GNU/Linux"  
VERSION_ID="8"  
VERSION="8 (jessie)"  
ID=raspbian  
ID_LIKE=debian  
HOME_URL="http://www.raspbian.org/"  
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"  
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"  

1. Install Go (Golang): without GVM

Note: I haven't tried gvm, but the corresponding guide is here: https://github.com/tgogos/rpi_golang#2-with-go-version-manager-gvm. The rest of this guide will show how to install Go without GVM.

Note: This is from this fork of tgogos/rpi_golang, which has instructions on how to install Go version 1.10.3.

Quick Summary:

1. Use the pre-built binary in the repo to install Go 1.4.3
2. Optionally use Go 1.4.3 to upgrade (build) Go 1.10.3

This presumes you're the root user. If you are not, you may need to append sudo to some of the following commands.

Optionally, ensure that the following directories do not exist as they may conflict with the process.

• /usr/local/go
• $HOME/go1.4

1. Clone the repo:

git clone https://github.com/tgogos/rpi_golang.git  
cd rpi_golang/  

2. Install either only 1.4.3 or upgrade to 1.10.3:

For 1.4.3 only:

If you have no intention of upgrading to 1.10.3, you can untar the binary in the repo into /usr/local.

# untar into /usr/local
tar -xzf go1.4.3.linux-armv7.tar.gz -C /usr/local

# Add to shell and .bashrc
export PATH=/usr/local/go/bin:$PATH  
echo "export PATH=/usr/local/go/bin:$PATH" >> $HOME/.bashrc

# go version should now output something
go version

# If you're happy with 1.4, you can stop at this point.

You're done!

For 1.10.3:

If you would like to upgrade to 1.10.3, follow this to untar the binary from the repo into a different location, and use it to bootstrap the build:

Run rm -rf /usr/local/go if you accidentally made this directory already.

# We use the 1.4 binary in the repo to bootstrap building 1.10:
# While still in rpi_golang directory, make the alternate directory:
mkdir -p $HOME/go1.4

# Untar into that directory
tar -xzf go1.4.3.linux-armv7.tar.gz -C $HOME/go1.4 --strip-components=1

# Download and untar the 1.10.3 src into /usr/local
wget https://dl.google.com/go/go1.10.3.src.tar.gz  
tar -xz -C /usr/local -f go1.10.3.src.tar.gz  

Build 1.10.3:

cd /usr/local/go/src

time GOROOT_BOOTSTRAP=$HOME/go1.4 ./make.bash  

Output:

A successful output will look something like:

root@pxpi:/usr/local/go/src# time GOROOT_BOOTSTRAP=$HOME/go1.4 ./make.bash

Building Go cmd/dist using /root/go1.4.  
Building Go toolchain1 using /root/go1.4.  
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.  
Building Go toolchain2 using go_bootstrap and Go toolchain1.  
Building Go toolchain3 using go_bootstrap and Go toolchain2.


Building packages and commands for linux/arm.  
---
Installed Go for linux/arm in /usr/local/go  
Installed commands in /usr/local/go/bin

real    8m42.421s  
user    18m36.579s  
sys     0m44.624s


# go version:
root@pxpi:/usr/local/go/src# go version  
go version go1.10.3 linux/arm  

Set up your paths and environment variables:

Add the following to your .bashrc, .bash_profile, .zshrc, or what have you.

export PATH=$PATH:/usr/local/go/bin  
export GOPATH=$HOME/go  
export PATH=$PATH:$GOPATH/bin  

Don't forget to source it or reload your shell.

Install datadog-agent

Building for 32-bit ARM requires the Puppy variant of the datadog agent. See: https://github.com/DataDog/datadog-agent/issues/1069

1. Install dependencies:

• Python2.7
• invoke
• Go 1.9+
• dep

1. Install system dependencies:

This presumes you are root or have sudo access. Optionally what you already have:

# For all:
sudo apt-get update

# Python 2.7
sudo apt-get install python2.7-dev

# Install snmpd -- not sure if this is needed for the Puppy agent
sudo apt-get install libsnmp-base libsnmp-dev snmp-mibs-downloader

# Install systemd dev -- again, not sure if this is built against on the Puppy agent
sudo apt-get install libsystemd-dev

2. Installing invoke:

pip install invoke  

3. Installing dep:

Dep does not support ARM binaries. You must go get it.

go get -u github.com/golang/dep/cmd/dep  

The following should now work if $GOPATH is set up correctly.
If it is not set up correctly, do so now. Remember that go env will print out Go env vars which is not necessarily the same as your shell's.

root@pxpi:/etc/datadog-agent# dep  
Dep is a tool for managing dependencies for Go projects

Usage: "dep [command]"  
[...]

2. Download/clone datadog agent source

The current README's example states to clone the directory (especially if you would like the master branch) but I'm guessing go get -u github.com/DataDog/datadog-agent should work as essentially the same:

git clone https://github.com/DataDog/datadog-agent.git $GOPATH/src/github.com/DataDog/datadog-agent  

3. Building the agent

Building for 32-bit ARM requires the Puppy variant of the datadog agent. See: https://github.com/DataDog/datadog-agent/issues/1069

cd $GOPATH/src/github.com/DataDog/datadog-agent

invoke deps  
invoke agent.build --puppy  

Check if it runs:

From https://github.com/DataDog/datadog-agent/blob/master/README.md#run:

cd $GOPATH/src/github.com/DataDog/datadog-agent

# Might error out unless you set an API key in 
# ./bin/agent/dist/datadog.yaml
# You can also export it as `DD_API_KEY`
# e.g. export DD_API_KEY=1234

./bin/agent/agent -c bin/agent/dist/datadog.yaml

# OR
# DD_API_KEY=<KEY HERE> ./bin/agent/agent -c bin/agent/dist/datadog.yaml

5. Postinstall (optional):

Move and/or copy files into expected directories

This depends on your preferences, but this is how I decided to finalize my install:

Move $GOPATH/src/github.com/DataDog/datadog-agent/ into /opt/ (to be compatible with normal package distributions).

cd $GOPATH/src/github.com/DataDog/  
mv datadog-agent /opt/  

Copy the config files into /etc/datadog-agent and edit as necessary:

mkdir -p /etc/datadog-agent/

cd /opt/datadog-agent/bin/agent/dist  
cp -r . /etc/datadog-agent/  

Edit /etc/datadog-agent/datadog.yaml to add your API key.

Configure a user:

I didn't need to do this part since I have a specific user/group setup for my development machines, but this is to illustrate how you might.

This is similar to how it's done in the Dockerfile.

The difference here is that I didn't add it to the root group, but you can choose to do what you'd like.

# create user if it does not yet exist
adduser --system --no-create-home --disabled-password --ingroup dd-agent dd-agent

# Give permissions to relevant directories
chown -R dd-agent:dd-agent /etc/datadog-agent/ /opt/datadog-agent/ /var/log/datadog/  
chmod g+r,g+w,g+X -R /etc/datadog-agent/ /var/log/datadog/  

(To add dd-agent to the root group, you can do the following instead of the above adduser command, then chown accordingly):

adduser --system --no-create-home --disabled-password --ingroup root dd-agent  
chown -R dd-agent:root /etc/datadog-agent/ /opt/datadog-agent/ /var/log/datadog/  

With guidance from this file, here's the systemd service for the puppy agent:

root@pxpi:~# cat /lib/systemd/system/datadog-agent.service

[Unit]
Description="Datadog Agent"  
After=network.target

[Service]
Type=simple  
PIDFile=/opt/datadog-agent/run/agent.pid  
User=dd-agent  
Restart=on-failure  
ExecStart=/opt/datadog-agent/bin/agent/agent start -p /opt/datadog-agent/run/agent.pid

[Install]
WantedBy=multi-user.target  

For more post-install steps on Debian-ish systems, you can also take a look at the omnibus postinstall script in the datadog agent repo.

Last tested with version Docker version 18.09.3 on Ubuntu 16.04, Debian 9 (stretch), macOS Mojave (10.14.4).

NOTE: If your problem is connecting TO containers FROM a macOS host, see this post: https://biancatamayo.me/blog/docker-troubleshooting-macos-network/

Sometimes you need to be able to connect to the host network from inside a Docker container. Could be for debugging, or small projects, or whatever reason. I ran into this need and after googling, it took me way too long to eventually find the answer in the docs. If you're in the same situation, I hope I can save you some time!

Update April 2019: This won't work for Kubernetes pods/services. Kubernetes networking works differently from plain Docker networking.

Depending on your use case, a network of type host may not work (and requires some setup). Docker provides a way to add hosts into your container's /etc/hosts file. I'll show it here in two ways, one via CLI and one via docker-compose as a bonus.

1. CLI: Using the --add-host parameter with docker run

If you're on macOS using Docker Desktop, it's easier. Scroll down or skip to note for macOS.

Main idea: pass in the docker0 IP address to the container via --add-host:

Get the host machine's address for the docker0 interface and put it in shell var (note that docker0 doesn't exist on macOS, scroll to the next part if you're on a Mac). Of course, this part is optional if you just want to paste the IP in.

We put it in the HOST_IP shell var like so:

$ HOST_IP=`ip -4 addr show scope global dev docker0 | grep inet | awk '{print \$2}' | cut -d / -f 1`

(To find the IP address without using the above snippet, you can use the command ifconfig docker0).

Then we execute docker run with --add-host, using the variable we set, e.g.:

$ docker run --add-host outside:$HOST_IP --name busybox -it busybox /bin/sh

Now, within the container, we can inspect /etc/hosts, we see an extra line has been added:

bcat@remote:~$ docker run --add-host outside:$HOST_IP --name busybox -it busybox /bin/sh

## now we're in the container:

/ $ cat /etc/hosts
127.0.0.1    localhost  
::1    localhost ip6-localhost ip6-loopback
fe00::0    ip6-localnet  
ff00::0    ip6-mcastprefix  
ff02::1    ip6-allnodes  
ff02::2    ip6-allrouters  
172.17.0.1    outside <---- THIS ONE!  
172.17.0.3    a8300156a695  

The IP address 172.17.0.1 which we passed in via docker run is now resolvable via the hostname "outside"!

We can verify it:

/ $ ping outside
PING outside (172.17.0.1): 56 data bytes  
64 bytes from 172.17.0.1: seq=0 ttl=64 time=0.326 ms  
64 bytes from 172.17.0.1: seq=1 ttl=64 time=0.118 ms  
64 bytes from 172.17.0.1: seq=2 ttl=64 time=0.098 ms  
64 bytes from 172.17.0.1: seq=3 ttl=64 time=0.137 ms  
^C
--- outside ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss  
round-trip min/avg/max = 0.098/0.169/0.326 ms

note for macOS (and Windows):

This supposedly also works on Windows, but as I don't have a Windows dev machine, I can't test it.

Docker for Mac does not have the docker0 interface¹ that's used in the above example. Instead, you can actually simply go into the container and use a special macOS-only DNS name (docker.for.mac.localhost) that comes out of the box (version 17.06+):

Update April 2019: The DNS name is now called host.docker.internal in the docs, though docker.for.mac.localhost works just as well for now in Docker 18.09.3. Additionally, you can also now also use gateway.docker.internal to access the host's gateway.

# In my macOS:

$ bianca@burritomac:~$ docker run -it busybox /bin/sh


## now we're in the container!:

## pinging docker.for.mac.localhost
/ $ ping docker.for.mac.localhost
PING docker.for.mac.localhost (192.168.65.2): 56 data bytes  
64 bytes from 192.168.65.2: seq=0 ttl=37 time=0.420 ms  
64 bytes from 192.168.65.2: seq=1 ttl=37 time=0.564 ms  
^C
--- docker.for.mac.localhost ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss  
round-trip min/avg/max = 0.420/0.492/0.564 ms


## pinging host.docker.internal

/ $ ping host.docker.internal
PING host.docker.internal (192.168.65.2): 56 data bytes  
64 bytes from 192.168.65.2: seq=0 ttl=37 time=0.289 ms  
^C
--- host.docker.internal ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss  
round-trip min/avg/max = 0.289/0.289/0.289 ms


## pinging the host's gateway:

/ $ ping gateway.docker.internal
PING gateway.docker.internal (192.168.65.1): 56 data bytes  
64 bytes from 192.168.65.1: seq=0 ttl=37 time=0.265 ms  
64 bytes from 192.168.65.1: seq=1 ttl=37 time=0.625 ms  
^C
--- gateway.docker.internal ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss  
round-trip min/avg/max = 0.265/0.445/0.625 ms  

Easy. 🍰

From the docs:

The host has a changing IP address (or none if you have no network access). From 18.03 onwards our recommendation is to connect to the special DNS name host.docker.internal, which resolves to the internal IP address used by the host. This is for development purpose and will not work in a production environment outside of Docker Desktop for Mac.

The gateway is also reachable as gateway.docker.internal. [src]

2. docker-compose:

This mechanism also available docker-compose.yml files as the extra_hosts key, like so:

docker-compose.yml:

version: '2'  
services:  
  samplev2:
    image: "redis:alpine"
    extra_hosts:
       - "outside:172.17.0.1"

And since we took advantage of variable substitution in CLI example, I'll show how we can do the same here:

version: '2'  
services:  
  samplev2:
    image: "redis:alpine"
    extra_hosts:
       - "outside:${HOST_IP}"

In this example, we don't have an .env file, and HOST_IP is only a shell variable. To become an env var, we need export it first, and then run docker-compose:

$ bcat@remote:~$ export HOST_IP=$HOST_IP && docker-compose up -d

Note: I don't run it as sudo here, but remember that sudo won't work with export!

The -d flag runs it in the background, and we can go into the container and check out our /etc/hosts file in almost the same way as we did earlier. Since we didn't name the container, we grab the container ID using docker ps first, which is 0dde138913ee:

bcat@remote:~$ docker exec -it 0dde138913ee /bin/sh

/# cat /etc/hosts
127.0.0.1    localhost  
::1    localhost ip6-localhost ip6-loopback
fe00::0    ip6-localnet  
ff00::0    ip6-mcastprefix  
ff02::1    ip6-allnodes  
ff02::2    ip6-allrouters  
172.17.0.1    outside <---- IT'S HERE!  
172.21.0.2    0dde138913ee  

Success!

Anyway, hope this is helpful in some way. And if it is please let me know so I can write more! You can always find me on Twitter. :)

Update December 2019: I understand there's a desire for the convenience hostname host.docker.internal to be made available on all platforms, and not just macOS or Windows. I don't have an opinion on that, but if you do you can follow the lengthy discussion here: https://github.com/docker/for-linux/issues/264

Again, if your problem is connecting TO containers FROM a macOS host, see this post: https://biancatamayo.me/blog/docker-troubleshooting-macos-network/

Footnotes and such:

$ mysql -se "SHOW VARIABLES"

e.g.:

$ mysql -se "SHOW VARIABLES" | grep -e log_error -e general_log -e slow_query_log

Output (with the grep):

binlog_error_action    ABORT_SERVER  
general_log    OFF  
general_log_file    /usr/local/var/mysql/burritobear.log  
log_error    stderr  
log_error_verbosity    3  
slow_query_log    OFF  
slow_query_log_file    /usr/local/var/mysql/burritobear-slow.log  

There will be a changelog IN THIS BLOG POST tomorrow (probably), but just a summary:

• This is now a customized version of Ghost and Casper! There will be bugs, for sure!
• Please please report bugs to me on Twitter or something
• I am aware of perf issues. It's not slow but its not IDEAL
• I've also been messing with Google Analytics lately as a dataviz enthusiast and apparently it's a huge world so be aware of weird GA experiments
• The site is much more colorful! Woo!
• Think of everything as under 🛠 development all the time 🛠

I wanted to write a really quick script in Sublime Text 3 that I could debug and run without having to switch windows. I was a bit surprised that there isn't a zero-config, quick-install package. However, the config needed is very minimal.

Open the Command Palette (⌘⇧P) and choose "Build: New Build System",

In the file that then pops up, replace the contents with ¹:

{
    "cmd"       : ["bash", "$file"],
    "selector"  : "source.shell"
}

Save it as bash.sublime-build in the suggested directory, which should be anywhere in Sublime's Packages directory.

Now if you open up a shell script, you can execute it through Sublime Text and have the output pop up in Sublime Text's console by running "Build With: bash" in the Command Palette.

Note: Sublime Text could have a different $PATH loaded, in which case you may have to pass in a path key into the config, e.g.:

{
    "cmd"       : ["bash", "$file"],
    "selector"  : "source.shell",
    "path"      : "/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"
}

Extra links:

• http://docs.sublimetext.info/en/latest/reference/build_systems.html has more information on how to create more complex build systems

Footnotes:

¹ Credit for these snippets go to this gist thread

I’ve been fiddling around with git-flow for a while now, trying to extend its functionality and customize some things.

Unfortunately, after a while of no success in trying to find where and in which documentation I could find how the git-flow executable turns into git flow (with a space), I gave up.

(I mean, is it a POSIX thing? Is it a submodule? Is it my shell? Do they change my path? Do they override git? Do they detect my shell and create aliases? What is it? I didn’t know what it was called, and Googling didn’t help me too much.)

Anyway, I had a hunch. And sometimes, proving hunches through trial and error is faster than actually finding documentation when you don’t know the terminology.

• Okay it wasn’t completely a hunch. I was looking through the GITEXECPATH directory ($(git —exec-path)) which I found by reading the docs and saw that they were all basically scripts that had a similar filename pattern.

So, TIL that if you create an executable in your path with a filename that starts with “git-”, git automatically treats it like a subcommand.

Example:

Here’s a script that’s in my $PATH:
/Users/btamayo/bin/git-echotest.sh:

#!/usr/bin/env bash

echo "Hello you!"  

Now, in your shell:

$ git echotest
Hello you!  

You can also do things such as source a git-provided utility script that lets you use functions such as die and usage . I won’t go into it here since this is a miniblog but you can read more here: https://www.kernel.org/pub/software/scm/git/docs/git-sh-setup.html

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)  

If you installed MySQL through Homebrew, you can restart the server via:

$ /usr/local/Cellar/mysql/5.7.17/bin/mysql.server restart     

 ERROR! MySQL server PID file could not be found!
Starting MySQL  
..... SUCCESS!

Or simply:

$ mysql.server restart

On this day, I was having a couple of issues with my PATH, and as far as I can tell, everything was fine. So it was a new problem I've never come across before in all my (fair amount!) of years as a developer. That's when I googled and learned that bash has an internal hash table. The tricksy clever thing.

From bash(1):

See that? "A full search of the directories in PATH is performed only if the command is not found in the hash table."

If you didn't know about this before, you usually hit it like this, in the "woah, which which" scenario.

Here's the rundown:

# I have a script, installed globally
$ cat /usr/local/bin/hello-world
#!/usr/bin/env bash

echo "Hello world! This is my global executable!"

# Let's try it out
$ hello-world
Hello world! This is my global executable!

# Cool, it works! I'd actually like my own version of this so I can modify it, in ~/bin. 
$ cp /usr/local/bin/hello-world ~/bin
$ ls -l ~/bin
-rwxr-xr-x  1 bianca  staff  71 Mar 23 14:13 hello-world

# Cool, checking $PATH real quick
$ echo $PATH
/Users/bianca/bin:/usr/local/bin:/usr/local/sbin

# Looks good! Let me edit my script now
$ sed -i "" 's/global/local/g' /Users/bianca/bin/hello-world
$ cat /Users/bianca/bin/hello-world
#!/usr/bin/env bash

echo "Hello world! This is my local executable!"

# Nice. Testing it out...
$ hello-world
Hello world! This is my global executable!

# ...Wat. That's not right! Troubleshoot.
$ which hello-world
/Users/bianca/bin/hello-world

# Wait it's pointing to the right thing! What is this madness!
# Oh, right! hash!
$ hash
hits command  
    1 /usr/bin/which
    1 /usr/local/bin/hello-world

# Reset it
$ hash hello-world # or `hash -r` to clear everything
hello-world  
Hello world! This is my local executable!

# Success! Wow, that could have have been really annoying to debug if this example wasn't contrived.

Congrats. You're now prepared for the woah, which which scenario!

Bonus:

JSYK, zsh's hash behavior is different:

ZSH:

# ZSHELL

$ cat /usr/bin/hello-world
#!/usr/bin/env bash

echo "Hello world! This is my global executable!"

$ hello-world
Hello world! This is my global executable!

$ cp /usr/local/bin/hello-world ~/bin
$ sed -i "" 's/global/local/g' /Users/bianca/bin/hello-world
$ cat ~/bin/hello-world
#!/usr/bin/env bash

echo "Hello world! This is my local executable!"

$ hello-world
Hello world! This is my global executable!

$ hash hello-world # bash would re-read PATH here, zsh doesn't
$ hello-world
Hello world! This is my global executable!

$ hash -r # Drop the entire table

# Now it works!
$ hello-world
Hello world! This is my local executable!

# Will it work if we scrap it? (Doesn't seem like it in bash)
$ rm ~/bin/hello-world
$ hello-world
Hello world! This is my global executable!  

BASH:

# BASH

$ cat /usr/local/bin/hello-world
#!/usr/bin/env bash

echo "Hello world! This is my global executable!"

$ hello-world
Hello world! This is my local executable!

# No rebuilding tho
$ rm /Users/bianca/bin/hello-world
$ hello-world
-bash: /Users/bianca/bin/hello-world: No such file or directory

# But this works (Not in zshell)!
$ hash hello-world
$ hello-world
Hello world! This is my global executable!