毎日モザイク

12.04のセキュリティフィックスがもうすぐ来なくなるよって出てるので、14.04を経由して16.04にしました。

地獄…。

apache2地獄

主な地獄はapache2が2.4になって、設定ファイルが大幅に変更されたこと。

書き方は公式マニュアルを見れば解るのですが、サイトが二つしか無いのにディレクトリごとに細かいアクセス制限をしていたため、めんどくさいことこの上なし。

php7地獄

php7も設定の作法が変っていて、conf.dにmods-availableからシンボリックリンクを作れと書いてあるところが多いようですが、apache2のa2enmodと同じように、phpenmodっていうコマンドでやるのが作法なようです。

phpenmodでやると、conf.dの他のリンクみたいに自動で作ってくれます。

.iniファイルの二行目にプライオリティの数値を書いてやると、読み込み順を変えられます。

php.iniの設定を後から上書きしていくもので、後ろの方が優先度が高いので、重要な変更は90とかにしとくといいかも。

16.04のphp7のデフォルトがshort_tag=offなので、大抵のphpは動きませんw。90台のiniファイルに書いておくといいでしょう。

phpのmysql_なんたらが廃止されていて、mysqli_なんたらに変更。単に書き直せば動くものもあるようですが、p_blogは動かせませでした。非公開だからもういいか…。

perl地獄

次の地獄はperl。kentさんのbbsが残ってるのをどうすっかと思って開こうとしたらエラー。

色々見たらjcode.plが非対応になっていたという。っていうか、今まで動いていたのがすごいといえば物凄い。おそろしいほどの長寿です。

これもググって変更したら今まで通りに動き出しました。

wordpress地獄

wordpress関連だと、slimstat-exがだめ。

エラー関連で、互換性のない変更ってやつに引っかかっているようです。

作者は随分更新してないし、自力で直すのもめんどくさいので廃止に。

非対応プラグインを有効にしたままアップグレードすると、phpのエラーで何も表示されなくなることがありますが、なりましたさ。ええ。

非対応プラグインをディレクトリごと移動して、再読込してから元に戻して、作法通りに削除。

nginx地獄

nginxはめんどくさいので当面停止。

サーバ機の速度稼ぎにリバースプロキシキャッシュとして使ってたんですが、apache2.4とphp7が異様に速いので、当面止めとくことに。

今現在は、APCも廃止、nginxのキャッシュも廃止で、この速度。この程度のサイトには十分過ぎる速さです。

メール地獄

imapもあるんですが、なりゆきでpop3を使ってました。

ダウンロード済みがクリアされて、5万通くらい溜め込んでいたメールファイルが山のように、雪崩のように、滝のように押し寄せています。

これを、thuderbirdのダブリメール削除プラグインでダブりを消して、要らんもんを消して…。ああ、めんどくさい。早めにimapにしとけばよかった。

っていうか、たぶん、thunderbirdをmaildirに変更したときだと思いますが、ローカルのを消したらサーバのメールも削除するチェックがはずれてましたwwww。アホだ…。spamとかも全部残ってる…。死にたいw

で、

会社のサイトの練習用のはこんなもんでしたが、主な出し物のFTPとafpとメール関連は特に問題なく動き続けていました。

これを本番環境でもやるのかと思うとhellです……。

以前借りていたレンタル屋さんが、OSをアップデートするくらいなら出てってくれたほうがマシだと言っていたのがわからんでもないようなw。

いくら恩賜のX61が遅いと言っても、SSDだし、たかがFTPクライアントだし、起動に3秒はかかりすぎ。Libreoffice writerより遅い。
なんだろ？
と思って設定を見てみたら、言語設定が何れにも設定されていなかった。
明示的に設定されてないとグルグルするようだ。
En_usに設定したら1秒弱で起動するように。

コロコロ（ニトムズのやつ）の本体は、メッキでつるつるの棒と適当にヤワな樹脂の組み合わせで軸受け部分をなんとなく潤滑的な何かをしています。
ローラー部分がガタガタになるのは軸受け部分がすり減ってくるからで、ここに穴が空いたら概ね寿命です。寿命を迎えたコロコロをバラすと軸受け部分にすり減ったカスが残っているのがわかります。
そこでセラグリスHG。
コロコロと同じく、ツルツルの棒と適当にヤワな樹脂の軸受けの組み合わせといえば、フルベアリングではないラジコン車両とかといっしょ。セラグリスHGの出番でしょう。
軸受けの抵抗が減るのでコロコロしやすいし、軸受けの減りも防げます。
スライダーでゴム椀を押すタイプのキーボードの潤滑にも使えるし、PCの冷却ファンの軸受けにも使えるので用途は広い。
ご家庭で使うにはちょうどいい量なので、一家に一本セラグリスHG。

コピーが止まる問題をtcpdumpで見て何とか探すとかいうのは素人には無理すぎるw

finderで何かをコピーするってことは、finderのwindowをいくつか開いているわけで、こうしてあると、afpは接続持続のためのnoopを発行してみたり、window内のファイルリストをリアルタイムに近い形で更新するために、何もしなくても10秒に一度くらいファイルリストを問い合わせしてるし、コピー操作以外の通信が多すぎて、しかも、同じコマンドを使ったりしてるので何が何だか分からないw

もしかして、ファイルリストの更新のコマンドを発行するタイミングで、コピー先にあったはずのゼロバイトの一時ファイルがなくなってたりすると誤認識したりするのだろうか……。

それにしても、wireshark様のお蔭でtcpdumpのコマンドを覚えなくてもなんとかなるのは助かる。

自分の閉鎖環境でやってる時は気が付かなかったのですが、お勤めに出ている先で頻繁に起きるので閉鎖環境でテストしてみました。

（久々にwiresharkを新しいのに入れ替えたら、Xアプリだったのがネイティブになっててちょっとびっくり。）

起きる環境

サーバ　osxserver 10.6, netatalk2.1.5

お勤め先は非公開なので解りませんが、windowsとかnetatalkではないとのことなので、osxserverでしょう。たぶん。

クライアント　MacOS10.11.6

お勤め先は社外秘なので、最新ではないとだけ。

起きる現象

afpサーバ上の同一ボリューム内の異なるフォルダからフォルダへファイルをコピーしようとすると-43エラーで止まる。

よくわからない

パケットキャプチャを読むと、Finderで同じサーバ上のファイルを別のディレクトリにコピーする時は、大雑把にこんな手順のようです。

掴んだファイルの情報を得る。

ドロップ先に掴んだファイルと同名ファイルがあるかどうか尋ねる。

同名ファイルがないよって答えが来たら、ゼロバイトのファイルを作ってくれって要求する（Finderで見えるグレーのファイルはサーバ上にゼロバイトで実際に作られる）

コピー先に作ったゼロバイトのファイルを消してから、コピーを要求する。

コピーされる。

コピーしたよって返事が来たら、コピー先のファイルがあるかどうか尋ねる。

あるよって答えが来たらおしまい。

みたいな感じです。

この間、ファイルがあるかどうかを確認してるので、毎度毎度、それこそ数十ミリ秒に一回くらいobject not foundが返ってくるので、見つからない項目がどうたらは四六時中起こっているわけで、それを捕まえて見つからないと言っているわけでもなさそう。

netatalkにもOSXserverにもエラーログは残らないので、サーバ側のエラーというわけでもなさそう。

相手がnetatalkでもOSXServerでも同じ挙動なので、やっぱりFinderが誤認してるのか？　netatalkはOSXServerと同じ動作を目指してる(?)のでOSXServerと同じ問題を抱えてるのか？

同一サーバでも別のボリュームだと、copyじゃなくて、readとwriteの繰り返し（クライアントを経由する）なので、動作が違うから問題ないのでしょう。

どうも、copyコマンドの扱いに問題がありそうな気がするところまでしかたどり着けなかった…。