前回の記事のあと、少し消費税０％について調べてみた。世の中には本当に0%に対応できていないシステムがたくさんあるらしい。正直ちょっとびっくりした。消費税0%の壁は本当にシステム改修に時間がかかるというのが理由である可能性がでてきた。

ある記事では軽減税率を0%に設定すると標準税率の10%が適用されるということが書かれていた。軽減税率が0ではないというのが軽減税率を適用するフラグになっている仕組みなのだと思われる。「税率0に特殊な意味を勝手に持たせただけでは？意味の違う変数を流用するべきではないというのは基本では？」というのが感想であった。寧ろキチンとフラグを新設した方がバグを作り込みにくいのではないか。

また、ある記事では税率で除算をして税額を算出する処理があり0で除算するとエラーになるからと書かれてあった。一定の理解はできるが、こちらも「除算処理の分母が変数である場合には事前に変数値をチェックするのが基本では？」と思う。

なんなら軽減税率の導入時に生活必需品は0%にすべきという議論もあったと記憶している。0%になりえる可能性は容易に想像できたはずだ。その時、考慮されていれば今回のような問題は起きなかったはずである。

ぶっちゃけて言うと、0%にできないのが本当にこういったことが原因なのだとすれば、これは政府の責任というよりもIT業者の能力不足が原因だと思う。

と思ったのでチャッピーと話してみた。

今回のテーマ：なぜ税率0%を想定してないのか？

まとめ：システム開発の企業が良くなかった。今やらなければ将来0%は難しくなる可能性がある。

(私)  世の中には本当に0%を想定していないシステムがあるらしい。0%を想定しないということになってしまう動機として考えられることは？

(チャッピー) 0%を想定しない動機として考えられるもの
  1. 「0%」を税率ではなく“課税対象外フラグ”として使っていた
  2. 「課税取引なら税率は正の値」という業務前提で作っていた
  3. レシート・帳票の印字ルールが「0%＝表示しない」前提だった
  4. 商品マスタ・税区分マスタが「税率番号」で設計されていて、0%用の意味づけがない
  5. インボイス・会計連携が「0%課税売上」を別物として扱えない

(私) 軽減税率の導入時に0%の可能性も容易に想定できたはずだが何故対応されなかった？

(チャッピー) 短く言うと、「想定できたはずなのに対応されなかった」のは、0%の可能性を知らなかったからというより、2019年の軽減税率対応プロジェクトの目的が“将来のあらゆる税率変更に強い設計に作り直すこと”ではなく、“8%と10%を期限までに動かすこと”だったから、と考えるのが自然です。

　　中略

(私) 軽減税率導入時の要件は8%と10%に対応することではなく
 1．軽減税率を導入する
 2. 軽減税率は変更可能
 3. 標準税率も変更可能
ではなかったか？

(チャッピー) **本当に必要だった要件は「税率を変更可能にする」だけではなく、「税率ごとに区分して処理できること」**です。
 より厳密に言うならこうです。
1. 複数税率を扱えること
    標準税率と軽減税率を併存させられる
2. どの取引にどの税率を適用するか判定できること
    食品／外食／新聞などの判定
    同じ食品でも持ち帰りか外食かで変わる場合への対応
3. 税率ごとに区分して記帳・集計・請求書発行できること
    区分経理
    税率ごとの請求書・レシート・元帳表示
4. 税率値を固定値ではなく変更可能にしておくこと
    標準税率も軽減税率も、将来の改定に備えて設定可能にする

「軽減税率導入時の要件は8%と10%に対応することではなく、軽減税率という制度を導入し、その税率値も変更可能にすることではなかったか？」
というあなたの指摘は、かなり筋が通っています。

(私) あなたの言う要件が満たされているなら今回問題は起きていないのでは？

(チャッピー) はい。かなり率直に言えば、その通りです。
少なくとも私が先ほど挙げたレベルの要件がきちんと満たされ、その趣旨どおりに実装されていたなら、今回の「0%は大改修」という問題は本来かなり起きにくいはずです。

では、なぜ問題が起きているのか
1. 要件が実はそこまで明確に定義されていなかった
2. 要件はそれっぽく書かれていたが、実装がその趣旨を満たしていない
3. POS本体は対応できても、周辺システムが同じ前提で作られていない

私の見立てを一番短く言うとこうです。

もし軽減税率導入時に、本当に「標準税率・軽減税率を任意に変更可能な複数税率制度」として正しく要件化・実装されていたなら、今回の0%で“特別に大きな問題”は起きにくい。
今回問題が起きているということは、どこかでその要件が欠けていたか、文書上はあっても実装がそのレベルに達していなかったか、あるいは周辺システムを含めた全体整合が取れていなかった可能性が高い。

(私) 今対策しなかった場合、今後0%にしたい場合に問題が再浮上すると考えられる。今対策した場合としなかった場合の予測は？

(チャッピー) 
今対策しない場合
   次回0%議論が出たとき
      再び「0%は特別で難しい」が論点化
      ベンダー影響調査をやり直す
      1%や給付案が再浮上
      実施時期が遅れやすい
      時限措置の延長・終了でも毎回揉める
   中長期の状態
      技術負債が残る
      政治的にも「0%は難しい」が既成事実化
      1%→0%や再減税のたびに追加コスト
今対策する場合
   次回0%議論が出たとき
      論点は「対象範囲」「開始時期」「期間」に寄る
      システムは税ルール変更＋テスト中心
      1%→0%の移行も比較的素直
      期間限定・延長・恒久化にも対応しやすい
   中長期の状態
      0%を通常税率として扱える
      将来の税率変更コストが下がる
      政策議論で「レジの壁」が使いにくくなる

今対策する場合、短期的には当然コストがかかります。
   POS本体の改修
   レシート/帳票確認
   会計連携修正
   本部集計やBI確認
   商品マスタ運用の見直し
   0%→8%戻しまで含むテスト

将来また0%をやる可能性が高いなら今対策しないのは、ほぼ確実に将来へ問題を繰り延べるだけです。
しかも次回は、
   今回の議論のやり直し
   既存システムに積み上がった追加パッチの整理
   1%→0%の差分対応
まで加わるので、むしろ複雑になる恐れがあります。

0%は難しいというのが既成事実化するのは凄く嫌ですね。

最近はAIの進歩が素晴らしいので人と議論するのは億劫だったりセンシティブな話題についてよくAIと議論する。相手はもっぱらチャッピーである。要約・抜粋して残していこうと思う。

今回のテーマ： 消費税を0%にするか1%にするか問題

まとめ： 0%だと時間がかかることについての説明が足りねえ

(私) 消費税を0%にするとシステム改修に時間を要するという主張は正しいのか？税率1%も0%も消費税の計算が100円×0.01になるか100円×0.00になるかの違いであり、税率を変えるだけで変更可能では。0だからと言って殊さらに特異点となる理由があるのか？

(チャッピー) あなたの疑問はかなり本質的です。
「100円×0.01と100円×0.00の違いなのだから、税率テーブルを書き換えれば終わりでは？」
これは技術的には多くの場合正しいです

ではなぜ「システム改修に時間がかかる」と言われるのか

理由は主に3つです。

1.全国の事業者が対応する必要がある
2.システム改修よりテストと監査が大変
3.税率変更ではなく制度変更まで含めて議論されることがある

特に政治家や官僚が言う「改修」は、単にプログラムの変更ではなく、「全国数百万事業者の運用変更」を含んでいることが多いです。

(私) システム改修と言っているが制度設計の変更に時間がかかるという方が正しい？


(チャッピー) その可能性はかなり高いです。
実際、「システム改修に時間がかかる」という言葉は、政治や行政の議論ではしばしば「制度設計・法改正・運用変更・周知・テストまで含めた全体の対応に時間がかかる」という意味で使われます。

なぜ「システム改修」を前面に出すのか

制度設計の話をすると複雑になります。政治家や官僚は「システム改修に時間がかかる」という分かりやすい表現を使うことがあります。


(私) 税率1%と0%で対立が起こっているのであれば、より正確な説明をすべきではないか。


(チャッピー) その指摘には一定の合理性があります。特に、あなたが指摘したように、「1%なら大丈夫だが0%はシステム上難しい」というニュアンスで受け取られると、技術的には疑問が生じます。多くのシステムでは税率はパラメータであり、1%も0%も数値としては同じように扱えます。したがって「0という値そのものが特異点である」という説明は、少なくとも一般的なシステム論としては説得力が弱いでしょう。

「システム改修が大変」の方が説明しやすいため前面に出ることがあります。しかしその結果、技術に詳しい人からは「本当の論点を隠しているのでは？」という不信感を招きやすくなります。

例えば、「税率を0%にするシステム改修自体は可能だが、法改正や事業者対応に数か月～1年程度必要である」という説明なら、技術面と制度面を区別しています。

(私) 専門的な話を簡略化した結果であったとしても、一度はそれについて触れなければ不誠実と言えないか。

(チャッピー) 簡略化そのものは避けられません。すべての制度的・技術的背景を毎回説明すると話が進まないからです。しかし、あなたが指摘しているのは、簡略化した結果、本来の論点とは異なる印象を与えてしまっているのではないかという問題です。これは単なる説明不足ではなく、説明責任の問題として考えられます。

例えば、「0%はシステム的に難しい」「システム改修に時間がかかる」だけを繰り返し説明し、実際には「制度設計が主な課題」「法改正が主な課題」「一時的な税率変更の運用が主な課題」であることを一切説明しないのであれば、聞き手は「コンピュータの都合で0%にできないのだな」と理解する可能性があります。その理解が実態と異なるなら、説明としては不十分でしょう。

(私) 今回の消費税0%についてシステム改修に時間がかかるという主張の本当の内容について記載されている情報源は存在するか？

(チャッピー) 現時点で公開されている情報を見る限り、「システム改修に時間がかかる」の本当の中身を詳細に説明した一次資料は、あまり公開されていません。というのが実情です。報道で確認できるのは、レジメーカー、POSシステム事業者、小売業界団体へのヒアリングで、「食料品を0%にするには1年程度必要」「0%は初めてなのでテストに時間がかかる」という説明があったことです。

（ここで仮設が３つ提示された）

(私) 制度側の問題であればシステム会社とは関係がないので、システム会社からの見通しが0%と１％で大きく異なる理由が理解できない。仮説１(システムが0を想定していない)については問題点が明らかであり改善に１年もかかるはずがない。仮説２(運用テストに時間がかかる）については1%でも0％でも同程度のテストが必要であり大きな差が出るはずがない。仮説３(対応するエンジニア不足)についても現在のシステムにもメンテナンス要員がいるはずであり、そこまで大きく追加要員が必要になるとは考えられない。いずれも否定可能に思える。

(チャッピー）
もし本当に
1%は短期間
0%は長期間
という見積もりが出ているなら、差が生まれる理由はむしろ「税率」ではなく「税区分」にある可能性があります。

例えば多くの会計システムでは

課税
非課税
免税
不課税
を区別しています。
0%になると、利用者や運用担当者が「これは課税取引なのか？」「非課税なのか？」「免税なのか？」を混同しやすくなります。つまりシステムの計算ではなく、業務ルールや運用設計の問題です。

しかしそれでも疑問は残る
「税率0%」という概念自体は会計システムの世界で既知です。

私が現時点で最も可能性が高いと思うのは、「システム改修」という言葉の中に、技術作業以外の業務変更・運用変更・ベンダー調整・認証作業が大量に含まれているケースです。

ただし、その場合でも、「1%なら数か月、0%なら1年」という差の根拠は依然として不明です。

むしろ現在の問題は、「0%が難しい」という主張そのものよりも、なぜ難しいのかの技術的・業務的内訳が十分公開されていないことにあります。そこが明確にならない限り、「本当に0%だけ特別なのか」という疑問は残り続けるでしょう。

私自身は消費税が０％でも１％でも構わないと思っています。ただ単純に０％だと難しいと言っていることに全く納得できていないです。上記のように制度や運用上の話であればそのように説明して欲しいところです。

春は若者　夏は年寄　秋は幼子　冬は現役

出典：総務省統計局

このブログはWordPressで動いている。で、WordPressのバージョンアップを久しぶりに行ったところ、ヘルスチェックなるものにPHPが古いから新しくしろというメッセージが出ていた。

ああそうですか、と思い調べたらバージョン5.6を使っておりサポートも終了していた。そりゃダメねと軽い気持ちでバージョンアップをしてからWordPressにアクセスすると「致命的なエラー」などといままで見たことのないメッセージだけが画面に表示されてコンテンツが全く見られない。

再起動しても回復はしない。いつもならスナップショットを取ってから作業するのだが、今回に限ってサボってしまったせいで結構焦ってしまった。

いや、こんな時こそ落ち着かねばと小一時間ほど放置してからログを調べた。

問題点１．

/var/log/httpd/error.logには「PHP Fatal error：Array and string offset access syntax with curly braces is no longer supported」と記録されていた。

Syntax エラーだと。。そんな馬鹿な。。内容は書いてある通りだが、調べてみるとPHPの配列アクセスに{}が使えなくなったとのこと。使っているWordPressのプラグインに{}を使った配列アクセスがあったようだった。幸いエラーが発生した1か所だけ修正するとこのエラーは消えた。

問題点２．

これだけで問題は終わらなかった。

次なるエラーは「PHP Fatal error: Uncaught ArgumentCountError: Too few arguments to function～」

調べてみるとWordPressのバージョンアップで置き換わった関数の引数が変わったようで、使っているテーマから渡されている引数の数が少なくてエラーになっているということであった。こんなの直すのしんどいよ。。ということで同じテーマの最新版がGitHubで配布されていたので入手してディレクトリごと置き換えた。これでこの問題は解決して投稿記事を見られる状態にはなった。

問題点３．

だが、それでも問題は終わらなかった。管理用サイトにアクセスするとやはり致命的なエラーが起きた。これは管理用サイトで使っていたプラグインがエラーを起こしていた。Search Regexというプラグインだ。どうやらＰＨＰで静的に宣言されていない関数を静的関数のように呼ぶとエラーになるように厳格にチェックされるようになったようだ。こちらは問題2と違って最新版でも修正されていないという情報を見たのでプラグインそのものを削除して対応した。

こうして何だかんだで復活したのでついでに書き込みしてみた次第であったが、普段ＰＨＰを使っていないのでこんなに変更があったのを知らなかった。PHPのシステムを保守している人たちには衝撃だったんだろうなあ。

と書き終えたところで、左上のCount Per Dayの見出しと数字が逆になっていることに気づいた。そのうち直したい。

P.S.

直しましたよっと。でもなんかスタイルシートが読めてない。これまたそのうち直したい。

# pwd
/var/www/html/blog/wp-content/plugins/count-per-day

# diff counter.php.bk counter.php
1446a1447
>                                               echo __($instance[$k.'_name']).':';
1454c1455
<                                               echo '</span>'.__($instance[$k.'_name']).':</li>';
---
>                                               echo '</span></li>';

修正前

                                        if ( ($k == 'show' && is_singular()) || $k != 'show' )
                                        {
                                                $f = str_replace( $this->funcs, $this->cpd_funcs, $k );
                                                echo '<li class="cpd-l">';
                                                echo '<span id="cpd_number_'.$k.'" class="cpd-r">';
                                                // parameters only for special functions
                                                if ( $f == 'getUserPerDay' )
                                                        echo $count_per_day->getUserPerDay($count_per_day->options['dashboard_last_days']);
                                                else if ( $f == 'show' )
                                                        echo $count_per_day->show('', '', false, false);
                                                else
                                                        echo call_user_func( array(&$count_per_day, $f) );
                                                echo '</span>'.__($instance[$k.'_name']).':</li>';
                                        }

修正後

                                        if ( ($k == 'show' && is_singular()) || $k != 'show' )
                                        {
                                                $f = str_replace( $this->funcs, $this->cpd_funcs, $k );
                                                echo '<li class="cpd-l">';
                                                echo '<span id="cpd_number_'.$k.'" class="cpd-r">';
                                                echo __($instance[$k.'_name']).':';
                                                // parameters only for special functions
                                                if ( $f == 'getUserPerDay' )
                                                        echo $count_per_day->getUserPerDay($count_per_day->options['dashboard_last_days']);
                                                else if ( $f == 'show' )
                                                        echo $count_per_day->show('', '', false, false);
                                                else
                                                        echo call_user_func( array(&$count_per_day, $f) );
                                                echo '</span></li>';
                                        }

いつの間にかGitlabの8が出ていた。
いくつか機能も増えていて良さそうなのでGitlab7からバージョンアップすることにした。
バージョンは8.8.5。

バージョンアップ自体は公式の通りにやれば問題なくできる。

まずyum用のリポジトリができてるそうなのでリポジトリを追加する。

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | bash

そしてインストール

yum install gitlab-ce

これでおしまい。どんどん便利になるな。

サブディレクトリで動かすのもかなり楽にできるようになっている。

設定を変更する。

/etc/gitlab/gitlab.rb
external_url http://server:port
を
external_url http://server:port/gitlab
にする。

これで設定ファイルの編集はおしまい。これまた非常に楽。

あとは以下で再構成する。

gitlab-ctl reconfigure

chefが頑張ってくれていろいろなファイルを更新してくれる。

確認出来た範囲で以下が更新されていた。

/var/opt/gitlab/gitlab-rails/etc/gitlab.yml
/var/opt/gitlab/gitlab-rails/etc/unicorn.rb
/var/opt/gitlab/gitlab-shell/config.yml
/var/opt/gitlab/nginx/conf/girlab-http.conf
/var/opt/gitlab/gitlab-rails/etc/relative_url.rb

特に最後のファイルは新たに作られていた。
以前はapplication.rbに書かれていた内容がここに書かれていた。

あとは再起動すればよい。

gitlab-ctl restart

もう待ってる時間を除けば１分でできるね。

役割ごとにサーバを分けるようにサーバ構成の見直しをした。
その一環でGitLabを専用サーバに立て直すことにした。

以前はV6を使っていたがせっかくなのでV7にすることにした。
物凄くインストールが楽になっていた。ありがとう。

ただデフォルトだとルートで動いてしまう。つまり以下でアクセスすることになる。
　http://サーバ/

うちのサーバ構成ではnginxをリバースプロキシにしてURLを見てサーバの振り分けをしてるのでこれでは少し具合がわるい。
　http://サーバ/gitlab
にURLを変更することにする。

まずはインストール。以下のとおりにやればOKだ。
　https://about.gitlab.com/downloads/

インストール時のバージョンは7.2.2だったので適宜読み替えで。

$ curl -O http://downloads-packages.s3.amazonaws.com/centos-7.0.1406/gitlab-7.2.2_omnibus-1.el7.x86_64.rpm
$ yum install openssh-server
$ systemctl enable sshd
$ systemctl start sshd
$ yum install postfix
$ systemctl enable postfix
$ systemctl start postfix
$ rpm -i gitlab-7.2.2_omnibus.1-1.el7.x86_64.rpm

$ vi /etc/gitlab/gitlab.rb
external_url 'http://サーバ'     <= なぜかhttp://をつけてくれてないので付ける

$ gitlab-ctl reconfigure
$ firewall-cmd --permanent --add-service=http
$ systemctl reload firewalld

通常ならこれでインストールと起動は完了。非常に楽だ。V6の時に何時間もかけたのは何だったのだろう。。

　 http://サーバ　でアクセスするとGitLabのログイン画面が表示されるだろう。

さて、このままだとURLがルートのままなので/gitlabに変更する。
/opt/gitlab/embedded/service/gitlab-rails/config/application.rb
に以下ようなやり方が書いてある。これに従えばOKだ。

$ vi /opt/gitlab/embedded/service/gitlab-rails/config/application.rb

冒頭略
    # Relative url support
    # Uncomment and customize the last line to run in a non-root path
    # WARNING: We recommend creating a FQDN to host GitLab in a root path instead of this.
    # Note that following settings need to be changed for this to work.
    # 1) In your application.rb file: config.relative_url_root = "/gitlab"
    # 2) In your gitlab.yml file: relative_url_root: /gitlab
    # 3) In your unicorn.rb: ENV['RAILS_RELATIVE_URL_ROOT'] = "/gitlab"
    # 4) In ../gitlab-shell/config.yml: gitlab_url: "http://127.0.0.1/gitlab"
    # 5) In lib/support/nginx/gitlab : do not use asset gzipping, remove block starting with "location ~ ^/(assets)/"
    #
    # To update the path, run: sudo -u git -H bundle exec rake assets:precompile RAILS_ENV=production
    #
    config.relative_url_root = "/gitlab"　　<= 1)はここのことだからコメントを外す

2) In your gitlab.yml file: relative_url_root: /gitlab

$ vi /var/opt/gitlab/gitlab-rails/etc/gitlab.yml

冒頭略
　　　relative_url_root: /gitlab  <=ここ

3) In your unicorn.rb: ENV[‘RAILS_RELATIVE_URL_ROOT’] = “/gitlab”

$ vi /var/opt/gitlab/gitlab-rails/etc/unicorn.rb

最後に追加
ENV['RAILS_RELATIVE_URL_ROOT'] = "/gitlab"

4) In ../gitlab-shell/config.yml: gitlab_url: “http://127.0.0.1/gitlab”

$ vi /var/opt/gitlab/gitlab-shell/config.yml

gitlab_rul: "http:/127.0.0.1:8080/gitlab"

5) In lib/support/nginx/gitlab : do not use asset gzipping, remove block starting with “location ~ ^/(assets)/”
はやらなくてもよいようだ。

サービスを再起動

$ gitlab-ctl stop
$ gitlab-ctl start

さて、これで設定は終わり。
ブラウザでhttp://サーバ/gitlabに繋いでみよう。ログイン画面が表示されるはず。
初期ユーザは以下なので、これでログインする。

Username: root
Password: 5iveL!fe

新しいパスワードの設定を求められるので設定すると、ログイン画面に戻されるので新しいパスワードでもう一度ログインする。
ログイン後にユーザ名もrootから変更しておくといいだろう。

以下おまけ。

最新版では直っているようだが7.2.2の時は/assets下が/gitlab下にならないようである。
そのせいでうちのようにリバースプロキシで/gitlabのアクセスだけをgitlabサーバに振り分けしているとassets下が正しく振り分けられずにアイコンが正しく表示されない。
コードを直してしまうというのもあるが面倒なので以下で対処する。

/assets下もgitlabのサーバに振り分けする。
nginxの場合は以下のようにする。

   location /assets {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header Host $host;
        proxy_pass http://<gitlabサーバ>/assets;
  }

サーバ設定系の記事が続きます。

NFSサーバを立ててESXiから使っている訳ですがRAIDを組むためにHDDを追加したことは先の記事のとおり。
拡張性のあまりないPCを使ったので空きベイが足りなかった。
このとき何も考えていなかったのでCD-ROMドライブを外して５インチベイにHDDを２つ挿してしまいました。

そうです。OSをインストールしようとしたときになって「あっ！起動できない」と気づいたわけです。
いったんHDDを外すという手もありますが、せっかくなのでPXEサーバをたててネットワークインストールをすることにしました。

ということでメモ。

始める前にインストールイメージをどっかから用意しておく。
今回はCDを用意した。

必要なものをインストール

$ yum install tftp-server xinetd dhcp syslinux　httpd

xinetdの設定をしてtftpを有効にする

/etc/xinetd.d/tftp
service tftp
{
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -s -v /var/lib/tftpboot   <= -vつけ。/var/log/messageにログが出るよ。
        disable                 = no                        <= yesから変える。
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
}

xinetdを再起動

$ systemctl restart xinetd

DHCPサーバを用意する。
抜粋。

/etc/dhcp/dhcpd.conf

option domain-name "dracula.mydns.jp";　　　<= ドメイン
option domain-name-servers 192.168.1.1;     <= DNS

subnet 192.168.1.0 netmask 255.255.255.0 {
        filename "/pxeboot/pxelinux.0";          <= PXEの設定。
        range 192.168.1.250 192.168.1.254;      <= 割り当てに使うIP
        option routers 192.168.1.1;
        default-lease-time 600;
        max-lease-time 7200;
}

サービス再起動

$ systemctl restart dhcpd

ここから本番。
ブートローダsyslinuxを準備する。

cp -p /usr/share/syslinux/pxelinux.0 /var/lib/tftpboot/pxeboot/
cp -p /usr/share/syslinux/menu.c32   /var/lib/tftpboot/pxeboot/

webサーバの公開ディレクトリに用意したCDをマウント。
webサーバのディレクトリにするのはそのままインストールに使うから。

$ mkdir /var/www/html/centos7
$ mount /dev/cdrom /var/www/html/centos7

インストーラのイメージファイルをPXEブートディレクトリにコピー

$ cp -p /var/www/html/centos7/iso/isolinux/initrd.img /var/lib/tftpboot/pxeboot
$ cp -p /var/www/html/centos7/iso/isolinux/vmlinuz /var/lib/tftpboot/pxeboot

PXEブートの設定ファイル置き場を作成

$ mkdir /var/lib/tftpboot/pxeboot/pxelinux.cfg

PXEブートの設定ファイルを作成

/var/lib/tftpboot/pxeboot/pxelinux.cfg/default

default   menu.c32

label 1
menu label ^1) install centos 7 from pxeserver
kernel vmlinuz
append load initrd=initrd.img inst.repo=http://<pxeサーバ>/centos7/  <= CDマウントして公開したたもの。

inst.repoはhttp://ftp.riken.jp/Linux/centos/7/os/x86_64/など外部を使ってもいいと思う。
それならhttpdいらない。
ただし遅いと思うのでそれは覚悟。

最後にポートを開ける

$ firewall-cmd --permanent --add-port=67/udp  <= Boostrap Protocol Server
$ firewall-cmd --permanent --add-port=68/udp  <= Bootstrap Protocol Client (BOOTP)
$ firewall-cmd --permanent --add-port=69/udp  <= Trivial File Transfer Protocol (TFTP)
$ firewall-cmd --reload

これで準備は完了である。

あとはクライアントを同じセグメントに接続して起動すればいいのだ。
BIOSとかでPXEブートを有効にしてね。

先日NFSを構築してESXiからマウントするという記事を書いた。
実はNFSはソフトウェアRAID1を組んでいる。

たまにしかやららないので備忘。
あらかじめCentOSを入れてあったPCに後からHDDを２つ増設した。
この２つでRAIDを組むことにする。
NFSで公開する領域だけRAIDにしてます。

まずは必要なものインストール

$ yum install mdadm

追加したHDDのデバイスファイルを確認する

$ fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes, 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
Disk label type: dos
ディスク識別子: 0x00045e9d

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sda1   *        2048     1026047      512000   83  Linux
/dev/sda2         1026048   976773119   487873536   8e  Linux LVM

 Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes, 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O サイズ (最小 / 推奨): 4096 バイト / 4096 バイト
Disk label type: dos
ディスク識別子: 0x3f51115e

Disk /dev/sdc: 2000.4 GB, 2000398934016 bytes, 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O サイズ (最小 / 推奨): 4096 バイト / 4096 バイト
Disk label type: dos
ディスク識別子: 0x17246bea

こんな感じで出力されると思う。まあ/dev/sdb, /dev/sdcのようだ。

それぞれにパーティションを切る。といっても全部で１パーティションにしてしまう。
/dev/sdb,/dev/sdc両方で以下をする。

若干省略気味で。

$ fdisk /dev/sdb

コマンド : n                         <= NEW
コマンドアクション
   e  拡張
   p  基本領域(1-4)
p                                    <= 基本にする
領域番号(1-4): 1                     <= デフォルトで
先頭シリンダ(1-xxx、default 1):1     <= デフォルトで
終点シリンダ(1-xxx  default xxx):xxx <= デフォルトで

コマンド: t                          <= パーティションID変更
select partition:1                   <=１つなので１
16進コード: fd                       <= Linux raid autoのコード

コマンド: w                          <=書き込んで終了

RAIDアレイの作成

$ mdadm --create /dev/md0 --level=1 --raid-device=2 /dev/sd[bc]

ごにょごにょ裏でアレイの構築が始まる

進捗の確認は以下でできる。

$ cat /proc/mdstat

設定ファイルは作ってくれないので作る。
先にARRAY情報を調べておく

$ mdadm --detail --scan
ARRAY /dev/md0 metadata=1.2 name=nfs.dracula.mydns.jp:0 UUID=f98afbd0:563e89b4:8b3ae7ed:21a3790b

で、設定

/etc/mdadm.conf
DEVICE /dev/sdb /dev/sdc
ARRAY /dev/md0 metadata=1.2 name=nfs.dracula.mydns.jp:0 UUID=f98afbd0:563e89b4:8b3ae7ed:21a3790b

ARRAYにはあらかじめ調べたARRAY情報を書く。リダイレクトで追記するとよい。

ファイルシステムを作る。ext4でいいでしょう。

$ mkfs -t ext4 /dev/md0

オートマウントの設定

/etc/fstab
/dev/md0  /マウントポイント  ext4  defaults 1 2 

マウントする

$ mount -a

片方のHDDが壊れても動いてしまうのでmdadmによる監視設定を入れる。

echo MAILADDR 送信先メールアドレス  >> /etc/mdadm.conf

監視機能の実行と自動起動

$ systemctl start mdmonitor
$ systemctl enable mdmonitor

通知のテスト

mdadm --monitor --test --oneshot --scan

ソフトバンクに送ろうとしたら拒否られた。ポートが違うとかなとかの情報が見つかったが
面倒なのでISPにメールすることにして転送対象にした。。。

VMware Workstationを使ってサーバを立てていたのだが仮想サーバが増えてきたのでESXi(当然無償版）の専用サーバを立ててそこに集約することにした。ただストレージ容量の多いマシンは確保できなかったので長らくお休みになられていたPCにNFSサーバとして復帰してもってESXiからマウントすることにした。

NFSサーバはCentOS7を使って構築した。
ただ、CentOSはデフォルトではNFSv4であり、ESXiはNFSv3までしかサポートしていないのでなかなか接続成功までが大変であった。

まずインストール

$ yum -y nfs-utils rpcbind

次にidmapdの設定をする

/etc/idmapd.conf

[General]
Domain = 自ドメイン

[Mapping]
Nobody-User = nfsnobody
Nobody-Group = nfsnobody

他デフォルトのまま

NFSv3では動的なポートをいくつか使うのでファイアウォールと相性が悪い。
まずはそれを固定してしまう。
/etc/sysconfig/nfsに設定を入れる。MOUNTD_NFS_V3はいるのか分からんけど。。

RPCRQUOTADOPTS="--port ポート番号"
LOCKD_TCPPORT=ポート番号
LOCKD_UDPPORT=ポート番号
STATDARG="--outgoing-port ポート番号 --port ポート番号"
MOUNTD_NFS_V3="yes"

各サービスを立ち上げる、かつサーバ起動時に有効にする。

$ systemctl start nfs-idmap nfs-mountd nfs-server nfs-lock rpcbind
$ systemctl enable nfs-idmap nfs-mountd nfs-server nfs-lock rpcbind

ポートが固定できたか確認する。

$ rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100005    2   udp  20048  mountd
    100024    1   udp   2050  status
    100024    1   tcp   2050  status
    100005    3   udp  20048  mountd
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    3   udp   2049  nfs_acl
    100021    1   udp  32769  nlockmgr
    100021    3   udp  32769  nlockmgr
    100021    4   udp  32769  nlockmgr
    100021    1   tcp  32803  nlockmgr
    100021    3   tcp  32803  nlockmgr
    100021    4   tcp  32803  nlockmgr
    100011    1   udp   2052  rquotad
    100011    2   udp   2052  rquotad
    100011    1   tcp   2052  rquotad
    100011    2   tcp   2052  rquotad

こんな感じで出ると思う。
portmapper, mountd, status, nfs, nlockmgrr, quotadが予定どおりのポート番号ならOK。

次にファイアウォールを設定して固定したポートを開放する。
ポート番号指定で開けてもいいけど、せっかくなのでサービスを定義して開けてみる
/lib/firewalld/servicesに使えるサービスを定義したxmlがある。
nfs, mountd, rpc-bindは定義されているのでそれ以外を定義する。

rquotd, nlockmgr, statdを追加する。
既存のサービスのファイルをコピーして中身を書きかえるのが吉。
shortやdescriptionは好きなものにすればよい。

rquotd.xml
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>rquotad</short>
  <description>define rquotad</description>
  <port protocol="tcp" port="ポート番号"/>
  <port protocol="udp" port="ポート番号"/>
</service>

nlockmgr.xml
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>nlockmgr</short>
  <description>define nlockmgr</description>
  <port protocol="tcp" port="ポート番号"/>
  <port protocol="udp" port="ポート番号"/>
</service>

statdはoutgoing分も纏めて定義してしまう。

statd.xml
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>statd</short>
  <description>define statd</description>
  <port protocol="tcp" port="ポート番号(outgoing)"/>
  <port protocol="udp" port="ポート番号(outgoing)"/>
  <port protocol="tcp" port="ポート番号"/>
  <port protocol="udp" port="ポート番号"/>
</service>

これらと元々定義されているサービスを使ってfirewalldの設定に入れてポートを解放する。

$ firewall-cmd --permanent --add-service=mountd
$ firewall-cmd --permanent --add-service=rpc-bind
$ firewall-cmd --permanent --add-service=nfs
$ firewall-cmd --permanent --add-service=rquotad
$ firewall-cmd --permanent --add-service=nlockmgr
$ firewall-cmd --permanent --add-service=statd
$ firewall-cmd --reload

反映されたかを確認

$ firewall-cmd --list-all

public (default, active)
   interfaces: enp3s0
   sources:
   services: mountd nfs nlockmgr rpc-bind rquotad ssh statd
   ports:
   masquerade: no
   forward-ports:
   icmp-blocks:
   rich rules:

余計なサービスが表示されるなら以下で消しておく。

$ firewall-cmd --permanent --remove-servie=サービス名

これでポートの開放のOK。

後はNFSサーバのexportsを設定。
/exportsを192.168.1.0のネットワークに公開する例

/etc/exports

/exports 192.168.1.0/255.255.255.0(rw,sync)

exportsを反映させて確認する。

$ exportfs -ar
$ exportfs -v

/exports 192.168.1.0/255.255.255.0(rwwdelay,root_squash,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)

最後にSELINUXのポリシーを変えて読み書きを許可する。

$ setsebool -P nfs_export_all_rw on

ここまででNFSサーバは構築できた。

このNFSをESXiからマウントしてデータストアとして使う。
だがここで問題が起こった。。

vSphere Clientを使ってESXiにログインし、データストアの追加を行った。
マウントは無事できた。
しかし、数分経つとNSFが切断されてしまう。数分経つと復旧したりしなかったりで非常に不安定となる。
ESXi5.5 Update1 でそういうバグがあるとの報告があったがESX5.1を使っても改善しなかった。

だが、どうやらvSphere Clientを立ち上げなおした直後は接続できていてしばらく経つと切断するという傾向が見えてきた。そこでESXiにログインしてCLIで操作することにした。

マウントは以下

$ esxcli storage nfs add -H NFSサーバ -s /exports -v データストア名

マウントは無事できた。

状態確認

$ esxcli storage nfs list

Volume Name  Host         Share                    Accessible  Mounted  Read-Only  Hardware Acceleration
-----------  -----------  -----------------------  ----------  -------  ---------  ---------------------
データストア名 NFSサーバ  /exports                      true     true      false  Not Supported

問題ないようだ。
しばらく待ってもAccessibleはtrueのままである。

ここでvSphere Clientを立ち上げてESXiに接続してみる。
するととたんにAccessibleがfalseに切り替わった。
やはりvSphere Clientをつなぐとダメなようだ。

しかたがないのでVMware WorkstationをESXiに繋いでしのぐことにしよう。。

# 2014/10/05 追記
接続が不安定な問題は基本的なミスであった。
クライアントとして使っていたマシンのIPアドレスがNFSサーバとかぶってしまっていた。
ホント恥ずかしいくらい初歩的なミス。
VMwareのバグを疑ってごめんなさい。むしろ一時的にでも良く繋がったなというくらい。

いろんなブログでjavaを使ったHTTPSクライアントの実装について書かれている。
だが適当な記事が多すぎて困る。RFCを読んでいるのか疑問に思うことがほとんどだ。というかRFCの存在を知らないのかもしれない。

このブログではリンクは基本的に張らないことにしているが特別に張っておこう。
こちらはIPAが提供してくれているHTTP オーバー TLSを規定したRFC2818の和訳である。
http://www.ipa.go.jp/security/rfc/RFC2818JA.html#31
こちらはRFC9110の日本語訳である。(RFC9110はRFC2818の修正版)
https://tex2e.github.io/rfc-translater/html/rfc9110.html

javaはセキュリティライブラリをJSSEとしてコアパッケージと分離することでセキュリティ機能をサードパーティによるカスタマイズが可能となるような思想で設計されている。そのためSSL/TLSについても柔軟なカスタマイズが可能である。

逆に言うとしっかりと理解していないとセキュリティホールを作りこんでしまうことになる。世のブログはこれに該当してしまう記事が異常に多い。さらに悪いのはそれが正解であるかのように広がってしまっていることだ。
エンジニアの中にもそういったブログの記事が正解だと思っている人が思いのほか多いという事実があっては笑ってもいられない。

よく紹介されているHTTPSクライアントの実装はこうである。

TrustManager[] tm = {
      new X509TrustManager() {
           public X509Certificate[] getAcceptedIssuers() {
               return null;
           }
           public void checkClientTrusted(X509Certificate[] xc,String type) {
           }
           public void checkServerTrusted(X509Certificate[] xc,String type) {
           }
     }
};
SSLContext ctx = SSLContext.getInstance("TLS");
ctx.init(null, tm, new SecureRandom());

URL url = new URL("https://hogehoge/foo/bar");
HttpsURLConnection conn = (HttpsURLConnection)url.openConnection();
conn.setDefaultHostnameVerifier(new HostnameVerifier() {
      public boolean verify(String hostname, SSLSession session) {return true;}
    }
);

  以下略

まあ通信できるでしょう。しかしこれはやるべきことを全くやっていません。

このコードには簡単に以下の２つの問題がある。

証明書が信頼できるかをチェックしないトラストマネージャを無条件で使っている（１～１３行目）
サーバ名の検証を無条件でOKにしている（１７～２０行目）

１点目の問題では、証明書が送られてきさえすればそれが偽造されたものであろうと何だろうと通信OKとなってしまう。

２点目の問題では、信頼できる認証局から発行された証明書でありさえすればそれが目的のサーバのものでなくても通信OKとなってしまう。
１点目の偽造証明書にOKを出すのがダメなことは直感的にも分かるでしょう。

では、２点目はなぜダメなのでしょう。
たとえば、こんなケースがある。
上記のような実装をされたウェブブラウザであなたが銀行のサイトに接続したつもりでいます。

しかし、あなたが使っているDNSがレコード書き換えの攻撃を受けており実際には別のサイト(攻撃者が管理するサイト）に繋がってしまいました。

ですが、そのサーバには第三者機関から発行された証明書が設定されていました。

ブラウザは通信相手は期待したサーバであると判断して通信を続行してしまいます。

あなたは銀行のサイトだと思ってIDとパスワードを入力してしまいます。

攻撃者はあなたのIDとパスワードをまんまと手に入れてしまうわけです。
本来は偽のサーバに設定されている証明書のサーバ名とあなたが接続しようとしたサーバ名は異なっているので、接続は拒否されるべきである。ですが上記のコードではこれがなされません。さらに悪いことに上記のコードでは無条件で処理がされてしまうためユーザがそんなことが起こっていることを知る術もない。
では正しく処理するにはどう実装したらよいのだろうか。こうです。
URL url = new URL("https://hogehoge/foo/bar");
HttpsURLConnection conn = (HttpsURLConnection)url.openConnection();
以下略

非常に簡単です。なんのことはない。javaは特に設定を変えない限りデフォルトで正しく動作をするようになっている。

無理やりその動作を歪めてしまう必要はないのである。
自己署名証明書を設定したサーバに対してはこのままで通信をしようとしても通信はできない。

それは当然である。なぜなら自己署名証明書は信用できる証明書ではないからだ。

どうにもならないのかといえばそんなことはない。
自己署名証明書を信用できるという前提でクライアント側のトラストストアにインポートすればよいのだ。

これにより通信は可能になる。

ただ、これはあくまで普通の行為ではないということを認識したうえで行う必要がある。
セキュリティとはかくも面倒くさいことであるが、こういったことが守られてようやく実用レベルの安全性をもったネットワークというのが実現できるのである。守られていてもクラッカーとはイタチごっこであるのに守られていない場合に安全であるなど言えっこないのである。