ESXi上のVMのWindows 10のCreators Updateの再起動で止まる

タイトル通り、ESXi上のVMのWindows10Proで、Creators Updateを手動で行ったところ、再起動で固まり、それ以降すすまない。

VMを電源オフし、起動するとWindows10は起動するが、バージョン1607のまま。

 

ネットワークドライブを外すなどいろいろ試した。

 

結果、仮想マシンのゲストOSの設定が「Windows 8」になっていたので、

仮想マシンのバージョンを 9から11へ変更し「Windows 10」に変えたところ、

再起動から先に進むようになった。

 

.htaccess Redirect で知らなかったこと

.htaccess Redirect で2点知らなかったことがあった

 

●1 日本語を含む場合は、転送元は日本語で .htaccess に記述する必要がある(.htaccessUTF-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日より提供開始 | 株式会社ニジモ | プレスリリース配信代行サービス『ドリームニュース』

 

FujiSSL-安心・安全の純国産格安SSLサーバ証明書

 

プレスリリースは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 を下記のように一つだけ追加していた。

xoops_version.php

$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から始めている。なので、下記に変更したところ、アップデートでも問題は発生しなくなった。

xoops_version.php

$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本体のバグだと思う。