.htaccess Redirect で知らなかったこと
.htaccess Redirect で2点知らなかったことがあった
●1 日本語を含む場合は、転送元は日本語で .htaccess に記述する必要がある(.htaccess は UTF-8 BOMなし)
例:
http://www.example.jp/転送元 -> http://www.example.jp/転送先
Redirect permanent /転送元 http://www.example.jp/%E8%BB%A2%E9%80%81%E5%85%88
●2 301リダイレクトは、ブラウザでキャッシュされる
1点目の確認をする最中に、気づいた
上記2点を知らなかったために、設定作成に時間がかかってしまった・・・
NETGEAR ReadyNAS 102 故障
昨年使い始めたNETGEAR ReadyNAS 102が故障。
NETGEAR ReadyNAS 102(ファームウェア 6.3.5と記憶) と iscsi でつないでいた サーバが停止
同様に、ReadyNAS 102 と iscsi でつないでいたESXiの一つのドライブも参照できなくなっていた。
いろいろ調べたがReadyNAS 102のハード故障らしい。
なので、たまたまあった別の ReadyNAS 102 にHDDを移動。
しかし、iscsi 用のLUN3つのうち、1つが完全に消えていた・・・(はぁ)
他の二つは正常に参照できた。
ReadyNAS 102の設定のバックアップがないし、復旧方法もわからず、このLUNの中のデータはあきらめ。(2日前のフルバックアップがあるVMと、削除予定のVMだけだった。)
現在このハード自体は捨てられてしまっていたので、原因等は結局わからず。
FujiSSL
FujiSSL からプレスリリースが発行されてた。
ニジモ、格安SSLサーバ証明書発行サービス「FujiSSL」2016年10月12日より提供開始 | 株式会社ニジモ | プレスリリース配信代行サービス『ドリームニュース』
プレスリリースは2016年10月12日だが、たまたま 10月5日には発見していて、
所属会社で2016年10月11日に発行してもらい、利用している。
他のところをみると、9月下旬には発行開始していたみたい。
本当に格安だが、手続きも難しくなく、発行もはやく、利用上もまったく問題がない。
モバイル端末だと、むしろ他の証明書より、対応範囲が広いかも。
ただ、手続きで2点引っかかった。
1. メールが文字化けした点
(HTMLメールで、文字コード指定は UTF-8 なのだが、実際は、JIS)
2. 証明書インストール手順のリンク切れ
https://www.fujissl.jp/request/issue/install/
からのリンクが切れている
誤:https://www.fujissl.jp/install/install-apache-mod_ssl-2-0-45
正:https://www.fujissl.jp/request/issue/install/install-apache-mod_ssl-2-0-45/
みなさん、ぜひ利用を検討してみてください。
ホスト名削除されない問題
(2013年末記述)
---
知人のWindows Server 2008を管理している人が、
ドメインコントローラとして動作しているサーバのハードウェアを更新するために、
2台目のサーバを作成し移したのだが、旧サーバのコンピュータ名が残るとのこと。
調査したところ、ホスト名を追加し優先順位の変更はしたが削除忘れたようだ。
cmd> hostname
host-newname
cmd> netdom computername %computername% /enum
コンピューターのすべての名前:
host-newname.domain.local
host-oldname.domain.local
コマンドは正しく完了しました。
cmd> netdom computername %computername% /remove:host-oldname.domain.local
し、リブートで解決
CentOS 6.8 の mknmz で "Unable to convert pdf file (maybe copying protection)"
○環境
- CentOS 6.8
- namazu-2.0.21
英語のPDFはうまく行くが、日本語のPDFが、mknmz で "Unable to convert pdf file (maybe copying protection)"と出てうまく行かない。
いろいろ調べたところ、CentOS6 の yum でインストール された poppler-util に含まれる
pdftotext/pdfinfo のバージョン表記が namazu の設定の想定外らしい。
従来は、xpdf に含まれていたためか、pdftotext/pdfinfoのバージョン表記は 3.0 等になっていたのだが、poppler-utils に含まれるようになって、バージョン表記が 0.12.4 などとなっている。
そのため、namazu の pdf filter でのオプションとミスマッチになっていた。
○対処
pdftotext のバージョンに関わらず、オプションを固定した。
/usr/local/share/namazu/filter/pdf.pl の 62,64~66,86,88~90行目をコメントアウト
61: if (util::islang("ja")) {
62: # if ($pdfconvver >= 1.00) {
63: @pdfconvopts = ('-q', '-raw', '-enc', 'EUC-JP');
64: # } else {
65: # @pdfconvopts = ('-q', '-raw', '-eucjp');
66: # }
85: if (util::islang("ja")) {
86: # if ($pdfinfover >= 2.02) {
87: @pdfinfoopts = ('-enc', 'EUC-JP');
88: # } else {
89: # @pdfinfoopts = ();
90: # }
XOOPS のモジュールのブロック定義の開始は 0 ではなく 1なのは、仕様かバグか?
XOOPS のモジュールを作った。
Block を下記のように一つだけ追加していた。
$modversion['blocks'] = array(
array(
'file' => 'block.php',
'name' => _NAME,
'description' => _DESCRIPTION,
'show_func' => 'block_show',
'template' => 'block.html',
),);
インストールも実行もうまくいっていた。
しかし、XOOPSのモジュール管理で、該当のモジュールのアップデートを行うと、ブロックが消えてしまう。
XOOPS本体のソースを追ったところ、アップデート後にも利用されるブロックかのチェックで、ブロックリストのインデックスを1からチェックしている。
具体的には、xoops\modules\system\admin\modulesadmin\main.php の 340行目付近
$blocks = $module->getInfo('blocks');
...
$count = count($blocks);
...
for ($i = 1; $i <= $count; $i++) {
なので、インデックス0で定義されているモジュールはアップデート後利用されないと判定され、ブロックの設定がXOOPSのデータベースから消されてしまう。
他の多くのXOOPSのモジュールを調べたところ、ブロックの定義は、0からではなく、1から始めている。なので、下記に変更したところ、アップデートでも問題は発生しなくなった。
$modversion['blocks'][1]['file'] = 'block.php';
$modversion['blocks'][1]['name'] = _NAME;
$modversion['blocks'][1]['description'] = _DESCRIPTION;
$modversion['blocks'][1]['show_func'] = 'block_show';
$modversion['blocks'][1]['template'] = 'block.html';
これは、XOOPSのモジュール作成時の作法(仕様)なのだろうか?
個人的にはXOOPS本体のバグだと思う。