Why I did drop the new Outlook after using it 6 months

Microsoft is currently pushing users to "beta" test the new Outlook in the same way as the new Teams client.

The new Teams desktop client for Windows is a big step forward, means you can finally be active in different tenants. Previously you had to always switch tenant to receive notifications from other tenants.

Now the new Temas client allows you to receive notifications from all tenants which you are logged in. Hurrah, MS did finaly understand how modern working is, you are often not only in one company, but you have different teams and client connections. (Of course all major competitors like slack did have this feature from the start, many many years ago)

So now the new Outlook client suggests that you will also receive better user experience compared to the "old" one.

Before switching to the new desktop client you have to know of a few (breaking) changes

1. You old addins won't work any longer, you have to look if a web version of these addins exist and install (and perhaps purchase) these. If they don't exist, your out of luck. But on the plus side, if such a plugin exists, you will also have it available in the web frontend

2. You will finaly be abke to drop the old pst files, together with all the problems comming along with them. On the backside, the search (or better the find) capability in outlook across accounts is not existent. Also moving emails/calendar entries between accounts isn't fun with the new interface and you can't automate these any longer

 If you can live with these, then you can consider using the new client, but stop, there are two more things, which microsoft did not tell us initially:

1. All acount data of other smtp/imap/pop3 accounts, together with all the emails etc. are sent to the microsoft servers. And yes, it's not a bug, it's a feature, to allow "better user experience" across systems. And there is no way to opt out of this account stealing, togerther with all your emails from foreign accounts

2. You can't use the new outlook desktop client to access exchange mailboxes, which have only a exchange online 1 or 2 license. If you wish to use it, then you have to upgrade the exchange online 1 or 2 license to a Microsoft365 licence which includes the desktop apps. So instead of paying 3.60 CHF/Month per mailbox (Arround 4$) you have to pay microsoft 11.20 CHF/Month for the Business Standard plan.

The last point is especially stange, but microsoft has confirmed this behaviour as the expected way of working (Read get more revenues). When you had added exchange online mailboxes to the "old" Outlook, then the automatic migration to the new outlook takes them over with no hick up and they work wonderfully in the new Outlook. Be beware, if you remove them, there is no way to re add them back, MS does a license check and denies you this.

Currently I have two employments with fully licensed Microsoft E3 enterprise tenants, and also 3 more tenants where I have full Microsoft education licenses. And even with these 5 Office 365 licenses together, I'm not allowed to open a simple Exchange Online mailbox...

If you continue down this road, then microsoft might publish new Excel and Word versions, which won't allow you to open/edit documents, if they are not stored on some kind of licences microsoft storage, just plain silly.

 So I started using BlueMail as my mail client for the Exchange stuff and the good old Thuderbird for all non-microsoft mailboxes.

 

Selfhosting supabase in k8s with helm and keycloak sso

Supabase is a free open source Firebase alternative.

The company behing the product is offering a SaaS solution and also the source code to host it yourself.

For development purposes, the selfhosting is done via docker compose.

When running it in production, in a kubernetes cluster, you can use the helm charts for this.

There are currently two helm charts available for this.

https://github.com/supabase-community/supabase-kubernetes from the community and https://bitnami.com/stack/supabase/helm from bitnami.

We did try both, but only got the bitnami version running.

The problem with self hosting supabase is, that you won't get any support from the company and the community seems to be small for self hosting.

So you are basically on your own when running it in production on your infrastructure.

The problem we faced with the supabase-cummunity helm chart was, that user registration via UI was not possible, apparently a known problem.

We did then try out the bitnami helm chart and got it working, with extensive googling and trying out.

The advantage of the bitnami package is, that it works similar to other bitnami packages, so you can reuse your knowledge in that area.

The final struggle we had, is to enable sso via keycloak, so we could reuse or single point of authentifaction for this.

For the whole helm chart (as of version 0.23.11) to work correctly, you have to define these things:

1. The URL of your application, let's say it's https://ai-frontend.company.com

2. The supabase URL of the supabase api, let's say it's https://supabase-api.company.com

3. The sso URL of your keycloak server, let's say it's https://sso.company.com

What we don't have at the moment, is exposing the studio url, since this needs additional authentification protection, which we did not yet get working, but that url could then be

4. https://supabase.company.com

When using the current 0.23.11 helm chart, you will receive auth errors, see  https://github.com/bitnami/charts/issues/16988

To prevent these, you can use the v2.91.0 version of the docker image

auth:
  image:
    registry: docker.io
    #
    # From https://github.com/bitnami/charts/issues/16988
    #
    repository: supabase/gotrue
    tag: v2.91.0

The final helm values are then something like this:

publicURL: "https://supabase-api.company.com"

auth:
  defaultConfig: |
    GOTRUE_API_HOST: "0.0.0.0"
    GOTRUE_API_PORT: {{ .Values.auth.containerPorts.http | quote }}
    GOTRUE_SITE_URL: "https://ai-frontend.company.com"
    GOTRUE_URI_ALLOW_LIST: "*"
    GOTRUE_DISABLE_SIGNUP: "false"
    GOTRUE_DB_DRIVER: "postgres"
    GOTRUE_JWT_DEFAULT_GROUP_NAME: "authenticated"
    GOTRUE_JWT_ADMIN_ROLES: "service_role"
    GOTRUE_JWT_AUD: "authenticated"
    GOTRUE_JWT_EXP: "3600"
    GOTRUE_EXTERNAL_EMAIL_ENABLED: "true"
    GOTRUE_MAILER_AUTOCONFIRM: "true"
    GOTRUE_SMTP_ADMIN_EMAIL: "no-reply@company.com"
    GOTRUE_SMTP_HOST: "inbucket.default.svc.cluster.local"
    GOTRUE_SMTP_PORT: "2500"
    GOTRUE_SMTP_SENDER_NAME: "noreply@company.com"
    GOTRUE_EXTERNAL_PHONE_ENABLED: "false"
    GOTRUE_SMS_AUTOCONFIRM: "false"
    GOTRUE_MAILER_URLPATHS_INVITE: "https://supabase-api.company.com/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_CONFIRMATION: "https://supabase-api.company.com/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_RECOVERY: "https://supabase-api.company.com/auth/v1/verify"
    GOTRUE_MAILER_URLPATHS_EMAIL_CHANGE: "https://supabase-api.company.com/auth/v1/verify"
    GOTRUE_EXTERNAL_KEYCLOAK_ENABLED: "true"
    GOTRUE_EXTERNAL_KEYCLOAK_CLIENT_ID: "Supabase_Client_ID"
    GOTRUE_EXTERNAL_KEYCLOAK_SECRET: "supabase-sso-client-secret"
    GOTRUE_EXTERNAL_KEYCLOAK_REDIRECT_URI: "https://supabase-api.company.com/auth/v1/callback"
    GOTRUE_EXTERNAL_KEYCLOAK_URL: "https://sso.company.com/auth/realms/MYREALM"

These are the paramters required to get it up and running, and login via email should work now.

Unfortunally sso login will not yet work, does to some errro 502 gateway errors and no vmRoute found errors.

So the normal  app url works, it the redirects you to the auth endpoint of supabase, which the redirects to your keycloak server. Once this one has sucessfully authenticated, it returns you to the supabase-api to authenticated the backend and then it should redirect you back to the original frontend.

This did require some additional hours of investigation, resulting in the case, that the http headers used after keycloak authentication are to big for the default kong and our nginx ingress controller.

The nasty part of finding this was, that KONG does log the access and errors in a logfile inside the pod, and does not expose then to stdout/stderr.

https://github.com/bitnami/charts/issues/22755

The solution for the header size problem was, to tell kong about the larger headers via kong config.

kong:
   kong:
    extraEnvVars:
      - name: KONG_NGINX_PROXY_LARGE_CLIENT_HEADER_BUFFERS
        value: "64 128K"
      - name: KONG_NGINX_PROXY_PROXY_BUFFER_SIZE
        value: "128k"
      - name: KONG_NGINX_PROXY_PROXY_BUFFERS
        value: "64 128k"

This did solve the kong 502 gateway error, but still our main ingress controller did struggle with the large header and returning also a 502 gateway error. In your nginx ingress you will see these errors: upstream sent too big header while reading response header from upstream.

So we had to also increase these values on teh main ngin ingress controller

kong:
  ingress:
    enabled: true
    hostname: "supabase-api.company.com"
    tls: true
    annotations:
      kubernetes.io/ingress.class: nginx
      cert-manager.io/cluster-issuer: letsencrypt-issuer
      acme.cert-manager.io/http01-edit-in-place: "true"
      nginx.org/proxy-connect-timeout: "600s"
      nginx.org/proxy-send-timeout: "600s"
      nginx.org/proxy-read-timeout: "600s"
      nginx.org/client-max-body-size: "20m"
      nginx.org/proxy-buffer-size: "256k"
      nginx.org/proxy-buffers: "64 512k"
      nginx.org/large-client-header-buffers: "64 128k"
      nginx.org/proxy-busy-buffers-size: "512k"
      # Required for keycloak sso, since the header get big
      # https://www.cyberciti.biz/faq/nginx-upstream-sent-too-big-header-while-reading-response-header-from-upstream/

This then finally allowed to use the keycloak sso capabality of supabase.

Don't hesitate to comment/ask here, if you need more information about the k8s setup via helm.