CentOS 7.0にGDライブラリのインストール（yumを使用)
新サイトへ移転しました
約３秒後に自動的にリダイレクトします。
前回の記事ではCentOS 6.5へのインストール方法を紹介しました。
CentOS 6.5にGDライブラリのインストール（yumを使用) - Love澤's Room
今回は諸事情によりCentOS 7.0を使うことになったので、そちらへGDモジュールをインストールする方法を書いておきます。
といっても、前回の記事とほとんど同じです。
インストール済みのPHPのパッケージ名の確認
前回の記事と同様に、安直に「yum install php-gd」などとするとエラーが出ることが懸念されます（確認したわけではありません）。そこで、インストール済みのPHPのパッケージ名を確認しましょう。
[root@hogehoge ~]# yum list installed | grep php php56w.x86_64 5.6.2-1.w7 @webtatic php56w-cli.x86_64 5.6.2-1.w7 @webtatic php56w-common.x86_64 5.6.2-1.w7 @webtatic php56w-devel.x86_64 5.6.2-1.w7 @webtatic php56w-gd.x86_64 5.6.2-1.w7 @webtatic php56w-mbstring.x86_64 5.6.2-1.w7 @webtatic php56w-mysql.x86_64 5.6.2-1.w7 @webtatic php56w-pdo.x86_64 5.6.2-1.w7 @webtatic
と言った具合です。
GDモジュールのインストール
インストールされているPHPのパッケージ名にあわせてGDモジュールをインストールします。
[root@hogehoge ~]# yum list | grep php php56w-gd.x86_64 5.6.2-1.w7 @webtatic [root@hogehoge ~]# yum install php56w-gd
Apacheの再起動
インストール後、Webサーバを再起動しましょう。CentOS 7からはCentOS 6以前とコマンドが変わっています。
[root@hogehoge ~]# systemctl restart httpd.service
これで正常に動くはずです。php.info()で確認してみましょう。
poppler&ImageMagickでPDFを画像に変換するも日本語が表示されない場合の対応(CentOS 7.0)
新サイトへ移転しました
約３秒後に自動的にリダイレクトします。
タイトルの通り、popplerとImageMagickでPDFを画像に変換した時に、日本語が表示されない場合の対応です。
なお、使用しているサーバのOSはCentOS 7.0です。
対応1：poppler-dataをインストール
poppler、poppler-utilsだけでなく、poppler-dataもインストールすることで、多くの場合は解決できるようです。
[root@hogehoge ~]# yum install poppler-data
今回は対応1だけでは日本語表示がされませんでした。というか、最初からpoppler、poppler-utils、poppler-data、ghostscriptなどを一緒くたにインストールしていたのですが、ダメでした。
対応2：adobe-fontsをインストール
フォント関係でなにか足りてないかと思ってyumで調べてみることに。するとadobe-source-han-sans-cn-fontsといった物が見つかりました。
[root@hogehoge ~]# yum info *adobe*
読み込んだプラグイン:fastestmirror, langpacks, priorities
Loading mirror speeds from cached hostfile
* base: ftp.nara.wide.ad.jp
* epel: ftp.iij.ad.jp
* extras: ftp.nara.wide.ad.jp
* remi: remi.kazukioishi.net
* rpmforge: ftp.riken.jp
* updates: ftp.nara.wide.ad.jp
* webtatic: us-east.repo.webtatic.com
133 packages excluded due to repository priority protections
利用可能なパッケージ
名前 : adobe-source-han-sans-cn-fonts
アーキテクチャー : noarch
バージョン : 1.000
リリース : 2.el7
容量 : 43 M
リポジトリー : epel/x86_64
要約 : Adobe OpenType Pan-CJK font family for Simplified Chinese
URL : http://sourceforge.net/adobe/source-han-sans/wiki/Home/
ライセンス : ASL 2.0
説明 : Source Han Sans is a sans serif Pan-CJK font family
: that is offered in seven weights―ExtraLight, Light,
: Normal, Regular, Medium, Bold, and Heavy―and
: in several OpenType/CFF-based deployment configurations
: to accommodate various system requirements or limitations.
:
: As the name suggests, Pan-CJK fonts are intended to
: support the characters necessary to render or
: display text in Simplified Chinese, Traditional Chinese,
: Japanese, and Korean.
名前 : adobe-source-han-sans-twhk-fonts
アーキテクチャー : noarch
バージョン : 1.000
リリース : 1.el7
容量 : 29 M
リポジトリー : epel/x86_64
要約 : Adobe OpenType Pan-CJK font family for Traditional Chinese
URL : http://sourceforge.net/adobe/source-han-sans/wiki/Home/
ライセンス : ASL 2.0
説明 : Source Han Sans is a sans serif Pan-CJK font family
: that is offered in seven weights―ExtraLight, Light,
: Normal, Regular, Medium, Bold, and Heavy―and
: in several OpenType/CFF-based deployment configurations
: to accommodate various system requirements or limitations.
:
: As the name suggests, Pan-CJK fonts are intended to
: support the characters necessary to render or
: display text in Simplified Chinese, Traditional Chinese,
: Japanese, and Korean.これをインストールしてみることに。今回、少しこれまでと挙動が異なったので、インストール途中の様子も載せています。違ったのは「adobe-source-han-sans-cn-fonts-1.000-2.el7.noarch.rpm の公開鍵がインストールされていません」という部分です。
[root@hogehoge ~]# yum install adobe-source-han-sans-cn-fonts adobe-source-han-sans-twhk-fonts 読み込んだプラグイン:fastestmirror, langpacks, priorities Loading mirror speeds from cached hostfile * base: ftp.nara.wide.ad.jp * epel: ftp.iij.ad.jp * extras: ftp.nara.wide.ad.jp * remi: remi.kazukioishi.net * rpmforge: ftp.riken.jp * updates: ftp.nara.wide.ad.jp * webtatic: us-east.repo.webtatic.com 133 packages excluded due to repository priority protections 依存性の解決をしています --> トランザクションの確認を実行しています。 ---> パッケージ adobe-source-han-sans-cn-fonts.noarch 0:1.000-2.el7 を インストール ---> パッケージ adobe-source-han-sans-twhk-fonts.noarch 0:1.000-1.el7 を インストール --> 依存性解決を終了しました。 依存性を解決しました ============================================================================================================ Package アーキテクチャー バージョン リポジトリー 容量 ============================================================================================================ インストール中: adobe-source-han-sans-cn-fonts noarch 1.000-2.el7 epel 43 M adobe-source-han-sans-twhk-fonts noarch 1.000-1.el7 epel 29 M トランザクションの要約 ============================================================================================================ インストール 2 パッケージ 総ダウンロード容量: 72 M インストール容量: 94 M Is this ok [y/d/N]: y Downloading packages: 警告: /var/cache/yum/x86_64/7/epel/packages/adobe-source-han-sans-cn-fonts-1.000-2.el7.noarch.rpm: ヘッダー V3 RSA/SHA256 Signature、鍵 ID 352c64e5: NOKEY adobe-source-han-sans-cn-fonts-1.000-2.el7.noarch.rpm の公開鍵がインストールされていません (1/2): adobe-source-han-sans-cn-fonts-1.000-2.el7.noarch.rpm | 43 MB 00:00:58 (2/2): adobe-source-han-sans-twhk-fonts-1.000-1.el7.noarch.rpm | 29 MB 00:02:35 ------------------------------------------------------------------------------------------------------------------- 合計 472 kB/s | 72 MB 00:02:35 file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 から鍵を取得中です。 Importing GPG key 0x352C64E5: Userid : "Fedora EPEL (7) <epel@fedoraproject.org>" Fingerprint: 91e9 7d7c 4a5e 96f1 7f3e 888f 6a2f aea2 352c 64e5 Package : epel-release-7-5.noarch (@extras) From : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 上記の処理を行います。よろしいでしょうか？ [y/N]y Running transaction check Running transaction test Transaction test succeeded Running transaction インストール中 : adobe-source-han-sans-twhk-fonts-1.000-1.el7.noarch 1/2 インストール中 : adobe-source-han-sans-cn-fonts-1.000-2.el7.noarch 2/2 検証中 : adobe-source-han-sans-cn-fonts-1.000-2.el7.noarch 1/2 検証中 : adobe-source-han-sans-twhk-fonts-1.000-1.el7.noarch 2/2 インストール: adobe-source-han-sans-cn-fonts.noarch 0:1.000-2.el7 adobe-source-han-sans-twhk-fonts.noarch 0:1.000-1.el7 完了しました!
サーバーがハングアップした時にしたこと（未解決：現在進行形）
新サイトへ移転しました
約３秒後に自動的にリダイレクトします。
いつぞやかに落雷が原因で停電したことがあった。それ以降、サーバーが不定期にハングアップするようになった。
長い時だと一週間位、短い時だと一日程度でハングアップ。サーバールームに駆け込み直接キーを叩くも反応なし。仕方ないので電源ボタンを長押しして強制終了→再起動というように、騙し騙し使っていた。
さすがに2～3ヶ月経ち、そろそろなにか原因を調査せねば思い立ったので、やっていること（2014年12月26日現在進行形）を書いていく。
/var/logのいろんなログを見つめる
特にこれといったエラーらしいものを発見できず。
OSの再インストール
一週間くらい何事も無く稼働していたのですが、昨日(2014/12/25 14時頃)ハングアップが。OS再インストールしてもだめということは、ハード側の問題かと勘ぐる。
セットアップなどは簡単に以下の様なことを行っていた
- インストール
- ネットワーク設定・ファイアウォール構築・ウイルス対策ソフトインストール
- SSH接続設定・SFTP接続設定
- Webサーバー構築・データベース(MariaDB)構築
- ImageMagickとpopplerのインストール
このあたりでハングアップ。ImageMagickとpopplerあたりが悪いのかなぁ。
HDDの不良セクタ検知
本日(2014/12/26 3時頃)、HDDの不良セクタを疑い、チェック中。コマンドは以下
# badblocks -s -o badsectors_sda1.txt /dev/sda1 # badblocks -s -o badsectors_sda2.txt /dev/sda2 # badblocks -s -o badsectors_sdb1.txt /dev/sdb1 # badblocks -s -o badsectors_sdb2.txt /dev/sdb2
sda1とsdb1のチェックは5秒くらいで終わったが、sda2とsdb2のチェックはそれぞれ1時間30分くらいかかった。しかし特に不良セクタは検知されなかった。
さて、これからどうするか。。。
MariaDB(Mysql)でキー情報を削除する方法
新サイトへ移転しました
約３秒後に自動的にリダイレクトします。
削除前に知るべき情報
キーのインデックスを知る必要があります。
MariaDB [hogehoge]> show create table hugahuga\G *************************** 1. row *************************** Table: hugahuga Create Table: CREATE TABLE `hugahuga` ( `id` int(11) NOT NULL AUTO_INCREMENT, `author_id` int(11) NOT NULL, `section_id` int(11) NOT NULL, `add_date` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `author_id` (`author_id`), KEY `section_id` (`section_id`), CONSTRAINT `hugahuga_ibfk_1` FOREIGN KEY (`author_id`) REFERENCES `foo` (`id`), CONSTRAINT `hugahuga_ibfk_2` FOREIGN KEY (`section_id`) REFERENCES `bar` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 1 row in set (0.00 sec)
インデックスは、主キーの場合だと"PRIMARY KEY (`id`)"の"id"が該当し、外部キーの場合だと"CONSTRAINT `hugahuga_ibfk_1`"の"hugahuga_ibfk_1"などが該当します。主キーでも外部キーでも無いけれどキーに設定されているものは"KEY `author_id` (``)"の"author_id"が該当します。
このインデックスを用いてキーを削除していきます。
主キーやただのキーの削除
indexをdropする。
MariaDB [hogehoge]> alter table hugahuga drop index id; Query OK, 0 rows affected, 1 warning (0.05 sec) Records: 0 Duplicates: 0 Warnings: 1 MariaDB [hogehoge]> alter table hugahuga drop index section_id; Query OK, 0 rows affected, 1 warning (0.05 sec) Records: 0 Duplicates: 0 Warnings: 1
foreign keyの削除
foreign keyをdropする
MariaDB [hogehoge]> alter table hugahuga drop foreign key hugahuga_ibfk_1;
iptableの設定もsshd_configの設定も正しいのにSSH接続できない時の原因
新サイトへ移転しました
約３秒後に自動的にリダイレクトします。
/home/user/のパーミッションが777になっていた。711に戻したらうまく接続できた
FileZillaでファイルを転送しようと思って、一時的にパーミッションを777に設定したところ、転送できなかった。
そこでTeraTermでiptableの確認をしようと思って接続を試みたところ、接続エラーとなった。
もしやと思ってパーミッション設定を711に戻したらうまく接続できた。
その後ググったところ、以下の様なサイトを発見。
SSHが鍵認証されないとき、パーミッションを疑え。 - それマグで！
もちろん、.sshから上位フォルダのパーミッションも必要
chmod 755 /home/takuya
これがうっかり７７７になってた。ホームディレクトリが７７７だと永遠にauthorized_keysは無効化される。
クライアント側のユーザのホームディレクトリのパーミッションにも注意する。所有者以外の書込み権を設定してあるとだめ。
たとえば、/home/hogeのパーミッションが777の場合、公開鍵認証でsshログインしようとすると、
Permission denied (publickey,gssapi-with-mic).
というエラーになる。この場合、サーバ側のログ(/var/log/secure)では
Authentication refused: bad ownership or modes for directory /home/hoge
となっていて、/hoem/hogeのパーミッションに問題があるということ。
所有者以外の書込み権を設定してあるとだめ。700、711、755にすればOK。
なるほど。
CentOSで文字コードの確認＆変更をする方法(nkfコマンド)
新サイトへ移転しました
約３秒後に自動的にリダイレクトします。
nkfコマンドを利用する。他の方法を見つけた時はまたその都度記事にしていきます。
インストール
# yum -y install nkf
文字コードの確認
# nkf -g *
"*"だとディレクトリ内の全てのファイルの文字コードを確認する。ファイルを指定する場合はその都度ファイル名を記述する。
実行結果は以下。
[root@myserv]# nkf -g * hoge.class:BINARY hoge.java:ASCII (LF) foo.txt:UTF-8 (LF) bar.txt:Shift_JIS (LF) ...(以下略)
文字コードの変更(UTF-8へ変更する場合)
# nkf -w foo.txt > bar.txt
オプションで変更後の文字コードを指定する。
詳細はヘルプ参照。主要な文字コードとオプションの対応は以下の通り。
- -j または --jis : JIS 7bit
- -s または --sjis : Shift JIS
- -e または --euc : EUC-JP
- -w または --utf8 : UTF-8
さらにオプションで上書き保存なども可能
- --in-place : 上書き保存
- --overwrite : 上書き保存(元のファイルのタイムスタンプを保持)
Cron <root@hogehoge> /root/tripwire.sh というメールが届いた時にしたこと（メモ）
新サイトへ移転しました
約３秒後に自動的にリダイレクトします。
管理者宛に、以下の様なメールが届いた。
### Error: File could not be opened. ### Filename: /usr/local/tripwire/lib/tripwire/hogehoge.twd ### No such file or directory ### Exiting... Null message body; hope that's ok ### Error: Incorrect site passphrase. ### Exiting... ### Error: Incorrect local passphrase. ### Exiting...続きを読む
