Perforceでは、パスワードベースとチケットベースの2つの認証方法がサポートされています。

Perforceスーパーユーザは、構成可能変数のsecurityを設定して、サーバ全体のパスワード使用要求、パスワード強度の強制、およびサポートされているユーザ/サーバ認証の方法を設定できます。security構成可能変数を変更するには、以下のコマンドを実行します。

p4 configure set security=seclevel

この場合、seclevelは0、1、2、または3です。

Perforceバージョン化サービスは、クライアントアプリケーションのどのリビジョンがPerforceに接続できるかを制御する機構を備えています。

最小のリビジョンを要求するには、構成可能変数minClientに適切なリビジョンを設定して、さらに(任意指定で)minClientMessageに古いアプリケーションのユーザがサーバに接続しようとした場合に表示されるエラーメッセージを設定します。

例:

p4 configure set minClient=2010.2
p4 configure set minClientMessage="Please upgrade to 2010.2 or higher"

サーバのセキュリティレベルとPerforceプリケーションの組み合わせに応じて、ユーザは「強い」パスワードの設定を求められる場合があります。パスワードがdm.password.minlengthに定義された文字数(デフォルトでは8文字)以上の長さで、以下の記述のうちの少なくとも2つがtrueである場合に、そのパスワードは強いと見なされます。

例えば、dm.password.minlengthが8でありsecurityを1以上に構成可能な環境では、a1b2c3d4、A1B2C3D4、aBcDeFgHなどのパスワードは強いと見なされます。

構成可能変数dm.password.minlengthを設定することにより、パスワードの最小文字数の条件をサイト全体に対して設定できます。例えば、16文字以上のパスワードを必須とするには、スーパーユーザが次のとおり実行します。

p4 configure set dm.password.minlength=16

パスワードの長さは1024文字までです。デフォルトのパスワード最小文字数は、8文字です。

Perforceスーパーユーザは、次のコマンドを使用してPerforceユーザのパスワードを手動で設定することができます。

p4 passwd username

入力を要求されたら、新しいユーザ用パスワードを入力します。

パスワード設定済みのユーザが次回Perforceを使用する際に自分のパスワードを再設定するよう強制するには、次のコマンドを使用します。

p4 admin resetpassword -u username

パスワード設定済みのすべてのユーザ(このコマンドを実行するスーパーユーザを含む)にパスワードの再設定を強制するには、次のコマンドを使用します。

p4 admin resetpassword -a

p4 admin resetpassword -aを実行すると、既に存在する(パスワードを登録済みの)ユーザのパスワードのみがリセットされます。新しいユーザアカウントをデフォルトのパスワードで作成する場合、最初のコマンドを実行する前にパスワードの再設定をすべての新規ユーザに対して要求するように、インストールを構成することができます。これを行うには、dm.user.resetpassword構成可能変数を以下のように設定します。

p4 configure set dm.user.resetpassword=1

デフォルトでは、存在しないユーザによってコマンドが発行されるたびにデータベースに新規ユーザレコードが作成されます。また、Perforceスーパーユーザは次のように-f(force)フラグを使って新規ユーザを作成することができます。

p4 user -f username

フォームフィールドに作成したいユーザに関する情報を入力します。

p4 userコマンドには、フォームエディタを使わずに標準入力できるオプション（-i）もあります。多数のユーザをすばやく作成するには、ユーザデータを読み取り、p4 userフォームによって使用されるフォーマットで出力を生成し、生成された各フォームをp4 user -i -fにパイプで送るスクリプトを作成します。

デフォルトでは、Perforceはユーザがディポまたはディポ内のメタデータを更新する可能性のあるコマンドを発行するたびに新規ユーザレコードを作成します。p4 configureコマンドでdm.user.noautocreate構成可能変数を以下のように設定することにより、この動作を制御することができます。

例:

p4 configure set dm.user.noautocreate=1

とするとサーバの動作が変更され、新しいユーザはサーバ上のデータの変更を試みる前に、まず自身のアカウントを作成することが必要になります。

p4 renameuserコマンドを使用してユーザ名を変更することができます。このコマンドはユーザ名を変更するとともに、変更を反映するように関連するアーティファクトを修正します。ユーザレコード、ユーザを含むグループ、ユーザに適用されるプロパティなどが修正されます。詳細については、『P4コマンドリファレンス』のp4 renameuserコマンドの解説を参照してください。一般的に、変更説明などの説明的テキストフィールドではユーザ名は変更されません。データベースレコードの所有者またはユーザのフィールドとして表示される名前のみ変更されます。

最善の結果を得るために下記のガイドラインに従ってください。

システム上の標準ユーザはそれぞれPerforceのライセンスを1つずつ使用しています。Perfroce管理者は、次のコマンドを使ってユーザを削除し、ライセンスの空きを作ることができます。

p4 user -d -f username

ユーザを削除する前に、チェンジリスト上でユーザが開いているファイルを取り消す(またはサブミットする)必要があります。ファイルを開いているユーザを削除しようとすると、Perforceはその旨のエラーメッセージを表示します。

ユーザを削除するとPerforceのライセンスが解放されますが、グループやプロテクションテーブルは自動的には更新されません。これらのテーブルからユーザを削除するには、p4 groupまたはp4 protectを使用してください。

Perforceのライセンスは、licenseと呼ばれるファイルにより制御されています。このファイルはサーバのルートディレクトリに格納されています。

ライセンスファイルを追加または更新するには、Perforceサーバを停止し、licenseファイルをサーバのルートディレクトリにコピーしてPerforceサーバを再起動します。

licenseを使用して標準入力から新しいライセンスファイルを読み込むことにより、Perforceサーバを停止することなく既存のp4 license -iファイルを更新することができます。

Perforceから取得した新しいライセンスファイルのほとんどは、サーバのIPアドレスが変更されている場合を除き、p4 licenseを使用してインストール可能です。サーバのIPアドレスが変更されている場合、または現時点でlicenseファイルが存在しない場合は、p4 admin restartコマンドでPerforceサーバを再起動する必要があります。

システム管理者がPerforceのバージョン化機能を使用しない組織では、operatorユーザタイプを使用することでライセンスコストを節約できる場合があります。

operatorユーザタイプは、super権限またはadmin権限を持っていますが、ソフトウェアやサーバ上のその他のアセットの開発向けではなく、Perforceサーバの保守に関して責任があるシステム管理者を対象とします。

Perforceユーザには、standardユーザ、operatorユーザ、およびserviceユーザの3種類があります。標準ユーザはデフォルトのユーザであり、それぞれ1つずつPERFORCEライセンスを消費します。サービスユーザはライセンスを必要としませんが、複製環境およびマルチサーバ環境におけるサーバ間の自動通信プロセスでしか使用できません(サービスユーザを参照してください)。operatorユーザは、Perforceライセンスを必要としませんが、以下のコマンドしか実行できません。

Perforceユーザには、standardユーザ、operatorユーザ、およびserviceユーザの3種類があります。standardユーザは従来からのPerforceユーザです。operatorユーザは人または自動処理によるシステム管理者を対象とします。serviceユーザは、リモートディポ(リモートディポと分散開発を参照してください)または分散環境(『Perforceサーバ管理者ガイド: マルチサイト展開』を参照してください)のコンテキストにおいて、サーバ間での認証に使用されます。

インストールした各Perforceサービスにserviceユーザを作成すると、サーバログの解析作業が容易になります。また通信が行われる設定になっているリモートの各Perforceサービスが、有効なログインチケットを持つことを要求し、セキュリティの向上にも役立てることができます。サービスユーザはPerforceのライセンスを消費しません。

サービスユーザは以下のコマンドしか実行できません。

サービスユーザを作成するには、次のコマンドを実行します。

p4 user -f service1

標準のユーザフォームが表示されます。改行を入力して、新しいユーザのType:をserviceに設定します。例:

User:      service1
Email:     services@example.com
FullName:  Service User for remote depots
Type:      service

デフォルトでは、p4 usersの出力にはサービスユーザが表示されません。サービスユーザを含めるには、p4 users -aを実行します。

Group:            service_users
Timeout:          unlimited
PasswordTimeout:  unlimited
Subgroups:
Owners:
Users:
        service1

不在または廃止されたユーザ(例えば退職者)によって開かれたままになっているファイルを元に戻すには、ファイルが開かれたままのクライアントワークスペース仕様をPerforce管理者が削除します。

例えば、p4 openedのアウトプットが次のように表示された場合が挙げられます。

//depot/main/code/file.c#8 - edit default change (txt) by jim@stlouis

クライアントワークスペース仕様stlouisは次のコマンドで削除できます。

p4 client -d -f stlouis

クライアントワークスペース仕様を削除すると、そのワークスペースで開かれていたファイルもすべて取り消され、ワークスペースに関連付けられた作業中チェンジリストと、ワークスペースに関連付けられた作業中の修正レコードが削除されます。クライアントワークスペース仕様を削除しても、ワークスペースの所有者が実際に使っていたワークスペースのファイルには影響しません。それらのファイルは引き続き他のユーザによってアクセス可能です。

時間の経過と共に、Perforceサーバにはあまり使用されなくなった古いプロジェクトに由来するファイルの多数のリビジョンが蓄積されます。p4 deleteは単に最新ビジョンでファイルを削除扱いにするだけなので、サーバのディスク容量に空きができるわけではありません。

アーカイブディポはこの問題への解決策となります。アーカイブディポを使用して、アクセスの少ないファイルを大容量記憶領域に移動できます。アーカイブディポを作成するには、適当なファイルシステムをマウントし、p4 archiveコマンド(および関連コマンドのp4 restore)を使用してこの記憶領域にあるアーカイブディポにデータを取り込みます。

以下の基準をすべて満たすファイルのみ、アーカイブが可能です。

アーカイブディポを作成して、そこにファイルをアーカイブするには以下を実行します。

ローカルディポに使用される(高パフォーマンスと想定される)記憶領域のディスク容量が確保されます。ユーザはアーカイブファイルの内容にアクセスできなくなりますが、すべてのファイル履歴は保持されます。

ファイルをアーカイブディポから復元するには以下を実行します。

データをアーカイブディポから完全消去するには以下を実行します。

場合により、ユーザの不注意なブランチやサブミットによってディポ内の間違った領域にファイル(またはディレクトリツリー全体)を追加してしまうことがあります。また、プロジェクトをディポから削除するだけではなく、開発作業の履歴も併せて削除する必要がある場合もあります。このような場合、p4 obliterateが役に立つでしょう。

Perforce管理者はp4 obliterate filenameを使用して、ファイルのすべての履歴をディポから削除し、それを存在しなかったも同然にすることができます。

デフォルトでは、p4 obliterate filenameは実行される内容を表示するだけで何もしません。実際にファイルを破壊するには、p4 obliterate -y filenameを使用します。

ファイルの1つのリビジョンだけを破壊するには、コマンドラインに消したいリビジョンの番号だけを指定します。例えば、リビジョン5のみを破壊するには、次のコマンドを使用します。

p4 obliterate -y file#5

リビジョン範囲の指定も可能です。ファイルのリビジョン5～7を破壊するには、次のように指定します。

p4 obliterate -y file#5,7

クライアント、ラベル、またはタスクストリームをアンロードするには、アンロードディポのファイルではなくクライアントのフラットファイルに対してp4 unloadコマンドの-oフラグを使用します。これは、クライアントを別のデータベースに読み込む場合や、クライアントのプレイベートバックアップを作成する場合に役立ちます。フラットファイルは標準のジャーナル形式を使用しています。コマンドの実行後にクライアント、ラベル、タスクストリームは完全に読み込まれた状態を維持します。

Perforce管理者は、p4 changeに-f(force)フラグを付けることでサブミット済チェンジリストの記述、日付、ユーザ名を変更できます。p4 change -f changenumberを記述します。標準のチェンジリストのフォームが表示されるだけでなく、このコマンドでスーパーユーザは、チェンジリストの時刻、コメント、日付および関連するユーザ名を編集できます。

-fフラグはp4 obliterateでファイルを消去されたサブミット済チェンジリストの削除にも使えます。p4 change -d -f changenumberと記述します。

p4 verify filenamesコマンドにより、Perforce管理者はファイルの各リビジョンについて保存されているMD5ダイジェストを検証できます。ユーザがディポにファイルを保存したとき作成された署名は、クラッシュ時にリカバリが正しく行われたことを後で確認するために利用できます。リカバリしたファイルの署名が保存されていた署名と一致すれば、そのファイルは正しくリカバリされたことになります。新しい署名がPerforceデータベースの該当するファイルリビジョンの署名と一致しなければ、Perforceは署名の後ろにBAD!と表示します。

毎晩システムバックアップを行うときには、事前にp4 verifyを実行し、p4 verifyで破損がないことを確認できた場合にのみバックアップに進むことが推奨されます。

大規模なインストールでは、p4 verifyの実行に時間がかかる場合があります。さらに、ファイル検証中はサーバの負荷が増大しているため、他のPerforceコマンドのパフォーマンスに影響を与える可能性があります。大規模なサイトの管理者は、p4 verifyを毎晩ではなく週1回実行する方が望ましい場合あります。

p4 verify実行中にBAD!が表示されるときは、データベースまたはバージョン化ファイルが破損している可能性があります。Perforceテクニカルサポートまでご連絡ください。

Perforceはファイルタイプがtextであるかbinaryであるかを判定するときに調べるバイト数を決定するために、構成可能変数filesys.binaryscanを使用します。デフォルトでは、filesys.binaryscanは65536です。先頭65536バイトについて最上位ビットが立っていなければtextと見なし、そうでなければbinaryと見なします。.zip形式(.jarファイルを含む)で圧縮されたファイルも自動的に検出され、ubinaryタイプが割り当てられます。

このデフォルトの動作は-t filetypeフラグを用いてオーバライドすることができますが、ファイルタイプが(常時ではなく)おおむね正しく検出される場合、ユーザは容易にこのオプションを指定し忘れてしまいます。RTF(Rich Text Format)やAdobe PDF(Portable Document Format)などの一部のファイルフォーマットは、一連のコメントフィールドまたはその他のテキスト形式のデータで始まることがあります。この場合コメントがある程度長いと、このようなファイルはPerforceサーバによって誤ってtextのタイプとして検出されます。

p4 typemapコマンドにより、システム管理者はPerforceのファイルタイプとファイル名の仕様をリンクさせるテーブルを設定できるため、この問題を解決できます。追加されているファイルが設定したタイプマップテーブルの入力と一致すると、ファイルタイプがオーバーライドされ、一致しない場合には、Perforceアプリケーションがファイルタイプを割り当てます。例えば、すべてのPDFファイルとRTFファイルをbinaryとして処理するには、p4 typemapを使用してタイプマップテーブルを以下のように修正します。

Typemap:
        binary //....pdf
        binary //....rtf

最初の3個のピリオド(“...”)はルートディレクトリ下の全ファイルをマッピングの対象に含めるPerforceのワイルドカードです。4個目のピリオドとファイル拡張子は、ファイル名の最後が.pdf(または.rtf)で終わるファイルを対象すとる指定です。

以下の表に、一般的なファイル拡張子と、それに対応するPerforceのファイルタイプおよび修飾子を示します。

上記の表で推奨されたすべてのファイル拡張子をPerforceのファイルタイプにマッピングするには、次のようにp4 typemapテーブルを使用します。

# Perforce File Type Mapping Specifications.
#
#  TypeMap:     a list of filetype mappings; one per line.
#               Each line has two elements:
#               Filetype: The filetype to use on 'p4 add'.
#               Path:     File pattern which will use this filetype.
# See 'p4 help typemap' for more information.
TypeMap:

        text //....asp
        binary+F //....avi
        binary //....bmp
        binary //....btr
        text //....cnf
        text //....css
        binary //....doc
        binary //....dot
        binary+w //....exp
        binary+F //....gif
        binary+F //....gz
        text //....htm
        text //....html
        binary //....ico
        text //....inc
        text+w //....ini
        binary //....jpg
        text //....js
        binary+w //....lib
        text+w //....log
        binary+F //....mpg
        binary //....pdf
        text+w //....pdm
        binary //....ppt
        binary //....xls

あるファイルタイプに複数のファイルタイプ修飾子を使用する必要がある場合、修飾子を続けて指定します。例えば、binary+lFS10とすると、binaryタイプで排他的作業状態(l)であり、圧縮されずに完全な形で保存され(F)、最新の10リビジョンのみが保存されている(S10)ファイルを意味します。

詳細については、『P4コマンドリファレンス』のp4 typemapのページを参照してください。

デフォルトで、Perforceは同時並行開発をサポートしていますが、編集目的でファイルを開くのは一度に一人のユーザのみであることが想定される環境では、部分ファイルタイプで修飾子+l（排他的作業状態）を使用して悲観的ロックを実施することができます。次のようにタイプマップを定義すると、ディポ内にあるすべての新規で追加されたファイルに対し+l修飾子が自動的に適用されます。

Typemap:
        +l //depot/...

このタイプマップを使用すると、タイプマップの更新後、ユーザがディポに追加したファイルに自動的に+l修飾子が適用されるので、以降そのファイルを編集目的で作業状態にできるのは一度に一人のユーザに限られます。タイプマップテーブルはディポへの新規追加分にのみ適用されます。したがって、タイプマップテーブルをサイト全体で排他的作業状態に更新した後、それ以前に+lを付けずにサブミットしたファイルは、p4 edit -t+l filenameコマンドを使って編集目的で開いて、再度サブミットしなければなりません。同様に、すでにファイルを編集目的で開いているユーザは、p4 reopen -t+l filenameコマンドでファイルタイプを更新しなければなりません。

Perforceスーパーユーザや管理者は、特定のコマンドに-fフラグを指定することによって、一般ユーザは実行できないような特定の操作を強制的に実行できます。Perforce管理者は、p4 branch、p4 change、p4 client、p4 job、p4 label、p4 unlockで-fフラグを使用できます。Perforceスーパーユーザはさらに、このフラグを使用してp4 userコマンドをオーバーライドできます。このフラグの用法と意味は次のとおりです。

2012.1でSSLのサポートが追加されたことで、信頼されていない通信チャネルでPerforceを安全に実行するためにsshやその他のVPNトンネルを手動で構成する必要はなくなりました。

ほとんどの場合、PerforceサーバのP4PORT設定はプロトコルとポート番号で構成されています。ユーザがPerforceサーバに接続するためには、サーバのIPアドレスを知っている(またはホスト名からそれを導き出せる)必要があります。

p4dプロセスにP4PORTでIPアドレスおよびポート番号の両方を指定すれば、PerforceサーバはP4PORTで指定された以外のIPアドレスからの要求は一切無視するようになります。このような設定は、p4dを特定のネットワークインターフェイスまたはIPアドレスに対してのみ接続待ちをするように構成したいときなどに役立ちます。例えば、P4PORT==protocol:localhost:portと設定すると、Perforceサーバはすべての非ローカル接続の要求を無視します。

通常のインストールを行ったPERFORCEサービスは、UNIX上で、ユーザからの接続要求を待つバックグラウンドプロセスとして動作します。接続があったときに初めてp4dを起動するようにするには、inetdとp4d -iを使用して、/etc/inetd.confの後に次の行を記述します。

p4dservice stream tcp nowait username /usr/local/bin/p4d p4d -i -r p4droot

さらに、/etc/servicesの後に次の行を記述します。

p4dservice nnnn /tcp

ただし、

/etc/inetd.confの行に、必ずp4dを“2つ”記述してください。inetdはこれをargv[0]としてOSに渡します。そのとき、最初の引数は-iフラグで、これによってp4dは、デーモンとしてバックグラウンドで動作するのではなく、stdin/stdout上で接続された単一のクライアントに対してサービスを行います。(inetdによって起動されるサービスにおいて、通例といえる方法です。)

これは、起動スクリプト以外からp4dを動作させる方法の1つです。特別なサービスの提供にも利用することができます。例えば、Perforce社では、UNIX上で動作するテストサーバが多数あり、それぞれが独自のポート番号を持つinetdサービスとして定義されています。

この方法には、注意すべき点があります。

初期(97.2以前)のリリースのPerforceサーバはUNIX環境、Windows環境を問わず、すべてのファイル名、パス名、およびデータベースのエンティティ名を、大文字/小文字の区別をつけて扱っていました。

例えば、//depot/main/file.cと//depot/MAIN/FILE.Cは、完全に異なる2つのファイルとして扱われました。このため、UNIX上のユーザがWindows上で動作しているPerforceサーバに接続している場合に、さまざまな問題が生じました。これは、Windowsサーバの基本的なファイルシステムでは、UNIXユーザによってサブミットされる、大文字と小文字が区別された名前のファイルを保存できなかったためです。

リリース97.3で、この状況は変わりました。UNIXサーバだけが、大文字と小文字が区別される名前をサポートするようになりました。とはいえ、UNIXとWindowsの両方にまたがる環境で開発プロジェクトを行っている場合には、いまだにユーザは大文字/小文字区別の問題にぶつかることがあります。

97.2以前のサーバをWindowsでご使用の場合には、support@perforce.comに連絡して、サーバやデータベースのアップグレードをご相談ください。

現在リリースされているサーバでは：

次の表は、これらの規則を要約しています。

Perforceサーバが動作しているプラットフォームはp4 infoで確認できます。

Perforceサーバ上で実行中のPerforce関連プロセスの監視と制御を行うには、p4 monitorコマンドを使用します。

8764 R user 00:00:00 edit
      [server.locks/clients/88,d/ws4(W),db.locks(R),db.rev(R)]
8766 R user 00:00:00 edit
      [server.locks/clients/89,d/ws5(W),db.locks(R),db.rev(R)]
8768 R user 00:00:00 monitor

Perforceサーバによって監視されているプロセスを一覧表示するには、次のコマンドを使用します。

p4 monitor show

現在実行中のプロセスのみを表示するには、次のコマンドを使用します。

p4 monitor show -s R

デフォルトではp4 monitorの出力の各行は、次のようになります。

pid status owner hh:mm:ss command [args]

ここで、pidはUNIXのプロセスID(WindowsのスレッドID)です。statusはRもしくはTで、実行中か終了しているかを示します。ownerは、そのコマンドを実行しているユーザのPerforceユーザ名です。hh:mm:ssは、そのコマンドを実行してから経過した時間です。commandとargsは、Perforceサーバが受け取ったコマンドと引数です。例:

$ p4 monitor show
74612 R qatool     00:00:47 job
78143 R edk        00:00:01 filelog
78207 R p4admin    00:00:00 monitor

実行時、コマンドと共に指定された引数を表示するには、次のように-a(引数)フラグを使用します。

$ p4 monitor show -a
74612 R qatool     00:00:48 job job004836
78143 R edk        00:00:02 filelog //depot/main/src/proj/file1.c //dep
78208 R p4admin    00:00:00 monitor show -a

ユーザ環境に関する追加情報を取得するには、-eフラグを使用します。-eフラグは、以下のようなフォームの出力を生成します。

pid client IP-address status owner workspace hh:mm:ss command [args]

この場合、clientはPerforceアプリケーション(およびバージョン文字列またはAPIプロトコルレベル)、IP-addressはユーザのPerforceアプリケーションのIPアドレス、workspaceはユーザの現在のクライアントワークスペースの設定です。例:

$ p4 monitor show -e
74612 p4/2011.1 192.168.10.2   R qatool    buildenvir 00:00:47 job
78143           192.168.10.4   R edk       eds_elm    00:00:01 filelog
78207 p4/2011.1 192.168.10.10  R p4admin   p4server   00:00:00 monitor

デフォルトで、すべてのユーザ名とクライアントワークスペース名(該当する場合)は10文字で切り捨てられ、行は80文字で切り捨てられます。この切り捨てを無効にするには、次のように-l(long-form)オプションを使用します。

$ p4 monitor show -a -l
74612 R qatool     00:00:50 job job004836
78143 R edk        00:00:04 filelog //depot/main/src/proj/file1.c //dep
ot/main/src/proj/file1.mpg
78209 R p4admin    00:00:00 monitor show -a -l

-a、-l、-eのオプションを使用できるのは、Perforce管理者とスーパーユーザのみです。

コマンドトレーシングまたはパフォーマンス追跡の動作を変更するには、p4d起動コマンドに適切な-v subsystem=valueフラグを指定します。ログファイルの名前はP4LOGまたは-L logfileフラグで指定します。例:

p4d -r /usr/perforce -v server=2 -p 1666 -L /usr/perforce/logfile

ログ記録を開始する前に、十分なディスク容量を確保しておく必要があります。

Perforceサーバ(p4d)でサーバデバッグレベルを設定しても、Perforceプロキシ(p4p)プロセスのデバッグレベルには何の影響もありません。また、この逆も同様です。

Perforceサーバコマンドのトレーシングおよび追跡のオプションをより高いレベルに設定することは、通常、システム管理者がPerforceテクニカルサポートとともに問題の診断や調査にあたる場合にのみ推奨されます。

Perforceサーバは個々のファイルへのアクセスを監査ログファイルに記録することができます。デフォルトでは監査機能は無効です。これを有効にするには、P4AUDITを監査ログファイルの場所を示すよう設定するか、もしくはサーバ起動時に-A auditlogフラグを指定する必要があります。

監査が有効にされると、サーバからクライアントへファイルコンテンツが転送されるたびに、サーバが監査ログファイルに一行追加します。アクティブなサーバ上では、監査ログファイルは非常に急速に増大します。

監査ログの行は次の形式で出力されます。

date time user@client clientIP command file#rev

例:

$ tail -2 auditlog
2011/05/09 09:52:45 karl@nail 192.168.0.12 diff //depot/src/x.c#1
2011/05/09 09:54:13 jim@stone 127.0.0.1 sync //depot/inc/file.h#1

Perforceサーバを実行しているマシン上でコマンドが実行されると、clientIPは127.0.0.1と表示されます。

複製環境においてサーバの動作を監査している場合、ビルドファームとなるサーバまたは転送レプリカサーバのそれぞれに、固有のP4AUDITログが設定されている必要があります。

ログファイルを構造化形式(.csv)で書き込むようにPerforceサーバを構成することができます。構造化ログファイルには一般的なログファイルよりも詳細な情報が含まれ、より解析しやすくなっています。また、Perforceサーバはユーザのサイトのログ記録の設定をカスタマイズするためのコマンドを追加で提供しています。このセクションでは、ログ記録の管理に使用するコマンドの概要とともに、構造化ログの使用方法と、ログファイルのローテーションを説明します。

p4 configure set serverlog.counter.3=myErrors

ユーザ認証は次の3つのいずれかのオプションで行うことができます。

認証は(トリガベースの認証でない限り)ユーザベースで行われます。各ユーザに対して認証に使用する方法を指定することができます。一部のオプションは互いに相容れません。例えば、コンフィギュレーションベースのLDAP認証はトリガベースのLDAP認証を無効にします。ただし、一部のユーザの認証にLDAPを使用し、その他のユーザに関してはPerforceの内部ユーザデータベースに照会することは可能です。詳細については、ユーザ用の認証を定義するを参照してください。

LDAP(Lightweight Directory Access Protocol)は、Active DirectoryやOpenLDAPによって代表されるさまざまなディレクトリサービスでサポートされています。PerforceはActive DirectoryまたはLDAPサーバに対して2種類の認証方法を提供します。認証トリガを使用する方法と、LDAP仕様により認証を行う方法です。後者の方法には複数の利点があります。簡単に使用できるほか、外部のスクリプトが不要で、バインドメソッドをより柔軟に定義できます。また、LDAPディレクトリにないユーザに対してPerforceの内部ユーザデータベースへの照会による認証を許可でき、より安全な方法です。

コンフィギュレーションベースのLDAP認証を設定するために必要な手順について、以下のセクションで詳細を解説します。このセクションのLDAP認証に関連するすべての情報は、Active Directoryの使用時にも共通して当てはまります。設定手順の概要は次の通りです。

LDAPコンフィギュレーションは、Perforceサーバがユーザを認証する際に照会するActive Directoryまたはその他のLDAPサーバを指定します。コンフィギュレーションを作成するには、p4 ldapコマンドを使用します。

LDAPコンフィギュレーション仕様を定義するには、Active DirectoryまたはLDAPサービスのホスト名とポート番号、バインドメソッドについての情報、セキュリティパラメータを指定します。バインドメソッドに検索(search)を使用したLDAPコンフィギュレーションのサンプルを以下に示します。

Name:              sleepy
Host:              openLdap.example.com
Port:              389
Encryption:        tls
BindMethod:        search
SearchBaseDN:      ou=employees,dc=example,dc=com
SearchFilter:      (cn=%user%)
SearchScope:       subtree
GroupSearchScope:  subtree

バインドメソッドはSASL、simple、またはsearchから選択することができます。

p4 ldapコマンドとLDAP仕様に関する詳細については、『P4コマンドリファレンス』を参照してください。

コンフィギュレーション作成後に構成可能変数auth.ldap.order.Nでそれを有効にする必要があります。例:

p4 configure set auth.ldap.order.1=sleepy

これでコンフィギュレーションが有効になり、認証に使用される状態になります。認証プロセスを定義するために追加で構成可能変数を定義しなければならない場合があります。これについては、LDAPに関連する構成可能変数を定義するで解説しています。

次のような場合には、複数のLDAPコンフィギュレーションを作成する必要があります。

LDAP認証を使用するには、認証に関連するいくつかの構成可能変数を設定する必要があります。

たとえば、以下のコマンドはActive Drectoryの検索順序とを指定するとともに、新しいユーザに対するデフォルトの認証先をperforceに設定します。

p4 configure set auth.ldap.order.1=sleepy
p4 configure set auth.ldap.order.2=dopey
p4 configure set auth.ldap.order.5=sneezy
p4 configure set auth.default.method=perforce

認証に関連する構成可能変数についての追加情報は、『P4コマンドリファレンス』の付録、「構成可能変数」を参照してください。

認証は、ユーザ仕様のAuthMethodフィールドの設定およびユーザ認証に影響を及ぼす構成可能変数により定義されています。

各ユーザに対して使用される認証方法は、p4 userコマンドで作成されるユーザ仕様のAuthMethodフィールドで定義されます。

デフォルト値をldapに変更するには、p4 user -fコマンドでユーザ仕様を編集する必要があります。ユーザ仕様の値AuthMethodを変更できるのはスーパーユーザに限られます。

構成可能変数auth.method.defaultは新しいユーザに対するAuthMethodのデフォルト値を定義します。指定できる値はperforceまたはldapです。

If you select the ldapの構成可能変数を選択した場合、スーパーユーザだけが(p4 userコマンドを使用して)新しいユーザを作成できます。新しいユーザをログイン時に自動で作成するには、auth.ldap.userautocreateを1に設定します。

PerforceにアクセスできるLDAPユーザをさらに細かく制御する必要がある場合、LDAPコンフィギュレーションのグループに関連するフィールドを使用して、Perforceユーザ以外をフィルタで除外することができる基本の認証手順を実施するようにできます。たとえば、次のようにフィルタを指定すればperforceという共通名(cn)を持つLDAP グループに属するLDAPユーザのアクセスを制限することができます。

Base DN: ou=groups,dc=example,dc=org 
LDAP query: (&(cn=perforce)(memberUid=%user%))

上記の例では、正しい資格情報を提供可能なユーザと指定されたグループのメンバーのみが認証されます。構成可能変数auth.method.defaultについて詳しくは、『P4コマンドレファレンス』のp4 configureコマンドの解説を参照してください。

ユーザ認証の設定にバインドメソッドを使用する一方で、組織内の全員が(特に全員が同一のディレクトリに存在するような場合に)Perforceサーバへログインできるようにはしたくない場合があります。このようなときは、代わりにそのディレクトリに認証済のユーザのみを含むグループオブジェクトを作成します。LDAPの新しい統合によって、グループのメンバー構成がサポートされるようになりました。

LDAPグループは検索バインドメソッドと同様の働きをします。LDAP検索クエリにより、ユーザが許可されるグループのメンバーであるか否かが決定されます。また、検索のベースと範囲も使用することができます。たとえば、LDAPディレクトリにperforceという名前でPerforceサーバへのアクセスがユーザに許可されているグループがある場合、その構成は以下のようになります。

GroupBaseDN:    ou=groups, dc=example, dc=com
SearchFilter:   (&(objectClass=posixGroup) (cn=perforce) (memberUid=%user%))
SearchScope:    subtree

Active DirectoryのグループオブジェクトはOpenLDAPのグループオブジェクトとわずかながら異なります。OpenLDAPにはメンバーのユーザ名のリストではなく、メンバーの完全なDNのリストが含まれます。通常これらを簡単に一致させることはできませんが、メンバーのユーザオブジェクトに追加される後方参照であれば一致させることができます。したがって、Active Directoryへ照会してグループの認証をする場合、ユーザのユーザオブジェクトを検索して、そのグループへのmemberOfの参照がないか探す必要があります。例:

GroupBaseDN:    ou=groups, dc=example, dc=com
SearchFilter:   (&(objectClass=user) (sAMAccountName=%user%) 
                    (memberOf=cn=perforce,ou=groups, dc=example, dc=com))
SearchScope:    subtree

LDAPコンフィギュレーションを有効にする前に、perforce認証を使用するsuperのアクセス権を持つアカウントを最低1つ作成してください。これにより、何らかの理由でAD/LDAPの接続を失った場合でもログインが可能になります。

LDAPコンフィギュレーションを作成が済んだら、それをテストして有効にする必要があります。LDAPコンフィギュレーションのテストを行えることで、既存ユーザに影響を与えることなくすべての動作が適切であるか確認することができます。すでに認証トリガを使用してLDAPに照会をしているような場合でも、テストを実行できます。LDAPコンフィギュレーションに問題がないことが確認できたら、再度作成し直すことなくユーザを新たな方法へと切り替えることができます。以下の手順は、コンフィギュレーションのテストと有効化のプロセスを詳しく説明します。

単一のLDAPサーバへの照会による認証をテストする以外にも、p4 ldaps -tコマンドを使用することで複数のサーバへの照会をテストすることができます。詳細については、『P4コマンドリファレンス』のp4 ldaps -tコマンドの解説を参照してください。

LDAPサーバの情報を取得するには、2つのコマンドを使用することができます。

詳細については、『P4コマンドリファレンス』の上記2つのコマンドの解説を参照してください。

新旧マシンのアーキテクチャで同じバイト順(例えばSPARC/SPARC、x86/x86、または32ビットWindowsから64ビットWindowsへ)を使用するなら、バージョン化ファイルもデータベースも2台の間で直接コピーできます。必要な操作はサーバルートのディレクトリツリーを新しいマシンに移すことだけです。tar、cp、xcopy.exeなど、あらゆる方法が使えます。P4ROOTディレクトリにあるもの、db.*ファイル(データベース)とディポのサブディレクトリ(バージョンファイル)をすべてコピーしてください。

(同一アーキテクチャ間の移動の場合、バックアップ、チェックポイント、移行後のp4 verifyは、厳密には必要ありませんが、移行の前後では、いつもシステムの完全性確認、チェックポイント、バックアップを行うようにすることが推奨されています。)

2台のマシン間で内部データ表現(ビッグエンディアンかリトルエンディアン)の規定に違いがあるが(例えば、Linux-on-x86/SPARC)、オペレーティングシステムはともに同じCR/LFテキストファイル規定を採用している場合も、簡単にサーバルートのディレクトリツリーを新しいマシンに移すことができます。

バージョンファイルはアーキテクチャ間で移動可能ですが、db.*ファイルに保存されているデータベースは違います。このようなデータベースを移動するには、古いマシンでPerforceサーバのデータベースのチェックポイントを作成し、そのチェックポイントを利用して、新しいマシン上にデータベースを再構成します。チェックポイントはテキストファイルであるため、あらゆるアーキテクチャのPerforceサーバで読み取ることができます。詳細についは、チェックポイントを作成するを参照してください。

チェックポイントを作成したら、tar、cp、xcopy.exeなどを用いてそのチェックポイントファイルとディポのディレクトリを新しいマシンにコピーします。(db.*ファイルはチェックポイントから再生されるので、コピーする必要はありません。)

この場合は、システムのアーキテクチャとCR/LFテキストファイルのどちらも異なる可能性があります。同様にチェックポイントを作成してコピーし、新しいプラットフォーム上でデータベースを再構成する必要がありますが、バージョンファイルを格納しているディポのサブディレクトリを移すときは、プラットフォーム間の異なる改行規定にも対処しなければなりません。

ディポのサブディレクトリには、テキストファイルもバイナリファイルも格納されます。テキストファイル(RCSフォーマットなら最後が“,v”)とバイナリファイル(個々にディレクトリを持ち、各ディレクトリの最後が“,d”)は、テキストファイルでは行末を変換するため(バイナリファイルはそのまま)、別々の方法で移す必要があります。

前述の他の移行の場合と同様、移行後は必ずp4 verifyを実行してください。

PerforceサーバをWindowsからUNIXへ、またはその逆に移行するときは、Perforceテクニカルサポートまでお問い合わせください。

新しいマシンのIPアドレスが古いマシンのときと異なる場合は、プロテクションテーブルのIPアドレスに基く保護を更新する必要があります。Perforceサーバのプロテクションの設定については、“Perforceの管理: 保護”を参照してください。

ライセンスをお持ちの場合でも、新しいIPアドレスを反映した新しいライセンスファイルが必要になります。Perforceテクニカルサポートにお問い合わせのうえ更新されたライセンスを取得してください。

新しいサーバマシンのホスト名が旧マシンのときと異なる場合は、P4PORTの設定を変更する必要があります。旧マシンが廃棄または名称が変更される場合は、旧マシンに適合するエイリアスを新しいマシンに設定すれば、P4PORTの設定変更が不要になります。

ディポ名は、ブランチ名、クライアントワークスペース名、ラベル名とネームスペースを共用します。例えば、//rel2はディポrel2、ワークスペースrel2、ブランチrel2、またはラベルrel2のうちいずれかを一意に指すものです。rel2というディポとラベルを両方同時に持つことはできません。

新しいローカルディポを定義する(つまり、現在のPerforceサーバのネームスペースに新しいディポを作成する)には、新しいディポの名前でp4 depotを呼び出し、表示されるフォーム内のMap:のフィールドのみを変更します。

例えば、bookという新しいディポを作成し、bookというルートサブディレクトリのPerforceサーバのネームスペースにファイルを保存する場合(つまり$P4ROOT/book)、コマンドp4 depot bookを入力し、表示されるフォームを次のように埋めます。

Depot:       book
Type:        local
Address:     local
Suffix:      .p4s
Map:         book/...

Address:フィールドとSuffix:フィールドはローカルディポには適用されないため、無視されます。

デフォルトでは、ローカルディポ上のMap:フィールドは、ディポ名と一致しているディポディレクトリを指し示し、サーバ上で設定されているサーバルート(P4ROOT)からの相対パスとなります。ディポでバージョン管理するファイルを別のボリュームやドライブに保持するには、Map:フィールドに絶対パスを指定します。このパスはP4ROOT下でなくとも構いません。Windows上でMap:フィールドに絶対パスを指定する場合は、p4 depotフォームでスラッシュ(d:/newdepot/など)を使用する必要があります。

スペックディポを利用してバージョン化仕様を有効にするユーザがユーザ編集フォームに対する変更履歴を取得するには、バージョン化仕様を有効にする必要があります。スペックディポにはどのような名前でも付けられますが、タイプをspecにする必要があります。また、一つのサーバに対して一つしか作成できません。(スペックディポが既に存在する場合、別のスペックディポを作成しようとするとエラーメッセージが出力されます。)

スペックディポを作成してバージョン化仕様を有効にすると、すべてのユーザ生成フォーム(クライアントワークスペース仕様、ジョブ、ブランチマッピングなど)は自動的にスペックディポにテキストファイルとしてアーカイブされます。スペックディポでのファイル名はサーバにより自動的に生成され、以下のPerforceシンタックスで表示されます。

//specdepotname/formtype/[objectname[suffix]]

一部のformtype(protect、triggers、typemapなどのフォーム)はそのサーバに固有であり、対応するobjectnameがありません。

Depot:       spec
Type:        spec
Address:     local
Map:         spec/...
SpecMap:     //spec/...
Suffix:      .p4s

SpecMap:
    //spec/...
    -//spec/protect/...

SpecMap:
    //spec/...
    -//spec/client/build_ws_*
    -//spec/label/temp_label_*

現在のPerforceサーバが認識しているすべてのディポのリストはp4 depotsコマンドで表示することができます。

ディポを削除するには、p4 depot -d depotnameコマンドを使います。

ディポを削除するには、事前にp4 obliterateを実行し、ディポ内のすべてのファイルを削除しておかなければなりません。

localディポおよびspecディポにおいて、p4 obliterateは関連するメタデータとともにバージョンファイルを削除します。remoteディポにおいて、p4 obliterateはローカルに保持しているクライアントおよびラベルの記録のみを消去します。リモートサーバ上のファイルとメタデータは、そのまま残ります。

p4 obliterateを実行する前、特にディポ内のすべてのファイルを削除するようなときには、ファイルを削除してディスク容量を再生するに記載される警告を読んで理解してください。

分散環境では、アンロードディポがエッジサーバごとに異なる内容を含んでいる場合があります。コミットサーバは、すべてのエッジサーバ上でアンロードディポが空であるかの検証を行わないため、コミットサーバからアンロードディポを削除するにはp4 depot -d -fを指定する必要があります。詳細については、『Perforceサーバ管理者ガイド: マルチサイト展開』を参照してください。

Perforceは大規模なネットワークの待ち時間に対処するように設計されており、本来、リモートサイトにクライアントワークスペースを持つユーザをサポートします。Perforceは、共同開発者の地理的な分散に関係なく、1台のサーバで共同開発プロジェクトをサポートできます。

共同開発プロジェクトを分割し、複数のPerforceシステムで行っても、スループットが改善されることはなく、通常は管理が複雑になるだけでしょう。サイトが分散型の開発に参加している場合には、通常は単一のPerforceサーバ上のディポ内にすべてのコードを置き、個々の開発サイトの頻繁にアクセスされるファイルをPerforceプロキシによってキャッシュするようにするほうがよいでしょう。Perforceの分散構成の設定と監視について詳しくは、『Perforceサーバ管理者ガイド: マルチサイト展開』を参照してください。

ただし、他の組織の成果物を定期的にインポートしたりエクスポートしたりするような場合には、コードドロップの手順を合理化するためにPerforceのリモートディポは利用価値があると言えます。

別のサーバのディポにあるファイルに対して、PerforceアプリケーションがどのようにユーザのデフォルトPerforceサーバにアクセスするかを、次の図に示します。

この例では、oak:1234のPerforceサーバにおける管理者は、pine:1818のリモートサーバからファイルを取得しようとしています。

開発者が個別にリモートディポからクライアントワークスペースへファイルを同期することは可能ですが、一般的にリソースの使い方が効率的ではありません。

組織におけるビルドや提供資料の管理者にとって、リモートディポからローカルディポの領域へファイルを反映することが、効率的なリモートディポの使い方と言えます。反映した後、開発者は、ローカルディポ内にある反映済みのファイルのコピーにアクセスすることができます。

リモートディポからのコードドロップを承諾するには、ローカルディポ内にリモートディポ内のファイルからのブランチを作成し、そのローカルブランチの中へリモートディポからの変更を反映します。この反映は、一方通行の操作となります。つまり、ローカルブランチで実施した変更をリモートディポへ反映し直すことはできません。自サイトのPerforce環境の中へ反映したファイルのコピーに対しては、自サイトの開発チームが責任を持ちます。ディポ上のファイルは、他のPerforce環境における開発チームの管理下に残ります。

コードドロップを実現するには、2つの組織間に役割を持たせる必要があります。つまり、コードドロップを受領するサイトと、コードドロップを提供するサイトです。多くの場合、次の3点が設定されていなければなりません。

Depot:       from-pine
Type:        remote
Address:     pine:1818
Map:         //depot/outbound/...

list user * * -//from-pine/...
read user adm * //from-pine/...

list user remote * -//...
read user remote 192.168.41.2 //depot/outbound/...

p4 pushとp4 fetchのコマンドを正しく動作させるには、アルゼンチン、米国、スウェーデンの3つのサーバのリモート仕様をそれぞれ正しく設定する必要があります。リモート仕様は、ローカルサーバがフェッチまたはプッシュ可能なリモートサーバを指定します。また、フェッチまたはプッシュされるファイルを指定します。(リモートおよびリモート仕様に関する詳細については、「分散バージョニングでPerforceを使用する」の「リモートを理解する」を参照してください。

アルゼンチンの開発者はフェッチとプッシュをスウェーデンのサーバに対して行うため、そのサーバのリモート仕様は以下のようになります。

RemoteID: ServerSweden
Address: ServerSweden:1666
DepotMap:
  //depot/code-dropA/... //depot/Sweden-dev/...
  //depot/Argentina-dev/... //depot/code-dropS/...

米国の開発者はフェッチとプッシュをスウェーデンのサーバに対して行うため、そのサーバのリモート仕様は以下のようになります。

RemoteID: ServerSweden
Address: ServerSweden:1666
DepotMap:
  //depot/code-dropUSA/... //depot/Sweden-dev/...
  //depot/USA-dev/... //depot/code-dropS/...

スウェーディンの開発者はフェッチとプッシュをアルゼンチンのサーバに対して行うため、そのサーバのリモート仕様は以下のようになります。

RemoteID: ServerArgentina
Address: ServerArgentina:1666
DepotMap:
  //depot/code-dropS/... //depot/Argentina-dev/...
  //depot/Sweden-dev/... //depot/code-dropA/...

スウェーディンの開発者はフェッチとプッシュを米国のサーバに対して行うため、そのサーバの2番目のリモート仕様は以下のようになります。

RemoteID: ServerUnitedStates
Address: ServerUnitedStates:1666
DepotMap:
  //depot/code-dropS/... //depot/USA-dev/...
  //depot/Sweden-dev/... //depot/code-dropUSA/...

PerforceサーバをUnicodeモードで実行することで、サーバ上でのUnicode表記から特定の要素を変換できるようになります。また、クライアントが使用する特定の文字セットをサーバに関連付けることができます。以下の要素の変換が可能です。

通常は、サーバをUnicodeモードに設定すると、サーバが実行されるプラットフォームによらず、各クライアントに適切なレンダリングが自動で構成されます。ただし、クライアントを設定する必要がある場合があります。以下のサブセクションでは、必要に応じてサーバとクライアントを設定する方法とトラブルシューティングのヒントをいくつか紹介します。

Unicodeサーバとそこにアクセスするワークステーションの設定方法は、今回初めてサーバを起動するか、あるいは既存のUnicodeではないサーバをUnicodeモードへ変換するかにより異なります。以下のセクションではそれぞれの使用例を説明します。

サーバをUnicodeモードで稼働するように設定するとき、クライアントにより現在の環境が検証され、使用する文字セットが特定されます。通常であれば、適切な翻訳を取得するために追加の操作は必要ありません。例えば、UNIXのクライアントは変数LANGまたはLOCALEを検証し、適切な文字セットが特定されます。ただし、以下のような場合にはクライアントにより選択された文字セットをオーバーライドしなければなりません。

上記のいずれの場合も、明示的にP4CHARSETを適切な値に設定するか、その他の操作を行うことが必要です。P4CHARSETの可能な値を取得するには、次のコマンドを使用します。

p4 help P4CHARSET

ファイルの破損を防止するため、ワークステーションを正しく構成することは不可欠です。次のセクションでは、一般的な問題について説明し、解決方法を説明します。

ユーザが新しいPerforceサービスに接続すると、パフォーマンス関連のプロパティはそのユーザが最後に接続していたPerforceサービスからリロードされます。

以下プロパティを使用して、P4Vの機能を有効または無効にすることができます。これらのプロパティはP4Vの起動時に、ユーザが最初に接続するサービスから一度だけ読み込まれます。これらのプロパティをOffに設定して非アクティブにされた機能はP4Vで使用不可となり、P4Vのプリファレンスのページに表示されません。

例えば、Perforceの欠陥追跡機能を使用していないサイトの管理者は、P4Vから次のコマンドを実行してジョブへのアクセスを無効にできます。

p4 property -a -n P4V.Features.Jobs -v Off

新しいプロパティが追加/更新され(-a)、その名前(-n)はP4V.Features.Jobsであり、Offという値(-v)が割り当てられます。

組織内のあるユーザグループがP4Vのジョブ機能を使用する必要がある場合、次のコマンドを実行して、そのユーザに対して選択的に(集中管理で)その機能を有効に再設定することができます。

p4 property -a -n P4V.Features.Jobs -v On -g jobusers

P4Vのジョブ機能の値をOnに設定してP4Vのジョブ機能が再び有効になるのは、jobusersグループのユーザの場合に限られます。

P4.Combine.URLのプロパティを使用して、P4MergeにおけるMicrosoft Word .docxファイルのリッチ比較を有効にすることができます。この機能を使用するには、共通のデプロイメントの一部としてP4Combineを展開する必要があります。

機能を有効にするには、P4.Combine.URLのサーバプロパティをP4Combine Web ServiceのURLに設定します。これで、P4Vは.docxファイルのリッチ比較をP4Mergeウィンドウに表示するようになります。テキスト、画像、形式、スタイル、表、ヘッダー、フッター、その他のオブジェクトの差分がHTML5で表示されます。