Salt 要做到「當某個檔案存在時,執行某個指令」的方法...

愈用愈有感覺 SaltStack 是一堆 workaround 的集合,一開始在設計整個系統時沒有規劃好,然後一直堆上去。

標題的這個問題是出自於 Ubuntu 預設會將 CPU 調節成 ondemand,方式是透過 /etc/rc*.d/ 下的 symbolic link 在開機時自動執行。

拔掉的方法是 updated-rc.d ondemand disable (而非直接砍掉 /etc/rc*.d/ 裡面的檔案),想要透過 SaltStack 提供的 file.exists 或 file.missing 都發現不可行。

最後是 cmd.run + onlyif + test 搞定:

ondemand-disable:
  cmd.run:
    - name: update-rc.d ondemand disable
    - onlyif: test -e /etc/rc2.d/S99ondemand

SaltStack 對於 dependency 的設計看起來問題重重,如果想要用 SaltStack 的人可以好好考慮一下。

現在的作法是直接 trial and error 跟他拼,PuppetChefSaltStack 都直接用時間跟他換。原因是這東西實在太底層了,架構不好就是上面的管理員與 DevOps 一直 workaround。

現在有種互相在比爛的感覺...

YAML 的地雷

因為碰 SaltStack,而官方建議用的格式是 YAML (雖然也支援 JSON,但文件幾乎都是 YAML),所以被迫要學一堆奇怪的 YAML hack,在官方文件上甚至寫了一篇「YAML Idiosyncrasies」讓大家參考,用 Idiosyncrasies 這個詞彙比較中性,但需要專文來寫就可以想像 YAML 有多 !@#$%^...

然後文章裡面也發現 SaltStack 在亂搞,於是就快起笑了...

首先是建議 indent 為 2 spaces,另外禁用 tab,這些到是沒什麼好抱怨的。但 dict 的設計就讓人崩潰,像是這樣的結構:

foo:
  - bar:
    baz1: abc
    baz2: def

你以為對應的 JSON 是:

{
  "foo": {
    "bar": {
      "baz1": "abc",
      "baz2": "def"
    }
  }
}

但實際對應的 JSON 中,bar、baz1、baz2 視同一層:

{
  "foo": {
    "bar": null,
    "baz1": "abc",
    "baz2": "def"
  }
}

因為其實對應的 YAML 是:

foo:
  - bar:
  - baz1: abc
  - baz2: def

你就不能把最上面的 YAML 定義成 syntax error 嗎... =_=

接下是 SaltStack 的惡搞時間,因為 YAML parser 會把 644 當作數字傳進去,所以這樣的設定:

/etc/vimrc:
  file:
    - managed
    - source: salt://edit/vimrc
    - mode: 644

SaltStack 會收到 644 (十進位),而如果你寫成 0644 時,就會被讀成八進位,也就是 420 (十進位):

/etc/vimrc:
  file:
    - managed
    - source: salt://edit/vimrc
    - mode: 0644

我覺得後面這個是比較正確的寫法,所以應該要會動,但 SaltStack 對這部份 workaround,會變成 chmod 420 /etc/vimrc,然後就噴飯了...

另外 2013_01_12 這種字串會被解讀成 20130102 (十進位),這會不會太歡樂...

反正用下去後應該會再踩更多地雷,繼續看下去吧...

SaltStack 的 Masterless 模式

最近在試 SaltStack,先從 Masterless 模式開始玩,可以拿來練習寫 SaltStack 專門的 sls 檔。相關的文件可以參考「Standalone Minion」這篇。

我是裝 Ubuntu 14.04.1 LTS,然後用 ppa 裝 SaltStack 最新版,避免與與官方的文件差異太大:

# apt-add-repository ppa:saltstack/salt
# apt-get update
# apt-get install salt-minion

然後建立 /srv/salt 後就可以在這個目錄下面開始做事。這個目錄是 SaltStack 的預設值 (可以參考 /etc/salt 下面的檔案),所以不需要另外再設定:

# mkdir /srv/salt
# cd /srv/salt

SaltStack 讀取的起點預設是 top.sls,這個檔案預設的格式是 YAML

base:
    '*':
        - default

然後就可以寫 default.sls

most:
  pkg:
    - installed

locale:
  cmd.run:
    - name: locale-gen zh_TW.UTF-8

然後在機器上呼叫 salt-call 執行:

# salt-call --local state.highstate

或是開 debug 訊息:

# salt-call --local -l debug state.highstate

這樣就可以看到各種輸出結果了。這樣應該就會看到 most 被裝起來,另外 zh_TW.UTF-8 的 locale 應該也會生出來。

SaltStack 與 Ansible 的比較

也忘記在哪邊看到的,反正是留在 browser 上的連結。

puppet 跳槽,因為 SaltStack (Salt) 與 Ansible 都是使用 Python 而被選擇,然後完整比較後記錄下來:「Moving away from Puppet: SaltStack or Ansible?」。

先說結論,最後看起來是選擇了 Salt:

At this point both Salt and Ansible are viable and excellent options for replacing Puppet. As you may have guessed by now, I’m more in favor of Salt.

作者花了相當多的時間比較得到結論,包括從 puppet porting 一個完整的部份 (不是全部,不過還是為數可觀的部份),以及 porting 中間發現問題後開 ticket 詢問。除了技術面上的評估外,還包括了 community 的態度... (其實是狂婊 Ansible... XDDD)

htpasswd 的 SHA 不會帶 salt (seed)...

剛剛發現 htpasswd (Apache.htpasswd 檔案產生程式) 提供的 SHA-1 不會使用 salt,不過 MD5 格式會...

以密碼「test」測試:

gslin@colo-p [~] [17:44/W7] touch test.txt
gslin@colo-p [~] [17:44/W7] htpasswd -b -m test.txt test1 test
Adding password for user test1
gslin@colo-p [~] [17:44/W7] htpasswd -b -m test.txt test2 test
Adding password for user test2
gslin@colo-p [~] [17:44/W7] htpasswd -b -s test.txt test3 test
Adding password for user test3
gslin@colo-p [~] [17:44/W7] htpasswd -b -s test.txt test4 test
Adding password for user test4

結果是:

test1:$apr1$GU6SyO0y$I.Ng9o4H8Tcje.M2A6ECb0
test2:$apr1$uqoX9b/x$7zGMAKqRjvoi6HHSKtaRO.
test3:{SHA}qUqP5cyxm6YcTAhz05Hph5gvu9M=
test4:{SHA}qUqP5cyxm6YcTAhz05Hph5gvu9M=

依照說明,htpasswd 使用的 SHA 是移植自 Netscape server 的 LDAP Directory Interchange Format (ldif):

Use SHA encryption for passwords. Facilitates migration from/to Netscape servers using the LDAP Directory Interchange Format (ldif).

在安全疑慮 (Security Considerations) 上也有註明 htpasswd 使用的 SHA 是不帶 salt:

The SHA encryption format does not use salting: for a given password, there is only one encrypted representation.

現在密碼儲存應該是朝 bcryptPBKDF2 發展,參考依林姊姊的「請愛用 bcrypt 和 PBKDF2」,後者 PBKDF2 被用在 WPA2 上。