Linuxサーバー

XNAMEをセカンダリDNSとして使う

プライマリDNSは自宅サーバで、セカンダリDNSはXNAMEを利用することにしていた。プライマリDNSがとりあえず機能していたため、セカンダリDNSとして使用していたXNAMEとの連携ができていない事を把握していながら、しばらく放置していた。

XNAMEと連携できていない「not available」

どのような症状だったかというと、xnameのコントロールパネル上（右上図）に

wingnotes.net (S)    Logs
    ns0.xname.org.    not available    zone content
    ns1.xname.org.    not available    zone content
    xxx.xxx.xxx.xxx    not available    zone content

「not available」となっていてxnameにゾーン転送が行われていない模様。

xnameのコントロールパネル[zone content]で、ゾーン情報を確認しようとしても、xnameから自宅サーバのDNSにアクセスができていないようだ。（↓）

Zone content for wingnotes.net on server xxx.xxx.xxx.xxx
; <<>> DiG 9.3.4 <<>> axfr wingnotes.net @xxx.xxx.xxx.xxx
; (1 server found)
;; global options: printcmd
;; connection timed out; no servers could be reached

xnameと連携できない原因究明＆対策

原因を推測する。
①ルーターのフォーワード設定に不備がある
②ファイアーウォールで通信がブロックされている
③BINDがゾーン転送できていない

tailコマンドを使って、bindのログを監視する。
XNAMEのコントロールパネルから「zone content」をクリックしてもBINDのログは何の変化も無し。うちのルータ（Gateway）ではUDP 53ポートへのアクセスがDNSサーバーにフォワードされる設定になっている。まず関係ないと思いながらもルーター（Gateway）にTCP 53ポートもフォワードするように設定を追加。UDP 53ポートは元もとアクセス許可済み（①の対策）
さらにDNSサーバーのファイアーウォール（iptables）にTCP 53ポートへのアクセスおよび送出を許可する（②の対策）

そしてもう一度XNAMEのコントロールパネルから「not available」をクリックしてみた。すると BINDのログに次のように出た。

Jun 29 16:25:15.520 queries: info: client 92.243.14.172#33204: query:
wingnotes.net IN AXFR Jun 29 16:25:15.520 security: error: client 92.243.14.172#33204: zone transfer
'wingnotes.net/IN' denied

おおっ！プライマリのDNS（BIND）が反応している。ただし、ゾーン転送は denied （＝拒否された）と出ている。拒否しているクライアントIPアドレス 92.243.14.172 は何なのだろうか。調べてみると www.xname.org の様だ。XNAMEの管理画面を動かしているWebサーバーのようである。
それまでBINDの設定ファイル named.conf でセカンダリDNSにゾーン転送を許可しているのは
・ns0.xname.org　（195.234.42.1）
・ns1.xname.org　（87.98.164.164）
の二つであった（2008.6.29時点）。

とりあえず named.conf の転送設定「allow-transfer」に www.xname.org （92.243.14.172） を追加する。（↓）

zone "wingnotes.net" IN {
    type master;
    notify yes;
    file "wingnotes.net.zone";
    allow-transfer {
        195.234.42.1; /* ns0.xname.org */
        87.98.164.164; /* ns1.xname.org */
        92.243.14.172; /* www.xname.org */
    };
};

DNSとプロトコル「TCP」

XNAMEのコントロールパネルの「zone content」の結果には「; <<>> DiG 9.3.4 <<>> axfr wingnotes.net @xxx.xxx.xxx.xxx」と出ているので、www.xname.org上ではDigコマンドがたたかれているようだ。DiGコマンドはプロトコルTCPを使うのか？？DNSはTCPでもレスポンスを返すのか？？ ここで、ルータのフォワードにTCP 53ポートを追加した事でアクセスできるようになったのはなぜだろう？管理人は「DNSはUDPポートを使う」と思いこんでいた。

ネットで情報を探すと仙石浩明の日記の記事には、

DNS問合わせというと、ネームサーバの UDP/IP の 53番ポートへ問合わせるのが一般的であり、 TCP/IP の 53番ポートはゾーン転送のみに使われることが多い。しかし RFC (RFC1035 および RFC2136) 上は TCP も、UDP と同様、通常の問合わせにも利用することができることになっているし、多くのネームサーバでそのような実装になっている。

と書いてあった。ゾーン転送はTCPを使う事があり、さらに通常のDNS問い合わせもTCPでもOKという事らしい。これまでうちのサーバーではTCP 53ポートを完全にブロックしていた。これがXNAMEとDNS連携取れなかった原因だったらしい。

xnameへゾーン転送できた

NAMEDを再起動する。
しばらくログを見ていると、、、

Jun 29 18:32:57.918 queries: info: client 92.243.14.172#36434: query:
wingnotes.net IN AXFR Jun 29 18:32:57.918 xfer-out: info: client 92.243.14.172#36434: transfer of 'wingnotes.net/IN': AXFR started

と「www.xname.org」へゾーン転送されている模様。（↑）
さらに「ns0.xname.org」へのゾーン転送も確認できた。（↓）

Jun 29 16:36:38.399 queries: info: client 195.234.42.1#63154: query: wingnotes.net IN AXFR
Jun 29 16:36:38.399 xfer-out: info: client 195.234.42.1#63154: transfer of 'wingnotes.net/IN': AXFR started

XNAMEのコントロールパネルで[zone content]で、ns0.xname.orgのゾーン転送状態を確認すると、きちんと転送されていた。（↓）

Zone content for wingnotes.net on server ns0.xname.org.
; <<>> DiG 9.3.4 <<>> axfr wingnotes.net @ns0.xname.org.
; (1 server found)
;; global options: printcmd
wingnotes.net. 86400 IN SOA ns1.wingnotes.net. xxxxxx.xxxxx.xxxxx.
2008051303 3600 1800 864000 3600
wingnotes.net. 86400 IN A xxx.xxx.xxx.xxx
wingnotes.net. 86400 IN NS ns0.xname.org.
wingnotes.net. 86400 IN NS ns1.xname.org.
wingnotes.net. 86400 IN NS ns1.wingnotes.net.
wingnotes.net. 86400 IN NS ns2.xname.org.
ftp.wingnotes.net. 86400 IN A xxx.xxx.xxx.xxx
mail.wingnotes.net. 86400 IN MX 10 mail.wingnotes.net.
mail.wingnotes.net. 86400 IN A xxx.xxx.xxx.xxx
ns1.wingnotes.net. 86400 IN A xxx.xxx.xxx.xxx
wnsvr.wingnotes.net. 86400 IN A xxx.xxx.xxx.xxx
www.wingnotes.net. 86400 IN A xxx.xxx.xxx.xxx
wingnotes.net. 86400 IN SOA ns1.wingnotes.net. xxxxxx.xxxxx.xxxxx.
2008051303 3600 1800 864000 3600
;; Query time: 7 msec
;; SERVER: 195.234.42.1#53(195.234.42.1)
;; WHEN: Sun Jun 29 14:35:09 2008
;; XFR size: 14 records (messages 1)

うーん、DNSって奥深い。しかも少々間違った設定のままでも不具合無いように動いてしまうから怖い。

2008/06/29 16:52 | コメント (0)  トラックバック (0)         Linuxサーバー TOPへ

SMARTによるHDD（ハードディスク）異常の検知

サーバーから次のような異常を知らせるメールが届いた。

Subject: SMART error (CurrentPendingSector) detected on host: wnsvr.wingnotes.net

This email was generated by the smartd daemon running on:

host name: wnsvr.wingnotes.net
DNS domain: wingnotes.net
NIS domain: (none)

The following warning/error was logged by the smartd daemon:
Device: /dev/hda, 61 Currently unreadable (pending) sectors
For details see host's SYSLOG (default: /var/log/messages).
You can also use the smartctl utility for further investigation
.
No additional email messages about this problem will be sent.

半年前の日記サーバーのHDDから異音にも書いた。その後しばらく異音は落ち着いていたがとうとう寿命が来たのかもしれない。いろいろネットで情報を探していたら、smartctl コマンドでHDDの状態を調べる事ができるらしい。 そもそも、SMARTDというデーモン稼働していることで、HDDの異常を検知すると管理者にメール連絡してくれる。SMARTに対応しているHDDである事が前提との事。

SMARTとは

そもそもSMARTとは？

「S.M.A.R.T.」（Self-Monitoring, Analysis and Reporting Technology System)

というんだって。IDE Harddisk の故障・不具合を事前に検査し、故障の前触れを察知する技術。ハードウェアとソフトウェアの組み合わせで実現している機能のようだ。Linux上ではSMARTDというデーモンがそのソフトウェアにあたる（？）。

HDDの状態を調べるために、コマンド smartctl を実行してみた。

# smartctl -a /dev/hda

=== START OF INFORMATION SECTION ===
Device Model: ST340810A
Serial Number: 6FB2210N
Firmware Version: 3.60
User Capacity: 40,020,664,320 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 6
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Fri Jul 4 01:17:22 2008 JST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
（中略）
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 061 051 025 Pre-fail Always - 69989819
3 Spin_Up_Time 0x0003 098 098 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 177
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 1
7 Seek_Error_Rate 0x000f 073 060 030 Pre-fail Always - 133933183465
9 Power_On_Hours 0x0032 062 062 000 Old_age Always - 33675
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 364
194 Temperature_Celsius 0x0022 046 051 000 Old_age Always - 46
195 Hardware_ECC_Recovered 0x001a 100 253 000 Old_age Always - 0
197 Current_Pending_Sector 0x0012 095 095 000 Old_age Always - 61
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 181 000 Old_age Always - 1825
200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0
202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0

さて、いろいろな情報が出力されているが、それぞれのATTRIBUTE（属性）が何を意味しているのか、よくわからない。
ネット探していたら
smartmontoolsで取得できるSMART情報一覧
という何ともすばらしいサイトを見つけた！

そのなかでHDDがこれだけのログを取っていたんだという事に驚いた。
起動回数　177回や
稼働時間　33675H→4年弱稼働している
温度　　　　46℃

ふむふむ。

SMART情報一覧ページのクリティカル度の高いヤバいエラーをみると

　・Reallocated_Sector_Ct
　・Current_Pending_Sector

あぁ、、、出てますね。。。。
そのほか、Seek_Error_Rate が 133933183465 と飛び抜けている。
これは早急にHDD交換した方がよいな。

Windows版SMART（フリーツール）

さて、今回SMARTについていろいろ調べていたら、フリーのWindows版SMARTツールがもるようですね。
早速ダウンロードしてWinマシンに入れてみました。HDDの管理に結構使えそうです。

Win版フリーのSMART診断ツール
HDD Health
日本語化　RiKu's On-Line

2008/07/04 10:23 | コメント (0)  トラックバック (0)         Linuxサーバー TOPへ

ハードディスクの温度をグラフ化するには

先日の日記「HDD（ハードディスク）の寿命か」にも書いたが、SMARTを使ってHDD（ハードディスク）の温度を取得できる事がわかった。データが取れるという事はこのデータをもとにMRTGでグラフにできるはず。普段からHDDがどのくらいの温度環境にいるのかわかったらいいなぁ。と思いネットで調べてみた。

ハードディスクの温度を取得する

まず、MRTGでグラフのソースとなるHDDの温度を返すシェル（バッチ）を作成する。これはsmartコマンドの結果から'Temperature'の値を抽出するバッチ。うちのサーバー環境に合わせて2つ搭載されているHDDの温度を取るコマンドを2行書いた。このコマンドはこのサイト備忘録::Naka MRTGでCPU温度とHDD温度もグラフ化を参考にさせて頂いた。

#/bin/sh
/usr/sbin/smartctl -A /dev/hda | grep Temperature | awk '{print $10}'
/usr/sbin/smartctl -A /dev/hdb | grep Temperature | awk '{print $10}'

適当にファイル名を付け（私の環境ではhdd_temp.sh）て保存。正しく温度を返すかこのシェルを実行してみる。

[root@xxxx mrtg]# ./hdd_temp.sh
55
51
[root@xxxx mrtg]#

55℃と51℃を返した。コマンドはOK。でもハードディスクの温度55℃は高いなー。。。

MRTGの設定

次にこのシェルの結果を基データとしてMRTGでグラフ化して表示させる。MRTGの設定ファイル /etc/mrtg/mrtg.cfg に、このデータをグラフ化する設定を追記。

### HDD Temperature ###
Target[hddtemp]: `/etc/mrtg/hdd_temp.sh`
MaxBytes[hddtemp]:100
Unscaled[hddtemp]:dwmy
Options[hddtemp]: gauge, growright, noinfo , nopercent
Title[hddtemp]: HDD Temperature
PageTop[hddtemp]: >H1&st;HDD Temperature Green:hda Blue:hdb>/H1<
ShortLegend[hddtemp]: (Celsius)
YLegend[hddtemp]: HDD Temperature(Celsius)
LegendI[hddtemp]: hda
LegendO[hddtemp]: hdb
Legend1[hddtemp]: hda(Celsius)

この設定では“Target[hddtemp]: `/etc/mrtg/hdd_temp.sh`”でHDD温度を取得している。次のコマンドを実行してグラフが作成されるか動作確認を行う。

[root@xxxx mrtg]# /etc/mrtg/mrtg.sh

特にエラーがでなかった。実際にHTMLとグラフが作成されているかサイトにアクセスする。HTMLのファイル名はhddtemp.htmlで出力されているはずなので、URL直打ちで確認。正常に出力されていた。

indexmakerでMRTGのTOPページを作成する

最後に、MRTGのサマリページ（index.html）に今回追加したHDD温度のグラフを追加する。MRTGにはmakeindexというperlで書かれたindexを作成してくれるツールが用意されている。このコマンドの使い方を忘れてしまったので、ネットで調査。ここのサイトMRTGのインデックスページ作成 （indexmaker）を参考にさせてもらった。私の環境の場合は次のコマンドを使用した。

indexmaker /etc/mrtg/mrtg.cfg > /var/www/xxxx/mrtg/index.html

2008/08/03 21:53 | コメント (0)  トラックバック (0)         Linuxサーバー TOPへ

CentOSをインストールする

そうしょっちゅう行うものではないが、OSインストール時に毎回ネットから情報を収集して作業するのも面倒くさくなってきたので、備忘録的にWebにメモっておく。ここではインストールCDをisoから作成し、インストール、インストール後の各種設定を快適に行うための環境設定メモを記載している。

インストールしたOSの種類とバージョン

OS：CentOS バージョン5.2

LinuxインストールCDを作成する

CentOSのサイトからインストールCDのイメージ（isoイメージ）をダウンロードし、インストールCDを作成する。
CDを使用してのインストールに必要なISOイメージは
  CentOS-(バージョン番号)-i386-bin-1of6.iso
   ：
  CentOS-(バージョン番号)-i386-bin-6of6.iso
の6つ（6CD）を用意。
※インストール時に選択するモジュールによっては使用しないCDもある。

＜参考情報＞
Creator Classic で ISO イメージファイルから書き込む方法
http://www2.roxio.jp/support/faq/ecdc/E_F70040.html

CentOSをインストールする

ファイアウォール

インストール時にとりあえず次のポートの通信を許可する。
  ・http 　　　　　　webサーバへのアクセスに使用
  ・ftp 　　　　FTP通信に使用
  ・samba(smb) 　Windowsファイル共有に使用
  ・ssh 　　　　　　ターミナル接続に使用
  ・vncserver 　　　　　リモートアクセスに使用
  ・smtp 　　　　　　メール送信に使用

＜参考情報＞
Linuxのファイアウォールは「iptables」というプログラムで動作する。
インストール完了後に再度ファイアーウォールの見直しを行う。
http://penguin.nakayosi.jp/linux/iptables.html

CentOSインストール完了後のサービスの設定

次のサービスを使えるように基本的な設定を行う。
  ・sshd
  ・vncserver
  ・samba(smb)

sshd

rootのログインを制限する・指定したユーザー以外のログをンを禁止するには次の設定ファイルを編集する。
   /etc/ssh/sshd_config

PermitRootLogin no
AllowUsers ユーザ名

sshdを再起動する。

vncserver

何かと便利なデスクトップGNOMEのツールを使用したいので、GUIのリモート作業ができるようにvncserverの環境を構築する。
1,設定ファイルを編集する。
  /etc/ssh/sshd_config

$geometry = "1024x768";
$depth = 16;

2,vnc接続許可ユーザの設定を行う
  /etc/sysconfig/vncservers

VNCSERVERS="1:ユーザー名"
VNCSERVERARGS[1]="-geometry 1024x756 -nolisten tcp -nohttpd"

3,vnc接続許可ユーザファイルの作成
作成したいユーザでログインする。

su xxxxxx
パスワード：

次のコマンドを打つ
vncserver

vnc接続用パスワードを入力する。

4,xwindow(gnome)が起動するように設定する。
/home/ユーザ名/.vnc/xstartup を編集する。

#xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
#twm &

上記2行の先頭に#を付けて、コメントアウトする。

exec gnome-session &

と1行記述し、vnc接続時にxwindow(gnome）が起動するように指定する。

5,vncserverを再起動する。

samba(smb)

1,linux上のファイルにWindows共有でアクセスするユーザー作成する。

smbpasswd -a ユーザー名
パスワード：

2,共有の設定・共有させるディレクトリを指定する
  /etc/samba/smb.conf

ワークグループ名やアクセスを許可するネットワークを指定する

workgroup=ワークグループ名
hosts allow = 192.168.10. 127.

LinuxとWindowsの文字コードの変換設定を追記する

dos charset = CP932
unix charset = UTF8
display charset = UTF8

共有するLinux上のディレクトリを指定する。

[public] #セクション名（任意）
　　　comment = public directory
　　　path = /var/public
　　　valid users = 接続許可するsmbユーザ名
#　　invalid users = 接続拒否するsmbユーザ名
#　　guest ok = ok
#　　only guest = ok
#　　public = yes
#　　browseable = yes
　　 writable = yes
　　 printable = no

3,smbを起動する。

2008/08/27 15:30 | コメント (0)  トラックバック (0)         Linuxサーバー TOPへ

Windows環境からLinuxのファイルシステムにアクセスするにはsambaを使用すれば実現できる。 逆にLinuxからWindows上の共有フォルダにアクセスするにはどうしたらよいか？

調べてみたら次の方法がある事がわかった。

①mountをつかう
②smbmountをつかう

mountでWindows共有にアクセスする

１、マウントポイントを作成する

　　※以下の場合では /mnt/win_share

２、mountコマンドでWindows共有フォルダにマウントする。
　　※以下の場合では、Windowsの共有フォルダshareに対してマウントしている。
　　　文字コード（cp932やutf8）は適宜環境に合わせる。

mount -t cifs -o username=common,codepage=cp932,iocharset=utf8 //windowsサーバ名（またはIPアドレス）/share /mnt/win_share

smbmountでWindows共有にアクセスする

Linuxにsambaをインストールしている場合は、smbmountという便利なコマンドが使える。

Windows共有フォルダにアクセスする時のユーザーを指定する事ができる。

smbmount //Windowsサーバ名（またはIPアドレス）/share /mnt/win_share/ -o username=administrator

注）ソースからsambaをインストールした場合、インストール時に --with-smbmount オプションを付けてコンパイルする必要あり。

そのほか様々なオプションがあるので、こちらを参考に。 http://www.samba.gr.jp/project/translation/3.0/htmldocs/smbmount.8.html

2008/09/01 09:53 | コメント (0)  トラックバック (0)         Linuxサーバー TOPへ

BINDのセキュリティ強化？

BINDを9.3.4にバージョンアップした時の話。
BIND9.3.4インストール後、namedが起動できないワナに陥った。

rndc.key作成したりゾーンファイルを配置後、service コマンドを使ってnamedを起動してみると「失敗」する。

BIND UDPクエリソースポートのランダム化

named起動時にログに何かはき出されていないか、syslogを観察してみる。

Aug 18 23:37:27 wnsvr named[18965]: /etc/named.conf:38: using specific query-source port suppresses port randomization and can be insecure.
Aug 18 23:37:27 wnsvr named[18965]: command channel listening on 127.0.0.1#953

と出ていた。このエラーメッセージを元に、ネットで調べていると
http://www.jp.debian.org/security/2008/dsa-1603　に情報があった。

この更新では Debian の BIND 9 パッケージに推奨された対応策 (UDP クエリソースポートのランダム化) を実装しました。この変更は攻撃者が推定しなければならない探索空間のサイズを、後方互換性を守る形で拡大し、攻撃の成功を困難にします。
：
このようなメッセージが吐かれている場合、設定から対象となる行を削除するか、記載されているポート番号を "*" に置き換えてください (例えば、 "port 53" を "port *" に書き換える)。

との事で、うちのサーバのOSはDebianではないが、同様の対応は入っていると思われた。named.confファイルには

query-source address * port 53;

と53ポートを指定していたのだが、この指定が良くなかったようだ。指示されたようにnamed.ｃｏｎｆを書き換えて再起動してみる。しかし、syslogには特にエラーは出なくなったが、まだ「失敗」となって起動できない。
namedのログを別にはき出す設定にしているので、そちらを観察してみる。そうすると

19-Aug-2008 00:03:24.887 general: debug 1: now using logging configuration from config file
19-Aug-2008 00:03:24.887 general: critical: couldn't open pid file '/var/run/named/named.pid': Permission denied
19-Aug-2008 00:03:24.887 general: critical: exiting (due to early fatal error)

と、今度はアクセス権の問題がわざわいしていたようだ。
ただ、ディレクトリ /var/run/named/ のパーミッションを見直しても現象は変わらず、何がいけないか？？と悩んでいたが、chrootしている事を思い出す。
ディレクトリ /var/named/chroot/var/run/named/ のアクセス権を見直して、無事起動できた。
　

2008/09/02 18:05 | コメント (0)  トラックバック (0)         Linuxサーバー TOPへ

MySQLを使う理由

これまでDBといえばPostgresqlをメインに使用してきたためMySQLの使い方は特に知らなかった。というか知らなくて済んだ。またxoopsをPostgresqlで使っていたのだが拡張性に優れず、いろいろ問題に直面していたため、本来のMySQLに戻す事にした。

Postgressqlは仕事でもよく使っていたので、結構細かい事もわかるのだが、MySQLについては知識が浅い。とりあえずMySQLを使う為に必要な情報をメモ書きする。

MySQLの起動

service mysqld { start | stop | restart | status }

MySQLのデータ格納パス

デフォルトのMySQLのデータ格納パスは

/var/lib/mysql

初期状態からのrootパスワードの変更

初めてMySQLを起動すると、いろいろなものが初期化される。MySQLを操作する管理ユーザー root　のパスワードも初期状態では設定されていないようなので、rootにパスワードを付与する

/usr/bin/mysqladmin -u root password 'パスワード'

ログイン（パスワード要求）

rootでMySQLにログインする。（この場合はDB指定無し）

mysql -u root -p

DBの作成

とりあえずデータベースを作成してみる。mysqlにログイン後に次のSQLを実行する。
データベースの文字コードを指定したい場合は“CHARACTER SET ujis”のようにCHARACTER SET XXXXと付ける。ちなみにこの例の場合、 "ujis" はEUC-JPを指定している。

create database DB名 CHARACTER SET ujis;

MySQL5のデフォルト文字コードは latin1。今回使おうとしているxoopsの文字コードはEUC-JPなため、ujisを指定して作ってみた。ここは各自、自分の環境に合わせて頂きたい。

ユーザーの作成とデータベースへのアクセス権限付与

rootユーザのみでもデータベース操作は可能だが、rootでDBを操作させるのはセキュリティ的に危険。故に指定したDBのみ操作可能なユーザーを作成する。

grant all privileges on DB名.* to ユーザー名@localhost identified by 'パスワード' with grant option;

MySQLのバックアップ

/usr/bin/mysqldump DB名 -u ユーザー名 -pパスワード -x > バックアップファイル名

※この時、-pの後にスペースは入れない

2008/09/03 08:25 | コメント (0)  トラックバック (0)         Linuxサーバー TOPへ

OSを入れ替えた際、PHPとMySQLのバージョンアップがくっついてきた。 PHP4とPostgreSQLで動作する変則的になXOOPSで構築していたものが、新しいこの環境だと動かない。

PHP5では「$HTTP_SERVER_VARS」変数が使えない

PHP5では「$HTTP_SERVER_VARS」変数が使えなくなったらしい。次のサイト PHPスクリプト講座:サーバ変数についてに、

PHP5以降では「register_long_arrays」という設定値がOFFであれば$HTTP_SERVER_VARSは使えません。

とある。ただ、これはphp.iniファイルの設定で使えるようにできるとの事。php.iniの次の設定をONにすればよい。

register_long_arrays = Off　→　On

しかし、これだけではまだPHPのエラーが出てダメであった。

PHP5のPHP4互換モード

ネットで情報収集していると、PHP5をPHP4として動作させる設定があるみたい。

PHP 5には、PHP 4（Zend Engine 1）との互換性を保つための設定ディレクティブが用意されている。下記のディレクティブをphp.iniに挿入すると、PHP 5はZend Engine 1（PHP 4）互換モードで動作する。

zend.ze1_compatibility_mode On

この設定で、XOOPSが動くようになるか？と思ったが、結局これも動かなかった。 最終的にはPHP5で古いXOOPSを動かすのは諦めた。

XOOPS動作に必要なMySQL5の文字コード指定

そこで、PHP5とMySQL5で動作するXOOPS Cubeに入れ替える事にした。

動作環境 | XoopsCubeのサイトには、「PHP5以上であっても問題なく動作する。」と書かれているので、最新版をDLする。この時の最新版バージョンは　「XOOPS Cube Legacy 2.1.5」
MySQLに関しては特に何も気にせず適当にDBを作成した。適当というのは、文字コードの指定など特にせず、デフォルトで作った。ということ。
XOOPS Cubeの初期設定も問題なく完了。いざ出来上がったサイトにアクセスしてみると、メニューなどの文字が「??????」と表示される。テンプレートに書かれている文字は問題なく表示されている。どうもDBから取得している文字の文字コードが怪しい。

ネット上には同じような問題が起こっている方がいらっしゃって、Xoops Cube文字化け解消！には

原因は単純でMySQLのCHARACTER SETでした。だってー、CentOSに入ってるMySQLのdefault CHARACTER SETってlatin1なんだもん、、、cp1252 West European [ latin1_swedish_ci ]ってなんだよー。

とのこと。デフォルトの文字コードはujis（EUC-JP）でもなく、UTF-8でもないんだって。でもってなんでlatin1なんだ！？と思ってしまった。 DBを作成する時に、次のように文字コードをujis（EUC-JP）で指定してあげる必要がある。とのこと。

create database db_name CHARACTER SET ujis;

そこで、DBの作り直しから。

PHP5とMySQL5で動作するXOOPSのバージョン

DBの環境は揃った。同じようにXOOPS Cubeの初期セットアップを行い、問題なく完了。 とりあえず文字化けは直ったが、管理機能を使用しようとしても画面に管理項目が表示されない。（メニュー一覧は表示されているのだが）

最新のソースがいけないのか、XOOPS Cube Legacyにある旧安定番 XOOPS 2.0.16a JP をインストール。（文字コードはEUC） このバージョンだと問題なく動いた。

最終的にPHPとMySQL、XOOPS Cubeの組み合わせは次のようなバージョンの組み合わせとなった。

CentOS 5.1
PHP 5.1.6
MySQL 5.0.45 （ujisの設定で使用）
Xoops 　XOOPS 2.0.16a JP

2008/09/05 16:28 | コメント (0)  トラックバック (1)         Linuxサーバー TOPへ

XOOPS Cube　と MySQL

前回の日記XOOPS Cube と PHP5, MySQL5 の相性でも書いたが、新しいバージョンのOS、PHP、MySQLでXOOPSを再構築した時に、MySQL5でのDB作成時にどつぼにはまっていた。

既に作成済みのDBの文字コードを変更する

とりあえずXOOPSの動作確認が取れた時のMySQLのデフォルトで作成した文字コードがlatin1のDBで、XOOPSの設定やコンテンツを登録したため、後になって問題が出てきた。

その問題とは、DBをバックアップ（ダンプ：mysqldump）した時に、ダンプファイルをテキストエディタで開くと、文字化けしているのである。無理矢理文字コードを変換すれば日本語で読める文字に直せるのだろうけど、今後の運用で問題となりそうなので、ujis（EUC-JP）へ変換（データマイグレーション）できないか調べてみた。

既に文字コードが latin1 で作成されたMySQLのDBを、構造と格納されているデータはそのまま、ujis（EUC-JP）に変換したいのだ。

ネットでこのようなMySQLの文字コードマイグレーションをされている方の情報を探す。

あんじーのテクニカルブログさんのサイトで、文字コードを変換する方法が紹介されていたので、この方法を試してみた。

文字コード変更の大まかな手順

１，DBをbinaryでダンプを取る。
２，ダンプファイル内のSQLでlatin1に指定されている構造部分のSQLをujisに手作業で変換する
３，ダンプファイルをujiでレストアする。

DBの文字コードをlatin1からujis(EUC-JP)に変更する手順

まず、現状のDBがどのような文字コード設定になっているかSQLを叩いて確認

mysql> show variables like '%char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.02 sec)

フムフム。DBは確かに「latin1」で作られているみたい。

mysqldump --default-character-set=binary -u ユーザ名 DB名 --password=パスワード > ダンプの出力ファイルパス

出力されたダンプファイルをテキストエディタで開いて、charsetが指定されている箇所をlatin1からujisへ全て置換する。 次に、ujisに置換したダンプファイルからDBをレストアする。

mysql -u ユーザ名 -p DB名 --default-character-set=ujis < ダンプファイル名

mysql> show variables like '%char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.01 sec)

alter database でキャラセットをujisに変更する。

mysql> alter database DB名 character set ujis;
Query OK, 1 row affected (0.00 sec)

構造を確認する。

mysql> show variables like '%char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | ujis |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

databaseの文字コードがujisに変わっている。

MySQLの設定ファイル（/etc/my.cnf）の修正を行う。

[mysqld]
default-character-set=ujis
skip-character-set-client-handshake

を設定ファイルに追加して、MySQLを再起動する。

service mysqld start

再起動後のDBの構造を確認

mysql> show variables like '%char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | ujis |
| character_set_connection | ujis |
| character_set_database | ujis |
| character_set_filesystem | binary |
| character_set_results | ujis |
| character_set_server | ujis |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

これで文字コードが latin1 だったMySQLのデータベースが、ujis(EUC-JP)のデータベースとして使用する事ができる。 これで元もとlatin1の文字コードだったDBをujis（EUC-JP）のDBへ移行する作業が完了。

2008/09/29 18:33 | コメント (0)  トラックバック (0)         Linuxサーバー TOPへ