クエリーログでサーバが容量不足に

さくらVPSで使っているDebianのサーバにログインしたところドライブの空き容量が無いと警告が表示された。容量の大きいファイルを検索したところ /var/log/mysql.log35GB になっていた。

契約しているのは50GBのプランで df -h コマンドだと46GBの容量と表示される。つまり容量の7割をmysqlのログファイルで占めていたことになる。このログファイルと不必要なバックアップファイルを5GBほど削除し、整理したところ空き容量ゼロの状態から空き容量38GBに落ち着いた。

原因

  • クエリログの出力が有効になっていた
  • クエリログの出力先が /var/log/mysql.log になっていた
  • /etc/logrotate.d/mysql-server が参照するファイルが /var/log/mysql/mysql.log であったためログファイルがローテートされていなかった

クエリログについては何かのトラブルの調査で出力するように設定して、そのままになっていたのではないかと思っている。基本的に dotdeb のパッケージでインストールした my.cnf をベースに設定していたはずなのでいつの間にか出力先が /var/log/mysql/*.log に変わってログローテートの対象から漏れたのかもしれない。

年末年始でパッケージをアップデートしておこうかと思ってログインして気がついて良かった。パッケージを大きくバージョンアップするときにはパッケージのデフォルトの設定ファイルと現行の設定ファイルを比較すべきだし、そうしていたつもりだが、ログファイルのパスなど機能の動作を変える設定ではないものは見落としがちだ。

Raspberry PiのLANがとんだ

自宅サーバとして使っていたRaspberry PiのLANが止まってしまったのでSDカードだけ付け替えて復旧した。

外からサーバに接続できなかったので最初はハングしているのかと思ったけど、電源を入れ直して再起動しても接続できず。ディスプレイを繋ぐとちゃんとOSは起動しており、ネットワークがつながっていない状態であることがわかった。それからLANケーブルを繋ぎ直したり、別のLANケーブルに交換してみてもつながらないのでRaspberry PiのLANポートがお亡くなりになったと判断。

自宅サーバで使っていたRaspberry PiはB+で、このタイミングではModel 2やModel 3に置き換えることも考えたが特にModel B+で困っていることもなく、また1からセットアップしてデータを移行するのも面倒なので、バックアップ用に取っておいた新品のRaspberry Pi B+に壊れたRaspberry PiのSDカードを指したら普通に稼働再開できた。

Raspberry Piは製造している会社によって微妙に違うのでもしかしたら別のRasbperry PiのSDカードでもダメなケースがあるかもしれないが、今回は両方ともRSコンポーネンツ製だった。こんな簡単に故障から復旧できるのは素晴らしいが、逆にSDカードが死んだらこの方法は使えないので、SDカードを選ぶ際はあまり妥協しないほうが良いと思った。

今更 Debian Jessie

1年前に計画したJessie(Debian 8)へのアップグレード計画をようやく実行。

このblogを運用しているサーバはChefで構築していて、レシピの動作確認と開発環境を兼ねてVagrantでローカルのVirtualBoxの仮想環境に同じものを構築している。

ということでローカルの仮想環境で気兼ねなくアップグレードの練習をして、アップグレード手順を作ってから一気にこの運用サーバを更新した。Vagrant 1.8からsnapshot機能が標準で用意され3rd party製プラグインに使わなくても仮想環境の状態をそのまま保存・復元できるようになり、アップグレード前の状態を保存しておけば繰り返しアップグレードの練習ができるのも安心できるところ。結局、1回で上手く言ったので復元はしていないが。

はまって手順で対応したところ

  • 時間表示がUTCになっている → cp -p /usr/share/zoneinfo/Japan /etc/localtime
  • WordPressが動かない → php5-fpmphp7.0-fpmでsocketの待ち受けPATHが変わっていたのでnginxの設定を変更
  • Ruby 2.3.3にしたらChefのdatabasecookbookがmysql2 gemがなくて動かない → mysql2 gemインストール

基本、全部Chefのレシピで対応したので新規のインストールでも大丈夫なはず。

そうこうしているうちにDebian 9もリリースされてしまうのだが、今回はDebianのバージョンアップというよりPHP7に移行するのが目的だった。DotdebリポジトリからPHP7はJessie向けにしか提供されていないため。Debian 8も暫くサポートされるだろうから必要がある時にアップグレードすればよいだろう。

  • Debian 7.11 -> 8.6
  • PHP 5.5.38 -> 7.0.14
  • Ruby 1.9.3 -> 2.3.3
  • MySQL 5.6.35 -> MariaDB 10.0.28

とりあえず以上のようにアップグレードした。rbenvで入れているのでJessie関係ないがRubyを2.3.3にあげた。最近Redmineをバージョンアップする度にRedmineの依存パッケージがRuby 2.0以上を必要として運用に苦しんでいたので2.3.3にした。クリスマスに2.4がリリースされていたがアップグレードした時点ではRedmineのホームページの対応rubyバージョンに2.4が載っていないのでひとまず2.3系にした。

PHPにはOpcacheもついでに入れてみた。いろいろ速くなったような気もするし、気のせいかもしれない。そもそも自分のブログをアクセスして読まないのでよくわからない。

サーバ証明書が更新されていなかった件

Let’s Encryptで取得したサーバ証明書がうまく自動更新できてていなかった。なお環境はDebian 7。

期限が20日と10日を切ると Let's Encrypt certificate expiration noticeという件名で期限が近いことをメールで知らせてくれた。ありがたい。

単にcronの設定を初歩的なミスで間違えていただけ。/etc/cron.d/certbotにchefでファイルを置くという運用をしていたが、個別のファイルにしたこともあってユーザのcrontabの設定と間違えてコマンドの実行ユーザを指定していなかった。それを直した次の日もcronはうまく実行できず、/usr/local/binにPATHが通ってなかったのでcertbot-autoコマンドが実行できていなかった。

とりあえず期限が迫ってきたのでおとなしく手動で実行したが、何故かaptnginxのパッケージの更新実行されて対話が必要だった。--no-self-upgradeを付けてもかわらなった。nginxが最新じゃないとだめだったりするのだろうか。

最新のドキュメント(Debian+Nginx)を見ると自動化はcronで以下の設定をしろと書いてある。見落としていたのか、いつの間にかコマンドが増えていたのか。

./path/to/certbot-auto renew --quiet --no-self-upgrade

ただ --force-renewal をつけてみたけどやっぱりnginxをreloadしないと反映されなかったので最終的に以下の設定にした。このブログは週末にアクセスが減るので日曜日に更新しておけばよいと思っている。

PATH=/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0 5 * * 0 root certbot-auto renew --quiet --no-self-upgrade --post-hook "service nginx reload"

最初は && service nginx reload で繋いでいたけどrenewコマンドはデフォルトだと期限が近いもの(30日以内)しか更新されない。無駄なNginxの再読込が実行されてしまう恐れがあるので--post hookを使うのが良さげ。

Raspberry PiのDirty COW対応

基本的に自宅サーバとして使っているRaspbery Piは家の外のネットワークからはつながらないようにしているつもりだが一応Dirty COW対応した。

Dirty COWは管理者権限を取られてしまう恐れのあるLinuxカーネルの脆弱性で、LinuxベースのOSで漏れなく発生しているためDebianベースなRaspbianも例外ではない。Raspberry Piの用途はサーバであったり、デスクトップPCであったり、IoTであったり様々だと思うがそれなりに数が出ているので狙われる恐れがある。

Dirty COWの対応記事は Fix Dirty COW on the Raspberry Pi にあり、以下の対応策が書かれている。

sudo apt-get update
sudo apt-get install raspberrypi-kernel

自分のjessie環境では apt-get updateraspberrypi-kernel は更新されていたので明示的なインストールが必要な環境があるのかはよくわからない。

気になるのは該当記事に問題が起きる環境と修正された環境の確認方法が書いていないということである。これはコメントに書いてくれている人がいて 4.4.26 kernel 以上になっていれば良いとのこと。再起動後に uname -mrs などのコマンドで確認できる。

軒並みアップデートしたが、それなりに非力なPCであるので暫くアップデートしていないRaspbery Piでは apt-get update にかなりの時間を要した。

https化の道その2

前回はLet’s Encryptの証明書を入れた。今回はmakotokw.comのコンテンツをhttpsに対応し、httpへのアクセスをhttpsにリダイレクトするようにした。

GitHubのBadgeでoctocard使っていたのだけど、これがhttps対応していないで諦めて直接GitHubのAPIをjsonpで処理して表示するようにした。

ブログのRSSからコンテンツの要約をトップで表示しているけど画像のリンクをhttpsにするためkwLogでAmazonJSのhttps版をこっそり運用している。

その他細々とした画像やフォントのurlをhttpsに変えていった。このブログはコンテンツが多いので画像のリンクなどを直すのが大変そうである。何かhttpsじゃないリンクをチェックしてくれるツールを探した方が良さそうな予感。

HTTPS化の開始

Let’s Encrypt

自分で持っているドメインのサイトのHTTLS化を始めることにした。今までは限定でSmartSSLで証明書を取得していたが、無料でサーバ証明書が取れ、更新が自動で更新できるLet’s Encryptをようやく調べることにした。

サーバ証明書の取得、更新が行えるクライアントソフトウェア certbot が公開されており、OSやブラウザを選んで書いてある設定の通りやった。

certbotのフロー

今まではPC(Mac)でサーバ証明書を取得してそれをchefをつかってサーバに配信するというフローでやっていたが、certbotの場合は運用環境で行う必要がある。というのもサーバー証明書の取得のコマンドは

certbot certonly --webroot -w /var/www/example -d example.com

という記述にになっており、ドキュメントルートを指定する必要がある。

何故かというとcertbotがドキュメントルート以下に.well-known/acme-challenge/xxxxx のようなファイルを一時的に作成し、それを外部からアクセスできるかどうかでドメインの所有者かどうかを判断している。ちなみに.で始まるファイルのアクセスを拒否していると証明書の取得に失敗するので注意が必要。

この方法だと複数台サーバがあると面倒になると思う。.well-known以下へのアクセスはcertbotを実行しているサーバそのサーバに振るみたいなルーティングをしないといけない。そもそも外部からアクセスできる運用サーバで実行しないといけない事自体が面倒。

いろいろ考えたがそんな複数サーバで構成するような規模感のサイトはおとなしく有料のサーバ証明書を買い、更新しろということなのではないかと思った。Let’s Encryptは個人ブログなどサーバ証明書を買うほどではないサイトがHTTPS化対応していくためのサポートなのだと理解する。

HTTLS化の道

サーバ証明書は取得してWebサーバには設定済み。ただHTTLS化の道はまだ長い。

サイトをHTTLS化にするにはサイトが参照する外部のjavascript, image, css, webfontなどの外部リソースもHTTPS化しないといけなく、自分の力だけではどうしようも行かないこともある。

それらの対応が終わったらHTTPのアクセスをHTTPSにリダイレクトする設定にもしないといけない。サーバ証明書の取得が簡単になったとは言えまだそこまで気軽にできることではないが、いろんなサイトがHTTPS化していけばこれらの問題も解決していくだろう。

Raspberry PiをJessieにアップグレード

自宅サーバと課しているRaspberry PiのJessie(Debian 8ベースのRaspbian)にアップグレードした。JessieはDebianのコードネームで従来よりToy Storyから採用されている。

基本的な流れは

  • wheezyを最新にする sudo apt-get upgrade; sudo apt-get dist-upgrade
  • source.listをwheezyからjessieに書き換える
  • Jessieに更新する sudo apt-get upgrade; sudo apt-get dist-upgradeする

と、Debianの更新手順と特に変わらない。

source.listの書き換えで

エラー http://raspberrypi.collabora.com jessie/rpi armhf Packages

と見つからないソースリストがあったのでコメントアウトした。Office系のソフトっぽいし、無くても支障はないだろう。

Jessieの更新は2時間くらいかかった(Raspberry Pi 2 Model BでWiFi接続)。パッケージの更新に伴う設定ファイルの確認で何回か対話処理が必要で画面が止まっていたのでもう少し短いかもしれないが。JessieでRubyが2.1になった。今やRuby 2.1でも古いがwheezyが1.9.3だったのでとても新しくなったと感じてしまう。

ちなみにRaspbianにはrpi-updateというコマンドがありファームウェアの更新ができるそうなのでやっておくと良い。

sudo rpi-update

Debian Jessie with Dotdebアップグレード計画

このブログはこの投稿を書いている時点ではさくらのVPSを借りて、Debian 7 Wheezyで運用している。

stableのディストリビューションのnginxやphpのバージョンが低いので、ブログの高速化をいろいろ考えて Dotdeb を使っていた。Debian 8 Jessieは去年リリースされていたが特に変える理由もなかったのでアップグレードしていなかった。

最近 PHP7がリリースされてWordPressが二倍速くなるとかならないとかという話がある。DotdebではJessie向けにPHP7を用意してくれている(Wheezy向けには対応されない方針)のでまず第1段階としてJessieにアップグレードしたい。

Jessieのディストリビューションでは以下のパッケージのバージョンがある。括弧はこれを書いている時点のバージョン。

  • PHP 5.6.7 (5.6.14)
  • MariaDB 10.0.16(10.0.22) と MySQL 5.5.42 (5.5.46)
  • Nginx 1.6.2

これに対して、今のWheezy + dotdeb + detdeb/php55なこのサーバの環境は以下のようになっている。

  • PHP 5.5.30 (Dotdeb)
  • MySQL 5.6.25 (Dotdeb)
  • Nginx 1.8.0 (Dotdeb)

PHPのバージョンが低く、MySQLとNginxのバージョンはJessieのディストリビューションより高いものが入っている。DotdebのJessieへの対応状況を調べた所、

  • PHP 7.0.2
    • PHP 5は対応しない
  • MySQLは対応しない
  • Nginx 1.8.0

となっている。

Dotdebの作者はPHP 5系を使いたいならJessieのPHP 5.6を使ってくれ、MySQLに関してはMariaDBにスイッチしてくれということで、Jessie向けにはPHP5とMySQLを対応しないことを明確にしている。

今はPHP5.5を使っているのでPHPはバージョンアップになるので良いが、MySQLに関してはMariaDB 10.0に移行する必要がある。まとめると各パッケージは以下のようになってDotdebからインストールするパッケージはNginxだけ残る。

パッケージ 現在のバージョン 第1段階(Jessie) 第2段階(PHP7)
PHP 5.5.30 (Dotdeb) 5.6.14 (Jessie) 7.0 (Dotdeb)
MySQL MySQL 5.6.25(Dotdeb) MariaDB 10.0.22 (Jessie) そのまま
Nginx 1.8.0 (Dotdeb) そのまま そのまま

基本的にMySQLとMardiaDBは互換性があるから大丈夫だと思うが、面倒なことにWheezyのディストリビューションにはMariaDBが無さそうなため

  • MySQLをアンインストール
  • Jessieにアップグレード
  • MariaDBをインストール

のようなステップがいるかも。

アップグレードに失敗したらその間ブログは止まることになるのでまずは仮想環境で試してからになりそう。

第9回redmine.tokyo勉強会

redmine.tokyo勉強会に参加した。今回で9回目ということだったんだけど、今までそんな勉強会が存在することは知らなかった。

参加したセッションのメモはこちら
第9回redmine.tokyo勉強会 2015/11/27

収穫

Lychee Redmine

アジャイルウェアの川端さんがセッションで紹介していたもの。有償だけどガントチャートの管理が便利そうなプラグイン。依然、似たようなプラグインを探したことがあったけど有償は除外していたのであまり知らなかった。

Redmineのプラグインはバージョンによって動かなくなっていることが多く、GitHubにあるものは誰かがForkして動くようにしているけどFork元の本家にはPRする文化はあまり無さそうな気がしていて亜流がいっぱいあってよくわからなくなっていることが多い。そういう状態だから自分もForkしてとりあえず動くようにして使うという悪循環になっているので、有償でもちゃんとメンテナンスしてくれるものを使ったほうが良いのかもしれない。

Redmine 3.2 レスポンスデザイン

@naitohさんのRedmine最新動向のセッションで、3.2でいろいろ改善されることを聞いた。レスポンスデザインになるそうで、自作のテーマにも影響がでてくるかもしれないので要確認。

View Customize Plugin

onozaty/redmine-view-customize

@onozatyさんがLTで紹介していたもの。任意の画面にcssやjavascriptを画面をカスタマイズできるプラグイン。テーマを使わなくても使えるので痒いところに手が届きそう。

開発プロセス

勉強会ではRedmineというツールの話、Redmineを使った開発プロセスの話が混ざってくることが興味深かった。チケット駆動開発の話や、どこまでをチケットで管理するかなどの話は悩みの種であるので共感できる話は多い。

ただ正直なところ個人的にはRedmine自体を管理するのが面倒だし、新しいものを使いたいのでGitHub Enterprise使ってGitHub FlowとかPR駆動開発とかやりたかったりする。

とはいえどんなツールを使っても、どんな開発プロセスを導入しようとも、人が絡んでソフトウェアを開発する以上、ためになる話はいいっぱい聞ける気がする。

コンテキスト

Redmineの管理者が多く参加されていたので、コンテキストが近くディスカッションなども機能するのかなと思った。

イベント&コミュニティスペース dots.

dotsさんのイベント&コミュニティスペースが会場だったんだけど、近いし、イベント開催以外でも貸し切りじゃないときはコワーキングスペースとしても使えるらしい。

コース 料金(税込)
1時間 500 円
3時間 1,300 円
5時間 2,000 円
終日 2,500 円