把自己的 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 也得等摸索差不多後更新...

Trac 1.4

剛剛看到 Trac 出了 1.4 的消息,雖然還是在用 Python 2:「Release Notes for Trac 1.4 Jinja Release」。

其中一個比較大的改變是 template engine 換掉了,從 Edgewall 自家的 Genshi 換到 Jinja2 上,目前看起來兩者都可以用,但可以預期現有的 template 要找時間換過去:「5 times speed-up when rendering query results, thanks to the migration from Genshi to Jinja2.」。

其他的改變應該還好,找個週末來把自己的 Trac 備份起來測試好了...

Algolia 從 Heroku 搬到 GKE 的故事

Algolia 是一個搜尋引擎服務,他可以幫你 index 資料後,你直接 query 他取得結果。

在這篇文章裡 Algolia 決定從 Heroku 搬到 GKE:「The Challenging Migration from Heroku to Google Kubernetes Engine」。

在文章只單純就產品與技術面上的需求在討論,像是一開始討論 IP 白名單的問題:

A good example of this complexity is with IP Whitelisting. One of our customers wanted us to crawl from a fixed IP address so that they could whitelist that IP for high-rate crawling without being throttled by their load balancer. Only two engineers were developing the crawler, so we asked other colleagues to set up an HTTP proxy with a fixed IP address. Yet, as the number of customers grew, many more started asking for the same thing, and our infrastructure team told us it was time for us to take care of it ourselves.

不過我更想知道搬過去後的各類成本差異... 省了多少平台費用,以及多少維護人力的差異,不過看起來沒提到 XD

CVE-2018-14665:setuid 複寫檔案的 security issue...

Twitter 上看到的 security issue,好久沒在這麼普及的軟體上看到這種 bug 了:

CVE - CVE-2018-14665 的說明裡面有提到 1.20.3 前的版本都有中,但沒講到從哪個版本開始,看起來是全系列...?

A flaw was found in xorg-x11-server before 1.20.3. An incorrect permission check for -modulepath and -logfile options when starting Xorg. X server allows unprivileged users with the ability to log in to the system via physical console to escalate their privileges and run arbitrary code under root privileges.

這一臉 orz...

Trac 關票時的資訊...

Trac 關票時一般都是由開票的人關 (i.e. Reporter),今天遇到的情況是這樣,在關票時的畫面上你會不知道是誰開的:

只要往上一點拉就會看到 Reporter 資訊 XD 這通常會發生在螢幕沒打直的人,直接拉到最下方的情況 XD

試著用 CSS 的 position: sticky 但抓不太到要的效果,決定還是開 jQuery 下去解決 XD

        // Copy reporter information to action section
        if ($('#action_resolve_resolve_resolution').length > 0) {
            var reporter = $('#h_reporter').parent().find('.trac-author, .trac-author-user')[0].outerHTML;

            $('#action_resolve_resolve_resolution').each(function(){
                $(this).parent().append('<span class="hint">(This ticket is created by ' + reporter + ')');
            });
        }

當下寫得很隨性,之後也許會再改... (會更新到「Trac - Gea-Suan Lin's Wiki」這邊)

Trac 的 DuplicateTicketSearchPlugin

DuplicateTicketSearchPluginTrac 的 plugin,在開新票時會搜尋系統內可能重複開過的票給出建議。

之前在寫 wiki 上的「Trac」條目時沒寫到,大概是最早的時候都沒裝,後來有人找出來要我裝的東西,所以印象沒那麼深刻。剛剛是在找 Trac + Elasticsearch 有沒有現成的方案可以搭,結果先看到這個...

產生的效果是這樣,在改變 summary 後會出現 (focus 從 summary 移開時):

當然就算裝了還是難免會重複開 (尤其組織夠大的時候),但算是有幫助的東西...

Trac 1.2 的 Due Date...

在先前的文章提到了把自己在用的事件管理系統 Trac 從 1.0 升級到 1.2,然後 Due Date 的設計改變了:「Trac 1.1 增加的 time 欄位,以及 Due Date 資料的轉移」、「總算把手上的 Trac 1.0 升級到 1.2 了...」。

Trac 1.2 的資料型態是在底層存 unix timestamp 的變形 (乘以 1000000,然後前端補上 0 存成文字),這幾天用下來才發現一些以前沒遇到的問題。

一開始轉到 Trac 1.2 是設成 date,但意外的發現 (因為伺服器時間不是 UTC),不同時區的使用者在更新 ticket 時,系統會判定 Due Date 有變動而產生變更記錄,想了一下就改用 datetime 來處理這個問題。

用了 datetime 一陣子後,才發現先前的公司遇到的情境中,時區差異都很小,所以不會有 Due Date 理解上的問題 (像是從 +7 到 +9 的時區),如果今天是美國西岸跟台灣互相合作的話,只用 date 就會產生很明顯的理解問題了...

算是這陣子用 Trac 1.2 而對 Due Date 設計有不一樣的理解...

KPTI (Meltdown Mitigation) 對 MyISAM 的痛點

MariaDB 的「MyISAM and KPTI – Performance Implications From The Meltdown Fix」這篇看到頗驚人的數字,這篇提到了他們收到回報 (回報的 ticket 可以參考「[MDEV-15072] Massive performance impact after PTI fix - JIRA」),說 KPTI (Meltdown Mitigation) 對 MyISAM 效能影響巨大:

Recently we had a report from a user who had seen a stunning 90% performance regression after upgrading his server to a Linux kernel with KPTI (kernel page-table isolation – a remedy for the Meltdown vulnerability).

他們發現 90% 是因為 VMware 舊版本無法使用 CPU feature 加速,在新版應該可以改善不少。但即使如此,文章內還是在實體機器上看到了 40% 的效能損失:

A big deal of those 90% was caused by running in an old version of VMware which doesn’t pass the PCID and INVPCID capabilities of the CPU to the guest. But I could reproduce a regression around 40% even on bare metal.

然後後面就在推銷 MariaDB 的 Aria Storage Engine 了,不是那麼重要... 不過知道 MyISAM 在 KPTI 下這麼傷還蠻重要的,因為接下來五年應該都還是愈的到 KPTI,應該還是有人在用 MyISAM...

SSL Certificate 的認證方式限縮

在「Ballot 218 - Remove validation methods 1 and 5 - CAB Forum」看到「Ballot 218: Remove validation methods #1 and #5」這則議案以 78% 的同意票通過,限縮 SSL Certificate 的認證方式。眼睛瞄到中華電信投下反對票:

14 Yes votes: CFCA, Cisco, Comodo CA, D-TRUST, DigiCert, GDCA, GlobalSign, GoDaddy, Izenpe, Let’s Encrypt, Logius PKIoverheid, SSL.com, TrustCor, Trustwave

4 No votes: Buypass, Chunghwa Telecom, Entrust Datacard, SwissSign

4 Abstain: Actalis, Disig, HARICA, OATI

78% of voting CAs voted in favor

找了一下在 BR (Baseline Requirements) 的 3.2.2.4.1 與 3.2.2.4.5,其中前者是透過註冊商認證:

3.2.2.4.1 Validating the Applicant as a Domain Contact

Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact directly with the Domain Name Registrar.

後者是透過文件認證:

3.2.2.4.5 Domain Authorization Document

Confirming the Applicant's control over the FQDN by relying upon the attestation to the authority of the Applicant to request a Certificate contained in a Domain Authorization Document.

在想投下反對的原因,會不會是因為中華自己的 domain 應該都是透過後者方式發的?透過內部公文系統...

Linus (又) 不爽了... XD

看得出來 Linus 對於 Intel 的行為很不爽:「Re: Avoid speculative indirect calls in kernel」。

Please talk to management. Because I really see exactly two possibibilities:

 - Intel never intends to fix anything

OR

 - these workarounds should have a way to disable them.

Which of the two is it?

那個 possibibilities 應該是 typo,但不知道為什麼看起來很有味道 XDDD