Linux Installation Guide for digna Release 2026.06¶
Release: 2026.06
Senast uppdaterad: 5 september 2026
Table of Contents¶
- Introduktion
- Systemkrav
- Förberedelser inför installation
- PostgreSQL-serverinställning
- Webbserverkonfiguration
- Initial installation
- Backendkonfiguration
- Dashboardkonfiguration
- Köra digna som en systemd-tjänst
- Uppgradering till en ny release
Introduktion¶
Om digna¶
digna är en omfattande AI-driven plattform utformad för att optimera hanteringen av datakvalitet i olika datamiljöer såsom warehouses, lakes och lakehouses. Byggd för hög skalbarhet och anpassningsbarhet adresserar digna moderna datautmaningar genom automation, realtidsövervakning och anomalidetektion.
digna består av två huvudkomponenter:
- digna: applikationens kärna, ansvarig för att bearbeta data och utföra kvalitetskontroller. Den förenar backend och kommandoradsgränssnittet i en enda körbar fil och ersätter därmed de separata programmen
dignabackendochdignaclifrån tidigare releaser. - dignadashboard: Ett webbaserat gränssnitt hostat på en webbserver som ger ett användarvänligt sätt att interagera med digna-plattformen och visualisera datakvalitetsmått.
Nytt i Release 2026.06¶
Denna release för in dataobservability-funktioner direkt i din kod, vilket gör det möjligt för utvecklare att övervaka datakvalitet vid källan. Se versionsanteckningarna för fullständiga detaljer.
Letar du efter Windows eller macOS?¶
Denna guide täcker Linux. För andra plattformar, se Windows-installationsguide eller macOS-installationsguide.
Vilken distribution täcker guiden?¶
Instruktionerna är skrivna för de två vanligaste serverfamiljerna. Där de skiljer sig anges båda kommandon:
- Debian-familjen — Debian, Ubuntu. Pakethanterare:
apt. - RHEL-familjen — Red Hat Enterprise Linux, Rocky Linux, AlmaLinux, Fedora. Pakethanterare:
dnf.
Valfri modern distribution med systemd fungerar; det är främst paketnamnen och ett fåtal konfigurationsvägar som skiljer.
Systemkrav¶
Innan du börjar installationen, kontrollera att ditt system möter följande minimikrav:
| Krav | Specifikation |
|---|---|
| Operativsystem | Ubuntu 22.04 LTS eller senare, Debian 12 eller senare, RHEL 9 / Rocky 9 / AlmaLinux 9 eller senare |
| Arkitektur | x86_64 (amd64) eller arm64 |
| Init-system | systemd |
| Minne (Minimalkonfiguration) | 16 GB RAM |
| Diskutrymme | 10 GB tillgängligt lagringsutrymme |
| Databas | PostgreSQL Server 12 eller högre |
| Webbserver | nginx, Apache httpd eller motsvarande |
Alternativ för databasinstallation¶
Om PostgreSQL redan är installerat: Du kan lägga till en ny databas för digna på din befintliga PostgreSQL-server.
Om du installerar PostgreSQL på samma maskin som digna:
Rekommenderade specifikationer
- Minne: 32 GB RAM (istället för 16 GB)
- Diskutrymme: 50 GB tillgängligt lagringsutrymme (istället för 10 GB)
Dessa högre specifikationer rymmer både digna och PostgreSQL-databasen som körs samtidigt.
Kontrollera din distribution och arkitektur¶
Flera kommandon i denna guide skiljer sig mellan Debian- och RHEL-familjerna. För att se vilken du har, kör:
ID=ubuntuellerID=debian— användapt-kommandona.ID=rhel,rocky,almalinuxellerfedora— använddnf-kommandona.x86_64elleraarch64— arkitekturen för det installationspaket du behöver.
Förberedelser inför installation¶
Innan du installerar digna, säkerställ att två viktiga förutsättningar är på plats:
- PostgreSQL-server – för att lagra beräknade mått och prestandadata
- Webbserver – för att hosta digna Dashboard
Om dessa komponenter inte redan är uppsatta, följ avsnitten nedan för att installera och konfigurera dem.
Uppdatera paketindexet¶
Uppdatera paketlistorna innan du installerar något:
Obs
I hela denna guide är det första kommandot i ett par för Debian-familjen och det andra för RHEL-familjen. Kör endast det kommando som matchar ditt system.
PostgreSQL-serverinställning¶
Om du redan har PostgreSQL¶
Om PostgreSQL redan är installerat och körs lokalt eller om du använder en hanterad fjärr-PostgreSQL, kan du hoppa till nästa avsnitt: Webbserverkonfiguration.
Installera PostgreSQL¶
Steg 1: Installera serverpaketet¶
Tips
Distributionspaket kan ligga efter i versionsnumret för PostgreSQL. Om du behöver en specifik nyare version, använd den officiella PostgreSQL apt- eller yum-repositorien istället.
Steg 2: Initiera databas-klustret¶
På Debian-familjen skapar och startar paketet ett kluster automatiskt — hoppa till nästa steg.
På RHEL-familjen måste klustret skapas explicit:
Steg 3: Starta och aktivera tjänsten¶
Detta startar PostgreSQL omedelbart och konfigurerar det att starta automatiskt vid uppstart.
Steg 4: Verifiera installationen¶
Du bör se PostgreSQL-versionen och en tjänst i status active (running).
Steg 5: Anslut till servern¶
Ett Linuxpaket för PostgreSQL skapar ett systemkonto postgres som äger klustret. Anslut via det kontot:
Obs — Linux skiljer sig från Windows här
Windows-installationen ber dig att ange ett lösenord för superanvändaren postgres under installationen. Linuxpaket gör inte det. Istället autentiseras lokala anslutningar med peer-autentisering: operativsystemets användare postgres får ansluta som databasanvändaren postgres utan lösenord.
Därför används kommandot ovan med sudo -u postgres. digna-backenden ansluter över TCP med användarnamn och lösenord, så du kommer att skapa en uttrycklig digna-användare i Initial installation.
Steg 6: Bekräfta porten¶
Standardporten för PostgreSQL är 5432. För att bekräfta vilken port din server lyssnar på:
Notera värdet — du kommer att behöva det när du konfigurerar digna-backend.
Steg 7: Aktivera lösenordsautentisering för digna-användaren¶
digna ansluter till PostgreSQL över TCP som digna_user, vilket kräver lösenordsautentisering istället för peer-autentisering. Kontrollera att din pg_hba.conf tillåter detta.
Lokalisera filen:
Öppna den i en editor och se till att lokala TCP-rader använder scram-sha-256 (eller md5 på äldre servrar) istället för 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
Ladda om PostgreSQL efter ändring:
Varning
Om digna rapporterar FATAL: Ident authentication failed for user "digna_user", är denna inställning orsaken.
Steg 8: Om PostgreSQL körs på en annan maskin¶
För att acceptera anslutningar från en annan host, sätt listen_addresses i postgresql.conf och lägg till en matchande host-rad för ditt nätverk i pg_hba.conf:
Öppna sedan porten i brandväggen och starta om tjänsten:
Webbserverkonfiguration¶
digna kräver en webbserver för att hosta dashboarden. Välj ett av följande alternativ:
- nginx — lättviktigt och rekommenderas
- Apache httpd — ett ofta använt alternativ
Du behöver endast installera och konfigurera en av dessa servrar.
Båda avsnitten konfigurerar två saker som dashboarden är beroende av:
- Fallback för single-page-applikationen, så att en uppdatering av en dashboard-URL inte ger en 404
- En
.mdMIME-typ, så att Markdown-filer serveras korrekt
nginx-inställning¶
Översikt¶
nginx är en lättviktig, högpresterande webbserver väl lämpad för att servera den statiska digna-dashboarden.
Installation¶
Starta nginx¶
Verifiera installationen¶
- Öppna din webbläsare
- Navigera till
http://localhost - Du bör se nginx välkomstsida
Öppna brandväggen¶
Om servern nås från andra maskiner, tillåt HTTP-trafik:
Konfigurera en site för dashboarden¶
nginx inkluderar varje fil i sin conf.d-katalog på båda distributionsfamiljerna. Skapa en dedikerad konfigurationsfil för digna där:
Klistra in följande och ersätt /opt/digna/dashboard med den faktiska sökvägen till din uppackade dashboard-mapp:
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;
}
}
Varning
Utan try_files-direktivet returnerar en omladdning av vilken dashboard-sida som helst utöver rot-URL:en en 404. Detta är nginx-ekvivalenten till URL Rewrite-modulen som krävs av IIS på Windows.
Inaktivera standardsidan¶
Endast en serverblock kan vara default_server för en port. På Debian-familjen, ta bort det paketlevererade standardblocket så att det inte kolliderar:
På RHEL-familjen, kommentera ut eller ta bort server { ... }-blocket i /etc/nginx/nginx.conf.
Tillämpa konfigurationen¶
Testa konfigurationen för syntaxfel, och ladda sedan om nginx:
Apache httpd-inställning¶
Översikt¶
Apache httpd finns i standardförvaren för alla stödda distributioner. Paketet heter apache2 i Debian-familjen och httpd i RHEL-familjen.
Installation¶
Starta Apache¶
Verifiera installationen¶
- Öppna din webbläsare
- Navigera till
http://localhost - Du bör se distributionens standard Apache-sida
Obligatoriskt: Aktivera mod_rewrite¶
Dashboarden kräver URL-omskrivning.
På Debian-familjen, aktivera modulen och starta om:
På RHEL-familjen laddas mod_rewrite som standard. Bekräfta det:
Obligatoriskt: Tillåt .htaccess-överstyrningar¶
Öppna konfigurationsfilen för ditt dokumentrot:
Leta reda på <Directory>-blocket som täcker din dokumentrot (/var/www/html på båda familjerna) och ändra:
till:
Obligatoriskt: MIME-typ för Markdown-filer¶
I samma fil, lägg till följande rad så att Markdown-filer serveras korrekt:
Varning
Utan denna inställning kanske .md-filer inte serveras korrekt.
Tillämpa konfigurationen¶
Kontrollera konfigurationen för syntaxfel, och starta sedan om Apache:
Initial installation¶
Steg 1: Skapa digna-repositoryt¶
digna-repositoryt lagrar alla mått som digna beräknar. Det fungerar som central databas för analytiska och prestandamätningar.
Skapa schema och användare för repositoryt¶
Öppna din PostgreSQL-klient (psql, pgAdmin eller liknande) och kör följande SQL-kommandon:
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>;
Byt ut följande platshållare:
<digna_repo_schema>— Ditt önskade schemanamn (t.ex.dignarepo)<digna_repo_user>— Ditt önskade användarnamn (t.ex.digna_user)<digna_repo_password>— Ett säkert lösenord för denna användare
Exempel:
CREATE SCHEMA dignarepo;
CREATE USER digna_user WITH PASSWORD 'YourSecurePassword123!';
GRANT ALL PRIVILEGES ON SCHEMA dignarepo TO digna_user;
För att köra dessa från shell i ett steg:
Klistra sedan in satserna vid prompten postgres=# och skriv \q för att avsluta.
Bästa praxis
Använd starka, komplexa lösenord för databasanvändare. Undvik lättgissade inloggningar.
Steg 2: Packa upp digna-installationspaketet¶
- Hitta digna-installations-ZIP-filen som du fått
- Packa upp den till din önskade installationsplats — till exempel
/opt/digna - Efter uppackning bör du se följande objekt:
dashboard/— Webbgränssnittetdigna— Huvudkörbar fil (backend + CLI i ett)
Konfigurations- och licensfilerna ingår inte i paketet
Varken config.toml eller dashboard/dashboard_config.toml medföljer installationen — du skapar båda själv, i Backendkonfiguration och Dashboardkonfiguration. Inte heller license.toml medföljer; digna levererar den separat, enligt beskrivningen i steg 3.
För att packa upp från shell:
Obs
Om unzip inte är installerat, lägg till det med sudo apt install -y unzip eller sudo dnf install -y unzip.
Gör den körbara filen körbar¶
Beroende på hur arkivet överfördes kan den körbara filens rättigheter ha förlorats. Sätt den uttryckligen:
Skapa ett servicekonto¶
Det rekommenderas att köra backend som en dedikerad oprivilegierad användare i produktionsmiljö:
sudo useradd --system --no-create-home --shell /usr/sbin/nologin digna
sudo chown -R digna:digna /opt/digna
Obs
På RHEL-familjen är motsvarande shellsökväg /sbin/nologin.
Steg 3: Installera licensfilen¶
Varning
Licensfilen ingår inte i installationspaketet och kommer att tillhandahållas separat av digna.
- Hitta
license.toml-filen som du fått - Kopiera den till rotmappen för digna-installationen (där
config.tomloch den körbaradignafinns)
Varför detta är viktigt: Licensfilen innehåller din kundinformation, licensens utgångsdatum och en digital signatur. Ändra inte denna fil — ändringar gör att den ogiltigförklaras.
Katalogstruktur efter installation:
/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)
Backendkonfiguration¶
Steg 1: Skapa och redigera konfigurationsfilen¶
Filen config_template.toml medföljer din digna-installation. Du behöver bara byta namn på den till config.toml.
Plats: /opt/digna/config.toml
Öppna config.toml i en texteditor och konfigurera varje sektion nedan.
[app] Sektionen¶
Denna sektion konfigurerar digna-backendens applikationsinställningar:
[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 = ["*"]
| Parameter | Värde | Noter |
|---|---|---|
digna_APP_CORS_ALLOW_ORIGINS | Frontend-URL | Om dashboarden ligger på annan server, lägg till dess URL |
digna_APP_CORS_ALLOW_CREDENTIALS | true | Krävs för CORS med credentials |
digna_APP_CORS_ALLOW_METHODS | ["*"] | Tillåt alla HTTP-metoder |
digna_APP_CORS_ALLOW_HEADERS | ["*"] | Tillåt alla headers |
Obs
Om du serverar dashboarden från nginx eller Apache på standard HTTP-porten är origin att tillåta http://localhost — eller serverns publika URL när dashboarden nås från andra maskiner.
[repo] Sektionen¶
Denna sektion konfigurerar anslutningen till PostgreSQL-databasen:
[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!"
| Parameter | Värde | Noter |
|---|---|---|
digna_REPO_HOST | localhost eller IP | PostgreSQL-serverns host/IP |
digna_REPO_PORT | 5432 (standard) | PostgreSQL-port |
digna_REPO_DB | postgres | Databasnamn |
digna_REPO_SCHEMA | dignarepo | Schemat som skapades tidigare |
digna_REPO_USER | digna_user | Användare skapad i PostgreSQL-uppsättningen |
digna_REPO_PASSWORD | Ditt lösenord | Lösenord satt vid skapandet av schemat |
Bästa praxis
config.toml innehåller ett databaslösenord i klartext. Begränsa dess rättigheter så att endast servicekontot kan läsa den:
[base] Sektionen¶
Denna sektion innehåller säkerhets- och cookie-inställningar:
[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"
| Parameter | Värde | Noter |
|---|---|---|
DIGNA_FERNET_KEY | Krypteringsnyckel | Används för att kryptera tokens och cookies (standardnyckel medföljer) |
digna_COOKIE_DOMAIN | localhost | Matcha din frontend-domän |
digna_COOKIE_SECURE | false (lokalt) / true (produktion) | Använd true för HTTPS-anslutningar |
digna_COOKIE_HTTPONLY | true | Alltid aktiverat för säkerhet |
digna_COOKIE_SAME_SITE | lax | Hindrar CSRF-attacker |
digna_TOKEN_EXPIRES_IN | 86400 (24 timmar) | Sessionstimeout i sekunder |
digna_MAX_WORKERS | Antal CPU-kärnor - 1 | Antal parallella inspektionsjobb |
DIGNA_SCHEDULER_MAX_DELAY | 100 | Maximal fördröjning, i sekunder, som schemaläggaren får lägga till innan ett förfallet jobb startar |
DIGNA_CLEANUP_TIME | "12:00" | Tidpunkt (24-timmarsformat HH:MM) då den dagliga rensningen startar |
Tips
För att ta reda på antal CPU-kärnor på din server, kör nproc.
[encryption] Sektionen¶
Denna sektion innehåller nyckeln som används för att kryptera känsliga värden i repositoryt. Den är obligatorisk — config check rapporterar sektionen [encryption] som FAILED om nyckeln saknas.
| Parameter | Värde | Noter |
|---|---|---|
DIGNA_ENCRYPTION_KEY | Base64-kodad nyckel | Krypterar känsliga värden som lagras i digna-repositoryt |
Skydda config.toml
Den här nyckeln är ett fast värde, identiskt i alla digna-installationer, och det är den som dekrypterar de känsliga värdena i ditt repository. Begränsa config.toml till det konto som kör digna, håll filen utanför versionshantering och delade enheter, och undanta den från varje säkerhetskopia som förvaras mindre säkert än repositoryt självt.
[logging] Sektionen¶
Denna sektion konfigurerar loggningsbeteende:
| Parameter | Värde | Noter |
|---|---|---|
digna_LOGGING_MODE | INFO eller DEBUG | INFO för produktion, DEBUG för felsökning |
digna_LOGGING_BACKUP_COUNT | 10 | Antal dagliga loggbackup att behålla |
Steg 2: Validera konfigurationen¶
Kontrollera att config.toml är fullständig och korrekt uppbyggd innan du initierar repositoryt. Kör i din digna-installationskatalog:
Varje sektion valideras för sig, så att ett enskilt fel inte döljer tillståndet hos de övriga:
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
Åtgärda allt som rapporteras som FAILED och kör kommandot igen innan du fortsätter. Den fullständiga listan över alternativ finns i CLI-referensen.
Steg 3: Initiera repositoryt¶
- Öppna en terminal
- Navigera till din digna-installationskatalog (där
config.tomloch den körbaradignafinns) - Kör anslutningstestet:
Du bör se en bekräftelse på att anslutningen upprättats (själva repositoryt har ännu inte initierats).
Obs
På Linux ingår inte den aktuella katalogen i din PATH, så den körbara anropas som ./digna istället för digna. För att använda den kortare formen överallt, lägg till en symbolisk länk:
Steg 4: Installera repositoryschemat¶
I samma katalog, kör:
Detta kommando installerar nödvändiga tabeller och schema i din PostgreSQL-databas.
Steg 5: Skapa en administratörsanvändare¶
- Öppna ett nytt terminalfönster
- Navigera till din digna-installationskatalog
- Kör följande kommando för att skapa en administratörsanvändare:
Exempel:
Detta skapar en användare med e-postadressen admin@example.com och fullständiga administratörsrättigheter.
Tips
Sätt lösenordet i enkla citationstecken. bash och zsh behandlar tecken som !, $ och * speciellt, och ett oinramat lösenord som innehåller dem kommer inte att skickas korrekt.
Bästa praxis
Använd ett starkt lösenord med en blandning av versaler, gemener, siffror och specialtecken.
Steg 6: Starta digna-servern¶
I digna-installationskatalogen, starta servern med:
Parametrar: - --address — Serverns hostnamn/IP - --port — Serverns port
Du bör se startmeddelanden som bekräftar att servern körs:
INFO: Started server process [1234]
INFO: Waiting for application startup.
INFO: Application startup complete
INFO: Uvicorn running on http://localhost:8082
Tips
Om dashboarden serveras från en annan maskin än backend, öppna även API-porten i brandväggen:
Servern upptar terminalen
serve körs i förgrunden och fortsätter tills du stoppar den med Ctrl+C. Låt den vara igång medan du slutför installationen; för att i stället starta den automatiskt vid uppstart, se Köra digna som systemd-tjänst.
Dashboardkonfiguration¶
Steg 1: Distribuera dashboarden till webbservern¶
digna-dashboarden läser sin egen konfiguration från dashboard/dashboard_config.toml. Den filen medföljer inte installationen — du skapar den i katalogen dashboard/ bredvid dashboardfilerna.
Dess innehåll beskrivs under Enkel inloggning (SSO), som också är där filen behövs: den innehåller de inloggningsalternativ som dashboarden erbjuder och, vid uppsättningar med flera instanser, backend-anslutningen.
Välj din webbserver och följ motsvarande distributionssteg.
Distribuera till nginx¶
Om du följt nginx-inställningen pekar serverblocket redan mot din dashboard-mapp och ingen kopiering krävs.
- Bekräfta sökvägen
- Öppna
/etc/nginx/conf.d/digna.conf -
Verifiera att
rootpekar mot din uppackadedashboard-mapp -
Säkerställ att mappen är läsbar
-
Ladda om nginx
-
Testa installationen
- Öppna din webbläsare
- Navigera till
http://localhost(eller din konfigurerade URL) - Du bör se inloggningssidan för digna-dashboarden
Distribuera till Apache httpd¶
-
Kopiera dashboarden till dokumentroten
-
Lägg till omskrivningsregler
Skapa en .htaccess-fil i den deployade mappen så att dashboard-routes överlever en webbläsaruppdatering:
Klistra in följande:
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]
-
Starta om Apache
-
Åtkomst till dashboarden
- Öppna din webbläsare
- Navigera till
http://localhost/digna - Du bör se inloggningssidan för digna-dashboarden
Steg 2: SELinux (endast RHEL-familjen)¶
På RHEL, Rocky, AlmaLinux och Fedora är SELinux som standard i enforcing-läge och kommer att blockera webbservern från att läsa filer utanför förväntade platser. Kontrollera om det är aktivt:
Om resultatet är Enforcing och du serverar dashboarden från /opt/digna/dashboard, märk katalogen så att webbservern får läsa den:
sudo semanage fcontext -a -t httpd_sys_content_t "/opt/digna/dashboard(/.*)?"
sudo restorecon -Rv /opt/digna/dashboard
Obs
Om semanage inte finns, installera det med sudo dnf install -y policycoreutils-python-utils.
Varning
En dashboard som returnerar 403 Forbidden på en nykonfigurerad RHEL-server är nästan alltid ett SELinux-märkningsproblem snarare än ett problem med filbehörigheter. Bekräfta med sudo ausearch -m avc -ts recent.
Köra digna som en systemd-tjänst¶
Varför köra digna som en tjänst?¶
Att köra digna-backenden som en systemd-tjänst säkerställer att den:
- Startar automatiskt när maskinen startas
- Körs i bakgrunden utan ett öppet terminalfönster
- Startas om automatiskt om den kraschar
- Kan hanteras via
systemctl, standardverktyget för Linux-tjänster
Tjänsthanteringsfiler¶
Alla nödvändiga filer finns i digna-installationskatalogen under: bin/
Följande shell-skript finns tillgängliga:
install_service.sh— Registrerar digna med systemduninstall_service.sh— Avregistrerar tjänstenstart_service.sh— Startar den registrerade tjänstenstop_service.sh— Stoppar den körande tjänsten
Root-privilegier krävs
Alla skript måste köras med sudo, eftersom registrering av en tjänst som startar vid boot skriver en enhetsfil till /etc/systemd/system.
Gör skripten körbara¶
Uppackning bevarar kanske inte exekveringsrättigheterna. Innan första användning:
Installera tjänsten¶
-
Öppna en terminal
-
Gå till bin-mappen
-
Kör installationsskriptet
digna-servern är nu registrerad i systemd med automatisk start aktiverad. Tjänsten startar dock inte omedelbart — se nästa avsnitt för att starta den.
Starta och stoppa tjänsten¶
För att starta tjänsten¶
- Öppna en terminal
- Navigera till
/opt/digna/bin - Kör:
För att stoppa tjänsten¶
- Öppna en terminal
- Navigera till
/opt/digna/bin - Kör:
Tips
Stoppa alltid tjänsten innan du uppdaterar applikationsfiler.
Hantera tjänsten med systemctl¶
När den är registrerad kan tjänsten även kontrolleras med standard systemd-kommandon från valfri katalog:
sudo systemctl start digna
sudo systemctl stop digna
sudo systemctl restart digna
sudo systemctl status digna
Verifiera tjänsten¶
För att bekräfta att tjänsten är registrerad och körs:
enabled betyder att tjänsten startar vid boot; active betyder att den körs nu.
Visa tjänstens loggar¶
systemd fångar allt som backend skriver till konsolen. För att läsa dem:
För att följa loggen live medan du reproducerar ett problem:
Tips
Detta är det snabbaste sättet att diagnostisera en tjänst som startar och omedelbart stannar. En repository-anslutningsfel eller en saknad license.toml rapporteras här.
Flytta tjänsten till en ny katalog¶
Enhetsfilen lagrar den absoluta sökvägen till den körbara filen, så att flytta installationen kräver att tjänsten registreras om:
-
Avinstallera den nuvarande tjänsten
-
Flytta applikationsfilerna
-
Installera om tjänsten
-
Starta tjänsten
Avinstallera tjänsten¶
-
Stoppa den körande tjänsten
-
Avinstallera tjänsten
digna-servern är nu avregistrerad från systemd.
Uppgradering till en ny release¶
Innan du uppgraderar¶
Verifiera alla databasanslutningar först
Från Release 2026.06 når digna varje källteknologi via ODBC. Tidigare releaser erbjöd ett val mellan en teknikspecifik drivrutin och ODBC, via omkopplaren Use ODBC. digna-teamet har valt att bygga enbart på ODBC, eftersom ett enda standardiserat gränssnitt ger mer än en uppsättning skräddarsydda drivrutiner:
- Autentisering — autentisering är en del av ODBC, så en anslutning kan använda allt som dess drivrutin stöder: lösenord, tokens och PAT:ar, Kerberos och Active Directory, MFA och webbläsarbaserad enkel inloggning, molnidentiteter, klientcertifikat och TLS. Nya metoder kommer med en uppdatering av drivrutinen i stället för att vänta på en digna-release.
- Drivrutiner som underhålls av databasleverantörerna — leverantörens egen drivrutin följer nya serverversioner och säkerhetsfixar, och du kan uppdatera den enligt ditt eget schema, oberoende av digna.
- Ett enda sätt att konfigurera allt — varje teknik är en lista med nyckel/värde-egenskaper, med samma gränssnitt, samma kryptering av känsliga värden och samma felsökning, i stället för olika fält per källa.
- Finjustering och räckvidd — drivrutinsalternativ som timeouts, TLS-inställningar, proxyservrar och hämtningsstorlekar är tillgängliga för varje källa, och varje teknik med en kompatibel ODBC-drivrutin kan anslutas, även sådana som digna inte publicerar någon egen guide för.
I praktiken innebär detta att omkopplaren Use ODBC och de separata fälten för värd, port, databas, användare och lösenord inte längre finns. Varje anslutning som inte redan använder ODBC måste läggas om till ODBC — det finns ingen automatisk konvertering, så planera för detta före uppgraderingen:
- Gå igenom varje databasanslutning som är definierad i din installation och notera vilka som ännu inte använder ODBC — var och en av dem måste konfigureras om.
- Installera motsvarande ODBC-drivrutin på digna-värden — anslutningar öppnas från den server som kör digna-backend, inte från webbläsaren. Se Installera ODBC-drivrutinen på digna-värden.
- Ha ODBC-egenskaperna redo för varje berörd anslutning. Teknikguiderna listar en beprövad uppsättning egenskaper per källa.
Efter uppgraderingen lägger du om varje berörd anslutning till ODBC och testar den från dashboarden — se Skapa en databasanslutning och Testa en anslutning.
Databricks Legacy-anslutningar
Databricks Legacy-anslutaren har tagits bort i denna release. Migrera dessa anslutningar till Databricks-anslutaren.
Det är obligatoriskt att skapa en backup av digna-repositoryt
Innan du uppgraderar digna, säkerhetskopiera ditt repository (PostgreSQL) för att skydda mot dataförlust. En backup säkerställer att du kan återställa om uppgraderingen stöter på oväntade problem.
För att skapa en backup från shell:
Uppgraderingsprocess¶
Steg 1: Stoppa digna-tjänsten¶
Om digna körs som en systemd-tjänst, stoppa den först:
Om digna körs i förgrunden, tryck Ctrl + C i dess terminalfönster.
Steg 2: Säkerhetskopiera nuvarande installation¶
Byt namn på mapparna i din nuvarande installation i digna-installationskatalogen, så att den nya releasen kan distribueras vid sidan av dem:
dignabackend och dignacli används inte längre
Från Release 2026.06 ersätts dignabackend och dignacli av den enda körbara filen digna, som förenar backend och CLI. Behåll dignabackend_old och dignacli_old bara tills du har verifierat uppgraderingen — därefter kan du ta bort båda mapparna. Behåll dashboard_old tills du har återställt dina konfigurationsfiler från den (se steg 4).
Steg 3: Packa upp och distribuera ny version¶
- Packa upp den nya digna-installations-ZIP-filen
- Kopiera den nya
digna-körbaren ochdashboard-mappen till din installationskatalog - Återställ körbarhetsbit och ägarskap för servicekontot:
Varning
Varken config.toml eller dashboard/dashboard_config.toml ingår någonsin i installations-ZIP:en — digna-teamet levererar aldrig någon av filerna. Din befintliga konfiguration påverkas därför inte av uppgraderingen, och kopiorna i de omdöpta *_old-mapparna är de enda du har.
Steg 4: Återställ dina konfigurationsfiler¶
Release 2026.06 ändrar config.toml
Tre inställningar är nya och obligatoriska, och två används inte längre. En config.toml som har följt med från en tidigare release saknar de nya inställningarna, och digna startar inte så länge de saknas. Lägg till följande i din befintliga config.toml:
[base]
DIGNA_SCHEDULER_MAX_DELAY = 100
DIGNA_CLEANUP_TIME = "12:00"
[encryption]
DIGNA_ENCRYPTION_KEY = 'ycELf6IbcO55dYIZHpPv6kQv/bbnUXoIaHLh2bh1kMg='
Lägg till de två [base]-nycklarna i din befintliga [base]-sektion och lägg till [encryption] som ny sektion. Ta sedan bort de två inställningar som inte längre används, digna_APP_HOST och digna_APP_PORT, från [app] — servern hämtar nu adress och port från digna serve.
Vad varje inställning gör beskrivs i Backend-konfiguration.
Enkel inloggning: formatet för [oidc_clients] har ändrats
Release 2026.06 ersätter arrayen av tabeller med en tabell per leverantör, namngiven efter leverantörsnyckeln. DIGNA_OIDC_KEY är borta — nyckeln ingår nu i sektionsrubriken.
Före:
[[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'
Efter:
[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'
Upprepa sektionen för varje leverantör och håll varje nyckel identisk med key i dashboard_config.toml. digna config check rapporterar oidc_clients som FAILED så länge den gamla formen finns kvar. Endast installationer som använder enkel inloggning berörs.
Steg 5: Ladda om webbservern¶
Dashboarden är en uppsättning statiska filer, så din webbserver — och webbläsaren — kan fortfarande leverera den tidigare versionen. Ladda om eller starta om den webbserver som är värd för mappen dashboard och ladda sedan om sidan med en hård uppdatering (Ctrl+F5).
Steg 6: Validera konfigurationen¶
Kontrollera att den uppdaterade config.toml är fullständig innan du rör repositoryt:
Varje sektion måste rapportera OK. Åtgärda allt som rapporteras som FAILED och kör kommandot igen innan du fortsätter.
Steg 7: Ersätt licensfilen¶
Varje release licensieras separat. Kopiera den license.toml som digna-teamet tillhandahållit för denna release till installationskatalogen och ersätt den gamla:
Behåll inte den tidigare licensen
En license.toml som utfärdats för en tidigare release täcker inte den här, och varje kommando som kontrollerar licensen — user, inspection, repo — avbryts innan det rör repositoryt när kontrollen misslyckas. Verifiera den innan du går vidare:
Steg 8: Uppgradera repositoryschemat¶
Navigera till din digna-installationskatalog och kör:
Detta uppdaterar PostgreSQL-schemat till senaste versionen samtidigt som all befintlig data bevaras.
Steg 9: Starta om tjänsterna¶
Om du kör som systemd-tjänst:
Om du kör manuellt, starta servern igen:
Om du använder nginx eller Apache, ladda om respektive webbserver:
På RHEL-familjen, återapplicera SELinux-märkningen om dashboard-katalogen ersattes:
Steg 10: Verifiera uppgraderingen¶
- Gå till digna-dashboarden
- Verifiera att gränssnittet laddar korrekt
- Kontrollera serverloggarna efter eventuella fel:
- Lägg om varje anslutning som ännu inte använde ODBC till ODBC och testa sedan alla anslutningar — se Testa en anslutning