XOOPS専用シンボリックリンクファイル生成・自動削除ツール
投稿者: Ujiki | 投稿日時: 2006-7-19 19:54 | 閲覧: 5893回
みなさん、はじめまして。 Ujiki.oOです。
１つのアカウント、１つのMySQLテーブルＤＢ、そして任意の複数XOOPSを運用することを目的に、
標題の通り、「XOOPS専用シンボリックリンクファイル生成・自動削除ツール」を作成しました。
目下、無料配布中(笑)です。詳しくは、Livedoor Wiki で解説中です。
modules なのですが、シンボリック下でも、正常に稼動できるような仕様、つまり mainfile.php に完全準拠するような、コア、モジュール開発の御願いを、いまさらお願いするのも気が随分とひけてしまうのですが・・・・・如何なものでしょうね。
MySQLサーバー機との通信さえ確立できれば、異なるユーザーであっても、どこかに基本のxoopsがあれば、ルートからの絶対パスのシンボリックリンクで、どんどんxoopsを増殖できるとしたら、どこのサーバーでもハードディスク・リソースの重複占拠が無くなるので、管理者も利用者も、幸せになれるような気がしてなりませんが。xoopsのバージョン管理も一元化できたりもします。
modules も、シンボリックリンク先を変えるだけで、modules のバージョンアップ、バージョンダウンも出来ますね。ダメかな^^;
【2006/10/17 追記】：シンボリックリンクがPHPより定義できるサーバーか、否か。
phpinfo() レポート内の、Directive欄の「 disable_functions 」を確認してください。「 Local Value 」欄に「 symlink 」が含まれていると、本ツールは利用できません。
関連スレッド：XOOPS用サブサイト簡単作成スクリプト by やまもと氏 2003-7-19
１つのアカウント、１つのMySQL
標題の通り、「XOOPS専用シンボリックリンクファイル生成・自動削除ツール」を作成しました。
目下、無料配布中(笑)です。詳しくは、Livedoor Wiki で解説中です。
modules なのですが、シンボリック下でも、正常に稼動できるような仕様、つまり mainfile.php に完全準拠するような、コア、モジュール開発の御願いを、いまさらお願いするのも気が随分とひけてしまうのですが・・・・・如何なものでしょうね。
MySQLサーバー機との通信さえ確立できれば、異なるユーザーであっても、どこかに基本のxoopsがあれば、ルートからの絶対パスのシンボリックリンクで、どんどんxoopsを増殖できるとしたら、どこのサーバーでもハードディスク・リソースの重複占拠が無くなるので、管理者も利用者も、幸せになれるような気がしてなりませんが。xoopsのバージョン管理も一元化できたりもします。
modules も、シンボリックリンク先を変えるだけで、modules のバージョンアップ、バージョンダウンも出来ますね。ダメかな^^;
【2006/10/17 追記】：シンボリックリンクがPHPより定義できるサーバーか、否か。
phpinfo() レポート内の、Directive欄の「 disable_functions 」を確認してください。「 Local Value 」欄に「 symlink 」が含まれていると、本ツールは利用できません。
関連スレッド：XOOPS用サブサイト簡単作成スクリプト by やまもと氏 2003-7-19
コメント(4)
新しいものから |
古いものから |
ネスト表示 |
Re: XOOPS専用シンボリックリンクファイル生成・自動削除ツール
Re: XOOPS専用シンボリックリンクファイル生成・自動削除ツール
投稿者: Ujiki | 投稿日時: 2006-8-17 4:46
引用：
シンボリックリンク生成による、実際のディレクトリー階層と、Webサーバーが履歴として保持するURLによる階層の相違を実際に体得できる「実検道場」(仮称)を設置致しました。学校での授業にも、どうぞ。
- Ujiki.oO -
□ ルール： 複数の方がヒッチしないように、Ujiki.oO XOOPS / Forum で、利用宣言による予約をお願い致します。別に受け付け処理は行っておりません。(おいおい) まあ、受け付け掲示メモとでも言いますか・・・利用したい方は他の方の予約をチェックする。利用したい方は空いている日時とフォルダー番号を書き込んでおく。そんな程度です。済みません。詳しくは、こちらにルールがあります。
□ 道場への最新リンク情報： Ujiki.oO XOOPS / Web Link にあります。
自己レス参照：
modules なのですが、シンボリック下でも、正常に稼動できるような仕様、つまり mainfile.php に完全準拠するような、コア、モジュール開発の御願いを、いまさらお願いするのも気が随分とひけてしまうのですが・・・・・如何なものでしょうね。
シンボリックリンク生成による、実際のディレクトリー階層と、Webサーバーが履歴として保持するURLによる階層の相違を実際に体得できる「実検道場」(仮称)を設置致しました。学校での授業にも、どうぞ。
- Ujiki.oO -
□ ルール： 複数の方がヒッチしないように、Ujiki.oO XOOPS / Forum で、利用宣言による予約をお願い致します。別に受け付け処理は行っておりません。(おいおい) まあ、受け付け掲示メモとでも言いますか・・・利用したい方は他の方の予約をチェックする。利用したい方は空いている日時とフォルダー番号を書き込んでおく。そんな程度です。済みません。詳しくは、こちらにルールがあります。
□ 道場への最新リンク情報： Ujiki.oO XOOPS / Web Link にあります。
Re: XOOPS専用シンボリックリンクファイル生成・自動削除ツール
投稿者: Ujiki | 投稿日時: 2006-8-17 5:26
引用：
安定していて、事故に遭遇しない環境って立派ですね。
って言うか、故障の無いコンピューターって皆無ですから、保全メンテナンスがきっちりしたサーバーをご利用のことかと存じ上げます。サーバー管理者が立派なポリシーを持っておられて、出費を惜しまず先手で保全用投資を続ける・・・・
もしも、何らかの原因でXOOPS領域が壊れたり、MySQL領域が壊れたり・・・XOOPS管理者である自分のミスで無くしたり、そんなことを当方では起こしてしまう可能性が大ですので、即時代替えできるサブXOOPSって必須な感じです。これってなさけないですね。
また、α版だったり、β版だったりの、新しいモジュールなどの利用実検にも、クローンXOOPSである裏XOOPSを立ち上げておいて、MySQLデーターもコピーした環境て実検を積極的に行います。そんな時に、クローンXOOPSって便利ですよ。「あちゃ〜、使えない」場合は、MySQLデーターを上書きしちゃう。
領域が有限で押さえ込まれている Free Web Hosting で可能な限り絞り込んだ占有って、複数のXOOPS稼動には、クローンXOOPSを増やす方法しかありませんね。
「XOOPSを利用しているけど、MySQLデーターのバックアップってしたことない」って言う人口が多くはないのかが最も心配です。「MySQLデーターのバックアップは行っているけど、復元させた経験がない」と言う人口も多くないでしょうか。
自分が100%作成した著作物が消失したなら仕方がない。でもXOOPSのように自分以外のユーザーの汗水でデーターが構築されますから、MySQLの保全と復元には慣れて欲しいと願います。
クローンXOOPSを作成する時には、自然と、MySQLのバックアップ(ダンプ)と、MySQLの復元を繰り返したりしますので、「いざ鎌倉」においても、MySQLの復旧は手馴れたものになるはずです。:boke:
引用：
まあ、XOOPSの中身は知りたくないけど、XOOPSの管理者となって自営したい方には便利な一面もありますが、XOOPSを熟知しており、自分専用のXOOPSを構築している、構築したい人にとっては、無用なことのようです。
引用：
themes も考え様によっては、サイト毎にチューニングが必要だったりしませんか？ 特に Free Web Hosting を利用する場合は、広告位置を themes 内で特別に調整しますよね。上書きしてしまったり、XOOPS標準で利用しては、デザイン上まずかったり、「広告が出ていなかったので削除させていただきました」なんて、笑えない。
引用：
ファイルのｉノードを直接指定できないですから、確かに処理は早くはならない、処理は同等でもありえない・・・・処理は遅くなる方向にあります。それでもシンボリックリンクにはメリットは高いと思います。物理マウントに影響しない、影響があっては困るシステムファイルはシンボリックリンクしか利用できない。システム管理者からすると、mount --bind で、あるフォルダーをフォルダーにマウントするなんてことを平気で行っていたりします。XOOPSアプリケーションのシンボリックリンクファイル利用で処理のロードが悪化することで罪を被るとしたら・・・・ mount --bind で処理が遅くなるようなシステム管理者は、大罪で処刑ものですね。反省！
引用：
ありがとうございます。励みにします。
adekatさんは書きました：
私自身は複数作る要望がないので、単にページを見た感想ですが。
安定していて、事故に遭遇しない環境って立派ですね。
って言うか、故障の無いコンピューターって皆無ですから、保全メンテナンスがきっちりしたサーバーをご利用のことかと存じ上げます。サーバー管理者が立派なポリシーを持っておられて、出費を惜しまず先手で保全用投資を続ける・・・・
もしも、何らかの原因でXOOPS領域が壊れたり、MySQL領域が壊れたり・・・XOOPS管理者である自分のミスで無くしたり、そんなことを当方では起こしてしまう可能性が大ですので、即時代替えできるサブXOOPSって必須な感じです。これってなさけないですね。
また、α版だったり、β版だったりの、新しいモジュールなどの利用実検にも、クローンXOOPSである裏XOOPSを立ち上げておいて、MySQLデーターもコピーした環境て実検を積極的に行います。そんな時に、クローンXOOPSって便利ですよ。「あちゃ〜、使えない」場合は、MySQLデーターを上書きしちゃう。
領域が有限で押さえ込まれている Free Web Hosting で可能な限り絞り込んだ占有って、複数のXOOPS稼動には、クローンXOOPSを増やす方法しかありませんね。
「XOOPSを利用しているけど、MySQLデーターのバックアップってしたことない」って言う人口が多くはないのかが最も心配です。「MySQLデーターのバックアップは行っているけど、復元させた経験がない」と言う人口も多くないでしょうか。
自分が100%作成した著作物が消失したなら仕方がない。でもXOOPSのように自分以外のユーザーの汗水でデーターが構築されますから、MySQLの保全と復元には慣れて欲しいと願います。
クローンXOOPSを作成する時には、自然と、MySQLのバックアップ(ダンプ)と、MySQLの復元を繰り返したりしますので、「いざ鎌倉」においても、MySQLの復旧は手馴れたものになるはずです。:boke:
引用：
adekatさんは書きました：
・異なるユーザで使うにはカスタマイズの制限を受けるのでリンク先ディレクトリがかなり限定されそう。
まあ、XOOPSの中身は知りたくないけど、XOOPSの管理者となって自営したい方には便利な一面もありますが、XOOPSを熟知しており、自分専用のXOOPSを構築している、構築したい人にとっては、無用なことのようです。
引用：
adekatさんは書きました：
・個人で使う分には保守が楽そう。でも、themes/は別々が普通かな？
themes も考え様によっては、サイト毎にチューニングが必要だったりしませんか？ 特に Free Web Hosting を利用する場合は、広告位置を themes 内で特別に調整しますよね。上書きしてしまったり、XOOPS標準で利用しては、デザイン上まずかったり、「広告が出ていなかったので削除させていただきました」なんて、笑えない。
引用：
adekatさんは書きました：
・クローンが増えた場合、パフォーマンスは大丈夫なんだろうか？
ファイルのｉノードを直接指定できないですから、確かに処理は早くはならない、処理は同等でもありえない・・・・処理は遅くなる方向にあります。それでもシンボリックリンクにはメリットは高いと思います。物理マウントに影響しない、影響があっては困るシステムファイルはシンボリックリンクしか利用できない。システム管理者からすると、mount --bind で、あるフォルダーをフォルダーにマウントするなんてことを平気で行っていたりします。XOOPSアプリケーションのシンボリックリンクファイル利用で処理のロードが悪化することで罪を被るとしたら・・・・ mount --bind で処理が遅くなるようなシステム管理者は、大罪で処刑ものですね。反省！
引用：
adekatさんは書きました：
ブログの件といい、この件といい面白い実験をされていますね。
ありがとうございます。励みにします。
Re: XOOPS専用シンボリックリンクファイル生成・自動削除ツール
投稿者: Ujiki | 投稿日時: 2006-9-15 15:25
引用：
各モジュールの「 header.php 」なのですが、以下の文法ならシンボリック呼び出しによるモジュールの一元管理って可能にならないでしょうか？
dirnameを３度も呼び出しています。う〜む。どなたかアカデミックな構文を、どうぞ。(^^);
- Ujiki.oO -
自己レスです。済みません：
modules なのですが、シンボリック下でも、正常に稼動できるような仕様、つまり mainfile.php に完全準拠するような、コア、モジュール開発の御願いを、いまさらお願いするのも気が随分とひけてしまうのですが・・・・・如何なものでしょうね。
各モジュールの「 header.php 」なのですが、以下の文法ならシンボリック呼び出しによるモジュールの一元管理って可能にならないでしょうか？
<?php
$MAINFILEphp = dirname(dirname(dirname( $_SERVER["DOCUMENT_ROOT"] . $_SERVER["REQUEST_URI"] ))) . "/mainfile.php" ;
if(is_file($MAINFILEphp)) require($MAINFILEphp);
else require('../../mainfile.php');
unset($MAINFILEphp);
?>dirnameを３度も呼び出しています。う〜む。どなたかアカデミックな構文を、どうぞ。(^^);
- Ujiki.oO -