# yum --enablerepo=fc6extras install mod_suphp
[global]
logfile=/var/log/suphp.log
loglevel=info
webserver_user=apache
docroot=/
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false
check_vhost_docroot=true
errors_to_browser=true
env_path=/bin:/usr/bin
umask=0077
min_uid=500
min_gid=500
handle_userdir=true
[handlers]
; ここを変更する
;x-httpd-php=php:/usr/bin/php
x-httpd-php="php:/usr/bin/php-cgi"
x-suphp-cgi=execute:!self
LoadModule suphp_module modules/mod_suphp.so
# mod_suphp を有効にするときは、頭の#を消す
#suPHP_AddHandler x-httpd-php
suPHP_AddHandler x-httpd-php
suPHP_Engine on
# 下記を php.conf から転記する
AddHandler x-httpd-php .php
DirectoryIndex index.php
chmod 777 /var/lib/php/session
# /etc/init.d/httpd restart
<?php phpinfo(); ?>
Server API: CGI/FastCGI
# tail /var/log/suphp.log
-----
Executing "/xxx/phpinfo.php" as UID 501, GID 501
$modversion['license']があります。しかし、実質的には、XOOPSのモジュールが暗黙のうちにGPL2にライセンシングしています。
これは妙だな、と思って調べてみたら、特殊なケースを覗いて、モジュールのライセンスはXOOPS2に引っ張られてGPL2にしなければならないようです。GPL2では、「プログラム」の派生物（二次的著作物）はGPL2でなければならないと定めています。（GPL3でもだめ。）
いや、ちょっとまてよ。モジュールって別にXOOPSの派生物じゃないじゃん！と思ったのですが、これがどうもGPL2ではモジュールを派生物と捉えるのが妥当のようです。どうしてこうなるかというと、GPL2ではソースコードをつぎのように捉えているからです。
ある実行形式の著作物にとって完全なソースコード とは、それが含むモジュールすべてのソースコード全部に加え、関連するイン ターフェース定義ファイルのすべてとライブラリのコンパイルやインストール を制御するために使われるスクリプトをも加えたものを意味する。 GNU 一般公衆利用許諾契約書
どういうことかというと、「実行時に読み込んでいるライブラリもそのプログラムの一部です」ということ。XOOPSのモジュールの場合、require '../../mainfile.php';を行うので、その時点でXOOPS2のGPL汚染が始まります。現にGPLのFAQで次のようなことが述べられています。
ライブラリが(LGPLではなく)GPLの下で公開されている場合、そのライブラリを利用するプログラムにはGPLが適用されていなければならないのでしょうか?
はい。なぜなら、実際に実行されるプログラムはライブラリを含んでいるから です。
GNU GPLに関して良く聞かれる質問
GPLの下で公開されていたプログラムがプラグインを使うとして、プラグインのライセンスにはどのような条件がありますか?
それはプログラムがどのようにプラグインを呼び出すかに依ります。プログラ ムがforkやexecでプラグインを呼び出すならば、プラグインは別のプログラム であり、メインプログラムのライセンスはそれらにはなんの条件も課しません。
もしプログラムがプラグインと動的にリンクされており、お互いにファンクショ ンコールを使ってデータ構造を共有している場合、それらは単一のプログラム を形成していると見なされますので、プラグインはメインプログラムの拡張部 分として扱われなければなりません。すなわち、それらはGPLかGPLと矛盾しな いフリーソフトウェアライセンスの下で公開されなければならないということ です。
プログラムがプラグインと動的にリンクされているが、それらの間のコミュニ ケーションはいくつかのオプションとともにプラグインの「main」関数を呼び 出して返値を待つだけという場合は、境界線上で微妙なケースとなります。
GNU GPLに関して良く聞かれる質問
このFAQが意味するのは、モジュールがXOOPSのライブラリ（例えば、XoopsTpl, XoopsObject, XoopsUserなど）を使う限り、別個に配布しようが、モジュールはGPL2になるということです。動的にライブラリを使うか場合、GPLは感染しない、なんという主張もありましたが、実際にライブラリを使うのに動的か静的かでGPLの制約が変わるというのも変な話です。
しかし、まったくXOOPSのライブラリに依存せず、なおかつ、XOOPSなしでも完全な実行ができるモジュールであれば、GPL2を名乗る必要もありません。それはGPLのFAQを隅々読みつくせば、このことを暗示する記述が見られます。しかし、そのようなモジュールはXOOPSと互換するようなライブラリを独自で開発するか、単純な機能しかもたないモジュール（例えば、index.phpでphpinfo()だけを出すモジュール）に限られると考えられます。あくまで、理論上可能という話です。XOOPS専用モジュールである限り、GPL汚染からは逃れられそうにありません。
XOOPS Cubeは修正BSDライセンスでリリースされていると聞きます。では、縛りのゆるい修正BSD版XOOPS Cube用にモジュールをリリースすれば、GPL汚染から逃れることができるでしょうか？
そもそも、XOOPS Cubeが修正BSDライセンスだと勘違いしている人がいるように思います。
XOOPS Cube Legacy は、 Cube コアのモジュールのひとつです。当プロジェクトが新作した Cube コアと、 XOOPS2 JP の後継版として働く Legacy の二つが手を繋いで、 XOOPS Cube Legacy （以下XCL）が動作します。XCL は、 ”XOOPS Cube でもあり、 XOOPS2 JP の後継アプリケーションでもある” という、とてもユニークな CMS です。
XOOPS Cube Legacy の真実……？
では、XOOPS Cubeのどこが修正BSDライセンスかというと、XOOPS Cube Coreです。これはXCLでいうところの、XOOPS_ROOT/core/フォルダのみを差します。xoopscube.jpにはXOOPS Cube Coreのみが修正BSDライセンスとの旨を誤解なく書いています。
XOOPS Cube Core
XOOPS Cube Coreは修正BSDライセンスを採用しています。修正BSDライセンスは、元のBSDライセンスから広告条項の部分を削除したものです。
ライセンス
[修正 2010/03/07]正確には、XOOPS CubeとXOOPS Cube Coreは同じものを差します。したがって、XOOPS Cubeは修正BSDライセンスということになります。なお、XOOPS CubeとXOOPS Cube Legacyはライセンスが異なります。XOOPS Cubeは修正BSDライセンス、XOOPS Cube LegacyはGPL2ライセンスです。修正BSDライセンスのXOOPS Cubeというのは、ここで配布されているものです。
coreだけでモジュールを作ればライセンスはGPLに限られません。ところが、coreだけでは通常のモジュールを作れないのが現実です。つまり、XOOPS CubeであってもXCLであっても、GPL2が飛び火してしまうのは避けられないことのようです。
[補足 2010/03/07]minahitoさんによると、「XCコアモジュール（Legacy Base非依存の、コアのサブシステムを差し替えるもの）は修正BSDで出せますよ。」とのことなので、Legacyから独立したベースモジュールの場合、GPL汚染は起こりません。
テーマはモジュールと異なり、CC(クリエティブ・コモンズ)で公開されていることがあります。どうも、テーマはモジュールとは事情が異なるようです。それは、ひとつの考えとして、テーマがそれだけで完結している点が挙げられると思います。
テーマはSmartyに依存していますが、Smarty自体はLGPLです。LGPLは動的にライブラリを使う場合は、GPLやLGPLの制約を受けないというライセンスです。したがって、Smartyに依存するだけでは、GPLの感染の問題はありません。
しかし、XOOPSのSmartyプラグイン(xoops_date_format, xoops_userなど)を使ったテーマを配布する場合は、テーマもGPL2ライセンスにする必要がありそうです。なぜなら、XOOPSのSmartyプラグインはGPLだからです。GPLでは、動的にプラグインを使用する場合でも、その著作物をGPLにライセンシングすることを要求します。
Smartyにもとから入っているプラグインだけで作ったテーマなら、GPLでなくてもいいといったところだと思います。ただし、Smarty変数がXOOPSなしでは定義されない点を考えると、XOOPSに依存しているということになり、GPL2適用の義務が生じるかもしれません。この点で、テーマはGPLと非互換のCCで配布するのは、グレーゾーンでもあります。
[補足 2010/03/07]minahitoさんによると、「あとテーマは、コードとみるかリソースとみるかで解釈が全く変わります。パイプラインがテーマをコンパイルし、結合可状態へ導いて初めてリンクされるので、GPLとコンフリクトしないライセンスなら(コンフリクトするとXCLで使用不可)選べると思います。」とのことです。リソース、つまり「データ」としてテーマを見る場合はGPL以外の選択肢もあるということ。（minahitoさんはGPLと互換性のあるライセンスならOKとしていますが、GPL汚染を受けていないと主張できる独立したテーマなら、非互換のライセンスで配布も可能なはずです。なぜなら、結合の制約は「複製・頒布・改変」のときだけで、実行するときにGPL非互換と結合することは制限していないはず。）ただし、コードかリソースかも解釈に依存していて、もしテーマがリソースだと判断できない場合は、GPL汚染を受けるかもしれないということです。たとえば、ひとつのテーマパッケージにXOOPS依存のPHPコードが混じっている場合など。詳しくはFAQに書いてあります。
]]>
# yum install bind bind-chroot
# yum install caching-nameserver
# cd /var/named/chroot/etc/
# cp -p named.caching-nameserver.conf named.conf
options {
// 外部にポートを開ける
// listen-on port 53 { 127.0.0.1; };
// listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
// 外部からの問合せを許可する
allow-query { any; };
allow-query-cache { localhost; };
// スレーブへのゾーン転送を許可する
allow-transfer {
xxx.xxx.xxx.xxx;
};
};
// rndc key を指定する
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
include "/etc/rndc.key";
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
// view 指定を外す
//view localhost_resolver {
// match-clients { localhost; };
// match-destinations { localhost; };
// recursion yes;
// include "/etc/named.rfc1912.zones";
//};
include "/etc/named.rfc1912.zones";
// マスターのソーンファイルを指定する
include "/etc/named.master.zones";
zone "exsample.com"{
type master;
file "masters/exsample.com.zone";
allow-update { none; };
};
$TTL 86400
@ IN SOA host.exsample.com. postmaster.exsample.com. (
2010010101 ; serial
86400 ; refresh
3600 ; retry
3600000 ; expire
1200 ; Negative Cache TTL
)
@ IN A xxx.xxx.xxx.xxx
@ IN NS ns1.exsample.com.
@ IN NS ns4.exsample.com.
@ IN MX 10 mail.exsample.com.
localhost IN A 127.0.0.1
host IN A xxx.xxx.xxx.xxx
ns1 IN A xxx.xxx.xxx.xxx
ns2 IN A xxx.xxx.xxx.xxx
mail IN A xxx.xxx.xxx.xxx
# chmod g+w /var/named/chroot/var/named
# /etc/init.d/named start
# dig exsample.com @localhost
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> exsample.com @localhost
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2075
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; QUESTION SECTION:
;exsample.com. IN A
;; ANSWER SECTION:
exsample.com. 86400 IN A xxx.xxx.xxx.xxx
;; AUTHORITY SECTION:
exsample.com. 86400 IN NS ns1.exsample.com.
exsample.com. 86400 IN NS ns2.exsample.com.
;; ADDITIONAL SECTION:
ns1.exsample.com. 86400 IN A xxx.xxx.xxx.xxx
ns2.exsample.com. 86400 IN A xxx.xxx.xxx.xxx
host.exsample.com. 86400 IN A xxx.xxx.xxx.xxx
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 7 00:44:17 2010
;; MSG SIZE rcvd: 147
nobu さんが検討してくれたチューニングを取り込みました(^ ^)。
これは結構効いてるかも。
]]>OSC で suin さんに聞いたアイディアを元に、
XCube_Root::getSingleton()->mContext->getAttribute('headerScript')->setMeta('keywords', 'xoops,development,module')
で、html のメタ要素（この例では "keywords"）を設定できるようにしました。
用途としては、ページによって robots の設定を変えたり（RSS拾って表示しているページとか）、rating 変えたりとかでしょうか。
]]>
解決できました（汗）
Smarty 3 APIはシンタクスが新しくなりました。Smarty2のシンタクスはサポートしますが、将来サポートが保証されない可能性があります。
Smarty3はPHP5のみ対応します。PHP4では動きません。
{php}タグはデフォルトでは無効になりました。{php}タグを使うことは非推奨です。$smarty->allow_php_tag=true;で{php}タグを有効にすることができます。
しかし、複数の{php}タグにまたがるPHPコードは、これ以上は動かないでしょう。
ホワイトスペースに囲まれたデリミタは今後、Smartyのタグとして扱われません。したがって、{ foo }はタグとしてコンパイルされません。この場合、コンパイルするには{foo}とする必要があります。この変更により、{literal}が必要とならないので、Javascript/CSSが扱いやすくなります。なお、$smarty->auto_literal = false;でこの設定を無効化できます。
Smarty2は、パラメータにクォートしていない文字列が現れたとき、大雑把で曖昧な面がありました。一方、Smarty3はより厳密です。といっても、特別な文字(A-Za-z0-9_以外)を含まない限り、今でもクォーテーションなしの文字列を使うことはできます。
例えば、ファイル名の文字列はクォートしなければなりません。
{include file='path/foo.tpl'}
Smarty3は初期化するのに、__constructメソッドを使います。Smartyクラスを拡張するとき、もし、小クラスが独自のコンストラクタを定義すると、Smartyのコンストラクタは実行されません。Smartyのコンストラクタを実行する必要があれば、小クラスのコンストラクタでparent::__construct()を実行してください。
class MySmarty extends Smarty {
function __construct() {
parent::__construct();
// your initialization code goes here
}
}
Smarty3はspl_autoload_registerで独自のオートローダーを登録します。もしあなたのコード中に__autoload関数が存在するのなら、 それを明示的に__autoloadスタックに登録しなければなりません。 詳しくは、http://us3.php.net/manual/en/function.spl-autoload-register.php を御覧下さい。
Smarty3ではPHP spl_autoloaderをサポートしています。このオートローダーは、ファイル名を小文字にすることを要求しています。したがって、Smartyプラグインのファイル名は小文字である必要があります。Smarty2では、大文字小文字が混在したファイル名でも動作しました。
Smarty2では特別なSmarty変数(例えば、$smarty.section...や$smarty.foreach)がグローバルスコープでした。もし、同じ名前のループがサブテンプレートにあると、親テンプレートの変数を上書きしていまします。
Smarty3では特別なSmarty変数は、ループがあるテンプレートのローカルスコープになります。もし、親テンプレートの変数をサブテンプレートに渡す場合は、パラメータにする必要があります。
{include file='path/foo.tpl' index=$smarty.section.foo.index}
Smarty3はutf-8をデフォルトcharsetとして、定数SMARTY_RESOURCE_CHAR_SETに定義します。これは、escapeのような修飾子のデフォルトcharsetとして使われるようになります。もし、utf-8以外のcharsetをテンプレートで使う場合、適宜にSMARTY_RESOURCE_CHAR_SETを定義することに注意してください。そうしなければ、なにも出力されない可能性があります。
テンプレートのソースに予期される改行の出力を得るために、{if},{else},{elseif},{/if}タグのコンパイル後コードに¥nが追加されました。もし、{if}タグなどが行末にある場合、HTMLの出力結果が改行されます。
「主催者」という項目名に変わっています。
define("_WLS_PROMOTER","主催者");
ＱＲコードが黒い小さな点で表示されるだけでうまく生成されません。
その新規投稿と編集にかかわるPHPファイルを教えて頂きませんか？
ところで、d3imgtagはイメージマネージャ統合機能として使っていますが、PHPモードでImageMagick処理には問題ないようです、
全国３千万人のオルソマッパーのみなさん、こんにちは。
熱心なオルソマッパーの方であれば、すでにご存知かと思いますが、今月末（平成２２年３月末日）をもって国土交通省国土計画局による「オルソ化空中写真」の提供が終了してしまいます。
つきましては、日頃お世話になった「オルソ化空中写真」に感謝を込めて、【緊急企画】といたしまして、「オルソよ今夜もありがとう ～ さよならオルソ大謝恩祭り」を開催いたします。
オルソに別れを惜しみつつ、貴重な最後の機会を有効に利用いたしましょう。
オルソ・ヘビーユーザーは、もちろんの事、まだオルソに触れたことのない方も大歓迎です。みなさん、ふるってご参加ください。
【開催日時】
本日より、平成２２年３月末日、オルソサーバーの息絶えるまで。
（尚、今年は暖冬につき、３月下旬は、お花見のシーズンを迎えそうです。お早目のご参加をお勧めいたします。）
【開催会場】
なし！ ご自宅でもＯＫ、お好きな場所でどうぞ。
【参加資格】
なし！ 誰でも自由に参加可能です。
【参加費用】
なし！ 但し、必要により、ネット回線、ＰＣ、おやつなどは各自ご負担ください。
【参加方法】
・JOSMやPotlatchで利用可能ですが、個人的にはJOSMをお勧めいたします。
・JOSMでの利用は、こちらをご参考にしてください。
・OSM-wiki : JOSM
・OSM-Tokai ML: オルソ化空中写真の利用
・あとは、ググってください・・（ぉぃ！
【主催】
・OpenStreetMap東海