Blog

ブログ

IBM Champion for Cloud 2020に認定されました!

昨年よりジョーレンの一員となりました榎本です。

弊社自体はIBMとの直接の関わりはないのですが、個人的な活動として続けてきたIBM Cloudに関連したコミュニティの活動が認められ、2019年に引き続き、今年もIBM Championとして認定いただきました!

※IBM Championとは、、、
IBMが公式に認定した外部エバンジェリスト(社員ではない)です。認定にはIBM製品に関する専門知識や、コミュニティやブログなどを通じて外部へ発信するインフルエンス力が必要とされる上、1年単位での更新(審査あり)が必要なため、割とタフ(笑)な認定になります。(詳細はこちら(英文))
ただ、他の非常に優秀なエンジニアの方々と会社という垣根を越えて繋がることができる上、様々な場所での登壇や勉強の機会が頂けるので、非常に魅力的な認定となっています!

2019年の私自身の活動として振り返ると、、、

  • 各種コミュニティでの登壇(写真はDISTさんでお話させて頂いた時のもの)

など、色々とありました!

他にもQiitaへの投稿を通じた情報発信など、色々と自由にやらせて頂いております!(2019は会社でQiitaアドベントカレンダーにも挑戦しました)

会社には技術に関連した活動に対するご理解や、サポートを頂き本当に感謝しています。これからも松戸発エンジニアの幸せを目指すジョーレン、そして松戸をテクノロジーで盛り上げていける様に頑張っていこうと思います。

開発が好きな人、新しい技術に触れたい人、一緒にこの素敵な会社で働きませんか?
こちらもお待ちしていまーす!

人の意見を聞くことの大切さ

どうも、モリタです。
こんにちは。

意味をちゃんと調べることなく、生きていく中でなんとなく覚え、なんとなく使っている言葉は結構多いのではないでしょうか。

今日はそんなお話です。

先日、MySQLでテキストが保存されたカラムに対してLike検索することを「全文検索」と呼んでいたら、複数の人から「それは違う」と指摘されて、エンジニア生活10年間、ずっと間違えて使っていたことにショックを受けました。

私はいままで、全文検索の手段としてLike検索を使うのか、全文検索エンジンを使うのか、はたまた転置インデックスを自作するのか、と思っていたのですが、どうやらRDBMSでは転置インデックスを使った検索のことを「全文検索」と言うらしいのです。

(ここで納得してしまった人は最後まで読まないと危険です)

これまで、「全文検索」についてしっかり調べたわけでもなく、エンジニアになって会話の文脈からなんとなく意味を把握し、特に疑問を持たないまま使っていたので、「あー、そーだったのかー」とその時は納得しました。

だがしかし、「全文検索」という日本語からしてLike検索が全文検索ではない、というのがどうもしっくりこなくてモヤモヤが膨らんでいきました。

なのでちゃんと調べてみることにしました。こういうときはウィキペディアが頼りになります。

 

全文検索(ぜんぶんけんさく、英: Full text search)とは、コンピュータにおいて、複数の文書(ファイル)から特定の文字列を検索すること。「ファイル名検索」や「単一ファイル内の文字列検索」と異なり、「複数文書にまたがって、文書に含まれる全文を対象とした検索」という意味で使用される。

 

ん?ちょっとまてよ?

私の認識は間違ってないんじゃないか?

ウィキペディアをもう少し見てみます。

 

全文検索技術
grep型
・・・中略・・・
索引(インデックス)型
・・・中略・・・

 

Likeはgrep型だろうなあ。

 

・・・

 

確信しました。

私の認識は間違っていなかった!!

結局、Likeだろうがインデックス使おうが、全文に対して行う検索は全文検索なんですね!!

ちゃんと調べて良かったー。

 

調べていく中で、「全文検索=インデックス型の全文検索」として扱っている記事が沢山ありました。

言葉は、勘違いや間違いが元で変化していくものだと思うので、多くの人の認識を正とすれば良いと思いますし、日常生活におけるコミュニケーションでは、話が噛み合っていなくてもそれほど大問題になることはないでしょう。(男女関係は別として)

しかしそれがシステム構築となると話は別です。(ビジネスなら何でもそうだと思いますが)

認識の齟齬が重大なバグを生み出すことになるかもしれません。

プロジェクトの全員が同じ認識でいるかどうかを把握するのは難しいと思います。

ただ、少しでもおかしいと思ったら迷わず確認するのが大事だなーと改めて感じました。

そして伝える時は「全文検索」と言う漠然とした言い方ではなく、「likeを使った全文検索」などと具体的に言うように心がけようとも思いました。

 

若い時は人の意見はあまり聞き入れず、自分が正しいと思ったことは貫き通していましたが、年を重ねるごとに、なるべく人の意見を聞くように心がけていました。

それが災いした今回の事件でした。

これからは人の意見を聞かないようにしたいと思います!!!(嘘)

 

AWSでWordPressの管理画面にログインできない

AWSでWordPressを構築する場合に行ったHTTPSのトラブルシュート

初めまして。Joolenで修行中の修行僧 おおたに です。修行のために頭を丸めました。

突然ですが、AWSでWordPressを構築する場合に行ったHTTPSのトラブルシュートについて、全世界に向けて絶賛公開いたします!!
(もったいぶらないで、回答からいくスタイルです)

[現象]

・Amazon EC2にWordPressをインストールすると管理画面でログインできない。
または、管理画面自体が表示されない。

[環境]

・サーバー:Amazon EC2

・外部からはELB(ロードバランサー)へHTTPSでアクセス

・ELBからEC2へはHTTPでアクセス

[解決策]

次の2点(1.と2.)を実施します。
セキュリティに関する設定になりますので、ご使用は自己責任でよろしくお願いいたしますm(_ _)m

1. WordPressの URL設定を変更する

<①ELBのHTTPS制限を一時的に無効にしても構わない場合>

HTTPS制限を解除すれば、WordPress管理画面へHTTPアクセスできます。管理画面へログインし、[設定]で次の2点を変更します(「WordPressのURL」は各自の環境に合わせて変更してください)

  • WordPress アドレス(URL):https://WordPressのURL
  • サイトアドレス(URL):https://WordPressのURL

変更が終わったら、解除していたHTTPS制限を元に戻すのをお忘れなく

<②ELBのHTTPS制限を無効にできない場合>

HTTPS制限があると、WordPress管理画面にログインできないので、DBを直接操作して、次の2文を実行します(「DB名」と「WordPressのURL」は各自の環境に合わせて変更してください)

  • 「UPDATE DB名.wp_options set option_value=’https://WordPressのURL’ where option_name=’siteurl’;」
  • 「UPDATE DB名.wp_options set option_value=’https://WordPressのURL’ where option_name=’home’;」

2. HTTPアクセスをHTTPSアクセスと認識させる

 WordPressのPHPファイルを編集します。

[wordpressインストールフォルダ/wp-config.php]の下の方に書いてある[require_once]文より上に、
次のif文を追記します。

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
          $_SERVER['HTTPS'] = 'on';

これで、解決できます。お疲れサマでした。南無阿弥陀仏♪

[参考ページ]

https://codex.wordpress.org/Function_Reference/is_ssl

[原因の解説]

ELBでHTTPS制限している場合は、外部からのアクセスはHTTPSに制限されますが、内部アクセスはHTTPに変わります。このため、WordPressへの内部アクセスはHTTPになります(ここがポイントです!)

WordPressがHTTP設定の場合、外部からのアクセスはHTTPSなのに、WordPressが生成するアドレスはHTTPになるため、ブラウザがセキュリティエラーを出して、[管理画面にログインできない]状態になります。

また、WordPressがHTTPS設定の場合、HTTPアクセスが来るとHTTPSアクセスへ変更してリダイレクトする仕様のため、リダイレクト無限ループが発生して、[管理画面自体が表示されない]状態になります。

■リダイレクト無限ループ

①WordPressがHTTP(内部のアクセス)をHTTPSへ変更してリダイレクト

②リダイレクトされたHTTPSを、ELBがWordPressへHTTPとして渡す(->①へ戻る)

WordPressがリダイレクトするコードはwp-login.phpファイルの先頭あたりに書いてあるので、見てみると面白いと思います。

それではまた。次回の投稿にご期待ください。南無阿弥陀仏♪

ECCUBE3でセッションが切れる?

eccube.CRITICAL: RuntimeException: Failed to start the session (uncaught exception) at /var/www/eccube/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php line 149 {“exception”:”[object] (RuntimeException(code: 0): Failed to start the session at /var/www/eccube/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php:149)”} []

システムエラー画面になってシステムログにはこんなエラーがでていた。

apacheエラーログは以下の通り。

PHP Warning:  session_start(): Failed to decode session object. Session has been destroyed in /var/www/eccube/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php on line 148

セッションオブジェクトをデコードできないってことなので、とりあえずセッションのデータを見てみることに。

結論から言うと、セッションデータがでかすぎて欠落した値がDBに保存されていたことが原因。

eccube3.0.8だったのでセッションはデフォルトでDBに保存される。(3.0.10ではファイルに変更されている模様)

解決策としては

  1. dtb_session.sess_dataの型をblobからmediumblobに変更
  2. 保存先をファイルに変更

が考えられるので今回は1で対応。

因に、my.cnfに「sql_mode=STRICT_TRANS_TABLES」を設定するとblobのままでも欠落した値が挿入されることは無く、

(恐らく値が更新されないので)上記エラーは起きなかった。

そもそも、セッションにCustomerエンティティとそこから紐づくエンティティが保存されるらしく、

それを知らずにリレーションしまくると大変なことになりそう。

(今回はカスタマイズでいろいろリレーションしていた)

紐づくエンティティーでも保存される物とされない物があり良くわからんのですが・・・

引き続き調査は続く。

EC2のmysqlが落ちた

ブログを書こうと思ってアクセスしたら「データベース接続確立エラー」でサイトを開けず。

mysqlが落ちてたので起動したがまたすぐに落ちてしまった。

EC2のスワップ領域を設定すると良い、という記事を見つけたのでそれを参考に設定してみるものの、またすぐに落ちる。

アクセスログを見たところ、xmlrpc.phpへの大量アクセスがあることが判明。

下記サイトを参考に不正なアクセスを拒否してとりあえず解決。

サーバーが高負荷の原因はWordPressのxmlrpc.phpを狙った攻撃だった

何かしら監視ツールをいれやう。

 

vagrantの同期ディレクトリでパーミッションを変えられない

あ、しまった!

ブログ用意しておいてまったく書いてない。

ということでちょっと技術メモ的なことを書いてみる。

 

Vagrantファイルで以下の設定をすれば変えられる。typeをnfsにする。

config.vm.synced_folder "src/", "/var/www", type:"nfs"

追記
nfsだとパーミッションは自由に変えられるものの、所有者とオーナーがホストOSのものになってしまう。
なのでやっぱり下記設定のほうが良さそう。

config.vm.synced_folder "src/", "/var/www", owner:"vagrant", group:"vagrant", mount_options:["dmode=775","fmode=775"]

こんな感じにして、apacheもvagrantユーザーで起動することにしました。