CVSサーバ設定ガイド(修正版)
キーワード:redhat rhel 4 cvsバージョン私が整理したこの文章の大部分の内容は私がRed Hat Linux 8.0と9.0で検証したもので、あなたに役に立つことを望んでいます.サーバのインストールは省略しますが、開発ツールをインストールするとデフォルトですでにCVSがあります.いいえ、aptまたはyumでできます.aptはhttp://www.bestunix.net/p/rhel4_apt.phpを参照してください.まず、CVS用のグループとユーザーを作成してください.
コード#コード#
/usr/sbin/groupadd cvs /usr/sbin/useradd cvsroot -g cvspasswd cvsroot
OK、ユーザーはすでに確立して、cvsrootは私たちがCVS操作をして使用したのです.
2.プロファイルの変更:
#cat/etc/services|grep cvspserver
あるかどうか見てみましょう.
cvspserver 2401/tcp #CVS client/server operations
cvspserver 2401/udp #CVS client/server operations
この2行です.システムにCVSが付属している場合、この2行もすでにありますので、確認するだけです.もしなかったら、自分で加えてください.
3.起動スクリプトを作成する必要があります.
vi/etc/xinet.d/cvspserver
内容は次のとおりです.
コード#コード#
ここでserverはCVS実行可能ファイルパスを指定し、デフォルトのインストールは/usr/bin/cvsです.server_argsはソースライブラリパスや認証方式などを指定し、例ではソースコードをcvsrootのホームディレクトリに格納したり、パスを別途指定したりすることもできますが、権限設定に注意しなければなりません.pserverはパスワード認証方式で、この方式の安全性は少し悪いですが、操作は簡単です.各行の等号の左右にスペースがあることに注意してください.そうしないと、サービスを開始できません.
実際、このファイルのフォーマットは非常に書き間違えやすいが、これらのエラーは何のヒントもないので、ダウンロード私が書いたサンプルファイルを強くお勧めします.これに基づいて修正すると便利です.4.CVSを初期化してcvsrootユーザーに切り替えます.次に初期化を行います:cvs-d/home/cvsroot initこのパスはcvspserverファイルで指定したパスと同じである必要があります.初期化後、このパスの下にCVSROOTディレクトリが作成され、CVS管理用のファイルが格納されます.この時点でxinetdサービスを再起動し、CVSサーバを起動できるようになります./sbin/service xinetd restartもちろん、コンピュータを再起動してもいいです.起動確認:netstat-anp|grep 2401見える場合:tcp 0 0.0.0.0:2401
説明は正常に起動しています.なければ、構成プロセスにエラーや漏れがないかどうかを再確認してください.
最後に、2401ポートが開いているかどうかを確認する必要があります.
/sbin/iptables -L&line;grep cvs
表示される場合
ACCEPT tcp -- anywhere anywhere tcp dpt:cvspserver
ポートが開いていることを示します.そうでない場合は、ファイアウォール2401ポートを開いてください.
/sbin/iptables -A INPUT -i eth0 -p tcp --dport 2401 -j ACCEPT
/sbin/service iptables save
ファイアウォールの詳細については、http://www.bestunix.net/p/iptables_enter.php5.ユーザー管理CVSデフォルト使用システムユーザーログインを参照してください.システムセキュリティの考慮のために独立したユーザー管理を使用することもできます.CVSユーザー名とパスワードは、CVSROOTディレクトリのpasswdファイルに保存されます.フォーマットは、ユーザー名:パスワード:システムユーザー、すなわち、CVSユーザーをシステムユーザーにマッピングすることで、システムユーザー名とパスワードをユーザーに知らせる必要がなく、システムユーザーの権限設定によってユーザーに異なる権限を割り当てることができます.ここのシステムユーザーは一般的にcvsrootというユーザーです.passwdファイルのデフォルトは存在しません.私たちは自分で作成しなければなりません.ファイルのパスワードフィールドはMD 5で暗号化されていますが、CVSではユーザー名を追加するコマンドが提供されていません.Apacheのコマンドを借りてこの作業を完了します.
まずpasswdファイルを作成します
htpasswd -c passwd username
他のユーザーは、パラメータhtpasswd passwd usernameを持たずにusernameにパスワードを指定し、passwdに保存します.ファイルが存在しない場合は自動的に作成されます.htpasswdコマンドはCVSのために設定されていないので、マッピングされたユーザー名を自動的に追加することはできませんが、大丈夫です.パスワードを設定してから、自分でこの部分を追加します.私のやり方はcvsrootユーザーにマッピングすることです.他のユーザーをマッピングする必要がある場合は、対応するディレクトリに権限を設定することに注意してください.そうしないと、CVSユーザーはソースコード倉庫にアクセスできない可能性があります.システムアカウントのログインを徹底的に防止するには、CVSROOTディレクトリのconfigファイルを編集し、#SystemAuth=noの行の前の#を削除しても、CVSはシステムユーザーを検証しません.そうしないと、ユーザー名がpasswdファイルにない場合、CVSはシステムユーザーの検証を行います.また、CVSROOTディレクトリのreadersファイルとwritersファイルを使用して、読み書き権限を構成する必要があります.この2つのファイルもデフォルトではありませんので、大丈夫です.自分で作成すればいいです.readersファイルは、読み取り専用の権限を持つユーザー名を記録し、各行に1人のユーザーを記録します.writersファイルには、読み書き権限を持つユーザー名が記録され、行ごとに1人のユーザーでもあります.readersファイルはwritersよりも優先されます.つまり、readersファイルに存在するかどうかにかかわらず、readersに表示されるユーザーは読み取り専用になります.構成が完了したら、まずテストします:#cvs-d:pserver:[email protected]:/home/cvsroot loginここではユーザー名がusernameであると仮定し、ローカルにログインします.パスワードのプロンプトが表示され、正しいパスワードを入力すると、ログインに成功します.プロンプト・アクセスが拒否された場合は、ユーザー権限、ディレクトリ権限、ファイアウォール設定を確認します.推奨環境変数CVSROOT:#export CVSROOT=:pserver:[email protected]:/home/cvsroot以降は-dパラメータを入力する必要はありませんが、-dパラメータはこの環境変数の設定を上書きします.6.ソースウェアハウスのバックアップと移動基本的に、CVSのソースウェアハウスには特別な点はなく、ファイルバックアップ方式でバックアップすることができます.ただし、バックアップ中にユーザーが変更をコミットしていないことを確認する必要があります.具体的には、CVSサーバを停止したり、ロックを使用したりすることができます.CVSの各モジュールは個別のディレクトリであり、他のモジュールやディレクトリとは何の関係もなく、かなり便利です.倉庫でディレクトリやファイルを削除するだけでモジュールの一部を削除できますが、CVSの削除機能を使用すると履歴が記録され、倉庫の直接削除に痕跡が残らないため、プロジェクト管理に不利です.モバイルウェアハウスはバックアップと同様に、モジュールのディレクトリを新しいパスに移動するだけで使用できます.残念なことに、バックアップ後にいくつかの変更があり、コミットが実行された場合、サーバに問題が発生してソース・コード・ウェアハウスをリカバリする必要がある場合、開発者が新しい変更をコミットすると、バージョンが一致しないエラーが発生します.この場合、CVS関連のディレクトリとファイルを削除するだけで、新しい変更を提出できます.7.CVSROOTディレクトリをさらに管理するには、他にも多くの機能があります.その中で最も重要なのはmodulesファイルです.このファイルはソース・ライブラリのモジュールを定義しています.次に例を示します.Linux Linux Kernel Linux/kernelこのファイルの内容は行ごとに並べられ、各行はモジュール名を定義し、次にモジュールパスです.これはCVSルート・ディレクトリに対するパスです.2つのモジュールを定義します.1つ目はLinuxモジュールで、Linuxディレクトリにあり、2つ目はKernelモジュールで、これはLinuxモジュールのサブモジュールです.modulesファイルは必須ではありません.その役割はインデックスに相当し、一部のCVSクライアントソフトウェアは、WinCVSなどの対応するモジュールを迅速に見つけることができます.8.共同開発の問題のデフォルト方式では、CVSは複数のユーザーが同じファイルを編集することを許可する.これは、複数の開発者が同じファイルの同じ部分を同時に修正するのは正常ではないため、プロジェクト管理では避けるべきである.このような状況が発生したのは、プロジェクトグループ内に統一的な意見がないことを示している.複数の開発者がファイルの異なる部分を修正すると、CVSはよく管理できます.この方式が制御しにくいと判断した場合、CVSも解決策を提供し、cvs admin-lを使用してロックすることができ、開発者が修正中である場合、CVSは他のユーザーのcheckoutを許可しない.ここで、ファイル形式の問題について説明します.テキスト形式では、CVSは履歴比較、バージョンマージなどの作業を行うことができますが、バイナリファイルはこの操作をサポートしていません.例えば、wordドキュメント、ピクチャなどはバイナリで提出する必要があります.バイナリ方式では、マージができないため、1人のユーザのみがファイルを変更する保証がない場合は、ロック方式で変更することをお勧めします.注意しなければならないのは、修正が終わったらロックを解除してください.バージョン1.6から、CVSは監視の概念を導入し、この機能はユーザーに現在誰がファイルを修正しているのかをいつでも知ることができ、CVSは自動的に監視のユーザーに最新の更新を通知するメールを送信することができる.9.複数のソース・コード・ウェアハウスを構築複数の開発グループを管理する必要があり、これらの開発グループ間で相互にアクセスできない場合は、a.1つのポートを共有し、cvspserverファイルを変更し、server_に与える2つの方法があります.argsは、複数のソースコードパス、すなわち複数-allow-rootパラメータを指定します.xinetdのserver_argsの長さには制限があり、server=/home/cvsroot/cvs.runなどのcvspserverファイルでサーバの設定を別のファイルにリダイレクトできます.その後、/home/cvsroot/cvs.runファイルを作成します.このファイルは実行可能である必要があります.コンテンツフォーマットは:!/bin/bash/usr/bin/cvs-f--allow-root=/home/cvsroot/src 1--allow-root=/home/cvsroot/src 2 pserverソースコードウェアハウスは/home/cvsrootではなく、初期化するときは、/home/cvsrootパスを初期化し、/home/cvsrootパスを初期化しないことに注意してください.b.異なるポートを用いてサービスを提供する第2ステップと第3ステップを繰り返し、異なるソースコード倉庫に異なるサービス名の起動スクリプトを作成し、これらのサービス名に異なるポートを指定し、初期化時にもそれぞれ初期化しなければならない.
コード#コード#
/usr/sbin/groupadd cvs /usr/sbin/useradd cvsroot -g cvspasswd cvsroot
OK、ユーザーはすでに確立して、cvsrootは私たちがCVS操作をして使用したのです.
2.プロファイルの変更:
#cat/etc/services|grep cvspserver
あるかどうか見てみましょう.
cvspserver 2401/tcp #CVS client/server operations
cvspserver 2401/udp #CVS client/server operations
この2行です.システムにCVSが付属している場合、この2行もすでにありますので、確認するだけです.もしなかったら、自分で加えてください.
3.起動スクリプトを作成する必要があります.
vi/etc/xinet.d/cvspserver
内容は次のとおりです.
コード#コード#
service cvspserver
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/bin/cvs
server_args = -f --allow-root=/home/cvsroot pserver
log_on_failure += USERID
}
ここでserverはCVS実行可能ファイルパスを指定し、デフォルトのインストールは/usr/bin/cvsです.server_argsはソースライブラリパスや認証方式などを指定し、例ではソースコードをcvsrootのホームディレクトリに格納したり、パスを別途指定したりすることもできますが、権限設定に注意しなければなりません.pserverはパスワード認証方式で、この方式の安全性は少し悪いですが、操作は簡単です.各行の等号の左右にスペースがあることに注意してください.そうしないと、サービスを開始できません.
実際、このファイルのフォーマットは非常に書き間違えやすいが、これらのエラーは何のヒントもないので、ダウンロード私が書いたサンプルファイルを強くお勧めします.これに基づいて修正すると便利です.4.CVSを初期化してcvsrootユーザーに切り替えます.次に初期化を行います:cvs-d/home/cvsroot initこのパスはcvspserverファイルで指定したパスと同じである必要があります.初期化後、このパスの下にCVSROOTディレクトリが作成され、CVS管理用のファイルが格納されます.この時点でxinetdサービスを再起動し、CVSサーバを起動できるようになります./sbin/service xinetd restartもちろん、コンピュータを再起動してもいいです.起動確認:netstat-anp|grep 2401見える場合:tcp 0 0.0.0.0:2401
説明は正常に起動しています.なければ、構成プロセスにエラーや漏れがないかどうかを再確認してください.
最後に、2401ポートが開いているかどうかを確認する必要があります.
/sbin/iptables -L&line;grep cvs
表示される場合
ACCEPT tcp -- anywhere anywhere tcp dpt:cvspserver
ポートが開いていることを示します.そうでない場合は、ファイアウォール2401ポートを開いてください.
/sbin/iptables -A INPUT -i eth0 -p tcp --dport 2401 -j ACCEPT
/sbin/service iptables save
ファイアウォールの詳細については、http://www.bestunix.net/p/iptables_enter.php5.ユーザー管理CVSデフォルト使用システムユーザーログインを参照してください.システムセキュリティの考慮のために独立したユーザー管理を使用することもできます.CVSユーザー名とパスワードは、CVSROOTディレクトリのpasswdファイルに保存されます.フォーマットは、ユーザー名:パスワード:システムユーザー、すなわち、CVSユーザーをシステムユーザーにマッピングすることで、システムユーザー名とパスワードをユーザーに知らせる必要がなく、システムユーザーの権限設定によってユーザーに異なる権限を割り当てることができます.ここのシステムユーザーは一般的にcvsrootというユーザーです.passwdファイルのデフォルトは存在しません.私たちは自分で作成しなければなりません.ファイルのパスワードフィールドはMD 5で暗号化されていますが、CVSではユーザー名を追加するコマンドが提供されていません.Apacheのコマンドを借りてこの作業を完了します.
まずpasswdファイルを作成します
htpasswd -c passwd username
他のユーザーは、パラメータhtpasswd passwd usernameを持たずにusernameにパスワードを指定し、passwdに保存します.ファイルが存在しない場合は自動的に作成されます.htpasswdコマンドはCVSのために設定されていないので、マッピングされたユーザー名を自動的に追加することはできませんが、大丈夫です.パスワードを設定してから、自分でこの部分を追加します.私のやり方はcvsrootユーザーにマッピングすることです.他のユーザーをマッピングする必要がある場合は、対応するディレクトリに権限を設定することに注意してください.そうしないと、CVSユーザーはソースコード倉庫にアクセスできない可能性があります.システムアカウントのログインを徹底的に防止するには、CVSROOTディレクトリのconfigファイルを編集し、#SystemAuth=noの行の前の#を削除しても、CVSはシステムユーザーを検証しません.そうしないと、ユーザー名がpasswdファイルにない場合、CVSはシステムユーザーの検証を行います.また、CVSROOTディレクトリのreadersファイルとwritersファイルを使用して、読み書き権限を構成する必要があります.この2つのファイルもデフォルトではありませんので、大丈夫です.自分で作成すればいいです.readersファイルは、読み取り専用の権限を持つユーザー名を記録し、各行に1人のユーザーを記録します.writersファイルには、読み書き権限を持つユーザー名が記録され、行ごとに1人のユーザーでもあります.readersファイルはwritersよりも優先されます.つまり、readersファイルに存在するかどうかにかかわらず、readersに表示されるユーザーは読み取り専用になります.構成が完了したら、まずテストします:#cvs-d:pserver:[email protected]:/home/cvsroot loginここではユーザー名がusernameであると仮定し、ローカルにログインします.パスワードのプロンプトが表示され、正しいパスワードを入力すると、ログインに成功します.プロンプト・アクセスが拒否された場合は、ユーザー権限、ディレクトリ権限、ファイアウォール設定を確認します.推奨環境変数CVSROOT:#export CVSROOT=:pserver:[email protected]:/home/cvsroot以降は-dパラメータを入力する必要はありませんが、-dパラメータはこの環境変数の設定を上書きします.6.ソースウェアハウスのバックアップと移動基本的に、CVSのソースウェアハウスには特別な点はなく、ファイルバックアップ方式でバックアップすることができます.ただし、バックアップ中にユーザーが変更をコミットしていないことを確認する必要があります.具体的には、CVSサーバを停止したり、ロックを使用したりすることができます.CVSの各モジュールは個別のディレクトリであり、他のモジュールやディレクトリとは何の関係もなく、かなり便利です.倉庫でディレクトリやファイルを削除するだけでモジュールの一部を削除できますが、CVSの削除機能を使用すると履歴が記録され、倉庫の直接削除に痕跡が残らないため、プロジェクト管理に不利です.モバイルウェアハウスはバックアップと同様に、モジュールのディレクトリを新しいパスに移動するだけで使用できます.残念なことに、バックアップ後にいくつかの変更があり、コミットが実行された場合、サーバに問題が発生してソース・コード・ウェアハウスをリカバリする必要がある場合、開発者が新しい変更をコミットすると、バージョンが一致しないエラーが発生します.この場合、CVS関連のディレクトリとファイルを削除するだけで、新しい変更を提出できます.7.CVSROOTディレクトリをさらに管理するには、他にも多くの機能があります.その中で最も重要なのはmodulesファイルです.このファイルはソース・ライブラリのモジュールを定義しています.次に例を示します.Linux Linux Kernel Linux/kernelこのファイルの内容は行ごとに並べられ、各行はモジュール名を定義し、次にモジュールパスです.これはCVSルート・ディレクトリに対するパスです.2つのモジュールを定義します.1つ目はLinuxモジュールで、Linuxディレクトリにあり、2つ目はKernelモジュールで、これはLinuxモジュールのサブモジュールです.modulesファイルは必須ではありません.その役割はインデックスに相当し、一部のCVSクライアントソフトウェアは、WinCVSなどの対応するモジュールを迅速に見つけることができます.8.共同開発の問題のデフォルト方式では、CVSは複数のユーザーが同じファイルを編集することを許可する.これは、複数の開発者が同じファイルの同じ部分を同時に修正するのは正常ではないため、プロジェクト管理では避けるべきである.このような状況が発生したのは、プロジェクトグループ内に統一的な意見がないことを示している.複数の開発者がファイルの異なる部分を修正すると、CVSはよく管理できます.この方式が制御しにくいと判断した場合、CVSも解決策を提供し、cvs admin-lを使用してロックすることができ、開発者が修正中である場合、CVSは他のユーザーのcheckoutを許可しない.ここで、ファイル形式の問題について説明します.テキスト形式では、CVSは履歴比較、バージョンマージなどの作業を行うことができますが、バイナリファイルはこの操作をサポートしていません.例えば、wordドキュメント、ピクチャなどはバイナリで提出する必要があります.バイナリ方式では、マージができないため、1人のユーザのみがファイルを変更する保証がない場合は、ロック方式で変更することをお勧めします.注意しなければならないのは、修正が終わったらロックを解除してください.バージョン1.6から、CVSは監視の概念を導入し、この機能はユーザーに現在誰がファイルを修正しているのかをいつでも知ることができ、CVSは自動的に監視のユーザーに最新の更新を通知するメールを送信することができる.9.複数のソース・コード・ウェアハウスを構築複数の開発グループを管理する必要があり、これらの開発グループ間で相互にアクセスできない場合は、a.1つのポートを共有し、cvspserverファイルを変更し、server_に与える2つの方法があります.argsは、複数のソースコードパス、すなわち複数-allow-rootパラメータを指定します.xinetdのserver_argsの長さには制限があり、server=/home/cvsroot/cvs.runなどのcvspserverファイルでサーバの設定を別のファイルにリダイレクトできます.その後、/home/cvsroot/cvs.runファイルを作成します.このファイルは実行可能である必要があります.コンテンツフォーマットは:!/bin/bash/usr/bin/cvs-f--allow-root=/home/cvsroot/src 1--allow-root=/home/cvsroot/src 2 pserverソースコードウェアハウスは/home/cvsrootではなく、初期化するときは、/home/cvsrootパスを初期化し、/home/cvsrootパスを初期化しないことに注意してください.b.異なるポートを用いてサービスを提供する第2ステップと第3ステップを繰り返し、異なるソースコード倉庫に異なるサービス名の起動スクリプトを作成し、これらのサービス名に異なるポートを指定し、初期化時にもそれぞれ初期化しなければならない.