標籤彙整: self-host

為什麼 Self-host 自架服務?

大約在一年前 2024/10 的時候,開始嘗試自架服務使用,一年後的此刻,整理一下自架的優缺點與心得。

  • Tailscale:建立一個大內網,安全的從外網連入。
  • Radicale:取代行事曆、通訊錄,支援 CalDAV、CardDAV 協定,iOS 可以整合使用。
  • FreshRSS:訂閱與管理 RSS 資訊,可以與應用程式整合。
  • Beszel:伺服器監控、歷史數據、Docker 統計與告警。
  • Open WebUI:自架 LLM、OpenAI、Anthropic 相容聊天介面。
  • Redmine:專案管理、待辦事項。
  • Memos:自架筆記、備忘。
  • WordPress:部落格、CMS。

隱私

選擇自架服務的原因在隱私,尤其平台可以把你的資料再次利用的時候,開始意識到我需要讓平台知道那麼多關於我的資訊嗎?我應該還有選擇的權力吧?而自己的資料擁有權應該屬於誰的,擁有平台的帳號應該不能表示也擁有平台,在沒有預警的情況下帳號隨時都有被停用、註銷的可能。

最後決定應該要有一個自己可以掌控資料的地方,但還有一個擔心的點跨不出去,如何安全的連回自己的主機?

Tailscale

跨出自架服務的第一步主要還是安全的考量,其次才是隱私,畢竟重要的資料是可以透過外部的網路存取到,需要特別注意是否會有任何的網站或是連線漏洞等問題。Tailscale 是一個可以突破內網(網路位址轉譯 NAT,不需要設定外部連線埠轉內部)、建立大內網域(透過 Carrier-Grade NAT, CGNAT 分配 IPs)的方式搭起一個私有網路。目前一個免費帳號可以建立 100 個連線裝置,包含行動裝置也可以安裝與納入。

Tailscale 是透過 Wireguard VPN 的技術與每個裝置建立起連線,除了每個裝置會有一個 IP 外,也可建立網域名稱並配發 SSL/TLS 憑證(Let’s Encrypt),在透過 HTTP 連線時也可以保有 HTTPS 的連線加密保障。網域的部分在後面自架服務時非常方便,憑證由於是 Let’s Encrypt 簽發的,瀏覽器可以正常識別其憑證的信任。

總之,與平時架站時設定 nginx 完全無異,甚至 80、443 連線埠都不用設定對外開放也可以連線(因為透過 NAT 的方式)。Tailscale 可以應用的方式太多了,後續會再提到!

Radicale

行事曆、通訊錄是重要隱私資訊的儲存媒介,Radicale 是支援 CalDAV、CardDAV 協定的伺服器,說伺服器有點不符合,因為他很輕量,作者當初想要挑戰用 Python 來完成一個課程的作業,想要證明用一個 Python 描述檔就可以實作完成,而作者也真的完成,後續也持續增補、修正。

iOS 也可以匯入 CalDAV、CardDAV 的協定連結,所以可以持續在「聯絡人」、「待辦事項」應用程式中使用。只是 Apple 有針對「待辦事項」額外開發的功能,如看板或子任務就無法使用。

回到隱私的考量,行事曆、通訊錄如果能夠自己掌握資料,那真的就不要放置在別人的服務中。想一想,今天如果帳號被接管了,除了郵件外,行事曆與通訊錄也是一個很重要的揭露資訊,能描繪帳號使用者輪廓的重要素材。

FreshRSS

現在還有多少人會使用 RSS 來閱讀網站更新的資訊,從以前閱讀網站資訊的時候都習慣訂閱該網站 RSS 資訊,從最早 Google Reader、Feedly,到此刻也因為隱私考量,自架服務使用 FreshRSS。

FreshRSS 雖然介面看起來停留在上一個世代,但其功能不因此打折扣,重點是很多行動裝置的應用程式都有支援與 FreshRSS API 溝通,所以可以再搭配一個額外的應用程式來閱讀或管理。我自己就購買 Reeder 在 iOS 上閱讀或是訂閱、在瀏覽器上一個分頁固定給 FreshRSS 持續收取最新資訊。

題外話,關於 RSS 的使用,現在也越來越多人思考是不是要回到這樣單純閱讀資訊的方式,我們要的究竟是把使用者努力帶來網站上做什麼?還是讓我們想要說的資訊傳遞出去呢?(通常努力把人帶回到網站是因為想透過網站上的廣告獲利)

Beszel

Beszel 是輕量監控平台,由彙整儀表板(Hub)與裝在被監控主機(Agent)組成。可檢視 CPU、記憶體、磁碟、網路、Conatainer 歷史與警示通知。

不需對外開 port,直接走 Tailscale 內網就可以,自架服務一多,總是要有個地方可以集中看「誰在跑、網路流量、有沒有異常」。文件與說明:https://beszel.dev

Memos

Memos 是自架筆記、備忘服務,隱私優先、無追蹤、支援 Markdown。思考、靈感或隨手紀錄的文字放在自己主機,不依賴其他第三方服務。與前面 Radicale、FreshRSS 屬於 DeGoogle 計畫中的一環。

Memos 雖然在行動裝置上可以直接用網頁開啟使用,但也有應用程式版本可以使用:iOSAndriod

Open WebUI

自架 LLM 聊天介面,可接本地或遠端 API(如 Ollama、OpenAI 相容端點)。對話內容與 prompt 不經過第三方,模型可跑在自己機器或你信任的端點。另一方面,透過 API 的方式連結語言模型所得到的回覆比較不會參雜個人化的設定在其中,或許現在使用 web 或 app 的方式有改善,但當初選擇自建立的時候是遇到很明顯的喜好記憶問題。

現在主要是串接 OpenAI、Antropic 的 API 使用,用在翻譯、寫作建議、問問題或是純粹閒聊的情境上。串接本的 Ollama 反而受限於主機硬體關係沒有使用。(open-webui

Redmine

專案管理、議題追蹤、甘特圖、自架替代 Jira、Linear 等。專案與待辦留在自己環境,適合個人或小團隊。我會在專案層級用 Redmine、個人待辦用 Radicale。(Redmine)。

Redmine 是一個很老牌的開源專案管理服務,我自己手邊如果有跨季度的專案,執行過程中需要依進度切割的話,我會用 Redmine 來協助我規劃與導航。用習慣後發現,單純的介面比較不會影響規劃時的思緒。

WordPress

之前是透過 Blogger 來寫文章,但後來平台看起來都沒有開發新功能,我自己也停了一段時間沒有寫文章,就這樣荒廢很久。直到最近想要恢復寫文章分享、紀錄的習慣。也有考慮一些可以產生靜態網站的,但看到 WordPress 越來越好用,就選擇自己來架一個用看看。

目前沒有裝太多的套件,基本款的 WordPress 已經算很好用了,文字編輯介面也滿好處理一些格式或區塊的問題,內建的版面外觀也滿好用的,調整好一個比較好看的版面後就專心寫文字。

唯一會擔心一點的部分是常常會聽到一些零時的漏洞問題,但因為前面有用 Cloudflare 擋一下,雖然不是萬無一失,但至少可以減少一些風險。

最後

自架服務一年後,除了隱私的考量外,希望可以有一個自己可以掌控資料的地方,一方面也是要測試去 Google 服務或是降低對其他平台的依賴。另外也是因為 Tailscale 的關係,可以建立一個大內網,安全的從外網連入,讓在一台主機上架設多個服務變得更加方便。

Stalwart 開源郵件伺服器即將發佈 1.0 版本,成為第一個實作 JMAP 協議的郵件伺服器

雖然現在已經很少人自架郵件伺服器了,但是一款開源的郵件伺服器軟體 Stalwart 完成了 JMAP 的實作!這篇文章介紹了 Stalwart Labs 一個重大里程碑:完成 JMAP 用於行事曆、聯絡人、地址簿、檔案儲存及分享的完整實作,使 Stalwart 成為首個支援完整 JMAP 協作協議的郵件伺服器。

完整的文章內容: https://stalw.art/blog/jmap-collaboration

  • 新一代協議:JMAP 包括用於行事曆、聯絡人、檔案儲存及分享的新協議,目標取代傳統的 WebDAV 技術如 CalDAV 和 CardDAV,並引入 JSCalendar 和 JSContact 作為 iCalendar 和 vCard 的繼承者。這些新標準提供一致且優雅的生態系統。
  • 舊技術的限制:傳統的 WebDAV 及其延伸技術因 XML 設計的複雜性,導致實施困難且互通性差。iCalendar 和 vCard 的技術負擔也使這些格式難以維護。
  • JMAP 的現代解決方案:JMAP 協議以 JSON 為基礎,透過 HTTPS 提供高效且清晰的 API,用於郵件、行事曆、聯絡人及檔案分享,簡化協作技術實作,提升可讀性與解析效率。這次發佈不僅帶來新功能,更改變了群件協議的設計和實作方式,對開發者和組織而言意味著更簡單、更少的互通性問題,並加速創新。
  • 客戶端支援與生態系統:目前已有幾個專案(如 Mailtemi、Parula 和 OpenCloud)在開發 JMAP 的客戶端實作,預期 JMAP 會快速被採用。
  • 感謝及未來展望:感謝 NLNet 對 JMAP 開發的支持。Stalwart 開發團隊將致力於性能優化和增強功能,目標在未來幾個月內推出正式的 1.0.0 版本,樹立開放且現代化的郵件通信伺服器新標準。

前幾個月有把 Stalwart 架起來,很難想像在此刻架一台郵件伺服器能有多難,但再往前跨一步出去後發現,很多雲端服務如 AWSDigitalOcean 將 25, 465, 587 連線埠給關閉或不提供 IP 反向解析1(PTR/RDNS),即使架好了也無法與其他郵件伺服器溝通,或許當越來越多人使用 Stalwart 後這個問題有可能會被克服,我很期待可以自己架設郵件伺服器!


  1. 設定 IP 反向解析(PTR/RDNS)有助於驗證發信伺服器的真實身份,提高郵件的可信度並減少被標記為垃圾郵件的風險,確保郵件順利地送達收件者的主要信箱,提升整體郵件的可交付性。 ↩︎

開源自架服務 immich 被 Google 安全瀏覽誤判為「危險」網站

Google 提供一項名為「安全瀏覽(Google Safe Browsing)」的服務,用來檢測網站是否存在惡意軟體、不受歡迎的軟體或從事某種社交工程行為。不過,對於如何判斷網站是否「危險」的細節仍然不太清楚。這導致使用 Google 安全瀏覽服務的瀏覽器(如 Chrome 和 Firefox)會自動警告使用者,除非少數人忽視這樣的警告,否則這些網站幾乎無法被訪問。

而近期一款開源自架的照片、影片管理軟體 immich,因為自家的 Demo 網站被標記為危險,影響到整個網域的使用。immich 解釋如何透過 Google 的申訴管道提出恢復,但恢復之後所產生的頁面也再次被標記危險。結論提到目前像是可自架服務的 NextCloud、n8n、Jellyfin …… 等,都會有這樣發生的可能,對於開源、自架環境是一個潛在的阻礙

有興趣可以閱讀完整內容:https://immich.app/blog/google-flags-immich-as-dangerous


查了一下 Google Safe Browsing 沒有公開名單讓人查閱哪些網站被放入,只有一個查詢的網站可以使用,雖然我自己不是用 Chrome,但其他使用者以目前 Chrome 的市占率,其影響不容小覷。

這樣的審查模式與臺灣之前討論 RPZ 類似,一樣也是不公佈名單,但 Google 比較麻煩的部分是評判標準不明,然後又常常誤判,申訴後也不知道何時可以恢復,如果真的遇到誤判,還真的不知道該如何面對。

之前作過一個內部系統,也是遇到這樣的問題,想說臨時換一個網域應該可以解決,但又馬上被判定「危險」,最後只能請使用者關閉「安全瀏覽」檢查的功能,還好不是面對外部的使用者,可以這樣一一通知暫時解法使用。