Ubuntu সার্ভারের জন্য Cockpit নাকি Webmin সেরা?

Cockpit বনাম Webmin: সংক্ষিপ্ত উত্তর

Cockpit এবং Webmin উভয়ই ব্রাউজার থেকে Linux সার্ভার পরিচালনার জন্য ওয়েব প্যানেল, তবে এদের উদ্দেশ্য ভিন্ন। Cockpit আপনার ডিস্ট্রিবিউশনের নিজস্ব রিপোজিটরিতে থাকে এবং systemd, journald, polkit ও udisks-এর মাধ্যমে মেশিনটি পর্যবেক্ষণ করে। ফলে এটি এমন একটি সার্ভার দেখায় যা আপনি মূলত SSH দিয়েই পরিচালনা করছেন। Webmin অনেক পুরনো এবং এর পরিধি অনেক বিস্তৃত: এটি Apache, BIND, Postfix, MariaDB এবং এমন অনেক সার্ভিসের কনফিগারেশন ফাইল সরাসরি পরিবর্তন করতে পারে যা Cockpit কখনোই স্পর্শ করে না। এই কাজগুলো করার জন্য এটি root হিসেবে নিজস্ব ওয়েব সার্ভার চালায়।

যখন আপনি একটি সার্ভারের লাইভ ভিউ, লগ রিডার এবং জরুরি প্রয়োজনে টার্মিনাল অ্যাক্সেস চান, তখন Cockpit ইনস্টল করুন। যখন আপনার এমন কোনো সার্ভিসের জন্য ফর্ম-ভিত্তিক এডিটর প্রয়োজন যা আপনি হাতে কনফিগার করতে চান না, তখন Webmin ইনস্টল করুন। কোনোটিই পাসওয়ার্ড লগইনসহ পাবলিক পোর্টে রাখবেন না। যদি আপনি ইতিমধ্যে দুই বা তিনটির বেশি সার্ভার পরিচালনা করেন, তবে সৎ উত্তর হলো—কোনোটিই ব্যবহার না করা। কারণ SSH এবং Ansible-এর সমন্বিত পদ্ধতি যেকোনো প্যানেলের চেয়ে অনেক বেশি কার্যকর।

প্রতিটি প্যানেল আসলে কী পরিবর্তন করতে পারে

Cockpit-এর বেস ইনস্টলেশন ছোট, এবং বেশিরভাগ অংশই আলাদা প্যাকেজ যা আপনি চাইলে বাদ দিতে পারেন:

• systemd services এবং timers: unit file চালু, বন্ধ, enable এবং পড়া যায়
• journal, যা unit এবং priority অনুযায়ী ফিল্টার করা যায়, এবং এটি journalctl এর মাধ্যমে তারিখ নির্বাচন করার সুবিধা দেয়
• লোকাল অ্যাকাউন্ট, গ্রুপের সদস্যপদ এবং authorized SSH keys
• cockpit-storaged সহ স্টোরেজ: partitions, LVM volume groups, filesystems এবং mount points
• cockpit-podman সহ কন্টেইনার, যা শুধুমাত্র Podman পরিচালনা করে
• cockpit-packagekit এর মাধ্যমে প্যাকেজ আপডেট
• cockpit-pcp এর মাধ্যমে CPU, memory, disk এবং network-এর গ্রাফ
• ব্রাউজার ট্যাবে একটি root terminal

Ubuntu VPS-এ দুটি অংশ অকেজো মনে হলেও আসলে তা নয়। Cockpit-এর Networking পেজটি NetworkManager-এর একটি ফ্রন্ট-এন্ড, আর Ubuntu সার্ভার ইমেজ netplan এবং systemd-networkd ব্যবহার করে, তাই এই পেজটি অনুপস্থিত বা খালি থাকে। এটি ফিরে পাওয়ার জন্য রিমোট বক্সে NetworkManager ইনস্টল করবেন না, কারণ এটি ইন্টারফেসের নিয়ন্ত্রণ নিয়ে নেয় এবং সেখানে কোনো ভুল হলে আপনি SSH সেশনও হারিয়ে ফেলতে পারেন। Cockpit-এর firewall কন্ট্রোলগুলো firewalld-এর ফ্রন্ট-এন্ড, আর Ubuntu ufw ব্যবহার করে, তাই আপনি কোনো firewall কন্ট্রোল পাবেন না। আপনাকে টার্মিনালে sudo ufw status ব্যবহার চালিয়ে যেতে হবে।

Webmin অনেক বেশি জায়গা জুড়ে কাজ করে, কারণ এটি একটি প্রোগ্রামের পরিবর্তে প্রতি-সার্ভিস মডিউলের একটি সংগ্রহ:

• ফর্মের মাধ্যমে Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL এবং Samba কনফিগারেশন
• ব্যবহারকারী, গ্রুপ এবং ডিস্ক কোটা
• cron jobs এবং সিস্টেম ক্লক
• প্যাকেজ আপডেট, এবং আপলোড ও ডাউনলোডের সুবিধাসহ একটি ফাইল ম্যানেজার
• firewall ফ্রন্ট-এন্ড, যার মধ্যে iptables এবং firewalld-এর জন্য একটি করে মডিউল আছে
• কনফিগারেশন ফাইলের ব্যাকআপ, এবং ক্লাস্টার মডিউল যা একটি পরিবর্তন অন্যান্য Webmin সার্ভারে পাঠিয়ে দেয়

Webmin /etc এর অধীনে থাকা আসল ফাইলগুলো এডিট করে। ফর্মগুলোর পেছনে কোনো লুকানো ডাটাবেস নেই, তাই যদি /etc ভার্সন কন্ট্রোলে থাকে, তবে ফর্ম সেভ করার পর sudo git -C /etc diff চালালে মডিউলটি ঠিক কী লিখেছে তা দেখা যায়। Webmin-এর কোনো পেজ আসলে কী কাজ করে তা শেখার এটিই দ্রুততম উপায়। Webmin ইনস্টল এবং প্রথম লগইন নির্দেশিকা মডিউল ট্রি নিয়ে বিস্তারিত আলোচনা করে। Virtualmin এবং Usermin একই ইঞ্জিনের ওপর তৈরি আলাদা পণ্য, যা শেয়ারড হোস্টিং এবং সাধারণ ব্যবহারকারীদের জন্য তৈরি, এবং এগুলো এখানে উল্লিখিত এক্সপোজার সংক্রান্ত সব বৈশিষ্ট্য উত্তরাধিকারসূত্রে পায়।

প্রতিটি যেভাবে প্রমাণীকরণ (authentication) করে

Cockpit-এর নিজস্ব কোনো ইউজার ডাটাবেস নেই। এর লগইন পেজ /etc/pam.d/cockpit-এ PAM (pluggable authentication modules) স্ট্যাক চালায়, তাই আপনার অ্যাকাউন্টগুলো হলো ইউনিক্স (Unix) অ্যাকাউন্ট এবং পাসওয়ার্ডগুলো হলো ইউনিক্স পাসওয়ার্ড। ডিফল্টভাবে root-কে প্রবেশ করতে দেওয়া হয় না কারণ /etc/cockpit/disallowed-users-এ এটি তালিকাভুক্ত থাকে। সুবিধাপ্রাপ্ত (privileged) কাজগুলো polkit-এর মাধ্যমে সম্পন্ন হয় এবং কোনো কিছু পরিবর্তন করার আগে ইন্টারফেসটি পুনরায় আপনার পাসওয়ার্ড জানতে চায়; এই কারণেই পেজের হেডার "Limited access" দেখাতে পারে যতক্ষণ না আপনি প্রিভিলেজ বাড়াচ্ছেন।

এই ডিজাইনের একটি ফলাফল হার্ডেনড (hardened) সার্ভারে দেখা যায়। আপনি যদি পাসওয়ার্ড প্রমাণীকরণ নিষ্ক্রিয় করে শুধুমাত্র SSH কি (key) দিয়ে লগইন করার পদ্ধতি অনুসরণ করে থাকেন, তবে ওই অ্যাকাউন্টের কোনো ব্যবহারযোগ্য পাসওয়ার্ড নাও থাকতে পারে। ফলে Cockpit লগইন প্রত্যাখ্যান করে, যদিও ssh তখনও কাজ করে। সার্ভারে এটি পরীক্ষা করুন:

sudo passwd -S deploy

deploy L দিয়ে শুরু হওয়া আউটপুট মানে হলো পাসওয়ার্ডটি লক করা আছে, তাই PAM-এর গ্রহণ করার মতো কিছু নেই এবং আপনি যে পাসওয়ার্ডই টাইপ করুন তা কাজ করবে না। P মানে হলো একটি ব্যবহারযোগ্য পাসওয়ার্ড সেট করা আছে। Cockpit-এর নিজস্ব লগইন পেজ SSH কি (key) গ্রহণ করে না। কি (key) শুধুমাত্র তখনই ব্যবহৃত হয় যখন Cockpit আপনার লগইন করা মেশিন থেকে অন্য কোনো হোস্টের সাথে সংযোগ স্থাপন করে।

Webmin তার নিজস্ব ইউজারদের /etc/webmin/miniserv.users-এ রাখে, যা /etc/passwd থেকে আলাদা, তবে একে ইউনিক্স অ্যাকাউন্টের বিপরীতে প্রমাণীকরণ করার নির্দেশও দেওয়া যায়। যে Webmin ইউজারকে সমস্ত মডিউলের অনুমতি দেওয়া হয়েছে, তিনি সেই মেশিনে root হিসেবে গণ্য হন, তার লগইন শেল যাই হোক না কেন। Webmin-এর নিজস্ব TOTP (time-based one-time password) সাপোর্ট এবং বারবার ব্যর্থ লগইনের পর হোস্ট ব্লক করার সুবিধা রয়েছে, যার উভয়ই Webmin Configuration-এর ভেতর থেকে চালু করা যায়। Cockpit-এ দ্বিতীয় স্তরের প্রমাণীকরণ (second factor) তখনই যুক্ত হয় যদি আপনি PAM-এ তা যোগ করেন, উদাহরণস্বরূপ libpam-google-authenticator ব্যবহার করে।

প্রতিটি যেভাবে আপডেট করা হয়

Cockpit আপনার ডিস্ট্রিবিউশন দ্বারা প্যাকেজ করা থাকে। Ubuntu 24.04-এ এটি আর্কাইভ থেকে আসে এবং আপস্ট্রিম প্রজেক্ট নতুন বিল্ডের জন্য backports পকেট ব্যবহারের পরামর্শ দেয়:

. /etc/os-release
sudo apt update
sudo apt install -t ${VERSION_CODENAME}-backports cockpit
sudo systemctl status cockpit.socket
apt policy cockpit

apt policy আপনার ইনস্টল করা ভার্সন এবং এটি যে রিপোজিটরি থেকে এসেছে তা প্রদর্শন করে। যদি backports-এ কোনো নতুন বিল্ড না থাকে, তবে apt আর্কাইভ ভার্সনে ফিরে যায়, যা ঠিক আছে। cockpit.socket-এ active (listening) লেখা থাকা উচিত। এরপর সিকিউরিটি ফিক্সগুলো আপনার কার্নেলের মতোই একই unattended-upgrades কমান্ডের মাধ্যমে আসে, এমন একজন পাবলিশারের কাছ থেকে যাকে আপনি ইতিমধ্যেই বিশ্বাস করেন।

Webmin উবুন্টুর আর্কাইভে নেই। অফিসিয়াল ইনস্টলেশন প্রথমে Webmin-এর নিজস্ব রিপোজিটরি এবং সাইনিং কি যোগ করে:

curl -o webmin-setup-repo.sh https://raw.githubusercontent.com/webmin/webmin/master/webmin-setup-repo.sh
sudo sh webmin-setup-repo.sh
sudo apt-get install webmin --install-recommends

সেই স্ক্রিপ্টটি চালানোর আগে পড়ে নিন, কারণ এটি root হিসেবে চলে। এরপর থেকে সার্ভারের প্রতিটি apt upgrade কমান্ড Webmin-এর রিপোজিটরি থেকেও ডেটা টানে, তাই আপনি বক্সে root-লেভেল ট্রাস্টসহ দ্বিতীয় একজন পাবলিশারকে যুক্ত করেছেন। এটিই Webmin-এর আসল খরচ এবং এটি একটি স্পষ্ট উদাহরণের দাবি রাখে: CVE-2019-15107 ছিল 1.9x প্যাকেজের বেশ কয়েকটিতে থাকা একটি ব্যাকডোর, যা আনঅথেনটিকেটেড কমান্ড এক্সিকিউশন করার সুযোগ দিত। এটি ব্যবহারকারীদের কাছে পৌঁছেছিল কারণ প্রজেক্টের বিল্ড হোস্টটি compromised হয়েছিল, তাদের সোর্স রিপোজিটরি নয়। ডিস্ট্রিবিউশন প্যাকেজিং এটিকে অসম্ভব করে তোলে না। তবে এটি এমন একটি বিল্ড এবং রিভিউ ধাপ যোগ করে যা আপনি নিজে মেইনটেইন করছেন না।

কেন কোনোটিই পাবলিক পোর্টে রাখা উচিত নয়

Cockpit TCP 9090 পোর্টে এবং Webmin TCP 10000 পোর্টে TLS (transport layer security) ব্যবহার করে চলে, যার সাথে একটি self-signed certificate থাকে, তাই ব্রাউজারে প্রথমেই একটি সতর্কবার্তা দেখা যায়। Creating and trusting a self-signed certificate অংশে এই সতর্কবার্তাটি কী বোঝায় এবং কী বোঝায় না তা ব্যাখ্যা করা হয়েছে। উভয় পোর্টই সবসময় স্ক্যান করা হয় এবং উভয় প্যানেলই root অ্যাক্সেস দেয়, তাই পাসওয়ার্ড অনুমান করা গেলে বা অন্য কোথাও ব্যবহৃত পাসওয়ার্ড মিলে গেলে সার্ভারটি পুরোপুরি compromised হয়ে যেতে পারে।

নিরাপদ পদ্ধতি হলো প্যানেলটিকে localhost-এ bind করা এবং SSH tunnel-এর মাধ্যমে সেটি অ্যাক্সেস করা। Cockpit-এর জন্য, socket unit-টিকে override করুন:

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

এখানে আলাদা লাইনে থাকা খালি ListenStream= অংশটি প্রয়োজনীয়। systemd লিস্ট সেটিংসে নতুন মান যুক্ত করে, তাই এটি ছাড়া unit-টি আগের 0.0.0.0:9090 মানটি রেখে দেবে এবং নতুন ঠিকানা যোগ করবে, ফলে আপনার প্যানেলটি পাবলিকই থেকে যাবে। override প্রয়োগ করুন এবং কোন পোর্টটি listening অবস্থায় আছে তা যাচাই করুন:

sudo systemctl daemon-reload
sudo systemctl restart cockpit.socket
sudo ss -lntp | grep 9090

আউটপুটে অবশ্যই 127.0.0.1:9090 দেখাতে হবে। যদি ঠিকানা *:9090 বা 0.0.0.0:9090 দেখায়, তবে বুঝতে হবে override কার্যকর হয়নি। এখন আপনার নিজের মেশিন থেকে tunnel খুলুন এবং https://localhost:9090 ঠিকানায় ব্রাউজ করুন:

ssh -N -L 9090:127.0.0.1:9090 deploy@203.0.113.10

local port এবং remote port একই রাখুন। Cockpit ব্রাউজারের Origin হেডার এবং সার্ভারের নিজস্ব ঠিকানার সাথে তুলনা করে, তাই local port 9999 থেকে tunnel করলে লগইন পেজ লোড হলেও লগইন করার সময় ব্যর্থ হবে এবং journalctl -u cockpit-এ প্রত্যাখ্যাত origin রেকর্ড হবে। যদি ভিন্ন কোনো local port প্রয়োজন হয়, তবে /etc/cockpit/cockpit.conf-এ সেটি উল্লেখ করুন:

[WebService]
Origins = https://localhost:9999 https://127.0.0.1:9999

পরিবর্তনটি কার্যকর করতে sudo systemctl restart cockpit.socket দিয়ে রিস্টার্ট করুন। Webmin-এর ক্ষেত্রে সমতুল্য সেটিংটি /etc/webmin/miniserv.conf ফাইলে থাকে:

bind=127.0.0.1

sudo systemctl restart webmin
sudo ss -lntp | grep 10000
ssh -N -L 10000:127.0.0.1:10000 deploy@203.0.113.10

Webmin ফর্ম পোস্টের সময় Referer হেডারটিও পরীক্ষা করে এবং অন্য কোনো host থেকে আসা অনুরোধ প্রত্যাখ্যান করে, যা reverse proxy ব্যবহারের প্রথম চেষ্টাকে ব্যর্থ করে দেয়। একই ফাইলের referers= লাইনে আপনি proxy-এর hostname অনুমোদন করতে পারেন এবং webprefix= লাইনে Webmin-কে জানাতে পারেন যে এটি একটি নির্দিষ্ট path-এর অধীনে চলছে।

একটি authenticated reverse proxy হলো অন্য বিকল্প: সামনে nginx থাকবে এবং Authentik single sign-on layer লগইন প্রক্রিয়াটি সম্পন্ন করবে। এটি কাজ করে এবং এটি দ্বিতীয় সেরা পদ্ধতি। তবে প্যানেলটি তখনও proxy-এর পেছনে root হিসেবেই চলে এবং আপনাকে একটির বদলে দুটি ফ্রন্ট ডোর রক্ষণাবেক্ষণ করতে হয়। একটি tunnel ইন্টারনেটে কোনো listening service উন্মুক্ত করে না এবং এটি আপনার ইতিমধ্যে সুরক্ষিত রাখা SSH key-ই পুনরায় ব্যবহার করে।

যে বক্সে ইতিমধ্যে প্রোডাকশন সার্ভিস চলছে সেখানে কোন প্যানেল ব্যবহার করবেন

Cockpit ব্যবহার করুন, কারণ অন্যদের নির্ভরতা রয়েছে এমন মেশিনের ক্ষেত্রে দুটি গুরুত্বপূর্ণ কারণ রয়েছে। এটি socket activated, তাই cockpit-ws শুধুমাত্র তখনই চলে যখন কোনো সেশন খোলা থাকে এবং কোনো স্থায়ী root daemon কোনো পোর্টে অপেক্ষা করে না। এছাড়া এটি কোনো কিছুর মালিকানা নেয় না: প্যাকেজটি রিমুভ করলে প্রতিটি সার্ভিস আগের মতোই চলতে থাকে, কারণ Cockpit নিজের কোনো কনফিগারেশন সংরক্ষণ করে না। Webmin-এর miniserv.pl লগইন থাকুক বা না থাকুক সবসময় সচল থাকে। systemctl status webmin ব্যবহার করে আপনারটির খরচ পরীক্ষা করুন, যা চলমান প্রসেসের রেসিডেন্ট মেমোরি প্রদর্শন করে।

যদি আপনার Webmin-এর DNS বা মেইল মডিউলের প্রয়োজন হয়, তবে সেগুলোকে আলাদা সার্ভারে রাখুন। একটি Webmin বক্স যা একটি নির্দিষ্ট কাজ করে এবং 127.0.0.1-এ আবদ্ধ থাকে, তা একটি নিয়ন্ত্রিত ঝুঁকি। গ্রাহকের মুখোমুখি অ্যাপ্লিকেশনের সাথে Webmin শেয়ার করা নিরাপদ নয়। যেকোনো প্যানেল ইনস্টল করার আগে প্রাথমিক কাজগুলো সম্পন্ন করুন: নতুন VPS-এ প্রথম দশ মিনিট নিবন্ধটি নন-রুট ইউজার এবং ফায়ারওয়াল নিয়ে আলোচনা করে, যা উভয় প্যানেলই আগে থেকে বিদ্যমান আছে বলে ধরে নেয়।

যখন উত্তরটি এর কোনোটিই নয়

একটি প্যানেল প্রতি-সার্ভার ভিত্তিতে কাজ করে এবং এটি ম্যানুয়াল, যা কী পরিবর্তন করা হয়েছে বা কেন করা হয়েছে তার কোনো রেকর্ড রাখে না। একটি সার্ভারের জন্য এটি ঠিক আছে। পাঁচটি সার্ভারের ক্ষেত্রে আপনি একই কাজ বারবার করছেন এবং বিশটি সার্ভারের ক্ষেত্রে আপনি অনুমান করতে পারছেন না কোন সার্ভারে পরিবর্তনটি বাদ পড়েছে। Cockpit-এর মাধ্যমে SSH ব্যবহার করে একটি সেশনে অন্যান্য হোস্ট যোগ করা যায়, কিন্তু সাম্প্রতিক সংস্করণগুলোতে এটি ডিফল্টভাবে নিষ্ক্রিয় থাকে এবং এর জন্য AllowMultiHost=yes প্রয়োজন হয় /etc/cockpit/cockpit.conf-এ, তাছাড়া এতে আপনাকে একই পরিবর্তন পাঁচবার ক্লিক করে করতে হয়।

এর বিকল্প হলো সাধারণ SSH এবং আপনার কনফিগারেশন একটি git রিপোজিটরিতে রাখা। এক জায়গা থেকে একাধিক Linux সার্ভার পরিচালনা এই সেটআপের রূপরেখা তুলে ধরে এবং প্রথম Ansible playbook একই firewall রুল প্রতিটি হোস্টে প্রয়োগ করে, যা আপনি একটি ফাইলের মাধ্যমে diff হিসেবে যাচাই করতে পারেন। কন্টেইনারের কাজও একইভাবে করা যায়: git-এ থাকা ফাইল থেকে SSH-এর মাধ্যমে docker compose up -d চালানো, যেমনটি Docker Compose-এর প্রাথমিক নির্দেশিকা-তে দেখানো হয়েছে, যেকোনো প্যানেলে ক্লিক করার চেয়ে কার্যকর, এবং Cockpit মূলত Docker পরিচালনা করে না।

টার্মিনাল যে কাজগুলো করতে পারে না, যেমন মেট্রিক্স গ্রাফ দেখা বা চল্লিশটি ইউনিটের মধ্যে কোনটি ব্যর্থ হয়েছে তা শনাক্ত করার জন্য প্যানেল ব্যবহার করুন। আর যে কাজ আপনি দুইবারের বেশি করবেন, তার জন্য কোড ব্যবহার করুন।

ব্যর্থতার ধরন এবং যে বার্তাগুলো আপনি দেখবেন

SSH যে পাসওয়ার্ড গ্রহণ করে, Cockpit তা প্রত্যাখ্যান করে। অ্যাকাউন্টটি শুধুমাত্র key-based। sudo passwd -S alice দ্বিতীয় ফিল্ডে L প্রদর্শন করে, যার অর্থ PAM-এর কাছে যাচাই করার মতো কোনো পাসওয়ার্ড নেই। sudo passwd alice ব্যবহার করে একটি পাসওয়ার্ড সেট করুন, অথবা ওই অ্যাকাউন্টটি শুধুমাত্র SSH-এর জন্য রেখে অন্য কোনো ব্যবহারকারী হিসেবে Cockpit-এ লগইন করুন।

সঠিক পাসওয়ার্ড থাকা সত্ত্বেও Cockpit root লগইন প্রত্যাখ্যান করে। /etc/cockpit/disallowed-users-এ root তালিকাভুক্ত থাকে। sudo অধিকার আছে এমন একজন সাধারণ ব্যবহারকারী হিসেবে লগইন করুন। এটিই নির্ধারিত পদ্ধতি, কারণ এর ফলে polkit রেকর্ড করতে পারে কোন ব্যক্তি বিশেষাধিকার গ্রহণ করেছেন।

Cockpit-এ Networking বা Firewall পেজ দেখা যাচ্ছে না। এই পেজগুলোর জন্য NetworkManager এবং firewalld প্রয়োজন। Ubuntu VPS-এ systemd-networkd এবং ufw সহ netplan চলে, তাই এই পেজগুলো প্রদর্শিত হয় না। কোনো কিছু নষ্ট হয়নি, এর সমাধান হলো SSH-এর মাধ্যমে ufw ব্যবহার চালিয়ে যাওয়া।

টানেলের মাধ্যমে Cockpit লগইন পেজ লোড হয়, কিন্তু লগইন ব্যর্থ হয়। আপনার লোকাল পোর্ট এবং রিমোট পোর্ট ভিন্ন, তাই Origin চেকটি ব্যর্থ হয় এবং journalctl -u cockpit তা প্রদর্শন করে। পোর্টগুলো মিলিয়ে নিন, অথবা /etc/cockpit/cockpit.conf ফাইলে Origins সেট করুন।

প্রক্সির পেছনে রাখার পর Webmin ফর্ম পোস্ট ব্যর্থ হয়। Referer চেকটি এগুলোকে প্রত্যাখ্যান করে। /etc/webmin/miniserv.conf ফাইলে referers=-এ প্রক্সির হোস্টনাম যোগ করুন এবং প্যানেলটি কোনো নির্দিষ্ট পাথের অধীনে চললে webprefix= সেট করুন।

প্যানেলটি এক্সপোজড কি না তা নিয়ে আপনি নিশ্চিত নন। sudo ss -lntp | grep -E '9090|10000' সার্ভার থেকেই এর উত্তর দেয় এবং Webmin প্রতিটি লগইন প্রচেষ্টাকে /var/webmin/miniserv.log ফাইলে লিখে রাখে, যা এটি কীভাবে লিসেন করছে তা পরিবর্তনের পর অন্তত একবার পড়ে দেখা উচিত।

FAQ

একটি Ubuntu VPS-এর জন্য Cockpit নাকি Webmin কোনটি ভালো?

অধিকাংশ ব্যবহারকারীর জন্য Cockpit ভালো, কারণ এটি Ubuntu-এর নিজস্ব রিপোজিটরি থেকে আসে, সিস্টেমের সাথে নিয়মিত আপডেট পায় এবং শুধুমাত্র ব্রাউজার সেশন খোলা থাকলেই এটি সচল থাকে। Webmin তখনই বেছে নিন যখন আপনার এমন কোনো সার্ভিসের জন্য ফর্ম-ভিত্তিক এডিটর প্রয়োজন যা Cockpit সমর্থন করে না, যেমন BIND বা Postfix। তবে মনে রাখবেন, এর বিনিময়ে আপনাকে মেনে নিতে হবে যে এর ওয়েব সার্ভার সবসময় root হিসেবে চলে এবং এর আপডেটগুলো Webmin-এর নিজস্ব রিপোজিটরি থেকে আসে।

আমি কি একই সার্ভারে Cockpit এবং Webmin চালাতে পারি?

হ্যাঁ। এরা ভিন্ন ভিন্ন পোর্ট (9090 এবং 10000) ব্যবহার করে, তাই এদের মধ্যে কোনো সংঘর্ষ হয় না; কারণ প্রতিটি টুলই সিস্টেমকে সরাসরি এডিট করে, সিস্টেমের মালিকানা নেয় না। তবে এটি একটি দুর্বল কৌশল। প্রতিটি প্যানেলই একই মেশিনে root-এর ক্ষমতা সম্পন্ন আলাদা লগইন পয়েন্ট, তাই মাত্র কয়েকটি ক্লিক বাঁচানোর জন্য আপনি আপনার ঝুঁকির পরিমাণ দ্বিগুণ করছেন। যদি দুটিই ইনস্টল করতে হয়, তবে উভয়কেই 127.0.0.1-এ bind করুন এবং SSH tunnel-এর মাধ্যমে সেগুলোতে প্রবেশ করুন।

ইন্টারনেট থেকে পোর্ট 9090 বা 10000 খোলা রাখা কি নিরাপদ?

পাসওয়ার্ড লগইন ব্যবহার করলে এটি নিরাপদ নয়। উভয় প্যানেলই root-এর নিয়ন্ত্রণ দেয় এবং পোর্ট খোলার কয়েক ঘণ্টার মধ্যেই রুটিন স্ক্যানিংয়ের মাধ্যমে এগুলো ধরা পড়ে। প্যানেলটিকে 127.0.0.1-এ bind করুন, তারপর ssh -N -L 9090:127.0.0.1:9090 user@host চালান এবং https://localhost:9090-এ ব্রাউজ করুন। sudo ss -lntp | grep 9090 দিয়ে নিশ্চিত করুন, যেখানে অবশ্যই 127.0.0.1:9090 দেখাতে হবে, 0.0.0.0:9090 নয়। একটি authenticated reverse proxy ব্যবহার করা দ্বিতীয় গ্রহণযোগ্য বিকল্প হতে পারে।

SSH কি (key) দিয়ে কাজ করলেও কেন আমার Cockpit লগইন ব্যর্থ হয়?

Cockpit PAM-এর মাধ্যমে Unix পাসওয়ার্ড দিয়ে প্রমাণীকরণ (authenticate) করে এবং এর লগইন পেজ SSH কি গ্রহণ করে না। একটি সুরক্ষিত (hardened) সার্ভারে অনেক সময় অ্যাকাউন্টে কোনো ব্যবহারযোগ্য পাসওয়ার্ড থাকে না। sudo passwd -S youruser চালান: দ্বিতীয় ফিল্ডে যদি L থাকে, তার মানে পাসওয়ার্ডটি লক করা আছে। ফলে PAM-এর কাছে গ্রহণ করার মতো কিছু থাকে না এবং প্রতিটি প্রচেষ্টাই প্রত্যাখ্যাত হয়। sudo passwd youruser ব্যবহার করে একটি পাসওয়ার্ড সেট করুন অথবা প্যানেলের জন্য অন্য একটি অ্যাকাউন্ট ব্যবহার করুন।

Cockpit কি Docker কন্টেইনার ম্যানেজ করতে পারে?

না। Cockpit-এর কন্টেইনার পেজটি cockpit-podman থেকে আসে এবং এটি Podman ম্যানেজ করে। পুরনো Docker মডিউলটি অনেক বছর আগেই বাদ দেওয়া হয়েছে এবং এটি আর ফিরে আসবে না। যদি আপনার সার্ভিসগুলো Docker-এর অধীনে চলে, তবে SSH-এর মাধ্যমে version control-এ থাকা compose file দিয়ে সেগুলো ম্যানেজ করুন এবং সিস্টেমের অন্যান্য বিষয়, যেমন journal এবং ডিস্ক ম্যানেজমেন্টের দায়িত্ব Cockpit-এর ওপর ছেড়ে দিন।