sshdが起動しない

AWS EC2において表題の件に陥った。

■ 環境

  • AWS EC2
  • Amazon Linux

■ 接続できない

「SSHで接続できなくなった」

と相談を受けた。話を聞いてみると「/var を全て削除した」という事をやったらしい。状況がおかしいのでManagementConsoleからインスタンスを再起動してみたりもした。とのこと。

該当のインスタンスを停止し、EBSをデタッチ。別途復旧用のインスタンスを起動し、デタッチしたEBSを復旧用のインスタンスにアタッチ。復旧用インスタンスにSSHでアクセスし、アタッチしたEBSを`mount`する。そして中を確認した。

ログファイル等を見ているとsshdが起動した形跡がない。”/var/log/secure“が空っぽのままであったので”/etc/init.d/sshd“にログを仕込む。先ほどの手順を逆に行い、該当のインスタンスを起動してみるも、やはり`ssh`での接続はできなかった。

再度復旧用のインスタンスでEBSを`mount`して仕込んだログを見ると下記のメッセージが出力されていた。

failed to run commands: exit status 255
Missing privilege separation directory: /var/empty/sshd

とりあえず該当のディレクトリを作成し、再度インスタンスを起動したところ`ssh`での接続ができるようになった。

念のため、”openssh-server“を入れ直すことにしたのだが、”/var“を削除したことによって`yum`のデータベースも削除されてしまったのだろうエラーとなる。ので見た目だけではあるがインストールした。

$ sudo yum install openssh-server

他にもエラーが残っている気がするが、とりあえずの復旧としては終了。

以上。

EC2 Maintenance

表題の件について。

■ 環境

  • Amazon EC2

■ mail

下記の件名のメールが届いていた。

Amazon EC2 Maintenance - Maintenance [AWS Account: XXXXXXXXXXXX]

使用しているインスタンスでメンテナンスがあるようだ。1インスタンスのみであったし、対象は別に再起動されても問題のないものであったのだが、先に自身で再起動してしまうことにした。

対象のインスタンスで`reboot`コマンドで実施した。

再起動後にManagementConsoleから確認したが、「予定されているイベントが1件あります」は変わらず。下記を参照した。

Amazon EC2のメンテナンスのヘルプページ
https://aws.amazon.com/jp/maintenance-help/

上記によると、再起動後にManagementConsoleに反映するのに1時間ほど掛かるようである。よってしばし待つ。

と思って1時間ほど待っていたのだが、反映されず…。はて?と思っていると下記に気がついた。

インスタンスの予定されたイベント
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html?icmpid=docs_ec2_console#schedevents_actions_reboot

確認してみると今回通知が来ているのは”system-reboot“の方であった。「予定されたメンテナンス期間中にシステムの再起動が実行されるまで待つことをお勧めします。」とのことなので放置することにした。

以上。

AmazonLinuxでJSTに固定

AmazonLinuxにおいて表題の通り。”glibc“のパッケージを”update“した際に”JST“にしておいた時間が”UTC“に戻ってしまっていた。

■ 環境

  • Amazon Linux

■ /etc/localtime

/etc/localtime“はいつも変更をしている。

$ sudo cp /usr/share/zoneinfo/Japan /etc/localtime

これで”JST“に変わったと満足してしばらく放置してしまうことが多々ある。前述の通り”glibc“のパッケージを”update“した際に再度”UTC”に戻ってしまうという現象が発生する。

■ /etc/sysconfig/clock

このファイルも下記のように変更する。

$ cat /etc/sysconfig/clock
ZONE="Asia/Tokyo"
UTC=true
$

後はおとなしく次の”update“を待つべし。

以上。

EC2で使用可能なインスタンスタイプ

表題の件について、どうやって調べるのが良いのだろうか?と悩んだ。とりあえずこれが良いのかな?と思えるものをメモしておく。

■ 環境

  • Mac OSX El Capitan
  • awscli 1.10.8

■ インスタンスタイプ

ほとんどが起動時に指定し、たまに後からインスタンスを再起動をしてインスタンスタイプを変更したりするが、次々に新しいインスタンスタイプが出てきたりして何を指定すれば良いのか、何が指定できるのか、というのがわからなくなる。指定できるインスタンスタイプの一覧をどこからか取得したいのだが、どこで取得できるのか。いろいろ試してみたのだがマニュアルを参照するのが良いのかな、という結論に達した。タイプの詳細はWEBページを見る。

`aws ec2 run-instances`のヘルプに一覧が書かれていた。

$ aws ec2 run-instances help

この中の`–instance-type`のオプションに書かれている。現状指定できるのは下記のようである。`–instance-type`のオプションがある他のサブコマンドにも同じように記載があるのであろう。

  • t1.micro
  • m1.small
  • m1.medium
  • m1.large
  • m1.xlarge
  • m3.medium
  • m3.large
  • m3.xlarge
  • m3.2xlarge
  • m4.large
  • m4.xlarge
  • m4.2xlarge
  • m4.4xlarge
  • m4.10xlarge
  • t2.nano
  • t2.micro
  • t2.small
  • t2.medium
  • t2.large
  • m2.xlarge
  • m2.2xlarge
  • m2.4xlarge
  • cr1.8xlarge
  • i2.xlarge
  • i2.2xlarge
  • i2.4xlarge
  • i2.8xlarge
  • hi1.4xlarge
  • hs1.8xlarge
  • c1.medium
  • c1.xlarge
  • c3.large
  • c3.xlarge
  • c3.2xlarge
  • c3.4xlarge
  • c3.8xlarge
  • c4.large
  • c4.xlarge
  • c4.2xlarge
  • c4.4xlarge
  • c4.8xlarge
  • cc1.4xlarge
  • cc2.8xlarge
  • g2.2xlarge
  • cg1.4xlarge
  • r3.large
  • r3.xlarge
  • r3.2xlarge
  • r3.4xlarge
  • r3.8xlarge
  • d2.xlarge
  • d2.2xlarge
  • d2.4xlarge
  • d2.8xlarge

随分とあるようだ。デフォルトは”m1.small“のようである。

以上。