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

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

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

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

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

आवश्यकताएँ

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

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

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

यह image सभी converter binaries के साथ आती है, इसलिए इसका आकार बड़ा है: अगस्त 2026 तक लगभग 3 GB। pull करने से पहले free 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/

एक healthy 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 के convert कर सकता है। एक बार flag लग जाने के बाद, $RequireSandboxOnDocker = TRUE; set करें और आपको container के अंदर वापस वही refusal व्यवहार मिल जाएगा।

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

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

Repository में मौजूद 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 चलाएं और अपने वर्ज़न से मेल खाने वाला prefix उपयोग करें, क्योंकि PHP के हर release के साथ package के नाम बदल जाते हैं और गलत नाम इस्तेमाल करने पर आपको Unable to locate package त्रुटि मिलेगी।

इसके बाद converters की बारी है। इसमें documents, images, audio, video और 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

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

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

यह एक vendor script है जिसे root के रूप में shell में pipe किया जाता है। यह upstream तरीका है और पूरी तरह वैकल्पिक है: यदि आप इसे छोड़ देते हैं, तो केवल ebook conversion की सुविधा ही काम नहीं करेगी।

अगला चरण PHP की सीमाएं निर्धारित करना है। रूपांतरण प्रक्रिया धीमी होती है और फाइलें बड़ी होती हैं, इसलिए stock values बहुत कम हैं। प्रोजेक्ट इन्हें 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 एक ऐसी request बना सकता है जो 40 GB की डिस्क क्षमता से कहीं अधिक डेटा लिख सकती है। Apache को restart करें और पुष्टि करें कि PHP ने क्या लोड किया है:

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

अब working directory सेट करें। Resources/config.php में $ConvertLoc इसका नाम निर्धारित करता है, और default मान /DATA/HRConvert2 है। वेब सर्वर user के पास इसका स्वामित्व (ownership) होना चाहिए:

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

Release को अपने Apache document root के अंतर्गत unpack करें। Default layout इसे HRProprietary/HRConvert2 फोल्डर में रखता है, और Resources/config.php में $InstLoc को उस स्थान का नाम देना होगा जहाँ आपने इसे रखा है। इसके बाद built-in diagnostic चलाएं, जो किसी उपयोगकर्ता द्वारा समस्या का सामना करने से पहले missing dependency का पता लगाने का सबसे तेज़ तरीका है:

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

-v पूरे इंस्टॉलेशन की जांच करता है: core versions, dependency checks, सैंडबॉक्स की स्थिति और language packs। फाइल रूपांतरण command line से समर्थित नहीं हैं, इसलिए यह argument सेट केवल प्रशासनिक कार्यों के लिए है।

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

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

इसे सीधे जाँचें:

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

Permission denied त्रुटि का अर्थ है कि namespace को ब्लॉक कर दिया गया है। इसका समाधान 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 प्रिंट करना चाहिए। इसके बाद कन्वर्जन काम करने लगेंगे।

Public converter एक ऐसा parser है जो अनजान लोगों के लिए खुला होता है

यह वह section है जिसके लिए यह पूरा post लिखा गया है। internet से access किया जा सकने वाला file converter किसी भी अनजान व्यक्ति से कोई भी file स्वीकार करता है और उसे LibreOffice, ImageMagick, FFmpeg या Ghostscript को सौंप देता है। ये बड़े C और C++ codebase हैं जिनमें parser bugs का लंबा इतिहास रहा है। file upload करने वाला व्यक्ति format चुनता है, जिसका अर्थ है कि upload करने वाला व्यक्ति यह चुनता है कि कौन सा parser चलेगा और उसके भीतर कौन सा code path execute होगा।

HRConvert2 का समाधान यह है कि हर dependency को एक bubblewrap namespace के भीतर चलाया जाए। प्रत्येक conversion को दो directories दिखाई देती हैं: एक जिसमें input होता है, जिसे read-only mode में mount किया जाता है, और दूसरी जिसमें output प्राप्त होता है। network को unshared रखा जाता है, जो project के शब्दों में, closes every URL handler in every dependency at once है। यह सुनने में जितना लगता है, उससे कहीं अधिक महत्वपूर्ण है। ImageMagick और Ghostscript दोनों ऐसे references स्वीकार करते हैं जो URL fetch करते हैं, और इसी तरह एक converter server-side request forgery (SSRF) tool में बदल जाता है, जिससे आपके network के भीतर से cloud metadata endpoint तक पहुँचा जा सकता है। namespace में network न होने के कारण, यह fetch संभव नहीं हो पाता।

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

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

ImageMagick की अपनी policy file sandbox के नीचे एक दूसरी सुरक्षा परत है, और इसे सेट करना उचित है। 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 coders को अस्वीकार (deny) करता है, और यह URL, HTTPS, HTTP और gs delegates को भी अस्वीकार करता है, जबकि 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 को कॉल करता है, और वही delegate वह स्थान है जहाँ ImageMagick के प्रसिद्ध remote code execution bugs मौजूद होते हैं। इस delegate को deny करने पर ImageMagick किसी भी अपलोड की गई फ़ाइल को gs को नहीं भेजेगा, चाहे फ़ाइल कुछ भी होने का दावा करे।

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

<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 होने से पहले ही इसे अस्वीकार कर देती हैं, जिससे kernel द्वारा किसी प्रक्रिया को kill करने के बजाय, वह प्रक्रिया स्वयं ही exit हो जाती है।

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

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

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

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

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

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

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

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

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

इसके बाद, request के 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) termination भी शामिल है, nginx reverse proxy कॉन्फ़िगरेशन की पंक्ति-दर-पंक्ति व्याख्या में कवर किया गया है।

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

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

$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 के पीछे रखें

default install में design के अनुसार कोई account नहीं होता है। जो कोई भी page तक पहुँच सकता है, वह file upload कर सकता है और आपके converter binaries को चला सकता है, और rate limits इसे केवल धीमा करती हैं। इसलिए तय करें कि आप किस स्थिति में हैं।

यदि यह आपके और कुछ सहयोगियों के लिए है, तो इसे बिल्कुल भी expose न करें। container को loopback पर bind करें जैसा कि ऊपर दिखाया गया है और इसे private network या SSH tunnel के माध्यम से access करें। तब public internet पर मौजूद कोई भी चीज़ इसे file नहीं भेज पाएगी, जो इसे filter करने के बजाय पूरे attack surface को ही हटा देता है। यदि उन सहयोगियों को बिना आपके hostname publish किए या port खोले इसे browser में खोलने की आवश्यकता है, तो इसे v3 onion service के रूप में serve करना converter को loopback पर bound रखता है और फिर भी उन्हें visit करने के लिए एक address देता है।

यदि इसे browser से reachable होना ही है, तो 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 करें और page load करें। एक prompt का मतलब है कि यह काम कर रहा है, और prompt न आने का मतलब है कि जिस location block को आपने edit किया है, वह request को handle नहीं कर रहा है। साझा password के बजाय वास्तविक accounts के लिए, single sign-on provider पर terminate करें: एक self-hosted Authentik SSO server आपको ऐसे application के सामने forward authentication देता है जिसका अपना कोई login नहीं है।

यदि वास्तव में एक सार्वजनिक converter ही लक्ष्य है, तो इसके निहितार्थों को स्वीकार करें और उसके अनुसार योजना बनाएँ। मान लें कि sandbox की जाँच (probe) की जाएगी। 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 अनुपस्थित है या वेब सर्वर यूजर के पाथ (path) पर उपलब्ध नहीं है।

एक फॉर्मेट विफल होता है और बाकी काम करते हैं। एक बाइनरी गायब है, जिसे स्पष्ट रूप से 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! ओनरशिप (ownership) संबंधी समस्याएं हैं। वेब सर्वर यूजर को $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 के fresh 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 बिना किसी message के बंद हो जाए तो dmesg -T | grep -i "killed process" की जाँच करें।

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

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