This Ziti TV will be another working session and office hours. Docker is a convenient mechanism for deploying applications, but it's easy to get lost along the way. We'll take a look at the existing docker quickstarts, how they work and how to troubleshoot them.
If you have any questions, we'll take those too, fire away! You can ask here or live.
Catch it live or catch the replay at YouTube:
Hello
I have followed all the videos you recommended, but it seems that there are some errors when creating the configurations 'Web-hello-world-host-config' and 'Web-hello-world-intercept-config.' Could you help me verify?
Hi @Samitthichots, welcome to the community and to OpenZiti!
To list a specific config you need to supply a valid filter. It'd look like: ziti edge list configs 'name contains "hello"'
Bash and ziti are sensitive to the correct single/double quotes. Make sure you use them as I've shown and you should get a result
Thank you very much, I may have misunderstood it. Initially, I followed everything completely, but it seems that my client machine cannot connect to openziti/hello-world. Is it possible for you to help me verify?.Do I need to map the host or change the IP/DNS settings?
❯ ping ziti.tv.docker.example
PING ziti.tv.docker.example (100.64.0.3): 56 data bytes
64 bytes from 100.64.0.3: icmp_seq=0 ttl=255 time=1.319 ms
64 bytes from 100.64.0.3: icmp_seq=1 ttl=255 time=0.565 ms
64 bytes from 100.64.0.3: icmp_seq=2 ttl=255 time=0.593 ms
64 bytes from 100.64.0.3: icmp_seq=3 ttl=255 time=0.330 ms
64 bytes from 100.64.0.3: icmp_seq=4 ttl=255 time=0.651 ms
64 bytes from 100.64.0.3: icmp_seq=5 ttl=255 time=0.364 ms
^C
--- ziti.tv.docker.example ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.330/0.637/1.319/0.327 ms
~ 5s
❯ curl http://ziti.tv.docker.example:9000
^C
~ 20s
You need to be careful with ping. Ping it a classic IP based tool. Though it appears to work with ziti in this case, ziti doesn't tunnel icmp at this time. If your curl command fails, you need to look in your tunneler logs for the reason why. Look through those logs and it should become clear, or there will be log messages that might map to another forum post with more help.
Thankyou, I have a question. Can we verify if the client can communicate with the edge router.
I would expect you to see a log message indicating something like, "NO_EDGE_ROUTER" in the client logs. The other way would be to open the routers config file, find the advertised address for the edge listener, and use openssl s_client to connect to the edge router. That will verify the router is online and reachable.
After the client connects, I checked the logs on the Controller and found the following logs. Where should I start troubleshooting?
this is logs
"ziti-controller-1 | [ 47.352] ERROR transport/v2/tls.(*sharedListener).processConn [tls:0.0.0.0:7501]: {remote=[202.129.207.11:61343] error=[remote error: tls: unknown certificate authority]} handshake failed
ziti-controller-1 | [ 52.375] ERROR transport/v2/tls.(*sharedListener).processConn [tls:0.0.0.0:7501]: {error=[remote error: tls: unknown certificate authority] remote=[202.129.207.11:61412]} handshake failed"
202.129.207.11 is my ip address
"❯ curl ifconfig.io
202.129.207.11"
My guess is that these errors are generally from using the ziti CLI tool with username/password auth and not certificate auth. Here on top I've started a controller and on bottom i login to it. You'll see every time i login, i get that error. All it's telling you is that a connection is being established without verifying the incoming certificate first.
Are you having some other issue, or are you just looking through logs and wondering if this is some error to be concerned with?
