Przejdź do treści

Przewodnik instalacji digna Release 2026.11 dla Linux

Wydanie: 2026.11

Ostatnia aktualizacja: 7 listopada 2026


Spis treści

  1. Wprowadzenie
  2. Wymagania systemowe
  3. Przygotowanie przed instalacją
  4. Konfiguracja serwera PostgreSQL
  5. Konfiguracja serwera WWW
  6. Instalacja początkowa
  7. Konfiguracja backendu
  8. Konfiguracja dashboardu
  9. Uruchamianie digna jako usługi systemd
  10. Aktualizacja do nowego wydania

Wprowadzenie

O digna

digna to kompleksowa platforma napędzana sztuczną inteligencją, zaprojektowana do optymalizacji zarządzania jakością danych w różnych środowiskach danych, takich jak hurtownie, data lake i lakehouse. Zbudowana z myślą o dużej skalowalności i elastyczności, digna rozwiązuje współczesne wyzwania związane z danymi dzięki automatyzacji, monitorowaniu w czasie rzeczywistym i wykrywaniu anomalii.

digna składa się z dwóch głównych komponentów:

  • digna: rdzeń aplikacji, odpowiedzialny za przetwarzanie danych i wykonywanie kontroli jakości. Łączy backend i interfejs wiersza poleceń w jednym pliku wykonywalnym, zastępując osobne programy dignabackend i dignacli z wcześniejszych wydań.
  • dignadashboard: interfejs webowy hostowany na serwerze WWW, zapewniający przyjazny sposób interakcji z platformą digna oraz wizualizację wskaźników jakości danych.

Co nowego w wydaniu 2026.11

To wydanie wprowadza digna Data Reconciliation, digna Agentic z digna MCP Server oraz digna Engine, który potrafi profilować dane wewnątrz digna i sprawdzać integralność referencyjną między różnymi technologiami baz danych. Pełne szczegóły znajdziesz w notatkach o wydaniu.

Z punktu widzenia instalacji wydanie wprowadza nowy mechanizm migracji repozytorium, opcjonalną sekcję [duckdb] w config.toml dla digna Engine oraz nowy plik licencji. Każdy z tych elementów omawia sekcja o aktualizacji.

Szukasz Windows lub macOS?

Ten przewodnik dotyczy Linux. Dla innych platform zobacz Przewodnik instalacji dla Windows lub Przewodnik instalacji dla macOS.

Których dystrybucji dotyczy ten przewodnik?

Instrukcje zostały napisane dla dwóch najpopularniejszych rodzin systemów serwerowych. Tam, gdzie się one różnią, podano oba polecenia:

  • Rodzina Debian — Debian, Ubuntu. Menedżer pakietów: apt.
  • Rodzina RHEL — Red Hat Enterprise Linux, Rocky Linux, AlmaLinux, Fedora. Menedżer pakietów: dnf.

Zadziała każda nowoczesna dystrybucja z systemd; zmieniają się jedynie nazwy pakietów i kilka ścieżek konfiguracyjnych.


Wymagania systemowe

Zanim rozpoczniesz instalację, upewnij się, że system spełnia następujące minimalne wymagania:

Wymaganie Specyfikacja
System operacyjny Ubuntu 22.04 LTS lub nowszy, Debian 12 lub nowszy, RHEL 9 / Rocky 9 / AlmaLinux 9 lub nowszy
Architektura x86_64 (amd64) lub arm64
System init systemd
Pamięć (Minimalna konfiguracja) 16 GB RAM
Miejsce na dysku 10 GB dostępnego miejsca
Baza danych PostgreSQL Server 12 lub nowszy
Serwer WWW nginx, Apache httpd lub równoważny

digna Engine

Połączenia z bazami danych, które jako lokalizację profilowania wykorzystują digna Engine, są profilowane bezpośrednio na hoście digna. Zaplanuj dla nich dodatkową pamięć i miejsce na dysku, zobacz sekcję [duckdb].

Opcje instalacji bazy danych

Jeśli PostgreSQL jest już zainstalowany: Możesz dodać nową bazę danych dla digna do istniejącego serwera PostgreSQL.

Jeśli instalujesz PostgreSQL na tej samej maszynie co digna:

Zalecane specyfikacje

  • Pamięć: 32 GB RAM (zamiast 16 GB)
  • Miejsce na dysku: 50 GB dostępnego miejsca (zamiast 10 GB)

Te wyższe specyfikacje uwzględniają równoczesne uruchomienie digna i bazy PostgreSQL.

Sprawdzanie dystrybucji i architektury

Kilka poleceń w tym przewodniku różni się między rodzinami Debian i RHEL. Aby sprawdzić, z której korzystasz, uruchom:

cat /etc/os-release
uname -m
  • ID=ubuntu lub ID=debian — używaj poleceń apt.
  • ID=rhel, rocky, almalinux lub fedora — używaj poleceń dnf.
  • x86_64 lub aarch64 — architektura potrzebnego pakietu instalacyjnego.

Przygotowanie przed instalacją

Przed instalacją digna upewnij się, że są spełnione dwa kluczowe warunki wstępne:

  1. Serwer PostgreSQL – do przechowywania wyliczonych metryk i danych wydajnościowych
  2. Serwer WWW – do hostowania Dashboardu digna

Jeśli te komponenty nie są jeszcze skonfigurowane, postępuj zgodnie z poniższymi sekcjami, aby je zainstalować i skonfigurować.

Odświeżanie indeksu pakietów

Zaktualizuj listy pakietów, zanim cokolwiek zainstalujesz:

sudo apt update
sudo dnf check-update

Uwaga

W całym przewodniku pierwsze polecenie z pary jest przeznaczone dla rodziny Debian, a drugie dla rodziny RHEL. Uruchamiaj tylko to, które pasuje do Twojego systemu.


Konfiguracja serwera PostgreSQL

Jeśli masz już PostgreSQL

Jeśli PostgreSQL jest już zainstalowany i działa lokalnie lub jeśli używasz zarządzanego zdalnego serwera PostgreSQL, możesz przejść do następnej sekcji.

Instalacja PostgreSQL

Krok 1: Zainstaluj pakiet serwera

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

Wskazówka

Pakiety dystrybucji mogą nie nadążać za bieżącym wydaniem PostgreSQL. Jeśli potrzebujesz konkretnej, nowszej wersji, użyj zamiast tego oficjalnego repozytorium apt lub yum PostgreSQL.

Krok 2: Zainicjuj klaster bazy danych

W rodzinie Debian pakiet automatycznie tworzy i uruchamia klaster — przejdź do następnego kroku.

W rodzinie RHEL klaster trzeba utworzyć jawnie:

sudo postgresql-setup --initdb

Krok 3: Uruchom i włącz usługę

sudo systemctl enable --now postgresql

To polecenie natychmiast uruchamia PostgreSQL i konfiguruje go tak, aby automatycznie uruchamiał się ponownie przy starcie systemu.

Krok 4: Zweryfikuj instalację

psql --version
sudo systemctl status postgresql

Powinieneś zobaczyć wersję PostgreSQL oraz usługę w stanie active (running).

Krok 5: Połącz się z serwerem

Pakiet PostgreSQL dla Linux tworzy konto systemowe postgres, które jest właścicielem klastra. Połącz się za jego pośrednictwem:

sudo -u postgres psql

Uwaga — tutaj Linux różni się od Windows

Instalator dla Windows prosi podczas instalacji o ustawienie hasła superużytkownika postgres. Pakiety dla Linux tego nie robią. Zamiast tego połączenia lokalne są uwierzytelniane za pomocą uwierzytelniania peer: użytkownik systemu operacyjnego postgres może łączyć się jako użytkownik bazy danych postgres bez hasła.

Dlatego powyższe polecenie używa sudo -u postgres. Backend digna łączy się przez TCP z nazwą użytkownika i hasłem, więc w sekcji Instalacja początkowa utworzysz dedykowanego użytkownika digna.

Krok 6: Potwierdź port

Domyślny port PostgreSQL to 5432. Aby potwierdzić port, na którym nasłuchuje Twój serwer:

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

Zanotuj tę wartość — będzie potrzebna podczas konfigurowania backendu digna.

Krok 7: Włącz uwierzytelnianie hasłem dla użytkownika digna

digna łączy się z PostgreSQL przez TCP jako digna_user, co wymaga uwierzytelniania hasłem zamiast uwierzytelniania peer. Sprawdź, czy Twój plik pg_hba.conf na to pozwala.

Znajdź plik:

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

Otwórz go w edytorze i upewnij się, że lokalne wiersze TCP używają metody scram-sha-256 (lub md5 na starszych serwerach), a nie ident:

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

Po każdej zmianie przeładuj PostgreSQL:

sudo systemctl reload postgresql

Ważne

Jeśli digna zgłasza FATAL: Ident authentication failed for user "digna_user", przyczyną jest właśnie to ustawienie.

Krok 8: Jeśli PostgreSQL działa na innej maszynie

Aby przyjmować połączenia z innego hosta, ustaw listen_addresses w postgresql.conf i dodaj w pg_hba.conf odpowiedni wiersz host dla swojej sieci:

listen_addresses = '*'

Następnie otwórz port w zaporze sieciowej i zrestartuj usługę:

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


Konfiguracja serwera WWW

digna wymaga serwera WWW do hostowania dashboardu. Wybierz jedną z poniższych opcji:

Wystarczy zainstalować i skonfigurować jeden z tych serwerów.

Obie sekcje konfigurują dwie rzeczy, od których zależy dashboard:

  • Mechanizm awaryjny dla aplikacji jednostronicowej (SPA), aby odświeżenie adresu URL dashboardu nie zwracało błędu 404
  • Typ MIME dla .md, aby pliki Markdown były serwowane poprawnie

Konfiguracja nginx

Przegląd

nginx to lekki, wydajny serwer WWW, dobrze nadający się do serwowania statycznego dashboardu digna.

Instalacja

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

Uruchamianie nginx

sudo systemctl enable --now nginx

Zweryfikuj instalację

  1. Otwórz przeglądarkę
  2. Przejdź do http://localhost
  3. Powinieneś zobaczyć stronę powitalną nginx

Otwieranie zapory sieciowej

Jeśli serwer jest osiągany z innych maszyn, zezwól na ruch HTTP:

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

Konfigurowanie witryny dla dashboardu

W obu rodzinach dystrybucji nginx dołącza każdy plik ze swojego katalogu conf.d. Utwórz tam dedykowany plik konfiguracyjny dla digna:

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

Wklej poniższą treść, zastępując /opt/digna/dashboard rzeczywistą ścieżką do rozpakowanego folderu 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;
    }
}

Ważne

Bez dyrektywy try_files przeładowanie dowolnej strony dashboardu innej niż główny adres URL zwraca błąd 404. Jest to odpowiednik modułu URL Rewrite wymaganego przez IIS w systemie Windows.

Wyłącz domyślną witrynę

Tylko jeden blok server może być default_server dla danego portu. W rodzinie Debian usuń domyślną witrynę z pakietu, aby nie powodowała konfliktu:

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

W rodzinie RHEL zakomentuj lub usuń blok server { ... } w pliku /etc/nginx/nginx.conf.

Zastosuj konfigurację

Sprawdź konfigurację pod kątem błędów składni, a następnie przeładuj nginx:

sudo nginx -t
sudo systemctl reload nginx

Konfiguracja Apache httpd

Przegląd

Apache httpd jest dostępny w domyślnych repozytoriach każdej obsługiwanej dystrybucji. Pakiet nazywa się apache2 w rodzinie Debian i httpd w rodzinie RHEL.

Instalacja

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

Uruchamianie Apache

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

Zweryfikuj instalację

  1. Otwórz przeglądarkę
  2. Przejdź do http://localhost
  3. Powinieneś zobaczyć domyślną stronę Apache danej dystrybucji

Wymagane: włącz mod_rewrite

Dashboard wymaga przepisywania adresów URL.

W rodzinie Debian włącz moduł i zrestartuj serwer:

sudo a2enmod rewrite
sudo systemctl restart apache2

W rodzinie RHEL moduł mod_rewrite jest ładowany domyślnie. Potwierdź to:

httpd -M | grep rewrite

Wymagane: zezwól na nadpisywanie przez .htaccess

Otwórz plik konfiguracyjny dla katalogu głównego dokumentów:

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

Znajdź blok <Directory> obejmujący katalog główny dokumentów (/var/www/html w obu rodzinach) i zmień:

AllowOverride None

na:

AllowOverride All

Wymagane: typ MIME dla plików Markdown

W tym samym pliku dodaj następujący wiersz, aby pliki Markdown były serwowane poprawnie:

AddType text/markdown .md

Ważne

Bez tego ustawienia pliki .md mogą nie być serwowane poprawnie.

Zastosuj konfigurację

Sprawdź konfigurację pod kątem błędów składni, a następnie zrestartuj Apache:

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


Instalacja początkowa

Krok 1: Skonfiguruj repozytorium digna

Repozytorium digna przechowuje wszystkie metryki wyliczane przez digna. Działa jako centralna baza danych dla danych analitycznych i wydajnościowych.

Utwórz schemat repozytorium i użytkownika

Otwórz klienta PostgreSQL (psql, pgAdmin lub podobny) i wykonaj poniższe polecenia 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>;

Zastąp następujące zmienne:

  • <digna_repo_schema> — Wybrana nazwa schematu (np. dignarepo)
  • <digna_repo_user> — Wybrana nazwa użytkownika (np. digna_user)
  • <digna_repo_password> — Bezpieczne hasło dla tego użytkownika

Przykład:

CREATE SCHEMA dignarepo;

CREATE USER digna_user WITH PASSWORD 'YourSecurePassword123!';

GRANT ALL PRIVILEGES ON SCHEMA dignarepo TO digna_user;

Aby wykonać je z powłoki w jednym kroku:

sudo -u postgres psql

Następnie wklej polecenia w wierszu zachęty postgres=# i wpisz \q, aby zakończyć.

Dobra praktyka

Używaj silnych, złożonych haseł dla użytkowników bazy danych. Unikaj łatwych do odgadnięcia danych uwierzytelniających.


Krok 2: Rozpakuj pakiet instalacyjny digna

  1. Znajdź plik ZIP instalacji digna dostarczony Ci
  2. Rozpakuj go do wybranej lokalizacji instalacyjnej — na przykład /opt/digna
  3. Po rozpakowaniu powinieneś zobaczyć następujące elementy:
  4. dashboard/ — interfejs webowy
  5. digna — główny plik wykonywalny (backend + CLI w jednym)

Plików konfiguracyjnych i pliku licencji nie ma w pakiecie

Ani config.toml, ani dashboard/dashboard_config.toml nie są dostarczane z instalacją — oba tworzysz samodzielnie, w sekcjach Konfiguracja backendu i Konfiguracja dashboardu. license.toml również nie jest dołączany; digna dostarcza go osobno, zgodnie z opisem w kroku 3.

Aby rozpakować archiwum z powłoki:

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

Uwaga

Jeśli unzip nie jest zainstalowany, dodaj go poleceniem sudo apt install -y unzip lub sudo dnf install -y unzip.

Nadaj plikowi wykonywalnemu prawo do uruchamiania

W zależności od sposobu przesłania archiwum bit wykonywalności może nie zachować się po rozpakowaniu. Ustaw go jawnie:

cd /opt/digna
sudo chmod +x digna

Utwórz konto usługi

W wdrożeniach produkcyjnych zaleca się uruchamianie backendu jako dedykowany, nieuprzywilejowany użytkownik:

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

Uwaga

W rodzinie RHEL odpowiednia ścieżka powłoki to /sbin/nologin.

Krok 3: Zainstaluj plik licencji

Ważne

Plik licencji nie jest dołączony do pakietu instalacyjnego i zostanie dostarczony oddzielnie przez digna.

  1. Znajdź plik license.toml dostarczony Ci
  2. Skopiuj go do katalogu głównego instalacji digna (tam, gdzie znajdują się config.toml i plik wykonywalny digna)

Dlaczego to ważne: Plik licencji zawiera informacje o kliencie, datę wygaśnięcia licencji i podpis cyfrowy. Nie modyfikuj tego pliku — jakiekolwiek zmiany unieważnią licencję.

Struktura katalogów po konfiguracji:

/opt/digna/
├── config.toml         (plik konfiguracyjny)
├── license.toml        (TWÓJ PLIK LICENCYJNY - skopiuj tutaj)
├── digna               (główny plik wykonywalny)
├── bin/                (skrypty zarządzania usługą)
└── dashboard/          (interfejs webowy)
    └── (pliki dashboardu)

Konfiguracja backendu

Krok 1: Utwórz i edytuj plik konfiguracyjny

Plik config_template.toml jest dostarczony w katalogu instalacyjnym digna. Wystarczy zmienić jego nazwę na config.toml.

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

Lokalizacja: /opt/digna/config.toml

Otwórz config.toml w edytorze tekstu i skonfiguruj każdą z poniższych sekcji.

Sekcja [app]

Ta sekcja konfiguruje mechanizm CORS (cross-origin resource sharing) między dashboardem a backendem:

[app]
DIGNA_APP_CORS_ALLOW_ORIGINS = ["http://localhost:5173"]
DIGNA_APP_CORS_ALLOW_CREDENTIALS = true
Parametr Wartość Uwagi
DIGNA_APP_CORS_ALLOW_ORIGINS Adresy URL dashboardu Adresy URL, z których serwowany jest dashboard. Żądania przeglądarki z każdego innego originu są odrzucane
DIGNA_APP_CORS_ALLOW_CREDENTIALS true Wymagane, aby przeglądarka wysyłała ciasteczko sesji z każdym żądaniem

Uwaga

Jeśli serwujesz dashboard z nginx lub Apache na domyślnym porcie HTTP, dozwolonym originem jest http://localhost — albo publiczny adres URL serwera, jeśli dashboard jest otwierany z innych maszyn.

Sekcja [app] jest opcjonalna

Od wydania 2026.11 można pominąć oba klucze, a nawet całą sekcję [app]. To właściwa konfiguracja, gdy reverse proxy serwuje dashboard i backend pod jednym originem: przeglądarka nie wysyła wtedy żądań między originami, a domyślnie żadne takie żądanie nie jest dozwolone.

Sekcja [repo]

Ta sekcja konfiguruje połączenie z bazą danych 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_SSLMODE = "prefer"
DIGNA_REPO_NUM_CONNS = 16
Parametr Wartość Uwagi
DIGNA_REPO_HOST localhost lub adres IP Nazwa hosta/IP serwera PostgreSQL
DIGNA_REPO_PORT 5432 (domyślnie) Port PostgreSQL
DIGNA_REPO_DB postgres Nazwa bazy danych
DIGNA_REPO_SCHEMA dignarepo Schemat utworzony wcześniej
DIGNA_REPO_USER digna_user Użytkownik utworzony w konfiguracji PostgreSQL
DIGNA_REPO_PASSWORD Twoje hasło Hasło ustawione podczas tworzenia schematu
DIGNA_REPO_SSLMODE prefer (domyślnie) Opcjonalne. Tryb SSL PostgreSQL: disable, allow, prefer, require, verify-ca lub verify-full
DIGNA_REPO_NUM_CONNS 16 (domyślnie) Opcjonalne. Liczba połączeń z repozytorium, które digna utrzymuje otwarte

Dobra praktyka

config.toml zawiera hasło do bazy danych zapisane otwartym tekstem. Ogranicz uprawnienia do pliku tak, aby mogło go odczytać wyłącznie konto usługi:

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

Sekcja [base]

Ta sekcja zawiera ustawienia bezpieczeństwa, ciasteczek i inspekcji:

[base]
DIGNA_FERNET_KEY = "DU4a0yJ-OqvbKCL4hNQn_CsknH-V1vWmHZqBUl-AY44="
DIGNA_COOKIE_DOMAIN = "localhost"
DIGNA_COOKIE_SECURE = false
DIGNA_COOKIE_HTTPONLY = true
DIGNA_TOKEN_EXPIRES_IN = 86400
DIGNA_MAX_WORKERS = 4
DIGNA_FRONTEND_BASEURL = "http://localhost/"
DIGNA_SOURCE_QUERY_TIMEOUT_SEC = 3600
DIGNA_SOURCE_LOGIN_TIMEOUT_SEC = 30
Parametr Wartość Uwagi
DIGNA_FERNET_KEY Wartość pokazana powyżej Klucz szyfrowania używanego przez wcześniejsze wydania. Musi być obecny; zachowaj pokazaną wartość
DIGNA_COOKIE_DOMAIN localhost Host, pod którym dostępny jest dashboard. "" nie ustawia domeny, co jest właściwe za proxy, które serwuje dashboard i backend pod jednym originem
DIGNA_COOKIE_SECURE false (HTTP) / true (HTTPS) Musi mieć wartość true zawsze, gdy digna jest serwowana przez HTTPS
DIGNA_COOKIE_HTTPONLY true Chroni ciasteczko sesji przed dostępem ze skryptów
DIGNA_TOKEN_EXPIRES_IN 86400 (24 godziny) Czas wygasania sesji w sekundach
DIGNA_MAX_WORKERS Liczba rdzeni CPU - 1 Liczba inspekcji, które mogą działać jednocześnie
DIGNA_FRONTEND_BASEURL URL dashboardu Wymagane. Używany w linkach w powiadomieniach, więc musi to być adres URL, który odbiorcy mogą otworzyć
DIGNA_SOURCE_QUERY_TIMEOUT_SEC 3600 (domyślnie) Opcjonalne. Liczba sekund, przez które pojedyncze zapytanie do źródłowej bazy danych może działać, zanim zostanie przerwane; 0 wyłącza limit czasu
DIGNA_SOURCE_LOGIN_TIMEOUT_SEC 30 (domyślnie) Opcjonalne. Liczba sekund oczekiwania na połączenie ze źródłową bazą danych; 0 oznacza oczekiwanie bez limitu

Wskazówka

Aby sprawdzić liczbę rdzeni CPU dostępnych na serwerze, uruchom nproc.

Sekcja [encryption]

Ta sekcja zawiera klucz służący do szyfrowania wrażliwych wartości przechowywanych w repozytorium. Jest wymagana — config check zgłasza sekcję [encryption] jako FAILED, jeśli klucza brakuje.

[encryption]
DIGNA_ENCRYPTION_KEY = 'ycELf6IbcO55dYIZHpPv6kQv/bbnUXoIaHLh2bh1kMg='
Parametr Wartość Uwagi
DIGNA_ENCRYPTION_KEY Klucz zakodowany w Base64 Szyfruje wrażliwe wartości przechowywane w repozytorium digna

Chroń plik config.toml

Ten klucz jest wartością stałą, identyczną we wszystkich instalacjach digna, i to on odszyfrowuje wrażliwe wartości w Twoim repozytorium. Ogranicz dostęp do config.toml do konta, na którym działa digna, trzymaj plik poza systemem kontroli wersji i dyskami współdzielonymi oraz wyłącz go z każdej kopii zapasowej przechowywanej mniej bezpiecznie niż samo repozytorium.

Sekcja [logging]

Ta sekcja konfiguruje zachowanie logowania:

[logging]
DIGNA_LOGGING_MODE = "INFO"
DIGNA_LOGGING_DIR = "logs"
DIGNA_LOGGING_MAX_FILES = 30
Parametr Wartość Uwagi
DIGNA_LOGGING_MODE INFO lub DEBUG INFO dla produkcji, DEBUG do rozwiązywania problemów. Akceptowane są również TRACE, WARN i ERROR
DIGNA_LOGGING_DIR logs (domyślnie) Opcjonalne. Katalog rotowanych plików logów, względem katalogu roboczego
DIGNA_LOGGING_MAX_FILES 30 (domyślnie) Opcjonalne. Liczba przechowywanych rotowanych plików logów

Sekcja [duckdb] (opcjonalna)

Nowość w wydaniu 2026.11. Ta sekcja określa zasoby digna Engine, który profiluje dane wewnątrz digna dla połączeń z bazami danych, których lokalizacja profilowania to Silnik digna, oraz wykonuje kontrole integralności referencyjnej między źródłami danych w różnych połączeniach z bazami danych. Zobacz Lokalizacja profilowania.

Sekcja jest opcjonalna. Bez niej obowiązują poniższe wartości domyślne.

[duckdb]
DIGNA_DUCKDB_MEMORY_LIMIT_MB = 1024
DIGNA_DUCKDB_TEMP_DIRECTORY = "/opt/digna/tmp"
Parametr Wartość Uwagi
DIGNA_DUCKDB_MEMORY_LIMIT_MB 1024 (domyślnie) Pamięć w MB, z której może korzystać jedno uruchomienie digna Engine. Jednocześnie może być aktywnych do DIGNA_MAX_WORKERS uruchomień
DIGNA_DUCKDB_TEMP_DIRECTORY Domyślnie: katalog tymczasowy systemu ($TMPDIR lub /tmp, gdy zmienna nie jest ustawiona) Katalog na pliki tymczasowe, gdy dane nie mieszczą się w pamięci

Dobór zasobów dla digna Engine

Zaplanuj na hoście digna do DIGNA_MAX_WORKERS × DIGNA_DUCKDB_MEMORY_LIMIT_MB pamięci ponad to, czego używa sama digna, oraz tyle wolnego miejsca na dysku w katalogu tymczasowym, aby zmieścić największą inspekcjonowaną datę spośród źródeł danych korzystających z digna Engine. Wskaż w DIGNA_DUCKDB_TEMP_DIRECTORY dysk z takim miejscem, z prawem zapisu dla konta, na którym działa digna:

sudo mkdir -p /opt/digna/tmp
sudo chown digna:digna /opt/digna/tmp

Ta sekcja jest potrzebna tylko wtedy, gdy co najmniej jedno połączenie z bazą danych korzysta z digna Engine albo kontrola integralności referencyjnej porównuje źródła danych w różnych połączeniach.


Krok 2: Sprawdź konfigurację

Przed zainicjowaniem repozytorium sprawdź, czy config.toml jest kompletny i poprawnie zbudowany. W katalogu instalacyjnym digna uruchom:

./digna config check

Każda sekcja jest sprawdzana osobno, więc pojedynczy błąd nie zasłania stanu pozostałych:

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
 - Template overrides: OK
 - Unknown keys: OK

Overall: OK

Popraw wszystko, co zostało zgłoszone jako FAILED, i uruchom polecenie ponownie przed kontynuowaniem. Ostrzeżenie (WARNING) w pozycji Unknown keys wymienia klucze w config.toml, których digna nie odczytuje; nie mają one żadnego efektu, więc usuń je lub popraw ich pisownię. Pełną listę opcji znajdziesz w dokumentacji CLI.

Krok 3: Zainicjuj repozytorium

  1. Otwórz terminal
  2. Przejdź do katalogu instalacji digna (tam, gdzie znajdują się config.toml i plik wykonywalny digna)
  3. Uruchom test połączenia:
cd /opt/digna
./digna repo check

W nowym schemacie polecenie łączy się, a następnie zgłasza, że repozytorium nie jest jeszcze zainstalowane:

Error: No repo installed. Use the 'digna repo upgrade' command to install it.

Na tym etapie jest to oczekiwany wynik: potwierdza, że digna dociera do PostgreSQL i do schematu. Błąd połączenia lub uwierzytelniania wskazuje natomiast na sekcję [repo] lub na konfigurację PostgreSQL.

Uwaga

W systemie Linux bieżący katalog nie znajduje się w zmiennej PATH, dlatego plik wykonywalny wywołuje się jako ./digna, a nie digna. Aby wszędzie używać krótszej formy, dodaj dowiązanie symboliczne:

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

Krok 4: Zainstaluj schemat repozytorium

W tym samym katalogu uruchom:

./digna repo upgrade

To polecenie instaluje niezbędne tabele w schemacie repozytorium i kończy się komunikatem:

✅ Repo schema 'dignarepo' is up to date.

repo upgrade instaluje i aktualizuje

Od wydania 2026.11 repo upgrade instaluje nowe repozytorium i aktualizuje istniejące. repo install nadal działa jako inna nazwa tego samego polecenia.

Krok 5: Utwórz użytkownika administratora

Użytkownik administratora jest tworzony bezpośrednio w schemacie repozytorium, więc serwer nie musi jeszcze działać. W katalogu instalacji digna uruchom:

./digna user add <email> <password> "<display_name>" --admin

Przykład:

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

To tworzy użytkownika o adresie e-mail admin@example.com z pełnymi uprawnieniami administracyjnymi.

Wskazówka

Umieść hasło w pojedynczych cudzysłowach. bash i zsh traktują znaki takie jak !, $ i * w szczególny sposób, a hasło zawierające je bez cudzysłowów nie zostanie przekazane w takiej postaci, w jakiej je wpisano.

Dobra praktyka

Używaj silnego hasła zawierającego wielkie i małe litery, cyfry oraz znaki specjalne.

Krok 6: Uruchom serwer digna

W katalogu instalacyjnym digna uruchom serwer poleceniem:

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

Parametry: - --address — nazwa hosta/IP serwera (domyślnie 127.0.0.1) - --port — port serwera (domyślnie 8000)

Po uruchomieniu serwer wypisuje adres, na którym nasłuchuje:

Server running on http://127.0.0.1:8082

Wskazówka

Jeśli dashboard jest serwowany z innej maszyny niż backend, otwórz również port API w zaporze sieciowej:

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

Serwer zajmuje terminal

serve działa na pierwszym planie i pracuje, dopóki nie zatrzymasz go skrótem Ctrl+C. Zostaw go uruchomionego, dopóki nie dokończysz konfiguracji; aby zamiast tego uruchamiał się automatycznie przy starcie systemu, zobacz Uruchamianie digna jako usługi systemd.


Konfiguracja dashboardu

Krok 1: Wdróż dashboard na serwerze WWW

Dashboard digna odczytuje własną konfigurację z pliku dashboard/dashboard_config.toml. Ten plik nie jest dostarczany z instalacją — tworzysz go w katalogu dashboard/, obok plików dashboardu.

Jego zawartość opisano w sekcji Logowanie jednokrotne (SSO), bo właśnie tam ten plik jest potrzebny: zawiera opcje logowania oferowane przez dashboard oraz, w przypadku wdrożeń wieloinstancyjnych, połączenie z backendem.

Wybierz serwer WWW i postępuj zgodnie z odpowiednimi krokami wdrożeniowymi.

Wdrażanie w nginx

Jeśli wykonano kroki z sekcji Konfiguracja nginx, blok server wskazuje już na folder dashboard i kopiowanie nie jest potrzebne.

  1. Potwierdź ścieżkę
  2. Otwórz /etc/nginx/conf.d/digna.conf
  3. Sprawdź, czy root wskazuje na rozpakowany folder dashboard

  4. Upewnij się, że folder jest czytelny

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

  5. Przeładuj nginx

    sudo nginx -t
    sudo systemctl reload nginx
    

  6. Przetestuj instalację

  7. Otwórz przeglądarkę
  8. Przejdź do http://localhost (lub skonfigurowanego adresu URL)
  9. Powinieneś zobaczyć stronę logowania dashboardu digna

Wdrażanie w Apache httpd

  1. Skopiuj dashboard do katalogu głównego dokumentów

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

  2. Dodaj reguły przepisywania

Utwórz plik .htaccess we wdrożonym folderze, aby trasy dashboardu działały po odświeżeniu przeglądarki:

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

Wklej poniższą treść:

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. Zrestartuj Apache

    sudo systemctl restart apache2
    
    sudo systemctl restart httpd
    

  2. Otwórz dashboard

  3. Otwórz przeglądarkę
  4. Przejdź do http://localhost/digna
  5. Powinieneś zobaczyć stronę logowania dashboardu digna

Krok 2: SELinux (tylko rodzina RHEL)

W systemach RHEL, Rocky, AlmaLinux i Fedora SELinux domyślnie działa w trybie enforcing i blokuje serwerowi WWW odczyt plików spoza oczekiwanych lokalizacji. Sprawdź, czy jest aktywny:

getenforce

Jeśli wynik to Enforcing, a dashboard jest serwowany z /opt/digna/dashboard, nadaj katalogowi etykietę, która pozwoli serwerowi WWW go odczytywać:

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

Uwaga

Jeśli polecenie semanage nie zostanie znalezione, zainstaluj je poleceniem sudo dnf install -y policycoreutils-python-utils.

Ważne

Dashboard zwracający 403 Forbidden na świeżo skonfigurowanym serwerze RHEL niemal zawsze oznacza problem z etykietami SELinux, a nie z uprawnieniami do plików. Potwierdź to poleceniem sudo ausearch -m avc -ts recent.


Uruchamianie digna jako usługi systemd

Dlaczego uruchamiać digna jako usługę?

Uruchomienie backendu digna jako usługi systemd zapewnia, że:

  • Uruchamia się automatycznie podczas startu maszyny
  • Działa w tle bez otwartego okna terminala
  • Automatycznie się restartuje w razie awarii
  • Można nim zarządzać za pomocą systemctl, standardowego menedżera usług w systemie Linux

Pliki zarządzania usługą

Wszystkie niezbędne pliki znajdują się w katalogu instalacji digna w: bin/

Dostępne skrypty powłoki:

  • install_service.sh — rejestruje digna w systemd
  • uninstall_service.sh — usuwa rejestrację usługi
  • start_service.sh — uruchamia zarejestrowaną usługę
  • stop_service.sh — zatrzymuje działającą usługę

Wymagane uprawnienia root

Wszystkie skrypty muszą być uruchamiane przez sudo, ponieważ rejestracja usługi uruchamianej przy starcie systemu zapisuje plik jednostki w /etc/systemd/system.

Nadawanie skryptom prawa do uruchamiania

Rozpakowanie może nie zachować bitu wykonywalności. Przed pierwszym użyciem wykonaj:

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

Instalacja usługi

  1. Otwórz terminal

  2. Przejdź do folderu bin

    cd /opt/digna/bin
    

  3. Uruchom skrypt instalacyjny

    sudo ./install_service.sh
    

Serwer digna jest teraz zarejestrowany w systemd z włączonym automatycznym uruchamianiem. Usługa nie uruchamia się od razu — zobacz następną sekcję, aby ją uruchomić.

Uruchamianie i zatrzymywanie usługi

Aby uruchomić usługę

  1. Otwórz terminal
  2. Przejdź do /opt/digna/bin
  3. Uruchom:
    sudo ./start_service.sh
    

Aby zatrzymać usługę

  1. Otwórz terminal
  2. Przejdź do /opt/digna/bin
  3. Uruchom:
    sudo ./stop_service.sh
    

Wskazówka

Zawsze zatrzymuj usługę przed aktualizacją plików aplikacji.

Zarządzanie usługą za pomocą systemctl

Po zarejestrowaniu usługą można też sterować standardowymi poleceniami systemd z dowolnego katalogu:

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

Weryfikacja usługi

Aby potwierdzić, że usługa jest zarejestrowana i działa:

systemctl is-enabled digna
systemctl is-active digna

enabled oznacza, że usługa uruchamia się przy starcie systemu; active oznacza, że działa w tej chwili.

Przeglądanie logów usługi

systemd przechwytuje wszystko, co backend wypisuje na konsolę. Aby to odczytać:

sudo journalctl -u digna -n 100

Aby śledzić log na bieżąco podczas odtwarzania problemu:

sudo journalctl -u digna -f

Wskazówka

To najszybszy sposób zdiagnozowania usługi, która uruchamia się i natychmiast zatrzymuje. Błąd połączenia z repozytorium lub brak pliku license.toml są zgłaszane właśnie tutaj.

Przenoszenie usługi do nowego katalogu

Plik jednostki przechowuje bezwzględną ścieżkę do pliku wykonywalnego, więc przeniesienie instalacji wymaga ponownej rejestracji usługi:

  1. Odinstaluj aktualną usługę

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

  2. Przenieś pliki aplikacji

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

  3. Zainstaluj usługę ponownie

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

  4. Uruchom usługę

    sudo ./start_service.sh
    

Odinstalowywanie usługi

  1. Zatrzymaj działającą usługę

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

  2. Odinstaluj usługę

    sudo ./uninstall_service.sh
    

Serwer digna jest teraz wyrejestrowany z systemd.


Aktualizacja do nowego wydania

Ta sekcja opisuje aktualizację instalacji wydania 2026.06 do wydania 2026.11. Jeśli Twoja instalacja jest starsza, najpierw przeczytaj Aktualizacja z wydania wcześniejszego niż 2026.06.

Przed aktualizacją

Utworzenie kopii zapasowej repozytorium digna jest obowiązkowe

Przed aktualizacją digna wykonaj kopię zapasową repozytorium (PostgreSQL), aby zabezpieczyć się przed utratą danych. Kopia zapasowa pozwoli przywrócić stan w razie napotkania problemów podczas aktualizacji.

Aby utworzyć kopię zapasową z powłoki:

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

Zamów plik licencji dla wydania 2026.11

Wydanie 2026.11 wymaga nowego pliku license.toml. Poproś o niego zespół digna przed rozpoczęciem i przygotuj go na krok 7.

Aktualizacja z wydania wcześniejszego niż 2026.06

Wydanie 2026.06 wprowadziło trzy zmiany, które nadal obowiązują, gdy aktualizujesz starszą instalację bezpośrednio do wydania 2026.11:

  • Tylko ODBC. digna łączy się z każdą technologią źródłową przez ODBC. Każde połączenie z bazą danych, które nie korzysta jeszcze z ODBC, trzeba po aktualizacji przestawić na ODBC; nie ma automatycznej konwersji. Wcześniej zainstaluj sterowniki ODBC na hoście digna, zobacz Instalacja sterownika ODBC na hoście digna, i przygotuj właściwości każdego połączenia na podstawie przewodników technologicznych. Łącznik Databricks Legacy już nie istnieje; przenieś te połączenia na łącznik Databricks.
  • Jeden plik wykonywalny. dignabackend i dignacli zostały zastąpione pojedynczym plikiem wykonywalnym digna, który łączy backend i CLI.
  • config.toml. Sekcja [encryption] jest wymagana, a DIGNA_APP_HOST i DIGNA_APP_PORT nie są już odczytywane: adres i port serwer pobiera z digna serve. Porównaj swój plik z Konfiguracją backendu.

Poniższe kroki wskazują, w których miejscach starsza instalacja wymaga innego postępowania. Aktualizacja repozytorium w kroku 8 przenosi repozytorium z dowolnego wcześniejszego wydania bezpośrednio do wydania 2026.11.

Proces aktualizacji

Krok 1: Zatrzymaj usługę digna

Jeśli digna działa jako usługa systemd, najpierw ją zatrzymaj:

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

Jeśli digna działa na pierwszym planie, naciśnij Ctrl+C w jej oknie terminala.

Krok 2: Wykonaj kopię bieżącej instalacji

W katalogu instalacyjnym digna zmień nazwy pliku wykonywalnego i folderu dashboardu bieżącej instalacji, aby nowe wydanie mogło zostać wdrożone obok nich:

cd /opt/digna
sudo mv digna digna_old
sudo mv dashboard dashboard_old

Zachowaj digna_old do czasu zweryfikowania aktualizacji, a dashboard_old, dopóki nie odtworzysz z niego swoich plików konfiguracyjnych (patrz krok 4). Potem możesz usunąć oba.

Aktualizacja z wydania wcześniejszego niż 2026.06

Zamiast pliku wykonywalnego zmień nazwy folderów dignabackend i dignacli: sudo mv dignabackend dignabackend_old i sudo mv dignacli dignacli_old. Żaden z nich nie jest używany przez wydanie 2026.11.

Krok 3: Rozpakuj i wdróż nową wersję

  1. Rozpakuj nowy plik ZIP instalacji digna
  2. Skopiuj nowy plik wykonywalny digna oraz folder dashboard do katalogu instalacyjnego
  3. Przywróć bit wykonywalności i własność konta usługi:
sudo chmod +x /opt/digna/digna
sudo chown -R digna:digna /opt/digna

Ważne

Ani config.toml, ani dashboard/dashboard_config.toml nigdy nie są dołączane do pliku ZIP instalacji — zespół digna nigdy nie dostarcza żadnego z tych plików. Aktualizacja nie narusza więc Twojej istniejącej konfiguracji, a kopie w folderach *_old o zmienionych nazwach są jedynymi, jakie posiadasz.

Krok 4: Przywróć pliki konfiguracyjne

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

Wydanie 2026.11 nie wymaga żadnych zmian w config.toml: plik, który działa z wydaniem 2026.06, działa nadal. Dwie zmiany są opcjonalne:

  • Dodaj sekcję [duckdb], jeśli połączenia z bazami danych mają korzystać z digna Engine, a jego wartości domyślne nie pasują do Twojego hosta.
  • Pomiń sekcję [app], jeśli reverse proxy serwuje dashboard i backend pod jednym originem.

Ustawienia, których digna nie odczytuje

Wcześniejsze wersje tego przewodnika pokazywały niektóre ustawienia, których digna nie odczytuje. Nie mają one żadnego efektu, a config check wymienia je w kroku 6 w pozycji Unknown keys. Usuń je lub popraw:

  • DIGNA_SCHEDULER_MAX_DELAY, DIGNA_CLEANUP_TIME, digna_COOKIE_PATH, digna_COOKIE_SAME_SITE, digna_APP_CORS_ALLOW_METHODS, digna_APP_CORS_ALLOW_HEADERS i digna_LOGGING_BACKUP_COUNT nie istnieją. Usuń je.
  • W nazwach ustawień rozróżniana jest wielkość liter. digna odczytuje DIGNA_REPO_HOST, a nie digna_REPO_HOST. Zapisuj każdą nazwę wielkimi literami, tak jak w Konfiguracji backendu.

Logowanie jednokrotne: zachowaj [[oidc_clients]]

digna odczytuje dostawców logowania jednokrotnego jako listę wpisów [[oidc_clients]], z których każdy ma własny DIGNA_OIDC_KEY. Jeśli zmieniłeś dostawców na sekcje [oidc_clients.<key>], jak pokazywała wcześniejsza wersja tego przewodnika, przywróć poprzednią formę. config check zgłasza OIDC config(s) jako FAILED, dopóki ta forma pozostaje na miejscu:

[[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'

Powtórz wpis dla każdego dostawcy i zadbaj, aby każdy DIGNA_OIDC_KEY odpowiadał wartości key w dashboard_config.toml. Dotyczy to wyłącznie instalacji korzystających z logowania jednokrotnego.

Krok 5: Przeładuj serwer WWW

Dashboard to zestaw plików statycznych, więc serwer WWW — i przeglądarka — mogą nadal serwować poprzednią wersję. Przeładuj lub zrestartuj serwer WWW, który udostępnia folder dashboard, a następnie przeładuj stronę z wymuszonym odświeżeniem (Ctrl+F5).

Krok 6: Sprawdź konfigurację

Upewnij się, że config.toml jest kompletny, zanim dotkniesz repozytorium:

./digna config check

Każda sekcja musi zgłosić OK. Popraw wszystko, co zostało zgłoszone jako FAILED, usuń klucze wymienione w pozycji Unknown keys i uruchom polecenie ponownie przed kontynuowaniem.

Krok 7: Wymień plik licencji

Plik licencji zwykle przechodzi bez zmian z jednego wydania do następnego. Wydanie 2026.11 jest wyjątkiem: dodaje dwa licencjonowane moduły, digna Data Reconciliation i digna Agentic, a licencja wystawiona przed wydaniem 2026.11 ich nie zawiera. Skopiuj plik license.toml dostarczony przez zespół digna dla wydania 2026.11 do katalogu instalacyjnego, zastępując stary:

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

Nie zachowuj poprzedniej licencji

Z poprzednią licencją digna nadal się uruchamia, ale digna Data Reconciliation i digna MCP Server pozostają wyłączone. Każde polecenie, które sprawdza licencję — user, inspection, repo — przerywa działanie, zanim dotknie repozytorium, jeśli kontrola się nie powiedzie. Sprawdź nową licencję, zanim przejdziesz dalej:

./digna license check

Krok 8: Zaktualizuj schemat repozytorium

W katalogu instalacyjnym digna uruchom:

cd /opt/digna
./digna repo upgrade

Wydanie 2026.11 zarządza schematem repozytorium za pomocą wersjonowanych migracji. Pierwsza aktualizacja z wcześniejszego wydania doprowadza schemat do ostatniej wersji poprzedniego mechanizmu, zapisuje ją jako punkt wyjścia, a następnie stosuje migracje wydania 2026.11. Kończy się komunikatem:

✅ Baseline migration recorded as applied.
✅ Repo schema 'dignarepo' is up to date.

Wszystkie istniejące dane zostają zachowane. Aby w dowolnym momencie sprawdzić stan repozytorium, uruchom ./digna repo check: polecenie pokazuje ostatnią zastosowaną migrację oraz migracje oczekujące.

digna nie uruchamia się na nieaktualnym repozytorium

Od wydania 2026.11 serwer odmawia uruchomienia, dopóki repozytorium wymaga aktualizacji, i informuje o tym, na przykład:

Error: Legacy repo version 3.0.2 installed. Use the 'digna repo upgrade' command to upgrade it.

Uruchom repo upgrade, zanim uruchomisz serwer lub usługę.

Krok 9: Uruchom ponownie usługi

Jeśli digna działa jako usługa systemd:

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

Jeśli uruchamiasz ręcznie, zrestartuj serwer:

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

Jeśli korzystasz z nginx lub Apache, przeładuj odpowiedni serwer WWW:

sudo systemctl reload nginx
sudo systemctl restart apache2

W rodzinie RHEL ponownie nadaj etykiety SELinux, jeśli katalog dashboard został zastąpiony:

sudo restorecon -Rv /opt/digna/dashboard

Krok 10: Zweryfikuj aktualizację

  1. Potwierdź wydanie nowego pliku wykonywalnego:

    ./digna version
    

    Pierwszy wiersz musi brzmieć Release: 2026.11.

  2. Otwórz dashboard digna i sprawdź, czy interfejs ładuje się poprawnie.

  3. Sprawdź logi serwera pod kątem błędów:

    sudo journalctl -u digna -n 100
    
  4. Przetestuj połączenia z bazami danych — zobacz Testowanie połączenia. Po aktualizacji z wydania wcześniejszego niż 2026.06 najpierw przestaw na ODBC każde połączenie, które jeszcze z niego nie korzystało.

Aby zacząć pracę z nowymi modułami, zobacz digna Data Reconciliation, Podłączanie agenta AI w przypadku digna MCP Server oraz Lokalizacja profilowania w przypadku digna Engine.