what is systemd ?


#systemd #sysvinit #init #linux #service #upstart #initng #article

https://t.me/unixmens

داده ها عنصر اصلی . دنیای امروز هستند . از داده ها و kpi ها در دواپس گرفته تا مارکتینگ مبتنی بر داده یا data driven . در همه اینها داده ها حرف میزنند .

در این بین سازمان ها به این راحتی سمت داده نمیروند . و در این maturity یا بلوغ مرتبه و مرحله هایی را داریم تا به data driven برسیم .

(خوشحالم در جهانی زندگی میکنم . که فکت و آمار و تحلیل و داده ها اهمیت دارند -- ایران هم میرسه به این روند . نگران نباشید . ما در گذر هستیم . و البته در بسیاری از جاها هم رسیدن و خوشحال بودم من نیز نقشی در این روند داده محور شدن داشتم . )

خب عزیزان گفتیم مراحلی برای رسیدن و بلوغی برای رسیدن آن وجود دارد :

برای داده محور شدن باید 5 مرحله را طی کرد:

1- مقاومت در برابر داده ها:
در ابتدا سازمان در برابر داده ها مقاومت می کند. اغلب می گویند: "ما همیش ه این کار را انجام داده ایم" - این یک امتناع دردناک هر یک از مدیران اجرایی است.

2- کنجکاوری در مورد داده ها:
در این مرحله سازمان از وجود داده ها اطلاع دارد و می داند که داده ها دارای ارزش ذاتی هستند ، حتی اگر ارزش آنها واضح نباشد. در این سازمان ها روی جمع آوری داده ها تمرکز می کنند و اغلب از ارزش بالقوه داده ها از طریق بررسی تامین کنندگان و سیستم های سازمانی آگاه می شوند

3- آگاهی از داده ها:
در مرحله آگاهی استخراج هر نوع ارز شی از داده ها رخ می دهد. شرکتهای آگاه در زمینه داده ها روی تجزیه و تحلیل تمرکز می کنند.

4- درک داده ها
در این مرحله سازمان متوجه می شود که داده ها صرفا دارای ارزش تاکتیکی نیستند؛ داده ها می توانند یک دارایی استراتژیک باشند. برای توسعه این ارزش استراتژیک ، سازمان بجای چیستی توجه خود را به چرایی معطوف می کند و به سمت توسعه بینش و بصیرت سوق می دهد.

5- داده محوری
سازمان های داده محور، تجزیه و تحلیل داده ها و بینش ها را برای پاسخ به سؤال "Waht Next" بکار می گیرند. سازمان هایی در این مرحله، در هر سطح و در هر قسمت از سازمان، داده ها را به عنوان یک منبع استراتژیک می شناسند.

#data #datadriven #data_driven #data_aware #data_resistant #data_guided
#devops #linux #culture #organization
https://t.me/unixmens
unixmens

https://markaicode.com/bitcoin-cold-storage-air-gapped-wallet-setup/

link
#wallet #linux #service #bitcoin 💳 #cryptocurrency #storage

@unixmens

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



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


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


#linux #yashar_esmaildokht

This image is a creative and symbolic representation of the importance of SQL (Structured Query Language) across various tech roles. It’s styled like the Knights of the Round Table, where each character represents a different profession in the tech industry. They all have their swords pointed towards the center, symbolizing SQL as a shared, unifying tool or "power" they all rely on.

Here’s a breakdown of what each character symbolizes:
🔁 Roles Around the Table:

Software Engineer

Data Analyst

BI Analyst (Business Intelligence Analyst)

Database Administrator

Cybersecurity Analyst

Full Stack Developer

AI/ML Engineer

ETL Developer

Cloud Engineer

Data Engineer

Data Scientist

💡 Meaning and Message:

Central Role of SQL: Despite the diversity in roles—from data-centric ones (like Data Analyst, Data Scientist) to infrastructure roles (like Cloud Engineer, Cybersecurity Analyst)—SQL is portrayed as a foundational skill that all of them must wield.

Unity Through Data: The image shows that in today’s data-driven world, SQL is not just for database admins—everyone in tech needs to know it, at least to a basic level.

Visual Metaphor: The round table evokes equality and cooperation, symbolizing how all these roles collaborate with a common language: SQL.

🧠 Deeper Insight:

Symbolic Leadership: The person labeled Software Engineer is placed centrally (like a king), which could imply the pivotal or initiating role of software engineering in tech development, though it’s arguable depending on context.

Shared Knowledge Culture: It’s a humorous but poignant reminder that, like a sword for a knight, SQL is a key tool in the arsenal of nearly every modern tech professional.

#sql #devops #linux #database #data #dba

https://t.me/unixmens

PacketFence is an open-source Network Access Control (NAC) solution that provides a comprehensive set of features for managing network access. It supports various functionalities such as captive portals for user registration, centralized management for wired and wireless networks, and robust BYOD (Bring Your Own Device) capabilities. The latest version, PacketFence 14.1, was released on February 18, 2025, and includes numerous improvements and new features aimed at enhancing network security and management.

Recent Updates and Features

Version 14.1: This release includes enhancements to existing features and introduces new functionalities that improve user experience and security management.
Zero Effort NAC (ZEN): A preconfigured version of PacketFence designed for rapid deployment, making it easier for organizations to implement NAC solutions without extensive setup.
Integration Capabilities: PacketFence continues to evolve by integrating with various network devices and security solutions, allowing for better management of diverse network environments.

Network Access Control (NAC) Trends for 2025

Market Growth and Trends
The Network Access Control market is expected to experience significant growth, with projections indicating a compound annual growth rate (CAGR) of approximately 45.9% from 2025 to 2029. This growth is driven by several factors:

Increased Cybersecurity Threats: As cyberattacks become more sophisticated, organizations are prioritizing NAC solutions to secure their networks.
Adoption of BYOD Policies: The rise of personal devices in the workplace necessitates robust NAC solutions to manage and secure these devices effectively.
Integration with IoT and Cloud Services: The growing number of IoT devices and the shift towards cloud-based services are pushing the demand for advanced NAC solutions that can handle diverse and dynamic network environments.

Key Features and Innovations

AI and Machine Learning: The integration of AI and machine learning in NAC solutions is enhancing threat detection and response capabilities, allowing for more proactive security measures.
Regulatory Compliance: Stricter data privacy regulations, such as GDPR, are driving the need for secure network access control solutions, influencing product development and market strategies.
Market Segmentation: The NAC market is segmented by components (hardware, software, services), deployment models (on-premises, cloud), and enterprise sizes, with a notable demand from small and medium enterprises (SMEs) due to increasing cyber threats.


#security #net #network #linux #nac #packetfense

https://t.me/unixmens

unixmens

KubeVirt is an innovative tool designed to manage the lifecycle and scheduling of Virtual Machines (VMs) within Kubernetes clusters. It aims to bridge the gap between traditional virtualization and modern container orchestration, allowing for a hybrid environment where both VMs and containers can coexist. Here’s a detailed overview of KubeVirt, its comparisons with other projects, and its use cases.
Overview of KubeVirt
KubeVirt extends Kubernetes by enabling it to manage VMs alongside containerized applications. This integration allows organizations to leverage Kubernetes' orchestration capabilities for both types of workloads, providing a unified platform for managing resources in a datacenter or cloud environment.
KubeVirt vs. Other Projects
Kubernetes:
Kubernetes is primarily focused on automating the deployment and management of containerized applications.
KubeVirt acts as an add-on to Kubernetes, enabling it to manage VMs, thus enhancing Kubernetes' capabilities.
OpenStack:
OpenStack is a comprehensive IaaS platform that includes various components for compute, networking, and storage.
KubeVirt is a single component that specializes in VM scheduling and lifecycle management, relying on other systems for networking and storage.
Nova:
Nova is the VM scheduling component of OpenStack, supporting multiple virtualization technologies.
KubeVirt focuses specifically on KVM managed by Libvirt, allowing for a more streamlined and efficient management of VMs.
oVirt:
oVirt is a virtualization management platform that emphasizes high availability and infrastructure-level guarantees.
KubeVirt aims to provide similar consistency guarantees while also offering the scalability needed for cloud environments.
Libvirt:
Libvirt is a toolkit for managing VMs on a local node, providing lifecycle management and network/storage interface management.
KubeVirt utilizes Libvirt for managing KVM VMs, leveraging its existing capabilities rather than reinventing the wheel.
AWS EC2 and Google GCE:
Both EC2 and GCE are proprietary cloud services that lock users into specific pricing models and infrastructures.
KubeVirt is an open-source project that focuses solely on VM scheduling, providing flexibility and independence from specific cloud providers.
Use Cases
KubeVirt is designed to address several key use cases:
Cloud Virtualization:
It provides a feature set for managing VM scale-out, similar to the abstractions offered by cloud IaaS APIs.
Datacenter Virtualization:
KubeVirt aims to deliver strong infrastructure consistency guarantees, making it suitable for managing large numbers of VMs.
Kubernetes Trusted Workloads:
It allows for the execution of virtualized workloads that require the security guarantees provided by a hypervisor.
Combining Container and Virtualized Workloads:
KubeVirt enables the scheduling of both containerized and virtualized workloads on the same Kubernetes cluster, facilitating a more integrated approach to resource management.
Conclusion
KubeVirt is positioned as a powerful tool for organizations looking to manage VMs within a Kubernetes environment. By focusing on KVM and leveraging existing technologies like Libvirt, KubeVirt aims to provide a robust solution for both cloud and datacenter virtualization, while also supporting the coexistence of containerized applications. Its open-source nature and flexibility make it an attractive option for IaaS providers and enterprises alike.


#ovirt #kubevirt #linux #k8s #kubernetes #lcm #virtualization


https://t.me/unixmens

KubeVirt is an innovative tool designed to manage the lifecycle and scheduling of Virtual Machines (VMs) within Kubernetes clusters. It aims to bridge the gap between traditional virtualization and modern container orchestration, allowing for a hybrid environment where both VMs and containers can coexist. Here’s a detailed overview of KubeVirt, its comparisons with other projects, and its use cases.
Overview of KubeVirt
KubeVirt extends Kubernetes by enabling it to manage VMs alongside containerized applications. This integration allows organizations to leverage Kubernetes' orchestration capabilities for both types of workloads, providing a unified platform for managing resources in a datacenter or cloud environment.
KubeVirt vs. Other Projects
Kubernetes:
Kubernetes is primarily focused on automating the deployment and management of containerized applications.
KubeVirt acts as an add-on to Kubernetes, enabling it to manage VMs, thus enhancing Kubernetes' capabilities.
OpenStack:
OpenStack is a comprehensive IaaS platform that includes various components for compute, networking, and storage.
KubeVirt is a single component that specializes in VM scheduling and lifecycle management, relying on other systems for networking and storage.
Nova:
Nova is the VM scheduling component of OpenStack, supporting multiple virtualization technologies.
KubeVirt focuses specifically on KVM managed by Libvirt, allowing for a more streamlined and efficient management of VMs.
oVirt:
oVirt is a virtualization management platform that emphasizes high availability and infrastructure-level guarantees.
KubeVirt aims to provide similar consistency guarantees while also offering the scalability needed for cloud environments.
Libvirt:
Libvirt is a toolkit for managing VMs on a local node, providing lifecycle management and network/storage interface management.
KubeVirt utilizes Libvirt for managing KVM VMs, leveraging its existing capabilities rather than reinventing the wheel.
AWS EC2 and Google GCE:
Both EC2 and GCE are proprietary cloud services that lock users into specific pricing models and infrastructures.
KubeVirt is an open-source project that focuses solely on VM scheduling, providing flexibility and independence from specific cloud providers.
Use Cases
KubeVirt is designed to address several key use cases:
Cloud Virtualization:
It provides a feature set for managing VM scale-out, similar to the abstractions offered by cloud IaaS APIs.
Datacenter Virtualization:
KubeVirt aims to deliver strong infrastructure consistency guarantees, making it suitable for managing large numbers of VMs.
Kubernetes Trusted Workloads:
It allows for the execution of virtualized workloads that require the security guarantees provided by a hypervisor.
Combining Container and Virtualized Workloads:
KubeVirt enables the scheduling of both containerized and virtualized workloads on the same Kubernetes cluster, facilitating a more integrated approach to resource management.
Conclusion
KubeVirt is positioned as a powerful tool for organizations looking to manage VMs within a Kubernetes environment. By focusing on KVM and leveraging existing technologies like Libvirt, KubeVirt aims to provide a robust solution for both cloud and datacenter virtualization, while also supporting the coexistence of containerized applications. Its open-source nature and flexibility make it an attractive option for IaaS providers and enterprises alike.


#kubevirt #linux #k8s #kubernetes #vm #virtualization

https://t.me/unixmens

ZFS (Zettabyte File System) offers several RAID-like configurations, including ZRAID and DRAID, which provide different advantages for data storage and redundancy.
ZRAID
ZRAID is a term often used to describe the traditional RAID configurations available in ZFS, such as RAID-Z1, RAID-Z2, and RAID-Z3. These configurations allow for:
Data Redundancy: Protects against data loss due to disk failures. RAID-Z1 can tolerate one disk failure, RAID-Z2 can tolerate two, and RAID-Z3 can tolerate three.
Efficient Storage: Unlike traditional RAID, ZFS uses variable block sizes and can efficiently utilize disk space.
Self-Healing: ZFS checksums all data and can automatically repair corrupted data using redundant copies.
DRAID
DRAID (Distributed RAID) is a newer feature in ZFS that enhances the traditional RAID configurations by distributing parity and data across all disks in a pool. Key benefits include:
Improved Performance: DRAID can offer better performance during rebuilds and normal operations by distributing the workload across all disks.
Scalability: It allows for easier expansion of storage pools by adding new disks without significant performance degradation.
Reduced Rebuild Times: Since data and parity are distributed, the time taken to rebuild a failed disk is generally shorter compared to traditional RAID configurations.

ZRAID (RAID-Z)

ZRAID encompasses the various RAID-Z configurations in ZFS, which include:

RAID-Z1:
Configuration: Similar to RAID 5, it uses one parity block.
Fault Tolerance: Can withstand one disk failure.
Use Case: Suitable for environments where data redundancy is important but cost needs to be managed.

RAID-Z2:
Configuration: Similar to RAID 6, it uses two parity blocks.
Fault Tolerance: Can withstand two disk failures.
Use Case: Ideal for critical data storage where higher redundancy is required.

RAID-Z3:
Configuration: Uses three parity blocks.
Fault Tolerance: Can withstand three disk failures.
Use Case: Best for environments with very high data availability requirements.

Advantages of ZRAID:

Data Integrity: ZFS checksums all data, ensuring that any corruption can be detected and repaired.
Snapshots and Clones: ZFS allows for efficient snapshots and clones, which can be useful for backups and testing.
Compression: ZFS supports data compression, which can save space and improve performance.

Considerations for ZRAID:

Rebuild Times: In traditional RAID configurations, rebuilding a failed disk can take a significant amount of time, during which the system may be vulnerable to additional failures.
Performance: Write performance can be impacted due to the overhead of calculating parity.

DRAID (Distributed RAID)

DRAID is a more recent addition to ZFS, designed to address some of the limitations of traditional RAID configurations.
Key Features of DRAID:

Distributed Parity: Unlike ZRAID, where parity is concentrated, DRAID distributes parity across all disks, which can lead to improved performance.
Dynamic Resiliency: DRAID can adapt to changes in the storage pool, such as adding or removing disks, without significant performance penalties.
Faster Rebuilds: The distributed nature of DRAID allows for faster rebuild times since the workload is shared across multiple disks.

Advantages of DRAID:

Performance: DRAID can provide better read and write performance, especially in environments with high I/O demands.
Scalability: It is easier to scale storage by adding disks, as the system can dynamically adjust to the new configuration.



Conclusion


Both ZRAID and DRAID provide robust solutions for data storage, with ZRAID being more traditional and widely used, while DRAID offers modern enhancements for performance and scalability. The choice between them depends on specific use cases, performance requirements, and the desired level of redundancy.



#zfs #raid #linux #storage #kernel #data

https://t.me/unixmens

ماژول stream در Nginx یکی از ماژول‌های قدرتمند و در عین حال کمتر شناخته‌شده است که برای پراکسی کردن (proxying) ترافیک لایه‌ی چهارم (TCP/UDP) به کار می‌رود. برخلاف ماژول http که برای سرویس‌های لایه‌ی هفتم طراحی شده، ماژول stream مخصوص لایه‌ی انتقال است (لایه چهارم در مدل OSI).
🎯 کاربرد اصلی Stream Module

ا Load Balancing برای دیتابیس‌ها (مثل MySQL, PostgreSQL)

ا TCP-level reverse proxy (مثلاً برای SSH، Redis، MQTT)

پراکسی کردن ترافیک UDP (مثل DNS، VoIP)

ساخت TLS passthrough proxy (برخلاف termination در http)

استفاده به عنوان ورودی برای SSL offloading

🧩 فعال‌سازی ماژول Stream

ماژول stream به‌طور پیش‌فرض در نسخه‌های pre-built رسمی Nginx فعال نیست. برای استفاده از آن باید:

از نسخه‌ی Nginx Plus استفاده کنید
یا

از سورس با --with-stream کامپایل کنید

بررسی فعال بودن:

nginx -V 2>&1 | grep -- --with-stream

📜 نمونه پیکربندی
✅ پراکسی TCP ساده

stream {
    upstream backend {
        server 192.168.1.10:3306;
        server 192.168.1.11:3306;
    }

    server {
        listen 3306;
        proxy_pass backend;
    }
}

✅ پراکسی UDP

stream {
    server {
        listen 53 udp;
        proxy_pass 8.8.8.8:53;
    }
}

ا ✅ SSL passthrough برای mail server

stream {
    map $ssl_preread_server_name $backend {
        mail.example.com   mail_backend:993;
        default            default_backend:993;
    }

    server {
        listen 993;
        proxy_pass $backend;
        ssl_preread on;
    }
}

نکته: قابلیت ssl_preread در stream شبیه SNI sniffing در TLS است.

⚙️ دستورات مهم Stream Module

proxy_pass  تعریف مقصد
upstream  تعریف سرورهای backend
listen  تعریف پورت/پروتکل ورودی
ssl_preread  فعال‌سازی خواندن SNI بدون decryption
proxy_timeout  تایم‌اوت بین Nginx و سرور مقصد
proxy_connect_timeout  تایم‌اوت برای اتصال اولیه
proxy_protocol  فعال‌سازی PROXY protocol (برای انتقال IP کلاینت)

📌 محدودیت‌ها


امکان دستکاری محتوا وجود ندارد (چون لایه ۴ است)

نمی‌توان از rewrite, headers, gzip, cache استفاده کرد

لاگ‌گیری محدود به connection-level است، نه request-level

🧠 جمع‌بندی

ماژول stream در Nginx به شما اجازه می‌دهد به‌جای لایه‌ی اپلیکیشن (HTTP)، روی لایه‌ی انتقال (TCP/UDP) تمرکز کنید و خدماتی مانند load balancing، SSL passthrough، reverse proxy برای سرویس‌های غیروبی ارائه دهید. این قابلیت برای طراحی زیرساخت‌های حرفه‌ای بسیار حیاتی است، به‌خصوص در محیط‌هایی مثل:

ا Kubernetes ingress برای TCP/UDP

انتقال ترافیک دیتابیس‌ها

پیاده‌سازی reverse proxy با امنیت بالا

🎯 امکانات ماژول stream در NGINX

پشتیبانی از TCP و UDP Reverse Proxy

ا Load Balancing برای TCP/UDP با الگوریتم‌های:

ا round-robin (پیش‌فرض)

ا least_conn (در نسخه Plus)

ا hash-based routing

پشتیبانی از Health Checks (در نسخه NGINX Plus)

ا SSL Passthrough با قابلیت ssl_preread

ا SNI-based Routing بدون decrypt کردن TLS

پشتیبانی از PROXY Protocol (برای انتقال IP کلاینت)

کنترل دسترسی با allow / deny

لاگ‌گیری سفارشی برای TCP/UDP connections

تنظیم Timeoutهای مختلف:

proxy_timeout

proxy_connect_timeout

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

تعریف upstream blocks برای backend سرورها

🧠 کاربردهای ماژول stream

پراکسی و Load Balancing برای دیتابیس‌ها (PostgreSQL, MySQL, Redis)

ا SSL passthrough برای HTTPS با SNI routing

پراکسی سرویس‌های VoIP و UDP-based (مانند RTP، SIP)

ا Reverse Proxy برای DNS (TCP و UDP)

پراکسی و مسیردهی ترافیک mail servers (IMAP, POP3, SMTP)

ا Bastion SSH Host برای هدایت کاربران SSH به سرورهای مختلف

پراکسی برای پروتکل‌های خاص TCP مانند MQTT، FIX، یا custom protocols

استفاده در Kubernetes Ingress Controller برای TCP/UDP Services




#nginx #stream #linux #network

https://t.me/unixmens

در واقع Mail Gateway یا دروازه ایمیل، سیستمی است که به عنوان نقطه ورودی و خروجی برای ایمیل‌ها در یک سازمان عمل می‌کند. این سیستم می‌تواند به عنوان یک لایه امنیتی، مدیریتی و کنترلی در تبادل ایمیل‌ها بین سازمان و دنیای خارج عمل کند.

▎ضرورت وجود Mail Gateway در سازمان‌ها:

1. امنیت: Mail Gateway می‌تواند به شناسایی و مسدود کردن ایمیل‌های مخرب، ویروس‌ها و اسپم‌ها کمک کند. این امر به کاهش خطرات امنیتی ناشی از حملات فیشینگ و بدافزارها کمک می‌کند.

2. مدیریت ترافیک ایمیل: با استفاده از Mail Gateway، سازمان‌ها می‌توانند ترافیک ایمیل خود را کنترل کنند و از بارگذاری بیش از حد سرورهای ایمیل جلوگیری کنند.

3. سیاست‌های دسترسی: این سیستم امکان پیاده‌سازی سیاست‌های خاصی را برای ارسال و دریافت ایمیل فراهم می‌کند. به عنوان مثال، می‌توان محدودیت‌هایی برای ارسال ایمیل به دامنه‌های خاص یا سایز فایل‌های پیوست شده تعیین کرد.

4. حفظ حریم خصوصی و انطباق با قوانین: Mail Gateway می‌تواند به سازمان‌ها کمک کند تا با قوانین مربوط به حفظ حریم خصوصی و حفاظت از داده‌ها (مانند GDPR) مطابقت داشته باشند.

5. گزارش‌گیری و آنالیز: این سیستم قابلیت تولید گزارشات دقیق در مورد ترافیک ایمیل، تهدیدات امنیتی و رفتار کاربران را دارد که می‌تواند به تصمیم‌گیری‌های مدیریتی کمک کند.

▎مزایای Mail Gateway:

• کاهش خطرات امنیتی: با فیلتر کردن ایمیل‌های مخرب، خطرات امنیتی کاهش می‌یابد.
• بهبود کارایی: با مدیریت بهتر ترافیک ایمیل، کارایی کلی سیستم‌های ارتباطی سازمان افزایش می‌یابد.
• قابلیت سفارشی‌سازی: سازمان‌ها می‌توانند سیاست‌های خاص خود را برای مدیریت ایمیل‌ها پیاده‌سازی کنند.
• حفاظت از داده‌ها: با رمزگذاری ایمیل‌ها و اطمینان از ارسال امن اطلاعات حساس، حفاظت از داده‌ها تضمین می‌شود.

در نهایت، استفاده از Mail Gateway به سازمان‌ها کمک می‌کند تا ارتباطات ایمیلی خود را امن‌تر، کارآمدتر و قابل مدیریت‌تر کنند.

#mail #gateway #security #dlp #linux #proxmox
@unixmens

کتاب مرجع دواپس نسخه 0.5 را بصورت آزاد منتشر کردم . تقدیم عزیزان

کتاب مرجع Devops
نویسنده : مهندس یاشار اسمعیل دخت

#devops #book #yashar_esmaildokht #linux #k8s #kubernetes #cloud #team #technology

https://t.me/unixmens

آیا با privoxy آشنا هستید و کار بردهای آن را میدانید ؟


#security #privoxy #proxy #net #devops #linux

Firewalls are essential components in cybersecurity that control incoming and outgoing network traffic based on predetermined security rules. Firewalls can be categorized in several ways based on how they operate and where they are deployed.

Here’s a breakdown of types of firewalls:

🔹 1. Packet-Filtering Firewalls

How it works: Inspects packets (headers) and allows or blocks them based on IP addresses, ports, or protocols.

Layer: Network Layer (Layer 3)

Pros: Fast and simple

Cons: Doesn’t inspect payloads; limited protection against complex threats

🔹 2. Stateful Inspection Firewalls

How it works: Tracks the state of active connections and makes decisions based on the context of the traffic (e.g., TCP handshake).

Layer: Network & Transport Layers (Layer 3 & 4)

Pros: More secure than packet-filtering; tracks connection state

Cons: More resource-intensive than stateless filtering

🔹 3. Application-Level Gateways (Proxy Firewalls)

How it works: Acts as a proxy between users and the resources they access, inspecting the actual data (e.g., HTTP traffic).

Layer: Application Layer (Layer 7)

Pros: Deep inspection of traffic; can log and filter based on content

Cons: Slower performance; more complex to manage

🔹 4. Next-Generation Firewalls (NGFW)

How it works: Combines traditional firewall with advanced features like:

Deep Packet Inspection (DPI)

Intrusion Detection/Prevention (IDS/IPS)

Application awareness

User identity tracking


Layer: Multi-layer (3 to 7)

Pros: Advanced threat detection, modern security capabilities

Cons: Expensive; requires skilled admins

🔹 5. Circuit-Level Gateways

How it works: Monitors TCP handshakes and sessions without inspecting packet contents.

Layer: Session Layer (Layer 5)

Pros: Lightweight and fast

Cons: No payload inspection; can’t prevent content-based attacks

🔹 6. Cloud-Based Firewalls (Firewall-as-a-Service – FWaaS)

How it works: Centralized firewall delivered via the cloud, protects users and devices regardless of their location.

Use case: Remote workers, branch offices, hybrid clouds

Pros: Scalable, easy to deploy, no physical hardware

Cons: Internet dependency; trust in third-party provider

🔹 7. Web Application Firewalls (WAF)

How it works: Specifically filters, monitors, and blocks HTTP/S traffic to and from web applications.

Focus: Protects against OWASP Top 10 (e.g., SQLi, XSS)

Pros: Essential for modern web apps and APIs

Cons: Not a full replacement for a network firewall

🔹 8. Host-Based Firewalls

How it works: Software-based firewall installed on individual servers or endpoints.

Scope: Local to the host

Pros: Fine-grained control; protects even if the network firewall is bypassed

Cons: Must be configured on each host; hard to manage at scale

🔹 9. Virtual Firewalls

How it works: Deployed in virtual environments (e.g., VMware, KVM, OpenStack) to secure VM traffic.

Use case: Cloud and virtualized data centers

Pros: Agile, integrates with SDN and orchestration

Cons: Requires knowledge of virtual infrastructure

#security #firewall #linux #kernel
https://t.me/unixmens

ساختار bluestore و lvm در ceph :



این نکته را باید گفت که : ؛در Ceph و مشخصاً در BlueStore، استفاده از LVM یک گزینه است، نه یک الزام.؛


اما در ادامه به بررسی مزایا و معایب این روش خواهیم پرداخت :

در کل ما دو گزینه داریم در مبحث bluestore

استفاده از Raw Device (Default و توصیه‌شده)

در این حالت، BlueStore مستقیماً روی یک دیسک یا پارتیشن فیزیکی نصب می‌شود (مثلاً /dev/sdX).

هیچ LVM یا فایل‌سیستمی در بین نیست.

مزیت: عملکرد بهتر، تأخیر کمتر، و سادگی در مدیریت.

و روش دیگر LVM-Based OSD (معمولاً در Ceph-Ansible یا ceph-volume استفاده می‌شود)

در این حالت از Volume Group و Logical Volume (LVM) استفاده می‌شود.

مخصوصاً وقتی شما بخواهید فضای OSD را روی LVM پارتیشن‌بندی کنید یا چند دیسک کوچک را تجمیع نمایید.

در ابزار ceph-volume این حالت پرکاربرد است.

به صورت مثال:

ceph-volume lvm create --data /dev/sdX

یا برای ساخت دستی:

pvcreate /dev/sdX
vgcreate ceph-vg /dev/sdX
lvcreate -n osd-lv -l 100%FREE ceph-vg
ceph-volume lvm create --data ceph-vg/osd-lv

پس BlueStore چگونه کار می‌کنه بدون فایل‌سیستم؟

در واقع BlueStore داده‌ها را مستقیماً روی دستگاه بلاک (Block Device) می‌نویسد.

برای متادیتا و ساختار مدیریت داخلی خودش، از یک دیتابیس داخلی استفاده می‌کند که اغلب RocksDB است.

ساختار ذخیره‌سازی BlueStore:

        block: داده‌های اصلی

        block.db: متادیتا

        block.wal: write-ahead log

این‌ها یا روی همان دیسک یا روی دیسک‌های جداگانه می‌توانند قرار گیرند.
🔧 چرا این تصمیم گرفته شده؟

حذف فایل‌سیستم مانند XFS باعث شده:

یک لایه میانی کمتر شود (Overhead کمتر)

Ceph کنترل کامل روی داده‌ها و تخصیص داشته باشد

بتواند عملکرد و latency را بهینه کند

بهتر با SSD و NVMe سازگار شود

اما مزایای استفاده از lvm میتونه چی باشه ؟ !!!!!!


استفاده از LVM در BlueStore یک گزینه اختیاری اما بسیار مفید است، مخصوصاً در محیط‌های production. در ادامه، مزایا و دلایل اصلی استفاده از LVM در BlueStore را با هم بررسی میکنیم :


1. مدیریت منعطف دیسک‌ها

با LVM می‌توان از چند دیسک فیزیکی یک Volume Group ساخت و آن را به یک OSD اختصاص داد.

می‌توان ظرفیت را در آینده افزایش داد (extend) یا تنظیمات جدید اعمال کرد.

مناسب برای دیتاسنترهایی که مدیریت منابع ذخیره‌سازی به‌صورت داینامیک انجام می‌دهند.

2. پارتیشن‌بندی دقیق اجزای BlueStore (block, block.db, block.wal)

در BlueStore ما سه جزء کلیدی داریم که قبلا به اون پرداختم .


با LVM می‌توان این اجزا را روی دیسک‌های مختلف قرار داد تا
از SSD برای block.db و block.wal استفاده کرد

و از HDD برای block (داده حجیم)

این کار تأثیر چشم‌گیری در افزایش کارایی و کاهش latency دارد.
3. یکپارچگی با ابزار ceph-volume

در واقع ceph-volume ابزار رسمی Ceph برای مدیریت OSDها است و از LVM به‌صورت native پشتیبانی می‌کند.

مزایا:

ساخت آسان‌تر OSD

مانیتورینگ بهتر با ceph-volume lvm list

سازگاری با cephadm/ansible

بازیابی ساده‌تر در صورت crash

4. قابلیت Tag گذاری و مدیریت منطقی

با LVM می‌توان Volumeها را با تگ‌های مشخص تعریف کرد (مثلاً برای osd.12 یا nvme-db)

در سناریوهای Disaster Recovery یا Migration بسیار مفید است.

5. Snapshot و Backup سطح Volume (در برخی کاربردها)

هرچند برای OSD عملیاتی مرسوم نیست، اما در برخی سناریوهای تست و توسعه امکان گرفتن snapshot از OSD volume وجود دارد.

مثلاً قبل از upgrade.

6. درک و مشاهده ساختار دقیق با ابزارهای LVM

ابزارهایی مثل lvdisplay, vgdisplay, pvdisplay دید کاملی از وضعیت OSD می‌دهند.

تشخیص مشکلات و مدیریت ساده‌تر.

#ceph #lvm #linux #storage #kernel #sds #bluestore

https://t.me/unixmens

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

کمی عمیق تر شویم :

بازرسی بسته عمیق چیست؟

ا Deep Packet Inspection یک روش فیلتر کردن بسته های شبکه است که هم هدر و هم بخش داده یک بسته را تجزیه و تحلیل می کند (بسته کوچکی از داده های مربوط به هر کاری که انجام می دهید، ارسال می کنید و دریافت می کنید). در مورد یک ISP، DPI به این معنی است که کل اتصال و ترافیک آنلاین کاربر را تجزیه و تحلیل می‌کند، نه فقط برخی از اطلاعات اتصال مانند شماره پورت، آدرس‌های IP دسترسی‌یافته و پروتکل‌ها.

ا ISPها معمولاً از DPI برای تخصیص منابع موجود برای ساده‌سازی جریان ترافیک و بهینه‌سازی سرورهای خود برای شناسایی هکرها، مبارزه با بدافزارها و جمع‌آوری داده‌های رفتاری در مورد کاربرانشان استفاده می‌کنند.





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

ا DPI معمولاً در سطح فایروال انجام می‌شود، به‌ویژه در لایه هفتم اتصال بین سیستم‌های باز - لایه برنامه. این روش محتویات هر بسته داده ای را که از یک نقطه بازرسی عبور می کند، ارزیابی می کند.

روشی که DPI محتویات بسته های داده را ارزیابی می کند بر اساس قوانینی است که توسط مدیر شبکه ایجاد شده است. DPI ارزیابی را در زمان واقعی انجام می دهد و می تواند بگوید که بسته های داده از کجا (به طور دقیق کدام برنامه یا سرویس) آمده اند. همچنین می‌توان فیلترهایی را برای هدایت مجدد ترافیک DPI از سرویس‌های آنلاین (مثلاً فیس‌بوک) ایجاد کرد.

به عنوان مثال، دولت چین از Deep Packet Inspection برای سانسور محتوایی که برای شهروندان چینی و منافع دولتی "مضر" تلقی می شود، استفاده می کند. برای این منظور، ISP های چینی از DPI برای ردیابی کلمات کلیدی خاصی که از طریق شبکه هایشان عبور می کنند، استفاده می کنند و در صورت یافتن چنین اطلاعاتی، اتصالات را محدود می کنند.

مثال دیگر آژانس امنیت ملی ایالات متحده است که از DPI برای نظارت بر ترافیک اینترنت استفاده می کند. همچنین، گفته می شود که دولت ایران از DPI برای جمع آوری اطلاعات افراد و مسدود کردن ارتباطات استفاده می کند.





چگونه ISP ها از بازرسی بسته عمیق استفاده می کنند؟

یکی از راه های اصلی استفاده ISP ها از DPI این است که به دنبال محتوای P2P بگردند – به خصوص در کشورهایی که تورنت دقیقاً قانونی نیست. وقتی محتوای P2P را پیدا می‌کنند، یا سرعت دانلود کاربر را کاهش می‌دهند (بهترین سناریو)، یا داده‌های کاربر را به مقامات و آژانس‌های حق نسخه‌برداری تحویل می‌دهند (که منجر به اعلامیه‌های DMCA، جریمه‌های هنگفت یا حتی زندان برای این افراد می‌شود. کاربر).

علاوه بر این، ISPها می توانند در صورت نیاز به مسدود کردن دسترسی به وب سایت خاصی، به DPI اعتماد کنند. به طور معمول، آنها این کار را برای رعایت قوانین دولتی و بالقوه حق چاپ در مورد محتوا انجام می دهند.

ا ISP ها همچنین می توانند از DPI برای ردیابی اتصالات کاربر استفاده کنند و پروفایل های جامع را بر اساس فعالیت ها و ترجیحات آنلاین خود جمع آوری کنند، که ممکن است آنها را به تبلیغ کنندگان شخص ثالث بفروشند. این چیزی است که از نظر قانونی می تواند در ایالات متحده و در پشت صحنه در کشورهای دیگر رخ دهد.

در نهایت، این امکان نیز وجود دارد که ISP شما از DPI برای کاهش پهنای باند استفاده کند. از آنجایی که DPI بینش زیادی در مورد آنچه آنلاین انجام می‌دهید و آنچه دانلود می‌کنید به آن‌ها می‌دهد، اگر فکر کنند از «داده‌های بیش از حد» برای یک فعالیت خاص استفاده می‌کنید - مانند بازی آنلاین، پخش آنلاین یا دانلود فایل‌ها، احتمالاً می‌توانند سرعت شما را کاهش دهند.


#dpi #net #security #linux #network #article



@unixmens

Security #Observability with #eBPF

#linux #cilium #kubernetes #k8s #security
https://t.me/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

#دانستنی های #گنو/ #لینوکس :


در واقع Tuned در لینوکس یک سرویس و مجموعه ابزار برای بهینه‌سازی خودکار عملکرد و مصرف انرژی سیستم است که می‌تواند پروفایل‌های آماده یا سفارشی را روی سخت‌افزار اعمال کند.

ایده اصلی Tuned این است که بسته به سناریوی کاری (سرور دیتابیس، ماشین مجازی، لپ‌تاپ، سیستم گرافیکی، ذخیره‌سازی و غیره)، سیستم را به‌طور پویا بهینه کند، بدون اینکه کاربر هر بار دستی پارامترها را تغییر دهد.

این تنظیمات می‌توانند شامل:

CPU governor و فرکانس پردازنده

زمان‌بندی I/O (I/O scheduler)

تنظیمات شبکه (TCP stack)

سیاست مصرف انرژی دستگاه‌ها (PCIe ASPM، SATA link power)

تنظیمات kernel sysctl

پارامترهای NUMA و حافظه


توی دنیای لینوکس، tuned-ppd یک "دیمنت پیاده‌سازی پل" (compatibility daemon) است که برای همگام‌سازی دو سیستم مدیریت پروفایل مصرف انرژی طراحی شده:

تعریف و هدف tuned-ppd

ا tuned-ppd وظیفه دارد تا API مورد استفاده توسط power-profiles-daemon (PPD) را به API سیستم TuneD ترجمه کند



نحوه عملکرد

برنامه‌هایی که با API قدرت قبلی (PPD) کار می‌کردند، اکنون از طریق tuned-ppd به TuneD متصل می‌شوند.



برای نمونه : من در لپ تاپ خودم با این ابزار میتونم . تنظیم کنم . تا چند درصد باطری را شارژ کامل کنه . تا باطری عمر بیشتری داشته باشه .

نکته : این قابلیت ها سخت افزاری هستند وباید تولید کننده لپ تاپ این قابلیت را بده .


برای مثال : لپ‌تاپت من Lenovo Ideapad هست و با درایور ideapad_laptop کار می‌کنه.

این درایور فقط یک حالت conserve mode (روشن/خاموش) داره، یعنی:

0 → خاموش، باتری تا 100٪ شارژ میشه.

1 → روشن، باتری حداکثر تا حدود ~55–60٪ شارژ میشه (محدوده دقیق وابسته به مدل و firmware هست)


--- TLP 1.7.0 --------------------------------------------



+++ Battery Care

Plugin: lenovo

Supported features: charge threshold

Driver usage:

* vendor (ideapad_laptop) = active (charge threshold)

Parameter value range:

* STOP_CHARGE_THRESH_BAT0: 0(off), 1(on) -- battery conservation mode

اما tlp :



یک ابزار تخصصی مدیریت مصرف انرژی در لینوکس است که برخلاف Tuned که بیشتر روی بهینه‌سازی کلی سیستم (CPU، I/O، Network، Memory) تمرکز دارد، بیشتر تمرکزش روی بهینه‌سازی مصرف باتری و افزایش طول عمر آن است، مخصوصاً برای لپ‌تاپ‌ها.

هدف TLP این است که:

عمر باتری لپ‌تاپ را افزایش دهد (Battery Longevity)

زمان کارکرد روی باتری را بیشتر کند (Battery Runtime)

بدون نیاز به تغییر دستی تنظیمات، بهترین تعادل بین مصرف انرژی و کارایی را پیدا کند.

ا TLP بعد از نصب و فعال‌سازی، به‌صورت خودکار با توجه به وضعیت سیستم (وصل بودن به برق یا کار روی باتری) تنظیمات بهینه را اعمال می‌کند.


تنظیم CPU frequency scaling governor

تنظیم PCI Express ASPM برای کاهش مصرف برق قطعات PCIe

خاموش‌کردن پورت‌های USB در حالت بیکار (USB autosuspend)

خاموش یا کم‌کردن توان Wi-Fi و Bluetooth در حالت باتری

تنظیم پارامترهای SATA link power management

کنترل GPU power saving (برای Intel، NVIDIA و AMD)

مدیریت Battery charge thresholds (در لپ‌تاپ‌هایی که پشتیبانی می‌کنند، مثل Lenovo/Dell/ASUS)

تغییر تنظیمات kernel power management



unixmens

#linux #kernel #tlp #tuned #performance
#tune


https://t.me/unixmens