VPSでCentOS7サーバを構築する 拡張設定編

前回から引き続いて(CentOS7を使った)サーバの設定を続けます。VPSの場合やCentOS7の場合はこういうテクニックも必要になる、という意味で変わった設定をしていますので、参考にしてみたい人は参考にしてみるとよいと思います。

 

07.ディスククォータを設定する

この作業は自宅サーバではまず必要ではない作業です。なぜなら自宅サーバで運営していてストレージ容量が足りなくなる、なんてことはまずあり得ない上に必要であればディスクを物理的に追加すればよい話だからです。これは「通常1パーティションしか割り当てが不可能」「ストレージ容量の拡張がほぼ不可能」「ストレージ容量が原因でのサーバ停止を避ける」という条件がある場合に設定するとよいと思います。実はこれがWindowModePatchの情報を集めようと思ってwikiを作ったはいいけれども公開できなかった大きな理由の一つです。

といっても、ディスククォータをパーティションレベルで割り当てるのは設定が意外と面倒なので単純な発想で「ループバックデバイスを使ってディスクイメージに容量制限をしたい領域を書き込ませる」というのがよいのでは、と思います。何かあったときにはファイルを取り出してディスクイメージを削除すれば簡単に元に戻せますし。

というわけでやってみましょう。私の場合は特にデータベースを扱う領域を別領域のように扱いたいので、その領域を作成します。例えばVPSだと大きくても50GBとか100GBのストレージしか持たない、なんてことは多いので、その中でも20GBをデータベースの領域として割り振ってみましょう。データベースはWordPressを使う関係でMariaDBを使う前提だとすると、/var/lib/mysqlをディスクイメージ領域にしてみるためにはこんなことをします。/diskimgにディスクイメージを置くとするとこんな感じになります。書き方はrootの状態での書き方になっています。必要であればsudoをつけてください。

# mkdir /diskimg
# dd if=/dev/zero of=/diskimg/database.img bs=1M count=20480
# mkfs.ext4 -m 0 /diskimg/database.img
# tune2fs -c 0 ./diskimg/database.img

ちなみに空ファイルの作成はddでやっていますが、こちらはtruncateから作ってもあまり変わりありません。mkfs.ext4を行った時点でスパースファイルになっていましたので。また、今回の場合はファイルシステムをext4で作っていますがこれは適当な物を選んでください。この場合のext4の問題点はオプションをつけなければ勝手にroot用の領域がとられてしまうこと、マウントの回数によってはディスクチェックがかかることですが、今回は内部的なのでそれはいらないということで両方ともカットしています。最後に/etc/fstabを書き換えて終わりですね。こんな行を追加します。

/diskimg/database.img /var/lib/mysql ext4 defaults 0 0

ほかにも必要な領域があるのであれば同じようにすればクォータシステムを(ある意味)簡単に使えます。本物のクォータと異なるところは対象の領域の容量が少なくなっても警告メールが来ないことでしょうか…。

 

08. 最新のパッケージを導入するために、現在入っている不必要なパッケージをすべて削除する

以前のサーバとできるだけ同じことができることが望ましいので、そのために次の物をセットアップします。

  • Webサーバ(Apache、php-fpm、nginx)
  • データベースサーバ(MariaDB)
  • FTPサーバ(vsftpd)
  • メールサーバ(postfix、dovecot)

この中で問題になるのがMariaDBです。こちらはCentOS7標準のリポジトリに入っているのですがこれのバージョンが5.5系統となっており、最新のMariaDBを使おうとするとライブラリが衝突する、ということであらかじめ削除しておく必要があります。

# yum erase mariadb-lib

ただ、面白いことに、これを行うとCentOS7に入っているpostfixがまとめて削除対象となりますので、データベースサーバをセットアップする前にメールサーバをセットアップしてしまうと人によっては泣きたくなるかも。サーバを構築する前に何を入れるのか確認をしておきましょう、ということですか…。

 

09. 最新のパッケージを導入するためのリポジトリを設定する

特にWebサーバに関わる物はある程度新しいパッケージを使いたかった、というかPHPを5.4系統から7系統まで引き上げることが今回の目的の一つなので必要なリポジトリを動かせるようにする必要があります。まず、リポジトリを導入する前に必要なライブラリおよびEPELリポジトリを使えるようにしておきましょう。

yum install yum-utils
# yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

そして、今回使うリポジトリとインストール手順は以下のようになります。

・IUS(Apache)

# yum install https://centos7.iuscommunity.org/ius-release.rpm

・Remi(php-fpm)

# yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm

・Nginx(nginx)

以下を/etc/yum.repo.d/にnginx.repoとして作成する

[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key

[nginx-mainline]
name=nginx mainline repo
baseurl=http://nginx.org/packages/mainline/centos/$releasever/$basearch/
gpgcheck=1
enabled=0
gpgkey=https://nginx.org/keys/nginx_signing.key

・MariaDB(MariaDB)

# curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash

インストール方法が多彩なので何でどれをやるのか確認しておくとよいと思います。vsftpとpostfixとdovecotについてはそこまでバージョンにこだわっているわけではないのでCentOS7標準のリポジトリからとってきた物で問題ないと思います。

 

10.アンチウィルスを導入する

これはできれば導入をしておきましょう。CentOS7で簡単にアンチウィルスを設定するなら多分ClamAVが設定資料も多くこの後のメールサーバとの連動もやりやすいのではないでしょうか。ほかに設定してみたい物があるならそれでもよいと思います。全くないのは外部に公開するサーバとしては怖すぎる、といったところですね。

 

以降は個別のセットアップ作業に入る

WordPressが使えるようになるまでにちょっと手順が必要なのがVPSなどの大変なところ。今回は移転が目的なので各種設定やチューニングは前のサーバのものをほとんど引き継ぎげるのがありがたいところ。バージョンアップしている分、設定が変わっていたりするのでその部分を合わせていくのが大変でしたが。

 

VPSでCentOS7サーバを構築する 初期設定編

サーバ移転記念ということで、しばらくはこのネタでやっていきたいと思います。まあ、今だとAWSやら何やらでほとんどがデフォルトで用意されている物を使えばなんていうことはなかったりするのですが、自前で構築してみたい人や自宅サーバを設定してみたい人向けに、設定でややこしそうなところをあげていって見ます。

 

基本的な全体手順

私が構築したときの手順は以下の通りです。

  1. VPSの契約(自宅サーバの場合はマシンセットアップ)
  2. rootログインを行い、yumで一度最新までアップデートを行う
  3. 通常のログインユーザを作成してsudoによるroot昇格を設定する
  4. (必要であれば)SELinuxを設定する
  5. SSHの設定を行い、外部からの侵入されないようにする
  6. 不必要なサービスを停止する
  7. ディスククォータを設定する
  8. 最新のパッケージを導入するために、現在入っている不必要なパッケージをすべて削除する
  9. 最新のパッケージを導入するためのリポジトリを設定する
  10. アンチウィルスを導入する

これ以降は必要な各サービスの導入となります。今回はWordPressが動作できることや、いまで使用していたftpやらメールやらが使用できることが条件なので、それに対応したサービスを設定します。以前に動作していた状態とほぼ同じにするので、バックエンドにhttpd(Apache)、フロントエンド(リバースプロキシ)にnginxを使い、phpはサーバ化することを念頭に置くと、

  1. httpd(Apache)の導入
  2. Let’s Encryptを使った常時SSL化対応処理
  3. php-fpmの導入
  4. MariaDBの導入
  5. nginxの導入
  6. vsftpdの導入
  7. postfix、dovecotの導入
  8. 各サービスの動作チェック

となります。今回はこの中の基本的な部分までを紹介したいと思います。

 

1.VPSの契約

これがなくては何も始まりません。特に常時応答となると自宅サーバでは電気代やらインフラやらが大変になるので簡単なサーバであればクラウドに任せてしまうのが正しいと思います。というわけで良さそうな物を適当に契約してください。ただし、メインメモリが1GBだと今の時期のプログラムだとさすがに厳しい物があるのでできれば2GB以上のプランにするとよいと思います。また、基本的にサーバでは余計な物を入れないのが鉄則なのと、極端にストレージを使うような用途(共有ファイルサーバなど)でもない限りはストレージ容量を使うことはあまりないので、ストレージの反応速度を上げるためにもSSDと書いてあればそちらの方がよいです。うまく選んでください。

なお、自宅サーバで考えている人は、これがマシンセットアップに変わります。マシン自体はほとんど何でもいいですが、OSを入れるときにはできるだけ最小構成でインストールするとよいと思います。必要になってからパッケージをインストールする方が余計な容量や余計なメモリを使わなくて済むので。

  • よほど動作が限定されなければメインメモリは2GB以上のプランを使う
  • ストレージはSSDと書いてある方が応答速度は速くなる傾向あり
  • OSからインストールする場合は最小構成で

2.rootログインを行い、yumで一度最新までアップデートを行う

契約した直後OSを入れ終わった直後はセキュリティ的にもかなり弱い状態ですのでまずは最新までアップデートする方がよいと思います。特にCentOSのようなOSでは、メジャーバージョンが変わらない限りはyumで最新のパッケージが入る物が少なくないので、ログイン用ユーザを作るよりも仮想コンソールなどで最新の状態にするのがよいのではないでしょうか。

 

3.通常のログインユーザを作成してsudoによるroot昇格を設定する

基本的にrootを用いて作業を行うのは非常に危険なのでrootを使うのははじめのアップデートとログイン用ユーザの作成およびsudoによる昇格設定までだと思います。手順としては

  1. useraddでログインするユーザを作成
  2. passwdでユーザにパスワードを設定
  3. visudoでwheelグループをsudoを使用できるグループに設定する
  4. usermodで作成したユーザにwheelグループに所属させる

になります。これができればいったんコンソールから抜けて作成したユーザでログインを行い、sudoによる昇格ができるかどうか確認してください。状況によってはサーバの再起動がいるかもしれません。

 

4.(必要であれば)SELinuxを設定する

VPSだと設定されていないこともあるSELinuxですが、OSを初期からインストールした場合はSELinuxが有効になっている場合も多いと思います。今現在ならばこれは「設定を簡単にしたい」ならばSELinuxを無効にする、「セキュリティを高めたい」ならSELinuxを有効にする、といったことで一長一短状態になっています。ここは個人的な好みではないでしょうか。

 

5.SSHの設定を行い、外部からの侵入されないようにする

SSHが設定できればあとは別マシンからでも操作が簡単にできるのでこれを設定して終わりになると思います。セキュリティ的には以下を考えておくとよいと思います。

  • Port22は攻撃の対象になるので(個人サーバであれば)ポート変更などでアタックされないようにするとよいかも。
  • ユーザをパスワード認証にすると、パスワード攻撃を受けてたときにかなり弱い。特定のコンピュータからしかログインしないのであれば鍵交換によるログインを設定してパスワード認証を無効にするとよい

特に後者については今ならば外部からのログインだとスマートフォンでのログインが考えられますが、こちらもAndroidであれば鍵ファイルを手動で入れておいてアプリ側で指定すればよほどでない限りはログインできますので、おすすめです。というわけで、設定の方法ですが、

  1. /etc/ssh/sshd_configに対して設定を行う
  2. ログイン用の鍵を作成する(ssh-keygen -t [鍵交換方式])
  3. 鍵ファイルをログイン用ユーザの場所に置く
  4. firewall-cmdでポートを再設定する
  5. /etc/ssh/sshd_configを変更してパスワードログインができないようにする

という手順になるかと思います。sshd_configに対して設定する重要なポイントは

Port 22
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

の3点になります。もちろん、rootログインの無効設定など当たり前の設定は行います。また、はじめの段階でパスワードログインができないようになると設定が失敗したときにサーバに入れなくなってしまいますので手順を間違えないように。鍵ファイルの作成および設定は、

$ ssh-keygen -t rsa
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
$ chmod 700 .ssh
$ chmod 600 .ssh/authorized_keys

のように行います。なお、ssh-keygenの時にオプションを聞かれますが、鍵付きにするとSSHのログイン時に鍵ファイルを開くためのパスワードが必要となるのでそれが良いか悪いかは人次第となります。あとはパーミッションの設定を忘れないように。.sshにあるid_rsaは(sftpなどで)手元に引き寄せておいて、id_rsa.pubは削除しておくとよいでしょう。ここまで設定できればポート変更をした人はfirewall-cmdでポートを開く設定を行い(–permanentと–reloadを忘れない)一度sshdを再起動して設定を有効にしましょう。ただし、外部からSSHでつないで処理している人はその端末をログイン確認ができるまでは絶対に落とさないように。落とすと直接コンソールからの処理に逆戻りとなります。

 

6.不必要なサービスを停止する

この段階でいらないサービスはすべて停止しておくのがよいかと思います。プリンタサーバとして使わないならcupsがある意味はないですし、bluetoothなんてサーバではほとんど使わないはずなのでこれも切ってしまってもよいと思います。なお、ここまで書いていませんでしたが、CentOS7系統はserviceコマンドではなくsystemctlを使いますので、こちらの使い方に慣れておきましょう。

 

次回は拡張設定編

ここまで来れば何もできないけれども乗っ取りなどの攻撃には耐えられるようになっていると思いますので一安心。逆にいうとここまで来ないと攻撃を受けてあっさりと乗っ取られる、なんて事態も起こりかねないことに気をつけておきましょう。次回はそのほかの設定ということで拡張設定編、と名乗っておきましょう。メインの設定はまだまだ後ですね。

 

プログラムの音色サイトの全面更新をしました

大体の作業が終わったので全面更新を報告したいと思います。

 

今回の全面更新とは?

結局何をやったか?というと…

サーバのOSレベルから更新作業を行いました。

このサイトを作ったときにVPSを契約してから…という場所まで戻るのですが、そのときに設定したのは(多分blogの記事を戻ればあるはずですが)CentOS6系統。さすがに今となってはかなり古いOSであることに加えてWordPressで動かすにはかなりの問題点が生じていました。それが各種Webプログラムのメジャーバージョンが簡単に上げられないということ。おかげでPHPは5.4系統を未だに使う羽目になっていてWordPress側でいろいろな警告がでるわ、バックエンドで動いているApacheのバージョンも2.2系統でこちらもいろいろとゆがみが出ているわ…という状態に。

というわけで、この2年間放置していたこともあり、全面更新を行い各種設定をやり直そうということで作業を行いました。

 

ちなみに、このサーバ自体が別物になっている

さすがに各システムの設定をすべて一発で間違えずに行うことはほぼ不可能ですし、ましてやCentOS6からのOS更新をしているのにダウンタイムを一切なしで乗り切るのは不可能ですので、今回は別のサーバを契約してそちらで環境構築を初期段階から行い、ほぼすべての設定が完了して見られる状態になったことを確認した上でDNSを切り替えるという手法で更新しています。なので、その間記事の更新などは一切できないのが弱点ですが、外から見ている人にはダウンタイムなしでつながっているように見える、ということをやっています。

なお、WordPressについては単にデータコピー&データベースの移動だけで済ませていますのでその意味でも見た目は全く変わりません。記事を書いている当人にも見た目の差は一切ない状態になっています。どうせならテーマを最新の物に変えるなどやった方がよいのかもしれませんが。

 

以降の記事はしばらくサーバ構築日記に

しばらくその手のの作業をしていなかった関係で新しくなっている部分がわからなかったり、一部設定で苦労したりということもありますので、これくらいのサイトをVPSで作るならどれくらいかかるのか?ということも紹介しながらしばらく記事を書いてみたいと思います。なお、サーバーを構築するのにかかった時間は実作業時間ベースならだいたい1日ほど、作業開始からいろいろな休憩やらほかの仕事やらをやっていながらの時間でいうなら3日ほどです。これを仕事にするにはちょっと微妙なところですが、そのあたりは解説サイトがいっぱいありますので探してみるといいかも。特にVPS関連はサービスが大分絞られてきたみたいで、前のようにまとめサイトを作る気にならない位の数しかありませんでした…。

 

伊勢神宮を参拝してきた

新年早々プログラムネタでもなく数学ネタでもなく教育ネタでもないただ単なる雑記です。しかも写真などもほぼ撮影していないのでただ単に参拝するところの紹介にしかなっていない記事です。

 

いろいろな場所にお社があるので考える必要あり

順序については「外宮」→「内宮」「御正宮」→「別宮」が習わしとされているようですので、御正宮の参道の近くにある別宮→少し離れたところにある別宮を考えると…

  1. 豊受大神宮(外宮)御正宮
  2. 豊受大神宮別宮(多賀宮、土宮、風宮)
  3. 豊受大神宮別宮(月夜見宮)
  4. 皇大神宮(内宮)御正宮
  5. 皇大神宮別宮(荒祭宮、風日祈宮)
  6. 皇大神宮別宮(月読宮、月読荒御魂宮、伊佐奈岐宮、伊佐奈弥宮)
  7. 皇大神宮別宮(倭姫宮)
  8. 皇大神宮別宮(伊雑宮、瀧原宮、瀧原竝宮)

という順序になる「かな~」というところです。曖昧な書き方になっているのは別宮が離れたところにある場合どのように参拝すると良いかが難しくなるからです。車の駐車場が簡単に確保できる日時なら良いのですが、そうではない場合、駐車してから車を動かさずに移動する必要があるため、歩いてそれほど距離がない月夜見宮ならまだいざ知らず、皇大神宮別宮は参道の近くにない神社ならそれなりの距離(例えば5→6なら1kmくらい)を歩く、もしくはバス移動となるのでちょっと厳しいのが弱点かな、と思います。

 

正月の規制で駐車&途中の移動をどうするかを考えるのが難しいことに

まずは外宮と内宮の移動がやっかいなんですね。外宮の駐車場なんてまともにあいている訳ではないですし、内宮の駐車場もさすがに厳しいところでした。一応パーク&バスライドが別の場所に設定されているのでそちらに止めてバス移動でもいいというのが今回はありがたかったところ。ただ、そうするとこのルートの場合パーク&バスライドの場合は直通なので3→4はOKですが、5→6→7の移動が一番厳しいことになるところです。ちなみに私はちゃんと歩きました。足がちょっとやばかったですが…。一応路線バスもあるのでそちらを使うことも考えて良いですが、その場合10分間隔くらいが目安なのでバスに乗り遅れると歩いた方が早いという結論に至ることも今回確認しました。路線バスでは交通系ICカードが使えるのでSuikaやICOCAあたりを用意しておけば小銭の心配もなく楽ですね。

 

そのほかの神社も参拝するとさらに大変に

例えば猿田彦神社とかですか。内宮からすぐの距離にあるので内宮を参拝した後で行く、というのもありだと思いますし、その他近場では二見浦の二見興玉神社に参拝してから外宮へ、という順番など突き詰めていくとなかなか大変な参拝になるよな~と言うところでした。

もう一つ大変だったことがお賽銭をどうするか、という問題です。別宮以外の社でも、となるとかなりの数になるので用意しておかないと簡単にそこをついてしまいます。補充したくても御札等、お土産等は大抵が100円単位なので人によっては微妙に感じることもありますし、こういう年末年始では細かいお賽銭を手に入れるために自動販売機で…と考えるパターンも多いようで周りの自動販売機は10円が釣り銭切れを起こす事態となっていましたし。いろいろと用意しておきましょう。

皆さんも初詣はどうでしょうか?

 

2019年は…

なんとか2018年も終わりを告げて2019年に入りました・・・

2018年はプログラマとしては全く動けなかった

プログラマ系統以外の仕事が忙しかったので全く動けませんでした・・・。WindowModePatchへの改良とか新しいゲームシステムの開発の種を作るとかいろいろとやりたかったことはあったのですが、それをするだけの時間が与えられませんでした。WindowModePatchの改良を望んでいる人から掲示板等に希望を書き込んでいただいたりされたのに希望に添えなくてすみませんでした。

2019年はかなり違う年になりそう

といっても今年度末まではあまり動きを見せることはできなさそうなのが残念なところ。年度が切り替わる前後からいよいよ本格的にプログラム系統の作業に着手する予定です。仕事として受け取ることもできる環境を整える予定でもありますし、プログラム系統の仕事ができなかった期間についていろいろと考えさせられる出来事も多かったので記事にできる内容であればそちらも記事にしてこのblogを復活させていこうかな、とも思っています。それで生活できるのか?といわれると?どうなのでしょうかね…。

2019年もどうぞよろしくお願いします。