ファーストサーバ

ディレクトリごとリダイレクトする方法は過去の記事にも書いてますし、ググれば比較的すぐに見付かります。

一応書いとくと、

Redirect permanent /old/ http://www.btmup.com/new/

こんな感じですね。
「/old/」がリダイレクト元、「http://www.btmup.com/new/」がリダイレクト先です。

ただ、これだとリダイレクト先までディレクトリになってしまって、特定のページへピンポイントでリダイレクトさせることができません。
続きを読む

メモ的エントリー。
タイトルのまんまです。

Web ページを表示するときには、まず HTML やら CSS やら JavaScript やら 画像やらをダウンロードする必要があります。
それら各ファイルを圧縮することで転送量を小さく抑え、結果的にパフォーマンス向上（時間短縮）に繋げましょう、というお話。
ページのつくりにもよりますが、70～80% くらいフツーに圧縮されちゃいます。強力。

自宅サーバーや専用サーバーを使ってる場合は Apache の設定を直接いじることも可能ですが、今回はとりあえずパス。
httpd.conf あたりを触ることになるんでしょうけど。

あと、「gzip」とは何ぞや、というのも、正直よく分かりません。
昔から使われてるし一番普及してるし圧縮率も高いし使用制限とかもフリーだし標準化もされてるし、っていう感じなので、あまり深く考えず乗っかった方が良さげかな、と。
続きを読む

SOY CMS でサイトを制作して、ドメイン直下にページを公開したい場合は「ルート設定」をします。
その意味や方法についてはマニュアルを見ていただくとして、今回のテーマは「ルート設定からの逃れ方」。

サーバーによっては、コントロールパネル（管理画面、以下「コンパネ」）がサイトと同じ階層（FTPで見えるところ）にあったり、全然別のURLなのにあたかも同じサーバーに乗っかってるような設定になっているところがあります。
（すんません。何を書いてるか自分でもよく分からないんですが、同じ状況になった人なら分かってくれると思います。たぶん）

で、そんな場合に SOY CMS のルート設定をすると、コンパネにアクセスできなくなったりすることがあるワケですね。
僕の場合は「404 Not Found」エラーになりまして、SOY CMS で設定した「見つかりません」ページが空しく表示されるばかり。
試しにルート設定を外してみると、コンパネにアクセスできるようになります。
再度設定すると、やっぱりまたアクセスできない。

うーん……、ルート設定に原因があることは間違いないみたい……。
これは困った。

……んですが、いろいろ試していると運良くうまくいく方法があったので、備忘も兼ねてご紹介しておきます。
続きを読む

.htaccess でリダイレクトする場合、一般的に使うのはこんな↓書式だと思います。

Redirect permanent /old/ http://www.btmup.com/new/ 

「/old/」がリダイレクト元、「http://www.btmup.com/new/」がリダイレクト先です。

そこら辺のことを以前まとめた記事があるので、興味のある方はどうぞ。
»PHPのページをWordPressのブログに301リダイレクトする。 ｜ btmup Blog

で、今回、あるサイトのリニューアルに伴って、リダイレクトする必要がありました。
何も考えずに上記の方法でしようとしたら、何と「505 Internal Server Error」が発生！！
色々試してみましたが、明らかに「Redirect permanent」を使用した場合にエラーが発生しています。

ちなみに、そのサーバーはアイルの「iClusta」（「i-02」プラン）。
「稼働率100%」が謳い文句の人気レンサバです。
システム構築担当の方も仰ってましたが、なかなか制限の多いサーバーのようで。
それだけ動作が安定してるってことなのかも知れませんが……。
皆様もご使用になる場合はご注意を。

さてさて、使えないもんはしょうがないので、別な方法でやってみました。
続きを読む

久々、ファーストサーバネタです。
まぁ別にファーストサーバが悪い訳ではないんですし、ここに限った話でもないんですけど、なぜか色々ややこしいことになることが多いもんで。

今回は CGI の設置方法についてです。

お客さん指定のアクセス解析用 CGI を導入することになったのですが、何回試しても「505 Internal Server Error」が表示されるという事態に陥りました。
作者さんのサイトにあった FAQ や、ファーストサーバのマニュアルとFAQなどを参考にして色々弄ってみても解決せず。

そこでエラーログを見てみたところ、以下のような一文がありまして、

Can’t locate warnings.pm in @INC (@INC contains: /usr/lib/perl5/5.00503…………

早速コピーしてググってみたところ、見つかったのが次のページです。

»warningsプラグマが使えるのは、Perl 5.6以降 – Sakura scope

これによると、Perl 5.6 以降で使える「warnings.pm」というのを探しているのが上記エラーの意味するところのようです。

ということは、Perl 5.6 以降がインストールされている環境であれば動作するはず。

……ん、ちょっと待てよ。ファーストサーバって Perl 5.8 とかスペック表に書いてなかったっけ？？

ってなワケで早速確認したところ、ありました（前出のマニュアルに記載されてたんですね……）。
パスを「/usr/local/bin/perl5.8」に設定するだけで、5.8 系を使用することができます。

散々エラーが発生していた CGI ファイルのパスを変更すると、あっさり動いてくれました。

どうもクセなのか、「/usr/bin/perl（ or /usr/local/bin/perl）」という文字列を見るとそれだけで確認した気になっていたのですが、それって 5.0 系だったのですね。
5.8 系なんて使ったこともないし、今まで意識したこともなかったのですが、これからはちょっと気を付けたいと思います。

というか、エラーログもちゃんと見ないとですね。