ＣＤ、ＬＰ管理と音楽のデータベース・システム　RecLib

普通の研ぎ方だと、砥石を置いて包丁を持ち、前後に動かしますよね。
でも、この方法だと結構難しい。「先端が丸くならないように、一定の角度で包丁を前後に動かす」と書くのは簡単ですが、実際にやるとなると「修行」が必要なほど難しい。

機械部品を加工する時、ヤスリをかける場合がありますが、加工対象の部品を固定してヤスリを動かしますよね。包丁研ぎの場合はヤスリ（砥石）を固定して加工対象（包丁）を動かすのはなぜ？？　包丁を固定して砥石を動かす方法を試してみました。

まず、手に持って扱える砥石を用意します。ホームセンターで「鎌砥石」というのを見つけ、それを購入しました。片手で簡単に扱える大きさです。

次に、包丁を置く台を用意します。日曜大工の端材の板を使いましたが、プラスチックのまな板もよさそうですね。その上に包丁を置きます。刃先が少し浮くように、刃の下に適当なものを置き貸す。私は割り箸を使いました。水をたっぷり含ませた鎌砥石を前後に（刃の長さ方向に）動かします。刃先の角度は砥石の左右方向の角度になります。
これを一定に保つのは、刃の角度を保って包丁を前後に動かすよりずっと簡単。
研ぐのが難しい切先も難なく研げたし、研磨面を見ながら研げるのもいい。お試しあれ。

Unit ファイルに User=tomcatUser を記述したら動かない。。。ググりまくった結果、
「User= を記述した場合は Unit ファイルは /etc/systemd.system/ にではなく /usr/lib/systemd/system/ 以下に置く必要がある」というのを見つけました。/usr/lib/systemd 以下に system フォルダがなかったので作成して tomcat.service を格納してテスト。
結果はＮＧ。起動スクリプトを spawn する時に「権限がない」のまま。権限はあるのに・・どういう事か・・
tomcat8.service の所有者が tomcatUser ではなかったので、苦しまぎれに所有者を tomcatUser に変更してテスト。

user 権限で tomcat が動きました。やったね。ところが、クライアントから接続できない。

原因は起動スクリプト内で iptables コマンドを用いて port80 を 8080 に、443 を 8443 にフォワーディングしていたからでした。iptables コマンドって、root でないと動かないんだよね。自動起動にばかり目が行っていたので、気付くのに時間がかかってしまいました。ログを見たら、やはり iptables の行で「権限がない」で失敗していました。

iptables で設定した値は、システムを止める（再起動する）と消えてしまうんですね。どうするか暫く考えて、結局 iptables-persistent をインストールしました。これを使う予定はないのですが、インストール時に iptables の設定内容を保存してくれます。これでＯＫ。

tomcat を自動起動する・・・まとめ
・/etc/init.d 以下に起動スクリプトを記述するのではなく、systemd のスタイルでやる。
/etc/init.d 以下の起動スクリプトは、systemd がそれらしく動かしてくれるが、なんか動きが変。起動スクリプト自体はどこにあってもＯＫらしいので、/etc/init.d/ 以下に置いても良さそう。（確認していません）私は別のフォルダを作って、そこに格納しました。

・シェルから /etc/init.d/tomcat start とした時と systemctl start tomcat とした時では動きが違うみたい。どこがどう違うとは説明できないのですが・・・そこまでは記録してないので・・・ごく基本的な起動のデバッグ、テストならばシェルから /etc/init.d/tomcat start でいいと思いますが、自動起動のための作業には適当ではないようです。

---- 以下、非root ユーザーで自動起動する場合 ----
・ユーザー権限で tomcat を起動するには Unit ファイルに User=tomcatUser を記述し、それを /usr/lib/systemd/system 以下に置く。/etc/systemd/system 以下に同名の Unit ファイルがあると、/etc・・・のものが優先されるので、削除する。
起動スクリプト内で su tomcatUser -c /etc/init.d/・・・とするのはお勧めしません。Unit に User=tomcatUser を記述したものが動いたので、su tomcatUser として動くかは確認していません。

・execStart= に記述する起動スクリプトの所有者が tomcatUser である必要がある。所有者が tomcatUser でない場合、起動スクリプトを起動する時「権限がない」が報告されました。rwx 権限があってもＮＧでした。

・root 以外で実行すると、port80, port443 にバインドできません。server.xml <connector> の 8080, 8443 に proxyPort="80" などと設定し、port80, port443 のコネクタは削除する。

・iptables コマンドを用いて port80 ---> port8080, port443 ---> port8443 のようにフォワーディングする設定をする。iptables での設定内容はメモリー上に記憶されているだけなので、システム停止時に消えてしまいます。iptables は root でしか実行できないので、起動スクリプト内に記述しても失敗します。
設定内容を保存するには iptables-persistent をインストールするのが簡単です。
iptables の設定を行い、動作を確認したら iptables-persistent をインストールします。インストールした時の設定を保存してくれます。

何年か使っていた夏タイヤがダメになりました。ウェット路面でひどく滑る。最初のうちは「おぉ～、滑るすべる」とか面白がっていたのですが、だんだん酷くなってきて、面白がっていられるレベルではなくなってしまいました。というのが１か月半くらい前。
冬タイヤに替える時まで我慢しようかと思っていたのですが、さらに酷くなって、はっきり言って危険なレベルになってしまいました。１０月末ごろタイヤを変える決心をして、さて、何を買うか。このところ冬はスタッドレスをはいていたのですが、考えてみたら走行距離の99％以上は普通の路面です。氷雪路は年間数キロ～十数キロ。普通の路面でのスタッドレスの性能は夏タイヤより劣っています。コーナリング時には問題ないのですが（タイヤの限界より制限速度ははるかに低い。多少とばすくらいでも大丈夫）、ウェット路面では問題があると思います。事故回避のために急ブレーキを踏んだらスリップして・・ＡＢＳがブレーキを弱めてくれて・・・が怖い。だから、注意して（我慢して）走るわけですが・・・ほんの僅かな氷雪路のために大部分の時間を我慢するのはいやだな。

というわけで、オールシーズンタイヤを検討しました。アメリカではオールシーズンタイヤが一般的で、冬、スタッドレスに交換するのは一般的ではありません。大体、街のクルマ用品店でスタッドレスを売っていない（１５年前の田舎町だったからかもしれませんが）。五大湖あたりでは昼間の最高気温が氷点下なんか普通にあるし、雪も積もるんですけどね・・・

ググってみたのですが、国産メーカーのオールシーズンタイヤは見つかりません。見つかったのはグッドイヤーのベクター。え～、これっかないの？　調べてみたら、チェーン規制の時もチェーンなしてＯＫとのこと。ふ～ん、その程度の性能はあるわけね。
チェーン規制には（１）夏タイヤはチェーンが必要。（２）全車チェーンが必要（スタッドレスでもチェーンが必要）の２種類があるそうです。全車チェーンが必要（そういう規制に出会った事はありませんが）ならば、どうせチェーンを巻くんだし、氷雪路をガンガン走るつもりもありません。乗り切れればいい。というわけで、グッドイヤー、ベクター４シーズンに交換しました。
このタイヤ、なかなか良い。まだ氷雪路は走っていませんが、普通の路面ではスタッドレスより良い。特にグリップがいいわけではありませんが、普通の夏タイヤにと比べても遜色なし（私の感覚的に、ですよ）。ウェット路面でも問題なし。激安夏タイヤには、これより悪いのもあるのでは？程度の性能です。

それから、燃費もいいみたい。「低燃費」とは表示してないのですが、悪くない。交換のタイヤと比べると、前アクセルを離した時の減速が少なくなりました。

「激安夏タイヤ＋激安スタッドレスよりは安い」くらいの価格でした。

新しい systemd のやり方で自動起動の設定を試みました。マニュアルも読まずにネットにある情報だけで Unit ファイルを作り、systemctl start tomcat とやるとエラー。でも、さほど苦労せずに動きました。systemctl からの start, stop はＯＫ。ログアウトしても止まらないし 自動起動もＯＫ。なんだ、最初からこれをやれば良かったんあだ・・・。ところが、tomcatUser で
動かしているはずなのに root で動いている。起動スクリプトに tomcatUser が存在すれば tomcatUser で起動、そうでなければ root で起動という部分があるのですが、いじりまわしているうちに壊してしまったようで、常に root で起動するようになっていました。それを修正して起動・・・動かない。またハマってしまいました。

root ならば動く。tomcatUser で起動しようとすると、起動スクリプトが正常終了した直後に stop を受け取る。正常終了後 stop を受け取るまでの間のログはなし。こんなタイミングで stop を発行できるのは systemd だけだと思うんだけど。

この時点では su tomcatUser -c で startup.sh を呼んでいたのだけれど、Unit ファイルの [Service] の User=・・ を記述すれば実行ユーザーを指定できる事になっているので、su tomcatUser はやめにして User=・・を記述して起動。

結果は変わらず。<---- 「結果は変わらず」は間違いでした。起動スクリプトを実行しようとすると「権限がない」エラーで停止した。が正しい。

起動スクリプトから systemd に戻った時に、「実行ユーザーが root でなかったら止める」みたいな事をやっているかの動きです。

これにはまいりました。使い方が悪いのか systemd のバグなのかも分からない。ググってみても情報は殆どありません。「ルート以外でサービスを起動しようとすると、ハマりどころがいっぱいある」といった記事を見つけて、そこに書いてある事をやってはみたものの、ＮＧ。
「どこから手をつけるか、何を調べるか、アイデアなし」状態です。

root でなら問題なく動くので、とりあえず root で我慢しておくか。面白くないけど。
残り作業は log lotate や時計の自動時刻合わせ、tomcat のメモリー容量、それからスクリプト内のデバッグ文の削除などなど。大した事ではないけど、疲れた。今日はこれで終わり。明日以降にしよう・・・明日は日曜日か。月曜日以降にするか。

一応の動作がＯＫなので、サーバー起動時に自動起動するように設定しようとしているのですが・・これ、次のような理由で必要だと思うんです。たとえば、UPS が持ちこたえられないほど長時間の停電があった場合、電源が復旧すればサーバー機は再起動するのですが、 tomcat は起動しない。tomcat を動かすためのサーバー機なんで、tomcat が動かないのでは意味がない。

やっているうちに、停電でもＯＳシャットダウンでもないのに tomcat が止まる事があるのに気づきました。sh startup.sh で起動した場合は、シェルを閉じれば tomcat も止まる・・これはいいんですけど /etc/init.d/tomcat start としても止まる場合がある。あ～でもない、こ～でもないとやったあげく、ログアウトすると止まるのを見つけました。

まず起動スクリプトに nohup を追加・・・ＮＧ・・・次に catalina.sh にある USE_NOHUP を true にしてテスト。これもＮＧ。なんで？

tomcat を起動した状態でプロセスを見てみると、tomcat の親プロセスは /lib/systemd/systemd --user となっていました。ログアウト～ログインしてプロセスを見ると /lib/systemd/systemd --user がいない。ググりまくった結果、【ＯＳのある部分のデフォルト値が変わった】という記事がありました。systemd の KillUserProcesses のデフォルト値が「no」から「true」に変わったとのこと。/etc/systemd/logind.conf には #KillUserProcesses=no と記述されていました。systemd が止めてくれていたようです。

このような変更は「何らかの理由」があって行われたと思うので、「KillUserProcesses = no」とすると副作用がありそうですが、とりあえず #KillUserProcesses=no を KillUserProcesses=no に変更してテストしてみました。ログアウトしても動いているように
見えたのですが、しばらくすると止まってしまいます。止まるまでの時間もまちまちで、たまたま止まった時に他の操作していたりすると「こいつが原因か」と思ったりして、泥沼状態です。

この状態で自動起動を設定して、もしうまくいったとしても、メンテナンスなどで手動で停止～起動をすると、ログアウトすれば止まってしまうわけで・・・システム全体を再起動もいやだし・・・loginctl enable-linger も必要だとかいう記事も見つけたのですが、これはこれで不安定な所があるみたいだし・・・。

この点以外には問題はないので、当面は現状のまま・・「ログアウトしてはいけない」という、とんでも仕様でやる事にしようか。疲れた。

という所で気付きました。なんで systemd が登場するの？

調べてみたら、ＯＳ前回のバージョンから systemd が導入され、現バージョンでは systemd だけになったようです。/etc/init.d 以下を「古いスタイルで」動かす場合も systemd が「それらしく」動かしてくれるらしい。なんか、解決の糸口がつかめたようです。

今日の内容は（も）テクニカルです。

サーバーがダウンした事だし、これを機会にセキュリティーの強化をしました。やった事は
（１）tomcat を root 以外で実行する。
（２）エラーページを作る。

（１）tomcat を root 以外で実行する。
tomcat を root で実行すると、何らかの攻撃にあって tomcat を乗っ取られると root 権限を奪われてしまう可能性があります。確かに対策すべきですね。

まず tomcat 専用のユーザーを作ります。これは簡単。

次に /etc/init.d/tomcat を編集して、startup.sh を起動する行を su tomcat-user -c startup.sh に変更するんですが、少しはまりました。
su tomcat-user -c startup.sh では動かない。エラーメッセージは出ないしログも出ない。どうも startup.sh が呼ばれていないみたい。いろいろやっていると、su tomcat-user --preserve-environment -c startup.sh とすれば startup.sh が動くのを発見。発見？？なぜそうなるのかが分からないので「発見」なんですね。startup.sh は動いたもののエラーの山で tomcat は起動しません。ログを見ると port80 と port443 に接続できない。あっ、そうか。tomcat-user は root ではない。1024 以下のポートは root でしか接続できないのです。server.xml を書き直して port80, port443 のコネクタを作っていたのですが、これではダメですね。
port80, port443 を削除、port8080, port8443 にproxyPort を設定しました。
再起動したら port 関連のエラーは消えましたが、「ログファイルが開けない・・権限がない」となりました。なんで？？ログファイルって、tomcat が作ったファイルじゃないの・・考えてみたら、root でテストした時のログファイルがあり,それを使おうとしていました。
所有者：root rw、グループ：root r、それ以外：none でした。tomcat-user は「それ以外」なので権限がない。ふむふむ。所有者、権限を調整して再起動。動きました。

ところが、一部のページが動かない。jsp を使っていますが、これも root でテストしていた時のファイルが残ってたのが原因でした。jsp は必要な時にコンパイルされて class ファイルが作成され、それが実行されるのですが、tomcat-user には root が作った class ファイルをアクセスする権限がなかったんですね。work 以下の class ファイルを削除して再起動。
class ファイルがなければ再コンパイルされるので、これでＯＫです。

（２）エラーページを作る。
web.xml にエラーページを定義できるので、とりあえず 404 だけ定義し、404 用のファイル err404.html を作ってテスト。ＯＫ。簡単だね。
でも、エラーごとにエラーページを作らなくてはならない。エラーの数は（数えていないけど）３０以上あります。こんなにたくさん作るのはいやだ。ネット上の情報によると、エラーページは html, jsp のいずれでも可能とあります。パラメータでエラー番号を受け取り、それに従ってエラー表示をする jsp を作ってテスト。ＯＫ。と思ったのですが、

webapps/reclibApp 以下のページは動作するのですが、webapps/root 以下のエラーページが呼ばれない。しばらくねばったのですがダメ。jsp はあきらめることにして・・・html でもパラメータが読めるので、 javascript で同様の方法を試しました。結果はＮＧ。/webapps/root 以下の html にパラメータが渡せない。調べてみると、パラメータには web.xml のエラーページの URL に書いたエラー番号ではなく、エラーを起こしたページ名が入っていました。ふ～ん、こういう仕様なのか。結局、エラーページを沢山作ることになりました。やれやれ。

時々、思い出したように書き込みをしていましたが、ブログ：WebLog のこと、log：航海日誌、日々の記録ということなので、出来るだけたくさん書くことにしました。豊富なネタがあるわけではないので、多分、面白くないし、「ためになる」事が書けるわけがない。。
このページに迷い込んだ方にはお詫び申し上げます。

サーバーアプリが動くようになったし、後はＳＳＬの設定をすれば（ほぼ）ＯＫ。なんですが、keystore の復旧に失敗してしまいました。keystore 内の情報は暗号化されていて、ファイルの中身を覗いてみても何がなんやら全く分かりません・・この状態から復旧させるのは「原理的には可能」という程度で、事実上不可能です。こうなると、ＳＳＬ屋さんに証明書を再発行してもらうしかない。

用語の説明
keystore：ＳＳＬに使う公開鍵、秘密鍵を格納したＷｅｂサーバー上のファイル。１つのkeystore に複数の秘密鍵、公開鍵の「鍵ペア」を格納できる。
alias：keystore 内の「鍵ペア」の名前。
keytool：Java の、keystore を管理するプログラムの名前。

まず、keytool で鍵のペアを作成して、それを格納した keystore を作ります。これで秘密鍵、公開鍵のペアが出来るのですが、このままでは使えません。なぜなら、鍵の発行者と「この鍵は正しい」という証明をしている者が同一だからです。いわゆる「オレオレ証明書」というやつです。で、どうするかというと、「認証局」と呼ばれる証明書発行業者に証明書の発行を依頼するんです。
証明書発行を依頼して、証明書が届くのを待ちます。数日かかりました。この証明書を最初に作成した keystore にインポートすれば完了なんですが、ここでハマってしまいました。

【もしあなたがＳＳＬの設定をしなくてはならないならば】
証明書は CSR を作成した時の keystore にしかインポートできません。誤操作などで keystore を壊してしまうと、証明書を再発行してもらうしか方法がなくなります。CSR を作成した時の keystore は必ずバックアップしましょう。keystore は単なるファイルなので、普通のファイルと同じようにコピー、削除などができます。インポートに失敗しても、バックアップがあればそれをコピーして何度でもやり直す事ができます。

keytool を使ってインポートしました。エラーもなく簡単に完了しました。Tomcat を再起動してテストすると、「alias XXXX はキーエントリを発見できませんでした」となり、動作しない。これって、keystore にその名前の鍵がないって意味じゃあないの？。

バックアップをコピーしようかとも思ったのですが、何が起こっているのか知りたかったので、もう少しねばる事にしました。

調べた結果は、「keytool が keystore に書き込む時、keystore が存在しなければ、指定された名前の keystore を作成する」のですが、keystore を作成するフォルダが問題でした。

フォルダが指定されていなければデフォルトのフォルダに作成するのですが、デフォルトのフォルダは環境変数 XXX が示すフォルダ以下の・・・なんです。どうやら Tomcat が起動しているか否かで環境変数 XXX が示すフォルダが異なるようなのです。証明者発行依頼を作成した時に Tomcat が動いていたかどうか・・なんて、覚えていない。

そう言えば、Tomcat の起動スクリプトは環境変数をいじりまわっていますよね・・・。

ファイルを検索すると、最初に作成した keystore 以外に予期していなかったフォルダにkeystore が作成されています。keystore の内容、作成日付を手掛かりに、最初に使用した keystore を特定して、その keystore に対してインポートすればＯＫ。でしょう。きっと。

keystore の名前に絶対パスを記述してインポートを試みました。最初に X.509 形式の証明書のインポートを試みましたが、「応答からの連鎖を確立できませんでした」となり、失敗。・・・X.509 はサポートされていると思うんだけど・・・
続いて PKCS #7 形式のサーバー証明書のインポートを試みる。成功。
ついでに PKCS #7 の中間証明書もインポート。これはサーバー証明書をインポートした keystore に、他と重複しない任意の alias でインポートすればＯＫです。
Tomcat を再起動してテストすると、めでたくブラウザに「鍵マーク」が表示されました。よかった、良かった。
ハマっていたのは１日半、フォルダの問題に気付いてからインポート完了まで３０分ほど。PKCS #7 形式の証明書のインポートは数秒。うまくいった時って、あっけないんですよね。

これで完了と思ったのですが、続きがありました。やれやれ。

時々、思い出したように書き込みをしていましたが、ブログ：WebLog のこと、log：航海日誌、日々の記録ということなので、出来るだけたくさん書くことにしました。豊富なネタがあるわけではないので、多分、面白くないし、「ためになる」事が書けるわけがない。このページに迷い込んだ方にはお詫び申し上げます。

という事で、サーバー復旧奮戦記（１）。
http://www.reclib.net というサイトを開設していますが、サーバーが潰れてしまいました。原因不明。サーバー機は２台あって、１台は Web サーバーとサーブレットエンジン（tomcat)、もう１台はＤＢサーバーなんですが、このうちの Web サーバー機がダウンしてしまいました。

調べてみたら・・・まともには起動しない。どうやらファイルシステムが壊れているようです。もう１台は平然と動いているのに・・なんで・・・考えてみたら、Web サーバー機はログを見るなどで、しばしばログインするのですが、どうも GUI プロセスがあまり安定ではないようで、時々電源スイッチを長押しして電源オフ～再起動などをやっていました。（サーバー機は Windows ではありません。linux です）linux に限らず unix 系のＯＳは「いきなり電源オフ」はご法度なんですが・・・。どうも、これが原因みたいですね。何にせよ、動かないんじゃしょうがない。

ファイルシステムの復旧を試みたのですが復旧できず。ファイルシステムの不整合はなくなったのですが、「整合性が取れていない部分は切り捨てる」のようで、必要なファイルがない。しょうがないので、新規にインストールすることにしました。

こういう事もあろうかと買っておいた「最新版ＯＳ」のＤＶＤを取り出してインストール。特に問題なくインストール終了。

まずは Samba をインストールします。Samba は linux 上のフォルダ、ファイルを Windows のフォルダ、ファイルであるかのように見せてくれるファイルサーバーで、ちょっとしたファイル交換なんかには便利なソフトです。Samba 配下のファイルは linux と Window の両方からアクセスできるんです。

インストールしたＯＳには「パッケージ・マネージャ」というのがあって、パッケージ（アプリに必要なプログラムをまとめたもの）単位にインストール、アンインストールできるというものなんですが、なんとパッケージ一覧に Smaba がない。こんな定番ソフトがないなんて・・・。apt get でインストール、設定して問題なく動作しました。気に入らんけど、動いたんだから、まぁいいか。

さて、Tomcat をインストール。これはパッケージ・マネージャの一覧にあったので、「これ、インストール」とマークして「適用」。問題なくインストールできました。（と、その時は思った）
テストすると、デフォルトのトップページが表示されました。簡単、かんたん。とことが、

アプリ（reclib.net のサーバー上のアプリ）をデプロイ（サーバー上に配置する事）してテストしたら動かない。ログには「情報」しか出ていない（「警告」とか「重大」とかは出ていない）のですが、とにかく動かん。ログを１行づつ読んでいくと、「情報・・・ファイルがないので・・・失敗」なんてのがありました。これ、「情報」ではなく「重大」なんですけど。
「ない」と言われたファイルは動作にかかせない（と思われる）ものなので、ディスク上で探しましたが、ない。これに気づくのに１日かかってしまいました。どうもパッケージ・マネージャかパッケージ・マネージャが見るパッケージの情報かに問題があるようです。

tomcat の大元サイトからダウンロード～インストール～設定してＯＫ。今度はサーバーアプリをデプロイしても大丈夫。アプリもちゃんと動きます。
これでＯＫ。後は SSL の設定をやったらＯＫね。

というところで、今日はここまで。