Debian システム上のアーカイブと圧縮ツールのまとめを以下に記します。

Debian システム上の単純なコピーとバックアップツールのまとめを以下に記します。

rsync(8) を使ってのファイルのコピーには他の方法より豊かな機能があります。

"./source" ディレクトリー中の全内容を異なるツールを用いてアーカイブしアーカイブ解凍するいくつかの方法を以下に記します。

GNU tar(1):

$ tar cvzf archive.tar.gz ./source
$ tar xvzf archive.tar.gz

cpio(1):

$ find ./source -xdev -print0 | cpio -ov --null > archive.cpio; gzip archive.cpio
$ zcat archive.cpio.gz | cpio -i

afio(1):

$ find ./source -xdev -print0 | afio -ovZ0 archive.afio
$ afio -ivZ archive.afio

"./source" ディレクトリー中の全内容を異なるツールを用いてコピーするいくつかの方法を以下に記します。

rsync(8):

# cd ./source; rsync -av . /dest
# cd ./source; rsync -av . user@host.dom:/dest

「転送元ディレクトリ後スラシュ付加」文法を上記の代わりに使えます。

# rsync -av ./source/ /dest
# rsync -av ./source/ user@host.dom:/dest

GNU cp(1) と openSSH scp(1):

# cd ./source; cp -a . /dest
# cd ./source; scp -pr . user@host.dom:/dest

GNU tar(1):

# (cd ./source && tar cf - . ) | (cd /dest && tar xvfp - )
# (cd ./source && tar cf - . ) | ssh user@host.dom '(cd /dest && tar xvfp - )'

cpio(1):

# cd ./source; find . -print0 | cpio -pvdm --null --sparse /dest

afio(1):

# cd ./source; find . -print0 | afio -pv0a /dest

"." を含むすべての例で "." は"foo" で代替でき、ファイルを "./source/foo" ディレクトリから "/dest/foo" ディレクトリにコピーできます。

"." を含むすべての例で "." を絶対パスの "/path/to/source/foo" で代替でき、"cd ./source;" を削除することができます。これらは使うツール次第で異なる場所にファイルをコピーします。

アーカイブやコピーコマンド (「アーカイブの慣用句」と「コピーの慣用句」参照) のためや xargs(1) (「ファイルに関してループしながらコマンドを反復実行」参照) のためにファイルを選択するのに find(1) が使われます。これの操作は find(1) のコマンド引数を使うことで強化できます。

find(1) の基本シンタックスは次のようにまとめられます。

find(1) はしばしば慣用的なスタイルで使われます。

# find /path/to \
    -xdev -regextype posix-extended \
    -type f -regex ".*\.afio|.*~" -prune -o \
    -type d -regex ".*/\.git" -prune -o \
    -type f -size +99M -prune -o \
    -type f -newer /path/to/timestamp -print0

これは次のアクションをすることを意味します。

上記例中でファイルを検索から除外するときの "-prune -o" の慣用的な使い方に注目して下さい。

コンピューターはいつか壊れるとか、人間によるエラーがシステムやデーターをへの損害を及ぼすことは皆知っています。バックアップと復元の操作は正しいシステム管理の必須構成要素です。考えうる全ての故障モードはいつかの日にやって来ます。

実際のバックアップと復元の方針を決める上で3つの要素があります。

データーのセキュアーなストレージとして、好ましくはファイルシステム破壊に耐えるように異なるディスクや機器上に、少なくとも異なるディスクパーティション上に、データーはあるべきです。重要データーは上書き事故を防ぐために CD/DVD-R のような1回書込みメディアに貯蔵するのが好ましいです。(シェルコマンドラインからストレージメディアにどうして書き込むかについては「バイナリーデーター」を参照下さい。GNOME デスクトップの GUI 環境ではメニュー: "Places→CD/DVD Creator" で簡単に書込みできます。)

Debian システム上の目に止まったバックアップユーティリティーのスイートから選んだリストを記します。

バックアップツールにはそれぞれの特別な狙いがあります。

「アーカイブと圧縮ツール」や「コピーと同期ツール」に記された基本的なツールを使うとカスタムスクリプト経由のシステムバックアップができます。そのようなスクリプトは次を使うと強化できます。

個人の Debian の unstable (非安定) スイートを実行するデスクトップシステムでは、個人的だったりクリティカルなデーターのみを保護する必要しかありません。いずれにせよ1年に1回はシステムを再インストールします。だから全システムをバックアップする理由もありませんし、フル機能のバックアップユーティリティーをインストールする理由もありません。

簡単なスクリプトでバックアップ用アーカイブを作成し、GUI を使って CD/DVD にそれを焼きます。次のこのスクリプトの例を示します。

#!/bin/sh -e
# Copyright (C) 2007-2008 Osamu Aoki <osamu@debian.org>, Public Domain
BUUID=1000; USER=osamu # UID and name of a user who accesses backup files
BUDIR="/var/backups"
XDIR0=".+/Mail|.+/Desktop"
XDIR1=".+/\.thumbnails|.+/\.?Trash|.+/\.?[cC]ache|.+/\.gvfs|.+/sessions"
XDIR2=".+/CVS|.+/\.git|.+/\.svn|.+/Downloads|.+/Archive|.+/Checkout|.+/tmp"
XSFX=".+\.iso|.+\.tgz|.+\.tar\.gz|.+\.tar\.bz2|.+\.afio|.+\.tmp|.+\.swp|.+~"
SIZE="+99M"
DATE=$(date --utc +"%Y%m%d-%H%M")
[ -d "$BUDIR" ] || mkdir -p "BUDIR"
umask 077
dpkg --get-selections \* > /var/lib/dpkg/dpkg-selections.list
debconf-get-selections > /var/cache/debconf/debconf-selections

{
find /etc /usr/local /opt /var/lib/dpkg/dpkg-selections.list \
     /var/cache/debconf/debconf-selections -xdev -print0
find /home/$USER /root -xdev -regextype posix-extended \
  -type d -regex "$XDIR0|$XDIR1" -prune -o -type f -regex "$XSFX" -prune -o \
  -type f -size  "$SIZE" -prune -o -print0
find /home/$USER/Mail/Inbox /home/$USER/Mail/Outbox -print0
find /home/$USER/Desktop  -xdev -regextype posix-extended \
  -type d -regex "$XDIR2" -prune -o -type f -regex "$XSFX" -prune -o \
  -type f -size  "$SIZE" -prune -o -print0
} | cpio -ov --null -O $BUDIR/BU$DATE.cpio
chown $BUUID $BUDIR/BU$DATE.cpio
touch $BUDIR/backup.stamp

root から実行されるスクリプト断片の例と言う位置づけです。

著者はこれをあなたが次のように変更し実行する事を期待します。

簡潔にしましょう!

ディレクトリーツリーの下のデーターセットは、"cp -a" としてコピーすると通常のバックアップができます。

"/var/cache/apt/packages/" ディレクトリーの下のデーターのようなディレクトリーの下の大きな上書きされない静的なデーターセットは、"cp -al" を利用するハードリンクを使うと通常のバックアップに代わるディスク空間を効率的に利用するバックアップができます。

私が bkup と名付けたデーターバックアップのためのコピースクリプトを次に示します。このスクリプトは現ディレクトリーの下の全ての (非 VCS) ファイルを親ディレクトリーかリモートホストの日付入りディレクトリーにコピーします。

#!/bin/sh -e
# Copyright (C) 2007-2008 Osamu Aoki <osamu@debian.org>, Public Domain
fdot(){ find . -type d \( -iname ".?*" -o -iname "CVS" \) -prune -o -print0;}
fall(){ find . -print0;}
mkdircd(){ mkdir -p "$1";chmod 700 "$1";cd "$1">/dev/null;}
FIND="fdot";OPT="-a";MODE="CPIOP";HOST="localhost";EXTP="$(hostname -f)"
BKUP="$(basename $(pwd)).bkup";TIME="$(date  +%Y%m%d-%H%M%S)";BU="$BKUP/$TIME"
while getopts gcCsStrlLaAxe:h:T f; do case $f in
g)  MODE="GNUCP";; # cp (GNU)
c)  MODE="CPIOP";; # cpio -p
C)  MODE="CPIOI";; # cpio -i
s)  MODE="CPIOSSH";; # cpio/ssh
S)  MODE="AFIOSSH";; # afio/ssh
t)  MODE="TARSSH";; # tar/ssh
r)  MODE="RSYNCSSH";; # rsync/ssh
l)  OPT="-alv";; # hardlink (GNU cp)
L)  OPT="-av";;  # copy (GNU cp)
a)  FIND="fall";; # find all
A)  FIND="fdot";; # find non CVS/ .???/
x)  set -x;; # trace
e)  EXTP="${OPTARG}";; # hostname -f
h)  HOST="${OPTARG}";; # user@remotehost.example.com
T)  MODE="TEST";; # test find mode
\?) echo "use -x for trace."
esac; done
shift $(expr $OPTIND - 1)
if [ $# -gt 0 ]; then
  for x in $@; do cp $OPT $x $x.$TIME; done
elif [ $MODE = GNUCP ]; then
  mkdir -p "../$BU";chmod 700 "../$BU";cp $OPT . "../$BU/"
elif [ $MODE = CPIOP ]; then
  mkdir -p "../$BU";chmod 700 "../$BU"
  $FIND|cpio --null --sparse -pvd ../$BU
elif [ $MODE = CPIOI ]; then
  $FIND|cpio -ov --null | ( mkdircd "../$BU"&&cpio -i )
elif [ $MODE = CPIOSSH ]; then
  $FIND|cpio -ov --null|ssh -C $HOST "( mkdircd \"$EXTP/$BU\"&&cpio -i )"
elif [ $MODE = AFIOSSH ]; then
  $FIND|afio -ov -0 -|ssh -C $HOST "( mkdircd \"$EXTP/$BU\"&&afio -i - )"
elif [ $MODE = TARSSH ]; then
  (tar cvf - . )|ssh -C $HOST "( mkdircd \"$EXTP/$BU\"&& tar xvfp - )"
elif [ $MODE = RSYNCSSH ]; then
  rsync -rlpt ./ "${HOST}:${EXTP}-${BKUP}-${TIME}"
else
  echo "Any other idea to backup?"
  $FIND |xargs -0 -n 1 echo
fi

これはコマンド例の位置付けです。スクリプトを読んで自分自身で編集してからご使用下さい。

リムーバブルストレージデバイスは次の何れも指します。

このようなリムーバブルストレージは、gnome-mount(1) を使い GNOME 等の現代的なデスクトップ環境では自動的にユーザーとしてマウントできます。

リムーバブルストレージデバイスを使ってデーターを共有する際には、両方のシステムにサポートされた共通のファイルシステムでそれをフォーマットするべきです。ファイルシステム選択のリストを次に示します。

FAT ファイルシステムはほとんど全ての現代的なオペレーティングシステムでサポートされていて、ハードディスク類似のメディア経由でのデーター交換目的に非常に有用です。

クロスプラットフォームの FAT ファイルシステムを使ったデーター共有にリムーバブルハードディスク類似デバイスをフォーマットする時の安全な選択肢は次です。

FAT とか ISO9660 ファイルシステムを使ってデーターを共有する際の安全への配慮を次に記します。

データーをネットワーク経由で他のシステムと共有するときには、共通のサービスを使うべきです。次に一部のヒントを記します。

このようなネットワーク経由でマウントされたファイルシステムやネットワーク経由のファイル転送法はデーター共有のために非常に便利ですが、インセキュアーかもしれませんこれらのネットワーク接続は次に記すようにしてセキュアーにされなければいけません。

さらに「他のネットワークアプリケーションサーバー」と「他のネットワークアプリケーションクライアント」を参照下さい。

重要なデーターアーカイブのためのコンピューターデーターストレージメディアを選ぶ時にはそれらの限界について注意を払うべきです。小さな個人的なバックアップのためには、著者としては名前が知られている会社の CD-R と DVD-R を使い、クールで日陰の乾燥した埃の無い環境に保存しています。(プロ用途ではテープアーカイブメディアに人気があるようです。)

ネット上に散見するアーカイブメディアの楽観的なストレージ寿命 (ほとんどベンダー情報由来)。

これらは取扱いによる機械的故障等は考慮していません。

ネット上に散見するアーカイブメディアの楽観的な書込み回数 (ほとんどベンダー情報由来)。

例えば2番目の SCSI ドライブ "/dev/sdb" というアンマウントされたドライブのディスクイメージファイル "disk.img" はcp(1) か dd(1) を用いれば次のようにして作れます。

# cp /dev/sdb disk.img
# dd if=/dev/sdb of=disk.img

プライマリ IDE ディスクの最初のセクターにある伝統的 PC のマスターブートレコード (MBR) (「ディスクパーティション設定」参照) のディスクイメージは、dd(1) を用いれば次のようにして作れます。

# dd if=/dev/hda of=mbr.img bs=512 count=1
# dd if=/dev/hda of=mbr-nopart.img bs=446 count=1
# dd if=/dev/hda of=mbr-part.img skip=446 bs=1 count=66

ブートディスクとして SCSI ドライブ (最近のシリアル ATA ドライブを含む) が使われている場合、"/dev/hda" を"/dev/sda" に置き換えて下さい。

オリジナルディスクのパーティションのイメージを作る場合には、"/dev/hda" を"/dev/hda1" 等で置き換えます。

ディスクイメージファイル "disk.img" はdd(1) を使ってサイズがマッチする例えば "/dev/sdb" という2番目の SCSI ドライブに次のようにして書き込むことができます。

# dd if=disk.img of=/dev/sdb

同様にディスクパーティションイメージファイル "partition.img" はサイズがマッチする例えば "/dev/sdb1" という2番目の SCSI ドライブの1番目のパーティションに次のようにして書き込むことができます。

# dd if=partition.img of=/dev/sdb1

単一パーティションイメージを含むディスクイメージ "partition.img" は次のように loop デバイスを使いマウントしアンマウントできます。

# losetup -v -f partition.img
Loop device is /dev/loop0
# mkdir -p /mnt/loop0
# mount -t auto /dev/loop0 /mnt/loop0
...hack...hack...hack
# umount /dev/loop0
# losetup -d /dev/loop0

これは以下のように簡略化出来ます。

# mkdir -p /mnt/loop0
# mount -t auto -o loop partition.img /mnt/loop0
...hack...hack...hack
# umount partition.img

複数のパーティションを含むディスクイメージ "disk.img" の各パーティションは loop デバイスを使ってマウント出来ます。loop デバイスはパーティションをデフォルトでは管理しないので、次のようにそれをリセットする必要があります。

# modinfo -p loop # verify kernel capability
max_part:Maximum number of partitions per loop device
max_loop:Maximum number of loop devices
# losetup -a # verify nothing using the loop device
# rmmod loop
# modprobe loop max_part=16

これで、loop デバイスは16パーティションまで管理出来ます。

# losetup -v -f disk.img
Loop device is /dev/loop0
# fdisk -l /dev/loop0

Disk /dev/loop0: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x452b6464

      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1               1         600     4819468+  83  Linux
/dev/loop0p2             601         652      417690   83  Linux
# mkdir -p /mnt/loop0p1
# mount -t ext3 /dev/loop0p1 /mnt/loop0p1
# mkdir -p /mnt/loop0p2
# mount -t ext3 /dev/loop0p2 /mnt/loop0p2
...hack...hack...hack
# umount /dev/loop0p1
# umount /dev/loop0p2
# losetup -d /dev/loop0

この他、同様の効果は kpartx パッケージの kpartx(8) により作られるデバイスマッパーデバイスを用いて次のようにして実現も出来ます。

# kpartx -a -v disk.img
...
# mkdir -p /mnt/loop0p2
# mount -t ext3 /dev/mapper/loop0p2 /mnt/loop0p2
...
...hack...hack...hack
# umount /dev/mapper/loop0p2
...
# kpartx -d /mnt/loop0

ディスクイメージファイル "disk.img" は消去済みのファイルを綺麗に無くした綺麗なスパースイメージ "new.img" に次のようにしてできます。

# mkdir old; mkdir new
# mount -t auto -o loop disk.img old
# dd bs=1 count=0 if=/dev/zero of=new.img seek=5G
# mount -t auto -o loop new.img new
# cd old
# cp -a --sparse=always ./ ../new/
# cd ..
# umount new.img
# umount disk.img

もし "disk.img" が ext2 か ext3 の場合には、zerofree パッケージの zerofree(8) を使うことも出来ます。

# losetup -f -v disk.img
Loop device is /dev/loop3
# zerofree /dev/loop3
# cp --sparse=always disk.img new.img

5GiB まで成長可能な空のディスクイメージファイル "disk.img" はdd(1) と mke2fs(8) を使って次のようにして作成できます。

$ dd bs=1 count=0 if=/dev/zero of=disk.img seek=5G

loop デバイスを使ってこのディスクイメージ "disk.img" 上に ext3 ファイルシステムを作成できます。

# losetup -f -v disk.img
Loop device is /dev/loop1
# mkfs.ext3 /dev/loop1
...hack...hack...hack
# losetup -d /dev/loop1
$ du  --apparent-size -h disk.img
5.0G  disk.img
$ du -h disk.img
83M disk.img

"sparse" に関して、そのファイルサイズは 5.0GiB でその実ディスク使用はたったの 83MiB です。この相違は ext2fs がスパースファイルを保持できるから可能となっています。

「ディスクイメージファイルをマウント」にあるように loop デバイスまたはデバイスマッパーデバイスによりデバイスに同様の操作をすることで、このディスクイメージ "disk.img" をparted(8) または fdisk(8) を使ってパーティションし mkfs.ext3(8) や mkswap(8) 等を使ってファイルシステムを作れます。

"source_directory" のソースディレクトリーツリーから作られる ISO9660 イメージファイル"cd.iso" はcdrkit が提供する genisoimage(1) を使って次のようにして作成できます。

#  genisoimage -r -J -T -V volume_id -o cd.iso source_directory

同様に、ブート可能な ISO9660 イメージファイル "cdboot.iso" は、debian-installer のような "source_directory" にあるディレクトリーツリーから次のようにして作成できます。

#  genisoimage -r -o cdboot.iso -V volume_id \
   -b isolinux/isolinux.bin -c isolinux/boot.cat \
   -no-emul-boot -boot-load-size 4 -boot-info-table source_directory

上記では、Isolinux ブートローダー (「2段目: ブートローダー」参照) がブートに使われています。

次のようにすると CD-ROM デバイスから直接 md5sum 値を計算し ISO9660 イメージを作成できます。

$ isoinfo -d -i /dev/cdrom
CD-ROM is in ISO 9660 format
...
Logical block size is: 2048
Volume size is: 23150592
...
# dd if=/dev/cdrom bs=2048 count=23150592 conv=notrunc,noerror | md5sum
# dd if=/dev/cdrom bs=2048 count=23150592 conv=notrunc,noerror > cd.iso

使えるデバイスは次のようにするとみつかります。

# wodim --devices

そしてブランクの CD-R をドライブに挿入して、例えば "/dev/hda" というこのデバイスに ISO9660 イメージファイル "cd.iso" にwodim(1) を使って次のようにして書込みます。

# wodim -v -eject dev=/dev/hda cd.iso

もし CD-R ではなく CD-RW が使われている場合には、次を代わりに実行して下さい。

# wodim -v -eject blank=fast dev=/dev/hda cd.iso

もし "cd.iso" の内容が ISO9660 イメージの場合、次のようにするとそれを "/cdrom" に手動でマウントできます。

# mount -t iso9660 -o ro,loop cd.iso /cdrom

もっとも基本的なバイナリーファイルを閲覧方法は "od -t x1" コマンドを使うことです。

ディスクをマウントせずに読出しや書込みをするツールがあります。

Linux カーネルが提供するソフトウエアー RAID システムは高いレベルのストレージ信頼性を達成するためにカーネルのファイルシステムのレベルでデーターの冗長性を提供します。

アプリケーションプログラムレベルでストレージの高い信頼性を達成するようにデーター冗長性を付加するツールもあります。

データーファイルの復元と事故の証拠解析のツールがあります。

単一ファイルでバックアップするにはデーターが大きすぎる場合、そのファイル内容を例えば 2000MiB の断片にしてバックアップし、それらの断片を後日マージしてオリジナルのファイルに戻せます。

$ split -b 2000m large_file
$ cat x* >large_file

ログファイルのようなファイルの内容を消去するためには、rm(1) を使ってファイルを消去しその後新しい空ファイルを作成することは止めましょう。コマンド実行間にファイルがアクセスされているかもしれないのがこの理由です。次のようにするのがファイル内容を消去する安全な方法です。

$ :>file_to_be_cleared

次のコマンドはダミーや空のファイルを作成します。

$ dd if=/dev/zero    of=5kb.file bs=1k count=5
$ dd if=/dev/urandom of=7mb.file bs=1M count=7
$ touch zero.file
$ : > alwayszero.file

次のファイルを見つかります。

"/dev/sda" にある USB メモリースティック等のハードディスク類似デバイス全体のデーターを完全に消すいくつかの方法があります。

次のようにしてデーターを0にリセットして全消去します。

# dd if=/dev/zero of=/dev/sda

次のようにしてランダムデーターを上書きして全消去します。

# dd if=/dev/urandom of=/dev/sda

次のようにしてランダムデーターを非常に効率的に上書きして全消去します。

# shred -v -n 1 /dev/sda

Debian インストーラ CD 等の多くのブート可能な Linux の CD のシェルから dd(1) が利用可能ですから、"/dev/hda" や "/dev/sda" 等のシステムハードディスクに対して同類のメディアから消去コマンドを実行することでインストールされたシステムを完全に消去することができます。

データーの消去はファイルシステムからアンリンクされているだけなので、例えば "/dev/sdb1" のようなハードディスク (USB メモリースティック) 上の使用されていない領域には消去されたデーター自身が含まれているかもしれません。これらに上書きすることで綺麗に消去できます。

# mount -t auto /dev/sdb1 /mnt/foo
# cd /mnt/foo
# dd if=/dev/zero of=junk
dd: writing to `junk': No space left on device
...
# sync
# umount /dev/sdb1

ファイルをうっかり消去しても、そのファイルが何らかのアプリケーション (読出しか書込み) によって使われている限り、そのようなファイルを回復出来ます。

例えば、次を試してみて下さい:

$ echo foo > bar
$ less bar
$ ps aux | grep ' less[ ]'
bozo    4775  0.0  0.0  92200   884 pts/8    S+   00:18   0:00 less bar
$ rm bar
$ ls -l /proc/4775/fd | grep bar
lr-x------ 1 bozo bozo 64 2008-05-09 00:19 4 -> /home/bozo/bar (deleted)
$ cat /proc/4775/fd/4 >bar
$ ls -l
-rw-r--r-- 1 bozo bozo 4 2008-05-09 00:25 bar
$ cat bar
foo

この代わりに、(lsof パッケージがインストールされている時) もう一つのターミナルで次のように実行します。

$ ls -li bar
2228329 -rw-r--r-- 1 bozo bozo 4 2008-05-11 11:02 bar
$ lsof |grep bar|grep less
less 4775 bozo 4r REG 8,3 4 2228329 /home/bozo/bar
$ rm bar
$ lsof |grep bar|grep less
less 4775 bozo 4r REG 8,3 4 2228329 /home/bozo/bar (deleted)
$ cat /proc/4775/fd/4 >bar
$ ls -li bar
2228302 -rw-r--r-- 1 bozo bozo 4 2008-05-11 11:05 bar
$ cat bar
foo

ハードリンクのあるファイルは "ls -li" を使って確認できます、

$ ls -li
total 0
2738405 -rw-r--r-- 1 root root 0 2008-09-15 20:21 bar
2738404 -rw-r--r-- 2 root root 0 2008-09-15 20:21 baz
2738404 -rw-r--r-- 2 root root 0 2008-09-15 20:21 foo

"baz" も "foo" もリンク数が "2" (>1) でハードリンクがある事を示しています。これらの inode 番号は共通の "2738404" です。これはこれらがハードリンクされた同じファイルということを意味します。ハードリンクされた全てのファイルを偶然うまく見つけられない場合は、それを例えば "2738404" という inode で次のようにして探せます。

# find /path/to/mount/point -xdev -inum 2738404

削除されたがオープンされたままのファイルは、通常の du(1) では見えませんが、ディスクスペースを消費します。これらは次のようにすればそのサイズとともにリストできます。

# lsof -s -X / |grep deleted

基本的なキー管理に関する GNU プライバシガードコマンドを次に記します。

トラストコードの意味を次に記します。

次のようにすると私のキー "1DD8D791" をポピュラーなキーサーバー "hkp://keys.gnupg.net" にアップロード出来ます。

$ gpg --keyserver hkp://keys.gnupg.net --send-keys 1DD8D791

"~/.gnupg/gpg.conf" (もしくは古い場所 "~/.gnupg/options") 中の良いデフォールトのキーサーバーの設定は次を含みます。

keyserver hkp://keys.gnupg.net

次によってキーサーバーから知らないキーが獲得できます。

$ gpg --list-sigs --with-colons | grep '^sig.*\[User ID not found\]' |\
  cut -d ':' -f 5| sort | uniq | xargs gpg --recv-keys

OpenPGP 公開キーサーバー (バージョン0.9.6以前) に2つ以上サブキーのあるキーを壊すバグがありました。新しい gnupg (>1.2.1-2) パッケージはこのような壊れたサブキーを取り扱えます。gpg(1) の"--repair-pks-subkey-bug" オプションの説明を参照下さい。

基本的なキー管理に関する GNU プライバシガードコマンドを次に記します。

インデックスメニュー上で "S" とすれば GnuPG が使えるようにしておきながら、遅い GnuPG が自動的に起動しないように "~/.muttrc" に次の内容を追加します。

macro index S ":toggle pgp_verify_sig\n"
set pgp_verify_sig=no

gnupg のプラグインを使うと ".gpg" や ".asc" や ".ppg" というファイル拡張子のファイルに対して透過的に GnuPG を実行できます。

# aptitude install vim-scripts vim-addon-manager
$ vim-addons install gnupg

md5sum(1) はrfc1321 の方法を使ってダイジェストファイルを作成し各ファイルをそれで確認するユーティリティーを提供します。

$ md5sum foo bar >baz.md5
$ cat baz.md5
d3b07384d113edec49eaa6238ad5ff00  foo
c157a79031e1c40f85931829bc5fc552  bar
$ md5sum -c baz.md5
foo: OK
bar: OK

ファイルの場所次第で次の手順のひとつに従うとふたつのソースファイル間の相違を抽出しユニファイド差分ファイル "file.patch0" か "file.patch1" を作成します。

$ diff -u file.old file.new > file.patch0
$ diff -u old/file new/file > file.patch1

差分ファイル (別名、パッチファイル) はプログラム更新を送るのに使われます。受け取った側はこの更新を別のファイルに次のようにして適用します。

$ patch -p0 file < file.patch0
$ patch -p1 file < file.patch1

3つのバージョンのソースコードがある場合、diff3(1) を使って効率的に3方マージを次のように実行できます。

$ diff3 -m file.mine file.old file.yours > file

次に全体像を提供するべく元来の VCS コマンドを極端に簡略化した比較を示します。典型的なコマンド文字列はオプションや引数が必要となるかもしれません。

CVS レポジトリーへのコミットを "src" グループメンバに限定し許可し、CVS の管理を "staff" グループメンバに限定し許可するように次の設定をすることでうっかりミスを予防できます。

# cd /var/lib; umask 002; mkdir cvs
# export CVSROOT=/srv/cvs/project
# cd $CVSROOT
# chown root:src .
# chmod 2775 .
# cvs -d $CVSROOT init
# cd CVSROOT
# chown -R root:staff .
# chmod 2775 .
# touch val-tags
# chmod 664 history val-tags
# chown root:src history val-tags

デフォールトの CVS レポジトリーは "$CVSROOT" で指示されます。次はローカルアクセスのための "$CVSROOT" を設定します。

$ export CVSROOT=/srv/cvs/project

多くの公開 CVS サーバーはアカウント名 "anonymous" で pserver サービス経由の読出しのみアクセスを提供します。例えば、Debian ウェッブサイト内容は webwml プロジェクトは Debian alioth サービスでの CVS を使ってメンテされています。次はこの CVS レポジトリーへのリモートアクセスのための "$CVSROOT" を設定します。

$ export CVSROOT=:pserver:anonymous@cvs.alioth.debian.org:/cvsroot/webwml
$ cvs login

次は SSH を使い webwml プロジェクトの CVS レポジトリーをリモートアクセスするために "$CVS_RSH" と "$CVSROOT" を設定します。

$ export CVS_RSH=ssh
$ export CVSROOT=:ext:account@cvs.alioth.debian.org:/cvs/webwml

リモートパスワードプロンプトを無くすのに SSH を使ったパブリックキー認証を使えます。

"~/path/to/module1" で新規のローカルソースツリーの場所を作成。

$ mkdir -p ~/path/to/module1; cd ~/path/to/module1

"~/path/to/module1" の下の新規のローカルソースツリーを埋める。

次のパラメーターを使って CVS にインポートします。

$ cd ~/path/to/module1
$ cvs import -m "Start module1" module1 Main-branch Release-initial
$ rm -Rf . # optional

CVS は現レポジトリーファイルを上書きせず他のファイルで置き換えます。だからレポジトリーディレクトリーへの書込みパーミッションはクリチカルです。"module1" という新規レポジトリーを "/srv/cvs/project" に作成の際毎に、必要ならこの条件を満たすために次を実行します。

# cd /srv/cvs/project
# chown -R root:src module1
# chmod -R ug+rwX   module1
# chmod    2775     module1

次に CVS を使う典型的なワークフローを記します。

"$CVSROOT" で指される CVS プロジェクトから得られる全てのモジュールを次のようにしてチェックします。

$ cvs rls
CVSROOT
module1
module2
...

"module1" をそのデフォールトディレクトリーの "./module1" に次のようにしてチェックアウトします。

$ cd ~/path/to
$ cvs co module1
$ cd module1

必要に応じ内容に変更を加える。

次のようにして "diff -u [repository] [local]" と等価を作成し変更をチェックします。

$ cvs diff -u

あるファイル "file_to_undo" をひどく壊したが他のファイルは大丈夫な事に気づきます。

次のようにして "file_to_undo" ファイルを CVS からのクリーンコピーで上書きします。

$ cvs up -C file_to_undo

次のようにして更新されたローカルソースツリーを CVS に保存します。

$ cvs ci -m "Describe change"

次のようにして "file_to_add" ファイルを作成し CVS に追加します。

$ vi file_to_add
$ cvs add file_to_add
$ cvs ci -m "Added file_to_add"

次のようにして CVS から最新バージョンをマージします。

$ cvs up -d

コンフリクトある変更を意味する "C filename" で始まる行に注意します。

".#filename.version" 中の変更されていないコードを探します。

コンフリクトある変更はファイル中の "<<<<<<<" や ">>>>>>>" を探索します。

必要に応じコンフリクト解消のためにファイルを編集します。

次のようにしてリリースタグ "Release-1" を追加します。

$ cvs ci -m "last commit for Release-1"
$ cvs tag Release-1

さらに編集します。

次のようにリリースタグ "Release-1" を削除します。

$ cvs tag -d Release-1

次のように CVS へ変更をチェックインします。

$ cvs ci -m "real last commit for Release-1"

リリースタグ "Release-1" を更新した CVS の main の HEAD に次のようにして再付加します。

$ cvs tag Release-1

次のようにして "Release-initial" タグによってで指定されるオリジナルのバージョンから、スティッキーブランチタグが "Release-initial-bugfixes" のブランチを作成し、"~/path/to/old" ディレクトリーにチェックアウトします。

$ cvs rtag -b -r Release-initial Release-initial-bugfixes module1
$ cd ~/path/to
$ cvs co -r Release-initial-bugfixes -d old module1
$ cd old

オリジナルバージョンに基づいたスティッキータグ "Release-initial-bugfixes" が付いているこのローカルのソースツリーで作業をします。

このブランチで一人で作業をします … 誰か他の人がこの "Release-initial-bugfixes" ブランチに合流するまで。

次のようにして必要に応じて新規ディレクトリーを作りながらこのブランチ上の他の人が変更したファイルと同期します。

$ cvs up -d

必要に応じコンフリクト解消のためにファイルを編集します。

次のように CVS へ変更をチェックインします。

$ cvs ci -m "checked into this branch"

次のようにしてスティッキータグを削除し ("-A")、キーワード展開せずに ("-kk")、main の HEAD (最新版) をつかってローカルのツリーを更新します。

$ cvs up -d -kk -A

次のようにしてキーワード展開せずに ("-kk")、"Release-initial-bugfixes" ブランチをマージしてローカルのツリー (内容 = main の HEAD) を更新します。

$ cvs up -d -kk -j Release-initial-bugfixes

エディターを使ってコンフリクト解消します。

次のように CVS へ変更をチェックインします。

$ cvs ci -m "merged Release-initial-bugfixes"

次のようにしてアーカイブを作成します。

$ cd ..
$ mv old old-module1-bugfixes
$ tar -cvzf old-module1-bugfixes.tar.gz old-module1-bugfixes
$ rm -rf old-module1-bugfixes

CVS から最新ファイルを取り込むには、次のように "tomorrow" (明日) を使います:

$ cvs ex -D tomorrow module_name

モジュールのエリアス "mx" を CVS プロジェクト (ローカルサーバー) に追加します。

$ export CVSROOT=/srv/cvs/project
$ cvs co CVSROOT/modules
$ cd CVSROOT
$ echo "mx -a module1" >>modules
$ cvs ci -m "Now mx is an alias for module1"
$ cvs release -d .

さて、CVS から "new" ディレクトリーに "module1" (エリアス: "mx") を次のようにしてチェックアウトします。

$ cvs co -d new mx
$ cd new

CVS からファイルをチェックアウトする時に、その実行パーミッションビットは保持されます。

チェックアウトされた例えば "filename" ファイルで実行ビットの問題にあった際には、次のコマンドを使い CVS レポジトリー中のそのパーミッションを変更します。

# chmod ugo-x filename

現状の subversion パッケージはレポジトリーの設定はしないので手動で設定を行う必要があります。レポジトリーを置く可能な場所の1つは "/srv/svn/project" 中です。

ディレクトリーを次のように作成します。

# mkdir -p        /srv/svn/project

レポジトリーデーターベースを次のように作成します。

# svnadmin create /srv/svn/project

Apache2 サーバー経由で Subversion レポジトリーにアクセスするだけなら、レポジトリーを次に記すように WWW サーバーのみによって書込み可とするだけが必要です。

# chown -R www-data:www-data /srv/svn/project

ユーザー認証経由でレポジトリーにアクセス許可するために "/etc/apache2/mods-available/dav_svn.conf" 中の次の部分を追加 (もしくはアンコメント) します。

<Location /project>
  DAV svn
  SVNPath /srv/svn/project
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /etc/subversion/passwd
<LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
</LimitExcept>
</Location>

次のコマンドでユーザー認証ファイルを作成します。

# htpasswd2 -c /etc/subversion/passwd some-username

Apach2 を再スタート

あなたの新規の Subversion レポジトリーは "http://localhost/project" と (ウェッブサーバーの URL が"http://example.com/" と仮定すると) "http://example.com/project" の URL にてアクセスできます。

次は Subversion レポジトリーを例えば project というグループによってローカルアクセス出きるようにする設定です。

# chmod  2775     /srv/svn/project
# chown -R root:src /srv/svn/project
# chmod -R ug+rwX   /srv/svn/project

あなたの新しい Subversion レポジトリーは、project グループに属するローカルユーザーにとって svn(1) から "file:///localhost/srv/svn/project" か "file:///srv/svn/project" の URL からグループアクセスできます。グループアクセスを確実にするために、svn や svnserve や svnlook や svnadmin 等のコマンドを "umask 002" の下で実行しなければいけません。

SSH から "example.com:/srv/svn/project" の URL にあるグループアクセス可能な Subversion レポジトリーは、svn(1) を使って "svn+ssh://example.com:/srv/svn/project" にてアクセスできます。

Subversion のブランチやタグの機能を欠くことを補うべく、多くのプロジェクトは次と似たようなディレクトリーツリーを使っています。

  ----- module1
    |   |-- branches
    |   |-- tags
    |   |   |-- release-1.0
    |   |   `-- release-2.0
    |   |
    |   `-- trunk
    |       |-- file1
    |       |-- file2
    |       `-- file3
    |
    `-- module2

"~/path/to/module1" で新規のローカルソースツリーの場所を作成。

$ mkdir -p ~/path/to/module1; cd ~/path/to/module1

"~/path/to/module1" の下の新規のローカルソースツリーを埋める。

ソースを次のパラメーターを使って Subversion にインポートします。

$ cd ~/path/to/module1
$ svn import file:///srv/svn/project/module1/trunk -m "Start module1"
$ svn cp file:///srv/svn/project/module1/trunk file:///srv/svn/project/module1/tags/Release-initial

この代わりに、次のようにも出来ます。

$ svn import ~/path/to/module1 file:///srv/svn/project/module1/trunk -m "Start module1"
$ svn cp file:///srv/svn/project/module1/trunk file:///srv/svn/project/module1/tags/Release-initial

次に Subversion をその本来のクライアントとともに使う典型的なワークフローを記します。

"file:///srv/svn/project" の URL で指定される Subversion プロジェクトから得られる全てのモジュールを次のようにしてチェックします。

$ svn list file:///srv/svn/project
module1
module2
...

次のようにして "module1/trunk" を"module1" ディレクトリーにチェックアウトします。

$ cd ~/path/to
$ svn co file:///srv/svn/project/module1/trunk module1
$ cd module1

必要に応じ内容に変更を加える。

次のようにして "diff -u [repository] [local]" と等価を作成し変更をチェックします。

$ svn diff

あるファイル "file_to_undo" をひどく壊したが他のファイルは大丈夫な事に気づきます。

次のようにして "file_to_undo" ファイルを Subversion からのクリーンコピーで上書きします。

$ svn revert file_to_undo

更新されたローカルソースツリーを次のようにして Subversion に保存します。

$ svn ci -m "Describe change"

次のようにして "file_to_add" ファイルを作成し Subversion に追加します。

$ vi file_to_add
$ svn add file_to_add
$ svn ci -m "Added file_to_add"

次のようにして Subversion から最新バージョンをマージします。

$ svn up

コンフリクトある変更を意味する "C filename" で始まる行に注意します。

"filename.r6" と "filename.r9" と "filename.mine" 等中の変更されていないコードを探します。

コンフリクトある変更はファイル中の "<<<<<<<" や ">>>>>>>" を探索します。

必要に応じコンフリクト解消のためにファイルを編集します。

次のようにしてリリースタグ "Release-1" を追加します。

$ svn ci -m "last commit for Release-1"
$ svn cp file:///srv/svn/project/module1/trunk file:///srv/svn/project/module1/tags/Release-1

さらに編集します。

次のようにリリースタグ "Release-1" を削除します。

$ svn rm file:///srv/svn/project/module1/tags/Release-1

次のようにして変更を Subversion にチェックインします。

$ svn ci -m "real last commit for Release-1"

リリースタグ "Release-1" を更新した Subversion の trunk の HEAD に再付加します。

$ svn cp file:///srv/svn/project/module1/trunk file:///srv/svn/project/module1/tags/Release-1

次のようにして "module1/tags/Release-initial" というパスで指定されるオリジナルのバージョンから、パスが "module1/branches/Release-initial-bugfixes" のブランチを作成し、"~/path/to/old" ディレクトリーにチェックアウトします。

$ svn cp file:///srv/svn/project/module1/tags/Release-initial file:///srv/svn/project/module1/branches/Release-initial-bugfixes
$ cd ~/path/to
$ svn co file:///srv/svn/project/module1/branches/Release-initial-bugfixes old
$ cd old

オリジナルバージョンに基づいたブランチ "Release-initial-bugfixes" を指定しているローカルのソースツリーで作業します。

このブランチで一人で作業をします … 誰か他の人がこの "Release-initial-bugfixes" ブランチに合流するまで。

次のようにしてこのブランチ上の他の人が変更したファイルと同期します。

$ svn up

必要に応じコンフリクト解消のためにファイルを編集します。

次のようにして変更を Subversion にチェックインします。

$ svn ci -m "checked into this branch"

trunk の HEAD を使って次のようにローカルツリーを更新します。

$ svn switch file:///srv/svn/project/module1/trunk

次のようにして "Release-initial-bugfixes" ブランチをマージしてローカルのツリー (内容 = trunk の HEAD) を更新します。

$ svn merge file:///srv/svn/project/module1/branches/Release-initial-bugfixes

エディターを使ってコンフリクト解消します。

次のようにして変更を Subversion にチェックインします。

$ svn ci -m "merged Release-initial-bugfixes"

次のようにしてアーカイブを作成します。

$ cd ..
$ mv old old-module1-bugfixes
$ tar -cvzf old-module1-bugfixes.tar.gz old-module1-bugfixes
$ rm -rf old-module1-bugfixes

Git は使うあなたの名前や email アドレス等を "~/.gitconfig" 中のいくつかのグローバル設定に設定したいなら次のようにします。

$ git config --global user.name "Name Surname"
$ git config --global user.email yourname@example.com

もしあなたが CVS や Subversion コマンドに慣れ過ぎている場合には、いくつかのコマンドエリアスの設定を次のようにするのも一計です。

$ git config --global alias.ci "commit -a"
$ git config --global alias.co checkout

あなたのグローバル設定は次のようにするとチェックできます。

$ git config --global --list

次を参照下さい。

git-gui(1) と gitk(1) コマンドは簡単に Git が利用出来るようにします。

アップストリームが異なる VCS を使っていようと、アップストリームへのネットワーク接続無しにローカルコピーを管理できるので、ローカル活動に git(1) を使うのは良い考えかもしれません。次は git(1) とともに使われるパッケージとコマンドのリストです。

"svn+ssh://svn.example.org/project/module/trunk" にある Subversion のレポジトリを "./dest" にあるローカルの Git レポジトリにチェックアウトでき、また Subversion レポジトリに戻すコミットができます。例えば:

$ git svn clone -s -rHEAD svn+ssh://svn.example.org/project dest
$ cd dest
... make changes
$ git commit -a
... keep working locally with git
$ git svn dcommit

Git ツールを使い設定の経時履歴をマニュアルで記録できます。次は "/etc/apt/" の内容を記録する単純な練習例です。

$ cd /etc/apt/
$ sudo git init
$ sudo chmod 700 .git
$ sudo git add .
$ sudo git commit -a

設定を説明とともにコミットします。

設定ファイルへの変更をします。

$ cd /etc/apt/
$ sudo git commit -a

設定を説明とともにコミットしそのままいろいろ作業をしていきます。

$ cd /etc/apt/
$ sudo gitk --all

フルの履歴を手中しています。