EBS 拡張で growpart がコケてヒヤヒヤした

古いインスタンス (M3.medium) の EBS を拡張する作業があったのですが、 growpart がエラーを返してきて焦ったので。

LANG が悪い

echo $LANG などして、 LANG=ja_JP.UTF-8 つまりシェルが日本語環境だとエラーが帰ってくるようです。 こんなん。

[root@ebs-fuyashitai-instance ~]# growpart /dev/xvda 1
/bin/growpart: 行 170: シリンダ数*255、63*: 構文エラー: オペランドが予期されます (エラーのあるトークンは "シリンダ数*255、63*")

どうする？

export LANG="en_US.UTF-8" とかして、セッション維持しているシェルだけ英語環境にしてから作業しましょう。

[root@ebs-fuyashitai-instance ~]# locale
LANG=ja_JP.utf8
LC_CTYPE="ja_JP.utf8"
LC_NUMERIC="ja_JP.utf8"
LC_TIME="ja_JP.utf8"
LC_COLLATE="ja_JP.utf8"
LC_MONETARY="ja_JP.utf8"
LC_MESSAGES="ja_JP.utf8"
LC_PAPER="ja_JP.utf8"
LC_NAME="ja_JP.utf8"
LC_ADDRESS="ja_JP.utf8"
LC_TELEPHONE="ja_JP.utf8"
LC_MEASUREMENT="ja_JP.utf8"
LC_IDENTIFICATION="ja_JP.utf8"
LC_ALL=
[root@ebs-fuyashitai-instance ~]# export LANG="en_US.UTF-8"
[root@ebs-fuyashitai-instance ~]# locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
[root@ebs-fuyashitai-instance ~]# growpart /dev/xvda 1
CHANGED: partition=1 start=2048 old: size=62908492 end=62910540 new: size=209710462,end=209712510

できましたね、このあとはファイルシステムの拡張を実施すればオッケーです。 しかしまー、使っているプロプライエタリのミドルウェアが必須要件として LANG に JP な環境を要求するので、スルッと終わるはずの作業が終わらなく、めっちゃ焦りましたね。

参考： hacknote.jp

Logicool Flow で Synargy を思い出すなどし

Synergy という、バックグラウンドにクライアントを立ち上げておくと、クライアントの動作しているマシン間でマウスとクリップボードを共有できるソフトウェアがあったのだ。 2011 年までは普通に使っていたのですが、確かそのあたりで有料化したので使うのをやめた記憶があります。 今見たら、 COVID-19 のために一時的に無料化？しているようでした。

Logicool Flow が (覚えている限り) これと同じ動作をしたので、「やるじゃん」という感じだったのでお気持ちをしたためておく。

ググるとわりと評価がよくない

評価が芳しくない記事が表示されるので、これはヤハりだめなやつか？ と思ったのですが、 開発用の MacBookPro で使用している M570 (t 付きではない発売直後のモデル) がついに右クリック認識しなくなり、何年持ったんだ……？ という感じだったので、買い換える前にダメもとで試してみっかーというお気持ちでした。

Flow

これまた発売直後に購入した MX Ergo を、画面左 Windows (母艦)・画面右 MacBookPro (連携先) として設定してみました。 初期設定では、画面端に移動すると別のマシンへマウス制御が移り事故が多発したので、CTRL クリックで明示的な動作をしないと制御が切り替わらないようにしてあります。 (画面端ってやつがわからんねんな……？)

反応はどうか

Flow 有効化した PC を同一ネットワーク ( 192.168.0.0/24 とかそういう意味だと思われる) に配置することで認識するのですが、1K のお部屋の以下条件下で利用しています。

• 母艦
  • Uniflying
  • MX Ergo に付属していたレシーバを利用
  • 有線 LAN でルータ->ハブと繋ぎ、ローカルネットワークはギガビット通信
  • CPU: i7-6900k, RAM: 32Gbyte
• 連携先
  • Uniflying
  • M570 に付属していたレシーバをそのまま流用
  • 無線 LAN でルータに直接 11ac 接続
  • Retina 2019 model(Thunderbolt 2port), RAM: 16Gbyte

マシンをまたぐとき稀に体感できる引っ掛かりがありますが、だいたいの場合において感じられるストレスはありません、Windows 側で録画エンコしながら、Xcode でビルドぶん回してる MacBookPro へ、お互いにスッと切り替わる感じ。 Synergy も当時はわりとパッと切り替わってスゴイーと思ったものですが、遜色ないですね。 しかし、いずれのマシンも仕事の都合上それなりスペックなので、低スペマシンだとどうなるかわからないです……。 多分切替時に引っかかるんじゃないかなあ。

まとめ

出た頃はボドボドだったと思われる記事 (日付みたら一年以上前のものがほとんどだった) が見受けられましたが、実際利用してみた所、少なくとも自身の利用環境では酷評するような動作ではありませんでした。 最悪見失ったら MacBookPro 本体にトラックパッドついとるしな。 普通ならここであまぞんとかの商品リンクが出てくると思うのですが、アフィ欲しいわけでもないので、商品自体は各自探してください。 ヨドバシとかビックカメラとか実店舗最強。

疑問

まとめのあとに疑問ってなんだよ、という感じですが。 これ連携先 (つまり二台目) の Logicool Options にマウス登録するとき、利用していないプロファイル番号 (僕の場合は 1 を Windows で利用していたので、2 を選択した) に切り替えてから、マウスの電源を切って Logicool Options を起動してマウスの電源再度入れて、ってして Logicool Options にマウス認識させるのですが、別に Flow 使わなくてもマウス自体のハードスイッチでプロファイル切り替えれば別々のマシンで切り替えて利用できるんですよね。 たぶん Flow 使う最大の利点は、ハードスイッチ押さなくてもシームレスに切り替えれる、クリップボードが共有できる、だと思うのですが、それぞれ異なる業種の仕事で利用するマシン間の共有なので、僕はクリップボード共有切っちゃったんですよね。

あれ、 Flow 使わなくてもよかった……？😂

追記 2020/07/20

よーくマウス見てたら Flow 設定したマシンの間をまたぐ時に、マウスのプロファイル番号の点灯が切り替わってました。 Flow はいちいちハードボタン押してプロファイル切り替えるのを勝手にやってくれる的な動作だったんですね！

クリップボード共有しないなら、ますます Flow なしでハードボタン切り替えでいい気がしてきた。

vagrant 起動時に setup が無いつってコケるが起動できている

VirtualBox と Vagrant の起動ステータスが連動しているわけじゃないんすねえ。

bash: line 4: setup: command not found

Vagrant で新しく amznlinux2 の環境を作成した所、 vagrant up の処理中にタイトルのようなエラーが出てしまい悩む羽目に。 この setup コマンド、 VirtualBox 側のアドオンコマンド？らしいので、 Vagrant 自体は無罪という想定で、VirtualBox のマイナーバージョン最新版へアップデートなり GuestAddon を再インストールするなり試してみたのですがだめした……。 結局公式の issue に以下の記述を見つけたので試した所、無事処理が中断することなく vagrant up が最後まで完遂すつようになりました。 メンテナンスしている (前任者から引き継いだ) 環境が軒並みかなり古く、 Docker で環境構築するより仮想環境で一式保持するほうが楽なので、いやーよかった助かった。

vagrant plugin update vagrant-vbguest

github.com

Ruby こわれる〜 (二度目

こいついつも壊してんな？ という感じですが言い訳させてください！ MacBookPro の USB-C ポート奥側が反応しなくなって GeniusBar に修理出したら IO ポート交換だったんです！ 事前チェックでディスクの初期化されて TimeMachine から環境復活させて壊れたんです……。

ld: library not found for -lssl

タイトルの通り、 OpenSSL のライブラリ向き先があってないのか、bundle install 時にライブラリ見つけられませんでした。 のでこうする。

bundle config --global build.mysql2 --with-opt-dir="$(brew --prefix openssl)"
bundle install --path vendor/bundle/

参考：

qiita.com

Ruby こわれる〜

rbenv + ruby-build を anyenv 経由でインストールしているのだけれど、 OpenSSL のライブラリを Homebrew でインストールされるものを見ているため、うっかり brew upgrade で依存関係から OpenSSL が更新されると、 Ruby 処理系がまるごと壊れて気絶してしまう。

Capistrano デプロイする環境をシュッと作る

プロジェクト初期にしかやらないから、毎回忘れて泣きながら調べてる。　ので、備忘録を兼ねて。

ちなみにこの手順を書くにあたって、社内のナレッジ ( docbase 使ってます ) を確認していたら、退社した元 CTO 兄貴迫真のカレーレシピを見つけて「日本人だいたい同じようなレシピに行き着くのか？」と DASH カレーと見比べてた。

MySQL のデータ移行前後で、データの正当性を担保できるのか？！

できるのか？ その謎を解き明かすためスタッフはアマゾンのお口へと向かった……。

関係ないけど MacBook Air 2020 出ましたね。