PHPerKaigi2022に参加しました

PHPerKaigiでの写真

PHPerKaigiとは

PHPerによるPHPerのためのお祭り、「ペチパーカイギ」今年も開催！

とあり、PHPer好きのためのイベントです。今年2022年は前夜祭も含め全3日での構成となっておりなかなかのボリュームがありました。

phperkaigi.jp

また、私の所属している株式会社ウィルゲートはゴールドスポンサーとしてスポンサーもしていました。

tech.willgate.co.jp

おすすめセッション

全体を通してどの発表もクォリティ高く全部オススメなのですが、やはりずば抜けて参考になる、すごいなと感じたのは t_wada さんの「予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント」がとても勉強になりました。 毎年PHP Conferenceなどでセッションは聞いていますが、今回PHP8.1の内容にアップデートした上で新しい内容をたくさん盛り込まれててとても参考になりました。

fortee.jp

もう一つは ヒエイカザト さんの「エラー監視とテスト体制への改善作戦」がとても良かったです。 エラー監視について泥臭く向き合いつつ、細かい工夫が参考になりました。最終的にはやはり組織の問題と一緒に解決しいこうという考え方も今の環境とも重なって見えとても参考になりました。

fortee.jp

その他

PHPerKaigiではPHPerチャレンジという#から始まる特定の文字列を探すというCTFのようなイベントがあったのですが、私は残念ながら6位という成績でした。

PHPerチャレンジの結果発表

また、会全体を通しての動向やログはツイッターでつぶやいてるので気になった方は覗いてみてください。

twitter.com

参加しての感想

今回、オフラインのこういった大規模なイベントへの参加は久しぶりでした。 久しぶりにオフラインで参加できたので、ギークなトークや現地での新たなつながりなどを得られてとても楽しかったです。 また、いろんな発表を聞いてとてもモチベーションが上がったので今度は自分もなにかセッションに応募して話してみたいなと思いました！

改めて、運営スタッフさん、スポンサーの皆さんに感謝です。ありがとうございました。

正しい鍵(キーペア)なのにSSHできない！？ 〜 原因は鍵のOpenSSH新旧の形式の違いだった

先日サーバ上でキーペアを使用したssh接続で作業しようとしていたところ、OpenSSHで作った鍵の形式が違うことにより、ハマってしまったポイントが有ったので記事にまとめようと思います。 ※この記事ではPuTTy形式とOpenSSH形式の違いによる話は取り扱いません。

起きた事象

• OpenSSH形式の公開鍵、秘密鍵のキーペアが正しい状態である
• 公開鍵がサーバにauthoried_keysとして登録されていて、authorized_keysの場所権限ともに正しい状態
• サーバにsshでログインしようとすると認証ができない（厳密にはWordPressのプラグインインストールをsshでできない）
  • 画面上のエラーメッセージ: 「{WPのユーザ}の公開鍵と秘密鍵が正しくありません」
  • /var/log/secure.log のエラーメッセージには怪しいものは特に出ておらずクライアント側で接続を切ったとしか出ていない

sshd[6058]: Received disconnect from 127.0.0.1 port 47070:11: PECL/ssh2 (http://pecl.php.net/packages/ssh2) [preauth]
sshd[6058]: Disconnected from 127.0.0.1 port 47070 [preauth]

• 他のサーバで同じキーペアを用いるとsshログインできることを確認
• 同じサーバで新しく生成し直したキーペアではsshログインできることを確認

結論

• OpenSSH7.8以降で生成した鍵は後方互換がなくクライアントによってはエラーが発生する
  • パスフレーズが有る際のフォーマットが変わっているため対応していないクライアントではうまくパースできず接続できない状態になっている模様
• OpenSSH7.8以前で生成した秘密鍵の特徴
  • -----BEGIN RSA PRIVATE KEY----- で始まる
  • パスフレーズで保護してると暗号化についての情報が表示される
• OpenSSH7.8以降で生成した秘密鍵の特徴
  • -----BEGIN OPENSSH PRIVATE KEY----- で始まる
  • パスフレーズで保護しても暗号化についての情報が表示されなくなった

解決までの経緯

問題発見

起きてた事象としては、WordPressのプラグインインストールをsshで行おうとしていたときに発生しました。 サーバ上に登録していた鍵を指定してsshメソッドを使いプラグインをインストールしようとするも公開鍵と秘密鍵が正しくありませんと言われインストールできない。

仮説→検証

そこで、そもそも鍵が誤っているのかを確認するため、サーバ上でlocalhostにsshできるかを試してみるが、これは成功する。 つまりキーペア自体は正しく設定されておりssh認証できる状態であることがわかる。

ここでこの鍵は他のサーバでも使っているものの使いまわし（本当はあまり良くないが）であることを思い出し、新たに別の鍵を生成してそれで同様にWordpPressのプラグインインストールができるかを試してみた。 すると、この新しい鍵ではスムーズにプラグインのインストールができた。

根本原因調査

ということで鍵の何らかの違いによってうまくsshできない状態になっていると仮定して鍵の違いを調査した。

もともとあった秘密鍵は鍵の冒頭が -----BEGIN OPENSSH PRIVATE KEY----- で始まっており、新しく作った秘密鍵は -----BEGIN RSA PRIVATE KEY----- で始まっていた。

ということで２つの鍵の違いを調べたところクラスメソッドさんの記事が出てきて、OpenSSH7.8で鍵のフォーマットが変わっていることを知りました。

dev.classmethod.jp

どうやらパスフレーズがあるときのフォーマットが変わっており、その変更のためにsshクライアント側でうまく考慮できていないとssh接続する前にエラーとなってしまい接続できないようになっているようでした。*1

解決

本来パスフレーズがあるときに暗号方式などが出ていたものを消すようにしたのはセキュリティ上の問題を少しでも低減する目的かと思いますが、今回はそもそもパスフレーズは設定していなかったので、もともとの形式に変換する方法を選択しました。 すでにある鍵ファイルを変換するために下記コマンドを使用しました。

ssh-keygen -p -m PEM -f id_rsa

これで変換した鍵ファイルを用いて再度WordPressのプラグインを試したところ無事成功しました。

めでたしめでたし。

*1:詳細は追っていないため、最新のWordPressなどでは対応されている可能性はある。

ISUCONに向けてpprof導入手順まとめた

pprofとは

Go用プロファイリングツール
実行時間を計測して処理の重い箇所を調べることができるとても便利なツール

導入手順

ライブラリの取得

$ go get -u runtime/pprof
$ go get -u net/http/pprof

※go modを利用していれば不要だった気がする

コードの修正

インポート部分に下記追加

import (
        ...
        ...
+   _ "net/http/pprof"
)

main関数に以下を追加

func main() {
+   runtime.SetBlockProfileRate(1)
+   runtime.SetMutexProfileFraction(1)
+   go func() {
+       log.Println(http.ListenAndServe("0.0.0.0:6060", nil))
+   }()
        ...
        ...
}

ここまでできたらほぼ完了。

依存パッケージのインストール

WebUIでグラフを見れるようにするために下記をインストール

$ apt install graphviz
or
$ yum install graphviz

ポート開放

WebUIを外から見れる用にするために 1080 ポートを開ける

分析データ収集

アプリケーションが動いてる状態（ISUCONならベンチマーク中）で以下のコマンドを実行しデータを収集＆WebUIを起動する

$ go tool pprof -http=0.0.0.0:1080 {アプリケーションのディレクトリ}  http://localhost:6060/debug/pprof/profile

プロファイルできてから再度見る場合

$ go tool pprof -http=0.0.0.0:1080 {アプリケーションのディレクトリ} {収集したファイルパス}

実行が終了したら以下のURLで見ることができる。

http://xxx.xxx.xxx.xxx:1080/

※ポートの説明

• 1080:pprofを結果を外部から見るためのポート
• 6060:pprof自体がアクセスするためのポート(外部からアクセスしないので、開けなくてよい)

参考サイト

medium.com

docs.google.com

HHKB厨が corne cherry を自作してみた

1年前くらいに自作したcorneキーボードの記事の下書きが眠ってたので消化です。

作って一時期使ってたのですが、HHKB type-s Hybrid が出て衝動買いしてからそっちを使ってしまってますｗ(これで家にHHKBが3代目ですよ、、) corneも無線対応してまた使いたいですね。

背景

今まで HHKB BTモデル無刻印 を使っていたが友達に左右分離がいいぞと言われたので、買ってみた。

自分のキーボードに求めるもの

ということで自分がほしいと思うキーボードの条件を洗い出してみた。

• US配列であること（記号が入力しやすい）
• コンパクトであること
• 静かであること
• 配線が少ないこと（できれば無線であること）
• ２〜３万円で揃うこと

上記に加えて自作のきっかけでもあるので左右分離キーボードを試してみたいと思っていました。

購入したもの

自作キーボードキット

『Corne Cherry』

軸

『cherry 茶軸』（42個）

キーキャップ

適当な黒い無刻印のやつ（40個）

以下自作工程写真

※写真はろうと思ったら画質良すぎて変換めんどくさくなったのでgoogleフォトでw

photos.app.goo.gl

firmware の設定

自作しただけではまだ使えません。キー配置の設定をマイクロチップに設定する必要があります。 今回は QMK Firmware を使って設定しました。

私の設定は下記レポジトリに入ってます。参考にしてみてください。 github.com

キー配置以外にも設定できるのですが、最初なのであまりいじってません。

キー配置は全部で4レイヤ設定しています。 設定次第ではもっとレイヤを増やすこともできますが、レイヤを増やしすぎると切り替えに使うキーが増えるのでその分corneだとそもそもキー数が少ないので配置がつらくなりますｗ

1. デフォルトレイヤ=アルファベット
2. RAISEレイヤ=Fnキー+移動系キー
3. LOWERレイヤ=数字キー+記号キー
4. SWITCH(RAISE+LOWER同時押し)レイヤ=予備(なにか欲しくなったら追加予定)

完成

マイクラサーバ運用でやっている5tips

お久しぶりです。すっかり寒い季節になってしまいましたね。

最近はマイクラにハマっており、マイクラサーバを運用していたりします。 せっかくなのでその際の取り組みとして工夫してよかったことをまとめて行きたいと思います！ マイクラサーバの運用記事や構築記事は色々あると思いますが、 サーバ運用者視点で取り組みや楽しさをまとめてる記事はないかなと思ったので、思い切って記事にしてみました。

この記事は ウィルゲート Advent Calendar 2019 - Qiita の19日目の記事です。 いよいよ残り一週間切りましたね！

昨日は @okashoi さんの PHP + Swoole で論理回路シミュレータを作ってみた でした。

この記事で書かないこと

「マイクラサーバの構築方法、運用方法について」はこの記事では言及しません。当初はこれを書こうかなと思っていたのですが、結構長くなってしまう上に真新しい情報がないので今回は取り上げないこととします。別途機会があれば別記事にまとめるかもしれません。

あくまでも今回は、 技術 以外のマイクラサーバ運用時のtipsや楽しみ方、こういうことやったら良かったよ、という内容に的を絞って書いていきます。

前提

まず先にマイクラサーバを運用している前提について書いていきたいと思います。

ユーザ

サーバでの想定利用ユーザを先に書いておきたいと思います。

まず本記事でのマイクラサーバはプライベートでの運用なので、全ユーザはサーバ運用をしている私の知人に限られます。 また、ユーザのほとんどは私の所属している会社の友人が主で、残りの数人も同じエンジニアコミュニティに所属している人ばかりです。 なので、いきなり誰も知らないユーザが入ってくるというようなことはありません。

サーバ運用

サーバの準備については私個人が好きでやっていることなので、私個人で借りているVPS上で私一人で運用されています。 もともと私個人が趣味開発用に借りてた1000円程度のVPSに同居しており、現在は少しスケールアップして2000円程度になっています。 サーバの費用についてはメンバーからのカンパ方式と私の善意（私がやりたいからやる）で運用しています。

工夫してよかったこと

1. Discord の導入

みんな知人みたいなものなので Discord を導入して、Discord 内でコミュニケーションを取れるようにしました。 これによりテキストコミュニケーションや、ボイスチャットでのコミュニケーションが取れるようになりゲーム中でもわいわい遊べるようになりました。 （オンラインゲームなので当たり前ではありますが）遠方にいる人とも一緒に遊べるのはとても良いですね。 ※実際、会社に内定者インターンとして来ていた子と一緒に遠方からでもコミュニケーション取りながら遊べたりしてとても良いですね。 Discord を用意することでゲームの待ち合わせをしたり、あ、今あの人やってるから自分もやろう！などができるのでとても良かったと思います。

2. Trelloの導入

みんな大好きかんばんです。 やりたいことややったことを可視化することで参加者のモチベーションにもつながると思って導入しています。 みんなのアイディアなんかもここに書いていくことで一緒にやる仲間を募集しやすくなります。 みんなで大きなチケットを消化したときはお祝いなんかもして楽しいですね。

3. 参加したくなるような企画

ただ目的なくマイクラをやっていても楽しいは楽しいのですが、色々目標を持ってやるともっと楽しくなると思っています。 例えば、私達のサーバでは某 Youtuber さんの企画をまるまる真似て『マイクラ人狼』なるものをやったり『マイクラバトルロワイヤル』をやったりしてました。 他にも『特定モンスターを一番多く倒した人が優勝選手権』みたいなものも企画しています。 単純にマイクラをやるでも楽しいので良いのですが、こういう企画があると一層楽しくなるのでおすすめです。 特にマイクラ人狼は普通の人狼とバトルロワイアル要素が混ざっており、普通の人狼とは一味違うのでとても楽しいです。 ※人数集めるハードルだけが少し難点かも。

4. Kyashの導入

サーバ費用はカンパ式でと冒頭でも書きましたが、毎月サーバ費用に対して参加者からお気持ちでサーバ費用を頂いています。 サーバ費用の支払に関しては極力手軽に支払いできるように Kyash という送金サービスを利用しています。 QRコードで送金先を指定して簡単に送金できるので、とても楽にカンパできると思います。

5. 情報の一元管理

最後が情報の一元管理です。情報が散乱しているプロジェクトはエンジニアの皆さんも嫌いだと思います。 マイクラでも同じく情報の一元管理は大事だなと私は考えています。 公開されているマイクラサーバの場合情報はwikiなどにまとめてることが多いかと思います。 ですが、今回の場合クローズドな完全身内だけのマイクラサーバのためwikiを用意して誰でも見れるように整える必要はないと考えました。 なので、すべての情報を Google スプレッドシートで管理するように考えました。 あらゆる情報をできるだけこのスプレッドシート上に集め、新しい参加者が来たときもここを教えれば済むようにまとめています。

まとめ

マイクラプライベートサーバで工夫してきた点をまとめてみました。 趣味なので一番は楽しくやれることですが、仕事を通して学んだこともうまく遊びにも活かせていて個人的にはとても良いなと思っています。 遊びながら楽しく発見して、それをまた仕事にも活かして、という良い循環ができてくると仕事も生活も豊かになっていくなと感じています。 ということで、これからもマイクラを通して色々学んでいきたいと思います！

明日のアドベントカレンダーは wg_ishikawa さんの「グロースハックについて内定者たちとしたディスカッション」です。お楽しみに！

【惨敗しました】ISUCON9予選に向けて準備してきたこととやったこと

前回の更新が徳丸試験受験だったのでちょうど1ヶ月ちょっと空いてしまいましたね。

この1ヶ月の間、割とこのISUCON9予選に向けて準備してきたので、そのことについて書きたいと思います。 どんな問題だったかや、何をしたら早くなるなどの解説や、運営方針で色々あったことについては、この記事では触れません。

あくまで忘備録的に自分たちが何を準備してきて、当日何が出来たかをまとめておきます。 惨敗とはいえ、用意はかなりしてきたつもりなのでそれなりにためになる情報もあるんじゃないかなと思ってます。

ISUCONってなに？

去年の参加記に説明あるので読んでみてください！

blog.zoe.tools

準備してきたこと

上記の通り去年のISUCON8で点数的には割と惜しいところまで行ったこともあり、今年こそは予選通過を本気で目指していました。 予選通過に向けて去年の振り返りをもとに練習を重ねました。

役割を決めての練習をする

今回チームメンバーは アッキー (@akki_megane) | Twitter と 02 (@cocoeyes02) | Twitter と参加しました。 それぞれ早い段階で役割を決めたのでその役割で練習をしました。 役割はざっくりこんな感じです。

• 私： インフラ主担当、その他細かい部分など
• アッキー (@akki_megane) | Twitter： 分析主担当、アプリ改修なども
• 02 (@cocoeyes02) | Twitter： アプリ改修主担当

役割を決めての練習は全部で6日ほど練習しました。 練習には過去問のISUCON5やISUCON8の予選問題を再現して練習してきました。

デプロイスクリプト用意しておく

これも前回の反省からの行動です。 事前に、用意できるものはできるだけ用意してきました。 用意したスクリプトなどはすべてgithub上で管理していました。 また当日のタイムライン管理もwikiで予めやることを書き出し、迷うことなく作業できるようにしておきました。

github.com

特に初期、サーバをもらってからやることはだいたい決まってるので、まとめています。

pprofを見れるように

ここは前回に比べて割とうまくできるようになったと思います。 web pprofを アッキー (@akki_megane) | Twitter が色々調べてくれたおかげでとても見やすく、分析に置いてもとても役立ちました。

（写真は↑しかとってなかったのでこれだけ、、）

2チーム参戦

これについては自チームの話とは関係ないですが、身内のコミュニティから今回ついに3チーム参戦しました。 ずっとISUCON面白いぞ、といいながら練習会をやってきた甲斐がありました。どのチームもコミュニティ名の「oysters」に少しかけた名前で出場してくれてました

当日やったこと

書こうと思ったけど疲れてきたので特に工夫したことだけ書いて、あとは当日のgithubレポジトリを貼っておきます。

工夫したこと

ポモドーロ

25分で作業を行い、5分でやったことの報告と次やることの報告。2ポモドーロ進捗なかったらみんなで解決に当たる。という方針でやってました。

環境構築について

今回はalibaba cloudのコンソールから各参加チーム代表者が運営に共有されたイメージをもとにインスタンスを立てベンチを回すと言う形式でした。 なので、まず最初1台を立て準備を整えベンチを回し、初期バックアップなどのスクリプトを実行した後、そのインスタンスをもとにカスタムイメージを作成し、作成したカスタムイメージをもとに 4台 インスタンスを立てました。 2台は最初に立てたものと合わせて競技用のインスタンス、残り2台はチームメンバーの開発環境として配布しました。

施策の検証方法について

これは試行錯誤しながら思いついた方法ですが、開発環境として本番同等のインスタンスを渡すことが出来たので、アプリ側で改修したものが正しく改修出来ているかを確認する方法として、本物のポータルのベンチを使う、ということができることに途中で気づきました。具体的にはポータルでベンチを回す際にはグローバルIPアドレスとインターナルIPアドレスを入れてサーバを登録後、ベンチを回すのですが、どうせ本番提出時もベンチに使うIPはproxyしているwebサーバだけなので残り２つをチームメンバー二人のサーバを登録することで施策をそれぞれ改修してベンチを回してデバッグするということが出来ました。 おかげで、本番に上げたらベンチ落ちてまた改修、みたいなことを減らすことが出来ました。

当日レポジトリ

github.com

基本的に当日はこのissueをもとに行動していきましたのでだいたいやったこと、やろうとしたことはこれを追えばわかるはず。 （このレポジトリはこのブログを書くにあたって公開にしており、ISUCON開催中はプライベートリポジトリでやっていました。）

当日の様子 (ちなみにこのとき僕は熱を出していて、しんどかったのでノーリアクションですが、めっちゃ楽しかったのでISUCON終わる頃には熱が治ってました）

isucon、 始まります！#isucon pic.twitter.com/PT6nOj5nQW

— 02 (@cocoeyes02) September 8, 2019

振り返り

チームで振り返りをしたら追記します！

最後に

運営さんいつもありがとうございます。 ISUCONもかなり規模が大きくなってきたので今まで通り出来ない部分や、期待も大きくなり大変な部分も多くあるかと思いますが、 いつも問題作成、運営してくださり、とても楽しく参加させていただいております！ 特に今回は問題のクォリティも高くとても準備に力が入っておりとても満足させていただきました！

徳丸基礎試験を受けてきました

こんにちは。 暑い日が続いてますね。 最近は 徳丸基礎試験（試験名：ウェブ・セキュリティ基礎試験） に向けて勉強してきていたので、受けてみての感想などをざっくりまとめたいと思います。

徳丸基礎試験（試験名：ウェブ・セキュリティ基礎試験）とは

これです。

peatix.com

セキュリティ界隈で有名な徳丸さん監修のウェブセキュリティ試験です。 今回はその基礎試験のベータ試験（第一回目）でした。

公開して1時間くらいで枠が埋まってしまったらしいです。

早くも完売となりました。早々のお申込みありがとうございました https://t.co/82lgOsbv6y

— 徳丸 浩 (@ockeghem) July 10, 2019

自分が申し込んだときは増枠前の最後の1枠だったので滑り込みセーフでした。

受けてみようと思ったきっかけ

徳丸試験のベータ試験が公開される前から徳丸試験というものを作っているという話は聞いており、 セキュリティは自身も気になっていた領域ではありました。 受験フォームが公開された日に知り合いが受けよう！と言ってシェアしていたので一緒に受けてみよう、という軽い気持ちで受けることにしました。 それに第一号合格者って響きが少しかっこいいなぁと思ったのもあります。

試験までの勉強方法について

試験までは約1ヶ月弱くらいでした。試験までの間の土日などを使い主に下記の本を読みながら勉強をしていました。

• 徳丸浩のWebセキュリティ教室

出題範囲の本の内容を軽くまとめて事例ベースで紹介しているような感じの本でした。 期間もあまりなかったので基本的にはこの本を読んで出そうなところを勉強するスタイルですすめていました。

• 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践

受験ページに書いてありますがこちらが出題範囲の本です。この本はウェブセキュリティについてすごくまとまっておりとてもいい本で、ウェブエンジニアなら一冊は手元に置いておきたい本ではあるのですが、一ヶ月で読むには少し量が多かったですｗなので基本的にはサラッと読み、自分の知識が足りない部分について補てんするように読んで行きました。

受けてみての感想

正直自分はあまりこういう試験を受けた経験がないことと、この試験は今回が第一回目だったこともあり、どれくらい勉強をすればいいか、合格ラインがどれくらいか、というものがわからず、割と闇雲に勉強していました。 まぁセキュリティの勉強なので勉強して無駄になるということは特にないので、問題はないのですが資格試験を受けるための勉強方法としてはコスパ悪い勉強方法だったな、と少し振り返りました。 また、試験の内容については口外できないので省きますが、勉強してみた結果、自分のセキュリティ知識でどこらへんが弱いのか認識できたことはとても良かったです。 意外と知らない攻撃手法や脆弱性があったり、知ってるつもりでもいざ説明しようとするとできないところとかがありました。

試験勉強をするということ自体久しぶりで少し懐かしい気持ちになったりもしました。普段は自分の今使いたい技術を思いつきで調べて学ぶということが多いので たまには、今回のように目標を決めて時間をとって体系的に技術を学んでみるのも面白いですね。

試験結果は3ヶ月くらいで出るらしいです。 結果が出るのが楽しみです。ドキドキ。結果出たらまたブログに書こうと思います。