毎日モザイク

White Room Layout Works

2013-08-15T11:41:28+09:00 [Thu]
--> [Ubuntu]

.AppleDouble

netatalkにmacからファイルをコピーすると、リソースフォーク部分を管理する.Appledoubleという不可視フォルダができます。

これらの不可視ファイル/フォルダ群は邪悪な存在で、有名どころでは.DS_Storeが悪さをしますが、.Appledoubleもなかなか凶悪。

Appleshareのみの環境なら問題は出ませんが、同じディレクトリをFTPなどでも共有していると面倒なことに……。

Mac→netatalk

hage

これをls -laすると

hage .DS_Store .Appledouble

になっていて、これをFTPでgetすると、netatalkを経由しないので邪悪なフォルダ群がそのままコピーされます。

ここまでは何の問題も出ません。余分なクソフォルダがあるだけです。

これを、再度netatalkサーバにコピーしようとするとエラーが出てコピーできません。

afpdのログを見ると

check_name: illegal name: '.AppleDouble'

とあり、不正なフォルダ名なのでダメです。ということのようです。

ということで、netatalkの共有ボリュームから他の方法で落としたフォルダは、別のフォルダに移してからコピーするしかないようです。

OSXServerは仕組みが違うので平気でコピーできます。

OSXServerはファイル名にも寛容なので、Win/Mac他が混在する環境でのファイル共有は、OSXServerが一番簡単なのではないかと。

3.xでは、別の方法で管理するようですが、2.xのNASも多いので、NASで同じ現象が起こったら同じ原因でしょう。

ついでに。

netatalkほかで共有しあっているディレクトリを使うときは、マジでリソースフォークを使っている形式のファイルは止めた方がいいっていうか止めないと面倒です。

epsのpictプレビュー形式が典型的で、プレビュー部分が.AppleDoubleに入ってしまっていて、見えているファイルはプレビューなしになります

2013-08-05T02:46:37+09:00 [Mon]
--> [WordPress]

WordPressでマルチサイト

現行のwordpressは、標準でマルチサイト対応になっていて、そのバージョン以降はwwwつきURLにも対応しています。http://example.com/以下でなくても、http://example.com/hage/なんかにも設置できます。

それ以前は、www非推奨どころか非対応で、.htaccessでwwwなしのurlにリダイレクトして、apacheがwwwつきにリダイレクトして、.htaccessがwwwなしにリダイレクトして〜が、リダイレクト制限に達したところでアクセス不能になるという動作でした。

しかし、現行のバージョン(3.6)でも、一部のプラグインはその頃の仕様に合わせてあったり、http://expample.com/以下に設置する前提で決め打ちしてあるものもあって、動作確認が必要です。

wp-click-trackは、www非対応時代の仕様に引っかかっていて、カレンダー部分が表示されません。

wp-click-trackは非常に便利なのですが、決め打ち部分が割と多く、非標準の設置方法にすると何かと引っかかります。

それと、マルチサイト無効のものは問題ないのですが、マルチサイトを有効にしたものは管理画面が異様に遅いというおなじみの現象に見舞われます。

マルチサイト有効/無効での大きな違いは、.htaccessでmod_rewriteを使っているところで、コードをよく見ていないのでなんとなくですが、www非対応時代の名残があるのかも。

とりあえずの回避策は、使っているテーマのfunctions.phpに

<?php
add_filter( 'do_mu_upgrade','__return_false');
?>

を入れて、自動確認を無効にすれば爆速に戻ります。

これは、管理ページをリロードするたびに呼ばれ、そのつど更新確認をしに行くので、tail -f access.log を見ながら動かすだけで、明らかにそこで引っかかっているのがわかるほど時間がかかっています。

ここを無効にしても、ネットワーク管理者のダッシュボードで手動で確認できるので、特に問題ありません。

2013-06-15T14:24:31+09:00 [Sat]
--> [日常]

変更完了

低価格ルータを文字通り焦がしたことがあるので、うちみたいな規模ではオーバースペックですが、NVR500にしました。

細かい設定も概ね終わり、平常運行に戻りました。

だいたい10年ぶりの変更なので、だいぶ速いです。

前のだと、10~40Mbpsくらいでしたが、今度のは上下とも瞬間では80Mbpsを超えます。

NVR500(似たような仕様のYAMAHAルータも同じ)でPassive ftp

特に何の設定もいらないという記事もありますが、ftpサーバ側でpassive portを指定して、NVR500で指定ポートをサーバに届ける設定を入れないとだいぶ遅いです。

動的フィルタに任せた方がセキュリティ的にはいいんでしょうが、こっちの設定の方が圧倒的に速いです。

2013-06-14T07:11:17+09:00 [Fri]
--> [日常]

ルータ不調

一部の方から、ときどきダウンロードが遅いと言われ、そのつど社内の別ネットワークからインターネット経由で試しても問題なかったのですが、どこからやっても超遅になりました……。

HTTPとFTPは元と同じくらいなんですが、afpovertcpが異様に遅い。ADSL1.5Mbps時代より遅くなってました。

自分のLAN内では爆速のまま。他のプロトコルでは上下とも同じ。afpovertcpでも、外部のafpサーバとのmacからの送受信は以前と同じ。ルータのNAT関連がおかしいようなのですが、理屈がわかりませんw

理屈はわからないのですが、会社に転がっていた古い他社のルータでテストしたら以前と同じか速いくらいの結果になったので、同社の新型に買い替えようかと思います。

何れにせよ、このままではサーバを維持している意味が無いので、お急ぎ便で注文しました。

早ければ明日、遅くとも週明けまでには改善させます。

ご利用各位にはご迷惑をおかけしてすみません。

2013-03-19T15:23:08+09:00 [Tue]
--> [Ubuntu]

logrotate

カーネルのアップデートがあったので、早朝に再起動しました。

ときどき、logcheckタンが送ってくるメールを眺めていたら、clamxav-daemonが立ち上がっていないふうなログが出ていたので、見てみたら、確かに立ち上がっていない。

起動しようとすると、ログファイルのアクセス権がないと言う。

見てみたら、確かにオーナーが変わっていて、アクセス権がないw

どこで変わった? と、考えて、思い当たるフシはlogrotateしかありません。

logrotate.d/clamxav-daemonを見ると、やはりここでした……。

ローテーション後のオーナーをデフォルトのまま放置していて、設置後、最初のローテーション以降、ログが書き込まれていない状態になっていた模様……。

logrotateには、自分のサーバでも引っかかった事がある気がする。

と、思ったらここにあったw

横着者には、やっぱり、きっちりバチが当たるんですね……。