Posted on

wordpress 永久連結設定失效

故障的可能原因

  1. .htaccess 檔案不正常:進入 WordPress 的管理後台,點擊「設定」→「連結」,然後按下「儲存變更」。這樣 WordPress 會重新生成 .htaccess 檔案。如果這個步驟沒有解決問題,可以手動在 WordPress 安裝目錄中找到 .htaccess 檔案,並且檢查它是否存在。
  2. 確認 WordPress 是否在正確的網址上運行:如果您的 WordPress 安裝在子目錄或子網域下,請確認永久連結設定正確設定到子目錄下這一點。
  3. 伺服器是否支援永久連結:如果您的伺服器不支援永久連結,則 WordPress 將無法使用它們。(設定方式請見下一篇)
  4. 確認您的主題是否有任何問題:某些 WordPress 主題可能會干擾永久連結的正常運作。嘗試暫時更換到 WordPress 默認主題並再次測試永久連結。

在Apache2支持永久連結

要啟用 Apache2 的 mod_rewrite 模組,您需要將以下內容添加到 Apache2 的設定檔案中:

LoadModule rewrite_module modules/mod_rewrite.so

這個設定通常會加入到 mods-enabled 目錄中的一個設定檔案中。例如,您可以創建一個名為 rewrite.load 的檔案,並將上面的設定添加到這個檔案中。請按照以下步驟進行操作:

  1. 進入 mods-enabled 目錄:
cd /etc/apache2/mods-available
  1. 創建一個名為 rewrite.load 的檔案:
sudo touch rewrite.load
  1. 打開這個檔案並添加以下內容:
LoadModule rewrite_module modules/mod_rewrite.so
  1. 儲存並關閉檔案。
  2. 重新啟動 Apache2 伺服器,以使更改生效:
sudo service apache2 restart

啟用rewrite功能

若您的 /etc/apache2/mods-available 目錄下已經有了 rewrite.load 設定檔案,您可以透過建立符號連結方式來啟用 mod_rewrite 模組。

請按照以下步驟:

  1. 進入到 /etc/apache2/mods-enabled 目錄:
cd /etc/apache2/mods-enabled
  1. 建立 rewrite.load 的符號連結:
sudo ln -s /etc/apache2/mods-available/rewrite.load
  1. 重新啟動 Apache2 伺服器,以使更改生效:
sudo service apache2 restart

執行完上述步驟後,Apache2 的 mod_rewrite 模組即會啟用。您可以再次檢查 /etc/apache2/mods-enabled 目錄,確保 rewrite.load 的符號連結已經建立。若您需要停用 mod_rewrite,則可以刪除這個符號連結即可。

Posted on

在AWS的EC2裡加上SSL/TSL

SSL/TSL是甚麼

SSL/TLS是一種網絡協議,用於在客戶端和服務器之間提供安全的數據傳輸。 SSL代表“安全套接字層”,TLS代表“傳輸層安全性”,兩者是相似的協議,TLS是SSL的升級版。

SSL/TLS通過加密數據流來保護通信的隱私和完整性,以防止數據在傳輸過程中被竊聽或篡改。它使用數字證書來驗證服務器身份,以確保連接到的服務器是預期的服務器,而不是惡意者偽裝的服務器。

SSL/TLS廣泛用於保護網站,電子郵件,即時通訊,虛擬專用網絡(VPN)等應用程序中的數據傳輸。通過使用SSL/TLS,這些應用程序能夠提供更安全的通信,確保用戶的數據受到保護。

我的伺服器環境

這邊所說的是自架的Linux服務器的狀況,一般若是在網域託管的服務商買網站空間,使用cPanel等管理網站的狀況下,一般都會在空間購買裡面附設有免費的SSL/TSL證書,除非我們的網站需要額外的附加資訊才需要自行購買。

這篇文章所講的主要是當我們要在Linux裡面自行設定SSL/TSL,或使用AWS、Azure等服務的虛擬機器架設網站時,會需要自行於Linux中建立SSL/TSL並匯入所需的SSL/TSL認證。

在AWS中使用免費的ACM證書

這邊有很詳細的指導: 教學課程: 在 Amazon Linux 2 上設定 SSL/TLS

但是這邊的教程在後面匯入SSL證書的部分,是要我們自己去購買自己網域專屬的證書,那個很貴而且不太能夠免費,一般免費的SSL/TSL其組織等資訊並不會附在上面,如下圖為AWS所提供的免費證書。

要使用免費證書一個重要的前提就是要將我們所購買的網域給AWS的Route 53來託管,這個動作會產生微量的費用,一個月為0.51美金。

在AWS裡面,有一些服務本身就可以直接和Route53,若是沒辦法,則要另外建立 Elastic Load Balancing,這個是免費的,它可以用來連結我們的EC2和Route53,這樣就可以利用ACM來設定憑證了。

Posted on

在CentOS 7的Xampp中使用Certbot

Certbot介紹

Certbot是一個由EFF(Electronic Frontier Foundation)開發的免費開源工具,用於自動化在Web服務器上部署SSL/TLS證書。它是一個自動化的客戶端,可以讓您輕鬆獲得免費的SSL/TLS證書,以保護您的網站通信,避免了手動創建證書的複雜過程。

Certbot支持多種服務器軟件,包括Apache、Nginx、HAProxy、Amazon Web Services等,它使用ACME(自動化證書管理環境)協議從Let’s Encrypt證書頒發機構獲取SSL/TLS證書。使用Certbot,您可以輕鬆地為您的網站啟用HTTPS協議,提高網站的安全性和可靠性。

如何安裝

CerBot的安裝很貼心,在官方網站就可以選擇你所使用的環境,然後他就會有很詳細的安裝教學了

官方網站: https://certbot.eff.org/

使用XAMPP的認證指令

若是要認證XAMPP的APACHE,不能直接使用–apache,而是要使用apache-ctl,如下:

sudo certbot certonly --webroot --apache-ctl /opt/lampp/bin/apachectl

錯誤訊息除錯 – Could not find configuration root

下面這個錯誤訊息代表這個認證機器人不知道你的網站的本地端http files靜態路徑的位置

packages/certbot_apache/_internal/parser.py", line 924, in _find_config_root
    raise errors.NoInstallationError("Could not find configuration root")
certbot.errors.NoInstallationError: Could not find configuration root

解決方法: 在執行指令的時候告知http files靜態路徑的位置

sudo certbot certonly --webroot --apache-ctl /opt/lampp/bin/apachectl

或者

sudo certbot renew --webroot -w /var/www/html/

錯誤訊息除錯 – Please add a virtual host for port 80

ERROR:certbot._internal.log:Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80.

這個錯誤提示表明Certbot無法在端口80上找到正在偵聽的虛擬主機,以便證明您控制域名。這是因為Certbot需要在域名的80端口上創建一個臨時HTTP服務器來進行驗證,以證明您控制該域名。

要解決這個問題,您需要在Apache服務器上為端口80添加虛擬主機配置。

/opt/lampp/apache2/conf/httpd.conf添加以下內容

<VirtualHost *:80>
    ServerAdmin your-email@example.com
    ServerName your-domain.com
    DocumentRoot /var/www/html
</VirtualHost>

接著重啟XAMPP

sudo /opt/lampp/lampp stop
sudo /opt/lampp/lampp start

或者

sudo service apache2 restart

其他除錯方向

  1. 防火牆沒有開:可以在本機中用curl去打IP,和從外面打,若是裡面可以外面不行,代表防火牆沒有開
  2. httpd設定只有localhost可存取: 應要把權限設定為”require all granted”。可用下面指令去搜尋電腦的httpd.conf的位置,並且尋找是不是你的網站被設定為”Require local”
sudo find / -name httpd.conf

成功拿到Certbot的SSL/TSL憑證

會可以看到下面的訊息,或許我們會懷疑為什麼都是pem,而不是.crt和.key,這是因為SSL/TLS憑證的格式可以有很多種,其中PEM格式是其中一種常見的格式,而.crt和.key則是PEM格式的一種變體。

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/bliss-angel.org/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/bliss-angel.org/privkey.pem

PEM格式是一種基於Base64編碼的標準格式,可以將數字證書和私鑰等敏感信息以文本格式表示出來,同時保持數據的可讀性。PEM格式的憑證通常以”.pem”為文件擴展名,可以包含公鑰、私鑰、憑證鏈等信息。

而.crt和.key則是PEM格式的一種變體,.crt檔案包含數字證書,.key檔案包含私鑰。這兩種檔案格式同樣是基於Base64編碼的PEM格式,只是文件名和內容有所不同。

為什麼有時候會看到PEM格式的憑證而不是.crt和.key檔案呢?這是因為PEM格式憑證可以包含多種類型的數字證書和私鑰,而且可以被用於多種網絡應用程序。例如,在OpenSSL等工具中,PEM格式憑證可以用於SSL/TLS加密、S/MIME郵件加密、SSH服務器驗證等方面。

因此,當你拿到一個PEM格式的憑證時,可以通過文件內容判斷它所包含的數字證書或私鑰類型。如果你需要將PEM格式憑證轉換成.crt和.key檔案,你可以使用OpenSSL等工具進行轉換。

但是這不影響的,仍然可以在/opt/lampp/etc/extra/httpd-ssl.conf設定,然後重啟Apache後SSL證書就生效囉!

SSLCertificateFile "/etc/letsencrypt/live/bliss-angel.org/fullchain.pem"
SSLCertificateKeyFile "/etc/letsencrypt/live/bliss-angel.org/privkey.pem"
Posted on

Socket.io錯誤訊息意義

I have found:

  • “ping timeout”: client stopped responding to pings in the allotted amount of time (per the pingTimeout config setting).
  • “transport close”: this appears to happen if the client side stopped sending data at all… or maybe there’s some kind of callback causing this to happen. I can see it happen if I just close a tab or follow a link from a page where I have an active connection to the server. But I’m not clear if this is always a case of the client causing it to happen.

    Sorry for re-opening the issue. Regarding the transport close that is the reason when page is closed/reloaded, it also happens some times in bad network conditions specifically when the ping packets are not delivered to the client. For the latter I need to handle it in the server side by waiting for the client to reconnect. Is there a way to properly distinguish between these two?

  • “Client namespace disconnect”: When the client sends a disconnect packet (client.disconnect())
  • “server namespace disconnect”: Looks to be when the server performs a socket.disconnect() action.
  • “Transport error”: An error occurred, I assume this is a server side error, but I’m not totally clear, as I’ve not been able to trigger one on my own.
  • “io server disconnect” This occurs using a third party library socketIOAuth when authentication fails

Continue reading Socket.io錯誤訊息意義

Posted on

Socket.io介紹

Socket.io

socket.io是基於Websocket的Client-Server實時通信庫

Socket.io承繼了Node.js的事件處理方法,把Client端與Server端的程式統一成一至的操作方式,讓使用者可以只需專注在處理「事件」,就可以快速開發出應用,他也支援『房間』的概念,可以使用同一條WebSocket卻擁有不被彼此干擾的資料傳輸(多種聊天頻道的概念)。另外,他也提供了很好的fallback機制,即使用戶的瀏覽器不支援WebSocket,他還是可以利用Flash、XMLHttpRequest等方式來傳送資訊(速度會比較慢就是了)。這些機制都他都包裝好了,所以寫程式時並不需要知道這些細節,只需要設定好就可以運作。

Socket.io 特性整理

  • Events 自訂事件。
  • Rooms Room 的概念只存在於伺服器端。可以理解為訊息處理時的聽眾分組,可對同一個分組內的聽眾進行廣播。
  • Namespaces 命名空間,我理解為底層連線的分組管理,不同命名空間可以走同一條 Engine.io 連線或是各自連線,每個命名空間可以各自驗證是否接受連線。
  • ACK 回調 如同 HTTP 之於 TCP,HTTP 為 TCP 提供了一套請求與響應的模型。ACK 也為 Socket.io 提供了一套請求與響應的通訊模型。
  • 連線維護
  • 自動斷線重連
  • ping/pong 心跳

Continue reading Socket.io介紹

Posted on

Socket.io自行增加header

伺服器端

範例程式碼:

import express from "express";
import http from "http";

const app = express();
const server = http.createServer(app);

const sio = require("socket.io")(server, {
    handlePreflightRequest: (req, res) => {
        const headers = {
            "Access-Control-Allow-Headers": "Content-Type, Authorization",
            "Access-Control-Allow-Origin": req.headers.origin, //or the specific origin you want to give access to,
            "Access-Control-Allow-Credentials": true
        };
        res.writeHead(200, headers);
        res.end();
    }
});

sio.on("connection", () => {
    console.log("Connected!");
});

server.listen(3000);

Continue reading Socket.io自行增加header

Posted on

Engine.io介紹

Engine.io介紹

Socket.io是在engine.io的基礎上去實作的
Gitlab連結: Engine.IO: the realtime engine
engine.iosocket.io提供跨瀏覽器/跨設備的雙向通信的底層庫。engine.io使用了WebsocketXHR方式封裝了一套socket協議。在低版本的瀏覽器中,不支持Websocket,為了兼容使用長輪詢( polling )替代。

關於長輪詢可參考我的另一篇文章:WebSocket與Ajax的不同
過去WebSocket未出來時,許多聊天室使用的都是長輪詢的方式去實作,而engine.io則可依據客戶端環境兼容使用這兩種方式。
Continue reading Engine.io介紹

Posted on

Redis Sentinel

Sentinel特性

Redis Sentinel為Redis提供高可用性。實際上,這意味著使用Sentinel可以創建Redis部署,該部署可以在沒有人工干預的情況下抵抗某些類型的故障。

Redis Sentinel還提供其他附帶任務,例如監視,通知,並充當客戶端的配置提供程序。

這是宏觀上Sentinel功能的完整列表(即,大圖):

監控。Sentinel會不斷檢查您的主實例和副本實例是否按預期工作。
通知。Sentinel可以通過API通知系統管理員或其他計算機程序,其中一個受監視的Redis實例出了問題。
自動故障轉移。如果主服務器未按預期工作,則Sentinel可以啟動故障轉移過程,在該過程中將副本升級為主服務器,將其他附加副本重新配置為使用新的主服務器,並通知使用Redis服務器的應用程序要使用的新地址。連接時。
配置提供程序。Sentinel充當客戶端服務發現的授權來源:客戶端連接到Sentinels,以詢問負責給定服務的當前Redis主服務器的地址。如果發生故障轉移,Sentinels將報告新地址。

Redis Sentinel是一個分佈式系統:

Sentinel本身設計為在有多個Sentinel進程協同合作的配置中運行。具有多個Sentinel進程進行協作的優點如下:

當多個哨兵就給定的主機不再可用這一事實達成共識時,將執行故障檢測。這降低了誤報的可能性。
即使不是所有的Sentinel進程都在工作,Sentinel仍能正常工作,從而使系統能夠應對故障。畢竟,擁有故障轉移系統本身就是一個單點故障,這沒有任何樂趣。
Continue reading Redis Sentinel