Tag: shell

Shell Script 裡面 [ "x$var" = "xval" ] 的歷史

看到「What exactly was the point of [ “x$var” = “xval” ]?」這篇，在講為什麼不直接寫 [ "$var" = "val" ] 而是會加上 x 而寫成 [ "x$var" = "xval" ]，被稱為 x-hack 的 workaround... (其實已經變成 best practice 了)

最常被拿出來講的是 - 開頭的字串，不過文章作者找到更多奇怪的 bug report，像是 ( 與 ) 之類的問題 XD

雖然作者提到大概在 2010 (或是 2015) 都修完了，但我應該還是會繼續這樣寫 (算是 best practice 了)，可以避免在遇到老系統上遇到問題...

AWS 推出 CloudShell

AWS 推出了 CloudShell，讓使用者可以繼承 IAM 的權限，在瀏覽器裡面用 command line 操作 AWS 資源：「AWS CloudShell – Command-Line Access to AWS Resources」。

使用方式很簡單，在 web console 上方的 icon 點下去就可以用了，只是第一次使用的時候會看到需要建立環境的訊息，會等比較久：

連進去後測了一下，看起來是跑一個 30GB Disk 與 4GB RAM 的 container 起來，/dev/cpuinfo 裡面可以看到是 Intel E5-2676 v3 的機器，以這個資訊來查，看起來可能是 m4 系列的機器。

網路的部份基本上對 internet 的 TCP 與 UDP 都可以通，但需要操作 raw socket 丟 ICMP 的 ping 與 mtr 就不會通了。

目前支援的區域只有這些，之後應該會陸陸續續再開放：

Regions – CloudShell is available today in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo) Regions, with the remaining regions on the near-term roadmap.

費用的部份，官方是說不需要另外的費用，只需要付出用到的 AWS 資源，但這邊沒給範例啊，到底是怎麼算的... 看了一圈 EC2、ECS、EKS 都沒有機器，應該是不會算到這邊？

Pricing – You can use up to 10 concurrent shells in each region at no charge. You only pay for other AWS resources you use with CloudShell to create and run your applications.

刷了一下的感覺是，對於已經習慣跳板機的人來說好像還好，尤其是 command line 已經用熟了，太習慣用 Ctrl-W 刪字串，而在瀏覽器裡面按下去就會直接出事的情況，還是有點難用...

比較明顯的好處應該是整合了 IAM 的權限，所以在 awscli 下的權限是一樣的，另外對於有些 web console 沒支援的操作可以用這個方法補強，而不需要自己弄機器出來跑。

第五堂：「Command-line Environment」

這個系列是從『MIT 的「The Missing Semester of Your CS Education」』這邊延伸出來的，這邊講的是「Command-line Environment」這篇。

開始聊之前先看一下其他的東西，我注意到這系列文章有簡體中文 (這裡，已經翻完) 與繁體中文 (這裡，還有幾篇還沒翻完) 的版本了，如果讀英文會比較累的人可以參考看看。

這堂講 command line 下的各種事情，感覺起來比起前面硬不少。

首先就先開始講 signal，各家系統的 signal 應該還是有些微差異，可以參考各家的 signal(7) (在 command line 下用 man 7 signal 可以列出來)。

這邊講的 signal 都比較通用，像是 SIGKILL 的殺傷力，SIGTERM 與 SIGQUIT，然後有提到 SIGHUP，但 SIGHUP 的設計慣例是拿來重讀設定檔好像就沒提到了...

接下來就帶過 tmux，只大概講了一下概念 (sessions、windows、panes) 與用法。

然後講 shell 的 alias 對於打造環境的幫助，以及 dotfiles 的設計。

後面講 SSH 的應用，然後還提到了兩個不同方向的 port forwarding。

這些對於初學者來說應該蠻有幫助的，第一次打造自己的 shell environment 的過程應該還蠻有趣的？(已經是很久前了...)

第二堂：「Shell Tools and Scripting」

這個系列是從『MIT 的「The Missing Semester of Your CS Education」』這邊延伸出來的，這篇文章講第二堂課「Shell Tools and Scripting」。

這堂有點像是第一堂的延伸，在講更多 shell 的操作與工具，然後說明 shell script 怎麼寫。

開頭就先說明有 function，然後講了不少 magic variable，像是 $0、$1 到 $9，而 $@ 與 $# 也提到了 (但居然沒提到 $*)，然後再來是 $$、!! 與 $_。

然後提到 true 與 false，接著就講條件 || 與 && 了。後面就開始講 shell 裡面的 for 與 if，基本上到這邊已經能寫不少東西了？

後面就介紹更多工具...

第一堂：Course overview + the shell

這個系列是從『MIT 的「The Missing Semester of Your CS Education」』這邊延伸出來的，這篇文章講第一堂課「Course overview + the shell」。

前面大概講一下這 11 堂各一個小時的課大概是什麼，後面就開始講 shell 下的操作了。

先講了一些基本指令 (date & echo)，然後提到了環境變數 $PATH，接著就講目錄結構與 ls，然後就順便提到 man 可以拿來查說明，接著是講 redirect 與 pipe 以及 root 權限的特殊性 (以及 sudo)。

在課程最後面的這個範例，你第一眼看不會想到是第一堂課就可以教完的東西，但的確是結合了上面提到的所有東西，可以細細品味一下：

$ echo 1 | sudo tee /sys/class/leds/input6::scrolllock/brightness

離開 Vim 的方法

先說明最基本的方法是按個幾下 Esc 確保離開 insert mode，然後輸入 :q 然後 enter 就可以離開。

在「How to exit vim」這邊則是創意大賽，尤其是前面幾個方式：

:!ps axuw | grep vim | grep -v grep | awk '{print $2}' | xargs kill -9

想練功的可以看一下指令，然後用 man 看一下說明學一些東西 XD

家裡電腦裝 Ubuntu 18.04

上個禮拜四家裡的桌機開不了機，找了一天發現是系統的 SSD 掛掉了，就買了張 M.2 SSD，然後計畫順便把本來的 Ubuntu 16.04 升級到 Ubuntu 18.04，但 Ubuntu 18.04 把預設的界面從 Unity 換成 GNOME (然後披上 Unity 的皮)，加上前陣子系統從 Intel 平台換到 AMD，整個狀況變得超混亂之後，就變成一連串踩地雷的過程...

最一開始是 UEFI + LUKS 的安裝問題，本來想裝到 M.2 SSD 上面，但 Ubuntu 18.04 的 grub-install 就是硬寫到 /dev/sda 不能改：「“Unable to install GRUB in /dev/sda” when installing GRUB」，照著這篇的 workaround 用還是不行，最後放棄，直接生一顆 SATA SSD 接到 SATA Port 1，把 M.2 當作資料碟。

硬體相關的問題：

軟體相關的問題：

  • 目前不支援從 GUI 設定 PPPoE 的網路 (沃槽)，幾種方式裡面我推薦用 pppoeconf 設定會比較好，然後可以改 /etc/ppp/options 加上 IPv6 的設定。
  • 本來想裝 gnome-shell-extension-system-monitor 觀察系統狀態，但會造成系統超級卡，關掉後就變成普通的卡 (後來就找到 Intel I211-AT 的那個問題了)。

現在至少是堪用的程度了，接下來就是不斷的補各種設定...

透過把 .git/safe/../../bin 加到 $PATH 執行程式

在「.git/safe」這邊看到的方式，想要方便執行 $GITROOT/bin 想法是：

  • 把 .git/safe/../../bin 放到 $PATH，如果可以順利解出來的話就是 repository 本身的 $GITROOT/bin。
  • 但一般是解不出來的 (因為 .git/ 裡面不會有 safe/ 這個目錄，所以預設是解不出東西的。而對於信任的 repository 則可以 mkdir .git/safe 讓 shell 可以搜尋到。

之所以可以這樣做的是因為：

  • .git 是保留字，從 command line 上你沒辦法塞 .git 目錄進到 repository 內，但不確定直接從 blob layer 塞會怎樣... (也就是得確認 checkout 時檢查的問題)

先寫起來看看好了，不過暫時應該也用不到...

在 AWS 強制使用 MFA 的情況下，透過 CLI 操作

AWS 可以設定 IAM 使用者強制使用 MFA (包括 API 的操作)，在這種情況下如果要使用 AWS Command Line Interface 就得透過 AWS STS (AWS Security Token Service) 產生另外一組 key + secret + session key，然後這組通行時間預設是 12 小時。

相關的文章可以參考「How do I use an MFA token to authenticate access to my AWS resources through the AWS CLI?」這篇，然後我就寫了一段 shell script 來做這件事情。

首先是在 ~/.aws/config 內放入 MFA 的 ARN，像是這樣：

[profile mycompany]
mfa = arn:aws:iam::012345678901:mfa/gslin
region = us-east-1

然後就可以用 aws.mfa mycompany 指令產生出一個會把 key + secret + session key 包進去的 shell：

function aws.mfa() {
    local MFA_ARN
    local MFA_TOKEN
    local PROFILE="$1"
    local STSDATA

    MFA_ARN="$(python3 -c "import configparser; import os; c=configparser.ConfigParser(); c.read('{}/.aws/config'.format(os.environ['HOME'])); print(c['profile ${PROFILE}']['mfa'])")
"
    echo "Reading ${PROFILE} and going for token ${MFA_ARN} ..."

    echo -n 'MFA Password: '
    read -r MFA_TOKEN

    STSDATA="$(aws --profile "${PROFILE}" sts get-session-token --serial-number "${MFA_ARN}" --token-code "${MFA_TOKEN}")"
    export AWS_ACCESS_KEY_ID="$(echo "${STSDATA}" | jq -r .Credentials.AccessKeyId)"
    export AWS_SECRET_ACCESS_KEY="$(echo "${STSDATA}" | jq -r .Credentials.SecretAccessKey)"
    export AWS_SESSION_TOKEN="$(echo "${STSDATA}" | jq -r .Credentials.SessionToken)"

    echo 'Running an independant shell...'
    ${SHELL}
}

很明顯的裡面用到了 Python 3 與 jq，這兩個應該都可以直接裝系統的版本就可以了。

後續的操作就跟原來的用法都一樣，像是 aws --region=us-east-1 s3 ls 這樣的指令。

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 做出來後就省下這件事情。