We could not log you in - contact an admin. [002] Failed to authenticate Try Again → #212

yindo commented

@timothycarambat commented on GitHub (Dec 30, 2023):

Ensure you have a database connected to the container via the DATABASE_URL environment variable and the connection string is correct
On boot of the container the default credentials will be created which are root@vectoradmin.com and password unless otherwise defined on container start
https://github.com/Mintplex-Labs/vector-admin/blob/6cad8a30a1a89f645e02e0663ccf8832dfe87047/backend/utils/boot/index.js#L51-L52

@timothycarambat commented on GitHub (Dec 30, 2023): - [ ] Ensure you have a database connected to the container via the `DATABASE_URL` environment variable and the connection string is correct - [ ] On boot of the container the default credentials will be created which are `root@vectoradmin.com` and `password` unless otherwise defined on container start https://github.com/Mintplex-Labs/vector-admin/blob/6cad8a30a1a89f645e02e0663ccf8832dfe87047/backend/utils/boot/index.js#L51-L52

yindo commented

@mascreativelabs commented on GitHub (Dec 30, 2023):

Where do I set the DATABASE_URL environment variable? Should I add it to the .env file?
What is the expected value for the variable?

@mascreativelabs commented on GitHub (Dec 30, 2023): Where do I set the `DATABASE_URL` environment variable? Should I add it to the `.env` file? What is the expected value for the variable?

yindo commented

@mascreativelabs commented on GitHub (Dec 31, 2023):

Here's my docker-compose.yml:

version: "3.9"
services:
  db:
    image: postgres
    container_name: vectoradmin-db
    hostname: vectoradmin-db
    mem_limit: 1g
    cpu_shares: 768
    ports:
      - 5433:5432
    networks:
      - vector-admin_default
    security_opt:
      - no-new-privileges:true
    user: 1026:100
    healthcheck:
      test: ["CMD", "pg_isready", "-q", "-d", "vdbms", "-U", "vectoradminuser"]
      timeout: 45s
      interval: 10s
      retries: 10
    volumes:
      - /volume1/docker/projects/vectoradmin/db:/var/lib/postgresql/data:rw
    environment:
      TZ: America/Los_Angeles
      POSTGRES_DB: vdbms
      POSTGRES_USER: vectoradminuser
      POSTGRES_PASSWORD: vectoradminpass
    restart: on-failure:5

  vectoradmin:
    image: mintplexlabs/vectoradmin:master
    container_name: vector-admin
    hostname: vector-admin
    mem_limit: 2g
    cpu_shares: 768
    ports:
      - 4950:3001
    networks:
      - vector-admin_default
    extra_hosts:
      - host.docker.internal:host-gateway
    cap_add:
      - SYS_ADMIN
    volumes:
      - /volume1/docker/projects/vectoradmin:/app/backend/storage
      - /volume1/docker/projects/vectoradmin/.env:/app/backend/.env
    environment:
      SERVER_PORT: 3001
      DISABLE_TELEMETRY: true
      TZ: America/Los_Angeles
      JWT_SECRET: secret
      SYS_EMAIL: root@vectoradmin.com
      SYS_PASSWORD: password
      INNGEST_EVENT_KEY: background_workers
      INNGEST_SIGNING_KEY: secret
      INNGEST_LANDING_PAGE: true
      DATABASE_CONNECTION_STRING: postgresql://vectoradminuser:vectoradminpass@vectoradmin-db:5432/vdbms     
    depends_on:
      db:
        condition: service_healthy

networks:
  vector-admin_default:
    driver: bridge
    external: true

Here's my .env:

SERVER_PORT="3001"
DISABLE_TELEMETRY="true"
TZ="America/Los_Angeles"
JWT_SECRET="secret"
SYS_EMAIL="root@vectoradmin.com"
SYS_PASSWORD="password"
INNGEST_EVENT_KEY="background_workers"
INNGEST_SIGNING_KEY="secret"
INNGEST_LANDING_PAGE="true"
DATABASE_CONNECTION_STRING="postgresql://vectoradminuser:vectoradminpass@vectoradmin-db:5432/vdbms"

Should I still add DATABASE_URL to the .env file? Wouldn't that be redundant with:

DATABASE_CONNECTION_STRING="postgresql://vectoradminuser:vectoradminpass@vectoradmin-db:5432/vdbms"

@mascreativelabs commented on GitHub (Dec 31, 2023): Here's my docker-compose.yml: ``` version: "3.9" services: db: image: postgres container_name: vectoradmin-db hostname: vectoradmin-db mem_limit: 1g cpu_shares: 768 ports: - 5433:5432 networks: - vector-admin_default security_opt: - no-new-privileges:true user: 1026:100 healthcheck: test: ["CMD", "pg_isready", "-q", "-d", "vdbms", "-U", "vectoradminuser"] timeout: 45s interval: 10s retries: 10 volumes: - /volume1/docker/projects/vectoradmin/db:/var/lib/postgresql/data:rw environment: TZ: America/Los_Angeles POSTGRES_DB: vdbms POSTGRES_USER: vectoradminuser POSTGRES_PASSWORD: vectoradminpass restart: on-failure:5 vectoradmin: image: mintplexlabs/vectoradmin:master container_name: vector-admin hostname: vector-admin mem_limit: 2g cpu_shares: 768 ports: - 4950:3001 networks: - vector-admin_default extra_hosts: - host.docker.internal:host-gateway cap_add: - SYS_ADMIN volumes: - /volume1/docker/projects/vectoradmin:/app/backend/storage - /volume1/docker/projects/vectoradmin/.env:/app/backend/.env environment: SERVER_PORT: 3001 DISABLE_TELEMETRY: true TZ: America/Los_Angeles JWT_SECRET: secret SYS_EMAIL: root@vectoradmin.com SYS_PASSWORD: password INNGEST_EVENT_KEY: background_workers INNGEST_SIGNING_KEY: secret INNGEST_LANDING_PAGE: true DATABASE_CONNECTION_STRING: postgresql://vectoradminuser:vectoradminpass@vectoradmin-db:5432/vdbms depends_on: db: condition: service_healthy networks: vector-admin_default: driver: bridge external: true ``` Here's my .env: ``` SERVER_PORT="3001" DISABLE_TELEMETRY="true" TZ="America/Los_Angeles" JWT_SECRET="secret" SYS_EMAIL="root@vectoradmin.com" SYS_PASSWORD="password" INNGEST_EVENT_KEY="background_workers" INNGEST_SIGNING_KEY="secret" INNGEST_LANDING_PAGE="true" DATABASE_CONNECTION_STRING="postgresql://vectoradminuser:vectoradminpass@vectoradmin-db:5432/vdbms" ``` Should I still add DATABASE_URL to the .env file? Wouldn't that be redundant with: ```DATABASE_CONNECTION_STRING="postgresql://vectoradminuser:vectoradminpass@vectoradmin-db:5432/vdbms"```

yindo commented

@timothycarambat commented on GitHub (Dec 31, 2023):

It would be redundant, yes. In any case, you should be able to inspect the users table and see which user exists.

Are you building from source or are you pulling from docker hub? When pulling from docker hub you should be able to boot with only some envs set and as long as the connection string is ok, you are good to go.

@timothycarambat commented on GitHub (Dec 31, 2023): It would be redundant, yes. In any case, you should be able to inspect the users table and see which user exists. Are you building from source or are you pulling from docker hub? When pulling from docker hub you should be able to boot with only some envs set and as long as the connection string is ok, you are good to go.

yindo commented

@mascreativelabs commented on GitHub (Dec 31, 2023):

It would be redundant, yes. In any case, you should be able to inspect the users table and see which user exists.

Are you building from source or are you pulling from docker hub? When pulling from docker hub you should be able to boot with only some envs set and as long as the connection string is ok, you are good to go.

Thank you @timothycarambat

I am pulling from docker hub:

image: mintplexlabs/vectoradmin:master

Using the following credentials to start:

SYS_EMAIL="root@vectoradmin.com"
SYS_PASSWORD="password"

I am seeing nothing worth noting in my logs (no error). I can provide the logs if you need them.
Can you tell me if you saw something wrong with my docker-compose.yml and .env files?

@mascreativelabs commented on GitHub (Dec 31, 2023): > It would be redundant, yes. In any case, you should be able to inspect the users table and see which user exists. > > Are you building from source or are you pulling from docker hub? When pulling from docker hub you should be able to boot with only some envs set and as long as the connection string is ok, you are good to go. Thank you @timothycarambat - I am pulling from docker hub: ```image: mintplexlabs/vectoradmin:master``` - Using the following credentials to start: ``` SYS_EMAIL="root@vectoradmin.com" SYS_PASSWORD="password" ``` I am seeing nothing worth noting in my logs (no error). I can provide the logs if you need them. Can you tell me if you saw something wrong with my `docker-compose.yml` and `.env` files?

yindo commented

@timothycarambat commented on GitHub (Dec 31, 2023):

When you attempt to login can you open the Network tab in the browser inspector window and confirm the URL that the login request is being sent to. Something tells me that the port remap might be conflicting with the default build for the frontend API interface. Since you bind 4950:3001 it may still be attempting to send a request to :3001 from the frontend

@timothycarambat commented on GitHub (Dec 31, 2023): When you attempt to login can you open the `Network` tab in the browser inspector window and confirm the URL that the `login` request is being sent to. Something tells me that the port remap might be conflicting with the default build for the frontend API interface. Since you bind `4950:3001` it may still be attempting to send a request to `:3001` from the frontend

yindo commented

@mascreativelabs commented on GitHub (Dec 31, 2023):

When you attempt to login can you open the Network tab in the browser inspector window and confirm the URL that the login request is being sent to. Something tells me that the port remap might be conflicting with the default build for the frontend API interface. Since you bind 4950:3001 it may still be attempting to send a request to :3001 from the frontend

Wow!!! that's a great explanation I'm going to try to bind with 3001:3001

However, if this solves the problem I'd have to stop anything-llm in other to use vector-admin it's a shame since it's the same company that created both docker images 🤔 ... that would have been great if the two configurations weren't in conflict with each other 😅

@mascreativelabs commented on GitHub (Dec 31, 2023): > When you attempt to login can you open the `Network` tab in the browser inspector window and confirm the URL that the `login` request is being sent to. Something tells me that the port remap might be conflicting with the default build for the frontend API interface. Since you bind `4950:3001` it may still be attempting to send a request to `:3001` from the frontend Wow!!! that's a great explanation I'm going to try to bind with `3001:3001` However, if this solves the problem I'd have to stop anything-llm in other to use vector-admin it's a shame since it's the same company that created both docker images 🤔 ... that would have been great if the two configurations weren't in conflict with each other 😅

yindo commented

@mascreativelabs commented on GitHub (Dec 31, 2023):

I get the same issue after changing the port to 3001:3001

Here's the log for vector-admin container after the boot:


      
2024-01-01T00:14:03.872288061Z Environment variables loaded from .env
2024-01-01T00:14:03.873460511Z Prisma schema loaded from prisma/schema.prisma
2024-01-01T00:14:03.882096499Z Datasource "db": PostgreSQL database "vdbms", schema "public" at "vectoradmin-db:5432"
2024-01-01T00:14:04.072120309Z 
2024-01-01T00:14:04.072267100Z 4 migrations found in prisma/migrations
2024-01-01T00:14:04.072349031Z 
2024-01-01T00:14:04.216328096Z 
2024-01-01T00:14:04.216453807Z No pending migrations to apply.
2024-01-01T00:14:04.257778079Z npm notice 
2024-01-01T00:14:04.258223773Z npm notice New patch version of npm available! 10.2.3 -> 10.2.5
2024-01-01T00:14:04.258454945Z npm notice Changelog: <https://github.com/npm/cli/releases/tag/v10.2.5>
2024-01-01T00:14:04.258947379Z npm notice Run `npm install -g npm@10.2.5` to update!
2024-01-01T00:14:04.259206372Z npm notice 
2024-01-01T00:14:05.882839738Z Environment variables loaded from .env
2024-01-01T00:14:05.883903297Z Prisma schema loaded from prisma/schema.prisma
2024-01-01T00:14:06.923357768Z 
2024-01-01T00:14:06.923838333Z ✔ Generated Prisma Client (v5.3.1) to ./node_modules/@prisma/client in 380ms
2024-01-01T00:14:06.923935284Z 
2024-01-01T00:14:06.923973464Z Start using Prisma Client in Node.js (See: https://pris.ly/d/client)
2024-01-01T00:14:06.924027164Z ```
2024-01-01T00:14:06.924075925Z import { PrismaClient } from '@prisma/client'
2024-01-01T00:14:06.924131665Z const prisma = new PrismaClient()
2024-01-01T00:14:06.924181456Z ```
2024-01-01T00:14:06.924225026Z or start using Prisma Client at the edge (See: https://pris.ly/d/accelerate)
2024-01-01T00:14:06.924281937Z ```
2024-01-01T00:14:06.924323717Z import { PrismaClient } from '@prisma/client/edge'
2024-01-01T00:14:06.924356367Z const prisma = new PrismaClient()
2024-01-01T00:14:06.924399148Z ```
2024-01-01T00:14:06.924443268Z 
2024-01-01T00:14:06.924482269Z See other ways of importing Prisma Client: http://pris.ly/d/importing-client
2024-01-01T00:14:06.924554869Z 
2024-01-01T00:14:06.962704212Z ┌─────────────────────────────────────────────────────────┐
2024-01-01T00:14:06.962861654Z │  Update available 5.3.1 -> 5.7.1                        │
2024-01-01T00:14:06.962937834Z │  Run the following to update                            │
2024-01-01T00:14:06.963002935Z │    npm i --save-dev prisma@latest                       │
2024-01-01T00:14:06.963065816Z │    npm i @prisma/client@latest                          │
2024-01-01T00:14:06.963128096Z └─────────────────────────────────────────────────────────┘
2024-01-01T00:14:07.505098122Z yarn run v1.22.19
2024-01-01T00:14:07.570884484Z $ /app/workers/node_modules/.bin/inngest-cli dev -u http://0.0.0.0:3355/background-workers
2024-01-01T00:14:07.649376050Z [2023-12-31 16:14:07 -0800] [106] [INFO] Starting gunicorn 20.1.0
2024-01-01T00:14:07.655372934Z [2023-12-31 16:14:07 -0800] [106] [INFO] Listening at: http://0.0.0.0:8888 (106)
2024-01-01T00:14:07.655585596Z [2023-12-31 16:14:07 -0800] [106] [INFO] Using worker: sync
2024-01-01T00:14:07.709884914Z [2023-12-31 16:14:07 -0800] [157] [INFO] Booting worker with pid: 157
2024-01-01T00:14:07.793942250Z [2023-12-31 16:14:07 -0800] [158] [INFO] Booting worker with pid: 158
2024-01-01T00:14:07.839947094Z [2023-12-31 16:14:07 -0800] [160] [INFO] Booting worker with pid: 160
2024-01-01T00:14:07.899226477Z [2023-12-31 16:14:07 -0800] [166] [INFO] Booting worker with pid: 166
2024-01-01T00:14:07.948010376Z setupFunctions failed fetch failed
2024-01-01T00:14:08.057188618Z 2023-12-31T16:14:08-08:00 INF runner > starting event stream | backend=redis
2024-01-01T00:14:08.057343510Z 2023-12-31T16:14:08-08:00 INF runner > service starting 
2024-01-01T00:14:08.057625952Z 2023-12-31T16:14:08-08:00 INF runner > subscribing to events | topic=events
2024-01-01T00:14:08.059844332Z 2023-12-31T16:14:08-08:00 INF devserver > autodiscovering locally hosted SDKs 
2024-01-01T00:14:08.063313114Z 2023-12-31T16:14:08-08:00 INF devserver > service starting 
2024-01-01T00:14:08.063537606Z 2023-12-31T16:14:08-08:00 INF api > starting server | addr=0.0.0.0:8288
2024-01-01T00:14:08.063726627Z 2023-12-31T16:14:08-08:00 INF executor > service starting 
2024-01-01T00:14:08.063806188Z 2023-12-31T16:14:08-08:00 INF executor > subscribing to function queue 
2024-01-01T00:14:08.386400080Z Storage folder for vector-cache created.
2024-01-01T00:14:08.387288698Z [TELEMETRY DISABLED] Telemetry is marked as disabled - no events will send. Telemetry helps Mintplex Labs Inc improve VectorAdmin.
2024-01-01T00:14:08.414470663Z prisma:info Starting a postgresql pool with 9 connections.
2024-01-01T00:14:08.720617237Z prisma:query SELECT COUNT(*) FROM (SELECT "public"."users"."id" FROM "public"."users" WHERE "public"."users"."role" = $1 OFFSET $2) AS "sub"
2024-01-01T00:14:08.720788478Z prisma:query SELECT "public"."users"."id", "public"."users"."email", "public"."users"."password", "public"."users"."role", "public"."users"."createdAt", "public"."users"."lastUpdatedAt" FROM "public"."users" WHERE ("public"."users"."email" = $1 AND "public"."users"."role" = $2) LIMIT $3 OFFSET $4
2024-01-01T00:14:08.797828401Z Example app listening on port 3001
2024-01-01T00:14:08.803516322Z prisma:query SELECT "public"."system_settings"."id", "public"."system_settings"."label", "public"."system_settings"."value", "public"."system_settings"."createdAt", "public"."system_settings"."lastUpdatedAt" FROM "public"."system_settings" WHERE "public"."system_settings"."label" = $1 LIMIT $2 OFFSET $3
2024-01-01T00:14:08.820855458Z prisma:query UPDATE "public"."system_settings" SET "label" = $1, "value" = $2 WHERE ("public"."system_settings"."id" = $3 AND 1=1) RETURNING "public"."system_settings"."id", "public"."system_settings"."label", "public"."system_settings"."value", "public"."system_settings"."createdAt", "public"."system_settings"."lastUpdatedAt"
2024-01-01T00:14:08.828308145Z prisma:query SELECT "public"."system_settings"."id", "public"."system_settings"."label", "public"."system_settings"."value", "public"."system_settings"."createdAt", "public"."system_settings"."lastUpdatedAt" FROM "public"."system_settings" WHERE "public"."system_settings"."label" = $1 LIMIT $2 OFFSET $3
2024-01-01T00:14:08.858549358Z prisma:query UPDATE "public"."system_settings" SET "label" = $1, "value" = $2 WHERE ("public"."system_settings"."id" = $3 AND 1=1) RETURNING "public"."system_settings"."id", "public"."system_settings"."label", "public"."system_settings"."value", "public"."system_settings"."createdAt", "public"."system_settings"."lastUpdatedAt"
2024-01-01T00:14:09.511826204Z Warning: connect.session() MemoryStore is not
2024-01-01T00:14:09.512325949Z designed for a production environment, as it will leak
2024-01-01T00:14:09.512431810Z memory, and will not scale past a single process.
2024-01-01T00:14:09.957219191Z setupFunctions success! 200
2024-01-01T00:14:09.957536134Z Background workers listening on port 3355
2024-01-01T00:14:09.957747966Z [Developer Notice] Run npx inngest-cli@latest dev -u http://127.0.0.1:3355/background-workers to debug events for workers or visit http://127.0.0.1:3355/background-workers

@mascreativelabs commented on GitHub (Dec 31, 2023): I get the same issue after changing the port to `3001:3001` Here's the log for `vector-admin` container after the boot: ``` 2024-01-01T00:14:03.872288061Z Environment variables loaded from .env 2024-01-01T00:14:03.873460511Z Prisma schema loaded from prisma/schema.prisma 2024-01-01T00:14:03.882096499Z Datasource "db": PostgreSQL database "vdbms", schema "public" at "vectoradmin-db:5432" 2024-01-01T00:14:04.072120309Z 2024-01-01T00:14:04.072267100Z 4 migrations found in prisma/migrations 2024-01-01T00:14:04.072349031Z 2024-01-01T00:14:04.216328096Z 2024-01-01T00:14:04.216453807Z No pending migrations to apply. 2024-01-01T00:14:04.257778079Z npm notice 2024-01-01T00:14:04.258223773Z npm notice New patch version of npm available! 10.2.3 -> 10.2.5 2024-01-01T00:14:04.258454945Z npm notice Changelog: <https://github.com/npm/cli/releases/tag/v10.2.5> 2024-01-01T00:14:04.258947379Z npm notice Run `npm install -g npm@10.2.5` to update! 2024-01-01T00:14:04.259206372Z npm notice 2024-01-01T00:14:05.882839738Z Environment variables loaded from .env 2024-01-01T00:14:05.883903297Z Prisma schema loaded from prisma/schema.prisma 2024-01-01T00:14:06.923357768Z 2024-01-01T00:14:06.923838333Z ✔ Generated Prisma Client (v5.3.1) to ./node_modules/@prisma/client in 380ms 2024-01-01T00:14:06.923935284Z 2024-01-01T00:14:06.923973464Z Start using Prisma Client in Node.js (See: https://pris.ly/d/client) 2024-01-01T00:14:06.924027164Z ``` 2024-01-01T00:14:06.924075925Z import { PrismaClient } from '@prisma/client' 2024-01-01T00:14:06.924131665Z const prisma = new PrismaClient() 2024-01-01T00:14:06.924181456Z ``` 2024-01-01T00:14:06.924225026Z or start using Prisma Client at the edge (See: https://pris.ly/d/accelerate) 2024-01-01T00:14:06.924281937Z ``` 2024-01-01T00:14:06.924323717Z import { PrismaClient } from '@prisma/client/edge' 2024-01-01T00:14:06.924356367Z const prisma = new PrismaClient() 2024-01-01T00:14:06.924399148Z ``` 2024-01-01T00:14:06.924443268Z 2024-01-01T00:14:06.924482269Z See other ways of importing Prisma Client: http://pris.ly/d/importing-client 2024-01-01T00:14:06.924554869Z 2024-01-01T00:14:06.962704212Z ┌─────────────────────────────────────────────────────────┐ 2024-01-01T00:14:06.962861654Z │ Update available 5.3.1 -> 5.7.1 │ 2024-01-01T00:14:06.962937834Z │ Run the following to update │ 2024-01-01T00:14:06.963002935Z │ npm i --save-dev prisma@latest │ 2024-01-01T00:14:06.963065816Z │ npm i @prisma/client@latest │ 2024-01-01T00:14:06.963128096Z └─────────────────────────────────────────────────────────┘ 2024-01-01T00:14:07.505098122Z yarn run v1.22.19 2024-01-01T00:14:07.570884484Z $ /app/workers/node_modules/.bin/inngest-cli dev -u http://0.0.0.0:3355/background-workers 2024-01-01T00:14:07.649376050Z [2023-12-31 16:14:07 -0800] [106] [INFO] Starting gunicorn 20.1.0 2024-01-01T00:14:07.655372934Z [2023-12-31 16:14:07 -0800] [106] [INFO] Listening at: http://0.0.0.0:8888 (106) 2024-01-01T00:14:07.655585596Z [2023-12-31 16:14:07 -0800] [106] [INFO] Using worker: sync 2024-01-01T00:14:07.709884914Z [2023-12-31 16:14:07 -0800] [157] [INFO] Booting worker with pid: 157 2024-01-01T00:14:07.793942250Z [2023-12-31 16:14:07 -0800] [158] [INFO] Booting worker with pid: 158 2024-01-01T00:14:07.839947094Z [2023-12-31 16:14:07 -0800] [160] [INFO] Booting worker with pid: 160 2024-01-01T00:14:07.899226477Z [2023-12-31 16:14:07 -0800] [166] [INFO] Booting worker with pid: 166 2024-01-01T00:14:07.948010376Z setupFunctions failed fetch failed 2024-01-01T00:14:08.057188618Z 2023-12-31T16:14:08-08:00 INF runner > starting event stream | backend=redis 2024-01-01T00:14:08.057343510Z 2023-12-31T16:14:08-08:00 INF runner > service starting 2024-01-01T00:14:08.057625952Z 2023-12-31T16:14:08-08:00 INF runner > subscribing to events | topic=events 2024-01-01T00:14:08.059844332Z 2023-12-31T16:14:08-08:00 INF devserver > autodiscovering locally hosted SDKs 2024-01-01T00:14:08.063313114Z 2023-12-31T16:14:08-08:00 INF devserver > service starting 2024-01-01T00:14:08.063537606Z 2023-12-31T16:14:08-08:00 INF api > starting server | addr=0.0.0.0:8288 2024-01-01T00:14:08.063726627Z 2023-12-31T16:14:08-08:00 INF executor > service starting 2024-01-01T00:14:08.063806188Z 2023-12-31T16:14:08-08:00 INF executor > subscribing to function queue 2024-01-01T00:14:08.386400080Z Storage folder for vector-cache created. 2024-01-01T00:14:08.387288698Z [TELEMETRY DISABLED] Telemetry is marked as disabled - no events will send. Telemetry helps Mintplex Labs Inc improve VectorAdmin. 2024-01-01T00:14:08.414470663Z prisma:info Starting a postgresql pool with 9 connections. 2024-01-01T00:14:08.720617237Z prisma:query SELECT COUNT(*) FROM (SELECT "public"."users"."id" FROM "public"."users" WHERE "public"."users"."role" = $1 OFFSET $2) AS "sub" 2024-01-01T00:14:08.720788478Z prisma:query SELECT "public"."users"."id", "public"."users"."email", "public"."users"."password", "public"."users"."role", "public"."users"."createdAt", "public"."users"."lastUpdatedAt" FROM "public"."users" WHERE ("public"."users"."email" = $1 AND "public"."users"."role" = $2) LIMIT $3 OFFSET $4 2024-01-01T00:14:08.797828401Z Example app listening on port 3001 2024-01-01T00:14:08.803516322Z prisma:query SELECT "public"."system_settings"."id", "public"."system_settings"."label", "public"."system_settings"."value", "public"."system_settings"."createdAt", "public"."system_settings"."lastUpdatedAt" FROM "public"."system_settings" WHERE "public"."system_settings"."label" = $1 LIMIT $2 OFFSET $3 2024-01-01T00:14:08.820855458Z prisma:query UPDATE "public"."system_settings" SET "label" = $1, "value" = $2 WHERE ("public"."system_settings"."id" = $3 AND 1=1) RETURNING "public"."system_settings"."id", "public"."system_settings"."label", "public"."system_settings"."value", "public"."system_settings"."createdAt", "public"."system_settings"."lastUpdatedAt" 2024-01-01T00:14:08.828308145Z prisma:query SELECT "public"."system_settings"."id", "public"."system_settings"."label", "public"."system_settings"."value", "public"."system_settings"."createdAt", "public"."system_settings"."lastUpdatedAt" FROM "public"."system_settings" WHERE "public"."system_settings"."label" = $1 LIMIT $2 OFFSET $3 2024-01-01T00:14:08.858549358Z prisma:query UPDATE "public"."system_settings" SET "label" = $1, "value" = $2 WHERE ("public"."system_settings"."id" = $3 AND 1=1) RETURNING "public"."system_settings"."id", "public"."system_settings"."label", "public"."system_settings"."value", "public"."system_settings"."createdAt", "public"."system_settings"."lastUpdatedAt" 2024-01-01T00:14:09.511826204Z Warning: connect.session() MemoryStore is not 2024-01-01T00:14:09.512325949Z designed for a production environment, as it will leak 2024-01-01T00:14:09.512431810Z memory, and will not scale past a single process. 2024-01-01T00:14:09.957219191Z setupFunctions success! 200 2024-01-01T00:14:09.957536134Z Background workers listening on port 3355 2024-01-01T00:14:09.957747966Z [Developer Notice] Run npx inngest-cli@latest dev -u http://127.0.0.1:3355/background-workers to debug events for workers or visit http://127.0.0.1:3355/background-workers ```

yindo commented

@mascreativelabs commented on GitHub (Dec 31, 2023):

here's logs from vectoradmin-db (postgresql database) container:

chmod: changing permissions of '/var/run/postgresql': Operation not permitted
PostgreSQL Database directory appears to contain a database; Skipping initialization
2023-12-31 16:35:57.647 PST [1] LOG:  starting PostgreSQL 16.1 (Debian 16.1-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2023-12-31 16:35:57.648 PST [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2023-12-31 16:35:57.648 PST [1] LOG:  listening on IPv6 address "::", port 5432
2023-12-31 16:35:57.671 PST [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-12-31 16:35:57.780 PST [16] LOG:  database system was shut down at 2023-12-31 16:35:51 PST
2023-12-31 16:35:57.830 PST [1] LOG:  database system is ready to accept connections

@mascreativelabs commented on GitHub (Dec 31, 2023): here's logs from vectoradmin-db (postgresql database) container: ``` chmod: changing permissions of '/var/run/postgresql': Operation not permitted PostgreSQL Database directory appears to contain a database; Skipping initialization 2023-12-31 16:35:57.647 PST [1] LOG: starting PostgreSQL 16.1 (Debian 16.1-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit 2023-12-31 16:35:57.648 PST [1] LOG: listening on IPv4 address "0.0.0.0", port 5432 2023-12-31 16:35:57.648 PST [1] LOG: listening on IPv6 address "::", port 5432 2023-12-31 16:35:57.671 PST [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2023-12-31 16:35:57.780 PST [16] LOG: database system was shut down at 2023-12-31 16:35:51 PST 2023-12-31 16:35:57.830 PST [1] LOG: database system is ready to accept connections ```

yindo commented

@mascreativelabs commented on GitHub (Jan 1, 2024):

@mascreativelabs commented on GitHub (Jan 1, 2024): ![CleanShot 2023-12-31 at 23 06 18@2x](https://github.com/Mintplex-Labs/vector-admin/assets/147929843/5691d365-1e39-4b3b-8c50-f5059c285ab6)

yindo commented

@timothycarambat commented on GitHub (Jan 1, 2024):

so the Err_CONNECTION_REFUSED is meaning that the backend does not appear to be reachable by the frontend. If you visit http://127.0.0.1:3001/api/ping do you get a 200? You should be able to run the container on any host port, I am just trying to remove as many variables as possible for conflict

@timothycarambat commented on GitHub (Jan 1, 2024): so the `Err_CONNECTION_REFUSED` is meaning that the backend does not appear to be reachable by the frontend. If you visit `http://127.0.0.1:3001/api/ping` do you get a 200? You should be able to run the container on any host port, I am just trying to remove as many variables as possible for conflict

yindo commented

@JairajGaur commented on GitHub (Jan 2, 2024):

I was also facing the same issue few days back however it got resolved by multiple cleanup of docker images and also we need wait for all BE services up and running. I don't think "Running" status on the docker container means all the service are reachable. I tried to trace the logs but no luck.

@JairajGaur commented on GitHub (Jan 2, 2024): I was also facing the same issue few days back however it got resolved by multiple cleanup of docker images and also we need wait for all BE services up and running. I don't think "Running" status on the docker container means all the service are reachable. I tried to trace the logs but no luck.

yindo commented

@mascreativelabs commented on GitHub (Jan 2, 2024):

I was also facing the same issue few days back however it got resolved by multiple cleanup of docker images and also we need wait for all BE services up and running. I don't think "Running" status on the docker container means all the service are reachable. I tried to trace the logs but no luck.

hey @JairajGaur what do you mean by "multiple cleanup of docker images"?

@mascreativelabs commented on GitHub (Jan 2, 2024): > I was also facing the same issue few days back however it got resolved by multiple cleanup of docker images and also we need wait for all BE services up and running. I don't think "Running" status on the docker container means all the service are reachable. I tried to trace the logs but no luck. hey @JairajGaur what do you mean by "multiple cleanup of docker images"?

yindo commented

@mascreativelabs commented on GitHub (Jan 2, 2024):

so the Err_CONNECTION_REFUSED is meaning that the backend does not appear to be reachable by the frontend. If you visit http://127.0.0.1:3001/api/ping do you get a 200? You should be able to run the container on any host port, I am just trying to remove as many variables as possible for conflict

@timothycarambat thanks for your response, and happy new year!
when you say visiting http://127.0.0.1:3001/api/ping for that test, should I be on the docker container when trying to reach the address? because so far I'm trying via another machine on the same network

@mascreativelabs commented on GitHub (Jan 2, 2024): > so the `Err_CONNECTION_REFUSED` is meaning that the backend does not appear to be reachable by the frontend. If you visit `http://127.0.0.1:3001/api/ping` do you get a 200? You should be able to run the container on any host port, I am just trying to remove as many variables as possible for conflict @timothycarambat thanks for your response, and happy new year! when you say visiting `http://127.0.0.1:3001/api/ping` for that test, should I be on the docker container when trying to reach the address? because so far I'm trying via another machine on the same network

yindo commented

@timothycarambat commented on GitHub (Jan 3, 2024):

However you would normally use the interface, so in this case http://<machine.ip>:3001/api/ping.

When you shared the screenshot of the frontend sending a request to http://127.0.0.1:3001/api/login were you on another machine totally? Because then it would make sense that http://127.0.0.1:3001 did not work, since the machine you were on is not running VectorAdmin! That would be a critical detail to know. I made the assumption you were running VectorAdmin on the same machine you would access it on.

@timothycarambat commented on GitHub (Jan 3, 2024): However you would normally use the interface, so in this case `http://<machine.ip>:3001/api/ping`. When you shared the screenshot of the frontend sending a request to `http://127.0.0.1:3001/api/login` were you on another machine totally? Because then it would make sense that http://127.0.0.1:3001 did not work, since the machine you were on is not running VectorAdmin! That would be a critical detail to know. I made the assumption you were running VectorAdmin on the same machine you would access it on.

yindo commented

@felixstander commented on GitHub (Jan 7, 2024):

@timothycarambat I'm also facing the same problem. The server is up on a remote machine through the docker image, and i'm able to get back "OK" info after sending a request to http://<machine.ip>:3001/api/ping on my local machine.
I check Network tab in the browser inspector window when attempting to login, and the error is the same as @MAS-CreativeLabs provides.

@felixstander commented on GitHub (Jan 7, 2024): @timothycarambat I'm also facing the same problem. The server is up on a remote machine through the docker image, and i'm able to get back "OK" info after sending a request to **http://<machine.ip>:3001/api/ping** on my local machine. I check Network tab in the browser inspector window when attempting to login, and the error is the same as @MAS-CreativeLabs provides. > ![CleanShot 2023-12-31 at 23 06 18@2x](https://private-user-images.githubusercontent.com/147929843/293572855-5691d365-1e39-4b3b-8c50-f5059c285ab6.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MDQ2ODM5NzMsIm5iZiI6MTcwNDY4MzY3MywicGF0aCI6Ii8xNDc5Mjk4NDMvMjkzNTcyODU1LTU2OTFkMzY1LTFlMzktNGIzYi04YzUwLWY1MDU5YzI4NWFiNi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwMTA4JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDEwOFQwMzE0MzNaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT00ZDk0ZjdkOTMzMzVmMTQ3NTFjOTQ3MTM0YmQyMWI0MzRlNjVlMTQ0MmEzNGFjNWZiMjc0MDM2YjdhMWQwNmY4JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.iVLuPF6dSqAK7xcqLp0lT434voBMPhxu_OOOuI7EmAs)

yindo commented

https://github.com/Mintplex-Labs/vector-admin/blob/e7659c94476cb3329cb3ade9f5a49cc9915d99d3/frontend/src/utils/constants.ts#L2

@timothycarambat commented on GitHub (Jan 8, 2024):

Will mark this as a bug for now, but I think the issue is that the docker image is running on a localmachine and the VITE_API_BASE is assuming localhost where is could be changed to be relative so the root URL can be assumed from the client side, enabling docker image on remote IPs

@timothycarambat commented on GitHub (Jan 8, 2024): Will mark this as a bug for now, but I think the issue is that the docker image is running on a localmachine and the `VITE_API_BASE` is assuming localhost where is could be changed to be relative so the root URL can be assumed from the client side, enabling docker image on remote IPs https://github.com/Mintplex-Labs/vector-admin/blob/e7659c94476cb3329cb3ade9f5a49cc9915d99d3/frontend/src/utils/constants.ts#L2

yindo commented

@felixstander commented on GitHub (Jan 9, 2024):

@timothycarambat thanks for the reply, how can I change the VITE_API_BASE from the pre-built image?

@felixstander commented on GitHub (Jan 9, 2024): @timothycarambat thanks for the reply, how can I change the VITE_API_BASE from the pre-built image?

yindo commented

@felixstander commented on GitHub (Jan 9, 2024):

@timothycarambat you are right. I'm able to log in after changing the VITE_API_BASE when building the docker image myself.

@felixstander commented on GitHub (Jan 9, 2024): @timothycarambat you are right. I'm able to log in after changing the VITE_API_BASE when building the docker image myself.

yindo commented

@mascreativelabs commented on GitHub (Jan 9, 2024):

@timothycarambat can we get to a solution that does not involve rebuilding the image each time you update your code? I don't want to fork the repo or rebuild an image just for an IP address. Can you set the address to the hostname of the DB?

@mascreativelabs commented on GitHub (Jan 9, 2024): @timothycarambat can we get to a solution that does not involve rebuilding the image each time you update your code? I don't want to fork the repo or rebuild an image just for an IP address. Can you set the address to the hostname of the DB?

yindo commented

@mascreativelabs commented on GitHub (Jan 9, 2024):

Or maybe make it an environmental variable that we could set via the docker-compose.yml or .env

@mascreativelabs commented on GitHub (Jan 9, 2024): Or maybe make it an environmental variable that we could set via the `docker-compose.yml` or `.env`

yindo commented

@mascreativelabs commented on GitHub (Jan 9, 2024):

@timothycarambat you are right. I'm able to log in after changing the VITE_API_BASE when building the docker image myself.

@felixstander how did you change the VITE_API_BASE from the pre-built image?

@mascreativelabs commented on GitHub (Jan 9, 2024): > @timothycarambat you are right. I'm able to log in after changing the VITE_API_BASE when building the docker image myself. @felixstander how did you change the `VITE_API_BASE` from the pre-built image?

yindo commented

@felixstander commented on GitHub (Jan 9, 2024):

@MAS-CreativeLabs have no idea, I clone the repo and build the image myself, and change the VITE_API_BAE variable in .env.production file in the frontend folder before building.

@felixstander commented on GitHub (Jan 9, 2024): @MAS-CreativeLabs have no idea, I clone the repo and build the image myself, and change the VITE_API_BAE variable in .env.production file in the frontend folder before building.

yindo commented

@mascreativelabs commented on GitHub (Jan 9, 2024):

@MAS-CreativeLabs have no idea, I clone the repo and build the image myself, and change the VITE_API_BAE variable in .env.production file in the frontend folder before building.

@felixstander In the frontend folder I only have .env.example containing the following lines:

VITE_APP_NAME="VectorAdmin"
# VITE_API_BASE='/api' # Use this URL deploying on non-localhost address.

is this the file you're referring to? what did you put in the file?
How long did it take to rebuild?
I'm also curious about your thoughts about the workflow do you think it's a viable solution?
I find this workflow to be odd, having to rebuild an image after each commit is hard to maintain in a testing environment much less for production

I think just having a variable in the .env with the prebuilt image would help users tremendously

@mascreativelabs commented on GitHub (Jan 9, 2024): > @MAS-CreativeLabs have no idea, I clone the repo and build the image myself, and change the VITE_API_BAE variable in .env.production file in the frontend folder before building. @felixstander In the frontend folder I only have `.env.example` containing the following lines: ``` VITE_APP_NAME="VectorAdmin" # VITE_API_BASE='/api' # Use this URL deploying on non-localhost address. ``` is this the file you're referring to? what did you put in the file? How long did it take to rebuild? I'm also curious about your thoughts about the workflow do you think it's a viable solution? I find this workflow to be odd, having to rebuild an image after each commit is hard to maintain in a testing environment much less for production I think just having a variable in the .env with the prebuilt image would help users tremendously

yindo commented

https://github.com/Mintplex-Labs/vector-admin/actions/runs/7470209197/job/20328530326

@timothycarambat commented on GitHub (Jan 9, 2024):

Just updated the image and build, and the VITE_API_BASE to now be relative. When the build is complete and is published you should be able to pull in the new image and it should function on local and remote IPs as the VITE_API_BASE will be relative.

@timothycarambat commented on GitHub (Jan 9, 2024): Just updated the image and build, and the VITE_API_BASE to now be relative. When the build is complete and is published you should be able to pull in the new image and it should function on local and remote IPs as the VITE_API_BASE will be relative. https://github.com/Mintplex-Labs/vector-admin/actions/runs/7470209197/job/20328530326

yindo commented

@mascreativelabs commented on GitHub (Jan 11, 2024):

@timothycarambat Thank you it worked! ✅

@mascreativelabs commented on GitHub (Jan 11, 2024): @timothycarambat Thank you it worked! ✅

yindo commented

@mascreativelabs commented on GitHub (Jan 11, 2024):

Now the new issue is the following:
I'm getting fetch Failed
The URL my chroma instance is reachable at is http://10.255.255.254:5959

I try the following:
http://10.255.255.254:5959 ❌
http://10.255.255.254:5959/api/v1 ❌
http://10.255.255.254:5959/api/v1/ ❌

Idon't think it my chromadb install that's at fault here because it works with flowise and anything-llm.

http://10.255.255.254:5959/api/v1/heartbeat returns the following:

{"nanosecond heartbeat":1705027265899832507}

http://10.255.255.254:5959/api/v1/collections returns the following:

[{"name":"valhala","id":"828f1797-6636-4a76-878f-a0c24936d1cd","metadata":{"hnsw:space":"cosine"},"tenant":"default_tenant","database":"default_database"},{"name":"flowise","id":"97abe11a-760e-4ce1-8b1a-9b3004fd114c","metadata":null,"tenant":"default_tenant","database":"default_database"}]

@mascreativelabs commented on GitHub (Jan 11, 2024): Now the new issue is the following: I'm getting `fetch Failed` The URL my chroma instance is reachable at is `http://10.255.255.254:5959` I try the following: `http://10.255.255.254:5959` ❌ `http://10.255.255.254:5959/api/v1` ❌ `http://10.255.255.254:5959/api/v1/` ❌ ![CleanShot 2024-01-11 at 18 28 35@2x](https://github.com/Mintplex-Labs/vector-admin/assets/147929843/25774076-9ecc-4039-8e99-d10dfd9e58b5) Idon't think it my chromadb install that's at fault here because it works with flowise and anything-llm. - [ ] `http://10.255.255.254:5959/api/v1/heartbeat` returns the following: ``` {"nanosecond heartbeat":1705027265899832507} ``` - [ ] `http://10.255.255.254:5959/api/v1/collections` returns the following: ``` [{"name":"valhala","id":"828f1797-6636-4a76-878f-a0c24936d1cd","metadata":{"hnsw:space":"cosine"},"tenant":"default_tenant","database":"default_database"},{"name":"flowise","id":"97abe11a-760e-4ce1-8b1a-9b3004fd114c","metadata":null,"tenant":"default_tenant","database":"default_database"}] ```

yindo commented