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

مدیریت سرور، چرا و چگونه؟

در این مطلب قصد داریم به شما کمک کنیم که تصمیم بگیرید که آیا تامین خدمات مدیریت سرور توسط یک مجموعه تخصصی تاثیر و مزایایی برای کسب و کار شما خواهد داشت یا خیر

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

یک سرویس مدیریت شده از زبان PCMagazine بصورت خلاصه به معنای انجام زحمت کار بصورت حرفه ای و با تجهیزات و سامانه های به روز توسط مجموعه ای تخصصی در خارج از سازمان شماست.

1. صرفه‌جویی در زمان

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

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

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

2. بهینه‌سازی هزینه‌ها

اگرچه در نگاه اول هزینه پرداخت به شرکت‌های تخصصی ممکن است زیاد به‌نظر برسد، اما در بلندمدت هزینه کمتری برای کسب‌وکار شما دارد:

استخدام یک مدیر سرور داخلی هزینه بیشتری دارد (حقوق ثابت، مزایا و غیره).
ابزارها و نرم‌افزارهای نظارتی و امنیتی گران‌قیمت هستند، اما شرکت‌های تخصصی به‌صورت اشتراکی از این ابزارها استفاده می‌کنند و هزینه آن‌ها در بین مشتریان تقسیم می‌شود.
هزینه‌های ناشی از خرابی سرور یا از دست رفتن داده‌ها به‌مراتب بیشتر از هزینه خدمات مدیریت سرور است.

3. دسترسی به دانش و تخصص پیشرفته

مدیریت سرور شامل موارد پیچیده‌ای مانند امنیت، بهینه‌سازی عملکرد، تنظیمات پیشرفته، و نظارت 24/7 است. شرکت‌های تخصصی تیم‌هایی دارند که:

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

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

4. امنیت بالاتر

امنیت داده‌ها و سرور از حیاتی‌ترین دغدغه‌های هر کسب‌وکاری است. شرکت‌های مدیریت سرور:

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

اگر امنیت سرور خود را به‌درستی مدیریت نکنید، ممکن است قربانی هک، سرقت داده‌ها یا حملات سایبری شوید که می‌تواند خسارات مالی و اعتباری سنگینی به همراه داشته باشد.

5. پشتیبانی 24/7

سرورها ممکن است در هر لحظه از شبانه‌روز دچار مشکل شوند. شرکت‌های مدیریت سرور معمولاً تیم‌های پشتیبانی 24/7 دارند که:

به‌صورت دائمی سرور شما را زیر نظر دارند.
در صورت بروز مشکل به‌سرعت وارد عمل می‌شوند.
اطمینان می‌دهند که حداکثر زمان آپتایم (Uptime) برای سرور شما فراهم باشد.

اگر بخواهید خودتان این کار را انجام دهید، باید دائماً آماده باشید و حتی در نیمه‌شب نیز احتمالاً مجبور به رفع مشکلات خواهید شد.

6. بهبود عملکرد و کارایی

شرکت‌های مدیریت سرور به دلیل تجربه و تخصص خود می‌توانند سرور شما را به‌گونه‌ای پیکربندی کنند که بهترین عملکرد را داشته باشد:

بهینه‌سازی منابع سرور (CPU، RAM و فضای دیسک).
کاهش زمان بارگذاری (Load Time) که تأثیر مستقیم بر تجربه کاربری و سئو دارد.
ارائه پیشنهاداتی برای ارتقاء یا تغییر منابع در صورت رشد کسب‌وکار شما.

اگر خودتان این کار را انجام دهید، ممکن است پیکربندی نادرستی انجام دهید که باعث هدررفت منابع یا کاهش کارایی شود.

7. تمرکز بر کسب‌وکار اصلی

وقتی مدیریت سرور را به یک شرکت تخصصی بسپارید:

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

8. دسترسی به SLA (توافق‌نامه سطح خدمات)

بیشتر شرکت‌های مدیریت سرور SLA ارائه می‌دهند که در آن تعهد می‌کنند خدمات باکیفیت ارائه دهند. این شامل:

تضمین زمان پاسخ‌گویی.
تعهد به حل مشکلات در زمان معین.
جبران خسارت در صورت عدم رعایت SLA.

در مقابل، اگر خودتان مدیریت را بر عهده داشته باشید، هیچ ضمانتی برای رفع سریع مشکلات وجود ندارد.

9. مقایسه در سناریوهای واقعی

خرابی سرور: اگر شما تخصص کافی نداشته باشید، رفع خرابی ممکن است ساعت‌ها طول بکشد، اما شرکت‌های مدیریت سرور در کوتاه‌ترین زمان آن را برطرف می‌کنند.
ارتقاء منابع: تیم‌های تخصصی با تجزیه‌وتحلیل دقیق، منابع موردنیاز را پیشنهاد می‌دهند. اما اگر خودتان این کار را انجام دهید، ممکن است منابع اضافی و غیرضروری تهیه کنید که باعث افزایش هزینه شود.

10. کاهش ریسک و خطا

انجام تنظیمات و مدیریت سرور توسط افراد غیرمتخصص می‌تواند منجر به:

خرابی‌های غیرمنتظره.
از دست رفتن داده‌ها.
تنظیمات امنیتی ضعیف و آسیب‌پذیری در برابر حملات.

شرکت‌های تخصصی با داشتن فرآیندها و پروتکل‌های استاندارد، این ریسک‌ها را به حداقل می‌رسانند.

11. ارتقای سئو

به دلیل پایداری بهتر سایت شما رتبه بالاتری دریافت خواهد کرد.
بهینه سازی سرویس ها منجر به افزایش سرعت فراخوانی سایت و یا برنامه شما خواهد شد که باعث افزایش رتبه سایت شما خواهد شد.

12. دریافت مشاوره تخصصی:

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

نتیجه‌گیری:

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

نصب مخزن EPEL داخل کشور بدون تحریم

زاگریو27 آذر 1403

366views

رفع مشکل مخزن EPEL با سرور داخلی بدون تحریم و کاهش سرعت

مخزن EPEL (Extra Packages for Enterprise Linux) یک مخزن نرم‌افزاری متن‌باز است که توسط پروژه Fedora برای توزیع‌های لینوکسی Enterprise مانند RHEL (Red Hat Enterprise Linux)، CentOS، راکی لینوکس Rocky Linux و آلمالینوکس AlmaLinux ارائه شده است. هدف اصلی این مخزن، فراهم کردن بسته‌های اضافی و کاربردی برای این توزیع‌هاست که در مخازن رسمی وجود ندارند.

EPEL چیست؟

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

چه کاربردی دارد؟

افزایش امکانات پیش‌فرض لینوکس سازمانی:
توزیع‌های RHEL و مشابه‌های آن برای استفاده در محیط‌های تجاری و سازمانی طراحی شده‌اند و فقط ابزارها و بسته‌های ضروری در مخازن رسمی آن‌ها وجود دارد. EPEL به کاربران اجازه می‌دهد ابزارها و بسته‌های اضافی موردنیاز خود را بدون ایجاد مشکل در پایداری سیستم، نصب کنند.
دسترسی به نرم‌افزارهای متن‌باز محبوب:
بسیاری از ابزارهای متن‌باز که به‌طور گسترده توسط توسعه‌دهندگان، مدیران سیستم و کاربران استفاده می‌شوند، مانند htop، nginx، fail2ban، ansible و غیره، از طریق EPEL در دسترس هستند.
رفع نیاز به کامپایل دستی نرم‌افزارها:
بدون استفاده از EPEL، کاربران باید بسیاری از نرم‌افزارها را به‌صورت دستی کامپایل کنند، که زمان‌بر است و ممکن است به مشکلات وابستگی‌ها (dependencies) برخورد کنند.

زیرساخت ها و نرم افزاهایی که در EPEL وجود دارد:

ابزارهای توسعه‌دهنده: مانند git ،vim-enhanced و build-essential
نرم‌افزارهای مانیتورینگ و مدیریت سیستم: مانند nagios ،zabbix-agent و net-tools
کتابخانه‌های برنامه‌نویسی و ماژول‌ها: مانند python-pip ،perl-modules و nodejs
سرورها و ابزارهای تحت وب: مانند nginx ،haproxy و phpMyAdmin
ابزارهای شبکه: مانند iperf3 ،tcpdump و wireshark

دلایل نیاز به EPEL:

گستره وسیع بسته‌ها:
مخازن رسمی RHEL، CentOS یا AlmaLinux شامل بسته‌های محدود و پایه‌ای هستند. برای دسترسی به ابزارهای اضافی، EPEL ضروری است.
پایداری و سازگاری:
تمام بسته‌های موجود در EPEL مطابق با استانداردهای Fedora ساخته شده‌اند، بنابراین قابل اعتماد بوده و با سیستم‌های لینوکسی Enterprise سازگارند.
مدیریت وابستگی‌ها:
با استفاده از EPEL، مشکلات مربوط به وابستگی نرم‌افزارها به حداقل می‌رسد زیرا تمام نیازمندی‌های یک بسته به‌صورت خودکار از مخزن نصب می‌شوند.
به‌روزرسانی منظم:
بسته‌های موجود در EPEL به‌طور مرتب به‌روزرسانی می‌شوند و آخرین نسخه‌های پایدار نرم‌افزارها را ارائه می‌دهند.

برخی از برنامه‌های ضروری داخل EPEL:

Ansible: ابزاری برای اتوماسیون مدیریت سیستم.
Htop: ابزار مانیتورینگ و مشاهده منابع سیستم.
Fail2ban: برای محافظت از سرور در برابر حملات brute force.
Nginx: به‌عنوان یک وب‌سرور یا پروکسی معکوس.
Certbot: برای دریافت و مدیریت گواهی‌های SSL از LetsEncrypt.

چگونه EPEL را فعال کنیم؟

فعال‌سازی EPEL بسیار ساده است. برای فعال کردن این مخزن در سیستم‌های لینوکسی مبتنی بر RHEL (مانند CentOS و AlmaLinux)، می‌توانید دستور زیر را اجرا کنید اما پس از اجرای این دستور در سرورهای داخل کشور ، اقدام به نصب و با به روزرسانی از این مخزن با خطا مواجه خواهد شد زیرا Fedora آدرسهای IP ایران را تحریم کرده است و باید با استفاده از ابزارهایی که برای دور زدن تحریم طراحی شده اند این موارد را دور بزنید که متاسافانه دارای سرعت بسیار پائینی هستند و بهره وری و سرعت انجام کار را بسیار زیاد می کند.

dnf install epel-release

1	dnf install epel-release

در همین راستا زاگریو به منظور رفاه حال همکاران و استفاده کنندگان سیستم ها و سرورهای لینوکسی؛ اقدام به راه اندازی مخازن متن باز لینوکس در ایران کرده است و همچنین یک کپی از مخزن epel در داخل کشور بر روی شبکه نیم‌بها با سرعت 100Gbit/s نموده است.

مشخصات سرور EPEL در ایران بدون تحریم:

آدرس اصلی مخزن که در اصل یک رونوشت از مخزن اصلی به آدرس ذیل است:

https://epel.mirrors.zagrio.net/

1	https://epel.mirrors.zagrio.net/

این مخزن بر روی آدرس‌ها و پروتکل‌های HTTP, rsync و FTP نیز در دسترس است:

http://epel.mirrors.zagrio.net/
rsync://mirrors.zagrio.net/epel/
ftp://mirrors.zagrio.net/epel/

http://epel.mirrors.zagrio.net/

rsync://mirrors.zagrio.net/epel/

ftp://mirrors.zagrio.net/epel/

یکی از مهمترین مزایای استفاده از این محزن، نیم بها بودن تعرفه اینترنت شما خواهد بود.

به دلیل محدودیت فضا، صرفا برنامه های مربوط به نسخه 7 به بالا در این مخزن وجود دارد و نسخ 4، 5 و 6 در این مخزن وجود نداند.

نحوه نصب مخزن EPEL زاگریو

نصب کلید GPG

ابتدا باید کلید مربوط به نسخه سرور خود را نصب کنید، نسخه سرور خود را با دستور cat /etc/redhat-release پیدا کنید.

نصب کلید برای سرورهای نسخه 7

curl -o /usr/src/RPM-GPG-KEY-EPEL-7 https://epel.mirrors.zagrio.net/RPM-GPG-KEY-EPEL-7
rpm --import /usr/src/RPM-GPG-KEY-EPEL-7

1 2	curl -o /usr/src/RPM-GPG-KEY-EPEL-7 https://epel.mirrors.zagrio.net/RPM-GPG-KEY-EPEL-7 rpm --import /usr/src/RPM-GPG-KEY-EPEL-7

نصب کلید برای سرورهای نسخه 8

curl -o /usr/src/RPM-GPG-KEY-EPEL-8 https://epel.mirrors.zagrio.net/RPM-GPG-KEY-EPEL-8
rpm --import /usr/src/RPM-GPG-KEY-EPEL-8

1 2	curl -o /usr/src/RPM-GPG-KEY-EPEL-8 https://epel.mirrors.zagrio.net/RPM-GPG-KEY-EPEL-8 rpm --import /usr/src/RPM-GPG-KEY-EPEL-8

نصب کلید برای سرورهای نسخه 9

curl -o /usr/src/RPM-GPG-KEY-EPEL-9 https://epel.mirrors.zagrio.net/RPM-GPG-KEY-EPEL-9
rpm --import /usr/src/RPM-GPG-KEY-EPEL-9

1 2	curl -o /usr/src/RPM-GPG-KEY-EPEL-9 https://epel.mirrors.zagrio.net/RPM-GPG-KEY-EPEL-9 rpm --import /usr/src/RPM-GPG-KEY-EPEL-9

نصب کلید برای سرورهای نسخه 10

curl -o /usr/src/RPM-GPG-KEY-EPEL-10 https://epel.mirrors.zagrio.net/RPM-GPG-KEY-EPEL-10
rpm --import /usr/src/RPM-GPG-KEY-EPEL-10

1 2	curl -o /usr/src/RPM-GPG-KEY-EPEL-10 https://epel.mirrors.zagrio.net/RPM-GPG-KEY-EPEL-10 rpm --import /usr/src/RPM-GPG-KEY-EPEL-10

تغییر فایلهای Repository (برای REHL9)

حالا باید فایلهایی که مربوط به مسیردهی مخزن هست را تغییر داد. برای انجام این کار چندین روش وجود دارد. این فایلهای در مسیر etc/yum.repos.d/ قرار دارند و در این فایلهای مقداری برای مسیر اتصال به مخزن ها تعریف شده است که metalink نام دارد. این مسیر لیستی از مخازن هستند که بر اساس موقعیت جغرافیایی و سرعت شبکه شما، به بهترین آنها متصل می شوید و عملیات دانلود از آن سرور انجام می شود.

یک نوع مسیردهی یگر با نام baseurl وجود دارد که می توانید با استفاده از آن مسیر سرور مخزن را مشخصا تعیین کنید. شما باید آدرس سرور ما که در بالا آمده است را بصورتی تنظیم کنید که مانند تصویر به سرورهای ما متصل شده باشند.

نمونه تنظیم شده فایل epel.repo برای مخزن زاگریو در داخل کشور

با استفاده از یکی از روشهای ذیل این تغییر را می توانید انجام دهید:

بصورت دستی با ویرایشگر دلخواه خود مانند nano فایلهای etc/yum.repos.d/epel.repo/ و etc/yum.repos.d/epel-testing.repo/ را ویرایش کنید و یک # در ابتدای خطوطی که داری metalink هستند اضافه کنید و # را از ابتدای baseurl حذف کنید و مقدار ذیل را بجای آن تنظیم کنید:

baseurl=https://epel.mirrors.zagrio.net/$releasever/Everything/source/tree/

1	baseurl=https://epel.mirrors.zagrio.net/$releasever/Everything/source/tree/

با استفاده از دستورات ذیل، فایلهای مخزن را حذف و نسخه تنظیم شده توسط ما را جایگزین آنها کنید: (روش پیشنهادی)

curl -o /etc/yum.repos.d/epel.repo https://repo.zagrio.net/linux/yum/epel-9.repo
curl -o /etc/yum.repos.d/epel-testing.repo https://repo.zagrio.net/linux/yum/epel-testing-9.repo

1 2	curl -o /etc/yum.repos.d/epel.repo https://repo.zagrio.net/linux/yum/epel-9.repo curl -o /etc/yum.repos.d/epel-testing.repo https://repo.zagrio.net/linux/yum/epel-testing-9.repo

محتوای فایلهای epel.repo و epel-testing.repo را با دستورات ذیل حذف و بصورت دستی جایگزین کنید:

rm /etc/yum.repos.d/epel.repo -f
echo '[epel]'> /etc/yum.repos.d/epel.repo
echo 'name=Extra Packages for Enterprise Linux $releasever - $basearch'>> /etc/yum.repos.d/epel.repo
echo '# It is much more secure to use the metalink, but if you wish to use a local mirror'>> /etc/yum.repos.d/epel.repo
echo '# place its address here.'>> /etc/yum.repos.d/epel.repo
echo 'baseurl=https://epel.mirrors.zagrio.net/$releasever/Everything/$basearch/'>> /etc/yum.repos.d/epel.repo
echo '#metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-$releasever&arch=$basearch&infra=$infra&content=$contentdir'>> /etc/yum.repos.d/epel.repo
echo 'enabled=1'>> /etc/yum.repos.d/epel.repo
echo 'gpgcheck=1'>> /etc/yum.repos.d/epel.repo
echo 'countme=1'>> /etc/yum.repos.d/epel.repo
echo 'gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever'>> /etc/yum.repos.d/epel.repo
echo ''>> /etc/yum.repos.d/epel.repo
echo '[epel-debuginfo]'>> /etc/yum.repos.d/epel.repo
echo 'name=Extra Packages for Enterprise Linux $releasever - $basearch - Debug'>> /etc/yum.repos.d/epel.repo
echo '# It is much more secure to use the metalink, but if you wish to use a local mirror'>> /etc/yum.repos.d/epel.repo
echo '# place its address here.'>> /etc/yum.repos.d/epel.repo
echo 'baseurl=https://epel.mirrors.zagrio.net/$releasever/Everything/$basearch/debug/'>> /etc/yum.repos.d/epel.repo
echo '#metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-$releasever&arch=$basearch&infra=$infra&content=$contentdir'>> /etc/yum.repos.d/epel.repo
echo 'enabled=0'>> /etc/yum.repos.d/epel.repo
echo 'gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever'>> /etc/yum.repos.d/epel.repo
echo 'gpgcheck=1'>> /etc/yum.repos.d/epel.repo
echo ''>> /etc/yum.repos.d/epel.repo
echo '[epel-source]'>> /etc/yum.repos.d/epel.repo
echo 'name=Extra Packages for Enterprise Linux $releasever - $basearch - Source'>> /etc/yum.repos.d/epel.repo
echo '# It is much more secure to use the metalink, but if you wish to use a local mirror'>> /etc/yum.repos.d/epel.repo
echo '# place its address here.'>> /etc/yum.repos.d/epel.repo
echo 'baseurl=https://epel.mirrors.zagrio.net/$releasever/Everything/source/tree/'>> /etc/yum.repos.d/epel.repo
echo '#metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-$releasever&arch=$basearch&infra=$infra&content=$contentdir'>> /etc/yum.repos.d/epel.repo
echo 'enabled=0'>> /etc/yum.repos.d/epel.repo
echo 'gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever'>> /etc/yum.repos.d/epel.repo
echo 'gpgcheck=1'>> /etc/yum.repos.d/epel.repo
rm /etc/yum.repos.d/epel-testing.repo -f
echo '[epel-testing]' > /etc/yum.repos.d/epel-testing.repo
echo 'name=Extra Packages for Enterprise Linux $releasever - Testing - $basearch' >>/etc/yum.repos.d/epel-testing.repo
echo '# It is much more secure to use the metalink, but if you wish to use a local mirror' >>/etc/yum.repos.d/epel-testing.repo
echo '# place its address here.' >>/etc/yum.repos.d/epel-testing.repo
echo 'baseurl=https://epel.mirrors.zagrio.net/testing/$releasever/Everything/$basearch/' >>/etc/yum.repos.d/epel-testing.repo
echo '#metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-epel$releasever&arch=$basearch&infra=$infra&content=$contentdir' >>/etc/yum.repos.d/epel-testing.repo
echo 'enabled=0' >>/etc/yum.repos.d/epel-testing.repo
echo 'gpgcheck=1' >>/etc/yum.repos.d/epel-testing.repo
echo 'countme=1' >>/etc/yum.repos.d/epel-testing.repo
echo 'gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever' >>/etc/yum.repos.d/epel-testing.repo
echo '' >>/etc/yum.repos.d/epel-testing.repo
echo '[epel-testing-debuginfo]' >>/etc/yum.repos.d/epel-testing.repo
echo 'name=Extra Packages for Enterprise Linux $releasever - Testing - $basearch - Debug' >>/etc/yum.repos.d/epel-testing.repo
echo '# It is much more secure to use the metalink, but if you wish to use a local mirror' >>/etc/yum.repos.d/epel-testing.repo
echo '# place its address here.' >>/etc/yum.repos.d/epel-testing.repo
echo 'baseurl=https://epel.mirrors.zagrio.net/testing/$releasever/Everything/$basearch/debug/' >>/etc/yum.repos.d/epel-testing.repo
echo '#metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-debug-epel$releasever&arch=$basearch&infra=$infra&content=$contentdir' >>/etc/yum.repos.d/epel-testing.repo
echo 'enabled=0' >>/etc/yum.repos.d/epel-testing.repo
echo 'gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever' >>/etc/yum.repos.d/epel-testing.repo
echo 'gpgcheck=1' >>/etc/yum.repos.d/epel-testing.repo
echo '' >>/etc/yum.repos.d/epel-testing.repo
echo '[epel-testing-source]' >>/etc/yum.repos.d/epel-testing.repo
echo 'name=Extra Packages for Enterprise Linux $releasever - Testing - $basearch - Source' >>/etc/yum.repos.d/epel-testing.repo
echo '# It is much more secure to use the metalink, but if you wish to use a local mirror' >>/etc/yum.repos.d/epel-testing.repo
echo '# place its address here.' >>/etc/yum.repos.d/epel-testing.repo
echo 'baseurl=https://epel.mirrors.zagrio.net/testing/$releasever/Everything/source/tree/' >>/etc/yum.repos.d/epel-testing.repo
echo '#metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-source-epel$releasever&arch=$basearch&infra=$infra&content=$contentdir' >>/etc/yum.repos.d/epel-testing.repo
echo 'enabled=0' >>/etc/yum.repos.d/epel-testing.repo
echo 'gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever' >>/etc/yum.repos.d/epel-testing.repo
echo 'gpgcheck=1' >>/etc/yum.repos.d/epel-testing.repo

rm /etc/yum.repos.d/epel.repo -f

echo '[epel]'> /etc/yum.repos.d/epel.repo

echo 'name=Extra Packages for Enterprise Linux $releasever - $basearch'>> /etc/yum.repos.d/epel.repo

echo '# It is much more secure to use the metalink, but if you wish to use a local mirror'>> /etc/yum.repos.d/epel.repo

echo '# place its address here.'>> /etc/yum.repos.d/epel.repo

echo 'baseurl=https://epel.mirrors.zagrio.net/$releasever/Everything/$basearch/'>> /etc/yum.repos.d/epel.repo

echo '#metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-$releasever&arch=$basearch&infra=$infra&content=$contentdir'>> /etc/yum.repos.d/epel.repo

echo 'enabled=1'>> /etc/yum.repos.d/epel.repo

echo 'gpgcheck=1'>> /etc/yum.repos.d/epel.repo

echo 'countme=1'>> /etc/yum.repos.d/epel.repo

echo 'gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever'>> /etc/yum.repos.d/epel.repo

echo ''>> /etc/yum.repos.d/epel.repo

echo '[epel-debuginfo]'>> /etc/yum.repos.d/epel.repo

echo 'name=Extra Packages for Enterprise Linux $releasever - $basearch - Debug'>> /etc/yum.repos.d/epel.repo

echo '# It is much more secure to use the metalink, but if you wish to use a local mirror'>> /etc/yum.repos.d/epel.repo

echo '# place its address here.'>> /etc/yum.repos.d/epel.repo

echo 'baseurl=https://epel.mirrors.zagrio.net/$releasever/Everything/$basearch/debug/'>> /etc/yum.repos.d/epel.repo

echo '#metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-$releasever&arch=$basearch&infra=$infra&content=$contentdir'>> /etc/yum.repos.d/epel.repo

echo 'enabled=0'>> /etc/yum.repos.d/epel.repo

echo 'gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever'>> /etc/yum.repos.d/epel.repo

echo 'gpgcheck=1'>> /etc/yum.repos.d/epel.repo

echo ''>> /etc/yum.repos.d/epel.repo

echo '[epel-source]'>> /etc/yum.repos.d/epel.repo

echo 'name=Extra Packages for Enterprise Linux $releasever - $basearch - Source'>> /etc/yum.repos.d/epel.repo

echo '# It is much more secure to use the metalink, but if you wish to use a local mirror'>> /etc/yum.repos.d/epel.repo

echo '# place its address here.'>> /etc/yum.repos.d/epel.repo

echo 'baseurl=https://epel.mirrors.zagrio.net/$releasever/Everything/source/tree/'>> /etc/yum.repos.d/epel.repo

echo '#metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-$releasever&arch=$basearch&infra=$infra&content=$contentdir'>> /etc/yum.repos.d/epel.repo

echo 'enabled=0'>> /etc/yum.repos.d/epel.repo

echo 'gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever'>> /etc/yum.repos.d/epel.repo

echo 'gpgcheck=1'>> /etc/yum.repos.d/epel.repo

rm /etc/yum.repos.d/epel-testing.repo -f

echo '[epel-testing]' > /etc/yum.repos.d/epel-testing.repo

echo 'name=Extra Packages for Enterprise Linux $releasever - Testing - $basearch' >>/etc/yum.repos.d/epel-testing.repo

echo '# It is much more secure to use the metalink, but if you wish to use a local mirror' >>/etc/yum.repos.d/epel-testing.repo

echo '# place its address here.' >>/etc/yum.repos.d/epel-testing.repo

echo 'baseurl=https://epel.mirrors.zagrio.net/testing/$releasever/Everything/$basearch/' >>/etc/yum.repos.d/epel-testing.repo

echo '#metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-epel$releasever&arch=$basearch&infra=$infra&content=$contentdir' >>/etc/yum.repos.d/epel-testing.repo

echo 'enabled=0' >>/etc/yum.repos.d/epel-testing.repo

echo 'gpgcheck=1' >>/etc/yum.repos.d/epel-testing.repo

echo 'countme=1' >>/etc/yum.repos.d/epel-testing.repo

echo 'gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever' >>/etc/yum.repos.d/epel-testing.repo

echo '' >>/etc/yum.repos.d/epel-testing.repo

echo '[epel-testing-debuginfo]' >>/etc/yum.repos.d/epel-testing.repo

echo 'name=Extra Packages for Enterprise Linux $releasever - Testing - $basearch - Debug' >>/etc/yum.repos.d/epel-testing.repo

echo '# It is much more secure to use the metalink, but if you wish to use a local mirror' >>/etc/yum.repos.d/epel-testing.repo

echo '# place its address here.' >>/etc/yum.repos.d/epel-testing.repo

echo 'baseurl=https://epel.mirrors.zagrio.net/testing/$releasever/Everything/$basearch/debug/' >>/etc/yum.repos.d/epel-testing.repo

echo '#metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-debug-epel$releasever&arch=$basearch&infra=$infra&content=$contentdir' >>/etc/yum.repos.d/epel-testing.repo

echo 'enabled=0' >>/etc/yum.repos.d/epel-testing.repo

echo 'gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever' >>/etc/yum.repos.d/epel-testing.repo

echo 'gpgcheck=1' >>/etc/yum.repos.d/epel-testing.repo

echo '' >>/etc/yum.repos.d/epel-testing.repo

echo '[epel-testing-source]' >>/etc/yum.repos.d/epel-testing.repo

echo 'name=Extra Packages for Enterprise Linux $releasever - Testing - $basearch - Source' >>/etc/yum.repos.d/epel-testing.repo

echo '# It is much more secure to use the metalink, but if you wish to use a local mirror' >>/etc/yum.repos.d/epel-testing.repo

echo '# place its address here.' >>/etc/yum.repos.d/epel-testing.repo

echo 'baseurl=https://epel.mirrors.zagrio.net/testing/$releasever/Everything/source/tree/' >>/etc/yum.repos.d/epel-testing.repo

echo '#metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-source-epel$releasever&arch=$basearch&infra=$infra&content=$contentdir' >>/etc/yum.repos.d/epel-testing.repo

echo 'enabled=0' >>/etc/yum.repos.d/epel-testing.repo

echo 'gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever' >>/etc/yum.repos.d/epel-testing.repo

echo 'gpgcheck=1' >>/etc/yum.repos.d/epel-testing.repo

غیرفعال کردن مخزن epel-cisco

در نهایت باید دستور زیر را در هر یک از روش فوق بزنید تا مخزن epel-cisco-openh264 را که از طرف سیسکو برای توزیع Codec H264 پیاده سازی شده است را غیرفعال کنید:

dnf config-manager --disable epel-cisco-openh264

1	dnf config-manager --disable epel-cisco-openh264

جمع‌بندی:

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

معرفی EPEL در سایت RedHat

تامین امنیت سرورهای لینوکسی به واسطه به‌روزرسانی خودکار

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

زاگریو22 آذر 1403

تامین امنیت سرورهای لینوکسی از طریق به‌روزرسانی اتوماتیک

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

یک قانون عمومی اغلب برای استفاده از به روزرسانی خودکار وجود دارد:

اگر سرور مذکور حاوی یک برنامه حیاتی است بصورتی که قطعی سرویس قابل قبول نیست و مشکلات متعددی بوجود می آورد، شما نباید از به روزرسانی خودکار استفاده کنید. در غیر این صورت می‌توانید در خصوص استفاده از این ویژگی تصمیم گیری کنید.

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

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

شما میتوانید از این سرویس برای دانلود و نصب خودکار هر نوع به روزرسانی استفاده کنید (مثلا به روزرسانی های امنیتی)

بسته dnf-automatic مبنی بر RPM به عنوان یک افزونه به DNF اضافه می شود سرویسی برای به روزرسانی خودکار فراهم می کند.

نصب و تنظیم dnf-automatic

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

sudo dnf install dnf-automatic

1	sudo dnf install dnf-automatic

بصورت پیشفرض فایل تنظیمات خود را در مسیر etc/dnf/automatic.conf/ ایجاد می کند. این تنظیمات بصورتی است که فقط بسته ها را دانلود می کند و آنها را نصب نمی کند. برای تغییر و یا افزودن هر نوع تنظیماتی، فایل مذکور را با کاربر دارای دسترسی root توسط ویرایشگر دلخواهتان باز کنید.

sudo nano /etc/dnf/automatic.conf

1	sudo nano /etc/dnf/automatic.conf

نصب و راه اندازی dnf-automatic

پس از نصب دستور زیر را برای فعالسازی وارد کنید:

systemctl enable --now dnf-automatic.timer

1	systemctl enable --now dnf-automatic.timer

سپس با دستور ذیل وضعیت سرویس را بررسی کنید:

systemctl list-timers 'dnf-*'

1	systemctl list-timers 'dnf-*'

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

dnf-automatic-download.timer که فقط دانلود را انجام می دهد.

dnf-automatic-install.timer که عملیات دانلود و نصب را انجام میدهد.

dnf-automatic-notifyonly.timer که فقط برا اساس تنظیمات فایل فوق؛ اطلاع رسانی را انجام می دهد.

شما می توانید از download_updates و apply_updates در داخل etc/dnf/automatic.conf/ بهره ببرید.

آیا بروزرسانی های DNF قابل اطمینان هستند؟

در سیستم های مبتنی بر Fedora و REHL بررسی کلید های GPG بصورت پیشفرض فعال هستند. با فرض اینکه شما کلید صحیح را در سیستم خودتان تعریف کرده باشید و مقدار gpgcheck=1 را در فایل dnf.conf وارد کرده باشید، میتوان اینگونه تصور کرد که فایلهای به روزرسانی خراب و یا تغییر داده شده نیستند و اصالت آنها را تایید کرد. در صورت فعال بودن این گزینه، یک خرابکار به هیچ وجه نمیتواند بسته ای را تولید و برای سرور شما ارسال کند که سیستم شما آن را قبول کند (مگر اینکه آنها کلید خصوصی متناظر با آنچه شما نصب کرده اید را داشته باشند) و در زمان دانلود سیستم فایلهای معیوب را شناسایی خواهد کرد.

هرچند، این پرسش هنوز مطرح است که آیا بسته به روزرسانی بصورت کامل و یا صحیح است؟ آیا با نصب آن سیستم شما دچار مشکل نخواهد شد؟ متاسفانه ما نمیتوانیم به این پرسش پاسخ درستی بدهیم و شما باید در طی یک پروسه آزمون و خطا صحت عملکرد بسته های به روزرسانی را متناسب با نیاز و شرایط خود بررسی کنید. هر بسته به روزرسانی توسط تیم های “کنترل کیفیت” بررسی می شود اما مشکلات همیشه بوجود می آید. خطای انسانی و یا بروز یک ناسازگاری ممکن است سیستم شما را با مشکل مواجه کند که این موارد خصوصا در آپدیت های سرورها و سیستم های ویندوزی به دلیل خودکار بودن بسیار رخ داده و خبرساز شده است. رویه استاندارد در صنعت IT و برنامه های حساس و سیستم های “در حال اجرا” این است که شما همواره قبل از به روزرسانی این بسته ها را بر روی سرورهای تستی خود اصالت سنجی و از صحت عملکرد سرور و سرویس خود اطمینان حاصل فرمائید.

چرا از به‌روزرسانی خودکار استفاده کنیم؟

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

در عین حال که می‌بایست در استفاده از به روزرسانی های خودکار، خصوصا در محیط های Production محتاط باشید، بررسی این موضوع حداقل در برخی شرایط ارزش بررسی دارد.

دلایل استفاده از به‌روزرسانی خودکار

هر چند کسی نمی تواند بصورت تضمینی این اطمینان را به شما بدهد که سرور شما کاندید مناسبی برای دریافت به روزرسانی های خودکار هست یا نه، بررسی چندین مورد می تواند در تصمیم گیری به شما کمک کند.

برخی از مواردی که در این خصوص می تواند به شما کمک کند به شرح ذیل است:

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

اگر تمامی موارد بالا برای شما صدق می کند ممکن است استفاده از این ویژگی برای شما گزینه خوبی باشد تا امنیت سرور خود را تامین کنید و اگر تمامی موارد بالا برای شما وجود نداشت حداقل می توانید ریسک انجام این کار را برآورد کنید و در این خصوص تصمیم گیری کنید.

دلایل عدم استفاده از به‌روزرسانی خودکار

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

عملکرد دائمی سیستم شما به قدری حیاتی است که شما و یا سازمان نمیتوانید لحظه ای قطعی سرویس را تحمل کنید.
شما برنامه های دست نویس را استفاده می کنید، از سورس یک برنامه را compile کرده اید و یا عملکرد سرویس شما نیازمند یک نسخه خاص از یک پیش نیاز نرم افزاری است.
شما از یک kernel خاص و یا یک ماژول اختصاصی در kernel خود بهره می برید و یا برنامه شما از یک ویژگی منحصر به نسخه خاصی از kernel بهره می برد. (شما می توانید آپدیت های kernel را محدود کنید)
محیط کاری و نرم افزاری شما نیازمند بررسی دقیق هرگونه تغییر و یا نظارت بر عملکرد هر بخش از سرویس می باشد.
از یک مخزن (Repository) غیر استاندارد استفاده می کنید که ممکن است با برنامه هایی که در مخزن اصلی وجود دارند تداخل نسخه ای داشته باشند.

همچنین برخی موارد هستند که بررسی به روزرسانی ها قبل از نصب آنها قطعا روش درستی برای کار نیست که چند نمونه مثال خواهیم زد:

نیاز به بکاپ گیری قبل از اعمال به‌روزرسانی: حتی بهترین برنامه ها می‌تواند دارای ایراد باشند. ممکن است تنظیماتی داخل یک فایل داشته باشید که با آپدیت، آن تغییرات از دست بروند. یا ممکن است نسخه جدید یک برنامه نحوه تنظیمات آن فرق کرده باشد و یا برخی از flag ها در آن حذف و یا اضافه شده باشد که عدم وجود و یا وجود آنها منجر به خطا در سرویس شما بشود. بهتر است قبل از به روزرسانی سرویس هایی مانند وب سرور، بانک اطلاعاتی و پست الکترونیکی؛ حتما از فایلهای تنظیمات خود یک نسخه پشتیبان تهیه کنید.
عوارض پیش بینی نشده: برخی از برنامه ها ممکن است دارای عوارضی جانبی باشند مانند برنامه هایی که از ویژگی cron jobs بهره می‌برند. به روزرسانی بسته هایی مانند openssl، openldap و sql به روزرسانی های متعددی برای برنامه هایی که به نظر بی ربط می‌رسند دارند.
باگ: برخی از بسته ها ممکن است اسکریپت آپدیت کننده آن دارای ایراد باشد که بعد از نصب ممکن است با خطاهای ناشناخته و یا عجیب روبرو شوید. نمونه ای از این خطا ها قبلا در Mozilla مشاهده شده است که بعضا آیکن ها حذف شده و برای کاربران دچار اعصاب خوردی و یا مشکلات کاربری ایجاد کرده است.
به روزرسانی خودکار ممکن است تمامی مراحل لازم برای ارتقای امنیت سیستم را انجام ندهد. برای مثال DNF می تواند آپدیت های kernel را نصب کند اما تغییرات اعمال نمی شوند. بسیاری از اینگونه تغییرات نیازمند ریستارت شدن سرویس (daemon) و یا ریستارت سرور است. این موارد ممکن است برای کاربر شائبه این را ایجاد کند که سیستم امن شده است در صورتی که به‌روزرسانی اصلا اعمال نشده است.

روش استاندارد برای انجام به‌روزرسانی خودکار

اگر تصمیم به استفاده از این ویژگی دارید باید حداقل موارد ذیل را برای اطمینان از صحت عملکرد آن انجام دهید.

بسته هایی به روزرسانی را کنترل کنید که آیا بصورت کامل نصب شده اند و یا نیازمند انجام عملیات دستی هستند و یا خیر، که برای این مهم میتوانید لاگ را در مسیر var/log/dnf.log/ بررسی کنید.

شما می توانید موجودیت بسته به روزرسانی را به واسطه ایمیل اطلاع رسانی دریافت و بررسی کنید. با اعمال تنظیمات در فایل etc/dnf/automatic.conf/

[emitters]
emit_via = email
[email]
# The address to send email messages from.
email_from = noreply@zagrio.com
# List of addresses to send messages to.
email_to = support@zagrio.com
# Name of the host to connect to to send email messages.
email_host = localhost

[emitters]

emit_via = email

[email]

# The address to send email messages from.

email_from = noreply@zagrio.com

# List of addresses to send messages to.

email_to = support@zagrio.com

# Name of the host to connect to to send email messages.

email_host = localhost

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

تنظیمات فوق به این معناست که به محض اجرا شدن عملیات به روزرسانی؛ اطلاعات بسته های به روزرسانی موجود و همچنین لاگ بسته های دانلود شده و یا نصب شده مطابق تنظیمات فایل automatic.conf برای شما ارسال خواهد شد.

راهکارهای جایگزین

بجای استفاده از dnf-automatic می توانید از auter نیز استفاده کنید. عملکرد آن بسیار مشابه به dnf-automatic است اما انعطافپذیری بیشتری برای تنظیمات زمانبندی اجرا دارد و همچنین امکانات اضافه ای برای تنظیمات اجرای اسکریپ هایی قبل و بعد از اجرای به روزرسانی ها دارد که شامل ریستارت سرور نیز می شود. با این حال پیاده سازی این ویژگی ها نیازمند تنظیمات پیچیده تری می باشد.

sudo dnf install auter

1	sudo dnf install auter

پس از نصب می بایست فایل تنظیمات آن در مسیر etc/auter/auter.conf/ را ویرایش کنید.

Auter بصورت پیشفرض هیچگونه عملیاتی انجام نمی دهد و برای تنظیم باید از کد prep-- (برای دانلود) و همچنین apply-- (برای نصب) استفاده کنید. تنظیمات اجرای آن درون فایلهای cron که در مسیر etc/cron.d/auter/ وجود دارد که شامل تعداد بسیاری از مثال های قابل انجام می باشد.

برای تست فوری عملکرد آن می توانید از دستور زیر استفاده کنید:

auter --apply

1	auter --apply

برای غیرفعال سازی آن می توانید از دستور زیر استفاده کنید. این دستور برای Cron Job ها نیز عمل میکند:

auter --disable

1	auter --disable

راهکار جایگزین استفاده از به‌روزرسانی خودکار برای تامین امنیت

اطلاع رسانی

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

زمانبندی به روزرسانی ها

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

روش‌های دیگر تامین امنیت

اگر انجام این به روزرسانی ها را در دستور کار خود ندارید میتوانید از روش های دیگری به منظور تامین امنیت سرور اختصاصی و یا سرور ابری خودتان نیز استفاده کنید تا در مقابله با تهدیدات سایبری، نفوذ هکر ها و نشت داده های خود آسوده خاطر باشید. از جمله این موارد می‌توان به نصب دیوار آتش سخت افزاری و یا نرم افزاری (iptables, ipchains, tcp wrappers) اشاره نمود، همچنین عدم نصب برنامه های اضافی و عدم انجام کارهای پرخطر توسط سیستم سرور (استفاده از اینترنت، کنترل ایمیل و ..) به همراه کنترل و نظارت ورود غیرمجاز (بررسی لاگ های ورود، استفاده از سیستم های IDS و..) از جمله راه کار هایی است که می توانید برای افزایش امنیت و حفاظت از ماشین کاری خود انجام دهید.

منبع: مقالات آموزشی فدورا

نحوه پیدا کردن فایل‌های حجیم در سرورهای لینوکس از طریق SSH

زاگریو19 مرداد 1401

4.1kviews

در مرکز آموزش زاگریو قصد داریم به بررسی نحوه پیدا کردن فایل‌های حجیم در سرورهای لینوکس از طریق SSH رسیده و دستورات آن را به شما بگوییم.

دستورات لازم | بررسی نحوه پیدا کردن فایل‌های حجیم در سرورهای لینوکس

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

SSH

در توزیع های RedHat / CentOS / Fedora از دستور زیر استفاده کنید:

"find {/path/to/directory/} -type f -size +{size-in-kb}k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'

برای پیدا کردن فایل‌های بیش از ۵۰MB در پوشه فعلی از دستور زیر استفاده کنید:

$ find . -type f -size +50000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'

جهت جستجو در پوشه /var/log/ از دستور زیر استفاده کنید:

# find /var/log -type f -size +100000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'

در توزیع‌های Ubunto / Linux از دستور زیر استفاده کنید:

find {/path/to/directory} -type f -size +{file-size-in-kb}k -exec ls -lh {} \; | awk '{ print $8 ": " $5 }'

برای جستجو در پوشه فعلی:

$ find . -type f -size +10000k -exec ls -lh {} \; | awk '{ print $8 ": " $5 }'

نمونه خروجی:

./.kde/share/apps/akregator/Archive/http___blogs.msdn.com_MainFeed.aspx?Type=AllBlogs.mk4: 91M ./out/out.tar.gz: 828M ./.cache/tracker/file-meta.db: 101M ./ubuntu-8.04-desktop-i386.iso: 700M ./MSH/out/mp3/Shadmani: 230M

دستورات فوق فایل‌هایی را که بیش از ۱۰۰۰۰ کیلوبایت حجم دارند را نمایش می‌دهند.
جهت پیدا کردن کلیه فایل‌هایی که در پوشه Home هستند و حجم آن‌ها کمتر از ۵۰۰ بایت می‌باشد از دستور زیر استفاده کنید:

$ find $HOME -size -500b

یا

$ find ~ -size -500b

برای پیدا کردن فایل‌هایی که حجم آن‌ها دقیقا ۲۰ بلوک ۵۱۲ بایتی می باشد از دستور زیر استفاده کنید:

# find / -size 20

نحوه Zip و Unzip کردن فایل‌ ها به وسیله SSH

زاگریو20 تیر 1401

7.6kviews

در این مطلب، قصد داریم تا در مورد نحوه Zip و Unzip کردن فایل‌ ها به وسیله SSH، در مرکز آموزش زاگریو صحبت کنیم، تا به شما در زیپ و آنزیپ کردن فایل‌هایتان کمک کنیم.

نحوه Zip و Unzip کردن فایل‌ ها به وسیله SSH

در ادامه به بررسی این مورد به وسیله SSH خواهیم پرداخت :

نحوه Zip و Unzip کردن فایل‌ ها به وسیله SSH

مطالعه این مقاله را نیز از دست ندهید :

دستورات مفید SSH برای مدیریت CFS

1. ابتدا از طریق نرم‌افزار Putty و یا Terminal به سرور خود متصل شوید.

برای ZIP کردن فایل‌ها دستور زیر را تایپ کنید:

# zip -r myarchive.zip myfolder

این دستور یک آرشیو ZIP شده از تمامی فایل‌ها و sub directorie ها ایجاد می‌کند.

2. به سرور می‌گوید که تمامی فایل‌ها و sub directorie را شامل شود.

myarchive.zip: نام پوشه ZIP شده که می‌خواهیم ایجاد کنیم.
myfolder: نام پوشه‌ای که می‌خواهیم آنرا ZIP کنیم.

3. برای UNZIP کردن فایل ها دستور زیر را استفاده نمائید:

# unzip myarchive.zip

myarchive.zip نام فایلی است، که می‌خواهیم آن را از حالت فشرده خارج کنیم.

آموزش ایجاد Master-to-Master replication در MariaDB

Saman Yazdannik8 آذر 1399

752views

در این آموزش قصد داریم به بحث sql master-to-master replication بپردازیم، اگر نمی‌دانید که replication به شیوه master-to-master چیست در ادامه در این آموزش با ما همراه باشید، تا هم نحوه ایجاد و هم با این نوع replication آشنا شوید.

در این شیوه اجازه داده می‌شود که اطلاعات و داده ها توسط گروهی از سرورها ذخیره شوند و در هر زمان با آپدیت شدن این اطلاعات در هر کدام از این سرورها اطلاعات و داده‌های ما بروزرسانی و آپدیت شود. در مثال زیر ما از دو سرور استفاده می‌کنیم و همزمان در پیکربندی این سرورها آنها را Master و slave یکدیگر قرار می‌دهیم.

replication چیست

قبل از هرچیزی، به صورت مختصر به بررسی معنی کلمه Replication می‌رسیم، کلمه Replication، به معنی تشکیل کپی‌ها یا Replica‌ها از یک استوریج (storage)، روی استوریج (مخزن اطلاعات) دیگری است، تا در صورت بروز خرابی و حادثه، کپی از اطلاعات موجود باشد و داده‌ها به صورت دائمی پاک نشوند. مکان این دستگاه‌ها ممکن است از شهر یا کشور متفاوتی باشد.

استفاده از Replication، خصوصا برای شرکت‌هایی که اطلاعات مهم – mission critical data دارند بسیار مهم است. در پیاده سازی ریپلیکیشن باید تست‌های لازم انجام شود و بررسی شود که آیا پهنای باند لازم برای این کار فراهم است یا خیر.

موارد مورد نیاز ایجاد master-to-master replication

برای آموزش پیش رو ما فرض می‌کنیم که شما موارد زیر را در اختیار دارید و می‌توانید آن‌ها پیکربندی نمایید.

replication

دو سرور با دیتابیس MariaDB که از پیش نصب شده باشد.
یک دیتابیس نمونه
دسترسی روت به سرور
کلاینت SSH

در ادامه روند آموزش ما نام دیتابیس نمونه را replicate.db در نظر گرفته‌ایم. این دیتابیس در شروع آموزش اطلاعاتی در خود ندارد. اگر تمامی موارد بالا را در اختیار دارید می‌توانیم به سراغ ایجاد master-to-master replication برویم.

پیکربندی سرور A

این سرور قرار است اولین Master server ما باشد و باید آن را برای پروسه replication و فعال کردن آن آماده نماییم. برای این منظور دستور زیر را اجرا نمایید.

sudo nano /etc/my.cnf

1	sudo nano /etc/my.cnf

در بخش [mysqld] باید بخش‌های زیر را اضافه نمایید.

log-bin
server_id=1
replicate-do-db=replicate
bind-address=192.168.0.12

log-bin

server_id=1

replicate-do-db=replicate

bind-address=192.168.0.12

سپس sql سرور خود را دوباره راه اندازی نمایید.

systemctl restart mariadb

1	systemctl restart mariadb

به MariaDB خود با دسترسی روت لاگین نمایید. و یک یوزر master با دسترسی‌های مورد نیاز ایجاد نمایید.

CREATE USER '$master_username'@'%' IDENTIFIED BY '$master_password';

1	CREATE USER '$master_username'@'%' IDENTIFIED BY '$master_password';

GRANT REPLICATION SLAVE ON *.* TO '$master_username'@'%';

1	GRANT REPLICATION SLAVE ON . TO '$master_username'@'%';

FLUSH PRIVILEGES;

1	FLUSH PRIVILEGES;

SHOW MASTER STATUS;

1	SHOW MASTER STATUS;

کامند ‘SHOW MASTER STATUS’ لاگ باینری فعلی موقعیتی که master باید از آن replication را شروع نماید را نشان می‌دهد. مانند زیر:

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB|
+------------------+----------+--------------+------------------+
| mariadb-bin.000001 |      626 |            |                 |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

+------------------+----------+--------------+------------------+

+------------------+----------+--------------+------------------+

| mariadb-bin.000001 | 626 | | |

+------------------+----------+--------------+------------------+

1 row in set (0.00 sec)

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

پیکربندی سرور B

قبل از شروع پروسه replication توجه داشته باشید که دیتابیس ساخته شده در سرور A را کپی نموده و به اینجا منتقل نمایید. این سرور دومین master سرور ما می‌باشد و برای عملیات replication باید آن را پیکربندی نماییم. برای شروع مثل قبل دوباره از دستور:

sudo nano /etc/my.cnf

1	sudo nano /etc/my.cnf

در بخش [mysqld] باید بخش‌های زیر را اضافه نمایید.

log-bin
server_id=2
replicate-do-db=replicate
bind-address=192.168.0.15

log-bin

server_id=2

replicate-do-db=replicate

bind-address=192.168.0.15

سپس sql سرور خود را دوباره راه اندازی نمایید.

systemctl restart mariadb

1	systemctl restart mariadb

مانند قبل به صورت روت به دیتابیس خود متصل شوید و یک یوزر master با دسترسی‌های مورد نیاز ایجاد نمایید.

CREATE USER '$master_username'@'%' IDENTIFIED BY '$master_password';

1	CREATE USER '$master_username'@'%' IDENTIFIED BY '$master_password';

GRANT REPLICATION SLAVE ON *.* TO '$master_username'@'%';

1	GRANT REPLICATION SLAVE ON . TO '$master_username'@'%';

FLUSH PRIVILEGES;

1	FLUSH PRIVILEGES;

قدم بعدی شامل بعضی از اطلاعات سرور A می‌شود که باید در سرور B نیز وارد شوند برای وارد نمودن این اطلاعات باید مانند زیر عمل نمایید.

SLAVE STOP;

1	SLAVE STOP;

CHANGE MASTER TO MASTER_HOST = '192.168.0.12', MASTER_USER = '$master_username', MASTER_PASSWORD = '$master_password', MASTER_LOG_FILE = 'mariadb-bin.000001', MASTER_LOG_POS = 626;

1	CHANGE MASTER TO MASTER_HOST = '192.168.0.12', MASTER_USER = '$master_username', MASTER_PASSWORD = '$master_password', MASTER_LOG_FILE = 'mariadb-bin.000001', MASTER_LOG_POS = 626;

SLAVE START;

1	SLAVE START;

قدم آخری که در سرور B باید برای تکمیل مراحل replication انجام دهیم تا اطلاعات را دریافت نماید بر مستر لاگ ذخیره کند و به سرور A ارسال نماید.

SHOW MASTER STATUS;

1	SHOW MASTER STATUS;

دستور ‘SHOW MASTER STATUS‘ لاگ باینری فعلی موقعیتی که master باید از آن replication را شروع نماید را نشان می‌دهد. مانند زیر:

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB|
+------------------+----------+--------------+------------------+
| mariadb-bin.000002 |      635 |            |                 |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

+------------------+----------+--------------+------------------+

+------------------+----------+--------------+------------------+

| mariadb-bin.000002 | 635 | | |

+------------------+----------+--------------+------------------+

1 row in set (0.00 sec)

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

کامل کردن replication بر روی سرور A

برای اتمام پروسه replication نیاز است که به سرور A وارد شوید و در MariaDB لاگین نمایید تا اطلاعتی که از سرور B دریافت کردیم را در این سرور وارد نماییم برای این منظور مانند زیر عمل نمایید:

SLAVE STOP;

1	SLAVE STOP;

CHANGE MASTER TO MASTER_HOST = '192.168.0.15', MASTER_USER = '$master_username', MASTER_PASSWORD = '$master_password', MASTER_LOG_FILE = 'mariadb-bin.000002', MASTER_LOG_POS = 635;

1	CHANGE MASTER TO MASTER_HOST = '192.168.0.15', MASTER_USER = '$master_username', MASTER_PASSWORD = '$master_password', MASTER_LOG_FILE = 'mariadb-bin.000002', MASTER_LOG_POS = 635;

SLAVE START;

1	SLAVE START;

بررسی عملکرد درست master-to-master

حالا که تمام پیکربندی‌ها کامل شد نیاز است که بررسی کنیم که آیا سیستم به درستی کار می‌کند یا نه؟ برای این منظور به سرو A لاگین می‌نماییم و وارد دیتابیس MariaDB می‌شویم، حالا یک جدول در دیتابیس replicate.db می‌سازیم.

CREATE TABLE replicate.sample (`name` varchar(18));

1	CREATE TABLE replicate.sample (`name` varchar(18));

حالا وارد سرور B شوید در این سرور نیز باید جدول ساخته شده را مشاهده نمایید.

SHOW TABLES IN replicate;

1	SHOW TABLES IN replicate;

که به صورت زیر نمایش داده می‌شود:

+---------------------+
| Tables_in_replicate |
+---------------------+
| sample              |
+---------------------+
1 row in set (0.00 sec)

+---------------------+

| Tables_in_replicate |

+---------------------+

| sample |

+---------------------+

1 row in set (0.00 sec)

برای اینکه مطمئن شوید بر روی سرور B نیز این امر امکان پذیر است می‌توانید مانند عملیات بالا را برای سرور B نیز انجام دهید.

MongoDB 4.2.1: آموزش نصب در CentOS 8

Saman Yazdannik12 شهریور 1399

MongoDB یکی از معروفترین و پر استفاده ترین دیتابیس‌های NoSQL است که به تازگی نسخه‌ی جدید عرضه نموده که قابلیت پشتیبانی از CentOS 8 را داراست، همانطور که شاید در جریان باشید برای CentOS 8 فقط می‌توانید از نسخه‌های 4 دیتابیس MongoDB استفاده نمایید و نسخه‌های قدیمی‌تر مانند نسخه 3 بر روی آن نصب نمی‌گردند! پس یا باید به فکر ارتقا CentOS خود به نسخه‌بالاتر باشید یا از MongoDB ورژن پایین‌تر استفاده نمایید.

MONGODB 4.2.1 خب برویم سراغ اصل مطلب و نصب MongoDB بر CentOS8، دراینجا فرض من این است که شما یا با دسترسی root به سرور خود متصل شده‌ای یا یک نام کاربری با دسترسی sudo ، در ادامه نیاز است که شما یک فایل در این دایرکتوری /etc/yum.repos.d/mongodb-org-4.2.repo با محتویات زیر بسازید:

[mongodb-org-4.2]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/4.2/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-4.2.asc

[mongodb-org-4.2]

name=MongoDB Repository

baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/4.2/x86_64/

gpgcheck=1

enabled=1

gpgkey=https://www.mongodb.org/static/pgp/server-4.2.asc

و سپس با استفاده از yum آن را نصب نمایید:

yum install -y mongodb-org

1	yum install -y mongodb-org

فرایند نصب چند ثانیه طول خواهد کشید. سپس چیزی مانند زیر مشاهده خواهید نمود:

[root@lab ~]# yum install -y mongodb-org
CentOS-8 - AppStream 2.0 kB/s | 4.3 kB 00:02
CentOS-8 - Base 1.7 kB/s | 3.9 kB 00:02
CentOS-8 - Extras 744 B/s | 1.5 kB 00:02
CentOS-8 - PowerTools 1.7 kB/s | 4.3 kB 00:02
Google Cloud SDK 205 B/s | 454 B 00:02
Google Compute Engine 199 B/s | 454 B 00:02
MongoDB Repository 2.0 kB/s | 4.5 kB 00:02
Dependencies resolved.
========================================================================================================================================================================
Package Arch Version Repository Size
========================================================================================================================================================================
Installing:
mongodb-org x86_64 4.2.2-1.el8 mongodb-org-4.2 10 k
Installing dependencies:
mongodb-org-mongos x86_64 4.2.2-1.el8 mongodb-org-4.2 14 M
mongodb-org-server x86_64 4.2.2-1.el8 mongodb-org-4.2 25 M
mongodb-org-shell x86_64 4.2.2-1.el8 mongodb-org-4.2 17 M
mongodb-org-tools x86_64 4.2.2-1.el8 mongodb-org-4.2 47 M
Transaction Summary
========================================================================================================================================================================
Install 5 Packages
Total download size: 103 M
Installed size: 260 M
Downloading Packages:
(1/5): mongodb-org-4.2.2-1.el8.x86_64.rpm 9.1 kB/s | 10 kB 00:01
(2/5): mongodb-org-mongos-4.2.2-1.el8.x86_64.rpm 9.1 MB/s | 14 MB 00:01
(3/5): mongodb-org-shell-4.2.2-1.el8.x86_64.rpm 31 MB/s | 17 MB 00:00
(4/5): mongodb-org-server-4.2.2-1.el8.x86_64.rpm 14 MB/s | 25 MB 00:01
(5/5): mongodb-org-tools-4.2.2-1.el8.x86_64.rpm 59 MB/s | 47 MB 00:00
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 44 MB/s | 103 MB 00:02
warning: /var/cache/dnf/mongodb-org-4.2-fddc3ec541fac48b/packages/mongodb-org-4.2.2-1.el8.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID 058f8b6b: NOKEY
MongoDB Repository 1.5 kB/s | 1.7 kB 00:01
Importing GPG key 0x058F8B6B:
Userid : "MongoDB 4.2 Release Signing Key &lt;packaging@mongodb.com&gt;"
Fingerprint: E162 F504 A20C DF15 827F 718D 4B7C 549A 058F 8B6B
From : https://www.mongodb.org/static/pgp/server-4.2.asc
Key imported successfully
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : mongodb-org-tools-4.2.2-1.el8.x86_64 1/5
Installing : mongodb-org-shell-4.2.2-1.el8.x86_64 2/5
Running scriptlet: mongodb-org-server-4.2.2-1.el8.x86_64 3/5
Installing : mongodb-org-server-4.2.2-1.el8.x86_64 3/5
Running scriptlet: mongodb-org-server-4.2.2-1.el8.x86_64 3/5
Created symlink /etc/systemd/system/multi-user.target.wants/mongod.service → /usr/lib/systemd/system/mongod.service.
Installing : mongodb-org-mongos-4.2.2-1.el8.x86_64 4/5
Installing : mongodb-org-4.2.2-1.el8.x86_64 5/5
Running scriptlet: mongodb-org-4.2.2-1.el8.x86_64 5/5
Verifying : mongodb-org-4.2.2-1.el8.x86_64 1/5
Verifying : mongodb-org-mongos-4.2.2-1.el8.x86_64 2/5
Verifying : mongodb-org-server-4.2.2-1.el8.x86_64 3/5
Verifying : mongodb-org-shell-4.2.2-1.el8.x86_64 4/5
Verifying : mongodb-org-tools-4.2.2-1.el8.x86_64 5/5
Installed:
mongodb-org-4.2.2-1.el8.x86_64 mongodb-org-mongos-4.2.2-1.el8.x86_64 mongodb-org-server-4.2.2-1.el8.x86_64 mongodb-org-shell-4.2.2-1.el8.x86_64
mongodb-org-tools-4.2.2-1.el8.x86_64
Complete!
[root@lab ~]#

[root@lab ~]# yum install -y mongodb-org

CentOS-8 - AppStream 2.0 kB/s | 4.3 kB 00:02

CentOS-8 - Base 1.7 kB/s | 3.9 kB 00:02

CentOS-8 - Extras 744 B/s | 1.5 kB 00:02

CentOS-8 - PowerTools 1.7 kB/s | 4.3 kB 00:02

Google Cloud SDK 205 B/s | 454 B 00:02

Google Compute Engine 199 B/s | 454 B 00:02

MongoDB Repository 2.0 kB/s | 4.5 kB 00:02

Dependencies resolved.

========================================================================================================================================================================

Package Arch Version Repository Size

========================================================================================================================================================================

Installing:

mongodb-org x86_64 4.2.2-1.el8 mongodb-org-4.2 10 k

Installing dependencies:

mongodb-org-mongos x86_64 4.2.2-1.el8 mongodb-org-4.2 14 M

mongodb-org-server x86_64 4.2.2-1.el8 mongodb-org-4.2 25 M

mongodb-org-shell x86_64 4.2.2-1.el8 mongodb-org-4.2 17 M

mongodb-org-tools x86_64 4.2.2-1.el8 mongodb-org-4.2 47 M

Transaction Summary

========================================================================================================================================================================

Install 5 Packages

Total download size: 103 M

Installed size: 260 M

Downloading Packages:

(1/5): mongodb-org-4.2.2-1.el8.x86_64.rpm 9.1 kB/s | 10 kB 00:01

(2/5): mongodb-org-mongos-4.2.2-1.el8.x86_64.rpm 9.1 MB/s | 14 MB 00:01

(3/5): mongodb-org-shell-4.2.2-1.el8.x86_64.rpm 31 MB/s | 17 MB 00:00

(4/5): mongodb-org-server-4.2.2-1.el8.x86_64.rpm 14 MB/s | 25 MB 00:01

(5/5): mongodb-org-tools-4.2.2-1.el8.x86_64.rpm 59 MB/s | 47 MB 00:00

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Total 44 MB/s | 103 MB 00:02

warning: /var/cache/dnf/mongodb-org-4.2-fddc3ec541fac48b/packages/mongodb-org-4.2.2-1.el8.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID 058f8b6b: NOKEY

MongoDB Repository 1.5 kB/s | 1.7 kB 00:01

Importing GPG key 0x058F8B6B:

Userid : "MongoDB 4.2 Release Signing Key <packaging@mongodb.com>"

Fingerprint: E162 F504 A20C DF15 827F 718D 4B7C 549A 058F 8B6B

From : https://www.mongodb.org/static/pgp/server-4.2.asc

Key imported successfully

Running transaction check

Transaction check succeeded.

Running transaction test

Transaction test succeeded.

Running transaction

Preparing : 1/1

Installing : mongodb-org-tools-4.2.2-1.el8.x86_64 1/5

Installing : mongodb-org-shell-4.2.2-1.el8.x86_64 2/5

Running scriptlet: mongodb-org-server-4.2.2-1.el8.x86_64 3/5

Installing : mongodb-org-server-4.2.2-1.el8.x86_64 3/5

Running scriptlet: mongodb-org-server-4.2.2-1.el8.x86_64 3/5

Created symlink /etc/systemd/system/multi-user.target.wants/mongod.service → /usr/lib/systemd/system/mongod.service.

Installing : mongodb-org-mongos-4.2.2-1.el8.x86_64 4/5

Installing : mongodb-org-4.2.2-1.el8.x86_64 5/5

Running scriptlet: mongodb-org-4.2.2-1.el8.x86_64 5/5

Verifying : mongodb-org-4.2.2-1.el8.x86_64 1/5

Verifying : mongodb-org-mongos-4.2.2-1.el8.x86_64 2/5

Verifying : mongodb-org-server-4.2.2-1.el8.x86_64 3/5

Verifying : mongodb-org-shell-4.2.2-1.el8.x86_64 4/5

Verifying : mongodb-org-tools-4.2.2-1.el8.x86_64 5/5

Installed:

mongodb-org-4.2.2-1.el8.x86_64 mongodb-org-mongos-4.2.2-1.el8.x86_64 mongodb-org-server-4.2.2-1.el8.x86_64 mongodb-org-shell-4.2.2-1.el8.x86_64

mongodb-org-tools-4.2.2-1.el8.x86_64

Complete!

[root@lab ~]#

حالا بیایید با دستور زیر بررسی نماییم که نصب ما به درستی صورت گرفته است یا خیر:

[root@lab ~]# mongo --version
MongoDB shell version v4.2.2
git version: a0bbbff6ada159e19298d37946ac8dc4b497eadf
OpenSSL version: OpenSSL 1.1.1 FIPS 11 Sep 2018
allocator: tcmalloc
modules: none
build environment:
distmod: rhel80
distarch: x86_64
target_arch: x86_64
[root@lab ~]#

[root@lab ~]# mongo --version

MongoDB shell version v4.2.2

git version: a0bbbff6ada159e19298d37946ac8dc4b497eadf

OpenSSL version: OpenSSL 1.1.1 FIPS 11 Sep 2018

allocator: tcmalloc

modules: none

build environment:

distmod: rhel80

distarch: x86_64

target_arch: x86_64

[root@lab ~]#

خب اگر متنی مانند بالا مشاهده نمودید نشانگر آن است که نصب شما به درستی صورت گرفته است و می‌توانید از MongoDB خود استفاده نمایید.

دیتابیس MySQL: بکاپ گیری و بازگرداندن آن

Saman Yazdannik7 شهریور 1399

1.6kviews

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

دیتابیس MySQL چیست ؟

قبل از هر چیزی بهتر است تا با مبحث دیتابیس MySQL آشنا شوید. MySQL در واقع یک سیستم مدیریت پایگاه داده‌ای (database) است، که به صورت رابطه‌ای منبع باز (open source) با یک مدل کلاینت – مدیریت سرور خدمات‌دهی می‌کند.

قدم اول برای بکاپ دیتابیس MySQL

خب در اولین اقدام نیاز است تا شما با استفاده از SSH به وارد VPS خود شوید و سپس با اجرای چند فرمان که در زیر به آن‌ها کی‌پردازیم از دیتابیس خود پشتیبان تهیه نمایید. و در ادمه آن را در بخش دیگری از سرور خود یا در کامپیوتر شخصی خود ذخیره نمایید.

دستورات SQL می‌توانند سرور را به انجام برخی عملیات زیر کنترل کنند:

پرس و جو داده‌ها (Data query): درخواست اطلاعات خاص از پایگاه داده موجود.
دستکاری داده‌ها (Data manipulation): اضافه کردن، حذف، تغییر، مرتب سازی و سایر عملیات برای تغییر داده‌ها، مقادیر یا تصاویر.
هویت داده (Data identity): تعریف انواع داده، به عنوان مثال تغییر داده‌های عددی به اعداد صحیح را می‌توان نامبرد.
کنترل دسترسی به داده‌ها (Data access control): ارائه تکنیک‌های امنیتی برای محافظت از داده‌ها، این شامل تصمیم گیری در مورد اینکه چه کسی می‌تواند اطلاعات موجود در پایگاه داده را مشاهده یا استفاده کند، می‌شود.

دیتابیس MySQL

mysqldump -u username -p database-name &gt; backup-name.sql

1	mysqldump -u username -p database-name > backup-name.sql

در کامن بالا نیاز است تا username و password (جهت امنیت سرور ) را با نام کاربری و رمز عبور خود جایگزین نمایید. در بخش database-name نیز لاز است نام دیتابیس خود را وارد نمایید. backup-name نیز نام نسخه پشتیبان شما می‌باشد، که قرار است ذخیره شود، می‌توانید نام آن را به هرچیزی که علاقه دارید تغییر دهید.

بعد از اجرای این کامند، از شما پسورد می‌خواهد و بعد از وارد کردن پسورد توسط شما، بکاپ دیتابیس شما آماده است!

حالا اگر شما می‌خواهید از دیتابیس wordpress خود نسخه پشتیبان تهیه کنید باید از دستور زیر استفاده نمایید.

mysqldump -u WordPressUser -p WordPressDB &gt; wordpress.sql

1	mysqldump -u WordPressUser -p WordPressDB > wordpress.sql

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

rsync -Waq backup-name.sql /path/to/directory/

1	rsync -Waq backup-name.sql /path/to/directory/

در این دستور هم فراموش نکنید که نام‌های مورد نظر خود را مطابق با نام دیتابیس و دایرکتوری مورد نظر خود تغییر دهید.

بعضی مواقع شما نیاز دارید تا بکاپ مورد نظر خود را در سیستم شخصی خود دانلود و ذخیره نمایید تا اگر سرور شما دچار مشکلی شد بتوانید از بکاپ خود از سیستم خود استفاده نمایید.

rsync -Waq -e 'ssh -p port-number' username@IP-Address:/backup-name.sql /path/to/local/directory

1	rsync -Waq -e 'ssh -p port-number' username@IP-Address:/backup-name.sql /path/to/local/directory

برای بازگرداندن بکاپ مورد خود می‌توانید از دستور زیر استفاده نمایید |دیتابیس MySQL

mysql -u username -p database-name &lt; backup-name.sql

1	mysql -u username -p database-name < backup-name.sql

HTTP/2 در Nginx: راهنمای فعال سازی

Saman Yazdannik25 مرداد 1399

637views

HTTP/2 نسخه جدید پروتکل منسوخ شده HTTP/1.1 می‌باشد که در سال 1999 به یک استاندارد کلی تبدیل شد. از آن زمان تا حالا تغییرات زیادی در سطح وب صورت گرفته است. وب اپلیکیشن‌های ما بسیار پیچیده تر شده‌اند و با وب اپلیکیشن‌های سال اواخر دهه نود و اوایل هزاره جدید قابل مقایسه نیستند. در این زمان تهدیدات هم افزایش یافت برای مقابله با این تهدیدات نیاز بود که HTTP/2 متولد شود.

مهمترین نکته درمورد HTTP/2 سریعتر بود آن نسبت به HTTP/1.1 برای کاربران مصرف کنند است، یعنی مصرف کننده‌های نهایی سایت سریعتری در اختیار خواهند داشت.

تعدادی از ویژگی‌های های HTTP/2:

HTTP/2 یک پروتکل باینری است.
HTTP/2 با HTTP/1.1 قابلیت هم‌خوانی و بازگشت به نسخه قبل را دارد.
HTTP/2 در سال 2015 عرضه شد.
دو مشخصه اصلی HTTP/ 2 را می‌توان: 1.پروتکل انتقال Hypertext نسخه 2 – RFC7540 و 2.فشرده سازی هدر RFC7541 در نظر گرفت
HTTP / 2 برنامه های ما را سریعتر ، ساده تر و قوی تر می کند.
هداف اصلی برای توسعه HTTP / 2 کاهش تأخیر بوده است.
HTTP / 2 براساس پروتکل SPDY گوگل است.
مرورگرها برای استفاده از HTTP / 2 به TLS مدرن نیاز دارند.
برای استفاده از HTTP/2 نیاز است که نسخه TLS ما حداقل 1.2 باشد. آموزش ارتقا TLS در این مقاله به تفصیل توضیح داده شده است.
اگر برای استفاده از HTTP /2 از یک سرور با TLS پایین تر از مقدار ذکر شده استفاده شود در اینصورت با خطای پروتکل روبرو می‌شویم.
برخی از ویژگی های اصلی HTTP / 2 عبارتند از: multiplexing ، فشرده سازی هدر ، اولویت بندی

ملزومات برای راه اندازی HTTP/2:

در قدم اول نیاز است Nginx را از ریپازیتوری اصلی نصب نمایید. برای الین کمنظور از کامند زیر استفاده نمایید:

wget https://nginx.org/keys/nginx_signing.key
apt-key add nginx_signing.key
printf "deb https://nginx.org/packages/mainline/ubuntu/ `lsb_release -sc` nginx \ndeb-src https://nginx.org/packages/mainline/ubuntu/ `lsb_release -sc` nginx \n" &gt;&gt; /etc/apt/sources.list.d/nginx_mainline.list
apt update
apt install -y nginx

wget https://nginx.org/keys/nginx_signing.key

apt-key add nginx_signing.key

printf "deb https://nginx.org/packages/mainline/ubuntu/ `lsb_release -sc` nginx \ndeb-src https://nginx.org/packages/mainline/ubuntu/ `lsb_release -sc` nginx \n" >> /etc/apt/sources.list.d/nginx_mainline.list

apt update

apt install -y nginx

بعد از اجرای این کامند می‌‍توانید مطمئن باشید که Nginx نصب شده است.

پیکربندی Nginx برای HTTP/2

پیکر بندی Nginx برای HTTP/ 2 بسیار راحت است و زمان کمی از شما خواهد گرفت برای این منظور نیاز است که تنها مقدار دستوردهنده listen را برای http2 درست تنظیم نمایید. و همانطور که قبلا هم اشاره کردیم لازم است TLS شما ورژن 1.2 یا بالاتر باشد.

server {
listen 80;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2 default_server;
server_name example.com www.example.com;
root /path/to/public;
ssl_certificate /path/to/certificate.pem;
ssl_certificate_key /path/to/private_key.pem;
ssl_protocols TLSv1.2 TLSv1.3;
}

server {

listen 80;

return 301 https://$host$request_uri;

}

server {

listen 443 ssl http2 default_server;

server_name example.com www.example.com;

root /path/to/public;

ssl_certificate /path/to/certificate.pem;

ssl_certificate_key /path/to/private_key.pem;

ssl_protocols TLSv1.2 TLSv1.3;

}

همانطور که متوجه شدید فعال سازی HTTP/ 2 بر روی ابنتو بسیار راحت است و برای دیگر سیستم عامل‌ها هم همین روش صادق است و تنها نیاز است که تعدادی از دستورات را طبق همان سیستم‌عامل وارد نمایید.

Apache/Prefork: تعیین حداکثر تعداد کلاینت‌ها

زاگریو20 تیر 1397

1.5kviews

اصول اولیه Apache/Prefork:

۱- تعیین مقدار RAM که برای Apache/Prefork در دسترس است.

۲- تعیین مقدار RAM برای هر کاربر آپاچی

۳- تنظیم حداکثر تعداد کلاینت‌ها به: (مقدار RAM در هر فرآیند آپاچی) / (مقدار RAM در دسترس آپاچی)

۴- نظارت و تنظیم

چگونه مقادیر را در Apache/Prefork تغییر دهیم:

مقادیر حداکثر تعداد کلاینت‌ها (MaxClients) در فایل اصلی main Apache configuration قرار گرفته است. به عنوان مثال /etc/apache2/apache2.conf یا /etc/httpd/httpd.conf.

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

بعد از تغییر مقادیر فایل را دخیره کنید و Apache را با دستور apache2ctl graceful-stop && apache2ctl start ری‌استارت نمائید.

چرا این موضوع مهم است؟

یکی از شایع‌ترین دلایل سقوط یک وب سرور این است که تمام حافظه فیزیکی (RAM) موجود را مصرف می‌کند. وقتی که این اتفاق پیش می‌آید، سیستم عامل با حرکت بر روی دیسک تلاش می‌کند مقداری از این فضا را آزاد کند. در لینوکس این عمل Swap Space و در ویندوز Page File نامیده می‌شود. این فرآیند به منظور شکست دادن RAM (که دسترسی سریع به داده‌ها را فراهم می‌کند) است و نیاز به منابع (CPU، دیسک I/O) برای انجام مبادله داده‌ها بین دیسک و RAM دارد. فضای جابجایی هم می‌تواند به طور کامل مصرف شود، اما مشکل اصلی این است که در یک محیط با سرعت بالا مانند وب سرور، سیستم به سرعت می‌تواند سرزیر شود و فقط تلاش برای مدیریت حافظه می‌تواند برای این سقوط موثر باشد. به همین دلیل به آن Thrashing می‌گویند.

به این کار اجتناب از شکست گفته می‌شود و تنها راه برای انجام این کار این است که آپاچی را از مصرف تمام RAM در دسترس نگهداری شود.

چگونه مقدار RAM موجود برای Apache/Prefork را تعیین کنیم:

مقدار حافظه در دسترس برای آپاچی مجموع مقدار RAM روی سیستم منهای مقداری است که توسط تمام فرآیندهای دیگر استفاده می‌شود. متاسفانه، تعیین مقدار RAM که بر روی سیستم استفاده می‌شود دشوار است. این مورد حتی از تعیین حداکثر حافظه‌ای که توسط دیگر فرآیندها زمانی که سرور تحت بار سنگین قرار دارد مشکل‌تر است. حتی زمانی که شما در حال اجرای Mysql بر روی همان سیستم هستید کار محاسبه دشوارتر می‌شود. به طور معمول هر درخواست که توسط Apache/Prefork به کار گرفته می‌شود حداقل یک اتصال با Mysql را باز می‌کند، بنابراین به عنوان یک درخواست آپاچی میزان مصرف RAM توسط Mysql افزایش می‌یابد. در کوتاه مدت، میزان مصرف حافظه Mysql بستگی دارد به اینکه چگونه آنرا توسط نرم‌افزار خود استفاده می‌شود. شما می‌توانید از اسکریپت mysqltuner برای دریافت حداکثر مقدار Mysql استفاده کنید. اما اگر تنظمیات آپاچی شما به درستی صورت گرفته باشد به ندرت مشکلی درباره میزان حافظه خواهید داشت.

بهترین راه‌کار این است که Mysql را که مصرف بالایی دارد در یک سرور جداگانه قرار دهیم و بیشترین مقدار را برای آن سرور در نظر بگیریم و با توجه به Server load تنظیمات را انجام دهیم.

برای تمامی فرآیندهای دیگر مقدار ۲۵۶MB را در نظر بگیرید. اگر شما در حال استفاده از خدمات دیگری همانند ماشین میزبانی مجازی هستید، ممکن است تمایل داشته باشید که از مقدار بیشتری استفاده کنید.

بنابراین در ابتدا برای یک سیستم معمولی ۲۵۶MB + حداکثر استفاده حافظه Mysql را در نظر بگیرید.

چگونه میزان RAM را برای مصرف هر فرآیند Apache تعیین کنیم:

باز هم، به حافظه مشترک (مخصوصا اگر از APC استفاده می‌کنید) بافر، دخیره و غیره توجه کنید. تعیین این موارد خیلی دشوار است. در تجربه ما، بهترین ابزار تعیین مصرف حافظه برای هر فرآیند ps_mem.py است.

خروجی ps_mem.py شبیه شکل زیر است:

در اینجا مشاهده می‌کنید که ۱۲۳ فرآیند Apache2 وجود دارد که در مجموع ۴٫۳GB مصرف حافظه دارند، بنابراین هر فرآیند Apache/Prefork حدود ۲۸MB از فضای RAM را استفاده می‌کنند. این سیستم حدود ۸GB حافظه (RAM) دارد و اگرچه ysqltuner.pl گزارش می‌دهد که Mysql حداکثر ۱GB از حافظه را مصرف می‌کند، ما می‌توانیم ببینم که مقداری که مصرف شده خیلی کمتر از ۱GB است. برای اطمینان برای دیگر فرآیندها ۱٫۵GB حافظه در نظر می‌گیریم و میانگین مصرف آپاچی را به ۳۲MB گرد می‌کنیم.

(۶٫۵ x 1024) / 32 = 208

برای اطمینان بیشتر آنرا به ۲۰۰ گرد می‌کنیم، زیرا بهتر است که کمتر تخمین زده شود.

نظارت کردن بر سرور:

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

watch -n 1 “echo -n ‘Apache Processes: ‘ && ps -C apache2 –no-headers | wc -l && free -m”

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

با استفاده از +/- سطر را بافر / ذخیره کنید. مقادیر برحسب MB است. شما می‌توانید در یک نقطه از زمان ببینید که حدود ۲٫۳GB از حافظه استفاده می‌شود و ۵٫۷GB از حافظه آزاد است. اگر فرآیندهای Apache/Prefork به تنظیمات حداکثر تعداد کلاینت‌ها نزدیک شوند و مقدار زیادی حافظه در دسترس خواهید داشت که شما می‌توانید قدم به قدم این مقدار را افزایش دهید تا این مقدار به کمتر از حداکثر تعداد کلاینت‌ها برسد و سپس آنرا Restart کنید.