bashを用いてSlackへメッセージを投稿する

という処理を実現するためにIncoming Webhooksという機能を使うようである。作業の大筋はこういう具合である。

  • Slackアプリを作成
  • Incoming Webhooksを有効にセット
  • ワークスペースへのアクセス許可を付与
  • 動作確認

Slackアプリを作成

まずナイスな緑のボタンをクリックすることでSlackアプリを作成するページへアクセスする。アプリに名を与え、活躍の場となるワークスペースを選択する。アプリ名はのちの変更が許されているから、命名に何時間もかける作業を先送りにできる。ワークスペースはあとから変更が効かないから勢い慎重にならざるを得ない。

Incoming Webhooksを有効にセット

アプリをこしらえるとBasic Informationのページへと遷移する。そうしたら「Add features and functionality」の中にある「Incoming Webhooks」をクリックする。ここにIncoming Webhooksを有効にするスイッチがあるから此れをクリックしてOnへと変更するのである。

ワークスペースへのアクセス許可を付与

Incoming Webhooksが有効にセットされるとページの下部にcurlのサンプルコマンドなどが現れる。此処で「Add New Webhook to Workspace」ボタンをクリックすると、アプリに対してワークスペースへのアクセス権限を許可する画面へと移るから投稿先のチャンネルを選択して「許可する」ボタンをクリックする。

此れによって遂に具体的なWebhook URLが誂えられる。Webhook URLは余所の人の悪用を避けるために内緒にせねばならない。あとはこのURLに対してJSON形式でメッセージをPOSTすることでSlackにメッセージを投げつけられるようになる。curlコマンドによるサンプルもこしらえてくれるから気軽に動作確認もおこなえる。

動作確認

サンプルのcurlコマンドを実行して、設定したワークスペースのチャンネルに対してメッセージが正常に投げかけられたら「ok」と表示される。スマートフォンにSlackを導入して良しなに設定を施してあれば通知もやってくる。

通知がやって来ないときはSlackの「おやすみモード」がオンになっていたりスマートフォンの省電力設定が妨害していることもあるから「通知のトラブルシューティング」を実施してみるのがよろしい。そうしてようやっと望んだ動作が手に入ったのである。

参考:
Sending messages using Incoming Webhooks

Slackを始める

暇のかかるなにがしかの処理が完了した報告や障害・異常の検知を、スマートフォンにインストールしているSlackへ投稿して通知が来るようにしたい。と企ててから随分年月を経てしまったのでいい加減取り組むものである。其れにはSlackを始めない事には話にならない。

まずはSlackを始めるページへアクセスして「+Slackワークスペースを作成する」という文言をクリックする。

メールアドレスを打ち込み「確認する」をクリックすると入力したアドレス宛に確認コードのメールが送られる。

確認コードを見届けたならば入力欄へ打ち込んでゆく。最後の数字を入力した時点で検証が自動的に始まる。検証に成功すると新たにページが遷移する。

社名やチーム名の入力を促される。これはワークスペース名になるという。省略は許されないから、気の利いた名前をつけ「次へ」をクリックする。

次にプロジェクト名を入力する。これはチャンネル名のことであった。これも割愛はできないため、気の利いた名前をつけて「次へ」をクリックする。

メールを一番送信する相手を聞かれるけれども、登録してもしなくともよかった。一先ず「後で」を選択して先へ進むと、チャンネルが出来上がったと大盛りあがりするページへ行くから「Slackでチャンネルを表示する」をクリックして無事、Slackの世界へ足を踏み入れることになった。

NoMachineの自動スクロールする領域を変更する

OS: Windows 10 Pro Version 1909
NoMachine for Windows 6.9.2

デフォルトの設定ではウィンドウの隅から40px内の領域へカーソルが侵入すると自動でスクロールが開始されるけれども、予期せず反応してしまって腹が立つこともあるから此の領域を狭めたいものである。

公式サイトによると設定ファイル %userprofile%\.nx\config\player.cfg にあるキー Automatic viewport scrolling sensitive area size の値を変更することで制御できる模様である。

NoMachineを停止させてから値を編集して保存する。ひとまず値を十分の一の4にセットした。

NoMachineを起動して具合を試したことろ反応する範囲が相当狭まって概ね満足である。

参考:
2.5. Scrolling Settings for Viewport Mode

新規作成メニューにある無用の項目を削除する

OS:Windows 10 Pro Version 1909

右クリックメニューの新規作成からビットマップイメージやリッチテキストドキュメントを生成したことが未だ嘗て無い。誤操作のもとであるから此れらを削除する。

レジストリエディタを起動して HKEY_CLASSES_ROOT を選択すると配下に数多の拡張子が羅列されているから削除を望むものを選択する。リッチテキストドキュメントであれば .rtf という具合である。この中にある ShellNew という名のキーを削除、乃至はリネームする。

リネーム前
リネーム後

変更は瞬く間に反映されてリッチテキストドキュメントの項目がすっかり削除された。

この調子でビットマップイメージ(.bmp)とショートカット(.lnk)も削除してやるとこういう具合である。大変清々しい心持ちである。

仮想化ベースのセキュリティが有効であるとVMware Workstationの仮想マシンが起動できない

Windows 10 Pro Version 1909
VMware Workstation 15 Pro 15.5.1
CPU: Intel Core i7-3520M

自端末へ VMware Workstation 15 Pro をインストールして幾ばくかの時間を隔てたのちに改めて仮想マシンの起動を試みたところ、見慣れぬエラーメッセージに見舞われて面食らった。曰く、

VMware Workstation と Device/Credential Guard には互換性がありません。VMware Workstation は Device/Credential Guard を無効にした後で実行することができます。詳細については、 http://www.vmware.com/go/turnoff_CG_DG を参照してください。

とのことである。調べてみるとWindows Defender Application GuardやWindows サンドボックスを導入すると仮想化ベースのセキュリティが有効になって、此れがVMware Workstationと相容れない情勢であるBIOSでIntel VT-xを有効にしてあっても無効であるものと判断されている。

何もしていないのに壊れたと憤慨したものであるが、Windows サンドボックスを有効にした覚えがある。何もしていないのに壊れたという申し立ては必ず嘘である。

こういう事では困るから慌ててWindows サンドボックスを無効にしたのであるけれども此れがちっとも効果が無い。コマンドプロンプトからmsinfo32を立ち上げて「システムの要約」→「仮想化ベースのセキュリティ」項目を確認すると値は「実行中」である。はてな、此は如何にと思案に暮れているとどうも無効にする手順が別に在る模様である。

先ずはローカルグループポリシーエディターを起動して、「コンピューターの構成」→「管理用テンプレート」→「システム」→「Device Guard」と辿る。そうして二つの設定「Windows Defender アプリケーション制御を展開する」「仮想化ベースのセキュリティを有効にする」を無効とする。

次いで幾つかのレジストリキーを削除する。

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LsaCfgFlags
HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\LsaCfgFlags
HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\EnableVirtualizationBasedSecurity
HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\RequirePlatformSecurityFeatures

自端末には EnableVirtualizationBasedSecurity しか見当たらなかったから此れのみ削除した。続いてコマンドプロンプトを管理者として実行して以下のコマンドを放り込む。全体どういう了見でこのUUIDが世に出たか知れないけれども兎に角、効く。

mountvol X: /s
copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
mountvol X: /d

ここまでこなしたら端末を再起動する。起動中に Credential Guard を無効にするか否かを問われ、無効にするならWindowsキーもしくはF3キーを押下する。時間制限があるからもたついていると何もせぬままに起動が進行してしまう。

あらためてmsinfo32を実行すると無事、仮想化ベースのセキュリティが無効になり仮想マシンの起動も恙無く済んだ。VMware Workstation ProとWindows サンドボックスの両立はむつかしいようであるから欲を張らずに、仮想化ベースのセキュリティを都度、有効か無効に切り替えてどちらかを選ぶしかないようである。

参考:
Windows Defender Credential Guard の管理
“VMware Workstation and Device/Credential Guard are not compatible” error in VMware Workstation on Windows 10 host (2146361)