というわけでファイル所有者の件で、少しまとめておく。

php から普通にファイルをつくると所有者は apache になるようだ。

ファイルをつくった時 chown() すればいいのかなと思い php マニュアルをみたら:

>スーパーユーザのみがファイルの所有者を変更できます。

と書いてあるので、レンタルサーバーなどで運用している場合使えない。しかし apache 所有だと FTP クライアントから消したりできんので非常にうっとおしいのも事実だ。

ぐぐってみると、「 CGI 版 php を使う」「php の ftp関数を使う」という逃げ方があるという話だけ見つかった。(意外にも、同じ問題で困っている人の質問は見つかったが、ずばり解決な情報は見つからなかった。)

ここで、この問題がなぜ起こるのかを考えてみた。要は「 php で作ったファイルやディレクトリが ftpクライアントからいじれない。」というわけだ。その理由は「 php の fopen() で新規にファイルをつくるとき、その所有者を指定して開くことができない。」ことと、「作成したファイルの所有者を変更する関数 chown() はスーパーユーザー(簡単に言うとルート権限をもつユーザー。)しか使用不可能という仕様。」だからだ。

一言で言うと、いきなりでなんだが「八方塞がり」だ。(笑)

だが、もし php から作るときにも ftp 経由で普段のユーザーとしてログインし「ファイルをつくる」ことができれば、問題はなさそうだ。

もしかしたら php の ftp関数を使うことで ftp 転送したときと同じ所有者にできるかも知れない。(ファイル転送ではなく、新規作成ができなければ実現できないが…普通 FTP といえばファイルを get/put するための仕組みだろうから、もしかしたら、いきなりでなんだが新規作成などということは無理かも知れない。(^^;)

また、画像ファイルなどをアップロードする XML-RPC API newMediaObject() の仕様として「転送先ディレクトリが存在しなければその場で作る。」というのがある。 php の ftp関数でディレクトリが新規に作れるかどうかは知らない。

というわけで、 FTP 転送時と同じ所有者でファイルとディレクトリを作るようにしたいところだが、とりあえずは apache 所有者で作られても ftp で手でファイルを消したりしようとしない限り普通に使えるし、よい解決方法がみつかるまではこれでいいかと。

しかし…「ファイルを1つつくる」などという基本的なことでけっこう頭を抱えなければならないんですなぁ。(苦笑)

php のマニュアルで ftp 関数を調べてみた。

>ftp_mkdir -- ディレクトリを作成する

ディレクトリの作成はできそうだ。

>ftp_fput --  オープン中のファイルをFTPサーバーにアップロードする

ファイルの新規作成については、こんなのがあった。ファイルポインタで指定して、ファイルの終端までをアップロードするそうだ。

この関数は、既存のファイルを開いて取得したファイルストリームを受け取って、ファイルストリームの末尾までを一気にリモートにアップロードする仕様らしい。

XML-RPC API 側でファイルを作成するときに、メモリストリームをつくり、受け取った記事内容をストリームから一定量ずつ流し込むなり fwrite 系の一定量ずつメモリブロックを読み書きするなりできるような関数があれば、今回やりたいことを実現できるのだが、上の関数では、一気に最後まで書き込んでファイルをつくる仕様なので無理だ。 php にはメモリストリームをあつかうためのクラスもないようだ。

困った…。

  1. FTP 転送自体を php でフルスクラッチする。
  2. php 以外のサーバーサイドスクリプトをつかう。
  3. 一旦 apache 所有のファイルを新規作成し、しかる後に、そのファイルから ftp_fput する。

1. は大変すぎだしプラットフォームによっては動かないようなものしかつくれそうにない。

2. は rn_xmlrpc.php の API との連携が大変。

3. なら実現できるだろうが…。無駄が多くてバカバカしいんだがなぁ。(いったん apache 所有でつくって、put して消すので、処理中のディスクサイズがファイルサイズの2倍必要になる。記事ならそれほど問題にならないだろうし newMediaObject で転送するファイルも過去の実測でいうと 1.5MB 程度までしか転送できなかったので、運用上いいっちゅやいいんだが…。(^^;)

理想的には、ファイルの転送をシミュレートするような ftp_fwrite , ftp_fread, ftp_fseek みたいなものがあればそれがズバリなのだが…

[コメントの受付は終了しています ]
1: (12/26 06:57)
似たような問題で困ったことがあります。
その時は新規作成するファイルが有限だったので、対象となるファイルを事前にFTPでアップロードしておき、CGIではそのファイルを書き換えるようにしていました。
有限でない場合で、FTPでファイルをアップロードできるのであれば、サーバー上にダミーファイルを置いておき、そのダミーファイルを開いてそのファイルハンドルを渡してFTPで上げると言うのはどうでしょうか?
試してはいませんが、phpのマニュアルを見た限りでは出来そうな気がします。
2: 冬星 (12/26 14:41)
こんにちは。吉里吉里の方ではお世話になってます。
おお、実現できそうですか?
おっしゃっている「ダミーファイルのファイルハンドルを渡して」というのは ftp_fput() にですよね。
soruce 側の fp に、ダミーファイルを開いてその fp を渡すということでしょうか。
そのあと、メモリ内に string としてもっている記事本文の情報を書き込む必要がありますがその部分の方法がわからんです。(^-^;
3: (12/26 17:21)
こんにちは、こちらこそお世話になってます。

次のような感じでどうですか?
私のところで試したところ、うまく行きました。
書き込み後は、またFTPでつないでパーミッション変えたほうがいいかもしれません。
chmodが使えるのなら、FTP使わずに出来るのですが、禁止されているかと。
ただ、この方法だとFTPのパスワードが入ってしまうので、その辺りはちょっと注意した方が良さそうですね。

ダミーファイルに書き込んでから、それをコピーすると言う手もありかもしれません。
その場合はパーミッションをいじらなくてすみそうです。
4: (12/26 17:21)
<?php
$path = "/your/site/full/path/"; // ダミーを置いておくディレクトリ、今回は作りたいファイルもここに置く
$templatefile = "template.txt"; // 初めに上げておくダミーファイル名
$writefile = "target.txt"; // 新たに作りたいファイル名

$FTP_HOST ="ftp.yourhost.co.jp";
$FTP_USER ="yourname";
$FTP_PW ="yourpw";
$FTP_ROOT_DIR="/";
$FTP_DIR = "targetdir/";
$is_copy_success = false;
5: (12/26 17:21)
$conn_id = ftp_connect($FTP_HOST);
if( ftp_login($conn_id, $FTP_USER, $FTP_PW) ){
  print "success FTP login<br>\n";
  ftp_pwd($conn_id);
  ftp_chdir($conn_id,$FTP_DIR);
  $filename = $path . $templatefile;
  if( $fp = fopen($filename, 'rb') ) {
    if( ftp_fput( $conn_id, $writefile, $fp, FTP_ASCII ) ) {
      print "success copy file.<br>\n";
      $chmod_cmd="CHMOD 0666 ".$writefile; // ftp_chmodは通らなかったのでこれで
      if( ftp_site($conn_id, $chmod_cmd) ) {
        print "success chmod.<br>\n";
        $is_copy_success = true;
      }
    }
    fclose($fp);
  }
  ftp_quit($conn_id);
}
6: (12/26 17:21)
$write_data = "書き込みたい内容が入った変数";
if( $is_copy_success ) {
  $filename = $path . $writefile;
  if( file_exists($filename) ) {
    if( $handle = fopen($filename, 'wb') ) {
      if( fwrite($handle, $write_data ) ) {
        print "Success write file.<br>\n";
      }
      fclose($handle);
    }
  }
}
?>
7: 冬星 (12/26 20:18)
詳しい解説ありがとうございます。>楓さん
理解しました。
所望の所有者で作っておいた空ファイルの複製をFTPでつくり、開いて書き込むことで所有権を維持、ですね。
うまいやり方ですね。ちと取り入れてみます。(^^
8: 冬星 (12/26 20:54)
FTP アカウントでファイル/ディレクトリ作成することもできるように修正してみました。
うまくいきましたよ~。>楓さん。
9: (12/28 16:29)
こんにちは。
うまく行きましたかー
それは良かったです。
この記事のリンク元 | 4 | 1 |

秋に思い立ってつくり、テスト(放置)していたが、公開しておこうと思う。

仕様検討が完了していないのだが、とりあえず忙しいことと、クリスマスシーズンなのにひとさまに何も贈るものがないというのが理由だ。

rn_xmlrpc-1.0.0.0.zip

ちなみに、これは何をするものかと言えば:

ブログへの記事の書き込みに、XML-RPC 投稿 API に対応した投稿クライアントが使えるようになる。
BlogPet が記事を投稿してくれるようになる。
といったものだ。(ちなみに自分自身の原初の制作動機としては後者だったのだが、使っているうちにそちらはわりとどうでもよくなり、日々の記事の投稿をクライアントソフトから行うことの便利さの方が重要になってしまった。(^-^;)

これの制作過程では Rinn さんにいろいろご助言、仕様案などいただいた。ありがたく。m(__)m

ということで、全国の BlogPet を rNote につけたい皆様と、ブログ投稿クライアントを愛する皆様に。


念のため…サーバー側に設置します。 php で書いてあります。 PEAR の XML-RPC パッケージが必要です。必要なファイルの配置例は INSTALL.TXT に簡単に書いてありますのでそれを参考に。

ID の扱いについて。XML-RPC 投稿API では記事を、記事ごとに一意な ID で管理します。いろいろ考えたのですが、 rNote では xml ファイルとして記事を書くので、ファイル名を ID にしています。形式は以下のとおり。

記事ファイル… YYYYMMDD_hhmmss.xml 。'YYYYMMDD_hhmmss' の部分(主ファイル名)がID。
カテゴリー指定用の一時ファイル…YYYYMMDD_hhmmss.category 。'YYYYMMDD_hhmmss' の部分(主ファイル名)がID。
要は、年月日時分秒を文字列にしたものをIDに使っています。このあたりの経緯はここの過去記事を参照してくださるとだいたいわかるかと思います。

xml 手書きでも投稿するよ、という場合、「この形式にならない」ように、また、「手書きの記事同士もまったく同名のファイル名を複数投稿しない」ようにすれば、問題は起きないはずです。

バグなど見つけたら(なおしたら)、あるいは仕様を改良されたら、ぜひ教えて下さい。助かります。(笑)

…と、いってるしりからファイル不備がみつかったので 1.0.0.1 1.0.0.2 (笑)にさしかえました。

(12/27追記)

作成されるファイル/ディレクトリ の所有者を FTP ユーザーと同じにすることのできる 1.1.0.0 に差し替えました。 (方法ありがとうございます。>楓さん。)

FTP アカウント情報を rnote_config.php に追加しますので、セキュリティ対策をよく考えてください。不安な場合、これまでと同じ apache 所有になる形でも使えます。デフォルトはこれまでの apache 所有の方です。 FTP アカウントでの作成方式に変更する方法は INSTALL.TXT をみてください。

動作確認用に WriteLog() を何箇所か入れてあります。うまく動作しない場合ログファイルを開いて確認してみてください。(=デバッグしてみてください。(^-^;)

(12/30追記)

FTP アカウント所有権に対応させた場合に、画像付きの投稿で画像のサイズが 0 バイトになっていたのを修正した 1.1.1.0 にさしかえました。

(2006/1/1追記)

moblog.uva.ne.jp を使った投稿に出来る範囲で対応した 1.1.2.0 にさしかえた。対応内容は別途記事を書いておく。

(2006/1/2追記)

1.1.2.1 で moblog.uva.ne.jp に完全に対応させた。改行処理の問題にも対応した。詳しくは別途記事にて。

(2006/1/4追記)

1.1.2.3 にさしかえた。改行処理のバグ修正1件と、機能追加が2件。

rn_xmlrpc-1.1.2.3.zip
[コメントの受付は終了しています ]
1: 霧島 夕 (12/25 11:38)
こんにちは。お久しぶりです:-)

設定している最中に気づいたんですが、
// 汎用httpアクセス関数
の後のコメントアウトが抜けていたのでエラー出ました(笑)

一応報告です。
2: 通りすがり (12/25 02:48) (01/01 09:00)
うわぁ…ホントですね。OTZ
ありがとうございます。
あとは…よその環境で動くのかが気になるところです。ファイルの所有権とかとくに設定してないので記事や画像などの投稿が無事にいけるかどうか興味津々。(^o^;
3: 冬星 (12/25 11:48)
通りすがりになって書いてしまった…。orz
4: 霧島 夕 (12/25 11:56)
ファイル名はともかく、私の場合Diary/2005というディレクトリで
書いてるもので現在rnote_configを修正中です(^_^;
あと、画像のアップロードですね。
rootからimage/カテゴリ/2005/***.jpgを使ってるので、このあたりも
どうなるか検証します~。
5: 霧島 夕 (12/26 04:12)
お仕事お疲れ様です。
本サーバではまだ行ってませんが、自宅のIIS+phpで投稿および画像アップロード確認しました。
IISで動いたのであれば、よほどのことが無い限りUNIX側で動作しないとは思えないかと:-)

あと、問題の画像アップロード先ですが、これは一カ所のみですね(^_^;
まぁ、投稿ツール側の問題ですが(笑)
とりあえず私の環境では動作に問題ないと考えます:-)

便利なAPIを作って頂きありがとうございましたm(_ _)m
6: 冬星 (12/26 09:38)
いやー、こちらこそチェックありがとうございます。動作してよかったです。
投稿クライアント使うとけっこう便利さを感じちゃいますよ。一番多く対応されているのは WYSIWYG エディタ方式ですが、タグ打ちこみ派にも対応しているものもあるようです。
7: 霧島 夕 (12/26 10:18)
本サーバで動作OKでした:-)
たまにPOSTエラーを起こしたりすることはありますが、きっとこれは契約している
サーバのレスポンス問題と考えてます(笑)

投稿クライアントは通常エンターを押すと<p>になってしまうのは、慣れが必要ですね(^_^;
8: のり (12/28 02:22)
とりあえず、ローカルで試してみました。汎用の書き込みツールが使えるようになるというのは、かなり面白いですね。
ところで、現状では rn_xmlrpc.php に xml の雛形が埋めてありますが、これは外部に出して頂けるとうれしいですね。
まぁ、直接いじればいいんでしょうが。
次期バージョンがあるようであれば、御検討のほどよろしくお願いします。
9: 冬星 (12/28 05:58)
createPost() で記事を作っているところでしょうか。
まぁあんまりかっこうよくはないかも知れませんね~。外部に出すと、記事の内容を作成するために読み込んできて置き換えて…という処理をどうするかで手がかかるので直書きしてます。
うまい方法があれば試してみてください。
10: Kaz@sleeper (01/03 01:34)
明けましておめでとうございました
え~無事にMoblogできました!
嬉しいお年玉ですねぇ
#1.1.2.0のrn_xmlrpc.phpのFOPEN_USE_FTPがfalseじゃなかったからってのはナイショですw
11: 冬星 (01/03 10:43)
使えてよかったですね。
使って何か気づいた点がでてきたら、レポートいただけると幸いです。

memo: xhtml 2005-11-19 (土) 03:34:00+09:00

ソフトウェア

Webページを記述するためによく使われるHTMLを、XMLに適合するよう定義し直したマークアップ言語。W3Cが仕様策定。

HTMLはXMLとは一部整合性を欠く言語仕様となっているが、両者の違いはある程度吸収できる範囲のものであるため、従来のwwwブラウザでも問題なく見られ、かつXMLに準拠した文書を作成する言語仕様としてXHTMLが作成された。

最初のW3C勧告となったXHTML 1.0はHTML 4.01が元。HTML 4.01に対応したWebブラウザでほぼ完全な形でページを見られる。

現在の最新版はXHTML 1.1で、文書見栄えを指定するタグが廃止(見栄えの記述は全てCSSで行なう)など、文書構造の記述に特化した言語へと変化しつつある状況。

XHTMLの各バージョンに共通したHTMLとの違い:

タグ名がすべて小文字に統一。
XMLベースの他の言語(MathMLやSVGなどが想定されている)による記述を埋め込むことができる。
終了タグをもたず単独で使用される
などのタグを
ないし
と書く。
e-wordsのXHTMLの項から抜粋。


The Web Standards Project の記事 MSIE7 Will Not Support application/xml+xhtml MIME Type によると:

IE7 の開発チームは、IE7 では xhtml への対応は実装しないということらしい。

来るべき未来の IE7 でも xhtml 形式での表示にきちんと対応できないとなると、投稿クライアントとしてもきちんと対応することはできない。(なにしろ、最終的にそれを表示するブラウザが対応していないんだからね。)

現状でできることといえばエディタに IE の WebBrowser コンポーネントを使用してやって、表示の「出来具合」を合わせて「IE自身の仕様です」とする。これぐらいか。

あるいは、Firefox あたりが編集モードももったブラウザコントロールを配布してくれればありがたいんだが、ないんだろうか。htmlメールも作れるメールクライアントへの組み込みなど需要は高いと思うんだが、知っている限りは、スタンドアローンな WYSIWYG 編集アプリケーションとして Nvu があるぐらいか。

というかよく知らないんだが、Firefox や Mozilla は xhtml のどのバージョンにどの程度対応済みなんだろう?



Firefox というより Mozilla のブラウザコントロールがあるようだ。

それのActive-X ラッパーがあるそうなので Mozilla ActiveX Project からMozillaControlの1.7.7 というものを手に入れてインストールしてみたが、開発環境にコンポーネントとして認識されなかった。あらまぁ。


はるかなる空へ 想いは飛び往く。
奥深い闇を 想いは射抜く。

その先にあるものを。
その先に拓ける未来を。
俺たちはどうしても 手に入れなければならないのだから。

夜風がカーブを増すたび、草の葉のこすれる微かな音がする。
闇に包まれ、些細な音に抱かれ、それらに包まれているようなやすらぎを感じる。
頭の上では二十五層におり重なった市街の赤い灯が、流された灯篭の群れのように遠く揺らめく。

一つ一つの灯篭の中では今も騒がしい日常が再生されているだろう。

その喧騒も聞こえては来ない。ここはまるで、音の無い死後の世界のようだ。

静かに眠るオンディーナの街。その最下層に広がるグランド層。真夜中の今、周囲には誰の姿もない。 ただ生ぬるい夜風がそこにあるものを撫ぜる昏い森。

次郎は、一人になりたかったのだ。

・・・オンディーナの子は、インバースと戦う。

生まれたときから決められた運命だ。なのに俺はその運命すらも勝ちとることができなかった。

母なるオンディーナ。二十五層の市街を包むドームを七つもつ、「この世界」で最も大きい州国家を擁する、偉大なる人工星。
その母の体はひどく疲弊していた。長く続くインバースの襲撃、循環資源の効率低下、反物質との反応による「この世界」の衰え…。
すべてが、遠くない世界の死を示していた。

暗雲に閉ざされていく運命に抗い、母なるオンディーナと「この世界」の寿命を少しでも永らえるため、オンディーナの子は、どこからともなく襲いくる航宙兵器「インバース」どもと戦うのだ。

頼みの綱は「チェイサー」と呼ばれる職業に就く者。クルーズチェイサー(航宙遊撃機)と呼ばれる航宙兵器に乗り込み、「この世界」を縦横無尽に疾駆し、インバースどもを狩る騎士のことだ。

だが、チェイサーになるには資格が必要だ。18歳になり成人し、難易度の高い筆記・実技試験に合格した、心身ともに健康で適性を満たした僅かな男女だけがクルーズチェイサーに乗れるのだ。零れ落ちた多くの者は、ラボ(航宙兵器開発所)や工場で労働者として働いたり商業を営んだり、市街で暮らす市民となる。

チェイサーには、倒した「インバース」の格(ランク)や機数に応じた賞金が与えられる。統制された軍隊というより賞金稼ぎであり、チームを組んで戦うのを好む者もいればソロで大物を狙う者もいる。いつの頃からか、そのような仕組みがつくられた。なぜそのようなシステムになったのかを一言で言えば、その方が「戦果が上がった」からだ。

そのようなわけで、「チェイサーになる」ということは、「一攫千金を狙う」こととほぼ同義だったが、次郎は賞金を稼ぐことには興味がなかった。鼻たれ小僧の頃から、ただチェイサーというものに憬れていた。必ずなるんだと信じてた。信じて、同じ道を目指す若者たちとともに己を磨いてきた。

そのなかに、なぜか強く惹きつけられる少女がいた。何がそんなに自分を惹きつけるのか、どうしてもわからないまま、想い続けた。強いて言うなら、彼女は何か得体の知れない「輝き」をもっていた。他の奴にも、そう感じられたかどうかは知らないが…。

少女は次郎とは正反対で、はっきりとした物言いをし、それはときには辛辣すぎるきらいもあったが、チェイサーという目標に向かうひたむきな姿勢と、困難に対しても一歩も退かない負けん気と、実際にそれを乗り越えてしまう機転の早さが、彼女を輝かせていた。・・・そう想う。

どんくさい自分を、笑いながらなぜか認めてくれた彼女と、「一緒にチェイサーになろう」、と約束したあの日。

そして試験を受け、自分だけが落ちた。落ち続けた。

思考能力にはさほど問題はなく、いやむしろ十分だったのだが、それを発揮する際の反応速度が問題だった。チェイサーとして必要とされる閾値を、どうしても超えることができなかった。

次郎は焦った。自分だけを残しチェイサーの門をくぐり離れていった同期達の姿が、浮かんでは消える。実際は、チェイサーになれなかったところで、働く場所はなくはなさそうだったが、どうしてもそれらを「現実の選択肢」として歩み寄ることが次郎にはできなかった。

「俺にはこれ(チェイサー)しかない。これだけを目指してやってきたし、他にできることもないのに…。」

流砂に半分飲まれてもう後戻りなどできないところまで来てしまったのに、その先に自分の通れる穴はない…。そんな不安と失意がない混ぜになったような感覚が次郎を襲った。

それに、手の届かないところに行ってしまった少女の、その後の様子も気になった。自分のものでもないのだが、他の男に奪われはしないかと、眠れなかった。

・・・恐れることは現実になる。

そうこうしている間に、彼女に彼氏ができた…という噂が流れてきた。相手は「クロス」というチェイサーだった。反応速度、戦闘のセンス共に破格の有望株の新人チェイサー。十二番街を彷徨っているとき、雑踏の中で抱き合う二人をみつけてしまった瞬間の胸の痛み……ナイフで切り開かれたというより、心臓を鋭い錐で貫かれた痛み。

痛くて、痛くて、痛くて。

重くて、重くて、脚が重くて。途方も無く重すぎて。

気がついたら、次郎は最下層の草原を歩いていた。

「俺にはもう何もない。」

言ってみると、自分の声が、もう他人ごとのように聞こえた。しかし、他の誰でもない。己のことなのだ。

「そうだ。俺のことなんだ。おれは…役立たずの廃棄物だ。だけど、それでも、俺だって、オンディーナの子なんだ。」

しゃがみこんで、健やかに伸びた芝草を両手でつかみ、次の瞬間…無残に牽きむしられる草の姿が思い浮び、手首に走った衝動はすぐに萎えた。小さなため息が一つ漏れた。

丸めた背中で空虚な胸を守るように。握ったこぶしで何もない未来を掴むように。

音のない海の底、灯篭の群れを仰ぎながら、闇に抱かれ次郎は眠った。

明日という日を、まだ生きるために。

(ver.1.02)

[履歴]

ver.1.02(第3版) 2022-4-22
ver.1.01(第2版) 日付不明
ver.1.00(初版) 2005-9-25

ブログを書くならBlogWrite




本編は、スクウェア(現スクウェア・エニックス)発売の「クルーズチェイサー BLASSTY」というソフトウェアをもとにした二次創作です。

発売されたのは、1986年ごろだったようです。かれこれ20年前になりますか。ジャンル的には、SF RPG ということになるんでしょうか。ロボットのデザインを日本サイライズがしていたり、ロボット同士の戦闘シーンがアニメーション表示されたりで、当時話題になった作品の一つでした。

自分にとっては色々な面で印象に残ったのがそのドラマ性でした。当時のスクウェアって、アドベンチャーでもRPGでも少し哀愁のあるドラマ仕立てのSF路線だったんです。そのあたりが自分の個性と一致したというか…。そのへん後のFFシリーズでもFF7が一番好きだったあたり、自分の中ではずっと変わってないようです。(「アドベントチルドレン」まだ観れてません。手に入る日を楽しみにしつつ…。)

「BLASSTY」では、主人公がオンディーナ側につくか、インバース側につくかで、2通りのエンディングがあったのも好印象でした。

今回のお話では、どっちにしようか、今はまだ考えながら書いています。(と、いいつつ、大筋はもう全部できあがっているんですけども。)元作品を知らない人のために、イラストや解説を入れながら進行していけたらなぁ…と思ってます。

稚拙な二次創作物ですが、どうぞよろしくお願いします。

(2005-9-25)

---

本体末尾にバージョンを付記しました。

(2005-9-25)