使っているレンタルサーバー会社から、『SSHのDSA(ssh-dss)公開鍵による認証を廃止する』と連絡がありました。

TeraTermから接続する時SSHで接続しています。
鍵を使って接続していますが、どの方式だったかな。お恥ずかしい話ですが、滅多に使わないので気にしたことがなかったです。
（以前の記事 ⇒ sshでサーバーに接続）

ssh-keygen -l -f 公開鍵ファイルへのパス
で鍵方式が調べられるそうです。

TeraTermでサーバーへ接続して調べました。RSA方式でした（後でファイル名を見たらRSAと入っていました）。
このまま使えるのだと思いますが、ちょうど手もすいていたので、一番安全なed25519方式へ変更してみました。

サーバーで鍵を作成するようです。
ssh-keygen -t ed25519
なのだとか。
SSH接続にて、ed25519の公開鍵＋パスワードの二段階認証を行う
の解説がわかりやすかったです。詳しくは上のサイトをご覧ください。
とても簡単に書くと、
サーバーで公開鍵と秘密鍵の2種類を作って（ファイルでできる）、
公開鍵をサーバーの.sshディレクトリに置いてパーミッションを600に設定、
公開鍵ファイルをauthorized_keysへリネーム、
秘密鍵をPCなどクライアントにダウンロードしてサーバーから削除、
ターミナルから接続する時、パスフレーズと秘密鍵を使って接続、
ということになります。

普通はサーバーで鍵を作るのだと思いますが、TeraTermで作成することにしました。
この場合、ダウンロードとアップロードが逆になって、
TeraTermで公開鍵と秘密鍵の2種類を作って、
公開鍵をサーバーの.sshにファイル名authorized_keysでアップロードしてパーミッションを600に設定、
ターミナルから接続する時、クライアントに残した秘密鍵とパスフレーズを使って接続、
になります。


ターミナルソフトから接続するアカウントが複数あるので、鍵も複数作るべきなのでしょうけど、接続するのは私だけですし、同じ鍵で接続できる方が便利なのです。
ターミナルを使うことは滅多にないので、あれこれやっているとわけがわからなくなってしまいます。

サーバーで鍵を作ると、アカウントごとに違う鍵が作成されますが、TeraTermで作成すると共通にすることができるのです。

これでほとんど今まで通りに使えます。

数日前から行っていたサイトの新環境への移行が完了しました。
【ネットビジネス便利ツール】
昨日、後は新旧を切り替えるだけと書きましたが、今日早くに切り替えました。

と言っても見た目はほぼ変わりません。URLがhttpからhttpsへ変わったくらいです。

行なったのは
SSL化、
ページの文字コードをUTF-8へ、
html5へ、
PHP7へバージョンアップとそれに伴うMySQL関係のソース書き換え、
PostgreSQLの移行（バージョンアップと文字コード変更）、
です。一番大変だったのは・・・ううんなんだろう。
そうだ、テストデータの用意、ですね。

一見動いているように見えても、どこかでエラーが起きていてはいけないので、テストサイトでテストをするのですが、そのデータを用意するのが大変でした。
まさか本番のデータでテストするわけにもいきませんので、でもきちんとデータを作らないと動かない箇所が沢山あるのです。

こういうとき、色々な所を自動化していると大変です。自動にしているソースを見直すのがではなく、自動にすることでデータの動きを自分自身も忘れてしまっているので、思い出して、テストデータを作るのが大変でした。

少々疲れました。
しかも「やった～、終わった！！」ではなく「うん、きっとこれで大丈夫。」という状況なので、今一晴れ晴れしません。

そろそろツールのソースの改修に戻ります。

先日からやっているサイトの
SSL化、
ページの文字コードをUTF-8へ、
html5へ、
PHP7へバージョンアップ、
PostgreSQLの移行（バージョンアップと文字コード変更）、
とほぼ全ての環境が変わってしまう移行がほぼ終わりました。
変わらなかったのはMySQLだけです。でもPHPのバージョンアップに伴い、MySQL関係がかなり変わったので、MySQLまで変わった気分です。

テストサイトでの動作確認は終了し、後は本番サイトとテストサイトとを切り替えます。
切り替え前に再度データの同期を取らなくてはいけません。
ドキドキします。


サイトをSSL化したので、ついでにPOSTしている部分をSSLに書き換えました。

ツールが売れたら、自分自身にもメール送信し、特定のメールボックスで受信します。
そのメールボックスにメールが届くとPHPを起動し、処理を行います。
PHPの起動は【.forward】で行います。
私が利用しているレンタルサーバーの場合、SSLを利用するには拡張モジュールを【php.ini】に記述しておかなければいけません。
ここでハマりました。どうしても読み込んでくれなかったのです。
もちろん私の勘違いで読み込まなかったのですが。。。分かってしまえばなんでもないところで、つまづきました。何を勘違いしていたかは恥ずかしいので内緒です。


【.forward】
"| exec /usr/local/bin/php -q -c/home/xxx/.php/php.ini /home/xxx/yyy/run.php"

【/usr/local/bin/php】はPHPのパス、サーバーによってはPHPのバージョンを指定できます。
【/home/xxx/.php/】ディレクトリ下の【php.ini】を読み込んで、【/home/xxx/yyy/run.php】を実行します。
私も初めは間違えていましたが、【php.ini】を指定している部分【-c/home/xxx/.php/php.ini】の【-c】の後ろにスペースは入りません。


説明を読んでも勘違いが解けず行き詰まってコーヒーを入れていたら、突然ポワッとcronの設定が目の前に浮かんできて解決できました。

3日間片頭痛で伸びていました。今回は薬があまり効かず、しんどかった。今日はやっとまともに活動できました。
片頭痛で吐き気がしている間は、指一本でも動かすと強烈な吐き気にくるので、ピクリとも動けません。そのせいで無理な姿勢で寝ていたのでしょうか、左腕がピクピクし始めてしまい、治まる気配がありません。ああ、鬱陶しい。


WebサイトのSSL化で、何か忘れている気がすると書きました。忘れていたわけではないのですが、テスト漏れがありました。すっかりテストした気になっていました。ご迷惑をおかけしてしまったユーザー様、申し訳ございません。

これからまだツールのソースを変更するので（サイトのSSLはそのままですが）、【.htaccess】のRewriteRuleを書き換えました。
特定のURLを除外して、httpsに301リダイレクトします。

RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_URI} !^/abcdefg.php$
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://engineer.ns-it.net/$1 [R=301,L]

http://engineer.ns-it.net/abcdefg.php へのアクセスはそのままhttpで、それ以外はhttpsへ301リダイレクトします。
【.htaccess】は【engineer.ns-it.net】の下へアップロードです。

RewriteCond %{REQUEST_URI} !^/abcdefg.php$
は
RewriteCond %{REQUEST_URI} !(.*/abcdefg.php$)
でもOKを確認しました。

このブログの文字コードをUTF-8に移行できたので、今日は【ネットビジネス便利ツール】をUTF-8に移行予定だったのですが、急遽予定を変更してSSL化を行いました。

使っているレンタルサーバーがLet's Encryptに対応しているので利用することにしました。
おそらくメジャーなレンタルサーバーは対応（設定や更新を自動化）していると思うので、興味のある方は調べてみてください。

【ネットビジネス便利ツール】はすんなりできました。
ですがこのブログはサブドメインで利用しています。使っているレンタルサーバーではLet's Encryptのワイルドカードにはまだ対応していないので、サブドメインごとにSSLを設定することで解決できました。

作業自体は簡単でした。
これで【ネットビジネス便利ツール】とこのブログをSSL化できました。
このブログの他にもサブドメインで運用しているサイトがあるのですが、閉鎖も含めてもう少し考えます。

ページ内にhttpでリンクを貼っている箇所を修正、PayPal決済関係でhttpを利用している箇所をhttpsに変更しました。

後は、【.htaccess】に
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://engineer.ns-it.net/$1 [R=301,L]
を書いて、httpでのアクセスをhttpsへリダイレクトと共に、検索サイトのページ情報を引き継がせます。

何か忘れている気もするけど、気がついた時また作業します。
助かりました。Let's Encryptとレンタルサーバーに感謝。

使っているレンタルサーバーが、メンテナンスを行ったようです。
今回のメンテナンスは、OSのバージョンアップを行うとのこと、多分何かあるだろうなとは思っていました。

朝起きて、メールのチェックをすると、エラーを知らせるメールの嵐いや洪水かな・・・ 200通以上届いていました。
一体何が起きているんだ。

メールの差出人はどれも【Cron Daemon】です。cron実行時に何かが起こっているようです。
サーバーに負荷をかけていてはいけないので、急いでエラーが起きているスクリプトを確認、実行を止めます。
これで落ち着いて内容を確認できます。

各メールの内容を絞り込むと、

1番目
sendmail: illegal option -- d （dのところは色々な文字）
sendmail: fatal: usage: sendmail [options]

と

2番目
postdrop: warning: could allocate space for only 100 open files

というエラーが起きているようです。

2つ目は、オープンファイル100個までしかスペースを取っていないよ、と言っています。何のスペース？
調べてみると【postdrop】はメール関連のワーニングのようです。

ワーニングが出ているスクリプトでは、メールボックスを開いて、各メールの内容を確認しているので、そのことか？
それともエラーが多すぎると言っているのか？

今後のためにと思いメールボックスに残しておいたメールを整理しました。いつかはしないといけないと思っていたので、いい機会です。
と思い整理したのですが、メールボックスのメールが原因ではなかったようです。


2番目はwarningなので、エラーほど切羽詰っていません。
問題は1番目です。
【sendmail】で【illegal option】というエラーが起きています。ありえない引数をしていしているということです。

エラーが起こっているスクリプトのどこかを調べていくと、MTAが【qmail】かどうか調べている箇所が原因だとわかりました。ここは、意図的にエラーを起こしている箇所です。スクリプトの変更は難しいです。

いや待て、今まで同じスクリプトでエラーを知らせるメールは送られて来ていなかったぞ。
ということは、スクリプト云々ではなく、cronの設定が今までと変わって、cron実行時に起こったエラーをメールで知らせるようになったのでは？

いずれにしても、cronの設定を変えるのが現実的です。出力先を変更する方法があるんだけど、何だっけ？
第30回 「cron のお勉強」が分かりやすいです。

止まりました。やれやれです。
しかし、crontabの内容を見直してみると、今まで送られてこなかったのが不思議です。

Webページを永久引越しする時、古いページの様々な情報を引き継ぎたいことがあります。

ブラウザからのアクセスは新しいページへリダイレクト、クローラーにはページ情報を引き継いで貰う方法はいくつかあります。
詳しくは割愛しますが、【.htaccess】を使いリダイレクトする方法が一番良いでしょうか。

今回は引っ越すページは1ページだけ、その上PHPを使っているので、【.htaccess】ではなく、PHPにソースを記述することにしました。

古いページ（http://oldsite.xxx/old.php）へ
Header("HTTP/1.1 301 Moved Permanently");
Header("Location: http://newsite.xxx/new.php");
と書けばOKです。

いざブラウザから古いページへアクセスすると、とんでもないことが！！！
http://newsite.xxx/new.php
ではないページへリダイレクトされてしまっています。

本番サイトの前に、テストサイトで試してみたのですが、その時リダイレクト先に設定していたページへリダイレクトされてしまってます。

今日は他のテストも行い、そのテストでは【.htaccess】のリダイレクトを使いました。その時、操作を誤り【.htaccess】を思いもしないサーバーのディレクトリにアップしてしまったのかと思い、サーバーの中を探し回りました。
ですが見当たりません。

http://oldsite.xxx/old.php のソースを書き変えてエコーを吐かせてみました。なんと！無視です。エコーは吐かず、リダイレクトされてしまいます。
つまり、http://oldsite.xxx/old.php に何と書こうと、
Header("HTTP/1.1 301 Moved Permanently");
Header("Location: http://newsite.xxx/new.php");
が実行されているのです。

なんじゃぁこりゃぁぁぁぁ！！！！！

2時間ほどあずった挙句、思いついたのが、『ブラウザが勝手にリダイレクトしてる？』でした。試しに別のブラウザからアクセスすると、あっさり正しいURLにリダイレクト・・・されました。

テストに使っていたのはIE9です。
履歴を消せばちゃんと動くかと思い、消してみましたが、駄目でした。
色々やってみた結果、【ツール－閲覧履歴の削除】で【お気に入りWebサイトデータを保持する】のチェックを外して削除するとリダイレクトの履歴が削除されるようです。

思い出してみると、テストのとき使用したファイルを、そのまま本番サイトにアップしてしまった記憶があります。
なので、初回アクセス時に、テストサイトのページへリダイレクトされ、それがブラウザの一時ファイルに残っていたようです。
2回目以降のアクセスはブラウザの一時ファイルの方が、優先されるようで、テストサイトのページへリダイレクトされ続けた、というのが真相のようです。

やれやれ、数分もかからず終わるはずの作業が、2時間弱かかってしまいました。

ここ数日またまた片頭痛の発作が起こっていましたが、今日やっと動けるくらいに回復しました。まだ痛いですが。

使っているレンタルサーバーがTelnet接続サービスを終了し、sshに移行したので、時間ができたらできるようにしておかなければと思っていた【sshでサーバーに接続】をやってみることにしました。決して時間ができたわけではないのですが。

まず、sshをサポートしているソフトを入手します。今まで使っていたソフトはサポートしていないのです。
Windowsでは
TeraTerm
Poderosa
などがあるようです。今回は【TeraTerm】で接続することにしました。
インストールそのものは簡単でした。
Tera Termの使い方－Tera Termのダウンロードとインストールを参考にしました。

インストールが済んだら、次はいよいよ接続です。
公開鍵、秘密鍵の作成方法はTera Termの使い方－SSH鍵の作成が参考になります。

ここで困ってしまいました。どうやって使うんだ？？？
Tera Termの使い方－SSH鍵の作成にあるように、公開鍵をサーバーに登録するのは、本当に管理者に聞かないといけないのかな・・・

検索していると、こんなサイトがありました。
TeraTermProで公開鍵認証を使う－公開鍵をサーバーに登録する
この通りにやってみました。
万歳！！接続！

後は、SSH公開鍵暗号化方式－サーバ側（接続受け側）の設定にあるように、パーミッションを変更しておきます。【600】では動かなかったので、【700】に設定しました。

これで完了。やれやれです。
それにしても、TeraTerm、使いにくい・・・
設定で使いやすくなるのだとは思いますが。
少しずつ慣れながら、設定を変えていくしかないかぁ。

ぶつぶつ書いてしまったqmailのバグですが、これでMTAを自動認識できるようになるかもしれません。

以前、何のMTAを使っているか判別する方法を探したとき、PHPのiniファイルの設定を読む方法しか見つけられなかったのですが、今回別の視点から検索していたら、見つけました。
ちょびろぐ
system関数を使って調べるようです。
設定ファイルを辿っていけば、どこかにMTAがわかる記述があるはずだとは思っていましたが、system関数で調べられるんだぁ。勉強、勉強。

しかし、どうやら重たいらしいです。まいったなぁ。
私としては、こんな苦労はしなくても、SMTPポートを直接開いて送信してしまったほうが後腐れなくて、すっきりして、爽快なんですが・・・
ポートを開くとなると、IDやPWをどこかに保存しておかなければいけません。（もしかしたら自動取得できるのかもしれませんが、どうせ面倒でしょうし、そうなるとどっちが良い方法かわからなくなってきます。）
ユーザーさんにも設定してもらわなければいけませんし、極力ファイルに保存しておきたくありません。
もちろんステップメールやメールマガジンのように大量配信する場合は、PHPのmail関数は不適切ですから、SMTPポートを開きます。ですが、一度に送信するのが1通や2通の場合は、ユーザーさんの設定を軽くしたいな、と思います。

Qdmailに組み込まれているソースを使いやすいようにアレンジして、試してみました。
動いているっぽいです。確かに、qmailのときはステータス111を返し、sendmailでは1を返してきます。
でもソースにある100はどんなときに返ってくるんだろう？

まぁ今の状態より、より正確な自動判定ができると思うので、導入しようと思います。
でも、今の手動で設定する方法も残しておくつもりです。
世の中思わぬ動きをするサーバーがあるかもしれません。自動判定できない場合に備えて手動も残しておいたほうが安心です。せっかく今機能があるんですから。

重たいらしいし、ツールの管理画面を開いたとき判定して、設定に反映したほうがいいかな？
送信前に一度だけチェックすれば、さほど負荷はかからないかな？

使っているレンタルサーバーが、Telnet接続を終了させ、今後はsshによる接続のみ利用できるようになってしまいました。
今まで、DBのテーブル作成、cronの設定はTelnetで接続して行っていたので、今後のためにも、sshの接続ができるようにしておかなければいけません。

もっとも、テーブル作成やcron設定が、サーバーの管理画面からできれば、私の場合なにもsshで接続する必要はないのですが。

接続方法を見ていると、なんだか面倒そうです。管理画面からできればなぁ。大抵のサーバーはできるようになっているのですが。
ということを思いながら、管理画面を見ていると、SQL管理ツールというプルダウンが目に留まりました。もしかして。
選んでみると、DB接続でき、SQLが発行できるではありませんか！！
しかもMySQL、PostgreSQL両方いけるではありませんか。
なんだ、Telnetで面倒な接続をしなくても、テーブル作ったり、中身をちょっと見てみたり、できるんじゃない！
なんで今まで気がつかなかったんだぁぁぁぁぁ。

後はcronの設定か管理画面からできれば、ssh接続は今のところ必要なくなります。

そう言えば、cronを管理画面から設定できるようにするって以前言ってたなぁ。
調べてみると、2008年8月に機能を付けます！とお知らせがきています。
でも管理画面のどこにも見当たりません。隠れているのかな？

やや期待して、問い合わせてみました。すると、準備はしているから待って、できるまでsshから設定して、とのこと。cron設定の機能を付けるのに、4年もかかるのか！？ そんなわけないでしょうに。

cronの設定はWebからできるようにならないか、何度もチャレンジしたのですが、どうしてもできませんでした。
ネットに書いてある方法はことごとく当てはまらないのです。
なんとかならないかなぁ。

【.forward】から転送されたメールは、
if(($objMail = @fopen("php://stdin", "rb")) == true ){
　while(!feof($objMail)){
　　$strLine.= fgets($objMail, 4096);
　}
}
@fclose($objMail);
で読み込むことができます。

上のソースだと、$strLine にはメールヘッダも本文も、全てが取り込まれるので、ここから必要な情報を抜き出していくことになります。

ヘッダと本文は、【￥n￥n】と改行コードが2回続くことで区切られています。
【￥n￥n】より前がヘッダ、後ろが本文です。
ちなみに、ヘッダも本文も、メールの改行コードは【￥n】です。

更にヘッダは
　・
　・
To: 送信先メールアドレス
Subject: 件名
From: 差出人名 <差出人メールアドレス>
　・
　・
のようになっています。1行ずつチェックして、上の形式から必要な情報を取り出します。

メールの差出人を会員などに登録する場合、【差出人メールアドレス】を抜き出し、登録処理を行えばOKです。

【To: 】と【From: 】以降は、
　名前 <メールアドレス>
の場合もあれば、
　<メールアドレス>
の場合も、
　メールアドレス
の場合もあります。

名前、件名などに、日本語が含まれる場合、エンコードされてますから、【mb_decode_mimeheader】でデコードしてください。

メール受信と同時にCGIを実行と合わせれば、【ビジネス羅針盤 ステップメール】を空メール登録に対応させることができます。

以前からあったほうがいいのかなと思っていた、【ビジネス羅針盤 ステップメール】への空メール登録へ対応してみることにしました。
空メールだけでなく、本文に姓名が書いてあれば、名前も登録されるようにしたいと思います。

これを実現するためには、メールを受信したらCGIを実行する、という設定がサーバーに必要になります。
この設定ができるものに、【aliases】、【procmail】、【.forward】ファイルがあるようです。
レンタルサーバーで一番使われているのが、【.forward】ファイルのようなので、ここでは【.forward】ファイルで試してみることにします。
しかしサーバーによっては、セキュリティ上設定を許可していないものもあるようです。

設定は簡単で、
【"| phpのパス -q 実行したいCGIのパス"】
となります。

【"| /usr/local/bin/php -q /usr/home/xxx/yyy/run.php"】
のようになります。
ご自分のサーバーの環境に合わせてパスは変更してください。
これでメール受信と同時に【run.php】が実行されます。

【.forward】ファイルはメールの転送を設定するファイルですが、転送先にCGIファイルを指定すると、プログラムを実行できるようになります。

【.forward】で転送を設定する場合は、無限転送にならないように十分注意してください。永遠にメールが転送され続け、サーバーに無駄で過大な負荷がかかることになります。

再度、RewriteRuleを使ってアクセス制御の必要に迫られました。

今度は、URLにパラメータ（クエリ）が付いています。

色々やってみたのですが、うまくいきません。
やっとたどり着いたのが、サーバー変数です。

例えば、
http://sample.ooo/sample.html?id=ABCD
を
http://sample.ooo/sample/sample.php?id=ABCD
へ飛ばしたいときは

--------------------------------------------------------------------
RewriteEngine on
RewriteRule ^sampel\.html$ /sample/sample.php?query=%{QUERY_STRING} [L]
--------------------------------------------------------------------

です。

ただ、
http://sample.ooo/sample.html?id=ABCD&code=EFGH
も
http://sample.ooo/sample/sample.php?id=ABCD
となります。


このほかにも便利なサーバー変数が色々あります。

こねくり回して、やっと思う動きを実現できました。

以前から自分のブログを見て気がついていたのですが、例えば、
http://sample.xxx/sub_dir/
へアクセスすると、sub_dirは存在しないのに、きちんとページが表示されています。

これは一体どういう仕組みなのでしょう。

始めは、
http://sample.xxx/index.php
など、トップディレクトリのインデックスファイルでアクセスを制御しているのかと考えました。が、これでは制御できない気がします。


となると、http://sample.xxx/ へアクセスを制御するファイルをおき、特定のディレクトリやファイルへのアクセスを、別のファイルへ飛ばしているのでしょう。

そしてそれは多分【.htaccess】ファイルです。


自分のブログを調べると、ありました。【.htaccess】。
中身を見ると、なにやら書いてあります。わからないので、ネットで調べてみました。

やはり、思ったとおりです。【RewriteRule】を使えばよいそうです。サーバーがApacheなら使えます。

--------------------------------------------------------------------
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /index.php?file=$1 [L,QSA]
--------------------------------------------------------------------

これを【.htaccess】に書き込み、http://sample.xxx/ へおきます。
http://sample.xxx/sub_dir
にアクセスかあると、http://sample.xxx/index.php?file=sub_dir へとばすことができます。

あとは、index.phpで$fileの値を調べ、表示するページを作ればOKです。


RewriteRule
が参考になります。


また1つ勉強になりました。