Linux」カテゴリーアーカイブ

VPNの設定が非常に苦労した… RTX810系+Win10編

ということで、とある出張に出かけたときのこと。ビジネスホテルに宿泊したときにこういう状況になることはよくあると思います。

  • ビジネスホテル側からWi-Fiもしくは有線LANが無料で提供される
  • ビジネスホテル側の通信環境そのものはそこまで悪くはない
  • ただし、通信先を知られたくないorデータサーバへの通信が必要なパターンがある

このような状況を解消するためによく使われるのがVPNなのですが、Win10の標準でVPNを構築しようと思ったらRTX810の設定とかなりかみ合わずにつながるまでに四苦八苦したので、その記録を書いておきたいと思います。実は設定の書き換えも外部から行っており、SSHを通せるようにしておいたからなんとかなったようなものなのですが…。

 

RTX810で使えるVPNの種類

いまだとちょっと古いルータになるので微妙なのですが、とりあえずRTX810上から設定できるVPNの種類を確認しておきましょう。実はターミナル上から手動ならばIKEv2が設定「できそう」に見えるのですが、これに成功したことがないので、GUIで設定できる方だけに限定しておくと

  • L2TP/IPSec
  • PPTP

あたりが可能です。ただし、PPTPはすでにセキュリティ的に使うべきではないレベルなので除外されて、L2TP/IPSecくらいになってしまいます。ちなみに、Twitterでもすこしつぶやきましたが、L2TP/IPSecはAndroid12系統では設定できなくなっているのでそうなってくるとAndroidで考えたら一つもない、という話になってしまいます。Win10であればL2TP/IPSecは標準で利用可能なので今回はそちらで設定します。

 

Win10でL2TP/IPSecによる接続を行うためのサーバ(RTX810)側の設定

今回はまってしまったのは実はこれです。Win10でL2TP/IPSecを使うときに「いくつかの設定をするとアルゴリズムが利用できないために接続不可になる」という現象が発生する、ということがわかったのがかなり後(いろいろと検索してみてやっと出てきた)だったのが痛かったです。具体的にはこのようにします。

  • 接続タイプ:L2TP/IPSec(Anonymous)
  • 接続ユーザIDおよびパスワード:適当に
  • 事前共有キー:適当に
  • 認証アルゴリズム:HMAC-SHA (HMAC-SHA256では認証不可になってしまう)
  • 暗号アルゴリズム:AES-CBC (AES256-CBSでは認証不可になってしまう)
  • キープアライブ:使用する
  • NATトラバーサル:使用する
  • PPP認証方式:MS-CHAP v2

ここで書いているとおり、認証アルゴリズムと暗号アルゴリズムがWin10標準のVPNだと制限されてしまう、ということです。暗号強度を上げておこうかと思って上位の設定をしていたのがまさか裏目に出るとは。ちなみにこれより暗号強度が低いアルゴリズムは逆にVPNとしての安全性を(現段階でも)保てないので論外です。今でさえこのアルゴリズムだと不安になりつつあるのに…。

あと、ちゃんとIPSecパススルー設定などに相当するespやUDPのPort500、1701、4500は通しておかないとつながりませんからね。

 

Win10でL2TP/IPSecによる接続を行うためのクライアント側の設定

こちらは適当に検索をかけると出てくる項目を片っ端からやっているのでどれが正解とかはあまり書くことができません。大事そうなのが

  • NATトラバーサルを有効にするためにレジストリの設定を行う(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgentにAssumeUDPEncapsulationContextOnSendRuleの値をDWORD型で2にセットする)
  • 接続の設定を作った後にネットワークの「アダプターの設定」から対象のVPN接続のプロパティを開き、「セキュリティ」の設定をサーバ側の設定と合わせる。ネットワークの設定でIPv6の設定を外した方がよい場合は外しておくこと
  • たまに一部のサービス(IKE and AuthIP IPsec Keying Modulesなど)が動いていないことがあるらしいのでそれを動かしてみる
  • ファイアウォールのアプリケーションごとの許可から「ルーティングとリモートアクセス」を許可する

といったところでしょうかね。特に最初の設定はほぼ確実に必要だと思われます。これを設定してから再起動してもつながらなかったら…後何が必要なのでしょうかね。

 

まず出張に行く前に接続できるか試しておきましょう

何事も事前準備が大切です、という当たり前のことを書いて終わりにしておきたいと思います。

48TBファイルサーバに起こった異変から大修理に(3) 再同期完了編(交換2台目)

今回の話はそこまで怖い話ではなく、単に流れをみているだけです。

 

8番目の交換が完了した時点で3番目のHDDはどうなっていたのか?

SMARTの出力で主要な部分だけ書くとこんな感じです。

…
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       112
…
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
…
ATA Error Count: 2
…
Error 2 occurred at disk power-on lifetime: 11521 hours (480 days + 1 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 53 00 ff ff ff 0f  Error: UNC at LBA = 0x0fffffff = 268435455

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 00 58 ff ff ff 4f 00      00:06:58.915  READ FPDMA QUEUED
  60 00 58 ff ff ff 4f 00      00:06:58.913  READ FPDMA QUEUED
  60 00 58 ff ff ff 4f 00      00:06:58.913  READ FPDMA QUEUED
  60 00 00 ff ff ff 4f 00      00:06:58.909  READ FPDMA QUEUED
  60 00 58 ff ff ff 4f 00      00:06:58.908  READ FPDMA QUEUED
…

SMARTの状態を知っている人ならわかると思いますが、Reallocated Sector Countが出ている時点ですでに危険な状態です。とりあえず予備のSectorでカバーできているけれども使えないSectorが出始めている、という意味です。これが行き過ぎると不良セクタが発生してデータ破損につながります。なので、もうこれは交換しないと近々故障することが確定しているディスクとなります。しかも、Read Errorについてもこちらに報告されているということはその意味でも故障寸前ということが推察されます。ちなみに、この修復作業をする前はReallcated Sector Countは数十セクタほどで、Read Errorに関する報告もSMARTからは出ていなかったので、resilver作業によってかなり危険度が増していることになります。

 

今回の交換はそれほど難しくはない

というのも、前回の話のせいで何回もresilver処理を行っている(この場合はscrub処理に近い処理を行った、という意味も含まれる)ため、ZFS側のファイル破損の可能性はほとんどない状態ということで、ZFSにおけるストレージ1つ分の交換処理だけですむからです。これに関しては本当にこちらの記事を読めばOKです。HDDの場所もしっかり確認しているためその手の問題はありませんでした。

 

修理するために使った金額はいくら?

結局交換用SATAインタフェースカード(SATA3-6I-PCIE×2)+故障したHDDの交換分(2台分)ということになります。約5万円ですか。ちょっとした出費となり痛かったです。

 

破損したファイルはほかにあったのか?

なんとか初期に発覚した1つだけで済んだようです。といっても破損したファイルのデータは全く戻ってこないので痛いですね。なお、ZFSの領域は私の設定だと圧縮領域なので途中でデータ破損がすればまず間違いなく破損部分以降の読み出しは不可能で、アーカイブファイルにリカバリレコードをつけることで…とかは全く意味がなかったことも付け加えておきましょう。圧縮領域でなければ読み出せたのか?といわれるとおそらく無理、となるのでしょうが。

 

こうならないように故障の前兆はつかむようにしましょう

今回はSATAインタフェースカードとHDDの同時故障が原因だったのでなかなか難しいところではありますが…。SATAインタフェースカードの場合はdmesgなどでI/Oエラーが出ていないか?がチェックの対象になりますし、そうでなかったとしてもzpool statusから見ることができるエラー状況は「なぜ起こったのか」をSMARTやdmesgなどである程度理由をつかんでおかないといかにRAID-Z2といえども危ない状況になることはある、というのが今回の教訓ですね。つまりは定期的にPCの状態は確認して管理しましょう、というところですか。あとはzpoolの修復も途中のエラーによってはやり方を変えないといつまでたっても終わらない、ということがわかってよかったです。日本語の記事でこれに言及しているものがほとんどなく、英語の記事でも詳細なものはほとんどない様子でしたので。もしzpoolの修復の話でこの記事にたどり着いた人は前回修復手順を参考にしてみてください。

48TBファイルサーバに起こった異変から大修理に(2) 交換1台目編(ZFSが大変)

副題に補題がつくほどこの作業が大変だったわけです。というか、これで1週間ほどが過ぎ去ったので記事が遅れた、という側面も否定できません。ということで、何が起こったのかを時系列をおいながら書きたいと思います。前回からの続きとなります。

 

SATAインタフェースカードの交換作業

単純に「SATA10ポート×1枚」を「SATA6ポート×2枚」にする作業です。ただし、対象のSATA3-I6-PCIEはPCI Express3.0 x2なので、それがささる場所が必要です。今回使っているM/Bがグラフィック用のPCI Expreess3.0 x16形式が2カ所あるタイプだったのでその2カ所を使うことでこの問題をパスすることができました。(もちろん、それを知っていてこの組み合わせにしています)

あとは「HDDの認識順番に合うように」SATAケーブルを接続する、という作業です。SATA3-I6-PCIEは前回のSATA3I10-PCIEとは異なり物理コネクタ位置と認識順番は一致しているようなので、よりCPUに近い側が認識順番が早いだろうという考えの元接続作業を行えば完了です。本来ならば一度サーバOSとは別環境でHDDがどの順番で認識するかチェックする必要があるのですが、そのあたりは説明書等で確認してしまえばそれほど問題はありませんでした。

 

SATAインタフェースカードを交換すると…先に8番目のHDDが異常に

実はこれが完全な予定外な案件でした。SATAインタフェースカードを交換すればあとはscrub処理をかけて、不良セクタが出かかっている3番目のHDDを交換して…と考えていましたが、先に8番目のHDDがSATAコマンドの送受信でエラーとなってしまってかなりまずい状態になってしまった、というところから今回の交換が大変になってしまった訳です。仕方がないので3番目の交換は後回しにして8番目の交換だけ行うことにしました。

ただし、すでにZFSのコマンドを使って8番目のHDDを切り離して…という処理をしている余裕がない状態だったため、物理的にHDDを切り離して交換用のHDDと取り替えた上で再同期処理を行う、という手順に出ました。詳しい手順はこちらの記事で。

 

再同期処理でエラーが発生

そして再同期中にエラーが起こってしまうわけです。おそらく前回のタイミングかそれより以前のタイミングでファイルが破損してしまったのでしょうね。こんな感じのエラーが出ます。

  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since (日時)
        12.4T scanned at 426M/s, 5.85T issued at 201M/s, 41.4T total
        749G resilvered, 14.12% done, 2 days 03:29:48 to go
config:

        NAME                       STATE     READ WRITE CKSUM
        tank                       DEGRADED     0     0     0
          raidz2-0                 DEGRADED     0     0     0
            zfs1                   ONLINE       0     0     2
            zfs2                   ONLINE       0     0     2
            zfs3                   ONLINE       0     0     2
            zfs4                   ONLINE       0     0     2
            zfs5                   ONLINE       0     0     2
            zfs6                   ONLINE       0     0     2
            zfs7                   ONLINE       0     0     2
            replacing-7            DEGRADED     0     0     2
              1914476987721512675  OFFLINE      0     0     0  was /dev/disk/by-partlabel/zfs8/old
              zfs8                 ONLINE       0     0     0  (resilvering)

errors: Permanent errors have been detected in the following files:

        /tank/data/dat.zip

ちなみに日時とファイル名はちょっといじってありますが、こんな感じです。resilverの作業中にファイル破損(しかも永続)が見つかってしまった、というものです。これが起こってしまうと対象のファイルのデータは基本的に取り出すことができない、という致命的な問題です。もうこれに関しては諦めるしかありません。SATAインタフェースの問題ですのでコマンドの発行ミスがあればデータもバグが出るでしょうからそんなものだと思います。

問題はこの後です。とりあえず起こってしまったことはしょうがないので取り合えずresilver作業が一巡してZFSのRAID-Z2が復旧してからファイルの状態を確認して…見ようとできなかった、というのが今回の主題です。

 

なぜかRAID作業が終わらない

で、放置して再同期が終わったはずのポイントでzpoolをチェックしてみるとなんと勝手にresilver作業が2周目に突入するという事態に。は?と思いましたよ。わけがわからずとりあえずresilver作業を止めたかったのですが「止められないやめられない」(ちょっと違う?)状態に。detach処理を行っても結局裏で構築している様子で止まることなく再同期。ちなみにエラーが出たファイルをしてもエラーが解消される訳でもなくこんな状況に。

errors: Permanent errors have been detected in the following files:

        tank:<0x7a0>

マジでどうしよう?でした。ちなみに、途中で「ファイルが削除されてCHECKSUMエラーが検出されなければresilver作業は終わるのでは?」と考えてzpool clearもかけて見たのですが結局解消されず、なんと3周目に突入するという訳のわからない状態となってしまいました。この間にも実は3番目のHDDがRead Errorを起こしたりと非常に危険な状態になっていました。すでに不良セクタが出かかっている状態なのでさもありなん、というところでしょうか。

 

再同期作業を停止させて一度zpoolをエラーがない状態に戻す必要が合った様子

仕方がないので3周目の再同期を強制的に停止すべく、「一度サーバを物理的に停止させてHDDの認識を外す」処理を行いました。あまりよくない作業ですがね。ちなみにresliver処理は再起動程度では停止させることはできませんのであしからず。ちゃんと前の状態を記憶して再同期しようとする優秀な機能(微妙に皮肉)です。

さすがに物理的にHDDが切り離されれば再同期対象のHDDがありませんので作業は一気に進み、とりあえずRAID-2Z全体から見ればDEGRADED状態ながらresilverは終わりましたので、Permanent errosを取り除く必要があります。が、どうも以下の手順がいるようです。

  1. Permanent errorsとなっているファイルを削除(今回はすでに削除済み)
  2. Permanent errorsをリセットするために一度scrub処理(今回はHDDを切り離した後のresilver処理が代わりとなった)
  3. 状態をクリアするためにzpool clearを発行

本来は1~3の処理が必要のようですが、再同期処理などが代わりとなってPermanent errorsを解消することに成功したのが大きかったです。scrub処理は3番目のHDDがかなり危険な状態になっていますので行いたくなかったのですが、しなくても何とかなったのでよかったです。ちなみに、ここまでに(故障に気がついてから)2週間ほどかかっています。

 

Permanent errorsがなくなればあとは再同期処理をもう一度発行するだけ

やっと終わりましたので再度HDDをつなぎ直してrepairを行います。実はこの作業もかなり祈りが必要な状態でした。3番目は壊れかかっていますのでまた読み込みエラーなどが出たら再同期に失敗する可能性もありますし、また破損ファイルが出てくると同じような作業を行ってエラーを解消しないと再同期できないことはわかっている状態なので、致命的なエラーだけは出てほしくない場面でした。で、3日間ほど放置して結果としては

  pool: tank
 state: ONLINE
  scan: resilvered 5.18T in 2 days 11:17:26 with 0 errors on (作業開始日時)
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            zfs1    ONLINE       0     0     0
            zfs2    ONLINE       0     0     0
            zfs3    ONLINE       0     0     0
            zfs4    ONLINE       0     0     0
            zfs5    ONLINE       0     0     0
            zfs6    ONLINE       0     0     0
            zfs7    ONLINE       0     0     0
            zfs8    ONLINE       0     0     0

errors: No known data errors

と、なんとか一度再同期作業が成功して一息つけた、というわけです。

 

最後に3番目のHDDを交換して…

ここで終えられたら楽なのですが、Read Errorが微妙な件数報告されていたり、SMARTの報告がかなり危なかったりしますのでやはり交換対象、というわけで次に続きます。次でこの話は最後になると思います。

 

48TBファイルサーバに起こった異変から大修理に(1) 機材購入編

この2週間ほどは2年前ほどに環境を構築したファイルサーバにとんでもない異変が発生したため、機材を集めたり修復用の処理をかけていました。これにかなりの時間がかかった(といっても原因がデータ量が大きすぎて環境の再構築作業に時間がかかった+その作業がとある理由で失敗続きだった)ということで教訓の意味も含めて書いておきたいと思います。

 

まずは現象から

確認したのは本当に些細なことでした。この48TBファイルサーバはZFSのRAID-Z2で構築されているので、時々手動で健康状態を確認しています。その中でちょっとやばい状態を見てしまったのですね。それがこれ。途中のscrubでの状態です。

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          raidz2-0  DEGRADED     1     0     0
            zfs1    ONLINE       2     0     0
            zfs2    ONLINE       0     0     0
            zfs3    ONLINE       0     0     0
            zfs4    FAULTED     13     0     0  too many errors
            zfs5    ONLINE       2     0     0
            zfs6    ONLINE       0     0     0
            zfs7    ONLINE       0     0     0
            zfs8    ONLINE       0     0     0

…これ、絶対にやばすぎでしょ。

ReadErrorを3台同時に出すという事態なんです。ちなみにRAID-Z2はRAID-6の仲間であり2台までの故障に耐えられるように設計されているのですが、今回は同時に3台なんですよ。どう見ても何かがおかしい。そのためにRAID-Z2の管理本体にも影響が出ている状態なんですよね。問題は何が故障したか、です。即座に見て危なそうなのはzfs4と名前をつけてあるHDDなんですが…。dmesgより何がエラーを起こしたのかをちょっと拾ってみるとこんな感じ。同じネタが大量に出ていたので今回のエラーに関わる部分だけ残しています。

[53020.294315] sd 11:0:0:0: [sdf] tag#23 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[53020.294317] sd 11:0:0:0: [sdf] tag#23 Sense Key : Illegal Request [current]
[53020.294319] sd 11:0:0:0: [sdf] tag#23 Add. Sense: Unaligned write command
[53020.294321] sd 11:0:0:0: [sdf] tag#23 CDB: Read(16) 88 00 00 00 00 00 e3 d6 b3 18 00 00 08 00 00 00
[53020.294322] blk_update_request: I/O error, dev sdf, sector 3822498584 op 0x0:(READ) flags 0x700 phys_seg 32 prio class 0
[53097.541816] sd 12:0:0:0: [sdg] tag#27 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[53097.541817] sd 12:0:0:0: [sdg] tag#27 Sense Key : Illegal Request [current]
[53097.541818] sd 12:0:0:0: [sdg] tag#27 Add. Sense: Unaligned write command
[53097.541819] sd 12:0:0:0: [sdg] tag#27 CDB: Read(16) 88 00 00 00 00 00 e4 85 00 f0 00 00 01 58 00 00
[53097.541820] blk_update_request: I/O error, dev sdg, sector 3833921776 op 0x0:(READ) flags 0x700 phys_seg 6 prio class 0
[53097.894271] sd 6:0:0:0: [sdc] tag#2 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[53097.894273] sd 6:0:0:0: [sdc] tag#2 Sense Key : Illegal Request [current]
[53097.894274] sd 6:0:0:0: [sdc] tag#2 Add. Sense: Unaligned write command
[53097.894275] sd 6:0:0:0: [sdc] tag#2 CDB: Read(16) 88 00 00 00 00 00 e4 85 00 f0 00 00 01 58 00 00
[53097.894276] blk_update_request: I/O error, dev sdc, sector 3833921776 op 0x0:(READ) flags 0x700 phys_seg 43 prio class 0

DRIVER_SENSEといっているならばエラーの原因はストレージ側ではなくインタフェースカードでは?と思い、念のためにすべてのドライブのSMARTステータスを見てみると、不良セクタ関係の問題が見つかったはなんとzfs3という事態に。つまり今回のエラーにかかっていないドライブだったわけです。ちなみに、RAIDのHDDを接続しているSATAインターフェースカードはこの記事でも書いているとおりこの段階まではSATA3I10-PCIEというもの。これがかなりのキワモノで、対象記事でも書いてあるとおり

SATA2PortのASM1062からSATAを取り出し、各ポートをポートマルチプライヤのチップであるJMB575で5Portずつ分割することで10Port確保しています。ネットワークで例えるならルータが外部1Port内部2Portで内部ポートをハブで10Portに分割しているようなものです。

今回の読み込みエラーが出たドライブにつながっているzfs1,(3,)4,5はBIOSの認識順とコネクタの実装場所の関係から予測するとすべて同じポートマルチプライヤのチップから出ている(と推測される)ことから、原因はSATA3I10-PCIEに実装されているJMB575に異常が発生したのでは?という結論になりました。

 

SATAインタフェースカードなんて今はあまりない…

SATA3I10-PCIEはすでに発売されてから8年経過しているものですので市場在庫もほとんどなさそうで入手性が非常に悪いことと、同じものを買って負荷をかけるのがなんとなくいやになったので、値段が多少高くなってもポート数が多いカードを探したのですが、簡単にあるわけないですね。PCのストレージはM.2が主流になっている以上作っても売れませんので。値段が6桁円にならずにこの用途でギリギリ使えそうだった製品がこちら。

SATA3-I6-PCIE

SATAの管理チップが最新版になったモデルです。ポートマルチプライヤのチップを使わずに6ポート出せるという今となってはなかなかなボードです。が、10台を1枚で支えることができませんので「1枚+MBのポートを使う」or「2枚使いにする」で少し迷いました。結局同じような環境で動かした方がよいと思いますので2枚使いにすることにしました。

 

HDDが微妙な値上がり…

というわけでHDDは依然と同じこれです。

ST8000DM004

ちなみに、2~3ヶ月前に見たときからkakaku.comベースですが、1000円ほど最安値が値上がりしているようです。こんなところに円安の影響か…とちょっと考え込んでしまいました。

 

一度エラーをクリアしようとしてちょっとまずい事態に

とりあえず、ReadErrorが残っていると付け替えしたときにまずいことにならないか?と思いいったんzpool clearでエラーをクリアしようとしたら、こんな状態に…。

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            zfs1    ONLINE       0     0     2
            zfs2    ONLINE       0     0     0
            zfs3    ONLINE       0     0     1
            zfs4    ONLINE       0     0     0
            zfs5    ONLINE       0     0     1
            zfs6    ONLINE       0     0     0
            zfs7    ONLINE       0     0     0
            zfs8    ONLINE       0     0     0

やばいドライブすべてでCHECKSUMエラーを出すという状態に。もしかしてRAID崩壊の危機が間近に?この作業の影響が後々危ない形で出てきます。結論から言うとエラークリアできていないと最終的な再構築作業がうまくいかない、という状態になるようです。とりあえずSATAインタフェースカードを交換する前にもう一度zpool clearでCHECKSUMエラーをなかったことにしました。

 

次回はzpoolの再構築作業

これでかなり時間がかかりました。どういうことかというとエラー状態がのこったっままで再構築をしようとするとなぜか再構築が終わらない、という現象になるようです。理由がわからない上に解決方法もかなり難しいものですので…さすがにRAIDが崩壊するかも、の危険との戦いとなり、厳しかったです。

 

久しぶりの投稿。メンテナンスやら新ソフトウェア公開準備やら

かなり久しぶりの投稿になります。8ヶ月ぶりくらいでしょうか。この期間はいろいろとやることが多すぎてブログの記事に手をつけられなかったんですよね…。

とりあえず2022年となりましたのでこの一言から。

新年明けましておめでとうございます。

 

サーバーの管理不足が目に見える…

というところから。1ヶ月ごとくらいで気がついたタイミングでWordPressの更新チェックやらはしていました。が、全然手が届かず。最小限の更新だけになっていました。その中で起こったのが今日の新ソフトウェアの公開をしようとしていたときにファイルが書き込めないという事態。別の場所経由で転送してmvで移動させようとすると[No space left on device]の非情な文字が…

ちなみに簡単に訳すと「このデバイス(保存領域)にはスペース(保存場所)がありません」と言うこと。なので、即座に何らかの理由で空き容量がなくなった可能性に思い至りdfコマンドで空きスペースを確認しましたがそちら側には問題はほとんど見えず。おかしいと思いinodeのチェックをすると見事に100%で埋まっていました…。

ちょっとWebをチェックしてやり方を調べて探索するとこのblogのキャッシュシステム(wp-file-cache)が引っかかっていました。あまりにも古いプラグインで不具合が出ていたようで、とりあえず停止と削除を手動で行いなんとか復旧しました。

ちなみに、確認する時にはコマンドは工夫するとよいと思います。よく紹介されているのは

find / -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -nr

ですが、これで探索するとルートディレクトリからの探索となってしまうため、すでに目星がついている場合はそのディレクトリに移動した後

find "./" -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -nr

とする方がよいと思います。下の方は「カレントディレクトリから下で調べる」の意味になるので時間短縮やコマンド回数の削減につながるのではないかと思います。

 

オンライン(ブラウザ)上でプログラムコードを簡単に組んで動かすサイトを作れないかな

というのがちょっと考えていること。C++とは言わないでもPythonやRuby、PHPなどのスクリプト言語を内部的にサンドボックスで動かして実行結果を見ることや、ログインしてコードを保存できるようにする簡単なサービスを「自分たちで簡単に構築できる」ことができればある条件においてとても力を発揮するのですが…。paiza.IOとは言わなくてもそんなサイトがサーバ上で構築できればちょっと実験したいことがあるので…。知っている人はTwitterでもいいのでコメントをください。

 

新ソフトウェアはとりあえずサーバ上にはおいてみた

まだダウンロードできるようなリンクは設定されていません。しかも開発時間は全くなかったのでベータ版扱いです。一応書いておくとMovieLayerPlayerの機能をちょっと変型した動画プレーヤーというものです。実はMovieLayerPlayerは動画を再生するときに擬似的に3D空間を設定してその中で動画を合成して再生する、という方法をとっているので、それを逆手にとって描画先の座標尾を設定できるようにすると…というものです。どんなものか想像できるでしょうか。ちょっと様子見したいと思います。Twitterなどで話しかけてくれた人が多いようなら早めに公開してみたいと思います。