দোকান খোলার আগে সার্ভারটি পরীক্ষা করুন
SixPreflight 6amMart-এর জন্য একটি সার্ভার-প্রস্তুতি পরীক্ষক। একটি ফোল্ডার আপলোড করুন, ব্রাউজারে খুলুন, আর 163টি পর্যন্ত পরীক্ষা শেষ হয় একটি বাক্যে: চালু করার জন্য প্রস্তুত, নাকি প্রস্তুত নয় — আর প্রথমে ঠিক কী ঠিক করতে হবে।
সবসময় চলতি রিলিজ, আর এটি আপনার নিজের সার্ভারেই চলে। এটি পড়ে: কোনো অ্যাপ্লিকেশন টেবিল কখনো পড়ে না বা লেখে না, আর কাউকে মেইল বা SMS পাঠায় না। টুলের নিজের ফোল্ডারের বাইরে কাজ করতে পারে এমন সারফেস তিনটি, আর চতুর্থটি ভেতরে লেখে — প্রতিটিই কেবল আপনি তার বোতাম চাপলে। দেখুন “আপনি বললে এটি কী বদলাবে”।
163
কোডে আলাদা পরীক্ষা
10
ধাপ, সবচেয়ে সস্তা ও সবচেয়ে ভাঙার সম্ভাবনা আগে
1
বাক্য, সবার শেষে
A–F
গ্রেড, প্রতিটি ব্লকারের নামসহ
একটি AI সহকারীর সাথে এই পৃষ্ঠাটি পড়ছেন?
SixPreflight নেওয়া
SixPreflight হলো PHP-র একটি ফোল্ডার, যেটি আপনি আপলোড করেন। আগে কিছু ইনস্টল করার দরকার নেই, সাইন আপেরও দরকার নেই। এটি বিনামূল্যে।
ডাউনলোডের আগে চালিয়ে দেখুন
ডেমোর পাসওয়ার্ড
Password: a3uap648vnh7yqenc9vb
No username — SixPreflight asks for the password only.
The shop runs a real dataset — tens of thousands of orders — so the screens behave the way they will on yours, not the way a demo with forty products does. Two things are switched off on the demo: maps and SMS one-time passwords. Both use keys locked to a single server, which is how they should be held, so they cannot answer from a demo host. They work normally on your own install.
SixPreflight নিন
Free- আপডেট অন্তর্ভুক্ত — প্রতিটি রিলিজ কোনো বাড়তি খরচ ছাড়াই CodeCanyon-এ যায়। কোনো লাইসেন্স সার্ভার নেই, নবায়ন করার মতো কোনো কী নেই।
- প্রথম সেটআপ বিনামূল্যে — আপনার পারচেজ কোড আর সার্ভারের তথ্য পাঠান WhatsApp-এ বা ইমেলে.
সক্রিয় করার কিছু নেই — এটি আপনার নিজের সার্ভারে চলে, বাইরে কিছু জানায় না, আর এই সাইট বন্ধ থাকলেও কাজ করতে থাকে।
এটি কী করে
ইঞ্জিনিয়ারের জন্য নয়, দোকানমালিকের জন্য
আপনি 6amMart কিনেছেন, একটি সার্ভার ভাড়া নিয়েছেন, আর কেউ সেটি ইনস্টল করে দিয়েছে। সাইট খুলছে। প্রস্তুত থাকা কিন্তু সেটি নয়। একটি দোকান ব্রাউজারে একেবারে স্বাভাবিক দেখাতে পারে, অথচ তার পেমেন্ট গেটওয়ের কোনো কার্যকর ক্রেডেনশিয়াল নেই, তার পুশ নোটিফিকেশন কোথাও পৌঁছায় না, তার .env ফাইল ইন্টারনেটে যে কেউ পড়তে পারে, তার নির্ধারিত কাজগুলো একবারও চলেনি, আর তার ডেটাবেস আপনি যত মেমরির টাকা দিচ্ছেন তার সামান্য অংশ ব্যবহার করার জন্য সেট করা। একজন আসল গ্রাহক আসল অর্ডার না করা আর চুপচাপ কিছু ভুল না হওয়া পর্যন্ত এর কোনোটিই ধরা পড়ে না।
সেটি ঘটার আগে যে পরীক্ষাটি আপনি চালান, SixPreflight সেটিই। আপনি সাইটে একটি ফোল্ডার আপলোড করেন, ব্রাউজারে খোলেন, একটি পাসওয়ার্ড দেন, আর একটি বোতাম চাপেন। একজন সতর্ক ইঞ্জিনিয়ার যেভাবে দেখতেন, এটি সার্ভারটিকে সেভাবেই দেখে — হার্ডওয়্যার, PHP, ডেটাবেস সেটিংস, ওয়েব সার্ভার, ফাইল পারমিশন, ইন্টারনেট থেকে কী কী পৌঁছানো যায়, আর সত্যি করে ডাকলে পেমেন্ট, ইমেইল, SMS, ম্যাপ ও পুশ নোটিফিকেশন আদৌ কাজ করে কি না।
তারপর এটি আপনাকে একটি বাক্য দেয় — “চালু করার জন্য প্রস্তুত” বা “অর্ডার নেওয়ার জন্য প্রস্তুত নয়” — একটি লেটার গ্রেড, আর কী কী ঠিক করতে হবে তার একটি সাজানো তালিকা, প্রতিটির সাথে ঠিক কোন লাইন বদলাতে হবে, সেটি কোন ফাইলে আছে, আর সেটি ফেলে রাখলে আপনার দোকানের কী খরচ।
স্ক্যান নিজে কেবল পড়ে। টুলটি যেখানে কাজ করতে পারে, সেখানে সে আপনার চাপা বোতামেই করে, নিজে থেকে কখনো নয়।
এটি থাকলে বনাম না থাকলে
দোকান খোলার আগে আপনি যা জানেন
দুই দিকেই একই সার্ভার। তফাত হলো সমস্যাগুলো আপনি খুঁজে পান, নাকি টাকা দেওয়া একজন গ্রাহক।
যেদিন আপনি খোলেন
SixPreflight ছাড়া
ব্রাউজারে সাইটটি খোলে, তাই আপনি দোকান খুলে দেন। একটি দোকান পুরোপুরি স্বাভাবিক দেখাতে পারে, অথচ তার পেমেন্ট গেটওয়ের কোনো কার্যকর ক্রেডেনশিয়াল নেই, তার পুশ নোটিফিকেশন কোথাও পৌঁছায় না, তার .env ফাইলটি ইন্টারনেটের যে কেউ পড়তে পারে, তার শিডিউল করা কাজগুলো একবারও চলেনি, আর তার ডেটাবেস আপনি যে মেমরির দাম দিচ্ছেন তার একটি ভগ্নাংশ ব্যবহার করতে সেট করা।
SixPreflight দিয়ে
সর্বোচ্চ 163টি চেক শেষ হয় একটি বাক্যে — খোলার জন্য তৈরি, নাকি অর্ডার নেওয়ার জন্য তৈরি নয় — সাথে একটি লেটার গ্রেড আর প্রথমে কী ঠিক করতে হবে তার সাজানো তালিকা।
কিছু ভুল আছে তা আপনি কীভাবে জানেন
SixPreflight ছাড়া
একজন সত্যিকারের গ্রাহক একটি সত্যিকারের অর্ডার দেন আর নীরবে কিছু একটা বিগড়ে যায়। ওটাই আপনার প্রথম সংকেত, আর তার দাম ওই অর্ডার এবং ওই গ্রাহক দুটোই।
SixPreflight দিয়ে
আপনি খোলার আগেই জানেন, নিজে চালানো একটি স্ক্যান থেকে — প্রতিটি আইটেম বলে দেয় ঠিক কোন লাইনটি বদলাতে হবে, সেটি কোন ফাইলে আছে, আর ওটি ফেলে রাখলে আপনার দোকানের কী ক্ষতি।
ক্রেডেনশিয়াল আছে, কিন্তু ভুল
SixPreflight ছাড়া
দেখতে ঠিক কাজ করা ক্রেডেনশিয়ালের মতোই। কনফিগ ফাইলে একটি মান থাকা মানে মানটি আছে, মানটি সঠিক তা নয়।
SixPreflight দিয়ে
সত্যিকারের কল দিয়েই এটি মীমাংসা হয়: একটি আসল Firebase টোকেন বানিয়ে Google-এর টোকেন এন্ডপয়েন্টে পাঠানো, EHLO / STARTTLS / AUTH দিয়ে একটি আসল SMTP কথাবার্তা, আর Google Maps-এ একটি লাইভ জিওকোডিং কল। আছে-কিন্তু-ভুল এখানেই ব্যর্থ হয় — গ্রাহক খুঁজে পাওয়ার আগে এটি ধরার একমাত্র জায়গা এটিই।
ইন্টারনেট এখনই যা পর্যন্ত পৌঁছাতে পারে
SixPreflight ছাড়া
আপনি ধরে নেন যে ফাইলগুলো পাবলিক হওয়া উচিত নয় সেগুলো পাবলিক নয়। সার্ভারের কিছুই আপনাকে উল্টোটা বলে না, কারণ কিছুই ওই রিকোয়েস্টগুলো করছে না।
SixPreflight দিয়ে
এটি আপনার নিজের লাইভ সাইট থেকে পরিচিত ঝুঁকিপূর্ণ ঠিকানার একটি নির্দিষ্ট তালিকা এনে দেখে — /.env, /.git/config, /artisan, ইনস্টলারের database.sql, আর টুলটির নিজের ফাইল — এবং সত্যিই কী ফিরে এল তা জানায়।
এতে কী খরচ
SixPreflight ছাড়া
একজন গ্রাহকের কাছ থেকে এটি জানাই হলো দামি সংস্করণ।
SixPreflight দিয়ে
কিছুই না। SixPreflight CodeCanyon-এ ফ্রি আর প্রথম সেটআপ ফ্রি। প্যাকেজের কিছুই কোনো লাইসেন্স, অ্যাকাউন্ট বা মেয়াদ পরীক্ষা করে না, আর এর কিছুই AllsWeb-কে কিছু জানায় না।
সত্যিকারের সার্ভারে চালানো
নিজেদের মেশিনে চালিয়ে দেখলে এটি কত পেল
যে পরীক্ষক কখনো কোনো ফল প্রকাশ করেনি, সে নিছক একটি দাবি। এই সংখ্যাগুলো SixPanel বেঞ্চমার্কের সেই একই মাপজোখের রাউন্ড থেকে — টুলটি সত্যিকারের দোকান চালানো সত্যিকারের সার্ভারে বসানো, আর শেল থেকে নয়, ব্রাউজার যেভাবে নম্বর দেয় সেভাবেই মাপা।
SixPanel
97 · A
যেসব সারিতে নজর দরকার: কোনোটিই নয়
SixPanel Docker
96 · A
যেসব সারিতে নজর দরকার: কোনোটিই নয়
সীমা-বাঁধা স্কোর ঠিকভাবে পড়ুন
একটিমাত্র সারিও লাল থাকলে স্কোর 88-এ আটকে যায়, বাকি সব যত ভালোই হোক। এটি ইচ্ছাকৃত — যে দোকান বেচাকেনা করতে পারে না, তাকে ভালো নম্বরের মতো দেখানো উচিত নয় — কিন্তু এর মানে হলো সীমা-বাঁধা সংখ্যাটি বাকি নিরানব্বইটি পরীক্ষার ব্যাপারে প্রায় কিছুই বলে না। একই রাউন্ডে আগে একটি সার্ভার 88 আর আরেকটি 96 দেখিয়েছিল, অথচ প্রায় একশোটি পরীক্ষার উপর তাদের ভিতরের স্কোরের ফারাক ছিল 0.03। দৃশ্যমান পুরো ব্যবধানটাই ছিল একটি বাসি ব্যাকগ্রাউন্ড কাজ। সবসময় লাল সারিগুলো পড়ুন, কেবল শিরোনামের সংখ্যাটি নয়।
এই রাউন্ডে টুলটির নিজের ভিতরেই পাওয়া একটি ত্রুটি
SixPreflight-এর নিজের স্ক্যান রানারে কোনো এরর হ্যান্ডলিংই ছিল না। যে সার্ভারে হোস্টিং কোম্পানি কোনো PHP ফাংশন বন্ধ করে রেখেছে, সেখানে PHP 8-এ সেটি ডাকা চাপা দেওয়ার মতো সতর্কবার্তা নয় — সেটি একটি ফেটাল এরর — তাই একটিমাত্র বন্ধ ফাংশনই রিপোর্টের বদলে স্ট্যাক ট্রেস দিয়ে গোটা স্ক্যান শেষ করে দিত। অথচ শেয়ার্ড cPanel ও Plesk হোস্টিংয়েরই এই টুলটি সবচেয়ে বেশি দরকার। এটি সারানো হয়েছে: বন্ধ ফাংশন এখন এমন একটি সারি যেখানে লেখা থাকে সেটি মাপা যায়নি, আর স্ক্যান শেষ পর্যন্ত চলে।
আর একটি জায়গা যেখানে কড়া-সুরক্ষিত সার্ভারে এটি ভুল বলে
যে সার্ভারে PHP কার্নেল স্যান্ডবক্সে আটকানো, সেখানে SixPreflight ওয়েব সার্ভারের কনফিগারেশন পড়তে পারে না — এবং একটি টাইমআউট সেটিংকে অনির্ধারিত বলে জানায়, যদিও ওয়েব সার্ভার সেটি সত্যিই ঠিক করে রেখেছে। প্রমাণের অনুপস্থিতিকে অনুপস্থিতির প্রমাণ ধরে নেওয়া, যাতে কড়া সুরক্ষার জন্যই সার্ভার শাস্তি পায়। এটি এখানে লেখা আছে কারণ যে টুল নিজের অন্ধ জায়গাগুলো জানিয়ে দেয়, সে ওই টুলের চেয়ে বেশি দামি যার কোনো অন্ধ জায়গা নেই বলে দাবি করা হয়।
এটি কীভাবে কাজ করে
ধাপে ধাপে, একটানা দীর্ঘ অপেক্ষা নয়
পেজটি নিজে কোনো পরীক্ষা চালায় না। এটি একটি খালি কাঠামো আঁকে, তারপর ব্রাউজার সার্ভারের কাছে একবারে একটি ধাপ চায়।
প্রথম দেখা সাথে সাথেই
টেস্ট ইনস্টলে মাপা: 2 ms-এ 6.8 KB, অথচ পেজটি রেন্ডারের আগে সব কাজ করলে ছিল 36 KB আর প্রায় 1.6 s। যে সার্ভারের সংজ্ঞাতেই ভুল কনফিগার থাকার সম্ভাবনা আছে, সেখানে কিছু দেখানোর আগে সবচেয়ে ধীর পরীক্ষার জন্য অপেক্ষা করা ভুল সিদ্ধান্ত।
প্রগ্রেস বারটি আসল
মোট ধাপের মধ্যে কতগুলো শেষ হয়েছে, কোনো অ্যানিমেশন নয়। এটি থেমে গেলে সত্যিই কিছু আটকে আছে, আর লেবেলে লেখা থাকে কোন পরীক্ষাটি।
আটকে যাওয়া একটি পরীক্ষা পুরো পেজ ফেলে দিতে পারে না
প্রতিটি ধাপ নিজেই একটি ছোট রিকোয়েস্ট, তাই কিছুই max_execution_time-এ গিয়ে ঠেকে না। যে ধাপ এরর তোলে সেটি একটি ফলাফল হিসেবে জানানো হয় আর স্ক্যান চলতে থাকে। প্রতিটি শেষ হওয়া ধাপ সাথে সাথেই ডিস্কে লেখা হয়, তাই মাঝপথে থেমে যাওয়া স্ক্যানও পড়া যায়।
দুটি বোতাম
এখনই পরীক্ষা
স্থানীয় কনফিগারেশন পড়ে আর সার্ভারের পাবলিক IP খুঁজে দেখে — প্রায় এক সেকেন্ড।
গভীর পরীক্ষা
এতে যোগ হয় সেই দুটি ধাপ যেগুলো সত্যিকারের বাইরের কল করে: আপনার নিজের URL-এর বিপরীতে পাবলিক-এক্সপোজার পরীক্ষা, আর লাইভ ইন্টিগ্রেশন পরীক্ষা।
সৎ কথা: “এখনই পরীক্ষা” পুরোপুরি অফলাইন নয়। পাবলিক-IP সারিটি বাইরের একটি ইকো সার্ভিসকে জিজ্ঞেস করে — ifconfig.me, তারপর api.ipify.org, তারপর icanhazip.com, এই ক্রমে চেষ্টা করা হয় আর স্ক্যানের মাঝে ক্যাশ রাখা হয়, ইচ্ছে করেই তিনটি প্রোভাইডার, যাতে একটির খারাপ এক মিনিট জানা-ভালো উত্তরটিকে মুছে না দেয়।
এটি চলার তিনটি ধরন
SixPreflight বুঝে নেয় সে কী দেখছে, আর সেই অনুযায়ী তার কথা বদলায়, কারণ প্রতিটি ক্ষেত্রে সৎ পরামর্শ আলাদা।
খালি সার্ভারে — এখনও কোনো অ্যাপ্লিকেশন বসানো হয়নি
সার্ভার বাছাই করা বা নতুন সার্ভার প্রস্তুত করার জন্য এটিই ধরন। হার্ডওয়্যার, PHP, ডেটাবেস সার্ভার, ওয়েব সার্ভার, পারমিশন ও পাবলিক এক্সপোজার — সবই তখনও পরীক্ষা হয়। .env ধাপ কিছুই ফেরত দেয় না, অ্যাপ্লিকেশন ধাপ কেবল প্রোফাইল সারিটি ফেরত দেয়, আর ডেটাবেস ধাপ জানায় “পরীক্ষা করা হয়নি — ক্রেডেনশিয়াল রাখার মতো কোনো অ্যাপ্লিকেশন এখানে নেই”, আর সেটিকে পাস ধরা হয়, যাতে ঠিকভাবে খালি একটি মেশিনে অনুপস্থিত সংযোগ সবচেয়ে খারাপ সারি হয়ে না দাঁড়ায়।
চাইলে খালি একটি মেশিনের ডেটাবেসও অডিট করতে পারেন — env_path-কে ক্রেডেনশিয়াল রাখা একটি স্টাব .env-এর দিকে দেখিয়ে দিন।
আপনার দোকানের ভেতরে — 6amMart অ্যাডমিন কোডবেসে
ফোল্ডারটি public/-এ আপলোড করুন, অর্থাৎ যে ডিরেক্টরি আপনার ওয়েব সার্ভার সত্যিই পরিবেশন করে। টুলের নিজের ফোল্ডার থেকে উপরে উঠে, সর্বোচ্চ পাঁচ স্তর পর্যন্ত, যে ডিরেক্টরিতে artisan আছে সেটিকেই অ্যাপ্লিকেশন রুট ধরা হয় — তাই public/preflight/ আর অ্যাপ্লিকেশন রুটের একটি ফোল্ডার দুটিই কাজ করে, আর পাঁচ স্তরের চেয়ে গভীরে রাখা আপলোড চুপচাপ স্ট্যান্ডঅ্যালোন ধরন পায়। সঠিক জায়গা public/ — অ্যাপ্লিকেশন রুটের একটি ফোল্ডারে URL দিয়ে পৌঁছানো যায় কেবল তখনই যখন ডকুমেন্ট রুট ভুল, আর এই টুল যা যা খোঁজে তার মধ্যে সেটিই সবচেয়ে গুরুতর।
এখানে প্রতিটি পরীক্ষা চলে, 6amMart কোডবেস থেকে বিশেষভাবে লেখাগুলোও: যে শিডিউলার স্টোর ও রাইডারদের টাকা দেয়, যেসব মডিউল চালু বলে চিহ্নিত অথচ নেই, তার ভেন্ডর প্যাকেজগুলোর জন্য ঠিক যেসব PHP এক্সটেনশন লাগে, আর লাইভ ডেলিভারি ট্র্যাকিংয়ের পেছনের ওয়েবসকেট স্তর। অন্য যেকোনো Laravel অ্যাপ্লিকেশনে সার্ভার সম্পর্কিত সবকিছু হুবহু একইভাবে খাটে, আর 6amMart-নির্দিষ্ট পরীক্ষাগুলো আন্দাজ না করে বাদ দেওয়া হয়।
SixPanel-এর ভেতরে বসানো
একটি SixPanel সার্ভারে ওয়েব সার্ভার, PHP, ডেটাবেস কনফিগারেশন, cron, কিউ ওয়ার্কার ও সার্টিফিকেটের মালিক প্যানেল নিজেই, আর প্রতিটি ডিপ্লয়ে সে নিজের টেমপ্লেট থেকে ওই ফাইলগুলো আবার লেখে — তাই হাতে পেস্ট করা কোনো মান পরের ডিপ্লয়ে চুপচাপ হারিয়ে যায়। ওই ধরনে SixPreflight পেস্ট ব্লক, কাঁচা nginx ও Apache ব্লক, php-fpm রিস্টার্টের লাইন আর “হোস্টিং প্যানেলে কোথায় ক্লিক করবেন” পথগুলো বাদ দেয়, আর তার বদলে প্রতিটি সেটিংয়ের মালিক SixPanel পেজটির দিকে দেখায়। অ্যাপ্লিকেশন সম্পর্কিত সবকিছু সে রাখে — .env, ব্যবসায়িক সেটিংস, অনুপস্থিত বা ভুল কি, ভুল APP_URL, ভাঙা স্টোরেজ, লগে থাকা এরর — কারণ এই অর্ধেকটাই প্যানেল নিজে ঠিক করতে পারে না। এটি কোন ধরনে আছে তা পেজের উপরে এক লাইনে বলে দেয়, তাই ধরনটি কখনো রহস্য থাকে না।
যে সার্ভার ব্লক এই পথের উত্তর দেয় তার সেট করা একটি এনভায়রনমেন্ট ভেরিয়েবল (SIXPANEL_EMBED=1), কিংবা config.php-তে 'embedded' => true দিয়ে ধরনটি ঠিক হয়। একটি রিকোয়েস্ট হেডারকে ইচ্ছে করেই প্রধান সংকেত করা হয়নি: হেডার লেখেন যিনি রিকোয়েস্ট করেন, তাই সেটি কেবল প্যানেলের ফ্রেমেই টিকত আর অন্য কোথাও নয় — একই পেজ নতুন ট্যাবে খুললেই টুলটি একই সার্ভারে স্ট্যান্ডঅ্যালোন পরামর্শে ফিরে যেত। X-SixPanel-Embed: 1 কেবল তখনই মানা হয় যখন আপনি 'trust_embed_header' চালু করেন, যা ডিফল্টে বন্ধ, কারণ খোলা রাখলে যেকোনো দর্শক নিজেকে ম্যানেজড-সার্ভারের দৃশ্যটি দিয়ে দিতে পারতেন — এমন সার্ভারে, যা আসলে তাঁরই ঠিক করার কথা।
এটি কী কী পরীক্ষা করে
163টি আলাদা পরীক্ষা, দশটি ধাপে
কোডে 163টি আলাদা পরীক্ষা আছে, যেগুলো দশটি ধাপে চলে, সবচেয়ে সস্তা আর সবচেয়ে ভাঙার সম্ভাবনা আগে রেখে সাজানো। বাইরের কল করে এমন দুটি ধাপ ধীর হিসেবে চিহ্নিত আর কেবল গভীর পরীক্ষায় চলে।
| ধাপ | এটি কী দেখে | পরীক্ষা | বাস্তব উদাহরণ |
|---|---|---|---|
| সিস্টেম ও হার্ডওয়্যার | যে মেশিনের টাকা আপনি দিচ্ছেন | 7 | vCPU সংখ্যা, RAM, swap, ফাঁকা ডিস্ক, লোড অ্যাভারেজ, OS রিলিজ, আদৌ কোনো ব্যাকআপ টুল আছে কি না |
| PHP রানটাইম | যে ভাষায় দোকান চলে | 18 | PHP সংস্করণের ব্যান্ড, 25টি প্রয়োজনীয় এক্সটেনশন, memory_limit, কার্যকর max_execution_time, display_errors, OPcache চালু/বন্ধ, OPcache মেমরি ও ফাইল সংখ্যা, হিট রেট |
| অ্যাপ্লিকেশনের স্বাস্থ্য | Laravel আর 6amMart নিজেই | 22 | .env git-এ ট্র্যাক হচ্ছে কি না, বাকি থাকা মাইগ্রেশন, ব্যর্থ জব, কিউয়ের জট, লগের আকার, লগে এররের সংখ্যা, শিডিউলার কখনো চলেছে কি না, মডিউল তালিকা বৈধ কি না, ট্রাস্টেড প্রক্সি, ইনস্টল সেটিংস আছে কি না |
| এনভায়রনমেন্ট (.env) | যে একটি ফাইল সবাই পড়ে | 14 | একই কি দুবার (শেষেরটিই টেকে, তাই আপনার সম্পাদনা কিছুই করে না), অদৃশ্য \r অক্ষর, অবৈধ বা প্যাকেজের সাথে আসা APP_KEY, APP_DEBUG=true, ভুল গড়নের APP_URL, যেসব কি কেউ পড়ে না, যেসব কি কনফিগ ক্যাশ হলে null হয়ে যায় |
| হোস্ট পরিচয় ও পারমিশন | ফাইলগুলোর মালিক কে | 9 | পাবলিক IPv4 ও IPv6, PHP ইউজার, ফাইলের মালিকানা, যে ছয়টি ডিরেক্টরিতে লেখা যেতে হবে, সবার লেখার মতো ফাইল, সবার পড়ার মতো .env, public/-এর ভেতরে লেখা ও চালানো যায় এমন কিছু |
| ওয়েব সার্ভার | সামনে থাকা nginx বা Apache | 17 | হ্যান্ডলারের ধরন, gzip, সার্ভার টোকেন, FastCGI read timeout, Apache মডিউল ও MPM, মেমরির তুলনায় php-fpm ওয়ার্কার সংখ্যা, আপলোড সাইজের শৃঙ্খল, লাইভ কমপ্রেশন, স্ট্যাটিক ক্যাশিং, HSTS, সার্টিফিকেটের মেয়াদ |
| ক্যাশ, কিউ ও রিয়েলটাইম | ব্যাকগ্রাউন্ডের কাজ | 11 | কিউ সংযোগ, কিউ ওয়ার্কার আদৌ চলছে ও তদারকিতে আছে কি না, সেশন ও ক্যাশ ড্রাইভার, Redis, Memcached, Reverb ক্রেডেনশিয়াল ও স্কিম, Pusher ক্রেডেনশিয়াল |
| ডেটাবেস কনফিগারেশন | যেখানে টাকা থাকে | 32 | আপনার আসল ডেটা ও RAM অনুযায়ী InnoDB বাফার পুলের মাপ, redo লগ, ফ্লাশ পদ্ধতি, php-fpm ওয়ার্কারের তুলনায় max_connections, skip_name_resolve, sql_mode, charset, PHP-বনাম-ডেটাবেস ঘড়ির পার্থক্য, বাফার-পুল হিট রেট, ডিস্কে টেম্প টেবিল, ডেটাবেস ইউজারের অধিকার |
| পাবলিক এক্সপোজারধীর | একজন অচেনা মানুষ কী কী আনতে পারে | 12 | HTTPS, ওয়েবে .env পড়া যায় কি না, .git/config পড়া যায় কি না, laravel.log পরিবেশিত হচ্ছে কি না, আপলোড করা একটি .php ফাইল সত্যিই চলছে কি না, Debugbar বা Telescope উত্তর দিচ্ছে কি না, ইনস্টলারের ডেটাবেস ডাম্প রয়ে গেছে কি না, এই টুলের নিজের ফাইল টেক্সট হিসেবে পরিবেশিত হচ্ছে কি না |
| পেমেন্ট, ইমেইল ও SMSধীর | যেসব সার্ভিস কাজ করতেই হবে | 21 | সত্যিকারের একটি SMTP কথোপকথন, সত্যিকারের একটি Firebase টোকেন তৈরি, Google Maps-এ সত্যিকারের একটি জিওকোড কল, পেমেন্ট মেথড ব্যবহারযোগ্য কি না, SMS গেটওয়ে ক্রেডেনশিয়াল, স্টোরেজ ডিস্কে লেখা যায় কি না, মেইনটেন্যান্স মোড, reCAPTCHA, টাইমজোন, মুদ্রা |
কলামটি যোগ করলে হয় 163। দুটি সারির সাথে একটি শর্ত আছে।
- 32টি ডেটাবেস পরীক্ষার একটি — db_standalone — কেবল সেই ক্ষেত্রের জন্যই আছে যেখানে ক্রেডেনশিয়াল রাখার মতো কোনো অ্যাপ্লিকেশন নেই। এটি বাকি 31টির সাথে যোগ না হয়ে তাদের জায়গায় দাঁড়ায়।
- 21টি পেমেন্ট/ইমেইল/SMS পরীক্ষার দুটি হলো প্রিফিক্স ভিত্তি (sms_, social_), যেগুলো চলার সময় প্রতিটি সক্রিয় গেটওয়ে বা কনফিগার করা সোশ্যাল লগইন পিছু একটি করে সারিতে ছড়িয়ে পড়ে। তাই ব্যস্ত দোকানে ওই ধাপ 21টির বেশি সারি দিতে পারে, আর খালি দোকানে কম।
কোনো একটি রানই 163টি সবগুলো চালায় না — আর এখানে ঠিক কেন
বসানো একটি দোকান সর্বোচ্চ 162টি আলাদা সারি দিতে পারে — আর কোনো একটি রানই 162টির সবগুলো দেয় না
db_standalone কেবল তখনই আসে যখন কোনো অ্যাপ্লিকেশন নেই, তাই বসানো দোকান সেটি কখনো দেখে না; সেটিই 163তম। 162 একটি ছাদ, কোনো রান নয়।
বসানো দোকানে একটি গভীর পরীক্ষা 160টি দেয়
গভীর ধাপটি পরে আসবে জানা থাকলে ওয়েব-সার্ভার ক্লাস তার দুটি কনফিগ-পড়া যমজ চেপে রাখে — nginx-এর gzip ও server_tokens, কিংবা Apache-এর keepalive ও server_tokens — কারণ লাইভ মাপ একই প্রশ্নের উত্তর আসল রেসপন্স থেকে দেয়, আর দুটি একে অন্যের সাথে অমিল হতে পারে (gzip on; কিন্তু gzip_types তালিকায় application/json নেই — কনফিগ অনুযায়ী পাস, মাপ অনুযায়ী সতর্কতা, একই সেটিং নিয়ে)। ওই যমজেরা 162-এর ভেতরেই আছে; এ কারণেই গভীর পরীক্ষা 162 নয়, 160-এ দাঁড়ায়, এগুলো উপরে বাড়তি কোনো জোড়া নয়।
একটি “এখনই পরীক্ষা” 123টি দেয় — এটি 39টি বাদ দেয়
ওই 39টি হলো 12টি পাবলিক-এক্সপোজার পরীক্ষা, 21টি পেমেন্ট/ইমেইল/SMS পরীক্ষা, আর ওয়েব-সার্ভারের সেই ছয়টি সারি যেগুলো কেবল লাইভ রেসপন্স থেকেই পড়া যায় — compression, static_cache, keepalive_live, server_banner, hsts আর cert_expiry। কনফিগ-পড়া যমজ দুটি এই রানে থাকে, কারণ যে লাইভ মাপ তাদের জায়গা নিত সেটি আসছে না।
ওই দুটি সংখ্যাই আলাদা কি গোনে, আর আসল সার্ভারে সংখ্যা আরও কম হয় — কম দিকটাই ধরুন
17টি ওয়েব-সার্ভার কি-র তিনটি আপনি যে ওয়েব সার্ভার চালাচ্ছেন না তার (nginx দেয় client_max_body_size, gzip ও fastcgi_read_timeout; Apache দেয় apache_modules, apache_mpm ও keepalive), আর ডেটাবেস ধাপে ইঞ্জিন-নির্ভর জোড়া আছে — MySQL 8.0.30+ জানায় innodb_redo_log_capacity, বাকি সব জানায় innodb_log_file_size, কখনোই দুটি একসাথে নয়। শুধু ওয়েব-সার্ভারের ভাগটি ধরলেই একটি nginx বা Apache ইনস্টলে গভীর পরীক্ষা সর্বোচ্চ 157টি সারি দেয়, আর “এখনই পরীক্ষা” সর্বোচ্চ 120টি; প্রতিটি ইঞ্জিন-নির্ভর ডেটাবেস সারি সংখ্যাটিকে আরও নামায়।
খালি সার্ভারে 40টি সারির পড়ার মতো কিছুই থাকে না
14টি .env পরীক্ষা, 12টি Laravel অ্যাপ্লিকেশন পরীক্ষা, 9টি 6amMart প্ল্যাটফর্ম পরীক্ষা আর 5টি রিয়েলটাইম পরীক্ষার পড়ার মতো কিছুই থাকে না — 40টি সারি, আর অ্যাপ্লিকেশন ধাপ থেকে কেবল প্রোফাইল সারিটিই বাকি থাকে।
তাই সৎ রূপটি হলো “163টি পর্যন্ত” — আর একটি 6amMart ইনস্টলে গভীর পরীক্ষা তার নাগালের পুরো সেটটিই চালায়, অর্থাৎ 160টি আলাদা কি, আর একটিমাত্র ওয়েব সার্ভার চালানো আসল মেশিনে সর্বোচ্চ 157টি সারি।
ধীর দুটি ধাপের কোনোটিই আন্দাজ নয়
এক্সপোজার ধাপ আপনার আসল সাইট থেকে আসল ঠিকানা আনে
এটি আপনার নিজের লাইভ সাইট থেকে পরিচিত ঝুঁকিপূর্ণ ঠিকানার একটি নির্দিষ্ট তালিকা আনার চেষ্টা করে — /.env, /.git/config, /storage/logs/laravel.log, /artisan, /composer.json, /vendor/autoload.php, ইনস্টলারের database.sql ও public.zip, /telescope, /_debugbar/open, স্টোর-সাইনআপ রুট, আর এই টুলের নিজের ফাইল — আর সত্যিই কী ফিরে এল তা জানায়।
সার্ভিস ধাপ সত্যিকারের কল করে
এটি একটি সত্যিকারের JWT তৈরি করে Google-এর টোকেন এন্ডপয়েন্টে পাঠায়, যাতে আপনার Firebase সার্ভিস অ্যাকাউন্ট কাজ করে তা প্রমাণ হয়; EHLO / STARTTLS / AUTH দিয়ে সত্যিকারের একটি SMTP কথোপকথন খোলে; আর Google Maps-এ একটি লাইভ জিওকোডিং কল করে। যে ক্রেডেনশিয়াল আছে কিন্তু ভুল, সেটি এখানেই ব্যর্থ হয়, আর গ্রাহকের চোখে পড়ার আগে এটিই তা ধরার একমাত্র জায়গা।
SMTP প্রোব অথেনটিকেশনেই থেমে যায়। এটি EHLO পাঠায়, STARTTLS ঠিক করে, অথেনটিকেট করে, তারপর QUIT করে — ওই ক্লাসে কোনো MAIL FROM নেই, কোনো RCPT TO নেই, কোনো DATA নেই, তাই কারও কাছেই কিছু পৌঁছায় না।
আরও দুটি পেজ, যা 163-এর অংশ নয়
দুটিই আসল প্রোডাক্ট সারফেস, আর কোনোটিই স্কোরে যোগ হয় না।
লাইভ ডেলিভারি ট্র্যাকিং — 15টি পরীক্ষা
এর নিজের পেজ, যা ঢাকে Reverb প্রসেস, প্রসেস ম্যানেজার, লিসেনিং সকেট, ফায়ারওয়াল, প্রক্সি, সার্টিফিকেট, ক্রেডেনশিয়াল, অ্যাপ কি, অ্যাপ সেটিংস, চ্যানেল অথ, ক্লায়েন্ট টার্গেট, কনফিগ ক্যাশ, কিউ, CDN ও ড্রাইভার। একজন 6amMart ক্রেতার কাছে এটিই লাইভ ম্যাপের পেছনের ফিচার, আর একে সার্ভার স্কোরে না মিশিয়ে আলাদাভাবে পরীক্ষা করা হয়।
টেস্ট অর্ডার অ্যালার্ট
হাতে বানানো পেলোড নয়, প্ল্যাটফর্মের নিজের artisan কমান্ড দিয়ে একটি আসল স্টোর বা রাইডার ডিভাইসে সত্যিকারের একটি পুশ নোটিফিকেশন পাঠায়। “কী পাঠানো হতো দেখান” নামে একটি বোতাম আছে যা শুকনো চালায়, কিন্তু ডিফল্ট বোতামটি সত্যিই পাঠায়।
এটি কীভাবে স্কোর দেয়
একটি সংখ্যা — আর সে বলে দেয় কী কী মাপতে পারেনি
প্রতিটি পরীক্ষা চারটির একটিতে শেষ হয়: পাস, সতর্কতা, সমস্যা, বা মাপা যায়নি।
সংখ্যাটি একটি ওয়েটেড গড়, গণনা নয়। ওয়েট তালিকা 200 থেকে নেমে 11 পর্যন্ত যায়, আর তা ঠিক হয় ভুল হলে আপনার কত খরচ তার উপর — APP_DEBUG=true বসে 200-এ, OS নামের সারিটি 12-এ, আর app_profile ও public_ipv6 বসে 11-এ। ওই তালিকায় নেই এমন যেকোনো কি ডিফল্ট 10-এ নামে, আর একটি লাইভ স্ক্যান কি ঠিক তা-ই করে: db_standalone, যা সত্যিই ক্রমহীন আর টুলের নিজের ড্রিফট রিপোর্টে দেখা যায়। পাস তার পুরো ওয়েট পায়, সতর্কতা অর্ধেক, আর সমস্যা কিছুই পায় না।
| স্কোর | গ্রেড | এর মানে কী |
|---|---|---|
| 90 ও তার বেশি | A | প্রোডাকশনের জন্য প্রস্তুত |
| 75–89 | B | ভালো। হলুদ বিষয়গুলো মিটিয়ে আবার পরীক্ষা করুন |
| 55–74 | C | চলবে, তবে সত্যিকারের পারফরম্যান্স হাতছাড়া হচ্ছে |
| 35–54 | D | প্রস্তুত নয়। কয়েকটি সেটিং চাপের মুখে ভোগাবে |
| 35-এর নিচে | F | এই কনফিগারেশনে লাইভে যাবেন না |
ব্লকার গ্রেড আটকে দেয়
কিছু ব্যর্থতা “পয়েন্ট কাটা” নয় — সেগুলোর মানে দোকান বেচাকেনাই করতে পারবে না। একটি ব্লকার স্কোর 74-এ আটকে দেয়, দুটি 54-এ, তিন বা তার বেশি 34-এ; অর্থাৎ ব্লকার গ্রেড ব্যান্ডকে নিচে নামিয়ে দেয় আর ওয়েটেড গড় কেবল ঠিক করে আপনি ওই ব্যান্ডের কোথায় দাঁড়াবেন। একটিও ব্লকার না থাকলেও একটি লাল সারিই স্কোর 88-এ আটকে দেয় — পেজে কোনো লাল থাকলে A পাওয়া যায় না।
ব্লকার তালিকা ছোট ও নির্দিষ্ট, আর সেটি ঠিক উনিশটি নামধরা কি, সাথে sms_ দিয়ে শুরু হওয়া যেকোনো কিছু: ওয়েবে .env পড়া যাওয়া, ওয়েবে লগ পরিবেশিত হওয়া, সাইট মেইনটেন্যান্স মোডে থাকা, আপলোড করা একটি .php ফাইল চলা, নতুন স্টোর নিবন্ধন করতে না পারা, ব্যবহারযোগ্য কোনো পেমেন্ট মেথড না থাকা, ডেটাবেসে পৌঁছানো না যাওয়া, স্টোরেজ ভুলভাবে সেট করা, মেইল ব্যর্থ হওয়া, SMS ব্যর্থ হওয়া, এমন একটি sql_mode যাতে প্ল্যাটফর্ম ভেঙে পড়ে, ভুল charset, শিডিউলার না চলা, 14 দিনের মধ্যে সার্টিফিকেটের মেয়াদ শেষ হওয়া, আর .env-এর আরও পাঁচটি ত্রুটি — অনুপস্থিত বা প্যাকেজের সাথে আসা APP_KEY, APP_DEBUG=true, ভাঙা ডেটাবেস ব্লক, ভাঙা মেইল ব্লক, আর একই কি দুবার।
লক্ষ করুন কোনটিকে ইচ্ছে করেই ব্লকার করা হয়নি: ডকুমেন্ট রুটের উপরের ফাইল পড়া যাওয়াকে ব্লকার নয়, সতর্কতা ধরা হয়েছে, কারণ সেটি ফাঁস, ভাঙন নয়। তালিকাটি ইচ্ছে করেই ছোট — সবকিছুই জরুরি হলে কিছুই জরুরি থাকে না।
একটি পরিণাম সোজা করে বলা দরকার: cert_expiry এমন একটি ব্লকার যা কেবল গভীর পরীক্ষাতেই মাপা হয়, কারণ এটি একটি লাইভ TLS হ্যান্ডশেক থেকে পড়া হয়। “এখনই পরীক্ষা” আপনাকে বলতে পারে না যে আগামী সপ্তাহে আপনার সার্টিফিকেটের মেয়াদ শেষ।
“মাপা যায়নি” কেন কখনো গ্রেড পায় না — আর সেটি কেন গুরুত্বপূর্ণ
যে পরীক্ষা টুলটি চালাতে পারেনি, সেটি স্কোরের একেবারে বাইরে রাখা হয়।
সংখ্যাটি নিয়ে বোঝার মতো সবচেয়ে জরুরি কথা এটিই। একটি ম্যানেজড প্যানেলে PHP সাইটের নিজের ডিরেক্টরিতেই আটকানো থাকে — যা ঠিক আছে আর রেখে দেওয়ারই মতো — আর তার মানে /proc, /etc/os-release, nginx কনফিগ আর php-fpm পুল কনফিগ একেবারেই পড়া যায় না। তখন সাতটি পরীক্ষার দেওয়ার মতো কোনো উত্তরই থাকে না।
যে টুল সেগুলোকে ব্যর্থতা হিসেবে স্কোর করত, সে আপনাকে এমন একটি নিরাপত্তা ব্যবস্থার জন্য শাস্তি দিত যা আপনার রেখে দেওয়াই উচিত। যে টুল সেগুলোকে পাস ধরত, সে মিথ্যে বলত। SixPreflight কোনোটিই করে না: ওই সারিগুলোতে লেখা থাকে “এখান থেকে পড়া যায় না”, PHP অংশের একটি সারি একবারই কারণটি বুঝিয়ে দেয় আর দুই দিক থেকেই এড়ানোর উপায় বলে, আর এগুলোর কোনোটিই স্কোর ছোঁয় না।
ব্যাকআপ পরীক্ষার ক্ষেত্রেও একই নিয়ম। কোনো ব্যাকআপ টুল না পাওয়া গেলে সারিটি সতর্কতা নয়, মাপা-যায়নি হয় — কারণ আপনার হোস্টিং প্রোভাইডারের স্ন্যাপশট সার্ভারের ভেতর থেকে দেখা যায় না, আর টুলটি যা দেখতেই পায় না তাকে ভাঙা বলতে অস্বীকার করে।
একটি কড়াভাবে বন্ধ করা সার্ভার বন্ধ করার জন্য খারাপ স্কোর পাবে না। নিয়মটি এই, আর এ কারণেই সংখ্যাটি পড়ার মতো।
ফিক্স তালিকা
প্রতিটি সতর্কতা ও প্রতিটি সমস্যা What to fix পেজে আসে, আগে লালগুলো, তারপর ওয়েটের ক্রমে। প্রতিটির সাথে একটি প্রভাবের লেবেল থাকে, যা স্কোর তৈরি করা সেই একই ওয়েট থেকেই আসে, তাই এক মাপকাঠিতে গ্রেড দিয়ে অন্য মাপকাঠিতে অগ্রাধিকার দেওয়া হয় না।
- অর্ডার বন্ধ করে
- অর্ডার বন্ধ করতে পারে
- গুরুতর ঝুঁকি
- ঝুঁকি
- সাইট ধীর করে
- ঠিক করার মতো
- গুছিয়ে নেওয়ার মতো
প্রতিটি কার্ড বলে দেয় সেটিংটি এখন কী, কী হওয়া উচিত, কোন ফাইলে আছে, চালানোর মতো কমান্ড থাকলে সেটি কী, আর পরিবর্তনটি হয়েছে কি না তা কীভাবে প্রমাণ করবেন। প্রতিটি গন্তব্য ফাইলের জন্য “সব লাইন একসাথে দেখান” নামে একটি ব্লক আছে, যাতে কেবল সেই লাইনগুলোই থাকে যেগুলো এখনও বদলানো বাকি — কারণ বিশটি মান একটি একটি করে কপি করতে গিয়েই একটি সংখ্যা পড়ে যায়। পেস্ট করার সেটিংস আর চালানোর কমান্ড আলাদা ব্লকে রাখা হয়; সেগুলো আলাদা জায়গায় যায়।
কার্ডের ডেটাবেস লক্ষ্যমাত্রাগুলো সেই একই হিসাব থেকে আসে যা আপনি কপি করা my.cnf ব্লকটি তৈরি করে, তাই প্রতি-সারির সংখ্যা আর ব্লকটির মধ্যে কখনো অমিল হতে পারে না।
এটি মনেও রাখে
টুলটি শেষ 60টি স্ক্যান ডিস্কে রাখে। ইতিহাস পেজে একটি “গত স্ক্যানের পর থেকে” কার্ড দেখা যায় — নতুন করে কী ভাঙল আর নতুন করে কী ঠিক হলো — আপনি সংরক্ষিত যেকোনো দুটি পরীক্ষা পাশাপাশি মেলাতে পারেন, আর একটি রান টেক্সট ফাইল হিসেবে রপ্তানি করতে পারেন।
শুধু-পড়ার একটি ?api=findings এন্ডপয়েন্ট শেষ সংরক্ষিত পরীক্ষাটি JSON হিসেবে ফেরত দেয়, ড্যাশবোর্ড বা মনিটরের জন্য। এটি কখনো স্ক্যান শুরু করে না: যে মনিটর প্রতিবার ড্যাশবোর্ড রিফ্রেশে একটি পুরো স্ক্যান চালাত — যার একটি ধাপ আপনার লাইভ সাইট থেকে URL আনে — সেটি মনিটরের পোশাক পরা একটি লোড জেনারেটর হতো। রেসপন্সে run.age_seconds থাকে, যাতে ডাকা পক্ষ পুরোনো খবরকে চলতি বলে না চালিয়ে বলতে পারে “এটি দুই সপ্তাহের পুরোনো”।
অন্য অর্ধেক
এর দ্বিতীয় একটি অর্ধেকও আছে: সেটআপ স্ক্রিপ্ট
SixPreflight পড়ে আর বুঝিয়ে দেয়। bin/setup-6ammart.php প্যাকেজের অন্য অর্ধেক: এটি পরিবর্তনগুলো করে। শিপ করা ডকুমেন্টেশন পেজে এটি এক লাইনে লেখা — “SixPreflight একটি সার্ভার পড়ে আর কী বদলাতে হবে বুঝিয়ে দেয়। setup-6ammart.php অন্য অর্ধেক: এটি সেই পরিবর্তনগুলো করে।”
ইচ্ছে করেই .php এক্সটেনশন দেওয়া একটি bash স্ক্রিপ্ট
PHP ফাইলটি নেয়, 3 নম্বর লাইনে একটি exit-এ গিয়ে ঠেকে, আর ব্রাউজারকে কিছুই দেয় না। এটি bash দিয়ে চালান, ব্রাউজার দিয়ে কখনো নয়।
ডিফল্ট ধরনটি শুকনো রান
ভুল করে চালালে কিছুই বদলায় না। --check চলতি বনাম প্রস্তাবিত অবস্থা জানায়। --apply কাজটি করে।
84টি ক্যাটালগ এন্ট্রি, তার 40টি না জিজ্ঞেস করেই প্রয়োগ করা নিরাপদ
এর সত্যের উৎস সেই একই টিউনিং ক্যাটালগ, যা ফিক্স কার্ডগুলো ব্যবহার করে — php, php-fpm, os, mysql, nginx, laravel ও 6ammart জুড়ে 84টি এন্ট্রি, যার 40টি না জিজ্ঞেস করেই প্রয়োগ করা নিরাপদ বলে চিহ্নিত, আর 44টির ক্ষেত্রে এক লাইনে সুবিধা-অসুবিধা জানিয়ে জিজ্ঞেস করা হয়, নয়তো হাতে করার নির্দেশ হিসেবে ছাপা হয়। দ্বিতীয় দলের কোনো এন্ট্রিই চুপচাপ প্রয়োগ হয় না, --yes দিলেও নয়।
গণনায় অমিল, খোলাখুলি বলা
শিপ করা docs/setup.html পেজে লেখা 84টি এন্ট্রি, 40টি স্বয়ংক্রিয় করা নিরাপদ, 44টি নয়। স্ক্রিপ্টের নিজের হেডার আর তিনটি data/tuning-*.json.php ফাইল সরাসরি গুনলে দুটিতেই আসে 86 / 41 / 45। উপরে প্রকাশিত কম সংখ্যাটিই ব্যবহার করা হয়েছে।
একটি চালু nginx vhost-এ লেখা, শিডিউলারের cron, আর জট জমা অবস্থায় কিউ ওয়ার্কার চালু করে এমন যেকোনো কিছু — সবই জিজ্ঞেস-করা দলে পড়ে: প্রতিটি ঠিক কী করতে যাচ্ছে তা দেখিয়ে জিজ্ঞেস করে, আর --yes তাদের হয়ে উত্তর দেয় না।
তাই SixPreflight একটি পরীক্ষক, যার পাশে ঐচ্ছিক একটি সংশোধক আছে, কেবল পরীক্ষক নয়।
এর সাথে চারটি গাইড আসে
ডকুমেন্টেশনের সেটে সংশোধকটিকে এক-চতুর্থাংশ পেজ দেওয়া হয়েছে।
এটি কীভাবে ব্যবহার করবেন
index.html — ড্যাশবোর্ড, দুটি স্ক্যান বোতাম, ফিক্স তালিকা আর ইতিহাস পেজ।
কী কী বসাতে হবে, আর প্রতিটি ক্রেডেনশিয়াল কোথা থেকে আসে
requirements.html — প্যাকেজ, এক্সটেনশন, আর প্রতিটি কি কোন কনসোল থেকে দেওয়া হয়।
কোন PHP, ডেটাবেস ও OS
versions.html — সুপারিশ, ক্রম অনুযায়ী স্কোরকার্ড, আর প্রতিটি বাছাইয়ের পেছনের কারণ।
সেটআপ স্ক্রিপ্ট কী করে
setup.html — ক্যাটালগ, কোন এন্ট্রিগুলো স্বয়ংক্রিয় হয়, আর কোনগুলো থেমে জিজ্ঞেস করে।
আন্দাজের চেয়ে এটি কেন ভালো
চারটি জিনিস, যা চোখে দেখে পরীক্ষা করা যায় না
আপনার নিজের বিচারের বিপরীতে
ভেন্ডরের পূর্বশর্ত পেজে সর্বনিম্ন মানগুলো লেখা থাকে, আর সর্বনিম্ন মানের উপর কিছু বানানো ভুল। “MySQL 5.7+ / MariaDB 10.3+” আড়াল করে যে দুটি ধারা ONLY_FULL_GROUP_BY-এর নিচে আলাদা আচরণ করে: MySQL 5.7.5+ এটি ডিফল্টে চালু রাখে আর সামলে নেয়, কারণ এই রিপোর্টগুলো যে কার্যকরী নির্ভরতার উপর দাঁড়ায় সেটি সে বের করে নিতে পারে; MariaDB এটি বন্ধ রাখে, আর চালু করলে ভেঙে পড়ে — তখন আইটেম-ভিত্তিক রিপোর্ট ERROR 1055 দিয়ে ব্যর্থ হয়। এটি ধরে নেওয়া হয়নি, দুটিতেই রিপোর্ট চালিয়ে যাচাই করা হয়েছে। তাই MariaDB-তে মোডটি বন্ধই থাকতে হবে, আর MySQL-এ ডিফল্ট যেমন আছে তেমনই রাখা উচিত। টুলটি ওই নির্দিষ্ট সংমিশ্রণটিকেই গ্রেড দেয়, সংস্করণ নম্বরকে নয়।
একটি phpinfo() পেজের বিপরীতে
phpinfo() মান ছাপে, তার বেশি কিছু নয়। আপনার আসল max_execution_time হলো php.ini আর php-fpm-এর request_terminate_timeout-এর মধ্যে ছোটটি; SixPreflight ওই কার্যকর সংখ্যাটি বের করে এবং গ্রেড দেয়। phpinfo() আপনার আসল RAM, আসল php-fpm ওয়ার্কার সংখ্যা ও আসল ডেটার আকার থেকে InnoDB বাফার পুলের মাপ ঠিক করতে পারে না — SixPreflight পারে, আর তারপর দেখে php-fpm-এর ওয়ার্কারগুলো আদৌ max_connections-এর ভেতরে আঁটে কি না। এটি আপনার প্রকল্পে কতগুলো PHP ফাইল আছে তা থেকে OPcache-এর ফাইল-সংখ্যার লক্ষ্যমাত্রাও বের করতে পারে না। আর ইন্টারনেট থেকে আপনার সাইটের কী কী আনা যায় তা-ও বলতে পারে না, কারণ সে কোনো রিকোয়েস্ট করছে না।
আপনার হোস্টিং কোম্পানির কথার বিপরীতে
“সার্ভার ঠিকই আছে” এমন দাবি কেউ যাচাই করতে পারে না। এটি পারে: এটি আপনার নিজের লাইভ URL থেকে /.env আনার চেষ্টা করে আর কী ফিরে এল তা বলে দেয়। এটি একটি সত্যিকারের SMTP সেশন খোলে। এটি একটি সত্যিকারের Firebase টোকেন তৈরি করে। এটি একটি সত্যিকারের Maps কল করে। এর প্রতিটিই সময়সহ একটি তথ্য, একটি ফাইলে সংরক্ষিত, যা আপনি রপ্তানি করে যিনি বলেছিলেন সব ঠিক আছে তাঁকে পাঠাতে পারেন।
আর সে না জানলে সেটাও বলে
যে টুলের সবসময়ই উত্তর থাকে, সে কোথাও না কোথাও আন্দাজ করছে। এটি যেসব সারি মাপতে পারেনি তাদের নাম বলে আর স্কোর থেকে বাদ দেয়।
আগে থেকেই SixPanel-এ আছেন?
আগে থেকেই SixPanel-এ আছেন? এটি আপনার কাছে আগে থেকেই আছে
cPanel, aaPanel, CloudPanel বা খালি VPS-এ থাকলে SixPreflight আপনার জন্য
ওয়েব সার্ভার, PHP, ডেটাবেস কনফিগ, cron ও সার্টিফিকেটের মালিক আপনি, তাই প্রতিটি পেস্ট ব্লক আর প্রতিটি কমান্ডই আপনার ব্যবহারের জন্য।
একটি SixPanel সার্ভারে এটি আগে থেকেই আছে
SixPanel দোকানের ভেতরে SixPreflight বসিয়ে রাখে আর প্যানেলের নিজের Shop check-up পেজ হিসেবে দেখায়। আপনাকে কিছুই নামাতে হয় না, আর প্যানেল যেসব সেটিংয়ের মালিক সেগুলোর জন্য এমন পেস্ট ব্লক নয় যা পরের ডিপ্লয়ে মুছে যেত, বরং যে প্যানেল পেজ ওই সেটিংয়ের মালিক তার দিকেই দেখানো হয়।
SixPanel দেখুনওই ধরনের জন্য আরও একটি সৎ কথা: একটি SixPanel মেশিনে অ্যাপ্লিকেশনের নিজের সেটিংস — পেমেন্ট, মেইল, SMS, Firebase, ম্যাপ, টাইমজোন, মুদ্রা — সার্ভার স্কোরের বাইরে রেখে আলাদাভাবে দেখানো হয়, কারণ সেগুলো দোকানমালিকের কাজ, সার্ভারের নয়। উপরের সহজ ভাষার রায়টি তবু পুরো ব্যবসার হয়েই কথা বলে।
শর্ত ও চালানোর নিয়ম
শর্ত, কীভাবে চালাবেন, আর এটি কী বদলাবে
টুলটির নিজের যা লাগে
| শর্ত | যা লাগে |
|---|---|
| PHP | টুলটি চালাতে 8.2 বা নতুন |
| ওয়েব সার্ভার | যেকোনো কিছু, যা আপনার সাইটের public/ ডিরেক্টরি পরিবেশন করে |
| লেখার অনুমতি | preflight/config.php (কিংবা হাতে একটি পাসওয়ার্ড হ্যাশ পেস্ট করুন) আর preflight/history/ |
| অ্যাপ্লিকেশন | কিছু লাগে না। এটি খালি সার্ভারেও চলে |
| যেসব প্যানেল এটি চেনে | cPanel · aaPanel · CloudPanel · DirectAdmin · Plesk · CWP · সাধারণ সার্ভার |
এটি আপনার সার্ভারকে কীসের বিপরীতে গ্রেড দেয়
| সম্পদ | সর্বনিম্ন | যা বেছে নেবেন |
|---|---|---|
| vCPU | 2 | 4 |
| RAM | 4 GB | 8 GB |
| ফাঁকা ডিস্ক | শর্তের পেজে 20 GB — কিন্তু ডিস্ক পরীক্ষাটি নিজে 20 GB-তে পাস দেয়, 10 থেকে 20-এর মাঝে সতর্ক করে, আর কেবল 10-এর নিচে ব্যর্থ বলে | 40 GB+ |
| স্টোরেজের ধরন | SSD | NVMe |
| হোস্টিংয়ের ধরন | VPS বা ডেডিকেটেড | root-সহ VPS |
ফাঁকা-ডিস্কের সারিটি সত্যিই নিজের সাথে অমিল, আর আপনি সেটি স্ক্রিনেই দেখবেন
Requirements::platform()-এ হার্ডকোড করা আছে “20 GB দরকার, 40 GB+ বেছে নিন”, অথচ হার্ডওয়্যার পরীক্ষাটি গ্রেড দেয় config.php-র min_free_disk_gb = 10-এর বিপরীতে — তাই 12 GB ফাঁকা থাকা একটি সার্ভার একই পেজে এক টেবিলে শর্ত-ব্যর্থতা আর অন্য টেবিলে হলুদ সতর্কতা।
ব্রাউজারে — স্বাভাবিক উপায়
ফোল্ডারটি আপলোড করুন
পুরো preflight/ ফোল্ডারটি আপনার সাইটের public/ ডিরেক্টরিতে আপলোড করুন।
প্রথম স্ক্রিনেই একটি পাসওয়ার্ড দিন
https://your-domain/preflight/ খুলে একটি পাসওয়ার্ড দিন। পাসওয়ার্ড ছাড়া এটি শুরুই হয় না, আর যিনি প্রথমে খুলবেন তিনিই সেটি ঠিক করবেন — তাই আপলোড শেষ হওয়ার সাথে সাথেই এটি করুন। সর্বনিম্ন আট অক্ষর। config.php-তে লেখা না গেলে পেজটি সেটি জানায় আর তার বদলে পেস্ট করার জন্য এক লাইনের password_hash() কমান্ডটি দেয়।
একটি বোতাম চাপুন
“এখনই পরীক্ষা” প্রায় এক সেকেন্ড নেয়। “গভীর পরীক্ষা” বাইরের পরীক্ষাগুলো যোগ করে।
কাজ শেষে ফোল্ডারটি মুছে দিন
এটি সুরক্ষিত, তবু এটি সার্ভারের ভেতরের কথা জানায় আর একটি লাইভ সাইটে থেকে যাওয়ার কোনো কারণ নেই।
ঐচ্ছিক: config.php-তে allow_ips দিয়ে IP অনুযায়ী অ্যাক্সেস সীমিত করুন (একক ঠিকানা বা CIDR রেঞ্জ, IPv4 ও IPv6)। Cloudflare বা লোড ব্যালান্সারের পেছনে সে যে ঠিকানা দেখে সেটি প্রক্সির, তাই নিজের IP-র একটি অনুমোদিত তালিকা আপনাকেই আটকে দেবে — এটি ফাঁকা রেখে পাসওয়ার্ডের উপর ভরসা করুন, নয়তো প্রক্সিতে সীমিত করুন। নিজেই আটকে গেলে 403 পেজটি ছেপে দেয় আসলে কোন ঠিকানা এসেছে আর প্রক্সি সেটিকে কী বলছে।
আপনি বললে এটি কী বদলাবে
স্ক্যান পড়ে। প্যাকেজের চারটি সারফেস লিখতে পারে, আর তার কোনোটিই নিজে থেকে চলে না — প্রতিটির জন্য একটি বোতাম বা একটি কমান্ড লাগে।
Error logs পেজ একটি লগ পরিষ্কার করতে পারে
Clear বোতামটি ফাইলটি মুছে না দিয়ে ftruncate দিয়ে খালি করে, কারণ PHP, MySQL ও nginx ওই ফাইলগুলো খোলা রাখে আর মুছে দিলে তারা নামহীন একটি হ্যান্ডেলে লিখতে থাকে। এতে CSRF টোকেন লাগে, আর PHP ইউজার ফাইলটিতে লিখতে না পারলে এটি কাজ না করে শেল কমান্ডটি ছেপে দেয়। এটি Laravel, MySQL slow/error, php-fpm আর ওয়েব-সার্ভার লগে লেখা — এমন ফাইল যেগুলোর মালিক টুলটি নয়।
Test order alert পেজ সত্যিকারের একটি পুশ পাঠায়
প্ল্যাটফর্মের নিজের artisan কমান্ড দিয়ে, একটি আসল স্টোর বা রাইডার ডিভাইসে। “কী পাঠানো হতো দেখান” নামে একটি শুকনো-রান বোতাম আছে; সেটি ডিফল্ট নয়।
ডেটাবেস বেঞ্চমার্ক নিজের টেবিল তৈরি করে আর মুছে দেয়
নাম zz_preflight_bench_<random>, প্রতি রানে নতুন র্যান্ডম প্রত্যয়সহ — পুরো নিরাপত্তার যুক্তি নিচে আছে।
পাসওয়ার্ড ঠিক করলে config.php আবার লেখা হয়
আর ড্যাশবোর্ডের “সেভ প্রোফাইল” কাজটি অপারেটরের দেওয়া RAM ও vCPU সংখ্যা সার্ভার প্রোফাইল ফাইলে লেখে। দুটিই preflight/ ফোল্ডারের ভেতরে।
আর আলাদা করে, ইচ্ছে করেই: bin/setup-6ammart.php আপনি --apply দিয়ে চালালে পরিবর্তনগুলো প্রয়োগ করে। সেটিই তো এর কাজ।
কমান্ড লাইন থেকে — অ্যাপ্লিকেশন নেই, ব্রাউজার নেই
তুলনার দুটি টুল কেবল কমান্ড লাইনেই চলে আর HTTP-তে উত্তর দিতে অস্বীকার করে।
php preflight/server-compare.php # এই মেশিনটি মাপুনphp preflight/server-compare.php --save=box-a.jsonphp preflight/server-compare.php --compare=box-a.json,box-b.jsonphp preflight/detect-size.php # RAM ও vCPU লিখে রাখুনওই পাহারাটি কেবল এই দুটি ফাইলেই নেই। প্যাকেজের এগারোটি ফাইল কমান্ড লাইনের বাইরে চলতে অস্বীকার করে — ওই দুটি, tests/smoke.php-সহ আটটি টেস্ট হারনেস, আর bin/setup-6ammart.php। পাহারাটি কেন জরুরি তার কারণ tests/smoke.php: পাসওয়ার্ড ছাড়া ওয়েবে পৌঁছানো যায় এমন অবস্থায় ফেলে রাখলে — একসময় এটি সেভাবেই শিপ হয়েছিল — নাম-পরিচয়হীন একটি GET-এর খরচ ছিল এগারো সেকেন্ড CPU, অ্যাপ্লিকেশন ডেটাবেসের একটি পূর্ণ প্রোব, সার্ভারের নিজের পাবলিক URL-এ করা দশটি রিকোয়েস্ট, আর Google Maps, কনফিগার করা SMTP হোস্ট ও Firebase-এ বাইরের কল — যা যে কেউ যতবার খুশি চালাতে পারতেন। স্ক্যান এখন আপনার সার্ভারে ঠিক ওই ফাইলটিই খোঁজে, কারণ এমন একটি ফোল্ডার বছরের পর বছর এক মেশিন থেকে আরেক মেশিনে কপি হতে থাকে।
server-compare.php স্বয়ংসম্পূর্ণ আর এর কোনো নির্ভরতা নেই — এতে কোনো অ্যাপ্লিকেশনই লাগে না, আর এ কারণেই আপনি যে দুটি সার্ভার ভাড়া নেওয়ার কথা ভাবছেন, কোনোটিতে রাজি হওয়ার আগে সেগুলো মেলানোর জন্য এটিই সঠিক টুল।
বেঞ্চমার্ক স্কোর পড়া
দুটি স্কোরই এমনভাবে স্বাভাবিক করা যে যেকোনো কাঠিন্যের মাত্রায় সেগুলোর মানে একই থাকে — কেবল মেশিনই সেগুলো বদলায়, আর বেশি মানে দ্রুত। চলতি একটি ক্লাউড vCPU-তে প্রায় 100 আসে। ভিন্ন ভিন্ন সময়ে দুই-তিনবার চালান: বার্স্টেবল ইনস্ট্যান্সের ক্রেডিট ফুরালে সেটি হঠাৎ নেমে যায়, আর একবার চালালে তা ধরা পড়বে না। ওই 100-এর পেছনের রেফারেন্স মেশিনটি একটি AMD EPYC 7713 vCPU, লোকাল NVMe, PHP 8.3, OPcache চালু।
ডেটাবেস স্কোরে বিশেষ করে single-row INSERT/sec দেখুন: innodb_flush_log_at_trx_commit=1 থাকলে প্রতিটিই একটি ডিস্ক সিঙ্কের জন্য অপেক্ষা করে, তাই ওই সংখ্যাটি আসলে আপনার স্টোরেজের fsync লেটেন্সি। প্রোভাইডারদের মধ্যে এটিই সবচেয়ে স্পষ্ট পার্থক্য।
আগে প্রস্তাবিত my.cnf প্রয়োগ করুন, তারপর দুটি সার্ভার মেলান — নয়তো আপনি মেশিন নয়, কনফিগারেশন মেলাচ্ছেন।
আসলে কী বসাবেন
কনটেইনার ছাড়া নেটিভ ইনস্টলের জন্য SixPreflight-এর নিজের সুপারিশ:
- Ubuntu 26.04 LTS
- PHP 8.5
- MariaDB 11.8
PHP 8.5
আপনার রিলিজের নিজের আর্কাইভে যা আছে — Ubuntu 26.04-এ 8.5, Debian 13-এ 8.4, Ubuntu 24.04-এ 8.3। 8.5 নিয়ে সন্দেহ ছিল কারণ maatwebsite/excel-এর মাধ্যমে আসা phpspreadsheet php <8.5 ঘোষণা করে; সেটি composer.json-এ একটি ঘোষণা, মাপ নয়, composer-এর প্ল্যাটফর্ম চেক বন্ধ, আর 8.5.4-এ কোডটি চালিয়ে সাদামাটা CodeCanyon ট্রি ও আমাদের নিজের ফর্ক — দুটিতেই বাইট-হিসেবে অভিন্ন স্প্রেডশিট এক্সপোর্ট পাওয়া গেছে। তিনটিই কার্যত একই গতিতে চলে, তাই এটি গতির সিদ্ধান্ত নয় — যেটির প্যাচ আপনার রিলিজ নিজেই দেয়, সেটিই নিন।
MariaDB 11.8 বা 10.11
যে-কোনোটি, আপনার রিলিজ যেটি বহন করে — একই দোকানে মেপে দেখা গেছে, 10.11-এর বিপরীতে 11.8 সমানে-সমান। যেটি সমানে-সমান নয় সেটি হলো ঘরানা: 6amMart আদৌ চলার আগে MySQL-এর দুটি সংস্করণেই কোড বদলাতে হয়, কারণ আইটেম সার্চ কেবল MariaDB-তে থাকা একটি অপ্টিমাইজার ফ্ল্যাগ সেট করে, আর দুটি ইনডেক্স মাইগ্রেশন এমন একটি ক্ষেত্রে সার্ভার ক্যাটালগ পড়ে যা MySQL ফেরত দেয় না, ফলে স্কিমা আংশিক প্রয়োগ হয়ে পড়ে থাকে।
Ubuntu 26.04
গতিতে Ubuntu 24.04 ও Debian 13-এর সমানে-সমান — মাপা পার্থক্যগুলো একটি মেশিনের নিজের সাথে নিজের অমিলের চেয়েও ছোট ছিল। এদের আলাদা করে সাপোর্টের মেয়াদ: 26.04-এর জন্য এপ্রিল 2031, তার বিপরীতে 24.04-এর জন্য মে 2029 আর Debian 13-এর জন্য অগাস্ট 2028। এটি সাপোর্টের মেয়াদের সিদ্ধান্ত, গতির নয়।
ওই ইঞ্জিনের সংখ্যাগুলো কী ঢাকে সেগুলো এসেছে একটি মেশিন ও একটি ডেটাসেট থেকে — একটি আসল দোকানের 66,701টি অর্ডারের ডাম্প — যেখানে প্রতিটি ইঞ্জিনে আগে মাইগ্রেশন চালিয়ে তৈরি হওয়া ইনডেক্স সেটগুলো মিলিয়ে 460টি ইনডেক্স পাওয়া গেছে, পাঁচটিতেই অভিন্ন, যাতে তুলনাটি অনুপস্থিত ইনডেক্সের নয়, ইঞ্জিনেরই হয়। এগুলো ওই একটি মেশিনে পাঁচটি ইঞ্জিনকে একে অন্যের সাথে মেলায়। 6amMart সাধারণভাবে কত দ্রুত, এগুলো তার কোনো বক্তব্য নয়।
এখানকার কিছুই বলে না যে একটি অপারেটিং সিস্টেম অন্যটির চেয়ে দ্রুত: অপারেটিং সিস্টেমগুলোর মধ্যে মাপা পার্থক্য একটিমাত্র মেশিনের নিজের সাথে নিজের ওঠানামার চেয়েও কম ছিল।
এটি কীভাবে চলে
প্যাকেজের কিছুই কোনো লাইসেন্স, অ্যাকাউন্ট বা মেয়াদের তারিখ পরীক্ষা করে না, আর এর কিছুই AllsWeb-কে কোনো কিছু জানায় না। এটি বাইরে যেসব কল করে সেগুলো সবই এমন জায়গায় যেখানে আপনার আগে থেকেই কাজ — আপনার নিজের সাইট, আপনার নিজের SMTP হোস্ট, Google-এর টোকেন ও জিওকোডিং এন্ডপয়েন্ট — সাথে নিজের ঠিকানা জানার জন্য একটি পাবলিক-IP ইকো সার্ভিস।
পরীক্ষাগুলো আদৌ কেন আছে তার সৎ কারণ: এগুলো এসেছে এই সার্ভারগুলো বানাতে ও ঠিক করতে গিয়ে, আর এর প্রতিটিই এমন প্রশ্ন যা আমাদের আপনাকে করতেই হতো। যে দোকানমালিক যোগাযোগ করার আগেই এগুলোর উত্তর দিতে পারেন তাঁর একটি দিন বাঁচে; যিনি পারেন না, তিনি এমন একটি রিপোর্ট পান যা তাঁর হোস্টকে পাঠাতে পারেন।
সৎ সীমাবদ্ধতা
সংখ্যাটির উপর ভরসা করার আগে এটি পড়ুন
সার্ভার যা দেখাবে না, সেটি এটি দেখতে পায় না
যেসব পরীক্ষার জন্য shell_exec বা /proc লাগে, সেগুলো আন্দাজ না করে “মাপা যায়নি”-তে নেমে আসে। ম্যানেজড প্যানেল আলাদা আলাদা জিনিস বন্ধ করে, তাই কিছু সারি এক হোস্টে ফাঁকা আর অন্য হোস্টে ভরা থাকে।
ম্যানেজড প্যানেলে সাতটি পরীক্ষার কোনো উত্তর থাকে না
open_basedir PHP-কে সাইটের ডিরেক্টরিতেই আটকে রাখে। সেটি ঠিক আছে আর রেখে দেওয়ারই মতো। সারিগুলো সেটি বলে দেয় আর স্কোরের বাইরে থাকে।
“এখনই পরীক্ষা” ওয়েব-সার্ভারের ছয়টি সারি দেখতে পায় না, আর তার একটি ব্লকার
কমপ্রেশন, স্ট্যাটিক ক্যাশিং, লাইভ keep-alive, সার্ভার ব্যানার, HSTS আর সার্টিফিকেটের মেয়াদ — এগুলো আসল রেসপন্স থেকে পড়া হয়, তাই কেবল গভীর পরীক্ষাতেই আসে — আর cert_expiry ব্লকার তালিকায় আছে। সবুজ ফল বিশ্বাস করার আগে গভীর পরীক্ষাটি চালান।
ফাঁকা ডিস্ক নিয়ে টুলটি নিজের সাথেই অমিল
শর্তের টেবিল বলে 20 GB ফাঁকা লাগবে; ডিস্ক পরীক্ষাটি 10–20 GB-কে সতর্কতা বলে আর কেবল 10-এর নিচে ব্যর্থ বলে। এক প্রশ্নের দুটি উত্তর, একই পেজে।
সার্ভার নিজের কনফিগারেশন বলে যা জানায়, এটি সেটিই জানায়
কোনো প্যানেল যদি এমন স্তরে কনফিগারেশন প্রয়োগ করে যা এই টুল দেখতে পায় না, তাহলে এর চেয়ে প্যানেলের নিজের ইন্টারফেসকেই বিশ্বাস করুন। cPanel ও aaPanel তাদের নিজের UI দিয়ে PHP ও MySQL কনফিগ সামলায় আর হাতে সম্পাদনা করা ফাইল মুছে দিতে পারে; CloudPanel আর সাধারণ সার্ভারে কনফিগ ফাইলই চূড়ান্ত থাকে। রিস্টার্টের পর কোনো সেটিং বারবার আগের অবস্থায় ফিরে গেলে সেটি প্যানেলেরই আবার লেখা — তার বদলে প্যানেল দিয়েই বদলান।
বেঞ্চমার্ক এই মেশিনকে এই মুহূর্তে মাপে
কোলাহলপূর্ণ প্রতিবেশী থাকলে প্রতিটি সংখ্যাই খারাপ দিকে যায় — সিদ্ধান্তে আসার আগে লোড-অ্যাভারেজের সারিটি দেখুন।
এক্সপোজার ধাপ কোনো পেনিট্রেশন টেস্ট নয়
এটি আপনার নিজের URL থেকে পরিচিত ঝুঁকিপূর্ণ ঠিকানার একটি নির্দিষ্ট তালিকা আনার চেষ্টা করে আর কী ফিরে এল তা জানায়। এটি অজানা দুর্বলতা খোঁজে না, আর এটি কোনো কোড অডিটও নয়।
একটি জিনিস সার্ভার থেকে সত্যিই পরীক্ষা করা যায় না
Google Maps ক্লায়েন্ট কি ব্রাউজার রেফারার দিয়ে সীমিত থাকে, তাই টুলটি বলতে পারে যে সেটি নেই, কিংবা সেটি বিপজ্জনকভাবে আপনার সার্ভার কি-র হুবহু সমান — কিন্তু সঠিকভাবে সীমিত করা একটি কি সার্ভারের দিক থেকে সে যাচাই করতে পারে না, আর সেটিকে পাস না দিয়ে কথাটি বলে দেয়।
আকারের টেবিলে সারির সংখ্যা আনুমানিক
সেগুলো আসে information_schema থেকে। নিখুঁত গণনা মানে হতো একটি লাইভ সাইটের প্রতিটি টেবিলের পূর্ণ স্ক্যান।
artisan-এর পাঁচ ডিরেক্টরির চেয়ে গভীরে রাখা আপলোড স্ট্যান্ডঅ্যালোন ধরন পায়
চুপচাপ — অ্যাপ্লিকেশন রুট খোঁজা পাঁচ স্তরেই থেমে যায়।
এটি আগে একটি পরীক্ষক
স্ক্যান নিজে কিছুই বদলায় না। প্যাকেজের চারটি সারফেস আপনি তাদের বোতাম চাপলে লেখে, আর bin/setup-6ammart.php আপনি --apply দিয়ে চালালে পরিবর্তন প্রয়োগ করে। পাঁচটিই উপরে লেখা আছে।
চালু দোকানে এটি কি নিরাপদ?
হ্যাঁ, আর এখানে ঠিক কেন।
আসল ডেটার প্রোবগুলো গঠনগতভাবেই শুধু-পড়ার
প্রতিটি প্রোব একটিমাত্র query() মেথডের মধ্য দিয়ে যায়, যা SELECT, EXPLAIN, SHOW বা WITH দিয়ে শুরু হয় না এমন কিছুই মানে না — আর ওই ক্লাসে এমন কোনো কোড পথই নেই যা INSERT, UPDATE, DELETE, ALTER, CREATE বা DROP চালাতে পারে, আর এই নিশ্চয়তাটিই আসলে প্রতিশ্রুতিটি বহন করে। সার্ভার সমর্থন করলে সেশনটি TRANSACTION READ ONLY-তে রাখা হয়, তাই ভুল হলেও সেটি এই কোড নয়, ডেটাবেসই ফিরিয়ে দিত। প্রতিটি স্টেটমেন্টে সার্ভারের দিকে 15 সেকেন্ডের একটি সীমা থাকে, তাই অপ্রত্যাশিত বড় একটি টেবিলে চালানো প্রোব সম্পদ আটকে বসে থাকতে পারে না — আর যে প্রোব ওই সীমা ছাড়ায় সেটিকে “খুব ধীর” বলে জানানো হয়, যা নিজেই একটি ফলাফল। যাচাই করা হয়েছে: আগে ও পরে সারির সংখ্যা ও SUM(order_amount) হুবহু এক।
ডেটাবেস বেঞ্চমার্ক কোনো অ্যাপ্লিকেশন টেবিলে কখনো হাত দেয় না
এটি যা কিছু তৈরি করে তার নাম zz_preflight_bench_<random>, প্রতি রানে নতুন র্যান্ডম প্রত্যয়সহ; কিছু তৈরি করার আগে নামটি ফাঁকা আছে কি না দেখে নেয় আর বিদ্যমান কোনো টেবিলে হাত না দিয়ে থেমে যায়; এর কোনো স্টেটমেন্টই এমন টেবিলের নাম নিতে পারে না যা সে নিজে বানায়নি; পরিষ্কার করার কাজটি টেবিলটি আসলেই তৈরি হয়েছিল কি না তার উপর নির্ভর করে, চলে একটি finally ব্লকে ও একটি শাটডাউন হ্যান্ডলারে, আর ছোট ছোট ব্যাচে কমিট লেখে, যাতে কিছুই দীর্ঘ সময় লক ধরে না রাখে। যাচাই করা হয়েছে: আগে ও পরে orders ও items-এর সারির সংখ্যা অভিন্ন, আর রানের পরে কোনো zz_preflight_ টেবিল টিকে থাকে না।
পরিধিটি টেবিল, ডেটাবেস নয়, আর এই পার্থক্যটিই পুরো প্রতিশ্রুতি
এটি কোনো অ্যাপ্লিকেশন টেবিল কখনো পড়ে না বা তাতে লেখে না — README-র নিজের ভাষা এটিই, আর এটিই সঠিক ভাষা। বেঞ্চমার্ক অ্যাপ্লিকেশনের ডেটাবেসের ভেতরে নিজের তৈরি করা একটি টেবিল বানায়, নিজের বানানো একটি নামে, আর আবার সেটি সরিয়ে ফেলে; ওই ডেটাবেসের আর কিছুতেই হাত পড়ে না।
নিজের ফোল্ডারের ভেতরে এটি একটিই জিনিস লেখে
preflight/history/, প্রতিটি সংরক্ষিত স্ক্যানের জন্য একটি ফাইল। ওই ফাইলগুলো সার্ভারের দুর্বলতা বিস্তারিতভাবে বলে, তাই প্রতিটির নাম .json.php আর শুরু হয় একটি PHP exit স্টেটমেন্ট দিয়ে — HTTP-তে আনতে গেলে ওয়েব সার্ভার সেটি চালায়, সাথে সাথেই থেমে যায়, আর কিছুই ফেরত দেয় না। nginx-এও এটি খাটে, যে .htaccess আমলে নেয় না।
লাল তালিকা এসেছে, কিন্তু সময় নেই?
রপ্তানি করা রিপোর্টটি আমাদের পাঠান। আমরা আপনার নিজের সার্ভারে 6amMart ইনস্টল, কনফিগার করে বুঝিয়ে দিই, আর একজন সিনিয়র ইঞ্জিনিয়ার রিলিজটি অনুমোদন করেন।
সার্ভার প্রস্তুত, তবু দোকান ধীর?
SixPreflight বলে দেয় সার্ভারটি প্রস্তুত কি না। দোকান নিজেই ধীর হলে সেটি অ্যাপ্লিকেশনের ব্যাপার, সার্ভারের নয় — আর 6amMart ইনস্টলেশন সার্ভিস এখন সর্বশেষ 6amMart রিলিজের উপরে ঠিক সেটিই দেয়: AllsWeb-এর অপ্টিমাইজ করা 6amMart বিল্ড প্রতিটি গ্রাহকমুখী স্ক্রিনে 10× থেকে 22× দ্রুত মাপা হয়েছে — 90–95% দ্রুত — লাইভ সার্ভারে, CDN বাদ দিয়ে মাপা।
FAQ
মানুষ আসলে যেসব প্রশ্ন করেন
আমার সার্ভার 6amMart-এর জন্য প্রস্তুত কি না, কীভাবে জানব?
তাতে SixPreflight চালান। এতে হার্ডওয়্যার, PHP, অ্যাপ্লিকেশন, .env, পারমিশন, ওয়েব সার্ভার, ক্যাশিং, ডেটাবেস, পাবলিক এক্সপোজার ও প্রতিটি বাইরের সার্ভিস জুড়ে 163টি পরীক্ষা আছে। একটি 6amMart ইনস্টলে গভীর পরীক্ষা তার নাগালের পুরো সেটটি চালায় — 160টি আলাদা পরীক্ষা, আর একটিমাত্র ওয়েব সার্ভার চালানো আসল মেশিনে সর্বোচ্চ 157টি সারি; দ্রুত “এখনই পরীক্ষা” চালায় 123টি, ওই একই মেশিনে সর্বোচ্চ 120টি, আর বাদ দেয় 12টি এক্সপোজার পরীক্ষা, 21টি সার্ভিস পরীক্ষা আর ওয়েব-সার্ভারের সেই ছয়টি সারি যেগুলোর জন্য লাইভ রেসপন্স লাগে। যেভাবেই হোক, এটি শেষ হয় একটি বাক্যে, A–F একটি লেটার গ্রেডে, আর প্রথমে কী ঠিক করতে হবে তার একটি সাজানো তালিকায়।
SixPreflight কি আমার সার্ভারে কিছু বদলায়?
স্ক্যান বদলায় না। এটি কোনো অ্যাপ্লিকেশন টেবিল কখনো পড়ে না বা লেখে না, আর কাউকে মেইল বা SMS পাঠায় না। চারটি সারফেস আপনি তাদের বোতাম চাপলে লেখে: Error logs পেজ একটি লগ ফাইল খালি করতে পারে, Test order alert পেজ একটি আসল ডিভাইসে সত্যিকারের পুশ পাঠায়, ঐচ্ছিক ডেটাবেস বেঞ্চমার্ক নিজের টেবিল তৈরি করে মুছে দেয়, আর পাসওয়ার্ড ঠিক করলে টুলের নিজের config.php আবার লেখা হয়। প্যাকেজের সাথে bin/setup-6ammart.php-ও আসে, যা আপনি --apply দিয়ে চালালে ইচ্ছে করেই পরিবর্তন প্রয়োগ করে।
অর্ডার নিচ্ছে এমন চালু দোকানে এটি চালানো কি নিরাপদ?
হ্যাঁ। ডেটাবেস প্রোবগুলো গঠনগতভাবেই শুধু-পড়ার — query() মেথড SELECT, EXPLAIN, SHOW বা WITH দিয়ে শুরু হয় না এমন কিছুই মানে না, ওই ক্লাসে লেখার মতো কোনো কোড পথই নেই, আর সমর্থন থাকলে সেশনটি TRANSACTION READ ONLY-তে চলে। ঐচ্ছিক বেঞ্চমার্ক কেবল সেই টেবিলেই কাজ করে যা সে নিজে একটি র্যান্ডম নামে তৈরি করে, আর একটি finally ব্লক ও একটি শাটডাউন হ্যান্ডলারে সেটি সরিয়ে ফেলে। দুটিই আগে-পরে সারির সংখ্যা ও SUM(order_amount) মিলিয়ে যাচাই করা হয়েছে।
এটি ব্যবহার করতে কি আমার 6amMart লাগবে?
না। এটি বুঝে নেয় সে কী দেখছে। অ্যাপ্লিকেশন নেই এমন খালি সার্ভারেও এটি হার্ডওয়্যার, PHP, ডেটাবেস সার্ভার, ওয়েব সার্ভার, পারমিশন ও এক্সপোজার পরীক্ষা করে — যদিও 14টি .env পরীক্ষা, 12টি Laravel অ্যাপ্লিকেশন পরীক্ষা, 9টি 6amMart প্ল্যাটফর্ম পরীক্ষা আর 5টি রিয়েলটাইম পরীক্ষার পড়ার মতো কিছুই থাকে না, আর অ্যাপ্লিকেশন ধাপ থেকে কেবল প্রোফাইল সারিটিই বাকি থাকে। যেকোনো Laravel অ্যাপ্লিকেশনে সার্ভার সম্পর্কিত সবকিছু খাটে আর 6amMart-নির্দিষ্ট পরীক্ষাগুলো আন্দাজ না করে বাদ দেওয়া হয়। 6amMart-এ যত পরীক্ষা চলতে পারে, সবই চলে।
লাইভে যাওয়ার আগে আমার কত স্কোর দরকার?
90 বা তার বেশি মানে A — প্রোডাকশনের জন্য প্রস্তুত। এর নিচে হলে আগে ব্লকারগুলো পড়ুন: বাকি সব যত ভালোই হোক, একটিমাত্র ব্লকার স্কোর 74-এ আটকে দেয়, দুটি 54-এ, তিন বা তার বেশি 34-এ। ব্লকার না থাকলেও একটি লাল সারি আপনাকে 88-এ আটকে দেয়। ব্লকার মানে সেসব জিনিস যা দোকানের বেচাকেনা থামিয়ে দেয় — ব্যবহারযোগ্য কোনো পেমেন্ট মেথড নেই, মেইল ব্যর্থ, ডেটাবেসে পৌঁছানো যাচ্ছে না, ওয়েবে .env পড়া যাচ্ছে, 14 দিনের মধ্যে সার্টিফিকেটের মেয়াদ শেষ। সংখ্যাটিতে ভরসা করার আগে একটি গভীর পরীক্ষা চালান: শেষেরটি আর ওয়েব-সার্ভারের আরও পাঁচটি সারি দ্রুত পরীক্ষায় একেবারেই মাপা হয় না।
কিছু সারিতে “এখান থেকে পড়া যায় না” লেখা কেন?
কারণ আপনার হোস্টিং প্যানেল PHP-কে সাইটের নিজের ডিরেক্টরিতেই আটকে রাখে, যা ঠিক আছে আর রেখে দেওয়ারই মতো — তাই /proc, /etc/os-release, nginx কনফিগ ও php-fpm পুল কনফিগ সত্যিই পড়া যায় না। তখন সাতটি পরীক্ষার কোনো উত্তর থাকে না। সেগুলো সৎভাবে জানানো হয় আর স্কোরের একেবারে বাইরে রাখা হয়, যাতে কড়াভাবে বন্ধ করা সার্ভার বন্ধ করার জন্য কখনো শাস্তি না পায়।
এটি কি cPanel, aaPanel, CloudPanel বা সাধারণ VPS-এ কাজ করে?
হ্যাঁ — এটিই এর মূল বাজার। এটি cPanel, aaPanel, CloudPanel, DirectAdmin, Plesk, CWP আর সাধারণ সার্ভার চেনে, আর প্রতি প্যানেলের জন্য আলাদা ইনস্টল কমান্ড ও পাথ দেয়। জেনে রাখার মতো: cPanel ও aaPanel তাদের নিজের ইন্টারফেস দিয়ে PHP ও MySQL কনফিগারেশন সামলায় আর হাতে সম্পাদনা করা ফাইল মুছে দিতে পারে, তাই রিস্টার্টের পর কোনো সেটিং বারবার আগের অবস্থায় ফিরে গেলে সেটি প্যানেল দিয়েই বদলান।
এটি কি কেবল বলে কী ভুল, নাকি ঠিকও করতে পারে?
দুটিই, আর ঠিক করার অর্ধেকটি আপনার ইচ্ছাধীন। ড্যাশবোর্ড প্রথমে আপনাকে প্রতিটি পরিবর্তন হাতে করতে বলে, কারণ যিনি নিজে পরিবর্তন করেন তিনি বোঝেন তিনি কী বদলেছেন। সেটি সম্ভব না হলে bin/setup-6ammart.php কমান্ড লাইন থেকে একই কাজ করে: ডিফল্টে শুকনো রান, জানানোর জন্য --check, কাজ করার জন্য --apply। এটি কেবল সেই ক্যাটালগ এন্ট্রিগুলোই প্রয়োগ করে যেগুলো স্বয়ংক্রিয় করা নিরাপদ বলে চিহ্নিত — প্রকাশিত 84টির মধ্যে 40টি — আর বাকিগুলোর জন্য জিজ্ঞেস করে বা ছেপে দেয়, --yes দিলেও।
আমি SixPanel চালাই। আমাকে কি এটি নামাতে হবে?
না। SixPanel দোকানের ভেতরে SixPreflight বসিয়ে রাখে আর প্যানেলের Shop check-up পেজ হিসেবে দেখায়। ওই ধরনে প্যানেল যেসব জিনিসের মালিক — ওয়েব সার্ভার, PHP, ডেটাবেস কনফিগারেশন, cron, কিউ ওয়ার্কার, সার্টিফিকেট — সেগুলোর পেস্ট ব্লক বাদ দেয় আর প্রতিটি সেটিংয়ের মালিক প্যানেল পেজটির দিকে দেখায়, কারণ সেখানে হাতে পেস্ট করা মান পরের ডিপ্লয়ে হারিয়ে যায়। অ্যাপ্লিকেশন স্তরের প্রতিটি পরীক্ষা সে রেখে দেয়।
আসলে কোন PHP ও ডেটাবেস সংস্করণ বসাব?
নেটিভ ইনস্টলের জন্য Ubuntu 26.04 LTS, আর তারপর তার নিজের আর্কাইভে যা আছে — PHP 8.5 ও MariaDB 11.8। 8.5 নিয়ে সন্দেহ ছিল কারণ একটি ডিপেনডেন্সি তার নিচে একটি সীমা ঘোষণা করে, কিন্তু সেই সীমা ঘোষণা, মাপ নয়: 8.5.4-এ কোডটি চালিয়ে সাদামাটা CodeCanyon ট্রি ও আমাদের ফর্ক — দুটিতেই বাইট-হিসেবে অভিন্ন স্প্রেডশিট এক্সপোর্ট পাওয়া গেছে। মাপা প্রতিটি PHP ও MariaDB সংস্করণই কার্যত একই গতিতে চলেছে, তাই এর কোনোটিই গতির সিদ্ধান্ত নয়। যা সত্যিকারের বিষয় সেটি ঘরানা: 6amMart আদৌ চলার আগে MySQL-এর দুটি সংস্করণেই কোড বদলাতে হয়, কারণ আইটেম সার্চ কেবল MariaDB-তে থাকা একটি অপ্টিমাইজার ফ্ল্যাগ সেট করে, আর দুটি ইনডেক্স মাইগ্রেশন এমন একটি ক্ষেত্রে সার্ভার ক্যাটালগ পড়ে যা MySQL ফেরত দেয় না।
ফলাফল কি আমার নিজের ড্যাশবোর্ডে যুক্ত করতে পারি?
হ্যাঁ। ?api=findings শেষ সংরক্ষিত পরীক্ষাটি HTTP Basic auth-এর মাধ্যমে JSON হিসেবে ফেরত দেয়, একটি স্থির কনট্র্যাক্ট সংস্করণসহ। এটি কখনো স্ক্যান শুরু করে না, আর পেলোডে run.age_seconds থাকে, যাতে আপনার ড্যাশবোর্ড পুরোনো খবরকে চলতি বলে না দেখিয়ে বলতে পারে “এই পাঠটি দুই সপ্তাহের পুরোনো”।
একটি ফোল্ডার আপলোড করুন। ব্রাউজারে খুলুন। একটি উত্তর পান।
সবসময় চলতি রিলিজ, আর তা চলে আপনার নিজের সার্ভারে। এটি আগে পড়ে, আর আন্দাজ না করে বলে দেয় কী কী মাপতে পারেনি।
প্যাকেজের কিছুই কোনো লাইসেন্স, অ্যাকাউন্ট বা মেয়াদের তারিখ পরীক্ষা করে না, আর এর কিছুই AllsWeb-কে কোনো কিছু জানায় না।