幫朋友安裝開源好用的mail server 「iredmail」，若需要加白名單，有兩個方法：
# python wblist_admin.py --list --whitelist
# python wblist_admin.py --list --blacklist
# python wblist_admin.py --add --whitelist 202.96.134.133 john@example.com @test.com @.abc.com
# python wblist_admin.py --add --blacklist 202.96.134.133 john@example.com @test.com @.abc.co先找出 wblist_admin 在哪個地方，然後加上白名單即可
系統大概長這樣，一個RockyLinux 9.2 主機安裝 iRedMail 1.6.3版(容器還在Beta版)，iRedMail安裝滿簡單的，很快就搞定；但因為太霸氣應改主機的nginx設定，並且深度修改，若這主機只當mail server倒是沒問題，但可惜因為種種原因需要再安裝一個wordperss容器，這就麻煩了，我得了解如何讓nginx使用反向代理方式(proxy)，才能連到wordpress，nginx反向代理設定似乎很簡單，也成功了，可惜log卻一直跳出錯誤：
connect() failed (111: Connection refused) while connecting to upstream
我祭出google大神，試了很多建議與解法卻失敗了，就在第9999次嘗試之後，突然意識到甚麼，將設定改了一下，只是簡單的將原本連到容器的方式 http://127.0.0.1:8080 改成該具名稱連線 http://www.test.com:8080 (該wordpress容器對外連結為https://www.test.com)，錯誤訊息居然就停止了，真是神奇。
proxy_pass http://127.0.0.1:8080;
改成以下具名設定
proxy_pass http://www.test.com:8080;算一算農曆七月快到了，就當作是靈異事件好了。
備份手法很多，最簡單就是整個主機定期做快照，加上離線備份，這樣就沒甚麼問題了。
但是我最近思考一件事，若我們想將podman上的容器軟體改成docker或是改回實體機使用， 這樣就比較棘手了。
我自己因為遇到podman storage要改不同位置，依照我以前文章更改storage路徑的做法再改一次路徑，podman居然整個崩潰了，搞到還要執行 podman system reset 才能恢復使用，但是reset後，原本的容器軟體全部出問題，若我有乖乖針對容器軟體進行備份，就不會這麼難堪了，最後只能整個VM還原。
所以我想了又想，覺得還是要直接備份容器的「images」與「volumes」。
爬文爬了幾天，修修改改後，我終於融合一個能備份容器以及其volume的腳本，很適合容器母體(host)為Linux使用，該腳本會備份所有的images、volume與執行容器指令。
按此下載podman容器備份腳本(需要輸入guest/guest，下載後請記得修改開頭幾行之備份路徑)。
執行備份，先備份images，然後掃描volume，查詢volume若與images互通款取，也一併備份，最後追蹤最初容器執行之指令，也一併圈禁備份起來。
備份後，每個目錄將包含容器使用之images、volumes與rush.sh(啟用指令)
後來我發現volume很適合restic增量備份方式，可以減少我這腳本full backup很耗空間的作法。
因此又改寫了一份針對volume能增量備份的腳本，兩種可以同時搭配使用，例如每個月一次full backup，剩下的定期每日或每周進行restic備份。
按此下載podman容器使用restic備份腳本(需要輸入guest/guest，下載後請記得修改開頭幾行之備份路徑)。
同仁反應搜尋檔案(檔名)失敗，我重開nextcloud沒用，系統剛好出現可以升級到25.0.8訊息，升級後也沒用；我冷靜仔細想想，覺得可能跟檔案快取有關，然後就想到一個神奇的指令，這個指令應該跟資料庫重新作index類似吧。
這個適合「換新container」或一季做一次 docker exec -u www-data -it nextcloud php occ files:scan --all #這個適合每天做一次 docker exec -u www-data -it nextcloud php occ files:scan --unscanned --all
重新scan檔案後，該同仁就可以搜尋到了。
最後我們要讓這個指令在host本體主機上，定期以排程(crontab)方式執行工作：
nextcloud可以連接多個ldap server，這對於IT來說很方便。
隨著時間推移，越來越多使用者離職，帳號設定成停用，當我們確認可以刪除後，nextcloud卻無法正常透過UI介面刪除帳號，這會造成一些困擾；很懶的我後來我爬文，解方居然是下指令才能刪除，更麻煩的是只能一個一個帳號刪除，真真嚇死我。
好險有個神人寫shell script就能批次刪除。
for i in $(php occ ldap:show-remnants | awk -F'| ' '{print $2}'); do
echo "Delete user: $i"
php occ user:delete $i
done
因為我用的是容器(docker)，指令如下：
for i in $(docker exec -u www-data -it nextcloud php occ ldap:show-remnants | awk -F'| ' '{print $2}'); do
echo "Delete user: $i"
docker exec -u www-data -it nextcloud php occ user:delete $i
done
Done.
警告：刪除帳號會導致該帳號所有檔案一併被刪除。
nextcloud的背景排程，預設為 AJAX，雖說nextcloud建議使用系統cron，但是nextcloud容器cron是「不啟用」的，每次改用Cron，還要進容器另外處哩，非常麻煩，容器升級又要做一次，折磨人啊 。 久而久之，nextcloud一律使用預設值AJAX，我測試過AJAX不會失敗(私、失敗しないので）。
直到最近我使用nextcloud的看板系統(Deck)，需要有「email通知 Deck系統裡 卡片異動通知」之功能，因此AJAX單人用還可以，但公司用我就得改用Cron，可是一想到要進容器啟用cron就覺得好煩，才來才知道我錯了。
原來改用cron意外地簡單!
不管是RockLinux、CentOS還是ubuntu，只要在容器宿主(Host)裡的cron，加上一條指令就完事了。
/usr/bin/docker exec -t -u www-data <容器名稱> php -d memory_limit=512M -f /var/www/html/cron.php
真是太棒了!
以下是排程我建議要執行的
docker exec -t -u www-data nextcloud php occ trashbin:expire --quiet
docker exec -t -u www-data nextcloud php occ versions:expire --quiet
docker exec -t -u www-data nextcloud php -d memory_limit=512M -f /var/www/html/cron.php
docker exec -u www-data -it nextcloud php occ files:scan --all
docker exec -u www-data -it nextcloud php occ files:scan --unscanned --all
自從我懂事以來，都是利用 certbot 進行 「HTTP-01 Challenge」，讓發證單位透過http方式驗證，以取得免費的https證書。
除非遇到Let’sEncrypt考驗伺服器秀逗，否則不可能出問題；長大後，我雄心壯志到各地歷練，發現有些主機 80、443 port 居然被封鎖，沒有了80 port (http)，就無法透過HTTP-01考驗方式取得https證書。直到此時，我才知道「代誌不是我們憨人想的架甘丹」—事情不是我們想像的這麼簡單啊。
後來我祭出google大神，引導我到Let’s Encrypt的Challenge Types，這網站列出支援的考驗類型，裡面提到若 HTTP-01 不能用，還有其他選擇，例如本文要說的：DNS-01 Challenge。
DNS-01 使用原理很簡單：DNS伺服器提供ACME DNS API，讓Let’s Encrypt能夠透過API進行考驗，就能取得https證書了。
本文以google domains 為範例：
1、先建立權杖(token)
登入google domain後，點選「安全性」->ACME DNS API 「建立權杖」
此權杖只會出現一次，因此複製後，要妥善保存。
2、我想使用certbot方式取得憑證，所以到 「certbot-dns-google-domains 」github ，取得執行方式。
2.1 新增權杖檔案
vi /var/lib/letsencrypt/dns_google_domains_credentials.ini
dns_google_domains_access_token = QWVpQWZjT1xxxxxxg2N3lrMi1LUQ==
dns_google_domains_zone = test.com
2.2 docker方式執行，輕鬆取得https證書。
docker run \
-v '/var/lib/letsencrypt:/var/lib/letsencrypt' \
-v '/etc/letsencrypt:/etc/letsencrypt' \
--cap-drop=all \
ghcr.io/aaomidi/certbot-dns-google-domains:latest \
certbot certonly \
--authenticator 'dns-google-domains' \
--dns-google-domains-credentials '/var/lib/letsencrypt/dns_google_domains_credentials.ini' \
--server 'https://acme-v02.api.letsencrypt.org/directory' \
--non-interactive \
--dns-google-domains-zone 'test.com' \
-d 'xxx.test.com'
3、還有其他取得證書方式(一樣是google domain)
請參考 List of known ACME clients to work the ACME DNS API
若使用的是阿里雲解析，可參考這篇文章，我自己測試結果沒問題；提醒一下，要使用let’s encrypt，dns需要有CAA record 允許let’s encrypt 發證，否則會出現 「Verify error : CAA ……」錯誤
未免忘記，節錄一些指令；
除了指令外，還需要在阿里雲加上RAM帳號,授權該帳號能透過阿里雲OpenAPI修改DNS，
並且取得該RAM帳號「Key」與「Secret」，以下指令需要用到。
yum install socat
curl https://get.acme.sh | sh
vim /root/.acme.sh/acme.sh.env
export LE_WORKING_DIR="/root/.acme.sh"
alias acme.sh="/root/.acme.sh/acme.sh"
export Ali_Key="xxxx"
export Ali_Secret="yyyy"
source ~/.bashrc
env
acme.sh --set-default-ca --server letsencrypt
acme.sh --issue --dns dns_ali --dnssleep 180 -d xxxx.test.com
#若以上指令不行,可改以下指令
acme.sh -f --use-wget --issue --dns dns_ali --dnssleep 180 -d xxxx.test.com2023/6/16 我在RockyLinux 9.2安裝失敗出現以下問題
[Errno 13] Permission denied: '/etc/letsencrypt/.certbot.lock'
這很複雜，原因很多，我的解法如下：
解法1. selinux 放行,然後再關起門來 setenforce 0 ; docker run \ -v '/var/lib/letsencrypt:/var/lib/letsencrypt' \ -v '/etc/letsencrypt:/etc/letsencrypt' \ --cap-drop=all \ ghcr.io/aaomidi/certbot-dns-google-domains:latest \ certbot certonly \ --authenticator 'dns-google-domains' \ --dns-google-domains-credentials '/var/lib/letsencrypt/dns_google_domains_credentials.ini' \ --server 'https://acme-v02.api.letsencrypt.org/directory' \ --non-interactive \ --dns-google-domains-zone 'test.com' \ -d 'xxx.test.com' ; setenforce 1; 解法2. 確認相關套件是否安裝 dnf install httpd mod_ssl certbot --apache #若出現The requested apache plugin does not appear to be installed，則代表缺少套件 yum list installed|grep certbot certbot.noarch 2.6.0-1.el9 @epel python3-certbot.noarch 2.6.0-1.el9 @epel 這樣還缺少 python3-certbot-apache , 我再安裝一下 dnf install python3-certbot-apache
長期以來，我「HTTP反向代理伺服器」只使用「Apache Http」， 理由簡單：習慣了；然而，新興的代理伺服器總讓我有種「雖簡單卻很艱難」的感受，雖說採用新服務器是進步的象徵，但我考量自己管理的網站達數十個，非常在意網站穩定性，若貿然決定更換新「反向代理服務器」，則需要很大的勇氣，誰都無法知道被代理的服務器會不會水土不服，造成災難，因而作罷。
一般來說，apache httpd運作很穩定，沒事就不要動設定；但是我總是遇到代理服務器重啟很慢的問題，原本也沒有多想，訓練自己忍耐力XD，直到遇見”Linux技術手扎“，網站中有兩篇文章，對於apache http效能，防止阻斷攻擊(DoS)有詳細說明。我拜讀之後，受用不盡，因此也節錄下來，作為自己快速參考用。
1、解決apache http重啟慢問題
vi /usr/lib/systemd/system/httpd.service
[Service]
...
KillMode=nonesystemctl daemon-reload2、防止阻斷攻擊(Dos)
vi /etc/httpd/conf/httpd.conf
...
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500systemctl restart http想知道修改原因、運作原理，請參考網站。
我在2023年4月6日，將網站升級到6.2.0(docker版本) ： 回想起一開始升級時， 容器(container)為舊版， 我沒有採用拉取(pull)方式升級， 直接使用內建升級功能，可惜失敗了!出現找不到“sw-check-permissions-e2a8b.js”錯誤；於是我改用拉取最新容器方式升級, 而且成功了。
升級後，,我陸續寫了好幾篇文章，卻沒有發現網站已經有狀況了。直到今日(4月24日)，我在同事電腦，瀏覽自己網站時，防毒軟體居然跳出”木馬”警告，我才意識到出事了!
警告內容為「bujerdaz.com」這個網站有木馬；既然有明確網站名稱，肯定網站內有這些字眼，我馬上登入網站伺服器，搜尋了一番, 還真的有找到：
找到問題後, 接下來就是決定解決方式： 1、刪掉這一行含木馬之語法；2、查看看容器是否有最新版。
第一種做法「刪掉木馬語法」通常逼不得已才做；於是我先選擇第二種「查看容器是否有新版」，沒想到，一模一樣的6.2.0版本，居然有不同內容，這明顯是官方犯了錯誤！一般我們不會懷疑同版本容器，內容會被異動；若內容不同，必須進一個版號，並且昭告天下有修補版本! (官方並沒有說明)
這讓我以後升級需要多一個心眼，要以防毒軟體進行掃描，至少不要影響用戶端瀏覽網站。
—
2023/4/25 雖然升級新版容器，自以為問題已解決，沒想到問題還是在！仔細一看，是plugin外掛所造成的，難怪用新版容器還是無法解決，因「外掛」程式我繼續沿用，不因容器更換而刪除，當然「木馬」一直存在。我發現阻擋垃圾留言的外掛「akismet」，出現兩個版本： 一個5.0；另一個1.2。(理論上不該存在兩個版本) 版本1.2裡面寫到要連線 bujerdaz.com ，看起來應該是進行一些確認才允許留言，我認定非木馬程式，可能wordpress系統用太多年了，這次大版本升級造成兩個版本並存之現象；最後移除1.2版akismet，只留下5.0版本，就恢復正常了。另外，依照這邏輯，我的網站應該「有問題」很久了，真的很不好意思。
#wordpress
#virus
#Trojan
今天公司有個網站, 到了每三個月要更新(renew)證書的日子, 沒想到卻出現「Certificat renewal failure during secondary validation: Remote PerformValidation RPC failed」這個錯誤訊息. 開始我還以為防火牆或網頁服務器出問題, 摸索一陣子卻找不出原因 XD
這麼多年來, 頭一遭遇到這問題; 隨著同仁瘋狂反應, 我緊張到瑟瑟發抖 ! 此時, 我突然想到可以到let’s encrypt官方論壇,查看有沒有人有相同問題. 幸運的是滿滿都是問題回報;原來是官網的主機出問題, 需要30~60分鐘時間修復.
經此風波, 我覺得有必要訂定SOP,用來解決發證書所造成的問題:
第一步: 發現renew失敗, 看log(/var/log/letsencrypt/letsencrypt.log).
第二步: 查看Let’s encrypt伺服器是否正常 https://letsencrypt.status.io/
第三步: 到let’s encrypt社群看看有沒有相同的問題反映
