Running multiple OpenVPN on the mac, sometimes my DNS hangs and I can’t get the VPNs. I use this hack to get around it.
❯ sudo networksetup -setdnsservers Wi-Fi "Empty"
Running multiple OpenVPN on the mac, sometimes my DNS hangs and I can’t get the VPNs. I use this hack to get around it.
❯ sudo networksetup -setdnsservers Wi-Fi "Empty"
My teammate hit an issue with Ingress Certificates not being valid:
oc get co ingress -oyaml
message: |-
OAuthServerRouteEndpointAccessibleControllerDegraded: Get "https://oauth-openshift.apps.mycluster.local/healthz": tls: failed to verify certificate: x509: certificate has expired or is not yet valid: current time 2025-04-02T17:58:35Z is after 2025-02-13T20:04:16Z
RouterCertsDegraded: secret/v4-0-config-system-router-certs.spec.data[apps.mycluster.local] -n openshift-authentication: certificate could not validate route hostname oauth-openshift.apps.mycluster.local: x509: certificate has expired or is not yet valid: current time 2025-04-02T17:58:33Z is after 2025-02-13T20:04:16Z
The Red Hat docs and tech articles are great. I found How to redeploy/renew an expired default ingress certificate in RHOCP4?
I ran the following on a non-production cluster:
oc get secret router-ca -oyaml -n openshift-ingress-operator> router-ca-2025-04-02.yaml
oc delete secret router-ca -n openshift-ingress-operator
oc delete pod --all -n openshift-ingress-operator
wait 30
oc get secret router-ca -n openshift-ingress-operator
oc get po -n openshift-ingress-operator
oc get secret router-certs-default -o yaml -n openshift-ingress > router-certs-default-2025-04-02.yaml
oc delete secret router-certs-default -n openshift-ingress
oc delete pod --all -n openshift-ingress
wait 30
oc get secret router-certs-default -n openshift-ingress
oc get po -n openshift-ingress
curl -v https://oauth-openshift.apps.mycluster.local/healthz -k
* subject: CN=*.apps.mycluster.local
* start date: Apr 2 19:08:33 2025 GMT
* expire date: Apr 2 19:08:34 2027 GMT
oc -n openshift-ingress-operator get secret router-ca -o jsonpath="{ .data.tls\.crt }" | base64 -d -i > ingress-ca-2025-04-02.crt
cp /root/ingress-ca-2025-04-02.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust
oc login -u kubeadmin -p YOUR_PASSWORD https://api.mycluster.local:6443
You’ve seen how to recreate the cert.
You should use the cert-manager operator from Red Hat.
The Red Hat team has released a new version of the Multi-Arch Tuning Operator.
In Multi-Arch Compute clusters, the Multiarch Tuning Operator influences the scheduling of Pods, so application run on the supported architecture.
You can learn more about it at https://catalog.redhat.com/software/containers/multiarch-tuning/multiarch-tuning-operator-bundle/661659e9c5bced223a7f7244
Addendum
My colleague, Punith, worked with the Red Hat team to add NodeAffinityScoring and plugin support to the Multi-Arch Tuning Operator and ClusterPodPlacementConfig. This feature allows users to define cluster-wide preferences for specific architectures, influencing how the Kubernetes scheduler places pods. It helps optimize workload distribution based on preferred node architecture.
Spec:
Plugins:
NodeAffinityScoring:
enabled: true
platforms:
- architecture: ppc64le
weight: 100
- architecture: amd64
weight: 50
Kudos to the Red Hat team. link
The introduction of the FIPS Cryptographic Module in Go 1.24 marks a watershed moment for the language’s security capabilities. This new module provides FIPS 140-3-compliant implementations of cryptographic algorithms, seamlessly integrated into the standard library. What makes this particularly noteworthy is its transparent implementation. Existing Go applications can leverage FIPS-compliant cryptography without requiring code changes.
Build-time configuration through the GOFIPS140 environment variable, allowing developers to select specific versions of the Go Cryptographic Module.
GOFIPS140=true go build
Runtime control via the fips140 GODEBUG setting, enabling dynamic FIPS mode activation.
GODEBUG=
Keep these in your toolbox along with GOARCH=ppc64le
The IBM Linux on Power team pushed new images to their public open source container images in the IBM Container Registry (ICR). This should assure end users that IBM has authentically built these containers in a secure environment.
The new container images are:
| Image Name | Tag Name | Project Licenses | Image Pull Command | Last Published |
|---|
| fluentd-kubernetes-daemonset | v1.14.3-debian-forward-1.0 | Apache-2.0 | podman pull icr.io/ppc64le-oss/fluentd-kubernetes-daemonset:v1.14.3-debian-forward-1.0 | March 17, 2025 |
| cloudnative-pg/pgbouncer | 1.23.0 | Apache-2.0 | podman pull icr.io/ppc64le-oss/cloudnative-pg/pgbouncer:1.23.0 | March 17, 2025 |