segment error during ddev config

[mfrieling]

Describe the bug
I've upgraded my machine from DDEV 1.10.0 to 1.10.1 but then needed to start a project immediately for a bugfix and had no time to execute ddev config on it first. I did that after the bugfix while the project was still running and got the following error messages (while ddev config itself worked fine):

segment 2019/08/05 16:41:39 ERROR: sending request - Post https://api.segment.io/v1/batch: dial tcp: lookup api.segment.io on 127.0.0.53:53: server misbehaving
segment 2019/08/05 16:41:39 ERROR: 2 messages dropped because they failed to be sent and the client was closed

Expected behavior
Those internal error messages should not be shown, but only error messages which are relevant to the user, e.g. created by DDEV itself. And if those are relevant, they should be catched by DDEV and wrapped/shown with a more explanatory message what they mean for the user or hints how to solve them.

Version and configuration information (please complete the following information):

• Host computer OS and Version: Linux Mint 19 (Cinnamon 3.8.9)
• Docker version information: 19.03.0., build aeac949
• ddev version information: 1.10.1

[rfay]

Thanks for this report.

[peterkraume]

I have a similar error message, but on every ddev command:

segment 2019/08/28 22:45:03 ERROR: sending request - Post https://api.segment.io/v1/batch: x509: certificate is valid for *.ddev.local, localhost, ddev-router, ddev-router.ddev_default, not api.segment.io
segment 2019/08/28 22:45:03 ERROR: 2 messages dropped because they failed to be sent and the client was closed

I'm using ddev version v1.10.2.

[rfay]

I imagine that you have an ad blocker or equivalent that is doing a DNS lookup of api.segment.io and returning 127.0.0.1 or 0.0.0.0 for it. You can test with ping api.segment.io and see what it does. Yours will likely return 127.0.0.1, which is invalid.

If you don't want this behavior:

1. Turn off the over-aggressive behavior of your ad-blocker or other local DNS filter or
2. Disable instrumentation with ddev config global --instrumentation-opt-in=false, which will prevent ddev from trying to access segment.

[peterkraume]

Thx a lot for the fast reply. You're right, I have a Pi-hole installed for network-wide ad blocking. I guess I'll put api.segment.io on the whitelist.

[rfay]

Both of these were a result of local host misconfiguration, which caused api.segment.io to be resolved as 127.0.0.1. I'm going to say this is not a ddev problem, but I wish segment didn't emit this stuff without permission. Closing for now, happy to continue the conversation here.

[jameswilson]

@rfay what is the effect of disabling instrumentation with ddev config global --instrumentation-opt-in=false ?

I tried to understand using ddev config global --help but the documentation wasn't any clearer.

$ ddev config global --help
Change global configuration

Usage:
  ddev config global [flags]

Examples:
ddev config global --instrumentation-opt-in=false
ddev config global --omit-containers=dba,ddev-ssh-agent

Flags:
  -h, --help                         help for global
      --instrumentation-opt-in       instrmentation-opt-in=true
      --nfs-mount-enabled            Enable NFS mounting on all projects globally
      --omit-containers string       For example, --omit-containers=dba,ddev-ssh-agent
      --router-bind-all-interfaces   router-bind-all-interfaces=true

Global Flags:
  -j, --json-output   If true, user-oriented output will be in JSON format.

[rfay]

Hi @jameswilson thanks for asking. The doc is at https://ddev.readthedocs.io/en/stable/users/cli-usage/#opt-in-usage-information

ddev config global --instrumentation-opt-in=false turns off reporting to segment, so no "phone home" behavior. We'd love it if you'd leave it on, but understand if you don't want to. Leaving it on helps us to understand how people use the tool.

A agree that help could be better!