راه رسیدن چیست ؟
ساده است ولی آسان نیست

#alone

Red Hat Recognized as a Leader for Second Consecutive Year in 2025 Gartner® Magic Quadrant™ for Cloud-Native Application PlatformsRed Hat OpenShift is recognized as a Leader in the 2025 Magic Quadrant for Cloud-Native Application Platforms. We believe this reinforces its role as a consistent, open hybrid cloud foundation for enterprise applications, AI workloads and developer innovation. Learn more Destination Linux Podcast: Interview with Sherard Griffin of Red HatSherard Griffin, Red Hat's head of engineering for OpenShift AI, discusses scaling machine learning across hybrid clouds and

via Red Hat Blog https://ift.tt/9DkBdKY

Alireza Ghorbani - Savushun.mp3

⚖شرکت فناپ از سوی وزارت خزانه‌داری آمریکا تحریم شد

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

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

این شرکت در بیانیه‌ای که پنج‌شنبه ۱۶ مرداد منتشر شد، نوشت: «این سیستم یکپارچه، می‌داند چه زمانی پاسخ سریع بدهد و چه زمانی با تفکر عمیق، پاسخ‌هایی در سطح تخصصی ارائه کند.»

نسل پنجم چت‌جی‌پی‌تی در دسترس همه کاربران قرار دارد، با این تفاوت که کاربران اشتراک پلاس از میزان استفاده بیشتری برخوردارند و مشترکین پرو به نسخه‌‌ای با نام GPT‑5 Pro دسترسی دارند که «توانایی استدلال گسترده‌تری برای ارائه پاسخ‌های دقیق‌تر و جامع‌تر» دارد.

اوپن‌ای‌آی اعلام کرد که نسل جدید چت‌جی‌پی‌تی در زمینه کدنویسی، «قدرتمندترین مدل کدنویسی» این شرکت است.
همچنین در زمینه نگارش و خلاقیت، این نسل جدید «توانمندترین توانایی نویسندگی» این شرکت تاکنون است.

سم آلتمن، یکی از بنیانگذاران و مدیر عامل اوپن‌ای‌آی گفت: «‌جی‌پی‌تی-۳ برای من مثل صحبت کردن با یک دانش‌آموز دبیرستانی بود؛ سوالی می‌پرسید، شاید جواب درست بگیرید، شاید چیز دیوانه‌واری پیدا کنید».
‌«جی‌پی‌تی-۴ مثل صحبت کردن با یک دانشجوی دانشگاه بود؛ ‌با جی‌پی‌تی-۵ واقعاً حس می‌کنید دربارهٔ هر موضوعی دارید با یک متخصص در سطح دکترا صحبت می‌کنید».

Security #Observability with #eBPF

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

در مورد Zen Discovery باید گفت که یک ماژول هماهنگ‌سازی کلاستر (Cluster Coordination Module) است که سه وظیفه اصلی دارد:

کشف نودها (Node Discovery)
پیدا کردن سایر نودها و ساختن یک View کامل از کلاستر.

انتخاب Master (Master Election)
تضمین اینکه در هر لحظه فقط یک Master فعال وجود دارد.

انتشار وضعیت کلاستر (Cluster State Publishing)
همگام‌سازی وضعیت بین همه نودها.

ا Zen چیست؟

در Elasticsearch، Zen Discovery مکانیزم اصلی برای:

پیدا کردن نودها (Node Discovery)

هماهنگی بین آن‌ها

انتخاب Master Node

حفظ سازگاری کلاستر

در نسخه‌های قدیمی (تا ۶.x) این مکانیزم Zen1 نام داشت. از Elasticsearch 7.x به بعد، Zen2 معرفی شد.
2. چرا Zen2 ایجاد شد؟

مشکل Zen1:

فرآیند انتخاب Master طولانی و پرخطا بود.

در شرایطی که بخشی از کلاستر قطع می‌شد، Split-Brain (دو Master همزمان) رخ می‌داد.

مدیریت Quorum (اکثریت نودها) سخت و مستعد مشکل بود.

بهبودهای Zen2:

پروتکل هماهنگ‌سازی جدید برای انتخاب سریع‌تر و امن‌تر Master.

جلوگیری قطعی از Split-Brain با استفاده از Voting Configuration.

ا Bootstrap Process شفاف و امن برای شروع کلاستر.

3. معماری Zen2

ا Zen2 در سه بخش اصلی کار می‌کند:

Discovery

پیدا کردن نودها با مکانیزم‌هایی مثل unicast, cloud, یا file-based.

همه نودها یکدیگر را می‌شناسند و وضعیت را به‌روز می‌کنند.

Master Election

ا استفاده از Voting Configuration (مجموعه نودهایی که حق رأی دارند).

ا برای انتخاب Master نیاز به Quorum (اکثریت) است.
مثلا اگر ۳ نود Master-eligible داشته باشیم → حداقل ۲ نود باید توافق کنند.

Cluster State Publishing

ا Master انتخاب‌شده تغییرات Cluster State را به همه نودها ارسال می‌کند.

ا State شامل اطلاعات شاردها، ایندکس‌ها، تنظیمات و وضعیت نودهاست.

مزایای Zen2

ایمنی در برابر Split-Brain
چون هیچ Master جدیدی بدون Quorum شکل نمی‌گیرد.

سرعت بالاتر انتخاب Master
حتی در شرایط قطعی شبکه.

Bootstrap امن
باید لیستی از نودهای Master-eligible اولیه مشخص شود تا کلاستر به‌درستی شروع کند:

cluster.initial_master_nodes:
- node1
- node2
- node3

ا Voting Configuration خودکار
وقتی نود اضافه یا حذف می‌شود، سیستم Voting به‌روزرسانی می‌شود.

ا Zen2 در OpenSearch

ا چون OpenSearch از Elasticsearch 7.10 فورک شده، Zen2 همان ساختار را حفظ کرده.

ا در نسخه‌های جدید OpenSearch، Zen2 با بهبودهای جزئی و ثبات بیشتر نگهداری می‌شود، ولی اساس کار یکسان است.
نکته مهم طراحی

همیشه تعداد نودهای Master-eligible را فرد (Odd Number) انتخاب کنید تا Quorum بهینه باشد.

برای تحمل خرابی، حداقل ۳ نود Master-eligible نیاز دارید.

در محیط‌های Multi-DC باید مراقب Latency و Quorum باشید.


نسخه‌های Zen

ا Zen1 (تا ES 6.x): مکانیزم قدیمی با مشکلات Split-brain و انتخاب Master کند.

ا Zen2 (از ES 7.x و OpenSearch): بازطراحی کامل برای سرعت، پایداری، و جلوگیری کامل از Split-brain.
معماری Zen Discovery (Zen2)

مراحل بوت‌استرپ (Bootstrap Process)

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

باید مشخص کنید کدام نودها Master-eligible هستند:

cluster.initial_master_nodes:
- node1
- node2
- node3

این لیست فقط اولین بار استفاده می‌شود تا Voting Configuration اولیه ساخته شود.

3.2. Node Discovery

Zen از Transport Layer (TCP) استفاده می‌کند تا نودها را پیدا کند.

متدهای رایج:

unicast → با لیست IP/hostname مشخص

Cloud plugins (AWS, Azure, GCP)

File-based seed hosts

پارامتر اصلی:

discovery.seed_hosts:
- node1:9300
- node2:9300

Master Election

الگوریتم انتخاب Master در Zen2 بر اساس Voting Quorum است:

فقط نودهای Master-eligible حق رأی دارند.

یک Master جدید فقط وقتی انتخاب می‌شود که اکثریت (Quorum) در دسترس باشد.

جلوگیری از Split-brain:

اگر Quorum برقرار نباشد، هیچ Master جدیدی انتخاب نمی‌شود.

پارامترهای مهم:

discovery.type: zen
node.master: true
node.data: false

3.4. Cluster State Publishing

وقتی Master انتخاب شد:

تغییرات (مثل اضافه شدن ایندکس یا شارد) در Cluster State ثبت می‌شود.

Cluster State به صورت atomic و versioned به همه نودها ارسال می‌شود.

هر نود فقط آخرین Cluster State معتبر را نگه می‌دارد.


#elasticsearch #log #linux #zen #clustering #elk

@unixmens

کتاب لینوکس برای همه ، نسخه 0.3



پیشنهاد میشود فصل اول اون را که در مورد اقتصاد متن باز و اقتصاد دیجیتال نوشتم را مطالعه فرمایید .


https://www.dropbox.com/s/kv845pwcw0l6uxq/linux_for_all_yashar_esmaildokht_0.3.pdf?dl=0


#linux #yashar_esmaildokht

The engineering teams of Red Hat Trusted Profile Analyzer (TPA) and Trustify decided to experiment with Model Context Protocol (MCP). This article will take you through the challenges we had to face along the way in hopes that our journey can help others attempting something similar.To give you some context, Red Hat Trusted Profile Analyzer (TPA) is a Red Hat product for software bill of materials (SBOM) management—it stores SBOMs and correlates the packages within the SBOMs with known public vulnerabilities. It is based on the upstream project Trustify.At a high level, its architecture is f

via Red Hat Blog https://ift.tt/ZKX0Tf3

This week we announced that for the third consecutive year, Red Hat has been named a Leader in the Gartner® Magic Quadrant™ for Container Management. We’re thrilled by this recognition and believe it represents continued validation of Red Hat OpenShift’s strong execution and strategy for delivering an industry leading application platform across hybrid environments from the data center, to the cloud, and to the edge.Red Hat OpenShift is recognized for its ability to execute and completeness of vision. Red Hat’s investments in OpenShift as a platform for AI workloads, and in building A

via Red Hat Blog https://ift.tt/UDRqFGf

Red Hat Enterprise Linux (RHEL) has a storied history, standing at the intersection of our customers, communities and partners, helping each achieve their goals while answering key end user needs, from enterprise-grade development practices and system security enhancements to a stronger software supply chain and end-to-end support backed by Red Hat’s unique expertise.. In 2021 we announced no-cost RHEL options for developers, in certain use cases, which include our proactive analytic capability, Red Hat Insights. Since then, we have listened to and learned from individuals and organizations

via Red Hat Blog https://ift.tt/qVMh6j1

محصول azure devops برای git repository از معماری استفاده میکنه . که بهینه نیست . azure devops ریپوزیتوری را روی دیتابیس ذخیره میکنه .
که به نظر من منطقی نیست .
در اینجا دلایل را بررسی میکنیم . نکته ای هم داشتید بگید .

1. کاهش کارایی و Latency بالا
عملیات Git (مثل clone, fetch, push) به شدت به I/O سریع نیاز دارد.
خواندن و نوشتن اشیای Git (blobs, trees, commits) در دیتابیس به جای سیستم فایل باعث افزایش overhead کوئری‌ها و تراکنش‌ها می‌شود.
دیتابیس‌های رابطه‌ای برای داده‌های باینری کوچک بهینه نیستند و باعث افزایش زمان پاسخ (latency) می‌شوند.
چندین لایه abstraction و parsing (مثلاً تبدیل داده‌ها به قالب دیتابیسی) باعث می‌شود عملکرد به نسبت سیستم فایل مستقیم پایین‌تر باشد.
2. وابستگی شدید به Availability و سلامت دیتابیس
دیتابیس به عنوان Single Point of Failure (نقطه شکست واحد) عمل می‌کند. اگر دیتابیس Down شود، دسترسی به تمام ریپوزیتوری‌ها قطع می‌شود.
حتی با وجود کلاسترینگ و Replica، Failover چند ثانیه یا بیشتر طول می‌کشد که در آن زمان کاربران نمی‌توانند به ریپوزیتوری‌ها دسترسی داشته باشند.
پیچیدگی مدیریت Transaction Logها و replication می‌تواند باعث کندی یا مشکلات synchronization شود.
3. محدودیت‌های مقیاس‌پذیری
دیتابیس‌های SQL رابطه‌ای معمولاً برای بارهای بسیار بزرگ و توزیع‌شده (مثلاً چند هزار کاربر همزمان) محدودیت دارند.
شاردینگ و توزیع داده‌های Git در دیتابیس پیچیده‌تر و سخت‌تر از سیستم فایل است.
در حجم‌های بسیار بالا، کوئری‌های پیچیده و تراکنش‌های زیاد باعث ایجاد bottleneck در دیتابیس می‌شوند.
4. پیچیدگی Backup و Restore
اگرچه گرفتن Backup یکپارچه برای کل سرویس ساده‌تر است، اما بازیابی فقط یک ریپوزیتوری یا Branch خاص در دیتابیس سخت‌تر است.
دیتابیس ممکن است به دلیل حجم داده‌های باینری و حجم بالا، عملیات Backup را سنگین و زمان‌بر کند.
بازیابی ناقص ممکن است باعث ایجاد inconsistency در ریپوزیتوری‌ها شود.
5. پیچیدگی Transaction Management
دیتابیس‌های رابطه‌ای برای مدیریت تراکنش‌های همزمان ساخته شده‌اند، اما عملیات Git مثل push یا merge شامل نوشتن‌های پراکنده و نامنظم است که مدیریت آنها در دیتابیس پیچیده است.
تراکنش‌های طولانی و همزمان ممکن است منجر به deadlock یا contention بالا در دیتابیس شوند.
6. عدم تطابق کامل با مدل توزیع‌شده Git
ا Git ذاتاً یک سیستم Distributed است که هر کلاینت نسخه کامل ریپوزیتوری را دارد و می‌تواند مستقل کار کند.
ذخیره‌سازی متمرکز در دیتابیس باعث می‌شود کارایی عملیات توزیع‌شده کاهش یابد و برخی مزایای Git مانند کار آفلاین کامل کمتر شود.
هر عملیات نیاز به ارتباط و اعتبارسنجی با دیتابیس مرکزی دارد.
7. افزایش بار روی شبکه و منابع سرور
درخواست‌های مکرر به دیتابیس برای خواندن و نوشتن داده‌های Git، باعث افزایش ترافیک شبکه بین سرورهای اپلیکیشن و دیتابیس می‌شود.
بار زیاد روی دیتابیس نیازمند منابع سخت‌افزاری بالاتر (CPU، RAM، Disk I/O) است که هزینه نگهداری را افزایش می‌دهد.

. پیچیدگی در به‌روزرسانی و Migration
هر تغییر در ساختار داده‌های دیتابیس یا به‌روزرسانی نسخه Azure DevOps، نیازمند مایگریشن‌های پیچیده روی داده‌های Git ذخیره شده است.
ریسک خطا در مایگریشن می‌تواند باعث آسیب به ریپوزیتوری‌ها یا از دست رفتن داده‌ها شود.
9. چالش‌های امنیتی و کنترل دسترسی
با اینکه دیتابیس امکان کنترل دسترسی دقیق‌تر می‌دهد، اما خطا در پیکربندی مجوزها یا آسیب‌پذیری‌های دیتابیس می‌تواند کل ریپوزیتوری‌ها را در معرض خطر قرار دهد.
نیاز به محافظت و رمزنگاری قوی برای داده‌های حساس داخل دیتابیس وجود دارد.

10. عدم تطابق با عملیات بهینه Git
ا Git با طراحی روی سیستم فایل و استفاده از ساختارهای باینری و فشرده (pack files) برای ذخیره اشیاء، بهینه‌سازی‌های خاصی انجام می‌دهد.
ذخیره داده‌ها در دیتابیس رابطه‌ای باعث می‌شود که این ساختارهای بهینه‌شده قابل استفاده نباشند و به صورت نرمالایز شده یا بلاک‌های کوچک‌تر ذخیره شوند که به کارایی ضربه می‌زند.

11. افزایش پیچیدگی مدیریت همزمانی (Concurrency Control)
در یک سیستم توزیع شده، هزاران کاربر ممکن است همزمان روی یک ریپوزیتوری کار کنند.
دیتابیس باید توانایی مدیریت تراکنش‌های همزمان پیچیده را داشته باشد که باعث افزایش پیچیدگی و احتمال بروز مشکلات همزمانی مانند lock contention می‌شود.
12. مشکلات مرتبط با عملیات Garbage Collection و Cleanup
اGit دارای مکانیزمی است به نام garbage collection برای پاکسازی داده‌های بلااستفاده (dangling commits, blobs) که روی سیستم فایل سریع و مستقیم انجام می‌شود.
پیاده‌سازی مشابه در دیتابیس به دلیل پیچیدگی‌های تراکنش و ایزوله‌سازی داده‌ها دشوارتر است و ممکن است باعث افزایش حجم دیتابیس و کاهش عملکرد شود.
13. چالش‌های مربوط به مقیاس‌گذاری افقی (Horizontal Scaling)
سیستم فایل به راحتی می‌تواند در محیط‌های توزیع شده با استفاده از ابزارهایی مانند NFS یا GlusterFS توزیع شود.
دیتابیس‌های رابطه‌ای معمولاً به سختی و با پیچیدگی زیاد مقیاس‌پذیر افقی می‌شوند که برای بارهای سنگین Git می‌تواند محدودیت ایجاد کند.

14. پیچیدگی در اشکال‌زدایی (Debugging) و نگهداری
در صورت بروز مشکل در داده‌های Git، تشخیص و رفع خطا در دیتابیس پیچیده‌تر از فایل‌های ساده Git است.
اشکال‌زدایی شامل بررسی تراکنش‌ها، لاگ‌های دیتابیس و تطابق داده‌ها در جداول مختلف است که نیازمند دانش تخصصی دیتابیس و Git به صورت همزمان است.
15. افزایش هزینه‌های زیرساختی
دیتابیس‌های قدرتمند با سخت‌افزار مناسب برای تحمل بارهای سنگین Git نیاز به سرمایه‌گذاری بیشتری دارند.
هزینه‌های نگهداری، لایسنس‌ها (اگر SQL Server باشد) و نیروی انسانی متخصص برای مدیریت دیتابیس زیاد است.
16. وابستگی به تکنولوژی‌های خاص
این روش باعث می‌شود سازمان به شدت وابسته به استک تکنولوژی خاصی (مانند SQL Server و ساختار Azure DevOps) شود و مهاجرت به پلتفرم یا مدل دیگر دشوار شود.
این Vendor Lock-in ممکن است در آینده محدودیت‌های استراتژیک ایجاد کند.



17. ریسک بروز Inconsistency داده‌ها
در محیط‌هایی که تراکنش‌های زیاد و همزمان انجام می‌شود، خطر بروز ناسازگاری بین جداول یا رکوردهای دیتابیس وجود دارد که منجر به corrupted repository می‌شود.
بازیابی این ناسازگاری‌ها معمولاً پیچیده و پرهزینه است.
18. مشکلات مربوط به به‌روزرسانی همزمان Branch ها
در Git معمولی، Branchها و commitها مستقل و توزیع‌شده هستند و تغییرات به صورت لوکال روی کلاینت انجام می‌شود.
در سیستم دیتابیس‌محور، به‌روزرسانی‌های همزمان روی Branchها ممکن است نیاز به قفل‌های دیتابیسی داشته باشد که باعث افزایش انتظار (wait times) و کاهش throughput می‌شود.

#azure #devops

Coming out of The Crash, we understood the problem more deeply—because we’d lived it.We had stretched a working bot to cover a new use case and data source—and watched it strain under the weight of unclear expectations, sprawling content, and retrieval blind spots. But those hard lessons gave us the clarity to regroup. We didn’t need to start over. We needed to design with intention and sharper focus.This phase is where we stop assuming, start scoping tightly, and make intentional choices that reflect the realities of our data, users, and goals.AI challenge: Construct a chatbot that ca

via Red Hat Blog https://ift.tt/OnlIiDF

این چه استدلالی هست که دارید انجام میدید . خود کلود فلر از waf های اپن سورس و کاستوم شده خودش استفاده میکند . در مورد پروژه modsecurity , مطالعه ای داشته باشید . که الان تحت مدیریت و سرویس دهی owasp هست .
Owasp
هم که معرف حضور هست .

بررسی کنید owasp core rule set را

برید OWASP Coraza WAF را بررسی کنید . که فورکی از modsecurity است .
خود وف f5 هم بیسش modsecurity هست

وف naxsi را هم بررسی کنید
https://coraza.io/

https://coreruleset.org/

#security #waf

unixmens

https://t.iss.one/unixmens

The World Economic Forum has identified upskilling as an important initiative for organizations over the next decade, predicting that at least 50% of the current workforce will lack the skills they need to keep pace with industry changes and demands. To remain competitive, organizations must embrace continuous, flexible learning models. Upskilling and cross-skilling initiatives are crucial for both talent retention and for equipping teams with the necessary expertise to navigate an AI-driven future. By fostering a culture of collective intelligence and supporting internal subject-matter expert

via Red Hat Blog https://ift.tt/GwcoLqH