現象： 私の２台のスマホの内、１台はつながるが、i-phoneの方がつながらない。もちろん以前はつながっていたし、いくらパスワードを設定してもダメ。そしておかしいのはパスワードをチェックをした様子は無く、即座につながらないと表示が出ること。
やった事：つながっているスマホをワザと切断し、パスワードを入れてもつながらなくなってしまった。何だこれは！！
解決：ルーター（無線のアクセスポイントも兼ねている）を再起動したら、問題解消。教訓：困ったときの再起動
近頃太陽が出て照度が充分あるのに東側の太陽電池が直列にならない。
抵抗値が経年変化で変化したのかと思い、半固定の可変抵抗器で調節したが、すぐに再度調整が必要になった。
どおもおかしい、CDSがダメになったのかと思ったが、その時、日中で暑いので屋根には登らず、夕方やろうと思っていたが、寄る年波でそれを忘れ、今日（実は西日本に台風が接近中）雨を合間を見て屋根に登って驚いた。取り付けたあるはずの容器（タッパウェア状のプラスチック容器）が無い。よく見ると太陽電池モジュールの下に転がっていた。だからおかしかった。ここに容器の写真がある
理由：プラスチックが経年変化でボロボロにもろくなり、取り付けビスから外れていた、ケースを触ると、ボロボロと分解する。教訓：屋外の直射日光の当たるところにプラスチック・ケースを設置してはいけない。
という訳でこのケースをアルミと曇りガラスで作ることにした。出来たらここで公開します。昔は家の隅に割れたガラスの破片がよく転がっていたが、今は見ないなー。うちにも無い。小さな曇りがラスを買うのもなー？
参考までに壊れたケースに入っていたCDSの写真。左上が比較の為に置いた新品のCDS。多分熱の為だと思うがセルの状態がかなり悪い
ふと気がつくと（気がつくのがかなり遅いですが。あまりサーバーをチェックしていないのがバレバレ）WEBサーバーからのAIDEのチェックメールが届いていない。
これはrootに転送し、aliasesでプロバイダーのメールに転送しているのだが。
# echo test | mail root
でテストメールをrootに送るがISPのメールに届かないぞー!
それではと /var/log/maillog をチェックすると
to=<root@kinryokai.net>, orig_to=<root>, relay=virtual, delay=0.16,
delays=0.08/0.03/0/0.04, dsn=5.1.1, status=bounced (unknown user: "root@kinryokai.net")私はメアドを postfixadmin で管理しているので早速、ログイン後 アドレス一覧を表示し（バーチャルホストの時は該当するドメインを選んで）
”転送先の追加”をクリック後、root@kinryokai.net のメアドを作成し普段使っているメアドに転送設定をした。再度
# echo test | mail root
とテストメールを出すとちゃんと、転送先のメールに届いたので、ISPのメアドを使う意味も無いので、AIDEのメールの送信先を、このサーバーで管理し、普段使っているメアドに設定した。
今までBuilding directory treeに時間が掛かっていたのはMYSQLの設定だった。
時間が掛かりすぎるのでbacluaのメーリングリストで聞いたら、やっぱりおかしいようだ。
一番の問題点はMYSQLのデーターベースエンジンに MyISAMを使っている事みたい。
これをInnoDBに変更する。ALTER TABLE テーブル名 ENGINE=InnoDB; を行なえと書いてあるが、データーベースごとそっくり変更出来ないかと調べたが、テーブル単位でしか出来ないようだ。
それではとデーターベースをエクスポートして、データーベース名を変更し、新規にbaculaをInnoDBで作り、インポートしたらおかしくなっていた。インポートしたファイルを見るとDBの指定がMyISAMになっていた。
面倒くさいので、既存のDBのテーブルを一つずつInnoDBにしてから
http://bacula.us/tuning/ にあるように /etc/my.cnf に
sort_buffer_size = 2MB
default-storage-engine=INNODB ←今後作るdatabaseのエンジンをINNODBにする
innodb_buffer_pool_size = 128MB
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT+-------+-------+----------+---------------+---------------------+------------+
| JobId | Level | JobFiles | JobBytes | StartTime | VolumeName |
+-------+-------+----------+---------------+---------------------+------------+
| 4 | F | 258,441 | 2,262,481,683 | 2015-07-02 14:32:50 | Vol-0004 |
| 14 | I | 158 | 79,623,411 | 2015-07-03 04:32:49 | Vol-0014 |
+-------+-------+----------+---------------+---------------------+------------+
You have selected the following JobIds: 4,14
Building directory tree for JobId(s) 4,14 ...何だこれは！！こんなに違うの！！そういえば以前は”Building directory tree”の時CPUのユーティライゼションが１００％になっていた。この時SWAPの状態をチェックしていなかったが、もしかしたらSWAPが大量に発生していたのかも?
【結論】baculaでmysqlを使うときは絶対にDBのベースエンジンは InnoDB にし、上記の設定を追加する事
この前に１１：リストアの時間が劇的に早くなったを参照の事。
どうもリストア時のファイルの作成（Building directory tree）に時間がかかりすぎる
+-------+-------+----------+---------------+---------------------+------------+
| JobId | Level | JobFiles | JobBytes | StartTime | VolumeName|
+-------+-------+----------+---------------+---------------------+------------+
| 4 | F | 258,441 | 2,262,481,683 | 2015-07-02 14:32:50 | Vol-0004 |
| 14 | I | 158 | 79,623,411 | 2015-07-03 04:32:49 | Vol-0014 |
+-------+-------+----------+---------------+---------------------+------------+
You have selected the following JobIds: 4,14
Building directory tree for JobId(s) 4,14 ... +++++++++++++++++++++++++++++++++++++++++++
224,831 files inserted into the tree.誤解の無いように言っておくが、これはリストアにかかった時間ではない。Building directory treeだけにかかった時間である。
ここで不安になって来た。もし壊れて場合こんなに時間がかかっているとその間はサービスが無い状態になってしまう。
ここから mark * で少し時間がかかり（上にあるように２２４、８３１もファイルがあるのでそれに印を付けるため）それから、いよいよリストアになりこれにも時間がかかる。
上の場合はフルバックアップと一つのインクリメントファイルだけである。最悪の場合（土曜日の時）フル、差分、6個のインクリメントの計８個のファイルを使って、リストアするファイルを作るとすれば、一体どれだけ時間がかかるの？
それとも私のやり方が間違っているの？どれだけ時間がかかるか調べて見ようか。
現在のバージョンは38.0.1です。ある時いつもは前回の終了時のタブを表示するのに、ホームページのみが表示される。
編集の設定（windowsはツールのオプション）から一般の起動にある”firefoxを起動するとき（S）”で前回終了時のウィンドウとタブを選んでもグレーアウト（私の設定では薄いブルーだが）していて選べない。
なんで！！
設定の中を色々見ていくと”プライバシー”に履歴があるのを見つけ、”履歴を一切記憶させない”になっていた。
ここを”履歴を記録させる”にしてfirefoxを再起動し再度、設定の一般で”firefoxを起動するとき（S）”を”前回終了時のウィンドウとタブを表示する”にし、又、再起動すると以前に開いていたタブが復元された。やれやれ
samba41-4.1.19にアップデートされたのはいいが、windowsからファイルサーバー（アクティブ・ドメイン）にアクセスできなくなった。
サーバーのログ（/var/log/samba/log.samba)を見ると
[2015/06/29 18:54:05.940937, 0] ../source4/smbd/server.c:370(binary_smbd_main)
samba version 4.1.19 started.
Copyright Andrew Tridgell and the Samba Team 1992-2013
ldb: module version mismatch in ../source4/dsdb/samdb/ldb_modules/acl.c : ldb_version=1.1.17 module_version=1.1.20
ldb: failed to initialise module /usr/lib64/samba/ldb/acl.so : Unavailable
抜粋（その下の /usr/lib64/samba/ldb/acl.so は存在するがバージョンが違うのでUnavailableになっているみたい。
google先生に聞くと。export LDB_MODULES_PATH="/usr/lib64/samba/ldb" を行なえとある。このままでは再起動後消えるので、.bash_profileに追記し、念のため再起動
でも同じエラーが出ている。
# yum list installed |grep ldb
で調べると
ldb-tools.x86_64 1.1.17-1.el6_4.wing
libldb.x86_64 1.1.17-1.el6_4.wing
pyldb.x86_64 1.1.17-1.el6_4.wingこれらを1.1.20にアップデートするために http://wing-repo.net/wing/6/x86_64/ から
pyldb-1.1.20-1.el6_6.wing.x86_64.rpm
libldb-1.1.20-1.el6_6.wing.x86_64.rpm
python-tdb-1.3.4-1.el6_5.wing.x86_64.rpm 2015-08-02追記：現在は1.3.6-1.el6_6.wing.x86_64.rpmになっている
libtdb-1.3.4-1.el6_5.wing.x86_64.rpm 2015-08-02追記：現在は1.3.6-1.el6_6.wing.x86_64.rpmになっている
の４つをダウンロードし
# rpm -Uvh pyldb-1.1.20-1.el6_6.wing.x86_64.rpm libldb-1.1.20-1.el6_6.wing.x86_64.rpm python-tdb-1.3.4-1.el6_5.wing.x86_64.rpm libtdb-1.3.4-1.el6_5.wing.x86_64.rpm
あれれ、エラーが出ている
エラー: 依存性の欠如:
libldb = 1.1.17-1.el6_4.wing は (インストール済み)ldb-tools-1.1.17-1.el6_4.wing.x86_64 に必要とされていますそれじゃー、ldb-tools-1.1.17-1.el6_4.wing.x86_64 を削除しよう
# rpm -e --nodeps ldb-tools-1.1.17-1.el6_4.wing.x86_64
再度
# rpm -Uvh pyldb-1.1.20-1.el6_6.wing.x86_64.rpm libldb-1.1.20-1.el6_6.wing.x86_64.rpm python-tdb-1.3.4-1.el6_5.wing.x86_64.rpm libtdb-1.3.4-1.el6_5.wing.x86_64.rpm
今度はうまく入った
準備中... ########################################### [100%]
1:libtdb ########################################### [ 25%]
2:libldb ########################################### [ 50%]
3:python-tdb ########################################### [ 75%]
4:pyldb ########################################### [100%]# service samba start
無事スタートしたので、windowsマシンからファイルサーバーにアクセス、やっと見れた
けれどもldb-toolsを削除したままなので、何かあるといけないので、同じ所( http://wing-repo.net/wing/6/x86_64/）から
ldb-tools-1.1.20-1.el6_6.wing.x86_64.rpm をダウンロードしインストールしておく。
こんな事なら最初からldb-toolsもダウンロードして５つのパッケージをインストールすればエラーは出なかったと思う。
エラーの内容は
エラー: パッケージ: 2:samba41-4.1.19-1.el6_27.wing.x86_64 (wing)
要求: libgfapi.so.0(GFAPI_3.4.0)(64bit)
問題を回避するために --skip-broken を用いることができません
これらを試行できます: rpm -Va --nofiles --nodigest色々調べると、これはgluserfs-apiに入っているみたいだが、これをインストールするにはglusterfs と glusterfs-libs も要るので、
http://download.gluster.org/pub/gluster/glusterfs/3.6/LATEST/CentOS/epel-6.6/x86_64/ から
glusterfs-3.6.3-1.el6.x86_64.rpm と
glusterfs-api-3.6.3-1.el6.x86_64.rpm と
glusterfs-libs-3.6.3-1.el6.x86_64.rpm の3点をダウンロードし
# rpm -Uvh glusterfs-3.6.3-1.el6.x86_64.rpm glusterfs-api-3.6.3-1.el6.x86_64.rpm glusterfs-libs-3.6.3-1.el6.x86_64.rpm
としてインストールする。
その後
# yum update
でアップデートすると samba が samba41-4.1.19-1 にアップデートされた。
８：他のホストにリストアでも言っていますが、バックアップされるホストの全てのファイルを（マウントしている他の領域の分も含めて）FileSetで指定してしまうと、リストア時にものすごく時間がかかってしまいます。ちなみに私はあるホストには/領域で6.7GB、マウントしている領域で2.4GBもう一つの領域で9.9GBをバックアップしたら、リストア時に８時間以上かかってしまいました。（バックアップされたサイズは１０．９ＧＢ）なので、方針を変更し、マウントしている領域はrsync（baculaでもいいが）で、作成しているバックアップ用のホストに１日１回同期させる様にしました。（マウントしている領域はWEBのデーターやmailのデーター領域等など、全てデーター領域です）
これで今日フルバックアップ（バックアップされたサイズは２．２ＧＢ）したので、後日リストアしてみてどれくらいの時間がかかるか報告します。
Gemfileに gem 'jquery-ui-rails'と記入し、app/asset/javascripts/application.jsに //= require jquery.ui.all、 app/asset/stylesheets/application.cssの最後の*/の前に *= require jquery.ui.all をそれぞれ追記し、サーバーを ctrl+c で止め、再度 rails s でスタートさせると
couldn't find file 'jquery.ui.all' with type 'text/css' とエラーが出た。
jquery-ui-rails の記入の仕方が 5.0 から変わった見たい。ここに回答があった
application.jsには //= require jquery-ui、application.cssには *= require jquery-ui と記入後、再度サーバーを立ち上げ直すとOKになった。
