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

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

かなり久しぶりの投稿になります。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などで話しかけてくれた人が多いようなら早めに公開してみたいと思います。

 

 

 

Fedora34をインストールしてみた

久しぶりの記事投稿です。しばらく忙しかった+ネタがなかったので投稿していませんでしたが、ネタになりそうなLinuxOSのインストールをしてみましたので近況報告と併せて書いてみます。また、一部のデータがサーバから失われてしまったという報告も兼ねて書いています。

 

Fedora32からFedora34へ(ただし、クリーンインストール)

ということで、Fedora34が出てFedora32のサポートが消えるのでほぼ1年ぶりのバージョンアップを行いました。私の場合はFedora系ではアップグレードではなくクリーンインストールして前の設定をできる限り引き継ぐ形で行うようにしているのでインストーラからの作業になりました。ちなみに特記するようなことは・・・まあなかったですね。インストーラもFedora32から変わった、というような印象もなく、インストール後も特に変わったパッケージなどもなかったですし。前に何を使っていたのか、の確認をおこない、それらをdnfで復旧させて旧の設定ファイルを見ながら再設定+起動設定を行って完了でした。

で、今回の困りごとというのがソフトウェアの方ではなく、ハードウェアのほう。どうも手元に置いていた無線キーボードが壊れてしまったことでした。はじめドングルをさしてみてもPC側に反応がないのでどうしたのかな?と思ったらメインPC側に差しても反応なし。ということで故障判定しています。Youtubeの修理動画に触発されて分解して原因でも探してみようか、と思ったのですがとりあえず保留です。また、その無線キーボードと一緒に使っていたトラックボールマウスも何か動作が怪しい感じで、マウスカーソルの動きがかくついていたり、クリックがうまく反映されなかったり。この手のハードウェアは放置しておくとまずいことが多いのでしょうかね。

 

SystemctlのTimerを設定するファイルも消してしまった・・・

設定ではこれが微妙に大変だったです。Fedoraを入れているサーバは一応メインサーバなのでIPをDNSサーバに通知してアクセスできるようにしているのですが、その仕掛けでかなり昔にCronを使っていたものがあり、今はSystemctlのserviceとtimerを併用して動かしていたのですが、クリーンインストールしたときに作成したファイルまで消してしまったようで、書き方を探すのが大変でした。ちなみにSystemctlのファイルは/usr/lib/systemd/systemにおいてありますが、自分で作成した場合は/etc/systemd/system以下に置いてもよかったようで、今回はそちらに置くようにしてみました。バージョンアップ時には念のために/etcの中身だけアーカイブしてもってきているので、次回以降これならばなんとかなるかな、と思います。

 

このサーバの掲示板のデータが・・・

いわゆるスパムですね。大量の投稿があり、さらに本来なら別ファイルにバックアップされて、という動作のはずだったのですが、その動作が正しく行わなかった結果、掲示板のデータを失う事態となってしまいました。しかもバックアップが2年前のもの、という大失態・・・。とりあえずその時点までは戻しましたが、ここ2年間の書き込みがなくなってしまいました。WebArchiveでも件名までしかたどることしかできず・・・。一部にWindowModePatchに関する情報があったのですが・・・。書き込んでくれたお二方、大変申し訳ありませんでした。今度からはある程度の頻度でバックアップをとるようにしていきます。必要に応じてIPフィルタをかけるかもしれません。

 

CentOS7でPHP7.2からPHP7.4にバージョンアップ。ただ簡単すぎた。

ただいま仕事がないのでサーバ系やフリーソフトのバージョンアップをしながらメンテナンスをしている状況です。で、今回はPHPのバージョンアップ。今までPHP7.2系を使っていましたがセキュリティメンテナンスの期限も過ぎてしまったのでさすがにまずいということでPHP7.4系にバージョンアップすることにしました。この手のバージョンアップは状態によっては手順がかなり面倒だったりするのですが…。

 

Remi経由でPHP7.2をインストール済みの環境から

今回の前提条件がこれ。CentOS8のように元からPHP7.2が入っている環境ではなくRemi経由でPHPのバージョンが7.2系にバージョンアップ+設定がちゃんとなされている状態から始まっています。これのおかげでこの後の作業がとんでもなく楽な作業になってしまいました。

 

Remi経由でPHP7.2が入っているならリポジトリを微妙に変更してアップデートを行うだけであっさり終わり

そう。単にアップデートを行うだけで終わりだったわけです。PHP7.2系のリポジトリはremi-php72なので、remi-php74を指定するとPHP7.4系のリポジトリに切り替わります。そのため、とりあえず最新の状態まで更新が完了すれば一発

$ sudo yum update --disablerepo=base,updates --enablerepo=remi,remi-php74

これだけで終わりです。簡単でしょ?まあ、アップデートするときに一時的にPHPに関するサーバを止めてしまったもよかったのかもしれませんが…。あとは更新対象になったものをすべて更新すれば完了です。設定もそこまで違うことはないので使い回しできそうですし、更新の途中でPHP Warningが大量に出てきますがこれもそれほど気にする必要はないと思います。

 

後は運用しながら様子見

とりあえずblogも問題なく動いているようですし、あとは不具合が見つかれば設定などを見直していく、という感じになるかと思います。WordPressのプラグインもそうですが、この手の更新についてもちゃんと確認していかないとセキュリティメンテナンスがされていないものを使っているとどこからアタックが仕掛けられるかわからないですからね。ちゃんとやっていきましょう。

8月に構築した48TBファイルサーバのHDDが一つやられたので交換してみる

まさか構築して1年以内にHDDがやられるとは思いませんでした。しかもエラーが現れたのはZFSのscrub処理によってで、しかもSMARTの報告で確定するくらいのもの。はじめは「とりあえず再チェックかければなんとかなるかな…?」と思っていましたが…

 

HDD1台が不良セクタを大量に出す事態に

まず問題になったのはzpoolのstatusから。たま~にコマンド経由で何か問題がないかチェックをかけていますが、そのとき出てきた状態。ちなみにstatusなどのメッセージはちょっと控えていないので状態だけ。とりあえずこんな状態でした。

$ sudo zpool status
…
    NAME             STATE     READ WRITE CKSUM
    tank             DEGRADED     0     0     0
      raidz2-0       DEGRADED     0     0     0
        zfs1         ONLINE       0     0     0
        zfs2         ONLINE       0     0     0
        zfs3         DEGRADED     0     0   170  too many errors
        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
…

zfs3だけ 大量のCheckSumエラーを出している状態です。不思議に思い一度zpool clearによりエラーを一度クリアして再度scrubによりチェックサムを確認させると同じような状態になったので「こりゃまずいのでは?」と思い、smartmontoolsを入れて問題のドライブの状態を見てみると…

$ sudo smartctl -a /dev/sde
…
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       65
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       936
  7 Seek_Error_Rate         0x000f   075   060   045    Pre-fail  Always       -       33243485
…

はい、明らかな 不良セクタの発生でした。冒頭にも書きましたが(HDDを10台同時とはいえ)稼働させて1年もたたずに1台目がやられてしまうとはびっくりです。とりあえずびっくりもしてられないので回復作業に取りかかります。念のために1台だけ予備のドライブがあるのでそれを取り付けます。

 

ZFSからRAIDZ系の回復作業を行う

ZFSでRAIDZ系を使っているときは対象のパーティションはDEGRADED状態ですがアクセスは可能ですので慌てなくても大丈夫です。後は取り外せる状態にして物理的に電源を落として交換orホットスワップによる交換を行い、再構築を行わせるだけです。まずは取り外す準備として壊れてしまったドライブを無効にする処理を行います。コマンドはzpool offlineです。

$ sudo zpool offline tank zfs3
$ sudo zpool status
…
    NAME             STATE     READ WRITE CKSUM
    tank             DEGRADED     0     0     0
      raidz2-0       DEGRADED     0     0     0
        zfs1         ONLINE       0     0     0
        zfs2         ONLINE       0     0     0
        zfs3         OFFLINE      0     0   170  too many errors
        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
…

上のようにすると取り外しの準備ができます。対象のドライブがOFFLINEになっていますね。これを行った後で当該のドライブを取り外し、予備のドライブと交換します。面倒だったのはどれが/dev/sdeにあたるか、という問題。構築時にも書きましたがSATA3I10-PCIEの特性で端子(物理ドライブ)の順番と認識されているドライブの順番が一致していないので順番を間違えないように交換する必要があります。確認してみると今回対象になっていたのは物理的に一番下に来ていたドライブでした。

あとは交換してパーティションを組み直して終わりです。ドライブが交換されただけなので認識順番が変わらないことを使うとそのまま/dev/sdeになるため、

$ sudo parted /dev/sde
 - mklabel gpt
 - mkpart zfs3 zfs 2048s -1s

でzfs3の領域が元に戻り、ZFSに再構築を行わせれば完了です。

 $ sudo zpool replace tank zfs3

さすがに8TBもあるとかなり時間がかかるようですので気長に待ちましょう。RAIDZ2のよいところは2台故障まで耐えられるので1台の修復中であればそこまで怖がる必要がないことですね。完了したらTwitterにでもつぶやいておきます。

 

壊れたドライブはどうしようか…

最後はこれ。1年もたたず(というか半年すらたっていない)ので保証とか効かないかな…とは考えています。さすがにさらに予備を買っておくのはどうかと思いますので、なんとかしたいところですね。

真面目に48TBファイルサーバを構築してみる(6) サーバ設定編

ここからはどちらかというと余談になります。いろいろと作業をしていくなかであった発見や「なるほど!」と思った現象について少し書いてみたいと思います。

 

ZFSの圧縮の効果がこんなところに

とりあえずすべてデータを転送してみたのですが、気になることが一つ。それはmdadmで確保されたRAID領域(ファイルシステム依存の領域)からZFSにコピーしたのですが、使用容量が8%ほど下がりました。おそらくZFSによる圧縮の効果だと思うのですが、アルゴリズムは速度優先でlz4を指定しているためそれほど圧縮されないはずですし、大抵のファイルが一度圧縮を行っているファイルのはずなので、圧縮はあまりかからないはずだったのですが…。圧縮をかけられるデータやファイル名などのメタデータが圧縮を受けるとどれだけ容量が削減できるかがよくわかりました。速度に問題がなければほかの領域でもかけたくなりますね。

 

QEMUの設定をRedHat系からDebian系に移すのはかなり難しい

こちらは苦労した点。設定ファイルを直接持って行ってどうにかなるのか?というと「基本的にはうまくいかない」が回答のようです。仮想マシンの実行ファイルはRedHat系とDebian系で名前が異なっているため変更が必要、VirtIOがうまく動作せず起動させるとブルースクリーン行きになる、設定ファイルをインポートするとコマンドライン指示の部分(ポート開放処理を記述)は削除される、などがありました。結局一時的に別のUbuntuServer機を用意してそちらにGNOMEとQEMUをインストールして「グラフィカルな環境で設定を行い動作したもの」+「そのときの設定ファイル」を再度コピーする、という手順でなんとかする羽目になりました。VirtIOはドライバのバージョンが古すぎたのかな…とも考えています。

 

mdadmによるソフトウェアRAIDは別PCにストレージだけをつけ直しても検知はされる

これは今回チェックできた中でよかったこと。ちゃんとSuperblockに設定が残っているらしく、OSが入れ替わったとしてもちゃんとmdstatに状態が表示され、mountをかけると普通にファイルが見えました。これでmdadmで構築した場合にインタフェースが故障してもある程度大丈夫ということがわかりました。ただし、mdadmからアレイを削除すると普通に見えなくなりますし、検知された段階で詳細をファイルに保存する(mdadm –detail –scan > /etc/mdadm.conf)ことを忘れるとその後見えなくなったときに二度と構築できなかったりとしますので注意は必要ですね。(元の計画では、HDDとインタフェースカードのみ追加して一時的にHDDを付け替えてコピーする、という算段をしていたが、これがうまくできるのかどうかわからなかったので諦めてPCを一台組んだ、という経緯がある)

 

SELinuxが動いている環境で設定ファイルを/etcにコピーする、というやり方は失敗する可能性がある

再度のFedora環境の移行時に起こった出来事。どうせ同じサービス環境を復元するので移行前の/etcを取り出しておいて移行先で必要なファイルだけ展開してコピーすればいいや、と思って作業をやるとこういう出来事に引っかかるのですよね…。今回引っかかったのはhttpdの秘密鍵と公開鍵の部分。移行前のサーバと同じものを使うためにコピーしてhttpdを起動させるとうまく起動しない。起動しない原因が(日本語に訳すと)「公開鍵ファイルが読み込めないため実行できない」というもの。ファイルのパーミッションは間違いがないのでおかしいな?と思っていたらこのことを思い出して設定を調べてみて判明。特に「/etcに元から存在しないファイルを外からコピーすると/etcのファイルに設定されるべきコンテキストが設定されないため読み込めない」という事態になることが判明。近くにあるファイルのコンテキストをls -dZで確認してchconで設定する、という作業が必要になります。

 

I219V(e1000e)はLinuxと相性が悪い?

どうもそのようです。e1000eに関するいろいろな記事が出ていますが、移行前および移行先のサーバともNICはI219Vを使用しており、移行後のサーバにネットワーク負荷をかけたところかなりの頻度で通信が切断される、という現象が起こったためいろいろと調べてみた結果の結論です。この症状が出るとログに頻繁に「Detected Hardware Unit Hang」が報告されれ、NICのリセットが行われる、というシーケンスが発生します。なお、私の場合はこれが発生しすぎたためかネットワーク経由でサーバにアクセスすることができず強制的に電源断を行わざるを得なくなりました。

原因としてはTSO(TCP Segmentation Offload)が有効になっているとNICへの負荷が高くなって切断される、というもののようで、セグメント分割の処理をCPU側に戻すとよいようです。方法としてはNICをeth0だとすると

# ethtool -K eth0 rx off tx off tso off gso off

のようにして関連する処理をすべてoffにすればOKです。面倒なのがこれを基本的には「起動時に」行う必要がある点。これについてはFedora32やUbuntu 20.04 LTSでは互換性維持のためrc.localによる記述が有効(ただし、Fedora系は/etc/rc.d/rc.local、Debian系は/etc/rc.local)であることを利用して

#!/bin/sh
ethtool -K eth0 rx off tx off tso off gso off

のような感じのrc.localを用意して実行権限を付与すればOKです。

ちなみに、JumboFrameを有効にするとCPUのC-Stateによる省電力が一部使えなくなるようですが、サーバ用途なので気にしなくても大丈夫だと思います。BIOSの設定でC-stateを無効にしても表示されていたのでどうしようもないかも。

ついでに見つかったのが/etc/resolv.confのシンボリックリンクがなぜかstub-resolv.confを指していて、NICリセット時に一時的に127.0.0.53をDNSサーバと勘違いしていた点。修正しましたが、こちらもなぜこんな設定だったのかは不明。

 

とりあえず安定状態に持って行くことができた

今回はファイルのコピーにとんでもない時間がかかってしまったのでサーバの設定時間の方がよほどやることがあって進んでいた印象があるのが今回の移行作業でした。また、今回はUSBメモリによるLinuxインストールを何回も行うことになりrufus(USBメモリに起動可能なデータを設定する)が大活躍しました。まあ、これだけOSを切り替えながらやる計画性のないやり方は今回限りにしたいですね。