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真好!又推坑一家公司了.

實體主機轉換成虛擬主機準備工作(ESXi 6.5)

實體主機轉換成虛擬主機準備工作

準備軟體

  1. rufus
    用來製作usb安裝開機碟
    download url
    https://rufus.ie/zh_TW.html
  2. vmware ESXi 6.5 server
    虛擬伺服器, 一個cpu免費, 到vmware官網註冊帳號即可申請
    download url
    https://my.vmware.com/web/vmware/downloads/details?downloadGroup=ESXI650&productId=614a
  3. vmware converter
    用來將實體主機轉換成虛擬主機
    download url
    https://my.vmware.com/en/web/vmware/downloads/info/slug/infrastructure_operations_management/vmware_vcenter_converter_standalone/6_2_0

硬體

  1. usb disk x2
    一個安裝,一個開機
  2. 硬體主機
    2.1 CPU
    intel i系列支援 vt-d, vt-x功能
    2.2 RAM
    依未來虛擬主機狀況配置, 至少8GB起跳
    2.3 主機板
    請參照vmware硬體指南
    https://www.vmware.com/resources/compatibility/search.php
    2.4 儲存空間
    資料存放位置(這部分最重要)
    可選用NAS或是內建硬碟

步驟

  1. 執行rufus將下載好的esxi 6.5寫入usb磁碟
  2. 將兩個usb碟插入虛擬伺服器上
  3. 其中usb開機後, 安裝到另一個usb磁碟, 然後讓安裝完畢的usb進行開機
  4. 開機後設定適當ip
  5. 到預定轉換的主機上安裝converter, 執行converter將主機從實體轉換到虛擬伺服器上
  6. 轉換後虛擬伺服器上確認是否成功
1 ... 34 35 36 37 38 ... 73