At VeeamON 2024, Veeam announced that in the upcoming version (likely v13), the Veeam Backup & Replication (VBR) Server will be available for Linux systems, in addition to Windows.


Historically, VBR has required a Windows installation. This move to support Linux is a long-awaited shift that many in the community have requested.


Deployment and design details mentioned in the post (though subject to change):

Expected delivery as an OVA (virtual appliance).

Likely based on a hardened Rocky Linux 9.2, managed by Veeam.

It will include a web-based console—though it's unclear if the traditional Windows console will also be available.

Initially, the Linux option may not support other distributions, focusing solely on Rocky Linux at launch.

Feature parity with the Windows version is hoped for, but not guaranteed.


Broader Context & Updates Since Then
Veeam Backup & Replication Version Info

The latest official release is v12.3.1.1139, released on March 19, 2025.
Wikipedia

As of that version, the Linux deployment of the VBR server was not yet available. VBR still runs on Windows in v12.

v13 Rolling Out with Linux Support

On September 3, 2025, Veeam officially released Veeam Backup & Replication 13 (v13)—but only as a Linux-based Software Appliance (VSA). The Windows installer is still pending and expected to come out in the coming months.



Available formats:

OVA (pre-built virtual appliance) for VMware vSphere (requires ESXi 7.0 U2 or later).

ISO for physical host or alternate hypervisor installations—with system requirements including:

x86-64 CPU with at least 8 cores.

Minimum 16 GB RAM, plus ~500 MB per concurrent job.

Two 240 GiB disks (for OS and installation).

Network: 1 Gbps+ local or 1 Mbps+ WAN connection.


Some existing Windows component dependencies still remain. For example, a Windows mount server is required for certain restore scenarios.


Due to the architecture changes in v13, Veeam has extended support for v12 (including its agents and plugins) to 4 years instead of the usual 3


#veeam #linux #backup

بررسی نرخ مربوط به داده و فرمول اختصاص محاسبه تقریبی رم

نسبت به نرخ داده در elasticsearch



بنده این فرمول را نسبت به ساختار های و معماری های مربوط به elasticsearch ، پردازش و تحلیل نموده که نرخ مربوطه حاصل گردیده است .


امید هست ، مورد استفاده ، جامعه It , devops , bigdata کشور قرار گیرد .





پذیرای هرگونه از پیشنهادات و نظرات و انتقادات شما عزیزان میباشم .


#data #elk #elasticsearch #linux #bigdata #log #etl

#yashar_esmaildokht

https://t.iss.one/unixmens

خرید Isovalent توسط سیسکو؛ گامی استراتژیک در آینده‌ی شبکه و امنیت چندابری

مقدمه

در دنیای فناوری اطلاعات، خریدها و ادغام‌های استراتژیک اغلب مسیر آینده‌ی صنعت را شکل می‌دهند. یکی از مهم‌ترین خریدهای اخیر در حوزه شبکه و امنیت، خرید شرکت Isovalent توسط سیسکو (Cisco Systems) است؛ حرکتی که نه تنها جایگاه سیسکو در بازار شبکه‌های ابری و چندابری را تقویت می‌کند، بلکه آینده‌ی فناوری‌های مبتنی بر eBPF را نیز رقم خواهد زد.
پیشینه خرید

در ۲۱ دسامبر ۲۰۲۳، سیسکو اعلام کرد که قصد خرید Isovalent را دارد.

این معامله در ۱۲ آوریل ۲۰۲۴ نهایی شد.


با این خرید، سیسکو مالکیت فناوری‌های کلیدی Isovalent مانند Cilium و Tetragon را به دست آورد؛ ابزارهایی که به‌ویژه در دنیای Cloud Native و محیط‌های چندابری به‌سرعت در حال تبدیل شدن به استاندارد صنعتی هستند.
فعالیت Isovalent و نقش آن در صنعت

در واقع Isovalent شرکتی پیشرو در توسعه‌ی راهکارهای شبکه و امنیت مبتنی بر eBPF است. eBPF (Extended Berkeley Packet Filter) یک فناوری قدرتمند در هسته لینوکس است که امکان نظارت، مشاهده‌پذیری (observability)، و اعمال سیاست‌های امنیتی در سطح پایین سیستم‌عامل را بدون نیاز به تغییر کد کرنل فراهم می‌کند.

محصولات کلیدی Isovalent

1. Cilium:

یک پلتفرم متن‌باز برای شبکه‌سازی Cloud Native در Kubernetes.

قابلیت‌هایی مانند شبکه‌سازی امن، load balancing و observability را ارائه می‌دهد.



2. Tetragon:

یک ابزار امنیتی پیشرفته مبتنی بر eBPF.

امکان تشخیص تهدیدات لحظه‌ای، مانیتورینگ امنیتی عمیق و اجرای سیاست‌های امنیتی پویا را فراهم می‌کند.

انگیزه‌های سیسکو از این خرید

1. تقویت موقعیت در بازار چندابری (Multicloud):
بسیاری از سازمان‌ها امروزه از چندین ارائه‌دهنده ابر استفاده می‌کنند. سیسکو با Cilium و Tetragon می‌تواند یک لایه مشترک شبکه و امنیت بر فراز تمام ابرها ایجاد کند.


2. افزایش توان امنیتی:
با eBPF، سیسکو می‌تواند قابلیت‌های امنیتی را از سطح سخت‌افزار و شبکه‌های سنتی به سطح نرم‌افزار و workloadها منتقل کند.


3. نوآوری در Observability و Performance:
ترکیب فناوری‌های Isovalent با محصولات سیسکو، امکان پایش لحظه‌ای و بهینه‌سازی عملکرد در مقیاس بالا را فراهم می‌کند.


4. هم‌افزایی با اکوسیستم متن‌باز:
خرید Isovalent به معنای ورود جدی‌تر سیسکو به دنیای پروژه‌های متن‌باز است که برای نوآوری در زیرساخت‌های ابری حیاتی است.
تأثیرات این خرید بر صنعت

تقویت جایگاه eBPF به‌عنوان ستون فقرات شبکه‌سازی و امنیت در محیط‌های ابری.

رقابت شدیدتر با شرکت‌هایی مانند VMware، Google و Red Hat در حوزه Cloud Native Networking.

ایجاد یکپارچگی بیشتر بین زیرساخت‌های سنتی شبکه سیسکو و جهان Cloud Native و Kubernetes

خرید Isovalent توسط سیسکو را می‌توان یک حرکت استراتژیک و آینده‌نگرانه دانست که مسیر تحول در شبکه‌سازی ابری، امنیت workloadها و observability را تغییر خواهد داد. سیسکو با این اقدام، نه‌تنها قدرت خود را در بازار شبکه‌های سازمانی تثبیت می‌کند، بلکه خود را به‌عنوان یکی از بازیگران اصلی در دنیای چندابری و Cloud Native مطرح می‌سازد.


#cisco #isovation #linux #kernel #ebpf #tetragon #cilium

https://t.iss.one/unixmens

دواپس و مسیر های ورود به آن



#devops #linux #infra #infrastructure #system #design #network #programmer #developer




https://t.iss.one/unixmens

به‌عبارت دیگر، متخصص زیرساخت کسی است که هم شبکه را می‌شناسد، هم کدنویسی بلد است، هم از سیستم‌ها شناخت عمیق دارد، و هم می‌تواند کل این پازل را در قالب یک معماری منسجم کنار هم بچیند.
در واقع زیرساختی‌ها تنها مجری نیستند. به دلیل درک جامع خود، می‌توانند نقش مشاور استراتژیک ایفا کنند و راهکارهایی ارائه دهند که از نظر اقتصادی، امنیتی و عملیاتی بهترین نتیجه را برای سازمان به همراه داشته باشد.

اما چرا ؟

🔹 دلیلش ساده است:
وقتی سال‌ها با سیستم‌عامل، استوریج، دیتابیس، شبکه لینوکسی، HA، replication و tuning کار کرده‌ای، به‌صورت تجربی یاد می‌گیری که:

چطور منابع محدود (CPU, RAM, Disk I/O, Network) را بین سرویس‌ها طراحی و بهینه کنی.

چطور برای scalability، سیستم را افقی (scale-out) یا عمودی (scale-up) توسعه دهی.

چه الگوهایی برای High Availability و Fault Tolerance وجود دارد.

چطور داده را در مقیاس بالا توزیع و ایمن نگه دارد

تفاوت با بقیه مسیرها

برنامه‌نویس‌ها بیشتر روی design در سطح کد (Design Patterns, Microservices Architecture) تمرکز دارند، اما وقتی صحبت از زیرساخت و ظرفیت سیستم می‌شود، عمق لازم را ندارند.

متخصصان شبکه هم system design را معمولاً فقط در لایه‌ی ارتباطات می‌شناسند (topology، routing، segmentation) نه در کل stack.


اما متخصص زیرساخت، وقتی از system design صحبت می‌کند، یعنی دید End-to-End دارد:
از block storage و replication گرفته تا شبکه، دیتابیس و اپلیکیشن.

چرا این در DevOps مهم است؟

چون DevOps فقط ابزار نیست؛ DevOps یعنی طراحی یک سیستم پایدار، مقیاس‌پذیر و قابل‌اعتماد.

اگر system design بلد نباشی، صرفاً ابزارها را به هم می‌دوزی.

ولی اگر system design را بفهمی، ابزارها را بر اساس نیاز واقعی سیستم انتخاب و ترکیب می‌کنی.


به همین خاطر کسی که از زیرساخت آمده، معمولاً در تیم DevOps نقش معمار (Architect) را هم می‌تواند بر عهده بگیرد، در حالی که بقیه مسیرها بیشتر در نقش مجری یا توسعه‌دهنده باقی می‌مانند.



#devops #linux #infra #infrastructure #system #design #network #programmer #developer




https://t.iss.one/unixmens

دوستان دواپسی نکته ای را از یاد نبریم

دواپس نصب سریع ابزار ها نیست .
دواپس سرعت بخشیدن به کارهای تکراری و toil work هست
دواپس یعنی داشتن درک system design .
از یاد نبریم وقتی شغل هایی که مفهوم engineer را یدک میکشن . به معنای ، implementation ، problem solving, optimisation, upgradation هست .

این یعنی دانستن معماری ، تحلیل ، و درک ماهیت اجزا و قابلیت حل مشکلات هست .

هدف نصب و استقرار به جای ۱ ساعت در ۱۰ دقیقه و ندانستن اجزا و رفع اون نیست .

اون مورد سرعت و اتومیشن هم برای bcp و drp هست ، در واقع شناخت اجزای سیستم و قابلیت حل مسائل در شرایط حساس مانند BCP/DRP.


مهندس DevOps بودن، یعنی درک این که ارزش ما فقط در سرعت نصب ابزار نیست، بلکه در توانایی طراحی، تحلیل و حل مسائل پیچیده زیرساختی و سازمانی است.

وهمچنین درک ساختار در موضوعات operation , prosessing , tecnical بخش جدانشدنی از این مسیر است.


#devops #linux #culture #team

https://t.iss.one/unixmens

Two bugs discovered in the NVIDIA Linux Open GPU Kernel Modules (drivers) and they can be exploited to gain root level access. The bugs can be triggered by an attacker controlling a local unprivileged process. Their security implications were confirmed via a proof of concept that achieves kernel read and write primitives. Those bugs are already fixed and use your Linux distributions package manager to apply security updates to your nvidia drivers on Linux servers and desktops


Link

#security

#kernel #exploite #linux

https://t.iss.one/unixmens

مفهوم ارتقا و رشد پایدار
چگونه انسان و ماشین در هم تنیده اند !؟؟
در واقع من دواپس هستم یا دواپس من !!؟

در فلسفهٔ هگل، فرایند دیالکتیکی از سه مرحله تشکیل می‌شود:

1. تز (Thesis) – گزاره یا ایدهٔ اولیه


2. آنتی‌تز (Antithesis) – نفی یا تقابل با ایدهٔ اولیه


3. سنتز (Synthesis) – مرحلهٔ فراتر که از دلِ تضادِ میان تز و آنتی‌تز زاده می‌شود و هر دو را در سطحی بالاتر رفع (Aufhebung) می‌کند.



🔹 توضیح بیشتر:
در نگاه هگل، حرکت تاریخ، اندیشه و هستی همگی دیالکتیکی هستند؛ یعنی رشد و تکامل از راه تضاد و نفی رخ می‌دهد.
سنتز نه صرفاً سازش، بلکه ادغام خلاقانه و برتری یافتن بر هر دو سوی تضاد است.

مثلاً:

تز: آزادی فردی

آنتی‌تز: نظم اجتماعی

سنتز: نظامی که هم آزادی فرد را حفظ می‌کند و هم نظم جامعه را برقرار می‌سازد (مانند دولت عقلانی در فلسفه هگل).


اگر بخواهیم ساده بگوییم:

> تز می‌گوید «الف»،
آنتی‌تز می‌گوید «نه الف»،
سنتز می‌گوید «هم الف و هم نه الف، اما در سطحی بالاتر».

واژه‌ی Aufhebung یکی از عمیق‌ترین و چندلایه‌ترین مفاهیم در فلسفه‌ی هگل است — واژه‌ای که ترجمه‌ی ساده‌ای ندارد و سه معنای هم‌زمان را در خود دارد:

1. نفی کردن (لغو) – چیزی از بین می‌رود یا رد می‌شود.


2. حفظ کردن (نگه‌داشتن) – با وجود نفی، جوهر و ارزش درونی آن چیز حفظ می‌شود.


3. بالا بردن (ارتقا دادن) – کل فرآیند در سطحی بالاتر و غنی‌تر ادامه می‌یابد.



هگل عمداً از واژه‌ای استفاده می‌کند که این سه معنا را هم‌زمان در خود داشته باشد. چون از دید او، در دیالکتیک هیچ چیز «کاملاً نابود» نمی‌شود؛ بلکه نفی می‌شود تا در سطحی بالاتر حفظ گردد.

🔹 نمونه‌ی ساده:
در رشد انسان:

کودک → نوجوان → بزرگسال


"بزرگسال" هم کودک نیست (نفی)، هم تجربه‌ها و ویژگی‌های دوران کودکی را در خود دارد (حفظ)، و هم آن‌ها را به سطحی بالاتر از آگاهی و تعقل رسانده (ارتقا).

🔹 در سطح فلسفی:
وقتی یک «تز» با «آنتی‌تز» روبه‌رو می‌شود، تضاد آن‌ها در «سنتز» از بین نمی‌رود، بلکه در سنتز رفع (Aufgehoben) می‌شود؛ یعنی هم نفی می‌شود، هم حفظ، و هم ارتقا.

به تعبیر زیبای هگل:

در واقع Aufhebung روحِ دیالکتیک است؛ همان چیزی که از تضاد، زندگی می‌سازد.


1. تز (Thesis)

ایده یا وضعیت اولیه.
در این مرحله، یک گزاره یا واقعیت مطرح می‌شود.
مثلاً: «فرد باید آزاد باشد.»

2. آنتی‌تز (Antithesis)

ایده‌ای در تضاد با تز پدیدار می‌شود.
مثلاً: «جامعه باید نظم داشته باشد؛ آزادی کامل موجب هرج‌ومرج می‌شود.»

3. سنتز (Synthesis)

اینجاست که تضاد میان تز و آنتی‌تز، به‌جای حذف یکی از آن‌ها،
در سطحی بالاتر رفع (Aufhebung) می‌شود.

این "رفع" یعنی:

نفی → تز و آنتی‌تز دیگر به شکل قبلی وجود ندارند.

حفظ → جوهر هر دو در سنتز باقی می‌ماند.

ارتقا → نتیجه، سطح بالاتری از فهم و واقعیت را نمایندگی می‌کند.


مثلاً:

آزادیِ فردی درونِ نظمِ اجتماعی — جایی که آزادی و نظم نه متضاد، بلکه مکمل‌اند.

مثال روزمره برای درک ساده‌تر:

تز: احساسات مهم‌تر از عقل‌اند.

آنتی‌تز: عقل مهم‌تر از احساسات است.

سنتز (Aufhebung): عقل و احساس باید در تعادل باشند؛ هر دو لازم‌اند.
نکتهٔ کلیدی:

در نظام هگل، این چرخه فقط یک‌بار اتفاق نمی‌افتد (تکرار پذیر و ادامه دار )
بلکه پیوسته تکرار می‌شود و هر سنتز، خود به تزِ مرحله‌ی بعد تبدیل می‌شود.
به این ترتیب، آگاهی، تاریخ، و جهان به‌صورت مارپیچی صعودی رشد می‌کنند.


رجوع شود به مفاهیم cmmi , agile ، scrum یا devops process

#devops #linux
https://t.iss.one/unixmens

وقتی میگوییم ، ما قسمتی از جهان هستیم .
و تصمیم های ما تصمیم های دیگری را میسازد و قسمتی از دهکده جهانی هستیم و مفهوم butterfly effect همیشه هست ...


وقتی می‌گوییم «ما قسمتی از جهان هستیم»، در حقیقت داریم به اصل وحدت و پیوستگی هستی اشاره می‌کنیم؛ یعنی هیچ موجودی، هیچ کنشی، و هیچ تصمیمی در خلأ اتفاق نمی‌افتد.

در این نگاه، تصمیم‌های ما فقط سرنوشت شخصی‌مان را نمی‌سازند، بلکه رشته‌ای از پیامدها را در شبکه‌ی بی‌انتها و پیچیده‌ی هستی آزاد می‌کنند. همین‌جا مفهوم Butterfly Effect معنا می‌گیرد:
لرزش بال‌های یک پروانه در نقطه‌ای از جهان، شاید به توفانی در آن‌سوی زمین بینجامد.

در سطح انسانی، یعنی:

هر گفتار، رفتار یا انتخاب ما، بر دیگران اثر می‌گذارد—even اگر آن را نبینیم.

ما درون یک «سیستم پیچیده» زندگی می‌کنیم، که در آن کوچک‌ترین تغییر می‌تواند مسیرهای بزرگ را دگرگون کند.

و در سطح فلسفی‌تر، یعنی جهان از آگاهی ما بی‌تأثیر نیست؛ ما تنها مشاهده‌گر نیستیم، بلکه بخشی از فرآیند خلق واقعیتیم.


#world #opensource #devops #linux

با pdb آشنا شویم :

در واقع Pod Disruption Budget (PDB) سیاستی است که مشخص می‌کند حداکثر چه تعداد پاد از یک برنامه می‌تواند به‌صورت هم‌زمان از کار بیفتد یا حذف شود — در زمان اتفاقات اختیاری (voluntary disruptions) مثل:

ارتقای نودها (Node upgrade)

و drain کردن نودها (مثلاً برای maintenance)

حذف دستی پادها توسط ادمین‌ها


به‌عبارتی، PDB تضمین می‌کند که در هر لحظه، حداقل تعداد معینی از پادهای یک برنامه در حال اجرا باشند تا سرویس قطع نشود.


دو نوع پارامتر اصلی در PDB

در فایل YAML مربوط به PDB، دو فیلد کلیدی برای تعریف بودجه در دسترس داریم:

1. minAvailable
یعنی حداقل چند پاد باید همیشه در حال اجرا باشند.
مثال:

minAvailable: 2

اگر برنامه شما 3 پاد دارد، این مقدار یعنی حداکثر 1 پاد را می‌توان هم‌زمان از کار انداخت.


2. maxUnavailable
یعنی حداکثر چند پاد می‌توانند هم‌زمان از کار بیفتند.
مثال:

maxUnavailable: 1

یعنی در هر لحظه، فقط 1 پاد می‌تواند غیرفعال باشد.



نمی‌توان هم‌زمان هر دو مقدار را در یک PDB تعریف کرد. یکی از آن‌ها باید انتخاب شود

نمونه فایل YAML

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: webapp-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: webapp

این مثال می‌گوید:

برای پادهایی که label آن‌ها app=webapp است،

همیشه حداقل ۲ پاد باید running باشند.

اگر deployment شما ۳ replica دارد، فقط یکی از آن‌ها را می‌توان در زمان upgrade یا drain از کار انداخت.

انواع اختلال (Disruptions)

نوع اختلال توضیح تحت کنترل PDB؟

در واقع Voluntary (اختیاری) کارهایی مثل drain node، upgrade cluster، delete pod دستی کاربردی است
و Involuntary (غیر اختیاری) crash نود، kernel panic، خطای سخت‌افزاری معنا ندارد


بنابراین، PDB جلوی خطاهای سیستمی را نمی‌گیرد؛ فقط جلوی اختلالات اختیاری‌ای را می‌گیرد که توسط عملیات نگهداری ایجاد می‌شوند.

رفتار در سناریوهای واقعی

فرض کنید یک Deployment با 3 پاد دارید و یک PDB با minAvailable: 2.
اگر نودها را drain کنید:

همچنین #Kubernetes بررسی می‌کند که با حذف هر پاد، هنوز ۲ پاد فعال باقی می‌مانند یا نه.

اگر نه، عملیات drain تا زمان جایگزینی پاد جدید به تعویق می‌افتد.

ابزارها و مشاهده وضعیت PDB

برای دیدن لیست PDBها:

kubectl get pdb

برای دیدن جزئیات هر PDB:

kubectl describe pdb <pdb-name>

نکات فنی و توصیه‌ها

همیشه برای Deploymentها یا StatefulSet‌های حیاتی (مثل frontend، API یا database replicas) PDB تعریف کنید
اگر replica فقط ۱ عدد است، تعریف PDB ممکن است باعث شود upgrade یا drain متوقف شود.
در سرویس‌های stateless معمولاً maxUnavailable بهتر است، و در سرویس‌های stateful minAvailable.
ابزارهایی مثل Cluster Autoscaler یا Kured (برای reboot خودکار نودها) با PDB کار می‌کنند.


#pdb #k8s #linux
https://t.iss.one/unixmens

چرا لینوکس و چرا در دواپس مهم هست .

تسلط عمیق به لینوکس باعث می‌شود مکانیسم‌های بنیادین سیستم مثل Memory Management، I/O، Networking، Process Lifecycle، Filesystem و Kernel Behavior را بفهمی.

همین مفاهیم پایه هستند که تفکر زیرساختی (Infrastructure Thinking) را می‌سازند.

وقتی این تفکر را داری، در DevOps، Security، Cloud، Storage و Database:

بهتر Performance Tuning انجام می‌دهی،

Root Cause Analysis را سریع‌تر پیدا می‌کنی،

راهکارهای متفاوت می‌بینی چون ساختار را از ریشه می‌فهمی نه از سطح،

و وابسته به ابزار نمی‌شوی.

«کسی که cgroups، namespaces و scheduling را بفهمد، Docker را بهتر از کسی که فقط دوره دیده می‌فهمد.»

«کسی که journalctl، syscalls و network stack را می‌شناسد، مشکلات پیچیدهٔ production را سریع‌تر حل می‌کند.»

و ...

#linux #devops
https://t.iss.one/unixmens

Security #Observability with #eBPF

#linux #cilium #kubernetes #k8s #security
https://t.iss.one/unixmens

محبوبیت Oracle 19c و چرایی استفاده کمتر از نسخه‌های جدید

۱. ثبات و بلوغ عملیاتی

ا. Oracle 19c نسخه‌ای است که پس از چند سال عرضه و دریافت به‌روزرسانی‌های امنیتی و رفع باگ‌ها، به یک نسخه پایدار و قابل اعتماد تبدیل شده است. سازمان‌ها تمایل دارند از نسخه‌ای استفاده کنند که ریسک کمتری داشته باشد و عملیات پایگاه داده را مختل نکند.
نسخه‌های جدید مثل 23c هنوز در مرحله بلوغ کامل نیستند و تجربه عملی DBAها با آنها محدود است.

۲. پشتیبانی طولانی‌مدت (Long-Term Support)

ا. Oracle 19c: تا سال ۲۰۲۷ پشتیبانی استاندارد و پس از آن Extended Support دارد.

ا. Oracle 23c: هنوز در ابتدای مسیر پشتیبانی است و بسیاری از شرکت‌ها تمایلی به استفاده از نسخه‌ای بدون سابقه طولانی ندارند.
این مورد یکی از مهم‌ترین عوامل تصمیم‌گیری سازمان‌هاست، زیرا ریسک توقف دریافت به‌روزرسانی امنیتی وجود دارد.


۳. سازگاری با اپلیکیشن‌ها و اکوسیستم موجود

اکثر برنامه‌های سازمانی، ابزارهای مانیتورینگ و پشتیبانی، و اسکریپت‌های DBA روی Oracle 19c بهینه شده‌اند. مهاجرت به نسخه‌های جدید مثل 23c نیازمند تست کامل و بازنویسی برخی فرایندها است که هزینه و ریسک بالایی دارد.

۴. ویژگی‌های کلیدی Oracle 19c

ا. Real Application Clusters (RAC) و Data Guard: فراهم کردن High Availability و Disaster Recovery.

ا. Automatic Indexing: خودکارسازی بهینه‌سازی شاخص‌ها برای افزایش کارایی.

ا. Hybrid Partitioned Tables: مدیریت داده‌ها با ترکیب چند نوع پارتیشن برای بهبود کارایی و نگهداری.

ا. JSON Data Support و Multimodel Database: امکان ذخیره و پردازش داده‌های غیرساخت‌یافته در کنار داده‌های رابطه‌ای.

ا. In-Memory Database Option: افزایش کارایی کوئری‌های تحلیلی با ذخیره‌سازی در حافظه.

ا. SQL Quarantine: جلوگیری از اجرای کوئری‌های مخرب یا ناکارآمد بدون توقف کل سیستم.

ا. Advanced Security Options: شامل Transparent Data Encryption و Data Redaction برای محافظت از داده‌ها.


۵. موانع پذیرش نسخه‌های جدید (23c و پس از آن)

ا. 23c ویژگی‌های نوین و بهینه‌سازی‌های جالبی دارد مثل JSON Relational Duality و Blockchain Tables، اما هنوز پایداری عملیاتی و تجربه DBA کافی با آن جمع‌آوری نشده است.

ابزارهای سوم‌شخص، اپلیکیشن‌های سازمانی و آموزش‌های موجود هنوز برای 23c کامل آماده نیستند.


نتیجه‌گیری

ا. Oracle 19c هم‌اکنون نقطه تعادل بین ثبات، امنیت، قابلیت‌های پیشرفته و پشتیبانی طولانی‌مدت است. نسخه‌های جدیدتر مزایای تکنیکی دارند اما ریسک و هزینه عملیاتی بالاتری دارند. به همین دلیل، سازمان‌ها همچنان 19c را ترجیح می‌دهند، و مهاجرت به نسخه‌های جدید بیشتر در سازمان‌های آزمایشی یا پروژه‌های جدید آغاز می‌شود.

#oracle #dba #database #linux
https://t.iss.one/unixmens

در پروژه‌های FOSS، ساختار حاکمیتی (governance) و منشور حاکمیت (Governance Charter) تعیین می‌کند که مسیر فنی پروژه چگونه انتخاب می‌شود، تضاد منافع چطور مدیریت می‌گردد، نقش‌ها و مسئولیت‌ها چگونه تعریف می‌شوند، و مشارکت‌کنندگان بر اساس چه قواعدی حق تصمیم‌گیری دارند. برخلاف پروژه‌های مالکیتی، در FOSS اگر این ساختار شفاف نباشد، پروژه به‌سادگی گرفتار بن‌بست، اختلافات داخلی، bus factor بالا، و حتی تصاحب توسط یک گروه خاص می‌شود. Governance Charter در واقع «قانون اساسی» پروژه است: از نحوه‌ی انتخاب maintainers تا فرآیند رأی‌گیری، release management، مدیریت امنیت، سیاست‌های merge، و سازوکار پاسخگویی را مشخص می‌کند. وجود همین چارچوب است که باعث می‌شود پروژه‌های متن‌باز بزرگ—مثل Linux Kernel، Kubernetes، Apache پایدار، قابل اعتماد و جامعه‌محور باقی بمانند و در طول زمان رشد کنند.

در آینده در مورد آن خواهم نوشت

#foss #opensource #Linux

در واقع DAM مخفف Database Activity Monitoring (پایش فعالیت‌های پایگاه داده) است
به زبان خیلی ساده: یک سیستم هوشمند که همه کارهایی که روی دیتابیس انجام می‌شود را می‌بیند، ثبت می‌کند و در لحظه هشدار می‌دهد و حتی می‌تواند جلوی کارهای خطرناک را بگیرد
.فکر کنید دیتابیس سازمان شما مثل گاوصندوق پول است. نگهبان، قفل و دوربین مداربسته دارید، اما هنوز نمی‌دانید دقیقاً کی درب گاوصندوق را باز کرده، چه مقدار پول برداشته یا حتی ادمین خودتان دارد چه کار می‌کند.DAM همان دوربین هوشمند + دستگاه ضبط + سیستم تشخیص سرقت برای گاوصندوق شماست


.سال ۱۴۰۲ یکی از پرداخت‌یارهای معروف ایران دچار نشت اطلاعات ۳ میلیون کارت بانکی شد
.علت: یک ادمین پیمانکار سابق با حساب سرویس قدیمی، جدول کارت‌ها را dump کرد
.فایروال و آنتی‌ویروس هیچی نگفتند، چون ترافیک عادی بود
!اگر DAM داشتند، در همان دقایق اول هشدار «حجم بالای SELECT روی جدول حساس» می‌دادند و می‌توانستند جلویش را بگیرند
.نتیجه‌گیری برای مدیران و سازمان‌ه
اامروزه داشتن DAM دیگر یک آپشن لوکس نیست
؛مثل بیمه نامه آتش‌سوزی برای ساختمان است — شاید هیچ وقت آتش‌سوزی نشود، اما اگر شد و بیمه نداشته باشید، همه چیز از دست می‌رود
.در سال ۱۴۰۴–۱۴۰۵ تقریباً همه سازمان‌های زیر مجبورند DAM داشته باشند
:بانک‌ها و مؤسسات مال
یپرداخت‌یارها و فین‌تک‌ه
ابیمه‌ه
ابیمارستان‌ها و مراکز درمانی (داده پزشکی
)شرکت‌های بورسی و سازمان‌های دولتی حسا
سهر شرکتی که داده کد ملی یا کارت بانکی نگهداری می‌کن
داگر هنوز DAM ندارید، همین امروز در برنامه امنیتی سال آینده‌تان قرارش بدهید — قبل از اینکه دیر شود و مجبور شوید با هزینه خیلی هزینه بیشتر و در شرایط بحران آن را راه‌اندازی کنید



!اگر در این موضوع به دنبال مشاور هستید ، ما در خدمت شما خواهیم بود


.#dam #dba #security #linux #database #devops #service

محدودسازی دیدن پردازش‌ها در لینوکس با استفاده از hidepid:


در بسیاری از توزیع‌های لینوکسی، به‌صورت پیش‌فرض تمام کاربران سیستم می‌توانند محتوای دایرکتوری /proc را مشاهده کنند. این یعنی هر کاربر غیر‌privileged قادر است اطلاعات پردازش‌های سایر کاربران—including root—‌را بخواند.

این وضعیت سطح حمله‌ی غیرضروری ایجاد می‌کند: مهاجم با یک حساب low-privilege می‌تواند به اطلاعات حساس دست پیدا کند بدون اینکه دسترسی خاصی داشته باشد.

به‌صورت پیش‌فرض، لینوکس این رفتار را محدود نمی‌کند. اما می‌توان با یک پارامتر ساده در mount، دسترسی کاربران غیر root را به پروسس‌ لیست محدود کرد.

چرا پنهان‌سازی پردازش‌ها (hidepid) مهم است؟ دلایل فنی

جلوگیری از Process Snooping

کاربر عادی می‌تواند با نگاه کردن به /proc/[pid]/cmdline یا /proc/[pid]/environ:

مسیر باینری‌ها

پارامترهای اجرای برنامه

توکن‌ها یا API keys قرارگرفته در پارامترهای خط فرمان

متغیرهای محیطی شامل رمزها، کانکشن‌استرینگ‌ها و secrets

را استخراج کند.

چنین اطلاعاتی برای یک مهاجم داخلی (insider threat) یا نفوذ اولیه بسیار ارزشمند است.

کاهش Attack Surface

کسی که بتواند لیست پردازش‌ها را ببیند، می‌تواند:

نسخه‌ی سرویس‌ها را تشخیص دهد

پورت‌ها و سرویس‌های فعال را حدس بزند

فرآیندهای آسیب‌پذیر یا misconfigured را پیدا کند

هدف را برای privilege escalation انتخاب کند

این دقیقا همان اطلاعاتی است که Nmap محلی ارائه می‌دهد—رایگان و بدون نیاز به دسترسی.

جلوگیری از افشای الگوی رفتار سیستم

اطلاعات مانند:

مصرف CPU

مصرف RAM

زمان اجرا

وضعیت threadها


مهاجم می‌تواند از این‌ها برای side-channel timing attacks استفاده کند.

جلوگیری از جاسوسی کاربران روی کاربران دیگر



برای این کار :


mount -o remount,rw,nosuid,nodev,noexec,relatime,hidepid=2 /proc

توضیح سریع گزینه‌ها:

nosuid → جلوگیری از اجرای فایل‌هایی با SUID

nodev → جلوگیری از ساخت device files

noexec → جلوگیری از اجرای فایل‌ها در این mount

relatime → بهینه‌سازی عملیات IO

hidepid=2 → مخفی‌سازی کامل پروسس‌ها برای کاربران غیر root

اعمال دائمی در فایل /etc/fstab

برای دائمی کردن تنظیم، این خط را اضافه کنید:


proc /proc proc defaults,nosuid,nodev,noexec,relatime,hidepid=2 0 0

یا اگر قبلاً وجود دارد، فقط قسمت options را اصلاح کنید.

نکات تکمیلی و پیامدها

ممکن است روی ابزارهایی که نیاز به خواندن کل لیست پردازش‌ها دارند تأثیر بگذارد:

برخی monitoring agents

ابزارهای مدیریت پردازش مانند htop (برای کاربران معمولی)

برخی ابزارهای امنیتی غیر root

اگر نیاز بود گروه خاصی به /proc دسترسی داشته باشد، می‌توان از پارامتر gid=GROUPID استفاده کرد:


mount -o remount,hidepid=2,gid=250 /proc

و سپس آن گروه را به کاربرهای مجاز assign کرد.

استفاده در سرورهای Enterprise و Cloud استاندارد است

تمام توزیع‌های hardened مانند:

CIS Benchmark

Red Hat STIG

Ubuntu Hardening Guides

این تنظیم را پیشنهاد می‌کنند.



#security #linux #kernel #devops

محدودسازی دیدن پردازش‌ها در لینوکس با استفاده از hidepid:


در بسیاری از توزیع‌های لینوکسی، به‌صورت پیش‌فرض تمام کاربران سیستم می‌توانند محتوای دایرکتوری /proc را مشاهده کنند. این یعنی هر کاربر غیر‌privileged قادر است اطلاعات پردازش‌های سایر کاربران—including root—‌را بخواند.

این وضعیت سطح حمله‌ی غیرضروری ایجاد می‌کند: مهاجم با یک حساب low-privilege می‌تواند به اطلاعات حساس دست پیدا کند بدون اینکه دسترسی خاصی داشته باشد.

به‌صورت پیش‌فرض، لینوکس این رفتار را محدود نمی‌کند. اما می‌توان با یک پارامتر ساده در mount، دسترسی کاربران غیر root را به پروسس‌ لیست محدود کرد.

چرا پنهان‌سازی پردازش‌ها (hidepid) مهم است؟ دلایل فنی

جلوگیری از Process Snooping

کاربر عادی می‌تواند با نگاه کردن به /proc/[pid]/cmdline یا /proc/[pid]/environ:

مسیر باینری‌ها

پارامترهای اجرای برنامه

توکن‌ها یا API keys قرارگرفته در پارامترهای خط فرمان

متغیرهای محیطی شامل رمزها، کانکشن‌استرینگ‌ها و secrets

را استخراج کند.

چنین اطلاعاتی برای یک مهاجم داخلی (insider threat) یا نفوذ اولیه بسیار ارزشمند است.

کاهش Attack Surface

کسی که بتواند لیست پردازش‌ها را ببیند، می‌تواند:

نسخه‌ی سرویس‌ها را تشخیص دهد

پورت‌ها و سرویس‌های فعال را حدس بزند

فرآیندهای آسیب‌پذیر یا misconfigured را پیدا کند

هدف را برای privilege escalation انتخاب کند

این دقیقا همان اطلاعاتی است که Nmap محلی ارائه می‌دهد—رایگان و بدون نیاز به دسترسی.

جلوگیری از افشای الگوی رفتار سیستم

اطلاعات مانند:

مصرف CPU

مصرف RAM

زمان اجرا

وضعیت threadها


مهاجم می‌تواند از این‌ها برای side-channel timing attacks استفاده کند.

جلوگیری از جاسوسی کاربران روی کاربران دیگر



برای این کار :


mount -o remount,rw,nosuid,nodev,noexec,relatime,hidepid=2 /proc

توضیح سریع گزینه‌ها:

nosuid → جلوگیری از اجرای فایل‌هایی با SUID

nodev → جلوگیری از ساخت device files

noexec → جلوگیری از اجرای فایل‌ها در این mount

relatime → بهینه‌سازی عملیات IO

hidepid=2 → مخفی‌سازی کامل پروسس‌ها برای کاربران غیر root

اعمال دائمی در فایل /etc/fstab

برای دائمی کردن تنظیم، این خط را اضافه کنید:


proc /proc proc defaults,nosuid,nodev,noexec,relatime,hidepid=2 0 0

یا اگر قبلاً وجود دارد، فقط قسمت options را اصلاح کنید.

نکات تکمیلی و پیامدها

ممکن است روی ابزارهایی که نیاز به خواندن کل لیست پردازش‌ها دارند تأثیر بگذارد:

برخی monitoring agents

ابزارهای مدیریت پردازش مانند htop (برای کاربران معمولی)

برخی ابزارهای امنیتی غیر root

اگر نیاز بود گروه خاصی به /proc دسترسی داشته باشد، می‌توان از پارامتر gid=GROUPID استفاده کرد:


mount -o remount,hidepid=2,gid=250 /proc

و سپس آن گروه را به کاربرهای مجاز assign کرد.

استفاده در سرورهای Enterprise و Cloud استاندارد است

تمام توزیع‌های hardened مانند:

CIS Benchmark

Red Hat STIG

Ubuntu Hardening Guides

این تنظیم را پیشنهاد می‌کنند.



#security #linux #kernel #devops

محدودسازی دیدن پردازش‌ها در لینوکس با استفاده از hidepid:


در بسیاری از توزیع‌های لینوکسی، به‌صورت پیش‌فرض تمام کاربران سیستم می‌توانند محتوای دایرکتوری /proc را مشاهده کنند.و با دستور top و ps و htop بتوانند . فرایند های سایر کاربران را ببینند . که این از لحاظ امنیتی درست ، نیس
ت . این یعنی هر کاربر غیر‌privileged قادر است اطلاعات پردازش‌های سایر کاربران—including root—‌را بخواند.

این وضعیت سطح حمله‌ی غیرضروری ایجاد می‌کند: مهاجم با یک حساب low-privilege می‌تواند به اطلاعات حساس دست پیدا کند بدون اینکه دسترسی خاصی داشته باشد.

به‌صورت پیش‌فرض، لینوکس این رفتار را محدود نمی‌کند. اما می‌توان با یک پارامتر ساده در mount، دسترسی کاربران غیر root را به پروسس‌ لیست محدود کرد.

چرا پنهان‌سازی پردازش‌ها (hidepid) مهم است؟ دلایل فنی

جلوگیری از Process Snooping

کاربر عادی می‌تواند با نگاه کردن به /proc/[pid]/cmdline یا /proc/[pid]/environ:

مسیر باینری‌ها

پارامترهای اجرای برنامه

توکن‌ها یا API keys قرارگرفته در پارامترهای خط فرمان

متغیرهای محیطی شامل رمزها، کانکشن‌استرینگ‌ها و secrets

را استخراج کند.

چنین اطلاعاتی برای یک مهاجم داخلی (insider threat) یا نفوذ اولیه بسیار ارزشمند است.

کاهش Attack Surface

کسی که بتواند لیست پردازش‌ها را ببیند، می‌تواند:

نسخه‌ی سرویس‌ها را تشخیص دهد

پورت‌ها و سرویس‌های فعال را حدس بزند

فرآیندهای آسیب‌پذیر یا misconfigured را پیدا کند

هدف را برای privilege escalation انتخاب کند

این دقیقا همان اطلاعاتی است که Nmap محلی ارائه می‌دهد—رایگان و بدون نیاز به دسترسی.

جلوگیری از افشای الگوی رفتار سیستم

اطلاعات مانند:

مصرف CPU

مصرف RAM

زمان اجرا

وضعیت threadها


مهاجم می‌تواند از این‌ها برای side-channel timing attacks استفاده کند.

جلوگیری از جاسوسی کاربران روی کاربران دیگر



برای این کار :


mount -o remount,rw,nosuid,nodev,noexec,relatime,hidepid=2 /proc

توضیح سریع گزینه‌ها:

nosuid → جلوگیری از اجرای فایل‌هایی با SUID

nodev → جلوگیری از ساخت device files

noexec → جلوگیری از اجرای فایل‌ها در این mount

relatime → بهینه‌سازی عملیات IO

hidepid=2 → مخفی‌سازی کامل پروسس‌ها برای کاربران غیر root

اعمال دائمی در فایل /etc/fstab

برای دائمی کردن تنظیم، این خط را اضافه کنید:


proc /proc proc defaults,nosuid,nodev,noexec,relatime,hidepid=2 0 0

یا اگر قبلاً وجود دارد، فقط قسمت options را اصلاح کنید.

نکات تکمیلی و پیامدها

ممکن است روی ابزارهایی که نیاز به خواندن کل لیست پردازش‌ها دارند تأثیر بگذارد:

برخی monitoring agents

ابزارهای مدیریت پردازش مانند htop (برای کاربران معمولی)

برخی ابزارهای امنیتی غیر root

اگر نیاز بود گروه خاصی به /proc دسترسی داشته باشد، می‌توان از پارامتر gid=GROUPID استفاده کرد:


mount -o remount,hidepid=2,gid=250 /proc

و سپس آن گروه را به کاربرهای مجاز assign کرد.

استفاده در سرورهای Enterprise و Cloud استاندارد است

تمام توزیع‌های hardened مانند:

CIS Benchmark

Red Hat STIG

Ubuntu Hardening Guides

این تنظیم را پیشنهاد می‌کنند.



#security #linux #kernel #devops