SSD Nodes Learn 🎉 VPS $5.50/மாதம் முதல்
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor · புதுப்பிக்கப்பட்டது 2026-08-16

VPS-ல் rootless Podman மூலம் Ollama-வை இயக்குவது எப்படி?

VPS-ல் rootless Podman மூலம் Ollama-வை இயக்க பிரத்யேக user, lingering வசதி, Quadlet unit மற்றும் SELinux label அமைப்புகளை எவ்வாறு சரியாக கட்டமைப்பது என்பதை இந்த வழிகாட்டி விளக்குகிறது.

VPS-ல் rootless Podman மூலம் Ollama-வை இயக்குதல்

ஒரு server-ல் rootless Podman மூலம் Ollama-வை இயக்க, desktop வழிகாட்டிகளில் தவிர்க்கப்படும் ஐந்து நிபந்தனைகள் பூர்த்தியாக வேண்டும். ஒரு பிரத்யேக unprivileged user அந்த container-க்கு உரிமையாளராக இருக்க வேண்டும். அந்த user-க்கு lingering வசதி செயல்படுத்தப்பட்டிருக்க வேண்டும், அப்போதுதான் நீங்கள் log out செய்த பிறகும் container தொடர்ந்து இயங்கும். ஒரு Quadlet file அந்த container-ஐ systemd-யிடம் ஒப்படைக்கும், எனவே reboot செய்த பிறகு அது தானாகவே மீண்டும் தொடங்கும். SELinux அமலில் உள்ள distribution-களில், model directory-க்கு உரிய SELinux label இடப்பட வேண்டும். API ஆனது loopback-ல் மட்டுமே கேட்கும் (listen), நீங்கள் அதை SSH (secure shell) tunnel வழியாக அணுக வேண்டும்.

Ollama என்பது large language models (LLM)-க்கான ஒரு server ஆகும். இது model weights-ஐ disk-ல் சேமித்து, அவற்றை memory-ல் ஏற்றி, port 11434-ல் வரும் HTTP கோரிக்கைகளுக்குப் பதிலளிக்கும். இதில் login வசதியோ, API key-யோ அல்லது user account-களோ கிடையாது, எனவே network மட்டுமே உங்களுக்குக் கிடைக்கும் ஒரே access control ஆகும். Podman எந்த daemon-உம் இன்றி, root அனுமதி இல்லாமலேயே container-களை இயக்குகிறது, எனவே container-லிருந்து வெளியேறும் எதுவும் ஒரு சாதாரண unprivileged user-ஆகவே தொடங்கும். உங்களுக்கு முதலில் runtime ஒப்பீடு தேவைப்பட்டால், VPS-ல் Podman மற்றும் Docker எவ்வாறு வேறுபடுகின்றன என்பதைப் படிக்கவும். நீங்கள் container-களைத் தவிர்க்க விரும்பினால், VPS-ல் நேரடியாக Ollama-வை நிறுவுதல் என்பது குறுகிய வழியாகும்.

SSD Nodes அதன் images-ல் Fedora-வை வழங்குகிறது, மேலும் Fedora-வில் Podman மற்றும் SELinux (security-enhanced Linux) ஆகியவை இயல்பாகவே உள்ளன. கீழே உள்ள ஒவ்வொரு கட்டளையும் Podman 5 அல்லது அதற்குப் பிந்தைய பதிப்பைக் கொண்ட எந்தவொரு distribution-லும் இயங்கும்.

சர்வர் சூழலில் லேப்டாப் பதிப்பில் ஏன் மாற்றங்கள் தேவைப்படுகின்றன

Fedora Magazine, 5 August 2026 அன்று இந்த stack குறித்த தெளிவான வழிகாட்டியை வெளியிட்டது: Running Ollama Locally with Podman on Fedora Linux, எழுதியவர் Yazan Monshed. இந்த கருவிகளுடன் தொடங்குவதற்கு இது ஒரு சிறந்த ஆரம்பமாகும். இது ஒரு லேப்டாப்பை மையமாகக் கொண்டது, ஆனால் பொது IP முகவரி கொண்ட ஒரு கணினியில் அதன் நான்கு தேர்வுகள் மாறுபட்ட விளைவுகளை ஏற்படுத்தும்.

  • இது podman run -d கட்டளையுடன் container-ஐத் தொடங்குகிறது. கைமுறையாகத் தொடங்கப்படும் ஒரு container, reboot-க்கு பிறகு தானாக இயங்காது, ஏனெனில் அதைத் தொடங்குவதற்கு எந்த உத்தரவும் வழங்கப்படவில்லை.
  • இது ollama/ollama என்ற மாறக்கூடிய tag-ஐப் பயன்படுத்துகிறது. லேப்டாப்பில், அதன் செயல்பாட்டில் மாற்றம் ஏற்படும்போது நீங்கள் அதை உடனே கவனிக்கலாம். சர்வரில், இரவு நேரத்தில் ஒரு script வேலை செய்யாமல் போவதுதான் அதன் முதல் அறிகுறியாக இருக்கும்.
  • இது -p 11434:11434 மூலம் வெளியிடுகிறது, இது அனைத்து interface-களையும் பிணைக்கிறது (bind). வீட்டு router-க்கு பின்னால் இருக்கும்போது இது இணையத்திலிருந்து அணுக முடியாததாக இருக்கும். ஆனால் ஒரு VPS-ல், இது கடவுச்சொல் இல்லாத பொது inference API-ஆக மாறிவிடும்.
  • இது உங்கள் login பயனர் கணக்கிலேயே இயங்குகிறது. சர்வரில், container-க்கு உரிமையாளராக இருக்கும் கணக்கு வேறு எதையும் கொண்டிருக்கக்கூடாது. அப்போதுதான், ஒருவேளை பாதுகாப்பு மீறல் (break-out) ஏற்பட்டாலும், அது காலியான home directory-க்குள் மட்டுமே முடிவடையும்.

எழுதப்பட்ட அந்த குறிப்பிட்ட கணினிக்கு இவை தவறானவை அல்ல. ஆனால், ஒரு கணினி எங்கிருந்தும் அணுகக்கூடியதாகவும், அதன் முன் யாரும் இல்லாத சூழலிலும் இருக்கும்போது, இந்த ஒவ்வொரு முடிவையும் நீங்கள் மறுபரிசீலனை செய்ய வேண்டும்.

அதிகாரமற்ற (unprivileged) பயனரை உருவாக்கி, subuid-ஐ சரிபார்த்தல்

Rootless Podman, container-க்குள் இருக்கும் பயனர் அடையாளங்களை (UID) host-ல் உள்ள பயன்படுத்தப்படாத அடையாளங்களின் தொகுப்போடு இணைக்கிறது. அந்தத் தொகுப்பு /etc/subuid மற்றும் /etc/subgid கோப்புகளில் குறிப்பிடப்பட்டிருக்கும். இது இல்லையெனில், rootless container-களைத் தொடங்க முடியாது.

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 கட்டளை இரண்டு வரிகளை அச்சிட வேண்டும்; ஒவ்வொரு கோப்பிலிருந்தும் தலா ஒரு வரி, ஒவ்வொன்றும் 65536 அடையாளங்களைக் கொண்ட வரம்பைக் குறிக்கும்:

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

உங்கள் தொடக்க எண் மாறுபடலாம், அது தவறல்ல. grep எதையும் அச்சிடவில்லை என்றால், useradd ஒரு வரம்பை ஒதுக்கவில்லை என்று அர்த்தம். அப்போது அந்தப் பயனராக நீங்கள் இயக்கும் முதல் podman கட்டளை இவ்வாறு தோல்வியடையும்:

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

வேறு எந்தப் பயனரும் வைத்திருக்காத ஒரு வரம்பை ஒதுக்கிவிட்டு, பழைய mapping காலாவதியாகிவிட்டதை Podman-க்குத் தெரிவிக்கவும்:

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

கடவுச்சொல்லைப் பூட்டுவதன் மூலம், யாரும் நேரடியாக ollama பயனராக உள்நுழைய முடியாது. உங்கள் நிர்வாகி பயனரிலிருந்து sudo -iu ollama கட்டளை மூலம் அந்த account-ஐ அணுகலாம்.

Logout செய்த பிறகும் service இயங்குவதற்கு lingering-ஐ செயல்படுத்துதல்

ஒரு பயனரின் systemd instance வழக்கமாக login செய்யும்போது தொடங்கி, logout செய்யும்போது நின்றுவிடும், மேலும் /run/user/<uid> அதனுடன் நீக்கப்படும். அந்தப் பயனருக்குச் சொந்தமான அனைத்து rootless container-களும் அதே நேரத்தில் நின்றுவிடும். Lingering வசதி, எந்த session-ம் இணைக்கப்படாத நிலையிலும் பயனர் instance-ஐ தொடர்ந்து இயங்க வைக்கும்.

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

இது Linger=yes என்பதை அச்சிட வேண்டும். Unit-ஐ உருவாக்கும் முன்பே இதைச் செயல்படுத்தவும், ஏனெனில் 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 பயனர் bus-ஐ $XDG_RUNTIME_DIR/bus-ல் தேடுகிறது, ஆனால் sudo -i அந்த variable-ஐ அமைப்பதில்லை. இந்த service-ஐ நீங்கள் நிர்வகிக்கும் ஒவ்வொரு admin shell-லும் அதை நீங்களே கைமுறையாக அமைக்கவும்:

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

Model blobs சேமிக்கப்படும் இடம் மற்றும் திட்டமிட வேண்டிய disk அளவு

Ollama, container-க்குள் /root/.ollama/models என்ற பாதையில் model weights-ஐ எழுதுகிறது. பயனரின் home directory-ல் உள்ள ஒரு கோப்புறையை அந்தப் பாதையுடன் bind செய்வதன் மூலம், கோப்புகள் நீங்கள் அளவிடக்கூடிய /home/ollama/ollama-data/models என்ற இடத்தில் சேமிக்கப்படும். Blobs-கள் models/blobs என்ற இடத்தில் content-addressed கோப்புகளாகச் சேமிக்கப்படுகின்றன, மேலும் models/manifests என்பது அவற்றை அடையாளம் காணும் சிறிய index-ஐக் கொண்டுள்ளது. Fedora Magazine கட்டுரையில் குறிப்பிட்டுள்ளது போல, நீங்கள் named volume-ஐப் பயன்படுத்தினால், அதே கோப்பு அமைப்பு /home/ollama/.local/share/containers/storage/volumes/<volume>/_data-க்குக் கீழ் அமையும்.

எந்தவொரு கோப்பையும் பதிவிறக்கும் முன் disk அளவைத் திட்டமிடுங்கள். வெளியிடப்பட்ட பதிவிறக்க அளவுகள் உங்களுக்கு ஒரு அடிப்படை அளவை வழங்கும்.

ChartPublished download size per Ollama model tag, ollama.com/library, checked 13 August 2026
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 தளத்தில் வெளியிடப்பட்ட புள்ளிவிவரங்கள்; இவை disk-ல் அளவிடப்பட்ட அளவுகள் அல்ல. இதில் மிகச்சிறிய tag ஆன gemma3:4b, 3.3 GB-ஐப் பதிவிறக்குகிறது. மிகப்பெரிய tag ஆன qwen3:30b, 19 GB-ஐப் பதிவிறக்குகிறது. Container image-ஆனது Podman-ன் சொந்த சேமிப்பகத்தில் இதற்கு மேலாக அமையும், எனவே podman system df மற்றும் df -h /home ஆகியவற்றைப் பயன்படுத்தி இரண்டு அளவுகளையும் சேர்த்துச் சரிபார்க்கவும். ஒரு model இயங்கும்போது, அதன் கோப்பு அளவிற்கு இணையான RAM தேவைப்படும்; அதனுடன் context window-க்கான இடமும் தேவை. எனவே, 16 GB RAM கொண்ட VPS-ல் 19 GB அளவுள்ள model இயங்காது.

Image tag-ஐ pin செய்யவும், முழுமையான 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 அதே பதிப்புகளுக்கு -rc மற்றும் -rocm tag-களையும் வெளியிடுகிறது; உங்களிடம் AMD GPU இல்லையென்றால், plain tag-ஐத் தேர்ந்தெடுக்கவும்.

Registry host-ஐயும் குறிப்பிடவும். Fedora-வில், systemd unit-ல் உள்ள short name-க்கு terminal இல்லாததால், அது பயனரிடம் உள்ளீட்டைக் கேட்க முடியாது; இதனால் unit பின்வரும் பிழையுடன் தோல்வியடையும்:

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

முதலில் கைமுறையாக (manually) pull செய்வது விருப்பத்திற்குரியது, ஆனால் இது பயனுள்ளது. ஏனெனில், பல gigabyte அளவுள்ள download-ஐ unit-ன் start timeout காலத்திற்கு வெளியே இது கொண்டு வந்துவிடும்.

Reboot-க்கு பிறகும் நீடிக்கும் Quadlet unit

Quadlet என்பது Podman-ன் systemd generator ஆகும். நீங்கள் ஒரு .container கோப்பை எழுதினால், systemd அதை boot-ன் போது ஒரு service-ஆக மாற்றும், அப்போது podman generate systemd-ன் தேவை இருக்காது. இதை ollama பயனரின் உரிமையில் /home/ollama/.config/containers/systemd/ollama.container என்ற பெயரில் சேமிக்கவும்.

[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

கோப்பின் பெயர் service-ன் பெயரைத் தீர்மானிக்கிறது, எனவே 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 கட்டளையை இயக்க வேண்டாம். இந்த unit வட்டில் ஒரு கோப்பாக இல்லாததால், systemd அதை நிராகரிக்கும்:

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

[Install] பகுதி ஏற்கனவே அந்த வேலையைச் செய்கிறது. Quadlet ஆனது daemon-reload-ன் போது boot-ல் தொடங்குவதற்கான இணைப்பை (link) தானே உருவாக்குகிறது, அதனால்தான் அந்தக் கட்டளை விருப்பத்திற்குரியது அல்ல. TimeoutStartSec=900 என்பது image-ஐ தரவிறக்கம் செய்ய வேண்டிய முதல் தொடக்கத்தைக் கையாள்கிறது, ஏனெனில் இரண்டு gigabyte தரவிறக்கத்திற்கு இயல்பான 90 வினாடிகள் போதாது, அவ்வாறு இருந்தால் systemd அந்தத் தொடக்கத்தைத் தோல்வியுற்றதாகக் கருதி நிறுத்திவிடும். OLLAMA_KEEP_ALIVE=30m என்பது ஒரு model-ஐ ஐந்து நிமிடங்களுக்குப் பிறகு நீக்குவதற்குப் பதிலாக, கோரிக்கைகளுக்கு இடையே நினைவகத்தில் (memory) வைத்திருக்கும்; இதிலுள்ள சாதக பாதகங்கள் Ollama model-ஐ நினைவகத்தில் வைத்திருத்தல் என்பதில் உள்ளன. இங்கே பயன்படுத்தப்பட்டுள்ள systemd சொற்கள் புதியவை எனில், VPS-ல் systemd services மற்றும் timers எவ்வாறு செயல்படுகின்றன என்பது அந்த unit-களைப் பற்றி விளக்குகிறது.

SELinux-ன் கீழ் model directory-க்கு permission denied என்று ஏன் வருகிறது

Fedora, RHEL, Rocky மற்றும் AlmaLinux ஆகியவற்றில், SELinux இயல்பாகவே அமலில் (enforcing) இருக்கும். ஒரு container process container_t domain-ல் இயங்குகிறது, பயனர் home directory-ல் உள்ள ஒரு கோப்பு user_home_t என்று பெயரிடப்பட்டுள்ளது. இந்த policy ஒன்றையொன்று அணுக அனுமதிப்பதில்லை, எனவே Ollama-வால் அதன் model tree-ஐ உருவாக்க முடியாமல் container வெளியேறுகிறது. இத்தகைய system-களில் getenforce கட்டளையை இயக்கினால் Enforcing என்று காட்டும், மேலும் இந்தத் தடை பதிவு செய்யப்படும்:

sudo ausearch -m avc -ts recent

அதில் 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= வரியின் இறுதியில் உள்ள :Z தான் இதற்கான தீர்வு. இது host directory-ஐ container_file_t என மறுபெயரிட்டு, அந்த container-க்கு மட்டுமே உரிய ஒரு private MCS (multi-category security) category-ஐ முத்திரையிடுகிறது. சிறிய எழுத்து :z ஒரு shared label-ஐப் பயன்படுத்துகிறது; இரண்டு container-கள் ஒரே directory-ஐப் படிக்கும்போது இது தேவைப்படும்.

:Z குறித்து ஒரு எச்சரிக்கை, ஏனெனில் இது தரவுகளை அழிக்கும் தன்மை கொண்டது மற்றும் அமைதியாகச் செயல்படும். இது recurses முறையில் மறுபெயரிடும். இதை /home/ollama-க்குக் குறிப்பிட்டால், அந்த home directory-ல் உள்ள அனைத்துக் கோப்புகளும் மறுபெயரிடப்படும், இது அந்தப் பயனரின் SSH key அணுகலை முடக்கிவிடும். எப்போதும் :Z-க்கு வேறு எந்தக் கோப்பும் இல்லாத ஒரு பிரத்யேக subdirectory-ஐ வழங்கவும். Named volumes-க்கு இது தேவையில்லை, ஏனெனில் Podman அவற்றை உருவாக்கும்போதே சரியாக 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 பக்கத்தை loopback-உடன் இணைக்கிறது. இதை உறுதிப்படுத்தவும்:

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 என்று பதிலளிக்க வேண்டும்.

எந்தப் பக்கத்தை இணைக்கிறீர்கள் என்பதில் கவனமாக இருக்கவும். PublishPort-ல் உள்ள முகவரி host முகவரியாகும். container-க்குள், Ollama அனைத்து interfaces-களிலும் listening நிலையில் இருக்க வேண்டும்; இதுவே image-ன் default அமைப்பாகும். Environment=OLLAMA_HOST=127.0.0.1-ஐ அமைப்பது Ollama-வை container-ன் சொந்த loopback-உடன் இணைத்துவிடும். இதனால் Podman அனுப்பும் traffic container-ன் network முகவரிக்குச் செல்லும், எனவே host-லிருந்து வரும் கோரிக்கைகளும் நிராகரிக்கப்படும்.

திறந்திருக்கும் 11434 port உங்களுக்கு இரண்டு வழிகளில் பாதிப்பை ஏற்படுத்தும். Ollama-வில் authentication கிடையாது, எனவே அந்த port-ஐ அணுகும் எவரும் /api/tags மூலம் உங்கள் models-களைப் பட்டியலிடலாம், /api/generate மூலம் உங்கள் CPU மற்றும் bandwidth-ஐப் பயன்படுத்தி inference இயக்கலாம், புதிய models-களை உங்கள் disk-ல் பதிவிறக்கலாம், மற்றும் ஏற்கனவே உள்ளவற்றை நீக்கலாம். இரண்டாவதாக, remote port-க்கு அனுப்பப்படும் plain HTTP கோரிக்கைகள் prompts மற்றும் completions-களை cleartext-ஆக அனுப்புகின்றன, எனவே வழியில் உள்ள எந்தவொரு machine-ம் அவற்றைப் படிக்க முடியும். port-ஐ அந்த machine-க்குள்ளேயே வைத்திருந்தால் இந்த இரண்டு சிக்கல்களும் நீங்கிவிடும்.

உங்கள் workstation-லிருந்து, SSH வழியாக port-ஐ forward செய்யவும்:

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

இப்போது உங்கள் laptop-ல் உள்ள http://127.0.0.1:11434 என்பது server-ன் 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-க்கு மாற்றவும்.

browser client-க்குத் தேவைப்படும்போது, அதற்கு முன்னால் password-உடன் கூடிய reverse proxy-ஐ அமைக்கவும். Caddy site block நான்கு வரிகளைக் கொண்டது, மேலும் caddy hash-password அதற்குத் தேவையான bcrypt hash-ஐ உருவாக்கும்:

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-வுடன் தொடர்புகொள்ளும் பல கருவிகளில் Authorization header-க்கான இடம் இருக்காது, அவை basic auth-உடன் 401 Unauthorized பிழையைத் தரும். SSH tunnel-ல் இத்தகைய சிக்கல் இல்லை, அதனால்தான் இதுவே பரிந்துரைக்கப்படும் முறையாகும்.

ஒரு model-ஐப் பதிவிறக்கி முழுப் பாதையையும் சரிபார்த்தல்

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 கட்டளையானது gemma3:4b பட்டியலைக் கொண்ட JSON-ஐத் தரும். /api/generate கட்டளையானது, வட்டில் (disk) இருந்து weights ஏற்றப்படும் வரை சிறிது நேரம் காத்திருந்து, response புலத்தைக் கொண்ட ஒரு JSON object-ஐத் தரும். du கட்டளையானது, வெளியிடப்பட்ட பதிவிறக்க அளவை (download size) ஒத்த ஒரு எண்ணைக் காட்ட வேண்டும். அதன் பிறகு, இந்த வழிகாட்டியின் முக்கிய நோக்கமான பகுதியை உறுதிப்படுத்தவும்:

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 இல்லாமல் பயனரின் systemd instance boot-ன் போது தொடங்காது. Lingering செயல்பாட்டில் இருந்தாலும், .container கோப்பில் [Install] பகுதி விடுபட்டிருக்கலாம் அல்லது நீங்கள் கோப்பைத் திருத்திய பிறகு systemctl --user daemon-reload-ஐ இயக்காமல் இருந்திருக்கலாம்.

Error: statfs /home/ollama/ollama-data: no such file or directory. Container தொடங்குவதற்கு முன்பே bind mount source இருக்க வேண்டும். Podman உங்களுக்காக host directories-ஐ உருவாக்காது. ollama பயனராக mkdir -p ~/ollama-data-ஐ இயக்கவும்.

90 வினாடிகளில் தொடங்குதல் தோல்வியடைகிறது. 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 தொடர்பானதா என்பதை அறியலாம். container_t மற்றும் user_home_t ஆகியவற்றைக் குறிப்பிடும் AVC பிழை, :Z விடுபட்டுள்ளதைக் குறிக்கிறது.

Host-லிருந்து வரும் கோரிக்கைகள் நிராகரிக்கப்படுகின்றன. active சேவையுடன் curl: (7) Failed to connect to 127.0.0.1 port 11434: Connection refused பிழை ஏற்பட்டால், பொதுவாக container-க்குள் OLLAMA_HOST என்பது loopback முகவரிக்கு அமைக்கப்பட்டிருப்பதே காரணம். அந்த வரியை நீக்கவும்.

Generation மிக மெதுவாக உள்ளது அல்லது container நிறுத்தப்படுகிறது. GPU இல்லாதபோது, inference CPU-வில் இயங்கும், எனவே பெரிய model இயல்பாகவே மெதுவாக இருக்கும். கோரிக்கையின் பாதியில் container நின்று, logs-ல் signal: killed என்று இருந்தால், அது kernel-ன் out-of-memory killer ஆகும். எனவே, மேலே உள்ள அட்டவணையில் இருந்து சிறிய tag-ஐத் தேர்ந்தெடுக்கவும்.

Pinned image-ஐ புதுப்பித்தல்

Pinning என்பது தானாக நடக்கும் ஒன்றல்ல, நீங்கள் செய்ய வேண்டிய ஒரு செயல்முறை. Image=-ஐ ollama.container-ல் திருத்தி, பின் reload மற்றும் restart செய்யவும்:

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

Models அனைத்தும் bind mount-ல் இருப்பதால், image மாற்றத்திற்குப் பிறகும் அவை பாதிக்கப்படாமல் அப்படியே இருக்கும். [Container] பகுதியில் உள்ள AutoUpdate=registry, மாறிக்கொண்டே இருக்கும் tag-களைப் பயன்படுத்துபவர்களுக்காக உள்ளது. ஒரு நிலையான version tag-உடன் இதைப் பயன்படுத்துவதில் எந்தப் பயனும் இல்லை, ஏனெனில் அந்த tag-ன் உள்ளடக்கம் மாறுவதில்லை. /home/ollama/ollama-data/models/manifests மற்றும் .container கோப்பை backup எடுக்கவும்; blobs-ஐத் தவிர்க்கவும்: அவை அளவில் பெரியவை, மேலும் புதிய server-ல் ollama pull அவற்றை மீண்டும் பதிவிறக்கம் செய்துகொள்ளும்.

FAQ

நான் logout செய்த பிறகு எனது rootless Podman container ஏன் நின்றுவிடுகிறது?

ஒரு பயனர் logout செய்தவுடன், அந்த பயனருக்கான systemd instance மற்றும் அதன் /run/user/<uid> அடைவு (directory) நீக்கப்பட்டுவிடும், அதனுடன் அனைத்து rootless container-களும் நின்றுவிடும். sudo loginctl enable-linger ollama கட்டளையை இயக்கி, loginctl show-user ollama --property=Linger வெளியீடு Linger=yes என உள்ளதா என்பதை உறுதிப்படுத்தவும். Quadlet unit-ஐ உருவாக்கும் முன்பே lingering-ஐ enable செய்யவும், ஏனெனில் அந்த unit-க்குத் தேவையான runtime அடைவு, lingering enabled நிலையில் இருந்தால் மட்டுமே இருக்கும்.

Ollama model அடைவுக்கு SELinux labels தேவையா?

Fedora, RHEL, Rocky மற்றும் AlmaLinux ஆகியவற்றில், நீங்கள் host அடைவை bind mount செய்தால், ஆம், தேவைப்படும். Container-ஆனது container_t domain-ல் இயங்குகிறது, ஆனால் home folder-ல் உள்ள அடைவு user_home_t என label செய்யப்பட்டிருக்கும். இதனால் எழுதும் அனுமதி (write access) மறுக்கப்பட்டு Ollama நின்றுவிடும். Volume= வரியில் :Z என்பதைச் சேர்த்து, ஒரு தனி subdirectory-ஐப் பயன்படுத்தவும். ஏனெனில், label-ஐ மாற்றும்போது அது recursive-ஆகச் செயல்படும், எனவே :Z-ஐ முழு home directory-க்கும் சுட்டிக்காட்டினால் அந்த பயனரின் SSH key அணுகல் பாதிக்கப்படும். Named volumes-க்கு Podman தானாகவே சரியான label-ஐ இடுவதால், கூடுதல் வேலை எதுவும் தேவையில்லை.

ஒரு Ollama model-க்கு எவ்வளவு வட்டு இடம் (disk space) தேவை?

ollama.com/library தளத்தில் குறிப்பிடப்பட்டுள்ள download அளவிலிருந்து கணக்கிடத் தொடங்கவும். இது gemma3:4b-க்கு 3.3 GB முதல் qwen3:30b-க்கு 19 GB வரை இருக்கும். இதனுடன் Podman image-ன் அளவையும் சேர்த்துக்கொள்ளவும். மேலும், கூடுதல் இடவசதியை (headroom) விட்டுவைக்கவும், ஏனெனில் ஒரு புதிய model-ஐப் பதிவிறக்கும்போது பழையது தானாக நீக்கப்படாது. பதிவிறக்குவதற்கு முன் df -h /home கட்டளையையும், பிறகு du -sh ~/ollama-data/models கட்டளையையும் சரிபார்க்கவும். RAM அளவையும் இதேபோல் திட்டமிடவும்: ஒரு model இயங்கும்போது அதன் கோப்பு அளவு மற்றும் context window-க்குத் தேவையான அளவு நினைவகம் தேவைப்படும்.

VPS-ல் 11434 port-ஐத் திறந்து வைப்பது பாதுகாப்பானதா?

இல்லை. Ollama-வில் எந்தவிதமான authentication வசதியும் இல்லை. எனவே, அந்த port-ஐ அணுகும் எவரும் உங்கள் model-களைப் பட்டியலிட, நீக்க, புதியவற்றை உங்கள் வட்டில் பதிவிறக்க, மற்றும் உங்கள் CPU மற்றும் bandwidth-ஐப் பயன்படுத்தி inference இயக்க முடியும். மேலும், இணையத்தில் plain HTTP மூலம் அனுப்பப்படும் அனைத்து prompt மற்றும் completion தகவல்களும் cleartext வடிவிலேயே இருக்கும். Host பக்கத்தில் 127.0.0.1-ஐ PublishPort=127.0.0.1:11434:11434 மூலம் bind செய்யவும், ss -ltnp | grep 11434 மூலம் அதை உறுதிப்படுத்தவும். அந்த port-ஐ SSH tunnel அல்லது password பாதுகாப்பு கொண்ட reverse proxy வழியாக மட்டுமே அணுகவும்.