When setup MySQL using Docker, I got this warning messages.

2022-03-01 16:32:02+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.37-1debian10 started.
2022-03-01 16:32:03+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2022-03-01 16:32:03+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.37-1debian10 started.
2022-03-01 16:32:03+00:00 [Note] [Entrypoint]: Initializing database files
2022-03-01T16:32:03.363347Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2022-03-01T16:32:03.368810Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting.
2022-03-01T16:32:03.368894Z 0 [ERROR] Aborting

As suggested in the logs above, the simple solution is you have to add explicit_defaults_for_timestamp=true into /etc/mysql/mysql.conf.d/mysqld.cnf on the [mysqld] section. Then restart your MySQL to take effect.

2022-03-01 19:21:03+00:00 [Note] [Entrypoint]: Starting temporary server
2022-03-01 19:21:03+00:00 [Note] [Entrypoint]: Waiting for server startup
2022-03-01T19:21:04.098887Z 0 [Note] mysqld (mysqld 5.7.37) starting as process 73 ...
2022-03-01T19:21:04.122680Z 0 [Note] InnoDB: PUNCH HOLE support available
2022-03-01T19:21:04.122817Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2022-03-01T19:21:04.122872Z 0 [Note] InnoDB: Uses event mutexes
2022-03-01T19:21:04.122885Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2022-03-01T19:21:04.122891Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-03-01T19:21:04.122897Z 0 [Note] InnoDB: Using Linux native AIO
2022-03-01T19:21:04.123252Z 0 [Note] InnoDB: Number of pools: 1
2022-03-01T19:21:04.123396Z 0 [Note] InnoDB: Using CPU crc32 instructions
2022-03-01T19:21:04.126063Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2022-03-01T19:21:04.141636Z 0 [Note] InnoDB: Completed initialization of buffer pool
2022-03-01T19:21:04.144961Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().

Reference:
https://stackoverflow.com/questions/15701636/how-to-enable-explicit-defaults-for-timestamp

I just checked OKD cluster in our development environment, I saw that OKD worker has node lost status.

Root cause analysis
First, we can check service status.

# systemctl status origin-node

And here's the output

● origin-node.service - OpenShift Node
   Loaded: loaded (/etc/systemd/system/origin-node.service; enabled; vendor preset: disabled)
   Active: activating (start) since Mon 2022-02-07 12:15:05 UTC; 1min 54s ago
     Docs: https://github.com/openshift/origin
 Main PID: 104753 (hyperkube)
   Memory: 22.9M
   CGroup: /system.slice/origin-node.service
           └─104753 /usr/bin/hyperkube kubelet --v=2 --address=0.0.0.0 --allow-privileged=true --anonymous-auth=true --authentication-token-webhook=true --authentication-token-webhook-cache-t...

Feb 07 12:15:05 nod03 origin-node[104753]: I0207 12:15:05.904780  104753 server.go:418] Version: v1.11.0+d4cacc0
Feb 07 12:15:05 nod03 origin-node[104753]: I0207 12:15:05.904830  104753 feature_gate.go:230] feature gates: &{map[RotateKubeletServerCertificate:true RotateKubeletClientCertificate:true]}
Feb 07 12:15:05 nod03 origin-node[104753]: I0207 12:15:05.904910  104753 feature_gate.go:230] feature gates: &{map[RotateKubeletServerCertificate:true RotateKubeletClientCertificate:true]}
Feb 07 12:15:05 nod03 origin-node[104753]: I0207 12:15:05.905038  104753 plugins.go:97] No cloud provider specified.
Feb 07 12:15:05 nod03 origin-node[104753]: I0207 12:15:05.905054  104753 server.go:534] No cloud provider specified: "" from the config file: ""
Feb 07 12:15:05 nod03 origin-node[104753]: E0207 12:15:05.919875  104753 bootstrap.go:195] Part of the existing bootstrap client certificate is expired: 2022-02-02 07:40:00 +0000 UTC
Feb 07 12:15:05 nod03 origin-node[104753]: I0207 12:15:05.919901  104753 bootstrap.go:56] Using bootstrap kubeconfig to generate TLS client cert, key and kubeconfig file
Feb 07 12:15:05 nod03 origin-node[104753]: I0207 12:15:05.920585  104753 certificate_store.go:131] Loading cert/key pair from "/etc/origin   / node/certificates/kubelet-client-current.pem".
Feb 07 12:15:05 nod03 origin-node[104753]: I0207 12:15:05.935057  104753 csr.go:105] csr for this node already exists, reusing
Feb 07 12:15:05 nod03 origin-node[104753]: I0207 12:15:05.937670  104753 csr.go:113] csr for this node is still valid

Check also nodes status

# oc get nodes
NAME      STATUS     ROLES          AGE
mst01     Ready      infra,master   2y
nod01     Ready      compute        2y
nod02     Ready      compute        2y
nod03     NotReady   compute        1y

As we can see above the log of origin-node service has certificate issue, and there is woker node has Not Ready.
Step to fix
Go check the CSR (Certificate Signing Request) with the following command:

# oc get csr
NAME                                                   AGE       REQUESTOR                                                 CONDITION
node-csr-iu4kZ9NYHiltJkndh4k5E9kjQq7jQv6TewLOyOuYeCU   19m       system:serviceaccount:openshift-infra:node-bootstrapper   Pending

The CSR has pending state, so we have to approve it.

# oc get csr -o name | xargs oc adm certificate approve
certificatesigningrequest.certificates.k8s.io / node-csr-iu4kZ9NYHiltJkndh4k5E9kjQq7jQv6TewLOyOuYeCU approved

And check it with oc get csr again:

NAME                                                   AGE       REQUESTOR                                                 CONDITION
csr-q2r52                                              7s        system:node:nod03                                         Pending
node-csr-iu4kZ9NYHiltJkndh4k5E9kjQq7jQv6TewLOyOuYeCU   21m       system:serviceaccount:openshift-infra:node-bootstrapper   Approved,Issued

If there's pending state of CSR, just approve it like we do before with oc get csr -o name | xargs oc adm certificate approve. Then check it again to make sure if CSR has been approved.

# oc get csr
NAME                                                   AGE       REQUESTOR                                                 CONDITION
csr-q2r52                                              20s       system:node:nod03                                         Approved,Issued
node-csr-iu4kZ9NYHiltJkndh4k5E9kjQq7jQv6TewLOyOuYeCU   22m       system:serviceaccount:openshift-infra:node-bootstrapper   Approved,Issued

Rechecking nodes
Make sure origin-node service and nodes status has running.

# systemctl status origin-node
● origin-node.service - OpenShift Node
   Loaded: loaded (/etc/systemd/system/origin-node.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2022-02-07 12:24:02 UTC; 40s ago
     Docs: https://github.com/openshift/origin
 Main PID: 572 (hyperkube)
   Memory: 133.4M
   CGroup: /system.slice/origin-node.service
           └─572 /usr/bin/hyperkube kubelet --v=2 --address=0.0.0.0 --allow-privileged=true --anonymous-auth=true --authentication-token-webhook=true --authentication-token-webhook-cache-ttl=...

# oc get nodes
NAME      STATUS     ROLES          AGE
mst01     Ready      infra,master   2y
nod01     Ready      compute        2y
nod02     Ready      compute        2y
nod03     Ready      compute        1y

If all running well, finally do check on the OKD web console side.

I'm getting the error when installing Spotify on Arch using Yay a.k.a Yet another Yogurt, it's an AUR Helper. The problem

:: PGP keys need importing:
 -> F9A21197XXXXX, required by: spotify
==> Import? [Y/n] y
:: Importing keys with gpg...
gpg: keyserver receive failed: Server indicated a failure
 -> problem importing keys

Step to fix
The resolution to fix the gpg key server error when importing keys, then I simply run:

$ gpg --keyserver hkp://pgp.rediris.es --recv-keys F9A21197XXXXX

or

$ gpg --keyserver hkp://keys.gnupg.net --recv F9A21197XXXXX

Selamat Tahun Baru 2021! Semoga di tahun 2021 ini Coronavirus(Covid-19) dapat segera berakhir, semoga apa yang direncanakan dapat terwujud, dan ke depannya menjadi lebih baik lagi.
Aamiin.

Image Credit: Eugine Cholo

Well, a couple days ago my friend contacted me that his server on Linode Cloud Hosting & Linux Servers was infected a malware. His server that had cpu high usage. After checking in-depth that the name of malware is kinsing, and was owned by postgres user.

Removing the malware
On this step we'll remove the malware manually. FYI, the characteristic of malware that he will create a kdevtmpfsi on /tmp and kinsing on /var/tmp directory, and the impact is it will consuming high CPU on the server. Every time I tried to removed the kdevtmpfsi and kinsing file on /tmp and /var/tmp but no luck, it will recreating by itself and running as postgres user.

As you can see above, the malware tried to download kinsing file from ip address 188.119.112.132.

Step to remove
As describe here, assuming you have been removed the malware on /tmp and /var/tmp directory, then create a kdevtmpfsi and kinsing file as follow:
At first, find and remove it:

# find / -iname kdevtmpfsi -exec rm -fv {} \;
# find / -iname kinsing -exec rm -fv {} \;    

Then create it:

# touch /tmp/kdevtmpfsi && touch /var/tmp/kinsing
# chmod 000 /tmp/kdevtmpfsi && chmod 000 /var/tmp/kinsing
# chattr +i /tmp/kdevtmpfsi && chattr +i /var/tmp/kinsing

Then purge remove of postgresql.

# apt-get remove --purge postgresql

After the step above, please reboot the server, and then install again the postgresql.

That's all!

References:
https://boxmatrix.info/wiki/Property:kdevtmpfs
https://en.wikipedia.org/wiki/Chattr#In_Linux_systems_.28chattr_and_lsattr.29
https://htop.dev/
https://linux.die.net/man/1/top