zuntan02のはてなブログ

備忘録的なものです。時々職場の技術者ブログにも転記してますが、メインはこちらで。

Rocket.ChatをAmazonEC2のCentOS7に導入した

EC2のCentOS7にRocket.chatをインストール＆NginxでSSL処理のメモ

【感想】

・構築自体はCentOS7を用意すれば、後述するさくらのナレッジに紹介された手順通りで構築可能。
・t2.microやt2.smallではCPUクレジットを一瞬で使い切って激重になるのでそれなりのスペックが必要。m4.largeあたりだと快適。
・Slackよりいたずらにリッチな感じ。音声メッセージって使う？
・WebRTC経由でのビデオチャットは正直まだ安定しているとはいいがたい。端末によってはカメラにアクセスできない場合もあり、まだまだβな雰囲気。

【記事作成時のバージョン】

>Stable: 0.46.0 22nd November 2016
>https://rocket.chat/releases/latest/download

【参考記事】

さくらのナレッジ

knowledge.sakura.ad.jp

公式のインストール手順

rocket.chat

【Rocket.Chatとは】

上記さくらのナレッジの記事より抜粋：

基本機能はほぼSlackと同様で、UIも似ている。また、WebブラウザだけでなくiOS/AndroidアプリやWindows/Mac OS X/Linux向けのデスクトップクライアントも提供されている点もSlackと近い。さらに音声/ビデオチャット機能やファイル共有機能、画面共有機能も備えている。
実装言語はNode.jsで、データベースにはMongoDBを採用。また、アプリケーションフレームワークにはMeteorが使われている。そのため、これらの技術に関する知識があればカスタマイズしやすい。

【CentOS7へのRocket.Chatインストール手順】

例によってさくらのナレッジをそのままコピペです……
※最初CentOS6やAmazonLinuxへのインストールを試みたのですが、どうしてもうまくいかずに諦めました。CentOS7ならいけたので以下にメモします。

SELINUX

vi /etc/sysconfig/selinux
→SELINUX=disabled : 無効にしておく（AmazonLinuxは初期値でdisabledだがCentOSはenableなので。）

インストールログ
# EPELより必要モジュールをインストール
rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum install --enablerepo=epel mongodb-server nodejs npm curl GraphicsMagick

# Rocket.Chat本体のインストール
cd /usr/local/src
curl -o rocket.chat.tgz -L https://rocket.chat/releases/latest/download
tar xvzf rocket.chat.tgz
mv bundle /opt/rocket.chat

# 実行ユーザ「rocketchat」を追加
useradd -r rocketchat -U
chown -R rocketchat:rocketchat  /opt/rocket.chat

# Systemdにサービス登録
# 環境ファイル作成
mkdir /etc/rocket.chat
touch /etc/rocket.chat/rocketchat.env

vi /etc/rocket.chat/rocketchat.env
# ============================================================
MONGO_URL=mongodb://localhost:27017/rocketchat
ROOT_URL=http://＜サーバのIPなど＞:3000/
PORT=3000
# ============================================================

# Systemdの設定ファイル作成
vi /etc/systemd/system/rocketchat.service
# ============================================================
[Unit]
Description=Rocket.Chat Server
After=network-online.target mongod.target
Requires=network-online.target

[Service]
ExecStart=/usr/bin/node /opt/rocket.chat/main.js
EnvironmentFile=/etc/rocket.chat/rocketchat.env
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=rocketchat
User=rocketchat

[Install]
WantedBy=multi-user.target
# ============================================================

# パッケージのディレクトリにて、npm installでnode.jsに必要なpackageをインストールする
cd /opt/rocket.chat/programs/server/
npm install

# systemctlコマンドで設定を反映させ、MongoDBおよびRocket.Chatを起動させる。
systemctl daemon-reload
systemctl start mongod
systemctl start rocketchat


# 稼働サービスの確認
systemctl status rocketchat

# サービス自動起動登録
systemctl enable mongod
systemctl enable rocketchat

# サービス自動起動登録状況確認
systemctl list-unit-files --type=service | grep mongo
# mongod.service  enabled
systemctl list-unit-files --type=service | grep rocket
# rocketchat.service  enabled

【問題解決メモ】

さくらのナレッジの手順だけで進めた場合、rocketchatを開始すると以下のエラーが出た
systemctl status rocketchat

● rocketchat.service - Rocket.Chat Server
   Loaded: loaded (/etc/systemd/system/rocketchat.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2016-12-07 16:35:30 JST; 13s ago
  Process: 12389 ExecStart=/usr/bin/node /opt/rocket.chat/main.js (code=exited, status=1/FAILURE)
 Main PID: 12389 (code=exited, status=1/FAILURE)

Dec 07 16:35:30 rktcht.hogehoge.jp systemd[1]: Started Rocket.Chat Server.
Dec 07 16:35:30 rktcht.hogehoge.jp systemd[1]: Starting Rocket.Chat Server...
Dec 07 16:35:30 rktcht.hogehoge.jp systemd[1]: rocketchat.service: main process exited, code=exited, status=1/FAILURE
Dec 07 16:35:30 rktcht.hogehoge.jp systemd[1]: Unit rocketchat.service entered failed state.
Dec 07 16:35:30 rktcht.hogehoge.jp systemd[1]: rocketchat.service failed.

→パッケージのディレクトリにて、npm installを実行するとエラーは出なくなった

cd /opt/rocket.chat/programs/server/
npm install

SSL対応

Nginxを上に置いてSSL処理する。confは公式サイトのコピペ。
【参考】
https://rocket.chat/docs/installation/manual-installation/configuring-ssl-reverse-proxy#configuring-ssl-reverse-proxy

# epelからnginxインストール
yum install nginx

# SSL証明書配置
mkdir /etc/nginx/ssl
hogehoge.comのpemとkeyを配置。
chmod 400 hogehoge.com.key
chmod 400 hogehoge.com.pem

# nginx.conf設定
vi /etc/nginx/conf.d/rktcht.conf
#==========================================================
# Upstreams
upstream backend {
    server 127.0.0.1:3000;
}

# HTTPS Server
server {
    listen 443;
    server_name hogehoge.com;

    error_log /var/log/nginx/hogehoge.com.access.log;

    ssl on;
    ssl_certificate /etc/nginx/ssl/hogehoge.com.pem;
    ssl_certificate_key /etc/nginx/ssl/hogehoge.com.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # don’t use SSLv3 ref: POODLE

    location / {
        proxy_pass http://127.0.0.1:3000/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forward-Proto http;
        proxy_set_header X-Nginx-Proxy true;

        proxy_redirect off;
    }
}
#==========================================================
nginx -t
systemctl restart nginx

# 自動起動確認
systemctl enable nginx
# 確認
systemctl list-unit-files -t service | grep -e nginx
# nginx.service  enabled


■そのほかやったこと
設定項目が山盛りで何をどう設定したらベストなのかがさっぱりわからない。とりあえず以下の設定で運用中。

[メール]-[SMTP]で既存のSMTPサーバを指定。SMTPサーバ側にユーザも専用で作成した。

[全般]-[言語]で日本語を選択

[管理]-[メッセージ]-[検索に常に正規表現を使用する]
（あなたの言語が MongoDBの全文検索 でサポートされていない場合、これを有効にすることをお勧めします。）
をONに。デフォルトのままだと部分一致検索ができない。

【CentOS6】chrootでsftp専用のアカウントを追加する

【前提】

1台のWebサーバにドキュメントルートを複数作成し、それぞれ個別のお客様にご利用いただくことになった。
他のお客様のドキュメントルートが見えないようにするために、

・sftp+chroot

でレンタルサーバ的な運用を行ってみる。

【方法メモ】

・sftpdグループにマッチしたら、sftpのみを許可してhome以上の階層に遷移させない（chroot）設定

chrootとは：
chrootとは、UNIXオペレーティングシステムにおいて、現在のプロセスとその子プロセス群に対してルートディレクトリを変更する操作である。 ルートディレクトリを別のディレクトリに変更されたプロセスは、その範囲外のファイルにはアクセスできなくなるため、この操作をchroot監獄などとも呼ぶ。"
chroot - Wikipedia
https://ja.wikipedia.org/wiki/Chroot

mkdir /opt/hogehoge

# hogehoge用グループの作成(apacheも所属させておく)
groupadd hogehoge
gpasswd -a apache hogehoge

# シェルへログイン不可ユーザを作成（-sオプションでログインシェルを/sbin/nologinにする）
useradd -g hogehoge -d /opt/hogehoge/ -s /sbin/nologin user-hogehoge

# 作成したユーザをapacheグループにも所属
gpasswd -a user-hogehoge apache

# ユーザにパスワードを設定
passwd user-hogehoge
Match条件とChroot先を以下の様にしてsshd_configに追記

vi /etc/ssh/sshd_config

# Subsystem sftp      /usr/libexec/openssh/sftp-server
Subsystem sftp internal-sftp 

Match Group hogehoge User *hogehoge
ChrootDirectory /opt/hogehoge
X11Forwarding no
AllowTCPForwarding no
ForceCommand internal-sftp -f AUTHPRIV -l VERBOSE -u 0002
オプションについて確認
Subsystem       sftp    internal-sftp
→SFTP の接続を処理するサブシステムを、標準の sftp-server から sshd 内部の internal-sftp に変更

X11Forwarding no		：X11転送させない（GUIを外部から使わない）
AllowTCPForwarding no	：ポートフォワーディングさせない
ForceCommand internal-sftp -f AUTHPRIV -l VERBOSE -u 0002
			-f AUTHPRIV	：syslogのfacilityを認証(AUTHPRIV)に指定する
			-l VERBOSE	：ログレベル
			-u 0002		：umask
chrootディレクトリのユーザーとグループは root:root、権限が755である必要があるので確認

ls -ld /opt/hogehoge

sftpユーザのため、chrootしたディレクトリ直下にディレクトリ(ここではdata）を配置し、sftpして編集できるようにする
cd /opt/hogehoge
chown -R apache:hogehoge data
find data -type d -exec chmod 2775 {} \;
find data -type f -exec chmod g+w {} \;


あとは上記 /opt/hogehoge/data をドキュメントルートにしてサイト構築

テスト

user-hogehogeアカウントでssh接続しようとしする
→接続できない

WinSCPなどでsftp接続した場合
→接続できるが、Chrootされていて他のディレクトリは見えない

ログについて

ファシリティはAUTHPRIVとなっている。AUTHPRIVは認証周りなので、
/etc/rsyslog.conf

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

/var/log/secure
に出力されることになる。

Apr 21 12:14:27 hogehoge sshd[1428]: opendir "/htdocs/wp-content" [postauth]
Apr 21 12:14:27 hogehoge sshd[1428]: closedir "/htdocs/wp-content" [postauth]

こんな感じ

メモ：VMのハードウェアクロックとソフトウェアクロックの関係

オンプレミス時代の環境に、cronで以下のコマンドを実施しているものがあった

0 0 * * * /usr/sbin/ntpdate ntp.jst.mfeed.ad.jp > /dev/null 2>&1
5 0 * * * /sbin/hwclock --systohc > /dev/null 2>&1

ntpで時間を合わせて、さらにその時間をハードウェアクロックに反映している。
これを仮想化するとき、あれ？ハードウェアクロックってどこになるの？と
思ってググったら以下の様だった。

tech-mmmm.blogspot.jp

VMにおけるハードウェアクロックは仮想BIOSが持つ時間
VM停止後のハードウェアクロック情報はBIOSは保持せず消失
VM起動時にESXのシステムクロックをVMのハードウェアクロックとして同期する

【AWS】一つのELBに複数のSSL証明書を設置できるか問題

【確認したいこと】
・ACMは1証明書あたり10個までの別名。つまり、一つのELBで10ドメインまでしかSSL証明できない。もっと追加したい。
・そもそもELBの443は複数の証明書を乗っけられないのか？

【確認手順】
既にHTTPS/443を使用しているロードバランサに、[追加]でHTTPS/443を追加
→「ロードバランサーのポートを重複して使用することはできません」となり、追加できない。
f:id:zuntan02:20161118165511p:plain

ダメだ。上限緩和申請するしかないのか。
AWSサポートダッシュボードから50まで上限緩和してほしい旨申請してみたところ、３日くらいでサクッと上限緩和してくれたので、とりあえずそれで。
参考：
http://zuntan02.hateblo.jp/entry/2016/09/28/202538

さくらのクラウドでディスク容量を拡張するのにハマったメモ

【問題】

・100GBのディスクのアーカイブをもとに500GBのディスクを作成してみたところ、領域が拡張さてれなかった。

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2        95G  7.5G   83G   9% /
tmpfs           499M     0  499M   0% /dev/shm

lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0     11:0    1 1024M  0 rom
sr1     11:1    1 1024M  0 rom
vda    252:0    0  500G  0 disk
|-vda1 252:1    0    4G  0 part [SWAP]
`-vda2 252:2    0   96G  0 part /

こんな感じ。500Gのうち100Gしか使われていない。

【原因】

・アーカイブからそのまま（ディスクサイズ以外は何も修正せずに）起動しただけでは拡張されない。
以下がポイント
・アーカイブのタグ「@size-extendable」をつける
・アーカイブからディスクを作成する際、ホスト名にアーカイブを取った元ホスト名と同じものをつける

【詳細】

さくらナレッジに紹介されている手順http://knowledge.sakura.ad.jp/knowledge/5970/に従えば問題ない。

サーバをシャットダウンしてアーカイブを取得

「アーカイブソース」にtest01のディスクを選択し、タグに「@size-extendable」を付け、右下の「作成」をクリック

アーカイブのタグに「@size-extendable」をつける必要がある。
試しに同じアーカイブで、このタグを外してから同じ手順でディスクを作成してみたところ、ディスクサイズの修正は行われませんでした。


アーカイブからディスク作成

[ディスク]-[＋追加]-[アーカイブ選択]
・先ほど作成したアーカイブを選択し、ディスクサイズを500GBにする。
・接続先サーバに元のサーバを指定
・ホスト名にアーカイブを取った元ホスト名と同じ名前を入力する。
こちらは

(さくらのクラウドのディスク修正機能を使用してパーティション拡張を行うための仕様です)。

とのこと。
ディスクに名前等をつけたら、右下の「作成をクリックし、ディスクを作成します。

旧ディスクをサーバから取り外し

省略

サーバ起動

省略

ディスク容量の確認

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2       489G  7.5G  456G   2% /
tmpfs           499M     0  499M   0% /dev/shm

いけた！
ちゃんとドキュメントは読みましょうという話ですが、うーん、タグで挙動が変わるのは……なんというか裏技では……

AWS SESでメールを受信する

【前提】
某サービスで、独自ドメイン（仮にmail@hoge.jpとする）へのメールをSESで受けてみるメモ。
※これまでは、たまに来る承認メールとかのためにメールサーバを用意してた。
　問い合わせなどは別の窓口で対応していたので、ホントに特定のメールが取れれば良い程度。

【参考】
Amazon SES によるメール受信の概念
https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/receiving-email-concepts.html
dev.classmethod.jp
→クラスメソッドさんのページに全部書いてある。以下は俺メモ

【手順】
https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/receiving-email-getting-started-before.html
こちらからのステップに従って作業を進める

ステップ 1: 開始する前に

・AWSへのサインアップとRoute53によるドメインの登録：省略

スステップ 2: ドメインの検証

1.Route53を登録しているAWSアカウントでhttps://console.aws.amazon.com/ses の Amazon SES コンソールを開きます。→「SES is not available in アジアパシフィック (東京). Please select another region.」といわれる。2016年11月現在東京リージョンは使用できないので、バージニア北部を利用してみる。

2.[Identity Management]-[Domains]-[Verify a New Domain] を選択

3.Domain:にAmazon Route 53 に登録したドメインの名前を入力、[Generate DKIM Settings] は未選択のままで、[Verify This Domain] を選択。

4.[Verify a New Domain] ページに、DNS サーバーに追加する必要があるレコードが表示されているので、[Use Route 53] を選択。

5.[Use Route 53] ページで、[Domain Verification Record] 、[Email Receiving Record]、および使用するホストゾーンを選択。

6.[Create Record Sets] を選択し、[Domain Identities] リストに戻る。

7.数分間待ってから、コンテンツページの右上にある最新表示ボタン押下、ドメインのステータスが [verified] であることを確認します。

※この時点でRote53を確認すると、MXレコードが[inbound-smtp.us-east-1.amazonaws.com]に切り替わっていた。

ステップ 3: 受信ルールの設定

受信ルールセットは、受信するメールに対してどのような処理を行うのかを指定する順序が指定された受信ルールの集合。

受信ルールを作成する

1.[SES Home]-[Email Receiving]-[Rule Sets]-[Create a Receipt Rule] を選択。
2.[Recipients] ページで、[Next Step] を選択。
　※受信者（Recipients）を追加していないため、この受信ルールは、すべての確認済みドメインのすべての受信者宛てのメールを処理します。下記の場合、”*@hoge.jp”あてのメールはすべてs3に保存されることになります。

3.[Add action] メニューから [S3] を選択
4.[S3 bucket] で、[Create S3 bucket] を選択
BucketNmae:mail.hoge.jp（任意）
その他のオプションはデフォルト設定のままにして、[Next Step] を選択。

5.[Rule Details] ページで、ルール名に [rule-for-mail.hoge.jp] と入力し、その他のオプションはデフォルト設定のまま[Next Step] を選択、[Review] ページで、[Create Rule] を選択。

ステップ 4: テストE メールの送信

hogefuga@hoge.jpにメールすると先ほど作成したs3にメールが溜まっていく。
ダウンロードして内容を確認。
→OK。

おまけ：メールが届いたらSNSからお知らせする

1.[SES Home]-[Email Receiving]-[Rule Sets]で既存のルールをEdit
Action:S3の[SNS Topic]-[Create SNS topic]でSNS topicを作成する

例：
TopicName:hoge-email-recieved
Display Name:hoge-email-recieved
・[Topic ARN] フィールドで、前のタスクで作成したトピック ARNをペーストします。
・[Protocol] ドロップダウンボックスで [Email] を選択します。
・[Endpoint] ボックスに、通知を受信するために使用できる E メールアドレスを入力します。
→[Create subscription] をクリックします。

これで、メールがS3に保存されると同時に内容を記載したメールが送られてきます。

おまけ２：特定の受信者（Recipients）のみAmazon WorkMailで受信し、それ以外はS3に落とす

1)WorkMail(1アカウント当たり$4/月)を契約
[Quick setup]→Alias : hoge.jp
[Domains]-[Add domain] : hoge.jp
[Users]-[Create User] : info@hoge.jp

2)[SES]-[Rule Sets]

→WorkMailのルールに以下を設定
1.Recipient：info@hoge.jpのみにする
2.[Action]の[WorkMail]の次に [Stop Rule Set]を追加し、
　info@へのメール処理が終わった場合はここで評価を終了するようにする

3.WorkMailのルールを一番最初にする。

【動作】
・info@hoge.jpにメールが来た場合は最初のWorkMailのルールが評価されてWorkMailに落ちる
・hogehoge@hoge.jpなど上記のRecipientにマッチしないメールアドレスに届いた場合は
　上のステップ3で作成した[rule-for-mail.hoge.jp]で、S3への保存とSNSによる通知を実施

おまけ３：SESで届いたACM承認メールから承認リンクを取り出す

admin/hostmasterなどすべての宛先に飛ぶため、それぞれのドメイン宛に5通飛ぶ。マルチドメイン証明とかしてると一気に何十通も飛んできて、見つけ出すのが面倒だったので。

# EC2インスタンス上の作業ディレクトリにてS3にたまっているメールを取得
aws s3 cp s3://mail.hoge.jp ./ --recursive

# 以下のコマンドでadmin@へのメールのみあたりをつける
find . -mtime -1 -type f | xargs grep 'To: admin@' | cut -d ":" -f 1 | xargs -I{} sh -c 'grep ^Domain {};grep certificates.amazon.com/approvals?code {} | grep -v "</a>"'