https://www.gooddata.com/ logo
Join Slack
Powered by
Hi GD team, I am getting ```title: "Not Found", st...
# gooddata-cn
h
Hi GD team, I am getting
Copy code
title: "Not Found", status: 404, detail: "404 NOT_FOUND "User is not registered"",…}
detail
: 
"404 NOT_FOUND \"User is not registered\""
status
: 
404
title
: 
"Not Found"
traceId
: 
"7d0cd6434a11c3a3"
I bring up the new GD in different AWS regions with new EKS, then back up and restore the DB . User creation works fine, but I can't access my existing user. I did remap the user to the Org as well,
Copy code
{"data":{"id":"insights","type":"user","attributes":{"authenticationId":"CiQwMjRmNWU3Yy0xxxxxxxs"}},"links":{"self":"<https://insights.xxxx/api/v1/entities/users/insights>"}}%
even the new user don't has any access to our workspace or data set , it is all empty on studio
r
please make sure the 
authenticationId
attribute exactly matches the 
cn
attribute your identity provider sets in oauth2 token. If you're using built-in Identity provider, migration using database backup/restore may not be sufficient if you didn't also migrated "dex" database. Check authentication ids for logins as they are returned by 
GET /api/v1/auth/users
API. There authenticationids must match authenticationids of users in /api/v1/entities/users
h
GET /api/v1/auth/users
Copy code
{
        "email": "insights@insights.xxx.zz",
        "password": null,
        "displayName": "DevOps",
        "authenticationId": "CiQ4MjI2NGE4My00MmZlLTQ5MDMtYThiYy03MmJmMTNjMWExZTISBWxvY2Fs"
    },
GET /api/v1/entities/users
Copy code
{
            "id": "insights.zz",
            "type": "user",
            "attributes": {
                "authenticationId": "CiQ4MjI2NGE4My00MmZlLTQ5MDMtYThiYy03MmJmMTNjMWExZTISBWxvY2Fs"
            },
            "links": {
                "self": "<https://insights.xxx.zz/api/v1/entities/users/insights.zz>"
            }
        },
            }
        },
We are using DEX
The step to restore: • Take a snapshot of the AWS posgarse and move it to the new acc and new region • Since we have Pulser installed under this EKS, ignore installing Pulser • Install Nginx • Install Gooddata
Copy code
helm3 upgrade --namespace gooddata-cn-new --version 2.2.1 \
  -f customized-values-gooddata-cn.yaml \
  gooddata-cn-new gooddata/gooddata-cn 
# file name: customized-values-gooddata-cn.yaml
service:
  redis:
    hosts:
      - <http://new-insights-xxx-cache.amazonaws.com|new-insights-xxx-cache.amazonaws.com>
    port: 6379
    clusterMode: false
  postgres:
    host: <http://insight-xxx.rds.amazonaws.com|insight-xxx.rds.amazonaws.com>
    port: 5432
    username: xxxx
    password: yyyyy

deployRedisHA: false
deployPostgresHA: false
ingress:
  annotations:
    #<http://kubernetes.io/ingress.class|kubernetes.io/ingress.class>: nginx-new
    <http://nginx.ingress.kubernetes.io/force-ssl-redirect|nginx.ingress.kubernetes.io/force-ssl-redirect>: "true"
dex:
  ingress:
    authHost: 'auth.xxx.zz'
    annotations:
      <http://kubernetes.io/ingress.class|kubernetes.io/ingress.class>: nginx-new
license:
  key: "key/eyJhddffffffffff"
Then create the Org 
#your-org-definition.yaml
apiVersion: <http://controllers.gooddata.com/v1|controllers.gooddata.com/v1>
kind: Organization
metadata:
name: xxx-org-zz
spec:
id: xxx
name: "XXX, INC."
hostname: insights.xxx.zz
adminGroup: adminGroup
adminUser: admin
adminUserToken: "$5xxxxxxxxxuNG80"
Map user to the org : 
url -v --request POST \
--header "Authorization: Bearer $GDC_API_TOKEN" \
--header 'Content-Type: application/vnd.gooddata.api+json' \
--data '{
"data": {
"id": "insights",
"type": "user",
"attributes": {
"authenticationId": "CiQ4MjI2NGE4My00MmZlLTQ5MDMtYThiYy03MmJmMTNjMWExZTISBWxvY2Fs"
},
"relationships": {
"userGroups": {
"data": [ {
"id": "adminGroup",
"type": "userGroup"
} ]
}
}
}
}' <https://insights.xxx.zz/api/v1/entities/users>
r
Hello Hamid, those example responses you provided (GET /api/v1/auth/users, GET /api/v1/entities/users) were from the old or new cluster? the authHost on new cluster, as well as Organization's hostname remain the same as it used to be on old cluster? The migration using db snapshot is not tested and officially supported, but might work under certain conditions.
we recommend performing organization migration by exporting the full Organization layout, updating data source credentials and uploading it to new cluster deployment (after creating Organization custom resource).
👍 1
h
It was from a new cluster, Issue resolved.✅ Workaround: After creating the new Org, • From dex. client copies the id and secret TO • md.organization oauth_client_id and oauth_client_secret. With this, I don't need to remap the existing user to org again. This was the workaround.
r
Yes, I thought it might be related. When you create Organization, a new oauth client is registered in dex. so this new client doesn't match the existing client that was transferred during db restore operation. I'm glad it works for you.
🙏 1
Open in Slack
PreviousNext
Powered by