pve maintenance mode
先前遇到一件事情, 其實說來話長, 也是因為covid-19造成的
因為無法親自到公司越南廠處理pve server, 偏偏又遇到pve不穩的狀況, 只好移除一些當時手動掛載的硬碟.
這下好了, 請當地的電腦公司人硬是移除手動掛載的硬碟 , 重開機後發現總是進入maintenance mode,
搞了好久才發現必須把/etc/fstab 的手動掛載硬碟資訊移除, 才能正常開機, 因此紀錄一下,以免重蹈覆轍.
先前遇到一件事情, 其實說來話長, 也是因為covid-19造成的
因為無法親自到公司越南廠處理pve server, 偏偏又遇到pve不穩的狀況, 只好移除一些當時手動掛載的硬碟.
這下好了, 請當地的電腦公司人硬是移除手動掛載的硬碟 , 重開機後發現總是進入maintenance mode,
搞了好久才發現必須把/etc/fstab 的手動掛載硬碟資訊移除, 才能正常開機, 因此紀錄一下,以免重蹈覆轍.
我自己在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有兩個, 一個是吉茶(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
原本用習慣的git server gitblit , 在2016年發表1.8.0版本之後, 原創者就不再更新, 當時也因為參與修改幾個bug,以及中文化花了不少心血, 覺得非常可惜, 撐到2018年之後, 覺得該專案不再更新, 安全性與bug都無法處理, 就毅然決然改用gitea 吉茶.
用了吉茶之後, 發現非常不能適應, 吉茶並沒有多子目錄的設計 , 方便我們建立階層式管理專案, 例如我要建立it部門, 吉碧麗除了畫面會分類成it之外, 連網址都與分類一致, https://yyy.zzz/r/it/xxx.git , 非常直覺.
吉茶則是團隊, 群組的概念, 對於專案的分類並沒有這樣的設計, 應該都儘量與github相同,程式師才會容易上手.
至於gitlab有分類,但似乎只能一層,無法達到gitblit的多子階層的功能.
以下是docker安裝吉碧麗的步驟:
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
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 注意事項
netsh interface portproxy add v4tov4 listenport=<本機port> listenaddress=<本機ip> connectport=<forward ip port> connectaddress=<forward ip>
在這虛擬化盛行的年代, 偏偏就有很多軟體開發商, 還在抗拒虛擬化, 害怕一旦虛擬化後,將更容易被盜用,造成損失.
他們的做法主要有二,
一是綁定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真好!又推坑一家公司了.
其實我也很不懂vim的v-mode , virsual mode , 反正屎用docker時候, 好多container 需要另外安裝vim ,
安裝結束後, 我就卡關了 XD ,
因為我習慣按滑鼠右鍵, 就把複製的文字貼上去 , 但是常常出現(insert) virsual 錯誤無法貼上
網上找了好久, 找到一種方式, 輸入 set mouse-=a , 就可以解決了