Unable to log in to the dashboard

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 无法登录 dashboard

| username: 轩辕青霄

[TiDB Usage Environment] /Test
[Reproduction Path] Error when logging into the dashboard


I checked and thought it was a permission issue, so I created a dashboardAdmin account, but the same error occurred.

I checked the error again and found that the MySQL connection process was stuck, so I restarted TiDB, but the error persisted.

From the cluster setup to now, apart from some sqlmod operations, I added:

server_configs:
  tidb:
    proxy-protocol.networks:

This parameter was not added in the production environment, and it works fine.
Thinking about it, haha, I deleted this parameter and it worked. (艹皿艹)
[Resource Configuration]
6 machines 16c64G2000G hard disk
[Attachments: Screenshots/Logs/Monitoring]
PD log


Text version for easier search by others:

[2023/11/23 18:46:14.042 +08:00] [WARN] [client.go:158] ["Unknown error occurred while opening TiDB connection"] [error="commands out of sync. You can't run this command now"]
[2023/11/23 18:46:14.042 +08:00] [WARN] [error.go:89] ["Error when handling request"] [uri=/dashboard/api/user/login] [remoteAddr=10.1.118.171:1645] [errorFullText="authenticate failed, cause: error.api.user.signin.other: commands out of sync. You can't run this command now\n at github.com/pingcap/tidb-dashboard/pkg/apiserver/user/sqlauth.(*Authenticator).Authenticate()\n\t/go/pkg/mod/github.com/pingcap/tidb-dashboard@v0.0.0-20221201151320-ea3ee6971f2e/pkg/apiserver/user/sqlauth/sqlauth.go:40\n at github.com/pingcap/tidb-dashboard/pkg/apiserver/user.(*AuthService).authForm()\n\t/go/pkg/mod/github.com/pingcap/tidb-dashboard@v0.0.0-20221201151320-ea3ee6971f2e/pkg/apiserver/user/auth.go:218\n at github.com/pingcap/tidb-dashboard/pkg/apiserver/user.NewAuthService.func1()\n\t/go/pkg/mod/github.com/pingcap/tidb-dashboard@v0.0.0-20221201151320-ea3ee6971f2e/pkg/apiserver/user/auth.go:110\n at github.com/breeswish/gin-jwt/v2.(*GinJWTMiddleware).LoginHandler()\n\t/go/pkg/mod/github.com/breeswish/gin-jwt/v2@v2.6.4-jwt-patch/auth_jwt.go:437\n at github.com/pingcap/tidb-dashboard/pkg/apiserver/user.(*AuthService).LoginHandler()\n\t/go/pkg/mod/github.com/pingcap/tidb-dashboard@v0.0.0-20221201151320-ea3ee6971f2e/pkg/apiserver/user/auth.go:314\n at github.com/gin-gonic/gin.(*Context).Next()\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165\n at github.com/pingcap/tidb-dashboard/util/rest.ErrorHandlerFn.func1()\n\t/go/pkg/mod/github.com/pingcap/tidb-dashboard@v0.0.0-20221201151320-ea3ee6971f2e/util/rest/error.go:70\n at github.com/gin-gonic/gin.(*Context).Next()\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165\n at github.com/gin-contrib/gzip.Gzip.func2()\n\t/go/pkg/mod/github.com/gin-contrib/gzip@v0.0.1/gzip.go:47\n at github.com/gin-gonic/gin.(*Context).Next()\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165\n at github.com/gin-gonic/gin.CustomRecoveryWithWriter.func1()\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.7.4/recovery.go:99\n at github.com/gin-gonic/gin.(*Context).Next()\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165\n at github.com/gin-gonic/gin.(*Engine).handleHTTPRequest()\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.7.4/gin.go:489\n at github.com/gin-gonic/gin.(*Engine).ServeHTTP()\n\t/go/pkg/mod/github.com/gin-gonic/gin@v1.7.4/gin.go:445\n at github.com/pingcap/tidb-dashboard/pkg/apiserver.(*Service).handler()\n\t/go/pkg/mod/github.com/pingcap/tidb-dashboard@v0.0.0-20221201151320-ea3ee6971f2e/pkg/apiserver/apiserver.go:244\n at net/http.HandlerFunc.ServeHTTP()\n\t/usr/local/go/src/net/http/server.go:2109\n at github.com/pingcap/tidb-dashboard/pkg/utils.(*ServiceStatus).NewStatusAwareHandler.func1()\n\t/go/pkg/mod/github.com/pingcap/tidb-dashboard@v0.0.0-20221201151320-ea3ee6971f2e/pkg/utils/service_status.go:67\n at net/http.HandlerFunc.ServeHTTP()\n\t/usr/local/go/src/net/http/server.go:2109\n at net/http.(*ServeMux).ServeHTTP()\n\t/usr/local/go/src/net/http/server.go:2487\n at go.etcd.io/etcd/embed.(*accessController).ServeHTTP()\n\t/go/pkg/mod/go.etcd.io/etcd@v0.5.0-alpha.5.0.20220915004622-85b640cee793/embed/serve.go:381\n at net/http.serverHandler.ServeHTTP()\n\t/usr/local/go/src/net/http/server.go:2947\n at net/http.(*conn).serve()\n\t/usr/local/go/src/net/http/server.go:1991\n at runtime.goexit()\n\t/usr/local/go/src/runtime/asm_amd64.s:1594"]
| username: 大飞哥online | Original post link

proxy-protocol.networks: You need to follow it with a value. Did you write nothing?

| username: 大飞哥online | Original post link

Supports networks named network1 and network2.

| username: Kongdom | Original post link

It seems that although your issue and mine are not the same, they should both be caused by network connectivity problems.

| username: Jellybean | Original post link

When deploying the dashboard, if the proxy-protocol.networks parameter is configured, there is a pitfall: after configuring this parameter, TiDB will allow the configured source IP addresses to use the PROXY protocol to connect to TiDB, and will reject these source IP addresses from using non-PROXY protocol connections.

In the internal Dashboard, it directly connects to the tidb-server for permission verification, which can lead to access failure issues.

To solve this problem, usually, you either do not configure the proxy-protocol.networks parameter or set the addresses in the proxy-protocol.networks parameter to external IP nodes where the tidb server is not deployed.

| username: Fly-bird | Original post link

:100: :100: :100:

| username: ShawnYan | Original post link

Is this resolved?

| username: tidb菜鸟一只 | Original post link

The proxy-protocol.networks can be followed by an IP or a list of IP segments or *. After setting it, these IPs can only connect through proxy mode and cannot connect to the TiDB server on port 4000, and the dashboard cannot connect either. I suspect you set the parameter but didn’t provide a value, so by default, it is treated as *, which means all direct connections to the TiDB server on port 4000 are blocked, and the dashboard cannot connect either.

| username: dba远航 | Original post link

Mine automatically jumps from 2379 to 2382, not sure why.

| username: oceanzhang | Original post link

Is this parameter binding to the network card?

| username: Jellybean | Original post link

No. It is related to the IP address you configured for load balancing. The official website has very detailed instructions, you can check the documentation.

| username: 小龙虾爱大龙虾 | Original post link

Learned.

| username: 普罗米修斯 | Original post link

Learned that login can be restricted.

| username: 轩辕青霄 | Original post link

I wrote it. After reading jellybean’s reply, I understood. Thank you.

| username: 轩辕青霄 | Original post link

Problem solved.

| username: zhanggame1 | Original post link

It’s not a deletion issue, right? Did you restart PD?

| username: 像风一样的男子 | Original post link

I’ve seen this question more than once, it’s indeed unfriendly.

| username: Kongdom | Original post link

:+1: :+1: :+1: This is drawing inferences from one instance~ Very good

| username: andone | Original post link

Did you specify a password when installing TiDB again?

| username: Billmay表妹 | Original post link

Please do not bring up issues that have already been resolved.