まさにタイトル通り。
携帯をスマホに変えたので、試しにkonata.netをスマホから見てみた。
流石にブラウザの中身はWebkitなので、表示は正しく行われる。
が、見難い。
現行のkonata.netのコンテンツは、全部PCでの参照が前提にして作っているので、
携帯端末から見ると、表示が大きすぎる。
臨時用2ch串のアクセス履歴には、携帯端末からのアクセスもあるのだけれど、
この表示で利用するのは中々に骨の折れる作業なんじゃないだろうか?
なれると平気なんかな?
臨時用2ch串とかモバイル版があった方がいいのかもしらん。
と一瞬考える。
しかし、ここ最近の規制のせいで臨時用2ch串での書き込み回数は、一日で2,000回を
超えることも少なくなく、同一IPを全員で使いまわす方式では、
これ以上のアクセスは捌き切れないと思われる。
モバイル版を作る→スマホユーザが増える→アクセスが増える→限界突破→\(^o^)/
なので、やっぱりモバイル版はナシの方向で。
そんな事を思った昼下がり。
仕事の関係で、Windows2003サーバをsambaに置き換えちゃおうという話が出た。
んで、仮想環境のFreeBSDにsambaいれてあれこれ試してたのだけれど、
どうやってもグループ毎にACLが設定できない。
たとえば、管理職と一般社員、監査役なんかでグループを分けて、
Aフォルダは管理職と一般社員がアクセスできて、
Bフォルダは管理職だけ、アクセスできる。みたいな話をやりたい。
アクセス権をそれぞれ振ってみたいな話をやりたい、
vfs object の acl_tdb と acl_xattr を見つけた時に、楽勝じゃん。と、思ったのだけれど。
ふつーに設定して、Windowsから共有フォルダを見て、セキュリティタブから権限を
設定しようとすると……
「アクセスが拒否されました」
「アクセスが拒否されました」
「アクセスが拒否されました」
と、一向に進まない。
こういう時って、フォルダ別に共有を作って、@groupみたいにグループ全部
書いていく方法が一般的なのだろうか?
で、調べる、smb.confのマニュアルやら、netコマンドのリファレンスだのを
しらみつぶしに見て、試して、試して、ためして、タメシテ
が、やっぱりできない。
で、ACLの権限関係のログを吐かせてみることにした
しかし、なんでsambaのログってこんなにカオスなんだろうか……
結局、それからさらに検索して、こんな情報に行き着いた。
そのあと、なんかそれっぽい予感がしたので、さらに単語を変えて検索。
この情報に行き着く。
行き着いた情報だけまとめると、ACL設定時のACEが3つ以外の場合、
その要求はコケる…………
試した結果、vfs objects の acl_tdb、acl_xattr があろうとなかろうと、
このルートに入り、問答無用で失敗する。
ちなみに、このコード、現行最新版の3.6.5ではもちろん、4.0のAlpha22でも入ってる。
失敗時に投げてた、ACE情報はどんなもんかと、”canon_ace index”で引っかけた
結果が以下。
ACEが7つ。そりゃ成功するわけないわ。
vfs_object の未設定状態や、acl_xattr なら、無制限にACE書き込ませるのは
なんとなくヤバいような気がするのだけれど、 acl_tdb はファイルに書くんだから、
大丈夫だと思うんだけどなぁ……
とりあえず、ソースを書き換えて、portsをちょろまかし、portupgradeで更新。
ぱっと見のACLのアクセス権がきちんと設定できていることを確認する。
業務時間が終わったので、権限がきちんと動くかは未確認。
まぁ、おいおいやればいいさ。
けど、これ、エロイ人に説明できんわ。
動作保障がものっそい面倒くさいもん。
※追記
CentOS5.8 だと、同じ権限要求があっさり通る。
ログを見ると、ACEが3つにマージされて成功するようになってるようだ。
全然そんなことなかった、やっぱダメだ。
SetEnvIfExpr のディレクティブで臨時用2ch串のアクセス拒否設定を済ませて、
apachectl -t でコンフィグチェックを走らせると、CoreDumpする。
再現率100%
以下がその時のスタックトレース。
全然関係のない別のSetEnvIfでコケてるように見える。
とりあえず、いくつかSetEnvIfを削ってやると無事起動することを確認。
本当はここ削りたくは無いのだけれど、アクセス拒否を優先することにした。
Apache 2.4系列、機能自体に不満はないのだけれど、もうちょっと安定して動いては
くれないものだろうか……
WebサーバをApache2.4.1に変えてから、httpd.confを書き換えると、
signal Bus error (10) を吐いてサーバが落ちる事象に悩んでいたのだけれど、
Apache2.4.2にバージョンを上げて恐る恐る httpd.conf を書き換えてみると
落ちなくなっていた。
これで、臨時用2ch串のアクセス拒否を正常運転できるようになった。
今までは、httpd.confの行数を変えるとエラーになっていたので、
古いアクセス拒否を消して新規のアクセス拒否を書いていたのだけれど、
これからは、そんな事をせずに済む。
まぁ、そんな運用をしなければならない事自体がおかしかったのだけれど。
Apacheの変更ログを見たところ、どうもこれで引っかかっていたっぽい。
ともかく、これでひと安心。
結論から言うと、Segmentation fault(11)は治らなかった。
とにかく、どうにもcore吐いてくれない事には始まらない。
という訳で、ググる。
カーネルの設定を変えてやればいいらしい。
sysctl kern.sugid_coredump
kern.sugid_coredump: 0
sysctl kern.sugid_coredump=1
kern.sugid_coredump: 0 -> 1
sysctl kern.corefile=/var/tmp/%N.%U.core
kern.corefile: %N.core -> /var/tmp/%N.%U.core
Apache は wwwにユーザー変えてるので、kern.sugid_coredump を 1に変えてあげないといけないと言うことらしい。
core吐く場所は、 CoreDumpDirectory ディレクティブで設定できる。
で、吐きました。
適当にぐぐってgdbで眺めてみると、
2chのどっかのスレのURLとsed_response_filter の文字が。
どうみても、mod_sedな関数名と、どう見ても、臨時用2ch串のアクセスっぽいURL。
試しに、そのスレのhtmlをローカルに落とし、そのhtmlに臨時用2ch串と同じ
mod_sed のディレクティブを書いてアクセスしてやる。
結果、再現率100%で落ちる事を確認。
吐かせたcoreも同じ箇所で落ちてることを示している。
つまり、ある特定のスレにアクセスすると、必ず反応がなくなる。
そういや、mod_sedはExperimental(実験的)モジュールの扱いだったなぁ……
と、今さらながらに思い出す。
けれど、mod_sedみたいな面倒くさいモジュールのソースを追う気は無い。
正確には、眺めてみたけどこれは手に負えそうにない。
なんとかならんもんかと、2.4の新機能を眺めて、あれこれググる。
どうも、mod_proxy_htmlにリンクを書き換えてくれる機能があるらしいのだけれど、
リンク以外にJavaScript追加してる所も有るので、こっちは使えない。
mod_ext_filterに戻るのはなんだか負けた気がする。
いや、別に勝負ではないんだけれど。
で、mod_sed つながりで、mod_substitute なんてのがあることを知り、
試してみると、これがいい感じに動いてくれる。
mod_substituteのステータスはExperimental(実験的)では無いので、落ちることもなかろう。
という訳で、こんなディレクティブを書いた。
これで、また様子をみることにする。