Docker Compose और nginx के साथ Keycloak SSO कॉन्फ़िगर करना

(du.nkel.dev)

3 पॉइंट द्वारा GN⁺ 2024-02-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें

यह एक सिंगल Linux VM पर Keycloak को rootless Docker में अलग-थलग चलाने और सिस्टम nginx को TLS termination तथा reverse proxy के लिए उपयोग करने वाली SSO deployment प्रक्रिया है
पूर्वापेक्षाएँ हैं: SSH access, Keycloak के लिए domain या subdomain, A record, बिना पासवर्ड वाला keycloak user, /srv/keycloak home directory, और Docker rootless installation
docker-compose.yml में postgres:16 और quay.io/keycloak/keycloak:25.0.1 का उपयोग होता है, और Keycloak को केवल 127.0.0.1:8080 पर bind किया जाता है, जबकि passwords और KC_HOSTNAME को .env में मैनेज किया जाता है
nginx, your.tld.com पर आने वाले HTTP requests को HTTPS पर redirect करता है और proxy_pass से आगे भेजता है; Certbot certificate जारी होने के बाद KC_PROXY_HEADERS: xforwarded सक्रिय किया जाता है
अगर custom theme या --optimized रन की ज़रूरत हो, तो multi-stage Dockerfile से अपनी image बनाई जा सकती है, और production में JGroups buffer size तथा Quarkus transaction recovery settings को अतिरिक्त रूप से ट्यून किया जा सकता है

डिप्लॉयमेंट संरचना और पूर्वापेक्षाएँ

Keycloak एक open source IAM विकल्प है, जिसे तब उपयोग किया जा सकता है जब web application में user management और SSO को सीधे implement करना कठिन हो
यह OpenID Connect (OIDC), OAuth 2.0, SAML जैसे प्रमुख SSO protocols के साथ interoperable है
यह कॉन्फ़िगरेशन Keycloak 23.0.6 के आधार पर लिखा गया था और 25.0.5 तक test किया गया है
पूरी संरचना में nginx को केंद्रीय reverse proxy के रूप में रखा गया है, जो service-specific rootless Docker namespace में localhost ट्रैफ़िक forward करता है
- web traffic 0.0.0.0:80 और 0.0.0.0:443 पर आता है, और nginx उसे 127.0.0.1:8080 पर चल रहे Keycloak तक भेजता है
- लक्ष्य एक ऐसा किफायती सेटअप है जो single host resources साझा करते हुए भी service environments को अलग रखता है

तैयारी का काम

बेस environment के रूप में Linux VM, SSH remote access, और Keycloak service के लिए domain या subdomain चाहिए
- domain में A record होना चाहिए, और विकल्प के रूप में AAAA record जोड़ा जा सकता है
Docker rootless की बेस setup एक अलग Mastodon पोस्ट की प्रक्रिया का पालन करती है
- बिना पासवर्ड वाला नया non-root user keycloak बनाना
- home directory को /srv/keycloak पर सेट करना
- /etc/subuid और /etc/subgid में keycloak user range जोड़ना
- dockerd-rootless-setuptool.sh से Docker rootless install करना
- keycloak user के लिए automatic service startup सेट करना

Docker Compose से Keycloak चलाना

नए बनाए गए keycloak user में जाने के लिए machinectl shell keycloak@ का उपयोग किया जाता है
- sudo -u keycloak -H bash तरीका इसलिए नहीं अपनाया जाता क्योंकि उसमें XDG_RUNTIME_DIR environment variable तैयार नहीं होता
पहले persistent data और Docker files के लिए directories बनाई जाती हैं
- PostgreSQL data path: /srv/keycloak/data/postgres16
- Docker files: ~/docker
docker-compose.yml आधिकारिक Keycloak image और PostgreSQL का सीधे उपयोग करता है
- PostgreSQL image: postgres:16
- Keycloak image: quay.io/keycloak/keycloak:25.0.1
- production environment में :latest की जगह specific image tag उपयोग करने की सिफारिश है
Keycloak container की मुख्य settings इस प्रकार हैं
- KC_DB: postgres
- KC_DB_URL: jdbc:postgresql://postgres_db/keycloak
- KC_HOSTNAME: ${KC_HOSTNAME:-your.tld.com}
- KC_HTTP_ENABLED: true
- HTTP_ADDRESS_FORWARDING: true
- KEYCLOAK_ADMIN: admin
- port को '127.0.0.1:8080:8080' के रूप में bind किया जाता है ताकि यह केवल localhost पर उपलब्ध रहे
.env में sensitive या environment-specific values रखी जाती हैं
- POSTGRES_PASSWORD
- KEYCLOAK_ADMIN_PASSWORD
- KC_HOSTNAME
${KC_HOSTNAME:-your.tld.com} syntax का मतलब है कि अगर .env में KC_HOSTNAME मौजूद है तो वही value उपयोग होगी, नहीं तो default के रूप में your.tld.com लिया जाएगा
/srv/keycloak/data/postgres16 में PostgreSQL का persistent data रहता है, इसलिए इसे नियमित backup में शामिल करना चाहिए
- पूरी तरह reset करना हो तो संबंधित PostgreSQL folder को delete करके फिर से बनाया जा सकता है; अगली start पर यह फिर बन जाएगा
अगर ~/docker को Git repository के रूप में manage किया जाता है, तो .env को .gitignore में जोड़कर सिर्फ docker-compose.yml commit किया जा सकता है

लोकल टेस्ट

Docker Compose stack को start करें और logs देखें

docker compose up -d && docker compose logs --follow

VM के Keycloak local port तक पहुँचने के लिए reverse SSH tunnel बनाएं

ssh you@111.11.11.11 -L :8080:127.0.0.1:8080 -p 22 -N -v

browser में 127.0.0.1:8080 खोलकर Keycloak welcome screen की पुष्टि करें

nginx reverse proxy और TLS

keycloak user से logout करने के बाद system nginx configuration करें
your.tld.com को अपने वास्तविक domain से बदलें, और domain registrar में A record जोड़ें ताकि DNS queries VM IP तक जाएँ
nginx site configuration file बनाकर उसे activate करें

nano /etc/nginx/sites-available/your.tld.com.conf
ln -s /etc/nginx/sites-available/your.tld.com.conf /etc/nginx/sites-enabled/

nginx configuration HTTP requests को HTTPS पर redirect करती है, और HTTPS server block में Keycloak तक proxy करती है
- proxy_set_header Host $host
- proxy_set_header X-Real-IP $remote_addr
- proxy_set_header X-Forwarded-For $remote_addr
- proxy_set_header X-Forwarded-Proto $scheme
- proxy_pass http://127.0.0.1:8080
SSL settings के लिए Mozilla SSL configurator for nginx का उपयोग करके nginx version के अनुसार defaults generate करने की सिफारिश है
configuration test करने के बाद nginx को reload करें

nginx -t
systemctl reload nginx

Certbot से certificate जारी करने पर your.tld.com.conf की ज़रूरी lines अपने-आप अपडेट हो जाती हैं

certbot --nginx -d your.tld.com

इसके बाद ssl_trusted_certificate /etc/letsencrypt/live/your.tld.com/chain.pem; को सक्रिय करें और nginx को फिर reload करें
nginx के पीछे काम करने के लिए docker-compose.yml में KC_PROXY_HEADERS: xforwarded सक्रिय करें, फिर Docker stack को restart करें

docker compose down && docker compose up -d && docker compose logs --follow

डिबगिंग पथ

सेटअप के बाद your.tld.com पर जाकर .env वाले password से admin user login की पुष्टि करें
सबसे पहले Docker Compose logs देखें

docker compose logs --follow

nginx access log और error log को इन files के जरिए follow करें

tail -f /var/log/nginx/your.tld.com-access.log
tail -f /var/log/nginx/your.tld.com-error.log

अगर Keycloak database को सीधे देखना हो, तो keycloak user में जाएँ और PostgreSQL container के अंदर psql चलाएँ

machinectl shell keycloak@
cd ~/docker
docker compose exec postgres_db /bin/bash
psql -h localhost -p 5432 -U keycloak keycloak

custom image और optimized रन

बेस configuration quay.io की prebuilt image का उपयोग करती है
theme customization या --optimized mode में run करने के लिए अपनी image build करें
Dockerfile आधिकारिक Keycloak image पर आधारित multi-stage build का उपयोग करता है
- builder stage में ENV KC_DB=postgres सेट करना
- /opt/keycloak/bin/kc.sh build चलाना
- final image में /opt/keycloak/ कॉपी करना
- ENTRYPOINT ["/opt/keycloak/bin/kc.sh"] सेट करना
docker-compose.yml में इसे इस तरह बदलें
- image: line हटाएँ या comment करें
- build: . सक्रिय करें
- command: start --optimized जोड़ें
इसके बाद Docker stack को बंद करें, चाहें तो explicit build चलाएँ, फिर दोबारा start करें

docker compose down
docker compose build
docker compose up -d && docker compose logs --follow

production environment में अतिरिक्त tuning

JGroups से जुड़ी MulticastSocket receive buffer warning को host के /etc/sysctl.conf में buffer values जोड़कर हल किया गया

net.core.rmem_max = 26214400
net.core.wmem_max = 1048576

setting लागू करने के लिए sysctl -p चलाएँ
Quarkus XA transaction recovery warning को Keycloak service में volume mount और environment variable जोड़कर ठीक किया गया
- volume: /srv/keycloak/data/keycloak/ObjectStore/:/ObjectStore/
- environment variable: QUARKUS_TRANSACTION_MANAGER_ENABLE_RECOVERY: true
start से पहले host पर ObjectStore directory बनाएँ, और container के अंदर /ObjectStore के owner को user ID 1000 में बदलें

कॉन्फ़िगरेशन के बाद के चरण

अंतिम स्थिति यह है कि rootless Docker के अंदर चल रही Keycloak service, system nginx reverse proxy के पीछे चलती है, और nginx SSL termination संभालता है
automatic container updates के लिए एक अलग Mastodon पोस्ट में दिए गए auto-update steps देखें
अगला configuration step है Keycloak admin console में email जोड़ना
- path है https://your.tld.com/admin/master/…
इसके बाद realm जोड़ना और theme सेट करना किया जा सकता है
- themes के लिए keycloakify और keycloakify-starter का उपयोग किया जा सकता है
- Dockerfile में keycloakify theme JAR को /opt/keycloak/providers/ में copy करने वाली एक commented line शामिल है

1 टिप्पणियां

GN⁺ 2024-02-12

Hacker News की राय

हाल ही में होमलैब में authentication जोड़ते समय Authelia चुना
Keycloak भी काम करता है, लेकिन बहुत भारी है, और traefik forward auth के साथ इस्तेमाल करने के लिए एक अतिरिक्त service और चाहिए
Authelia में user editing UI नहीं है और backend LDAP server के साथ two-way sync भी नहीं है, लेकिन इसे सिर्फ static files और environment variables से configure किया जा सकता है, इसलिए कई मामलों में यह अच्छे से फिट बैठता है
अगर कुछ services में authentication जोड़ना है और जहां संभव हो वहां SSO लगाना है, तो Authelia से शुरुआत करना अच्छा विकल्प हो सकता है
- FusionAuth में काम करता/करती हूं
  अगर SSO, आसान setup और admin UI चाहिए, तो FusionAuth भी देखने लायक है। UI/UX 2000 के दशक के मध्य जैसा महसूस होता है, लेकिन इसे सीधे download करके चला सकते हैं[0], यह Docker-friendly है[1], और OIDC या अन्य settings को Terraform[3] से manage करने जैसे कई configuration तरीके[2] देता है
  इसे free में इस्तेमाल किया जा सकता है, लेकिन यह open source नहीं है[4]
  0: https://fusionauth.io/download
  1: https://fusionauth.io/docs/get-started/download-and-install/...
  2: https://fusionauth.io/docs/operate/deploy/configuration-mana...
  3: https://fusionauth.io/docs/operate/deploy/terraform
  4: https://fusionauth.io/license-faq#28
- Authelia को 2 साल से ज्यादा समय से चला रहा/रही हूं, और हल्के LDAP implementation LLDAP[0] के साथ LDAP integration configure किया है
  Caddy को reverse proxy के रूप में इस्तेमाल करके Authelia के साथ integrate[1] किया है और यह अच्छे से काम करता है
  सभी services में मजबूत two-factor authentication लगाया है, और self-hosted apps को VPN के बिना access करने पर भी काफी सुरक्षित महसूस होता है
  हालांकि Authelia का 1 साल से ज्यादा समय से नया release नहीं आया है, इसलिए security को लेकर चिंता है
  [0] https://github.com/lldap/lldap
  [1] https://www.authelia.com/integration/proxies/caddy/
- हाल ही में इसी रास्ते पर गया/गई, और निजी तौर पर Caddy plugin caddy-security[1] चुना
  [1] https://github.com/greenpau/caddy-security
- Authelia का छोटे installation size वाला बहुत अलग फायदा है, और Keycloak या authentik इस क्षेत्र में आसानी से फिट नहीं बैठते
  homelab environment के लिए यह बहुत अच्छा use case है, खासकर अगर बड़े solutions की features की जरूरत नहीं है या वे नहीं चाहिए
- थोड़ा अलग विषय है, लेकिन जानना चाहता/चाहती हूं कि आजकल LDAP के alternatives हैं या नहीं
  खोजने पर भी simple schema, JSON, HTTP जैसी कोई चीज नहीं मिली, और यह यकीन करना मुश्किल है कि लगभग हर चीज को नए सिरे से बनाने वाले लोगों ने LDAP को फिर से नहीं बनाया
  मेरी जानकारी में, व्यावहारिक रूप से दूसरा standard सिर्फ Active Directory है
  यह भी जानना चाहता/चाहती हूं कि access control को बाहर सौंपने के लिए कोई standard या protocol है या नहीं
  Authelia URL patterns से access control कर सकता है, लेकिन उदाहरण के लिए file server के मामले में, authenticated user ID और database की key के आधार पर LDAP server से permissions check करने जैसा तरीका अपेक्षित लगता है
  यह उस OAuth2 की उल्टी दिशा जैसा दिखता है जिसमें server किसी third-party service का access right हासिल करता है
हाल ही में homelab में अपेक्षाकृत सरल SSO सेटअप करने के लिए देखा, और मुख्य लक्ष्य Google या GitHub authentication से आसानी से login करना था
पिछली नौकरी में JetBrains Hub[1] और Keycloak दोनों इस्तेमाल किए थे, लेकिन दोनों की configuration काफी झंझटभरी थी
JetBrains Hub सच में बहुत आसानी से शुरू हो जाता था और मेरा पिछला अनुभव भी ऐसा ही था, लेकिन Docker registry में latest tag न होना असुविधाजनक था
मुझे पता है version pinning अच्छा होता है, लेकिन personal use में आम तौर पर सभी Docker containers को एक साथ update करना चाहता हूं
दूसरी ओर Keycloak शुरू करना बहुत झंझट वाला था; development mode में आसान था, लेकिन production configuration पर अटक गया
याद है कि यह wildcard Let's Encrypt certificate से जुड़ा था, और कुछ घंटों बाद हार मान ली
आखिरकार Dex[2] चुना। Documentation कम होने की वजह से इसे टाल रहा था, लेकिन असल setup बहुत आसान था; basic YAML, SQLite database और एक subdomain काफी था
Dex को शानदार OAuth2 Proxy[3] और custom Nginx Proxy Manager template के साथ मिलाकर हर internal service के लिए दो-line SSO configuration बना ली, और unRAID के लिए Dex Docker template[4] भी बनाया
इसके ऊपर घर के बाहर से access के लिए Cloudflare Access और WAF जोड़कर security मजबूत की, और थोड़ी ज्यादा insight पाने के लिए बस CrowdSec जोड़ना चाहता हूं
- obligator को temporary storage, कोई database नहीं, और 100% code-based configuration के साथ इस्तेमाल कर रहा हूं
  निजी तौर पर मुझे यही सबसे सरल विकल्प लगता है
  https://github.com/lastlogin-io/obligator
- जानना चाहता हूं कि oauth2-proxy Dex में न मौजूद कौन-सा feature देता है
मैंने self-host किए जा सकने वाले कई OpenID Connect servers की एक अधूरी comparison table बनाई है[0]
चौंकाने वाली बातों में से एक यह थी कि Keycloak codebase सच में बहुत विशाल है
[0]: https://github.com/lastlogin-io/obligator?tab=readme-ov-file...
यह सोचना मजाकिया है कि Keycloak security problems हल कर देता है
CVE list देखेंगे तो समझ जाएंगे मेरा मतलब क्या है
- https://www.cvedetails.com/vulnerability-list/vendor_id-25/p...
- यह दोधारी तलवार है
  जिन closed, non-transparent solutions में कोई reported CVE नहीं है, उन्हें भी “secure” कहना हास्यास्पद होगा
  और latest release 22.0.2 में सिर्फ 3 known vulnerabilities हैं
  https://www.cvedetails.com/vulnerability-list/vendor_id-25/p...
कम से कम उस article में https://www.keycloakify.dev/ का जिक्र बहुत उपयोगी है
यह standard theme approach का शानदार alternative लगता है
- बेहतरीन project है
  2 साल से इस्तेमाल कर रहा हूं और इसके बारे में सिर्फ अच्छी बातें ही कह सकता हूं
  maintainer बहुत तेजी से respond करता है, और हाल में Keycloak और keycloakify दोनों में theme approach की future compatibility बढ़ाने वाले changes भी आए हैं
  फिलहाल officially सिर्फ create-react-app से बनी apps support होती हैं, लेकिन vite branch development में है और निजी तौर पर मैं इसे काफी समय से vite के साथ इस्तेमाल कर रहा हूं
- मैं competitor के यहां काम करता हूं और हम theme system को फिर से work कर रहे हैं, इसलिए यह project review करने और rework model के तौर पर अपनाने के लिए अच्छा लगता है
authentik[1] और authelia[2] पर करीब से नज़र रख रहा हूँ
Authelia बहुत अच्छी लगती है, लेकिन Keycloak में Angular के लिए connector है, जबकि Authelia में, उदाहरण के लिए, OIDC Angular plugin को खुद configure करना पड़ता है, इसलिए थोड़ा सतर्क था
फिर भी अगर Keycloak के लिए setup मौजूद हो, तो शुरुआत आसान हो जाएगी
[1] https://goauthentik.io/
[2] https://www.authelia.com/
- अगर कोई authentik पर विचार कर रहा है, तो मैं चेतावनी देना चाहूँगा कि यह “जहाँ ड्रैगन छिपे हैं” वाला इलाका है
  मैं Docker और Kubernetes में हमेशा 10 से ज़्यादा services को protect कर रहा हूँ, और अगर आपको हर service के लिए protection settings अलग-अलग करना पसंद नहीं है, तो authentik में आपको परेशानी होगी
  authentik में एक गंभीर bug[0] है: कई subdomains (app1.example.com, app2.example.com आदि) को एक ही configuration से protect करते समय, session expire होने के बाद re-authentication करने पर user randomly किसी दूसरी service पर redirect हो जाता है
  [0]: https://github.com/goauthentik/authentik/issues/6886
- Authentik ने OAuth client credentials grant की implementation पूरी तरह बिगाड़ दी है
  compatibility तोड़े बिना इसे ठीक नहीं किया जा सकता, और यह cc grant इस्तेमाल करने वाले कई tools के साथ काम नहीं करता
  यह देखने के बाद मैंने इसे candidates से पूरी तरह हटा दिया
  https://github.com/goauthentik/authentik/issues/6139
- मैं Authelia के core maintainers में से एक हूँ
  अगर Angular setup में किसी तरह मदद कर सकता हूँ, तो GitHub Discussions के जरिए खुशी से मदद करूँगा
- अभी मैं भी ऐसा ही फैसला लेने की कोशिश कर रहा हूँ
  Authentik बेहतर लग रहा था, लेकिन दूसरे replies में बताया गया bug काफी खराब लगता है
Keycloak की समस्या यह है कि यह पुराना project है, इसलिए इसमें बहुत ज्यादा बदलाव हुए हैं
यह JBOSS project के रूप में शुरू हुआ था, और IdP के तौर पर इसकी उपयोगिता on-premises cluster authentication में चमकती है, लेकिन मेरे हिसाब से बस वहीं तक
Fortune 500 की एक division में AWS ECS पर Keycloak को बड़े scale पर implement किया था, और इसे ठीक से cluster कराने की प्रक्रिया 1000 साल के युद्ध जैसी थी
DNS discovery ठीक से काम नहीं कर रही थी, और cluster discovery UDP-based थी, इसलिए cloud environment में नहीं चली
एक server पर stateful login दूसरे server पर मौजूद नहीं था, इसलिए simple load balancing असंभव थी, और sticky sessions ही एकमात्र विकल्प था
Keycloak को docker run से चलाकर Auth0 की तरह plug-and-play करना आसान है, लेकिन यह 2,50,000 मील चली 1996 Ford F-150 खरीदने जैसा लगता है
चलती है और काम करती है, लेकिन maintenance सचमुच भयानक है
- scale छोटा था, लेकिन on-premises Docker Swarm के अंदर किया था, और वाकई दर्दनाक था
  जहाँ तक याद है, default discovery method multicast इस्तेमाल करता है, जो आम cloud networks या Swarm/Kubernetes overlay networks में enabled नहीं होता
  RDBMS को एक तरह के quorum mechanism की तरह इस्तेमाल करने वाला database ping भी देखा, लेकिन वह बहुत fragile लगा और last resort जैसा महसूस हुआ
  आखिरकार Swarm cluster के DNS से nodes discover करने वाला Kubernetes cluster driver इस्तेमाल कर पाया
  इसे चलाने लायक बनाना काफी मुश्किल था, लेकिन उसके बाद से जहाँ तक मुझे पता है, stable है
  आजकल शायद native EC2 networking driver भी है, लेकिन मैंने खुद explore नहीं किया
- सुना है कि Quarkus पर पूरी तरह move होने के बाद सुधार हुए हैं
  ECS deployment आपने कब किया था, यह जानने की उत्सुकता है
- OAuth और OpenID Connect, और realm में apps और clients जोड़ पाने की क्षमता ही Keycloak की saving grace थी, और यही इसे जारी रखने की एकमात्र वजह थी
- cluster discovery UDP थी, यह सुनकर दर्द होता है
  हमारे यहाँ UDP सिर्फ DNS के लिए allowed है
Keycloak शानदार है, लेकिन beginners के लिए काफी confusing हो सकता है
इसमें features बहुत हैं और documentation सबसे अच्छी नहीं है
हाल में Zitadel इस्तेमाल किया, और वह कहीं ज्यादा easy to use लगा
हालांकि built-in database के साथ run नहीं कर सकते, इसलिए self-hosting थोड़ी ज्यादा मुश्किल है
- सही है, इसके लिए अपनी database चाहिए
  आगे चलकर Postgres को database के तौर पर इस्तेमाल करने की दिशा है, इसलिए उम्मीद है कि दूसरे tools के साथ deploy करना आसान होगा
मेरे boss ने हाल ही में Keycloak को “ऐसी चीज़ जो लगातार gift देती रहती है” कहा, लेकिन असल में मतलब यह था कि कुछ कैसे करना है, यह पता लगाने के लिए नए Jira tickets लगातार बनते रहते हैं
फिर भी हमारे पास Terraform है जो EKS cluster बनाता है, Keycloak deploy करता है, SAML/OIDC clients बनाता है, external ID providers जोड़ता है, और AWS IAM Identity Provider तक configure करता है
जब आप यह पता लगा लें कि क्या किया जा सकता है, UI में कैसे किया जाता है, और mrparkers Terraform provider से उसे कैसे automate करना है, तो इसे इस्तेमाल करना खुद में बहुत आसान हो जाता है
- क्या वह Terraform कहीं open source में public है?
  एक दोस्त को इसकी ज़रूरत है :)
कई साल Keycloak इस्तेमाल करने के बाद सच कहूँ तो उसकी हर तरह की अजीब behaviours से तंग आकर alternatives ढूँढने शुरू किए
Authentik आदि कई candidates ठीक लग रहे थे, लेकिन Zitadel[1] ने ध्यान खींचा, और उसके बाद पीछे मुड़कर नहीं देखा
[1] https://zitadel.com/blog/zitadel-vs-keycloak
- अच्छा है कि आपको पसंद आया
  जानना चाहूँगा कि निर्णायक रूप से किस चीज़ ने आपको attract किया

Docker Compose और nginx के साथ Keycloak SSO कॉन्फ़िगर करना

डिप्लॉयमेंट संरचना और पूर्वापेक्षाएँ

तैयारी का काम

Docker Compose से Keycloak चलाना

लोकल टेस्ट

nginx reverse proxy और TLS

डिबगिंग पथ

custom image और optimized रन

production environment में अतिरिक्त tuning

कॉन्फ़िगरेशन के बाद के चरण

संबंधित पढ़ाई

1 टिप्पणियां

Hacker News की राय