HRConvert2 के साथ अपना फाइल कन्वर्टर कैसे होस्ट करें

फाइल कन्वर्टर को self-host क्यों करें

एक self-hosted फाइल कन्वर्टर फाइल को आपकी अपनी डिस्क पर रखता है। इसे चलाने का यही एकमात्र कारण है। एक मुफ्त कन्वर्टर साइट फाइल को अपलोड कर लेती है और आपको यह जानने का कोई तरीका नहीं देती कि बाद में उसका क्या हुआ। जब फाइल एक हस्ताक्षरित क्लाइंट अनुबंध या स्कैन किया हुआ मेडिकल रिकॉर्ड हो, तो अपलोड करना ही एक सुरक्षा घटना (incident) बन जाता है। HRConvert2 एक ड्रैग-एंड-ड्रॉप फाइल कन्वर्जन सर्वर है जिसे PHP में लिखा गया है और यह GPLv3 के तहत लाइसेंस प्राप्त है। इसका 3.7.4 वर्ज़न 18 अगस्त 2026 को रिलीज़ किया गया था और प्रोजेक्ट 488 समर्थित फॉर्मेट्स का दावा करता है।

इसमें कोई डेटाबेस, कोई अकाउंट और कोई कुकीज़ नहीं हैं। एक उपयोगकर्ता का मतलब एक अस्थायी डायरेक्टरी है। प्रत्येक कन्वर्जन एक स्थानीय कमांड लाइन टूल द्वारा किया जाता है: डॉक्यूमेंट्स के लिए LibreOffice, ऑडियो और वीडियो के लिए FFmpeg, इमेज के लिए ImageMagick, ऑप्टिकल कैरेक्टर रिकग्निशन (OCR) के लिए Tesseract, और बाकी के लिए छोटे टूल्स की एक लंबी श्रृंखला। HRConvert2 एक अपलोड पेज, पाइपलाइन और उनके चारों ओर की सफाई (cleanup) प्रक्रिया है।

यह एक फाइल को एक फॉर्मेट से दूसरे फॉर्मेट में बदलता है। यह ब्राउज़र ऑफिस सुइट नहीं है, इसलिए यदि आप चाहते हैं कि लोग टैब में डॉक्यूमेंट्स एडिट करें, तो इसके बजाय self-hosted OnlyOffice और Collabora की तुलना करें। यह स्टोरेज भी नहीं है। कनवर्ट किया गया आउटपुट डिलीट करने के लिए होता है, इसलिए यदि फाइलों को कहीं सुरक्षित रखने की आवश्यकता है, तो वह काम एक self-hosted फाइल मैनेजर का है।

आवश्यकताएं

Debian या Ubuntu, Apache 2.4, PHP 8 या बाद का संस्करण, और bubblewrap की आवश्यकता है। Bubblewrap (bwrap) एक sandbox है और यह अनिवार्य है: यदि सर्वर sandbox नहीं बना पाता है, तो वह बिना sandbox के चलने के बजाय conversion करने से मना कर देता है। Upstream README के अनुसार Raspberry Pi Model B+ पर्याप्त है, जो PHP भाग के लिए सही है। Converter binaries आपके वास्तविक हार्डवेयर बजट को निर्धारित करती हैं, जिसका विवरण आगे दिया गया है।

इसे सेटअप करने के दो तरीके हैं। Docker image आज रात ही काम करने लगती है। Apache और PHP का इंस्टॉलेशन एक शाम का समय लेता है और आपको स्पष्ट रूप से दिखाता है कि सिस्टम पर क्या चल रहा है।

इसे आज रात Docker के साथ चलाएं

इस image में सभी converter binaries शामिल हैं, इसलिए यह काफी बड़ी है: अगस्त 2026 तक लगभग 3 GB। pull करने से पहले उपलब्ध disk space की जाँच करें।

यहाँ tags महत्वपूर्ण हैं। 17 अगस्त 2026 तक Docker Hub पर प्रकाशित सबसे नया tag v3.7.2 है, जबकि सबसे नया GitHub release v3.7.4 है। latest tag समय के साथ बदलता रहता है, और यह application एक बड़ा parser surface है, इसलिए एक विशिष्ट version को pin करें और सोच-समझकर upgrade करें।

docker pull zelon88/hrconvert2:v3.7.2
docker run -d --name hrconvert2 \
  -p 127.0.0.1:8080:80 \
  --security-opt seccomp=unconfined \
  zelon88/hrconvert2:v3.7.2

docker ps
curl -I http://127.0.0.1:8080/

एक सही ढंग से चल रहा container Up स्थिति में रहता है और curl का मान HTTP/1.1 200 OK आता है। जो container बार-बार restart हो रहा है, उसमें startup की समस्या है, इसलिए कुछ भी बदलने से पहले docker logs hrconvert2 पढ़ें।

दो flags बहुत महत्वपूर्ण हैं। -p 127.0.0.1:8080:80 port को केवल loopback पर publish करता है, इसलिए जब तक आप जानबूझकर इसके सामने proxy नहीं लगाते, तब तक converter तक कुछ भी नहीं पहुँचता। project का अपना उदाहरण -p 8080:80 -p 8443:443 को map करता है, जो public interface सहित हर interface पर listen करता है। --security-opt seccomp=unconfined का उपयोग इसलिए किया जाता है क्योंकि bubblewrap अपने sandbox को user namespace और mount system calls का उपयोग करके बनाता है, जिन्हें Docker का default seccomp profile block कर देता है। इस flag के बिना, conversions विफल हो जाते हैं और application आपको कारण बताता है: A sandbox blocks the required syscalls unless it was started with the correct options.

यह flag एक वास्तविक समझौता है। आप container के syscall filter को ढीला करते हैं ताकि application उसके अंदर अपना अधिक सुरक्षित sandbox बना सके। व्यवहार तय करने वाली दो settings $RequireSandbox और $RequireSandboxOnDocker हैं, जो Resources/config.php में होती हैं, और जिनका default मान क्रमशः TRUE और FALSE है। चूंकि Docker की आवश्यकता default रूप से बंद रहती है, इसलिए seccomp flag के बिना container बिना किसी sandbox के conversion कर सकता है। एक बार flag लग जाने के बाद, $RequireSandboxOnDocker = TRUE; set करें और आपको container के अंदर वापस वही सुरक्षा व्यवहार मिल जाएगा।

यदि इस machine पर Docker नया है, तो पहले daemon को set करें। VPS पर Docker चलाना में install, storage driver और Docker द्वारा अपने firewall rules लिखने के तरीके को कवर किया गया है।

इसे Apache और PHP पर इंस्टॉल करें

रिपॉजिटरी में मौजूद Documentation/INSTALLATION_INSTRUCTIONS.txt फाइल ही आधिकारिक निर्देश है, और इसमें नौ चरण शामिल हैं। इसकी प्रक्रिया इस प्रकार है। वेब सर्वर, प्रोग्रामिंग भाषा और सैंडबॉक्स से शुरुआत करें:

sudo apt update
sudo apt install -y apache2 php libapache2-mod-php php-all-dev php8.3-zip php8.3-gd bubblewrap

php8.3-* नाम Ubuntu 24.04 के अनुरूप हैं। php -v चलाएं और अपने वर्ज़न से मेल खाने वाला प्रीफिक्स उपयोग करें, क्योंकि पैकेज के नाम हर PHP रिलीज़ के साथ बदलते हैं और गलत नाम का उपयोग करने पर आपको Unable to locate package त्रुटि मिलेगी।

इसके बाद कन्वर्टर्स की बारी आती है। इसमें डॉक्यूमेंट, इमेज, ऑडियो, वीडियो और OCR शामिल हैं, जो कि अधिकांश लोगों द्वारा की जाने वाली कन्वर्जन प्रक्रिया का मुख्य हिस्सा हैं:

sudo apt install -y imagemagick ffmpeg libreoffice-common libreoffice-java-common \
  default-jre ghostscript poppler-utils libgxps-utils tesseract-ocr inkscape \
  xvfb clamav curl tar libxcb-cursor0

आर्काइव फॉर्मेट, 3D मॉडल, ई-बुक्स और बूट करने योग्य ISO इमेज के लिए इससे अधिक पैकेजों की आवश्यकता होती है, और इनमें से कुछ Ubuntu के multiverse कंपोनेंट में उपलब्ध हैं। आधिकारिक निर्देशों के चरण 3 और 5 में पूरी सूची क्रमवार दी गई है। दो डिपेंडेंसी apt पैकेज नहीं हैं: रिपॉजिटरी Documentation/Build/ffmpeg-build.sh और Documentation/Build/build-imagemagick-v7.sh प्रदान करती है, उन लोगों के लिए जिन्हें एनकोडर या ImageMagick 7 की आवश्यकता है जो Ubuntu के पैकेज में उपलब्ध नहीं है। ई-बुक सपोर्ट calibre के अपने इंस्टॉलर से आता है, जिसे निर्देशों में एक लाइन के रूप में दिया गया है:

sudo -v && wget -nv -O- https://download.calibre-ebook.com/linux-installer.sh | sudo sh /dev/stdin

यह एक वेंडर स्क्रिप्ट है जिसे root के रूप में शेल में पाइप किया जाता है। यह अपस्ट्रीम तरीका है और वैकल्पिक है: यदि आप इसे छोड़ देते हैं, तो केवल ई-बुक कन्वर्जन की सुविधा ही काम नहीं करेगी।

अगला चरण, PHP की सीमाएं। कन्वर्जन प्रक्रिया धीमी होती है और फाइलें बड़ी होती हैं, इसलिए डिफ़ॉल्ट मान बहुत कम हैं। प्रोजेक्ट इन्हें php.ini में सेट करता है:

max_execution_time = 1200
max_input_time = 90
memory_limit = 512M
post_max_size = 5000M
upload_max_filesize = 5000M
max_file_uploads = 100
display_errors = Off
zlib.output_compression = On

ये संख्याएं ऐसी मशीन के लिए हैं जिसमें पर्याप्त संसाधन हों। छोटे VPS पर जाने से पहले इन्हें कम कर लें, क्योंकि upload_max_filesize = 5000M के साथ max_file_uploads = 100 एक ऐसी रिक्वेस्ट बना सकता है जो 40 GB डिस्क की क्षमता से कहीं अधिक डेटा लिख सकती है। Apache को रीस्टार्ट करें और पुष्टि करें कि PHP ने वास्तव में क्या लोड किया है:

sudo service apache2 restart
php -i | grep -E "upload_max_filesize|post_max_size|memory_limit"

अब वर्किंग डायरेक्टरी की बारी है। Resources/config.php में $ConvertLoc इसका नाम निर्धारित करता है, और डिफ़ॉल्ट मान /DATA/HRConvert2 है। वेब सर्वर यूजर के पास इसका स्वामित्व होना चाहिए:

sudo mkdir -p /DATA/HRConvert2
sudo chmod -R 0755 /DATA/HRConvert2
sudo chown -R www-data:www-data /DATA/HRConvert2

रिलीज़ को अपने Apache डॉक्यूमेंट रूट के अंतर्गत अनपैक करें। डिफ़ॉल्ट लेआउट इसे HRProprietary/HRConvert2 फोल्डर में रखता है, और Resources/config.php में $InstLoc को उस स्थान का नाम देना होगा जहाँ आपने इसे रखा है। इसके बाद इन-बिल्ट डायग्नोस्टिक चलाएं, जो किसी यूजर द्वारा समस्या का सामना करने से पहले किसी भी गायब डिपेंडेंसी को खोजने का सबसे तेज़ तरीका है:

sudo php /path/to/HRConvert2/convertCore.php -v

-v पूरे इंस्टॉलेशन की जांच करता है: कोर वर्ज़न, डिपेंडेंसी चेक, सैंडबॉक्स स्टेटस और लैंग्वेज पैक। फाइल कन्वर्जन कमांड लाइन से समर्थित नहीं हैं, इसलिए यह आर्गुमेंट सेट केवल प्रशासनिक कार्यों के लिए है।

Ubuntu 24.04 के नए इंस्टॉलेशन पर हर कन्वर्जन विफल क्यों हो जाता है?

इसका कारण सैंडबॉक्स है, और यह पहले दिन आने वाली सबसे आम समस्या है। Ubuntu 24.04 और Debian 12 डिफ़ॉल्ट रूप से अनप्रिविलेज्ड यूजर नेमस्पेस (unprivileged user namespaces) को प्रतिबंधित करते हैं। Bubblewrap को अपना सैंडबॉक्स बनाने के लिए यूजर नेमस्पेस की आवश्यकता होती है, इसलिए bwrap शुरू नहीं हो पाता है। चूंकि एप्लिकेशन सैंडबॉक्स के बिना कन्वर्जन करने से मना कर देता है, इसलिए हर जॉब विफल हो जाती है।

इसे सीधे चेक करें:

bwrap --ro-bind / / --dev /dev /bin/true && echo sandbox ok

Permission denied एरर का मतलब है कि नेमस्पेस ब्लॉक कर दिया गया है। इसका समाधान bwrap बाइनरी के लिए एक AppArmor प्रोफाइल बनाना है। सबसे पहले ABI फाइलों की सूची देखें और मौजूद सबसे बड़ी संख्या को नोट करें:

ls /etc/apparmor.d/abi/

फिर /etc/apparmor.d/bwrap लिखें, और 4.0 को उस सबसे बड़ी संख्या से बदलें:

abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}

इसे लोड करें:

sudo apparmor_parser -r /etc/apparmor.d/bwrap

कोई आउटपुट न आने का मतलब है कि प्रोफाइल लोड हो गई है। bwrap चेक को दोबारा चलाएं, अब इसे sandbox ok प्रिंट करना चाहिए। इसके बाद कन्वर्जन काम करने लगेंगे।

एक पब्लिक कन्वर्टर इंटरनेट पर खुला एक पार्सर है

यह वह सेक्शन है जिसके लिए यह पूरी पोस्ट लिखी गई है। इंटरनेट से एक्सेस किया जा सकने वाला फाइल कन्वर्टर किसी अज्ञात व्यक्ति से कोई भी फाइल स्वीकार करता है और उसे LibreOffice, ImageMagick, FFmpeg या Ghostscript को सौंप देता है। ये बड़े C और C++ कोडबेस हैं जिनमें पार्सर बग्स का लंबा इतिहास रहा है। फाइल अपलोड करने वाला व्यक्ति फॉर्मेट चुनता है, जिसका अर्थ है कि अपलोड करने वाला व्यक्ति यह चुनता है कि कौन सा पार्सर चलेगा और उसके अंदर कौन सा कोड पाथ निष्पादित होगा।

HRConvert2 का समाधान यह है कि प्रत्येक डिपेंडेंसी को bubblewrap नेमस्पेस के अंदर चलाया जाए। प्रत्येक कन्वर्जन प्रक्रिया को केवल दो डायरेक्टरी दिखाई देती हैं: एक जिसमें इनपुट फाइल है (जिसे read-only मोड में माउंट किया जाता है) और दूसरी जिसमें आउटपुट प्राप्त होता है। नेटवर्क को अनशेयर (unshare) कर दिया जाता है, जो प्रोजेक्ट के शब्दों में, closes every URL handler in every dependency at once है। यह सुनने में जितना लगता है, उससे कहीं अधिक महत्वपूर्ण है। ImageMagick और Ghostscript दोनों ऐसे रेफरेंस स्वीकार करते हैं जो URL फेच कर सकते हैं, और इसी तरह एक कन्वर्टर सर्वर-साइड रिक्वेस्ट फोर्जरी (SSRF) टूल में बदल जाता है, जिसका उपयोग आपके नेटवर्क के अंदर से क्लाउड मेटाडेटा एंडपॉइंट तक पहुँचने के लिए किया जा सकता है। नेमस्पेस में नेटवर्क न होने के कारण, यह फेचिंग संभव नहीं हो पाती।

अस्वीकृति (refusal) इसका दूसरा महत्वपूर्ण हिस्सा है: A server that cannot build a sandbox refuses the conversion rather than quietly running without one. एक ऐसा टूल जो फेल होने पर पूरी तरह बंद हो जाता है, उस टूल से कहीं बेहतर है जो केवल लॉग में चेतावनी देता है जिसे कोई नहीं पढ़ता। यही कारण है कि ऊपर बताया गया AppArmor स्टेप वैकल्पिक नहीं है, और यही कारण है कि $RequireSandboxOnDocker को कंटेनर को एक्सपोज करने से पहले देखना आवश्यक है।

ImageMagick को policy.xml के साथ सुरक्षित करना

ImageMagick की अपनी policy file सैंडबॉक्स के नीचे एक दूसरी सुरक्षा परत है, और इसे सेट करना उचित है। Ubuntu 24.04 पर ImageMagick 6 के साथ यह फाइल /etc/ImageMagick-6/policy.xml पर स्थित है। वर्तमान में सक्रिय policy देखने के लिए यह चलाएँ:

identify -list policy

यह प्रोजेक्ट Documentation/Build/policy.xml पर एक policy प्रदान करता है जो एक अच्छा मॉडल है। यह PS, PS2, PS3, EPS, XPS और MVG कोडर्स को अस्वीकार (deny) करता है, और यह URL, HTTPS, HTTP और gs डेलिगेट्स को भी अस्वीकार करता है, जबकि PDF को अनुमति देता है:

<policy domain="coder" rights="none" pattern="PS" />
<policy domain="coder" rights="none" pattern="MVG" />
<policy domain="delegate" rights="none" pattern="URL" />
<policy domain="delegate" rights="none" pattern="gs" />
<policy domain="coder" rights="read|write" pattern="PDF" />

gs लाइन सबसे महत्वपूर्ण है। ImageMagick स्वयं PostScript को पार्स नहीं करता है। यह Ghostscript को कॉल करता है, और वही डेलिगेट वह स्थान है जहाँ ImageMagick के प्रसिद्ध रिमोट कोड निष्पादन (remote code execution) बग मौजूद होते हैं। इस डेलिगेट को अस्वीकार करने पर ImageMagick किसी भी अपलोड की गई फाइल को gs को नहीं सौंपेगा, चाहे फाइल खुद को कुछ भी बताए।

यही policy संसाधन सीमाएँ (resource caps) भी निर्धारित करती है, जिससे एक विशेष रूप से तैयार की गई इमेज को मशीन के संसाधनों को खत्म करने से रोका जाता है:

<policy domain="resource" name="memory" value="256MiB"/>
<policy domain="resource" name="map" value="512MiB"/>
<policy domain="resource" name="disk" value="1GiB"/>
<policy domain="resource" name="width" value="16KP"/>
<policy domain="resource" name="height" value="16KP"/>
<policy domain="resource" name="area" value="128MP"/>

एक डिकंप्रेशन बॉम्ब (decompression bomb) एक छोटी फाइल होती है जो बहुत बड़े आयामों (dimensions) की घोषणा करती है। width, height और area सीमाएँ आवंटन (allocation) होने से पहले ही इसे अस्वीकार कर देती हैं, जिससे कर्नल द्वारा किसी प्रक्रिया को समाप्त करने के बजाय, वह प्रक्रिया स्वयं ही बंद हो जाती है।

दूसरी दिशा में एक समस्या है। Ubuntu की डिफ़ॉल्ट policy PDF कोडर को पूरी तरह से अस्वीकार कर देती है, इसलिए एक अनछुए सिस्टम पर PDF कार्य attempt to perform an operation not allowed by the security policy 'PDF' त्रुटि के साथ विफल हो जाते हैं। यह स्ट्रिंग दर्शाती है कि policy अपना काम कर रही है। कोडर को वापस अनुमति देना आपका एक सचेत निर्णय होना चाहिए, और ऐसा करते समय आपको gs डेलिगेट को अस्वीकार ही रखना चाहिए।

छोटे VPS पर dependency chain की लागत

Idle अवस्था में, इनमें से कुछ भी महंगा नहीं है। Apache और PHP कुछ दसियों megabytes पर रहते हैं और converter binaries बिल्कुल नहीं चल रही होती हैं। पूरी लागत एक साथ तब आती है, जब कोई फाइल प्रोसेस होने के लिए आती है।

एक document conversion LibreOffice को शुरू करता है, जो एक Java runtime को शुरू करता है। एक image conversion ImageMagick को 256 MiB memory और ऊपर दी गई policy के तहत 512 MiB memory map देता है। एक video conversion FFmpeg को आपके सभी cores दे देता है, क्योंकि FFmpeg वीडियो के साथ यही करता है। project के configuration में PHP का अपना memory_limit 512M है। ये संख्याएं एक ही job के दौरान, operating system और web server के ऊपर जुड़ जाती हैं।

इसलिए 1 GB का VPS पहले वास्तविक document पर ही swap करने लगता है और फिर thrashing शुरू हो जाती है। जब memory खत्म हो जाती है, तो kernel का out of memory killer उस process को समाप्त कर देता है जिसका resident size सबसे बड़ा होता है। आमतौर पर वह soffice.bin होता है, और उपयोगकर्ता को एक conversion दिखता है जो बिना किसी उपयोगी संदेश के विफल हो गया है। कभी-कभी यह apache2 होता है, और पूरी साइट डाउन हो जाती है। बाद में इसकी पुष्टि dmesg -T | grep -i "killed process" के साथ करें।

यह benchmark के बजाय sizing मार्गदर्शन है: 4 GB RAM और दो cores एक छोटी टीम के लिए आरामदायक हैं, और 2 GB के साथ swap file तब काम करती है यदि load documents और images का हो और आप प्रतीक्षा करने के लिए तैयार हों। Swap file conversion को तेज नहीं बनाती है। यह burst को fatal होने के बजाय धीमा बना देती है, जो एक stalled page और outage के बीच का अंतर है। डिस्क को आवश्यकता से अधिक जगह दें, क्योंकि 3 GB की image, एक बड़ी upload limit और converted output मिलकर किसी भी अन्य चीज़ के खत्म होने से बहुत पहले डिस्क को भर देते हैं।

Conversions स्वभाव से bursty होते हैं। दो लोग एक ही समय पर वीडियो upload करेंगे तो वे सभी cores का उपयोग करेंगे, और अगली request उनके पीछे प्रतीक्षा करेगी। इसके सामने कोई job queue नहीं है, इसलिए आपके पास एकमात्र नियंत्रण limits का है।

डिस्क को भरने से रोकने के लिए सीमाएं निर्धारित करें

सबसे पहले PHP मानों को कम करें। 4 GB वाले साझा सर्वर के लिए upload_max_filesize = 512M, post_max_size = 512M और max_file_uploads = 20 एक उचित शुरुआती बिंदु हैं। ध्यान रखें कि max_execution_time = 1200 एक PHP अनुरोध को बीस मिनट तक चलने देता है, जिसकी आवश्यकता लंबे वीडियो रूपांतरण के लिए होती है, लेकिन इसका अर्थ यह भी है कि एक धीमा अपलोड बीस मिनट तक एक वर्कर को व्यस्त रखता है।

इसके बाद, अनुरोध के PHP तक पहुँचने से पहले, प्रॉक्सी पर आकार और दर को लागू करें:

limit_req_zone $binary_remote_addr zone=convert:10m rate=6r/m;

server {
    listen 443 ssl;
    server_name convert.example.com;

    client_max_body_size 512M;
    client_body_timeout 300s;

    location / {
        limit_req zone=convert burst=4 nodelay;
        proxy_pass http://127.0.0.1:8080;
        proxy_read_timeout 1200s;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

client_max_body_size का मान कम से कम उस सबसे बड़ी फ़ाइल के बराबर होना चाहिए जिसे आप रूपांतरित करना चाहते हैं, अन्यथा Nginx 413 Request Entity Too Large उत्तर देगा और PHP को अपलोड कभी नहीं दिखेगा। proxy_read_timeout का मान आपके सबसे लंबे रूपांतरण से अधिक होना चाहिए, अन्यथा प्रॉक्सी के पीछे ठीक से चल रहा कार्य ब्राउज़र को 504 Gateway Time-out लौटा देगा। उस सर्वर ब्लॉक का शेष भाग, जिसमें TLS (transport layer security) टर्मिनेशन शामिल है, Nginx रिवर्स प्रॉक्सी कॉन्फ़िगरेशन की पंक्ति-दर-पंक्ति व्याख्या में कवर किया गया है।

कन्वर्ट की गई फाइलों को हटाना

हर कन्वर्जन के बाद संवेदनशील फाइल की एक कॉपी उस डायरेक्टरी में रह जाती है जिसे वेब सर्वर पढ़ सकता है। क्लीनअप ही वह प्रक्रिया है जो एक कन्वर्टर को उन सभी फाइलों के संग्रह से अलग करती है जिन्हें किसी ने कभी कन्वर्ट किया है।

$DeleteThreshold, Resources/config.php में वह समय है (मिनटों में) जिसके बाद सेशन समाप्त हो जाता है, और इसका डिफॉल्ट मान 60 है। जब सामग्री संवेदनशील हो तो इसे घटाकर 15 कर दें। यह सफाई स्वयं कोर पर एक कमांड लाइन आर्ग्युमेंट है:

sudo -u www-data php /path/to/HRConvert2/convertCore.php -c
sudo -u www-data php /path/to/HRConvert2/convertCore.php -c=15

-c कॉन्फ़िगर किए गए थ्रेशोल्ड का उपयोग करके दोनों डेटा लोकेशन से समाप्त हो चुके सेशन को हटा देता है। -c=15 उस रन के लिए केवल पंद्रह मिनट का उपयोग करता है। -c=now उम्र की परवाह किए बिना हर सेशन को हटा देता है, जिसमें वह सेशन भी शामिल है जिसे कोई उपयोगकर्ता उस समय कन्वर्ट कर रहा है, इसलिए इसे केवल मेंटेनेंस के लिए रखें। यही आर्ग्युमेंट docker exec के माध्यम से कंटेनर के अंदर भी काम करते हैं।

इस सफाई प्रक्रिया को एक टाइमर पर सेट करें ताकि क्लीनअप किसी के पेज लोड करने पर निर्भर न रहे। /etc/cron.d/hrconvert2 में एक लाइन पर्याप्त है:

*/10 * * * * www-data php /path/to/HRConvert2/convertCore.php -c

इसे कुछ मिनट बाद ls /DATA/HRConvert2 के साथ चेक करें और पुरानी सेशन डायरेक्टरी को गायब होते हुए देखें। चूंकि वेब सर्वर उपयोगकर्ता उस डायरेक्टरी का मालिक है, इसलिए एक एक्सप्लॉइटेड पार्सर को ठीक वही एक्सेस मिलेगा, इसलिए उस अकाउंट के पास ऐसी कोई अन्य चीज नहीं होनी चाहिए जो मूल्यवान हो। VPS पर लीस्ट प्रिविलेज यूजर अकाउंट्स एक सामान्य पैटर्न है, और यह यहाँ सामान्य से अधिक लागू होता है।

यदि सार्वजनिक एक्सेस उद्देश्य नहीं है, तो इसे authentication के पीछे रखें

डिफ़ॉल्ट इंस्टॉलेशन में डिज़ाइन के अनुसार कोई अकाउंट नहीं होता है। जो कोई भी पेज तक पहुँच सकता है, वह फ़ाइल अपलोड कर सकता है और आपके converter binaries को चला सकता है, और rate limits केवल इसे धीमा करती हैं। इसलिए तय करें कि आप किस स्थिति में हैं।

यदि यह आपके और कुछ सहयोगियों के लिए है, तो इसे बिल्कुल भी expose न करें। कंटेनर को ऊपर दिखाए अनुसार loopback पर bind करें और इसे private network या SSH tunnel के माध्यम से एक्सेस करें। तब सार्वजनिक इंटरनेट पर मौजूद कोई भी चीज़ इसे फ़ाइल नहीं भेज पाएगी, जो इसे फ़िल्टर करने के बजाय पूरे attack surface को ही हटा देता है।

यदि इसे ब्राउज़र से एक्सेस किया जाना आवश्यक है, तो proxy के सामने authentication लगाएँ। Basic auth केवल दो commands का काम है और यह upload form को अनजान लोगों से दूर रखता है:

sudo apt install -y apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd alice

location / {
    auth_basic "Converter";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://127.0.0.1:8080;
}

Nginx को reload करें और पेज लोड करें। एक प्रॉम्प्ट का मतलब है कि यह काम कर रहा है, और यदि प्रॉम्प्ट नहीं आता है तो इसका मतलब है कि जिस location ब्लॉक को आपने एडिट किया है, वह अनुरोध को हैंडल नहीं कर रहा है। साझा पासवर्ड के बजाय वास्तविक अकाउंट्स के लिए, single sign-on प्रदाता पर terminate करें: एक self-hosted Authentik SSO server आपको उस एप्लिकेशन के सामने forward authentication देता है जिसका अपना कोई लॉगिन नहीं है।

यदि वास्तव में एक सार्वजनिक converter ही उद्देश्य है, तो इसके निहितार्थों को स्वीकार करें और उसके अनुसार योजना बनाएँ। मान लें कि sandbox की जाँच की जाएगी। Image tag को pinned रखें, ImageMagick policy को सख्त रखें, upload limits को कम रखें, और इसे ऐसे VPS पर चलाएँ जिसमें आपके काम की कोई अन्य चीज़ न हो।

विफलता के प्रकार और वे स्ट्रिंग्स जो आपको दिखाई देंगी

प्रत्येक कन्वर्जन तुरंत विफल हो जाता है। सैंडबॉक्स नहीं बनाया जा सकता। सामान्य इंस्टॉलेशन पर यह AppArmor प्रोफाइल की समस्या होती है। Docker में यह --security-opt seccomp=unconfined की कमी है। एप्लिकेशन इसका नाम बताती है: A sandbox blocks the required syscalls unless it was started with the correct options. और See --Require Sandbox-- & --Require Sandbox On Docker-- in config.php. की ओर संकेत करती है।

केवल इमेज कन्वर्जन विफल होते हैं। Bubblewrap is missing or non functional, so this image conversion cannot be isolated! का अर्थ है कि bwrap अनुपस्थित है या उस पाथ पर उपलब्ध नहीं है जो वेब सर्वर यूजर के पास है।

एक फॉर्मेट विफल होता है और बाकी काम करते हैं। एक बाइनरी गायब है, जिसे स्पष्ट रूप से रिपोर्ट किया गया है: ImageMagick may not be installed, or may not be reachable on the system path used by the web server user. यही संदेश FFmpeg और LibreOffice दोनों के लिए आता है। यह देखने के लिए कि इंस्टॉलेशन क्या ढूंढ सकता है, convertCore.php -v चलाएं, और याद रखें कि Apache वर्कर का PATH आपके लॉगिन शेल का PATH नहीं है।

PDF का काम पॉलिसी एरर के साथ विफल हो जाता है। attempt to perform an operation not allowed by the security policy 'PDF', ImageMagick की policy.xml से आता है, न कि HRConvert2 से।

बड़ी अपलोड फाइलें 413 एरर देती हैं। nginx client_max_body_size फाइल से छोटा है। इस चेन में तीन सीमाएं हैं, एक nginx में और दो PHP में, और जो सबसे छोटी होती है वही प्रभावी रहती है।

कन्वर्जन रुक जाते हैं और कुछ भी स्पष्ट रूप से नहीं बदला है। The device where data is stored has an insufficient amount of storage space available. खाली जगह (free space) की जांच करें और सुनिश्चित करें कि क्लीनअप स्वीप वास्तव में चल रहा है।

क्लीनअप लॉग में शिकायत करता है। Could not clean the temporary location! और Could not clean the convert location! ओनरशिप (स्वामित्व) संबंधी समस्याएं हैं। वेब सर्वर यूजर को $ConvertLoc द्वारा नामित डायरेक्टरी का मालिक होना चाहिए।

FAQ

क्या self-hosted file converter को इंटरनेट पर expose करना सुरक्षित है?

यह तब तक सुरक्षित है जब तक आप इसे अजनबियों के लिए खुले एक parser के रूप में देखते हैं। हर upload को LibreOffice, ImageMagick, FFmpeg या Ghostscript को सौंपा जाता है, और upload करने वाला व्यक्ति चुनता है कि किसका उपयोग करना है। HRConvert2 इन tools को बिना नेटवर्क और read-only input directory वाले bubblewrap namespace के अंदर चलाता है। यह किसी भी ऐसे conversion को अस्वीकार कर देता है जिसे यह sandbox नहीं कर सकता, जो कि एक मजबूत default सुरक्षा है। फिर भी, authentication की आवश्यकता रखना, upload limits को कम रखना और इसे ऐसे VPS पर चलाना बेहतर है जिसमें कोई अन्य महत्वपूर्ण डेटा न हो।

Ubuntu 24.04 के नए install पर सभी conversions क्यों विफल हो जाते हैं?

Ubuntu 24.04 और Debian 12 unprivileged user namespaces को प्रतिबंधित करते हैं, और bubblewrap को अपना sandbox बनाने के लिए इसकी आवश्यकता होती है। चूंकि application बिना sandbox के convert करने से मना कर देती है, इसलिए सभी jobs विफल हो जाती हैं। /usr/bin/bwrap के लिए flags=(unconfined) के साथ एक AppArmor profile लिखें, इसे sudo apparmor_parser -r /etc/apparmor.d/bwrap के साथ load करें, और फिर bwrap --ro-bind / / --dev /dev /bin/true के साथ पुष्टि करें।

Docker में conversions क्यों विफल होते हैं जबकि सामान्य install पर काम करते हैं?

Docker का default seccomp profile उन system calls को block करता है जिनका उपयोग bubblewrap करता है, इसलिए container के अंदर sandbox नहीं बनाया जा सकता। इसे --security-opt seccomp=unconfined के साथ start करें, जो कि project की अपनी run command करती है। ध्यान दें कि $RequireSandboxOnDocker default रूप से FALSE होता है, इसलिए बिना flag वाला container बिना किसी sandbox के convert कर सकता है। एक बार seccomp flag लग जाने के बाद इसे TRUE पर set करें।

file conversion server को कितनी RAM की आवश्यकता होती है?

Idle स्थिति में यह कम RAM लेता है, लेकिन live conversion के दौरान ऐसा नहीं है। LibreOffice एक Java runtime शुरू करता है, ImageMagick 256 MiB memory और 512 MiB map लेता है (shipped policy के तहत), और PHP की अपनी limit 512M है। 1 GB के VPS पर यह संयोजन swap का उपयोग करने लगता है और out of memory killer soffice.bin या apache2 को समाप्त कर देता है। एक छोटी टीम के लिए 4 GB RAM और दो cores की योजना बनाएं, और जब भी कोई conversion बिना किसी संदेश के बंद हो जाए तो dmesg -T | grep -i "killed process" की जाँच करें।

converted files कहाँ जाती हैं और उन्हें कब delete किया जाता है?

वे Resources/config.php में $ConvertLoc द्वारा नामित working directory में जाती हैं, जो default रूप से /DATA/HRConvert2 होता है। $DeleteThreshold उस आयु को मिनटों में set करता है जिस पर session समाप्त हो जाता है, और इसका default मान 60 है। Sweep command line से चलता है: php convertCore.php -c समाप्त हो चुके sessions को साफ़ करता है, और -c=now सक्रिय sessions सहित हर session को तुरंत साफ़ कर देता है। -c को cron entry या systemd timer पर रखें ताकि deletion किसी के साइट पर आने पर निर्भर न रहे।