set setting reset

脂肪と糖にはたらくやつ

AWS CLI v2 で 'ascii' codec can't encode characters in position 1-14: ordinal not in range(128)

背景

AWS CLI v2 をインストールし、 EventBridge のリストを取得しようしたところ表題のエラーが発生。

環境

$ /usr/local/bin/aws --version
aws-cli/2.6.0 Python/3.9.11 Linux/5.10.16.3-microsoft-standard-WSL2 exe/x86_64.ubuntu.20 prompt/off

エラー

$ aws events list-rules

'ascii' codec can't encode characters in position 1-14: ordinal not in range(128)

Description に日本語が含まれていると発生する模様。

対応

自分の環境では .bash_profile で以下のようにしたら解決した。

- export LC_ALL=C
+ export LC_ALL=C.UTF-8

export PYTHONIOENCODING=utf-8 しなさいという記事もあったが、これは効果がなかった。

参考

qiita.com

富士そば 日暮里店と渋谷明治通り店

この記事は 富士そばアドベントカレンダー 2019 9日目の記事です。

adventar.org

がっつり遅刻です。申し訳ございません。

富士そば好き度で言えば先日、ラスベガスで開催された某カンファレンスに参加したのですが、
行く前から「帰ってきたら富士そばに行くんだ。。。」と考える程度の者です。

ラスベガスからはロサンゼルス経由で成田に帰国したのですが、成田から自宅への帰路としては京成スカイライナーで日暮里まで行き、そこからなんやかんやで自宅まで帰るわけです。
去年は巣鴨店に行きましたが、今年は別のお店にしようとGoogle Mapで検索すると、日暮里にあるわけですね。富士そば
まぁありそうな雰囲気です。

fujisoba-nippori - Google 検索

いかにもありそうな雰囲気だなぁと思いつつも、去年もどうせ調べた自分としては、それを見逃すはずはないなぁとか考えていたら割と最近開店したようでした。
ですよねー。

【開店】名代 富士そば 日暮里店

というわけで行ってまいりました。日暮里店。

f:id:rriifftt:20191207212157j:plain
富士そば 日暮里店 外観

看板が新しく、いかにもニューウェーブ富士そばという雰囲気。 駅近で使い勝手がよさそうです。

写真にもある通り、 肉骨茶そば なるメニューが見えます。なんだそれは。気になる。
でもあれですよ。合衆国からの帰国一発目の食事で 肉骨茶そば ほどの攻勢に出れる人間なんていませんよ絶対、きっと、たぶん。

そして完全に日和ったぼくはいつも通り紅生姜そばを注文したのでした。

f:id:rriifftt:20191207212823j:plain
紅生姜天そば

ところで紅生姜天そばっていつ頃からできたメニューなんでしょうね。
10年前くらいに富士そば1号店でカレーうどん3食していた頃にはなかったと記憶しています。
いや、あったかな。。なかったと思う。。

新しめの富士そばらしいカエシで黒すぎない感じのおつゆで、これはこれでアレです。
紅生姜天は鉄板なので、特に言うこともないです。 が、あえて言うなら 最 高 です。
ごちそうさまでした。


とはいえ、なんだかもうやっぱり気になって気になって納期のせまるお仕事が手につかず、困りました。
そう、 肉骨茶そば

というわけで翌々日に我がホームであるところの渋谷明治通り店に突撃です。

f:id:rriifftt:20191209123230j:plain

よかった。新進気鋭の日暮里店が編み出した独自メニューじゃなかった。
逆に言えば新進気鋭感があるこちらのメニューを複数店舗で販売する富士そばは相変わらずなんというかちょっとキてますね。
そして迷わず注文しました。

f:id:rriifftt:20191209123618j:plain
肉骨茶そば 引き
f:id:rriifftt:20191209123626j:plain
肉骨茶そば アップ

食べてみると、揚げにんにくが乗った塩豚骨?な感じでして、なんとも言えないデジャブに襲われます。
なんだっけこれ。。食べたことある。。でも麺は富士そばだ。。なんだこれ。。よくわかんない。。という感じでした。
おいしいかおいしくないかは自分にとって重要ではありませんが、不思議なインパクトがあるメニューとなっておりました。
たぶんもう食べないけど。

というわけでごちそうさまでした。

SSM Session Manager のポートフォワードを使って EC2 に RDP する

はじめに

SSM Session Manager でポートフォワードができるようになったそうなので、表題のことを試してみます。

環境

ローカルマシン

Windows 10 です。

> Get-WmiObject Win32_OperatingSystem


SystemDirectory : C:\WINDOWS\system32
Organization    :
BuildNumber     : 18362
RegisteredUser  : Windows ユーザー
SerialNumber    : 00330-51554-55623-AAOEM
Version         : 10.0.18362
> $PSVersionTable.PSVersion
Major  Minor  Build  Revision
-----  -----  -----  --------
5      1      18362  145

> (Get-Module AWSPowerShell).Version
Major  Minor  Build  Revision
-----  -----  -----  --------
3      3      509    0

AWS Tools for PowerShell の Credential 設定

> Set-AWSCredential -AccessKey ************ -SecretKey ************* -StoreAs default
> Initialize-AWSDefaultConfiguration -ProfileName default -Region ap-northeast-1 

後述しますが、設定したはいいものの AWS Tools for PowerShell は使いませんでした。

接続先のEC2

  • Windows Server 2016
  • SSM Agent 2.3.714.0
    • 2.3.672.0 以降であることが必須要件
      • バージョンが低い場合は Run Command から AWS-UpdateSSMAgent が便利
# AWS-UpdateSSMAgent 実行時のログ

Updating amazon-ssm-agent from 2.3.539.0 to latest
Successfully downloaded https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/ssm-agent-manifest.json
Successfully downloaded https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/amazon-ssm-agent-updater/2.3.714.0/amazon-ssm-agent-updater-windows-amd64.zip
Successfully downloaded https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/amazon-ssm-agent/2.3.539.0/amazon-ssm-agent-windows-amd64.zip
Successfully downloaded https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/amazon-ssm-agent/2.3.714.0/amazon-ssm-agent-windows-amd64.zip
Initiating amazon-ssm-agent update to 2.3.714.0
amazon-ssm-agent updated successfully to 2.3.714.0
  • Systems Manager 画面の Managed Instances 一覧にいれば OK

Session Manager Plugin のインストール

PowerShellインストーラーをダウンロードし、起動する。

> invoke-webrequest -uri https://s3.amazonaws.com/session-manager-downloads/plugin/latest/windows/SessionManagerPluginSetup.exe -outfile SessionManagerPluginSetup.exe

> .\SessionManagerPluginSetup.exe

ウィザードが開くので普通にインストールする。 一度ターミナルを再起動し、 session-manager-plugin.exe にパスが通っていることを確認する。

> session-manager-plugin.exe

The Session Manager plugin was installed successfully. Use the AWS CLI to start a session.

ポートフォワードセッションの確立

AWS Tools for PowerShell を使います。

> Start-SSMSession  -Target "i-************" -DocumentName "AWS-StartPortForwardingSession" -Parameter @{ 'portNumber' = "3389"; "localPortNumber" = "56789" }

Start-SSMSession : i-*********** is not connected. と怒られる。 WSL の AWSCLI からは aws ssm start-session できたので、EC2 問題なさそう。

公式によると Start-SSMSession is not currently supported by AWS Tools for PowerShell on Windows local machines. とのこと。
かなしい。 https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartSession.htmldocs.aws.amazon.com

仕方ないので AWSCLI にします。

AWSCLI セットアップ

chocolatey インストール

> Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

Pythonインストール

chocolatey からインストールします。

> choco install python -y
> python -V
Python 3.7.3                                                                                                            

AWSCLI インストール

pip からインストールします。

> pip install awscli

Credential の設定

~\.aws\credential~\.aws\config によしなに設定します

# .aws/credential
[default]
aws_access_key_id = ******************
aws_secret_access_key = **********************
# .aws/config
[default]
region = ap-northeast-1

ポートフォワードセッションの確立(リベンジ)

> aws ssm start-session --target i-04cc97356f6474cf3 --document-name AWS-StartPortForwardingSession --parameters "portNumber=3389,localPortNumber=56789"

Starting session with SessionId: *******-****************
Port 56789 opened for sessionId *******-****************. 

どうやらうまくいった模様。

いざRDP

f:id:rriifftt:20191001182516p:plain
localhost:56789 に対して RDP します。

f:id:rriifftt:20191001183345p:plain
どうやらつながったようです。
今回はサーバーローカルの Administrator が生きているので、パスワードを入力してみます。

f:id:rriifftt:20191001183041p:plain
ログインできました。

おわり

PowerShell でもできるようになってほしいですね!

おまけ

コマンドを書くのがだるくなったので、指定した Name タグの EC2 インスタンスに対して StartPortForwardingSession する ps1 を作りました。

github.com

Mac の pbcopy と同じことを Windows Subsystem For Linux (ubuntu) でもやりたい

はじめに

最近ギョームマシンをMacからWindowsに変えました。
Windows Server Container を使うかもしれないし、WSL がよくなっているという噂を聞いたので、もしかして Windows を使わない理由がないのではと考えたからです。
ただ、細かいところで Mac での慣れが通用しないことがあり、表題の件もその例の一つです。

pbcopy とは

pbcopy は標準出力をパイプで食わせるとクリップボードにコピーできる便利機能です

ubuntu on WSL では

ぐぐるxsel なるものを使うとよいとあったので試してみます。

$ sudo apt-get install xsel

インストールしたら cat hoge.txt | xsel --clipboard --input のように使うとのことでしたが、以下のエラーとなりました。

xsel: Can't open display: (null)
: Inappropriate ioctl for device

なんだか難しそうなエラーなので他の方法がないか調べてみます。

clip.exe

すると Stackover Flow にたどり着きました。

stackoverflow.com

WSL では Windows 上の exe をシームレスに扱えますので、Windows 標準の clip.exe で事足りそうです。

$ cat hoge.txt | clip.exe

あとはエイリアスを作りたければご自由にという感じですね。
この件はしばらくこれで乗り切れそうです。

宛先ごとに並列でpingする

というものをpythonで作りました。

github.com

pacemakerping RA というものを使い、スプリットブレイン対策のためにNW監視をしているのですが、
宛先ごとにシーケンシャルに ping を撃つという仕様であることから、対象に増減があると timeout などの調整がしんどいというマイナーな事情がありまして。
それを置き換えたいという目的です。

所感としては concurrent.future が便利でした。
また、 Subprocess にも run というメソッドが追加されていて、とても使いやすかったです。

SHIROBAKOとチームビルディングについて

この記事はSHIROBAKOアドベントカレンダーの12日目です。

adventar.org

SHIROBAKOといえば最高なわけですが、なぜ最高なのかは人それぞれでしょう。
ただ、モノづくりの現場を描ききった本作に何かしらのシンパシーを感じている方は多いのではないでしょうか。
ぼくもへなちょこDTMerであり、へっぽこエンジニアだったりするので、感じるものがあります。

現代においては(本質をついているかどうかはともかく)アジャイル開発はある種スタンダードになり、
DevOpsやSREといった発展した文脈も生まれてきている中、それらが原因というわけではないにしても現場に唐突な変化が起きることは少なくありません。

人は基本的に集中を削がれるのを嫌う生き物ですので、場当たり的な変更が繰り返されると疲弊してしまいます。 でもモノづくりは好きだし、携わっていて思い入れも強いプロダクトは成功してほしい、そんなモチベーションで課題やタスクと対峙するという日々を送ったり送らなかったりしています。

そんな感じで心が荒れ気味のとき、SHIROBAKO 2話 「あるぴんはいます!」はキます。

f:id:rriifftt:20181211220444p:plain
あの。。つまり原画から全部新作ということですか???

冒頭から立ち込める暗雲、そして訪れるカオス。やばそうなイキフン。
監督と円さんの口論を経て、なべPに無茶振りされたみゃーもりは緊急会議を開くことにします。

f:id:rriifftt:20181211223331p:plain
今回の作画を直すとして、作業に入る前にもっかいあるぴんやえくそだすっ!のキャラについて、みんなに確認しておくのはどうでしょう?大切なことだと思うんです。

昨今では心理的安全性といった言葉をよく聞くようになりました。チームのパフォーマンスを最大化するためのフレームと捉えていますが、Googleでは 効果的なチームを可能とする条件は何か というリサーチを行ったそうで、この re:Work という記事はちょっとした話題になりました。

rework.withgoogle.com

個人的には、そんなんなくてもどうにかするのがプロでしょっていうのと、やっぱ人間だし必要だよねそういうのっていうのが半々だった時期があるのですが、ないよりはあった方がいいに決まってるじゃんと言われると、まぁ、ぐうの音も出なかったわけです。

モヤッてるときにモヤッたまま進むとモヤッたモノができます。
モヤッたモノに関わった人たちは、少なからずモヤモヤを抱えなければなりません。できればどうにかしたいものです。

どうにかするには、答えは状況によりけりでしょうが、物語の中では対話をすることになります。

f:id:rriifftt:20181211223956p:plain
演出プランを全面的に見直すそうです!

立ち話はコスパがよい と聞いたことがありますが、たしかに話すだけで済むなら簡単です。
対話によって 自分はその場に参加している という当事者意識も働くでしょう。質のよい時間であった方がよいという合理的な判断から、ネガティブであってもポジティブであっても建設的な議論をすることを心がけるでしょう。
そして、よい議論を行うにあたっては、そもそも心理的安全性が前提として必要だったりもします。また、共感も重要な要素となることがあります。

f:id:rriifftt:20181211231159p:plain
うんうん!わかるわかるー!

という共感からの

f:id:rriifftt:20181211231722p:plain
良くも悪くも脇が甘いんですよねー

この山田さんの表情なんかは非常によい例ではないでしょうか。

f:id:rriifftt:20181211232219p:plain
さっきまでこうだった人が
f:id:rriifftt:20181211231722p:plain
こうですからね(しつこい)

そんなこんなで監督の思いがみんなに伝わり、

f:id:rriifftt:20181211232749p:plain

なんやかんやで、あるぴんはここにいます!になるわけです。

re:Workの話に戻ると、チームの課題として以下のことが挙げられています。

従業員はほとんどの仕事をチームの一員として行います。しかし、チームの対人関係に問題が生じたり、メンバーのスキルが適切でなかったり、あるいはチームとしての目標が明確でなかったりすると、生産性の低下やメンバー間の摩擦が生まれるといった問題が生じかねません。

このような課題に対するある種の回答が、このお話には内包されていると思うのです。
人と人がわかり合うニュータイプ的な感覚を共有することと、攻殻機動隊的なスタンドプレーによるチームワークというような、個人的に理想的なチーム。
いいなぁと思うわけです。いいなぁ。

まぁ、そもそも監督ちゃんとしろよという意見ももっともですが、口下手な監督もいますからね。仕方ないですね。
ギャップがあることが問題であるなら埋めた方がいいでしょうね。

見返せば見返すほど発見があるSHIROBAKOですが、今回はこんなところです。

最後に、心理的安全性という観点では監督がスタジオでこんなことも言っていますね。

f:id:rriifftt:20181211233840p:plain
あたしここにいていいのかな?いてよーし!みたいな?

武蔵野アニメーションGoogleかなんかなのかな。

こちらからは以上です。ありがとうございました。

pgpool インストール時に configure: error: header file <libmemcached/memcached.h> is required for memcached support

背景

pgpool-4.0.1 を検証していたら pgpool-4.0.2 が出たのでインストールしてみたところ表題のエラーとなりました。

エラー発生時のインストール手順

pgpoolのインストールはソースから行いますが、インメモリクエリキャッシュを使いたいのでlibmemcachedをインストールします。

# yum install libmemcached

以下の手順で configure してみると WARNING がでます。

# cd /usr/local/src
# curl -L 'http://www.pgpool.net/download.php?f=pgpool-II-4.0.2.tar.gz' -o pgpool-II-4.0.2.tar.gz
# tar xzf pgpool-II-4.0.2.tar.gz
# cd pgpool-II-4.0.2
# ./configure --with-pgsql=/usr/pgsql-9.6 --with-openssl --with-libmemcached=/usr/lib64/libmemcached.so.11

~略~
configure: WARNING: unrecognized options: --with-libmemcached 

--with-libmemcached オプションは非サポートとなり、 --with-memcached となったようです。
なお、ビルドそのものは可能でした。

オプションを変更して再チャレンジしてみると前述のエラーとなりました。

# ./configure --with-pgsql=/usr/pgsql-9.6 --with-openssl --with-libmemcached=/usr/lib64/libmemcached.so.11

~略~

checking libmemcached/memcached.h usability... no
checking libmemcached/memcached.h presence... yes
configure: WARNING: libmemcached/memcached.h: present but cannot be compiled
configure: WARNING: libmemcached/memcached.h:     check for missing prerequisite headers?
configure: WARNING: libmemcached/memcached.h: see the Autoconf documentation
configure: WARNING: libmemcached/memcached.h:     section "Present But Cannot Be Compiled"
configure: WARNING: libmemcached/memcached.h: proceeding with the compiler's result
configure: WARNING:     ## ---------------------------------------- ##
configure: WARNING:     ## Report this to pgpool-hackers@pgpool.net ##
configure: WARNING:     ## ---------------------------------------- ##
checking for libmemcached/memcached.h... no
configure: error: header file <libmemcached/memcached.h> is required for memcached support

why?

メッセージの通り libmemcached/memcached.h が存在しないためのようでした。
yum でインストールしたからでしょうか。バイナリのみがサーバー上に存在しています。

# updatedb && locate libmemcached
/usr/lib64/libmemcached.so.11
/usr/lib64/libmemcached.so.11.0.0
/usr/lib64/libmemcachedprotocol.so.0
/usr/lib64/libmemcachedprotocol.so.0.0.0
/usr/lib64/libmemcachedutil.so.2
/usr/lib64/libmemcachedutil.so.2.0.0
/usr/share/doc/libmemcached-1.0.16
/usr/share/doc/libmemcached-1.0.16/AUTHORS
/usr/share/doc/libmemcached-1.0.16/COPYING
/usr/share/doc/libmemcached-1.0.16/ChangeLog
/usr/share/doc/libmemcached-1.0.16/README
/usr/share/doc/libmemcached-1.0.16/THANKS
/usr/share/doc/libmemcached-1.0.16/TODO

libmemcached をソースでインストールしてみる

以下の手順で libmemcached をソースからインストールしてみます。

# curl -L https://launchpad.net/libmemcached/1.0/1.0.18/+download/libmemcached-1.0.18.tar.gz -o libmemcached-1.0.18.tar.gz
# tar xzf libmemcached-1.0.18.tar.gz
# cd libmemcached-1.0.18
# ./configure
# make
# make install

すると、 libmemcached は /usr/local/include/libmemcached にインストールされます。

# updatedb && locate memcached.h
/usr/local/include/libmemcached/memcached.h
~略~

再度 pgpool をビルド

先程のエラーメッセージでは configure: error: header file <libmemcached/memcached.h> ということでしたが、
まさかヘッダーファイルのみをオプションに指定するわけではないだろうということで、ディレクトリを指定してみるとビルドが通りました!

# ./configure --with-pgsql=/usr/pgsql-9.6 --with-openssl --with-memcached=/usr/local/include/libmemcached
# make && make install

こういうものなんですかね。
とりあえずこれで進めてみます。