headless VPS-ல் Gemini CLI எப்படி இயக்குவது

நீங்கள் உருவாக்குவது என்ன

நீங்கள் சொந்தமாக வைத்திருக்கும் ஒரு சேவையகத்தில், SSH வழியாக அணுகக்கூடிய, எப்போதும் இயங்கும் ஒரு Gemini CLI. இது நீண்ட நேர agent பணிகளை இயக்கும். நீங்கள் மடிக்கணினியை மூடிய பிறகும் இந்தப் பணிகள் தொடர்ந்து இயங்கும். நிறுவல் மூன்று கட்டளைகளில் முடிந்தது. சிரமம் என்பது டெஸ்க்டாப் இருப்பதைக் கருதும் அனைத்திலுமே உள்ளது. Google-ன் CLI உள்நுழைய ஒரு உலாவியைத் திறக்க முயற்சிக்கும். ஆனால் உங்கள் சேவையகத்தில் உலாவி இல்லை. எனவே இந்த வழிகாட்டியின் பெரும்பகுதி headless பாதையைப் பற்றியதாக உள்ளது. அதாவது, விநியோகம் தராத ஒரு தற்போதைய Node பதிப்பு, root இல்லாமல் செய்யக்கூடிய ஒரு பொதுவான npm நிறுவல், உங்கள் shell வரலாற்றில் இல்லாமல் பாதுகாக்கப்பட்ட API key உடன் உலாவி இல்லாத அங்கீகாரம், மற்றும் SSH இணைப்பு துண்டிக்கப்பட்டால் இயங்கும் பணி பாதிக்கப்படாமல் இருக்க tmux ஆகியவை அடங்கும்.

Gemini CLI என்பது ஒரு திறந்த மூல (Apache-2.0) Node நிரல் (@google/gemini-cli). இது Google-ன் Gemini மாதிரிகளுடன் தொடர்புகொள்கிறது. கோப்புகளைப் படிக்கவும் எழுதவும், shell கட்டளைகளை இயக்கவும், மற்றும் தற்போதைய அடைவில் உள்ள கருவிகளை இயக்கவும் முடியும். ஒரு VPS-ல் இது ஒரு சிறிய, எப்போதும் கிடைக்கக்கூடிய agent. இதை நீங்கள் தொடர்ந்து பணியில் ஈடுபட விடலாம். எனவே, இது எந்தக் கணக்கில் இயங்குகிறதோ அந்தக் கணக்கும், சேவையகத்தில் இருக்கும் சான்றுகளுமே இங்குள்ள வேறு எந்த ஒரு அமைப்பைக் காட்டிலும் முக்கியமானவை.

முன்தேவைகள் மற்றும் நேர்மையான சிக்கல்கள்

• root அல்லது sudo அணுகலுடன் புதிய Ubuntu 24.04 KVM VPS. எந்த KVM திட்டமும் வேலை செய்யும்; CLI மட்டுமே இலகுவானது, ஓய்வு நிலையில் சில நூறு MB RAM தேவைப்படும்.
• Node.js 20 அல்லது புதியது. இதுதான் கடுமையான பதிப்பு கட்டாயம், மேலும் distro தொகுப்பு இதற்கு குறைவாக உள்ளது — அடுத்த பிரிவைப் பார்க்கவும்.
• Google APIகளுக்கு வெளிச்செல்லும் HTTPS (port 443). உள்வரும் portகள் எதுவும் தேவையில்லை; இது ஒரு client, server அல்ல, எனவே இதற்காக நீங்கள் firewall ஓட்டை எதையும் திறக்க மாட்டீர்கள்.
• சேவையகத்தில் browser தேவையில்லாத ஒரு அங்கீகார முறை: Google AI Studio இலிருந்து ஒரு Gemini API key, அல்லது உங்கள் கணினியில் உள்ள browserக்கு மீண்டும் ஒரு SSH tunnel. API-key பாதைதான் scriptகள் மற்றும் கண்காணிப்பில்லாத இயக்கங்களுக்கு ஏற்றது.
• Docker அல்லது Podman, --sandbox தனிமைப்படுத்தல் வேண்டுமானால் மட்டுமே. விருப்பத்தேர்வு, இறுதியில் விளக்கப்பட்டுள்ளது.

அனைவரையும் சிக்க வைக்கும் சிக்கல்: பயனர் நட்பு gemini முதல்-இயக்க உள்நுழைவு செயல்முறை desktopக்காக வடிவமைக்கப்பட்டுள்ளது. இது ஒரு browserஐ திறக்க முயற்சிக்கிறது, மேலும் headless பெட்டியில், தோல்வியடைகிறது அல்லது வேலை செய்யாத ஒரு இணைப்பை உங்களுக்கு கொடுக்கிறது. நீங்கள் தொடங்கும் முன் அங்கீகார பாதையை தீர்மானிக்கவும்.

Node: விநியோகத்தின் தொகுப்பு மிகப் பழையது

Ubuntu 24.04 தனது சொந்த களஞ்சியங்களில் Node 18.19.1-ஐ வழங்குகிறது, இதனுடன் npm 9.2.0 இணைக்கப்பட்டுள்ளது. Gemini CLI-இன் package.json engines: { node: ">=20" }-ஐ வரையறுக்கிறது. npm இயல்பாக இந்தப் பொருத்தமின்மையை நிறுத்தி வைப்பதில்லை — அது எப்படியும் நிறுவுகிறது. பின்னர், இந்த வித்தியாசத்தைக் குறிப்பிடும் எச்சரிக்கையை அச்சிடுகிறது:

npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '@google/gemini-cli@0.50.0',
npm WARN EBADENGINE   required: { node: '>=20' },
npm WARN EBADENGINE   current: { node: 'v18.19.1', npm: '9.2.0' }
npm WARN EBADENGINE }

அந்த எச்சரிக்கையை மீறிச் சென்றால், CLI ஆதரவற்ற இயக்கநேரத்தில் இயங்கும். அங்கு அது Node 20+ API-ஐ அடையும்போது சரியாக வேலை செய்யாமல் போகலாம் அல்லது செயலிழக்கலாம். Node 18-ம் ஏப்ரல் 2025-ல் ஆதரவு காலவரையை எட்டியது. எனவே இது எந்த வகையிலும் முடிவடைந்த பாதையாகும். CLI-ஐ நிறுவுவதற்கு முன்பாக தற்போதைய LTS-ஐ நிறுவவும். இதற்கு இரண்டு சரியான வழிகள் உள்ளன: NodeSource (கணினி அளவிலான கையொப்பமிடப்பட்ட apt களஞ்சியம்) அல்லது nvm (ஒரு பயனருக்கான பதிப்பு மேலாளர்). இரண்டில் ஒன்றைத் தேர்ந்தெடுக்கவும்.

NodeSource, கணினியில் உள்ள அனைத்துப் பயனர்களுக்கும் Node கிடைக்க வேண்டும் என்றால்:

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt-get install -y nodejs
node --version

node --version v20.x அல்லது அதற்கு மேற்பட்டதாக அச்சிட வேண்டும் — v24.x தற்போதைய செயலில் உள்ள LTS ஆகும். தற்போதைய அமைப்பு ஸ்கிரிப்டுக்காக NodeSource பக்கத்தைச் சரிபார்க்கவும்; புதிய LTS வெளியாகும்போது URL-ல் உள்ள setup_24.x-ஐ மேம்படுத்த வேண்டும்.

nvm, Node-ஐ ஒரு பயனரின் இல்லத்திற்குள்ளேயே வைத்து, sudo பயன்படுத்தாமல் இருக்க விரும்பினால்:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
source ~/.bashrc
nvm install --lts
node --version

அந்த URL-ல் உள்ள v0.40.1 இது எழுதப்பட்ட போது தற்போதையதாக இருந்தது; சமீபத்திய வெளியீட்டிற்கு nvm-இன் README-ஐச் சரிபார்த்து, அதை இயக்குவதற்கு முன்பு பதிப்பை மாற்றவும். இந்த வேலைக்கு nvm-க்கு ஒரு உண்மையான நன்மை உள்ளது: இது Node-ஐயும் அதன் உலகளாவிய தொகுப்புகளையும் ~/.nvm கீழ் நிறுவுகிறது. எனவே அடுத்த பிரிவில் உள்ள உலகளாவிய நிறுவல் அனுமதிச் சிக்கல் எழுவதே இல்லை. நீங்கள் nvm வழியைப் பின்பற்றினால், npm-prefix படியைத் தவிர்க்கலாம்.

sudo npm -g இல்லாமல் CLI-ஐ நிறுவுதல்

பயன்படுத்தத் தோன்றும் கட்டளை sudo npm install -g @google/gemini-cli. இதைச் செய்ய வேண்டாம். root-க்குச் சொந்தமான உலகளாவிய முன்னொட்டு ஒவ்வொரு அடுத்தடுத்த நிறுவலிலும் அனுமதிப் பிழைகளை உருவாக்குகிறது. மேலும் உங்கள் npm தற்காலிக சேமிப்பில் root-க்குச் சொந்தமான கோப்புகளை விட்டுச் செல்கிறது. இவை பல மாதங்களுக்குப் பிறகு பிரச்சினையை உருவாக்கும். சாதாரண (sudo இல்லாத) npm install -g-ஐ கணினி Node-க்கு எதிராக இயக்கினால் மற்றொரு தோல்வி ஏற்படுகிறது:

npm error code EACCES
npm error syscall mkdir
npm error path /usr/lib/node_modules/@google
npm error errno -13
npm error Error: EACCES: permission denied, mkdir '/usr/lib/node_modules/@google'

இது npm-ஆல் /usr/lib-ல் எழுத முயற்சிப்பதால் நிகழ்கிறது. அதில் உங்கள் பயனருக்கு எழுதும் உரிமை இல்லை. இதற்கான தீர்வு sudo அல்ல. அதற்குப் பதிலாக npm-ன் உலகளாவிய முன்னொட்டை உங்கள் முகப்புக் கோப்பகத்தை நோக்கித் திருப்ப வேண்டும். அப்போது உலகளாவிய நிறுவல்கள் உங்களுக்குச் சொந்தமான இடத்தில் செல்லும்:

mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
npm install -g @google/gemini-cli
gemini --version

~/.profile-க்குப் பதிலாக ~/.bashrc என்பது வேண்டுமென்றே தேர்ந்தெடுக்கப்பட்டது. tmux — இதற்குள் நீங்கள் இனி வரும் இரண்டு பிரிவுகளில் CLI-ஐ இயக்கப் போகிறீர்கள் — ஒரு புகுபதிகை அல்லாத ஷெல்லைத் தொடங்குகிறது. அது ~/.bashrc-ஐ மட்டுமே படித்து ~/.profile-ஐ தவிர்க்கிறது. ஆகையால் தவறான கோப்பில் இருக்கும் PATH வரி, நீங்கள் அதை மிகவும் தேவைப்படும் இடத்தில் gemini-ஐ கண்ணுக்குத் தெரியாதபடி மறைத்துவிடும். gemini --version ஒரு பதிப்பு எண்ணை அச்சிடுவதே முழுமையான சோதனை. அதற்குப் பதிலாக நீங்கள் gemini: command not found பெற்றால், உங்கள் PATH ஏற்றுமதி நடைபெறவில்லை. தோல்வி நிலைகளைப் பார்க்கவும். nvm-ல் முன்னொட்டு வரிகளை முற்றிலும் தவிருங்கள். அது ஏற்கனவே உங்கள் முகப்புக் கோப்பகத்தின் கீழ் உலகளாவிய நிறுவல்களைச் செய்கிறது.

நீங்கள் ஏதோ ஒரு முன்னர் sudo npm-ஐ இயக்கியிருந்து இப்போது Your cache folder contains root-owned files காண்கிறீர்கள் என்றால், ஒரு முறை sudo chown -R $(id -u):$(id -g) ~/.npm-உடன் அதைச் சரிசெய்யவும்.

Headless அங்கீகாரப் பிரச்சினை, அதை எப்படித் தவிர்ப்பது

முதல் முறை gemini-ஐ இயங்குமுறையில் இயக்கினால், உங்கள் Google கணக்கைப் பயன்படுத்தி உள்நுழைய விருப்பம் தரப்படும். டெஸ்க்டாப்பில் இது ஒரு browser தாவலைத் திறக்கும். Headless VPS-ல் browser இல்லை. எனவே, இந்தச் செயல்முறை நீங்கள் திறக்க வேண்டிய ஒரு localhost URL-ஐ அச்சிடும், அல்லது பின்வருமாறு நேரடியாகத் தோல்வியடையும்:

Failed to open browser. Please visit the following URL to authorize:
https://accounts.google.com/o/oauth2/v2/auth?...&redirect_uri=http://localhost:PORT

இங்கே சிக்கல் redirect_uri=http://localhost:PORT. நீங்கள் அந்த URL-ஐ உங்கள் மடிக்கணினியில் திறந்து அங்கீகரித்தாலும், Google அதை http://localhost:PORT-க்குத் திருப்பி விடும். அது சேவையகத்தின் localhost — உங்கள் மடிக்கணினியால் அணுக முடியாத ஒரு போர்ட். உள்நுழைவு ஒருபோதும் முடிவதில்லை.

இதற்கு இரண்டு சரியான வழிகள் உள்ளன.

முதலாவது API key. இதுவே ஒரு சேவையகத்திற்கான சரியான இயல்புநிலை முறை. Google AI Studio (aistudio.google.com)-ல் ஒரு key உருவாக்கி, அதை ஒரு environment variable மூலம் CLI-க்குக் கொடுங்கள். அது GEMINI_API_KEY-ஐப் படித்து browser செயல்முறையை முற்றிலும் தவிர்க்கும். இப்போது "அதை வரலாற்றிலும் பிறர் படிக்கக்கூடிய கோப்புகளிலும் வைக்கக் கூடாது" என்பதைப் பார்ப்போம். export GEMINI_API_KEY=AIza...-ஐ prompt-ல் தட்டச்சு செய்ய வேண்டாம் — அது ~/.bash_history-ல் cleartext-ஆகச் சேமிக்கப்படும். பிறர் படிக்கக்கூடிய கோப்பிலும் அதை வைக்க வேண்டாம். அதை mode-600 கோப்பில் எழுதுங்கள்; shell தொடங்கும்போது இந்தக் கோப்பைப் படிக்கும்:

umask 077
printf 'export GEMINI_API_KEY=%s\n' 'AIzaSyYOUR_KEY_HERE' > ~/.gemini_env
chmod 600 ~/.gemini_env
echo '[ -f ~/.gemini_env ] && . ~/.gemini_env' >> ~/.bashrc
source ~/.bashrc

chmod 600 என்பது உங்கள் பயனர் மட்டுமே அந்தக் கோப்பைப் படிக்க முடியும் என்பதைக் குறிக்கிறது. printenv GEMINI_API_KEY கட்டளையை இயக்கி அந்த key environment-ல் வந்ததா எனப் பாருங்கள். அது எதையும் அச்சிடவில்லை என்றால், CLI மீண்டும் browser செயல்முறைக்கே திரும்பும்; அது தோல்வியடையும். அது ~/.gemini/-ல் உள்ள .env கோப்பையும் படிக்கும். அந்த அமைப்பு உங்களுக்கு விருப்பமென்றால் அதையும் பயன்படுத்தலாம் — விதி ஒன்றே, எனவே chmod 600 ~/.gemini/.env.

இரண்டாவது வழி, OAuth callback-ஐ உங்கள் மடிக்கணினிக்கு tunnel செய்வதன் மூலம் தனிப்பட்ட Google கணக்கு உள்நுழைவையும் (அதன் இலவச அடுக்கையும்) தக்கவைக்கிறது. இதில் உள்ள சிக்கல், CLI-ன் loopback சேவையகம் ஒவ்வொரு முறையும் ஒரு random போர்ட்டைப் பயன்படுத்துகிறது. எனவே, நீங்கள் முதலில் OAUTH_CALLBACK_PORT environment variable மூலம் அந்தப் போர்ட்டை நிர்ணயித்தாலன்றி, அதை forward செய்ய நிலையான எதுவும் இருக்காது. பின்னர் அந்தக் குறிப்பிட்ட போர்ட்டை மட்டும் forward செய்யுங்கள்:

# from your laptop, forward the callback port into the SSH session:
ssh -L 8085:localhost:8085 user@your-server
# then, on the server, pin the callback to the same port and start the CLI:
export OAUTH_CALLBACK_PORT=8085
gemini

CLI ஒரு browser-ஐத் திறக்க முடியாது. எனவே அது auth URL-ஐ அச்சிடும். அதை உங்கள் மடிக்கணினி browser-ல் திறந்து அங்கீகரியுங்கள். Google அதை http://localhost:8085/...-க்குத் திருப்பியனுப்பும்போது, SSH forward அதை VPS-ல் உள்ள loopback சேவையகத்திற்குக் கொண்டு செல்லும்; உள்நுழைவு முடிவடையும். போர்ட்டை நிர்ணயிக்காவிட்டால், ஒவ்வொரு முறையும் அது புதிய random போர்ட்டிற்குச் செல்லும். முன்கூட்டியே அமைக்கப்பட்ட எந்த ssh -L-ஆலும் அதைப் பிடிக்க முடியாது. இது வேலை செய்யும். ஆனால், இதற்கு நீங்கள் ஒரு browser முன் அமர்ந்திருக்க வேண்டும். எனவே இது script-களுக்குப் பொருத்தமற்றது. நீங்கள் தொடர்ந்து இயக்கிவிடும் எதற்கும் API key-ஐப் பயன்படுத்துங்கள்.

AI Studio-க்குப் பதிலாக Vertex AI அல்லது ஒரு Google Cloud project-ஐப் பயன்படுத்தினால், GOOGLE_API_KEY-ஐ GOOGLE_GENAI_USE_VERTEXAI=true-உடன் சேர்த்து அமையுங்கள். அல்லது Code Assist உரிமத்திற்கு GOOGLE_CLOUD_PROJECT-ஐ அமையுங்கள் — அதே environment-variable ஒழுங்கு, அதே mode-600 கோப்பு.

SSH இணைப்பு துண்டிக்கப்பட்டாலும் செயல்முறை நிற்பதற்கு tmux க்குள் இயக்கவும்

நீங்கள் SSH shell இலிருந்து நேரடியாக இயக்கும் gemini செயல்முறை அந்த shell இன் சேயாக இருக்கும். இணைப்பு துண்டிக்கப்பட்டால் — மடிக்கணினி மூடப்படுதல், Wi-Fi துண்டிக்கப்படுதல், செயலற்ற நேர முடிவு — sshd அந்த pseudo-terminal ஐ இழுத்து அழிக்கிறது, shell க்கு SIGHUP கிடைக்கிறது, அது மீண்டும் CLI ஐத் துண்டிக்கிறது. கோப்புகளைத் திருத்தி 10 நிமிடம் ஆகியிருக்கும் ஒரு பணி அதனுடன் செத்துப்போகிறது. மீண்டும் இணைத்தால் மீட்க எந்தச் செயல்முறையும் இருக்காது.

shell ஐ sshd க்குப் பதிலாக tmux வைத்திருப்பதன் மூலம் இந்தப் பிரச்சினையை தீர்க்கிறது. இது தொலைநிலை VPS இல் tmux க்குள் AI குறியீட்டு முகவரை இயக்குவதைப் போன்ற அதே முறையாகும். இது இங்கும் ஒரே மாதிரியாகச் செயல்படுகிறது:

sudo apt install -y tmux
tmux new -A -s gemini
# inside the session:
gemini
# detach with Ctrl-b then d — the task keeps running
# reconnect later from any machine:
tmux attach -t gemini

tmux new -A -s gemini என்பது gemini என்ற பெயருடைய session இருந்தால் அதை இணைக்கிறது; இல்லையென்றால் உருவாக்குகிறது. எனவே ஒவ்வொரு உள்நுழைவுக்கும் பிறகும் இயக்க வேண்டிய ஒரே ஒரு கட்டளை இதுதான். உள்ளே இருக்கும் shell உங்கள் SSH session க்குச் சொந்தமானதல்ல; பிரிக்கப்பட்ட tmux server க்குச் சொந்தமானது. எனவே இணைப்பைத் துண்டித்தாலும் CLI வேலை செய்வதை நிறுத்துவதில்லை. மீண்டும் இணைத்து, attach செய்தால் நீங்கள் அதே scrollback இல் திரும்புவீர்கள்.

ஊடாடாத, ஸ்கிரிப்ட் மூலமான இயக்கங்களுக்கு, Gemini CLI க்கு headless பயன்முறை உண்டு: gemini -p "summarise the failing tests in this repo" ஒரு பதிலை அச்சிட்டு வெளியேறுகிறது. --output-format json வேறிடத்திற்குப் பைப் செய்ய இயந்திரம் படிக்கக்கூடிய வெளியீட்டைத் தருகிறது. API key உடன் கூடிய headless பயன்முறைதான் நீண்ட batch பணியை இயக்கும் tmux session க்குள், அல்லது cron entry இலிருந்து இயக்குவதற்குத் தேவையானது — ஒரு எச்சரிக்கை: cron பணி உங்கள் எந்த login கோப்பையும் ஏற்றுவதில்லை. எனவே crontab வரிக்கு அதற்கே உரிய GEMINI_API_KEY ஐக் கொடுக்கவும் (அல்லது கட்டளை ~/.gemini_env ஐ ஏற்றச் செய்யவும்). இல்லையென்றால், CLI browser flow க்குத் திரும்பி தோல்வியடையும்.

உற்பத்தியும் இயங்கும் ஒரு சேவையகத்தில் சாண்ட்பாக்ஸிங் மற்றும் அனுமதிகள்

ஷெல் அணுகல் கொண்ட ஒரு முகவர் என்பது ஒரு ஷெல்லே. Gemini CLI கட்டளைகளை இயக்க முடியும். இயல்பாக, ஒவ்வொரு ஆபத்தான கட்டளைக்கும் முன் அது கேட்கும். ஆனால் பயனர்கள் --yolo (ஒவ்வொரு கருவி அழைப்பையும் தானாக அங்கீகரிக்கவும்) என்பதைப் பயன்படுத்துவார்கள். அப்போது அது கோப்புகளை நீக்கலாம், git க்கு push செய்யலாம், அல்லது அது இயங்கும் பயனரின் முழு அதிகாரத்துடன் உள்ளக சேவைகளைத் தொடலாம். உற்பத்தியும் இயங்கும் சேவையகத்தில், இது ஒரு நிஜமான பெரிய பாதிப்பு; ஊகம் அல்ல.

மூன்று கட்டுப்பாடுகள், அவை தரும் பாதுகாப்பின் அளவின் வரிசையில்:

• இதை ஒரு பிரத்யேக, அதிகாரமற்ற பயனராக இயக்கவும். root ஆக அல்ல, sudo உறுப்பினராகவும் அல்ல. சொந்த home கொண்ட ஒரு agent பயனரை உருவாக்கவும். அங்கே Node மற்றும் CLI ஐ நிறுவவும். ஒரு தவறாக வாசிக்கப்பட்ட அறிவுறுத்தல் அந்தக் கணக்கிற்குள்ளேயே தடுக்கப்படும். இதுதான் மிக உயர்ந்த மதிப்புள்ள முடிவு.
• உற்பத்தி சான்றாணைகளை சேவையகத்திலிருந்து விலக்கி வைக்கவும். prod ~/.aws/credentials இல்லை, உற்பத்தியிலிருந்து நகலெடுக்கப்பட்ட .env இல்லை, முக்கியமான எதையும் எழுத அனுமதி கொண்ட தரவுத்தள கடவுச்சொல் இல்லை. அதற்கு ஒரு staging அல்லது படிக்க மட்டுமே அனுமதிக்கும் சான்றாணையைக் கொடுக்கவும்.
• உள்ளமைக்கப்பட்ட சாண்ட்பாக்ஸைப் பயன்படுத்தவும். Docker அல்லது Podman நிறுவப்பட்டிருந்தால், gemini --sandbox (அல்லது GEMINI_SANDBOX=docker) முகவரின் கருவி அழைப்புகளை ஹோஸ்ட் கோப்பு முறைமை மற்றும் நெட்வொர்க்கிலிருந்து தனிமைப்படுத்தப்பட்ட ஒரு கொள்கலனுக்குள் இயக்கும். இது அதிகாரமற்ற பயனுக்கு மாற்றாக இல்லை. ஆனால் அதே VPS உண்மையான வேலையைச் செய்யும்போது, இது ஒரு வலுவான இரண்டாவது பாதுகாப்பு அடுக்கு.

நீங்கள் Gemini CLI ஐ மற்ற சுய-ஹோஸ்ட் செய்யப்பட்ட கருவிகளுக்கு அருகில் இயக்கினால் — உதாரணமாக, அதே VPS இல் முகவருக்கு கருவிகளை வெளிப்படுத்தும் ஒரு MCP சேவையகம் — சேர்க்கப்படும் ஒவ்வொரு திறனையும் முகவர் அடையக்கூடிய கூடுதல் மேற்பரப்பாகக் கருதவும். அதற்குக் கொடுக்கப்படும் டோக்கன்களை ஒரே ஒரு வேலைக்கு மட்டும் வரம்பிடவும்.

கோட்டா, செலவு, மற்றும் நீங்கள் தேர்ந்தெடுத்த அங்கீகார பாதை

அங்கீகார பாதை உங்களுக்கு எப்படி பில் செய்யப்படும் என்பதை தீர்மானிக்கிறது. தனிப்பட்ட Google கணக்கு (OAuth பாதை) இலவச Gemini Code Assist அடுக்கைப் பயன்படுத்துகிறது. இதற்கு நிமிடத்திற்கு மற்றும் நாளொன்றிற்கான உண்மையான வரம்புகள் உள்ளன. இந்த வரம்புகளை தாண்டினால், சாளரம் மீட்டமைக்கப்படும் வரை கோரிக்கைகள் rate-limit பிழையை திருப்பியனுப்பும். AI Studio இலிருந்து வரும் API key திட்டத்தைப் பொறுத்து இலவச-அடுக்கு அல்லது பில் செய்யப்பட்டதாக இருக்கலாம். பில் செய்யப்பட்ட key வரம்புகளை உயர்த்துகிறது. மேலும் இது token க்கு ஏற்ப கட்டணம் வசூலிக்கிறது. Vertex மற்றும் Cloud-project அங்கீகாரம் Google Cloud வழியாக பில் செய்யப்படுகின்றன.

இரண்டு நடைமுறை குறிப்புகள். ஒரு லூப்பில் இயங்கும் கண்காணிக்கப்படாத agent கோட்டாவை விரைவாக தீர்த்துவிடும். எனவே, இதை cron job க்கு ஒப்படைப்பதற்கு முன் முதல் சில முறை கவனியுங்கள். மேலும், சர்வர்-பக்க மாதிரியை நீங்கள் தேர்ந்தெடுத்ததற்கான காரணம் Google இன் ஹோஸ்ட் செய்யப்பட்ட மாதிரிகளை விட தனியுரிமை அல்லது அளவிடப்படாத inference என்றால், அது வேறொரு கருவி — VPS இல் Ollama உடன் திறந்த LLM ஐ சுய-ஹோஸ்ட் செய்வது weights மற்றும் prompts ஐ உங்கள் சொந்த சர்வரிலேயே வைத்திருக்கும். ஆனால் இதற்கு ஈடாக Gemini ஐ விட மிகவும் சிறிய மாதிரியை இயக்க வேண்டும்.

புதுப்பித்து வைத்தல்

Gemini CLI அடிக்கடி வெளியிடப்படுகிறது. நீங்கள் இதை user-owned prefix-இல் நிறுவியுள்ளதால், புதுப்பிக்க sudo தேவையில்லை:

npm install -g @google/gemini-cli@latest
gemini --version

வெளியீட்டு சேனல்கள் உள்ளன: @latest உறுதியானது, @preview வாராந்திர preview, @nightly மிகவும் மேம்பட்ட பதிப்பு — நீங்கள் நம்பியிருக்கும் எதிலும் @latest-ஐ பின்தொடரவும். nvm-ல், உலகளாவிய தொகுப்புகள் தற்போதைய Node பதிப்பின் கீழ் இருப்பதால், Node-ஐ மாற்ற nvm use-க்குப் பிறகு நீங்கள் CLI-ஐ மீண்டும் நிறுவ வேண்டியிருக்கலாம். ஒவ்வொரு patch-ஐயும் துரத்துவதை விட வெளியீட்டு குறிப்புகளைப் படிக்கவும்.

பிழை நிலைகள், சரியான சரங்களுடன்

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }, பிறகு இயக்க நேரத்தில் CLI செயலிழக்கிறது. Node பதிப்பு மிகப் பழையது — distro-வின் பதிப்பு 18.19.1, இதுவும் ஆதரவு காலவரம்பைக் கடந்தது. NodeSource அல்லது nvm மூலம் Node 20+ நிறுவவும், node --version உடன் உறுதிப்படுத்தவும், மேலும் பல Node நிறுவல்கள் இருந்தால், which node புதிய பதிப்பைச் சுட்டுகிறதா மற்றும் /usr/bin/node ஐ அல்ல என சரிபார்க்கவும்.

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. root-க்கு சொந்தமான prefix-க்குள் ஒரு global நிறுவல். இதற்கு sudo பயன்படுத்த வேண்டாம் — npm config set prefix ~/.npm-global ஐ அமைக்கவும், ~/.npm-global/bin ஐ PATH இல் சேர்க்கவும், மேலும் உங்கள் சாதாரண பயனராக மீண்டும் நிறுவவும். ஒரு முந்தைய sudo npm root-க்கு சொந்தமான cache கோப்புகளை (Your cache folder contains root-owned files) விட்டுச் சென்றிருந்தால், sudo chown -R $(id -u):$(id -g) ~/.npm ஐ இயக்கவும்.

Failed to open browser, ஒரு login தொங்குகிறது, அல்லது நீங்கள் அணுக முடியாத redirect_uri=http://localhost:PORT. OAuth flow க்கு சர்வரில் இல்லாத ஒரு browser தேவை, மேலும் அதன் localhost callback உங்கள் மடிக்கணினியை அல்லாமல் சர்வரைச் சுட்டுகிறது. API-key பாதையைப் பயன்படுத்தவும் (GEMINI_API_KEY), அல்லது OAUTH_CALLBACK_PORT ஐ பின் செய்யவும், ssh -L உடன் SSH வழியாக அனுப்பவும், மேலும் URL-ஐ உள்ளூரில் திறக்கவும்.

SSH துண்டிக்கப்பட்டபோது செயல்முறை மறைந்தது. நீங்கள் gemini ஐ SSH shell-இல் இருந்து நேரடியாக இயக்கினீர்கள், எனவே அது அந்த shell-ன் ஒரு child ஆக இருந்தது மற்றும் இணைப்பு துண்டிக்கப்படும்போது pty உடன் இறந்தது. மீட்க ஏதுமில்லை. ஒவ்வொரு அமர்வையும் tmux new -A -s gemini உடன் தொடங்கி அதற்குள் CLI-ஐ இயக்கவும்.

விசை அமைக்கப்பட்டிருந்தும் auth தோல்வியடைகிறது — CLI அதன் auth picker-க்குத் திரும்புகிறது, அல்லது ஒரு கோரிக்கை HTTP 400 உடன் API key not valid ஐத் தருகிறது. விசை CLI பார்க்கும் environment-ல் இல்லை. printenv GEMINI_API_KEY உடன் உறுதிப்படுத்தவும்; அது வெறுமையாக இருந்தால், உங்கள் ~/.gemini_env கொண்டு வரப்படவே இல்லை — அந்த வரி ~/.bashrc இல் உள்ளதா எனச் சரிபார்க்கவும், இதை interactive shells (tmux உட்பட) படிக்கும் ஆனால் cron மற்றும் பிற non-interactive shells படிக்காது. விசை மதிப்புக்குள் தவறான ஒரு space அல்லது quote ம் API key not valid ஐ உருவாக்கும்.

429 / RESOURCE_EXHAUSTED / ஒரு rate-limit செய்தி. உங்கள் auth பயன்படுத்தும் tier-ன் quota-வை நீங்கள் தாக்கியுள்ளீர்கள். window மீண்டும் சீரமைக்க காத்திருக்கவும், agent-ஐ மெதுவாக்கவும், அல்லது கட்டணம் செலுத்தும் API விசைக்கு மாறவும். ஒரு agent retry loop-ல் சிக்கித் தவித்தால் இதைத் தொடர்ந்து தாக்கும் — அதை நிறுத்தி அது என்ன செய்கிறது எனச் சரிபார்க்கவும்.

FAQ

ஒரு headless server-ல் Gemini CLI-ஐ எப்படி authenticate செய்வது?

Browser login-ஐ பயன்படுத்தாதீர்கள்; API key பயன்படுத்துங்கள். Google AI Studio-ல் ஒரு key உருவாக்குங்கள். அதை உங்கள் shell source செய்யும் mode-600 file-ல் வையுங்கள் (export GEMINI_API_KEY=...). அப்போது CLI OAuth browser flow-ஐ முற்றிலும் தவிர்க்கும். குறிப்பாக உங்களுக்கு personal-account free tier தேவைப்பட்டால், OAUTH_CALLBACK_PORT=8085 கொண்டு loopback port-ஐ pin செய்யுங்கள். ssh -L 8085:localhost:8085 user@server மூலம் அதை உங்கள் laptop-க்கு forward செய்யுங்கள். பின்னர் அச்சிடப்பட்ட URL-ஐ உள்ளூரில் திறக்கவும். ஆனால் இதற்கு ஒரு browser-ல் நீங்கள் நேரில் இருக்க வேண்டும். எனவே இது script-களுக்கு ஏற்றதல்ல.

npm global install ஏன் sudo கேட்கிறது, மேலும் நான் அதை எப்படி தவிர்ப்பது?

npm-ன் default global prefix /usr/lib/node_modules ஆகும். உங்கள் user-க்கு அங்கு write செய்ய அனுமதி இல்லை. எனவே சாதாரண npm install -g கட்டளை EACCES பிழையுடன் தோல்வியடைகிறது. தவறான தீர்வு sudo npm -g. இது root-க்கு சொந்தமான file-களை உருவாக்குகிறது. அவை பிற்கால install-களைப் பழுதாக்கும். சரியான தீர்வு: prefix-ஐ உங்கள் home-க்கு மாற்றுங்கள் (npm config set prefix ~/.npm-global). அதன் bin-ஐ PATH-ல் சேர்க்கவும். அல்லது nvm பயன்படுத்துங்கள்; அது global package-களை தானாக உங்கள் home-க்குள் install செய்யும்.

நான் disconnect செய்த பிறகும் Gemini CLI இயங்கிக்கொண்டிருக்க எப்படி செய்வது?

அதை tmux-க்குள் இயக்குங்கள். உங்கள் SSH shell-ல் இருந்து தொடங்கப்பட்ட ஒரு process, அந்த shell-ன் child ஆகையால் connection துண்டிக்கப்படும்போது முடிந்துவிடும். tmux அந்த shell-ஐ ஒரு detached server-க்குள் இயக்குகிறது. அது disconnect-ஐ தாங்கி நிற்கும். tmux new -A -s gemini பயன்படுத்துங்கள். உள்ளே gemini இயக்கவும். Ctrl-b d மூலம் detach செய்யவும். பின்னர் tmux attach -t gemini மூலம் மீண்டும் attach செய்து கொள்ளவும்.

ஒரு production box-ல் Gemini CLI-ஐ இயக்குவது பாதுகாப்பானதா?

கவனத்துடன் மட்டுமே பாதுகாப்பானது. Shell அணுகல் கொண்ட ஒரு agent, அது இயங்கும் user-க்கு சாத்தியமான அனைத்தையும் செய்ய முடியும். அதை sudo அற்ற ஒரு பிரத்யேக unprivileged user-ஆக இயக்குங்கள். production credentials-ஐ அந்த machine-ல் வைக்க வேண்டாம். --yolo auto-approval-ஐ தவிர்க்கவும். tool call-களை host-லிருந்து பிரிக்க --sandbox (Docker அல்லது Podman) பயன்படுத்தவும். நீங்கள் அமைக்கும் எந்த ஒரு flag-ை விடவும், அது இயங்கும் account முக்கியமானது.

Gemini CLI-க்காக ஏதேனும் firewall port-களை திறக்க வேண்டுமா?

இல்லை. அது Google-ன் API-களுக்கு outbound HTTPS call-களை மட்டுமே செய்யும் ஒரு client. எனவே அதற்கு outbound port 443 தேவை, inbound port-கள் தேவையில்லை. நீங்கள் OAuth tunnel பயன்படுத்தினால், pin செய்யப்பட்ட callback port (உதாரணமாக 8085) localhost-ல் இயங்கும். அது ஒரு திறந்த inbound port வழியாக அல்லாமல், உங்கள் SSH forward வழியாக அணுகப்படும். inbound-ஐ பூட்டப்பட்ட நிலையிலேயே வையுங்கள்.