SSH SFTP設定 先新增一個群組，提供給 sftp 使用者 $ sudo groupadd sftpusers 新增 sftp 的使用者 $ sudo useradd -g sftpusers -d /incoming -s /sbin/nologin [username] $ sudo passwd [username] 建立 sftpuser 的 root 目錄 /home/sftp/ $ sudo mkdir -p /home/sftp/[username]/incoming 將 incoming 的目錄權限設定給 user $ sudo chown [username]:sftpuse /home/sftp/[username]/incoming/ 確認一下是否有設定正確 $ ls -ld /home/sftp/arcsight/incoming/ 情境需求 限制使用者登入 限制 IP 位置 限制目錄位置 限制只能使用 SFTP $ ls -ld /home/sftp/<UserName>/ $ ls -ld /home/sftp/ ＃只允許特定使用者登入 AllowUsers arcsight root ＃只允許用10.
通常做好的 docker image 都是直接往 docker hub 丟，但是如果要在內部架設使用，又有一些安全或隱私的問題 就需要一個存放私人 docker image 的地方，最終讓我找到這個避風港 Hardware Resource Minimum Recommended CPU 2 CPU 4 CPU Mem 4 GB 8 GB Disk 40 GB 160 GB Dependencies ntp swapoff Remove any matching reference found in /etc/fstab swapoff -a Docker version 17.06.0-ce+ Docker Engine overview | Docker Documentation Docker-compose 1.18.0+ Install Docker Compose | Docker Documentation Openssl python 36 python 36 for centOS 7 Install 1 2 3 4 5 6 7 8 9 10 11 12 13 yum install epel-release yum install python36 rm -rf /usr/bin/python ln -s /usr/bin/python3 /usr/bin/python # install pip3 python3 -m ensurepip # update pip3 pip3 install --upgrade pip Fix change /usr/bin/python to /usr/bin/python2.
Github 有一個限制，就是當單檔案大於 100M 時，就會使用到 LFS 的儲存空建，並且上限是 5GB 我是窮苦人家，只能土法煉鋼自己架設 LFS Server Required 從 https://git-lfs.com/ 這裡下載並安裝 git-lfs
Gitea 我是在 TrueNAS Scale 上安裝 Gitea 的，至於安裝過程可以參考 Self Hosting Gitea On TrueNAS Scale With Working SSH Access
然而我覺得純粹充當 LFS Server 有點浪費，所以我覺得可以搭配異地備份的概念
讓 Gitea 定時從 Github 將專案抓回來，但指定 Gitea LFS 為 Gitea 和 Github 共同的位置
LFS 在 repo 底下
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 # 初始化 git lfs install # 設定 Git LFS 位置 git config -f .
TrueNAS Scale 從 2022/02 推出以後到現在也歷經 10 個月 想說那就來把我的 TrueNAS Core 升級至 Scale，畢竟我還是對於 Linux 比較熟悉 雖然 TrueNAS Core 碰了一些 FreeBSD，但我還是比較喜歡 Linux，加上還有 K3S 可以用 Prepare 首先根據官網的說明 Migrating from TrueNAS CORE
TrueNAS systems on 12.0x or lower should update to the latest CORE 13.0 release (e.g 13.0-U2) prior to migrating to SCALE.
我必須先將我的 TrueNAS Core - 12 更新至 13，然後再下載 TrueNAS Scale iso 進行更新
Upgrade 基本上官方網站寫的很詳細 Migrating from TrueNAS CORE 完全可以照著進行
選擇 Install/Upgrade 仔細仔細仔細，不要選到儲存碟
為了解決網路程式的收發效能，根據三個面向進行研究 分別是系統、程式、硬體三個面向 程式面向 程式處理邏輯優化，縮短處理下一包的時間 使用多核效能，更改成多進程或多執行序，同時以參考 Reactor、Proactor 等模型架構，不一定要採用 透過 SO_REUSEPORT 搭配 RSS 進行有效的 CPU 使用 系統面向 系統層的優化，分別針對收容能力及核心分配做處理
收容能力 不用無條件的往上增加，而是增對需求條件進行調校，因為不單單只有收容能力需要調整
1 2 3 4 5 6 # 增加對 NIC Ring Buffer 的抓取的 CPU 資源，預設 300 net.core.netdev_budget=900 # 寫入的 Socket Buffer net.core.wmem_max=20971520 # 接收的 Socket Buffer net.core.rmem_max=20971520 核心分配 若為多行程/多進程設計，並有搭配 REUSEPORT，則可以降低 CPU 分配
透過 taskset、isolation、cgroup 進行分配、隔離、綁定
硬體面向 透過支援的網卡設定 Receive Side Scaling (RSS)，並透過 SO_REUSEPORT 的搭配，使 CPU 有效分配 RSS 這邊簡端說明，NIC 隊列通道會是一個以上，預設可能只用一個
可以啟用多個通道進行接收並搭配多個 CPU，達到更高的接收、發送效能
有興趣的可以閱讀 Linux Network Scaling: Receiving Packets
不想透過純命令的方式去合併 Git Commits，操作起來很不直觀 想透過 VScode 直接將 Git Commits 合併成一個 Commit 套件 圖形化的 Git Commits
VScode Extension - Git Graph VScode 設定 開啟 設定 並搜尋 git force，然後開啟 Git: Allow Force Push
合併 Commits 首先進入到 VScode 的 Git 控制頁面，然後選擇 View Git Graph 的 Icon
然後可以看到 Commits 圖形化，然後選擇欲合併的 Commit
選擇 Reset Current Branch to this Commit…
然後這邊選擇 Mixed
然後會看到建立一個本地分支
這時候會看到之前變更過的檔案需要重新提交
然後會看到合併之後的提交
最後透過 推送(強制更新) / Push(Force) 進行推送
最終就會看到提交合併了，Github 上也是如此
Ref Github - Squashing commits Dannyherran - Git squash commits in VS Code
Wordpress 的頁面不會時常更新，希望透過緩存的方式減少不必要的損耗，並同時加速頁面載入速度 雖然 Wordpress 有眾多的緩存插件可以使用，但用起來的效果感覺都沒有很好，所以決定用 Nginx 來實現緩存 環境 Ubuntu - 20.04 LTS Nginx - 1.18.0 (Ubuntu) nginx-cache-purge - 0.1.8 Lua - 5.2.4 實現 Nginx 緩存 一個最基本的 Wordpress 的反向代理設定
1 2 3 4 5 6 7 8 9 10 11 http { server { listen 80; server_name domain.com; location / { proxy_hide_header X-Frame-Options; proxy_pass http://192.168.0.100; } } } 設定緩存路徑及緩存鍵名 proxy_cache_path <path> [levels=levels] keys_zone=name:size [inactive=time] [max_size=size] [use_temp_path=on|off]; <path>: 設定代理緩存位置的相關設定為 /var/run/proxy_cache
levels: 設定目錄結構，例如 1:2，總共用了兩層目錄，第一層目錄單個 16 進制命名，第二層為兩個 16 進制命名
前言 UDP 若發生丟包，往往會認為封包遺失在路上，然而需要因環境架構來進行判斷
若發生問題的在一個大量的高速 UDP 的環境，則狀況可能會更加複雜，但往往事實出乎意料
知識 接收 網卡接收封包存入 Ring Buffer 然後透過 Kernel 存入 Socket Buffer 然後 Application 再從 Socket Buffer 取出封包
傳出 APP 將封包透過系統調用執行 sendTo 經歷 UDP封裝、IP封裝後進入 Socket Buffer，然後經由 Traffic Control 的 Qdisc(Classless Queuing Disciplines)，而 Qdisc 會有一套傳輸的規則，符合規則才從 Ring Buffer 透過網卡送出
發生原因 傳送方 UDP 傳送速率太快受到 Qdisc 規則限制 TX Ring Buffer 太小 Socket Buffer 太小 接收方 RX Ring Buffer 太小 Socket Buffer 太小 App 處理太慢 檢查流程 確認網路協議統計 UDP 是否出現丟包 buffer errors 是否不為 0