Java inventory میں صرف java -version کافی نہیں، چلتی JVM الگ گنیں

Production میں کون سی Java versions چل رہی ہیں، یہ جاننے کے لیے ہر سرور پر صرف java -version چلانا کافی نہیں۔ یہ کمانڈ اس shell میں منتخب Java binary کا ورژن دکھاتی ہے؛ چلتی ہوئی ہر application اسی binary سے شروع ہوئی ہو، یہ ضروری نہیں۔ پہلے چلتی JVM processes تلاش کریں، پھر ہر process کا runtime معلوم کریں اور containers کے workloads الگ شامل کریں۔

Inventory میں منتخب binary، نصب شدہ runtimes، اس وقت چلتی JVMs اور containerized workloads کے الگ خانے رکھیں۔ اس فرق سے patch کے جائزے میں واقعی استعمال ہونے والا ورژن سامنے آتا ہے، جبکہ نصب مگر غیر استعمال شدہ Java asset اور licensing جائزے سے غائب نہیں ہوتی۔ جس ورژن کی تصدیق صرف image یا installation سے ہوئی ہو، اسے چلتی process کا ورژن نہ لکھیں۔

ایک host کی چار الگ حقیقتیں درج کریں

ہر دریافت کے ساتھ host یا workload کی شناخت، مشاہدے کا وقت، مکمل Java ورژن، vendor اور ثبوت کا طریقہ محفوظ کریں۔ ایک ورژن کئی processes میں چل سکتا ہے اور ایک host پر کئی runtimes نصب ہو سکتے ہیں؛ اس لیے صرف version کو منفرد شناخت نہ بنائیں۔ یہ بھی لکھیں کہ نتیجہ process سے ملا، executable سے ملا یا disk scan سے۔

• منتخب binary: متعلقہ shell میں java -version کا نتیجہ اور منتخب executable کا path درج کریں۔ یہ اس نشست کا جواب ہے، پورے host کی applications کی فہرست نہیں۔
• نصب runtime: package records اور متعلقہ filesystem paths میں ملنے والی ہر Java installation کا path اور ورژن لکھیں۔ محض installation ملنا استعمال کا ثبوت نہیں۔
• چلتی JVM: ہر Java process کے ساتھ اس کا PID، service یا workload، launch command اور اسی process سے حاصل شدہ runtime version جوڑیں۔
• Container workload: container کی شناخت اور اس میں چلتی Java process کو host کی installation اور process entries سے الگ درج کریں۔

ان خانوں کا تعلق صرف وہاں قائم کریں جہاں اس کا ثبوت ہو۔ مثال کے طور پر host پر موجود Java installation کو container image کے runtime کے برابر فرض کرنے سے ایک workload غلط ورژن کے تحت درج ہو سکتا ہے۔ اسی طرح shell کے PATH یا JAVA_HOME سے ملا path کسی service کے launch path کی تصدیق نہیں کرتا۔

چلتی JVM سے اس کا ورژن لیں

Host پر jcmd بغیر arguments چلائیں اور نظر آنے والے PID کو متعلقہ service سے ملائیں۔ Oracle کی jcmd دستاویز کے مطابق بغیر arguments یہ کمانڈ دستیاب Java processes کے PID اور launch کی تفصیل دکھاتی ہے؛ منتخب PID کے لیے jcmd <PID> VM.version، JVM version کی معلومات اور VM.system_properties، system properties دکھاتی ہے۔

ورژن کے ساتھ java.version، java.vendor اور java.home جیسی properties مفید ہیں، مگر انہیں اسی PID اور مشاہدے کے وقت کے ساتھ محفوظ کریں۔ Linux میں /proc/<PID>/exe کا path اس executable کی شناخت میں مزید مدد دے سکتا ہے جس سے process شروع ہوئی تھی۔ ورژن کی تشخیص کے لیے process سے ملا ثبوت، administrator کی shell میں چلائے گئے java -version سے زیادہ متعلقہ ہے۔

jcmd کو اسی مشین پر JVM شروع کرنے والے مؤثر user اور group identifiers کے ساتھ چلانا ہوتا ہے۔ اس لیے فہرست میں process نہ آنے کو Java کی عدم موجودگی نہ سمجھیں؛ پہلے رسائی اور process کی حد دیکھیں۔ VM.system_properties کی پوری output inventory میں رکھنے کے بجائے ضروری version fields نکالیں، کیونکہ باقی properties میں application کی configuration بھی شامل ہو سکتی ہے۔

Docker container کی process الگ دریافت کریں

Host کی jcmd فہرست containers کی مکمل فہرست نہیں: الگ Docker process میں JVM اس کی عام listing سے رہ سکتی ہے۔ چلتے containers کی شناخت کے بعد ہر متعلقہ container میں process موجود ہونے کا ثبوت حاصل کریں۔ Docker کی container top دستاویز کے مطابق docker container top CONTAINER اس container کی چلتی processes دکھاتا ہے۔

اس command سے Java process کا سراغ مل سکتا ہے، خود اس کا درست runtime version نہیں۔ ورژن کے لیے اسی workload کی قابلِ رسائی JVM diagnostics یا اس کے Java executable کا ثبوت لیں، اور نتیجے کے ساتھ container کی شناخت بھی رکھیں۔ Host اور container میں PID کی شناخت مختلف ہو سکتی ہے؛ ملان کے وقت صرف PID پر انحصار کرنے کے بجائے container اور workload کو بھی شناخت کا حصہ بنائیں۔

اگر minimal image میں shell یا jcmd موجود نہ ہو تو version کا خانہ اندازے سے نہ بھریں۔ Image اور build records سے ایک ممکنہ runtime کی شناخت ہو سکتی ہے، مگر اسے چلتی process سے تصدیق شدہ ورژن سے الگ نشان زد کریں۔ Host پر image کا موجود ہونا بھی active workload کا ثبوت نہیں؛ اس کے لیے چلتے container اور process کی دریافت درکار ہے۔

Fleet agent اور installed scanner کی حدود ملائیں

Fleet سطح پر agent سے JVMs کی مرکزی فہرست مل سکتی ہے، لیکن اس کی coverage کو installation کی مکمل دریافت نہ سمجھیں۔ Azul کی JVM Inventory وضاحت کے مطابق اس کی فہرست ان JVMs کی ہے جو Azul JVM یا Intelligence Cloud Agent کے ذریعے service سے connected ہوئی ہوں؛ یہ غیر استعمال شدہ JVMs خود دریافت نہیں کرتی۔ اس فہرست میں runtime کا نہ ہونا، اس کے نصب نہ ہونے کا ثبوت نہیں۔

Installed-runtime scanner اس کے برعکس package records، disk paths یا شامل کردہ images میں Java ڈھونڈتا ہے۔ اس کا مثبت نتیجہ installation کی موجودگی بتاتا ہے، چلتی application نہیں۔ منفی نتیجے کی حد بھی واضح کریں: جس path، image یا host کو scan ہی نہیں کیا گیا، اس کے بارے میں عدم موجودگی کا فیصلہ نہیں کیا جا سکتا۔

دونوں طریقوں کے نتائج کو ایک ہی مبہم «Java موجود ہے» حالت میں ضم نہ کریں۔ ہر runtime کے سامنے «نصب ملا»، «چلتی process سے تصدیق ہوئی» اور «agent نے مشاہدہ کیا» جیسی الگ حیثیت رکھیں۔ مختصر مدت کے jobs یا restart ہونے والی services ایک وقتی snapshot سے چھوٹ سکتی ہیں، اس لیے آخری مشاہدے کا وقت بھی درج کریں؛ پرانی agent entry کو موجودہ چلتی process نہ گنیں۔

Patch اور licensing کے لیے نتیجہ کیا ہونا چاہیے

کارآمد inventory ہر workload کو اس کے مشاہدہ شدہ runtime سے اور ہر installation کو اس کے استعمال کی حیثیت سے جوڑتی ہے۔ Patch کے جائزے میں چلتی JVM کا درست ورژن، vendor، application owner اور deployment مقام سامنے رکھیں۔ نصب مگر غیر استعمال شدہ runtime کو الگ جانچیں، کیونکہ اسے کسی active workload سے جوڑے بغیر production میں چلتا ہوا قرار دینا غلط ہوگا۔

Licensing جائزے میں بھی installation اور مشاہدہ شدہ استعمال کے شواہد الگ رکھیں؛ ان کی قانونی اہمیت متعلقہ vendor کے معاہدے پر منحصر ہوگی۔ جہاں process کا ورژن دستیاب نہ ہو، وہاں «نامعلوم» درج کریں اور واضح کریں کہ کون سا ثبوت باقی ہے۔ اس طرح فہرست بتاتی ہے کہ کون سا Java runtime حقیقتاً چلتا دیکھا گیا، کون سا صرف نصب ملا اور کہاں inventory ابھی نامکمل ہے۔

یہ بھی پڑھیں:

• CVSS 10 اکیلا patch order نہیں، KEV اور affected version پہلے دیکھیں
• Gemini اب Gmail سے Slides بنائے گا—بیرونی apps میں write access نہیں
• HAProxy خامی نہیں، binary بدل دی گئی—Ted backdoor logs سے بھی چھپتا ہے