「@nifty @homepage」利用者だった人のための「@nifty ホームページサービス」について

【2021/05/10】
「標準モジュール」に関する記事について、認識の違いがあったので修正。

いつも「ホームページの仕様、どんなんだったっけ?」ってなるんで、備忘録。

経緯

元「@nifty @homepage」利用者は、「@nifty ホームページサービス」への移行案内の際、適切に手続きをしていれば、「@niftyホームページサービス(ミニ)」というプランで移行されている。

これは @nifty を2016年以前から契約利用し、かつ当時無料にて提供されていた「@nifty @homepage」を利用していた人向けの、言わば「救済」プラン。

プラン毎の違い

ちなみに「@nifty ホームページサービス」には、以下の3つのプランがある。

  • LaCoocan ライト(1G。CGIなど色々不可)
  • LaCoocan スタンダード(4G。CGI、DB利用可)
  • LaCoocan スタンダードプラス(10G。スタンダードの大容量版)

「ミニ」プランから「LaCookan スタンダード」「LaCookan スタンダード」のプランに変更することは可能。ただし変更後は、再度「ミニ」「ライト」プランに戻すことができない。

「@nifty ホームページサービス」既存の各種プランと違うところ

  • ディスク容量が2GB(ライトは1GB、スタンダード4GB、スタンダードプラス10GB)
  • CGI は Perl のみ利用可(ライトは利用不可)
  • CGI 定期実行が利用可(ライトは利用不可)

機能の違い

「@nifty ホームページサービス」への移行によって変わった機能

プライベートパック

アクセス制限機能(.htaccess、.htpasswd)による BASIC 認証に変わる(利用には再設定が必要)。

SSLも未提供。

URL

別物のサービスなので、URLも変わる。

FTP

サービス自体が別物扱いなので、すべて再設定が必要。
接続先ホスト名・アカウント名などが変更になる。

CGI

ホームページアドレスとCGI環境のアドレスが統合され、すべてホームページアドレス内で動作するようになった。
つまり cgi-bin ディレクトリがなくなり、すべて homepage ディレクトリ配下で、HTML ファイルと同じ場所にCGIの実行ファイルを設置し、そのファイルに実行権を与えれば動作するようになる。

「@niftyホームページサービス」では提供されなくなった機能

  • アクセスカウンター
    (自前CGIで実現可能。だが今時のコンテンツにおいてアクセスカウンターは流行らないし機能不足。解析用途であれば、Google Analytics などを導入するほうがよいと思う。)
  • サクサクかきあげ君
  • 簡単マイページ設定
  • 公開停止・再開機能(アクセス制限機能で代用可能)
  • 素材集(巷のWebコンテンツから拾えばよい)

「@nifty ホームページサービス」から提供される新機能

  • CGI 定期実行(LaCoocanライトを除く)
  • .htaccess(アクセス制限)
  • 独自ドメインの利用(ドメイン取得や維持は別料金)
  • カスタムエラーページ

LaCoocanスタンダード(プラス)にアップグレードすることで提供される新機能

  • sendmail
  • アクセスログ解析
  • 簡単インストーラー(WordPress などが導入可能、らしい)
  • データベース(MySQL、SQLite)

Perl(CGI)について

Perl 5 標準モジュールが一部欠けている

@homepage 時代と同じ。
ちなみに、perl 5.8.7(2021年3月時点)

ちなみに公式的には標準モジュールは提供しないとしているが、実際のところ、一部は利用可能。
しかしながら、例えば「DB_File」や「DateTime」モジュールが利用できない等、便利なモジュールが一部省かれている。
それに、今は使えているモジュールが今後使えなくなる可能性だってある。
なので、意味合いとしては標準モジュール提供は保証しないという形で捉えるのが妥当。

その影響により、ファイルアクセスだろうが、データアクセスだろうが、何をするにしても、原始的なレベルの作り込みが必要になる場合がある。

よって「@nifty ホームページサービス」における Perl は、かなり単純な機能のみを提供するようにしないと、開発・保守の両面からコストが発生することを念頭に置く必要あり。

自分の場合も、バックオフィスは別プロバイダで提供されている PHP と MySQL などで実装し、「@nifty ホームページサービス」はフロントエンドに徹し、Webコンテンツの稼働に必要なデータ類を、可能なかぎり構築してから転送している。

具体的には、バックオフィスにて tsv 形式のデータファイルなど、フロントエンド用のWebコンテンツ動作に必要なデータを構築・管理。
フロントエンド側では、バックエンド側からアップロードされたデータファイルなどを Perl を用いた CGI で動作させている程度に留めている。

ちなみに自分で必要な Perl モジュール(パッケージ・ライブラリなど)を設置することで「@nifty ホームページサービス」上で高度なWebコンテンツを構築することができる可能性はある。

ただ個人的には、今のご時世、小手先でゴチャゴチャ調整するのは時間がかかるし、ライブラリのアップデート時などの追従性やセキュリティ面も考えると不安。
もしそのようなコンテンツを実現したいのであれば、コスト面も踏まえると、もっと別の自由度の高いプロバイダーのサービスを使うと思う。

そもそも「@nifty ホームページサービス」が、いつまで CGI のサービス(というかホームページサービスそのもの)を提供してくれるかも不明。
(昨今ISPのホームページサービスは、契約者の利用率も右肩下がりなうえ、システムアップデートの追従やセキュリティなどの観点からコストに見合わず、提供終了されつつある。)

ここまで考えると、他のプロバイダーサービスを利用するほうが良いのではないかと。

use strict; use warnings; は役立たず。

とは言っても「外せ」という意味ではなく。

「@nifty ホームページサービス」は、(@homepage サービスの時代と同じく)ブラウザ上では全部500エラーが表示されるだけ。
また管理画面等からエラーログを確認するための手段もない。そのためエラーが発生しても、原因を掴むことは至難。

実際には、デバック文を挿入したり、変数を表示させるなどの手法で動作確認したり、ソース全体を、

eval {
  ...(CGIソース本体)...
};
if ($@) {
    print "Content-type: text/html\n\n";
    print "<title>error</title>\n";
    print "$@\n";
}

で囲い込んで、無理矢理エラーを表示させることも可能かもだが、正直微妙。

自分の場合はエラーを追跡するため「だけ」に、標準モジュールの存在しない開発・動作確認用のサーバを別途建てて、それから「@nifty ホームページサービス」にデプロイしています。

この環境を構築するのが一番面倒、という話もある。

【参考】使い道

これらサービスの制約下でも、当方では無駄なく使っている。
以下参考まで。

ちなみにいずれのコンテンツも、管理機能はWebプログラミングが可能な別サイトに構築。

期間限定の共有フォルダ

URLを知っていればアクセスできるようなファイルを置く場所。
期間超過のファイルは、「CGI定期実行」機能によって削除。

ただし前述の通りSSLが使えないため、盗聴されると可能性あり。そのため、そのリスクを負っても問題ないようなファイルしか扱えない。

画像アルバム

風景写真とか。素材写真とか。
こちらも当方(撮影・作成者)で権利関係の弊害がなさそうな画像を公開するために作った。

郵便番号⇒住所変換

文字通りのツール。
そもそも tsv 形式のデータの抽出速度がどれ位かかるのかを調べるため、実験的に作ったもの。
現実的な速度で提供できるように試行錯誤しながら提供中。

自宅持ちのサーバをクラウドに

自宅のサーバをクラウドへにするべく、少し考えてみたのですが。結局、当面の間は保留することにしました。

経緯。

事務所は「事務所兼自宅」なのですが、息子が生まれたので、子供部屋を確保すべく、仕事部屋としている部屋を、近々明け渡さなくてはなりません。(仕事部屋は納戸に移動する予定。)
そのため、家にある機材や書類を減らす必要があり、その一環として、サーバを減らしたいと思い立ちました。

現在の機材はおよそ6万円で、3年ぐらい前に購入しました。
本当は当方が利用している「さくらのレンタルサーバ」に入れたかったのですが、以下の Web アプリに問題もあったため、あえなく現在の状態に。

  • TInyTynyRSS の処理(RSSの巡回取得処理)が cron で稼動している。この処理が遅く「さくらのレンタルサーバ」の制約に引っかかる。
  • Redmine。Ruby on Rails で書かれていて、さくらのレンタルサーバでも無理矢理設置することはできる(らしい)のだが、恐ろしく遅い(らしい)。

この機材には VMWare を乗せていて、当初は「これで必要に応じて、仮想サーバを建てればいいや」と思っていました。
でも結局は、さくらに載せられなかった Web アプリしか稼動していない Web サーバと DB サーバのみしか、稼動してません。容量も空き放題の状態。

そのため、さくらの VPS かクラウドに載せ変えて、自宅の機材は停止させようかな、と考えた次第。
自宅サーバは電気代もかかるし。

結論。

見送りです。

さくらのクラウドの場合、最低スペックにしても年間 25,000 円ぐらいかかってしまう。(月 2,000 円ぐらい。)
これを高いと考えるかは、人によるかもだが、自分の場合はちょっと高いと感じた。(年間 10,000 円ぐらいなら考えるのだが。。。)

さくらの VPS にしても良いのだが、ディスクの途中増設が不可能。
よって容量超過時には、上位プランを別契約して、再セットアップ、データ移行という大きな手間が発生する。
(Redmine があるので、容易にディスク容量増やせないプランは、少し厳しい。)

他社を探しても良いかもだが、管理上、契約先も増やしたくないので、とりあえず保留。

ほぼ、月毎の季節テーマをまとめてみた

12月末~1月前半:正月飾り
1月後半~2月前半:節分・雪だるま
2月後半~3月3日:ひなまつり
3月4日~4月前半: 桜、彼岸
4月後半~5月前半:こいのぼり
5月後半~ 6月:アジサイ、傘、長靴、カエル
7月~9月:太陽、入道雲、海、ヒマワリ、アサガオ 、ヘチマ、スイカ
10月:ハロウィン
11月:紅葉、モミジ、栗
12月:クリスマス

夏場のテーマは長いので、前半と後半で、テーマを分割してもいいかも。

YAMAHA ルータに Poderosa でSSH接続する場合

本家のバージョン4.1.0 では、開発された時点でのSSHの暗号アルゴリズムが少ないので、NVR500に搭載されているSSHサーバの暗号アルゴリズムが解読できないみたい。

なので、オープンプロジェクト以降のバージョン4.3.0b以降~を使うのが良いかと。

YAMAHA ルータ NVR500 で DHCP 静的 IP を割り当てる方法

まぁ、ルータが壊れたので、急遽新調。
その際にNVR500を購入したので、その備忘録。

1.「かんたん設定」で、LANのDHCP割当IPの設定までやる。

ここでは、以下のような感じで。

  • 識別番号「1」
  • IPアドレス領域「192.168.100.2~192.168.100.253」
  • サブネットマスク「255.255.255.0」

2.「かんたん設定」でSSHで接続できるようにする。
あとSSHでログインするためには、ルータ(に組み込まれているOSへのログイン)ユーザ登録も必要になので、登録する。

3.静的IPを割り当てたい機材のMACアドレスを調べておく。
(実はこれが一番面倒。 )

4.SSHクライアント(TeraTermPro とか Poderosa とか)でルータにSSHログイン。

(1)管理者に成る。

> Administrator
(ここで管理者パスワードを聞かれるので、
「かんたん設定」で登録した管理者パスワードを入力。)
#

管理者になれたらプロンプトが「>」から「#」に変わる。

(2)静的割当するIPとMACを登録。(やっと本題)

# dhcp scope bind 1 192.168.100.6 ethernet 12:34:56:78:9a:bc
#

(3)最後は「保存」のコマンドを実行。

# save
#

これを忘れると、ルータの電源切ったり再起動した時に登録した情報がすべてパーとなる。

(4)確認するときは show config コマンドの結果の中から、dhcp だけを grep して確認。

#show config|grep dhcp
(結果がここにダラダラでてくる)
#

Drobo FS の SSH 上から MAC アドレスを調べる方法

ルータを新調したので、DHCP の IP 静的割当を設定したのだが、Drobo FS の MAC アドレス探しがちょっと面倒だったので、備忘録。

まぁ Drobo FS 本体に貼られているラベルを見れば、MAC アドレスは判るんだけども、肝心のラベルが本体底面に貼られているので、引っ繰り返さないと確認できないのが難点。

我が家の場合、ラベルを確認するためには、Drobo FS の電源を切って、Drobo FS 本体が格納されているラックから引き剥がす必要があって、これがラックの場所とかの関係で、ちょっと大変。

ちなみに、IP アドレスとかサブネットとかは Drobo Dashboard から設定するものなので、そこから確認できるものの、MACアドレスは確認できない。(まぁ所詮米国製なので、こういうツールの「痒いところに手が届かない」のは、 米国の仕様(=御国柄と同意)。)

ということで、パソコンからは少し面倒ではあるが、Drobo FS の組み込み Linux にアクセスして調べることに。
という訳で以下手順。

1. DroboAppsから「dropbear」(SSHサーバ)をインストール

2. SSHクライアント(TeraTermProとかPoderosaとか)でDroboFSにSSHログイン。

ここでSSHの接続が確立できない場合は、DroboApps の挙動がおかしい可能性がある。
その場合は、Drobo Dashboard の管理者設定の「DroboApps を有効化」を一度切ってから、再度入れ直す。
ちなみに Drobo FS 再起動しても、接続は改善できない。必ず上記操作が必要。

3. ログインできたら、以下のコマンド実行

# /sbin/ifconfig
(ここにMACアドレスなどのネットワーク情報が表示される。)
#

(パスが通ってないので、最初に/sbin付けて、絶対パスでコマンド実行。)

これで本体をひっくり返さずに、MACアドレスの確認ができる。

とはいえ、とても面倒。

やっとこさ JS ヘルパーのおよそのコツがつかめてきました

まぁ、JS ヘルパーを使うことによって、jQuery の記述を分離する必要がなくなるのは利点といえば利点。
でもそれ以上の不利もある。

  • 繰り返しロジックの中で JS ヘルパーを使うと、そのたびにスクリプトが生成されることになり、これはコードの無駄な冗長に繋がる。
  • ビューの HTML の中の PHP 記述の更に内側に javascript(jQuery)記述が割り込んでくるので、これがわかりにくい
  • ヘルパーで自動生成される javascript(jQuery)記述ががわかりにくい。

まぁ JS ヘルパーに限らず、全体的にヘルパーというのは、使用した際に最終的にどのような HTML になるかを少なからず想像しなくてはならないものなのだが、JS ヘルパーはその想像が難しい。
しかも CakePHP 御大が提供しているドキュメントがウンコで、とても判りにくい。結局、JS ヘルパーの場合、ヘルパーのコアソースを追うのが一番早かった。
あと、Ajax ヘルパー(prototype.js)のように、jQuery の経年による陳腐化した際の仕様変更や廃止も怖い。

こうなると javascript(jQuery)は、ヘルパーを使わずに普通に記述したほうがよいのかもしれない。

でも、JS ヘルパーを利用することにより、ソースコーディング量が減るもの事実。
実際 javascript(jQuery)を記述するよりも、ソースコーディングは減った。(結果的に生成される HTML は、javascript(jQuery)を記述するよりも大きいのだが。)

WordPress 日本語メッセージの対応(面倒臭い版)

正直なところ、直接、テーマのスタイルやPHPソースファイルを修正したほうが手っ取り早いです。参考書籍でさえ、そのような記述が為されているものが多いです。

でも折角なので、なるべく TwentyTen のテーマを構成しているソースの構成をベースに残したまま、メッセージを修正してみます。

ちなみに、WordPress の日本語版に同梱されている TwentyTen テーマは、日本語ローカライズに対応していて、元文書のPHPソースを修正せず、設定ファイルみたいな物を介して、該当箇所の英語メッセージを日本語に置換して表示しています。
今回はこの仕組みをそのまま利用するための修正方法です。

WordPress をバージョンアップするときの注意事項

テーマをカスタマイズしている場合、特に TwentyTen などWordPress のデフォルトテーマをベースに style.css などをカスタマイズしている場合は、必ずバックアップを取得する事。

バックアップせずにバージョンアップするとテンプレートも上書きされてしまいます。

まぁ、やってしまった本人が語っているので、間違いない。。。(T_T)

phpMyAdmin のディレクトリを移動したとき

現象

Web サーバのメンテナンスや整備で、phpMyAdmin のディレクトリを移動し、phpMyAdmin のログインからユーザ名とパスワードを入力し「実行する」をクリックした際、

エラーが出たためセッションを開始できませんでした。 PHP やウェブサーバのログファイルに出ているエラーを確認して、PHP を正しく設定してください

というエラーに出くわすことがある。

原因

phpMyAdmin のディレクトリを移動する前はログインできていたのに、移動した途端に動かなくなった場合、cookie 内に保存しているセッションが不整合を起こしている可能性があり。

config.inc.php の中に

$cfg['Servers'][$i]['auth_type'] = 'cookie';

と設定している場合は、セッションは cookie に格納されている。

対処

  • クライアントの該当する cookie を削除。
  • ブラウザを再起動。phpMyAdmin にアクセスし、再度ログイン。

ただし、これでもエラーが発生する場合や、上記の場所とは違う画面や操作でセッションのエラーが発生している場合、php.ini の設定など別の問題が考えられるので、ググって確認するべし。