新しい年になったので、自宅サーバーも新たな気持で再稼働と思いリブートしたら起動できなくなった！！　どうもkernelが 3.10.0-327.3.1 にバージョンアップしてたみたいで、Kernel panicが発生してるようだ。　最新kernelは自宅サーバーに使ってる HP ProLiant MicroServer との相性が悪いみたいだ。　仕方ないので一つ前のkernelでブートして、解決策をGoogleで調べたら /etc/default/grub のGRUB_CMDLINE_LINUX=”…”にKernelパラメータ initcall_blacklist=clocksource_done_booting を追記することでKernel panicを回避できるという情報があった。

■ということで /etc/default/grub を編集

[root@server2 ~]# vi /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.lvm.lv=centos/swap vconsole.font=latarcyrheb-sun16 vconsole.keymap=jp106 rd.lvm.lv=centos/root crashkernel=auto  rhgb quiet"

 ↓　initcall_blacklist=clocksource_done_bootingを追記

GRUB_CMDLINE_LINUX="rd.lvm.lv=centos/swap vconsole.font=latarcyrheb-sun16 vconsole.keymap=jp106 rd.lvm.lv=centos/root crashkernel=auto  rhgb quiet initcall_blacklist=clocksource_done_booting"
GRUB_DISABLE_RECOVERY="true"

■次のコマンドを実行してブートローダーの設定を更新

[root@server2 ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.10.0-327.3.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-327.3.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-229.20.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-229.20.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-229.14.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-229.14.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-229.11.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-229.11.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-229.7.2.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-229.7.2.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-30cdb5e79c4c42df8e8ac6d86d8ab745
Found initrd image: /boot/initramfs-0-rescue-30cdb5e79c4c42df8e8ac6d86d8ab745.img
done

rebootするとkernel 3.10.0-327.3.1で起動することができた。

GNOMEデスクトップでも問題が発生して、ログインし直せとかいうメッセージが出るようになった。こちらはとりあえず、ランレベルをCLIログインに変更して対処することにした。

■現在のランレベル確認

[root@server2 ~]# systemctl get-default
graphical.target

■multi-user.targetのCLIログインに変更

[root@server2 ~]# systemctl set-default multi-user.target
Removed symlink /etc/systemd/system/default.target.
Created symlink from /etc/systemd/system/default.target to /usr/lib/systemd/system/multi-user.target.

cron.hourly から以下の様なメールが届いた。

/etc/cron.hourly/0yum-hourly.cron:

Not using downloaded repomd.xml because it is older than what we have:
  Current   : Thu Oct 22 08:25:28 2015
  Downloaded: Wed Oct 21 04:02:20 2015

yumは、1度ダウンロードしたファイルは/var/cache/yum/にキャッシュとして保存するが、長期運用しているとサイズが肥大化するためyum cleanで定期的に削除する必要がある。

yumのキャッシュがどれ位利用されてるか調べる。下記の例では119Mバイト利用されていることが分かる。

[root@server1 ~]# du -sh /var/cache/yum/
119M    /var/cache/yum/

yumのキャッシュを削除

[root@server1 ~]# yum clean all
読み込んだプラグイン:fastestmirror, langpacks, priorities
リポジトリーを清掃しています: base centosplus epel extras rpmforge updates
Cleaning up everything
Cleaning up list of fastest mirrors

パッケージのアップデート

[root@server1 ~]# yum update
読み込んだプラグイン:fastestmirror, langpacks, priorities
base                                                                         | 3.6 kB  00:00:00
centosplus                                                                   | 3.4 kB  00:00:00
epel/x86_64/metalink                                                         | 5.8 kB  00:00:00
epel                                                                         | 4.3 kB  00:00:00
extras                                                                       | 3.4 kB  00:00:00
rpmforge                                                                     | 1.9 kB  00:00:00
updates                                                                      | 3.4 kB  00:00:00
(1/8): base/7/x86_64/group_gz                                                | 154 kB  00:00:00
(2/8): epel/x86_64/group_gz                                                  | 169 kB  00:00:00
(3/8): epel/x86_64/updateinfo                                                | 370 kB  00:00:00
(4/8): extras/7/x86_64/primary_db                                            |  88 kB  00:00:00
(5/8): epel/x86_64/primary_db                                                | 3.6 MB  00:00:00
(6/8): centosplus/7/x86_64/primary_db                                        | 1.9 MB  00:00:01
(7/8): base/7/x86_64/primary_db                                              | 5.1 MB  00:00:02
(8/8): updates/7/x86_64/primary_db                                           | 4.0 MB  00:00:02
rpmforge/primary_db                                                          | 125 kB  00:00:00
Determining fastest mirrors
 * base: ftp.jaist.ac.jp
 * centosplus: ftp.jaist.ac.jp
 * epel: ftp.riken.jp
 * extras: ftp.jaist.ac.jp
 * rpmforge: ftp.riken.jp
 * updates: ftp.jaist.ac.jp
88 packages excluded due to repository priority protections
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ java-1.7.0-openjdk.x86_64 1:1.7.0.85-2.6.1.2.el7_1 を 更新
---> パッケージ java-1.7.0-openjdk.x86_64 1:1.7.0.91-2.6.2.1.el7_1 を アップデート
---> パッケージ java-1.7.0-openjdk-headless.x86_64 1:1.7.0.85-2.6.1.2.el7_1 を 更新
---> パッケージ java-1.7.0-openjdk-headless.x86_64 1:1.7.0.91-2.6.2.1.el7_1 を アップデート
--> 依存性解決を終了しました。

依存性を解決しました

====================================================================================================
 Package                           アーキテクチャー
                                                バージョン                      リポジトリー   容量
====================================================================================================
更新します:
 java-1.7.0-openjdk                x86_64       1:1.7.0.91-2.6.2.1.el7_1        updates       204 k
 java-1.7.0-openjdk-headless       x86_64       1:1.7.0.91-2.6.2.1.el7_1        updates        25 M

トランザクションの要約
====================================================================================================
更新  2 パッケージ

総ダウンロード容量: 25 M
Is this ok [y/d/N]: y
Downloading packages:
updates/7/x86_64/prestodelta                                                 | 250 kB  00:00:00
Delta RPMs reduced 25 M of updates to 1.5 M (94% saved)
(1/2): java-1.7.0-openjdk-1.7.0.85-2.6.1.2.el7_1_1.7.0.91-2.6.2.1.el7_1.x86_ |  40 kB  00:00:00
(2/2): java-1.7.0-openjdk-headless-1.7.0.85-2.6.1.2.el7_1_1.7.0.91-2.6.2.1.e | 1.4 MB  00:00:00
Finishing delta rebuilds of 2 package(s) (25 M)
----------------------------------------------------------------------------------------------------
合計                                                                 37 kB/s | 1.5 MB  00:00:40
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  更新します              : 1:java-1.7.0-openjdk-headless-1.7.0.91-2.6.2.1.el7_1.x86_64         1/4
warning: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.91-2.6.2.1.el7_1.x86_64/jre/lib/security/US_export_policy.jar created as /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.91-2.6.2.1.el7_1.x86_64/jre/lib/security/US_export_policy.jar.rpmnew
warning: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.91-2.6.2.1.el7_1.x86_64/jre/lib/security/java.security created as /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.91-2.6.2.1.el7_1.x86_64/jre/lib/security/java.security.rpmnew
warning: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.91-2.6.2.1.el7_1.x86_64/jre/lib/security/local_policy.jar created as /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.91-2.6.2.1.el7_1.x86_64/jre/lib/security/local_policy.jar.rpmnew
  更新します              : 1:java-1.7.0-openjdk-1.7.0.91-2.6.2.1.el7_1.x86_64                  2/4
  整理中                  : 1:java-1.7.0-openjdk-1.7.0.85-2.6.1.2.el7_1.x86_64                  3/4
  整理中                  : 1:java-1.7.0-openjdk-headless-1.7.0.85-2.6.1.2.el7_1.x86_64         4/4
warning: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.85-2.6.1.2.el7_1.x86_64/jre/lib/security/local_policy.jar saved as /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.85-2.6.1.2.el7_1.x86_64/jre/lib/security/local_policy.jar.rpmsave
warning: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.85-2.6.1.2.el7_1.x86_64/jre/lib/security/US_export_policy.jar saved as /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.85-2.6.1.2.el7_1.x86_64/jre/lib/security/US_export_policy.jar.rpmsave
  検証中                  : 1:java-1.7.0-openjdk-headless-1.7.0.91-2.6.2.1.el7_1.x86_64         1/4
  検証中                  : 1:java-1.7.0-openjdk-1.7.0.91-2.6.2.1.el7_1.x86_64                  2/4
  検証中                  : 1:java-1.7.0-openjdk-1.7.0.85-2.6.1.2.el7_1.x86_64                  3/4
  検証中                  : 1:java-1.7.0-openjdk-headless-1.7.0.85-2.6.1.2.el7_1.x86_64         4/4

更新:
  java-1.7.0-openjdk.x86_64 1:1.7.0.91-2.6.2.1.el7_1
  java-1.7.0-openjdk-headless.x86_64 1:1.7.0.91-2.6.2.1.el7_1

完了しました!

■PHPでファイルがアップロードできない場合は、まずphp.iniの下記の設定を変更する。

upload_max_filesize 　→　アップロードされるファイルの最大サイズ

アップロードしたいファイルサイズがupload_max_filesizeを超えていたら、アップロードできない。

そんな時はupload_max_filesizeの設定値を増やしてあげる。

ただし、この値の変更時は、下記2つの設定値にも注意する必要がある。

memory_limit 　→　スクリプトが確保できる最大メモリ
post_max_size 　→　POSTデータに許可される最大サイズ

上記3つの項目が下記のような関係になるように設定しなければいけない。

memory_limit >= post_max_size >= upload_max_filesize

例として、ファイルサイズを32MBまで許容する設定にする。
php.iniを直接編集する

/etc/php.ini（保存場所は違う可能性がある）を直接編集。

実際はこんな風に綺麗に3行並んでいない。
<pre>[root@server1 ~]# vi /etc/php.ini

memory_limit = 128M

post_max_size = 32M

upload_max_filesize = 32M</pre>

Anacronから以下のメッセージが届いた

/etc/cron.daily/0yum.cron:
There are unfinished transactions remaining. You might consider running yum-complete-transaction first to finish them.

実行中のyumのトランザクションが残っているので yum-complete-transaction せよとのこと。昨日サーバのバックアップのことで色々と作業していたのが原因かも・・

[root@server1 ~]# yum-complete-transaction

yum update してみる

[root@server1 ~]# yum update
Loaded plugins: downloadonly, fastestmirror, priorities, refresh-packagekit, security
Loading mirror speeds from cached hostfile
* base: ftp.tsukuba.wide.ad.jp
* centosplus: ftp.tsukuba.wide.ad.jp
* epel: mirror01.idc.hinet.net
* extras: ftp.tsukuba.wide.ad.jp
* updates: ftp.tsukuba.wide.ad.jp
99 packages excluded due to repository priority protections
Setting up Update Process
No Packages marked for Update

特に問題なさそう。

CentOS6でのcron/anacronが少々変わった。今までは# crontab -e で設定してたが、/etc/cron.dにて時間指定することにした。また、特に時間指定しなくても良さそうなものは/etc/cron.dailyにスクリプトを入れておく。
メインサーバ

[root@server1 ~]# echo "*/1 * * * * root /usr/ddns/ddo.jpIP_upgrade.pl" > /etc/cron.d/ddns
[root@server1 ~]# echo "0 2 * * * root /root/mysqldump.sh" > /etc/cron.d/mysqldump
[root@server1 ~]# echo "30 2 * * * root /root/backup.sh" > /etc/cron.d/backup
[root@server1 ~]# mv chkrootkit /etc/cron.daily/
[root@server1 ~]# mv clamscan /etc/cron.daily/
yumはyum-cronで自動更新
[root@server1 ~]# yum -y install yum-cron
[root@server1 ~]# /etc/rc.d/init.d/yum-cron start
[root@server1 ~]# chkconfig yum-cron on
[root@server1 ~]# chkconfig --list yum-cron
[root@server1 ~]# yum -y groupinstall "Base" "Development tools"

[root@server1 ~]# crontab -e
全て削除

予備サーバ

[root@server2 ~]# echo "30 3 * * * root /root/backuprsync.sh" > /etc/cron.d/backuprsync
[root@server2 ~]# echo "30 4 * * * root /root/backupshare.sh" > /etc/cron.d/backupshare
[root@server2 ~]# echo "30 5 * * * root /root/restore.sh" > /etc/cron.d/restore
[root@server2 ~]# echo "0 6 * * * root /root/mysqldump.sh" > /etc/cron.d/mysqldump
[root@server2 ~]# echo "30 6 * * * root /root/backup.sh" > /etc/cron.d/backup
[root@server2 ~]# mv chkrootkit /etc/cron.daily/
[root@server2 ~]# mv clamscan /etc/cron.daily/
yumはyum-cronで自動更新
[root@server2 ~]# yum -y install yum-cron
[root@server2 ~]# /etc/rc.d/init.d/yum-cron start
[root@server2 ~]# chkconfig yum-cron on
[root@server2 ~]# chkconfig --list yum-cron
[root@server2 ~]# yum -y groupinstall "Base" "Development tools"

[root@server2 ~]# crontab -e
全て削除

以前は予備サーバーは決められた時間に起動しバックアップ等が終わったらシャットダウンする設定にしていたが、予備サーバーもファイルサーバーの関係で24時間稼働させることにしたので、メインサーバー、予備サーバーとも crontab の設定を変更。
■メインサーバー

[root@server1 ~]# crontab -e
*/1 * * * * /usr/ddns/ddo.jpIP_upgrade.pl
00 02 * * * /root/chkrootkit.sh
10 02 * * * /root/clamscan.sh
00 03 * * * /root/yum_upgrade.sh
30 03 * * * /root/mysqldump.sh ; /root/backup.sh

■予備サーバー
[root@server2 ~]# crontab -e

30 04 * * * /root/backuprsync.sh ; /root/backupshare.sh
30 05 * * * /root/restore.sh
00 06 * * * /root/chkrootkit.sh
10 06 * * * /root/clamscan.sh
00 07 * * * /root/yum_upgrade.sh
30 07 * * * /root/mysqldump.sh ; /root/backup.sh

2013年3月9日 CentOS 6.4 がリリースされた。
CentOS 6.4 Release Notes
http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.4
Direct Download
i386 – http://mirror.centos.org/centos/6/isos/i386/
x86_64 – http://mirror.centos.org/centos/6/isos/x86_64/
CentOSはいわゆるRPM系Linuxに属しており、パッケージ管理システムとしてYumを採用しているので、マイナーバージョンはyum updateでアップデートできる。だが、カーネルは再起動しないと反映されないので、yum update後は再起動しておく。
CentOSのバージョンは、メジャーバージョンとマイナーバージョンの二つより構成され、今回は、2013年2月21日にリリースされたRHELのバージョンアップに対応したものである。
ちなみに今までのバージョンとリリース日

バージョン　　　　　　　　　リリース日
CentOS 4 （4.0）	2005年03月09日
CentOS 5 （5.0）	2007年04月12日
CentOS 6 （6.0）	2011年07月09日
（6.1）	2011年12月09日
（6.2）	2011年12月20日
（6.3）	2012年07月09日
（6.4）	2013年03月09日

yumでアップデートして再起動

[root@server1 ~]# yum update
[root@server1 ~]# shutdown -r now

バージョン確認

[root@server1 ~]# cat /etc/redhat-release
CentOS release 6.4 (Final)

カーネル確認

[root@server1 ~]# uname -r
2.6.32-358.0.1.el6.centos.plus.x86_64

アップデートするとWebサーバのドキュメントルートの所有者がrootに戻るので所有者変更しておく

[root@server1 ~]# chown higo:higo /var/www/html/
[root@server1 ~]# ll /var/www/
合計 20
drwxr-xr-x  9 root root 4096  3月 11 06:01 2013 awstats
drwxr-xr-x  2 root root 4096  2月 22 20:20 2013 cgi-bin
drwxr-xr-x  3 root root 4096  3月 11 03:14 2013 error
drwxr-xr-x 42 higo higo 4096  2月 22 20:20 2013 html
drwxr-xr-x  3 root root 4096  3月 11 03:19 2013 icons

自宅サーバーを構築した頃はサーバーもクライアントも文字コードをeucにしていたが、CentOS4以降、標準文字コードがutf-8になった。特にSSHなどでサーバーにリモート接続して操作する場合にはサーバーとクライアントの文字コードが違うと文字化けが発生してしまう。また、MySQLを使ったブログなどは文字コードが違うと後で直すのは更に厄介だ。今までは文字化けしないように騙し騙しやってきてたが、今回、サーバーをCentOSの64bit版、utf-8で再構築したので、昔からのMySQLのデータもすべてをutf-8で統一することにした。どうすればいいのかネットで調べてもなかなか有力な情報が得られなかったが、下記の方法でなんとかutf-8に統一することが出来た。
まず、phpmyadminで確認すると、データベースはeucjpms_japanese_ci、各テーブルはlatin1_swedish_ciになっている。テーブルの中身もしっかり文字化けしている。

当然この状態でテーブルの照合順序をutf-8にしても、データベース全体をutf-8にしても文字化けは解消されない。また、mysqldumpでエクスポートしたものも、文字化けしているテーブルと文字化けしていないテーブルがある。なので、各テーブルごとにmysqldumpでエクスポート、各テーブルごとに文字化けを修正し文字コードをutf-8にして保存。直した各テーブルをmysqlでインポートすることでほぼ文字化けが解消した。
手順は下記の通り
phpmyadminでデータベースのテーブルを確認し全テーブルをbackupフォルダにエクスポート。mysqlのrootパスワード(********) データベース名(centos) テーブル名(nucleus_item) 保存フォルダ場所(backup)の場合

[root@server1 ~]# mysqldump -uroot -p******** centos nucleus_item --default-character-set=binary > /backup/nucleus_item.sql

mysqldumpでエクスポートしたそれぞれのテーブルのデータをテキストエディタで開き、latin1になってたところをutf8に修正、文字化けしてないか確認し、文字化けしてるようであれば文字化けが解消する文字コードで一旦読み込み、文字化けを直してから文字コードをutf-8nに指定して保存。文字化けしてなければそのまま文字コードをutf-8nに指定して保存。

修正が終わったらそれぞれのテーブルをmysqlコマンドでインポート。

[root@server1 ~]# mysql -uroot -p******** centos --default-character-set=binary < /backup/nucleus_item.sql

mysqlでインポートする際、幾つかのテーブルがエラーになったが、どうもデータ容量が大きいためらしい。デフォルトの最大サイズは1Mらしいので、大きいデータでもインポート出来るように16Mに変更。
/etc/my.cnfを修正。

[root@server1 ~]# vi /etc/my.cnf
[mysqld]
max_allowed_packet=16M　←　追加

最後に、phpmyadminでデータベースの照合順序をeucjpms_japanese_ciからutf8_general_ciに変更。あとはNucleusのグローバル設定の使用する言語をjapanese-eucからjapanese-utf8に変更。設定画面上のサイト名が文字化けしてたが手入力で修正。これでサーバーとクライアントの文字コードがutf-8で統一され文字化けが解消した。

Thumbnailデータはどの文字コードで読み込んでもことごとく文字化けしてて修正不能だった為、一旦データそのものをMySQLから削除して作業続行。

Thumbnailプラグインもバージョンが上がってたので新しいものをインストール。テーブルを作りなおすことで文字化けが解消した。