てんこ

ブログ名は愛猫(てん)の愛称です。中身は個人のIT系学習記録です。

AnsibleでFortigateのポリシーを設定してみた(その1)

前回に引き続き、AnsibleでFortigateの設定をしてみました。

なかなか素敵なハマりをしたので、ご紹介しつつ。

入れ替え(move)とか並び順とかはその2を別で書こうと思いますので、まずはスタンダードなところから。

■間違い探し

みなさんは、以下の2つのポリシーの違いは判りますか…?

Ansible関連の実践記事一覧はこちら


目的

AnsibleでFortigateのFirewallポリシーを設定できるか試すため

環境

  • ansible: 2.9.0
  • Fortios: 6.0.6
  • ansibleのコネクションプラグイン: local(fortiosapiライブラリ利用)

実践

Firewallポリシーの追加・削除に利用するモジュール

ansible2.8にリリースされた、fortios_firewall_policyモジュールを利用します。

モジュールの公式リファレンスはこちら

ansible2.9からstateなどが加わっているようです。むしろ、これまでは削除ってどうしてたんだろう…

ポリシーの追加

以下のようなPlaybookでポリシーの追加が可能です。

---
- hosts: localhost 
  gather_facts: false
  vars:
    host: "10.254.254.254"
    username: "admin"
    password: "password"
    vdom: "root"
    ssl_verify: "False"

  tasks:
  - name: Configure Firewall Policy(add).
    fortios_firewall_policy:
      host: "{{ host }}"
      username: "{{ username }}"
      password: "{{ password }}"
      vdom: "{{ vdom }}"
      ssl_verify: "{{ ssl_verify }}"
      state: "present"
      firewall_policy:
        policyid: "1"
        srcintf:
          - name: "internal"
        dstintf:
          - name: "wan1"
        srcaddr: 
          - name: "all"
        dstaddr: 
          - name: "all"
        service:
          - name: "ALL"
        schedule: "always"
        logtraffic: "disable"
        fsso: "disable"
        action: "accept"
        status: "enable"

ポリシーの削除

stateをabsentにして、policyidだけ書けば削除が可能でした。

---
- hosts: localhost 
  gather_facts: false
  vars:
    host: "10.254.254.254"
    username: "admin"
    password: "password"
    vdom: "root"
    ssl_verify: "False"

  tasks:
  - name: Configure Firewall Policy (Delete)
    fortios_firewall_policy:
      host: "{{ host }}"
      username: "{{ username }}"
      password: "{{ password }}"
      vdom: "{{ vdom }}"
      ssl_verify: "{{ ssl_verify }}"
      state: "absent"
      firewall_policy:
        policyid: "1"

ポリシーの編集

編集したいポリシーのpolicyidを指定することで、上書きすることが可能でした。

---
- hosts: localhost 
  gather_facts: false
  vars:
    host: "10.254.254.254"
    username: "admin"
    password: "password"
    vdom: "root"
    ssl_verify: "False"

  tasks:
  - name: Configure Firewall Policy (modify).
    fortios_firewall_policy:
      host: "{{ host }}"
      username: "{{ username }}"
      password: "{{ password }}"
      vdom: "{{ vdom }}"
      ssl_verify: "{{ ssl_verify }}"
      state: "present"
      firewall_policy:
        policyid: "1"
        srcintf:
          - name: "internal"
        dstintf:
          - name: "wan1"
        srcaddr: 
          - name: "all"
        dstaddr: 
          - name: "all"
        service:
          - name: "SSH" # もともとは”ALL"
        schedule: "always"
        logtraffic: "disable"
        fsso: "disable"
        action: "accept"
        status: "enable"

↓変更後のポリシー

冪等性があるか?

全く同じPlaybookを2回実行しても、changed=1になってしまいました…

とはいえ、結果的には同じ内容になるので、changedになるのを知ってさえいれば問題なさそうです。

わかったこと

想像通りな感じで、ポリシーについては、それほど支障なく追加・削除・編集はできそうです。

また、連続でPlaybook書いてると、やっぱりhttpapi側に切り替えたくなってきました…長い…

httpapiで操作する環境についてのブログをよこちさんが書いてくださったので、そちらも参考にしてください!

tekunabe.hatenablog.jp

ただ、公式なこのモジュールの説明見ても、httpapi使えるとは書いてないんですよね。修正漏れなのか、本当に使えないのか…httpapiの環境が動いたらやってみます。

気を付けていただきたいこと

ansibleによるFortigateの操作は、原則としてFortigateのREST APIを利用しており、これはCLIとは異なります。

なので、しっかりと動作試験を行ったうえで利用してください。やってはいけない例を1つご紹介します。

やってはいけないPlaybook

以下のようなPlaybookを実行したとします。

---
- hosts: localhost 
  gather_facts: false
  vars:
    host: "10.254.254.254"
    username: "admin"
    password: "password"
    vdom: "root"
    ssl_verify: "False"

  tasks:
  - name: Configure Firewall Policy Ng Pattern (Removed at Reboot).
    fortios_firewall_policy:
      host: "{{ host }}"
      username: "{{ username }}"
      password: "{{ password }}"
      vdom: "{{ vdom }}"
      ssl_verify: "{{ ssl_verify }}"
      state: "present"
      firewall_policy:
        policyid: "1"
        srcintf:
          - name: "internal"
        dstintf:
          - name: "wan1"
        srcaddr: 
          - name: "all"
        dstaddr: 
          - name: "all"
        service:
          - name: "ALL"
        action: "accept"
        status: "enable"

↓実行結果はok,changedで成功した時と同じような感じ。

-vつけてもこんなかんじ。ステータスコードは200でSuccess。

このときのWebUIの画面(これが冒頭で出した、NGなポリシーのもの)

この状態で再起動するとどうなるか?

以下のようなログが出ます。

再起動するとポリシーはどうなるか?

消えます…

Configからも消え去ります。

なぜこうなるのか?

REST APIを使うことで、CLIでカバーされているエラーチェックが動かないことが主な要因のようです。

この状態のConfigは以下のようになります。

config firewall policy
    edit 1
        set uuid ee645184-fec9-51e9-d467-0b6fb1a24d6d
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set service "ALL"
    next
end

キーとなるのはなんなのか?

あまり細かくは試していませんが、NGなPlaybookの中に「schedule: "always"」だけ加えたら、再起動後も設定は維持されていました。

CLIだとどうなるか?

CLIで同じように、「schedule」の指定を抜いた状態でendしようとすると、怒られました。

この状態でポリシーは動作するのか?

pingレベルでは動いてしまいました…(1.1.1.254は暫定で付与したwan1のIP)

やってはいけないことをやってみて

アンチパターンは貴重な財産ですね。

今回のは、CLIで普段設定する人からすると当たり前かもしれませんが、Playbookを手抜きしていた結果、見つけることができました。

今後もこういうのを見つけたらどんどん載せていきたいと思います。

AnsibleでFortigate(Fortiosモジュール)を触りはじめてみた

Ansible2.8以降で、fortios系のモジュールが大量に追加されています。

つい先日リリースされた2.9でも、さらに200以上のfortios用モジュールが追加されました。

ただ、「ansible fortigate」とかでググっても、日本語情報はよこちさんの「てくなべ/Qiita」(いつもお世話になっております!)しかヒットせず、それも随分昔の記事だったこともあり、実際に国内で利用されているのか???な状況でした。

なので、怖いもの見たさでいろいろと調べ始めました。

今後、Fortigate系でansibleによる自動化を実践してみた結果をちまちまと上げていこうと思いますが、今回は実際の利用前にいろいろと調べた結果を中心に書いてみます。

Ansible関連の実践記事一覧はこちら。

Ansible自動化の実践記事一覧 - てんこ


目的

AnsibleでのFortigate自動化について調べた結果を整理するため

検証環境

  • ansible: 2.8.6 / 2.9.0
  • pip: 19.3.1
  • Fortios: 6.0.6

Ansibleリリースバージョンとfortios系モジュール数の推移

fortios系モジュールはこのページから確認できます。

ざっと調べてみたところ、以下のような結果になりました。

Ansible Version 2.3 2.4 2.5 2.6 2.7 2.8 2.9
追加モジュール数 2 1 0 1 0 219 204
メインライブラリ pyFG netaddr - fortiosapi - fortiosapi fortiosapi

Ansible2.3系から少しだけモジュールは存在しましたが、2.8から一気に増えているのがわかると思います。

必要になるライブラリとしては、pyFG / fotriosapiなどがあるようです。

補足(httpapiについて)

実際には、ansible2.9からfortiosもhttpapiというコネクションプラグインに対応したため、ライブラリ無しでも動くようになったようです。(流石よこちさん)

公式ドキュメント側のhttpapiに関する説明はこちら↓。確かにfortiosも含まれてますね。

Httpapi plugins — Ansible Documentation

今回はfortiosapiベースで書いていますが、今後書くときはどちらなのか冒頭に明記していきたいと思います。

動作環境の整備

pyFGライブラリの導入→検証環境だと失敗

以下のGitHubで公開されているライブラリです。

github.com

中身については、paramikoのssh接続を利用したライブラリのようでした。(違ってたらすみません)

導入方法については、以下の通り。

pip install pyfg

ただ、検証環境でリファレンス通りに導入しようとすると、以下のようなエラーが発生しインストールに失敗しました。(画像内は一部省略済み)

見た感じだとインストール時にimportすべきライブラリがない、というエラーのようです。おそらく対処方法はあるのだと思いますが、私も詳しくないため、まずは華麗にスルーします。

pyfgで出来ることは限られていますし、2年以上アップデートもされていないため、ここにはあまり手をかける理由もないかな、とも思いました。

fortiosapiライブラリの導入

以下のGitHubで公開されているライブラリです。

github.com

上記URL内に以下のような記述もあり、非常に心強い感じです。実質メーカー公式ライブラリ&モジュールと言っても差し支えない!

Known Usage

Fortiosapi library is used in Fortinet Ansible modules and in Cloudify plugins. Maintained mainly by Fortinet employees.

とはいえ、コミュニティモジュールでありREDHATさんのサポート対象外なのはご注意ください。

こちらは、Fortigate のREST APIを利用するライブラリです。

導入方法については、以下の通り。

pip install fortiosapi

こちらは問題なく導入することができました。

(ansible28) ansible@ENVY360:~/ansible-study$ pip install fortiosapi
(略)
Collecting fortiosapi
  Downloading https://files.pythonhosted.org/packages/53/10/0647648a7e199cff5389d697d03553c41e682d14be475287377041d10a99/fortiosapi-1.0.1-py2.py3-none-any.whl
(略)
Installing collected packages: urllib3, certifi, chardet, idna, requests, oyaml, pynacl, bcrypt, paramiko, fortiosapi
Successfully installed bcrypt-3.1.7 certifi-2019.9.11 chardet-3.0.4 fortiosapi-1.0.1 idna-2.8 oyaml-0.9 paramiko-2.6.0 pynacl-1.3.0 requests-2.22.0 urllib3-1.25.6
(ansible28) ansible@ENVY360:~/ansible-study$ 

動作確認(疎通試験)

サーバ系のものと異なり、pingモジュールみたいな疎通試験的に使えるものがansible2.8の頃のモジュール群では見つからず後述する色々に悩まされてました。

ansible2.9で新たに実装された"fortios_facts"モジュールが疎通試験的に利用できそうだったため、情報が取れるかやってみました。

なお、利用ライブラリは「fortiosapi」側です。Legacy Modeと呼ばれる状態で利用しています。そのため、Playbookもその書式で書いています。

---
- hosts: localhost 
  gather_facts: false
  vars:
    host: "10.254.254.254"
    username: "admin"
    password: "password"
    vdom: "root"
    ssl_verify: "no"

  tasks:
  - name: Get Facts.
    fortios_facts:
      host: "{{ host }}"
      username: "{{ username }}"
      password: "{{ password }}"
      vdom: "{{ vdom }}"
      ssl_verify: "{{ ssl_verify }}"
      https: "yes"
      gather_subset:
        - fact: 'system_status_select'
    register: getfact_result

  - name: Debug
    debug: 
      var: getfact_result

以下の通り、情報が取得できました。

感想

最近ではfortios用のモジュールも豊富に整ってきており、かなり恵まれた状況なようにも思えます。

ただ、現状は冒頭にも書いた通り、ググッてもansible2.3/2.4の頃によこちさんが検証された記事くらいしか情報がなかったため、触り始める前は、いろいろと不安を感じてしまいました。

まだ酸いも甘いも味わえていませんが、今のところ調べたり試してみた限りではAnsibleでのFortigate自動化も現実的なレベルで実現可能まだまだ色々課題がありそうだと思います。

今後やっていくこと

今後は、ansible2.9以降でのFortigate自動化について、ググったら日本語情報が出てきて、他の方の【やってみよう】の後押しなるように、初学者ながらちまちまと記事を追加していきたいと思います。

特に、『運用を視野に入れたうえでも本当に使えるの?(使う必要あるの?)』ってところにも切り込んでいきたいです。

おまけ

いろいろと参考になりそうなドキュメント

調べている中で、「Fortinet Ansible Modules Documentation Release 1.0」というものを見つけました。

以下URLで公開されています。

https://buildmedia.readthedocs.org/media/pdf/ftnt-ansible-docs/latest/ftnt-ansible-docs.pdf

なんと、1600P超の大ボリュームのPDFファイルで、Fortinetモジュールに関するソースやPlaybookのサンプルがずらずらと…

FortiGateだけでなく、FortiAnalyzerやFortiManagerのモジュールに関する記述もあります。

ansible2.8のときからあったものなので、2.9バージョンがそのうちリリースされるのかもしれません。

ssl_verifyに悩まされた

AnsibleでFortigateの自動化できないかと触り始めた当初はansible2.8.6でした。

その当時はfortios_factsというものはなかったので、アドレスオブジェクトを追加するPlaybookを書いて試していたのですが、まあうまくいかず…

上手くいかなかった理由は、大別すると以下のような感じです。

  • fortiosapiは1.0以降で下位互換性を切り捨てている模様

    • 0.9.8のころは、HTTPSで利用されるのが自己証明書でもverifyはしていなかったため使えた
    • 1.0以降では標準動作でセキュリティを重視した作りとしており、その結果、自己証明書を使っているHTTPSは蹴られるようになった

    • 回避策としてはhttpsでアクセスさせたくない場合は、モジュール的にはhttps: "no"を入れる、という手段が提供された

  • fortigateは、デフォルトのhttpsでは自己証明書を利用している

  • fortigateは、デフォルトでhttpアクセスするとhttpsにリダイレクトされるようになっている

  • →この結果、fortigate初期状態ではverifyエラーで使えない状態になった。(試し始める障壁に)

このあたりが曲者で、Playbook側でhttps: "no"ってやっても証明書エラーでるのなんでやろ…と数時間悩みました。

結局、以下の設定箇所で Redirect to HTTPS をOFFにしてHTTPSへのリダイレクトを回避するかたちで対応しました。

ただ、アクセスそのものはできるようになったのですが、結局アドレスオブジェクトの追加すらうまくいかず…

色々とGitにあるモジュールのissueやらを眺めていたところ、2.9でモジュール側にssl_verifyで証明書の確認が無視できる機能が追加されるという情報を見つけました。

悩んだ結果、しっかりとした原因にたどり着かないまま、先に2.9に手を出してしまいました…

いつか戻って復習します…

ちなみに、最新の公式モジュールでも、https: no + ssl_verify: no みたいな記述があるのですが、Sampleに記載のあるssl_verifyの宣言はあくまで「変数としての宣言」までなので、実際使うならタスクごとにusernameなどと同様に呼び出しが必要です。

この辺は、タスクごとに大量に同じ文字列が並ぶので、Playbookも見やすいとは思えませんでした。 なので、たぶんこのあたりのつらみに悩まされないようにするためにも、httpapiを今後の標準としていく流れなのだと理解しています。

エラー応答をみてもさっぱり理由がわからない

これはおそらく今も同じエラーが出る場合もあると思いますが、Playbookのエラーなどが原因でリクエストが失敗した場合、大体が以下の2種類のエラーでした。

こういうのが出ると、どうしてもググってサンプルやらリファレンスやら見たくなるのですが、手軽に見れる情報があまりない状態だったのもあり、うぎゃーと叫びながら

  • HTTPS使わない状態でWireSharkでキャプチャデータのリクエスト/レスポンスを眺める
  • FortiGateのdiagnose debugしながら何かヒントがないか眺める

とかをやっていました。

Wiresharkは日常茶飯事で使うものの、普段からdiagnose debug見てる職業の人ではないので直観でなんかないかなーレベルで見ていましたが、まあわかるはずもなく。

多分、2.9系からはその辺が補強されたのか、エラー見てもだいぶ分かりやすくなってる気がします。(気のせいかもしれない)

いずれにしても、失敗談は失敗談として掲載したほうが、同じようなハマりをした方の助けにもなりますし、自分の覚書にもなるので、駄目だったケースも積極的に載せていこうと思います。

FortiはAPIではPOSTは無理では?というような検索結果に震える

"fortigate ansible"でググって出てこないので、"fortigate api"とかで検索をかけてみると、少しだけ記事はあったのですが、「参照専用」とか書かれていることが多く、「本当にできるんだろうか…」と不安になりながら進めていました。

実際、今回の記事では触れていませんが、問題なく設定追加や変更も可能です。

やはり、ググって結果が出てくる状態は素敵だなあと思います。少しでも貢献できるように微力ながらがんばります。

Ansibleもくもく会リモート参加の手引き

私は地方に住んでいるということもあり、首都圏で開催されている勉強会にはなかなか参加できませんでした。

そんな中、Ansibleもくもく会はリモートで参加できるということもあり、何度もリモートで参加させていただきました。

おかげさまで、いろいろと学習する意欲が湧いてきて、前に一歩進むきっかけを頂けました。大変感謝しております。

勉強したいな、と思っても同じような境遇で現地参加できない、という方のために、リモート参加ってどんなかんじなの?という情報や楽しむためのコツをまとめておきたいと思います。

事前準備

Connpassでの申し込み

何はなくとも、Connpassで参加の申し込みをしましょう。

Ansibleに興味を持たれた方は、掲載されているイベントはスケジュールや空き枠が合わなかったとしても、Connpassのページでアカウント登録を行い、「Ansibleユーザ会」のメンバーになることをオススメします。

メンバーになると、その会で主催するイベントが登録されるたびに、通知が飛んでくるようになり、次回のチャンスを見つけやすくなります。

ansible-users.connpass.com

端末環境の準備

もくもく会の当日に使うものは、以下の通りです。

  • ブラウザ(教材や質問票などを見るため)
  • ターミナルソフト(SSH接続できればOK)
  • リモート参加のみで利用するBlueJeans

上記を利用するため、利用端末からインターネットに向けて、いくつかのポートで通信ができる環境が必要になります。

  • HTTP/HTTPS (TCP80/443)
  • SSH (TCP22)
  • TCP5000 / TCP5061 / UDP5000 - 5999

最後のはBlueJeansという、オンライン会議システム特有のものです。詳細なシステム要件は以下サポートページが参考になります。

BlueJeans Support Center

以前は追加アプリケーションの導入が必須だったように思いますが、ChromeのWebRTCのみでも利用できるようになったようなので、Chromeでの利用をお勧めします。

BlueJeansを使った会話の必要はありませんが、当日資料のURLリンクはBlueJeans経由で映像で案内されます。そのため、序盤に配信される映像は最低でも確認できる必要があります。

開催直前(前日くらい)に、主催されているREDHATさんから、メールにて以下のURLが案内されます。

  • 当日のリモート参加で接続するためのBlueJeansのURL
  • 事前のBlueJeans動作確認用のURL

もしかすると、プロキシ環境からだとうまく利用できないかもしれません。

BlueJeansについては、事前に接続テストをしておくと良いと思います。

↑動作確認用ページのオウム君。マイクで話すと、それをオウム返しでしゃべってくれます。

↑実際にテスト画面で通信しているパケットキャプチャのデータ。UDP5000が見えると思います。

過去に一度、Windowsへ接続するためのRDP(TCP3389)が必要になったことがありますが、その場合には開催案内に注意書きがあると思います。

端末環境であったほうがいいもの

「マルチディスプレイ構成」がおすすめです。

もくもくするときは、どうしてもブラウザで教材を開きながら、ターミナルやエディタを操作する形になります。

このほか、後述する質問票の画面を開きながらやろうとすると、どうしても手狭になります。そのため、マルチディスプレイが可能な方は是非活用すると良いでしょう。

リモート参加用のBlueJeansにもチャット機能がありますが、過去の経験上ほとんど利用はされていませんので、もくもく中はほとんどチェックしなくても大丈夫だと思います。(場合によっては、そこにURLなどが案内されるケースもあります)

当日の流れ

まずは、事前に案内されたBlueJeansの当日用のURLを開き、開始時間を迎えましょう。  

会議室入室時にニックネームを求められますが、connpassアカウントでもよし、好きな名前を付けましょう。チャットログくらいにしか残りません。

Connpassにも記載のある通りではありますが、基本的にAnsibleもくもく会は、以下のようなタイムテーブルで進行されます。

No. 概要 メイン 所要時間
1. 出だしの挨拶+もくもくの仕方のご説明 REDHATさん 5分~10分程度
2. 提供される課題でひたすらセルフでもくもく学習 ご自身 1時間半程度
3. 成果共有枠の方の発表 発表者 10分程度
4. アンケートの案内や次回開催などのご案内 REDHATさん 5分程度

まず、もくもく会の冒頭で、進行されるREDHATの方から、BlueJeans経由の映像でbit.ly(短縮URLサービス)のURLのご案内があると思います。(コピペ出来ないので注意)

そこを開くと、GoogleDocsを利用した質問票の当日用のページに飛びます。

質問表の中には、もくもく会の教材のあるURLや、アンケートのURLなどのリンクが記載されています。リンクなどの情報の流れを概略で書くと、こんな感じ↓です。

0.現地スライド or リモートBlueJeans画面共有で、1.のURLの共有(bit.ly)

1.質問票[GoogleDocs] … 2&3のリンク+質疑+アンケート案内 + ユーザ番号予約
 ├2.ログイン情報や参考ドキュメントURLへのリンク用ページ
 └3.教材のGitHubページ

2.のログイン情報を用いてSSHでAnsibleもくもく環境へログイン

質問票には、どのユーザ番号を使うか、という記載をする欄がありますので、まずはじめに空いているところに自分のニックネームを書きましょう。

↓こんな感じ

教材について

教材は基本的にブラウザで閲覧します。

いくつかページを開くので、タブブラウザをお勧めします(今時シングルのが珍しいか…)

基本的に教材を読んでいけば学習は進められるようになっていますが、詰まってしまったら遠慮なく質問票に質問してみましょう!

ターミナル環境について

教材のURLで、質問票でキープした番号に紐付いたターミナルログイン先の情報などが記載されていますので、その情報を参考に接続先を入力し、ログインします。

↓こんな感じで掲載されています。

Ansible実行環境へのSSHは、初期状態はパスワード認証です。

もしパスワード入力が面倒!!という方は、事前に鍵認証用の公開鍵を準備しておくと良いと思います。(切断されない限り、再接続するケースは稀だと思いますが)

ターミナル+操作環境上のVimなどでも問題なくもくもくはできますが、 最近流行りの、Visual Studio Code Remoteを使ってのもくもくもお勧めです!

エディタとターミナルが一体になっていて、拡張モジュールなども便利に活用できるので、環境の縛りがないようであれば、ぜひ多機能なVisual Studio Code Remoteを使うことをお勧めします。

※とはいっても、いまだに私もターミナル側の操作ログを取る方法がわかってません…

わからない点が出てきた時の質問について

質問票は、ブラウザ経由でGoogleDocsを利用して、複数人でテキスト形式で質問や回答などをやり取りします。

↓こんな感じ

これは、基本的には現地でもリモートでも同じです。

GoogleDocsでは、「表示」→「印刷レイアウト」がデフォルトでチェックが入っています。これがあるとページの区切りがはっきりする構成になってしまい、情報が分断されてしまうので、好みもあると思いますがチェックを外すことをお勧めします。

もくもくタイム中のBlueJeansについて

上記2.のもくもくタイム中は、BlueJeansは基本的に使いません。画面配信も実施されないと思います。

もくもくタイム終了後の成果共有発表について

BlueJeansで中継されます。

他の方がどんな学びを得たのかを知るいい機会です。たまにすごいことを話される方がいらっしゃいますし、初学の方の発表も新しい気付きを得るいい機会になると思いますので、成果共有の視聴はおすすめです。

偉そうに言ってますが、私も初学者です…

BlueJeansを利用する上での注意点

デフォルト値が変わるケースもあると思いますが、ご自身のマイクが入った状態だと、他の方にも聞こえてしまうケースがあります。ビデオもご自身の姿が映ってしまう可能性もあります。

過去に参加した際も、お仕事っぽい電話の声が聞こえたこともありますので、BlueJeansを開いたらご自身のマイクやカメラは無効化(グレーアウトだったかな?)しておきましょう。

↑こんな感じ

後は、最近は試していませんが、「後からBlueJeans上でサウンドの出力デバイスを変えても反映されない」という症状に悩まされたことがあります。

あれー?音出てないなー?と思ったら、思わぬところから出力されているかもしれません。

その他

遅刻した場合、欠席する場合

遅刻したとしても後から参加も可能です。

冒頭に表示されるbit.lyのURLは分からないと思いますが、BlueJeansのチャットのログを見ると残っていることがあるかもしれません。

もし何も情報がなければ、BlueJeansのチャットや、ユーザー会のページで案内されているTwitterで相談してみましょう。常時確認されているわけではないので、誰かが気付いてくれるのを待ちましょう。 (○○さんが入室しました、というようなログも出ませんので、発言しないと気付いてもらえません)

完全に参加が無理であれば、空くのを待っている人のためにちゃんとキャンセルしましょう。

個人的にやったほうがいいと思うもの

もくもく会なので会話そのものは不要なのですが、BlueJeansが持っているチャットの機能で、開始と終了のときは簡単に挨拶だったりお礼だったりを残しておくと良いと思います。

モチベ維持のためにあったほうがいいと思うもの

色々とご意見もあると思いますが、私はTwitterの利用をお勧めします。

もくもくリモートでやっていると、どうしても詰まったりします。

その場合、基本的には当日案内される質問票でやり取りをする形になるのですが、質問までいかないまでも、何か思ったことがあれば、ハッシュタグ「#ansiblejp」をつけてつぶやいてみましょう。

当日、同じようにハッシュタグをつけてつぶやいている人からアドバイスがもらえるかもしれません。

私だけかもしれませんが、現地にいる感覚になれるのでTwitterやりながらでも、とても楽しいです。(少しペースは落ちますが)

遠ざけておいたほうがいいもの

ペットなどを飼われている方は、遠ざけておかないと大変なことになります…

我が家では、ねこが大敵です…

参考リンク

Ansibleユーザ会の有志の方で作成いただいている、Ansibleユーザ会の案内ページです。

Slackの案内などもあるので、こちらへの参加もお勧めです。

Ansible ユーザー会とは | Ansibleユーザー会のまとめページ

AnsibleからのWindows操作をSSHにしてみた

本業ネットワーク屋さんなのにWindows系の記事ばかりですが、勢いに任せて。

これまではWinRMで接続していたAnsible~Windowsホスト間を、SSH接続にしてみました。

Ansible関連の実践記事一覧はこちら。

Ansible自動化の実践記事一覧 - てんこ


目的

WinRMはなんでもできてダメー!ポートも怖いからダメー!

よくわからないからダメー!!どうしてもダメー!!セキュリティ的にだめー!

っていう条件が付いたときに、代替手段としてAnsibleの足回りとしてSSHを使えるようにするため。

WindowsのOpenSSHはベータ版ではありますが、今の動きを見ている限り、近いうちに公式に取り入れられてもおかしくなさそうです。

ベースにした資料

  • ひよこ大佐のスライド

Red Hat Tech Nightでひよこ大佐がお話されていた資料です。

概要や参考リンクなど情報が詰まっており、とても助かりました。
Ansible本も刊行されたら必ず購入させていただきます。執筆頑張ってください!

RHTN: Ansible 2.8 x Windows - Speaker Deck

環境

Ansible側

WSL上のUbuntuで実行しました。先のことも想定してvirtualenv配下です。

(ansible28) ansible@ENVY360:~$
(ansible28) ansible@ENVY360:~$ ansible --version
ansible 2.8.6
  config file = None
  configured module search path = [u'/home/ansible/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /home/ansible/ansible28/local/lib/python2.7/site-packages/ansible
  executable location = /home/ansible/ansible28/bin/ansible
  python version = 2.7.15+ (default, Oct  7 2019, 17:39:04) [GCC 7.4.0]
(ansible28) ansible@ENVY360:~$ ansible-config dump --only-changed
(ansible28) ansible@ENVY360:~$

ansibleのバージョンは、つい先日出た脆弱性が修正されてるバージョンですね。

操作されるWindows

IP設定もDHCPの初期状態からスタート。

例のごとく管理者パスワードはインベントリに合わせる。

…って書いてましたが、今回パスワードはインベントリに書かず、手動入力にしましたので、インベントリその他への記述は不要。

テスト用で操作するWindows

メイン環境なのでいろいろ入ってますが、割愛。

Ansibleモジュール利用前のSSH接続確認用でのTeraTermなどしか利用してません。

操作されるWindows側のセットアップ

公式なインストールガイドはこちら。

Install Win32 OpenSSH · PowerShell/Win32-OpenSSH Wiki · GitHub

OpenSSHのバイナリのダウンロード

公式手順として、最新版の確認方法がPowerShellで提供されていたりもしますが、以下URLよりブラウザで手動でダウンロード。

Release v8.0.0.0p1-Beta · PowerShell/Win32-OpenSSH · GitHub

ダウンロードしたファイルは「OpenSSH-Win64.zip」です。作業時点ではバージョンは8.0.0p1-betaとのこと。

なお、Windows Server側で作業をしているため、事前にIEのセキュリティ強化の構成などを無効化したりしています。

その後、ZIP圧縮されたファイルを展開し、デフォルトインストールパスとして指定されている C:\Program Files\OpenSSH として配置。

Windowsサービスとしてのsshdの登録

手順に従い、PowerShellを起動して、デフォルトのインストールパスに移動し、以下コマンドを入力。

powershell.exe -ExecutionPolicy Bypass -File install-sshd.ps1

-File の部分で絶対パスを指定すれば特に移動も必要ないと思います。

Windows FirewallでのTCP22の開放

手順に従い、そのままPowerShellで以下のコマンドを入力。

New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

sshdサービスの起動

以下コマンドを入力し、sshdサービスを起動。

net start sshd

→正常にサービスが起動することを確認。

テスト用端末からパスワード認証での動作確認

ターミナルソフトでIPを指定→ハッシュが表示される!

ユーザ名とパスワードを入力しログイン→いけた!!

Ansible経由でのパスワード認証での疎通確認

こんなかんじのインベントリで

[win_2012]
192.168.10.249

[win_2012:vars]
ansible_user=administrator
ansible_connection=ssh
ansible_shell_type=cmd

win_pingモジュールを起動するだけのPlaybookをたたく。-kオプション付けてパスワードを聞かれるように。

→sshpassというプログラムが足りないと怒られる…

※補足 実際にはこの時点で、known_hostsへのハッシュの追加を聞かれてます。いきなり鍵認証に進む方は、大抵設定されてると思いますがansible.cfgなどでハッシュの確認を無効化しておきましょう。

$ sudo apt-get install sshpass

入れてみて再チャレンジ!

キタ━━━━(゚∀゚)━━━━!!

認証を鍵認証にしてみる

さて、パスワード認証が終わったところで鍵認証に移行。まあ、よくあるハマりがありました。

鍵ファイルの配置場所とターミナルからの接続確認

該当のページ上のsshd_configドキュメントを読んでみると、以下がデフォルトパスとのこと。

“.ssh/authorized_keys .ssh/authorized_keys2”

ただし、注意事項があり、OpenSSH7.7以降のAdministratorsグループ用の鍵ファイルの位置は、以下パスがデフォルトであるとの記載あり。

%programdata%/ssh/administrators_authorized_keys

なるほどと思い、administratorsグループ側のパスに公開鍵ファイルを置いてみる。

いざターミナルで接続確認→繋がらず。なんか拒否られてる感じ。

確認してみたところ、以下パスにログが保管されてそうなディレクトリがあったのですが、ファイルは何もなし。

%programdata%/ssh/logs/

さらに、そこにsshd_configファイルを発見。覗いてみることに。

sshd_configの設定変更とログ確認

Windows側のOpensshの設定ファイル

%programdata%/ssh/sshd_config

Rootログインやら鍵認証やらは許可されている。

上述した、AdministratorGroupのパスワードの設定も末尾に入っている。

Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

該当のページ上のsshd_configドキュメントを読んでみると、「ログをファイルベースにするには、LOCAL0のファシリティにしろ」とのこと。

ということで、設定変更しサービスを再起動し、再度鍵認証実施→ログ確認。

administrator@WIN-T4SRVR692IR C:\ProgramData\ssh\logs>more sshd.log
1148 2019-10-19 20:05:38.667 Server listening on :: port 22.
1148 2019-10-19 20:05:38.667 Server listening on 0.0.0.0 port 22.
856 2019-10-19 20:05:55.168 Accepted password for administrator from 192.168.10.
243 port 52224 ssh2
2752 2019-10-19 20:05:56.214 Received disconnect from 192.168.10.243 port 52224:
11: disconnected by server request
2752 2019-10-19 20:05:56.214 Disconnected from 192.168.10.243 port 52224

↑ここまでパスワード認証

↓ここから鍵認証

2164 2019-10-19 20:06:11.230 Authentication refused.
2164 2019-10-19 20:06:13.121 Received disconnect from 192.168.10.243 port 52229:
11: authentication cancelled [preauth]

原因は Authentication refused って書いてある。

となると、よくあるのはauthorized_keysが格納されているパスまでのパーミッション

セキュリティ設定(パーミッション)の変更

確認してみたところ、 configなどが格納されている sshフォルダのパーミッションが甘そう。

なので、「Authenticated Users」のグループから全権限を外す。

※事後で権限つけてScreenShot撮ってるので、初期値は違う可能性があります。ご了承ください。

テスト用端末からの鍵認証の確認

キタ━━━━(゚∀゚)━━━━!!

Ansible経由での鍵認証での疎通確認

Ansible側のホストの$HOME/.ssh/id_rsa秘密鍵を配置、パーミッション設定をしていざ実行…

キタ━━━━(゚∀゚)━━━━!!

感想

ということで、無事にAnsibleからのWindowsの操作をSSH経由で実施できる環境が整いました。

WinRMと比べてセットアップ工程が長いので、スクリプト化しないとだめかなあという気持ちになりました。

わからなかったところ

いつのまにかsshd_config とかが生成されていたので、これはどのタイミングなのかはまた調べてみようと思いました。

まだAnsibleの学習が進んでないこともあり、デフォルトシェルをcmdにするのかpowershellにするのがいいのか、というのはわかりませんでした。

FACILITY設定する前のログはイベントログ側にあるのか?未確認

また勉強します。

参考にした資料(まとめて再掲)

  • ひよこ大佐のスライド

RHTN: Ansible 2.8 x Windows - Speaker Deck

[wiki]のページにいろいろ書かれています。

GitHub - PowerShell/Win32-OpenSSH: Win32 port of OpenSSH

  • Win32-OpenSSHのMicrosoft自動翻訳ページ

上記公式GitHubがほぼ日本語に翻訳されてるので、とてもありがたかった…!

Windows 用 OpenSSH の概要 | Microsoft Learn

自宅ラボ用にNUCを買いました。

Ansibleその他の検証をするために、やっぱり自宅にラボ環境が欲しいなあと思っていました。記録のためブログに残しておきます。

2020/07/26追記

Ansible実践関連の記事一覧はこちら。

Ansible自動化の実践記事一覧 - てんこ

購入候補

以下の2パターンのうち、どちらにするか悩んでいました。

No. メーカ CPU 備考
1 Intel NUC BOXNUC8I7BEH Corei7 第八世代 TDP28W
2 Asrock DeskMini A300 Ryzen 3400G(別途調達) TDP65W

結果、No.1のNUCを購入しました。

普通のマウスを載せてもこのサイズ感…!!小さい!!

購入した構成

@sky_jokerxx さんの以下の記事を参考に…というかまんまです。

https://sky-joker.tech/2019/07/12/intel-nuc%e3%81%aenuc8i7beh%e3%81%ae%e3%83%a1%e3%83%a2%e3%83%aa%e3%83%bc%e3%82%9264gb%e3%81%ab%e3%81%97%e3%81%a6esxi%e3%82%92%e3%82%a4%e3%83%b3%e3%82%b9%e3%83%88%e3%83%bc%e3%83%ab%e3%81%97%e3%81%a6/

種別 概要 型番 備考
ベアボーン Intel NUC BOXNUC8I7BEH -
モリー Samsung 32GB DDR4 2666MHz(SODIMM) M471A4G43MB1 -
ストレージ Samsung NVMe SSD 500GB 970 EVO Plus MZ-V7S500B/IT -
電源コード サンワサプライ 電源コード
(3P・ストレートコネクタ) 1m
KB-DM3S-1 要別発注

まずは、ということでメモリは32GB×1枚なので現時点だと高くついてますが、そのうち買い増しすると思います。

買ったけど不要だったもの

NVMeのSSDの発熱が…というような記事をよく見かけたので、念のためNVMe用のヒートシンクを購入したのですが、NUCを開けてみるとNVMe用のゴムのようなものがついていて、ヒートシンクつけるとフタが締まりませんでした(汗)

どうやら、これでケースにNVMeの熱を逃がす設計になっているようです。

ESXiのインストール

インストーラの作成とかも、上記 @sky_jokerxxさんの記事をもろ参考にしています。私は母艦がWindowsなのもあり、そのあたりは多少アレンジしていますが実施内容自体は変わらないので割愛。

ESXiのインストール先はUSBメモリにしました。

少しハマッたこと

私のメイン環境の配線は、以下のようなイメージです。

ここで、右下の「作業用ポート」のところにNUCをHDMI(4K)ケーブルでつないでみたところ、全く画面が映らず、愕然としました。

やってしまったか…と思ったのですが、HDMIの切り替え機(Extend)のランプがパチパチ切り替わっていたのもあったので、もしやこれが原因では…と思い、右上にある液晶テレビHDMIポートにつないだところ、問題なく画面が出力されました。

原因そのものを追求してはいないのですが、初期インストール時の接続はあまり高解像度環境で実施しないほうが無難だと思います。(OS入れてドライバ入れば大丈夫だと思いますが)

やろうとおもってできなかったこと

MicroSDをESXIのインストール先にしようかな?とも思ってたのですが、全く認識せず…

NUCのFAQを見てみたら、サポートしてないとのこと。

SD カードからインテル® NUC を起動できますか?

おとなしくUSBメモリをインストール先にしました。

たいしたことない思い出ばなしなど

以前も、ShuttleのベアボーンでESXiを組んでいたことはあったんですが、流用パーツで作ったため性能が低かったり、モチベーションなどの理由から使用頻度が低くなり、昨年の引っ越し前の断捨離でいったん廃棄することになりました。

大学時代からプチ自作をしていたので、それを少しでも思い出すAsrockも捨てがたかったのですが、CPU世代とBIOSバージョン間のリスク(古いファームだと新型Ryzen認識しないかもしれない問題)もあり、また「今やりたいのは自作じゃない」という観点からも、実績の多いNUCパターンを選択しました。

いろいろ試すための環境がそろってきたので、がんばるぞー!

2020/07/26追記

SATA-SDDとして、Samsung 860 EVO 1TB SATA 2.5" 内蔵 SSD MZ-76E1T0B/ECを追加。問題なく動作しています。

追加のメモリとして、以下のメモリを購入。問題なく動作しています。

https://www.amazon.co.jp/gp/product/B085ZXGQ4Q/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

これで、メモリ64GB、ストレージ1.5TB(500G-NVMe/1T-SSD)のつよつよマシンになったぞ!