自分宛てメモ

 

ssh経由で動くfs、しかもfuse。

 

準備
1)リポジトリから sshfsを入れる。fuseも必要だがおそらく既にインストールされているはず。
2)マウントポイントをホームディレクトリ内に用意する。どこでも良いのだが、下手に/mnt以下にするとパーミッションで弾かれるかも知れない。(直せば良いのだが)
3)adduser user fuse
これをしないと /etc/fuse.confが読めねえ、と怒られる。
Slitazでは必要ない、はず。/etc/fuse.confが見当たらない。

 

sshfs リモート マウントポイント [options]
オプションの位置に注意。使うのは -C くらいか?

アンマウントは fusermount -u マウントポイント

便利だが遅いサーバー相手だとやはり使い勝手は良くない。リモートなのでゴミ箱が使えない。

 

ハイレゾのデモ音源を聴いていて気づいたのだが、手元の常用PCであるThinkPad R500(LinuxMint17.3-amd64-xfce4)は思いの外音が悪い。ThinkPadは昔から音にはひと通りの配慮があったのだが。まあ、まったくダメ、という訳ではなく、「何となくノイジーだよな」というレベル。

 

さて、HDDの空き容量が気になりだしたので、先日ようやく実用域に達したnfsにファイルを退避し、改めてサーバー上のハイレゾ音源を再生してみました。

 

そうしたらですね、音が変わりました。

 

クリアになりました。自分でも自分の耳を疑って(加齢の為、高域部分の聞き取りに明らかに難がある)、音源ファイルを替えて試してみたのですがどれも同じ傾向。

 

疑うべきはただひとつ。HDDへのアクセスの有無(あるいは多少)。ハイレゾはファイルサイズが大きいので、こんなところで差がでたのかも知れません。

 

しかし、ここで別の問題が。

手元のnfsは遅いので音飛びが生じるケースがありました。

 

何事も2つ良いことはないようです。

 

使っているプレイヤーはAudacious 3.8.2。LinuxMint17のリポジトリに収録されているのは少し前のバージョン(3.4.3)なので、Audaciousのサイトからソースを貰ってきて自前でビルドした。一般にx86だとビルドオプションの設定具合でバイナリの実行速度が大きく変わったりするがamd64では大差ない。R500(CPUはcore2duo)ではsse命令の世代がsse2からsse4.1に代わるくらいではなかろうか。何より、肝心のlibFLACはOSの既存品のままである。

 

ビット深度はAutomaticも選べるが、予め音源ファイルをmplayer で確かめて32に固定している。気休めである。

 

尚、configure 時にbuildstampを指定すると設定ダイアログの左下に表示されて便利。

 

自分宛てメモ

 

LinuxMintをVirtualBoxで動かしていて気づいたのだが、SlitazだとGuestAdditionsで生成されるモジュールの一つ(vboxvideo.ko)がロードされない。手動で modprobe とかするとエラーになる。

 

原因は最近のVirtualBoxにて、Linuxカーネルバージョン3.11未満及びxorgサーバー1.17未満を相手にしていないから、らしい。
Slitazはそれぞれ、3.2.71, 1.12.4である。

 

対策としては、VirtualBoxのサイトから旧バージョンのGuestAdditions(5.0.16)を貰ってきてインストールする方法があるらしい。

 

ということで、早速試してみたら取り敢えず解像度の件は解決。手持ちのディスプレイの最大解像度である1280x1024で表示できるようになった。

 

副作用が怖いな。

 

 

 

フォーラム参照先
http://forum.slitaz.org/topic/problem-installing-virtualbox-guest-additions-error-could-not-insert-vboxvideo-invalid-argumen

自分宛てメモ


tls(ssl)の設定
about:config
security.tls.version.min -> 2

LinuxMintの新バージョン、18.2(以下LM18,同様にLM17)がリリースされました。早速、手元の18.1(xfce4,amd64)をアップデート、またx86版(xfce,MATE)をVirtualBoxで動かしてみました。導入のしやすさは相変わらずで、誰でも使えるディストリビューションに仕上がっています。惜しむらくは日本語訳が不完全な箇所があることで、これは少し前に発覚した、「どこぞのウ◯◯ス◯ラ馬◯◯鹿ト◯ー◯◯シ◯ツがやらかしたライセンス抵触問題」が未だに尾を引いているのかも知れません。

 

さて、使いやすいLinuxMintですが唯一ややこしかったのがBluetoothの接続。LM17.3まで、そのままではオーディオデバイス(スピーカー)を認識してくれない場面があって苦労させられます。
原因はpulseaudioがbluetoothモジュールを正しく読み込んでくれないからなのですが、それでは、とxfce4の起動時点で読み込ませようと設定してもダメ。結局、デスクトップ起動後、手動で読み込ませるのが一番確実という不便さでした。

 

pactl load-module module-bluetooth-discover

 

しかし、使い始めこそ不便さを感じたのですが、慣れてしまうとむしろ好都合な事に気づきました。
bluetoothスピーカーは一度ペアリングしてしまうと、次回からは見つけた相手と自動的に接続しますが、時としてこれが煩わしいことがあるのですね。まあ、PC側のbtを止めておけば良いのですがスピーカー以外を繋ぐこともあるので、それはそれで煩わしい。

 

こんな時、pulseaudioにモジュールを読み込ませるか否か、で接続を制御できるという訳です。

 

LM18ではそんなこともなくなりました。UIもbluemanからblueberryに変わり、扱いやすさは改善されていますが、まだまだAndroidなんかに比べると遠く及ばないなあ、というのが実感です。

 

自分宛てメモ

 

/etc/exports
async

 

HDD
hdparm -t | -T

 

CPU
mpstat n

 

NFS
nfsstat

 

nfs上のflacを再生していてエラーが多発したので。mp3だと発生しないので、転送速度(容量)の問題か。

 

 

取り敢えず

sudo mount -t nfs 192.168.11.4:/home /mnt/nfs -o tcp,soft,timeo=5,bg,rsize=16384,wsize=16384

 

 

tcp使用時、rsize,wsizeは65536まで使えるらしい。デフォルトは32768とか。udpだと8192。大きければ良いというものではなく、サーバーがpoor(例えばPC)だったり回線が細かったりすると、タイムアウトするまでにパケットの転送が終了せずかえってパフォーマンスが低下するらしい。

 

手元の環境で試した(nfs上のファイルのmd5sumを取ってみた)ところ、32768及び65536でエラーが発生した。また、8192と16384とでは18秒程度と大差なかった。(なお、同一ファイルをクライアントにコピーし、md5sumをとったところ1秒未満で終了したので、この部分の時間は無視する)

大雑把に転送時間を計算すると17Mbps位(※)である。サーバーが遅い、回線が遅い(特にクライアントは無線LANで接続している)ということを考慮すればこんなものかも知れない。

 

他の手順との比較では、

FTP(サーバーpure-ftpd, クライアントgFTP)で9.375Mbps、SCP(サーバーDropbear、クライアントopenssh)では2.3MB/sと表示された(nfsよりわずかに速い程度)ので、nfsが極端に遅いということは無いと思われる。

 

※単純に転送バイト数に8を掛けているので。

サーバーを替えて試す。

 

サーバー LinuxMint17.3(i386,MATE) VirtualBox
クライアント LinuxMint17.3(amd64,Xfce4)

 

サーバー側の作業
テスト環境を新築した。OSが旧く、オンラインでアップデートする必要があるためVirtualBox側のネットワーク設定はブリッジとした。

VirtualBoxのGuestAdditionsもインストールした。
アップデート後、リポジトリからnfs-kernel-server をインストール。

 

サービスの起動方法
Mint17は昔ながらの方法で制御できた。18以降は試していない。
sudo /etc/init.d/nfs-kernel-server start | stop

 

 

クライアント側の作業
busybox mount でも、本来のmountでも正常にマウントできた。

 

エラー対策
障害が発生して(というより、クライアントの電源を落とす前にサーバーを落とした時)リトライがかかりっぱなしになる件
取り敢えず、mountオプションで、timeo=1,bg,softを付与してみたところ、端末で打ったlsはエラーメッセージを返して戻ってきた。
デフォルトのタイムアウト値は7(0.7秒)らしい。詳しくはman nfsを参照。

これで、Slitazで動かすサーバーに問題(という程のものでもない)があることの見当がついた。

 

サーバー Slitaz

クライアント LinuxMint 17.3(amd64,xfce4)

 

LinuxMintにもBusyboxはインストールされている。システム損傷時の緊急ツールとして用意されているものなので、アプレットはリンカとしては存在していない。

 

Slitaz(VirtualBox)の時とほぼ同じ方法でやってみたところ、正常にマウントされた。

 

sudo busybox mount -t nfs 192.168.11.4:/home /mnt/nfs -o nolock

 

/etc/fstab も読み込む。

sudo busybox mount -a

 

ここでエラーメッセージが。no_subtree_check は unknown option とのこと。このへんがBusyboxの辛いところ。余り凝ったことはできない。

 

にしても。

標準ツールでマウントできない、というのは謎である。サーバー側の問題なんだろうか。というか、以前はこんな面倒なことをしなくても確かに使えていた覚えがあるのだが。

 

7月1日追記

mount でも正常に動作することを確認。しかし、失敗する場合もある。回線速度が遅い、サーバーマシンの動作そのものが遅い、というのが根本的な原因のような気がする。

 

自分宛メモ

 

サーバー Slitaz

クライアント Slitaz(VirtualBox内)

 

※クライアント側のVirtualBoxにて、ネットワークの設定をNATからブリッジアダプターに変更する。これで仮想環境と実環境が同じネットワークに乗る(アドレスの割当は無線LANルーターで行う)。

 

Slitazフォーラムの過去ログ(http://forum.slitaz.org/topic/mountnfs-protocol-not-supported)によれば、util-linux-mountをインストールすると nfs mount/umountが壊れるらしい。

 

対策として、busyboxのアプレットを使う。

sudo busybox mount -t nfs 192.168.11.4:/home /mnt/nfs -o nolock

 

 

自分宛てメモ

 

いつの間にか、Slitazのnfsサーバーが動作しなくなっていたので。

 

このサーバーというのはいつもの音出しサーバーで、実験的にnfsを動かしてファイルサーバーにもしていた。転送速度が遅すぎるのと、サーバーにファイルを送るだけならmountしなくてもftpでもscpでも可能であること、何より、mountした後、クライアントよりもサーバーの電源を先に落としてしまうとクライアントが固まってしまう、という問題が解決できなかったので利用をやめていた。

 

で、本日、ある件で必要になり性懲りもなく起動しようとしたのだが。

 

/etc/init.d/nfsd start 等とやると、nfsd を modprobeしようとして「フォーマットが違うとか何とか」のエラーを吐く。

 

このサーバーに入れていたmodprobeはバイナリだったのだが、比較用に準備しておいた仮想環境上(virtualbox)のSlitazではkmodへのシンボリックリンクになっている。元々、kmodだったのを何かの弾みにmodprobeのバイナリを入れたのかも知れない。よく覚えていない。

 

ということで。

 

sudo tazpkg clean-cache

sudo tazpkg get-install kmod

 

取り敢えずサーバーは起動した。が、今度はクライアント側のLinuxMintで「このプロトコルをサポートしていない」とのことでマウントに失敗する。

 

先は長い。

 

 

 


Search

Calendar

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< August 2017 >>

Archive

Mobile

qrcode

Selected Entry

Link

Profile

Search

Other

Powered

無料ブログ作成サービス JUGEM