tftp サーバー on Ubuntu12.04.1

Ubuntu 12.04.1 に tftp サーバーを入れた時のメモ。

$ sudo apt-get install tftpd

設定ファイルが /etc/xinetd.d/tftp にあるはず、、なのに何も作ってくれてない。

そこで、 RHEL マシンから設定ファイルを持ってきた。

/etc/xinetd.d/tftp


# default: off
# description: The tftp server serves files using the trivial file transfer \
#       protocol.  The tftp protocol is often used to boot diskless \
#       workstations, download configuration files to network-aware printers, \
#       and to start the installation process for some operating systems.
service tftp
{
        disable = no
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -s /var/lib/tftpboot
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
}

一箇所ハマった点。
tftp はデフォルトではクライアントからの put での新規ファイル作成はできないようになっている。
（すでに存在するファイルへの上書きはできる。）
そこで、以下のように -c をつけておくと、新規作成もできるはず、、

        server_args             = -c -s /var/lib/tftpboot
RHEL ではこれでうまくいったが、Ubuntu だと、 -c がついていると、get も put も 「Transfer timed out」になってしまって、さっぱり動きません。
セキュリティ上の配慮なんでしょうか。。

というわけで、新規作成はあきらめることにしました。
とりあえず一番やりたいことは、 u-boot からの kernel ダウンロードだから、get さえできれば、ひとまずはOKです。

ntpdate と ntp daemon on Ubuntu

Ubuntu 12.04.1 LTS で ntp daemon をインストールした。

Ubuntu では標準で ntpdate がインストールされている。

両者の違いは以下のような感じと思っている。

・ntpdate
実行したときにワンショットで、すぐにサーバーの時刻と同期。

・ntp daemon
起動してもすぐには同期しない。
長期的にずれないようにうまく保ってくれるもの。どういうアルゴリズムなのかはよく知らない。


デフォルトでは、ネットワークがつながった時に
/etc/network/if-up.d/ntpdate から
/usr/sbin/ntpdate-debian
が自動実行されるようになっていると思っている（たぶん）。

ntpdate-debian は簡単なシェルスクリプトなので、中身見てみると、
/etc/default/ntpdate
を設定にして、ntpdate を実行しているようだ。

サーバー名はデフォルトで

NTPSERVERS="ntp.ubuntu.com"

を見るようだ。

会社などプロキシなどの問題がある場合、NTPSERVERSのところを会社指定のntpサーバに書きかえれば、同期してくれるようになった。


ntp daemon はデフォルトで入っていないので、

$ sudo apt-get install ntp
でインストールする必要がある。

/etc/ntp.conf が設定ファイルなので
server のところを必要に応じて書き換える。


ところで、ntpdate と ntp daemon が両方入っていたらどうなるんでしょう。。

ntp daemon がすでに起動しているときに、ntpdate を実行しようとすると
the NTP socket is in use, exiting
とエラーが出て、実行できない。

一方、
システムツール -> システム設定 -> 日付と時刻
で「ネットワーク時刻」をオフからオンに切り替えたときや、
新たにネットワークがつながったときは、
ntp daemon が NTP socket をつかむ前に ntpdate が実行されるように見えます。
よって、ntpdate が最初にガツンと合わせ、その後は ntp daemon がずれないように維持してくれるように見えました。

git daemon

git daemon の設定方法をメモっておきます。

Ubuntu と RHEL/CentOS 両方やってみましたが、やり方がちょっと違いますので、分けて説明します。

まずは Ubuntu でのやり方：
Ubuntu 12.04.1 LTSで試しました。

$ sudo apt-get install git-daemon-run
$ sudo sv start git-daemon

でできた。

あとは、export したいgit リポジトリの下に git-daemon-export-ok という空ファイルを作っておく。

Ubuntu だと sv というのがあるんですね。RHELにはないです。
この辺の事情は知りません。。

man sv を読むと、デフォルトで /etc/service の下をサーチするとある。
確かに
/etc/service/git-daemon
というのがある。

これは
/etc/sv/git-daemon ディレクトリへのシンボリックリンクになっている。

/etc/sv/git-daemon/run の内容は以下のようになっていた。


#!/bin/sh
exec 2>&1
echo 'git-daemon starting.'
exec chpst -ugitdaemon \
  "$(git --exec-path)"/git-daemon --verbose --reuseaddr \
    --base-path=/var/cache /var/cache/git

Debian 系は /var/cache/git の下にリポジトリがあるのを期待している。

なので、 gitweb や git-daemon などの etc ファイルをいちいち書き変えるよりも、

/var/cache/git から本当のリポジトリ置き場へシンボリックリンクを貼っておくのがよいと思う。

/var/cache/git に直にリポジトリを置いてもいいんですが、FHS的には、/var/cache/ 以下はアプリケーションのキャッシュとして使われるということなので、ちょっと気持ち悪い気がする。

--base-path=/var/cache は アクセスするときに、パスの先頭から /var/cache をはぎ取るという意味だから、

/var/cache/git/repo.git をクローンする場合、

$ git clone git://hostname/git/repo.git

みたいな感じでアクセスすればよい。

引き続いて、RHEL/CentOS でのやり方：
RHEL 6.3で試しました。

# yum install git-daemon
でインストールする。
xinetd もついでに依存関係で入る。

/etc/xinetd.d/git の設定ファイルができているので、
ちょこっと編集します。


# default: off
# description: The git dæmon allows git repositories to be exported using \
#       the git:// protocol.

service git
{
#        disable         = yes    ← コメントアウト
        disable         = no      ← 追加
        socket_type     = stream
        wait            = no
        user            = nobody
        server          = /usr/libexec/git-core/git-daemon
#        server_args     = --base-path=/var/lib/git --export-all --user-path=public_git --syslog --inetd --verbose     ←コメントアウト
        server_args     = --base-path=/var --export-all --user-path=public_git --syslog --inetd --verbose /var/git    ←追加
        log_on_failure  += USERID
}


disable を noにして、server_args の部分を書き換えています。

git clone git://my.git.server/git/hoge.git
で /var/git/hoge.git へアクセスするようになります。

あとは
# service xinetd restart
とします。

git daemon はデフォルト 9418番ポートを listen するので、
ファイアウォールを使っている場合は、9418/tcp を開ける。

git repogitory 自動バックアップ

git の repogitory は絶対に失ってはならない、最重要データの一つである。

そこで、独立した複数台のPCに常にバックアップを取ることを考えた。
cron を使い、定期的に他のマシンへ git push するようにする。

サーバーへは普通は ssh で接続するようになっているケースが多い。
自動バックアップのためにはパスワードなしで ssh 接続できないといけないので、
前回の「公開鍵暗号による ssh接続」の設定を済ませておく。
（秘密鍵を取り出すパスフレーズは空にしておく。）

そして、
$ crontab -e
で定期的に実行したいコマンドを記入する。
記入フォーマットは左のカラムから分、時、日、月、曜日、コマンドとなっている。
例えば、毎時55分になったら、 /var/git/main_repo.git の master ブランチを
backup_server マシン (アカウント名 = my_account) の ~/backup/backup_repo.git へ
pushしたい場合以下のようになる。

55 * * * * cd /var/git/main_repo.git; git push my_account@backup_server:~/backup/backup_repo.git master

↑ブラウザの都合で複数行に見えるかもしれないけど、1行です。


やりながらふと思ったが、
メインのマシンの方で、git daemon を動かしておいて、
バックアップサーバの方から定期的に git pull git://〜
するのでも良かった。

公開鍵暗号による ssh 接続

ssh でパスワードではなく、公開鍵暗号によってログインする方法。 ### 動作の仕組み ### 1. サーバーは接続してきたユーザーの公開鍵を `~/.ssh` ディレクトリから取り出す。 「乱数」を生成し、その乱数を公開鍵で暗号化してクライアントに送る 2. クライアントは、サーバーから送られてきた乱数を、秘密鍵で復号化し、サーバーに送り返す 3. サーバーは自分が作った乱数と、クライアントから戻ってきた値を照合し、一致すれば正しいユーザーと判断する ### 設定方法 ### #### クライアント側 #### $ ssh-keygen -t rsa 途中でパスフレーズ入力を求められる。 パスフレーズは秘密鍵を取り出すときに必要になります。 パスフレーズは省略もできます。 秘密鍵 `~/.ssh/id_rsa` および 公開鍵 `~/.ssh/id_rsa.pub` が生成される。 どんな方法でもよいので、公開鍵を ssh サーバーに送る。 (公開鍵なので、途中で傍受されてもよい。) #### サーバー側 #### $ cat id_rsa.pub >> ~/.ssh/authorized_keys うっかりしやすいのが、 `authorized_keys` のパーミッションです。 group に write permission がついているとうまくいきません。 $ chmod go-w ~/.ssh/authorized_keys のようにしておきます。 これ以降、公開鍵暗号方式でssh接続できる。 パスフレーズを省略していると、（セキュリティ的に脆弱だが）パスワードをいちいち入れずに、sshでログインできるようになる。

gut push でメールをとばす

git push でリポジトリが更新されたときに、commitの内容をメールで送信する方法。


ディストリビューションにもよるが、メール送信スクリプトは
/usr/share/git-core/contrib/hooks/post-receive-email
に普通インストールされていると思うので、これをそのまま使うこととする。

送信には sendmail を使用しているので、まずは sendmail ができるようにならないといけない。


MTA の設定はあまり詳しくないが、、、
とりあえずUbuntu でやってみた。

$ sudo apt-get install postfix
でインストール。
途中で選択肢が出てくるので、「インターネットサイト」を選択。

自宅のマシン場合、特に設定なしでも、そのまま使えた。
以下でちゃんとメールが届けばOK。

$ sendmail my.address@gmail.com
To: my.address@gmail.com
From: my.address@gmail.com
Subject: test
test
.


会社の場合、ファイアウォールの問題で、このままだと配送できなかったので、relayhostを設定。

/etc/postfix/main.cf を編集し、
relayhost のところに中継サーバーのIPアドレスを指定する。
IPアドレスで指定しないといけないみたいなので、
会社からこれを使え、と言われているSMTPサーバ名から nslookup で引く。

$ nslookup my.office.smtp.server
で Address : xxx.yyy.zzz.www
みたいにIPアドレスが返ってくるので、
relayhost = xxx.yyy.zzz.www
と指定するとOK。



sendmail が動くようになったので、続いて git の設定。

/usr/share/git-core/contrib/hooks/post-receive-email
にやり方が全部書いてあるので、この通りやるだけですが。。

post-receive-email に実行権限を与える
$ sudo chmod a+x /usr/share/git-core/contrib/hooks/post-receive-email

設定したいgit リポジトリへ移動
$ cd  /my/git/repogitory.git/hooks

post-receive-email へ post-receive という名前でシンボリックリンクをはる。
$ ln -s /usr/share/git-core/contrib/hooks/post-receive-email post-receive

送りつけたい宛先を config に設定
$ git config hooks.mailinglist "address@you.want.to.send"

とりあえずこれで送信されます。

あと、お好みでやっておく設定

メールのタイトルが 「UNNAMED PROJECT」になっているので、description にプロジェクト名を記載。

送信元アドレス指定
$ git config hooks.envelopesender do_not_reply_this@foo.org

メール最大行数を指定
$ git config hooks.emailmaxlines 500

Ubuntu 12.04 on RAID5 トラブルシューティング

先日の記事
「Intel RST 設定画面の入り方」
「Linuxインストール on RAID5 (Intel RST)」
に書いたやり方で、SSD 4 台でRAID5を組み、Ubuntu 12.04.1 LTS (alternate install)
をインストールして使い始めた。

使って数日目、以下のようなメッセージを出して起動しなくなった。
udevd[164]: inotify_add_watch(6, /dev/dm-1) failed: No such file or directory
udevd[163]: inotify_add_watch(6, /dev/dm-2) failed: No such file or directory
udevd[163]: inotify_add_watch(6, /dev/dm-1) failed: No such file or directory


とりあえず、エラーメッセージで検索してみると、Ubuntu関連でいろいろヒットした。

試行錯誤の後、とりあえず起動するようになった。


(1) 起動直後に、シフトキーを押しっぱなしにして、grub の画面を出す。
(2) 「Ubuntu, with Linux 3.2.*-**-generic (recovery mode)」を選択。
(3) 「Resume」を選択。
(4) デスクトップまで起動する。
(5) このままだと、再起動後、同じ現象で起動しなくなる。
そこで
$ sudo apt-get install cryptsetup
として、再起動すると、ちゃんとブートするようになった。

cryptsetup のインストールは、検索で出てきた通りやってみたら運良く直ったということなので、理屈は理解していません。