Home » Posts tagged "system"

AWS 推出可以直接操作機器的 Shell Access

AWS 推出了 Shell Access,讓你可以直接操作 EC2 上的機器,而且又符合稽核上的要求:「New – AWS Systems Manager Session Manager for Shell Access to EC2 Instances」。

看起來機器上只要有 ssm-agent 就可以做這件事情了。在官方的圖可以看到用法:

另外 AWS 也在開發新的功能,一個是繞過 security group 的 SSH client:

SSH Client – You will be able to create SSH sessions atop Session Manager without opening up any inbound ports.

另外一個是給外部機器用的版本:

On-Premises Access – We plan to give you the ability to access your on-premises instances (which must be running the SSM Agent) via Session Manager.

這功能最主要還是稽核面的需求... 以前要作到這件事情會需要透過跳板之類的東西記錄使用者行為,現在 AWS 做出來後就省下這件事情。

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」這邊)

沒有 Google 專屬套件的 Android

剛剛在「How to Android without Google」這邊的文章裡看到「How to Android without Google [easy way]」這篇指南,說明如何弄出一個沒有 Google 專屬套件的 Android 環境。

主要是 LineageOS 當作底層基礎 (作業系統),然後用 microG 提供 API 相容層,並且用 F-Droid 安裝 Open Source 軟體。

裡面有兩個方案以前沒看過,一個是 XPosedFramework,提供框架讓使用者有更強的控制力,更完整的說明可以參考「Xposed Framework + App Settings 為每個 App 設定不同的運行模式」這篇。

另外一個是 Yalp Store,當軟體只在 Google Play 平台上提供安裝的時候,就需要透過這個套件了 XD

Amazon EFS 在首爾先開了...

Amazon EFS 其實就是 AWS 提供的雲端版 NFS 或是 CIFS,這對於某些應用來說很好用,尤其效能不是主要考量時,像是從外面買來的商用軟體需要找個空間放資料...

不過沒想到在亞洲第一個開的點居然是首爾 (i.e. ap-northeast-2):「Amazon Elastic File System (Amazon EFS) Available in Asia Pacific (Seoul) Region」。

提到 AWS 的首爾區,台北過去的直線距離雖然比大阪與東京都近,但各家的路由都是從日本繞過去,不然其實首爾的點應該會是台灣的首選... 不曉得北京與上海到首爾的連線情況又是如何,找機會開台機器測試看看。

Trac 的 DuplicateTicketSearchPlugin

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

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

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

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

把 git log 用得很開心...?

看到「git log – the Good Parts」這篇文章,裡面研究了 Gitgit log 的各種好用的功能,然後整理出來... (所以是 good parts XD)

作者用的參數是一個一個加上去,所以可以一個階段一個階段了解用途。除了可以用作者推薦的 repository 測試外,我建議大家拿個自己比較熟悉的 open source 專案來測 (有用到比較複雜的架構):

git log
git log --oneline
git log --oneline --decorate
git log --oneline --decorate --all
git log --oneline --decorate --all --graph

看到喜歡的部份可以在 ~/.gitconfig 裡設 alias 使用,像是用 git l 之類的?保留 git log 本身可以避免一些 script 用到這個指令時因為輸出格式跟預期不一樣而爛掉 XD

Qubes OS 4.0 推出

也是個放在 tab 上一陣子的連結,Qubes OS 推出了 4.0 版:「Qubes OS 4.0 has been released!」。這個作業系統的副標蠻有趣的,不是「絕對安全的作業系統」,而是用了 「reasonably」這樣的描述:

A reasonably secure operating system

主要是透過虛擬機隔離,但實做了常見會因為虛擬機而被擋下的功能,像是讓你可以直接剪下貼上。而界面上也是儘量做成無縫,像是這張 screenshot 就可以看到三個環境,但儘量給出視窗的感覺,而非 VM 的感覺:

有機會重灌的時候再說好了,系統轉移好累... Orz

一路從 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 的升級意外的順利?雖然是一步一步升,但沒遇到什麼大問題...

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 設計有不一樣的理解...

Archives