QNAPさんの調子が悪い

運用中のTS-231がRTRRでのバックアップがたまに失敗したり、Q'centerから切断されたりと調子が悪くなってきた(というより元々悪い)のでグラフとかを見てみるとCPU使用率がめちゃ高かった(80%)。

プロセスリストを見てみるとpython2のプロセスがめちゃ多かったので「自分でなんかしかけたっけなぁ・・・」と思いつつ急いでsshでログインしてみると下記のようなものがずらっと出てきた。

 

/mnt/ext/opt/Python/bin/python2 /mnt/ext/opt/wsd/wsd.py

 

何用のものかよく分からないけどWSDiscoveryとか書いてあるのでなんらかのサービス探索用の物かなと思われる。

 

それっぽいのを止めてみる

http://docs.qnap.com/nas/4.1/SMB/en/index.html?service_discovery.htm

 

追記2018/6/11

それでもなぜか増えてきてたので/etc/init.d/wsd.shの中身を見てみた。

cronでも毎日4時にrestartしてる(restartすると既存のすべてのwsd.pyが一旦死ぬ)

おそらくこれをstopしてしまえばいいんだろうがとりあえず手動でrestartでお茶を濁しておいた。

 

追記2018/6/14

結局勝手に再起動が走ったので(これのせいじゃないかもしれないけど)stopでころして様子を見ることに。

OSPFを試してみる

スタティックなルートを書くのがダサく感じる中二病的な病にかかった勤務先のインターネット回線の冗長化を考えたときに避けては通れないようなので割とどこのルータにも実装されているOSPFを使用して感じをつかんでみることにした。

記憶力がよくないので単なる個人的な整理のために書き残しておく。

 

利用したのはお家にあったIX2015を3台。

 

初めは全ルータのFE0/0,FE0/1同士をL2SWでつないで試してみた。

 

全拠点二本引っ張ってればだいたいそのようなトポロジーになるがそれだけではなんとなく面白くなかったので次に1台中継用ルータとして設定し、2台は直接つながってない状況を作って試してみた。

pingを送りながら線をぶち抜くと15秒くらいで切り替わった。設定はほぼデフォルトの設定でしたのでこの秒数を短くするには何等かのパラメータを調整しないといけないんだろうな。helloパケットの間隔かな。

 

特に秒を争うことでもない限りこれで勝手にフェールオーバーはできるので

いいんじゃないでしょうか。

図とかコンフィグの詳細とかは気が向いたときに整理したい。あとは実環境を想定してIPsecトンネル張った状態でのルート配信も試してみたい。

php-pecl-memcachedをアップデートしたら怒られるようになった

先日PHP7.0を入れたCentOS7のマシンのアップデートを行ったところログに下記のようなものがずらーっと出るようになってしまった。

PHP Warning:  Unknown: using touch command with binary protocol is not recommended with libmemcached versions below 1.0.18, please use ascii protocol or upgrade libmemcached in Unknown on line 0

どげんかせんといかん。ということで調べてみると下記のような情報がでてくる。

qiita.com

が、自前でコンパイルとかいやずら、という私のような人は下記のように/etc/php.d/50-memcached.iniの設定変更すればよい。

memcached.sess_binary_protocol = On
↓
memcached.sess_binary_protocol = Off 

なんか設定ファイルだけ先んじてデフォルトOnになっちゃったのかな。それとも1.0.18含め忘れたのか。

ゆくゆくはOn(default)にした方がいいのかもしれないけどしばらくはこのままかな。

Creators Update(1703) からFall Creators Update(1709)にしたときのBashはどうなる?

あと4日でアップデート振ってくるみたいですが社内での不具合等の人柱的な存在として先行してアップデートしてみました。

特にアップデート自体は少々の時間がかかったものの特に何も変わりなく起動したので当初の目的としては完了。

それはいいのだが、そういえばBash on Windowsがなくなり(?)ubuntuとかSUSEとかFedoraとかが入れられるとかだったなぁということを思い出して気になったので少し調べたところやはり下記にあるように今のを一旦消して、ubuntuとか入れなおした方が良いようです。

What’s new in WSL in Windows 10 Fall Creators Update – Windows Command Line Tools For Developers

Note: If you've previously installed WSL on Anniversary or Creators Update, your existing "legacy" Ubuntu instance will continue to work just fine, but it is considered deprecated. We recommend that you migrate your files off the legacy instance and replace it with a store-delivered instance, so that you receive the support of Canonical and Microsoft moving forward.

Creators Updateとかで入れたBashの消し方はよく書かれてる

lxrun /uninstall /full

でできると思います。 やる前に/home/配下とか必要なものはバックアップ取っておきましょう。 %USERPROFILE%\AppData\Local\lxss\からもアクセスできるようなのでわざわざターミナルから作業しなくてもよさそうです。 後は個人的にはaptで入れたものとか、pipで入れたものとかを一覧にしておきました。

grep -i 'requested-by\|command' /var/log/apt/history.log >apt_list.txt
pip freeze >pip_list.txt

死にかけHDDからWindowsが何とか起動した

とある人からある日ノートパソコン(SVT13119FJS)が持ち込まれた。

Windowsの光る旗マークから一向にすすまないから使ってなかったんだけど、Office使いたいんだよね。なんとかならない?」

「(復旧かけるか、最悪リカバリかけたらなんとかなるやろ)」

と高をくくっていたものの電源を入れて状況を確認すると

旗→エラー(any keyで再起動)→以下略

起動前のF8とかのメニューからセーフモードその他も同上

どないせえっちゅうんじゃい

この時点でよくわからんかったので伝家の宝刀SystemRecsueCDさんにお世話になる。

いろいろあった*1*2がうちの環境では以下の手順でやることで元のWindowsを立ち上げることができた。

材料:

元のHDDと同程度もしくはそれ以上の容量のHDD(3.5inchでも可、以下Disk1)

2.5inchのDisk1がない場合は元の環境の本体領域が収まる程度の2.5inchHDD(以下Disk2)

USB-SATA変換

結局はHDDが物理的に逝ってるようなので、Disk1(今回は3.5inchを利用)にバックアップを取る。

dd if=/dev/sdx of=/dev/sdy bs=512 count=1

dd if=/dev/sdx1 of=/dev/sdy1 bs=512 conv=noerror,sync

dd if=/dev/sdx2 of=/dev/sdy2 bs=512 conv=noerror,sync

dd if=/dev/sdx3 of=/dev/sdy3 bs=512 conv=noerror,sync

conv=noerror,syncはエラーが起きた時に止まらずそのまま続けるためのものです。各ワードの意味はめんどくさいので調べてみてください。

本体領域*3以外はDisk2にも取っておくが、元のHDDから取るとエラーが起こってクソ遅いのでDisk1からコピーしたほうが無難。

その際Disk2を利用の方はMBRコピーした後第3パーティションの調整をしてください。

取れたら、一度別のWindowsマシン(以下作業Win)にDisk1をつないで第3パーティションの領域をchkdskかける。/F /Rオプションで。

そうすると本体領域のファイルシステムが健全になる(起動できるとは言っていない)。

そのあと作業Win上でParagonとかEASEUSとかの無料ツールを使い、Disk1の第3パーティションをDisk2の第3パーティションにコピー。

このままDisk2を本体に挿して動く場合もあるかもしれないけど今回の場合は動かなかった*4ので以下を行った。

今回の場合入ってるOSがWin7だったのでインストールディスクまたはISOから作ったUSBメモリを用意し、起動させて、修復を試みる。

うまくいけば起動に必要な部分が修復されて本体から起動できる。

それでもできない場合は、実は今回先にDisk2を使ってリカバリ領域*5を戻して*6正規の手順でリカバリを試みていた。

その際に第2パーティションに何らかの影響を与えていたとも言えなくもないのでダメ元で試してほしい。

という感じで今回はたまたま起動してくれたからよかったものの、少しでも逝ってる場所が違えば起動しなかった可能性も十分に考えられる。

というわけで以下ほんと重要(本業並感)

  1. 日々のバックアップ
  2. リカバリ領域のバックアップ
  3. OfficeのCDとかプロダクトキーは置いておく


結局このマシンのHDDが壊れたまんまなのは変わらないのでmSATAのSDDでも引っ張り出してOSインストールでもしようかと思う。

*1:この時点でリカバリ領域が不完全だが他に書き出してリカバリすれば起動はするもののOfficeが入っていないことが判明

*2:OfficeのCD、プロダクトキーは捨てたため見当たらないという状況だったため何が何でも元の環境を立ち上げてOfficeのプロダクトIDを確認する必要があった

*3:今回の場合第3パーティション

*4:\Boot\BCD的なエラーが出て起動できなかった

*5:今回の場合第1パーティション

*6:厳密にいうと第2パーティション