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本体のバグだと思う。
遠隔地のReadyNAS間のレプリケーション速度について問題発生
遠隔地のReadyNAS間のレプリケーション速度について問題発生
要は、ある時間帯に、インターネットの接続の速度が低下している現象
いろいろ調べたところ、結果、光電話のルータ PR-200NE の節電設定がなされていて、ある特定の時間帯に、ether が10M になってたため、それ以上の速度が出なかった。
●PR-200NE機能詳細ガイド
http://web116.jp/shop/hikari_r/pr_200ne/pr_200ne_03.html
PR200NE_detail1212/機能詳細ガイド/guide/4-w/8w_m7.html
節電機能動作開始時は、有線LANのリンク速度が10Mbpsに変更されるため通信速度が低下したり、通信が切断されたりする場合があります。また、節電機能動作終了時も有線LANのリンク速度が変更されるため、通信が切断される場合があります。
節電設定で、CPU速度とかは変わりそうだが、有線LANの速度も変わるのは想定外だった。
気づいたのは、転送速度を見ていて、ある時間帯は、常に900kb/s あたりをうろうろ(変動少ない)しているが、ある時間帯外は、変動が大きく500kb/s ~ 4Mb/s などだったため、どこかの装置の速度規制を疑った。
ReadyNAS を使った VMWare ESXi の VMイメージのバックアップ環境設定にはまった。
NAS を利用しローカルの ESXi の VMイメージをバックアップすることになった
NAS: NETGEAR ReadyNAS 102 *2 (のちに ローカル側 ReadyNAS 314 / リモート側 ReadyNAS 102に変更)
・ローカル側ReadyNAS に iSCSI 領域を作り、VMイメージを配置。ESXi で利用する設定
=> 何事もなく完了
・リモート側ReadyNAS 設置
=> 何事もなく完了
=> できない(★問題1)
・NFS領域もしくは、SMB領域のレプリケーション設定は可能
=> 問題なく完了
・ESXi でローカルHDDからReadyNAS(102)のNFS領域へVMイメージコピー
=>ReadyNAS(102)が停止(★問題2)
=>iSCSI領域上のVMのHDDが不整合になり、長時間の全システム停止(OSの破損等が生じ修復に時間がかかる)
・ReadyNAS(102)のNFS領域へのVMイメージコピーが原因とは思わず、環境修復後再度行う。
=>ReadyNAS(102)が2度目の停止
=>再度長時間の全システム停止
・ReadyNAS 102 のスペックが原因なのではとのことで、ReadyNAS 314を追加購入
・ESXi でローカルHDDからReadyNAS(314)のNFS領域へVMイメージコピー
=>無事成功
・しかし ESXi から NFS 領域へのコピーが遅い(★問題3)
●ローカルHDD 20.8 MB/s
●iSCSI 15.6 MB/s
●NFS(sync MTU 1500) 7.4 MB/s
・MTUを 1500 -> 9000 に変更(NAS もスイッチも対応していたので)
●NFS(sync MTU 9000) 8.1 MB/s
=>さほどかわらず
●NFS(async MTU 1500) 39.2 MB/s
●NFS(async MTU 9000) 39.6 MB/s
・速度向上!
(参考
NETGEAR Support | Answer | How do disable NFS Sync mode in ReadyNAS OS 6, to improve NFS performance )
・async MTU 1500 で運用中