あれ?iTerm2でコピーできんくなった

いつの日か、iTerm上で文字列を選択しても、コピーできんくなった。。
いや、あれ?このインスタンスだとできるけど、これだとできんなぁ。。みたいな感じだったので、まぁ、ついてないだけやろって思ってたけど、いやもうムリコレーってなったんで、雑にググったらこちらのページに行き着きました。

gozuk16.hatenablog.com

ありがとうございます、助かりました!
なんかvi起動したときの、 visual mode でよく起きるわぁ〜とか思ってたらその通りでございました。
重複になりますが、僕もウェブに残しておきます 🙇‍♂️

  • Preferences > Profile > Terminal > Terminal Emulation
    • Enable mouse reporting のチェック外す

Amazon LinuxのタイムゾーンをUTCからJSTに変える

Amazon Linux(2ではない)を選択してインスタンスを立てたらタイムゾーンUTCだったのでJSTに変更しました。

  • OSを確認
    CentOSってイメージだったけど、 rhel fedora ってなってるってことは、必ずしもCentOSと一緒ってことではなさそうなんすね。
$ cat /etc/os-release
NAME="Amazon Linux AMI"
VERSION="2018.03"
ID="amzn"
ID_LIKE="rhel fedora"
VERSION_ID="2018.03"
PRETTY_NAME="Amazon Linux AMI 2018.03"
ANSI_COLOR="0;33"
CPE_NAME="cpe:/o:amazon:linux:2018.03:ga"
HOME_URL="http://aws.amazon.com/amazon-linux-ami/"
  • 時間を確認
    うん、9時間ずれてる。
$ date
202078日 水曜日 02:23:56 UTC
  • /etc/sysconfig/clock を修正
$ sudo vi /etc/sysconfig/clock
#ZONE="UTC"
ZONE="Asia/Tokyo"
UTC=true
sudo ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
  • 時間を確認
    9時間戻った。
$ date
202078日 水曜日 11:41:30 JST
  • crondを再起動
    Amazon Linux(2ではない)は、 systemctl が入ってなかったので、 service コマンドで再起動すれば良さそう。
$ sudo service crond restart
Stopping crond:                                            [  OK  ]
Starting crond:                                            [  OK  ]

Amazon Linuxの言語設定を変更した

言語設定が英語のUTF-8になってたので、日本語設定しておいた。

$ cat /etc/sysconfig/i18n
LANG=en_US.UTF-8

でもlocaleは日本語になってた。

$ locale
LANG=ja_JP.UTF-8
LC_CTYPE="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
LC_ALL=

まぁ、どっかの rc かなんかで設定してるんかなと推測。

$ echo $LANG
ja_JP.UTF-8

とりま変えとく

$ sudo vi /etc/sysconfig/i18n
#LANG=en_US.UTF-8
LANG=ja_JP.UTF-8

DebianのLocal timeをJSTに変更した

EC2でDebian/Ubuntuベースのインスタンスを立ち上げたときに、だいたい UTC になってて9時間ほど前の時間になってると思う。
それはちょっと面倒なので、 JST に変更します。

$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
  • timezoneの確認
$ timedatectl
               Local time: Thu 2020-07-09 03:56:56 UTC
           Universal time: Thu 2020-07-09 03:56:56 UTC
                 RTC time: Thu 2020-07-09 03:56:57
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: no
  • 東京のtimezoneの値を確認
$ timedatectl list-timezones|grep Tokyo
Asia/Tokyo
  • timezoneを東京に変更
$ sudo timedatectl set-timezone Asia/Tokyo
  • 東京の時間になったか確認
$ timedatectl
               Local time: Thu 2020-07-09 13:02:27 JST
           Universal time: Thu 2020-07-09 04:02:27 UTC
                 RTC time: Thu 2020-07-09 04:02:28
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: no

インスタンスを再起動しても、Local timeが JST のままだったので、とりあえずよしとしました。

Bitnamiの右ロゴリンクを無効にした

Bitnami Redmineでもほぼ同じだった。

  1. sshでログイン
  2. コマンド実行
$ sudo /opt/bitnami/apps/wordpress/bnconfig --disable_banner 1
  1. httpdリスタート
$ sudo /opt/bitnami/ctlscript.sh restart apache
Unmonitored apache
Syntax OK
/opt/bitnami/apache2/scripts/ctl.sh : httpd stopped
Syntax OK
/opt/bitnami/apache2/scripts/ctl.sh : httpd started at port 80
Monitored apache

お前のパソコンを構成管理してやろうか

この記事は GMOペパボ Advent Calendar 2018 の14日目の記事です。

qiita.com

 さっむいですね。。
前回の記事が「あっついですね」で始まっていたのにもう寒くなってしまいました。寒暖差が体に堪えても、普通に会社に出て普通に仕事しています。

 最近ですね、お仕事してる時にこう言われることが多くなってきたんです。

  • 開発環境が壊れて開発すべきページが見れなくて困っている
  • テンプレートのデザインしたので、コミットしておいてもらえませんか

 あれ?何かが違う気がする。。。

気がついたら、そのたびに小一時間、下手したら丸一日かかりっきりでパソコンを直してました。

  • Ruby のバージョンが違う
  • コンテナが buzy で止まってる
  • pid ファイルがあるのにサーバが止まってる
  • Python3 にしないと動かないはずなのに動かない
  • Composer がエラー吐く
  • PuppetLabs の VM イメージが古すぎて GnuPG の署名が通らなくなってた
  • rbenv の git リポジトリが変わってるみたいで Puppet が止まる
  • 会社でホストしてた yum リポジトリがなくなってた

 などなど、そもそも構築方法を見直さなければならないものから、手順自体を見直さなければならないものまで、多種多様の「動かなくなった」案件が舞い降りました。
 僕はわりと壊れたものを直すのが好きなので、時間がかかっても最終的に直してしまっていたのですが、ちょっと時間取られすぎかなって思ったり、いやいや、そもそもちゃんとした開発環境もないのにちゃんと開発できてるんか?生産性とか開発のテンポってみんなどう感じてる?みたいな思いが頭の中でグールグルしていました。
 そんな家でビールを飲んでテレビを見てうとうとしていた時に、なぜかデーモン閣下が僕にこうささやいていました。

「お前のパソコンを構成管理してやろうか!」

 というのは嘘なんですが、これは結構大事なんじゃあなかろうかと思いました。
 確かに僕たちが開発してるものは、維持しなければならない技術スタックが多くなってきてまして、それらを維持するための解決案もあってケアされていると思っていましたが、それをブラッシュアップしきれていない状況でした。
このことについては、我らが偉大なるリーダーも課題感を持っており、会社ブログで書いてました。

tech.pepabo.com

 ただ、僕としては DB を除く全てのロールをコンテナ化したいと思っていて、そのコンテナから社内 OpenStack のイメージを作成してサンドボックス環境化して行きたかったんですね。
で、環境作るときはとりあえず docker-compose up しといて!って言ったら終わる感じにしておきたかったんですが、今の puppet どうする? capistrano どうする?みたいなよくある構成管理はどのツールに請け負わす?みたいな解決案を持っていませんでした。
 docker-compose.ymldockerfile に全部書けるぐらいなら管理も楽だしそれがいいんですが、ちょっとそんなに単純でもないしな。かと言って本番の Terraform からキックされるクックブックとは違う開発環境のクックブックをブラッシュアップしていくことにどれほどの意味があるのか。 mitamae か確かに便利そうだなぁ、割と Ruby っぽいレシピ書くっぽいけどこれ自体を維持していけるかな。あでもなんか mruby 使ってるだけあって速いらしいけど、今のやつは Fabric と混ざってる??
 うーんうーん、と悩んでたんですが、結局、まずまずは目の前の環境が壊れている子を助けることが主眼なんだから、今手元でずっと温め続けてきた ansible-playbook をもうちょっとブラッシュアップして使ってもらったほうが早いのでは?と思い直し、とりあえずみんなの環境ができて、お隣に行ってガチャガチャ直す時間が減ってからベストプラクティスを定義しても遅くはないのではなかろうか?どうせコンテナ化したらまたバックグラウンドが変わるだろうし。と思って社内で公開しました。

 構成はベストプラクティスに寄せたつもりです。

$ tree -L 2
.
├── ansible.cfg
├── dev.yml
├── hosts
├── log
│   ├── debug.log
│   roles
│   ├── composer
│   ├── docker
│   ├── homebrew
│   ├── hosts
│   ├── migration
│   ├── node
│   ├── pip
│   ├── ruby
│   ├── sidekiq
│   ├── styleguide
│   ├── vagrant
│   ├── vagrant.puppet
│   └── workspace
└── workspace
    ├── repository A
    ├── repository B
    └── repository C

 抽象化した作業をロールで分解して、使いたいタスクを dev.yml のコメントを外して使ってもらって好きな playbook を使ってもらえるように意識したつもりで、例えば好きなロールのサーバの起動だけしたいとか、 homebrew でインストールしたアプリのアップデートだけしたいとか、ユースケースに併せて使えるように意識しました。今後、使ってもらっていって、固定化されたユースケースが浮き上がってきたらそれ用の playbook を作ったらいいんだし、再利用性を考慮したつもりなんですけど、こういう設計って答えがなくて無限に悩めますね。
(ちなみに、これが全てではなくて、ロール固有の処理とかビジネスロジックに依存するタスクは割愛しております。

 Ansible 自体は前職のゲーム作っていた時に本番のサーバプロビジョニングで使っていたので、記法や勘所はすぐに思い出せたのですが、個人のパソコンをプロビジョニングする時にとっても悩んだ点を紹介します。
サーバのプロビジョニングはベースとなる構成が同じなので、各個人の macOS でベースが違うプロビジョニングはかなりハードルが高いと思いました。例えば

  • 使っているシェルが zsh や fish 、 bash など異なる
  • ndenv 、 nodebrew など、言語のバージョン管理ツールが各個人で異なる
  • sudo する時のパスワード入力
  • python の実行パスが各個人で異なる
  • インストールパスに各個人の趣向が異なる
  • 既にインストール済みのモジュールのエラー回避
  • ロールの設計

 また、普通にハマったことはこんなもの

  • 変数にハイフン( - )を使ったら見つからなくなった
TASK [test : debug] ***************************************************************
Tuesday 11 December 2018  17:00:54 +0900 (0:00:01.294)       0:00:01.437 ******
ok: [localhost] => {
    "ps-test": "VARIABLE IS NOT DEFINED!"
}

 こんな感じで、 VARIABLE IS NOT DEFINED! になってあれ?って思ったんですけど、ハイフン使わなかったら出ました
( yml かなこれは

[local]
localhost ansible_python_interpreter=/usr/local/bin/python3

hosts に ansible_python_interpreter を指定して Python3 のインタプリタをフルパス指定したら動きました

 個人 mac なんで、 NOPASSWD とか指定してませんから、 sudo が必要なタスクで --ask-become-pass を指定しておかないと権限がなくてエラーになります。
パスワードの入力自体はいいんですけど、NOPASSWD を記述してる VM 内の操作にそぐわなかったので、まぁ、playbook を分けるか mac に NOPASSWD を記述します。
 でも、セキュリティ上、良くないので、 vault で解決できたらそれがいいんですが、ちょっとそこまで行きませんでした。。

  • rbenv はバージョンが切り替わるけど、 ndenv は切り替わらなかった

 これは、今でもよくわかっていないのですが、 shell モジュールの実行時、 .node_version での node バージョンの切り替えがうまくいきませんでした。
rbenv の場合、 .ruby_version に記載のバージョンに切り替わるので、 chdir を指定したらバージョンが切り替わったのですが、なぜか ndenv の場合、 .node_version のバージョンに切り替わりませんでした。
 lookup を使って .node_version を参照して node global xxx で切り替わったのでそうしましたが、もうちょっと上手いことやれる気がしてます。、

感想など

 やっぱり自動化は面白い!って思いました。
Ansible は、エラーが実行したコマンドのエラーそのまま出ますので、えー、これ使ってるんや!とか、なんでこのファイルのここをコメントアウトしてるんだ・・・とか発見が多かったです。
 多分、普通にアプリ実行環境(本番とかステージング環境)の構築に Ansible を使っているだけではぶつからないエラーに引っかかるので、ちょっと Ansible 力が上がった気がします。

 ということで、明日の GMOペパボ Advent Calendar 2018@litencatt さんです。

WebExtensions で Firefox Add-ons を公開してみました

 あっついですね。。
前の記事からだいぶサボってました。。
ブログ記事にするようなことがなかったわけではないのですが、なぜだか間が空いてしまいました。
資格試験の勉強をしていたのですが、だんだん飽きてきてしまったので、そういえばブログだな〜っていうテンションで書いてます。
公開してから結構経ってしまったのですが、初めて WebExtensions に触れて公開したので、メモ書きします。

 今年のはじめ、QAチームのエンジニアさんというポジションに配属したのですが、問い合わせ業務や改善作業や障害対応もいろいろ関連付けて仕事していたら、なんだか何でも屋さんになってしまっていて、結局僕はなんていう名前のポジションなんだろうって考えてまして、あえて言うなら最近流行りの SRE( Site Reliability Engineering )や CRE( Customer Reliability Engineer )かな〜って思ってたんですが、まぁそんな大それた感じでもないか〜って思ってました。


 で、いろいろな作業をやるうちの一つに、内部脆弱性検査を実施するお仕事もありまして、 OWASP ZAPBurpSuite を触っていたのですが、エンジニアが少ないQAチームメンバーでも効率的に脆弱性を検査できるツールで VAddy を使おうということになりました。
このツール、素晴らしく脆弱性を検査してくれます。アップデートが早いし、どんどん高機能になっているので、僕は今後もお世話になっていくことになるでしょう。 中の方が茅場町に来てくださったので、上役とお邪魔してきました。

vaddy.doorkeeper.jp

 ただ、自動テストを想定しているせいか、手動でのテストは割と手間がかかるかなぁという印象です。
自動テストは僕がやりたい領域のトップに入るのですが、残念ながら今、それに注力できる時間が少なく、そもそも、環境からじゃね?ってなっていまして、いろいろ遠回りするしかなくてなかなかテストスクリプトを書く段階まで至らず、でもその間にも脆弱性は検知したいので、どうしても手動によるテストや探索的テストに大きく頼らざるを得ません。
そういう時、以下のマニュアルに沿って手で進めるのですが、大量にクロールデータ(テストシナリオ)を作る作業で時間がかかってしまうなぁと感じました。

support.vaddy.net

 まぁ、とはいえ手順が多いとか、複雑とかではなく、やることは至って単純なのです。
上記はクロールデータを作成する手順でして、ブラウザのプロキシを設定して、 begin URL(開始) を叩いて、画面操作して、 commit URL(終了)を叩けば終わりです。
あとは僕が作ってくれたシナリオをスキャンするのに、ボタンポチポチするか、スクリプトでガーッとやるかなんですが、クロールデータを作成するのは、僕ではなかったりしました。テスト担当者や、 CS のメンバーにお願いしていたため、どうしてもどれのあとにこれをやって、でどうなってっていう説明が難しくてですね。
説明が難しくても、厚めにフォローしてたら解決できる範囲だったのでいいのですが、 begin URL を叩いたら、変なエラーがでたとか、うまく操作してるつもりだったんだけど、クロールデータができなかったとかありまして、そのときにでたエラーを1つ1つ解消するのに苦労しました。


 なんでだろうな〜、って思っていたのですが、間違って begin URL を2回叩いていたとか、クロールデータ作成中に他のメンバーが begin URL を叩いてしまって、中断されてしまったとかでした。
複数メンバーで一気にクロールデータ作成を行っていたために起きていた問題と、そもそも操作ミスが原因で起きていた問題に切り分けられました。
前者は検証環境を増やすことで解消できたのですが、操作ミスは依然残ってしまっていて、どうしたらスムーズに進行してもらえるかな〜と考えていまして、その結果、 Add-ons を作ることにしました。
要するに、開始 URL と終了 URL を1回ずつ叩けばいいので、ブラウザの右端にアイコン作ってあげて、操作ミスを軽減したらいいのではないかと。
で、開始 URL を叩いたタイミングでテスト対象の URL を開いてあげたら更にいい感じになるのではと思ったので、それぐらいなら速攻できそうだなと思われました。

Easy VAddy Proxy Crawling – Firefox 向けアドオン

 はじめ、 Chrome を想定して作っていたのですが、割と出来上がってきたタイミングで、あ、Chromeのプロキシってシステムのプロキシ利用するんだったってことに気づいて、あぁあぁぁぁ。。ってなりました。
確かにマニュアルにも近しいこと書いてるなぁ。なんかそういうのなかったっけって調べたんですが、 sudoChrome 叩いて、引数に Proxy を渡したら、どうやらいい感じに動いたんですが、いや、流石にちょっとPCを管理している感じの人に怒られそうだな、じゃぁ、そのままシステムのプロキシ使ってもいいんじゃない?って思ったんですが、あれ? Slack... ってなったんで、やっぱ Firefox しかねぇって方向転換しました。
最近、 Firefox も WebExtensions になったみたいだし、書いたコードも流用できるでしょうと思ってたのですが、案外 Firefox の WebExtensions の作例が少なかったので、 MDN 読んでたら結構なボリュームだったんで、読むのに時間かけてしまいました。。。 ^^;

github.com

 作りながら、うーん、このタイミングで Notification を出したいな〜とか、このタイミングのときは Icon を変えたくないなぁとか、 Option ページは bootstrap とか使ってそれなりのデザインにしたいなぁとか欲求がでてきまして、速攻とか言ってましたけど、 Add-ons を作ること自体が楽しくなってきてしまって2、3日かけてしまいました。。


 まだ、ちょっと使いづらいし、例外ハンドリングが甘いのですが、僕たちがクロールデータを手動で作成するワークフローに合うように作れたと思います。
チームメンバーに使ってもらって、フィードバックを得たいですが、初めてブラウザのアドオン作ったので、いい勉強になりました!