Archive for the ‘Linux’ Category

いや、そんなに大したことではない。PCのHDDを交換する件で紆余曲折し、構成や製品を決めて注文したのが、さっき届いたのだ。

当初は、全部のHDD(3台)を交換する必要があると思っていたので、新しいのを2台買って全部で3万円以上掛かる予定だった。が、良く考えて、ビデオ用のHDDは全く問題がなく、ほとんど使わないし、バックアップはあるし、壊れた場合に復旧に時間が掛かっても問題ないので、壊れるまで(あと2年くらい?)使うことにした。

それで、買うのは1台で良くなった。容量は4TBが要ると思っていたのだが、良く考えたら3TBでいいことが分かった。

製品の候補は以下だった。全部、サーバー(NAS)用の3TB品である。

  • HGST 0S03663: 約1.4万円
  • WD WD30EFRX: 約1.2万円
  • Seagate ST3000VN007: 約1.1万円

いろいろなレビューや口コミを読んだのだが、お互いに相反・矛盾していたので、とても迷った。経験上、HGSTはいい物だというのは分かっていたのだが、現在はWD傘下なので、どうも怪しい気がする。実際、回転数が7200rpmと高速のせいか、熱いとかうるさいとかいう悪評がある。ただ、Backblaze社の2016年版のレポートでは、故障率が他社(WD、Seagate、東芝)の1/3以下と良い。が、それも本当に信用できるのか、怪しい。

それでWDにも傾いたのだが、Backblazeのレポートでは一番故障率が高かったし、例のタイマー(ヘッドを頻繁にアンロードする)を仕掛けているのが嫌だったので、却下した。

残ったSeagateは悪評が高いし、僕の中でも悪いイメージなのだが、良く考えてみると、使っていて壊れたことはない。ファームウェアに問題があって交換したことがあったのと、サポートがひどかった程度だ。今使っている悪評の高い製品(ST3000DM001)ですら壊れていない。そして、回転数が5900rpmと少し低いせいなのか、熱さとか騒音についての評判は良さそうだった。

それで、一昨日はHGSTが候補だったのだが、昨日はSeagateになった。更に、Amazonを見ていたら、容量の同じ別製品(ST3000VX002)が約8800円と安かったので、それを注文した。監視カメラ用だが、24時間の連続動作を想定しているので、デスクトップPC用には充分だと考えた(Backblazeは、サーバー用でもデスクトップ用でも故障率は変わらないという見解で、実際にデスクトップ用をサーバーに使っているが、異論が多いので、本当のところは良くわからない)。

まあ、HDDは機械製品なので、結局は賭けなのだと思う。壊れる時は壊れるけど、大丈夫な物がほとんどなのだろう。故障率が高い製品・メーカーはあるが、実際に手元に来た物が壊れるかどうかは「運」ではないだろうか。僕は、今までHDDが壊れた経験はほとんどないし、この5-10年は全くない気がする。

という訳で、いろいろな賭けをしたおかげで、3万円以上だった見積もりが1万円未満になった。届いたHDDをPCに繫いだら無事認識できて、今はbadblocksというコマンドで不良ブロックのチェック中である。このチェックは、昔と違って実際には余り意味がないような気がするのだが、もし初期不良があったら交換してもらいたいので、やっている。あと3時間くらい掛かりそうだ。チェックが終わったら、データの移行を始めるつもりだ。

感想は、今のところは全く問題なく、うまく行った感じだ。騒音は(エアコンや音楽のせいか)動いているのが分からないほど静かだし、熱に関しても、不良チェックで2時間くらい酷使しても35℃くらいまでしか上がっていない(室温: 23℃)。なお、ケースを開放しておくと、通風が悪いためにHDDの温度が上がってしまうので、今は中に仮置きしている。

あと、どういう訳か、AmazonはHDDの梱包がひどいという苦情が多かったので、これにするまでは別の会社に注文するつもりだったのだが、この製品が安いのはAmazonだけなので、別のものを一緒に頼んだ。すると、目論見通り、いつもの空間たっぷりの梱包で届いた。実際には、HDDのヘッドは非稼働時には安全な位置にあるので、落下とかすごく激しい振動とか踏み潰しのようなひどいことがない限り、簡易な梱包で問題ないと思う。それに、いつもの梱包だって、ビニールで底面に固定されているので、振動には無力だ。

余談だが、この製品は2014年頃に発売された物で、箱のラベルが何となく古ぼけていたので、「何年間も倉庫に眠っていた古い物?」と心配したのだが、本体ラベルのDate欄には、"16"で始まる2016年らしき番号が書いてあったので、ちょっと安心した。それから、Amazonの製品ページでは、ラベルは綺麗なブルーだったのだが、実際には上のような色気ないものだった。まあ、ラベルで信頼性や性能が決まるわけではないので、問題ない。

製造年について: 調べたら、Dateの先頭の2桁("16")は確かに製造年を示しているが、7月開始の「会計年度」のため、僕のは2015年10月製造のようだ。1年半くらい倉庫で寝ていたようだが、その程度なら問題ないし、ちゃんと動いているので良しとする。(3/25 10:43)

ディスクのチェック結果は問題なく、(当然ながら)不良ブロックは全くなかった。それでデータの移行を始めたのだが、コピーに時間が掛かるのは仕方ないものの、Windowsからの移行の時にシンボリックリンク(Windowsの「ショートカット」と類似のもの)を多用したため、予想外に手間が掛かることが分かった。手を抜くと、いつかはそのツケを払うことになるようだ。。。 (3/24 7:15)

ファイルのコピーとシンボリックリンクの修正が終わり、ひとまずHDD交換は完了だ。いくつか気付いた点を書く。

  • 新HDDの温度は低目で、室温が15℃程度の場合、コピー中でも35℃程度までしか上がらなかった。また、アイドル時の温度は約25℃(室温: 約20℃)。ちなみに、前から使っているHGSTは約29℃、SSDは約23℃で、温度だけなら長持ちしそうな予感がする。
  • NTFS中の未解決シンボリックリンクがコピー時に空のファイルになってしまったので、スクリプトで修正した。
  • 使用しなくなったHDDを接続しないと、起動に失敗するようになった。 ← HDDのマウント時(/etc/fstab)に通常のデバイス名(例: "/dev/sdb")を指定すると駄目なようだ。ブートローダーやLinuxの以前の設定とデバイス名が変わったためか。 → デバイス名でなくUUIDを指定したら直った。 (→ 参照) 今までは大丈夫だったのだが・・・
  • 起動時・使用中に、時々、小さく短いビープ音が鳴るようになったのだが、原因不明。どこから出ているのか(新しいHDD)?? 2004年にあった、HGSTのHDDから猫の鳴き声が聞こえる現象と同類?
  • 現在の新HDDの使用量: 約1.8TB (69%), 空き: 約870GB。ここには音楽、写真、ドキュメントを入れるのだが、CDだったら千枚は入るから、HDDが壊れるまでに容量が不足する心配はないだろう。
  • HDDには関係ないが、言語を英語(LANG=C)にしてThunderbirdを起動したら、名前が日本語のローカルフォルダが扱えなくなってしまった。フォルダ名を英語にすれば直ったが、いつもながら出来が悪い。

(2017/3/25 8:06, 9:58, 11:17)

HDDに特別な高速性は求めていないのだが、興味があったので、新しいHDDの速度を測定してみた。Windowsのように安直なツールはないようなので、ちょっと調べて、ddコマンドで1Gバイトのアクセス速度を測った。他のディスク(ADataのSSDと日立(HGSTになる前)のHDD)でも測定した。

書き込み (コマンド: dd if=/dev/zero of=テストファイル名 bs=1G count=1 oflag=dsync)

  • AData SSD (SX900): 687 MB/s
  • Seagate HDD (ST3000VX002): 106 MB/s
  • 日立 HDD (HDS5C3030ALA630): 157 MB/s

読み出し (コマンド: dd of=/dev/null if=テストファイル名 bs=1G count=1 oflag=dsync)

  • AData SSD: 773 MB/s
  • Seagate HDD: 807MB/s
  • 日立 HDD: 659 MB/s

※上記はそれぞれ1-2回しか測定していないし、他のプロセスも停めていないので、あくまでも目安である。

意外にも、Seagateの書き込みは日立より遅かった。実用には充分なので問題はないのだが、理由が知りたいと思った。回転数はどちらも同等(5400-5900rpm)で、日立は3GbpsのSATAインタフェースで接続されている(Seagateは6Gbps)し、ファイルシステムはNTFSなので(Seagateはext4)、日立の方が遅くなってもいいのに不思議だ。やっぱり、昔の日立は前身のIBMの成果が残っていて優秀だったのかも知れない。それから、HDDではSATAインタフェースの速度を高速にしても、(特に書き込み速度に関しては)余り意味がなさそうだ。

なお、Seagateには音楽ファイルが入っているので、書き込み速度測定中に音飛びが発生した。

(2/25 14:47)

  •   0
  •   0

Linux Mintのデスクトップ環境は、Xfceを概ね過不足なく使っているのだが、ひとつ使いにくいことがある。ウインドウのサイズ変更をする時、ウインドウの端をマウスで掴んでドラッグするのだが、掴む領域(枠)が余りにも狭いのだ(調べたら3画素(ドット)だった)。その範囲(図中、青と赤色の部分)にマウスを入れて掴むのは結構神経を遣うし、手や眼が疲れる。

設定で広くしようと思ったのだが、設定マネージャー(Windowsのコントロールパネルに相当する)にはないので検索したら、なかなか面倒だった。Xfce(のウインドウマネージャ、xfwm4)は、ウインドウの端を画像(xpm)で描画しているので、枠を太くするには、その画像を修正する必要がある。そして、その画像はウインドウの各場所用に何個もあるのだ。左上、左、左下、下・・・といった具合で、10個くらい修正した。xpmは画像ではあるのだが、中身はテキストで記述されているので、修正はエディタでできた。

枠の幅が広いほど使いやすくなるが、見た目がかっこ悪く(スタイリッシュでなく)なってしまうので(例: 幅が9画素の場合)、試行錯誤して7画素でちょうどいい感じになった。また、Mint-Xでは、枠の色は暗い色(影を表しているのだろう)と明るい色の2色が使われているのだが、暗い色を増やすのも、明るい色だけを増やすのも今一つだったので、その間に中間的な明るさの色を入れた。画素数の配分は、暗、中、明をそれぞれ1, 2, 4画素にした。

今改めて見ると、昔のMacOS 8とか9を思い出させる気がする。おもしろいことに、Windows 7はどうなっているか、全く思い出せない(検索する気もしない)。仕事で散々使っているのだが、全然興味がない・好きじゃないようだ。いずれにしても、あれは全然美しくないだろう。

実は、この方法でも調整できない部分がある。ウインドウ上部の枠(図中、青色の部分)だ。ここはタイトル領域と枠が同じ画像になっているせいなのか、画像の高さを広げてもマウスで掴める部分は広がらなかった(もし広げられるようにするとしたら、ウインドウマネージャに画像認識機能が要りそうだ)。調整方法を検索した時に見つかったページでも、この部分に関しては さらっと何も書かれていなかった(僕が読み飛ばしたのかも知れない)。きっと、プログラム中に固定的に書いてあるのだろう。Xfceの問題点なのではないだろうか。

それにしても、いまだにアナクロ的に、こういうパーツを画像ファイルから持って来て描画する理由やメリットが分からない。これでは、ディスプレイの画素密度(分解能)が変わったら、見た目や使い勝手が全然違ってしまう。プログラムで描画すれば、いつも同じにできるし自由に設定変更できるのに。Xfceは軽量なのが売りだから、あえてそうしていないのかも知れないが、そんなに重いのだろうか。重いのなら、一度描画したものを画像にしてキャッシュすればいいと思う。

まあ、いずれにしても、いつも使う左・下・右の部分が太くなって大分使いやすくなったので、良しとした。

以下、実際に調整してみて分かった、細かいことを書く。

  • 調整する画像は、/usr/share/themes/(テーマ名)/xfwm4/left-active.xpmなどであるが、テーマによっては、存在しない場合がある。この場合は、そのテーマの元になっているテーマのものを調整する。
    • 例: Mint-X-Sandの場合には、Mint-Xのものを調整する。
  • 画像(xpm)を変更後、xfwm4 --replace & を実行すると反映されるが、&を忘れるとひどいことになってしまう。それを防ぐ、もっと手軽な方法がある。 Xfce Theme Manager(パッケージ名: xfce-theme-manager)のWindow Bordersに使用可能なテーマ名が表示されるので、それを選択すれば、即座に枠だけに反映される。
  • システムのxpmを調整する代わりに、自分のホームディレクトリに調整したものを置くこともできる。~/.themes/(テーマ名)/xfwm4である。この場合、テーマ名は自分で適宜設定する。
    • 例: Mint-X-Wide
  • どうしてか、Xfce Theme Managerにプレビューが2個出たり、プレビューが出なくなってしまう場合があるが、xpmが正しければ正常に動作するので、気にする必要はない。

(3/21 7:40 加筆・修正)

PS. 書こうと思っていて書くのを忘れていた。ちょっとしたことだが、これに前後してもう一個カスタマイズをした。ウインドウのタイトルバーの右端に並ぶボタンは、僕の使っているテーマでは最小化(_)の右に閉じる(×)ボタンがあるのだが、2つの間隔が狭いので、たまに、最小化を押そうと思って閉じるを押してしまうことがある。

それで、ボタンの間隔は変更できないようなので(こういう場合は、なかなか不自由な環境だ)、2つの間に無害なボタン(メニュー(▼))を入れた。そうすれば、手が滑って最小化の隣を押してしまってもメニューが出るだけなので、被害はない。

これをやる時、昔のMac(今はどうなっているか覚えていないし、知りたくもない)のように、閉じるを左端に置くことも考えた。それなら間違いようがない。が、それでは余りにも標準から離れてしまって、他のLinix Mintも揃えないと使いづらくなるし、何となく、作った人の意図を踏みにじるような気がしたので止めた(まあ、こんなボタン配置にした時点で、既に踏みにじっている気はするが)。

余談: UIだったか、機械の操作系の配置だったか、「安全な物と危険な物は隣(近く)に置かない」というルールがあった気がする。これは本当に重要だと思う。そういう点では、このテーマを作った人は、アフォだと思う。もちろん、メニューに「フォーマット」と「取り出し」が並ぶ窓社なんて、アフォの集団だ。

↑訂正: Mint-Xのデフォルト設定では、最小化と閉じるボタンの間に最大化があるので、上記のルールは守られていた。アフォだったのは、自分で最大化ボタンを取り除いたのを忘れて偉そうなことを書いた僕だった。(3/21 19:25)

それから、「最大化(□)」という、僕にとっては邪悪の権化とか無用の長物としか言いようがないボタンは表示しないことにしているw

Xfceのウインドウのボタンの設定

(2017/3/20 13:52)

  •   0
  •   0

検索しても見つからなかったので、Linux関係のメモを(かなりニッチかも)。

1. [Linux Mint 18] デジタルカメラをUSB接続した時に、自動起動コマンドが重複起動する場合の対処

現象: 設定マネージャーの「リムーバブルドライブとメディア」の「カメラ」で「接続されたら写真を取り込む」をOnにしている時、デジタルカメラをUSB接続すると、自動起動設定したコマンドが2回(以上)起動されてしまう。

原因: 不明

対処: (関連する設定は他になく、)Mint側では対処不可なようなので、自動起動させるコマンド(自作)側で対処した。

1. 設定: コマンドにデバイス名を渡すようにする。デバイス名は%dで指定できる。

例: /home/user/bin/import-images.sh "%d"

2. コマンド側: 2回目(以降)の起動ではデバイス名が渡されない(例の場合、引数がない)ので、その場合は何もしないで終了するようにする。

備考: コマンドが自作のものでない場合も、一旦、スクリプト(デバイス名の有無をチェックし、デバイス名が指定されていたら、本来のプログラムを起動する)を起動するようにすれば、対応可能。

2. [smartmontools] smartctlなどで、AData SX900のSMARTの属性(状態)を正しく表示させる方法

現象: smartctlやGSmartControlなどでAData SX900のSMARTを表示すると、SX900固有の属性が認識されず、デフォルトの名前と意味で表示される。 (例: #231は本来は"SSD Life Left"だが、”Temperature”となる)

原因: smartmontoolsのドライブのDB (/var/lib/smartmontools/drivedb/drivedb.h)の機種判定用のパターンが実際と異なっている(発売後にSX900の出す名前が変わった?)ため。

対処: 以下のいずれか。

a. デフォルトのDBを修正する。

"ADATA SSD S[PX]900 (64|128|256|512)GB-DL2|"の行の次に次の行を追加するか、元の行を次のように変更する。

"ADATA S[PX]900|"

b. 自分のDBを作り、smartctlなどに-Bオプションで指定する。自分のDBは、デフォルトのDBからSX900の部分(正確には"SandForce Driven SSDs"のブロック)を抜き出して、判定パターンを上のものに変更する。

 

1の解決策を見つけたおかげで、今では、デジカメを接続しただけで自動的に画像を取り込むことができるようになって便利だし、本来やりたかったことができたので、とても気分がいい。

2も同様で、今までは、GSmartControlでSX900の状態を見ると、温度(本来は残寿命)が警告になっていたりして、「使えない」ものだったのだが、これでまともになった。 更に、smartdでの状態監視も正しくできるようになったはずだ。

気になることをずっと忘れずに・諦めずにいて、考え続けたり試行錯誤したりすることは、大抵は徒労に終わるのだが、成功することもある。

  •   0
  •   0

サーバのSSL証明書をLet's encrypt(LE)にした時にThunderbirdなどが文句を言ったのは、Windows 7がLEに対応してない(LE対応の証明書が入っていない)せいだと思い込んでいたのだが、それは誤りだったことに今頃気付いた。

先日、たまたまLinux Mintのファイルマネージャでサーバと接続してみたら、やっぱり同じ警告が出たので、今日、その原因を調べてみた。すると、証明書にはサーバ自体のものと、認証局までのもの(中間証明書)の2種類があって、両方をサーバに指定する必要があったのだが、僕はサーバのものしか指定していなかったので、証明書が不完全になっていた。

そのために、ThunderbirdやLinux Mintのファイルマネージャが文句を言っていたのだ。ブラウザ(VivaldiやFirefox)はなぜか何も言わない(確認しても、「証明書は正しい」と言う)ので、問題の発見が遅れた。

それで、さっき、2つの証明書をサーバに設定したら、見事にファイルマネージャの警告が出なくなった。Thunderbirdは、最初に接続した時に警告を解除したので変化が分からないが、きっと大丈夫だろう。

それで、この問題が原因で、iPhoneがカレンダーを同期しなくなる問題が起こっていたのかも知れないとヌカ喜びしたのだが、やっぱり関係なかった。ただ、iCloudの設定を変えると、いきなりアクセスが始まるので、その辺りに鍵がありそうだ。

  •   0
  •   0

テキストエディタは、WindowsではNotepad++を使っていたのだが、Linuxにはないので、(いろいろ試した後に残った、)jEditを使っていた。まあ悪くなかったのだが、昨日、Atomが更新されたというニュースを目にして、ちょっと試してみた。以前試した時は、いろいろ不満があったので却下したのだが、しばらく経って改善されたのではと思ったのだ。

実際に使ってみると、結構良かった。僕が必要な機能はほとんど備えている。そして、表示がシンプル(jEditは昔のソフトのせいか、「ゴテゴテ」している)なのは好ましいし、最新のソフトのせいか、細かいところが使いやすそうだ。キー割り当ても、デフォルトでほとんど僕の慣れと同じだから、設定する手間がない。なお、jEditの「ハイパーサーチ」(検索結果を一覧表示して、押すとジャンプできる)と、選択した単語をハイライト表示する機能がなかったが、find-listとhighlight-selectedいうパッケージを追加したら、できた。

細かいことでは、色遣いが落ち着いていて目に優しい。jEditの色設定はいかにも「テキトー」だったので、自分で調整しろということだったのかも知れないが、いろいろな言語ごとにいちいち調整する気は起きなかった。あと、なぜか、同じフォントを使ってもjEditより綺麗なのもいい。

それから、ごく当たり前のことだが、日本語がまともに使えるのは大きい(jEditは、大抵日本語を入力できなかったので、その場合は別のを使っていた)。

今、一番欲しいのは、プログラムのブロックの範囲を左端に表示する機能だ。Atomでも、ブロックを囲む括弧({}など)同士の背景色を変えられるが、ブロックが大きくてウインドウに収まらない場合には見えなくなってしまうので、jEditの方が便利だ(そもそも、そんな大きなブロックは作るべきでないのではあるが、できてしまったものは仕方ない・・・)。

↑ 近い機能として、Atomにはブロックを畳む機能がある。ブロックの一部をクリックしてから行番号の右の空欄にカーソルを置くと、ブロックの最初の行に"V"が表示されるので、それをクリックすると、そのブロックが畳まれる。なお、jEditのブロックの範囲を示す線も、クリックするとそのブロックが畳まれる。

最後に、一番気に入らないことは、Google製であることだ。仕様や使用条件が勝手に変わるかも知れないし、いつ「終了」になるか分かったものではない。でも、その時は、別のいいものが出ていそうだから、まあいいか。

  •   0
  •   0

懸案だった、サーバのOS更新が無事終わった。更新後に再起動する時は、果たしてちゃんと立ち上がるか、少しドキドキしていた。結構大きいヤマが片付いて、一安心だ。あと4-5年は、こういった作業は不要だろう。

大きな問題はなかったのだが、いくつか気付いた点があったので、書いておく。

  • サーバには、なぜかdo-release-upgrade(OS更新スクリプト)がなかったが、パッケージupdate-manager-coreをインストールするだけで解決した。
  • テスト環境で起こった、do-release-upgradeの実行時に(Python(プログラミング言語)が)エラーになる問題は、なぜか起こらなかった。不思議だ。← 上に書いたように、do-release-upgradeを後からインストールしたからか?
  • なぜか、更新時にaptitude(ちょっと便利なパッケージ管理コマンド)が削除されたので、再度入れた。
  • テスト環境同様、更新後にrunlevel(OSの動作モードのようなもの)が5になっていたので、systemctlコマンドで2相当にしようとしたのだが、runlevelで見ると3になってしまった。でも、プロセス一覧を見ると、余計なものは動いていなかったので良しとした。おそらく、もうrunlevelも/etc/rc*.dの起動スクリプトも意味がないのだろう。だったら削除してほしい。。。
  • 作業で一番時間が掛かったのはバックアップで、圧縮後のサイズが9GBくらいになるせいか、1回80分くらい掛かった。更新自体は、最初は40分、2回目は20分くらいで終わった(それも結構長い気はする)。

そして、やっぱり、何をするにしても、特に、リスクのあることだったら、充分な準備をする価値はあると思った。

(23:47 若干加筆)

 

PS. みんなやっていることかも知れないけど、僕がコマンドライン(ターミナル)で作業をする時は、以下のようにしている。

  1. 実行するコマンドや順序を考えて(あるいは、どこかのページからコピーして)、どこか(例: Dropbox PaperやEvernote)に書く。
  2. それをターミナルにコピー・ペーストして実行する。

コマンドの例(PHPのバージョンを5から7に):
sudo aptitude remove php5
sudo aptitude install php php-cgi php-cli php-curl php-fpm php-gd php-intl php-mysql php-sqlite3 php-ftp php-net-socket php-sockets php-mbstring php-zip php-pdo-mysql php-exif php-apcu

こうすると、後で同じことや同様なことをするのが楽だし、何を実行するかあらかじめ考えるから、間違いが起こる可能性が減る。それに、上のような長大なコマンドだって、タイプミスせずに一発で打てる。更に、何をしたかの記録が残るから、後で何か問題が起こった場合にも、その時実行した処理に問題がなかったかを検討することができる。

また、トラブル対処などで、その場で(アドリブで?)コマンドを実行してしまった場合でも、なるべく、実行したコマンド文字列をコピーして、「**したら動いた」のように残すようにしている。

上のように書くと、「コマンドラインなんて古臭くて面倒だな」と思う人が多いかも知れないが、逆に便利だと思う。もし、GUIで上のPHPの例と同様な作業を記録するとしたら、「*を起動して、*を検索して、*と*と(中略)と*にチェックを入れて、インストールボタンを押す」なんて書くか、スクリーンショットを撮るしかないだろう。

前者の場合、オプションが多いと書くだけでも面倒なうえに、後日再実行しようとしてもコピー・ペーストは無理だから手間が多くなるし、後者の場合、手間に加えて、画像中の文字の検索は無理だから、後で調べるのが困難になるだろう(Evernoteは文字認識するから、検索できるかも知れない)。

  •   0
  •   0

ブログサーバーのOSを更新するため、2/26(日)に本サーバーを停めます。作業終了までは、断続的な動作になる可能性があります。

その日のうちに復帰する予定ですが、予期せぬ問題が起こった場合は、しばらく停まる可能性があります。

作業が終わりましたら、この投稿に追記してお知らせします。

よろしくお願いします。

2/26 10:56: 無事、OSの(2段階)更新が終わり、動作確認中です。ここまでの所要時間は約3時間でした。大きな問題はなかったです。

2/26 13時 動作確認が終わりました。正常運用に戻りました。

  •   0
  •   0

想定外のことがあって、しばらく休みになった。自宅謹慎とかではなくて、インフルエンザである。それで、懸案のブログサーバーのOS更新を試してみた。KUSANAGIを使わないのであれば、確認・移行用に新たなサーバー(VPS)を借りなくても、自分のPCに仮想環境を作って、無料でいくらでも試せることに気付いたのだ(KUSANAGIも仮想マシンを配布しているのかも知れないけど、使う気がないので、パスした)。

試した結果は、いくつか気になる点や注意事項はあるものの、現行のサーバーをインプレースで(「上書き」)更新しても大丈夫そうだった。今日1日(実質半日)で、仮想環境で、古かったOSを最新版に更新でき、テスト用ブログサーバーが動いた。しかも、PHPを7.0にしたせいか、何もしなくても4倍くらい速くなった。

最も気になるのは、「ゴミ」である。今使っているOSは古いため、最新版に更新するには、2回(2段階で)更新する必要がある。その過程でゴミが残って(あるいは、不足が生じて)動作に悪影響がないかと、今までの数年間の運用や試行錯誤でさまざまなゴミが溜まっているだろうから、その影響も気になる。

もしゴミをなくしたいなら、新しいサーバを借りて、最初からセットアップするべきだが、それはかなりの手間だ。

まあ、趣味だし、とりあえず動いたから、上書き更新でもいいような気がする(が、今までの経験上、そうやって手を抜くと、あとで思わぬトラブルが勃発して慌てるのだが)。それならほとんど時間が掛からないでできるし、トラブル対処の勘所も分かったので、もう少し考えてみよう。

以下は、更新に当たって起こったできごとや注意事項などのメモである。OS名を明記しないので、余り参考にならないかも知れない(が、よく読めば、自明なはずである)。

  • OSの更新は、基本的に、do-release-upgradeコマンドでできる(これは、ご丁寧にも、古い版のOSにログインした時に表示されたので、何も調べなくても分かった)。ただし、更新が失敗する場合やパッケージがあった。
    • 1つ前の版から最新にする時、do-release-upgradeが実行できなかった。これは、pythonが古くてaptというモジュールがなかったからのようで、一旦削除してインストールしなおしたら、動くするようになった。
    • mysqlのDBのディレクトリ名(/var/lib/mysql/*)に異常なものがあって、更新に失敗した。使っていないものだったので、そのディレクトリを削除したら成功した。
  • 現行サーバーの環境をコピーするため、ディスクの内容を新しい仮想環境に上書きしたのだが、ファイルの選択がいい加減だったので、/etc/fstabまで上書きしてしまい、ディスクのマウントがおかしくなってしまった。まあ、当たり前のことであるが、/が読み出しのみでマウントされて、fstabの修正もできなかったので、手で読み書き可にマウントしなおして編集できるようにした。
  • PHPはパッケージ版を使ってみた。すると、php-fpmはなぜか/etc/rc?.dから起動できず、プログラムの場所も分からず、再起動するにはOSを再起動しないといけなくて、面倒だった。良く調べたら、場所は/usr/sbin/php-fpm7.0だった。また、なぜか、/etc/init.d/php7.0-fpm startなら起動した。起動スクリプトの仕様が変わったようだが、他にも同様なことがあるので、要調査だ。
  • パッケージ版のPHPは、現在ビルド時に指定している、さまざまなモジュールをapt-getに"php-curl"のように指定して追加すれば、今使っているものと同等の機能のものがインストールできた。
  • 当然ながら、パッケージ版のPHPに移行するには、元々の(自分でビルドした)PHP関連コマンドを削除しないと、誤動作する。
  • ブログ(WordPress)を正しく動作させるためには、仮想環境にドメイン名を付け、それに合わせて、webサーバの設定とWordPressの設定(設定ファイルと「サイトアドレス」)を変える必要があった。webサーバの設定はもう少し綺麗にしたいが、仕様が難解で難しい。。。
  • ブログでは、以前PHP 7を試した時に生じた問題(ウィジェットの設定画面がおかしい)が再発した。しかし、検索しても同様の問題はないので、更に調べたら、自作のウィジェットが原因だった。一部の標準ウィジェットをカスタマイズするため、コピー・変更して使っていたのだが、その使い方がPHP 7に互換でなかったようだ。これはフックにできないだろうか。
  • PHP 7.0にしたら、ブログの表示は約4倍速になった。ただし、正規表現での検索は10倍くらい遅くなった。自作したものなので、効率の悪い点がありそうだ。また、ページを最初に表示する時は遅い。これは、PHP 7.0の動作(JITやキャッシュ?)に関係しているのかも知れない。
  • もう一つのブログや他のwebサービスも、問題なく動いている感じだ。
  • カレンダー・アドレス帳サーバーは、最初は予想外のエラー(HTTP 400)が出て動かず、ちょっと苦労したが、何とかなった。設定の、「信頼するドメイン」に、サーバー自身のドメインを追加する必要があるようだ。それがどういう意味なのか(自分すら信頼できないのか??)、今ひとつ分からない。
  • パッケージ版のwebサーバーも試したが、ログやSSL証明書の場所の設定を若干修正する程度で問題なく動いた。僕の用途では、最小構成で充分なようなので、得した気分だ。(20:47)
  • パッケージ版のPHPのバージョンは最新ではなく、約3か月遅れで、辛うじて許せるレベルだ。一方、webサーバーは、約10か月遅れなので、ちょっと古い感じだ。今までwebサーバーの問題を見たことがないから古くてもいいが、心配なのは、セキュリティ面だ。
  • https(SSL)の証明書は、現行サーバからコピーしたものではブラウザに文句を言われたが、sshの鍵は、コピーしたものがそのまま使えた。確かにそういうものだが、本当にそれでいいのかと思う・・・
  • OSを仮想環境にインストールしたせいか、runlevelが5(デスクトップ用らしい)になっていて、時々文句を言われた。直し方は不明だが、とりあえず動いたし、実環境は2なので、問題ない。

(2/16 17:21追記) その後、準備や調査をした結果を書く。

  • php-fpmが/etc/rc?.dから起動できなかった問題は、Linuxの起動時のプログラム起動システムが(、さまざまなものを経て、)今は、systemdというものに変わっているためだった。ただ、昔ながらの起動スクリプト(/etc/init.d/*や/etc/rc?.d/*)も残っているので、それを使ったら騙され失敗した。何とも中途半端だ。だから、php-fpmは、正しくはsystemctlコマンドで起動するべきだったのだ。だが、これもいつまで続くか分からないし、手で自作のサーバープログラムを追加するのは面倒そうなので、なかなか覚える気がしない。
  • ランレベルも同様で、昔は設定ファイル(/etc/inittab)があったのに、今はなくなっていて、"systemctl set-default multi-user"などのようにして変更するそうなので、分かる訳がなかった。
  • なかなか苦労して、webサーバの設定をかなり綺麗に簡素にでき、行数を半分以下にできた。今までは、文法が難解なので、いろいろなサイトのコピーをベースにして、おそるおそるいじっていたため、ゴミが多かったのだが、今回は観念して腰を据えて、気合を入れて文法を理解しつつ抜本的に作りなおしたので、「どうしてこうなんだろう?」という箇所はなくなり、ゴミもほぼ0になった。また、非推奨の処理もなくせた。でも、これがサーバの高速化に繋がるかと言えばそうでもない。だが、保守性の向上とかセキュリティホールができにくくなることには繋がる。以下に新旧の行数の比較を載せる。
    • 現行: 705行 (2ファイル)
    • 改良後: 310行 (4ファイル)
  • 自作のウィジェットがPHP 7.0でエラーになる問題も対処できた。どういう訳か、作成当時にエラーになったので止めていた方法(元になるウィジェットのサブクラスを作る)がすんなり通ったので、PHP 7.0でのエラーは起こらなくなり、コピーの部分もほとんどなくなった。不思議なことに、それが今のPHP 5でも通ったので、当時のPHP 5にバグがあったのか、僕の思い込みだったのか不明だ。

そんな訳で、OS更新までに残る作業は、作り直したwebサーバの設定の動作確認程度である。これが、(手でやる場合には)拒否・通過設定しているURLをブラウザで1個1個開いていくという、なかなか手間が掛かるうえに間違いやすい作業なのだが、設定修正のたびに繰り返すのは嫌なので、確認用スクリプトを作って自動化したいと思っている。

(2/18 17:02追記) その後、サーバのセキュリティ関連設定確認用スクリプトを作って確認し、問題を見付けて修正して、問題なくなったことが分かったのだが、その後でブログを見たら、みごとに崩れていて、とても参った。「完璧な設定」に見えたのは、どうも、サーバの各種プログラムの不思議な動作(いちいち停めないと駄目だったり、OSの再起動すら要る場合がある)やブラウザのキャッシュによって作られた「幻」だったようだ。

今でも、「修正できたと思ったら、実は駄目だった」の繰り返しである。このwebサーバは、なかなか一筋縄に行かないようだ。

それから、その設定確認用スクリプトを作っている時にも、大いにはまった。スクリプトは、準備として、外部(web)からアクセスできない場所にファイルを作る(それをアクセスしても、サーバの設定でブロックされることを確認する)のだが、2回目に実行すると、必ずサーバにssh接続ができなくなってしまう。いろいろな原因を疑って一つずつ潰して行ったのだが、原因が分からなかった。そして、試してみたら、現行のサーバでも同じ現象が起こった。それで、かなり悩んで、ふと、(自分で設定した)IPフィルタ(簡易なファイアウォール)かも知れないと思って調べたら、本当にそうだった。

ブログサーバを立ち上げた頃に、sshを頻繁に繰り返す攻撃を無効化する設定を、どこからか見付けて入れていたのだ。その後、そんな設定をしたなんてことはすっかり忘れていたのだが、今回の設定確認用スクリプトは、確認用ファイルを作るために、まさに頻繁にssh接続するので、すぐに限界(例: N回/時間)に達してしまっていた。OS更新テスト用の仮想環境も、ブログサーバの内容をほぼまるごとコピーしたので、設定が有効になっていたのだ。全くあてにしていなかったのにちゃんと動いてくれてうれしかった反面、思わぬ落とし穴にどうしたものかと思った。

一時的に無効にすることは可能だが、何度もやるうちに戻し忘れるのが嫌だ。それで、いろいろ考えて、確認用ファイルの作成と削除は、1ファイルごとにssh接続せず、まとめて1回のsshで実行するようにした。その(長々とした)コマンドを作るのがかなりの手間だったが、とりあえず動いて、問題は起こりにくくなった。めでたし、なのか??

(2/19 8:30追記) 大変な苦労の末、サーバの設定の改良が終わった。仮想環境では再起動しても壊れなかったので、おそらく大丈夫だろう。そして、今朝、実サーバにも適用した。いくつか問題が見つかったので、修正した。今のこれが幻でないことを祈るばかりである。

ちょっと残念なのは、いくつか、例外的な「汚い」処理が必要だったことだ。まあ、今の僕の技量ではそこまでってことだ。でも、今までの設定に比べたら、随分まともになったと思う。そんな訳で、設定の行数は361行に増えた。

  •   0
  •   0

ブログサーバーのOS更新の件。

KUSANAGIについて、一番気になっている点(複数のブログ/httpサービスが実現できるのか)を調べたのだが、ドキュメントが貧弱過ぎて、確実なことは分からなかった。あと、全体をKUSANAGI固有の環境とか操作手順(コマンド)に変えてしまっているのが、(僕に言わせれば)何ともセンスが悪い。更に、セキュリティについては、元々良い訳ではなく、自分で設定を変更して向上させる必要があるようだった。しかも、そのレベルが低い。「(独自環境にしたんだから)そんなのデフォルトでやっとけよ」って感じだ。

そして、こんな(言い過ぎかも知れないが、いい加減な)会社に少なくとも10年も依存していいのかという疑念すら生じた。例えば、WordPressの更新がリアルタイムにでき(てい)るのだろうか? とか、数年で会社がなくなることはないのだろうか? などだ。そもそも、高速化しなくたって、何も問題はないのだ。

大体、あのキャラ(わざわざそんなのを作ったこと自体)も、起動時の大げさなバナーも全然気に入らない!

そんな訳で、僕の体温に反比例して、KUSANAGI熱は一気に醒めてしまった。

CentOSについても、10年のサポート期間は魅力だが、(今使っているOSの)5年だって大きな問題はないと思える。5年に1度、ちょっと手間を掛ければいいだけだ。逆に、10年も経つと、次のOSはものすごく変わっていて、更新は更に大変ではないだろうか。仕事でCentOSを使う可能性はあるが、そんなの会社でやれば充分で、自宅でまで苦労したくない。OSなんて、(WindowsやMacのなどを除いて)何だって良くて、ちゃんと動けばいいのだ。

という訳で、今は、今使っているOSの最新版に更新する方向に傾きつつある。

  •   0
  •   0

このブログサーバーのOSは、かなり古い。まだサポート期間内だが、もうすぐ切れる。それで、そろそろ最新版に更新しようかと思っている。それで、昨日、手順や起こりうる問題などを考えたり検索したりしていたら、思わぬ新機軸が見つかり、それまでの考えとは全く違う方向に行く(暫定の)結論になった。

まず、コンセプトや目指すところは、それまでの「現状維持」(単に今のOSを更新する)から、以下になった。

  • 管理の手間を減らす。
    • 毎月のようにPHPを更新(ソースからビルド)しているが、もう止めたくなった。
    • Webサーバの更新も、頻度は低いが、やっぱり面倒。
  • ブログの高速化 : 遅くても問題はないが、速い方が気持ちいい。

手段としてはKUSANAGIというシステムに移行する。

実際には、使っているサーバー会社のサポートするOSのページを見たら、KUSANAGIもサポートしているのを知り、それ(以前見たことがあるのだが)を使えばブログ(WordPress)を劇的に高速化できそうなことに気付いた。しかも、WordPressの環境が最初から全部構築されているので、PHPやwebサーバーなどの更新は自動で行われそうだし(そうでなくても更新のコマンドを実行するだけだろう)、Let's encryptのSSL証明書のサポートも入っているようなので、管理の手間がかなり減りそうなことが分かった。

KUSANAGIでは、副次的ではあるが、セキュリティの強化も期待できそうだ(少なくとも今よりは良くなりそうだし、自分でセキュリティに配慮する負担は減るだろう)。更に、新しいLinuxの勉強もできそうだ(というか、しなくてはならない)。というのは、サーバー会社が提供するKUSANAGIはCentOSで動くのだが、(それは今と同じLinuxではあるが、)系統が違うので、管理方法や操作が若干異なる。でも、仕事で使いそうだし、覚えておいて損はないと思う。また、CentOSはサポート期間が10年と長いのが魅力的だ(今のは5年程度)。

次に、移行手順だが、今使っているサーバーをいきなりKUSANAGIに変えることは無理だし危険だし苦労が多いので、そうはせず、「軟着陸」させる。

実際には、今のOSを更新するだけと考えていた時から、直接更新せずに一旦別のサーバーを借りて、そこで動作確認してから移行することを考えていた。それで、サーバー会社のページでKUSANAGIを見つけたのである。

移行手順は以下を考えている。

  1. 移行先のサーバーを借りる。(OS=KUSANAGIで設定)
  2. 新サーバーに、仮のドメイン名を付ける。(サーバー会社が提供するのが使える?)
  3. 新サーバーに、今のサーバーのコンテンツなどをコピーする。
  4. しばらく(3か月以内を目標)、動作確認と調整を行う。
  5. 新旧サーバーの切り替え
    1. 新旧サーバーのwebサーバーを停止する。
    2. 新サーバーのコンテンツを最新にする。
    3. 新サーバーのドメイン名を今のに変える。
    4. 新サーバーのwebサーバーを起動する。
  6. 仮のドメイン名の契約を終了する。
  7. 新サーバーの安定動作を確認後(3か月程度)、旧サーバーの契約を終了する。

移行期間は長くて半年程度と考えているので、コストは1万円未満(新旧サーバーの重複期間の使用料+仮ドメイン名の費用)だろう。

懸念事項は以下である。

  • KUSANAGIに致命的な問題がないか? → 出てからしばらく経っているので、大丈夫では?
  • いつまでKUSANAGIが続くか? → 終わったらまた考える。どうせ、後継が出てくるだろう。
  • 今使っているWordPressの機能・設定・プラグインが全部動くか。→ 駄目な時は代替を探す。
  • PHPが高速版(HHVM)に置き換わるが、他のPHPのプログラムが問題なく動くか。→ 動作確認して、調整する。それでも駄目なら、HHVMを使わない。
  • 自分で追加した機能がうまく移行できるか。→ 同等のものがKUSANAGIにあればそれを使い、なければ自分のを動かす。
  • HHVMがFacebook製なのが気に入らない。→ MSよりはマシなので、我慢する。
  • "KUSANAGI"とか"HHVM" (Hip Hop VM)とか、名前が気に入らない。KUSANAGIのキャラも気に入らない。→ 我慢する。
  •   0
  •   1