लेखक: Matt Connor 2026-08-13

VPS पर rootless Podman में Ollama कैसे चलाएं

VPS पर rootless Podman के साथ Ollama सेटअप करने का तरीका जानें। इसमें unprivileged user, systemd Quadlet, SELinux लेबलिंग और सुरक्षित SSH टनलिंग की पूरी प्रक्रिया शामिल है।

VPS पर rootless Podman में Ollama चलाना

सर्वर पर rootless Podman में Ollama चलाने के लिए पाँच ऐसी शर्तों का पूरा होना आवश्यक है जिन्हें डेस्कटॉप गाइड में अक्सर छोड़ दिया जाता है। एक समर्पित unprivileged user कंटेनर का स्वामी होता है। उस user के लिए lingering सक्षम होना चाहिए, ताकि आपके लॉग आउट करने के बाद भी कंटेनर चलता रहे। एक Quadlet फाइल कंटेनर को systemd को सौंपती है, जिससे रीबूट के बाद यह स्वतः शुरू हो जाता है। जिन डिस्ट्रिब्यूशन में SELinux लागू है, वहाँ मॉडल डायरेक्टरी पर सही SELinux लेबल होना चाहिए। API केवल loopback पर listen करती है, और आप इसे SSH (secure shell) टनल के माध्यम से एक्सेस करते हैं।

Ollama लार्ज लैंग्वेज मॉडल्स (LLM) के लिए एक सर्वर है। यह मॉडल वेट्स को डिस्क पर स्टोर करता है, उन्हें मेमोरी में लोड करता है, और port 11434 पर HTTP अनुरोधों का उत्तर देता है। इसमें कोई लॉगिन, API की या यूजर अकाउंट नहीं होता, इसलिए नेटवर्क ही एकमात्र एक्सेस कंट्रोल है। Podman बिना किसी डेमन और बिना रूट के कंटेनर चलाता है, इसलिए यदि कोई प्रक्रिया कंटेनर से बाहर निकलती है, तो वह एक सामान्य unprivileged user के रूप में ही शुरू होती है। यदि आप पहले रनटाइम की तुलना देखना चाहते हैं, तो VPS पर Podman और Docker में अंतर पढ़ें। यदि आप कंटेनरों का उपयोग पूरी तरह से छोड़ना चाहते हैं, तो VPS पर सीधे Ollama इंस्टॉल करना एक छोटा विकल्प है।

SSD Nodes अपने इमेजेस में Fedora प्रदान करता है, और Fedora डिफ़ॉल्ट रूप से Podman और SELinux (security-enhanced Linux) के साथ आता है। नीचे दिए गए सभी कमांड Podman 5 या उससे नए वर्जन वाले किसी भी डिस्ट्रिब्यूशन पर काम करते हैं।

सर्वर पर लैपटॉप संस्करण में बदलाव की आवश्यकता क्यों है

Fedora Magazine ने 5 अगस्त 2026 को इस स्टैक का एक स्पष्ट विवरण प्रकाशित किया: Running Ollama Locally with Podman on Fedora Linux, जिसे Yazan Monshed ने लिखा है। यह इन टूल्स के साथ शुरुआत करने के लिए एक अच्छा मार्गदर्शक है। यह एक लैपटॉप को लक्षित करता है, और इसके चार विकल्प सार्वजनिक IP पते वाली मशीन पर अलग तरह से व्यवहार करते हैं।

यह कंटेनर को एक साधारण podman run -d के साथ शुरू करता है। हाथ से शुरू किया गया कंटेनर रीबूट के बाद वापस नहीं आता है, क्योंकि इसे शुरू करने के लिए कभी कोई निर्देश नहीं दिया गया था।
यह मूविंग टैग ollama/ollama का उपयोग करता है। लैपटॉप पर आपको उस दिन पता चल जाता है जब व्यवहार बदलता है। सर्वर पर इसका पहला संकेत वह स्क्रिप्ट है जो रातों-रात काम करना बंद कर देती है।
यह -p 11434:11434 के साथ पब्लिश करता है, जो हर इंटरफ़ेस को बाइंड करता है। होम राउटर के पीछे यह इंटरनेट से पहुंच योग्य नहीं होता है। VPS पर यह बिना किसी पासवर्ड वाली एक सार्वजनिक इन्फरेंस API बन जाती है।
यह आपके अपने लॉगिन यूजर के रूप में चलता है। सर्वर पर कंटेनर के मालिक अकाउंट के पास कुछ और नहीं होना चाहिए, ताकि यदि कोई ब्रेक-आउट हो, तो वह एक खाली होम डायरेक्टरी में ही रहे।

जिस मशीन के लिए इसे लिखा गया था, उसके लिए इनमें से कुछ भी गलत नहीं है। प्रत्येक बिंदु केवल एक ऐसा निर्णय है जिसे आप तब दोबारा देखते हैं जब मशीन हर जगह से पहुंच योग्य हो और उसके सामने कोई बैठा न हो।

Unprivileged user बनाएँ और subuid की जाँच करें

Rootless Podman कंटेनर के आंतरिक user IDs (UID) को होस्ट पर unused IDs के एक ब्लॉक पर मैप करता है। उस ब्लॉक को /etc/subuid और /etc/subgid में घोषित किया जाता है। इसके बिना, rootless कंटेनर बिल्कुल भी start नहीं हो सकते।

sudo dnf install -y podman        # or: sudo apt install -y podman
sudo useradd --create-home --shell /bin/bash --comment "Ollama container owner" ollama
sudo passwd --lock ollama
grep ollama /etc/subuid /etc/subgid

grep को दो लाइनें print करनी चाहिए, प्रत्येक फाइल से एक, जिनमें से प्रत्येक 65536 IDs की एक रेंज का नाम बताती है:

/etc/subuid:ollama:100000:65536
/etc/subgid:ollama:100000:65536

आपकी शुरुआती संख्या अलग होगी, और यह सामान्य है। यदि grep कुछ भी print नहीं करता है, तो useradd ने कोई रेंज allocate नहीं की है, और उस user के रूप में पहला podman कमांड इस तरह विफल हो जाता है:

Error: cannot find UID/GID for user ollama: no subuid ranges found for user "ollama" in /etc/subuid

एक ऐसी रेंज असाइन करें जिसे कोई अन्य user न रखता हो, फिर Podman को बताएं कि उसकी पुरानी मैपिंग पुरानी (stale) हो चुकी है:

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 ollama
sudo -iu ollama podman system migrate

पासवर्ड लॉक करने का अर्थ है कि कोई भी सीधे ollama के रूप में login नहीं कर सकता। आप sudo -iu ollama के साथ अपने admin user से उस account तक पहुँचते हैं।

Lingering सक्षम करें ताकि service logout के बाद भी चलती रहे

एक user का systemd instance सामान्यतः login पर शुरू होता है और logout पर बंद हो जाता है, और /run/user/<uid> को हटा दिया जाता है। उस user के स्वामित्व वाला प्रत्येक rootless container उसी क्षण बंद हो जाता है। Lingering, user instance को बिना किसी session के चलते रहने देता है।

sudo loginctl enable-linger ollama
loginctl show-user ollama --property=Linger

यह कमांड Linger=yes प्रिंट करना चाहिए। इसे unit बनाने से पहले सक्षम करें, क्योंकि जिस directory की unit को आवश्यकता होती है, /run/user/<uid>, वह केवल तभी मौजूद होती है जब lingering चालू हो।

एक और कदम है जिसकी उम्मीद कोई नहीं करता। sudo -iu ollama आपको shell तो देता है लेकिन session bus नहीं, इसलिए systemctl --user तुरंत विफल हो जाता है:

Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined

systemd, user bus को $XDG_RUNTIME_DIR/bus पर खोजता है, और sudo -i उस variable को set नहीं करता है। इसे हर उस admin shell में मैन्युअल रूप से set करें जहाँ आप इस service को manage करते हैं:

sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
systemctl --user status

मॉडल ब्लब्स कहाँ स्टोर होते हैं और कितनी डिस्क स्पेस की योजना बनाएं

Ollama कंटेनर के भीतर /root/.ollama/models में वेट्स (weights) लिखता है। यूजर की होम डायरेक्टरी से एक डायरेक्टरी को इस पाथ पर बाइंड करें, ताकि फाइलें ऐसी जगह स्टोर हों जिसे आप माप सकें: /home/ollama/ollama-data/models। ब्लब्स models/blobs में कंटेंट-एड्रेस्ड फाइलों के रूप में जाते हैं, और models/manifests में वह छोटा इंडेक्स होता है जो उन्हें नाम देता है। यदि आप इसके बजाय एक नेम्ड वॉल्यूम का उपयोग करते हैं, जैसा कि Fedora Magazine पोस्ट में बताया गया है, तो वही ट्री /home/ollama/.local/share/containers/storage/volumes/<volume>/_data के अंतर्गत रहता है।

कुछ भी पुल (pull) करने से पहले डिस्क का आकार निर्धारित करें। प्रकाशित डाउनलोड साइज आपको न्यूनतम आवश्यकता बताते हैं।

ChartPublished download size per Ollama model tag, ollama.com/library, checked 13 August 2026

label

download_gb

gemma3:4b

3.3

mistral:7b

4.4

qwen3:8b

5.2

gemma3:12b

8.1

qwen3:14b

9.3

gemma3:27b

qwen3:30b

The data behind this chart

[
  {
    "label": "gemma3:4b",
    "download_gb": 3.3
  },
  {
    "label": "mistral:7b",
    "download_gb": 4.4
  },
  {
    "label": "qwen3:8b",
    "download_gb": 5.2
  },
  {
    "label": "gemma3:12b",
    "download_gb": 8.1
  },
  {
    "label": "qwen3:14b",
    "download_gb": 9.3
  },
  {
    "label": "gemma3:27b",
    "download_gb": 17
  },
  {
    "label": "qwen3:30b",
    "download_gb": 19
  }
]

सभी 7 पंक्तियाँ ollama.com/library पर प्रकाशित आंकड़े हैं, न कि डिस्क पर मापा गया साइज। यहाँ सबसे छोटा टैग, gemma3:4b, 3.3 GB डाउनलोड करता है। सबसे बड़ा टैग, qwen3:30b, 19 GB डाउनलोड करता है। कंटेनर इमेज स्वयं Podman के अपने स्टोरेज में इसके ऊपर रहती है, इसलिए podman system df और df -h /home के साथ दोनों आंकड़ों की एक साथ जांच करें। लोड होने के दौरान एक मॉडल को RAM में लगभग अपने फाइल साइज के बराबर जगह चाहिए होती है, साथ ही कॉन्टेक्स्ट विंडो के लिए अतिरिक्त जगह भी चाहिए, इसलिए 16 GB वाले VPS पर 19 GB का मॉडल नहीं चलेगा।

Image tag को पिन करें और पूर्ण registry नाम का उपयोग करें

sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
mkdir -p ~/ollama-data ~/.config/containers/systemd
podman pull docker.io/ollama/ollama:0.32.9

एक released version tag का उपयोग करें, अगस्त 2026 तक 0.32.9, न कि latest। एक pinned tag का अर्थ है कि 04:00 बजे restart करने पर आपको वही binary मिलेगी जिसका आपने परीक्षण किया था, इसलिए व्यवहार में कोई भी बदलाव आपके द्वारा किया गया बदलाव है। Docker Hub उन्हीं versions के लिए -rc और -rocm tags भी प्रकाशित करता है; जब तक आपके पास AMD GPU न हो, तब तक plain tag ही चुनें।

Registry host भी लिखें। Fedora पर systemd unit में short name होने पर prompt के लिए कोई terminal नहीं होता है, और unit इस error के साथ fail हो जाती है:

Error: short-name "ollama/ollama" did not resolve to an alias and no unqualified-search registries are defined

पहले मैन्युअल रूप से pull करना वैकल्पिक है लेकिन उपयोगी है, क्योंकि यह multi-gigabyte download को unit के start timeout से बाहर ले जाता है।

Quadlet unit जो रीबूट के बाद भी बना रहता है

Quadlet, Podman का systemd जनरेटर है। आप एक .container फाइल लिखते हैं, systemd इसे बूट के समय एक सर्विस में बदल देता है, और podman generate systemd की आवश्यकता नहीं रहती। इसे /home/ollama/.config/containers/systemd/ollama.container के रूप में सेव करें, जिसका स्वामित्व ollama यूजर के पास हो।

[Unit]
Description=Ollama API (rootless)
After=network-online.target
Wants=network-online.target

[Container]
Image=docker.io/ollama/ollama:0.32.9
ContainerName=ollama
PublishPort=127.0.0.1:11434:11434
Volume=/home/ollama/ollama-data:/root/.ollama:Z
Environment=OLLAMA_KEEP_ALIVE=30m
Environment=OLLAMA_MAX_LOADED_MODELS=1

[Service]
Restart=always
TimeoutStartSec=900

[Install]
WantedBy=default.target

फाइल का नाम सर्विस का नाम निर्धारित करता है, इसलिए ollama.container बदलकर ollama.service हो जाता है।

systemctl --user daemon-reload
systemctl --user start ollama.service
systemctl --user status ollama.service

status को active (running) दिखाना चाहिए। systemctl --user enable ollama.service न चलाएं। यह यूनिट डिस्क पर फाइल के रूप में मौजूद नहीं है, इसलिए systemd इसे अस्वीकार कर देता है:

Failed to enable unit: Unit file /run/user/1001/systemd/generator/ollama.service is transient or generated.

[Install] सेक्शन पहले से ही यह कार्य करता है। Quadlet स्वयं daemon-reload के दौरान बूट-पर-स्टार्ट लिंक बनाता है, इसीलिए वह कमांड वैकल्पिक नहीं है। TimeoutStartSec=900 पहली बार स्टार्ट होने की प्रक्रिया को कवर करता है जिसमें इमेज को पुल करना होता है, क्योंकि दो-गीगाबाइट डाउनलोड के लिए डिफ़ॉल्ट 90 सेकंड पर्याप्त नहीं हैं और systemd स्टार्ट को विफल मानकर समाप्त कर देगा। OLLAMA_KEEP_ALIVE=30m अनुरोधों के बीच मॉडल को अनलोड करने के बजाय मेमोरी में रखता है; इसके फायदे और नुकसान Ollama मॉडल को मेमोरी में रखने के बारे में विस्तार से बताए गए हैं। यदि यहाँ उपयोग की गई systemd शब्दावली आपके लिए नई है, तो VPS पर systemd सर्विस और टाइमर कैसे काम करते हैं में यूनिट्स के बारे में जानकारी दी गई है।

SELinux के अंतर्गत model directory 'permission denied' क्यों दिखाती है

Fedora, RHEL, Rocky और AlmaLinux पर, SELinux डिफ़ॉल्ट रूप से enforcing मोड में होता है। एक container process container_t domain में चलती है, और user की home directory को user_home_t label दिया जाता है। policy एक को दूसरे तक पहुँचने की अनुमति नहीं देती है, इसलिए Ollama अपना model tree नहीं बना पाता और container बंद हो जाता है। इन systems पर getenforce चलाने पर Enforcing दिखाई देता है, और यह denial record हो जाता है:

sudo ausearch -m avc -ts recent

आपको एक line दिखाई देगी जिसमें domain और target label का नाम होगा:

avc:  denied  { write } for  pid=1842 comm="ollama" name="models" dev="vda1" ino=131077 scontext=system_u:system_r:container_t:s0:c214,c827 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir permlisted=0

Volume= line के अंत में दिया गया :Z इसका समाधान है। यह host directory को container_file_t में re-label कर देता है और उस पर एक private MCS (multi-category security) category लगा देता है जिसे केवल वही container carry करता है। lowercase :z इसके बजाय एक shared label का उपयोग करता है, जो तब उपयोगी होता है जब दो containers एक ही directory को read करते हैं।

:Z के बारे में एक चेतावनी, क्योंकि यह destructive है और कोई सूचना नहीं देता। Relabelling recursive होती है। यदि आप इसे /home/ollama पर point करते हैं, तो उस home directory की हर file re-label हो जाएगी, जिससे उस user का SSH key access टूट जाएगा। :Z को हमेशा एक समर्पित subdirectory दें जिसमें कुछ और न हो। Named volumes के लिए इसकी आवश्यकता नहीं होती, क्योंकि Podman उन्हें create करते समय सही label लगा देता है। यदि आपको अधिक जानकारी चाहिए, तो SELinux basics for a server contexts और booleans की व्याख्या करता है। Ubuntu और Debian पर इसके बजाय AppArmor का उपयोग होता है, वहाँ :Z का कोई प्रभाव नहीं पड़ता है, और इसे unit में छोड़ देना सुरक्षित है।

Port 11434 को बंद करें और SSH के माध्यम से API तक पहुँचें

PublishPort=127.0.0.1:11434:11434 host side को loopback पर bind करता है। इसकी पुष्टि करें:

ss -ltnp | grep 11434
curl http://127.0.0.1:11434

ss का आउटपुट 127.0.0.1:11434 दिखाना चाहिए। 0.0.0.0:11434 या *:11434 का मतलब है कि port इंटरनेट के लिए खुला है, और curl को Ollama is running का जवाब देना चाहिए।

इस बारे में सटीक रहें कि आप किस side को bind कर रहे हैं। PublishPort में दिया गया address host address है। Container के अंदर, Ollama को सभी interfaces पर listen करना जारी रखना चाहिए, जो कि image का default है। Environment=OLLAMA_HOST=127.0.0.1 सेट करने से Ollama container के अपने loopback पर bind हो जाता है, और Podman पब्लिश किए गए traffic को container के network address पर forward करता है, इसलिए हर request host से भी refuse हो जाती है।

एक खुला 11434 आपको दो तरह से नुकसान पहुँचाता है। Ollama में कोई authentication नहीं है, इसलिए जो कोई भी port तक पहुँचता है, वह /api/tags के माध्यम से आपके models की सूची देख सकता है, /api/generate के माध्यम से आपके CPU और bandwidth allowance पर inference चला सकता है, आपकी disk पर नए models pull कर सकता है, और आपके पास मौजूद models को delete कर सकता है। दूसरा, remote port पर plain HTTP prompts और completions को cleartext में भेजता है, इसलिए रास्ते में आने वाली हर machine उन्हें पढ़ सकती है। यदि port कभी भी box से बाहर नहीं जाता है, तो ये दोनों समस्याएँ खत्म हो जाती हैं।

अपने workstation से, SSH के माध्यम से port को forward करें:

ssh -N -L 11434:127.0.0.1:11434 you@vps.example.com

अब आपके laptop पर http://127.0.0.1:11434 सर्वर का Ollama है, जो SSH session के encryption के अंदर है। यदि आपके laptop पर पहले से ही Ollama चल रहा है, तो local bind bind [127.0.0.1]:11434: Address already in use के साथ विफल हो जाएगा; -L 11435:127.0.0.1:11434 का उपयोग करें और अपने client को 11435 पर point करें।

जब किसी browser client को इसकी आवश्यकता हो, तो इसके बजाय सामने password वाला एक reverse proxy लगाएँ। Caddy site block चार लाइनों का होता है, और caddy hash-password उस bcrypt hash को print करता है जिसकी उसे आवश्यकता होती है:

ollama.example.com {
  basic_auth {
    you $2a$14$replace_with_the_generated_hash
  }
  reverse_proxy 127.0.0.1:11434
}

Caddy अपने आप TLS (transport layer security) पर certificate प्राप्त कर लेता है, इसलिए traffic encrypted रहता है। पहले अपने client का परीक्षण करें: Ollama से बात करने वाले कई tools में Authorization header के लिए कोई field नहीं होती है, और वे basic auth के साथ bare 401 Unauthorized पर विफल हो जाएंगे। SSH tunnel में ऐसी कोई समस्या नहीं है, यही कारण है कि यहाँ इसे default रूप से सुझाया गया है।

मॉडल को पुल करें और पूरे पाथ की जाँच करें

podman exec -it ollama ollama pull gemma3:4b
curl -s http://127.0.0.1:11434/api/tags
curl -s http://127.0.0.1:11434/api/generate -d '{"model":"gemma3:4b","prompt":"Reply with the single word: ready","stream":false}'
du -sh ~/ollama-data/models

/api/tags एक JSON लिस्टिंग लौटाता है जिसमें gemma3:4b शामिल होता है। /api/generate एक JSON ऑब्जेक्ट लौटाता है जिसमें response फील्ड होता है, जो डिस्क से वेट्स (weights) लोड होने के दौरान थोड़े अंतराल के बाद आता है। du को प्रकाशित डाउनलोड साइज के करीब एक संख्या दिखानी चाहिए। अब उस हिस्से को सिद्ध करें जिसके बारे में यह पूरी गाइड है:

sudo reboot
# reconnect, then:
sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
systemctl --user is-active ollama.service

active का अर्थ है कि प्रक्रिया अभी भी चल रही है, और [Install] सेक्शन तथा daemon-reload ने अपना काम पूरा कर लिया है। inactive का अर्थ है कि इन तीनों में से कोई एक गायब है।

विफलता के प्रकार और उनसे संबंधित संदेश

Reboot के बाद container गायब हो जाता है। सबसे पहले loginctl show-user ollama --property=Linger की जाँच करें, क्योंकि Linger=yes के बिना user का systemd instance boot के समय कभी start नहीं होता। यदि lingering चालू है, तो .container फ़ाइल से [Install] सेक्शन गायब है, या आपने फ़ाइल को edit किया है लेकिन systemctl --user daemon-reload नहीं चलाया है।

Error: statfs /home/ollama/ollama-data: no such file or directory। container start होने से पहले bind mount source का मौजूद होना आवश्यक है। Podman आपके लिए host directories नहीं बनाता है। ollama user के रूप में mkdir -p ~/ollama-data चलाएँ।

90 seconds पर start विफल हो जाता है। journalctl --user -u ollama.service में Start operation timed out. Terminating. दिखाई देता है क्योंकि image pull अभी भी चल रहा था। इसे मैन्युअल रूप से pull करें, या TimeoutStartSec=900 को बनाए रखें।

Container start होकर बंद हो जाता है। podman logs ollama और sudo ausearch -m avc -ts recent एक साथ आपको बताते हैं कि क्या यह SELinux label की समस्या है। container_t और user_home_t को दर्शाने वाला AVC संदेश बताता है कि :Z गायब है।

Host से requests अस्वीकार कर दी जाती हैं। curl: (7) Failed to connect to 127.0.0.1 port 11434: Connection refused के साथ service active का अर्थ आमतौर पर यह है कि container के अंदर OLLAMA_HOST को loopback address पर सेट किया गया था। उस line को हटा दें।

Generation बहुत धीमी है, या container kill हो जाता है। GPU न होने पर, inference CPU पर चलता है और एक बड़ा model स्वभाव से धीमा होता है। logs में signal: killed के साथ बीच में ही बंद होने वाला container kernel का out-of-memory killer है, इसलिए ऊपर दिए गए chart से छोटा tag चुनें।

Pinned image को अपडेट करना

Pinning का अर्थ है कि updates आप स्वयं करते हैं, न कि वे अपने आप होते हैं। Image= को ollama.container में edit करें, फिर reload और restart करें:

systemctl --user daemon-reload
systemctl --user restart ollama.service
podman exec ollama ollama --version

Models bind mount में रहते हैं, इसलिए वे image बदलने पर भी सुरक्षित रहते हैं। [Container] section में मौजूद AutoUpdate=registry उन लोगों के लिए है जो moving tag का उपयोग करते हैं। fixed version tag के साथ इसका कोई उपयोग नहीं है, क्योंकि उस tag की सामग्री कभी नहीं बदलती। /home/ollama/ollama-data/models/manifests और .container file का backup लें, और blobs को छोड़ दें: वे बड़े होते हैं, और किसी नए box पर ollama pull उन्हें फिर से fetch कर लेता है।

FAQ

मेरा rootless Podman container logout करने पर क्यों बंद हो जाता है?

जब किसी user का अंतिम session समाप्त होता है, तो उस user का systemd instance और उसकी /run/user/<uid> directory हटा दी जाती है, और सभी rootless containers भी उनके साथ बंद हो जाते हैं। sudo loginctl enable-linger ollama चलाएं और सुनिश्चित करें कि loginctl show-user ollama --property=Linger का output Linger=yes है। Quadlet unit बनाने से पहले lingering को enable करें, क्योंकि unit के लिए आवश्यक runtime directory केवल तभी मौजूद होती है जब lingering चालू हो।

क्या मुझे Ollama model directory पर SELinux labels की आवश्यकता है?

Fedora, RHEL, Rocky और AlmaLinux पर, यदि आप host directory को bind mount करते हैं, तो हाँ। Container container_t domain में चलता है और home folder की directory को user_home_t label दिया जाता है, इसलिए write access अस्वीकार कर दिया जाता है और Ollama बंद हो जाता है। Volume= line में :Z जोड़ें और इसे एक समर्पित subdirectory दें, क्योंकि relabelling recursive होती है और :Z को पूरी home directory पर point करने से उस user के लिए SSH key access टूट सकता है। Named volumes को Podman द्वारा सही ढंग से label किया जाता है और उन्हें किसी अतिरिक्त चीज़ की आवश्यकता नहीं होती है।

Ollama model को कितनी disk space की आवश्यकता होती है?

ollama.com/library पर प्रकाशित download size से शुरुआत करें, जो gemma3:4b के लिए 3.3 GB से लेकर qwen3:30b के लिए 19 GB तक हो सकती है। इसके ऊपर Podman image को जोड़ें, और फिर अतिरिक्त जगह छोड़ें, क्योंकि दूसरा model disk पर पहले वाले को replace नहीं करता है। Pull करने से पहले df -h /home और बाद में du -sh ~/ollama-data/models की जाँच करें। RAM की योजना भी इसी तरह बनाएं: एक model को load होने के दौरान लगभग अपनी file size के बराबर memory की आवश्यकता होती है, साथ ही context window के लिए भी जगह चाहिए।

क्या VPS पर port 11434 को expose करना सुरक्षित है?

नहीं। Ollama में किसी भी प्रकार का authentication नहीं होता है, इसलिए जो कोई भी इस port तक पहुँचता है, वह आपके models को देख सकता है, उन्हें delete कर सकता है, disk पर नए models download कर सकता है, और आपके CPU तथा bandwidth का उपयोग करके inference चला सकता है। internet पर plain HTTP हर prompt और completion को cleartext में भेजता है। Host side को 127.0.0.1 के साथ PublishPort=127.0.0.1:11434:11434 पर bind करें, ss -ltnp | grep 11434 के साथ पुष्टि करें, और इसे SSH tunnel या ऐसे reverse proxy के माध्यम से access करें जिसके लिए password की आवश्यकता हो।

#ollama #podman #rootless#quadlet#selinux #systemd