把自己的 Trac 換到 1.4

八月底的時候就已經出 Trac 1.4 了 (參考當時寫的「Trac 1.4」),不過當時升級一直失敗:

$ trac-admin ./ upgrade
Error: Unable to check for upgrade of trac.db.api.DatabaseManager: TracError: Unsupported database type "mysql"

後來在「TracError: Unsupported database type “mysql”」這邊找到解法,下面有人提到解法是裝系統的 python-pymysql,那麼對應到 pip 的套件安裝時,裝 PyMySQL 就可以了。

另外一個比較麻煩的就是 Trac 的 XmlRpcPlugin 套件,這個套件其實一直都很 hack,常常是自己硬幹底層的東西跳過現有機制 (於是像是透過他開 ticket 時,就不會發通知信之類的問題),但目前暫時又不能不用他...

Anyway,這東西在升級後也爛掉了:「Plugin fails on Trac 1.4」,然後下面看到 Gasol 修了一版出來:「Gasol/trac-xmlrpcplugin」。

另外是我自己有掛 custom theme 的套件 ThemeEnginePlugin 也爛掉了,不過這個暫時移除就好,之後再排進去修...

最後就是把本來的 css/js 都依照「Customizing the Trac Interface」的說明,porting 到 Jinja2 下。

主要就是把本來的 site.html 裡面的片段搬到 site_head.htmlsite_footer.html 裡,然後 CSS 的部份照著建議拆到 style.css 裡 (因為 css selector 的 id selector # 在一行開頭的位置會被 Jinja2 當作命令處理)。

後續繼續看看還有什麼要修正的,另外 wiki 也得等摸索差不多後更新...

AWS 提供將 Lightsail 切換到 EC2 的功能

AWS 總算把 Lightsail 轉移到 EC2 的功能做出來了:「Amazon Lightsail Now Provides an Upgrade Path to EC2」。

這樣先從小站開始跑,搞大後想要改用 AWS 服務的切換成本就降低不少了。不過目前看起來是透過 export-and-import 做:

When you are ready to upgrade an instance to EC2, simply take a snapshot of your instance and follow the step-by-step process in Lightsail's console to export your snapshot to EC2. You can then use EC2 or the Upgrade to EC2 wizard in Lightsail's console to get your new EC2 instance up and running.

不過上次用 Lightsail 可以發現可用的 CPU 跟其他 VPS 比起來慢不少... 這點是一開始要不要選 Lightsail 的因素。

Ubuntu 推出 14.04 的 ESM 計畫

Ubuntu 14.04LTS 版本,在明年四月底 (也就是 2019 年四月) 將會滿五年的維護期,之後就不會有任何公開更新了 (包括安全性更新)。

在前一次的 Ubuntu 12.04 是第一次提供 ESM (Extended Security Maintenance) 服務,讓沒辦法即時轉及到新版的單位可以付費繼續收到安全性更新,算是 LTS 的一個重要服務。

而官方這次也對 Ubuntu 14.04 推出了 ESM:「Announcing Extended Security Maintenance for Ubuntu 14.04 LTS – “Trusty Tahr”」。

Ubuntu 14.04 LTS – ESM will become available once Ubuntu 14.04 reaches its End of Life on April 30, 2019.

價錢應該會跟之前類似吧...

把 Blog 換成 PHP 7.2

去年十一月出 PHP 7.2,現在已經更新到 7.2.5,各家軟體的相容性也都修的差不多了,差不多該升級了。

在「PHP 7.2 的效能改善」這邊有提到與 PHP 7.1 的效能改善主要來自於同時間有多人同時存取時的最佳化。

同樣 wiki 也跟著更新了,來看看效果如何...

一路從 MySQL 5.5 升級到 MySQL 8.0 的故事...

在「Migrating to MySQL 8.0 without breaking old application」這邊看到這個有趣的故事 XD 這是作者的應用程式 DrupalMySQL 5.5 一路升級到 8.0 的過程記錄...

真正的問題發生在 5.7 到 8.0:

原因是 Drupal 用到關鍵字了:

In fact, this old Drupal, uses a table name that is now part of the reserved keywords. It’s always advised to verify what are the new keywords reserved for MySQL itself. New features can also mean new keywords sometimes.

修正後就好了:

話說依照「File:Drupal release timeline.png」這邊的資訊,Drupal 6.2 也十年左右了?應該是 PDO 剛開始要推廣的年代,不知道他跑哪個版本的 PHP...

另外 MySQL 的升級意外的順利?雖然是一步一步升,但沒遇到什麼大問題...

CloudFlare 把 HTTPS Everywhere 的清單拿到 CDN 上用所推出的產品...

這個產品就如同標題所說的方式而已,做起來不難,只是一直沒人做就是了:「How we brought HTTPS Everywhere to the cloud (part 1)」。

傳統的作法是直接硬幹下去換掉,或是用 header 讓瀏覽器主動轉過去:

A naive way to do this would be to just rewrite http:// links to https:// or let browsers do that with Upgrade-Insecure-Requests directive.

但這有必須有兩個假設成立才可以:

  • Each single HTTP sub-resource is also available via HTTPS.
  • It's available at the exact same domain and path after protocol upgrade (more often than you might think that's not the case).

而 HTTPS Everywhere 則是用人力確認了哪些網站可以這樣玩。CloudFlare 利用這份清單改寫程式碼裡面的 HTTP 連結,僅可能將 HTTP 資源換成 HTTPS。算是還不錯的方式...

之後有可能再推出對 HTTP images 與 HTTP assets 的 proxy cache?

Linode 記憶體升級,以及新的日本機房計畫

Linode 的 13 歲禮物:「Linode’s 13th Birthday – Gifts for All!」。包括了記憶體的升級計畫:

Old Plan New Plan Price
Linode 1 GB Linode 2 GB $10/mo ($0.015/hr)
Linode 2 GB Linode 4 GB $20/mo ($0.03/hr)
Linode 4 GB Linode 8 GB $40/mo ($0.06/hr)
Linode 8 GB Linode 12 GB $80/mo ($0.12/hr)
Linode 16 GB Linode 24 GB $160/mo ($0.24/hr)
Linode 32 GB Linode 48 GB $320/mo ($0.48/hr)
Linode 48 GB Linode 64 GB $480/mo ($0.72/hr)
Linode 64 GB Linode 80 GB $640/mo ($0.96/hr)
Linode 96 GB Linode 120 GB $960/mo ($1.44/hr)

比較小的機器都是 double RAM,比較大的機器就沒那麼明顯了... 但這樣就超越 DigitalOcean 的規格,而且還領先其他 VPS 不少。

不過由於東京機房已經滿了,這次升級不包括在內,但也透漏了東京的新機房將會在今年年底前啟用:

Unfortunately, since Tokyo is sold out, the upgrade is not available there. We hope to have our second Tokyo facility online before the end of the year.

是個好消息 XD

Composer 出現 lock file out of date 的解法

之前也有遇到,結果 Lorna Jane Mitchell 寫了一篇「Handling Composer "lock file out of date" Warning」給了不少解法。

第一種是 composer upgrade,直接全部升級。

第二種是先用 composer update --dry-run 看看是不是有人加到 composer.json 後忘記更新,如果是的話再用 composer update [package] 處理。

第三種是用 composer update nothing 閉上眼睛更新 hash 值,當作什麼都沒看到 XDDD

Sometimes this is the right answer so it's a handy trick to know!. I seem to see these kinds of issues in people's projects quite often (I'm a consultant, I see a lot of projects) so I thought I'd share my usual tactics for getting things sorted - if you have any tricks of your own to share, I'd love to hear them :)

該說很「實用」嗎 XDDD

把 HTTP 站台逐步換向 HTTPS 站台的步驟

Jerry Qu 寫的「关于启用 HTTPS 的一些经验分享」這篇文章講了要怎麼將 HTTP 站台逐步換成 HTTPS 站台的方式 (以及工具)。

一開始會遇到 Mixed Content,瀏覽器預設值不會直接全部擋掉,而是會放行圖片類資源 (但是出現對應的警告)。然後可以用 upgrade-insecure-requests 來幫助邊換,讓 url 裡指定 http 的自動連到 https。

當全站把 url 都修完後,接著就可以考慮用 HSTS 強制全上 HTTPS。

做到這邊的安全性已經到一定程度了,接下來要不要進 HSTS Preload List 就看大家自己的想法了。

桌機的 Ubuntu 12.04 升級到 14.04

拖了好久,總算利用連假的時間 (而且在台灣!) 把桌機的 Ubuntu 12.04 (Precise) 升級到 14.04 (Trusty)。整個升級的過程果然充滿了地雷... XD

這邊當作雜記記錄下來,希望對之後的人升級有幫助。其中比較重要的前提是,我是用 Unity,所以升級的流程大致照著官方的指示做就可以了,對於使用 GNOME 的人,需要再多研究看看?

升級前的注意事項:

  • 假設當初有裝很多 UNSUPPORTED 的 repository (這邊是指官方的 *.archive.ubuntu.com 裡有一些沒有被官方支援的項目,像是 universe 與 multiverse),要記得到 /etc/apt/sources.list 裡暫時註解掉。
  • 跑 do-release-upgrade 時的語系要用英語系 (Cen_US 之類的,像是 env LANG=C LANGUAGE=C LC_ALL=C do-release-upgrade 這樣執行),不然會造成 Python 的錯誤訊息 (decode error,因為是用 ascii 去解),原因是 /etc/apt/sources.list.d/ 下面在替換 precise -> trusty 時會增加註解,而這個註解在 zh_TW.UTF-8 狀態下會出現中文 UTF-8,於是就造成 parser 爛掉... XD

升級完成後的注意事項:

  • Fix Ubuntu 把該關的關掉。
  • /etc/apt/sources.list.d/ 下面的東西整理過,有些是 backport 回 12.04 的,在 14.04 就可以省略,有些則是要找替代方案。

升完後還沒解決的問題:

  • scim 的狀態很詭異,在 Terminal 裡有時候可以用但有時候不能用,而在 Google Chrome 裡面是完全不能用。目前暫時拿 ibus 撐著。
  • 天氣的 indicator 好像要換掉,暫時沒有花時間研究。

對於沒有技術背景的人來說,升級的工程太浩大 (有大量的錯誤訊息要查,然後一個一個解決),還是建議當 Windows 的方法處理會比較好... (重灌未必比較慢,真的...)

在還沒摸熟前,公司的電腦應該還是維持在 12.04 吧,不然就是等下次連假的時候弄...