風險：隱蔽權限修改致使rgw服務中斷

上午正在開會，忽然收到rgw服務異常的告警（503 Service Unavailable），立馬停下來處理告警，避免影響到用戶~

 

咱們的rgw frontend用的是apache，以前也遇到過503的問題，經驗上反應出應該是/var/run/ceph的目前權限出了問題致使apache進程沒法訪問到rgw的fastcgi.sock文件，從而致使503。按這個思路去查，果真，全部rgw機子的/var/run/ceph（owner和group均爲ceph）的權限都從0777變成了0770！！！

恢復服務爲重，先把全部的權限修改正確，再細查權限變化的緣由~

那麼問題來了，究竟是誰修改了/var/run/ceph的權限？

嘗試在網上尋找相似的問題，沒有發現，自力更生~

嫌疑人	分析
人爲	rgw這些機子和服務是由我負責的，應該不會有人操做這些機子，暫時排除這個可能
cron任務	沒有找到可能作修改的週期性任務
ceph組件進程	ceph各組件已經穩定運行了一年多，服務一直正常，並且組件進程也沒有重啓過，組件進程修改的可能性較小
...	:(

當你迷茫的時候，不妨看看源碼，在ceph的源碼中搜索「/run/ceph」，發現了這樣的一個文件systemd/ceph.tmpfiles.d，內容是這樣的：

d /run/ceph 0770 ceph ceph -

咱們的/var/run/ceph目錄就是被改爲了0770權限，直覺告訴咱們，遇到的問題跟這個目錄有千絲萬縷的聯繫... 從ceph.spec.in看出，這個文件最終安裝成了/usr/lib/tmpfiles.d/ceph-common.conf ，涉及到systemd tmpfiles機制，臨時抱佛腳學習下 systemd tmpfiles機制 ~

d /run/ceph 0770 ceph ceph -
對於這條配置，開機時systemd-tmpfiles-setup服務會建立owner和group爲ceph、權限爲0700的目錄/run/ceph；而systemd-tmpfiles-clean服務會週期性（週期爲天，可經過systemctl list-timers --all查看）遍歷/run/ceph下的文件，根據配置來進行刪除，這裏配置的是「-」，意爲不進行刪除

而systemd-tmpfiles-setup服務最終執行的命令爲：

/usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev

作個測試，咱們建立了內容爲「d /run/test 0770 ceph ceph -」的文件/usr/lib/tmpfiles.d/test.conf，而後執行上述命令，果不其然，/run/test目錄建立出來了：

root@c144:~$ ll /run/ |grep test
drwxrwx--- 2 ceph ceph 40 Jan 17 09:26 test

咱們把/usr/lib/tmpfiles.d/test.conf內容改爲「d /run/test 0777 ceph ceph -」，再執行命令，權限發生了變化：

root@c144:~$ ll /run/ |grep test
drwxrwxrwx 2 ceph ceph 40 Jan 17 09:26 test

那問題又來了， 誰調用了/usr/bin/systemd-tmpfiles？

不賣官司了...是這樣的：

運維人員更新了systemd的rpm，而systemd rpm的post install腳本調用了該/usr/bin/systemd-tmpfiles，修改了/run/ceph的權限，而/var/run是軟鏈到/run的，最終致使了服務異常

rpm -q --scripts systemd:
...
systemctl start systemd-udevd.service >/dev/null 2>&1 || :
udevadm hwdb --update >/dev/null 2>&1 || :
journalctl --update-catalog >/dev/null 2>&1 || :
systemd-tmpfiles --create >/dev/null 2>&1 || :
...

風險屏蔽

臨時修改/usr/lib/tmpfiles.d/ceph-common.conf 文件的內容爲：

d /run/ceph 0777 ceph ceph -

蝴蝶效應

遇到問題要努力去解決而不能輕易放過，否則，它會出其不意給你一棒子~

關注筆者

專一筆者公衆號，閱讀更多幹貨文章：）