I have set up OpenZiti using the Docker quickstart. Once I have my containers set up and running i usually enter the Ziti Edge Controller container docker exec -it <ziti-edge-controller-id> bash, execute zitiLogin and then I can start running ziti commands.
However, this only works for the duration that I assume the first session lasts, because on subsequent zitiLogins I just get the following message
error: unable to authenticate to https://my.custom.domain.com:1280/edge/management/v1. Status code: 401 Unauthorized, Server returned: {
"error": {
"code": "INVALID_AUTH",
"message": "The authentication request failed",
"requestId": "aaaaaaaaaa"
},
"meta": {
"apiEnrollmentVersion": "0.0.1",
"apiVersion": "0.0.1"
}
}
For sure this might be because I’m doing something wrong and/or my understanding about the zitiLogin command is flawed, could somebody point me in the right direction?
Have you changed the admin password? I tried to find a post that I spoke about it, and it may no longer be a thing, but if I changed the admin password I needed to use ‘ziti edge login’ instead of ‘zitiLogin’ as passing the password through the later would not work. However since you say it works the first time is interesting.
Assuming it’s what I’m guessing this is, this is the same bug that keeps hitting people, if you stop the docker container for the controller, when it comes back online it has the very unfortunate bug of overwriting the ziti.env file. That’s 99% fine, except for the fact that the ZITI_PWD is overwritten at that time, which leads to subsequent zitiLogin functions failing because the password that’s sourced, is not the correct password… I’m going to try to get this bug fixed since it keeps hitting people … docker env password is renewed at each `docker-compose up` · Issue #1013 · openziti/ziti · GitHub
The best thing to do is to either archive that password after the very first time you bring the compose environment up, or change the password to something you can remember until we fix this…
You can use zitiLogin as long as you set ZITI_PWD since zitiLogin is just a short alias:
That explains a lot of headaches I’ve been having the past 4 days, but since I was having other Ziti-unrelated issues I thought I was making some mistakes xDD
Luckily I stored the first password it shows in the logs. Gotta go to sleep, but tomorrow I’ll try what you mentioned about setting ZITI_PWD manually and retyring zitiLogin
One question though, does this bug you mentioned affect in any way the ziti-controller and ziti-edge-router behaviours if the containers are stopped and started again?
I also had some weird issues at some point where after stopping and restarting everything the router wouldn’t connect to the controller… but since now it seems that I don’t have that issue (even after start/stopping containers) I assume that I did something wrong probably.
No, it should not. If you’re finding that the case, perhaps you’re using docker compose down -v? Using -v will remove the entire pki that’s generated for the controller. If that pki is destroyed, it’d definitely impact routers/controller/the overlay in general. It would show up as some kind of pki type error from the router/controller indicating the router isn’t able to establish a secure connection, or something like that (I don’t recall the exact error, something like that though). Hopefully that makes sense.
Aright then I probably messed up pretty badly when I was testing out stuff xD Forget about that then, I’ll report back when I try out what you mentioned about ZITI_PWD
I’m going to try to get this bug fixed since it keeps hitting people …