にしし ふぁくとりー:西村文宏 個人サイト

てがろぐ セットアップ(設置)方法

お手軽マイクロブログCGI「てがろぐ」のセットアップ方法です。お使いのサーバに設置する手順を解説しています。
手順と言っても基本は全ファイルをアップロードして、パーミッションを設定するだけです。簡単です。本当に簡単です。説明が長いのは、念のための補足説明が多いだけで、必須の手順はわずか3ステップです。

《最終更新: 2022年09月21日 》

CGIの動作要件

動作要件はとても緩いので、たいていのウェブサーバでは何も気にせず8ファイルをアップロードするだけで使える場合も多そうな気がします。
Perl5さえ使えればたいてい動作します。データベースは不要です。

CGIの設置環境(動作要件)

  • てがろぐCGIは Perl で記述しています。動作には、Perl 5 が必要です。(Perl 5.6以上)
  • CGIモジュールと、Time::Localモジュールがインストールされていることが必須ですが、CGIが使用可能なサーバならたいてい入っているので問題ありません。(もしそれらのモジュールがサーバにインストールされていない場合でも、CGIモジュールTime::Localモジュールを別途入手し、このCGIと同じディレクトリに置いた上で、読み込むよう設定すれば使えます。)
  • それ以外には、特に必要なものはありません。(データベースは使いません。

動作サーバの例

  • さくらインターネットのライトプラン(※最も安いプラン)でも動作します。
  • ロリポップ!のエコノミープラン(※最も安いプラン)でも動作します。
  • プロバイダ提供スペースや、無料サーバでも、CGI(Perl5)の動作が可能ならたいていは問題ない気がします。
  • そのほか、「CGIの設置が可能」と謳っているサーバなら、たいていどこでも動作するでしょう。

当サイトは、「さくらインターネット」のサーバ上で公開されています。 てがろぐCGIの動作テストも、さくらインターネットのサーバで実施しています。さくらインターネットをお使いなら、何も書き換えることなくそのままアップロードしてパーミッションを正しく設定すれば動きます。

CGIの設置方法

CGIの簡単セットアップ手順

てがろぐのセットアップ方法は、ダウンロードしたZIPファイル(※ダウンロードはてがろぐ公式TOPページから)を展開して、出てきたファイルをWebサーバの任意の場所にアップロードして、下表に記したパーミッション(アクセス権/属性)に設定するだけです。 ただし、サーバによっては、てがろぐCGI本体(tegalog.cgi)の1行目を、サーバ側が要求するように事前に書き換えておく必要があります。

したがって、セットアップ手順は下記の3ステップだけです。

  1. 必要に応じて tegalog.cgi 内の1行目を書き換える。(※書き換える必要がない場合も多くあります。)
  2. 全ファイルを同一のディレクトリ下にアップロードする。
  3. パーミッション(属性値)を指定通りに設定する。

これだけで動作します。

設置手順1:CGIファイル1行目を(必要に応じて)書き換える

最近のウェブサーバなら、おそらく特に何も書き換えずにそのままアップロードするだけで動くことが多いです。

なので、まずは何も書き換えずに「設置手順2」へ進んで下さい。

もし、最終的に(設置手順3の後で)「500 Internal Server Error」が出るようなら、 CGIソースの1行目にある #! /usr/bin/env perl の記述を、例えば #! /usr/bin/perl#! /usr/local/bin/perl などに書き換える必要があります。 その場合は、tegalog.cgi をテキストエディタで開いて、1行目をサーバ会社が指定する通りに書き換えて下さい。

tegalog.cgiソースの1行目を書き換える

例えば、

  • 「さくらインターネット」のサーバなら書き換え不要ですから、このステップは飛ばせます。
  • 「ロリポップ!」のサーバでも書き換え不要ですから、このステップは飛ばせます。
  • そのほか、「XREA」でも書き換え不要だと報告を受けています。たぶん、書き換え不要なサーバはもっとたくさんあります。

テキストエディタには、EmEditorをお勧めしています。てがろぐCGIの開発にもEmEditorを使っています。(EmEditorは、無料版として使うこともできます。)
※てがろぐVer.3以降のファイルは、Windows7以下の「メモ帳」では編集できませんのでご注意下さい。(改行コード[LF]が改行として認識されないため。) Windows10以降なら「メモ帳」でも大丈夫ですが。

設置方法2:ウェブサーバへのファイルのアップロード方法

説明用の「README.TXT」ファイルを除くすべてのファイルを任意のディレクトリにアップロードして下さい。
その際、FTPソフトの設定は「アスキーモード」(テキストモード)にする方が無難です。

設置後のディレクトリ構造は下図のようになります。
自由に作成したサーバ上のディレクトリへ、必要なファイルをアップロードすれば良いだけです。サブフォルダも含めてアップロードする場合は、フォルダ構造(階層構造)を維持したままアップロードして下さい。 考えるのが面倒なら、とりあえず全部アップロードすれば良いです。(笑)

CGI設置後のディレクトリ構造例

図の左側は最小限のファイルだけで使う場合のディレクトリ構造、中央は最小限のファイルだけで使う場合の推奨形態、右側は完全版の全ファイルをUPする場合のディレクトリ構造です。 (※backupサブディレクトリはデータの自動バックアップのために必要で、imagesサブディレクトリは画像を投稿できるようにするために必要です。なので、この2ディレクトリだけは最小構成で使う場合でもある方が望ましいです。)

※FTPソフトでアップロードする際に、転送モードが「バイナリモード」になっていると、CGIソース内の改行コードが正しく変換されないために、ブラウザでは「500 Internal Server Error」が表示される場合があります。 その場合は、FTPソフトの設定を確認してみて下さい。

※FTPソフトを使わずに、Webサーバのコントロールパネルからファイルをアップロードすると、バイナリモードでアップロードすることになってしまい、うまく動作しないことがあります。 その場合は、FFFTPなどのFTPソフトを使ってアップロードして見て下さい。 (どうしてもそのようなソフトウェアが利用できない場合は、一旦 tegalog.cgi と fumycts.pl をテキストエディタで読み込み、改行コードをお使いのWebサーバに合わせて変更した上で上書き保存し、アップロードして下さい。)

設置方法3:パーミッションの設定

アップロードしたファイルのパーミッション(アクセス権/属性)を下表のように設定して下さい。

※特に、さくらインターネット、ロリポップ、Xserver、XREA、usamimi.info、fya.jp等に設置する場合は「suEXEC」側のパーミッションに設定して下さい。 お使いのウェブサーバで「suEXEC」という安全な仕組みが有効になっている場合は「suEXEC」側の値を設定しないと動かない可能性があります。(特にディレクトリの設定は絶対ですので気をつけて下さい。)

ファイル名パーミッション
一般の場合 / suEXEC
補足
▼プログラムファイル
tegalog.cgi 755700メインCGI (これを実行します) ※0
fumycts.pl 644600補助プログラム (メインCGIから呼び出されます)
▼データファイル(CGIによって書き換えられるファイル)
tegalog.xml 666604投稿データ記録用ファイル(CGIによって編集されます) ※1,2
tegalog.ini 666604設定記録用ファイル(CGIによって編集されます) ※1,3
psif.cgi 666600パスワード・セッションID格納ファイル(CGIによって編集されます) ※1,4
▼表示HTML関連ファイル
skin-cover.html 644604表示用スキンファイル(テンプレートHTMLファイル:外側用) ※1
skin-onelog.html644604表示用スキンファイル(テンプレートHTMLファイル:内側用) ※1
tegalog.css 644604表示用スタイルシートファイル ※1,5
▼サブディレクトリ(※設置は任意)
backup 766705自動バックアップファイルが蓄積されるディレクトリ ※6
images 766705投稿画像ファイルが蓄積されるディレクトリ ※6
skin-* 755705別スキンは「1スキン1サブディレクトリ」で置けます。 ※7

※0:ファイル名を「index.cgi」に変更しても動作可能ですが、それよりは『ファイル名「tegalog.cgi」を省略してアクセス可能にする方法』の採用がお勧めです。
※1:ファイル名は自由に変更可能です。(ファイル名の変更内容は tegalog.cgi 内に反映させる必要があります。よく分からない場合はデフォルトのままご使用下さい。)
※2:ファイル拡張子は.xml以外に変更しても構いません。(記録形式はXMLです。)
※3:ファイル拡張子は.ini以外に変更しても構いません。(記録形式はINIベースの独自仕様です。)
※4:ファイル拡張子は.cgi以外でも構いませんが、外部から閲覧されるのを防ぐために「.cgi」にしてあります。他の拡張子に変更する場合は、.htaccessファイルなどを使って中身が閲覧されないように設定して下さい。ログイン用のパスワードを忘れてしまった場合は、このファイルの中身を空っぽにして再度アップロードすると、無条件ログインが可能になります。
※5:ファイル拡張子は.cssでなければなりません。ファイル名は、skin-cover.htmlのlink要素に書かれているファイル名に合わせる必要があります(スキンによっては tegalog.css ではない場合もあります)。
※6:このディレクトリには「書き込み権限」の付与が必須です。しかし、サーバでsuEXECが使われている場合は、705等の一般的な値のままで正しく動作します。その場合は、766などに設定すると(主に画像表示の面で)正しく動作しなくなります
※7:ディレクトリ名は何でも構いません。必ずしも「skin-」で始まっている必要はありません。

ウェブサーバによっては、上記の「755」や「644」などのパーミッション(アクセス権/属性)値は「705」や「604」のように真ん中をゼロにしないといけない場合があります。詳しくはウェブサーバのヘルプをご参照下さい。

さくらインターネット、ロリポップ、Xserver、XREA、usamimi.info、fya.jpなどのサーバに設置する場合は、上表にある「suEXEC」側の値を設定して下さい。 特にディレクトリのパーミッションを誤って「一般の場合」の値に設定してしまうと、例えば「画像投稿処理は完了できるのに、画像が一切表示されない」といった動作上の不具合が起こります。(パーミッションを正しく設定し直せば解決します。)

ZIP内に含まれている「Readme.txt」ファイルは、アップロードしないで下さい。解説を記述したただのテキストファイルですから。

➡ ここまで完了したら、もう動作するハズです。

動作を試す際には、ブラウザで tegalog.cgi にアクセスする必要がある点にご注意下さい。自身で何らかの工夫をしない限り、ディレクトリ名までのURLにアクセスしても表示されません。 ディレクトリ名までのURLで動くようにしたい場合は、さらに『ファイル名「tegalog.cgi」を省略してアクセス可能にする方法』をご参照下さい。

セットアップ上の補足

※別スキン(オプションスキン)を使う場合のアップロード先

てがろぐには、複数のスキンをアップロードしておいて、別スキンを一時的に適用する(スキンを切り替える)機能があります。 その機能を使う場合は、「1スキン=1サブディレクトリ」の階層構造でアップロードして下さい。ディレクトリ名は何でも構いません。

「1スキン=1サブディレクトリ」の階層構造でアップロード

スキンファイルは、置き場所に応じて以下のように扱われます。

  • CGIと同じディレクトリにあるスキンファイル(※上図の緑色部分) = 標準スキンとして初期状態で適用される
  • CGIのあるディレクトリのサブディレクトリにあるスキンファイル(※上図のピンク色部分) = 管理画面から切り替えられる別スキンとして機能

てがろぐVer 1.4.0以降には、CGIの管理画面上で本番適用スキンを切り替えられる機能があります。 しかし、本番適用するスキンはCGIと同じディレクトリにスキンファイルを置いておく方が、より高速に動作します。 使用するスキンが確実に決まった場合には、スキンファイルを物理的に移動しておくことをお勧め致します。

別スキンの適用方法やスキン内の各ファイルの役割については、カスタマイズ方法ページ内のスキンをカスタマイズする際に書き換えるファイルもご参照下さい。

※文字コードについて

配布ファイルの文字コードは、すべて UTF-8 になっています。
UTF-8コード以外での動作は想定していませんし実験もしていません。 文字コードは、UTF-8のままアップロードされることをお勧めしますが、他の文字コードを使用したい場合は、全ファイルを使用したい文字コードに変換した上でアップロードして下さい。一部のファイルだけ文字コードを変えると、文字化けが起こります。 (文字コードを変更した場合は、tegalog.cgi の68行目を適切に書き換える必要があります。)
よく分からない場合は、文字コードを変換せずUTF-8コードのままご使用下さい。

※サンプルデータについて

データファイル内には、サンプルデータが含まれています。 サンプルデータが不要なら(※当然不要でしょうが:^^;)最初に使用する際に管理画面上で削除して下さい。 もしくは、中身が空のデータファイル(tegalog.xml)を新しく作成してからアップロードしても構いません。しかし、ファイル自体のアップロードを省略すると、動作時にエラーになります。

CGIの更新方法

ダウンロード

最新版のCGI一式は、TOPページの「CGIのダウンロード」区画からダウンロードできます。

更新情報

最新バージョンで新たに追加された機能や修正された不具合等の案内は、リリースノートでご覧頂けます。追加機能ごとに公式ヘルプ各ページへのリンクも用意していますので参考にして下さい。

CGIをバージョンアップする方法

以前のバージョンをお使いの場合は、 tegalog.cgi と fumycts.pl の2つのファイルのみを上書きアップロードして下さい。 それ以外のファイルをアップロードする必要はありません。 特に、データファイル(tegalog.xml)を上書きしてしまうと、過去のデータが消えてしまいますので、くれぐれもご注意下さい。

バージョンアップ時に上書きするファイルは2つだけ

なお、CGIソースに直接記述する形の設定は、上書きするとデフォルト設定に戻ってしまいます。アップロードする前に、以前と同じように編集しておいて下さい。

「今までは動いていたのに、バージョンアップすると動かない!」という場合は、CGI本体(tegalog.cgi)1行目の記述を書き換え忘れていないか確認して下さい。 ただし、Ver 3.7.0以降では、ほとんど環境で1行目を書き換える必要はなくなっています。まずは何も書き換えずに上書きしてみて下さい。 そのほか、トラブルシューティング区画の「500 Internal Server Errorになってしまう場合の対処方法」項目などもご参照下さい。

※データの互換性について

データファイルはそのままの状態で、CGIを最新版に更新するだけで使い続けられます。

※Ver 1.x系から Ver.2系 へのアップグレード時でも、データファイルや設定ファイルはそのまま引き継げます
※Ver 2.x系から Ver.3系 へのアップグレード時でも、データファイルや設定ファイルはそのまま引き継げます

Ver 1.x系から一気に Ver.3系 へアップグレードする場合でも、データファイルや設定ファイルはそのまま引き継げます

※スキンの更新について

もし、配布されているスキンをそのまま利用している場合は、スキンファイル群も同時に上書きアップロードすれば、新しく加わった表示機能を簡単に活用できます。 スキンをカスタマイズして使っている場合は、上書きアップロードはしないようご注意下さい。その際は、新パッケージに含まれるスキンHTMLやCSSの中身を別途ご覧になりつつ既存スキンを編集すると、カスタマイズしやすいでしょう。

標準添付のスキンはいろいろありますが、スキンのHTMLやCSSソース内に最も詳しくコメントを書き添えてあるのは「標準スキン」です。 新しい機能に関する書き方を、ソースを読んで知ろうとする場合には、「標準スキン」のソースをご覧になることをお勧め致します。

※データが失われてしまった場合は自動バックアップから復元

もし自動バックアップ機能を有効にしている場合は、バックアップ蓄積ディレクトリの中に、直前までのデータファイルが存在します。 データが失われてしまった際には、バックアップ蓄積ディレクトリの中にある最新日付のファイルをダウンロードして、ファイル名を変更し、CGIと同じディレクトリにアップロードすれば(バックアップされた時点のデータが)回復します。

設置上のTIPS/トラブルシューティング

ファイル名をわざわざ index.cgi に変更しなくても、「tegalog.cgi」を省略して「/」で終わるURLでアクセスできるようにする方法

てがろぐ本体を置いたディレクトリに「.htaccess」ファイルを用意して以下の1行を書いておけば、わざわざ「tegalog.cgi」のファイル名を「index.cgi」に修正しなくても、「/」で終わるURLでアクセスできます。

DirectoryIndex tegalog.cgi

この場合、実体の位置は https://www.example.com/memo/tegalog.cgi でも、 https://www.example.com/memo/ という「/」で終わるURLだけで表示できます。

その場合、管理画面には https://www.example.com/memo/tegalog.cgi?mode=admin というURLだけでなく、 https://www.example.com/memo/?mode=admin というURLでもアクセスできます。

てがろぐ動作試験版では、CGIの実体は https://www.nishishi.org/testground/tegalog/tegalog.cgi にありますが、 上記の方法を使って https://www.nishishi.org/testground/tegalog/ というURLでもアクセスできるようになっています。

アップロードした画像が表示されない、ありがちな理由

投稿画像を蓄積するための「images」サブディレクトリのパーミッション設定が誤っていないかどうかを確認してみて下さい。

画像の投稿はエラーなく完了するのに、表示だけがされないという場合は、ほぼ間違いなく、imagesディレクトリのパーミッションの設定を 766 にしてしまっていることが原因です。755や705などに変更して下さい。

「suEXEC」という安全な仕組みが有効のサーバ(さくらインターネットやロリポップなどもそうです)では、ディレクトリのパーミッションを誤って「一般の場合」の値に設定してしまうと、「画像投稿は完了するのに、画像が一切表示されない」という動作上の不具合が起こります。 ディレクトリのパーミッションを正しく設定し直せば解決します。

suEXECという安全な仕組みが有効なサーバでは、サブディレクトリのパーミッションはデフォルトのまま(755など)で構いません。 ここで(全員に書き込み権限を付加する意味の)766 にしてしまうと、そのサブディレクトリに格納されたあらゆるファイルは(安全のために)表示されなくなります。 その場合は、サブディレクトリのパーミッションを 755 や 705 に変更すると表示されるようになります。755 か 705 のどちらに設定すべきかは、サーバのヘルプをご参照になるか、または他のディレクトリのパーミッションを確認すると良いでしょう。(さくらインターネットやロリポップでは 705 にして下さい。)

※各ファイルのパーミッションの値については、セットアップ(設置)方法ページの「設置方法3:パーミッションの設定」をご参照下さい。

404 Not Foundや、403 Forbiddenになる、ありがちな理由

構成ファイル群をアップロードしたハズなのに、ブラウザでアクセスすると「404 Not Found」や「403 Forbidden」のエラーが出てしまう場合は、tegalog.cgi にアクセスしているかどうかを確認して下さい。

自身で何らかの工夫をしない限り、「ディレクトリ名までのURL」にアクセスしても表示されません。
例えば https://ドメイン/tsubuyaki/ のディレクトリにアップロードした場合は、https://ドメイン/tsubuyaki/tegalog.cgi にアクセスする必要があります。

もし「ディレクトリ名までのURL」で動くようにしたい場合は、さらに『ファイル名「tegalog.cgi」を省略してアクセス可能にする方法』で説明している方法等を使う必要があります。 (この方法が使えない場合は、 tegalog.cgi を index.cgi に改名して使う手もあります。)

ロリポップのサーバ上で稼働させた場合で、(普段は普通に使えるのに)ある特定の種類の投稿後にだけ「403 Forbidden」になってしまう場合は、『ロリポップのサーバで投稿後に「403 Forbidden」になる場合の対策』をご覧下さい。

閲覧は問題ないのに、投稿や設定変更後にだけ「404 Not Found」になってしまう場合は、『投稿や設定変更操作をすると「404 Not Found」エラーになる場合』をご覧下さい。

500 Internal Server Errorになってしまう場合の対処方法

CGIをアップロードした際に、「500 Internal Server Error」が表示されるだけで動作しない場合には、下記の点をチェックしてみて下さい。 なお、可能ならウェブサーバ側のエラーログファイルに何が記録されているかを参照すると、原因究明の参考になります。

※バージョンアップした際にInternal Server Errorになってしまう場合

バージョンアップ時には、tegalog.cgi と fumycts.pl の2つのファイルを必ずセットで上書きアップロードして下さい。
どちらか片方だけしか上書きしなかった場合は、Internal Server Error になる可能性があります。

そのほか、初回セットアップ時に必要だった各種操作(1行目の書き換えや、CGI本体に直接記述する系統の設定など)を忘れていないか、下記の「最初からInternal Server Errorになってしまう場合」項目を参考にしてみて下さい。

どうしてもエラーが解消しない場合は、試しに別のディレクトリに新規セットアップを試してみて下さい。それで動作するなら、バージョンアップの過程に何か問題があります。

※最初からInternal Server Errorになってしまう場合
▼アスキーモードで転送したかどうかを確認

CGIの構成ファイルを「アスキーモード(テキストモード)」でアップロードしたかどうかを確認して下さい。 バイナリモードでアップロードしてしまうと、改行コードが正しく変換されずに、Internal Server Errorになることがあります。 試しに、アスキーモードであることを確認した上でアップロードし直してみて下さい。

配布ファイルの改行コードは、てがろぐVer 2.xまではWindows標準の[CR]+[LF]でした。この場合、たいていのウェブサーバとは異なります。 てがろぐVer.3以降はUNIX標準の[LF]になっています。この場合、たいていのウェブサーバとは一致するでしょうが、必ず一致するとは限りません。なので、念のためにアスキーモードで転送する方が無難です。

もし改行コードが自動変換されない方法でアップロードしたい場合(Webサーバのコントロールパネル経由でアップロードしたい場合など)は、任意の改行コードで上書き保存できるテキストエディタ(例えばEmEditor)を使って、改行コードをWebサーバの仕様に合わせて上書き保存した上でアップロードしてみて下さい。 (たいていのWebサーバではUNIX系OSが使われていますから、改行コードは[LF]にする必要があります。)

▼CGIソースの1行目を書き換えたかどうかを確認

CGI本体ファイルである tegalog.cgi の1行目は、#! /usr/bin/env perl のように記述されています。 これは、たいていのサーバでは(書き換えることなく)このままで動作しますが、お使いのサーバによっては正確なPerlパスに書き換えないと動かない(=「500 Internal Server Error」になる)場合があります。 もし書き換える必要があるサーバをお使いの場合は、 例えば、#! /usr/bin/perl#! /usr/local/bin/perl などに書き換える必要がないか、お使いのサーバのヘルプを確認してみて下さい。

さくらインターネットやロリポップのサーバでは書き換え不要です。(※Ver 3.7.0未満をお使いの場合は、ロリポップの一部サーバ等で書き換える必要があります。てがろぐCGIの最新版をお使い下さい。)

▼必要なパーミッションの設定値が「suEXEC」の方ではないかを確認

ウェブサーバ側で指定されているパーミッションの設定方法が「一般の場合」か「suEXECの場合」かを確認して下さい。 suEXECという安全な仕組みが採用されているサーバでは、「suEXECの場合」に示したパーミッションを設定しないと動作しないことがあります。 (特に、ディレクトリに対してGroupやOtherへ書き込み権限を付与すると動作しません。) 設定値は、パーミッションの設定をご覧下さい。

特に、次に挙げる各レンタルサーバでは、suEXEC側の設定にする必要があります。
さくらインターネット、ロリポップ、Xserver、XREA、usamimi.info、fya.jp など。

※suEXECの方がセキュリティ面で安全な仕組みなので、suEXECを採用しているサーバは多数あります。たいていサーバのヘルプに記載がありますから、サイト内検索やページ内検索等で調べてみて下さい。

▼必須モジュールが存在するかどうかを確認

ローカル環境や自力でセットアップしたサーバ等で稼働させる場合には、必須のPerlモジュールがサーバにインストールされていない可能性があります。 CGIの設置環境要件の記述をご確認頂き、不足していればインストールして下さい。

権限の問題でサーバにモジュールをインストールできなくても、CGI本体と同じディレクトリにモジュールの構成ファイルを(ディレクトリ構造を維持したまま)設置する方法でも使えます。 その際には、tegalog.cgi の冒頭付近にある #use lib '.'; という記述行の先頭にある「#」記号を削除しないと読み込まれないので注意して下さい。 詳しい書き方は、CGI本体ファイルに直接記述する高度な設定群の「その他」項目もご参照下さい。

▼Perlのバージョンを確認

お使いのWebサーバにセットアップされているPerlのバージョンに問題がある場合もあります。 Perl 5でも、マイナーバージョン番号が古すぎる場合や新しすぎる場合には、何らかの原因で動作しないことがあります。 てがろぐCGIを動作させるには、Perl 5.6以上のバージョンが必要です。 もし、サーバのコントロールパネルからPerlのバージョンを選択可能なら、他のバージョンに変更してみて下さい。(ただし、Perlのバージョンを変更すると、Perlで動作する他のCGI等にも影響しますので充分ご注意下さい。)

動作確認に使っているPerlの詳細なバージョンは、配布パッケージ(ZIPファイル)に含まれている README.TXT ファイルの冒頭付近に記してあります。

※動作の途中でInternal Server Errorになってしまう場合

どのような状況でエラーになるのか、直前の操作内容をお知らせ頂けると助かります。
可能ならウェブサーバ側のエラーログファイルに記録されている内容も参照してみて下さい。

※一度Internal Server Errorになった後は、何をしても(再度セットアップし直しても)エラーが解消しない場合

新規にセットアップすると問題なく動作するのに、それと同じファイルを使ってアップデートしてもエラーが解消しない場合は、「500 Internal Server Error」エラーメッセージを、独自に用意したページに置き換えていないかどうかを確認して下さい。

お使いのWebサーバで「500 Internal Server Error」エラーメッセージを独自に用意したページに置き換えている場合に、URLが変わる形で転送してしまっていると、エラーが解消しないように見えることがあります。(その場合は、ブラウザのキャッシュをクリアしたり、別のブラウザを使ったりすれば、正しく見えます。)

これは、.htaccessファイルの記述が望ましくない形になっているためです。
独自エラーページへ(301で)転送すると、転送先URLをブラウザが記憶するため、次回以降のアクセス時には「直接エラーページを見に行く」ようになってしまい、エラーが解消されてもエラーページしか見えなくなります。

この現象を解消するには、独自エラーページへの転送を止めるのが最も簡単です。ただし、設定を削除してもブラウザのキャッシュは消えないため、ブラウザのキャッシュをクリアする作業も必要です。(あなた自身だけでなく、一度でもエラーページを見てしまった閲覧者は全員キャッシュをクリアしない限り、エラーページしか見えない状態になります。)

エラーページを独自に用意する場合は、転送せずに内容だけを置き換えるように(=エラーページが見えている場合でもURLは元のまま変わらないように)するのが無難です。

ロリポップのサーバでエラーが出る場合の解決策

てがろぐCGIをロリポップのサーバ上で稼働させた場合にエラーになる場合は、下記の点もご確認下さい。

▼ロリポップのサーバで「500 Internal Server Error」になる場合の解決策

まずは、てがろぐ Ver 3.7.0 以降のバージョンをお試し下さい。

もしそれでも解決しない場合や、どうしても Ver 3.6.x 以下のバージョンを使う必要がある場合は、 てがろぐ本体(tegalog.cgi)をテキストエディタで開いて、1行目にある記述を #! /usr/local/bin/perl のように修正する必要があります。

▼ロリポップのサーバで投稿後に「403 Forbidden」になる場合の対策

ロリポップのサーバ上で稼働させている場合に、投稿本文の中に /etc/abcd のような半角9文字を含めて送信(投稿)すると、サーバに拒否されて「403 Forbidden」エラーが出る問題が分かっています。 abcdの部分は英字4文字以上なら何でもエラーになるようです。(そのほかにも何らかのNGワードがあるかもしれません。) この謎仕様はロリポップ側の問題なので、てがろぐCGI側で直接どうにかすることはできません。 ただ、NGワードを避ければ良いだけなので、以下の2通りの対策が考えられます。

  • 【対策1】文字として表示できれば良いだけなら、意味のないHTMLタグで挟まれるように書く。
    /etc/abcd という連続した9文字の投稿が無理でも、先頭1文字を太字装飾にして [B:/]etc/abcd のようにするとNG判定に引っかからなくなるので投稿できます。 この方法だと先頭のスラッシュ記号が太字になってしまいますが、例えば自由装飾記法を使って [F:hogehoge:/]etc/abcd のようにすると、 意味のないHTMLタグで囲まれるだけなので、表示上は「 /etc/abcd 」という何も装飾されていない文字として見えます。
  • 【対策2】ウェブ上の etcディレクトリにあるファイルを参照したい場合は、別ディレクトリからリダイレクトする。
    例えば https://www.example.com/etc/image.png のように、Web上に存在するetcディレクトリの中にあるファイルを参照したい場合などでも、そのまま投稿すると403エラーになってしまいます。 これを避けるには、例えば以下の方法があります。
    1. まず、適当な「sonota」といような名称のディレクトリを作成します。
    2. そこに .htaccess ファイルを置いて、「etc」ディレクトリへリダイレクトさせます。
    すると、てがろぐ上では /sonota/filename というパスを書けば、実際には /etc/filename を参照できることになります。

UNIX系OSでは /etcディレクトリに各種設定ファイルがありますから、おそらくそのようなファイルがWebフォームから参照されてしまわないようにするための対策なのでしょうけども。 ちょっどざっくり過ぎる(強引すぎる)対策な気がします……。WAF(Web Application Firewall)の機能のような気もするのですが、WAFをOFFに設定しても回避はできないという報告も受けていますので、 WAFのせいというわけでもないのかもしれません。とすると、ロリポップサーバでは(どうやっても)受け入れるしかない仕様なのかもしれません。^^;(解決できる設定方法を発見された場合は、ぜひお知らせ下さい。

投稿時等に「CGIの設置ドメインとは異なる場所からデータが送信されました」というエラーが表示されてしまう場合

投稿時や設定変更時に「CGIの設置ドメインとは異なる場所からデータが送信されました」というエラーが表示されてしまう場合は、以下の方法をお試し下さい。

  • てがろぐ Ver 3.2.0以上にバージョンアップして下さい。
  • もし、お使いのドメイン以外に「サーバ会社側が用意したデフォルトドメイン」でも同じページにアクセスできる仕様のサーバなら、その「サーバ会社側が用意したデフォルトドメインを使ったURL」でアクセスして投稿してみて下さい。

その上でも同様のエラーが表示される場合には、そのときエラー画面に表示されている内容をコピーして、CGI作者までメールでお知らせ下さい

fumycts.pl ファイルの20行目付近に、my $rcheck = 1; という記述があります。 ここを my $rcheck = 0; のように書き換えると、このエラーを強制的に無効化できます。 ただし、この方法での無効化は、セキュリティ面からあまりお勧めはできません。(ローカル環境やセキュリティで保護された環境下など、第三者がアクセスしない場所で稼働している場合には、この方法の対処でも問題ありません。)

何も表示されなかったり、一部の画面だけがエラーになったり、投稿や設定変更だけがエラーになる場合

CGIにアクセスしても何も表示されなかったり、 「ページは正しく生成されているのに管理画面だけは見えない」場合や、「管理画面は見えるがページが見えない」場合など、一部の画面だけがうまく表示されていなかったりする場合には、 CGI本体ファイルに直接記述する高度な設定群の「その他」項目にある「$howtogetpath」の値を0、1、9などに変更してみて下さい。

もし、0でも1でもダメな場合で、tegalog.cgi のファイル名を別名に変更して使おうとしている場合は、ファイル名を tegalog.cgi に戻した上で、値を「9」に設定してみて下さい。

投稿や設定変更操作をすると「404 Not Found」エラーになる場合

ページも管理画面も正しく表示されるのに、投稿操作や設定変更操作をした場合にだけ「404 Not Found」エラーが出てしまう場合は、てがろぐCGI側が自身の所在を正しく認識できていないことが原因です。 その場合は、CGI本体ファイルに直接記述する高度な設定群の「その他」項目にある「$howtogetpath」の値を0、1、9などに変更してみて下さい。

レンタルサーバの「カラフルボックス」では、この値を「0」にしないと正しく動作しないと報告を受けています。

ログインしたハズなのに何度もログインフォームが表示されてしまう(管理画面TOPに戻ろうとするとログインフォームが出てしまう)場合

ログインしているハズなのに、管理画面TOPを再度表示しようとするとログインフォームが見えてしまう場合や、ログインしたハズなのに再度ログイン画面が見えてしまう場合は、キャッシュが効き過ぎている可能性があります。 管理画面TOPのURLと、「非ログイン状態から管理画面のTOPにアクセスしようとしたときのログイン画面」のURLが同じなので、ログイン画面が表示された時点でキャッシュされてしまうと、管理画面TOPが見えなくなります。

この場合には、ブラウザやサーバのキャッシュ設定を見直してみて下さい。サーバによってはデフォルトで強力なキャッシュが設定されているかもしれません。

Ver 3.5.0以降では、管理画面の表示時にはキャッシュが効き過ぎないようにするヘッダ「cache-control: no-cache」を出力するようになりました。古いバージョンを使っている場合は、Ver 3.5.0以降にバージョンアップしてみて下さい。

普段お使いのブラウザ以外のブラウザでもログインを試してみて下さい。それでうまくいくなら、お使いのブラウザのキャッシュ設定が強すぎる可能性があります。 他のブラウザでも同様の問題が発生する場合は、サーバ側のキャッシュ設定が強すぎる可能性があります。

レンタルサーバのロリポップでこの問題が発生する場合は、ロリポップアクセラレータを無効に設定してみて下さい。

埋め込み合成用のスキンを使った表示結果を、SSIやPHPなどを使って他ページに合成している場合では、画像やハッシュタグリンクなどのリンク先が(相対パスで出力されるために)リンク切れになってしまう可能性があります。 その際は、下記の設定項目(黄色矢印部分と水色矢印の部分)にチェックを入れておくと、それぞれが絶対URIで出力されるようになるため、リンク切れにならずに済みます。

リンクを絶対URIで出力する設定

出力結果を別ページに埋め込む際の設定方法(注意点)には他にも少々ありますので、詳しくは、あるスキンの出力結果を別のページに埋め込む方法をご覧下さい。

※複数のスキンを併用しているなど、『一時適用中のスキンを維持できるリンクを出力する』のチェックを外す方法を避けたいなら、JavaScriptを使ってリンク先URLを動的に編集する方法もあります。詳しくは上記ページをご覧下さい。

最新版をUPしたのに、てがろぐがアップデートされない!? なぜだ!? という場合の確認点

最新版の tegalog.cgi と fumycts.pl をアップロードしたのに、Web上のてがろぐがバージョンアップされておらず旧バージョンのままに見える場合は、下記の点をご確認下さい。

▼ファイル名を変更して使っている場合に、ファイル名を変更せずにUPしていませんか?
例えば、てがろぐの本体ファイル名 tegalog.cgi を index.cgi に改名して使用している場合に、最新版のてがろぐ本体ファイルを tegalog.cgi のままアップロードして、ブラウザでは index.cgi にアクセスしている場合です。 これだと、ずっと旧バージョンにアクセスすることになります。ファイル名を変更してからアップロードして下さい。

なお、tegalog.cgi は index.cgi に改名しても動作しますが、そうしなくても、.htaccessファイルに1行書いておくだけで、ファイル名は tegalog.cgi のままで「 / 」で終わる短いURLでアクセス可能にできます。 詳しくは、わざわざファイル名を index.cgi に変更しなくても、「/」で終わるURLでアクセスできるようにする方法をご覧下さい。

▼ディレクトリは正しいですか?
実は異なるディレクトリにアップロードしていた、というケースがあります。 例えば、以前に実験として試しにアップロードしていた(本番用途には使っていない)てがろぐの方をアップデートしていた、というような可能性です。 アップロード先が正しいかどうかを再確認してみて下さい。
▼強力なキャッシュが効いているのかもしれません
普段は使っていない別のブラウザやPCを使ってアクセスしてみて下さい。その場合にバージョンアップできているなら、キャッシュが効き過ぎていることが原因です。 とりあえずはブラウザのキャッシュを削除すると(バージョンアップ後の)ページにアクセスはできるでしょう。しかし、根本的な解決にはなっていないので、サーバ側のキャッシュの設定を見直すことをお勧め致します。

SSL証明書を導入して https://~ のURLでアクセスしても警告マークが表示されてしまう場合

てがろぐCGIは、HTTPS環境でも問題なく動作します。 もし、SSL証明書を導入してHTTPS化したにもかかわらず、ブラウザのアドレス欄に緑色の錠前アイコン(🔒)ではなく黄色の警告アイコン(⚠)が表示されてしまう場合は、表示ページ内のどこかでHTTP決め打ち( http://~ のURL)の画像などが読み込まれている可能性があります。 特に、『ユーザアイコンのURLが「http://~」で書かれている』というケースが散見されますので、ぜひご確認下さい。

HTTPSアクセス時に黄色の警告アイコンが出る場合は、たいてい以下の理由です。

  • CGI自体はHTTPSでアクセスできるんだけど、
  • ページ内に表示される一部の画像だけがHTTPでアクセスされている

ページに埋め込む画像をURLで指定する場合に、https://~ ではなく http://~ で書いてしまうケースはよくあります。 てがろぐの場合、特にユーザアイコンの設定は見落とされがちな気がします。 ユーザアイコンは、管理画面の「ユーザIDを管理」からユーザ別に設定できます。

ユーザアイコンのURLは https:// から書かなくても、「/」で始まる絶対パスで書くこともできますし、CGI本体の設置場所を基準にした相対パスで書くこともできます。 また、CGI本体と同じディレクトリに画像ファイルを置いているなら、単に画像ファイル名を書くだけでも表示可能です。
※ユーザアイコンは、CGIの存在する位置からの相対パスで指定するか、サーバルートからの絶対パスで指定するのがお勧めです。

解決が難しいトラブルに遭遇した場合

にっちもさっちもいかなくなった場合は、作者までお問い合わせ下さい。 その際は、発生している問題の詳細、設置場所(URL)、お使いのサーバ会社名など、できるだけ詳しい情報をお知らせ頂けると、話が早く進みます。 サーバのエラーログがあるととても望ましいです。

そのほか、事実上のサポート掲示板になっている「てがろぐ動作試験版」に何か情報が投稿されている可能性もありますので、遭遇している問題に関係しそうなキーワードで検索してみて下さい。 また、お使いのバージョンが正式版な場合は、最新β版で何か解決できていないかも併せてご確認頂ければ幸いです。

CGIを複数個設置して併用する方法

てがろぐCGIは、同一サーバ内にでも必要なだけ複数個設置して使えます。 ただし、それぞれのCGIで別個にログイン状態を維持するためには、管理画面からの設定が必要な場合があります。

CGIを複数併用する場合の設置場所

1つ1つを異なるディレクトリにアップロードして下さい。例えば以下のような感じです。

  • てがろぐ1つ目: https://www.example.com/tegalog/
  • てがろぐ2つ目: https://www.example.com/tegalog2/
  • てがろぐ3つ目: https://www.example.com/tegalog-extra/

ディレクトリ名は何でも構いません。要は、「1つのてがろぐ=1ディレクトリ」で構成されていれば問題ありません。

CGIやデータファイル等の全構成ファイルの名称を変更すれば同一ディレクトリ内に複数のCGIを設置することも不可能ではありませんが、お勧めはできません。 また、そのような稼働方法では動作試験をしていません。

CGIを複数併用する場合の設定

てがろぐCGIを複数個設置する場合で、それぞれのCGIを新規にセットアップしたなら、以下の設定は(ほとんどの場合で)不要です。

しかし、「既に稼働しているてがろぐCGI」の全構成ファイルをコピーする方法で2つ目のCGIを設置した場合(※1)には、以下の設定を手動で行う必要があります。

※1:正確には、他の場所で既に稼働していたCGIの tegalog.ini ファイルをコピーして流用した場合には、以下の設定が必要になります。

▼共存のために必要な設定

管理画面の「設定」→「システム設定」→「ログイン維持設定」区画内にある『このCGI固有の識別文字列』項目に入力されている数文字の英数字を、他のCGIと重複しない文字列に変更して下さい。 文字数に制限はありませんが、Cookieの接尾辞に使われますので、5文字前後くらいにしておくのが無難だと思います。

《▼なぜこの設定が必要か?》

てがろぐCGIのログイン状態は、ブラウザのCookieを利用して維持されます。 同一サーバ内に設置するCGIで、もし同じCookie名を流用してしまうと、1つのドメインにつき1つのログイン状態しか維持できません。 そのため、どれか1つにログインすると、他のすべてのログイン状態は解除されてしまいます。

それを防ぎ、すべてのCGIで個別にログイン状態を維持できるように、別々のCookieを発行してログイン状態を維持できる仕様になっています。 それぞれのCGIを別個に識別する目的で異なるCookie名を利用するために、1つ1つのCGIで異なる識別文字列が必要です。 (入力した識別文字列がそのままCookie名になるわけではなく、ベースのCookie名に付加される接尾辞として使われます。)

その識別文字列を設定するのが、『このCGI固有の識別文字列』項目です。

新規にセットアップした場合は、この識別文字列には5文字の英数字がランダムに入りますので、(確率的にはほとんどの場合で)他とは異なる文字列が指定されています。 そのため、手動で識別文字列を書き換える必要性は(ほぼ)ありません。 9億分の1くらいの確率で同じ識別文字列が偶然設定されてしまう可能性はありますが。(^_^;)

設置するドメインが異なっていれば、同じ識別文字列を使っても問題ありません。(同じ識別文字列を使うメリットは何もありませんが。)

▼設定値を変更した際の注意

設定で「このCGI固有の識別文字列」項目を書き換えるたびに、認証状態を保持するCookie名が変わるため、全ユーザが自動ログアウトされてしまいますのでご注意下さい。 (それぞれのユーザが再度ログインすれば、それ以後はまたログイン状態を維持できます。)

設定で「このCGI固有の識別文字列」項目を書き換えた結果として全ユーザがログアウトしてしまった場合は、サーバ側に保存してある既存の認証記録は消えないため、管理画面TOPの下部に表示されている「ログイン人数」の表示は減りません。 そのままでは正しいカウント値になりませんので、それが気になる場合は、設定を変更した後に一度だけ、管理画面から「全員を強制ログアウト」ボタンを押してサーバ側の認証記録をクリアして下さい。 すると、サーバ側に保存してある認証記録がすべて消えるために「ログイン人数」のカウント値が0に戻りますから、それ以後は正しいログイン件数が表示されます。

▼識別文字列を共有するメリットはありません

同じ識別文字列を指定しても、IDやパスワードを共用できるわけではありません。 同じ識別文字列を指定しても、不便になるだけでメリットは何もありません。

複数のてがろぐCGI間でIDやパスワードを共用する方法はありません
ただし、既に稼働しているCGIから tegalog.ini と psif.cgi の2ファイルをコピーしてセットアップすれば、既に設定されていたIDとパスワードをコピー(流用)して使うことは可能です。 (※同時にその他の設定も引き継がれます。識別文字列も引き継がれるため、セットアップ後に修正が必要です。また、日付別カウント数・ハッシュタグカウント数・カテゴリカウント数なども引き継がれてしまうため、その方法でセットアップした場合は、セットアップ後に一度だけ管理画面から「投稿の再カウント」を実行する方が良いでしょう。)

複数のCGIを識別しやすくする支援機能

てがろぐCGIを複数個設置しているときに、それぞれを区別しやすくする方法を2つ用意しています。

▼カラーテーマを変更する機能

管理画面の配色(カラーテーマ)を切り替える機能があります。 複数のてがろぐCGIを併用する際に、どれを使っているのか迷わないよう色分けする用途にもご活用頂けます。 あくまでも管理画面のUI配色を選択するだけであって、ページの表示(スキン)には一切影響しません。

Ver 3.5.0以降では、下記の7テーマから選択できます。(Ver 2.7.0~3.4.0では、最初の4テーマのみから選択できます。)

てがろぐ管理画面のカラーテーマ4種類

「てがろぐ」管理画面のカラーテーマ(追加3)

設定箇所は、管理画面の[設定]→システム設定→【管理画面内の表示】→『カラーテーマ』項目です。

ここで設定したカラーテーマは、ログアウト状態でも適用されます。(WordPressのようにログインユーザごとに適用されるわけではなく、ログインしているかどうかに関係なく全員共通の配色として表示されます。)

▼識別名称を付与できる設定機能

ブラウザのタブ(タイトルバー)で識別できるように、タイトル先頭に任意の識別名を挿入する機能もあります。 ここで指定した識別名は、管理画面では常時左上に表示されるほか、ブラウザのタイトルバー先頭にも(管理画面が表示されている状況では)常時表示されます。 あくまでも管理画面で「そのてがろぐの用途」を識別しやすくするための機能であって、ページの表示(スキン)には一切影響しません。

てがろぐ識別名称を付与できる設定機能

設定場所は、管理画面の[設定]→[システム設定]→【管理画面内の表示】→『管理画面のタイトル先頭に挿入される識別名』項目です。

同一ブラウザの複数のタブで、別々のてがろぐCGIを同時に使っている場合に、それぞれを区別しやすくするためのニッチな機能です。^^;

CGIの高度な設定

てがろぐCGIの主な設定は、ブラウザ上で「管理画面」にログインしてから簡単に変更できます(変更内容は設定ファイルに保存されます)。
しかし、一部の高度な設定は、てがろぐCGI本体である tegalog.cgi のソース冒頭付近を直接編集することで設定する仕様になっています。

CGI本体ファイルに直接記述する高度な設定群

もし必要があれば、tegalog.cgi の中身をテキストエディタで読み込んで、下記の通りに書き換えられます。

※fumycts.pl側には書き換える項目はありません。
※デフォルトの状態で使用するのであれば、(1行目以外は)まったく書き換えなくても動きます

▼Perlの位置

(1行目) #! /usr/bin/env perl
Perlの位置を必要に応じて書き換えます。 /usr/bin/perl や /usr/local/bin/perl など。書き換えなくて良いケースも多いです。

▼基本設定

(32行目) my $bmsdata = 'tegalog.xml';
データファイル名(拡張子はxmlでなくても構いませんが、記録形式はXMLです。)
(35行目) my $setfile = 'tegalog.ini';
設定ファイル名(拡張子はiniでなくても構いません。)
(38行目) my $passfile = 'psif.cgi';
パスワード・セッションID格納ファイル名(デフォルトは psif.cgi )
▲中身を閲覧されないようにするため拡張子をcgiにしています。他の拡張子に変更しても動作は可能ですが、中身は第三者に閲覧されないようにして下さい。(※パスワードは暗号化(ハッシュ化)されて記録されていますから中身を見られてもパスワードは漏洩しませんが、セッションIDが漏洩すると危険です。)
(41行目) my $autobackupto = 'backup';
自動バックアップファイル保存先ディレクトリ名
(44行目) my $imagefolder = 'images';
投稿画像の保存先ディレクトリ名

▼オプション設定

(51行目) my $keepsession = 1;
セッション維持の有無(1:ブラウザを終了してもログイン状態を維持する/0:ブラウザを終了するとログアウトする)
▲ログイン状態を維持する場合、デフォルトの維持期限は(最後の操作から)31日後です。(CGIの管理画面で、1時間~1年の範囲内で自由に設定できます。)
(54行目) my $safemode = '0';
セーフモードの選択(デフォルトは "0")
▲HTMLソースを直接記述可能な設定項目の動作を制限できます。(0:何もしない/1:scriptタグ系の記述は無効にする/9:あらゆるHTMLタグを無効にする) ※9は試験実装の段階なのでお勧めしません。
(57行目) my $nopassuser = '0';
ログイン可能なユーザ種類の選択(デフォルトは "0")
▲パスワード未設定のユーザのログインを拒否できます。(0:拒否しない / 1:拒否する / 2:全ユーザのパスワードがない状態では管理画面以外の表示を拒否する )
(60行目) my $safessi = '1';
Include(SSI)機能使用時の参照可能ディレクトリ制限(デフォルトは "1")
▲スキン内でのInclude(SSI)機能使用時に、上位ディレクトリの参照やフルパスでの記述を許可するかどうか。(0:しない / 1:する / 9:Include機能を無効化する )
(63行目) my $MsgForLoginScreen = '';
ログイン画面下部に表示させるメッセージ(デフォルトは空文字)
▲複数人で共用する場合の案内や、複数個設置する際の識別のために、ログインフォームの下部に何かメッセージを表示できます。HTMLを書くとそのまま出力されます。

▼その他

(70行目) my $charcode = 'UTF-8';
文字コード(デフォルトは "UTF-8")
▲変更する場合はCGIや各種データファイルの文字コードも一緒に変更して下さい。(UTF-8以外での動作は想定していませんので、変更しないことをお勧め致します。)
(73行目) my $skincover = 'skin-cover.html';
(74行目) my $skininside = 'skin-onelog.html';
スキンファイル名(外側/内側)
▲変更すると、変更後のファイル名に合致したファイルしかスキンとして認識されなくなります。(変更しないことをお勧め致します。)
(77行目) my $howtogetpath = 2;
CGI名の取得方法。※ログイン直後や投稿直後に画面がうまく出ない場合画面遷移が正しく行われない場合には、この値を別の値に変更してみて下さい。(0:プロトコルから/1:ディレクトリから/2:ファイルだけ/9:決め打ち) 特に動作に問題がない場合は、「2」のまま変更せずにお使い下さい。
(88行目) #use lib '.';
サーバにインストールされていないモジュールを、CGIと同じディレクトリ内に自力で置いた場合は、この行の先頭にある「#」を削除して下さい。すると、それらを読み込んで使うように動作します。

特に必要がなければ、何も変更せずにお使い頂くことをお勧め致します。上記以外の各種設定は、ブラウザ上で管理画面から変更できます。

Last modified: 2022/09/21 10:38:00

--- 当サイト内を検索 ---