Open Connector-ஐ சொந்தமாக host செய்வது எப்படி?

AI agent-க்கு Open Connector என்ன செய்கிறது

Open Connector-ஐ நீங்களே host செய்வதன் மூலம், உங்கள் AI agent-களுக்கும் அவை அழைக்கும் ஒவ்வொரு software as a service (SaaS) API-க்கும் இடையே ஒரு அங்கீகார நுழைவாயிலை (auth gateway) உருவாக்கலாம். இதனால், எந்தவொரு provider token-ம் agent-ன் வசம் இருக்காது. இது OOMOL Lab-ன் திறந்தநிலை மென்பொருள் (open source gateway) ஆகும், இது Apache 2.0 உரிமத்தின் கீழ் கிடைக்கிறது. இது ஒரே container-ஆக இயங்குகிறது, தனது தரவுகளை ஒரே ஒரு SQLite கோப்பில் சேமிக்கிறது, மேலும் provider செயல்களை HTTP மற்றும் MCP (model context protocol) வழியாக வழங்குகிறது.

இரண்டாவது integration-ஐச் செய்யும்போதுதான் சிக்கல்கள் தொடங்குகின்றன. ஒவ்வொரு provider-க்கும் தனித்தனி OAuth (open authorization) முறை, refresh token காலாவதி நேரம் மற்றும் scope பெயர்கள் உள்ளன. ஐந்து provider-களை agent-உடன் கைமுறையாக இணைக்க வேண்டுமெனில், ஐந்து redirect handler-கள், ஐந்து credential store-கள் மற்றும் token காலாவதியாவதற்குள் இயங்க வேண்டிய ஐந்து refresh loop-கள் தேவைப்படும். இந்த குறியீட்டை யாரும் எழுதுவதில்லை. அதற்குப் பதிலாக, ஒவ்வொரு சேவைக்கும் ஒரு நீண்ட கால personal access token-ஐ உருவாக்கி, அதை agent config, environment file அல்லது prompt-ல் பதிவிடுகிறார்கள். அந்த token-ஐ agent இயக்கும் அனைத்து கருவிகளும் படிக்க முடியும், மேலும் அது transcript-ல் பதிவாகிவிடும். இது AI agent-களில் ரகசியங்களை எவ்வாறு பாதுகாப்பது என்ற பகுதியில் விவரிக்கப்பட்டுள்ள பாதுகாப்பு மீறலுக்கு வழிவகுக்கிறது.

ஒரு auth gateway, credential-ஐ இரண்டாகப் பிரிக்கிறது. இந்த gateway, provider credential-ஐச் சேமித்து OAuth செயல்பாட்டை இயக்குகிறது. Agent-க்கு, gateway-ல் மட்டுமே செல்லுபடியாகும் ஒரு runtime token மட்டுமே கிடைக்கிறது. Agent ஒரு செயலை அழைக்கும்போது, gateway சேமிக்கப்பட்ட credential-ஐ ஏற்றி, அதை server பக்கத்தில் outbound request-ல் இணைத்து, response body-ஐ மட்டும் திருப்பி அனுப்புகிறது. Agent-க்கு provider access token ஒருபோதும் கிடைப்பதில்லை. எனவே, ஒருவேளை agent transcript கசிந்தாலும், உங்கள் GitHub கணக்கிற்குப் பதிலாக, எளிதில் நீக்கக்கூடிய ஒரு runtime token மட்டுமே பாதிப்புக்குள்ளாகும்.

இந்த catalog 1,000-க்கும் மேற்பட்ட provider-களையும் 10,000-க்கும் மேற்பட்ட முன்-தயாரிக்கப்பட்ட செயல்களையும் (prebuilt actions) கொண்டிருப்பதாகக் கூறுகிறது; இது திட்டத்தின் சொந்த புள்ளிவிவரமாகும், இதை வெளியில் இருந்து சரிபார்க்க முடியாது. ஆனால், அதன் கட்டமைப்பை நீங்கள் சரிபார்க்க முடியும்: ஒரு செயலுக்கு ஒரு HTTP endpoint, ஒரு provider-க்கு ஒரு சேமிக்கப்பட்ட இணைப்பு, ஒரு agent-க்கு ஒரு token.

ஹோஸ்ட் செய்யப்பட்ட கனெக்டர் சேவையைப் பயன்படுத்துவதற்குப் பதிலாக Open Connector-ஐ ஏன் நீங்களே ஹோஸ்ட் செய்ய வேண்டும்

ஹோஸ்ட் செய்யப்பட்ட கனெக்டர் சேவையும் அதே வேலையைத்தான் செய்கிறது, மேலும் நீங்கள் இணைக்கும் ஒவ்வொரு சேவைக்கும் தேவையான refresh tokens-ஐ அதுவே வைத்திருக்கிறது. Google அல்லது GitHub-க்கான ஒரு refresh token என்பது உங்கள் மின்னஞ்சல் மற்றும் களஞ்சியங்களுக்கான (repositories) நீண்ட கால அணுகல் திறவுகோலாகும்; இது பொதுவாக கடவுச்சொல் மாற்றத்திற்குப் பிறகும் செல்லுபடியாகும். அந்தச் சேவை பாதிக்கப்படும்போது, அது உங்கள் பாதிப்பாக மாறுகிறது. நீங்களே ஹோஸ்ட் செய்யும்போது, அந்தத் தரவுகள் அனைத்தும் நீங்கள் வாடகைக்கு எடுத்து நிர்வகிக்கும் ஒரு கணினியில் உள்ள SQLite கோப்பில் சேமிக்கப்படுகின்றன. இவை உங்கள் கணினியை விட்டு வெளியேறாத ஒரு திறவுகோலால் பாதுகாக்கப்படுகின்றன.

தொடங்குவதற்கு முன்பே இதற்கான செலவை வெளிப்படையாகக் கணக்கிடுங்கள். இந்த VPS நீங்கள் இயக்கும் மிக முக்கியமான சர்வராக மாறும். இது ஒரு டஜன் சேவைகளுக்கான செயல்பாட்டுச் சான்றுகளை (credentials) ஒரே கோப்பில் வைத்திருக்கிறது. எனவே, ஒரு கடவுச்சொல் மேலாளரை (password manager) நீங்கள் எவ்வாறு கவனிப்பீர்களோ, அதே கவனத்தை இதற்கும் அளிக்க வேண்டும்: 443 port-ஐ மட்டும் அனுமதிக்கும் firewall, பகிரப்பட்ட logins இல்லாமை, நீங்கள் ஏற்கனவே ஒருமுறை மீட்டெடுத்துச் சரிபார்த்த backup, மற்றும் அது பதிலளிக்காதபோது எச்சரிக்கை செய்யும் வசதி. உங்கள் கடவுச்சொல் பெட்டகத்தை (password vault) இந்தச் சர்வரில் வைக்க நீங்கள் தயங்குவீர்கள் என்றால், கனெக்டரையும் இதில் வைக்காதீர்கள்.

எதையும் நிறுவும் முன் ஒரு குறிப்பிட்ட பதிப்பை (version) உறுதிப்படுத்தவும்

Open Connector ஒரு புதிய மென்பொருள். இதன் களஞ்சியம் (repository) 29 June 2026 அன்று முதன்முதலில் தோன்றியது. 1 August 2026 நிலவரப்படி, மிகப்புதிய tagged release என்பது v1.3.3 ஆகும். இது 30 July 2026 அன்று வெளியிடப்பட்டது மற்றும் latest குறியீட்டையும் கொண்டுள்ளது. இந்த registry, main-ல் உள்ள மிகப்புதிய commit-லிருந்து உருவாக்கப்பட்ட tip குறியீட்டையும் வெளியிடுகிறது.

இவ்வளவு புதிய திட்டங்களில், நகரும் குறியீடுகள் (moving tags) அடிக்கடி மாறக்கூடும். இரண்டு வெளியீடுகளைத் தாண்டிச் செல்லும் ஒரு docker compose pull, உங்கள் agent சார்ந்திருக்கும் endpoint-ஐ மாற்றக்கூடும். அப்போது, அது ஒரு agent சிக்கல் என்று கருதி நீங்கள் இரவு முழுவதும் பிழைதிருத்தம் (debugging) செய்ய வேண்டியிருக்கும். எனவே, image-ஐ ஒரு குறிப்பிட்ட release tag-ல் உறுதிப்படுத்தவும் (pin). வெளியீட்டுக் குறிப்புகளை (release notes) வாசித்த பிறகு, உங்கள் விருப்பப்படி அதை மேம்படுத்தவும் (upgrade).

உங்கள் சொந்த VPS-ல் TLS-க்கு பின்னால் Open Connector-ஐ நிறுவுதல்

Container தொடங்குவதற்கு முன் உங்களுக்குத் தேவையானவை:

• Ubuntu 24.04 அல்லது அது போன்ற இயங்குதளத்தில் Docker மற்றும் அதன் Compose plugin
• இந்த VPS-ஐச் சுட்டிக்காட்டும் A record கொண்ட ஒரு hostname, உதாரணமாக connect.example.com
• அந்த hostname-க்கான TLS (transport layer security) வசதியை ஏற்கனவே கையாளும் ஒரு reverse proxy
• கீழே உருவாக்கப்படும் இரண்டு சீரற்ற ரகசியங்கள் (secrets)

பல Docker Compose செயலிகளுக்கான Traefik reverse proxy வழிகாட்டி proxy அமைப்பைப் பற்றி விளக்குகிறது. ஒரு செயலிக்கான முழுமையான certificate அமைப்பைப் பற்றி Docker மற்றும் HTTPS உடன் VPS-ல் n8n வழிகாட்டியில் காணலாம்.

முதலில் ரகசியங்களை உருவாக்கவும். Encryption key சேமிக்கப்பட்ட நற்சான்றிதழ்களை (credentials) பாதுகாக்கிறது. Admin token இணையதள கன்சோலையும், முழு /api தளத்தையும் பாதுகாக்கிறது. இவற்றுக்கு இயல்பான (default) மதிப்புகள் இல்லை, இவை இல்லாமலேயே runtime தொடங்கும்.

mkdir -p ~/open-connector && cd ~/open-connector
umask 077
printf 'OOMOL_CONNECT_ENCRYPTION_KEY=%s\n' "$(openssl rand -base64 32)" > .env
printf 'OOMOL_CONNECT_ADMIN_TOKEN=%s\n' "$(openssl rand -base64 32)" >> .env
chmod 600 .env

முதல்முறை தொடங்குவதற்கு முன்பே, இந்த இரண்டு மதிப்புகளையும் உங்கள் password manager-ல் நகலெடுத்துக் கொள்ளவும். Encryption key-ஐ மீட்டெடுக்க வழி இல்லை, இதற்கான காரணம் கீழே உள்ள தோல்விப் பட்டியலில் கொடுக்கப்பட்டுள்ளது.

இப்போது compose.yaml-ஐ உருவாக்கவும். இது அசல் (upstream) உதாரணத்திலிருந்து இரண்டு இடங்களில் மாறுபடுகிறது, இரண்டுமே முக்கியமானவை.

services:
  connector:
    image: ghcr.io/oomol-lab/open-connector:v1.3.3
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - connector-data:/app/data
    environment:
      OOMOL_CONNECT_DATA_DIR: /app/data
      OOMOL_CONNECT_ORIGIN: "https://connect.example.com"
      OOMOL_CONNECT_ENCRYPTION_KEY: "${OOMOL_CONNECT_ENCRYPTION_KEY:?set this in .env}"
      OOMOL_CONNECT_ADMIN_TOKEN: "${OOMOL_CONNECT_ADMIN_TOKEN:?set this in .env}"

volumes:
  connector-data:

முதல் மாற்றம் latest-க்கு பதிலாக ஒரு குறிப்பிட்ட tag-ஐப் பயன்படுத்துவது. இரண்டாவது மாற்றம் port எண். அசல் கோப்பு 3000:3000-ஐ வெளியிடுகிறது, இது host-ன் அனைத்து interface-களிலும் இணைகிறது. ufw filter chain பாக்கெட்டைப் பார்ப்பதற்கு முன்பே Docker அதன் published ports-ஐ NAT (network address translation) அட்டவணையில் எழுதிவிடுகிறது. எனவே ufw deny 3000 அந்த port-ஐ மூடாது; இது Docker ports ஏன் ufw-ஐத் தவிர்க்கின்றன என்பதில் விவரிக்கப்பட்டுள்ள ஒரு சிக்கலாகும். 127.0.0.1:3000:3000 என்று குறிப்பிடுவது loopback interface-ல் மட்டுமே வெளியிடும், உங்கள் reverse proxy அதே host-லிருந்து இணைப்பை ஏற்படுத்தும்.

:? ஒவ்வொரு மாறியும் கட்டாயம் தேவை என்பதை உறுதிப்படுத்துகிறது. எனவே .env விடுபட்டிருந்தால், நற்சான்றிதழ்கள் குறியாக்கப்படாமல் (unencrypted) தொடங்குவதற்குப் பதிலாக, stack தொடங்குவதையே மறுத்துவிடும். மதிப்புகளை compose கோப்பில் வைப்பதற்குப் பதிலாக .env-ல் வைத்திருப்பது Docker Compose env கோப்புகள் மற்றும் ரகசியங்கள் வழிகாட்டியில் உள்ள முறையாகும்.

docker compose up -d
docker compose logs -n 30 connector
curl -s http://127.0.0.1:3000/health
sudo ss -tlnp | grep 3000

Runtime இயங்கத் தொடங்கியதும் /health, { "ok": true }-க்கு பதிலளிக்கும். ss கட்டாயம் 127.0.0.1:3000 என்று காட்ட வேண்டும். 0.0.0.0:3000 என்று ஒரு வரி வந்தால், port mapping இன்னும் அசல் நிலையிலேயே உள்ளது என்றும், gateway நேரடியாக இணையம் முழுவதற்கும் பதிலளிக்கிறது என்றும் பொருள். Health check-ல் connection refused என்று வந்தால், container இன்னும் listening நிலையில் இல்லை என்று அர்த்தம்; எனவே proxy-ஐத் தொடுவதற்கு முன் logs-ஐப் பார்க்கவும்.

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.connector.rule=Host(`connect.example.com`)"
      - "traefik.http.routers.connector.entrypoints=websecure"
      - "traefik.http.routers.connector.tls.certresolver=le"
      - "traefik.http.services.connector.loadbalancer.server.port=3000"

OAuth ஏன் உண்மையான hostname-ஐக் கட்டாயமாக்குகிறது

OOMOL_CONNECT_ORIGIN என்பது பயனர்கள் தவிர்க்கும் ஒரு அமைப்பாகும். இதைத் தவிர்ப்பது OAuth-ல் ஒரு பிழையை ஏற்படுத்துகிறது, இது பார்ப்பதற்கு provider-ன் மென்பொருள் பிழை போலத் தோன்றும். Runtime தனது redirect URI-ஐ அந்த origin-லிருந்து <origin>/oauth/callback என்ற வடிவில் உருவாக்குகிறது. இது அமைக்கப்படாமல் இருந்தால், origin இயல்பாக http://localhost:3000 என்று எடுத்துக்கொள்ளப்படும். இதனால், உங்கள் OAuth app-ல் https://connect.example.com/oauth/callback பதிவு செய்யப்பட்டிருக்கும்போது, runtime அந்த provider-க்கு http://localhost:3000/oauth/callback என்ற redirect URI-ஐ அனுப்புகிறது. இந்த இரண்டு சரங்களும் (strings) வெவ்வேறாக இருப்பதால், GitHub பின்வருமாறு பதிலளிக்கிறது:

The redirect_uri MUST match the registered callback URL for this application.

ஒரு OAuth provider உலாவியை (browser) மீண்டும் அந்த URI-க்கு திருப்பிவிடும். எனவே, அது வெளி உலகிலிருந்து அணுகக்கூடிய முகவரியாக இருக்க வேண்டும். localhost-ஐத் தவிர மற்ற எதற்கும் plain http://-ஐ provider-கள் நிராகரித்துவிடும். இதனால்தான் இந்த deployment-க்கு ஒரு hostname மற்றும் certificate தேவைப்படுகிறது. முதல் முறை தொடங்குவதற்கு முன்பே origin-ஐ அமைக்கவும், ஏனெனில் இந்த மதிப்பு தொடக்கத்தின்போதே (startup) வாசிக்கப்படுகிறது: .env அல்லது compose.yaml-ஐத் திருத்திய பிறகு, அதைச் செயல்படுத்த docker compose up -d-ஐ மீண்டும் இயக்கவும்.

உங்கள் முதல் provider-ஐ OAuth மூலம் இணைத்தல்

முதலில் provider-ல் OAuth app-ஐ உருவாக்கவும். GitHub-ல் இதற்கான பாதை Settings, பிறகு Developer settings, அதன் பின் OAuth Apps, இறுதியாக New OAuth App என்பதாகும். Authorization callback URL-ஐ https://connect.example.com/oauth/callback என அமைக்கவும். Client ID மற்றும் client secret-ஐப் பாதுகாப்பாக வைத்துக்கொள்ளவும்.

ஒவ்வொரு /api அழைப்பும் admin token-ஐக் கொண்டிருக்கும், எனவே shell session-க்காக அதை ஒருமுறை export செய்யவும்.

export ADMIN_TOKEN='paste-the-admin-token'
curl -s https://connect.example.com/api/oauth/configs \
  -H "authorization: Bearer $ADMIN_TOKEN"

அந்தப் பட்டியல் ஒவ்வொரு provider-க்கும் runtime எதிர்பார்க்கும் redirect URI-ஐக் காட்டுகிறது. உங்கள் origin மாற்றங்கள் நடைமுறைக்கு வந்துவிட்டதா என்பதைச் சரிபார்க்க இதுவே விரைவான வழியாகும். ஒருவேளை அது இன்னும் localhost என்று காட்டினால், container பழைய மதிப்பிலேயே இயங்குகிறது என்று பொருள்; இதனால் OAuth flow இறுதி நிலையில் தோல்வியடையும்.

Client credentials-ஐச் சேமித்துவிட்டு, authorization-ஐத் தொடங்கவும்.

curl -s -X PUT https://connect.example.com/api/oauth/configs/github \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"clientId":"...","clientSecret":"..."}'

curl -s -X POST https://connect.example.com/api/oauth/authorizations \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"service":"github"}'

இரண்டாவது அழைப்பு ஒரு authorizationUrl-ஐத் தரும். அதை browser-ல் திறந்து, scopes-க்கு ஒப்புதல் அளிக்கவும். பிறகு provider browser-ஐ /oauth/callback-க்குத் திருப்பிவிடும்; அங்கு runtime அந்த code-ஐப் பெற்று credential-ஐச் சேமிக்கும். உங்கள் origin-ல் உள்ள web console, அதே admin token-ஐப் பயன்படுத்தி ஒரு படிவத்தின் (form) மூலம் இதே படிகளைச் செய்கிறது. Plain API key-ஐப் பயன்படுத்தும் provider-களுக்கு இவை எதுவும் தேவையில்லை: PUT /api/connections/<service>-ஐ {"authType":"api_key","values":{"apiKey":"..."}} உடன் பயன்படுத்தினால், அந்த key நேரடியாகச் சேமிக்கப்படும்.

ஒவ்வொரு agent-க்கும் ஒரு runtime token-ஐ வழங்கவும், credential-ஐ ஒருபோதும் வழங்க வேண்டாம்

Agent-ஆனது admin API மூலம் உருவாக்கப்பட்ட runtime token-ஐப் பயன்படுத்தி gateway-ல் அங்கீகாரம் (authenticate) பெறுகிறது.

curl -s -X POST https://connect.example.com/api/runtime-tokens \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"name":"research-agent"}'

பதிலானது oct_ எனத் தொடங்கும் ஒரு token-ஐக் கொண்டிருக்கும். ஒவ்வொரு agent-க்கும் தனித்தனியாக ஒரு token-ஐ வழங்கி, அதற்கு அந்த agent-ன் பெயரைச் சூட்டவும். ஏனெனில், அடையாளம் காண முடியாத ஒரு token-ஐ நீக்குவது என்பது, அனைத்து token-களையும் நீக்குவதற்குச் சமமாகும். அதன் பிறகு, agent சாதாரண HTTP மூலம் செயல்பாடுகளை (actions) அழைக்கும்.

curl -s -X POST https://connect.example.com/v1/actions/github.get_current_user \
  -H "authorization: Bearer oct_..." \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

சரியான பதிலானது ஒரு envelope ஆகும். அதில் success புலம் true என இருக்கும், மேலும் provider payload data-ன் கீழ் இருக்கும். அந்தப் பதிலில் GitHub token எங்கும் இருக்காது. ஒரு MCP client-க்கு, அதே bearer header-உடன் அதை https://connect.example.com/mcp-க்குச் சுட்டிக்காட்டவும். அப்போது gateway, ஒவ்வொரு API-க்கும் ஒரு கருவி என்பதற்குப் பதிலாக, search_actions மற்றும் execute_action போன்ற discovery கருவிகளை வழங்கும். இது agent-ன் கருவிப் பட்டியலைச் சிறியதாக வைத்திருக்கும். VPS-ல் MCP servers-ஐ இயக்குதல் என்பது அந்த இணைப்பின் client பகுதியை விளக்குகிறது.

இதை முடிப்பதற்கு முன் மேலும் ஒரு சோதனையைச் செய்யவும். authorization header-ஐ நீக்கிவிட்டு, அந்தச் செயல்பாட்டு அழைப்பை (action call) மீண்டும் செய்யவும். இந்தத் திட்டத்தின் quickstart, bearer இல்லாமலேயே /v1-ஐ அழைக்கிறது. எனவே, runtime auth அமைக்கப்படாத ஒரு நிறுவல், அந்தப் port-ஐ அணுகக்கூடிய எவருக்கும் செயல்பாடுகளைச் செய்ய அனுமதிக்கும். உங்கள் அங்கீகரிக்கப்படாத அழைப்பு வெற்றி பெற்றால், இரண்டு வழிகள் உள்ளன: runtime token-களை உள்ளமைத்து, இப்போது anonymous அழைப்பு தோல்வியடைவதை உறுதி செய்யவும், அல்லது reverse proxy-ல் /api, /v1 மற்றும் /mcp ஆகியவற்றை உங்கள் agent-கள் வரும் முகவரிகளுக்கு மட்டும் கட்டுப்படுத்தவும். /oauth/callback மட்டும் உலகிற்குத் திறந்த நிலையில் இருக்க வேண்டும், ஏனெனில் provider-ன் browser redirect-க்குத் தேவையான ஒரே பாதை அதுதான்.

முகவர் (agent) தேவைப்படும் செயல்பாடுகளின் பட்டியலைச் சுருக்குதல்

ஆயிரக்கணக்கான வழங்குநர்களைக் (providers) கொண்ட ஒரு நுழைவாயிலை (gateway) ஒரு மொழி மாதிரியிடம் (language model) ஒப்படைப்பது, தாக்குதலுக்கு உள்ளாகக்கூடிய பரந்த தளத்தை உருவாக்குவதாகும். இரண்டு கட்டுப்பாடுகள் இதைச் சுருக்குகின்றன.

OOMOL_CONNECT_ALLOWED_ACTIONS என்பது கமாவால் பிரிக்கப்பட்ட அனுமதிப் பட்டியலை (allowlist) எடுத்துக்கொள்ளும், மேலும் இது service.* மற்றும் * ஆகியவற்றை ஏற்கும். OOMOL_CONNECT_BLOCKED_ACTIONS என்பது தடைப் பட்டியல் (denylist) ஆகும், இதில் தடைப் பட்டியலே முதன்மையானது. அனுமதிப் பட்டியலை github.get_current_user,github.list_issues என அமைத்தால், முகவர் எதைக் கேட்டாலும் மற்ற அனைத்துச் செயல்பாடுகளும் மறுக்கப்படும்; இதுவே ஒரு சாதாரண தவறுக்கும், ஒரு பாதுகாப்புச் சம்பவத்திற்கும் (incident) உள்ள வேறுபாடாகும். இயக்க நேர டோக்கன்கள் (runtime tokens) உலகளாவிய விதிகளுக்கு மேலாகத் தமக்கெனச் சொந்தமான செயல்பாட்டு விதிகளைக் கொண்டுள்ளன. அவற்றின் allowedProxies பட்டியல் காலியாகவே தொடங்கும், எனவே நீங்கள் அனுமதிக்கும் வரை POST /v1/proxy/:service மறுக்கப்படும். அந்தப் ப்ராக்ஸி எண்ட்பாயிண்ட் (proxy endpoint), உங்கள் நற்சான்றிதழ்களுடன் (credential) ஒரு மூலக் கோரிக்கையை (raw request) வழங்குநருக்கு அனுப்பும், எனவே ஒரு குறிப்பிட்ட முகவருக்குத் தேவைப்பட்டால் ஒழிய அதை காலியாக விடவும்.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK இயல்பாக false என இருக்கும். இது, சுய-வழங்கி (self-hosted) இணைப்புகளை 169.254.169.254-ல் உள்ள கிளவுட் மெட்டாடேட்டா சேவை அல்லது அதே நெட்வொர்க்கில் உள்ள உங்கள் தரவுத்தளம் போன்ற தனிப்பட்ட முகவரிகளைச் சுட்டிக்காட்டுவதைத் தடுக்கிறது. இதை ஆஃப் (off) நிலையிலேயே விடவும். நீங்கள் சுயமாக வழங்கும் ஒரு வழங்குநருக்கு மட்டும் இதை ஆன் (on) செய்யவும்.

அனைத்து டோக்கன்களையும் கொண்ட பெட்டியை பேக்அப் செய்தல்

இரண்டு விஷயங்கள் முக்கியமானவை, ஒன்று மற்றொன்றின்றி பயனற்றது. connector-data வால்யூமில் உள்ள /app/data/connect.sqlite-ல் இருக்கும் டேட்டாபேஸ், சீல் வைக்கப்பட்ட நற்சான்றிதழ்களை (credentials) வைத்திருக்கிறது. .env-ல் உள்ள என்க்ரிப்ஷன் கீ (encryption key) அவற்றை திறக்க உதவுகிறது. கீ இல்லாத வால்யூம் பேக்அப் எதையும் மீட்டெடுக்காது, அதேபோல் வால்யூம் இல்லாத கீயும் எதையும் மீட்டெடுக்காது. எனவே, கீயை உங்கள் பாஸ்வேர்டு மேனேஜரிலும், வால்யூமை உங்கள் வழக்கமான பேக்அப் சுழற்சியிலும் வைத்திருக்க வேண்டும்.

SQLite கோப்பை நகலெடுக்கும்போது கன்டெய்னரை நிறுத்திவிடவும். ஏனெனில், எழுதும் செயல்பாட்டின் போது எடுக்கப்படும் நகல் சிதைந்த டேட்டாபேஸாக மாறக்கூடும்.

docker volume ls | grep connector-data
docker compose stop connector
docker run --rm -v open-connector_connector-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/connector-data.tgz -C /data .
docker compose start connector

வால்யூம் பெயர் என்பது உங்கள் புராஜெக்ட் டைரக்டரியுடன் _connector-data சேர்ந்ததாகும். இதனால்தான் முதல் கட்டளை அங்கு உள்ளது: உண்மையான பெயரை மூன்றாவது கட்டளையில் பதிவிடவும். அந்த ஆர்க்கைவை VPS-லிருந்து restic பேக்அப்கள் மூலம் VPS-லிருந்து வெளியே அனுப்பவும். இது வெளியேறும் முன்பே என்க்ரிப்ட் செய்யப்படும், ஏனெனில் அந்த ஆர்க்கைவ் நற்சான்றிதழ் சேமிப்பகமாகும்.

ரன்டைம் சமீபத்திய செயல்பாடுகளை தணிக்கை பதிவுகளாக (audit records) வைத்திருக்கும். இயல்பாக 5,000 பதிவுகள் இருக்கும், எனவே எந்த ஏஜென்ட் எப்போது எதை இயக்கியது என்பதை கன்சோல் மூலம் அறியலாம். ஒரு ஏஜென்ட் விசித்திரமாக செயல்படும்போது, முதலில் படிக்க வேண்டியது அந்த லாக் தான். Uptime Kuma ஸ்டேட்டஸ் பேஜ் ஒன்றை https://connect.example.com/health-க்கு சுட்டிக்காட்டவும். கேட்வே பதிலளிக்காதபோது, ஏஜென்ட்கள் குழப்பமான முறையில் தோல்வியடையும். கேட்வே செயலிழந்துவிட்டது என்பதை அறிந்துகொள்வது, ஏஜென்ட் வெளியீட்டைப் படித்துக்கொண்டிருக்கும் ஒரு மணி நேரத்தை மிச்சப்படுத்தும்.

என்னென்ன செயலிழக்கும், நீங்கள் காணும் செய்திகள் என்ன

redirect_uri_mismatch வழங்குநரிடம் (provider). மூலமும் (origin) பதிவுசெய்யப்பட்ட callback URL-ம் வெவ்வேறாக உள்ளன. /api/oauth/configs-ல் உள்ள துல்லியமான சரத்தை (string), வழங்குநரின் app settings-ல் உள்ளவற்றுடன் ஒப்பிடவும். இதில் https மற்றும் http ஆகியவற்றுக்கு இடையே உள்ள வேறுபாடுகள் மற்றும் இறுதியில் உள்ள slash (/) குறியீடு ஆகியவற்றையும் கவனிக்கவும்.

ஒவ்வொரு /api அழைப்பும் 401 பிழையைத் தருகிறது. நிர்வாகி token header விடுபட்டுள்ளது அல்லது தவறாக எழுதப்பட்டுள்ளது. அந்த header Authorization: Bearer <token> ஆகும்; web console-ம் அதே token-ஐக் கேட்கிறது.

container இயங்குகிறது, ஆனால் நற்சான்றிதழ்கள் (credentials) plain text-ஆக உள்ளன. OOMOL_CONNECT_ENCRYPTION_KEY container-ஐச் சென்றடையாதபோது இது நிகழ்கிறது. runtime, நற்சான்றிதழ் பதிவுகளைத் தொடங்க மறுப்பதற்குப் பதிலாக, அவற்றை encrypt செய்யாமல் சேமித்து வைக்கிறது. உங்கள் சொந்த install-ல் இதைச் சரிபார்க்கவும்: உங்களுக்குத் தெரிந்த API key-ஐக் கொண்டு ஒரு வழங்குநரை இணைக்கவும், பின் database-ல் அதைத் தேடவும்.

docker compose cp connector:/app/data/connect.sqlite /tmp/connect.sqlite
grep -c 'github_pat_' /tmp/connect.sqlite
shred -u /tmp/connect.sqlite

0-க்கு மேல் எண்ணிக்கை இருந்தால், அந்த key செயல்பாட்டில் இல்லை என்று அர்த்தம். எனவே, .env ஆனது compose.yaml இருக்கும் அதே directory-ல் உள்ளதா என்பதையும், docker compose config அந்த மதிப்பைக் காட்டுகிறதா என்பதையும் சரிபார்க்கவும். key சரியாக அமைக்கப்பட்டிருந்தால், அதே தேடல் 0 என்ற முடிவைத் தரும். ஏனெனில், அந்தப் பதிவு AES-256-GCM (advanced encryption standard, 256-bit key, Galois/counter mode) மூலம் பாதுகாக்கப்பட்டுள்ளது.

restore செய்த பிறகு எதுவும் decrypt ஆகவில்லை. encryption key மாற்றப்பட்டுள்ளது அல்லது தொலைந்துவிட்டது. வடிவமைப்பின்படி, அது தரவுகளுடன் சேர்த்துச் சேமிக்கப்படுவதில்லை. எனவே, இதற்கு மீட்பு வழிமுறை (recovery path) கிடையாது, எந்த support ticket-ம் உதவாது. ஒவ்வொரு வழங்குநரையும் மீண்டும் இணைக்கவும். ஒரு தனி key variable மற்றும் runtime-ல் உள்ள data command மூலம் rotation ஆதரிக்கப்படுகிறது. எனவே, எதையும் rotate செய்வதற்கு முன் தற்போதைய release notes-ஐப் படிக்கவும்.

catalog-ல் உள்ள ஒரு செயலை agent பிழையாகக் காட்டுகிறது. கண்டறிதலும் (discovery) செயல்படுத்துதலும் (execution) தனித்தனி நிகழ்வுகள். ஒரு செயல் search_actions-ல் தோன்றினாலும், அது OOMOL_CONNECT_ALLOWED_ACTIONS மூலமாகவோ, denylist மூலமாகவோ அல்லது அந்த runtime token-ன் விதிகளின் அடிப்படையிலோ மறுக்கப்படலாம்.

மேம்படுத்தல்கள் (Upgrades). volume-ஐ backup எடுக்கவும், image tag-ஐ புதிய release-க்கு மாற்றவும், பின் docker compose pull && docker compose up -d-ஐ இயக்கவும். migration வரியைக் காண docker compose logs -n 50 connector-ஐக் கவனிக்கவும். மீண்டும் நம்பகத்தன்மையுடன் பயன்படுத்துவதற்கு முன், health check-ஐயும் ஒரு உண்மையான செயலையும் மீண்டும் இயக்கவும். பழைய நிலைக்குத் திரும்புவது (rolling back) என்பது பழைய tag-ஐ மீண்டும் பயன்படுத்துவதாகும்; நீங்கள் அதை முன்கூட்டியே pin செய்திருந்தால் மட்டுமே இது வேலை செய்யும்.

FAQ

Open Connector-ஐ self-host செய்ய பொது டொமைன் (public domain) தேவையா?

API key-ஐப் பயன்படுத்தும் providers-க்கு, தேவையில்லை: 127.0.0.1-ல் உள்ள gateway போதுமானது. ஆனால் OAuth-க்கு, நடைமுறையில் இது அவசியம். Provider உங்கள் browser-ஐ callback URL-க்கு திருப்பிவிடும், எனவே அந்த URL பொது இணையத்திலிருந்து (public internet) அணுகக்கூடியதாக இருக்க வேண்டும். மேலும், localhost-ஐத் தவிர மற்ற இடங்களில் plain http://-ஐ providers ஏற்காது. முதல் முறை தொடங்குவதற்கு முன்பே OOMOL_CONNECT_ORIGIN-ஐ உங்கள் https:// hostname-க்கு அமைத்து, provider-ன் OAuth app-ல் <origin>/oauth/callback-ஐ பதிவு செய்யவும்.

Open Connector encryption key தொலைந்துவிட்டால் என்னவாகும்?

சேமிக்கப்பட்ட நற்சான்றிதழ்களை (credentials) மறைகுறியாக்க (decrypt) முடியாது, இதை மீட்டெடுக்க வழியும் இல்லை. தரவுகளுடன் சேர்த்து key சேமிக்கப்படுவதில்லை என்பதால், database-ஐ வைத்திருப்பவர் யாராலும் (உங்களையும் சேர்த்து) அதை வாசிக்க முடியாது. புதிய key-ஐ அமைத்து, ஒவ்வொரு provider-உடனும் மீண்டும் இணைப்பதே ஒரே வழி. Key-ஐ ஒரு password manager-லும், database-ஐ உங்கள் backup rotation-லும் பாதுகாப்பாக வைத்திருக்கவும், ஏனெனில் restore செய்ய இவை இரண்டும் தேவை.

எனது AI agent-ஆல் provider access token-ஐப் பார்க்க முடியுமா?

Gateway வழியாக அழைக்கும்போது பார்க்க முடியாது. Agent ஒரு runtime token-ஐப் பயன்படுத்தி அங்கீகரிக்கப்படுகிறது (இது oct_-ல் தொடங்கும்). Gateway, server-ல் உள்ள provider credential-ஐ outbound request-ல் சேர்த்து, பதிலை மட்டும் திருப்பி அனுப்பும். இரண்டு விஷயங்கள் இந்த பாதுகாப்பை மீறலாம்: /v1/proxy/:service endpoint, இது உங்கள் credential-உடன் raw request-களை அனுப்பும் (இதன் grants காலியாக இருப்பதற்கு ஒரு காரணம் உண்டு), மற்றும் API key-ஐ நீங்களே agent-ல் உள்ளிடுவது, இது gateway-ஐ முழுமையாகத் தவிர்க்கிறது.

Gateway பொது இணையத்திலிருந்து அணுகக்கூடியதாக இருக்க வேண்டுமா?

/oauth/callback மட்டும் அணுகக்கூடியதாக இருந்தால் போதும். Container port-ஐ 127.0.0.1-ல் மட்டும் publish செய்யவும், இதனால் Docker-ன் NAT விதிகள் உங்கள் firewall-க்கு அப்பால் அதை வெளிப்படுத்தாது. அதற்கு முன்னால் ஒரு reverse proxy-ஐ வைக்கவும். பிறகு authorization header இல்லாமல் ஒரு action call-ஐச் சோதிக்கவும். அது வெற்றி பெற்றால், அங்கீகரிக்கப்பட்ட அழைப்புகள் மட்டுமே செயல்படும் வரை, proxy-ல் /api, /v1 மற்றும் /mcp ஆகியவற்றை உங்கள் agent-கள் பயன்படுத்தும் முகவரிகளுக்கு மட்டும் கட்டுப்படுத்தவும்.

Open Connector production பயன்பாட்டிற்குத் தயாரா?

இது Apache 2.0 உரிமம் பெற்றது மற்றும் வேகமாக வளர்ந்து வருகிறது: repository 29 June 2026 அன்று வெளியானது மற்றும் v1.3.3 ஆனது 30 July 2026 அன்று வெளியானது. எனவே, இந்த வழிகாட்டியில் உள்ள ஒவ்வொரு version எண்ணையும் 1 August 2026-ன் ஒரு snapshot-ஆகக் கருதவும். எப்போதும் ஒரு release tag-ஐப் பயன்படுத்தி இயக்கவும், ஒருபோதும் latest அல்லது tip-ல் இயக்க வேண்டாம். ஒவ்வொரு upgrade-க்கு முன்பும் release notes-ஐ வாசிக்கவும், ஒருமுறை restore செய்து சரிபார்க்கப்பட்ட volume backup-ஐ வைத்திருக்கவும். நீங்கள் சொந்தமாக வைத்திருக்கும் server-க்கு இதன் வடிவமைப்பு சரியானது, இதில் உள்ள ஆபத்து architecture-ல் இல்லை, version மாற்றங்களில் மட்டுமே உள்ளது.