Wiki

Ubuntu / Debian にインストール

.deb パッケージ：3 つの質問、データディレクトリ、オフラインインストール、バックアップとアンインストール。

Ubuntu 24.04+、Debian 13+（x86_64）。2 つのコマンド、3 つの質問。

インストール

1. パッケージをダウンロード

サーバーをホストするマシンで、通常のセッションで実行します：

cd /tmp && wget -N https://uversion.io/downloads/server/uversion-server_latest_amd64.deb

_latest_ の URL は常に最新の公開バージョンを指します。 -N フラグは、リモートファイルの方が新しい場合にのみ再ダウンロードするよう wget に指示します：.deb.1、 .deb.2 などのコピーを溜め込まずに更新できるので便利です。 .deb がホームディレクトリにある場合、cd /tmp は見た目上の apt 警告（"unsandboxed as root"）を回避します。

2. インストールを開始

ダウンロードしたばかりのパッケージがあるディレクトリで、コマンドを 1 つ実行します：

sudo apt install ./uversion-server_latest_amd64.deb

するとインストーラーは、次の 3 つのステップの順で3 つの質問をします。全画面の青いダイアログに表示されます：Tab で移動し、Enter で確定します。

3. 回答：データディレクトリ

デフォルト：/var/lib/uversion。ここにバージョン管理されたファイルの内容が保存されます。つまり大きくなるディレクトリであり、大容量ディスクに置きたいディレクトリです。すべてのパスが受け入れられるわけではありません：データディレクトリを選ぶのセクションに 4 つのルールがあり、インストーラーは違反したルールを示して拒否します。

Debian インストーラーの最初の質問。全画面の青いダイアログ内：データディレクトリのパスが /var/lib/uversion であらかじめ入力されている。

4. 回答：データベースもデータディレクトリに置きますか？

デフォルト：いいえ。これはインストールで最も影響の大きい質問であり、このデフォルトにはそのままにする前に知っておくべきコストがあります。

この回答は、1 台のディスクだけでサーバーを再構築できるかどうかを決めます。

いいえ（デフォルト）：PostgreSQL データベースはシステムディレクトリ（/var/lib/postgresql）に残り、データとは分離されます。マシンが故障した場合、生き残ったデータディスクにはファイルの内容が含まれますが、リビジョン、アカウント、ロック、権限は一切ありません。これは再起動できるサーバーではなく、ただのバイトの山です。
はい：インストーラーはデータディレクトリの内部に専用のデータベースを作成し、そこに復旧手順を書き込みます。生き残ったディスク 1 台と、 PostgreSQL とこのパッケージがあれば、別のマシンでサーバーを再構築できます。

はいと答える前に知っておくべき 2 つの代償があります。このデータベースディレクトリは、それを作成した PostgreSQL のメジャーバージョンでしか再オープンできないため、数年後の再構築ではそのバージョンを明示的にインストールする必要があるかもしれません。そしてそのディスクにはライセンスキー、JWT シークレット、データベースのパスワードも含まれることになります：秘密情報として扱ってください。この回答は後から sudo dpkg-reconfigure uversion-server で変更できます。

5. 回答：アクティベーションコード

必須です。ただし、マシン上またはステップ 3 で選んだディスク上にすでにライセンスがある場合は除きます：その場合、インストーラーは専用のメッセージでそのことを知らせ、質問しません。アクティベーションコードは 1 回限りの使用であり、あなたのコードはこのディスクの元となったマシンですでに消費されているからです。

この項目は 3 つの形式を受け付けます。これはマシンにインターネットがない場合の出口です：短いコード UV-XXXX-XXXX-XXXX、完全なライセンスキーを含むファイルへの絶対パス、または完全なキーを直接貼り付けたもの （eyJ で始まる長い文字列）。最初の形式のときだけ、インストーラーは licence.uversion.io に接続してコードを完全なキーと交換します。

6. 最後に表示される内容を控える

インストールは色付きの枠で終わります：admin のユーザー名、一時パスワード、サーバーアドレス、証明書のフィンガープリント。これらを控えてください：このパスワードを含むファイルは、変更するとすぐに削除されます。

インストール完了時に表示される概要：管理者ユーザー名、一時パスワード、サーバーアドレス。

続いて初回ログインに進めます。

中断されたインストールは安全に再開できます。 ウィンドウを閉じてしまった、ネットワークが切れた、あるいはインストーラーがエラーで止まった場合は、同じ apt install コマンドをもう一度実行するだけです。アクティベーションコードが再び 失われることはありません：一度交換されると、取得したキーがディスクに書き込まれ、以降の試行で再利用されます。そして、再インストールせずに任意の回答をあとから見直すには：sudo dpkg-reconfigure uversion-server。これはこのページ共通の万能なやり直しコマンドです。

インストーラーが受け入れるデータディレクトリを選ぶ

ルールは 4 つ。最初の 3 つはアクティベーションコードが消費される前に検証されるので、拒否されても損はありません：修正してやり直すだけです。

/home の下でも /root の下でもないこと。 サーバーは、個人ディレクトリへのアクセスを意図的に一切持たないシステムアカウントで動作します：そこでは読み書きが決してできず、起動もしません。
パスにスペースを含まないこと。 パスはそのままサービスの設定にコピーされますが、そこではスペースが 2 つの値を区切ります。/media/jean/My Book のような名前で自動マウントされた外付けディスクは、まさにこれに引っかかります。
絶対パスであること、つまり / で始まること。
各親ディレクトリが uversion と postgres のアカウントを通過させること。 これは最も分かりにくい罠で、root としてインストールするときには見えません：手作業で作られて閉じられた親ディレクトリ（たとえば Helix デポから引き継いだ root:root 0750 の /perforce）は、インストール全体を通過させたあと、最初のアクセスでサービスをブロックします。症状は、status=200/CHDIR で起動を拒否するサービス、または最初の書き込みでの "Permission denied" です。

この最後の点をインストール開始前に確認するには、選んだ場所に至るディレクトリチェーン全体の権限を表示します：

namei -l /srv/uversion        # remplacez par le chemin que vous voulez utiliser

各行の権限の最後の列（「その他」の列）に x が付いている必要があります。欠けている場合、インストーラーは問題のディレクトリと、実行すべき正確なコマンド（sudo chmod o+x /le/dossier のような形式）を示します。インストーラーが自分の所有していないディレクトリを自ら変更することは決してありません：あなたのツリーへのアクセスを開くのはあなたの判断であり、インストーラーの判断ではありません。

ファイルの保存先

場所は 2 つあり、データディレクトリを変更したときに付いてくるのはそのうち 1 つだけです。

データディレクトリ内（質問 1 のもの）：バージョン管理されたファイルの内容（data/chunks の下）、TLS 証明書とそのフィンガープリント（data/tls の下）、サーバーの識別情報（server-id、last-validated-at）、初期管理者パスワード（initial-admin-password、変更するとすぐに消去されます）、PostgreSQL データベース（pgdata）、そして質問 2 にはいと答えた場合は復旧キット（recovery）。

/etc/uversion/ 内、これは決して動きません：設定ファイル config.toml、ライセンスキーのそのままのコピー（licence-key）、データベースのパスワード（db-password）。

このページのすべてのコマンドは、ハードコードされたパスの代わりに <data-dir> を使います。そのパスはあなたが選んだものだからです。すでにインストール済みのマシンで実際の値を読み取るには：

sudo sed -n 's/^WorkingDirectory=//p' /etc/systemd/system/uversion-server.service.d/10-data-dir.conf

インストールを確認

独立した 3 つのチェックを、この順で実行します：サービスが動いている、リッスンしている、そして何も報告していない。

1. サービスが動いている

systemctl status uversion-server

期待される結果：active (running)。それ以外の値ならトラブルシューティングへ。

2. サーバーが 8443 で HTTPS をリッスンしている

ss -tlnp | grep 8443

1 行が表示されるはずです。サービスが動いているのに何も出力されない場合、たいていは設定で TLS が無効化されています：その場合サーバーは素の HTTP に切り替わり、8443 はまったくリッスンしなくなります。

3. ログにエラーがない

sudo journalctl -u uversion-server -n 50

journalctl はシステムのログリーダーです：サーバーが何をしているかを書き込む場所であり、何かが起動しないときに最初に見るべき場所です。

証明書のフィンガープリントを再表示

<data-dir> を上で読み取った値に置き換えて：

sudo cat <data-dir>/data/tls/fingerprint

初期管理者パスワードを再表示

変更されていない限り、まだディスク上にあります：

sudo cat <data-dir>/initial-admin-password

ここで "No such file or directory" と出るのは、パスワードがすでに変更されたことを意味します：これは期待される動作で、そのときにファイルは削除されます。

非対話・オフラインのインストール

異なる 2 つのニーズ、同じ 1 つの仕組み：apt を実行する前に回答をあらかじめ入力しておき、質問が一切表示されないようにします。これらの回答を保存する仕組みは debconf と呼ばれ、コマンドラインから操作します。

1. 3 つの回答をあらかじめ入力

質問ごとに 1 行、対話式インストールとまったく同じ 3 つです：

echo 'uversion-server uversion-server/data-dir string /srv/uversion' | sudo debconf-set-selections
echo 'uversion-server uversion-server/db-on-data-dir boolean true'   | sudo debconf-set-selections
echo 'uversion-server uversion-server/licence-key string UV-XXXX-XXXX-XXXX' | sudo debconf-set-selections

2. ダイアログなしでインストール

回答がすでにそろっているので、インストールは何も尋ねません：

sudo DEBIAN_FRONTEND=noninteractive apt install -y ./uversion-server_latest_amd64.deb

オフラインの変種：コードの代わりにキーを渡す

インターネットにアクセスできないネットワークでは、アクティベーションコードを交換できません：連絡できる相手がいないからです。その場合は、接続された端末のアカウントページから完全なライセンスキーを取得してマシンに置き、上のステップ 1 でコードの代わりにファイルのパスを渡します。これが唯一の出口であり、そのために用意されています：

echo 'uversion-server uversion-server/licence-key string /root/uversion-licence.key' | sudo debconf-set-selections

ファイルにはキーだけを、1 行で、引用符やその他の内容を付けずに含める必要があります。誤って config.toml 全体を指定するとはっきりと拒否されます。ファイルを置きたくない場合の 3 つ目の形式：パスの代わりに、完全なキーを値に直接貼り付けます。

リスクのある操作の前にバックアップする

コピーすべきものは 3 つあり、それぞれバックアップの仕方が異なります：データベース （アカウント、リビジョン、ロック、権限）、データディレクトリ（ファイルの内容）、そして別の場所にあり忘れられがちな設定です。

1. データベース

バックアップは postgres アカウントで行い、root では決して行いません： PostgreSQL には root という名前の「ロール」（データベースアカウントを指す PostgreSQL の用語）がないため、root で直接実行したコマンドは、実際には識別情報の問題なのに障害のように見えるメッセージで失敗します。

データベースに関する質問にいいえ（デフォルト）と答えた場合、それはシステムクラスタにあります：

sudo -u postgres pg_dump -Fc uversion > /tmp/uversion.dump

はいと答えた場合、それは別のクラスタにあり、明示的に指定しないと間違ったほうをバックアップしてしまいます：

pg_lsclusters                                    # repere la ligne "uversion" et sa version
sudo -u postgres pg_dump --cluster <major>/uversion -Fc uversion > /tmp/uversion.dump

2. データディレクトリ

一貫したコピーのために、サービスを停止して：

sudo systemctl stop uversion-server
sudo tar czf /tmp/uversion-data.tar.gz -C <data-dir> .
sudo systemctl start uversion-server

3. 設定

/etc/uversion/ はデータディレクトリに付いてこず、データベースにも含まれません：ライセンスキー、セッションに署名するシークレット、データベースのパスワードを保持しています。これがないと、新しいマシンでの復元は新しいシークレットで始まるため、チーム全員が一度に切断され、ライセンスを再度申請する必要があります。

sudo tar czf /tmp/uversion-etc.tar.gz -C /etc uversion

アンインストール

注意： これらのコマンドはリポジトリ、履歴、ユーザーアカウント、設定を削除します。あとで元に戻せるようにしたい場合は、まず前のセクションのバックアップを取ってください。

1. パッケージをパージ

パージはバイナリ、サービス、設定の回答、/etc/uversion/、システムアカウント uversion を削除します。データベースとデータディレクトリは意図的に保持します：これらはあなたのファイルであり、パッケージマネージャーが黙って消すことはありません。

sudo systemctl stop uversion-server 2>/dev/null
sudo apt purge -y uversion-server

このアンインストールのあとに sudo apt autoremove --purge を実行しないでください。 PostgreSQL はこのパッケージの依存関係として入ったため、apt はそれを削除しようと提案します。そして PostgreSQL 自身のパージは、uVersion とは無関係のものも含め、マシン上のすべてのデータベースを消去します。パッケージはインストール時にガードを設けますが、このコマンドは避けるべきものです。

2. パージが表示したばかりの手順に従う

データベースとデータディレクトリはまだ残っており、それらを削除するコマンドはあなたのマシンによって異なります：だからこそ、ここに書くのではなく、計算して画面に表示されます。

パージが表示する内容を読んでください：この先はあなたのマシンによって異なります。 アンインストールスクリプトはデータベースが実際にどこにあるかを調べ、パスやバージョン番号を含め、あなたのケースに正確に合ったコマンド手順を画面に表示します。汎用のレシピではなくそれに従ってください：いいかげんなコマンドは、間違ったデータベースを破壊するか、まったく何もしないかのどちらかです。

この手順が避ける 2 つの落とし穴があり、それがガイドからコピーするのではなくあなたのために計算される理由です：

クラスタを指定しない DROP DATABASE は、間違ったデータベースサーバーを対象にします。 データベースに関する質問にはいと答えた場合、あなたのものは専用のクラスタにあります：デフォルトのコマンドはシステムクラスタに対して実行され、削除するものが見つからず、完了したと思い込ませます。
先にクラスタを削除せずにデータディレクトリを rm -rf すると、システムに宣言されたままの幽霊データベースが残り、存在しないディレクトリを要求してマシンの起動のたびに失敗します。順序が重要です：pg_dropcluster --stop、そのあとに ディレクトリを削除します。

3. 復旧キットを削除

ディスクが手元を離れる場合（転売、リース返却、廃棄）に行います：このディレクトリには ライセンスキー、JWT シークレット、データベースのパスワードが含まれており、構造上パージ後も残ります。

sudo rm -rf <data-dir>/recovery

4. システムアカウントが消えていることを確認

通常はパージによってすでに削除されています。すでに消えている場合、このコマンドは何もしません：

sudo deluser --system uversion 2>/dev/null || true

5. 何も残っていないことを確認

4 つのチェック。それぞれ、横に表示されるはずの内容を添えています：

systemctl status uversion-server         # "not-found" ou "inactive"
ls /etc/uversion 2>&1                    # "No such file"
id uversion                              # "no such user"
sudo -u postgres psql -tAc "SELECT 1 FROM pg_database WHERE datname='uversion';"   # (vide)