LogWatchの監視項目を減らす方法

毎日、毎日、３０台以上のマシンからLogWatchがシステムログのサマリーを送ってくれているわけですが、とある開発用サーバーがFTPの転送ログをこれまた毎日数十メガバイト分も送りつけて来ます。

ロギング自体をストップする権限は無いので、LogWatchからFTPの転送ログだけを除外することにしました。
マシンのOSは、CentOS-5.5です。

ところが、/etc/logwatch/conf/logwatch.confの中身は空です。
本体は/usr/share/logwatch/default.conf/logwatch.confにあって、こちらは変更したくありませんね。

ということで、ググって見つけました。

Stop logwatch reporting on a particular service on CentOS

サービス名の前にマイナス記号を入れることで、設定をオーバーライドできるようです。
/etc/logwatch/conf/override.conf:
Service = "-ftpd-xferlog"
---
とすることにしました。

Resinの実行アカウント

Resinサーバーをdebパッケージでインストールすると、rootアカウントで実行するように設定されてしまいます。この状態だと、サーバー上で動作させるアプリケーションもrootとして動作してしまうため、ミスの内容によってはシステムを破壊してしまうこともあります。

そこで、www-dataという制限ユーザーでアプリケーションを実行させるため、ちょっと調整を行います。
まず、/etc/resin/resin.xmlを修正します。

        184: <user-name>www-data</user-name>
        185: <group-name>www-data</group-name>
        186:  -->

という部分を探してください。コメントアウトされていますので、186行目のコメント閉じマークを移動させるなりして、ユーザー名とグループ名の指定を有効にします。

続いて、

/var/www/webapps
/var/www/resin-data
/var/www/log
/var/www/doc

以上４つのディレクトリと、その中身のオーナーをwww-dataに再設定します。

これで準備が完了しました。Resinサーバーを起動してみてください。また、問題が起きていないかログを確認する事も忘れないようにしましょう。

Resin-4.0の簡易評価

BLOGスペースを作ったことをすっかり忘れてました。。。

気を取り直して、Resinの評価です。
ResinというのはJ2EEサーバーなのですが、あまり日本では話を聞きません。
じゃあ、そんなマイナーなものをどうして、という話ですが、他のJ2EEサーバーと比較してResinが有用だと思われるケースがあるからです。
ResinにはQuercusというサーブレットが付属していて、PHPスクリプトを実行することができる。というのが利点です。

Debian系のLinuxにResin(-pro)をインストールすると、デフォルトのWEBサーバー用ディレクトリとして、/var/www/webapps/ROOTが作成されます。
でもって、ここにPHPファイルを置くと、そのまま実行できてしまうわけです。

さらに言うと、このResin上で動作するPHPはエンジン部分が拡張されていて、Javaのクラスモジュールなんかをimportできてしまいます。便利ですね。
ライブラリとかフレームワークの概念が無いプログラマに対抗するには、PHPスクリプトで作ったモジュールをWARファイルにまとめてデプロイするというような技も使えます。でも、WARファイルがZIPファイルであることを教えてはいけません。それこそ元の木阿弥です。w

既存のJ2EEサーバー上でPHPスクリプトを実行させたい場合は、Quercusモジュールを対象のJ2EEサーバーにデプロイしてあげれば、PHPの実行環境ができあがります。（web.xmlとかに設定を行う必要はあります）

Resinサーバーのアドバンテージは、PHPスクリプトをJavaにコンパイルして高速動作してくれることです。他のJ2EEサーバーでQuercusを利用する場合このアドバンテージは無くなりますが、J2EEサーバー上のライブラリを利用可能なPHPプログラムの開発という時点で何となく特した気分になれるかもしれませんね。

Lucid Lynx+GALILEOにADTをインストールする

Ubuntu-10.04(Lucid Linx)にADTをインストールする際、Eclipse(GALILEO)で次のようなエラーが出て、そのままではインストールできない。

... requires 'org.eclipse.wst.xml.ui 0.0.0' but it could not be found  

https://groups.google.com/group/android-developers/browse_thread/thread/1da899d34557f2e8?hl=ja
によれば、WSTをインストールしたあと、再度ADTをインストールすれば成功するということなので、その通りに行ってみて、ADTがインストールできることを確認した。

どこでもWi-Fiで、2chとかFacebookとか

２年間の時限式で契約した「どこでもWi-Fi」は、通信速度が約200Kbpsながらも月々千円弱という値段設定で有効活用中。

ただ問題となるのが、接続先のフィルタリング。子どもでも安全に使用できるようにというポリシーのため、2chを始めとして、アダルティーな香りのするサイトがほぼ接続拒否される。（そのうえ、拒否されたことを表示するページすら表示を拒否されたりして）
出会い系には接続できないようにする配慮からか、MixiやFacebook(Nintendo DSに標準搭載なんだが）もアクセス拒否される。

以 前はSquidを使ってプロキシを建てていたが、とにかくHDDとかメモリを馬鹿食いするし、設定は面倒だし、で古いLinuxBoxルータには荷が重 かった。この旧LinuxBoxルータが死亡したのを機に、新LinuxBoxルータではSquidの代わりにtinyproxyを使うことにした。
マシンのスペックは、Pentium2-233MHz、160MB、14GBってところ。

このマシンにUbuntu-10.04 Serverをインストールして、さらにtinyproxyをインストール。
tinyproxyの設定は、以下の部分だけ。

/etc/tinyproxy.conf:
Listen 192.168.0.2
LogLevel connect
#Allow 127.0.0.1
DisableViaHeader Yes

あとは、tinyproxyサービスを起動して終了。無事に、どこでもWi-Fi経由で2chとかFacebookにアクセスできるようになった。

192.168.0.2はADSLモデムに接続されていて、ADSLモデムが使っているグローバルIPをDynDNSで引けるようにしてある。
"Allow 127.0.0.1"をコメントアウトして、すべてのIPからの接続を許してあるけれども、サービスにアクセスするにはiptablesによる監査を受けたあと。つまりアクセス制御は、すべてiptablesとtcpwrapperで行っている。

tinyproxyはキャッシュを生成しないらしい。情報系のページを閲覧するには、キャッシュは無用の長物なので、Squidよりも都合がいいかもね。
高度な処理をしないぶん、メモリの消費量も少ないはず。

foursquareのカテゴリ

foursquareにvenueを登録したり、編集したりするときに悩むのがcategoryだ。

たとえば、銭湯とかコンビニとか神社は、これぞというマッチした選択肢が見つからないし、日本では十把一絡げに「公園」と称しているものが、複数の選択肢を持っていたりする。

まあ、コンビニは Shops ->  Food & Drink -> Grocery / Supermaket あたりが妥当なところだろうとは思うが、では、銭湯は？

銭湯を英訳すると、public bath、bathhouse、sentoなどだそうなのだが、そういう選択肢は無い。
かろうじて、Shops -> Spa / Massage がそれっぽくも感じるが、Spaの和訳は温泉・鉱泉だ。てことは温泉銭湯にしか設定したくなくなってしまう。

公園の場合は、まあ、なんとかなりそうな気もするが、まじめに分類しようとすると混乱すること必須かもしれない。
普段、公園と呼んでいるものに該当しそうなカテゴリが以下のようにいくつもある。
Parks & Outdoors -> Field

Parks & Outdoors -> Garden

Parks & Outdoors -> Park

Parks & Outdoors -> Playground

Parks & Outdoors -> Plaza / Square

でも、カテゴリを全部羅列して眺めてみると、何となくfoursquareでの分類方法が理解できるかもしれない。特にCollege & Educationが参考になるだろう。この分類項目は大学とかの構内にありそうな目標物を網羅している。
foursquareでは、目標物を面ではなく点で集積しようとしているのだろう。

それなら、カテゴリにそれほどこだわる必要もない。ひとつのvenueに複数のカテゴリを登録できるので、必要なカテゴリをどんどん追加する。結果としてvenueのカテゴリがあいまいになるか、もしくはより現実的な姿を表すようになるけれども、どちらがいいのかは利用者が判断する部分だろう。

Gwibberの設定ファイル

Ubuntu-10.04, Gwibber-2.30,CouchDB

Gwibberでは設定ファイルとしてApacheのCouchDBを利用している。

設定ファイルの場所は ~/.local/share/desktop-couch ディレクトリの中になる。同ディレクトリ内にあるcouchdb.htmlをfirefox等のWEBブラウザで開くと、CouchDBに関する簡単な説明が表示されたあと、設定DBの管理画面へリダイレクトされる。

Gwibber-2.30では隠しオプション等が格納されていなかったが、もしかしたら他のアプリは楽しいオプションが隠れているかもね。