Skip to Content

بلاگ

ایجاد اتصال SSH بدون Password در لینوکس

ایجاد اتصال SSH بدون Password

SSH Passwordless Login در پنج قدم

در این پست نحوه پیکربندی و ایجاد اتصال SSH بدون Password  یا اصطلاحا Password-Less Login را بین دو سرور مرور خواهیم کرد.  در این روش اتصال از طریق SSH Key انجام خواهد گرفت. از مزیت های این روش که اغلب بین سرور های Trust  ایجاد می شود، می توان به راحتی تبادل فایل، پشتیبان گیری به صورت ریموت،  مدیریت سرور مقصد به صورت ریموت و …  اشاره کرد.

در محیطی این آموزش سرور مبدا و مقصد با مشخصات زیر می باشند.

سرور مبدا یا سروری که قرار است اتصال بدون Password  از طریق آن انجام شود با آدرس 172.17.105.29

سرور مقصد که قرار است اتصال بدون Password  به آن انجام پذیرد با آدرس 172.17.105.28

قدم اول :

 

اتصال به سرور مبدا و ایجاد یک جفت کلید عمومی از طریق دستور زیر، در اینجا من از نام کاربری root  بین دو سرور استفاده میکنم و در صورت تمایل میتوانید از نام های کاربری دیگری غیر از root  هم استفاده کنید.

[root@hamed-lab ~]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
0e:74:10:1c:b5:08:59:fb:e0:eb:7b:8a:d6:dd:34:6b root@hamed-lab
The key's randomart image is:
+--[ RSA 2048]----+
|    .+=+.        |
|    ...+ .       |
|      = o        |
|     o +         |
|      o S        |
|       +  o      |
|     ....o o     |
|    .o. o E      |
|   .. ++ .       |
+-----------------+

قدم دوم:

ایجاد دایکتوری ای با نام .ssh در Home Directory  کاربر، در سرور مقصد که در اینجا ما این عمل را از طریق SSH و از سرور مبدا انجام می دهیم.

[root@hamed-lab ~]# ssh root@172.17.105.28 mkdir -p .ssh
root@172.17.105.28's password: 

 

قدم سوم

محتویات فایل id_rsa.pub که در مرحله اول ایجاد شده است باید در سرور مقصد ودر فایل authorized_keys و در  مسیر ایجاد شده در مرحله قبل وارد شود.

[root@hamed-lab ~]# cat .ssh/id_rsa.pub | ssh root@172.17.105.28 'cat >> .ssh/authorized_keys'
root@172.17.105.28's password: 

قدم چهارم

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

[root@hamed-lab ~]# ssh root@172.17.105.28 "chmod 700 .ssh ; chmod 640 .ssh/authorized_keys"
root@172.17.105.28's password: 

مرحله پنجم

اتصال بدون Password

اگر مراحل بالا به درستی انجام شده، از این به بعد اتصال به سرور مقصد از طریق کاربر root  بدون Password  انجام خواهد شد.

[root@hamed-lab ~]# ssh root@172.17.105.28 
Last login: Mon Sep 18 21:57:13 2017 from 172.17.105.29
[root@localhost ~]# ifconfig 
eno16780032: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.105.28  netmask 255.255.255.128  broadcast 172.17.105.127
        inet6 fe80::250:56ff:feba:16f2  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:ba:16:f2  txqueuelen 1000  (Ethernet)
        RX packets 734175  bytes 42688092 (40.7 MiB)
        RX errors 0  dropped 245  overruns 0  frame 0
        TX packets 4779  bytes 790935 (772.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 10  bytes 964 (964.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10  bytes 964 (964.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

امیدوارم مفید واقع شده باشد.

ادامه مطلب

نصب و راه اندازی سرویس VSFTP در CentOS

نصب و راه اندازی سرویس VSFTP در CentOS

آموزش گام به گام نصب و راه اندازی سرویس FTP در لینوکس

آموزش نصب و راه اندازی سرویس VSFTP در CentOS

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

FTP چیست:

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

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

vsftp چیست؟:

vsftp یکی از سرویس های ارائه FTP است که مخفف کلمات Very Secure File Transfer Protocol  میباشد. این سرویس به علت امنیتی که در عین سادگی پیکربندی فراهم میکند بسیار مورد توجه قرار گرفته است و به صورت گسترده نیز در حال استفاده است. برخی از امکانات این سرویس به شرح زیر است:

    • امکان استفاده از virtual IP
    • پشتیبانی از virtual user
    • قابلیت کار به صورت Standalone یا تحت نظر inetd
    • فراهم بودن ایجاد محدودیت در پهنای باند
    • پشتیبانی از IPv6
    • رمز نگاری اطلاعات از طریق ssl

نصب و راه اندازی vsftp:

در این آموزش از سیستم عامل CentOS به عنوان سرور استفاده شده است. پکیج مربوط به این سرویس vsftpd نام دارد و در repository های پیش فرض این سیستم عامل قرار دارد.

با استفاده از yum پیکیج vsftpd  را نصب می نماییم.

yum –y install vsftpd

بعد دانلود و نصب پیکیج های مورد نیاز، می بایست سرویس را start  و  enable  کرده تا سرویس در هر بار بوت به صورت اتوماتیک اجرا گردد.

systemctl enable vsftpd 
systemctl start vsftpd

حال برای این که امکان سرویس دهی از طریق پروتکل ftp  به سیستم های داخل شبکه فراهم شود، نیاز است رول های مربوطه در firewalld  به صورت دائمی اضافه گردند.  در غیر این صورت فایروال اتصال کاربران از طریق این پروتکل را به صورت پیش فرض نمی دهد.

firewall-cmd --zone=public --permanent --add-port=21/tcp
firewall-cmd  --zone=public --permanent --add-service=ftp
firewall-cmd –reload

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

پارامترهای فایل پیکربندی:

سرویس vsftp نیز همانند اکثر سرویس های لینوکسی پارامتر های پیکربندی را از قایل پیکربندی آن و  درمسیر    /etc/vsftpd/vsftpd.conf مقدار دهی خواهد کرد. برخی از پارامتر های مورد استفاده در این سرویس به همراه توضیحی مختصر از آنها به شرح جدول زیر می باشد.

anonymous_enable مشخص کننده این است که آیا امکان اتصال به سرور به صورت ناشناس وجود دارد یا خیر در حالت پیش فرض مقدار این گزینه برابر با yes است که به این معنی می باشد که نام های کاربری anonymous و ftp امکان اتصال به سرور را دارا می باشند.
local_enable_enable امکان authentication را بر اساس نام های کاربری local فراهم می سازد. درواقع این گزینه امکان authentication کاربران را بر اساس فایل /etc/passwd فراهم میکند.
write_enable در صورت فعال بودن، اجازه استفاده از دستوراتی که منجر به نوشتن بر روی دیسک میشود را فراهم میکند. مانند put یا del
local_umask مشخص کننده umask پیش فرض فایل های ایجاد شده می باشد. مقدار پیش فرض022 می باشدکه برابر با ۷۵۵ در دستورchmod است.
dirmessage_enable هنگامی که کاربری به دایرکتوری ای جدید وارد میشود در صورت yes بودن این گزینه و موجود بودن فایل message_file پیغامیکه درون آن فایل قرار دازد در هنگام تغییر دایرکتوری به وی نمایش داده می شود.
message_file بیان گر نام فایلی است که قرار است پیغام آن به کاربر نمایش داده شود.
connect_from_port_20 استفاده از پورت 20 را به عنوان data channel فعال یا غیر فعال میکند. این گزینه با yes یا no مقدار دهی می شود.
ftp_data_port در صورتی که قصد داشته باشیم data channel بر روی پورتی غیر از پورت 20 فعالیت کند می بایست گزینه بالا را برابر با no قرار داده و از طریق ftp_data_port پورت مورد نظر را مشخص نمائیم.
xferlog_std_format در صورت no بودن، لاگ های اتصال کاربران در مسیر /var/log/vsftpd.log ثبت و ذخیره مشود.
listen این گزینه مشخص کننده این است که سرویس به صورت standalone فعالیت کند یا خیر. در صورتی که این گزینه no باشد سرویس تحت مدیریت xinetd فعالیت خواهد کرد در غیر این صورت به عنوان سرویسی خود تمام وظایف مانند listen کردن بر روی پورت ها را بر عهده میگیرد.
معمولا در صورتی این گزینه no قرار داده میشود که قرار باشد بر روی IPv4 و IPv6 به صورت همزمان فعالیت نمود. باید توجه داشت در صورتی که سرویس در حالت standalone قرار کرفته باشد، خط listen_ipv6 می بایست برابر با no قرار گیرد.
listen_ipv6 با فعال بودن این گزینه سرویس بر روی سوکت IPv6 فعالیت خواهد کرد.
pam_service_name بیانگر نامی است که مازول امنیتی pam برای این سرور مورد استفاده قرار خواهد داد. فایل کانفیگ سرویس ها در ماژول pam در مسیر /etc/pam/vsftp قرار میگیرد.
userlist_enable با yse ‌بودن این گزینه سرویس لیست کاربران را از فایلی که معمولا در مسیر /etc/vsftp.userlist قرار دارد میخواند. در صورتی که گزینه userlist_deny برابر با yes ‌باشد هیچکدام از کاربران درون لیست مذکور اجازه اتصال به سرور را نخواهند داشت. بر عکس در صورتی که این مقدار برابر با no باشد تنها کاربران داخل لیست امکان اتصال خواهند داشت.
tcp_wrappers این گزینه برای فعال یا غیر فعال کردن tcp wrappers است. هنگامی که کلاینتی قصد اتصال و استفاده از سرویسی را داشته باشد tcp wrapper به ترتیب به فایل های /etc/hosts.allow و /etc/hosts.deny نگاه میکند تا ببیند آیا لیستی از هاست های مجاز و غیر مجاز وجود دارد یا خیر و اگر وجود دارد کلاینت در کدام یک از این فایل ها وجود دارد.
به عنوان مثال میتوان کلاینت با آدرس ۱۹۲.۱۶۸.۲۰۰.۲۰۱و لوکال هاست را به صورت زیر جهت استفاده از vsftp مجاز و بقیه را غیر مجاز معرفی کرد.
Vsftp : 192.168.200.201,LOCAL
و با اقزودن خط زیر به /etc/hosts.deny بقیه کلاینت ها را غیر مجاز معرفی کرد.
Vsftp : ALL
ALL : ALL
chown_uploads با کمک این گزینه میتوان تعیین کرد که فایل هایی که کاربران ناشناس در سرور آپلود می نمایند دارای ownership به خصوصی باشند. این گزینه در کنار گزینه chown_username کاربرد دارد.
chown_username بیان گر نام کاربری است که فایل های آپلود شده به سرور تحت مالکیت آن خواهند بود.
idle_session_timeout بیانگر مدت زمانی است که سرور در انتظار فعالیتی از کلاینت می ماند. در صورتی کانکشنی بیش از مدت زمان تعیین شده بدون فعالیت باقی بماند آن کانکشن توسط سرور بسته خواهد شد.
userlist_file معرفی کننده مسیری است که فایل userlist در آن قرار گرفته است.
userlist_deny اگر برابر با yes ‌باشد ( مقدار پیش فرض) کاربران داخل این لیست مجاز به اتصال نخواهند بود. در صورت no ‌بودن تنها کاربران userlist امکان اتصال خواهند داشت.
chroot_local_user بیانگر این است که jail ‌برای کاربران فعال است و پس از ورود در home دایرکتوری خود محبوس میشوند. اما به صورت پیش فرض و به دلایل امینتی vsftp اازه نوشتن در مسیری که jail شده است را به کاربر نمی دهد. برای این که کاربر اجازه نوشتن در دایرکتوری ای که در آن jail شده است را داشته باشد باید گزینه زیر نیز فعال شود.
allow_writeable_chroot اجازه دادن به کاربر جهت نوشتن در روی دایرکتوری ای که در آن jail شده است.

 

نکته: در خصوص گزینه message_file باید توجه داشت که این فایل باید hidden  باشد و در دایرکتوری ای که قصد نمایش آن را به کاربر داریم وجود داشته باشد. به عنوان نمونه با قرار دادن مقدار این پارامتر به صورت زیر  و قرار دادن فایل warning در home  کاربر می بایست پیغام داخل این فایل در هنگام ورود  به کاربر نمایش داده شود.

message_file=.warning

mesage

در نهایت با توجه به این که در این آموزش قصد داریم تا امکان استفاده از ftp را برای کاربران local فراهم کنیم و هر کاربر نیز در home  خود  jail شود،  فایل config نهایی به صورت زیر خواهد بود.

conf.d

پس از ذخیره کردن تنظیمات، سرویس را مجددا راه اندازی میکنیم.

با توجه به این که ما در این آموزش از chroot استفاده کرده ایم نیاز است تا selinux  نیز در این خصوص پیکربندی شود. در غیر این صورت در هنگام وررود با پیغام زیر مواجه خواهید شد.

setsebool -P ftpd_full_access on

selinux error

تست عملکرد:

پس از انجام تنظیمات، اتصال از طرق ftp به سرور را تست و بررسی میکنیم.

test-service-funcionality

همانطور که مشاهده می شود، اتصال به سرور موفق بود. حال با توجه به این که tcp_wrapper  نیز در تنظیمات vsftp فعال شده بود، تست دیگر را با معرفی هاست و سرویس در فایل های /etc/hosts.allow و /etc/hosts.deny انجام می دهیم.

ابتدای به امر در فایل /etc/hosts.allow امکان استفاده از سرویس vsftpd را تنها برای Localhost فراهم کرده و سپس در /etc/hosts.deny سایر هاست ها را از استفاده از این سرویس منع میکنیم. محتویات فایل های اشاره شده به صورت زیر خواهد بود.

tcp-wrapper

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

tcp-wrapper-test-localhost

حال از کلاینت خود و از طریق شبکه اتصال را بررسی میکنم. با توجه به توضیحات بالا و پیکربندی انجام شده کاربر امکان اتصال به سرویس را نخواهد داشت.

tcp-wrapper-test-client

توضیح نهایی این که تا این جای کار کاربران local امکان اتصال حواهند داشت، در صورتی  قصد داشته باشیم تا تعداد محدودی از کاربران مجاز به ورود و استفاده از سرویس باشند، می بایست  از userlist  استفاده کنیم و  تنها نام کاربری کاربران مجاز را در آن معرفی نماییم.

نتیجه گیری:

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

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

 

 

ادامه مطلب

systemd چیست؟

systemd چیست؟

تفاوت میان init و systemd

systemd

systemd یک System Manager  می باشد که در ابتدای بوت شدن سیستم پردازش آن شروع می شود و به عنوان parent  سایر process ها شناخته می شود و به عنوان جایگزینی برای init معرفی شده است.

init چیست؟

init  یا SysVinit در اصل یک daemon process یا پکیج مدیریت سرویس است  که به محض روشن شدن کامپیوتر تا زمان خاموش شدن آن فعالیت می کند. در واقع init اولین پردازشی است که پس از بوت شدن  سیستم شروع به فعالیت می کند و به عنوان والد (parent) تمام پردازش ها محسوب می شود و همیشه دارای PID برابر با ۱ می باشد.

systemd چیست؟

اگر به هر دلیلی daemon مربوط به init  نتواند شروع به کار کند, هیچ پردازش یا پروسس دیگری نمی تواند شروع به کار نماید. در این صورت سیستم وارد شرایطی شده است که به آن kernel panic می گویند.

با توجه به نیاز های مختلف جایگزین هایی برای هدف  ایجاد شد که برخی از آنها به daemon process  اصلی برخی از توزیع ها در آمد. مانند ‌Upstart  که در Ubuntu پیاده سازی گردید (تا نسخه ۱۶.۰۴)  یا systemd  که در برخی از توزیع ها مانند Fedora, Open SuSE, CentOS و … پیاده سازی گردیده اند.

systemd چیست؟

systemd همانند init  یک System Manager  یا پکیج مدیریت سرویس  می باشد که در ابتدای بوت شدم سیستم پردازش آن شروع می شود و به عنوان parent  سایر process  ها با PID=1  فعالیت خواهد کرد. systemd برای رفع برخی نواقص init  طراحی و پیاده سازی شده است به عنوان نمونه شروع process  ها به صورت همزمان و موازی در زمان بوت شدن سیستم که علاوه بر کاهش زمان بوت شدن سیستم عامل, استفاده از منابع پردازشی را نیز کاهش می دهد.

به عنوان نمونه init  به صورت سریالی عمل میکند. به این معنی که یک وظیفه تنها در زمانی شروع میشود که وظیفه قبلی با موفقیت انجام شده و در Memory نیز load  شده باشد که در زمان بوت شدن سیستم عامل باعث افزایش زمان بوت شدن می گردید. لازم به ذکراست که systemd  با هدف افزایش سرعت بوت شدن ایجاد نشده است اما برای این که کارها به صورت منظم انجام شود, نیاز بود تا هر گونه delay یا تاخیر غیر ضروری حذف گردد. که اجرای موازی process  ها و رعایت dependency  از مواردی بود که به کاهش این تاخیر ها کمک کردند.

نمونه ای از رعایت dependency این است که به صورت مثال سرویس هایی که در ابتدای شروع به پردازش نیاز به running بودن سرویس network دارند میتوانند پس از شروع به کار سرویس network به صورت همزمان و موازی شروع به کار نمایند. که این کار در init همانطور که گفته شد به صورت سریالی انجام می پذیرد.

 

ویژگی های systemd

برخی از ویژگی هامانند کارآمی بیشتر نسبت به init  و یا ساده تر شدن پروسه بوت و بهبود API  و… باعث شد تا systemd  محبوبیت بیشتری پیدا کند و رفته رفته جای خود را در توزیع های مختلف باز بکند. در زیر شرح کامل ویژگی های systemd  آورده شده است.

  1. طراحی بهتر و کارآمد
  2. ساده شدن پروسه بوت شدن
  3. اجرای پروسس ها به صورت همزمان و موازی در هنگام بوت
  4. بهتر شدن API
  5. امکان حذف Component های اختیاری
  6. راه اندازی سرویس ها بر اساس تنظیمات نوشته شده در فایل کانفیگ (راه اندازی سرویس ها در init  به وسیله سلسله دستوراتی از طریق شل اسکریپت انجام میگیرد.)
  7. زمان بندی کارها
  8. لاگ ها توسط  journald ذخیره سازی می شوند.
  9. امکان انتخاب systemd برای ثبت وقایع سیستمی همانند sysog
  10. ذخیره سازی لاگ ها به صورت باینری
  11. کنترل ورود و خروج کاربران به وسیله systemd-logind

نطقه ضعف systemd عدم تطابق با  POSIX است.

systemd در برخی از توزیع های لینوکس:

نام توزیع وضعیت استفاده 
Fedora از سال ۲۰۱۱ (اولین توزیعی که از systemd به صورت پیش فرض استفاده نمود)
Arch از سال ۲۰۱۲
RedHat از سال ۲۰۱۴ و نسخه ۷
CentOS از سال ۲۰۱۴ و نسخه ۷
Debian از سال ۲۰۱۵ و نسخه ۸ (Jessie)
Gentoo به صورت پیش فرض استفاده نمی شود و  نیاز به دانلود, نصب و پیکربندی دارد.
OpenSUSE از سال ۲۰۱۴ و نسخه ۱۲
Slack در حال حاضر خیر
Ubuntu از سال آپریل سال ۲۰۱۵ و نسخه ۱۵.۰۴
مقایسه systemd و init
Features init systemd
DBus Dependency – Mandatory No Yes
Device based Activation No Yes
Device dependency configuration with udev No Yes
Timer based Activation Cron/at Proprietary
Quota Management No Yes
Automatic Service Dependency Handling No Yes
Kills users Process at logout No Yes
Swap Management No Yes
SELinux integration No Yes
Support for Encrypted HDD No Yes
Static kernle module loading No Yes
GUI No Yes
List all the child processes No Yes
Sysv compatible Yes Yes
Interactive booting No Yes
Portable to non x86 Yes No
Adopted on Several Distro Several Distro
Parallel service startup No Yes
Resource limit per service No Yes
Easy extensible startup script Yes No
Separate Code and Configuration File Yes No
Automatic dependency calculation No Yes
Verbose debug Yes No
Version N/A V44+
Size 560 KB N/A
Number of Files 75 files 900 files + glib + DBus
Lines of code – LOC 15000 (Approx) 224000 (Approx) (inc Codes, comments and white space) 125000 (Approx) (acctual code)

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

journald

daemon است که وظیفه جمع آوری لاگ اتفاقات سیستمی و ذخیره سازی آنها به صورت باینری را بر عهده دارد. البته ادمین سیستم این امکان را دارد که مشخص کند لاگ ها توسط این daemon انجام شود یا توسط syslog-ng یا rsyslog

logind

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

networkd

وظیفه handle  کردن پیکربندی کارت های شبکه را بر عهده دارد.در اوایل این daemon  تنها می توانست به صورت استاتیک به کارت های شبکه IP دهد و برخی از پیکربندی های اولیه ‌Bridging  را انجام دهد که از سال ۲۰۱۴ امکان DHCP سرور برای IPv4 و پشتیبانی از VXLAN به آن اضافه شده است.

tmpfiles

ابزاری است که وظیفه ایجاد و حذف فایل ها و دایرکتوری های موقت (Temp) را بر عهده دارد و به صورت معمول در شروع به کار سیستم عامل فعال شده و در بازه های مشخص شده نیز عمل می کند.

timedated

وظیفه کنترل تنظیمات مربوط به زمان را بر عهده دارد. تنظیماتی مانند زمان سیستم, time zone و انتخاب زمان به UTC و زمان محلی (Local Time Zone) را بر عهده این daemon  است.

udevd

udev  نقش یک device manager  را برای کرنل ایفا میکند و وظیفه آن handle کردن دایرکتوری /dev و تمام فعالیت های مرتبط با user space را در هنگام حذف یا اضافه device  جدید را بر عهده دارد.

libudev

یک استاندارد library برای استفاده از udev است که به برنامه های third-party اجازه میدهد تا منابع udev را query  کنند.

Systemd-boot

boot Manager است که در systemd تعبیه شده است که سابقا با نام gummiboot شناخته می شده است.

تفاوت init و Systemd در یک نگاه

systemd چیست؟

برای آشنایی با نحوه ایجاد سرویس در systemd میتوانید با ما در این وبسایت همراه باشید.

 

ادامه مطلب

نصب و راه اندازی NFS Server در CentOS

نصب و راه اندازی NFS Server در CentOS

قدم به قدم با نصب NFS Server در CentOS

NFS چیست:

NFS مخفف کلمات Network File System  و معرفی پروتکلی برای به اشتراک گزاری دایرکتوری بین سرور های لینوکسی است. از طریق این پروتکل میتوان یک دایرکتوری را در بستر شبکه با سرور یا کلاینتی دیگر به اشتراک گذاشت به شکلی که گویی از دیسک لوکال خود در حال استفاده است. از این پروتکل تاکنون چهار نسخته ارائه شده است که آخرین آن NFSv4 می باشد. خصوصیات و معرفی ورژن های مختلف این پروتکل رو میتوانید از اینجا مطالعه کنید.

این سرویس به صورت سرور / کلانت فعالیت می کند و از طریق آن میتواند Storage مرکزی ای ایجاد کرد. همچنین میتوان آن را از طریق acl در ورژن جدید آن نیز ایمن تر کرد.

 

راه اندازی NFS server:

در این مستند راه اندازی سرویس NFS روی centos 7  و با هدف اشتراک گزاری یک دایرکتوری بین دو سرور با قابلیت read/write  همزمان بر روی آنها توضیح داده خواهد شد

در این آموزش از دو سیستم در محیطی تستی و با مشخصات زیر استفاده شده است.

Server1:

CentOS Linux release 7.4.1708 (Core)

IP: 192.168.200.200

Server2:

CentOS Linux release 7.4.1708 (Core)

IP: 192.168.200.201

ماشین Server1 در این مستند به عنوان NFS Server  و server  دوم به عنوان NFS Client  فعالیت خواهند کرد.

برای نصب NFS در هر دو ماشین از دستور زیر استفاده میکنیم تا پکیج مربوطه به همراه Dependency  های آن نصب گردد.

Server1~]#  yum –y install nfs-utils

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

Server1~]#  mkdir -p /share/nfs

Server1~]#  chmod –R 755 /share/nfs

Server1~]#  chown nfsnobody:nfsnobody /share/nfs

file creation and permissions

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

Server1~]#  systemctl enable rpcbind

Server1~]#  systemctl enable nfs-server

Server1~]# systemctl enable nfs-lock

Server1~]# systemctl enable nfs-idmap

یا به صورت کلی در یک دستور به صورت زیر

Server1~]# systemctl enable rpcbind nfs-server nfs-lock nfs-idmap

حال سرویس های مربوطه را به صورت زیر start  میکنیم.

Server1~]#  systemctl enable rpcbind

Server1~]#  systemctl enable nfs-server

Server1~]# systemctl enable nfs-lock

Server1~]# systemctl enable nfs-idmap

یا مانند بالا به صورت کلی و با یک دستور:

Server1~]# systemctl start  rpcbind  nfs-server nfs-lock nfs-idmap

معرفی سرویس ها:

 

  • rpcbind:وظیفه mapping سرویس  را به پورت آن بر عهده دارد. سرویس RPC به هر برنامه یک آیدی اختصاص میدهد  که به آن program ID گفته می شود این اطلاعات در فایل /etc/rpc نگه داری میشود. این سرویس مشخص می کند که هر program id از چه پورتی برای برقراری ارتباط میتواند استفاده کند. هنگامی که کلاینتی درخواستی مبنی بر اتصال ایجاد می نماید، این سرویس پورت مربوطه را مشخص کرده، سپس کاربر را به سمت آن هدایت میکند در نتیجه امکان ارتباط و communicate بین سرویس و کلاینت مستلزم فعال بودن این سرویس می باشد که می بایست قبل از باقی سرویس ها شروع به کار نماید.

همانطور که در شکل زیر مشاهده می کنیم، به سرویس NFS آیدی ای برابر با 100003 اختصاص داده شده است.

rpcbind

حال با دستور rpcinfo –p میتوانیم ببینیم که این program id به چه پورتی map شده است.

rpcinfo

همانطور که در شکل بالا مشخص است، nfs در ورژه های 3 و 4  بر روی پورت 2049 udp و tcp فعالیت میکند.

  • nfs-idmap: وظیفه mapping بین username و Group  به  UID و GID را بر عهده دارد.
  • nfs-lock: عملیات locking بر روی فایل های NFS را بر عهده دارد. در صورتی که کلانتی درخواست locking  برای فایلی را به سرور ارسال نماید، این سرویس وظیفه مدیریت این در خواست را بر عهده دارد. به عنوان مثال در صورت درخواست کلاینت به صورت پیشفرض به مدت 15 ثانیه بر روی فایل عملیات locking  را انجام میدهد.

بعد از شروع به کار سرویس ها،  دایکتوری ای را که ایجاد کرده ایم را به صورت زیر در فایل /etc/export معرفی میکنیم.

/share/nfs      192.168.200.201(rw,sync,no_root_squash,no_all_squash)

exports

پارامتر های پیکربندی:

برخی از پارامتر های مورد استفاده در فایل /etc/export به شرح زیر است:

  • rw: مجوز هر دو عملیات خواندن و نوشتن بر روی فایل سیستم را فراهم میکند.به صورت پیشفرض هر عملیاتی که منجر به تغییر بر روی فایل سیستم شود، نادیده گرفته میشود، همانند رفتاری که در تنظیم ro در پیش گرفته میشود.
  • async: این گزینه این امکان را فراهم میکند تا به درخواست های تغییر بر روی دیسک قبل از این که واقعا تغییری اعمال شود، پاسخ داده شود. در واقع به کلاینت گفته می شود تغییرات مورد نظر بر روی دیسک اعمال شده است ولی در عمل اینطور نیست. این گزینه میتواند کارایی سیستم را بهبود ببخشد اما در کنار این بهبود ریسک از دست رفتن اطلاعات در صورت ری استارت شدن ناگهانی سرور یا به اصطلاح unclean restart ( مانند شرایط کرش کردن کرنل و قطع برق سرور و …) نیز وجود دارد.
  • sync: درخواست تغییر روی دیسک تنها و تنها زمانی به کلاینت ارسال می شود که تغییرات بر روی دیسک اعمال یا commit  شده باشد. از ورژن ۱ به بعد این گزینه به عنوان تنظیمات پیش فرض مورد استفاده قرار میگیرد.
  • wdelay:  در صورتی که سرور تشخیص دهد ممکن است عملیات نوشتن دیگری مرتبط با عملیات فعلی بر روی دیسک انجام شود، عملیات نوشتن بر روی دیسک را با تاخیر انجام خواهد داد. این کار باعث میشود تا در یک عملیات نوشتن چندین درخواست را در دیسک نوشت. در نتیجه تعداد دفعات رجوع به دیسک جهت نوشتن داده بر روی آن کمتر میشود که در نتیجه آن کارایی سرور نیز بهبود می یابد. اما در مواقعی که درخواست های زیاد و نامرتبطی به سرور ارسال شود فعال بودن این گزینه عملا میتواند باعث کاهش کارایی و عملکرد سرور شود. این گزینه از تنظیمات پیش فرض است که جهت غیر فعال سازی آن میتوان از no_wdelay استفاده کرد.
  • root_squashدر صورتی که کاربر root قصد دسترسی به فایلی را در nfs ‌ سرور داشته باشد. رفتار سرور با این کاربر هماهنند کاربر root در سرور اصلی خواهد بود. با فعال بودن این گزینه. uid کاربر root در سرور به  uid دیگری که متعلق به کاربر nobody است map میشود. در نتیجه سطح دسترسی کاربر در سرور به حداقل دسترسی ممکن کاهش می باید. برای غیر فعال سازی این گزینه از گزینه no_root_squash استفاده میشود.
  • all_squash : عملکردی همانند عملکرد  root_squash‌دارد با این تفاوت که این عملکرد برروی تمامی کاربرای تاثیر گزار خواهد بود. غیر فعال سازی عملکرد این گزینه با no_all_squash امکان پذیر است. فعال کردن این گزینه برای فایل سیستم هایی که در دسترس عموم قرار میگیرند مناسب است.
  • anonuid and anongid: با استفاده از این دو گزینه میتوان درخواست های یک فایل سیستم یا دایرکتوری را که از سمت کاربر anonymous  وارد می شود را به یک uid و  gid به خصوص map کرد. به عنوان مثال تصور کنید نام کاریری ای به نام javad با uid ‌ برابر با ۵۰۵  داریم. با انتخاب گزینه anouid=505 تمامی درخواست ها بر روی فایل ها با uid  کاربر javad ثبت و انجام می شوند.

لازم به ذکر است در صورتی که بخواهیم اشتراک گزاری را به آدرس خاصی محدود نکنیم میتوانیم جای آدرس IP از “*” استفاده کنیم.

در نهایت تنظیمات مربوط به فایروال را برای باز کردن NFS و سرویس ها مورد استفاده آن را به صورت زیر انجام میدهیم.

firewall-cmd --permanent --zone=public --add-service=nfs

firewall-cmd --permanent --zone=public --add-service=mountd

firewall-cmd --permanent --zone=public --add-service=rpc-bind

firewall-cmd –reload

تنظیمات سمت کلایت ( Server2)

پس از نصب پکیج nfs-utils  بر روی سرور دوم، می بایست دایرکتوری را که قصد داریم جهت sharing  از آن استفاده کنیم را ایجاد کرده، سپس مسیر share  شده در سرور اول را با تایپ NFS   به آن  mount کنیم.

Server2~]#  mkdir /share

mount -t nfs 192.168.200.200:share/nfs /share

برای این که عملیات mount  کردن به صورت اتوماتیک در هر بار بوت شدن سیستم عامل انجام شود، خط زیر را در فایل /etc/fstab اضافه میکنیم.

192.168.200.200:share/nfs           /share   nfs defaults 0 0

fstab

و با دستور mount –a  سیستم را force میکنیم تا بر اساس فایل fstab  عملیات mount  کردن را مجددا انجام دهد.

حال با دستور df  یا mount  میتوان مطمئن شد که عملیات طبق انتظار انجام شده باشد.

df output

mount output

در نهایت با mount شدن دایرکتوری nfs به دایرکتوری  share در سرور دوم،  جهت تست نیز فایلی در مسیر /share  ایجاد مینماییم.

create shared directory

همانطور که مشاهده میشود، به علت استفاده از no_root_squash فایل ایجاد شده با ownership کاربر root ایجاد شده است.

تست عملکرد:

حال جهت تستی دیگر این گزینه را به root_squash تغییر می دهیم و مجددا فایلی را ایجاد می نمائیم.

create shared directory root squash

طبق توضیحات بالا همانطور که انتظار میرفت فایل جدید با ownership  کاربر nobody  ایجاد گردید.

به عنوان آخرین تست نیز میخواهیم تمامی فایل های ایجاد شده در مسیر /share با ownership کاربر hamed و گروه  nfsnobody ایجاد گردند. برای این کار فایل exports را به شکل زیر تغییر میدهیم.

nfs usr_id

در server1 کاربر hamed دارای uid  برابر با 1002  می باشد.

anouid

از آنجا که کاربری به نام hamed در سرور دوم وجود ندارد، در نتیجه امکان map کردن این uid  به نام کاربری برای سرور دوم مقدور نمی باشد و صرفا uid را نمایش میدهد. در صورتی که در server1  این نام کاربری وجود دارد لذا وضعیت فایل در سرور اول به صورت زیر می باشد.

ls output

نتیجه گیری:

در این مستند نحوه پیکربندی و پیاده سازی سرویس NFS مورد بررسی قرار گرفت. این سرویس از آن نظر که محدودیتی در توزیع سیستم عامل های لینوکسی در آن وجود ندارد میتواند  در شبکه به عنوان Central Storage  مورد استفاده و بهره برداری قرار گیرد.

ادامه مطلب

آموزش استفاده از CD/DVD به عنوان Repository در لینوکس

آموزش استفاده از CD/DVD به عنوان Repository

استفاده از DVD  به عنوان Local Repository

 

نصب package  ها بر روی سرور هایی که فاقد اینترنت هستند و به Repository  های پیش فرض متصل نمی شوند و یا پکیج های خاص و یا حجم بالا یکی از معضلات  کاربران لینوکسی است. در این آموزش قصد داریم به صورت مرحله به مرحله نحوه استفاده از DVD به عنوان Local Repository  را بررسی کنیم.

 

  • ابتدا ISO مورد نظر (Installation ISO) را به یک دایرکتوری Mount  میکنیم.
# mount -o loop /home/hamed/RHEL7.1.iso /mnt

 

در صورتی که از DVD استفاده میکنیم باید به شکل زیر مسیر DVD Rom  را وارد نمائیم.

# mount -o loop /dev/sr0&nbsp; /mnt

 

در مسیر  /etc/repos.d  ایجاد میکنیم که باید با .repo  خاتمه یابد به عنوان مثال localrepo.repo و مقادیر زیر را در آن وارد خواهیم کرد.

Cat /etc/repos.d/localrepo.repo

 

[LocalRepo]

name=Local Repository
baseurl=file:///mnt
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

 

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

# yum clean all

در نهایت با دستور yum install Package-name پکیج مورد نظر را نصب میکنیم. در اینجا به عنوان نمونه پکیج vsftpd  را نصب خواهیم کرد.

# yum install vsftpd

 

Loaded plugins: fastestmirror

LocalRepo                                                | 3.6 kB     00:00
(1/2): LocalRepo/group_gz                                  | 157 kB   00:00
(2/2): LocalRepo/primary_db                                | 2.7 MB   00:00
Determining fastest mirrors
Resolving Dependencies
--> Running transaction check
---> Package vsftpd.x86_64 0:3.0.2-9.el7 will be installed
--> Finished Dependency Resolution
 
Dependencies Resolved
 
================================================================================
Package         Arch            Version               Repository          Size
================================================================================
Installing:
vsftpd          x86_64          3.0.2-9.el7           LocalRepo          165 k
 
Transaction Summary
================================================================================
Install  1 Package
 
Total download size: 165 k
Installed size: 343 k
Is this ok [y/d/N]: y
Downloading packages:
warning: /cdrom/Packages/vsftpd-3.0.2-9.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
Public key for vsftpd-3.0.2-9.el7.x86_64.rpm is not installed
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Importing GPG key 0xF4A80EB5:
Userid     : "CentOS-7 Key (CentOS 7 Official Signing Key) <security@centos.org>"
Fingerprint: 6341 ab27 53d7 8a78 a7c2 7bb1 24c6 a8a7 f4a8 0eb5
Package    : centos-release-7-0.1406.el7.centos.2.3.x86_64 (@anaconda)
From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Is this ok [y/N]: y
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : vsftpd-3.0.2-9.el7.x86_64                                    1/1
Verifying  : vsftpd-3.0.2-9.el7.x86_64                                    1/1
 
Installed:
vsftpd.x86_64 0:3.0.2-9.el7
 
Complete!

 

به یاد داشته باشید این روش فقط محدود به ماشینی خواهد بود که DVD  بر روی آن Mount  شده است.

ادامه مطلب

رفع مشکل Error در License RDP

رفع مشکل Error در License RDP

Remote Desktop License Error

در صورت مواجه با پیغام خطای “The remote session was disconnected because there are no Remote Desktop License Server available to provide a license Please Contact the server administrator” جهت رفع مشکل مراحل زیر را دنبال کنید.

یک روش ورود به سرور با استفاده از Admin Mode  می باشد یعنی
mstsc /admin

اما برای رفع کامل مشکل :

  • با دستور regedit وارد محیط  Registry Editor  شوید و وارد مسیر زیر شوید.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod

Registry remove key

  • در قسمت Permissions مالکیت دایرکتوری GracePeriod  را به کاربر admin تغییر می دهید.

Take Ownership

Take Ownership

  • به کاربر admin دسترسی کامل می دهیم تا امکان پاک کردن کلید L$RTMTIMEBOMB برایتان فراهم شود.

Full Control To admin

  • در نهایت کلید L$RTMTIMEBOMB را پاک کرده و سیستم را مجددا راه اندازی می کنید.

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

ادامه مطلب

معرفی فایروال های لینوکسی firewalld و iptables

معرفی فایروال های لینوکسی firewalld و iptables

معرفی iptables و firewalld:

سرویس های firewalld  و  iptables  هر دو فایروال های پیش فرض سیستم عامل ها و توزیع های مبتنی بر RedHat  میباشند و هر دو از بستر netfilter  استفاده میکنند. iptables نسخه ای سنتی و قدیمی تر از firewalld می باشد که در نسخه RHEL7 یا firewalld  جایگزین گردید. اما هر دو همچنان گستردگی استفاده خود را در دنیای لینوکس حفظ کرده اند.

هر دو ابزار با پشتیبانی IPv4 و IPv6  و پروتکل های TCP و UDP این امکان را فراهم میکنند تا امنیت سرور ها را در شبکه تا حد ممکن افزایش داده و از دسترسی های ناخواسته به سرور از طریق شبکه جلوگیری نمود.

نکته: در RHEL8 که اخیرا عرضه شده است، firewalld از بستر nftables به جای netfilter  استفاده میکند.

در ادامه مستند به نصب هر دو سرویس ، معرفی و پیکربندی هرکدام خواهیم پرداخت.

iptables:

همانطور که پیش تر اشاره شد، iptables بر اساس netfilter  پیاده سازی شده است و تا قبل از  RHEL7 به عنوان فایروال پیش فرض استفاده می شده است. ساختار iptables  بر اساس سه قسمت زیر است:

  • Tables
  • Chains
  • Rules

Tables:

جداول iptables برای برای دسته بندی گروهی از chain ها که هر کدامل شامل یک یا چند rule  میباشند مورد استفاده قرار میگیرند.جداول پیش فرض شامل 5 جدول به شرح زیر هستند:

  • filter: جدول پیشرفض مورد استفاده iptables است که برای فیلتر کردن پکت های ورودی و خروجی مورد استفاده قرار میگیرد.
  • nat: جدولی است که به منظور اعمال تنظیمات NAT مورد استفاده قرار میگیرد.
  • raw: در حالت عادی کرنل پکت ها را بر اساس State آنها ( یا جزئی از یک کانشن جدید هستند یا جزئی از یک کانکشن جاری و باز) بررسی میکند. این جدول این امکان را فراهم میکند تا با پکت ها قبل از این که کرنل بر اساس state  آنها اقدامی انجام دهد کارکرد.
  • mangle: از طریق این جدول میتوان تغییراتی را در header پکت ها ایجاد نمود. به عنوان مثال تغییر مقدار TTL در پکت های دریافتی. این عمل تحت عنوان packet mark نیز شناخته می شود.
  • security: برای مدیریت دسترسی از طریق متد MAC یا mandatory access control  می باشد.

Chains:

هر جدول شامل تعدادی chain هستند که هر کدام گروهی از rule  ها را در خود نگه میدارند. که میتوانند سیستمی باشند یا توسط کاربر ساخته شود.

سه chain  اصلی عبارتند از :

  • INPUT: برای مدیریت rule های مربوط به پکت های ورودی به سیستم به کار میرود.
  • OUTPUT: برای مدیریت rule های مربوط به پکت های خروجی از سیستم به کار میرود.
  • FORWARD: برای مدیریت پکت هایی که از طریق route در سیستم forward می شوند به کار میرود.

Rules:

مجموعه ای از قوانین هستند که درون chain  ها نگه داری می شوند و شامل matches و targets است. بدین معنی که بخشی از rule  ها بیانگر شروطی  و بخشی دیگر بیانگر عملی است که در صورت صادق شدن آن شروط باید انجام شود.

هنگامی که پکتی بررسی می شود، از ابتدای این لیست به ترتیب rule  ها بررسی می شوند تاmatch  اتفاق افتد. در صورتی که پکتی با قوانین موجود در لیست همخوانی داشته باشد، بر اساس قواعد target با آن برخورد می شود.

به عنوان مثال:

اگر پکتی از آدرس 192.168.200.150 و از طریق پورت 5050 پروتکل TCP وارد شد آنگاه آن را drop  کن.

در مثال بالا بخش اگر همان match و بخش آنگاه همان target  خواهد بود.

Matches:

شرایطی است که برای پکت ها در نظر گرفته می شود. در صورتی که این شرایط برای پکت همخوانی داشته باشد، iptables پکت را بررسی و قواعد target را بر آن اعمال میکند.

برخی از match ها به شرح زیر می باشند.

  • Source (-s): بیان گر مبدا پکت است که میتواند IP، رنج IP یا hostname باشد.
  • destination (-d): بیانگر مقصد پکت است می تواند ، رنج IP یا hostname باشد.
  • protocol (-p): بیانگر پروتکل پکت ورودی می باشد. مانند TCP یا UDP در صورتی که پروتکلی مشخص نشود، به صورت پیش فرض کلیه پروتکل های یا all در نظر گرفته می شود.
  • –in-interface (-i): بیانگر اینترفیسی است که پکت از آن دریافت می شود.
  • –out-interface (-o): بیانگر اینترفیسی است که پکت از آن خارج می شود.

Targets:

بیانگر اقدامی است که برای پکت در نظر گرفته می شود. target  با –j یا  –jump در انتهای دستور مشخص می شود. و چهار نوع دارد:

  • :Accept اجازه دسترسی یا عبور پکت را میدهد.
  • Drop: اجازه دسترسی به پکت یا عبور آن را نمیدهد و جوابی نیز به درخواست کننده نمی دهد.
  • Queue: پکت های دریافتی را صف بندی میکند.
  • Return: اگر rule دارای target برابر با return باشد، بررسی rule  های آن chain برای پکت متوقف می شود و پکت بر اساس رول های chain بالا دستی بررسی می شود ولی در صورتی که این rule در یکی از chain های اصلی وجود داشته باشد، پالیسی پیشرفض برای آن اعمال خواهد شد.

در صورتی که قصد اضافه کردن rule به chain  خاصی را داشته باشیم، از option با مقدار A- یا  append– و در صورتی که قصد حذف آن را داشته باشیم از option با مقدار D- یا delete– استفاده میکنیم.

دستورات iptables:

حال بعد از آشنایی با iptables، به بررسی چند دستور جهت آشنایی بیشتر با نحوه حذف و اضافه نمودن rule ها می پردازیم.

جهت بررسی و مشاهده لیست rule  های موجود از دستور زیر استفاده می کنیم.

iptables -L

list rules

در صورتی که صرفا لیست rule  های یک chain  به خصوص مد نظر باشد نیز در انتهای دستور اسم chain را به صورت زیر وارد میکنیم.

iptables –L INPUT

list a chain

ایجاد Default policy:

در صورتی که پکتی با rule  های هیچ یک از chain  ها همخوانی نداشته باشد، نیاز است تا اقدامی به صورت پیش فرض برای آن در نظر گرفته شود. به عنوان نمونه اگر پکتی با هیچ rule خاصی همخوانی نداشت، آن را drop کنیم.دستور زیر سیاست پیش فرض را  قبول یا accept قرار خواهد داد.

iptables -t filter -P INPUT ACCEPT

و دستور زیر سیاست پیش فرض را بر رد درخواست با drop  قرار خواهد داد.

iptables -t filter -P INPUT DROP

ایجاد و حذف و جایگزین کردن  فیلتر:

در مثال های زیر با اضافه نمودن چند فیلتر به ساختار دستوری iptables  در حذف و اضافه کردن rule  ها خواهیم پرداخت.

 

  • مثال1: تمامی ترافیک های ورودی از یک ادرس را به سرور مسدود نمائیم. از آنجا که پروتکلی در دستور زیر مشخص نشده است، کل ترافیک ورودی از 192.168.200.200 به مقصد 192.168.200.201 مسدود خواهد شد.

 

 

iptables -A INPUT -s 192.168.200.200 -d 192.168.200.201 -j DROP
  • مثال2:  ترافیک SSH با دستور زیر فیلتر خواهد شد
iptables -A INPUT -s 192.168.200.200 -d 192.168.200.201 -p tcp --dport 22 -j DROP
  • مثال3: ترافیک ورودی و خروجی TCP بر روی پورت 22 برای اینترفیس en33  مورد قبول واقع می شود
iptables -A INPUT -p tcp -i ens33 --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp -o ens33 --sport 22 -j ACCEPT
  • مثال4: همانند مثال بالا با این تفاوت که چند پورت به صورت رنج معرفی گردیده است.
iptables -A INPUT -p tcp -i ens33 --dport 22:26  -j ACCEPT

در تمامی مثال های بالا rule هایی به chain های جدول filter  اضافه گردید. حال اگر قصد حذف rule وارد شده را داشته باشیم از همان دستور اما با option  برابر با D- استفاده می نمائیم.

iptables -D INPUT -s 192.168.200.200 -d 192.168.200.201 -j DROP

در صورتی که قصد داشته باشیم تمامی rule  های یک chain را حذف نمائیم از دستور زیر استفاه میکنیم.  در مثال زیر forward chain ازجدول filter تخلیه خواهد شد.

iptables  -F FORWARD

در صورتی که قصد داشته باشیم تمامی rule  های یک table  را پاک نمائیم از دستور زیر استفاده خواهد شد.

iptables  -t filter -F

نکته:

باید توجه داشت که ترتیب rule  های هر chain  مهم است. به عنوان نمونه در صورتی که خط اول INPUT برای پذیرش تمامی ترافیک ها و خط آخر برای عدم قبول ترافیک ICMP تنظیم شده باشد، ترافیک ورودی فقط با rule  اول match خواهد شد. لذا این ترتیب بندی ها میبایست در نظر گرفته شود.

برای مشاهده شماره و ترتیب rule  ها میتوان از دستور زیر استفاده کرد.

iptables -L --line-numbers

rules line numbers

تا به اینجای کارrule اضافه شده در انتهای chain اضافه یا append  می شدند. در صورتی که قصد داشته باشیم rule در جای خاصی از جدول اضافه شود به جای –A از –I یا –insert استفاده مینمائیم. مانند دستور زیر

iptables -I INPUT 2 -s 192.168..199 -d 192.168.200.201 -p tcp --dport 22 -j DROP

insert rule

تفاوت این دستور با دستورات بالا در این است که علاوه بر استفاده از option   -I مبنی بر insert در جدول، بعد از اسم chain نیز با مشخص کردن شماره خط،  همانند شکل بالاrule  اضافه شده را در خط دوم  اضافه نمودیم.

حال که شماره rule ها در chain را در اختیار داریم، میتوانیم همانند دستور زیر، rule  های مورد نظر را به id یا شماره آنها حذف نمود.

iptables -D INPUT 2

delete by id

در نهایت اگر قصد داشته باشیم rule خاصی را replace  نماییم میتوانیم از option –R یا –replace استفاده وکنیم.

با دستور زیر rule  دوم از تصویر بالا را با rule  مورد نظر جایگزین می نمائیم.

iptables -R INPUT 2 -s 192.168.200.199 -d 192.168.200.201 -p tcp --dport 22 -j DROP

firewalld:

سرویس firewalld همانطور که پیشتر اشاره شد از نسخه RHEL7 جایگزین iptables   شد اما تا قبل از نسخه 8 از یک بستر استفاده میکردند. در firewalld از ابزاری به نام firewall-cmd برای ایجاد، جایگزینی و حذف rule  ها استفاده می شود. قبل از معرفی این ابزار برخی از مفاهیم firewalld را مورد بررسی قرار میدهیم.

Zones:

firewalld rule  ها را در مجموعه هایی به نام zone  مدیریت میکند. در واقع Zone  ها لیستی از rule  ها هستند که رفتار firewalld با ترافیک دریافتی اینترفیس ها از طریق آنها مشخص می شود.

Zone  های پیش فرض در firewalld به شرح زیر می باشند:

  • drop: کمترین میزان اعتماد در این zone وجود دارد. در این zone تمامی ترافیک های دریافتی بدون ارسال هیچ پاسخی drop خواهند شد و فقط ترافیک های خروجی مجاز خواهند بود.
  • block: همانند drop می باشد اما با خشونتی کمتر از آن. در این zone نیز تمامی ترافیک های ورودی drop می شوند اما در پاسخ به درخواست های ورودی، پیغامی مانند icmp-host-prohibited و یا icmp6-adm-prohibited  نیز ارسال می شود.
  • public: به نوعی بیانگر شبکه های عمومی و سطح امنیت و اعتماد کم در آن هاست. ترافیک های ورودی در این zone تماما بسه نمی شوند می میتوان بر اساس نیاز به آنها اجازه دسترسی داد.
  • external: در صورتی که قصد NAT کردن Private IP خود را داشته باشیم از این zone استفاده می نمائیم.
  • internal:  ترافیک های دریافتی در این zone قابل اعتماد تر هستند و برخی سرویس ها در این zone نیز ممکن است در دسترس باشند.
  • dmz: برای ایزوله کردن ترافیک از سایر آدرس هاش شبکه مورد استفاده قرار میگیرد و فقط ترافیک های خاصی امکان اتصال خواهند اشت.
  • work: بیشتر ترافیک های ورودی در این zone قابل اعتماد هستند و تعدادی کمی از سرویس ها نیز در آن فعال و در دسترس هستند.
  • home: برای محیط خانگی کاربرد دارد و تضور بر این است که تمام سیستم های شبکه اعتماد وجود دارد. سطح دسترسی از طریق سرویس های مختلف کمی بیشتر از home می باشد.
  • trusted: به تمام ماشین های داخل شبکه اعتماد کامل وجود دارد و کمترین محدودیت در ترافیک ها را اعمال میکند.

دریافت اطلاعات Zone ها:

هر کارت شبکه به یک zone متصل خواهد شد و قوانین آن zone بر ترافیک های ورودی و خروجی آن اینترفیس حاکم خواهد بود. این امکان وجود دارد که در صورت نیاز zone  مورد نظر خود را ایجاد و خصوصیات آن را ویرایش کرده و سپس اینترفیسی را به آن متصل نمائیم.

Rule ها در firewalld یا به صورت آنی (immediate) و یا به صورت دائمی (permanent ) خواهند بود. در صورتی که تغییری در rule خاصی ایجاد شود یا rule جدیدی اضافه شود مادامی که به صورت دائمی ثبت نشوند موقت خواهند بود ودر بوت بعدی وجود نخواهند داشت.

اضافه کردن دائمی rule  و یا ایجاد تغییرات در آن ها با option –permanent صورت میپذیرد.

برای مشاهده لیست zone  ها و zone  پیش فرض از دو دستور زیر استفاده مینمائیم.

firewall-cmd get-zones
firewall-cmd --get-default-zone

zone list

در صورتی که قصد داشت هباشیم rule های هر zone  را مشاهده کنیم، میتوانیم از دستور زیر استفاده کنیم.

firewall-cmd --list-all  --zone=block

دستور بالا rule  های block zone  را به صورت زیر نمایش می دهد. در صورتی که اسم zone  مشخص نشود، rule های zone  پیشفرض نمایش داده می شود.

list rules insde a zone

در صورتی که قصد داشته باشیم اینترفیسی را به zone خاصی متصل کنیم، از دستور زیر استفاد می نماییم.

firewall-cmd  --zone=trusted --change-interface=ens33

assigne rule to interface

همانطور که در تصویر قابل مشاهده است، اینترفیس ens33 به trusted zone متصل گردید.

نکته مهم:

در هنگام انتقال اینترفیس ها باید مد نظر داشت که این تغییرات بر روی سرویس درحال کار تاثیر گزار خواهد بود. بدین صورت که اگر اینترفیسی از zone فعلی که دارای ارتباط ssh فعال است به zone دیگری که در آن ssh مسدود است منتقل شود ممکن است ارتباط قطع گردد. لذا در صورتی این تغییرات انجام شود که یا از عملیات مطمئن بوده یا دسترسی به سرور در صورت بروز مشکل فراهم باشد.

در صورتی که مدیریت تمامی اینترفیس ها از طریق یک zone فراهم باشد، میتوان zone پیش فرض را به zone مورد نظر و با دستور زیر تغییر داد.

firewall-cmd --set-default-zone=home

اضافه کردن rule برای سرویس ها:

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

اطلاعات مرتبط با سرویس ها با نام همان سرویس در مسیر /usr/lib/firewalld/services و در فرمت xml قابل مشاهده هستند. برای دریافت لیستی از سرویس ها میتوان از دستور زیر استفاده کرد.

firewall-cmd --get-services

get-services

به عنوان نمونه درصورتی که بخواهیم سرویس ssh  را به public zone اضافه نمیایم به صورت زیر عمل خواهیم کرد.

firewall-cmd --zone=public --add-service=ssh

و برای حذف سرویس نیز از remove-service– به صورت زیر استفاده خواهیم کرد.

firewall-cmd --zone=public  --remove-service=ssh

در صورتی که بخواهیم تغییرات به صورت دائمی ثبت شوند نیز میتوان مانند دستور زیر از –permanent  استفاه نمائیم.

firewall-cmd --zone=work --add-service=ssh  --permanent

در صورتی که سرویس مورد نظر در لیست سرویس های firewalld قرار نداشت میتوانیم با استفاده از فرمت xml یکی از سرویس ها سرویس مورد نظر خود را ایجاد نمائیم یا این که پورت مورد استفاده در سرویس مورد نظر را در firewalld و با دستور زیر اضافه نماییم.

با دستور زیر پورت 3550 بر روی پروتکل tcp به public zone  اضافه میگردد.

firewall-cmd --zone=public --add-port=3550/tcp

add port

همچنین در صورتی که بخواهیم رنجی از پورت ها را در این zone  اضافه کنیم نیز میتوانیم به صورت زیر این کار را انجام دهیم.

firewall-cmd --zone=public --add-port=3720-3725/tcp

در firewalld ویژگی دیگری به نام rich rule  وجود دارد که از طریق آن میتوان با جزئیات بیشتر اقدام به محدود کردن ترافیک ها نمود. به عنوان نمونه، هدایت کردن ترافیک یک پورت بر روی پورتی دیگر، ایجاد Whitelist، محدود کردن تعداد درخواست های ورودی و…

نمونه ای از rich rule به صورت زیر می باشد که در آن rule مورد نظر بر روی IPv4 و از مبدا 192.168.200.199 و برای سرویس http  فعال خواهد شد و تعداد درخواست ها در ساعت را برابر با 100  درخواست در ساعت قرار داده و در صورتی که شرایط مطرح شده در rule برقرار شود، آن را در فایل messages ثبت می نماید. در آموزشی مجزا به تشریح rich rule ها خواهم پرداخت.

firewall-cmd --permanent --zone=public --add-rich-rule='rule family=ipv4 source address=192.168.200.199/32 service name=http log level=notice prefix="firewalld rich rule INFO: " limit value="100/h" accept'

نتیجه گیری:

در این مستند، به بررسی مفاهیم و ساختار دو فایروال مطرح و محبوب لینوکسی firewalld و iptables  پرداخته شد و سعی شد پس ایجاد آشنایی با دستورات هر دو سرویس، نحوه ایجاد، حذف و اضافه کردن rule ها و ایجاد یا رفع محدودیت در ترافیک های ورودی و خروجی را به صورت ابتدایی مورد بررسی قرار دهیم. حفظ امنیت سرور و جلوگیری از دسترسی ها و ایجاد ترافیک های ناخواسته در محیط های عملیاتی بسیار مهم و حیاتی می باشند در نتیجه آشنایی با این سرویس ها برای ایجاد امنیت هر چه بیشتربرای system administrator ها امری ضروری خواهد بود.

ادامه مطلب

سرویس syslog در لینوکس

سرویس syslog در لینوکس

معرفی سرویس rsyslog

معرفی Syslog:

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

با اطلاعات کسب شده از این طریقمی توان  بررسی روند عملکرد یک نرم افزار ، عیب یابی سیستم (troubleshot)، ثبت وقایع امنیتی، مدیریت سیستم و تحلیل و آنالیز آن ها پرداخت.

Syslog دارای پیام هایی به شرح زیر می باشد.

  • Facility
  • Severity
  • message

Facility:

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

لیستی از facility ها به شرح زیر می باشد:

 

Facility Keyword Description
0 kern Kernel messages
1 user User level message
2 mail System daemon
3 daemon System daemons
4 auth Security messages
5 syslog Syslog Internal message
6 lpr Line printer subsystem
7 news Network news subsystem
8 uucp UUCP subsystem
9 cron Clock daemon
10 authpriv Security/auth message
11 ftp For ftp daemon
12 ntp For ntp subsystem
13 security Log audit
14 consol Log alert
15 Solaris-cron Scheduling daemon
16-23 Local0 – local7 For Local use

Severity:

هر پیام ثبت شده در syslog  باید دارای یک severity level یا اولویت (priority) باشد تا درجه اهمیت پیام را مشخص نماید، serenity های موجود به شرح جدول زیر می باشند:

Severity code Description
0 Emerg یا Emergency( سیستم غیر قابل استفاده می باشد)
1 Alert: (شرایطی به وجود آمده است و نیاز با اقدامی سریع می باشد.)
2 Crit یا Critical:(شرایط بحرانی )
3 Err یا Error: (خطایی به وجود آمده است)
4 Warning:(هشداری ایجاد شده است)
5 Notice: (شرایط طبیعی است اما شرط یا شرایطی مصداق پیدا کرده اند)
6 Info یا Information: (پیام هایی صرفا با جنبه اطلاعات)
7 Debug: (پیام هایی با جنبه عیب یابی سیستم)

 

در syslog  هر چقدر که مثدار عددی severity بالاتر رود، درجه اهمیت و اولویت آن نیز بالاتر میرود.

Message:

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

خط زیر یک نمونه از پیام های ایجاد شده توسط kernel  می باشد.

Jan  5 08:55:20 server1 kernel: e1000: ens37 NIC Link is Down

Syslog میتواند به صورت لوکال یا به صورت متمرکز و مرکزی عمل کند. در حالتت لوکال، برنامه ها پیام های خود را به سرویس لوکال syslog  ارسال میکنند و این سرویس بر اساس تنظیماتی که برای آن در فایل /etc/syslog.conf  انجام شده است با پیام ها بر خورد میکند.

در روش متمرکز، سروری به عنوان سرور مرکزی لاگ وظیفه دریاف لاگ از سایر سرور ها و ذخیره سازی آنها را بر اساس تنظیمات انجام شده در /etc/syslog.conf  ذخیره می نماید. در سایر سرور ها که می بایست اگ خود را به سرور مرکزی ارسال نمایند، هر برنامه پیام خود را به syslog  لوکال خود ارسال میکند و پیام درفایت شده بر اساس تنظیمات انجام شده برای سرویس لوکال، به سمت سرور مرکزی هدایت خواهد شد.

تنظیمات syslog:

در فایل پیکربندی syslog  در هر دو مدل پیاده سازی، هر خط بیانگر یک یا چند selector وaction  می باشد. قسمت selector  بیانگر facility وpriority می باشد.

به عنوان مثال در خط زیر mail.info به عنوان selector و /var/log/mail.log بیانگر Action  مربوطه می باشد و بدین معنی میباشد که لاگ های دیافت شده از سرویس mail ( یا همان facility2)  و با severity برابر با 6 را در فایل /var/log/mail.log ذخیره نماید.

mail.info /var/log/mail.log

استفاده از “*” در Selector  به معنی any می باشد.  به عنوان نمونه در مثال های زیر نمونه اول بیانگر این است که لاگ های دریافت شده از mail با هر اولویتی که دریافت شد در مسیر اشاره شده ذحیره گردد. و یا در در مثال دوم عنوان میشود که از هر سرویسی اگر پیامی با درجه اولیت warning دریافت شد در فایل /var/log/warning.log ذخیر گردند.

mail.* /var/log/mail.log
*.warning /var/log/warning.log

نکته مهم:

در تعریف selector نقشی به نام modifier  نیز وجود دارد که با علامت “=”  یا “!” استفاده میشود. در صورتی که در تعریف selector و در قسمت severity از modifier استفاده نشود، به آن  priority  و priority های مهم تر از آن اشاره میکند، در واقع mail.warning  یعنی هر پیامی با اولویت warning و بالاتر از آن (err، crit، alert و emergency). در صورتی که بخواهیم صرفا یک severity خاص را معرفی کنیم میبایست از modifier  “=” را به صورت زیر استفاده کنیم.

mail.=notice /var/log/messages

در صورتی که بخواهیم پیام هایی با اولویت کمتر لاگ شوند از فرمت زیر استفاده میشود که به معنی هر لاگی غیر از لاگ هایی با اولیوت notice و بالاتر خواهد بود.

mail.!notice /var/log/messages

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

mail.!=debug /var/log/service.log

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

در صورتی که قصد داشته باشیم تا پیام را به remote server  یا log server ارسال کنیم میتوانیم به صورت زیر Action را تعریف نمائیم.

*.emerg @logserver.testdomain.ir
*.emerg @172.16.15.14

در خط بالا علامت @ بیانگر ارسال بر روی پروتکل  UDP و @@  بیانگر ارسال از طریق پروتکل  TCP خواهد بود.

در centos  به صورت پیش فرض از rsyslog  جهت ثبت وقایع استفاده میشود. این سرویس به صورت modular  طراحی شده است و برخی از علکرد های آن را میتوان از طریق فراخوانی این ماژول ها استفاده کرد. برخی از این ماژول ها به صورت یش فرض در سرویس  شروع به کار سرویس load  می شوند و نیازی به فراخوانی آنها به صورت مستقل نیست. برخی از تنظیمات این سرویس به شرح زیر می باشند:

  • Imuxsock: ماژولی است امکان لاگ کردن پیام ها به صورت لوکال را از طریق ابزاری مانند logger فراهم می سازد.
  • Imjournal: ماژولی است که در سیستم عامل های مبتنی بر system امکان دسترسی سرویس به imjournal را فراهم میکند.
  • ActionFileDefaultTemplate: مشخص کننده این است که به صورت پیشفرض از کدام template برای فرمت دهی لاگ ها استفاده کند. به صورت پیشفرض این سرویس از فرمت استاندارد استفاده میکند و در صورتی که قصد داشته باشیم از فرمت دلخواه استفاده کنیم می بایست ابتدا template متناسب را ایجاد کرده و به این پارامتر معرفی نمائیم.
  • ActionFileEnableSync: دارای مقادیر on یا off می باشد و به این معنی می باشد که هر بار write های انجام شده را با فایل مربوطه در دیسک sync نماید. این عمل در تعداد عملیات های زیاد نوشتن میتواند کارایی سیستم را کاهش دهد.

Forwarding rules:

همانطور که پیش تر اشاره شد، میتوان لاگ ها را در سروری مرکزی نیز ذخیره نمود. برای این کار علاوه بر این که سرور مبدا می بایست پیام ها را به سرور مقصد ارسال کند، می بایست سرور مقصد برای پذیرش لاگ از سایر سرویس ها پیکربندی شده باشد. در سمت ارسال کننده یا مبدا، برای ارسال  پیام ها به سروری دیگر، یابد از forwarding rule  ها استفاده نمود. میتوان برای پیام های مختلف، Severity های مختف rule  های متنوعی ایجاد نمود.

در زیر یک نمونه از forwarding rule ها آورده شده است. باید توجه داشت که کل مجموعه زیر به عنوان یک rule  درنظر گرفته می شود. در صورتی که قصد داشته باشیم rule  های بیشتری ایجاد نمائیم باید کل بلاک زیر مجددا در فایل کانفیگ تکرار شوند.

$ActionQueueFileName fwhamed1 
$ActionQueueMaxDiskSpace 1g   
$ActionQueueSaveOnShutdown on 
$ActionQueueType LinkedList   
$ActionResumeRetryCount -1    
*.* @@remote-host:514

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

  • ActionQueueFileName: نامی یکتا برای فایل spool متعلق به این rule می باشد.
  • ActionQueueMaxDiskSpace: جداکثر فضایی که فایل spool میتواند در دیسک اشغال کند را مشخص می نماید.
  • ActionQueueSaveOnShutdown: در هنگام shutdown پیام ها را جهت ارسال در آینده در دیسک ذخیره کند.
  • ActionQueueType: متد و الگورتیم مدیریت صف پیام ها را مشخص میکند.
  • ActionResumeRetryCount: بیانگر این است که در صورتی که سرور مقصد از دسترس خارج شد، چه میزان تلاش برای اتصال به آن صورت پذیرد. مقدار -1 به معنی بی نهایت می باشد.

سخن آخر:

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

 

ادامه مطلب

راه اندازی Multipath در لینوکس

راه اندازی Multipath در لینوکس

آموزش قدم به قدم راه اندازی Multipath در Centos

معرفی Multipath و آموزش راه اندازی آن

Path چیست؟

path مسیر ارتباطی بین سرور و Storage  است که میتواند از طریق HBA یا کابل سرور را به storage متصل کند. در صورتی که به هر دلیلی مانند مشکل در San Switch، مشکل در کابل، مشکل شبکه ای و … مشکلی در عملکرد ارتباط برقرار شود، قطع شدن مسیر ارتباطی میتواند مشکلاتی را برای سرور و سریس دهی آن ایجاد کرده و یا کل عملکرد آن را مختل نماید.

در واقع ارتباط بین سرور و Storage آن هم از یک مسیر میتواند  گلوگاهی پر خطر در سرویس دهی و معماری سرویس باشد.  تصور کنید سرور دیتابیسی که دیسک آن بر روی SAN یا SDN قرار دارد. قطع شدن تنها راه ارتباطی آن به دیسک خود و عدم توانایی آن در خواندن و نوشتن داده ها میتواند سرویس دهی تمامی سرویس های وابسته به آن مجموعه را مختل کند.

 

Multipath چیست؟

با توجه به توضیحات بالا، جهت رفع این دست مشکلات معمولا بیش از یک مسیر ارتباطی بین سرور و Storage فراهم میگردد تا علاوه بر ایجاد redundancy  و بالا بردن throughput  در صورتی که یکی از مسیر ها به هر دلیلی دچار مشکل شد، عملکرد سیستم از طریق مسیر فرعی و بدون مشکل ادامه داشته باشد.

در لینوکس ابزاری بومی به نام DM- multipathing  وجود دارد که امکان معرفی چند مسیر برای ارتباط با Storage را فراهم  می سازد. به این ترتیب که مسیر های معرفی شده را با هم تجمیع کرده و هر LUN  متصل به سرور را به عنوان block device جدیدی در مسیر /dev/mapper  ایجاد می نماید.

اجزا multipath:

Multipath دارای چهار جز اصلی و به شرح زیر می باشد.

dm-multipath ماژولی در کرنل است که وظیفه تصمیم گیری در خصوص routing  مسیر ها را در حالت عادی و حالتی که یک یا چند مسیر دچار مشکل شده باشند را بر عهده دارد.
multipath دستوری در command line  است که برای پیکربندی، لیست کردن و یا مشاهده مسیر ها به کار می رود.
multipathd سرویسی است که مسیسر ها را دائما مانیتور کرده تا وجود قطعی در مسیری یا رفع مشکل در مسیر قطع شده، را متوجه شده و آن را به عنوان failed path و یا restored  علامت گذاری می کند.
kpartx دستوری است که به صورت خودکار هنگامی که دستور multipath  اجرا میشود فراخوانی شده، و وظیفه ایجاد device mapper  را برای LUN های  multipath  بر عهده دارد.

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

برای پیاده سازی multipath از دو سرو با مشخصات زیر استفاده شده است که در آن سرور یک به عنوان storage server و  server دوم نقش کلاینت را در این سناریو ایفا می کنند.

Server1: 	
CentOS Linux release 7.4.1708 (Core) 
IP: 192.168.200.200
Server2: 	
CentOS Linux release 7.4.1708 (Core) 
IP: 192.168.200.201

نیازمندی های انجام پروژه:

در این پروژه جهت شبیه سازی شرایط مورد نظر نیاز به وجود حداقل یک LUN متصل به سرور است. با توجه محیط آزمایشگاهی و نبود SAN، از طریق Server1  نسبت به ایجاد یک iSCSI Target  و ایجاد LUN و معرفی ان به Server2 اقدام میکنیم و در نهایت با افزودن دو کارت شبکه دیگر به Server1 پیکربندی Multipath و تست شرایط قطعی را بررسی خواهیم کرد.

پیاده سازی iSCSI:

تنظیمات سمت سرور (iSCSI target):

 

برای ییاده سازی ISCSI در لینوکس از ابزاری به نام target  استفاده می کنیم که این امکان را برای ما فراهم میکند تا یک یا چند دیسک از سرور را از طریق پروتکل iSCSI در شبکه به صورت block device  به  اشتراک گذاشته و یک Storage متمرکز ایجاد نمائیم. به سروری که  iSCSI در آن اجرا می شود و دیسک ها آن به شاتراک گذاشته می شود، iSCSI target  و به کلاینت هایی که به سرور متصل می شوند و از دیسک ها استفاده میکنند، iSCSI initiator  گفته می شود.  در مستند با توجه به موضوع اصلی آن توضیحات ارائه شده در خصوص پیکربندی iSCSI به صورت خلاصه بیان خواهد شد.

مرحل پیاده سازی iSCSI target  در لینوکس به شرح زیر می باشد.

در ابتدا با دستور زیر targetcli را در Server1 نصب مینمائیم.

Server1~]#  yum install targetcli

yum target

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

Server1~]#  systemctl enable target
Server1~]#  systemctl start target

بعد از شروع به کار سرویس با دستور targetcli وارد محیط prompt این سرویس میشویم.

Server1~]# targetcli

در محیط prompt با دستور ls لیستی از اطلاعات موجود و پیکربندی های فعلی را میتوانیم ببینیم.  که در آن تمامی دیوایس ها در قسمت backstore نمایش داده خواهند شد که میتواند یکی از تایپ های block،  fileio، pscsi و ramdisk باشد. در قسمت target  لیستی از iSCSI target  های ایجاد شده داده خواهد شد.

targetcli menu

در اینجا از پیش دو دیسک sdb و  sdc یک physical volume ایجاد کرده و در نهایت یک lvm با حجمی برابر با حجم هر دو دیسک ایجاد کرده ایم را  به عنوان iSCSI target  معرفی نمائیم. اما ابتدا لازم است وارد قسمت block  شویم لذا مراحل ما به صورت زیر خواهد بود.

/> cd backstores/block 
/backstores/block> create LUN00 /dev/isc-co-vg/isc-co-lv

create lunn001

با دستور ls میتواینم ببینیم که block device ما ایجاد شده است.

block ls

حال برای ایجاد target مورد نظر ابتدا با دستور cd /iscsi وارد مسیر iscsi  میشویم سپس با دستور زیر iSCSI target مورد نظر را ایجاد میکنیم.

cd /iscsi
/iscsi> create iqn.2020-01.com.test:server

create iqn

بعد از ایجاد iSCSI target برای آن port group با نام tpg1 ایجاد می شود که داخل آن میتوانیم به صورت زیر دسترسی به Target را فقط برای کلاینت های مجاز فراهم کنیم.

cd /iscsi/iqn.2020-01.com.test:server/tpg1/acls
create iqn.2020-01.com.test:clients

create iqn client

در انتها نیاز است که LUN مورد نظر را به target  ایجاد شده اختصاص دهیم. برای این کار وارد مسیر lun در target  رفته و دستور زیر را وارد می نمائیم.

cd /iscsi/iqn.2020-01.com.test:server/tpg1/luns 
create /backstores/block/LUN00

create block lun00

در نهایت با بازگشت به صفحه اصلی و زدن دستور ls پیکربندی نهایی را خواهیم دید. همانطور که در شکل زیر قابل مشاهده است، LUN ایجاد شده در مرال قبل به acl  مرتبط به clients به درستی map  شده است.

ls after all configuration

در نهایت با استفاده از دستور saveconfig تنظمیات انجام شده را ذخیره میکنیم. البته در صورت استفاده از دستور exit  به صورت اتوماتیک آخرین اغییرات اعمال شده ذخیره خواهد شد اما همچنان می توان با استفاده از دستور saveconfig  از ذخیره شدن تنظیمات مطمئن شد.  پیکربندی های انجام شده در فایل /etc/target/saveconfig.json ذخیره خواهد شد.

سرویس target  را با استفاده از دستور زیر restart  میکنیم.

Systemctl restart target

به عنوان آخرین قدم پورت 3260 را در فایروایل نیز باز میکنیم.

firewall-cmd --permanent --add-port=3260/tcp
firewall-cmd --reload

تنظیمات سمت کلاینت (iSCSI initiator):

در سمت کلاینت ابتدا با دستور زیر iscsi-initiator-utils را نصب میکنیم.

yum install iscsi-initiator-utils

بعد از نصب، وارد مسیر /etc/iscsi/initiatorname.iscsi شده و iqn ایجاد شده برای clients را در آن به صورت زیر وارد میکنیم.

InitiatorName=iqn.2020-01.com.test:clients

cat initiator iscsi

سپس سرویس های iscsi  و iscsid را Enable و start میکنیم.

systemctl enable iscsi iscsid
systemctl start iscsi iscsid

سپس با دستور زیر از صحت ارتباط اطمینان برقرار میکنیم.

iscsiadm --mode discovery --type sendtargets --portal 192.168.200.200:3260

iscsiadm

در صورتی که مشکلی در ارتباط و پیکربندی وجود نداشت، با دستور زیر به iSCSI target معرفی شده login میکنیم.

iscsiadm -m node -T iqn.2020-01.com.test:server -p 192.168.200.200 –l

iscsiadm-m node

در نهایت با زدن دستور  های زیر میبینیم که دیسک جدید به ماشین اضافه شده است و میتوان از آن استفاده کرد.

fdisk –l
pvs –a –o +dev_size

psw dev_size

در صورتی که قصد داشته باشیم ارتباط را قطع نمایئم میتوانیم از درستور قبل با option –u استفاده نمائیم.

iscsiadm -m node -T iqn.2020-01.com.test:server -p 192.168.200.200 –u

iscsiadm disconnect

در نهایت با معرفی LUN مورد نظر به Server2 به نحوه پیکربندی multipath میپردازیم.

پیکربندی multipath:

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

بعد از اضافه شدن اینترفیس ها از این که امکان دسترسی به LUN ایجاد شده در مرحله قبل از طریق هر سه اینترفیس Servcer1 فراهم است، اطمینان حاصل میکنیم.

iscsiadm sendtargets

سپس دستور iscsiadm را برای سایر اینترفیس های اضافه شده نیز اجرا میکنیم تا از طریق دو IP جدید نیز به LUN مورد نظر login کنیم.

[root@server2 ~]# iscsiadm -m node -T iqn.2020-01.com.test:server -p 192.168.200.199 -l
[root@server2 ~]# iscsiadm -m node -T iqn.2020-01.com.test:server -p 192.168.200.198 -l

iscsiadm on server 2

بعد از انجام عملیات فوق در صورتی که وضعیت دیسک های متصل به سرور را بررسی کنیم، خواهیم دید که LUN معرفی شده به Server2 با توجه به این که از سه مسیر مخلف به آن معرفی شده است، به عنوان سه دیسک شناخته شده است.

pvs dev_size server2

حال که دیسک از سه مسیر قابل مشاهده و دسترسی است، به سراغ پیکربندی multipath خواهیم رفت. Multipath  در لینوکس با استفاده از device-mapper-mulitpath یا dm-multipath انجام می شود و همانطور که گفته شد به صورت بومی بر روی سرور های لینوکسی وجود دارد. با این حال ّرای اطمینان از وجود این package میتوانیم از دستور زیر استفاده کنیم.

rpm -qa |grep multipath

در صورتی که این package نصب نبود، با دستور زیر نسبت به نصب آن اقدام میکنیم.

yum install device-mapper-multipath

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

systemctl enable multipathd
systemctl start multipathd

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

mpathconf --enable --user_friendly_names n

درصورتی که user_freindly_names برابر با y قرار داده شود، در هنگام نمایش مشخصات دیسک ها و مسیر های آنها از alias آن ها برای نمایش به جای WWID  استفاده خواهد شد. علت استفاده از WWID این است که این ID برای هر دیسک منحصر به فرد بوده و قابل تغییر نیست در صورتی که نام میتواند به هر دلیلی دچار تغییر شود. در این صورت ممکن است این تغییر نام مشکلاتی درعملکرد و شناسایی تنظیمات مبتنی بر نام ایجاد کند.  در شکل زیر، در دستور اول این گزینه برابر با no و در دستور دوم مقدار آن برابر با yse  می باشد.  تفاوت نمایش با رنگ زرد مشخص شده است.

multipath-ll

لازم به ذکر است درصورتی که WWID ای به نامی map شود، اطلاعات آن در مسیر /etc/multipath/bindings ذخیره خواهد ش

فایل پیکربندی ایجاد شده دارای چند بخش می باشد که در ادامه به معرفی بخش ها آن خواهیم پرداخت:

  • defaults
  • blacklist
  • multipath
  • devices

defaults: 

تنظیماتی است که به صورت پیش فرض برروی تمامی Device ها اعمال می شود. به عنوان نمونه در تنظیمات زیر، از round-robin  برای انتخاب مسیر استفاده خواهد شد، friendly name  برای همه yes خواهد بود مگر این که در قیمت devices و  multipath برای Device مشخصی مقدار جداگانه ای برای آن تغریف شود.

defaults {
        path_selector           "round-robin 0"
        user_friendly_names     yes
}

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

polling_interval بیانگر زمان چک کردن وضعیت بین path ها بر حسب ثانیه میباشد.
multipath_dir بیانگر نحوه ایجاد Device است. درصورتی که برابر با yes  باشد، به ازای هر مسیری که black list  نشده باشد اقدام به ایجاد device برای آن path  نخواهد کرد مگر این که یا کاربر سرویس رو force کند device ی از یک path  ایجاد شود، یا قبلا آن path ایجاده شده بوده و WWID آن ذحیره شده باشد یا حداقل دو path به Device موجود باشد.
find_multipaths بیانگر نحوه ایجاد Device است. درصورتی که برابر با yes  باشد، به ازای هر مسیری که black list  نشده باشد اقدام به ایجاد device برای آن path  نخواهد کرد مگر این که یا کاربر سرویس رو force کند device ی از یک path  ایجاد شود، یا قبلا آن path ایجاده شده بوده و WWID آن ذحیره شده باشد یا حداقل دو path به Device موجود باشد.
path_selector مشخص کننده این است که برای عملیات I/O بعدی از چه الگوریتمی برای انتخاب مسیر استفاده کند. که شامل سه الگوریتم است.
round-robin 0: از طریق ایجاد یه حلقه بین مسیر های موجود هر بار یکی را انتخاب میکند. به عنوان نمونه عملیات اول به مسیر اول، عملیات دوم به مسیر دوم، عملیات سوم به مسیر سوم هدایت میشوند. برای عملیات های بعدی نیز به ترتیب مسیر ها انتخاب و عملیات های I/O به ان ارسال میشوند.queue-length 0: ارسال عملیات های I/O بر این اساس انجام میشود که کدام مسیر کمتری I/O به آن ارسال شده است.
service-time 0: ارسال عملیات I/O بر اساس مدت زمان سرویس دهی هر مسیر انتخاب می شود که بر اساس میزان I/O بر throughput مسیر محاسبه می شود.مقدار پیش فرض برای این پارامتر Service_time م ی باشد.
path_checker بیانگر متدی است که وضعیت مسیر جهت تشخیص وضعیت آن به کار گرفته می شود. مقدار پیش فرض این پارامتر directioاست که اولین سکتور از path را با به صورت direct I/O میخواند. درصورت که موفق باشد، مسیر در دسترس و در غیر این صورت مسیر قطع شده در نظر گرفته می شود.
no_path_retry تعداد دفعاتی است که سیستم سعی میکند از یک مسیر fail شده استفاده کند. مقدار پیش فرض این پارامتر برابر با صفر است.
user_friendly_names در صورت yes بودن از alias Device برای نمایش آن استفاده میکند. در غیر این صورت تنها WWID آن استفاده خواهد شد.

blacklist:

در این قسمت میتوان Device ها را از فرایند multipath خارج یا black list کرد. برای black list  کردن Device ها میتوان از WWID، devnode (device name)، vendor، product، property های device و همچنین بر اساس device type  استفاده کرد.

به عنوان نمونه:

Black list  با استفاده از WWID

lacklist {
       wwid 26353900f0264456456
}

Black list  با استفاده ازdevnode

lacklist {
  devnode "^sd[a-z]"
}

Black list  با استفاده از vendor  و product

blacklist {
       device {
               vendor  "HP"
               product "*"
      }
}

Multipaths:

در این قسمت میتوانیم به تفکیک برای هر Device   تنظیمات بخصوص آن را جداگانه معرفی نمایئم. تنظیماتی که در این قسمت معرفی می شوند، بر تنظیماتی که در قسمت Devices و defaults مشخص شده اند overwrite خواهند شد. پارامتر هایی که میتوان در این قسمت استفاده کرد همانند پارامتر های دو قسمت قبل است. یک نمونه از این تنظیمات به صورت زیر است.

multipaths {
       multipath {
              wwid                  3600508b40000775650000000b0000
              alias                 server1
              path_selector         "round-robin 0"
              no_path_retry         5
		}
	}

devices:

درصورتی که Storage controller ی در لیست تجهیزات شناخته شده multipath نباشد یا بخواهیم Attribute خاصی از آن را با مقدار مشخصی مقدار دهی کنیم، میتوانیم از طریق این قسمت آن را به سیستم معرفی کنیم. برای مشاهده vendor های پشتیبانی شده از دستور زیر استفاده میکنیم.

multipath –t

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

multipath-conf

بعد از راه اندازی سرویس با زدن دستور multipath –ll وضعیت دسترسی به دیسک را مشاهده خواهیم کرد. در تصویر مشخصات دیسک به همراه نام انتخاب شده برای آن و وضعیت مسیر ها  نمایش داده شده است. همانطور که مشاهده میشود وضعیت دیسک ها Active  و آماده فعالیت نمایش داده می شود.

multipath-ll server2

حال برای تست عملکرد یکی از اینترفیس های Server1 را قطع کرده سپس مجددا وضعیت را در server2 بررسی میکنیم.

همانطور که در شکل مشاهده می شود، یکی از مسیر ها به وضعیت failed و  faulty تغییر وضعیت داده شده است.

multipath-ll server2-faulty

وضعیت مسیر بر اساس مقدار polling interval  چک و بررسی خواهد شد و در صورت فعال شدن مجددا به صورت Active و ready تغییر وضعیت داده شده و مجددا مورد استفاده قرار میگیرد.

نتیجه گیری:

در محیط های عملیاتی می بایست برای حفظ دوام سرویس دهی و کیفیت آن، تلاش کرد مواردی که به هر دلیلی میتواند گلوکاهی برای سرویس دهی باشد حذف شده و یا ریسک آنها به حداقل ممکن رسانده شود. بروز مشکلاتی مانند قطعی ارتاط یک سرور به دلیل عدم وجود fault tolerance میتواند ضرر های هنگفت مالی و غیر مالی برای کسب و کارهای حساس ایجاد کند. در این مستند سعی شد تا معرفی multipath مکانیزمی برای تحمل خطا در سرور هایی که از دیسک های شبکه ای مانند SAN استفاده میکنند را مورد بررسی قرار گیرد. باید توجه داشت که پیکربندی این سرویس با در نظر گرفتن محیط آزمایشگاهی و سادگی آنها انجام شده است و در محیط ها عملیاتی میبایست پارامتر های مختلفی را جهت پیکربندی مناسب سرویس در نظر گرفت.

ادامه مطلب

آموزش کامل ساخت LVM در لینوکس

آموزش کامل ساخت LVM در لینوکس

LVM چیست؟

ساخت دیسک  LVM یا Logical Volume Management  تکنیکی است پر کاربرد برای مدیریت فضای یک سرور که قابلیت های خوبی را در اختیار ادمین سرور قرار می دهد. یکی از این قابلیت ها انعطاف پذیری آن است که می توان پارتیشن ها را به صورت توزیع شده، متمرکز یا ترکیبی از این دو را با استفاده از چندین دیسک ایجاد نمود که البته تاثیری در عملکرد سرور نیز نخواهد داشت. همچنین امکان اضافه کردن یا کم کردن فضای آن با کمترین ریسک نیز فراهم است.

همانطور که در شکل بالا ملاحظه میکنید ابتدا دیسک های فیزیکی به physical volume  یا همان PV  تبدیل می شوند و با استفاده از  Volume Group یا VG تمام PV ها به صورت یک گروه یکپارچه در خواهند آمد. در اینجا است که میتوان از دل این VG  اقدام به ساخت Volume Group  های مختلف نمود که می توان آنها را سایز آنها را افزایش یا کاهش داد بدون این که نیازی به فرمت کردن یا پارتیشن بندی مجدد دیسک داشته باشیم. همچنین از طریق این روش میتوان می توان I/O دیسک را نیز بهبود بخشید چرا که میتوان LV ساخت که در پشت آن چندین دیسک وجود دارد که درنتیجه عملیات خواندن و نوشت داده ها می تواند بین دیسک ها تقسیم گردد.

به صورت خلاصه قابلیت های این تکنیک به شرح زیر است.

  • قابلیت افزایش فضا در هر زمان
  • پشتیبانی از انواع مختلف File system
  • استفاده از Migration در ریکاور کرد خطاهای دیسک
  • بازگردانی فایل سیستم با استفاده از snapshot

در این آموزش من از Centos 7  با یک دیسک استفده کرده ام. در ادامه   با دستور  های زیر به ترتیب PV، VG و LV های موجود در سیستم را مشاهده خواهید کرد.

# PVS

# VGS

# LVS

 

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

  • نمایش دهنده دیسکی است که در Physical Volume  مورد استفاده قرار گرفته است.
  • سایز physical disk
  • نام انتخاب شده برای Volume Group
  • سایز Volume Group
  • نمایش دهنده LV های ایجاد شده به همراه VG های آنها که همانطور که از اسم گذاری آنها مشخص است یکی برای SWAP و دیگری برای root سیستم استفاده شده است.
  • نمایش میزان سایز LV ها

با تصور پر شدن فضای دیسک ما سه دیسک مجزا برای افزایش آن به سرور اضافه میکنیم که مطابق با شکل زیر است. و همانطور که ملاحظه میکنید سه دیسک با نام ها ی sdb, sdc, sdd و با ظرفیت 20 گیگ به سرور اضافه شده اند.

#fdisk –l

 


با دستور زیر وضعیت Volume Group های ایجاد شده در سیستم قابل مشاهده است.

#vgdisplay

 

 

که در آن

VG name : نام Volume Group

Format: فرمت و ساختار استفاده شده در ساخت VG که در اینجا lvm2  است.

VG Access:  که نمایشگر Permission های VG است

VG Status: وضعیت VG  را نمایش میدهد که در اینجا  وضعیت resizable  است و در موقعی نیاز شد میتوان ظرفیت آن را افزایش داد.

Cur LV: بیانگر تعداد LV هایی است که از دل این VG ایجاد شده اند.

Cur PV and Act PV: بیانگر تعداد Physical disk  ها و فعال یا غیر فعال بودن آنها است.

PE Size: بیانگر Physical Extents است  که بلاک بندی منطقی physical Volume  برای LVM  محسوب می شود که مقدار پیش فرض آن 4 مگابایت می باشد. به عنوان مثال تصور کنید قصد ساخت LV با ظرفیت 8 گیگابایت داریم با مقدار پیشفرض 4 مگابایت PE size  در نهایت 2048  بلاک منطقی استفاده خواهد شد.

8GB = 8192 MB

8192MB /4MB=2048

Total PE: تعداد کل physical extend  ها

Alloc PE : تعداد PE های اختصاص داده شده و مورد مصرف به LV ها

Free PE: تعداد PE های آزاد و استفاده نشده

در ادامه ابتدا ما اقدام به ساخت یک PV  متشکل از سه دیسک جدید میکنیم.

توجه : پیشنهاد می گردد برای ساخت PV  ابتدا بخش مورد نظر از دیسک جدید یا کل آن  را با دستور fdisk  به یک پارتیشن جدیدی با فرمت lvm تبدیل کرده و سپس مراحل  را ادامه دهید. ساخت PV از کل دیسک به مانند دستور زیر سریعتر و آسانتر است و نیازی به ریبوت ندارد. اما با توجه به مشکلاتی که ممکن است در مدیریت آن پیش آید پیشنهاد نمی گردد. به عنوان مثال با روش زیر کل فضای دیسک برای ایجاد pv مورد استفاده قرار میگیرد و متا دیتایی مبنی بر LVM  بودن آن بر روی دیسک ایجاد نمی گردد لذا ممکن است توسط سیستم عاملی دیگر به عنوان دیسکی خالی تصور شده و از ابتدا روی آن عملیات نوشتن را انجام دهد. در آموزشی جداگانه نحوه پارتیشن کردن دیسک با استفاده از دستور fdisk  را توضیح خواهم داد.

 

# pvcreate /dev/sdb /dev/sdc /dev/sdd

 

همانطور که در شکل زیر میبینید ایجاد PV مورد نظر با موفقیت انجام شد ودر ادامه با اجرای دستور PVS نیز مشاهده خواهید کرد که سه دیسک جدید ایجاد شده اند و بر خلاف sda2  که دارای VG به نام CentOS است این physical Volume  ها فاقد VG هستند.

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

# vgcreate –s 8M [Volumegroupname] pv1 pv2 pv3 … pvn

 

که در دستور بالا –s  برای مشخص کردن PE Size  به میزان 8 مگابایت استفاده شده است در صورت عدم استفاده از این Option  سیستم از مقدار 4 مگابایتی پیش فرض استفاده خواهد کرد. [Volumegroupname] نیز نامی خواهد بود که برای volume Group  در نظر گرفته اید و PV ها بیانگر Physical Voilume  هایی است که در مرحله قل ایجاد کرده است.

ما در این مثال سایز PE را 8 مگابایت قرار خواهیم داد.

 

که در شکل بالا  #Sn  بیانگر تعداد snapshot های موجود در این Volume Group  و Attr  نیز بیانگر خصوصیات آن می باشد که میتواند Writeable, readable, resizeable, exported, partial   و clustered باشد. که در اینجا wz- – n – به معنی Writeable و  resizeable است.

لست کامل خصوصیات به شرح زیر است.

  1. Permissions: (w)riteable, (r)ead-only
  2. Resi(z)eable
  3. E(x)ported
  4. (p)artial: one or more physical volumes belonging to the volume group are missing from the system
  5. Allocation policy: (c)ontiguous, c(l)ing, (n)ormal, (a)nywhere
  6. (c)lustered, (s)hared

با استفاده از –v  در دستور vgs  نیز میتوان اطلاعات بیشتری مانند UUID و سایز PE  را نیز مشاهده کنید.

# vgs –v

 

با ساخت Volume Group  یا VG میتوانیم اقدام به ساخت LV  و اختصاص فضا به آنها از فضای موحود در Vg کنیم .

برای ساخت LV و مشخص کردن حجم آن ما چند روش پیش رو داریم یکی استفاده از PE Size  و دیگری مشخص کردن میزان حجم براساس بایت (sectore,byte,kilobyte,megabyte,….) است که در ادامه از هر چند روش برای ایجاد LV  استفاده خواهیم کرد.

روش اول استفاده از PE size

برای استفاده از PE Size  شما باید مقدار تعیین شده آن برای VG  را بدانید. مقدار تعریف شده در این آموزش 8 مگابایت بود در نتیجه با توجه به توضیحات قبل برای ساخت یک LV 20 گیگاباتی ما 2560 PE  باید اختصاص دهیم.

# lvcreate -l (Extend size) -n (name_of_logical_volume) (volume_group)

 

در دستور بالا –l  به معنی استفاده از Physical Extend  می باشد  و –n  جهت تعریف نام LV مرد استفاده قرار میگیرد.

همانطور که در شکل بالا میبینید LV به اسم PE-LV یا حجم 20 گیگابایت ایجاد شده است.

روش دوم

استفاده از سایز مشخص

# lvcreate -L 10G -n (name_of_logical_volume) (volume_group)

 


استفاده از مقداری از فضای VG  به درصد

در این روش میتوان به جای مصخ کردن مقدار دقیق درصدی از دیسک به LV  اختصاص یابد به عنوان مثال در دستور زیر ما ده درصد از فضای VG  را به یک LV اختصاص خواهیم داد.

# lvcreate -l 10%VG -n mylv  new-vg

 

توجه داشته باشید که در دستور بالا از 10 درصد فضای کل VG برای ساخت LV ساخته خواهد شد نه از فضای باقی مانده. در مثال زیر نیز با اجرای دستور، ده درصد از فضای کل و به میزان 6 گیگابایت به LV جدید اختصاص یافت.

استفاده از باقی مانده فضای آزاد VG

با اجرای دستور زیر تنها ده درصد از فضای باقی مانده و ازاد از VG  ایجاد شده برای ساخت LV  جدید مورد استفاده قرار خواهد گرفت

# lvcreate -l 10%free -n mylv  new-vg

 

با دستور بالا از 20 گیگابایت فضای باقی مانده از VG، ده درصد برای ساخت LV جدید استفاده خواهد شد. برای استفاده از کل فضای خالی VG  کافی است مقدار را برابر با 100% قرار دهید.

هدف نهایی ما در این آموزش ایجاد سه LV  با حجم 20 گیگابایت بود در نتیجه مابقی LV های ایجاد شده را حفذ میکنیم و تنها همان سه LV  را نگه میداریم و برای راحتی بهتر در ادامه کار نام آنها را نیز تغییر خواهم داد.

# lvrename VGname Old-lvname new-lvname

 

یا

# lvrename /dev/vg02/lvold /dev/vg02/lvnew

 


و در نهایت

برای این که امکان استفاده از LV  ها فراهم شود نیاز است که با یکی از انواعFile system  که ما فرمت ها آنها را فرمت کنیم در اینجا من قصد دارم از فرمت ext4  استفاده کنم. برای این کار از دستور زیر استفاده خواهیم کرد.

# mkfs.ext4 /dev/new-vg / lv1

# mkfs.ext4 /dev/new-vg / lv2

# mkfs.ext4 /dev/new-vg/ lv3

 

در نهایت Logical Volume  های ساخته شده با Mount  شدن به یک دایرکتوری قابل استفاده خواهند بود.

برای mount  کردن lv  های ساخته شده ابتدا سه دایرکتوری خواهیم ساخت سپس هر کدام را جداگانه به یکی از دایرکتوری ها mount  خواهیم کرد.

# mount /dev/new-vg/lv1       /tmp/lv1

# mount /dev/new-vg/lv2      /tmp/lv2

# mount /dev/new-vg/lv3     /tmp/lv3

 

با دستور dh  میتوانی LV  های ساخته شده و مسیری که به آنها Mount  شده اند را مشاهده کنید.

از آنجایی که دستور mount  به صورت موقت عملیات mount  کردن را انجام می دهد و با بارگزاری مجدد ماشین تغییرات اعمال شده از بین خواهد رفت، نیاز است تا هر LV  و مسیری که باید Mount شوند را در فایل fstab نیز اضافه کنیم.

ما خط های زیر را به فایل مذکور اضافه خواهیم کرد.

/dev/new-vg/lv1              /tmp/lv1             ext4       defaults               0  0

/dev/new-vg/lv2              /tmp/lv2             ext4       defaults               0  0

/dev/new-vg/lv3              /tmp/lv3             ext4       defaults               0  0

 

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

# mount -av

 

خروجی دستور mount  بعد از ریبوت ماشین.

 

تا اینجا ما با نحوه ساخت physical volume, Volume group  و logical volume  آشنا شدیم. در آموزش های بعدی نحوه resize  کردن آنها و همچنین Snapshot  گرفتن و بازگردانی آن را آموزش خواهیم داد.

امیدوارم مفید واقع شده باشد.

ادامه مطلب