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

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

お手軽マイクロブログCGI「てがろぐ」のセットアップ方法です。お使いのサーバに設置する手順を解説しています。
手順と言っても単に全ファイルをアップロードして、パーミッションを設定するだけです。

《最終更新: 2020年10月01日 》

CGIの動作要件

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

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

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

動作サーバの例

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

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

CGIの設置方法

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

ZIPを展開したファイルの内、説明用の「README.TXT」ファイルを除く8個のファイルを、同一のディレクトリにアップロードして、下表に記したパーミッション(アクセス権/属性)に設定するだけです。 ただし、サーバによっては、てがろぐCGI本体(tegalog.cgi)の1行目を、サーバ側が要求するように事前に書き換えておく必要があります。

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

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

これだけで動作します。

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

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

しかし、お使いのサーバによっては、CGIの1行目にある#! /usr/bin/perlの記述だけをサーバ環境に合わせて例えば#! /usr/local/bin/perlなどに書き換える必要があります。 もし書き換える必要があれば、tegalog.cgi をテキストエディタで開いて、1行目をサーバ会社が指定する通りに書き換えて下さい。

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

よく分からない場合は、とりあえず、まずは書き換えずにそのままアップロードして試してみて下さい。
書き換える必要がなければそのまま動作します。書き換える必要がある場合には「500 Internal Server Error」になります。

例えば、

  • さくらインターネットのサーバなら書き換え不要ですから、このステップは飛ばせます。
  • ロリポップ!のサーバは、多くの場合で書き換え不要ですが、一部には#! /usr/local/bin/perlに書き換える必要があるサーバがあります。

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

設置方法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:パーミッションの設定

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

※レンタルサーバの「さくらインターネット」や「ロリポップ!」に設置する場合は、「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でなければなりません。
※6:このディレクトリには「書き込み権限」の付与が必須です。(※サーバでsuEXECが使われている場合は、705等の一般的な値のままで正しく動作します。逆に、766などに設定すると動かなくなります。)
※7:ディレクトリ名は何でも構いません。必ずしも「skin-」で始まっている必要はありません。

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

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

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

セットアップ上の補足

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

てがろぐには、複数のスキンをアップロードしておいて、別スキンを一時的に適用する(スキンを切り替える)機能があります。 その機能を使う場合は、「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行目の #! /usr/bin/perl の記述を書き換え忘れていないか確認して下さい。 そのほか、「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

ファイル名「tegalog.cgi」を省略してアクセス可能にする方法

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

DirectoryIndex tegalog.cgi

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

HTTPS化したにもかかわらず警告アイコンが表示される、ありがちな理由

SSL証明書を導入してHTTPS化したにもかかわらず、ブラウザのアドレス欄に「緑色の錠前アイコン」ではなく「黄色の警告アイコン(⚠)」が表示される場合には、 『ユーザアイコンのURLが「http://~」で書かれている』というケースが散見されますので、ぜひご確認下さい。

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

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

ページに埋め込む画像をURLで指定する場合、https://~ ではなく http://~ で書いてしまうケースはよくあります。てがろぐの場合、特にユーザアイコンの設定は見落とされがちな気がします。(^_^;)
ユーザアイコンは、管理画面の「ユーザIDを管理」からユーザ別に設定できます。(※ユーザアイコンは、CGIの存在する位置からの相対パスで指定するか、サーバルートからの絶対パスで指定するのがお勧めです。)

tegalog.cgiファイルのあるディレクトリにアイコン画像ファイルが置いてあれば、ユーザアイコンURLの指定欄には画像ファイル名を書くだけで表示できます。(サブディレクトリに置いてある場合は、相対パスで指定できます。)

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

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

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

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

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

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

バージョンアップ時には、tegalog.cgi と fumycts.pl の2つのファイルを必ずセットで上書きアップロードして下さい。
どちらか片方だけしか上書きしなかった場合は、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本体ファイルである tegalog.cgi の1行目には、Perlのパスが #! /usr/bin/perl のように記述されています。 もし、お使いのサーバのPerlパスがこれとは異なる場合は、正しいパスに書き換えないと「500 Internal Server Error」になります。 例えば、#! /usr/local/bin/perl などに書き換える必要がないか、お使いのサーバのヘルプを確認してみて下さい。

さくらインターネットのサーバでは(たいてい)書き換え不要ですが、ロリポップの一部のサーバでは #! /usr/local/bin/perl に書き換える必要があります。

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

さくらインターネットやロリポップのサーバでは、suEXEC側の設定にする必要があります。

●必須モジュールがサーバにインストールされていない可能性があります。CGIの設置環境要件の記述もご確認下さい。
●必須モジュールがサーバにインストールされていなくても、自力でCGIと同じディレクトリに設置すれば動作させられます。 しかし、お使いのWebサーバにインストールされているPerlが新しい場合は、tegalog.cgi の冒頭付近にある「#use lib '.';」という記述行の先頭にある「#」記号を削除しないと読み込まれないので注意して下さい。 詳しい書き方は、CGI本体ファイルに直接記述する高度な設定群の「その他」項目をご参照下さい。

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

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

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

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

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

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

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

※エラーページを独自に用意する場合は、転送せずに内容だけを置き換えるように(=エラーページが見えている場合でも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の主な設定は、ブラウザ上で「管理画面」にログインしてから簡単に変更できます(変更内容は設定ファイルに保存されます)。
しかし、一部の高度な設定は、てがろぐCGI本体である tegalog.cgi のソース冒頭付近を直接編集することで設定する仕様になっています。

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

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

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

▼Perlの位置

(1行目) #! /usr/bin/perl
Perlの位置を必要に応じて書き換えます。 /usr/local/bin/perl など。

▼基本設定

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

▼オプション設定

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

▼その他

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

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

Last modified: 2020/10/01 18:38:00

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