लेखक: Matt Connor 2026-08-13 · अपडेट किया गया: 2026-09-04

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

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

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

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

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

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

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

Fedora Magazine ने 5 August 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 नहीं कर सकता। आप अपने admin user से sudo -iu ollama के माध्यम से उस account तक पहुँचते हैं।

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

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

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 के अंतर्गत रहता है। किसी भी स्थिति में ollama pull और ollama run वेट्स को एक ही ट्री में लिखते हैं, और दोनों कमांड्स के बीच का अंतर केवल यह है कि डाउनलोड पूरा होने के बाद चैट सेशन खुलता है या नहीं।

कुछ भी पुल (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

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

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

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

पहले manually 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 डायरेक्टरी permission denied क्यों दिखाती है

Fedora, RHEL, Rocky और AlmaLinux पर, SELinux डिफ़ॉल्ट रूप से लागू (enforcing) होता है। एक container process container_t डोमेन में चलती है, और उपयोगकर्ता की home डायरेक्टरी को user_home_t लेबल दिया जाता है। policy एक को दूसरे को छूने की अनुमति नहीं देती है, इसलिए Ollama अपनी model ट्री नहीं बना पाता और container बंद हो जाता है। इन सिस्टम पर getenforce चलाने पर Enforcing प्रिंट होता है, और denial रिकॉर्ड हो जाता है:

sudo ausearch -m avc -ts recent

आपको एक लाइन दिखाई देगी जिसमें डोमेन और target लेबल का नाम होगा:

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= लाइन के अंत में दिया गया :Z इसका समाधान है। यह host डायरेक्टरी को container_file_t पर relabel करता है और उस पर एक private MCS (multi-category security) कैटेगरी लगा देता है जिसे केवल यही container धारण करता है। लोअरकेस :z इसके बजाय एक shared लेबल का उपयोग करता है, जो तब आवश्यक होता है जब दो containers एक ही डायरेक्टरी को पढ़ते हैं।

:Z के बारे में एक चेतावनी, क्योंकि यह विनाशकारी है और चुपचाप काम करती है। Relabelling रिकर्सिव (recursively) होती है। यदि आप इसे /home/ollama पर पॉइंट करते हैं, तो उस home डायरेक्टरी की हर फाइल relabel हो जाएगी, जिससे उस उपयोगकर्ता के लिए SSH key access टूट जाएगा। :Z को हमेशा एक समर्पित सब-डायरेक्टरी दें जिसमें कुछ और न हो। Named volumes के लिए इसकी आवश्यकता नहीं होती, क्योंकि Podman उन्हें बनाते समय सही ढंग से लेबल करता है। यदि आपको अधिक विस्तृत जानकारी चाहिए, तो SELinux basics for a server contexts और booleans की व्याख्या करता है। Ubuntu और Debian पर इसके बजाय AppArmor का उपयोग किया जाता है, वहाँ :Z एक no-op है, और इसे unit में छोड़ देना सुरक्षित है।

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

PublishPort=127.0.0.1:11434:11434 होस्ट साइड को 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 का मतलब है कि पोर्ट इंटरनेट के लिए खुला है, और curl को Ollama is running का उत्तर देना चाहिए।

इस बात को लेकर सटीक रहें कि आप किस साइड को bind कर रहे हैं। PublishPort में दिया गया पता होस्ट का पता है। कंटेनर के अंदर, Ollama को सभी इंटरफेस पर listen करना जारी रखना चाहिए, जो कि इमेज का डिफॉल्ट व्यवहार है। Environment=OLLAMA_HOST=127.0.0.1 सेट करने से Ollama कंटेनर के अपने loopback पर bind हो जाता है, और Podman पब्लिश किए गए ट्रैफ़िक को कंटेनर के नेटवर्क पते पर फॉरवर्ड करता है, इसलिए होस्ट से भी हर अनुरोध अस्वीकार (refuse) कर दिया जाता है।

एक खुला 11434 पोर्ट आपको दो तरह से नुकसान पहुँचाता है। Ollama में कोई प्रमाणीकरण (authentication) नहीं है, इसलिए जो कोई भी इस पोर्ट तक पहुँचता है, वह /api/tags के माध्यम से आपके मॉडल की सूची देख सकता है, /api/generate के माध्यम से आपके CPU और बैंडविड्थ का उपयोग करके इन्फरेंस चला सकता है, आपकी डिस्क पर नए मॉडल डाउनलोड कर सकता है, और आपके पास मौजूद मॉडल को हटा सकता है। दूसरा, रिमोट पोर्ट पर सादा HTTP प्रॉम्प्ट और कंप्लीशन को cleartext में भेजता है, इसलिए रास्ते में आने वाली हर मशीन उन्हें पढ़ सकती है। यदि पोर्ट कभी भी बॉक्स (सर्वर) से बाहर नहीं निकलता है, तो ये दोनों समस्याएँ समाप्त हो जाती हैं।

अपने वर्कस्टेशन से, SSH के माध्यम से पोर्ट को फॉरवर्ड करें:

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

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

जब किसी ब्राउज़र क्लाइंट को इसकी आवश्यकता हो, तो इसके सामने पासवर्ड के साथ एक reverse proxy लगाएँ। Caddy साइट ब्लॉक चार लाइनों का होता है, और caddy hash-password वह bcrypt हैश प्रिंट करता है जिसकी उसे आवश्यकता होती है:

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) पर सर्टिफिकेट प्राप्त कर लेता है, इसलिए ट्रैफ़िक एन्क्रिप्टेड रहता है। पहले अपने क्लाइंट का परीक्षण करें: Ollama से बात करने वाले कई टूल्स में Authorization हेडर के लिए कोई फ़ील्ड नहीं होता है, और वे basic auth के साथ एक खाली 401 Unauthorized पर विफल हो जाएंगे। SSH टनल के साथ ऐसी कोई समस्या नहीं है, यही कारण है कि यहाँ इसे डिफ़ॉल्ट अनुशंसा के रूप में रखा गया है।

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

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 के समय कभी शुरू नहीं होता है। यदि lingering चालू है, तो .container फाइल से [Install] सेक्शन गायब हो सकता है, या आपने फाइल को edit किया है लेकिन systemctl --user daemon-reload नहीं चलाया है।

Error: statfs /home/ollama/ollama-data: no such file or directory। Container शुरू होने से पहले 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 शुरू होकर बंद हो जाता है। podman logs ollama और sudo ausearch -m avc -ts recent एक साथ आपको बताते हैं कि क्या यह SELinux label की समस्या है। यदि AVC में container_t और user_home_t का उल्लेख है, तो इसका मतलब है कि :Z गायब है।

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

Generation बहुत धीमी है, या container kill हो जाता है। GPU न होने पर, inference CPU पर चलता है और एक बड़ा model स्वभाव से धीमा होता है। यदि logs में signal: killed के साथ container request के बीच में ही बंद हो जाता है, तो यह 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 क्यों बंद हो जाता है?

जब किसी 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 deny हो जाता है और Ollama बंद हो जाता है। Volume= line में :Z जोड़ें और इसे एक समर्पित subdirectory दें, क्योंकि relabelling recursive होती है और पूरी home directory को :Z पर 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 चला सकता है। इंटरनेट पर 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