https://daniel.feldroy.com/posts/autodocumenting-makefiles
標題: 「透過一點小技巧讓你的 Makefile 有一個更好的 Help說明」 類別: tools 連結: https://daniel.feldroy.com/posts/autodocumenting-makefiles
本篇文章使用 python 搭配 Makefile 的內建語法來輕鬆幫你的 Makefile 加上各種 Help 訊息，整個概念滿簡單的
有興趣的可以看看，整個寫法非常簡單有趣。
標題: 「視覺化系統內 iptables 規則」 類別: tools 連結: https://github.com/Nudin/iptable_vis
這是一個非常有趣的小工具，目標就是視覺化系統中的 iptables 規則，把 chain 之間的關聯給視覺化呈現出來 整個專案非常小，該專案主要會透過 awk 來解析系統中的規則並且產生特定輸出，接者使用別的軟體將該輸出給轉換成圖檔
有興趣的都可以使用看看
標題: 「如何用 2297 個 Linux Kernel Patches 來重新整理所有的 header file 並提升整個 Kernel 建置時間高達 78%」 類別: 其他 連結: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Fast-Kernel-Headers
摘要: Linux Kernel 的長期貢獻者 Ingo Molnar 花了一年多的時間整理 Kernel 內的 Header 架構，一口氣提交了 2297 個 patches，其中影響 的檔案數量有 25,288 個，並且加入了 178,024 行數，移除了 74,720 行。 這一系列的改動直接重新整理 Linux Kernel 內將近 10,000 個不同的 header 檔案，這次的整理將過去 30 年累積的各種你呼叫我，我呼叫你這 種「Dependency Hell」問題給一起處理掉，結果論來說提升了整體建置時間 50% ~ 80 %
標題: 「如何使用 jq 讓你的 kubectl更為強大」 類別: tools 連結: https://medium.com/geekculture/my-jq-cheatsheet-34054df5b650
作者認為 kubectl 本身提供的 label-selector, go-templates, jsonpath, custom-colume 等各式各樣功能使這個工具變得強大，能夠找到符合自己需求的各式各樣資源 然而上述的這些指令使用起來還是會覺得卡卡的，並沒有辦法滿足所有條件，而且不同選項的語法也完全不同，所以對於操作者來說其實不太便利。
順利的是 kubectl 可以透過 -o json 以 json 的格式輸出結果，這時候就可以搭配 jq 這個指令來使用，相對於前述的各種用法，作者更加推薦使用 jq 來處理，因為 jq 是一個更為廣泛的工具， 除了 kubectl 可以搭配外，很多時候都可以搭配 jq 來處理其他情況，因此掌握 jq 的語法實務上會有更多用途。
文章幾乎都是以 kubectl 為範例來介紹 jq 內的各種用法，除了基本的 read/write/filter 之外，還有各式各樣 jq 的內建函式， 有興趣的都可以使用看看
標題: 「PwnKit, 長達 12 年可以讓一般使用者輕鬆變成 Root 的 CVE」 類別: others 連結: https://blog.qualys.com/vulnerabilities-threat-research/2022/01/25/pwnkit-local-privilege-escalation-vulnerability-discovered-in-polkits-pkexec-cve-2021-4034
CVE-2021-4034 講述的是 pkexec 此工具的 vulnerability，其影響範圍非常廣大，主要原因有
漏洞細節文章中有解釋非常多，主要是記憶體位置的處理沒有處理，當運行參數為空的時候，程式會意外地去讀取到後面的 envp 這塊用來存放環境變數的區塊，搭配 pkexec 後續的程式邏輯就有機會觸發本次 CVE 的安全性問題。 所以請趕緊更新系統上的 pkexec，確保該版本已經更新，否則任何一個使用者都可以輕鬆變成 root。
Ubuntu 使用者可參考 https://ubuntu.com/security/CVE-2021-4034
標題: 「Linux 5.17 將使用 BLAKE2s 來替代 SAH1 來達到更安全更快速的隨機亂數產生器」 類別: other 連結: https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.17-RNG
Linux Kernel 內亂數子系統的維護者近期遞交了一個將 SAH1 給全面替換為 BLAKE2s 的相關 Patch
相對於 SHA1 來說， BLAKE2s 本身更為安全，同時計算速度也更快，這邊也可以參考下列這篇 2017 的文章 https://valerieaurora.org/hash.html 來探討不同 HASH 演算法的一些狀態，雖然沒有及時更新到 2022 的狀態，但是如果 2017 都 不安全的東西現在就更不應該使用，譬如文章中提到 SAH1 於 2017 就被 Google 用(6500 CPU或是110 GPU)的實驗來證實有衝突，建議停止使用。
標題: 「Kubernetes 內透過 DNS-01 處理 wildcard TLS 的兩三事」 類別: introduction 連結: https://medium.com/linkbynet/dns-01-challenge-wildcard-tls-certificates-on-kubernetes-d2e7e3367328
很多人都會使用 Kubernetes 的 Ingress 讓外部可以存取的部署的應用程式，同時會透過 Ingress 搭配 Cert Manager 來處理 TLS 的憑證 大部分情況下都會使用 HTTP-01 的方式來進行域名擁有性的認證，而某些情況可能不方便透過 HTTP 來驗證的話就會採取 DNS-01 的方式透過 DNS 創建一個 TXT 的資訊來驗證域名的擁有權，本篇文章則是作者分享 DNS-01 的一些心得分享
對 DNS-01 使用有興趣的可以看看本篇文章
標題: 「透過 Crossplane 與 ArgoCD 來達成應用程式與基礎建設的 GitOps 部署方式」 類別: cicd 連結: https://medium.com/containers-101/using-gitops-for-infrastructure-and-applications-with-crossplane-and-argo-cd-944b32dfb27e
作者表示過往很多教學文章當探討到 Kubernetes 部署議題的時候，通常都不會去探討如何部署 Kubernetes 而是專注於應用程式的部署， 理由非常直觀，文章就是要專注於 Deployment 的議題，能夠讓讀者更容易地去閱讀與參考，另外一個背後的原因其實是因為 Kubernetes 部署的方式 太多種，常見的方式使用 Terraform 透過 IaC 的概念來管理，而應用程式都使用 Helm/Kustomize 完全不同的方式來管理
而作者今天想要探討的是如何透過 ArgoCD 來建設一個 GitOps 的環境，並且於上面使用 Crossplan 這個解決方案來處理各種底層基礎建設的需求，如此一來 就可以統一透過 Helm/Kustomize 的方式來描述這些基礎建設
Crossplan 很類似 Terraform 但是有者一些些微的差異
由於整個 Crossplan 可以視為一個 Kubernetes 應用程式，所以直接使用 ArgoCD 的方式來部署 有興趣的可以閱讀全問
標題: 「The pains of GitOps 1.0」 類別: cicd 連結: https://codefresh.io/about-gitops/pains-gitops-1-0/
作者認為很多文章都闡述 GitOps 對於部署帶來的好處，但是軟體世界沒有十全十美的東西，所以作者就探討了 12 個其認為 GitOps 的缺點
註:
這邊就節錄幾個文章中探討的議題，剩下有興趣的可以閱讀全文
作者認為 GitOps 的精神「我想要將 Git 專案內的所描述的狀態給同步到叢集中」這點只能處理應用程式部署的問題，但是其他的流程 譬如編譯程式碼，運行單元測試，安全性檢查，靜態掃描等過程都沒有辦法被 GitOps 給處理。
作者不滿的點主要是很多 GitOps 的工具好像都會宣傳自己是個全能的解決方案，能夠處理所有事情，但是實際上卻沒有辦法。 實際上其專注的點就是應用程式部署策略為主的部分，其餘部分還是團隊要有自己的方式去處理
過往很多團隊都會將 CI/CD 給整合到相同的 pipeline 中去處理，通常是最後一個階段就會將應用程式給部署到目標叢集，然而有外部 Controller 實作的 GitOps 解決方案會使得 CI/CD 兩者脫鉤，好處來說就是 pipeline 不需要去處理部署，只需要專心維護 Git 內的資訊，後續都讓 Controller 來處理。
然後某些團隊本來的 CI/CD 流程會於部署完畢後還會進行一些測試或是相關操作，這部分會因為 GitOps 將部署給弄走導致整個流程不太好處理，畢竟要如何讓 GitOps 部署完畢後又要可以觸發其他的工作也是額外要處理的事情
雖然 GitOps 的核心是透過 Git Commit 去控制當前部署的版本，那發生問題時到底該怎麼處理，如何去 rollback? 作者舉兩種範例
作者認為目前現有的 GitOps 工具都沒有辦法提供下列答案
註: 有什麼概念是天生就可以有這些東西的..? GitOps 有點無妄之災
標題: 「NPM 的 colors modules 打亂一堆人...」 類別: other 連結: https://research.swtch.com/npm-colors
NPM 上一個著名的 Module Color 以及 Faker 的作者這幾天生氣氣的修改這兩個 module，於 Color 內塞入了無限循環並且印出各種亂碼 然後所有使用這兩個 module 的工具一旦更新就會發現自己的 Terminal 輸出整個爆炸，完全看不懂了。
這篇文章是 Golang 的作者 Russ Cox 分享關於這件事情的一些看法，簡單來說每個開放原始碼的授權都有提到並沒有保固這種事情，所以任何現代化的模組管理者 設計時都必須要考量到這種版本更新的可能性，並且盡可能地去減少。
文章中以 aws-cdk 作為範例， aws-cdk 最初描述時是使用 ^1.4.0 的方式來參考各種 ^1.4.0 版本的 color，結果 color 的作者就直接爆氣來一個炸彈，aws-cdk 直接更新然後建置，最後 產生出一個令人崩潰的版本。
作者認為任何一個系統要更新的時候應該都需要緩慢與穩健的去逐步更新，並且這些更新都要經過一段時間的觀察與測試來降低各種可能放到生產系統出包的可能性。
以下節錄自文章中的重點 「High-fidelity builds solve both the testing problem and the gradual rollout problem. A new version of colors wouldn’t get picked up by an aws-cdk install until the aws-cdk authors had gotten a chance to test it and push a new version configuration in a new version of aws-cdk. At that point, all new aws-cdk installs would get the new colors, but all the other tools would still be unaffected, until they too tested and officially adopted the new version of colors.」