CMS সিঙ্ক ও সার্টিফিকেট পরিচালনা
1. পরিচিতি
DAT CMS (Certificate Management Service) হলো এমন একটি সার্ভার যা পুরো ক্লাস্টার ভাগাভাগি করবে এমন সার্টিফিকেট তৈরি ও বিতরণ করে।
প্রতিটি অ্যাপ্লিকেশন CMS ক্লায়েন্টের (DatCmsManager) মাধ্যমে নিয়মিতভাবে সার্টিফিকেটের তালিকা নিয়ে যায়, আর এই সিঙ্কই কী রোলিং স্বয়ংক্রিয় করে। অপারেটর নিজে কী প্রতিস্থাপন না করলেও সার্টিফিকেট নির্ধারিত চক্রে নতুন করে তৈরি হয় এবং পুরোনোগুলো নিজে থেকেই মেয়াদোত্তীর্ণ হয়।
ইস্যু করার উপযোগী সার্টিফিকেট কেবল লগইন সার্ভারই পায়; কনটেন্ট সার্ভারগুলো শুধু যাচাইয়ের সার্টিফিকেট পায়। কনটেন্ট সার্ভারের শুধু CMS-কে জানলেই চলে, লগইন সার্ভারকে জানার দরকার নেই।
2. সিঙ্ক প্রোটোকল
2.1. অনুরোধ ও উত্তর
| এন্ডপয়েন্ট | ব্যবহার |
|---|---|
GET /v1/certs?version=N | সম্পূর্ণ সার্টিফিকেট (স্বাক্ষরের প্রাইভেট কী সহ) |
GET /v1/certs/verify-only?version=N | কেবল যাচাইয়ের সার্টিফিকেট |
GET /v1/certs.json, /v1/certs/verify-only.json | একই বিষয়বস্তুর JSON ফরম্যাট |
POST /v1/cert/{sig-alg}/{crypto-alg}/{delay}/{duration}/{ttl} | সার্টিফিকেট ম্যানুয়ালি তৈরি (Master টোকেন প্রয়োজন) |
GET /health | অবস্থা পরীক্ষা |
উত্তরের বডি একটি সাধারণ টেক্সট যার প্রথম লাইনে সার্ভারের বর্তমান version, এবং তার পরের লাইনগুলোতে প্রতি লাইনে একটি করে সার্টিফিকেট থাকে।
1712345678
1a.1712345000.3600.1800.ECDSA-P256.IV-AES256-GCM.<sig-key>.<crypto-key>
2b.1712348600.3600.1800.ECDSA-P256.IV-AES256-GCM.<sig-key>.<crypto-key>2.2. ভার্সন কার্সর
ক্লায়েন্ট সর্বশেষ সফল version মনে রাখে এবং পরবর্তী অনুরোধে সেটি পাঠায়। সার্ভার সেই মানের চেয়ে নতুন সার্টিফিকেটগুলোই বেছে ফেরত দেয়।
- ক্লায়েন্টের version সার্ভারের চেয়ে পুরোনো হলে → তার পরে তৈরি হওয়া সার্টিফিকেটগুলোই ফেরত দেওয়া হয়।
- ক্লায়েন্টের version সার্ভারের চেয়ে নতুন হলে (সার্ভার প্রতিস্থাপন, DB রিসেট ইত্যাদি) → কার্সর
0-তে ফিরিয়ে পুরো সেট ফেরত দেওয়া হয়। - ক্লায়েন্ট কেবল ইমপোর্ট সফল হলেই version এগিয়ে নেয়। ব্যর্থ উত্তরে কার্সর এগিয়ে গিয়ে সার্টিফিকেট চিরতরে হারিয়ে ফেলার পরিস্থিতি ঠেকাতেই এই ব্যবস্থা।
অনুরোধ ইনক্রিমেন্টাল হলেও উত্তরটি সম্পূর্ণ প্রতিস্থাপন
?version=N মানে "N-এর পরের পরিবর্তনগুলো দাও" — কিন্তু ক্লায়েন্ট প্রাপ্ত তালিকাটিকে আগের তালিকার সাথে মেশায় না, বরং প্রতিস্থাপন (clear = true) করে। কারণ সার্ভার সবসময় বৈধ সার্টিফিকেটের পুরো সেট বিচার করেই নামিয়ে দেয়, এবং এই পদ্ধতির কারণেই CMS-এ প্রত্যাহার (revoke) করা সার্টিফিকেট ক্লায়েন্টে থেকে যায় না।
2.3. প্রমাণীকরণ টোকেন
CMS তিন ধরনের টোকেন দিয়ে অ্যাক্সেস ভাগ করে।
| টোকেন | অনুমতি |
|---|---|
Master টোকেন | DAT সার্টিফিকেট তৈরি করুন, সার্ভার ভার্সন দেখুন |
Full Cert টোকেন | Full (Pair Key, Hash Key) সার্টিফিকেট GET করুন |
Verify Cert টোকেন | Verify (Verify Key Only) সার্টিফিকেট GET করুন |
কেবল যাচাই করে এমন সার্ভারকে শুধু Verify Cert টোকেন দেওয়াই নীতি। তবে এনক্রিপশন কী verify-only উত্তরেও অন্তর্ভুক্ত থাকে, তাই এর অর্থ কী তা সার্টিফিকেট ডকুমেন্টের সতর্কতার সাথে মিলিয়ে দেখুন।
3. সার্টিফিকেট ইস্যুর বিলম্ব (delay)
নতুন সার্টিফিকেট তৈরি করার সাথে সাথেই ইস্যুতে ব্যবহার করলে, এখনো সিঙ্ক না করা অন্য নোড সেই সার্টিফিকেট দিয়ে স্বাক্ষরিত টোকেন যাচাই করতে পারে না। ইস্যু বিলম্ব এই ফাঁক দূর করার জন্যই।
উদাহরণস্বরূপ ধরুন CMS সার্টিফিকেট A তৈরি করল এবং সার্ভার 1 ও 2 প্রতি 60 সেকেন্ড অন্তর সিঙ্ক করে। সার্ভার 1 আগে সেটি পেয়ে A দিয়ে DAT ইস্যু করল, কিন্তু সার্ভার 2 তখনো সেটি পায়নি — তাহলে সার্ভার 2 ওই DAT যাচাই করতে পারবে না।
বিলম্ব 180 সেকেন্ড রাখলে সার্টিফিকেট তৈরির পর 180 সেকেন্ড ধরে সেটি ইস্যু-অযোগ্য অবস্থায় থাকে, আর সেই সময়ের মধ্যে সব সার্ভার নিরাপদে সিঙ্ক সম্পন্ন করে। সাময়িক নেটওয়ার্ক ত্রুটির কথা বিবেচনা করে এই মান প্রতিটি সার্ভারের সিঙ্ক ব্যবধানের অন্তত 3~4 গুণ বা তার বেশি রাখার সুপারিশ করা হয়।
4. উদ্দেশ্যপ্রণোদিত আচরণ
নিচের আচরণগুলো সবই ডিজাইন অনুযায়ী উদ্দেশ্যপ্রণোদিত, কোনো ত্রুটি নয়। পরিচালনার সময় প্রত্যাশার চেয়ে ভিন্ন মনে হতে পারে বলে এখানে স্পষ্ট করে বলা হলো।
4.1. ইস্যু-উইন্ডো বন্ধ হওয়ার পরও ক্যাশ করা সার্টিফিকেট দিয়ে স্বাক্ষর চলতে থাকে
অ্যাপ্লিকেশন সিঙ্কের সময় বেছে নেওয়া ইস্যুর সার্টিফিকেটটি ব্যবহার করতেই থাকে, প্রতিবার ইস্যুতে আবার issuable() পরীক্ষা করে না।
কারণ: CMS-এর সাথে সংযোগ বিচ্ছিন্ন অবস্থায় ইস্যু-উইন্ডো বন্ধ হয়ে গেলে, পুনঃপরীক্ষার পদ্ধতিতে ঠিক সেই মুহূর্তে পুরো সার্ভিসের লগইন থেমে যায়। DAT এ ক্ষেত্রে "নতুন সার্টিফিকেট না পেলেও আপাতত ইস্যু চালিয়ে যাওয়া" বেছে নিয়েছে।
মূল্য: নেটওয়ার্ক বিভ্রাট দীর্ঘ হলে ইস্যু-উইন্ডো পেরিয়ে যাওয়া সার্টিফিকেট দিয়েই টোকেন বেরোতে থাকতে পারে। তবে সেই টোকেনও সার্টিফিকেটের চূড়ান্ত মেয়াদ শেষের আগ পর্যন্ত অন্য নোডে স্বাভাবিকভাবে যাচাই হয়, তাই বিভ্রাটের সময় সার্ভিস বন্ধ হয়ে যাওয়ার চেয়ে এটিকে ভালো বিবেচনা করে নেওয়া একটি ট্রেড-অফ।
4.2. একই CID দিয়ে হালনাগাদ করা সার্টিফিকেট বাদ দেওয়া হয়
ইতিমধ্যে হাতে থাকা CID-এর মতো একই CID-এর সার্টিফিকেট এলে নতুন আসাটিকেই উপেক্ষা করা হয়।
কারণ: CID হলো সার্টিফিকেটের অপরিবর্তনীয় শনাক্তকারী। একই CID ভিন্ন ভিন্ন কী নির্দেশ করলে, ইতিমধ্যে ইস্যু হয়ে ঘুরে বেড়ানো টোকেন কোন কী দিয়ে যাচাই হবে তা আর জানা যায় না।
কী প্রতিস্থাপন অবশ্যই নতুন CID দিয়ে
একই CID রেখে কেবল কী বদলে বিতরণ করলে সেটি ক্লায়েন্টে কখনোই প্রতিফলিত হয় না, আবার কোনো ত্রুটিও দেখায় না। কী প্রতিস্থাপনের সময় নতুন CID-এর সার্টিফিকেট ইস্যু করুন।
4.3. নতুন সার্টিফিকেট না থাকলে বিদ্যমান তালিকা ধরে রাখা হয়
উত্তরে একটিও সার্টিফিকেট না থাকলে ক্লায়েন্ট হাতে থাকা তালিকা যেমন আছে তেমনই রাখে। তালিকা খালি করে না।
কারণ: সার্টিফিকেট সার্ভার বন্ধ কিংবা উত্তর অস্বাভাবিক — এমন সবচেয়ে খারাপ মুহূর্তে হাতে থাকা সার্টিফিকেট খালি করে দিলে সাথে সাথেই সব টোকেনের যাচাই ব্যর্থ হবে। নতুন কিছু না পেলে যা আছে তা দিয়ে টিকে থাকাই নিরাপদ।
4.4. SINGLE_NODE মোড প্রতিবার চালু হওয়ার সময় সার্টিফিকেট তৈরি করে
CMS একক নোড মোডে চালালে ইস্যুযোগ্য সার্টিফিকেট আছে কি না তা নির্বিশেষে প্রতিবার চালু হওয়ার সময় একটি সার্টিফিকেট তৈরি করে।
কারণ: একক নোড মোড হলো CMS-কে আলাদা অবকাঠামো ছাড়াই স্বতন্ত্রভাবে চালানোর কনফিগারেশন। চালু হওয়ার সাথে সাথেই ইস্যুযোগ্য সার্টিফিকেট থাকা দরকার।
সতর্কতা: বারবার পুনরায় চালু করলে সার্টিফিকেট জমতে থাকে। তবে প্রতিটি সার্টিফিকেট নিজের মেয়াদ শেষের সময় পেরোলে তালিকা থেকে বাদ পড়ে, তাই সেগুলো অসীমভাবে বাড়ে না।
4.5. ইস্যুযোগ্য সার্টিফিকেট না থাকলে বিলম্ব ছাড়াই তৎক্ষণাৎ ইস্যু হয়
সার্টিফিকেট তৈরির সময়ে ইস্যুযোগ্য একটিও সার্টিফিকেট না থাকলে CMS বিলম্ব পর্ব এড়িয়ে গিয়ে বিলম্বের সময়টুকু ইস্যুর মেয়াদের সাথে যোগ করে দেয়।
কারণ: বিলম্ব মেনে চললে সেই সময়টুকুতে পুরো ক্লাস্টার একটিও টোকেন ইস্যু করতে পারে না। প্রথমবার চালু হওয়া বা পূর্ণ বিভ্রাট থেকে পুনরুদ্ধারের পরিস্থিতিতে তৎক্ষণাৎ ইস্যু করা সম্ভব হওয়া দরকার। এ ক্ষেত্রে সার্ভার লগে একটি সতর্কবার্তা রেখে যাওয়া হয়।
5. সার্টিফিকেট প্রত্যাহার ও মেয়াদ শেষ
- সার্টিফিকেট চূড়ান্ত মেয়াদ শেষের (
start + duration + ttl) মুহূর্ত পর্যন্ত বিতরণ তালিকায় থাকে। ইস্যু-উইন্ডো বন্ধ হলেই সাথে সাথে হারিয়ে যায় না। - ইস্যু-উইন্ডো শেষ হওয়ার ঠিক আগে বেরোনো DAT নিজের TTL পরিমাণ সময় আরও বেঁচে থাকে, তাই সেই মুহূর্তের পরে প্রথমবার বুট হওয়া যাচাই সার্ভারও সার্টিফিকেটটি পেয়ে ওই টোকেন যাচাই করতে পারে।
- চূড়ান্ত মেয়াদ পেরিয়ে যাওয়া সার্টিফিকেট তালিকা থেকে বাদ পড়ে, এবং পরবর্তী পরিচ্ছন্নতার কাজে স্টোরেজ থেকেও মুছে ফেলা হয়।
6. ডিপ্লয়মেন্ট
CMS সার্ভারের রান অপশন, Docker · Kubernetes · বাইনারি ডিপ্লয়মেন্টের পদ্ধতি এবং এনভায়রনমেন্ট ভেরিয়েবল আলাদা ডকুমেন্টে আলোচনা করা হয়েছে।