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

 

遠隔地の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に変更)

 

・ローカル側ReadyNASiSCSI 領域を作り、VMイメージを配置。ESXi で利用する設定

=> 何事もなく完了

・リモート側ReadyNAS 設置

=> 何事もなく完了

iSCSI 領域のレプリケーション設定

=> できない(★問題1)

NFS領域もしくは、SMB領域のレプリケーション設定は可能

=>NFS領域のレプリケーションで対応することに変更

・ESXi でReadyNASNFS領域をマウント

=> 問題なく完了

・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イメージコピー

=>無事成功

NAS間のレプリケーション設定も完了

・しかし 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

=>さほどかわらず

ReadyNASNFSの書き込み同期設定を変更

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 で運用中

 

ReadyNAS間のレプリケーション速度についても問題発生(下記別記事で)

shaggyman.hatenablog.jp

VMware vCenter Converter Standalone で「一般的なシステム エラーが発生しました:SQL_FULL: database or disk is full」が発生して、VM のコンバートができない。

VMware vCenter Converter Standalone で「一般的なシステム エラーが発生しました:SQL_FULL: database or disk is full」が発生して、VM のコンバートができないという現象に遭遇。

 

結論から書くと McAfee インターネットセキュリティが悪さをしていたようだ。

 

マカフィーのリアルタイムスキャンを無効(オフ)にすると、エラーなく転送が完了した。

Redmine で、各ユーザーが勝手に新プロジェクトを作ってた。

Redmine で、各ユーザーが、Redmine管理者の知らないところで、勝手に新プロジェクトを作ってた。

 

Redmine では、ユーザー + プロジェクトの組み合わせに対して、権限を付与しているように見えるが、どれか一つのプロジェクトにでも、Manager(もしくは、プロジェクトを作れる権限)があると、プロジェクトを作れてしまう。

権限設定の時に、プロジェクト内だけでなく、プロジェクト外へ影響を与える権限があると、さらに気を付けないと。

fetchmail: Server certificate verification error: certificate has expired

2014-01-28 21:00:00 JST 以降
fetchmail: Server certificate verification error: certificate has expired
とエラー

●以下コマンドで確認したが、サーバのpop3d の証明書の有効期限は切れていない。

openssl x509 -in file.crt -noout -dates
openssl x509 -inform pem -in file.pem -text

●以下コマンドで確認すると、通信時に、証明書の有効期限が切れてると表示

openssl s_client -connect example.com:995 -showcerts

CONNECTED(00000003)
depth=2 /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
verify error:num=10:certificate has expired
notAfter=Jan 28 12:00:00 2014 GMT
verify return:0
---
Certificate chain
 0 s:/C=JP/OU=Domain Control Validated/CN=example.com
   i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Domain Validation CA - G2
-----BEGIN CERTIFICATE-----

ん?どうやら Root CA の有効期限が切れてる?

サーバではなく、クライアント側らしい。

おそらく、下記にあてはまった。
https://access.redhat.com/site/solutions/702843

確認したところ、
クライアントOS: CentOS5
openssl-0.9.8e-26.el5_9.1
だった。

●対処

/etc/pki/tls/certs/ca-bundle.crt を CentOS6 の同ファイルに入れ替えた。

(上記対処が正しいかは自信なし。)