ぽよメモ

ファッション情報学徒の備忘録.

M75q-1 TinyをWindows以外からでもリモート管理したい

[2020/9/30 21:00 追記]
libcurl.so.4の置き換えは推奨されない旨と、bootorderの変更が実際には反映されない旨を追記しました。

M75q-1 Tinyって何?

オタク大好き小型激安高性能マシンです。

楽天リーベイツの20%ポイント還元を使って、35090円の7018ポイント還元で実質28072円で買えました*1。安く買う方法や詳細はのらねこ先生のブログおよびのらねこ先生のバイヤーズガイドをご覧下さい。 スペックは以下の通りです。

  • CPU: Ryzen 5 Pro 3400 GE (4core 8thread)
  • Mem: 8GB
  • SSD: 128GB

DASH

Desktop and mobile Architecture for System Hardware(DASH)とは、M75q-1 Tinyに搭載されているリモート管理機能です。これによって、リモートからマシンの電源を入れたり、BIOSの設定などを変更したりできます。サーバマシンなどに搭載されているIPMIなどと似たものです。BIOSの設定から有効にすることが出来ます(デフォルトはオフになっています)

これを利用するためのアプリケーションとして、Windows向けにAMD Management Console(AMC)というものがAMD公式で用意されており、以下のWebサイトからダウンロードできます。

developer.amd.com

上述したのらねこ先生のバイヤーズガイドでもこちらの利用方法が解説されています。しかしオタクたるもの、GUIアプリケーションよりも黒い画面から操作したいし、Windowsなんて持ってない……*2。そんな要望を満たすアイテムは無いものか…………

f:id:pudding_info:20200926172948j:plain

あるじゃん👉

AMDは神。

Windowsだけでなく、UbuntuおよびFedora向けのdebパッケージが公開されています。Dockerコンテナに押し込めてしまえば、WindowsだろうがMacだろうがLinuxだろうが、関係無くDASH CLIを使えそうな予感がします。というわけでやっていきしましょう。

Docker Image for DASH CLI

大変残念ながらwgetcurlなどを使ってアーカイブを取得することができなかった*3ため、ダウンロードページ( https://developer.amd.com/tools-for-dmtf-dash/#downloads )から手動でdashcli-setup_3.0.0-285-Public_amd64_deb.tar.gzをダウンロードしてください。

同じディレクトリに以下のDockerfileを配置します。

FROM ubuntu:18.04

ARG DASHCLI_VERSION=3.0.0-285

ENV DASHCLI_PKG=dashcli-setup_${DASHCLI_VERSION}-Public_amd64
ENV TZ Asia/Tokyo
ENV DEBIAN_FRONTEND nointeractive

WORKDIR /opt/dashcli

RUN apt-get update \
 && apt-get install -y --no-install-recommends \
        sudo \
        libssl1.0 \
        libsdl1.2debian \
        libsdl2-2.0-0 \
        libxml2 \
        mono-devel \
        libcurl3 \
 && apt-get clean \
 && apt-get autoremove -y --purge \
 && rm -rf /var/lib/apt/lists/*

ADD ${DASHCLI_PKG}_deb.tar.gz .

RUN dpkg -i ${DASHCLI_PKG}_deb/${DASHCLI_PKG}.deb \
 && dashcli version \
 && rm -rf ${DASHCLI_PKG}

ENTRYPOINT ["/usr/bin/dashcli"]

CMD ["help"]

後はdocker buildするだけです。

$ docker build . -t dashcli:3.0.0-285
# 一時的にdashcliというエイリアスを作成しておく
$ alias dashcli="docker run --rm -i dashcli:3.0.0-285"
$ dashcli version
DASH CLI v3.0.0.285

[2020/9/30 21:00 追記]

libcurl.so.4を置き換えないようにDockerfileを修正しました。

追記ここまで

注意
ちゃんとライセンスを読んでいないので確かなことは言えないのですが、勝手にこのバイナリを含むDockerイメージを公開する(==再配布する)行為はライセンス違反となる可能性があります。念のためプライベート・非商用での利用をお勧めします。

DASH CLIの使い方

使い方に関するドキュメントが非常に少ないです*4。僕自身もしばらく触っただけで、まだ全く活用は出来ていません。
実はdebパッケージにドキュメントが含まれており、 /usr/share/doc/dashcli-setup/ 以下に配置される……はずなんですがこのディレクトリは空になっています(なんで?)。debパッケージを手動で展開し、手元にドキュメントを用意します。以下のコマンドで可能です。

$ DASHCLI_VERSION=3.0.0-285
$ docker run --rm -v $PWD/doc:/doc --entrypoint /bin/bash dashcli:${DASHCLI_VERSION} -c "dpkg-deb -x dashcli-setup_${DASHCLI_VERSION}-Public_amd64_deb/dashcli-setup_${DASHCLI_VERSION}-Public_amd64.deb dash_deb && cp -r ./dash_deb/usr/share/doc/dashcli-setup/* /doc/"
$ ls doc/
DASHActiveDirectory.pdf  License                         LinuxDASHCliUserGuide.pdf
DASHCertificates.pdf     LinuxDASHCliDeveloperGuide.pdf  LinuxReleaseNotes.pdf

LinuxDASHCliUserGuide.pdfよりもLinuxDASHCliDeveloperGuide.pdfの方が情報が豊富でおすすめです。

ヘルプの表示

$ dashcli help

DASH CLI v3.0.0.285
Command line utility to manage DASH capable systems.

Usage: dashcli [options] commands

Options allowed:
        -h <host>               Host Name
        -p <port(s)>            Server Port(s)(For discovery more than one ports can be specified seperated by commas)
        -u <username>           User Name
        -P <password>           Password
        -a <digest|basic|gss>   Authentication Type [default=digest]
        -S <http|https>         HTTP Scheme [default=http]
        -c <certificate>        Certificate file (Alternatively certificate can be stored in certificate store)
        -C                      Ignore certificate/do not verify certificate
        -t <targetpath>         Target Path
        -s <startip>            Start IP address for discovery (only for discovery)
        -e <endip>              End IP address for discovery (only for discovery)
        -T <timeout>            Timeout in seconds
        -v <1|2>                Verbose Level [ 1 - More explanation on error or 2-Dump WSMAN data]
        -o <verboseoutput>      Verbose output file to dump wsman data [default is sdtout].

Commands allowed:
        help                    Display help
        version                 Show dashcli version
        enumerate               Enumerate targets
        discover                Perform discovery
        registeredprofile       Checks the profile support
        indication              Indication commands(subscribe for indication, create filters/destinations
        listenevents            Listen for events/alerts
        textredirection         Configure Text Redirection services
        usbredirection          Configure USB Redirection services
        kvmredirection          Configure KVM Redirection services
        raw                     Issue raw commands
        account                 Creates,Deletes and Manages the Account
        roles                   Manages the Roles
        shell                   Launch interactive DASH shell
        capabilities           Display Capabilities of a target

For commands specific to targets
        dashcli help target

Where allowed targets are
        alertdestination
        asset
        battery
        bios
        bootconfig
        computersystem
        dhcpclient
        dnsclient
        ethernetport
        fan
        filtercollection
        indicationfilter
        indicationsubscription
        indicatorled
        ipconfiguration
        ipinterface
        kvmredirection
        logentry
        memory
        mediaredirection
        networkport
        opaquemanagementdata
        operatingsystem
        pcidevice
        physicalcomputersystemview
        platformwatchdog
        powersupply
        processor
        recordlog
        registeredprofile
        role
        sensor
        serviceprocessor
        software
        textredirection
        usbredirection
        user

Example usage:
Discovery example:
dashcli -s 192.168.0.4 -e 192.168.0.15 -u admin -P admin -p 623 discover
dashcli -s 192.168.0.4 -e 192.168.0.15 -p 623 discover
dashcli -s 192.168.0.4 -e 192.168.0.15 -p 623,664,8889 discover
dashcli -s 192.168.0.4 -e 192.168.0.15 -S http  -p 623 discover
dashcli -s 192.168.0.4 -e 192.168.0.15 discover info
dashcli -h hounds-demo -S http -p 623 discover
dashcli -h 192.168.0.8 -S http -p 623 discover
dashcli -h hounds-demo -S http -p 623 discover info
dashcli -h 192.168.0.8 -S http -p 623 discover info

Enumerate target example:
dashcli -h 192.168.0.4 -S https -p 664 -u admin -P admin -C enumerate computersystem
dashcli -h 192.168.0.4 -S https -p 664 -u admin -P admin -C enumerate processor
dashcli -h 192.168.0.4 -S https -p 664 -u admin -P admin -C enumerate bootconfig

Executing commands on a target example:
dashcli -h 192.168.0.4 -S https -p 664 -u admin -P admin -C -t computersystem[0] power on
dashcli -h 192.168.0.4 -S https -p 664 -u admin -P admin -C -t processor[0] enumerate memory
dashcli -h 192.168.0.4 -S https -p 664 -u admin -P admin -C -t bootconfig[0] changebootorder 1 0

DASH CLIにはCommandsとtargetというものがあるようです。Commandsは操作するコマンド、targetはコマンドによって操作される対象を表しています。ただ、上記helpに表示されているCommandsというものは、どのtargetに対しても有効な物です。各target特有のCommandは、 dashcli help ターゲット名 で表示することができます。

DASHが有効なホストの探索

IPアドレスの範囲を指定することで、自動で探索してくれます。DASHを有効化した後、IPアドレスを固定せず、MACアドレスも控え忘れたままディスプレイから引っこ抜いてしまったときに使えそうですね。

$ dashcli -s 192.168.0.2 -e 192.168.0.4 discover

Checking 192.168.0.2 ...
Checking 192.168.0.3 ...
Checking 192.168.0.4 ...

DASH system(s) discovered:
        192.168.0.4:623

電源状態の取得・変更

各ホストの詳細の表示・変更にはログイン情報を渡す必要があります。デフォルトのユーザ名とパスワードは以下の通りです。

  • ユーザ名:Administrator
  • パスワード:Realtek

BIOSのUI上からではこれらを変更する方法はなく、このコマンド経由でのみパスワード変更等が可能です。 アカウントの作成・削除もできるため、後述する方法で新規ユーザの作成と、Administratorの無効化を行う方がセキュリティ的には良いかと思います。

電源状態を表示してみます。

$ dashcli -h 192.168.XX.YY -u Administrator -P Realtek -C -t computersystem[0] power status

Power state   : On

-C を付けないと Error: Connection Failed : Trnasport initailization failed というエラーが出ます。
電源のオン・オフ・再起動は以下のコマンドで可能です。

# 電源オン
$ dashcli -h 192.168.XX.YY -u Administrator -P Realtek -C -t computersystem[0] power on
# 電源オフ
$ dashcli -h 192.168.XX.YY -u Administrator -P Realtek -C -t computersystem[0] power off
# 再起動
$ dashcli -h 192.168.XX.YY -u Administrator -P Realtek -C -t computersystem[0] power restart

注意点として、これらのコマンドはその実行結果を保証しません。つまり、状態のリクエストはしますが、その状態に移行したことは保証してくれません。power onした後に実際にそのホストが起き上がってくるかどうかは、別の方法で検証する必要があります。

boot順の表示・変更

[2020/9/30 21:00 追記]

boot順の変更はSuccessするものの、試した限りではそれが実際のブートに反映されることはありませんでした。
変更後、setdefaultsetnextsetnextsingleuse も試しましたが変化はありませんでした。
Windows版DASH CLIAMD Management Console、Realtek Management Consoleのいずれでも同様でした。もし成功する方が居られれば、情報頂きたいです。

この事象についてLenovoにメール問い合わせをしましたが、技術的な内容はオンサイトの技術サポートに問い合わせて欲しいと言われました。
オンサイトは電話窓口しかないため、電話する気力が湧けば確かめてみたいと思っては居ます(BIOS経由でEnableできる特殊な機能のため、回答はあまり期待していません)。
一応AMDのDASHサポートにも問い合わせてみてみましたが、おそらくM75q-1 TinyのUEFIおよびRealtekのDASH firmwareの問題だと思われるため、こちらも良い回答は期待していません。

追記ここまで

まずはブート順の表示

$ dashcli -h 192.168.XX.YY -u Administrator -P Realtek -C enumerate bootconfig


Boot Config Instance 0
Element Name             : Bootcfgsetting:0
Instance ID              : Bootcfgsetting:0
Is Default Configuration : No
Is Current Configuration : No
Is Next Configuration    : Yes
Is Next Single Configurat: No
Boot Device(s)           :
        Device 0         : CIM:Windows Boot Manager:1
        Device 1         : CIM:UEFI: PXE IPV4 Realtek PCIe GBE Family Controller:1
        Device 2         : CIM:UEFI: PXE IPV6 Realtek PCIe GBE Family Controller:1

WIndowsのブートマネージャーが最初に、次にIPv4でのPXEブートが来ているようです。この順序を逆にしてみます。

$ dashcli -h 192.168.XX.YY -u Administrator -P Realtek -C -t bootconfig[0] changebootorder 1 0

Boot Order Changed Successfully
$ dashcli -h 192.168.XX.YY -u Administrator -P Realtek -C enumerate bootconfig


Boot Config Instance 0
Element Name             : Bootcfgsetting:0
Instance ID              : Bootcfgsetting:0
Is Default Configuration : No
Is Current Configuration : No
Is Next Configuration    : Yes
Is Next Single Configurat: No
Boot Device(s)           :
        Device 0         : CIM:UEFI: PXE IPV4 Realtek PCIe GBE Family Controller:1
        Device 1         : CIM:Windows Boot Manager:1
        Device 2         : CIM:UEFI: PXE IPV6 Realtek PCIe GBE Family Controller:1

元に戻すときは再度 changebootorder 1 0 をすることで入れ替わります。この状態で前述のコマンドを使って再起動をかければ、PXEブートするはずです。
ただ、多くの場合は一時的にブート順序を変えたいのではないでしょうか?このコマンドは恒久的に変更してしまうため、このような変更を行うにはいいかんじのタイミングで再度ブート順序を変更する必要がありそうです。

他にもどうもsetnextとかsetnextsingleuseとかいうコマンドがあるようですが、使い方も意味も分かりません……*5

ユーザの作成・削除

さすがにデフォルト値のユーザを使い続けるのはセキュリティ的に良くありません。ユーザ一覧を見てもAdministratorしかいないことが分かります。

$ dashcli -h 192.168.XX.YY -u Administrator -P Realtek -C enumerate user


User Instance 0
Name                       : Administrator
User id                    : Administrator
Element Name               : Account
Organization Name(s)       : DMTF
Enabled State              : Enabled
Requested State            : Not Applicable
Associated Role(s)         : Role:0,  Role:1,  Role:2

DASHはRole Based Access Controlを採用しているようで、Roleごとに権限が与えられており、このRoleを特定のユーザに付与することで、そのユーザに実行可能な操作を限定できるようです。デフォルトのAdministratorには多くの権限が付与されているため非常に危険です。

$ dashcli -h 192.168.XX.YY -u Administrator -P Realtek -C enumerate role


Role Instance 0
Role Name   : Role:0
Privileges  : priv:0 (BaseDesktopAndMobile(Execute)),
              priv:11 (SimpleIdentityManagement(Execute)),
              priv:12 (RoleBasedAuthorization(Execute))

Role Instance 1
Role Name   : Role:1
Privileges  : priv:13 (TextConsoleRedirection(Execute)),
              priv:14 (USBRedirection(Execute)),
              priv:21 (KVMRedirection(Execute))

Role Instance 2
Role Name   : Role:2
Privileges  : priv:0 (BaseDesktopAndMobile(Execute)),
              priv:1 (CPU(Execute)),
              priv:2 (BootControl(Execute)),
              priv:3 (PowerStateManagement(Execute)),
              priv:4 (Indications(Execute)),
              priv:5 (SystemMemory(Execute)),
              priv:6 (SoftwareInventory(Execute)),
              priv:7 (Sensors(Execute)),
              priv:8 (Fan(Execute)),
              priv:9 (PowerSupply(Execute)),
              priv:10 (PhysicalAsset(Execute)),
              priv:15 (DHCPClient(Execute)),
              priv:16 (IPInterface(Execute)),
              priv:17 (BIOSManagement(Execute)),
              priv:18 (OperatingSystem(Execute)),
              priv:19 (RecordLog(Execute)),
              priv:23 (EthernetPort(Execute)),
              priv:24 (NetworkPort(Execute))

まずはユーザを作成します。

$ dashcli -h 192.168.16.51 -u Administrator -P Realtek -C \
    -t computersystem[0] \
    user add ユーザ名 パスワード Organization名


User Added Successfully

なぜかOrganization名は反映されませんでした。

$ dashcli -h 192.168.XX.YY -u Administrator -P Realtek -C -t user[1] show

User Instance 1
Name                       : ユーザ名
User id                    : ユーザ名
Element Name               : Account
Organization Name(s)       : DMTF
Enabled State              : Enabled
Requested State            : Not Applicable
Associated Role(s)         : N/A

この状態ではRoleが付与されていないのでこのユーザでは何も出来ません。Administratorと同じRoleを付与します。

$ dashcli -h 192.168.XX.YY -u Administrator -P Realtek -C -t user[1] assignroles Role:0 Role:1 Role:2

Roles assigned Successfully
$ dashcli -h 192.168.XX.YY -u Administrator -P Realtek -C -t user[1] show

Name                       : ユーザ名
User id                    : ユーザ名
Element Name               : Account
Organization Name(s)       : DMTF
Enabled State              : Enabled
Requested State            : Not Applicable
Associated Role(s)         : Role:0,  Role:1,  Role:2

これでこのユーザを使えるようになったはずです。

$ dashcli -h 192.168.XX.YY -u ユーザ名 -P パスワード -C -t computersystem[0] power on

Power state 'On' was applied successfully

使えることが分かったので、Administratorは無効にしておきます。

$ dashcli -h 192.168.XX.YY -u ユーザ名 -P パスワード -C -t user[0] disable
Error: Disabling User

えぇ…………
仕方が無いのでパスワード変更にします。

$ dashcli -h 192.168.XX.YY  -u ユーザ名 -P パスワード -C -t user[0] changepassword 新パスワード

User password changed Successfully

これで多少は安心できそうですね。

LEDも操作できる!?

できませんでした……。

$ dashcli -h 192.168.XX.YY -u Administrator -P Realtek -C enumerate indicatorled


Indicator LED(s) not found

何台もM75q-1 Tinyがある場合に点滅させたりできたら楽しそうだなと思ったんですが残念……我々はテプラから逃れられないようです。

JSON形式での実行と表示

こんなよく分からない形式のデータを扱うのつらそう……と思いましたが、調べてみるとどうもJSONでのコマンド実行・出力が出来るようです。すごいですね。
ただちょっとクセがあります。

入力するJSONは位置引数以外は単にオプション名をキーに、その値をバリューとするように構成します。ただし、-C のような値を取らないフラグは1を値として与えます。
また、位置引数は Commands というキーに対して、文字列を空白区切りのarrayとして与えます。JSONとして成立しない壊れたものも頑張って読み込もうと知るため、思っているのとは違うエラーが出ることにも注意が必要です。

-jdo を使う方法

-jdo を付けると、標準入力からJSONを受け付け、実行結果をJSONで表示します。

$ echo '{"h": "192.168.XX.YY", "u": "ユーザ名", "P": "パスワード", "C": 1, "Commands": ["enumerate", "bootconfig"]}' > enumerate_bootconfig.json
$ cat enumerate_bootconfig.json | dashcli -jdo | jq
{
  "@odata.id": "/DASH/v1/BootConfigurationCollection",
  "@odata.type": "#BootConfigurationCollection.v1_0_0.BootConfigurationCollection",
  "Id": "BootConfigurationCollection",
  "Members": [
    {
      "@odata.id": "/DASH/v1/BootConfigurationCollection/BootConfiguration",
      "@odata.type": "#BootConfiguration.v1_0_0.BootConfiguration",
      "BootDevices": [
        {
          "Name": "CIM:Windows Boot Manager:1",
          "Value": 0
        },
        {
          "Name": "CIM:UEFI: PXE IPV4 Realtek PCIe GBE Family Controller:1",
          "Value": 1
        },
        {
          "Name": "CIM:UEFI: PXE IPV6 Realtek PCIe GBE Family Controller:1",
          "Value": 2
        }
      ],
      "ElementName": "Bootcfgsetting:0",
      "Id": "BootConfiguration",
      "InstanceId": "Bootcfgsetting:0",
      "InstanceNumber": 0,
      "IsCurrentConfiguration": "No",
      "IsDefaultConfiguration": "No",
      "IsNextConfiguration": "Yes",
      "Name": "Boot Configuration"
    }
  ],
  "Name": "Boot Config Collection"
}

ちゃんとjqで読み込める、まともなJSONが返ってきます。最高かな?

-ji-jo を使う方法

入力するJSONファイルと、出力するJSONファイルのパスをそれぞれ指定する方法です。
Dockerを使う関係上少し面倒になってしまいますが、以下の様な感じです。

# カレントディレクトリを/workdirとしてマウント
# /workdirを実行時のカレントディレクトリにする
# 実行ユーザのUID・GIDをDockerホストと統一
$ alias dashcli="docker run --rm -i -v $PWD:/workdir --workdir /workdir -u $(id -u):$(id -g) dashcli:3.0.0-285"
$ dashcli -ji enumerate_bootconfig.json -jo result.json
$ jq "." result.json
# 省略

微妙なところ

結構よくできている印象のCLIですが、やはりメインはWindows向けなのかいくつか微妙な点があります。

変なエラーが出る

[2020/9/30 21:00 追記]

AMDのDASHサポートにメールしたところ、このエラーが出る事象は把握しており、動作には問題が無いとのこと。
置き換えることでテストケースがfailするようなので、少々邪魔くさいですが諦めてエラーが表示されることは許容しようと思います。
また、修正版をリリースする予定もあるとのことなので、それを待つことにします。

(libcurl.so.4を置き換えないようにDockerfileも修正しました。)

追記ここまで

Dockerfile内で勝手に潰しているのですが、単にインストールするだけでは以下の様なエラーメッセージを毎回吐きます。

$ dashcli version
/usr/bin/dashcli: /usr/bin/libcurl.so.4: no version information available (required by /usr/bin/libwsman_curl_client_transport.so.1)
DASH CLI v3.0.0.285

この /usr/bin/libcurl.so.4 はdashcli-setupのdebパッケージ内に含まれており、インストール時に勝手に配置されます*6
自分でlibcurl3をインストールして、そのlibcurl.so.4へのシンボリックリンクに勝手に置き換えるとちゃんと動いている上にエラーメッセージも出ません。これについてはサポートに問い合わせているので、何か返事があれば追記します。

インストール後に実行されるスクリプトがsudoを使う

debパッケージを展開するとわかるのですが、インストール後に実行されるpostinstというスクリプト内でsudoが使われています。
そのため、Docker内で実行すると sudo をインストールしていないとコケます。

うーん、 どうせパッケージインストール時に権限が必要なので、rootでないユーザは sudo dpkg -i するだろうからこれは不要なのでは……*7

出力に毎回変な改行が混ざる

できるだけ出力はそのままコピペしているので分かると思うんですが、毎回変な改行が先頭に入っています。なんやねんこれ。 -ji-jo を使うときですらなぜかそうなるので微妙な気持ちになります。あんまり実害はないのでまだ許せますが。

まとめ

Linuxで使えるDASH CLIと、それをDockerコンテナに閉じ込めて使う方法の紹介でした。軽くググった限りでは日本語の記事はこれが初出なのではないでしょうか。
今後の展望としてPXEブートできる環境を用意し、このCLIを使用して電源操作・ブート順操作の自動化をすることで、物理マシンに任意のOSをインストールしゼロからシステムをデプロイできる環境の作成を目指しています。

[2020/9/30 21:00 追記]

ブート順を変更できないっぽいため、どうするか少し悩んでいます。PXE→iPXE→HTTPでiPXEスクリプトを問い合わせというフローでブートできることを確認したので、必要な時以外は単にexitするスクリプトを配布すればその後SSDからブートするため、常にPXEブートを最上位に持ってきておくことで対応出来るのでは?と考えています。

追記ここまで

自宅で物理マシンを使ってImmutable InfrastructureとInfrastructure as Codeを実現できそうなのは結構面白いのではないでしょうか。できればあと数台M75q-1 Tinyが欲しいところです。収入が足りない😢


*1:週末は約3.2万で買えるようになっており、ポイント還元キャンペーンが無くても十分安いです

*2:僕はオタクではないのでWindowsマシンも持っています

*3:やり方が分かる人は是非教えてください

*4:というか日本語の情報は存在しない……?

*5:DeveloperGuideには記載が無く、UserGuidにはコマンド例のみが掲載されています

*6:こんなとこに置くの辞めて欲しい……これは問い合わせメールに書くの忘れました

*7:これも問い合わせメールには書き忘れました

GNU Make勉強会を開催した

なぜ今Make?

Makefileを書く機会がほとんどない割に、使う機会は多いなと昔から思っていました。
大学の講義でもC言語で書いたソースコードコンパイルEclipseに任せっきりで、TAとしてトラブルシュートする以外ではMakeはおろかgccを叩くこともほとんどありませんでした。

最近個人的に便利なタスクランナーとしてMakeを使うようになり、もっと効率の良い書き方はないのか?なぜこれは動かないのか?と悩む機会が増えるようになりました。同じ時期にあちこちでMakeの挙動に悩んでいるっぽい声を聞いたため、これは勉強会を開催するしか無いと思い提案したところ、おもったよりも反響があったため開催に至りました。

古くからあるソフトウェアであり、加えてC/C++用のビルドツールとしての役割から、複数のツール/言語にまたがるジェネリックなタスクランナーに切り替わってきたことで、Google検索で正しい情報を得ることが難しくなってきているように感じていることも、開催のモチベーションの一つでした。

資料

あんまり体系的に学ぼうとはしていません。僕が使う機能を重点的におさえて、まぁ最低限のMakefileが書けるくらいを目指して作っています。

スライド中にもありますが演習問題のリポジトリは以下です。

github.com

answersブランチに回答をアップロードしてあります(ex08までしかまだありません申し訳ない)。本当はex11まで作る予定だったのですが 間に合わなかった キリが悪かったので10個としてあります。

学んだこと

なんとなくで書いてなんとなくで読んできたことに説明ができるようになったので良かったです。一方でまだまだ深淵は深く、自分では説明できないことも多数あり、今後も精進が必要だなと感じています。

余談ですが、VSCodeのRemote Containersを使えばWinでもMacでもLinuxでもなんとかなるだろうと思って環境を用意していました。結果的に最初の環境構築でそこそこ時間を取られ、世の中ままならないものですね*1。一応もともと薄い環境を用意していたので、各々には多少の追加セットアップをしてもらうことで凌ぎました。

今回はその程度の対処でどうにかなりましたが、もう少し規模の大きな勉強会なら

  • 事前にセットアップを試してもらう
  • 自分でもいくつかの環境で試す

など、事前準備にはもう少し力を入れないといけないなと痛感しました。

まとめ

  • Makeに詳しい人ツッコミとPull Requestください
  • 本資料およびリポジトリはMITライセンスに則ってご自由にお使い下さい。
    • Twitterでの雑なリプライでも、このブログの紹介でも構わないので、一言頂けると今後のモチベーションになります。
  • そのうちex09とex10の解答もアップロードします

*1:WinではWSL2でなぜか急にDockerが動かず、Manjaro LinuxではRemote Containersが動かないという事態に見舞われました

リモート研修についての雑感

はじめに

 社名は明かしません。知っている人も、わざと明かすような言及はしないで貰えると助かります。なお色々ぼかしたり混ぜたりして書いています。
 

これは何

f:id:pudding_info:20200504235658p:plain
テレワークのイラスト

 入社から一度も出勤せず、全てリモートで研修を受けて一ヶ月経ったので、今時点での自分の感想を言語化して残しておきたいと考えました。もしかしたら今後意見が変わるかも知れないし、変わらないかも知れないヤツです。研修を受けた側の本音はまだ貴重な方だと思うので、リモート研修やってる各社の人事に届け。

 ちなみに、これはエンジニア向けの研修ではなく、それ以外も含めた共通の研修を1ヶ月程度受けたことについての感想です。相当に恵まれた環境であり、先輩社員の方々の努力を節々から感じています。他の会社のリモート研修は知りません。全てを一般化しないで下さい。

著者の状況

  • 2020年の新卒
  • (ソフトウェア)エンジニア職での採用
  • 通勤には電車を使って1時間程度かかる
  • 家に仕事をする部屋がある
  • 元から引きこもりオタク

正直な感想

 これを言うと不謹慎っぽいんですがフルリモートでの研修になって本当に良かったです。以下良かったところです。

  • 通勤電車に乗らなくて良い
    • 感染リスクが〜とかもありますが、純粋に移動時間が減って嬉しい。余裕をもって家事が出来る。朝急がなくて良い。
  • 昼休憩にちゃんと休憩できる
    • やたらコミュ力を発揮したりしなくて良いので楽
  • 別に困っていない
    • そもそもリモートでやるためのコンテンツが用意されているので当たり前だが、別にリモートで困ったと思ったことがない
    • この内容で十分だと思ったし、むしろこれ以上色々やっても意味あるか怪しい

「通勤したい」と思ったことは今のところ一度も無いです。別に顔はリモートでも見ることができ、会話もでき、ある程度仲良くなることも可能でした。業務が終わった後に軽く雑談したり、リモート飲み会をやったりもしています。それ以上の関係性を仕事には特に求めていません*1

 研修のコンテンツに不足感もそれほど感じていません*2。これ以上何かやる必要有る?という気持ちです。冗長なことを続けられても、どんどん失望するだけだと思います。

 一方で、通勤したいサイドの言い分も十分理解出来ました。例えば「家で仕事することを想定していなかったので、まともな椅子や机がなく身体がしんどい」とか、「家のWiFiが不安定/遅く、まともにWeb会議できない」などです。家の設備がそれなりに整っているオタク以外にリモートワークはなかなか厳しいというのは確かにと感じました。「(リアルで)顔が見たい」「(リアルで)会話したい」「(リアルで)一緒に遊びに行きたい」などはあまり賛同できませんでした。別にリモートでよくない?(真顔)

リモート研修で微妙だなと思ったこと

初日出社するかどうかを新卒に委ねる

 そもそも初めての事態だったので仕方ないのですが、「こーーれは微妙なライン」という状況で新卒に「初日来ますか?リモートにしますか?」って聞いたら99%の新卒は出社しますって言うと思います。そこで「や、感染怖いんでリモートにします」って言うヤツはたぶん人生2周目です。

 この引きこもりの僕ですら「一回くらいは出社しておきたいな」と思ったくらいなので、普通の人は出社すると思います。実質一択の質問で責任を新卒に持たせるのはどうかと思います*3

昼飯食べながらの雑談会

f:id:pudding_info:20200504235750p:plain
オンライン飲み会のイラスト

  • 昼飯を用意する時間が十分でない
  • そもそも食べながらとか喋りにくい

などの理由で微妙でした。リアルで会っていれば、食べに行くまでや食べ物を用意する時間などにも会話が発生するかも知れませんが、リモートでは全員手元に食事を用意している段階ではいスタート!なのでコミュニケーションがとりづらいです。昼飯じゃなくておやつの時間とかにしませんか?

成果の見えない(見えにくい)自学自習の時間

 単純にモチベ湧かないです。抽象的な目標と手段を与えられてこれやっといてねと言われても、成果を測定しづらく、またそれがどう役に立つのかイマイチわからないのでやる気になりませんでした。計算ドリルでもやってた方がマシです。

リモート研修で良かったこと

研修の内容自体については言及しませんが、まぁ研修ってこんなもんだよなという気持ちでした。まぁまぁ楽しかったので良かったのでは?それ以上特に言うことはないです。それ以外についてだけ述べます。

服装の自由

 僕はほぼずっと下半身はスウェットで過ごしていました。上半身も単なるパーカーとか、せいぜいシャツをちゃんと着る程度で、寝間着に見えないようにだけ気を遣っていました。その程度の配慮で十分じゃないですか?スーツ着てリモートやってるとこもあるらしく、ウケると言う他ないです*4

同期との雑談の時間

 ガス抜きという意味でも、交流を深めるという意味でも、こういう時間は貴重でした。やっぱりリアルでの細かいコミュニケーションの発生が無い分、こういう時間を無理にでも取って補うしか無いと思います。ちなみに同期の名前はあんまり覚えられませんでした。

社員との雑談の時間

 同期としか話していないと今後の不安が蓄積するばかりなので、先輩社員の方々と喋って解消するというのも大事だなと感じました。人事だけでなく、あらゆる部署の人と一回は話しておけると雰囲気を掴めて良いのではないでしょうか。ちなみに先輩社員の名前はあんまり覚えられませんでした。

来年以降に向けて

 もしかしたら来年以降、自分が研修する側に回る可能性もあるのでいくつか気付いたことを残しておきます。

出社可能になってもリモートの選択肢を残す

 受けていて思ったのは「わざわざ座学を受けるためだけに出社する必要ある??」です。ここで「いやでも同期とのコミュニケーションが〜」とか言うなら座学とは別にコミュニケーション取る日を用意して下さい。要するに、リモートで可能なもののために出社を強要して欲しくないということです。

 出社が難しくなる理由は何も感染症だけではありません。電車が止まるかも知れないし、体調があまり良くないかもしれないし、朝起きれないかも知れない。必要なときなら仕方ないですが、リモートで問題ないものならリモートでいいじゃんというのが僕の主張です。同時に、実施した内容を常に録画しておくことも重要だと思います。後から次の年の反省に活かすことも出来るし、病欠した人のフォローにも使えるからです。

座学におけるフィードバック

 リアルで喋っていれば、フィードバックは視線や身振りからでも得られますが、リモートにこれを期待するのは難しいです。実際、フィードバックが無くて「わかりましたか?…………あー……うーん……………先に進めます」みたいな状況が頻繁に発生しています。これには2つ原因があると考えています。

  1. そもそもフィードバックの方法が用意されていない(or 適切な手段でない)
  2. 喋っている側がフィードバックの確認方法を知らない

 予め研修中に使用するリアクションの手段を決めておくべきでしょう。更に言うとそれは身振り手振りなどではなく、Web上または使用しているツール上で行うことができ、感情を表現できる方法で行うべきだと考えています。前述したように回線の問題で自分のビデオをオンにしないほうが快適に動く人も居るため、身振り手振りは適した方法ではありません。また、👍のみのようなリアクションは、適切なフィードバックをするのに十分でないため、文章orもっと多様なリアクションが使えると良いと思います。

 フィードバックを確認する側も、予めここにこうリアクションしてくれと伝えておくことで、気まずい沈黙を避けることが出来ると思います。これを研修を実施する側の人全員で共有できているとなお良いと思います。

受講者が手を動かして何か出来るコンテンツの用意

 完全な座学なら難しいですが、少しでも受講者の能動的な行動を要求する内容があると自然と話を聞きます。内容的には何でもよく、特定のWebサイトを開く程度で十分かも知れません。その上で何か出来るともっと良いと思います。

 ただ、死ぬほど興味ない内容でひたすらインタラクションを要求されると、辞めたい度が急上昇するのでさじ加減は必要です。

研修の目的と妥当性の提示

 何のためにやるのかよく分からないものをリアルで延々受けさせられたら発狂して辞表たたきつけると思いますが、リモートだとただただ「無視」できます。それで良いなら構いませんが。研修の各内容について

  1. 何を目的として
  2. どのような方法で
  3. なぜその方法が妥当であると判断したか

の3点が分かっているだけで不満は相当減ると感じました。内容にそこまでのめり込めなくても、必要性を理解出来るからです。1、2は問題なくても3に問題がある場合もあります。目的に対して手法がマッチしていなければ(マッチしていないと研修を受ける側が感じれば)、やる意味が無くなってしまうからです。逆に言うと、これが説明できない研修なんて必要ないので辞めれば良いと思います*5

 今年はコンテンツをしっかり練る時間もなく急ごしらえかもしれませんが、来年以降リモートが必要になったときに同じようなことを続けるのは愚策かと思います。特に3について、実施する側はよく考えるべきだと思います*6

最後に

 研修という言葉に良いイメージがなく、ビビりながら受けましたが、それなりに楽しかったので良かったです*7。誰も直面したことが無かった事態においても柔軟に対応し、尽力頂いた社員の方々には大変感謝しています。一方、まだまだリモート研修の可能性はこれからだなと思っているので、もっとこの文化が成熟していけばいいなと感じています。

*1:職場恋愛を夢想する人には最悪な状況かも知れません

*2:人事がどう思ってるかは知らないです。あくまで僕自身の感想です。

*3:結局弊社では初日から全員リモートになりました

*4:顧客の前に出るとか、その様子が全国に公開されるとかなら会社のイメージのためにスーツを要求するのは理解出来ます。

*5:リモートだろうがそうでなかろうが関係無くです

*6:例えばAIを使った新規事業を考案!とかです。何の意味があんの?あんたらAI欠片も知らんのでしょ

*7:別にまだ研修は終わっていません。この一ヶ月やってみてという感想です。