壞習慣記錄_01 - 不要用文字編輯器改 /etc/sudoers & /etc/sudoers.d/*，要用 visudo

前言：這是新開的篇章，主要是要讓自己修正自己以前的壞習慣…XD

如標題所示，在下知道這是老狀況了，但不得不說，人…果然不是可以被信任的生物

狀況發生是這樣的…

因為一些狀況，在下想要讓 A 帳號可以使用 sudo -u B 來執行某個程式(假設要用python)，但要不用需入密碼確認，所以就要去增加

A ALL=(B) NOPASSWD: /usr/bin/python

在 /etc/sudoers 中…

而且，在下本來還想到以前的經驗是不要用文字編輯器直接改 /etc/sudoers ，以免造成系統鎖住 sudo 指令，然後想到現在有 /etc/sudoers.d 可以個別載入…然後就用 nano 開了 /etc/sudoer.d/A 來寫上述的東西…一存檔就屎了…

當下是不緊張，因為以前的經驗是可以用

pkexec visudo

來修正…但在下是在 AWS EC2 的環境，ubuntu 的帳號是用 key-pair 的方式，所以沒有自己的密碼…而上面的指令是需要輸入用戶密碼的

好啦，這時內心有點小激動了…但想到「沒關係，還可以用 root 去改」就又冷卻了下來

結果，root 當在 instance 用好後沒去用過，所以 root 預設是沒密碼的，「su -」是要輸入密碼的，空密碼是不允許的…

這時內心真的不只激動了，暴動都有了

然後，就馬上 google 「aws /etc/sudoers syntax error near line 1」的關鍵字來找有沒有救援方式，而且還要是適合 aws ec2 的這種…

搜尋的第一則就是來自 AWS 官方的…原來這狀況已經是基本狀況了，呵呵

詳細的操作還是要依官方說明，以下在下只是簡略的概述

• 先把有狀況的 instance(以下都稱 s) 給停止，並記下 s 所使用的 volume ebs id
• 不過，如果是有多 volume 的，主要是記下有存放 /etc 的那一個
• 切記，如果多 volume 的，要記下這個 volume 是掛在 /dev/sda[x] 的哪一個，device name 要記住，最後會用到
• 到左列硬碟 ebs 選單，找到上面的 ebs id後，進行 detach 的動作
• 接著回到 instance dashboard，找一台機器或新增一台(建議是新增的)，記下 instance id
• 留意，這台救援用的 instance 要和 s 是同一個 zone
• 再回到硬碟 ebs，進入前面被 dispatch 的 ebs，然後進行 attach 動作，目前 instance 選前一步要拿來救援的的 instance，然後可以以預設或自定 device id(name?)
• 這個 device id(name?) 雖說可以自定，但上面也有說明在一些比較新的系統還是會被修正為 /dev/xvdf
• attche 完成後，就可以連上救援的系統中，然後執行 lsblk 來看一下目前線上的 device name 與其 volume
• 確定 /dev/xvdf 或自訂的 device name 和 volume 有出現在列表上後，就可以依 os 的不同而進行將 volume 掛載進來
• amazon linux, ubuntu, debian
• sudo mount /dev/xvdf1 /mnt
• amazon linux 2, centos 7, 8,  suse 12, rhel 7, 8
• sudo mount -o nouuid /dev/xvdf1 /mnt
• 再來將指定區域 on 起來再換到這顆掛載硬碟的 root 去
• for dir in {/dev,/dev/pts,/sys,/proc}; do sudo mount -o bind $dir /mnt$dir; done
• sudo chroot /mnt
• amazon 官方教學此行沒有加上 sudo ，但在下自己測試時是得加上去的，因為到目前為止在救援的這台的身份都還只是 ubuntu ，並非 root
• 看到切換成功的訊息後，就可以發現目前的環境已換到有 sudoers 問題的那系統的硬碟中了，也就是換到 s instance 的硬碟環境了，此時就可以進行修正，也因為是 chroot 過來的，所以目前身份就是 s 的 root
• aws 提供兩個解法
1. 直接執行 visudo 去修正 s 的 /etc/sudoers 的問題
• 在下採用這個，因為事實上在下是先執行了 visudo 發現，原本的 /etc/sudoers 根本就沒載入 /etc/sudoers.d 的東西，這是被 remark 起來的，之前的狀況單純只是 linux 的防護機制引發的，所以當在下看了一遍 /etc/sudoers 沒狀況而離開 visudo 後，visudo 就有提醒 /etc/sudoers.d/A 有修改記錄，問要不要去修正
• 當下就確定去修正，然後看了一下確定沒有寫錯，但為了保險先刪除原本寫的
2. 以救援這台 instance 的 /etc/sudoers 去蓋過 s 的 /etc/sudoers
• 在下沒使用這個，因為原本的 sudoers 還有別的設定，不想重設
• 改好且離開 visudo 後，就可以進行解掛載 s 的硬碟的動作了
• for dir in {/dev,/dev/pts,/sys,/proc}; do sudo umount /mnt$dir; done
• 一樣的狀況，aws官方在 umount 前沒 sudo ，但在下遇到的狀況需要加上 sudo ，而且前面 mount 時官方就有加上 sudo…
• 這邊有時可能會遇到這四個區域系統回報有其中幾個還在 busy，切記不要直接進行下一步，可以稍等幾分鐘再以「sudo umount /mnt/{dev, dev/pts, /sys, /proc}」來一個一個再確認一次沒有出現 busy 了再進行下一步
• sudo umount /mnt
• 這邊的 sudo 是 aws 官方本來就有的，但前面做 mount 時就沒有，還要自己加
• 這時就可以回到左邊碟硬 ebs 的選單把 s 的硬碟再給 detach 掉，然後再 attach 回 s 的 /dev/sda1(或原本它的 device name)
• 雖然是雲系統，但在下還是建議要 detach 前先把救援的這台先關機停止，然後再 detach
• 然後啟動 s instance，啟動完畢後就登入試試 sudo，理論上應該就不會再出現「syntax error」的訊息了