UNIXやLinuxの最近のブログ記事

先月からずっと原因も解決策もわからず悶々としてるんだけど・・・

qmail で構築しているメールサーバがあるのね。(qmail を使っていることの是非についての意見は聞きません。qmail 使用でパッケージ化されているシステムなのと、qmail がどうの、オリジナルの sendmail がどうの、postfix がどうこうという話は宗教感の違いでしかないので(笑))

で、そのメールサーバで空メールを受け取ってあれこれ処理をして結果をメールで返してるんだけど・・・

Gmail からメールした時だけ、

The recipient server did not accept our requests to connect. Learn more at https://support.google.com/mail/answer/**20 [mail.exsample.jp. xxx.xxx.xxx.xxx: unable to read banner]

というエラーになる。

IIJ Gio、NTT PC WebARENA、GMO クラウドなどのサーバ上から送信したメールはちゃんと処理される。

また、俺の実メールアドレスに転送する test という alias を作ってテストをしてみても、やっぱり同じエラーになるのでプログラムが悪いわけではない。

そうそう、Yahoo! の Web メールもちゃんと届く。本当にうまくいかないのは Gmail だけなのである。
ちなみに、gmail.com のアカウントから送っても、他のアカウントを From にセットして送っても一緒である。

しょうがないので、さっき postfix でメールサーバを再構築してみた。
そしたら、ちゃんと Gmail から空メールを送ってプログラムを実行することも、test というメールに送って俺の実メールに転送することも成功した。

どうも、Gmail+qmail サーバのみの問題のようだ。

もちろん、qmail サーバの設定がおかしいという可能性もあるが、Yahoo!メールや、他のレンタルサーバ上に構築されたメールサーバからの送信では問題が発生しない。そう考えると qmail の設定の問題というわけではないだろう。

netstat でみると、

tcp        1      0 adm01:smtp              mail-io1-f51.goog:30637 CLOSE_WAIT

という具合に SMTP のポートに接続には来ているようだ。qmail が反応しないんだなあ。

とりあえず、上記のように postfix でシステム再構築をしてうまくいっているのだが、はっきり qmail で駄目だった原因がわからないとどうにもすっきりしない。
原因がわかるという識者の方がいらっしゃれば、ぜひご教授ください。
今回、新たにセットアップしたサーバで CGI から MySQL への接続がうまくいかない。

環境は、

CentOS 7.4(1708)
Apache 2.4.39
MySQL 8.0.16
Perl 5.16.3
DBI 1.627
DBD::mysql 4.023

というソフトウェア構成。

Apache は systemd(init に変わる起動処理やシステム管理を行う仕組み)を使って起動している。
(systemctl start httpd.service というコマンドで起動しているというわけね)

で、この環境で、CGI から DBI/DBD 経由で MySQL にアクセスすると、

Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

というエラーが発生してしまう。

しかし、/tmp/mysql.sock は存在している。権限関係も問題ない。

# ls -la /tmp/mysql*
srwxrwxrwx 1 mysql mysql 0 May 31 09:55 /tmp/mysql.sock
-rw------- 1 mysql mysql 5 May 31 09:55 /tmp/mysql.sock.lock

いやぁ、ハマったわぁ~(^^;

結局、オチから言うと、これって systemd の PrivateTmp 機能による問題で、例えばソケットの置き場所を /var/lib/mysql/mysql.sock とかにしていた人には発生しない。

どういうことかというと、今回、ソースビルドした Apache についても systemd で管理(起動等)をしているのは上に書いたとおり。
で、systemd 経由で起動したデーモン(今回は Apache)は、それぞれ独自の /tmp ディレクトリが用意される。

つまり、Apache 上で実行される CGI プログラムが見ている /tmp と、本来の /tmp ディレクトリは全然別物なので、いくら MySQL が(本来の)/tmp ディレクトリ上にソケットファイル(mysql.sock)を用意しても、CGI プログラムからは見えないのである。

結果、

DBI connect('dbname=hoge_db;host=localhost;port=3306;mysql_socket=/tmp/mysql.sock','hoge_admin',...) failed: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) at ./db_connect_test.pl line 42.

というエラーとなってしまう。
反対に、ソケットファイルの置き場を /tmp ではなく /var/lib/mysql/mysql.sock などにしていた場合は CGI からも見ることができる。これは、/tmp(/var/tmp も?)だけの問題である。

tmp は temporary の略で、/tmp ディレクトリというのは文字通り「一時ファイル」の置き場所。そのため、誰でも読み書きできるようになっており、それを専用に用意することで安全性や利便性を上げようって思想なんだろうけど、裏目に出たなあ>俺のところでは(^^;

ちなみに、じゃあ、プロセス毎の /tmp ってどこにあるの?というと、/tmp ディレクトリの下にある。

# ls -lad /tmp/systemd*
drwx------ 3 root root 4096 Apr 20  2016 /tmp/systemd-private-4ee168e88455407fa3b27bd35ffb371d-ntpd.service-1GgKhB
drwx------ 3 root root 4096 May 22 16:24 /tmp/systemd-private-bf1b49c0e6014448894be7a3091317ee-ntpd.service-5jH2a8
drwx------ 2 root root 4096 Feb  8  2016 /tmp/systemd-private-W69tS0
# ls -la /tmp/systemd-private-4ee168e88455407fa3b27bd35ffb371d-ntpd.service-1GgKhB
total 12
drwx------  3 root root 4096 Apr 20  2016 .
drwxrwxrwt 13 root root 4096 May 31 14:44 ..
drwxrwxrwt  2 root root 4096 Apr 20  2016 tmp
# ls -la /tmp/systemd-private-4ee168e88455407fa3b27bd35ffb371d-ntpd.service-1GgKhB/tmp
total 8
drwxrwxrwt 2 root root 4096 Apr 20  2016 .
drwx------ 3 root root 4096 Apr 20  2016 ..

こういう具合に、systemd が /tmp の下にそれぞれのプロセスごとに専用の /tmp を用意している。

じゃ、どうするかって話なんだけど、ソケットファイルを /tmp 以外のディレクトリに置けばいいんだけど、もう多くの CGI などで明示的に /tmp/mysql.sock を指定しているので全部直すのも大変。

とりあえず、sysytemd 経由での起動をやめる。
手動で apachectl コマンドを叩いて実行。

# systemctl stop httpd
# /usr/local/apache2/bin/apachectl start
# ps auxww|grep http
root     21911  0.0  0.2 114864  4516 ?        Ss   13:45   0:00 /usr/local/apache-2.4.39/bin/httpd -k start
apache   21912  0.0  0.1 114656  2756 ?        S    13:45   0:00 /usr/local/apache-2.4.39/bin/httpd -k start
apache   21913  0.0  0.1 401692  3328 ?        Sl   13:45   0:00 /usr/local/apache-2.4.39/bin/httpd -k start
apache   21914  0.0  0.1 401692  3324 ?        Sl   13:45   0:00 /usr/local/apache-2.4.39/bin/httpd -k start
apache   21916  0.0  0.1 401692  3324 ?        Sl   13:45   0:00 /usr/local/apache-2.4.39/bin/httpd -k start
root     22011  0.0  0.0 112708   948 pts/1    S+   13:45   0:00 grep --color=auto http

これで、CGI からも MySQL へのアクセスが可能となった。

systemd の PrivateTmp 機能を無効にする方法を調べるまでは、とりあえずこの運用とする。
そうか。CentOS7 では daemon の自動起動設定や起動、停止コマンドは chkconfig や service じゃないのか・・・(^^;

現在借りている CentOS6 のレンタルサーバ(root 権限有り)のサービスが終了するということなので、他の会社の CentOS7 のサーバ借りて設定してるんだけど、なんか 6→7 は随分変わってるのね。

sshd の自動起動の設定がどうなっているのか調べようと思って、

# chkconfig --list sshd

したら、

Note: This output shows SysV services only and does not include native
      systemd services. SysV configuration data might be overridden by native
      systemd configuration.

      If you want to list systemd services use 'systemctl list-unit-files'.
      To see services enabled on particular target use
      'systemctl list-dependencies [target]'.

error reading information on service sshd: No such file or directory

とか怒られるし、sshd の再起動しようと思って、

# service sshd restart

したら、

Redirecting to /bin/systemctl restart sshd.service

って。systemctl にリダイレクトされとる(^^;

どうも、自動起動設定や起動、停止等のコマンドは systemctl に移行したんだな。

chkconfig の代わりに

# systemctl list-unit-files|grep sshd
sshd-keygen.service                           static
sshd.service                                  enabled
sshd@.service                                 static
sshd.socket                                   disabled

とかすれば自動起動が ON になっているかわかる(enabled が ON ね)し、systemctl restart sshd とすれば再起動ができる。(sshd の部分は sshd.service でも sshd だけでも良いみたいだ)

systemctl restart sshd
systemctl status sshd
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2019-05-24 10:50:35 JST; 9s ago
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 27691 (sshd)
   CGroup: /system.slice/sshd.service
           └─27691 /usr/sbin/sshd -D

こんな感じ。

ところで、/etc/rc.d/init.d の下に置いていた起動、停止等の操作用のシェルスクリプトってどこに行ったんやろ???
/usr/lib/systemd/system/ の下にあるファイルは違うしなあ???

サーバに Apache 等をソースからインストールするのだが、今回はインストールソフトウェアの管理に porg(Source Code Package Organizer)を使おうと思う。

porg は「ソースコードからビルドを行ったパッケージソフトウェアなどを管理するためのパッケージ管理ツール」だそうだ。
パッケージ化したソフトウェア情報を参照したり(インストールされたファイルの一覧や、コンパイルオプションなども見れる)、アンインストールをしたり出来るげな。

今まで一度も使ったことがないし、当然インストールをしたこともないので、ここにメモっておく。

1.ソースのダウンロード

# cd /usr/local/src

2.ソースの展開とディレクトリ移動

# tar xvfz porg-0.10.tar.gz
porg-0.10/
porg-0.10/ChangeLog.paco
porg-0.10/aclocal.m4
porg-0.10/doc/
porg-0.10/doc/index.html
porg-0.10/doc/porgrc.5.in
porg-0.10/doc/porgball.8.in
porg-0.10/doc/grop.png
<略>
porg-0.10/grop/porgball.h
porg-0.10/grop/lock.h
porg-0.10/grop/preferences.h
porg-0.10/INSTALL
porg-0.10/config-bot.h.in
# cd porg-0.10

3.configure の実行

CentOS 6.5 環境 + g++ 4.4.7 という環境だが、そのまま configure を行うと、

cc1plus: error: unrecognized command line option "-std=c++11"

というエラーが出てしまう。

このサイトによると、4.4系だと -std=c++0x にしろということのようなので、そのように修正する。

configure ファイルの 17,437行目を

MY_CXXFLAGS="$MY_CXXFLAGS -ansi -pedantic -Wall -fno-operator-names -std=c++0x -Wno-deprecated-declarations"

と修正した。

で、configure 実行。

# ./configure --prefix=/usr/local --disable-grop

FHS(Filesystem Hierarchy Standard)的には --sysconfdir=/etc を付けるべきだったが、ま、いっか(^^;

4.make とインストール

# make

make install 時に porg 自体も porg でパッケージとして管理するため、make したばかりの porg を使って make install を行う。

# ./porg/porg -lD make install

オプションの意味は、'l'がログを取る、'D'がディレクトリ名(porg-0.10)をパッケージ名にするという意。

以上でインストールは終了なので、実際に porg が porg 自身によって管理されているか見てみる。

# porg -f porg
porg-0.10:
/usr/local/bin/paco2porg
/usr/local/bin/porg
/usr/local/bin/porgball
/usr/local/etc/bash_completion.d/porg_bash_completion
/usr/local/etc/porgrc
/usr/local/lib/libporg-log.a
/usr/local/lib/libporg-log.la
/usr/local/lib/libporg-log.so
/usr/local/lib/libporg-log.so.0
/usr/local/lib/libporg-log.so.0.0.0
/usr/local/share/man/man5/porgrc.5
/usr/local/share/man/man8/porg.8
/usr/local/share/man/man8/porgball.8
/usr/local/share/porg/README
/usr/local/share/porg/download.png
/usr/local/share/porg/faq.txt
/usr/local/share/porg/index.html
/usr/local/share/porg/porg.png
/usr/local/share/porg/porgrc

パッケージ名 porg-0.10 でインストールされたファイルの一覧が取得できた。

バッチリ。
どうせ無制限で sudo できる設定をするくらいなら、普通に su すればいいだけじゃん・・・と思うんだけど、世の中にはインターネットの情報だけでサーバ管理者になっちゃった人も多くて、そういう人が(ちゃんと理由も検証せず)「root になって作業するなんて危ない!sudo して作業するべき!!」とか小うるさいことを言うのよね。

"わかってる"人は「そんなの人それぞれ。好きなようにやりゃあいいんじゃないの」って言うけどね。特に自分が root のパスワードを知っている管理者ならね。
sudo なんて、本来は「準管理者」な人に「インストールだけは許す」とか、そういうゆるい制限をかけるためのもんでしょ?

とは言うものの、パパっとインストールしちゃいたい時は(セキュアだ、どうだ、という問題ではなく)sudo して済ましちゃった方が良い場合もある。

今まで sudo 設定をしてなかったサーバにも、とりあえず設定しちゃおう・・・という話。

$ sudo ls
[sudo] password for hoge:<hoge のパスワード入力>
hoge is not in the sudoers file.  This incident will be reported.

hoge ユーザは sudoers ファイルに設定がないので sudo 出来ない。
ディフォルト状態では、/etc/sudoers には root の設定しかされていないからな。

## Allow root to run any commands anywhere
root    ALL=(ALL)       ALL

この設定ね。

ここに、hoge も追加してやればいい。

# ls -la /etc/sudoers
-r--r----- 1 root root 4002 Mar  2  2012 /etc/sudoers

ファイルはこのように、root ユーザでも書き込み出来ないパーミッションになっているが、w! して強制的に書き込めばいいので、俺は普通に vi で編集。

# vi /etc/sudoers

## Allow root to run any commands anywhere
root    ALL=(ALL)       ALL
hoge    ALL=(ALL)       ALL ←追加

これで、

# exit
logout
$ sudo ls
[sudo] password for hoge:<hoge のパスワード入力>
api_test_data  code.dmp  systemmst.dmp  test  test.pl

こんな感じで hoge ユーザで sudo が可能となる。

ちなみに、「vi で sudoers を編集するの、怖いよ」というビビリのために visudo という vi ライクなエディタが用意されているが、どうしてこのエディタを使ったら安全なのかよくわからん。別に vi だろうが visudo だろうが、sudoers ファイルを編集するのは一緒だろ?
なんか、vi にはない良い機能があるの?"絶対"visudo を使うべき!派の意見を聞いてみたいね(笑)
Raspberry Pi3(Raspbian)で /var/log/mesages に、

Feb 13 12:59:39 host1 rsyslogd-2007: action 'action 17' suspended, next retry is Mon Feb 13 13:01:09 2017 [try http://www.rsyslog.com/e/2007 ]

というメッセージが出続けている。

これ、Raspbian jessie のベースとなった Debian jessie のバグらしい。


rsyslog.conf に、X Window System を立ち上げてなくても、/dev/xconsole に対してメッセージを出力しようとする設定が書かれているためのようだ。

なので、手っ取り早いのはこの設定をコメントにして無効にしてしまうこと。
コメントにしちゃうと、/dev/xconsole にエラーメッセージなども送られなくなっちゃうけど、わしら「X は日頃立ち上げてないけんね」というサーバ使いにとっては問題あるまい。

# cp /etc/rsyslog.conf /etc/rsyslog.conf_20170213
# vi /etc/rsyslog.conf
# diff /etc/rsyslog.conf /etc/rsyslog.conf_20170213
118,122c118,121
< # 2017/02/13 comments (debian bug)
< #daemon.*;mail.*;\
<       #news.err;\
<       #*.=debug;*.=info;\
<       #*.=notice;*.=warn      |/dev/xconsole
---
> daemon.*;mail.*;\
>       news.err;\
>       *.=debug;*.=info;\
>       *.=notice;*.=warn       |/dev/xconsole

このようにコメントにして、rsyslog の再起動。

# service rsyslog restart
# tail /var/log/messages
<略>
Feb 13 16:16:35 host1 rsyslogd-2007: action 'action 17' suspended, next retry is Mon Feb 13 16:18:05 2017 [try http://www.rsyslog.com/e/2007 ]
Feb 13 16:25:44 host1 rsyslogd-2007: action 'action 17' suspended, next retry is Mon Feb 13 16:27:14 2017 [try http://www.rsyslog.com/e/2007 ]
Feb 13 16:25:44 host1 rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="527" x-info="http://www.rsyslog.com"] exiting on signal 15.
Feb 13 16:25:45 host1 rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="16645" x-info="http://www.rsyslog.com"] start

この後、メッセージは出なくなったので OK なんじゃろね。

余談だが、Raspbian(ラズビアン)という OS の名前は「レズビアンみたいでいやらしい!」と思う性欲の強い方も中にはいらっしゃるでしょうが、これはベースになった Linux ディストリビューション Debian(デビアン)の名前を継承しているから。

ちなみに、Debian という名前は、最初にディストリビューションを立ち上げた Ian Ashley Murdock が、当時のガールフレンドの名前 Debra Lynn と自分の名前 Ian を組み合わせて Debian としたわけで、もちろんレズビアンもデロリアンも関係ないので気をつけてほしい(笑)
例えば、

http://www.exsample.com/cgi-bin/test.cgi

にアクセスすると、

#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "Hello, World.";

のような、CGI プログラムのソースが表示されてしまう。

さて、今回は Debian 系のパッケージ、いわゆる APT パッケージの Apache 2.4 を入れてみた。
RedHat 系世界の住民の俺から見ると、頭がおかしいんじゃないか?と思うような Apache 設定ファイルの構成である。

てか、俺は Apache に関しては「ソースからインストール派」なので、RPM パッケージの Apache の設定ファイル群にもイラっとさせられるんだけどね(笑)
まあ、この辺は宗教問題なのでこれ以上の言及は控えておきましょう(笑)

CGI プログラムのソースが表示されてしまう件に話を戻す。

まず、VirtualHost 設定の該当部分。

/etc/apache2/sites-available/www.exsample.com.conf の中に、

    ScriptAlias /cgi-bin/ "/usr/local/share/apache/cgi-bin/"

    <Directory "/usr/local/share/apache/cgi-bin">
        AllowOverride All
        Options +ExecCGI

        AddHandler cgi-script .cgi .pl

        Require all granted
    </Directory>

という記述あり。

なんか、ScriptAlias と Handler/ExecCGI の設定が二重にされてますけど(^^;
まあ、ScriptAlias してるんだから +ExecCGI は不要だと思うけど、現行、これで問題なく動いているので、とりあえずこれで良しとする(笑)

で、実際に CGI module を読み込んでるんかいな?と確認してみると、

# apache2ctl -M
Loaded Modules:
 core_module (static)
 so_module (static)
 watchdog_module (static)
 http_module (static)
 log_config_module (static)
 logio_module (static)
 version_module (static)
 unixd_module (static)
 access_compat_module (shared)
 alias_module (shared)
 auth_basic_module (shared)
 authn_core_module (shared)
 authn_file_module (shared)
 authz_core_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 deflate_module (shared)
 dir_module (shared)
 env_module (shared)
 filter_module (shared)
 mime_module (shared)
 mpm_event_module (shared)
 negotiation_module (shared)
 setenvif_module (shared)
 status_module (shared)

ありり?cgi_module がロードされてませんねえ。

# ls -la /etc/apache2/mods-available/cgi.load
-rw-r--r-- 1 root root 58  7月  6  2016 /etc/apache2/mods-available/cgi.load

cgi.load というファイルはあるので、こいつのシンボリックリンクを /etc/apache2/mods-enabled の下に作ってやる。

ln コマンド使って手動でやればすぐだが、せっかくなので a2enmod コマンドを使ってみる。
これ、シンボリックリンクを作ってくれるだけのコマンドのようだ。こんなコマンドの使い方を覚えている暇があれば、さっさと手動でリンクしちゃった方が早いじゃんとか言いながら笑ってはいけない。Debian 信者からむっちゃこのコマンドの正当性を説明されるで(笑)

# ls -la /etc/apache2/mods-enabled/*cgi*
ls: /etc/apache2/mods-enabled/*cgi* にアクセスできません: そのようなファイルやディレクトリはありません
# a2enmod cgi.load
Your MPM seems to be threaded. Selecting cgid instead of cgi.
Enabling module cgid.
To activate the new configuration, you need to run:
  service apache2 restart
# ls -la /etc/apache2/mods-enabled/*cgi*
lrwxrwxrwx 1 root root 27  1月 18 17:31 /etc/apache2/mods-enabled/cgid.conf -> ../mods-available/cgid.conf
lrwxrwxrwx 1 root root 27  1月 18 17:31 /etc/apache2/mods-enabled/cgid.load -> ../mods-available/cgid.load

素晴らしい(笑)

しかし、俺は cgi モジュールをロードしたかったのに、なぜに cgid が???

cgid って、Perl とかの生エラーメッセージをログに吐いてくれないからいやなんよね。

ま、いっか(^^; 今度時間が出来たら対応しよう。

で、サーバ再起動。

# service apache2 restart

CGI モジュールも、

# apache2ctl -M|grep cgi
 cgid_module (shared)

無事ロードされたね。

これで、

http://www.exsample.com/cgi-bin/test.cgi

にアクセスすると、

Hello, World

と表示されるようになる。

どう?RedHat 系世界の住民の皆さん。気持ち悪いでしょ?(笑)
若干のトラブルはあったものの(^^;、新しい OS イメージの展開に成功したので、それを Raspberry Pi の起動ディスク(SDHC カード)に焼き付ける。

今、俺んちにあるマシンで SD カードが刺さるのって MacBook Pro だけなので(Windows 機のメモリカード I/F 全部壊れてもうた。なんでじゃろ?(^^;)、作業は OS X のシェル上で行なう。

まず、MacBook Pro に SD カードを刺す。今回は、I-O データ製の 32GB SDHC カードを使用。

シェル上でカードが認識されていることを確認。
(ちなみにワシ、sudo じゃなくて root で作業する派なので悪しからず(sudo 派、うるせえからなあ(^^;))

# diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS osx                     499.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     Apple_partition_scheme                        *24.1 MB    disk1
   1:        Apple_partition_map                         32.3 KB    disk1s1
   2:                  Apple_HFS PX504A_JPN_OSX_3783_41B 24.0 MB    disk1s2
/dev/disk2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *30.9 GB    disk2
   1:             Windows_FAT_32 NO NAME                 30.9 GB    disk2s1
/dev/disk3
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *4.4 GB     disk3
   1:             Windows_FAT_32 boot                    66.1 MB    disk3s1
   2:                      Linux                         4.3 GB     disk3s2

disk2 として認識されているのがわかる。

これ、そのまま dd コマンドでイメージを焼き付けようとすると、

# dd bs=1m if=/Users/shinoda/2016-11-25-raspbian-jessie.img of=/dev/disk2
dd: /dev/disk2: Resource busy

という具合に Resource busy になっちゃうので、File System から SD カードを一旦 unmount する。
カードそのものではなく、論理ディスクだけをね。

# diskutil umount /dev/disk2s1
Volume NO NAME on disk2s1 unmounted

そして、dd コマンドでディスクイメージを焼き付け。

# dd bs=1m if=/Users/shinoda/2016-11-25-raspbian-jessie.img of=/dev/disk2
4169+0 records in
4169+0 records out
4371513344 bytes transferred in 2087.134050 secs (2094505 bytes/sec)

結構時間がかかる。
うちの(8年前に購入した)MacBook Pro のシェル上だと30分くらいかかった。

20170103_raspberry.JPG
もう一度 diskutil list コマンドで確認すれば、SD カードが Linux の boot ディスクになっているのがわかる。
書き込みは成功。

/dev/disk2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *30.9 GB    disk2
   1:             Windows_FAT_32 boot                    66.1 MB    disk2s1
   2:                      Linux                         4.3 GB     disk2s2

正常に書き込みが終了したら、SD カードそのものを unmount する。

# diskutil unmountDisk /dev/disk2
Unmount of all volumes on disk2 was successful

MacBook Pro から SD カードを抜いて Raspberry Pi に刺し、電源を入れれば Raspbian が起動するぞ。
20170101_raspberrypi1.JPG
事務所のサーバを、でっかい DELL のタワー型サーバから Raspberry Pi 3 に置き換えようと思ってる。
Raspberry Pi 3 は年末の Amazon で買ったら、急ぎ配送で元旦に届いた(笑)
ええと、Amazon 配送による運送屋さんの作業過多が社会問題になってましたが、ごめんなさい。俺のような客がいるからですね。正月の配達、ありがとうございました(^^;

まあ、それはそれとして(^^;

さっそく、最新の OS(RASPBIAN JESSIE WITH PIXEL Kernel 4.4)を、


から「Download ZIP」ボタンクリックで落としてきた。

2016-11-25-raspbian-jessie.zip

これを Mac OS X 標準のアーカイバーで解凍すると、

2016-11-25-raspbian-jessie.zip.cpgz

という、なんか知らない拡張子のファイルに・・・ img ファイルにならない。
いきなり作業中断。こんなところで悩むことになるとは思っていなかった(^^;

結局、StuffIt Expander で解凍したら問題なく

2016-11-25-raspbian-jessie.img

に解凍された。

ググってみると「バージョンの古いStuffIt Expander(ver 8.0.2)で解凍しないとだめだった」という情報もあったんだけど、うちは 15.0.7a という新しい(どの程度新しいものなのか不明なのだが)バージョンで OK だった。
なんか、cpgz になるにも色々なパターンがあるみたいやなあ。「拡張子が zip なのに、中身はテキストファイルだった」とか「古いアーカイバソフトで圧縮したため」とか、原因も色々あるみたいなんで、解決策も色々ってことだろうな。

ま、これで先に進めます(笑)
IIJ GIO ホスティングパッケージで提供されているサーバが 2台あって、仮に A.exsample.com と B.exsample.com とする。
この 2台の保守を依頼されたんだけど、なんか、A の時刻は合ってるのに、B の方は 8分ほどずれている。

どちらのサーバにも ntpd は入ってないようなので、IIJ のマニュアルを調べてみると「IIJ GIOホスティングパッケージのCentOS5は、初期状態ではXenの機能を使用してハイパーバイザと時刻を同期するように設定されています。」と。
確かに、A の方が CentOS 5 で、B の方が CentOS 6 のようだ。

試しに、A の方で確認してみると、

# /sbin/sysctl -n xen.independent_wallclock
0

と、ハイパーバイザとの時刻同期が有効な状態にあるという結果が返ってくる。("1"だと無効)

B の方で確認すると、

# /sbin/sysctl -n xen.independent_wallclock
error: "xen.independent_wallclock" is an unknown key

となる。

CentOS 6 環境も Xen 上で提供されていると思うんだけど、こっちは端からハイパーバイザとの時刻同期とはなっていないようですなあ。

ということで、Xen はよく知らないので、手っ取り早く NTP(Network Time Protocol)で時刻同期を行うことにする。

まず、yum を使ってパッケージのインストール。

# yum -y install ntp

ntp-4.2.6p5-10.el6.centos.1.x86_64 がインストールされる。

自動実行ファイルなんかも入ってるね。

# ls -la /etc/rc.d/init.d/ntp*
-rwxr-xr-x 1 root root 1923 May  4  2016 /etc/rc.d/init.d/ntpd
-rwxr-xr-x 1 root root 2043 May  4  2016 /etc/rc.d/init.d/ntpdate

まず、NTP はあまりに時間がかけ離れていると同期に時間がかかるので(って、最近もそうなん?以前はそうだった。あ、20年くらい前の話ね(笑))、ある程度手動で時刻を合わせておこう。

# date
Thu Dec  8 11:45:02 JST 2016
# date -s "12/08 11:53 2016"
Thu Dec  8 11:53:00 JST 2016

8分遅れていたので調整。

# date
Thu Dec  8 11:53:05 JST 2016

ちゃんと時刻が変更されている。
実際の時間とは数十秒ずれているだろうが、ここで ntpdate の実行。

# date
Thu Dec  8 11:55:27 JST 2016
# ntpdate ntp00.iij.net
 8 Dec 11:55:49 ntpdate[9221]: step time server 210.130.188.10 offset 21.042093 sec
# date
Thu Dec  8 11:55:53 JST 2016

21秒ほどあった差が修正された。
あとは、自動的に同期が行われるよう、ntpdデーモンを起動しておく。

まず、/etc/ntp.conf の上位サーバを変更。
上位サーバには全て IIJ が提供しているものを選んだ。

# cp /etc/ntp.conf /etc/ntp.conf_20161208
# vi /etc/ntp.conf
# diff /etc/ntp.conf /etc/ntp.conf_20161208
22,28c22,25
< #server 0.centos.pool.ntp.org iburst
< #server 1.centos.pool.ntp.org iburst
< #server 2.centos.pool.ntp.org iburst
< #server 3.centos.pool.ntp.org iburst
< server ntp00.iij.net
< server ntp01.iij.net
< server ntp02.iij.net
---
> server 0.centos.pool.ntp.org iburst
> server 1.centos.pool.ntp.org iburst
> server 2.centos.pool.ntp.org iburst
> server 3.centos.pool.ntp.org iburst

自動起動の設定を忘れないうちにやっておこう。

# chkconfig --list ntpd
ntpd            0:off   1:off   2:off   3:off   4:off   5:off   6:off
# chkconfig ntpd on
# chkconfig --list ntpd
ntpd            0:off   1:off   2:on    3:on    4:on    5:on    6:off

で、デーモン起動。

# service ntpd start
Starting ntpd:                                             [  OK  ]

同期状況確認。

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp00.IIJ.Net   210.130.188.1    3 u    6   64    1    1.108    0.055   0.002
 ntp01.IIJ.Net   210.130.188.1    3 u    6   64    1    1.481    0.266   0.002
 ntp02.IIJ.Net   210.130.188.1    3 u    5   64    1    1.063    0.068   0.002

さすが、同じ社内の NTP サーバ。同期が早い。起動したとたんに同期したで。
あ、さっき手動で ntpdate コマンド実行したからか(^^;

左に * がついている ntp00.IIJ.Net が、時刻同期している上位NTPサーバ。

もう一回実行してみる。

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ntp00.IIJ.Net   210.130.188.1    3 u   25   64    7    1.114    2.955   2.291
+ntp01.IIJ.Net   210.130.188.1    3 u   29   64    7    1.488    3.068   2.217
+ntp02.IIJ.Net   210.130.188.1    3 u   28   64    7    1.130    2.903   2.255

ntp01.IIJ.Net や ntp02.IIJ.Net の横に + マークがついたけど、これは「同期候補にあがっている」サーバだということ。
例えば現在同期サーバである ntp00.IIJ.Net に何かあった場合は(多分、反応に時間がかかってるとか)、この + マークが付いているサーバが同期に使われる。

ばっちりやね。

このアーカイブについて

このページには、過去に書かれたブログ記事のうちUNIXやLinuxカテゴリに属しているものが含まれています。

前のカテゴリはMacです。

次のカテゴリはWindowsです。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。


月別 アーカイブ

電気ウナギ的○○ mobile ver.

携帯版「電気ウナギ的○○」はこちら