狛ログ

2017年5月27日土曜日

AWS EC2 で Amazon Linux を使用する場合に最初にやること


初稿:2017年5月27日
修正:2018年9月16日 Amazon Linux 2 から、cloud-initが無くなった事による修正。

オフィス狛 技術部です。

AWSでEC2インスタンスを立ち上げる度に、設定すべき事を忘れてしまうので、
備忘録の為にブログに残しておこうと思います。

「aws ec2 やる事」でググると、もっと細くやる事を記載している方も居るので、
しっかりやりたい方は、それらを参考にして下さい。

ここに記載するのは、本当に最低限の設定です。

何はともあれ yum update

まずは yum update です。
$ sudo yum update -y

タイムゾーンの変更

Amazon Linux はデフォルトのタイムスタンプが UTC になっているので、日本時間に変更します。
$ date
2017年  5月  20日 土曜日 02:33:43 UTC
$ sudo ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
$ date
2017年  5月  20日 土曜日 11:35:33 JST

このままでは、サーバーの再起動を行うと UTC に戻ってしまうので、設定を変更します。
$ sudo vim /etc/sysconfig/clock

※「ZONE="UTC"」となっている部分を「ZONE="Asia/Tokyo"」に変更します。

ec2-user の 削除

ec2-user はデフォルトのユーザーなので、セキュリティ上、削除しておいた方が良いです。
(もちろん変わりのユーザーも作成します。)

まずは、新規ユーザー(ofkomauser)を追加します。
$ sudo useradd ofkomauser

鍵などをec2-userからコピーし、権限設定を行います。
$ sudo cp -arp /home/ec2-user/.ssh /home/ofkomauser/
$ sudo chown -R ofkomauser /home/ofkomauser/.ssh

新しいユーザーのパスワードを設定します
$ sudo passwd ofkomauser

sudoersファイルを編集し、新しいユーザーで sudo が使えるようにします。
修正:Amazon Linux 2 から、cloud-initが無くなり、90-cloud-init-usersを編集する事になっています。
$ sudo visudo -f /etc/sudoers.d/cloud-init
$ sudo visudo -f /etc/sudoers.d/90-cloud-init-users

※「ec2-user」の部分をコメント化、もしくは削除し、新しいユーザーを追加します。
# User rules for ec2-user
#ec2-user ALL=(ALL) NOPASSWD:ALL
ofkomauser ALL=(ALL) NOPASSWD:ALL

そして、最後に「ec2-user」を削除します。
$ sudo userdel -r ec2-user

以上が、最低限の設定になります。

EC2の用途によっては、もっと細かい設定は必要ですが、
それはまった追って記事にしようと思います。


,

2017年5月6日土曜日

Codeigniter で他システムとセッション共有する場合に、$_SESSION が消えてしまう

オフィス狛 技術部です。

同じドメイン配下に存在する別システム(Codeigniter ではないPHPを使ったシステム)と、
セッションを共有する・・・つまり、$_SESSION で値をやりとりする事になったのですが、
Codeigniter 側で $_SESSION から値を取ろうとすると、空になっている現象が発生しました。
単純には行かないのですね、やっぱり。

※ちなみに、Codeigniter のバージョンは 3.1.2 です。

1)セッションIDを調べてみる

セッションIDが変わってしまって、違うセッションを見ているのかと思い、
$_COOKIE を調べたところ、session_id は同じでした。
(同じドメインですし、敢えてセッションを変えるような設定もしていないので)
セッションIDが同じで値が取れないのであれば、どこかで値を消している、という事になります。

2)Codeigniter を使用していないPHPシステムで試してみる

Codeigniter を使用していない、Webサーバー上に置いただけのPHPファイルで試してみたところ、
$_SESSION から値が取れる事が確認出来ました。
という事は、Codeigniter でセッションを消している事になります。

3)Codeigniter の Session.php を調べてみる

というわけで、Codeigniter の System/libraries/Session に存在する、
「Session.php」を調べてみました。

105行目付近に、
$class = $this->_ci_load_classes($this->_driver);
という記述があり、このタイミングで driver を変更しているため、
この処理以降に設定した driver のセッションを参照しているのではないかと予想できます。

※実際、この処理の直前では $_SESSION の値は取得できたが、
直後には値が消えていた事を確認しています。

4)対応方法(暫定)

とりあえず、先程の記述の直前で、
// 追加ここから
session_start();
$session = $_SESSION // 値を一時変数に格納
session_write_close();
// 追加ここまで
$class = $this->_ci_load_classes($this->_driver);
と記載します。実は、session_start 自体はもっと後で行うのですが、
ここで一旦スタートさせて、$_SESSION の値を退避しておきます。
(closeも忘れずに)
そして、今度は、元々あった「session_start」(150行目近辺)の後に、
session_start();
//追加ここから
$_SESSION = $session; // 値を一時変数から再設定
// 追加ここまで
と追加する事で、他システムで設定された $_SESSION を利用する事ができます。

5)本当はどう対応するべきなのか

実は、弊社側のシステムは、セッションをDBに保存する設定にしています。
そしておそらく、他システム側は、セッションはファイル保存していると思います。
(弊社保有のシステムでは無いので、実際は分からないですが・・・)
ですので、$_SESSION が消えてしまうのも、当然と言えば当然なのです。
だとするならば、
こちら側の driver を「files」にして、保存パスを共有した場合、うまくいきそうな気がします。

※ちなみに、設定出来る driver は、本家サイト(翻訳版)に記載してありますが、
  • files(デフォルト; ファイルシステムベース)
  • database
  • redis
  • memcached
となっています。(自分でカスタムセッションドライバも作成可能です。)

今回は、テスト環境含め、弊社が触れる環境では無いので、
色々試せないですが、いずれ社内に環境作って試してみようと思います。


,