Go to Qiita Advent Calendar 2024 Top
LoginSignup
1
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@yamazaki(yamazaki)

KUSANAGI on ConoHa セットアップ #1 サーバー設定編

Last updated at Posted at 2017-08-16

色々事前の調査は終えたので、いよいよ、本格的にサーバのセットアップを進める。
調査した時の以下のメモを見ながら、やるとこを思い出しつつ、具体的な操作について、ここに記録してく。

手順記載を割愛する事前作業

ConoHaを利用するためのアカウント作成と、インスタンスの追加については、簡単すぎるので割愛するが、以下については、どうするか考えた上で作業を進めることをオススメ。

  1. インスタンスのネームタグは、複数インスタンスを作成した場合でも識別しやすい命名がいいよ
  2. SSHの鍵は、後から設定するのでも、インスタンスを作成するときでもいいけど、どっちにする？
  3. 接続許可ポートは、最低限にしておいてもいいかもね

[追記]
SSHのポートを変更するので、接続許可ポートは全解放にして、サーバー側のファイアウォールで制限。
APIで設定すればインフラ側(ConoHaの管理ポータルで指定する接続許可ポート)での制御もできる。

後、サーバーで独自ドメインを利用する場合は、インスタンス作成後にわかるサーバーのIPを控えておき、利用するドメインのDNSの設定でexample.comとwww.example.comの両方に対して、Aレコードを設定しておくとSSL(Let’s Encrypt)の設定の際に失敗しない。

後、サーバーのホスト名についてもhost.example.comなどでAレコードを設定しておくと良、サーバーのroot宛のメールを転送する際にエラーが発生しない。

ということで、改めて列挙すると、細かな手順記載を割愛する事前作業は、以下。

  1. SSHの鍵生成
  2. ConoHa上でのインスタンス作成
  3. 独自ドメインのAレコード設定

SSHの鍵生成

今回、鍵は自分のMacBookで生成して、ConoHa上でインスタンス作成時に、公開鍵を登録したので、その際のメモ。

$ ssh-keygen -t rsa -b 4096 -C "{your_mail_adress}"
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/{user_user}/.ssh/id_rsa): 
Created directory '/Users/{user_user}/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /Users/{user_user}/.ssh/id_rsa.
Your public key has been saved in /Users/{user_user}/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:(snip) {user_user}
The key's randomart image is:
+---[RSA 4096]----+
|   o+o.o.oOO*... |
(snip)
|           ...   |
+----[SHA256]-----+

ConoHaにインスタンス作成時、公開鍵を入力欄に記入する時は、以下のようにクリップボードにコピーして貼り付けをした。

$ pbcopy < ~/.ssh/id_rsa.pub

Aレコード設定

僕の場合、ムームードメインを利用しているので、Aレコードの設定は以下のような感じ。
(ドメイン名やIPはマスキングしたので、そのあたりはよしなに)

ムームードメインでのAレコードの設定例

サーバーのyum update

まずは、yum updateなんだけど、KUSANAGIでは、初期設定のyumリポジトリ以外に、remiとremi-php56も参照するようなので、毎度、それらを指定するのは面倒。ということで、毎度の指定を省略できるように、参照するリポジトリの初期値を変更。

SSHの設定変更をする前なので、サーバーへの接続は、一旦、以下のような感じでクライアントから接続する。

$ ssh root@150.95.000.000

で、yumのリポジトリの設定を編集。

# cd /etc/yum.repos.d/
# vim remi.repo

以下のように、毎回参照するレポジトリremiとremi-php56をenabled=0からenabled=1に変更しておく。

[remi]
 :
(snip)
 :
enabled=1

[remi-php56]
 :
(snip)
 :
enabled=1

上記設定にある通り、公式ドキュメントにある通りyum updateを実行。

# yum update -y

ちなみに、公式ドキュメントでは、以下のように参照するyumリポジトリを追加指定している。

# yum --enablerepo=remi,remi-php56 update -y

updateが完了したら、rebootしておく。

ちなみに、yum updateでkernelもアップデートされていたので、念のため、/bootの容量をチェック。

# df
Filesystem                  1K-blocks    Used Available Use% Mounted on
/dev/mapper/centos_h16-root  47781076 2702264  45078812   6% /
devtmpfs                       497228       0    497228   0% /dev
tmpfs                          508192       0    508192   0% /dev/shm
tmpfs                          508192    6696    501496   2% /run
tmpfs                          508192       0    508192   0% /sys/fs/cgroup
/dev/vda1                      508588  313812    194776  62% /boot
tmpfs                          101640       0    101640   0% /run/user/0

3つか4つ前までのkernelが残っているようだったので、何処かのタイミングで、古いものは削除しておいても良さそう。

# package-cleanup --oldkernels --count=3
/bootのディスク容量が不足した時は以下のあたりを参考に対処する - [CentOS/RHELで古いカーネルを削除して/bootを整理する方法 - Qiita](http://qiita.com/testnin2/items/2946cc6bc54b0de96221) - [CentOS7 で不要になった古いカーネルを削除する - CUBE SUGAR CONTAINER](http://blog.amedama.jp/entry/2015/09/21/054317) - [yum-utilsを使って/bootの不要なカーネルを削除する方法 | OXY NOTES](http://oxynotes.com/?p=7297) - [バグラボ！: yumによる自動アップデートの注意点２つ](http://www.buglabo.com/2014/10/yum.html)

作業用ユーザーの作成

後ほど、rootでのSSH接続を不許可にするのと、今後の作業は、新設のユーザーで行うので、そのユーザーを追加する。

# useradd {user_user}
# passwd {user_user}

wheelグループの所属させて、

# usermod -G wheel {user_user}

wheelグループのみrootになれるように、設定ファイルを開いて、

# vim /etc/pam.d/su

以下の行がコメントアウトされているので、行頭の#を削除して設定を有効にする。

auth required pam_wheel.so use_uid

wheelグループのユーザーがsudoできるように以下のコマンドを実行して、

# visudo

以下が適用されていることを確認する。
(コメントアウトされていれば、行頭の#を削除しておく。)

%wheel ALL=(ALL) ALL

作成したユーザーでのシェルログインには、鍵認証を利用するので、/home/{user_user}/.sshに公開鍵を格納する。

鍵の操作は状況によりけりだが、僕の場合は、ConoHaでインスタンスを作成する際に手元の公開鍵を設定したので、rootのホームディレクトリ配下に既に必要な公開鍵が格納されているため、そちらを移設した。

cd /home/{user_user}
mkdir .ssh
mv /root/.ssh/authorized_keys /home/{user_user}/.ssh/
chown -R {user_user}. .ssh
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

ホスト名の変更

nmtuiコマンドを使って、サーバーのホスト名をDNSで設定したFQDNで設定する。

# nmtui

コマンドを実行すると以下のような画面がターミナル内で表示されるので、

スクリーンショット 2017-08-16 16.23.08.png

矢印キーでSet system hostnameを選択して、以下の入力画面を表示して、DNSで設定したFQDNを入力して、ホスト名を変更する。

スクリーンショット 2017-08-16 16.24.16.png

SSHの設定変更

SSHに関しては、以下のあたりを設定しておくと良さそう。

  1. ポートを22から任意の番号に変更
  2. プロトコルを2に限定
  3. rootでのSSHログインを禁止
  4. 公開鍵認証にして、パスワードによる認証を禁止

SSHの設定ファイルを開いて、

vim /etc/ssh/sshd_config

以下のあたりを設定を行う。

# 任意のポート番号に変更
Port {ssh_new_port}

# プロトコルを2に限定
Protocol 2

# rootでのログインを禁止
PermitRootLogin no

# 公開鍵認証を有効化
PubkeyAuthentication yes

# パスワード認証を無効化
PasswordAuthentication no

上記設定を適用するため、sshを再起動。

systemctl restart sshd.service

ローカルから、正常に接続できることを確認して完了。

$ ssh {user_user}@150.95.000.000 -p {ssh_new_port}

一応、初期値の22番ポートやrootで接続できないことをローカルから試してみて確認

$ ssh {new_user}@150.95.000.000
ssh: connect to host 150.95.000.000 port 22: Connection refused

$ ssh root@150.95.000.000
ssh: connect to host 150.95.000.000 port 22: Connection refused

$ ssh root@150.95.000.000 -p {ssh_new_port}
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

ファイアウォールの設定

ネットワークのファイアウォールに関しては、サーバーの設定だけでなく、ConoHaのインフラ側でも制御ができるが、APIで操作する必要があり、若干複雑なので、番外編で記すとして、一旦、サーバー上でできる設定を行う。

起動時にどのような挙動になっているかを以下のコマンドで確認。

# systemctl list-unit-files |grep firewalld
firewalld.service                             disabled

サーバー起動時に自動でファイアウォールが有効になるように以下のコマンドを実行。

# systemctl enable firewalld.service
Created symlink from /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service to /usr/lib/systemd/system/firewalld.service.
Created symlink from /etc/systemd/system/basic.target.wants/firewalld.service to /usr/lib/systemd/system/firewalld.service.

念のため、最初の設定状況を確認するコマンドを実行して、状態をチェック。

# systemctl list-unit-files |grep firewalld
firewalld.service                             enabled

ファイアウォールのサービスは止まっている状態なので、起動して後述の設定を行う。

# systemctl start firewalld.service

また、設定前の状態を確認しておく。

# firewall-cmd --list-services
dhcpv6-client ssh
# firewall-cmd --list-ports
(何も表示されないはず)

前項で、SSHのポートをカスタマイズしたので、そのポートを解放し、再起動時も同様に解放するように設定。

# firewall-cmd --add-port={ssh_new_port}/tcp
success
# firewall-cmd --permanent --add-port={ssh_new_port}/tcp
success

標準的なポートについて、ウェブサイトへのアクセスが未設定のため、設定し、sshについては、ポートを変更しているため、標準のポートは閉じておく。(カスタマイズで解放したポートと同様に、サービス起動時に同様の設定になるようにpermanetの設定もしておく)

# firewall-cmd --add-service=http
success
# firewall-cmd --add-service=https
success
# firewall-cmd --remove-service=ssh
success
# firewall-cmd --permanent --zone=public --add-service=http
success
# firewall-cmd --permanent --zone=public --add-service=https
success
# firewall-cmd --permanent --zone=public --remove-service=ssh
success

サービスを再起動して、設定内容が反映されているかを確認。

# systemctl restart firewalld.service
# firewall-cmd --list-services
dhcpv6-client http https
# firewall-cmd --list-ports
{ssh_new_port}/tcp

以上で、主なサーバー側の設定が完了したので、次は、KUSANAGIを利用したWordPressのプロビジョニング！

続きは、こちら(KUSANAGI on ConoHa セットアップ #2 KUSANAGI&WordPress設定編)に記載。

1
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?