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
しなさいという記事もあったが、これは効果がなかった。
参考
富士そば 日暮里店と渋谷明治通り店
この記事は 富士そばアドベントカレンダー 2019 9日目の記事です。
がっつり遅刻です。申し訳ございません。
富士そば好き度で言えば先日、ラスベガスで開催された某カンファレンスに参加したのですが、
行く前から「帰ってきたら富士そばに行くんだ。。。」と考える程度の者です。
ラスベガスからはロサンゼルス経由で成田に帰国したのですが、成田から自宅への帰路としては京成スカイライナーで日暮里まで行き、そこからなんやかんやで自宅まで帰るわけです。
去年は巣鴨店に行きましたが、今年は別のお店にしようとGoogle Mapで検索すると、日暮里にあるわけですね。富士そば。
まぁありそうな雰囲気です。
いかにもありそうな雰囲気だなぁと思いつつも、去年もどうせ調べた自分としては、それを見逃すはずはないなぁとか考えていたら割と最近開店したようでした。
ですよねー。
というわけで行ってまいりました。日暮里店。
看板が新しく、いかにもニューウェーブ富士そばという雰囲気。 駅近で使い勝手がよさそうです。
写真にもある通り、 肉骨茶そば
なるメニューが見えます。なんだそれは。気になる。
でもあれですよ。合衆国からの帰国一発目の食事で 肉骨茶そば
ほどの攻勢に出れる人間なんていませんよ絶対、きっと、たぶん。
そして完全に日和ったぼくはいつも通り紅生姜そばを注文したのでした。
ところで紅生姜天そばっていつ頃からできたメニューなんでしょうね。
10年前くらいに富士そば1号店でカレーうどん3食していた頃にはなかったと記憶しています。
いや、あったかな。。なかったと思う。。
新しめの富士そばらしいカエシで黒すぎない感じのおつゆで、これはこれでアレです。
紅生姜天は鉄板なので、特に言うこともないです。 が、あえて言うなら 最 高
です。
ごちそうさまでした。
とはいえ、なんだかもうやっぱり気になって気になって納期のせまるお仕事が手につかず、困りました。
そう、 肉骨茶そば
。
というわけで翌々日に我がホームであるところの渋谷明治通り店に突撃です。
よかった。新進気鋭の日暮里店が編み出した独自メニューじゃなかった。
逆に言えば新進気鋭感があるこちらのメニューを複数店舗で販売する富士そばは相変わらずなんというかちょっとキてますね。
そして迷わず注文しました。
食べてみると、揚げにんにくが乗った塩豚骨?な感じでして、なんとも言えないデジャブに襲われます。
なんだっけこれ。。食べたことある。。でも麺は富士そばだ。。なんだこれ。。よくわかんない。。という感じでした。
おいしいかおいしくないかは自分にとって重要ではありませんが、不思議なインパクトがあるメニューとなっておりました。
たぶんもう食べないけど。
というわけでごちそうさまでした。
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
が便利
- バージョンが低い場合は Run Command から
- 2.3.672.0 以降であることが必須要件
# 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
localhost:56789
に対して RDP します。
どうやらつながったようです。
今回はサーバーローカルの Administrator が生きているので、パスワードを入力してみます。
ログインできました。
おわり
PowerShell でもできるようになってほしいですね!
おまけ
コマンドを書くのがだるくなったので、指定した Name タグの EC2 インスタンスに対して StartPortForwardingSession する ps1 を作りました。
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 にたどり着きました。
WSL では Windows 上の exe をシームレスに扱えますので、Windows 標準の clip.exe で事足りそうです。
$ cat hoge.txt | clip.exe
あとはエイリアスを作りたければご自由にという感じですね。
この件はしばらくこれで乗り切れそうです。
宛先ごとに並列でpingする
SHIROBAKOとチームビルディングについて
この記事はSHIROBAKOアドベントカレンダーの12日目です。
SHIROBAKOといえば最高なわけですが、なぜ最高なのかは人それぞれでしょう。
ただ、モノづくりの現場を描ききった本作に何かしらのシンパシーを感じている方は多いのではないでしょうか。
ぼくもへなちょこDTMerであり、へっぽこエンジニアだったりするので、感じるものがあります。
現代においては(本質をついているかどうかはともかく)アジャイル開発はある種スタンダードになり、
DevOpsやSREといった発展した文脈も生まれてきている中、それらが原因というわけではないにしても現場に唐突な変化が起きることは少なくありません。
人は基本的に集中を削がれるのを嫌う生き物ですので、場当たり的な変更が繰り返されると疲弊してしまいます。 でもモノづくりは好きだし、携わっていて思い入れも強いプロダクトは成功してほしい、そんなモチベーションで課題やタスクと対峙するという日々を送ったり送らなかったりしています。
そんな感じで心が荒れ気味のとき、SHIROBAKO 2話 「あるぴんはいます!」はキます。
冒頭から立ち込める暗雲、そして訪れるカオス。やばそうなイキフン。
監督と円さんの口論を経て、なべPに無茶振りされたみゃーもりは緊急会議を開くことにします。
昨今では心理的安全性といった言葉をよく聞くようになりました。チームのパフォーマンスを最大化するためのフレームと捉えていますが、Googleでは 効果的なチームを可能とする条件は何か
というリサーチを行ったそうで、この re:Work という記事はちょっとした話題になりました。
個人的には、そんなんなくてもどうにかするのがプロでしょっていうのと、やっぱ人間だし必要だよねそういうのっていうのが半々だった時期があるのですが、ないよりはあった方がいいに決まってるじゃんと言われると、まぁ、ぐうの音も出なかったわけです。
モヤッてるときにモヤッたまま進むとモヤッたモノができます。
モヤッたモノに関わった人たちは、少なからずモヤモヤを抱えなければなりません。できればどうにかしたいものです。
どうにかするには、答えは状況によりけりでしょうが、物語の中では対話をすることになります。
立ち話はコスパがよい
と聞いたことがありますが、たしかに話すだけで済むなら簡単です。
対話によって 自分はその場に参加している
という当事者意識も働くでしょう。質のよい時間であった方がよいという合理的な判断から、ネガティブであってもポジティブであっても建設的な議論をすることを心がけるでしょう。
そして、よい議論を行うにあたっては、そもそも心理的安全性が前提として必要だったりもします。また、共感も重要な要素となることがあります。
という共感からの
この山田さんの表情なんかは非常によい例ではないでしょうか。
そんなこんなで監督の思いがみんなに伝わり、
なんやかんやで、あるぴんはここにいます!になるわけです。
re:Workの話に戻ると、チームの課題として以下のことが挙げられています。
従業員はほとんどの仕事をチームの一員として行います。しかし、チームの対人関係に問題が生じたり、メンバーのスキルが適切でなかったり、あるいはチームとしての目標が明確でなかったりすると、生産性の低下やメンバー間の摩擦が生まれるといった問題が生じかねません。
このような課題に対するある種の回答が、このお話には内包されていると思うのです。
人と人がわかり合うニュータイプ的な感覚を共有することと、攻殻機動隊的なスタンドプレーによるチームワークというような、個人的に理想的なチーム。
いいなぁと思うわけです。いいなぁ。
まぁ、そもそも監督ちゃんとしろよという意見ももっともですが、口下手な監督もいますからね。仕方ないですね。
ギャップがあることが問題であるなら埋めた方がいいでしょうね。
見返せば見返すほど発見があるSHIROBAKOですが、今回はこんなところです。
最後に、心理的安全性という観点では監督がスタジオでこんなことも言っていますね。
武蔵野アニメーションは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
こういうものなんですかね。
とりあえずこれで進めてみます。