コンテンツにスキップ

digna リリース 2026.06 の Linux インストールガイド

リリース: 2026.06

最終更新: 2026年9月5日


目次

  1. はじめに
  2. システム要件
  3. 事前準備
  4. PostgreSQL サーバーのセットアップ
  5. Web サーバーの構成
  6. 初回インストール
  7. バックエンドの設定
  8. ダッシュボードの設定
  9. digna を systemd サービスとして実行する
  10. 新しいリリースへのアップグレード

はじめに

digna について

digna は、ウェアハウス、データレイク、レイクハウスなど様々なデータ環境におけるデータ品質管理を最適化するために設計された包括的な AI 駆動プラットフォームです。高いスケーラビリティと適応性を備え、自動化、リアルタイム監視、および異常検知を通じて現代のデータ課題に対処します。

digna は主に次の2つのコンポーネントで構成されています:

  • digna: アプリケーションの中核であり、データの処理と品質チェックの実行を担います。バックエンドとコマンドラインインターフェイスを単一の実行ファイルに統合し、以前のリリースで別々だった dignabackend と dignacli を置き換えます。
  • dignadashboard: Web サーバー上でホストされる、digna プラットフォームとやり取りしデータ品質指標を可視化するための Web ベースのインターフェース

リリース 2026.06 の新機能

このリリースでは、データオブザーバビリティ機能をコードの中に直接取り込み、開発者がデータ品質をソースで監視できるようになりました。詳細は release notes を参照してください。

Windows や macOS をお探しですか?

本ガイドは Linux 向けです。他のプラットフォームについては、Windows インストールガイド または macOS インストールガイド を参照してください。

本ガイドはどのディストリビューション向けですか?

手順は、最も一般的なサーバーファミリ 2 種に対して書かれています。両者で差がある場合は両方のコマンドを記載しています:

  • Debian 系 — Debian、Ubuntu。パッケージマネージャ: apt
  • RHEL 系 — Red Hat Enterprise Linux、Rocky Linux、AlmaLinux、Fedora。パッケージマネージャ: dnf

systemd を採用している現代的なディストリビューションであれば動作します。変更されるのはパッケージ名と一部の設定パスだけです。


システム要件

インストールを開始する前に、システムが次の最小要件を満たしていることを確認してください:

要件 仕様
オペレーティングシステム Ubuntu 22.04 LTS 以降、Debian 12 以降、RHEL 9 / Rocky 9 / AlmaLinux 9 以降
アーキテクチャ x86_64 (amd64) または arm64
Init システム systemd
メモリ(最小構成) 16 GB RAM
ディスク容量 10 GB の空きストレージ
データベース PostgreSQL Server 12 以降
Web サーバー nginx、Apache httpd、または同等のもの

データベースのインストール オプション

PostgreSQL が既にインストールされている場合: 既存の PostgreSQL サーバーに対して digna 用の新しいデータベースを追加できます。

digna と同じマシンに PostgreSQL をインストールする場合:

推奨仕様

  • メモリ: 32 GB RAM(16 GB の代わりに)
  • ディスク容量: 50 GB の空きストレージ(10 GB の代わりに)

これらの高めの仕様は、digna と PostgreSQL データベースが同一マシン上で同時に動作することを想定したものです。

ディストリビューションとアーキテクチャの確認

本ガイドのいくつかのコマンドは Debian 系と RHEL 系で異なります。どちらを使用しているかを確認するには、次を実行してください:

cat /etc/os-release
uname -m
  • ID=ubuntu または ID=debian — apt コマンドを使用
  • ID=rhel、rocky、almalinux または fedora — dnf コマンドを使用
  • x86_64 または aarch64 — 必要なインストールパッケージのアーキテクチャ

事前準備

digna をインストールする前に、次の 2 つの主要な前提条件が整っていることを確認してください:

  1. PostgreSQL サーバー – 計算されたメトリクスやパフォーマンスデータを格納するため
  2. Web サーバー – digna Dashboard をホストするため

これらのコンポーネントがまだセットアップされていない場合は、以下のセクションに従ってインストールと構成を行ってください。

パッケージインデックスの更新

何かをインストールする前にパッケージリストを更新してください:

sudo apt update
sudo dnf check-update

注意

本ガイド全体で、2 行並んだコマンドの最初の行は Debian 系、2 行目は RHEL 系 向けです。ご自身の環境に合う方だけを実行してください。


PostgreSQL サーバーのセットアップ

既に PostgreSQL をお持ちの場合

PostgreSQL がローカルで既にインストール済みで稼働している場合、またはマネージドなリモート PostgreSQL サーバーを使用している場合は、次のセクションに進んでください。

PostgreSQL のインストール

ステップ 1: サーバーパッケージのインストール

sudo apt install -y postgresql postgresql-contrib
sudo dnf install -y postgresql-server postgresql-contrib

ヒント

ディストリビューションのパッケージは最新の PostgreSQL リリースに追従していないことがあります。特定の新しいバージョンが必要な場合は、公式の PostgreSQL apt または yum リポジトリ を使用してください。

ステップ 2: データベースクラスタの初期化

Debian 系では、パッケージが自動的にクラスタを作成して起動します — 次のステップへ進んでください。

RHEL 系では、クラスタを明示的に作成する必要があります:

sudo postgresql-setup --initdb

ステップ 3: サービスの起動と有効化

sudo systemctl enable --now postgresql

これにより PostgreSQL が直ちに起動し、ブート時に自動的に再起動するよう設定されます。

ステップ 4: インストールの確認

psql --version
sudo systemctl status postgresql

PostgreSQL のバージョンと active (running) のサービスが表示されるはずです。

ステップ 5: サーバーへの接続

Linux の PostgreSQL パッケージは、クラスタを所有する postgres システムアカウントを作成します。次のようにして接続します:

sudo -u postgres psql

注意 — ここは Windows と異なります

Windows のインストーラーはセットアップ中に postgres スーパーユーザーのパスワードを設定するよう促します。Linux パッケージではそうではありません。代わりに、ローカル接続は peer authentication で認証されます: postgres OS ユーザーはパスワードなしで postgres データベースユーザーとして接続できます。

これが上記コマンドに sudo -u postgres を使う理由です。digna バックエンドは TCP 経由でユーザー名とパスワードで接続するため、初回インストール で明示的な digna ユーザーを作成します。

ステップ 6: ポートの確認

デフォルトの PostgreSQL ポートは 5432 です。サーバーがどのポートで待ち受けているか確認するには:

sudo -u postgres psql -c "SHOW port;"

値を控えておいてください — digna バックエンドの設定時に必要です。

ステップ 7: digna ユーザーのためのパスワード認証を有効にする

digna は digna_user として TCP 経由で PostgreSQL に接続します。これは peer 認証ではなくパスワード認証が必要です。pg_hba.conf がそれを許可しているか確認してください。

ファイルの場所を確認するには:

sudo -u postgres psql -c "SHOW hba_file;"

エディタで開き、ローカル TCP 行が ident ではなく scram-sha-256(古いサーバーでは md5)を使用していることを確認します:

# TYPE  DATABASE  USER  ADDRESS         METHOD
host    all       all   127.0.0.1/32    scram-sha-256
host    all       all   ::1/128         scram-sha-256

変更を行ったら PostgreSQL をリロードしてください:

sudo systemctl reload postgresql

重要

digna が FATAL: Ident authentication failed for user "digna_user" を報告する場合、この設定が原因です。

ステップ 8: PostgreSQL が別マシンで動作している場合

異なるホストからの接続を受け入れるには、postgresql.conf の listen_addresses を設定し、pg_hba.conf にネットワークに一致する host 行を追加します:

listen_addresses = '*'

その後ファイアウォールでポートを開け、サービスを再起動します:

sudo ufw allow 5432/tcp
sudo firewall-cmd --permanent --add-port=5432/tcp && sudo firewall-cmd --reload
sudo systemctl restart postgresql


Web サーバーの構成

digna はダッシュボードをホストするために Web サーバーを必要とします。次のオプションのいずれかを選択してください:

これらのうち いずれか一つ をインストールして構成すれば十分です。

両セクションともダッシュボードが依存する次の 2 つを構成します:

  • シングルページアプリケーションのフォールバック — ダッシュボードの URL をリロードしても 404 が返らないようにする
  • .md の MIME タイプ — Markdown ファイルを正しく配信するため

nginx のセットアップ

概要

nginx は静的な digna ダッシュボードの配信に適した軽量で高性能な Web サーバーです。

インストール

sudo apt install -y nginx
sudo dnf install -y nginx

nginx の起動

sudo systemctl enable --now nginx

インストールの確認

  1. ブラウザを開く
  2. http://localhost にアクセス
  3. nginx のウェルカムページが表示されるはずです

ファイアウォールの開放

サーバーが他のマシンから到達される場合、HTTP トラフィックを許可します:

sudo ufw allow 'Nginx Full'
sudo firewall-cmd --permanent --add-service=http && sudo firewall-cmd --reload

ダッシュボード用のサイトを構成する

nginx は両ディストリビューションファミリで conf.d ディレクトリ内のすべてのファイルを読み込みます。digna 用の専用設定ファイルを作成してください:

sudo nano /etc/nginx/conf.d/digna.conf

抽出した dashboard フォルダの実際のパスにある /opt/digna/dashboard を置き換えながら、以下を貼り付けてください:

server {
    listen       80 default_server;
    listen       [::]:80 default_server;
    server_name  _;

    root   /opt/digna/dashboard;
    index  index.html;

    # Serve Markdown files with the correct MIME type.
    types {
        text/markdown  md;
    }

    # Single-page-application fallback: unknown paths return index.html
    # instead of a 404, so dashboard routes survive a browser refresh.
    location / {
        try_files $uri $uri/ /index.html;
    }
}

重要

try_files ディレクティブがないと、ルート URL 以外のダッシュボードページをリロードすると 404 が返されます。これは Windows の IIS で必要な URL Rewrite モジュールに相当する nginx の設定です。

デフォルトサイトを無効化する

同じポートで default_server であるサーバーブロックは 1 つだけにできます。Debian 系では、パッケージ付属のデフォルトを削除して競合を避けてください:

sudo rm /etc/nginx/sites-enabled/default

RHEL 系では、/etc/nginx/nginx.conf 内の server { ... } ブロックをコメントアウトするか削除してください。

設定を反映する

構文エラーがないかテストし、nginx をリロードします:

sudo nginx -t
sudo systemctl reload nginx

Apache httpd のセットアップ

概要

Apache httpd はサポートされるすべてのディストリビューションのデフォルトリポジトリで利用可能です。パッケージ名は Debian 系では apache2、RHEL 系では httpd です。

インストール

sudo apt install -y apache2
sudo dnf install -y httpd

Apache の起動

sudo systemctl enable --now apache2
sudo systemctl enable --now httpd

インストールの確認

  1. ブラウザを開く
  2. http://localhost にアクセス
  3. ディストリビューションのデフォルトの Apache ページが表示されるはずです

必須: mod_rewrite を有効にする

ダッシュボードは URL 書き換えを必要とします。

Debian 系ではモジュールを有効化して再起動します:

sudo a2enmod rewrite
sudo systemctl restart apache2

RHEL 系では mod_rewrite はデフォルトで読み込まれています。確認するには:

httpd -M | grep rewrite

必須: .htaccess の許可を有効にする

ドキュメントルートの設定ファイルを開きます:

sudo nano /etc/apache2/apache2.conf
sudo nano /etc/httpd/conf/httpd.conf

ドキュメントルートをカバーする <Directory> ブロック(両ファミリとも /var/www/html)を見つけ、次のように変更します:

AllowOverride None

を:

AllowOverride All

必須: Markdown ファイルの MIME タイプ

同じファイルに次の行を追加して、Markdown ファイルが正しく配信されるようにします:

AddType text/markdown .md

重要

この設定がないと、.md ファイルが正しく配信されない可能性があります。

設定を反映する

構成の構文をチェックし、Apache を再起動します:

sudo apachectl configtest
sudo systemctl restart apache2
sudo apachectl configtest
sudo systemctl restart httpd


初回インストール

ステップ 1: digna リポジトリのセットアップ

digna リポジトリは、digna が計算するすべてのメトリクスを格納します。分析およびパフォーマンスデータの中央データベースとして機能します。

リポジトリ用のスキーマとユーザーを作成する

PostgreSQL クライアント(psql、pgAdmin など)を開き、以下の SQL コマンドを実行してください:

CREATE SCHEMA <digna_repo_schema>;

CREATE USER <digna_repo_user> WITH PASSWORD '<digna_repo_password>';

GRANT ALL PRIVILEGES ON SCHEMA <digna_repo_schema> TO <digna_repo_user>;

以下のプレースホルダーを置き換えてください:

  • <digna_repo_schema> — 希望するスキーマ名(例: dignarepo)
  • <digna_repo_user> — 希望するユーザー名(例: digna_user)
  • <digna_repo_password> — このユーザーのための安全なパスワード

例:

CREATE SCHEMA dignarepo;

CREATE USER digna_user WITH PASSWORD 'YourSecurePassword123!';

GRANT ALL PRIVILEGES ON SCHEMA dignarepo TO digna_user;

シェルから一度に実行するには:

sudo -u postgres psql

その後 postgres=# プロンプトに文を貼り付け、終了するには \q と入力してください。

ベストプラクティス

データベースユーザーには強力で複雑なパスワードを使用してください。簡単に推測される認証情報は避けてください。


ステップ 2: digna インストールパッケージを展開する

  1. 提供された digna インストール ZIP ファイルを見つけます
  2. 希望するインストール先(例: /opt/digna)に展開します
  3. 展開後、次の項目が存在するはずです:
  4. dashboard/ — Web ダッシュボードインターフェース
  5. digna — メイン実行ファイル(バックエンド + CLI 統合)

設定ファイルとライセンスファイルはパッケージに含まれていません

config.toml も dashboard/dashboard_config.toml もインストールパッケージには含まれていません。どちらも バックエンドの設定 と ダッシュボードの設定 でご自身で作成します。license.toml も同梱されていません。ステップ 3 で説明するとおり、digna から別途提供されます。

シェルから展開するには:

sudo mkdir -p /opt/digna
sudo unzip digna-2026.06-linux-x86_64.zip -d /opt/digna

注意

unzip がインストールされていない場合は、sudo apt install -y unzip または sudo dnf install -y unzip で追加してください。

実行ファイルに実行権を付与する

アーカイブの転送方法によっては実行ビットが失われることがあります。明示的に設定してください:

cd /opt/digna
sudo chmod +x digna

サービスアカウントを作成する

本番環境では、バックエンドを専用の特権のないユーザーで実行することを推奨します:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin digna
sudo chown -R digna:digna /opt/digna

注意

RHEL 系では同等のシェルパスは /sbin/nologin です。

ステップ 3: ライセンスファイルのインストール

重要

ライセンスファイルはインストールパッケージに含まれておらず、digna から別途提供されます。

  1. 提供された license.toml ファイルを見つけます
  2. それを digna のインストールルートディレクトリ(config.toml と digna 実行ファイルがある場所)にコピーします

なぜ重要か: ライセンスファイルには顧客情報、ライセンスの有効期限、デジタル署名が含まれています。このファイルを変更しないでください — 変更すると無効になります。

セットアップ後のディレクトリ構成:

/opt/digna/
├── config.toml         (configuration file)
├── license.toml        (YOUR LICENSE FILE - copy here)
├── digna               (main executable)
├── bin/                (service management scripts)
└── dashboard/          (web interface)
    └── (dashboard files)

バックエンドの設定

ステップ 1: 設定ファイルを作成・編集する

config_template.toml ファイルが digna インストールディレクトリに含まれています。これを config.toml にリネームするだけです。

cd /opt/digna
sudo mv config_template.toml config.toml

場所: /opt/digna/config.toml

テキストエディタで config.toml を開き、以下の各セクションを設定してください。

[app] セクション

このセクションは digna バックエンドのアプリ設定を構成します:

[app]
digna_APP_CORS_ALLOW_ORIGINS = ["http://localhost:5173"]
digna_APP_CORS_ALLOW_CREDENTIALS = true
digna_APP_CORS_ALLOW_METHODS = ["*"]
digna_APP_CORS_ALLOW_HEADERS = ["*"]
パラメーター 値 注意
digna_APP_CORS_ALLOW_ORIGINS フロントエンドの URL ダッシュボードが別サーバーの場合、その URL を含める
digna_APP_CORS_ALLOW_CREDENTIALS true 認証付き CORS に必要
digna_APP_CORS_ALLOW_METHODS ["*"] すべての HTTP メソッドを許可
digna_APP_CORS_ALLOW_HEADERS ["*"] すべてのヘッダを許可

注意

ダッシュボードをデフォルトの HTTP ポートで nginx や Apache から提供している場合、許可するオリジンは http://localhost です — またはダッシュボードが他のマシンから到達される場合はサーバーの公開 URL を指定してください。

[repo] セクション

このセクションは PostgreSQL データベースへの接続を構成します:

[repo]
digna_REPO_HOST = "localhost"
digna_REPO_PORT = 5432
digna_REPO_DB = "postgres"
digna_REPO_SCHEMA = "dignarepo"
digna_REPO_USER = "digna_user"
digna_REPO_PASSWORD = "YourSecurePassword123!"
パラメーター 値 注意
digna_REPO_HOST localhost または IP PostgreSQL サーバーのホスト名/IP
digna_REPO_PORT 5432 (デフォルト) PostgreSQL のポート
digna_REPO_DB postgres データベース名
digna_REPO_SCHEMA dignarepo 先に作成したスキーマ
digna_REPO_USER digna_user PostgreSQL セットアップで作成したユーザー
digna_REPO_PASSWORD ご自身のパスワード スキーマ作成時に設定したパスワード

ベストプラクティス

config.toml はプレーンテキストでデータベースパスワードを含みます。サービスアカウントのみが読めるように権限を制限してください:

sudo chown digna:digna /opt/digna/config.toml
sudo chmod 600 /opt/digna/config.toml

[base] セクション

このセクションにはセキュリティとクッキーの設定が含まれます:

[base]
DIGNA_FERNET_KEY = "DU4a0yJ-OqvbKCL4hNQn_CsknH-V1vWmHZqBUl-AY44="
digna_COOKIE_DOMAIN = "localhost"
digna_COOKIE_PATH = "/"
digna_COOKIE_SECURE = false
digna_COOKIE_HTTPONLY = true
digna_COOKIE_SAME_SITE = "lax"
digna_TOKEN_EXPIRES_IN = 86400
digna_MAX_WORKERS = 4
DIGNA_SCHEDULER_MAX_DELAY = 100
DIGNA_CLEANUP_TIME = "12:00"
パラメーター 値 注意
DIGNA_FERNET_KEY 暗号化キー トークンやクッキーの暗号化に使用(デフォルトが提供される)
digna_COOKIE_DOMAIN localhost フロントエンドのドメインに合わせる
digna_COOKIE_SECURE false(ローカル) / true(本番) HTTPS 接続では true を使用
digna_COOKIE_HTTPONLY true セキュリティのため常に有効推奨
digna_COOKIE_SAME_SITE lax CSRF 攻撃を防止
digna_TOKEN_EXPIRES_IN 86400(24 時間) セッションのタイムアウト(秒)
digna_MAX_WORKERS CPU コア数 - 1 同時並列検査タスクの数
DIGNA_SCHEDULER_MAX_DELAY 100 スケジューラーが実行予定のジョブを開始する前に追加できる最大の遅延(秒)
DIGNA_CLEANUP_TIME "12:00" 日次クリーンアップが開始される時刻(24 時間表記 HH:MM)

ヒント

サーバー上の CPU コア数を確認するには nproc を実行してください。

[encryption] セクション

このセクションには、リポジトリに保存された機密値を暗号化するための鍵が含まれます。必須です。鍵が欠けている場合、config check は [encryption] セクションを FAILED として報告します。

[encryption]
DIGNA_ENCRYPTION_KEY = 'ycELf6IbcO55dYIZHpPv6kQv/bbnUXoIaHLh2bh1kMg='
パラメーター 値 注意
DIGNA_ENCRYPTION_KEY Base64 エンコードされた鍵 digna リポジトリに保存された機密値を暗号化します

config.toml を保護する

この鍵は固定値で、すべての digna インストールで同一であり、リポジトリ内の機密値を復号するのはこの鍵です。config.toml へのアクセスを digna を実行するアカウントに限定し、バージョン管理や共有ドライブには置かず、リポジトリ本体より安全性の低い場所に保管されるバックアップからは除外してください。

[logging] セクション

このセクションはログ動作を設定します:

[logging]
digna_LOGGING_MODE = "INFO"
digna_LOGGING_BACKUP_COUNT = 10
パラメーター 値 注意
digna_LOGGING_MODE INFO または DEBUG 本番は INFO、トラブルシューティング時は DEBUG
digna_LOGGING_BACKUP_COUNT 10 保持する日次ログバックアップの数

ステップ 2: 構成を検証する

リポジトリを初期化する前に、config.toml が完全で正しく構成されていることを確認します。digna のインストールディレクトリで次を実行します:

digna config check

各セクションは個別に検証されるため、1 つの誤りが他のセクションの状態を隠すことはありません:

Configuration validation report (source: config.toml):
 - App config: OK
 - Repository config: OK
 - Base config: OK
 - Logging config: OK
 - Encryption config: OK
 - OIDC config(s): OK

Overall: OK

FAILED と報告された箇所をすべて修正し、続行する前にコマンドを再実行してください。オプションの完全な一覧は CLI リファレンスにあります。

ステップ 3: リポジトリの初期化

  1. ターミナルを開く
  2. digna のインストールディレクトリ(config.toml と digna 実行ファイルがある場所)に移動
  3. 接続テストを実行:
cd /opt/digna
./digna repo check

接続が確立されたことを確認するメッセージが表示されるはずです(リポジトリ自体はまだ初期化されていません)。

注意

Linux ではカレントディレクトリは PATH に含まれていないため、実行ファイルは ./digna として呼び出します。どこでも短い形式を使いたい場合は、シンボリックリンクを追加してください:

sudo ln -s /opt/digna/digna /usr/local/bin/digna

ステップ 4: リポジトリスキーマのインストール

同じディレクトリで次を実行します:

./digna repo install

このコマンドは PostgreSQL データベースに必要なテーブルとスキーマをインストールします。

ステップ 5: 管理者ユーザーの作成

  1. 新しいターミナルウィンドウを開く
  2. digna のインストールディレクトリに移動
  3. 次のコマンドで管理者ユーザーを作成します:
./digna user add <email> <password> "<display_name>" --admin

例:

./digna user add admin@example.com 'AdminPassword123!' "Admin User" --admin

これにより、メールアドレス admin@example.com の管理者権限を持つユーザーが作成されます。

ヒント

パスワードはシングルクォートで囲んでください。bash や zsh は !、$、* などの文字を特別扱いするため、引用符なしだと正しく渡らないことがあります。

ベストプラクティス

大文字・小文字・数字・特殊文字を混ぜた強力なパスワードを使用してください。


ステップ 6: digna サーバーの起動

digna インストールディレクトリでサーバーを起動します:

./digna serve --address <host> --port <port>

パラメーター: - --address — サーバーのホスト名/IP - --port — サーバーのポート

次のような起動メッセージが表示され、サーバーが実行中であることを確認できます:

INFO:     Started server process [1234]
INFO:     Waiting for application startup.
INFO:     Application startup complete
INFO:     Uvicorn running on http://localhost:8082

ヒント

ダッシュボードがバックエンドと別マシンで提供されている場合、API ポートもファイアウォールで開放してください:

sudo ufw allow 8082/tcp
sudo firewall-cmd --permanent --add-port=8082/tcp && sudo firewall-cmd --reload

サーバーはターミナルを占有します

serve はフォアグラウンドで実行され、Ctrl+C で停止するまで動作し続けます。セットアップを終えるまで実行したままにしてください。起動時に自動的に開始する方法は次を参照してください: digna を systemd サービスとして実行する.

ダッシュボードの設定

ステップ 1: ダッシュボードを Web サーバーにデプロイする

digna ダッシュボードは独自の設定を dashboard/dashboard_config.toml から読み込みます。このファイルはインストールパッケージに含まれていないため、dashboard/ ディレクトリ内にダッシュボードのファイルと並べて作成します。

その内容は シングルサインオン で説明しています。このファイルが必要になるのもそこです。このファイルには、ダッシュボードが提供するログイン方法と、マルチインスタンス構成の場合はバックエンドへの接続先が記述されます。

利用する Web サーバーを選び、該当するデプロイ手順に従ってください。

nginx にデプロイする場合

nginx のセットアップ に従った場合、サーバーブロックはすでに dashboard フォルダを指しているのでコピーは不要です。

  1. パスを確認
  2. /etc/nginx/conf.d/digna.conf を開く
  3. root が展開した dashboard フォルダを指しているか確認

  4. フォルダが読み取り可能であることを確認

    sudo chmod -R a+rX /opt/digna/dashboard
    

  5. nginx をリロード

    sudo nginx -t
    sudo systemctl reload nginx
    

  6. インストールのテスト

  7. ブラウザを開く
  8. http://localhost(または設定した URL)にアクセス
  9. digna ダッシュボードのログインページが表示されるはずです

Apache httpd にデプロイする場合

  1. ダッシュボードをドキュメントルートにコピー

    sudo cp -R /opt/digna/dashboard /var/www/html/digna
    

  2. リライトルールの追加

ブラウザリロード時にダッシュボードのルートが生きるよう、デプロイ先フォルダに .htaccess ファイルを作成します:

sudo nano /var/www/html/digna/.htaccess

以下を貼り付けてください:

RewriteEngine On
RewriteBase /digna/

# Serve existing files and directories as-is.
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]

# Everything else falls back to the single-page application entry point.
RewriteRule ^ index.html [L]
  1. Apache を再起動

    sudo systemctl restart apache2
    
    sudo systemctl restart httpd
    

  2. ダッシュボードにアクセス

  3. ブラウザを開く
  4. http://localhost/digna にアクセス
  5. digna ダッシュボードのログインページが表示されるはずです

ステップ 2: SELinux (RHEL 系のみ)

RHEL、Rocky、AlmaLinux、Fedora では SELinux がデフォルトで enforcing になっており、Web サーバーが想定外の場所にあるファイルを読めないようブロックすることがあります。以下でアクティブか確認してください:

getenforce

結果が Enforcing で、ダッシュボードを /opt/digna/dashboard から配信している場合、Web サーバーが読み取れるようディレクトリにラベルを付けてください:

sudo semanage fcontext -a -t httpd_sys_content_t "/opt/digna/dashboard(/.*)?"
sudo restorecon -Rv /opt/digna/dashboard

注意

semanage が見つからない場合は、sudo dnf install -y policycoreutils-python-utils でインストールしてください。

重要

新規に構成した RHEL サーバーでダッシュボードが 403 Forbidden を返す場合、多くはファイル権限の問題ではなく SELinux のラベリング問題です。sudo ausearch -m avc -ts recent で確認してください。


digna を systemd サービスとして実行する

なぜ digna をサービスとして実行するのか?

digna バックエンドを systemd サービスとして実行すると次のメリットがあります:

  • マシン起動時に自動で開始される
  • ターミナルを開いておく必要なくバックグラウンドで実行される
  • 障害発生時に自動で再起動される
  • 標準の Linux サービス管理ツールである systemctl で管理できる

サービス管理ファイル

必要なファイルはすべて digna インストールディレクトリの bin/ にあります。

利用可能なシェルスクリプトは次の通りです:

  • install_service.sh — digna を systemd に登録
  • uninstall_service.sh — サービスを登録解除
  • start_service.sh — 登録済みサービスを起動
  • stop_service.sh — 実行中のサービスを停止

ルート権限が必要

サービスは起動時に読み込まれるユニットファイルを /etc/systemd/system に書き込むため、すべてのスクリプトは sudo で実行する必要があります。

スクリプトに実行権を付与する

展開によって実行ビットが保持されないことがあります。初回使用前に:

cd /opt/digna/bin
sudo chmod +x *.sh

サービスのインストール

  1. ターミナルを開く

  2. bin フォルダに移動

    cd /opt/digna/bin
    

  3. インストールスクリプトを実行

    sudo ./install_service.sh
    

digna サーバーは systemd に登録され、自動起動が有効になります。サービスは直ちに開始されません — 起動方法は次のセクションを参照してください。

サービスの起動と停止

サービスを開始するには

  1. ターミナルを開く
  2. /opt/digna/bin に移動
  3. 次を実行:
    sudo ./start_service.sh
    

サービスを停止するには

  1. ターミナルを開く
  2. /opt/digna/bin に移動
  3. 次を実行:
    sudo ./stop_service.sh
    

ヒント

アプリケーションファイルを更新する前は、必ずサービスを停止してください。

systemctl でのサービス管理

登録後は、任意のディレクトリから標準の systemd コマンドでサービスを管理できます:

sudo systemctl start digna
sudo systemctl stop digna
sudo systemctl restart digna
sudo systemctl status digna

サービスの確認

サービスが登録され、実行中であることを確認するには:

systemctl is-enabled digna
systemctl is-active digna

enabled はブート時に開始されることを意味し、active は現在実行中であることを意味します。

サービスログの表示

systemd はバックエンドがコンソールに出力する内容をすべてキャプチャします。ログを読むには:

sudo journalctl -u digna -n 100

問題を再現しながらログをリアルタイムで追うには:

sudo journalctl -u digna -f

ヒント

サービスが起動してすぐ停止する問題を診断する最速の方法はこれです。リポジトリ接続失敗や license.toml の欠如はここに記録されます。

インストール先を移動する場合

ユニットファイルには実行ファイルへの絶対パスが格納されるため、インストールを移動するにはサービスを再登録する必要があります:

  1. 現在のサービスをアンインストール

    cd /old/path/digna/bin
    sudo ./uninstall_service.sh
    

  2. アプリケーションファイルを移動

    sudo mv /old/path/digna /new/path/digna
    

  3. サービスを再インストール

    cd /new/path/digna/bin
    sudo ./install_service.sh
    

  4. サービスを開始

    sudo ./start_service.sh
    

サービスのアンインストール

  1. 実行中のサービスを停止

    cd /opt/digna/bin
    sudo ./stop_service.sh
    

  2. サービスをアンインストール

    sudo ./uninstall_service.sh
    

これで digna サーバーは systemd から登録解除されます。


新しいリリースへのアップグレード

アップグレード前に

最初にすべてのデータベース接続を確認する

リリース 2026.06 から、digna はすべてのソース技術に ODBC 経由で接続します。以前のリリースでは、技術ごとの専用ドライバーと ODBC を Use ODBC スイッチで選択できました。digna チームは ODBC のみを基盤とすることを決めました。単一の標準インターフェイスは、個別に作り込まれたドライバー群よりも多くをもたらすからです:

  • 認証 — 認証は ODBC の一部であるため、接続はドライバーが対応するあらゆる方式を利用できます。パスワード、トークンと PAT、Kerberos と Active Directory、MFA とブラウザーベースのシングルサインオン、クラウド ID、クライアント証明書、TLS などです。新しい方式は digna のリリースを待つのではなく、ドライバーの更新とともに利用できるようになります。
  • データベースベンダーが保守するドライバー — ベンダー自身のドライバーが新しいサーバーバージョンとセキュリティ修正に追随し、digna とは独立に、ご自身の都合に合わせて更新できます。
  • すべてを同じ方法で構成できる — どの技術もキーと値のプロパティの一覧であり、同じインターフェイス、同じ機密値の暗号化、同じトラブルシューティングを使います。ソースごとに異なる入力欄が並ぶことはありません。
  • 調整と適用範囲 — タイムアウト、TLS 設定、プロキシ、フェッチサイズといったドライバーレベルのオプションがすべてのソースで利用でき、準拠した ODBC ドライバーがある技術であれば、digna が個別のガイドを公開していないものも含めて接続できます。

実際には、Use ODBC スイッチと、ホスト・ポート・データベース・ユーザー・パスワードの個別の入力欄はなくなりました。すでに ODBC を使っていない接続はすべて ODBC へ移行する必要があります。自動変換はありませんので、アップグレード前に計画してください:

  1. インストールに定義されている各データベース接続を確認し、まだ ODBC を使っていないものを書き出してください。いずれも再構成が必要です。
  2. 対応する ODBC ドライバーを digna ホストにインストールします。接続はブラウザーからではなく、digna バックエンドを実行しているサーバーから開かれます。参照: digna ホストへの ODBC ドライバーのインストール。
  3. 影響を受ける各接続の ODBC プロパティを用意してください。 技術別ガイドには、ソースごとに実績のあるプロパティ一式が記載されています。

アップグレード後、影響を受けた各接続を ODBC に切り替え、ダッシュボードからテストしてください。参照: データベース接続の作成 および 接続のテスト。

Databricks Legacy 接続

Databricks Legacy コネクタは本リリースで削除されました。該当する接続は Databricks コネクタへ移行してください。

digna リポジトリのバックアップ作成は必須です

アップグレード前にリポジトリ(PostgreSQL)のバックアップを作成し、データ損失に備えてください。バックアップがあれば、アップグレード中に問題が発生しても復旧できます。

シェルからバックアップを作成するには:

pg_dump -h localhost -p 5432 -U digna_user -n dignarepo postgres > digna_repo_backup.sql

アップグレード手順

ステップ 1: digna サービスを停止する

digna が systemd サービスとして動作している場合、まず停止します:

cd /opt/digna/bin
sudo ./stop_service.sh

digna がフォアグラウンドで動作している場合は、そのターミナルで Ctrl + C を押してください。

ステップ 2: 現在のインストールをバックアップする

digna のインストールディレクトリで、新しいリリースを並べて配置できるよう、現在のインストールのフォルダー名を変更します:

cd /opt/digna
sudo mv dignabackend dignabackend_old
sudo mv dignacli dignacli_old
sudo mv dashboard dashboard_old

dignabackend と dignacli は使用されなくなりました

リリース 2026.06 から、dignabackend と dignacli は、バックエンドと CLI を統合した単一の実行ファイル digna に置き換えられます。dignabackend_old と dignacli_old はアップグレードを確認するまで残し、その後は両方とも削除してかまいません。dashboard_old は、そこから構成ファイルを復元するまで残してください(手順 4 を参照)。

ステップ 3: 新バージョンの展開とデプロイ

  1. 新しい digna インストール ZIP ファイルを展開
  2. 新しい digna 実行ファイルと dashboard フォルダをインストールディレクトリにコピー
  3. 実行ビットとサービスアカウントの所有権を復元:
sudo chmod +x /opt/digna/digna
sudo chown -R digna:digna /opt/digna

重要

config.toml も dashboard/dashboard_config.toml も、インストール ZIP に含まれることは 決して ありません。digna チームはどちらのファイルも配布しません。そのため既存の設定はアップグレードの影響を受けず、名前を変更した *_old フォルダー内のコピーが手元にある唯一の設定になります。

ステップ 4: 設定ファイルの復元

sudo cp dashboard_old/dashboard_config.toml dashboard/dashboard_config.toml

リリース 2026.06 で config.toml が変わります

3 つの設定が新たに必須となり、2 つは使用されなくなりました。以前のリリースから引き継いだ config.toml には新しい設定が含まれておらず、それらが欠けている限り digna は起動しません。既存の config.toml に次を追加してください:

[base]
DIGNA_SCHEDULER_MAX_DELAY = 100
DIGNA_CLEANUP_TIME = "12:00"

[encryption]
DIGNA_ENCRYPTION_KEY = 'ycELf6IbcO55dYIZHpPv6kQv/bbnUXoIaHLh2bh1kMg='

2 つの [base] キーを既存の [base] セクションに追加し、[encryption] を新しいセクションとして追加します。そのうえで、使用されなくなった 2 つの設定、digna_APP_HOST と digna_APP_PORT を [app] から削除してください。サーバーのアドレスとポートは digna serve から渡すようになりました。

各設定の役割については次を参照してください: バックエンド構成.

シングルサインオン: [oidc_clients] の形式が変わりました

リリース 2026.06 では、テーブルの配列が、プロバイダーごとに 1 つのテーブルへ置き換わりました。テーブル名はプロバイダーのキーになります。DIGNA_OIDC_KEY は廃止され、キーはセクション見出しの一部になりました。

変更前:

[[oidc_clients]]
DIGNA_OIDC_KEY = 'microsoft'
DIGNA_OIDC_CLIENT_ID = '<client_id>'
DIGNA_OIDC_CLIENT_SECRET = '<client_secret>'
DIGNA_OIDC_REDIRECT_URI = 'http://localhost:3000/oidc/callback'
DIGNA_OIDC_CONFIGURATION_URL = 'https://login.microsoftonline.com/<tenant_id>/v2.0/.well-known/openid-configuration'

変更後:

[oidc_clients.microsoft]
DIGNA_OIDC_CLIENT_ID = '<client_id>'
DIGNA_OIDC_CLIENT_SECRET = '<client_secret>'
DIGNA_OIDC_REDIRECT_URI = 'http://localhost:3000/oidc/callback'
DIGNA_OIDC_CONFIGURATION_URL = 'https://login.microsoftonline.com/<tenant_id>/v2.0/.well-known/openid-configuration'

プロバイダーごとにこのセクションを繰り返し、各キーを dashboard_config.toml の key と一致させてください。古い形式が残っている間、digna config check は oidc_clients を FAILED と報告します。影響を受けるのはシングルサインオンを使用しているインストールのみです。

ステップ 5: Web サーバーをリロードする

ダッシュボードは静的ファイルの集まりであるため、Web サーバー(およびブラウザー)が以前のバージョンを配信し続けている可能性があります。dashboard フォルダーをホストしている Web サーバーをリロードまたは再起動し、ページをハードリフレッシュ(Ctrl+F5)で再読み込みしてください。

ステップ 6: 構成を検証する

リポジトリに手を加える前に、更新した config.toml が完全であることを確認します:

./digna config check

すべてのセクションが OK と報告される必要があります。FAILED と報告された箇所を修正し、続行する前にコマンドを再実行してください。

ステップ 7: ライセンスファイルを置き換える

ライセンスはリリースごとに個別に発行されます。digna チームがこのリリース用に提供した license.toml をインストールディレクトリにコピーし、古いものを置き換えます:

sudo cp /path/to/new/license.toml /opt/digna/license.toml

以前のライセンスを使い続けないでください

以前のリリース向けに発行された license.toml はこのリリースには適用されません。ライセンスを確認するすべてのコマンド(user、inspection、repo)は、確認に失敗するとリポジトリに手を加える前に中止されます。先に進む前にライセンスを確認してください:

./digna license check

ステップ 8: リポジトリスキーマのアップグレード

digna インストールディレクトリに移動して次を実行します:

cd /opt/digna
./digna repo upgrade

これにより既存のデータを保持したまま PostgreSQL スキーマが最新バージョンに更新されます。

ステップ 9: サービスの再起動

systemd サービスとして実行している場合:

cd /opt/digna/bin
sudo ./start_service.sh

手動で実行している場合はサーバーを再起動します:

cd /opt/digna
./digna serve --address <address> --port <port>

nginx または Apache を使用している場合は、それぞれをリロードしてください:

sudo systemctl reload nginx
sudo systemctl restart apache2

RHEL 系で dashboard ディレクトリを置き換えた場合は、SELinux のラベリングを再適用してください:

sudo restorecon -Rv /opt/digna/dashboard

ステップ 10: アップグレードの確認

  1. digna ダッシュボードにアクセス
  2. インターフェースが正しく読み込まれることを確認
  3. サーバーログにエラーがないか確認:
  4. まだ ODBC を使っていなかった接続をすべて ODBC に切り替え、そのうえですべての接続をテストします。参照: 接続のテスト
sudo journalctl -u digna -n 100