digna रिलीज 2026.06 के लिए Linux स्थापना मार्गदर्शिका¶
रिलीज़: 2026.06
अंतिम अपडेट: 5 सितंबर, 2026
सामग्री सूची¶
- परिचय
- सिस्टम आवश्यकताएँ
- पूर्व-स्थापन सेटअप
- PostgreSQL सर्वर सेटअप
- वेब सर्वर विन्यास
- प्रारम्भिक स्थापना
- बैकएंड कॉन्फ़िगरेशन
- डैशबोर्ड कॉन्फ़िगरेशन
- digna को systemd सेवा के रूप में चलाना
- नए रिलीज़ में अपग्रेड करना
परिचय¶
digna के बारे में¶
digna एक व्यापक AI-संचालित प्लेटफ़ॉर्म है जो वेयरहाउस, लेक्स और लेकहाउस जैसे विभिन्न डेटा वातावरणों में डेटा गुणवत्ता प्रबंधन को अनुकूलित करने के लिए डिज़ाइन किया गया है। यह उच्च मात्रा में स्केलेबल और अनुकूलनीय है और ऑटोमेशन, वास्तविक समय निगरानी और अनोमली डिटेक्शन के माध्यम से आधुनिक डेटा चुनौतियों को संबोधित करता है।
digna दो मुख्य घटकों से मिलकर बनता है:
- digna: एप्लिकेशन का केंद्र, जो डेटा संसाधित करने और गुणवत्ता जाँच चलाने के लिए ज़िम्मेदार है। यह बैकएंड और कमांड लाइन इंटरफ़ेस को एक ही निष्पादन योग्य फ़ाइल में जोड़ता है और पिछली रिलीज़ के अलग-अलग प्रोग्राम
dignabackendतथाdignacliकी जगह लेता है। - dignadashboard: एक वेब-आधारित इंटरफ़ेस जो वेब सर्वर पर होस्ट किया जाता है और digna प्लेटफ़ॉर्म के साथ इंटरैक्ट करने व डेटा गुणवत्ता मेट्रिक्स को विज़ुअलाइज़ करने का यूजर-फ्रेंडली तरीका प्रदान करता है।
रिलीज 2026.06 में क्या नया है¶
यह रिलीज़ डेटा ऑब्ज़र्वेबिलिटी क्षमताओं को सीधे आपके कोड में लाती है, जिससे डेवलपर्स स्रोत पर ही डेटा गुणवत्ता की निगरानी कर सकते हैं। पूर्ण विवरण के लिए देखें release notes।
Windows या macOS के लिए मार्गदर्शिका चाहिए?¶
यह गाइड Linux को कवर करता है। अन्य प्लेटफार्मों के लिए देखें Windows Installation Guide या macOS Installation Guide।
यह गाइड किस वितरण के लिए है?¶
निर्देश दोनों सामान्य सर्वर परिवारों के लिए लिखे गए हैं। जहाँ फर्क होता है, दोनों कमान्ड दिए गए हैं:
- 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 या उच्चतर |
| वेब सर्वर | nginx, Apache httpd, या समकक्ष |
डेटाबेस इंस्टॉलेशन विकल्प¶
यदि PostgreSQL पहले से इंस्टॉल है: आप अपने मौजूदा PostgreSQL सर्वर में digna के लिए नया डेटाबेस जोड़ सकते हैं।
यदि आप PostgreSQL को उसी मशीन पर इंस्टॉल कर रहे हैं जहाँ digna चलेगा:
अनुशंसित विनिर्देश
- मेमोरी: 32 GB RAM (16 GB की बजाय)
- डिस्क स्थान: 50 GB उपलब्ध स्टोरेज (10 GB की बजाय)
ये उच्च विनिर्देश digna और PostgreSQL डेटाबेस दोनों को एक साथ चलाने के लिए सहायक हैं।
अपना वितरण और आर्किटेक्चर कैसे जाँचें¶
इस गाइड में कई कमान्ड Debian और RHEL परिवारों के बीच अलग हैं। यह जाँचने के लिए चलाएँ:
ID=ubuntuयाID=debian—aptकमान्ड का उपयोग करें।ID=rhel,rocky,almalinuxयाfedora—dnfकमान्ड का उपयोग करें।x86_64याaarch64— उस आर्किटेक्चर का नाम जिसका इंस्टॉलेशन पैकेज आपको चाहिए।
पूर्व-स्थापन सेटअप¶
digna स्थापित करने से पहले सुनिश्चित करें कि दो प्रमुख पूर्वापेक्षाएँ मौजूद हैं:
- PostgreSQL सर्वर – गणना किए गए मेट्रिक्स और प्रदर्शन डेटा संग्रहीत करने के लिए
- वेब सर्वर – digna Dashboard को होस्ट करने के लिए
यदि ये कंपोनेंट पहले से सेटअप नहीं हैं, तो उन्हें इंस्टॉल और कॉन्फ़िगर करने के लिए नीचे दिए गए सेक्शन का पालन करें।
पैकेज इंडेक्स रिफ्रेश करना¶
कुछ भी इंस्टॉल करने से पहले अपने पैकेज लिस्ट अपडेट करें:
नोट
इस गाइड में जोड़ी में दी गई पहली कमान्ड Debian परिवार के लिए है और दूसरी RHEL परिवार के लिए। केवल वही कमान्ड चलाएँ जो आपके सिस्टम से मेल खाती हो।
PostgreSQL सर्वर सेटअप¶
यदि आपके पास पहले से PostgreSQL है¶
यदि PostgreSQL स्थानीय मशीन पर पहले से इंस्टॉल और चल रहा है या आप किसी मैनेज्ड रिमोट PostgreSQL सर्वर का उपयोग कर रहे हैं, तो आप अगले सेक्शन पर जा सकते हैं।
PostgreSQL इंस्टॉल करना¶
चरण 1: सर्वर पैकेज इंस्टॉल करें¶
टिप
वितरण के पैकेज वर्तमान PostgreSQL रिलीज़ से पीछे हो सकते हैं। यदि आपको किसी विशिष्ट नए संस्करण की आवश्यकता है, तो आधिकारिक PostgreSQL apt या yum रिपोजिटरी का उपयोग करें।
चरण 2: डेटाबेस क्लस्टर इनिशियलाइज़ करें¶
Debian परिवार पर पैकेज क्लस्टर स्वतः बना देता है और शुरू कर देता है — अगले चरण पर जाएँ।
RHEL परिवार पर क्लस्टर को स्पष्ट रूप से बनाया जाना चाहिए:
चरण 3: सेवा शुरू और सक्षम करें¶
यह PostgreSQL को तुरंत शुरू कर देता है और बूट पर ऑटो स्टार्ट के लिए कॉन्फ़िगर कर देता है।
चरण 4: इंस्टॉलेशन सत्यापित करें¶
आपको PostgreSQL का वर्ज़न और active (running) सेवा दिखना चाहिए।
चरण 5: सर्वर से कनेक्ट करें¶
एक Linux PostgreSQL पैकेज postgres सिस्टम अकाउंट बनाता है जो क्लस्टर का मालिक होता है। इसके माध्यम से कनेक्ट करें:
नोट — Linux यहाँ Windows से अलग है
Windows इंस्टॉलर सेटअप के दौरान postgres सुपरयूज़र के लिए पासवर्ड सेट करने के लिए कहता है। Linux पैकेज ऐसा नहीं करते। इसके बजाय लोकल कनेक्शन्स peer authentication द्वारा प्रमाणीकृत होती हैं: postgres ऑपरेटिंग-सिस्टम उपयोगकर्ता को बिना पासवर्ड के postgres डेटाबेस उपयोगकर्ता के रूप में कनेक्ट करने की अनुमति होती है।
इसलिए ऊपर दिया गया कमान्ड sudo -u postgres का उपयोग करता है। digna backend TCP के ऊपर उपयोगकर्ता नाम और पासवर्ड के साथ कनेक्ट करता है, इसलिए आप Initial Installation में एक स्पष्ट digna उपयोगकर्ता बनाएँगे।
चरण 6: पोर्ट की पुष्टि करें¶
डिफ़ॉल्ट PostgreSQL पोर्ट 5432 है। यह पुष्टि करने के लिए कि आपका सर्वर किस पोर्ट पर सुन रहा है:
मान नोट कर लें — आपको इसे digna backend कॉन्फ़िगरेशन में चाहिए होगा।
चरण 7: digna उपयोगकर्ता के लिए पासवर्ड प्रमाणीकरण सक्षम करें¶
digna TCP पर digna_user के रूप में PostgreSQL से कनेक्ट करता है, जिसे peer प्रमाणीकरण के बजाय पासवर्ड प्रमाणीकरण की आवश्यकता होती है। सुनिश्चित करें कि आपका pg_hba.conf इसे अनुमति देता है।
फ़ाइल का स्थान खोजें:
इसे किसी संपादक में खोलें और पुष्टि करें कि स्थानीय 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 को रीलोड करें:
महत्वपूर्ण
यदि digna रिपोर्ट करता है FATAL: Ident authentication failed for user "digna_user" तो इसका कारण यही सेटिंग है।
चरण 8: यदि PostgreSQL किसी अन्य मशीन पर चलता है¶
यदि किसी अन्य होस्ट से कनेक्शन्स स्वीकार करना है, तो postgresql.conf में listen_addresses सेट करें और अपने नेटवर्क के लिए pg_hba.conf में एक मेल खाने वाली host लाइन जोड़ें:
फिर फ़ायरवॉल में पोर्ट खोलें और सेवा को पुनरारंभ करें:
वेब सर्वर विन्यास¶
digna को डैशबोर्ड होस्ट करने के लिए एक वेब सर्वर की आवश्यकता है। निम्न में से किसी एक विकल्प को चुनें:
- nginx — हल्का और अनुशंसित
- Apache httpd — व्यापक रूप से उपयोग किया जाने वाला विकल्प
आपको केवल इनमें से एक सर्वर इंस्टॉल और कॉन्फ़िगर करना है।
दोनों सेक्शन उन दो चीज़ों को कॉन्फ़िगर करते हैं जिन पर डैशबोर्ड निर्भर है:
- एक सिंगल-पेज-एप्लिकेशन फॉलबैक, ताकि डैशबोर्ड URL रिफ्रेश करने पर 404 न लौटे
- एक
.mdMIME टाइप, ताकि Markdown फाइलें सही ढंग से सर्व हों
nginx सेटअप¶
अवलोकन¶
nginx एक हल्का, उच्च-प्रदर्शन वेब सर्वर है जो static digna डैशबोर्ड सर्व करने के लिए उपयुक्त है।
इंस्टॉलेशन¶
nginx शुरू करना¶
इंस्टॉलेशन सत्यापित करें¶
- अपना ब्राउज़र खोलें
http://localhostपर नेविगेट करें- आपको nginx स्वागत पृष्ठ दिखाई देना चाहिए
फ़ायरवॉल खोलना¶
यदि सर्वर अन्य मशीनों से पहुँचा जाता है, तो HTTP ट्रैफ़िक की अनुमति दें:
डैशबोर्ड के लिए साइट कॉन्फ़िगर करना¶
nginx दोनों वितरण परिवारों पर अपने conf.d डायरेक्टरी में हर फ़ाइल को शामिल करता है। वहाँ digna के लिए एक समर्पित कॉन्फ़िगरेशन फ़ाइल बनाएँ:
निम्न पेस्ट करें, /opt/digna/dashboard को आपके निकाले गए 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 लौटेगा। यह nginx का वही व्यवहार है जो Windows पर IIS के URL Rewrite मॉड्यूल की आवश्यकता को पूरा करता है।
डिफ़ॉल्ट साइट अक्षम करें¶
किसी पोर्ट के लिए केवल एक सर्वर ब्लॉक default_server हो सकता है। Debian परिवार पर पैकेज्ड डिफ़ॉल्ट को हटाएँ ताकि यह टकराव न करे:
RHEL परिवार पर /etc/nginx/nginx.conf के अंदर server { ... } ब्लॉक को कमेंट या डिलीट करें।
कॉन्फ़िगरेशन लागू करें¶
सिनटैक्स त्रुटियों के लिए कॉन्फ़िगरेशन परीक्षण करें, फिर nginx रीलोड करें:
Apache httpd सेटअप¶
अवलोकन¶
Apache httpd हर समर्थित वितरण के डिफ़ॉल्ट रिपॉज़िटरीज़ में उपलब्ध है। पैकेज Debian परिवार पर apache2 नाम से और RHEL परिवार पर httpd नाम से आता है।
इंस्टॉलेशन¶
Apache शुरू करना¶
इंस्टॉलेशन सत्यापित करें¶
- अपना ब्राउज़र खोलें
http://localhostपर नेविगेट करें- आपको वितरण का डिफ़ॉल्ट Apache पेज दिखाई देना चाहिए
आवश्यक: mod_rewrite सक्षम करें¶
डैशबोर्ड को URL rewriting की आवश्यकता है।
Debian परिवार पर मॉड्यूल सक्षम करें और पुनरारंभ करें:
RHEL परिवार पर mod_rewrite डिफ़ॉल्ट रूप से लोड होता है। यह पुष्टि करें:
आवश्यक: .htaccess ओवरराइड अनुमति दें¶
अपने डॉक्यूमेंट रूट के लिए कॉन्फ़िगरेशन फ़ाइल खोलें:
अपने डॉक्यूमेंट रूट (/var/www/html दोनों परिवारों पर) को कवर करने वाले <Directory> ब्लॉक को ढूँढें और बदलें:
को:
आवश्यक: Markdown फाइलों के लिए MIME टाइप¶
इसी फ़ाइल में निम्न लाइन जोड़ें ताकि Markdown फाइलें सही ढंग से सर्व हो सकें:
महत्वपूर्ण
इस सेटिंग के बिना, .md फाइलें सही ढंग से सर्व नहीं हो सकती हैं।
कॉन्फ़िगरेशन लागू करें¶
सिनटैक्स त्रुटियों के लिए कॉन्फ़िगरेशन जांचें, फिर Apache पुनरारंभ करें:
प्रारम्भिक स्थापना¶
चरण 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;
शेल से इन्हें एक ही चरण में चलाने के लिए:
फिर postgres=# प्रॉम्प्ट पर स्टेटमेंट पेस्ट करें और बाहर निकलने के लिए \q टाइप करें।
सर्वोत्तम प्रथा
डेटाबेस उपयोगकर्ताओं के लिए मजबूत, जटिल पासवर्ड का उपयोग करें। आसानी से अनुमान लगाने योग्य क्रेडेंशियल से बचें।
चरण 2: digna इंस्टॉलेशन पैकेज निकालें¶
- आपको प्रदान किया गया digna इंस्टॉलेशन ZIP फाइल ढूँढें
- इसे अपने इच्छित इंस्टॉलेशन लोकेशन पर निकालें — उदाहरण के लिए
/opt/digna - निकाले जाने के बाद, आपको निम्न आइटम दिखाई देने चाहिए:
dashboard/— वेब डैशबोर्ड इंटरफ़ेसdigna— मुख्य executable (backend + CLI संयुक्त)
कॉन्फ़िगरेशन और लाइसेंस फ़ाइलें पैकेज में नहीं हैं
न तो config.toml और न ही dashboard/dashboard_config.toml इंस्टॉलेशन के साथ आती है — दोनों को आप स्वयं बनाते हैं, बैकएंड कॉन्फ़िगरेशन और डैशबोर्ड कॉन्फ़िगरेशन में। license.toml भी साथ नहीं आती; digna इसे अलग से उपलब्ध कराता है, जैसा कि चरण 3 में बताया गया है।
शेल से निकालने के लिए:
नोट
यदि unzip इंस्टॉल नहीं है, तो इसे जोड़ें: sudo apt install -y unzip या sudo dnf install -y unzip।
executable को runnable बनाएं¶
यह निर्भर करता है कि आर्काइव कैसे ट्रांसफर किया गया था, executable बिट extraction के दौरान सुरक्षित नहीं रह सकता। इसे स्पष्ट रूप से सेट करें:
सर्विस अकाउंट बनाएं¶
प्रोडक्शन डिप्लॉयमेंट के लिए बैकएंड को एक समर्पित अनप्रिविलेज्ड उपयोगकर्ता के रूप में चलाना अनुशंसित है:
sudo useradd --system --no-create-home --shell /usr/sbin/nologin digna
sudo chown -R digna:digna /opt/digna
नोट
RHEL परिवार पर समकक्ष शेल पाथ /sbin/nologin है।
चरण 3: लाइसेंस फ़ाइल इंस्टॉल करें¶
महत्वपूर्ण
लाइसेंस फ़ाइल इंस्टॉलेशन पैकेज में शामिल नहीं होती है और इसे digna द्वारा अलग से प्रदान किया जाएगा।
- आपको दिया गया
license.tomlफ़ाइल ढूँढें - इसे root digna इंस्टॉलेशन डायरेक्टरी में कॉपी करें (जहाँ
config.tomlऔरdignaexecutable स्थित हैं)
क्यों यह महत्वपूर्ण है: लाइसेंस फ़ाइल में आपका ग्राहक जानकारी, लाइसेंस समाप्ति तिथि, और डिजिटल सिग्नेचर होता है। इस फ़ाइल में कोई परिवर्तन न करें — किसी भी परिवर्तन से यह अमान्य हो जाएगी।
सेटअप के बाद निर्देशिका संरचना:
/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 में नाम बदलना है।
स्थान: /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 से सर्व करते हैं, तो अनुमति देने वाला origin 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 सर्वर का hostname/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 में डेटाबेस पासवर्ड प्लेन टेक्स्ट में होता है। इसकी अनुमतियाँ सीमित करें ताकि केवल सर्विस अकाउंट इसे पढ़ सके:
[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 बताता है।
| पैरामीटर | मान | नोट्स |
|---|---|---|
DIGNA_ENCRYPTION_KEY | Base64 में एन्कोड की गई कुंजी | digna रिपॉज़िटरी में संग्रहीत संवेदनशील मानों को एन्क्रिप्ट करती है |
config.toml की सुरक्षा करें
यह कुंजी एक निश्चित मान है, जो सभी digna संस्थापनों में एक समान है, और यही आपकी रिपॉज़िटरी के संवेदनशील मानों को डिक्रिप्ट करती है। config.toml तक पहुँच उसी खाते तक सीमित रखें जिससे digna चलता है, फ़ाइल को संस्करण नियंत्रण और साझा ड्राइव से बाहर रखें, और उसे हर ऐसे बैकअप से हटा दें जो रिपॉज़िटरी की तुलना में कम सुरक्षित रखा जाता है।
[logging] सेक्शन¶
यह सेक्शन लॉगिंग व्यवहार को कॉन्फ़िगर करता है:
| पैरामीटर | मान | नोट्स |
|---|---|---|
digna_LOGGING_MODE | INFO या DEBUG | प्रोडक्शन के लिए INFO, ट्रबलशूटिंग के लिए DEBUG |
digna_LOGGING_BACKUP_COUNT | 10 | रोज़ाना लॉग बैकअप रखने की संख्या |
चरण 2: कॉन्फ़िगरेशन जाँचें¶
रिपॉज़िटरी आरंभ करने से पहले जाँचें कि config.toml पूर्ण और सही ढंग से बना है। अपनी digna संस्थापन निर्देशिका में चलाएँ:
प्रत्येक सेक्शन की जाँच अलग से होती है, इसलिए एक अकेली गलती बाकी की स्थिति नहीं छिपाती:
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: रिपॉज़िटरी इनिशियलाइज़ करें¶
- एक टर्मिनल खोलें
- अपनी digna इंस्टॉलेशन डायरेक्टरी में नेविगेट करें (जहाँ
config.tomlऔरdignaexecutable स्थित हैं) - कनेक्शन टेस्ट चलाएँ:
आपको पुष्टि दिखाई देनी चाहिए कि कनेक्शन स्थापित है (रिपॉज़िटरी अभी इनिशियलाइज़ नहीं हुई है)।
नोट
Linux पर वर्तमान डायरेक्टरी आपके PATH में नहीं होती, इसलिए executable को ./digna के रूप में बुलाया जाता है न कि digna के रूप में। शॉर्ट फॉर्म हर जगह उपयोग करने के लिए, एक symbolic लिंक जोड़ें:
चरण 4: रिपॉज़िटरी स्कीमा इंस्टॉल करें¶
एक ही डायरेक्टरी में चलाएँ:
यह कमान्ड आपके PostgreSQL डेटाबेस में आवश्यक टेबल और स्कीमा इंस्टॉल करती है।
चरण 5: एक एडमिन उपयोगकर्ता बनाएं¶
- एक नई टर्मिनल विंडो खोलें
- अपनी digna इंस्टॉलेशन डायरेक्टरी में जाएँ
- निम्न कमान्ड चलाकर एक एडमिन उपयोगकर्ता बनाएँ:
उदाहरण:
इससे admin@example.com ईमेल पते और पूर्ण प्रशासनिक अधिकारों वाला एक उपयोगकर्ता बनता है।
टिप
पासवर्ड को सिंगल कोट्स में रैप करें। bash और zsh विशिष्ट कैरेक्टर्स जैसे !, $ और * का विशेष व्यवहार करते हैं, और बिना कोट किए गए पासवर्ड में ये सही तरीके से पास नहीं होंगे।
सर्वोत्तम प्रथा
ऊपरी, नीचले अक्षर, संख्याएँ और विशेष अंक मिलाकर मजबूत पासवर्ड का उपयोग करें।
चरण 6: digna सर्वर शुरू करें¶
digna इंस्टॉलेशन डायरेक्टरी में, सर्वर शुरू करें:
पैरामीटर्स: - --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 पोर्ट को फ़ायरवॉल में भी खोलें:
सर्वर टर्मिनल को व्यस्त रखता है
serve अग्रभूमि में चलता है और तब तक चलता रहता है जब तक आप इसे Ctrl+C से रोक नहीं देते। सेटअप पूरा करते समय इसे चलता रहने दें; इसके बजाय बूट पर स्वतः प्रारंभ करने के लिए देखें digna को systemd सेवा के रूप में चलाना.
डैशबोर्ड कॉन्फ़िगरेशन¶
चरण 1: डैशबोर्ड को वेब सर्वर पर डिप्लॉय करें¶
digna डैशबोर्ड अपनी कॉन्फ़िगरेशन dashboard/dashboard_config.toml से पढ़ता है। यह फ़ाइल इंस्टॉलेशन के साथ नहीं आती — आप इसे dashboard/ डायरेक्टरी में डैशबोर्ड फ़ाइलों के साथ बनाते हैं।
इसकी सामग्री सिंगल साइन-ऑन के अंतर्गत बताई गई है, और वहीं इस फ़ाइल की आवश्यकता भी होती है: इसमें वे लॉगिन विकल्प होते हैं जो डैशबोर्ड प्रदान करता है और, मल्टी-इंस्टेंस डिप्लॉयमेंट के लिए, बैकएंड कनेक्शन।
अपने वेब सर्वर का चयन करें और संबंधित डिप्लॉयमेंट स्टेप्स का पालन करें।
nginx पर डिप्लॉय करना¶
यदि आपने nginx सेटअप का पालन किया है, तो server block पहले से ही आपके dashboard फ़ोल्डर की ओर पॉइंट करता है और कॉपी करने की आवश्यकता नहीं है।
- पाथ की पुष्टि करें
/etc/nginx/conf.d/digna.confखोलें-
पुष्टि करें कि
rootआपके निकाले गएdashboardफ़ोल्डर की ओर पॉइंट करता है -
यह सुनिश्चित करें कि फ़ोल्डर पढ़ने योग्य है
-
nginx रीलोड करें
-
इंस्टॉलेशन का परीक्षण करें
- अपना ब्राउज़र खोलें
http://localhost(या आपका कॉन्फ़िगर किया गया URL) पर नेविगेट करें- आपको digna डैशबोर्ड लॉगिन पेज दिखाई देना चाहिए
Apache httpd पर डिप्लॉय करना¶
-
डैशबोर्ड को डॉक्यूमेंट रूट में कॉपी करें
-
रीराइट नियम जोड़ें
डैशबोर्ड रूट होने पर ब्राउज़र रिफ्रेश से बचने के लिए तैनात फ़ोल्डर के अंदर एक .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]
-
Apache पुनरारंभ करें
-
डैशबोर्ड तक पहुँचें
- अपना ब्राउज़र खोलें
http://localhost/dignaपर नेविगेट करें- आपको digna डैशबोर्ड लॉगिन पेज दिखाई देना चाहिए
चरण 2: SELinux (केवल RHEL परिवार)¶
RHEL, Rocky, AlmaLinux और Fedora पर SELinux डिफ़ॉल्ट रूप से enforcing होता है और यह वेब सर्वर को उसकी अपेक्षित लोकेशनों के बाहर फाइलें पढ़ने से ब्लॉक कर देगा। जाँचें कि यह सक्रिय है या नहीं:
यदि परिणाम Enforcing है और आप /opt/digna/dashboard से डैशबोर्ड सर्व कर रहे हैं, तो डायरेक्टरी को लेबल करें ताकि वेब सर्वर इसे पढ़ सके:
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 सेवा के रूप में चलाने से यह सुनिश्चित होता है कि यह:
- मशीन बूट होने पर स्वचालित रूप से शुरू हो जाए
- बैकग्राउंड में बिना खुले टर्मिनल विंडो के चले
- यदि क्रैश करे तो स्वतः पुनरारंभ हो
systemctlके माध्यम से मैनेज किया जा सके — जो कि मानक Linux सेवा प्रबंधक है
सेवा प्रबंधन फ़ाइलें¶
सभी आवश्यक फ़ाइलें digna इंस्टॉलेशन डायरेक्टरी के अंतर्गत: bin/ में स्थित हैं
उपलब्ध shell स्क्रिप्ट्स:
install_service.sh— digna को systemd के साथ रजिस्टर करता हैuninstall_service.sh— सेवा का रजिस्ट्रेशन हटाता हैstart_service.sh— रजिस्टर की गई सेवा शुरू करता हैstop_service.sh— चल रही सेवा को रोकता है
रूट अनुमतियाँ आवश्यक
सभी स्क्रिप्ट्स को sudo के साथ चलाया जाना चाहिए, क्योंकि बूट पर शुरू होने वाली सेवा रजिस्टर करने के लिए /etc/systemd/system में एक यूनिट फ़ाइल लिखी जाती है।
स्क्रिप्ट्स को executable बनाना¶
Extraction executable बिट को संरक्षित नहीं कर सकता। पहली बार उपयोग से पहले:
सेवा इंस्टॉल करना¶
-
एक टर्मिनल खोलें
-
bin फ़ोल्डर में नेविगेट करें
-
इंस्टॉलेशन स्क्रिप्ट चलाएँ
digna सर्वर अब systemd के साथ स्वचालित स्टार्टअप सक्षम करके रजिस्टर हो गया है। सेवा तुरंत शुरू नहीं होती — इसे शुरू करने के लिए अगले सेक्शन को देखें।
सेवा शुरू और रोकना¶
सेवा शुरू करने के लिए¶
- एक टर्मिनल खोलें
/opt/digna/binमें नेविगेट करें- चलाएँ:
सेवा रोकने के लिए¶
- एक टर्मिनल खोलें
/opt/digna/binमें नेविगेट करें- चलाएँ:
टिप
एप्लिकेशन फ़ाइलें अपडेट करने से पहले हमेशा सेवा को रोकें।
systemctl के साथ सेवा प्रबंधन¶
एक बार रजिस्टर हो जाने पर, सेवा को किसी भी डायरेक्टरी से मानक systemd कमांड्स से नियंत्रित किया जा सकता है:
sudo systemctl start digna
sudo systemctl stop digna
sudo systemctl restart digna
sudo systemctl status digna
सेवा सत्यापित करना¶
सुनिश्चित करने के लिए कि सेवा रजिस्टर और चल रही है:
enabled का अर्थ है सेवा बूट पर शुरू होगी; active का अर्थ है यह अभी चल रही है।
सेवा लॉग देखना¶
systemd कंसोल पर बैकएंड द्वारा लिखी गई सभी चीज़ें कैप्चर करता है। इसे पढ़ने के लिए:
समस्या उत्पन्न करते समय लाइव रूप में लॉग फॉलो करने के लिए:
टिप
यह उस समस्या का निदान करने का सबसे तेज़ तरीका है जिसमें सेवा शुरू होने के तुरंत बाद बंद हो जाती है। रिपॉज़िटरी कनेक्शन फेल्योर या गुम license.toml जैसी त्रुटियाँ यहाँ रिपोर्ट होती हैं।
सेवा को नई डायरेक्टरी में स्थानांतरित करना¶
यूनिट फ़ाइल executable के absolute पाथ को स्टोर करती है, इसलिए इंस्टॉलेशन को स्थानांतरित करने पर सेवा को फिर से रजिस्टर करना आवश्यक है:
-
वर्तमान सेवा अनइंस्टॉल करें
-
एप्लिकेशन फ़ाइलें स्थानांतरित करें
-
सेवा फिर से इंस्टॉल करें
-
सेवा शुरू करें
सेवा अनइंस्टॉल करना¶
-
चल रही सेवा को रोकें
-
सेवा अनइंस्टॉल करें
अब digna सर्वर systemd से अनरजिस्टर कर दिया गया है।
नए रिलीज़ में अपग्रेड करना¶
अपग्रेड करने से पहले¶
पहले सभी डेटाबेस कनेक्शन जाँचें
रिलीज़ 2026.06 से digna हर स्रोत तकनीक तक ODBC के माध्यम से पहुँचता है। पिछली रिलीज़ में प्रति तकनीक अलग ड्राइवर और ODBC के बीच चुनाव था, जिसे Use ODBC स्विच से तय किया जाता था। digna टीम ने केवल ODBC पर आधारित रहने का निर्णय लिया, क्योंकि एक ही मानक इंटरफ़ेस विशेष रूप से बनाए गए ड्राइवरों के समूह से अधिक देता है:
- प्रमाणीकरण — प्रमाणीकरण ODBC का हिस्सा है, इसलिए कोई कनेक्शन वह सब उपयोग कर सकता है जो उसका ड्राइवर समर्थित करता है: पासवर्ड, टोकन और PAT, Kerberos और Active Directory, MFA और ब्राउज़र-आधारित सिंगल साइन-ऑन, क्लाउड पहचान, क्लाइंट प्रमाणपत्र और TLS। नई विधियाँ digna की रिलीज़ की प्रतीक्षा किए बिना, ड्राइवर अपडेट के साथ आती हैं।
- डेटाबेस निर्माताओं द्वारा अनुरक्षित ड्राइवर — निर्माता का अपना ड्राइवर नए सर्वर संस्करणों और सुरक्षा सुधारों का अनुसरण करता है, और आप उसे digna से स्वतंत्र रूप से, अपनी सुविधा के अनुसार अपडेट कर सकते हैं।
- सब कुछ कॉन्फ़िगर करने का एक ही तरीका — हर तकनीक कुंजी/मान गुणों की एक सूची है, उसी इंटरफ़ेस, संवेदनशील मानों के उसी एन्क्रिप्शन और उसी समस्या-निवारण के साथ, न कि प्रति स्रोत अलग-अलग फ़ील्ड।
- समायोजन और पहुँच — ड्राइवर-स्तर के विकल्प जैसे टाइमआउट, TLS सेटिंग्स, प्रॉक्सी और फ़ेच आकार हर स्रोत के लिए उपलब्ध हैं, और अनुरूप ODBC ड्राइवर वाली कोई भी तकनीक जोड़ी जा सकती है, वे भी जिनके लिए digna अलग मार्गदर्शिका प्रकाशित नहीं करता।
व्यवहार में इसका अर्थ है कि Use ODBC स्विच तथा होस्ट, पोर्ट, डेटाबेस, उपयोगकर्ता और पासवर्ड के अलग फ़ील्ड अब मौजूद नहीं हैं। हर वह कनेक्शन जो पहले से ODBC का उपयोग नहीं करता, उसे ODBC में बदलना होगा — कोई स्वचालित रूपांतरण नहीं है, इसलिए अपग्रेड से पहले इसकी योजना बनाएँ:
- अपने संस्थापन में परिभाषित प्रत्येक डेटाबेस कनेक्शन की समीक्षा करें और उन्हें नोट करें जो अभी ODBC का उपयोग नहीं करते — इनमें से हर एक को फिर से कॉन्फ़िगर करना होगा।
- संबंधित ODBC ड्राइवर को digna होस्ट पर संस्थापित करें — कनेक्शन ब्राउज़र से नहीं, बल्कि उस सर्वर से खोले जाते हैं जिस पर digna बैकएंड चलता है। देखें digna होस्ट पर ODBC ड्राइवर संस्थापित करना।
- प्रभावित प्रत्येक कनेक्शन के लिए ODBC गुण तैयार रखें। तकनीक-वार मार्गदर्शिकाएँ प्रत्येक स्रोत के लिए एक परखा हुआ गुण-समूह देती हैं।
अपग्रेड के बाद प्रभावित प्रत्येक कनेक्शन को ODBC में बदलें और डैशबोर्ड से उसका परीक्षण करें — देखें डेटाबेस कनेक्शन बनाना और कनेक्शन का परीक्षण।
Databricks Legacy कनेक्शन
Databricks Legacy कनेक्टर इस रिलीज़ में हटा दिया गया है। उन कनेक्शनों को Databricks कनेक्टर पर स्थानांतरित करें।
digna रिपॉज़िटरी का बैकअप बनाना अनिवार्य है
digna को अपग्रेड करने से पहले अपने रिपॉज़िटरी (PostgreSQL) का बैकअप लें ताकि डेटा लॉस से बचा जा सके। बैकअप यह सुनिश्चित करता है कि यदि अपग्रेड के दौरान अनपेक्षित समस्याएँ आयीं तो आप रिकवर कर सकें।
शेल से बैकअप बनाने के लिए:
अपग्रेड प्रक्रिया¶
चरण 1: digna सेवा बंद करें¶
यदि digna systemd सेवा के रूप में चल रही है, तो पहले उसे बंद करें:
यदि digna foreground में चल रहा है, तो उसके टर्मिनल विंडो में Ctrl + C दबाएँ।
चरण 2: वर्तमान संस्थापन का बैकअप लें¶
अपनी digna संस्थापन निर्देशिका में वर्तमान संस्थापन के फ़ोल्डरों के नाम बदलें, ताकि नई रिलीज़ उनके साथ तैनात की जा सके:
dignabackend और dignacli अब उपयोग में नहीं हैं
रिलीज़ 2026.06 से dignabackend और dignacli की जगह एकल निष्पादन योग्य फ़ाइल digna ले लेती है, जो बैकएंड और CLI को जोड़ती है। dignabackend_old और dignacli_old को केवल तब तक रखें जब तक आप अपग्रेड की पुष्टि न कर लें — उसके बाद दोनों फ़ोल्डर हटाए जा सकते हैं। dashboard_old को तब तक रखें जब तक आप उससे अपनी कॉन्फ़िगरेशन फ़ाइलें पुनर्स्थापित न कर लें (चरण 4 देखें)।
चरण 3: नया वर्शन निकालें और डिप्लॉय करें¶
- नया digna इंस्टॉलेशन ZIP फाइल निकालें
- नई
dignaexecutable औरdashboardफ़ोल्डर को अपने इंस्टॉलेशन डायरेक्टरी में कॉपी करें - executable बिट और सर्विस अकाउंट के स्वामित्व को पुनर्स्थापित करें:
महत्वपूर्ण
न तो config.toml और न ही dashboard/dashboard_config.toml कभी भी इंस्टॉलेशन ZIP में शामिल की जाती है — digna टीम इनमें से कोई भी फ़ाइल कभी नहीं भेजती। इसलिए अपग्रेड से आपकी मौजूदा कॉन्फ़िगरेशन अप्रभावित रहती है, और नाम बदले गए *_old फ़ोल्डरों में मौजूद प्रतियाँ ही आपके पास एकमात्र प्रतियाँ हैं।
चरण 4: अपनी कॉन्फ़िगरेशन फ़ाइलें पुनर्स्थापित करें¶
रिलीज़ 2026.06 config.toml बदलती है
तीन सेटिंग्स नई और आवश्यक हैं, और दो अब उपयोग में नहीं हैं। पिछली रिलीज़ से लिया गया config.toml नई सेटिंग्स नहीं रखता, और जब तक वे अनुपस्थित हैं digna प्रारंभ नहीं होगा। अपनी मौजूदा config.toml में निम्नलिखित जोड़ें:
[base]
DIGNA_SCHEDULER_MAX_DELAY = 100
DIGNA_CLEANUP_TIME = "12:00"
[encryption]
DIGNA_ENCRYPTION_KEY = 'ycELf6IbcO55dYIZHpPv6kQv/bbnUXoIaHLh2bh1kMg='
दोनों [base] कुंजियाँ अपने मौजूदा [base] सेक्शन में जोड़ें और [encryption] को नए सेक्शन के रूप में जोड़ें। इसके बाद वे दो सेटिंग्स हटा दें जो अब उपयोग में नहीं हैं: [app] से digna_APP_HOST और digna_APP_PORT — सर्वर अब अपना पता और पोर्ट digna serve से लेता है।
प्रत्येक सेटिंग क्या करती है, यह यहाँ बताया गया है: बैकएंड कॉन्फ़िगरेशन.
सिंगल साइन-ऑन: [oidc_clients] का प्रारूप बदल गया है
रिलीज़ 2026.06 तालिकाओं की सरणी के स्थान पर प्रत्येक प्रदाता के लिए एक तालिका रखती है, जिसका नाम प्रदाता की कुंजी पर आधारित होता है। 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: वेब सर्वर रीलोड करें¶
डैशबोर्ड स्टैटिक फ़ाइलों का एक सेट है, इसलिए आपका वेब सर्वर — और ब्राउज़र — अभी भी पिछला वर्शन दिखा सकते हैं। जो भी वेब सर्वर dashboard फ़ोल्डर को होस्ट करता है, उसे रीलोड या रीस्टार्ट करें, फिर हार्ड रिफ़्रेश (Ctrl+F5) के साथ पेज रीलोड करें।
चरण 6: कॉन्फ़िगरेशन जाँचें¶
रिपॉज़िटरी को छूने से पहले पुष्टि करें कि अद्यतन config.toml पूर्ण है:
प्रत्येक सेक्शन को OK बताना चाहिए। जो कुछ भी FAILED बताया जाए उसे ठीक करें और आगे बढ़ने से पहले कमांड फिर चलाएँ।
चरण 7: लाइसेंस फ़ाइल बदलें¶
हर रिलीज़ का लाइसेंस अलग से दिया जाता है। digna टीम द्वारा इस रिलीज़ के लिए दी गई license.toml को इंस्टॉलेशन डायरेक्टरी में कॉपी करें, जिससे पुरानी फ़ाइल बदल जाए:
पिछला लाइसेंस न रखें
किसी पिछली रिलीज़ के लिए जारी की गई license.toml इस रिलीज़ को कवर नहीं करती, और लाइसेंस की जाँच करने वाला हर कमांड — user, inspection, repo — जाँच विफल होने पर रिपॉज़िटरी को छूने से पहले ही रुक जाता है। आगे बढ़ने से पहले इसे सत्यापित करें:
चरण 8: रिपॉज़िटरी स्कीमा अपग्रेड करें¶
अपनी digna इंस्टॉलेशन डायरेक्टरी में नेविगेट करें और चलाएँ:
यह मौजूद सभी डेटा को संरक्षित रखते हुए PostgreSQL स्कीमा को नवीनतम वर्शन में अपडेट कर देता है।
चरण 9: सेवाएँ पुनः प्रारंभ करें¶
यदि systemd सेवा के रूप में चल रही है:
यदि मैन्युअल रूप से चलाती हैं, तो सर्वर पुनरारंभ करें:
यदि nginx या Apache का उपयोग कर रहे हैं, तो संबंधित वेब सर्वर रीलोड करें:
RHEL परिवार पर, यदि dashboard डायरेक्टरी प्रतिस्थापित की गई थी तो SELinux लेबलिंग फिर से लागू करें:
चरण 10: अपग्रेड सत्यापित करें¶
- digna डैशबोर्ड एक्सेस करें
- सुनिश्चित करें कि इंटरफ़ेस सही ढंग से लोड हो रहा है
- किसी भी त्रुटि के लिए सर्वर लॉग्स जाँचें:
- हर उस कनेक्शन को ODBC में बदलें जो अभी तक इसका उपयोग नहीं करता था, फिर सभी कनेक्शनों का परीक्षण करें — देखें कनेक्शन का परीक्षण