さくらのレンタルサーバでSSH接続して環境を整える (AWS CLIをインストールするまで)

SSH接続ができるレンタルサーバーも増えてきました。
さくらのレンタルサーバもそのひとつ。
今回 AWS CLI を使いたいため、さくらのレンタルサーバ (スタンダードプラン) にSSH接続して、AWS CLIをインストールしてみました。

ターミナルでさくらのレンタルサーバにSSH接続。

さくらのレンタルサーバのサーバー環境は、

  • FreeBSD
  • 標準のシェルが csh
  • 標準のテキストエディタ vi
  • Python が 2.7.x

という環境です。

さくらのレンタルサーバは、git や WP-CLI もすでにインストール済みで結構使える。

まずは、環境を整える

  • 標準のシェルを bash
  • 標準のテキストエディタ vim

に変更。

ログインシェルを bash に変更する

chsh コマンドでログインシェルを bash に変更する

chsh -s /usr/local/bin/bash

設定ファイルを作る。

touch ~/.bash_profile
touch ~/.bashrc

.bash_profile の中身を書く。

vi ~/.bash_profile
if [ -f $HOME/.bashrc ]; then
    source $HOME/.bashrc
fi

PATH=$PATH:$HOME/bin:$HOME/usr/local/bin:$HOME/.local/bin
export PATH

一度ログアウトして再ログインする。
ログインシェルが bash に切り替わる。

標準のテキストエディタを vim に切り替える

which vim

すると、vim はすでにインストール済みなので。

.bashrc の中身を書く。

vi ~/.bashrc
alias vi='vim'

vim の設定を変える。ここはお好みで。

  • カーソルキーでカーソル移動ができるように (カーソルキーでABCDと入力になるのを避けるため、vi互換モードを off に。通常のカーソル移動は「h,j,k,l」)
  • バックスペースキー (Macだとdeleteキー) で文字を削除できるように

以上の設定は、.vimrc を作って。

touch ~/.vimrc
vi ~/.vimrc

以下を設定。

set nocompatible
set backspace=indent,eol,start

一度ログアウトして再ログインする。
以上、環境を整えた。

Pythonのパッケージ管理システム pip をインストール

AWS CLI は、pip経由でインストールするため。
まずは pip をユーザー権限でインストールします。

Pythonの設定ファイル .pydistutils.cfg を作って設定。

touch ~/.pydistutils.cfg
vi ~/.pydistutils.cfg
[install]
user=1

インストール先は、ユーザーディレクトリになるため
以下のPATHを .bash_profile に設定してあらかじめ PATH を通しておく。(この記事ではすでに通し済みです)

$HOME/.local/bin

インストールの準備が整ったところで、pip をインストール

easy_install pip

インストールが完了したところで。

pip -V

バージョンが表示されていたら無事完了。
以下が表示されるなら。PATHが通っていないかも。

pip: Command not found.
source ~/.bash_profile

で、bashの設定を再読み込みして再度確認。

以下でユーザーディレクトリにインストールされたことが確認できる。

which pip

/home/<user>/.local/bin/pip

AWS CLIをインストール

AWS CLIを pip 経由でユーザーディレクトリ先にインストール。

pip install awscli --upgrade --user

インストールが完了したところで確認。

aws --version

aws-cli/1.17.2 Python/2.7.16 FreeBSD/11.2-RELEASE-p14 botocore/1.14.2

インストール先も確認。

which aws

/home/<user>/.local/bin/aws

これで、さくらのレンタルサーバで AWS CLI が使えるようになった。

ログ監視ツール Logwatch を使ってみる (アップデート版)

以前の記事から Logwatch のコマンドが変わっていたので、再度書き直しました。

以前から変わったところは、出力のところ。
前は、logwatch --print とするだけで標準出力できましたが、
logwatch --output stdout と出力指定をする必要があります。

Logwatch は、いろいろなログをまとめて集計し、レポートとして毎日定期的にメールで届けてくれる。不正アクセスや不具合の発見とサーバの監視に便利なツール。

Logwatch のインストール

Logwatch は Perl で書かれていて Perl 5.8 以上が必要です。

yumからのインストールは、

$ yum install logwatch

で、

ソースからのインストールは、こちらから

Logwatch をインストールした時点で cron に登録されているので、毎日指定した時刻または anacronでランダムな時刻に Logwatch のスクリプト (/etc/cron.daily/0logwatch) が実行されてレポートが届く。

logwatch の設定

logwatch の設定は、/usr/share/logwatch/default.conf/logwatch.conf を編集する。標準設定のままで十分ですが、以下の項目を確認して設定。

#ログが保存されているディレクトリ
LogDir = /var/log
#メールの送信先
MailTo = user@hoge.com
#アーカイブされたログも含めるかどうか
Archives = Yes
#レポートの日付範囲を3つのオプションから。All, Today, Yesterday
Range = Yesterday
ログの詳細度、Low (=0), Med (=5), High (=10) または 0から10までの数字で
Detail = High
# チェックの対象となるサービスを /usr/share/logwatch/scripts/services/ 以下、あるいは All で指定。
Service = All
# メールコマンドパス
mailer = "/usr/sbin/sendmail -t"

サービスごとの個別設定は、/usr/share/logwatch/default.conf/services/ に用意されている。各サービスの設定ファイルを編集することで個別設定できる。

logwatch コマンドを使ってみる

標準出力

logwatch --output stdout

または、デフォルトで標準出力

logwatch

出力は、標準出力 (stdout) ほか、メール (mail) とファイル (file) への出力がある。

特定のサービスだけ出力

logwatch --output stdout --service http

複数のサービスにも

logwatch --output stdout --service http --service sshd

ログの詳細度を変えてみる

logwatch --output stdout --detail 10 --service http

メールに出力

logwatch --output mail --mailto user@hoge.com

ファイルに出力

logwatch --output file --filename /path/to/logwatch.txt

logwatch --help

Usage: /sbin/logwatch [--detail ] [--logfile ] [--output ]
   [--format ] [--encode ] [--numeric] [--no-oldfiles-log]
   [--mailto ] [--archives] [--range ] [--debug ]
   [--filename ] [--help|--usage] [--version] [--service ]
   [--hostformat ] [--hostlimit <host1,host2>] [--html_wrap ]

--detail : Report Detail Level - High, Med, Low or any #.
--logfile : *Name of a logfile definition to report on.
--logdir : Name of default directory where logs are stored.
--service : *Name of a service definition to report on.
--output : Report Output - stdout [default], mail, file.
--format : Report Format - text [default], html.
--encode : Enconding to use - none [default], base64.
--no-oldfiles-log: Suppress the logwatch log, which informs about the
                   old files in logwatch tmpdir.
--mailto : Mail report to .
--archives: Use archived log files too.
--filename : Used to specify they filename to save to. --filename  [Forces output to file].
--range : Date range: Yesterday, Today, All, Help
                             where help will describe additional options
--numeric: Display addresses numerically rather than symbolically and numerically
           (saves  a  nameserver address-to-name lookup).
--debug : Debug Level - High, Med, Low or any #.
--hostformat: Host Based Report Options - none [default], split, splitmail.
--hostlimit: Limit report to hostname - host1,host2.
--hostname: overwrites hostname
--html_wrap : Default is 80.
--version: Displays current version.
--help: This message.
--usage: Same as --help.
* = Switch can be specified multiple times...
</host1,host2>

関連サイト

WordPressをサーバH2Oで動かす (WordPressアプリケーションサーバとしてのH2O)

常時SSL とプロトコル HTTP/2 に対応するため、サーバ環境を新しくしてウェブサイトを移行しました。
新しい試みとしてサーバ構成を CentOS7 + PHP7 + MariaDB + H2O + WordPress にしてみました。

次世代の HTTPサーバ H2O を中心に速い WordPress を目指してサーバを構築。

今回 WordPress を HTTPサーバ H2O でどのように動かせばいいのか見てみたいと思います。

HTTPサーバ H2O とは

H2O は、プロトコル HTTP/2 に最適化されたウェブサーバです。

ここ数年でセキュリティ面で SSL が必須になりつつあり、ネット環境も新しい通信規約 (プロトコル) が求められている時代に最適なウェブサーバのひとつになっていくのだろうと注目していました。

H2O の開発は、2014年から元DNAの @kazuho さんが中心にオープンソースとして進められています。Perl を使っている方はウェブアプリを作るときに Server::Starter でお世話になっているのでは。ボクもいつもお世話になっています。
Server::Starter は、H2O のバックグラウンドにも使われていて start_server が動いているのが見て取れます。こういうところにも使われているのかとほんと感心しますね。

HTTP/2 時代を見据えているだけあってサーバの性能もベンチマークを見るとレスポンスが Apache や Nginx より速い。
他にも H2O の技術要素に注目したいものがたくさんあるのですが、詳しく知りたい方は、公式サイトやスライドも上がっているのでそちらを見ていただければと思います。

WordPress をサーバ H2O で動かす

2015年6月に FastCGI機能を実装したバージョン 1.3.0 がリリースされて、PHP が動くようになりました。
サーバ H2O で WordPress を動かすには、2 つの方法があります。

ひとつめは、WordPress を PHP-FPM や HHVM で管理。Nginx で従来やっている馴染みのあるやり方をそのまま踏襲。H2O も fastcgi.connect でホストに繋げてレスポンスを返してくれる。

今回採用したもう一個の方は、H2O 自体で管理する方法。
fastcgi.spawn で起動してH2Oの下で PHP のプロセスを管理してくれます。
PHP-FPM や HHVM をインストールしてコンフィグの設定起動、運用の手間がなくなります。

今回の試みとして思っていたことで、
WordPress とかPHPアプリを動かすアプリケーションサーバとしてH2Oは、最適なんじゃないかなぁと。

実際 H2O の下に php-cgi が動いているのが見て取れます。

WordPress を動かすサーバ設定 (/etc/h2o/h2o.conf) もYAML書式でシンプルに書けます。

以下これだけでWordPressが動きます。

paths:
  "/":
    file.dir: /path/to/wordpress
    redirect:
      url: /index.php/
      internal: YES
      status: 307
    file.custom-handler:
      extension: .php
      fastcgi.spawn: "PHP_FCGI_CHILDREN=10 exec /usr/bin/php-cgi"

実にシンプル。YAMLでわかりやすいのがいいですね。(本番運用には、自動更新やダッシュボードへのアクセスのところでもう少し手を入れる必要があるのですが。)

で今回の試したサーバ設定は、

  • 常時SSL
  • www にURL正規化
  • http から https にリダイレクト
  • WordPress ツールバーからダッシュボード (www.example.com/wp-admin/) へアクセス
  • WordPressの自動更新ができるように
  • FastCGI のスループットチューニング
  • 他もろもろ

で以下のような本番運用サーバ設定 (/etc/h2o/h2o.conf) になりました。

user: nobody
 
listen:
  port: 80
listen:
  port: 443
  ssl:
    certificate-file: /path/to/fullchain.pem
    key-file: /path/to/privkey.pem
 
hosts:
  "localhost":
    paths:
      "/":
      redirect:
        status: 301
        url: https://www.example.com/
 
  "www.example.com:80":
    paths:
    "/":
      redirect: https://www.example.com/
  "www.example.com:443":
    paths:
      "/":
        file.dir: /var/www/wordpress
        redirect:
          url: /index.php/
          internal: YES
          status: 307
 
file.index: [ 'index.php', 'index.html' ]
 
file.custom-handler:
  extension: .php
  fastcgi.spawn:
    command: "PHP_FCGI_CHILDREN=10 exec /usr/bin/php-cgi"
    user: example
  fastcgi.timeout.keepalive: 10000
 
access-log: "| exec sudo rotatelogs /var/log/h2o/access.log.%Y%m%d 86400"
error-log:  "| exec sudo rotatelogs /var/log/h2o/error.log.%Y%m%d 86400"
 
pid-file: /var/run/h2o/h2o.pid
http1-upgrade-to-http2: ON
http2-reprioritize-blocking-assets: ON

WordPressを動かすH2Oサーバ設定のポイント

WordPress ツールバーからダッシュボード (www.example.com/wp-admin/) へアクセス

通常の設定では、WordPress ツールバーからダッシュボード (www.example.com/wp-admin/) へアクセスは、トップページを返してしまいます。

ダッシュボードにアクセスできるように file.index で index.php を追加して www.example.com/wp-admin/ で www.example.com/wp-admin/index.php にアクセスするようにしました。

WordPressの自動更新ができるように

H2O はデフォルトで nobody の下で動きます。
H2Oの管理下にある PHP も nobody で動きます。
WordPressの自動更新は、WordPressのファイル所有者の下でPHPが動かないと自動更新が働きません。
fastcgi.spawn には、どのユーザ user で動かすか指定できるので、WordPressのファイル所有者を指定して動かします。

FastCGI のスループットチューニング

fastcgi.spawn での PHP への接続は、デフォルトでは1回限りの接続です。これだとWordPressが動くたびにコネクションが発生します。
fastcgi.timeout.keepalive で Keep-Aliveを 10 秒に指定。一定時間 FastCGI の接続を継続させてスループットを改善してみました。

まだまだキャッシュ周りやいろいろチューニングができそうなので、運営しつつ試してみたいと思います。

参考サイト

sudo「コマンドが見つかりません」PATHが初期化されているときの対処法

sudo でコマンドを実行すると、「command not found」とエラーに。環境変数 PATH が通っていないと思って設定しても変わらず。実は sudoers の設定でセキュリティ上環境変数が初期化されている。そのときの対処備忘メモ。

現象

  1. sudo でコマンドを実行
  2. 「command not found」 (コマンドが見つかりません) とエラーに
  3. .bash_profile にパスを設定してみる
    vi ~/.bash_profile
    
    PATH=$PATH:$HOME/bin:/sbin:/usr/sbin
    

    から

    PATH=$PATH:$HOME/bin:/sbin:/usr/sbin:/usr/local/bin
    

    に変更。

  4. sudo でコマンドを実行
  5. 再び「command not found」 (コマンドが見つかりません) とエラーでパスが通っていない

さらに突き詰めると、

sudoers の env_reset オプションが有効になっている

原因

sudoers の env_reset オプションが有効になっている場合、セキュリティ上環境変数が初期化されて secure_path に設定しているパスが使われるので、環境変数 PATH が通らない。

解決

3つの方法でパスを通す

sudoers はデフォルトでは env_reset オプションが有効になっている。無効化するか、環境変数を引き継ぐか、または secure_path にパスを設定することで環境変数 PATH を通す。

sudoers は visudo コマンドで編集できる。設定が間違っていたらエラーチェックもしてくれるので、直接ファイルを編集することは控える。

1. 無効化する場合

コメントアウトして env_reset オプションを無効化。

#Defaults env_reset

2. 環境変数を引き継ぐ場合

以下を追記

Defaults env_keep += "PATH"

そして以下をコメントアウト

#Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

.bash_profile に設定したパスが通ります。

3. パスを設定する場合

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

から

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin

に変更してパスを追加

sudo でコマンドを実行して確認。
complete!!

教訓

環境変数 PATH の設定の他、env_reset が有効化されているかどうかも確認しよう。

関連サイト

「#!/usr/bin/perl –」はFTP転送モードの問題? 実はFTPサーバ設定の問題

Perl のパス 「#!/usr/bin/perl -w」では正常に動くのに、「#!/usr/bin/perl」では「Internal Server Error」に。

cgiスクリプトの記述や設定が正しくなかったり、サーバ内部でエラーが発生した場合に返されるのが「Internal Server Error (HTTPステータスコード500)」。エラーがあるのは分かるが、原因がわからない、Webエンジニアにとって頭を悩ます「Internal Server Error」。

その原因も様々。原因が明らかにできなければ対策も解決もできない。Perl パスの問題かと思いきや、FTPの転送モードの問題?、実はFTP サーバ設定の問題というちょっと複雑。そんな問題に直面した備忘メモ。

現象

  1. FTP を使ってアスキーモードでファイルをアップロード
  2. Perl のパス 「#!/usr/bin/perl」 では cgi が 「Internal Server Error (HTTPステータスコード500)」に
  3. Perl のパス 「#!/usr/bin/perl -w」 または 「#!/usr/bin/perl --」 では正常に動作する
  4. 改行コードが問題と思ってファイルの改行コードを「LF」に変換
  5. 再度、FTP を使ってアスキーモードでファイルをアップロードしても同じ現象に
  6. 「あれれ」無限ループにはまる。

さらに突き詰めると、

シェル上でスクリプトを走らせると、

/usr/bin/perl^M: bad interpreter: No such file or directory

とエラーに

さらに突き詰めると、

FTP サーバに vsftpd を使っている

原因

FTP サーバ vsftpd では、ファイルの改行コードが変換されないこと。

解決

改行コードを「LF」に変換するだけという、単純なものではありません。

実際は、ファイルをアスキーモードでFTPアップロードしても、改行コード「LF」に変換されません。

それは、FTP サーバ vsftpd ではアスキーモードでのダウンロード・アップロードのデフォルト設定が無効になっているから。

ということで vsftpd の設定をしてみる。

1. vsftpd の設定をする

シェル上で vsftpd.conf を編集。

vi /etc/vsftpd/vsftpd.conf

設定内容を

ascii_download_enable=NO
ascii_upload_enable=NO

から

ascii_download_enable=YES
ascii_upload_enable=YES

に変更して有効に

2. vsftpdを再起動

service vsftpd restart

3. ファイルを再度アップロードする

4. 確認。Perl のパス「#!/usr/bin/perl」でうまく表示できた。

complete!!

教訓

FTPの転送間違えの他、視野を広げてFTP サーバの設定も診てみよう。

関連サイト

最近の投稿

カテゴリー

アーカイブ