動作要件はとても緩いので、たいていのウェブサーバでは何も気にせず8ファイルをアップロードするだけで使える場合も多そうな気がします。
Perl5さえ使えればたいてい動作します。データベースは不要です。
お手軽マイクロブログCGI「てがろぐ」のセットアップ方法です。お使いのサーバに設置する手順を解説しています。
手順と言っても単に全ファイルをアップロードして、パーミッションを設定するだけです。
《最終更新： 2020年10月01日 》
動作要件はとても緩いので、たいていのウェブサーバでは何も気にせず8ファイルをアップロードするだけで使える場合も多そうな気がします。
Perl5さえ使えればたいてい動作します。データベースは不要です。
当サイトは、「さくらインターネット」のサーバ上で公開されています。
てがろぐCGIの動作テストも、さくらインターネットのサーバで実施しています。さくらインターネットをお使いなら、何も書き換えることなくそのままアップロードしてパーミッションを正しく設定すれば動きます。
ZIPを展開したファイルの内、説明用の「README.TXT」ファイルを除く8個のファイルを、同一のディレクトリにアップロードして、下表に記したパーミッション(アクセス権/属性)に設定するだけです。 ただし、サーバによっては、てがろぐCGI本体（tegalog.cgi）の1行目を、サーバ側が要求するように事前に書き換えておく必要があります。
したがって、セットアップ手順は下記の3ステップだけです。
これだけで動作します。
最近のウェブサーバなら、おそらく特に何も書き換えずにそのままアップロードするだけで動くことが多いです。
しかし、お使いのサーバによっては、CGIの1行目にある#! /usr/bin/perlの記述だけをサーバ環境に合わせて例えば#! /usr/local/bin/perlなどに書き換える必要があります。
もし書き換える必要があれば、tegalog.cgi をテキストエディタで開いて、1行目をサーバ会社が指定する通りに書き換えて下さい。
よく分からない場合は、とりあえず、まずは書き換えずにそのままアップロードして試してみて下さい。
書き換える必要がなければそのまま動作します。書き換える必要がある場合には「500 Internal Server Error」になります。
例えば、
#! /usr/local/bin/perlに書き換える必要があるサーバがあります。
説明用の「README.TXT」ファイルを除くすべてのファイルを任意のディレクトリにアップロードして下さい。
その際、FTPソフトの設定は「アスキーモード」（テキストモード）にして下さい。
設置後のディレクトリ構造は下図のようになります。
自由に作成したサーバ上のディレクトリへ、必要なファイルをアップロードすれば良いだけです。サブフォルダも含めてアップロードする場合は、フォルダ構造(階層構造)を維持したままアップロードして下さい。
図の左側は最小限のファイルだけで使う場合のディレクトリ構造、中央は最小限のファイルだけで使う場合の推奨形態、右側は完全版の全ファイルをUPする場合のディレクトリ構造です。 （※backupサブディレクトリはデータの自動バックアップのために必要で、imagesサブディレクトリは画像を投稿できるようにするために必要です。なので、この2ディレクトリだけは最小構成で使う場合でもある方が望ましいです。）
※FTPソフトでアップロードする際に、転送モードが「バイナリモード」になっていると、CGIソース内の改行コードが正しく変換されないために、ブラウザでは「500 Internal Server Error」が表示される場合があります。 その場合は、FTPソフトの設定を確認してみて下さい。
※FTPソフトを使わずに、Webサーバのコントロールパネルからファイルをアップロードすると、バイナリモードでアップロードすることになってしまい、うまく動作しないことがあります。 その場合は、FFFTPなどのFTPソフトを使ってアップロードして見て下さい。 （どうしてもそのようなソフトウェアが利用できない場合は、一旦 tegalog.cgi と fumycts.pl をテキストエディタで読み込み、改行コードをお使いのWebサーバに合わせて変更した上で上書き保存し、アップロードして下さい。）
アップロードしたファイルのパーミッション(アクセス権/属性)を下表のように設定して下さい。
※レンタルサーバの「さくらインターネット
」や「ロリポップ！
」に設置する場合は、「suEXEC」側のパーミッションに設定して下さい。
お使いのウェブサーバで「suEXEC」という安全な仕組みが有効になっている場合は「suEXEC」側の値を設定しないと動かない可能性があります。（特にディレクトリの設定は絶対ですので気をつけて下さい。）
| ファイル名 | パーミッション 一般の場合 / suEXEC | 補足 | |
|---|---|---|---|
| ▼プログラムファイル | |||
| tegalog.cgi | 755 | 700 | メインCGI （これを実行します） ※0 |
| fumycts.pl | 644 | 600 | 補助プログラム （メインCGIから呼び出されます） |
| ▼データファイル（CGIによって書き換えられるファイル） | |||
| tegalog.xml | 666 | 604 | 投稿データ記録用ファイル（CGIによって編集されます） ※1,2 |
| tegalog.ini | 666 | 604 | 設定記録用ファイル（CGIによって編集されます） ※1,3 |
| psif.cgi | 666 | 600 | パスワード・セッションID格納ファイル（CGIによって編集されます） ※1,4 |
| ▼表示HTML関連ファイル | |||
| skin-cover.html | 644 | 604 | 表示用スキンファイル（テンプレートHTMLファイル：外側用） ※1 |
| skin-onelog.html | 644 | 604 | 表示用スキンファイル（テンプレートHTMLファイル：内側用） ※1 |
| tegalog.css | 644 | 604 | 表示用スタイルシートファイル ※1,5 |
| ▼サブディレクトリ（※設置は任意） | |||
| backup | 766 | 705 | 自動バックアップファイルが蓄積されるディレクトリ ※6 |
| images | 766 | 705 | 投稿画像ファイルが蓄積されるディレクトリ ※6 |
| skin-* | 755 | 705 | 別スキンは「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サブディレクトリ」の階層構造でアップロードして下さい。ディレクトリ名は何でも構いません。
スキンファイルは、置き場所に応じて以下のように扱われます。
てがろぐVer 1.4.0以降には、CGIの管理画面上で本番適用スキンを切り替えられる機能があります。 しかし、本番適用するスキンはCGIと同じディレクトリにスキンファイルを置いておく方が、より高速に動作します。 使用するスキンが確実に決まった場合には、スキンファイルを物理的に移動しておくことをお勧め致します。
別スキンの適用方法やスキン内の各ファイルの役割については、カスタマイズ方法ページ内のスキンをカスタマイズする際に書き換えるファイルもご参照下さい。
配布ファイルの文字コードは、すべて UTF-8 になっています。
UTF-8コード以外での動作は想定していませんし実験もしていません。
文字コードは、UTF-8のままアップロードされることをお勧めしますが、他の文字コードを使用したい場合は、全ファイルを使用したい文字コードに変換した上でアップロードして下さい。一部のファイルだけ文字コードを変えると、文字化けが起こります。
（文字コードを変更した場合は、tegalog.cgi の68行目を適切に書き換える必要があります。）
よく分からない場合は、文字コードを変換せずUTF-8コードのままご使用下さい。
データファイル内には、サンプルデータが含まれています。 サンプルデータが不要なら（※当然不要でしょうが：^^;）最初に使用する際に管理画面上で削除して下さい。 もしくは、中身が空のデータファイル(tegalog.xml)を新しく作成してからアップロードしても構いません。しかし、ファイル自体のアップロードを省略すると、動作時にエラーになります。
最新版のCGI一式は、TOPページの「CGIのダウンロード」からダウンロードできます。
以前のバージョンをお使いの場合は、 tegalog.cgi と fumycts.pl の2つのファイルのみを上書きアップロードして下さい。
それ以外のファイルをアップロードする必要はありません。
特に、データファイル(tegalog.xml)を上書きしてしまうと、過去のデータが消えてしまいますので、くれぐれもご注意下さい。
なお、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と同じディレクトリにアップロードすれば（バックアップされた時点のデータが）回復します。
てがろぐ本体を置いたディレクトリに「.htaccess」ファイルを用意して以下の1行を書いておけば、わざわざ「tegalog.cgi」のファイル名を「index.cgi」に修正しなくても、「/」で終わるURLでアクセスできます。
DirectoryIndex tegalog.cgi
この場合、実体の位置は https://www.example.com/memo/tegalog.cgi でも、 https://www.example.com/memo/ という「/」で終わるURLだけで表示できます。
SSL証明書を導入してHTTPS化したにもかかわらず、ブラウザのアドレス欄に「緑色の錠前アイコン」ではなく「黄色の警告アイコン(⚠)」が表示される場合には、 『ユーザアイコンのURLが「http://～」で書かれている』というケースが散見されますので、ぜひご確認下さい。
HTTPSアクセス時に黄色の警告アイコンが出る場合は、たいてい以下の理由です。
ページに埋め込む画像をURLで指定する場合、https://～ ではなく http://～ で書いてしまうケースはよくあります。てがろぐの場合、特にユーザアイコンの設定は見落とされがちな気がします。(^_^;)
ユーザアイコンは、管理画面の「ユーザIDを管理」からユーザ別に設定できます。(※ユーザアイコンは、CGIの存在する位置からの相対パスで指定するか、サーバルートからの絶対パスで指定するのがお勧めです。)
tegalog.cgiファイルのあるディレクトリにアイコン画像ファイルが置いてあれば、ユーザアイコンURLの指定欄には画像ファイル名を書くだけで表示できます。（サブディレクトリに置いてある場合は、相対パスで指定できます。）
投稿画像を蓄積するためのimagesサブディレクトリのパーミッション設定が誤っていないかどうかを確認してみて下さい。
例えば、「suEXEC」という安全な仕組みが有効のサーバで、ディレクトリのパーミッションを誤って「一般の場合」の値に設定してしまうと、「画像投稿処理は完了できるのに、画像が一切表示されない」という動作上の不具合が起こります。（パーミッションを正しく設定し直せば解決します。）
CGIをアップロードした際に、「500 Internal Server Error」が表示されるだけで動作しない場合には、下記の点をチェックしてみて下さい。
なお、可能ならウェブサーバ側のエラーログファイルに何が記録されているかを参照すると、原因究明の参考になります。
バージョンアップ時には、tegalog.cgi と fumycts.pl の2つのファイルを必ずセットで上書きアップロードして下さい。
どちらか片方だけしか上書きしなかった場合は、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等にも影響しますので充分ご注意下さい。）
どのような状況でエラーになるのか、直前の操作内容をお知らせ頂けると助かります。
可能ならウェブサーバ側のエラーログファイルに記録されている内容も参照してみて下さい。
お使いのWebサーバで「500 Internal Server Error」エラーメッセージを、独自に用意したページに置き換えている場合に、URLが変わる形で転送してしまっていると、エラーが解消しないように見えることがあります。（その場合は、ブラウザのキャッシュをクリアしたり、別のブラウザを使ったりすれば、正しく見えます。）
これは、.htaccessファイルの記述が望ましくない形になっているためです。
独自エラーページへ(301で)転送すると、転送先URLをブラウザが記憶するため、次回以降のアクセス時には「直接エラーページを見に行く」ようになってしまい、エラーが解消されてもエラーページしか見えなくなります。
この現象を解消するには、独自エラーページへの転送を止めるのが最も簡単です。ただし、設定を削除してもブラウザのキャッシュは消えないため、ブラウザのキャッシュをクリアする作業も必要です。（あなた自身だけでなく、一度でもエラーページを見てしまった閲覧者は全員キャッシュをクリアしない限り、エラーページしか見えない状態になります。）
※エラーページを独自に用意する場合は、転送せずに内容だけを置き換えるように（＝エラーページが見えている場合でも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とパスワードをコピー(流用)して使うことは可能です。
（※同時にその他の設定も引き継がれます。識別文字列も引き継がれるため、セットアップ後に修正が必要です。また、日付別カウント数・ハッシュタグカウント数・カテゴリカウント数なども引き継がれてしまうため、その方法でセットアップした場合は、セットアップ後に一度だけ管理画面から「投稿の再カウント」を実行する方が良いでしょう。）
もし必要があれば、tegalog.cgi の中身をテキストエディタで読み込んで、下記の通りに書き換えられます。
※fumycts.pl側には書き換える項目はありません。
※デフォルトの状態で使用するのであれば、1行目以外、まったく書き換えなくても動きます。
▼Perlの位置
▼基本設定
▼オプション設定
▼その他
特に必要がなければ、何も変更せずにお使い頂くことをお勧め致します。上記以外の各種設定は、ブラウザ上で管理画面から変更できます。
