How to change variable value via task script in redhat PAM

 Use kcontext to update variable value

kcontext.setVariable("validationError",validationError1);

Enable SSL Trace in IBM HTTP server

 Step 1: Stop IBM HTTP Server.

Step 2: Turn on IBM HTTP Server verbose logging for SSL

Append the LogLevel directive to httpd.conf:

• IBM HTTP Server 9.0 and later:

LogLevel debug ibm_ssl:trace8

• IBM HTTP Server 8.5.5 and earlier:

LogLevel debug

Append SSLTrace directive to httpd.conf (no argument)

SSLTrace

Step 3: Start HTTP Server.

Ref: https://www.ibm.com/support/pages/mustgather-ibm-http-server-ssl-handshake-and-configuration-problems

List all supported ciphers if ibm http server.

 Use the below command to list all support ciphers

bin/apachectl -t -f path/to/httpd.conf -DDUMP_SSL_CIPHERS

Ref: https://www.ibm.com/docs/en/ibm-http-server/8.5.5?topic=options-ssl-cipher-specifications

Use separate cer for separate domain with nginx ingress in kubernetes

 We have nginx  ingress to control https service and forward to backend in kubernetes. We want some thing like domain abc.com should use "abc.com" 's certificate  and  domain xyz.com should use "xyz.com" 's certificate.

Step 1: Create TLS Secrets

Anytime we reference a TLS secret, we mean a PEM-encoded X.509, RSA (2048) secret.

You can generate a self-signed certificate and private key with:

$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout abc.key -out abc.cer -subj "/CN=abc.com/O=abc.com"

Then create the secret in the cluster via:

$kubectl create secret tls abc --key abc.key --cert abc.cer

The resulting secret will be of type kubernetes.io/tls.

We add same tls for xyz.com domain.

Step 2: Add ingress resource 

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    # Enable client certificate authentication
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    # Create the secret containing the trusted ca certificates
    nginx.ingress.kubernetes.io/auth-tls-secret: "default/ca-secret"
    # Specify the verification depth in the client certificates chain
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    # Specify an error page to be redirected to verification errors
    nginx.ingress.kubernetes.io/auth-tls-error-page: "http://www.mysite.com/error-cert.html"
    # Specify if certificates are passed to upstream server
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"
  name: nginx-test
  namespace: default
spec:
  rules:
  - host: abc.com
    http:
      paths:
      - backend:
          serviceName: http-svc
          servicePort: 80
        path: /
  tls:
  - hosts:
    - abc.com
    secretName: abc

Ref: https://kubernetes.github.io/ingress-nginx/examples/auth/client-certs/

Add the DNS entry to DNSCore in kubernetes

 Edit configmap with name coredns in namespace 

kubectl edit cm coredns   -n kube-system

apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
log
health
rewrite name foo.example.com foo.default.svc.cluster.local
kubernetes cluster.local 10.0.0.0/24
file /etc/coredns/cluster.db cluster.local
proxy . /etc/resolv.conf
cache 30
}
cluster.db: |

cluster.local.               IN      SOA     ns.dns.cluster.local. hostmaster.cluster.local. 2015082541 7200 3600 1209600 3600

something.cluster.local.     IN      A       10.0.0.1

otherthing.cluster.local.    IN      CNAME   google.com.

Add the highlight  content above( The example.db is included dns entries the you want to add).

and we also need to edit the volumes section of the Pod template spec(DNSCore deployment):

      volumes:

and we also need to edit the volumes section of the Pod template spec:

volumes:
- name: config-volume
configMap:
name: coredns
items:
- key: Corefile
path: Corefile
- key: cluster.db
path: cluster.db

Ref: https://coredns.io/2017/06/08/how-queries-are-processed-in-coredns/

Use Multicast to keep the request body

 In the Redhat Fuse, when we route to the target system( like API, Database) the body will be overwrite with the response for  target system. In case we want access the data from the request, we should use  Multicast.

With the route above, The request will duplicate  to 2 route ( _route2 and _route3 ) and merge  the response of those route to  it body ( it 's array of  responses ). So, because the _route2 just  echo the message then we can access the  origin request.

And we can access the merge  of those response like access the array

 

Control plane node isolation

 By default, your cluster will not schedule Pods on the control-plane node for security reasons. If you want to be able to schedule Pods on the control-plane node, for example for a single-machine Kubernetes cluster for development, run:

kubectl taint nodes --all node-role.kubernetes.io/master-

With output looking something like:

node "test-01" untainted
taint "node-role.kubernetes.io/master:" not found
taint "node-role.kubernetes.io/master:" not found

This will remove the node-role.kubernetes.io/master taint from any nodes that have it, including the control-plane node, meaning that the scheduler will then be able to schedule Pods everywhere

Ref: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/