Just a short collection of tricks working with Theia IDE.

Auto Format Files

Check that the ‘formatOnSave’ is set to ‘true’

"editor.formatOnSave": true

Flighty explorer

If you observe the problem that after starting Theia IDE your explorer is permanently refreshing if if you do not change any files and is always changing the scroll position automatically, than this can be missing exclusion of file types from the file file watcher. Just extend the list of unimportant files like my list below:

"files.watcherExclude": {
  "**/.git/objects/**": true,
  "**/.git/subtree-cache/**": true,
  "**/target/**": true,
  "**/node_modules/**": true,
  "**/build/**": true,
  "**/out/**": true,
  "**/bin/**": true,
  "**/.mvn/**": true
}

In this short tutorial I will explain how to deploy Forgejo into a Kubernetes Cluster. Forgejo is a self-hosted lightweight source code management solution based on Git. Forgejo is a good alternative to Github if you want to host your own Git Repository server.

Forgejo was founded in 2022 as a fork of the Gitea project. In the meantime it becomes a noteable an relevant Open Source alternative to Github. The project is community driven and maintained by the Codeberg e.v. If you have an open source project you can host your project directly on codeberg.org . For private repositories you can install your own instance of Forgejo.

There are several ways how you can install Forgejo. As it is provided as a Docker Image you can easily start the system with docker compose. See the official documentation.

Read more: How to Deploy Forgejo in Kubernetes

Kubernetes

If you have a Kubernets cluster it is easy to setup a production ready deployment of Forgejo. I assume that you are familiar with Kubernetes (see also my Kubernetes Setup Project Imixs-Cloud on Gihub ) and I assume you have some kind of storage solution and ingress solution already installed.

I split the deployment into two parts, each with a separate deyployment .yaml file

• Database – 010-postgresql.yaml
• Git Repo – 020-forgejo.yaml

The Database

For productive environments it is recommanded to replace the build in SQLLight database with MySQL or Postgres. For a kubernetes deployment this is the recommanded way.
In the following deployment example I deploy a postgreSQL database for forgejo

---
###################################################
# Deployment PostgreSQL
###################################################
apiVersion: apps/v1
kind: Deployment
metadata:
  name: forgejo-postgres
  namespace: my-git-repo
  labels: 
    app: forgejo-postgres

spec:
  replicas: 1
  selector: 
    matchLabels:
      app: forgejo-postgres
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: forgejo-postgres
    spec:
     
      containers:
      - env:
        - name: POSTGRES_DB
          value: forgejo
        - name: POSTGRES_USER
          value: forgejo
        - name: POSTGRES_PASSWORD
          value: xxxx

        image: postgres:16-alpine
        name: forgejo-postgres

        readinessProbe:
          exec:
            command: ["pg_isready", "-U", "forgejo"]
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          exec:
            command: ["pg_isready", "-U", "forgejo"]
          initialDelaySeconds: 15
          periodSeconds: 20

          
        ports:
          - containerPort: 5432        
        volumeMounts:
        - mountPath: /var/lib/postgresql/data
          name: forgejo-dbdata
          subPath: postgres
      restartPolicy: Always
      volumes:
      - name: forgejo-dbdata
        persistentVolumeClaim:
          claimName: forgejo-dbdata


---
###################################################
# Data Volume
###################################################
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: forgejo-dbdata
  namespace: my-git-repo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  volumeMode: Filesystem
  volumeName: "forgejo-dbdata"
  storageClassName: ""

---
kind: PersistentVolume
apiVersion: v1
metadata:
  name: forgejo-dbdata
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 10Gi
  csi:
    driver: rbd.csi.ceph.com
    fsType: ext4
    nodeStageSecretRef:
      name: csi-rbd-secret-ceph-abpua
      namespace: ceph-system
    volumeAttributes:
      "clusterID": "xxxxxxxxxxx"
      "pool": "kubernetes"
      "staticVolume": "true"
      "imageFeatures": "layering"
    volumeHandle: "forgejo-dbdata"
  persistentVolumeReclaimPolicy: Retain
  volumeMode: Filesystem


---
###################################################
# Network
###################################################
apiVersion: v1
kind: Service
metadata:
  name: forgejo-postgres
  namespace: my-git-repo
  labels: 
    app: forgejo-postgres
spec:
  clusterIP: None
  ports:
    - name: tcp
      port: 5432
  selector:
    app: forgejo-postgres

This deplyoment is quite easy and assumes that you have a storage solution (in this example a ceph cluster) to provide a data volume for the postgresql service.

The Git Repo

The second part of our deployment is the forgejo service – providing the git repo and the web applicaiton. Also here we need a data volume for the git repository and configuration and also a ingers network to access the application via HTTPS.

---
###################################################
# Deployment Forgejo
###################################################
apiVersion: apps/v1
kind: Deployment
metadata:
  name: forgejo-git
  namespace: my-git-repo
  labels: 
    app: forgejo-git
spec:
  replicas: 1
  selector: 
    matchLabels:
      app: forgejo-git
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: forgejo-git
    spec:

      containers:
      - env:
        - name: FORGEJO__security__INSTALL_LOCK
          value: "true"
        - name: FORGEJO__database__DB_TYPE
          value: postgres
        - name: FORGEJO__database__HOST
          value: forgejo-postgres:5432
        - name: FORGEJO__database__NAME
          value: forgejo
        - name: FORGEJO__database__USER
          value: forgejo
        - name: FORGEJO__database__PASSWD
          value: xxxx
        - name: FORGEJO__server__DOMAIN
          value: git.forgejo.foo.com
        - name: FORGEJO__server__ROOT_URL
          value: https://git.forgejo.foo.com/
        - name: FORGEJO__server__SSH_DOMAIN
          value: git.forgejo.foo.com
        - name: FORGEJO__service__DISABLE_REGISTRATION
          value: "true"
        # Mail
        - name: FORGEJO__mailer__ENABLED
          value: "true"
        - name: FORGEJO__mailer__PROTOCOL
          value: "smtp"
        - name: FORGEJO__mailer__SMTP_ADDR
          value: "mailgateway.my-git-repo"
        - name: FORGEJO__mailer__SMTP_PORT
          value: "25"
        - name: FORGEJO__mailer__FROM
          value: "Webmaster <webmaster@foo.com>"
        # Layout
        - name: FORGEJO____APP_NAME
          value: "Imixs Workflow"
        - name: FORGEJO____APP_SLOGAN
          value: "Git Forgejo Repository"
        - name: FORGEJO__i18n__DEFAULT_LANG
          value: "en-US"
        - name: FORGEJO__ui__DEFAULT_THEME
          value: "forgejo-dark"
          
        image: codeberg.org/forgejo/forgejo:9
        name: forgejo
        startupProbe:
          httpGet:
            path: /api/healthz
            port: 3000
          failureThreshold: 30     
          periodSeconds: 10

        readinessProbe:
          httpGet:
            path: /api/healthz
            port: 3000
          periodSeconds: 10

        livenessProbe:
          httpGet:
            path: /api/healthz
            port: 3000
          periodSeconds: 20
          failureThreshold: 3   

        ports:
          - containerPort: 3000
            name: http

        volumeMounts:
        - mountPath: /data
          name: forgejo-data
          subPath: forgejo
      restartPolicy: Always
      volumes:
      - name: forgejo-data
        persistentVolumeClaim:
          claimName: forgejo-data

---
###################################################
# Data Volume
###################################################
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: forgejo-data
  namespace: my-git-repo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 200Gi
  volumeMode: Filesystem
  volumeName: "forgejo-repodata"
  storageClassName: ""

---
kind: PersistentVolume
apiVersion: v1
metadata:
  name: forgejo-repodata
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 200Gi
  csi:
    driver: rbd.csi.ceph.com
    fsType: ext4
    nodeStageSecretRef:
      name: csi-rbd-secret-ceph-abpua
      namespace: ceph-system
    volumeAttributes:
      # abpua
      "clusterID": "xxxxxxxxxxxxxxxx"    
      "pool": "kubernetes"
      "staticVolume": "true"
      "imageFeatures": "layering"
    volumeHandle: "forgejo-repodata"
  persistentVolumeReclaimPolicy: Retain
  volumeMode: Filesystem

---
###################################################
# Network
###################################################
apiVersion: v1
kind: Service
metadata:
  name: forgejo-git
  namespace: my-git-repo
  labels: 
    app: forgejo-git
spec:
  ports:
    - name: http
      port: 3000
  selector:
    app: forgejo-git

---
kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  name: forgejo-git-tls
  namespace: my-git-repo
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    # prevent the controller from redirecting (308) to HTTPS
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/proxy-body-size: "512m"
  
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - git.forgejo.foo.com
      secretName: tls-forgejo-git
  rules:
    - host: git.forgejo.foo.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: forgejo-git
                port:
                  number: 3000    

As you can see I added a mail configuration and my internet domain – in this example git.forgejo.foo.com. You can replace these values.

You can also adjust the other environment parameters to your needs. These are just examples.

Deplyoment

For the deployment just save the two files into a deployment directory and run:

kubectl create namespace my-git-repo
kubectl apply -f ./

As you can see from the configuraiton I disabled self-registration. To set the default admin password you can ssh the running forgejo container and run the following shell command:

su git -c "forgejo admin user create --username my-admin --password 'xxxxx' --email admin@foot.com --admin"

This will create you first admin user to login to the dashboard.

Network Access

In my deployment I use only HTTPS and disabled the SSH port 22 that is also exposed by Forgejo. But depending on your Kubernetes architecture you possible may not expose port 22. I think it is not necessary at all as the HTTPS support is very comfortable in Forgejo using API access tokens.

Conclusion

That’s it. As you can see to run Forgejo in a Kubernetes cluster is easy to achiv. If you have comments or additional ideas – let me know!

WordPress is powerful. Maybe too powerful. If all you want is a clean blog or a product landing page, you quickly find yourself fighting plugin sprawl, sluggish load times, and an admin interface designed for agencies – not for people who just want to write.

I looked around for alternatives and landed on Ghost. Open source, MIT license, modern editor, and most importantly: no overhead. Here is how I set it up.

Continue reading “Ghost instead of WordPress – Setup a self-hosted Custom Theme”

In this blog post I explain the setup of a application running on Wildfly 29 using the OIDC authentication mechanism. It took me a long time to figure out the correct and necessary configuration steps. My requirement was not only to authenticate a user with Keycloak via OpenID Connect (OIDC), but also enable my backend services to authenticate programmatically to access the Rest API.

So we have two requirements: User login via Keycloak/OIDC and a programmatically login for backend service. The later is called Bearer Authentication mechanism.

Bearer Token Authentication

The Bearer Token Authorization is the process of authorizing HTTP requests through a valid Bearer Token. Such a token can be obtained from a Identity Authority like Keycloak using a simple curl command. For example to get a valid token from a Keycloak server you can run:

curl -X POST \
  -d "grant_type=password" \
  -d "client_id=imixs" \
  -d "client_secret=xxxxxxxxxxxxxxxxxxx" \
  -d "username=anna" \
  -d "password=123" \
  "https://my-keycloak.server/realms/my-keycloak-realm/protocol/openid-connect/token"

This will result in a JSON Web Token (JWT) containing differnet sections.

{"access_token":"eyxxxxx.eyxxxxxxxxx",
  "expires_in":300,
  "refresh_expires_in":1800,
  "refresh_token":"eyyyyyyyyyy.eyyyyyyy",
  "token_type":"Bearer",
  "not-before-policy":0,
  "session_state":"fc2f7e36-e4ba-145a-b493-efb287ec0c7a",
  "scope":"profile email"
}

The interesting one is the ‘access_token’. You can copy this part and now you can request a secured resource from your applications Rest API:

curl -X GET \
  -H "Authorization: Bearer eyyyyyyyyyyyyyyyyyy" \
  "https://my-app/api/documents/ABC"

OK, this all sounds very easy and straight forward. But due to the fact that this security mechanisms evolving fast also in wildfly there were differnet concepts used in the past. So the following will work for Wildfly 29 (and hopefully later) version.

The Wildfly Descriptor ‘oidc.json’

An easy and very fast setup is to use the Wildfly specific deployment descriptor file ‘oidc.json‘. This file is placed in /WEB-INF/ directory:

{
    "client-id" : "my-client-id",
    "provider-url" : "https://my-keycloak.server/realms/my-keycloak-realm",    
    "principal-attribute" : "preferred_username",  
    "credentials" : {
        "secret" : "xxxxxxxxxxxxxxx"
    }
}

In addition change the login-config in your web.xml file to ‘OIDC’

...
  <login-config>
    <auth-method>OIDC</auth-method>
  </login-config>
...

No further configuration is needed. No realms need to be configured at all in the standalone.xml or in your application.

The Jakarta OpenIdAuthenticationMechanismDefinition

Jakarta EE 10 includes a new authentication mechanism: OpenID Connect! This can be added to a Jakarta EE servlet using the new @OpenIdAuthenticationMechanismDefinition annotation.

This annotation is the standarized way to use OIDC authentication mechanism. You need to implement a CDI security bean in your application like shown in the following example:

import jakarta.enterprise.context.RequestScoped;
import jakarta.enterprise.event.Observes;
import jakarta.inject.Inject;
import jakarta.security.enterprise.authentication.mechanism.http.OpenIdAuthenticationMechanismDefinition;
import jakarta.security.enterprise.identitystore.openid.AccessToken;
import jakarta.security.enterprise.identitystore.openid.OpenIdContext;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;

@RequestScoped
@Path("/oidc")
@Produces({ MediaType.TEXT_PLAIN })
@OpenIdAuthenticationMechanismDefinition( //
        clientId = "${oidcConfig.clientId}", //
        clientSecret = "${oidcConfig.clientSecret}", //
        redirectURI = "${baseURL}/callback", //
        providerURI = "${oidcConfig.issuerUri}" //
)
public class Securitybean implements Serializable {
    private static final long serialVersionUID = 1L;
   
    @Inject
    Principal principal;

    @Inject
    private OpenIdContext context;

    @GET
    @Produces("text/plain")
    public String sessionInfoAuth() {
        String message = "";
        try {
            System.out.println("=========================================");
            if (principal != null) {
                System.out.println("  Principal name: " + principal.getName());
            } else {
                System.out.println("  Principal resolved to null!");
            }
            // Here's the unique subject identifier within the issuer
            if (context == null) {
                message = "Failed to resolve OpenIdContext!";
            } else {
                System.out.println("  Subject = " + context.getSubject());
                System.out.println("  Access token = " + context.getAccessToken());
                System.out.println("  ID token = " + context.getIdentityToken());
                System.out.println("  Claims json = " + context.getClaimsJson());
                System.out.println("=========================================");
                message = "Imixs-Security-OIDC ==> OK \n" + //
                        "User Principal      ==> " + principal.getName()
                        + "\n\nSession details are available on server log";
            }
        } catch (Exception e) {
            message = "Failed to resolve OpenIdContext!";
        }
        return message;
    }
}

The important part is only the annotation. I added the method sessionInfoAuth only for convenience to provide a rest API to check the auth information.

Using this mechanism it is important to disable the integrated-jaspi module in your standalone.xml file:

...
        <subsystem xmlns="urn:jboss:domain:undertow:14.0" default-virtual-host="default-host"
            default-servlet-container="default" default-server="default-server"
            statistics-enabled="${wildfly.undertow.statistics-enabled:${wildfly.statistics-enabled:false}}"
            default-security-domain="other">
            ......
            <application-security-domains>
                <application-security-domain name="other" security-domain="ApplicationDomain"
                    integrated-jaspi="false" />
            </application-security-domains>
            .......
        </subsystem>            
.....  

The problem is, that with this setup you can login as a user like before with the oidc.yaml file, but a programmatic login with the access token is no longer possible.

If you find an solution for this problem, please let me know 😉

Update 25. June 2025

I have developed a new OIDC Module that allows an easy and platform independent integration of ODIC into modern Web Applications.
Find details about Imixs-Security-OIDC here.

In the following I show an example how you can upgrade an old PostgreSQL server to a new Major version running in a Kubernetes cluster. In this example I upgrade directly from 9.6.1 to 17.4. My deployment runs on Kubernetes and I have external data volumes bound to my servers based on a ceph system. The migration concept in short is the following:

1. Mount a new /backup/ volume to backup the data on the old databasesever
2. Backup the existing database with pg_dump
3. Undeploy your old PostgreSQL Server
4. Create a new deployment for the new empty Server and mount the /backup/ volume
5. Restore the backup with pg_restore

Continue reading “PostgreSQL: Major Upgrade in Kubernetes”