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

真面目に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を切り替えながらやる計画性のないやり方は今回限りにしたいですね。

 

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

これまでにPCの組上げやパーツの特性のチェックなどが終わりましたのでやっとサーバの構築に入ることができます。なお、この構築でも本来の予定と異なったことをやっている場面がありますので、そちらも紹介していきたいと思います。

 

サーバのOSは…Ubuntu?

いままでNASサーバは安定性重視でCentOSを使ってきました。サポート期間も長く、今までRedHat系をよく使っていたためなれているという部分もあったためです。そのため、はじめはCentOS8をインストールして設定、と思っていたのですが、インストール時にいくつか問題点が発生していろいろとOSを試しているうちになぜかUbuntu 20.04 LTSになりました。先に原因を書いておくと、今回の場合は

  • CentOS8をインストールするときになぜかNICが正常に応答せず、通信ができなかった
  • インストールパーティションの設定でソフトウェアRAID(mdadm)を設定するときの使い勝手がUbuntuに比べて悪い。RAID1による保護をかけるための設定で、パーティションごとにRAID1を設定されるなど非効率な場面を作ってしまった。
  • ZFSをCentOS系で使うときの手順がかなり複雑である(と聞いている)。dkmsなどの機構が必要になる可能性が高いらしいので安定性が下がるかも。

というものでした。一番はじめのやつが致命傷でした…。

 

FakeRAID(Intel RST)はLinux系OSのインストール時に使用できないと思った方がよい

これもサーバOSを入れるまでに時間がかかった原因です。今回メインHDDはRAID1を組んで障害に耐える構成にする予定でしたので、これをLinux側でやると故障時の対応がややっこしそうだったため、Intel RST側でRAID1を組んで…と思っていたのですが…。RST側でRAIDを組むとLinuxのインストーラがRAIDのHDDを発見できない、という悲劇が発生します。解決するための方法はあるにはあるようなのですが、「インストーラ起動時のオプション設定でdmraidを有効に…」などと書いてあり、やってみても全くうまくいかず、CSMの影響か、とも思いM/BでCSMを設定すると今度はUEFIが見えなくなるという悲劇を数回行い、そのたびにCMOSリセットをせざるを得なくなる羽目に。

改めて書いておきますが、FakeRAIDはLinuxでは相性がかなり悪いので普通にmdadm経由でRAIDを設定するのが正しいようです。そのため、HDDはAHCIで接続させ、Linux側でSoftwareRAIDを設定しましょう。

 

同じ容量のHDDを指定すればインストーラ側がちゃんとRAIDの領域を作ってくれるらしい

心配になっていたのがこの部分。データ領域はRAID1による保護を行うのですが、領域を切り出したときに「それぞれのHDDに同じ容量のパーティションを作成してRAIDを設定する」が果たして守られるのか?ということだったのですが、これは問題はないようです。しかも今回はブート領域にRAIDを設定することができない関係でHDDまるごとRAID1にはできないことを逆用してswap領域をRAID0、データ領域をRAID1で設定するというちょっとだけ速度を向上させる設定にしてみました。swap領域は一時領域なので故障を気にせず速度寄りに、もしHDDが故障した場合はもう片方にバックアップ用のブート領域およびRAID1の保護領域があるので、ブート領域のコピーおよびRAID1の回復作業を行うことで復旧が可能になっています。

 

swap領域があるならswapファイルは無効化してしまおう

Ubuntuの場合はswapファイルが自動的に作成されswap領域が割り当てられます。swap用のパーティションがあるのであればswapファイルは削除するとよいです。swapファイルの停止は以下の手順で行います。面倒なので以下sudoの代わりにroot権限でコマンドを発行しているものとします。

 # swapoff /swap.img
 # rm /swap.img

この後/etc/fstabよりswap.imgのマウント指示を削除して完了になります。

 

Firewallは有効化しておこう

Ubuntuの場合はインストール完了直後はFirewallが入っていないようなので、OpenSSHなどをインストールした後でFirewallを動かしましょう。RedHat系ならばfirewall-cmdを使いますが、Debian系はufwというものらしいです。

 # ufw enable 

 

ファイルサーバなのでSambaは必須

これがないとWindowsからファイル共有ができません。導入してみます。

 # apt install samba
 # ufw allow samba
 # pdbedit -a [user]

pdbeditでログインするユーザのパスワードを設定します。あと、Firewallの許可はサービス名で登録できる場合とポートを直接指定するタイプがあります。今回の場合はサービス名が使えるタイプ。firewall-cmdより簡単ですね。もちろん、 /etc/samba/smb.confの編集をしてsystemctlで再起動が必要です。

 

人によってはtelnetを使いたくなることがあるかも

通常はSSHですが、内部LANに限って簡単にアクセスするのであればtelnetもありかもしれません。Ubuntuの場合telnetはxinetd経由で起動させる方法を使います。つまり、このようにします。内部ネットワークが192.168.0系統ならば…

 # apt install telnetd xinetd
 # vi /etc/xinetd.d/telnet
 # systemctl restart xinetd
 # ufw allow from 192.168.0.0/24 to any port 23

/etc/xinetd.d/telnetはこんな感じ。

service telnet
{
    disable         = no
    flags           = REUSE
    socket_type     = stream
    wait            = no
    user            = root
    server          = /usr/sbin/in.telnetd
    log_on_failure  += USERID
}

ほかのxinetdの設定サイトでもよく見るあれです。しかし、Firewallの設定が非常に楽に見えるのは気のせいでしょうか。

 

今回の本命であるZFSの設定

これが設定できなければ意味がありません。というわけでZFSの設定です。まずはインストールから。

 # apt install zfsutils-linux

これで必要なコマンド類がインストールされます。次はZFSを設定するHDDへのパーティション設定です。通常はHDD全体をZFSに設定するのでpartedからmklabel gptで設定するだけで終わりなのですが、今回はZFS用のパーティションを作成し、そちらをZFSで設定します。

 # parted
 - select /dev/sd[c-j]
 - mklabel gpt
 - mkpart zfs[1-8] zfs 2048s -1s

今回の構成ではメインHDDがsdaとsdbに当たるのでそれ以降のsdcからsdjに対してこれを行います。前回の記事でポート番号がどれになるか確認するのはsdcがどのHDDになるかをしっかりと確認するためになります。Linux上ではこれは認識順(つまりBIOSの順番)となるのでそれほど迷うことはないと思います。ちなみに今回の場合USBメモリからインストールしようとしたためSATAカードとUSBメモリの認識が同時に行われてこの順番に割り込まれることがあったのですが…。

あとはZFSのプールを作成していくつか設定をすれば完了です。作成時にmkpartでラベルを設定しているのでそちらから設定します。

 # zpool create -f tank raidz2 zfs1 zfs2 zfs3 zfs4 zfs5 zfs6 zfs7 zfs8
 # zfs set atime=off tank
 # zfs set compression=lz4 tank
 # zfs set recordsize=1M tank

特にZFSの特性である圧縮機構を有効にするのはやっておくと容量の節約になります。単にonにするだけでもいいですが、必要であれば圧縮アルゴリズムを指定しまってもよいと思います。あとは最終アクセス時刻は基本的に使わないので書き換えをしないようにして無駄な書き込みを防ぎます。

ちなみに、今回RAIDZ(RAID5相当)とRAIDZ2(RAID6相当)を作ってベンチマークを取ってみましたが、こんな感じでした。必要であれば前回の記事の速度と比較してみてください。

RAIDZ 1GBファイル RAIDZ 4GBファイル RAIDZ2 4GBファイル
Seq-Read 4993.22
Seq-Write 2020.38
Rand-Read-512K 5729.92
Rand-Write-512K 737.395
Rand-Read-4K 258.524
Rand-Write-4K 54.959
Rand-Read-4K-QD32 67.978
Rand-Write-4K-QD32 57.255
Seq-Read 309.542
Seq-Write 593.169
Rand-Read-512K 44.064
Rand-Write-512K 585.633
Rand-Read-4K 0.707
Rand-Write-4K 17.824
Rand-Read-4K-QD32 0.729
Rand-Write-4K-QD32 17.046
Seq-Read 366.538
Seq-Write 565.193
Rand-Read-512K 20.784
Rand-Write-512K 368.535
Rand-Read-4K 0.159
Rand-Write-4K 8.108
Rand-Read-4K-QD32 0.224
Rand-Write-4K-QD32 7.591

初期設定だと1GBファイルしか作っていなかったので、どうもZFSのキャッシュ機構に引っかかってとんでもない速さでアクセスした状態になったようです。そのため、キャッシュを無効にするためにファイルサイズを4GBまで上げて再度速度測定をしています。見る限りではさすがにRAIDZ2になるとランダムアクセスが大分遅くなるようです。シーケンシャルアクセスはインタフェースカードの限界の問題もあると思うのでこんなものかな、という感じです。

ちなみに注意点としてはZFSの予備領域などの関係でいままで「48TBファイルサーバ」と書いていましたが、実際に使用可能な容量は「43TB(40TiB)」となり、予定より容量が少なくなってしまうことです。それでも今までの32TB(29TiB)よりは大分拡張されているのでまあいいか、というところでしょうか。

 

さすがに同期作業が大変…

ある程度安定動作ができるようになったのでここから旧NASサーバから新NASサーバへのデータコピーを行います。LAN経由しかないので

 $ rsync -av [旧サーバ]:[コピー元フォルダ名] [コピー先フォルダ名] 

などとしてSSH経由で引っ張り上げる位ですがなにせ32TBのサーバに入っていたデータを引き上げるので時間がかかることかかること…。

ちなみに注意点として圧縮をかけた

 $ rsync -avz [旧サーバ]:[コピー元フォルダ名] [コピー先フォルダ名] 

とする方法もあるのですが、これは「ネットワークが遅い場合」「転送元のサーバスペックが高い場合」に限られます。特にネットワークに十分な速度がある場合(両方がGbEのハブでつながっている状態など)は転送元のrsyncでCPU使用率が100%に張り付いてしまい、十分な速度が出ません。実際に私の環境では-zオプションありで30MB/sほど、-zオプションなしで60MB/s~80MB/sと2倍以上開きがありました。これを知らずにはじめに-zをつけて転送をしていたために大分時間がかかってしまいました…。

 

さて、あと何日かかるかな~

これが終わったら旧NASサーバはHDD部分を解体して新作業用サーバ(Fedora)に変身、現作業用サーバはお役御免でお疲れ様、となります。このあたりの入れ替えもまた大変な作業なのですが、まずはデータコピーが終わらないとどうしようもないですね。がんばります。

 

CMSサイトの構築とSELinux

というわけで今回はこういう話題です。ほとんどの解説サイトがSELinuxを前提にしていない書き方をしているためにこの系の権限変更がちゃんと行われず、サイトの初期設定すらまともに行えない、という現象にはまることが多いような気がするのでそれについて書いてみます。

 

SELinuxが持っているhttp系の初期権限

これを知らないと大変なことになります。SELinuxでは、http系で操作される各種ファイルについて以下のようなラベルを割り当てて管理しています。大まかに必要な分だけですが…。

権限名 意味 権限
httpd_sys_content_t 通常コンテンツ 読み込み専用
httpd_sys_rw_content_t 通常コンテンツ(読み書きあり) 読み書き
httpd_sys_script_exec_t 実行可能コンテンツ(CGIなど) 読み込みおよび実行
httpd_var_lib_t /var以下に存在するhttpの動作に関わる補助ファイル(phpのキャッシュなど) 読み書き
httpd_var_run_t /var以下に存在するhttp上で実行されるコンテンツの補助ファイル(phpのセッションなど) 読み書き

下二つはあまり関係しませんが、php-fpmなどの設定時に関わってくることがあります。で、問題は上の3つ。

 

SELinuxがhttp系ファイルにつける初期ラベルはhttpd_sys_content_tになる

これが要注意ポイント。つまり読み込み専用になるわけです。この状態は通常のコンテンツをアップロードしたときには正しいのですが、CMSサイトのようにディレクトリ内にキャッシュを持ったり、自分自身でファイルのアップデートを行うコンテンツにおいては非常に相性が悪い(というかこの状態だとうまく使えないこと)になってしまいます。

 

CMSサイトのディレクトリにはhttp_sys_rw_content_tをつけないとインストールできないことも

この件について調べるのにかなり時間がかかってしまいました…。特に内部的にキャッシュディレクトリを持つ場合はそのキャッシュディレクトリにhttp_sys_rw_content_tを設定しておかないとキャッシュが動かず実行できません。これは大変です。また、CMSの場合たまにあるのが、アップデート時に何らかのスクリプトをCGI権限で動かすパターンがあるのですが、その場合は個別にhttpd_sys_script_exec_tを設定しないとたとえchmodによる実行権があってもSELinuxにより実行が拒否されますので対応する必要があります。

 

CMSサイトのディレクトリには必要な部分にhttp_sys_rw_content_tを設定しよう

という結論になります。もちろん、全域に設定するとセキュリティが弱くなるので必要な部分だけ、というのはあるのでコンテンツに関するディレクトリだけです。例えば/var/www/cms以下にコンテンツをインストールして、/var/www/cms/webroot以下を書き換え可能にするとするなら

# semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/cms/webroot(/.*)?"
# restorecon -R -v /var/www/cms/webroot

のような処理が必要になります。この処理はターミナル上からしかできないのでSELinuxを設定している時は要注意になります。また、実行権が必要になるファイルにもhttpd_sys_script_exec_tの設定処理が必要になりますので、これを参考にやっておきましょう。

 

SELinuxがセキュリティに貢献していることがよくわかる…

chmodによる権限変更だけでは受け入れない堅さが自慢です、というところですか。面倒ですが、少しずつ覚えていって使いこなせるようにならないとまずいような気はしますね。

 

Fedora32のPHPは初期設定でphp-fpmになるのか…

そして今回の出来事の中で気がついてしまったこと。昔はApacheの場合はphpがhttpd上で動く組み込みパターンになるのでphpの実行者はhttpdの実行者と同じになっていたのですが、Fedora32の場合は初期設定がphp-fpmによる外部動作なので、phpの実行者がphp-fpmで設定されている実行者になる、という「suexecを考えるよりはわかりやすいのか?」という状態になっているようです。このあたりも気をつける必要がある人は気をつけましょう。

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

今回のFedoraは公開されてからあまり時間をおかずにインストールしています。一応今のところは不具合などはありませんが、それでも変更点は何個もあったのでそれを紹介していきたいと思います。

 

パーティションはほぼデフォルトで

Fedora30のときにはext4で…と書いていましたが、今回はほぼデフォルトに任せてパーティションを設定させました。そうすると、boot系のパーティションを除きLVMで作成され、しかもデータパーティションの形式はxfsになっていました。xfsが標準となりつつあるのでしょうか…?

 

ファイアウォールの設定に少し戸惑った

ファイアウォールの設定は以前からfirewall-cmdを通す形式だったのですが、バックグラウンドがiptablesからnftablesに変わったからかよくわかりませんが、デフォルトで適用されるゾーンの名前がpublicからFedoraServerになったようです。このため、以前は–zone=publicを指定して設定していたポート開放処理ですが、Fedora32では—zone=FedoraServerを指定しないと正しいポート開放にならなくなっているようです。このあたりはfirewall-cmdでリストを出せばわかるのですが、一発では気がつかない現象でした。

 

cronが標準でいなくなった?

はじめにこれを感じたのはcrontabのコマンドがなくなったことでした。crontabのファイル自体は存在していますが、コマンドからのファイル編集がなくなっているので…と思いちょっと見てみると、cron自体が入っていなくなったのですね…。

じゃあcronの代わりは?というとsystemctlのtimerを使って定期的にジョブを動かす、という仕掛けになっているようです。つまり、自分でtimer(+service)の設定ファイルを作成し、systemctlで有効にする、という手順をとらないと以前にcronでやっていた「定期的にスクリプトを動作させる」ということが標準でできないようです。この差はちょっと大きいですね。しかも、SELinuxを有効にしたままだとスクリプトファイルの権限に関する問題(ファイルの実行フラグではなくSELinuxに基づく実行許可問題)が現れてしまい、auditの設定やらsemanageやらなんか面倒なことをする必要が増えたな~という感想です。セキュリティは強化されているのですが。

 

どうせ「StayHome」なので、こういうときにこそ更新作業をしよう

長期の休みなので、家でしかできないことシリーズとしては、こういうOSの更新作業なんていうものは典型的なものだと思いますので、皆さんも思い出した段階でやっておきましょう。

メインサーバにFolding@homeを導入して新型コロナウィルスなどの解析に協力してみた

さすがに新型コロナウィルスの影響がしゃれになっていない状態になってきています。自分の身にも転職や請負の仕事などで降りかかっていますし…。ということでちょっとある動画でやっていた、いわゆる余っているPCの能力を組み合わせていろいろなものを調べる系(分散コンピューティング)のプロジェクト、今回は特に新型コロナウィルスなどの構造解析をやっているFolding@homeを導入してみたいと思います。

 

今回はLinux版(Redhat系)でやってみる

メインマシンに入れるとファンの音の問題や消費電力の問題も大きそうですので、サーバー機に入れてやってみようと思います。さすがに世界的なプロジェクトだけあってWin版以外にもmac版、Linux版(Debian系、Redhat系)などがありますので自分に適したものを導入すればOKです。手順としてはこんな感じ。

 

1. ホームページ(https://foldingathome.org/)から上のメニューより「Start folding」をクリックする

2.ダウンロードページの中程にある「alternative downloads」のリンクをクリックする

3.各OSにインストールするときのインストールプログラムおよびパッケージへのリンクがあるので必要なファイルをダウンロードする

このとき、GUIからの監視や設定プログラムがなくてもよい場合はfahclientのみでOK。監視プログラムを入れる場合は特に別PCから監視する場合はいくつかのポートを開いたりするなどファイアウォールの処理が必要になるので注意。

4.root権限を使ってパッケージをインストールする。

DNFが使えるFedora系ならば(3/29現在だと)

$ sudo dnf install fahclient-7.5.1-1.x86_64.rpm

でOKです。openssl系のパッケージが必要になるのでそこだけ注意。

5.インストールが完了すると勝手に動作を開始するので一度停止させる

いくつか設定をちゃんとする必要があるので動作を停止させましょう。本当をいうならreloadができるはずなので止めなくてもよいかもしれませんが、初期設定の場合は一度完全に止めた方が確実でしょう。

$ sudo /etc/init.d/FAHClient stop

6. 必要な設定を作成する

初期設定だけならFAHClientからファイルを作ることができますのでそれを使いましょう。

$ sudo FAHClient --configure
User name [Anonymous]:(自分を示すユーザ名を入力する。空欄ならAnonymous)
Team number [0]:(参加したいチームの番号を入力する)
Passkey:(パスキーを入力する)
Enable SMP [true]: (複数CPUへの分散を行うときはtrueを指定する)
Enable GPU [true]: (GPU[OpenCLやCUDA]を使用するときはtrueを指定する。認識されていなければ動作しない)
Name of configuration file [config.xml]:(空欄でOK)

7. /etc/fahclient/config.xmlを編集してCPU使用率に関する指定をする。

エディタで設定ファイルを開いてもう少し細かく設定します。特にCPUやGPUの使用率に関してもっと使ってほしい場合にはこの設定項目を変更します。

 <power v='light'/> (ここをmediamやfullにすると使用率が上がる)

8. サービスを再起動する

$ sudo /etc/init.d/FAHClient start

 

実行に必要になるものは勝手にダウンロードされるので後は放置でOK

解析させたいタンパク質のデータもそうですが、対象のPCにあう解析プログラムがダウンロードされるので、それが実行されるまでしばらくかかるようです。実行されるとCPU使用率が大幅に上がるはずです。なお、実行で使われるデータ、プログラムおよびログは/var/lib/fahclient以下にありますので解析ログを見てみたい人は直接見てみるとよいと思います。そんなにこまめに見るものでもないと思いますが。

 

昔はSETI@homeがあったな…

こちらは「宇宙から来た電波などを解析して宇宙人の痕跡を探す」でしたが、すでに終了しています。こういう分散コンピューティングの先駆けともなっているものを知っているのでこういうときに協力してみようという気になるわけですね・・・。