RailsアプリをLet's Encryptで常時SSL化する方法

f:id:boost-up:20171214003033j:plain

常時SSLはもはや現代の常識!?

今を遡ること3年前、2014年のことになりますが、GoogleがSSL化されたサイトをサーチエンジンがポジティブに評価することを発表して以来、新しくWebサービスを作る場合にはSSL化することが必須タスクの一つになってきました。

私が運営するWebサービスでは、今年2017年に立ち上げたSCDB JAPANはサービス開始当時から常時SSL化の対応を行っていますが、2014年から運営している上場企業サーチ.comはユーザが情報を登録する機能を実装していないこともあり、これまでSSL対応が出来ていませんでした。

Let's Encryptの登場

従来、WebサイトのSSL化を実現するためには、認証局に対してお金を払ってサーバ証明書を発行してもらう必要がありました。 このコストは最も安いものでも年間数千円必要であり、個人が格安のレンタルサーバで運営しているような小規模なWebサイトでは無視できないケースもあったのではないかと思います。 また、証明書の発行を申請するためには、サーバにOSログインして証明書署名要求(CSR( Certificate Signing Request ))を作成する必要があり、若干のハードルがありますので、対応できずにいたWebサイト運営者もいたのではないかと思います。

そんな中、2016年に登場したLet's Encryptは通信の暗号化に特化した無料のSSL証明書発行サービスです。

ドメインを認証するDV認証にしか対応しておらず、発行される証明書の有効期限が3ヶ月と短く定期的に更新手続きが必要にはなるものの、サーバのルート権限を持っている管理者であれば簡単な操作で署名済みの秘密鍵(KEY)と公開鍵(CRT)を入手することができます。

今回、上場企業サーチ.comに導入しましたので、以下ではその手順を紹介します。 OSはCentOS7.3になります。

Let's Encryptのインストール

1.epelリポジトリを有効にしてcertbotをインストールします。

sudo yum install epel-release
sudo yum install certbot

2.certbotのコマンドを実行してサーバ証明書を作成する

path-to-rootにはRailsアプリのルートディレクトリを指定します。

certbot certonly --webroot -w path-to-root -d xn--vckya7nx51ik9ay55a3l3a.com

私は上記のコマンドを実行したところ、次のエラーが発生しました。

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for xn--vckya7nx51ik9ay55a3l3a.com
Using the webroot path *** for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. xn--vckya7nx51ik9ay55a3l3a.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://xn--vckya7nx51ik9ay55a3l3a.com/.well-known/acme-challenge/NLgdUKK3PeaxTjwbURWZYmidDjUDfoLs61aAOggMjiQ [210.140.40.129]: 404

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: xn--vckya7nx51ik9ay55a3l3a.com
   Type:   unauthorized
   Detail: Invalid response from
   http://xn--vckya7nx51ik9ay55a3l3a.com/.well-known/acme-challenge/NLgdUKK3PeaxTjwbURWZYmidDjUDfoLs61aAOggMjiQ
   [210.140.40.129]: 404

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.

エラーメッセージを見る限り、サーバ直下に作成される.well-knownディレクトリにインターネットからアクセスしようとして404エラーが出たことが問題のようです。 Let's EncryptはSSL化しようとしているサーバに作ったファイルに外部からアクセスできることをもって、実在性の確認を行っているようです。

3..well-knownへのアクセスを許可する

上場企業サーチ.comはRailsで構築しており、publicフォルダ内に置いた静的ファイル以外はunicornに渡す設定にしているのですが、 .well-knownはpublic外にあり、当然ながらルーティングも設定されていないため、設定上正しい動きとして404になります。

今回、WebサーバにはH2Oを使っていますので、h2o.confに下記の末尾2行を追加してサービスを再起動します。

  "xn--vckya7nx51ik9ay55a3l3a.com:80":
    listen:
      port: 80
      host: 0.0.0.0
    paths:
      "/.well-known":
        file.dir: path-to-root/.well-known/

4.改めて、certbotのコマンドを実行してサーバ証明書を作成する

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for xn--vckya7nx51ik9ay55a3l3a.com
Using the webroot path *** for all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/xn--vckya7nx51ik9ay55a3l3a.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/xn--vckya7nx51ik9ay55a3l3a.com/privkey.pem
   Your cert will expire on 2018-03-12. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

今度は上手くいきました。 fullchain.pemが公開鍵、privkey.pemが秘密鍵になりますので、適切な場所に保管します。

5.h2o.confにSSL接続の設定を追加する

  "xn--vckya7nx51ik9ay55a3l3a.com:443":
    listen:
      port: 443
      host: 0.0.0.0
      ssl:
        certificate-file: "path-to-fullchain.pem"
        key-file: "path-to-privkey.pem"
        cipher-suite: "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"
        cipher-preference: server

ポート443の設定を追加します。 certificate-filekey-fileには先ほど作成した公開鍵と秘密鍵のパスを指定します。 cipher-suitecipher-preferenceはなくても動きますが、脆弱な暗号方式を使わないようにするための設定です。

設定後、h2oサービスを再起動するとSSL通信が可能となります。

6.その他

今回は詳しくは触れませんが、上記まででSSL接続ができないときは、ファイヤーウォールでインバウンド443が空いているかを確認してください。 それから、80ポート(HTTP)へのアクセスを443ポートにリダイレクトしておいた方が良いと思いますので、適宜この設定も追加してください。

7.おまけ

昔から慣れているので今でもSSLと言ってしまいますが、暗号化方式としてSSLは既に時代遅れと言われており、世の中的にはTLS通信に移行が進んでいます。

上で書いた5.のcipher-suiteのところで、頭に"!"が付いているのはそのアルゴリズムを「許可しない」ことを意味するのですが、今回の設定ではSSLを軒並み拒否しています。

冒頭で「常時SSLは世の中の常識!?」とまで書きましたが、正しくは「常時TLSは世の中の常識!?」ですね。

bootstrapを使ったモバイル画面で幅が100%にならずに「ぐらぐら」する件

bootstrapを使ってコーディングしたページをモバイルで表示したとき、横幅がきっかり100%にならずに「ぐらぐら」する場合があります。

↓ちょっとわかりにくいですが、こういうやつです。

f:id:boost-up:20171212220135p:plainf:id:boost-up:20171212220121j:plain
スワイプするとぐらぐるするWebページのスクリーンショット

SCDB JAPANでも以前から発生していることを認識はしていながら、これまで放置しておりましたが、 ようやく対応が完了しましたので対応方法を共有します。

ぐらぐらの原因は何だったのか?

グリッドシステムのrowにはマイナスのmargin(ネガティブマージン)が設定されており、これが要素を左右に引っ張っているために親要素を突き破っていたことが原因でした。

修正前の状況

横幅320pxの画面で表示した場合の状況なのですが、親要素が307.2pxなのに対して、子要素で左右-15ずつのmarginが取られたことによりコンテンツが307.2px+15px+15px=337.2pxとなり、画面サイズの320pxをオーバーしてしまっています。

【親要素】 f:id:boost-up:20171212221929p:plain

【子要素(rowが設定されている要素)】 f:id:boost-up:20171212222200p:plain

修正内容

親要素のpaddingに左右それぞれ+15pxを取り、子要素のネガティブマージンと相殺しました。

.parent-element{
  padding-left: 15px;
  padding-right: 15px;
}

【親要素】 f:id:boost-up:20171212222806p:plain 左右にpaddingを取ったため、コンテンツの幅が同じだけ狭くなりました。

【子要素(rowが設定されている要素)】 f:id:boost-up:20171212222830p:plain ネガティブマージン自体はそのままですが、親要素が狭くなったことで子要素も同じだけ狭くなっており、320px以内に収まるようになりました。

<経過観察中>RapidSSLで認証したSSLサーバ証明書を使っているサーバにChromeでアクセスすると警告がでる件

f:id:boost-up:20171211234910j:plain

既に数か月前から騒がれている話ですが、GoogleがSymantec系のサーバ証明書に対する信頼を落としており、Thawte、VeriSign、Equifax、GeoTrust、RapidSSLといったSymantec系のサーバ証明書を使っているサーバは証明書の再発行、再署名といった対応が求められる可能性が高い状況です。 forest.watch.impress.co.jp

SCDB JAPANはRapidSSLを使っており、今日現在ChromeでアクセスするとConsoleに以下のような警告が表示される状況です。 (この情報は、モダンブラウザを数クリックすれば誰でも確認できるので隠す程のことではありません。)

f:id:boost-up:20171211230802p:plain

RapidSSLのWebサイトの情報

www.rapid-ssl.jp

RapidSSLのサイトによるとサーバ証明書の「発行日」と「有効期限」の組み合わせによって、必要な対応が変わってくるそうです。

対象・対応と日程:

1.2016年6月1日より前に発行された証明書(Google Chrome66よりSSLサーバ証明書が無効化されます)
① 有効期限が2018年3月14日以前:対応不要
② 有効期限が2018年3月15日以降:2018年1月~3月までに再発行

2.2016年6月1日より後且つ2017年12月より前に発行された証明書(Google Chrome70よりSSLサーバ証明書が無効化されます)
① 有効期限が2018年9月12日以前:対応不要
② 有効期限が2018年9月13日以降:2018年1月~9月までに再発行

scdb.jpのサーバ証明書は次の通り、発行日が2017/2/25、有効期限が2020/2/26ですので、上記の2-②のパターンに該当します。

f:id:boost-up:20171211232305p:plain

来年まで悠長なことを言わずに今すぐ再発行できないのかと考え、契約したRapidSSLの販売代理店に問い合わせたところ「来年2月頃に再発行をご案内します」との回答。

仕方がないのでとりあえず忘れないようにここに備忘を残し、時が来るのを待つことにしたいと思います。

余談

SSL化の目的は主に、通信経路を暗号化することと、運営者に対する第三者証明の2つがあります(それ以外にも、SEOの観点でも加点要素と言われています)。 後者については、ドメイン認証、企業認証、EV認証という三段階の認証基準があり、どれを採用するかでコストも認証の難易度もかなり変わってくるのですが、実は暗号化レベルは基本的に一緒です。

私は今のところはドメイン認証ができれば十分なので、コスト的に最もお手軽なRapidSSLを使っているのですが、それでもこれまでは少なからず対価を支払う必要がありました。

ところが最近は、3ヵ月毎の更新が必要ではあるものの、Let's Encryptという無料サービスが普及してきています。 私が管理する別のサーバでも使っていますが、インターネット側のサーバもイントラネット内のサーバも問題もなく動作しています。

通信経路の暗号化を目的にドメイン認証が出来れば良いというのであれば、Let's Encryptでも十分なのかも知れません。

14%の上場企業が連結納税制度を採用していた件

f:id:boost-up:20171211234614j:plain

連結納税制度とは

連結納税は「法人税」を対象とした税制で、2以上の法人を1つの法人とみなして課税所得を計算する仕組みで、日本では平成14年4月から施行されています。

この連結納税は親会社の黒字と子会社の赤字を通算することにより、法人全体の法人税負担を軽くできるなど、基本的には法人税額を減らすための仕組みなのですが、以前は連結納税制度を採用する時点で連結子法人が持っていた繰越欠損金が切り捨てられるルールだったことから、繰越欠損金を抱える子会社を有する親会社にとっては採用に踏み切りづらい側面もありました。

その後、平成22年の税制改正により、みなし連結欠損金の範囲が拡大されたことなどをきっかけに、次第に連結納税制度を採用する企業が増える傾向にあったと思います。

ただ、これまでは漠然と「あ、この会社も連結納税始めたんだ」くらいの感覚的なものでしかなかったので、今回改めて、上場企業の中で連結納税制度を採用している会社がどれくらいあるのかを調べてみました。

2017年12月時点で上場企業約3,700社中、約520社が連結納税制度を採用(一部直近まで採用していた企業を含む)

以前、消費税の税込処理を行っている上場企業を調べたときと同じ方法で、上場企業サーチのデータベースから、2017年12月11日時点で各社が開示している最新の有価証券報告書の情報を使い、連結納税制度を採用している会社数を調べました。

以下は、「重要な会計方針」に「連結納税」という単語を含む数を上場市場と業種でクロス集計したものです。

f:id:boost-up:20171211223554p:plain

単純合計では523社ありますが、個別に調べたところ、極少数ですが「今期から連結納税制度の適用を取りやめた」会社も含まれていました。

例えば、名証二部の1件というのは「ニッコー株式会社」なのですが、この会社は今期途中に吸収合併を行った結果、連結完全支配関係を有する国内連結子会社が存在しなくなったという理由で連結納税の適用を取りやめています。

今回は1件単位で正確な数字を拾うことが目的ではありませんので、約520社ということで整理させて頂きますのでご了承ください。

日本には約3,700社の上場企業がありますので、約520社というのは約14%となります。

この数字を多いと思うか、少ないと思うかは人それぞれだと思いますが、私としては「かなり増えた」という印象を受けました。

また、パッと目につくところでは5大商社はいずれも連結納税制度を採用していますし、トヨタ、本田、日産、マツダ、スズキなどの自動車大手、パナソニック、シャープ、富士通、三菱電機、日本電気、東芝などの電機大手なども名を連ねています。

感覚的となりますが、多数の連結子会社を抱える商社、製造業に連結納税が浸透しているということは、かなりの数の会社が連結子法人として連結納税制度に参加していると言えると思います。

また、興味が向いたときにもう少し分析してみたいとは思いますが、個人的には欲求が満たされたのでこのくらいにしておきたいと思います。

2017年12月時点で連結納税制度を採用している(いた)上場企業の一覧

今回の集計で作った一覧を下のリンクからダウンロードすることができますので、興味がある方はご利用ください。

ただし、正確性など品質は一切保証できませんので自己責任の下で利用いただくようお願いします。

https://blog-contents.ds.jp-east.idcfcloud.com/2017年12月時点で連結納税制度を採用している(いた)上場企業の一覧.xlsx

上場企業で消費税を税込経理している会社が3社存在した件

f:id:boost-up:20171208202121j:plain

税込経理と税抜経理

企業会計では消費税の会計処理として税込処理と税抜処理の2つの方法が認められています。

税込経理とは取引の本体価格と消費税を一体として処理する方法であり、 税抜経理とは取引の本体価格と消費税を区別して処理する方法です。

例えば、本体価格1万円の商品を販売した場合、税率を現在の8%とすると、それぞれの方式における仕訳は次のようになります。

  • 税込経理の場合
売掛金 10,800 / 売上 10,800
  • 税抜経理の場合
売掛金 10,800 / 売上 10,000
        / 仮受消費税 800

仕訳だけを見れば、税込経理の方が単純で楽そうですが、 税務上、会計上様々な理由から、特に規模の大きい企業では税抜経理が常識と言われています。

その理由は今回の本旨ではありませんのでまたの機会にするとして、 ふと、「常識」が正しいのかどうか気になりましたので調べてみることにしました。

データソースは上場企業サーチ.comで集めている上場企業各社の有価証券報告書になります。

対象とした有価証券報告書

本日2017年12月8日現在、上場企業各社がEdinetを通じて開示している最新の「有価証券報告書」を対象にしました。 対象の各有価証券報告書において、個別財務諸表の注記事項として記載されている「消費税等の会計処理」を全件調査しました。

開示されるのは上場企業本体の消費税処理方式ですので、 グループ会社などの消費税処理方式は親会社と異なる可能性もあります。

上場企業で税込経理を採用しているのはわずか3社!!!

もしかしたら1社も該当がないのではないかとの不安と期待を旨に結果を取り出してみたところ、 たった3社だけ、税込経理を採用している上場企業がありました。

眼科薬の開発を行う創薬会社の持株会社

家賃保証業務を行っている会社

不動産担保ローン業務を行っている会社

上場企業で税込経理を採用する会社があったことは正直意外でしたが、 よくよく見てみると、窪田製薬ホールディングスは上場会社単体では売上高がゼロという極めて珍しい状況ですし、 あんしん保証とアサックスの2社もそれぞれ家賃保証、不動産担保ローンを業としており、非課税取引が本業の会社ということで、 やはりそれぞれ一定の事情はあるようです。 (後の2社については、非課税取引が本業の会社で税抜経理を採用している会社も多数ありますので、単に業種だけの問題だけの問題ではないとは思います。)

ということで、上場企業は税抜処理という「常識」は一応確信に変わりました。

上場企業の平均年収と調べ方

f:id:boost-up:20171207225800j:plain 拙作、上場企業サーチ.comでは上場企業の平均年収を「上場企業年収ランキング」として日々集計・更新しています。

xn--vckya7nx51ik9ay55a3l3a.com

平均年収上位にはM&A関連企業が多数登場

数年前までは長い間、キーエンスがトップを継続しており、全体でみると中堅に位置する製造業(電気機器業)に属する企業がトップということでかなり注目されていましたが、現在は3位になっています。

キーエンスに代わり1位となったのがM&Aアドバイザリー業務を手掛けるGCA株式会社、続く2位もやはりM&Aアドバイザリー業務のM&Aキャピタルパートナーズ株式会社、更にはキーエンスを挟んで4位に位置する株式会社ストライクもまたM&A関連企業となっており、如何にM&A市場が活発でハイスペックな人材を集めているのかが想像できます。

M&A関連ビジネスの中でも特にFAと呼ばれるアドバイザー業務は、買収価格の一定率という形で報酬を得る成功報酬契約を結ぶことが多く、大型の案件が纏まると巨額の報酬を手にすることが出来る構図となっています。

M&A業界は年収もさることながら平均年収が低いことも特徴的です。

1位のGCA株式会社はなんと平均年齢37.2歳で平均年収2,139万円となっており、 2位のM&Aキャピタルパートナーズ株式会社も平均年齢31.1歳で平均年収1,905万円という数字をたたき出しています。

M&Aの当事会社にとっては統合日であるDay1からが本当の意味でのスタートですが、 M&AアドバイザーであるFAは、Day1以前に置かれるクロージング日までが仕事ですのでモチベーションを維持する時間軸が決定的に違います。 日本企業のM&Aの成功率は10%~50%程度と言われたりしますが、、、この辺語り出すと長くなるのでまた今度にすることにします。

平均年収のデータソース

上場企業の平均年収は有価証券報告書を見れば記載されています。

有価証券報告書というのは、金融商品取引法が有価証券の発行者に対して提出を要求しているもので、決算ごとに年1回の有価証券報告書と四半期ごと年3回の四半期報告書のことを指します。 四半期報告書と有価証券報告書は情報量が大きく異なっており、平均年収の開示が求められているのは有価証券報告書だけですので、企業の平均年収は年1回の頻度で更新された情報が開示されます。

有価証券報告書を入手したければ、各社のホームページのIRコーナーか、Edinetからダウンロードすることが出来ます。

ちなみに、たまに誤解されている方がいますが、この平均年収というのは、あくまでも上場企業本体の従業員に関しての平均年収で、企業グループの平均年収ではありません。

特に昨今では、少数精鋭が所属する持株会社(~ホールディング、~ホールディングスというのは基本的に持株会社です)を上場させ、多数の従業員が所属する事業会社はその子会社であることも多く、実は有価証券報告書の平均年収は実体を表していないことも多々ありますのでその点は注意が必要です。

大企業やそのグループ会社についての年収情報を得たいのであれば、Vorkersなどの民間の口コミサイトの方がより真実に近い数字を持っているように思います。

有価証券報告書に一言モノ申す

私は一年中有価証券報告書と格闘している人間の一人だと思いますが、実は有価証券報告書には結構誤植があります。

確かに有価証券報告書はいわゆる財務諸表部分を除くと会計監査人(監査法人等)の監査範囲外ですし、こと電子開示されるXBRLについては全体が監査範囲外ではありますが、年に両手に届くぐらい、余りにも単純なミスが含まれていることがあります。

例えば、どこの会社かは伏せますが、次のような情報がEdinetを通じて実際に開示されています。

f:id:boost-up:20171207225332p:plain 平均年収62億円って、、、あらゆる手段を尽くして1年だけ入社したいです。

また、次のような会社もあります。

f:id:boost-up:20171207225407p:plain こちらは持株会社ですので、事業会社と兼務で別の給料が支払われている可能性もゼロではないですが、年収36万円では私はやっていけません。

といった感じで、今回は平均年収の箇所だけの「一言」でしたが、他の開示箇所でもたまにこの種のケアレスミス(?)を目にします。

企業内で開示業務に関わっている方々は、非常にタイトなスケジュールの中で昼夜奮闘されていることと推察しますが、 利用者の意思決定に資する価値ある情報を提供するため、最後の通しチェックを行っていただくよう、何卒宜しくお願い致します。

<解決済み>Railsでassets:precompileを実行したところ「constant ::Fixnum is deprecated」等のエラーが出た件

f:id:boost-up:20171207230216j:plain

問題が発生した環境

  • Ruby 2.4.1
  • Rails 4.2.5

問題の内容

production環境でassets:precompileを実行したところ、大量のエラーが出力されprecompileが出来ませんでした。 エラー内容の抜粋は以下の通りです。

# bundle exec rake assets:precompile RAILS_ENV=productionn
path_to_vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.5/lib/active_support/core_ext/numeric/conversions.rb:121: warning: constant ::Fixnum is deprecated
path_to_vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.5/lib/active_support/core_ext/numeric/conversions.rb:121: warning: constant ::Bignum is deprecated
rake aborted!
SystemStackError: stack level too deep
path_to_vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.5/lib/active_support/core_ext/numeric/conversions.rb:124:in `block (2 levels) in <class:Numeric>'
path_to_vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.5/lib/active_support/core_ext/numeric/conversions.rb:131:in `block (2 levels) in <class:Numeric>'
path_to_vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.5/lib/active_support/core_ext/numeric/conversions.rb:131:in `block (2 levels) in <class:Numeric>'
path_to_vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.5/lib/active_support/core_ext/numeric/conversions.rb:131:in `block (2 levels) in <class:Numeric>'
path_to_vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.5/lib/active_support/core_ext/numeric/conversions.rb:131:in `block (2 levels) in <class:Numeric>'
path_to_vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.5/lib/active_support/core_ext/numeric/conversions.rb:131:in `block (2 levels) in <class:Numeric>'
path_to_vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.5/lib/active_support/core_ext/numeric/conversions.rb:131:in `block (2 levels) in <class:Numeric>'
path_to_vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.5/lib/active_support/core_ext/numeric/conversions.rb:131:in `block (2 levels) in <class:Numeric>'
path_to_vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.5/lib/active_support/core_ext/numeric/conversions.rb:131:in `block (2 levels) in <class:Numeric>'
path_to_vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.5/lib/active_support/core_ext/numeric/conversions.rb:131:in `block (2 levels) in <class:Numeric>'
path_to_vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.5/lib/active_support/core_ext/numeric/conversions.rb:131:in `block (2 levels) in <class:Numeric>'
~ 以下、延々と同じエラーメッセージが大量に出力 ~

原因と対応の内容

ネットで調べたところ、海の向こうに同じ現象に陥った先人がいることが分かり、 チャットを読み進めていくとどうやらRuby 2.4ではFixnumとBignumはIntegerに統合され、元のクラスはなくなってしまったとのこと。 stackoverflow.com

Qiitaで解説している方がいらっしゃいました。 qiita.com

仕事としてお金を貰って他人のためのシステムを作るときには絶対にできない進め方ですが、 私の場合、開発を仕事にしているわけでもなく、自分のためのシステムを自分一人で作っているので、 新しいバージョンが出ると「とりあえず上げてみる」を結構やってしまいがちです。

運営するサービスも少しずつ大きくなってきているので、そろそろちゃんとしないとと思ってはいるのですが、早くサービスを良くしようという思いが強すぎるようです。 なので、恥ずかしながらRuby 2.4からFixnumとBignumがIntegerに統合されていたなんてことも今まで知りませんでした。 というか、FixnumとBignumというクラスすら意識して使ったことがありません。。。

話を元に戻すと、どうやらRails4.2.5のソースコードの中にFixnumとBignumを使っている箇所があることがエラーの原因らしく、 先の英語のチャットを読んでいくと、「All you have to do is upgrading Rails from 4.2.5 to Rails 4.2.8.」とのこと。

ということで、Railsを4.2.5から4.2.8に上げてみることにしました。

Gemfileのrailsのバージョン指定を次のように変更して保存し、bundle updateを実行します。

source 'https://rubygems.org'

# Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
gem 'rails', '4.2.8'

その後、改めてprecompileを実行してみると、、、無事、precompileが成功するようになりました。

偉大な先人たちに日々感謝です。