動作要件はとても緩いので、たいていのウェブサーバでは何も気にせず8ファイルをアップロードするだけで使える場合も多そうな気がします。
Perl5さえ使えればたいてい動作します。データベースは不要です。
お手軽マイクロブログCGI「てがろぐ」のセットアップ方法です。お使いのサーバに設置する手順を解説しています。
手順と言っても基本は全ファイルをアップロードして、パーミッションを設定するだけです。簡単です。本当に簡単です。説明が長いのは、念のための補足説明が多いだけで、必須の手順はわずか3ステップです。
《最終更新： 2024年03月01日 》
動作要件はとても緩いので、たいていのウェブサーバでは何も気にせず8ファイルをアップロードするだけで使える場合も多そうな気がします。
Perl5さえ使えればたいてい動作します。データベースは不要です。
当サイトは、「さくらインターネット」のサーバ上で公開されています。
てがろぐCGIの動作テストも、さくらインターネットのサーバで実施しています。さくらインターネットをお使いなら、何も書き換えることなくそのままアップロードしてパーミッションを正しく設定すれば動きます。
なお、同人・創作サイト専用レンタルサーバー「WitchServer」には、てがろぐのセットアップがコントロールパネルからのボタンクリックだけで完了する、てがろぐインストール専用機能があります。 コントロールパネルからセットアップ先ディレクトリを指定して新規セットアップができるほか、インストール履歴から対象を選択してバージョンアップさせる機能もあります。
レンタルサーバ別のセットアップ方法を下記の通り用意しています。もし下記に該当するサーバをご利用なら、専用のセットアップ方法ページをご覧下さい。
上記のリストにないサーバをご使用の場合は、これ以降に掲載している汎用のセットアップ方法をご覧下さい。
これから新規にレンタルサーバをどこか契約しようと考えている場合は、記事「てがろぐCGIを使うためにサーバを新規契約するなら」の情報もご参照下さい。
なお、ローカルPCにセットアップして http://localhost/ 等のURLで稼働させたい場合は、記事「てがろぐCGIをローカルPCで動かす方法」をご参照下さい。
てがろぐのセットアップ方法は、ダウンロードしたZIPファイル（※ダウンロードはてがろぐ公式TOPページから）を展開して、出てきたファイルをWebサーバの任意の場所にアップロードして、下表に記したパーミッション(アクセス権/属性)に設定するだけです。 ただし、サーバによっては、てがろぐCGI本体（tegalog.cgi）の1行目を、サーバ側が要求するように事前に書き換えておく必要があります。
したがって、セットアップ手順は下記の3ステップだけです。
これだけで動作します。
最近のウェブサーバなら、おそらく特に何も書き換えずにそのままアップロードするだけで動くことが多いです。
なので、まずは何も書き換えずに「設置手順2」へ進んで下さい。
もし、最終的に（設置手順3の後で）「500 Internal Server Error」が出るようなら、
CGIソースの1行目にある #! /usr/bin/env perl の記述を、例えば #! /usr/bin/perl や #! /usr/local/bin/perl などに書き換える必要があります。
その場合は、tegalog.cgi をテキストエディタで開いて、1行目をサーバ会社が指定する通りに書き換えて下さい。
テキストエディタには、EmEditorをお勧めしています。てがろぐCGIの開発にもEmEditorを使っています。（EmEditorは、無料版として使うこともできます。）
そのほか、文字コードにUTF-8(BOMなし)が扱えて、改行コードを明示的に[LF]に指定して保存できるテキストエディタなら、何を使っても問題ありません。
※Windows7以下の「メモ帳」では編集できませんのでご注意下さい（改行コード[LF]が改行として認識されないため）。
Windows10以降なら「メモ帳」でも大丈夫です。
ごく一部のサーバでは稀に、tegalog.cgi の77行目付近にある （ただ、ほとんどのサーバでは変更不要です。）my $howtogetpath = 2; という記述の値「2」を、0、1、9 のどれかに書き換えないと正常に動作しないことがあります。
管理画面等で設定を保存できなかったり、ページ遷移がうまくいかない場合には、ここの値を変更して試してみて下さい。
➡ Ver 4.2.0 以降では、この書き換えは一切不要になりました。
説明用の「README.TXT」ファイルを除くすべてのファイルを任意のディレクトリ※1にアップロードして下さい。
その際、お使いのFTPソフトに転送モードの設定がある場合は、
※1：Webからアクセスできる場所なら、どこでも好きなディレクトリにアップロードすれば良いです。ただし、次の2点は避けるようご注意下さい。
もちろん自力で解決する知識があるならそこに設置しても構わないのですが、WordPressやそれに付随して用意される.htaccessファイルの設定や仕様に詳しくない場合には、別のサブドメインを使う方が早いと思います。 （WordPressの存在するドメインであっても、WordPressのセットアップされているディレクトリ配下以外のディレクトリに設置できるなら、おそらく問題はありません。）
最近のレンタルサーバでは滅多にないと思いますが、ウェブサーバが最初から cgi-bin ディレクトリを用意しているサーバがあります。 ここは特殊な設定がなされているディレクトリなので、ここにCGI一式の全ファイルを入れてしまうと、「動作はするものの、装飾(スキン)が適用されないし、画像も表示されない」という問題が起きます。 このようなサーバでは『cgi-bin ディレクトリの中身はすべて実行ファイルである』という前提で動作させてしまうため、画像やCSSファイルのような『ブラウザがそのまま中身を読めば良い』ファイルを置くと、正しく読んでくれなくなる問題があるためです。 cgi-bin ディレクトリとは『本当にプログラムだけ』を置くためのディレクトリなので、配布CGIの一式全部を設置する場所としては適切ではありません。
※2：構成ファイルのうち、少なくとも tegalog.cgi と fumycts.pl の改行コードは [LF] である必要があります。[CR] や、[CR]+[LF]だとエラーになります。
設置後のディレクトリ構造は下図のようになります。
自由に作成したサーバ上のディレクトリへ、必要なファイルをアップロードすれば良いだけです。サブフォルダも含めてアップロードする場合は、フォルダ構造(階層構造)を維持したままアップロードして下さい。
考えるのが面倒なら、とりあえず全部アップロードすれば良いです。(笑)
図の左側は最小限のファイルだけで使う場合のディレクトリ構造、中央は最小限のファイルだけで使う場合の推奨形※3、右側は完全構成ZIPの全ファイルをUPする場合のディレクトリ構造です。
初めてお使いになる場合は、完全構成版のZIPの中身を全部アップロードして、上図の右端の「完全構成」にすることをお勧め致します。
※3：backupサブディレクトリはデータの自動バックアップのために必要で、imagesサブディレクトリは画像を投稿できるようにするために必要です。なので、この2ディレクトリだけは最小構成で使う場合でもある方が望ましいです。
アップロードしたファイルのパーミッション(アクセス権/属性)を下表のように設定して下さい。
お使いのウェブサーバで「suEXEC」という安全な仕組みが有効になっている場合は「suEXEC」側の値を設定しないと動かない可能性があります。
お使いのサーバの仕様が分からない場合は、下記の3ステップの考え方で試してみて下さい。
| ファイル名 | パーミッション | 補足 | |
|---|---|---|---|
| suEXEC※A | 一般の場合※B | ||
| ▼プログラムファイル | |||
| tegalog.cgi | 700 | 705 755 | メインCGI （これを実行します） ※0 |
| fumycts.pl | 600 | 604 644 | 補助プログラム （メインCGIから呼び出されます） |
| ▼データファイル（CGIによって書き換えられるファイル） | |||
| tegalog.xml | 600 | 606 666 | 投稿データ記録用ファイル（CGIによって編集されます） ※1,2 |
| tegalog.ini | 600 | 606 666 | 設定記録用ファイル（CGIによって編集されます） ※1,3 |
| psif.cgi | 600 | 606 666 | パスワード・セッションID格納ファイル（CGIによって編集されます） ※1,4 |
| ▼表示HTML関連ファイル | |||
| skin-cover.html | 604 644 ※たぶんデフォルトのままで可 | 表示用スキンファイル（テンプレートHTMLファイル：外側用） ※1 | |
| skin-onelog.html | 表示用スキンファイル（テンプレートHTMLファイル：内側用） ※1 | ||
| tegalog.css | 表示用スタイルシートファイル ※1,5 | ||
| ▼サブディレクトリ（※設置は任意） | |||
| backup | 705 | 707 777 | 自動バックアップファイルが蓄積されるディレクトリ ※6 |
| images | 705 | 707 777 | 投稿画像ファイルが蓄積されるディレクトリ ※6 |
| skin-* | 705 | 705 755 | 別スキンは「1スキン1サブディレクトリ」で置けます。 ※7 |
※A：suEXECという安全な仕組みが採用されているサーバでは、こちらの値を設定しないと正しく動かない場合があります。（特にディレクトリの値を「一般の場合」にはしないようご注意下さい。）
※B：ウェブサーバのヘルプをご参照頂き、サーバ側が要求する（推奨する）値があればそれに設定して下さい。そのような情報がないか分からない場合は、まずは「705」や「604」のように真ん中がゼロの値にしてみて下さい。それで支障がある場合には、「755」や「644」などの（真ん中がゼロではない）値の方をお試し下さい。
※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等の一般的な値のままで正しく動作します。その場合に777等に設定すると（主に画像表示の面で）正しく動作しなくなる可能性があります。
※7：ディレクトリ名は何でも構いません。必ずしも「skin-」で始まっている必要はありません。
➡ ここまで完了したら、もう動作するハズです。
ブラウザで tegalog.cgi にアクセスして表示を確認してみて下さい。
てがろぐをさらに複数個セットアップして併用する場合は、セットアップ方法ページの「CGIを複数個設置して併用する方法」もご覧下さい。
てがろぐ自身が「404 Not Found」エラーを出すことはありませんので、もし 404 Not Found エラーが見えたなら、それは100％ アクセスするURLが間違っている のが原因です。
※例えば、tegalog.cgi と同じ位置に dummy.html などのファイル名で適当なHTMLを置いてみて下さい。そのファイルにアクセスできないのなら、URLが間違っています。
You don't have permission to access this resource.）になる場合は、
Server unable to read htaccess file, denying access to be safe）になる場合は、
ディレクトリ内をこねくり回しすぎて何が何やら分からんわ……という場合は、一旦そのディレクトリを全部消して、もう一度（アップロードする前の）ディレクトリを新規作成するところからやり直してみることをお勧め致します。^^;
編集していない状態のファイルなら正常に動作する場合は、（編集したことで）改行コードが正しくなくなっている可能性があります。改行コードを明示して保存できるテキストエディタ（EmEditor等）を使って、改行コードは [LF] で保存して下さい。もしくは、FTPソフトの転送モードを「アスキーモード（テキストモード）」に設定してアップロードしてみて下さい。
てがろぐCGIの正常稼働を確認できた後は、下記の .htaccess ファイルを設置するなどして、Webからアクセスする必要のないファイルへのアクセスをブロックしておくことをお勧め致します。
てがろぐを設置したディレクトリには、下記の内容を含む .htaccess ファイルを設置することを推奨致します。（動作には必須ではありませんが、ある方が望ましいです。）
DirectoryIndex tegalog.cgi <FilesMatch "psif\.cgi$|\.pl$|\.ini$|\.xml$"> deny from all </FilesMatch>
上記ソースの .htaccess ファイルは、配布パッケージ（ZIPファイル）に含まれているほか、下記からダウンロードもできます。
(Recommend).htaccess のファイル名で含まれています。それを .htaccess にリネームしてお使い下さい。(Recommend).htaccess ファイルを .htaccess にリネームしてお使い下さい。
お使いの環境やお望みに合わせて、他の記述を加えたり書き換えたりしても問題ありません。
既に .htaccess ファイルがある場合は、上記の記述を追記すれば問題ありません。
tegalog.cgi 部分の記述をそのファイル名に書き換えて下さい。psif\.cgi 部分の記述をそのファイル名に書き換えて下さい（ドット記号は\.のように記述します）。
先に、てがろぐの正常稼働を確認してから
.htaccessファイルの中身に記述ミスがあると、設置したディレクトリ内全体へのアクセスが Internal Server Error になります。そのため、先にてがろぐCGIを設置して正常に動作することを確かめた上で、その後から .htaccess ファイルを置くことをお勧め致します。（そうしないと、エラーの原因がどこにあるのかを特定しにくくなりますから。）
WebサーバがApache互換ではない場合は、そもそも .htaccess ファイルによるアクセス制限ができない可能性があります。そのような環境でお使いの場合は、そのサーバに合わせた何らかのアクセス制限方法を使って下さい。
てがろぐはデータベースを使わない仕組みなため、あらゆるデータはファイルに記録されています。主に以下の3ファイルです。（ファイル名は変更することもできます。）
例えば、もし①のファイルをダウンロードできれば、すべての投稿本文が得られます。そこには、下書き状態の投稿本文、予約投稿で公開前の投稿本文、鍵付き状態の投稿本文など、Web上では表示対象外になっている本文も含めて、すべての投稿データが含まれています。 表示対象外になっている投稿が存在せず、すべてが公開済みであれば、このファイルをダウンロードされたところで特に不都合はありません。しかし、表示対象外になっている投稿が存在する場合は、ダウンロードされると困る場合もあるでしょう。 ①のファイルは単なるXMLファイルですから、（何も対策していなければ）ブラウザのアドレス欄にURLを正確に打ち込みさえすれば、誰でも表示(またはダウンロード)できてしまいます。
ここで、先に示した .htaccess ファイル等を使って適切にアクセス制限を施していると、たとえブラウザのアドレス欄にファイルのURLを正確に打ち込まれても、403 Forbidden エラーが表示されるだけで、ファイルは表示もダウンロードもできません。 それによって、見せたくない投稿本文（＝下書き状態、予約、鍵付き等のようにWeb上に公開されていない本文）が漏れてしまうのを防げます。
したがって、予約投稿、下書き、鍵付き(パスワード保護)投稿、プライベート動作などの「隠す系統の機能」を使いたい場合には、.htaccess ファイルの設置が必要です。 （※たとえ今は使っていなくても、将来的に使うかもしれないと考えるなら、先に設置しておく方が無難でしょう。）
なお、②のファイルをダウンロードできると、設定値がすべて分かります。それが問題になるかどうかは使い方次第ですが、見せる必要のないものは見えないようにしておく方が無難です。
また、③のファイルは絶対に第三者に閲覧されてはいけないファイルです（漏れると不正アクセスの原因になります）。
拡張子が .cgi なので、.htaccessによる制限がなくても表示・ダウンロードはできないハズですが、念のために.htaccessでアクセスを拒否しておく方が無難です。
画像保存用ディレクトリ（標準では images）には、キャプション等の画像情報を index.xml ファイルに記録しています。もし閲覧されると、画像ファイルの一覧、キャプション、フラグの設定状況などが分かります（閲覧されたところでおそらく問題はないでしょうが）。 .htaccess ファイルによるアクセス制限の影響範囲にはサブディレクトリも含まれますので、先の .htaccess ファイルを設置しておけば、この index.xml へのアクセスも拒否できます。
どうしても .htaccess ファイルを使えない何らかの理由がある場合は、データファイル名を tegalog.xml ではない名称に変更したり、設定ファイル名を tegalog.ini ではない名称に変更したり、バックアップ用ディレクトリ名を backup 以外に変更したりするなど、第三者が推測しにくい名称に変更しておく方が望ましいでしょう。ファイル拡張子をすべて .cgi にしてしまう手もあります。（これらのファイル名・ディレクトリ名は、tegalog.cgi ソースの冒頭付近で変更できます。）
個人情報などの「絶対に漏れてはいけない情報」を書きたい場合は、必ずBasic認証等の「サーバ側で提供されているアクセス制限・認証機能」を使って下さい。 てがろぐ単独の機能だけでそのようなクリティカルな情報を保護することはできません。 （てがろぐCGIそのものは、そこまで堅牢なシステムではありません。）
※基本的に、てがろぐ上で提供される何らかの「隠す」系統の機能はすべて「ネタバレ防止」程度の用途を想定したものです。
てがろぐには、複数のスキンをアップロードしておいて、別スキンを一時的に適用する(スキンを切り替える)機能があります。
その機能を使う場合は、「1スキン＝1サブディレクトリ」の階層構造でアップロードして下さい。ディレクトリ名は何でも構いません。
スキンファイルは、置き場所に応じて以下のように扱われます。
てがろぐVer 1.4.0以降には、CGIの管理画面上で本番適用スキンを切り替えられる機能があります。 しかし、本番適用するスキンはCGIと同じディレクトリにスキンファイルを置いておく方が、より高速に動作します。 使用するスキンが確実に決まった場合には、スキンファイルを物理的に移動しておくことをお勧め致します。
別スキンの適用方法やスキン内の各ファイルの役割については、カスタマイズ方法ページ内のスキンをカスタマイズする際に書き換えるファイルもご参照下さい。
配布ファイルの文字コードは、すべて UTF-8 になっています。
UTF-8コード以外での動作は想定していませんし実験もしていません。
文字コードは、UTF-8のままアップロードされることをお勧めしますが、他の文字コードを使用したい場合は、全ファイルを使用したい文字コードに変換した上でアップロードして下さい。一部のファイルだけ文字コードを変えると、文字化けが起こります。
（文字コードを変更した場合は、tegalog.cgi の68行目を適切に書き換える必要があります。）
よく分からない場合は、文字コードを変換せずUTF-8コードのままご使用下さい。
データファイル内には、サンプルデータが含まれています。 サンプルデータが不要なら（※当然不要でしょうが：^^;）最初に使用する際に管理画面上で削除して下さい。 もしくは、中身が空のデータファイル(tegalog.xml)を新しく作成してからアップロードしても構いません。しかし、ファイル自体のアップロードを省略すると、動作時にエラーになります。
最新版のCGI一式は、TOPページの「CGIのダウンロード」区画からダウンロードできます。
最新バージョンで新たに追加された機能や修正された不具合等の案内は、リリースノートでご覧頂けます。追加機能ごとに公式ヘルプ各ページへのリンクも用意していますので参考にして下さい。
てがろぐCGIの本体ファイルを1クリックだけで最新版にバージョンアップできるPHPスクリプト「TegUp」があります。 事前に tegalog.cgi と同じディレクトリに置いておけば、tegup.php にアクセスするだけで最新版の所在を確認し、最新版が公開されていればボタン1クリックで自動バージョンアップします。 ぜひ、ご活用下さい。 （※現在のところ、正式版へのバージョンアップにのみ対応しています。最新β版にバージョンアップする用途には使えませんが、既存のβ版から正式版へのバージョンアップには使えます。）
以前のバージョンをお使いの場合は、 tegalog.cgi と fumycts.pl の 2ファイルのみを上書きアップロードして下さい。
それ以外のファイルをアップロードする必要はありません。
特に、データファイル（tegalog.xml）を上書きしてしまうと、過去の投稿データが消えてしまいますので、くれぐれもご注意下さい。
また、tegalog.ini を上書きしてしまうと設定がリセットされてしまいますし、 psif.cgi を上書きしてしまうとパスワードが無効になってしまいます。
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 3.x系から Ver.4系 へのアップグレード時でも、データファイルや設定ファイルはそのまま引き継げます。
Ver 1.x系から一気に Ver.4系 へアップグレードする場合でも、データファイルや設定ファイルはそのまま引き継げます。
もし、配布されているスキンをそのまま利用している場合は、スキンファイル群も同時に上書きアップロードすれば、新しく加わった表示機能を簡単に活用できます。 スキンをカスタマイズして使っている場合は、上書きアップロードはしないようご注意下さい。その際は、新パッケージに含まれるスキンHTMLやCSSの中身を別途ご覧になりつつ既存スキンを編集すると、カスタマイズしやすいでしょう。
標準添付のスキンはいろいろありますが、スキンのHTMLやCSSソース内に最も詳しくコメントを書き添えてあるのは「標準スキン」です。 新しい機能に関する書き方を、ソースを読んで知ろうとする場合には、「標準スキン」のソースをご覧になることをお勧め致します。
もし自動バックアップ機能を有効にしている場合は、バックアップ蓄積ディレクトリの中に、直前までのデータファイルが存在します。
データが失われてしまった際には、バックアップ蓄積ディレクトリの中にある最新日付のファイルをダウンロードして、ファイル名を変更し、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://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ディレクトリのパーミッションの設定を 707 (777) や 706 (766) にしてしまっていることが原因です。705 や 755 などに変更して下さい。
「suEXEC」という安全な仕組みが有効のサーバでは、ディレクトリのパーミッションを誤って「一般の場合」の値に設定してしまうと、「画像投稿は完了するのに、画像が一切表示されない」という動作上の不具合が起こることがあります。 ディレクトリのパーミッションを正しく設定し直せば解決します。
suEXECという安全な仕組みが有効なサーバでは、サブディレクトリのパーミッションはデフォルトのまま（755など）で構いません。
ここで（全員に書き込み権限を付加する意味の）777 や 766 等にしてしまうと、そのサブディレクトリに格納されたあらゆるファイルは（安全のために）表示されなくなります。
その場合は、サブディレクトリのパーミッションを 705 や 755 に変更すると表示されるようになります。（さくらインターネットやロリポップでは 705 にして下さい。）
※お使いのサーバでどのような値に設定する必要があるのかは、レンタルサーバ別のセットアップ方法を用意していますのでそちらをご参照下さい。
※その一覧に存在しないレンタルサーバをお使いの場合、各ファイルのパーミッションの値については「設置方法3：パーミッションの設定」をご参照下さい。
構成ファイル群をアップロードしたハズなのに、ブラウザでアクセスすると「404 Not Found」や「403 Forbidden」のエラーが出てしまう場合は、tegalog.cgi にアクセスしているかどうかを確認して下さい。
「アップロード先のディレクトリ」と「URL」との関係を再度ご確認頂き、アップロードした場所を指し示すURLにアクセスできているかどうかをご確認下さい。
てがろぐ自身が「404 Not Found」エラーを出すことはありませんので、もし 404 Not Found エラーが見えたなら、それは100％ アクセスするURLが間違っている のが原因です。
※例えば、tegalog.cgi と同じ位置に dummy.html などのファイル名で適当なHTMLを置いてみて下さい。そのファイルにアクセスできないのなら、URLが間違っています。
自身で何らかの工夫をしない限り、「ディレクトリ名までのURL」にアクセスしても表示されません。
例えば https://ドメイン/tsubuyaki/ のディレクトリにアップロードした場合は、https://ドメイン/tsubuyaki/tegalog.cgi にアクセスする必要があります。
もし「ディレクトリ名までのURL」で動くようにしたい場合は、さらに『ファイル名「tegalog.cgi」を省略してアクセス可能にする方法』で説明している方法等を使う必要があります。 （この方法が使えない場合は、 tegalog.cgi を index.cgi に改名して使う手もあります。）
ロリポップのサーバ上で稼働させた場合で、（普段は普通に使えるのに）ある特定の種類の投稿後にだけ「403 Forbidden」になってしまう場合は、『ロリポップのサーバで投稿後に「403 Forbidden」になる場合の対策』をご覧下さい。
閲覧は問題ないのに、投稿や設定変更後にだけ「404 Not Found」になってしまう場合は、『投稿や設定変更操作をすると「404 Not Found」エラーになる場合』をご覧下さい。
CGIをアップロードした際に、「500 Internal Server Error」が表示されるだけで動作しない場合には、下記の点をチェックしてみて下さい。
なお、可能ならウェブサーバ側のエラーログファイルに何が記録されているかを参照すると、原因究明の参考になります。
バージョンアップ時には、tegalog.cgi と fumycts.pl の2つのファイルを必ずセットで上書きアップロードして下さい。
どちらか片方だけしか上書きしなかった場合は、Internal Server Error になる可能性があります。
そのほか、初回セットアップ時に必要だった各種操作（1行目の書き換えや、CGI本体に直接記述する系統の設定など）を忘れていないか、下記の「最初からInternal Server Errorになってしまう場合」項目を参考にしてみて下さい。
どうしてもエラーが解消しない場合は、試しに別のディレクトリに新規セットアップを試してみて下さい。それで動作するなら、バージョンアップの過程に何か問題があります。
FFFTP等の一部のFTPソフトには、ファイルの転送モードを選択する機能があります。（ファイルの改行コードを自動変換してくれる機能です。） 以下の条件によって転送モードを明示的に指定してアップロードしてみて下さい。
CGIソースを編集せずに、ZIPに含まれていた状態のままでアップロードする場合は、「バイナリモード」に設定してアップロードしてみて下さい。 ZIPに含まれているCGIソースは、改行コードが [LF] で作られています。多くのサーバでは、改行コードが [LF] である必要がありますから、バイナリモードでアップロードすれば確実です。
CGIソースを編集した場合は、さらに下記の条件によって転送モードを選んでみて下さい。
CGIソースの改行コードが、ウェブサーバ側の求める改行コード（＝たいていは [LF] です）と異なる場合には、実行すると Internal Server Error になります。
Windows環境で編集すると、改行コードは [CR]＋[LF] になる場合があります。なので、Windows環境で編集する場合は、保存時に改行コードを明示的に指定できるEmEditor等のテキストエディタを使う方が無難です。
要するに、
……という判断基準で試してみて下さい。
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の最新版をお使い下さい。
※お使いのサーバでどのような値に設定する必要があるのかは、レンタルサーバ別のセットアップ方法を用意していますのでそちらをご参照下さい。
CGI本体ファイルである tegalog.cgi の77行目付近には、my $howtogetpath = 2; という記述があります。
極々稀に、この値を 0、1、9 のどれかに書き換えないと正常に動作しないサーバがあります。（※ほとんどのサーバでは書き換える必要はありません。）
現在のところ、書き換える必要があると報告を受けているレンタルサーバは、mixhost と カラフルボックス だけです。
※お使いのサーバでどのような値に設定する必要があるのかは、レンタルサーバ別のセットアップ方法を用意していますのでそちらをご参照下さい。
ウェブサーバ側で指定されているパーミッションの設定方法が「一般の場合」か「suEXECの場合」かを確認して下さい。
suEXECという安全な仕組みが採用されているサーバでは、「suEXECの場合」に示したパーミッションを設定しないと動作しないことがあります。
（特に、ディレクトリに対してGroupやOtherへ書き込み権限を付与すると動作しません。） 設定値は、パーミッションの設定をご覧下さい。
※お使いのサーバでどのような値に設定する必要があるのかは、レンタルサーバ別のセットアップ方法を用意していますのでそちらをご参照下さい。
※その一覧に存在しないレンタルサーバをお使いの場合、各ファイルのパーミッションの値については「設置方法3：パーミッションの設定」をご参照下さい。
※suEXECの方がセキュリティ面で安全な仕組みなので、suEXECを採用しているサーバは多数あります。 さくらインターネット、ロリポップ、リトルサーバー、スターサーバー、WitchServer等々多々あります。
ローカル環境や自力でセットアップしたサーバ等で稼働させる場合には、必須のPerlモジュールがサーバにインストールされていない可能性があります。 CGIの設置環境要件の記述をご確認頂き、不足していればインストールして下さい。
※特に、レンタルサーバの mixhost の新サーバでは、必須モジュールがインストールされていません。 mixhostには、コントロールパネルからPerlモジュールをインストールする機能が提供されていますので、それを使ってインストールするして下さい。 詳しくは、「mixhostでの、てがろぐセットアップ手順」ページをご覧下さい。
権限の問題でサーバにモジュールをインストールできなくても、CGI本体と同じディレクトリにモジュールの構成ファイルを（ディレクトリ構造を維持したまま）設置する方法でも使えます。
その際には、tegalog.cgi の冒頭付近にある #use lib '.'; という記述行の先頭にある「#」記号を削除しないと読み込まれないので注意して下さい。
詳しい書き方は、CGI本体ファイルに直接記述する高度な設定群の「その他」項目もご参照下さい。
お使いのWebサーバにセットアップされているPerlのバージョンに問題がある場合もあります。 Perl 5でも、マイナーバージョン番号が古すぎる場合や新しすぎる場合には、何らかの原因で動作しないことがあります。 てがろぐCGIを動作させるには、Perl 5.6以上のバージョンが必要です。 もし、サーバのコントロールパネルからPerlのバージョンを選択可能なら、他のバージョンに変更してみて下さい。（ただし、Perlのバージョンを変更すると、Perlで動作する他のCGI等にも影響しますので充分ご注意下さい。）
動作確認に使っているPerlの詳細なバージョンは、配布パッケージ(ZIPファイル)に含まれている README.TXT ファイルの冒頭付近に記してあります。
どのような状況でエラーになるのか、直前の操作内容をお知らせ頂けると助かります。
可能ならウェブサーバ側のエラーログファイルに記録されている内容も参照してみて下さい。
新規にセットアップすると問題なく動作するのに、それと同じファイルを使ってアップデートしてもエラーが解消しない場合は、「500 Internal Server Error」エラーメッセージを、独自に用意したページに置き換えていないかどうかを確認して下さい。
お使いのWebサーバで「500 Internal Server Error」エラーメッセージを独自に用意したページに置き換えている場合に、URLが変わる形で転送してしまっていると、エラーが解消しないように見えることがあります。（その場合は、ブラウザのキャッシュをクリアしたり、別のブラウザを使ったりすれば、正しく見えます。）
これは、.htaccessファイルの記述が望ましくない形になっているためです。
独自エラーページへ(301で)転送すると、転送先URLをブラウザが記憶するため、次回以降のアクセス時には「直接エラーページを見に行く」ようになってしまい、エラーが解消されてもエラーページしか見えなくなります。
この現象を解消するには、独自エラーページへの転送を止めるのが最も簡単です。ただし、設定を削除してもブラウザのキャッシュは消えないため、ブラウザのキャッシュをクリアする作業も必要です。（あなた自身だけでなく、一度でもエラーページを見てしまった閲覧者は全員キャッシュをクリアしない限り、エラーページしか見えない状態になります。）
エラーページを独自に用意する場合は、転送せずに内容だけを置き換えるように（＝エラーページが見えている場合でもURLは元のまま変わらないように）するのが無難です。
てがろぐCGIをロリポップのサーバ上で稼働させた場合にエラーになる場合は、下記の点もご確認下さい。
まずは、てがろぐ Ver 3.7.0 以降のバージョンをお試し下さい。
もしそれでも解決しない場合や、どうしても Ver 3.6.x 以下のバージョンを使う必要がある場合は、
てがろぐ本体（tegalog.cgi）をテキストエディタで開いて、1行目にある記述を
#! /usr/local/bin/perl のように修正する必要があります。
ロリポップのサーバ上で稼働させている場合に、投稿本文の中に /etc/abcd のような半角9文字を含めて送信(投稿)すると、サーバに拒否されて「403 Forbidden」エラーが出る問題が分かっています。
abcdの部分は英字4文字以上なら何でもエラーになるようです。（そのほかにも何らかのNGワードがあるかもしれません。）
この謎仕様はロリポップ側の問題なので、てがろぐCGI側で直接どうにかすることはできません。
対処方法として、Ⓐサーバ側の設定でどうにかする方法と、Ⓑてがろぐ側でNGワードを避ける方法とを以下に紹介しておきます。
ロリポップのサーバのうち、先頭が「spd」か「ent」ではないサーバをお使いの場合は、.htaccessファイルを使ってWAFの設定を加えることで対処できるようです。対象サーバをご使用なら、以下の方法を試してみて下さい。 下記は、ロリポップをご利用のユーザさんからご提供頂いた情報です。
シグネチャで除外設定する
コードの確認は、WAF設定のログ参照から確認する必要があります。 また私の環境ではてがろぐで投稿しWAFでエラーが出た場合、 1つ目のコードを除外設定した後にもエラーが発生しましたが、 ログ参照し、2つ目のコードも除外設定する事で回避出来ました。 なので、複数のコードを除外する必要があるようです。コード例：
# AAA-11,BBB-12を確認したコードに変更
SiteGuard_User_ExcludeSig AAA-11
SiteGuard_User_ExcludeSig BBB-12
IPアドレスで除外設定する
IPアドレスが固定なら、この方法が楽かもしれません。コード例：
# カッコ内のxxx.xxx.xxx.xxxをご自身のIPアドレスに変更
SiteGuard_User_ExcludeSig ip(xxx.xxx.xxx.xxx)
この2つのどちらかを.htaccessに記述すれば、
/etc/abcdのような文字列でも問題なく投稿できました。 ロリポップをお使いで403エラーにお困りの場合は、お試しください。
また、ロリポップ公式ヘルプの「PHPやCGIでプログラムの記述変更をしたところ403errorが表示されます」ページも併せてご参照下さい。
上記の方法が採れないサーバをご使用の場合等は、てがろぐ側でNGワードを避ける以下のような方法もありますのでお試し下さい。
/etc/abcd という連続した9文字の投稿が無理でも、先頭1文字を太字装飾にして [B:/]etc/abcd のようにするとNG判定に引っかからなくなるので投稿できます。
この方法だと先頭のスラッシュ記号が太字になってしまいますが、例えば自由装飾記法を使って [F:hogehoge:/]etc/abcd のようにすると、
意味のないHTMLタグで囲まれるだけなので、表示上は「 /etc/abcd 」という何も装飾されていない文字として見えます。
https://www.example.com/etc/image.png のように、Web上に存在するetcディレクトリの中にあるファイルを参照したい場合などでも、そのまま投稿すると403エラーになってしまいます。
これを避けるには、例えば以下の方法があります。
/sonota/filename というパスを書けば、実際には /etc/filename を参照できることになります。
UNIX系OSでは /etcディレクトリに各種設定ファイルがありますから、おそらくそのようなファイルがWebフォームから参照されてしまわないようにするための対策なのでしょうけども。
ちょっどざっくり過ぎる（強引すぎる）対策な気がします……。
そのほかに解決する方法を発見された場合は、ぜひお知らせ下さい。
投稿時や設定変更時に「CGIの設置ドメインとは異なる場所からデータが送信されました」というエラーが表示されてしまう場合は、以下の方法をお試し下さい。
その上でも同様のエラーが表示される場合には、そのときエラー画面に表示されている内容をコピーして、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」エラーが出てしまう場合は、てがろぐCGI側が自身の所在を正しく認識できていないことが原因です。 その場合は、CGI本体ファイルに直接記述する高度な設定群の「その他」項目にある「$howtogetpath」の値を0、1、9などに変更してみて下さい。
レンタルサーバの「カラフルボックス」では、この値を「0」にしないと正しく動作しないと報告を受けています。
ログインしているハズなのに、管理画面TOPを再度表示しようとするとログインフォームが見えてしまう場合や、ログインしたハズなのに再度ログイン画面が見えてしまう場合は、キャッシュが効き過ぎている可能性があります。 管理画面TOPのURLと、「非ログイン状態から管理画面のTOPにアクセスしようとしたときのログイン画面」のURLが同じなので、ログイン画面が表示された時点でキャッシュされてしまうと、管理画面TOPが見えなくなります。
この場合には、ブラウザやサーバのキャッシュ設定を見直してみて下さい。サーバによってはデフォルトで強力なキャッシュが設定されているかもしれません。
Ver 3.5.0以降では、管理画面の表示時にはキャッシュが効き過ぎないようにするヘッダ「cache-control: no-cache」を出力するようになりました。古いバージョンを使っている場合は、Ver 3.5.0以降にバージョンアップしてみて下さい。
普段お使いのブラウザ以外のブラウザでもログインを試してみて下さい。それでうまくいくなら、お使いのブラウザのキャッシュ設定が強すぎる可能性があります。 他のブラウザでも同様の問題が発生する場合は、サーバ側のキャッシュ設定が強すぎる可能性があります。
レンタルサーバのロリポップでこの問題が発生する場合は、ロリポップアクセラレータを無効に設定してみて下さい。
最新版の tegalog.cgi と fumycts.pl をアップロードしたのに、Web上のてがろぐがバージョンアップされておらず旧バージョンのままに見える場合は、下記の4点をご確認下さい。
なお、tegalog.cgi は index.cgi に改名しても動作しますが、そうしなくても、.htaccessファイルに1行書いておくだけで、ファイル名は tegalog.cgi のままで「 / 」で終わる短いURLでアクセス可能にできます。 詳しくは、わざわざファイル名を index.cgi に変更しなくても、「/」で終わるURLでアクセスできるようにする方法をご覧下さい。
もし、tegalog.cgi と間違えて psif.cgi ファイルを上書きしてしまった場合は、以下のような動作になってしまいます。
➡ てがろぐのバージョンは変わらないままで、ログインパスワードだけが無効になる。
こうなってしまった場合、採れる対処は下記の2点です。
もし、tegalog.cgi と間違えて tegalog.xml ファイルを上書きしてしまうと、投稿データが消えます。
もし、tegalog.cgi と間違えて tegalog.ini ファイルを上書きしてしまうと、設定データが消えます。
これらの場合は、バックアップから復元することで対処できます。
投稿データ(tegalog.xml)は、自動バックアップ機能を有効に設定しているなら backup ディレクトリにバックアップされていますから、そこにあるファイルを使って復元できます。
設定データは、自力でバックアップファイルをローカルに保管していればそれを使って復元できます。
復元方法は、使い方・設定方法ページの「バックアップから復元する方法」をご覧下さい。
てがろぐCGIをバージョンアップする方法は、「CGIの更新方法」で説明していますのでご参照下さい。
てがろぐのバージョン番号は tegalog.cgi ファイル(だけ)によって決定されます。なので、tegalog.cgi ファイルを上書きすれば、絶対にバージョン表記の数値は上がります。 「上書きしたハズなのにバージョンが上がらない」という場合は、このファイルが実際には上書きできていない（＝操作者の勘違い）か、またはキャッシュが効き過ぎている（＝過去の状態が見えたまま）か、上書き用に用意したファイル自体が古いか、のどれかです。
埋め込み合成用のスキンを使った表示結果を、SSIやPHPなどを使って他ページに合成している場合では、画像やハッシュタグリンクなどのリンク先が(相対パスで出力されるために)リンク切れになってしまう可能性があります。 その際は、下記の設定項目（黄色矢印部分と水色矢印の部分）にチェックを入れておくと、それぞれが絶対URIで出力されるようになるため、リンク切れにならずに済みます。
出力結果を別ページに埋め込む際の設定方法（注意点）には他にも少々ありますので、詳しくは、あるスキンの出力結果を別のページに埋め込む方法をご覧下さい。
※複数のスキンを併用しているなど、『一時適用中のスキンを維持できるリンクを出力する』のチェックを外す方法を避けたいなら、JavaScriptを使ってリンク先URLを動的に編集する方法もあります。詳しくは上記ページをご覧下さい。
てがろぐCGIは、HTTPS環境でも問題なく動作します。 もし、SSL証明書を導入してHTTPS化したにもかかわらず、ブラウザのアドレス欄に緑色の錠前アイコン(🔒)ではなく黄色の警告アイコン(⚠)が表示されてしまう場合は、表示ページ内のどこかでHTTP決め打ち（ http://～ のURL）の画像などが読み込まれている可能性があります。 特に、『ユーザアイコンのURLが「http://～」で書かれている』というケースが散見されますので、ぜひご確認下さい。
HTTPSアクセス時に黄色の警告アイコンが出る場合は、たいてい以下の理由です。
ページに埋め込む画像をURLで指定する場合に、https://～ ではなく http://～ で書いてしまうケースはよくあります。 てがろぐの場合、特にユーザアイコンの設定は見落とされがちな気がします。 ユーザアイコンは、管理画面の「ユーザIDを管理」からユーザ別に設定できます。
ユーザアイコンのURLは https:// から書かなくても、「/」で始まる絶対パスで書くこともできますし、CGI本体の設置場所を基準にした相対パスで書くこともできます。
また、CGI本体と同じディレクトリに画像ファイルを置いているなら、単に画像ファイル名を書くだけでも表示可能です。
※ユーザアイコンは、CGIの存在する位置からの相対パスで指定するか、サーバルートからの絶対パスで指定するのがお勧めです。
パスワードを忘れてしまった場合は、以下の2通りの対処方法があります。
管理者権限を持つIDが他にある場合は、そのIDでログインしてから、管理画面の「ユーザIDを管理」にアクセスして、目的のユーザIDの設定画面を表示させて下さい。
すると「パスワードリセット」枠が見えますので、そこから新しいパスワードに強制変更できます。
※管理者でも既存のパスワードを知ることはできませんが、任意のパスワードへの強制変更はいつでもできます。
※パスワードを忘れたIDが管理者権限を持つIDでも、それ以外に管理者権限を持つ別のIDがあれば、そのIDでログインしてから目的のIDのパスワードを変更できます。
管理者権限を持つIDのパスワードを忘れてしまった場合は、サーバ上にある「パスワード・セッションID格納ファイル」（＝デフォルトでは psif.cgi ファイル）の中身を空にして上書きアップロードして下さい。
すると、無条件ログインができるようになります。（その際のログイン画面には、図のように無条件ログインが可能なことを示すメッセージ枠が表示されます。(※Ver 4.2.4以降)）
その後、管理画面の「ユーザIDを管理」からパスワードを再設定して下さい。
この場合、全ユーザのパスワードが未設定状態に戻りますのでご注意下さい。
一時的に誰でも無条件ログインができる状態になりますから、ディレクトリ全体に一時的にBASIC認証を加えるなどの安全策を施してから作業することをお勧め致します。
※パスワードが消えるだけで、それ以外のユーザ情報は消えません。正確には、以下の3種類の情報だけが消えます。
※パスワードはハッシュ化されて保存されているため、ファイルの中身を覗いてもパスワードは分かりません。（※だからといって第三者に開示して良いわけではありません。
特に、このファイルにはセッションIDも記録されていますので、常に外部から閲覧されないようにしておく必要があります。）
※ファイルの中身を空にする操作ができない場合は、てがろぐのパッケージ（ZIP）内に含まれている、初期状態の psif.cgi ファイルを上書きアップロードする方法でも構いません。
他に管理者が存在しない状態では、既存の管理者IDを削除することはできない（＝管理者権限を持つIDの数を0個にはできない）ような仕様にしているつもりですが、何らかのトラブルで管理者権限を持つIDが1つもなくなってしまった場合は、下記の手順で既存IDに管理者権限を付与することができます。
userids= という文字列で始まる行の存在が見えるハズです。この行を探して下さい。
このファイル内はアルファベット順にソートされていますので、一旦ファイルの一番下までスクロールしてから上へ向かって探す方が早いです。（もちろん、テキストエディタの検索機能をお使い頂くのでも良いです。）userids= で始まる行の存在は1つだけです。）
userids=skaura<>1<>さくら<>.........
userids=skaura<>9<>さくら<>.........
上記の手順でご操作頂くと、再度管理画面にアクセスしたときには、ユーザ「さくら(sakura)」の権限が管理者権限(Lv.9)になっているはずです。
ユーザIDの権限を変更したり、ユーザIDそのものを削除したりしても、そのユーザIDを使って過去に投稿された投稿はすべてそのまま残っています。 てがろぐでは、IDを消しても投稿は消えません。（名無しの投稿として扱われるようになるだけです。その場合、元のID名でIDを新規作成すれば、元通りの紐付けに戻ります。）
上記の手順で管理者権限は付与できるはずですが、編集箇所を誤ってしまったり、前後の記号を削除してしまったりした場合は、ユーザIDが正しく認識されなくなる可能性があります。 どうしても解決できない場合は、次の手順でユーザIDすべてをリセットし、「管理者権限を持つID『admin』1つだけが存在する初期状態」に戻すことができます。
※この場合でも、既存の投稿はすべて残ったままですのでご安心下さい。（IDを消したりリセットしたりしても、過去の投稿が消えることはありません。）
userids= という文字列で始まる行の存在が見えるハズですので、その行を探して下さい。userids=の部分も含めて1行全部を消し去って下さい。）上記の手順でご操作頂くと、再度管理画面にアクセスしたときには、管理者権限を持つユーザID「名無し(admin)」だけが存在する初期状態に戻っています。
もし、adminにパスワードが掛けられている場合は、ご自身で初回にセットアップした際に admin に対して設定したパスワードでログインできます。 そのパスワードが分からない場合は、さらにパスワードを忘れてしまった場合の対処方法も併せて使って下さい。
既存のユーザIDをすべて消してしまっても、過去の投稿はすべて残っています。 投稿者名は一時的に「名無し」等のデフォルト名での表示に変わりますが、あくまでも一時的なものです。 各投稿とIDとの紐付け情報は残ったままですので、 過去に使っていたID名と同じID名で新しくIDを作れば、元通りの表示・元通りの紐付け状態に戻せます。
にっちもさっちもいかなくなった場合は、作者までお問い合わせ下さい。 その際は、発生している問題の詳細、設置場所(URL)、お使いのサーバ会社名など、できるだけ詳しい情報をお知らせ頂けると、話が早く進みます。 サーバのエラーログがあるととても望ましいです。
1つ1つを異なるディレクトリにアップロードして下さい。例えば以下のような感じです。
ディレクトリ名は何でも構いません。要は、「1つのてがろぐ＝1ディレクトリ」で構成されていれば問題ありません。
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を複数個設置しているときに、それぞれを区別しやすくする方法を2つ用意しています。
管理画面の配色(カラーテーマ)を切り替える機能があります。 複数のてがろぐCGIを併用する際に、どれを使っているのか迷わないよう色分けする用途にもご活用頂けます。 あくまでも管理画面のUI配色を選択するだけであって、ページの表示（スキン）には一切影響しません。
Ver 3.5.0以降では、下記の7テーマから選択できます。（Ver 2.7.0～3.4.0では、最初の4テーマのみから選択できます。）
ここで設定したカラーテーマは、ログアウト状態でも適用されます。（WordPressのようにログインユーザごとに適用されるわけではなく、ログインしているかどうかに関係なく全員共通の配色として表示されます。）
ブラウザのタブ（タイトルバー）で識別できるように、タイトル先頭に任意の識別名を挿入する機能もあります。 ここで指定した識別名は、管理画面では常時左上に表示されるほか、ブラウザのタイトルバー先頭にも（管理画面が表示されている状況では）常時表示されます。 あくまでも管理画面で「そのてがろぐの用途」を識別しやすくするための機能であって、ページの表示（スキン）には一切影響しません。
設定場所は、管理画面の［設定］→［システム設定］→【管理画面内の表示】→『管理画面のタイトル先頭に挿入される識別名』項目です。
同一ブラウザの複数のタブで、別々のてがろぐCGIを同時に使っている場合に、それぞれを区別しやすくするためのニッチな機能です。^^;
てがろぐCGIでは、すべての設定データは同一ディレクトリ内に存在します。他のデータベース等は利用していません。 したがって、ディレクトリを丸ごと消すだけで削除（アンインストール）が完了します。 てがろぐCGIが不要になった場合は、単にディレクトリごと全部消して下さい。
ディレクトリ内の全ファイルをダウンロードして保管しておけば、再開したくなったときには再度アップロード（してパーミッションを適切に設定）するだけで、いつでも復活させられます。
てがろぐ上で投稿した本文は、データファイル tegalog.xml 内にXMLっぽいテキスト形式で記録されています。 投稿内容を他のツールに流用したい場合には、この tegalog.xml ファイルをテキストエディタ等で開くと楽に作業できるかもしれません。
てがろぐCGIでは、すべての設定データは同一ディレクトリ内に存在します。他のデータベース等は利用していません。 したがって、ディレクトリを丸ごとコピーするだけで移転は完了します。 具体的には以下のような手順で操作すると良いでしょう。
以上で、引っ越しは完了します。
※注：稀に、パスワードの再設定が必要になるケースがあります（使用可能なハッシュ化方式が新旧サーバで異なる場合）。 もし、移転先で（パスワードが異なるというエラーで）ログインできない場合は、psif.cgiファイルの中身を空っぽにして上書きUPし、パスワードを再設定して下さい。 その場合は、鍵付き投稿機能で使うパスワード「共通鍵」も再設定が必要です。
※「psif.cgiファイルの中身を空っぽにする」という操作がよく分からない場合は、配布パッケージに含まれている初期状態の psif.cgi ファイルを使って上書きアップロードして下さい。
補足情報として、FAQ・豆知識ページの「仮設置場所から本番設置場所へ移動するなど、サーバを引っ越す場合はまるごと移動するだけでOK」もご覧下さい。
もし必要があれば、tegalog.cgi の中身をテキストエディタで読み込んで、下記の通りに書き換えられます。
※fumycts.pl側には書き換える項目はありません。
※デフォルトの状態で使用するのであれば、（1行目以外は）まったく書き換えなくても動きます。
▼Perlの位置
▼基本設定
▼オプション設定
▼その他
特に必要がなければ、何も変更せずにお使い頂くことをお勧め致します。上記以外の各種設定は、ブラウザ上で管理画面から変更できます。
