310,127 total views, 178 views today

Linux – ZeroConfNetworking

Windows 設定 DHCP 時,沒有 DHCP 服務時會自己產生一個 169.254.x.x 的 IP,Linux 遇到沒有 DHCP 服務除了開機不斷重試浪費時間之外,失敗後什麼 IP 都沒有,導致臨時要使用 IP 連線都沒有辦法。

Linux 該如何在使用 DHCP 卻沒有 DHCP 分配 IP 的情況還可以像 Windows 產生一組 IP ?

參考資源

Windows 使用的是 Zero-configuration networking (zeroconf) 技術, RFC3927 ,Apple Bonjour 也是相同的技術

安裝

Hoyo 在 DietPi 上測試時是裝 avahi-autoipd,網路上大多是教安裝 avahi-daemon,實際裝過不知道用途為何

avahi-autoipd 安裝完就完成了,預設設定有一些問題不過問題不大可以正常使用,Hoyo 是打算就這樣使用

實際使用

沒有 DHCP

接上網路線或是 DHCP 恢復後

eth0:avahi 網路會消失

設定檔

/etc/dhcp/dhclient-enter-hooks.d/avahi-autoipd

問題

登入時需要 Ctrl + C 中斷

78 total views, 1 views today

CentOS 7 – 在 CentOS7 安裝 Python3.8.4

參考

安裝

事前準備

如果有安裝舊版先移除,sqlite 要先安裝,否則 python3 裝完還需要重新 make 才能添加

模組安裝

225 total views, no views today

Hoyo 教你串 OAuth – Google 登入

JavaScript 登入

參考資源

使用 JavaScript 的好處是程式處理的份量較少,壞處是容易受瀏覽器影響

OAuth 2.0 用戶端 ID

從程式需求看來需要一個 client_id 也就是 OAuth 用戶端 ID,請按照路徑:建立憑證 → OAuth 用戶端 ID

完整程式範例

頁面載入時必須先執行 startApp() 進行登入按鈕初始化,然後指定的 id (GoogleLogin) 就會點擊才有功能

PHP 後端登入

參考資源

使用後台處理

流程

  1. 註冊 Google 會員帳號
  2. 進入 https://console.cloud.google.com/
  3. 登入連結 https://accounts.google.com/o/oauth2/auth?
  4. 使用者同意後取得 code
  5. 拿 code 去換 access_token, https://accounts.google.com/o/oauth2/token , Google 回傳的是 json 格式
  6. 將 json decode 後,使用 https://www.googleapis.com/oauth2/v1/tokeninfo?access_token= 進行解讀

 

 

和 Facebook 不同的是,Google Plus 在用 code 換 access_token 時,使用 HTTP POST 丟值過去

 

 

118 total views, no views today

伏地挺身 – 100 下 100 天

結束感想

漫長的 100 天總算完成了,總數超過 10000 多一點點,中間無法執行缺的次數都有另外補上。

這種長時間的運動企劃最怕的就是受傷,後期右手腕有點受傷,撐著時用力不當就會痛,就只能將重心偏左來規避。

做了一萬次伏地挺身才對這個動作有一些理解,難怪健身需要教練,重點就是調整動作有效率也不會運動傷害,最後也不能做拍手伏地挺身,做到兩萬次的時候再試試看好了

69 total views, no views today

CentOS 7 – 使用 Liberoffice 將 Office 轉換 PDF

參考

安裝、中文化設定

檢查語系設定

套用

轉換

首先依據來源文件安裝對應程式,例如試算表 calc

從網頁執行

除了需要設定一個網頁 apache 可以寫入的目錄外,還要注意 SELinux 是否已經關閉

Windows CLI

87 total views, no views today

Linux – SD 壽命寫入控制

為了控制 SD 卡寫入次數限制達到最佳使用壽命,所以 Hoyo 先將自己開發的程式另外一個分割區,再把原系統分割區設定為唯讀,只要確定程式分割區所有的寫入動作皆在預想之下,如此就可以達到目的。

得知最近有被寫入的檔案

使用前記得校時

找出最近一個小時內有被寫入的檔案

  • -mtime 檔案有修改,單位:天
  • -mmin 檔案有修改,單位:分鐘

修正後

記憶體檔案

為什麼要排除 /proc /run /sys ? 首先可以看一下 df 資訊

可以知道系統預設掛載了很多 tmpfs 也就是使用記憶體的路徑,除了記憶體之外也有很多虛擬的檔案資訊,例如 /proc /sys ,這些路徑當然也是要排除

資料庫

原先使用 SQLite,使用前先將檔案複製到記憶體再從記憶體存取,當需要異動資料時再從記憶體複製到 SD 卡,這樣從邏輯也是控制了寫入,不過後來遇到頻繁遇到資料庫毀損以及最嚴重的 database disk image is malformed 問題,就改成使用 JSON 當作資料的儲存載體,當然需要犧牲一些系統功能,不過在這種應用穩定以及將問題可控制才是最重要的

(後來找到了 TinyDB 這種好像也是使用 JSON 為載體的資料儲存方式)

431 total views, no views today

大量 3306 TIME_WAIT 的邪道解法

不知道會不會衍生其他問題,有後續狀況再更新

出現大量的 TIME_WAIT 大概長這樣

通常 Google 找到的資料是這樣

會噴 cannot stat /proc/sys/net/ipv4/tcp_tw_recycle: No such file or directory 錯誤,而且問題沒有改善,可以得知關鍵就是 tcp_tw_recycle 這個參數,只好繼續找答案

  • sysctl -p 設定啟用

357 total views, 2 views today

需量預測

參考

公式

  • P = 時間 t 時之累計電力量
  • Δt = 標本時間
  • ΔP = 標本時間內增加電力增加量
  • t = 開始測量時間

範例

假設有一個穩定的 100kW 負載,於某需量區間 4 分量測,取前一分鐘為標本時間

100kW = 100 度(kWh) ,需量區間  = 100 / 4 = 25 (每 15 分鐘一個結算)

每分鐘電度約等於 25 /15 = 1.667

P = 1.667 * 4 = 6.668

Δt =1

ΔP = 1.667

6.668 + (1.667/1) * (15-4)

= 6.668 + (1.667) * 11

= 6.668 + 18.337

= 25.005 kWh * 4 = 100.02 kW

由此得知此需量預測公式是準確的

LaTeX

158 total views, 1 views today

PHP 7 – OpCache

結論

  1. 主要作用在提昇 PHP 執行效能,以及簡易的程式加密
  2. 使用 OpCode 加密可以保護程式邏輯,不能保護「程式內的字串」

php.ini

  • opcache.enable=1 ; 啟用 OpCache
  • opcache.save_comments=0 ; 關閉 comments
  • opcache.file_cache=/opt/Server/OpCache ; 設定 OpCache Cache 路徑
  • opcache.validate_timestamps=0 ; 關閉檔案更新檢查,配合下面的程式保護
  • opcache.revalidate_freq=0 ; 檔案更新檢查時間
  • opcache.max_accelerated_files=4000 ; 最大 cache 檔案數,需要大於總 .php 數量

重新啟動 apache2 服務

保護程式作法

先將所有 .php 檔案編譯成 OpCache 之後就可以將 .php 原始碼檔案清空或是填入不相關內容

使用 PHP 官網範例稍加修改,將 require_once 替換為 opcache_compile_file(),官網有針對兩者之間的差異說明,請根據實際情況選用

在網路根目錄執行以下執行即可將所有 .php 檔案內容清空

更新

因為使用了禁用時間戳檢查,以及將原始碼清空,因此更新時,必須由開發主機提供 .php.bin 檔,OpCache 檔案皆是 www-data 使用者權限,可以使用 tar 打包及還原

.php.bin 檔案更新後,必須使用 opcache_reset() 或 opcache_invalidate() 來啟用新的 .php.bin 檔

計算 php 檔案數量

OpCache 長相

節錄內容

Preload

PHP 7.4 增加了 opcache.preload & opcache.preload_user 參數,因為原始碼後來會清空,因此不適用此參數

306 total views, 1 views today

MQTT – 使用 Let’s Encrypt SSL + EMQ X 建構 SSL WebSocket

原理

  • 網站的證書和 MQTT (WebSocket) 的證書必須一致
  • Let’s Encrypt 證書檔案必須讓 emqx 帳號有讀取權限

編輯emqx.conf

  • 請自行替換 {web url} 為你的網域
  • .ssl. 是 MQTT使用;.wss. 是 WebSocket 使用

Let’s Encrypt 證書檔案權限

要讓 emqx 可以讀取 Let’s Encrypt 產生的證書,最大的問題就是目錄和檔案的讀取權限。

預設的權限大多是只有 root 使用者可以讀,最方便的方式是將 /etc/letsencrypt 的 archive & live 的其他人讀取開放

可以使用一般使用者讀取證書檔案測試,如果沒問題就可以重啟 emqx 服務

HTML

在使用上和沒有 SSL 差別不到,注意 mqtt.connect() 的通訊協定是 wss:// 以及 port 的設定即可。

網路上可能會找到有關 MQTT.js 證書相關的設定,不過那些設定並沒有什麼卵用,因為當網站是 https:// 時瀏覽器就會檢查如果是同網站就需要使用相同證書,不同網站就會發生跨網站的相關錯誤,當然現在也是不能和 http 混用

在 F12 console 下如果沒有看到錯誤恭喜已經成功了。

281 total views, 1 views today