Stuck in login loop when using multiple replicas

[schulmar]

I was banging my head against this for days and accidentally noticed that having two replicas got me stuck in a login loop where I'd just get redirected to the login mask after entering the correct passphrase.

This is my values.yaml with following notable changes:

1. postgresql instead of mariadb
2. redis disabled (had problems with sentinel?) -> maybe this caused split brain between the replicas?
3. integration tests disabled, they gave me some headaches too
4. latest docker image

   app:
   cache:
   redis:
     enabled: false
     sentinelProxy:
       enabled: false
       image:
         registry: ""
         repository: haproxy
         tag: latest
       resources: {}
   database:
   kind: postgresql
   databaseInitContainer:
   enabled: true
   image:
   tag: 4.8.0-1-ce
   resources: {}
   tls:
   autogenerate: true
   mariadbDependencyEnabled: false
   postgresqlDependencyEnabled: true
   postgresql:
   auth:
   # -- Configure postgresql auth username
   username: passbolt
   # -- Configure postgresql auth password
   password: <postgres-password>
   # -- Configure postgresql auth database
   database: passbolt
   ingress:
   annotations: 
   cert-manager.io/cluster-issuer: letsencrypt-staging
   traefik.ingress.kubernetes.io/router.middlewares: passwordstore-path-prefix@kubernetescrd,passwordstore-cors@kubernetescrd,passwordstore-ssl-redirect@kubernetescrd
   enabled: true
   hosts:
   - host: <my domain>
   paths:
   - path: /
     pathType: ImplementationSpecific
     port: http
   tls:
   - autogenerate: true
   hosts:
   - <my domain>
   integrationTests:
   enabled: false
   gpgServerKeyPrivate:
   jwtPath: /etc/passbolt/jwt
   jwtServerPrivate: <the key>
   passboltEnv:
   plain:
   APP_FULL_BASE_URL: https://<my.domain>
   CACHE_CAKE_DEFAULT_SERVER: 127.0.0.1
   DEBUG: false
   EMAIL_DEFAULT_FROM: no-reply-passbolt@<my-domain>
   EMAIL_DEFAULT_FROM_NAME: Passbolt
   EMAIL_TRANSPORT_DEFAULT_HOST: <my domain>
   EMAIL_TRANSPORT_DEFAULT_PORT: 587
   EMAIL_TRANSPORT_DEFAULT_TIMEOUT: 30
   EMAIL_TRANSPORT_DEFAULT_TLS: true
   KUBECTL_DOWNLOAD_CMD: curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
   PASSBOLT_JWT_SERVER_KEY: /var/www/passbolt/config/jwt/jwt.key
   PASSBOLT_JWT_SERVER_PEM: /var/www/passbolt/config/jwt/jwt.pem
   PASSBOLT_KEY_EMAIL: passbolt@<my-domain>
   PASSBOLT_LEGAL_PRIVACYPOLICYURL: https://www.passbolt.com/privacy
   PASSBOLT_PLUGINS_JWT_AUTHENTICATION_ENABLED: true
   PASSBOLT_PLUGINS_LICENSE_LICENSE: /etc/passbolt/subscription_key.txt
   PASSBOLT_REGISTRATION_PUBLIC: false
   PASSBOLT_SELENIUM_ACTIVE: false
   PASSBOLT_SSL_FORCE: false
   secret:
   CACHE_CAKE_DEFAULT_PASSWORD: <probably not needed anymore>
   DATASOURCES_DEFAULT_DATABASE: passbolt
   DATASOURCES_DEFAULT_PASSWORD: <postgres-password>
   DATASOURCES_DEFAULT_USERNAME: passbolt
   EMAIL_TRANSPORT_DEFAULT_PASSWORD: <mail-password>
   EMAIL_TRANSPORT_DEFAULT_USERNAME: passbolt@<mydomain>
   PASSBOLT_GPG_SERVER_KEY_FINGERPRINT: <fingerprint>
   redisDependencyEnabled: false
   replicaCount: 2

[Tecnobutrul]

Hello @schulmar.

Passbolt needs an external cache service to handle sessions on multiple instances, so redis (or any other cache service supported by cake php) has to be present on this kind of deployments.

I am going to close this because this is not an issue. If you need further help don't hesitate to open a thread on community.passbolt.com.

[schulmar]

Thanks for your response, I already thought as much and just wanted to document it here. Maybe the helm chart could fail when no cache service is used in conjunction with more than one replica?

I am not sure why I disabled redis but I believe the startup failed when it was enabled.