WordPress 手動安裝教學(Linux 主機)

以下示範如何在 Linux 主機上手動下載並安裝 WordPress。

✅ 前置需求

  • 已安裝 Apache / Nginx
  • 已安裝 PHP
  • 已安裝 MySQL 或 MariaDB
  • 已建立資料庫與資料庫帳號

📥 步驟一:下載 WordPress

cd /tmp
wget https://wordpress.org/latest.tar.gz

說明:
進入 /tmp 目錄並下載最新版 WordPress 壓縮檔。


📦 步驟二:解壓縮檔案

tar -vxf latest.tar.gz

解壓縮後會產生 wordpress 目錄。


📂 步驟三:複製檔案到網站目錄

rsync -av wordpress/ /var/www/html/

說明:
將 WordPress 檔案同步到網站根目錄(此處以 /var/www/html/ 為例)。

⚠️ 如果你的網站目錄不同,請修改為實際目錄路徑。


🔐 步驟四:修改檔案權限

chown -R apache:apache /var/www/html/

說明:
將檔案擁有者改為 Apache 使用者(CentOS / RHEL 常用 apache)。

🔎 如果是 Ubuntu / Debian 系統:

chown -R www-data:www-data /var/www/html/

🗄️ 步驟五:建立資料庫

登入 MySQL:

mysql -u root -p

建立資料庫與使用者:

CREATE DATABASE wordpress;
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

🌐 步驟六:完成網頁安裝

  1. 開啟瀏覽器
  2. 前往你的網域或 IP,例如: http://your-server-ip/
  3. 依照畫面輸入資料庫資訊
  4. 完成安裝 🎉

✅ 安裝完成

成功後即可登入後台:

http://your-domain/wp-admin

[Fix] PHP Server Monitor Shows “Online” for Failed Pings on Newer Linux Distros

I recently deployed PHP Server Monitor v3.5.2 on my server to keep track of my hosting status. However, right after setting it up, I noticed a very bizarre issue:

I purposely added a completely unreachable, invalid IP to test the Ping monitoring, but the system reported it as “Online” with a latency of 0ms!

I checked the system error logs, but they were completely clean—no error messages at all. A monitoring system that fails to alert you when a server goes down is virtually useless. To fix this fatal flaw, I began a deep dive to troubleshoot the issue.

🕵️‍♂️ The Diagnosis: Where did it go wrong?

Initially, I suspected the server’s PHP security settings (like disable_functions in php.ini) might be restricting the execution of system commands. If the exec() function is disabled, PHP wouldn’t be able to run the system’s ping command.

To test this theory, I wrote a simple PHP diagnostic script (test_ping.php) to check the underlying connection:

<?php
$test_ip = "192.168.255.255"; 
$cmd = "ping -c 1 -w 2 " . escapeshellarg($test_ip) . " 2>&1";
exec($cmd, $output, $return_var);

echo "Return Code: " . $return_var . "<br>";
print_r($output);
?>

The execution results were eye-opening:

  • Return Code: 1 (which means failure)
  • Actual Terminal Output: It clearly printed 2 packets transmitted, 0 received, 100% packet loss, time 1016ms.

This proved that the server environment and permissions were perfectly fine! The system successfully sent the packets and accurately recognized that the IP was unreachable (100% packet loss). The environment was not the culprit.

💡 The Root Cause: Outdated Regex vs. Modern Linux

With the environment ruled out, the root of the problem pointed directly to a bug within PHP Server Monitor v3.5.2 itself.

After digging into the official GitHub repository, I realized the software hasn’t seen a major active update since around 2021. The old codebase uses a very rigid method to determine ping status: it uses Regular Expressions (Regex) to parse the text output of the terminal. If it spots the keyword time anywhere in the output string, it blindly assumes “there’s a response time, so the host must be Online.”

In older Linux distributions, a failed ping (100% packet loss) usually wouldn’t print the time taken at the end of the output. However! In newer Linux distributions (like recent Debian versions), the ping command reliably prints out time 1016ms at the very end, even if every single packet is dropped.

Because of this simple phrase—time 1016ms—the outdated code in PHP Server Monitor gets completely confused. It ignores the glaring 100% packet loss right next to it and falsely reports the server as Online. This is also exactly why the “fix” available in the official development branch still fails on newer Linux systems.

🛠️ The Ultimate Solution: Rewriting the Core Logic

Since official maintenance has stalled, the most reliable way forward is to rewrite the validation logic ourselves. Instead of relying on the app to parse terminal text—which can constantly change depending on the Linux distribution—we should just grab the most honest metric the OS provides: the Return Code (0 means success, anything else means failure).

How to apply the fix:

  1. Access your PHP Server Monitor web directory via SSH or FTP.
  2. Locate and open this specific file: src/psm/Util/Server/Updater/StatusUpdater.php
  3. Search for the protected function updatePing function inside the file (it should be roughly past the middle).
  4. Replace the entire updatePing function block with this updated, precise version:
    protected function updatePing($max_runs, $run = 1) {
        $starttime = microtime(true);
        $ip = $this->server['ip'];
        $os_is_windows = strtoupper(substr(PHP_OS, 0, 3)) === 'WIN';
        
        if ($os_is_windows) {
            // Windows Ping: -n 1 (1 packet), -w 2000 (2000ms timeout)
            exec('ping -n 1 -w 2000 ' . escapeshellarg($ip), $output, $result);
            $output_str = implode("", $output);
            // Windows ping notoriously returns 0 on unreachable hosts. Verify with "TTL="
            $status = ($result === 0 && stripos($output_str, 'TTL=') !== false) ? true : false;
        } else {
            // Linux/Unix Ping: -c 1 (1 packet), -w 2 (2s timeout), capture stderr
            exec('ping -c 1 -w 2 ' . escapeshellarg($ip) . ' 2>&1', $output, $result);
            // Core fix for Linux: Only trust the Return Code! (0 is success)
            $status = ($result === 0) ? true : false;
        }
        
        // Record the response time
        $this->rtime = (microtime(true) - $starttime);

        // If it fails and we haven't reached max retries, try again
        if(!$status && $run < $max_runs) {
            return $this->updatePing($max_runs, $run + 1);
        }
        
        return $status;
    }

Save the file and head back to your PHP Server Monitor dashboard. Test that invalid IP again, and the system will finally behave as it should, properly displaying a red “Offline” status!

📝 Conclusion

Sometimes, when running older open-source software on modern operating systems, official patches might not be enough to resolve bugs caused by OS-level changes. In situations like this, writing a simple script to test the underlying commands directly can help cut through the confusion and point you toward the most effective fix.

If you are using PHP Server Monitor and experiencing this “Fake Online” bug, give this fix a try!

Tags: PHP Server Monitor, Bug Fix, Server Monitoring, Ping, Linux

Linux ZFS 指令大全(OpenZFS 實戰版)

適用:

  • Ubuntu 22.04 / 24.04
  • Debian 12
  • Rocky Linux / AlmaLinux 9
  • OpenZFS 2.x

本文適用於現代 Linux 系統(OpenZFS 2.x)


一、安裝 ZFS(Linux)

✅ Ubuntu / Debian

sudo apt update
sudo apt install zfsutils-linux

✅ Rocky / AlmaLinux

sudo dnf install epel-release
sudo dnf install zfs

啟用模組:

sudo modprobe zfs

確認版本:

zfs --version

二、Zpool(儲存池)管理


✅ 建立 ZFS 儲存池(Mirror)

sudo zpool create -o ashift=12 mpool mirror /dev/sdb /dev/sdc

📌 說明:

  • ashift=12 → 4K 磁碟最佳化(強烈建議)
  • mirror → 類似 RAID1

✅ 建立 RAIDZ1

sudo zpool create -o ashift=12 mpool raidz /dev/sdb /dev/sdc /dev/sdd

✅ 建立 RAIDZ2

sudo zpool create -o ashift=12 mpool raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde

✅ 查看儲存池

sudo zpool list
sudo zpool status

✅ 增加容量(新增 vdev)

⚠️ 注意:ZFS 無法擴充單一 vdev,只能新增一組 vdev

sudo zpool add mpool mirror /dev/sde /dev/sdf

✅ 加入 Hot Spare

sudo zpool add mpool spare /dev/sdg

✅ 更換故障磁碟

sudo zpool replace mpool /dev/sdb /dev/sdh

✅ Scrub(資料一致性檢查)

sudo zpool scrub mpool

查看進度:

sudo zpool status mpool

建議每月執行一次。


✅ 匯出 / 匯入 Pool

匯出(卸載):

sudo zpool export mpool

匯入:

sudo zpool import mpool

✅ 刪除 Pool(⚠️ 會刪除所有資料)

sudo zpool destroy mpool

三、ZFS 檔案系統管理


✅ 建立檔案系統

sudo zfs create mpool/data

✅ 設定掛載目錄

sudo zfs set mountpoint=/data mpool/data

✅ 建立子檔案系統

sudo zfs create mpool/data/projects

✅ 刪除檔案系統

sudo zfs destroy mpool/data/projects

✅ 查看檔案系統

sudo zfs list

四、Snapshot(快照)

ZFS 最強功能之一 ✅


✅ 建立 Snapshot

sudo zfs snapshot mpool/data@2026-05-06

✅ 查看 Snapshot

sudo zfs list -t snapshot

✅ 還原 Snapshot

sudo zfs rollback -r mpool/data@2026-05-06

✅ 刪除 Snapshot

sudo zfs destroy mpool/data@2026-05-06

✅ 建立可寫 Clone

sudo zfs clone mpool/data@2026-05-06 mpool/testclone

五、壓縮與空間管理


✅ 啟用壓縮(推薦)

sudo zfs set compression=lz4 mpool/data

✅ lz4 幾乎無效能損耗,強烈建議開啟。


✅ 關閉壓縮

sudo zfs set compression=off mpool/data

✅ 設定容量限制(Quota)

sudo zfs set quota=100G mpool/data

✅ 設定保留空間(Reservation)

sudo zfs set reservation=20G mpool/data

六、ZFS Volume(區塊設備)

類似虛擬磁碟,可給 iSCSI / VM 使用。


✅ 建立 Volume

sudo zfs create -V 10G mpool/vm_disk

✅ 查看裝置

ls -l /dev/zvol/mpool/

✅ 刪除 Volume

sudo zfs destroy mpool/vm_disk

七、Linux 最佳實務建議 ✅


✅ 使用磁碟 ID(避免重開機順序改變)

查看:

ls -l /dev/disk/by-id/

建立 pool 範例:

sudo zpool create -o ashift=12 mpool mirror \
/dev/disk/by-id/ata-Samsung_SSD_1 \
/dev/disk/by-id/ata-Samsung_SSD_2

✅ 強烈建議使用 by-id 而非 /dev/sdX


✅ 查看磁碟

lsblk

✅ 自動開機掛載(ZFS 會自動處理)

sudo systemctl enable zfs-import-cache
sudo systemctl enable zfs-mount

八、常用維護指令總整理

功能指令
查看 Poolzpool list
查看 Pool 狀態zpool status
查看 Datasetzfs list
查看 Snapshotzfs list -t snapshot
開始 Scrubzpool scrub mpool
查看 I/Ozpool iostat 2

✅ 結語

ZFS 在 Linux 上已非常成熟,適合:

  • NAS
  • VM 主機
  • Docker 儲存
  • 資料備份伺服器
  • Home Lab
  • 企業儲存環境

測電筆 使用說明書

YITOLI 易之力
DWGR-2897+ PRO MAX


⚠ 警告

使用前請仔細閱讀使用說明書,並嚴格遵守安全規則和使用說明書所列的小心、注意、警告等事項。


安全須知

⚠ 警告
為避免可能發生的觸電或人身傷害:

  • 如未依照指示使用測電筆,則測電筆提供的保護功能可能會受到影響或失效。
  • 如果測電筆顯示屏無顯示,請勿使用。
  • 使用測電筆前,請在已知帶電的電源上進行測試,以確保測電筆處於良好的工作狀態。
  • 在使用測電筆時,即使無顯示或無聲音報警,仍然可能會有電壓存在。如果產品已經損壞,或者無法正常工作,請勿使用。如懷疑有問題,請及時送修。
  • 請勿施加超過測電筆上標記的額定電壓。
  • 測試交流 30 伏以上的電壓時,要格外小心,因為這樣的電壓有發生觸電的危險。
  • 遵守當地和國家的安全規範,依照當地或國家主管當局的規定使用適當的保護設備。

外表結構

  1. 探針(NCV 感應頭)
  2. 手電筒
  3. 開機/照明燈按鍵
  4. 顯示屏
  5. 接觸測量按鍵
  6. 導通/正極測量按鍵

操作說明

開機/關機

按下開機/照明燈按鍵,並保持大於 1 秒開機,蜂鳴響一聲,顯示屏點亮,進入開機狀態;
在開機狀態下,長按開機/照明燈按鍵 1 秒,關機。


手電筒

在開機狀態下,短按開機/照明燈按鍵,手電筒打開;
在手電筒打開狀態下,再短按開機/照明燈按鍵,則關閉手電筒。


感應模式測量

開機默認感應模式測量狀態。

將測電筆的探針放在靠近交流電壓源時,蜂鳴器響;蜂鳴器響的頻率有三檔,隨信號增強遞增。同時顯示屏會顯示「___U」,信號強時顯示「HI」。

以此功能,可查找電線斷點。


交流電壓探測

開機後,按住接觸測量按鍵,進入交流電壓測量模式,測電筆的探針接觸帶有交流電壓的導體時,顯示屏幕上顯示對應的交流電壓。此功能,可檢測交流電壓大小。


零火線測量

根據電壓的大小區分零火線,零線電壓約為 3~7V。


斷電檢測

在電池沒電時測量火線也會顯示高壓符號。


電線導通

開機後,右手按住測電筆導通/正極測量按鍵,左手捏住不帶電導線一端,用測電筆探針接觸導線另一端,如導線連通正常,則顯示屏顯示「___C」,蜂鳴器響,如電線開路,測電筆無反應。


電池正極檢測

開機後,右手按住測電筆導通/正極測量按鍵,左手電池負極,用測電筆探針接觸電池正極,如正常,則顯示屏顯示「___P」,蜂鳴器響,如接反,測電筆無反應。


一般情況下,背光亮紅色時,說明被測物體可能存在危險,需小心操作。


注意事項

注 1: 請確保人體與大地絕緣,請穿著絕緣性好的鞋子,或是站在絕緣墊上使用;如人體的某一部位接觸到帶電物體,或者是其他大面積的導電物體,或者是接觸到大地,會使測量結果偏大。

注 2: 本產品只能用於測量市電電壓,如測量其他經過處理的電源類電壓,誤差較大。

注 3: 由於插座的結構不同,當不能通過感應模式區分零火線時候,可切換到交流電壓檢測模式,一般可根據電筆探測到的電壓大小來區分。

注 4: 當使用感應模式分辨零火線時,如果零火線靠很近時,儘可能將兩根線分開來檢測;如實在不可分開,可根據探測到信號強弱來區分,信號強的一根是火線,信號弱的一根零線。

注 5: 因電筆測量需要人體接觸形成回路,所以請確保手指可以良好的接觸測電筆按鍵。

注 6: 因電筆的感應模式有極高的靈敏度,可以感應微弱的電場信號,所以在金屬探測頭直接接觸帶有微弱電場的物體時,觸發感應,屬正常現象。


自動關機

在約 3 分鐘無感應信號或無任何操作後,測電筆會自動關機,以延長電池壽命。


欠壓提示

當電池電壓不足時,顯示屏會顯示「電池符號」;當出現欠壓提示時,為了不影響檢測,請及時更換電池。


技術參數

工作電壓:
交流電壓:3~500V,50/60Hz

測量誤差:
3~300V ±(5%+3)
300~500V ±(6%+5)

使用環境:
工作溫度:0~40℃
存儲溫度:-10~50℃
濕度:≤95%
海拔高度:≤2000 米

電源:1×1.5V AAA 電池


更換電池

如下圖所示推開電池蓋,然後取出舊電池,按電池正負指示裝入新電池。

⚠ 警告:
為避免電擊,電池蓋在扣好鎖緊前不要使用測電筆進行電壓探測。
為不影響檢測,請確保人體和大地絕緣。


清潔

用濕布進行清潔。
注意:清潔過後要待測電筆完全乾燥後才能使用。


山東易之力工具有限公司
SHANDONG YIZHILI TOOLS CO., LTD
地址:山東省臨沂市經開區沂河路與沃爾沃路交匯南
電話:400-8838-505

✅ How to Fix ISPConfig Manual SQL Backup Not Working (While Auto Backup Works)

Problem Overview

In ISPConfig 3.3 multi‑server setups, you may encounter the following issue:

  • ✅ Scheduled (Automatic) SQL backups work normally
  • ❌ Manual SQL backup does nothing
  • ❌ No error message appears
  • ❌ No backup folder is created
  • ✅ Some websites may work, others do not

This behavior can be confusing because everything seems healthy — but manual backups simply don’t trigger.

This article explains the root cause and provides the permanent fix.


Why This Happens

ISPConfig handles backups differently:

✅ Automatic Backup

Runs locally on the SQL server via cron and does not rely on datalog synchronization.

❌ Manual Backup

Uses this flow:

  1. The ISPConfig UI writes a task into sys_datalog (on the Master server)
  2. The SQL server reads the datalog entry
  3. server.sh processes the task
  4. Backup runs

If the datalog entry cannot be properly written or transmitted, the manual backup will silently fail.


The Real Cause: max_allowed_packet Too Small

In most cases, the issue is caused by a MariaDB configuration problem:

max_allowed_packet

On Debian 12/13 and many CentOS installs, the default is:

16M

In some cases, even:

1M

That is too small for ISPConfig 3.3 multi‑server environments.

Why?

Because sys_datalog may contain:

  • SSL certificate blobs
  • Large JSON configuration data
  • Backup metadata
  • Website configuration structures

If a datalog record exceeds max_allowed_packet, MariaDB silently rejects the transfer.

Result:

  • Small websites → manual backup works
  • Larger websites → manual backup does nothing
  • Auto backup still works

How to Check Your Current Value

Run on BOTH Master and SQL server:

mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';"

If you see:

16777216  (16M)

or smaller → this is your problem.


✅ The Permanent Fix (Debian 13 / MariaDB 10.11+)

Step 1 — Edit MariaDB Configuration

On Debian 13, edit:

/etc/mysql/mariadb.conf.d/50-server.cnf

Find the [mysqld] section and set:

max_allowed_packet = 256M
wait_timeout = 300
interactive_timeout = 300

Save the file.


Step 2 — Restart MariaDB

systemctl restart mariadb

Verify:

mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';"

You should now see:

268435456

Step 3 — Reset Stuck Datalog Entries

On the Master server:

mysql -u root -p dbispconfig

Run:

UPDATE sys_datalog SET processing = 0;

Then on the SQL server:

/usr/local/ispconfig/server/server.sh

After Fixing

Manual SQL backups should now:

  • ✅ Work for all websites
  • ✅ Create backup folders immediately
  • ✅ No longer silently fail

Why 256M Is Recommended

For ISPConfig multi‑server setups:

SettingRecommended Value
max_allowed_packet256M
wait_timeout300
interactive_timeout300

256M ensures large SSL or configuration payloads do not break datalog synchronization.


Important Notes

✅ You must update BOTH Master and SQL servers
✅ Restart MariaDB after changes
✅ Clear stuck datalog entries

If you only update one server, the problem may persist.


Final Thoughts

If you see:

  • Manual SQL backup does nothing
  • No error in UI
  • Auto backup works
  • Some sites succeed, others fail

The issue is almost certainly MariaDB’s max_allowed_packet.

Increasing it to 256M resolves the problem permanently in almost all ISPConfig 3.3 multi‑server environments.

Debian 13 + ISPConfig 3.3 + Slave Installation and config

1️⃣ Install Debian 13

最小安裝完成後:

apt update
apt upgrade -y

2️⃣ Enable Root Login

nano /etc/ssh/sshd_config

加入或修改:

PermitRootLogin yes

重新啟動 SSH:

systemctl restart ssh

3️⃣ Set Static IP

nano /etc/network/interfaces

加入:

auto ens18
iface ens18 inet static
    address 10.0.0.x
    netmask 255.255.255.0
    gateway 10.0.0.1
    dns-nameservers 8.8.8.8 8.8.4.4
    up ip route add 10.y.0.0/24 via 10.0.0.z
    down ip route del 10.y.0.0/24 via 10.0.0.z

確認無拼字錯誤。


4️⃣ Reboot

reboot

5️⃣ Set DNS

nano /etc/resolv.conf

內容:

nameserver 8.8.8.8
nameserver 8.8.4.4

6️⃣ Test Network

ping google.com

若可解析並 ping 通,表示 DNS 正常。


7️⃣ Edit Hosts

nano /etc/hosts

加入:

10.0.0.w    master.ispconfig.domain

(確認 IP 與實際 master 相符)


8️⃣ Install ISPConfig

cd /tmp
wget -O - https://get.ispconfig.org | sh -s -- --interactive

9️⃣ Installation Mode

Installation mode (standard,expert) [standard]: expert

🔟 Join Multiserver Setup

Shall this server join an existing ISPConfig multiserver setup (y,n) [n]: y

11️⃣ MySQL Master Information

MySQL master server hostname []:
master.ispconfig.domain
MySQL master server root password []:

⚠ 必須:

  • 知道 master 的 MySQL root password
  • 並且 master MySQL 必須允許 slave IP 連線

在 master 上確認:

GRANT ALL PRIVILEGES ON *.* TO 'root'@'10.0.0.x' IDENTIFIED BY 'password' WITH GRANT OPTION;
FLUSH PRIVILEGES;

12️⃣ Keep MySQL Root Password

安裝過程中會顯示:

  • MySQL root password

請保存。


13️⃣ Remove Install Logs

rm /root/ispconfig-install-log/setup-*

避免密碼留在系統中。


14️⃣ Set Default PHP Version

update-alternatives --config php

選擇:

php 7.4

否則 slave cronjob 會無法與 master 正常連線。

確認:

php -v

✅ Installation Complete

登入:

https://slave.ispconfig.domain:8080

使用 master 帳號登入。


WordPress Installation

  1. ISPConfig → Sites → Add Website
  2. 建立 Database
  3. 上傳 WordPress
  4. 設定 wp-config.php
  5. 完成安裝

如果你需要,我可以:

  • 幫你排成「正式教學文件格式」
  • 或整理成「公司內部 SOP 文件版」
  • 或轉成 PDF 版教學稿

告訴我你要哪種格式。