cetnos 7 + postfix 新增dkim功能

  1. 安裝

rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum install -y opendkim

  1. 產生private key與dns的TXT Record

opendkim-genkey -d <domain name>
cp default.* /etc/opendkim/keys
chown -R opendkim:opendkim /etc/opendkim

  1. 修改/etc/opendkim.conf
    確認該設定檔案有以下的設定( KeyFile /etc/opendkim/keys/default.private 要mark起來 )

Mode sv
Socket inet:8891@127.0.0.1
Canonicalization relaxed/simple
Domain <domain name>
#KeyFile /etc/opendkim/keys/default.private
KeyTable refile:/etc/opendkim/KeyTable
#ps 若使用測試軟體出現invalid data set, 請改成 KeyTable /etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
ExternalIgnoreList refile:/etc/opendkim/TrustedHosts
InternalHosts refile:/etc/opendkim/TrustedHosts

  1. 修改 /etc/opendkim/KeyTable

default._domainkey.<domain name> <domain name>:default:/etc/opendkim/keys/default.private

以 test.com 為例子

default._domainkey.test.com test.com:default:/etc/opendkim/keys/default.private

  1. 修改 /etc/opendkim/SigningTable

*@<domain name> default._domainkey.<domain name>

以test.com為例子

*@test.com default._domainkey.test.com

  1. 修改 /etc/opendkim/TrustedHosts

127.0.0.1
<mail host name>
<domain name>

以 test.com 為例子

127.0.0.1
mail.test.com
test.com

  1. 新增以下設定 /etc/postfix/main.cf

smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters
milter_default_action = accept

  1. 將/etc/opendkim/key/default.txt的資料更新到dns上

  2. 啟用service

systemctl start opendkim ; systemctl enable opendkim ; systemctl restart postfix

  1. 測試
    • opendkim-testkey -x /etc/opendkim.conf 若無錯誤訊息代表成功
    • 測試網站 https://www.appmaildev.com/

pve maintenance mode

先前遇到一件事情, 其實說來話長, 也是因為covid-19造成的
因為無法親自到公司越南廠處理pve server, 偏偏又遇到pve不穩的狀況, 只好移除一些當時手動掛載的硬碟.

這下好了, 請當地的電腦公司人硬是移除手動掛載的硬碟 , 重開機後發現總是進入maintenance mode,
搞了好久才發現必須把/etc/fstab 的手動掛載硬碟資訊移除, 才能正常開機, 因此紀錄一下,以免重蹈覆轍.

pve 6上調整zfs快取大小

我自己在pve 6上使用zfs的經驗不是很順利;有遇到慢的、不穩的,現在可能還需要調整zfs的快取大小,才能讓zfs順利使用。
新增一個檔案 /etc/modprobe.d/zfs.conf
並修改如下:

範例為最小4G, 最大16G, 可自行依照主機實力設定,千萬不可多。 修改後重開機, 可下arcstat 查詢是否成功

options zfs zfs_arc_min=4294967296
options zfs zfs_arc_max=17179869184
options zfs zfs_flags=0x10

git server移轉注意事項

我工作上用的git server有兩個, 一個是吉茶(gitea), 另一個是吉累(gitlab), 因為重新使用吉碧麗(gitblit), 所以將吉累狠心地關閉, 因為他功能太多, 架構龐大, 太耗資源, 願意用的原因只有一個, 就是分類的方式比吉茶好, 現在終於來了一個分類更強的server – gitblit.

我將gitlab上面的git專案, 直接複製到gitblit 目錄上, 一切正常, 但卻遇到 lfs 檔案移轉失敗的現象, 也就是gitblit上面的lfs並無法真正的指向檔案實體位置, 全部都是空的.

我嘗試很多指令想解決這問題, 如 git lfs clean , git lfs pust –all 等等要麻就是無反應timeout, 要麻就是出現檔案不存在等等奇怪現象, 皇天不負苦心人, 我終於爬文爬到有位專家 https://github.com/sprohaska 提出解法 https://github.com/git-lfs/git-lfs/issues/1113 , 最後如願從client端將大檔案正確的放到新的gitblit上, 指令如下:

git lfs ls-files -l | awk '{ print $1 }' | xargs git lfs push --object-id origin

再次擁抱-吉碧麗gitblit – git server 使用docker

原本用習慣的git server gitblit , 在2016年發表1.8.0版本之後, 原創者就不再更新, 當時也因為參與修改幾個bug,以及中文化花了不少心血, 覺得非常可惜, 撐到2018年之後, 覺得該專案不再更新, 安全性與bug都無法處理, 就毅然決然改用gitea 吉茶.

用了吉茶之後, 發現非常不能適應, 吉茶並沒有多子目錄的設計 , 方便我們建立階層式管理專案, 例如我要建立it部門, 吉碧麗除了畫面會分類成it之外, 連網址都與分類一致, https://yyy.zzz/r/it/xxx.git , 非常直覺.
吉茶則是團隊, 群組的概念, 對於專案的分類並沒有這樣的設計, 應該都儘量與github相同,程式師才會容易上手.
至於gitlab有分類,但似乎只能一層,無法達到gitblit的多子階層的功能.

以下是docker安裝吉碧麗的步驟:

  1. 官網
    https://github.com/gitblit/gitblit-docker
  2. 設定volume之後, 啟動gitblit , 指令的port隨時可改, 預設帳密都是admin , 登入後請馬上更改
    docker volume create gitblit-etc
    docker volume create gitblit-data
    docker run -d --restart always --name gitblit -v gitblit-data:/var/opt/gitblit/srv -v gitblit-etc:/var/opt/gitblit/etc -p 8443:8443 -p 8089:8080 -p 9418:9418 -p 29418:29418 gitblit/gitblit:latest

安裝PVE 注意事項

PVE8 注意事項(2023-8-11)

1. 修改 /etc/apt/sources.list.d/ceph.list
#若沒有訂閱,請全部加上 #
#deb https://enterprise.proxmox.com/debian/ceph-quincy bookworm enterprise
2. 修改/etc/apt/sources.list.d/pve-enterprise.list
#deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise
#deb http://enterprise.proxmox.com/debian/pve bookworm pve-no-subscription
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
deb http://ftp.debian.org/debian bookworm main contrib
deb http://ftp.debian.org/debian bookworm-updates main contrib
deb http://security.debian.org/debian-security bookworm-security main contrib

接下來執行apt update;apt upgrade就可以了


PVE 6 注意事項

  1. 設定自動更新
    修改/etc/apt/sources.list.d/ 裡面的檔案

    deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise
    改成
    deb http://enterprise.proxmox.com/debian/pve buster pve-no-subscription
    請注意免費版是存取http, 非訂閱版的https , buster 代表pve 6版
    修改完畢, 執行 apt update ; apt upgrade
  2. 建議安裝套件
    apt install multipath-tools lsscsi
  3. ZFS相關(2023-01-07 安裝pve 7.3時若zfs停止同步功能,會遇到當機)
    *若使用內建的zfs功能, 請考慮關掉sync功能,避免讀取過慢,造成當機
    執行
    #zfs list 取得raid pool name
    zfs list
    zfs set sync=disabled <raid pool name>
    zfs get sync <raid pool name>

    *若zfs壞了, 無法zpool import , 有時候可以清除label , 並且以readonly掛載起來
    zpool labelclear /dev/sda
    zpool import  -f -o readonly=on  <zfs pool name>
  4. 掛載硬碟到directory, 反悔解除後上面的路徑還在
    此時可以到/etc/systemd/system把該硬碟的檔案刪除, 重新刷新pve,就不會出現了
  5. 以後想到會補充在這裡

Promox VE神救援的故事, workflow GP 3.1

在這虛擬化盛行的年代, 偏偏就有很多軟體開發商, 還在抗拒虛擬化, 害怕一旦虛擬化後,將更容易被盜用,造成損失.

他們的做法主要有二,
一是綁定usb key , 讓你虛擬化後,還是得依賴usb key;
另一是軟體自行偵測是否處在虛擬環境, 若是就拒絕運行,有些則是偵測後,最後還是綁定一台實體主機, 進行授權檢查.

其實在我看來, 他們就是打著反盜版侵權的旗幟, 實際上強力控制客戶.

以台灣最有名的ERP廠商為例子 , 朋友10年前購買workflow GP 3.1 , 當時並沒有告知會鎖定實體主機, 直到朋友公司因為主機老舊,需要重新安裝, 卻出現安裝到虛擬伺服器上, 無法使用的情形, 詢問後, 才知道必須另外在一台實體主機上安裝授權程式, 並且支付ERP廠商”產生“授權序號的費用, 才能使用.

ERP廠商說得好聽就是請記得購買維護, 這些都可以免費協助, 說難聽就是要綁架,要控制這家公司的, 強力取得維護.

其實老實說, 大部分的公司都願意購買維護, 大可不需要用這種手段, 讓IT難為.

萬一實體主機壞了, 系統就停擺, 要等他們處理, 但他們卻沒有想過, 萬一產品停產, 不再維護, 或公司倒了怎麼辦?

後來我跟朋友在一個場合遇到, 才聊到他的問題, 於是我就幫忙檢視一下, 朋友公司使用ESXi 6.5 , 真的無法運行, 仿間小技巧都無法騙過ERP軟體的偵測.

我左思右想,居然橫空出現一個想法, 2010那個年代, 大部分的IT只知道vmware出的虛擬伺服器, 因此我猜測ERP廠商大概也就只會偵測vmware, 並不會偵測qemu , promox ve.

嘿嘿, 於是我立馬安裝了promox ve這個虛擬伺服器系統, 再重建workflow erp系統, 果然成功了, erp軟體一點都沒發現身處虛擬環境, 運行正常.

後話, 我還是建議朋友購買維護, 畢竟他們的ERP專業很夠, 但系統建置這方面就小鼻子小眼睛, 就讓人非常不認同.

會用到這類軟體的公司, 營收都是億來億去, 豈會虛擬化後, 還複製到別處使用, 況且這樣的軟體,一般還要經過上課, 顧問輔導, 系統開帳才有辦法使用, 會願意這樣做的公司, 還會盜用?

系統移轉在驚喜中完成,有promox ve真好!又推坑一家公司了.

1 ... 34 35 36 37 38 ... 73